Archive for July, 2006

Riunione Essapici del 24 luglio

Wednesday, July 26th, 2006

Summary: the Essap people met on July 24 for a Rails workshop and a pizza. Good fun.

Workshop

DSC00140.JPG

Riunione Essap del 24 luglio. Ci siamo incontrati alle 15 in un aula dell’Università dell’Insubria per un seminario/laboratorio su Rails. Appena arrivati abbiamo visto che l’aula non era attrezzata per quello che volevamo fare. Ma… si vede che alla Essap i ragazzi hanno imparato bene, perché hanno subito spostato tutte le sedie negli angoli, e portato un tavolone dal corridoio dentro all’aula. Così si fa!

L’obiettivo del seminario era introdurre Rails. La ragione dietro a Rails è che è troppo noioso sviluppare web app in Java, tanto che alla Essap (e anche al Milano XP-UG) ci siamo impantanati su questioni tecniche noiosissime.

Argomenti del seminario:

  1. Hello World. Tutti quanti devono vedere il famoso saluto alla url http://localhost:3000/hello
  2. Simple model. Vogliamo creare un entità di dominio User.
    1. script/generate model User
    2. crea i database, i permessi di accesso, aggiorna la configurazione di Rails
    3. dimostra i metodi di ActiveRecord::base in console, ovvero interagendo con l’applicazione dalla riga di comando di Ruby
    4. scrivi semplici unit test (in realtà learning tests) per le varianti di User.find
    5. aggiungi semplici validazioni, in TDD
  3. simple controller. Sviluppiamo in TDD un UserController che mostri la lista degli utenti.

Siamo arrivati fin qui. Il passo successivo sarebbe stato aggiungere al controller un’azione per inserire un nuovo utente, il che dimostra il funzionamento delle form. Sempre in TDD!

Retrospettiva

Come sempre abbiamo avuto alcuni problemi. Avere le macchine correttamente installate è sempre un problema. La soluzione è arrivare con i kit appositi per Linux (Rails Live), Mac (Locomotive + RadRails) e Windows (InstantRails + RadRails).

UPDATE: fornire agli studenti una procedura da eseguire per verificare che sul loro computer sia tutto installato correttamente. A volte sembra tutto a posto, ma non lo è.

Poi l’idea di avere un PC per due persone non va bene; nella prima fase gli esercizi sono semplicemente “fai come ti ho mostrato e fallo funzionare”, e non ha molto senso fare pair programming (il navigatore non fa nulla.) Magari in un corso di più ampio respiro, posso assegnare degli esercizi da fare in un oretta, e lì va bene fare pair.

Inizialmente avevo deciso di spiegare senza pomodoro. Però abbiamo notato tutti che la cosa funzionava peggio. Dopo un’ora ho iniziato a lavorare con il pomodoro, e la cosa ha funzionato molto meglio. Sono riuscito a fare coincidere con il pomodoro dei “capitoletti” di quello che volevo spiegare. Chissà mai che non sia una buona idea usare il pomodoro anche a lezione?

Renzo mi ha fatto notare che i test con cui ho sviluppato il controller testavano più la vista (con assert_tag) che il controller stesso. Ha ragione, infatti avrei potuto fare prima dei test più semplici con il controller solo.

Comunque credo di avere mostrato un infarinatura di quello che Rails può fare. Tutti i partecipanti (tranne quelli senza PC) hanno seguito il codice con me.

Banchetto :)

La sera ci siamo spostati al circolino per una pizza, dove ci ha raggiunti il Prof. Lanzarone. L’atmosfera di relax ha fatto nascere alcune idee.

La più carina riguarda il modo di fare proseguire XP all’Insubria. Federico ha proposto che gli studenti si organizzino per fare un “Open Team” in un giorno, un ora e un aula fissi ogni settimana. Io potrei sostenerli con una riunione al mese (ma altri XPer sarebbero benvenuti). L’idea è che l’open team sviluppi l’applicazione proposta durante l’Essap (un’app per gestire le prenotazioni delle date degli appelli). Chiunque si ritrovi di lì ed entri, incuriosito dal cartello “Open Team”, può provare a fare pair programming con i ragazzi. Lanzarone ha dato il suo appoggio all’iniziativa, anzi ha lamentato che di buone iniziative degli studenti non ce ne sono abbastanza!
Spero proprio che questa cosa si riesca a fare.

UPDATE: si è parlato di dove mettere il server svn per il team. Una possibilità è di acquistare un minipc da portare in giro, in modo da poter deployare il team in pochissimo tempo. Sul minipc installiamo la buildix, e lo usiamo anche per creare una rete locale wireless.

Si è parlato di fare degli altri seminari su Rails, ma mi pare pleonastico dato che a settembre inizia il mio corso di Applicazioni Web, che parla sempre di Rails.

Dopo la cena, abbiamo passeggiato per le vie della vecchia Varese fino a una remota gelateria. Torniamo a casa stanchi e contenti.

REST per semplificare

Wednesday, July 26th, 2006

Summary: cool post by Scott Raymond Update 2011/06/08: backup copy on the Internet Archive

Scott Raymond scrive di avere adottato per il suo sito lo stile REST, in cui si cerca di modellare tutto in termini delle operazioni CRUD: Create, Read, Update, Delete. Si diminuisce drasticamente il numero di azioni, si aumenta il numero di risorse su cui queste azioni standard si applicano. Il bello è che queste azioni standard si mappano bene sui metodi di HTTP: POST, GET, PUT, DELETE. Questo permette di ridurre il numero di url necessarie. GET /users/3 significa dammi i dati dell’utente con id 3, mentre DELETE /users/3 cancella l’utente numero 3, ecc.

Rails è un eccellente design che si basa su alcune idee importanti: DRY, MVC, Convention over configuration, buon gusto. La nuova buona idea che si aggiunge a queste è REST, come DHH ha spiegato nell’ultima RailsConf.

Il bello è che come conseguenza di questo ulteriore vincolo di design, le applicazioni si semplificano. Raymond scrive:

So, by adding a few controllers, I cut the total number of actions by almost twenty. That’s a pretty big deal, because actions are like moving parts in a machine—the more there are, the more can go wrong. The fact that I could cut almost twenty actions indicates that there was a lot of redundancy hiding beneath the surface. …

Cutting actions is great, but even more significant is that the remaining ones are almost completely uniform. There are seven standard Rails actions: index, new, create, show, edit, update, and destroy. Everything else—oddball actions—are usually a clue that you’re doing RPC. … The upshot is that the controllers are very uniform, which makes the entire application conceptually simpler, and thus easier to maintain, test, and extend.

Finalmente!

Sunday, July 16th, 2006

Summary: we’re running on WordPress.

Ho installato un nuovo blog basato su WordPress. Finalmente riabilito la funzione di commento.