micheledellatorre.net

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? Continua »

Credo che meriti una presentazione tutta per lei la mia moto, una Suzuki SV650S, modello 2007 (K7) nera.

Avevo smesso di andare in moto a 18 anni, quando la mia Mito Ev ero stata demolita in seguito ad un incidente con un fuoristrada che aveva avuto l’idea di invadere la mia corsia (come mi disse Max, un incidente a 18 anni lo abbiamo fatto tutti…) e ho avuto la possibilità di comprarne un’altra solo quest’anno avendo iniziato a lavorare dopo superiori e università.

Volevo un mezzo che mi ricordasse per quanto possibile la Mito, senza però l’erogazione appuntita di un 125 da 30 cv e rotti (quando penso a cosa si perdono i sedicenni di oggi in giro con i 125 4 tempi mi viene da piangere ): cercavo quindi un mezzo di impostazione sportiva, ma non esagerato come le race replica di cui sono piene le strade, possibilmente bicilindrico.
Il mercato non offre molto in questo senso, soprattutto in un paese modaiolo come l’Italia, e alla fine la scelta si era ridotta a pochissimi modelli. E scegliere non è stato facile.

Il lizza erano rimaste le Kawasaki Er6, sia in versione naked che carenata, le Suzuki SV, anche in questo caso in doppia versione, e la Suzuki GSR che, pur non rispecchiando molti dei requisiti, è dispertamente “sexy”.
Le Kawa non mi sono piaciute così tanto, a vederle dal vivo non mi hanno dato l’impressione che mi aspettavo… non so come dire, ma sicuramente i motociclisti mi capiscono: la moto è prima di tutto una sensazione e se questa viene delusa si cercano altre soluzioni.
La GSR è stata scartata per un motivo molto più pratico: io sono alto 1.89 e su quella moto mi trovo ad avere le gambe troppo divaricate visto che si trovano all’altezza del motore.
L’SV è stata quindi scelta in versione semicarenata per l’impostazione di guida più sportiva rispetto alla naked.

Per il momento sono davvero soddisfatto dell’acquisto: portata a casa con poco più di 5000€ (motivo per cui non ho nemmeno più cercato gli usati), la posizione di guida si è rivelata piuttosto comoda e non mi è mai capitato di avere dolori alla schiena o ai polsi, nemmeno dopo 5 ore senza mai scendere; la sella invece è duretta e quella si fa sentire dopo qualche ora di viaggio!
Il motore è la parte che apprezzo di più: corposo a tutti i regimi e dando gas ci si ritrova a velocità da ritiro della patente prima di rendersene conto e se a questo aggiungiamo un consumo medio intorno ai 20 km con un litro di benzina, il quadro non può che essere decisamente positivo.

Gli unici difetti che ho trovato riguardano la forcella che è decisamente morbida anche senza forzare la guida, basta prendere un dosso rallentatore un po’ decisi e si nota un affondamento evidente, e i freni che avrei preferito con più mordente quando si tira la leva; non voglio assolutamente dire che la moto non freni, anzi, è solo che tirando la leva non poca forza si ha la sensazione che l’impianto possa dare di più.
Cercherò di risolvere questi problemini al prossimo tagliando, un kit forcella e delle pastiglie diverse dovrebbero essere più che sufficienti.

Ora una foto, scattata sul passo di San Marco qualche settimana fa:

Tra i tantissimi strumenti che si usano per la progettazione e lo sviluppo del software, il mio preferito è sicuramente la lavagna, tant’è che sono giunto alla conclusione che non si sta facendo nulla di complicato se non si sente la necessità di averne sempre una a portata di mano.

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.

Inauguro il blog con un post che dice poco o nulla, ma serve soprattutto per rompere il ghiaccio.

Nella pagina spirito del blog troverete le motivazioni che mi hanno spinto ad aprire questo sito, ora spero di avere il tempo di seguirlo a sufficienza e, cosa più importante, qualcosa di sensato da scrivere.