giant robots smashing into other giant robots

Your next great teammate

Wed, 08 Feb 2012 13:47:00 -0500

Every company we speak with could use a great web designer or developer on their team. We think we know where to find such mysterious figures.

What does a great teammate look like?

Imagine a programmer next to you, noise-canceling headphones on, punishing his keyboard with forceful blows, punctuating each change by slamming the heels of his hands against his desk. While tests run, jolly meme photos float into Campfire.

Imagine this person writing test-first code that is pushed to production each day. Imagine them refactoring ruthlessly and making other team members stronger through feature branch code reviews.

37signals doesn’t have to imagine. Nick Quaranto now works with them.

Nick was an apprentice at thoughtbot. We cannot claim responsibility for his motivation, problem solving abilities, or other Nick-isms, but his time with us was not an aberration.

There are plenty of great designers and developers worldwide

75% of the new team members we hired last year started as apprentices.

Last year, we met Prem Sichanugrist, a lifelong Thailand resident. You’ll find him currently ranked #32 for most commits to Rails.

Galen Frechette creates useful and beautiful stuff like this. Alex Godin was in Techstars New York before he could legally buy a pack of smokes. Gabe Berke-Williams is becoming a prolific (and often funny) open source contributor.

All are former thoughtbot apprentices.

Running an apprenticeship program isn’t easy

We’ve now run an internal apprentice program for about two years. We’ve also run design and development workshops for years.

Like many things, these are easy to start but difficult to regularly do well. Apprentices will temporarily slow their mentors down. Questions will arise.

How much time should be spent pairing? Attending workshops? Reading the Pickaxe or watching Peepcodes? Reading incoming code reviews from a variety of projects?

We’re getting good at many of these subtle details. As a fairly efficient design-and-code consultancy, we’re the right team to try to push the limits.

apprentice.io

We’re now opening up our apprenticeship program externally for any company that would like to sponsor apprentices. We’re calling this new program apprentice.io.

When you sign up on the website as an employer you get immediate access to the bios of all of the current apprentices and the others from all over the world that we already have scheduled for this year.

As an employer, you contact and interact with the apprentices directly. Over time we’ll grow the apprentice.io platform to provide mentor-to-employer updates on the progress of apprentices, and more.

For little more than you may already pay job boards and a lot less than you might pay recruiters, this money now goes to train people.

We think that’s a powerful idea: what if instead of recruiting, you educate?

If you’re a designer or developer interested in apprenticing, please apply.

If you just want to talk about this, please email me at apply@apprentice.io or call me at (877) 976-2687 x113.

Airbrake acquired by Exceptional

Tue, 07 Feb 2012 17:45:00 -0500

Late last year, Airbrake was acquired by the team at Exceptional, inc. We’re extremely excited about this move and we’d like to explain why.

A brief history

We created Hoptoad in the fall of 2007 and launched it publicly in spring of 2008. We had been tracking our errors previously with an email notifier that flooded our inboxes with repeat errors, many generated by search engines requesting weird URLs.

In 2011, we renamed the product Airbrake.

Over the years, Airbrake handled billions of error reports for thousands of web applications from all over the world. We kept the product focused on grouping similar errors, notifying developers once per error, and displaying the backtrace and session information to help debug the issue.

A serious commitment

As the number of customers and errors increased, we spent a lot of time addressing scaling issues. There were times we’d have 150,000 requests per minute, or requests with 500MB of session data.

Running Airbrake was like being under a constant DoS attack.

So, we spent very little time working toward our vision of a product that integrated more completely with developer tools.

Last year, we were approached by the Exceptional team and their Chief Strategic Officer, Jonathan Siegel (who has created or invested in RightSignature, RightScale, Intercom, and Iron.io). Exceptional had a team ready to work toward the same vision we had for Airbrake.

The future

After getting to know the Exceptional team, we felt their serious financial and team commitment had the best chance to turn our shared vision into reality. We agreed to sell Airbrake to Exceptional.

The new team has been handling all support issues and feature work for several months now. We’re very pleased with their work so far.

We continue to provide web design and development consulting and are developing Trajectory, Copycopter, and apprentice.io to help solve problems for web design and development teams.

Thank you

If you’ve been an Airbrake customer, thank you! It’s been a great experience for us and you continue to be in good hands with the new team.

Read more about the acquisition at TechCrunch and the past, present, and future of Airbrake at the Airbrake blog.

Design 101: Stop Yelling

Mon, 06 Feb 2012 14:31:00 -0500

How do you make yourself heard in a loud room? BY YELLING! And when it comes to design, that’s often the approach used for drawing attention to elements. LOUDER! BIGGER! FASTER!

But there’s a better way.

Imagine yourself in that loud room again. Now imagine that instead of yelling to get above the noise, you could just turn down everyone else. Instead of shouting at the person you’re talking to and ending up with a strained voice, you’ll be able to have a nice, thoughtful conversation with them.

While it’s hard to turn down the volume of a room, it’s easy to quiet the background noise in your design and let the important parts speak clearly. Let’s take a closer look at this idea.

Below is an example of a composition where everything is shouting at you. The big red headline at the top is trying to assert itself, but so is everything else, which means, in the end, nothing stands out.

So let’s turn down the volume. You have to decide what you’re trying to communicate and how to say it in a clear and concise way. This will drive your design decisions. In the example below, we’ve established a clear hierarchy between each bit of text. The headline still dominates, but we’ve toned down the other text so that your eye moves comfortably and naturally from headline, to subhead, to body text.

Let’s try another iteration that makes more dramatic use of white space. I tell students in my workshop that white space is the secret ingredient in design. Effective use of white space can transform a mundane design into something that feels elegant and timeless.

In this example, I’ve made the headline and subhead the same size as the body copy. I’m relying on white space to create the hierarchy, isolating the elements within the composition so they can establish their presence without competing with surrounding elements. Think of that loud room again. Not only have we quieted the voices in the room, we’ve moved everyone to their own corner so they can talk without distraction.

When thinking about how to create emphasis, don’t be so quick to turn up the volume. Think about how to use hierarchy and white space to communicate your message without shouting it at your audience. You’ll create something more elegant and respectful that still accomplishes your communication goal.

I’ll be teaching more visual design principles and strategy in my workshop, Design for Developers, which is running Feb 27–28 in our Boston office.

This week in open source

Fri, 03 Feb 2012 16:41:00 -0500

bourbon

As a programmer I love the change that made it into version 1.3.6 (10f978d) of bourbon: Phil LaPier (plapier) added to work done by Frank (frankzilla) to add a monospaced font family, $monospace—with support for Bitstream Vera Sans Mono, my favorite monospace typeface (3467fe3 and c86e5687). Nice.

paperclip

Friday saw a new release of paperclip (1cb40e3), in accordance with the prophecy. It contains Windows support, a bug fix, and two new features.

Prem Sichanugrist (sikachu) has been working on handling characters that are not URL-safe; to this end he added a :restricted_characters option to has_attached_file, with a default value of &$+,\/:;=?@<>\[\]\{\}\|\\\^~%# , which specifies characters to replace with an underscore, _ (8353518 and 604304e). Benjamin Hüttinger (maxigs) added the ability to pass a block, evaluated at runtime, for :fog_host, :bucket_name, and :fog_credential options (e049ec5, 2b562a9, 8742615, and 1c88a72).

The gem itself had problems installing on Windows because a bundled test made sure that filenames with question marks were handled fine; turns out this simply breaks on Windows. Even though no actual programmers use Windows, we removed the offending file (ed5cd9f). Jon Yurek (jyurek) fixed a long-standing bug where the RSpec matchers (validate_attachment_content_type, validate_attachment_presence, and validate_attachment_size) didn’t handle the :if argument they were supposed to handle (5d4ba62).

capybara-webkit

A new release of capybara-webkit is in the works, and this is what you’ll see in it: Matthew Mongeau (halogenandtoast) added the ability to trigger mousedown and mouseup events (51c4dfe and 16c1637) while Joe Ferris (jferris) has commands block until the page finishes loading (18607d0).

clearance

Oh sweet, a new version of clearance is out (6c0c070)! In it you’ll find support for Rails 3.2 from Gabe Berke-Williams (gabebw), mostly in following deprecation warnings (6e57d10). Some prodding from Matthew Daubert (MDaubs) prompted us to upgrade cucumber-rails to 1.1.1 (691e867 and 91f4675). Dan Hodge (danhodge) dropped a totally awesome change on us, abstracting out the User class into Clearance.configuration.user_model, which can be changed at runtime (085a9b6, a582eec, and fc6af70). Dude, that’s awesome.

fake_braintree

Holy cow it’s version 0.2.0 of fake_braintree (0be2aea). In this Gabe Berke-Williams (gabebw) gave us the ability to specify a constant amount for a transaction (783719c), and mimics the behavior around customers with failing credit cards (a2ceb58).

factory_girl

No big news in factory_girl this week. Carlos Antonio da Silva (carlosantoniodasilva) updated the docs to mention that .stub is now .build_stubbed (08018f6). Michael Klishin (michaelklishin) fixed the build on Travis CI for Rails 3.2 by updating rubygems first (850116d). Joshua Clayton (joshuaclayton) found a spec that was not appropriately named, and fixed it (0d67a42).

kumade

While kumade did not see a deploy this week, it did see some feature improvements, some of which come with an API change.

The hook for running code just before deployment was originally run_predeploy_task but is now run_pre_deploy_task (764aebe). Chad Boyd (hoverlover) made this change so he could introduce the run_post_deploy_task, which is further exposed as kumade:post_deploy to Rake (da74087, f68a487, and 9679018).

Kumade now works with more stuff: Jammit 0.6.5 (ec63310) thanks to Vesa Vänskä (vesan), and Ruby 1.9.3 (8e73b90) thanks to Gabe Berke-Williams (gabebw).

Gabe also fiddled with some source code (7e0e11e, bb695b9 and 92aa8f4).

copycopter_client

A small documentation update occured in copycopter_client by Joe Ferris (jferris), reminding us that you can leave the name of the controller or model off of the translation key only when using t from a view (6416897).

Decoupling Data from Presentation

Thu, 02 Feb 2012 14:10:00 -0500

I’m really happy to see a resurgence in an understanding that writing integration tests that use classes and DOM structure to perform assertions within these tests is typically a bad idea. The DOM structure constantly changes but the data displayed (the stuff we want to assert is present on a page) typically doesn’t.

Why write tests against some markup that a designer may change, sometimes often if he’s iterating over a design? It’ll end up causing everyone headaches and frustration.

How can we mark up our documents without performing assertions against a deep nesting of classes and elements while ensuring our data is displayed properly?

Data attributes.

The browsers I care about support HTML5, so why not start using some of its capabilities to clean up some integration tests?

Imagine this scenario:

Scenario: See the site description on the homepage
  When I am on the homepage
  Then I should see the site description

Simple, straightforward, and each step is a similar level of abstraction.

Now imagine this markup:


  
    Welcome to the site!
    Insert a witty tagline here
  
  This product will make your life 100 times
  better.

I could write a step like this:

Then "I should see the site description" do
  page.should have_selector("section.primary-content p.description",
                            text: "This product will make your life 100 times better.")
end

This step is asserting that there’s a section element with a class of primary-content who has a child paragraph tag with a class of description that contains the correct text. Classes change. Structure changes. This is begging to be rewritten.


  
    Welcome to the site!
    Insert a witty tagline here
  
  This product will make your life 100 times better.


Then "I should see the site description" do
  page.should have_selector("[data-role='primary-content'] [data-role='description']",
                            text: "This product will make your life 100 times better.")
end

Now, the step is asserting that there’s an element with a role of description within an element with a role of primary-content that contains the correct text.

XHTML introduced a role attribute, but it’s not present currently in HTML5. Luckily, data attributes are even more flexible and we can use any conventions we like. data-role and data-state are two of my favorites.

Interested in how to write awesome Cucumber steps? Head to my Intro to Test-Driven Rails workshop on March 26th and March 27th where we’ll cover this and other awesome topics on writing great tests!

This week in open source

Fri, 27 Jan 2012 14:18:34 -0500

bourbon

Over the past week bourbon went up to version 1.3.5. A whole bunch of sweet new features are in it now:

Frank (frankzilla) added a modular-scale mixin, of which the golden-ratio mixin is but one implementation (126a83b and 96659a2). He also added a parameterized fallback color to linear-gradient (60e2c63).

Phil LaPier (plapier) worked with Gabe Berke-Williams (gabebw) on a bourbon command-line too for working with Sass outside of a Rails app, such as Jekyll, WordPress, or even a static site (ad1499b, b55a763, 0ebf906, c2077d8, 13e70d3, 2fc2c90, and bf34e70). You can run bourbon install to install it and bourbon update to update an existing installation.

capybara-webkit

A careful sleuth has updated the documentation for capybara-webkit this week. Marc Schwieterman (marcisme) discovered that a fully passing test suite depends on ImageMagick, and documented as much in the contributions guide (df39268).

factory_girl

Version 2.5.0 of factory_girl is out, and there’s a badass new feature in it. But first:

Joshua Clayton (joshuaclayton) fixed a bug where the :parent’s factory wasn’t being passed along (4aecfff). Carlos Antonio da Silva (carlosantoniodasilva) fixed the URLs in the readme to point to correct locations (aa74edd and 42f5a10).

Oh, and you may remember from last week that Josh deprecated the attributes_for method admist much controversy. Well, he undid that (2d6adfd).

Josh then implemented a feature that Joe Ferris (jferris), FactoryGirl’s originator, has wanted for years: you can specify how FactoryGirl should construct the class (5780364). Joe excitedly documented this (ea89aad). This means that FactoryGirl can be used for non-ActiveRecord classes, including immutable classes.

paperclip

In accordance to our new gem schedule, paperclip hit 2.5.1 this week. Mike Burns (mike-burns) cut the release, adding a ChangeLog and updating the NEWS file (b7f9b6f and ec4793e). In short: Fog storage is passed the content type, S3 can be encrypted, and ActiveRecord is optional.

Designer Tools

Thu, 26 Jan 2012 09:58:00 -0500

In addition to the basic development environment everyone at thoughtbot works with, there are a number of other apps most of the designers here use to keep our work flows efficient and our skills top notch. When I came to thoughtbot as an apprentice a little over three months ago, I was exposed to a variety of new apps that greatly improved my work-flow, so I thought I would share with you some of the apps I open up every morning and a bit on how I use them.

The basics

These apps are not necessarily design-specific apps but they are so essential in our day to day work-flows that I couldn’t leave them out.

Propane: Chat client for 37Signals’ Campfire. This is an indispensable communication tool.
Growl: Notifications for anything and everything. Used primarily for Campfire notifications.
iTerm: Terminal emulation for OSX. Mostly beneficial for it’s ability to open multiple windows in tabs.
MacVim: Text editing. If you’re not already using Vim, take the time to start learning. It will greatly speed up your development time and if you’re working with developers who use Vim it will make pairing easier.
Divvy: Helps you keep your screens and windows spaced, aligned and organized efficiently without clicking and dragging all day.

Adobe

If you work on the web I am sure you are already familiar with the typical Adobe software that web designers use, so Im not going to get into the details of our Adobe setups here. Most of us prefer to do hand sketches/whiteboarding and move into wire framing with HTML and CSS as soon as possible any way. Static mock-ups tend to have a host of draw backs when working in an agile development process. That said, photoshop, illustrator and fireworks are still our workhorses when it comes to specific graphic design needs.

Skitch

A handy screen capturing tool that allows you to very easily draw and add notes on top of your screen shots, without having to open up photoshop or some other image editing tool.

Cloud App

Collaboration and iteration are key ingredients in doing great work and I have found this app to be an effective way of sharing screen shots with team members, clients and other designers so I can get that valuable feedback on the development of my work. When you take screen shot Cloud app automatically uploads your image to web servers and in a drop-down from the Cloud app icon in the OSX menu bar, provides you with a sharable link to that image.

Notational Velocity

Good for general note taking and the keeping of VIM and Git cheat-sheets. Especially if you are new to VIM or Git keeping track of commands and remembering how to get certain things done right can be quite challenging, so we all suggest building up robust cheat-sheets with this little app.

FontCase or FontExplorer X

Great typography is a fundamental element of great design. Managing your fonts effectively will help you find that perfect type-face faster and reduce the time it takes to get started with a solid visual design direction. Taking the time to organise your typefaces in a way that is meaningful to you can also be a good way of curating your collection and more intimately familiarizing your self with the fonts in it.

Little Snapper or Gimme Bar

Both are awesome tools for building a personally curated library of design inspiration. Saving images and examples of the things that inspire you is a great way to refine and hone your own personal style and also a great way to help kick off the visual direction for a new project. If you are not using tools like these already, start. It will be hugely beneficial to the quality of work you do.

Hues

A great little app for grabbing colors from anywhere on your screen. It provides rgb, hsl, and hex values for any color you select which makes pulling color pallets from photos and images you have stashed in your Gimme Bar or Little Snapper quite nice.

Bourbon

Bourbon is not an app, it’s a library of SASS mixins and functions that greatly speed up front-end development time. It is just as awesome for new comers to .css/.scss as it is for the most seasoned pros. It’s also one of the main reasons the sketch-to-html&css-wire frames process has proven to be so effective and efficient for us. We have extensively written about bourbon before.

So that’s it for a light-weight overview of the apps I find my self opening on a daily basis. Hopefully I have introduced you to some new and useful tools. I’d also love to hear about some of the tools your using, so feel free to add your comments below!

A users guide to the Trajectory redesign

Wed, 25 Jan 2012 16:49:00 -0500

We released a redesign to the Trajectory UI today. I want to explain the thinking that went into the redesign, what the benefits to users are, and what’s in store for Trajectory as we move forward.

View of the main stories index.

First, let’s do a quick history lesson. A year and a half ago, we decided to build Trajectory to scratch our own itch. We wanted a lightweight agile project management tool that had a strong focus on discussions, both for the stories being worked on, as well as for longer term planning. The original design for the Trajectory UI emerged out of an iterative process, and evolved as we learned more about the product over the course of its development.

This redesign was a chance to take stock of what’ve we learned through that process, and lay the groundwork for the future. The most obvious change is the lighter color scheme. We’d heard continual feedback that people found it difficult to quickly scan through stories because of the dark color scheme. The new UI fixes this problem and provides a more pleasant experience for extended, daily use.

Next, we designed the UI to respond better to differing screen sizes. If you have a large monitor, the site will expand to use the space available to it. Shrink your window down, and the site remains just as usable. There’s more work to be done, but the long term goal is to serve a single web-based interface to all devices, whether it’s a 27” display or your mobile device.

There are a number of other UI improvements. We’ve improved the searching and filtering of stories. (Pro tip: hit the f key to enter search mode.)

The new search interface.

It’s now easier to estimate and re-estimate stories.

The new story estimation UI.

You can also quickly see the progress on stories created from an Idea.

Progress of stories attached to an idea.

We also performed a heavy refactoring/rewriting of the front-end markup and style. We were able to eliminate and simplify substantial portions of the front-end code, which should hopefully translate to snappier performance within the browser.

Trajectory is going to be a very important part of what thoughtbot does in 2012. If you haven’t done so yet, sign up for a free trial and see what we’re so excited about.

Inject that Rails Configuration Dependency!

Wed, 25 Jan 2012 13:33:00 -0500

Setting up configuration settings in a Rails app has been fairly straightforward for a while now:

# config/environments/development.rb
Doit::Application.configure do
  config.default_creator = "Person 1"
end

# config/environments/test.rb
Doit::Application.configure do
  config.default_creator = "Test Person"
end

# config/environments/production.rb
Doit::Application.configure do
  config.default_creator = "John Doe"
end

To access this setting, call Doit::Application.config.default_creator within your app. Pretty straightforward, right?

class TodoItem < ActiveRecord::Base
  before_create :assign_default_creator, unless: :creator?

  private

  def assign_default_creator
    self.creator = Doit::Application.config.default_creator
  end
end

Let’s imagine you have a todo item and you want to test that the value gets assigned if no creator is provided.

Imagine how you’d test this.

describe TodoItem do
  it "assigns the default creator when no creator is assigned" do
    Doit::Application.config.stub(:default_creator).and_return("default creator from config")
    subject.save
    subject.creator.should == "default creator from config"
  end

  it "does not assign the default creator if it has been set" do
    Doit::Application.config.stub(:default_creator).and_return("default creator from config")
    subject.creator = "Jane Doe"
    subject.save
    subject.creator.should == "Jane Doe"
  end
end

There’s a few things that are gross. First, we’re referencing Doit::Application in the model spec. Second, we’re stubbing in both examples. The latter is a low-hanging fruit so it can be extracted.

describe TodoItem do
  it "assigns the default creator when no creator is assigned" do
    config_default_creator_returns("default creator from config")
    subject.save
    subject.creator.should == "default creator from config"
  end

  it "does not assign the default creator if it has been set" do
    config_default_creator_returns("default creator from config")
    subject.creator = "Jane Doe"
    subject.save
    subject.creator.should == "Jane Doe"
  end

  def config_default_creator_returns(value)
    Doit::Application.config.stub(:default_creator).and_return(value)
  end
end

Now, interacting with Doit::Application is confined to one method. Some people may stub the application in an RSpec before block, but I don’t like doing that because one of the specs cares about the stubbed value. I want that stub right in the example so it’s obvious that the stub and assertion are close (in number of lines).

Even though Doit::Application is confined to one call in the spec, I really don’t like that the spec cares about its config at all. What I’d love to do is assign a custom configuration on my TodoItem in my test intsead of caring about Doit::Application and having to stub on config. I can do this with dependency injection.

Right now, TodoItem has a dependency on Doit::Application.config. Dependency injection would mean TodoItem gets a class_attribute :config that defaults to Doit::Application.config but can be overridden (say, in our tests).

describe TodoItem do
  it "assigns the default creator when no creator is assigned" do
    subject.config = stub("config", default_creator: "default creator from config")
    subject.save
    subject.creator.should == "default creator from config"
  end

  it "does not assign the default creator if it has been set" do
    subject.config = stub("config", default_creator: "default creator from config")
    subject.creator = "Jane Doe"
    subject.save
    subject.creator.should == "Jane Doe"
  end
end

With the class attribute, I’m able to override config on the instance and replace it with a stub that has a default_creator method, which I’ve assigned to the string I expect. I was able to remove my reference of Doit::Application from the spec. Perfect!

Here’s the model code:

class TodoItem < ActiveRecord::Base
  class_attribute :config
  self.config = Doit::Application.config

  before_create :assign_default_creator, unless: :creator?

  private

  def assign_default_creator
    self.creator = config.default_creator
  end
end

The callback assign_default_creator now doesn’t care about Doit::Application.config, only that config has a default_creator method.

This post actually stemmed from my interaction with a developer in Factory Girl GitHub Issues who asked a pretty interesting question about reloading classes in Factory Girl after removing the constant and loading the Ruby file again (it seemed like a code smell and not an issue with Factory Girl).

At the end of the thread, I suggested he attend my Test-Driven Rails workshop next week, January 30th and 31st, because I’ll be talking about RSpec and dependency injection (among other things like Cucumber, how, when, and what to test in a Rails app). It’s perfect for Rails developers who are interested in writing more cleaner, more stable applications.

See you there!

Apprentice.io Three Week Retrospective

Mon, 23 Jan 2012 20:59:53 -0500

Over the past three weeks I’ve begun my apprenticeship at thoughtbot. The apprenticeship lasts until the end of March. I’m joined by designers Paul Webb and Edwin Morris, and fellow coder apprentice Alex Patriquin. Each of us is assigned to a mentor, who makes sure we absorb as much as possible of the thoughtbot way of doing things and achieve our specific goals. For me, the apprenticeship is a couple of things: it’s a chance to work in coder nirvana (TDD, heavy refactoring, bookshelf full of great literature, 5-minute meetings, pair programming, investment days, open source - the works), and it’s a chance to vastly increase my Rails skills in a bootcamp-style training environment.

My head is swimming with new knowledge. I entered this state the first day, and I’ve been there constantly for the past three weeks. Each evening I ride the T home with my poor neurons about to burst with new activity. At night while I sleep my brain indexes all this new knowledge, and the next day I dive in again. If you’ve ever read Ender’s Game, it’s sort of like Battle School for Geeks.

Let’s get specific. This list is long because I’ve been truly busy. In the past three weeks I have:

Mercilessly refactored my code two, three, even four times after writing it. The standards for code quality here are very, very high.
Learned to use Github pull requests for code review.
Responded to around 150 code review comments, most of which made me stop and rethink coding habits I’ve held unconsciously for years. My style is improving fast.
Participated daily in a morning company-wide standup that actually takes less than five minutes, and a team standup that takes another five. That’s only ten minutes of meetings per day!
Switched to using higher-level cucumber tests involving steps like “When I sign up as a new user” as opposed to “When I click the link marked ‘foo’”.
Achieved and maintained 100% perfect TDD discipline - not writing a single line of feature code until a failing test is present.
Completely switched text editors, from Textmate to Vim.
Became faster in vim than I ever was in Textmate.
Written custom functions for vim.
Learned other new tools including Homebrew, ack, ctags, New Relic, KISSmetrics, and kumade.
Forked thoughtbot’s dotfiles repo and started customizing it as my personal dev environment. The dotfiles repo contains bashrc, vimrc, git-config, alises, etc - I can now install it to any computer I use to instantly have my customized dev environment in place.
Watched an app’s user base jump from 100 to 10,000 in a matter of minutes as an article hit TechCrunch.
Gotten a crash-course in startup funding from the other coding apprentice, Alex Patriquin, who boasts, quite accurately, of knowing everybody.
Participated in discussions about new features in rails.
Made my very first contribution to an open source repo.
Been approved to give my first professional presentation - a lightning talk at at Boston.rb meeting.
Consumed 3,000 cups of green tea and a foie gras taco.

Did I mention I’ve been busy? That’s just the first three weeks - and I’ve got ten weeks left. I feel excited, involved, and challenged in a completely invigorating way. The team here is universally smart and helpful, and while I’m here I simply can’t help but get better by osmosis at what I do. This is the most fun I’ve had in an office in a long time.

For more information about this program, and to sign up to sponsor a pool of apprentices, visit apprentice.io

More later on,

Every Two Weeks

Mon, 23 Jan 2012 11:00:05 -0500

Our most popular gems—paperclip, capybara-webkit, factory_girl, and clearance—will see new releases every two weeks.

Trying to be reasonable

Release early, release often. In the past we’ve often released new versions of gems in a “when we feel like it” fashion: either we needed the gem to exist for a personal project, or we’re proud of some change we just made, or someone complained to us about an old version. This lead to a problem: when we were just taking pull requests we didn’t think to release a new version.

By setting up a regular schedule this means that contributions will be more public more quickly. We chose two week cycles as a compromise between releasing very often (every time we take a pull request) and in a wide duration (every three months). Too often and we’d annoy people when they upgrade; too infrequently and the bugs are simply not being fixed for the largest number of people.

It’s a process

Setting aside time to make a release elevates it from “OK I made these changes gem push woo!” to “I am going to make a proper release”—it reifies the release as a first-class action for us to concentrate on. Changelogs, blog posts, and tweets are side effects of putting the right amount of care into releasing a new version of a gem.

When‽

Factory Girl (factory_girl and factory_girl_rails) and Paperclip are on a two week release cycle starting January 27th, 2012. Clearance and capybara-webkit are on a two week release cycle starting February 3rd, 2012.

You can track gem releases using the RubyGems Web site and your favorite feed reader. It’s like this:

Sign up for RubyGems, or sign in if you already have an account.
Navigate to the page for the gem you care about.
Click “Subscribe”.
Click the “Dashboard” link at the top of the Web page.
There’s a sweet orange RSS icon in the middle of that page. Subscribe to that link!

When you say “every two weeks”…

Sometimes it doesn’t make sense to cut a release only every two weeks. Important security fixes or bugs that block everyone from using the gem are examples where getting something out as soon as possible is the only way to do it. On the other hand, sometimes there simply haven’t been any changes.

If we release a new version of a gem on the 26th and the 27th is when a scheduled release is to happen, it’s likely that we’ll skip the schedule. In general we’ll continue the “do I feel like making a release?” thought process, but every two weeks and with a bias towards a positive answer.

Or whenever

The bi-weekly cycle is new and, like everything else in software and life, worth reconsidering at all times. Please let us know if it’s too often, too seldom, just right, or completely useless to you!

Factory Girl 2.5 Gets Custom Constructors

Fri, 20 Jan 2012 19:30:00 -0500

Today marks a big day in the life of Factory Girl; you can now override the constructor for factories! This is great news for people who’ve been upset that they can’t use Factory Girl with objects who have constructors with required arguments, as Factory Girl would previously just call new without passing any arguments.

Here’s the syntax:

# app/models/report_generator.rb
class ReportGenerator
  def initialize(name, data)
    @name = name
    @data = data
  end

  # ...
end

# spec/factories.rb
FactoryGirl.define do
  factory :report_generator do
    ignore do
      name "Generic Report"
      data { {:foo => "bar", :baz => "buzz"} }
    end

    initialize_with { ReportGenerator.new(name, data) }
  end

  # ...
end

Note that I wrapped the name and data attributes in an ignore block. Factory Girl doesn’t differentiate between attributes passed in the custom constructor and normal attributes to assign, so moving them to the ignore block ensures that I don’t instantiate the report generator and then attempt to assign name and data again.

Grab a copy of 2.5.0 and start using Factory Girl with your other objects today!

This week in open source

Fri, 20 Jan 2012 16:50:21 -0500

shoulda-context

Hey! shoulda-context has a maintainer! His name is Travis Jeffery (travisjeffery) and he’s got commit rights and everything! Thank you, Travis.

Yeah!

cocaine

One feature was added to cocaine over the past week: Daniel Mircea (viseztrance) made it such that you can now pass blank argument values (a2d01c4). For example, this now works:


command_line = Cocaine::CommandLine.new(
  "curl",
  "-X POST -d :data :url",
  :data => "",           # Hey note this!
  :url => "http://localhost:9000",
  :swallow_stderr => false)

puts command_line.command

…which will produce:

curl -X POST -d '' 'http://localhost:9000'

paperclip

The paperclip project saw a few neat commits this week. Jeremy McNevin (jmcnevin) and ralph (ralph) pass the file type to Fog now, always (839b98c and 201f02e). Luke Griffiths (Sporky023), one of our new apprentices, got his first open source contribution in: you can pass an :s3_encrypted option for controlling which encryption type S3 should use (65e0338 and af6d343). And Jon Yurek (jyurek) fixed mixing Paperclip with non-ActiveRecord codebases (bc6ed16).

factory_girl

The fixture replacement gem, factory_girl, is now at version 2.4.2 (845578c). It includes bug fixes, a deprecation, and more Rails support. All commits were by Joshua Clayton (joshuaclayton).

There was an issue where using an inline trait would cause it not to be reset (70a80fd), and an issue with the precedence of inline traits (065c6c1).

Josh also deprecated the attributes_for class method, which once upon a time produced all the attributes that a factory would set (a883315). He provided no reliable workaround.

Today, Rails 3.2 was released, so we made sure to test against that—and it works! (5555f14)

capybara-webkit

A new release for capybara-webkit, yeay! Joe Ferris (jferris) cut the release (59ba861), first removing a long-standing debugging print statement (0bac05e).

Sweet features, bro: Yuri Gadow (ylg) added support for the fancy text inputs in HTML5 like email, number, search, and so on (7e5e99b).

John Barker (excepttheweasel) updated the README to point out that capybara-webkit does not, in fact, listen on port 8200 (2285621).

This week in open source

Fri, 13 Jan 2012 18:51:00 -0500

Deprecations

We have officially stopped maintaining the following open source products: limerick_rake, trout, shoulda-context, and jester. Do you want to take over any of them? Let us know!

kumade

The kumade Heroku deployer now has a rake task hook for running code before the deployment (8bd2824). This was done by Joshua Clayton (joshuaclayton) in the new version: 0.8.2 (52a9348).

paul_revere

The paul_revere notification gem has this sweet button to hide a notification. Ben Orenstein (r00k) changed the duration of this hiding from one day to one year (5a773d4).

bourbon

Phil LaPier (plapier) has released version 1.3.1 of bourbon, the much-loved collection of sass mixins (e90113c). In this version we have a new syntax for animation shorthands, which means the old shorthands are deprecated (e6dcbf5, a6d3a32, 89cc340). Get it while it’s hot!

pacecar

We have a gem that generates scopes for ActiveRecord objects, named pacecar, which you would love if you also love methods that magically appear. Matt Jankowski (mjankowski) released version 1.5.3 (06b5e8e) with support for Rails 3.1.3 and 3.0.11 (dcc30d4) and which treats decimals as numeric column types, giving you all the methods that you need for those, too (ff7bc67).

paperclip

The oft-used paperclip file uploader gem hit version 2.5.0 (071c938) with a NEWS file describing the changes, written by Mike Burns (mike-burns). That’s me. I like writing about changes.

Jim Ryan (jimryan) changed paperclip to process any :original style before all others, which can be useful in case order matters (f56e863 and d3db7a1).

Nathan Hyde gave us a performance gain by only generating the file’s fingerprint if it can be persisted (9fb9255 and 4e07681).

Alexander Greim (iltempo) landed a feature on us: S3 headers can be set at runtime by passing a block as the value of the headers instead of a static hash (a83de65 and 7a8d1e6).

Steve Madsen (sjmadsen) found an edge case where if you set an attachment, save it, set a new atachment, save it, then refresh the missing styles using the rake task, it will crash. And he fixed it (dc53432).

And Jon Yurek (jyurek) finally fixed Paperclip::Attachment such that it no longer overrides the Ruby hash method with an unrelated one (3fd4c96).

factory_girl

As usual, factory_girl got way more commits than I want to read over in one sitting. For example: Simone Carletti (weppos) added a ruby version dependency to the Gemspec (e6e4d8b). He also fixed the link to our blog (11a79a0 and 30e13dd).

Things like that.

So on the feature front, Evan Larkin (elarkin) made it such that factories still work if you define a class that overrides the to_s class method (8b3ee85). Dmytrii Nagirniak (dnagir) added support for neo4j (5246fda and 591ec7a). Joshua Clayton (joshuaclayton) made it such that you can call methods that are on the object from within a factory definition (d918c1d).

More wishy-washily, Josh made a bunch of refactorings, the most important of which speeds up the whole product (f2e4138). You can read the rest of the refactorings as code with good commit messages: 2e2d490, 40242e9, 32ff41f, ac1df1d, a022dda, 1c7eab1, d9e0372, and b734b58.

The README was improved with the status of all the dependent gems (768dfaa), by Steve Richert (laserlemon). Daniel Schierbeck (dasch) fixed the formatting of sample code (1e82889).

In the end, Josh released version 2.4.0 (69957ea).

capybara-webkit

Matthew Mongeau (halogenandtoast) had fun taking in pull requests on capybara-webkit. Joe Fiorini (joefiorini) added the requested_url method that produces the URL after a pushState (7f907a0). Niklas Baumstark (niklasb) added submit and path methods (352823d, d07cf3d, 21f4b84, 83905bb, 4ceb874).

John Hume (duelinmarkers) added support for JRuby (0979db4). Pete Gieser (pgieser) fixed a double-escaping bug in URLs (fccb444).

Matthew Mongeau (halogenandtoast) fixed the link to the Capybara README (e2c103c) and linked to the mailing list (d8c640d), and Jo Liss (joliss) recommended bundle exec in more places (7fe06e9).

clearance

Our authentication system aptly named clearance got some love from Chad Pytel (cpytel) and Joe Ferris (jferris), resulting in the release of clearance 0.14.0 (5471159, 214d1dd, and 0dc43a6). The big deal is that the deny_access RSpec match and the flash messages were totally borked. They fixed it (2085f03, 23df300, and 160366e).

fake_braintree

Version 0.1.1 of fake_braintree was released, in which Gabe Berke-Williams (gabebw) fixed a bug in the failure message for the have_accessor_for matcher (9d97aa6) and also refactored everything (0a45900, 59a7b60, 3daf2aa, 0f955c6, 3e8745f, bb1f339, 6d7d90c, ac0d550, d2f470e, 3c66129, 8cf7d9c, 157b2a7, 8f21376, 29429ef, e4cef67, 9928436, 94cca24, 7bd4e20, 2dde9ed, e775167, a72e31b, 57f3623, d580024, ad82f0e, 3385e12, cacb537, ae86ebe, c6cead6, a352f33, f7a6cf5, 9f1fb3b, 124706d, ef8b13a, and b20e318).

Factory Girl 2.4 Goes Meta

Fri, 13 Jan 2012 14:40:00 -0500

Factory Girl has been getting some hardcore internal refactorings over the past few months. Traits are a great example of something that’s started very bare-bones with a few caveats and been transformed to one of my favorite features of the Factory Girl syntax. It required a pretty decent chunk of refactoring and there were bugs for quite a while due to the way attributes in general were handled.

The Old Way

Internally, Factory Girl has four different types of attributes (Dynamic, Static, Association, and Sequence); when compiling attributes, we were sorting attributes by the order attributes were added, moving all static attributes to the beginning of the list (with a priority attribute). This worked for 99% of all cases but did have bugs (the most recent involved traits and dynamic attributes). I wanted to resolve this once and for all.

The New Way

Factory Girl now creates a new class per factory (with some awesome usage of Class.new) and defines methods on that class for each attribute declared in the factory files. This means Factory Girl doesn’t have to worry about sorting attributes anymore; every attribute is effectively lazily-evaluated so it’ll return the correct value every time. Factory Girl also uses inheritance for these anonymous classes, resulting in a pretty significant speedup of factory interaction (namely because we were copying all parent attributes and callbacks to each child to mimic inheritance before).

What Does It Mean?

Factory Girl is now faster!

Here’s some benchmarks from Factory Girl 2.3.0:

                                user     system      total        real
build x10000                4.920000   0.010000   4.930000 (  5.028088)
trait build x10000          6.180000   0.010000   6.190000 (  6.296030)
inline trait build x10000   5.870000   0.010000   5.880000 (  5.989512)
deep build x10000           8.100000   0.020000   8.120000 (  8.285039)
attributes_for x10000       3.200000   0.010000   3.210000 (  3.289043)
create x500                 1.010000   0.320000   1.330000 (  4.186271)

And from Factory Girl 2.4.0:

                                user     system      total        real
build x10000                3.050000   0.000000   3.050000 (  3.121359)
trait build x10000          3.260000   0.010000   3.270000 (  3.353590)
inline trait build x10000   6.700000   0.040000   6.740000 (  7.037460)
deep build x10000           3.400000   0.010000   3.410000 (  3.503984)
attributes_for x10000       0.820000   0.010000   0.830000 (  0.886641)
create x500                 0.710000   0.310000   1.020000 (  3.980102)

Grab a copy of Factory Girl 2.4.0 and speed up your suite!

Vim Macros and You

Fri, 06 Jan 2012 10:47:00 -0500

Ever get the urge to update a ton of files? I know I do. For example, I recently changed multiple hundred coffeescript files from the syntax of

MyGreatClass = Backbone.Model.extend(
  defaults:
    awesome: true
)

class @MyGreatClass extends Backbone.Model
  defaults:
    awesome: true

How long did it take me? A couple of minutes. Here’s how.

Ack (or Grep)

I like ack. To find all the files I need to edit, I’d write something like this:

ack '^[^\s].*\=.*\.extend\($' app/assets/javascripts -l

This finds everything that doesn’t start with a space, has an equals sign, and has .extend( at the end of the line.

Opening a list of files in vim

After looking over the results of ack and ensuring that everything that matched is what I want to edit, I’ll open those files in vim.

vim $(ack '^[^\s].*\=.*\.extend\($' app/assets/javascripts -l)

Vim Macros

If you’ve been using vim and haven’t taken advantage of macros (especially if you’re editing a lot of files in a similar fashion), you’re missing out. Open up vim and type :help q to get the nitty-gritty; I’ll summarize here.

To start recording a macro, press (in normal mode) q and then a letter or number. This will record a macro to whatever register you chose (via the letter or number).

Once you’re recording a macro, anything you type will be recorded to that macro so that it can be replayed. What I would type to change these files to the new format would be:

qqgg0iclass @f=cwextends2f.DGdd:wnq

Whoa, brain overload. Let’s break it down:

qq             # records the macro to the q buffer
gg             # first line in file
0              # first character in line
iclass @  # inserts class @ at the cursor and returns to normal mode
f=             # finds the first equal after the cursor
cwextends # changes the word (=) and moves to insert mode, adds extends, and returns to normal mode
2f.            # finds the second period after the cursor
D              # deletes the remainder of the line
G              # moves to the end of the file
dd             # deletes the line
:wn            # writes the file and moves to the next file in the list
q              # stops recording

This should be fairly straightforward; the only thing I really want to point out is the :wn. The n in that command moves to the next file in the list of files you opened with vim. This is one half of what makes editing all these files really fast.

Replaying a Macro

Now that you have your macro, it’s time to replay it. To replay a macro, press (in normal mode) @q (assuming you stored your macro into the q register). If you were to run that macro, it’ll run it against the current file, write the file, and move to the next. Since vim supports prefixing many commands with a number (for the number of times to repeat the command), running 100@q will run that macro on the first one hundred open files that I’ve opened with vim. Typically, this should be all you need to batch-edit, but if there are more files, just run that command again (or start with a higher number). If there are no more files to edit, vim will let you know.

Ben also mentioned recursive macros (my mind was blown) by adding @q right before the last q (which will run the q macro before stopping recording). Just make sure your q register is empty! This would allow you to run your macro once, without specifying the number of times to run it, because vim will run the macro until it’s out of files. Fancy!

Vim for fun and profit

Want to kick ass at vim? Pick up a copy of Vim for Rails Developers and become blazing-fast! If you want to hang out with fellow vim users to swap awesome tips like this, be sure to head to the Boston Vim Meetup!

Use Bundler's binstubs!

Thu, 05 Jan 2012 10:18:00 -0500

If you’re not using bundler’s binstubs with RVM integration yet, you should give it a try! This means you don’t have to type “bundle exec” ever again.

Setup:

One time, run chmod +x $rvm_path/hooks/after_cd_bundler
Once for each project, run bundle install -—binstubs

With rvm integration enabled, the “bin” directory is added to your path each time you cd into a project directory with binstubs. That means you can just run “rake”. If you aren’t ignoring the “bin” directory in your project, you should do so:


# .gitignore
bin/

Evaluating alternative Decorator implementations in Ruby

Mon, 26 Dec 2011 16:13:00 -0500

Recently, decorators have become a big part of my Ruby on Rails life.

We used them heavily in a recent client project, Harold Giménez wrote a great post about them, Avdi Grimm is writing about them in Objects on Rails, and Jeff Casimir has a great presentation about them.

Until recently, I still had some questions, however, such as:

Should I roll my own decorators?
If I roll my own, what are the tradeoffs of different implementations?
Do I care about the “transparent interface” requirements of the Gang of Four’s decorator definition?
Is it good or bad that the decorated object’s class is the decorator instead of the component?

I’d like to try to answer those questions here.

Intent

A decorator is a design pattern. Its intent, as described in Design Patterns by the Gang of Four is:

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Use it instead of inheritance

An example I’ve seen a couple of times for decorators is the “coffee with milk and sugar” example. One that I found particularly helpful was Luke Redpath’s article.

Here’s a Ruby implementation of that example using class inheritance (subclassing):

class CoffeeWithSugar < Coffee
  def cost
    super + 0.2
  end
end

class CoffeeWithMilkAndSugar < Coffee
  def cost
    super + 0.4 + 0.2
  end
end

The problems with inheritance include:

Choices are made statically.
Clients can’t control how and when to decorate a component.
Tight coupling.
Changing the internals of the superclass means all subclasses must change.

In Ruby, including a module is also inheritance:

module Milk
  def cost_of_milk
    0.4 if milk?
  end
end

class Coffee
  include Milk
  include Sugar

  def cost
    2 + cost_of_milk + cost_of_sugar
  end
end

How a decorator works

Using Gang of Four terms, a decorator is an object that encloses a component object. It also:

conforms to interface of component so its presence is transparent to clients.
forwards (delegates) requests to the component.
performs additional actions before or after forwarding.

This approach is more flexible than inheritance because you can mix and match responsibilities in more combinations and because the transparency lets you nest decorators recursively, it allows for an unlimited number of responsibilities.

Alternative implementations in Ruby

I’ve researched and found four common implementations of decorators in Ruby:

Module + Extend + Super decorator
Plain Old Ruby Object decorator
Class + Method Missing decorator
SimpleDelegator + Super + Getobj decorator

There’s probably others but these seem to be the most common.

Module + Extend + Super decorator

This implementation is described, and I think advocated for, in the Design Patterns in Ruby book. It consists of:

module
super
extend

Staying with the “coffee with milk and sugar” example for consistency, it is implemented like this:

class Coffee
  def cost
    2
  end
end

module Milk
  def cost
    super + 0.4
  end
end

module Sugar
  def cost
    super + 0.2
  end
end

coffee = Coffee.new
coffee.extend(Milk)
coffee.extend(Sugar)
coffee.cost   # 2.6

The benefits of this implementation are:

it delegates through all decorators
it has all of the original interface because it is the original object

The drawbacks of this implementation are:

can not use the same decorator more than once on the same object
difficult to tell which decorator added the functionality

The “Plain Old Ruby Object” (PORO) decorator

My recommendation is to start with this style of decorator in your Ruby programs, including Rails apps, and then move to something else only when this style fails you.

class Coffee
  def cost
    2
  end

  def origin
    "Colombia"
  end
end

class Milk
  def initialize(component)
    @component = component
  end

  def cost
    @component.cost + 0.4
  end
end

coffee = Coffee.new
Sugar.new(Milk.new(coffee)).cost  # 2.6
Sugar.new(Sugar.new(coffee)).cost # 2.4
Sugar.new(Milk.new(coffee)).class # Sugar
Milk.new(coffee).origin           # NoMethodError

The benefits of this implementation are:

can be wrapped infinitely using Ruby instantiation
delegates through all decorators
can use same decorator more than once on component

The drawbacks of this implementation are:

cannot transparently use component’s original interface

This drawback also means that this decorator isn’t really a decorator under the Gang of Four definition. I maintain that we should still call it a decorator, however, because it otherwise looks and acts overwhelmingly like a decorator.

This is a sticky opinion, however, so let’s consider the “transparent interface” requirement from Gang of Four in more detail.

Do we care about the “transparent interface” requirement?

Let’s say the interface we care about decorating is cost. If so, we don’t need to also support origin method. Then, the PORO decorator meets our practical needs.

By redefining the scope of “interface” to be the subset of the object’s entire interface that we care about, we meet the Gang of Four definition. Is that cheating?

I say no. Consider how many methods are on Object in Ruby 1.9.3:

> Object.new.methods.size
=> 56

An Object in Rails has more than double the number of methods:

> Object.new.methods.size
=> 118

An ActiveRecord Object has even more:

> User.new.methods.size
=> 366

We’re not using hundreds of methods on each object, especially in typical use from a Rails view.

However, if we used the PORO decorator in a Rails app to decorate an ActiveRecord object, we’re probably reducing the interface by about 300 methods.

Depending on how we use the object in the app, that may or may not be a problem.

In practice, when TDD’ing a new feature, I have not found this to be an actual problem. That’s why I say start with this decorator.

If it’s not a problem, great. Your test suite should tell you. You might decide to add one or two more methods that do very clear delegation:

def comments
  @component.comments
end

def any?
  @component.any?
end

However, you might feel like this is tedious or repetitive. So, let’s say we do care about the “transparent interface” requirement later on.

That’s usually accomplished with method_missing or something from Ruby’s delegate library like Delegator, SimpleDelegator, DelegateClass, or Forwardable.

“Method Missing” decorator

Here’s a method_missing implementation of a Ruby decorator:

module Decorator
  def initialize(component)
    @component = component
  end

  def method_missing(meth, *args)
    if @component.respond_to?(meth)
      @component.send(meth, *args)
    else
      super
    end
  end

  def respond_to?(meth)
    @component.respond_to?(meth)
  end
end

class Coffee
  def cost
    2
  end

  def origin
    "Colombia"
  end
end

class Milk
  include Decorator

  def cost
    @component.cost + 0.4
  end
end

coffee = Coffee.new
Sugar.new(Milk.new(coffee)).cost   # 2.6
Sugar.new(Sugar.new(coffee)).cost  # 2.4
Sugar.new(Milk.new(coffee)).origin # Colombia
Sugar.new(Milk.new(coffee)).class  # Sugar

The benefits of this implementation are:

can be wrapped infinitely using Ruby instantiation
delegates through all decorators
can use the same decorator more than once on the same component
transparently uses component’s original interface

The drawbacks of this implementation are:

uses method_missing
the class of the decorated object is the decorator

Do we care that the class is the decorator?

We should not. This is Ruby, land of duck typing.

However, Rails inflects (object.class.name) for polymorphic relationships, form_for, and other places. When I tried to convert a few older Rails view helpers to decorators, this was an actual problem in the form of ActiveRecord errors during test runs.

In some cases, this revealed a deeper problems. By re-working the model code, I was able to use PORO decorators and the overall codebase was cleaner. Other times, I just thought it was less time-consuming to make the class appear to be the component’s class and move on.

“SimpleDelegator + Super + Getobj” decorator

So, a Rails compromise is this decorator implementation. I’m trying to use it only as a last resort.

class Coffee
  def cost
    2
  end

  def origin
    "Colombia"
  end
end

require 'delegate'

class Decorator < SimpleDelegator
  def class
    __getobj__.class
  end
end

class Milk < Decorator
  def cost
    super + 0.4
  end
end

coffee = Coffee.new
Sugar.new(Milk.new(coffee)).cost   # 2.6
Sugar.new(Sugar.new(coffee)).cost  # 2.4
Milk.new(coffee).origin            # Colombia
Sugar.new(Milk.new(coffee)).class  # Coffee

The benefits of this implementation are:

can be wrapped infinitely using Ruby instantiation
delegates through all decorators
can use same decorator more than once on component
transparently uses component’s original interface
class is the component

The drawbacks of this implementation are:

it redefines class

I honestly don’t know exactly what sort of problems can result from using method_missing or redefining class but I imagine they’ll be manifested in the form of a time-consuming debugging session.

Plan of action

I think I now understand the tradeoffs of different Ruby implementations and have a plan for using them:

PORO to start
SimpleDelegator if I need the “transparent interface” requirement or the decorated object’s class is causing problems for Rails

I still have other questions like:

What’s the difference between a decorator and a presenter?
What’s the difference between a decorator and a strategy? And a composite?
Should I use a gem like Draper?
Is there any reason to use classic Rails view helpers anymore?
Should I be using a different templating system like Mustache?

I think I have answers to some, but that’s another post…

A quick screencast that shows how I use CSS snippets to speed up...

Wed, 21 Dec 2011 09:00:00 -0500

A quick screencast that shows how I use CSS snippets to speed up my workflow.

Links Mentioned in video:

This week in open source

Fri, 16 Dec 2011 17:03:24 -0500

paperclip

Much of the work over the past week was done in paperclip, so now you can upload files to your Rails apps with more flare and style!

It now supports an option for keeping old files, so you can pass :keep_old_files to has_attached_file and, when you destroy an attachment (@user.avatar.destroy) it won’t actually delete the underlying files (345ec74). Many people find this useful for S3 storage, which hints that there may be a deeper problem elsewhere. This is thanks to Eike Bernhardt (teefax) but was originally written by Philippe Creux (pcreux).

Christoph Lupprich (kitto) saw a quick way to speed up the #public_url method for Fog storage using AWS as the provider, so he did (989ec0e).

I’ve long wanted a migration helper, and Daniel Schierbeck (dasch) wrote it with some git cleanup from Alexey Mahotkin (693b528, b922111, f82c0d9, f3eacd2, e0a6732, ffbfc24, 500f1bb, b70ffbc, 65a6ae8). It looks like this:

class AddAvatarColumnsToUser < ActiveRecord::Migration
  def self.up
    change_table :users do |t|
      t.has_attached_file :avatar
    end
  end

  def self.down
    drop_attached_file :users, :avatar
  end
end

There were also some important internal changes. For example, Prem Sichanugrist (sikachu) replaced the AWS::S3 gem with AWS::SDK (1df1b03, 81129ad, 88a8af9, 75f413d, 2cf7378). He called out AWS (amazonwebservices) and Trevor Rowe (trevorrowe) for helping, and John Joseph Bachir (jjb) updated the docs appropriately (308f1a0).

Prem also got Paperclip passing on Rubinius (001fd99).

In bug fixes, base URLs with a ? but no = will produce Paperclip URLs using ? (128d664 and bb22be3). Prem thinks that’s the right behavior now, but it’s tricky to nail down.

Nick Padgett (npadgett) found an edgecase where we were calling strip on a non-string object, sometimes, and fixed that (34913f1).

Dimitrij Denissenko (dim) handled the case where using the :id_partition pattern in a URL or path pattern raises a NoMethodError on an unsaved resource (ac82244). He and I are now enemies for life for his use of nil.

Prem fixed another bug: if you have a path or URL pattern with :class in it it will show a warning. He removed this warning (b4ff2c5).

Prem worked with Steve Richert (laserlemon) to show the Gemnasium results in the README (3e20907 and 777ac90), and Prem also updated the README to be more readable (adcd03c).

fake_braintree

The fake credit card processor, fake_braintree, hit 0.0.6 (eed875e and 0934f1e) this week as Ben Orenstein (r00k) added support for discounted subscriptions (757c0aa) and Gabe Berke-Williams (gabebw) exposed the transactions that have run (8dde09c and ab93137).

suspenders

Taking a stance on whether we play along with the little Open Directory Project game, suspenders now defaults to NOODP on every page which, as Matt Jankowski (mjankowski) points out, tells Web crawlers to never bother looking for ODP details (6275d0f).

shoulda-matchers

The sweet shoulda-matchers collection of RSpec matchers now has more accurate error messages for the allow_value matcher (25c2623), thanks to Clemens Helm (clemenshelm). It uses the underlying internationalization information to generate this.

bourbon

Another documentation update on bourbon as Phil LaPier (plapier) explained that multiple background images with shorthand notation are unsupported (798aa1c), after clarifying that multiple background images themselves have fancy comma-separated syntax (aa66831).