Someone else solved this problem three years ago but nobody accepted their patch, and now /etc/bash_completion.d/screen has been overhauled and the patch no longer applies.

I updated the patch so it works and resubmitted it to Ubuntu.

If you don’t wanna wait, grab the code from this gist and do this:

sudo patch /etc/bash_completion.d/screen screen.patch

This will probably work on Debian too since that’s where the completion script came from.

Well, a few months ago Ilya Grigorik posted a Gist containing a really amusing microframework that is one of the most brilliantly expressive bits of code I’ve ever seen, without being particularly hard to read. 13 lines of Ruby code provides a web application that will allow any Ruby object you choose to have its entire public API exposed via URLs of the form /method/arg1/arg2, where the method return value becomes the response body.

For the benefit of non-Ruby developers, I’m going to walk through all 13 lines of code plus the 1-line example application to explain how it works. I really hope that by reading through this explanation you will come to appreciate the expressiveness of Ruby, and maybe what a clever bit of dynamic language programming this is.

Here is the code: Inspired by @JEG2’s talk at Rubyconf… Any ruby object, as a webapp! ‘Cause we can. :-)
In particular, note the 7th comment, with the embedded animated GIF. This should put you into the right frame of mind for understanding this code.

Line 1: Load RubyGems, which is a library that helps you manage other Ruby libraries that your code depends on.

Line 2: Load Rack, which is a standard API for connecting web servers to web application frameworks.

Line 4: We are modifying the Object class itself, so our changes will affect every object in the application.

Line 5: We are adding an instance method called “webapp” to every object.

Line 6: We are going to modify the class of just the instance whose “webapp” method was invoked. This may seem paradoxical: how can you modify its class without affecting all other instances of that class? The answer is that we are actually creating a unique, anonymous subclass, and the object whose “webapp” method was invoked now becomes an instance of it. So when a caller invokes “webapp” on an object, we will modify just that instance.

Line 7: We are defining a method in our anonymous subclass named “call”, which takes a single argument, “env”. This is what the Rack API will invoke to ask our web application to handle each web server request.

Line 8: We are splitting the URL path on occurrences of “/” and storing the result into an array, and then filtering out all elements of that array that return true when the “empty?” method is called on them. Then, using multiple assignment, we take the first element of the array and assign it to the local variable “func”, and a new array containing the remaining elements to the local variable “attrs”.

Line 9: The Rack API expects a return value of an array containing 3 elements: an HTTP status code, a hash of HTTP response header names and values, and the response body. So here we respond with that array. “send(func, *attrs)” is an expression that calls “send” on self, which lets you invoke a method without specifying the name of the method nor the arguments to be passed to it until runtime. The method invoked is the one named in func, and the argument list passed to that method are taken from the attrs array. This is how the URL of the web request is mapped onto the API of the object that you made into a webapp.

Line 12: The return value from invoking the “webapp” method will be the same object that “webapp” was invoked on, which now has our special “call” method added.

Okay, so that’s it: a tiny Ruby web app microframework. Now we’re going to use it to expose an object!

Line 16: Start up the Mongrel web server listening on port 9292, and load up an empty array as a Rack webapp.

Lines 17-19 are a joke: because our webapp is an array, we have just implemented a horizontally scalable in-memory sharded NoSQL database, which is really the only suitable option for our expected ROFLScale needs.

Line 23: [].push(1) returns [1]; rack calls .to_s (convert to string) which returns “1″ as the response body.
Lines 24 and 25: Since the array is the webapp, the changes are persistent.
Line 27: [1,2,3].to_a returns [1,2,3], and [1,2,3].to_s returns “123″.
Line 29: Remove the last value, returning 3 and leaving [1,2] in the array.
Line 30: Remove the first value, returning 1 and leaving [2] in the array.

User story: “As a princess I want to confirm my royalty so I get bruised after sleeping on 40 mattresses over a pea”. Just tell real stories”

That sounded so much like a Cucumber feature that I decided to write it as one:

Feature: Physical Sensitivity
  In order to confirm my royalty
  As a princess
  I want to be very delicate

  Scenario: 40 mattresses on a pea
  Given there is a pea on the bed
  And there is a stack of 20 mattresses on the pea
  And there is a stack of 20 featherbeds on the mattresses
  When I try to sleep on top of the stack of featherbeds
  Then I should not be able to sleep

But do you know about kill -STOP and kill -CONT?

I’m not sure of the exact mechanism (kernel vs. user process) but everything I’ve used it on on a Mac OS X machine has responded to it in the same way. So you may find a process that doesn’t do this, but I haven’t found one.

Basically kill -STOP 1234 will pause the process with pid 1234, and kill -CONT 1234 will resume it. It’s as if you can sleep individual applications instead of your entire computer.

It’s simple, but you can probably imagine why this would be useful. Want to keep Firefox with 45 tabs open, but you’re not using it for a while and you want to save battery life? Pause it. Pretty much anything like “I don’t want to quit and then re-launch this but I wish it wasn’t using a bunch of CPU time while it idles” is a good candidate.

Remember that this means your app my time out when it is resumed, as if you had slept your laptop. So network connections it had open when you paused it may be broken when you resume it. So pausing Terminal.app with a bunch of open ssh connections to remote servers isn’t going to work too well.

But because the concept of database migrations is such a powerful one, it’s tempting to jam any old change that affects the database into a new migration and run rake db:migrate to make it happen. I’ve been guilty of a bit of this in the past, and I’ve joined some projects that did other ugly things in migrations. In the process I’ve learned the hard way that there are some things you must never do in a migration or they will come back to haunt you later. Here they are.

Antipattern: Require the Database to Exist Already

In other words, the antipattern is for the first migration to depend on some tables and maybe even some data already being in the database.

I know that the original Rails blog video shows DHH using a MySQL admin tool to create the blog database interactively, but really you should be using migrations to create the schema programmatically from scratch.

If you’re already working on a project that didn’t do that, you can run rake db:schema:dump and look at db/schema.rb; it contains code that you can insert into a new migration to create the same schema in your development environment. If you’re using DB features that the design philosophy of ActiveRecord doesn’t agree with, such as triggers, and the schema.rb dump doesn’t include them (or if you just think the migration DSL is ugly and you like SQL DDL better), you can do a mysqldump / pg_dump / whateverdump and wrap a migration around the loading of that SQL file.

If you have a hybrid (you have to start with an old db dump and then migrate it so it becomes current), that’s gross, and you have a couple of options which are both pretty ugly. But they will work, and when you’re done the ugliness will be gone.

You could fight your way back to the oldest schema version by debugging the self.down methods and running rake db:rollback repeatedly until you can create a 00001_starting_db_schema.rb migration, or you could just blow away all the migrations and use the highest schema version for a new migration that contains the output of a current rake db:schema:dump. It depends on how many copies of the database are out there with old schemas that would need to be brought up to date. Clearing out db/migrate and replacing it all with a single migration is cleaner, but if your production database is 5 migrations out of date you obviously can’t do that. But you could collapse it down to the one big-bang migration (as the oldest), plus the 5 pending schema changes. If you do it right, you can just deploy the new code and run rake db:migrate and everything will be fine. If not, well, you were testing it on a backup of the production database, right? :)

Antipattern: Only Work Correctly With the Production Data

What’s wrong with developers just making dumps of the production database and loading them locally?

First of all, it means that all schema changes have to start at the production database and work backwards to developers’ sandboxed development environments. Hopefully this strikes you as a very stupid workflow.

Secondly, maybe your users don’t all want to get a message that says “test message foo bar sdfasdfasd bloopity bloop” when you’re testing your new alert system. Should you really be putting their data (passwords, contact info, etc.) at the mercy of your crummy new code?

You should be able to immediately generate an empty, clean database for development. rake db:drop; rake db:create; rake db:migrate should do this; rake db:reset should have the same result but should be faster since it doesn’t bother with each migration in sequence.

You should also be able to immediately generate any essential base data such as the initial admin user. The SeedFu plugin does a good job here.

If you need some additional fake data to fiddle around with in your development environment, the Populator gem is handy for mass-inserting a bunch of faux data, especially in conjunction with Faker.

Note that the migrations should neither depend on nor contain actual data. They should just change the data model.

Antipattern: Clean Up That Only Works on Production Data

This is really a subset of the previous item but it’s worth considering as a special case.

If you want to fix some data that got slightly corrupted by some bad code that has been replaced, migrations aren’t a terrible way to accomplish that.

It’s not really what migrations are for, and a one-off rake task can do it just as well, but if you really want to, you can get away with it under one condition: you have to make your cleanup migration code succeed even if the database is empty (such as when a developer has just run rake db:reset; rake db:migrate).

Antipattern: Load Data

The populator gem is good for initial, mandatory data. The machinist gem is good for synthetic test data. Delete db/fixtures and everything in it. Fixtures are evil.

Wrap a rake task around the “get my development database ready” concept. This task should start with the “get my empty production database ready” task (or some subset of that which is appropriate for developer use).

If you need to load arbitrary data now and then, write an importer. Do this as a rake task, or a web UI to a bulk data importer feature. Better yet, make a web UI in your admin area which is just a wrapper around the rake task that bulk imports data. Then delegate the bulk importing to your customers so your admins can do real admin work. But don’t load data in a migration.

Antipattern: Use Rails Models in the Migration

Models evolve, but old migrations don’t change (nor should they). So when you wrote a migration that used a model, it used the old version of the model code. Then a year later the model has evolved, and the new validations on first_name and last_name fail because it used to be full_name, and that old migration that hasn’t changed has stopped working. It depended on something that did change, incompatibly.

For rockstar points, in your continuous integration environment you should run rake db:drop; rake db:create; rake db:migrate to make sure that this can never happen.

But if it has already happened, rip out the model code and replace it with Rails DSL code, with execute statements containing raw SQL code, or (if you feel like a Ruby rockstar) declare new, stripped down model classes inside your migration class that will act as stand-ins for the limited needs of the migration. See Migrating with Models for more on how to do this last trick.

Conclusion

You should always be able to do this in every Rails environment that your application has: rake db:drop; rake db:create; rake db:migrate; rake db:reset

At this point you should then be able to run rake db:test:prepare and then rake spec or rake test or whatever and have it work.

If any part of that process fails, you are missing out on the benefits of using Rails migrations.

“HI. You’re using libxml2 version 2.6.16 which is over 4 years old and has plenty of bugs. We suggest that for maximum HTML/XML parsing pleasure, you upgrade your version of libxml2 and re-install nokogiri. If you like using libxml2 version 2.6.16, but don’t like this warning, please define the constant I_KNOW_I_AM_USING_AN_OLD_AND_BUGGY_VERSION_OF_LIBXML2 before requring nokogiri.”

Aaron Kalin figured out how to fix this if you’re installing nokogiri as a system gem, but I want to use Bundler and keep my system gems down to the bare minimum. I figured out how to do this under Bundler 0.8.5.

The gems I have installed via plain old “gem install xxx” are bundler08 -v0.8.5, rake -v0.8.7, and ZenTest -v4.2.1. That’s it. Everything else is under vendor/bundler. I’m using RVM and REE 1.8.7 2009.10 as described in my previous post.

Here is a quick summary of Aaron’s blog post; this will update your libxml and libxslt libraries to reasonably recent versions. (Be my guest if you want to use libxml 2.7.7 and libxslt 1.1.26, which are current as of today, but I didn’t test those myself.)

mkdir -p ~/Downloads/XML
cd ~/Downloads/XML
curl -O ftp://xmlsoft.org/libxml2/libxml2-2.7.3.tar.gz
curl -O ftp://xmlsoft.org/libxml2/libxslt-1.1.24.tar.gz
tar xzf libxml2-2.7.3.tar.gz
tar xzf libxslt-1.1.24.tar.gz
cd ~/Downloads/XML/libxml2-2.7.3
./configure
nice make
sudo make install
cd ~/Downloads/XML/libxslt-1.1.24
./configure --with-libxml-prefix=/usr/local --with-libxml-include-prefix=/usr/local/include --with-libxml-libs-prefix=/usr/local/lib
nice make
sudo make install

Now make this YAML file and call it bundler_build_options_macosx_leopard.yml and put it in your RAILS_ROOT:

nokogiri:
  xml2-include: /usr/local/include/libxml2
  xml2-lib: /usr/local/lib

Then, to build nokogiri so that it uses the new libs you just installed:

gem bundle --build-options bundler_build_options_macosx_leopard.yml

You should now have nokogiri installed under vendor/bundler/ruby/1.8/gems, and when you run your app it should not complain about the version of libxml2 anymore.

Update: Bundler 1.0.0.beta.10 allows this too. See my other post that shows how to do it.

AvantiConveniences is a set of convenience code for Ruby on Rails applications.

ArgChecks helps you implement simple sanity-checking of arguments, like
permanent assertions or a poor man’s Design by Contract facility, so you can
write code that will Fail Fast (see http://c2.com/cgi/wiki?FailFast).

HashExtensions currently just adds the Hash#rekey method.

StringExtensions provides String quoting (not escaping) with single quotes,
double quotes, or a caller-specified quoting character, and a String#dehumanize
method to do the reverse of the String#humanize method provided by ActiveSupport.

TextFormatter provides methods for hyphenating words for word-wrapping.

URIExtensions provides URI::Generic#query_from_hash, which will create a URI
query string from a Hash.

INSTALL:
If you haven’t done this before:
gem sources -a http://gems.github.com

Then:
sudo gem install JamieFlournoy-AvantiConveniences

See also: the AvantiConveniences GitHub project page.

However, if you’re upgrading an existing project and you’re sticking with official releases (as opposed to edge Rails) like I am, your code probably needs some tweaking to work with Rails 2.2.2. Mine certainly did. Although there were a lot of failed tests with ugly stacktraces, there were only a few API changes in Rails that needed to be accomodated to fix them all. Here’s a list of the changes that broke my app, and what I had to do to get it working again.

TextHelper.truncate no longer allows you to supply the length parameter as a second argument. You have to use truncate(somestring, :length => 20) instead of truncate(somestring, 20).

I was getting an error that looked like this:

ActionView::TemplateError: wrong number of arguments (3 for 1)

The line in question is:

<%= render(:partial => 'layouts/header') %>

The problem is that the simply_helpful plugin’s behavior is now built-in; just delete the whole vendor/plugins/simply_helpful directory if you were using it, and any existing code that depends on simply_helpful’s API should work again.

I was using the tztime and tzinfo_timezone plugins, which are no longer needed now that time zone support is available via Time.zone in Rails 2.2. Delete the plugins, upgrade the tzinfo gem to 0.3.12 or uninstall any older version of it, and search for TzTime instances in your code and replace any of the occurences of Time.at(some_tztime_variable) that you had been using. TzInfo is still useful in cases such as this:

TZInfo::Timezone.get('UTC')

But since you can now embed the time zone information in a Time instance, you don’t need TzTime objects anymore.

I was using a nice hack from Technoweenie, to allow me to validate forms using the familiar ActiveRecord model validations API even if those forms were not backed by a database table (sometimes the UI just doesn’t look anything like the data model, y’know?). It broke, and I was unable to find any solutions from anyone else, so I wrote my own: EphemeralModel, for Rails 2.2.2 form validation without a DB table.

I was using ActiveRecord::Errors.default_error_messages[:invalid] in a few model validators, which is now deprecated because it’s not internationalized. The new way to ask for the same string in the currently configured language is: I18n.t(:invalid, :scope => 'activerecord.errors.messages')

Finally, the app wouldn’t start because it wants a :secret option to config.action_controller.session in config/environment.rb. I came up with something sufficiently random and now it’s fine.

I’d just like to make one last comment about this: having thorough automated tests is a huge time and sanity saver during this process. If you’re not close to 100% test coverage on your current Rails project, then your house is on fire and you need to address that immediately. Even as I write this in late 2008, I’m talking to prospective clients about contracting work, and some of them don’t do automated testing at all(!). Unless you’re in a mad dash for a demo that will save the company from financial collapse, having automated tests that verify that your code works should be priority #1. Upgrades can wait.

# Usage: in the faux-model class, include EphemeralModel and ActiveRecord::Validations
# Then just say "column :foo" to set up a property called 'foo' for validation
module EphemeralModel
    # Stubbing methods from ActiveRecord::Base that ActiveRecord::Validations may call
    def EphemeralModel.included(mod)
        def mod.self_and_descendents_from_active_record; [self]; end
        def mod.human_attribute_name(arg); arg.to_s; end
        def mod.human_name; self.name; end
        def mod.column(attr_name)
            attr_name = attr_name.to_s
            column_names.push(attr_name) unless column_names.include?(attr_name)
            attr_accessor attr_name
        end
        mod.module_eval do
            def self.column_names
                cn = self.instance_variable_get(:@column_names)
                if cn.nil?
                    cn = self.instance_variable_set(:@column_names, [])
                end
                cn
            end
        end
    end
    def save; end
    def save!; end
    def update_attribute; end
    def new_record?; end

    def initialize(initial_attributes = nil)
        initial_attributes.each{|k,v| instance_variable_set("@#{k}".to_sym, v)} if initial_attributes
    end

    def attributes
        @attributes = {}
        self.class.column_names.each do |colname|
            @attributes[colname]= instance_variable_get("@#{colname}".to_sym)
        end
        @attributes
    end

    def attribute_names
        self.class.column_names
    end

    def [](name); attributes[name.to_s]; end

    def []=(name, value)
        instance_variable_set("@#{name}".to_sym, value)
        # print "set #{name} to " + instance_variable_get("@#{name}".to_sym) + ".\n" # DEBUG
    end
end