lixo.org

It looks like we’re having a Christmas party at the Old Bank of England, next December 12. For the first time since perhaps the launch of the Apple Store, people from Python, Django, TurboGears, Ruby, Rails, Java, Perl, Catalyst, Maypole and Motorola 68k and 6052 Assembly communities are getting together.

This time, instead of lusting and buying expensive hardware covered with shiny brushed metal and highly scratchable white plastic, we’ll be having beer, the obligatory plate full of chips that last for about 10 seconds and a whole lot of great conversation. As the Python, Java and Perl inquisitions will be within a few feet apart, burning people at a stake can be considered.

Leave a comment here if you intend to turn up.

We’ve started using PMD a few days ago at our current project to analyze a whole lot of legacy code. I was browsing around the website looking for documentation on rules written in XPath (as we have a few project-specific metrics, we’ll have to write some new simple rules) and ended up clicking on to the PMD Scoreboard, only to find out that they were, apart from generating the usual metrics, linking to a DOOM map file.

The map file contains a number of those nasty explosive barrels that varies according to the number of warnings generated by PMD. Pretty much like psDooM, where Unix processes are represented as monsters, but more programmable via – guess what – a Ruby API, Ruby-DOOM. How cool is that?

Can someone with loads of free time please make DamageControl or CruiseControl do this, too? With a bit of shell-scripting glue, you could have a Continuous Integration arcade machine with a new game starting after every build. This would probably encourage developers to keep the build times short, so they can play another round

I just stumbled across Francis Hwang’s urirequire library, via _why, and I just had one of those ‘why didn’t I come up with this?’ moments.

If you haven’t played with Ruby yet, or just don’t feel like clicking the link, here’s what it does: at every require (which has similar mechanics to its Java and Python import counterparts) that starts with http://, https:// or ftp://, it reaches for the contents of the file remotely and eval()s them. It actually overwrites the standard require method, and this way, it can load any Ruby script that can reach and just use it, instantly.

There are, of course, very serious security implications with running remote code just like that, but keeping in mind that we have Ruby’s tainting mechanism and that with just a one-line change to one of the regexes used we can have code that’s only loaded from trusted (or local) servers, the safety part of it can be reasonably covered. Of course, if you want to get serious about it, code signing might be the best option, and I don’t see any technical impediments to that.

Essentially, we have the most interesting bit of Maven, the downloading of dependencies, automatically built in. Want everything running on the bleeding edge? Point the require to a ViewCVS HEAD page, like this one for urirequire. Want to use a specific version? No worries – point it to a different ViewCVS page. Or have servers seamlessly bootstrapping their installation and configuration from a central location, Java WebStart-like desktop applications updating at start-up, WebService client libraries delivered by the server on demand, there are so many interesting things that can be done with this.

Certainly, most of them have indeed been done before, but not with the same flare, not with the same piece-of-cakeness to it.