More on Modern Version Control

Lately, I've been trying to select a modern choice of VCS for personal (and freelance) work, as well as picking a recommendation for my current place of employment. I'm leaning towards Git (see my previous post), but I would still like to head off any potential arguments for the other contenders - in this case, namely Mercurial.

Here's a very detailed comparison of the top three DVCS solutions: Git, Mercurial, and Bzr (which I'm not considering). It doesn't necessarily make the choice for me, but it gives a good idea of what the advantages and disadvantages are.

One sticking point of Git, when it comes to making a recommendation at the office, is that it has very poor Windows support. It is really only available via Cygwin and doesn't really have any decent GUI tools outside of Linux. Given that I use OS X for personal and freelance work, this isn't an issue.

Mercurial (or Hg, which is its command-line executable - and the atomic symbol for Mercury -- very clever) has great support on Windows, but this isn't surpising: it's written in Python. This means that, in general, it is fairly cross-platform. There is also good a GUI tool for Windows, namely TortoiseHg.

The one thing that's not clear for me from this comparison is which tool has the better branching and merging model. Git has it's rebasing and can do complete historical merges, as well as more of a standard branch/merge model. Mercurial's model is less well known to me at this time, so perhaps the next step in this decision process is finding an equivalent of Pro Git for Mercurial.

Getting Git

Pro Git is an excellent book on the Git version control system. It covers all aspects of Git from the day-to-day basics and branching to the use and setup of remote repositories. It is concisely written with excellent examples. The diagrams are particularly helpful in understanding branching, particularly in the context of merging and rebasing.

A must read for anyone considering a distributed VCS.

Double Disk Failure

You'd think I'd be good at this. You'd think I'd be disciplined. I've had enough catestrophic hardware failures in my life, that you'd think I'd have a regular backup strategy of the important files on my main computer (a Macbook). You'd be right. Well, at least I did up until my back-up drive died...over a year ago.

Pretty useless strategy when your main hard-drive dies.

Normally, this wouldn't be as catastrophic as it sounds. Except that I'm in Germany, and I don't know where to go to find parts or restore the data on my drive. Nor do I even have my OS X disks (or any disks, for that matter, to even try Ubuntu) or the tools to repair the laptop. Fortunately, I have an iPod Touch, which proved invaluable for finding information and stores. I was able to try a number of steps to see about recovery, even with these obstacles.

First, I tried to install Ubuntu to a thumb-drive and boot from there. I have a thumb drive on hand, and could download Ubuntu (using my flatmate's laptop), so this was a good, free option. Following this guide, I had no problem setting up the thumb-drive. However, it turns out, that Macbooks won't boot Linux from USB drive. I haven't yet looked into whether or not it needs to have the right partition table, but looking around the web, it doesn't seem to be possible.

Second, I found an electronics store - Saturn - and bought some CD-R's^[1] and a copy of OS X: Snow Leopard. My second, less-then-free-but-still-cheaper-than-buying-a-new-hard-drive strategy was to install Snow Leopard to an external USB hard-drive, which I happen to have on hand. Following this guide, I began by formatting and repartitioning the disk. Remember when I mentioned that I'm in Germany? Well, it seems that this disk did not exactly survive the flight here in my luggage. The format failed repeatedly, using Disk Repair failed repeatedly, and even when it seemed to work, the install would fail immediately when attempting to write to disk. At least, I was able to verify that it was only the Macbook's disk was broken.

Third, I found another electronics store - Conrad - where I could buy a new hard-drive (double the size of the old one, so there's one silver lining) and the tools to replace it. 70 Euro later, and I have the parts to fix things^[2]. Thanks to iFixit and their tutorial for replacing the hard-drive, I was able to easily install a copy of Snow Leopard.

So, I'm left with a clean laptop^[3], and the task of restoring all my applications. This is a bit of a pain, since some of them don't run on Snow Leopard (I'm looking at you Microsoft Office 2004), and I don't have the disks on hand for others (Adobe Creative Suite). I'll have to find some open-source alternatives, in the mean time.

It's a relief having it back up and running. Aside from being my personal development space, it currently is my communication platform and my entertainment platform. I've lived with out a computer before, but it takes a week to get over the hole it leaves in my life. I'm glad it only took a few days to plug that whole back up.

[1] The CD's were for creating a bootable Ubuntu CD, as a backup plan.

[2] Total cost: 102.70 Euro - Not too bad really

[3] I have yet to find a place to recover the data from my old disk, but I may wait until I'm back in the States.

Twing of Jealosy

It's stuff like this that makes me want to give up working in business-related applications: SIGGRAPH2009.

Frankly, there some pretty cool concepts there.

File Madness

One thing that has already driving me nuts about the iPhone OS is the file system interaction. It's not necessarily something that I'll have to deal with very frequently, but the way standard directories are defined is a bit of a hodge-podge:

Getting your Application bundle directory (where all of your resources are going to be written):

NSString *resourceDir = [[NSBundle mainBundle] resourcePath];

Getting the Application's Home directory, where its documents, cache, and temporary directories are (as well as the above mentioned bundle directory):

NSString *homeDir = NSHomeDirectory();

But to get any of these other directories it get's uglier:

NSArray *paths =
 NSSearchPathForDirectoriesInDomains(
     NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];

The least they could have done is given us a simple function to get that document directory, something like NSGetDocuemntDir(), for example.

Now, all this is in the documentation, but the bundle directory (where all your project resources go) are not considered files, so therefore, are only mentioned in passing in the File section of the documentation. I have been less then impressed by the developer documentation from apple. It's complete, but I just don't find the organization to be all that intuitive.

First iPhone App

I finished the first pass at a working iPhone app. It's a port of the SpiderMonkey Javascript engine from Mozilla. I've put together a simple UI with an editor and output text areas. Currently it only has an alert() function and a print() function for displaying results in the output text view. It does have all of the default functions and objects for JavaScript 1.7.




Source available here. I am looking to host the project somewhere, but I haven't decided on a Mercurial hosting solution that's free and allows me to upload an existing repository.

Now, I can't actually submit this to the App Store (it uses a separate language interpreter). I did it as an exercise in porting an existing application as a first step for porting another application which uses SpiderMonkey as its scripting engine. That one has a lot more graphical and file issues, so it'll be a bit more of a challenge.

Back to Mobiles

I spent a good chunk of time, early in my career, working on mobile handset programs. They were J2ME programs, and there were a tremendous amount of limitations. In order to get back into the waters of mobile development, I recently bought an iPod Touch.

Boy, times have changed.

The iPhone OS provides quite a suite of libraries: sound, animation, data, OpenGL, and a rich UI library. You also get a whopping 8 GB of space on the base models of either the phone or touch. On the earlier Motorola J2ME handsets, we had to keep our app under 150K - a real challenge with a java app as feature rich as that one.

Of course, the major difference in device development for me is that my previous experience was in business applications. Most of my ideas for getting my feet wet on the iPhone OS are small games.

Frankly, I don't know a whole lot about this sort of thing. But it's only a matter of learning some new API's and remembering how to do some simple math transforms.

I think one of the reasons I'm drawn to this platform (as well as the Wii - one at a time, people) is that it has some potentially novel input methods. The first is the multi-touch screen, while not a new idea, widens the types of interactions one can have with the device. One can build games with innovative gesture controls which may become more intuitive then using the mouse and keyboard is now.

Second (and far more interesting), the tri-axis accelerometer provides a new level of gesture-based interaction. The device itself may be used as a steering wheel, it may be shaken to clear the screen, or it may be used to perform some other intuitive physical action.

I have a lot of ideas on paper, so now it's just a matter of getting those ideas in code.