No classes and objects in Lua. So...

So let's use old-C structs :D
How?
Image a struct to define a 2d point. It will looks like

struct Point2DStruct{
    double x;
    double y;
};

typedef struct Point2DStruct Point2D;

Point2D* new_Point2D(double x, double y){
    Point2D* result;
    result=(Point2D*)malloc(sizeof(Point2D));
    result->x=x;
    result->y=y;
    return result;
}

How we can do something similiar in Lua? With a table!

function new_Point2D(newx,newy)
    result={x=newx,y=newy};
    return result;
end

Easy, fast, and good looking. Well, you can also implement objects and classes using metatables. But I prefer using this "structured" way, because it's easier to read a to write.

No Memory on iPhone?

A rumor about new iPhone nano: they could be sold without memory, downloading dinamically from network. A storage location already exists: it's MobileMe.
It could be an interesting idea: but how much will cost in Italy, where our 3G network is expensive as gold?

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.