I got a notice from LaunchBar 5 that RC 2 has been released. Most excellent. The release notes say that there have been a lot of changes - to the clipbard, to the tiny URL feature... all very nice.
I have to say that I really like the clipboard history feature. I use that a lot. It's getting closer to final release, but I've been using it every day for quite a while and haven't run into any problems. Excellent timesaver.
While I've been dealing with a lot of jUnit testing issues this past week, for the last two days I've been dealing with the realities of trying to match the actual data from the system to the application I've got and that had turned out to be a lot more difficult than I had hoped.
The problem is classic: they have no comparison tools for the final stage in testing. They rely on eyes to look at one and the other over time to see if things "look right". This, as expected, can be very hit-n-miss, and I was getting a lot more of the latter than the former.
It's pretty easy to see if you're not even close, but if you're off by 10%, is that a mistake, or a sampling interval issue? Hard to say. If there's a lot of volatility in the sampled data, then maybe it's as close as you can expect to get. So I find myself wishing for fewer jUnit tests and better test frames for the end result. The fist are nice, but the second are critical.
In the end, the only way I'm going to get better test frame data is to be a part of it's creation. Unfortunately, I may have to do that.
OK, I'm a TV nut. Well... I used to be. Now I'm an ex-TV nut, and still I like to watch the shows I want to see. Things like House, M.D.. This morning I heard about a new Hulu Desktop application (beta 0.9.1) for Mac OS X, and I have to say it's amazing.
This is exactly what I've wanted to see from one of these online video archive sites. Sure, it's got commercials, and from what I've seen, many are the exact same commercial over and over during the same show. But even this isn't bad. I can deal with that. It's the experience that matters.
Now I'm looking at the nicest desktop app for video I've seen in ages. It's clean, smooth, clear, and beats my Comcast DVR hands-down for viewing video. I'm almost ready to go get a Mac mini and hook it into my TV just so I can run this app and see the TV I want to see, when I want to see it.
DVR is still dicey. This is the best of FOX, ABC and Disney all online with a lot of older shows (Hill Street Blues, St. Elsewhere, etc.) that I watched back in grad school and loved. It's simply incredible. Well worth the time and effort.
Also, I don't really like the web-browser-based viewers. I code, and I have my browsers set up for what I want them to look like. These sites all want you to reformat that to fit the TV show. No longer. I can fire up the Hulu Desktop app and it's stand-alone. Sure, it's probably just a web-browser underneath, but that's OK. It's standalone. That's nice.
If you like TV, get it.
The fantastic folks at Apple are at it again with an update to iWork '09 on Software Updates. The release notes are simple: helps when saving documents. I'm not sure of that means that there were file corruption issues in the previous version, but it's good enough for me to take the time to update.
It's still more fun to work in iWork than MS Office for me. I guess I'm biased.
The folks on the Google Chrome team have a nice download site for the shapshot builds of Chrome for Mac OS X and linux. I can imagine that the linux port will be a tough GUI as the platform isn't really about a consistent user interface, but the Mac OS X port is coming along nicely.
I'm sure it's not even at the alpha stage in the group's mind, but it's up and serving pages. Sure, that's about 10 mins. with Xcode, but the fact is they have the similar GUI to the windows version and it's working. They are making progress and that's nice to see.
In the end, I'm not sure whether Chrome or Safari is going to be the best browser on the Mac. It's nice to have a choice like that, however.
UPDATE: Ah... it's Chromium that has the builds - not Google Chrome. The former is the basis of the latter, but the two are different. Still... you need to have the one to have the other, so progress is still a good thing.
[6/5] UPDATE: Well, that didn't take long. It seems that there is a Google Chrome for Mac OS X out now. Very early release, but it's there and they are working on it. So they only lagged the Chromium release by a few days. Nice to see they are working on it.
I'm not a big widget fan, but this guy is really rather impressive. Yeah, it's as much that it's PHP, and I'm a big PHP fan, but it's a slick interface to the problem of a language that seriously needs a manual like this. One of the criticism of PHP is that there are so many functions that are database-specific (for instance). This makes one long for a more general function set.
But until then, this is a great little tool to look up the functions in a Dashboard widget.
I'm a huge fan of data visualization tools, and OmniGraphSketcher is a pretty nice looking tool. This morning I noticed that they had released 1.0 beta 4 with several nice improvements on the way to the final 1.0 release.
As soon as I get some time, I'm going to have to throw a few graphs together with this tool. It's demo screencasts are impressive and look to be capable of making publication-quality graphics. Nice.
Today has been a lot of messing around. I'm in the middle of adding a few new features to the app I'm inheriting from another developer and it's been a bit of a challenge. Over the last two days I've been adding the code and the unit tests to the codebase, and today it was time to get it all loaded up into the test server(s) and see how it runs. Things took a little longer than I'd have hoped, but all in all, it's understandable given that I haven't used these servers before today.
A few bumps in the road, but at least they had my favorite cereal in the kitchen this morning. It's amazing how something as simple as what you have for breakfast can really change your mood. There's got to be studies based on developers/creative types where they look at the effect of a new pad of paper, or a clean set of editor colors, or a new font - or cereal, has on your mood and how, in turn, that effects your productivity. In any case, it was a bit of a rough start, made smoother by those wonderful squares of goodness.
So I finally got things running and it came time time to compare the numbers between the code we added, and the application where we're getting the raw numbers. This application also does the aggregation of the raw numbers and that's what we're comparing. Did they match? Some. Never a good result.
I worked the rest of the day trying to get 29West working between a server of data and my app... didn't have a lot of luck, but did find out that speed/duplex problems are rampant even here, and my linux box was plugged into a switch that was improperly configured for auto/auto operation. That was fixed and helped a lot of things on my box, but not the 29West issues.
The data matching tests revealed that the formula I was using for the normalization of the values was wrong, and the right formula was a single factor different - not too bad, really. I fixed that up in the code and fixed the jUnit tests and things started to look better. But still not perfect.
Then the 29West guys noticed that it wasn't my box, but the sender's box that was having problems. So hopefully they'll get on that box and fix things up so he can send around the network. We'll have to see tomorrow.
Finally, my co-worker did the exhaustive testing of taking the raw data and using Excel manually aggregate it and compare it to the data in the app. There's only one problem with one instrument. It was just sprinkled throughout the portfolios so as to make it appear that there was more of a problem than there was. This was good news, but the day was over.
I'm sure glad I had those Mini Wheats.
I'm not a huge flickr user, but I've got a few photos up there and when I was first looking at it, I wanted a Mac desktop client to make it easier to upload a lot of photos (thinking this was going to be a big thing for me) and when I looked, one of the nicest desktop flickr clients was 1001. It's been quite a while, but they finally updated the app to 1.0.17.
Exactly what's new in this release I'm not sure, but it's been a while and I'm guessing it's a few little things that will make the experience a little nicer. I can still see all my photos/images on flickr, so it seems to work. If I see something really awesome as I play with it, I'll write it down, but it's enough to see an update for me.
I can really appreciate the case for unit tests. I have built them in many forms - 'test apps' and simple running tests that exercise the components, all the way up to jUnit tests for Java. There is a place for each, and I can see their value. But anything taken to an extreme can be bad. Very bad.
Take the case of unit tests I ran into today working with the original developer of an app adding a new feature to said app. It wasn't that hard... OK, it was harder than it should be because no one wanted to take responsibility for the data in the system.
OK... here's the problem.
Options expire. Futures expire. Options on Futures expire. But when an option on a future expires on the same date as the future, then the time it expires can be shifted. This is most easily solved by having the expiration date/time a table that understands this. But as with the Y2K issue, shortcuts are often taken in the initial stages of a project, and these things are thought to be "insignificant". Then, several years later (just like Y2K) the fixing of the problem is far far bigger than it would have been initially.
The system we were looking at had the future expiration date/time and the option expiration date/time. I said that the easiest way to know what to do is to look at the dates of these two expirations, if they are the same, then expire the option on the earliest of the future or option expiration. That way, if the future expired first, then the option is dead and has to expire at the same time. Simple.
If the future expiration date/time data were maintained properly in the system. Alas, it is not. Only the date component is maintained. So we had to put in a hack. I hate hacks. This was a double hack in my book because the author felt the best solution was to add a new constructor argument with a map of expiration times for 'double expirations' based on the future. This was then placed in a Spring XML file and then used in the code.
In truth, the change was only about 20 mins to do. We talked about alternatives for much longer than that (Given how I hate hacks). So the time required wasn't too bad.
But the jUint tests... oh... the tests.
We spent the next several hours updating jUnit tests to work with the new functionality. While I'm all for the testing ideas, when the testing code is bigger than the code under test, there's a hint you're doing something wrong. When you find a bug in the testing code, you know you're in trouble.
Testing code is meant to do Unit Testing. Not massive Q/A tests. Those are almost impossible to simulate and there's a reason that they exist. If you're spending two hours fixing up tests with 'fake' numbers, then chances are, you're making a mistake.
I still did it. I believe that consistency is very important - even if it's something I'd fight to the end of time to redo. If it's there, and if you're going to keep it, then by golly... make the new code work like the old.
But when unit tests go wrong, there's almost nothing worse. Almost.