It’s been a great 3 days here at RubyConf. I’m a little wiped out, but here are a variety of notes, mainly on the Rails end of things.

There’s been a ton of info on Ruby, from the arcane to the really, really arcane. The conference is more than twice as big as last year, which seems to be largely due to RoR. There were many of us who hadn’t attended before and were there this year as a result of using Rails. There was mention in DHH’s morning talk of a possible RailsConf, but that sounds pretty speculative at this point. There was also some talk about having a Rails track at RubyConf and so not breaking it off.

The Rails core team has been working all weekend on the last touches for a 1.0 RC. Below are the notes on what’s new. The release may have a number like 14.0 or 13.2 or such so that RubyGems will pick up the change for the final 1.0 release. The main area they need to work on for final release is the database connectors for closed source databases.

Here are some misc. notes from this afternoon’s talk by DHH on Rails 1.0.

1. db/schema.rb
Can round trip
dbschemadump
dbschemaimport
to maintain database. Use along with migrations. If you don’t use constraints (indexes are supported) can manage a ‘very agile database’ this way.

2. Rails::Initializer
Mainly will help to update your app to new versions of Rails. Will no longer have to run ‘rails’ against your application. Substantial changes to environment.rb and others.

3. Better FCGI spinner, spawner, reaper – also better fcgi_handler (same as noted in my fastcgi guide). The bad news: ‘dynamically allocated FastCGI Processes are Evil’. – David Heinemeier Hansson when I asked about them. That’s what DreamHost uses, along with many other shared web hosts. So it doesn’t look good for FastCGI without some workarounds.

What was suggested as the best solution for shared hosts was using TextDrive’s setup. They use a proxy http server to forward requests to the user’s own instance of http server which then has its own processes and can manage them with the spawner/reaper tools. Maybe we can get DreamHost to look into the setup involved.

4. SwitchTower automated deployments to clusters including restarting processes as needed. Can even deploy into production ‘in prime time if your code is solid’. Won’t disrupt in-progress requests.

5. Plugins Use directory under /vendor: /vendor/plugins/acts_as_taggable/lib

  • the lib directory will be added to the path, so in models can easily access the plugin
  • if you use an ‘init.rb’ (at same level as /lib dir) that will get run at startup time – so you could extend activerecord, for example
  • should be simple – use a components for more involved needs

6) Prototype 1.5, Script.aculo.us 1.5

  • Some new stuff: count iterators (example was to show unread threads in an rss reader). New slider.

7) Speed

  • about 2x speed over 0.13.1 - without changing app
  • more with changes to ruby/application: can change garbage collector, etc – diminishing returns, unlikely to be needed by most

8) Binding gems and edge You can bind your rails app to the rails gems you have installed. They will be expanded into /vendor for you. This only binds the Rails gems – if you use others you’ll need to tend to those yourself.

This is particularly useful on shared hosting accounts where they may change the version of some gem that breaks your app.

rake freeze_gems
rake unfreeze_gems

Unfreeze simply removes the directory from under /vendor and your back on the local gems. Very handy.

9) Per Action Session Management Can turn off sessions on a per action basis.

session :off, :only => :feed

Would turn off sessions for the feed action. This was big for basecamp/backpack to reduce sessions that were getting spawned for feed aggregators that were hitting every 15 minutes. There are switches besides ‘:off’ and there are a number of other options, e.g. only for web services.