AlessioSaltarin WebLog

Pensare in REST (Thinking in REST)

noreply@blogger.com (Alessio Saltarin) — Thu, 23 Feb 2012 10:15:00 +0000

La progettazione di applicazioni Web based ha subìto una silenziosa rivoluzione quando nel 2000 Roy Fielding ha pubblicato la sua ormai celebre dissertazione dal titolo: "Architectural Styles and the Design of Network-based Software Architectures", e in particolare il capitolo cinque: "Representational State Transfer (REST)".

In cosa consiste questa rivoluzione? Esiste una modalità, diciamo così, "classica" di concepire un'applicazione per computer, e questa prevede la composizione di un algoritmo più o meno complesso che prende in input una serie di dati, li trasforma e poi li rende persistenti - ad esempio salvandoli su un database. L'essere umano interagisce con l'applicazione attraverso una "interfaccia utente" che viene aggiornata a seconda del cambiamento di stato - o dell'input o dell'output. Così, in modo appunto "classico", un'applicazione è costituita di un'interfaccia utente, una logica, e uno stato - cioè dei dati persistenti.

Le prime applicazioni Web complesse, rese possibili dalle primigenie tecnologie di trasformazione dinamica dell'HTML, lato server con ASP o PHP ad esempio e lato client con DOM/Javascript, implementavano questo modello classico. Vale a dire, presentavano all'utente un'interfaccia grafica con la quale inserire i dati, offrivano una serie di comandi associati a una logica di esecuzione, e infine persistevano i risultati su un database.

Il problema di questo approccio è che l'applicazione diventa un monolite che si può utilizzare solamente nel modo in cui è stata inizialmente concepita.

Con l'aumentare delle necessità di servizi Web, con l'aumentare dei device eterogenei che vi accedono - dai computer ai telefonini, dai videogiochi alle lavastoviglie - questo tipo di approccio è diventato controproducente: l'applicazione monolitica impedisce di utilizzare i dati e le informazioni che è in grado di veicolare appunto perché è concepita per essere utilizzata in un solo modo, che è quello inizialmente concepito dai suoi autori. La conseguenza di tutto ciò è che ogni nuova esigenza di accedere ad un dato o ad un servizio veicolato dall'applicazione necessita di un cambiamento nel codice applicativo o, peggio, nella creazione di una nuova applicazione ad hoc.

Oggi le aziende spendono moltissime risorse IT proprio perché hanno a che fare con applicazioni monolitiche che non riescono a "servire" il dato in maniera abbastanza neutra.

L'idea alla base del protocollo REST inventato da Roy Fielding è che le applicazioni Web devono essere progettate in modo tale per cui immettendo direttamente le URL (che così diventano URI) su un browser si ottengano immediatamente i dati che servono, e che queste URL possano essere "combinate" tra loro in un workflow per ottenere un'applicazione, allo stesso modo con cui nelle architetture SOA noi combiniamo i "servizi" per ottenere sempre nuove applicazioni.

La URL così richiamata deve essere in grado di rispondere in formato "neutro", possibilmente veicolando solamente "i dati", senza cioè alcuna informazione "grafica" di supporto. Le URL stesse devono specificare il formato dei dati che richiedono: se la URL finisce per ".xml" il dato verrà restituito in XML, per ".json" in JSON, e, naturalmente, di default rispondere con un HTML human readable.

Per finire un esempio. Supponiamo di scrivere un videogioco Web, magari per Facebook. Avremo da qualche parte una struttura dati che prende tutte le informazioni relative al giocatore (Player). Questa struttura dati raccoglie e persiste lo "stato" del giocatore durante il gioco. La modalità classica consiste nello scrivere un'applicazione che, a seconda dei comandi dati via web dal giocatore, cambia lo stato e aggiorna di conseguenza la tabella "Player". Esagerando, l'applicazione potrebbe essere costituita da un'unica "pagina" che, a seconda del comando HTTP ricevuto, risponde in un modo o in un altro. Ovviamente, così facendo, nessuno, ad esempio, potrebbe costruire un altro gioco a partire dai dati correnti dei giocatori: perché le informazioni di stato dei giocatori sono "chiuse", e utilizzabili solo dalla "pagina" di cui parlavamo prima.

Se volessimo applicare il protocollo REST all'entità "Giocatore" (Player), come prima cosa dovremmo definire le "URL" che accedono a ciascuna informazione del giocatore, e le URL che vanno a modificare lo stato del giocatore stesso. Ad esempio:

GET    /player/list(.:format)        player#list

POST   /player/list(.:format)        player#list

GET    /player(.:format)             player#index

POST   /player(.:format)             player#create

GET    /player/new(.:format)         player#new

GET    /player/:id/edit(.:format)    player#edit

GET    /player/:id(.:format)         player#show

PUT    /player/:id(.:format)         player#update

DELETE /player/:id(.:format)         player#destroy

Questa tabella fornisce un verbo HTTP e una URL associata. Queste URL, se chiamate con il rispettivo verbo HTTP, sono già in grado di descrivere le funzionalità di base con cui l'utente può ottenere le informazioni sui giocatori! La prima fornisce una lista dei giocatori, la seconda modifica la lista, la terza ottiene informazioni generiche, la quarta e la quinta inseriscono nuovi giocatori, la sesta permette di modificare i dati di uno specifico giocatore e via dicendo...

Se chiamo /player/list ottengo una pagina HTML, /player/list.json un array di giocatori, /player/list.xml un documento XML. Applicazioni sempre diverse accedono agli stessi dati in maniera omogenea. In questo modo, se l'applicazione è ben scritta, sarà sempre possibile immaginare nuovi modi per accedere ai dati, e produrre applicazioni nuove senza dover modificare il codice lato server.

Chiaramente, progettare un'architettura Web in modalità REST comporta un ribaltamento del modo di pensare: invece che partire dalle esigenze "funzionali", bisogna partire dai dati, e dal modo con cui si può manipolarli. Ma il vantaggio di farlo fin dall'inizio, con disciplina, produrrà significativi risparmi nella gestione evolutiva dell'applicazione, e darà l'opportunità di costruire nuovi modi d'uso di applicazioni esistenti praticamente senza sforzo.

Oggi esistono molti framework che producono applicazioni Web RESTful. Il più famoso è "Ruby On Rails". Seguono "Bowler" per Scala, "Jersey" per Java. E molti altri stanno nascendo.

Interoperabilità tra Scala e Java

noreply@blogger.com (Alessio Saltarin) — Tue, 24 Jan 2012 14:47:00 +0000

Scala è interoperabile con Java, poiché entrambi i linguaggi producono Java bytecode. Questo significa che tutte le seguenti frasi sono vere:

Codice Scala può essere eseguito da una Java Virtual Machine
Codice Java può essere "visto" da codice Scala
Codice Scala può esserre "visto" da codice Java

Supponiamo di avere ad esempio la seguente classe di business in Scala, una generica struttura che rappresenta l'astrazione di un numero razionale. E' costruita passando numeratore e denominatore, ad esempio Rational(2,3) è due terzi (2/3).

 package net.alessiosaltarin.rationals  
   
 class Rational(n: Int, d: Int) {  
   require(d != 0)  
   
   private val g = this.gcd(n.abs, d.abs)  
   val numer: Int = (n / g)  
   val denom: Int = (d / g)  
   println("Created " + this.toString())  
   
   def this(n: Int) = this(n, 1)  
   
   override def toString = this.numer + "/" + this.denom  
   
   def +(that: Rational): Rational =  
     new Rational(  
       this.numer * that.denom + that.numer * this.denom,  
       this.denom * that.denom)  
   
   def *(that: Rational): Rational =  
     new Rational(this.numer * that.numer, this.denom * that.denom)  
   
   private def gcd(a: Int, b: Int): Int =  
     if (b == 0) a else gcd(b, a % b)  
 }  
   
 object RationalComputer {  
   
   def performSum(r1: Rational, r2: Rational): String =  
     (r1 + r2).toString()  
   
   def performMultiply(r1: Rational, r2: Rational): String =  
     (r1 * r2).toString()  
   
 }  
   
 object RationalFactory {  
   
   def create(rationalStr: String): Rational =  
     {  
       val indexOfSlash = rationalStr indexOf '/'  
       val n = nrParse(rationalStr.substring(0, indexOfSlash))  
       val d = nrParse(rationalStr.substring(indexOfSlash + 1))  
       new Rational(n, d)  
     }  
   
   private def nrParse(nstr: String): Integer = Integer.parseInt(nstr)  
 }

Se vogliamo offrire a questo codice una user interface, che non sia Web, abbiamo ben poche possibilità, se vogliamo rimanere nell'ambito di Scala, e cioè quelle di usare il wrapping delle librerie Swing scritto in Scala, vale a dire: http://www.scala-lang.org/api/current/scala/swing/package.html Il problema di questo approccio è che alla data di questo post manca totalmente un editor visuale che generi in output un codice Scala. Quello che abbiamo, invece, sono degli editor visuali che generano codice Swing in Java, ad esempio:

Netbeans Matisse
Eclipse Visual Editor

La buona notizia è che, stanti le premesse di cui sopra, codice Scala può essere visto da Java come se fosse una "libreria" esterna (e viceversa, tra l'altro). Possiamo infatti pensare di realizzare un'interfaccia di questo tipo:

attraverso l'editor visuale che preferiamo, generare il codice Java equivalente, e poi eseguirlo. Per farlo possiamo seguire due approcci, entrambi validi: eseguire dalla macchina virtuale Scala il codice Scala e il codice Java interpretarlo come bytecode esterno, oppure eseguire da una qualsiasi macchina virtuale Java il codice dell'interfaccia grafica e da questo richiamare il bytecode compilato da Scala come una libreria esterna. Chiaramente, è il secondo approccio quello più interessante. Infatti nella pratica avremo a disposizione macchine virtuali Java, ottimizzate a seconda dell'uso. Perché questo approccio sia percorribile, occorre costruirsi un proxy Java in grado di richiamare il codice di business in Scala. Il proxy conterrà i metodi richiamati direttamente dall'interfaccia - nell'esempio, il pulsante di 'esegui operazione'. Ad esempio:

 package net.alessiosaltarin.javaproxy;  
   
 import net.alessiosaltarin.rationals.Rational;  
 import net.alessiosaltarin.rationals.RationalFactory;  
 import net.alessiosaltarin.rationals.RationalComputer;  
   
 public class ProxyLogic  
 {  
   public static String performOperation(Operation op,   
                           String rationalOne,   
                           String rationalTwo)  
   {  
     Rational r1 = RationalFactory.create(rationalOne);  
     Rational r2 = RationalFactory.create(rationalTwo);  
     String result;  
       
     switch (op)  
     {  
          case ADD:  
          default:  
               result = RationalComputer.performSum(r1, r2);  
               break;  
                 
          case SUBTRACT:  
               throw new UnsupportedOperationException();  
                 
          case MULTIPLY:  
               result = RationalComputer.performMultiply(r1, r2);  
               break;  
                 
          case DIVIDE:  
               throw new UnsupportedOperationException();  
     }  
       
     return result;  
   }    
 }

Il codice sopra richiama il codice Scala - il namespace

net.alessiosaltarin.rationals.Rational

Come fa? Semplicemente lo trova nel percorso del codice compilato come Java bytecode, a patto di avere la libreria Scala

scala-library.jar

nel classpath corrente. Supponendo che la classe RationalGUI sia quella generata dal tool visuale, il codice eterogeneo Scala/Java verrà eseguito dalla JVM in questo modo:

java -cp scala-library.jar;[jre,...] net.alessiosaltarin.javaproxy.RationalGUI

Utilizzando ad esempio Eclipse, è possibile aprire due progetti, uno in Scala e uno in Java, e in quello Java che contiene il metodo main, referenziare come libreria esterna il codice Scala custom e la libreria scala-library.jar.

Il negozio di scarpe di mio nonno

noreply@blogger.com (Alessio Saltarin) — Fri, 30 Dec 2011 09:10:00 +0000

"Io appartengo a una grande azienda che produce scarpe..." disse l'ingegner Carozzi. "In questi tempi di crisi, l'azienda sta andando molto male, e sta cominciando a licenziare. Io mi guardo intorno, e credo di aver capito perchè l'azienda in cui lavoro sta fallendo: è perché noi siamo dei bravi venditori, siamo degli ottimi manager, ma non ci capiamo un gran che di scarpe! Anzi, nelle riunioni aziendali si sente spesso dire con una punta di orgoglio dai nostri capi che loro non ci capiscono molto di scarpe, del resto loro sono bravi dirigenti, bravi venditori, non importa che vendano scarpe oppure lustrini natalizi. Non importerà, d'accordo, intanto però l'azienda sta fallendo." L'ingegner Carozzi si scostò un attimo per accendersi la pipa. Fuori stava cominciando a nevicare. "Io dico queste cose con cognizione di causa, sapete." Fece una pausa di riflessione, poi continuò: "Mio nonno aveva un negozio di calzature in centro. Il suo negozio era sempre pieno di gente! E tutti erano molto sorpresi che il negozio di mio nonno fosse sempre pieno. Perché dovete sapere che mio nonno aveva un carattere difficile, era un burbero, un uomo molto pragmatico, era l'esatto contrario di un buon venditore. Lui era capace di dire a un cliente che aveva messo gli occhi su una scarpa molto costosa, che quella scarpa non era per lui, di lasciar perdere, di uscire dal negozio e risparmiare i suoi soldi. Il negozio di scarpe di mio nonno era sempre pieno perché la gente sapeva che quell'uomo burbero era davvero un intenditore di scarpe! Questo perché prima di essere un negoziante era stato un calzolaio. La gente sapeva che quando andava da lui poteva chiedere un consiglio sulla scarpa adatta a lui, e ricevere una risposta del tutto sincera e competente. La gente in quegli anni doveva risparmiare su tutto: non poteva permettersi un acquisto sbagliato! E sapeva che mio nonno gli avrebbe venduto la scarpa giusta. E il suo negozio era sempre pieno! Nonostante lui fosse un burbero, avesse un carattere difficile e non fosse tagliato per il mestiere di commerciante." L'ingegner Carozzi si voltò verso i suoi interlocutori, sorrise loro con un sorriso amaro, poi si voltò e se ne andò per la sua strada.

Navigazione e geolocalizzazione

noreply@blogger.com (Alessio Saltarin) — Wed, 31 Aug 2011 12:38:00 +0000

Sono a P., una città a me sconosciuta, per un meeting. Ho bisogno di una farmacia - mi sono dimenticato le aspirine a casa! Fortunatamente ho con me il mio cellulare Android. Ecco cosa faccio:

1) Apro Google. Siccome ho attivato il geolocalizzatore, la pagina visualizzata riporta chiaramente che mi trovo a P.
2) Seleziono Places
3) Da lì digito "Farmacia". Appare un elenco delle farmacie, in ordine di vicinanza.
4) Scelgo la prima e visualizzo la mappa, con le informazioni in tempo reale del traffico.
5) Ok, il traffico è leggero. Maps mi dice che ci arriverò in cinque minuti in macchina e in nove minuti a piedi! Sono in macchina, ci vado in macchina.
6) Clicko sul Navigatore, che immediatamente attiva il GPS. La voce di una signorina, in bell'italiano, mi racconta la strada da fare, nominando anche le vie.

Il tutto con un Android senza nessuno speciale software a pagamento, con una configurazione "out-of-the-box". Niente male!

Il prossimo passo è andare in un supermercato, fare la spesa, e uscire senza pagare alla cassa - ma ritrovandosi il conto esatto addebitato sulla carta di credito. (Il che non è propriamente fantascienza...)

Fammi ripetere con parole mie

noreply@blogger.com (Alessio Saltarin) — Fri, 24 Jun 2011 17:25:00 +0000

Come Software Architect, la lezione più preziosa è stata imparare che io e lo sponsor del progetto - o meglio, si dovrebbe dire gli stakeholder - parliamo lingue differenti.

Abbiamo del resto una formazione differente, esperienze differenti, e significative difformità nei punti di vista.

Per questo la chiave del successo di un progetto software, oggi, è la chiarezza di comunicazione tra chi fornisce la tecnologia - l'Architect, appunto - e chi intende utilizzarla per raggiungere i suoi scopi di business.

Ecco perché è fondamentale che l'Architect si chieda sempre: ho capito quali sono gli obiettivi di questo progetto? Esiste uno strumento formidabile: dopo aver letto un documento, aver partecipato a una riunione, avere ascoltato le parole degli stakeholder, fermarsi un attimo e dire: "Ok, ora fammi ripetere con parole mie". Vediamo cosa ho capito davvero.

Altrettando fondamentale è chiarire fin dall'inizio che cosa la tecnologia può offrire, e che cosa non può offrire. E' bene fin da subito spianare il campo da miti e leggende. (E lo so che è difficile: è bello all'inizio avere uno sponsor che ci guarda come Bilbo Baggins guardava Gandalf nello Hobbit!)

Direi quindi che sono due le chiavi importanti per il successo di un progetto software enterprise:

1) Voglio capire bene quali sono gli obiettivi da ottenere con il sistema
2) Voglio comunicare bene cosa un sistema è in grado di offrire (e cosa no)

Le questioni tecniche, i disegni architetturali, i dettagli implementativi vengono molto dopo.

Basta Database!

noreply@blogger.com (Alessio Saltarin) — Fri, 17 Jun 2011 14:26:00 +0000

Una domanda che non fareste mai ad un Cliente, che ha un sistema informativo con un suo potentissimo sistema di RDBMS (database relazionale, normalmente Oracle o MS Sql Server), è: "Ok, ma a cosa ti serve?"

Come a cosa serve un database? (Ti guardano come un poveretto, con tanto di occhi sgranati)... Ma non lo sai che in un database ci sono tutti i dati aziendali? Ma non lo sai che è il cuore del sistema informatico? Ma non lo sai che nessuno nemmeno osa pensare di non averne uno...

Mentre sento queste cose mi aggiro curioso tra gli utenti (solitamente disperati) di un tale eccellente sistema: sono lì che combattono con infinite tabelle, piene di dati ridondanti e infinitamente inutili, che per essere tirati fuori hanno bisogno di uno stranissimo linguaggio, perlopiù incomprensibile alle logiche umane, chiamato SQL.

La maggior parte delle aziende, per cercare di tirar fuori qualcosa da quei mostri lì, compra sistemi di Datawarehouse e Business Intelligence che costano loro un ordine di grandezza in più...

Mi aggiro tra sistemisti che sognano vacanze ai Caraibi e mondi senza computer - soprattutto senza database - e tra manager che guardano fuori dalla finestra cercando di capire con quali soldi pagare l'espertone Oracle (o quello che volete) che gli risolverà il loro maggior problema, e cioè: perché ho milioni di dati inutili e non trovo mai quelli che mi servono?

A cosa serve un database? "Ad archiviare i dati". Sono scettico. "A gestire le transazioni..." ok, ci avviciniamo. "Ad estrarre dai miei dati le informazioni che servono per il mio business..." Ah no! Ecco il punto!

Il punto è che la tecnologia delle basi di dati è nata quando i computer erano relativamente lenti, soprattutto i dischi, poco capienti e le applicazioni molto costose da scrivere, perché difficili da creare e debuggare. Perciò si è inventato un sistema altamente efficace nell'archiviare i dati (scrittura) e nel recuperarli (lettura), e questo a scapito della loro intelligibilità e facilità d'uso.

Il sistema relazionale inventato da Cobb è un sistema efficace con computer poco potenti e capienti, esattamente il contrario dei computer di cui disponiamo oggi.

Oggi possiamo tranquillamente immaginare (e realizzare!) un sistema informativo complesso senza database sotto. "E come fai ad archiviare i tuoi dati?" Li scrivo sul disco, ovvio. Sì ma in che formato?

Ecco una buona domanda. Le cui risposte possono essere almeno tre, e ricoprire con ciò gran parte delle necessità di archiviazione di un'applicazione anche di media/grande complessità.

Prima possibilità: flat file. Salviamo tutti i nostri dati in file di testo in formato flat. Esempi: il win.ini, YAML, SQLite, TextDB ecc. ecc. (http://en.wikipedia.org/wiki/Flat_file_database)

Seconda possibilità: chi ha necessità di immagazzinare relazioni gerarchiche di tipo padre-figlio, o strutture fortemente innestate, può usare il formato di testo più potente in assoluto: XML. Il che è però fin troppo per la stragrande maggioranza delle applicazioni.

Terza possibilità: ok, proprio non potete fare a meno di Oracle! Almeno lasciatelo scrivere a chi lo sa fare, e voi non sporcatevi le mani. Utilizzate dunque uno strumento di ORM - object relational mapping - che ha il compito di serializzare, deserializzare e ricercare i vostri oggetti di business in un normale database relazionale.

Quest'ultima possibilità è quella secondo me più interessante, e che spero prenda piede nelle applicazioni enterprise del prossimo lustro. L'articolo che più concisamente descrive la tecnica è questo.
Seguito dall'ottima voce su Wikipedia.

In soldoni, nelle applicazioni moderne, le attività di DDL (Data Definition Language) e DML (Data Manipulation Language) debbono essere demandate ad un apposito strato software (l'ORM appunto) che le svolge al meglio e in modo "trasparente" per l'utente. In questo caso ciò che conta maggiormente nell'applicativo non è più il modello concettuale dei dati, ma il modello concettuale degli oggetti (sottinteso, di business, cioè a dire: web services, remote procedure calls e quant'altro). Il vantaggio consiste, di fatto, nella drastica diminuzione delle risorse necessarie al disegno e allo sviluppo della base dati - fino quasi ad annullarle.

Per Java, il miglior strumento ORM è senz'altro Hibernate, mentre per il mondo Microsoft è l'Entity Framework

Entrambi sono ottimi punti di partenza per dire definitivamente addio agli odiati database.

Testo e font sfocati in IE9 e Firefox 4

noreply@blogger.com (Alessio Saltarin) — Thu, 24 Mar 2011 08:24:00 +0000

Ok, vi siete scaricati Internet Explorer 9 e/o Firefox 4 e, dopo un iniziale periodo di eccitazione mistica, avete pensato di avere bisogno di un nuovo paio di occhiali! "Ma sono io, o si vede tutto un po' sfocato?"

Il fatto è che i nuovi engine grafici dei browser di ultima generazione utilizzano di default - quando la trovano - l'accelerazione hardware via scheda grafica. La rappresentazione di un documento HTML non è più la commistione di font raster (cioè disegnati pixel per pixel) e immagini, ma un'unica immagine che si va componendo mentre la pagina viene renderizzata. L'effetto "sfocatura" è dovuto al fatto che i font non sono più raster, ma vettoriali, e utilizzano le primitive grafiche per essere renderizzati - proprio come accade, ad esempio, nelle applicazioni Silverlight (WPF e compagnia).

Ok, ma io adesso come faccio? E' inaccettabile che lo schermo si veda "peggio" che con IE8 o Firefox 3.

Avete due possibilità: la prima è quella di disabilitare l'accelerazione hardware, ad es. in Firefox 4 sotto Opzioni / Navigazione / Utilizza l'accelerazione hardware quando disponibile. Chiaramente con questo vi giocate una delle più importanti innovazioni dei browser di ultima generazione, cioè l'utilizzo della GPU nel rendering delle pagine, con un sostanziale aumento delle performance.

Oppure potreste fare il "fine tuning" dell'engine di renderizzazione grafica dei font vettoriali. In Windows XP andando su questo sito:

http://www.microsoft.com/typography/cleartype/tuner/step1.aspx

Invece su Vista e 7, semplicemente da Menù Start, scrivendo "Ottimizzazione caratteri Clear Type"

(Io ho seguito quest'ultima strada e sono soddisfatto, però è questione di gusti)

Il fisico e il meteorologo o del perché i progetti IT falliscono

noreply@blogger.com (Alessio Saltarin) — Tue, 14 Sep 2010 12:33:00 +0000

I progetti IT normalmente falliscono. Esiste tutta una letteratura di report e di statistiche sui fallimenti (v. rif. in calce). Quella dello Standish Group (1995 e 2009) stima una percentuale attorno al 70% di fallimenti. Più drastico Gartner Group, che in diversi report, stima attorno all'85% i progetti IT che producono ritorni negativi (ROI < 0).

Chiaramente esiste una moltitudine di risposte alla domanda "Perché i progetti IT falliscono", e molti autori forniscono la loro ipotesi. Io credo che il motivo principale sia dovuto a un errato processo di valutazione dei costi e degli effort di un progetto, dovuto a una serie di miti su come si realizza e si sviluppa un progetto informatico.

Comincerò con un aneddoto. Un fisico e un meteorologo passeggiano in un parco. Entrambi guardano il cielo. Il fisico dice al meteorologo: "Non capisco. Noi fisici siamo in grado di predire al secondo la posizione di tutti i satelliti in cielo, e voi meteorologi non siete in grado di dire se domani pioverà o meno". Il meteorologo, per nulla scandalizzato, lo guarda e gli dice: "Hai ragione! Non siamo in grado di dirlo".

Durante il mio ultimo progetto informatico ho assistito alla stessa obiezione. Siamo in una grande fabbrica di aeroplani. "Ma come" dice il Cliente al Consulente Informatico "io sono in grado di dire esattamente quanto ci metterò a costruire e a consegnare al mio cliente un aeroplano, e tu non sei in grado di dirmi quanto ci metterai a costruire il mio sistema informativo e quanto ti costerà". "Hai ragione" dice l'onesto consulente "non sono in grado di dirtelo."

La verità è che di consulenti informatici onesti - o abbastanza coraggiosi da ammettere la dura realtà - ce ne sono pochi. Quando il progetto, com'è normale, esce dal budget previsto in termini di costi e tempi, si assiste al nascere di curiosissime scuse: il costo del vendor è aumentato, i dati storici erano sbagliati, il progettista che aveva fatto le stime aveva bevuto, il nostro miglior sviluppatore è dovuto andare in maternità, il server con i sorgenti si è impastato. Scuse, scuse, giusto?

I progetti IT - tutti quelli di una certa complessità e novità - sono caratterizzati dalla legge: prima volta-primo uso. E' quasi impossibile calcolare con esattezza il costo di qualcosa che non è mai stato tentato. È così unico, così sfaccettato, e ha così tanti fronti che il numero e la dinamica delle sue variabili crea un problema insormontabile a chiunque stia cercando di valutare i suoi costi a preventivo.

Il numero di variabili e la novità sono i tratti caratterizzanti di un progetto IT. La tecnologia cambia. Gli strumenti cambiano. Le soluzioni sono diverse e nuove. Gli sviluppatori bravi usano tecnologie obsolete, quelli che usano tecnologie nuove, sono impreparati e non hanno abbastanza esperienza. Inoltre, nessuno conosce "a preventivo" che cosa sarà effettivamente sviluppato.

Paradossalmente, il modello di project-estimation e di creazione dell'offerta ancor oggi più usato in ambito consulenziale è quello "Waterfall", costituito da sei step seriali:

1. Descrizione (sommaria e vaga) dei requisiti del progetto
2. Valutazione e stima degli effort e delle risorse necessarie
3. OFFERTA MONETARIA AL CLIENTE (spesso "chiavi in mano", tutto incluso e senza possibili variazioni)
4. Analisi funzionale (dove si comincia a comprendere che cosa era sbagliato al punto 2)
5. Analisi architetturale (dove i dubbi della fase 4 diventano certezze)
6. Sviluppo & Test (dove il disastro assume proporzioni irreparabili)

Da tempo esistono risposte e metodologie per mitigare gli effetti di questa errata impostazione. Queste sono figlie del movimento Agile e del concetto di Ciclo di Vita dello Sviluppo del Software (Application Life-Cycle Management).

Queste metodologie, abbastanza sorprendentemente, sono tuttora ignorate dalla gran parte del mondo consulenziale IT e delle aziende che hanno grandi e complesse realtà IT al loro interno. Questo per un motivo fondamentale, e cioè che la "stima a preventivo" è la testata d'angolo cui poggia tutto il business, sia per chi vende che per chi acquista soluzioni IT. Il problema, come si è visto, è che la "stima a preventivo" è quasi sempre totalmente errata, quando non addirittura una menzogna.

Se per un momento facciamo l'ipotesi di poter fare a meno della "stima a preventivo", possiamo immaginare un processo di Project Costing & Estimation efficace e, soprattutto, vantaggioso per tutti gli attori (win-win). Questo processo è un processo iterativo, che si svolge all'interno di uno "sprint" di tempo - solitamente pari a un mese. In un mese - ogni mese - si fanno:

1. Analisi dei requisiti (e backlog)
2. Analisi tecnica
3. Sviluppo
4. Test e stime (di completamento, di budget, di costo totale ecc.)

e poi si ricomincia. Questa iteratività è alla base di qualunque processo di cambiamento in azienda, e risponde precisamente alla necessità di conoscere qualcosa che, all'inizio, è inconoscibile. E' un processo di raggiungimento della verità.

Sono convinto che se le imprese che lavorano nel settore IT non cominceranno a predisporre processi inerentemente iterativi, i fallimenti non potranno che continuare a essere all'ordine del giorno.

Le tecniche di sviluppo agili, l'intero Agile Movement, il mondo Open-Source insegnano tutti che il modello iterativo - che parte inoltre dal basso, e cioè dal codice sorgente - è un modello che assicura risultati grandemente maggiori rispetto al Waterfall classico. Le grandi realtà di sviluppo software globale (Google, Microsoft) da tempo seguono questo approccio.

Riferimenti:
STANDISH GROUP: http://www.projectsmart.co.uk/docs/chaos-report.pdf
http://www.standishgroup.com/newsroom/chaos_2009.php
http://www.gartner.com/5_about/news/exec_reports.jsp
http://www.itarchitect.co.uk/articles/display.asp?id=203
http://www.projectsmart.co.uk/project-cost-management.html
http://www.it-cortex.com/Stat_Failure_Cause.htm (altri report di fallimenti)
http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland

Differenza tra 'object' e 'class' in Scala

noreply@blogger.com (Alessio Saltarin) — Fri, 02 Jul 2010 13:54:00 +0000

Una delle cose che trovo più intelligenti nel linguaggio Scala, è la netta distinzione tra Tipo Object e Tipo Class. Il primo è un tipo che può avere soltanto una istanza. Il secondo è un tipo che può avere molteplici istanze.

Il primo ha sintassi 'object', il secondo 'class'.

Chiaramente il primo, essendo sostanzialmente una classe "statica", non va istanziato, i suoi metodi possono essere chiamati direttamente. Il secondo va istanziato.

Ecco un esempio:

class Molteplice(nr : Int)
{
  def id = nr;
  
  def parla()
  {
    println("Buongiorno, sono il Molteplice nr = " + id);
  }
}

object Singleton 
{
  def parla() 
  {
    println("Buongiorno, sono un singleton.");
  }
}

object Main 
{
  def main(args : Array[String]) : Unit = 
  {
      Singleton.parla();
      val range = 0.until(10);

      for (i <- range)
      {
         val m = new Molteplice(i);
         m.parla();
      }
      
   } 
}

Questo ci permette di capire subito le intenzioni del programmatore, che deve creare classi solamente dove questo ha realmente senso.

Nella mia esperienza di programmatore OO (in Java, C++ e C#), direi che su 100 tipi in un programma normale, ad esempio di integrazione aziendale, 70 sono singleton (cioè in Scala 'object'), ovvero collezioni statiche di metodi e proprietà, e solo 30 classi vere e proprie (in Scala, 'class').

Ereditarietà multipla in Scala

noreply@blogger.com (Alessio Saltarin) — Fri, 10 Jul 2009 08:51:00 +0000

Il problema dell'ereditarietà multipla nei linguaggi fortemente tipizzati (C++) è, molto banalmente, che se un oggetto eredita da due differenti classi che implementano lo stesso metodo, il compilatore non sa quale implementazione di quel metodo associargli (bind).

In Java e in C# perciò si è deciso di abolire l'ereditarietà multipla, e di inserire il concetto di interfaccia. Il problema delle interfacce, però, è che attraverso di loro viene descritto il comportamento di un oggetto (quali metodi sicuramente quel metodo avrà), ma non viene implementato, perché l'implementazione si demanda alla classe di quell'oggetto.

Questa soluzione non è ottimale, perché se nella mia tassonomia di classi ho delle forti "somiglianze" tra una classe e l'altra, la scrittura dell'implementazione dell'interfaccia comune rischia di doversi ripetere da una classe all'altra. Insomma, rischiamo ripetizioni e riscritture.

In Ruby esiste il concetto di mixin, per cui posso "prendere a prestito" del codice che esiste "altrove" e inserirlo nella mia classe, senza doverlo riscrivere. Il problema è che Ruby è un linguaggio di scripting, e non è tipizzato.

Scala è invece un linguaggio tipizzato che permette - in un certo senso! - l'ereditarietà multipla, e lo fa attraverso i "trait".

Ecco un esempio:


abstract class Animale
{
   def nome:String;
   def classe:String;
   def comeMiChiamo:String = ("Sono il " + this.nome + " e sono un " + this.classe);
}

trait Mammifero extends Animale
{
   override def classe:String = "Mammifero";
}

trait Rettile extends Animale
{
   override def classe:String = "Rettile";
}

class Delfino(aName: String) extends Animale with Mammifero
{
   def nome:String = "delfino "+ aName;
}

class Serpente(aName: String) extends Animale with Rettile
{
   def nome:String = "serpente "+aName;
}

object Main
{
    def main(args: Array[String])
    {  
      parla(new Delfino("Pippo"));
      parla(new Serpente("Pluto"));
    }
 
    def parla(animale: Animale)
    {
      println(animale.comeMiChiamo);
    }
}

In questo esempio, la classe Animale è una classe astratta, che definisce il metodo "comeMiChiamo" (ok, non mi veniva niente di meglio!). Questo metodo è polimorfico rispetto alla "specie" dell'animale. Definisco perciò due nuove classi, che incidentalmente sono anche "classi di animali": i rettili e i mammiferi.

L'output del programma in console è:


Sono il delfino Pippo e sono un Mammifero
Sono il serpente Pluto e sono un Rettile

Quello che voglio dimostrare, è che posso scrivere in Scala una classe che eredita sia da Animale (il metodo "come mi chiamo"), sia da Rettile oppure Mammifero. Per farlo, "Rettile" e "Mammifero" sono due trait, di fatto la trasposizione dei Mixin per Scala. Se vogliamo, sono delle interfacce, solo che, a differenza delle interfacce in Java, il metodo che espongono è anche già implementato - evitandoci riscritture e copia/incolla nel codice (che è sempre male).

PS: La questione della duplicazione dei metodi alla base del problema dell'ereditarietà multipla, non è risolta, in Scala, è solo "evitata", dal momento che il compilatore, quando si tratta di "trait", fa un bel copia e incolla e non si preoccupa di controllare la coerenza - provate infatti ad esempio a far ereditare a Delfino sia il trait Mammifero che il trait Rettile:


class Delfino(aName: String) extends Animale with Mammifero with Rettile

Ajax su Https

noreply@blogger.com (Alessio Saltarin) — Thu, 30 Apr 2009 12:15:00 +0000

Scenario: avete un'applicazione Ajax che funziona benissimo. Switchate il protocollo da Http a Https (SSL) e non funziona più.

La prima cosa che vi viene da pensare (come è venuta a me) è che Ajax - o meglio, l'oggetto XmlHttpRequest - non funziona su Https.

Ricerche e un po' di approfondimenti hanno risolto la situazione.

Intanto confermo che XmlHttpRequest (su qualsiasi browser, in particolare Firefox 3 e Internet Explorer 8) funziona su Https.

Il problema è che la pagina chiamante e lo script Javascript (e tutte le altre eventuali sorgenti che formano la pagina, ad esempio le immagini) devono assolutamente provenire da fonti sicure - cioè da fonti sotto Https.

Nel mio caso, infatti, le pagine venivano servite da una directory virtuale sotto Https, mentre gli script in Javascript erano serviti via Http normale. Se questo è il caso, XmlHttpRequest restituisce un errore di Security.

Xorg.conf per Intel X3100

noreply@blogger.com (Alessio Saltarin) — Tue, 14 Apr 2009 07:33:00 +0000

Un bug introdotto nella release 7.4 di Xorg (Linux) comporta un problema di visualizzazione nelle schede video Intel X3100 - ad esempio montate sui notebook Lenovo T60.

Questo bug fa sì che fallisca il riconoscimento dei driver corretti in automatico da parte di Xorg, cosicché occorre mettere mano direttamente alla configurazione nel file


/etc/X11/xorg.conf

Dopo una serie di tentativi e di studi, sono approdato alla configurazione ottimale, che riporto qua sotto e che si deve immettere andando a editare il file di cui sopra, ad esempio con:


sudo gedit /etc/X11/xorg.conf

Sostituendo interamente il suo contenuto con questo:


# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# Note that some configuration settings that could be done previously
# in this file, now are automatically configured by the server and settings
# here are ignored.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "Device"
Identifier "Configured Video Device"
Driver "intel"
Option "XaaNoPixmapCache"
Option "XAANoOffscreenPixmaps" "1"
Option "DRI" "true"
Option "AccelMethod" "XAA"
VideoRam 440320
Option "XvMCSurfaces" "6"
Option "May_Need_ForceBIOS" "1
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor  "Configured Monitor"
Device  "Configured Video Device"
EndSection

PS:
Oggi a colazione dicevo a Lucilla: "Vedi, figliola, non è vero che Linux è gratis! Il suo utilizzo impone che se uno trova la soluzione a un problema deve pubblicarla quanto prima su Internet. Fondamentalmente è questo il meccanismo che ha permesso all'Open Source di essere ciò che è oggi."

Switch in Python

noreply@blogger.com (Alessio Saltarin) — Wed, 25 Mar 2009 14:10:00 +0000

Com'è noto Python non supporta la sintassi "switch".

Invece che scrivere interminabili e poco leggibili catene di if/elif/else è possibile risolvere elegantemente la cosa con un dizionario.

Ecco un esempio:

        switch = {
           'vigenere': Key(parameters),
           'des': DESWrapper(password),
           '3des': TripleDESWrapper(password)
       }
      
       if crypto_type in switch:
           self.crypto = switch[crypto_type]
       else:
           pass

In questo esempio la funzione imposta l'oggetto self.crypto basandosi su una stringa di input crypto_type, che può assumere i seguenti valori:

vigenere
des
3des

(come potete immaginare è un programma di crittografia). Il dizionario inizializza l'oggetto che, a seconda della stringa in input, può diventare di tipo "Key", "DesWrapper" o "TripleDesWrapper", passando al costruttore gli argomenti corretti.

Se la stringa crypto_type è trovata all'interno del dizionario switch l'oggetto viene inizializzato, altrimenti il programma passa oltre.

Nove regole di bellezza per il codice sorgente

noreply@blogger.com (Alessio Saltarin) — Wed, 21 Jan 2009 10:31:00 +0000

Ho sempre amato un aspetto, nella programmazione dei computer, e cioè che le cose possono essere fatte in moltissimi modi diversi, e non c'è sostanzialmente un modo giusto e uno sbagliato di scrivere un programma per computer.

Tuttavia, esiste certamente un modo migliore ed uno peggiore per scrivere software. Ecco alcune norme basate sull'esperienza che vorrei condividere.

(In ciò che segue intendo per "codice" il "codice sorgente" di un programma per computer)

1. Il codice dovrebbe sempre tendere ad essere "bello"

2. Quasi mai la "bellezza" coincide con la "sinteticità", benché certamente un codice ridondante sia un codice brutto.

3. La "bellezza" di un codice è proporzionale alla sua "leggibilità"

4. Il codice "esplicito" è più bello di quello "implicito"

5. Le strutture "piatte" sono più belle delle strutture "innestate"

6. "Sparso" è più bello di "denso"

7. Un codice utile "in generale" (generico) è da preferire ad uno utile "in particolare" (ad hoc). La genericità è bella.

8. Non esiste un problema di programmazione che non sia risolubile attraverso la scomposizione in sotto-problemi. Perciò un codice bello è un codice "composto".

9. L'espressività di un linguaggio di programmazione si misura in quanti modi differenti è possibile implementare lo stesso algoritmo. Un linguaggio espressivo, solitamente è bello.

Architettura IT e Architettura Civile

noreply@blogger.com (Alessio Saltarin) — Mon, 29 Sep 2008 13:55:00 +0000

Mia moglie fa l'architetto - quello vero! - e spesso mi fa vedere libri illustrati sulle opere architettoniche dei nostri tempi. Io solitamente non ci capisco molto, né riesco ad emozionarmi come fa lei. Una cosa però intuisco: che le architetture edilizie, rispetto alle architetture IT sono sostanzialmente più evolute.

Si capisce molto bene, vedendo un'opera di Renzo Piano o di Fuksas, che il requisito di un'architettura civile non è (non è soltanto, diciamo) la funzionalità, ma vi sono anche requisiti di bellezza, originalità, integrazione col contesto.

La differenza sostanziale tra l'architettura civile e quella informatica è che la prima di solito "funziona" (nel senso che assolve la sua funzione primaria, quella cioè di costituire una o più unità abitative) e di fatto "dura nel tempo".

Le architetture informatiche, anche quelle più complesse e con costi paragonabili a quelli dell'architettura civile, solitamente invece "non funzionano" (nel senso che non riescono a tradurre al 100% i requisiti funzionali in software) e, soprattutto, "non durano" - difficilmente un sistema informatico dura più di cinque anni, quasi mai dura più di dieci.

Come mai quindi l'industria spende milioni di dollari in sistemi informatici che non durano e che non funzionano? La risposta è piuttosto semplice: in questo campo umano, molto semplicemente, non esistono alternative. Noi architetti IT progettiamo "al meglio" quanto la tecnologia e l'ingegneria informatica oggi consentono di fare. In altre parole, come dicevo prima, l'architettura dei sistemi informativi è una scienza relativamente giovane, e come tale, largamente immatura.

Dobbiamo accontentarci di fare, dunque, spallucce, e realizzare quei sistemi qualitativamente pessimi a cui l'industria dei sistemi IT enterprise ci ha abituati?

Io credo di no. E suggerisco, umilmente s'intende, due linee guida (noi architetti IT siamo, questo sì, veramente bravi nel produrre Guidelines!) per migliorare la qualità complessiva dei progetti.

La prima è ovvia, ma sempre trascurata. Premiare la semplicità. Se andate da qualche responsabile IT di una media o grande impresa, vi accorgerete che non riuscirete facilmente a vendere cose semplici. Esistono pochi requisiti informativi enterprise che non siano in realtà soddisfacibili con uno script shell o al massimo con un programma in Python (o in Ruby, guardate per esempio alla lezione di Ruby On Rails), affiancato a un buon database e ad un buona tecnologia di front-end. Ma molto difficilmente riuscirete a vendere qualcosa che non si appoggi a J2EE (una delle tecnologie peggiori e più inutilmente complesse che siano mai state prodotte dall'Uomo) e che non richieda hardware secondo solo a quello della NASA. Credo che questa necessità di complessità sia in qualche modo correlata all'idea che si ha dei computer e del software come qualcosa di oscuro e di magico, campi esoterici in cui il Segreto e il Mistero sono connaturati alla soluzione che si va proponendo.

Della seconda ho parlato nel mio blog precedente a proposito del mio macellaio. Avremo, io credo, un balzo nella qualità dei sistemi informativi quando abbandoneremo del tutto l'idea (presuntuosa e sempre disattesa) di poter stimare il loro valore economico a preventivo. So di dare un dispiacere ai venditori di (complessissime!) metodologie che vorrebbero calcolare a priori il costo o il valore di un progetto informatico: ogni anno vengono pubblicati studi che confermano che questo è un campo del sapere in cui semplicemente non siamo in grado di fare previsioni! Non siamo in grado e non abbiamo una metodologia in grado di stimare il costo di un progetto informatico a partire dai suoi requisiti e dall'analisi funzionale. Come nella meteorologia, in un progetto informatico di medie o grosse dimensioni, le variabili sono talmente tante, che non è possibile tenerle tutte in conto. Perciò ogni previsione è destinata in genere a naufragare.

Per rispondere seriamente e onestamente alla domanda: "quanto costa" occorrerebbe applicare analisi statistiche da confermare con successivi ricicli ad ogni milestone del progetto, convincendo la controparte che - agli stadi iniziali - non si possono avere idee precise sui costi, e che darne una "spannometrica" equivale più o meno a mentire.

Quando ero ancora un ragazzino, il mio datore di lavoro, che fu tra i primi in Italia a proporre soluzioni di Workflow, aveva un metodo infallibile per stimare il prezzo a cui vendere una soluzione software: "Vedi" mi diceva sorridendo "io cerco di capire quanti soldi il mio cliente ha nel portafoglio, e poi cerco di prenderglieli tutti".

Benché tecnicamente ingiustificabile, e moralmente discutibile, questo approccio aveva se non altro il merito dell'onestà intellettuale.

Il costo del prosciutto

noreply@blogger.com (Alessio Saltarin) — Thu, 11 Sep 2008 08:10:00 +0000

In questi giorni mi sto occupando del processo di costing di un'iniziativa di upgrade tecnologico e SOA-enabling piuttosto complessa.

Ci pensavo ieri sera, mentre andavo dal mio salumiere per un etto di prosciutto. Pensavo che se il processo di costing che adottiamo nell'industria del software dovesse essere applicato al prosciutto, molto probabilmente questo genere alimentare - di cui sono particolarmente appassionato - sparirebbe.

Mi immaginavo già la scena mentre entravo nel piccolo salumierino del mio paese.
Entro e saluto il ragazzo al banco. “Vorrei del prosciutto...” dico.
“Ah, le chiamo subito il salumiere capo” - Project Management, costo 2 euro.
“Buonasera sig.Saltarin, cosa le va di mangiare stasera?” - Technical Proposal, costo 1 euro.
“Mah, pensavo a del prosciutto...”
“Ma, mi scusi, del prosciutto cotto o del prosciutto crudo?” - Feasibility, costo 2 euro.
“Del crudo” e sorrido terrorizzato sapendo cosa mi aspetta.
“Ah, guardi, ho del Parma dolcissimo, assaggi... assaggi!” - Proof Of Concept, costo 2 euro.
“Mmm, buono... va bene, lo prendo!”
“Benissimo, sig. Saltarin! E lo vuole al fiocco, o all'osso?” - Functional Specification, costo 3 euro.
“Mah, non saprei... al fiocco?”
“Chiamiamo il Mauro” - il Mauro è l'aiuto salumiere (Development Team)
“Ah, lo so io cosa vuole il Sig. Saltarin” dice il Mauro “un etto bello dolce vicino al fiocco” - Architectural Specification, 3 euro.
“Taglio?” Faccio di sì terrorizzato con la testa.
E il Mauro taglia - Development, 5 euro + 1 etto di prosciutto crudo di Parma, 2 euro.
Le fette cadono sottilissime sulla carta da salumeria - Deployment, 2 euro.
“E mi faccia sapere se era buono!” - Testing, 1 euro.
“In tutto” dice il mio salumiere “fanno 23 euro, con lo sconto facciamo 20! Contento?”
“Mah, tutto sommato forse, guardi, è meglio che vado in Pizzeria...”
“Ma cosa fa, sig. Saltarin, si dà all'outsourcing?”

Scala e i suoi fratelli

noreply@blogger.com (Alessio Saltarin) — Mon, 31 Mar 2008 14:01:00 +0000

Da qualche tempo guardo con interesse ai nuovi linguaggi che fanno la loro comparsa nel variegato orizzonte della programmazione dei computer. Tra gli altri, soprattutto Scala.

Giusto due note a proposito: che sono, lo sottolineo, del tutto soggettive.

La prima: il paradigma della programmazione funzionale non soppiantera' il paradigma a oggetti. Infatti il successo della programmazione a oggetti deriva dal fatto che l'essere umano,normalmente, pensa per oggetti e relazioni tra oggetti, e non per funzioni. Tranne casi particolari (il matematico, il fisico) l'uomo non pensa a un problema in termini funzionali (e men che meno di funzione di funzione, o di funzione di funzione di funzione...)

La seconda: dopo Java (e C#) il panorama dei linguaggi per computer e' abbastanza statico, e ho l'impressione che i nuovi venuti non portino significativo valore aggiunto. Ho l'impressione che oggi il focus si debba spostare dai linguaggi alle API. Il successo di Java, e poi del .NET Framework, si deve all'efficacia e all'ampiezza delle loro API piuttosto che delle specifiche tecniche del linguaggio. Francamente, al programmatore medio importa assai poco delle closures piuttosto che delle list comprehensions. Se invece riesce a creare un file e poi zipparlo in due linee di codice il discorso cambia...

Inoltre, il sempre maggior peso della UI (sia lato desktop che lato Web, il che ho l'impressione che prossimamente sara' la stessa cosa...) privilegia quei linguaggi e piattaforme che permettono di realizzare facilmente le interfacce grafiche e di integrarle con la business logic dell'applicazione.

In questo senso, il .NET Framework con il suo supporto a Silverlight attraverso XAML e il WPF, e dall'altra parte Adobe con AIR/Flex per Flash, siano i veri nuovi protagonisti della scena.

Se starnazza come un'anatra...

noreply@blogger.com (Alessio Saltarin) — Wed, 05 Mar 2008 09:19:00 +0000

... allora è un'anatra!

No, non sono diventato un membro del club degli ammiratori di Massimo Catalano (ricordate "Quelli della notte"?). E' solo un modo per esprimere un concetto che differenzia i linguaggi a oggetti di scripting da quelli compilati. I primi genericamente sono blandamente tipizzati, i secondi invece fortemente tipizzati. Questo impatta sul discorso delle interfacce che facevo in precedenza: nel primo caso (Ruby o Python, ad esempio) il fatto che io esprima un'interfaccia dei miei oggetti è solamente un aiuto che do a chi legge il mio programma: gli comunico esplicitamente come ho pensato il design a oggetti della mia soluzione. Nel secondo caso (Java o C#, ad esempio), senza un'interfaccia, il metodo polimorfico semplicemente non funziona.

Nel secondo caso, per tornare alle anatre, bisogna dire al compilatore: guarda che ti sto passando un'anatra, comportati di conseguenza! Nel primo, all'interprete, non dico niente: se starnazza come un'anatra, allora è un'anatra. Punto e basta.

Un esempio polimorfico in Java e in Ruby ci può aiutare a capire meglio. Cominciamo da un linguaggio fortemente tipizzato come Java:



package anatre;

import java.util.ArrayList;
import java.util.Collection;

interface IGallinaceo
{
 String starnazza();
}

public class Anatra implements IGallinaceo
{
 @Override
 public String starnazza()
 {
  return "Sono un'anatra e starnazzo!";
 }
}

public class Oca implements IGallinaceo
{
 @Override
 public String starnazza()
 {
  return "Sono un'oca e starnazzo!";
 }
}


public final class Cortile
{

 public static void main(String[] args)
 {
  Collection<IGallinaceo> cortile = 
          new ArrayList<IGallinaceo>();
  
  cortile.add(new Anatra());
  cortile.add(new Oca());
  cortile.add(new Anatra());
  
  for (IGallinaceo gall : cortile)
  {
   System.out.println(gall.starnazza());
  }
 }
}

Come si vede, le due classi Ocae Anatra implementano esplicitamente l'interfaccia IGallinaceo, cioè sono (IS-A) a tutti gli effetti dei Gallinacei e il compilatore lo sa a compile-time.

Vediamo lo stesso esempio in Ruby.


class Oca
    def starnazza
        return "Sono un'oca e starnazzo";
    end
end

class Anatra
    def starnazza
        return "Sono un'anatra e starnazzo"
    end
end

cortile = Array.new
cortile.push(Anatra.new)
cortile.push(Oca.new)
cortile.push(Anatra.new)

for animale in cortile
    puts(animale.starnazza)
end

Qui semplicemente io passo una serie di classi al mio metodo polimorfico, e mi limito a richiamare il metodo "starnazza". Se facessi questa cosa in Java avrei un errore di compilazione! Invece, all'interprete Ruby non interessa che io "affermi" che un'Anatra è (IS-A) un Gallinaceo: se starnazza, allora lo è. Si fida! (Beato lui). E se gli passo un oggetto che non implementa "starnazza"? Be', semplicemente avrò un errore a run-time.

Si tratta dunque di due filosofie diverse: nella prima, io devo dichiarare sempre la classe dell'oggetto passato a un metodo, nella seconda posso farne a meno. Non c'è chiaramente una soluzione migliore dell'altra: nel primo caso privilegio le performance, e nel secondo la flessibilità del design.

(E se avete dei dubbi sul fatto che Oche e Anatre starnazzino, date un'occhiata qui!)

Mixin come interfacce in Ruby

noreply@blogger.com (Alessio Saltarin) — Tue, 22 Jan 2008 13:12:00 +0000

Un utilizzo forse un po' anomalo dei mixin in Ruby è quello di considerarli alla stregua di interfacce per implementare un comportamento polimorfico.

Chi conosce almeno un linguaggio a oggetti puro (come Java o C#) sa che le interfacce sono dei contratti che il programmatore stipula con l'utilizzatore del suo codice sorgente per garantirgli che una classe "implementa" certi metodi, con certi parametri. Le interfacce sono alla base dell'utilizzo del polimorfismo nei linguaggi a oggetti compilati.

In genere nei linguaggi di scripting a oggetti, possiamo utilizzare il polimorfismo anche senza le interfacce, cioè ammettendo che, se l'oggetto passato al metodo polimorfico non implementa determinati metodi, avremo un errore a run-time.

In realtà a volte può essere difficile se non impossibile, non avendo a disposizione ad esempio il commento di un certo codice sorgente, sapere se una certa classe è stata progettata per un utilizzo polimorfico.

Bene, grazie ai mixin, noi possiamo rendere esplicita la nostra intenzione di voler far implementare a una classe una determinata interfaccia, o, in altri termini, ad assicurare il programmatore che utilizzerà il nostro codice, che questo utilizza un certo modulo come interfaccia, quindi garantendo che i metodi in quel modulo saranno implementati.

Ad esempio:



module Animale
  def mangio
    puts "Sono un animale e mangio"
  end
end

class Uccello
  def volo
    puts "Sono un uccello e volo"
  end
end

class Gazzella < Uccello
  include Animale
  
  def mangio
      puts "Sono una gazzella e mangio"
  end
end

def metodopolimorfico(animale)
    animale.mangio
end

metodopolimorfico(Gazzella.new)

In questo codice noi abbiamo una classe di Gazzelle che eredita dalla classe base Uccello. Qui il programmatore vuole dirci che Gazzella è (IS-A) sì un Uccello, ma è "anche" un Animale (infatti implementa "mangio"). In questo modo il client-programmer che vuole sapere se potrà passare una "Gazzella" al suo metodo "metodopolimorfico" che prende in ingresso un "Animale" è assicurato: siccome Gazzella è un mixin di Animale, sicuramente rispetta l'interfaccia di Animale (che nel nostro caso è il metodo mangio).

Non solo: Gazzella può fare l'override di un metodo incluso. Infatti lo fa, e "mangio" di Gazzella ha un'implementazione diversa da "mangio" di Animale. Chiaramente, poteva anche non farlo, mantenendo l'implementazione originale (e qui sta la differenza con le interfacce, che sono sempre astratte e vanno sempre e comunque implementate).

Nuovo anno, nuovo blog

noreply@blogger.com (Alessio Saltarin) — Sat, 19 Jan 2008 10:56:00 +0000

Avevo cominciato con l'idea "peregrina" di tenere separato il blog diciamo così delle attività lavorative, che sarebbe questo, dal blog delle attività extra (ho scritto "letterarie" ma poi ho eliminato a furia di backspace), con il risultato che scrivo poco su quello e su questo.
Comunque: il blog "altro" è qui: Fogli sparsi
Ma quest'anno ho intenzione di fare un po' di casino e mescolare i due mondi (i tre mondi, dovrei dire: informatica, letteratura e poesia... aaargggh).
Del resto, come dice Lucilla, lo scrittore e il poeta è morto da tempo, e ora possiamo dare vita a una campagna pubblicitaria ex post....

Espressività e sinteticità di un linguaggio

noreply@blogger.com (Alessio Saltarin) — Tue, 20 Mar 2007 09:32:00 +0000

La recente discussione su Artima che riguarda l'espressività e la sinteticità di un linguaggio (http://www.artima.com/forums/flat.jsp?forum=276&thread=198171) mi spinge a fare qualche altra riflessione, visto che sull'argomento avevo già speso in passato qualche parola.
In questo forum si discute della sinteticità e dell'espressività di un linguaggio come sinonimi (e si sottolinea che non lo sono, o meglio, non è sempre detto che lo siano).
Un linguaggio per computer è conciso quando permette di fare "tanto" con "poche" righe di codice. Prendete ad esempio questa classica ricetta in Python:

thelist.sort()
item_insert_point = bisect.bisect(thelist, theitem)
is_present = thelist[item_insert_point-1 : item_insert_point] == [theitem]

Questo codice permette di cercare un item all'interno di una lista ordinata usando un algoritmo di ricerca binario. Sfido chiunque a fare la stessa cosa, per esempio, in Java, in 3 linee di codice. Dunque, Python è un linguaggio sintetico. (Il che significa spesso che ha delle API molto avanzate: in questo caso tutto il lavoro lo fa bisect).
Eppure, il codice sopra è poco espressivo. Ho detto che per espressività in genere si intende la capacità di un linguaggio di essere:

leggibile (cioé facilmente comprensibile a chi abbia una ragionevole dimestichezza con i linguaggi per computer)
potente (cioé possa esprimere un algoritmo in molti modi diversi)

Sicuramente è poco leggibile - tranne che dai fan di Python! Però capiamoci, non è vero che Python (ma potrei dire Ruby o Groovy o qualsiasi altro linguaggio della scorsa generazione, cioé prima di Scala, per intenderci) sia poco espressivo. Al contrario, viene sempre indicato come un linguaggio super-espressivo (e ciascun programmatore in Python vi dirà che è contento di Python proprio perché permette di fare "tutto" con pochissimo sforzo).

Allora qual è il nocciolo della questione? E' che spesso si confonde l'espressività di un linguaggio con la sua capacità di offrire "zucchero sintattico" per fare le cose normali, senza però aggiungere veramente qualcosa di nuovo. La sinteticità, in fondo, è sempre "zucchero sintattico", a volte è solo un virtuosismo inutile. Perciò, l'espressività di un linguaggio non la misurerei in varianti sintattiche per fare la stessa cosa (esempio, contare da 1 a 1000), ma nella sua capacità di fare cose che altri linguaggi non sono in grado di fare (esempio, le closure di cui parlavamo). Con nuova espressività, un linguaggio è in grado di annoverare tra le sue API, delle API che in altri linguaggi non sono nemmeno immaginabili.

Perché queste cose noiose sono così interessanti? Perché in realtà qui si gioca la nostra capacità di utilizzare i computer per fargli fare - senza perderci una vita - ciò che vogliamo: nuovi modi per lavorare, la possibilità di automatizzare alcuni compiti, o anche nuovi modi per divertirci, dalla comunicazione ai videogiochi. Linguaggi per computer più espressivi ci permetteranno di fare con loro - insieme all'evoluzione tecnologica dell'hardware - cose prima inimmaginabili.