Am I missing any important properties?

While trying to track down some issues, I wished I had Squeak’s PointerExplorer, which makes it easy to examine the references to an object—and figure out who’s causing problems by hanging on to one.

After a quick look at a few existing tools for tracing leaks, it doesn’t appear that there’s currently any way of doing this. So I took some code from Joe Damato, updated it a bit, and implemented two things: weak arrays, and GC.heap_find().

Weak arrays work pretty much as you’d expect:

>> a = []
=> []
>> a.weak = true
=> true
>> 1000.times { a << Object.new }
=> 1000
>> GC.start
=> nil
>> a[200]
=> nil

Like the PointerExplorer, GC.heap_find scans the heap to find references to an object. Since it uses the same algorithms that the garbage collector itself uses, it won’t miss anything. (If Ruby’s mark-and-sweep collector can’t find your object, it’s not going to be kept.)

>> obj = Object.new
=> #<Object:0x1007f6900>
>> a = [obj]
=> [#<Object:0x1007f6900>]
>> h = {:foo => 2, :bar => obj}
=> {:bar=>#<Object:0x1007f6900>, :foo=>2}
>> refs = GC.heap_find(obj)
=> [{:bar=>#<Object:0x1007f6900>, :foo=>2}, [#<Object:0x1007f6900>]]
>> refs[1].object_id
=> 2151609120
>> a.object_id
=> 2151609120

One slight issue is that heap_find can’t return some objects that are traversed by Ruby’s GC, but aren’t first class Ruby objects—things like SCOPEs and VARMAPs. heap_find could indicate their presence somehow, but, since they’re not first class, they can’t be returned directly. This isn’t that big a deal: memory issues here are pretty unlikely, and any present probably indicate a bug in Ruby itself.

Because the arrays returned by heap_find are weak, you can continue to explore the object graph as far as you like, without worrying about them interfering with the results, and leading to confusing additional references.

>> refs.weak?
=> true
>> obj2 = Object.new
=> #<Object:0x1013ec9c0>
>> foo = [1, 2, obj2]
=> [1, 2, #<Object:0x1013ec9c0>]
>> GC.heap_find(obj2)
=> [[1, 2, #<Object:0x1013ec9c0>]]
>> foo.weak = true
=> true
>> GC.heap_find(obj2)
=> []

Here’s the patch for ruby 1.8.7-p174 (shipped with OS X 10.6).

Potentially most powerfully of all, developers should be able create their own plug-ins that run on the server. There should be an agreement between plug-in developers and the webmail provider that creating a plug-in automatically grants a royalty-free perpetual irrevocable worldwide (etc.) license to the provider, and that the source code to any plug-in may be merged into the main product. Though plug-ins have niche appeal, this could be a good source of new features, and a strong competitive advantage. I’d just fix Gmail if I could.

I’d happily pay for any service that got this stuff right.

$ crontab -l
0 * * * *   /Users/patrick/Binaries/clean-downloads
$ cat Binaries/clean-downloads
#!/bin/zsh
find ~/Downloads -maxdepth 1 -amin +720 -exec mv {} ~/.Trash \;

You have twelve hours to do something with whatever it is you downloaded, or it’ll end up in the Trash. I highly recommend it.

• How slowly things change. When we started Auctomatic in mid-2007, eBay was dominant but faltering, PayPal was lumbering along without any innovation, Facebook was amazing everyone (and scaring Google) with their growth, the iPhone was reshaping the cell phone industry, and everyone was talking about Twitter. Two and a half years on, that still sounds like a reasonable assessment of things. With Auctomatic, we felt this tremendous sense of urgency. That may have been good for other reasons, but it was misguided. When building something, I now think you should assume that you’ve plenty of time, and that very little will change in the interim. (This is, admittedly, the kind of rule that works until it doesn’t.)
• Tied to this, the realization that a good product is so much more important than first mover advantage. Obvious, but keeps surprising me. Facebook, the iPhone, Dropbox, Skype, etc., have an amazing array of failed predecessors.
• Succeeding at biz dev just requires endless persistence.
• Internationalization is an underexploited axis—people try to expand on the x-y plane, and ignore this third dimension. We grew our iPhone app revenue by over 200% through internationalization. The biggest competitve advantage we ever had with Auctomatic was supporting the obscure international eBay sites that the big US players ignored. I’m generalizing from pretty limited experience, but if I were a floundering start-up trying to get to cashflow positive, internationalizing is probably the first trick I’d try.
• How dangerous the assumption that you’re going to grow is: “oh, we need to build this this way, because when we’re successful, we’ll need it”. This is often used as an argument against over-engineering for scalability, but it applies more generally. Now, when coding, I try to think: “how can I write this such that if people saw my code, they’d be amazed at how little there is and how little it does”.

So here’s undop. Every time I visit a domain in ~/.bad_sites, it dims the display by 30%, gradually returning it to its previous brightness over the course of 30 seconds. It’s both an annoyance and a reminder. The effect is small enough that I don’t mind it on those occasions when I actually do want to read Twitter or Hacker News or whatever blog, but it’s jarring enough that I now subconsciously avoiding following links to them, and have mostly broken the check-for-new-stuff muscle memory.

Caveats: it only works with Safari on OS X. (Patches with support for other browsers welcome.) I’m guessing it might not be good for display backlights.

$ git-find-removal HEAD~20 'def my_important_function'