The Rails podcast is back in business with a handful of new shows conducted by Geoffrey Grosenbach of Topfunky. There are interviews with Amy Hoy, Obie, Matt, and Thomas Fuchs. And Geoffrey promise to keep the deliveries regular. Fire up that nano.
Our trusty Rails server Wrath was generating cruft and crust faster than you could say we-have-no-sysadmin, so at RubyConf we decided to remedy the situation and ask for help. Dan Peterson stepped up to the plate and is now officially the new Rails systems administrator. Welcome on board, mate!
And wasting little time, he has already cleaned a few rough corners for performance and, more importantly, upgraded and fixed Trac — the software that runs dev.rubyonrails.com. So no more timeouts, better performance, more features.
Seth Banks has launched Skunk Studios. It’s a games portal for mini-games available for single play or buy. Neat stuff.
Sebastian Delmont from New York City is looking for 1-2 full-time (no telecommuting) Ruby on Rails developers for a new consumer-focused startup. Write him sd at notso.net. 3 Leaf Networks is looking for a single programmer in Santa Clare for work on another start-up in Rails.
Robby on Rails has a great introduction to named placeholders in Rails. Making ActiveRecord::Base.find more readable and secure at the same time, what’s not to like? Please Robby, or someone else, turn a succinct version of this argument into a documentation patch.
Sam Stephenson and Marcel Molina are no longer available for custom consulting jobs through Ionist. Both are now “made men” of the 37signals syndicate. They will certainly continue to amuse us all through projectionist, though.
That restores the 37signals part of the Rails core to 1/3. Still down from 1/1 in January and 1/2 before going to a counsel of 12. But once again respectable ;)
SwitchTower is a utility for executing commands in parallel on multiple machines. It lets you (among many other things) deploy distributed applications with a single command.
When your application is young you may be deploying it to a single machine, which runs the web server, app server, and database all together. In this situation, deploying manually is not unbearably painful. But as your application grows you may find yourself needing to deploy your application to two web servers, four app servers, and two database servers, atomically. This is where SwitchTower steps in as a pain-killer.
Suppose you have an existing Rails application that you want to deploy to a cluster of machines. SwitchTower attempts to make the entire process as painless as possible:
- Install SwitchTower. This is as simple as
gem install switchtower.
- Decorate your application with the necessary SwitchTower files. Just do
switchtower --apply-to /path/to/your/app.
- Tell SwitchTower where your application code sits and what machines it should deploy to. Just edit
config/deploy.rband fill in the blanks.
- Set up your machines so they are ready to receive your application. It’s as easy as
rake remote_exec ACTION=setup.
- Lastly, deploy your application! Just type
rake deployand let the good times roll.
In addition to simply moving your application to the various boxes, SwitchTower attempts to make the task of maintaining your deployment simpler. Suppose something goes wrong while checking out your code—SwitchTower will detect that and roll back the change, on all deployed machines. This means it is much harder to wind up with your application out of sync on the various boxes.
Other things SwitchTower can do, out of the box:
- Database migrations on your production database
- Enable/disable the web interface (only works with Apache currently)
- Restart your application on the application servers
SwitchTower also makes it very simple to override and extend the standard tasks, and to write your own. The tasks use a simple language similar to Rake that allows you to automate many different tasks.
Want to know more about SwitchTower? There’s an entire user manual full of useful tidbits at http://manuals.rubyonrails.com/read/book/17.
The release of 1.0 is near upon us! It has been a long time in the making, involved a heroic final sprint at RubyConf by the core team, and is a testament to how it’s all been coming together over the last months. Almost three hundred bug fixes, enhancements, and new features have been introduced since 0.13.1 saw the light of day three months ago. That’s on average three per day. So it’s not been a while because of slacking off.
But with all these changes, we want to allow for an extended release-candidate phase before we declare 1.0 a reality. So from today you can get the 1.0 RC 2, which is packaged as version 0.14.1 in the gems.
Over the next two weeks or so, we’re very interested in hearing about bugs and we’ll likely push out a few more release candidates as more and more fixes go in. That said, we can’t fix it all and we surely can’t process all the pending feature enhancements for 1.0. So don’t expect to see an empty Pending Patches or Faults lists. Our main objective is to stamp out the “heinous” bugs: those that significantly affect the many or those that dangerously affect the few.
(The main gem server is pretty over-worked, you may want to do
gem install rails --source http://gems.rubyonrails.org --include-dependencies to offload it a bit)