WhiteCat: scheduling tasks depending on role events

I spent a few hours making what seemed a little change to the WhiteCat code, but that soon resulted in a very complex and refactoring-based change: implementing a task scheduler driven by role events.

WhiteCat already publishes role events when a role is assumed or released, based on that and on the last change on role tasks, the idea is to allow an agent to schedule the execution of a role task as soon as the role is assumed by another agent or before the role is released by an agent. The scenario this change covers is that of asynchronous inter-agent collaboration: an agent can ask another agent to do something once it is ready to do it. To get it simple, consider a scenario where a person goes to work, and assume an employee role; thanks to the scheduling another agent is able to "ask" the former to perform a phone call as soon as it is at the office (i.e., as soon as it assumes the employee role). It is like when you say "call me when you are in office" to a friend of yours, or at the opposite "call me before you get home".

Now to get into details, the scheduler is fully configured thru Spring and an agent can specify to the scheduler to perform a task specific to a role by a specific agent or by the first agent that is going to assume/release such role. Of course, the event the task must be performed will be specified at the time of the scheduling, so an agent has the following choice for scheduling a task:

• the task to schedule (of course)
• an agent that must perform the task or any agent that is able to do the task (i.e., any agent that is going to assume/release the role the task belongs to)
• when the task must be executed (after the role assumption or before the role release)

This allows for new dynamic and collaborative solutions in the agent/role modelling! The current implementation exploits AOP to deal with the event dispatching and the task schedulation. Several changes have been done to all the system, starting from the task execution, that now has a task return type that wraps the result of the execution and implements a simple "future reply" pattern, the event dispatching, that now allows for notification of all events no matter of which agent id they are related to, role descriptors and repository, that now are more powerful for inverse role lookup and so on. During the coding several problems have been fixed, and new tests have been added to the code base.

Of course, all the code is available thru the git repository.

Drawbacks of this implementation are present, of course: the scheduling is related to a single role instance, and this could be fixed in future releases since it is based on the role repository. Moreover, it could be interesting to implement a real "do it for me" mechanism, where the execution of the task is totally in charge of the agent running the role (i.e., a pure message based system).

Il peso dell'esperienza...

Anni fa ho realizzato un progetto Java piuttosto complesso, e successivamente sono arrivato a fare un refactoring dello stesso progetto per sistemare le cose che nel frattempo avevo compreso meglio, o che semplicemente potevano essere fatte con pattern differenti. Ebbene, il peso dell'esperienza si fa sentire: il diagramma delle dipendenze dei package mostra un chiaro miglioramento (linearizzazione) fra le due soluzioni. Se la prima ("inesperta") mostrava un groviglio di interdipendenze, la seconda ("esperta") mostra una chiara separazione fra i vari componenti.

Risultato analogo per le dipendenze delle singole classi, dove si evidenzia un numero minore di "allacciamenti" e quindi di legami forti fra le varie classi. Personalmente non considero molto i diagrammi di dipendenza delle classi, non perché non siano importanti, ma perché tendono a fornire risultati facilmente fuorvianti. Infatti aumentando il numero delle classi riducendo contemporaneamente la complessità di ognuna di esse (quindi tenendo la complessità del progetto costante) si vengono ovviamente a creare un numero di dipendenze maggiori. Inutile dire che queste dipendenze non sono "cattive", ma sono naturalmente forzate dal design del progetto stesso. Basti pensare alla programmazione per interfacce, ove ogni classe avrà una dipendenza con una o piu' interfacce. Ad ogni modo di seguito riporto i diagrammi con la situazione di dipendenza reciproca fra classi nettamente migliorata.

Infine una curiosità: il progetto nella sua prima versione si basava su AspectJ, proprio per ridurne la complessità. La sua seconda versione non ha ancora introdotto tecniche AOP (piu' che altro per mia pigrizia). Ciò non significa che AOP non serva, ma semplicemente che AOP permette di gestire anche un cattivo design.

KMail 2 introduce grandi novità

Come si evince da diversi articoli presenti in rete, KMail 2 introdurrà molte novità, in particolare grazie all'integrazione con Akonadi e Nepomuk. Grazie a questi due framework l'utilizzo della posta elettronica acquisterà una nuova semantica: sarà possibile taggare le e-mail, fare ricerche molto piu' veloci (grazie all'uso di un database) e la barra di avvio veloce (ALT+F2) consentirà di cercare non solo fra i programmi ma anche fra le e-mail!

Linguaggi che crescono, linguaggi che calano...

E' interessante osservare la classifica dei linguaggi di programmazione piu' usati. Si nota per esempio che Java rimane IL linguaggio piu' usato, posizione stabile dovuta alla presenza di un numero molto esteso di librerie, sistemi, e applicazioni. Così come è interessante notare che il tanto criticato C++ è ancora ai vertici, addirittura sopra all'elegante C#.

Ma la cosa ancora piu' evidente è l'enorme crescita dell'Objective C, dovuta sicuramente alla programmazione dei dispositivi Apple (iPhone e iPad in particolare).

WhiteCat system complexity

The code visualization for the WhiteCat framework clearly shows the huge weight of the RoleBooster class. In fact, while the whole system is built around a lot of small classes, the RoleBooster is a class that has to do a lot of work in order to achieve the framework goals.

This does not automatically imply a bad OOP design, because the RoleBooster is the central "actor" that must make all the other small classes and objects cooperating together. So, while the RoleBooster itself allows a plug-in architecture, it must use such plugins, resulting in a big chunk of code, even if highly customizable. This situation becomes even clearer looking at the class dependency graph, that shows how the RoleBooster is tied to a lot of other interfaces without having though strong connections.

As for sake of documentation, I put below the image of the package dependency.

Of course, the above images represent the current status of the framework, and are going to change as the system evolves.

Java è un linguaggio sicuro?

Questo post non parla di sicurezza puramente informatica, ma di sicurezza di investimento. Io sono un programmatore Java incallito, di quelli che storcono il naso a pensare a C# pur riconoscendogli il grande valore che merita. Non sono però un fanatico di Java, ritengo che molte cose la Sun abbia cercato di farle "bere" agli sviluppatori (come l'assurdità della bruttezza dell'operator overloading). Mi ritengo quindi uno sviluppatore abbastanza oggettivo circa questo fantastico linguaggio.

Come si sa, Oracle ha acquisito Sun, azienda che ha creato Java. Problema: Java è business, e lo è sempre stato. Quando Java è stato introdotto, le sue prestazioni erano buone (o almeno sufficienti per fare anche elaborazioni grafiche), ma non erano eccelse. Sun era probabilmente tranquilla: poteva dominare il mercato con il monopolio sul linguaggio. Eppure l'interesse attorno a Java ha attirato altre grandi aziende, così IBM incaricò OTI di sviluppare un ambiente (e prima una libreria) ad altre prestazioni per Java: nasce SWT ed Eclipse. Allora Sun deve controbattere: aumenta le prestazioni di Swing e si focalizza su Netbeans (sto andando in fast-forward con la storia...). IBM aveva anche creato un compilatore, Jikes, che produceva codice piu' ottimizzato di quello Sun, unico ambiente dove effettivamente l'azienda deteneva il monopolio. Con l'avvento delle aziende e tecnologie che ruotavano attorno a Java, Sun si vide costretta a inventarsi qualcosa di nuovo: J2EE. Che nelle prime specifiche aveva molte bruttezze analoghe a quelle che gli ingegneri Sun attribuivano al rivale C++.

Nel frattempo diversi sforzi vengono fatti per rendere OpenSource Java, i compilatori, le librerie e perfino le virtual machine.

Allora Sun, forse per mantenersi il favore degli sviluppatori e usufruire della comunità rilascia Java come OpenSource. Ma questo produce un calo delle azioni della compagnia, e Jonathan Schwartz inizia a scalare la compagnia. La compagnia viene poi comprata da Oracle, la quale intenta una causa contro Google. Se tutto ciò è corretto Jonathan possiede azioni a basso presso che si rivalutano non per il maggior potere tecnologico, ma per la causa intentata.

Ovviamente la causa Oracle-vs-Google ha suscitato molte reazioni: c'è chi sostiene che C# (e in particolare Mono) sia piu' sicuro di Java, essendo non in mano ad una azienda. In realtà non è così: C# è di fatto Microsoft. O meglio, è uno standard ECMA, ma le feature sono di fatto decise da Microsoft, mentre per Java le feature sono decise da una comunità. O almeno è stato così con JCP, vedremo ora. Intanto si può leggere l'ottimo post di Miguel De Icaza.

La morale? Non credo ci sia, diciamo che non esiste un linguaggio o una tecnologia davvero sicura. La pervasività della tecnologia (o del linguaggio) fanno la differenza. Ma un pizzico di oggettività non guasta mai...

Hackergotchi

Grazie alla potenza di The Gimp realizzare un hackergotchi è veramente un'operazione semplice. Di seguito riassumo i passi che ho usato per realizzare il mio:

1. si usa la sezione a mano libera per tracciare un contorno approssimativo della testa;
2. si aggiunge un alpha-layer per avere la trasparenza;
3. si inverte la selezione e si cancella con la gomma attorno alla testa una regione rettangolare sufficiente per un taglio con lo strumento di crop;
4. con lo strumento di crop si ritaglia la testa in modo rettangolare;
5. con la gomma e tanta pazienza si va a rifinire il contorno della testa.

Ed ecco il risultato: