Programmatic Thinking

Am looking at Monit & God, curbing the urge to do my own monitoring system for our rails app. A quick scan of user reviews is pushing me towards Monit. I am not very inclined to experiment with God and see if it indeed leaks memory and whether it does indeed need some monitoring itself.

Step-0. ssh to my ec2 instance

Step-1: sudo apt-get install monit

Step-2: configure /etc/monit/monitrc

Step-3: sudo monit

Done!

P.S: Yes, I can add more details about configuration options and alerts but there is enough info out there on the web. Google can be your friend too

A quick note:

Source code posted to this blog with <code> element, was losing its indentation.
Using <pre> helped retaining it, but at the expense of losing the green over grey, block styling given by <code>.

Combining the two as suggested by sohtanaka helped. This is a problem being reported by many fellow programmer-bloggers out there but the solution is quite elementary!

F.P.Brooks, in his visionary paper “No Silver Bullet“, makes a very significant point:

My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded. Not only salary, but the perquisites of recognition–office size, furnishings, personal technical equipment, travel funds, staff support–must be fully equivalent.

Now, how many technology firms understand the need for such parity between the managers and the designers? I see more and more technologists trying to get an MBA degree, just so that they can climb an extra rung on the corporate ladder. Disparities between managers and designers leads to long term social ills, so to say. Today’s society respects managers more, as their influence/fame/pay is relatively higher. (The WallSt con-artist executive gets all the girls, while the fellow who designs the next-gen caching algorithm ends up being labeled a geek/nerd!). This in turn corrupts smart youngsters to take the management studies route, instead of pursuing their latent technical interests. Such corruption dwarfs the problem of brain drain from pure sciences to applied sciences.

That said, established large corporations would be too timid to implement Brooks’ radical proposal. But we, as technology entrepreneurs, should take the lead and implement it in our startups. Our org-charts must start reflecting the reality of great designers and great managers being equal in all aspects.

All I learnt about the beauty of program design, I owe it to these two simple and yet great treatises on programming – K&R and K&P.

Prologue:
Programming is an act of creating beauty. A master programmer weaves an exquisite tapestry of form and function into a program. Whitespace is the background. Indentation is the visual design.

Reality:
I’ve seen too many examples of painful code and invariably it is visually unbearable too. And it is also true that I haven’t yet seen a person who writes visually beautiful code which is functionally/logically poor. This post goes out to those who share my pain.

Take a look this beauty by Linus Torvalds: Linux Kernel 2.6.31: fork.c

Most of its visual beauty can be attributed to simple rules such as:

1. A space, after the comma (but not before it, even when used as a binary operator).
2. No space before ‘;’. A space after ‘;’ except at EOL.
3. A space before and after most binary operators (exceptions such as -> and arithmetic operators is specific cases)
4. ‘*’ when used for indirection sticks to the variable (“int *p;” is good; “int * p;” isn’t. Neither is “int* p;”!)
5. A tab between the type and the variable(s) in a declaration
6. Underscores for creating white space between words in long variables (this_is_holy_kernel_code; NoCrowdedCamelCasePlease)
7. Multiline comments have the ‘*’s aligned.

Violations stick out sorely and spoil the look. In the same file (fork.c), compare the inconsistency between lines 212 (good) and 422 (poor):
212: static struct task_struct *dup_task_struct(struct task_struct *orig)
422: static struct mm_struct * mm_init(struct mm_struct * mm, struct task_struct *p)


A passing thought:
One of the irrelevant topics taught at school can be replaced with a short course on appreciating the beauty of programming. On the lines of fine arts courses where people get together and just look at examples of masterpieces.

Saying hello with rake is easy. Especially for us who like the good old make.
$ cat lib/tasks/hello.rake
namespace :hello do
desc "Say hello to the world, K&R style"
task :say do
puts "hello, world!"
end
end
$ rake -s hello:say
hello, world!
$

Quite the magic. Isn’t it?

int     main(void)
{
        printf("hello, world!\n");
        return 0;
}