a tornado of razorblades

Ryan Dahl’s talk on Node.js presents a clear and cogent argument for event-driven I/O. The first ten minutes could just as easily be a pitch for EventMachine or Twisted (touching on one of my own battlecries: threads suck). But he then follows on by pointing out that these libraries will never be truly intuitive to use, because event-driven I/O is enough of a fundamental shift that it requires deep language integration. This is why he ceated Node.js: Javascript, it turns out, is a fundamentally event-driven language because of its origins in the browser. I find it interesting to note that this is also the exact argument for Erlang.

I’ve given over maintenance of RestClient to Julien Kirch (archiloque). He's got a 1.1 release now in Gemcutter/Rubyforge, with some hot new features:

Phil Wainewright gives us Cloud delusions at the turn of the decade. Such as:

Tim Lind writes about Innovation in Database Technology:

Nick Codignotto writes about my QCon talk:

That’s what I asked myself one day after noticing a bunch of “The End of” headlines. We’ve reached The End of History because the Western liberal democracy is the “end point of humanity’s sociocultural evolution and the final form of human government.” We’ve reached The End of Science because of the “fact that there aren’t going to be any obvious, cataclysmic revolutions.” We’ve even reached The End of Theory because all answers can be found in the continuous stream of data we’re collecting. And doesn’t always seem like we’re at The End of the World?

… if I really don’t think any of those other “end of” ideas are true, then we probably haven’t really reached the end of scaling either. More than likely what we’ve reached is the end of my vision. Time to get my eyes checked.

Current systems were built in an era where resources were incredibly expensive, and every computing system was watched over by a collection of wizards in white lab coats, responsible for the care, feeding, tuning and optimization of the system. In that era, computers were expensive and people were cheap. Today we have the reverse. Personnel costs are the dominant expense in an IT shop.

“Science” and “reason” are two words often spoken alongside each other - almost as if they were the same thing. Both are approaches to seeking truths about the world around us; they complement each other, but each is distinct.

Pony is a little project I started a year ago for quickly and simply sending mail from Ruby. The project showed a lot of promise, and many people were excited about it (as you can tell by the 30+ forks on Github); but I never found the time to take it to its full fruition.

Ruby gem repositories are a bit of a headache right now. The current options:

• Rubyforge - In addition to being a gem host, Rubyforge has lots of features you may (but probably don’t) care about. Sourceforge-style projects, revision control, mailing lists, and so on. gets in the way of the one thing you certainly DO care about: publishing gems. Putting gems on Rubyforge is a very manual process (though Jeweler and others offer automation workarounds). Gem propagation is slow, as long as 24 hours to propagate to all mirrors.
• Github - Publish gems to gems.github.com by bumping your revision number and then git push. (Deploying with git push makes sense to me, naturally.) Typically they get built within ten minutes. Github is good for diversity since every fork can have their own gem, but this is its strength as well as its weakness. Having a canonical place to look up the primary version of a gem, in particular for automated dependency resolution, makes Rubyforge still the top pick for publishing major gems.