Aggiunte note sulla conferenza

notes/conferenza azienda.md

@@ -0,0 +1,22 @@
+7. I materiali richiesti dall'azienda vanno consegnati prima dello sviluppo, anche dopo le richieste del professore, l'importante è che sia prima di iniziare a lavorare sul software in modo da non rimettere mano al software.
+7a. Le configurazioni dei device vanno in un database relazionale standard, mentre il time series db ha caratteristiche particolari: si può usare db verticale, l'ER è superfluo per il series db, i dispositivi possono dare errori tipo warning in modo da far capire che il dispositivo non sta funzionando, e allora non inserire come misurazione. Se non ricevo informazioni ci sarà una tabella di fermi che indica perchè il dispositivo non sta funzionando, altrimenti il servizio è giù. La tabella dei fermi serve per colmare i vuoti per sapere se l sistema sta funzionando o meno.
+7b. Documentazione API da non perdere troppo tempo, la forma deve essere costante omogenea in tutte le documentazioni, ovvero stessa lingua, no mezzo e mezzo.
+
+8a. i gateway sono pezzi di software che viene installato nelle varie reti dove sono presenti i vari dispositivi, ogni sede ha il suo gateway in modo che ogni gateway sia connesso direttamente con i dispositivi perchè essi potrebbero essere all'interno di reti private. Il gateway è un traduttore fa falling verso i vari dispositivi, il gateway all'installazione sa solo a che topic di kafka connettersi, poi conoscerà i dispositivi a cui collegarsi, che valori prendere, il gateway tramite il suo protocollo ogni tanto fa la chiamata ai devices in base alla configurazione. Creare piccoli pezzi di software che espone degli xml in modo da fare delle prove. 
+Il gateway resta come consumer di un topic di kafka, quando riceve una nuova configurazione (non lavorare sui delta) rimandare sempre tutta la configurazione, non solo aggiunto o rimosso device. 
+Qualora si dovesse rimandare la configurazione per l'aggiunta di nuovi dispositivi, cosa succede per l'ente/amministratore? Il configuratore del sistema tecnico/amministratore sa dove sa sono i dispositivi (ip esempio), configura il sistema, all'ente è collegato uno o più valori letti, non l'intero dispositivo.
+L'utente riceve solo i dati che gli servono, quindi teoricamente non se li seleziona.
+8b. La traduzione da binario a json non è compito nostro, noi riceviamo json da gateway. Raggruppiamo i dati in un formato a nostra scelta (json preferibile). Kafka mette a disposizione un modo per impostare il formato del pacchetto in modo che kafka riesca già a tradurlo in json. KSQL per estrapolare i dati. Trasformazione dei dati a livello di connect prima di scrivere i dati su db. Riceviamo i dati da un singolo topic, poi verranno divisi a livello di stream o a livello di sink (scelta nostra). Usare container docker per fare tutti i test possibili.
+8c. Per inviare delle azioni ai device il configuratore conosce i device, al censimento del device al sistema ci possono essere altri dati oltre a quelli di lettura con una flag tipo scrittura, il gateway interpreta che quel device ha certe prioprietà e per eseguire qualche azione viene settata la flag a scrittura e si setta il valore che si vuole dare. Dobbiamo creare un protocollo per interfacciarci con i devices.
+
+9e. Non implementare le autenticazioni, sicurezza ma anche solo nominarle come proposte.
+Per le password minimo numero di caratteri, non necessariamente 8 caratteri, anche meno, nessun limite ai caratteri (non è necessario che ci siano dei caratteri specifici come punti speciali, numeri, ecc...) o altri sistemi di autenticazione tipo 2 fattori
+9f. Ben accetta la visualizzazione dei grafici
+9g. Ben accetto il merge dei grafici
+A livello di smartphone non è necessaria la configurazione dei device, non è vincolante, mentre sì da tablet e da pc. Visualizzazione grafici parte responsive sì.
+
+10. Il nome utente è stato implementato dopo, quindi per semplificare si crea il link che deve essere aperto con telegram per passare dei parametri (id risorsa per identificare chi è in modo che allo start del bot si identifica) in modo da autenticarsi. Altra soluzione possibile all'entrata della chat venga inviato il biglietto da visita, ovvero l'account della risorsa. A nostra scelta la soluzione più comoda, in modo che 2 omonimi vadano in conflitto o si scambino. Bot di telegram fattibile in php. Java supportata da più tempo. Container docker: node o micro servizio che consumi il meno possibile allora GO.
+
+Tema bootstrap accettato: admin lte, quello che vogliamo open source. Basta non pensarci troppo
+
+11. L'invio dei comandi basta che ci sia, non necessariamente entrambi.