Empty Thoughts

I just happened across the Passenger website. Passenger claims to provide “Easy and robust deployment of Ruby on Rails applications on Apache webservers.” The metric graphs show it performing as well as Mongrel and Thin. It will be interesting to see how this plays out in community and the hosting companies. In true Ruby on Rails fashion there’s screencasts, lots of pretty colors, big fonts, and rounded corners everywhere. Hopefully there’s some there there.

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…

Bob Follek wrote an interesting post asking the question Why The h Can’t Rails Escape HTML Automatically?.

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. (Although I could do without the plethora of questions on IRC that begin with “Why suddenly are all my HTML attributes appearing as > and <.) The really cool thing is the amount of flexibility built into the auto-escaping architecture. Auto-escaping can be turned off per-site, per-template level or per-variable level. This gives the developer total control, while still maintaining a safety by design stance.

What’s even more interesting is the comments in Simon Willison’s reference to the aforementioned post. To be more precise the interesting part is the actual comment banter that takes place between koz, Michael Koziarski, a Rails core developer and Simon. Read the comments to get all the details, but essentially koz explains that the difficulty is in the fact that all of the Rails helpers, such as link_to would need to be able to not be escaped. It is a difficult problem but the same problem existed for Django with some of the tags and template filters, and they handled it with a flag that let the render engine know how things should be handled.

I got involved with Rails in early 2005 and I remain involved somewhat with the Rails community, although not as engrossed as I once was. The Rails developer community has been asking for this feature for as long as I can remember. Some will argue that a framework can’t solve lack of developer competence, but the reality is that our frameworks and tools should be safe by design. Security must be something that is designed into the product and not as an afterthought.

Along the same vein as this thinking, it has bugged me for a while now that the database vendors do not make any effort to stop sql injection attacks. They could be seriously thwarted by setting a default database option that does not allow more than a single transaction to be executed at a time. Of course they would need an option to turn this off as needed, but this would certainly help correct the problem in a big way.

Regarding the Rails issue, I agree with koz that it’s not an easy problem to solve, especially with a framework like Rails that is so far along in development. But it’s also not an impossible thing to address either. The auto-escaping Rails plugin looks interesting and I hope that as the Rails framework moves forward they will adopt a solution such as that to deal with this problem effectively. My guess is that it probably took no more than about 40 – 60 hours of development time to get it implemented in Django, although that’s just an assumption on my part.

As an aside one thing that has always impressed me with Michael Koziarski is that although he is quick to defend Rails or set the record straight, he always does so with grace. This is certainly something that a lot of individuals involved in open-source projects could learn from.

The Beast is getting green eggs and spam

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.

About a week or two ago I emailed Benjamin Curtis, creator of the Agile Web Development plugin repository. I asked him if he would add the ability for users to be able to save a list of favorite plugins that they use all the time. I wanted a place to keep track of all the plugins I am interested in so I don’t have to keep going back and searching for them every time. I was pleasantly surprised when he emailed me back about a week later and said that he had implemented it. It works perfectly.

If you’re not familiar with Benjamin’s repository, I recommend that you head on over there as soon as you have a few spare hours. It’s easy to get lost in all the great plugins that are being developed. Thanks Benjamin and keep up the good work.

This past week I attended Advanced Rails Training in Chicago that was put on by Pragmatic Studio. Pragmatic Studio is Mike Clark’s training company and includes Ruby / Rails heavy weights Chad Fowler and Dave Thomas.

It was a great experience and I highly recommend that you attend one of the Pragmatic Studios in the future. What is always interesting about these types of events is that the value in attendance has to as much with the offline discussions as it does with the training program itself. There were so many great people that I had an opportunity to get to know and others that I got to get reacquainted with. I was especially fortunate because Mike Mangino, founder of Elevated Rails, put me up and chauffeured me around. I learned so much from Mike during my stay. I highly recommend his company if you need a quality solution for your next Rails project.

There was also another unique opportunity for the attendees of the Advanced Rails training program. David Chelimsky, lead developer on RSpec, was also in attendance and was kind enough to give us all a special presentation (including fine libations donated by Object Mentor) on RSpec one evening. David discussed RSpec, it’s history, it’s use in Rails applications, and how to make the transition. His presentation was exactly what I needed to get me over the BDD hump. I’ve decided that my next project will be using RSpec and hopefully I’ll have more to say about that as I get into it.

All in all it was a whole lot of fun. If you want to god deeper into Rails development, or if you’ve had your head down and need to get updated on the latest Rails approaches, like Simply Helpful, Capistrano deployment, Restful Routes, etc…, head on over to the Pragmatic Studio website and get signed up for the next available course.

I recently started using Topfunky’s Power Tools Plugin to clean up some of my testing routines. It’s a nice little package that brings together lots of different asserts that have been out there in the wild in one form or another.

I really enjoy the assert_required_fields method. I used to implement my model checking like so:

def test_should_require_login
  assert_no_difference User, :count do
    u = create_user(:login => nil)
    assert u.errors.on(:login)
  end
end

...and now with the Topfunky Power Tools Plugin I end up with the following:

def test_should_require_login_password
  assert_required_fields :create_user, :login, :password
end

Notice how it allows you to check multiple fields at once. There’s a lot more available in the plugin, but sometimes all it takes is one or two little things to make your day.

If you’re receiving this error when using the streamlined plugin, I might have a solution for you:

“A copy of AuthenticatedSystem has been removed from the module tree but is still active!”

It’s taken me several hours of investigation but I found something that works. The issue is that in Rails 1.2 the order of initialization has changed. You can find a lot more information about this from Rick Olson’s blog.

The issue is that the PlugIns load before the application itself. Therefore the PlugIns cannot refer to the application or monkey patch it.

To correct this problem in streamlined we only need to comment out two lines; the require line to the application.rb file and the line that reminds us not to act_as_streamlined from the ApplicationController directly. The beginning of the module should look like the following:

#require "#{RAILS_ROOT}/app/controllers/application"
module StreamlinedController 
  def self.included(base) 
    #raise "Cannot extend ApplicationController with acts_as_streamlined: please extend individual controllers." if base.instance_of? ApplicationController 
    base.extend(ClassMethods) 
  end

The problem with these lines is that they are referring to the ApplicationController which creates a dependency between streamlined and the ApplicationController. As I understand it prevents its dependencies from being unloadable.

I’ve done some preliminary testing and it appears to be working fine. I will continue with some more thorough testing and report back if there are problems.