### Archives For Programming

At a previous job I was given the mission of constructing a development task that we could let prospective team members complete. Having been on the receiving end of several of these tasks, I had a rough idea of what to include and what to avoid. Basically, I was looking for the smallest possible task that would still give a good glimpse into the developer’s way of constructing code and solving problems.

So I went with FizzBuzz. Or rather, a variation on FizzBuzz. But first, the basic idea of FizzBuzz is to write a program that prints out numbers from 1 to 100. For multiples of three, the number should be replaced by “Fizz”, for multiples of five, the number should be replaced by “Buzz” and for multiples of both three and five, write “FizzBuzz”.

```1
2
Fizz
4
Buzz
(etc)```

Usually whenever someone writes a blog post about FizzBuzz, the comments fill up with examples of how to do it. This is all very well, but my favorite implementation has to be the quite fantastic FizzBuzz Enterprise project on GitHub.

```public static boolean numberIsMultipleOfAnotherNumber(int nFirstNumber, int nSecondNumber) {
try{
final int nDivideFirstIntegerBySecondIntegerResult =
(IntegerDivider.divide(nFirstNumber, nSecondNumber));
final int nMultiplyDivisionResultBySecondIntegerResult =
nDivideFirstIntegerBySecondIntegerResult * nSecondNumber;
if (IntegerForEqualityComparator.areTwoIntegersEqual(nMultiplyDivisionResultBySecondIntegerResult, nFirstNumber)) {
return true;
} else {
return false;
}
} catch( ArithmeticException ae ){
return false;
}
}
```

Pure enterprise at its best!

Anyway, the core of our task was doing FizzBuzz as a C# console application. The added twist was that there should be unit tests that fully covered the logic of which text to print. As an aside we mentioned that it was not necessary to test the console client portion of the code. This was basically inserted to see whether the applicant would leave the 1 to 100 loop untested. Most did, and in my evaluation I did not hold it against them – but it was interesting to see who went the extra mile to make the loop-logic testable as well.

During my time of evaluting solutions I don’t think that we ever actually got one that failed the basic “1, 2, Fizz, 4, Buzz” part of the task. We did, however, get some less-than-satisfactory ways of unit testing parts of the logic. For instance, one candidate only included a single unit test that checked that the modulo operator returned the expected result. Sorry, you fail the test!

It was also possible to fail by writing too many tests, but this was generally preferable to writing too few. A worse way to fail was to write convoluted code with weird flow control statements, etc. The basic FizzBuzz logic isn’t that complicated, so it should be possible to express it in a succint way.

Now, this test was just a small part of the recruitment process, and other criteria weighed far heavier, but sometimes terrible performance on the FizzBuzz test made us skip a candidate. This may very well mean that we missed out on good people, since the test is far from a perfect indicator of future performance. And unfortunately I never had the chance to discuss the solutions with the developers, talking about how they had approached the problem, how they reasoned when writing the code, and so forth. But overall I think it worked out pretty well, and since no two solutions looked the same, it was always interesting to investigate, evaluate and learn.

Finally, our task did not use the words “fizz” and “buzz”, thereby decreasing the potential for finding a solution using Google. No cheating!

I have a few private repositories at GitHub, and I was looking to set up a continuous integration/build solution for one of them. If it had been a public repository I would probably have looked at Travis CI or AppVeyor, which are free for open source projects. However, they require you to fork out a bit of cash for private repos. I usually don’t mind paying for software, especially not good software, but since I already have a server running at home, I figured that TeamCity could do the job nicely – it is free if you have less than 20 build configurations, it has a lot of great features and I am quite familiar with it after using it at work for the past year.

So the basic need I had was for TeamCity to be able to access and fetch the code for a private GitHub repo. Now, there are a few different ways of setting up access to a private GitHub repo, and having investigated the different available options I settled on using what GitHub calls a deploy key. In short, this is an SSH key that gives full access to the repository.

This guide will assume that you have a repository in GitHub, and that you have a TeamCity project set up.

## Generating the SSH key

So let’s start by creating the SSH key that we will use. The simplest way I could think of was to use the PuTTYgen tool. If you don’t have it, you can find it a the PuTTY download page, or – if you are running Windows – by installing PuTTY through Chocolatey.

Once you’ve generated the key, copy all the text from the “Public key for pasting into OpenSSH authorized_keys file” onto the clipboard. This will go into your GitHub project settings. We’ll need the private part of the key later, so save it to disk by clicking on “Save private key”.

## Setting up your GitHub project

Next, go to the Settings page for your GitHub repository. In the menu on the left, you’ll find the Deploy Keys entry. Go there and click on the “Add deploy key” button. Enter a title for your deploy key and then paste the contents of your clipboard into the “Key” part of the form.

Click on “Add key”. There, you’ve just added a deploy key to your project in GitHub. Now for TeamCity…

## Setting up TeamCity

TeamCity will be using the private part of the SSH key, the one that we saved to disk earlier on. First, go to your project settings page. Go to the SSH Keys menu item, and click on “Upload SSH key”. You can give the key a title, or just select the file and use the filename.

Click “Save” and it will be added to your project. However, there’s one more thing you have to do.

Whether you’ve already set up the VCS root for the TeamCity project or not, what you need to configure in the VCS root is under the Authentication Settings section. For Authentication method, choose “Uploaded Key”. The Username must be set to “git”, and in the Uploaded Key dropdown you simply select the SSH key that you just uploaded.

We’re done! To try it out, scroll to the bottom and click on “Test connection”. Hopefully, you’ll see this:

Success!

If not, make sure to double-check all the settings. Also, bear in mind that the SSH key allows full access to the GitHub repository, so make sure that you keep it in a safe place.

TeamCity can now get the source code from GitHub for your project. Now there’s only the matter of writing the software that TeamCity will continuously integrate – and perhaps deploy – for you! But that’s the easy part, right?

Making small commits often is usually preferable to making massive once-a-day commits – especially if you want someone to review your changes. For me, my stress levels rise with the number of files that have been touched since the last commit. When commits grow too big I’ve been known to stash the code, and redo the changes, breaking up what would have been a large commit into a number of smaller commits. Yes, sometimes large commits are inevitable. They happen. Things could be worse.

By worse, I mean like the two types of commits that have been bothering me on occasion lately.

The first is the one where the commit strays off topic, delving into multiple features at once. For example, you find a commit with the following description:

```Added ATOM parsing to RssFeedReader
Validation of ExpirationDate for user account
```

OK, yeah, those two changes seem totally related. Or maybe they should have been two separate commits? Imagine that we wanted to merge one of these changes to another branch. The Single Responsibility Principle probably applies to commits as well.

However, there is another type that actually bothers me more: The overzealous drive-by code cleaning.

Imagine that you’re looking at the history of the UserAccount.cs file. One of the changes has the following commit message:

```Added ATOM parsing to RssFeedReader
```

Why would RSS parsing affect the UserAccount class? You’re sitting there, scratching your head, wondering why a completely unrelated file has been touched. Upon closer inspection you discover what changed. One line. One unused using statement was removed.

Indeed, that is quite unrelated to adding ATOM parsing to an RSS feed reader. So not only has the history of the UserAccount.cs file been distorted, it was done for pretty much no business value whatsoever.

Now, maybe I’m nitpicking. By all means, clean up the code. But try to keep each commit focused and coherent, instead of going off fixing “problems” in unrelated files. Small fixes like adjusting spacing and removing unused using statements should really only be done if you already had another reason to fiddle with the file. Alternatively, do all the tiny fixes together in one go without changing anything else. Then you can just check the changes in with a suitable comment like “Removing unused using statements”. Accurate, succint and to the point. Clean code. Even cleaner source control history.

I have always been a big fan of computer books. However, it is usually not books about a specific technology or tool that I find the most interesting, but books about the process and psychology of development.

In September last year I spent a few weeks on the West Coast of the USA, and one of the highlights was a visit to Powell’s Books in Portland, Oregon. There I had the pleasure of getting my hands on a first edition copy of Gerald Weinberg‘s excellent “The Psychology of Computer Programming” from 1971. I have owned the Silver Anniversary edition from 1996 for over ten years, but getting hold of a first edition was too good an opportunity to let go to waste.

This is the book that first featured the term “egoless programming”, the concept of separating the coder from the code and the notion that having your code criticised does not mean that you are being criticised as a person. The book contains a lot of humorous anecdotes that bring the lessons to life, such as the one regarding “egoless programming” where the programmer Bill G. (yes, an amusing coincidence) feels that his code is ready for review, and asks his colleague Marilyn B. to review it.

In this particular instance, Bill had been having one of his “bad programming days.” As Marilyn worked and worked over the code – as she found one error after another – he became more and more amused, rather than more and more defensive as he might have done had he been trained as so many of our programmers are. Finally, he emerged from their conference announcing to the world the startling fact that Marilyn had been able to find seventeen bugs in only thirteen statements. He insisted on showing everyone who would listen how this had been possible. In fact, since the very exercise had proved to him that this was not his day for coding, he simply spent the rest of the day telling and retelling the episode in all its hilarious details.

Another thing about the book that stands out for me is it’s role as a historical document of how development was done “back in the days”, way before my time. The days of Fortran, COBOL, interactive terminals, keypunch operators, print-outs, etc. In the Silver Anniversary edition which features comments on each chapter 25 years later, Weinberg states his envy of current – i.e. 1996 – tools and how they make him drool (even using the term “Drool Tools” jokingly). Today, another 17 years later, I find myself drooling over today’s tools compared to what we had in 1996. I don’t even want to think about 1971.

A previous owner has written his name inside the front cover, I believe it says Jim Campbell. And as a bonus, it also included a “While you were out” card from OSECO, 3505 Elston Ave, Chicago. This is itself is a fascinating piece of history, I suppose that a previous owner of the book used it as a bookmark. Perhaps it was Jim.

I look forward to a Gold Edition of this book in 2021!

Back in the good old days when I started doing unit testing and test-driven development, the way I ran tests was to start the NUnit Windows application, run the tests, wait for them all to go through and examine the result. Not exactly slow, but there is some friction, and a hint of context switching as a new window appears right on top of Visual Studio.

Earlier this year I purchased ReSharper from Jetbrains. Using their test-runner certainly reduced the friction compared to NUnit, but there were still the explicit steps of writing code, starting the unit tests, etc.

And then I discovered NCrunch, and all the friction was gone.

So what is NCrunch? To quote their website:

NCrunch is an automated concurrent testing tool for Visual Studio .NET.

It intelligently runs automated tests so that you don’t have to, and gives you a huge amount of useful information about your tested code, such as code coverage and performance metrics, inline in your IDE while you type.

What this means in practice is that NCrunch runs your unit tests as soon as you edit your code. I cannot stress enough what a game-changer this is. The feedback loop is cut down to practically nothing, and there is no need to stop and wait, or launch an external program. It’s just there and does its thing, and you can keep on writing code instead of continually disrupting your flow.

Once you start using NCrunch (or a similar tool, there are others, of course), it is very hard to go back to not having it. Like when you start using ReSharper and then use Visual Studio without it, it feels like something is missing.

The Single responsibility principle states that each class should have a single reason to change. There are certainly many ways to deduce if a class has too many responsibilities, most of which actually require you to use your brain! However, a quick-and-dirty way to establish if a class has too many responsibilities is simply to look at the list of using statements at the top of the file (imports in Java and Visual Basic.NET). If you open the source file in your IDE of choice and the list of usings/imports fills your entire view, the class is likely to have a lot of reasons to change.

Here is what the list of using-directives in one of our classes looked like a few months ago:

```using System;
using System.Collections;
using System.Collections.Generic;
using System.Data;
using System.IO;
using System.Linq;
using System.Net;
using System.Net.Mail;
using System.Net.Mime;
using System.Text;
using System.Text.RegularExpressions;
```

The likelihood that a class like this was developed using test-driven development seems slim (and indeed, it was not).

I don’t really believe that we can set a strict “maximum” number of using directives to allow, but probably anything more than six or seven should serve as an indication that perhaps the class in question could do with some refactoring. Perhaps we can use the number of usings/imports as a metric describing code complexity, albeit a very blunt one.