Home
Il servizio proposto permette all’utente di ottenere suggerimenti di ricette basandosi su ingredienti posseduti. La Webapp è strutturata in modo tale da analizzare gli ingredienti posseduti da un utente e, se richiesto dall’utente, consigliare nuove ricette. L’utente dovrà provvedere all’inserimento degli ingredienti acquistati e disponibili nella cosiddetta “dispensa virtuale”. Da qui il nome del servizio “La Dispensa”.
La dispensa verrà aggiornata in seguito all’acquisto di nuovi prodotti ed al loro utilizzo. Sarà possibile consultare la lista degli ingredienti disponibili in qualunque momento della giornata.
La WebApp sarà, inoltre, in grado di verificare la fattibilità di una ricetta: nel momento in cui l’utente vorrà cucinare un determinato piatto, potrà verificare se gli ingredienti disponibili sono sufficienti per cucinare quella pietanza o meno. Verranno, quindi, specificati i prodotti da acquistare.
Affinché l’utente possa avere una grande varietà di piatti, la WebApp controllerà che una ricetta non venga riproposta nel breve periodo. Vi sarà un sistema di notifica per cibi in scadenza che permetterà di evitare sprechi.
I servizi descritti finora sono pubblici: non necessitano di alcuna registrazione. Servizi aggiuntivi, quali monitoraggio soldi spesi, tracciamento apporto quotidiano di micro e macro nutrienti, esportazione dati personali ed inserimento nuove ricette sono disponibili solo con un’area personale.
| Nome e Cognome | Matricola | Github | |
|---|---|---|---|
| Paolo Aliprandi | paolo.aliprandi@studenti.unitn.it | 209404 | iPaoloTM |
| Letizia Girardi | letizia.girardi@studenti.unitn.it | 213934 | letiziagirardi |
| Michele Lamon | michele.lamon@studenti.unitn.it | 209396 | gelsounitn |
| Andrea Tomasoni | andrea.tomasoni-1@studenti.unitn.it | 209443 | andreaunitn |
- Wiki: Repository Wiki
- Documentazione apiary: Documentazione apiary
- Deploy Heroku
- Backlog e sprint backlog: Google Sheets
- Sprint 1: Backlog e planning
- Sprint 1: Project Board
- Sprint 1: Testing
In questa repository del nostro progetto si trova il codice backend e frontend. Il codice del frontend (HTML) si trova all'interno della cartella "frontend" mentre il codice delle api (nodejs + mongoose + express, inclusa la documentazione Swagger) si trova nella cartella "backend". Abbiamo anche creato una cartella "documentation" contenente i file per la documentazione Swagger + Apiary.
root
├── Immagini //immagini per UI e logo
│ └── forchetta.png
├── README.md
├── documentation //Documentazione Swagger + Apiary
│ ├── apiary.apib //File apiary per documentazione
│ ├── swagger-def.js //File per generazione swagger.json
│ └── swagger.json //Documentazione swagger
├── backend
│ ├── db.js //Configurazione MongoDB
│ ├── home.js //Server
│ ├── insert.js //File per inserire ricette nel database
│ ├── package.json //Dipendenze
│ ├── ricette.js //File API per ricette
│ └── schemas.js //Schema mongoose per le ricette
├── frontend
│ ├── acquisti.html //pagina principale UI
│ ├── dispensa.html //pagina secondaria UI
│ └── home.html //pagina secondaria UI
├── node_modules //Librerie Node.js
│ └─ [...]
├── package-lock.json //Dipendenze
└── spazzatura.txt //Junk file
Ogni membro del team ha pubblicato, condiviso, esaminato ed eseguito modifiche al codice tramite rami Git condivisi con gli altri partecipanti. Adottando un’adeguata strategia di branching, abbiamo collaborato efficacemente dedicando più tempo possibile allo sviluppo del codice.
Sono stati utilizzati principalmente i seguenti modelli di workflow:
- il modello più utilizzato durante questo primo Sprint è il modello “Centralized Workflow”. Questo modello utilizza una repository centrale, detta master branch, la quale funge da unico punto di ingresso per nuove modifiche al progetto. Ogni membro del gruppo, quando intende apportare delle modifiche, clona la repository centrale e nelle proprie copie locali del progetto, modifica i file e con il comando push carica il lavoro sul branch corrente. Così facendo si ottiene una storia lineare senza necessità di comandi merge.
- un secondo modello utilizzato è il modello “Git-Feature Branch Workflow”. Questa strategia prevede la creazione di branch dedicati a specifiche feature. Una volta che la feature è conclusa, il branch viene chiuso e si aggiorna il branch master tramite un comando merge. Si è rivelato molto utile nella divisione del lavoro tra i membri del gruppo. Questa tecnica è stata adottata in modo da evitare la “Master only strategy”, ovvero quella tecnica che prevede di lavorare sempre su un solo branch: il branch master.
Esempio branching secondo il modello “Git-Feature Branch Workflow" - in tale branch é stata implementata la funzione cercaRicette. La funzione permette di cercare una determinata ricetta inserita manualmente dall’utente. Affinché la pagina possa essere accessibile tramite un identificatore globale (URL), é stata implementata l’architettura strutturale REST.
Il Product Backlog consiste in un elenco di attività (Product Backlog Item) ordinato per priorità. Già nella fase precedente del progetto (Milestone #4) è stata compilata una bozza di tale documento.
Durante questa prima iterazione, come previsto, abbiamo aggiornato la priorità di alcune attività. Il Product Backlog, infatti, deve essere costantemente rivisto e riordinato in base alle necessità degli utenti, del mercato o in base a suggerimenti da parte del team. Durante l’implementazione della WebApp ci siamo accorti che alcune user stories dovevano avere la priorità su altre, abbiamo quindi dato precedenza alla loro implementazione ed aggiornato il documento.
Il nuovo documento si trova al seguente link: product backlog. Possiamo notare che vi è stato un cambiamento di priorità nelle prime attività. Di preciso abbiamo preferito dare precedenza all’inserimento di prodotti acquistati dall’utente e all’eliminazione dei prodotti utilizzati, rispetto alla diversificazione delle ricette. La verifica dei prodotti mancanti per una determinata ricetta ha ottenuto più importanza in quanto è un servizio che la WebApp da anche all’utente non loggato. Spiegato, quindi, il motivo della minore importanza per l’area personale.
La nostra definizione di "Done" prevede che:
- Il codice relativo alla funzionalità in questione è stato implementato
- Il codice sia stato testato da chi lo ha fatto e sia funzionante
- la correzione di precedenti bug/errori conosciuti sia stata dimostrata al team
- Il codice sia stato letto ed approvato da almeno un altro membro del team
- La documentazione sia stata letta ed approvata da almeno altri due membri del team
- Il database sia stato progettato e integrato per supportare la funzionalità in questione
Il goal del nostro primo Sprint è di realizzare un prodotto software funzionante, coerente e utile. Vogliamo sviluppare una WebApp che possa risolvere un problema concreto, reale, che abbia motivo di essere realizzata. Siamo consci del fatto che con solo uno Sprint non possiamo sviluppare un prodotto software con un alto livello di complessità, rifinitura, dettaglio e correttezza del funzionamento, ciononostante non vogliamo produrre un software incompleto, “beta”. Vogliamo sviluppare un software, seppur ristretto rispetto alla nostra idea finale, che sia concreto, coerente nel suo insieme, e che sia utile per l’utente finale, anche in questa prima versione.
Il nostro goal per questo sprint è stato:
- consigliare ricette
- verificare fattibilità di una ricetta
- inserire ingredienti acquistati
- modificare lista ingredienti acquistati
- visualizzazione degli ingredienti posseduti
- sviluppo UI
- progettazione database
- implementazione metodi REST
- documentazione Swagger e Apiary
Dal meeting, abbiamo convenuto nel implementare le funzionalità relative alle user stories in ordine crescente di importance stimate. Detto questo, siamo passati alla divisione degli incarichi: ognuno dei membri del team ha competenze e conoscenze diverse; c’è chi conosce molto bene Git, chi è più esperto nella gestione di database, e chi è più ferrato nella programmazione frontend. Ma ciò non ci ha influenzato nella divisione dei compiti. Abbiamo voluto evitare la strada facile, preferendo una distribuzione equa e che garantisse a tutti noi di imparare cose nuove e confrontarsi con sfide mai viste prima, piuttosto che una ripartizione basata sulle conoscenze pregresse dei singoli. Ogni membro del team è stato quindi invitato a partecipare attivamente al progetto, sviluppando come preferiva la propria funzione, documentandola e testandola. Agli altri membri del team è stato permesso discutere, per incentivare la comprensione, ed eventualmente poi modificare le altre parti di codice, in modo da favorire la più totale collaborazione. Nel corso dello Sprint ognuno ha rispettato bene i ruoli assegnati, nonostante sia capitato che qualche membro del team chiedesse un consiglio a un altro membro del team. Noi crediamo che, nonostante sia giusto avere dei ruoli assegnati, sia da favorire anche la collaborazione tra il team, a patto che non leda la divisione degli incarichi. Per i meeting e daily scrum di gruppo abbiamo preferito la piattaforma Discord, in quanto si è sempre rivelata perfetta per il team working, anche in altri corsi.
Nella pagina “testing” del documento “Sprint backlog” sono stati indicati alcuni test cases eseguibili con l’attuale versione delle nostre API. Questi si concentrano principalmente sulla ricerca di ricette tramite apposito url “./api/v1/ricette” con aggiunta di parametri come “ingredienti”, “titolo” e “id”. Con l’ampliarsi delle API nel prossimo Sprint, si aggiungeranno nuovi test cases relativi a login, registrazione e aggiunta ricette. Prevediamo di riuscire a provarli tutti e correggere le criticità.
Alla fine dello sprint, abbiamo partecipato al meeting per la sprint review. Inizialmente, eravamo molto titubanti sull’implementazione della nostra idea: approcciarsi con un database non relazionale è stato abbastanza complesso e macchinoso. Essendo sempre stati abituati a database relazionali, abbiamo faticato nel comprendere il funzionamento. Ma successivamente, abbiamo riscontrato una maggiore naturalezza nella modellazione degli oggetti e nella scrittura delle query. Similmente, l’intero processo di sviluppo delle API è iniziato lentamente e faticosamente. La confusione era molta: non era chiaro quali metodi permettere, quali risultati dare e come gestire gli errori. Solo lavorandoci più e più volte siamo riusciti a soddisfare i nostri obiettivi. Infine, le funzioni javascript client-side sono risultate più immediate e siamo riusciti a lavorare con maggiore facilità, dato il background generale del team. Nonostante questo, non ci siamo risparmiati molto tempo di debug. Forse ci siamo sopravvalutati dove sapevamo di più, e ci siamo sottovalutati di fronte alle nuove cose da imparare. Il nostro prodotto software, per essere il primo Sprint, è completo e ne siamo soddisfatti. Siamo comunque consapevoli dell’esistenza di alcune criticità e bug ancora presenti. Prevediamo di risolvere questi errori sparsi nel codice nei primi passi del prossimo Sprint.
Dal meeting, abbiamo deciso di procedere seguendo l’ordine crescente delle importance e abbiamo inizialmente discusso e infine concordato nell’assegnazione degli story points a ciascuna task. Successivamente, però, ci siamo dovuti ricredere e modificare alcuni story points, in particolare quelli relativi alle prime user stories sono stati incrementati. Nel corso di questo Sprint, ci siamo anche resi conto che il product backlog precedente non rispecchia correttamente la nostra percezione del prodotto software: man mano che le funzioni venivano implementate e testate, ci siamo chiesti quale sarebbe stato il naturale prossimo step. La risposta a questa domanda non sempre era ben riflessa dalla scala delle importance del backlog precedente. Abbiamo quindi modificato alcune importance, per adattarle alla nostra maturata idea della WebApp.
Dall’ultimo meeting, emerge la generale soddisfazione del nostro lavoro di squadra. Nonostante abbiamo avuto poche occasioni di collaborare in presenza, abbiamo recuperato con la piattaforma online Discord. Siamo sempre riusciti a proporre le nostre idee, confrontarle e risolvere eventuali disaccordi e perplessità. Siamo riusciti a implementare le funzionalità che ci eravamo prefissati. Ci siamo sottovalutati, infatti siamo riusciti ad implementarne altre. Abbiamo quindi modificato le funzionalità previste nel prossimo Sprint. Nel prossimo sprint terremo conto della nostra nuovamente stimata capacità produttiva. Ognuno di noi ha ampliato le proprie conoscenze in Javascript e abbiamo anche avuto modo di imparare cose nuove, ovvero l’utilizzo di nuovi strumenti per lo sviluppo software di cui ora non possiamo più fare a meno. Ci riteniamo compiaciuti in particolare della divisione dei compiti: siamo riusciti a lavorare in parallelo su diversi task, per poi unire i diversi artefatti in un prodotto finale complessivamente soddisfacente.