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

The new RubyURL API

Posted by Sun, 31 Aug 2008 17:55:00 GMT

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

Posted by Fri, 29 Aug 2008 20:35:00 GMT

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:

flash message area
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. :-)

Git: Push it! (real good)

Posted by Fri, 29 Aug 2008 17:23:00 GMT

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)

RSpec: It Should Behave Like

Posted by Wed, 20 Aug 2008 01:47:00 GMT

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

Things.app syncs with the iPhone!

Posted by Tue, 19 Aug 2008 03:18:00 GMT

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:

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 @ Agile2008 slides

Posted by Tue, 12 Aug 2008 22:19:00 GMT

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

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

Here are a few skitches from the slideshow.

The Wisdom of Experience
The Wisdom of Experience
The Wisdom of Experience
The Wisdom of Experience
The Wisdom of Experience

Older posts: 1 2