Gruppi: 4-5 persone, idealmente. Scadenza: 31 Ottobre per creare i gruppi.
I gruppi:
- Definiscono API, che si discute poi insieme. Le API devono essere versioned, perchè potranno cambiare durante il progetto.
- Definiscono stories e piano di implementazione
- Definiscono casi di test per le API e le mettono nel CI environment
- Scrivono integration test cases
Il gruppo si divide internamente il lavoro di implementazione e di testing, ma tutti devono avere commits visibili su github.
Ogni gruppo ha un solo GitHub. OGNI membro del gruppo scrive sia codice che test cases, e la cosa deve trasparire da commit fatti dallo studente visibili su GitHub
Il gruppo fa setup di CI environment (tutti devono saperlo fare, anche se il CI e’ uno per gruppo).
Wiki o ReadMe
Il progetto ha una wiki, pubblica o privata a vostra scelta (comunque su github) che descrive obiettivi e contiene puntatori a:
- API description document (su apiary)
- Applicazione su Heroku
- Github repository
- La descrizione del progetto ( come lo avete compreso) e della parte del progetto che voi realizzerete
La wiki contiene inoltre i nomi dei partecipanti al progetto
Sistema di supporto ad homework ed esami
Sistema che consente la consegna di assignments che contengono
i) codice
ii) testo
iii) URLs (eg di heroku, apiary,. GitHub,..)
instructor/Teaching Assistant (TA) può definire e caricare sul sistema funzioni che testano la consegna (testano l’ora, il fatto che rispondano a ping, ma anche test specifici, tipo che API faccia quello che deve).
Il sistema offre templates e facilitazioni per i test più comuni
TA puo’ indicare che il codice o la documentazione sia peer reviewed
In questo caso N membri della classe ricevono e commentano e poi caricano il doc commentato (o uno URL, ma importante che sia una consegna “immutabile”)
Verifica di IP address da cui viene fatta la consegna
TA o peer reviewer possono anche dare un voto, secondo una scala stabilita da TA
Se TA decide, studente può vedere in tempo reale durante l’esame se quello che ha consegnato fino ad ora passa i test
What you should think about and define?
- Entities (Resources), APIs, Functions (besides CRUD),
- DB
- Alternatives: hardcoded variables, MongoDB
- Autenticazione - tabella utenti/ruoli
- UI (Optional)
- Sviluppare back end e definire casi di test che verificano le funzionalità di sistema - può essere script, test-driven development, casi di test per ogni funzionalità che verifica il corretto funzionamento delle loro API
Presentazione idea/soluzione di progetto
- Entro il 12 Novembre ore 12
- Github repository creato (eventualmente privato, se preferite), e link inserito sul file di registrazione
- Apiary file (in swagger language) creato e messo sotto version control sul github repo
- Applicazione "vuota" che risponde "hello world" o quello che volete, deployed su heroku (mettete il link a vostra heroku app sul solito registration file)
- github wiki contenente per ora almeno i nomi del gruppo e dei partecipanti, link a apiary, link a heroku
- ogni persona del gruppo deve fare una modifica a un file qualunque, ma uno stesso file (ad esempio un readme.md o readme.txt, dove ciascuno aggiunge il proprio nome e fa commit) e fare push sul github repo
- se il repo e' privato, condividetelo per cortesia con epaja, marcorobol and jorgeramirez
- 13 Novembre: presentazione idea progetto da loro
- Definizione soluzione
- APIs
- User Stories definite
- 22 Novembre:
- API per il tema del progetto scritte in swagger, almeno a livello di REST resources, non e' necessario specificare per ora il formato degli oggetti che vengono passati
- ad esempio, per un app di movie search vorrei vedere API per /movies, /cinemas, /cinemas/{id}, con per ogni operazione una brevissima desc e le risposte possibili con http status codes; quindi per il vostro progetto non potete avere come risorse solo student e professor, non confondete le risorse con i due tipi di utente e i loro accessi e diritti
- se avete dubbi sul linguaggio per API specification, potete anche fare riferimento a https://swagger.io/docs/specification/about/ per un aiuto
- definizione di un project su github, e vi consiglio di utilizzare il template automated kanban
- user stories per ll servizio che dobbiamo realizzare, specificate come issues su github. Per la parte "how to demo" delle storie, scrivetela dentro le stories (dentro gli issues in guthub). Mi aspetto da voi le user stories, se avete dubbi chiedete. NON vi daro’ una lista dei requirement da implementare, definite voi le stories sulla base di quello che vi ho raccontato e se avete dubbi da chiedere ai "customers" (io, marco e jorge), chiedeteci
- NB: non importa che siano perfette, Lo stiamo facendo come esercizio e siamo qui per imparare, ma e' importante che ci dedichiate del tempo. Pensateci, con cura, e proponente API e storie "ragionate", a valle della lettura della documentazione fornita su API e scrum. Quello che non potete fare e' scrivere due cose velocemente solo per dire "fatto".
- 26 novembre
- Definizione di issues nel backlog (Vi consiglio di creare un issue su github per [metodo, verbo] (ad es, POST su /users), assegnarlo alla persona del team che deve farlo)
- Issues assegnati a persone (vedi sotto)
- APi completata, da implementare su apiary e come sempre committed su github
- Con descrizione e schema per i parametri
- 4 dicembre
- prima release del progetto
- discussione in aula
- 19 dicembre
- final release del progetto, sottomissione entro e non oltre le 12 in punto (mezzogiorno) del giorno stesso
- presentazione in aula dalle 13:30 alle 17:30