Recent Posts

82,520 minutes on Phusion Passenger

April 10, 2009

It’s been over 83,520 minutes since I made the switch from using mongrel as my development environment web server to Phusion Passenger. I’ve been extremely impressed with it. Our team has all switched over and haven’t really hit any obstacles in the transition.

Since some people asked me to let them know how this trial period worked out, I felt it was my duty to encourage you all to try it. You can check out my previous post, Switch to Passenger (mod_rails) in development on OSX in less than 7 minutes or your money back! to get rolling.

Additionally, if you’re looking for a streamlined Ruby on Rails deployment environment that includes Passenger, check out Rails Boxcar.

Building a prototype? Bring some rope.

April 09, 2009

While scanning through Allison’s copy of Designing for the Digital Age: How to Create Human-Centered Products and Services{width=”1” height=”1” border=”0” style=”border:none !important; margin:0px !important;”}, I came across this nugget.

The problem with software prototypes

It seems to be widely understood that industrial design and mechanical engineering prototypes—from paperclips and tape to polished appearance models—are disposable learning tools. Prototyping is clearly distinct from manufacturing, so it would be ludicrous to think that even a late-stage prototype could be reused as part of the final product. In software, however, the tools used for anything other than paper prototyping are generally the same tools used for “manufacturing” (i.e., writing production code). For this reason, many stakeholders can’t see why a detailed prototype that appears functional is still many months away from completion.

It immediately reminded me of a few posts that I had written about three years ago on the topic of developing prototypes and NOT keeping them.

The author continues with…

It’s important to educate stakeholders that prototype code is kind of like the illusion of automatic doors on Star Trek—it looks like it’s working, but it’s really a guy standing behind the wall pulling a rope.

I completely agree that education is the most important aspect to managing client expectations. With regard to the amount of work that you put into a prototype, we need to be careful on how much time and energy is put into them. If we can get away with a guy (or some quick Javascript hacks) to demonstrate possible functionality, make sure we aren’t using much more than rope. Rope is cheap. Prototypes should be too.

20 articles on Cucumber and a free beverage recipe!

April 09, 2009

Cucumber has been getting quite a bit of attention in the community and with the new RSpec Book on nearing publication, I predict that by this time next year, it’ll become a household word like boanthropy.

What is Cucumber?

The Cucumber project describes itself as a suite that, “lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid - all rolled into one format.”

One of the great things about Cucumber is that it can be used to test applications in any language. I haven’t been able to track down a lot of articles of how people are using it with other languages, so please comment if you’re aware of some.

In any event, I’ve been collecting and reading resources from a variety of Cucumber aficionados and thought I’d share some links with you. To round it out, I asked on twitter for some others so that I could hit twenty. :-)

  1. What’s in a Story?, Dan North
  2. Telling a good story - Rspec stories from the trenches, Joseph Wilk
  3. Beginning with Cucumber, Ryan Bates (Railscasts)
  4. Using RSpec, Cucumber and User stories to build our internal systems, Rahoul Baruah
  5. Cucumber: The Latest in Ruby Testing, Ruby Inside
  6. Using Cucumber for Acceptance Testing, Noel Rappin
  7. Behavior Driven Development with Cucumber, Brandon Keepers (presentation/slides)
  8. Testing capistrano recipes with cucumber, Jeff Dean
  9. Using Cucumber to Integrate Distributed Systems and Test Messaging, Ben Mabey
  10. Tutorial: How to install/setup Cucumber, Alan Mitchell
  11. Testing outbound emails with Cucumber, Dr. Nic Willians
  12. Proper Cucumber Sintatra Driving, Chris Strom
  13. On getting started using Cucumber for .NET
  14. DRY up your Cucumber Steps, Matt Wynne
  15. Cucumber, Celerity, & FireWatir, Aidy Lewis (presentation/video)
  16. Cucumber step definition tip: Stubbing time, Bryan Helmkamp
  17. Story Driven Development Recipes with Cucumber, Sebastien Auvray
  18. Testing Facebook with Cucumber, Brandon Keepers
  19. Testing with the help of machinist, forgery, cucumber, webrat and rspec, Etienne van Tonder
  20. Integration testing SSL with Cucumber
  21. Continuous Integration Blueprints: How to Build an Army of Killer Robots With Hudson and Cucumber

So.. there you have it. Please post comments with links to any useful articles not mentioned and I’ll try to keep the list updated.

Also, be sure to check out the list of tutorials and related blog posts on the cucumber wiki (github).

FREE RECIPE: Cucumber Water

{style=”float:right;”}
And now…for the reason you are all here! If you like cucumbers (eating them)… I would highly recommend heading to your local farmers market and purchasing some cucumbers. Aside from being healthy to eat… they can help make a tasty beverage.

Then do the following…

  • Chop several slices of a cucumber
  • Fill a pitcher with cold water and ice
  • Toss in slices of cucumber
  • Stir and leave in fridge for a while
  • Take out of fridge, pour into cup…
  • Drink… hack… and enjoy

Be sure to check out, How to Make Cucumber Water on wikihow for details.

Happy Hacking!

HTTParty goes foreign

March 16, 2009

Just a quick post to get share something I was tinkering with this evening.

I came across this post by Gerald Bauer, which shows you how to use the Google Translation API with Ruby via Net::HTTP. I thought I’d play with the service with HTTParty.


class GoogleApi
include HTTParty
base_uri ‘ajax.googleapis.com’

def self.translate(string=””, to=””, from=”en”)
get(“/ajax/services/language/translate”, :query => {:langpair => “#{from}|#{to}”, :q => string, :v => 1.0})
end
end\

A few examples from playing with it.


>> GoogleApi.translate(‘bonjour’, ‘en’, ‘fr’)
=> “{"responseData": {"translatedText":"hello"}, "responseDetails": null, "responseStatus": 200}”

>> GoogleApi.translate(‘Red wine’, ‘fr’)
=> “{"responseData": {"translatedText":"Vin rouge","detectedSourceLanguage":"en"}, "responseDetails": null, "responseStatus": 200}”

>> GoogleApi.translate(‘Where is the bathroom?’, ‘es’)
=> “{"responseData": {"translatedText":"\302\277D\303\263nde est\303\241 el ba\303\261o?","detectedSourceLanguage":"en"}, "responseDetails": null, "responseStatus": 200}”

>> GoogleApi.translate(‘Good morning’, ‘it’)
=> “{"responseData": {"translatedText":"Buon giorno","detectedSourceLanguage":"en"}, "responseDetails": null, "responseStatus": 200}”

What a party!


>> GoogleApi.translate(‘party’, ‘it’){lang=”ruby”}
=> “{\”responseData\“: {\”translatedText\“:\”festa\“,\”detectedSourceLanguage\“:\”en\“}, \”responseDetails\“: null, \”responseStatus\“: 200}”{lang=”ruby”}
>> GoogleApi.translate(‘party’, ‘es’){lang=”ruby”}
=> “{\”responseData\“: {\”translatedText\“:\”fiesta\“,\”detectedSourceLanguage\“:\”en\“}, \”responseDetails\“: null, \”responseStatus\“: 200}”{lang=”ruby”}\

Look how easy that was. :-)

For a previous post on using this gem, read The HTTParty has just begun.

Git commit-msg for Lighthouse tickets

February 16, 2009

A quick follow-up to a post from a few months ago on how our team has a naming convention for git branches when we’re working on Lighthouse tickets (read previous post).

I’ve just put together a quick git hook for commit-msg, which will automatically amend the commit message with the current ticket number when you’re following the branch naming conventions described here.

Just toss this gist into .git/hooks/commit-msg.

```
  #!/bin/sh

  #
  # Will append the current Lighthouse ticket number to the commit message automatically
  # when you use the LH_* branch naming convention.
  #
  # Drop into .git/hooks/commit-msg
  # chmod +x .git/hooks/commit-msg

  exec < /dev/tty

  commit_message=$1
  ref=$(git symbolic-ref HEAD 2> /dev/null) || return
  branch=${ref#refs/heads/}

  if [[ $branch =~ LH_(.*) ]]
  then
  lighthouse_ticket=${BASH_REMATCH[1]}

    echo "What is the state of ticket #${lighthouse_ticket}? "
    echo "(o)pen "
    echo "(h)old"
    echo "(r)esolved"
    echo "Enter the current state for #${lighthouse_ticket}: (o)"

    state="open"

    read state_selection

    case $state_selection in
      "o" )
        state="open"
        ;;
      "h" )
        state="hold"
        ;;
      "r" )
        state="resolved"
        ;;
    esac
  echo >&2 "[#${lighthouse_ticket} state:${state}]" >> "$1"
    exit 0
  fi
```

Then a quick example of how this works…

```
  ➜  bin git:(LH_9912 ♻ ) git ci -m "another test"
  What is the state of this ticket? 
  (o)pen 
  (h)old
  (r)esolved
  Enter the current state: (o)
  h
  Created commit 1ed2713: another test
   1 files changed, 3 insertions(+), 1 deletions(-)
```

Now to see this in action… (screenshot)

::: thumbnail git message
hook :::

Then we’ll check out the git log really quick.

```
➜  bin git:(LH_9912) git log
commit 1ed271323c4a054fe56e76bddc9ac81d241a1032
Author: Robby Russell <robby@planetargon.com>
Date:   Mon Feb 16 12:06:33 2009 -0800

    another test
    [#9912 state:hold]
```

Thanks to Andy for helping me figure out how to read user input during a git hook.

On shells

February 13, 2009

Zsh versus Bash. Fight!

::: thumbnail OH in developer
channel :::

…because we need another religious war in the developer community. ;-)

(skitch via Gary)

Switch to Passenger (mod_rails) in development on OSX in less than 7 minutes or your money back!

February 11, 2009

We recently switched our default builds of Rails Boxcar to leverage the benefits of using Passenger (mod_rails) for deployment of your Ruby on Rails applications and it’s been working out great for our customers. Several of our customers and colleagues mentioned that they also began using Passenger in development, which was intriguing.

But… Mongrel has been working great for us for the past few years. Why switch?

It’s true, I’ve been happily using mongrel since it came out as a replacement to webrick back in early 2006, which makes it about 28 in dog years.

Nigel and
I{width=”500” height=”375”}
[Nigel and I.. 2 1/2 years ago back when Mongrel was just a puppy]{.small}

But… over the next few weeks, I’m going to evaluate Passenger in my development workflow. There’s no better way to try something then to jump head first. So… here goes.

::: thumbnail locke
[this guy was a passenger…and I recently started to watch the show]{.small} :::

Our team will be evaluating Passenger in our development work flow with a forthcoming blog post but if you want to get your feet wet right away, here are some instructions for setting up Passenger on OSX with PrefPane, which were inspired by Manfred’s posts.

Installing Passenger via RubyGems

To install Passenger on your OSX machine, just run the following with root credentials.

sudo gem install passenger

This will install the passenger gem on your machine. Now we need to go ahead and run a script that is provided with this gem (also with root credentials).

sudo passenger-install-apache2-module

You’ll want to follow the instructions that appear. When you see something similar to the following output from the command, you’ll want to copy/paste that into an apache configuration file. I just created a file at /etc/apache2/other/passenger.conf.

Edit this file with your editor of choice

mate /etc/apache2/other/passenger.conf

Mine looks like:

```
  #/etc/apache2/other/passenger.conf

  # Passenger modules and configuration
  LoadModule passenger_module /opt/local/lib/ruby/gems/1.8/gems/passenger-2.0.6/ext/apache2/mod_passenger.so
  PassengerRoot /opt/local/lib/ruby/gems/1.8/gems/passenger-2.0.6
  PassengerRuby /opt/local/bin/ruby

  # Set the default environment to development
  RailsEnv development

  # Which directory do you want Apache to be able to look into for projects?
  <Directory "/Users/robbyrussell/Projects/development">
      Order allow,deny
      Allow from all
  </Directory>
```

Once you finish running through sudo passenger-install-apache2-module, you’ll need to restart Apache on your workstation. This can be done by simply turning off/on Web Sharing in your Sharing Preference Pane.

::: thumbnail Sharing :::

Alright, we got through the hard part. Now, in order for you to begin using Passenger, we need to setup Apache to point to your individual Ruby on Rails application(s). You can hack on Apache configuration files more, but there is an easier way thanks to the Passenger Preference Pane.

This will manage your VHost files for you!

Setting up Preference Pane

If you followed my post on installing Ruby on Rails via MacPorts, you’re going to need to install Ruby Cocoa, which can be done with the following. If you’re using the Ruby provided from Apple, you can skip this step.

sudo port install rb-cocoa

Once that is done, go ahead and move on and download Passenger Preference Pane. Once downloaded, you can install the preference pane, by double-clicking on the following file.

::: thumbnail PassengerPane-1.2 :::

The next part is really simple as well. Just begin to add your various Ruby on Rails projects into the Preference Pane… and when you’re done, you should be able to run your applications over port 80 without any problems.

As you can see, I’ve already setup a handful of projects and we don’t have to start/stop mongrels for each one or worry about port numbers when running multiple projects. (time savings!)

::: thumbnail Passenger :::

Voila. Simple enough. You might need to stop/start Apache, couldn’t remember if I needed to or not.

For each host that you add into this panel, it’ll automatically be added so that you can immediately browse to http://yourhost.local and it should just work. :-)

Things to still figure out…

Debugging. If you’re used to doing --debugger, it appears that you can do something similar with the socket-debugger plugin. Not tried it myself, but worth looking into.

Browser testing via VMWare/Parallels/VirtualBox. Does anybody have any tips on how to best appraoch this? Our designers are curious…

As I mentioned, this is day one of trying it out and managed to motivate our entire design and development team to try it with me so that we can all learn about issues together and find solutions quicker. If you’ve been using this approach for a while, I’d be interested in hearing your story and if there are any issues that we should be aware of.

Rolling out new updates for Rails Boxcar

January 28, 2009

Alex, Director of Deployment Services, has been hard at work helping us get our new suite of hosting plans out for Rails Boxcar, a deployment environment that we’ve designed to help you get your Ruby on Rails applications running as painless and quickly as possible. With this new announcement, we’ve rebuilt the Boxcar image based on the feedback of our existing customers.

Additionally, we’ve been looking over some of early results from the Ruby on Rails Hosting in 2009 Survey that we’ve been running the past few weeks, which has further boosted our confidence that we’re on the right track with this big change.

What are some of the changes?

This means that with a Rails Boxcar, you can now get a pre-configured deployment environment using some of the most efficient platforms for hosting your Ruby on Rails applications. (REE has shown to increase performance by 33% in some cases)

We’re really excited about this new setup and would like to invite you all to check out our new plans and send us any questions that you might have.

Rails Hosting Survey - 5 days left...

January 27, 2009

Wow. Thanks to all of you who have helped get the word out about the Ruby on Rails Hosting 2009 Survey. We just passed 900 people and we have about five more days left to hit the 1500 milestone that I set for myself.

If you can spare five minutes to help us reach this goal, we’d really appreciate it.

Here is a quick sample of the questions that we’re asking the community.

  • Where is your source code hosted?
  • Which database do you typically use in production?
  • which performance monitoring tool do you use?
  • How much of your monthly budget is allocated for deployment and hosting expenses?
  • So, can Rails scale? ;)

Don’t hesitate… we only have a few days left!

{style=”padding-top: 20px; padding-bottom: 40px;”}

For more information, read the original post, Take the Ruby on Rails Hosting in 2009 Survey.