From the category archives:


I told a lot of people that I was going to stay out of the diversity discussion. However I couldn’t sleep last night because something was bothering me.

One of the memes when I joined the Ruby Community was “MINASWAN.” It means “Matz is nice and so we are nice.” Honestly, I think Matz smiles even when he’s asleep or using the bathroom. Unfortunately, sometimes I wonder if we forget that our community was built on the idea that we are kind and accepting to everyone in our community.

Most of us think about MINASWAN with regards to new programmers or programmers new to the language. I’m afraid sometimes we forget that it applies to everyone in the community.

The ideals of MINASWAN are mutual respect, helpfulness, and acceptance. We do very well with this when dealing with most members of the community because we mostly agree and frankly it’s not that hard.

Where I think we fail at this is when we want to make a point, we’re right, and we let that take precedence over being nice.

Let’s take the current situation with the discussion over diversity. MINASWAN clearly encompasses diversity. It’s doesn’t differentiate based upon sex or race and neither should we. So, in a sense, the folks pushing for more diversity are in fact working for a subset of what MINASWAN means.

The problem is that their response was not always in keeping with MINASWAN. Pointing out the problem so someone can fix it is the lowest level of what MINASWAN means. And only if it’s done in a respectful and accepting way.

I don’t think the initial commentary on BritRuby’s lineup was intended to be disrespectful or mean. However, I’ve found that many things on the internet get interpreted in the harshest way regardless of intent. So, if we’re going to be nice on Twitter, we need to be careful.

What MINASWAN means in the larger sense is: Just as we help “noobs” come into the community, we should help everyone. An all white-male lineup at BritRuby was a consequence of the organizers not knowing how to encourage a diverse speaker base to come speak. If we were to help them like we help new people coming to the community, then the experts in diversifying a conference should have stepped up and offered to make introductions and to show them how to reach out.

Some of the consequences I’m afraid we’ll see are that this will damage our conferences by increasing the risk or perceived risk of putting on a conference. That attendance will be hurt by this same sort of thing happening to their conference resulting in their losing money and effort. Or that they may decide to preemptively call the whole things off.

I also worry that some of the brilliant minority speakers we have in this community will feel that they got to speak because of their sex or race rather than because they were the right PEOPLE for the conference and because they are amazing programmers and great speakers.

If there’s any way we can pull together and be constructive about these issues, we have a responsibility to do it. A total win for the community would be that BritRuby be reinstated and that the organizers get a little help in finding the diversity they lack. An epic win would be that other conferences and community members gain the resources and know-how to promote diversity in their efforts without being afraid that they’ll get punched in the nose for trying to give back.

No one should feel singled out by this. It’s a general feeling that I’ve observed over the last day or so that needed to be addressed.


So, I uninstalled macports from my machine and in the process removed the libjpeg.7.dylib file that I needed to make rmagick work. When I tried installing it with homebrew, it got version 8, rather than version 7, so the libjpeg.8.dylib file was there. Rmagick didn’t recognize it.

What I wound up doing was downloading the source code (which is impossible to find, so go here) and running the standard commands for installing a new library.

cd jpeg
make install

So, if you get an error saying that it can’t find libjpeg.7.dylib, just follow those instructions and you should be set.

{ 1 comment }

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.


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 }

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.


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.


I’ve recently been working on cleaning up the code and fixing some of its issues. One of the problems that is more of a business problem than a problem that the users would see was that a lot of spammers were shortening URLs through the service.

So, one layer of new security in going into place is integration with Project Honeypot’s HTTP:BL API. Now, identifying spammers doesn’t necessarily belong is the “core” of a URL shortener. And, other people may want to integrate this into their own sites to block spammers from commenting on their blogs, using their services, or any number of other things. So, I’ve put the gem up on

You can also check out the source code here.

If you want to use the gem, go to and sign up for an account. That will get you an API key for the service. Then you can install the gem:

gem install project-honeypot

And then do a lookup call:

ProjectHoneypot.lookup("myapikey", "")

You’ll get back a Url object that gives you information about the ip address. You can get more information on what this looks like in the README on the Github page.


I got an email from someone who enjoys Teach Me To Code. He was having a problem getting gems. Anytime he tried to install a new gem, he was getting this response:

ERROR:  While executing gem ... (Gem::RemoteSourceException)
    HTTP Response 302 fetching

I told him to try running ‘gem update –system’ which will update RubyGems itself. He did and got the same error.

He told me then that he was running RubyGems 1.0.1. Aha! That’s the problem. If you’re running into this problem, here’s what you do:

  1. Go to
  2. Download the RubyGems .zip or .tar.gz file
  3. Unzip or untar the file you just downloaded
  4. Change directories to the directory created by unzipping or untarring
  5. Run ‘ruby setup.rb’

It will build RubyGems from scratch and replace your ‘gem’ executable. Then ‘gem’ will connect to and pull the gem libraries in properly.


Hey, do you like books from the Pragmatic Programmers? Do you like Peepcode videos? So do I!

Here’s the deal. I’ve set up a survey at Anyone who takes the survey will be entered to win 1 of 5 Pragmatic Programmers books/videos and 1 of 5 Peepcode videos.

So, if you want a chance at a free video or book, then go to and take the survey. I really appreciate the feedback.


I was setting up a new project/gem that interfaces with Project Honeypot. While I was setting it up, I ran into a couple of problems running my specs. The first one, I hit this error while running ‘bundle exec spec spec’:

/usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/shared_helpers.rb:137:in `bin_path': can't find executable spec (Gem::Exception)
	from /usr/local/bin/spec:19

What this means is that the spec gem doesn’t have an executable called ‘spec.’ This confused me since all of the previous versions had been run with a ‘spec’ command. As it turns out, in RSpec 2.0.x, the command to run your specs is ‘rspec,’ not ‘spec.’ So a ‘bundle exec rspec spec’ got around that error.

The next issue I got was an undefined constant error for ‘Spec::Runner.’ Here is my spec_helper where I was referencing Spec::Runner.

require "rubygems"
require "bundler/setup"
require "rspec"
require "flexmock"
require File.dirname(__FILE__) + "/../lib/project_honeypot"

Spec::Runner.configure do |config|
  config.mock_with :flexmock

So, RSpec has changed the configuration setup to use RSpec instead of Spec::Runner and it worked like a charm.

You can check out the respository I was working in at