Ruby on Wrecks


<itamar> I'm beginning to joy my daily ritual of watching rails screw up penny arcade
<itamar> today it switched from not showing the actual image for the comic to 'Application error (Rails)'


Has anyone else noticed how penny arcade has become the world's premier advertisement for why not to write your working PHP/Perl/Java/whatever site in Rails? Do they have any idea how bad their site sucks since the rails port?

This is slightly tongue in cheek, though: it can't possibly all be Rails's fault. It wasn't anything to write home about in PHP either. How do they manage to consistently screw this up? It's a web page with a paragraph of text and a single image, updated at most twice per day. It's not rocket science; it's not even computer science. It's barely a shell script.

Potentially Of Interest

I had about half an hour in the office today where I was listening for some background noise which made using my keyboard difficult. I killed a little bit of time making this icon with my mouse: an SVG-ization of the cool new Emacs icon that comes with Emacs 22. I am sure that somebody in the open source world would like to use it, so I hereby place said icon in the public domain. Feel free to copy and use for whatever purpose.

A Rich Source of Gremlinium

Today, Tycho makes an interesting point in Penny Arcade, which is to say, he agrees with me.

A few months ago, when I was first pimping Divmod's Vertex generic peer-to-peer system, the first application I proposed was a BitTorrent-like protocol, but with explicit support for giving users credit. There is a proof-of-concept implementation of this called "sigma" in vertex (but don't try to use it yet, it's full of horrible known bugs - it's just there if you want to help implement it).

When I first mentioned this to a few potentially interested parties, they assumed that the advantage would be increased bandwidth savings on the part of the "content provider". It doesn't provide that, and I'm not sure that one can improve on BT's savings; as Steve Holden said, the only platform Avalanche runs on is PowerPoint. When I revealed what I thought were substantial advantages, this prospective audience sighed and said that BitTorrent was great and that nobody cared about any of my features.

The advantages of a Vertex-implemented BitTorrent would be as follows:
  • Vertex provides extremely aggressive NAT-traversal code. If it can get through your firewall, it will. This is important because huge numbers of people using BitTorrent don't care that they're not transmitting data; the seeds are "fast enough" and they don't have the technical knowledge required to configure their firewalls. For some BitTorrent-based applications (such as the Blizzard downloader) such configuration is intentionally impossible; the downloader uses a fixed port number and would therefore require smarts on your gateway to forward properly. I cannot fathom how they could make such a stupid decision - that's certainly not a flaw in BitTorrent itself but it seems to be a common implementation mistake.
  • Vertex totally separates the application (file downloading) from the transport mechanism. This means a vastly reduced implementation complexity for implementors (if, like Blizzard, they think they need a totally customized "user experience", they can still use common vertex libraries, or at least implement the protocol separately).
  • Most relevant to Tycho's post, Vertex provides strong identity verification for peers. This means that you can provide non-bandwidth-related incentives for people to upload. Imagine that your character got one gold piece for every megabyte of the patch that you uploaded!


This last point I have had an especially difficult time communicating, because I thought that Tycho's point was obvious and I didn't bother to explain it.

So here's the thing: if you're a "content provider" and you use BitTorrent, it's great that it decreases your bandwidth costs, but the message you're sending to your users is, "I don't care about the experience you get using my site. I care about saving money on bandwidth." Especially given that the percentage of full-duplex capable seeders is so poor (see my point about NAT traversal) it is often significantly slower to download a file over BitTorrent than over a straight-up high-upstream link, and of course it is vastly better to simply offer it via a service like Akamai's media delivery.

If you want your users to shoulder part of the burden for you, that's great, and it can improve the experience for them provided you're using the money you've saved for something worthwhile, but at least say thank you for using their upstream. To do that, you have to know who is actually helping you more or less. Since BitTorrent has started using bits of Twisted now, hopefully by the time this project gets off the ground, it won't be some custom file-download protocol that offers this feature, it will simply be the next version of BT itself.

Thankfully Divmod has a client right now who is motivating a bit more maintenance on Vertex. I hope I can present it at the next CodeCon.

Commit Messages and Cracker Jacks

Divmod and Twisted have instituted a fairly rigorous development process over the last few months. I'm very happy with the results, but there have been several objections to the strict enforcement of apparently useless or trivial parts of the policy, especially as related to small or mechanical changes.

When I was a wee lad, I took violin lessons according to the Suzuki Method. In the Suzuki Method, the first thing you do in your violin lessons (if you are a 4-year-old, anyway) is make a "violin" out of a cracker jack box and a ruler. For months, I did nothing but sit, then stand, hold the cracker jack box, extend it outward, and place it under my chin, hold it there, remove it, tuck it under my arm, and sit back down. I had to draw a diagram, on a poster, which showed where my feet were supposed to go while performing these steps. Then I stood on that diagram, placing my feet in the appropriate positions.

You are not allowed to use a real violin until you can get every step of this exactly correct. As a kid, that was pretty cool. When you have progressed to the point where you are allowed a real violin, you get to open the box and eat the cracker jacks. Parents, however, were often unhappy with this particular trajectory of violin training. Their 4-year-olds were eating cracker jacks six months after starting violin lessons, and students in other methods (read: their hypercompetitive co-workers' children) were playing Twinkle Twinkle Little Star on their shiny new violins at Christmas and Thanksgiving, much to the approval of the assembled family.

Of course it looks ridiculous to results-obsessed American parents to be messing around with crude drawings of your feet and tiny cardboard boxes when what you're ostensibly doing is learning to play an instrument. Why not move on to the instrument directly and focus on the important parts of playing, like fingering and tone and harmonics and sight-reading and so-forth?

The Suzuki Method was invented by a japanese fellow, and it follows the japanese sensibility that requires even trivial tasks to be performed according to extremely rigid rules. Have you ever watched a sushi chef prepare a meal? The next time you do, observe what they do when they wash their hands. They will always position a bowl of water in exactly the same position. They will always dip their hands in the water the same number of times. The knife will always be placed in the same position, picked up and put down at the same exact moments before and after slicing the fish. I don't know how to prepare sushi myself, but I've observed the pattern at every sushi bar I've sat in, from San Jose to Austin to Florida.

There is a reason why we focus on the small details of the development process. If there is an obviously correct way to do something, it should be done that way. Why expend effort on every method trying to decide whether it "should" be documented? Document everything. Why create elaborate rules for what "should" be tested? Test everything.

Those kids who were playing "twinkle twinkle" six months before I was? Well, I got to play with them later, in school and community orchestras. Some of them even became quite good violinists. However, there were certain differences you can easily pick up on. You can spot a Suzuki student because they sit straight; they hold the bow properly and lift the violin with their chin, not with their arm. A less methodical violinist will slouch, hold the violin wrong, hold the bow at an angle, and generally require more effort to play even simple songs. In fact, they will especially require more effort on simple songs, because the Suzuki student has every automatic aspect of playing completely ingrained in their muscle memory. No conscious thought is expended on the things that don't require it.

Not all the first-chair violinists I've played with learned on the Suzuki method, but they all know how to hold the instrument correctly without thinking about it.

Better Blog Next Time

I am pretty unhappy with the way my "paying if you should" essay came out. I am trying to pare it down, and maybe split it up into 3 or 4 more coherent pieces where I'm saying one thing that makes sense.


If you couldn't really figure out what I was trying to get across, it's because I was doing a terrible job of expressing myself. Please read the next version, and try to forget about the previous one.