Posted by Nick Sieger
Sat, 24 Jun 2006 17:27:00 GMT
Bill Katz took a code-focused approach to explaining metaprogramming
and DSLs.
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.
Posted in ruby, rails | Tags railsconf | no comments | no trackbacks
Posted by Nick Sieger
Sat, 24 Jun 2006 16:18:00 GMT
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)
3.d6
3.d6 :keep_best => 3
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.
Posted in ruby, rails | Tags railsconf | no comments | no trackbacks
Posted by Nick Sieger
Sat, 24 Jun 2006 15:15:00 GMT
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”.
Posted in ruby, rails | Tags railsconf | no comments | no trackbacks
Posted by Nick Sieger
Fri, 23 Jun 2006 21:43:00 GMT
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.
Posted in ruby, rails | Tags railsconf | no comments | no trackbacks
Posted by Nick Sieger
Fri, 23 Jun 2006 20:40:00 GMT
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
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.
Top Rails Performance Problems
- slow helper methods
- complicated routes
- associations -- navigating and eager loading vs. proxy loading
- retrieving too much data from the DB
- slow session storage (e.g., ActiveRecord store)
Stefan says that in his experience, DB performance is generally not a
big factor or bottleneck. Instantiating ActiveRecord objects is
expensive, though.
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.
Posted in ruby, rails | Tags railsconf | 3 comments | no trackbacks
Posted by Nick Sieger
Fri, 23 Jun 2006 16:45:00 GMT
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.
Posted in ruby, rails | Tags railsconf | no comments | no trackbacks
Posted by Nick Sieger
Fri, 23 Jun 2006 15:12:00 GMT
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!
Posted in ruby, rails | Tags railsconf | no comments | no trackbacks
Posted by Nick Sieger
Fri, 23 Jun 2006 14:10:00 GMT
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!
Posted in ruby, rails | Tags railsconf | no comments | no trackbacks
Posted by Nick Sieger
Fri, 26 May 2006 03:32:00 GMT
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
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!
Posted in ruby, rails | Tags pdf, ruby, rubyonrails | no comments | no trackbacks
