From the monthly archives:

January 2011

A few weeks ago I was looking at Peter Cooper’s Ruby course and wound up proposing a Basic Ruby on Rails course. Interestingly enough, I’ve been named the instructor for the course.

I’ve been working on the curriculum, what I want to teach and what to include to help people pick it up. Of course, it’s always interesting both in applications and other areas like this one to figure out what is essential and what can be omitted. The obvious inclusions are explaining MVC, and demonstrating Models, Views, and Controllers. I also feel like testing is essential and several tools that are either included with Rails or help in building it.

I’ve been using MindMeister (affiliate link) to organize my thoughts. I’ve broken the curriculum up over 6 weeks to basically include the following:

  1. Rails Structure, Setup, and Tools
  2. Rails Views
  3. Rails Controllers
  4. Rails Models
  5. Extending Rails
  6. Testing Rails

If there are things you would like to learn that don’t appear to be included in this curriculum, please email me and let me know.


This week’s podcast guest is Evan Light. I met Evan at the Ruby|Web Conference at Snowbird. He’s responsible for Coulda and the Ruby DCamp.

Evan recommended Get Clients Now!(TM): A 28-Day Marketing Program for Professionals, Consultants, and Coaches (affiliate link) for marketing as a freelancer.

We talked about organizing a conference and what it takes.

He also had some great suggestions for people thinking about switching to freelance.

I also found his discussion of why he wrote Coulda very interesting. It inspires me to think that if I want something different, I can create it.

If you’re looking for a way to increase readability of your code, look at flog or metric_fu.

Jake Scruggs’ talk at Lone Star Ruby Conference 2008

Next month I’ll be teaching a Basic Ruby on Rails course. Go check it out and sign up.

Download this Episode

{ 1 comment }

What is HAML?

HAML is a markup language. It’s specifically designed to replace the HTML + ERB combination typically used in Ruby applications to render web pages.

Why I like HAML

HAML is nice for several reasons, all revolving around how its files are structured.

First, it’s indentation driven. I have run into a few issues with indentation, but for the most part, it’s pretty clear which parts of the page are within other parts of the page. I’ve never been a fan of whitespace delimited code, but in this case, it’s kind of nice.

Second, adding a class or id to an element on your page is as simple as #id or .class rather than class=”class” or id=”id”. It’s not just about saving typing. I actually find it easier to read.

Third, HAML includes SASS. SASS, or syntactically awesome stylesheets, give you a lot of features like storing your colors, sizes, and other common settings in variables, nesting styles, and inheritance. This saves you a TON of copying and pasting in your stylesheets. You can say $chadfowlerpink instead of #993366. (Click here if you’re wondering about Chad Fowler pink.)

Finally, you don’t have to declare your div tags. This is particularly useful because most layout these days is done using div tags and css attached to your classes and ids. So, instead of <div class=”…”> all over the place, you see .class1.class2.class3#id.

Sounds Great! Why Wouldn’t I Use It?

HAML use really boils down to the people involved. I’ve worked with several designers who work very well in HTML and CSS. I’ve also worked with several developer who have never programmed with HAML. These are the two types of people you need to consider when choosing HAML. Collaborators and maintainers.

Is it worth forcing collaborators like designers to undergo the learning curve to learn to use HAML? HAML comes with an HTML converter. Is it worth the extra step if they’re not going to learn HAML? Weighing the collaborators’ learning curve against the increase in productivity you’re likely to see as a developer is worth considering.

As for maintainers, keep in mind that you’re not likely to be the programmer building this project forever. Are you making it more difficult for your employer or client to find someone who can pick up their application and continue to work on it? Are you adding to the training required for new employees? (I don’t find this to be too much of a problem with new developers.)

HAML doesn’t have a steep learning curve, so in most cases, using it is worth it. But these are questions to keep in mind.

Where do I get HAML?

You can find out more about HAML at To install it, just
gem install haml

{ 1 comment }

Because I’m going to be testing in cucumber sections of the site that require a user to be logged in, I decided to get it out of the way. So, in this video, I write a cucumber feature to test login and round it off with a few tests on the devise generated user model to make sure it continues to behave as I expect it to as I update it throughout the process of building this application.

Download 191.8 MB
Download (iPhone & iPod) 87.2 MB


I’ve been working on several applications where I’ve needed not only to verify that someone was logged in, but actually make sure that someone had permission to modify a particular object. There are several authentication solutions out there. I’ve actually listed 9 of them in this post.

I’m going to add one that I’ve picked up lately. It’s called Devise. I’m actually really enjoying it and liking a lot of the options that it offers. I still haven’t figured it all out, but it extends your rails application and manages your sign up, sign in, and sign off functionality. I’ll probably put up a screencast on it soon. So, stay posted.

The part that I’m really excited about, though, is CanCan. I’ve built complicated permissions systems before. Some were role based, others permissions based (possibly containing roles). I would place the role and permission checks into the controllers and manage the rights the user exercised that way. The problem was that I found myself repeating a LOT of code.

That’s what I like about CanCan. It provides a before filter for your controllers that saves you all of that code. The best thing about that is that your permissions are all defined in one place (/app/models/ability.rb) so if you need to give someone access to a particular resource in your application, you just set it up there and it’s propagated to the rest of your application. Trust Ryan Bates to come up with something simple and awesome like that.


Michael Hartl put together a free rails tutorial online. We met at RubyConf and determined to talk about his tutorials. His path into Rails development has been interesting to listen to. Similarly, his thoughts on business are inspiring.

We talked about a great way to support Teach Me To Code. And that is by purchasing his videos and book here.

I don’t usually promote products, but I think this one is a terrific one and I hate asking for money in return for nothing, so in this case you get some great videos and a book!

Download this episode


I’ve had a few people ask me what my workflow is when programming. Specifically, they’re usually interested in TDD or BDD (Test Driven and Behavior Driven Development) as it is applied to Ruby on Rails.

So, here’s my approach to testing Rails. It’s pretty simple. Unit test your models. Integration test everything else.

No Controller Unit Tests?

In Ruby on Rails, you should be writing skinny Controllers. With skinny controllers, your actions should generally be either gathering information or manipulating data through the Model. This implies that most of your complicated logic should be in your Models. So, test your Models. If you have complicated logic in a Controller, you should consider which Model to move it to before you consider whether or not to test it.

You can test whether you’re getting the right data in integration tests. Otherwise, you wind up mocking out the Model, which may or may not accurately represent what you get from the database.

No View Unit Tests?

In testing Views, there are two things you could be concerned about. Layout and data. In my opinion, layout is best tested by visual inspection. That leaves data, which can and should be tested through integration tests.

You should not have complicated logic in the views.

Integration Tests

Integration tests represent a great way to make sure that there is nothing wrong in your Controller and View. Ultimately what you’re looking for in the integration tests is that the data in your database is properly displayed. This is more in the realm of BDD, where you check to make sure that the application shows the right data at the right time.

I’m still working out the javascript portion of this. One application I’ve been working on has a lot AJAX in it. The tool I’ve been using (Cucumber) doesn’t do javascript out of the box, so I’m still figuring that out. But still, even from that point of view, I can still manipulate the API designed for AJAX calls and verify the results.


Here is what I’ve done to create this application:

  1. Use the ‘rails new’ command to create a rails application
  2. Set up the Gemfile
  3. Configure the Database
  4. Install Cucumber
  5. Install Rspec
  6. Install Devise
  7. Install CanCan
  8. Install jQuery
  9. Configure Devise

Download (HD) 84.2 MB
Download (iPod & iPhone) 47.4 MB


So, between family stuff, more work than I can realistically handle, and being sick, I’m afraid I fell behind on the podcast. However, not to worry, I have big plans for 2011 including dedicating a full day to getting all of the podcasts, screencasts, blog posts, and other stuff out the door and into your hands. So, if you’re looking for details or an explanation, then listen to this episode.

Download this Episode