What's it all about, Alfie?

It's amazing how complex systems can really bite you in the rear. I'm reading Prey as well as trying to get a few fixes out that have been impacted by a seemingly minor change in one of the data sources I use. Seemingly, I say, because the ripple effects were far wider than I had originally thought, and to fix each one has taken more time than I had originally planned. Oh sure, the changes I knew about have been put into place just fine... it's the ones that I didn't know I'd be facing that are real pains.

For example, I'm using the JEP Java Expression Parser, and while it's a nice piece of work, it's got some structures based on Hashtables as opposed to HashMaps. This means that I can't ask it to represent null values properly as the old Hashtable can't deal with that. Since the error reporting it less than "stellar", I don't even get good error messages when I give it a null. So that brings up the problem of testing for a null in an expression - clearly, you can't. But what a pain when the HashMap is right there!

I've now taken the route that any null variable value is immediately bad news, and the expression can never evaluate to true which is the point of the expression - to filter results. I'm hoping that this takes care of the problems I've been having, but it's never over till it's over, and I don't hear and fat singing lady.

Not yet, anyway.

I have to admit that I don't like debugging code that isn't mine. In fact, it's one of the most frustrating things I can think of. You are stuck between the users of the software and the vendor and neither is really capable of giving the other what they are needing at this moment. The developers want detailed stack traces, detailed information about what was being done - something that makes it more repeatable. Users just know it crashed and they didn't necessarily start it in such a way as to get this information because they didn't think that it would crash.

So to the developers I have to say "Hey, this is what I have and I know it's not much..." and to the users I have to say "OK... I'll let them know" but in the end, there's not really a single thing I can do other than to try and replicate the problem myself in an environment that I can get the necessary information from the application for the developers.

What I really want is the source code so that I can look into putting more advanced features that might make it a little easier to figure out what happened. Alas, that's not possible, and I'm stuck being in the middle. Not the best place to be to really help with solving the problems, but if that's the only place to be, there isn't a lot of choice.

It's an interesting thing, building better software.

I've finally gotten a first cut done at the application that will allow me to make journal entries a lot easier than before. This is a little Cocoa app that runs on Mac OS X and uses XML-RPC to communicate with the server that hosts my journal. It's interesting that there seems to be a hit-n-miss nature to it working from certain access points, but that's probably as much the access as it is the software. I'm sure it could be more reliable, but as long as it connects and does the job, I'm happy.

I have completed the first few tests and things are really looking up.

OK... one of the things that I've been trying to do over the last few days is to create a new mechanism for uploading and editing all the entries in my journal. Since I've put everything behind a router/firewall, I don't have easy access to all the ports of the server, and that's good, but also it limits what I can do in terms of creating a client for the Journal.

I remembered XML-RPC as one simple implementation of a remote invocation system that's transported completely on top of the web server's port/protocol. This then, would be ideal - since I have all the machines' web servers opened up through the router, and with XML-RPC I have the choice of platforms to write both the client and the server. I decided to go with PHP for the client and a native Cocoa app on Mac OS X for the client.

The choice of PHP for the server seems like a good one. I have all the database connectivity I need and the methods that I'm creating are small and pretty fast - even on the hardware that I'm using. I will admit that the docs were a little thin, but it didn't take more than a few hours to get my server running. Interestingly, I didn't know that it was running until I put the client together.

I have to hand it to Apple - they have put together some of the greatest tools I've ever used. In Jaguar (10.2) they had an implementation of XML-RPC in AppleScript and while it had problems, it was still there. Thankfully, the guys at Ranchero created another XML-RPC implementation for Jaguar that didn't have these issues. When I checked their latest Cocoa documentation pages, it seems that Panther (10.3) has a better XML-RPC implementation built into it. So I used that.

There were several issues with getting the data passed back to the caller - most notably, that the PHP arrays can't be passed as arrays in XML-RPC, at least not in the implementation that I got. They end up getting passed as associative arrays/structs and in Cocoa that's NSDictionary objects. Not obvious and certainly the most difficult part of the project. Once I knew what the data really was, iit was a simple matter of matching things up. Yet there was still one more problem.

While at work, I have a standard internet connection - meaning a DSL line behind a router providing NAT, etc. When I try to hit the web site as a simple web site the browser never really renders the page. If I use telet to the right port, the data comes back just fine. This means that the connectivity to the host is fine, it's something with the browser - in this case, Safari 1.2. Since the XML-RPC service is also based on the core web services that drives Safari, it's not surprising that it hangs as well. Very strange.

The result is that the reason for the creation of the server and client is is part of the problem. If I'm at home, then there's no hanging and no problems. Also, I can easily SSH from work to the box meaning that not all the tools/services are effected. A simpler solution may be to create an X11 app and then SSH into the box and run the app there. Seems sort of silly as text files work just fine. So maybe the solution is a few scripts that send and upload the files. Seems like if SSH is solid it'd be easier to do that, but it certainly isn't as interesting and fun as making the client/server work with some kind of protocol.

We'll have to see if I get any clues as to why this is happening and if it's even possible to clear this up. Looks kind of doubtful right now.

One of the things I really like is getting surprised by really well written software. It doesn't happen everyday, so it's really nice to be really shocked by a chunk of code.

Thankfully, today is one of those days.

I was working with a few of my web sites and one of them happened to be on an NT box. I have the NT box for several reasons, but they all seem to be less important the more I try to do something on that box and find out that because it's NT, I can't. No good telnet server... no really solid ftp server... no OpenSSH server for security... it's so unlike all my other systems (all Unix of one sort or another), it's difficult to get some things done.

So I was trying to figure a way to get the web site fixed and I thought about BBEdit's "Open from FTP Server..." functionality. It's nothing short of amazing. I was able to look at the directory structure and load in the file as clean as you please. Then edit it a bit, save it and reload the page. Everything was working perfectly. I was stunned that it was as easy as it was.

In the end, it didn't matter that my NT FTP server wasn't really 'good', it was good enough for BBEdit. I got everything I wanted done.

I've been around the Intel computing platform since the 8080 was hot stuff. My first computer had a serial interface to a teletype and later to a first-generation video display terminal. I've used DOS on Intel since version 1.3... I say all this to make a point that I've seen a lot and done a lot over the decades and for the most part things have gotten better. For the most part.

Case in point - hardware is much better than it used to be. Also, I have to hand it to Microsoft for coming up with significant advancements in the base OS such as abstracted printer drivers and such. Pre-Windows software had to ship with it's own printer drivers which is why so many Unix software dealt with only Postscript. It was on the network and a known language.

Still, many things haven't improved. This past week I've been "upgraded" at work from Windows NT to XP. Now I've had XP at home on a few computers I don't really use, and so I've gotten all the changes down and I'm pretty comfortable with it, but working on it all day long is another issue. So I was trying to keep an open mind about going to XP in the hopes that things wouldn't be as bad as I had thought they'd be.

Well... I hate to say it, but I was wrong. It's no different than NT, and in many ways, worse. OK, what's the big issue? Well... there are programs like PuTTY that I've used for a long time to access servers that is having a very hard time running well on XP. It could be the install of XP that the Bank is doing, but if that's the case, then there's another thing that Microsoft has done wrong with XP - allowing people to break it on install.

I have moved off NT/XP as my primary development platform, but all my apps have to run on NT/XP and so I have to deal with it every day anyway. This makes me realize what's good about it and what really isn't. I'm totally surprised that in XP the terminal sessions are "old style" window bar and not in keeping with the "theme" of the rest of the windows. Why in the world did they do that? They had to have seen it and known that it was inconsistent... It's totally amazing to me that they let this pass.

Sure, most of the suite of tools runs OK - Office, development tools, etc. But even then, there's the problems with certain tools and the backslash vs. forwardslash difference in Cygwin. It's enough to make a cross-platform developer cry.

But I also have a good upgrade story to tell - I've ordered the 17-inch PowerBook and it should arrive in a week or so. This will be a very nice upgrade and will carry me forward for at least another couple of years. I have been looking forward to this for quite some time and it's getting very exciting thinking about all new and different things the PowerBook has. Certainly, the display is important, but the backlight keyboard is going to be nice, as is the processor and memory. It will be nice to have all that drive space, and the DVD burner will be a nice tool to have.

It's just amazing to me that even when Microsoft sees what's better they don't take the steps to incorporate those changes in the same way that they've done with Office and the Browser and the TCP/IP stack - all these were separate products, but as they became more important to Microsoft, they started to provide them. It's amazing that XP is as bad as it is.

Anyway... back to try and get some more tools installed, or figure out why the ones I have now aren't working right. It's never easy with them...

I spent a little bit of time yesterday updating this and that on sherman and fiddled with Vim on OS X. There's the Carbonized version that's really more akin to 'gvim' on linux, and then there's the command line 'vim' with no graphical component. I'm sure if someone really wanted to make one distribution they could, but I'm not unhappy about having to deal with two versions. They are both based on 6.1, so the differences are all exceptionally minor and don't effect me in the least. However, I needed to get the colors on the Terminal windows right, which was as simple as setting the TERM variable to xterm-color and away we go. It's really quite nice.

I've also spent a little time with the X11 xterm on OS X to get the default colors to be white on black. This meant editing the ~/.Xdefaults file and putting in the lines:

xterm*VT100*foreground: white
xterm*VT100*background: black

But the really interesting part was that the file had to be a 'Unix' file for it to be read properly. On Mac OS X you can have DOS files, Unix files and Mac files - all with their different line endings. Well, X11 needs to have the Unix 'newline' endings or else it won't work properly. This is a very nice thing to know, and it would have saved me quite a bit of time to know that. But, in the end, everything worked out and the defaults look great. Once again, the command-line vim works great in the xterm session.

One more little thing I updated was to the latest version of iTerm - a very nice little tabbed terminal emulator. It's come a long way since it's initial releases, and I have to say that it's pretty darn close to being my preferred terminal program because it will make it possible to get more terminals in a smaller space, and there isn't an abundance of space on my iBook's screen. Very nice.

Safari seems to be coming along, and I'm hoping to see a new release in the coming days. Also, the iPods are way past due for an update, and while I'm not going to get one of those until my existing MP3 player craps out, it's still exciting to wonder what the next generation will bring - besides increased storage.

I've been working on a few changes to the code for these projects at work and I've gotten myself to a point today that I've tested everything, but there is so much to release it's going to be a pain in the morning. I've changed more than I probably should have for one day, and while I'm not worried about the changes working (I have tested them), there are still a lot of things to do when rolling out new versions of the apps that it's going to be a very busy morning tomorrow to get everything done in time for the first traders.

Thankfully, I stopped changing things when I realized that I'd pushed the limits, and so I've had time to write everything up, update the docs, and make a good To Do list for tomorrow morning. I'm pretty sure I've got everything covered, but it's going to take a bit of final testing to make sure that everything's OK in the morning.

Yikes!

On a lighter note, it's interesting to see how interdependent everything is when you build a large number of large systems and each feeds data into the other. Yup, it's circular data time, and it just makes keeping things straight that much more important. However, it is interesting to see that all these systems work together to get the complete job done. Of course, no user is really interested in the least, but they aren't really supposed to either.

From here on out, I'll be planning my daily changes a little more carefully so as not to get into this spot again. Just a little bit uncomfortable this afternoon keeping everything straight.

I had a little time today and decided to try to get a few performance numbers for barney by Indigo². I've got shark my Ph.D. thesis simulator in g77/gcc and also have numbers for several different machines in my office. I was a little surprised to see what the numbers came out to be.

For the Weak Inversion - Triode Operation simulation I have the following total run times:

This puts barney at the top end. About what I expected. Again, there's a lot more to total system throughput than the CPU's MHz rating.I'm planning on doing a little development on barney and was just a little curious about the relative performance of him to the other boxes in the office.

UPDATE: When I ran the same tests on my iMac (sherman) it was clear that the new hardware really spanks the old guard - as nice as they were at the time.

Lots of things are changing these days - work, mostly, but there's plenty of things going on at home as well. Hey, it's the season of change and renewal, right?

I got jikes source code for barney by SGI box and sherman by iBook. Both are a little disappointing in the java compilation speed department. It's interesting that sherman is a 600MHz G3 and barney is a 195MHz R10000, but their compile speeds are quite comperable. Just goes to show that MHz isn't the real determining factor in system performance.

Anyway, jikes is a Java bytecode compiler that's a lot faster than javac - like taking a 30 sec. compile to 5 sec. - it's really impressive. Anyway, I've been using it in my development on Linux for a while and it's given me good bytecode so there's no reason not to take advantage of it on my other platforms. Now I've got a lot zippier compiles on my other development machines. Nice.

Work is difficult in that the layoffs are starting to 'happen' - meaning that work is piling up and the management isn't really yet showing any interest in selecting projects for 'mothballing' due to the cuts. What it seems like is what I feared most about the cuts - that it was assumed that everyone that got cut contributed nothing or next to nothing, and so their absence will not be missed. This is, of course, sheer maddness, and as a result, the work environment is getting more and more detached from the management, and less productive.

It's kind of funny, these cuts... it's done two things that I'm guessing the management didn't want to do - make the place less productive as a whole, and cause there to be a significant gap between the workers and management. I know they expected for things to slow down with only half of the people (overall) remaining, but I'm guessing they didn't plan for the toll on those of us that stayed that the increasing workload represents. It's a demoralizing level of work, and clearly cannot realistically be done by any human being. So without some 'relief' in the way of mothball projects, each of us is left to wonder about the relative priorities of all the jobs we've just taken on.

Added to that the fact that the "Dilbert Gap" that's developing in the ranks, and you have a group of people who are far less interested in making the managers look good, feel good, and since there's clearly no money for bonuses and raises, there's even less motivation to work hard. It's a circle that feeds in on itself - more disconnection and work lead to a "who cares" attitude, which leads to more disconnection... It's a very bad scene.

So it's fair to say that depression is a constant companion these days for about everyone I've talked to - both those going and staying. I talked to two guys today in the elevator - one going and the other staying. We talked about how things are going, in general. It was depressing, but also at little bit comical. I mentioned that I thought those that were going had a larger short-term pain than those staying, but the long-term pain for those staying was far greater. It just depends on the job market. I'm betting that if the job market were better - regardless of the profit/loss of this place, there'd be a lot more people leaving because the short-term pain of a mover would be next to nothing.

I've talked to others that are staying and they are actively avoiding management because they don't have any motivation to do the work that they have been saddled with, and rather than have a confrontation, they simply avoid them. What a place!

I know that this is not like having a terminal disease. It's not even like having a real problem like a bad back or even a really bad sinus headache. But it is demoralizing. It eats away at the soul and argueably causes more damage to a person than all but the cancer. There really isn't a way to remain in this situation and not be effected. Maybe, with time, the place will get better, but I'm not overly optimistic on that. I'm trying to stay optimistic, but it's hard.