Recent Posts

Launching Ruby on Rails projects, a checklist

December 14, 2008

::: warning Since publishing this article, I have given a talk on this topic at Rails Underground 2009. I invite you to checkout the slides. :::

As mentioned in a recent post, I’m hoping to share some lessons that were learned throughout the process of launching a client project. Over the past few years, we’ve been part of several dozen client projects and the big launch date is always an anxiety-filled, yet exciting point for the client and our team. I wanted to provide a quick list of a few the things that our team considers vital before launching that next big project. While most of these things might seem obvious, it’s still good to cover the basics and I hope a few people find it helpful.

Hosting

Our company has been offering Ruby on Rails hosting for nearly four years and a few years longer with the PHP5 and PostgreSQL world. Given that, we’ve seen customers come to us at the last minute before they launch and wanting to get things setup and deployed right away. Quite often, this is their first experience deploying a Ruby on Rails application and there has historically been a semi-steep learning curve to do this. It’s really encouraged that you get this stuff figured out ahead of time. If you’re lucky, some hosting companies might offer cheaper plans so that you can begin to get things setup a few months or ahead of time and upgrade your plan prior to the big launch. This is how our Rails Boxcar hosting plans work.

We’ve seen a lot of customers avoid engaging with a hosting company more than a week or two before their launch because they want to reduce their monthly expenses, but the reality is that if you end up saving yourself a few hours of work by not scrambling at the last minute to get things setup, the hosting costs will pay for themselves. Several of our customers have learned this the hard way and as a result, this has resulted in extra stress that might have been avoidable if things had been ready earlier on.

The basic process that our team is to get a real deployment environment setup as early in the design and development process as possible. Often times, this will be 4-6 months before launch on larger projects. In our process, we aim to have a staging environment that mirrors our production environment. We tend to use a Boxcar Lite plan for our own client projects and get the deployment process working and automated. When it’s time to launch, we can easily upgrade the Boxcars with more resources to one or more Plus plans.

If you’re in the market for a hosting company, do keep us in mind, but if we can offer any advice, be sure to find out how you can scale upwards to meet your initial 3-6 month growth targets. Don’t worry about planning too far ahead in the future, until you see how traffic picks up and how the application and databases perform, you’ll be spending a lot of time guessing without data. If you’re new to this and aren’t sure, I’d encourage you to speak with a Ruby on Rails deployment specialist.

A few things to consider here:

setup early. Make sure everything works and set it up to work with
multiple deployment environments. (staging, production, etc.)
-   Use [Boxcar
    Conductor](http://www.robbyonrails.com/articles/2008/04/15/boxcar-conductor-rails-deployment-made-easy)
    with your Rails Boxcar. ([Boxcar Conductor on
    github](http://github.com/planetargon/boxcar-conductor/tree/master))
```text
-   Use the **HTTP Basic Authentication**, which is available in Ruby on
```yaml
Rails to keep peeping toms (competitors, search crawlers, spammers,
etc.. ) out of your project while you're deploying to your staging
environment. We tend to give out a `.htaccess` user/pass with this
method to the stakeholders so they can access the site whenver they
need to.
-   Rails documentation on HTTP Basic Authentication: [view
    docs](http://api.rubyonrails.org/classes/ActionController/HttpAuthentication/Basic/ControllerMethods.html)
-   Watch a Railscast for using HTTP Basic Authentication: [watch
    screencast](http://railscasts.com/episodes/82)
```text
-   Get your automated tasks (cron jobs) setup way before launch. Verify
```yaml
that things are working here at the right times
-   Extra-credit: Check server time settings to make sure you're not
    running big tasks at time periods when heavy traffic is expected
```text
-   Make sure your hosting provider has monitoring setup. It's good to
```yaml
gauge uptime % from launch
-   Extra-credit: Setup your own monitoring with
    [Pingdom](http://pingdom.com/) or similar service to make sure
    you know when things are down. (You can audit your hosting
    provider this way!)
```ruby
There are a handful of really great hosting companies out there for Ruby
on Rails. Be sure to do your homework early! This isn't something you
want to do at the last minute.

Reminder: **Keep your project releasable at all times.**

## Search Engines and Analytics

Before the big launch, be sure that you have outlined a consistent
pattern for managing the HTML page titles on each page. Getting targeted
traffic to your new web application is (usually) vital. Our team has
adopted a basic pattern that we use throughout the application. This way
we don't have to go through at the last minute and figure out where
titles are and/or aren't being set.

In a previous post, I [shared a basic
plugin](http://www.robbyonrails.com/articles/2008/03/26/managing-seo-friendly-html-titles-with-rails)
that our team uses on projects to manage page titles on a view-by-view
basis.

Additionally, be sure to take advantage of using descriptive permalink
URLs.

Another tip is to setup your application with analytics ([google
analytics](http://google.com/analytics) is free!) If there is one thing
that I wish we had setup from day one on every project in the past, was
a set of conversion goals. So, be sure to get into your analytics
account and prepare your application so that you can track these goals
from the moment your application is launched. Collecting as much data
about your visitor's usage habits is going to help you in the coming
weeks and months as you tune things based off of feedback and this data.
Also, after you begin to introduce changes, you can analyze these
metrics to verify that you're improving things and not the opposite.

So, be sure that you are doing the following:

-   Have implemented descriptive page titles and urls
-   Are ready to track your site visitor's usage habits from the
```yaml
starting gate
-   Conversion goals for obvious things like:
    sign-ups/registrations, viewing your product tour, contact
    requests, etc.
```ruby
## When Things Go Wrong / Tracking Exceptions

What happens when things go wrong? We've been amazed by how many
projects we've seen have been in production for months/years and lacking
something that seemed so obvious. Exception notifications! All too
often, we've seen teams totally unaware that things were failing for
their customers and not being reported to anybody. The easiest way to
track exceptions in the past was to use the
[exception_notification](http://github.com/rails/exception_notification/tree/master)
plugin that the Rails team manages. You can have this plugin send your
development team emails with a backtrace and all the goodies that'd
normally show up in a 500 error. At a minimum, you should be using
something like this.

-   Tip: Make sure your hosting environment can send out emails!
```text
(otherwise, you'll never know about these problems...eek!)
```ruby
However, in the last year, the Rails community has seen two options,
[Exceptional](http://getexceptional.com/) and
[Hoptoad](http://www.hoptoadapp.com/) introduced for managing
exceptions. Our team has only used Exceptional so far, because our good
friends at [Contrast](http://www.contrast.ie/) invited us to be early
beta-testers for their new service. We love the Exceptional's
integration with Lighthouse, which is the bug/issue tracking application
that we're currently using. With Exceptional, our team is able to search
through and track exceptions in our application and have a good meter on
the overall health of our application. This solution works so much than
the email-based approach because we can track which exceptions have been
opened and sent to Lighthouse and if they've been closed by someone
already.

I've heard great things about Hoptoad as well, but have yet to test it
out. Would be interested to read a comparison between the two and am
curious if there are other services for this currently.

## Non-default 404 and 500 pages

Honestly, this is one of those things that we tend to forget about until
the last minute. When you're launching a new project, you're bound to
have a bug and/or a few broken links not accounted for. What you want to
avoid is having your customers end up on an unhelpful page that looks
like this:

::: thumbnail
[![The page you were looking for doesn\'t exist
(404)](http://img.skitch.com/20081215-q11ckmua6qe5gf4nsd6ghptw83.preview.jpg)](http://skitch.com/robbyrussell/6txe/the-page-you-were-looking-for-doesn-t-exist-404)
:::

It doesn't take too long to put something together that is a bit more
helpful for your visitors.

::: thumbnail
[![AlphaClone --- Page not
found](http://img.skitch.com/20081215-12prkpg4b98rptwiwy637ss1.preview.jpg)](http://skitch.com/robbyrussell/6txm/alphaclone-page-not-found)
:::

So, do yourself a favor and add a ticket for your designers to design a
custom 404 and 500 pages to replace the defaults that are provided by
Ruby on Rails in `public/`.

## Hold your client's hands

If you're working with startups, do remember that this is quite possibly
their first launch. It's important to remember that they're going to be
going through their own spectrum of feelings and it's our job to help
get them through the process with an eased mind. Show them that you have
things covered, that things are ready to go, alert them when things pop
up... in a nutshell. Keep them informed about the challenges and do what
you can help to manage their stress. If they've just contracted you for
an extended period of time to help get their **big idea** designed and
developed, remember that this launch is just the beginning of the race
for them. They have a big journey ahead of them and you just helped them
get their new car engine built. Make sure they know that things are
likely to breakdown along the way, need to be refueled (refactor!
refactor!), and need service repairs. The worst thing you can do is set
the expectation that nothing will go wrong once their application is
released into the wild. They need to budget for this early on so that
they can pace themselves after launch. (this is a big topic definitely
worth of it's own post)

Just remember that this should be a big celebration for your team and
client. Remember to celebrate! (and then follow it with a retrospective)

## In Conclusion

As mentioned, these are just a handful of things that we have learned to
avoid overlooking (through trial and error). I'm hoping to share more
thoughts on launching in the near future and would love to hear from all
of you on things that you've come across. What works? What doesn't work?

What is on your checklist for launching successful projects?

### Related Articles

-   [The Art of Delivery, part
```text
2](http://www.robbyonrails.com/articles/2008/05/22/the-art-of-delivery-part-2)
```text
-   [Agile development begins
```text
within...](http://www.robbyonrails.com/articles/2006/04/21/agile-development-begins-within)
```ruby
-   [Audit Your Rails Development
```text
Team](http://www.robbyonrails.com/articles/2007/06/17/audit-your-rails-development-team)
```text
-   [Embracing Chaos, part
```text
1](http://www.robbyonrails.com/articles/2007/12/17/embracing-chaos-part-1)

AlphaClone on PostgreSQL and Ruby on Rails

December 12, 2008

::: {.thumbnail style=”float:right;”} tour-ss-full-berkshire.jpg (JPEG Image, 370x713
pixels) :::

Earlier this week, our team launched a client’s project into the public. We began working on it early this year and it was quite an endeavor for our team. The company that we helped launch is AlphaClone, a premier stock research and portfolio simulation service for individuals and professional investors alike. Clone, backtest and track over 230 top fund manager portfolios. More than 15,000 pre-generated clones and nearly limitless possibilities based on your own custom groups of funds. Take a tour of AlphaClone…

It’s hard to deny that I’m insanely proud of the team at Planet Argon for bringing our client’s business idea to reality. We’ve been enjoying keeping up on how the press is responding so far since they’ve launched. I expect that they’ll do well with their business endeavor and look forward to helping them evolve and expand.

I’ve been asked to share some stories and lessons learned throughout the project. Given that we tackled a lot on the Interaction Design side of things in addition to relying a lot more on some of the advanced features of PostgreSQL (we’re dealing with a TON of data here), we have things to share. So, stay tuned as I’ll be highlighting some of those lessons over the coming week(s).

Additionally, if you’re looking for a team to help you execute your next big idea, give us a call!

Lighthouse tickets and Git branching

December 11, 2008

We’re currently using Lighthouse as our ticketing system with clients for maintenance/bug requests. We’re also using Github for all of our major client projects. I’m sure that many of you take advantage of the Lighthouse service that Github allows you to use so that your commits can trigger actions on your tickets in Lighthouse.

If you’re not already, you might consider running (cheat ?):

  • cheat lighthouse
<!-- -->

lighthouse:

  • Commit comment [#213] Adds message as comment to ticket #213 ```

The HTTParty has just begun

November 26, 2008

After releasing the new RubyURL API, I decided that it was time to look around at libraries to interact with it. I came across a new Ruby gem from John Nunemaker named, HTTParty, which aims to make it easy to talk to XML and JSON-based web services. Be sure to read John’s announcement of HTTParty.

So, I decided it might be fun to introduce more people to the gem by showing you all how to use it to talk to the new RubyURL API.

Install HTTParty

Before we get started, you’ll need to install the HTTParty gem with the following command:

   ~ : sudo gem install httparty
  Password:
  When you HTTParty, you must party hard!
  Successfully installed httparty-0.1.6
  1 gem installed
  Installing ri documentation for httparty-0.1.6...
  Installing RDoc documentation for httparty-0.1.6...
```shell
Great! Now that **we're ready to party hard**, let's build something.

## Talking to the RubyURL API

The [RubyURL API](http://rubyurl.com/api) currently supports both XML
and JSON, which are each supported by HTTParty. The great thing about
HTTParty is that all you need to do is include it in a class and you're
able to quickly talk to remote services.

In this following example, we're going to create a new class called
`Rubyurl`.

````ruby
class Rubyurl
end
````ruby
What we'll want to do now is include the HTTParty library. (**note:**
you'll need to require both rubygems and httparty gems and I'll skip
those lines in following code samples)

````ruby
class Rubyurl
  include HTTParty
end
```text
The HTTParty provides [a few class
methods](http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb),
which we can use to configure our library. We'll go ahead and specify
the `base_uri`, which we'll set to `rubyurl.com`.

````ruby
class Rubyurl
  include HTTParty
  base_uri 'rubyurl.com'
end
```bash
Now that our class is setup to talk to the
[Rubyurl.com](http://rubyurl.com) site, we'll want to add a new method
which we can use to communicate with the RubyURL API. We'll call this
`shorten` as we're using RubyURL to shorten long URLs... right?

````ruby
class Rubyurl
  include HTTParty
  base_uri 'localhost:3000'

  def self.shorten(website_url)
  end
end
```yaml
Our new `shorten` method will expect us to provide it with a website
url, which we'll want RubyURL to return a shortened URL for. The PATH
for the API that we'll want to talk to is: `/api/links`, which we're
expected to pass XML or JSON to.

Here are two examples of using the RubyURL API with HTTParty.

### RubyURL via JSON w/HTTParty

We're going to use the `post` method that is provided with HTTParty to
send a request to `/api/links.json`. As you can see, we're providing the
original website url to the web service.

````ruby
class Rubyurl
  include HTTParty
  base_uri 'rubyurl.com'

  def self.shorten(website_url)

```javascript
post('/api/links.json', :query => { :link => { :website_url => website_url } })
```text
end
end
```yaml
When ran, it'll produce the following:

````ruby
>> Rubyurl.shorten('http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb').inspect
=> {"link"=>{"permalink"=>"http://rubyurl.com/uJVu", "website_url"=>"http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb"}}
```shell
Pretty simple, eh?

### RubyURL via XML w/HTTParty

The great thing about HTTParty is that you can use XML without changing
much.

````ruby
class Rubyurl
  include HTTParty
  base_uri 'rubyurl.com'

  def self.shorten(website_url)

```javascript
post('/api/links.xml', :query => { :link => { :website_url => website_url } })
```text
end
end
```text
Produces the following

```ruby
http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb
http://rubyurl.com/uJVu

Closing thoughts

So… there you have it. HTTParty makes it extremely easy to interact with various web services that work over HTTP. I’d encourage you all to take a few minutes to experiment with it and see what crazy ideas that come to mind during the process. :-)

Lesson Learned: Git Ref Naming

September 18, 2008

Our team has been working our way into the Git world. One of our big client projects is now 100% git while the other is still on Subversion for another month or so. (I’m getting by with git-svn, the gateway drug on that). We’ve had pretty much nothing but success with Git for quite some time, but recently this repository started to get chaotic, which has eaten up time… which isn’t conducive to productivity.

So, I wanted to share a quick lesson that we learned today after scratching our head for a while. It’s important that you avoid having a branch on a remote repository that shares the name of a tag in your local and/or remote repository.

I REPEAT.

It’s bad mojo to have a tag and branch share the same name. Things that you’d expect to just work… don’t. This was causing us to see warnings and errors like the following, which we weren’t really sure what to make of it.

“warning: refname ‘staging’ is ambiguous.

“error: src refspec staging matches more than one.”

This started about two weeks ago when we started a few new remote branches: staging and design. It seemed to be going okay but we managed to muck up things when we merged those two together and some of us were having success fetching/pulling/pushing to staging and others were having to specify :heads/staging and couldn’t have a local branch named staging. Needless to say, it was causing some problems and slowing us down.

This afternoon, we finally noticed in the GitHub interface that there was a tag named staging. Hmm… interesting. We verified this by using git show-ref.

Ubiquity meets RubyURL

September 02, 2008

Alex Malinovich decided to take some time this afternoon to write a Ubiquity command for RubyURL using the new RubyURL API. You can take a look at Alex’s Ubiquity code for RubyURL. He’s taking advantage of the JSON support that I added to RubyURL this weekend and JQuery. Be sure to read Alex’s blog post, which includes a screencast! =)

Also! We added this to RubyURL so that if you have Ubiquity installed, you’ll be presented with the following the next time you visit: http://rubyurl.com.

::: thumbnail RubyURL Âť Keep it short (and
sweet) :::

  • [The new RubyURL
API](http://www.robbyonrails.com/articles/2008/08/31/the-new-rubyurl-api)
```text
-   [RubyURL through
```text
QuickSilver](http://www.robbyonrails.com/articles/2008/01/06/rubyurl-through-quicksilver)
```text
-   [RubyURL bookmarklet
```text
screencast](http://www.robbyonrails.com/articles/2007/08/09/rubyurl-bookmarklet-screencast)

Google Chrome: discuss

September 01, 2008

I’m sure that most of you heard the news that Google is releasing a new web browser named Chrome. Their comic for the announcement was very refreshing and entertaining read. Granted… nobody that I know has seen it (as of today)…

For me, I’m really interested in seeing what they’ve done to hopefully improve some of the short-comings of the user experience through their interaction design process. For example, tabs containing their own url/search fields sounds refreshing (I really dislike the hierarchy currently). Also, I’m really looking forward to their dashboard-like default page.

::: thumbnail Google Chrome - Google Book
Search :::

From a web development standpoint, it definitely raises questions about what we’ll be able to do in the coming year(s).

What are your initial thoughts on this? Discuss…

Update: Gary came across this amusing quote from a response by a representative at Microsoft.

“The browser landscape is highly competitive, but people will choose Internet Explorer 8 for the way it puts the services they want right at their fingertips … and, more than any other browsing technology, puts them in control of their personal data on-line,” Hachamovitch said. (read article on CNN)

I’m really not sure what that even means. Don’t we already have our online services at our fingertips? I suspect CNN interviewed the wrong person.. because this person said nothing.

Update #2: Only a PC version available… OSX / Linux are in development. Oh well…

The new RubyURL API

August 31, 2008

We’ve just deployed the initial version of an API for RubyURL. It makes it really easy to create RubyURLs and is now open to the public. Should it end up being abused, we’ll consider introducing an API KEY for authenticating and tracking abuse.

In the meantime, you can now start to use the RubyURL API.

For example, the following…

Git: Push it! (real good)

August 29, 2008

After wrestling with some git-remote-branching-merge-problems… I remembered this song…

If you’re using git, you might add this to your [alias] section in .gitconfig.

(notice the up-on-this alias)

Flash Message Conductor

August 29, 2008

Do you find yourself copying and pasting the same code from Rails application-to-application as new projects start? Our team has a handful of projects in development right now and we notice that some of these reusable components tend to get out of sync when we bounce between projects. So, we’re making an effort to spot these and are creating a handful of plugins so that we can keep them updated between projects. (I’m sure that a lot of you do this as well)

In an effort to share some of our patterns, we’ll try to release them into the wild for others to use and perhaps if you have better patterns to offer, we’re always interested in improving our approach.

Introducing Flash Message Conductor

Over the years, our designers and developers have approached the management of flash messages several different ways. In Rails, the default way to add something to a flash message is to do something like this in your controller.


flash[:message] = “You have successfully signed in to your account.”``ruby\

What we began doing a while back is to create a few controller helper methods:


add_message( “You have successfully signed in to your account.” )ruby\ `add_notice( “You’ve Got Mail!” )ruby\ add_error( “Oops! Something got fucked up!” )```ruby\

Really, nothing too crazy here, just a pattern that our developers have preferred to managing our application’s flash messages.

Okay, so now for the part of the puzzle that we aimed to make consistent across our projects. Rendering flash messages would usually result in several lines of conditionals in our application layout to check if the flash had any values assigned to it. As we worked with our HTML/CSS designers to define a consistent pattern, we moved our code into a helper for rendering flash messages.

With Flash Message Conductor, we just need to pop in the following into our application layout.


<%= render_flash_messages %>``ruby\

If we had called add_message, it’d render the following:

::: {#flash_messages} You have successfully done XYZ… :::

Or, should you have called add_error, it’d render the following:

::: {#flash_messages} Oops! Something went bonkers! :::

What we’ve done here is defined a consistent pattern for our designers and developers to follow. We’ll always have a div container that will use a p tag to display the flash messages with a CSS class value that maps to the type of flash message that we’re displaying. This makes it easier for us to reuse the same flash message styling (and tweak if necessary), but we know that it’ll produce the same HTML across our applications.

Installing Flash Message Conductor

Like most modern Rails applications, you can install with: