Sunday, January 30

Tidbits for developers who use the Vim editor

Vim is an excellent general-purpose text editor, but it is relatively stupid by itself in some situations. Thankfully, it can be scripted. You can find many scripts on, I will mention a few useful ones here.

Every decent code editor has a shortcut to quickly comment / uncomment a block of code. A similar effect can be achieved on Vim by installing FeralToggleCommentify. This plugin works with a great number of different filetypes. I especially like to use it to comment out HTML/XML markup because XML comment tags are tedious to type (the script comments each line of the selection separately though). The binding C-c, although on a nasty key, is quite useful as well - it makes a copy of the current line and comments it out.

If you work with Subversion and write commit messages with Vim, you might find svn-diff handy (you will need Python scripting support in vim). It shows the diff of your commit in a pane below the commit message. Besides, Vim does syntax highlighting, so the patch is easier to read than on the console. Remember that if you see something wrong in the diff, you can always abort the commit by not saving the commit message file or, if you have already saved it, deleting the file (:!rm %).

Python coders will appreciate the smart handling of indentation by the alternative python indent script. It is sometimes too smart and therefore annoying, but works well in most cases.

The XML editing plugin is also nice to have if you deal a lot with HTML / XML. Its functions appear to be quite useful (I keep forgetting the bindings): jumping between opening and closing tags, enclosing content in tags and deleting enclosing tags, etc.

If you work in Vim a lot, I highly recommend to remap Escape. The standard position makes you move your hand away from the home row. I have remapped Escape to Caps Lock which I never use. It takes a few minutes to readjust to the standard Escape position when working in Vim on other computers, but that is a small price to pay for the increased productivity. You can remap the key on X by using xmodmap. Run xmodmap ~/.xmodmaprc after creating the .xmodmaprc file in your home directory that contains these two lines:

clear lock
keycode 66 = Escape

Make sure to have a look at a post by Marius Gedminas about CTags and id-utils if you are not familiar with these two timesavers.

I have uploaded my vimrc, maybe you will find something useful in there. I highly encourage to go through the Vim internal features that are turned on in the script, you will probably want to use most of them. Do not expect the script to work out of the box, you will have to remove the sections that depend on other scripts and plugins.

Time bug in kernel 2.6.10

The kernel 2.6.10 has an uncanny ability to lose track of time when it is sleeping. Whenever I would suspend my computer and then wake it up, I would find the clock hours or even days ahead from reality.

I tried to circumvent the problem with hwclock, but that made things even worse. Evolution would get extremely confused the moment I resumed my laptop and it would suck up all CPU and then some. In the end I would have to switch to a text console, login (wait 20 seconds for the prompt to come up), killall evolution evolution-alarm-notify evolution-data-server-1.0, wait another 5 seconds for the processes to actually get killed and then see the flurry of messages from modules being loaded by my resume script.

To fix the timeshifting problem I had to modify the code as described in this LKML post. The fix is in 2.6.11pre. If you decide to try out 2.6.10, and you use suspend, make sure to apply the patch.

A new Scheme standard in the works

I was surprised to find out that R7RS, a new revision of the Scheme standard, is being prepared. There is a report (PDF) on the progress of the standard.

The most important thing in the new standard is that a module system will be defined. Some interesting things have been considered, such as language case-sensitivity (no decision), non-hygienic macros (no decision), square brackets equivalent to parentheses (passed). Lots of practical suggestions (Unicode support, regular expressions, I/O, hash tables, object-oriented programming, network programming, serialisation, etc.) are also being reviewed.

I was a bit disappointed that a lot of ideas are either still not decided upon or have been postponed for R7RS. It is still nice to know that the language is still evolving and improving

Thursday, January 27

Nasty memory leak in X

Quite recently a friend of mine has found the cause of a leak in X that has been plaguing me for ages. The problem is that the X cursor library does not free animated cursors properly. As a result, my X server would hoard hundreds of megabytes of RAM after a few days of use.

If you are using an animated mouse cursor theme, you might want to check if you are affected (most machines seem not to be for reasons that I have not yet found out). Run top and find the XFree86 process (you might want to sort by memory usage by pressing M). Then have a look at the value in the 'RES' column (it is typical for X to hoard lots of virtual memory, so you should not pay attention to the other values). If it is significantly more than about 40m, chances are that you are experiencing the aforementioned leak. I would suggest working around the issue for now by switching to standard non-animated X cursors.

More information about the bug and a sample application to reproduce the problem is available in the Debian bug tracking system. As far as I can see, the problem has not yet been fixed. By the way, my tests indicate that the problem is pertinent to X.Org too.

Wednesday, January 26


Since I found out about Gnome Blog, had a look, liked what I saw, and then discovered the fact that it could not set post titles on, I have been looking around for other blog applications that can cooperate with I have found several, and finally settled with PyQLogger.

While PyQLogger does not look as neat as Gnome Blog, it is quite functional. It uses a smart interface to - posts can also be retrieved from, edited and republished without touching the web browser. I really liked the idea of saving unfinished drafts. HTML highlighting and easily accessible post preview are quite nice to have. Spellchecking is also supported, although it is not very convenient.

Since PyQLogger is based on PyQt, it does not blend in with my Gnome desktop, but I do not really mind. There are many worse things. The interface is a bit overcrowded. There are some very annoying bugs. The hyperlink dialog is buggy (the "Cancel" button works as "OK", and the "OK" button does not work at all). And it is annoying that Home/End keys jump to the start / end of the paragraph rather than the active line. The OSD library seems to be used out of plain vanity in situations where a statusbar message would do.

Still, PyQLogger does its job. If someone weeded the bugs out and cleaned up the interface, it would be excellent. For now, it is acceptable, but still better than most of the other clients I have tried.

Monday, January 24

Kernel 2.6.10 on a Toshiba laptop

I upgraded the Linux kernel to 2.6.10 about a week ago. I had been using 2.6.8. Here are some impressions.

There were a few pleasant changes. I have already covered CD packet writing earlier. ACPI support has also improved a bit. A minor but very pleasant detail is that my laptop automatically resumes now when I open the lid.

I was surprised to find out that suspend-to-disk kind-of-works now. It used to hang during resume, now it resumes successfully, but maims USB. After resuming the kernel starts spewing messages such as these:

Jan 16 17:26:42 localhost kernel: usb 1-2: khubd timed out on ep0out
Jan 16 17:26:49 localhost kernel: usb 1-2: khubd timed out on ep0in
As my USB mouse stops working after this, suspend-to-disk is still not viable for everyday use to me, but at least it seems to be getting there.

I have also noticed that the clock would at least a few hours off after each resume. I have worked around by saving the system time to the hardware clock right before suspending, and then restoring the time just after resuming. Nonetheless I keep finding premature Evolution alerts after resuming. Really annoying, I hope this will be fixed.

3D support in X still breaks after suspend. It's not really important though, I can restart the X server when I really need 3D working. Besides, it is quite slow anyway.

People who own a Toshiba A15-S157 laptop might find my kernel configuration and suspend script useful.


I have recently come across an interesting project called JScheme, which, as far as I understand, is something similar to Jython, but for the Scheme language. As Scheme syntax differs a lot from Java (Python syntax is very similar in comparison), JScheme adopted special syntax called the Java dot notation to manipulate Java objects, which is quite simple but adequate.

Since JScheme is implemented in Java, you can run it as an applet too. An online demo is available. The interface is cumbersome and ugly, but enough to demonstrate the concept.

Saturday, January 22


It is interesting that people have absolutely no problem filling up latest storage devices despite the rapid advances of data storage technology. This topic has seen some attention from the Slashdot crowd. I do not think that the amount of useful data on a typical computer changes at the same astounding rate. So, where does the space go?

Probably most of the data is multimedia - movies and songs. I wonder how much of those are just played once or twice and then left alone for the rest of time, or until the hard drive dies, whichever comes first. It is none of my business what people do with their multimedia, but I think that it is foolish to hoard things that you will never use.

Movies, in my experience, are a one-off thing. Some do deserve several viewings, but then you do not wait a year before watching them again. I can not think of a good reason not to delete the movie, unless it is one of the few very specials that you actually would want to see after a long period of time passes. Could it be because it "took me a week to download, so it's precious!" Perhaps a friend might want it some time in the future (I can hear the MPAA growling, but I'm not in the USA so I do not care), but then save him/her a few hours and lend a good book instead.

Songs are a slightly different matter. In particular because I have a larger store of them than I would want to (80MB of MIDI from the old times, 5GB of MP3s just locally on my laptop and 350MB of sheet music). I could argue that I do listen to various pieces occasionally. I understand why people are reluctant to delete music. However, I still maintain that collecting for the sake of collection is not a bright thing to do.

Collecting trash is not smart either. Some store all bits of information that they have come in contact with. I say, who cares about the SMS messages, archives of mailing lists, notes, articles that you found "interesting" at the time, artifacts of experiments and primitive one-off scripts. In theory, they could come in useful one day, but in practice they do not by overwhelming proportions.

I suspect that some people put up with the trash just because they are lazy to clean it up. Unorganised files pile up and then in a few years they have trouble finding anything. Well, I think that just like in real life it pays to have a tidy work environment.

The big question is, why am I discussing this? I think that usability and efficiency problems arise out of the sheer amounts of cruft accumulated, and we do not notice. Technical ones too, but that is not important. Database-like file systems are promising, but maybe we could go along with what we have now if we revised our habits a bit. I am not comfortable with the fact that the amount of useless information is increasing so rapidly, and we are battling it by improving searching technology. It would be much better if the signal-to-noise ratio could be improved.

That is a sensible message for developers too: users should be encouraged to throw away what they do not need.

Such an approach of tidying things up does not work on distributed systems, for obvious reasons. That is why we do need good search capabilities and the semantic web. However, in most cases, you are the boss of your computer, so locally you can organize things however you want.

There are practical reasons to keep only useful data around other than searching. Backups are smaller and therefore easier to do, therefore you do them more frequently, therefore your data is safer, QED. Furthermore, there is less risk to accidentally throw away something important while cleaning up junk when you need some extra space. And for me it's a nice feeling that my computer is not a huge pile of virtual trash with the important things buried somewhere inside.

Sunday, January 16

CD packet writing on Linux

The CD packet writing mode on Linux allows you to mount rewritable compact discs as ordinary read/write media. It brought my attention when I was upgrading my Linux kernel to 2.6.10. Apparently, patches to implement packet writing were floating around previously for some time, but now it has made it into the mainline kernel (darn, can't wait until reiser4 is merged).

It is fairly obvious that packet writing support makes using rewritable discs much easier. I have abhorred floppy discs since I got a CD writer. Floppies are so unreliable and their capacity is appalling by modern standards. However, burning CDs involved much overhead - I had to start a burning application, find an unused CD, erase it, create a new compilation, and then finally burn it. That made CDs inconvenient for storing and exchanging small documents of several megabytes.

Probably the biggest disadvantage of packet writing is that you lose about a sixth of the disc capacity - GNOME shows 550MiB free on a fresh 700MB disc. That means that you will have to burn movies the old-fashioned way, otherwise they will not fit.

Packet writing is slower than burning normal images, which is not surprising. I did a small benchmark. Copying a directory of 11 files, about 10 megabytes each, 90MB in total, took about two minutes of real time. My CD burner supports 10x (1500KB/s). I included spin-up time and unmount time. Linux seems to cache writes, so work with the disc is snappy (well, until you fill the buffer), but unmounting takes some time. In theory, the minimum amount of time required would be one minute plus spin-up time. The result is not so bad. If I was burning the data as an image, I would have had to first erase the disc and then wait while lead-in and lead-out were written out in addition to the data itself.

Compatibility with Windows is extremely important. Modern versions support UDF without problems. I just tried to read the CD on Windows XP. It had the title of "LinuxUDF", included the folder "lost+found", and a empty file "Unallocated space", but other files were read properly. Oh, and that darn GNOME created a directory called .Trash-gintas which I had not noticed. Out of curiosity I tried to write to the CD on Windows by drag and drop, and it did not work, therefore Linux CD-RW support is superior.

Here is a guide to get CD packet writing working on Debian GNU/Linux (with udev):

  1. Upgrade the kernel to 2.6.10. If you are compiling it yourself, you will need UDF read/write support and packet writing support (CDROM_PKTCDVD).
  2. modprobe pktcdvd (add pktcdvd to /etc/modules if you want). You obviously do not need it if packet writing support is statically compiled into the kernel.
  3. apt-get install udftools You need not create the device nodes when asked to, they are for the older packet writing interface.
  4. Edit the file /etc/default/udftools. Uncomment the DEVICES declaration, set the value to your CD device, "/dev/cdrom" should work in most cases. You will need to run/etc/init.d/udftools start afterward.
  5. Find an unused rewritable disc, preferably one that supports fast speeds, and insert it.
  6. Run cdrwtool -d /dev/cdrom -q. The CD will be erased and formatted, an UDF file system will be created on the disc.
  7. While the CD is being prepared, which will take a while, mounting can be set up. Create the directory /mnt/cdrw, then edit /etc/fstab, add this line:
    /dev/pktcdvd/0 /mnt/cdrw      udf       rw,user,noauto,noatime 0 0
  8. After the CD has been prepared, mount /mnt/cdrw.
  9. I had some permission problems - /mnt/cdrw was owned by root with no word-write permissions. If you make changes to its permissions, they appear to be saved into the CD. I used chmod 1777 /mnt/cdrw. Maybe there is a better way.
  10. Try copying files to the mounted disc. I especially like the fact that deleting files is trivial. Run umount /mnt/cdrw when you're done playing. If you use GNOME, you should also be able to mount and eject UDF discs by a single click, just like standard CDs. Use the CD-RW icon instead of CD-ROM in the Computer window.

By the way, you can use any file system, not just UDF, but remember to use the noatime option so that the disc is not written to on every read. You do not want to put too much wear on the disc, as they can endure about a thousand rewrites.

Saturday, January 15


Here's an easy one for the Friday night.

A few people have been asking about, I thought that I could briefly cover my experiences here.

Things I like most are the fact that there is no hassle with setting up software on a local server, and that design is a matter of choosing a template. The former has a few drawbacks - I can not have trackbacks as they are not yet supported by, and backups are not trivial. I do not care much about either of these. As for design, I can make things look neat, but not attractive and beautiful. Preset templates saved a whole lot of time, although I did spend almost an hour picking one as they are all quite nice.

My absolute worst complaint about is that it treats paragraphs in a completely braindead way. There are two modes: either no paragraph breaks are inserted (you have to write <p> and <br> tags yourself), or each line break is replaced with an <br> tag. That means that you can not have normal paragraphs in <p> tags. Even if you leave an empty line, two breaks are inserted and that's it. I decided to stick with the manual markup option. The developers of really ought to address this problem, it does not look hard to fix.

I was a bit appalled by customisation of links to other blogs. Let me tell how templates work: you choose one from a list (previews are available) and then you can further fine-tune the HTML source. Well, you have to edit the source to add links, which means that if you decide to change the template, they will be lost. I had hoped for a more generic method - links are just a collection of titles and hyperlinks, how hard can it be to implement a page to deal with them?

Today Marius Gedminas brought my attention to gnome-blog, a small GTK app for posting to blogs, written in Python. It looks a bit unpolished, but seems to be quite functional. And judging from the code it should insert those dreaded <p> tags to form paragraphs. This is my first post through this nice program, I will soon find out if publishing works correctly.

In conclusion, I could recommend as a way to publish blogs without hassle. It may not have the latest features, but there should be more than enough for most people.

gnome-blog report: it did handle the paragraph tags correctly (yay!), but the title I entered was put as the first line of the post, and the real title of the post was left empty. Well, since it's Python, such a minor problem should be easy to fix.

Friday, January 14

Me, I, umm, myself...

While writing English texts, especially this blog, I frequently shuffle with discomfort as can not find a way around using the words "I" and "me" several times in almost each sentence of every paragraph. I guess that using these words a lot is natural, as I am writing a lot about myself, yet it takes some getting used to for me. Using passive voice is an alternative, but it causes more stylistic problems than it solves. I think that some prolific writers structure their sentences to dodge the problem somehow, but I just can not grasp, much less adopt it.

The awkwardness probably comes from my native language. In Lithuanian there is no need to repeat the "I"'s because all verbs have a first-person form, if my phrasing is correct. I can only think of the word "am" in English, as in "I am here", as an analogy, other verbs do not have the difference ("I live" vs. "you live" vs. "they live"). Actually I frequently spot naïve translations from English which indicate the agents explicitly when it is not needed, and this makes the sentences more blunt and unfriendly. I seem to remember a text which discussed fundamental differences between languages where the agent is implied and ones where it is not, so I might have covered just the tip of the iceberg (note to self: cut down on clichés).

One could speculate if using "I" and "me" frequently has a subconscious effect on the writer (or the reader). However, as I am not a psychologist, I will refrain from discussion.

I will again slightly change topic here and use the chance to mention E-Prime. In short, E-Prime is a subset of English which does not include forms of the verb "to be". There are already enough resources to explain it on the web (such as this one), so I need not do that here. I just thought I would mention it as it tries to deal with other aspects of bluntness of the English language.

Thursday, January 13


Most of my friends know my uncanny ability to notice typos everywhere. I am not sure why that is so, as I do not read all that much (that I do intend to change). There is a bit of irony that I am working on SchoolTool (school administration software) at the moment. Darn, I wish I was good at punctuation instead of spelling, which is becoming less useful as automatic spellcheckers get better. Which brings me to the point.

Recently I have come across an interesting essay called "The Philosophy of Punctuation" by Paul Robinson. It is rather wordy, but well worth reading. I have picked a few things that I could apply to my own writings.

Most importantly the essay brought my attention to the fact that I am overusing punctuation. I used to like long, intricate sentences with dashes, parentheses and semicolons. Connecting ideas in various ways seemed interesting and original. However, Robinson claims that overusing punctuation indicates a lack of writing ability. "Expository prose is linear," and therefore ideas should be presented sequentially. Dashes and semicolons "betoken stylistic laziness," they are a sign of weakly connected ideas.

With regard to long sentences, I read somewhere on the web that varying sentence length helps keep the reader interested. I still rarely use short sentences, but I'm getting better. At least my recent writings are stylistically lighter and more lucid than ones I wrote a few years ago. I am still dissatisfied with structure of my writings, that will probably take time to improve.

I found the personified descriptions of the punctuation marks highly entertaining and persuasive. The style also helps the message that it is not a good idea to try to outwit yourself. It is not clever to obfuscate content, and trying to be modern is a bad excuse. Making the text overly complex means that you distance yourself from the reader, which hinders not only readability of the text, but emotional response as well.

Robinson also expressed the old idea that "Good writing is as much a matter of subtraction as creation." This is good to be reminded of, and so obvious that I need not add anything.

For technical people who care about their writing I could suggest to have a look at Lyn Dupre's "BUGS in Writing: A Guide to Debugging Your Prose" ( Although in my opinion sometimes Dupre overshoots while trying to attain lucidity, that may not be necessarily a bad thing as the goal is to help people who are already used to a formal, rigid writing style.

Friday, January 7

Python unit test runners

As I do test-driven Python development almost every day, I care a lot about testing infrastructure.

Currently my development environment of choice is Vim + a terminal (for running PyUnit tests). It's rather low-tech, but it works reasonably well. I usually do not use Vim's QuickFix because it's a bit cumbersome to use (I do use quickfix in combination with idutils). I could outline two main inefficiencies of my current approach.

First, to run the tests I have to save the changed files (which I occasionally forget to do), then M-tab to the terminal window and use Up,Enter to run the previous command, which was most likely to run the tests. The latter step, which is now pretty much a reflex as I do it hundreds of times a day, does unexpected things when I forget that the previous command was something different. I have tried to improve upon things by using a shell snippet while true; do ./test -pv foo bar ; read; done, which requires only Enter to be pressed. I find it hard to drop the habit and still press Up,Enter most of the time. Well, at least unexpected things do not happen. Yet this is clearly a poor man's approach. It also makes changing the arguments to the test runner slightly harder.

Second, I am currently doing the jumping to errors manually. QuickFix could do it automatically, but it sometimes does not work as I would like it to, because sometimes I want to jump to a function higher up in the stack rather the one that raised the exception. Typing the line numbers in by hand is not that much trouble, but tedious.

The page that turned my attention into my testing routine inefficiencies is One Button Testing. It contains some interesting ideas. I especially liked the suggestion to use a smart test runner that automatically runs the tests when you save the code. Now I am thinking that, for starters, it might be quite easy to write a small script that would monitor a directory (either by polling or by utilising dnotify/inotify) and would invoke an ordinary text-mode test runner when a file changed.

I have thought up some features (in addition to the usual ones) that my imagined test runner should have:

  • GUI. Command-line interfaces are really powerful and great for scripting, but they require typing, which is exactly what we want to avoid. (I would not mind if the backend was a text-based test runner.)
  • Global keyboard shortcuts. Some examples: C-M-a to run all tests, C-M-l to only run tests that failed the last time, C-M-s to show and hide the test result window. All without having to switch away from the code editor.
  • Notification area support. It would be great to see without switching windows if a test run is in progress, whether the last run had failures or not, and other things.
  • File monitoring. This is the idea from OneButtonTesting. The critical thing here is to run the tests only for the module that has been updated. Otherwise we either have to run all the tests of a project (slow) or type in a specific subsystem to test (error prone and requires typing).
  • Integration with Vim and Emacs. As discussed, clicking on a traceback to jump to corresponding code in the editor would save some keystrokes. It would be great if it also did not require using the mouse (e.g., use Left/Right to switch between failed tests, Up/Down to walk between stack frames in a traceback, Enter to go to the highlighted code)

There are already quite a few test runners out there, and some of them already implement a few of the items in the above list. First, the text-only ones:

  • The Zope 3 test runner is a quite usable, and has some nifty features.
  • The SchoolTool test runner (download) has been written by Marius Gedminas, my colleague and a very bright Python hacker (if you are a Python programmer, make sure to have a look at his blog). I prefer this test runner over the Zope 3 one, because it is faster (demonstration) and neater.

There are also some GUI test runners out there already. In my opinion they are inferior to the text runners available, at least the ones I have tried. Here is a list:

  • The PyUnit test browser has integration with vim, idle and kate, but that's about it. It is hard to figure out, requires a few dependencies and in general looks unmaintained. Besides, it uses Tkinter, therefore it looks ugly.
  • The PyUnit GUI test runner (screenshot) is rather simple and not very useful. It uses Tkinter too.
  • Pycotine is for Macs, I have not tried it.
  • PyUnitOSX seems to be a port of the PyUnit GUI test runner to the Mac. I have not tried it either. Well, at least it looks nicer than the original.
  • The NUnit GUI test runner (screenshot) is not a Python test runner, but I wanted to mention it because it gets some things right. Notably, it sports file monitoring -- whenever you rebuild your project, the runner notices and resets status of all tests. Besides, it is not ugly. However, other things in my wishlist are missing.

As a sidenote, I would like to mention the std library by Armin Rigo and Holger Krekel, two top-notch Python hackers. However, it's buried in obscurity, I do not think it even has a web page. You can check it out from the CodeSpeak Subversion repository (here). The library makes unit tests more Pythonic by doing dissection of expressions (it provides values of context variables with the traceback). It also encourages use of the plain assert statement, which is so much cleaner than the Java-esque self.assertEquals and others. As assertEquals was primarily used so that the value of variables would be shown on failure, there is no need to use it if you use the std library. There are more cool ideas, go see for yourself.

I would implement the stuff I described myself, but I have quite a few unfinished matters already (I will cover them in other posts) and my conscience would not let me drop them and start a yet another project. Therefore, I am hoping that someone with too much free time and good Python skills will have a look at my wishlist, say "These are neat ideas!" and go on and implement them in a couple evenings. Make sure to let me know if you do. By the way, I have seen a pygtk-based GUI test runner by Marius Gedminas . I suspect that it is rather incomplete, but I would not be surprised if Marius, being so ingenious, came up with something really useful, as he has with the SchoolTool test runner.

Darn, another essay-post. Indeed, my original intent was to provide content, but this is too time-consuming to keep up. I will have to try to be more concise.

Thursday, January 6

Why blog?

Today I would like to discuss the reasons why I thought that blogging would be a good thing to pick up for me. While there are already numerous essays covering the psychology of the blogger (such as this one), I thought that I could present a few of my personal thoughts.

The most straightforward reason why I started this blog is that my attempts of creating a homepage were rather unsuccessful. I would only occasionally find time to reserve for building the page, and when I did, it was not apparent what to do next, what information to put up and how to organise it, not to mention my poor design skills getting in the way. Because the process was so slow, it was not fun and a negative feedback loop ensued. As a result, I have not touched the web page for half a year. Conversely, it is really easy to post to a blog, so I hope that blogging will be fun and will not die off.

A case for blogging is that nowadays there is little point in carefully organising information that you put up on the web. Chances are that the people who need the information will come through a web search engine, therefore, they won't see or care about the structure. Of course, it is a completely different story for large sites which harbour lots of information on a specific field, but I am talking about typical homepages that include information fragmented by nature, for example, "How to set up Linux on a Toshiba laptop", "Some useful Python tricks", "My favourite links", and "Public-domain sheet music of pieces that I like to play". Just post when you feel like it and the info will be scanned by Google in at most a week.

Technical reasons and fun factor aside, there are more serious reasons why I picked up blogging. Browsing the web started to seem too passive for me. I despise television because it makes people passive receivers of whatever is fed to them. The web is better in this regard, because you can (and have to) choose what to read. It is much more interactive. However, I think that to take in the information you need to put it into your own words, or, even better, to explain it to someone. Posting on a blog is communication (even though it is indirect), and you can also get comments, so I expect blogging to be intellectually stimulating.

By the way, Paul Graham has written an interesting text called The Age of the Essay, which discusses the idea of the essay and how it improves mind flow. I think that some ideas from the text may apply to blogging as well.

My memory is not something I am completely satisfied with. That might be the reason why when reading a book or a lengthy text I sometimes feel that reading is pointless. The words just seem to zoom by without a leaving a lasting trace. I sometimes recognise quotes from books (to my surprise). However, I find that I can not consciously recall most of the essence of a book not long after I have finished it. I have discovered that whereas rephrasing helps comprehension, writing down the rephrased thoughts helps memory. It would be reasonable to hope that jolting down my thoughts will help me remember things.

Most of the above does not explain why I would want to make my thoughts available to the public. (I find it funny that apparently only now have I realised why people would write diaries.) Fact is, I am now trying to be more open and transparent to other people. I used to be a rather reserved person, but I have found that it is not the best way. Besides, I do not think that I have much to hide - for example, this essay is completely open and honest, yet I do not think there is anything in here that I would want to keep secret.

I also find the idea of blogging appealing to reveal my personality to people who cannot meet me in person. Just as everyone, I communicate by e-mail with lots of people whom I have never met. The Internet is already an alienating medium in many ways, so it can not be a bad idea to make communication warmer and more personal. I, for one, would really appreciate the chance to find essays similar to this one by people I have to deal with but can't meet.

The last, trivial and a really simple reason to have a blog is to improve English skills. I am not quite satisfied with my English writing abilities. In particular, I would like to improve not just the quality of my writing (which is reasonable, but it still could be much better), but efficiency as well. If I develop a habit of posting regularly, surely there will have to be a noticeable improvement.

I hope you have learnt something about me from this essay. Even better if you found out something about yourself - in my opinion, that is the most important goal of most non-technical writings. Now go write something about yourself if you have not yet done that, there is nothing to lose, only to gain -- to personalise your online identity, and to find out things you might not have noticed.

Whew, now that was a whole essay rather than a post. Well, I had lots of things to say and this particular text would look weird posted a paragraph a day. I guess I made up for the lag - darn, five whole days since the first post, I will have to try and improve...