Robby on Rails: Category Ruby on Rails

Planet Argon is hiring

Robby Russell — Mon, 22 Aug 2011 23:28:00 -0500

Hello all!

I’ve been so busy this year travelling (for pleasure and work) and helping grow the company that I’ve not had much to say here. Expect some posts soon!

In the meantime, if you’re looking for a new challenge… Planet Argon is seeking a few more Ruby on Rails developers. Interested? get in touch.

Announcing RailsDeveloper

Robby Russell — Wed, 01 Sep 2010 12:01:00 -0500

Earlier today… our team at Planet Argon launched a new site for the Ruby on Rails community. If you have a few spare minutes, I’d love it if you’d to head over and read the announcement on RailsDeveloper.

Enjoy!

Installing Ruby on Rails, Passenger, PostgreSQL, MySQL, Oh My Zsh on Snow Leopard, Fourth Edition

Robby Russell — Mon, 08 Feb 2010 13:14:00 -0600

Welcome to what seems like my tenth installment (actually, it’s the fourth) of showing you how I setup my development environment on a fresh OSX install. In this case, I’m actually getting a MacBook setup for a new employee with Snow Leopard.

Over the years, I’ve evolved these following steps and they’ve helped our team maintain a consistent and stable envirnment for Ruby on Rails development. I know that there are a few other ways to approaching this and I’m sure you’ll get similar results, but this approach has allowed me to maintain a hassle-free setup for the last five years.

As with all things… your milage may vary.

Phase One

During this initial phase, we’re going to install the primary dependencies and setup our environment.

XCode

The first thing that you’ll need to do is install XCode, which almost everything depends upon as this will install developer-friendly tools for you. Apple has been kind enough to ship this on your Snow Leopard DVD.

Go ahead and install XCode from the Optional Installs folder.

(might require a reboot)

You can also download it online.

MacPorts

Now we’ll install MacPorts, which the web site describes itself as, “an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac OS X operating system.”

As I’ve said in past versions of this guide, this tool is about to become one of the most important tools on your operating system. It’ll be used time and time again to maintain your libraries and many of the Unix tools that you’ll be using. If you’re from the Linux or BSD world, you are likely familiar with similar tools… such as: apt-get, port, and yum.

You’ll want to download the latest stable version from http://www.macports.org/. Once downloaded, you can install it.

Once this is installed, you’ll be able to use the port command from your console.

Wget

Let’s test out your MacPorts install by installing a useful tool called wget, which we’ll use to install oh-my-zsh.

sudo port install wget

Git and Subversion

Every development environment should have some source code management tools available. We’ll install both of these with one command.

sudo port install git-core +svn

This will install git and subversion.

oh-my-zsh

Oh My Zsh is the most amazing thing to happen to shells since… well since I said so. It’s one of my open source projects that I encourage you to give a whirl.

wget http://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

That’s it. The next time you open up your terminal, you’ll be running zsh with a bunch of stuff available. For more information, visit http://github.com/robbyrussell/oh-my-zsh.

Terminal theme (optional)

I never understood why the icon for Terminal has a black background but when you start it up the default theme is black on white.

versus

Anyhow, I’m a fan of the the dark background. To change this, open up preferences in Terminal. Select Pro, then click on the Default window so that this sticks around.

Let’s now open up a new Terminal window..

You should be looking at something like this:

Much better… let’s continue.

Phase Two

We’re now going to start installing everything we need to get this running.

Ruby 1.8.7.x

First up, Ruby.

Snow Leopard includes Ruby and Rails already installed, but we’re going to back these up for a rainy day. Just issue these commands:


$ sudo su -
Password:
:~ root# mv /usr/bin/ruby /usr/bin/ruby.orig
:~ root# mv /usr/bin/gem /usr/bin/gem.orig
:~ root# mv /usr/bin/rails /usr/bin/rails.orig
:~ root# logout

Now we’ll go ahead and install a fresh copy of Ruby and RubyGems via MacPorts.

sudo port install ruby rb-rubygems

You should now see something like this for a bit…

Let’s watch a video about bumble bees.

When it finishes installing, you should check that Ruby is available to you and installed in /opt/local/bin.

We’ll also take a second to create a symlink for this as some tools seem to rely on /usr/bin/ruby being there.

sudo ln -s /opt/local/bin/ruby /usr/bin/ruby

Great, let’s move on.

Passenger (mod_rails)

Now that we have Ruby installed, we’re going to take a quick detour to setup Passenger with the Apache server already available on your machine. I’ve been a big fan of using Passenger for your development for over a year now.

sudo gem install passenger

Once the gem is finished installing, you’ll need to install the apache2 module with the following command:

It’ll ask you to continue by pressing Enter. At this point, it’ll check that you have all the necessary dependencies and then compile everything needed for Apache2.

Now I’ll force you to watch a highlights reel of Fernando Torres… the best striker in the world!

The passenger install will then show you this output, which you’ll want to stop and read for a moment and highlight the following:

Then using vi or emacs, you’ll want to create a new file with the following content:

vi /etc/apache2/other/passenger.conf

Then paste in the following (what you highlighted and copied above.)


LoadModule passenger_module /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.9/ext/apache2/mod_passenger.so
PassengerRoot /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.9
PassengerRuby /opt/local/bin/ruby

You’ll also want to include the following below what you just pasted.


  # Set the default environment to development
  RailsEnv development

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

You’ll want to quickly start up your web sharing, which will start Apache2 up via your System Preferences.

Simple enough… moving forward.

Passenger Pref Pane

To make things as simple as possible, I’d encourage you to install the Passenger Preference Pane (view this post for a download).

Development directory

I have a directory named development/ in my home directory, which is where I end up storing all of my projects. This should match whatever you put above in the apache configuration (<Directory "/Users/ryangensel/development">).

mkdir development; cd development;

Installing Ruby on Rails via RubyGems

Now we’ll use RubyGems to install the latest version of Ruby on Rails (and all of it’s dependencies).

sudo gem install rails

While this is installing, you can watch a video from my old band that ended around the time that business started picking up for Planet Argon.

Great, let’s test out the install of Rails…

Test Rails and Passenger

In your development directory, let’s quickly a new Rails app…

rails testapp

This will generate a new Rails application in a testapp/ directory.

Now open up the Passenger Preferences Pane and add this directory as a new application.

Press Apply…

You should now fire up your browser of choice and head to http://testapp.local. If all has worked, you’ll see a, “Welcome aboard” screen from the Ruby on Rails application.

Assuming that this worked for you, let’s take a quick break to make some tea…

Phase Three

In this last phase, we’re going to install a few database servers and corresponding rubygems so that you can get to work.

PostgreSQL

At Planet Argon, we build our web applications on top of PostgreSQL. I’ve been a long-time advocate of it and hope you consider using it yourself.

At this point in time, the current stable version of PostgreSQL via MacPorts is 8.4.x. Let’s install that now…

sudo port install postgresql84 postgresql84-server

Once this finishes compiling, you’ll need to run the following commands to setup a new PostgreSQL database.


sudo mkdir -p /opt/local/var/db/postgresql84/defaultdb
sudo chown postgres:postgres /opt/local/var/db/postgresql84/defaultdb
sudo su postgres -c '/opt/local/lib/postgresql84/bin/initdb -D /opt/local/var/db/postgresql84/defaultdb'

Assuming that you want PostgreSQL to always be running, you can run:

sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql84-server.plist

...and to start it right now, run:

sudo launchctl start org.macports.postgresql84-server

Before you can start using it, we’ll need to make sure that the PostgreSQL executables are available in your shell path. Since you’re now using oh-my-zsh, you’ll want to edit ~/.zshrc with your favorite editor.

vi ~/.zshrc

Just append this to export PATH= line in the file.

:/opt/local/lib/postgresql84/bin

Your PATH might look something like the following now:

@# Customize to your needs… export PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/opt/local/lib/postgresql84/bin@

Setup database user

To setup a new database (with superuser credentials), just run:

createuser --superuser ryangensel -U postgres

We’ll now test creating a database:

createdb test_db

Let’s test that we can access it…


➜  ~  psql test_db
psql (8.4.2)
Type "help" for help.

test_db=# \q

Great, let’s drop it now.


➜  ~  dropdb test_db
➜  ~  psql test_db
psql: FATAL:  database "test_db" does not exist
➜  ~

Okay, we’ll now install the library that will allow Ruby to talk to PostgreSQL.

Just run: sudo gem install pg

Voila… let’s move on to the inferior database…

MySQL

We’re going to run through the installation of MySQL really quickly because you might need it.

sudo port install mysql5 mysql5-server

This took ages on my machine… so let’s watch a video.

We’ll now setup the database and make sure it starts on system boot.


 sudo -u _mysql mysql_install_db5
 sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
 sudo launchctl start org.macports.mysql5

Let’s test that we can create a database now (and that it’s running.)


 ➜  ~  mysql5 -u root
 Welcome to the MySQL monitor.  Commands end with ; or \g.
 Your MySQL connection id is 3
 Server version: 5.1.43 Source distribution

 Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

 mysql> create database test1;
 Query OK, 1 row affected (0.00 sec)

 mysql> \q

Great, we’ll now install the library that will allow Ruby to talk to MySQL.

sudo gem install mysql -- --with-mysql-config=/opt/local/lib/mysql5/bin/mysql_config

That should be it!

Phase Four, next steps

Okay… so we’ve installed XCode, MacPorts, Ruby, Rails, PostgreSQL, MySQL… and I’ve also got you to switch your default terminal shell from bash to zsh. You might take a look over the available themes for Oh My Zsh so that you can personalize your terminal experience even further.

You also now have a handful of gems installed as you can see with gem list.

Closing thoughts…

This is the fourth version of this guide and I’ve appreciated the hundreds of comments, questions, and emails that I have received… let’s not forget all those beers that people buy me when I’m at conferences. :-)

I hope you have found some of this useful. If you have any problems and/or questions, don’t hesitate to post them in the comments section below.

RubyURL goes GOP...

Robby Russell — Wed, 16 Dec 2009 23:08:00 -0600

Will refrain from any political commentary, but was notified by some friends that the GOP was using the source code for RubyURL for their new URL shortening site (gop.am).

To celebrate, I decided to daisy chain a few rubyurl-based sites together and came up with:

http://rubyurl.com/hj6l

Enjoy!

As always, you can fork/clone here

Sending email: Controllers versus Models

Robby Russell — Mon, 16 Nov 2009 09:33:00 -0600

While reviewing some code recently, I came across controller code that resembled the following.

if @customer.save
  CustomerMailer.deliver_welcome_message(@customer)
  flash[:message] = "Your account has been successfully created. We've sent you a welcome letter with..."
  redirect_to dashboard_path
else
  ...
end

Fairly typical Rails code. Nothing alarming here, but I wanted to evaluate the call to the mailer in this scenario. When it comes to sending emails from your application, you can choose to do it from the controller as in the example above or in your models. Our team prefers to do this from our model via a callback as we are considering this to be part of our business logic.

Each time a customer is created, we want to send them an email. This can be moved into the model and resembled something like the following..

after_create :send_welcome_message #, other callbacks..

def send_welcome_message
  CustomerMailer.deliver_welcome_message(self)
end

There are a few benefits to doing it this way.

We can test that this is being triggered within our model specs instead of our controller specs. (we prefer to spend more of our time working within models than controllers)
We remove the dependency that all requests must be processed through our controllers.
- Example: We may one day create rake tasks that data and want these emails to still be sent out. (We’ve had to do this a few times)

I definitely don’t think doing this via controllers is a bad idea, I just lean towards keeping controllers as dumbed down as possible. This allows us to have less controller code that is focused on passing data to/from models and letting our models do the heavy lifting.

UPDATE: DHH was kind enough to post a more detailed response on his blog.

Launching Ruby on Rails projects, the video

Robby Russell — Wed, 11 Nov 2009 12:00:00 -0600

For those of you who didn’t make it to Rails Underground in July to witness my mind-blowing talk, Launching Ruby on Rails projects , it appears that Skills Matter has finally posted a video of it online. :-)

The sound levels are really low… but hopefully you’ll find it helpful.

You can also view the slides.

Launching Ruby on Rails projects, a checklist

Tracking Google Analytics events in development environment with GoogleAnalyticsProxy

Robby Russell — Sun, 01 Nov 2009 13:55:00 -0600

As mentioned in a recent article¹, I’ve been diving deep into Google Analytics lately while working on a few client projects. We’re aiming to use much more of the features of Google Analytics and have been hitting some roadblocks with the development versus production application environments. Once you begin to dive into event tracking and AJAX-driven goal conversions, relying on just the sample code that Google Analytics provides you is going to result in you looking at a handful of JavaScript errors.

another example from the firebug javascript console…

We see JavaScript errors like this because we don’t load the google analytics code in our development environments. As you can see, we are only loading this in our production environment.

  <% if RAILS_ENV == 'production' -%>
    <!--// Google Analytics //-->
    <script type="text/javascript">
    var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
    document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
    </script>
    <script type="text/javascript">
    var pageTracker = _gat._getTracker("UA-XXXXXX-1");
    pageTracker._trackPageview();
    </script>
  <% end -%>

To track an event with Google Analytics, you’d need to trigger something like:

  pageTracker._trackEvent('Button', 'Click', 'Get in touch');

As you can see from our code earlier, in development, the pageTracker variable isn’t defined and that’s why we’re getting those JS errors. We also don’t want to add conditionals everywhere in our application to check if we’re in development or production environment.. as that’d just make our views uglier than they need to be. So, I decided that I’d create a proxy class in JavaScript that would allow us to trigger _trackEvent() and _trackPageview() and handle it appropriately.

This class works with the following logic:

if google analytics is loaded, pass the parameters to the real pageTracker
if google analytics is NOT loaded, output the information to console.log() for debugging purposes

For example, on a gallery on our web site… we track when people navigate next and/or previous through the photos. In our development environment, I can watch the JavaScript console output the following:

And in our production environment, we can see that this was sent to Google Analytics.

We’re able to do this by initializing the GoogleAnalyticsProxy class and calling these functions through it. For example:

  _gap = new GoogleAnalyticsProxy();
  _gap._trackEvent('Video', 'Play', 'Homepage video');
  _gap._trackEvent('Video', 'Pause', 'Homepage video');
  _gap._trackEvent('Button', 'Click', 'Call to action X');

You’ll see that we’re just calling _gap versus pageTracker. We then replace all the instances of pageTracker (except where it is defined in the google analytics code block they provide you). You’ll find this located near the bottom of our application.html.erb file.

<% if RAILS_ENV == 'production' -%>
  <!--// Google Analytics //-->
  <script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
  </script>
  <script type="text/javascript">
  var pageTracker = _gat._getTracker("UA-XXXXXX-1");
  pageTracker._trackPageview();
  </script>
<% end -%>

<script type="text/javascript">
  var _gap = new GoogleAnalyticsProxy();
</script>

We now have _gap available throughout our project and can call _trackEvent() and _trackPageview() with it. Note: You can use any JS variable name that you want, _gap is just what I went with.

Get GoogleAnalyticsProxy

I’ve gone ahead and tossed this small JavaScript class (known as GoogleAnalyticsProxy) on Github for your enjoyment. I have some more articles in the works that will show you some tips for how to make the most of Google Analytics. If you have any questions and/or ideas for related article topics, don’t hesitate to let me know.

¹ Tracking AJAX-driven events in Ruby on Rails for Google Analytics conversion goals

Planet Argon Podcast, Episode 2: The Letter Scotch

Robby Russell — Fri, 30 Oct 2009 08:27:00 -0500

Earlier this week our new podcast was approved and is now available in the Apple iTunes Store. We’re also soliciting topic ideas for future episodes on brainstormr.

We posted Episode 2, The Letter Scotch, yesterday for your enjoyment. In this episode, we covered a handful of web browser tools that we use (and detest) to debug HTML, CSS, and JavaScript. This included Web Inspector, Firebug, DebugBar, and a handful of other tools. We all have slightly different preferences, depending on the tasks that we’re working on and the team had an open dialogue about the pros/cons of each of these tools.

You can learn more about and listen to our podcast at http://planetargon.com/podcast.

Thanks in advance for listening!

Planet Argon Podcast, Episode 1: Shin Splints

Robby Russell — Thu, 22 Oct 2009 18:50:00 -0500

We’re currently waiting to get our new podcast approved by Apple, but have uploaded episode 1 to tumblr in the meantime.

In this short episode, we cover the following topics:

We’re planning to keep this short and focused to a few topics. Once it’s posted on iTunes, we’ll let you know.

Please consider subscribing to the podcast. Enjoy!

RailsOnPg released

Robby Russell — Wed, 21 Oct 2009 17:07:00 -0500

Hello fellow PostgreSQL and Ruby on Rails geeks,

Alexander Tretyakov (twitter) recently released a plugin for Ruby on Rails, which extends migrations and provides you with the ability to create.

Functions (pg docs)
Triggers (pg docs)
Views (pg docs)

While you can already do something like this with execute in your migrations:

execute("CREATE VIEW my_tasty_snacks AS SELECT * FROM snacks WHERE food = 'Tasty';")

With RailsOnPage, you’re provided a DSL so that you can do the following:

create_view :my_tasy_snacks do |view|
  view.select     '*'
  view.from       'snacks'
  view.conditions 'food' => 'Tasty'
end

note: I haven’t tested the above, just a hypothetical example

Anyhow, if you’re in the habit of using views, functions, or triggers with your PostgreSQL database and are using Ruby on Rails, you might give RailsOnPg a whirl.

Tracking AJAX-driven events in Ruby on Rails for Google Analytics conversion goals

Robby Russell — Wed, 21 Oct 2009 13:09:00 -0500

Tracking your KPI’s is extremely important in your online venture. At a minimum, you should be using something like Google Analytics to track conversions in your application. Setting up goals is actually quite simple, especially if you’re just tracking that specific pages are loaded. However, if some of your conversion points occur through AJAX, you might not be capturing those activities in Google Analytics.

Lucky for you, it’s actually quite simple to update this. I thought I’d show you a fairly simple example to help you along.

On our web site, we have a mini contact form at the bottom of many of our pages. When submitted, if JavaScript is enabled, it’ll perform an Ajax request to submit the form. If you fill out the main Get in Touch form that gets processed and we redirect people to a thank you page. The URL for that is unique and we’re able to track those in Google Analytics quite easily.

However, with the Ajax-form, the URL in the browser isn’t going to change so Google Analytics isn’t going to track that conversion. So, we needed to track that properly.

To do this, we just need to call a JavaScript function that the Google Analytics code provides you.

  pageTracker._trackPageview("/contact_requests/thanks");

Let’s look at some simple code from our controller action. If the request is from JavaScript, we currently replace the form area with the content in a partial. (note: if you’re curious about the _x, read Designers, Developers and the x_ factor)

  respond_to do |format|
    format.html { redirect_to :action => :thanks }
    format.js do
      render :update do |page|
        page.replace :x_mini_contact_form_module, :partial => 'mini_contact_form_thanks'
      end
    end
  end

As you can see, the redirect will within the format.html block will lead people to our conversion point. However, the format.js block will keep the user on the current page and it’ll not trigger Google Analytics to track the conversion. To make this happen, we’ll just sprinkle in the following line of code.

  page.call 'pageTracker._trackPageview("/contact_requests/thanks");'

However, if you need to do something like this in several locations in your application, you might want to just extend the JavaScriptGenerator page. GeneratorMethods. (you could toss this in lib/, create a plugin, etc…)

  module ActionView
    module Helpers
      module PrototypeHelper
        class JavaScriptGenerator #:nodoc:
          module GeneratorMethods
            # Calls the Google Analytics pageTracker._trackPageview function with +path+.
            #
            # Examples:
            #
            #
            #  # Triggers: pageTracker._trackPageview('/contact_requests/thanks');
            #  page.track_page_view '/contact_requests/thanks'
            #
            def track_page_view(path)
             record "pageTracker._trackPageview('#{path}');"
            end
          end
        end
      end
    end
  end

This will allow us to do the following:

  page.track_page_view "/contact_requests/thanks"

  # or using a route/path
  page.track_page_view thanks_contact_requests_path

So, our updated code now looks like:

render :update do |page|
  page.replace :x_mini_contact_form_module, :partial => 'mini_contact_form_thanks'
  page.track_page_view thanks_contact_requests_path
end

With this in place, we can sprinkle similar code for our various conversion points that are Ajax-driven and Google Analytics will pick it up.

Happy tracking!

The 8-Hour Rails Code Audit

Robby Russell — Tue, 20 Oct 2009 07:13:00 -0500

While our team is typically focused on larger client and internal projects, we do get an opportunity to assist businesses on a much smaller scale. Whether this be through retainer-based consulting or through code audits, we have seen a lot of Ruby on Rails code over what has nearly been… five years!? We’ve been able to compile a fairly extensive checklist that we use in our code audit process that we’ve decided to streamline it into a smaller product.

Historically, this service has ranged anywhere from $2000-6000, depending the size and scope of the projects, but we want to help smaller startups¹ and projects outline a roadmap for how they can begin to refactor and optimize their existing code base so that they can be more efficient at the start of 2010. So, we’ve scaled things down into an extremely affordable flat-rate package where we work off of a pre-defined number of hours.[2]

Through the end of 2009, we’re now offering the 8-Hour Rails Code Audit package for just $1000 USD (details).

We’re currently limiting this service to just two projects per week, so reserve your spot now.

¹ Larger projects are welcome to benefit from this service and custom quotes are available upon request.

² As always, we’re happy to discuss longer engagements.

Flash Message Conductor now a Gem

Robby Russell — Tue, 13 Oct 2009 10:30:00 -0500

We’ve been doing some early (or late… if you’re a half-full kind of person) spring cleaning on some of our projects. One of the small projects, flash_message_conductor, which we released last year as a plugin is now a gem. We’ve been moving away from using plugins in favor of gems as we like locking in specific released versions and being able to specify them in our environment.rb file is quite convenient.

To install, just run the following:


  sudo gem install flash-message-conductor --source=http://gemcutter.org
  Successfully installed flash-message-conductor-1.0.0
  1 gem installed
  Installing ri documentation for flash-message-conductor-1.0.0...
  Installing RDoc documentation for flash-message-conductor-1.0.0...

You’ll then just need to include the following in your config/environment.rb file.

Rails::Initializer.run do |config|
  # ...
  config.gem 'flash-message-conductor', :lib => 'flash_message_conductor', :source => "http://gemcutter.org"
end

You can take a peak at the README for usage examples.

We’ll be packaging up a handful of our various plugins that we reuse on projects and moving them to gems. Stay tuned… :-)

Planting the seeds

Robby Russell — Sat, 05 Sep 2009 08:00:00 -0500

Yesterday, the Rails team released 2.3.4, which includes standardized way for loading seed data into your application so that you didn’t have to clutter your database migrations.

I noticed a few comments on some blogs where people were asking how to use this new feature, so here is a quick runthrough a few ways that you can use it.

Populating Seed Data Approaches

The db/seeds.rb file is your playground. We’ve been evolving our seed file on a new project and it’s been great at allowing us to populate a really large data. Here are a few approaches that we’ve taken to diversify our data so that when we’re working on UI, we can have some diversified content.

Basic example

Any code that add to db/seeds.rb is going to executed when you run rake db:seed. You can do something as simple as:

# db/seeds.rb

Article.create(:title => 'My article title', :body => 'Lorem ipsum dolor sit amet, consectetur adipisicing elit')

Just create database records like you would in your Rails application or in script/console. Simple enough, right? Let’s play with a few other approaches that we’ve begun to use.

Use the names of real people

We’re using the Octopi gem to connect to github, collect all the names of people that follow me there, and using their names to seed our development database.

@robby_on_github = Octopi::User.find('robbyrussell')

# add a bunch of semi-real users
@robby_on_github.followers.each do |follower|
  github_person = Octopi::User.find(follower)
  next if github_person.name.nil?

  # split their name in half... good enough (like the goonies)
  first_name = github_person.name.split(' ')[0]
  last_name = github_person.name.split(' ')[1]
  new_person = Person.create(:first_name => first_name, :last_name => last_name, :email => Faker::Internet.email,
                             :password => 'secret', :password_confirmation => 'secret',
                             :github_username => follower, :website_url => github_person.blog)
  # ...
end

We do this with a few sources (twitter, github, etc..) to pull in the names of real people. If you want to be part of my seed data, you might consider following me on Github. ;-)

Use Faker for Fake data

You may have noticed in the previous code sample, that I used Faker in that code. We are using this a bunch in our seed data file. With Faker, you can generate a ton of fake data really easy.

person.links.create(:title => Faker::Lorem.words(rand(7)+1).join(' ').capitalize,
                    :url => "http://#{Faker::Internet.domain_name}/",
                    :description => Faker::Lorem.sentences(rand(4)+1).join(' '))

We might toss something like that into a method so that we can do the following:

@people = Person.find(:all)

500.times do
  generate_link_for(@people.sort_by{rand}[0])
end

...and we’ll get 500 links added randomly across all of the people we added to our system. You can get fairly creative here.

For example, we might even wanted random amounts of comments added to our links.

def generate_link_for(person)
  link = person.links.create(:title => Faker::Lorem.words(rand(7)+1).join(' ').capitalize,
                             :url => "http://#{Faker::Internet.domain_name}/",
                             :description => Faker::Lorem.sentences(rand(4)+1).join(' '))

  # let's randomly add some comments...
  if link.valid?
    rand(5).times do
      link.comments.create(:person_id => @people.sort_by{rand}[0].id,
                           :body => Faker::Lorem.paragraph(rand(3)+1))
    end
  end
end

It’s not beautiful, but it gets the job done. It makes navigating around the application really easy so that we aren’t having to constantly input new data all the time. As mentioned, it really helps when we’re working on the UI.

Your ideas?

We’re trying a handful of various approaches to seed our database. If you have some fun ways of populating your development database with data, we’d love to hear about it.

So long and thanks for all the hoodwinks

Robby Russell — Thu, 20 Aug 2009 00:24:00 -0500

_why,

If you’re out there and come across this… know that one of my fondest memories on the internet was with you. Hoodink.d was one of the greatest things on the internet four years ago and I suspect that a very tiny fraction of the Ruby community has even heard of it.

Fortunately for me, I have a copy of the hoodwink git repository and was able to get it running tonight in hopes that I might find you lurking in the mousehole. I’m convinced that you are in a parallel internetverse. Perhaps you might send me an invite.

I miss hoodwink… and if you stay missing, I’ll just miss hoodwink more.

In the meantime, I wonder how hard it’ll be to get hoodwink to run on rack.

Wink you on the other side, Robby

p.s. you can find me in my own mousehole… should you want to send me an invite and/or feed me cheese.

Thank you hoodwink.d

Ch-ch-ch-changes at Planet Argon

Robby Russell — Wed, 12 Aug 2009 18:31:00 -0500

Now that the cat is out of the bag, I can share some recent news with you. Earlier today, we announced that Blue Box Group had acquired Rails Boxcar, our kickass deployment solution for Ruby on Rails applications.

Our team has been offering hosting services for over six years. When I made the decision to start providing Rails hosting over four years ago, it was something that I thought the community needed to validate that Ruby on Rails was a viable solution for building web applications. At the time, there was only one or two companies offering pre-configured solutions. The good ole days. :-)

Over the course of the past 4+ years, we’ve helped deploy and host well over a thousand web applications built with Ruby on Rails. Perhaps we even hosted your site at one point or another. We definitely had a lot of fun and learned a lot from our experience.

Fast-forward four years, the community now has several great solutions and options for hosting their Ruby on Rails applications. Knowing this, we began to look over the plethora of services that we offer and felt that we had been spreading ourselves too thinly. We were faced with the big question of: Should we focus our energy on trying to innovate in this competitive space or should we find a community-respected vendor to pass the torch to?

Rails Boxcar is a product that we are extremely proud of and believe the acquisition by Blue Box Group will be great for our existing customers. The acquisition is going to benefit our customers as they’ll be able to interface with a team with more resources. A team that also aims to innovate in this space and believes that Rails Boxcar will help them do that.

As a byproduct of this deal, our team has an opportunity to focus our collective energy on designing and developing web applications, which has also been a central part of what we do for as long as we’ve been in business. We plan to speed up our efforts on a handful web-based products that we’ve been internally developing and hope to release in the near future.

I had the pleasure of getting to talk thoroughly with the team at Blue Box Group and really feel like they’ll be able to focus their energy on maintaining and innovating within the Ruby on Rails hosting world.. definitely more than we could over the coming years. In the end, the acquisition is going to benefit our customers the most as they’ll be able to interface with a larger team that is innovating in this space.

If you’re interested in learning more about the acquisition, please read the press release.

From our perspective, this is a win-win-win situation for everyone involved. Expect to see some more news from us in the near future… and if you’re looking for a design and development team, don’t hesitate to get in touch with us.

Slides from my Rails Underground 2009 talk

Robby Russell — Fri, 24 Jul 2009 10:37:00 -0500

Hello from London!

Am currently enjoying the talks at Rails Underground 2009 in London and had the pleasure to be one of the first speakers at the conference. My talk covered a collection of what our team considers best practices. Best practices that aid in the successful launch of a web application and covered a few Rails-specific topics as well.

I’ll be sharing some posts in the coming week(s) that’ll expand on some of these topics as promised to the audience.

Launching Ruby on Rails projects: A checklist

View more documents from Robby Russell.

Since I covered a wide range of topics, I decided to share my slides online. They won’t provide as much context (as I’m not speaking as you’ll look at them), but they might hint at some of the topics that I covered. There was a guy video taping the talks… so I assume that a video of my talk will be posted online in the near future.

Until then… here are the slides

Launching Rails projects, an open call for lessons learned

Robby Russell — Tue, 23 Jun 2009 12:33:00 -0500

I’m working on my presentation for Rails Underground and was hoping to solicit a few tips from other people in the industry.

Have you launched a Ruby on Rails application recently? Are there some things that you wish you had known beforehand?

Mind sharing? You can email me with your story at robby+launchstory@planetargon.com. I’ll let you know if your tip gets used in the presentation and please indicate if you’d be okay with me posting your tip in a future blog post.

Using model constants for project sanity

Robby Russell — Tue, 23 Jun 2009 01:39:00 -0500

On one of our larger client projects (approx. 160 models and growing…) we have a specific model that we refer to quite a bit throughout our code. This model contains less than 10 records, but each of them sits on top of an insanely large and complex set of data. Each record refers to a each of their regions that our client does business in.

For example… we have, Australia, United Kingdom, Canada, United States, and so forth. Each of these regional divisions has their own company code, which are barely distinguishable from the next. They make sense to our client, but when we’re not interacting with those codes on a regular basis, we have to look constantly look them up again to make sure we’re dealing with the right record.

I wanted to share something that we did to make this easier for our team to work around these codes, which we should have thought of long ago.

Let’s take the following mode, Division. We only have about 10 records in our database, but have conditional code throughout the site that are dependent upon which divisions specific actions are being triggered within. Each division has various business logic that we have to maintain.

Prior to our change, we’d come across a lot of code like:

# For all divisions except Canada, invoices are sent via email
# In Canada, invoices are sent via XML to a 3rd-party service
def process_invoices_for(division)
  if division.code == 'XIUHR12'
    # trigger method to send invoices to 3rd party service
    # ...
  else
    # batch up invoices and send via email
    # ...
  end
end

An alternative that we’d also find ourselves using was.

if division.name == 'Canada'

Hell, I think I’ve even seen if division.id == 2 somewhere in the code before. To be fair to ourselves, we did inherit this project a few years ago. ;-)

Throughout the code base, you’ll find business rules like this. Our developers all agreed that this was far from friendly and/or efficient and worst of all, it was extremely error-prone. There have been a few incidents where we read the code wrong and/or got them confused with one another. We were lacking a convention that we could all begin to rely on and use.

So, we decided to implement the following change.

Model Constants

You might already use constants in your Ruby on Rails application. It’s not uncommon to add a few into config/environment.rb and call it a day, but you might also consider scoping them within your models. (makes it much easier for you to maintain them as well)

In our scenario, we decided to add the following constants to our division model.

class Division < ActiveRecord::Base
  AFRICA      = self.find_by_code('XYU238')
  ASIA        = self.find_by_code('XIUHR73')
  AUSTRALIA   = self.find_by_code('XIUHR152')
  CANADA      = self.find_by_code('XIUHR12')
  USA         = self.find_by_code('XIUHR389')
  # etc..
end

What this will do is load up ech of these constants with the corresponding object. It’s basically the equivallent of us doing:

if division == Division.find_by_code('XIUHR389')

But, with this approach, we can stop worrying about their codes and use the division names that we’re talking about with our clients. Our client usually approaches us with, “In Australia, we need to do X,Y,Z differently than we do in the other divisions due to new government regulations.”

if division == Division::CANADA
  # ...
end

case division
  when Division::AFRICA
    #
  when Division::AUSTRALIA
    # ...
end

We are finding this to be much easier to read and maintain. When we’re dealing with a lot of complex business logic in the application, little changes like this can make a big difference.

If you have any alternative solutions, we’d love to hear them. Until then, we’ve been quite pleased with this approach. Perhaps you’ll find some value in it as well.

Aliasing resources in Ruby on Rails

Robby Russell — Tue, 23 Jun 2009 01:00:00 -0500

Earlier today, a friend working on a project asked me how we approached routes on our website. If you take a quick peak at our website, you’ll see that we have URLs like so:

http://planetargon.com/
http://planetargon.com/who-we-are
http://planetargon.com/who-we-are/robby-russell
I couldn’t remember where I came across this before and wasn’t quickly finding it in the Ruby on Rails API, so decided that I’d do a quick write up on it.

When we launched our new site a few months ago, we were working off an existing code base. We have a model named, TeamMember and a corresponding controller. When we decided to come up with new conventions for our URL structure, we opted to ditch the normal Rails conventions and go our own route. What we weren’t sure about was how to alias resources in our routes nicely. After some digging around, we came across the :as option.

So, our route was:

  map.resources :team_members

Which provided us with:

/team_members
/team_members/robby-russell

We simply added :as => 'who-we-are' to our route:

  map.resources :team_members, :as => 'who-we-are'

...and we got exactly what we were looking for in our URLs.


* /who-we-are
* /who-we-are/gary-blessington

If you look at our site, you’ll notice that we did this in a few areas of our application so that we could define our own URL structure that was more friendly for visitors and search engines.

Anyhow, just a quick tip for those who want to change up their URLs with Ruby on Rails.

p.s., if you know where I can find this documented, let me know so that I can provide a URL in this post for others. :-)

Speaking at Rails Underground 2009

Robby Russell — Thu, 18 Jun 2009 08:40:00 -0500

It’s time to find my passport again…

I’ve been invited to speak at Rails Underground, which is being held in London, UK from July 24-25th.

My talk, which is tentatively titled, “Launching Ruby on Rails projects, a checklist”, will expand on several ideas that came out a previous article on the topic. Additionally, I plan to share some of the lessons that we’ve learned at Planet Argon as we’ve launched projects over last several years.

If you’re able to make it, I encourage you to register for the event before it’s too late. Take a quick peak at the list of speakers. I’m grateful to the event organizers for the invite and look forward to seeing/meeting all of the attendees!

Also, for those of you in the London area. If you’re seeking a design and development team that specializes in Ruby on Rails and want to schedule a meeting with me while I’m visiting, don’t hesitate to get in touch with us. I’m planning on staying a few days extra around the conference dates to visit some of our existing clients and would be happy to meet you.

Howdy Rip!

Robby Russell — Thu, 11 Jun 2009 12:35:00 -0500

Chris Wanstrath (@defunkt) just posted the following on twitter.

“Hello Rip – http://hellorip.com/“

The Rip project describes itself as, “an attempt to create a next generation packaging system for Ruby.”

One of the cool features is that it supports multiple environments. For example, you can have different Rip environments (with different gem versioning) that are targeted towards specific applications. I have to dig around more through the project, but this looks fascinating.

Check it out at http://hellorip.com/

I’m also curious as to how you think you might be able to start using this.

What are some ways that you could use Rip—http://heybrainstormr.com/t/pgte

Hello, HeyBrainstormr.com

Robby Russell — Wed, 03 Jun 2009 18:28:00 -0500

If you follow me on twitter, you might have heard that we launched a little project that we’ve been cooking up at Planet Argon. (news post)

HeyBrainstormr is a lightweight web application that we created so that we could start a brainstorm on a specific topic and solicit ideas from each other. That’s all it does. Nothing more. Nothing less.

We know that having an open brainstorming session requires there to be zero criticism and opted to keep the process anonymous so that even the quiet people could share their ideas. :-)

We’ll be posting more details about it on our blog in the near future, but wanted to invite all of my readers to give it a whirl.

Start a brainstorm now!

I have a few topics that I started (and tweeted about). Feel free to share your ideas on them. :-)

We hope that you find it as fun as we have.

82,520 minutes on Phusion Passenger

Robby Russell — Fri, 10 Apr 2009 05:10:00 -0500

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.

20 articles on Cucumber and a free beverage recipe!

Robby Russell — Thu, 09 Apr 2009 22:22:00 -0500

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. :-)

What’s in a Story?, Dan North
Telling a good story – Rspec stories from the trenches, Joseph Wilk
Beginning with Cucumber, Ryan Bates (Railscasts)
Using RSpec, Cucumber and User stories to build our internal systems, Rahoul Baruah
Cucumber: The Latest in Ruby Testing, Ruby Inside
Using Cucumber for Acceptance Testing, Noel Rappin
Behavior Driven Development with Cucumber, Brandon Keepers (presentation/slides)
Testing capistrano recipes with cucumber, Jeff Dean
Using Cucumber to Integrate Distributed Systems and Test Messaging, Ben Mabey
Tutorial: How to install/setup Cucumber, Alan Mitchell
Testing outbound emails with Cucumber, Dr. Nic Willians
Proper Cucumber Sintatra Driving, Chris Strom
On getting started using Cucumber for .NET
DRY up your Cucumber Steps, Matt Wynne
Cucumber, Celerity, & FireWatir, Aidy Lewis (presentation/video)
Cucumber step definition tip: Stubbing time, Bryan Helmkamp
Story Driven Development Recipes with Cucumber, Sebastien Auvray
Testing Facebook with Cucumber, Brandon Keepers
Testing with the help of machinist, forgery, cucumber, webrat and rspec, Etienne van Tonder
Integration testing SSL with Cucumber
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

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

Robby Russell — Mon, 16 Mar 2009 02:05:00 -0500

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')
=> "{\"responseData\": {\"translatedText\":\"festa\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"
>> GoogleApi.translate('party', 'es')
=> "{\"responseData\": {\"translatedText\":\"fiesta\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"

Look how easy that was. :-)

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

The Rails Hosting Survey 2009 Survey results are in!

Robby Russell — Wed, 11 Mar 2009 13:27:00 -0500

We recently announced a survey that touched on topics related to the deployment and hosting of Ruby on Rails applications. We promised to share the results with the community and have made this information available at http://rails-hosting.com. You can download the results in CSV, PDF, and view them in HTML here.

Thanks again to everyone who helped us execute this survey!

Show me your and I'll show you mine (terminal prompts with git branches)

Robby Russell — Fri, 13 Feb 2009 12:57:00 -0600

I asked on twitter but only got a small handful of responses. So, I’m taking it here.

Show me yours and I’ll show you mine. Your terminal prompt that you’re using. Inspire me with new ideas for my prompt.

Here is mine.

Now… show me yours.

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

Robby Russell — Wed, 11 Feb 2009 16:52:00 -0600

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.. 2 1/2 years ago back when Mongrel was just a puppy

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.

this guy was a passenger…and I recently started to watch the show

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.

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.

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!)

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

Robby Russell — Wed, 28 Jan 2009 23:30:00 -0600

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?

Moving to Ruby Enterprise Edition (REE)
Moving to Passenger (mod_rails) by default
All-new pricing structure! (starting at $35/month)

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.

Visit RailsBoxcar.com

Rails Hosting Survey - 5 days left...

Robby Russell — Tue, 27 Jan 2009 10:52:00 -0600

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!

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

Rails Hosting Survey (continued)

Robby Russell — Thu, 15 Jan 2009 17:36:00 -0600

Thanks to everyone has taken the survey and mentioned it on twitter. We just passed 400 people. We have a ways to go before we hit our goal of at least 1500 people surveyed. (if we can get even more than that… great!)

The survey is taking most people less than 5 minutes to complete, so if you haven’t filled it out yet and have experience deploying Ruby on Rails applications, here’s a link. :-)

Any help that you can provide in getting the word out would be greatly appreciated.

Thanks!

Question: Plugins or Gems? (or both?)

Robby Russell — Tue, 13 Jan 2009 13:56:00 -0600

Our development team likes to extract reusable pieces of code for our projects and have historically used plugins. However, we are finding more and more people releasing these sorts of modules/components/patterns as gems.

Which do you prefer and why?

If you use both, how do you decide to use plugins or gems?

Take the Ruby on Rails Hosting in 2009 Survey

Robby Russell — Tue, 13 Jan 2009 12:40:00 -0600

Calling all Ruby on Rails developers and system administrators.

The team at Planet Argon is hoping to collect some information about how everyone is currently managing the deployment and hosting of their Ruby on Rails applications. We are inviting you all to participate in the Rails Hosting in 2009 survey, which consists of nearly forty questions about you and your Rails hosting experiences. Most people say it is taking less than five (5) minutes to complete it. =)

We will collect responses for the survey until the end of January and will then publish the results (with anonymous raw data) for everyone in the community to share and use.

Our goal is to use this information ourselves to continue to evolve our hosting-related products and deployment services for you. We also want all of our fellow hosting providers and development teams to have access to this information so that they can continue to improve their services. Rails deployment and hosting is getting easier for us all, but we know that there is always room from improvement.

We make an effort to keep our ear close to the ground in the community to listen for trends and problems, but sometimes it’s better to just ask directly.

So, if you have a few minutes to spare, please take the survey!

update: some people mentioned that we should have made some options multi-select. it’s too late to change it without losing submissions. so, for questions like: Monit, God, or Other (and you’re using God and Monit, put that in Other and we’ll track them accordingly)

P.S. Please spread the word about the survey!

Get to know a gem: Ghost

Robby Russell — Mon, 12 Jan 2009 00:18:00 -0600

In my last post, Subdomain accounts with Ruby on Rails explaind, I mentioned that you’d need to modify your /etc/hosts file to use custom subdomains for development/testing. Apparently, there is a much better way to handle this that I was introduced to by Nathan de Vries. Nathan suggests using a gem that I hadn’t heard of before that bares the name of Ghost (view project on github).

Ghost describes itself as…

“A gem that allows you to create, list, and modify local hostnames in 10.5 with ease…”—

If you’ve ever had to modify your /etc/hosts file for anything local, I highly encourage you to check out this shiny gem.

Installing Ghost

Like most gems, you can just install Ghost with the following command.


~ : sudo gem install ghost
Password:
Successfully installed ghost-0.1.2-universal-darwin-9
1 gem installed
Installing ri documentation for ghost-0.1.2-universal-darwin-9...
Installing RDoc documentation for ghost-0.1.2-universal-darwin-9...

Okay, now that Ghost is installed, let’s see what we can do with it.

Using Ghost for local domains/subdomains

Ghost is fairly straight forward. It’s essentially a friendly wrapper for dscl, which is the Directory Service command line utility for Mac OS X. I’ve never played with that directly, but it seems that with Ghost… I shouldn’t need to. :-)

With Ghost, you can add, modify, and delete entries in the Directory Service by issuing any of the following commands. Let’s start out by running ghost to see what we have here.


 ~ : ghost
USAGE: ghost add <hostname> [<ip=127.0.1.1>]
       ghost modify <hostname> <ip>
       ghost delete <hostname>
       ghost list
       ghost empty

Okay, let’s see if there is anything already listed.


   ~ : ghost list
  Listing 0 host(s):

Nope. Let’s test this out. First, we’ll try to ping a domain name that we hope doesn’t exist.


   ~ : ping bigbrown.cow
  ping: cannot resolve bigbrown.cow: Unknown host

Alright, now we’ll add bigbrown.cow with ghost.


   ~ : ghost add bigbrown.cow
  Password:
    [Adding] bigbrown.cow -> 127.0.0.1

As you can see, it required root credentials to do this as it’s system-wide. Let’s now see if we can talk to bigbrown.cow.


   ~ : ping bigbrown.cow     
  PING bigbrown.cow (127.0.0.1): 56 data bytes
  64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.047 ms
  64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.035 ms
  ^C
  --- bigbrown.cow ping statistics ---
  2 packets transmitted, 2 packets received, 0% packet loss
  round-trip min/avg/max/stddev = 0.035/0.041/0.047/0.006 ms

Excellent! If we run ghost list again, we should see this record.


~ : ghost list
Listing 1 host(s):
  bigbrown.cow -> 127.0.0.1

We can modify the record to a non-localhost IP as well with ghost modify.


   ~ : ghost modify bigbrown.cow 192.168.10.104
    [Modifying] bigbrown.cow -> 192.168.10.104
   ~ : ghost list
  Listing 1 host(s):
    bigbrown.cow -> 192.168.10.104

I’ll let you play with it yourself as there isn’t much to it. This is a great little addition to my development environment. Thanks to Nathan for pointing it out and to Bodaniel Jeanes for creating this useful gem.

Subdomain accounts with Ruby on Rails explained

Robby Russell — Sun, 11 Jan 2009 17:30:00 -0600

DHH recently posted, How to do Basecamp-style subdomains in Rails on SvN and it just happens that I was implementing some similar stuff this last week for a project we’re developing internally.

In our project, not everything needs to be scoped per-account as we are building a namespace for administrators of the application and also want a promotional site for the product. Three different interfaces, with some overlap between them all.

Let’s walk through a few quick steps that you can follow to setup the two interfaces within the same application.

Suppose that we’re going to build a new web-based product and have the following requirements initially.

We need a promotional site for sign-ups, frequently-asked-questions, support requests, etc.
When people sign-up for an account, they’ll should have their own unique sub-domain
There are two different visual layouts (promotional site and the account)

Note: I use RSpec and am going to skip the TDD process here and let you conquer that for yourself. Am using the default Rails commands in this tutorial.

Account model / Database

We’re going to generate a new model for Account, which will be responsible for scoping sub-domains and individual accounts.

  account-demo : ruby script/generate model Account subdomain:string 
       create  app/models/
       create  test/unit/
       create  test/fixtures/
       create  app/models/account.rb
       create  test/unit/account_test.rb
       create  test/fixtures/accounts.yml
       exists  db/migrate
       create  db/migrate/20090111220627_create_accounts.rb

Great, let’s migrate our application.

   account-demo : rake db:migrate
  ==  CreateAccounts: migrating =================================================
  -- create_table(:accounts)
     -> 0.0045s
  ==  CreateAccounts: migrated (0.0052s) ========================================

Before we get too far, let’s make sure that we’re adding an index on this table for the subdomain, as it’ll improve performance in the database as the subdomain will used in SQL conditions quite often.

account-demo : ruby script/generate migration AddIndexToAccountSubdomain
     exists  db/migrate
     create  db/migrate/20090111221009_add_index_to_account_subdomain.rb

Let’s open up this new migration file and toss in a UNIQUE INDEX on subdomain.

  class AddIndexToAccountSubdomain < ActiveRecord::Migration
    def self.up
      add_index :accounts, :subdomain, :unique => true
    end

    def self.down
      remove_index :accounts, :subdomain
    end
  end

Okay, let’s migrate this bad boy.

   account-demo : rake db:migrate
  ==  AddIndexToAccountSubdomain: migrating =====================================
  -- add_index(:accounts, :subdomain, {:unique=>true})
     -> 0.0047s
  ==  AddIndexToAccountSubdomain: migrated (0.0050s) ============================

Great, we’re now ready to move on to the fun stuff.

Let’s open up app/models/account.rb and throw some sugar in it.

Data Validation

Because we’re going to be dealing with subdomains, we need to make sure that we’re only allowing people to sign-up with valid data otherwise, there could be issues. URLs need to fit within certain conventions and we need to make it as graceful as possible for our customers.

Let’s make a quick list of what we need to enforce for the subdomain attributes. This can easily be expanded, but let’s cover the basics.

Each account should have a subdomain
Each subdomain should be unique within the application
A subdomain should be alpha-numeric with no characters or spaces with the exception of a dash (my requirement)
A subdomain should be stored as lowercase

So, let’s update the following default Account model….

  class Account < ActiveRecord::Base
  end

..and add some basic validations.

  class Account < ActiveRecord::Base
    validates_presence_of :subdomain
    validates_format_of :subdomain, :with => /^[A-Za-z0-9-]+$/, :message => 'The subdomain can only contain alphanumeric characters and dashes.', :allow_blank => true
    validates_uniqueness_of :subdomain, :case_sensitive => false

    before_validation :downcase_subdomain

    protected

      def downcase_subdomain
        self.subdomain.downcase! if attribute_present?("subdomain")
      end
  end

Reserved subdomains

In the project that our team is working on, we wanted to reserve several subdomains so that we could use them later on. We tossed in the following validation as well.

  validates_exclusion_of :subdomain, :in => %w( support blog www billing help api ), :message => "The subdomain <strong>{{value}}</strong> is reserved and unavailable."

This will prevent people from using those when they sign up.

Controller / Handling Requests

Let’s now think about how we’ll handle requests so that we can scope the application to the current account when a subdomain is being referenced in the URL.

For example, let’s say that our application is going to be: http://purplecowapp.com/ [1]

Customers will get to sign-up and reserve http://customer-name.purplecowapp.com/. I want my account subdomain to be green.purplecowapp.com and everything under this subdomain should be related to my instance of the application.

I’ve begun working on my own module, which is inspired mostly by the account_location plugin with some additions to meet some of our product’s requirements.

Here is my attempt to simplify it for you (removed some other project-specific references) and have put this into a Gist for you.

  #
  # Inspired by
  # http://dev.rubyonrails.org/svn/rails/plugins/account_location/lib/account_location.rb
  #
  module SubdomainAccounts
    def self.included( controller )
      controller.helper_method(:account_domain, :account_subdomain, :account_url, :current_account, :default_account_subdomain, :default_account_url)
    end

    protected

      # TODO: need to handle www as well
      def default_account_subdomain
        ''
      end

      def account_url( account_subdomain = default_account_subdomain, use_ssl = request.ssl? )
        http_protocol(use_ssl) + account_host(account_subdomain)
      end

      def account_host( subdomain )
        account_host = ''
        account_host << subdomain + '.'
        account_host << account_domain
      end

      def account_domain
        account_domain = ''
        account_domain << request.domain + request.port_string
      end

      def account_subdomain
        request.subdomains.first || ''
      end

      def default_account_url( use_ssl = request.ssl? )
        http_protocol(use_ssl) + account_domain
      end

      def current_account
        Account.find_by_subdomain(account_subdomain)
      end

      def http_protocol( use_ssl = request.ssl? )
        (use_ssl ? "https://" : "http://")
      end
  end

View gist here (embed wasn’t working right when I tried)

Just include this into your lib/ directory and require it in config/environment.rb. (if people think it’s worth moving into a plugin, I could do that)

Including AccountSubdomains

In the main application controller (app/controllers/application.rb), just include this submodule.

  class ApplicationController < ActionController::Base
    include SubdomainAccounts

    ...
  end

Now, we’ll want to add a check to verify that the requested subdomain is a valid account. (our code also checks for status on paid memberships, etc… but I’ll just show a basic version without that)

Let’s add in the following to app/controllers/application.rb. This will only check on the status of the account (via subdomain) if the current subdomain is not the default. For example: purplecowapp.com is just our promotion site, so we won’t look up the account status and/or worry about the subdomain. Otherwise, we’ll check on the status.

  before_filter :check_account_status

  protected
    def check_account_status
      unless account_subdomain == default_account_subdomain
        # TODO: this is where we could check to see if the account is active as well (paid, etc...)
        redirect_to default_account_url if current_account.nil? 
      end
    end

Current Account meets Project model

When requests are made to an account’s subdomain, we want to be able to scope our controller actions.

WARNING: I’m going to gloss over the following steps because this is just standard Rails development stuff and I want to focus on how to scope your Rails code to account subdomains.

I’ll just say that this product gives each account many projects to do stuff within. I’ll assume that you’ll know how to handle all that and we’ll assume you have a Project model already.

What you will need is to add a foreign key to your table (projects in this example) that references Account. So, make sure that your model has an account_id attribute with and that the database table column has an INDEX.

We’ll add our associations in the models so that they can reference each other.

  # app/models/account.rb
  class Account < ActiveRecord::Base
    has_many :projects
    # ...
  end

  # app/models/project.rb
  class Project < ActiveRecord::Base
    belongs_to :account
    # ...
  end

Okay great… back to our controllers. The SubdomainAccounts module provides you with the current_account variable, which you can use within your controllers/views. This allows us to do the following in our controllers. For example, if we had a ProjectsController.

  class ProjectsController < ApplicationController
    def index
      @projects = current_account.projects.find(:all)
    end

    def new
      @project = current_account.projects.new
    end 

    def show
      @project = current_account.projects.find(params[:id])
    end

    # ...
  end

See, this wasn’t so hard, was it?

Handling layouts

I wanted to highlight one other thing here because I suspect that most projects that fit this will likely need a promotional/resource site where people will sign-up from. In our application, we have two application layouts. One for the main application that customers will interact with via their subdomain and the promotional site layout.

The default layout is just app/views/layouts/application.html.erb and we have our promotional site layout at app/views/layouts/promo_site.html.erb. A few of our controllers are specifically for the promotional site while the rest are for the application itself and in some cases, there is some overlap down to individual action within a controller.

What we did was add a few more before filters to our application controller to a) define the proper layout to render, and b) skip login_required on the promo site.

To have the proper layout get rendered, we’re just checking whether the current request was made to the promotional site or not.

class ApplicationController < ActionController::Base
  # ...
  layout :current_layout_name # sets the proper layout, for promo_site or application

protected

  def promo_site?
    account_subdomain == default_account_subdomain
  end

  def current_layout_name
    promo_site? ? 'promo_site' : 'application'
  end

  # ...
end

Our application is using Restful Authentication and we just want to check to see if the current request is made to the promotional site or not. If it is, we’ll skip the login_required filter. Let’s assume that you have the following before_filter set.

class ApplicationController < ActionController::Base
  # ...
  before_filter :login_required

We’ll just change this to:

class ApplicationController < ActionController::Base
  # ..
  before_filter :check_if_login_is_required 

  protected
    def promo_site?
      account_subdomain == default_account_subdomain
    end

    def current_layout_name
      promo_site? ? 'promo_site' : 'application'
    end    

    def check_if_login_is_required
      login_required unless promo_site?
    end

    # ...

There we go. We can now render the proper layout given the request and only handle authentication when necessary.

Development with account subdomains

When you begin developing an application like this, you need to move beyond using http://locahost:3000 as we need to be able to develop and test with subdomains. You can open up your /etc/hosts (within a Unix-based O/S) file and add the following.


127.0.0.1 purplecowapp.dev
127.0.0.1 green.purplecowapp.dev
127.0.0.1 sample.purplecowapp.dev
127.0.0.1 planetargon.purplecowapp.dev
127.0.0.1 lollipops.purplecowapp.dev
127.0.0.1 help.purplecowapp.dev
127.0.0.1 support.purplecowapp.dev

After you edit that file (with root permissions), you can flush your dns cache with dscacheutil -flushcache (Mac OS X). This will let you make requests to http://purplecowapp.dev:3000/ and http://green.purplecowapp.dev:3000. This is a convention that our team has begun using for our own projects (TLD ending in .dev). It’s important to remember that the subdomain must be specified here in order to work for local requests. Unfortunately, hosts files don’t support wildcards (’*’).

Update

You can also use Ghost, which is a gem for managing DNS entries locally with Mac OS X. Read Get to know a gem: Ghost

Summary

I know that I glossed over some sections, but was hoping that the code itself would be the most beneficial for you. Feel free to leave any questions and/or provide some feedback on our approach. Perhaps you have some suggestions that I could incorporate into this so that we can improve on this pattern.

¹ yeah, I’ve been reading more Seth Godin recently…

Rails and Business in the 2009 World

Robby Russell — Sat, 10 Jan 2009 21:11:00 -0600

The past few months have been difficult for many companies and as a result, some have had layoffs and now there are developers out there looking for new opportunities. I’ve received a few emails from friends and acquaintances in the Ruby on Rails community from people who are hoping to make it as a freelancer until another opportunity comes along. Questions ranging from hourly rates to managing clients has come up. I’m more than happy to offer people advice on this front but always try to invite them to solicit ideas and feedback from a larger group of people. We just happen to have an open forum for all of you that are interested in discussing business-related topics.

Two years ago, I started the Ruby on Rails meets the business world group on Google, which currently consists of nearly 900 members.

So, if you’re an entrepreneur and looking to engage with other business owners, freelancers, or to just listen in on the discussions out of curiosity, don’t hesitate to join the group. There are several of us that would love to share our experiences/lessons with you and also learn from others.

I’d invite you all to check out the discussion archives and start a dialogue with us.

...and as always, if you’re not ready for a bigger group, feel free to drop me a line personally.

Rails 3 and Merb

Robby Russell — Tue, 23 Dec 2008 16:55:00 -0600

So… Rails and Merb are going to be merged into Rails 3. (link)

Has hell frozen over?

(it has in Portland the last week)

I’m curious about how the revised core team will incorporate the library-agnostic view points into Rails without increasing the complexity for configuration. For example, being able to use a different ORM is great, but at the same time, one of the things that I have really liked about Ruby on Rails was that it did make decisions ahead of time for you. Conventions over Configuration and all that jazz. While they intend to keep these defaults, I really wonder how much more configuration will be involved. Be that as it may, Rails and Merb are run by some of the best developers I’ve ever known… so I am sure these decisions will not be made without some deep consideration.

Rails application don’t all look and smell the same, but it’s nice to know that there is consistency across all of our client applications. What I’m concerned about (from an efficiency standpoint) is that this could lead to project-diversity at the cost of experimenting. Pre-Rails, the development teams that I was a part of was constantly trying out new libraries from client project to project, but this came at a huge cost. We weren’t able to leverage our experience with previous projects like our team does with Ruby on Rails currently. (hell, I even helped write two different ORMs in the two years before Rails for PHP… and still wasn’t satisfied)

But, this isn’t so much a technical problem as much as a people problem. The thing is… is that Rails helped solve a people problem with a technical answer. Having testing, consistency, and other best practices built-in did the world a huge favor. ...and all it took was someone like DHH to throw his opinion out there and stick to it. It took me nearly a full year to really embrace a lot of these conventions, but in the end.. it paid off.

While I do feel that it’s in developers best interests to try out new approaches, I just don’t think it should be on your clients dime. This was part of the reason why I quit my last job to start Planet Argon full-time. I really wanted to get away from that cycle.

Since we (Planet Argon) adopted Ruby on Rails four years ago, we’ve been able to build off of every project we had worked on before. We since adopted things like RSpec and JQuery, but our team decided on these changes after someone took the initiative to experiment with these on internal and personal projects. Having this foundation has freed up a lot of our time to focus on other issues as a team, like Interaction Design, Usability, and client collaboration.

As far as Merb itself, I honestly haven’t tried to do anything with it since about 0.2/0.3. I gave up quickly though because the documentation didn’t help me get anywhere and my time is valuable. I’ve since seen that documentation has improved drastically, but I haven’t been able to prioritize the time needed to really play with it. With Merb being merged into Rails 3, it means that I really should spend more time exploring it as we might be able to leverage some of it’s benefits without as much of an investment.

Much of the lack of great interest in Merb was because I felt Rails had consistently provided our team with a solid foundation for a majority of our internal and client applications. The old saying, “if it ain’t broke, don’t fix it.” Not to say that others haven’t expressed a lot of excitement about Merb and it’s benefits, I just didn’t see there being enough of a productivity gain to warrant the time investment required to really learn and use a new framework… and the one thing that I have had trouble with was that it didn’t sound like Merb encouraged a default set of libraries. I could be totally wrong, but that’s been the perception I’ve had based on how it was branded.

But… the best part about this for you, me, and the Rails community? Is that I don’t need to register robbyonmerb.com anytime soon. ;-)

I hope that you’re all having a great end to 2008 and am excited to see all the energy in the Ruby/Rails/Merb community. I suspect that between these two (now-merged) teams, we’ll have an even better platform to develop web applications on. I believe this is great news and I’m all in favor of seeing the Ruby community conquer these challenges that lay ahead.

Anyhow, I’m just thinking out loud. What are your thoughts?

RailsBoxcar.com 2.0

Robby Russell — Wed, 17 Dec 2008 23:55:00 -0600

In case you missed the tweet from Alex ...

Our team just designed, developed, and deployed a new site for, Boxcar, our streamlined deployment environment for Ruby on Rails applications.

Feel free to take a tour to learn more about our product plans, which currently start as low as $59/month.

If you have a project that you’ll be launching in the coming months, get in touch with us. :-)

Launching Ruby on Rails projects, a checklist

Robby Russell — Sun, 14 Dec 2008 19:28:00 -0600

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:

Get your Capistrano or Vlad deployment tasks setup early. Make sure everything works and set it up to work with multiple deployment environments. (staging, production, etc.)
- Use Boxcar Conductor with your Rails Boxcar. (Boxcar Conductor on github)
Use the HTTP Basic Authentication, which is available in Ruby on 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
- Watch a Railscast for using HTTP Basic Authentication: watch screencast
Get your automated tasks (cron jobs) setup way before launch. Verify 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
Make sure your hosting provider has monitoring setup. It’s good to gauge uptime % from launch
- Extra-credit: Setup your own monitoring with Pingdom or similar service to make sure you know when things are down. (You can audit your hosting provider this way!)

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 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 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 starting gate
- Conversion goals for obvious things like: sign-ups/registrations, viewing your product tour, contact requests, etc.

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 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! (otherwise, you’ll never know about these problems…eek!)

However, in the last year, the Rails community has seen two options, Exceptional and Hoptoad introduced for managing exceptions. Our team has only used Exceptional so far, because our good friends at Contrast 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:

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

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?

AlphaClone on PostgreSQL and Ruby on Rails

Robby Russell — Fri, 12 Dec 2008 08:23:00 -0600

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!

Interviewed by Database Radio Podcast

Robby Russell — Thu, 11 Dec 2008 11:46:00 -0600

Bob Zurek, the Chief Technology Officer at EnterpriseDB interviewed me a few months ago for their new Database Radio podcast. It finally was published last week. Bob and I had a nice conversation about PostgreSQL and it’s community, our use of PostgreSQL with Ruby, Ruby on Rails, and development tools/methods.

You can listen to the podcast mp3 and/or read the transcript.

The new RubyURL API

Robby Russell — Sun, 31 Aug 2008 13:55:00 -0500

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…


$ curl  -i \ 
        -X POST \
        -H 'Content-Type: application/xml' \
        -d '<link><website_url>http://github.com/robbyrussell</website_url></link>' \
        http://rubyurl.com/api/links  


	...would return the following response.




	I’ll be updating the ShortURL gem in the coming days (unless someone else wants to patch it first wink) to take advantage of new API, versus how it’s currently creating RubyURLs.


	You can see the code & changes for this new API on the RubyURL github site.


	Update with JSON


	I took a little time today to update the API and extend it to support JSON. So… you can now use the RubyURL API to generate RubyURLs via JSON. (see commits)




	Enjoy! If you’re using RubyURL via the new API, I’d love to hear about it. :-)



Flash Message Conductor
Robby Russell — Fri, 29 Aug 2008 16:35:00 -0500
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."

	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." )
add_notice( "You've Got Mail!" )
add_error( "Oops! Something got fucked up!" )

	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 %>

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


<div id="flash_messages">
  <p class="message">You have successfully done XYZ...</p>
</div>

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


<div id="flash_messages">
  <p class="error">Oops! Something went bonkers!</p>
</div>

	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:



script/plugin install git://github.com/planetargon/flash-message-conductor.git


	Then all of our helper methods will be available to your application. We’ve also included an example CSS file, which you’ll find in the plugin directory.


	Sample output:



Uploaded with plasq’s Skitch!

	Anyhow, we’ve posted the plugin up on GitHub for you all to use, if you’d like to adopt a similar approach. If you have any alternative patterns that has helped your team, do share and I’m looking forward to sharing some more of ours in the near future.


	For more information, visit the Flash Message Conductor plugin on GitHub.


	If anything, hopefully this will inspire those of you who find yourself copying/pasting artifacts from application-to-application to extract that code into it’s own reusable plugin. :-)


RSpec: It Should Behave Like
Robby Russell — Tue, 19 Aug 2008 21:47:00 -0500
I was going through an older project of ours and cleaning up some specs and noticed how often we were doing the same thing in several places. When we started the project, we didn’t get the benefits of shared groups. Now that we have some time to go through and update some of our older specs, I’ve been trying to take advantage of the features currently available in RSpec. One feature that I haven’t seen a lot of mention of by people is shared groups, so I thought I’d take a few minutes to write up a quick intro to using it.


	To pick some low-hanging fruit, let’s take an all-too-familiar method, which you might be familiar with… login_required. Sound familiar? Have you found yourself stubbing login_required over and over throughout your specs?


describe Admin::DohickiesController, 'index' do

  before( :each ) do
    controller.stub!( :login_required )
    Dohicky.should_receive( :paginate ).and_return( Array.new )
    get :index
  end

 ...
end

	If you’re requiring that a user should be logged in when interacting with most of the application (as in the case of an administration section/namespace), you might want to consolidate some of your work into one shared specification group. The basic premise behind this is that you can write a typical describe block and load it into any other spec groups that you need. For example, in our case, we’ll need to stub login_required in several places. We can set this up in one shared group and reference it wherever necessary.


	For example, here is what we’ll start off with.


describe "an admin user is signed in" do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

describe Admin::DohickiesController, 'index' do
  ...

	However, the new describe block isn’t accessible from the block at the bottom of the example… yet. To do this, we just need to pass the option: :shared => true as you’ll see in the following example.


describe "an admin user is signed in", :shared => true do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

	Great, now we can reference it by referring to it with: it_should_behave_like SharedGroupName. In our example above, this would look like:


describe "an admin user is signed in" do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

describe Admin::DohickiesController, 'index' do
  it_should_behave_like "an admin user is signed in"

  before( :each ) do
    Dohicky.should_receive( :paginate ).and_return( Array.new )
    get :index
  end

 ...
end

describe Admin::DohickiesController, 'new' do
  it_should_behave_like "an admin user is signed in"

  before( :each ) do
    @dohicky = mock_model( Dohicky )
    Dohicky.should_receive( :new ).and_return( @dohicky )
    get :new
  end

  ...

	That’s it! Pretty simple, eh? We can now reference this shared group in any describe blocks that we want to. A benefit to this approach is that we can make change the authentication system (say, we decide to switch it entirely and/or even just change method names, set any other prerequisites necessary when an admin is signed in), we’ll have a single place to change in our specs. (tip: you can put these in your spec_helper file)


	You can learn more about it_should_behave_like and other helpful features on the RSpec documentation site.


	If you have any suggestions on better ways of handling things like this, please follow up and share your solutions. I’m always looking to sharpen my tools. :-)


	Update


	In response, Bryan Helmkamp suggests that a better solution is to define a method in our specs like, for example: build_mock_user_and_login. then calling it in our before(:each). So, maybe the approach above isn’t the most ideal method but I did wantt o draw some attention to it_should_behave_like. I suppose that I need a better example.. another post, perhaps? :-)


	Also, Ed Spencer has posted an article titled, DRYing up your CRUD controller RSpecs, which will introduce you mor to it_should_behave_like.


	Thanks for feedback people!


	Related Posts


	
	Be Careful that you don’t Stub your Big Toe
		Spec Your Views
	


Expanding Rails Boxcar packages
Robby Russell — Mon, 04 Aug 2008 09:30:00 -0500
If you’re in the market for a new hosting provider for your Ruby on Rails application, you might take a look at the new options for Rails Boxcar. We recently expanded our service offerings into three pricing tiers as well as custom packages for those who need a bit more.


	


	A few things that we’ve recently added support for:


	
	Provide us your SSH key during sign up!
	
	Allows us to keep your server even more secure by avoiding sending passwords over the net
		Other fun features related to this coming soon
	
	
		Auto-configured Nginx w/Mongrel cluster
		Phusion Passenger (mod_rails) support! (for those with mixed-environments)
		Continued development of Boxcar Conductor)
		...more in the works!
	


	The best part is that we can get you up and running with a new Boxcar now for as low as $59/month USD.


	For more information, visit: http://railsboxcar.com


	If you have any questions, don’t hesitate to contact us.


Ruby 1.8.7 on MacPorts causing some problems
Robby Russell — Fri, 20 Jun 2008 16:11:00 -0500
It appears that MacPorts has upgraded to Ruby 1.8.7, which is good news if you’re running Rails 2.1… but if you have an older Rails application… it’s not going to work too well.


	In order to get Ruby 1.8.6 installed with the latest MacPorts, you’ll need to do the following.



  $ mkdir /Users/Shared/dports



$ svn checkout -r 36429 \ 
    http://svn.macports.org/repository/macports/trunk/dports/lang/ruby/ \ 
    /Users/Shared/dports/lang/ruby/


	Then you’ll need to modify your macports to use this new local source. You’ll need to edit /opt/local/etc/macports/sources.conf  and add the following line above the existing rsync record.


	file:///Users/Shared/dports and create that directory


	Next, you’ll want to index this new local source with the following command:


	portindex /Users/Shared/dports


	After that, you can do the following.


	sudo port uninstall rb-rubygems ruby


	sudo port clean rb-rubygems ruby


	sudo rm -r /opt/local/lib/ruby/gems/1.8/doc/rubygems-1.1.1/


	sudo port deactivate autoconf


	sudo port install ruby rb-rubygems


	..and hopefully you’ll have Ruby 1.8.6 installed and be able to retain the rubygems you installed already.


New Boxcar plans announced!
Robby Russell — Fri, 30 May 2008 14:30:00 -0500
Yesterday we announced our new suite of plans for Rails Boxcar. You can now get started with a pre-configured VPS designed by Rails developers like you for as low as $59/month.


	You can check out our new rates here:


	
	http://railsboxcar.com
	


	If you’re at RailsConf, be sure to introduce yourself and ask for details. :-)


Meet us at RailsConf
Robby Russell — Wed, 28 May 2008 08:46:00 -0500
If you’re coming to Portland for RailsConf or CabooseConf, be sure to introduce yourself (and we’ll try to do the same). A few of us from Planet Argon will be attending the conference. I thought that I’d make it easy to spot us by putting some faces to our names.


	In corner #1 we have Alex Malinovich who is our Director of Deployment Services. If you have any questions about hosting options, deployment tips, and scaling your Ruby on Rails application.. be sure to tug on his shoulder. I also overheard that he’ll be giving people discounts on our Boxcar products to those he meets in person.


	
Alex Malinovich, Director of Deployment Services


	In corner #2, we have Andy Delcambre who is on our development team. You might remember Andy from his series of blog posts/tutorials on using Git and getting Basecamp RSS feeds working in Google Reader via a Mongrel-based proxy (our team is still using this approach using this after ten months!).


	
Andy Delcambre, Software Developer


	In corner #3, we have Gary Blessington who has been leading our design and development team. If you’re looking for a job working with Ruby on Rails, be sure to introduce yourself to Gary as he’s hoping to meet up with several applicants who will be in Portland this week.


	
Gary Blessington, Director of Design and Development


	In corner #4… is me. I’m not doing any talks this year so I plan to do wander around stress-free as I’m not finishing my slides at the last minute or preparing for panel talks. I’m happy to field questions and exchange stories with you. :-)


	
Robby Russell


	We are hiring... so feel free to introduce yourself to any of the faces above.


	...and most importantly, I hope you have a great time in Portland!


Boxcar Conductor plugin moved
Robby Russell — Fri, 23 May 2008 04:23:00 -0500
Update. We’ve moved the Boxcar Conductor plugin for deploying Ruby on Rails applications to a new location on GitHub.


	
	http://github.com/planetargon/boxcar-conductor
	


	You can still submit bugs/feature requests on Lighthouse here:


	
	Boxcar on Lighthouse
	


	Enjoy!

Robby on Rails: Category Ruby on Rails

Planet Argon is hiring

Announcing RailsDeveloper

Installing Ruby on Rails, Passenger, PostgreSQL, MySQL, Oh My Zsh on Snow Leopard, Fourth Edition

Phase One

XCode

MacPorts

Wget

Git and Subversion

oh-my-zsh

Terminal theme (optional)

Phase Two

Ruby 1.8.7.x

Passenger (mod_rails)

Passenger Pref Pane

Development directory

Installing Ruby on Rails via RubyGems

Test Rails and Passenger

Phase Three

PostgreSQL

Setup database user

MySQL

Phase Four, next steps

Closing thoughts…

RubyURL goes GOP...

Sending email: Controllers versus Models

Launching Ruby on Rails projects, the video

Related Posts

Tracking Google Analytics events in development environment with GoogleAnalyticsProxy

Get GoogleAnalyticsProxy

Planet Argon Podcast, Episode 2: The Letter Scotch

Planet Argon Podcast, Episode 1: Shin Splints

RailsOnPg released

Tracking AJAX-driven events in Ruby on Rails for Google Analytics conversion goals

The 8-Hour Rails Code Audit

Related Posts

Flash Message Conductor now a Gem

Planting the seeds

Populating Seed Data Approaches

Basic example

Use the names of real people

Use Faker for Fake data

Your ideas?

So long and thanks for all the hoodwinks

Related Posts

Ch-ch-ch-changes at Planet Argon

Slides from my Rails Underground 2009 talk

Launching Rails projects, an open call for lessons learned

Using model constants for project sanity

Model Constants

Aliasing resources in Ruby on Rails

Speaking at Rails Underground 2009

Howdy Rip!

Hello, HeyBrainstormr.com

82,520 minutes on Phusion Passenger

20 articles on Cucumber and a free beverage recipe!

What is Cucumber?

FREE RECIPE: Cucumber Water

Related Posts (by me)

HTTParty goes foreign

The Rails Hosting Survey 2009 Survey results are in!

Show me your and I'll show you mine (terminal prompts with git branches)

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

Installing Passenger via RubyGems

Setting up Preference Pane

Things to still figure out…

Rolling out new updates for Rails Boxcar

Rails Hosting Survey - 5 days left...

Rails Hosting Survey (continued)

Question: Plugins or Gems? (or both?)

Take the Ruby on Rails Hosting in 2009 Survey

Get to know a gem: Ghost

Installing Ghost

Using Ghost for local domains/subdomains

Subdomain accounts with Ruby on Rails explained

Account model / Database

Data Validation

Reserved subdomains

Controller / Handling Requests

Including AccountSubdomains