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)

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.

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

I want it to be more DRY than it is, since the whole application is using rSpec and Haml, all helpers should have the same before(:each)

So basically – what I did was :

[source:ruby]
Spec::Runner.configure do |config|
config.with_options :behaviour_type => :helpers do |config|
config.include Haml::Helpers
config.include ActionView::Helpers
config.prepend_before :all do
@haml_is_haml = true
@haml_stack = [Haml::Buffer.new]
end
end
end
[/source]

Except it will not work, for various reasons.

Hope to solve all the quirks sometime soon. I know this will cost me some sleep.

After some tweaks and manipulations – I have came to use Scintilla + Explorer + TortoiseSVN + WebDAV (windows integrated). Overall this is almost perfect, except one small thing, organizing the different windows on the screen — and those huge window titles I hate so much. It would be really perfect if the titles were minimal (text height, no more), and the layout would be saved.

This is when it hit me — why not create a program that will do the layout only?

A really small application – preferably multiplatform, which will run windows inside it with layout separation for resizing, and with tabs for each window — for more than one program maybe. So basically you’ll have what all development studios have — eclipse for example, but instead of a file explorer you would run Windows Explorer, and instead of a version control plugin you would have TortoiseSVN, and instead of WebDAV integration you would also have the explorer. And instead of the text editor window you will have scintilla, or notepad, or whatever . . . and these layouts will be saveable and configurable to include multiple colums or rows, and tabs for each window.

GTK or QT would probably be the best ways to do this and stay multiplatform at the same time.

Ideas are coming at a rate much higher than project completition….

Update: There are several utilities which do something like this, Acer’s GridVista is one of them for example. Good, but not good enough.