Seth Ladd's Blog

With Ruby on Rails 2.2 released , no doubt you've seen the major feature overviews. But did you know there are lots of subtle improvements? Pathfinder Development has a nice summary at Rails 2.2 For Me And For You . My favorite new feature that I didn't know about: Also, partials now take blocks, meaning they can act somewhat like layouts. The partial itself can contain a yield: <table> <tr><td> <%= yield %> </td></tr> </table> Then the call to the partial can include a block: <% render :partial => "table_partial" do %> <%= @project.name %> <% end %> And the yield command invokes the block, as you would expect Awesome!

Just a head's up to Ruby on Rails fans out there. DHH just checked in a very backwards incompatible change for the 2.3 branch. The root class for your controllers is now ApplicationController and not Application . I'm hoping this patch is reverted and instead rolled out for 3.0.

I had a need to display the deployment date and time (timestamp) and the current revision/version number in the footer of all our pages in our Rails application. Our users always were asking "Did you update the web site?" Thanks to capistrano , the deployment tool, this turned out to be fairly easy. Capistrano already collects the deployed version and places it into a file named REVISION in the deployment directory. The contents hold whatever is reported by your version control software. For git , this is a SHA1 hash. For the deployment timestamp, thankfully capistrano uses a timestamp for the deployment directory name. So we can just parse the path, looking for the timestamp. Below is the helper code, please let me know if there's a better way. [sourcecode language='ruby'] # pulls from the capistrano directory structure def deploy_timestamp if Rails.env.production? RAILS_ROOT.split('/').last else "Undeployed" e

Dear MySQL , I know you just got bought by Sun, and are now swimming in money and possibilities. Please continue this momentum by formalizing your connection to the Web by including a RESTful end point in your next version. The Web is where you grew up and matured, and it's time to give back. The architecture wars are nearly over, and REST has proven time and again to be the dominant architectural style for Web applications. You, MySQL, need to expose your data via REST to promote interoperability across clients and further cement your place as one of the top databases for the Web. This is low hanging fruit. Your URL space is well defined, as you have databases, tables and views, rows, and columns. The HTTP methods (GET, PUT, POST, DELETE) map very well to your SQL DML methods of SELECT, INSERT, UPDATE, and DELETE. I'd imagine your URL space to be something like: /databases /databases/NAME/tables /databases/NAME/tables/NAME/rows /databases/NAME/tables/NAME/rows/PK U