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.