I recently completed some short term Java work where using git saved me quite a bit of work. The real savings came about because of the style of work that a distributed version control system allows you to follow: many small commits with easy branching and merging.

Background

Most of my work lately has been doing Java work remotely on my own machine. The projects use Ant scripts for the build process and Subversion for version control. I was used to having access to customer VPNs from my machine, using their servers for database access and version control.

All of this works pretty well for me and my customers, as it does for many developers today.

Recently, I picked up some short-term work to add undo and redo functionality to an existing Java Swing application. The project uses an older version of Rational ClearCase for version control, but circumstances did not allow them to use the web component of ClearCase. Also, company policy denies access to the VPN from non-company computers.

The work itself did not require a lot of interaction with the rest of the project team, so most of my work could still be done on my own if I could figure out a reasonable way to access and update ClearCase. I am perfectly willing to switch development tools or equipment if that works best for the customer, but since this was a short-term project, I knew I would be much more productive if I could keep my work style as unchanged as possible.

I had been using git for some personal projects, and thought it would be a good choice to support my work. I checked out the current project view from ClearCase on a company machine, copied the files to my machine, and setup a local git repository for it.

I was then able to use git to make many small commits as I worked on the project. When I was in the office, I would copy over changed files from my local machine to my ClearCase view and update the company repository with my changes. The process worked well and I was able to stay productive most of the time.

Git to the rescue

Early in the process, I introduced a small bug that had no effect in my development environment (a MacBook Pro), but ended up with some screen update problems when running under Windows XP. I did do sanity testing on the GUI on a Windows XP box while in the office, but did not notice anything odd until two weeks later.

By that time, it was not at all obvious what kind of change could have triggered the problem, and I spent a fair amount of time investigating double buffering, validation, and other Swing differences between the Java VM on OS X and Windows. After probably too much time on workarounds and checking Swing internals, I decided to give it a rest for a day or so and then use my git history to help me track down what change caused the problem.

When I came back to the problem, I started with a copy of the project directory and basically did a binary search through all the commits to find the one where the bad behavior started. It took a little over an hour to find the change that caused the problem — a bug that might have taken many more hours to find using any other method.

I am so pleased with the results that I will be using git and the style of many small, local commits, in every project I possibly can.

GIT FTW
— Doug

Thumbs up and highly recommended

It has been several years since I took the time to attend any kind of extended technical conference. Often when conferences would finish, I would wonder whether it was worth the investment of time. Even when I wasn’t sure if the answer was “yes”, I would either rationalize or convince myself that it was.

CodeMash was different, it was very much worth my time. I took the opportunity to meet people I would not normally have met, try some languages and techniques I have not tried before, and listen to sessions that I would not have heard otherwise. I was surrounded by people who were knowledgeable, yet still eager to share and learn new things. It was pretty cool.

Short version, if you are a developer who wants to grow, this conference is for you. Even if you do not directly use most of what you hear and learn, it will still have a positive influence on the work you do.

Precompiler Day

I attended the precompiler day, where extended sessions were offered (many conferences do this sort of early training day). It was good to be able to spend an entire morning doing one thing, then an entire afternoon something different.

Morning — Ruby 101

I have had Ruby on my list of interests for awhile now, but never quite taken the time to dive in. The whole day “Ruby 101” session caught my eye, and I was glad I attended during the morning. Jim Weirich and Joe O’Brien led us through a series of programming koans designed to gradually introduce us to key Ruby features and uses. I thought it was a very useful technique — we mostly proceeded at our own pace, but Jim and Joe were on call to answer some of the “why would Ruby do it this way” sorts of questions. Going back and forth between simple exercises that built on the previous ones, some Q&A with experts, and some rabbit trail type experiments was a great way to begin learning Ruby.

The session continued into the afternoon, but I chose to continue my koans on my own so I could attend something different that afternoon.

Afternoon — iPhone Development 101

Chris Adamson, one of the co-authors of the Pragmatic Programmer’s book on iPhone development, led this session. I had already started learning and writing some simple iPhone apps, so was familiar with the basics, but the session was still very useful for me.

Chris took us through the steps of creating a simple web browser as a native app, then through a series of refinements. Along the way, he explained and demonstrated several points of iPhone development that I had missed or where I had a very sketchy understanding. The most useful thing I gained from the session was a better understanding of who nib/xib files and custom classes work together. That by itself was worth the afternoon.

Keynotes and sessions

The themes I picked up from the week were the emphasis on agility and on getting out of your comfort zone.

I really enjoyed and learned from almost all the keynotes and sessions I attended, but I found the most value in those that encouraged me to think differently (and hopefully better) about who uses what I write, design, and testing.

I may write some followup entries on some individual sessions, but overall I was pleased with those I chose to attend. There were a couple I regretted not being able to attend, but by Friday afternoon my new idea tank was rapidly filling up.

Meeting people

One of the biggest benefits of any conference was in meeting people and actually talking to them. I’ve been to conferences or training events where the meet part happened, but real conversations lagged. CodeMash was great in that everyone I met, no matter where, was eager to talk and discuss a wide range of topics.

I loved the interaction with people outside my normal professional circle, and outside my areas of expertise. If for no other reason, I have already put CodeMash v2.0.1.0 on my schedule for next year (Jan 12-15, 2010). Hope to see you there.

I received my iPhone Developer Program activation code this morning, followed the on-line instructions and had no issues at all. My iPhone (Blackberry) and my iTouch (Raspberry) are now provisioned and useable for development and testing.

Double cool.

It has been just over two weeks since I applied to the developer program, so Monday evening I sent an e-mail using the ‘Contact Us’ page on the developer website asking about my status.

Early this morning I received this message from Apple:

Dear Registered iPhone Developer,

We noticed that you have not yet completed your enrollment in the iPhone Developer Program. Please log in using your Registered iPhone Developer Apple ID to continue with the enrollment process. If you have any questions, or need assistance in completing your enrollment, please contact us.

Best regards,

iPhone Developer Program

When I logged in, I was presented with the iPhone SDK click-through agreement which I am sure I clicked through before, but once I agreed (again), I was able to purchase the developer program through the on-line store.

I assume the message was a reply to my status e-mail, but I guess it could have been a very timely coincidence. Either way, I am just waiting for my purchase to arrive via e-mail so I can begin testing on my iPhone and iTouch.

Cool.

Over the last couple of months, I have been working on a set of ideas for a new iPhone application and have actively begun development today. As I begin narrowing down my thoughts on features, I will post more about the actual application.

My current goals:

• Focus on doing a few things very well,
• Link to existing resources where it clearly enhances the value of the application,
• Deliver a working application to a small set of people by February 2009,
• Have a marketable application by April 2009,
• See continued growth in customers each month of 2009.

I have spent a considerable amount of time the last two months reading books, articles, blogs, reviews, etc. to get a better understanding of what it takes to build a business around an iPhone application. I have not done enough to be comfortable (who has), but I have done enough to begin.

Today’s accomplishments:

• I successfully upgraded to the latest versions of all the tools,
• I downloaded what appears to be useful sample source code,
• I verified that my development environment works as expected,
• I applied for Apple’s developer program (thought I had done that months ago),
• I restarted my blogging with this post.

Next tasks:

• Figure out how how to best use GIT with xcode projects
• Setup a GIT server on a separate machine,
• Acquire one new skill with iPhone SDK
• Post about my progress.

Waiting on:

• An e-mail from Apple about the developer program