For example, if instead of using config.force_ssl = true, you used the following snippet your code it would not force ssl on pages under the path /public:

require "rack/ssl"
config.middleware.insert_before ActionDispatch::Static, Rack::SSL, :exclude => proc { |env| env['PATH_INFO'].start_with?('/public') }

Instead of jumping through these hoops in your configuration file, I thought that Rails should allow you to pass options to Rack::SSL.  I submitted a pull request with my changes which was promptly accepted by José Valim, so if you’re either using edge Rails or 3.2 when it comes out you’ll be able to do the following to configure SSL in your application:

config.force_ssl = true
config.ssl_options = { :exclude => proc { |env| env['PATH_INFO'].start_with?('/public') } }

I hope that this change makes configuring your application to be safe a bit easier. Happy SSL’ing!

1. Check to see if the continuous integration build is passing
2. Pull any upstream changes
3. Run the local test suite
4. Push to the remote repository if the local tests are passing

Often, we skipped the first step, since it was annoying to check the CI server manually, and running the local test suite is generally a good enough indication that the world is OK before pushing.  However, when the local build takes upwards of 20 minutes you may not want to wait to see a local failure to find out that CI was failing.  Ideally, you want to check if the remote build is failing, and if it is, wait until it passes before pulling and running the build.

I wrote a gem, propel, that encapsulates this logic into a single command.  It currently works with Jenkins, CI Joe, and Team City, and support for other CI servers is easy to add.  You can have it abort if the CI build is failing, or have it wait for you while someone else fixes the build.

Additionally, it tries to be helpful if you encounter anomalous situations while pushing your changes – if you ended up with a detached HEAD, it aborts with a helpful message before any harm is done to the repository.

Installation is easy – just ‘gem install propel’.  You can run it by simply typing ‘propel’ inside of your local project repository.  Configuring the url of the CI server can be done via the command line, or it can be saved in a .propel file at your project root.

Propel is still pretty new, but it has been working well for us on a few projects.  Check it out and let us know what you think.  Happy propelling!

While porting a small Rails application, Listable, to Rails 3.0, I found an interesting difference in the behavior of the two frameworks: attr_accessible on a model used for a join relation between two entities works when using ‘<<’ to add records in Rails 3.0, while in Rails prior to 3.0 it is silently ignored.   It took me a moment to figure out what was happening, so I figured I’d leave a note here in case it helps someone else in porting their app to the newest Rails framework.

Taking a step back, here is a simple case that demonstrates the difference between Rails version 2 and Rails version 3 with respect to << (aliased as ‘concat’ and ‘push’ in the ActiveRecord framework) when adding to a collection established using has_many :through.  Given three models: User, List, and UserListLink (which has foreign keys for user and list):

class User < ActiveRecord::Base

has_many :user_list_links, :dependent => :destroy

has_many :lists, :through => :user_list_links

end

class List < ActiveRecord::Base

has_many :user_list_links, :dependent => :destroy

has_many :users, :through => :user_list_links

end

class UserListLink < ActiveRecord::Base

belongs_to :user

belongs_to :list

end

In both Rails 2 and 3, the following works:

u = User.create

l = List.create

u.lists << l

However, if you add attr_accessible [] to UserListLink, under Rails 3 the UserListLink that is automatically generated will have nil/null values for both list_id and user_id. You’ll see the expected message in the Rails log, “WARNING: Can’t mass-assign protected attributes: list_id, user_id”, which indicates that Rails uses mass assignment to create this intermediary object. In my case, removing the attr_accessible line in my code allowed ‘<<’ to work as it did before upgrading to Rails 3.

I’m not sure how I feel about the change in behavior in ActiveRecord 3 where mass assignment protection is triggered by the ‘concat’ method on a has_many :through relationship.  I suppose whether or not this is ‘correct’ behavior depends on whether there is a chance for user-generated data to be passed into the attribute hash used to construct the intermediary object.  If so, this is probably a nice fix in ActiveRecord 3.    Otherwise, though, it may help to bypass the mass assignment check when saving intermediary objects using concat.

First, my goal in creating Clean.ly was to add a layer of information on top of the NYC restaurant data to make them more interesting and useful.  Geocoding the restaurant addresses was a first step in this process, which was easily accomplished using the Google API.  Next, I grabbed some other information about the restaurants, including type of food, from other freely available sources on the web.

For these data mining tasks, I needed to serialize a bunch of operations to make sure I didn’t go over API quotas.  I also wanted to create a system that could accept data from different inputs without much trouble later.  To meet these needs, I used a Kestrel queue to serialize HTTP retrievals from various providers.

Once I had the necessary data in place, Sphinx was an obvious choice to bring these data in front of the user on demand.

For those of you who have used the fulltext searching engine in Sphinx, it’s easy to envision how restaurant searching based on name or “tag” (such as type of food) would work.  A lesser known fact about Sphinx is that in the newest releases, simple geodistance calculations are supported.  The only real trick in implementing this part of the Clean.ly was that the latitude and longitude obtained from Google had to be converted to radians before piping them to the Sphinx indexer.  After that, I had near-instant results with distance calculations from an input address, making it possible for users to search for restaurants close to where they want to eat.

Once I had geodist calculations in Sphinx working, I wanted to make sure that pages loaded quickly.  Since Clean.ly doesn’t really have user-modifiable content, I immediately thought of page caching.  In other work that I’ve done scaling high-performance web sites, I had implemented Varnish, a reverse page caching daemon, and had great success.  It’s an extremely elegant and easy-to-use program which I’d highly recommend checking out for anyone interested in scaling high volume web sites.

Implementing Varnish for Clean.ly turned out to be a fairly straight-forward task. Clean.ly only has one server, a small instance on EC2 that I also use to host a variety of other small Rails projects.  Varnish proxies port 80 on this instance to another port where Apache is listening, and it short-circuits and returns results for pages stored in the page cache.

In another post, I’d like to go into more detail on using Varnish with Rails applications.  For now, though, I hope that you enjoy using Clean.ly.  Be sure to check it out, as well as the other great submissions to the NYC BigApps contest.

In other words, software engineering best-practices often go out the window as Rake tasks are built, leading to missed opportunities for software reusability and increased maintenance costs.  In my experience, it’s only a bit more effort to turn the effort of writing a one-off Rake task into an opportunity to expand on the reusable components already in your system.

When I’ve coded maintenance scripts in Rake, two of the signs that a task needs refactoring are length of the task itself and the number methods that have to be defined in the namespace to support the method.  A task, just like any other method, should do just one thing.  If the Rake task is so long that it scrolls off the screen, opportunities for error are high and the next person working on the code is much more likely to start from scratch rather than sort things out in the method body.

The same applies to Rake tasks that require the presence of lots of other methods defined loosely inside of the namespace.  Defining methods in the Rake namespace for munging data or doing other task setup usually means that these methods aren’t formally tested anywhere.  In many cases, it also indicates that opportunities to hide complexity by using an Object-Oriented interface are being lost.

I’ve found that Rake tasks often descend into a mass of procedural code to manage data.  Part of the strength of Ruby is the set of tools it provides for defining objects that we can use to hide complexity, leading to more maintainable code.  It’s a shame to not use these tools when it only takes a short amount of time to think about how your task could be decomposed into a set of methods to be invoked on new or existing objects.

It takes some practice to think about writing good object-oriented code in short Rake tasks.  One of the hurdles is thinking of your task in terms of the existing objects in your codebase.  These may be existing models, in which case you have a pre-existing place to put code that would be more cohesive than just including it in the namespace of your Rakefile.  In other cases, you may have to define new classes (often under the “lib” folder of your project) to best encapsulate the data that you have to act upon.

Writing short Rake tasks that operate on objects in your codebase rather than defining long task bodies with supporting procedural methods often requires a shift in thinking about your Rake tasks and how it relates to the objects in your codebase.  The effort is worthwhile, however, as you add new classes and more precisely define the interfaces of existing classes in your system in order to achieve a more maintainable system.

It may seem to be hard to articulate beyond an intuitive impression that subclasses are stepping beyond their bounds in particular cases.  In my own work, I’ve found it helpful to think through Barbara Liskov’s notion of substitutability of subclasses in creating a clean inheritance hierarchy in Rails projects.  Essentially, Liskov substitution says that we should be able to replace a parent class with any subclass without changes in the interface or the exceptions that are raised.  If this rule is being violated, it’s a sign that the renegade classes may need to be reigned so they adhere to the contract established by the parent, or put into a different pattern if they’re really just bursting out at the seams.  There are many more implications of this rule expressed succinctly on the page linked above, so it’s worth a read as you think through this issue in your own project.  Once this rule is thought through, it often exposes numerous cases where an inheritance relationship can be improved or refactored into a different form.

The Gang of Four describes how inheritance can easily be overused.  I’ve frequently seen this in Rails projects.  Specifically, you should watch out for cases where subclasses become entangled with the parent classes through modification of instance variables or private methods.  The GoF book notes that we should tend to favor composition of simple objects to create a software ecosystem instead of relying on inheritance hierarchies. Generally the problem noted in the GoF book is that inheritance is essentially at odds with encapsulation.  In Ruby, as with other dynamic languages, this problem isn’t easy to resolve, though some thought has been given to the matter at the level of language implementation.  The GoF book reminds us that delegation is always an alternative to inheritance in more complex cases.

Thoughts on inheritance from GoF as well as the principle of Liskov substitution are extremely useful in identifying cases where inheritance is poorly implemented through subclasses that are doing too much (essentially stepping out of line from their parents).  I’m sure that most Rails programmers reading this post will be able to think of a case that could be improved by considering these ideas.

Since abusive subclasses can take many forms, it is difficult to provide a path to clean code that works universally in all Rails projects.  An approach that works well in many cases, though, is to find behavior that can be extracted in the overloaded subclasses to a pattern such as delegation.  This gives the classes room to be more substantially different without having to worry about straying too far from the requirements established by the parent object.  If you’re new at Rails it may be helpful to remember that you’re not locked into expanding the functionality of your project by creating increasingly complex models.  In fact it’s often easier to build small classes for different functionality and project subcomponents.  They can stay in the “lib” folder of your project.  This also makes tests easier to maintain when all of these minor classes have their own spec files.

On the other side of the spectrum–from classes that abuse inheritance by the mechanisms above–are classes that don’t do enough.  These were called “lazy classes” at least as early as Martin Fowler’s book, “Refactoring: improving the design of existing code.”  Fowler defines lazy classes as classes that don’t pull their own weight.  These classes can be found independent of their inheritance relationship, but Fowler talks about the special common case of subclasses that don’t do much.  Since this problem is succinctly expressed by Fowler I’ll quote the short section from the Refactoring book in its entirety before discussing how Rails projects often fall into this trap:

Each class you create costs money to maintain and understand.  A class that isn’t doing enough to pay for itself should be eliminated.  Often this might be a class that used to pay its way but has been downsized with refactoring.  Or it might be a class that was added because of changes that were planned but not made.  Either way, you let the class die with dignity (Fowler 83).

I’ve lost count of the number of cases that I’ve seen where subclasses dangle uselessly off the end of an inheritance chain, and I inevitably think of applying Fowler’s object-oriented “tough love.”  Remember that with ActiveRecord::Base STI it’s easy to remove the type column after pulling their behavior up into the parent classes.  After that, they’re a prime candidate for the refactoring that Fowler anarchistically labels “collapse hierarchy.”

One Ruby-specific way to see from outside of a class that a class may be underused is if you find code that acts based on a class type with the method “is_a?”.  For example, if you have a STI relation where Car has subclasses RedCar and BlueCar, you might have in your code somecar.is_a?(RedCar).  Note that this isn’t really considered good Ruby code anyway, since most programmers prefer duck-typing to asking a class what it is.  That is, asking what it respond(s)_to? is considered better as it’s more versatile if the object given is of a different type. In this case, it isn’t likely that we really need colored cars to be their own object types… giving them an attribute “color” should suffice without the confusing presence of classes that don’t do much.

As you can see, there is an abundance of material from software engineering that can be applied to Ruby and Rails projects to clean up inheritance hierarchies.  In my own experience applying refactorings to inheritance hierarchies along the lines described above can really help Rails projects grow and accommodate new features.  There are certainly some cases where inheritance is the correct choice.  It is clear, though, that Rails and Ruby projects benefit greatly in terms of maintainability and extensibility when programmers consider whether inheritance is abused or subclasses are underused.