Rilasciato Mustang, aka Java 6.0

This morning (ieri, ndr) Sun officially released Java 6 for download after over two years of development. The Java 6 development cycle has been the most open of any Java release with weekly builds available to the public and extensive collaboration between Sun and over 330 external developers. Sun has worked with over 160 companies to ensure backwards compatibility, stability and optimum performance of applications
running on the JVM.

Mario, a quando i primi commenti?

Ma chi usa i trackback? E i tag nei post dei blog?

Mi ricordo che un po’ di tempo fa, ai tempi del suo seminario sui blog, Domenico distingueva tra trackback e pingback. In quell’occasione espressi il mio scetticismo sulla popolarità del trackback. Anche i blog più letti e con tanti commenti avevano pochi trackback. Non riuscii a convincere Domenico.
Ho appena letto un post che sostiene, con maggior brillantezza, le stesse perplessità sui trackback.
Nell’elenco delle feature inutili Dave aggiunge anche il tagging dei post. Questo sarà un brutto colpo per Domenico. Non oso immaginare la sua reazione.

PS. Lo scetticismo non mi impedisce di fare la cosa giusta: questo post ha dei tag associati e spedisce un trackback al daveblog (sbagliando; l’ho corretto dopo 🙂

News dal First Eclipse Italian Meeting

Venerdì 1 Dicembre, al First Eclipse Italian Meeting presso l’IBM Tivoli Lab, abbiamo presentato eConference nella versione attuale e la futura release che includerà Eclipse Communication Framework. I lettori più accaniti ricorderanno che questa nuova versione di eConference è stata premiata con l’Eclipse Innovation Award 2006. A Roma abbiamo raccolto le congratulazioni dal vivo.
Harald Kornmayer, University of Karlsruhe e coordinatore del progetto europeo g-Eclipse, ha chiesto se siamo interessati a diventari contributor di ECF. “Of course yes”, la risposta.
Jochen Krause, amministratore delegato di INNOOPRACT e membro dell’Eclipse Board of Directors, ha chiesto se siamo interessati ad “ajaxizzare” eConference usando RAP (ne avevo già parlato un po’ di tempo fa). La risposta è stata: “Why not?”

The Pragmatic Web

Ormai il “caro vecchio” Web non ci basta più… o almeno ci sembra troppo stantio e si sente il bisogno di trovargli sempre una “nuova vita”…un’evoluzione… parafrasando i girotondini lo slogan di fondo è “un web diverso è possibile”

Ne è riprova la coniazione di sempre nuovi termini che hanno tutti una caratteristica in comune: la parola WEB… dall’ormai “veterano” Semantic Web al “trendy” Web 2.0 fino addirittura al Web 3.0 (forse un po’ “azzardato”)

Recentemente però ha catturato la mia attenzione un “nuovo” termine che in realtà poi così nuovo non è…risale infatti al 2002 ad opera di un signore di nome Munindar P. Singh

Riporto qui qualche estratto dal pragmatic web manifesto:

The goal of the Semantic Web is to develop the basis for intelligent applications that enable more efficient information use by not just providing a set of linked documents but a collection of knowledge repositories with meaningful content and additional logic structure.

Will it work this way? According to Rob McCool, cofounder of the large-scale RDF project TAP, the answer is negative. “Because it’s a complex format and requires users to sacrifice expressivity and pay enormous costs in translation and maintenance, the Semantic Web will never achieve its widespread public adoption.”

In order to enable the use of the Web for communicating, agreeing upon, and cooperatively modifying ontologies, the support provided by the Semantic Web is insufficient. An ontology is an agreed-upon conceptual specification used for making ontological commitments. The crucial question is: how do human agents commit and renegotiate their meaning commitments? And what kind of socio-technical infrastructure is required to leverage these conversations?
This Pragmatic Web constitutes the new challenge that will not replace but extend the Semantic Web. As Singh writes: “The best hope for the Semantic Web is to encourage the emergence of communities of interest and practice that develop their own consensus knowledge on the basis of which they will standardize their representations”

The vision of the Pragmatic Web is thus to augment human collaboration effectively by appropriate technologies, such as systems for ontology negotiations, for ontology-based business interactions, and for pragmatic ontology-building efforts in communities of practice.
In this view, the Pragmatic Web complements the Semantic Web by improving the quality and legitimacy of collaborative, goal-oriented discourses in communities.

Nel settembre scorso è stata inoltre organizzata la prima “International Pragmatic Web Conference” in Germania
Riporto infine alcuni riferimenti interessanti (che io stesso mi riprometto di approfondire)

  • Singh, M.P. The Pragmatic Web: Preliminary thoughts. In Proceedings of the NSFOntoWeb Workshop on Database and Information Systems Research for Semantic Web and Enterprises, (Apr. 2002), 82–90.
  • Singh, M.P. The pragmatic web, IEEE Internet Comput. 6 (3) (2002).
  • De Moor, A. Patterns for the Pragmatic Web. Proc. of the 13th International Conference on Conceptual Structures (ICCS 2005), July 18-22, Kassel, Germany. LNAI, Springer, Berlin

Sarà che sono sempre stato un tipo “pragmatico” ma quest’altra veste del caro vecchio web “a me me piace”;)

Alzati e cammina (da solo, stavolta…)

Seconda puntata della saga “Il sever Ugres e i suoi problemi” inaugurata dal prof.
Venerdì scorso (era un venerdì 17, infatti) dopo che Daniela s’era appena disconnessa (sarà un caso, ma le coincidenze non esistono — in più credo che fosse la prima volta in assoluto che Daniela utilizzava Ugres) il CollaBlog ha smesso di funzionare. O meglio, ha preso a funzionare a singhiozzi. Il db MySQL era divenuto improvvisamente e inspiegabilmente lento nel rispondere. WordPress si connetteva al db 1 volta su 20, o anche meno. Ho riavviato come da prassi i servizi httpd e mysqld, ma niente. Ho chiesto come al solito numi al buon Mario, ma nemmeno lui è riuscito a venirne a capo.
Stanchi, abbiamo rimandato tutto alla mattina successiva.
“Ha da passà ‘a nuttata,” pensavo per me, ma pare funzioni pure per Ugres. La mattina del sabato, infatti, il CollaBlog risponde subito al primo tentativo. “Coincidenza,” pensiamo con Mario. Seconda volta anche, e terza pure. Tutto era andato a posto da solo. Come? Boh!

Autonomic-Ugres…

Do you know Domain Driven Design?

DDD book by Eric Evans

“A document must be involved in project activities” — Eric Evans

Inutile nasconderselo: una delle cose più difficili da mettere in pratica è l’allineamento fra la documentazione (requisiti e design) ed implementazione. Di approcci ce ne sono tanti ma uno dei più interessanti è il DDD. Non si tratta di un vero e proprio processo software, più o meno formalizzato, ma di una differente prospettiva che pone il modello (il dominio, ossia entità e relazioni, ossia classi e associazioni) al centro dello sviluppo (inteso in senso lato, dalla discussione continua dei requisiti al codice).

Essenzialmente:

  1. si definisce (e si arricchisce/modifica costantemente) un linguaggio comune tra sviluppatori e committenti (Ubiquitous Language) il cui scopo è fornire il vocabolario per il modello e per tutte le interazioni umane.
  2. Progetto e implementazione fanno costantemente riferimento al dominio: se un dominio non è implementabile allora perde di valore! Nella pratica questo porta ad analizzare (discutere) più a fondo il dominio con il risultato di semplificare il dominio: sviluppatori e committenti interagiscono, il software si modifica per meglio aderire alle esigenze man man che esse emergono dal fog of ideas ma queste idee sono effettivamente realizzabili
  3. Si fa uso massiccio di un insieme di pattern e best practices (chiamati Building Blocks) nella strutturazione dell’applicazione al fine di isolare il modello dai requisiti sistemici che lo sporcherebbero (quindi: layered architecture, entities, value objects, services, repositories, …).

Molti concetti sono, in effetti, quelli che sono alla base della normale buona programmazione ma che sono particolarmente importanti in un processo software agile dove la qualità dell’elemento umano (la cultura dello sviluppatore, intesa sia come conoscenze tecniche che del dominio) è (finalmente, dico io) messa al centro della costruzione del software.

Effettivamente mentre un approccio document-centric (cioè che produce molta “carta”) tende a modellare lo sviluppo software come un processo manufatturiero “qualsiasi” dove operai poco skillati realizzano progetti di ingegneri skillati, un approccio agile (o code-centric) ha bisogno di personale ugualmente versato (le specializzazioni sono scontate ed emergono naturalmente ma non si tratta di differenziazioni rigide ma di opportunità per il project manager): in ogni caso non sono ammissibili sviluppatori-analisti che ignorano l’implementazione e “code-monkeys” che ignorano il dominio.
Il libro che voglio segnalare è Domain Driven Design, Tackling Complexity in the Heart of Software di Eric Evans: praticamente il libro clue per questo argomento e consigliato senza esclusione da mostri sacri come Martin Fowler e Kent Beck. Ok, non è leggero come Topolino ma si trovano degli interessanti spunti per la nostra professione … 😀