micheledellatorre.net

Capita davvero di rado di avere problemi di prestazioni e quindi quando capita è un evento talmente eccezionale che merita uno studio approfondito.

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. Read more »

Come ho scritto qualche tempo fa, ho iniziato a giocare un po’ con Ruby, cercando di realizzare un piccolo gioco.
Il primo approccio non è stato dei più felici. Read more »

Una della basi per poter effettuare il refactoring in modo sicuro e tranquillo è l’avere a disposizione un insieme di test sufficientemente grande da lanciare molto spesso per verificare che il lavoro svolto non abbia introdotto errori.
Utilizzando Java ed Eclipse è molto semplice lanciare tutti i test di un progetto, basta cliccare con il pulsante destro sul progetto e selezionare “run as… JUnit test”, ma con Netbeans e Ruby non è così immediato: è infatti necessario creare una suite di test, cioè un insieme di test cases che quando lanciato esegue tutti i test contenuti.

Read more »

In “Extreme Programming Adventures in C#” ho apprezzato soprattutto lo spirito di Ron Jeffries che voleva scrivere un editor XML in C# senza avere una conoscenza approfondita del linguaggio.
Io mi sono messo in testa di imparare Ruby, giusto per avere un punto di vista differente da quello di Java senza cambiare completamente paradigma di programmazione; seguendo le orme di Jeffries proverò a scrivere un piccolo gioco della serie “Tower defense”, che tanto apprezzo, in Ruby.

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.

Il mio primo post è stato dedicato all’uso della lavagna per lo sviluppo software: ora è finito l’esaltamento iniziale dello vedere il nuovo pannello appeso al muro dell’ufficio ed è il caso di tirare le prime somme.

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.

Ci sono argomenti di ingegneria del software che inizialmente sembrano semplici, ma poi ragionandoci sopra ci si rende conto che non è proprio così: l’uguaglianza tra oggetti è uno di questi.

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