AK's weblog

In this posting (and also this one), Su-Shee pleads for a more vocal and active promotion/advocacy. While I know how nice it can be to use a piece of software that makes people envious, I just want a quiet, hype-free, pragmatic, down-to-earth knowledgable community, and I will explain why.

Some years ago, summer or fall 2002, if I recall correctly, there was this new object-oriented programming language that everybody was talking about, that was quite obscure but really cool because you could write compact, easy-to-read, object-oriented code, in a fashion not unlike Perl. That programming language was Ruby. Having had a background of Pascal, C, and some C++ and Perl, I was astonished by the expressiveness and flexibility of the language, without losing readability. I used Ruby for quite some time, worked on some silly open source project with it, I used it for scripting at work (until my then-boss prohibited the use of any programming language for which no other developer in-house had any knowledge), I wrote daemons that formed the glue between email and MMS systems, I even used it as exploratory prototyping language for stuff that I would later rewrite in C. And then came Rails.

Rails was hyped as the greatest invention since sliced bread, the be-all end-all of web development. As somebody who had previously only known CGI.pm and cgi.rb, this indeed looked intriguing. I had a closer look, bought a book, played with it, and found it quite OK. Until I wanted to do things differently than what the usual tutorials had in mind. Useful documentation about the greater context and overall concepts was sparse (be aware, this was pre-1.0 Rails, things may have changed a lot since then), and I felt constricted by too many things in Rails (this has most likely been addressed in later releases; I haven't bothered to look back since then, though). So many things that were advertised as awesome turned out to be nice, but not that impressive on closer inspection.

And this is exactly what I don't want to do, namely awakening false hope in people about awesome features of $SOFTWARE, and I think an overly optimistic presentation of a system's features can easily lead to exactly that. In fact, the only screencast that didn't disappoint on closer look was Google's launch of the Go programming language in 2009, but that only as a side note. Self assurance is nice at all, but in my experience, there's only a fine line between self assurance and misrepresentation.

Another aspect of the Rails hype was the complete turn-over of a great portion of the Ruby community. The usual community and support channels were flooded with people interested in Rails, Rails became synonymous with Ruby, the signal-noise ratio drastically became worse. Some people even tried to actively recruit me for open-source Rails projects because I "knew Ruby". I declined, because the web applications aren't my area of interest at all (even today, the only things I have to do with web is that I hack on stuff like Apache and PHP [the interpreter] for a living; still, no web development).

Yeah, the community turn-over. Soon, people with big egos and great self assurance surfaced, dubbing themselves rockstars or ninjas or similar. I always found these to be acts of total douchebaggery, because, in the end, they all only cooked with water, anyway (a notable exception was why the lucky stiff). These were the people with great self assurance and a total lack of self-criticism or reflection on one's own work. It's not the kind of people whose software I would want to use, because too often my experience was that some library, framework or tool was announced with big words, which then practically always turned out not to be great at all, sometimes even barely usable or totally buggy.

And that brings me back to the original topic of Perl. Exactly the things that I learned to despise about the culture revolving around Ruby and Rails are something that I haven't experienced in the Perl community at all so far. Libraries, framework, documentation and people had more time to mature, probably, while still being down-to-earth. I can expect good documentation, functioning software, friendly people and most importantly accurate words in announcements and discussions.

Through my current employment, I found the way back to Perl, using it at work and also for some personal stuff. I recently even started a new open source project where I productively use Moose for the first time. My code is probably not very expressive and may seem weird (I know, TIMTOWTDI), but at least I feel comfortable writing it. I'm fine with most things surrounding Perl, its eco-system and its communities, and so I don't want to see any kind of interruption and turn-over like I saw it with Ruby.

Nachdem ich in "Was nehmen für statische Seiten?" meine Requirements dargelegt habe, ich allerdings bis jetzt nichts passendes gefunden habe, habe ich mich kurzerhand hingesetzt und selbst ein Tool namens wsg ("website generator") gehackt und in mein Subversion-Repository getan. Das README beschreibt kurz, wie man wsg benutzt, ansonsten ist IMHO alles selbsterklärend (solange man schon mal mit eRuby gearbeitet hat). Und sobald ich meine eigene Internetseite damit neu gemacht habe, wird auch ein etwas umfangreicheres Beispiel vorhanden sein. Wie immer ist Feedback sehr willkommen.

Ich bin mit meiner derzeitigen Lösung, wie ich die HTML-Seiten von http://synflood.at/ generiere, nämlich WML (Website Meta Language), nicht wirklich zufrieden. Einfach, weil WML an vielen Stellen eine eher krude Syntax im Einsatz hat (kein Wunder bei den 9 Filtern, durch die jedes WML-Dokument geht, bis am Ende HTML rauskommt), es ist langsam (siehe voriges Argument), es wird zum Scripting Perl eingesetzt (welcome to the 1990s), und last but not least: es wird nicht mehr maintained.

Richard hatte mir empfohlen, m4 einzusetzen, nur davor scheue ich mich etwas, auch wegen der kruden m4-Syntax. Kann mir in der Richtung irgendwer was empfehlen? Was ich brauche ist im wesentlichen ein schnelles Template-System, es muss skriptbar sein in einer angenehmen Sprache, und es sollte Ausgabeformatagnostisch sein (i.e. es spießt nicht, wenn ich WML [Wireless Markup Language] oder Textdateien generieren will). Über Hinweise würde ich mich freuen. Falls es keine Hinweise gibt, dann werde ich mir wohl selber was bauen (müssen), möglicherweise auf eRuby-Basis.

This week, I put quite a lot of effort into pushing Liam further in terms of features. It is now a quite nice mail client, already. What you can currently do is send mails, reply to mails, forward mails (even as attachments, just like Thunderbird does it) and attach files to mails with a nice file browser. You can view mails, viewed mails will be marked as seen. You can mark already seen mails as unread. You can mark mails as deleted, and then expunge them from the mailbox. Mails marked as deleted can also be undeleted as long as haven't been expunged. When you reply to a message, it will be marked as "answered" on the server. This is also shown in the mailbox view. You can flag messages. You can define a "header filter" which describes which headers shall be shown in the mail view. If you don't define such a filter, all headers will be shown. And even documentation for everything is available, in DocBook format. This feature list might not look really long, but remember, this is all the achievement of less than a week!

If you want to try out Liam, just check it out from the SVN repo. Liam depends on several external packages, such as Ruby 1.8, STFL and RubyMail. STFL is noteworthy because currently you need this patch to fix a bug in STFL and to add a new widget and probably this and this patch if you have troubles building it. And don't forget to install swig before building STFL as it is required to build the Ruby bindings.

If you managed to get Liam running after all that, look at liamrc.example and create your own ~/.liamrc after it. As usual, feedback is welcome. If you're eager to help with Liam development, don't hesitate to look at the TODO list, hack away and send patches. So far, I would like to thank Michael Prokop for his huge amount of valuable input and for trying out Liam in this early stage.

After the generally positive feedback that I got for the first few steps with my prototypical IMAP client, I put further effort into it, and implemented cool features like replying, group-replying (aka "Reply All") and sending mails. Currently, the only transport protocol implemented is SMTP, but I made everything as generalized as feasible, so replacing SMTP with e.g. the local "sendmail" command wouldn't be much of an effort. In addition, I added (hear! hear!) support for showing threads. This means that threads of email discussions, be it a long conversation between you and a friend or a discussion on a mailing list, is shown in its structure. Again, I compiled a feature show of new features since the last posting as screencast.

Today I spent a few hours of hacking on an IMAP mail client in Ruby which I codenamed "liam" (backwards for mail, haha, how funny). I based it on basically two libraries, namely Ruby's Net::IMAP, which provides a very complete (but a bit complicated) interface to IMAP, and Clifford's STFL, the Structured Terminal Forms Library, which is pretty new, but definitely the best ncurses widget library around.

The functionality is currently really simple: you start the program, it connects to your IMAP server, reads all available mailboxes from it, and lets the user decide which one to open. After selecting the right mailbox from the list, it is opened and the message envelopes from this mailbox are downloaded. Then, the user can again select the message he wants to view. Then, the message is downloaded and the raw message is presented to the user using the less(1) pager. The user can view this message. When he quits less, he is again presented with the list of messages in the mailbox. To return to the list of mailboxes, a simple press of the 'q' key is enough. From there, it is possible to select another mailbox, or to quit liam by again pressing 'q'.

This probably sounds pretty difficult, but it's extremely simple. To visualize this more efficiently, I prepared a simple screencast, which you can view here.

But what is my goal with this prototype? I don't know yet. It is definitely not here to replace mutt-ng (which is not dead yet, I'm currently preparing a "relaunch" since I now know my requirements much better than at the beginning of the project), but it's more a prototype to experiment on the future of terminal-based email clients. Sooner or later, mutt (and mutt-ng) will require a rewrite, and with this prototype I can find out what will be important for a new design, and where the stumbling blocks might be. Anyway, any feedback is welcome.

Update: more hacking on liam (including a new STFL widget), and a new screencast to demonstrate email viewing.

A few weeks ago, Sven reminded me of an inherent problem of the current design of tpp's file format, namely it's line-based file format which gives no options to e.g. set text properties like bold or underlined for only a single word or a phrase. Currently, the whole line must be made bold, underlined or whatever.

For those who don't know: tpp is the "PowerPoint for the console" that I wrote together with Nico Golde and currently the (IMHO) only mature solution to do presentations solely using text terminals.

A quick look over the existing commands in the current file format shows three (no, four, nobody
expects the Spanish Inquisition!) classes of commands:

• presentation-wide commands: presentation title, author, date, header, footer, border
• slide-wide commands: header, footer (to override to presentation-wide default, if set)
• line-wide commands: output, shell output, special effects, alignment
• character-wide commands: text color, text properties like bold, underlined, reverse, ...

Now, the goal is to reflect this new specialization and change in what tpp should provide into a new, better file format, to make tpp more flexible than right now.

One option would be to use an XML schema, but that is not a very attractive option, since XML would be a lot too verbose to actually make it fun to write tpp presentations.

Another approach would be to keep with most of the current problems, and to introduce additional, Wiki-like formatting methods, like using stars or underlines or something like [bold|The text supposed to be bold] or [bold,fgcolor=blue,bgcolor=white|blue/white text, bold]. The only disadvantage: it would make the parser a lot more difficult than it currently is. But probably it is
too simple, anyway.

So, what's your opinion on that? I would like to hear your comments, and to do some brainstorming instead of just starting some experimental quick-shot implementation.

Currently, I'm searching for the right scripting language for which I would like to write my servlet container. The original idea was to use my beloved Ruby scripting language, as it contains all the features I need and like. For using it in my servlet container, I also need the possibility to embed more than just one VM instance, to keep the applications strictly separated. And as far as I was able to research, this isn't possible with Ruby.

And now I'm searching for some other object-oriented, embeddable scripting language that bears no arbitrary limit on the number of VM instances within a single process. AFAICS, Python isn't an option, either (nor are all the other hardly known scripting languages that I found), so I'm open for hints or recommendations. I'm willing to use any language that bears the above-mentioned attributes (as I was unable to find a language that matches all requirements).