3.2.0.0.1 Organizzazione:

A inizio progetto sono stati stilati insieme i primi requisiti di business e funzionali, sono state delineate le prime user stories, ragionando sui problemi che avrebbe dovuto affrontare tale tipologia di lavoro. Si è deciso di suddividere il lavoro in Sprint, ognuno con durata teorica di una settimana. Ad ogni Sprint corrispondevano diverse attività, anche chiamate issue. Tale tempistica, come accennato sopra, poi non è sempre stata rispettata. Spesso si sono riscontrati problemi durante lo svolgimento di un task e i tempi si sono allungati.
All’interno del team Daniele Tentoni è stato sicuramente colui che ha svolto il ruolo dello Scrum Master oltre a far parte del gruppo di sviluppo: egli ha guidato il team per facilitare lo sviluppo di software funzionante, assicurando anche la corretta applicazione dei processi scrum.
Lo Sprint con le varie attività da svolgere veniva stilato solitamente durante gli incontri, e le decisioni su cosa fare venivano prese collegialmente. Il Product Backlog è stato quindi fatto insieme.
Si è proceduto in questo modo: si è iniziato a produrre la parte Server e, una volta sviluppate le principali funzionalità di quest’ultimo con i relativi test, si è poi passati a curare la parte client e la parte grafica. Nel frattempo si è anche iniziata a collegare la parte backend con quella frontend.
Ognuno era delegato al testing e agli User Acceptance Test sulla propria parte di codice prodotta,i test sono interni al progetto.

3.2.0.0.2 Gantt Chart:

A partire da inizio progetto si è stilato un diagramma di Gantt, uno strumento utile per la pianificazione dei progetti. Il diagramma ha aiutato a mantenere la costanza e un ritmo nel progetto molto più serrato. Nel capitolo relativo agli sprint, in [Fig. 10.1] si riporta il diagramma di Gantt risultante.

3.2.0.0.3 Licensing:

Per quanto riguarda la gestione delle licenze, è stato scelta, tra le varie disponibili, la licenza GNU General Public Service. E’ una licenza copyleft, ovvero un tipo di licenza che viene applicata ai software open source. Il programma può essere quindi distribuito liberamente, modificato e migliorato, con la clausola di non cambiare licenza. Questo tuttavia impone a tutti i software derivati di mantenere il codice opensource, anche in caso di commercializzazione a pagamento. Nonostante alcune aziende non possano usare il codice qualora volessero incorporarlo in prodotti in cui il codice non è pubblico, consciamente è stata fatta questa scelta per supportare l’opensource. Per referenze è possibile consultare un riassunto dello spettro delle licenze a questo link.

3.2.0.0.4 Versioning:

Per il versioning ci si è avvalsi di Git e come piattaforma web di GitHub che incorpora le funzionalità di controllo di versione di Git.

3.2.0.0.5 Github Issues and Project Boards:

Per organizzare il lavoro, elencare i problemi riscontrati ed assegnare i tasks sono state utilizzate le Github Issues dove è possibile pianificare e tenere traccia del proprio operato aggiungendo varie issue al progetto, ognuna corrispondente a un task. Ad ogni issue è possibile aggiungere vari elementi, labels e l’assegnatario. In minor misura sono state usate le GitHub Projects boards. Esse aiutano a organizzare e prioritarizzare il lavoro. Si tratta di schede che contengono issues e note che vengono categorizzate in cards su colonne, ogni colonna indica lo stadio di avanzamento del compito.

3.2.0.0.6 Telegram:

E’ stato creato un gruppo Telegram per aggiornarsi giornalmente sullo sviluppo del progetto, esprimere eventuali dubbi e avere ulteriori chiarimenti.

3.2.0.0.7 Incontri:

Si è deciso di sentirsi una volta a settimana, per risolvere insieme alcuni task rimasti,aiutarsi nelle problematiche riscontrate durante lo sviluppo, fare il chiarimento della situazione. Eventualmente si stilava anche lo Sprint per la settimana successiva, se quello precedente era stato completato. Sono state alternate sedute sia in presenza che online, dove ci si è avvalsi della piattaforma Microsoft Teams.

3.3.1 Relazione di Progetto

La relazione è stata scritta su Overleaf, uno strumento di scrittura e pubblicazione collaborativo online. Inoltre il progetto Overleaf è stato sincronizzato su un apposito repository in Github, dove poter inserire le modifiche ogni volta. Il branch main ospita la release finale della relazione. Ad ogni modifica di tale branch vengono rilasciate le versioni pdf e web aggiornate della relazione.

3.3.2 Progetto

L’approccio GitFlow, che abbiamo seguito fedelmente, utilizza due rami principali per gestire il controllo di versione del progetto. Il primo, main che conserva tutte le release, è il centro del nostro progetto, perché rispecchia la versione pubblica attualmente in produzione, la versione cioè accessibile ai nostri utenti. Il secondo è il ramo dev, che è fondamentale per lo sviluppo delle prossime versioni e serve come base per le future integrazioni. Il dev è il punto di partenza e di arrivo di tutti gli altri branch.
Per lo sviluppo di ogni issue veniva creato un branch apposito. Al completamento il codice veniva compilato e testato, infine veniva fatta una pull request, dove veniva richiesta la review di almeno un componente del team per poter includere le proprie modifiche al progetto.
Periodicamente quindi veniva fatta una release sul branch main. Il codice sul branch dev veniva ritestato e anche i membri del team eseguivano gli opportuni User Acceptance test per verificare le varie funzionalità implementate. Il deploy finale del progetto per la produzione è stato fatto sull’ambiente Github Pages.

4.2.1 User stories

Di seguito sono riportate tutte le user stories formulate assieme agli utilizzatori

• Come utente voglio:

  • poter visualizzare le previsioni odierne per una località specifica o per la propria posizione attuale.

  • poter visualizzare le previsioni relative ai prossimi giorni per una località specifica o per la propria posizione attuale.

  • poter impostare la fiducia per ogni servizio usato e fornire un feedback, con la possibilità anche di eliminarlo.

  • specificare la località preferita di cui vedere le previsioni non appena viene visualizzata l’area riservata, oppure modificare o rimuovere quest’ultima.

  • aggiungere un device, registrandolo come centralina meteo a cui richiedere le previsioni con la possibilità di modificarlo o rimuoverlo.

  • ricevere notifiche ad una certa ora con le previsioni giornaliere sulla località preferita.

  • visualizzare le statistiche e indici di affidabilità di un provider in base ai feedback degli altri utenti.

4.3.1 Applicativo web

L’applicativo web deve consentire ad ogni utente di accedere con una serie di credenziali, e dividere le operazioni consentite in base ai permessi concessi. Il sito è suddiviso in pagine:

• Autenticazione: Pagina di login per effettuare l’accesso e pagina di registrazione per i nuovi utenti.

• Home: dove è possibile registrarsi, accedere, visualizzare le previsioni. E’ visibile da chiunque. Mostra brevemente, con l’aiuto di immagini, le funzionalità del sito.

• Profilo Privato: dove visualizzare e modificare le proprie informazioni o gestire i propri feedbacks e centraline. Solo il proprietario del profilo può accedere a questa pagina.

• Profilo Pubblico: serve per visualizzare le informazioni di un altro utente. E’ visibile da chiunque.

• Forecast dove vengono visualizzate le condizioni meteo correnti e le previsioni dei prossimi tre giorni. Queste possono essere sia aggregate che non. E’ visibile da chiunque.

• Feedbacks visualizza i feedbacks dei vari provider e i loro indici di affidabilità. E’ visibile da chiunque, ma si possono aggiungere feedbacks solo se registrati.

• About mostra informazioni sugli sviluppatori del progetto e sullo scopo dell’applicativo, con un modulo di contatto per chiedere informazioni o segnalare problemi agli admin.

4.5.1 Metodologie e Tecnologie Utilizzate

In quanto progetto sviluppato per l’esame di Applicazioni e Servizi Web è necessario che le tecnologie usate rispettino gli standard di insegnamento. Per tale motivo è stato richiesto di utilizzare un elenco di tecnologie viste a lezione. Esse sono Node.JS, MongoDB, Express.JS e un framework per lo sviluppo di applicazioni frontend tra Vue.JS, Angular o React.

5.3.1 Client-Server

Nella figura 5.2 è illustrato come avviene un flusso di richieste di previsioni meteo dal Client al Server.

Procedendo in ordine numerico, al punto 1., il Client invia una richiesta al Server contenente il nome della località di cui vuole sapere le coordinate. Il Server nei punti 2. e 3. prepara la richiesta da inviare ai vari provider di previsioni meteo. Nello specifico vengono preparate solamente altre due richieste per altrettanti providers, ma in un caso reale potrebbero essercene molte di più. Da notare come in questo punto avvenga una divisione del flusso computazionale principale in due flussi separati ed indipendenti. Nei punti 4. e 5. tali flussi eseguono autonomamente le richieste delle previsioni al provider meteo esterno a loro assegnato. Ricevuta la risposta nei punti 6. e 7., la inoltrano al Client nei punti 7. e 8..

6.1.1 Interfacce utente

In seguito ad un’analisi preliminare del problema sono stati prodotti dei mockup della grafica per dare l’idea delle funzioni e dei requisiti dell’applicativo. Le pagine effettive si sono evolute durante lo sviluppo ma mantengono le linee guida dei mockup. Vengono descritte le interfacce utente più importanti. Si consulti anche il capitolo 7.4 per visualizzare il risultato finale delle pagine.

La homepage è la pagina principale di presentazione. In bella vista presenta una card con una barra di testo dove inserire il nome della località con l’icona di una mappa per le coordinate geografiche, con due bottoni in basso per richiedere le previsioni. Attraverso i bottoni Login e Register inoltre si può accedere alle pagine di autenticazione.

Viene pensata una pagina di login classica con la possibilità di recuperare la password e una pagina di registrazione. Effettuata la registrazione viene chiesto agli utenti di completare la propria iscrizione cliccando sul link dell’email di conferma.

Il fulcro dell’applicazione è sicuramente la pagina delle previsioni. Inizialmente la pagina visualizza un’immagine esplicativa con in alto una barra di testo dove inserire la località oppure richiedere le coordinate geografiche attuali attraverso l’icona della mappa. Cliccando sui due pulsanti a lato si può richiedere il meteo attuale o quello dei prossimi tre giorni. Comparirà così in posizione centrale la card della previsione aggregata e in basso un insieme di schede che rappresentano le previsioni di ogni provider, con informazioni utili sul meteo. Nel caso siano richieste le previsioni dei prossimi tre giorni, la pagina si aggiornerà mettendo a disposizione un tooltip di bottoni per scegliere il giorno specifico e uno slider per scegliere l’ora della previsione.

Nella pagina delle recensioni è possibile visualizzare uno slider che contiene le schede con le recensioni relative ai vari provider. Tramite la barra di ricerca in alto è possibile trovare quello desiderato digitandone parte del nome. Ogni scheda contiene una lista di recensioni lasciate dagli utenti. Per ogni recensione viene mostrato l’avatar dell’utente che l’ha rilasciata, con a lato la sua valutazione. Questa è stata espressa graficamente da una a cinque stelle. Cliccando sul campo è possibile visualizzare il profilo pubblico dell’utente associato.

All’estremità di ogni scheda, se si è autenticati, sarà presente il pulsante per aggiungere una nuova recensione. Se si clicca su di esso si visualizzerà una finestra con il rating da inserire. Questa è espandibile: si possono anche specificare il campo della previsione che si vuole recensire (ad esempio temperatura minima, Pressione, etc), la data della previsione alla quale ci si riferisce, e eventuali note. In cima ad ogni card si è deciso di far visualizzare una statistica, calcolata come media dei rating di quel provider. Si tratta di un indice di affidabilità che calcola l’accuratezza della previsione, basandosi sull’opinione delle altre persone.

La pagina del profilo privato dà la possibilità ad ogni utente di visualizzare e gestire le proprie informazioni personali. Cliccando su "edit" si aprirà un dialog che consentirà di poter modificare la propria password o la propria posizione preferita. L’utente ha la possibilità di visualizzare le proprie centraline, di aggiungerle tramite il pulsante "+" in alto della tabella, modificarle e eventualmente cancellarle (ne verrà richiesta la conferma). L’utente ha la possibilità di visualizzare le proprie recensioni e eventualmente cancellarle (ne verrà richiesta la conferma). Navigando in questa pagina c’è anche la possibilità di cancellare il proprio account tramite un bottone apposito in fondo alla pagina.

La pagina del Profilo pubblico ha la stessa struttura del Profilo privato, ma qui nessuna operazione di modifica è concessa.

Infine una pagina per i contatti che consente l’inserimento di un messaggio/ticket per il supporto tecnico e alcune informazioni sul team di sviluppo.

6.1.2 Componenti

Si descrivono in breve i componenti principali usati per ogni pagina. Prima di tutto si elencano i componenti presenti in tutte le pagine:

• Appbar: E’ una barra colorata situata nella zona alta della pagina. Contiene tre componenti:

  • Icona Utente: Situata nell’estremità destra, permette di autenticarsi o registrarsi al sito se l’utente non ha eseguito l’accesso, altrimenti esso può visualizzare la propria pagina del profilo privato o effettuare il logout. Il suo aspetto cambia: se è autenticato mostra le iniziali del proprio nome e cognome, altrimenti mostra un’icona generica.

  • Titolo Weather Vortex: Situata nella parte centrale, permette di navigare alla home cliccando su di esso.

  • Icona Menù: Situata nell’estremità sinistra, consente di mostrare o nascondere la barra di navigazione (Navbar).

• Navbar: Si tratta della barra di navigazione attraverso cui l’utente può muoversi nelle principali finestre del sito.

• Footer: Il footer a fine pagina contenente dei link utili.

La pagina Home è composta dai principali componenti:

• QuickForecastCard: Card che viene usata come scorciatoia per visualizzare le previsioni.

• AccountButtons: Contiene i bottoni per accedere alle pagine di autenticazione.

• InfoMain: Insieme di cards di descrizione

• checkStatus: Card che mostra lo stato del server.

La pagina Feedbacks è composta dai seguenti componenti:

• SlidesOrizontalGroup: Si tratta dello slider che contiene le schede dei vari provider con le recensioni. E’ composto da due sottocomponenti:

  • ServiceRatingList: Rappresenta la lista delle recensioni del provider. Ogni campo recensione è composto dall’avatar dell’utente, dalle sue iniziali e dalla sua recensione.

  • FeedbackDialog: Rappresenta il dialog per l’aggiunta della recensione.

La pagina Forecast è composta dai seguenti componenti:

• EmptyForecast: Mostra la pagina iniziale delle previsioni.

• CurrentForecast: Mostra la pagina del meteo attuale. E’ composta dal seguente sottocomponente:

  • ForecastGroup. Esso rappresenta l’insieme delle previsioni meteo. Richiama il componente WeatherForecastCard che rappresenta una singola previsione per uno specifico provider o il meteo aggregato. Esso contiene la descrizione del meteo, la data, la temperatura minima e massima, la pressione, l’umidità, la quantità di nuvole, di pioggia e di neve.

• ThreeDaysForecast: Mostra la pagina delle previsioni dei prossimi tre giorni. Richiama gli stessi componenti di "CurrentForecast".

La pagina Profilo Privato è composta dai seguenti componenti:

• PrivateUserCard: Si tratta della card che visualizza le informazioni private dell’utente: avatar, nome, cognome, data di creazione, email, posizione preferita e bottone di modifica.

• PrivateUserReviews: Tabella che visualizza le recensioni rilasciate. Contiene i relativi campi: provider, valutazione, commento e un pulsante per la cancellazione.

• PrivateUserControlUnits: Tabella che visualizza tutte le centraline inserite. E’ costituita dai seguenti campi: nome, posizione, url e due pulsanti per la modifica e la cancellazione.

La pagina Profilo Pubblico ha i seguenti sottocomponenti:

• PublicUserCard: Si tratta della card che visualizza le informazioni pubbliche dell’utente: avatar, nome, cognome, eventuale posizione preferita.

• PublicUserReviews: Tabella che mostra le recensioni lasciate dall’utente. Contiene i seguenti campi: provider, recensione, commento.

• PublicUserControlUnits: Tabella che visualizza tutte le centraline inserite dell’utente. E’ costituita dai seguenti campi: nome, posizione, url.

La pagina About è composta dai seguenti componenti:

• Timeline: Componente che visualizza cronologicamente gli vari stadi del progetto.

• MeetTeam: Un insieme di cards per descrivere gli autori del progetto.

• ContactUs: Componente che funge da modulo di contatto.

6.1.3 Vue-Router

Oltre ai componenti descritti sopra all’interno di ogni pagina un componente di Vue.js che è stato utilizzato è il vue-router, per il routing e la navigazione delle pagine. Esso consente, tramite una router-view, di visualizzare i componenti desiderati (che insieme compongono le varie interfacce utente).

6.2.1 Modelli

Ci sono cinque modelli che sono il fulcro dell’applicazione, essi si trovano nella cartella models. Essi costituiscono un modello di dati da salvare in MongoDB, che vengono usati per istanziare oggetti che saranno automaticamente dotati di metodi per svolgere le classiche operazioni CRUD.

• user - Rappresenta il modello dell’utente. I suoi campi sono:

  • firstName: nome dell’iscritto.

  • lastName: cognome dell’iscritto.

  • password: password dell’iscritto.

  • email: email dell’iscritto.

  • token: stringa generata durante il login per verificare l’autenticazione dell’utente.

  • creationDate: data di creazione dell’account.

  • emailToken: token per verificare l’iscrizione.

  • resetLink: token per il cambio della password.

  • isVerified: booleano che indica se l’utente è stato verificato.

  • preferred: una eventuale località preferita.

  • stations: elenco delle centraline dell’utente.

  • feedbacks: elenco delle recensioni dell’utente.

• feedback - Rappresenta il modello della recensione. I suoi campi sono:

  • rating: valutazione della recensione.

  • provider: il provider a cui la recensione si riferisce.

  • user: utente che ha rilasciato la recensione.

  • creationData: data di creazione della recensione.

  • forecastData: data della previsione su cui si è basata la valutazione della recensione.

  • fields: eventuali campi della previsione da valutare.

  • description: eventuale descrizione.

• location - Rappresenta il modello della località. I suoi campi sono:

  • name: nome della località.

  • position: posizione della località espressa in coordinate geografiche tramite latitudine e longitudine.

  Serve per memorizzare le richieste di previsioni che sono state fatte.

• provider - Rappresenta il modello del provider che fornisce il meteo. I suoi campi sono:

  • name: nome del provider.

  • average: la media di tutte le valutazioni date al provider.

  • feedbacks: lista di tutte le recensioni del provider date dagli utenti.

• station - Rappresenta il modello della centralina. I suoi campi sono:

  • authKey: valore usato per autenticare richieste alla stazione.

  • name: nome della centralina.

  • owner: proprietario della centralina.

  • position: nome della località in cui si trova.

  • url: url della centralina.

6.2.2 Storage

Gli storage sono dei componenti che si occupano di manipolare i dati e i modelli dell’applicazione nascondendo il supporto di memorizzazione degli stessi.

• database storage - storage che usa come supporto di memorizzazione il database.

• webservice storage - storage che richiede i dati ad un web service esterno. Nella nostro caso si tratta di gestire le richieste da provider esterni e recuperarne le previsioni.

6.2.3 Controllers

I Controllers contengono la logica applicativa e si occupano di fornire i dati estratti dagli Storage agli utenti. Tra i compiti svolti rientrano l’invio di email e le risposte alle chiamate HTTP dei clients.

6.2.4 Routes

Le Routes si occupano di prendere in carico le chiamate HTTP in entrata e inoltrarle ai giusti Controllers. Anche le richieste che arrivano dalle Sockets per gestire le previsioni del meteo vengono smistate da questi componenti.

7.1.1 Forecast e Socket.IO

All’avvio del Server, viene subito richiamata la funzione di Sockets.IO per rimanere in ascolto di nuove connessioni da parte delle sockets dei clients per richiedere le previsioni meteo:

io.on("connection", (socket) => {
  socket.on("current", (arg) => {
    if (arg.locality) {
      // Retrieve forecasts by locality.
    } else if (arg.latitude && arg.longitude) {
      // Retrieve forecasts by geolocation position.
    });
    
  socket.on("threedays", (arg) => {
    // Same as before.
  });
});

In seguito, quando i risultati delle richieste di previsioni meteo ai servizi esterni sono pronti, vengono immediatamente inoltrati ai clients tramite gli eventi delle sockets:

openWeatherStorage
  .currentByLocation(latitude, longitude)
  .then((result) => {
    socket.emit("result", ...);
  })
  .catch((error) => {
    socket.emit("forecast_error", ...);
  });
  
troposphereStorage
  .currentByLocation(latitude, longitude)
  .then((result) => {
    socket.emit("result", ...);
  })
  .catch((error) => {
    socket.emit("forecast_error", ... );
  });

7.1.2 Autenticazione

// generate token when user log in
userSchema.methods.generateToken = function (cb) {
  var user = this;
  var token = jwt.sign({ _id: user._id }, process.env.SECRET);
  user.token = token;
  user.save(function (err, user) {
    if (err) return cb(err);
    cb(null, user);
  });
};

// find by token
userSchema.statics.findByToken = function (token, cb) {
  var user = this;
  jwt.verify(token, process.env.SECRET, function (err, decode) {
    user.findOne({ _id: decode, token: token },
      function (err, user) {
        if (err) return cb(err);
        cb(null, user);
      }
    );
  });
};

//delete token, when the user logout
userSchema.methods.deleteToken = function (token, cb) {
  var user = this;

  user.update({ $unset: { token: 1 } },
    function (err, user) {
      if (err) return cb(err);
      cb(null, user);
    }
  );
};

let auth = (req, res, next) => {
  let token = req.cookies.auth;
  if (!token) {
    // Response the missing token result.
    return res.status(401).json({
      error: "Missing auth token in the request.",
    });
  }

  User.findByToken(token, (err, user) => {
    if (err) throw err;
    if (!user)
      // Notify the unauthorized access.
      return res.status(403).json({
        error: "Didn't found any user matching the auth token provided.",
      });

    // Use the found data in next handler.
    req.token = token;
    req.user = user;
    next();
  });
};

userSchema.pre("save", function (next) {
  var user = this;
  if (user.isModified("password")) {
    bcrypt.genSalt(salt, function (err, salt) {
      if (err) return next(err);
      bcrypt.hash(user.password, salt, function (err, hash) {
        if (err) return next(err);
        user.password = hash;
        next();
      });
    });
  } else {
    next();
  }
});

userSchema.methods.comparePassword = function (password, cb) {
  // Compare the user password when user tries to login
  bcrypt.compare(password, this.password, function (err, isMatch) {
    if (err) return cb(next);
    cb(null, isMatch);
  });
};

8.1.1 Backend

Il backend utilizza il testing stack Mocha + Chai + Sinon.

Mocha è il testing framework ricco e semplice che consente di creare facilmente degli unit test eloquenti. Chai è la libreria di assertions BDD/TDD che consente di creare le asserzioni multi-paradigma per i test. Tali asserzioni rendono i test più leggibili e forniscono messaggi di errore migliori.

Sinon è la libreria per creare e gestire i test spies, stubs e mocks da utilizzare nei test. Nel nostro caso è stato utilizzato soltanto per simulare l’invio delle email.

Durante lo sviluppo del backend è stata adoperata una collection Postman per testare tutte le varie chiamate al server anche in assenza dell’applicativo client definitivo, in attesa di sviluppo.

9.1.1 Problematiche riscontrate

Tuttavia, successivamente ci siamo accorti che l’ambiente Pages non ci permetteva di supportare anche l’uso dei cookie con il parametro HTTP only valorizzato a True perché il dominio github.io è elencato in una reserved list e i browser non permettono di salvare cookies di quel tipo in questi domini a meno che non provengano dal dominio stesso. Questa configurazione quindi si è dimostrata inadeguata ai fini del progetto, dato che il dominio dal quale sarebbero arrivati i cookies di autenticazione corrisponde ad un altro (https://weather-vortex-server.herokuapp.com/). Abbiamo dovuto quindi trovare un’altra modalità che non richiedesse di stravolgere l’architettura del nostro sistema senza rinunciare alla sicurezza.

Data la presenza in tutti i repository dei file Dockerfile per la creazione delle immagini Docker e l’esecuzione in containers come visto a lezione, abbiamo pensato di sfruttare tali funzionalità con l’aggiunta dell’applicativo Docker Compose per la dimostrazione in sede d’esame.

10.1.1 Svolgimento

Gli sprint sono stati portati avanti nel seguente modo:

10.1.2 Sprint 0

All’interno dello sprint 0 il focus è stato posto sull’apprendimento delle tecnologie scelte più dal punto di vista tecnico. Inoltre è stato impostato l’ambiente di sviluppo, rendendolo condiviso e unificato. Infine sono state definite le operazioni chiave per le API REST, lo user data model e le procedure di user authentication, login e register.

10.1.3 Sprint 1

All’interno dello sprint 1 il focus è stato sulla creazione del client, con l’utilizzo di Vue per creare le pagine base di esso e alcuni componenti chiave.

10.1.4 Sprint 2

All’interno dello sprint 2 sono stati fatti cambiamenti e miglioramenti su più parti del sito. Arrivati a questo punto inoltre è stato necessario anche occuparsi di bug creati in precedenza. E’ stato aggiunto il deploy automatico su GH Pages. Nuovi campi centralina sono stati aggiunti. La geolocalizzaizone ora acquisisce la posizione corrente.

10.1.5 Sprint 3

All’interno dello sprint 3 il focus è stato sul creare i componenti principali rimanenti. La pagina dei feedback è stata modellata dal lato grafico. L’homepage è stata completata assieme alla pagina di autenticazione. Sono stati aggiunti per gli sviluppatori dei codici rappresentanti le varie condizioni meteo.

10.1.6 Sprint 4

All’interno dello sprint 4 il focus è stato nuovamente sulla correzione di errori e bug. Le routes sono state inoltre rifattorizzate. Sono stati aggiunti gli alert per rendere più intuitiva la navigazione del sito.

10.1.7 Sprint 5

All’interno dello sprint 5 la mole di lavoro è stata notevole, essendo lo sprint finale. I feedback degli utenti sono stati recuperati dal DB e mostrati. La route per la password dimenticata è stata completata. Inoltre sono state implementate le previsioni meteo dalle stazioni. La funzionalità dell’aggregazione delle previsioni è stata definita.

11.1.1 Daniele Tentoni

Questo progetto mi ha sin da subito motivato moltissimo nel lavorare data la sua natura intrinseca e l’oggetto del sistema da sviluppare. Essendo scout, ho spesso provato un certo astio nei confronti dei differenti providers di previsioni che non si riescono mai a mettere d’accordo e, più ne vengono consultati, più le idee diventano confuse. Con questo progetto ho sperato di creare qualcosa che io possa usare anche in futuro e che possa essere conosciuto anche da altre persone.

L’inizio dello sviluppo, in estate, è andato bene e liscio per poi rallentare drasticamente nel momento in cui sono rincominciate le lezioni. Questo ha fatto calare la mia motivazione. L’uso di tecnologie che io già conoscevo per via del mio lavoro extra universitario e di progetti personali non ha certo aiutato a proseguire a passo spedito.

Penso tuttavia che questo progetto mi abbia aiutato ad avere una migliore visione di cosa voglia dire sviluppare dei sistemi applicativi web al giorno d’oggi, avendo utilizzato tecnologie che vengono tutti i giorni utilizzate da altri milioni di persone al mondo e che sono in costatnte sviluppo.

Il risultato finale del progetto secondo me è buono ma non ottimo. Avrei voluto avere più tempo per poter portare a termine tutte le funzionalità che avevamo avuto in mente, ma con il susseguirsi dello sviluppo, abbiamo notato che avevamo sovrastimato il carico complessivo.

11.1.2 Silvia Zandoli

Questo progetto mi ha dato la possibilità di approfondire le mie conoscenze riguardanti l’utilizzo di NodeJs, Express e MongoDb. Tutte le tecnologie che sono state usate erano per me completamente nuove, ma sono soddisfatta del mio apprendimento. Ho anche compreso come con Vue si riescono a realizzare velocemente e in modo non troppo complesso degli applicativi molto interessanti ed user-friendly.

Un aspetto importante, non tanto riguardante l’ambito dello Sviluppo Web, che ho potuto imparare è l’importanza dell’organizzazione: collaborare in questo team mi ha incentivato ad organizzare il lavoro, e questo mi ha insegnato un modo migliore di lavorare. A inizio progetto eravamo partiti con in mente qualche funzionalità in più. Poi per una questione di tempi, un membro ha avuto qualche difficoltà in più, non sono stati realizzati. Sono comunque soddisfatta del progetto svolto e lo ritengo un’idea innovativa, magari da approfondire in futuro.

11.1.3 Igor Lirussi

Al termine del percorso di sviluppo del progetto ritengo di aver acquisito una discreta moltitudine di nuove conoscenze. Sono state impiegate e integrate diverse tecnologie e metodologie anche complesse con cui sono state affinate parecchio le mie competenze nell’ambito. Sicuramente c’è ancora spazio per approfondire molti argomenti, ma nel complesso reputo sia servito a formare una base di conoscenza a tutto tondo. Il lavoro di gruppo ha permesso, infatti, di scambiarci nozioni a vicenda e ne sono più che contento, seppur mi rincresce non essere stato presente a volte come avrei voluto. Molte tecnologie usate sono state per me una scoperte in-itinere, in quanto completamente nuove. Ritengo comunque il progetto sia stato particolarmente ambizioso e il risultato ottenuto a mio parere è più che soddisfacente. Infine, spero questo lavoro possa rappresentare una buona base di partenza per un eventuale sviluppo futuro.