What's it all about, Alfie?

Last night I had a release of the server and in the release package I thought the shell scripts were included. Now, it's obvious what's happened, but I really thought they were included. Then, while walking to the train, and with no hopes of going back and fixing it without being home late, I went ahead and got on the train. Then I got the call. Yup, what I had thought about was the case - the deployment package did not include the shell scripts and there was a critical path change in this release. Crud!

It was easy enough to fix when I got home, but the problem was that the opening greeks were going to be missing because of the failures in the calculation nodes. So I had to reload all the underlyings with positioned options. This took about 40 mins, but could be done without having to take the server down. Since the Hong Kong day was already in full swing this was the far better idea.

As I was doing this by hand, I was thinking that it would be nice to have a little program that would do this for me. Well, this morning when I came in I started doing a little digging and sure enough, I had written a tool to do just this many moons ago. I had just forgotten about it until I had the time to dig into the possibility. Next time, I'll remember.

My point is that while I know it just makes me look more human (so says my wife) it really is terribly embarrassing to make mistakes like this. Sure, it was easily fixed and I fixed it, but the fact that I made the mistake was what bugs me. Deep down, I knew there was a problem because it came to me like a flash on the way to the train. So there was something there trying to tell me what I was doing, but I was sure it was going to be OK.

Wishful thinking.

I need to lighten up a bit. Everyone makes mistakes and I have no problem forgiving others, I just have a hard time forgiving myself. I remember a scene from My Favorite Year when Swann (Peter O'Toole) was yelling to Benjy (Mark Linn-Baker) about going on TV live - "I'm not an actor! I'm a moviestar!" Benjy gets angry at Swann for starting to walk out and says something about how Swann has always been his hero, and heros never walk out. Swann is upset with the responsibility this places on his, as he really likes Benjy, and reacts badly by saying something to the effect of "I'm not that person! I'm just a person.". Benjy responds with the best lines in the show: "I can't use my Alan Swanns life-sized. I need them as Big as I can get them." And then the clincher: "Oh... and by the way, No one is that good an actor." Swann comes around and saves the day. In the end, seeing that the person Benjy sees in him is really there, if he just believed in himself a bit more.

I feel I need to be better and not makes those mistakes that are so easy to make. I don't want to be just ordinary. Man... the baggage we carry around from our childhoods. I've certainly got my share, and it comes out when I make mistakes like this. Double-Crud!

Things are looking a lot better today with regards to the horrible application that I was working with again today. This is the one where there are empty tables, interesting method names, and nothing in general telling us what's really going on. Today I was able to successfully track down the problem to an ancient data access layer by proving that this application requested the instrument data, but never got anything back from the service. This would normally be a simple matter of looking at the database access for the loading of the data from the appropriate database, but no... that would be far too easy.

I had to find the place where the query for this service was being built, and then in an entirely different directory (library) of this app, the data was being read in and processed. It's amazing that anyone actually understood what was going on here. Maybe there were code generation tools in the initial versions, but there aren't any now, and it's an amazing lump of horrible code to try and find out something as simple as what was asked for and what was returned.

In the end, I'm confident that it's a data problem in the database that's used to return the information for these calls. What exactly is wrong, I have no idea, but there's a group that does this all day long, and while they don't necessarily have any better idea about this than I do, at least they have time to invest in getting it tracked down. I need to be doing other things, and not spending more time on tracking down a data problem.

While I don't do a ton of web coding, I have to say that when I do it, it's nice to have Coda around, and just yesterday they released an update to v1.1 - the move to Leopard. The changes seem to be across the board - GUI changes to match the new UI of Leopard... engine changes for a lot of the things like CSS, etc. ... fixed a few bugs, added a few features. Not bad.

Every time I use Coda, I keep wishing there was more web coding to do. Fact is, it's a joy to use and I just like using it. I can't image a better recommendation than that. It works, and it works well. It looks great too. Super.

Today I spent most of my day dealing with a horrible system that has been folded, spindled, and mutilated far more than anything I've ever seen. This code has methods like:

    void klugeToGetAroundAnotherFatAssBug( ... );
    void klugeToGetAroundAnotherFatAssBug_node( ... );

and I'm not kidding, either. The old coders of this mess didn't think enough of the even older coders of this mess to write decent methods and just fix things. No, they had to make it personal. This is what I'm walking into. I really hate it.

Anyway, today I had to try and track down a data problem that was effecting just one instrument in the application. I looked in the tables in one of the databases it uses, and found the table the data should be in. Nope... it's empty. Nice try. But then why keep the table there? Just to mess with people's heads?

Then it hit me - it's The Curse. Good, decent programmers have to work on this code and it is such an incredible burden to them that they go insane and go work in flower shops, or pump gas for a living. It's painful, but it's real.

I want to get this solved, and then document a few things about this mess and then move on. It's not going to be easy, and it's certainly no fun, but it's what I do.

I know it's ranting... I know it's tilting at windmills, but darn it, these large ISPs that are not really doing the right thing for their customers are really yacking me off! The other day it was Comcast and their blocking ports and messing with responses to requests. It's frustrating that it seems the companies with the capital to provide large bandwidth are the same ones that are the most intent on keeping it to web and mail traffic. It's incredible.

Then today I'm trying to upload a few files from work via an AT&T DSL line to my HostMonster account and it starts to send but fails in the response. I know about this as it's happened before, and I can solve this problem by doing it while I'm at home - from Comcast. Now I don't know why AT&T's DSL is messing things up - and it honestly might not be AT&T - but it's upstream where I can't see the HostMonster boxes and they can't see me.

It's really amazing. In the old days, I'd have had a modem in my laptop and I'd dial into the ISP I needed to get to and things would just work. Today the speeds are faster - which is nicer, but the connectivity is probably a lot less. Trying to stretch their infrastructure to the limit to get the most customers on it before having to upgrade it is just the typical corporate way... and it's leading to regulation. They are going to find themselves looking down the business end of massive regulation if they don't clean up their act.

One of the things that I keep coming back to every so often is the simulation work I did during my Ph.D. Now that I had upgraded to 10.5.1 on my laptop, I wanted to see about getting the code going in x86_64 mode. I have had it running in 64-bit on PPC, but now that Xcode supports it, and the gfortran I use does as well, I was interested in seeing if it was going to run faster - or slower, in x86_64 mode.

The first thing I noticed was that the LINPACK routines that I had taken and hand-tuned to the problem were not working out well with the 64-bit compiler. I was getting SegFaults, and rather than mess with trying to fix those versions, I thought I'd use the BLAS and LAPACK that are bundled with Mac OS X in the Accelerate Framework. These are supposed to be optimized for the AltiVec (PPC) and SSE3 (Intel) so I was thinking that moving this way was a nice upgrade.

The code changes weren't major - primarily in the data storage going into the functions, so it only took me a few hours to fix all that up and clean up the code with a few #ifdefs to make it compile either with the LINPACK routines I built or with the LAPACK functions that came with the OS. What was major, were the results.

As I had hoped, the 64-bit version of LAPACK was faster than the 32-bit version. However, the surprise was the fact that my 32-bit hand-optimized routines were faster still. If I wanted, I'm guessing that I could update these guys to 64-bit by looking at the use of the data element sizes - that's got to be the cause of this as the logic is fine, and then I might very well have something that's faster still. What a shot in the arm! I had no idea that the modifications I had made were going to be that fast. Good for me.

UPDATE: I went into the code and found that it was a simple matter of how the integers were being passed from FORTRAN to C. By putting a simple typedef in the code:

    /*
     * Because we need to be able to build this for 32-bit and 64-bit
     * versions, I want to be able to typedef the integer here so that
     * the value coming in from the FORTRAN code matches what we will
     * use here. Without this, we'd have a mess on the conversions.
     */
    #if defined(__x86_64__) || defined(__ppc64__)
    typedef int f_int;
    #else
    typedef long int f_int;
    #endif

and replacing the long int with f_int (FORTRAN int), I was able to use the same code for both builds and the errors went away. Nice.

Since it is so new, I didn't want to turn on TimeMachine too early in my using Mac OS X 10.5 (Leopard) because I didn't know if I was going to have issues with 10.5 in the first place, or exactly how they built TimeMachine and how it would function. My initial questions were pretty basic: What would happen if I disconnected the drive between backups? Would it error on me when it tried to run? How fast was it going to be? Basic things that you want to know before you invest a lot of time into using a tool like this.

I was initially pretty sad to see that the initial backup of my MacBook Pro was 64.64GB, and took about 3.5 hours on a FireWire 400 external drive. Yeah, if I had a FireWire 800 drive it would have been faster, but this is the guy I got a while back to do my own backups on. So it's not fast for the first (initial) backup. But it seems to be complete. The real question to me insofar as 'completeness' is: Does it backup /usr/local/ as well? I'm going to have to dig into it and see what it's got. Maybe it does, and maybe not. Certainly, it's not a crime if they don't, but then I'll have to maintain my own backups of /usr/local/ when I install new things, etc.

When it was done with the initial backup, I was pleased - nay, very pleased, to see that if you unmount (disconnect) the external drive, then TimeMachine sees this and says that the next scheduled backup is when the drive is connected. Very nice, guys. Very nice indeed. This means that I can use it as I want - keeping it connected when I'm at work - most of the time, and then when I roam, I'll be without backup or restore. Not a bad trade-off, really.

I'll have to see how it runs for the rest of the day taking backups every hour. I'm hoping that I don't even notice them being done. That would be ideal. On my G5 iMac at home where I've had TimeMachine running since I upgraded it, there's a noticeable activity on my LaCie 500GB drive, but that's the drive and not the machine or TimeMachine. I can live with that.

So far, very nice. We'll see how it runs, now.

UPDATE: it's great to know that the backup includes /usr/local/ - that's a big load off my mind. Super.

When I put code segments into a post, I've used BBEdit's Copy as XHTML function to get it out of BBEdit and into the post. It makes something that's impossible to edit in the post, but it looks nice, and it previews nice in MarsEdit. So, all-in-all, not a bad solution.

But it's not perfect.

So I decided to look for a WordPress plugin that would do a similar job, but simply, and without a ton of things I had to manage/deal with. What I found seems to be a nice little compromise between what I had and what should work really well for me. It's called WordPress:CodeHighlighterPlugin (obvious, yes) and it appears to do all the languages I can imaging and it's all just PHP code as a plugin to WordPress. Additionally, to use this you simply use the <pre> tag with an additional lang argument to indicate which language to use. You can also optionally specify line numbers to be generated and where these line numbers should start.

While this plugin doesn't allow me to preview the code in the form it will appear, it does allow me to easily edit it. So it's a trade-off. I'm not sure how much I'll use this guy, but it's loaded and it's there, and should I need it, it's nice to know that it's there. I guess I'll try it out the next time I need to put code into a post.

There's a reason I like working where I do - it's not the hours, that's for sure. It's that for the most part decisions are made by the appropriate people. That means that if there's a need for the entire organization to be involved, then the decision is handled at a very high level. However, if it's the decision to update from an unsupported product to a supported version of the same thing, then, again, for the most part the decision is handled at a low level as there's not really a lot that we're going to do about it. We're going to have to update, and what we update to is really the only question.

Today I've had a couple of things I'm working on go from being properly handled to being very improperly handled. A while back it was the ordering of hardware and the request to get the vendor's technical sales reps involved. True to my prediction, they knew nothing. They took more than two weeks to come back and tell us that they knew nothing. Total waste of time.

A few weeks ago, we wanted to get a nice messaging bus in - Tibco EMS. We knew it was going to be a ton of money, but there were a ton of reasons to spend it now and convert the Shop to Tibco. But since it wasn't going to solve a pressing problem, it was into the "project" category... complete with timelines, Visio diagrams, step-by-step proposals. The Works!

I read a wonderful quote the other day attributed to Mark Twain: The best time to fix a hole in the roof is when the sun is shining. The reality here is much more like: They only time to fix the hole in the roof is during a monsoon. I appreciate that this is not pocket change that we're talking about, but the problems facing us aren't likely to be solved in an afternoon, either. Serious problems demand serious people and serious tools. This is not something to slap together with perl and Visual Basic.

But that battle is lost. Today I was trying to get a new version of the modeling libraries into production. I try to keep a low profile - there's no real option. We have to do it, so the fewer people that know about this the better. The fewer people involved the better. More visibility almost always translates to slower decisions, more arguments, more grief, and in the end, since there's really no other option, simply a slower roll-out of the needed functionality.

I tried not to get flustered with this as it was a friend that made the critical mistake of involving too many people early on. His opinion is (was) that this would be 'no big deal', and could not have been more wrong. I appreciate what he was trying to do. He just wants to keep people up to date and he thinks it'll be a slam dunk. But when someone usually thinks that I have the nervous feeling that if they are wrong, they'll be wrong in a very big way.

So it got involved with four more people that have very little time to look at things and have very little idea of the real alternatives open to us. This means that they'll look at a difference of 0.0005 and say "That's too much - match it exactly!". But Dude! That's the old numbers... we match the new ones exactly. Let's not get bogged down about the difference on what was - let's look at what is.

But I know that's not how it's going to go. It's going to be a few days of people discussing it and trying this permutation on the data, and that input set, and this and that until they get frustrated and finally see that it's the old values that are off and give up. In the end, it'll be just as if they never got involved. They'll add nothing, because there's nothing to add. But it's something to argue over.

This the is most Dilbert-like part of my job. I really don't like it.

There are days that I don't mind that Comcast is a big organization that really is horrible at customer service and responsiveness to their customer base. Then there's the P2P spoofing that's annoying, but for the most part, even this is glossed over in my day-to-day interactions with them. After all, there aren't a lot of choices in the broadband market in the Chicago area. But then today happens and it really starts to make me angry.

I was trying to simply upload a few web pages to my home servers - nothing special, but I wanted to upload them and then look at them. But Comcast's monitoring of the 'standard' ports and hindering them got in the way. See, because I have multiple machines with the same servers (web, ssh) running, I needed to do port forwarding on the firewall, so only one machine is on the 'standard' ports, and the others are on clearly non-standard ports, but since I know what they are, I can deal with it.

So I try to SSH to a non-standard machine and I get in fine. I try the same thing to the standard port machine and Comcast times out on me. I go to the non-standard machine, get in fine, and from there, SSH to the standard machine just fine. So the machine is not the problem - it's bloody Comcast and their crappy port hindering/filtering/dropping rules. Why? What does it matter if I use the capped bandwidth for web serving or downloading stuff from their web site? Who cares? Are they trying to legislate/regulate morality? Computer usage? What gives?

I try the same thing with the web servers. The standard one fails and the non-standard one gets in just fine. So I'm sure that it's Comcast, and they have a record of the P2P problems and now that's a class-action lawsuit. When will they learn? Be the "Good Guys", and just let people use what they have paid for. Don't waste your time on the filters, spoofers, lawyers, etc. Just sell us the service and let us decide how to use it.

Do the phone companies regulate how you use your phone? Nope. How about the water company? Nope. Why should we allow these crappy ISP companies to do it? Because most people don't know or care.

Grrrrr... makes me mad.