Tuesday 21 December 2010

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.

Monday 20 December 2010

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.

Tuesday 14 December 2010

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.

Friday 10 December 2010

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.

Friday 3 December 2010

iPhone Tutorials - Start with Objective-C


If you want to program on Macintosh or iPhone, first you have to learn Objective-C. Objective-C is very different from C++ or Java, because it follows the "other" way for Object Oriented Programming, the Message Passing.
With message passing, you can easly implement some designs patters, such as the delegate, but you'll see it when I'll talk about UITableViews. First, you'll see how Message Passing is more expressive and readable than C/C++/Java Methods.
Now, let's image to implement a simple (and classic) ComplexNumber class. First, on a file called ComplexNumber.h we'll write the class interface.

//ComplexNumber.h
@interface ComplexNumber: NSObject{
    double real;
    double imaginary;
}

//---constructor
-(id)init;

@property(nonatomic)  double real;
@property(nonatomic)  double imaginary;

//---Add
-(void)Add:(ComplexNumber*)other;

@end

Quiet easy, right? Class' members are defined between braces and methods (or messages) follows immediatly. Class Interface is closed between @interface and @end keywords. id type is a pointer to an unspecified object, something like a "pointer to anything". It's usefull expecially in delegate design pattern.

@properties are "syntactic sugar". They help you to implement easily getters and setters for members. With this trick we'll can write

complex.real=3.0f;

Parameters inside the @property specify how the variable is passed (e.g. by reference or by copy). Because real and imaginary are base-datas, we haven't to specify the way.

A method is defined according with this protocoll

-(type_returned) MethodName:(parameter_type)parameter_name;

So, a method called "HelloWorld" wich returns nothing (void) and wich accepts a NSString* (OpenStep strings) will look like

-(void)HelloWorld:(NSString*)string;

Now, let's create another file called ComplexNumber.m and let's implement all methods

#import "ComplexNumber.h"

@implementation ComplexNumber

//--- implementing properties
@synthesize real;
@synthesize imaginary;

/**
* Constructor
* a constructor always calls first constructor from 
* mother class and returns the object itself. Between
* [super init] and [return self] we set values for
* all object members
-(id)init{
    self=[super init];
    real=0.0f;
    imaginary=0.0f;
    return self;
}


/**
 * Add
 * add param other to this ComplexNumber
 */
-(void)Add:(ComplexNumber*)other{
   real+=other.real;
   imaginary+=other.imaginary;
}
@end

Now, our class is over. Let's trying it on a main.m.

int main(int argc, char** argv){
    ComplexNumber* one=[[ComplexNumber alloc] init];
    ComplexNumber* two=[[ComplexNumber alloc] init];

    one.real=3.2f;
    one.imaginary=1.8f;

    two.real=4.0f;
    two.imaginary=2.2f;

    [one Add:two];

    // NSLog is the OpenStep equivalent
    // of printf. You can declare a NSString* without using
    // a constructor, using the synthax:
    // NSString* s=@"Hello world";
    NSLog(@"Now one is %.1f+i%.1f",
                                one.real,
                                one.imaginary);

    [one release];
    [two release];

    return 0;
}

This is our first Objective-C program: a simple ComplexNumber class. It has many problems, such as it lacks a parametrized constructor (something like c=new Complex(real,imaginary) in C++ or Java) a toString method and a method to set real and imaginary in one shot. I shall show you how improve this class in next tutorial.

Wednesday 1 December 2010

Tutorials and Protests

Just some random thoughts
About Tutorials
Some months ago, I was surprised for the «Tech-Blog-Silence». Many blogs about GNU/Linux and FOSS stop to write saying «there's nothing to say». Obviously, if you talk just about GNU/Linux Desktop there's not always a revolution to talk about. How many years we waited to pass from X11 to X.org? And how many to pass to Wayland? In this blog I would talk about programming, computer science, sometimes about math and often about technological trends.
I would like to write some tutorials about Java, iOS programming. Maybe also about C++/QT and pure C and python and Lua. If you have some preferences, please tell me.
Obviously, I'll continue to write my annoying rants :)

Meanwhile, in Italy: Demonstrations and Prime Minister
In Italy, protests against new university law (Decreto Gelmini) continues, moving students and professors. Italian Prime Minister said "True students are at home, studying". I disagree this statement: everybody, in a democratic country, can express his ideas and, even if there are always some extremist factions, it's unfair to despise ALL demonstrators.

Meanwhile, in Italy: Wikileaks and Prime Minister
All goverments are trying to controll the recent wikileaks flood, hunting for Julian Assange, investigation to find the chatterbox. In Italy, the Prime Minister say that all leakes about him are just lies. He says goverment works well and these infamous informations was provided by payed girls, fourth-category politicians or communist newspapers.
I didn't know that to be vice-abassador of USA in Italy is a «fouth-category» office, neither that «The Guardian», «The Economist» and «The New York Times» are pro-communism.
Maybe in Italy we are detached from reality.