DAY 4

CRONACA DI PROGETTO 

DAY 4

A cosa ci server?

Ogni viaggio giunge ad una conclusione, e se non lo fa siano beati o dannati i passeggeri. Il nostro termina oggi.

Entriamo nell'ufficio dopo un rapido caffè e come sempre ad aspettarci troviamo il nostro Virgilio del mondo informatico, Antonio Pintus. Finora siamo riusciti a connettere due Arduino attraverso dei server di prova già realizzati e pronti all'uso, ma l'ultimo giorno è sempre quello speciale.

L'obbiettivo di oggi è capire i principi che stanno alla base di un'applicazione server e successivamente di realizzarne una vera e propria per i nostri ipotetici usi nell'ambito IoT. Sappiamo però che molti dei nostri lettori, come noi, non sono certamente dei guru dell'informatica e perciò proveremo a spiegarvi a grandi linee quello di cui stiamo parlando.

Quando parliamo di applicazione server ci stiamo riferendo a un vero e proprio programma scritto e caricato su una macchina (PC, Arduino o server che sia) che sia in grado di accettare e rispondere a richieste che gli vengono fatte da un altro dispositivo. Nel nostro percorso del DAY 2 e del DAY 3 abbiamo già visto le richieste di tipo GET e POST, e sarà su queste che lavoreremo per lo più. L'intento è quello di realizzare un applicazione server a cui inviare dei dati rilevati da un sensore e che sia in grado di cederli sotto richiesta di un attuatore in modo da completare l'analisi delle parti dei sistemi IoT. Il nostro server non sarà certo al pari di quelli di google ma per i nostri scopi ci accontentiamo con molto piacere. 

Lavorare per la programmazione di alcuni piccoli server, sia locali che remoti, potrebbe rivelarsi un impresa più che ardua per quattro studenti che mai prima d'ora si erano cimentati in queste imprese ma per fortuna abbiamo la compagnia del nostro tutor che tanto basta ad addolcire le fredde linee di codice che ci si presentano davanti passo dopo passo.  Per realizzare i nostri scopi decidiamo di utilizzare come framework node.js. Una sorta di esecutore del linguaggio JavaScript che ci permette di realizzare applicazioni web anche di una certa complessità.

La sintassi di node.js è semplificata a tal punto che con sole quattro righe di testo è possibile creare un sever locale e, con qualche passo in più, anche uno in remoto. Il primo server che creiamo è elementare. Lo impostiamo per rispondere alle richieste GET con il messaggio "ecco la risorsa" e a quelle POST con un HTTP 201 dopo aver stampato sullo schermo il contenuto della richiesta del client.

Come ogni festa barbecue che si rispetti non ci limitiamo solo agli affettati ma decidiamo di mettere altra carne al fuoco e oltre alle due funzioni elementare di GET e POST e creiamo all'interno del server delle API che ipoteticamente ci permetterebbero di raccogliere i dati rilevati dai nostri sensori in una posizione specifica come ad esempio in un database. Nell'immagine sottostante è possibile distinguere le varie API create grazie al " / " che precede i loro nomi. 

Per verificare il tutto facciamo un tentativo di richiesta GET al server creato e grazie a un particolare terminale verifichiamo che il nostro sistema abbia ricevuto la richiesta. La conferma arriva dal codice a tre cifre di cui abbiamo parlato nel DAY 2 "304" che tradotto in linguaggio umano significa "not modified", ovvero, "Richiesta andata bene, la risorsa che hai chiesto è identica a com'era l'ultima volta che l'hai chiesta". 

La nostra esperienza si conclude qui, tra le righe di codice, gli Arduino i saluti e la consapevolezza di essere entrati in contatto con qualcosa di cui spesso ci si dimentica nell'uso quotidiano della tecnologia, quello che c'è dietro la tecnologia stessa.

Un grazie ad Antonio Pintus, alla coordinatrice di progetto Carol Salis e a tutto il CRS4.