Well, if I lived in Egypt or Pakistan, I'd really appreciate the update to VelaClock to 2.1.13 as it fixed the Daylight Savings Time rules for those countries. Since I live in the US, it's just a fun update to have, and not really that necessary.
Got it for the fun value.
To continue the update frenzy, I noticed this morning that DrawIt was updated to 3.7.8 and it's meager update notes say:
- Resize handles are now visible and working outside the document canvas
- Fixed a bug in the Cut-Bounds function
Again, nice, but it's a pretty rock-solid app already and I haven't run into problems with it. Great drawing tool to cover what Acorn misses.
This morning has been a bonanza of updates. When I restarted after the 10.5.7 update, I noticed that Acorn had been updated to 1.5.3 - and I had to get that. The update notes say:
- No longer clipping off the corners of custom brush images, when you rotate the brush in the Brush Designer.
- Cleaned up some drawing artifacts when making selections while zoomed in.
- The 60pt Flat Spatter 60 brush now picks up on the current color, instead of being just black.
- Selecting "Crop" from the Image menu now sets to current tool to the crop tool (but only if there's no selection to crop already).
Sounds nice, but honestly, I hadn't run into any of these issues, but it's great that he's still working on it.
Once you update to Mac OS X 10.5.7 you can then hit Software Update, and if you've installed the Safari 4 Beta, you'll get the update with the security patches, etc. This brings Safari 4 up to 5528.17, and I'm sure that means something, but it's the latest and it works with 10.5.7, and that's what I'm looking for.
Good enough.
Can't help but like this - a new version of Mac OS X is available on Software Update 10.5.7. From what I've heard, this looks to be one of the last updates to 10.5 before the release of Snow Leopard (10.6) later this year. There is a complete list of updates available, and a separate list of security fixes. Not bad.
Gotta take the time to update.
UPDATE: on the update, my machine hung and I had to power-cycle it. When I did that, everything resumed updating normally, and things worked themselves out. Also, after the update, I did another Software Update and got the latest Safari 4 Beta. Nice.
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.
I just got a tweet about an update to MarsEdit to 2.3.2. The Sparkle notes say that the changes include:
- Flickr browser fixes
- Add support for deauthorizing the current account
- Fix an issue where a bad URL or missing image size could be inserted
- Fix a bug in the display of ampersands (&) in image titles
- Use Leopard 10.5 style for window's status bar text
- AppleScript date-setting command now accepts string date descriptions
and while I don't use flickr a lot, I do have some pictures there, and with the iPhoto integration, when I get a camera I will carry, it might be a nice way to put images on the weblog.
Definitely worth the upgrade time.
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.