Free PeepCode Blog

Rethinking Rails 3 Controllers and Routes

Wed Jun 02 16:00:00 +0000 2010

This article is heavily styled and is best viewed at PeepCode!

DISCLAIMER: Reg Braithwaite delivered this quote in a completely different context¹, but I think it’s applicable to the design of almost any software API. Illustration by Mike Rohde.

The Rails router has been written and rewritten at least four times², including a recent rewrite for the upcoming Rails 3. The syntax is now more concise.

But never mind making it shorter! It’s time for a final rewrite: Let’s get rid of it altogether!

Let’s get rid of the seven controller actions: index, show, new, create, edit, update and delete. Their meaning is blurred in the context of REST. They’re an unhelpful layer between programmer and protocol.

Let’s get rid of the trivial but cumbersome mental translation you have to do everytime you want to think about the HTTP GET method, the URL, the index action, and the plural_path URL helper.

Let’s get rid of duplicate functionality already implemented in the controller. If you need to redirect, take action based on the user agent, or examine headers, that should be done in a controller!

And let’s start thinking in URLs, resources, and APIs instead of doing image caching in models or asset bundling in view helpers. That’s the controller’s job. It scales better, too.

Routes are unnecessary configuration.
The seven standard controller actions are legacy.
Become intimate with your URLs – don’t abstract them away.
Decrease the distance between thought and implementation.
Let the controller do its job.

Get Back to Thinking in URLs

A big part of the problem with a routing layer is that it abstracts the developer away from the URLs that define the application. This leads to poor API designs and convoluted solutions to otherwise easy problems.

This epiphany came while writing a few Sinatra applications. The exact URL for a handler sits right in front of my eyes as I write the code for it. I can’t ignore it.

As a result, I find myself spending more time thinking about how my URLs are designed. Should I be serving JSON from the same controller that serves the HTML interface, or should it be organized separately?

In contrast, you can write an entire Rails application without ever looking at a URL. The design of URLs is delegated to the framework, out of sight and out of mind.

This isn’t to say that we need to lose the good parts of how Rails works with URLs. URL helper methods like pancake_path(:id) are a great idea for reducing duplication and typos. They could be implemented apart from any router.

I love URLs. I dream about them at night. I think about them before I think about anything else. — Adrian Holovaty, co-creator of Django

* From Webstock 2009

Retire the Seven Action Names

It has been three years since the seven controller actions had any immediate meaning. The API no longer adds to the programmer’s understanding of the tasks at hand.

Experienced programmers know that inline comments mark code that’s too confusing or too clever.

Yet every Rails controller is generated with two lines of repetitive comments for every action. That’s a code smell! And a failure of API design.

Every Rails developer must memorize the table at right, mapping HTTP method and URL to the controller action name. If we can get rid of the action name, the rest of the table is already self-explanatory.

So instead of going through this extra syntactical layer, let’s deal directly with GET, POST, PUT, and DELETE. (Suggestions follow.)

You can tell this is a great idea because it’s the way unit tests already work! Let’s bring this syntax back to the controller and complete the API.

Method	URL	Action	Helper
GET	/pancakes	index	pancakes_path
GET	/pancakes/:id	show	pancake_path(:id)
GET	/pancakes/new	new	new_pancake_path
POST	/pancakes	create	pancakes_path
GET	/pancakes/:id/edit	edit	edit_pancake_path(:id)
PUT	/pancakes/:id	update	pancake_path(:id)
DELETE	/pancakes/:id	destroy	pancake_path(:id)

controller-comments.rb

# GET /pancakes
# GET /pancakes.xml
def index
end

# POST /pancakes
# POST /pancakes.xml
def create
end

test-with-http-method.rb

test "should create pancake" do
  post :create
  assert_redirected_to pancake_path(1)
end

Assets Are Resources

Thinking in URLs helps you solve web-related problems in the right way.

Exhibit A: If you deploy to a site whose view fragments are already cached in memcached, it’s likely that Rails’ asset caching view helpers will not be called and CSS bundles will not be generated.

# Caching shouldn't happen here
stylesheet_link_tag("a", "b", "c",
                    :cache => true)

This whole problem is easily solved by using controllers to do what they do best. Views and helpers should not generate URL-based resources.

The task of combining several CSS files into one file and caching them to disk is exactly the kind of task controllers are built to do³.

Controllers should generate and cache assets, not view helpers.

Idea 1: Sinatra

There are many ways the controller API could be improved. Existing attempts have failed to achieve wide adoption because they have tried to handle controllers, views, and models all at once⁴.

Instead, I think a more limited, controller-only approach could work better.

The first is already in wide use: Sinatra.

# Sinatra-style handler
get "/api/v1/report/:id" do |id|
  # ...
end

Sinatra is arguably the most widely replicated Ruby web framework, having inspired implementations in Node.js, Clojure, PHP, Scala, and many other languages.

Part of the problem with writing a routing API is finding a way to describe multiple URLs in a single string. This problem is solved if you handle each URL on its own.

There’s no middle routing layer with arbitrary action names. HTTP method and URL are all you need (but handlers can filter on the user agent or other header information).

Thanks to Rack, Sinatra apps can be embedded in Rails applications. Or, Carl Lerche is writing a Rails 3 plugin that provides this syntax to Rails controllers⁵.

Idea 2: Method, Member, Collection

Jamis Buck introduced an implementation of REST as a plugin four years ago. Yet unlike other areas of Rails that have seen massive improvements, Rails’ implementation of REST is basically the same as it was in Rails 1.2.

A halfway approach could combine elements of the Rails 3 router syntax with the class method style of configuration that’s already familiar to Rails developers.

# Class method and HTTP-style methods.
class ReportsController < AppController
  before_filter :authenticate
  resource "/api/v1/reports(/:id)"

  get(:collection) do
  end

  get(:member) do |id|
  end

  put(:member) do |id|
  end

end

Variations on this syntax could easily accomodate nested resources, singleton resources, or other custom URL schemes.

Conclusion

For several years, Rails has charged forward and defined new, innovative syntaxes for writing web applications. It’s time for it to happen again.

An improved syntax could get rid of stale controller actions, reduce confusion, reduce duplication, and improve the way we think about solving technical problems with web applications.

Reactions

Thanks to Reg Braithwaite and Ben Hoskings for feedback on this article.

Ben Hoskings said

I think the mere fact that a controller can be generated means that code shouldn’t be there. There’s no intelligence in code that can be generated from a single resource name.

I think it’s doubly important because once you free the controller from having to implement the specifics of each action (like models doesn’t have to implement the specifics of #save), you have a lot more room to raise the abstraction level and start getting declarative.

I think making the controller more declarative is probably the end goal. Instead of the bulk of each action being an imperative mess, the controller can be heavier on the class-level configuration that’s really proven itself in the model (associations, scopes, plugin configuration, etc.).

The provides class-level configuration directive in Merb/Rails 3 is a signal that controllers can head in this direction.

Thoughts and reactions? Reply to @topfunky on Twitter, write a blog post of your own, or comment at Hacker News.

¹ Video of Reg Braithwaite at RubyFringe. Quote is about 15:30 in.

² The original version by David Heinemeier Hansson, then by Ulysses, then by Koz and Jamis Buck (together), and most recently by Yehuda Katz, Josh Peek, and the Rails 3 team.

³ Sample controller code. Versioning and expiration of assets are easily solved by storing a version number in the application and appending it to the link tag.

⁴ See hammock by Ben Hoskings, make_resourceful by Hampton Catlin and resource_controller by James Golick.

⁵ Carl Lerche’s Astaire plugin.

Am I the Only One Who Uses a Text Editor to Edit Files?

Thu Mar 25 12:00:00 +0000 2010

This article is heavily styled and is best viewed at PeepCode!

Files should be navigable by file, class, or method name and show metadata useful for distinguishing between similar files (mockup).

If I had no experience with computers and were to guess which group of people had the best software tools to do their job, I would guess “computer programmers.”

And if I were to guess what task would have been extensively optimized, I would guess “opening files.”

If you are a programmer, you know that I would be wrong.

Last summer, Dave Peck wrote about his hopes for a modern, progressive, text editor.¹ I’d like to focus on one missing feature that’s absolutely possible today: powerful file navigation.

Keyboard

Perform any navigation task without touching the mouse.

Fuzzy Search

Find files by typing only a few letters.

Paths

Search includes folder names (relative to the project).

Metadata

File modification date and SCM status aid in file picking.

Beautiful

Terminal raster graphics don’t count! I want GUI beauty.

As every Vim user knows, most of one’s time spent in a text editor is spent editing, not writing (this is why Normal mode in Vim is the one you use for navigation and editing).

For most programming tasks, editing involves opening several files at once and switching between them (e.g. HTML/JavaScript/CSS).

I’m talking about three tasks:

Open any file on the computer.
Open any file in the current project.
Activate a file that’s already open in another tab.

And yet most text editors offload these important tasks to the operating system or implement half-hearted custom solutions. Even worse, third-party plugins frequently implement file-jumping functionality for different frameworks with unique, cryptic key mappings (e.g. between implementation and test or controller and view template).

This is a core task! Editors should approach it with the same innovation and care they spend on basic text entry.

TextMate

Keyboard

Fuzzy

Beautiful

Command-T with fuzzy search was revolutionary and was one of the main reasons I bought a copy of TextMate. But it breaks down for projects with many files of the same name (such as Ruby on Rails).

There’s no way to filter by directory.

Tabs are even worse. I frequently open more tabs than can fit on my screen, which means that both usability and the extra tabs get thrown out the window. The tab menu can only be accessed with the mouse and becomes a human-powered binary search of an unsorted list.²

Xcode

Keyboard

Beautiful

Xcode’s Open Quickly command (Command-Shift-D) only works with the exact file name starting with the first letter.

Xcode’s Open Quickly dialog

Many Cocoa developers store all their code files in the root directory of the project and rely on Xcode’s virtual directories for organization, which is the only reason it’s even barely usable.

Emacs

Keyboard

Fuzzy

Path

Emacs is the closest to satisfying my requirements.

The ido-menu provides fuzzy search, including pathnames. Chris Wanstrath’s textmate.el plugin³ wraps it in even more useful functionality, such as autodiscovery of a project root based on the existence of a .git directory.

Open buffers (similar to tabs) can be searched for by name (C-x b) or in a list (C-x C-b).

But the inline menu is an ugly paragraph.

A powerful search hidden behind a mess of text.

The only solution I can think of, so far,
Is to smash out the windows with a crowbar. — Buck 65

Once you start thinking about making file navigation better, the ideas flow freely. Could a dialog search on class or method names instead of just filenames? What about a free-form search for times and classes such as “yesterday Bacon#save”?

This article started with pain, developed into an idea, and ended up as an unexpected prototype implemented in MacRuby. I’m using it daily and am fine-tuning the interaction, visuals, features, and performance.

The app is now available as PeepOpen with a beautiful icon. Works with TextMate, Emacs, and MacVim.

For other updates, follow @peepcode on Twitter here.

The initial prototype performs a fuzzy search on paths and lists file modification dates.

You can contribute your own froth over the design and content of this article with the Neanderthals at Hacker News.

¹ Dave Peck sends supplication to the text editor gods.

² The RubyAMP bundle for TextMate shows a simple list of open windows, but without fuzzy search.

³ Chris Wanstrath’s textmate.el

About this Blog

Wed Feb 24 18:00:00 +0000 2010

This article is heavily styled and is best viewed at PeepCode!

Style

Each post is uniquely styled within a grid. ↓

Sinatra

Generates static pages and graphics. Styles code samples. ↓

No SQL

Not even a database! File-based metadata. ↓

Haml

Powers article templates and markup. ↓

SASS/CSS

Comprehensive and reusable styling. ↓

JavaScript

Taking it further…custom behavior & graphics. ↓

Style

Before there were blogs we had websites. Beautiful, random websites that felt more like a zine — one page looking nothing like the one before or after it.

Greg Storey, Airbag Industries¹

Many developments in computer science have nothing to do with the capabilities of computers, but with the way we use them.

A few years ago, an article on Airbag Industries¹ inspired me to think about writing a blog with a unique design per post.

There are many benefits:

It encourages creativity both at the computer and away from it
It’s like a code kata for design
You can easily experiment with cutting-edge CSS3 features or just learn CSS2
You’ll learn how to build a style foundation for other designs in other applications

On the downside, it takes more time than simply writing prose.

Building an art-directed blog may seem as easy as dropping an extra CSS link tag into every blog post, but a little extra work upfront makes it a lot easier.

First, I started with a layout grid in CSS. Grids have been used extensively in print design but have only recently become popular in website design. I like Tyler Tate’s 1kb grid² because it’s the simplest thing necessary to accomplish the task.

In standard website design, elements can be placed anywhere on a page. In contrast, a grid defines boundaries in regular increments, limiting the possibilities. Instead of stifling creativity, it encourages experimentation by making it easier to think about a finite number of widths for text or images.

I use a 12 column grid (double-click anywhere on this page to see it). Twelve columns are easily divided into other increments: 12 · 6+6 · 2+5+5 · 4+4+4 · 3+3+3+3

Sinatra

The Sinatra web framework has a beautiful REST API, can be extremely powerful, and is super fast.

It’s easily deployed with Phusion Passenger alongside my other Rack-based web applications.

I started with the Nesta⁴ blog engine and enhanced it with the additional CSS and graphic generation features I needed. All pages are cached statically with Sinatra::Cache⁵ for even greater speed. Although this blog could be generated with a static site generator, I find it more natural to write it in a dynamic style.

One example is the generation of text headline images with the Textorize⁶ renderer from Thomas Fuchs. I reference the images by URL in my CSS files. Sinatra generates the graphic on the fly when that URL is accesed (then caches it). Sinatra keeps URLs at the forefront of the web developer’s mind — where they should be!

Other resources are generated at the view level when needed. Code snippets are formatted by the Pygments⁷ command-line script via a special RedCloth tag implemented as a Haml filter.

Textorize (right half) renders text edges smoothly.

No SQL

metadata.yml

heading: About this Blog
heading-font: Klavika-BoldCondensed
heading-color: #000
heading-background: transparent
published: December 30 2019 at 6pm
categories: meta design
summary: An article about...
format: haml

.column.article
  %h2 Bacon

  :custom
    Haml and textile together...

It’s much easier to debug a visual design in development on the local machine, check the whole thing into Git, and deploy when ready. No need to write an authentication system or an article preview mechanism.

Article files are stored on disk with a bit of YAML-esque metadata at the top. Each article can be in Textile format, or can use the full power of Haml for more complicated markup.

Early on I needed to store information about the title’s font size and color. Later I needed to add other custom fields for additional tagging. With an ORM this would have meant writing a migration and installing a plugin to manage tags.

There was no such problem here! I just added a few key-value pairs to the article’s metadata and started using them in the application immediately.

Haml

Not only does each post get its own CSS, it can also specify its own HTML, via Haml⁸.

When I’m designing visually in the browser, I’m thinking primarily about blocks of text and images, and how they will be styled. I don’t want to be thinking about HTML boilerplate or need to hunt to find a matching end tag.

Haml decreases the mental distance between HTML and CSS. I work directly with CSS selectors no matter what file I happen to be in.

But Haml isn’t well suited to working with inline text. Fortunately, there’s Textile⁹ for that!

The differences between the basic syntaxes of Textile and Markdown are negligible. Where it pulls away from Markdown is when you add new tags of your own. You can write view helpers that take a simple string and turn it into a group of HTML tags. It’s not only faster to type, but I can build reusable elements for movie links, syntax-highlighted code snippets, pull quotes, and product boxes.

Textile enhancements are easily used inline within any Haml document. In RedCloth 4, the steps are:

Write a module with methods for each of the tags you want to use (such as movie at right).
In each method, examine the :text key in the options, then build and return an HTML string. I build links for the mov and m4v versions of each movie.
Write a Haml filter. The name of your module will be used as the name of the filter.
Extend RedCloth with your custom module.
Add more methods to your tags module as needed.

The code samples at right were built this way. I specify a path to a source file and it runs it through pygmentize. It also prepends a link to the source file itself.

The end result is a text system customized for writing about code, but it looks great, too! I can’t imagine using a CMS that was any less powerful than this.

textile_in_use.haml

.column.article

  %h2 Custom Filter Sample
 
  :custom_red_cloth

    movie. http://example.com/movie.mov

    source. /tutorials/code.rb

    buy. http://peepcode.com/products

custom_tags.rb

module CustomTags
  
  def movie(opts)
    my_text = opts[:text]
    # Build an HTML string around my_text
    # ...
    return my_text
  end
  
end

custom_haml_filter.rb

module Haml
  module Filters

    # Renders custom textile.    
    module CustomRedCloth
      include ::Haml::Filters::Base
      lazy_require 'custom_tags'

      def render(text)
        red_cloth = ::RedCloth.new(text)
        red_cloth.hard_breaks = false
        red_cloth.extend CustomTags
        red_cloth.to_html
      end
    end
  end
end

SASS/CSS

article_sample.sass

@import ../page_util
@import ../pygments_pastie

+masthead-reset
+dark-logo
+dark-masthead-menu

!base_color = #d1e3ff

.prose
  +grid_6
  float: left
  margin:
    left = !grid_gutter_width
    top  = !line_height*5

Archives page with screenshots

In a recent copy of Print Magazine¹¹, someone talked about designing a “style sheet” for the magazine back in the 70’s. For some reason, the extra space jolted my brain into thinking differently. Style. Sheet.

A stylesheet isn’t supposed to be a receptacle into which one tosses a bunch of unrelated visual directives. It’s a coherent guideline for how things should look. It should be planned and reusable. And like backend code, it may take several iterations of use in the real world to get it right.

SASS is a huge part of achieving that concept in this blog.

People get emotional when they hear about SASS. Either they see it as a threat to traditional CSS (used only by hacks who haven’t taken the time to learn it) or they welcome it as the best thing to happen to the Internet.

After working with this blog for a few months, I’m in the second camp.

As an example, any page can be designed with a light or a dark background. A few mixins at the top automatically adjust the page background, logo color (implemented as an image sprite), and menu colors. All these are contained in the stylesheet and don’t require any modification of the page’s HTML.

The technical parts of the grid and vertical rhythm are also wired into my SASS stylesheets. I can give elements meaningful names in HTML, then specify +grid_6 in SASS to make the element six columns wide (alternately, I could have used arguments like grid(6)).

Variables like grid_gutter_width and line_height are available to the whole application. I rarely type a number; instead I use meaningful variables to add margins or manipulate elements into position.

_grid.sass

And if I’m going to spend that much time in the powder room, I want to show it off. The archives page uses webkit2png.py¹⁰ to take a screenshot of each page and display it in a grid.

JavaScript

A unique design for each post is great, but how about unique JavaScript for each post?

For my Rails 3 upgrade screencast, I wanted to show a timeline of Rails release dates. I’ve recently become enamored with RaphaelJS¹² and it took only a few lines of code to import a JavaScript file for posts that want one.

I wrote a custom Timeline function that plots dates as large dots.

Conclusion

As with many features of this blog, it will take a while to figure out how to use them all fully. In the meantime, it’s a great learning experience and a fun output for creativity.

I haven’t published the source yet and may never. But now you have the ideas…implement them on your own blog!

In an earlier post, RaphaelJS was used to chart Rails release dates.

custom.js

jQuery(function () {

  var paper = Raphael("graph", 940, 81),
    timeline;

  timeline = new Timeline(paper, [
    {date:"06/25/2004", version:"0.5"},
    {date:"12/13/2005", version:"1.0.0"},
    {date:"12/07/2007", version:"2.0.0"},
    {date:"6/10/2010",  version:"3.0 ?"}
  ]);

});

¹ Airbag Industries wrote on the old days when blogs were designed like zines.

² The 1kb grid is the simplest thing necessary to get the job done. I convert it to SASS with the included css2sass command.

³ With a hack to ruby-mode in Emacs, I can easily jump to any Sinatra URL handler in a file.

⁴ Nesta is a minimal blog engine by Graham Ashton (but easy to extend). It’s built on the Sinatra web framework.

⁵ Sinatra::Cache source code

⁶ Textorize text renderer

⁷ Pygments is the best syntax highlighter out there. When you view diffs and code at GitHub, you’re viewing pygments. Pipe code to it on the command line.

⁸ The Haml template engine is available for Ruby and other languages.

⁹ Textile is a syntax for formatting prose.

¹⁰ webkit2png.py is a capable screenshot capturing script for Mac OS X. There’s a Ruby port, but the original works well enough that I don’t see the need. I’ve wrapped it in the osxscreenshot gem.

¹¹ Print Magazine is a classic (over 70 years in publication). Baseline Magazine is a more academic European counterpart. I recently bought a subscription to both.

¹² RaphaelJS is a JavaScript-based SVG drawing library.

¹³ The Plainview web browser is a full-screen browser, useful not only for HTML-based presentations.

What Pythonistas Think of Ruby

Wed Feb 03 07:00:00 +0000 2010

This article is heavily styled and is best viewed at PeepCode!

San Pueblan Milksnake

The very things I find ugly in Ruby are what make amazing Ruby software like RSpec possible, and that Python could never have (given the current implementation). Gary Bernhardt

I think Ruby's syntax is ugly until they do something glorious and beautiful with it like Rake, then I think "damn it!" Unidentified Attendee

Q: Does Ruby have a better inheritance system than Python?
A: I find inheritance distasteful. That's like asking me whether I would rather eat grasshoppers or tree bark. Gary Bernhardt

My perspective on Ruby was rocked last weekend at Northwest Python Day in Seattle.

Compared to other programming languages, Python and Ruby are so similar that hearing arguments between them is like trying to figure out which identical twin is more handsome.

But there are differences, and not only in the languages! The Seattle Python community represented there was almost painfully polite. People sat silently for 3-5 minutes between talks while the speaker plugged in to the projector. I rudely whispered to my neighbor, eager to discuss the ideas presented.

During the talks, people mostly sat and listened to the speaker. Many Ruby conferences in the USA are half full of hackers with laptops open, coding away at a project and jeering the speaker over IRC. Not here.

I later learned that this may be an attribute unique to Seattle Python developers. After all, we’re the city that gave the world the Uptight Seattleite and where drivers with the right-of-way stop to let cyclists turn left in front of them.

Python vs. Ruby, A Battle to the Death

The main attraction (and last presentation) was from my friend Gary Bernhardt¹. Gary spent a few months contracting on a Rails project for four hours in the morning and a Django project for four hours in the afternoon. So when he speaks of either, it’s not in ignorance.

At the end, I couldn’t find a single criticism of Ruby that I disagreed with. I did pick up a new appreciation for unique features of the Ruby language that I previously took for granted.

Matz Idolizes Larry Wall!

There was an audible gasp from the audience when Gary posted a slide with this quote from Matz:

Ruby inherited the Perl philosophy of having more than one way to do the same thing. I inherited that philosophy from Larry Wall, who is my hero actually.²

I’m not sure if the shock was from hearing someone embrace TIMTOWTDI or from learning that someone considers Larry Wall to be a hero.

If you open a python prompt and type

>>> import this

you’ll see the Zen of Python, 19 guidelines that Python programmers live by. One is “There should be one—and preferably only one—obvious way to do it.”

I do appreciate that Ruby is flexible enough to be used in many ways. That’s what makes the creativity and richness of Ruby libraries like Hpricot and Rake possible.

Parentheses Are Optional!

Gary pointed out that in most languages, appending parentheses to a variable that references a function, calls the function.

my_method = Proc.new { ... }

# ERROR: You can't do this in Ruby
my_method()

In Ruby, parentheses are a vestigial appendage. You could write an entire Ruby application without parentheses (and some do!). To Python developers, this is shameful.³

# In Ruby, you must use the call method
my_method.call()

I’m on the line here. I always use parentheses when defining methods, but use them infrequently when calling methods.

One’s aesthetic reaction to the following code snippets distinguishes the Rubyist from the Pythonista:

attr_accessor(:title, :slug, :body)
belongs_to(:article)
before_save(:encrypt_password)

get("/articles") do
  haml(:article)
end

And yet our repulsion at too many parentheses contrasts with Lisp’s influence on Ruby (which will be mentioned later).

They Monkey-Patch Object!

It’s well known that Pythonistas abhor monkey patching, a.k.a. duck punching,⁴ i.e. adding methods to existing classes.

They have a point. You can do a lot of damage in a few lines. Previous versions of ActiveRecord monkey-patched Logger, making it almost unusable for other applications that expected it to work in the standard way (it now behaves more civilly).

But without monkey patching, you can’t insert should and should_not into Object:

describe MySum do
  it "performs a sum" do
    sum = MyClass.add(1, 1)
    sum.should == 2
  end
end

So Python can’t implement the smooth syntax of RSpec.

Namespaces Run Amok!

The last line of the Zen of Python is

Namespaces are one honking great idea — let’s do more of those!

Python’s import statement gives you a high level of control over what code you’re bringing in to your application.

from django.db import models

In contrast, a Ruby require often slurps in other classes that seem entirely unrelated to the code you requested.

require 'active_record'
# => ActiveSupport is now in the global namespace

Having more control over the global namespace would be useful, but it seems to me that it would require a re-architecting of nearly the entire Ruby language.

Can I Have A Chainsaw Without So Much Lisp In It

My favorite quote of the whole presentation:

Ruby takes full advantage of the Lisp chainsaw.

Can I have that on a t-shirt?⁵

Python has no comparable equivalent to Ruby’s do end block. Python lambdas are limited to one line and can’t contain statements (for, if, def, etc.). Which leaves me wondering, what’s the point?

Without powerful blocks and lambdas, you can’t have Rake. You can’t have RSpec. You can’t have Sinatra’s clear REST syntax.

Without yield, you can’t have RailsCamp.

So the very features that make Ruby complicated to parse and potentially Perlish are the same features that can make it incredibly descriptive and flexible.

Not to mention the free Lisp chainsaw without all the parentheses!⁶

A Hacker News discussion about this article has over 200 comments here.

¹ Gary blogs at blog.extracheese.org and recently posted the audio and slides of the talk.

² From an interview at Artima

³ You can also call a Ruby proc with square brackets, but the crowd found that even more revolting.

⁴ Wikipedia on duck punching

⁵ Or just Lisp Chainsaw Massacre. Apparently this is a reference to Perl as a “Swiss army chainsaw.”

⁶ Personally, I don’t mind the parentheses. They can be rather comforting like a pillow.

Live Coding Rails 3 Upgrade

Mon Feb 01 12:00:00 +0000 2010

This article is heavily styled and is best viewed at PeepCode!

Rails release dates plotted with SVG. Javascript by Geoffrey Grosenbach (using RaphaelJS ). Data from Mike Gunderloy.

Free Screencast: Desktop iPod/Apple TV

Rails 3 Upgrade Handbook PDF

All You Need to Know
Only ^$12! More info…

NOTE This screencast covers an unreleased version of Rails 3 run from the source. Rails 3 Release Candidate 1 has been released and we’ll update this screencast when the final version is available.

For several months people have wondered, “Where can I download a video that features a developer stumbling through an upgrade of a Rails 2 app to Rails 3?”

I’m proud to say that an answer is now available!

In only 25 minutes, I convert my news screenshot site from Rails 2.x to Rails 3 (prerelease, from source).

It features the newest bundler (0.9.0.pre), Jeremy McAnally’s rails-upgrade script, new routes, Arel-based ActiveRecord queries, and more.

Stay tuned for the explosions at the end!

Resources

Nginx Development Script for Passenger

Tue Jan 12 12:00:00 +0000 2010

This article is heavily styled and is best viewed at PeepCode!

Free Screencast: Desktop iPod/Apple TV

Like most Rails developers, I incessantly tweak my development environment in pursuit of Nirvana. But like biological evolution, it’s not always an upward trend.

I recently jumped onto the Unicorn¹ bandwagon. It starts quickly and subjectively serves pages faster even in development (as does every technical modification powered by hope). But it can’t compete with Phusion Passenger when serving multiple assets simultaneously². Since many of my applications use dynamically generated graphics (or at least dynamic CSS with SASS), this can make a big difference.

But even with the minimal configuration needed to create a new Passenger app, it’s inconvenient for spontaneous apps or small demos. If I want to try out a Rails 3 application with Passenger, I don’t want to configure a new virtual host for just a few minutes of experimentation.

At RailsCamp 6, PeepCode author Pat Allan showed a beautiful solution. It’s a script that starts Nginx from any directory³ using a shared configuration file. I modified it ever so slightly and posted a screencast above with a walkthrough.

I store the script in my ~/bin directory so it can be called from any location:

nginx.sh

I use the following configuration file, stored in my source-controlled dotfiles directory.

nginx-dir.conf

Now that I’m back with Passenger for development, both visual modifications and backend code tweaks happen much faster. And I can fire up the server in any directory.

¹ Unicorn is a close-to-the metal Unix-based webserver written in Ruby.

² Phusion Passenger for Apache or Nginx manages multiple servers when more requests come in than can be handled. The result is faster delivery of assets to the client without the need to manually manage application server instances.

³ Pat’s original article shows how to build Nginx from source.

jQTouch Cheat Sheet

Wed Dec 30 18:00:00 +0000 2009

This article is heavily styled and is best viewed at PeepCode!

Markup: The core of a jQTouch application is the markup. Although you can use any HTML or CSS that you like, following conventions for class names and element structure offloads most of the work to the framework.

h1: A single HTML document contains many pages, each with an optional title inside the toolbar.

a.back: Just like native apps, pages are navigated in a stack. jQTouch handles backward navigation and animation if you include a back link in the toolbar.

Custom HTML: Although jQTouch includes styling for many elements, you don't have to use them! Style up your own interfaces with HTML and CSS.

ul: Lists make great menus or table-like displays. Add the rounded, plastic or edgetoedge classes to an unordered list for different styles.

Images: Stock and freeware icons are easy to use and can make your app look great. A 12px square icon works best. Try Helveticons, Glyphish or Eddit.

li.arrow & li.forward: Themes include classes for indicating the clickability of list items.

JavaScript Callbacks: Use jQuery to attach to the tap event. Or bind to pageAnimationEnd to add your own custom page behavior.

h2: Subtitles separate sections.

ul.individual: This class styles unordered lists as half-width buttons.

div.info: A styled div for auxiliary notes.

See the Movie!

70 minute screencast.
Only ^$9! More info…

Ruby, Emacs & Flog Metrics

Mon Dec 28 12:00:00 +0000 2009

This article is heavily styled and is best viewed at PeepCode!

Free Screencast: Desktop iPod/Apple TV

Learn Emacs!

One hour screencast.
Only ^$9! More info…

Summary: Flog metrics are often difficult to understand. The numbers can't be compared between projects or even classes. This editor enhancement helps by showing the flog score in the left column as you code.

Flog Score in the Column: This method has a flog score of 22 which can be seen in the column. It's more meaningful if compared to the scores of other methods in the same class. Larger numbers indicate greater complexity. If one method has a score that is significantly larger than others, it should probably be broken apart into several methods.

Repeated OR: The method repeats a conditional inline many times in the options. Refactoring the optional default value into the metadata method simplifies it and reduces the flog score in real time. (See the screencast linked above.)

Requirements: You'll need flog (sudo gem install flog). The source to flog is also available in several SCMs.

Code: → Get the code

Inspiration: Gary Bernhardt wrote the initial Python implementation for Vim and posted a screencast that shows it in action. Ignas Mikalajunas ported it to Emacs. I used numbers instead of colors since flog scores aren't absolute (it would be hard to calibrate numbers to colors).

The Expert Javascript Programmer

Sun Dec 06 22:00:00 +0000 2009

This article is heavily styled and is best viewed at PeepCode!

I spent the weekend reading Douglas Crockford’s essays on Javascript. He was an independent advocate for Javascript back when most programmers hated it. He was responsible for making JSON a standard for data interchange, even between completely different languages.

There are some classic essays in there and it only took a few hours to read all the articles on the front page. You can forgo the 90’s web design style by using the Readability bookmarklet either on the desktop or mobile¹.

I use style: novel, size: large, margin: narrow.

If you don’t use Javascript, you’ll learn some valuable lessons from a skilled programmer and tech visionary. If you do use Javascript, you’ll learn a lot about how an enthusiast uses the features and shortcomings of the language to their best effect.

His opinionated decisiveness and surly delivery produce some real chestnuts.

It helps to periodically remind oneself of these clear truths.

At least one other clear truth emerged while reading. It surprised me that many of his style recommendations were precautions against elementary programming mistakes. For example, he recommends that Javascript programmers always use brackets with an if statement even if the body consists of only a single statement.

if.js

// Possible error
if (a === b)
  c = d;
  e = f;

// Recommended
if (a === b) {
  c = d;
}
e = f;

I don’t think I’ve ever accidentally misused a one-line if statement. A grizzled verteran like Crockford would certainly never make that mistake either.

My epiphany was recognizing the contrast between two ways of approaching a programming session. One says “I’m experienced and I can trust myself to write flawless code.” The other says “I’m likely to make a mistake at some point and will take precautions against errors.”

Novices in many fields look at experts and rightly observe that experts don’t use the same training wheels that novices do. The (erroneous) conclusion is that experts don’t need any.

But in reality, experts often use more aids than novices. The skilled craftsman doesn’t see these as insults to one’s intelligence but as a tool for achieving perfection.

Skilled woodworkers build a jig before cutting a piece of wood.

Graphic designers start a layout by drawing a grid to contain the contents.

Professional vert skateboarders wear helmets.

And experienced programmers adopt habits that guard against elementary errors.

¹ Unfortunately, the Readability bookmarklet also changes the spacing on some code samples in the essays.

The Sound of No Command

Thu Dec 03 12:00:00 +0000 2009

This article is heavily styled and is best viewed at PeepCode!

Free Screencast: Desktop iPod/Apple TV

Learn the Shell

Basic & Advanced
Only ^$9! More info…

On the last night of RailsCamp 6 I hosted a show and tell of shell commands.

I always love seeing what aliases, functions, and techniques other people use. And I hope that people will find something useful from mine.

drnic-inputrc.sh

Earlier in the weekend, Dr. Nic showed me an inputrc he uses with bash that searches his command history like command-r but uses the up and down arrow keys. You just start typing part of a command, then hit up-arrow and it shows the previous command that starts with the string.

~~Unfortunately, I couldn’t get it to work with zsh.~~ Alexandros Podaras sent in a zsh-compatible version.

It only searches the beginning of commands, not the entire command including arguments.

Bo’s Method Missing

fish_method_missing

Bo Jeanes took it up a notch with a method_missing-type handler for the fish shell.

He can do things like paste a bare URL into the terminal and it will download the file and untar it for him automatically. Git URLs will be cloned automatically. There is also an artificial shortcut for running Cucumber stories by typing just the name of the feature file.

I discovered that both zsh and bash have similar capabilities! Oddly, it only works with zsh on Snow Leopard, not Leopard OG.

bash-command-not-found.sh

For bash, use the trap handler and shell_method_missing script found at right.

shell_method_missing.rb

For zsh, write a function called command_not_found_handler that calls a custom Ruby script. The Ruby script will try to find the intended command and run it.

command_not_found_handler.sh

# For zsh. Add to your .zshrc
function command_not_found_handler() {
  ~/bin/shell_method_missing $*
}

I’ve modified the shell_method_missing.rb script to easily clone repositories from GitHub. Type the name of a user and the name of a project:

% bjeanes dot-files.git
=> Runs "git clone git://github.com/bjeanes/dot-files.git"

I can also install gems by typing the name and a .gem suffix.

% haml.gem
=> Runs "sudo gem install haml"

Currently, my zsh settings intercept git and http URLs and don’t pass it onto the command_not_found_handler. I haven’t figured out how to work around this yet.

One could go wild with the possibilities:

Run specs by name
Run rake tasks
Deploy a website by typing staging or production

Try it out!