Monthly Archives: May 2006

SQLite

In the ATV telemetry there are some parameters with text values. In good implementation they should really be integer numbers representing text indexes like 0 – “OFF”, 1 – “ON”, but it looks like we shall have English texts themselves instead. So we have to translate it to Russian somehow. One way to do it is to create hash table of possible texts for each parameter and then look up texts in it. A very good way, but in order to do that, an application receiving this telemetry must somehow compose this hash table.

The problem is that full catalogue of texts is rather big – about 40 MB in text file. My application needs a few minutes to process it, which is simply unacceptable. Some optimisation could reduce this time, but I think not that it will be sufficient. So some cache is necessary.

First I thought that text cache file with only needed texts (there are not many of them) would be enough. But then I realised that if we build this cache based on current list of parameters to be received, we shall have to rebuild it each time this list is changed. I thought not that it is a problem until we knew that we shall probably have to change them in real time! It is ridiculous idea (as well as the idea to send texts in telemetry), but the probability that we shall have to do it is rather high.

So, we do not know anymore which texts are needed and which are not. And the whole catalogue is too big to be processed each time. What to do? First thing that comes to mind is databases. We could put this catalogue into indexed database (It is exported database table in the first place! Although we have not access to it.) and look up texts using SQL requests, which should be fast enough.

But to set up an entire database server for simple network application is a bit of an overkill. So I remembered thing called SQLite – simple and fast local database – and decided to try it. And now what I wanted to say in the first place: it is good! I simply open file as database and then go and insert data using standard SQL queries. Lookup is very fast. No need to configure or administer – so it is really light, exactly what one need when talking about things such as cache. So I recommend it to everybody who need light, fast and reliable local database.

To debug or to delete?

Joel Spolsky is a very good programmer that writeth very good articles.

Eric Steven Raymond is another very good programmer that wrote magnificent book The Art of Unix Programming, which thou probably got tired to hear from me about.

On top of that, Joel refereth in one of his articles to this book and recommendeth it.

So far, nothing is wrong. But Joel writeth that one should never throw away any written code while Eric sayeth: “Don’t hesitate to throw away the clumsy parts and rebuild them”. That is exactly opposite. But why? What should one really do when they think their code is a mess? Throw it away and rewrite or bear with it and debug it?

The answer is that in properly designed software it is actually the same thing. Eric writeth, “The most powerful optimization tool in existence may be the delete key”. I can say the same thing about debugging. The most effective way to debug something is probably to delete the whole thing containing bugs. But hey, stop! If we could simply delete it why have we developed it in the first place? Is not it better to just throw away the entire PC then? ^_^ No, what I am talking about is a little bit different. In fact, if thou noticed not, I have not told thee what this “whole thing” is. The trick is that in properly designed software there is a set of independent modules. Each module should be small enough to easily debug it or throw it away and rewrite from scratch if it is too much of a mess. So, this module is our “whole thing” or “clumsy part” which Eric refereth to.

What Joel says is that thou shalt not throw away the whole project. But if thy project is small enough to be thrown away without great harm, just do it. Consider it debugging ^_^. Thou just have to learn how to know when this debugging technique is most effective and when it is not. Only experience will teach thee that.

Графические среды в Unix

Сначала я это писал в форуме нашей сети, но потом понял, что получилось больше, чем просто сообщение для форума.

Я ни в коем разе не утверждаю, что наличие графической среды в какой-либо степени является недостатком системы. Напротив, я верю в то, что она необходима.

Проблема тут как раз в намерении показать “альтернативу” (1). Разработчики KDE дошли до той кондиции, что с каждой версией пытаются показать альтернативу сами себе, тщательно переделывая всё, что можно. Разработчики ASPLinux пытаются выпендриться в свою очередь перед ними, переделывая KDE под свой фирменный стиль, неизбежно добавляя туда новые баги. Это не имеет никакого отношения к заботе о пользователе, но требует вложения сил.

Я как-то уже излагал свои мысли на этот счёт, правда по-английски. Вкратце: нужна графическая среда для пользователя, но выполнена она должна быть в духе Unix. Ссылку на книгу Эрика Рэймонда, внятно изглагающего что есть дух Unix, я уже приводил. Среда должна быть максимально отделена от системы технически, для пользователя это выражаться должно в том, что при желании он всегда может посмотреть сквозь неё и увидеть те процессы, что происходят в ней. Среда должна быть максимально модульной, то есть состоять из небольших компонентов, а не монолитный монстр вроде KDE. В общем, принцип “K. I. S. S.” (keep it simple, stupid) должен работать на всю катушку.

Кроме того, минимум переделок непонятно ради чего, как в KDE. Стабильность и привычность прежде всего. Привычность означает похожесть на то, к чему пользователь привык. Как минимум это винда, хотя наличие разных режимов приветствуется. Всякие же попытки сделать “не как у них”, ничем не подкреплённые – это преступление против юзабилити, а значит неуважение и высокомерие по отношению к пользователю. Пример: GNOME Human Interface Guidelines – о чём они думали, переделывая привычное “Yes”, “No”, “Cancel” в “No”, “Cancel”, “Yes”?!

Пока разработчики графических сред будут городить огород из непонятно чего, вкладывая невероятное количество сил в разработку какой-то ерунды, о которой пользователь даже и не узнает, забывая свою цель помочь пользователю освоиться с незнакомой системой, пользователи будут шарахаться от незнакомых графических сред куда подальше, проклиная их за кривость, глюкавость и тормознутость, утверждая, что винда – самая надёжная, быстрая и удобная операционная система. Они, разумеется, не правы насчёт операционной системы, но поверхностное сравнение (а другое пользователь проделать и не в состоянии) оконных сред показывает именно такой результат.

Пример бестолковых действий разработчиков: KOffice. Пользователь, сев за новую ОС, чуть ли не сразу пойдёт искать Word. Найдёт KWord и попробует открыть в нём свой “Служебная записка.doc”. Полюбовавшись на результат, наверняка почувствует желание забыть о Unix навсегда. Что должны были сделать разработчики KDE: убрать свой дурацкий офис как только появился OpenOffice.org и вместо этого обеспечить нормальную интеграцию с ним от рождения. Тогда это бы оставило гораздо более приятное впечатление.

Другой пример: ранее упоминаемый DVD-плеер из 100 строк (2), который почти наверняка – дрянь редкостная. Если бы они вместо этого интегрировались с MPlayer, например, а дистрибутив Linux от рождения включал бы в себя его и кодеки к нему, пользователь бы имел возможность насладиться возможностью воспроизведения почти всех вообразимых форматов видео, что наверняка произведёт на него неизгладимое впечатление после первого опыта общения с Media Player с его набором кодеков по умолчанию, что не в состоянии даже DivX открыть, кажется.

Конечно, альтернативные решения имеют право на существования. Это тоже часть истинного пути Unix. Но они должны чем-то превосходить своих собратьев. KOffice ничем не лучше OpenOffice.org. Будь он хотя бы побыстрее и попроще в употреблении – но нет, это такой же навороченный тормоз, как и вся KDE.

Но почему-то никто об этом не думает, и пытается тщательно изобретать велосипеды, да ещё оригинальничать при этом. Вот и остаётся: либо следовать истинному пути Unix, либо сидеть в винде и не высовываться. Ну или высовываться раз в несколько лет, чтобы разведать обстановку.

Единственный способ применения всех этих велосипедов, это в качестве временного средства транспорта, чтобы доехать до приличных средств передвижения, а затем бросить их. Я сам начинал с KDE. Но будь я нормальным пользователем, я бы забил на Unix ещё в самом начале, в силу кривости и глюкавости – ведь это только потом я узнал, что кривы и глюкавы – дистрибутивы и среды, а не система или софт.

О, разработчики графических сред! Мало модульности, мало прозрачности, мало интеграции! Читайте Рэймонда, учите албанский!


(1) Цитата из форума: “Да дело не в “умных” или “неумных” системах, а в намериниях разработчиков показать альтернативу средне статистическому юзеру привыкшему к Винде”.
(2) Цитата из форума: “Enlightemnet (enlightenment.org) же – делала контора целиком, начиная с библиотек обработки графики (imlib) и заканчивая аж двд-проигрывателем на всего лишь 100 строках кода используя библиотеки той же разработки”.

C vs C++ vs…

They say that C is not suited well for high-level development. They say that C++ is not portable. They say that both of them have much trouble managing memory. They say that for higher-level development higher-level tools are needed.

I shall tell thee what. They are right. It is true that manual memory management in C and C++ giveth (1) a lot of trouble. It is true that higher-level tools and languages are needed. For example, it would be ridiculous to use C++ for pure text filtering, because it is a job for Perl.

But dare not thou ever say (2) that memory management troubles and other low-level stuff is something inherent to C and C++ and the only cure is to run away from it to higher-level stuff. Because, thou know, there are such things as “libraries”. And they can handle it all for thee, really!

For C++, use QString in Qt and forget about memory management for strings and about encodings as well. Use shared classes and forget about troubles with expensive copying or duplicate pointers in shallow copies. For C, I believe GLib provideth the same set of features.

And for portability, just use the most basic things (e. g. use namespaces not!) and thou shalt find that C is the most portable language and C++ is probably the second one. Thou only needest to use portable libraries as well, like Qt and GnuWin32 stuff. In fact, thou canst easily reduce codebase size by ten times using these tools.

For those who think Java is the most portable language: know you not that Java is implemented partially in C++? Not even C! So how the hell can it be more portable?! We are not talking about exotic platforms like cellphones, okay?


(1) Now where can I learn more of this nice archaic English grammar? That is the question. These are nice, but are definitely not sufficient:
http://dan.tobias.name/frivolity/archaic-grammar.html
http://members.shaw.ca/hai-etlik/archaic_english.html
Or is reading Shakespeare and playing Thief the only way?
(2) Is it even half-correct? ^_^

GNOME Human Interface Guidelines

Misunderstand me not. I really love GNU. I really admire Richard Stallman and his followers. In a way, I am one of them as well. But I sometimes just can not understand what these guys are thinking about.

For example, I read in GNU coding standards “Please don’t use “win” as an abbreviation for Microsoft Windows”. Is it really that important that Windows should be written in full or abbreviated to one letter, but not to three? What about four? Will they say that I am being rude to Mother Nature abbreviating “Windows” to “Wind”? Or what if I really like the funny way “Windo” (accent on last “o”, please) sounds? Weird guys. But that is okay, that is just their religious preoccupations. It is harmless anyway.

Now here is another thing. GNOME Human Interface Guidelines say that in “confirmation alerts” (for example, when application asks whether it should save document before closing) buttons should be ordered like “Close without Saving”, “Cancel”, “Save”. Okay, calling them like this instead of usual “Yes”, “No”, “Cancel” seems like a good idea because it decreases the chance user will mistake one confirmation with another (for example, they may think that they are being asked whether application should really close). So that is perfectly fine.

But what the hell is about this weird ordering?! I had a discomforting feeling all the time that something is wrong here, and when I stopped and thought “Why do I dislike these GTK+ confirmation dialogs so much?”, I finally realised: it is not “Yes, No, Cancel”, it is “No, Cancel, Yes”! So, no single button is on its rightful place. I am not saying that “Yes, No, Cancel” should be like that simply because it is like that in Windows. But it is something most people used to. It is something natural, after all! I have seen many “Y/N” questions even in DOS, but I have never seen “N/Y” question. People say “Please answer with yes or no”, but they never say “no or yes”. The root of that discomforting feeling was that each time I knew I should save, I was tempted to press first button which is “Close without Saving”, but then I saw that it is not usual “Yes” and was stuck.

I thought that some developers do not really think about ordering when making such dialogs and so they mess it up. But now I see this thing in something like standard guidelines I just can not understand why they are making more enter barriers then there are already. After all, all the point of GNOME and similar environments is to give the right feeling to people who are used to GUI environments, not to give them something even more weirder than CLI which is just a different thing, but at least without any unnatural attachments.

I am really happy that I use very few of these GUI things, otherwise I would probably be constantly mad about stupid design and inconvenient interfaces. But I just can not rid of the feeling that all these GNOME things is just another “let us make something really different, no matter how and what”.

IDEs in Unix

It is often said that there is almost no good IDEs in Unix. I finally realised that this is wrong. There is one very good IDE called Emacs. It does not look like IDE simply because it uses very powerful mechanism of commands and keyboard shortcuts instead of fancy menus, buttons and stupid dialogs usually found in other IDEs. But other than that, Emacs is full-featured IDE which supports a lot of languages and at least compiling, debugging, navigation and completion. Compared to Borland IDEs, Emacs is a way better. Compared with things like Eclipse and IntelliJ IDEA it lacks only GUI builder and refactoring tools. Former is not a problem because there is a lot of very good GUI builders that can be used independently of editor (like Qt Designer), the latter is a little bit disappointing, though. Maybe I did not search well enough or maybe refactoring is not really needed with true Unix development style (this makes sense, since I did not miss refactoring even once).

Nonetheless, Emacs is really an IDE. If it seems strange to you, imagine that your favorite IDE has all its menus, toolbars and panels removed, their functions bound to key sequences (less often used ones to text commands), and you will quickly understand why Emacs looks like an editor.

So, to continue “Emacs and Vim” discussion, it becomes very simple: Vim is the best editor, Emacs is the best IDE.