GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Internbot Chronicles #5: Training Reflections

2009-06-25T15:49:00Z

Last week I sat in on the Training class we held here at the Boston office. I haven’t considered Ruby or Rails from the point of a greenhorn in a few years, and helping the students learn about both opened my eyes quite a bit to some aspects of our language and framework of choice here at Thoughtbot.

Ruby is natural, not simple.

This is paraphrased one of my now favorite Matz quotes. Watching others learn about Ruby for the first time was a lot of fun, because usually they were astounded to find out that what they used to do was just so…simple. Of course, under the hood, Ruby is exactly the opposite, but that’s the beauty of it. Scott Hanselman explains it best by showing a great example of using Ruby DSLs such as 20.minutes.ago instead of the more verbose Java equivalent new Date(new Date().getTime() - 20 * 60 * 1000). He ends up concluding:

That was a perfect way to describe __, and there’s no ambiguity.

This aspect of Ruby has stuck with me since I first tried to dive through the Pickaxe. However, it didn’t really work out that nicely: I learned Rails first, and Ruby along the way. Having a basic understanding of Ruby, especially with how blocks and the yield keyword works can go a long way. The best part is that given a bottom-up approach, it’s easy to see how the expressiveness of Ruby fits perfectly into Rails.

Rails isn’t full of black magic.

Without a good understanding of Ruby, it’s easy to think that this is the case. ActiveRecord can seem like a bag of tricks dumped on top of your precious database, and don’t even get me started with some of the ActionView helpers. One of the best parts of the training was when we hooked up a form, and used error_messages_for to show the validation errors. Watching the students’ eyes light up with understanding how that all came together was fantastic, but it did seem like “witchcraft” to a few.

Granted, there is a lot of metaprogramming going on in Rails, but I feel the more Ruby one understands, the less “magical” it seems. Learning Ruby first is the best way to go, especially since it allows one to dive easily into the latest and greatest projects, such as Cucumber or Sinatra.

Someone’s already done this before.

Convention over configuration here is key: not having to understand some cryptic XML file to set up your database or the application as a whole is a huge win. Using pure Ruby for migrations is just one example of how Rails makes web development easier. Staying on the “golden path” is a huge part of Rails, and you can usually bet that someone has solved the problem you’re facing before. Looking for the solution inside the framework or outside for a well-tested and maintained plugin before you steam ahead with your own implementation is always a smart idea. I definitely have been to blame for this: I began writing my own Prototype implementation of periodically_call_remote before getting called out on it.

One of the big lessons that I took away from training was that we really do depend on the community for most of our tools: Capistrano, Git, Prawn ...the list goes on and on. If you’re not looking to community for your solutions in the Ruby world or are not aware of what’s available, you’re missing out. Keeping in touch with what’s new is tough, but luckily there’s a few sites that make it really easy for you to do so.

Overall, training was a lot of fun. Over the course of three days we went from playing around with Ruby objects in irb, whipping together a simple Rails site, to deploying it live on Heroku. Going back to the basics was definitely eye opening, and it was a good reminder that I should trudge through the Pickaxe for Ruby 1.9 as soon as possible.

We've got several positions open (Developers, Designers, and Intern)

2009-06-11T20:27:00Z

I just wanted to take a moment to remind everyone that we still have several positions open at thoughtbot.

We’re looking to hire up to 2 web designers, preferably one in Boston and one in NYC, and up to 3 developers in Boston.

Also, this summer, we’ve had Nick Quaranto in as a development intern, and he’s worked out so well that we’d like to get another, so we’re opening the internship position back up to find another.

All positions include relocation expenses as part of the benefits. You can read more about these positions on our jobs page.

Our team works in a relaxed and educational environment. We use the latest web development technologies, and embrace both agile development methodologies and a “getting real” project philosophy. We limit our work weeks to 40 hours, stock the fridge with free drinks, and provide lunch on Fridays.

We believe in goal-driven business development (we want to understand what’s valuable to clients before we begin), design-driven product development (we want to know what a product will look like and how it will work before we start building it) and test-driven software development (we want to ensure ongoing quality and a successful post-launch existence for the applications we build).

If you are interested, contact us at resumes@thoughtbot.com.

Boston neighborhood guide for tasteful Rubyists & designers

2009-06-06T19:00:00Z

I have a friend from another city who is considering a Ruby job in Boston. He asked me for advice on places to live.

Since we’re currently in the midst of hiring designers & developers & many candidates have been from other areas (we require that they move to Boston or New York), I thought I’d share publicly.

Opinions

If you’re a Rubyist or a designer, you’ve already got taste. The following neighborhoods are what I personally consider the nicest, most intellectually stimulating, aesthetically pleasing, or funkiest neighborhoods.

This is by no means comprehensive but that’s partly the point. Moving is stressful & keeping options limited lightens the mental burden.

Cost of living

Boston rent is not for the faint of heart. Expect to pay between $750-$1,250/month for a clean apartment close to Boston. You should be able to knock it down to $500/month if you share a bedroom with someone or live in Jamaica Plain.

However, average salary, and more importantly, the quality of life are also high.

Cambridge

I’ve mostly lived in Cambridge over the last 5 years so let’s start here. The Wikipedia entry hits the high points of Cambridge culture: Harvard University, MIT, the Charles River, & The Red Line.

The blue line encompasses the sections of Cambridge I’d recommend: most of Cambridge except areas that are more industrial or North Cambridge, which is just a little too far from downtown Boston for my tastes.

I put three pushpins in Boston for reference: Fenway Park, the Prudential Center, & Park Street at Boston Common (where the thoughtbot office is located).

If, like my friend, you’re not working downtown, but instead in Watertown, Waltham, Somerville, Medford, or Charlestown, I’d strongly recommend Cambridge.

Brookline

Again, the Wikipedia entry will give you the best overview of the town & it’s culture: John F. Kennedy, The Country Club, & The Green Line.

This is an area I’d recommend for people with kids. Quiet, safe, & great schools. It’s close to Waltham, Watertown, & the Mass Pike if you’re working out along Route 128. It’s also extremely convenient if you’re working in the Longwood area (I believe there are a number of hospitals & universities over there hiring Rubyists).

Within Brookline, Coolidge Corner & Washington Square are the two areas I would focus on. They’re both right on the Green Line along Beacon Street & have plenty of things worth walking to.

Jamaica Plain

Wikipedia calls Jamaica Plain The Eden of America. I can see that.

This is where you want to be if you’re a park lover or a real artist. The population is extremely diverse demographically. The Milky Way Lounge (Latin dance nights), JP Licks (ice cream), & Doyle’s Cafe (oldest Irish pub in Boston, longtime evening hangout for the city’s Irish politicians) are iconic institutions.

The area I’d recommend is bounded by the Orange Line on the right, the ponds on the left, and is split by Centre Street, which is filled with attractive cafes, galleries, restaurants & shops.

South End

Scan through the Wikipedia entry then take a walk through the area. If you’re not touched by the signature brick architecture of Boston that is prevalent in the South End, you have no heart. You’re probably a vampire. Might want to get that checked out.

The South End is known as a gay & artistic neighborhood. Tremont Street may have the greatest concentration of “Saturday night date restaurants” in the city. Unbelievable food over there. Lots of theaters, lots of music, lots of visual arts.

I’ve bounded the South End by some major streets.

It’s a tricking balancing act of trying to live in the South End, however. The closer you are to Copley, the closer you are to some of the highest rent areas of Boston. The closer to Washington Street, the further you are from all subway lines & the closer you are to some higher crime areas. Like any city, however, often the best places to live are on the edge of gentrification of former combat zones.

For the venture capitalists…

It wouldn’t be tour through Boston’s neighborhoods if I didn’t point out the Back Bay, Beacon Hill, & the North End.

These are all awesome neighborhoods that are out of the price range of most individuals unless you’re the kind of person who likes to fund Twitter or knock home runs out of Fenway Park.

Documentation Demolition Derby

2009-06-04T17:28:00Z

Who doesn’t love cars crashing into other cars? And freshly generated documentation? Well, now you can get both. Or maybe just documentation. We’ve moved our open source projects’ documentation onto RDoc.info, which uses YARD and some GitHub post-receive hooks to make sure it’s always up to date. Update your bookmarks, delicious links, cheat sheets, wikis, what have you:

Shoulda

Paperclip

Factory Girl

Internbot Chronicles #4: CI & Test Metrics

2009-05-29T16:12:00Z

Inspired by some of the great talks at RailsConf 2009 such as Automated Code Quality Checking in Ruby on Rails along with Using metric_fu to Make Your Rails Code Better, this Internbot was recently tasked with getting a similar system working for the open source projects and Rails client sites that live in the Thoughtbot ecosystem.

The first step of this process was to get a new CI server up an running. Thoughtbot was using CruiseControl.rb and RunCodeRun previously, but both had fallen out of use recently. I had some experience with setting up Integrity, which is a much easier to use system. Adding a new project is dead simple: plug in your project’s Git URL, give it a build script to run (usually just rake) and boom, you’ve got CI. Integrity also supports post-receive hooks, so when we push commits GitHub tells Integrity to grab the latest changes and get testing. We also make use of the Campfire hook to let us know the results of the build.

It was easy to get Integrity itself running, but getting the tests passing for all of our projects was no simple task. Here’s some of the gotchas that I ran into that might help you out if you’re putting together your own CI server:

Make sure your Rails apps’ database tables exist. In hindsight, simply running rake db:create:all would have done the trick.
Use a Linux distro with an up-to-date version of Ruby that’s easily available. We settled on Ubuntu 8.10 with Ruby 1.8.7 patchlevel 72.
The build script can take any system command, so use it for setting up your test environment if necessary.
Builds don’t run in the background, so switch them to a different port if you want to be able to view your projects while builds are running.

Check out our build server at http://ci.thoughtbot.com if you want to see the status of our projects.

Next up was getting some metrics generated. The metric_fu project does a great job of this: with just one rake task, you can summon stats from Flay, Flog, RCov, Roodi, Reek, and more. That’s decent for one project, but for nearly 20 it doesn’t work so well. I ended up hacking a script together that does the following for each project that lives in the Integrity database:

Runs metric_fu to generate stats
Compares the last run to the current one to see if there’s any difference
Alerts Campfire using Tinder if there’s changes
Logs the run in a Google Spreadsheet using google-spreadsheet-ruby

So around 4 times daily we get updates as to how <s>bad</s> good our code is, and eventually we’ll start seeing some trends in the spreadsheets. I also hacked a custom template based on Integrity’s layout so it’s easier to browse the metrics, which is available in my fork. The next step is to integrate the tools into the Integrity build script, which we’re still in the process of deciding what factors will determine a failure.

The metrics are up and available at http://metrics.thoughtbot.com if you’d like to browse around.

Both of these projects have been a lot of fun to work on. So far there’s no penalties for breaking the build, but there are plenty of NERF guns around the office if we feel the need for retaliation. The Reek and Roodi metrics results have been quite enlightening and they seem to give great suggestions for refactoring. As for the trends, perhaps I’ll report back in a future edition of the Chronicles on the progress!

Ten days of Thunder Thimble

2009-05-26T21:49:00Z

Since last weeks launch of Thunder Thimble we’ve received some great feedback from early users. Thanks to everyone who checked this out. We’ve deployed a few interesting changes since then, as well.

Bug fixes

There were times during a search update where one brand’s search having any issues (ie, it was an invalid search, or twitter was down, or twitter responded with an unexpected response, or there was a network timeout, etc) could have lead to subsequent searches not being updated. If you created an account in the first ~24 hours or so after launch and then didn’t see any results for a while, this is probably what was happening. We’ve added every error that’s occurred so far to the updating task, and we continue to add the new ones as they happen (thanks to Hoptoad for some nice logging). So, if this is you and you gave up right away, you might want to check back for new results today.

If you STILL aren’t seeing any results but think you should be, contact us via twitter @thunderthimble, or via the getsatisfaction help site.

UI changes

Early last week we deployed a UI change to the “global dashboard” and “brand dashboard” views within the application. This change brought the “positive”, “negative” and “ignore” UI elements closer to the user, and now requires less back and forth between a “deep” page and the dashboard to do these common actions. It’s also easier to see recent trends and latest activity at a quick glance with this change.

New feature – tweet from the application

When we launched, you could send a twitter REPLY to a message we found for you with the monitoring service, but you could not initiate a tweet directly from Thunder Thimble itself. From our own internal use of the product, this was the one thing that we kept expecting to be able to do and finding we couldn’t (yes, we are surprised by the lack of features even in things we built!).

As of today, you can use the “Post a new Twitter update” link from the brand dashboard page to initiate a tweet as any account you have hooked up to TT (at the account, brand and user levels, that is). We default to the brand you’re on, but allow you to change that prior to sending. You can also use the backtick key — ` — as a keyboard shortcut to access this feature from anywhere in the application.

Fluid.app icon

For users of Fluid we have a 512×512 PNG file for you here which is guaranteed to look awesome in your OS X dock. This icon should be picked up automatically when you setup your fluid application for Thunder Thimble.

10 reasons you should be listening to the Rails Envy Podcast

2009-05-18T19:36:00Z

As sports fans go, we’ve been very lucky over the past few years in Boston. The Red Sox, Patriots, & Celtics have all won championships.

To me, the best part about having competitive teams from your city is the extra entertainment it gives you for weeks or even months. Each round your team advances is exciting and it gives you something to talk about with your friends. The city takes on a certain buzz on game days, and you see lots of people wearing the team’s colors.

Another thing I enjoy about the playoffs is “mayoral bets”. For example, during the Super Bowl two years ago, New York and Boston were competing. The mayors from each city made a gentleman’s bet:

If the Patriots win, that means Bloomberg will send a delivery to Boston that includes Manhattan clam chowder, pastrami sandwiches, New York pizzas, black and white cookies, New York steaks and a few gallons of lemon ice. And if the Giants claim victory, Menino will send a package with New England Clam Chowder, Dunkin’ Donuts coffee, Boston cream pies, chicken sausages and Brigham’s ice cream.

I don’t know who gets to feast on the spoils, but in the same spirit, thoughtbot and Rails Envy made a bet while at Railsconf in Vegas for the Boston Celtics-Orlando Magic series.

The terms were simple: if the team from your city wins, highlight the other company’s work in your favorite medium. For us, that’s the Giant Robots blog, and for Rails Envy, it’s the Rails Envy podcast.

Unfortunately, Boston’s title defense ended last night as Orlando won the series, taking our dream of having an entire rails envy podcast dedicated solely to thoughtbot down with it. So, without further ado, I present to you the Top 10 reasons you should be listening to the Rails Envy podcast.

10

The production value is far above the usual internet fare, and even some Hollywood fare.

9

Their ability to mangle the names of Rails developers fills a gaping void left by former President Bush. Laughing at people mis-speak is as natural as laughing at a football to the groin.

8

They’re like the Meet the Press of the Rails world: once a week, they hit you in the face with the best Rails knowledge you can find anywhere.

7

They put their money where their mouth is and have the guts to bet on sporting events with other members of the community.

6

They always include a few things on bleeding edge, such as Tokyo Cabinet in their latest podcast.

5

They read RSS and Twitter so you don’t have to, leaving you plenty of time to do neck exercises, increasing the blood to your brain.

4

No fluff, just stuff. They don’t “report” on the drama in the Rails community. Look through their show notes. It’s all practical information that you can use as a Rails developer. If there’s a technical reason to care, they deliver a level-headed analysis (example: Ruby v. Scala in Episode #75).

3

Much like their city’s basketball players, they are both a frightening seven feet tall. Thank god they mostly work in audio.

2

They frequently highlight thoughtbot’s stuff and came up with an amazing “Giant Robots Smashing into Other Giant Robots” (CRASH!) sound.

1

Gregg and Jason are both guys that seem to really enjoy what they’re doing. They clearly care about the community in both professional and social aspects, and are consistently giving talks, presenting at conferences, etc.

Product Launch: Thunder Thimble

2009-05-15T20:16:00Z

We’re pleased to announce the launch of our next product — which is a web based product called Thunder Thimble.

For regular readers, yes – this is the same application whose initial prototype was mentioned here in how we accidentally redesigned a product in a week.

Overview

Thunder Thimble is a web based application meant for monitoring and managing mentions of your products, services, brands in “social media”. For now, this means twitter support only. In the future, we may add blogs, news, videos, facebook, etc – or even more “mainstream” web content, but the intention is really to monitor “current” topics and trends as opposed to all time mentions, and twitter makes the most sense for this right now.

Use case

At thoughtbot, we have four areas of operation. First, our consulting service, which is the core of our business and for which “thoughtbot” is really the only brand name involved. Second, our products like WidgetFinger and Hoptoad and TeeBot. Third, our “fun” projects like Umbrella Today and Stock Names. Finally, our open source projects like Shoulda, Paperclip, Factory Girl, Squirrel, etc.

Whether it’s to send us praise or complaints, comments or questions – we really love hearing from people about our work. The common problem we faced monitoring and responding to all of this feedback was that we had a plethora of twitter accounts, support address, contact forms, and so on – and we had different people (with no real official responsibility to do so) attempting to manage all of that.

We would also have a “feeling” that – for example – Hoptoad was getting mostly positive feedback on twitter, but we had never really had any hard metrics to back that up. We’ve been using the Thunder Thimble application ourselves for two months now, and it solves basically all of those problems.

Features

Now we have a scenario where…

Multiple people from thoughtbot constantly monitor each of our brands (we have rss support for mentions within a brand and across the entire account – this replaces google alerts and twitter search for many of us)
We can flag tweets as positive or negative, and see trends over time in a handsome line graph
We can embed a javascript widget in a website, which shows recent positively rated tweets
We can reply to messages directly from the tool itself
We can reply from the relevant account (business, product, personal) depending on the message we’re replying to
We can even enter competitor or complimentor brands, and respond to mentions of those if needed

Recent brand activity

Free plans

You can sign up today and check out the product – there’s a even a FREE plan so that you can take it on a trial run for 30 days before you commit to a paid account.

Feedback

Thanks to our beta testers for feedback during the last month or so – we think have a tool that’s at least more valuable than not using it, and we’ve got big plans for the coming months as well!

We’ve got a getsatisfaction account set up to handle feedback and feature requests, so let us know what you think. We look forward to continue expanding the product in the future.

RailsConf 2009 Wrapup

2009-05-12T20:39:00Z

Now that the fun and games are over and the Rails world is returning to work, this is a great time to appreciate some of the wisdom that was imparted to us last week during RailsConf. We’d also like to thank those who showed up for the Poker Tournament and made it a great time for all.

If you missed the conference, be sure to check out the keynotes at blip.tv and also my expansive set of notes on the talks I attended.

Now, the tiny robots have some reflections on what they’ve learned and would like to share:

Nick

One of my favorite talks was Scott Chacon’s Smacking Git Around. It was a great source of information for those new to Git and those who have been using it for a while. Also, Rack has seriously arrived in the Ruby world and is pretty much essential to learn.

Matt

You’ll think I’m kidding, because of this, but the Tim Ferriss keynote (fireside chat?) was probably the best part of RailsConf. Please understand that I do 600 pushups on the roof top of my apartment building every morning at 3:30AM though, so your mileage may vary. I also change my own oil in my car—which has a quarter million miles on it and still runs like a champ.

Jon

Uncle Bob’s keynote was one of the best keynotes I’ve heard at a RailsConf. While he was preaching to the choir a bit about TDD, it needed to be said. Plus the idea that not only is professionalism important, but it’s not the stodgy three-piece-suit some people seem to think it is, is a meme that needs circulating.

In that light, Ezra’s talk (partially) about automated and verifiable server deployments as well as Marty Andrew’s talk about automated code quality metrics spoke a bit more to me than they probably would have (although they would have been interesting on their own, regardless!)

Of course, nothing will top Eric Torrey’s explanation of why fixing the problem at its root is better than temporary fixes:

Jason

My favorite three things that I learned about at RailsConf were learning how to monitor and manage distributed computational tasks using Amazon Web Services with Matt Wood’s Mission Control, using FunFX to test your Flash (and Flex) applications with Cucumber, and running Rack apps on Google AppEngine with some helpful related tools.

Mike

The most interesting talk for me was the What Makes Ruby Go: An Implementation Primer talk, where we learned how Object#extend can kill your method cache and just how slow global constants really are. Other highlights include seeing the toad from Hoptoad on the big screen while I learned about the ins-and-outs of using Rack in Rails, and seeing all the people I only get to see at Rails conferences.

Chad

As mentioned above, Rack is where its at, and it will continue to enable a lot of coolness in Rails. One of the best talks I’ve seen on Rack, at any conference, was And the Greatest of These Is … Rack Support, by Ben Scofield. A lot of the Rack talks I’ve seen have been rather abstract to date. Things have started to clearly started to gel with Rack, and Ben was able to give an excellent, concise overview of the current capabilities of Rack support in Rails, and some ways in which it can be used.

Joe

I enjoyed Automated Code Quality Checking In Ruby And Rails – it gave us the kick we needed to add code quality tools to our CI process. I also found out about some tools (like “Roodi”) that I had never heard of before. As usual, though, my favorite part was being able to discuss code with the author in person, as well as getting to see some of the people in our community that I only see at conferences.

Vanquish thoughtbot at the poker table

2009-05-06T22:30:00Z

“If you even dream of beating me you’d better wake up and apologize.” – Muhammed Ali

Not since the Thrilla in Manila has there been a contest so hyped, with so much on the line. This is bound to be the most remarkable, exceptional event in Vegas all year.

Of course I refer to…

The 2009 Railsconf Poker Tournament

We’re pleased to announce a no-limit Texas Hold ‘Em poker tournament tomorrow night (Thursday) at 9pm at The Poker Room at Caesar’s Palace.

The buy-in is $65. Caesar’s takes $15 from each person to set everything up for us. We’ll have our own dealers, and the casino handles everything.

Winner takes the rest.

Internbot Chronicles #3

2009-04-24T16:04:00Z

Now that testing is a normal part of my daily workflow, I think it’s a great time to go over some of the testing tools that I use here at thoughtbot.

Shoulda

Typing too much makes testing no fun at all. I’m actually coming from the RSpec world, and thankfully it was pretty easy to switch over to Shoulda from it. Here’s what I like best about it:

context and setup blocks makes testing ridiculously simple and DRY.
before_should: Basically, you can set up expectations with your favorite mocking framework in these blocks, which run before the setup block in the given context.
Macros that just save tons of time. Simple ones like should_redirect_to are actions that need to be tested all the time, and luckily there’s a whole suite of them for both ActiveRecord and ActionController.
Custom macros that can be easily dropped in to test the same actions in multiple places. I do miss RSpec’s it_should_behave_like though, but this works decently.

Mocha

The concept of mocking and stubbing in general is somewhat new to me, and it’s definitely been difficult to learn how to use effectively. It’s starting to become natural though, and I don’t mind the speedup that testing in isolation gives. The majority of our projects use Mocha, which does the job just fine. I’ve also been looking into RR, which has a much cleaner syntax and some additional features, but usually my daily mocking is done with Mocha. The most important thing for me to remember is to avoid situations where test pass but the code is broken due to excessive stubbing of behavior. The sweet spot with this is to use integration testing to cover all the bases.

factory_girl

If you’ve ever dealt with the frustration that is Rails fixtures, then you know the breath of relief that factories can give your tests. Being able to generate new models with a simple Factory(:post) call makes testing ridiculously easy. Some of the latest features I’ve been using is the :parent option on Factory.define, which allows you inherit attributes from another factory. Clearance has a great example of this in how it creates a Factory(:email_confirmed_user) that descends from Factory(:user).

Cucumber

I’ve learned about user stories in classes, but being able to write them in plain English and run them with Ruby has totally blown me away. Outside-in development is a great way to approach features that need to be built and tested from the ground up. Ben Mabey’s presentation at MountainWest RubyConf has a great example of how this development method works if you haven’t tried it out yet. The best part I find is that it can be read by clients or developers coming into the project, and it can be used outside of the Rails environment as well. Take some time and look into Cucumber if you haven’t already, and start at their fantastic site.

FakeWeb

Mocking out external HTTP calls is difficult. If you’re working with any sort of API from another site and you want to ensure that your code is actually submitting to it, relying on FakeWeb is a good choice. The syntax and setup is really simple, and it will usually look something like this:

1234	require 'fake_web'FakeWeb.allow_net_connect = falseFakeWeb.register_uri(:post, "http://somesite.com", :string => 'response body')

This little snippet will cause FakeWeb to throw errors if any other HTTP calls are made outside of the ones registered. The final line will tell the library to return the given string when that URL is hit from the application with a POST request. Like most projects in the Ruby world, it “just works”.

Testing in your shell

Being a convert to vim from TextMate, running tests usually isn’t as simple as doing Cmd+R. Luckily there’s two tools that help out with this. One is autotest, which I’ll run if the test suite for the app I’m working with doesn’t take too long. What I love best is that it fires off the test immediately after a :w in vim, so I don’t have to do any sort of context switching to run the test. It can get annoying though, and modifying your ~/.autotest to not run the entire suite after fixing a failed test helps cut that down. Another helpful thing that some of the thoughtbotters use is a zsh script that adds autocompletion for running unit and functional tests. Basically just type tu or tf, and tab away.

If you know of other testing tools that we should be looking into, speak up in the comments!

Tips for writing your own Rails engine

2009-04-23T17:23:00Z

While converting Clearance to a Rails engine was easy, once we were there, we found it wasn’t Valhalla.

We fixed the bugs while using the engine internally on a few apps. Here are the lessons we learned. Keep them in mind if you’re thinking of writing your own engine.

Routes precedence

As developers, we want routes in our app to take precedence over routes in the engine. That is not the default behavior.

To get around that, we came up with this hack. (credit to Nick Quaranto, a.k.a. qrush a.k.a. Internbot)

class ActionController::Routing::RouteSet
  def load_routes_with_clearance!
    clearance_routes = File.join(File.dirname(__FILE__), 
                       *%w[.. config clearance_routes.rb])
    unless configuration_files.include? clearance_routes
      add_configuration_file(clearance_routes)
    end
    load_routes_without_clearance!
  end

  alias_method_chain :load_routes!, :clearance
end

Rather than using the Rails engine convention of naming the routes file vendor/gems/clearance/config/routes.rb, we named it vendor/gems/clearance/config/clearance_routes.rb so it won’t be automatically loaded. Then we alias_method_chain around some ActionController internals.

Ugly stuff, but effective and solved a blocker for releasing as an engine.

Cached classes in development

In development, all your classes are constantly reloaded. This makes sense for your app, but not for your engine classes or modules.

We added unloadable to our Clearance module to fix this. Again, credit goes to Nick.

123	class Clearance::SessionsController < ApplicationController unloadableend

If you see errors like the following, you might consider a similar approach.

has been removed from the module tree but is still active

Namespacing controllers

We decided namespacing controllers was a good convention for our engine.

When we need to override something in the engine, this gives us clear routes separation…

# in the engine
ActionController::Routing::Routes.draw do |map|
  map.resources :users, :controller => 'clearance/users' do |users|
    users.resource :password,
      :controller => 'clearance/passwords',
      :only => [:create, :edit, :update]
end

# in the app
ActionController::Routing::Routes.draw do |map|
  map.resources :users
end

... and clean subclassing:

class UsersController < Clearance::UsersController
  def edit
    ...
  end
end

Helper inclusion

Tammer has also recently been extracting the announcement code from Hoptoad into an engine. He found that helper :all in the controller doesn’t find engine helpers.

Within the engine’s init.rb, he hooked his engine’s AnnouncementsHelper into the app’s ApplicationHelper like so:

123	config.to_prepare do ApplicationController.helper(AnnouncementsHelper)end

Note that any code that extends classes from the application (such as ApplicationController) must be wrapped in a to_prepare block.

This is because ApplicationController gets reloaded before each request during development. Without this block, only the first request would see the AnnouncementsHelper methods.

Clearance is a Rails engine

2009-04-22T14:00:00Z

Clearance is now a Rails engine… BLAOW!

Why

Clearance has served us well for many months. Our only complaints were shared by others:

lots of includes
too much generated code
too many tests to maintain
sometimes awkward to override functionality

With the re-institution of Rails engines in Rails 2.3, we decided to convert Clearance to engine. The process was relatively painless, the code is far cleaner, and we think we were able to scratch all our itches.

Philosophy

We highly recommend that you use the Cucumber features that come with Clearance to test the integration of the engine with your app:

script/generate clearance_features

You no longer run Clearance’s generated Shoulda & Factory Girl tests within your test suite. That code is unit tested internally. Use the Cucumber features to test integration. If and when you override functionality, write your own unit tests.

Read Mixing Cucumber with Test::Unit/Shoulda if you’re getting started with Cucumber and not using RSpec.

Overriding

We haven’t and probably won’t ever move Clearance beyond email and password authentication, despite frequent requests. We’re focused on “clean code that works” for the baseline authentication we’ve written over and over again for clients.

A huge part of “clean code that works” means that overriding Clearance needs to be painless. The change to an engine helps achieve that goal.

class UsersController < Clearance::UsersController
  def edit
    ...
  end
end

ActionController::Routing::Routes.draw do |map|
  map.resources :users
end

That’s it.

Write your tests for whatever action you want to add or override.
Subclass one of Clearance’s controllers (Users, Sessions, Passwords, and Confirmations).
Update your routes (by default, the routes will point to the namespaced Clearance controllers).

The Royal Library of Alexandria

All knowledge pertaining to Clearance can be found on its Github wiki, where you’ll find such articles as:

Upgrading to Rails engine
Organization of modules, routes, & flashes
Extending Clearance with usernames, admins, or invite codes

.. and much more.

Enjoy!

Klang & Strongbox

2009-04-17T14:23:00Z

We’ve been running Ruby on Rails training classes since September. Classes are running monthly:

Since graduating, our alumni have been building some great stuff. Here’s a selection of their public work.

Klang

Klang is a small record label. Alumni Mark Cornick built their Rails app.

From Mark:

It combines a blog-style news section, a product catalog w/ a (not fully automated) shopping cart, a show listing, and some other features. Behind the scenes, there’s Shoulda and factory_girl for testing, and I recently replaced file_column with Paperclip and restful_authentication with Clearance.

If you want to see a well-written, well-tested Rails app’s full source code, Mark has has put the full source code on github. Very cool! The question, “where can I see real-world Rails app source code” often comes up on Ruby mailing lists. Point them to Klang.

As if that wasn’t enough, Mark has made Klang’s RunCodeRun builds public. For those unfamiliar with RunCodeRun, it’s a hosted Continuous Integration service from Relevance.

Strongbox

Strongbox is Ruby gem by Spike Ilacqua that provides Public Key Encryption for ActiveRecord.

From Spike:

The idea isn’t new, I originally did this is Perl five or so years ago, and the most popular post on my blog is a how-to I wrote a year ago.

I wrote a gem for internal use at the same time I wrote the post, but I never published it. My testing was weak, and I didn’t want to put it out in the world without better coverage. Enter Advanced Rails Training. The class really helped me get my head around testing and TDD, and that’s how I’ve been approaching all of my projects. I re-built the gem using TDD and posted it to Github.

This is a cool idea and has a nice API:

class User < ActiveRecord::Base
  encrypt_with_public_key :secret,
    :key_pair => File.join(RAILS_ROOT,'config','keypair.pem'),
end

user.secret.decrypt 'password'

Great job, Mark and Spike! We can’t wait to see what the growing ranks of alumni make next.

Rails 2.3.2 upgrade gotchas

2009-04-15T15:38:00Z

With the latest stable release of rails out the door for about a month, we’ve had a chance to upgrade the bulk of the applications we maintain to 2.3.2.1. The rails 2.3 release notes were a HUGE help during this upgrade. Thanks to the Mike Gunderloy for compiling that document.

Here are some “gotchas”, aka issues, aka roadblocks to Strategic Enterprise Adoption that we discovered while upgrading some of them.

Upgrade Hoptoad

Problem: `const_missing’: uninitialized constant CGI::Session (NameError)

Solution: Hoptoad Notifier plugin needs to be updated.

ruby script/plugin install --force git://github.com/thoughtbot/hoptoad_notifier.git

Rename application controller

Problem: `load_missing_constant’: uninitialized constant ApplicationController (NameError)

Solution: You need to rename application.rb to application_controller.rb

CGI::Cookie

Problem: @request.cookies["name"] = CGI::Cookie.new("name", "value") sets the cookie to [“value”] instead of “value”.

Solution: You no longer need to set the cookie to a CGI::Cookie instance. Just set it to the string directly: @request.cookies["name"] = "value"

Transactional Fixtures

Problem: undefined method `use_transactional_fixtures=’ for Test::Unit::TestCase:Class (NoMethodError)

Solution: In your test/test_helper.rb file, you need to rename ‘Test::Unit::TestCase’ to ‘ActiveSupport::TestCase’ to set these options.

Routing tests

Problem: NoMethodError: undefined method `assert_recognizes’ for #<RoutesTest:0×22058f8>

Solution: Are you testing your routes in a unit test with a class of ActiveSupport::TestCase? The routing assertions are only included in ActionController::TestCase now, so change the test class to use that instead.

Count through associations

Problem: errors on a #count that goes through a named_scope on a has_many :through. This used to successfully proxy through and run a successful SQL COUNT query. Now there’s all this

Solution: not sure yet, maybe use the file at the end of that ticket?

Upgrade rake

Problem: when you deploy to staging or production, you get an error about an undefined ‘reenable’ method on Rake::Task.

Solution: This method was introduced in rake 0.8.2, but not actually used by rails prior to the 2.3 release. You need to update rake to a version newer than 0.8.2 on your servers (0.8.4 is latest stable as of now).

Upgrade rubygems

Problem: When deploying you get an “undefined method `ruby_version’ for Gem:Module” error.

Solution: Upgrade rubygems to the latest stable version (1.3.1 at the time of this post).