5 quotes by the creator of PHP, Rasmus Lerdorf: I don't like programming, and I'm not a real programmer.

  • I really don't like programming. I built this tool to program less so that I could just reuse code.
  • PHP is about as exciting as your toothbrush. You use it every day, it does the job, it is a simple tool, so what? Who would want to read about toothbrushes?
  • I was really, really bad at writing parsers. I still am really bad at writing parsers. We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all.
  • There are people who actually like programming. I don't understand why they like programming.
  • I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I'll just restart apache every 10 requests.

Hat tip @igrigorik

Go Ruby!

Uninstalling and reinstalling all ruby gems

sudo gem list | cut -d" " -f1 > gem_list.txt
cat gem_list.txt | xargs sudo gem uninstall -aIx
cat gem_list.txt | xargs sudo gem install

This is useful if you ever want to just reset your gems and clean them up. Or if you upgrade to Snow Leopard and want to make sure all your native gems are in decent shape (since Snow Leopard is 64-bit).

How Superfeedr built Analytics using MongoDB

We weren’t quite sure how to build these analytics. We slowly established a set of requirements and constraints

  • Zero performance impact
  • Fully decoupled from the current infrastructure
  • Results at most hourly
  • Data is more important than graphs
  • Easily-extensible, in case we want to measure more things

This is a really interesting tech read by our friend Julien from Superfeedr.

We've been experimenting with MongoDB in-house as well. It'll be interesting how things shake out over the next year w.r.t. nosql implementations... We're also using Redis and have found that to be much faster / more reliable, though simpler in some respects.

Inspect a live running Ruby process

Are you still adding printf/puts calls and restarting your app to figure what went wrong? Sometimes, the problem is hard to reproduce, or you only discover it in production. You've got a process that exhibits the bug, but you didn't run it under ruby-debug, so there's no choice but kill it and reproduce after adding some code to inspect your program, right?

Sure not. Jamis Buck blogged about how to use GDB to inspect a live Ruby process, and showed how to get a stack-trace using Ruby's C API and some GDB scripting:

(gdb) set $ary = (int)backtrace(-1)
(gdb) set $count = *($ary+8)
(gdb) set $index = 0
(gdb) while $index < $count
>  x/1s *((int)rb_ary_entry($ary, $index)+12)
>  set $index = $index + 1

But it gets much easier than that. How about this:

(gdb) eval "caller"


(gdb) eval "local_variables"

Once you've opened that door, you get a full-powered Ruby interpreter inside GDB. Ruby's introspection capabilities do the rest. Local variables, instance variables, classes, methods, Ruby threads, object counts... evil eval can bring us pretty far. You can find the scripts to turn GDB into a sort of IRB that can attach to running processes below.

This turned out to be massively useful today while debugging some errors with the Facebook API on our live site -- it was causing zombie passenger workers.

There's something about using GDB to find problems with production instances just makes you feel cool.

ProtoMultiselect, through the magic of @github, you have grown up! Git+github = open source game changer.

Proof positive that Git and Github has changed the game when it comes to open source. I had happened upon the ProtoMultiselect code back about a year ago when we first implemented Posterous Tagging. It's an amazing little bit of JS that gives you a Mail.app / Facebook selector-like textbox. Essential.

I love autocomplete functionality, and this was one of the most complete open source autocompletes available. It was a pretty unclean codebase -- we had to do quite a bit of hacking to get it working for our tagging. (But it works!)

I hadn't thought about it until lately -- but now we're re-examining all old JS and also planning some cool functionality around address books that will require more multi-select autocomplete UI. Enter Github.

I had found thewebfellas's version of ProtoMultiselect, and from there, clicking on the Network tab, I found who else had picked up the trail, since that original repo had gone cold on March 24th. dvsandersluis picked it up... between March 24th and now, an amazing array of cleanups and fixes had gotten into this codebase. I was astonished at how much had changed between the hacky code snippet off an outdated blog post from last year to the clean, up-to-date version of today.

I forked off dvandersluis and added my own bit (a piece that we need to properly support tagging) --

And now I've also submitted back to the tree in the form of my own fork. I needed something, the codebase didn't do it, and I added it.

Code is living. It's how open source was meant to be. Github, you rock.