Archive for the 'Uncategorized' Category

A New Chapter

After an amazing 4 years living and working in London, my fiancé and I have moved back home to New Zealand. I learned an incredible amount as a contractor working on enterprise software development. I love software development, but I never felt fulfilled developing software for the enterprise. In my spare time I would work on my own projects, but always wished I had more time to devote to my product ideas.

So after a lot of consideration, I’ve taken the plunge and started an app development company with a good friend of mine. We will be focused mainly on creating iOS apps for the iPhone and iPad. Developing for this platform is something I truly enjoy doing and the App Store is a great place to find customers who are willing to pay for quality apps.

Last year we created and launched our first iPhone app in the App Store. We both loved the process of creating and launching a product to paying customers and improving it based on the feedback we received.

Our goal is not to grow a business with dozens of employees and large monthly overheads (I would hate that), but to simply earn enough revenue to make a decent living and have the freedom to work from where we want, for customers we care about, on products we are passionate about.

"Build a life around what you’re really talented at and you’ll be many times more successful than if you base your work on what you’re ok at." – John Williams.

I’m spending time at the moment learning about product development and researching several product ideas. I am very wary of wasting time and money creating a product that no one wants, so I’m researching ideas thoroughly before thinking about design or writing a single line of code. I will discuss this process further in my next post.

Am I worried about the uncertainty of starting a business? Of course I am – I still have bills to pay and setting up a flat in Auckland is not cheap. I know sometimes it’s going to get hard and I’m going to need passion and motivation to stick in there. But I know deep down that this is what I want to do and now is the time to do it.

Life’s too short not to enjoy what you do every day. Make 2011 the year you get paid for doing what you love. If you’re interested in taking the plunge, I highly recommend reading Screw Work, Let’s Play: How to Do What You Love and Get Paid for it by John Williams.

Refactoring To Functional Code

In my previous post I explained that some problems are better suited to a functional approach than traditional, imperative code. I showed an example of a problem that suits a functional approach and demonstrated turning several lines of imperative code with nested for-each loops and if-statements into a single line of functional code. Paul Harrington posted a comment asking what individual steps I took to refactor the code. Here’s my explanation of the refactoring:

First, here is the original, imperative method.

public int[] Translate(string word)
{
    ArrayList numbers = new ArrayList();

    foreach (char character in word)
    {
        foreach(KeyValuePair<int, char[]> key in keys)
        {
            foreach(char c in key.Value)
            {
                if(c == character)
                {
                    numbers.Add(key.Key);
                }
            }
        }
    }

    return (int[]) numbers.ToArray(typeof (int));
}

As you can see, it takes some effort to determine what’s really going on. From this code we can determine that:

For each character in a word, select the first key in the list of keys that contains the character and add it to an array of numbers to return.

Now, lets express the statement above as functional code:

To select each character in a word, we need to convert the string to an array of characters. The LINQ Select method projects each element of a sequence into a new form. In this case, a string translates to a sequence of characters:

IEnumerable<char> characters = word.Select(c => c);

For each character, we need to find the corresponding key that contains the character. The First method returns the first element of a sequence:

int key = keys.First().Key;

In our case we need the first key in the list of keys that contains the character. The First method has an overload that returns the first element in a sequence that satisfies a specified condition.  To specify our condition we use the Contains method, which determines whether a sequence contains a specified element:

char c = 'a';
int number = keys.First(k => k.Value.Contains(c)).Key;

When we combine the code that selects each character with the code that gets the first key containing the character, we end up with this:

IEnumerable<int> numbers = word.Select(c =>
        keys.First(k => k.Value.Contains(c)).Key);

Finally, we use the ToArray method to return an array of type int. Now we have our final, refactored method:

public int[] Translate(string word)
{
    return word.Select(c =>
        keys.First(k => k.Value.Contains(c)).Key).ToArray();
}

I hope this helps to explain the steps I took to refactor imperative code to functional code. You can get really clever with functional code, but remember, readability is what’s most important. Sometimes it’s best to stick with good old-fashioned for-loops and if-statements, but for some problems, like above, a functional approach can lead to more readable, clean and concise code.

Design and Testability, Which Comes First?

Jeremy Miller recently posted a good entry on Design and Testability. He talks about how important a good understanding of fundamental design principals is to writing testable code. I totally agree with this. I also believe that testing code is a great way to truly understand the benefits of applying design principals. Can you spot the circular dependency? 🙂

I first learned about the S.O.L.I.D. design principals several years ago and thought I was applying them in my code. However, it wasn’t until I started writing unit tests that I truly grasped the problems dependencies in particular can create in a system.

I eventually learned the hard way. In my early unit-tested applications, the tests ran slowly, often hit the database and required a fair amount of set up. The tests were still very beneficial, but the tight-coupling meant that it was difficult to refactor without breaking hundreds of tests.

So here’s the catch-22:

Without unit testing, you are unlikely the fully appreciate the effect dependencies have on a system.

But, without an understanding of good design principals, your unit tests may be ineffective, difficult to write, require a lot of set up and can quickly become hard to maintain. At which point you are likely to blame unit testing itself and not your lack of understanding the fundamentals of good design.

So what should come first? Learning about unit testing, thus feeling the pain of a poor design. Or, learning about good design but not fully understanding the benefits it has on a well structured and tested application?

Steve’s Circuit Breaker Interceptor

Steve Degosserie has created an implementation of the Circuit Breaker Pattern as an Interceptor using Castle Windsor IoC.

Check out his post here:
http://blog.yoot.be/post/CircuitBreaker-Interceptor.aspx