semantic art

Killing is_paranoid

Tue, 13 Oct 2009 00:00:00 -0000

Intro

In short, I’m killing is_paranoid. It’ll still exist as a github repo (mostly as an example of hack-ery and buffoon-ery) and you’re still welcome to use it if you insist. However, I’m no longer going to support it or continue development on it. I’m sorry to anyone this affects.

Why

I created is_paranoid as an example of using “default_scope” to simulate acts_as_paranoid. It was a proof-of-concept and a toy that caught on for whatever reason. I liked it because the original version was ridiculously simple to grok and it was a fun example of the power of default_scope.

But over time, I found out that default scope isn’t as default as I had thought, and is_paranoid became a pile of hacks upon hacks to overcome unexpected behaviors in ActiveRecord and unexpected, complicated use-cases. It became a pain and a mess.

A few examples of the train-wreck

About default_scope not being default-enough for is_paranoid: Imagine you have a product model with a default scope that specifies that only products with in_stock = true should be selected (we don’t want to show out-of-stock products by default). Cool, that works on simple finds. Now let’s imagine we have categories which have many products. Category.find(:first, :include => :products) works, but it doesn’t respect the default_scope on the eager-loading of products so you get out-of-stock items. This applies to all relationships that are eager-loaded, not just has_many. It also isn’t respected on has_many :through relationships (eager-loaded or otherwise). It also probably isn’t respected in a few other places I can’t recall offhand.

Don’t get me wrong, I’m not claiming ActiveRecord or default_scope should be implemented differently or that I could do it better. It just turns out that even though you can implement a rudimentary soft-deletion with default_scope I don’t think you should do it. The problem wasn’t ActiveRecord, the problem was how I was using default_scope. It just doesn’t hold up long-term.

Another issue is that once a scope is applied (default, named, otherwise), it isn’t possible to easily subtract that scope. is_paranoid used with_exclusive_scope to find soft-deleted items, but with_exclusive_scope makes things like Person.female.with_destroyed break since with_exclusive_scope undoes the female scope. There’s no obvious easy way to just pop out the is_paranoid scope and leave the other scopes.

And you can overcome these things (and you can surely do it more cleanly than I did), but it will always be a hack because in the end you’re trying to make ActiveRecord behave differently than it wants to in several different places.

Moving on…

More than just is_paranoid becoming hacky, I’m also subscribing to Rick Olson’s reason for not using acts_as_paranoid anymore (even though he’s the author). This is a sentiment echoed by Ben Johnson in his post about discontinuing Resourcelogic. Simply put, you lose intent by relying on magic. It makes a lot more sense to just be explicit about things using named_scopes or something similar.

I’m biting the hand that feeds me to an extent here since is_paranoid has been my most popular open source project. But I’d rather not be known than be known for something I don’t believe in.

Remember that just because you can do something doesn’t mean you should.

I wouldn’t recommend using is_paranoid unless you want to fight with it. And make sure you write a lot of tests :/

I do want to thank the people who reported bugs and contributed solutions to is_paranoid. I genuinely appreciate it.

Well, now that I’ve sufficiently bummed myself out, I’m going to go back to hacking (the good kind, heh) on a fun little project that should be announced here in a day or two. Ob-la-di, ob-la-da, right?

Using default_scope to recreate acts_as_paranoid

Sun, 22 Mar 2009 00:00:00 -0000

Intro

Rails 2.3 gives us “default_scope” which was described by Ryan Daigle as allowing you to “specify default ordering, and other scopes, in edge rails directly in your ActiveRecord model.” Ryan’s post gives some good examples of when you might want to use this (specifically on models where you always want them sorted in a specific manner). In the comments of that post, Ryan Bates suggests that this might be useful for “simulating destroying a model (like acts_as_paranoid).” Indeed this is possible and the idea of using scoping to create this is both present in acts_as_paranoid itself and also has been brought up before.

In this article I’m going to reinvent the wheel using default_scope to illustrate how powerful default_scope is and how trivial it makes this task. You can keep track of the finished product in my is_paranoid gem.

Getting started

The syntax for declaring a default_scope is simple. Here’s what Ryan D. uses in his article:

class Article < ActiveRecord::Base
  default_scope :order => 'created_at DESC'
end

To break this down, every time we use ActiveRecord to query our database, it will add the “created_at DESC” order to our query. Here’s a sidebar word of warning about default_scope: That’s every query, so you’re incurring some unnecessary overhead if you haphazardly set default scopes when you don’t really need them. As a trivial example, the show action on our articles controller doesn’t need to sort the articles by created_at since it should only be finding one article anyway.

If you’re unfamiliar with acts_as_paranoid, it allows “you to hide and restore records without actually deleting them.” The plugin uses a timestamp field on your table to specify whether an item should count as deleted or not; if the deleted_at timestamp is nil, it is not deleted, if the timestamp is not nil, it is deleted. The migration for articles with our deleted_at column looks like this:

class CreateArticles < ActiveRecord::Migration
  def self.up
    create_table :articles do |t|
      t.string :name
      t.text :body
      t.timestamp :deleted_at, :default => nil
      t.timestamps
    end
  end

  def self.down
    drop_table :articles
  end
end

And our default scope should look like:

class Article < ActiveRecord::Base  
  default_scope :conditions => {:deleted_at => nil}
end

Now in script/console if you do Article.first, you can see the effects in your log: "SELECT * FROM “articles” WHERE (“articles”.“deleted_at” IS NULL) LIMIT 1"

We’ll need to redefine destroy if we want it to mark an item deleted instead of actually deleting it.

class Article < ActiveRecord::Base  
  default_scope :conditions => {:deleted_at => nil}

  def destroy
    self.update_attribute(:deleted_at, Time.now.utc)
  end
end

Let’s give it a spin:

>> a = Article.create(:name => "Test Article", :body => "some body")
=> #<Article id: 3, name: "Test Article", body: "some body", deleted_at: nil, created_at: "2009-03-22 16:08:00", updated_at: "2009-03-22 16:08:00">
>> a.destroy
=> true
>> Article.first
=> nil

But the log shows it actually just did "UPDATE “articles” SET “updated_at” = ‘2009-03-22 16:08:02’, “deleted_at” = ‘2009-03-22 16:08:02’ WHERE “id” = 3" so our article is still there, we simply can’t find it because of our default_scope.

Sadly there’s something we’ve broken already, though. Because we redefined destroy, we can’t use our destroy callbacks, like before_destroy, anymore. We can fix that by changing the way we implement destroy. You should check out lib/is_paranoid.rb in the repo to see how this is implemented. Let’s move on.

Now we need to add a method to help us find things that have been marked deleted. To do that, we’ll need to bypass our default_scope by using with_exclusive_scope.

def self.find_with_destroyed *args
  self.with_exclusive_scope { find(*args) }
end

Essentially this takes whatever arguments you provide as finder conditions (and/or order, includes, etc.) and passes them to the find method after first specifying that we should ignore the default_scope. Now we can find our destroyed items as well as our non-destroyed items.

>> Article.find_with_destroyed(:first)
=> #<Article id: 3, name: "Test Article", body: "some body", deleted_at: "2009-03-22 16:08:02", created_at: "2009-03-22 16:08:00", updated_at: "2009-03-22 16:08:02">

There’s still a few features to add, like count_with_destroyed and a restore method, but this should give you a good intro to the power of default_scope. Both those features are added in the current version of is_paranoid and we’re still sitting on less than 40 actual lines of code to accomplish the core functionality of acts_as_paranoid.

Why you might not want to use default_scope

There’s the previously mentioned overhead incurred with applying order or conditions to every interaction ActiveRecord has with your database, but beyond that, some people in the community feel that overriding find methods can add unnecessary complexity to your code and make debugging more complicated. In fact, Rick Olson, the author of acts_as_paranoid, no longer uses AAP in favor of hidden and visible named scopes on his models.

Granted, it is more readily apparent that you’re in a named scope since they’re explicitly called, but if you have a good number of models that you want to be able to soft-delete or hide, then it seems that declaring those scopes on each model isn’t very DRY. I’d wager most people end up using a mixin to prevent repetition. I don’t feel that using default_scope in a manner such as this is far beyond simply DRYing things up.

Besides, anyone should be able to easily grok the code in is_paranoid, as brief and simple as it is. Ultimately it comes down to personal preference. As always, makes sure you know your toolset.

In praise of ActiveRecord (rat-hole)

As a quick rat-hole, ActiveRecord implements destroy and delete_all fantastically. Basically Model.destroy and Model.destroy_all both internally call instance.destroy and Model.delete and instance.delete both internally call Model.destroy_all. Because of this, you only have to redefine delete and destroy once for them to take effect across the other methods. Awesome.

In closing

If you’re looking for a light-weight acts_as_paranoid replacement and you’re on Rails 2.3+ then give is_paranoid a look. The readme should give a decent overview, but beyond that, check out the specs and read the source.

I want to keep is_paranoid light-weight, but if anything important is missing or if you uncover any bugs, please let me know.

If you like this or the other articles, please consider subscribing to my rss feed

Comparing Thinking Sphinx And Acts As Ferret For Full-text Indexing In Rails

Thu, 05 Mar 2009 00:00:00 -0000

This will by no means be an exhaustive list of differences between using Sphinx and using Ferret, but we’ll look at a few major differences between the way these two search engines are implemented via acts_as_ferret (AAF) and Thinking Sphinx (TS).

Active Development

First thing is first, TS is in much more active development. At the time of writing, TS last had a commit to the offical repo 13 days ago in comparison with three months ago for AAF. And it shows. acts_as_ferret discussion these days is minimal online and most of the tutorials are rather old. Meanwhile, Thinking Sphinx has a very active google group and several more recent tutorials including a fairly recent Railscast.

So Thinking Sphinx wins in terms of active development.

Speed, Reliability, and Resources

Another place TS blows AAF out of the water is in speed and resource usage. Sphinx uses kilobytes of memory where a ferret daemon will sit on megabytes, having to load your entire Rails app into memory. For example, on my machine, the Sphinx daemon sat at 376 KB while my ferret process ate 57.69 MB. Not kidding.

Ezra Zygmuntowicz said

Ferret is unstable in production. Segfaults, corrupted indexes
galore. We’ve switched around 40 clients form ferret to sphinx and
solved their problems this way. I will never use ferret again after
all the problems I have seen it cause peoples production apps.

Plus sphinx can reindex many many times faster then ferret and uses less cpu and memory as well.

Anecdotally, that’s my experience as well. Thinking Sphinx can index my database in less than a minute, while acts_as_ferret can take up to 30 minutes or more.

The Level of Interaction with Rails

Simply put, acts_as_ferret obeys ActiveRecord, while Thinking Sphinx goes low-level.

In his Thinking Sphinx Peepcode PDF, Pat Allen writes “For those familiar with Ferret, Sphinx is quite similar, except that Sphinx talks directly to database servers – both MySQL and PostgreSQL – to obtain the data to index.”

This is largely what gives Sphinx its speed advantage, but it also makes Thinking Sphinx dumb as far as your ActiveRecord models are concerned.

For instance, this means that TS isn’t aware of your acts_as_paranoid models until you add the deleted_at conditional to your define_index block.

define_index do
  indexes [:body, :title]
  where ['deleted_at is NULL']
end

This also means that TS can’t index computed values as easily. In AAF you can index methods on your object, so you could index a method like the following

def ordinalized_names_of_children
  ordinalized_children = []
  self.children.sort_by(&:birth_date).each_with_index do |child, i|
    ordinalized_children << [child.first_name, i.to_ordinal]
  end
  ordinalized_children
end

This is a silly example, but to accomplish the same with TS you need to use db-specific string transformations and add all your conditional logic to the query as well. And you can easily imagine more complicated examples. Where with AAF you have the entire landscape of Ruby to use and abuse and you’re instantly inheriting the constraints of ActiveRecord, with TS you’re limited to what can be done solely on the database level. Luckily this is usually enough.

Indexing Changes to Your Models

As far as ease of handling updates goes, acts_as_ferret has a big initial advantage. From Gregg Pollack

the index gets modified every time you add/edit/remove the ActiveRecord model it’s associated with. You never have to worry about doing this yourself, it happens automatically, so your search index is always 100% accurate. No rebuilding needed.

With Thinking Sphinx, you need to specify something called delta indexes on the models you want to keep up-to-date for searches between index rebuilds. This is a little more intrusive than AAF’s approach since you also have to add a field to your table called “delta” to track what has updated… but a single boolean field doesn’t incur much overhead. You’ll still need to periodically rebuild your indexes regularly as the delta indexes can slow things down over time.

In both AAF and TS, deleted models are immediately removed from the index.

To sum up the differences:

AAF requires less work on your part to keep an accurate running index, but the overhead involved in updating the index on each record update can be painfully slow over time.
TS requires more work to specify delta indexes and requires you to add a column to your database, but provides you with options on how often incorporate the changes so that you’re not waiting on a change to be indexed on every model save.

From my experience, very few model updates need to be instantly available for search, and both approaches have their pros and cons. Though it requires slightly more work on your part, I feel TS puts more control in your hands.

The Overall Winner

The winner here is obviously Thinking Sphinx. You use less resources and get better speed, reliability, and the future looks a lot more sure for support. Sure, you may have to get your hands a little dirtier with some SQL, but the benefits more than make up for it.

Also (and I get nothing out of this), you should buy the Peepcode PDF as it will give you a huge head start on Thinking Sphinx.

An aside on Sphinx’s Treating of Primary Keys

There’s another thing Ferret can do that Sphinx cannot. As Section 3.5 of the Sphinx documentation states, “ALL DOCUMENT IDS MUST BE UNIQUE UNSIGNED NON-ZERO INTEGER NUMBERS (32-BIT OR 64-BIT, DEPENDING ON BUILD TIME SETTINGS).” And Thinking Sphinx enforces this in its config file by performing math on your table’s id column to help create unique sphinx index ids.

99 times out of 100 this is fine since most tables just have auto-incremented integer ids anyway, but what if you have tables with ids of significant value? That’s the situation I found myself in when adopting Thinking Sphinx on my current project. We have a ton of external data coming in and much of that data already has a GUID so we decided early on to use the GUID as a primary key and foreign key as that would allow us to later recreate any table without having to worry about the foreign key integrity issues that can sometimes be a taxing side-effect of using auto-incremented ids.

My first approach to overcoming this limitation was to add an auto-incremented column named “id” to the table and then make use of set_primary_key in Rails. Unfortunately, once you do that, Thinking Sphinx tries to call that primary key you specified. So Thinking Sphinx had to be patched. Essentially, I added a method set_sphinx_primary_key to allow you to specify a primary key that TS should use regardless of what the ActiveRecord model specifies as its primary key.

So in the example:

class Robot < ActiveRecord::Base
  # The key ActiveRecord will use on joins, map to id, etc.
  # Setting the primary key isn't necessary for set_sphinx_primary_key to work
  set_primary_key :internal_id

  # The key sphinx will use for indexing, must be a unique integer
  set_sphinx_primary_key :alternate_primary_key

  define_index do
    indexes :name
  end
end

ActiveRecord will use the field internal_id on the “robots” table (the set_primary_key could just as well be left out and ActiveRecord would use the default “id”). But while ActiveRecord uses internal_id, Thinking Sphinx will instead use alternate_primary_key. So our robots can internally use a GUID string while Sphinx is still provided with the integer column it needs to index the robots.

You can find these updates in my github branch of Thinking Sphinx. I have no idea if Pat will ever merge these into the main repo, as it is admittedly a niche need. But if you find yourself in the situation I found myself in, it can really help you overcome this limitation of Sphinx.

CsvMapper gets a little more magical

Fri, 06 Feb 2009 00:00:00 -0000

Have you checked out CsvMapper by Luke Pillow? It makes some of the drudgery of CSV parsing fade away. It really is a fantastic library. As an example from the doc:

Given the csv

First Name,Last Name,Age
John,Doe,27
Jane,Doe,26
Bat,Man,52
...etc...

you can do

include CsvMapper

results = import('/path/to/file.csv') do
  start_at_row 1
  [first_name, last_name, age]
end

results.first.first_name  # John
results.first.last_name   # Doe
results.first.age         # 27

Cool, right? There’s a lot of magic built in, but I felt there was an extra-mile left to go… By default CsvMapper requires you to specify the columns you want. Most of the time you want to do this, but it doesn’t really feel DRY in cases where the column names are made redundant by matching those on the first line of the file. And its a pain to reproduce column names when there are many, many fields. So, presto:

include CsvMapper

results = import('/path/to/file.csv') do
  read_attributes_from_file
end

results.first.first_name  # John
results.first.last_name   # Doe
results.first.age         # 27

Sweet, you say, but what if my field names are something absurd and clunky? Fine, say I, just specify an alias for them.

results = import('/path/to/file.csv') do
  read_attributes_from_file('First Name' => 'what_my_friends_call_me')
end

results.first.what_my_friends_call_me  # John

What about more realistic example with a bigger csv file? OK, here’s one from Subsidyscope:

results = import('subsidyscope-tarp.csv'){read_attributes_from_file}
results.first  # <OpenStruct type_of_institution="holding company", city="New York", 
               # description="Preferred Stock w/Warrants", 
               # total_assets="1856207282000.00", date="2008-10-28", 
               # fdic_number="1039502", ots_number=nil, transaction_type="Purchase",
               # price_paid="25000000000.00", state="NY", 
               # name="JPMorgan Chase & Co.", stock_symbol="JPM",
               # pricing_mechanism="Par", regulator="Federal Reserve">

We didn’t have to define a single attribute name; the csv file did it for us.

Ok, I’m sold, you say. Where can I get this? Try my CsvMapper github fork until it maybe gets merged into the official branch.

If you like this or the other articles, please consider subscribing to my rss feed

Ruby Idioms from Open Source, Volume One - Seinfeld

Sat, 29 Nov 2008 00:00:00 -0000

This is the first in what I hope to be a series of articles looking at different open source projects and pulling out various ruby idioms.

We’re looking at Seinfeld which powers Calendar About Nothing. If you haven’t signed up yet, you should definitely do so. It is a fantastic way of keeping yourself motivated and contributing.

String Substitution

You can find the first bit of interesting code at line 37¹ of seinfeld_calendar.rb in the page_title method:

def page_title
  "%s's Calendar" % @user.login
end

Here we see String formatting substitution. You could also do sprintf(“%s’s Calendar”, @user.login), but why would you? Use an array if you have more than one value for substitution.

Date Manipulation

now        = Date.new(params[:year], params[:month])
prev_month = now << 1
next_month = now >> 1

Around line 58 of seinfeld_calendar.rb, we see that for the calendar’s next and previous month links to work properly, Seinfeld uses the << and >> methods which are described to

Return a new Date object that is n months earlier/later than the current one.

These methods were new to me, but they’re easy enough to remember if you think of them as looking like fast-forward and rewind.

Determining if a string is empty… wait, what?

Line 120 of /lib/seinfeld/models.rb gives us

return if login_name.size.zero?

Which looks nice, but one can’t help but wonder why they didn’t use login_name.empty? instead. My benchmarks show .empty? to be trivially faster, but I may be missing something. Any ideas? My money is on it simply being the author’s preferred idiom. I think .size.zero? may be more readable, but I’ll stick with .empty? for the near future.

If you like learning by examining good examples of ruby code, I highly recommend David A. Black’s Ruby for Rails: Ruby Techniques for Rails Developers

If you have any suggestions for a future project to look at, please let me know.

¹ Because projects are always changing these line numbers are just provided as-is at the time of writing.

Driving Sinatra Without A Browser

Fri, 28 Nov 2008 00:00:00 -0000

Intro

I’ve been hacking on leethal’s stuff-site (the software that runs this blog) recently and adding a good number of features to my fork. One item I recently added is pushing everything out to a static version of the site. This allows you to run the app on any hosting and bypass Sinatra altogether on the host side. To borrow the motto from merb, “no code is faster than no code.” I’m not using anything that has to be dynamic, so let’s remove all the moving parts and just use the Sinatra part for development and testing.

There are a plethora of ways to make static sites. I didn’t want to rely on outside resources like wget or curl and I wanted to avoid using any html parsing/spidering if possible. Since this is a very simple app with only 4 types of pages (index, rss, article, topic), it made sense to borrow from whatever magic Sinatra’s specs are using to make test requests and throw the task in the Rakefile.

Let’s do this already

Sinatra’s rspec suite provides get_it, post_it, etc. methods, so we first search for where these methods are defined and see if we can piggyback off of whatever process they use. You can find them (as of this publication) on line 35 of /lib/sinatra/test/methods.rb but the lines we really care about are 36 and 56

@request = Rack::MockRequest.new(Sinatra.build_application)
# ...
@response = @request.request(http_method, path, opts)

So let’s try this¹

@request = Rack::MockRequest.new(Sinatra.application)
puts @request.request('get', '/').inspect

yields



#<Rack::MockResponse:0×1031f28 @body=“(…)”, 

@errors=“- – - [28/Nov/2008 12:29:02] \”get / \" 200 1511 0.0034\n",

@original_headers={"Content-Type"=>"text/html"},

@headers={"Content-Type"=>"text/html"}, @status=200>

We really only care about the response body. To dump out the index of our site, we just use

File.open(File.join(static_dir, 'index.html'), 'w') do |f|
  f.print @request.request('get', '/').body
end

Then we continue with this process for each section of the site we want to make static. Now uploading new content is as easy as running our rake task and then using rsync.

Obviously you can set up your webserver to serve static content when it is available and then fall back on Sinatra when the static content isn’t present.

You can see the full code in the rake file of my repository or check out an archived gist version.

Nice, what’s actually happening here?

Sinatra is a DSL built upon Rack, so we simply leverage Rack’s built-in methods to drive our web app without ever touching the browser.

From the documentation for Rack:MockRequest

Rack::MockRequest helps testing your Rack application without actually using HTTP.

Note that it is the HTTP part of the request that is being mocked here. Your app is receiving the request in the same way that it would if the request were triggered from the browser.

¹ : though the test/methods.rb isn’t updated as of publication of this article, Sinatra.build_application is deprecated and it is now recommended you use Sinatra.application instead

Sinatra, Github, And More

Tue, 25 Nov 2008 00:00:00 -0000

Some random things… I’m now six months into my job at Politics4All and it is pretty amazing how far we’ve come as a company and how much my views on open-source and ruby have matured.

Sinatra is an awesome framework. I’ve written hoboken (a simple wiki) with it and now I’m running this blog on it thanks to August Lilleaas’ stuff-site.

There’s something about Rails where once you start using it you want to use it for things that it is overkill for. You can use a chainsaw to cut the Thanksgiving turkey, but are you sure that’s the wisest thing to do? Sinatra stays out of the way and lets you do as little as you want to do. All Sinatra is doing for me is pointing http requests to my methods. There’s no black magic or voodoo going on, it is just a small DSL on top of rack. It does what it does, and lets me do what I want to do. That’s awesome.

GitHub has, for months, only existed for me as the place where my work repository was stored and a place where I could browse other people’s repositories. I’ve dabbled in open source before, but when Calendar About Nothing showed up, something clicked for me. I might not be able to turn out the next big thing, but there’s surely something incremental I can do each day to make my hobby projects and the projects of others better. Sure enough, I’m now thirteen days into a streak. I’ve worked on hoboken and a few api wrappers and made minor improvements to gnip-ruby and the aforementioned stuff-site. You can follow me on github if you’d like.

So, “thank you” to August, the people behind sinatra, github, and Calendar About Nothing.

Review Of Envy Cast's Ruby On Rails 2.2 Screencast And Pdf

Wed, 05 Nov 2008 00:00:00 -0000

Recently I was given the opportunity to review the Ruby on Rails Envycast of Rails 2.2 from Envy Casts. I’ve long been a fan of the Rails Envy podcast. They give us solutions to Ruby and Rails problems as well as provoking deep thought about the Terminator. They even mocked me once. But most people will remember them as the jerks who encouraged everyone to use Ferret.

If you’re not familiar with the Rails Envy podcast, you should do yourself a favor and go listen to an episode first. Don’t worry, I’ll wait here…

To try to write about Rails screencasts without mentioning Railscasts or Peepcode is impossible, so I won’t try to act like the Rails Envy guys invented this space. What do they bring to the table? They’re in front of the camera, for one thing, and despite the fact that neither Gregg nor Jason look like that beautiful girl you knew in high school turned exotic dancer, seeing them makes the their interactions and gags all that much more enjoyable. Also, this video is a good bit longer than the Railscasts (44 minutes!) and this in-front-of-the-camera methodology keeps you from spacing out as I’m prone to do watching a Peepcode screencast.

The Ruby on Rails 2.2 Package is the second offering from Envy Casts. It is available as a 9 dollar video or a 9 dollar PDF, or as a 16 dollar combo. Take a moment to write a rails app illustrating how much you save by buying the combo*. Now scale it across 5 slices. Now consider the silence of a pebble.

Both items (surprise) cover the new features in Rails 2.2. If you haven’t watched the commit logs or kept up with Ryan Daigle’s What’s new in Edge Rails, you’ve missed some massive changes. This PDF and screencast will bring you up to speed quickly.

The screencast is conveniently broken into chapters (in the mov format, anyway), so, of course, is the PDF. Each segment is filled with new features and each new feature is approached in a “why would I care about this?” manner that cuts through the fluff and lets you easily see how the change is relevant.

The PDF covers the whole gambit of changes in Rails 2.2, while the video version covers a more interesting subset of the features. The content quality of the PDF is on par with the PDF’s you’d get from PeepCode, but the visual quality is not nearly as polished. Don’t misunderstand, the content is perfectly readable, it just lacks any splash of color to break up the monotonous black and white. Syntax highlighting and broken out sidebar boxes with key information might be useful in future Envy Cast PDFs.

There are a few awkward moments where they’re just left giggling at each other and some asides that go absolutely nowhere, but if you’re an fan of the podcast, you know that’s just part of the charm. Besides, who wants to read a boring list of changes with examples? Well, I do. But I also like a summary format that gives me an overview with fancy special effects that appeal to my short attention span. That’s why the bundle of the PDF and the screencast is an excellent choice. The grown up in me likes the dense and concise information in the PDF, but the kid in me likes the bleeped out profanity.

Did I learn? Yes. Did I laugh? Yes. Would I recommend the screencast? Yes, but that “yes” becomes “Absolutely!” if you are already a fan of the podcast. The PDF is vanilla enough that regardless of your tastes in humor, you should make it a purchase.

The Envy Cast guys didn’t invent the screencast, but they’ve made it enjoyable. If you want to learn without feeling like you’re working and become enlightened on Rails 2.2 rapidly, this is the best $16 you can spend.

*Bonus points to anyone who uses BackgrounDRb for the heavy math.