Once upon a time, there was KDE

KDE: your UNIX easy

My first Desktop Environment on GNU/Linux was KDE 2, at university laboratory. At that time I didn't have a computer powerfull enough to double-boot Windows 95 and a distro, but I read a lot, fascinated by FOSS philosphy.
I was KDE fanboy: I am still convinced that big projects as a desktop environments must be programmed with an object-oriented language. KDE uses C++, while Gnome works in C. This difference was visible in first years of 2000: KDE was fast, fascinating and colorful, while Gnome and its applications were gray and old-looking.
When KDE3 was released I run it on my new Pentium IV 1200 with 512MB, looking admired that environments, far advanced from Windows XP. Many friends of mine were surprised by KDE3, its themes and its applications (Kopete, Konquerror, Kircand KOffice), making it very near to Mac OS X.
On 2002, the Liquid theme (made by Mosfet), was a wonder.

KDE 4 Revolution

Since Matthias Ettrich foundation, KDE was a well engeneered project. Ettrich did many analysis to optimize user experience, expecially about memory use.
KDE 4 was a "revolutionary" project: its developers wanted to change the usual "desktop paradigm", introducing a engine which runs many "plugin" (called "plasmoids"). You can still have a "desktop" with your folders: it's a "plasmoid" which will show you your $HOME/Desktop folder big as your monitor.
KDE4's underlaying platform is a programming masterpiece: there are base libraries well organized (Phonon, Solid, KIO, Plasma, KParts and others) and well integrated all togheter, but... take a look to these two screenshots

KDE 4	Enlightenment 17

Well... there's something not very clear to me: Enlightenment 17 is a "yet not finished" project, but you can test it. It's written in C and it's very fast and light. So light to move some producers of embedded devices to run E17 on their products.
KDE4 is big, heavy and does E17 same things.
Looking to Gnome, I see a lighter DE, fast and nice looking. Its technology is not refined as in KDE, but Gnome does its job very well. It's usable and I can be productive with it. One year ago I tryed both KDE4 and Gnome: after some "Wow! Amazing!" I used Gnome because I can "do things", while KDE4 seemed to me a "useless videogame".

The Future

Gnome is the most widespread DE thanks to its usability. Its Human Interface Guidelines were the secret of its success. KDE, instead, worked too much on its underlying technology, making it «the Java of Desktop Environments»: well designed, well documented, well thinked, not very usable.
KDE has to rethink its structure, moving the user-experience as center of its universe, continuing to host great applications and (maybe) trying to take a diet.

The answer to a Non-Rigid-Organization

Japanese philosophy is so near to computer-science

Do you remember? Some days ago I suggested some ways to do data-entry, but I didn't explain well when a wiki is a good solution. I want to illustrate better this concept and introduce you some cases where a wiki is a comfortable solution.

Wabi-Sabi

What's Wabi-Sabi? In wikipedia we read

Wabi-sabi (侘寂?) represents a comprehensive Japanese world view or aesthetic centered on the acceptance of transience. The aesthetic is sometimes described as one of beauty that is "imperfect, impermanent and incomplete".[1] It is a concept derived from the Buddhist assertion of the Three marks of existence (三法印 sanbōin?), specifically impermanence (無常 mujō?).
Characteristics of the wabi-sabi aesthetic include asymmetry, asperity, simplicity, modesty, intimacy and the suggestion of natural processes.

Do this sounds familiar to you? Concepts like "transience", "impermanence", "incompleteness" can appear very often in a bad organized office and are programmer's hell. Let's think to write a relational database. It's well designed and has good interfaces for CRUD. Now, let's imagine our boss asks us to change the relational schema. Adding or removing a column could be not very difficult, but changing big pieces of this schema means to rewrite our application controller from 40% to 70% and write some scripts to move datas from the old schema to the new. Pretty boring and frustrating. And, more important, probably non definitive, because in a bad organized office, changes could happen very often.

Wiki is Wabi-Sabi

A wiki is "fluid". It have a very simple schema (to our eyes), mostly based on "Articles" and "Categories". It checks if a certain page exists (blue links) or not (red links); it lists all uncategorized pages; it lists all unused categories, ecc. It will also include the "Search" which shows us all pages wich contain the searched word.
I choose a wiki for a particular job: I had a web application and I have to list all entities showed to the user. I started with an excel spreadsheet, listing where the entity was located (in wich web page), if it was read or write, who can modify it and other fields. This organization changes some days ago, forcing me to change the schema. But this time I moved all data to a wiki (mediawiki), making a page (article) for every entity.
Result: it's appreciated and a change will be managed easily, 'cause there's no SQL schemas to modify, just pages.
If you're losing your life on a Access database and your boss wants every day a "small change" which makes you mad, then moving to a wiki is probably the best solution.

The Apache which leaved the reunion

Apache is flown away

Me and Mix (a friend of mine) have a very different opinion about Java: he totally dislikes it, but I think it's good on servers.
Two days ago, Apache leaved Java Community Process, because it disagree Oracle's decision to don't release for free tools to check a Java implementation compatibility. This is an ugly decision, because it will make very difficult (or impossibile?) to check if (e.g.) Apache Harmony is a Java compliant implementation.
Oracle is handling Java as a colony, ignoring what the Java Comunity did in these years. Oracle is pressing to morph Java into a "personal language".

When Mix sent me this news, I throws my hand in the sky saying «well, we will program in python or PHP» and I was serious. I used Java in few projects in these years and no-one end successfully. In the low-medium market, where I work and where work at least 70% of programmers, Java is never used because:

1. it's more difficult to write a JSP than a PHP page
2. it's more difficult to use Hibernate than Ruby on Rails
3. Swing is slower than QT or than WXpython or than TKinter
4. it's harder to use an XML as configuration file than using a python/ruby/php/lua dictionary/hash

Many big competitors use Java for their work and they have many powerfull tools, such as JUnit, Log4J, Ant, Geronimo, Batik, Cayenne, Cocoon and many more, developed by Apache Foundation.

I am tired to talk about Java: Oracle, Apache, IBM and Google are playing with it in a very boring way. C/C++ didn't have all Java troubles because the language and the standard library were free to be developed by everybody. Java was once strictly managed by Sun and now by Oracle. This decision cut off necessary freedom from Java to transform it as "language of choice". People still use C/C++ because they're faster; use Ruby or Python because they're easier; and because people aren't interested to portability.

Maybe Java, as we know it, is going to dead. Maybe we'll see two branches, the one "official" made for servers (supported by Oracle, IBM and RedHat) and the "mobile" one, supported by Apache and Google for Android platform.
Future's unknown. Until the next "big" revolution, let's script.

Never do Data-Entry

«I am sorry if I didn't write these days. Unluckly, I was very busy with a lot of work so I didn't pay much attention to other tutorials. Excuse me. I'll try to write something about next week»

It happened to me yesterday...

Data Entry is bad by design.
It's true, it's important, because without datas, a database is useless. But there are good and bad ways to insert datas. Good ways are:

1. User-Based: users insert informations on specific designed application
2. Data-Transfer: datas are moved from a data source (text file, excel, network, ecc.) to a destination database with a script
3. User-Evolved: it's similiar to the user-based. It's more Zen, because in this model we admit «perfection is impossible, imperfection is normal, evolution is required». Premising we can't insert all datas, we'll delegate users to modify and to refine them. It's how Wikipedia works

Bad ways are (usually) more widespread, because data-entry is made to solve an informations hole without considering how the database will evolve, who will use it and how.

1. One-Man-One-App: this is the "less worst" solution. A programmer is charged to implement a program to manage a database and to fill this database by himself. Though is still a bad solution, it's a bit more human because the programmer can write a program more suitable for HIS needs. More important, a single error doesn't compromise whole work
2. Data-Source-Based: absolutely THE worst solution. Two or more users work to fill a common data-source (an excel file, a text file, ecc.)

One-Man-One-App problems are:

1. A new "data-inserter" must be trained to learn how the hight-customized application works
2. Move datas to another database more well designed could be difficult
3. The official data-inserter doesn't always pay necessary attention on data-entry, because he's a programmer. Repetitive jobs make programmers angry and frustrated

Data-Source-Based is bad because

1. Data-entry manifests in its worst way: "filling" an excel spreadsheet is one of most boring and frustrating activities on earth. Even a 100x6 table is hard to fill with care
2. "Save button" is "Cumulate-and-Fire" anti-pattern incarnation. If someone forgets to Save, hours of works could be trashed
3. Finding errors could be hard if you have more than 7 columns
4. A clumsy operation (e.g. a "sort and save" just on a selection) could make datas inconsistent and ruin irremediably all the work done

If you're ALONE to fill a large database with datas wich came from paper or other non-scriptable sources, try to move yourself to a good way of data-entry. If it's impossibile, NEVER USE data-source-based: create a front-end even if you're working with an excel. This will allow you to have to avoid the "cumulate-and-fire" anti-pattern, will allow you to make a more comfortable way to insert datas and will give you a little fun when coding your script.

Anyway, data-entry is bad and boring. The only good way to do it is spreading it among three or four employed on a long timeline. 10 minutes per-day of data-entry is sopportable: two or more hours per-day doesn't.