GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS

How grep got its name

Wed, 28 Jul 2010 13:58:00 -0400

thoughtbot is pairing up with Ben Orenstein to present a Vim course, this time at WorkBar. As part of this collaboration WorkBar is offering $50 off your first month’s membership if you register for the Vim course.

One thing you will discover at this course is the history of the command `grep’. This all starts back with `ed’, the original unix editor. ed was a command-line editor that worked identically to the colon-commands in vi and vim—in fact, you can press Q to get into ed mode (then type vi to get back into vim). From the ed editor you can issue common line-oriented commands like s, d, y, and so on:


:%s/rdoc/docr/g
:/include/d

If you’re following along at home you may wonder “how can I see the contents of this file?” Well if you just want to see every line you can use %p (% is “the whole file”, and p is “print to screen”), though it’s more likely that you want to see a small series of lines. 10,20p will show you lines 10 through 20, but maybe it makes more sense to see all lines matching a regular expression.

From ed, to see all lines matching “include”, use g/include/p. To see all lines matching “docr” use g/docr/p. In general, to see all lines matching the regular expression “re”, use g/re/p.

… And that’s how grep got its name.

Rock 'Em Sock 'Em Robots

Mon, 26 Jul 2010 15:30:00 -0400

Node.js Knockout is a programming competition, similar to the Rails Rumble, focused on the increasingly popular node.js. As a company and individuals we’ve been participating in and sponsoring the Rumble from the beginning. And we’re happy to announce we’re also sponsoring and participating in the Knockout.

Introducing below, from Lenexa, KS, the not-made-for-actual-boxing, image-not-representative-of-actual-prize, zero-time champion of the world:

Let us know what you plan on building in the comments. See you in the ring.

Flutie

Mon, 26 Jul 2010 10:15:00 -0400

Background

When we start on new client projects or internal apps, we don’t always start the HTML/CSS buildout the same way. Sometimes a client has sketches; sometimes wireframes; sometimes they have a brand/identity in place already - there’s a big variety in what materials they come to us with. Likewise, when we start our design process, we don’t always use the same exact things we did the last time. Part of this is a result of wanting to constantly experiment and make each time better than the last by learning - and part of it is just the unique style of each designer and their thought process.

Regardless of how we got there though, one major pain point was always in the first few days of HTML/CSS building. Would we use a css “framework”? Which one? Should we put a “reset” in place but no framework? Should we start with literally nothing and let the site dictate as we go? Should we start with specific CSS rules and stay narrow, or start with very general CSS rules and assume we’ll have re-use down the road?

Depending on the team we had working on an application, the answers to these questions were always different.

Goals

We decided that we did not want to build a new CSS framework, but that regardless of any particular approach, we wanted to have these things on each project:

A consistent set of CSS styles that every project could start with
A consistent internal mindset about “start general; then get specific”
The ability for developers to create “normal html” and not get burned by some weird CSS float rule to get unexpected results before putting something in front of a client.
The ability to show designers and developers (and maybe clients) a “style guide” type of page which would show how elements would be displayed unless they were overridden.

One thing maybe worth noting is that we put the entire HTML/CSS skillset into the “designer” bucket at thoughtbot. We don’t have a “front end developer” position to do HTML/CSS/JS exclusively. We attempt to hire developers with experience and comfort working with front end technologies, but we primarily consider it a design responsibility to get HTML and CSS work done correctly. Even with our growing design team, design time is usually at a premium and we want to grease the wheels as much as possible to maximize efficiency.

Features

To that end, we created flutie. Flutie is a Rails 3 Engine, distributed as a gem. Note that this is NOT a css framework or grid system. It is very opinionated about what basic type size, form styles, list/table style and so on should be — but it is very unopinionated about how you go about creating an overall site layout, how you make grids, how you position things, etc. There are dozens of other tools for those purposes. This is really a “how can I start with something that doesn’t look awful” tool. We want to ensure that when a developer with no specific CSS or design knowledge creates some HTML in an application, they produce something that we’re not embarrassed about.

Flutie provides…

A collection of stylesheets which we believe are a reasonable starting point for general layout and relative size.
Pretty basic form styles, and styles for the rails flash.
A page at the /styleguides URL in development mode to view this default state - or to view all the styles within the application layout. We render within your own layout first, and you can click “default layout” to see flutie by itself.
The ability for plugins and the main application to insert partials into the styleguide, to view sample styling.
CSS which is generally simple to override.

We also discovered a rails feature that we decided to take advantage of. You can “register” symbols which point to arrays and will be expanded when using stylesheet_link_tag. For example, this will expand to include the 7 stylesheets in flutie alongside the “admin” stylesheet, and cache them all together.

<%= stylesheet_link_tag :flutie, ‘admin’, :cache => true %>

Install

To get flutie in place in a rails3 app, just add it to your Gemfile…

gem 'flutie',           '1.0.3'

For rails 2.x apps, you can pull from the rails2 git branch…

script/plugin install git://github.com/thoughtbot/flutie.git -r rails2

Once installed, you should run a setup rake task

rake flutie:install

…which will copy some stylesheets into the public directory of the application.

After that, put the :flutie symbol somewhere in your stylesheet_link_tag or equivalent area.

<%= stylesheet_link_tag :flutie, 'screen', :cache => true %>

After that, start your server, browse to /styleguides, and check it out.

What does this look like?

Click through for full screenshot…

What To Do When You Don't Know What To Do

Fri, 23 Jul 2010 12:39:48 -0400

Sometimes, test driven development is really annoying, and the abundance of untested applications out there suggests that I am not the first person to have had this thought.

The thing is, there are limitations to test driven development. The workflow of test development essentially goes like this:

Create a user story that encapsulates a chunk of functionality of the application
Write tests for this story (which should fail before you have implemented anything)
Write the code to make the tests pass

What is missing from this flow, however, is a period of time to consider the overall design of the code in the application. If you’re not careful, your program can end up like an old school map of Africa - the small details are right, but the overall structure is off.

Test Driven Development rests on the assumption that you basically know the optimal way to make your tests pass in advance. If you’ve written several similar apps, you probably do know how to fill in your tests. However, if you’re new to programming, or if you’re creating a unique program, you may not.

Recently, my coworker Jason and I encountered this problem when working on the open source app GNITE. GNITE requires an internal large tree structure that can support up to 5 million nodes. Neither of us had worked with trees that large before, and we didn’t know what the stumbling blocks were going to be. So, we decided to spike it out.

A spike is a quickly written, untested piece of code that’s intended to be thrown away. You intentionally abandon your best practices in the interest of quickly learning about good ways to design your app. Once you’ve gained everything you can from it, however, you scrap it and don’t build anything else off it.

In our case, we started out fooling about with jsTree, to display the tree, and the ruby gem ancestry, to organize the tree structure in the database. (If you want to check it out, it’s up on github here and you can see it working here.) As it turned out, ancestry and jsTree worked well together - ancestry stores the entire lineage of each node on the node itself, which made things like asynchronous search work well with jsTree.

Happy with our initial findings, and looking to push our luck, we extended our program to parse large, compressed tree files. Once we had the large tree in the database, the display behavior remained satisfactory, but the act of parsing a tree took a long time - too long to be a regular occurrence on the website. Initially, we had considered making parsing trees a regular part of the work flow, but the 5 to 10 minute load times suggested that we would need to look into some sort of caching (or, possibly, a different way of storing nodes on the back end with a quicker insertion.)

In the end, we decided caching uncompressed trees in the database could be a potential solution, given the amount of space we had. In our case, the most straightforward approach for displaying trees worked out well, but not for saving and loading trees.

Now that we have a loose idea of the structure we’re going to pursue, we can keep it in mind when we’re writing our code. And, we have some really relevant example code to work off, which will (hopefully) make the “getting the tests to pass” step in TDD quite a bit easier.

Missed connections: I saw you testing my website

Wed, 21 Jul 2010 11:35:00 -0400

Usability testing is like flossing: everyone knows it’s important, but they don’t do it nearly as much as they should. Because let’s face it, making sites is a lot more exciting than testing them. Well, this past week we ran our first round of in-house usability tests and wanted to share how we did it, what we learned, and what we need to improve.

This presentation by Meetup on Lean Usability was a big help in putting together our initial plans. It does a good job of laying out the pros and cons of several approaches and points out what you should focus on at the beginning, before you have any experience to guide you. Read it.

How we did it

We chose to test an important form that we were in process of redesigning for a client. With differing opinions about the approach to certain aspects of the redesign, it was a prime candidate for usability testing.
We decided to use Silverback to capture the test sessions. We liked it because of the ability to record audio and video of both the user and the screen, giving us an objective record of what happened during the session that could be reviewed later.
We placed an ad in the “volunteers” section on craigslist. The message gave a quick summary of what we needed the volunteers to do, who we were, and directed them to a Wufoo form where they provided us with their information. We offered $30 for about 30 minutes of their time and ended up having almost 70 responses in less than 24 hours.
We decided to schedule 5 sessions, one right after the other, during one afternoon. We picked 5 people whose schedules worked with ours and emailed them to let them know we had scheduled a session for them. We also emailed everyone we didn’t select, thanking them for contacting us.
Before the sessions, we wrote up scenarios that would be given to the user. We decided on three tasks, each more complex than the last, that would focus on a key point of the clients’ form we were redesigning. We also prepared a release form that let testers know that we’d be recording audio and video of their session, that this would be viewed by thoughtbot and our client, but would not be used for any other purpose.

What we learned

We sent a confirmation message the morning of the testing to all the testers, and ended up having 4 out of 5 show up.
The scenarios/instructions are important. Our first tester was completely stumped by the first scenario, and we realized that we had not been as clear as we could have been. We quickly modified the instructions before the next session.
Silverback has drawbacks. Each of our sessions was between 22 - 30 minutes and takes up more than a GB of hard drive space. Additionally, exporting video of the sessions takes a long time. On a MacBook with an dual core processor and 2 GB of RAM, it takes 2 to 3 hours. (It still takes over an hour on a maxed-out MacBook Pro.)
It takes time. Recruiting testers, writing scenarios, running sessions, exporting video, sending the results — all of these things take time. Make a realistic estimate of how much time you’ll actually be investing in doing usability testing.

What to improve

The users we recruited for this round of testing didn’t need to have any special qualifications. As we do more testing, we’ll likely encounter a situation where we’ll need users with specific knowledge related to the site they’ll be testing. (Running usability tests on Hoptoad would present this problem.) It’s unclear if craigslist will work in these situations.
While it’s impossible to completely remove any confusion that the instructions may introduce, we’ll need to do a better job of writing scenarios that are clear.

How To: Take Notes Like a Champ

Tue, 20 Jul 2010 10:37:00 -0400

Information Overload

One of our newest projects here at thoughtbot is a taxonomic naming app called GNITE which we’re building for the Marine Biological Lab. As designer on this project my first challenge was to get a basic understanding of the subject matter and the goals of the project, but I found the information to be complicated especially for someone new to taxonomy. We had the pleasure of visiting the Marine Biology Lab in Woods Hole, MA on Cape Cod recently and in the meetings I dusted off an old note taking trick I frequently used in college but with new tools — an iPad and Adobe Ideas app.

Taking notes vs. absorbing information

Design is often about reducing complex systems to their simplest form. Our meetings at the Marine Biology Lab could have produced pages and pages of comprehensive notes but my goal was to organically absorb as much information as possible without the distracting task of transcribing information. Using Adobe Ideas, an iPad and a stylus, I took visual notes, writing down key pieces of information, embellishing them, and organizing them visually. The embellishment is the key part - it leaves your ears open to what’s being discussed. When looking back at my notes I can clearly remember who was talking, what the sentiment was, and other subtle things that could be forgotten during normal note taking. The visual nature of the notes jogs my memory in a way pure text or handwriting doesn’t. The outcome is an understanding of a simplified gestalt which isn’t burdened by details.

Click each image to view it larger:

Adobe Ideas allows fractalesque zooming. You are able to use vast scale differences to communicate importance as well as benefit from a very flexible canvas, so you almost never run out of space taking notes.

Check out that mushroom! Someone said “fungi” so I drew a mushroom. As my theory goes, I absorbed whatever was said after that (it was an anecdotal tale of conflicting fungi names, I believe).

But won’t you miss important details?

The drawback to taking notes like this is that many details will never get written down. If those details are critical bring a voice recorder. In my case there were two developers in the meetings as well, so I was confident our team-like approach would yield all necessary information (and it did).

Life after NDA’s

One of the most exciting aspects to this project is it’s open source which opens the possibility to documenting the building process in ways we usually can’t with most client work. This is the first in what I hope will be a series of posts documenting the design process all the way through to the final product.

CAPE CODE

Thu, 15 Jul 2010 14:19:00 -0400

Still without plans for August? Did you know that August is our nation’s warmest and most-traveled month? Looking for a nice trip? Well…have I got a deal for you!

Come relax on the sandy shores of Massachusetts’ own wicked beautiful Cape Cod at our previously announced event: CAPE CODE! Join thoughtbot’s team of designers and developers and stiff management types while we bask in the glorious New England sun. It’s the most relaxed you can be and learn about web programming at the same time.

Hey, maybe you can dig up some clams while you’re there.

Logos Suck When Branding Yourself

Wed, 14 Jul 2010 11:00:56 -0400

I’ve recently begun a redesign of my portfolio and my biggest blocker is never knowing what to do for a logo or header. Then, last night, it hit me. You don’t need to create anything. Crazy, right? Maybe not for some of you, but for a designer like me, that’s unheard of.

So how do people recognize me?

The answer to this struck me while messing around on twitter, my face is my brand. I recognize people by their twitter avatar. When someone changes their avatar, I have no idea who is tweeting at me. This is incredibly strong branding and most people don’t even realize it. Now just imagine if every place you were, virtually and physically, always had your brand. If you haven’t figured it out yet, you can make this happen. Make your face your brand and you will reinforce whatever you stand for, everywhere you go. More than just your face being your brand, make one particular photo your brand, everywhere. I can’t count the number of times I’ve seen the same people on different sites and recognized them only because they used the same photo. It’s much weaker, and almost pointless, if you change your photo from place to place.

Dan Benjamin wrote a great post on his blog, Hivelogic, about the significance of your avatar, and how never changing it is the only way to go. Smart guy over there!

Trash that old logo

Some people want to use just their name or some forgettable mark. I was a disciple of this belief for the majority of my design career; I used a fedora and my name set in Museo. That’s idiotic. I don’t wear a fedora, and my name is unmemorable. If I’m banking on an employer remembering me they aren’t going to think of the guy that had a fedora as his logo. They’re going to remember my attitude, the interaction between us, and most importantly my face. When they’re thinking of my face, I need it to be easily findable. I want it on the top of my résumé, website, and even my business cards!

Think about these cases

I bet you will recognize a few photos and their subject by a simple description, without even showing you the photo.

Everyone knows the creator of Myspace, and that photo he never changed. Imagine if Tom changed his photo every week like most of the power social network users do. Tom would be nobody, unrecognizable, and forgotten forever. Now, even though Myspace is a joke, people from our generation will remember Tom and his face for a long time. In my opinion he is still more recognizable than Mark Zuckerberg.
Remember that blonde bombshell from the 1950s in The Seven Year Itch? Standing above the subway vent, holding her white dress down, as the gust from below blew her dress every which way. Everyone knows that powerful picture of Marilyn Monroe and while she never intended for it to be her brand, it is definitely something she is remembered by.
How about Steve Jobs? He knows this secret. You’ll always see him in his black turtleneck and thin framed glasses. He actually recreates his single brand image every time he goes out in public. This is the perfect case of branding yourself. It may get boring, but it’s instantly recognizable.

Actually doing it

Like anything else in life, if you’re going to do this, don’t half ass it. Don’t find some weak camera phone picture of you somewhere. Pay, barter, or do whatever you need to get a good photographer to produce at least one good picture of you. thoughtbot hired Jamie Beck, a great photographer we know from New York City. She did an all star job and now we all have super photos to brand ourselves with. You should do the same, and see how much more people begin remembering and recognizing you.

Suspenders now with RSpec, jQuery, and more

Tue, 13 Jul 2010 08:55:00 -0400

Suspenders is a Rails project template used as a base app for all of our client work. It has gone through a few changes that better reflect our development stack and also allow us to test changes to suspenders itself.

RSpec

As you may know, we are spec’ing our apps with RSpec along with shoulda matchers now. This along with cucumber for integration tests is the testing stack that we’ve been using for a while. RSpec replaces Test::Unit in suspenders.

jQuery

For our front-end behavior we’re using jQuery. The ecosystem around jQuery Core, jQuery UI, and the slew of third-party plugins help bring life to our applications. Using jQuery also gives us an easy transition for mobile web app development with tools like jQTouch. jQuery replaces prototype/scriptaculous in suspenders.

Dependencies

Our projects depend on a number of gems. Some have native extensions and therefore cannot be vendored in the project - I’m talking about our friends nokogiri and RedCloth. In the past we would check if the gems where installed, and installed them if they weren’t. Now that suspenders-gem is the preferred way of installing and using suspenders, we have added these as rubygem dependencies on our gemspec.

Testing suspenders

The creation of suspenders-gem affords us the opportunity to write integration tests for suspenders. In the past, testing updates to suspenders was a manual process because of the nature of the template. But from now on we can write cucumber scenarios that verify that the suspenders project starts in a clean state.

Take her for a ride!

Along with these major changes, versions of all other dependencies were bumped to the latest stable versions. Take suspenders for a ride and let us know what you think:

gem install suspenders
suspenders create billion_dollar_idea

Capturing Errors on a Global Scale

Thu, 08 Jul 2010 10:33:00 -0400

Has your database gone down recently? What about timeouts from third-party services? Exceptions can be raised anywhere in your app, and Hoptoad’s here to track them for you. Problem is, these exceptions can manifest themselves in your controllers or models, and that’s not helpful when you have to sort through all of them because of Hoptoad’s grouping logic.

To help, we’ve introduced global error classes for all paid accounts. Per project, you can list exception classes that you’d like to be grouped together in Hoptoad. We handle the nitty-gritty so your life is easier when you’re trying to resolve these issues that come up. Since we’re not ones to leave you high and dry, we’ve started everyone off with a list of common global exceptions from Rails projects:

Mysql::Error
MemCache::MemCacheError
Mongrel::TimeoutError
ThinkingSphinx::ConnectionError
Net::HTTPFatalError
OpenURI::HTTPError
ActiveResource::ResourceNotFound
ActiveResource::TimeoutError
ActiveResource::ServerError
Net::SMTPServerBusy
Net::SMTPFatalError
Net::SMTPSyntaxError

To change the list of global errors, go edit a project.

Under the name of the project, you’ll see a list of Global Error Classes (again, prepopulated with a handful of common errors). We separated by new lines, but spaces or commas will work as well.

Once those are set up, you’re ready to roll! Here’s a snapshot of how a global error shows up after adding RuntimeError to the list.

That’s about all there is to it! Note that this isn’t retroactive, so your old errors will still be in the same groups as they were before. Another reminder: if you’re on our Egg plan, be sure to upgrade; your first month is free!

Quit your job and come work for thoughtbot

Thu, 08 Jul 2010 09:59:00 -0400

Things are humming along and we’re ready to add another designer to the team.

We’re looking for someone who can produce great designs, really cares about the quality of their HTML and CSS code, and wants to be a part of a kick ass team that builds great stuff.

If this is you, and you’re either in Boston or willing to relocate, get in touch, because we want to talk to you.

Test Time Bombs

Fri, 02 Jul 2010 14:29:00 -0400

Testing with times and dates have come a long way, now that Timecop is around. Prior to Timecop, we would use a stubbing library like Mocha to stub out just what we needed, but why do that when Van Damme could beat the right values out of Time?

The Bomb

I wrote this Cucumber feature, models have been changed to protect the innocent.

  Scenario: List latest posts under a tag
    Given the following posts exist:
      | Post   | Tag list | Created on   | Expires on   |
      | post1  | yankees  | May 1, 2010  | July 1, 2010 |
      | post2  | yankees  | June 1, 2010 | July 1, 2010 |
      | post3  | yankees  | May 5, 2010  | July 1, 2010 |
      | post4  | yankees  | May 30, 2010 | July 1, 2010 |
      | post5  | yankees  | May 29, 2010 | July 1, 2010 |
    When I visit the tags page
    And I follow "yankees"
    Then I should see the following posts in order:
      | title  |
      | post2  |
      | post4  |
      | post5  |
      | post3  |
      | post1  |

Most of these steps are from factory_girl and webrat, except for the last one, which parses the page using Nokogiri and looks for the titles in the order listed. This feature passed when I wrote it (June 30th). Of course, on July 1st, I ran the test again, and FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.

Timecop wasn’t too helpful here, because the code actually used MySQL’s NOW() function instead of accepting a date parameter for today. So that’s one thing I could have fixed instead, but I didn’t want to touch any other code in the app.

Another obvious solution: bump up the expired date by a year, forget about it until next year. If you’re thinking of this solution, try imagining this guy kicking you in the face:

Future-proofing

Van Damme’s given us another chance. Let’s refactor this feature.

   Scenario: List latest posts under a tag
    Given the following posts with tags exist:
      | title  | tag list | created              |
      | post1  | yankees  | 2.months.ago         |
      | post2  | yankees  | 1.month.ago + 4.days |
      | post3  | yankees  | 1.month.ago          |
      | post4  | yankees  | 1.month.ago + 2.days |
      | post5  | yankees  | 1.month.ago + 1.day  |
    When I visit the tags page
    And I follow "yankees"
    Then I should see the following posts in order:
      | title  |
      | post2  |
      | post4  |
      | post5  |
      | post3  |
      | post1  |

Using a bit of ActiveSupport’s time helpers, we can future proof this step by always moving forward instead of locking to a specific date. The step definition then uses eval to get the real dates back:

Given /^the following posts with tags exist:$/ do |table|
  table.hashes.each do |row|
    created_on = eval(row['created'])
    Factory(:post, :title      => row['title'],
                   :tag_list   => row['tag list'],
                   :created_on => created_on,
                   :expires_on => created_on + 1.year)
  end
end

KABOOM

So this is a simple way of avoiding time bombs in your tests. There’s no real way to prevent them always, you just need to consider how you’re dealing with time based code. If you’ve left time bombs in your test suites, feel free to own up and share your story too. Before Van Damme gets you.

iPad sketching app review

Tue, 29 Jun 2010 10:34:00 -0400

Photo by Jamie Beck

Sketching on an iPad

When I first held an iPad I knew it would have significance to a web designer as a sketching tool. It’s portable, connected, and friendly, and with the apps that have emerged since launch we now have many options to choose from based on what needs and wants we might have. I’m reviewing three apps: Adobe Ideas, Draft, and Sketchbook Pro from the perspective of a web designer, focusing on tasks such as layout sketching. I aim to help you decide which tool or tools is best suited for you and your working environment.

Tools of the trade

Before discussing the apps I should point out I do all sketching on the iPad using a stylus, specifically the Pogo Sketch, so unless you find your index finger particularly capable, I suggest purchasing a stylus.

Adobe Ideas

Free (app store link)

Adobe Ideas is a basic sketching app that is geared towards clean results and simple, quick usage. You have one marker tool at your disposal which can be adjusted with radius, color and opacity controls via a vertical slider. When sketching, the UI is limited to a slim control bar on the left which can be hidden, but it’s unobtrusive enough that it doesn’t distract.

Adobe Ideas’ files are vector based which comes with two fantastic upsides: you’re able to zoom in and out easily and to extraordinary levels, and the exported file is a lightweight .PDF which can be manipulated or printed easily. The resolution independence means you can magnify to add small, sophisticated details, and pan around the canvas in case your drawing ends up bigger than you intended. Sketches are auto-saved so you don’t have to worry about losing work or saving files. I use Adobe Ideas on a daily basis and since it’s free I highly recommend giving it a try.

Pros: Free, simple but powerful toolset, lightweight vector export

Cons: none

Draft

$9.99 (app store link)

When 37 Signals released Draft I was curious how their pragmatic approach would translate in to an app, particularly one in a realm I am highly interested in. Draft is task oriented: the tools are extremely limited (one brush radius, and only white and red) and one eraser. The advantages to this approach are a consistent output, and with no options to monkey with you are kept from getting lost worrying about style. This is, in essence, a grand equalizer - someone with artistic abilities and someone without will produce very similar sketches using Draft. Draft has a static canvas which can become a problem if you run out of space, but I quickly got used to the limitation. At the time of this writing, Draft only has one level of undo which can be frustrating given the longstanding prevalence of multiple undos in most creative apps.

Draft’s killer feature, however, is integration with 37 Signals’ own chat app, Campfire. Through a sharing button you’re two taps away from posting the image instantly in a Campfire chat room — and if you use Campfire as extensively as we do at thoughtbot, this feature will blow your mind. Draft is all about communicating ideas quickly, and if you think of it as a portable, miniature dry erase board you will be satisfied.

Pros: Task oriented approach, excellent Campfire integration, consistent output

Cons: $9.99 is potentially prohibitive to some users given limited features, only one level of undo

Sketchbook Pro

$9.99 ($3.99 until July 4th) (app store link)

Autodesk’s Sketchbook Pro is a different breed of sketching app from the previous two. It’s a derivative of a desktop version, and it inherits many of the features and capabilities. And when I say “capabilities” I mean a shocking feature set that is almost hard to believe it’s available on an iPad - such as layers, natural brushes, .PSD export, and a professional color picker. When you’re sketching on Sketchbook Pro it feels very close to sketching on paper with traditional media. Despite the iPad’s lack of pressure sensitivity, brush strokes can taper off at the end giving a very natural and satisfying experience. There is also the ability to magnify the document, but since it’s a bitmap image zooming exposes pixelization.

For replicating natural media there is no comparison - Sketchbook Pro is incredible, but for web design and communication purposes the wide variety of features and brushes can often leave you tweaking and stylizing, instead of focusing on the task. It has a deep UI that requires a learning curve but mastery can open some exciting possibilities and ease of use. For those experienced in traditional media and who may feel stifled by Adobe Ideas’ uniform tools, Sketchbook Pro will go a long way towards satisfying your delicate artistic sensibilities.

Pros: Amazing natural media capabilities, professional toolset, .PSD export

Cons: UI takes getting used to, numerous features can distract from task oriented sketching

What else?

While using these apps I’ve experimented and looked for useful ways to shoehorn them into my work routine. Both Adobe Ideas and Sketchbook Pro allow for importing of images which you can draw on top of - as an example I’ve drawn on a browser window and utilized a grid system:

Conclusion

All three of these apps are well designed and well executed, so choosing one (or a tag team of two) depends on which best fits in to your workflow. If flat, smooth sketches and vector-flexibility is key to you, Adobe Ideas is a fantastic solution. If you’re an avid Campfire user or value a focused approach, Draft is a great choice. If you’re a suppressed artist living in a designer’s body, Sketchbook Pro will let you embellish sketches with an imbued sense of creativity.

This should_change your mind

Thu, 24 Jun 2010 13:38:00 -0400

There’s been a bunch of hullabaloo about our recent deprecation of the Shoulda macros should_change and should_not_change. A lot of people have asked, “why remove it?” Short answer: we don’t use it anymore. Long answer: it’s confusing and may encourage bad programming practices.

Consider this example of should_change:

context "updating a post" do
  setup do
    @post = Post.create(:title => "old")
    put :update, :post => {:title => "new"}, :id => @post.to_param
  end

  should_change("the post title", :from => "old", :to => "new") { @post.title }
end

This reads well and seems to be fairly straightforward. Sadly, this doesn’t work because of how should_change works internally (hence the confusing part). It would actually need to be written like this:

context "given a post" do
  setup do
    @post = Post.create(:title => "old")
  end

  context "updating" do
    setup do
      put :update, :post => {:title => "new"}, :id => @post.to_param
    end

    should_change("the post title", :from => "old", :to => "new") { @post.title }
  end
end

The @post instance variable needs to be assigned a context above the context containing should_change. I told you it was confusing.

Now, onto the bad practice aspect. This tests that the post was saved! Come on, we don’t want to do that here. That’s why we write Cucumber scenarios! We’re testing the controller, right? If that’s the case, then we shouldn’t care whatsoever if update_attributes worked with specific data passed to it, just that it was called and that we handle the result accordingly.

context "updating a post" do
  setup do
    @post = Factory :post
    Post.stubs(:find => @post)
  end

  context "when the update is successful" do
    setup do
      @post.stubs(:update_attributes => true)
      put :update, :post => {:title => "new"}, :id => @post.to_param
    end

    should set_the_flash.to(/updated/)
    should redirect_to(posts_path)
  end

  context "when the update is unsuccessful" do
    setup do
      @post.stubs(:update_attributes => false)
      put :update, :post => {:title => "new"}, :id => @post.to_param
    end

    should render_template(:edit)
    should assign_to(:post).with(@post)
  end
end

This is more inline with what we really want to test; that the controller handled update_attributes correctly when the update worked and when it didn’t. Leave the model logic and whether it should save or not in the model (and its tests), and test the controller to ensure it handles whether the model was updated.

I mentioned before that Cucumber scenarios should cover overall integration. Something like these would work:

Scenario: Update a post successfully
  Given I am signed in
  And I authored a post titled "Great Scott"
  When I go to edit the "Great Scott" post
  And I fill in "Title" with "Willard Scott"
  And I press "Update"
  Then I should see the flash message "Your post was updated successfully"
  And I should have authored "Willard Scott"

Scenario Example: Update a post unsuccessfully
  Given I am signed in
  And I authored a post titled "Great Scott"
  When I go to edit the "Great Scott" post
  And I fill in "" with ""
  And I press "Update"
  Then I should see error messages
  When I fill in "" with ""
  And I press "Update"
  Then I should see "Your post was updated successfully"
  Examples:
    | required field | valid value       |
    | Title          | Awesome Post Name |
    | Body           | Awesome story     |

I’m sure this isn’t the only way people were using should_change, but hopefully this clarifies how deprecating the methods will encourage better tests.

Do you use should_change and think it’s by far the best way to test certain pieces of code? I’d like to see some people who’ll sorely miss it post some real code (Pastebin or Gist).

Ben Orenstein is a Ruby buddy of ours in Boston who is teaching...

Wed, 23 Jun 2010 15:43:00 -0400

Ben Orenstein is a Ruby buddy of ours in Boston who is teaching our vim training on Friday afternoon/early evening.

Check out this video he made giving a few suggestions for reaching vim mastery. I think you’ll find Ben is a good teacher who thinks deeply about how people learn.

It’s not too late to register, and you have ample time to register for the next session in September. Hope to see you there!

Giant Robots Redesign Wallpapers

Wed, 23 Jun 2010 12:08:00 -0400

To celebrate the redesign of this very blog we’re sharing some GIANT ROBOTS themed desktop wallpaper. They’re available in a few common screen sizes for your convenience.

1440x900
1920x1200
2560x1600

Giant Robots Gets An Overhaul

Tue, 22 Jun 2010 15:46:00 -0400

Last week we started on a blog redesign, it’s live now in case you hadn’t noticed (get in here RSS subscribers!). It was the last of our products that needed an overhaul to get up to date with some of our current styles. First we did the Hoptoad and Widgetfinger (RIP) skins, then we did thoughtbot.com and finally our training app. Giant Robots was the last on our list and I finally had a little downtime to work on it.

We approached it similar to the thoughtbot.com redesign with two designers having a go, and taking the best of both ideas for a final version. Kyle and I both took a few stabs at the design. He was tasked with taking a more minimal approach because I knew I’d be trying an over the top, elaborate design. Our only goal was to match the brand/feel of thoughtbot.com so it wasn’t such a harsh transition when you came to the blog. Other goals included making the content area a little wider, getting rid of a lot of extraneous stuff, and to update the look and feel to a more modern styled blog.

Review and Compare

When we compared two of our multiple versions, there were things from both that helped contribute to the final design. When I looked at them I definitely knew I liked Kyle’s approach more, sticking with the bare minimums and keeping it as clean as possible. The main things that persisted from my design were the colors and the body styles. From Kyle’s came the minimal approach. His simplicity and elegant typography really struck me.

Amidst the design process Kevin said something that stuck with me and became a goal of mine when putting the final design together. We had been looking at a blog post on twitter’s blog and Kevin mentioned that the content was his only focus. It’s what he initially was drawn to, and what he stayed focused on. I wanted this to happen with the new Giant Robots. This became my first goal, to have the content be the primary focus, and nothing else. I know this should always be the case, but sometimes we veer off the content is king path a little to make things look snazzy, I know at least I do. The main method of achieving this was to strip everything else from around the site. Every time I thought I had finished stripping things away, I realized we could take more. There’s even been things removed since the design was pushed live less than 24 hours ago. We think the new design is a success, let us know how you feel.

factory_girl 1.3: integrating effectively with Rails 3

Mon, 21 Jun 2010 11:18:00 -0400

factory_girl has always had little Rails-specific code. It only depends on Ruby, and in order to use it in your application, it asks three things of your models:

They can be instantiated without parameters
All properties have writer methods
They respond to #save! (this is only necessary for the “create” strategy)

However, despite this simple API, there’s one feature in factory_girl that has traditionally caused some issues with Rails: automatic factory definition loading.

The definition loader has simple rules: if it finds any of test/factories.rb, spec/factories.rb, test/factories/**/*.rb, or spec/factories/**/*.rb, it will load those files in no particular order. For most applications, this just makes things a little nicer.

Hacking around Rails dependency management

In early versions of factory_girl, it looked for definitions as soon as you loaded factory_girl.rb. Unfortunately, this broke down when Rails 2.1 introduced gem dependency management. Loading factory_girl during the application initialization phase meant that the factory definitions might reference your models before all the gems and plugins they depended on were fully loaded. Contributer technicalpickles fixed that by detecting Rails and deferring definition loading until Rails was initialized. This solution worked effectively for the entire Rails 2.x series of releases.

Bundler: effective but strict dependency management

The upcoming Rails 3 release uses a new library for managing application dependencies: bundler. Bundler’s behavior is more predictable and understandable than Rails 2’s dependency manager ever was. However, with the introduction of Bundler, two important changes were introduced that impacted many libraries that integrate silently with each other:

Rails is no longer initialized by the time your gem is loaded
Load order is no longer configurable, so you can’t depend on another gem’s constants being defined when you integrate with it

Yehuda Katz, the author of Bundler, discussed this topic in depth on his blog. In his discussion, he suggests a solution that could be added to Rubygems:

s.integrates_with "rails", "~> 3.0.0.beta2", "haml/rails"

However, this functionality doesn’t exist yet, so we’ve decided to create a separate factory_girl_rails gem. This way, we can declare an explicit dependency on Rails, including the version, and automatic definition loading still takes place for Rails apps without any additional application code.

What this means for you

This doesn’t change much for an application that uses factory_girl. It boils down to this:

If you’re using Rails 2, just depend on the factory_girl gem, and Rails 2 will pick up the existing rails/init.rb and load your definitions.
If you’re using Rails 3, just add factory_girl_rails to your Gemfile. This gem depends on factory_girl and will set up definition loading for you.

A lesson on “easy to add” features

I originally added this feature to factory_girl because it was convenient, and seemed easy to add. However, this trivial feature has turned out to be the most difficult to maintain part of factory_girl, and is the single feature that is most likely to outright break an application. I plan on maintaining this feature because we’re used to having it and we’ve worked out most of the kinks at this point, but next time you consider adding an “easy” feature to your own library, also consider whether or not it’s essential to your library’s core mission.

Sailing down the Hudson with RVM

Fri, 18 Jun 2010 16:59:00 -0400

We recently decided our CI server needed an overhaul. I really enjoyed Integrity as a build server, but after trying out Hudson it’s hard to say I want to go back. Hudson has several huge advantages:

Totally self contained. Integrity was a constant mashup. I don’t want to maintain the codebase for my CI server anymore.
Live console output. When your builds take 20-30 minutes, this is really nice.
Metrics/graphing built in! None so far on the other side of homegrown Ruby CI servers.
Kickass plugin installing, don’t need to hack a Gemfile or fix bad code (so far).
Building multiple branches in the same project is no longer a hassle.
Jobs won’t stomp over each other, and I don’t need separate configuration/database for them.

Here’s the details of what I went through to get our new CI server up and running. Be warned, these are probably specific to our projects and needs, but the general process can definitely help anyone who’s looking to get started.

Basic Loadout

We started with a fresh Ubuntu 9.04 LTS install. First up was a basic iptables setup, all the commands you need are on this SliceHost article.

Next up we needed to install Hudson. Follow the instructions here: http://hudson-ci.org/debian/

The nice part about this install (instead of custom compiling it) is that it comes with an init script that is really handy to stop/start the server. There’s more tips on installing here.

If apt-get starts whining, just run sudo apt-get install -f. The hudson package should install the Java dependencies you’ll need for now.

Let’s also install some other basics we’ll need eventually. You may disagree with my choices here, but too bad, I’m the one maintaining CI:

sudo apt-get install zsh vim git-core build-essential postfix ack-grep
curl
chsh /usr/bin/zsh

The postfix install will prompt you for your server’s host name, we’ll want it eventually for emails. If you’re confused, check this article out.

By now you should be able to visit http://YOUR_SERVER_IP:8080 and Hudson should be alive and kicking.

Apache Setup

That’s annoying though, we want to serve requests on port 80. Supposedly doing this with Hudson itself is a bad idea, since it would need to run as root. Apache does a better job, and this tutorial goes over the reasons why.

Here’s what I had to do to get this working:

sudo apt-get install apache2 libapache2-mod-proxy-html
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2dissite 000-default

That will install apache2, get the proxy mod enabled to forward requests along to hudson from the root domain, and disable the default site. Next step is editing /etc/apache2/apache2.conf and adding the following directive to the bottom:

# where your server lives!
ServerName ci.thoughtbot.com

Next up we’ll need to actually make a virtual host for apache to serve (thanks to this StackOverflow question for the right incantations). Create /etc/apache2/sites-available/hudson with the following:


  ProxyPass         /  http://localhost:8080/
  ProxyPassReverse  /  http://localhost:8080/
  ProxyRequests     Off

  # Local reverse proxy authorization override
  # Most unix distribution deny proxy by default 
  # (ie /etc/apache2/mods-enabled/proxy.conf in Ubuntu)
  
    Order deny,allow
    Allow from all

And the final touch to enable hudson and fire up apache:

sudo a2ensite hudson
sudo /etc/init.d/apache2 restart

Hudson Configuration

Port 80 is much better. Now to continue with the configuration! We’re just using a standard security setup with one user. The process is a bit confusing, you have to enable authorization, then go out and sign up to set the password. After that, make sure you set the anonymous user permissions so they can see jobs on the home page.

If you’re an idiot like me and locked yourself out while doing this, disabling security is pretty simple.

As for plugins, we chose so far:

Git SCM (allows us to check out from git)
GitHub (links files in builds on github)
Campfire (You’ll need Maven locally to build this, the default one does not work.)

After installing the plugins and restarting, I disabled a bunch we didn’t need too, like Maven, CVS, etc. I would also check the “Prevent CSRF” button, that’s just a ridiculous option not to have on.

Databases

Let’s get mysql and postgres installed first.

sudo apt-get install mysql-server mysql-client libmysqlclient15-dev
sudo apt-get install postgresql postgresql-client postgresql-contrib

Redis is up next. We’re running the release candidate of 2.0, which is a bit of a pain to set up so far since make install was removed. I came up with an upstart scriptto run it instead.

sudo adduser redis
sudo su - redis
curl -O http://redis.googlecode.com/files/redis-2.0.0-rc1.tar.gz
tar zxvf redis-2.0.0-rc1.tar.gz
cd redis-2.0.0-rc1.tar.gz
make
logout
sudo bash -c "curl http://gist.github.com/raw/444033/9784f426402d5bece09894fcc6f98a33db5f5d15/redis.upstart > /etc/event.d/redis"
sudo start redis

Finally, Ruby!

Now that RVM exists, we can completely isolate projects from each other using gemsets. First we’re going to need even more system packages to deal with ruby and the other gems we’ll be installing eventually (nokogiri, paperclip, etc):

sudo apt-get install bison openssl libreadline5 libreadline-dev zlib1g zlib1g-dev libssl-dev                                                                                                            libsqlite3-0 libsqlite3-dev sqlite3 libreadline5-dev libreadline6-dev                                                                                                              libxml2-dev subversion autoconf libxslt-dev imagemagick

Jump in as the hudson user now and set up RVM:

sudo su - hudson
bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )
echo "[[ -s $HOME/.rvm/scripts/rvm ]] && source $HOME/.rvm/scripts/rvm" > .profile
echo "---\ngem: --no-ri --no-rdoc" > .gemrc

Install the rubies you need now. Our starting lineup:

rvm install 1.8.6
rvm install 1.8.7
rvm install ree
rvm install jruby

Maybe not finally.

We’ll need to get the hudson user set up with git and github too. Make sure to upload your public key ~/.ssh/id_rsa.pub to github so you can start cloning repos.

ssh-keygen -t rsa
git config --global user.email "hudson@thoughtbot.com"
git config --global user.name "hudson"

For each app, create the gemset, databases, and get the gems you need. Bundler would make this easier, but we’re not on it for all projects yet.

sudo su - hudson
rvm gemset create hoptoad
rvm gemset use hoptoad
mysql -u root
> create database hoptoad_development;
> create database hoptoad_test;
gem install mysql nokogiri json

Make a new Hudson job, check from SCM periodically, enable the post build notifications you want. Here’s the build script we’re using for hoptoad so far:

bash -l -c "rvm use 1.8.6-p287 && rvm gemset use hoptoad && rake db:migrate db:test:prepare default"

Debug, rinse, and repeat until it’s green.

Made it!

RVM made this process a lot easier, I used to have to compile multiple versions of Ruby on my own and it was just a pain to manage. Gemsets are a killer feature too, and it’s easy to move them around to another Ruby version with the copy command:

rvm gemset copy 1.8.6@factory_girl 1.8.7@factory_girl

Overall the process was pretty smooth, and like any CI solution this took a while to set up and has its share of annoyances:

Campfire plugin was obnoxious to figure out. Not sure why they ship a broken one, but the custom one from GitHub works great.
Unfortunately, I couldn’t figure out how to make GitHub’s post-receive URLs trigger a build. It worked with a GET request, but POST requests seem to need some special authentication. Hudson has a cron-job style SCM polling, so that works instead.
Lots of clicking around to configure everything, my vim-senses are tingling for a command line interface.

I hope these guidelines help those new to continuous integration with Hudson or otherwise. Of course, there’s plenty of other options in the Ruby-verse, but hopefully you won’t pass up what Hudson has to offer.

Redesigning the toad

Wed, 16 Jun 2010 10:49:00 -0400

Over the last few weeks, we released several redesigned pages for Hoptoad. With the launch of its new Bossfrog plan, we redesigned the homepage and plans and pricing page. Yesterday, we released the redesign of the sign up form. The biggest goal for the redesign was to convert more of Hoptoad’s visitors to users. We also wanted to keep the process from the homepage to signing up to be a cohesive experience.

The idea for the Hoptoad homepage was to give a new coat of paint based on some of the feedback and metrics that have been collected, not do a total redesign. We added more entry points into the plans and pricing page, added clearer messaging about what Hoptoad is, and highlighted that it’s not just a Rails service.

The plans and pricing page and sign up page have adapted the style of the homepage. The plans have been grouped vertically so that they are easily comparable. The backgrounds fade out from largest to smallest to help convey the difference in size.

On the sign up page the plan information has been moved to the side so that it won’t get in the way of users filling out the form. Inputs have been made bigger, given more space and more emphasis. The form has been broken down into only two sections instead of three, making it seem like less to fill out. Lastly, the create account button has been made bigger and more inviting.

Check out the revamped design at hoptoadapp.com and let us know what you think.