Robby on Rails

In a previous post, I showed how we’ve been working on an interactive deployment process for Rails applications to reduce the time it takes to deploy to a Boxcar.

We began to move our Boxcar deployment recipes into it’s own Rails plugin and just made it available on GitHub.

Introducing Boxcar Conductor

The Boxcar Conductor plugin aims to automate the entire process for deploying to your Boxcar. We’re down to just a few simple commands to run to get your application up and running. While mileage may vary with other hosting providers, we did want to open up this work to the community and centralize our work with the community of Boxcar customers who have helped us build and test these tools.

Install Boxcar Conductor

If you’re running on Edge Rails… you can take advantage of the new support for installing plugins in git repositories.

  $ ./script/plugin install git://github.com/robbyrussell/boxcar-conductor.git

note: If you’re not using edge rails, you can download a tarball and install the plugin manually.

Installing the plugin will add a custom Capfile and config/deploy.rb, which has a few things for you to define based on your Boxcar subscription.

Configure Your Boxcar

Once the plugin is installed, you can run the following task:

  $ cap boxcar:config

This will ask you a few questions about your deployment needs.

• Which database server will you be using? (along with db user/pass info)
• How many mongrels should run in your cluster?

After a few quick multiple choice answers, you’re application is ready to be deployed and you can run an Boxcar-specific deployment task.

  $ cap deploy

We’ve also created a new public project on Lighthouse so that you can submit tickets and ideas to us. With Boxcar, we’re really aiming to remove as many steps from the deployment process that aren’t necessary.

To follow along, visit the project on lighthouse or GitHub.

If you’re interested in learning more about Rails Boxcar, feel free to drop us a line.

Related Posts

• Deploying Rails with an interactive Capistrano recipe to your Boxcar
• Announcing Cobalt and monthly subscriptions for Boxcar

We’ve been designing and developing a new centralized billing platform over the past few months and late last week, we launched it! Along with this new billing platform, we launched another new application, Cobalt, which is a new account management and support tool for our hosting customers.

We’ll be migrating all of our past customers over to this new system in time, but are initially using it for new Boxcar customers.

We’ve been building the new system to use Braintree as our new credit card payment gateway. With this switch, we’re also introducing monthly subscription rates for Boxcar, which means that you can try it out month-to-month now.

Over the next few weeks/months, we’ll be announcing several features to Cobalt that will ease your Rails deployment experience.

I want to thank all those on my team that helped get these new applications up and running.

If you’re looking for professional VPS-based Rails hosting, hop on our train by ordering a Boxcar today for $99/month!

For more information, visit railsboxcar.com or Planet Argon.

Also, be sure to follow Boxcar on twitter.

We’re starting a new project and I’m finding myself adding things to the code base that we’ve done in the past… hence the last few posts. As we’re doing this, I’d like to highlight some of the little things that we do on each project to maintain some consistency and in that process reach out to the community for alternative approaches.

I’m intrigued by the vendor everything concept, but we haven’t yet adopted this on any of our projects (yet).

What we have been doing is to maintain a REQUIRED_GEMS file in the root directory of our Rails application.

For example:

$ cat REQUIRED_GEMS

actionmailer
actionpack
actionwebservice
activerecord
activesupport
cgi_multipart_eof_fix
daemons
fastercsv
fastthread
feedtools
gem_plugin
image_science
mongrel
mongrel_cluster
mysql
rails
rake
RedCloth
Ruby-MemCache
soap4r
uuidtools

Everybody on the team (designers/developers) knows to look here to make sure they have everything installed when beginning to work on the application.

This has worked fairly well from project to project but since we’re starting a new project, I’m curious if anybody has some better ways to approach this. Should we look more seriously at the vendor everything approach or are there any alternative approaches?

I’ve seen this come up a few times in the #rubyonrails IRC channel and figured that I’d post a quick entry for future reference.

Problem: HTML titles

You want to have a clean way to manage the titles on your HTML pages.

  <html>
    <head>
      <title>Robby on Rails &mdash; Article Title Goes Here</title>
    </head>
    <body>
      ...

Possible Solution(s):

Since the <title> tag is usually declared in your layout, you need to be able to dynamically update this information from almost every action in your application.

Here are a few ways that I’ve seen this handled.

1. Use a instance variable, which would have a default value and you could override it in any controller action
2. Use the content_for method to manage it.

Let’s take a few minutes to look at these two approaches.

Instance Variable

With the instance variable, you might end up with something like:

  # app/views/layouts/application.html.erb
  <title>Robby on Rails &mdash; <%= @html_title || 'Default text here...' -%></title>

Then in a controller action…

  # app/controllers/articles_controller.rb
  def show
    # ...
    @html_title = @article.title
  end

So, that’s one way to handle it and is probably a more common way.

The content_for helper method approach

This solution is very similar (and underneath uses an instance variable).

We’ll use the content_for and a little yield action.

  # app/views/layouts/application.html.erb
  <title>Robby on Rails <%= (html_title = yield :html_title) ? html_title : '&mdash; Default text here...' %></title>

Then we’ll create a helper method.

  # app/helpers/application_helper.rb
  def set_html_title(str="")
    unless str.blank?
      content_for :html_title do
       "— #{str} " 
      end
    end
  end  

Now, instead of defining the HTML <title> value in the controllers, we’ll just toss this into our html.erb files as necessary.

  <% set_html_title(@article.name) -%>
  ... rest of view

..and that’s pretty much it.

Which is the better solution?

This is where we’ll not find a lot of consensus amongst people. I’m a fan of the content_for-based approach and defining the title in views rather than in controller actions. I’m an advocate of skinny controllers and while I’m not a big fan of messy views, I believe that there is less overhead in managing this within the View-world.

I’d love to hear your thoughts on this. Perhaps you have a more eloquent for managing things like this? Do share. :-)

This is inspired by a recent post by Seth Godin titled, Things you don’t understand, where he shared a list of things that he probably could understand if he put your mind to it, but doesn’t. I decided to post a list of five (5) things in response within the context of Ruby/Rails.

I’m really interested in various things but am really unable to prioritize them high enough to spend the time to understand them.

• RSpec User Stories
• Using Selenium with RSpec
• JQuery (Graeme speaks highly of it)
• JSSpec (BDD for Javascript)
• Using the Google Charts API with Rails

What about you? What’s your list of things that you’d like to understand more about?

I’m guilty of it. Many of you are likely guilty of it… and I know that several customers of our Rails Code Audit and Review service are guilty of it.

How many times have you realized (after a few months has passed) that your Copyright date/year on your web site was no longer current?

How many of you had the same problem last year? The year before?

Let me share some advice with you all… DRY (a)!

Don’t Repeat Yourself (again)!

This is really a simple problem to fix but when we’re busy tackling bigger problems… little things like this slip by. Don’t worry, you’re not the only one who was reminded by a colleague three months into the year that you forgot to update this.

On client projects, we have a handful of helpers that we drop into the application. We’re starting to extract more of these into plugins and will be releasing those as time permits. It just happened that I found myself looking at yet-another Rails code base this afternoon that was showing 2007 in the footer. An easily forgivable offense.. but if you’re going to go in there and change it (again), take a moment to do the right thing. ;-)

Our solution at Planet Argon on client projects is to create a basic view helper that renders the current year. This allows us to do the following.

  <div id="footer">
    &copy; Copyright <%= current_year -%>. All Rights Reserved.
  </div>

The helper code looks like:

  # add to application_helper.rb
  module ApplicationHelper
    def current_year
      Time.now.strftime('%Y')
    end
  end

Voila. Not rocket science.. is it?

Guess what? I’m getting really tired of adding this to every Rails project that I touch. So, I bottled this little gem into a new Rails plugin that we’ll just add to future projects.

Introducing Year after Year

This is really the smallest plugin that I could put together (and it includes specs!)

What does it provide you?

YearAfterYear will provide you a helper that will render the current year (dynamically)! That’s right… just add the plugin to your Rails application and you too can enjoy New Years 2009 without having to have a deployment ready with a one line change from 2008 to 2009!

To use.. add the following to any view from within Ruby on Rails.

  <%= current_year -%>

Installation

As I’m using git, you’ll need to grab this and put it into vendor/plugins. That’s it!

You can grab it on GitHub!

• http://github.com/robbyrussell/year_after_year/
• Bugs / Feature Requests here

Happy New Years (8+ months early)!

Just a friendly reminder to not forget the small stuff… because your visitors will notice! ;-)

Updates…

I got a few requests for this to also provide a range of years for people who like to do: 2005-2007. So this is now provided as well.

year_range(start_year)

Example:

  <%= year_range(2005) %> # => 2005-2008