lixo.org

I’ve been working on a Ruby On Rails app for a while now (see previous post, and also Obie’s take on it), and seriously, more often than not it’s hard to stop coding; more than once I’ve looked at the taskbar and gasped in disbelief - over the past month, I’ve coded way past 2 AM after having worked the whole day, and even though I needed to wake up early the next morning, I was not tired at all. So, to put it in another words, careful - this thing is addictive.

And it’s gaining an astounding lot of momentum too, as Wilkes Joiner points out. It’s definitely a good time to have a look at it, now that the 0.11.0 version has been released. It’s still early days, and the sheer amount of functionality that’s in Rails already is somewhat disturbing. By the time this thing hits 1.0, taking over the world or entirely destroying it with it will be a matter of calling a couple of methods and putting some nice CSS on top of it.

I’ve started reading The Wisdom Of Crowds yesterday, a wonderful book about how decisions taken by groups assembled under the right conditions constantly outperform the ones taken by experts. There are numerous examples, tales and food for thought served warm and with some delicious toppings.

I’ll refrain from blurting out quotes, because there are just so many good quotes I can’t really decide on anything significantly interesting that could be taken out of context. Anyway, if you can’t take the time to read the whole thing, try Smarter than the CEO, an essay by the same author, James Surowiecki.

I reckon there’s a huge and barely explored field for great software to grow in based on the wisdom that crowds hold: most companies don’t really take into account the power of its combined intelligence, relying on higher-ups to decide on what’s important when creating a good environment for groups of employees to decide on these matters could yield more accurate decisions.

Software that helps assembling and aggregating information from those groups within a company barely exists today, and I’m trying to come up with something. Shouldn’t be too hard, actually: some companies have experimented with internal stock markets and had fabulous results, and maybe that’s a good way to go. I’d buy a lot of Dan North and Liz Keogh shares by now: there’s GeekNight next week and JBehave is surely going to be discussed.


PS: I promise the next picture will not have insects of any kind.

At my last project, we’ve been writing our acceptance tests as Fit tests, using JWebFit, part of JWebUnit. For those unfamiliar with the concept, it’s basically (and roughly) a test organized as a table. An example would speak for itself, in this case, so let’s get to one:

LogicFixtureFitTest.html:

…and so on and so forth. As you can imagine, this test lists all possible outcomes of a less-than operator. This test, when run, will repeatedly call the example.LogicFixture.lt(String, String) method, and assert its results against the ones in the ‘Expected’ column, and you get a green or red cell depending on the result:

LogicFixtureFitTest-RESULT.html:

This is pretty much what you would expect from any other explanation of a fit test, despite my poor eloquence. I promise I’ll make this a bit more interesting, though.

For example, with test methods that do, well, interesting stuff. We could go to a database, click buttons, fill forms, or whatever else comes to mind. In this particular project, a web app, we were doing all of those, plus a few more, and we ended up creating new fancy methods as we saw things being repeated over and over. For example, when we saw things like:

Login.html:

We were tempted to change it into this:

Login.html:

Which does exactly the same thing (actually, the code in OurApplicationFixture just calls enter(), enter() and click() in sequence), but it has a better representation and communicates what the test is doing a lot better, and in the same language developers and business analysts use, or at least something closer to that, which is always good in terms of total amount of hair pulled over 40 hours per week. Over time, we ended up creating a lot of these methods, and one of the challenges was organizing them so they were still manageable. We had a great idea, then: why not code test sub-routines using fit itself?

BuyTwoProducts.html:

Login.html:

Roughly, what OurEvenBetterApplicationFixture does when it can’t find a proper method on the fixture class is to look for a directory called subroutines/ under the fit test tree and find a suitable HTML file, substitute the parameters properly, execute it and include the results in the caller fit test. The end result, then, looks like this:

BuyTwoProducts-RESULT.html:

This way, people looking at the test source still see a simple “login” line, but get to look at the results (and any problems that may show up) in much more detail. I don’t really know if this is something new, and I surely don’t believe has never been thought of before, but as I’m quite new to this Fit testing thing the best way for me to be sure is to actually blog about it and see what kind of discussion it generates, if any.

I like extrapolating, though, and the obvious next step after Fit subroutines is to implement branching and looping constructs, and then some sort of closure support, just because everyone loves closures these days. I think it’s a bad idea in this particular context for an infinite number of reasons, but it actually has some kind of coolness. In fact, give this a few years, and I’m sure when we look back, we’ll all laugh and try to figure out what happened to using plain text to edit code. We’ll be programming in spreadsheets by then, and life will be lived very happily thereafter. You know, people writing hardcore macros in Excel today will be the next refactoring and code analysis masters. Come to think of it, one of the great things about the user interface of JetBrains’ MetaProgramming System is using little nifty drop-downy table cells instead of plain-text. Maybe I’m reaching here, but who knows if this is not actually a good way to go?

Yesterday I tried to set up Subversion on a Debian box I’ve got. It was awful. I mean, it took me minutes. What decent server software install can take only minutes?

What happened to the good old days, where one had to compile stuff, find out the Makefile wasn’t compatible with the platform, work out how to build the stuff by resorting to the source code, spend hours on it, and then find that a handful of dependencies were needed, and then repeat the process trying to build them? What happened to the “using Unix takes balls” crowd? Have they all got PowerBooks and turtleneck shirts, and complain about girly things like usability?

Installing Subversion was not much more than just a matter of

apt-get install subversion subversion-tools

And a few bits of chmod and chgrp, and it was working nicely, with SSH authentication and all the bells and whistles. Very, very nice.

Oh, and that probably wouldn’t be possible without Mike Mason’s great Pragmatic Version Control using Subversion, a copy of which was lying around the office desks somewhere. I grabbed it, looked at the index, found the “Installation” chapter, and a glance at it gave me enough info to get by and have the thing working (see, a few bits of chmod and chgrp can always go a long way). Joy.