Patrick Collison » blog

Gmail proved that, despite the apparently high switching costs, a new webmail client can quickly get a lot of traction. There’s room now to do to Gmail what Gmail did to everything else. The replacement should have some concept of workflow (”archive, but remind me to respond tomorrow”, “send, and alert me if I don’t get a response within a few days”), some concept of teams and colleagues (allow threads to be shared as a first-class object, rather than flailing around with forwards and CC lines), be some way smart about mining the semi-structured mails going through the system (flight booking emails should be automatically annotated with .ics files), know something about prioritization (I like Twitter DMs because of the assumption that they’ll go to a mobile device. If I’ve sent more than 20 emails to someone, they should have the option of copying their mail to me as an SMS).

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.

This has solved the eternal “there’s 3GB of stuff in my Downloads directory that I don’t feel comfortable deleting” problem for me:

$ 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.

Like most internet users, I waste too much time on the web. Despite that, I’ve never had much luck with the apps that set out to solve this, like Freedom or RescueTime. They feel too heavy-handed. Instead, I want fairly repetitive and annoying prods that make wasting time less fun—the equivalent of small electric shocks, counterbalancing the Dopamine hits.

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.

Steven Troughton-Smith is a very talented iPhone developer from Dublin, with a bunch of cool apps under his belt. His blog is full of useful iPhone tidbits (Using Dynamic Library Injection with the iPhone Simulator, On Speed, Development & Design).

Anyway, the cool news is that he’s now going to be spending some time hacking on the offline Wikipedia iPhone app. Stay tuned to see what cool features he cooks up.

Back To My Mac seemed like a neat feature when Steve demoed it back at WWDC 07, but very little attention seems to have been paid to it since.

Remote NAT traversal for screen sharing and AFP is cool and all, but the most useful part is hardly mentioned anywhere: Back To My Mac can automatically establish on-the-fly tunnels to any machine with Back To My Mac enabled. You can just ssh foobar.joebloggs.members.mac.com, or curl something directly from the web server, or whatever. So long as you can make outgoing connections, it should work around any routers, firewalls, and other wrinkles in the network topology.

The catch is that it only works over IPv6. sshd on OS X has IPv6 enabled by default, as does Apache, but a lot of other stuff doesn’t.

I haven’t figured out how it works yet. It’s definitely not a straight IPv6 tunnel—the source IP of any connection is a private address (which kinda seems to defeat the purpose of using IPv6 in the first place). Any info or pointers appreciated.

Update: In the comments, JH points out that it’s not a private address, but an RFC 4193 unique local address.

Economic theory suggests that financial innovation must lead to failures. And, in particular, since successful innovations are hard to predict, the infrastructure necessary to support innovation needs to lag the innovations themselves, which increases the probability that controls will be insufficient at times to prevent breakdowns in governance mechanisms. Failures, however, do not lead to the conclusion that re-regulation will succeed in stemming future failures. Or that society will be better off with fewer freedoms. Although governments are able to regulate organisational forms, they are unable to regulate the services provided by competing entities, many yet to be born. Organisational forms change with financial innovations. Although functions of finance remain static and are similar in Africa, Asia, Europe and the United States, their provision is dynamic as entities attempt to profit by providing services at lower cost and greater benefit than competing alternatives.

—Myron Scholes (yeah, that Scholes), debating Joseph Stiglitz.

While working on some web analytics software a few weeks ago, I wrote a dirty hack to enable pictures in SLIME REPLs. The implementation is ugly, but I think the concept is neat:

You can grab the patch against CVS SLIME here.

Yanking pictures back into the REPL works fine too, so you can do something like (defparameter *my-chart* [picture-object]).

Sample usage:

(defparameter *flickr-url* "http://www.flickr.com/search/?q=~A&s=int")

(defun flickr-pic (search)
  (let ((html (drakma:http-request (format nil *flickr-url* search))))
    (cl-ppcre:register-groups-bind (url)
        ("photo_container.+img src=\"([^\"]+)\"" html)
      (swank:make-picture :url url :type 'jpeg))))

(flickr-pic "linux")

Update (22/06): To clarify in response to the reddit thread, this is a dirty proof-of-concept that resulted from an hour of hacking, and obviously shouldn’t be merged into mainline SLIME as it stands. See the slime-devel thread for the discussion surrounding it. With that said, it should be fairly straightforward to rework it as a saner contrib module.

Some sweet work by Chris Ball and Wade Brainerd has resulted in the iPhone app I wrote for offline browsing of Wikipedia being ported to the OLPC. From Chris’s email:

We’re going to be shipping the result to Peru on tens of thousands of laptops in the near future, and it should go up to hundreds of thousands if the other South American countries with OLPC deployments decide to include it in their builds too.

The source is available in the OLPC repository.

Awesome!

Sho Fukamachi has a spectacularly uninformed piece on MagLev and language implementation. He writes:

There are about 5 serious, credible, working Ruby implementations - MRI, YARV, JRuby, Rubinius, and IronRuby. They all have highly intelligent, experienced, dedicated staff who know a lot more about writing compilers and VMs than I could ever hope to learn. […] Do you seriously think that all these smart people, writing (and collaborating on) all these projects have somehow missed the magic technique that’s going to make Ruby run 60x faster?

Fukamachi distorts things (he goes from “up to 60x faster” to the unqualified “60x faster”), but to the underlying question—”despite all the work that’s been done on Ruby VMs, can MagLev really be hugely faster?”—the answer is an emphatic yes.

For a start, MRI is neither a compiler or a VM—it’s an interpreter. MagLev/GemStone compiles to bytecodes which are then JIT’ed to native code. MRI uses a non-compacting mark-and-sweep garbage collector; GemStone uses a generational collector. GemStone uses inline caches to speed message sends. And so on. There’s no “magic technique”. GemStone have been working on this implementation for decades. Like compound interest, incremental improvements over so many years tend to add up.

But a broad 10x speedup across the whole language beggars belief. It should be impossible. Actually, I’m going to come right out and say it is impossible, until conclusively proven otherwise, to make a fully compatible ruby implementation that’s more than two or three times faster than today’s best.

These kind of predictions are why we should have a site that stores quotes and holds people accountable. Look at Ruby’s performance on the language shootout. If Ruby was 10x faster, it’d still be slower than Python (Psyco) and Lua (LuaJIT).

As it happens, I write a lot of Common Lisp, which is both more flexible than Ruby, and (according to the shootout) runs 37x faster. I don’t know if MagLev will actually be 10x faster when it’s released, but it’s uninformed burbling to claim that such a speedup is impossible.

Benchmarks on a system which isn’t even partially compatible with Ruby are utterly worthless. I can write some routine which messes around with arrays in C which is a hundred times faster than Ruby. […] Who knows what they actually are, how tuned they are, whether they’re capable of doing anything other than running those benchmarks fast (I doubt it).

“Isn’t even partially compatible”? Maybe he missed the part where MagLev ran WEBrick.

And wow ..! A shared memory cache! Finally, Rails can cast off that shared-nothing millstone around its neck. Except, of course, that shared-nothing is one of its main selling points. If you want to share objects use the database! That’s what it’s there for!

A Rails deployment is not shared-nothing (unless each scaling unit has its own database, and each request contains enough information to route it to the correct node).

Except of course that OODBs have been around for decades, and the last time I checked, we’re all still using 3rd normal form. If OODBs were the solution to all scaling’s ills then Facebook would be using Caché, not MySQL. Guess which one they’re using.

Facebook scales through aggressive use of memcached and abandonment of 3NF.

This credulity and blind bandwagon-jumping is the single worst thing about the Rails community.

Mindless ranting is well up there too.

Disclaimer: Avi and the rest of the MagLev team are friends of mine.

Update (05/06): As expecting, preliminary benchmarking Antonio Cangiano shows that MagLev is indeed hugely faster than MRI (and only marginally slower than C++).