Things I Like

Gimme Cookie!

2012-02-13

I’m using signed permanent cookies to track users in my app, and sometimes it’s nice to be able to be able to set them in the browser manually. I’m using “Edit This Cookie” in Chrome to handle this, but it was a bit tricky to figure out how to get the encrypted value of the cookie to manually set it. Well, for future reference, I’ll put it here.

cookie_jar = ActionDispatch::Cookies::CookieJar.new(Rails.configuration.secret_token)
cookie_jar.permanent.signed[:foo] = 'bar'
cookie_jar[:foo] # => "BAhpBg==--8e5eb732858427af92a0c1eeb4f81b276a775fb8"

Using Webmock with Cucumber for Robust Integration Tests

2012-02-09

I decided that it would be a good idea to make my integration tests reflect as much of the real-world setup of my app as possible. This includes hitting 3rd party APIs over the internet. While this can be slow, it is nice to check assertions against actual responses, in case an API change breaks something.

The drawback to this was that I could no longer rely on all my cucumber features passing while I was coding on the train, or in a park, for example.

Mocking the responses would work, but I didn’t want to have 2 sets of scenarios, just for offline and online testing. I also wanted to run the same assertions regardless of where I was.

So I came up with the following pattern, which tries to use a real connection, and falls back to a stub when a connection can’t be made.

First, I use curl to record an actual response for Webmock to send. The -i option is necessary to include the headers. (The API I was using in this example accepts posts of json, and returns json responses.)

curl -iX POST -d @request.json http://www.api.example.com/do_something > do_something_response.json

Next, I set up my API stubs, in support/fake_api.rb. Note the instance variable in the After block – that a key part that we will return to.

module FakeApi
  def stub_api
    canned_response  = File.read(File.join(Rails.root, 'features', 'support', 'fixtures', 'api', 'do_something_response.json'))

    stub_request(:post, "http://www.api.example.com/do_something").to_return( canned_response )
  end
end

World(FakeApi)

After do
  @api_stubbed = false
end

Lastly, I write my cucumber step that deals with the API

When /^I do something at an external API endpoint$/ do
  api = MyApi.new
  begin
    result = api.do_something
    result.should be_something

  rescue SocketError => e
    unless @api_stubbed
      stub_api
      @api_stubbed = true
      retry
    end
    fail "Can't connect to API (real OR fake)"
  end
end

So what we do here is try the real API, and if we cannot connect, we retry the begin-rescue block using the stubbed version. We use the instance variable as a flag to prevent an infinite loop, and we use the After block to ensure that the next scenario starts with a real attempt again.

You might want to adjust this, perhaps omitting the After block cleanup to assume that if the network isn’t there for one test, it won’t be there for the duration of the run.

You could also move the flag setting into the method that does the stubbing.

My Development Setup

2012-01-30

I was working on the CSS for this blog, and reading an older post, when I realized how much my daily development setup has changed. Almost everything has changed from a couple of years ago, and I thought it might be nice to share how I get things done, since IMHO it is a pretty nice way to work.

Hardware

This has changed the least. I’m still tooling away on my 2008 MacBook Pro, although I did drop in a 500GB drive. I will say this about Apple products – they stay useful far longer than their counterparts from Acer and Dell.

Editor

Still using Textmate, although I am now starting to explore alternatives. Rubymine (which I use at work) is a total pain to work with, so right now I’m leaning towards biting the bullet and learning Vim, unless another decent editor pops up.

VCS

Github. Is there really anything that needs to be said about that?

Ruby & Rails

I’m currently using Ruby 1.9.2-p290, with RVM. My most recent project is Rails 3.1.2, but I will probably upgrade to 3.2 within the month.

Development App Server

I’m using Pow, from 37 signals, which although it has some drawbacks with regard to SSL, is still pretty nice to use locally. I got sick of tweaking Apache and Passenger config files all the time.

Testing Tools

Cucumber, RSpec 2.8 & Capybara for the basics. Fabrication as a factory for test data NullDb to ensure that my unit tests are actually unit tests. Shoulda Matchers, Email Spec, and Timecop for some miscellaneous conveniences.

Extras

I use Guard, with guard-spork, guard-rspec, guard-cucumber, guard-bundler, and guard-pow. This keeps my tests running quickly and continuously.

I’m also using TDDium to offload my CI work. There’s a post-receive hook set at Github, and they push to Heroku for me when the build is green. Pain-free continuous deployment, yay!

I’m also using Pivotal Tracker and pickler to coordinate my development priorities. With the Pivotal iPhone app, I can write stories on the train, and then pickler-pull them into my test suite to do BDD.

That’s about it – some nice tools to keep me focused on writing code instead of struggling to configure a bunch of stuff on my machine. After all, who likes shaving yaks?

Set Up A Rails 3.1 App On Heroku Cedar, Ruby 1.9, with Assets Precompiled on the Server

2012-01-07

Someone told me the other day that they had some trouble with this, so here is a quick guide to getting set up on Heroku. This approach is going to compile assets during slug compilation, which I think is the best of the available options.

Step 1

set up a new Rails app

$ rails new placepanda --database=postgresql --skip-test-unit

Step 2

put the app into a Git repo

First, I like to add the following two lines to .gitignore:

config/database.yml
.DS_Store

Heroku makes it own database connection, and I hate those .DS_Store files cluttering up my repository. Now we can get on with the commit.

$ git init
$ git add .
$ git commit -m "my brand new Rails app"

Step 3

Deploy to Heroku as soon as possible. This way we can deal with issues as they arise, not after they accumulate and become hard to track down.

$ heroku create --stack cedar
$ git push heroku master

Now we can look at the app’s status

$ heroku ps

Process  State       Command
-------  ----------  ---------------------------------
web.1    up for 10s  bundle exec rails server -p $PORT

$ heroku logs

2012-01-07T18:35:28+00:00 heroku[api]: Add-on add logging:basic by user@example.com
2012-01-07T18:35:28+00:00 heroku[api]: Release v2 created by user@example.com
2012-01-07T18:36:18+00:00 heroku[slugc]: Slug compilation started
2012-01-07T18:37:08+00:00 heroku[api]: Add-on add shared-database:5mb by user@example.com
2012-01-07T18:37:08+00:00 heroku[api]: Release v3 created by user@example.com
2012-01-07T18:37:08+00:00 heroku[api]: Config add RAILS_ENV, LANG, PATH, RACK_ENV, GEM_PATH by user@example.com
2012-01-07T18:37:08+00:00 heroku[api]: Release v4 created by user@example.com
2012-01-07T18:37:11+00:00 heroku[api]: Deploy cc64c78 by user@example.com
2012-01-07T18:37:11+00:00 heroku[api]: Release v5 created by user@example.com
2012-01-07T18:37:11+00:00 heroku[web.1]: State changed from created to starting
2012-01-07T18:37:15+00:00 heroku[web.1]: Starting process with command `bundle exec rails server -p 40738`
2012-01-07T18:37:18+00:00 heroku[slugc]: Slug compilation finished
2012-01-07T18:37:20+00:00 app[web.1]: [2012-01-07 18:37:20] INFO  WEBrick 1.3.1
2012-01-07T18:37:20+00:00 app[web.1]: [2012-01-07 18:37:20] INFO  ruby 1.9.2 (2011-07-09) [x86_64-linux]
2012-01-07T18:37:20+00:00 app[web.1]: [2012-01-07 18:37:20] INFO  WEBrick::HTTPServer#start: pid=1 port=40738
2012-01-07T18:37:21+00:00 heroku[web.1]: State changed from starting to up

Step 4

I use HAML, so I am installing the haml-rails gem, and so we can check if the assets precompilation on deploy works, I am also building out a minimal app with a HAML view, an image, and a SASS stylesheet. I’ve also installed RSpec, and Thin as the webserver at this point, because that’s just how I roll. You can see the actual commits here

Now I deploy to Heroku again.

$ git push heroku master

And it all seems to be working.

I will update this post a little later, as I add more real-world features to the app, and see if we can’t keep everything working and happy.

Step 5

O.K. – I’m back now, and installing the Compass gem and framework.

$ compass init rails . --syntax sass

edit your Gemfile to include

gem "compass", ">= 0.12.alpha.3"

in the :assets group.

Now, we’ve got to move the sass files to where Rails expects them to be, and also to rename them (to include the ‘.css’) for the assets pipeline.

$ mv app/stylesheets/screen.sass app/assets/stylesheets/screen.css.sass
$ mv app/stylesheets/print.sass app/assets/stylesheets/print.css.sass
$ mv app/stylesheets/ie.sass app/assets/stylesheets/ie.css.sass
$ rm -rf app/stylesheets

Also, we need to update the app/config/application.rb to include:

config.assets.precompile << /^((.*?)\/)?(?!_)[^\/]*$/

(The idea is that this regex prevents the pre-compilation of partials, because if that is attempted, it will fail with errors like “Undefined mixin ‘blueprint-form’”)

I usually put the above line with the regex after the line:

config.assets.enabled = true

Also, in order to use Compass properly, we need to rearrange our stylesheet folder a bit. I make a folder called

app/assets/stylesheets/application

and I put all my custom stylesheets in there.

Then I edit app/assets/stylesheets/application.css, and change from:

*= require_tree .

to:

*= require_tree ./application

This allows the compass stylesheets to render and be included separately, which I prefer. I wind up with one stylesheet for the framework, and one for the rest of my app. My layout head section looks like this:

%head
  %title Placepanda
  = stylesheet_link_tag 'screen.css', :media => 'screen, projection'
  = stylesheet_link_tag 'print.css', :media => 'print'
  /[if IE]
    = stylesheet_link_tag 'ie.css', :media => 'screen, projection'
  = stylesheet_link_tag    "application"
  = javascript_include_tag "application"
  = csrf_meta_tags

Naturally, you might want to do this all in one big file, in which case, I suggest not using the folder structure above, and instead you can just edit the application css to require the files in the right order, as the default alphabetical order is usually non-optimal. It would probably end up like:

*= require_self
* THE COMPASS STYLES
*= require screen
*
* YOUR STYLES THAT NEED TO BE ORDERED
*= require my_stylesheet
*= require my_other_stylesheet
*
* EVERYTHING ELSE IN THE STYLESHEETS FOLDER
*= require_tree .

Now we can deploy to Heroku again

$ git push heroku master

and everything should still be peachy.

Step 6

Installing blueprint.

If you’re following along with the commits on github, at this point, I’ve added my basic app functions, and I just want to style my static pages using blueprint. (The procedure will be similar for other frameworks)

First in my app directory:

$ compass install blueprint

And once again we have to move the files that get created into our assets folder and rename them to ‘some-name.css.sass’

After that, we can just deploy again, and everything is still working.

$ git push heroku master

Cleaning Up After Paperclip Cucumber Tests

2011-11-24

I love using cucumber for acceptance testing, but recently on a personal project I noticed that I was accumulating files in my public/system directory every time a paperclip step was executed. A little googling got me to a solution, which I’ve adapted below for Rails 3.1

In features/support/env.rb:

require 'paperclip'

module Paperclip::Interpolations 
  alias_method :orig_attachment, :attachment 
  def attachment(att, style) 
    "cucumber/" + orig_attachment(att, style) 
  end 
end

After do 
  `rm -rf #{"#{Rails.root}/public/system/cucumber"}`  #remove paperclip files
end

Story Anti-Patterns 1

2011-11-06

This is the first in a series, where I describe some common mistakes made when trying to run an agile team.

Anti-Pattern 1 – Visual design isn’t the whole story.

Example 1 – the team is using Pivotal Tracker as a to-do list

Typical Story

Add styling to product page.

In teams that have stories like this, there are probably a few others that look like:

Clicking on product title directs user to to product page

Product page shows detailed description and product specs

User clicks buy now button on product page

Example 2 – all the business value attached to the wrong thing for the wrong role

Typical Story

As the designer
I want a well-designed product page
In order to encourage purchases

Here, the team is trying to find the value, but they are looking in the wrong place for it. This is an example of thinking about “what do I want the user to do?” instead of “what does the user want to do?”

Forces leading to the use of this anti-pattern:

The team is using Pivotal Tracker (or their equivalent tool) to track to-do items, instead of tracking the stakeholder conversations it was meant for.
The visual designers are not working on the same team as the software developers (stovepiping).
UI design and graphic asset production is being done in a big-design-up-front fashion.
The user is lacking representation in the agile process
The development team feels pressured to put points on the board.

Problems caused by this anti-pattern:

When this pattern becomes common, you wind up with an application that spends most of its time not ready for deployment. If the demo gets rescheduled two weeks earlier, there’s a good chance you won’t be able to show many features in a complete state. Punchlists that need to be completed in order to deploy is the opposite of agile practice.

Another issue this pattern leads to is programmers waiting on designers, or vice versa. Again – not very agile. This fosters an us-vs-them mentality that is inimical to getting things done.

Lastly, when software development is iterating, but UI design and/or production is handled as a page-at-a-time waterfall, the mismatch leads to gross inefficiencies in how the look & feel gets implemented – bloated CSS, endless tweaking of styles, etc.

Solutions:

Use story templates that enforce business value consideration
Use iterative development in ui design as well as programming
Designers and developers work together on the same stories until they are done.

Using better story templates

Story templates need to show three important things:

Business value
The role that benefits from the value
The feature necessary to provide the value

The above story could become:

In order to more easily make a purchase decision
the customer
wants to see a well-designed product details page

Given an existing product named “Foo"
When the customer visits the product page for "Foo"
Then the customer should see the product details for "Foo"
And the page should be styled according to the current design specifications for the product page

Notice that there are no implementation details exposed in the story or scenario. This prevents brittle tests. The feature is written from a user’s point of view, and doesn’t concern itself with what the developers consider details, or what the designers mean by well-designed.

If what is meant by “product details” changes, this is a change in requirements that will correctly force a change in the implementation of the step. However, the feature itself does not need to change, since it is value-driven and focused on the user’s needs. Ideally, what is meant by product details should be centralized, and changed only in one place to update all the features that rely on it.

The last step could be implemented using matchers for such ui requirements as: All headlines should be blue, and all body copy should be 16px high. This then becomes a reusable step that can help catch look & feel flaws on other pages, as well.

It can be argued that tests for this sort of thing are excessive, since look and feel changes so often, and maintaining these tests creates a lot of overhead. I think that perhaps the overhead would encourage more consideration of changes, since the actual cost of doing them correctly becomes exposed. The alternative is to not care whether the look and feel is correct – if you do care, there is work to be done to ensure correctness, whether it is automated or (like most teams) manually reviewed by designers working over the shoulders of developers, nearly doubling the overhead costs.

Iterative UI design

There’s not enough space or time to go into a full discussion of agile UI development here. I wish there were more resources online, but unfortunately there is not a lot written on the topic. Briefly, though, UI development should follow many of the same principles as software development. The UI design can and should be developed in an organic, iterative fashion. Stories should be deployed as they are completed – in this system you’ll never hear “the story is done, but we can’t deploy it until the UI is finished.”

No More Us-And-Them

The UI design team should be an integral part of the development team, and should pair with software engineers to deliver stories. The pairs can work on establishing what UI elements are needed for a given story, and can add chores to create the actual assets, while using placeholders in development. Programmer-Designer pairs can go from paper wireframes to HTML prototype to working application code, together. The agile principle of YAGNI will be critical to making this system work. Design development can also benefit from DRY thinking.

Getting Settled In San Francisco

2011-11-06

I’ve been in San Francisco for about a month now, and I am finally starting to feel like I am getting settled. I’ve mostly adjusted to the changes in my job, and I’ve got almost all the furniture I need, and I am back to training jiu jitsu, although not as frequently as I’d like.

I’m going to write a post giving my first impressions of the city, as compared to NYC, because that seems to be a required post for developers and/or startup employees. But first, I am working on a story about stories.

New Blog

2011-08-03

I finally decided to stop using Wordpress for this blog, and am now using Toto.

It was very easy to get it up and running on Heroku, using instructions I found at Ruby Inside.

I also found this article on ways to customize it, although I’m not taking advantage of this fully, at the moment.

I’ve never been much of a blogger, but I’m hoping the simplicity of this setup makes it easier for me to write quick posts like this one about things I like.

Things I Like

2011-07-21

Programming, Brazilian Jiu Jitsu, Burgers, Beer, etc.

Passenger Headaches

2009-04-02

I’ve been using Phusion Passenger and Apache2 for a little while as my development setup, since it is hassle free for setting up apps and switching between them. I don’t miss typing ./script/server 100 times a day at all. However, Over the last couple of weeks I’ve run into a few issues that sidetracked me for more time than they were worth.

First, I realized that one of my apps that was using Thoughtbot’s Paperclip for attachments was no longer making thumbnails, and it wasn’t giving me an errors either. In case you are having this problem too, here’s the cause and solution (as found here.) Apparently mod_rails apps run as the same user as Apache so whatever is in your personal $PATH doesn’t carry over. Therefore it is not finding the ImageMagick binaries. The solution is to create an initializers/paperclip_config.rb file something like: if RAILS_ENV == “development” Paperclip.options[:image_magick_path] = ‘/opt/local/bin/’ else Paperclip.options[:image_magick_path] = ‘/usr/bin/’ end Now it can find the programs it needs for the thumbnails, and you’re back in business.

The next issue I ran into was with Authlogic, which is my current favorite authentication solution. Apparently, when using Passenger 2.0.6 with Rails 2.3.2 and using the cookie session store, you are prevented from logging out. I’m not sure why, but the solution is either to use the ActiveRecord session, or to upgrade to 2.2.1+ which is what worked for me.

Now, today I hit another little glitch when using the ruby-ole and spreadsheet gems. The gem uses the ruby logger writing to STDERR by default, and it seems that while Mongrel can route the log messages to the right place, Passenger just throws a “stream closed” error. The solution was just to add the following line to environment.rb Ole::Log = RAILS_DEFAULT_LOGGER Simple enough, but it took me a long time (and a coworker’s input) to realize what was going on.