/Users/<user>/Library/Application Support/MobileSync/Backup

I then found the bkupextract.pl script that attempts to extract all of the sqlite3 databases from the backup files. I modified the script to also extract the plist, JPEG and PNG files and posted it to a gist. My Perl-Fu is weak, so no complaining about the quality of the code, but it found my photos.

NetBeans 6.7 was released on Monday and I dutifully downloaded it and played with it for a couple of days. The first thing that stuck me is that it looks good on OS X.

This is the best looking Swing application I have ever seen, and yet there are little inconsistencies that can become annoying. For example, you can drag a Cocoa window by clicking anywhere on the integrated toolbar, but in NetBeans you have to click on the title bar. This is a big issue since the toolbar in NetBeans looks like an integrated Cocoa toolbar, but it isn’t. Also, clicking on a file in the explorer on the left shows the file’s members in the Navigator, but does not open the file. You have to double click to actually open a file.

All of this would be forgivable if NetBeans offered better functionality than my current toolset. The whole idea behind IDEs is that it is more convenient to have all of the functionality you need bundled into one application than to use several separate apps. However, getting to some of the functionality in NetBeans requires digging around in the UI, and some stuff is just broken compared to the non-IDE equivalent. For example, when running Ruby tests or the Rails server via script/server from within NetBeans, the ASCII color codes are not properly interpreted making the output unreadable.

So far, I have found NetBeans less convenient than the combination of TextMate, GitX, Terminal and Sequel Pro. Part of this is due to the fact that I have a lot of time invested in my current development stack. The latest version of NetBeans shows enough promise, and I am enough of a tools geek, that I am going to tough it out a few more days. That having been said, I am having a hard time seeing the value in an IDE when the components of a non-integrated development tool stack are of such high quality.

After a little experimentation I was able to set things up in a way that solves both of these issues. Some of the details are a bit specific to Mac OS X, but this method could easily be adapted to any UNIX-like environment. The method involves symlinks so Windows users are probably out of luck.

I decided to install all Erlang related stuff under ~/Library/Erlang to generally conform to OS X conventions. While I chose to install under my home directory, you could also put it in /Library with minimal changes to the process. In the Erlang directory I have two subdirectories: Releases and Site. The general idea is that each Erlang release will live in a subdirectory of Releases named after the Erlang release (i.e., “R13B01”) while 3rd party code goes in Site. Finally, I create a symlink named Current in the Erlang directory and link it to the release that I am currently using.

The final setup looks like this:

Erlang
  |-- Current -> Releases/R13B01
  |-- Releases
  |     |-- R12B5
  |     `-- R13B01
  |-- Site
  |     |-- erlydtl-0.5.2.2
  |     |-- mochiweb-0.97.1
  |     |-- nitrogen-0.2.0
  |     `-- webmachine-1.3
  `-- setup.sh

The setup.sh file is sourced in my .bash_profile and it sets up the shell environment:

export ERL_ROOT=$HOME/Library/Erlang/Current
export ERL_LIBS=$HOME/Library/Erlang/Site
export MANPATH=$ERL_ROOT/man:$MANPATH
export PATH=$ERL_ROOT/bin:$PATH

With this setup, all of the libraries in Site are in the Erlang code path and the current Erlang VM is in the shell’s path. I can switch Erlang VMs by changing the symlink to point to a different distribution, but everything else remains the same.

Building Erlang from source is simple. After extracting the source distribution:

$ ./configure --prefix=$HOME/Library/Erlang/Releases/R13B01
$ make
$ make install

You will want to replace the ‘R13B01’ with the name of the distribution you are building.

This morning I was looking over my Today list in Things and I realized that there were two tasks on my mind but not in the system. Safari bookmarks aren’t synching to my laptop properly and I have a memory upgrade for my daughter’s iMac that needs to be installed. I initially resisted adding those tasks to Things with the justification that they are little things and I would take care of them this evening. Of course, I have had the memory upgrade for over a week now and it has yet to be installed.

These “little things” were becoming a source of stress because every time I would walk past the iMac or log onto the laptop I would think: “Oh, yeah. I need to do something about this…but not right now.” And yet, I resisted adding them to my list in Things. Once I became aware of this I thought of several tasks that I had been holding in my head. Getting those tasks into things relieved some of the stress and gave me more confidence that they would eventually be done.

Now all I have to do is become more disciplined about doing the things on my list as opposed to just moving things around.

If you are interested you can download a binary or check out the source on Github.

Download: QLMarkdown-1.1.zip
Source: http://github.com/toland/qlmarkdown

One of the points that I’ve been trying to make since I’ve gotten back in to the languages space is that a lot of what is happening in languages now is unpausing the nuclear winter that Java imposed on the programming language space. If you haven’t been following this space for a while, you’d believe that all this dynamic language stuff was invented in the last 5 or 10 years or so.

— Ted Leung

(Via James Robertson.)

Be sure to checkout GitHub’s Guides, including the list of cool and unusual Git techniques. Finally, the aforementioned Ruby Inside post also pointed out this Ruby and Git roundup at InfoQ.

Rails will be hosted on the upcoming Github site, which looks promising. Of course, Gitorious is a similar service that has been around for a little while and repo.or.cz has been around for longer still. The cool thing about these sites is that they can provide advanced version control hosting due to Git’s simplicity. Github, in particular, has some impressive features.

Many people who are used to centralized version control systems don’t immediately see the value in a distributed system like Git. I think that moving from Subversion to Git is like moving from Java to Ruby. If you write Ruby code like you write Java code then you are likely to be disappointed. In order to get the most from Ruby you have to change the way you think about software development and latch on to concepts like duck typing and metaprogramming. The same is true of Git. If you use Git like you used Subversion, it is going to be a disappointment. Once you are comfortable with the distributed SCM model, and begin to take advantage of features like cheap local branches, then you will be much happier with Git.

Tim Burks says that with distributed version control systems like Git “‘the world is flat’ for programmers”:

All participants have the freedom to make whatever innovations they want and the opportunity to promote their changes to the public. Because all repositories are equally functional, the project leader has the ability to act as Brooks’ chief architect, pulling and filtering changes back into his or her personally-branded version.

This is how Linux kernel development happens and it is surprisingly liberating. Development tools tend to be quirky and we accept the little oddities as the cost of doing business. We become insensitive to the quirkiness and accept it after a fashion. These little nuisances wear grooves in our daily development routine and it can be hard to escape those grooves.

Ryan Tomayko describes a thorny version control problem and how Git solves it handily. The point isn’t that Git has Feature X which other systems lack, it is that Git does not impose unnecessary cruft on your workflow:

The thing about Git is that it’s oddly liberal with how and when you use it. Version control systems have traditionally required a lot of up-front planning followed by constant interaction to get changes to the right place at the right time and in the right order. And woe unto thee if a rule is broken somewhere along the way, or you change your mind about something, or you just want to fix this one thing real quick before having to commit all the other crap in your working copy.

It is different, but sometimes different is good. It is also frustrating and the interface can be a bit odd at times. But the interface is getting better and the frustration subsides as you begin to “get it.” All in all, now seems to be a good time to get comfortable with Git.

(Click the image to see a larger version)