From the monthly archives:

April 2010

Maintainability of your code can be measured in many different ways. Jake Scruggs has combined several of the tools that measure you code into one Ruby Gem: metric_fu.

Here’s a demonstration. Go check it out!
Download 116.1 MB
Download (iphone & ipod) 55.8 MB


Dave Thomas is one of the founders of the Pragmatic Programmers. He is a signatory of the Agile Manifesto. He’s written several books, including: The Pragmatic Programmer, Programming Ruby (The Pickaxe Book), and Agile Web Development with Rails

This discussion covered a wide variety of topics, including how he picked up Ruby, learning new languages, and building businesses.

I think one of my favorite parts were his description of how he came to write his books Programming Ruby and the Pragmatic Programmer. For me it was valuable to get that type of view into some of the early documentation on my primary programming language.

I also appreciated his insight into building code better, rather than building better code. He offered insight into code that is appropriate to the task that is being built. He offered the following questions as qualifying whether you’re building code better:

  • Does it do what the customer wanted?
  • Can it continue to provide value so in the future?

This sort of purpose driven development is really the whole point of what we do as programmers. Thank you Dave for pointing out that the important thing is keeping the practices that allow us to adapt to changes in the ecosystem our applications run in.

Dave also shared with us that talent in programming is important. Like musicians, you need talent to be able to perform. You can only get so far pushing your way through programming. Can you think about things as explicitly as a computer?

More importantly, rather than the introverted programmer who doesn’t communicate, a good programmer has the ability to translate the customer’s requirements into computer instructions. You need the ability to communicate clearly and represent the computer and its capabilities to the customer.

One of the most important things you can do is find a good set of mentors. Someone who can teach you what you’re doing right and what you’re doing wrong. Dave shared a terrific example where he said the right thing in the wrong way and explained how his mentor approached him and what to look for in a great mentor.

Here is what Dave recommends in looking for a mentor:

  • Spend some time getting to know them.
  • Look for people around you.
  • Look at what they do, since you’ll be modeling yourself after them.
  • Ask them to be your mentor. If they’re not willing, they’re not a good mentor.

Oddly enough, the person I approached after this podcast is also named Dave.

If you want to know where the Pragmatic Programmer came from, Dave tells us toward the end of this episode. We pick up the discussion next week talking about his businesses and entrepreneurship.

Download this Episode

Here are some affiliate links to Amazon for Dave’s Books:


Ruby uses special characters to define certain data types. If you wish to use these characters in your data types, you need to escape them or use percent functions.

Percent functions are much simpler.
Download 35.8 MB
Download (iphone & ipod) 14.7 MB


The DRY principle is a guiding principle behind frameworks like Ruby on Rails. It’s basic tenet as provided by the Pragmatic Programmers is:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

This basically means that between your database schema, code, architecture, etc. you should only have one representation of each piece of knowledge that applies to your system.
[click to continue…]


This is take II of the Pair Programming episode. The first take wasn’t what I wanted to communicate about pair programming. Please give it a listen and check out the show notes on the original recording.

Download this Episode


I recently read Refactoring in Ruby. There were several things I really liked about the book and one flaw that caused me some problems.

The first thing I liked about the book was the way it pointed out code smells and how to identify them. I found several things that really affected the way I code because I recognized that I implement several of the code smells routinely in my own code. This part of the book was very clear and in my opinion alone made it worth having.

Second, the exercises are top notch. They make you think about the code you need to refactor. They also help you visualize or actually complete the changes that need to be made to the code.

Finally, it made me think about how I implement code in the first place. This is related to the first point, but there I’m talking about the mistakes I’ve already made, or at least the smells in my existing code. In this case, I’ve already approached a couple of problems only to see that there was a better way due to the principles behind the code smells.

The only problem I had with the book was that it seemed to rely on other literature to define the solutions. It would give an explicit name for the refactoring that needed to take place, but wouldn’t explain the process. Now, in most cases, you could guess from the name what the steps for refactoring might be, but this was not always clear.

Overall, I feel like the book is a great resource if you’re looking for exercises to make your code better or if you want a compilation of common code smells in Ruby. Just make sure you’re willing to look up the refactorings that are named but not explained.


Ruby on Rails allows you to nest models within a form. Ryan Bates of Railscasts demonstrated how to set up these forms with JavaScript using the Prototype framework, which ships with Rails.

In this episode, Charles Max Wood gives a brief overview of how Ryan’s code works, and then refactors the JavaScript to use JQuery.

Ryan Bates demonstrated how to build a form with nested attributes in Ruby on Rails with Prototype. This screencast demonstrates how to refactor that form into usage of jQuery.
Download 88.4 MB
Download (iphone & ipod) 40.7 MB


This week’s episode on pair programming discusses where you might see pair programming, HashRocket’s pairing setup, perceived and real disadvantages to pair programming, its advantages, and what it takes to do good pairing.

Pair programming is usually associated with Extreme Programming. It is sometimes seen as a mentoring practice, but is actually a collaboration practice, not a mentoring practice. This is because both programmers participate equally, not one leading and the other following for long durations. Pair programming is done with 1 computer and 2 programmers. I’ve never seen it work well with 2 computers and 2 programmers unless one computer was being ignored or under-utilized.
[click to continue…]