Nick Sieger: Category rails

Rails is simpler than Office

Nick Sieger — Fri, 26 May 2006 03:32:00 +0000

Before my big blog drought at the beginning of the year, I had an entry queued up talking about some success I’d experienced with Rails. A lot in the Rails world has progressed since then, but I still think the story is worth documenting. Also, the code to generate a PDF of mailing labels may be useful to somebody out there.

I’ve had some Rails success lately building a home-use mailing list manager/rolodex application. There are plenty of ways that such a list could be maintained without resorting to a full web application framework such as Rails, but what the heck! The mailing list started life as an MS Access database; after my work computer was re-imaged I no longer had “access to Access” so it had a temporary layover in an Excel spreadsheet. Within the past couple of months I had moved it to a MySQL database as a way to nurture my fledgling Rails efforts.

Ok, so nothing real special so far, except that in order to print mailing labels (one of the primary reasons for keeping such a list) I’d have to export the names to a .csv file and do a mail merge with Word. Until the most recent mailing.

On a Saturday night I had the brainstorm to use Austin Ziegler’s PDF::Writer library to create a printable PDF directly from the Rails app, thus skipping the need to go through the mail merge rigamarole. Only a couple of hours of effort later, I had my mother-in-law’s Christmas mailing list printed out! Anyone who has ever done a mail merge with Word knows that clicking a single link to create the printable versions of the mailing labels is a huge improvement in usability. And finally, no MS bits were harmed in the production of this mailing!

My starting point in building the code to generate PDFs was this page in the Rails wiki. I decided to use the method that describes installing an “rpdf” template handler. Nowadays, you may as well use Josh Charles’ Rails PDF plugin, but for posterity I’ve packaged up my effort as a simple plugin as well (install into an existing Rails application with ./script/plugin install http://svn.caldersphere.net/svn/main/plugins/pdfrender).

With the plugin in place, all that’s necessary is a controller method to set up the data for the view, and the view code itself. The controller is as straightforward as you’d expect:

class AddressController < ApplicationController
  # ...

  def pdf
    @addresses = Address.find(:all, :order => 'last_name, first_name')
    render :layout => false
  end
end

The view code is a little more hairy but with a little thought the dimensioning and layout code could easily be DRY’d out.

FONT = "Times-Roman"
FONT_SIZE = 12

COLS = 3
LABELS_PER_PAGE = 30
LABELS_PER_COL = 10

# margins: .5in top & bottom, 0.19 in left and right
# table column widths: 2.63in | 0.13in | 2.63in | 0.13in | 2.63in
# table rows: 1in height

MARG_X = pdf.in2pts 0.19
MARG_Y = pdf.in2pts 0.5

CELL_Y = pdf.in2pts 1
CELL_X = pdf.in2pts 2.63

COL_PAD_X = pdf.in2pts 0.19

COL1_X = MARG_X 
COL2_X = COL1_X + CELL_X + COL_PAD_X
COL3_X = COL2_X + CELL_X + COL_PAD_X

CELL_PAD_X = pdf.in2pts 0.13
CELL_PAD_Y = pdf.in2pts 0.25
CELL_LINE_Y = FONT_SIZE + 2

def cell_x(col)
  [COL1_X, COL2_X, COL3_X][col] + CELL_PAD_X
end

def cell_y(row, line)
  MARG_Y + ((LABELS_PER_COL - row) * CELL_Y) - CELL_PAD_Y - (line * CELL_LINE_Y)
end

def add_label(row, col, addr, pdf)
  if addr
    pdf.add_text_wrap(cell_x(col), cell_y(row, 0), CELL_X, addr.name, FONT_SIZE)
    pdf.add_text_wrap(cell_x(col), cell_y(row, 1), CELL_X, addr.address, FONT_SIZE)
    pdf.add_text_wrap(cell_x(col), cell_y(row, 2), CELL_X, "#{addr.city}, #{addr.state} #{addr.zip}", FONT_SIZE)
  end
end

pdf.select_font(FONT)

pages = @addresses.length / LABELS_PER_PAGE
pages += 1 if (@addresses.length % LABELS_PER_PAGE) > 0

0.upto(pages - 1) do |page|
  start = page * LABELS_PER_PAGE
  address_page = @addresses[start..start+LABELS_PER_PAGE]

  0.upto(LABELS_PER_COL - 1) do |row|
    add_label(row, 0, address_page[row*COLS], pdf)
    add_label(row, 1, address_page[row*COLS+1], pdf)
    add_label(row, 2, address_page[row*COLS+2], pdf)
  end

  pdf.new_page unless page + 1 == pages
end

And that’s it! Avery labels in Rails!

RailsConf begins

Nick Sieger — Fri, 23 Jun 2006 14:10:00 +0000

I got lucky with a last minute ticket and found a way to get to the First International Rails Conference in Chicago.

That’s me, hope to see you this weekend!

RailsConf: Dave Thomas keynote

Nick Sieger — Fri, 23 Jun 2006 15:12:00 +0000

Dave Thomas, Professional Cassandra

Intro

Dave starts by dissecting a google search and pointing out how the sponsored links sidebar contains a wealth of paid ads for various topics:

Hosting
Consulting
Commercial IDEs and tools
Alternatives to RoR!

Moving on to rubyforge, Dave examines some download stats, and points out that there have been 536835 downloads of Rails through gem install rails

Dave examines some Google trends mapping of ruby on rails vs the following, showing RoR catching up on some and overtaking others:

websphere
jboss
tapestry
spring framework
zend

3 Problems for Rails

Dave proceeds to give his own, tailored for Rails, version of David Hilbert’s famous “23 unsolved problems”…except due to time constraints, can only discuss three.

PDI

An acronym, PDI, has emerged on the Rails core team as a way to encourage people to contribute. Please Do Investigate

The challenge is to get new features to be proved out in the community before taking it into the core, the Rails core team is only 12 and has limited bandwidth, and that is the idea behind PDI

The three problem areas are:

Data integration
CRUD
Deployment

Data integrations

Dave mentions that he and David “disagree mildly” on the point of using constraints in the database.

automatic validation based on schema
work with foreign keys - make it easy to define in a migration
add a “belongs_to” relationship if a foreign key constraint is detected
primary key support, e.g., non-integer keys, particularly in migrations, and composite primary keys

The argument here is that real-world applications, and legacy databases today require these features, and Rails needs to be able to have answers to those questions if it wants to be viable in that area.

Dave is asking for distributed transactions now. Should we be pushing Rails into such an enterprisey direction? If you really need XA transactions, shouldn’t you be banished to a java world?

Non-database models would be a fabulous addition to rails. ActiveRecord::Base currently assumes that it’s talking to a sinle relational datastore. If we could integrate multiple disparate data soures, it would make integrations, REST data sources, and mashups much easier. Microsoft is doing this with LINQ today, and if Rails wants to keep up, it will need this.

Real-world CRUD

Dave is arguing that we should beef up scaffolding and make it useful. Scaffolding was the star of the initial 10 minute Rails video that started everything, but yet it’s the ugliest web 1.0 interface ever! No AJAX, no automatic, DRY, in-browser validation. But should we, can we really genericize these interfaces? Maybe a scaffolding widget/component system? It can and probably will happen, but at the momet I’m inclined to think that this will complicate things. Do we want Rails view to turn into Wicket widgets or ASP.NET components? It’s a completely different way of writing web programs. We’ll have to see how it plays out.

Deployment

Dave argues for improved deployment. Yes we have Capistrano, and it’s arguably the best web deployment mechanism in existence, but the web of knowledge required to deploy a Rails application is too large, varied and unwieldy.

Capistrano is a push model, ideal for small shops where the developers manage and maintain everything, but it’s not the real world. Larger shops have separate development and admin departments. They have stricter requirements for where files go, pre and post-deployment hooks, roles, passwords, security, etc. Capistrano currently falls down a bit in this environment.

Dave discusses cap --deploy-on: a hypothetical extension to Capistrano that would allow staged deployment to multiple servers, and the possibility to introduce workflow between developers and administrators. What if ISPs had a standardized infrastructure that would allow hobbyists to issue a cap --deploy-on and instantly have their apps running up on TextDrive, DreamHost, etc. To go further, what if we could deploy from rubygems? gem deploy <name> --on cap://my.isp.com. Typo installation would literally be a single command.

Closing

All developers need to be happy, so let’s make their lives easier!

RailsConf: Mike Clark -- Introduction to Capistrano

Nick Sieger — Fri, 23 Jun 2006 16:45:00 +0000

Introduction to Capistrano

Mike Clark has been Java-free for 15 months and 16 days. He’s here to talk about deployment with Capistrano.

First off, props to Jamis! There are several hundred people in the room and it’s a tribute to him.

Capistrano is about making it easy to deploy web applications. “Cap”, the short name has quickly become jargon in the Rails community. “Stop wasting time, just cap it!”

Capistrano is built to scale. From a single machine all the way up to clusters, it is intended to make application deployment as simple as the push of a button. That’s priceless for reducing friction as your project nears its first production live date, as well as subsequent maintenance releases.

Configuring Capistrano - create a recipe

Set the application name

set :application, "depot"

Set the repository

set :repository, "http://svn.yourhost.com/#{application}/trunk"

Roles

role :app, "app01.example.com", "app02.example.com"
role :web, "web01.example.com", "web02.example.com"
role :db, "db.example.com", :primary => true

Deployment Root

set :deploy_to, "/Library/Rails/#{application}"

Setup

Run cap setup once to setup the deployment directory structure on all the roles you’ve configured:

depot
  `- releases
  `- shared
       `- log
       `- system

First time deploy

Run cap update_code symlink. This checks out the code, adds a “current” symlink to the code on the remote machine that points to the timestamped releases directory where the code was checked out. You can then manually start your web server(s) if you wish.

New Release

Run cap deploy. The newly committed code to your repository gets pulled, a new release created, and it also restarts fcgi processes.

Rollback release

Run cap rollback. The “current” symlink gets updated to the previous release, and the fcgi processes get restarted.

Scheduled downtime

Run cap disable_web. A maintenance screen is put up during the maintenance period. This is great when you’re in firefighting mode and you don’t want to think, just get the page up there. To enable again, use cap enable_web.

Customization

Here are examples of several useful, real-world tasks. The fourth task shows aggregation of tasks together.

desc "locate ruby"
task :which_ruby, :roles => [:app] do
  puts "You're running:"
  run "which ruby"
end

task :current_revision do
  run "echo Current rev is #{revision}"
  run "echo Current rev is at #{releast_path}"
end

task :uptime, :roles => [:app, :web, :db] do
  run "uptime"
end

task :status do 
  which_ruby
  current_revision
  uptime
end

Channels and streams

Mike showed a log file tailing task here. I failed to capture the full task code, so you’re on your own here.

Hooks

task :before_deploy, :roles => [:app] do
  cleanup
end

task :after_update_code, :roles => [:app] do
  production_config = "path/to/database.yml"
  run "cp #{production_config} #{current_path}/config/database.yml"
end

Multiple configs

if where == "production"
  set :user, "ops_gal"
else
  set :user, "dev_guy"
end

Task libraries

You can creat a file full of extra, reusable tasks and simply require them in. The files can be published and installed as gems or placed anywhere on your load path.

Capistrano isn’t just for Rails

It’s great at shuttling files around and executing remote commands on the server. Mike describes some automation James Duncan Davidson did to replicate new servers into a cluster with the push of a button.

Assumptions

Capistrano, out of the box comes with some assumptions:

Remote servers talk POSIX
Same deploy structure and password on each machine
Web application uses FastCGI with Apache or Lighty

It looks like you can bend some of these assumptions if you are willing to write your own custom deployment tasks.

Take Home

Capistrano provides easy, consistent, worry-free deployment of new releases. The friction to deploying your app just got simpler, so you can go enjoy your life!

Notes and Questions

Can you use SSH public keys to authenticate? Yes, this is the most typical scenario.
You can use sudo to execute remote commands – this is built-in.
Can you/would you want to check out subsets of files on each server, rather than pulling all the code everywhere? So far most of our stuff has been on the same server, so this hasn’t been an issue. It seems like you would need to override deployment tasks for some roles.
Sometimes I want to deploy a lot, but what if the app is big, lots of media files? It can take a longer time to pull all the code. One solution I’ve seen is to check out once and rsync everywhere else. I haven’t had to do that myself.
Who can I talk to for promoting my own extensions into Capistrano. You probably don’t. Instead, publish your extensions, blog them, and see if it takes.
deploy_with_migrations – use with caution as it’s not as easy to rollback, and not all migrations can be rolled back cleanly.

RailsConf: Stefan Kaes - Rails Performance

Nick Sieger — Fri, 23 Jun 2006 20:40:00 +0000

Stefan starts by citing a factor of 4-5 improvement in performance in Rails over the last year.

Performance, broken down

Latency – how fast
Throughput – how many
Utilization – how idle is the cpu
Cost efficiency – performance per unit cost

For completeness calculate the min, max, mean and standard deviation of these metrics and use the deviation as your guide for how reliable the data is.

Tools

Log files (level > Logger::DEBUG)
Rails Analyzer Tools (Eric Hodel)
Benchmarker (script/benchmarker)
DB vendor tools
Apache bench (ab or ab2)
httperf
railsbench (Stefan Kaes)

Railsbench

Railsbench measuress raw performance of rails request processing. It’s configured using config/benchmarks.yml and config/benchmarks.rb. These files let you control which requests get benchmarked, whether to create a new session when benchmarking them, etc.

Profiling Tools

Ruby Profiler
Zen Profiler
rubyprof
Rails profiler script
Ruby Performance Validator

At this point Stefan gave an overview of RPV, which appears to be a nifty tool that lets you get typical hotspot tree views of where time is spent in code. It currently only runs on Windows.

Session containers

In memory – if you server crashes…oops. Also doesn’t scale.
File system – easy to set up, scales with NFS, but slower than…
ActiveRecordStore – easy to set up since it comes with Rails, but much slower than…
SQLSessionStore – which uses the same table structure as ActiveRecordStore, but was written by Stefan to overcome performance issues with ActiveRecordStore. Setup is more involved.
memcached – slightly faster than SQLSessionStore, scales best, but setup is also more involved.
DrbStore – distributed ruby store

Caching

Full pages – fastest, complete pages are served on the filesystem. Web server bypasses appserver for rendering. If you have private pages, you can’t use it.
Actions – pages are cached after an action is rendered. The user ID can be used as part of the storage key.
Fragments – fragments can be cached in memory, on the file system, in a DrbStore, or in memcached. Memcached scales the best but doesn’t support expiring fragments by regular expression.

ActionController

Stefan recommends avoiding components, and replacing them with helpers or partials. He has not found a use for them.

ActionView

Don’t create unnecessary instance variables in the controller; creating them in the view with instance_variable_set and accessing with instance_variable_get is slow.

Helpers

pluralize – don’t use the inflector if you don’t need to, it’s expensive.
linkto and urlfor are among the slowest helpers, since they need to use routes. Instead, if you have page with lots of links, you might consider hard-coding the links. This reduces the amount of GC by up to 50% and the GC time down by a few percentage points (11.3% to 8.7% of total processing time).

ActiveRecord

use the :include option to prefetch associations, it avoids extra onesy-twosy SQL statements.
use piggy-backing plugin for has_one or belongs_to relationships – allows you to retrieve extra attributes from additional tables in the same fetch query.
Field values are retrieved from the DB mostly as strings, so type conversion happens on each access, which can be slow.

Language-level and miscellaneous issues

Method calls are the slowest – don’t needlessly create method abstractions
Short-circuit intermediate results to improve performance
Cache results in instance variables or class variables
Don’t call ObjectSpace.each_object on each request

Ruby Memory Management

designed for batch scripts, not long-running servers.
no generational garbage collection.
this is suboptimal for Rails because ASTs are stored on the heap (biggest portion of non-garbage for Rails apps), and get processed/traversed more often than they need to be
Railsbench includes a patch to allow one to recompile Ruby and tweak the garbage collector.

Rails Template Optimizer

Stefan has started a project to “compile” templates.
The idea is to cache results of some ERb scriptlets and essentially “compile” or replace the template with one that has more expressions expanded or inlined.
Code forthcoming; I assume you can stay tuned to Rails Express for news.

Questions

There was a question on JRuby – Stefan replied that it would certainly solve GC issues, but he doesn’t know if it’s in a state to be able to benchmark Rails requests.
What are your recommendations for a web server. I don’t have any.
Is horizontal or vertical scaling better? I don’t know, I’ve been focused on making single requests go fast, so I don’t have enough experience.

RailsConf: Amy Hoy - Overcoming Scaffolding Addiction

Nick Sieger — Fri, 23 Jun 2006 21:43:00 +0000

Scaffolding is not a swiss army knife, it’s more like a rusty spoon. It’ll give you tetanus! Scaffolding leads to brain atrophy and laziness. Leads to bad code, bad UI, etc. Instead, start from scratch. script/generate is not inherently bad, it can write necessary, tedious code for you.

script/generate controller kitten create view put_to_sleep

This gives you:

class KittenController < ApplicationController

  def create
  end

  def view
  end

  def put_to_sleep
  end
end

Amy proceeds to break down a from-scratch, minimalist set of views, to underscore the point that it’s not too hard to not use scaffolding. I’d agree, it was so straightforward that unfortunately I’m going to omit the details here. Rolling your own without scaffolding is highly recommended.

Some of the items that you generally will experience in real world apps but do not come in scaffolding are widgets for maintaining relationships. Select lists based on a belongs_to, checkbox groups for has_many are two examples.

Amy breaks these down as well and it turns out they’re pretty easy to do. One snippet of code for updating checkboxes was succinct and surprisingly readable, and made judicious use of the ruby array’s - behavior to add newly checked and remove newly unchecked items quickly.

Amy promised to post snippets and slides later on her blog, so go over to slash7 for more.

RailsConf: Obie Fernandez - Thoughtworks on Rails

Nick Sieger — Sat, 24 Jun 2006 15:15:00 +0000

Is anyone doing “real” projects in Rails? Obie’s talk is the answer to this frequently received question.

Twix, the first Rails project at Thoughtworks was an internal tool that functioned as an introduction to the technology and began the evangelization process for Rails within Thoughtworks.

Apparently DHH and Roy (the owner of Thoughtworks) hit it off when DHH said to Roy in a meeting, “I want to change the world.”

The Deere project started as a supply-chain application built on Java that took 6 weeks to get up and running. Rails was sneaked in as a tool to help business owners generate sample data for the main application. The interface was simple, and made it fun for the users. It generated quite a stir, with one of the customers exclaiming that it was better than the app they already had!

This led to Deere COA (Certificate of Analysis). There was a sticky-note, user-centered design, task analysis session that helped to drive what form the application would take. The resulting implementation took about two calendar weeks, eight person weeks. Obie’s comment at this point was that the amount of time was on the order how long it usually took the client just to decide that they wanted to do something.

Later, as maintenance of the tool was being handed off to some internal developers, Obie gave a brief presentation on Rails to some of the client stakeholders. When he returned to finish training on the technology three months later, he found that a product manager (somewhat non-techie) had built a time tracking application during his two-week family leave that subsequently received a lot of attention at the office. A project manager was asking him to help fix a bug with the application that had already been deployed and in use for three months, and the company wanted to roll it out for use to several thousand people at the company.

The story about the Kiosk project highlighted that agile and XP methods fit so well with Rails. Obie described one case where they brought their usability expert in for a review and Rails allowed them to make changes to the UIs as fast as the usability person could point them out.

Note: Q & A is paraphrased.

How can you transform a client’s thinking about technology and acceptance of Ruby and Rails so that when you leave, they own it? Find a common thread of command-line, text-based development, or experience with similar languages. Most skilled programmers can pick up Rails in days or weeks. Your miles may vary but it goes with the amount of talent you’re working with.
Comment on RadRails. Code completion is overrated, it keeps you from solving the problems in your head because the editor is feeding alternatives to you.
Comment on deployment. The reason you can’t do Ruby on Rails is that it’s not a supported technology in our data center. Politics, status quo, not important, blah, blah. We ended up doing the app anyway, and the data center people said, “sure you can do it, we’ll give you a VPS”.

RailsConf: Steven Hammond - DSLs and Rails Plugins

Nick Sieger — Sat, 24 Jun 2006 16:18:00 +0000

Intro

Steven talks on the whats and whys of domain specific languages.

Steven’s background is is as a java developer and more recently, a project manager, or “sith lord” as he put it.

Some early exposure to DSLs for him involved the use of something called Program Composition Notation that was used to describe a weather modeling program to be run on massively-parallel supercomputers.

Features of DSLs

Usually a partial programming language focused on a single problem domain.
Replicate syntax/structure that is common to users of that domain.
Tries to be as elegant, concise and expressive as possible in that domain.

Horizontal vs. Vertical

Horizontal – programming problems (e.g., Rails migrations)
Vertical – business domain problems (e.g., a game DSL, insurance product definition, circuit board specification)

Recipe example

Steve contrasted a procedural, C-style recipe vs. a Ruby-based DSL that used blocks to delineate ingredients from procedures. The differentiating point was “which one could your mom translate into meatloaf”? I suppose neither if you don’t like your mom’s meatloaf.

Rails DSLs

The framework itself (“is the whale shark a fish?”)
Migrations
RJS templates
Plugins
- acts_as_state_machine
- RESTful Rails
- game_dsl

When to create a DSL

established syntax or vertical domain
soemthing that’s inelegant in normal imperative or object-oriented style
abstract implementation details so that you don’t depend on them (e.g., migrations does this for database DDL)
reuse

DSLs and Reuse

“Reuse is vastly overrated” – DHH in 1/2006
- Business logic is very application specific and is difficult to reuse across projects
- Level of reuse is at a lower lever where there is an information barrier to understanding the component (e.g., LINPACK)

Designing a DSL

Be careful to balance forward-looking with extraction. In other words, DSLs should be extracted or driven by need just like anything else.
Layout a domain syntax (not necessarily in Ruby)
Extract and evolve over time
Translate business requirements/statements into succinct programming fragments. (e.g., rolling dice and assigning attributes)

# extending Integer to deal with die-rolling
3.d6
3.d6 :keep_best => 3

# Deck-dealing example
class Tile < AciveRecord::Base
  acts_as_deck
end

class Player < ActiveRecord::Base
  acts_as_player
end

class DeckController < ApplicationController
  def deal_cards
    @deck = Tile.find :all
    @deck.shuffle
    @card = @deck.draw
    @deck.deal :cards => 6, :to => @players
  end
end

There was a discussion at this point about whether it was necessary to use a DSL in this case, and Obie Fernandez piped in that if you’re aiming for reuse or as an API, DSLs give a readable, understandable representation that makes reuse and sharing easier.

Another comment was regarding namespace collisions, and Steven replied honestly that there is not a good answer. If you combine a game-playing DSL with a home-building DSL, are you randomizing your porch?

YAML provides another good medium for succinct data layout (e.g., database.yml). Steven’s example followed the same pattern to apply to selecting different sources for a random number generator.

Pitfalls

DSLs should not necessarily be the first solution – the domain could be too narrow or too broad.
Too many DSLs (or even plugin bloat) could end up compromising the readability of the code. Namespacing comes in here. Which DSL/plugin provided the given functionality?
Interaction side-effects – it’s not clear how mixing metaphors can make the solution clearer.
Vertical DSLs additionally suffer from the problem that it’s still programming, and there are syntax issues to overcome, even though the DSL can faciliate interactions with the customer.

A comment came from Aslak Hellesoy about the use of external DSLs (i.e., built using parser generators). Steven replied that it is appropriate in some cases, but the complexity will be higher.

It seems to me that in the case of external DSLs, the freedom (lack of constraints) can actually be a burden. You can design syntax however you want but you need to be sure that it makes sense to the people who will be using it. Unless you’re really good with language and interface design it can be easy to create a custom, niche language that nobody knows anything about and is inflexible. In my experience it’s hard to use parser generators like yacc to build flexible parsers. Ruby turns out to be really good for DSLs because you can omit details (parentheses and hash curly braces) and it still does what you want.

RailsConf: Bill Katz - Metaprogramming Writertopia

Nick Sieger — Sat, 24 Jun 2006 17:27:00 +0000

Bill Katz took a code-focused approach to explaining metaprogramming and DSLs.

Resources

http://www.writertopia.com/developers has an authorization plugin used in writertopia, which is the main focus of this talk.
http://www.simbiome.org and https://wimtk.org/svn/simbiome contain code for physics based simulation resources.

Bill applies Paul Graham’s quote on bottom-up design and lisp as justification for using Ruby to program DSLs.

Authorization plugin

In search of a better authorization scheme, Bill wanted an elegant syntax using blocks to delineate sections of code that require specific permissions, and a more intuitive way of managing the data surrounding access controls.

current_user.has_role? "moderator"
current_user.has_role? "member", workshop
workshop.accepts_role? "member", user

current_user.is_moderator_of workshop
user.is_eligible_for? campbell_award

Implementing `permit`

class MeetingController < ApplicationController
  permit "rubyists and wanna_be_rubyists", :except => :public_text

We need a class method. Where to put it? How does this work? (Insert pretty diagram of instance, singleton class and superclass here.) Metaclassees are “anonymous”, you don’t see them by looking at class ancestors.

ActionController::Base.send(:include, Authorization::Base)
ActionView::Base.send(:include, Authorization::Base::ControllerInstanceMethods)

Singleton methods from the point of view of the object are the same as instance methods in the metaclass. See slides on “How do we permit?” for details. Bill chose to tuck the DSL-related methods into modules and used self.included, class_eval and other goodies to set up the methods in the correct places. There is more than way to do this but I suspect Bill chose to do it for purposes of cleanly separating concerns along the lines of where in the class hierarchy the methods live.

ActiveRecord::Base.send(:include,
  Authorization::ObjectRolesTable::UserExtensions,
  Authorization::ObjectRolesTable::ModelExtensions)

This loads an acts_as_authorizable plugin which, when used in a model, inserts an accepts_role family of methods for querying and setting user roles.

Bill blazed through a whole lot of pretty-looking code here for how to set up the DSL infrastructure. You’ll have to go over to the writertopia developer link to see it. Bill has said he’ll post his slides online as well.

Questions

Use of method_missing – does that clash with ActiveRecord::Base usage of method_missing? No, as long as you use super to invoke the next method in the chain, you’re ok. Ruby module inclusion semantics handle this for you.
How to insert the class methods? A discussion started around ActionController::Base.send(:include, ...) and There is More Than One Way to Do It.

ActionController::Base.send(:include, Authorization::Base)

class ActionController::Base; include Authorization::Base; end

ActionController::Base.class_eval { include Authorization::Base }

Question about the class inheritance chain. There are actually two inheritance chains, one for the classes and one for the metaclasses. Resolution at method invocation time travels first to the object’s metaclass, then to the object’s class, then to the superclass of the singleton class, then the class’s superclass, etc. Blech, that makes no sense. Instead, go read Seeing Metaclasses Early.

RailsConf: Ezra Zygmuntowicz - Rails Deployment

Nick Sieger — Sat, 24 Jun 2006 19:18:00 +0000

Ezra: Programming in Ruby for 3 years, Rails for 2. Just another Ruby hacker, he says. Right!

Yakima Herald

http://yakimaherald.com – Local newspaper website
CMS
Lots of non-SQL content
Classified and obituary workflow
Internal credit card transaction

Data Aggregation

Mysql
XML feeds from AP
RSS and Atom feeds from parent newspaper
Proprietary database for articles
- Yucky Vendorscript
- Crusty OS 9 server!
- Wrote DSL to emit script over a socket to remote machine

Deployment

Apache? Seems to be the industry standard…

class ApacheWithFCGI < ActiveRecord::Base
  has_many :random_500_errors
end

Lighttpd
- Better FCGI support
- More stable
Switched to standalone, external FCGIs with capistrano spinner/spawner/reaper tasks, and finally got stable.

Tuning

Cache, cache, cache
Got RAM?
Hot spot/profiling/benchmarking
Use httperf not ab
See Zed Shaw’s rant on statistics (Programmers Need To Learn Statistics Or I Will Kill Them All)

Shared hosting

Apache with ProxyPass/ProxyPassReverse talking to multiple lighty instances is about as good as it gets.
But let’s face it…shared hosting + Rails suck.
Only as reliable as the worst application on the server
Not always good neighbors
Resource constraints
Free-for-all

Ezra recommends a Xen VPS for Rails deployment. I’ve followed his advice; this blog is hosted on a Xen VPS at http://rimuhosting.com.

Deployment models

Starting point, web, app and db on the same server.
Next, move database to a separate server. Use the more powerful hardware to the db.
Third, split each role to a separate server. But now you need an NFS to serve static and cached contents. Ezra states you can go a long way with this setup

class FutureOfRailsDeployment < ActiveRecord::Base
  belongs_to :mongrel
end

Mongrel

Speaks plain old HTTP, so you can take advantage of existing tools for load balancing, proxying or caching
You can use frontends: Pound, Pen, Balance, Haproxy, Lighttpd (although mod_proxy needs to be fixed), or Apache 2.2 modproxybalancer
Mongrel cluster gem allows easy management of multiple mongrel processes. It’s straightforward to integrate with capistrano too.

Engine Yard

Ezra describes a new hosting service he’s been working on that will give you a greatly simplified but powerful and performant hosting environment for your Rails applications, including a web admin console and deployment directly from SVN revisions and tags.

Go to Engine Yard for a beta signup email now!

BackgroundDrb

Distributed Ruby server that manages long runnng tasks.
Uses a MiddleMan proxy/stub class that allows the Rails process to connect to the background server.
Can use it as a worker queue, (e.g. for sending email) or as a distributed memory cache.
You can even query for progress on the background workers and push the result all the way to the browser with an ajax progress bar.
The code for BackgroundDrb looks really clean! Go to http://backgroundrb.rubyforge.org/ for the nitty gritty.

Nick Sieger: Category rails

Rails is simpler than Office

RailsConf begins

RailsConf: Dave Thomas keynote

Dave Thomas, Professional Cassandra

Intro

3 Problems for Rails

PDI

Data integrations

Real-world CRUD

Deployment

Closing

RailsConf: Mike Clark -- Introduction to Capistrano

Introduction to Capistrano

Configuring Capistrano - create a recipe

Set the application name

Set the repository

Roles

Deployment Root

Setup

First time deploy

New Release

Rollback release

Scheduled downtime

Customization

Channels and streams

Hooks

Multiple configs

Task libraries

Capistrano isn’t just for Rails

Assumptions

Take Home

Notes and Questions

RailsConf: Stefan Kaes - Rails Performance

Performance, broken down

Tools

Railsbench

Profiling Tools

Top Rails Performance Problems

Session containers

Caching

ActionController

ActionView

Helpers

ActiveRecord

Language-level and miscellaneous issues

Ruby Memory Management

Rails Template Optimizer

Questions

RailsConf: Amy Hoy - Overcoming Scaffolding Addiction

RailsConf: Obie Fernandez - Thoughtworks on Rails

RailsConf: Steven Hammond - DSLs and Rails Plugins

Intro

Features of DSLs

Horizontal vs. Vertical

Recipe example

Rails DSLs

When to create a DSL

DSLs and Reuse

Designing a DSL

Pitfalls

RailsConf: Bill Katz - Metaprogramming Writertopia

Resources

Authorization plugin

Implementing permit

Questions

RailsConf: Ezra Zygmuntowicz - Rails Deployment

Yakima Herald

Data Aggregation

Deployment

Tuning

Shared hosting

Deployment models

Mongrel

Engine Yard

BackgroundDrb

Implementing `permit`