ruby's sprintf considered harmful

irb(main):001:0> sprintf("%d", "01")
=> "1"
irb(main):002:0> sprintf("%d", "02")
=> "2"
irb(main):003:0> sprintf("%d", "03")
=> "3"
irb(main):004:0> sprintf("%d", "04")
=> "4"
irb(main):005:0> sprintf("%d", "05")
=> "5"
irb(main):006:0> sprintf("%d", "06")
=> "6"
irb(main):007:0> sprintf("%d", "07")
=> "7"
irb(main):008:0> sprintf("%d", "08")
ArgumentError: invalid value for Integer: "08"
from (irb):8:in `sprintf'
from (irb):8
irb(main):009:0> sprintf("%d", "09")
ArgumentError: invalid value for Integer: "09"
from (irb):9:in `sprintf'
from (irb):9
irb(main):010:0> sprintf("%d", "10")
=> "10"
irb(main):011:0> sprintf("%d", "11")
=> "11"
irb(main):012:0> sprintf("%d", "12")
=> "12"

Of course, this bug's been known for years.

unexpectedly dangerous commands

rsync! unexpectedly dangerous!

rsync -a . root@pom:~
sending incremental file list
./
.acl
README.txt

oops, I should have specified a sub-directory.
and then...

ssh root@pom -i ~/.ssh/id-key
root@pom's password:


ssh no longer accepts my key.
because rsync's "-a" flag changed the ownership of the target directory

(rails) naming chained named scopes

Is nobody doing this?

Rails named scopes are chainable, right? Here's a traditional example:

class Story < ActiveRecord::Base
  named_scope :hilarious, :conditions => ["type = ?","comedy"]
  named_scope :popular, :conditions => ["popularity_level > ?", 3]
end

and then you can ask for Story.popular.hilarious.all

But it didn't take much complexity for me to want to make a named scopes that represented a chain of named scopes.
Here's my first draft of a solution:

  named_scope :hilarious_and_popular, lambda{ self.hilarious.popular.scope(:find) }

It's a little ugly, but it seems to work.

Story.popular_and_hilarious.all.should == Story.popular.hilarious.all

TheSans

The guy who developed Inconsolata namechecked TheSans

I was particularly struck by the beauty of Luc(as) de Groot's Consolas, which is his monospaced design for Microsoft's upcoming Vista release. This font, similar to his earlier TheSansMono, demonstrated clearly to me that monospaced fonts do not have to suck.‡

And that piqued my curiosity. After a few days of hunting, I found a source that could get me the font for less than the list price of $Ridiculous

Even though it was explicitly designed for programming, it's a little funny looking. And the zeros aren't dotted or crossed.

in VIM


in Gnome Terminal

anti-aliasing nightmare on debian

Debian mysteriously turned on font-anti-aliasing when I upgraded my laptop a few days ago. I guess that's fine, but suddenly my terminal got completely unreadable.
before


after


I thought about turning it antialiasing off -- and I still may -- but it occurred to me that I could probably do better.
I asked around, and I found a few shootouts, including Jeff Atwood's, but none for my exact setup.
The problem is, Linux/X11's font renderer isn't really ClearType. Also, different applications seem to render the same font different ways: VIM and Gnome Terminal sometimes show the same character in the same font in a dramatically different way.

Now I've got a handful of beautiful monospace fonts, but I can't seem to decide which to use. I'll post some examples here, as I get time to make screenshots.

So far, I've got:

• Andale Mono
• Consolas
• Consolas
• DejaVu Sans
• Inconsolata
• TheSans Mono
• Bitstream Vera

I don't have Monoco or Pragmata, but maybe I'll find them later.

Rails 2.2.2 is a lemon

There's one bug that makes my life miserable in all sorts of ways. It's the Catch-22 that you often can't run rake tasks if any of your models fail to compile.
It seems to be a bit of a heisenbug:
http://rails.lighthouseapp.com/projects/8994/tickets/1548-gem-tasks-fail-when-cache_classestrue
http://rails.lighthouseapp.com/projects/8994/tickets/802-eager-load-application-classes-can-block-migration
http://www.redmine.org/issues/show/2441

I've seen it bite me:

• trying to migrate up fields in the database, while a model was trying to call "alias" on the field


• trying to automatically install a gem dependency, including while a model was trying to mixin a module from that gem


• trying to run specs in a plugin when the app it was plugged into had syntax errors in a model

Gaaah.

programming languages that I still can't read:

1. LISP (and scheme)
2. C++ Templates

which suggests I need to take some time to really grok macros.

debian linux: bigmem gives you highmem and you need it or you'll be missing memory

if you're running a debian system, make sure you have a bigmem kernel installed, like this one, or memory above (somewhat less than) 1GB will be ignored.

before
sudo grep -i memory /var/log/dmesg
[ 0.004000] Memory: 899224k/917504k available (1693k kernel code, 17724k reserved, 746k data, 320k init, 0k highmem)


after
sudo grep -i memory /var/log/dmesg
[ 0.004000] Memory: 2059204k/2087744k available (1834k kernel code, 27260k reserved, 788k data, 256k init, 1170240k highmem)


Now I can stop blaming firefox.

Update:
I've become convinced that this is a bug in Debian's 2.6.26 image. The previous version (2.6.24) had "highmem" (memory above 1GB) turned on even if "bigmem" (memory above 4GB) was turned off.
(I think. Someone should confirm this.)

mixed types

In scala, it's possible to mix parameterized types (e.g. TypeOne[T]) with inheritance (e.g. TypeOneTwo extends TypeOne[TypeTwo] )
but it's complicated.
Lesson learned: if it's possible to just pick one or the other (pure inheritance or pure parametrization), do so.

more on that later.

gij is a bad citizen

I think I've found what was going on with my scala interpreter. The debian scala package depends on gij, the GNU Interpreter for Java. THIS IS BAD. I didn't notice it get installed, but suddenly everything that called java on my system was filling up system memory, going into swap, filling up the entire swap, and crashing. I suspect that if I install a version of scala that uses the real java interpreter, it won't use 1GB of RAM to call 'hello world'.
Come on debian. Java is GPL now. Let's get out of the ghetto.

TO: larry drebes <ltd@janrain.com>

Larry, I think it is despicable that the same company that was responsible for shepherding the OpenID 2.0 spec is now selling a proprietary product that capitalizes on the failures of that spec. I think it is obscene that the open source libraries that your company maintains^[1] are now being pitched as excessively complicated^[2] so that you can sell a proprietary wrapper for them. This is a fundamental conflict of interest.

~Jesse Wolfe