It is important to note that Test-driven development (TDD) is not solely a testing technique, but rather part of a holistic design, development and testing process. The basic idea of TDD is that instead of writing your code first and then writing tests after to ensure the code works, you write your tests first and then write the code that will get all the tests to pass. This is known as a Test-First approach.

There are two generally accepted views on how and why you should practice TDD in your software development. The first view sees TDD as a technique for specifying your requirements and design before writing the actual program code. The second view takes a more pragmatic approach and sees TDD as a technique that helps programmers write better code. Regardless of the view one takes, what TDD practitioners all agree on is that TDD will not only improve your code, but it will also improve the overall design and implementation of your software system.

History of TDD

Generally, the modern “rediscovery”” of TDD is attributed to Kent Beck, who is also known as the creator of Extreme Programming. It was through both the Extreme Programming and Agile software development movements that TDD came to be widely accepted in the software development community.

It is said that Kent Beck “rediscovered” TDD since a prototype of TDD dates back to the early days of computing in the 1960s. During the mainframe era when program code would be entered onto punch cards, programmers had limited time with the machine and thus would need to maximize the time they had. One documented practice was to write the expected output of whatever operation you were doing before entering the punch cards into the computer. Then when the mainframe would output the results of your program, you could immediately see whether the results you got were correct by comparing the actual output with the expected output that had been documented earlier.

The big difference between modern TDD and those early days is that it used to be a completely manual testing process, whereas the re-birth of TDD in recent years was facilitated due to automated testing. Today TDD refers solely to automated test-driven development.

Modern TDD was first practiced in the Smalltalk community and they used the Smalltalk SUnit suite for their automated testing. However, the Smalltalk community was always quite a small group and while influential, it took years for much of their brilliance to reach the wider industry. Additionally, since Smalltalk never really took off, that also hampered the initial spread of TDD.

It was in the Java community that TDD really started to take off thanks to the JUnit tool. JUnit was a port of SUnit written by Kent Beck and a couple others, and it brought automated testing to Java. At this time, many Java developers who were practicing either Agile or Extreme programming methodologies began to embrace TDD thanks to JUnit. Since then, a class of tools known as XUnit have been created for almost every programming language from PHP, Ruby, Python to JavaScript. Today, regardless of the programming language you are using, you should be able to find the tools and resources to implement TDD as part of your software development process.

The Agile Manifesto

The Agile Manifesto is considered to be a very important milestone in modern software development and it was from this document that the term Agile Software Development was born. Many cutting-edge programming techniques such as Extreme Programming, Scrum, pair programming and refactoring have come the agile software community.

The Agile Manifesto is also an important milestone in the development of TDD as several of the key principles in the manifesto are the cornerstones of TDD. Some of these ideas are captured in the following quotes that are from the article Principle behind the Agile Manifesto:

• “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
• “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
• “Continuous attention to technical excellence and good design enhances agility.”
• “Working software is the primary measure of progress.”

It is these and other principles of the agile software movement that are truly realized through test-driven development. TDD helps software developers to manage and even welcome changing requirements, allowing them to quickly adapt their code as needed. TDD helps to deliver working software frequently as developers write their tests and then quickly write code that gets the tests to pass. TDD helps with a continuous attention to technical excellent and good design, as it forces developers to carefully plan and think through their design before writing any code. Finally, TDD helps to deliver working software, which is really the primary measure of progress on a software development project. TDD produces software that works.

The TDD Process

It is helpful to now take a careful look at exactly how the test-driven process works. Exactly how does a developer begin to embrace and implement a TDD process in their workflow?

Step One: Write a failing test

A TDD practitioner begins by extracting a specific function from the system requirements. Once a specific function has been determined, the developer then writes an automated test that will test that specific function. The developer writes the test and then will write the minimal amount of code required in order for the test to simply run. Of course since the actual functionality has not been developed, the test will initially fail. This initial failure of the test is a key aspect of TDD and it is how each test begins.

Step Two: Write the code so the test passes

Once a failing automated test is completed, the developer can now write the code to implement the function. As the developer works on the code they can execute the automated test at any time to see if their code is working. This gives the developer immediate feedback and is part of the reason why TDD improves programmer productivity. The developer continues to work on their code until their automated test is passing. Once the test is passing the programmer can know with confidence that his code works as it should.

Step Three: Refactor (if necessary)

Refactoring is covered in detail below, however it is mentioned here as once a test is passing, the code is ready to be be refactored as needed. Now, this is not always a required step at this time, however some programmers will try to quickly get a test working and may in the process write some sloppy code. If that is the case, once the test is passing, the developer should go back and refactor their code so that is implemented properly with good design. Throughout the refactoring process, the developer can re-run the automated tests to make sure that they have not broken the required functionality.

Step Four: Repeat

Once the programmer has a test that is passing and they have clean and refactored code, they can then move on to the next function and proceed in the same manner. As the programmer progresses through all the required functions of the application, they will ultimately develop the actual working application. A real benefit of TDD comes with this, as they will simultaneously be completing a full test suite for the application with complete test coverage. It is very rare that a programmer will go back to their code and write tests for everything after having a fully implemented application. Complete test suite code coverage is simply a natural by-product of the TDD process and it is one that should not be underestimated.

Refactoring

As mentioned above, refactoring is a part of the TDD process and is in fact a key advantage to TDD. This is because refactoring requires code that has complete test coverage and so when a programmer is following TDD, all their code will always meet this requirement.

Code refactoring is essentially a restructuring of an existing body of code in order to improve the underlying structure and design of the code. When you refactor, you don’t change or add any functionality, rather you want the code to produce the exact same behaviour as it did before refactoring. This is why complete test coverage is required before refactoring, since the tests will ensure that the functionality does not change and still works exactly as required.

A developer can refactor a method or function and throughout the process, they can re-run the automated tests to ensure that the behaviour of the code is still working as expected and that the tests are all passing. This gives a developer great confidence to go in and refactor code that they might otherwise avoid since without the tests, you never will know if the changes you are making have broken anything.

Traditional and Test-Driven Development Compared

The following flowcharts show the primary differences between traditional and test-driven development processes. Both of these charts are largely based upon diagrams that are found in the Impact of Using Test-Driven Development: A Case Study and Test driven development: empirical body of evidence papers, which are shown under Resources.

As the above diagrams show, the key difference between the two approaches is simply the test first nature of TDD. In the traditional process, you don’t write your tests until after completing the full implementation. Thus, testing is primarily a verification that the code works as intended; it doesn’t help the developer in their work. Since TDD starts with testing and incorporates testing as a part of the development process, the tests actually help the developer and will generally improve the quality and design of the code.

A word on automated Testing

The foundation of test-driven development is automated testing, since without it, TDD would not be possible. In order to understand TDD, it is critical to also have a good understanding of automated testing. There are three main types of automated testing that are generally performed and these tests are written and executed by the actual developers. There may also be other types of automated testing but these three are some primary ones that developers will be working with.

• Unit Testing: Unit testing works as the name implies, it allows for the testing of individual units of code. Typically a unit test is written in order to execute a specific method or function within a class or modules of code. The main goal in unit testing is to ensure that each individual unit of code is executing as specified in the system requirements.
• Integration Testing: Integration testing is the logical progression from unit testing and it seeks to test multiple units and ensure that the units are able to produce the desired functionality when they are all brought together. An integration test will generally mirror an actual use case and it will ensure that all the underlying units are working together to produce the expected result of that use case.
• Performance Testing: with performance testing you typically seek to simulate a real-world usage scenario where you have a large number of users accessing and using the application simultaneously. Automated performance testing will use various tools to simulate such user behaviour and it ensures that the system can still perform under varying degrees of load.

With TDD, the primary focus of the developer will be on first writing Unit Tests and then writing Integration Tests. This is because both of these tests are built around the system requirements and ensure that each function works as intended both in isolation and then when integrated into the whole system. Performance testing is generally not included as a part of TDD but depending upon the application, it may also be included. Performance testing would be applicable when the performance of the system is itself a feature of the application.

Benefits of TDD

The benefits of using TDD are wide reaching and very compelling. In the paper Test driven development: empirical body of evidence, the following is stated, “TDD may help to improve software quality significantly, in terms of decreased fault rates, when employed in an industrial context.” As this paper gathers and summarizes 13 empirical studies from the industry, this is quite a compelling conclusion that is backed by hard facts.

In an article entitled, Does Test-Driven Development Really Improve Software Design Quality, the authors document how TDD contributes to better code. The article shows that code produced through TDD is generally better organized into smaller and well-designed units that are better tested. Such code not only is better from its initial release, but it is easier and less costly to maintain and adapt in the future.

Overall, you can find many articles and reports that list the many purported benefits of using a TDD process in your software development. Some of these benefits are as follows:

• Less software defects: since TDD produces code that is much more highly tested, the resulting software is generally shown to have fewer defects.
• Immediate feedback to the programmer: immediate feedback is given to the software developers during the TDD process so they can respond and change quickly. All a developer needs to do in order to find out if their code works is just run the tests.
• Increased confidence: since all the code is covered by tests that ensure it works as expected, developers have more confidence in their own code.
• Enables refactoring: since total test coverage is needed to refactor code, by doing TDD you are creating code that can easily be refactored.
• Cleaner and simpler designs: the code produced by TDD has been shown to be generally cleaner and simpler than code produced through a more traditional method. This ultimately produces code that is easier and less expensive to maintain.

Overall these are quite substantial benefits that should at the very least pique the interest of developers. Embracing a TDD process does require quite a radical shift in the thinking of developers but these benefits show that the effort required to do so is likely worth it.

TDD Case Study

In the case study entitled Impact of Using Test-Driven Development: A Case Study, we have the results of an experimental study that was done using undergraduate students at the University of Southern Mississippi. Each of these two groups consisted of 9 students and time period for the whole study was 3 months.

In this study, two groups of students were created; one group would develop software using a traditional approach of writing unit tests after developing the application. The other group would take a TDD approach and write their tests first and then implement the functionality of the application second. Both of these two groups developed the exact same software and both used an incremental and iterative approach. So, this study sought to determine whether the practice of TDD in a real software project resulted in better code and more productive programmers.

An additional SQA team was also utilized in the study and they were assigned the role of measuring the results of the study. This SQA team did subsequent additional unit testing, integration testing and acceptance testing of the software from each of the two development groups. Their work was done to measure the quality of the code produced by the two groups.

Some specific metrics were calculated for each of these two groups, which were used to help determine which development process was superior. These included the following:

• The number of test cases written
• The number of faults found by the SQA group in subsequent unit testing
• Number of faults recorded in subsequent integration testing
• Number of faults recorded during acceptance testing
• The total person hours for each group

The following table of results can be found in the case study:

The results of this case study are indeed compelling. While this is only one small case study, the results are consistent with other academic and industry studies. Clearly the TDD approach resulted in code that was much better tested, had fewer faults and ultimately took less time to write.

Conclusion

In conclusion, I hope that this article has shown the very real benefits that can be gained from a test-driven development process. The industry results and case studies are quite conclusive; TDD has a very positive real and measurable benefit to software development projects.

I’m learning as I go here and so I would love to hear any feedback. Please get in touch if you have any questions or to let me know if I’ve gotten any details wrong.

I set everything up as expected, copying my public key into the ~/.ssh/authorized_keys file on the remote server. However, it just didn’t work. Whenever I tried to log into the server, instead of immediately logging me on, it still gave me the password prompt. In order to dig a little deeper and find out exactly what was going on, I ran the ssh command in verbose mode (adding -v). This showed me that my public key was offered but then rejected:

$ ssh -v derek@xyz.com
.....
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/derek/.ssh/id_rsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive

So, that confirmed my suspicion that the server was rejecting my public key. In order find out why the server was rejecting my key, I needed to get the SSH server to give me additional details. To do so, I turned on AUTH logging in the /etc/ssh/sshd_config file on the server. My relevent portion of my sshd_config file looked like this:

SyslogFacility AUTH
SyslogFacility AUTHPRIV
LogLevel INFO

After restarting sshd (/etc/init.d/sshd restart) I tried again to authenticate using my public key, and expected the key was rejected. However, thanks to turning on AUTH logging, the details of my login attempt were captured in the server logs (/var/log/messages to be exact):

Authentication refused: bad ownership or modes for directory /home/derek

It was from the above log message that I was able to figure out the problem, it was simply one of permissions. SSH is very particular about the permissions on your home folder, the .ssh folder and the authorized_keys file. The solution thus involved adjusting permissions to make sure they conformed to what SSH expected. SSH wants only your user account to have write access to your home directory (group can have read), and then only it can have read access to your .ssh folder and your authorized_files file (group cannot have read).

I was then able to fix the permissions by using the following commands:

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

After doing that I tried again and voilà - it worked!

In addition to being more convenient, public key authentication is also more secure since your password is not transmitted over the network. It’s also relatively quick and easy to set up, and I hope the following information will be helpful in that regard.

With SSH public key authentication, instead of using your password to authenticate, it will instead use your public key. Of course the public key is only half of the solution, the other half is your private key. These two keys work together, so that a message encrypted using your public key can only be decrypted with your private key. It is important to remember that you can freely distribute your public key but you must never give your private key to anyone.

Public key authentication with SSH works by having your public key reside on the server, inside your account’s home directory. When you connect to the server using SSH, the server will encrypt a message using your public key and send it to you. SSH will then use your locally stored private key to decrypt that message and thus prove to the server that you are the bearer of the private key. Once your identity is authenticated through this exchange, you will be given access to your account on the server.

The following commands should work on any Unix-based system such as Mac OS X or Linux. If you are on Windows, please check out PuTTY for information on using SSH on Windows.

Step 1: Generate your key pair

If you don’t yet have a key pair, you’ll need to generate that first. The following command will generate a new RSA key pair:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/derek/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/derek/.ssh/id_rsa.
Your public key has been saved in /home/derek/.ssh/id_rsa.pub

Unless you have a good reason not to, you should accept the default location for the keys. You will also be asked for a passphrase, you can leave this blank for convenience but it’s more secure to have one. In the above example my private key is stored in the id_rsa file, and my public key is stored in the id_rsa.pub file. If you’re curious, feel free to open those files in a text editor and take a look at their contents.

If you do enter a passphrase you will want to use a tool called “ssh-agent” to cache your private key so that you won’t need to type in the passphrase every time. Use the following command to do so:

$ ssh-add ~/.ssh/id_rsa
Need passphrase for /home/derek/.ssh/id_rsa
Enter passphrase:

Step 2: Copy your public key to the remote server

Once you have your key-pair, you’ll need to use scp to securely copy your public key up to the remote server:

$ scp ~/.ssh/id_rsa.pub username@remote:publickey.txt

Then you should log into the server so that you can move your public key into the correct location. As you will note in the following commands, it is also essential to have the permissions set correctly both the .ssh directly and on your public key, so that only your user account has access to those items.

$ ssh username@remote
...
$ mkdir ~/.ssh
$ chmod 700 .ssh
$ cat publickey.txt >> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
$ logout

Step 3: Try it out!

Once that is all done you should be all set to log in to your remote server. Simply type in the ssh command as you normally would and within moments you should be securly logged into your remote account.

I hope this post has been helpful, please get in touch if you have any questions. I am also planning a follow-up which will cover some SSH troubleshooting and should hopefully give solutions to some common issues you might experience.

Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt is yet another classic from The Pragmatic Bookshelf. This is not your typical programming / technical book, where you focus on a specific technology, methodology or toolset. Instead, with this book you take a much higher-level approach, learning how the brain learns, so that you can be more efficient and effective in all that you do.

As a software developer I have to be continually learning each day. I’m either learning new things about the current programming languages and tools that I use, or else I’m learning new programming languages and tools. It never ends, and that is part of the reason why I love working in this field. It keeps things interesting and exciting, constantly pushing you out of your comfort zone and challenging you to keep progressing.

I found this book to be a great help to this process, as it helps you understand how you learn and thus optimize the learning we do, getting more value out of our already busy schedules.

So often it’s easy to continue with less effecient practices because we never take the time to step back and think about what we are doing. We think we are saving time and energy because we are doing what we find comfortable, but so often our practices could be dramatically improved. This book challenges our tendency to get comfortable and urges the reader to think critically about everything they do. Improving now only how we learn but also how we execute our knowledge throughout our daily routines.

Refactor Your Wetware

The subtitle of the book is refactor your wetware, which is a fantastic summary of the book’s purpose. As a programmer, I know only too well how over time a codebase will develop cruft that makes it less efficient and less manageable. We also know how important regular refactoring of a codebase is, and how much better and more efficient it not only makes the codebase, but also how it makes our lives easier as we work with it.

Our minds are really not much different and so we need to be regularly examining our practices and thinking how we can refactor them. Many times it’s simply a matter of stopping what you are doing and taking a couple minutes to think about how it could be done better. Maybe it involves creating a mind map or sketching out the process on a piece of paper, looking for optimizations. The hard part for me is stopping and thinking, but I’m getting better at that, thanks in part to this book.

The Dreyfus Model

The book begins by giving a helpful overview of the Dreyfus Model of skill acquisition. The Dreyfus Model is a helpful way to think about the learning process and it proposes five specific stages: Novice, Advanced beginner, Competent, Proficient, and Expert. I found this to be a helpful way to think about my current skill set, and it allowed me to categorize my skills into the various stages. From there you can plan out what skills you want to target for improvement, and in determining the current stage you are at, you can then work out a plan to get to your desired stage.

Subsequent chapters dive into an exploration of the brain and how we can optimize our brains for learning. My biggest takeaway from this section is that I need to engage my creative side (the “R-mode”) more often. I really appreciated some of the strategies that the book gave to help facilitate and encourage R-mode involvement. It could be something as simple as taking a walk to think through a problem, we just need to be continually thinking outside the box and looking for ways to see a problem from multiple angles.

Learn Deliberately

My favourite chapter of the book is called Learn Deliberately. This chapter was incredible helpful, especially as it unpacked the use of targeted SMART Objectives and it encouraged thinking about learning as an investment. Like any financial investment, you need to regularly contribute in order to increase your portfolio over time. I found the discussion on the use of Mind Maps to be especially helpful. This is a chapter I will be going back to regularly so I can really internalize the contents and completely integrate these practices into my routine.

I’m really just scratching the surface of the book’s contents in this brief review. There is so much more, it’s jam packed with useful information and so I would highly recommend it. If you have not yet read it, I would encourage you head over to The Pragmatic Bookshelf and grab a copy.

Although it is now just a memory, 2011 was a good memory. So many wonderful moments shared with wonderful people.

I find it is important (and accurate) to view each day as a gift. You don’t know how much longer you have left in this incredible thing we call life. And so as another year comes and goes, I find it helpful to think about how I can use the limited time I have. What goals can I set for the coming year?

Write it down

This has been a practice that I have followed now for many years and it’s encouraging to look back on past goals that I eventually achieved. I think the first step towards any goal is writing it down. Once you’ve got the goal nailed down, you can then start to work out a game plan for achieving it.

Now only do I like to write down my goals, but I find it’s vital to regularly review past goals. If I didn’t make any progress on them, why not? What can I do to change that?

For me some of my goals have taken years to come to fruition, but they all started with me writing them down. Something so very simple, yet with profound implications.

So, what about some goals for 2012?

There is one major goal I would like to accomplish this coming year. It is finally finishing off my Bachelor of Technology degree. This was something I put off for years but finally started working on again during 2011. I made good progress on it throughout last year and as long as I can persevere, I’ll be able finish it this year.

There is a bunch of more minor goals. I want to continue to improve my skills and knowledge as a software developer, maybe learn a new programming language (maybe Haskell?). I would like to blog regularly, not because anyone reads these posts, but so that I can improve as a writer. There are, of course, many books that I want to read.

Finally, on a personal level, I want to spend more time with my family. It during time spent with them that it really hits me how precious life is, and yet it will just pass you by unless you engage. My kids are growing up so quickly and I want to squeeze every moment out my time with them. If I accomplishing nothing else this year apart from this goal, I will consider it a success.

I must confess that prior to imbibing episode 10 of the Ihnatko Almnanac, the idea of keeping a journal was not even on my radar. However, the episode got me to start thinking about it and the more I thought about it, the more intrigued I became.

Of course I had the typical objections. Could I be consistent? My life is pretty typical, why even keep a journal?

Even if I did get off to a good start, would I shortly thereafter fall back into old patterns and forget about it?

Well, despite these objections, I checked out Day One and was very impressed by it. It just looks beautiful. But beyond it’s good looks, the app’s features were what sold me. Two features in particular stood out:

1. Automatic reminders. Exactly what I need if I am going to be consistent.
2. Available on the Mac and all iOS devices with seamless syncing via Dropbox. This in particular sold me as I am finding I’m doing much more productive writing tasks on my iPad, thanks to the Zagg Keyboard.

So on December 9th, 4 days after the podcast, I bought Day One for both OS X and iOS and started journaling. Since then, I’ve only missed one day and several days actually have two entries, one earlier in the day and then one later.

The reminders feature of Day One dealt with my concern of not being consistent, and from over 2 weeks of usage I can confirm that this feature does work. I especially like how you can tell the reminder to come back in 15 minutes or an hour. I myself use that all the time and by the time the second reminder appears, I’m ready to write something.

There is still the potentially greater issue of actually having something to write about. Speaking from 2 weeks of experience, I have not found this to be an issue. In fact, I’m now looking forward to writing each day. Usually it’s just a quick dump of thoughts and experiences. I’m finding the whole process, both thinking about my day and then writing those thoughts down, to be very therapeutic. Life is so fast paced that it’s nice to step back for a few minutes and assess how you’re doing. I also think it will be helpful for me to look back on these entries months, even years in the future, and get a sense of how I’ve progressed.

I would highly commend the practice of daily journalling to you and I would most definitely recommend Day One as the tool to help you in that practice.

As much as I love working on my computer, I’ve been discovering the power in using a different medium: a piece of paper and a pen (or pencil). There is something about using a pen and actually moving your hand that seems to help me when I’m working through a tough problem. I find it helps tap into the more creative “R-mode” thinking processes.

Just today I was struggling with a feature that never really worked the way it was supposed to. The code itself executed without any errors and all the tests returned green. But the code was not the problem, rather it was one of system design and quite an elusive one at that. No matter how I attacked the problem using the various tools on my computer I just couldn’t see it.

I needed to look at the problem from a completely different perspective in order to see the solution.

That’s when I took out a piece of paper and a pen, and started to work through the problem from the ground-up. I wrote out how the feature should work and then drew out what supporting system design would thus be required. It was not long before a real solution emerged. Here was a problem that had been nagging me on and off for weeks and within 30 minutes of working it out on a piece of paper, the solution became obvious.

So the next time you’re working through a hard problem, step back from the computer and see if an old-fashioned paper and pen works its magic for you

Today I started work on migrating another website over to Octopress and I ran into a problem with rake. Interestingly enough, I encountered this problem previously but didn’t document the solution. Since this is my second time seeing this error, I thought it might be helpful to document both the error and how I resolved it.

As documented on the Octopress site I got started with this new site by first cloning the Octopress git repository, installing any dependencies and then proceeding with the default theme installation. This is where I encountered the rake error:

$ rake install
rake aborted!
You have already activated rake 0.9.2.2, but your Gemfile requires rake 0.9.2. Using bundle exec may solve this.

The Gemfile requires rake 0.9.2 but I actually have a slightly newer version of rake installed. So, the solution is to let Bundler know that a newer version of rake is acceptable. To do so, I opened the Gemfile in the root directory of my Octopress site and updated the line for rake as follows:

gem 'rake', '>= 0.9.2'

I then saved the file and ran bundle update on the command line:

$ bundle update

What this does is update the Gemfile.lock file so that Bundler will accept any version of rake greater than or equal to 0.9.2.

I was then able to run rake install and have the installation execute successfully:

$ rake install
## Copying classic theme into ./source and ./sass
mkdir -p source
cp -r .themes/classic/source/. source
mkdir -p sass
cp -r .themes/classic/sass/. sass
mkdir -p source/_posts
mkdir -p public

I hope this solution helps someone. If anyone knows of a better way to fix the error, please let me know.

Put on by the Vancouver Park Board and the British Columbia Professional Fire Fighters’ Burn Fund, this is an essential Christmas event for families in the greater-Vancouver area. Not only do you have a good time by going, you also help support a great cause, the Burn Fund, which helps burn survivors and their families.

This year the event was themed around the Polar Express movie, which is one of my kids favourite holiday films. The event did not disappoint in this regard, they even had a man playing the role of the Conductor who caused my son Jonathan to do a double-take.

This was the first year that both of my boys were old enough to really appreciate the experience. There’s real magic happening as you try and see the event through their eyes. Going on a weekday and arriving there before 4pm also made a big difference, with much less crowds and thus minimal line-ups. It also didn’t hurt that the weather was fantastic.

In previous years I was dead set on making sure it was dark when we went on the train. However, you then end up in very long lines and of course it gets much colder once the sun sets. When you have young kids, lets just say it’s really not the wisest move.

So this year I compromised and we bought tickets for a 4:30 train ride. The result? A 10 minute wait to get on the train, two happy boys, a happy mom, and even I was happy since it ended up getting dark during our train ride. It was an overwhelming success.

As usual the light displays did not disappoint. With over two million lights it certainly would be hard to do so. There were a lot of the memorable displays that we look forward to every year, plus some new ones that the kids loved.

All in all, it’s a truly magical experience. It wouldn’t be Christmas in our family without it.

Blogging with Octopress by Matt Gemmell is a very helpful post that documents his reasons in moving from Wordpress to Octopress and gives some useful configuration and workflow tips. I really identified with almost all of Matt’s points and found they mirrored much of my own experience.

Switching to Octopress by Mark Nichols outlines how he went about switching from Wordpress to Octopress. A big portion of the article outlines the process of migrating a significant amount of Wordpress content into Markdown files. This is a must read if you plan on migrating from Wordpress.

Forking Octopress, also by Mark Nichols details how he forked the Octopress Github repository instead of just cloning it. This has allowed him to issue pull requests to the Octopress master so that he can contribute his work back to the project. I’m not contributing back yet but it is something I would like to do in the future, and so this was very helpful in that regard.

Since Octopress is built upon Github’s Jekyll, the more you know about Jekyll, the better. How to Use Jekyll is a great tutorial from Nettuts+ that will walk you though creating a very basic static blog with Jekyll.

If you’re not familiar with Markdown, then you might find this Markdown cheat sheet helpful as well.

Of course, the official Octopress site is a fantastic resource and is probably the best place to start looking if you’re interested in learning more.

Finally, if I can offer any assistance, please get in touch and I’d be happy to do so.

Who doesn’t love handmade letterpress cards? I sure do, and what a pleasure surprise it was to find some custom made letterpress cards for geeks!

My uncle, who is also a fellow geek, sent me a link to Code Cards about two weeks ago and after a quick browse through the site, I placed my order. I got the Egg Nog Arrays cards which includes a set of 4 cards & envelopes, with the cards written in Python, Ruby, PHP and JavaScript.

The cards were dispatched promptly and they arrived earlier this week in perfect condition. The set comes in a protective plastic case and a bubble-wrap envelope, which tells you about the care that goes into the product. The cards themselves are beautifully made on heavy, bright white, acid-free cotton stock.

I encourage you to head on over to code-cards.com where you can see some high quality images of the cards. Next time I’ll be placing an order for a set of CSS Happy New Year!

Prior to today, this site was driven by Wordpress and overall I was fairly happy with it.Wordpress is indeed a powerful platform and as an experienced PHP developer, I can dig into the source code and tweak things to my heart’s content. For many of the sites I manage, Wordpress is an excellent option and I will continue to use it for those sites. However, for a simple blog like this, Wordpress tended to get in the way more often than not, and I found I would get caught up in managing all the various plugins and themes more often than simply writing.

Baked vs. Fried

It was around the time of this growing discontent that I stumbled across some articles on baked blogs vs. fried blogs. Some of the most convincing posts in favour of baking came from Brent Simmons, including: New publishing system / tour of my head, A plea for baked weblogs and More on baked blogs.

The essential difference between these two approaches is that fried sites are build on demand by the user through a database lookup. In general, a fried site (assuming you’re not doing any caching) will perform a database lookup for each page view, and hence a large influx of visitors can create such a server load that the site will go down. On the other hand, baked sites are built from a bunch of scripts which output static web pages. You generally updates these static pages whenever you add or update a post. It is these static web pages that are then accessed by visitors. Not only can this speed up page load time but it can also protect you from getting fireballed.

Wordpress Alternatives

All that got me thinking about looking for a baked alternative to Wordpress, and if I couldn’t find the right one I even thought about writing my own from scratch. There was some specific features that was looking for such as being able to write all the blog posts in Markdown and of course I wanted something that was written in Ruby. Over the past several years Ruby has become my programming language of choice and so I’m always looking for opportunities to use it.

In my search I first found Jekyll, which the static site generator written in Ruby that is used on Github Pages. If you’ve visited Github Pages then you’ve seen Jekyll in action. Jekyll is fantastic but it does require you to create all your own HTML Templates, CSS and any JavaScript from scratch. Wouldn’t it be great if someone took Jekyll but then built a framework around it so that it could be complete solution? This is where Octopress comes in.

Octopress

Octopress is exactly the solution I was looking for. Build on the solid foundation of Jekyll, it provides a complete blogging framework with everything you need including:

• A beautiful semantic HTML5 template
• A Mobile friendly design
• Easy deployment
• Build in support for Twitter, Google+, Disque Comments, etc..
• Much, much more…

It is incredibly easy to get started with Octopress and the official site at octopress.org lays out the process step by step. For myself, within about an hour reading the documentation and following the detailed instructions, I had a working site.

I was also able to easily migrate my Wordpress posts over to Markdown files using Exitwp. So, if you’re a Wordpress user and you’re looking for a static blog alternative, no more excuses, you can easily make the switch over to Octopress. I’m definitely glad I did.

Could there be an innate desire in us as humans, to create? It seems to be an integral part of who we are as a species. We love to create things and we enjoy the results of other’s creations. It is a real privilege, as a software developer, to get paid for doing what is naturally fulfilling.

At the core of my work as a software developer, I have an incredible freedom to be creative in my day to day work. It is what helps me look forward to each day of work.

Now, it hasn’t always been this way. There have been times when I’ve been stuck in a rut, pushing out mediocre code, doing the bare minimum that allowed me to just finish the job. In that state of mind, there was no joy in the work and it all became tedious. I found that I had to actually work to find joy in my work. Improving my craft through reading books and related websites, taking pride in the end result, not being satisfied with mediocrity. All this contributes to not only being better at what you do, but it also makes the work enjoyable.

Now whether or not you are a software developer, I hope you have a job that gives you the freedom to create something. Its a great feeling to end a day of work and be able to say to yourself, “I made something today”.

I can relate. I can’t say I was ever actively looking for another career, but the thought crossed my mind, “do I really want to still be programming in another 10 years”? Can you blame me? I was primarily doing PHP Programming. Not to knock PHP, it works great, has an incredible amount of resources available, and for many years has gotten the job done. The problem is that while I could finish the job, the actual process always left something to be desired.

And then I started learning Ruby. I got the PickAxe and Agile Web Development with Rails books and my world was changed. My passion for programming was reignited and a whole series of events were triggered. I basically just couldn’t get enough, the floodgates opened and I let the Ruby waters sweep me away.

The Koans walk you along the path to enlightenment in order to learn Ruby. The goal is to learn the Ruby language, syntax, structure, and some common functions and libraries. - Ruby Koans

So, that brings us to Ruby Koans. If you are a developer and are looking for something that will get you excited about programming again, then maybe you should check out Ruby and I think Ruby Koans is one of the best ways to do so. The fact that Ruby Koans is what it is, speaks to how special Ruby is and how incredible the Ruby community is. Something to keep in mind when you start programming Ruby is that you also join a community of like-minded programmers, and that benefit should not be underestimated.

The subtitle for this book is “How Google Thinks, Works, and Shapes Our Lives”, which is a great summary of the book’s actual content. For me, its been incredible to see the rise of Google over the past decade. I remember when AltaVista, WebCrawler, Excite and HotBot were some of the places you would go when searching the web. Interestingly enough, I was actually working for a search engine company when Google first appeared on the scene. It shouldn’t be a surprise that I was shortly thereafter looking for another job. Google surprised us all back then with some truly disruptive search technology.

Well I digress, what about this book? I’m a huge fan of Steven Levy and I really think that he has written the definitive book on Google to date. Levy was given unprecedented access to the company over a period of several years and it shows in the behind-the-scenes information and insight that he shares.

My favourite sections of the book are the more historical portions. Even though I was an early Google adopter, this book revealed so much about the early history of Google that I had never heard before. The history of PageRank was especially interesting for me. Levy is a masterful storyteller and so much of the book brought back fond memories of the exciting early days of the web.

One of the things that wasn’t a surprise was the fact that Google is primarily an engineering-driven company. Much of the time you can see how this is their greatest strength, leading to their incredible innovations, such as PageRank. However, you can also see how this does give them a blindside at times, and they end up touting something like Google Wave as the next big thing.

Then of course there is a fairly significant section on Google’s unsuccessful foray into China. It really explores what a dilemma the company faced during that period. On the surface the whole thing looked like a clear compromise of the Google motto, “don’t be evil”. However, the book explores the debates and discussion that went on behind the scenes, and you really see that the situation was never that black and white. Despite the the fact that I still have reservations about Google’s involvement in China, I now have a much greater respect for them and I better appreciate what they were trying to accomplish there.

Overall, a highly readable book that gives you an unprecedented look into history of Google and delves deep into what makes them tick. I would say this is an essential read for anyone involved in the software industry. However, anyone who uses the Internet regularly and wants a greater understanding of how Google rose to prominence would also benefit from it. Highly recommended.

Buy “In the Plex” from Amazon.com today.

My band Greylevel has recently released their sophomore album entitled “Hypostatic Union”. We worked really hard on it over the course of about 2 years and we are very happy with the end result.

The album itself is quite an expansive work with long songs that flow into each other. Lyrically, the album is an exploration into the search for meaning and the discovery of coherence through a transcendent worldview. Some have called the album dark and depressing, which I don’t get. It is however an album that, I hope, will give you a window into some of my thoughts and also cause you to think some of your own thoughts.

If you are a fan of modern progressive rock, or if you’re just a fan of music in general, then please check it out. If you visit the Greylevel website,  you can listen to song samples and also find out where you can buy a copy, if you are so inclined.

This is a fantastic book and I would recommend it without hesitation to anyone who works as a software developer but is currently in a rut and looking to revitalize their passion for programming. I am speaking from experience since a couple years ago, this described me. There was a point that I was even considering changing industries and looking for another job.

Now it wasn’t just this book or any single event that helped me to regain my passion for programming, it was a whole combination of factors. However, this book played a role as it helped me to regain some perspective and realize that I actually enjoy programming. Somehow I had forgotten that in the midst of the daily grind.

You can play it safe and simply get by in the software industry by doing a decent job for your employer and getting your work done adequately. That sort of behaviour will generally lead to stagnation and a sense of dissatisfaction with your job (again, speaking from experience). This book calls for something different. It calls for software developers to be passionate about their work and not settle for mediocre. Take some risks, learn new skills, challenge yourself daily, never allow yourself to settle for crap.

So as you can probably guess, I highly recommend this book. It has really helped me once again be excited to be a part of such an innovative and fast-paced industry. I hope it does the same for you.

Buy “The Passionate Programmer” from Amazon.com today.

Being Geek by Michael Lopp is an enjoyable and insightful read for anyone in the software industry, but especially for us developers. The book’s subtitle is “The Software Developer’s Career Handbook” which I thought was quite apt.

Michael Lopp is someone who has worked as both a software developer and a manager and so he gives a balanced perspective. As a software developer you’re going to need to deal with managers and so it’s good to gain a better understanding of their perspective. This book will help with that.

One of the things I appreciated was the focus on treating your job as a career, and thus thinking about it with a longer term trajectory. I found that helpful, since I know it’s easy to live in the moment and not think about the bigger picture. If you do want to progress in your career, you need to have a plan.

Overall, I would recommend the book. I found it to be a nice break from my usually reading which consists of much more technical material. If you’re interested, it’s worth checking out (the book’s website)[http://www.beinggeek.com] as well.

Buy “Being Geek” from Amazon.com today.

This is the first book in the highly acclaimed A Book Apart series. As a web developer I found this book to be very helpful in presenting a solid introduction to HTML5 that I could put into practice right away.

As the title clearly indicates, this is targeted at web designers, and so it’s somewhat light on the technical details. However, this also means that the book is highly practical and is full of real-world examples. There are other books out there which I, as a web developer, can turn to for those lower-level details. Before you go ahead and purchase this book it’s important to keep that in mind. You might be better served by Introducing HTML5.

The bottom line: a great introduction to HTML5. If you’re looking for a book to get you started with understanding how to utilizing HTML5 in your website development, I’m not aware of a better book.

Buy “HTML5 for Web Designers” from Amazon.com today.

I think most developers would agree that one of the best ways to either learn new programming languages or to simply improve as a developer, is to read code and learn by example. Appsamuch is exactly that and has 31 example iPhone applications with the complete source code for each. In addition, each app comes with a nice step-by-step guide to get you up and running as quickly as possible.