Build Your Own Sandbox Application

Sandboxes are fun. A simple box full of sand, a bucket, and a shovel somehow opens the imagination like nothing else. You can build anything you want, keep it around for a while if you like it, add to it, subtract from it, or crush it in Godzilla like fashion if you so choose. You can experiment with your creation in any way imaginable, without consequence. Creating things in such a carefree environment can be refreshing, and rewarding.

I think that it is a great idea for developers to have such an environment for themselves where they can try out new technologies, techniques, or processes. Setting up a sandbox now-a-days is pretty easy. Machines are cheap, or free if you’re not picky and keep your eyes and ears open. That 4 year old PC that your cousin is throwing away because he got a brand new Dell for Christmas will fit the bill just fine. Linux is free, runs great on older computers, and has the power and flexibility to host virtually any application. Sign up for a free DNS service such as DynDNS and poof, you’ve got yourself a little server that you can reach over the Internet. My sandbox is a dusty old dual Pentium III with 512 MB of RAM, which is running Ubuntu Linux. It fits the bill quite nicely if you ask me.

But a sandbox is only half the equation. For developers, we need an application that we can play with in the sandbox. Something we can poke and prod. A sandbox application so to speak. There are several reasons why you many want to create a sandbox application.

Platform for playing with new technologies

Perhaps the biggest reason for creating and maintaining your own sandbox application is that it can serve as a platform for trying out new technologies. Doing this at work can be tough. Your boss or client may not be thrilled to hear that you completely re-wrote part of the application to use the bleeding edge release of some hot new framework because you “thought it was cool”. But, there’s nothing stopping you from doing it with your own application. Even if you rely heavily on your application, there’s no reason why you can’t fork your code, and give the new technology a try on a separate branch. If it works out you can merge the code into the main branch, and if not you can always abandon the changes. Now, this approach will only work if you have your application under source control (which you should). If you don’t mind giving the world access to your code, GitHub will host your code for free. Otherwise, it’s very easy to setup your own source control system in your sandbox.

Material to blog about

Trying out new technologies, techniques, or processes can also give you plenty of material to blog about. If the technology/technique/process you are tinkering with is hot, it is very likely that many people will be interested in reading about your experience. If you blog frequently about topics that people are interested in, you’ll steadily increase readership. This could be very good for your career, as well known programmers generally don’t have a hard time finding work. Work usually finds them.

Create something that you will use

What’s the point in going through all of this trouble to create something if you never use it? I’ve created a few applications that I use on a regular basis. Not only did these applications address some need that I was currently facing, but having a sandbox application that you actually use means that you will be more likely to maintain and enhance it.

Looks great on a resume

Employers love to hire people who show an interest in their field outside of work. I’ve found that people passionate about their field are usually better at their jobs than those who show up at 9, work on the same ol’ stuff for 8 hours, and go home. Having a sandbox application shows people that you love what you do so much that you have dedicated time outside of work to create something that you care about. This especially holds true if you’ve put serious thought into your application, and are excited to show it off to anybody who asks to see it.

Release it, and potentially help others

One of my colleagues once said,

Your parents lied to you. You are not special. There’s millions of people out there just like you.

He wasn’t trying to be mean, this time :) He was simply pointing out that you are not alone. If you are facing a problem, odds are there are hundreds or thousands (or more) of people out there who are facing that same problem. Releasing your application could be helping all of these people. Perhaps it would help them so much that they would be willing to pay for it. Wouldn’t that be nice?

Open source your application

Open sourcing your application can be great for several reasons. Perhaps you’ve just finished migrating your application to the latest version some framework. Not only can you blog about your experience, but you can share the code with others so that they can see exactly how you did it. This could potentially help others looking to migrate their applications to the same framework. You could get feedback from the community about something you could be doing better, and learn something new. People looking at your code could spot a bug, giving you the opportunity to fix it before it affects you (especially if you use your application). Some employers ask to see source code samples as part of the interview process. What sort of reaction do you think you would get if you immediately spit out several repositories that you owned on GitHub for the prospective employer to browse at their leisure? I’m not sure about you, but I’d be pretty impressed.

However, there is a potential drawback in releasing your code to the world. Ironically, it’s the same as one of the benefits. The world can see your code. This can be a bad thing if your code is full of bugs, or sloppy. So if you plan on releasing your code, take the extra care necessary to ensure that the code reflects your best effort. Your code, and you as a developer, will benefit from the extra TLC.

The next big thing

You never know which crazy, off the wall idea will turn into the next big thing. Who would of thought that there was a real need for an application that lets you tell the world what you’re doing right now. If your idea for a sandbox application turns into something with real business value, then you never know where it will end up. Large companies will often spend big bucks to buy great ideas. I’d imagine it would be pretty cool to be on the receiving end of one of those deals.

Summary

Creating a sandbox, and a sandbox application is something that every serious developer should do. If nothing more, it will give you a place to tinker with new technologies and grow as a developer. There is little to no cost to set it up, and your imagination is the only limit.

Why Code Coverage Alone Doesn’t Mean Squat

Agile software development is all the rage these days. One of Agile’s cornerstones is the concept of test driven development (TDD). With TDD, you write the test first, and write only enough code to make the test pass. You then repeat this process until all functionality has been implemented, and all tests pass. TDD leads to more modular, more flexible, and better designed code. It also gives you, by the mere nature of the process, a unit test suite that executes 100% of the code. This can be a very nice thing to have.

However, like most things in life, people often focus on the destination, and pay little attention to the journey required to get there. We as human beings are always looking for short cuts. Some software managers see 100% code coverage as a must have, not really caring how that goal is achieved. But it is the journey to 100% code coverage that provides the benefits that most associate with simply having 100% code coverage. Without taking the correct roads, you can easily create a unit test suite that exercises 100% of your code base, and still end up with a buggy, brittle, and poorly designed code base.

100% code coverage does not mean that your code is bug free. It doesn’t even mean that your code is being properly tested. Let me walk through a very simple example.

I’ve created a class, MathHelper that I want to test. MathHelper has one method, average, that takes a List of Integers.

/**
 * Helper for some simple math operations.
 */
public class MathHelper {

    /**
     * Average a list of integers.
     * 
     * @param integerList The list of integers to average.
     * @return The average of the integers.
     */
    public float average(List<Integer> integerList) {
        ...
    }
}

Caving into managerial pressure to get 100% code coverage, we quickly whip up a test for this class. Abracadabra, and poof! 100% code coverage!

coverage-green-bar

So, we’re done. 100% code coverage means our class is adequately tested and bug free. Right? Wrong!

Let’s take a look the the test suite we put together to reach that goal of 100% code coverage.

public class MathHelperTest {

    private MathHelper _testMe;

    @Before
    public void setup() {
        _testMe = new MathHelper();
    }

    @Test
    public void poor_example_of_a_test() {
        List<Integer> nums = Arrays.asList(2, 4, 6, 8);
        _testMe.average(nums);
    }
}

Ugh! What are we really testing here? Not much at all. poor_example_of_a_test is simply verifying that the call to average doesn’t throw an exception. That’s not much of a test at all. Now, this may seem like a contrived example, but I assure you it is not. I have seen several tests like this testing production code, and I assume that you probably have too.

So, let’s fix this test by actually adding a test!

    @Test
    public void a_better_example_of_a_test() {
        List<Integer> nums = Arrays.asList(2, 4, 6, 8);
        _testMe.average(nums);
        assertEquals(5.0, result);
    }

Let’s run it, and see what we get.

java.lang.AssertionError: expected:<5.0> but was:<2.0>

Well, that’s certainly not good. How could the average of 2, 4, 6, and 8 be 2? Let’s take a look at the method under test.

    public float average(List<Integer> integerList) {
        long sum = 0;
        for (int i = 0; i < integerList.size() - 1; i++) {
            sum += integerList.get(i);
        }
        return sum / integerList.size() - 1;
    }

Ok, there’s the bug. We’re not iterating over the full list of integers that we have been passed. Let’s fix it.

    public float average(List<Integer> integerList) {
        long sum = 0;
        for (Integer i : integerList) {
            sum += i;
        }
        return sum / integerList.size();
    }

We run the test once again, and very that our test now passes. That’s better. But, let’s take a step back for a second. We had a method with unit tests exercising 100% of the code that still contained this very critical, very basic error.

With this bug now fixed, we commit the code to source control, and push a patch to production. All is fine and dandy until we start getting hammered with bug reports describing NullPointerExceptions and ArithmeticExceptions being thrown from our method. Taking another look at the code above, we realize that we have not done any validation of the input parameter to our method. If the integerList is null, the for loop will throw a NullPointerException when it tries to iterate over the list. If the integerList is an empty list, we will end up trying to divide by 0, giving us an ArithmeticException.

First, let’s write some tests that expose these problems. The average method should probably throw an IllegalArgumentException if the argument is invalid, so let’s write our tests to expect that.

    @Test(expected=IllegalArgumentException.class)
    public void test_average_with_an_empty_list() {
        _testMe.average(new ArrayList<Integer>());
    }
    
    @Test(expected=IllegalArgumentException.class)
    public void test_average_with_a_null_list() {
        _testMe.average(null);
    }

We first verify that the new tests fail with the expected NullPointerException and ArithmeticException. Now, let’s fix the method.

    public float average(List<Integer> integerList) 
            throws IllegalArgumentException {
        
        if (integerList == null || integerList.isEmpty()) {
            throw new IllegalArgumentException(
                "integerList must contain at least one integer");
        }
        
        long sum = 0;
        for (Integer i : integerList) {
            sum += i;
        }
        return sum / integerList.size();
    }

We run the tests again, and verify everything now passes. So, there wasn’t just one bug that slipped in, but three! And, all in code that had 100% code coverage!

As I said in the beginning of the post, having a test suite that exercises 100% of your code can be a very valuable thing. If achieved using TDD, you will see many or all of the benefits I list at the top of the post. Having a solid test suite also shields you from introducing regressions into your code base, letting you find and fix bugs earlier in the development cycle. However, it is very important to remember that the goal is not to have 100% coverage, but to have complete and comprehensive unit tests. If your tests aren’t really testing anything, or the right thing, then they become virtually useless.

Code coverage tools are great for highlighting areas of your code that you are neglecting in your unit testing. However, they should not be used to determine when you are done writing unit tests for your code.

Moved Rails Apps to GitHub

I’ve spent some time over the past couple of months cleaning up the Rails apps I’ve written with the goal of making them available for download on this site. I wrapped that up last week with the release of Addressbook. However, I soon realized that making the code available on this site was not ideal, and it would be much better if I made the code available via some code hosting site, like Sourceforge or GitHub. This gives the projects a little more visibility, allows for easier contributions to the projects, and simply provides a better home for the code. So, I spent the past few days making Diners Club, Addressbook, and Karate Journal available on GitHub. Please check the project pages on this site for links to the GitHub repositories.

Choosing GitHub was fairly easy. I’ve been wanting to learn Git for a while now, GitHub has all of the features I needed (plus some nice-to-haves), and it seemed pretty straight forward to use. So far so good!

I did however have to do some additional cleanup before the move to GitHub. Previously, I had a bash script that I ran that would export the code from my local Subversion repository, and wipe out any user names, passwords, or other configuration that I didn’t want to publish with the code. The script would then tar and zip up the code, and push it to the site. This wouldn’t fly with GitHub, since everybody would be able to see the code in the repository. So, some work was needed to provide template config files (database.yml.template for example) for people to specify their own configuration, and I removed the original files from source control.

All things considered, I’m very happy with the move, and wish I’d done it sooner. I think from now on, I’ll be using GitHub from the start with new projects.

Merry Christmas everybody!

Addressbook Webapp Has Been Released

Yay for me! I set a personal goal to have the code for all of my Rails apps on this site by the end of the year. Tonight, I can check that one off the list. The code for the Addressbook webapp is now available for download. Addressbook was not only my first Rails app, but also my first experience with Ajax. And trust me, it shows. I learned a lot from this project, especially what not to do. However, I must also say that I use Addressbook more than any other personal project I have ever completed. So, it can’t be that bad :) I love the fact that I can access my contact information from anywhere, and that I can manage groups of addresses and print mailing labels with the click of a button. Sure, the UI can be a bit unintuitive, but it’s not that big of an issue for me. There are a few more things I’d like to do with this project. We’ll see where it goes from here.