lixo.org

Every morning, you have a shower and put some clean socks on. You might still wear the same trousers as the other day, or that t-shirt you wore last friday. Or even an inside-out pair of boxers if you just can’t be bothered. But in the name of all that’s sacred, you need a fresh pair of socks every morning. Don’t dispute this fact.

And there are millions of ways to end up with at least one pair of fresh socks in your drawer, but it’s basically down to either constantly buying new ones, washing them yourself or getting someone else to do it for you, with various degrees of automation.

Suppose, like me, you already tried to buy a 7-pack of socks every week for about two months and realised that was a bad economic decision (and also not a very ecological one), and that you want to dedicate your time at home to learn how to cook that stuff you see on Cooking For Engineers, instead of having to constantly remind yourself to do the laundry. You just don’t want to think too much about it, if at all.

In fact, you want to minimise your involvement in the time it takes to do it, even if the task itself takes a bit longer. The laundrette next door seems like a good idea in this case – your involvement is reduced as now you don’t have to do so many little washes because of the laughable size of the washing machine in your flat.

This would be the equivalent of something like a Web Service. You have to go there, in baskets as big and full as possible as to avoid doing too many trips. You’re subject to environment instability (after all, it’s annoying to walk there in the rain or if the network is playing up) but the economies of scale make it quite cheap. Amazon S3 is a great example.

Then there’s the other laundrette on the high street, which offers pick-up and drop-off. You have even less involvement because now even the question of how your socks get to the service is out of your mind. An equivalent would be a good runtime library – you don’t care how it does it, you just tell it to do stuff, and it works. The environment doesn’t interfere as much, but contrary to the laundrette example, libraries are a lot cheaper to use – in fact, you’ll see in this an inverse relation of cost between the examples.

If you really don’t want to think about the socks, though, you’ll want to hire a maid. A maid will set you back a considerable amount, but your involvement is absolutely zero and your clothes would get washed as soon as they become dirty: a considerably better service. An equivalent would be language runtime features such as a GC, which are almost invisible except when you attend to the fact you’re not doing it yourself.

From there, we can extrapolate:

As software developer-facing services become more elaborate, they require less involvement and cost less to use.

As sock-washing services become more elaborate, they require less involvement and cost more to use.

I imagine we can all quickly understand now why asking your girlfriend to do your laundry is a bad idea, but I’m not sure what’s the software development lesson from all of this.

I’m just writing this quick post to celebrate the fact that, today, for the first time in my life, after sitting at or being near computers for pretty much as long as I can remember being conscious, I have managed to successfully install a printer and use it to print a document without a defect, misaligned margin, glitch, blur, fault, smudge, error, discoloration, warning, beep, loose cable or irritating pop-up.

You wouldn’t believe that, but the feeling is quite underwhelming. It’s like waking up to the fact that you’re just yet another mediocre carbon-based organism spreading filth in a universe that doesn’t need any more of it. It doesn’t make you feel any special, but anyway, thanks Apple Bonjour: at least I’m now a filthy carbon-based organism capable of printing documents without having a nervous breakdown – just like everyone else.

After a fit of Smalltalk envy a while ago, I’ve been playing with the idea of having an instance of my VM being seemingly “always up” and adding more and more code to it in an iterative fashion as I went through developing a system.

On top of that, after looking at the Rails Migrations and other database refactoring tools, it occurred to me that I should be able to do something quite similar to what migrations do to databases in my own code: instead of trying to keep a very regular and smooth codebase, I’d keep track of the changes applied to an “empty” environment, each change providing some value and tests on its own. Also, I should be able to dump some of the VM’s contents back into a script that can be executed on a “clean” VM and the behaviour between both machines should be the same.

My current language of choice, the very small, elegant and simple Io, made it easy to test out the concept. As a prototype-based, extremely dynamic language, you can pretty much reopen anything you want and attach more behaviour to it at any point. So, here are the basic rules I chose to develop an application that looked for collocations in a body of text:

• Every change script should live on a file of its own, sequentially numbered (like 012_add_foo.io), containing all the changes necessary to the system to implement a particular feature (or story).
• Every change script should have a test for the new functionality in a separate file in the test/ directory. Preferably, new functionality should be driven by them.
• The change scripts will be run in sequence by a loader. The loader may also execute unit tests in pair with the change scripts or after all change scripts are loaded, to verify later change scripts did not break any of the existing behaviour. After the loader runs, the system should be ready to use.
• If the latest change script is causing the code to break, fix it, but scripts that have already been superseded by others shouldn’t be changed unless they stop development of new change script (with a syntax error, for instance). This makes more sense when change scripts are created by other tools instead of humans.

So far, it has worked quite well – I ended up with 25 change scripts, one patch to the runtime APIs (which got accepted, yay!), plus a pretty simplistic loader script:

Directory folderNamed(“src”) fileNames sort foreach(name,
	if(name != “main.io” and name endsWithSeq(“.io”),
		“Loading #{name}” interpolate println
		doFile("src/" .. name)
	)
)

Because of my unfamiliarity with Io, I ended up writing pretty brittle unit test suite and broke the “build” a lot (my colleagues would certainly point out here that I break the build a lot, even in other languages, too), and didn’t manage to integrate the test runs in the loader either.

Anyway, the whole point of this exercise was this: it’s possible to do some really cool, dynamic refactorings when developing software like this.

I’m about to write my little Refactoring object, which allows me to do things like:

Refactoring renameObject(Foo, Fubar)
Refactoring renameMethod(Foo, foo, fubar)

The renaming of objects and methods won’t happen instantly across the codebase, as you’d expect from IDEs like IntelliJ or Eclipse – instead, the method or object to be renamed gets replaced with a proxy to the new one and every time the proxy gets hit, the caller method gets its code dumped to a new change script, with the appropriate replacements.
This should give me 100% accurate refactorings with very little disturbance to my development flow (of course, I had to change the way my flow works, but I think that’s a good compromise).

I have just finished migrating all my stuff from a friend’s dedicated server to my own little space at Dreamhost. So far, the service has been flawless, but please let me know if there’s anything wrong. I haven’t quite found a theme I like, and might have to adjust this one a bit.

Meanwhile, I got my tiny little cards from moo.com. The quality of the prints is really, really good. Plus, it’s cheap and novel. As are the USBCell batteries I got in the mail on the same day. They might not have enough power to keep my digital camera up for too long, but having the charger built into the batteries themselves is just so convenient it makes it worth it.

I don’t know exactly where to post this to get the most attention from the JCP, so I just thought I would put it on my blog and ask the readers to kindly link it appropriately so it reaches the right pairs of eyes. Apologies if this post sounds more like a rant; in some respects, it is.

I’ll tell you what I really, really need from a future version of Java. This is where I’m coming from: I’m going to be using a language where I have to spoonfeed the compiler by declaring the types of my variables, parameters, methods, collections (with the addition of generics, even more than that), and sometimes I want to do some whacky dynamic programming with proxies, CGlib or just good old-fashioned wrestling with the bytecode in a pool of mud.

In those cases, I want to be able to isolate the dynamic whackiness as much as possible from the rest of my “sane” code. I want to make my code read as nicely as possible, given the constraints and inherent line-noise of the language I chose (or had to) to use, and last but not least, when I rename something, I want every single last one of the references to be changed automatically for me, and I don’t want to even consider the slight possibility of having to dig around some XML file or JMock test to finish renaming what the IDE couldn’t find.

I want extended static reflection capabilities: when I tell Spring that every URI that starts with /something needs to go to SomethingController.doSomething(String), I don’t want to give it a method name, I want to give it a reference to the actual method. Likewise, when using JMock I want to write something resembling:

mock.expects(once()).method(Foo.class.instanceMethods.bar(String.class));

instead of:

mock.expects(once()).method("bar").with(isA(String.class));

Even though the former takes a bit more typing, that call to doSomething(String) is something IDEs can work out from the AST without any fiddly string search-and-replace operation.

This feature does not change the syntax of the language (doSomething() would be a call to a method inside some instanceMethods field belonging to Class) and does not introduce any incompatibilities I can think of.

So, why not?