You can see these (frequently updated) TextMate 2 release notes here: https://github.com/textmate/textmate/blob/master/Application...

You actually have a fair bit of flexibility here, if that helps: https://github.com/angular/angular.js/blob/master/CHANGELOG....

+1 for AssetSync and S3 hosting when you're running an app on Heroku. I wouldn't do it any other way anymore.

Aside from the obvious benefits, even just streaming certain responses can be useful when your app lives on the Heroku cedar stack and you want to keep connections alive for longer than the default 30 seconds. I put this to use (albeit with an older Rails technique) for processing credit cards. Long description of it here: http://icelab.com.au/articles/money-stress-and-the-cloud/

I read that article after reading your one about the NewRelic trouble. It's a nice technique and it's great to see someone else actually writing about this in regards to Rails (your NewRelic post saved me a load of agony) :)

Without the gem, making your RESTful routes have the right plural/singular forms takes something like this:

    match 'jobs' => 'jobs#index', :via => :get, :as => :jobs
    match 'jobs' => 'jobs#create', :via => :post
    resources :job, :controller => 'jobs', :except => [:index, :create]

For a bunch of resources, it's certainly much easier to use the one-line `tasteful_resources` helper instead.

It's your call as to whether you think this is worthwhile, but we think that these small details matter, even in URLs.

I don't understand why changing the way rails does its routing provides any benefit to the application or its code base.

Any rails helpers that depend on default resource routes will break or require special decorators to maintain consistency. Experience rails developers entering your code base will be confused why their newest partial didn't just work, and will have to learn in one form or another the customization this gem provides.

So now you maintain an entire "system" on top of rails for the benefit of reversing the pluralization of models, something a well placed monkey patch could do with less lines and overall maintenance.

All of this of course is limited to my opinion, your miles may vary. Generally, I've learned from those more experienced that quick and dirty will get you farther, faster, than building things you will never use.

The configs that Foreman generates for upstart or standard init system include the 'respawn' keyword, which makes sure that these processes are restarted if they crash for any reason. In this way, it can replace monit's basic functionality. What's not there at the moment is a way of restarting the processes when they, for example, use too much memory or CPU. Ideally you'd have something check for this as well.

You could also check out something like http://upstart.ubuntu.com/wiki/Stanzas#limit for use in your upstart scripts.

Ah, that's very useful! Thanks for the heads up.

Yes, this is absolutely right. The commands in your Procfile don't have to be rake tasks, they can be any executable system command.

While Foreman is written in Ruby, you don't actually have to use it in any way that is connected to a Ruby or Rails app. All you need is a Procfile and the foreman gem installed on your system.

Then, you can run the processes in the foreground with `foreman start` (eg. on your dev machine), or export the processes to config files for the init system of your choice (eg. on your server). Once the processes have config files in the init system, Foreman is out of the picture: your processes are run and managed by the init system.

Of course, this all works very well in a Rails app (hence my blog post), but that's only one of many uses. Hope that helps!

Great point. A good reason to keep them around in some form, even if you only revisit them occasionally.

I had about 400 yet-to-be-completed items in my to-do list before I started afresh. Seemed like way too many. How about you?