Sunday, December 17, 2006

Recursion vs. Loop

Problem

Imagine that your application is meant to process an XML file. It is given a tag and needs to find a "special tag" that this tag might be nested in. This problem has several solutions. I tackled a similar problem some time ago and I will present you with some of the solutions that I considered.

While loop

private SpecialTag findSpecialTag()
{
Tag parent = this.getParentTag();
while (parent != null && !(parent instanceof SpecialTag))
{
parent = parent.getParentTag();
}
return (SpecialTag) parent;
}

Do-while loop

private SpecialTag findSpecialTag()
{
Tag parent = this;
do
{
parent = parent.getParentTag();
}
while (parent != null && !(parent instanceof SpecialTag));
return (SpecialTag) parent;
}

Recursion

private SpecialTag findSpecialTag()
{
return findSpecialTag(this.getParentTag());
}

private SpecialTag findSpecialTag(Tag tag)
{
if (tag == null || tag instanceof SpecialTag)
{
return (SpecialTag) tag;
}
else
{
return findSpecialTag(tag.getParentTag());
}
}

Solution

In my personal opinion, I find the while loop cleanest and simplest to understand. Do-while loop gets a bit messy with the condition at the end and recursion is probably the worst. I find recursion a bit hard to follow. It can also introduce an extra method just for its own sake (as in this example).

I do not have a strong opinion on this topic. If you like to program recursions, while loops, do-while loops, or for loops, it's fine by me. I certainly will not change your code, but if you ask me to write some code, it'd most likely be a while (or for) loop.

I use while and for loops interchangeably. The previous example with while loop would look like this with for loop:

private SpecialTag findSpecialTag()
{
Tag p = this.getParentTag();
for(; p != null && !(p instanceof SpecialTag); p = p.getParentTag());
return (SpecialTag) parent;
}

What is your preference?

Big Screen

Martin Fowler in his recent blog post about big screen emphasizes the importance of the workspace size, as in the size of the screen. He says that you cannot see much on a small screen and must switch between windows that overlap each other. I totally agree with him.

I was lucky enough to work at companies that could afford spending a little extra for the benefit of increased productivity. At Siemens I had 21" monitor, which was the biggest you could get at that time. Then at 3D3.com, I had two 17" monitors, which was again an excellent choice (one screen for programming, second screen for running the app/testing).

Fast forward to present, I work at Atlassian and the choices are great. If you work fulltime you can choose between a huge 24" widescreen monitor or TWO 20" widescreen monitors. When I got my 24" monitor, the pair programming just got better.

I use a laptop at home and I used laptops for work at MSC and Agreon. I never had any problems with my eyesight. Except the time when I worked for Agreon and used a Dell laptop. My eyesight got worse and I had to wear glasses at the end of the day as my eyes were strained. Now at Atlassian, with 24" monitor in front of me, I don't need to use my glasses any more. My vision is just fine. (It must've been the screen of that Dell laptop, IBMs and Toshibas are fine) If you use a laptop, at least ask for a stand so you raise the screen to your eye height. A simple bookstand will do as long as it is strong enough. Anyway, laptops are no good for pair programming.

So a big screen is good as you can display more valuable information on the screen. However, one screen still does not save you from application switching. If you are lucky enough to have two screens, you know what I am talking about. It's just a pleasure not to be forced to switch between apps as you can easily have one on one screen and the other on the second screen. A typical scenario is coding and running the (web) application, or coding and reading documentation.

At Atlassian we take turns in support. A developer from each team takes a fortnight turn to join the support team. We usually move to support area (so we can be close to the members of support team). We have a dedicated "support desk", which has all hardware necessary. The only piece missing is the computer that the developer brings along. The monitor on support desk is a 24" widescreen monitor.

When people move to support they bring their own desktop computers. I drag my monitor as well. It's the same 24" monitor and I always think that it'd be a waste to let it sit unused on my "dev" desk for two weeks. I hook it up and voilá! Two 24" widescreen monitors give me the greatest work space I can get (for now). I gotta tell you, it's really fantastic to have these two screens. You can be digging in the code on one screen and doing something else on the other screen. I usually have a virtual machine running on one and a browser in the other. No switching, no overlapping windows.

If you want to see me in action with two 24" monitors, have a look at these videos about Atlassian and my bosses Scott and Mike [mp4] or [wmv] (around 1 min 40 sec).

Monday, December 11, 2006

Project Automation

I just finished reading Pragmatic Project Automation (How to Build, Deploy and Monitor Java Applications) written by Mike Clark.

This book is very well written and an easy read. I picked it from the shelf in our Atlassian library two months ago. I read it mostly in the mornings and evenings on the train commuting to the office. I must say that even my trips take only 20 minutes, in those 20 minutes I managed to read just enough to get me started thinking about software processes that we have in place and how to improve them.

There were many things in the book that I was quite familiar with. I have already used Ant, written unit tests, created scripts that build new releases. Although I was familiar with many of these aspects of project automation, there were new ideas, other angles of application of the automated processes I've never thought about. I was quite interested in reading the chapters dedicated to installation, deployment and monitoring. I have faced the dilemmas of these stages of software development and I was quite curious to find out how the author solved them.

This book is truly inspirational. In a sense it is a cook book for project automation. It's easy to follow and proves useful to a novice as well as experienced developer.

I will put this book back on the shelf in our office. It's worth sharing and I will highly recommend reading it to anybody who wants to automate almost anything in software development.


Creative Commons License This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.