What's it all about, Alfie?

Today I've been up to my neck (again) in the code I inherited that I seem to be bound to with rope and Crazy Glue. This time, I was trying to add to the Flex client a little data that was in at least one of the XML data feeds. Turns out, it wasn't in all three of the necessary XML data feeds, and therein lies my sorry tale of woe today.

The original author believed that, when it came to JUnit tests, if a few are good, a lot are really super, and dozens are really far out. While that might be true, the problem today turned out that the data driving the tests wasn't contained 100% within the JUnit tests, but also took data from the database, etc. and when things changed, as they have in the last few weeks, you run into a lot of broken tests, with no real way to easily fix them.

There are a few things that unit tests - even automated unit tests, are really good for. But they are all basically small, utility class functionality that isn't dependent on date, or time of day, or anything not controlled by the test. When you have things like database configurations, or expiring instruments, then you need to be very careful, because when you come back to the tests after a prolonged period of inactivity, you can get into a really bad place... and that's where I found myself today.

There were errors all over the place, and the one line of code change could not have accounted for the failures. There was something else, but what? The problem with JUnit tests is that you typically only get an error and an exception stack. It's up to you to dig in there to see what the problem is. Sure, the unit tests I've made have a lot of sub-tests in them so that it's pretty darn easy to see what caused the problem, but that's not required. Unfortunately, these tests I was working with were very complex, and no real intermediate results, so it took me about an hour to figure out the problem: database changes.

This is where the unit test concept really fails. It took a simple one-line change and drug it out to more than an hour of work. This is not what the proponents of unit testing put forth. In theory, since I just added one thing, they would say I'd only see a different where that caused an output difference. But that's ideal, and this is the real world.

So I got the changes in, and the tests corrected for the new data in the database, and things are OK for now. But in a few months, it might happen again. A 10 min change drags out into an hour-long test-fixing enterprise. Gack!

MarsEdit 2.4 was released today and the Sparkle notes say the changes are:

• Improved Squarespace support
  • Support for server drafts
  • Support for tags
  • Support for adding new categories
  • Improved error handling
• Post editor windows now automatically remember size and screen position
• Avoid accidental post publishing by disabling the send button when document is not frontmost
• Improved error messages for misconfigured Tumblr blogs
• Bug fixes
  • Fixed Flickr image links so they produce valid HTML when align-centered.
  • Fix a Snow Leopard problem that prevented the Save button from enabling immediately when document is edited
  • Fix a rare bug that could cause locked up dialogs on the second launch
  • Fix a crash that could occur when configuring a blog with an extremely weird URL
  • Fix a bug that occurred when an invalid URL was specified for a blog home page
  • Fix a bug that caused duplication of tags on a previously published draft
  • Fix a bug that prevented existing open document from being located when opening a local draft.

I'm very interested in the post windows saving their position, but I'm not certain that it'll solve my issue with the size of the post window. Alas, we'll have to see when I install the update.

UPDATE: nope, the minimum size of the post window is exactly the same. So it goes.

When HandBrake 0.9.4 was announced, I immediately downloaded the new 64-bit version for Snow Leopard, and was excited about the possibilities. It's great to see the move to 64-bits, even though I know it's going to take a long time to get the vast majority of the apps there, it's great to see some open source headliners get there sooner than later.

But I hadn't tried to use HandBrake to rip a DVD since the upgrade. Just no need.

Then I read this off Daring Fireball this morning. Very interesting. I have to wonder how on earth the HandBrake guys built the 64-bit version if they didn't have a 64-bit VLC, and if they didn't have it, what did they use?

I have the FairMount (32-bit) installed, and can use that in the interim while VLC gets around to creating a 64-bit binary. Alternatively, I could just go back to a 32-bit HandBrake, and then move to 64-bit when VLC is there, but that isn't necessary with the FairMount work-around.

I just never imagined that they'd ship something that can't work. Very odd. If it turns out that the work-around takes too much time, then I'll fall back to a 32-bit HandBrake. But if I'm lucky, the 64-bit VLC will be out before I need to rip another DVD.

While I haven't had need to use it in a long while, Bean 2.4.2 was released today and I decided to pick up a copy. There are quite a few Snow Leopard fixes in this release, which is great news. I like having a fast, lightweight alternative to Pages that's capable of dealing with Microsoft Word files. Nice to have in my pocket.

Being an Electrical Engineer, I've always had a soft spot for SPICE, and the Mac port: MacSpice is a great little version that can get you some really nice performance and top-notch simulation results on inexpensive hardware. Today I noticed that MacSpice 2.10.22 was out and there were a few nice additions and fixes. While I'd really like to see a graphical client for SPICE, but I don't really have to have it, and the commercial ones are nice, but far too expensive for playing with.

Noticed today that Adium 1.4b16 is out with only three bugs left to be fixed until they release 1.4 final. I have to admit, this is one of the more complex pieces of code I use that's open source... it's put together by a bunch of guys that do it for the fun of it. Gotta appreciate the effort. I know I sure do.

This morning I noticed that HandBrake 0.9.4 was released - now with 64-bit versions that are Snow Leopard ready. It's my favorite way to rip DVDs for my Mac and iPhone - there's just nothing that even comes close.

This morning I noticed that iPhoto 8.1.1 was out on Software Updates. Not a major update, mostly effecting the facial recognition, but still, it's nice to see the update. I take a lot more pictures with my iPhone than I ever did in the past. iPhoto makes it very easy to organize and share them.

Today I had a most uncomfortable experience. We are using Subversion as our SCM, and while it's generally quite nice, it's a little difficult to branch with it. More to the point, it's difficult enough that some folks simply refuse to branch. This really makes the SCM a one-way train: no backing up... no detours... always ahead, straight ahead. It's really selling the product short, but more importantly it's very limiting.

So today I had changes that needed to go in, but needed database changes before they could go to UAT. It's all checked in because it's running great in Test, and I expected the database changes to be made this afternoon. Bummer is, they aren't going to be made, it seems, this afternoon, but that's not really the problem.

The problem was a teammate wanted to push to UAT with changes, and had updated before making their changes, which is something you should do. Problem is, they can't push to test until the database changes are done. So what's the fix?

Well, if we're using SVN, the solution would be to branch off the trunk one revision back of my checkins, add in the changes to the system on the branch, check it in, and publish it to UAT. Then, merge the branch back in on the trunk and everything is fine. There's a record of what went to UAT, and it's the "textbook" way of getting around this problem.

But what happens if you are unwilling to branch SVN? Well... you might ask your co-worker (that would be me) to back out their changes so you could put your changes on the trunk without any branching. This certainly works, because then I'll put them back in and everyone would be happy: the person that didn't want to branch wouldn't have to, and I'd have to back-out and then put back in again, my changes.

Wait a sec... doesn't sound like everyone is happy. I'm getting the short-end of the stick.

Given that people aren't going to want to use branching, the best solution (in my opinion) is a Distributed SCM - like git. With git, I would have had my code checked-in, but not pushed to the central repository. I'd build that into the "push to UAT" script so that the central repository always has what's in UAT, but every developer is free to SCM whatever they want without having to worry about others using that repository.

It really is a very unique way of looking at the problem: use a distributed model so that you don't have to interact with others except at times of mutual agreement.

I'm going to be pushing to use git at the Shop now. This is just not something I want to have to go through again. It's only happened once, but that was more than enough. I can't make people learn to use the tools, so the next best thing is to isolate myself from them.

This morning, another release of OmniGraphSketcher 1.1 (this time: beta 2) was released. It's getting more full-featured with every release, and I have to say, it is fast approaching my favorite visualization tool - DataGraph.

I think OmniGraphSketcher is focused on the Keynote-style graphs, and DataGraph is focused on the scientific journal market. Still, they are getting closer, and that's great news.