Recent Posts - Page 11

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

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

(notice the up-on-this alias)

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:

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

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

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

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

Installing Flash Message Conductor

Like most modern Rails applications, you can install with:

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

Awesome. Things 1.1 for the iPhone was just pushed to the Apple iTunes Store, which means… I can finally sync my Things.app with my iPhone!

I’ve been using Things for quite a while to manage my life (work and personal) and bringing this to my phone definitely makes my day.

For more information about Things, visit the following sites:

• http://culturedcode.com/things/ (Things for OSX)
• Things

(iPhone)

I’ll post a review in the coming days as I get a chance to play with it. Just wanted to share the news. :-)

Alan Cooper, author of About Face, has slides from his presentation at Agile 2008 online.

• The Wisdom of Experience

If anybody knows if there is video of this talk, please let me know. :-)

Here are a few skitches from the slideshow.

::: thumbnail :::

::: thumbnail :::

::: thumbnail :::

::: thumbnail :::

::: thumbnail :::

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.

It’s been quiet because I’ve been busy over the past few months. Projects, vacations, and pair programming with our new developer, Nigel. ;-)

In other news, Chris and I launched http://ohmyscience.org (on twitter) in an effort to get a small one-night micro-project out the door.

::: thumbnail :::

I have a growing list of a few micro-projects that I hope to be helping get developed and launched before the summer is over. Stay tuned!

::: thumbnail :::

I hope that you’re all enjoying your summer!

After noticing a few patch requests on Rubyforge.. I decided that I’d put the ShortURL gem up on GitHub as I spend quite a bit of my time there these days. :-)

• http://github.com/robbyrussell/shorturl/tree

I’ve also thrown up a few lines of code so that you can get the gist of the gem. ;-)

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.

Kudos to the 37signals team for launching what looks like a nice way to get the word out about their products.

I’ve been using Basecamp for three years and it’s been a great tool for collaborating with our clients.

{border=”0” height=”250” width=”300”}

Disclaimer: This is my get-rich-quick scheme for the day.

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

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!