What does 5 years feel like? That was the question that I found myself pondering this morning.

Today my eldest son Jonathan turned 5 and one of the first things I did after he woke up was to sit him on my lap and tell him the story of when he was born. It’s one of his favourite stories, and he loves to hear how that day transpired. From the time that my wife entered into labour at about 5am up until when we held our precious newborn in our arms around 10pm. It was a long and wonderful day. One of the best days of my life.

Personally, Ruby is my favourite programming language and whenever I have a choice in the matter I’ll be using Ruby for any projects. Likewise, when building a web app I’ll turn to Ruby-based frameworks like Rails or Sinatra. However, I know for me I don’t always have a choice in the matter.

Currently one of my largest projects is maintaining and improving a very large and complex PHP / Zend Framework web application. To even think about porting this app to Rails would be off the table and despite such limitation, I want to make the process as comfortable as possible. To do so, I will still attempt to use the tools I’m familiar with whenever I can. Enter Zend Framework deployment with Capistrano.

I’m sure they’re out there, but I’m not aware of any PHP or Zend Framework based deployment tools that even come close to the functionality of Capistrano. The great thing about Capistrano is that you’re not limited to using it with only Ruby and Rails based projects, but it actually works beautifully for any kind of project. In my case, it was an ideal deployment solution for this large PHP web application that I manage.

In this post I will detail exactly what you need to do to get your Zend Framework apps deploying with Capistrano. To play along you will need to have Ruby and Git installed on your system.

Several years ago now, I started on a journey that I found to be intimidating and humbling. After being out of school for the past 12 or so years, I decided to return and complete something that I had begun those many years ago - my undergrad degree. While I’m not yet done, as the finish line draws ever closer, I am now able to start looking back on this experience and understand how important this journey has been.

There were many times throughout the past year and a half that I really felt that what I was doing was basically insane. Here I was, a 33 (now 34) year old man with a wife, two kids, a great full-time job and over 12 years of experience as a professional software developer. What benefit could an undergrad degree ever serve at this point in my life?

The journey to return back to school began several years ago during a period of dissatisfaction with my career as a software developer. I found myself starting to ask the question: can I really see myself doing this for the rest of my life? Sure it had been a fantastic ride so far, and I really did enjoy writing code, but I had a hard time seeing myself still doing this in my 40s and beyond. It was this time of personal re-evaluation that I began to think about some other options for myself in the future.

Perhaps you’ve heard of test-driven development but don’t really know what it is. Or maybe you know about it but you just don’t know why you would ever want to use it. In this article I hope to give an overview of exactly what test-driven development is and why you should consider integrating it into your software development process.

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.

This is a follow-up to my recent post on SSH Public Key Authentication. I was setting up a remote account with public key authentication so that it would work with my capistrano deployment process. Basically I wanted to be able to run cap deploy and have it execute without needing to type in the password of the remote account. While setting this up I ran into an issue that I thought would be helpful to document, both the problem and the solution.

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:

Do you use SSH to log in to a remote server? If so, do you type your password in every time you log in? Did you know that you don’t have to?

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.

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.