Ecto and WordPress 2.1

WordPress, the software that powers this blog, released a new version recently and I, like many others, upgraded right away. As it turns out, there’s a minor bug in the XMLRPC handling that breaks my favorite blogging client Ecto.

If you’re using Ecto and WordPress, you can apply the patch or you’ll have to wait for the next maintenance release of WordPress.

Getting gem to work in Ubuntu Dapper

Typically, you would install rubygems like so:

tar xfvz rubygems-0.8.11.tgz

cd rubygems-0.8.11
sudo ruby setup.rb

Unfortunately, attempting to install anything will generate an error:

sudo gem install rails –include-dependencies
ERROR: While executing gem … (Gem::GemNotFoundException)
Could not find rails (> 0) in the repository

As I understand it, the Ruby package will look in /usr/lib/ruby/gems, but the rubygems tarball will look in /var/lib/gems. To get around this, create a symbolic link:

sudo ln -s /usr/lib/ruby/gems/ /var/lib/gems
sudo gem update –system
sudo gem install rails –include-dependencies

The most disappointing gadget of 2005: the Nokia 770 Internet Tablet

I had been excited by the prospects of the Nokia 770 from the moment I read about it on Planet GNOME. An internet tablet that ran Open Source Software and used GNOME/GStreamer bits. It was hard to not be excited. The early reports from the people who received developer units was promising. Software was being ported and written, and things seemed to be progressing by all accounts.

Nokia 770

The Nokia 770 was finally released, but only available online. I waited patiently for them to appear locally. Jorge finally spotted one in the wild, at a CompUSA in Michigan. I braved a snow storm and headed out to my local CompUSA and picked up the only one in inventory. I was almost giddy when I got home and plugged it in to charge. And then I used it.

The review Eric wrote for Ars Technica sums up my feelings on it nicely. I really wanted to like the 770. It had the potential to be a great device but severely fell short on expectations. The hardware seems underpowered, with the lack of RAM crippling the performance. Beyond that, the software itself was buggy — even for a first release. I could forgive the occasional glitch or two and wait for an update but the persistent issues with the UI — slow visual response to operations, applications crashing or refusing to start without restarting the device and the minimal working configuration options made it a profound disappointment.

Apparently I’m not the only one to return the Nokia 770, either. When Jorge returned his, the manager came to talk to him. He wanted to know if it was really that bad, because his store had seen a 100% return rate on the device. Let that sink in for a minute: every single person who purchased the Nokia 770 at that store returned it. That doesn’t bode well for a future revision of the device to address the flaws in this virgin release. Nokia had a great idea, but the poor execution leads me to proclaim the Nokia 770 the most disappointing gadget of 2005. Better luck next year, guys.


I was chatting on irc and organizing my wallpaper when I realized that there was no way to set my background image directly through Nautilus. I cracked open Anjuta and got to work.

Here is the result: nautilus-wallpaper

I still need to wrap my brain around autoconf, automake, etc. I did manage to hack the Makefiles so that the extension is installed to prefix/lib/nautilus/extensions-1.0. Hopefully there aren’t any other quirks with that.

Where am I?

Just a little bit of code I’ve been working on. Call this a proof-of-concept to test the geo-targetting library that I’m using. Taking that (a commercial product) and combining it with the Google Maps API, I’ve come up with something kind of fun:

Where am I?

It’s not 100% accurate and it only goes to the city level but it’s close enough for most purposes I need it for. It’s some pretty interesting technology, too. My next step is extending it to not only target the city you (or your ISP) is in, but other cities around you in a certain mile radius.

Benchmarking Apache

I’m writing a new web application using mod_perl 2.0. It’s heavy on network I/O so I’m doing some benchmarking and testing with simulated I/O to see just how many requests/second I can expect a single server to handle. While reading through Practical mod_perl I discovered one of the greatest tools ever: ab.

stone@moradin:~ $ ab -n 5000 -c 10 http://localhost/echo
This is ApacheBench, Version 2.0.41-dev < $Revision: 1.141 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
Copyright (c) 1998-2002 The Apache Software Foundation,

Benchmarking localhost (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Finished 5000 requests

Server Software: Apache/2.0.54
Server Hostname: localhost
Server Port: 80

Document Path: /echo
Document Length: 33 bytes

Concurrency Level: 10
Time taken for tests: 2.326156 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Total transferred: 1145916 bytes
HTML transferred: 165132 bytes
Requests per second: 2149.47 [#/sec] (mean)
Time per request: 4.652 [ms] (mean)
Time per request: 0.465 [ms] (mean, across all concurrent requests)
Transfer rate: 481.05 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.7 1 8
Processing: 2 2 1.2 3 10
Waiting: 0 1 0.9 2 8
Total: 3 3 1.2 4 11
WARNING: The median and mean for the waiting time are not within a normal deviation
These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 4
95% 5
98% 7
99% 7
100% 11 (longest request)

This is awesome. Not only does it rock, but it’s included by default with Apache.

Quickie: Browser Detection

I haven’t had much time to do anything but sleep or work the last few weeks but I had to take a quick break to share something very, very cool.

I needed to add some browser detection code to my current project. This is such a standard thing I knew someone had to have written a version that I could use and lo and behold, Mozilla has done it: The Ultimate JavaScript Client Sniffer.

The page is marked as obsolete and a historical reference but that’s okay with me. I’m trying to detect obsolete browsers, so I figure it’s appropriate.

Reviving dead hardware: IBM Thinkpad 600

I had an old IBM Thinkpad that I bought used at a local computer show for Dena. A Pentium II 233Mhz with a 5G hard drive and 192M of PC100 RAM. Not exactly high end but hey, it’s a Thinkpad and it was fairly cheap.

After she got her Powerbook I installed Debian on it and used it as a backup laptop. A buddy of mine needed a machine for a while so I lent him the Thinkpad. I eventually got it back a year or so later but it wouldn’t boot. Instead it greeted me with the BIOS error code “161, 192, 163″, which is computer speak for “What the fuck, I can’t remember who or what I am.” I did a little googling and found that this Thinkpad uses a very standard battery for CMOS, the CR2025, which can be bought damn near anywhere. I picked one up at Radio Shack for under $3.50 with tax.

Inside the Thinkpad 600

Getting to the BIOS battery is painfully easy. Remove the cover housing the memory and pull the top piece of memory. You might be able to work around it but why bother. From there, you can disconnect the battery lead and pull it free. It’s just sitting there waiting for attention.

Liberating the CMOS battery

The guy at Radio Shack was in awe of the yellowness of the battery. Apparently he’s unfamiliar with modern marvels such as “shrink-wrapped plastic”. In any case, we’ll be cutting off the plastic coating shortly.

Assemble the new battery

Cut away the plastic coating. The negative and positive leads are stamped into the surface of the battery so you have to pry them off carefully. I used the flat blade of a screwdriver to work the lead away from the battery.

Putting it all together

Putting it back together is a bit of a cheap hack but it seems to work well enough. I cut small strips of electrical tape to secure the leads to the battery. I made sure to wrap the exposed leads to the wire so that there is no chance of them coming into contact with each other or anything else metallic in the case. Then I wrapped the entire thing for safe measure. Putting the battery back in place is easy, just reverse the process. Tighten it up and you’re ready to go.

The first time you power it up you’ll get another BIOS error code, this one telling you that you need to set the date/time. It’s an ugly screen but it works.

This quick and simple hack has given this old Thinkpad a new life. Armed with a fresh install of Ubuntu and a wireless card, I’ll be rigging this up as a semi-permanent member of my wardriving setup.

C# Gripe: enum base types

As a whole I love C# but sometimes I find some quirk that I just don’t understand. I’m sure there is a reasonable explanation of why it works the way it does but I don’t know what it is.

I was building a Gtk.TreeView last night and setup an enum for each column in the TreeView. No big deal, right? The enum looks something like this:

enum Fields
enum1 = 0,

Then, to build the column I do something like this:

TreeViewColumn col = new TreeViewColumn ();
CellRenderer NameRenderer = new CellRendererText ();
col.PackStart (NameRenderer, true);
col.AddAttribute (NameRenderer, "text", (int)Fields.Keyword);

Notice on that last line that I have to cast the enum member to an int, even though the type of the enum is int, you still have to cast its value.

You can specify the base type of an enumerator, but it defaults to an int. You could do this (and I tried) but it doesn’t change anything:

enum Fields : int
enum1 = 0,

It would be nice to not need to cast the value of the enum, especially given the ability to explicitly set the type of the enum. I don’t know the internals of how the compiler works nor have I read the CLR specification. It’s just annoying to to tell an enum that it’s an int, only have to remind it of that fact every time you use it.

Professional Courtesy

So I sit down tonight to make some layout changes to a client’s website. The changes were minor, moving a form from the bottom of the page to the top and shifting some data around. No big deal, right? The code in question involves some external javascript code supplied by a third-party vendor. No big deal, I thought. Famous last words.

I move the code around and refresh the page. There is significant lag while the browser tries to render the form. Odd, I think, but maybe the server the javascript is being pulled from is slow. Better to pull the javascript local, right? I pull the code down and crack it open, with the intent of either embedding it directly in the page or at least pull it from a local file.

Holy shit what a disaster.

The file consisted of 5 lines of code, only one of which was actually necessary. The problem was that the single line was approximately 46,838 characters long. Yes, you read that right: 46,838 characters.

Let this serve as a public plea to anyone who develops web applications in any form: For the love of all that is sacred, never, ever, neglect the endline. Endline characters are my friend. They should be your friend, too. If you can’t grasp the fact that an application, especially a web browser, might have problems handling FOURTY SIX THOUSAND characters without a line break, then I have one favor to ask: find a new line of work. People like you make it more difficult for people like me to do my job. Sure, I get to play the part of hero when I show my client their “new and improved website” that loads an order of magnitude faster because I simply applied sane whitespace rules. At the end of the day, however, I would rather spend my time doing my job and not cleaning up your crap.