21 May 2008

Spikin' Ruby on Rails

by mo

I’m just about finished reading…

Agile Web Development with Rails, 2nd Edition
by Dave Thomas, David Hansson, Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, Andreas Schwarz

Read more about this book...

This book focuses on the Ruby on Rails framework for developing web applications. It touches very lightly on the Ruby language itself, but mostly talks about things like Model View Controller, Active Record, Action Pack and how it’s implemented in RoR’s. The book starts off with a light primer on what MVC is, which I enjoyed, then moves on to how to install RoR, then jumps right into building a quick application using RoR. I enjoyed the discussion Testing and the concept of Migrations.

Before jumping right in to chapter one I quickly read through the first Appendix titled “Introduction to Ruby”, which helped a little bit, but I probably would have done better if I had first read a book just on the Ruby language. I think I would have found it more interesting as well. There were times in the book where it got so deep into the nitty gritty details of the RoR framework that I just completely lost interest. I choose to read this book to get some high level ideas, but I wasn’t as interested in the tiny details of the framework. There’s tonnes of great ideas in this book, that I recognize being adopted quite a bit in the .NET community. Migrations and MVC being a couple of my favorites.

Here’s a few excerpts that I enjoyed from this book.

Convention over Configuration

Rails gives you lots of opportunities to override this basic workflow … As it stands, our story illustrates convention over configuration, one of the fundamental parts of the philosophy of Rails. By providing convenient defaults and by applying certain conventions, Rails applications are typically written using little or no external configuration - things just knit themselves together in a natural way.”


“Over the years, developers have come up with ways of dealing with this issue. One scheme is to keep the Data Definition Language (DDL) statements that define the schema in source form under version control. Whenever you change the schema, you edit this file to reflect the changes. You then drop your development database and re-create the schema from scratch by applying your DDL. If you need to roll back a week, the application code and the DDL that you check out from the version control system are in step: when you re-create the schema from the DDL, your database will have gone back in time.

Except… because you drop the database every time you apply the DDL, you lose any data in your development database. Wouldn’t it be more convenient to be able to apply only those changes that are necessary to move a database from version X to version Y? this is exactly what Rails migrations let you do.”

E.g. 001_create_products.rb

class CreateProducts < ActiveRecord:Migration    
  def self.up      
    create_table :products do |t|      
      t.column :title, :string      
      t.column :description :text      
      t.column :image_url :string      

  def self.down      
    drop_table :products      

Pragmatic Ajax-ification

In the old days, browsers were treated as really dumb devices. When you wrote a browser-based application, you’d send stuff down to the browser and then forget about that session. At some point, the user would fill in some form fields or click a hyperlink, and your application would get woken up by an incoming request. It would render a complete page back to the user, and the whole tedious process would start afresh…

Whenever you work with AJAX, it’s good to start with the non-AJAX version of the application and then gradually introduce AJAX features.

No REST For The Wicked

“REST stands for REpresentational State Transfer, which is basically meaningless. What it really means is that you use HTTP verbs (GET, POST, DELETE, and so on) to send requests and responses between applications.”

Performance Testing

Testing isn’t just about whether something does what it should. We might also want to know whether it does it fast enough.

Before we get to deep into this, here’s a warning. Most applications perform just fine most of the time, and when they do start to get slow, it’s often in ways we would never have anticipated. For this reason, it’s normally a bad idea to focus on performance early in development Instead, we recommend using performance testing in two scenarios, both late in the development process.

Statement Modifiers

Ruby statement modifiers are a useful shortcut if the body of an if or while statement is just a single expression. Simply write the expression, followed by if or while and the condition.

The following is valid Ruby syntax:

puts "Danger, Will Robinson" if radiation > 3000

I would love to express the following C# syntax.

public void AddLicense(ILicense license){
  if (license.IsValid()) {

Like this…

  public void AddLicense(ILicense license){
books 💎