Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Rails 1.2 On

Posted by Sun, 28 Jan 2007 18:58:00 GMT

I was recently asked a few questions by Stacy Cowley, a writer for CRN about the Rails 1.2 release and how our Design and Development team at PLANET ARGON is adopting it. This Q&A session resulted in a brief article titled, Ruby on Rails Gets RESTFul in Major Update, which appeared on the CRN site last Friday afternoon.

Thanks to the Rails Core team and all of those in the community who continue to help make Ruby on Rails an awesome addition in my tool belt.

Let's not forget the little people

Posted by Wed, 24 Jan 2007 19:27:00 GMT

Yesterday, I announced the new Ruby on Rails Deployment group, which has attracted over 200 people and boasts over 50 messages in just the first 24 hours of it’s life.

While this is a greater turnout than I expected… I made a huge mistake yesterday. I forgot to invite the man behind the cutrain.

14:25 < zedas> robbyonrails: rubyonrails-deployment and i wasn't invited?
14:26 < zedas> i think i need to revoke some licenses. :-)
14:26 < jarkko> sounds robby just lost his mudcrap belt

I forgot to invite… Zed Shaw.


I know that I’ve only met you briefly, but I feel like I’ve known you for years. With each and every mongrel I install, configure, and start… you’re always… right there… with me. This love goes deep.

Please forgive me for not inviting you to the show. I’ve asked the person sitting in the first row to move back a few rows to an empty seat… so you can sit here… right here… with me.

Please accept this letter and invite as an apology.


For everyone else, we have a few seats available near the back of the room, which you can reserve here. ...but before you do, be sure to recommend his work. [1]

1 king of the world

Announcement: New Ruby on Rails Deployment Group

Posted by Tue, 23 Jan 2007 19:52:00 GMT

Our team is working on a new hosting solution1 for Rails applications. Throughout this process, we’ve been reviewing all the various methods that our team and customers have been using to deploy and host applications written with Ruby on Rails. Our team has been able to closely watch the technologies change on our servers for almost two full years to accommodate the latest in deployment solutions.

Recently, a few deployment savvy customers of ours and us decided that it was time to take some of our experiences and conversations out into the public. We’d like to invite all of you that are interested in Rails deployment to join the new Deploying Rails google group. Whether you’re trying to setup a staging server, deploy to a shared solution like we offer at PLANET ARGON, managing your own VPS, or configuring a cluster of servers for your big launch, we’d love to talk with you about this stuff.

I’m secretly hoping that all the talented Rails deployment experts, like our friends at Rails Machine and Engine Yard, will join us in our effort. :-)

If you’re still hosting your Rails application on Apache and FCGI in a shared environment, this list is for you! ;-)

Join the group today!

UPDATE Zed Shaw has entered the building…

1 Stay tuned in early February… ;-)

Every Second Counts with a Piston in your Trunk

Posted by Tue, 16 Jan 2007 06:15:00 GMT

Recently, I wrote about using RSpec and autotest (...which I think should be called autospec) together to help boost productivity while working on Rails projects. It seems that a few members of the PLANET ARGON team have picked up on using it, which I’m happy to hear about. :-)

It’s not the only thing that I’m happy about though.

I recently came across another gem. Several of my comrades in #caboose are using piston to manage external plugins for Ruby on Rails. Wait! Isn’t this what Subversion externals is meant for? Well, yes… but externals also eat away at productivity. For example, each day, we may have anywhere from 4-6 designers and developers working on one client project. When we’re in crunch mode, this could account for quite a few subversion commits throughout the day. We all know that we should run svn up on a regular basis to make sure that we’re keeping things in sync… especially when designers and developers are working really closely and fine tuning something specific in the application. Well, the one downside to this process is that each svn up not only checks our repository, but it also checks external repositories.

“But wait! Can’t you just ignore externals on an update?”

Of course, but who wants to type out --ignore-externals each time they run an update? ...or perhaps you could make an alias for this in your shell. In any event, everyone on the team is then left to be responsible for doing this… and an extra 30-60 seconds (if not longer) per svn update times x number of people on project… well… time wasted if you’re closely watching the svn updates. Also, TextMate doesn’t have an option currently (that I could find) to ignore externals, so for those who manage subversion through it… they’re waiting on externals within their primary workspace.

Another issue with svn externals is that when a repository goes down, it really starts to slow stuff down your updates. This is always fun when you go to deploy your application with Capistrano and realize that you can’t finish the update because it can’t connect it to to make sure that your application has the latest version of the best plugins available for Rails.


Then there is the whole issue of wanting to make changes to the plugin that you’re including as an external. How does that fit into the whole mix?

There is Hope!

Piston encourages you to keep your external plugins in your local repository. Don’t worry, it remembers where it retrieved the code from so that you can update from the external repository at any time.

Installing Piston

Again, this is really simple like most gems.

    $ sudo gem install -y piston
    Successfully installed piston-1.2.1

Great, that’s all that you have to do to get started with Piston. Now, let’s get on with the show.

If you don’t have any existing Subversion externals, feel free to skip this section.

Converting existing externals

Okay, so let’s say that you’re working on a Ruby on Rails project and are relying on several external repsitories. For example, a project that I’m working on… currently looks like this.

    $ svn proplist --verbose vendor/plugins/               
    Properties on 'vendor/plugins': 
      svn:externals : 
    rspec_on_rails                svn://

Piston is smart enough to know how to convert these Subversion externals into Piston-friendly plugins. This can be done by passing the piston command the convert option from within your Rails application directory.

Go ahead and run the following.

    $ piston convert
    Importing '' to vendor/rails (-r 5619)
    Exported r5619 from '' to 'vendor/rails'

    Importing '' to vendor/plugins/authorization (-r 83)
    Exported r83 from '' to 'vendor/plugins/authorization'

    Importing '' to vendor/plugins/svn_tools (-r 119)
    Exported r119 from '' to 'vendor/plugins/svn_tools'

    Importing '' to vendor/plugins/simply_helpful (-r 5700)
    Exported r5700 from '' to 'vendor/plugins/simply_helpful'

    Importing '' to vendor/plugins/exception_notification (-r 3900)
    Exported r3900 from '' to 'vendor/plugins/exception_notification'

    Importing '' to vendor/plugins/asset_field (-r 50)
    Exported r50 from '' to 'vendor/plugins/asset_field'

    Importing 'svn://' to vendor/plugins/rspec_on_rails (-r 1330)
    Exported r1330 from 'svn://' to 'vendor/plugins/rspec_on_rails'

    Importing '' to vendor/plugins/rspec_autotest (-r 48)
    Exported r48 from '' to 'vendor/plugins/rspec_autotest'

    Done converting existing svn:externals to Piston    

All we have to do now is checkin our changes to subversion and we’re golden.

svn ci -m "updating repository to use piston instead of those lame-o externals..."

If you find this interesting and want to learn more, be sure to check out this post on Ruby Inside for a detailed introduction to Piston.


the following morning I saw this come across our development team channel…

< argonbot> svn.commit( project_name, { :author => '', :rev => 83, :log => 'converted svn:externals to piston for product, cus I can.' } 


Meet the Cheat

Posted by Wed, 10 Jan 2007 17:37:00 GMT

Hey! You’re a cheater!

Well, if you’re not… I’m hoping to make one out of you.

“A thing worth having is a thing worth cheating for.”—W. C. Fields

I’m a fan of the PDF cheat sheets as I like the consolidated content contained in them. However, I don’t like having to read PDFs any more than I have to. Printing them isn’t always ideal either as I really don’t like to carry around extra paper in my laptop bag. So, what are we to do?

Well, you can cheat the system! ...and I’m going to show you how!

Cheat is this really nice command-line tool that outputs a plain text cheat sheet whenever and wherever you want.

Install the Cheat

Like all the happy and good Rubygems, this is quite simple…

$ sudo gem install cheat

Done! Okay… let’s try to do some cheating. Don’t worry, your friends and family will forgive you.

Becoming a Cheat(er)

To view a cheat sheet, just run the cheat command from your favorite terminal window.

$ cheat _cheat name_

So, for example… to see the cheat sheet for RSpec, run cheat rspec.

    $ cheat rspec
      $ sudo gem install rspec

      $ ./script/plugin install
      Where X_Y_Z is the version number.

      $ ./script/generate rspec
            create  spec
            create  spec/spec_helper.rb
            create  spec/test2spec.erb
            create  test/test2spec_help.rb
            create  script/rails_spec
            create  script/rails_spec_runner

      HOW TO USE
      ./script/generate rspec_model User

# truncated to save precious bandwidth

Because this is all printing out in your shell, you can take advantage of your favorite command line tools.

Piping to grep

$ cheat rspec | grep 'equal' 
      @user.errors.on(:username).should_equal "is required" 
  target.should_equal <value>
  target.should_not_equal <value>

Piping to TextMate

$ cheat rspec | mate

Find more Cheats

Head over to this list of cheats to see what is currently available.

Thanks to the Err team for putting this together!

The Zen of Auto Rspec

Posted by Wed, 10 Jan 2007 16:08:00 GMT

Several months ago, I heard that people were using a program called autotest to have their tests continue to run as you made changes to your code base, which comes with ZenTest. It’s a really nice tool written by Ryan Davis and I hadn’t gotten a chance to play with it as of yet. Well, our team isn’t spending too much time in the test/ directory these days as we jumped ship near the end of last summer and found ourselves hanging out on the Isle of BDD. The locals are quite thoughtful about these sorts of things.

I just started working on a project that has been under development for several months and as I’m getting to learn the ins/outs of the system, I find myself having to rerun the specs, which can take quite a bit of time watching. Watching your specs or tests run sometimes is as productive as watching your code compile. Oddly enough, this is as close to compilation as we really get when working with Ruby on Rails… and it’s a productivity killer for me.

There Must Be a Better Way!

So, I did a quick google search and found an announcement for Rails that ran specs through ZenTest. This was exactly what I was searching for!

Some requirements

Please makes sure that you have the following gems installed in your development environment as they are dependencies to make this all work.

  • zentest
  • diff-lcs

$ sudo gem install zentest diff-lcs 

note I’m going to assume that you have rspec and rspec for rails installed… if not… tsk. ;-)

Install RSpec autotest

$ script/plugin install

If you’re using subversion, you might consider installing it as an external.

$ script/plugin install -x

Running RSpec autotest

This is where it gets tricky. ;-)

$ rake spec:autotest

Now, you can keep a terminal window open and autotest will watch your application and detect when files change. When they change, it’ll attempt to rerun your specs (specifically those that changed). This helps save you the time of having to rerun all your specs throughout the development process and keep your spec:all sanity checks for when you’re about to commit code to your repository.

I’ll post another entry in the next few days to show you how you can use Growl with RSpec Autotest to keep you from having to look at your terminal all the time.

Until then… have fun!

Older posts: 1 2