Prima di entrare nei dettagli del codice e della soluzione, faccio una breve introduzione al problema.
L’applicazione in oggetto è un sistema di controllo domotico relativamente semplice, infatti il compito richiesto è il coordinamento della sola parte audio e video, senza altri tipi di integrazione.
Il controllo dei sistemi audio e video è un problema che ricorre in tutti gli impianti realizzati dall’azienda in cui lavoro attualmente, quindi per accelerare i tempi ho scritto un framework in Java in modo tale che tutte le problematiche ricorrenti vengano gestite nel modo più automatico possibile.; tale framework è abbastanza complesso perchè ogni impianto è fatto ad hoc per ogni cliente e quindi si ha una grande varietà di classi in grado di risolvere i problemi tipici.

Nell’ultima installazione, sebbene i singoli compiti fossero confinati al controllo dell’audio e del video, si aveva per la prima volta un insieme piuttosto vasto di apparecchi; in altri termini la singola stanza è semplice, ma quello che è elevato è il numero delle stanze stesse.
La centrale di controllo si interfaccia con i dispositivi o tramite una delle sue porte seriali oppure tramite una connessione IP.
Al momento del test dell’impianto è stato evidente che in alcuni casi le cose non andavano come previsto: la centrale di controllo inviava effettivamente i comandi, il dispositivo rispondeva in tempi brevissimi, ma l’applicativo di controllo vedeva la risposta solo dopo un po’, a volte il ritardo era anche di alcuni secondi.

Era necessario capire il problema e trovare la soluzione.
Avevamo due indizi fondamentali: il primo erano tutti gli impianti fatti in precedenza, anche più grandi di quello in oggetto e scritti nel linguaggio di programmazione proprietario della centrale, che hanno sempre funzionato senza problemi e che le connessioni seriali non davano alcun problema di sorta.
La conclusione era abbastanza evidente: per qualche motivo c’era un problema sulla ricezione di pacchetti IP dall’applicativo Java… ma dove?
Gli indagati erano 3:

1. Il framework nella sua completezza
2. la gestione delle connessioni IP a livello applicativo
3. la JVM e il sistema operativo della centrale

Il framework nella sua completezza non sembrava il responsabile, visto che gestisce senza alcun rallentamento le connessione seriali, quindi il problema era o nelle connessioni IP a livello applicativo o in uno degli strati a cui si appoggia, ma sul campo non avevo modo di capirlo, infatti se la regola numero uno dell’ottimizzazione è

Non ottimizzare

la seconda è

Misurare, non tirare a indovinare

quindi sono tornato in ufficio e con calma mi sono messo a lavorare sulle connessioni IP a livello applicativo, che erano l’unica possibilità per me di migliorare la situazione: un rallentamento a livello di JVM o di sistema operativo infatti non sarebbero stato risolvibili da me direttamente.

L’ambiente di test che ho realizzato è stato molto semplice: due connessioni TCP/IP su socket locale che si scambiano dati secondo un protocollo banale, cioè un processo inviava dei dati all’altro che li rispediva indietro (in sostanza una delle due parti è un echo server).
Usando il profiler di Netbeans scopro che la maggior parte del tempo viene passata nella funzione di lettura dei dati da socket, questo mi ha dato due indicazioni importanti:

1. il problema probabilmente era lì: il campo di ricerca si era ridotto
2. la lettura però è bloccante, quindi è ragionevole che si passi molto tempo in quel metodo

Il metodo di lettura da socket è qualcosa di questo tipo:

public String read() throws IOException {

Il modo di procedere è stato analizzare i 4 blocchi lo compongono: ho cercato una soluzione più veloce per ogni parte confrontando i dati con quelli del caso base.
I check e la creazione della stringa in pratica non hanno impatto sulle prestazioni, così come la sostituzione del bufferedReader usato per incapsulare il socket con qualcosa di più leggero, mentre riciclando il buffer al posto di ricrearlo ad ogni invocazione le performance sono migliorate di un 40% abbondante, che è un ottimo incremento, superiore alle mie aspettative, infatti sarei stato pronto a scommettere che il collo di bottiglia fosse sulla lettura e non lì: ecco perchè è importante misurare sempre quando si ottimizza, lasciando in disparte il proprio intuito. 

Molto soddisfatto di quanto ottenuto, modifico anche il programma che sulla centrale e lo provo: con immensa sorpresa noto che l’incremento di prestazioni è qualcosa si eccezionale, oserei dire mostruoso. Giusto per dare qualche dato, sul mio pc si passa da 25 secondi a 14 per l’esecuzione di un certo numero di test, sulla centrale di controllo (con un numero di test diversi rispetto a quelli del pc, quindi i dati non sono confrontabili direttamente) da 209 secondi a 10!!! Un miglioramento di 20 volte è a dir poco incredibile.
La motivazione risiede nella JVM usata: su pc ho una Sun ufficiale ultima versione (1.6 con tutti gli aggiornamenti), mentre sulla centrale vi è una JVM non meglio definita capace di far girare J2ME (quindi 1.4).

Le conclusioni sono semplici:

1. L’ottimizzazione fa effettuata solo quando vi è una forte evidenza della sua necessità
2. Codice semplice, modulare e leggibile è da preferire sempre perchè rende più semplice l’eventuale sua ottimizzazione
3. Non fidarsi mai del proprio intuito, è decisamente meglio affidarsi ad un profiler
4. Se è stata effettuata una modifica che non ha apportato miglioramenti significativi, ritornare alla versione originale del codice se ne è stata compromessa la leggibilità
5. Prestare grandissimi attenzione se si sta effettuando sviluppo multipiattaforma o cross-piattaforma: assicurarsi sempre che i miglioramenti siano evidenti anche per la piattaforma su cui si andrà in produzione: spesso le virtual machine e i compilatori sono in grado di aumentare le prestazioni molto più di quanto si creda

Ruby è un linguaggio dinamico che sfrutta la tipizzazione dinamica, quindi può essere modificato a runtime il comportamento di una classe e non vi sono controlli sul tipo a compile-time.
Queste due caratteristiche danno una flessibilità incredibile al linguaggio, ad esempio pensate di avere a che fare con un’applicazione in cui i numeri devono essere trasmessi sulla rete con una codifica particolare a 16 bit; con un linguaggio come Java svilupperemo un metodo con la seguente signature

public static byte[] encodeFloat(float f)

ma non è molto “object oriented” come soluzione, in Ruby è possibile aggiungere il metodo encode direttamente alla classe numerica, arrivando poi a scrivere codice del tipo

socket.sendData( 10.encode )

che è sicuramente più pulito.

Tutta questa flessibilità però ha un prezzo molto salato,infatto il compilatore non è più un nostro alleato e si finisce col perdere tantissimo tempo alla ricerca di un errore comune come la scrittura errata del nome di una variabile o di un suo metodo. Il fatto più irritante è che questo problema può essere evidenziato solo dopo molto tempo. Prendiamo il seguente esempio in pseudocodice:

numero = random(10000)
if (numero > 0) 
    risultato = log(numero).toString()
else
    risultato = numro.toString()

in un linguaggio come Java o C# si viene segnalato subito che nell’ultima riga abbiamo sbagliato a scrivere il nome della variabile, mentre in Ruby ce ne accorgiamo solo quando viene eseguito quel ramo di codice, ma è evidente che la probabilità è molto bassa.

Il test diviene quindi fondamentale visto che deve prendersi carico anche dei compiti che normalmente vengono eseguiti dal compilatore, quindi una metodologia test first è praticamente obbligatoria (tant’è che Ruby ha integrato un framework di test simile a JUnit).

Preso singolarmente questa mancanza non sembrerebbe quindi così grave: chi, come me, scrive sempre i test prima del codice non ha particolari problemi. Peccato che non sia vero.
Tanto per cominciare il compilatore è davvero comodo, cioè ci fa risparmiare tempo, per alcuni tipi di modifiche: ad esempio supponiamo di esserci resi conto che una certa classe è inutile e perchè può essere sostituita con una classe fornita da una libreria. La cosa più rapida è cancellare la vecchia classe, guardare quali sono i file che non compilano più e modificarli: con un IDE come Eclipse l’operazione è davvero molto veloce, visto che con un semplice doppio click sull’errore si viene rimandati dalla riga corrispondente.
In Ruby invece bisogna continuare a lanciare i test finchè la barra non è verde… insomma, è un lavoro decisamente più lungo, specialmente se i test non riescono a darci un’idea precisa di dove sia l’errore.

Il secondo limite, ben più grave, è in sede di refactoring, specialmente per quelli molto comuni come la rinominazione di un metodo o una variabile visto che la mancanza di tipizzazione statica non fornisce alcun indizio al motore di refactoring stesso (tant’è che Netbeans ci obbliga a vedere la preview e accettarla).

Dalla mia breve esperienza, posso dire che Ruby è ottimo quando si devono scrivere programmi relativamente piccoli in tempi rapidi, mentre mi affiderei ad un linguaggio con un numero maggiori di controlli a compile time, come Java o C#, per programmi più vasti o critici.

In Java questo è un tipico caso di Composite, mentre in Ruby è possibile sfruttare la sua capacità di eseguire altri file in modo molto semplice a runtime grazie alla funzione require.

Il modo più semplice di procedere è usare una qualche convenzione per il nome dei singoli file di test, io, ad esempio, chiamo foo_test.rb il file che contiene i test della classe foo.rb.
Ora, ricordandosi che la require non è una direttiva del compilatore, ma una vera e propria funzione, è possibile richiamarla all’interno di un semplice ciclo che scorre tutti i file della directory il cui nome matcha il pattern *_test.rb:

Dir.glob("../test/*_test.rb").each do |file|
  require file
end

Notare che la glob ritorna un insieme di stringhe e non di file, quindi è possibile passare direttamente ogni elemento alla require senza altre forme di processamento.

Lascio a voi per esercizio l’implementazione dello script che esegue anche i test delle sottocartelle :p

Premetto subito che il mio scopo non è fare il gioco, ma imparare un po’ il linguaggio, quindi sono conoscio che il gioco potrebbe non vedere la mai la luce, ma in fondo non è problema grave dal mio punto di vista: se per qualcuno di voi lo è può sempre darmi una mano

Ruby è un linguaggio orientato agli oggetti completamente dinamico, a prima vista sembra ottima l’idea di poter, ad esempio, aggiungere un metodo ad una classe a runtime, ma se a questo aggiungiamo il fatto che Ruby è interpretato si capisce subito che non si ha un compilatore che ci fa notare alcuni errori. I test quindi hanno un valore ancora più elevato perchè devono essere loro a farci notare i problemi che normalmente sono rilevabili staticamente, perciò userò un approccio TDD (sai che novità, ormai lo uso per tutto!).
Come ambiente di sviluppo non mi sento di usare un normale editor di testo: qualcuno sostiene che facendo tutto a mano si impara di più, ma sicuramente si perde molto più tempo; avendo già scritto qualche programmino di esempio senza un IDE credo di avere almeno un’idea dei fondamentali e quindi mi sono orientato su Netbeans 6.0.1 che possiede il supporto per Ruby.
Mi appoggerò alla libreria Rubygame, che è un framework per lo sviluppo di giochi in, nemmeno a dirlo, Ruby.

Ora, facciamo due conti: conosco giusto le basi di Ruby, ho letto due tutorial su Rubygame e normalmente non uso Netbeans… non sembra di certo il miglior modo di partire, ma in fondo sono fiducioso: come ho già detto il mio obiettivo è imparare il linguaggio, quindi non sarà una tragedia che il gioco non sarà mai terminato e comunque credo di avere delle buone basi per tirare fuori qualcosa.

Appena ho scritto un po’ di codice significativo lo posto.

Io seguo la metodologia di sviluppo TDD che non prevede una fase di design iniziale, ma il design deve “nascere” in base alle esigenze del progetto e da quello che il codice comunica. Prima o poi tornerò sull’argomento.
Devo dire che per quello che rigurda il design di dettaglio, cioè la struttura di una o poche classi, il design emergente è effettivamente quello che dà i risultati migliori; quando ho provato ad applicare un approccio classico disegnando sulla lavagna un diagramma UML i risultati non sono stati altrettanto soddisfacenti.
Il problema fondamentale è che un diagramma delle classi rappresenta molto bene le relazioni tra le entità, ma non riesce a fornire alcuna indicazione su come saranno le interazioni tra di esse; prima di scrivere il codice si ha solo un’indicazione e durante la fase di implementazione rimane molto difficile, soprattutto psicologicamente, modificare o rivedere un diagramma che sulla carta (o sulla lavagna) risulta così ben equilibrato e ragionevole.

Per la progettazione di algoritmi invece la lavagna è uno strumento comodissimo, in particolare per quelli concorrenti che non possono essere facilmente sviluppati a partire dai test.

La domanda sembra banale: sotto quali condizioni un oggetto a è uguale ad un oggetto b?

In termini formali l’uguaglianza è una relazione riflessiva, transitiva e simmetrica; le specifiche di Java richiedono anche che sia consistente, cioè che il risultato dell’operazione rimanga lo stesso purchè nessuna informazione usata nella comparazione venga modificata: in altri termini due oggetti il cui stato non viene modificato devono essere sempre uguali o sempre diversi.
In Java, e in molti linguaggi OO, esiste una strettissima relazione tra l’equals e l’hash code: due oggetti uguali devono avere lo stesso hash code, inoltre quest’ultimo non deve cambiare se non ci sono cambiamenti nello stato.

Oggetti immutabili non pongono particolari problemi, mentre per quelli mutabili la situazione è più complicata (altrimenti questo post non avrebbe nemmeno molto senso ).

Fondalmentalmente esistono due scuole di pensiero: la prima dice che due oggetti devono essere sempre uguali o sempre diversi per tutta la durata dell’applicazione, la seconda invece permette variazioni nel risultato.
Nelle API di Java si adotta spesso il secondo approccio, ad esempio per la classe Calendar (che comunque non rimane un esempio di design da seguire…), ma questo crea problemi tutte le volte in cui si indicizza qualcosa tramite hash code, come nelle HashMap o HashSet e in generale nei Set, tant’è che nella javadoc si trova questa frase:

Note: Great care must be exercised if mutable objects are used as set elements. The behavior of a set is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is an element in the set.

Per evitare questi problemi si può seguire l’approccio opposto, cioè sostenere che se due oggetti sono uguali, allora lo sono per sempre e che se sono diversi allora lo sono per sempre. E’ possibile spingersi oltre e dire che deve valere l’uguaglianza comportamentale, cioè che due o più oggetti sono uguali allora non è possibile distinguerli richiamando in un ordine qualsiasi i loro metodi. Questo è l’approccio consigliato da Liskov.
La diretta conseguenza è piuttosto radicale: due oggetti mutabili sono uguali solo se sono lo stesso oggetto, quindi il metodo equals non deve essere ridefinito, così come il metodo hashCode.

In Refactoring Martin Fowler fa una classificazione decisamente interessante in questo senso: ci sono oggetti dei quali ci interessa il valore e oggetti di cui ci interessa l’identità. Fanno parte della prima categoria ad esempio le date e la valuta: in questo caso andrebbero implementati come oggetti immutabili con l’override di equals; appartengono alla seconda categoria ad esempio le persone dove il reale interesse è legato all’identità: istanze mutabili sono quindi legittime, ma potrebbe essere necessario introdurre una factory per garantire che l’esistenza di una singola istanza quando si richiede lo stesso oggetto in punti diversi del programma.

Inizialmente ero molto scettico riguardo a questa definizione di uguaglianza, ma poi ho iniziato a seguirla in modo metodico e devo ammettere che funziona molto bene. Non vi è una grande perdita di libertà nell’implementazione, ma se ne guadagna parecchio in chiarezza del design: ogni volta che mi trovo a creare una nuova classe mi chiedo se sono interessato al valore o all’identità, prendendo poi le decisioni del caso.

La lavagna permette di scrivere molto velocemente sia testo che diagrammi o formule matematiche, cosa che non accade stando davanti allo schermo di un computer, mantenendo un costo di correzione molto basso, utilissimo in fase di esplorazione delle possibili soluzioni; oltre a questo fattore tecnico, io apprezzo molto l’aspetto psicologico: la possibilità di fare due passi davanti al pannello e parlare guardando quando è stato scritto rende il processo più “vivo” e intenso, senza pesare troppo.

Strumenti del genere sono di grandissima utilità, ad esempio all’università mi capitava spesso di scrivere a matita sul tavolo specialmente durante le discussioni con il mio fido compagno di studi Mauro: bastava uno schema chiaro, per quanto abbozzato, per risolvere molti dubbi.

Se vogliamo ben vedere l’unico limite della lavagna è la mancanza del “copia/incolla” che sarebbe particolarmente apprezzabile quando ci si rende conto di dover spostare degli elementi da un punto all’altro, ad esempio durante la fase di posizionamento delle classi nei vari package: in certe occasioni può essere più comodo l’uso di crc cards o varianti… in attesa che tecnologie come Surface di Microsoft diventino di uso comune.