What's it all about, Alfie?

Today has been a day of struggling with Visual Studio 2008, C# and VBA scripts. It's not my favorite suite of tools, but I didn't get to pick them, and there was a bug that needed to be fixed, and this was the easiest way to fix it.

There's a Windows app with an exposed COM interface and the VBA script 'talked' to it and set it in a state ready to do some work. Then the C# app hit it and did the work, but the end result was that the numbers weren't right. So I had to find out what was wrong, and why.

To it's defense, Visual Studio 2008 is a decent windows development IDE. It's got all kinds of nice things to make it easier to develop and debug an app, but it's the fact that I've been away from Windows for so long that getting back into it is just painful. There's no gdb and make, and it's C# as opposed to Java or C or C++. So it's a struggle for every little thing.

In the end, I was able to set breakpoints and see that the values weren't what I expected. There was a bug in the VBA script and the value folks thought were defined, really weren't, and so were assumed to be zeros by VBA. This caused all kinds of problems, the upshot of which was the numbers were wrong.

By defining the enum values in the VBA script, all of a sudden everything worked. The C#, the underlying app... it all just worked. All for the lack of a few undefined variables. I had wondered where these were defined, but the answer I kept getting was "in the DLL". I had my doubts, which is why I was able to see this problem, but it's just another reason I'm not fond of Windows programming.

Life would be so much simpler if I could code on my Mac all day long. Or linux... that's not horrible, but it's not as sweet as the Mac.

I've been doing a lot of stuff today on a project another developer built. There are a lot of interesting ideas in the code, lots to use, but there are little things that keep making me wonder why it was put together the way it was, and that slows down what I need to do. An example is that the code throws a NullPointerException for an unknown command, and that's OK. It's the expected behavior. In my mind, there should never be a NullPointerException thrown because it's just too easy to check all the times you'd get one, and make sure that you don't try to message a null. Simple.

This made me think back to several conversations I've had in the past with developers, as well as lots of things I've read over the years about the productivity gap between decent developers and really top-notch developers.

There's clearly a difference between great developers and good developers. Much of it is experience, domain knowledge, and education. But it's not always that simple. Some of the best developers I've worked with did not have a wealth of experience, but they had made the most with the experience they had. They weren't the ones with the most education, but they kept learning and always drove to the root of each problem to make sure they understood why it happened, and what needed to be done to correct it. And I suppose in doing these things, they acquired the best experience in the time they had.

But how they got it, or what their specific qualifications were, aren't nearly as important as how they did the job. That's the big difference.

A great developer is worth far more than a good one. Even the development paradigms designed to make great developers from good ones don't really work that well. Sure, they will make fewer bugs, and the effective developer multiplier might be 1.5, but it's never going to be 10.0 - it's just not realistic. I think of woodworking... using bad, rough, chipped tools in different ways may make the table look better, but it's never going to be the same as using good tools, and the right tools for the job.

While in many cases, it might not seem like it matters, in my experience there are more times that it does matter that management doesn't think it does, than times that it really doesn't matter. Management fools itself into believing that it doesn't matter if this is throw-away code. But it does. Hacks hurt.

In the end, I haven't found the replacement for a really good developer. They understand the problem, how to design the right system - not too little and it can't expand and grow, and not too much so that it's overly complicated for the task at hand. It's a skill. It's not magic or luck. And those that think it doesn't matter are kidding themselves. It does. All the time.

I have to say that while it's been tedious to do some of the servlet functions for the server administration, it was amazingly easy to do the communication and GUI. I mean this is really the strength of the "Web 2.0" (AJAX/CSS) way of doing things. Had I known of this back in my last job, I'd have never built the monolithic old-style web app that we built. Everything was a call to the server and a new page. The calls could have been so much more lightweight and the interactivity so much better.

Even the Java applets could have been nicer as they could have done similar things to get the data from servlets and update themselves automatically. Simple.

But, in fairness, that project was started at least three years ago, and while the technology existed, there wasn't the level of support and understanding there is today. Well... at least that's the story I'm going with.

It is nice to be able to whip something up quickly and have it work very nicely.

I ran into a bug in my web app today that I should have seen coming, but my head hadn't been in the multi-threaded space at the time, so I missed it. The core concept is that JavaScript can be driven on multiple threads (timer, user interaction, callback, etc.) and if there are multiple threads doing things to the same codebase, you have a multi-threaded program, and you'd like all the tools a general multi-threaded language.

In my reading, I have heard that certain JavaScript engine implementations are single-threaded, but that's not part of the specification, and it's up to the implementors to decide whether or not to make the engine multi-core. In general, I think it's more likely that as time goes on, more engines will be multi-threaded rather than less.

The code I was having problems with this morning looked like this:

  prevRange = graph.getVisibleChartRange();
  if ((prevRange.start.getTime() == maxGraphRange.start.getTime()) &&
      (prevRange.end.getTime() == maxGraphRange.end.getTime()))) {
    prevRange = null;
  }

where I'm getting the selected range on the Google Visualization AnnotatedTimeLine widget and comparing that to the original (un-zoomed) values, and if they are the same, I'm nulling it out. The reason for this is to preserve the zoom level across changes to the graph, but the problem is very tricky.

Since JavaScript is inherently multi-threaded, I have to be aware of the possibility that things are being changed underneath you from timers and AJAX requests... so there's the possibility that while you're running this code, the graph itself is updated with data and redrawn, and in that redrawing, the data is invalid, and there will be no valid range on the graph. Resulting in the first line returning null.

This null then creates a null pointer exception in the code when it's asked for start in the second line. Not nice. So I had to protect the code from that possibility by saying:

  prevRange = graph.getVisibleChartRange();
  if ((prevRange != null) &&
      (prevRange.start.getTime() == maxGraphRange.start.getTime()) &&
      (prevRange.end.getTime() == maxGraphRange.end.getTime()))) {
    prevRange = null;
  }

The problem with this is that it's possible that there was a zoomed range, and in the redraw, and just plain bad timing, we're going to loose that because the method getVisibleChartRange() is going to return null when it was just incapable of returning anything meaningful. The better solution would be to have a mutex on the graph, and have it not return anything while it's redrawing, and then when it's done, return the answer.

But that would presume the concept of a JavaScript mutex. But nothing like it exists. Odd, isn't it? It just hit me this morning, and I did a bit of Googling to see if there were anything I was missing in JavaScript or a library that might act as a mutex, but there really isn't. That's too bad. Really too bad.

What it means is that there's going to be something like it one day, and that's going to make coding in JavaScript much nicer, and it also means that there's nothing I can really do to fix up the code. There is a slim possibility that there will be an update to the graph while hitting that one section of code that will be invalidated by the inability to lock (block) the update.

I suppose I could think about setting a value before the update and then restoring it afterwards... Hmmm... something to think about.

The story seems to be that there have been two recent updates (as in this week) to Google's Chrome browser - one for a security fix, and another for a problem with the 2D image handling. At the same time, I got a call yesterday from some network security folks asking if there was a way to run my web app in the Chrome 'environment' without allowing the users to run the browser itself.

I understand their position - network security is such that an unknown must be considered dangerous, and certifying something is going to take a lot of time and effort. Unfortunately, the JavaScript in the Google Visualization API needs something like Chrome to work well at the amount of data that I'm working with.

So there have been a few updates this week. Nothing major for me, but certainly something to keep an eye on from the network security folks.

My favorite Mac OS X editor - BBEdit, was updated today to 9.2. There are several things I asked for in this release:

• ability to make ctags files from the bbedit executable
• added better function searching in navigation bar

to be fair, there are a ton of changes, and unfortunately, not all of them I'm really happy about. The biggie I noticed right off was the fact that the status bar is now below the horizontal scroll bar, and there seems to be no way to hide the horizontal scroll bar. I need to scroll horizontally, but not all that much. The old scheme was perfect, in my mind. Sad to see it's gone.

After looking at it for a little bit I decided that since I could not remove the horizontal scroll bar, I dropped the status bar. Not what I wanted, but it seems unavoidable.

UPDATE: Interestingly, the file position "appears" to the left of the horizontal scroll bar if you move the cursor. When you switch to another window, it disappears again. Interesting... this is the single most important part of the status bar, and since it's available as I'm moving in the file, I guess it's not really "missing". Great. Kind of wild, but neat.

This morning I read that the Google Visualization team has put another version into Release Candidate mode where you can ask for version '1.1' and get access to now. They expect to make it 'production' this Sunday (May 10), and want to have people test it and give them feedback.

The changes are all under the covers and when I tried it I didn't see any difference, so I'm guessing that things are working, which is really nice. Gotta test these things as I'm going to be forced to use them in a few days.

Well, he's done a major update to DataGraph, the nice 2D plotting package (and framework) for the Mac. It's pretty darn nice, and the release notes in the download package indicate some of the major new features. There are more templates, lots of possibilities on the data views, and updates on all the usability stuff.

The framework is now quad-fat for 10.5 (PPC and Intel, 32 and 64 bit) and I got that update as well. I noticed that he had added a few more examples, which I'm excited to look at and see what he's done with the tools. In all, it's about perfect for what I need. I just wish he'd add in the 3D mapping to 2D - heat charts and contour plots. Those would make this perfect. It's still pretty darn nice.

I firmly believe that the best way to do anything is to give it everything you have. All of it. All the time. As they say, Leave it all on the track. Do that, and you'll never wonder if you could have done more. Never. That's a really nice feeling. The problem is that to do this is very tiring. Very.

I've been running full-tilt this week, and it's taking it's toll on me. I'm really tired. I was really tired this morning. But I kept at it. That is one of the really nice things I learned in grad school - you can keep going after you think you can't, you just have to know your own limits.

And today, I have to say, I wrote some great code for my web app because I was running towards a 'finish line' of the QA team getting ahold of it this afternoon. Well... they didn't end up starting to test the app, which in the end, was fine. I needed the entire day to finally fix up the last of the new features. Difficult. But worthwhile.

In a few hours, I'll be rested (a bit) and I'll be able to look back on today and realize that there's nothing I could have done to get more done today. I got an enormous amount done. Useful, nice things - all.

I just need a little rest.

And a nice weekend.

I got in on the LaunchBar 5 beta back at Beta 6, and I haven't been sad that I did. It's worked flawlessly, and I do love the addition of the clipboard history - that's a huge benefit to me and the way I work.

Now they have released LaunchBar 5 Release Candidate 1 and I had to get that, as well. The release notes say it mostly a few usability fixes and a couple of small bug fixes, but that's OK, it's getting close to done, and the polish is starting to be applied. In all my experience with Mac software, LaunchBar has been one of the best apps I've ever used. Amazing.