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.

/usr/local/bin/macirb:60:in `block': No such file or directory - open() failed (Errno::ENOENT)
	from /usr/local/bin/macirb:9:in `block'
	from /usr/local/bin/macirb:7:in `
'

If you’re seeing this, you need to do something like this:

# preserve history across irb executions:
require 'irb/completion'
unless 'macruby' == RUBY_ENGINE
  require 'irb/ext/save-history'
  ARGV.concat [ "--readline"]
end
IRB.conf[:SAVE_HISTORY] = 100
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb-save-history"

What I changed was to add lines 2 and 5 from that excerpt, making lines 3 and 4 only run if I’m *not* using macirb. If you’re getting the same error from macirb, this (or something similar) should fix it.

The monit configuration stanza (in monitrc) looks like this:

check process mailtunnel with pidfile /var/run/autossh.pid
  start program = "/root/start_mailtunnel.sh"
  stop program = "/root/stop_mailtunnel.sh"
  if changed pid then alert
  if failed host localhost port 2525 protocol smtp with timeout 30 seconds then alert
  if 3 restarts within 5 cycles then timeout

start_mailtunnel.sh looks like this:

#!/bin/sh
export AUTOSSH_PIDFILE=/var/run/autossh.pid
/usr/bin/autossh -N mailtunnel &

And that -N is the key to making ssh happily connect and not run a remote shell, which would want a tty on stdin. That’s how you tell it to just be a port-forwarding connection.

The ssh mailtunnel config just has some port forwarding rules, and “ExitOnForwardFailure yes”.

Finally, stop_mailtunnel.sh looks like this:

#!/bin/sh
test -e /var/run/autossh.pid && kill `cat /var/run/autossh.pid`

So now instead of making a YAML file and referring to it, pass the options like this:

bundle config build.nokogiri \
--with-xml2-include=/usr/local/include/libxml2 \
--with-xml2-lib=/usr/local/lib

The problem would appear unpredictably, and defied my attempts to reproduce it, with one exception: Netflix Instant streaming would invariably result in a failure in less than 15 minutes of play. I tried updating the Silverlight plugin, and then simply not ever using Netflix streaming, but that didn’t help. Eventually I found that running anything that kept the CPU near 100% utilization for a minute or so would trigger the problem. Could it be a thermal issue?

I use iStat Menus so I was able to easily see that my CPU temperature was over 160°F whenever this happened, and my fan speed was about 6000 RPM. I tried placing something under my laptop to increase airflow underneath it (simulating my wife’s Griffin Elevator), but that didn’t help. I did some searching to see if that CPU temperature and fan speed were unusual, and found the Intel Mac Temperature Database. It seems like other folks have seen higher CPU temperatures than 160°F without problems, so that probably wasn’t it.

I decided to dig around a bit to see if 6000 RPM was a reasonable fan speed. Apparently not; several pages I found mentioned that MacBook Pros get uncomfortably hot because the standard temperature to fan speed profile that Apple used wasn’t enough to keep the laptop cool, and so some people use smcFanControl to increase the minimum fan speed to 4000 RPM. I installed smcFanControl and found that 6000 RPM is the maximum fan speed it allows.

I wondered if maybe my laptop was getting hot, and the fans were working as hard as they could and still couldn’t keep the temperature under control?

Following that hypothesis led me to this post in the "Macbook overheating?" thread on MacRumors. Since I’ve upgraded the hard drive in every MacBook I’ve owned, I have the tools to open one up already, and the excellent iFixIt Fan Replacement Instructions were almost the same as what I’d had to do for a hard disk replacement, so I decided to go ahead and open it up and take a look myself.

Here’s what I found:

The right fan filter is almost completely clogged. (click to enlarge)

The left fan filter is also almost completely clogged. (click to enlarge)

Jackpot. I vacuumed the dust out. Here’s what it’s supposed to look like:

That's much better.

The left fan filter is now clean-ish.

I put it back together, and the problem is gone! Cost: $0.

As a bonus, it runs cooler so it isn’t painful to use on my lap, and since the fans don’t have to work so hard, it’s quieter than before.

So if you have a flaky MacBook Pro of similar age that’s running strangely hot and your fans are running at full blast, maybe you should open it up and see what your dust situation is. Like I said, my guess is that every single MacBook Pro will experience this problem sooner or later.

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.

`method_missing': No sham defined for name

It’s discussed in the machinist Google Group as well.

It’s because of a wacky hack that’s part of Machinist that overrides Module.name so you can do Sham.name, but ZenTest expects Module.name to do what it does normally.

I have a fix for this.

I sent notahat a pull request via GitHub, so hopefully it’ll be merged by notahat into the official machinist gem, but until that happens you can try mine. I published the gem as JamieFlournoy-machinist to rubygems.org.

Try ‘gem install JamieFlournoy-machinist -v 1.0.6′ and see if it works for you. It does for me with ZenTest 4.2.1, autotest-rails 4.1.0, and a Rails 2.3.5 project.

(my machinist fork on github)

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.