You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Riportiamo per completezza la conversazione avvenuta su telegram:
85
81
86
82
\begin{enumerate}
87
-
\item Siamo convinti di partire da una specifica dell'API utilizzando OpenAPI v3 + i tool Swagger.
88
-
Hai consigli per il framework Java da utilizzare? Stiamo guardando Quarkus e Spring Boot o Spring Data, ma non avendo esperienza facciamo fatica a valutare quale sia più adatto e/o semplice da utilizzare.
89
-
\item Secondo te è una scelta valida utilizzare i framework NativeScript/angular per riutilizzare codice tra l'applicazione mobile e la web app?
83
+
\item Secondo te è una scelta valida utilizzare i framework NativeScript/Angular per riutilizzare codice tra le applicazioni web e mobile?
84
+
\item Hai consigli per il framework Java da utilizzare? Stiamo guardando Quarkus e Spring Boot o Spring Data, ma non avendo esperienza facciamo fatica a valutare quale sia più adatto e/o semplice da utilizzare.
90
85
\end{enumerate}
91
86
92
-
A cui Davide Zanetti ha risposto:
87
+
A cui il proponente ha risposto:
93
88
94
89
\begin{enumerate}
95
-
\item Personalmente conosco bene spring boot e spring data (molto più diffusi negli ambienti dove lavoro), sono un po' più carente per quanto riguarda Quarkus (che comunque mi sembra interessante come framework).
96
-
Quindi, validi entrambi, sul primo posso aiutarvi più facilmente ed è abbastanza facile da usare, sul secondo non sono molto esperto ma se volete provarlo mi documento con voi.
97
90
\item Non sono molto pratico di questo ad essere onesto, provo ad informarmi con qualche collega più esperto e vedo di trovarvi una risposta sensata.
91
+
\item Personalmente conosco bene Spring Boot e Spring Data (molto più diffusi negli ambienti dove lavoro), sono un po' più carente per quanto riguarda Quarkus (che comunque mi sembra interessante come framework).
92
+
Quindi, validi entrambi, sul primo posso aiutarvi più facilmente ed è abbastanza facile da usare, sul secondo non sono molto esperto ma se volete provarlo mi documento con voi.
98
93
\end{enumerate}
99
94
100
95
% sec:conversazione_telegram (end)
101
96
97
+
\section{Tecnologie frontend}%
98
+
\label{sec:tecnologie_frontend}
99
+
100
+
Il proponente ci ha fatto presente che utilizzare NativeScript non è una soluzione particolarmente pulita perché in caso di difficoltà si deve ricadere sulla scrittura di classi in Java puro;
101
+
quindi il vantaggio di utilizzarlo probabilmente non vale il rischio di incontrare problemi difficilmente risolvibili più avanti nello sviluppo.
102
+
103
+
L'aspetto di riutilizzo del codice tra web/mobile è un bonus, ma l'applicazione che stiamo progettando è abbastanza contenuta quindi ha consigliato di fare tutto in Java.
104
+
105
+
Inoltre, integrare mappe nell'applicazione mobile (ad es.\ nelle schermate delle organizzazioni) dovrebbe essere semplice.
106
+
107
+
L'applicazione deve funzionare perlomeno su Android 9, ma comunque faremo riferimento alla \href{https://developer.android.com/distribute/best-practices/develop/target-sdk}{guida ufficiale}
108
+
109
+
\subsection{Geofences}%
110
+
\label{sub:geofences}
111
+
112
+
Il proponente ha confermato la validità della nostra idea di utilizzare le geofences come confine esterno centrato sui luoghi delle organizzazioni.
113
+
In particolare, le potremmo utilizzare per garantire che un utente è uscito da un luogo (il proponente ha usato il termine ``rollback'').
114
+
115
+
Inoltre, possiamo farci affidamento per diminuire il consumo energetico dell'applicazione quando gli utenti sono lontani dalle organizzazioni.
116
+
117
+
% sec:tecnologie_frontend (end)
118
+
119
+
\subsection{Applicazione web}%
120
+
\label{sub:applicazione_web}
121
+
122
+
A prescindere dalle tecnologie utilizzate per l'applicazione mobile, usiamo il framework Angular per l'applicazione web.
123
+
124
+
Il proponente ci ha consigliato \href{https://www.selenium.dev/}{Selenium} per testarne gli aspetti grafici.
125
+
126
+
% sub:applicazione_web (end)
127
+
102
128
\section{Tecnologie backend}%
103
129
\label{sec:tecnologie_lato_server}
104
130
105
-
\placeholder{\dots}
131
+
Spring Boot è estremamente diffuso e ha un ecosistema molto grande, quindi è probabilmente utile per noi imparare a utilizzarlo.
106
132
107
-
% sec:tecnologie_lato_server (end)
133
+
Il proponente ha menzionato il modulo \href{https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html}{WebFlux} che permette di utilizzare il paradigma del Reactive Programming.
108
134
109
-
\section{Tecnologie frontend}%
110
-
\label{sec:tecnologie_frontend}
135
+
Per quanto riguarda le funzionalità LDAP, Davide ha detto che possiamo utilizzare Spring LDAP (una libreria del framework), ma che molto probabilmente è sufficiente utilizzare un'API RESTful.
136
+
Ha menzionato in particolare la \href{https://directory.fedoraproject.org/docs/389ds/design/ldap-rest-api.html}{389 Directory Server RESTful API}
111
137
112
-
% sec:tecnologie_frontend (end)
138
+
\subsection{Progettazione API}%
139
+
\label{sub:progettazione_api}
113
140
114
-
\placeholder{\dots}
141
+
Il proponente ci ha consigliato di guardare la risorsa \href{https://opensource.zalando.com/restful-api-guidelines/}{Zalando RESTful API and Event Scheme Guidelines}.
115
142
116
-
\section{Accesso a server di Imola Informatica}%
117
-
\label{sec:accesso_a_server_di_imola_informatica}
143
+
Inoltre ha detto che non consiglia di utilizzare gli strumenti di generazione automatica del codice di Swagger, perché la qualità del codice generato è molto bassa.
118
144
119
-
\placeholder{\dots}
145
+
% sub:progettazione_api (end)
146
+
\subsection{Containerization}%
147
+
\label{sub:containerization}
120
148
121
-
% sec:accesso_a_server_di_imola_informatica (end)
149
+
Il proponente ci ha consigliato di concentrarci prima sull'aspetto di ``containerizzazione'' attraverso Docker, perché se viene fatto bene rende molto semplice agganciare a posteriori i pod di Kubernetes per la gestione e scalabilità dell'applicativo.
150
+
151
+
Si è anche raccomandato di fare molto affidamento sulle immagini ufficiali di software disponibili su Docker Hub (come ad es.\ i database SQL), perché semplificano enormemente la configurazione dei servizi.
122
152
123
-
\section{Metriche di qualità di prodotto}%
124
-
\label{sec:metriche_di_qualita_di_prodotto}
153
+
% sub:containerization (end)
125
154
126
-
\placeholder{\dots}
155
+
% sec:tecnologie_lato_server (end)
127
156
128
-
% sec:metriche_di_qualità_di_prodotto (end)
157
+
\section{Accesso a server di Imola Informatica}%
158
+
\label{sec:accesso_a_server_di_imola_informatica}
159
+
160
+
Nei prossimi giorni entreremo in contatto via email con un tecnico di Imola Informatica che ci creerà un'utenza sulle macchine del loro laboratorio.
161
+
162
+
Il proponente ci ha fatto presente che non dobbiamo salvare dati persistenti sul loro server, perché spesso le macchine vengono resettate.
163
+
164
+
% sec:accesso_a_server_di_imola_informatica (end)
129
165
130
166
\newpage
131
167
\section{Registro delle decisioni}%
132
168
\label{sec:registro_delle_decisioni}
133
169
134
170
\begin{enumerate}
135
-
\item\placeholder{\dots}
171
+
\item Usare Spring Boot + Spring LDAP per il backend.
172
+
\item Progettare prima l'API in maniera da avere un approccio \textit{Contract First}.
173
+
\item Usare MariaDB per i dati più persistenti.
174
+
\item Usare InfluxDB per le serie temporali (in part.\ presenza/assenza degli utenti nei luoghi).
175
+
\item Posticipare la decisione sulle tecnologie frontend a dopo la finalizzazione dell'API\@.
0 commit comments