Over the past month and half I’ve been working hard on my TDD skills. Having come from a learn-as-you-go web development background (as a lot of web developers have) I’ve found the transition to a test-first workflow to be a real challenge. Luckily, I work with a great group of Rubyists and Madison, Wisconsin has a great Ruby community.

First step: RTFM (or RTFB, in this case)
RSpec is central to my everyday workflow. I work in a Ruby shop and have the luxury of working with people who have already mastered this stuff. While this is great, it also means that most of my experience with RSpec up until now has been with maintaining and extending a test suite, not starting from scratch and driving out features.

To begin my study of RSpec, I picked up the RSpec Book (David Chelimsky), which is really more of a TDD/BDD book than it is purely RSpec. It does a fantastic job of covering the BDD development cycle and it’s more of a conicidence that the samples are in Ruby.

The cycle is described as follows:

1. Focus on one scenario (Cucumber)
2. Red: Write a failing step definition (Cucumber)
3. Red: Write a failing example (RSpec)
4. Green: Write code to make the example in #3 pass (RSpec)
5. Refactor: Refactor your code, ensure your tests continue to pass (RSpec)
6. Return to Step #2 and continue to through your step definitions until all are passing
7. Refactor: Refactor your code, keeping both RSpec and Cucumber test suites passing

The RSpec Book is worth the money on the merit of its coverage of the BDD cycle alone. I also appreciated that the author, David Chelimsky, chose to use a command-line application as the central example rather than a web app. While Rails is a great framework, I’m discovering that if you’re not careful to ground yourself in Ruby fundamentals, you can easily lose your way in the conveniences of the framework and write a lot of bad code. The command-line app gets back to basics and helps liberate the user from having to worry about browsers, databases and servers for awhile and focus on the code itself.

More complex example: Conway’s Game of Life
The next step in my process was to apply it to test-driving Conway’s Game of Life. Conway’s Game of Life is a classic programming exercise used to demonstrate object oriented programming techniques. As I began working on the problem, I was stumped. As I mentioned earlier, most of my experience is in maintaining a mature test suite. This means that much of the infrastructure and helpers have been defined. This was a brand new endeavor: new project, empty test suite and an unfamiliar topic. It was the programming equivalent of writer’s block.

To get unstuck, I did some searching to see if there were any solutions to this problem that I could study. As luck would have it, there is a great screen cast of Ryan Bigg tackling Conway’s Game of Life using RSpec and Ruby. I watched the video a couple times and was able to implement all four rules after getting a feel for how a master approaches TDD.

Global Day of Code Retreat
While it did feel good to get Game of Life functioning, I felt like I had cheated by watching someone else implement the first rule. As luck would have it, I was able to get a ton more practice at the Global Day of Code Retreat.

The Global Day of Code Retreat, held on December 7th, was a collection of local events around the world where programmers worked together along with a facilitator to practice BDD on (you guessed it) Conway’s Game of Life. After each 45 minute session, you trash your code. It’s not about the result, but about putting the principles of BDD into practice. After hacking at the Game of Life from 9am to about 4pm, I learned a valuable lesson: BDD is about practice.

That’s all there is to it. I’m not going to get it all at once. It’s an approach and an attitude, not a silver bullet. After studying RSpec for a month and a half, I’ve learned that I’ll be studying RSpec, or more specifically BDD, for the rest of my career. And that’s fine by me.

About the 1up Project
The 1up Project is the brain-child of Joe Nelson. It is a self-directed program of personal-improvement where the participants choose specific topics, study them over a discrete period of time while applying the knowledge gained to a specific project, presentation or blog post.

I kind of had a feeling that would be my conclusion based on hearing this talk at Madison Ruby by Paolo Perrotta, the guy who wrote the book on metaprogramming. In the talk, he shows just how tricky metaprogramming can make your code.

Essentially, because metaprogramming is code that writes code, you can end up with a codebase that has hidden “gotcha” methods that are created as if by magic. This often conceals what is actually going on, makes the code hard to read, hard to debug and hard to extend or modify.

Definitely an endeavor left to someone who’s a bit more of an expert than me.

That’s not to say that I didn’t learn anything. Quite the contrary. The series starts with a great overview of the Ruby object model, the call chain for methods, inheritance versus mixins, singleton methods and a whole slew of other great stuff.

I plan to cover a couple of these topics here, but as a note to the reader, a lot more has been written on these topics by people infinitely smarter than me. My coverage of the topics here is intended to be more of an exercise of completion of the section of my 1up project than an attempt at a definitive screed on the subject.

The Call Chain
When you call a method in Ruby, the interpreter looks for the definition of that method in the object that maps to ‘self’ in the current context, if that method doesn’t exist on self, Ruby moves “up the chain” and checks self’s parent class, and so on until it runs out of parent classes. Here’s an example:

# define a specific string
my_string = "I'm a string!"
# call #reverse
# 1) this first checks to see if my_string has a method called reverse
# 2) it doesn't find one
# 3) it then checks for reverse on my_string's parent class, which is String
# 4) it finds the method and executes it and outputs the following:
my_string.reverse
=> "!gnirts a m'I"

# if we define a singleton method on my_string like so:
def my_string.reverse
  "I'm overriding .reverse"
end
# and then call .reverse on my_string
my_string.reverse
# we get the result of the new method and not that of
# the default behavior of String

my_string.reverse
=> "I'm overriding .reverse"

This concept becomes important in metaprogramming because the Ruby interpreter has several “hooks” for methods, classes and modules, marshalling and coercion that can be used to execute code that extends Ruby’s functionality. When you use these hooks, you need to be sure where exactly which member of the call chain you’re attaching your meta-functionality to. For example, in the screencasts, Dave Thomas demonstrates how to attach console tracing to methods by using the method_added hook. It’s really impressive to watch him implement the code, but there are a lot of nuances that he has to work around. A list of all these hook methods can be found here: http://stackoverflow.com/questions/5127819/is-this-a-comprehensive-list-of-ruby-hook-methods.

One of the more well-known uses of these hooks is to use the method_missing hook to create the semantically-rich find_by_xxxx methods in Active Record where xxxx is a model attribute that is essentially a column in a database. (I sure hope I said that right)

You must realize the truth: there are no class methods
Another interesting tidbit that stuck with me was this: class methods are really nothing all that special. In actuality class methods are really just singleton methods on a Class object. The following two examples are essentially the same:

class Foo
  def self.bar
    puts "I'm at the bar!"
  end
end

# is essentially the same as
Foo = Class.new 
def Foo.bar
  puts "I'm at the bar!"
end

While this kind of prototype-based development is valid, it’s not typical Ruby style. The screencast advised that that type of idiom is more prevalent in Javascript, so I’m going to squirrel that knowledge away for my future 1up investigations into Javascript and it’s popular libraries like jQuery, Backbone, etc.

I’m sure there was a ton of information in these screencasts that just didn’t stick. It’s my hope that I’ll learn more on subsequent viewings and more practice. I’d definitely recommend them to anyone who wants to learn more about the Ruby object model and how important it is to have a deep understanding of those concepts before embarking on any metaprogramming adventures.

Also, if I’ve made any egregious errors in my explanation of concepts above, please let me know. I really want to keep this stuff straight in my head.

For my next topic, I’m going to tackle Test Driven Design (TDD) with Ruby and Rspec in an effort to write cleaner, better-designed code. I’m always amazed when I watch some of the giants in the industry sit down and drive out features and functionality with TDD, and I’m looking forward to a lot of practice.

I found Chapter 37 to be one of the more valuable in the course. It’s simple enough: go through a few dozen of Ruby’s symbols and keywords, guess at what they do, look up what they really do, then write some code that shows what they do. While this may sound tedious to some, I found it incredibly valuable to get a better grounding in the Ruby toolbox and a reminder to spend time studying the entirety of the languages I use instead of just nibbling around the edges.

The course involves a good deal of repetition. Revisiting concepts and projects throughout to help drive home the fundamentals of the language. Practice and drilling on fundamentals is something that you don’t always hear about when people talk about learning to program, but it’s probably the best way to learn. Like the 10,000 hour rule says: if you want to master something you just have to do it. A lot.

One of the the aspects of the course that didn’t resonate with me was that the larger exercises focused on creating games of one sort of another. I had a difficult time dreaming up a text-based “you’re in a hallway with a door in front of you” type of game.

Luckily, my office has a mostly-weekly Ruby quiz. One of the challenges was to develop a blackjack program and it coincided nicely with one of the game development chapters. I was excited to dive in and began making good progress. As I implemented rules, the card deck, and other aspects of the game, I discovered something. My code was a mess. Blech. There were instance variables all over the place, methods that did all kinds of different things…an unmitigated disaster. But it ran!

Great, so I had basically created the AMC Pacer of blackjack programs, the Spruce Goose of Ruby scripts. When it came time to show my code, I told everyone how dissatisfiled I was with the way it turned out. Thankfully, I work with a supportive group of people (MINiSWAN) who had a lot of great suggestions. The most useful feedback I got was the following: “your code works, but it’s not clean.”

So, I’ve got some things to add to my research list: SOLID principles and Clean Code, by Kent Beck. I hope to return to my blackjack trainwreck and fix it after some practice with these concepts.

It’s clear that my study of Ruby as a language will take me longer than one month. I had a feeling when I set out to cover a different topic every month that some would probably spill well over that limit. In those cases, I can either “call it” and move on or take the extra time, depending on the situation.

In this case, I feel it’s well worth it to stick with my study of Ruby for at least another month. The next topic I plan to cover is Pragmatic Programmer’s screencasts on metaprogramming and the Ruby object model. I’ve watched a few of these already and I’m looking forward to going through the rest.

Special thanks to Joe Nelson for sending me a virtual pants-kick via Twitter.

I think the biggest thing that’s stood out for me thus far is an idiom of string substitution I’ve not seen before. It involves leaving %s or %d within a string and then listing the values to be substituted into the string after closing the string. See the example below:

# string substitution
puts "We'd have %s beans, %s jars, and %s crates." % [jelly_beans, jars, crates]
 

Aside from that, I’m happy to report that nothing has surprised me. I’m hoping to finish this off this weekend. I realize that I’m taking a faster pace than is outlined on the site, but I’ve got quite a few Ruby resources to get through over the next month. If I hit a snag, I’ll slow down and take the time I need, but for now it’s full speed ahead.

Plotting my course of study for the next year

Earlier this summer, Joe Nelson embarked on a quest to become a world-class developer over the course of one year. He calls it his “1up Project“. The approach is 2-week iterations of concentrated study on a variety of topics ranging from the HTML5 Canvas to PPC advertising. Each 2-week sprint culminates with a blog post, lighting talk or some other form of knowledge transfer. Learning a topic with the intent of teaching is a great way to truly absorb a subject.

After attending this year’s Madison Ruby Conference, seeing Joe present his 1-up project and being inspired to level up my own development skills by some of the sharpest minds of the Ruby community, I’ve compiled a list of topics that I want to cover over the next year.

My ambition is not as lofty as Joe’s. I’m not sure I can hit world-class developer in a year. Since I’ve only recently begun working full-time as a Ruby developer, I still need to cement many fundamental concepts and tools of open source development that Joe already has in his toolbelt before I can walk his path.

Given that some of these topics are very broad, I plan to devote a month (or more in come cases) to each topic. I do still intend on developing a blog post after completing each phase of the course with the intent of documenting my path.

I started by mind-mapping the skills that I’ve observed seasoned developers using as I pair with them at work. From that map, I developed a list of 8 broad topics and then identified resources within each topic that I will use in my course of study. Here is my 1up list:

* Ruby (gotta start with the basics)
* Rails
* Testing
* Javascript
* Git
* Rails deployment
* Databases
* The *nix shell
* Vim
* And some miscellaneous topics.

So there you have it. Probably a year’s worth of self-guided study to begin a move towards craftsmanship. For my very first topic, Ruby, I’m going to go back to the very basics and run through Zed Shaw’s Learn Ruby the Hard Way. I’ll let you know how it goes!

UXMad is coming. Some of the greatest minds in User Experience will be descending on the Overture Center in Madison, Wisconsin on July 19 through the 21st. If your product, application or service has any room for improvement you owe it to yourself to attend.

The conference is single-track, so you won’t miss a thing. It’s put together by the same folks who organize Madison Ruby, which was mind-meltingly awesome last year and promises to be again this summer. There are twenty-one sessions from some of the smartest folks in UX, with backgrounds ranging from application development to healthcare to the music industry. That’s a whole lotta smart to pack into one conference.

Conference aside, Madison is a great city to visit. Lakes, restaurants, the University of Wisconsin, an abundance of craft beer and legions of smart, friendly people make Madison a great place to visit (or live, for that matter).

So, there you have it. There’s still time to register. If you don’t come, I’m totally not inviting you to my birthday party. Details are at UXMad.com.

A quick reminder on a Friday: nobody’s dying words are “I wish I had spent more time at the office.”

Remember, your slides are there to support your talk, to make it more interesting. Find some great images or dynamite illustrations to burn your story into my brain. They are an (and usually hate this word) opportunity for you to turn a boring old talk into a multimedia event akin to the U2 Zooropa tour. Okay, that may be a stretch.

However, if you must read to me, please bring milk and cookies and offer a nap time afterwards. Or during, for that matter.

P.S. I’ve perpetrated this odious deed myself. Let’s all get better together.

Every time someone asks, “what’s the ROI of social media?” A unicorn dies. So sayeth Scott Stratten, author of Unmarketing.

He’s right.

“What’s the ROI of social media?”
First of all, it’s too broad a question. “What’s the ROI of high speed internet?” “What’s the ROI of our cash register?” “What’s the ROI of executive perks?” Are all similarly difficult to answer. All these things are, like it or not, the underpinnings of business as usual.

Unless you’re an Amish woodworker, you need high speed internet. If you sell things at a retail outlet, you need a cash register. And if you have a gaggle of executives, you need to provide them some level of perks on par with their peers or they’ll bolt for one of those companies. Finally, if you have customers, they’re probably talking about you in social media.

Social media is fast becoming THE fundamental communication channel for your customers. Is your plan to pretend it doesn’t exist because it is presently difficult to measure? Your competitors are certainly hoping you will.

Social media is market intelligence
As I said before, if you have customers, they’re talking bout you in social spaces. They used to do it anyway, it was called the coffee shop, the farmer’s co-op or the local tavern. You need to understand and be prepared to engage your customer in meaningful conversations in social spaces. Today, it’s Facebook and Twitter. Deal with it.

If you must measure the sentiment around your brand, you can start with SocialMention or Google Alerts. They’re free and can help you take the temperature of your brand’s buzz. Do this before you drop a briefcase full of cash one of the big listening packages.

Social media is story-telling
A Twitter account is free. A Facebook page for your business is free. A YouTube account is free. However, they are, as friend Tom Buchheim says, “free like a puppy.” You need to be prepared to tell your story in these channels.

Please note, the following is not your story, “be my friend and get some occasional discounts.” That’s boring. That’s a loyalty program.

“I’m in my office.” Also not a story. In fact, that’s not even interesting as a statement.

“Our founder, Phineas Q. Widget, III, created the first prototype for WidgeCo during a 72-hour Mt. Dew-fueled bender in his garage. He started two fires and collapsed in a heap of ecstasy when he first saw it function properly.” That’s a story. Your customer can identify with that. Turn your brand into a serial novel and people will see you as a friend instead of just a commodity.

Social media can help you stretch your advertising dollar
Social networks know a ton about their users. Web sites have this uncanny way of harvesting data about their likes and dislikes, their hopes and dreams as well as pictures of what they’re having for dinner.

Instead of placing an ad in the local paper might be seen by some of the people who might possibly be slightly interested in what you’re selling, you can place a Facebook Ad that is served only to men from age 18-24 who have “liked” the band Mastodon and the movie Napoleon Dynamite.

Now that’s some serious targeting.

Hop to it, the metrics will come
Just as people lagged in seeing the value of the Web and email as business technologies (ever work at a company where not all employees had email accounts?), so do they lag on social media. Just as metrics evolved with those technologies, so will they evolve with social.

That said, there are already lots of things you can measure with social media. Tracking codes on links that are specific purchasing calls-to-action can be easily consumed by web analytics packages. There, you’ve got some ROI. Just be careful. Don’t go all Kenny Tarmac and turn your Facebook page into some kind of full-court press hard-sell smarm-a-palooza. Remember you’re telling a story, not selling.

Facebook gives you some great measures of how many people are engaging with your page, all the way down to what kind of content is most viral. Check out Facebook’s insights immediately, if not sooner.

YouTube, Twitter and LinkedIn all have some sort of reporting that you can combine with some clever web analytics work to paint a picture of your progress.

So don’t use the lack of hyper-sophisticated ROI black boxes for social media as an excuse to ignore social media. Get out there and tell your story, your customer is waiting. 

Pep Tse, master of the ancient art of product placement

This is a post about Gurus, with a capital G. They have books, they have accessories and they have the answer to everything. If they’re a big enough Guru, they can become a lifestyle choice in and of themselves. They will sell and resell their “5 Secrets to Better Pancakes” or “12 Simple Steps to a Nutmeg-Free Life”.

But the real secret is that there are no secrets. The Guru makes money off those who want to buy a book instead of doing the work.

If you ever find yourself in a position where you think the only thing standing between you and your dreams is writing a check to a “Guru” to unlock the secrets of the universe, do yourself a favor and don’t. Save your money. Remember that success is very closely bound to hard work and is accelerated by God-given talent. A positive attitude is also a nice-to-have.

Chris Brogan talks about being an overnight success. It only took about ten years of non-stop speaking, blogging, writing, networking and entrepreneurship. Chris is no “Guru”, he’s a smart, humble, hard-working guy. It’s a grind. So you better love what you do, and you have to be willing to do it and do it a lot.

Remember that the mighty Beatles started as a gig band a the Cavern in Hamburg. From 1961 to 1963 The Beatles made 292 appearances there (see Wikipedia). So instead of climbing the mountain to find your guru, find yourself a cavern. Go hone your talent, eventually people will seek you out.