> irb
irb(main):001:0> a = [1,2,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]

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.

I am reading the book “Refactoring” by Martin Fowler, 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, 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).

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. It takes less time to output names and parameters to a file than to execute the actual commands. So while running the actual script might take 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’ve mentioned earlier, I guess that the most used refactoring to improve readability would be Inline Method. Whoever wrote the original scripts was very fond of wrappers for commands like “ln”. Even though commands like “ln” don’t really need a wrapper. 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. 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!

PS: Google docs rocks! (even publish-to-blog kinda works)

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

Thankfully, Sun realizes that not everyone is looking for a 3,456 port InfiniBand switch. So, it has prepped a 72-port InfiniBand switch that will sit on top of the Sun Blade 6048 rack.

I just can’t stop being amazed.

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.

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

A quick peek into ruby/bin/gem revealed much of what I needed to know.

Lets demonstrate :

Welcome to the JRuby IRB Console 

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> Gem.manage_gems
=> true
irb(main):003:0> gem = Gem::GemRunner.new
=> #
irb(main):004:0> gem.run(['help','commands'])
GEM commands are:

    build            Build a gem from a gemspec
    cert             Adjust RubyGems certificate settings
    check            Check installed gems
    ...
=> nil
irb(main):005:0>

update: The bug that prevented me from installing gems, turned out to be a _gemrc file that had http_proxy configured. A proxy no longer in use, but since I didn’t use gems all that much on this workstation before – I forgot all about it.

This is what I came up with:

#!/bin/env ruby

exit if ARGV[0].nil?
exit unless File.exists?(ARGV[0])

CACHE_DIR_NAME='cache'

haml_file = ARGV[0]
haml_time = File.stat(haml_file).mtime

html_file = CACHE_DIR_NAME + '/' + haml_file.sub(/aml$/,'tml')
if File.exists?(html_file)
  html_time = File.stat(html_file).mtime

  if html_time > haml_time
    output = File.read(html_file)
  end
end

if output.nil?
  require 'rubygems'
  require 'haml'
  template = File.read(haml_file)
  haml_engine = Haml::Engine.new(template)
  output = haml_engine.to_html()

  # cache the output
  Dir.mkdir(CACHE_DIR_NAME) unless File.directory?(CACHE_DIR_NAME)
  html_file_io = File.open(html_file,"w")
  html_file_io.print(output)
  File.utime(Time.now, haml_time, html_file)
end

# unbuffer output
$stdout.sync = true

require 'cgi'
ENV['SERVER_SOFTWARE'] ||= 'not set'
cgi = CGI.new('html3')
print cgi.header(
        'type'     => 'text/html',
        'charset'  => 'UTF-8',
        'length'   => output.length,
        'server'   => ENV['SERVER_SOFTWARE'],
        'expires'  => Time.now + 10*3600*24, # 10 days
        'Pragma'   => 'no-cache',
        'Last-Modified' => haml_time,
        'Cache-Control' => 'no-cache'
)
print output

And as Mike suggested, adding a couple lines to your Apache configuration makes all the difference:

  AddType text/haml .haml
  AddHandler haml-file .haml
  Action haml-file /dev/bin/haml_cache_cgi.rb
  Action text/haml /dev/bin/haml_cache_cgi.rb