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 HTTParty has just begun

Posted by Thu, 27 Nov 2008 00:54:00 GMT

After releasing the new RubyURL API, I decided that it was time to look around at libraries to interact with it. I came across a new Ruby gem from John Nunemaker named, HTTParty, which aims to make it easy to talk to XML and JSON-based web services. Be sure to read John’s announcement of HTTParty.

So, I decided it might be fun to introduce more people to the gem by showing you all how to use it to talk to the new RubyURL API.

Install HTTParty

Before we get started, you’ll need to install the HTTParty gem with the following command:


   ~ : sudo gem install httparty
  Password:
  When you HTTParty, you must party hard!
  Successfully installed httparty-0.1.6
  1 gem installed
  Installing ri documentation for httparty-0.1.6...
  Installing RDoc documentation for httparty-0.1.6...

Great! Now that we’re ready to party hard, let’s build something.

Talking to the RubyURL API

The RubyURL API currently supports both XML and JSON, which are each supported by HTTParty. The great thing about HTTParty is that all you need to do is include it in a class and you’re able to quickly talk to remote services.

In this following example, we’re going to create a new class called Rubyurl.

class Rubyurl
end

What we’ll want to do now is include the HTTParty library. (note: you’ll need to require both rubygems and httparty gems and I’ll skip those lines in following code samples)

class Rubyurl
  include HTTParty
end

The HTTParty provides a few class methods, which we can use to configure our library. We’ll go ahead and specify the base_uri, which we’ll set to rubyurl.com.

class Rubyurl
  include HTTParty
  base_uri 'rubyurl.com'
end

Now that our class is setup to talk to the Rubyurl.com site, we’ll want to add a new method which we can use to communicate with the RubyURL API. We’ll call this shorten as we’re using RubyURL to shorten long URLs… right?

class Rubyurl
  include HTTParty
  base_uri 'localhost:3000'

  def self.shorten( website_url )
  end
end

Our new shorten method will expect us to provide it with a website url, which we’ll want RubyURL to return a shortened URL for. The PATH for the API that we’ll want to talk to is: /api/links, which we’re expected to pass XML or JSON to.

Here are two examples of using the RubyURL API with HTTParty.

RubyURL via JSON w/HTTParty

We’re going to use the post method that is provided with HTTParty to send a request to /api/links.json. As you can see, we’re providing the original website url to the web service.

class Rubyurl
  include HTTParty
  base_uri 'rubyurl.com'

  def self.shorten( website_url )
    post( '/api/links.json', :query => { :link => { :website_url => website_url } } )
  end
end

When ran, it’ll produce the following:

  >> Rubyurl.shorten( 'http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb' ).inspect
  => {"link"=>{"permalink"=>"http://rubyurl.com/uJVu", "website_url"=>"http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb"}}

Pretty simple, eh?

RubyURL via XML w/HTTParty

The great thing about HTTParty is that you can use XML without changing much.

class Rubyurl
  include HTTParty
  base_uri 'rubyurl.com'

  def self.shorten( website_url )
    post( '/api/links.xml', :query => { :link => { :website_url => website_url } } )
  end
end

Produces the following

<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<link>
  <website_url>http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb</website_url>
  <permalink>http://rubyurl.com/uJVu</permalink>
</link>

Closing thoughts

So… there you have it. HTTParty makes it extremely easy to interact with various web services that work over HTTP. I’d encourage you all to take a few minutes to experiment with it and see what crazy ideas that come to mind during the process. :-)

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

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

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

The Art of Delivery, part 2

Posted by Thu, 22 May 2008 17:42:00 GMT

Two years ago, I wrote an article titled, The Art of Delivery. I wanted to post a few updates based on how our process has evolved since then (and continues to).

Over the past few years, we’ve been fortunate enough to work on quite a diverse collection of projects. This has enabled us to work with many different clients and solicit feedback on our process. This has given us an opportunity to evolve a set of best practices that fulfills the long-term project goals/budgets of our client while making sure that we’re able to maintain a design and development process that is agile.

As I’ve mentioned in previous posts, our team typically bills work per-iteration on projects rather than per-hour or a flat-bid per-project. Since iterations are bite-sized pieces of the entire project and limited to 1-2 weeks, our teams estimates are much more accurate and we’re able to keep things rolling and on track.

stay on track

The basic structure of our project looks like this.

  • A Project has many releases
  • A Release has many iterations
  • An Iteration has many deliverables
  • A Deliverable has many tasks

Before we begin working on an iteration, we outline a set of goals that we want to create solutions for. This process comes out of discussions between our client and us until we agree on what is the highest value/most critical to the success of the project, based on our shared understanding of where we are today. These goals translate into Deliverables, which in a typical iteration might require Interaction Design, Interface Design, or Development. We tend to break our process up into stages so that Interaction Design on Module XYZ would be implemented in a following iteration. This is because it’s unrealistic to expect someone to provide an accurate estimate on how long it’ll take to implement something before you know how people will interact with it.

Within any given iteration, our team is spread across several sets of deliverables. As a team, we breakdown these deliverables into smaller sets of tasks. It’s our aim to keep tasks smaller than a full days worth of work as it’s much easier to measure progress across the iteration when we can track tasks at a granular level.

Essentially, tasks are the individual steps needed to achieve these goals. We don’t go out of our way to list each one of those during an estimate process as some tasks take less time than it takes to generate an estimate for them. Each person providing estimates should avoid getting too granular and aim to find a good balance that compliments their workflow.

Like most things… mileage may vary.

Through this process, we can get calculate the estimated costs for each deliverable, which then provides us an cost for the entire iteration. In addition to deliverables, we also budget a set of hours/days so that we can be compensated for handling small requests, bug fixes, and project management. It’s important to factor these things into your process.

In future posts, I’ll discuss how we’re handling this process while working on multiple projects… as that’s where it can chaos can start if you’re not careful. ;-)

oops

How does your team work? As we’re always evolving our process in an effort so that we can be more efficient and speed up our delivery cycle, I’d love to learn from those in the community.

Older posts: 1 ... 3 4 5 6 7 ... 13