Friday, July 29, 2005

Remote pair programming on TopCoder

Last night Tom and I tried our second match on TopCoder using Remote Pair Programming. (Our first match we had some technical difficulties that limited our success.)

The tools we used were:
  • Eclipse 3.1 for our Java IDE.
  • Microsoft Remote Assistant for sharing my desktop with Tom.
  • Skype for voice over IP.
  • Microsoft Messenger to launch Remote Assistant and text chat.
  • Firefox browser.
I have a 3MB/384k DSL connection which handled the sharing of my desktop in 1280x1024 and voice over IP on Skype very well. Only once Tom complained that his refresh got behind his typing when he was driving. An earlier attempt where we used VNC and a 1.5MB/256k DSL connection at the host had more refresh problems, but was generally workable.

The contest went well. TopCoder provides three problems of increasing difficulty worth 250, 500 and 1000 points max (points decrease over time). The problem set is listed on We jumped into the 500 point problem first called WordCompositionGame. As a pair, Tom was immediately thinking ahead about how to implement the next steps as I coded the steps that we knew. This eliminated some hesitations and pauses that might have slowed down either of us alone.

On the 1000 point problem, KthElement we also quickly hacked out the solution. Our code was more brute force than elegant because we were racing the clock. Our JUnit tests failed showing we had the right sequence, just not the correct KthElement. I immediately guessed we had an "index off by one" bug. So rather than puzzling out the bug, I simply added one to the index and re-ran the unit test... it passed!!! (Thanks to Tom for creating a program that converts the TopCoder problem statement into Unit Tests). We submitted the code.

Next we opened the 250 problem with lots of time left. While reading the problem statement, something bugged us about our solution to the 1000point KthElement problem. KthElement ran a long time for large numbers. Tom checked the rules and realized there is a 8 second limit on runtime. So we reopened KthElement. This cost us more points because the clock was now ticking down points on the 250 problem, and reopened the countdown on KthElement.

A quick look at the data in the KthElement unit tests made us realize the sequences started to repeat. So the solution was to collect the sequence until it repeats and calculate the KthElement from the repeating pattern. This took a bit of effort, but saved us from total failure. At one point in this, Tom and I disagreed about how to find the KthElement from the repeating pattern. Tom started to go off on his own solution (he has two monitors at home), while I was hacking out my solution. Fortunately this split didn't last more than a minute or two. I was able to draw Tom back to look at my solution because I was so close to getting it, but needed another pair of eyes. Together we got the pattern identified and the calculation for the Kth element correct.

Finally back to the 250 problem SequenceOfNumbers. It was a real easy one, but we only had 9 min left on the clock. We got rushed and made some mistakes in our approach. Thankfully as a pair we quickly saw when things were off track and got back together. At one point we went off in a tangent trying to make an elegant solution. It wasn't panning out, so we trashed it and did a quick brute force. Adrenaline was pumping as we compiled and ran unit tests with less than one minute remaining. It pass the tests and we got everything submitted with ony 34 sec left in the contest.

Final score... all our solutions worked and scored. We could have scored higher on KthElement and SequenceOfNumbers if we had looked at the unit tests and realized KthElement involved a repeating pattern. Having both problems opened at the same time was not good.

Remote Pair Programming worked great! We performed as well as we would have sitting right next to each other. In fact we probably performed better being remote because it was easier to swap control since we each had our own mouse and keyboard.

(Yes, we know TopCoder considers collaboration as cheating. Sorry. We were just trying to experiment with Pair Programming and enjoy the contest. We assume this is ok during a *not for money* match. It would be nice if TopCoder had a division for Pair Programmers.)

[Aug 11, 2005. I've posted a follow up article.]

Learning Iterated Development from the Game Industry

Julian Gold published a great article "Object-Oriented Game Development: Iterative Development Techniques" on Most Agile developers will recognize the basic iterative development techniques. Julian adds the concept of defining features into three catagories: Core, Required, and Desired. (Most projects I've worked we just identified features as either Required or Desired.) You will have to read the article to understand the difference between Core and Required.

Julian also divides up the object development into well defined levels of quality: null, base, nominal and optimal. I really like the idea of defining the quality of object develop along a well defined scale. This quailty scale is then used to divide up the development into prioritized iterations and evolve the objects through the project's life.

Thursday, July 21, 2005

Reflector == Cool Tool

[image of Reflector]

A co-worker introduced me to this little utility for .Net. Reflector is a nice assembly browser that includes a disassembler, call graph and callee graphs. Very nice! I can point it at my assemblies. Then with a few clicks I can drill down into disassembled source for system libraries and third-party libraries that I am calling. Reflector also has some plugins for DB browsing and other stuff.

Reflector is available from

BORG everywhere

I wonder how many things in the I.T. world are named "BORG". On my previous job we had a project named BORG. On my current job, we've also got a project named "BORG". I was just reading the tutorial doc for DbEncrypt here. Guess what, the DB in the tutorial is also "BORG". :)

I wonder, after the Firefly movie will I start seeing things named Serenity?

Wednesday, July 20, 2005

Byecycle looks like a cool idea. The homepage has a wink demo of the plugin (very nice). Byecycle will display a dependency graph of you modules and highlight dependency cycles (plugin for Eclipse). This makes it easy to see problems in design. One realy cool features of byecycle is the way performs automatic layout. The layout engine will keep shifting the diagram as it finds better layouts. Also, check out the people behind this plugin. Some really smart folks.

Yes, a code metrics tool could provide similar information. But the cool graph display makes this a lot more fun. Plus the layout helps you understand the dependencies. Hopefully, if you system is well designed the layout would show your architecture layers since it tries to make the arrows go top to bottom.

Tuesday, July 19, 2005

VS.Net customization

After my eyes got tired from looking at the screen too long, I found a macro that will let me easily change the font size in Visual Studio .Net. The macro is here: Zooming your code in Visual Studio .NET

I wish VS.Net provided some styles or themes with different color schemes. The plain white gets old. I looked at modifying the colors. But the settings were too detailed. It would take hours or days to get a good looking set of colors and fonts setup.

Friday, July 15, 2005

Remote Collaboration

The NetBeans folks have a very interesting collab module. It was designed to assist remote peer-review of code. The model is really cool. You take a file and share it with others. The shared file goes into a "sandbox" so your original is not modified. Everyone can collaborate in the sandbox. Then the sondbox file changes can be merged back into the original file. This could even help assist remote pair-programming (something I've been experimenting with).

There is an article about it here...

The collab project is here ... You can see a demo of it. Just look under "Getting Started" for the "See" link.

If only it worked in IntelliJ and Eclipse.