53:37 Che ne pensate del software Bruno? Può essere un sostituto di OpenAPI e semplificare la vita di sviluppatori BE è FE? Soprattutto per il testing del BE.
Grazie per avermi ricordato l'esistenza di Bruno! È sicuramente un'alternativa valida a Postman. La funzionalità chiave è l'export della documentazione nel formato Swagger/OpenAPI.
@@zedrcom Postman è un servizio in cloud a pagamento (se non per team di max 3 persone), esterno al progetto, accessibile solo online e tramite account. Bruno permette di tenere nel repository la knowledge di come chiamare delle REST Api, a costo zero. Elimina la necessità di dover condividere con il team l'accesso alla collection. Ce l'hanno di default. Permette di poter vedere facilmente delle diff, dato che i file .bru sono human readable. Non necessita di account per accedere a quei dati. Bruno dovrebbe essere la prima scelta, a meno di particolari use case (quali? Io fin'ora non è ho individuato).
40:44 non mi è chiaro il concetto di entrypoint per risolvere il problema espresso. Cosa dovrebbe rispondere questa API principale, per evitare che il client conosca la struttura della chiamata di dettaglio?
Ciao Giovanni. Il problema è il seguente: voglio evitare di tenere sincronizzato il codice del client ogni volta che l'API viene cambiata. Una API REST è in grado di descrivere pienamente tutte le transizioni possibili al client. Quest'ultimo deve cominciare la sua sessione interattiva da un punto noto, ovvero l'entry point o root resource dell'API. Dopodiché, il client può seguire gli hyperlink e, mediante le transizioni del suo stato tra una risorsa e l'altra, assolvere il suo compito, il concetto chiave del vincolo HATEOAS. Per questo è importante implementare un'ontologia coerente per la propria API. Un client di un'API REST deve conoscere a priori solo dove si trova la risorsa root. Tutto il resto lo impara dialogando con l'API.
@@zedrcom Ok, grazie, approfondiró. Mi è chiaro il concetto, ma non saprei come realizzarlo in pratica. Non capisco come i flussi di una operazione si possano esprimere in un entrypoint. Tornando all'esempio esposto, ovvero ottenere il dettaglio di un prodotto. L'entrypoint immagino che fornirà l'elenco di tutti gli endpoint che quel servizio espone. Nel nostro caso, indicherà al client che esiste l'endpoint per la lista dei prodotti e quello per il dettaglio. Come fa il client a sapere che deve chiamare prima la lista (per ottenere l'ID) e poi il dettaglio (e non il contrario)? - Parte individuando le info per chiamare il dettaglio, che indicano di chiamare prima la lista e quale parametro estrarre per chiamare il dettaglio? Oppure, più semplicemente: - le 2 chiamate sono indipendenti e il client fa il parsing della response dell'entrypoint e recupera l'uri del dettaglio tramite una chiave, che poi userà nella chiamata di dettaglio? Quindi, i flussi restano definiti sul client?
Ciao Giovanni - se vuoi vedere un esempio di entrypoint prova con api.github.com in un browser, in pratica restituisce un indice degli endpoint. - HATEOAS è solo un vincolo non uno standard quindi ci possono essere diversi stili - Quando si "naviga" in un link fornito da un entrypoint, quindi un endpoint, di solito questo fornisce altri link per continuare la "navigazione" dei "sotto" endpoint. Un esempio di risposta di un endpoint che rispetta il vincolo è nella pagina di wikipedia di HATEOAS, en.wikipedia.org/wiki/HATEOAS dove i link sono contenuti nel campo "links" della risposta. - Uno stile abbastanza comune per rispettare il vincolo HATEOAS è HAL en.wikipedia.org/wiki/Hypertext_Application_Language in cui i link sono nel campo "_links". La API di Github non è HAL ma rispetta il vincolo. - Una implementazione python (esempio) di un backend HAL-like è EVE docs.python-eve.org/en/stable/features.html - Segnaliamo che nella pagina di wikipedia di HATEOAS c'è il riferimento ad un articolo di Carson Gross autore di HTMX che ha un punto di vista su HATEOAS veramente interessante.
Sono commosso. Anche io ho iniziato con quel libro di VB6.0. Ricordo ancora il mio primo eseguibile, un cronometro. Mi sembrava la cosa più incredibile del mondo
I want to mention a mistake I've made: the example about the racing drone is not from Deepmind, but from a joint collaboration between Intel and the university of Zurich
Grazie a Paolo per gli ottimi spunti , suggerirei di fare una seconda puntata magari piu' operativa dove far vedere operativamente cosa vuol dire spulciare il codice da un browser (ad esempio) per cercare vulnerabilita' o meglio ancora su come verificare la copertura dei test che qualcuno ha dichiarato di aver fatto :-)
Grazie Paolo per aver partecipato! Andate a vedere il canale di Paolo per scoprire cose sulla sicurezza informatica! ru-vid.combBb0-9soTpU?feature=share
Che soft skill deve sviluppare in modo assolutamente prioritario uno sviluppatore mid/senior? Assumete provenienza da contesti dove non esiste questo tipo di cultura
Ecco la risposta di Fiorella! Scusa il ritardo! "Ciao Ettore, grazie mille per la domanda. Credo che le soft skill più importanti per un developer siano la comunicazione, l'ascolto attivo, il saper lavorare in team e saper gestire il proprio tempo (già queste skill sono un ottimo punto di partenza). Poi un altro must have è l'apprendimento continuo."
