Power of plain text, the power of being simple

As we see the convergence of technologies through web, I think plain text is going to play a crucial role in delivering a standard cross platform solution for communication. It has already taken the center stage in form of XML. Debate on simplicity (or human side of technology) and performance will, I think, have a positive shift towards the former (people love faster development and simpler use more these days I think.. Rubyist view)

why plain text?

pragmatic programmers answer it with bullets – insurance against obsolescence, leverage (lot of tools available for talking to plain text) and easier testing. and I as always agree.

The concern is there although. Concern is that in addition to being human readable, the text should be human understandable as well. Using names which are semantically correct and contextually relevant is going to act as a substantial catalyst in helping dealing with these plain text files (whether it is a database or configuration file or data-transfer format).

Being always biased towards keeping configuration and databases (good old unix way) I am going to take care of this as a specification in almost all (not everything is driven by me!) development I do. You should also do the same so that your database outlasts your application!

Orthogonality and its importance in software development

I’ve been lately reading The Pragmatic Programmer by Andrew Hunt & David Thomas. Been onto a chapter about decoupling requirement in the development of software, I thought of putting few lines on the weblog. Orthogonality is derived originally from Geometry where it is meant to illustrate two lines which meet at right angles and hence are mutually independent moving in all directions. In software, orthogonality refers to the independence between the modules of the software. e.g. user interface of a software should not have any dependence on Database schema. Decoupling, if not met properly while designing software, can lead to disaster in code maintenance. A decoupled code is better for maintenance because of numerous reasons –

1. Changes are localized and hence development and testing time (and cost) are reduced. Quality also improves since better division of work is possible.

2. Problems are also localized. An issue in one module does not affect other modules and hence fix requires to be done their only (or whole module can be replaced by another implementation altogether).

3. There is more possibility of smaller independent teams (which is ideal for a better coordination)

An interesting introduction into orthogonality is the advent of Aspect Oriented Programming (AOP), a research project at Xerox Parc. As Object oriented programming focusses on the objects and their interaction, Aspect oriented programming focusses on aspects (concerns). AOP lets you express a behavior which would otherwise be distributed throughout the source code. The most obvious example would be logging. Log messages are normally generated by sprinkling explicit calls to some log function throughout the code. With AOP, you implement logging orthogonally to the things being logged. Using the AOP for Java, you could write a log message while entering any method of Class Fred by coding the aspect –

aspect Trace {
advise * Fred.*(..) {
static before {
Log.write(” -> Entering ” + thisJointPoint.methodname);
}
}
}

If you weave this aspect in your code then log messages will be generated and if you don’t, they won’t. Either way, your original source is unchanged.

Towards the end of the discussion is a challenge: Consider large GUI-oriented tools typically available on Windows and small but combinable command line tools used on shell prompts. Which do you think are more orthogonal in design?

What do you think?

Building Strings in Ruby

If efficiency is important to you, don’t build a new string when you can append items onto an existing string. Constructs like str << ‘a’ + ‘b’ orĀ  str << “#{var1} #{var2}” create new strings that are immediately subsumed into the larger string. This is exactly the thing to avoid. Use str << var1 << ” ” << var2; instead.