Diario per Tecnologia e Applicazioni Internet, a.a. 2011/12

Matteo Vaccari > Tecnologia e Applicazioni Internet

• 09-03-2012 Lezione 0
  Test-Driven Development.
  • Studiare il Capitolo 5 di Flexible, Reliable Software (pdf)
  • Lucidi
  • Esercizio: ripetere da capo tutto lo sviluppo della PayStation, seguendo il Capitolo 5 e riportando il codice in Eclipse.
  • Esercizio: risolvere l'esercizio 5.4. Il codice per iniziare è in questo zip sul sito del prof. Baerbak.
  
  
• 23-03-2012 Lezione 1
  Architettura di un'applicazione web
  • Esercizio svolto a lezione: come separare la parte "web" di un'applicazione dal modello del dominio. Vedi il codice su github. Per scaricare il codice, usare (solo la prima volta)

    git clone https://github.com/xpmatteo/tecnologia-e-applicazioni-internet-2012.git
    

    Per aggiornare successivamente, usare

    cd tecnologia-e-applicazioni-internet-2012
    git pull	
    

  • Esercizio: modificare l'esercizio visto a lezione per interfacciarsi con la PayStation. Modificare HelloWorldContainer in PayStationContainer, modificare HelloWorldPage in PayStationPage. La pagina deve assomigliare a questa:

    Minuti acquistati: 0
    Quando si preme il bottone "5 ¢", la pagina si ricarica e la scritta diventa: "Minuti acquistati: 2".
  • Leggere Writing Testable Code di Mišco Hevery
  • Guardare The Clean Code Talks - Unit Testing di Mišco Hevery
  • Lucidi
  
  
• 30-03-2012 Lezione 2
  Costruire una GUI web per la PayStation
  • Testare le pagine: come usare asserzioni custom per evitare di fare asserzioni sull'intero codice HTML restituito
  • Come mantenere stateless il server, mantenendo lo stato della conversazione nella pagina
  • Esercizio svolto in laboratorio: quando si preme il bottone "Acquista" viene visualizzata la ricevuta
  • Esercizio da fare a casa: implementare una pagina di "log ricevute". Quando si carica nel browser la pagina http://localhost:8080/admin/receipts si deve visualizzare una pagina del tipo

    Receipts

    2012-04-03 13:24	5 minutes
    2012-04-03 14:14	7 minutes
    2012-04-03 19:14	54 minutes

    Opzionalmente, mostrare anche l'indirizzo IP da cui è stato fatto l'acquisto.
  
  
• 13-03-2012 Lezione 3
  Uso di template per le viste. Introduzione a XPath. Uso di XPath per testare le viste.

  Abbiamo risolto l'esercizio di lezione precedente: fare una pagina di amministrazione che mostri l'elenco delle ricevute di parcheggio acquistate. Questo ha comportato:

  1. Introduzione di un Repository, un oggetto che nasconde la persistenza
  2. Introduzione di Observer, che permette di aggiornare il Repository ogni volta che viene fatto un'acquisto, ma senza introdurre una dipendenza dalla PayStation al Repository. Ho fatto qualche esempio su come questo pattern possa essere usato in svariate maniere arricchendo il funzionamento dell'applicazione senza complicare gli oggetti di dominio.
  3. Introdurre un Router, che decide sulla base della url richiesta quali pagine servire
  4. Introdurre una classe astratta Page da cui le due pagine derivano
  5. Il concetto di model-view-controller. Nel nostro caso il Model è la PayStation, il controller sono gli oggetti Page, e le view sono gli oggetti View.

  Ho fatto un disegno della struttura dell'applicazione e l'ho anche fotografato:

  Per usare i template, nell'esercizio di oggi abbiamo introdotto la classe TemplateView, che ha come scopo di interfacciare il nostro codice alla libreria di templating che abbiamo scelto. Il principio è quello di mantenere isolato il codice della nostra applicazione dalle dipendenze da librerie di terze parti, per due ragioni: uno, perché potremmo decidere in seguito di cambiare libreria e passare, ad esempio, a Velocity, e non vorremmo dover girare per tutta l'applicazione a cambiare le nostre view. E due, perché vogliamo fissare una volta per tutte come abbiamo deciso di usare la libreria FreeMarker. Se ad esempio un domani decidiamo che i template vanno caricati in maniera diversa, ad esempio dal classpath invece che dal filesystem, le modifiche sarebbero concentrate in un unico punto.

  Altra classe introdotta oggi è XmlFragment, che parsa una stringa che contiene XML, e permette di interrogare il documento mediante XPath. Questo ci sarà molto utile per testare in maniera precisa le view. Anche qui il principio è di concentrare in una sola classe la maniera con cui usiamo una libreria, in questo caso il parser XML. Non c'è bisogno di dire che per poter usare questa libreria, il nostro codice HTML deve essere XML valido, il che è sempre una buona idea.

  • Lucidi
  • Vedi il codice su github.
  • Studiare Interfacing with hard-to-test third-party code di Mišco Hevery
  • Studiare il manuale di Freemarker per gli autori di template, sezioni 1-3
  • Facoltativo: leggere Hexagonal Architecture fino a "Sample Code" escluso.
  • Facoltativo: leggere Steve Freeman su come disaccoppiare logging da oggetti di dominio.
  • Esercizio svolto in laboratorio: reimplementare PayStationView usando TemplateView.
    1. Scrivere un test (anche senza XPath) di PayStationView, per garantirci che reimplementandolo, non lo rompiamo inavvertitamente.
    2. Copiare il "template" dalla costante nel codice Java al suo proprio file, e reimplementare PayStationView in termini di TemplateView. Si può mettere una TemplateView dentro a PayStationView, oppure fare ereditare PayStationView da TemplateView.
    3. Testare meglio la PSView, scrivendo qualche test con XPath. Nel file PayStationViewTest ho lasciato qualche traccia.
    4. Infine rimuovere la "set" generica da PSView e sostituirla con un paio di setter specifici: setState, setMinutes
  • Esercizio da svolgere a casa: implementare una PurchaseListView, che usi una tabella e contenga le informazioni specificate nell'esercizio della volta scorsa. Testarla con XPath accuratamente.
  
  
• 04-05-2012 Lezione 4
  Persistenza in Java con Jdbc. Pattern di uso di Jdbc. Il pattern Repository.
  • Lucidi
  • Esercizio: creare un Repository per l'applicazione PayStation. Partire dal codice su github. Passi preliminari:
    • Installare Mysql (su Ubuntu, il package mysql-server)
    • Eseguire script/create_databases.sh
    A questo punto dovrebbero esserci esattamente due test rossi, in DatabaseReceiptRepository.
    1. Fare passare i due test rossi.
    2. Sostituire lo InMemoryReceiptRepository creato nel PayStationContainer con il DatabaseReceiptRepository
    3. Verificare che tutti i test continuino a passare
    4. Terminare l'applicazione e farla ripartire. Verificare nella pagina di amministrazione che le Receipt acquistate siano ancora presenti.
    Domanda: ora che abbiamo il DatabaseReceiptRepository, è ancora necessario avere una singola istanza di repository? O possiamo creare un nuovo DatabaseReceiptRepository per ogni richiesta?
  • Studiare il corso JDBC Basics, sezioni "Getting Started" e "Processing SQL Statements with JDBC"
  
  
• 11-05-2012 Lezione 5
  

  Risorse statiche. Layout.

  Abbiamo visto una soluzione al problema per casa della volta scorsa. Abbiamo parlato dell'importanza di non condividere la connessione al DB fra diverse richieste. La soluzione da me suggerita è di aprire una nuova connessione per ogni richiesta, ricordandosi di chiuderla non appena la richiesta è stata gestita. Una soluzione alternativa potrebbe essere di usare un connection pool.

  Abbiamo visto come fare in modo che la nostra applicazione possa restituire risorse statiche come file CSS o immagini. Se usassimo un container di servlet come Tomcat o Jetty questo sarebbe già gestito; ma poiché invece utilizziamo un framework molto più vicino al protocollo HTTP, queste cose dobbiamo gestircele da soli. Abbiamo visto come applicare il pattern decorator per gestire le risorse statiche senza toccare il codice del resto dell'applicazione (vedi classe StaticAssetContainer nel codice della lezione.)

  Poi ci siamo posti il problema di come definire un layout generale dell'applicazione, che definisca header, footer e altre cose comuni a tutte le pagine dell'applicazione. Abbiamo definito una classe ApplicationLayout e abbiamo visto come usare TemplateView per implementarla.

  • Esercizio da fare a casa. Vogliamo realizzare un'applicazione per gestire fatture. Inizialmente ci accontentiamo di avere una pagina che permetta di
    • Visualizzare le righe della fattura (Invoice), il totale imponibile (cioè prima dell'IVA), l'IVA (VAT) e il totale con IVA.
    • Inserire nuove righe nella fattura.

    L'interfaccia utente sarà simile a questa:

    Fattura
    Descrizione	Importo
    Voce 1	€ 100,00
    Voce 2	€ 300,00
    Voce 3	€ 600,00
    Imponibile	€ 1000,00
    IVA al 21%	€ 210,00
    Totale	€ 1210,00

    Procedimento suggerito:

    1. Codice di partenza
    2. Iniziamo la soluzione dal modello del dominio dell'applicazione. Scriviamo i test per l'oggetto Invoice. Nel codice pubblicato su Github trovate i primi test (che non passano). Facciamo passare tutti i test.
    3. Sarà evidente che il modello del dominio conterrà (almeno) due classi:

             +------------+      0..* +------------+
             |  Invoice   |<>---------| LineItem   |
             +------------+           +------------+
           

       Un LineItem rappresenta una "riga" della fattura e contiene una description e un amount e sa come formattare correttamente una riga. In pratica la fattura è essenzialmente una lista di LineItem.
    4. Realizziamo la parte web dell'applicazione, usando inizialmente un InMemoryInvoiceRepository.
    5. Salviamo e recuperiamo la fattura su database, sostituendo lox InMemoryInvoiceRepository con un DatabaseInvoiceRepository.

    Nota: non usare float o double per il denaro!!! La matematica in virgola mobile non è esatta. Rappresentiamo il denaro con una quantità intera di centesimi. In alternativa possiamo definire una classe Money che incapsula una quantità intera di centesimi ed espone metodi per sommare e per formattare.

  
  
• 18-05-2012 Lezione 6
  Il linguaggio JavaScript. Programmazione a oggetti; prototipi; JSON. Manipolazione del DOM. Test unitari in JavaScript.
  • Lucidi
  • Esercizi svolti in laboratorio (vedi il codice su github)
    1. Caricare il file fibonacci-test.html in Chrome (NON Firefox), aprire il debugger con (bottone destro->Ispeziona Elemento), cliccare su Scripts, cliccare sul bottone in basso a sinistra che apre la console. Osservare il messaggio "Hello, World!"
    2. Modificare il file fibonacci.js; scrivere una funzione che calcola Fibonacci. Stampare sulla console il valore di Fibonacci(20).
    3. Modificare il file fibonacci-test.html per costruire una semplice interfaccia utente per calcolare Fibonacci. Mettere un campo di testo e un bottone etichettato "Fibonacci". - Scrivo "6" nel campo di testo - Premo il bottone - Il codice JavaScript scrive "Fibonacci(6) = 5" in un paragrafo che prima era vuoto.
  • Esercizio da fare a casa: Rifare l'esercizio delle fatture della volta scorsa; questa volta verrà eseguito tutto in una pagina HTML senza parlare con il server. Per prima cosa ridefinire gli oggetti Invoice e LineItem prendendo spunto dalle version Java della volta scorsa. Assicurarsi che funzionino osservandone il comportamento sulla console del debugger di Chrome. Quando siamo sicuri che il nostro modello funziona correttamente, aggiungiamo l'interfaccia utente HTML.
  • Studiare i capitoli 1-6 di Pro JavaScript Techniques di John Resig. La versione pdf si può comprare per $32 circa.
  • Guardare la presentazione JavaScript Survival Guide di Giordano Scalzo
  • (Facoltativo) Materiale su JavaScript a cura di Douglas Crockford.
  
  
• 25-05-2012 Lezione 7
  Come fare TDD in JavaScript. La libreria jQuery.
  • Studiare questa presentazione su jQuery da pagina 4 a 27 comprese.
  • Studiare i capitoli 10,11 di Pro JavaScript Techniques di John Resig.
  • Esercizio fatto in laboratorio: riscrivere il codice javascript della Fattura per usare jQuery. Spostare il codice JavaScript in un file separato "invoice_glue.js". Sfruttare $(document).ready per collegare il comportamento al documento HTML in maniera "unobtrusive".
  • Esercizio da fare a casa: implementare il Lights Out Puzzle con jQuery. Desiderata:
    • Disegnare una tabella di 4x4 bottoni.
    • I bottoni possono essere accesi o spenti.
    • Quando la pagina viene caricata, i bottoni sono accesi o spenti in una configurazione scelta a caso, sempre diversa.
    • Quando l'utente preme un bottone con il mouse, il bottone premuto cambia stato, e così anche i quattro bottoni adiacenti (non in diagonale).
    • I bottoni sul bordo sinistro sono considerati adiacenti al corrispondente bottone sul bordo destro; i bottoni sul bordo superiore sono considerati adiacenti a quelli sul bordo inferiore. In questo modo quando premo un qualsiasi bottone, sono sempre esattamente 5 i bottoni che cambiano stato.
    • Scopo del gioco è spegnere tutti i bottoni. Se l'utente riesce a spegnere tutti i bottoni, appare la scritta "Bravo! Hai vinto!". La scritta deve apparire con una animazione (scegli tu quale.) Deve apparire anche un bottone con la scritta "Gioca ancora"; se l'utente preme il bottone "Gioca ancora", la scritta "Hai vinto" e il bottone scompaiono, e il gioco ricomincia con una nuova configurazione scelta a caso.

    Implementare prima la logica del gioco in JavaScript con TDD. Poi realizzare l'interfaccia utente in HTML.

    Per rendere la cosa ancora più interessante: realizzare tutta l'interfaccia utente in JavaScript, nel senso che il documento HTML inizialmente contiene soltanto

      <html>
        <head><title>Lights Out!</title></head>
        <body><div id="puzzle"></div></body>
      </html>
    

    Tutti i bottoni vengono creati tramite istruzioni jQuery (vedi append). In questo modo anche la dimensione del puzzle viene scelta a caso fra 3x3, 4x4 e 5x5.

  
  
• 08-06-2012 Lezione 8
  Ajax. Come fare Ajax con JavaScript puro e come fare Ajax con jQuery.
  • Lucidi
  • Leggere la documentazione di jQuery.ajax(), i paragrafi "Data Types" e "Examples".
  • Studiare l'articolo Menu Test (esclusa l'ultima sezione Effects Mocking)
  • Leggere l'articolo del 2005 Ajax: a New Approach to Web Applications dove è stato coniato il termine "Ajax".
  • Esercizio svolto in laboratorio e da completare a casa:
    • Collegare la form al server tramite ajax in modo che quando viene premuto il bottone, la form viene aggiornata tramite ajax senza ricaricare l'intera pagina
    • Formattare correttamente con una tabella la fattura
    • Gli importi vanno formattati in euro (es. € 1,23)
    • Devono apparire imponibile, iva e totale con iva
    Modificare (anche) lato server:
    • Ci devono essere una tabella invoices e una tabella line_items
    • Popolare manualmente il database per inserire due invoice che abbiano ID 123 e ID 234
    • Visitando la url /invoices/123 devo vedere la fattura 123 e i suoi line items
    • Visistando la url /invoices/234 devo vedere la fattura 234 e i suoi line items
    • Se aggiunto un line item con la form, deve essere attaccato alla fattura corretta.
    (vedi il codice su github).
  
  
• 13-06-2012 Lezione 9
  Integrare JavaScript lato client e Java lato server.
  • Leggere la Presentazione di Ugo Landini a Java Day 2009 -- 2.5 Tiers
  
  
• 14-06-2012 Lezione 10
  Test di accettazione. Test end-to-end. Smoke test. Come scrivere test espressivi. Continuous integration.
  • Lucidi
  • Leggere la definizione standard di Acceptance Tests per sapere di che cosa stiamo parlando.
  • Implementare l'esercizio. La descrizione dell'esercizio è nel README.
  • Leggere Getting Started With HtmlUnit per imparare il minimo sullo strumento che ho scelto per l'esercizio.
  • (Facoltativo) Leggere Acceptance TDD Explained di Lasse Koskela, che è un ottimo articolo sul perché e sul come.
  • (Facoltativo) Leggere Alternatives to Acceptance Testing per ascoltare un parere diverso
  • (Facoltativo) La piramide dei test. Viene discussa anche in questo ottimo video di Misko Hevery.
  • (Facoltativo) Brian Marick's Testing Quadrants.
  • Nota: la migliore documentazione di riferimento online per JavaScript si trova sulla Mozilla Developer Network.