Il Ruby Tower Defence sta procedendo molto lentamente per una cronica mancanza di tempo e per la tipica ansia da tema: alla superiori quando il professore di italiano dettava la traccia non si sapeva mai come iniziare, ma una volta scritte le prime frasi si procedeva in modo spedito.
Nonostante questo qualcosa di interessante è arrivato. Read more »
E’ un po’ che non vado in moto causa maltempo, non ho ancora ripreso a giocare a Guitar Hero a causa del dito, ma almeno ero molto fiducioso per l’imminente uscita di Rock Band qui in Europa dopo tantissimi posticipi. 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.
Se ultimamente ho aggiornato pochissimo il blog la colpa è anche di Guitar Hero 3, versione Xbox: non un gioco, ma una droga da cui si diventa dipendenti nel giro di qualche minuto.
Per chi non lo conoscesse, Guitar Hero è uno dei giochi concettualmente più semplici: bisogna premere i pulsanti sul manico della chitarra, che viene fornita nella confezione, seguendo le indicazioni sullo schermo dove cadono le note. Quando, ad esempio, la nota gialla raggiunge il fondo dello schermo bisogna premere il pulsante giallo e dare la pennata sulle corde muovendo una levetta sulla cassa della chitarra. Ogni volta che si azzecca una nota l’indicatore di quanto si sta rockeggiando sale, ogni volta che si sbaglia scende. Se arriva a zero si deve ricominciare la canzone. 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.
Subscribe to my blog using RSS