Testing messy bash scripts

Read this book too!

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.Australia

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!

Testing messy bash scripts

Read this book too!

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 Britain. 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

Writing helpers with Haml and rSpec

Recently Wolfman posted a description about Rails helpers written with Haml::Helpers#open and rSpec.

inflatable water slides for sale

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

So basically – what I did was :

Continue reading

Using FireBug’s console logger with GreaseMonkey 0.6.4

FireBug is the best tool (a Firefox extension) for web development ever invented … well, at least one of the best.

The console method  (formerly known as printfire) is a feature of FireBug that enables logging into firebug’s console with different levels. Thing is – it does not quite work with GreaseMonkey scripts. Until now!

The solution is very simple – using GM’s unsafeWindow object. This object is the same as the ‘window’ object that local javascript is seing, and it includes firebug console methods.

Like so:

unsafeWindow.console.info('some informational message');

Ruby + proper specifications = rSpec

I had an enlightenment today – truly an enlightenment.

After months of reading and getting to know what test driven development and extreme programming is all about, I have finally been able to practice what I preach. Since I work with several programmers and the product we are writing is so new that it is still in diapers (famous hebrew saying). Quality control is a demand from above management, after they got burned with too many escalations with the existing product. So part of my job description was preaching unit testing and such.支架水池

Anyways – I really did understand and could quote all the reasons why testing is important, and why its a sort of a documentation, and why it should be done before coding, and why it makes coding more structured and disciplined and gives the programmer a direction. But I could not make myself understand how to implement it with ruby’s Test::Unit for example, not even talking about more obscure implementations of xUnit like CppUnit which is something that was chosen for our project.

Last week I saw the presentation Dave Astels made at google, freely downloadable from google video. An I saw that it was god (with one ‘o’). And today I finally got to trash all the beginnings that I tried to do with Test::Unit on the ClearCase wrapper I’m writing – and started doing rSpec instead.

It flowed… like a river. And any bumps that were on the were not frustrating, they were annoying, thus actually motivating me to kick them of my route and continue flowing with the flow without any frustration. It rocks. I love it.

Still the one thing I miss with all this TDD and BDD are good concrete examples that are a bit more than what rSpec examples are, I need it chewed and digested for extreme easy understanding. Maybe a step-by-step evolving kind of code, maybe even a book matching the Progmatic books quality is the thing missing in all of this. Because it always looks really great – but when a motivated but inexperienced programmer like me tries to implement this stuff it soon becomes frustrating. Even though rSpec is not too frustrating, and hopefully it will only grow to be easier and more intuitive and productive like it is already in its alpha(?) state.

Enough ramblings for now – back to the code! :)

The Ultimate Development GUI

For the last several days I have been trying to find the perfect tool for development of the many projects I have. My basic requirement was a good editor (TextMate would be a dream, but I don’t own a Mac yet), and a good integration with the filesystem – either remote, or in version control.

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.