Conventional wisdom holds that the solution to the problem is documenting the code appropriately. Conventional wisdom is wrong. Reasons are manifold, and quite obvious once you start to think about it.

Documentation is always out-of-date. It’s impossible to have anyone and everyone who updates code to update the comments and documentation accurately. Sure, you could try, but to a large extent, this is simply beyond your control. Typically, this means you need to assume the documentation is wrong and read the code in detail anyway, so you might as well simply start by reading the code.

Reading the code is the only way to figure out what it is doing. Documentation only tells you what somebody thinks the code is doing. It is quite possible that they’re wrong, or only partially correct. Besides, it’s better to build up a model of what you think the code is supposed to do, than to be told what to expect.

Code is more concise. If the code is well-written and self-documented, it is generally faster to read the code and understand what’s going on than to read the comments (which are, by definition, more verbose than the code they attempt to explain). And if you can’t trust the programmer to write good code, you can’t trust the guy to write good documentation either.

There are some situations where documentation is necessary, of course. Examples would be when you are attempting to explain the motivations or structure of your design at a larger scale, or if you want to explain what the code is not — why you decided to something one way and not the other.

Nov 20 10:24:01 [sshd] Invalid user backup from 203.239.105.2
Nov 20 10:24:03 [sshd] Invalid user info from 203.239.105.2
Nov 20 10:24:04 [sshd] Invalid user shop from 203.239.105.2
Nov 20 10:24:06 [sshd] Invalid user sales from 203.239.105.2
Nov 20 10:24:07 [sshd] Invalid user web from 203.239.105.2
Nov 20 10:24:09 [sshd] Invalid user www from 203.239.105.2
Nov 20 10:24:11 [sshd] Invalid user wwwrun from 203.239.105.2
Nov 20 10:24:12 [sshd] Invalid user adam from 203.239.105.2
Nov 20 10:24:14 [sshd] Invalid user stephen from 203.239.105.2
Nov 20 10:24:15 [sshd] Invalid user richard from 203.239.105.2
Nov 20 10:24:17 [sshd] Invalid user george from 203.239.105.2
Nov 20 10:24:19 [sshd] Invalid user michael from 203.239.105.2
Nov 20 10:24:20 [sshd] Invalid user john from 203.239.105.2
Nov 20 10:24:22 [sshd] Invalid user david from 203.239.105.2
Nov 20 10:24:23 [sshd] Invalid user paul from 203.239.105.2
Nov 20 10:24:27 [sshd] Invalid user angel from 203.239.105.2
Nov 20 10:24:30 [sshd] Invalid user pgsql from 203.239.105.2

1. Make sure you install all the popular TrueType fonts (Microsoft’s common fonts are generally available via your distribution’s repositories).
2. Remember to enable anti-aliasing of fonts. Anti-aliasing can be turned on through the desktop-environment’s configuration, for example, KDE’s Control Center.
3. Set the hinting to ‘medium’ while enabling anti-aliasing of fonts.
4. Change the user-interface fonts to something that looks good, like Verdana, DejaVu or Calibri. Firefox also comes with an ugly set of default fonts, so you may also want to change those defaults too.

The solution is a simple one: run a development website in parallel, so that all changes can be tested on that first. Updating the primary website would be like flipping a switch. Here’s how I managed this:

1. Set up a new virtual host for the development site.
2. Set up a new database for the development site and populate it with existing records.
3. Update the WordPress configuration file to select a different database based on the current working directory.
4. Set up server authentication for the development website.
5. Write an init script to copy (rsync) all the files from the development site to the primary one. Exclude the authentication files like htpasswd, of course.
6. Set up a dependency on the new script in Apache, so that restarting the service also restarts Apache (this is useful at times).

It’s as simple as that!

The ‘quad’ roller skates are simply shoes with four wheels underneath. You wear the shoes and, instead of walking, you skate (or fall).

They say practice makes perfect, which is certainly true to some extent. However, like any other sport, there is a technique to doing it right that is far more important. Here’s a breakdown of what I discovered this week:

Bend your knees

This is true for almost any sport. Bending your knees automatically forces you into a crouching position, moving your weight ahead of your feet. This ensures that you don’t fall backward, which is painful and dangerous. The instinctive reaction to falling forward is to put one foot ahead and stop the fall, which is exactly what you need to do to start skating.

Gather momentum

The simplest and probably the only way to gather momentum is to put one foot ahead and put your weight on that single foot. You have your knees bent, right? The trick here is to apply pressure on the foot not directly straight ahead but towards the side. That is, you push your right foot forward and towards the right, and then your left foot forward and towards the left alternately. This provides some control over your motion.

Moving your feet

Don’t straighten up

…unless you know what you are doing. If you are moving slowly, it is alright to straighten up temporarily, but you need to bend your knees again before stepping again.

Don’t put you weight on both feet

Consider your normal walk: your front foot presses against the ground, while your back foot provides support. It’s the same principle at work here. Naturally, you can’t put pressure on both feet, otherwise your feet will drift wider and wider apart until you do the splits.

A possible misunderstanding by the novice is to imagine that the wheels would magically carry him ahead. In reality, the best analogy to roller skating is walking, except that the ground is rolling away behind you. Ergo, you need to lift up one foot at a time and place it ahead.

P.S. — How often do you get to use the word “ergo” in your posts?

For instance, setting the value of a variable X is an idempotent operation, because setting its value to be Y several times has the same effect as setting it just once. On the other hand, incrementing its value is not an idempotent method because the result depends on the number of times the operation is called.

Implementation

Before delving into why you might want to have idempotence, let’s have a look at how it can be implemented. One way of doing it is like this:

Design a state machine

A state machine identifies every unique state that the system can exist in, with a clear indication of which states the system can transition to from any given state, and under what conditions.

Design a minimal API

An application programming interface is the gateway for external systems to interact with the service. We start by designing a minimal API, identifying all the methods that could change the state of the system. It is best not to clutter the API with non-critical methods at this stage.

Expressed differently, an API method represents a single transition in the state diagram. For example, a system could have states such as ReadyToPurchase and TaxAdded. The addTax() method, if successful, provides the transition from the first state to the second. This method can never be applied a second time, because by then the system has already moved on to the next state.

An important restriction on the API is that if the state has some attributes, they must be maintained meticulously and checked against incoming requests. Suppose the addTax() method takes a parameter called amount. If the method is called again with the same amount, then the expected response is success, since the system is indeed in a state that the function call was supposed to move it to. However, if amount is different, then the response should be a failure, or at least some kind of partial failure — otherwise, the client will assume that the new tax amount had been added. A state should never change its internal attributes once they have been set.

Transitions should be atomic

It goes without saying that transitions need to be atomic, so that multiple requests do not corrupt the state while the system is transitioning. This can be achieved easily by acquiring a lock on a mutex at the start of a transition, and releasing it on completion.

Why Idempotence?

Naturally, it is a good idea to ask why we are putting in so much effort. While this may seem inordinately complex at first, you will soon discover that such a design actually simplifies the system tremendously when there is a great deal of concurrency. When there are a large number of processes or threads communicating with each other and the number of messages exchanged is huge, idempotence provides a guarantee of sorts about what the system can or cannot do. The state machine approach allows you to simply worry about the system in its current state, rather than the system as a whole. As a debugging technique, the developer simply needs to say, “This was the previous state A, and now it has moved into this new state B — what combination of parameters caused such a transition?” Idempotence makes this approach even more robust, ensuring that the system works in the face of message duplication and errors.

This robustness also allows the design to sacrifice a reliable communication layer in exchange for speed. For example, TCP (which has a larger overhead) can be replaced with UDP, since the application is resilient to message loss and duplication.

So here goes:

1. Create a new image slightly larger than the desired image size with a transparent background.
2. Make a rectangular selection the size of the actual logo, convert it to a round-edged rectangle and fill the selection with the highlight color (for example, the red on the edge of the logo).
3. Duplicate the layer twice.
4. Fill the lowermost layer with black, and blur it in order to create a shadow effect. It needs to spill out from behind the main logo slightly. Scale up the layer a few pixels if requried.
5. Scale down the top most layer by around 10–15 pixels, and apply a slightly darker shade gradient to it. (for example, a darker shade of red). The gradient should be subtle and slightly asymmetrical. Blur this layer just a little, so that it merges with the middle layer which is just below it.
6. Create a new text or image layer to add your logo to the image foreground.
7. Save your file.

That’s it — you’re done!