I think I really dislike Python

Read this book too!
Read this book too!

Ruby:

> irb
irb(main):001:0> a = [1, buy
 2, discount
 3]
=> [1, 2, 3]
irb(main):002:0> a[10] = 20
=> 20
irb(main):003:0> a
=> [1, 2, 3, nil, nil, nil, nil, nil, nil, nil, 20]

Perl:

> perl
@a = (1,2,3);
$a[10] = 20;
use Data::Dumper;
print Dumper(@a);
$VAR1 = 1;
$VAR2 = 2;
$VAR3 = 3;
$VAR4 = undef;
$VAR5 = undef;
$VAR6 = undef;
$VAR7 = undef;
$VAR8 = undef;
$VAR9 = undef;
$VAR10 = undef;
$VAR11 = 20;

Python:

> python
>>> a = [1,2,3]
>>> a[10] = 20
Traceback (most recent call last):
File "", line 1, in ?
IndexError: list assignment index out of range
>>> a
[1, 2, 3]

A bright idea in the middle of the day

I was reading a blog yesterday about “The sad state of open source monitoring tools” and was thinking about it for some time. Coincidently today I had a chance to look at my CruiseControl configuration files, internist which I wrote quite a long time ago.

I really love the DSL that CruiseControl is using for it’s configuration, it’s extremely powerful at describing how to build projects. Especially powerful are the variables, that unlike in Ant are not immutable, and the way plugins can be pre-configured with your own defaults, as well as renamed to other names. It’s really easy to configure it in such a way that adding a new version for a project is just 1-3 lines of XML, for example

<xxx-project name="XXX v6.66">
<property name="version" value="6.66"/>
</xxx-project>

Just in those 3 lines, the pre-configuration already includes all the information about the project. Where it is at, who to send e-mail to, where is the version control, EVERYTHING! If the only variable that changes over time is the version number, then that is all you need to leave as a variable … everything else is just a template that can be re-used. And these templates are extremely easy to combine from smaller templates, it’s a template-in-the-template kind of configuration.

IMHO this would very much apply to configuration of monitoring software, like nagios for example. And the way the (CC) plugins are written in java – adding new plugins that check all kinds of esoteric things is really easy to do.

If it would also have the XML/XSLT configuration of how the web-interface looks like (the way CruiseControl does), and the super-easy installation (again like in CruiseControl). It would be a really really really great product, extremely powerful, easy to configure, and potentially great looking.

If only ThoughtWorks would write such a thing … I would be thrilled!

Actually nagios is already extremely similar to what I described, but for some strange reason I find the rigid configuration of nagios a large PITA. Maybe some-day when time stops and I will have unlimited time to code, I will do it myself.

Testing messy bash scripts

Read this book too!

I am reading the book “Refactoring” by Martin Fowler, site and just reek with ideas about improving software, as well as solving problems I head-banged during my “software” development career.

On my last job, there was this huge messy heap of bash scripts that were “The Installation” of their main software product. It was a remarkable amount of bad smelling bash code, and it somehow managed to work. My work, at the time, was from-scratch-rewrites of this or that functionality and then somehow plugging it into the existing framework (damn, i call it a framework now).

It could have been just amazing if I could take the existing pile of dirt dung bash scripts – and refactor it into something that is readable, sort of.

Today, while I was riding the bus, reading “Refactoring” pg.110, it struck me. It’s actually can be extremely easy to test bash scripts! All it takes is a collection of all the familiar commands, like “cat”, “rm”, etc … and one sneaky PATH environment variable. These commands would be fakes, stubs – they all just print their name and parameters into a log file. In fact, there is just one actual script and the rest are links to that single one.

That log file can be compared before and after a refactoring. These commands writing their names to a file take less time than their actual execution. So while running the actual script might have been hours, with the stubs it should run in less time, much less. Finally by comparing your pre and post refactoring log files, you get a really nice test-suite that can help you refactor. I might even call it replacing unreadable code with readable one without breaking much of anything.

In the particular case of the scripts that I mentioned earlier, I guess that the most used refactoring to improve readability would be Inline Method. Since whoever wrote the original scripts was too fond of wrappers, when most commands like “ln” don’t really need a wrapper to do the same as the command does perfectly well. The wrapper with at least two echo commands and a very long name is quite redundant and adds unnecessary complexity.

There are several problems with this simplistic approach though. One of the problems might be that the script is using full path in names (like /bin/ln), instead of relying on the PATH environment variable. But such things can be relatively easily taken care of until the testing solution is perfect. (I guess). One of the things to try, for example, is running bash in restricted mode, if I remember what that is correctly.

I’ll try that on some new messy scripts that I got on my new job!
YEY!

Read this book too!

I am reading the book “Refactoring” by Martin Fowler, store
and just reek with ideas about improving software, erectile
as well as solving problems I head-banged during my “software” development career.

On my last job, there was this huge messy heap of bash scripts that were “The Installation” of their main software product. It was a remarkable amount of bad smelling bash code, however it somehow managed to work. My work, at the time, was from-scratch-rewrites of this or that functionality and then somehow plugging it into the existing framework (damn, i call it a framework now).

Continue reading

GMail is broken

What happened to GMail lately?
It steals focus!
Contacts don’t work most of the time!
Mail is often not sent because the button pushing has no effect.

Is this GMail 2.0?
Fuck 2.0, cheap I want the working GMail back!
And stop it from stealing focus to it’s own tab, that is SO annoying.

Invite the world to GMail

The other day I noticed that I have this “Invite a friend” on my GMail. I didn’t use that thing for more than a year, disease so I took the chance of this re-discovery to get rid of it. Within several minutes I sent 98 invitations to an imaginary friend whose mail bounced at some noreply@somewhere… address. And it worked – I got rid of that little blue box that serves no purpose on my GMail page!

Imagine my surprise when today I find that box at the same place, with 50 new invitations to give away.

No, really – I don’t have any friends who don’t have a GMail account. I don’t want to use this “feature”, ever. And it does not contribute a thing to my GMail experience – get rid of it Google! Put some AdSense there or something.

JRuby in a JAR

A bit of fairy dust, allergist a sprinkle of elven blood, this lots of water and boil it all for 5 hours on a low fire. What you get? … I wouldn’t know, but I do know that it took me almost 2 whole days to grasp the idea of a JRuby in a JAR, with two bootstrappers!

Let’s assume that I wrote this great utility that does this magnificent function that will help mankind. And this utility/software needs a computer to run. Now, I speak Ruby quite well – and specify my behavior thoroughly with RSpec. But alas – most computers don’t have ruby installed (Java JRE yes, Ruby no, especially in enterprises).

So let’s also assume that some giants wrote a Ruby interpreter that can run on a JVM, and called it JRuby. And further more assume that most java “utilities” can be written inside a single jar, and can be executed with:

java -jar fairy_dust.jar

How can I take my ruby code and have it run just like the above? With just a single file and all …

Answer:
1. JRuby
2. One-jar
3. Custom Bootstrapper

And the result is – a JAR file, with multiple Ruby files inside – that works just like a java jar:

java -jar rubified.jar

And you can get all the above (with the ant build.xml) for the price of one download!

Presenting: Rubified 0.1 BETA