Those of you who are still following my “morning posts” know I’ve been actively focused on testing out, commenting on, and reviewing the entire process of “Learn Ruby the Hard Way“. For those of you who have decided to just avoid my feed in the mornings and focusing on my afternoon posts, that’s fine, but I’m going to talk about about it here, too. Not the Practicum, but the overall concept, and the site behind it.

I first heard about “The Hard Way” because of a book called “Learn Python the Hard Way“, written by Zed Shaw. It was introduced to me by a developer I worked with when I was at Tracker (the company I was at prior to SideReel). We were talking about learning how to code, and I voiced my frustration at the fact that most books skimmed the surface ideas, and offered very little to those of us trying to make the jump from having a superficial knowledge and understanding of a programming language and actually getting proficient in using it. He said “Then you should totally check out this book. It does exactly what you want, as it walks you through a lot of exercises and then has you struggle with the extra ideas to work on. Oh, and he says you’re not allowed to copy and paste. You have to actually type everything in!”

I downloaded the book PDF, skimmed it, thought it looked promising… and then forgot about it. Why? While the idea was interesting, I really didn’t have a need, or time, to work with Python at that given point. Tracker’s a .NET shop, so I spent my time focusing on reading about and monkeying around with C#, but again, just on the periphery, nothing in depth.

Fast forward to 2011. I now work in a Rails shop, where Ruby is the Lingua Franca of the business, as well as all of the additional add-ons that are used to add functionality to an enterprise level Rails site. I’m actively involved in working with Cucumber, Rspec and Ruby as a testing framework. A lot of the framework I’ve been able to figure out by trial and error, but this time, I decided it would make a lot more sense to just get some in-depth Ruby knowledge, so that I can better communicate with the development team, and also make my own tests perhaps more extensible and add some of my own logic to the mix.

That’s when I thought “ah, if only there were a Hard Way book for Ruby. Wouldn’t that be cool?” For grins one day I typed in “Learn Ruby the Hard Way” in Google, just to see if there was some kind of discussion board about it. Imagine my surprise and delight (OK, that’s pushing it, but will you accept amused interest :)?) to discover that, indeed, there was a “Learn Ruby the Hard Way“, and that it was structured nearly exactly along the lines of the original Python book. What’s more, that this process was being applied to a number of different languages and concepts, and there’s a site dedicated to this process called “Learn Code the Hard Way“. The Python book is the most famous, and the Ruby book looks like it will follow suit. Zed is also working on developing three additional books. First is a project to do the same for the C programming language (called, appropriately enough, Learn C the Hard Way),  a project for SQL, and a project for Regex. Zed also welcomes those that want to help the project along, so go check out the page and see if you would like to contribute (I’m guessing he might appreciate some testers checking out the site, too 🙂 ). Is there a programming language you’d like to see listed. Suggest it, or better yet, if you have experience and are willing to contribute, why not help write one yourself?

As you might guess, I am finding this site and this approach valuable. testers, you might find it valuable as well. Even if you don’t need to use Ruby or Python or C, you may well need to interact with SQL and I’d think understanding Regex would be a valuable skill for any tester that has to write scripts of any kind, even if it’s just shell scripts (and know I’m saying that rather tongue in cheek; I’m very aware of just how much power and the full linguistic capability of the shell there is). In short, this is a site I think anyone interested in the inner workings of code should consider spending some time with.