Empty Thoughts

A few weeks ago I stumbled across Heroku, an online IDE for instant Rails development. It provides editing, sharing, and collaborating of projects, as well as the ability to import and export projects.

Heroku is an amazing implementation of technology and innovative in so many ways. Even if you’re not a Rails developer you will appreciate the beauty of Heroku.

Hmm, what would it take to get something like this for Django?

After reading Zed A. Shaw’s rant, Rails Is A Ghetto, I was a bit surprised. I’ve met Zed on a couple of occasions and each time he was always pleasant and kind.

As a result I decided I would dig further into Mr. Shaw’s background and surprisingly I discovered this letter.

It’s amazing how much things have stayed the same. :)

Fabio Akita (not the Fabio) has an excellent interview with Adrian Holovaty, creator of the Django Framework.

I’ve been following Akita’s work for some time and I’ve enjoyed it immensely. Recently he reproduced the original Rails screencast, to update it. I also enjoyed his two-part interview with Avi Bryant.

Even if you’re not doing Rails stuff, Akita’s feed is a Must Subscribe.

Mike Clark just announced the release of his new Beta book Advanced Rails Recipes. Although it is a beta book, it already contains 42 recipes, and by the time the book is complete there should be 70+ available.

Unlike the first Rails Recipes book, written primarily by Chad Fowler, this books is collection of the best tips and tricks from the Rails community at large. Mike Clark contributed, reviewed, edited, and consolidated them into a great collection of the most up-to-date Rails information available.

For those of you that do not know him, Mike Clark is an independent consultant, author, trainer, and programmer. I got to know Mike and his lovely wife Nicole through their excellent training program at The Pragmatic Studio.

I just received my PDF copy and plan to make my way through it over the next week or two. So many new books, so little time…

As many of you know, Django recently introduced an enhancement that automatically auto-escapes all template variables. It’s a very elegant solution and something that I’m really excited about. Bob Follek recently wrote an interesting post asking the question Why The h Can’t Rails Escape HTML Automatically?”...

There’s been some buzz lately about Hobo, a plugin extension to the Rails framework that makes it easy to do rapid prototyping of web applications. You can find out about all of the features at the HoboCentral website. One exciting feature is the implementation of DRYML, a way of drying up your views and providing extendable tag libraries.

Check out the screencasts. They’re very well done. I haven’t been this stunned by a screencast since I saw the original DHH Rails screencast. It’s exciting times.

I was trying to spec out a few of my controllers that had actions on them requiring authentication. After jumping through many mind hoops to figure out how to stub them out properly I asked the RSpec-Users list and received this solution from Graeme Nelson:

def mock_user_authentication(allow_user_to_pass=true)       
  controller.stub!(:login_required).and_return(allow_user_to_pass)
end

It’s elegantly simple and works well. I’m still fumbling around with this RSpec stuff and did not realize I could stub out a method directly on the controller. This has cleared up a big missing piece in my thinking.

Ryan Bates provides an excellent collection of Ruby on Rails screencasts for free. If you have a couple of minutes, literally, please check out what he’s put together.

Some time ago I had envisioned producing something similar, but in no way could I have even come close to this. Ryan really nails it, with high production quality and keeping it concise. Show him some love.

The fine folks developing Slate, a content management system for Rails, have just released a Textile Editor plugin. This works well in conjunction with Err the Blog’s acts_as_textiled plugin.

After months of waiting patiently, I was finally informed that my elastic cloud account was available. If you’re not familiar with all of the cool things Amazon Web Services is doing, I recommend you spend some time getting acquainted with their offerings. I’ve been using S3, their storage solution, for some time now, and I’m definitely stoked about playing around with EC2. This on the heals of Jesse Newland’s announcement of Capazone, a Capistrano task library for managing EC2 servers. Like I needed one more thing to distract me from all the projects I should be working on.

ActiveReload, a new company by Justin Palmer and Rick Olson (of Mephisto fame), just announced the release of Lighthouse. Lighthouse is a simple and elegant issue tracking software as a service application. Signup for free account and give it a whirl.

Subscribing to the RSS Change Log feed to the Subversion repository for Ruby on Rails is a great way to stay on top of what’s going on in Rails land and helps to give you a leg up on the types of things that are coming down the pipe. Today I saw Changeset 6485 and it was quickly blogged about by Dave Thomas. This changeset removes the use of the semicolon in RESTful routes and reverts it back to the old slash way of indicating sub resource intent. What this means is that a route like:

/categories/1;edit

will now become (or should I say become once again)

/categories/1/edit

In addition we get niceties like:

/categories/recent
/categories/1/stamp

I’ve never liked having the semicolon in the url; it just smelled of ugliness. I think we’ll find that this change is a good one and one that allows us to have the benefit of RESTful urls while still allowing for legitimate variations on that theme to support sub resources.

I just spent about an hour trying to figure out why none of my RESTful routes were working properly within my RSpec controller specs. In my controller I had some boilerplate code like this:

# POST /categories
# POST /categories.xml
def create
  @category = Category.new(params[:category])

  respond_to do |format|
    if @category.save
      flash[:notice] = 'Category was successfully created.'
      format.html { redirect_to category_url(@category) }
      format.xml  { head :created, :location => category_url(@category) }
    else
      format.html { render :action => "new" }
      format.xml  { render :xml => @category.errors.to_xml }
    end
  end
end

The line causing the problem was:

redirect_to category_url(@category)

I kept receiving an error on the eval of category_url with an error description of “can’t convert Fixnum into String”.

I tried replacing @category with @category.id to see if I would get different results. The error went away but the test failed indicating that the id returned from the @category instance was not the same as I was expecting. This led me to determine that I needed to stub out the id property on my class. So I added the following to my setup:

@category.stub!(:id).and_return(1)

Everything worked. Problem solved. But wait, that’s ugly and smells of something wrong. I should be able to just pass the object to the category_url and have it return the correct value. What I did next was go down a rat hole trying to figure out what the named route was sending to the object to get the id. I had assumed id, but in fact it’s to_param, which I had already stubbed out as follows:

@category = mock_model(Category, :to_param => 1)

So what’s the problem? It turns out that to_param must return a string. Makes sense. I changed it to the following and everything worked perfectly:

@category = mock_model(Category, :to_param => "1")

It’s little things like this that make learning so much fun. This issue is really indicative of a much bigger problem—my lack of understanding mocks and stubs. But, I’ll have more to write about this later.

As I indicated in a prior post I’m beginning to wrap my head around Rspec and use it in a new project that I’m working on. I recently came across a post where someone had written something similar to the following, indicating a spec for has_many and belongs_to in a model.

context "A Category with fixtures loaded" do
  fixtures :listings, :categories

  specify "should have many Listings" do
    l = categories(:cars).listings
    l.should_not be_nil
    l.should_not be_empty
    l.first.should be_an_instance_of Listing
  end
end

One of the comments to the blog post was critical of this approach suggesting that this spec was validating Rails code and that the author should focus only on code that he / she has written. I’ve seen this argument several times in the past and this issue actually came up briefly in the Advanced Rails Training course in Chicago.

While I agree that you shouldn’t be testing Rails code, that’s not what is going on here. The spec is for the existence of the defined relationships within the model, and that things are wired up properly to enable accessing the relationship properly within the model. If someone were to inadvertently remove the has_many method call in the model the spec would fail, which is exactly the behavior we want.

Secondly, even if we were testing Rails code, I think it’s better to error on the side of overcoverage than to not write tests at all. It is important that developers are not so overwhelmed with the “right” or “wrong” way to do testing that testing is not done at all.

The above code actually comes from a project I’m working on. This blog post aside, if you have recommendations on how it should be done differently, please let me know.

The past couple of weeks I’ve been digging into Test::Rails from the ZenTest library of tools. One of the main benefits to using Test::Rails is the ability to have separate Controller and View tests. It also includes a lot of test helpers that make the process of testing Views and Controllers much easier. I about gave up on Test::Rails a couple of different times; the docs are a bit sparse and there’s not a lot information on the internet about how to setup and use Test::Rails. I finally happened upon a blog post that gave me a few tidbits of information and got me pointed in the right direction.

I’ve documented the setup process I took as well as some helpful hints.