Paul Graham has impressed me time and again with his stunning insight. Whenever I read his writings, it’s as if he plucked his ideas out from my own head and then put pen to paper. His latest, Holding a Program in One’s Head, contains several gems that I personally have experienced several times at work.

The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.

This is spot-on, and I notice this a lot during my lunch break. Sometimes I can’t get a program or problem out of my head and occasionally I even come up with a solution not 10 minutes into my lunch break and then I can’t wait to get back and finish it. Other times however, especially if I have lunch with my colleagues the whole ‘problem space’ I’ve built up in my head simply vanishes. Due to the amount of work it usually takes (maybe a half-hour to an hour) to re-load my brain with the problem I was working on, a lot of post-lunch time is wasted and sometimes I can never recreate the problem fully again because I tend to be sharper in the mornings than in the lazy afternoons.

Since there’s a fixed cost each time you start working on a program, it’s more efficient to work in a few long sessions than many short ones.

I have often wanted to do this, but it’s almost impossible to do. There is always lunch, some other interruption, going home, eating dinner or something similar. On the weekends, however, I sometimes manage to stay up late and can work uninterrupted for quite a while.

Rewriting a program often yields a cleaner design.

True sometimes, but I agree with him that even the process of rewriting a program can lead to significant insights; even if the rewritten program is not a huge improvement.

Instead of summarizing the whole essay here, I highly recommend that all programmers and their managers go read it. Even non-IT staff, such mathematicians, whose work involves long-stretches of thinking, and constructing problem spaces in their heads will benefit from the advice in this essay.

I haven’t been paying attention to my RSS feeds recently and I forgot just how good some people are at writing and expressing their insights Paul Graham and Joel On Software are two blogs (journals?) that I really enjoy reading.

Technorati Tags: coding programming software

Fedora 7 is released!: I really liked the last Fedora release, but I believe it was slightly plagued by problems with some of it’s package management utilities. I have already installed this release and am quite impressed. Wireless now works with WPA out of the box and their new re-spinning feature is something I will try out someday.

XML Parser benchmarks: I have always had my own suspicions of which XML parser model would be faster (Sax or StaX), but I’m glad to see this benchmark done by the O’Reilly folks.

Fear and loathing at Cupertino: Jeremy Allison’s terrible experience while trying to prepare a talk for his Apple WWDC presentation. Jeremy works on Samba, along with Tridge, who they all call “the smartest man in Australia” Jeremy works at Google now. Smart man.

I’m going to occasionally post links here that I find particularly insightful, interesting or geeky.

Three things that caught my interest today:

PowerTOP: Released by Intel, this utility builds on work done by kernel developers to make the Linux kernel power-efficient. PowerTOP gives you a snapshot of what apps are consuming the most power. Turn off these apps or modify their behavior, and you’ll notice an instant increase in the battery life.

The Linux SLAB Allocator: Traditional heap memory managers suffer from fragmentation, among other issues. The SLAB Allocator in Linux, inspired by a similar implementation for Solaris and various embedded systems, allocates memory as fixed sized objects and uses caches to reduce fragmentation. It also has options to enable hardware cache alignment which allows objects in different caches to share the same cache lines, thus improving performance.

Advanced Linux Programming: After many years of coding mostly Java, I’ve been meaning to brush up on my C, Assembly and general Unix programming skills. I found this excellent book freely available online and it seems to be getting a lot of praise from reviewers on Amazon so I downloaded it. It has a lot of topics that I’m very interested in, like IPC and threads, and it even has a few assembly oriented chapters. I will definitely be reading this one

LinuxWorld started yesterday here in rainy London and I had a great time! It was the first time ever that I wasn’t a visitor, but was helping out at the Jokosher stand. I did several demos of the app to tons of people and we managed to distribute more than 130 Jokosher flyers to interested people.

I was quite surprised at the level of interest in the app, and we managed to solicit a great many feature requests from people, some of which will hopefully end up in Jokosher someday, making it rock even harder! I will definitely try to help out at more of these events in the future
You can find the photos I took with my camera phone at my flickr photo page.

I turned my computer on today to get some work done, started Eclipse and started coding. When I tried to use the command-line though, I got this strange error:


Error: no known VMs. (check for corrupt jvm.cfg file)


I couldn’t run 'java' or 'javac' from the command-line at all! I immediately went to /System/Library/Frameworks/JavaVM.framework and looked for 'jvm.cfg'. I have 3 VMs installed on this machine, 1.3.1, 1.4.2, and 1.5.0. 1.3.1 and 1.4.2 had a proper jvm.cfg file installed but for some reason 1.5.0’s jvm.cfg was a zero-length file. Googling didn’t turn up anything useful except this tip, which wouldn’t work because in my case all my permissions were correct. Fixing permissions using Disk Utility didn’t show any permissions problems at all.

In the end, all I did was copy the 1.4.2 version over to the 1.5.0 directory and all was well. The tip above mentions that Eclipse might have had something to do with this, and there might be some truth to that, as I did update my Eclipse to 3.2 recently, but I have been using it for a week without any problems …

A lot of the time at work I have to come up with quick solutions to various programming problems, and I mean *real* quick. There is usually very little time for finding the right library or open source toolkit that has already solved the problem or some part of it and then to figure out how to integrate that into our own workflow. It is usually much quicker to simply write a few scripts that get the job done.

In such situations I increasingly find myself solving these problems using the Python programming language. I’ve usually whipped up scripts using bash scripts and even Perl but I often find that I have to “re-learn” Perl again and again, or at least the part that I’m temporarily using to solve some problem. Python just seems (and looks) so much natural and cleaner. I’ve been fascinated by Ruby recently after my brush with Ruby on Rails and I am seriously trying to find a project to use it in all the time!

Anyway I wanted to give some examples of Pythons’ ability to solve quick problems. I’ve used it to make remote backups, check if certain services are running remotely and to fetch and delete mail off a remote server. For example, the following snippet of code can be used to send mail:

import smtplib

mailServer = smtplib.SMTP(serverURL)
mailServer.sendmail(sender, to, message)
mailServer.quit()

Really sweet and simple. I’m sure you can do this in only 1 line or even half a line in Perl (or even Python!) but this is really clear and concise. When I needed to write a script to send mail, I simply googled for it and dug this up in literally 20 secs! That’s one other reason I like writing scripts in Python: you can always google for snippets of code to do stuff.

Similarly, the following can be used to check if SSH is running and accepting connections on a remote server:

IDENT_STRING = "SSH"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, int(PORT)))
data = s.recv(1024)
s.close()

if data.find(IDENT_STRING) == -1:
sys.exit (1)
# if everything OK, exit normally
sys.exit(0)

If you put this in a script and run it, you can use the exit code (echo #?) to determine if SSH was running or not. Very useful if you’re writing a script to make backups to a remote server; you need to make sure that the service is up and running on the server and that it is accepting connections from the local machine.

I will try to see if Ruby makes any of these tasks even easier to do or perhaps easier to write and comprehend. I might even give Groovy a try since Java is my day job and Groovy is described as a scripting language for Java programmers.