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.

My wife, Lori, and I have been using Listable, both on our iPhone devices and on the Web for the last month, and we have lists of groceries, tasks, movies that we want to watch, and wines that we like. It has been helpful for both Lori and I professionally, as I found out that Lori had been keeping a list of things that needed to be done on her dissertation, and I used it to keep track of bugs that needed to be fixed in Listable.

In our personal lives, it has been helpful as well, as Lori and I are keeping a list of possible baby names for our first, a girl, due on December 30th.  Names we like more get re-arranged to the top, and we mark as “completed” names that we’ve considered and discarded.  Maybe we’ll even share that list with our daughter when she’s old enough to appreciate the collaborative process that went into giving her a name!

We use the Listable web site, listableapp.com, to manage lists when we’re on our computers, and the iPhone app when we’re not at home.  The iPhone app includes push notifications so that you know immediately when a collaborator makes a change to one of your lists.

Listable for the iPhone is a free download in the App Store.

Have you tried Listable?  Let me know what you think in the comments!

This release makes SubwayDelay the only iPhone application to integrate both service alerts and scheduled advisory information available in an easy-to-read format for NYC subway riders.

More information is available at SubwayDelay.com.

SubwayDelay is not affiliated with the MTA.  Unfortunately, the MTA has yet to release easy access to data on service alerts.  This application rests on MTA Feeds (another site that I created), which provides free access to the MTA data in an easy-to-consume format for transit software developers and subway riders.