WEBVTT 00:00:00.000 --> 00:00:02.000 Sotto il cappello dei performance test 00:00:02.000 --> 00:00:04.160 c'è un ampio spettro di test 00:00:04.160 --> 00:00:05.120 che vengono eseguiti. 00:00:05.120 --> 00:00:07.040 Di fatto vengono simulati i comportamenti 00:00:07.040 --> 00:00:09.279 degli utenti reali verso un prodotto, 00:00:09.279 --> 00:00:09.919 che sia un sito, 00:00:09.919 --> 00:00:12.000 che sia un'applicazione, che sia magari 00:00:12.000 --> 00:00:13.599 un insieme di API che vengono 00:00:13.599 --> 00:00:15.245 richiamate dal sito, in modo da 00:00:15.245 --> 00:00:16.765 simulare quello che è la "journey" 00:00:16.765 --> 00:00:18.285 di utilizzo dell'utente reale. 00:00:18.285 --> 00:00:19.565 In questo modo posso andare a 00:00:19.565 --> 00:00:21.164 vedere come si comporta il mio 00:00:21.164 --> 00:00:22.605 sistema e vedere se ci sono 00:00:22.605 --> 00:00:23.964 dei colli di bottiglia o dei 00:00:23.964 --> 00:00:26.204 problemi di prestazione, cioè determinate richieste 00:00:26.204 --> 00:00:28.125 che causano un rallentamento maggiore del 00:00:28.125 --> 00:00:31.269 sistema o una eccessiva rapidità con 00:00:31.269 --> 00:00:32.710 cui arrivano gli utenti. 00:00:34.070 --> 00:00:35.909 Salve a tutti, siete all'ascolto di 00:00:35.909 --> 00:00:38.229 INSiDER - Dentro la Tecnologia, 00:00:38.229 --> 00:00:40.469 un podcast di Digital People e 00:00:40.469 --> 00:00:41.645 io sono il vostro host, 00:00:41.645 --> 00:00:43.004 Davide Fasoli. 00:00:49.484 --> 00:00:52.844 Oggi parleremo con UNGUESS di "performance test", 00:00:52.844 --> 00:00:54.684 ovvero di tutti quei test che 00:00:54.684 --> 00:00:56.604 verificano che un sito web, 00:00:56.604 --> 00:00:58.710 un software o un servizio mantengano 00:00:58.710 --> 00:01:00.949 elevate prestazioni anche in condizioni di 00:01:00.949 --> 00:01:02.629 stress o uso intenso. 00:01:02.630 --> 00:01:04.069 Prima di passare alle notizie che 00:01:04.069 --> 00:01:05.989 più ci hanno colpito questa settimana, 00:01:06.069 --> 00:01:07.750 vi ricordo che potete seguirci su 00:01:07.750 --> 00:01:11.465 Instagram a @dentrolatecnologia, iscrivervi alla newsletter 00:01:11.465 --> 00:01:13.224 e ascoltare un nuovo episodio ogni 00:01:13.224 --> 00:01:15.144 sabato mattina, su Spotify, 00:01:15.144 --> 00:01:18.104 Apple Podcast, YouTube Music oppure direttamente 00:01:18.104 --> 00:01:19.224 sul nostro sito. 00:01:32.250 --> 00:01:34.409 Da diversi anni Google sta lavorando 00:01:34.409 --> 00:01:36.569 e investendo milioni di dollari nel 00:01:36.569 --> 00:01:38.784 settore della computazione quantistica. 00:01:38.864 --> 00:01:40.784 Come risultato è proprio Google l'azienda 00:01:40.784 --> 00:01:43.584 che dal 2019 detiene la supremazia 00:01:43.584 --> 00:01:44.625 in questo settore. 00:01:44.625 --> 00:01:46.146 E qualche giorno fa l'azienda ha 00:01:46.146 --> 00:01:48.944 presentato un nuovo chip quantistico che 00:01:48.944 --> 00:01:51.105 questa volta potrebbe aprire la strada 00:01:51.105 --> 00:01:53.859 alla costruzione di computer commercializzabili e 00:01:53.859 --> 00:01:54.900 su larga scala. 00:01:54.900 --> 00:01:56.099 La più grande sfida ad oggi 00:01:56.099 --> 00:01:58.019 nel lavorare con i "Qbit" o 00:01:58.019 --> 00:02:00.180 Quantum Bit, di cui avevamo parlato 00:02:00.180 --> 00:02:01.859 in una puntata, è legata alla 00:02:01.859 --> 00:02:04.180 soppressione del rumore e alla correzione 00:02:04.180 --> 00:02:04.819 degli errori. 00:02:05.155 --> 00:02:07.875 I Qbit infatti sono molto instabili 00:02:07.875 --> 00:02:09.314 e il loro stato può variare 00:02:09.314 --> 00:02:13.074 rapidamente restituendo risultati sbagliati o indesiderati. 00:02:13.074 --> 00:02:14.915 Con la nuova architettura di Google, 00:02:14.915 --> 00:02:17.235 chiamata "Willow", sono stati fatti dei 00:02:17.235 --> 00:02:18.675 passi da gigante in questo ambito, 00:02:18.960 --> 00:02:22.000 riducendo gli errori esponenzialmente grazie all'introduzione 00:02:22.000 --> 00:02:24.159 di alcuni Qbit dedicati proprio a 00:02:24.159 --> 00:02:26.480 proteggere le informazioni dal rumore. 00:02:26.480 --> 00:02:27.760 Questo ha permesso non solo di 00:02:27.760 --> 00:02:30.800 aumentare ulteriormente i Qbit del chip, 00:02:30.800 --> 00:02:32.080 ma come detto all'inizio, 00:02:32.080 --> 00:02:34.080 potrebbe essere una svolta nel produrre 00:02:34.080 --> 00:02:37.194 chip su larga scala e utilizzabili commercialmente, 00:02:37.194 --> 00:02:39.995 aprendo nuove possibilità nell'utilizzo di algoritmi 00:02:39.995 --> 00:02:42.155 pratici ad oggi impossibili da eseguire 00:02:42.155 --> 00:02:43.915 su computer tradizionali. 00:02:46.474 --> 00:02:50.289 OpenAI questa settimana ha lanciato ufficialmente Sora, 00:02:50.289 --> 00:02:52.689 il modello avanzato di intelligenza artificiale 00:02:52.689 --> 00:02:54.930 presentato a febbraio, che permette la 00:02:54.930 --> 00:02:57.329 generazione di video realistici in alta 00:02:57.329 --> 00:03:00.370 risoluzione attraverso stringhe di comandi testuali, 00:03:00.370 --> 00:03:02.530 immagini statiche o altri video di partenza. 00:03:02.884 --> 00:03:05.204 Attualmente il nuovo sistema di OpenAI 00:03:05.204 --> 00:03:07.204 è disponibile solamente per gli abbonati 00:03:07.204 --> 00:03:09.844 ai piani Plus e Pro di ChatGPT, 00:03:09.844 --> 00:03:12.164 dal costo rispettivamente di 20 e 00:03:12.164 --> 00:03:13.444 200 euro al mese. 00:03:13.444 --> 00:03:15.204 Inoltre al lancio sono stati esclusi 00:03:15.204 --> 00:03:16.989 il Regno Unito, la Svizzera e 00:03:16.989 --> 00:03:18.750 l'intera area economica europea. 00:03:18.750 --> 00:03:20.750 Tuttavia OpenAI ha dichiarato di voler 00:03:20.750 --> 00:03:22.509 estendere l'accesso a Sora anche a 00:03:22.509 --> 00:03:23.389 questi paesi. 00:03:23.389 --> 00:03:25.229 La versione di Sora rilasciata questa 00:03:25.229 --> 00:03:27.870 settimana è stata potenziata notevolmente rispetto 00:03:27.870 --> 00:03:29.550 al modello annunciato a inizio anno, 00:03:29.794 --> 00:03:31.474 tant'è che ora è sia più 00:03:31.474 --> 00:03:33.474 veloce ma anche più efficiente nella 00:03:33.474 --> 00:03:36.034 generazione di video, rendendo l'esperienza finale 00:03:36.034 --> 00:03:37.794 ancora più fluida e immediata. 00:03:37.875 --> 00:03:39.875 Alcune differenze sono state introdotte anche 00:03:39.875 --> 00:03:42.675 sulla base della tipologia di abbonamento sottoscritto. 00:03:42.990 --> 00:03:44.510 Chi possiede un piano Plus da 00:03:44.510 --> 00:03:46.349 20 euro avrà infatti fino a 00:03:46.349 --> 00:03:48.990 50 generazioni da 20 secondi massimo 00:03:48.990 --> 00:03:51.789 con una risoluzione di 720p, 00:03:51.790 --> 00:03:53.710 mentre chi è sottoscritto alla versione 00:03:53.710 --> 00:03:55.870 Pro da 200 euro potrà generare 00:03:55.870 --> 00:03:57.950 video illimitati in 1080p, 00:03:58.064 --> 00:04:00.705 con l'ulteriore possibilità di scaricare i 00:04:00.705 --> 00:04:02.705 contenuti senza watermark. 00:04:14.539 --> 00:04:16.939 Una buona esperienza utente o "UX", 00:04:16.939 --> 00:04:19.660 e in particolare l'interfaccia utente o "UI", 00:04:19.660 --> 00:04:21.180 si occupano di garantire che un 00:04:21.180 --> 00:04:22.939 software o un sito web abbia 00:04:22.939 --> 00:04:24.860 un design accattivante e intuitivo. 00:04:24.860 --> 00:04:26.539 Ma è altrettanto necessario che questa 00:04:26.539 --> 00:04:28.785 interfaccia risponda in modo immediato e 00:04:28.785 --> 00:04:31.345 senza interruzioni a ogni nostra interazione. 00:04:31.504 --> 00:04:33.584 Oltre all'interfaccia grafica, quindi, 00:04:33.584 --> 00:04:35.024 la velocità e la reattività di 00:04:35.024 --> 00:04:37.264 un software sono elementi cruciali per 00:04:37.264 --> 00:04:39.665 determinare il livello di soddisfazione dell'utente. 00:04:39.979 --> 00:04:41.259 Ma come si può garantire che 00:04:41.259 --> 00:04:43.579 un sito web mantenga elevate prestazioni 00:04:43.579 --> 00:04:45.259 anche in condizioni di stress o 00:04:45.259 --> 00:04:47.180 di uso intensivo, magari da parte 00:04:47.180 --> 00:04:49.500 di migliaia di utenti contemporaneamente? 00:04:49.579 --> 00:04:51.500 Per approfondire questo tema è con 00:04:51.500 --> 00:04:54.985 noi Edoardo Vannutelli, Testing Automation Senior 00:04:54.985 --> 00:04:57.704 Manager e Co-Founder di UNGUESS. 00:04:57.944 --> 00:04:59.225 Benvenuto Edoardo. 00:04:59.464 --> 00:05:01.305 Grazie mille, è un piacere essere qua. 00:05:01.704 --> 00:05:03.625 Questa è la seconda puntata che 00:05:03.625 --> 00:05:05.865 realizziamo con voi, con UNGUESS, 00:05:06.289 --> 00:05:08.529 qualche mese fa abbiamo parlato con 00:05:08.529 --> 00:05:12.050 Alessandro Caliandro di UX e UI appunto, 00:05:12.050 --> 00:05:14.689 quindi di esperienza utente e interfaccia utente. 00:05:15.089 --> 00:05:17.970 E oggi invece ci concentriamo sulle prestazioni, 00:05:18.129 --> 00:05:20.610 sulle performance di un sito web, 00:05:20.610 --> 00:05:22.855 di un servizio, di un software. 00:05:23.254 --> 00:05:24.375 In questo senso, quindi, 00:05:24.375 --> 00:05:26.295 che ruolo gioca la reattività di 00:05:26.295 --> 00:05:28.215 un sito o di un servizio 00:05:28.295 --> 00:05:30.775 per la soddisfazione dell'utente finale? 00:05:31.655 --> 00:05:33.335 Ma, gioca un ruolo cruciale, 00:05:33.334 --> 00:05:35.295 con Alessandro avete parlato della UX, 00:05:35.295 --> 00:05:38.529 la User Experience, sicuramente la velocità 00:05:38.610 --> 00:05:41.330 è un fattore determinante per garantire 00:05:41.330 --> 00:05:43.569 anche una, concorre a definire una 00:05:43.569 --> 00:05:45.089 User Experience di valore. 00:05:45.330 --> 00:05:48.529 Diciamo che più un software è lento, 00:05:48.529 --> 00:05:50.290 più un software ha delle interruzioni, 00:05:50.375 --> 00:05:51.975 non è costante le sue performance, 00:05:51.975 --> 00:05:53.735 più porta frustrazione all'utente. 00:05:53.735 --> 00:05:55.495 Quindi ci sono alcuni elementi fondamentali 00:05:55.495 --> 00:05:56.535 che ci danno valore, 00:05:56.535 --> 00:05:58.935 quindi riduce, le buone performance riducono 00:05:59.014 --> 00:06:01.495 la frustrazione che l'utente potrebbe provare 00:06:01.495 --> 00:06:02.694 durante l'utilizzo del software, 00:06:03.019 --> 00:06:05.180 aumenta la produttività, posso fare più 00:06:05.180 --> 00:06:06.540 attività in un tempo ridotto, 00:06:06.540 --> 00:06:08.220 ho più tempo per usare altre 00:06:08.220 --> 00:06:09.660 funzionalità dello stesso prodotto. 00:06:09.660 --> 00:06:10.939 Anche un fattore molto importante è 00:06:10.939 --> 00:06:11.980 la percezione della qualità, 00:06:11.980 --> 00:06:13.339 se io ho un software reattivo, 00:06:13.420 --> 00:06:14.459 un software che mi consente di 00:06:14.459 --> 00:06:15.899 fare rapidamente le operazioni che voglio 00:06:15.899 --> 00:06:16.845 andare a fare, che sia un 00:06:16.845 --> 00:06:18.764 bonifico bancario, ma anche solo la 00:06:18.764 --> 00:06:20.125 pubblicazione di un post in un 00:06:20.125 --> 00:06:22.205 qualche social network, la velocità mi 00:06:22.205 --> 00:06:24.845 fa percepire anche una qualità molto superiore, 00:06:24.845 --> 00:06:26.045 soprattutto l'assenza di lag, 00:06:26.045 --> 00:06:27.805 cioè dei comportamenti dove la velocità 00:06:27.805 --> 00:06:29.564 non è costante, faccio tre operazioni, 00:06:30.069 --> 00:06:31.350 ho un tempo di attesa per 00:06:31.350 --> 00:06:32.790 portarla a termine, ho un "loading" 00:06:32.790 --> 00:06:34.230 molto più lungo rispetto agli altri, 00:06:34.230 --> 00:06:37.029 questo mi dà una percezione di 00:06:37.029 --> 00:06:38.790 un prodotto di qualità più bassa. 00:06:38.790 --> 00:06:40.870 Tutto questo concorre a un coinvolgimento 00:06:40.870 --> 00:06:42.784 maggiore dell'utente, più è veloce, 00:06:42.784 --> 00:06:44.144 più è immediata, più apprezzo l'utilizzo 00:06:44.144 --> 00:06:46.144 di quel software e di conseguenza 00:06:46.224 --> 00:06:48.305 abbassa drasticamente il tasso di abbandono. 00:06:48.305 --> 00:06:49.745 L'esempio classico un e-commerce, 00:06:49.745 --> 00:06:52.224 se io ho una ricerca molto complicata, 00:06:52.224 --> 00:06:53.584 una ricerca molto lenta, 00:06:53.584 --> 00:06:54.944 magari se inserisco un parametro di 00:06:54.944 --> 00:06:55.904 un prodotto che conosco e devo 00:06:55.904 --> 00:06:57.425 attendere molto perché mi si presenti, 00:06:57.629 --> 00:06:59.149 sono più portato a usare magari 00:06:59.149 --> 00:07:00.990 un altro e-commerce o un altro 00:07:00.990 --> 00:07:02.589 servizio che mi consente di acquistare 00:07:02.589 --> 00:07:03.389 il prodotto. 00:07:03.389 --> 00:07:05.230 Anche perché oggi siamo abituati alla 00:07:05.230 --> 00:07:07.149 velocità e quindi ci metto un 00:07:07.149 --> 00:07:09.550 attimo a cambiare sito potenzialmente se 00:07:09.550 --> 00:07:11.470 è il primo dove sto cercando 00:07:11.470 --> 00:07:13.795 di acquistare qualcosa ad esempio non 00:07:13.795 --> 00:07:16.595 funziona ecco è molto facile cambiare 00:07:16.834 --> 00:07:18.514 potenzialmente l'esercente. 00:07:18.595 --> 00:07:20.675 Esattamente, siamo abituati alla velocità e 00:07:20.675 --> 00:07:21.794 abbiamo una grande offerta. 00:07:21.794 --> 00:07:23.714 Sono pochi i servizi esclusivi, 00:07:23.714 --> 00:07:24.435 cioè che mi danno... 00:07:24.834 --> 00:07:26.995 quei prodotti che mi offrono un 00:07:26.995 --> 00:07:27.555 servizio esclusivo. 00:07:27.829 --> 00:07:30.709 Quindi sono orientato, ho molta selezione, 00:07:30.709 --> 00:07:31.670 molta scelta. 00:07:32.149 --> 00:07:34.149 Da questo punto di vista oggi 00:07:34.310 --> 00:07:37.110 c'è più sensibilità sulla cura dell'estetica 00:07:37.110 --> 00:07:40.069 e dell'intuitività di un software, 00:07:40.069 --> 00:07:41.029 di un sito web, 00:07:41.235 --> 00:07:45.475 oppure c'è altrettanta attenzione alle sue performance? 00:07:45.714 --> 00:07:48.115 Purtroppo nella realtà dello sviluppo c'è 00:07:48.115 --> 00:07:49.235 un po' di, ancora un po' 00:07:49.235 --> 00:07:51.154 di iato tra quelli che sono 00:07:51.474 --> 00:07:52.914 la parte di design e quella 00:07:52.914 --> 00:07:53.954 che è la parte di sistema, 00:07:53.954 --> 00:07:55.235 nel senso che chi fa design 00:07:55.235 --> 00:07:56.860 si aspetta che poi i sistemisti, 00:07:56.860 --> 00:07:58.860 gli sviluppatori, tutto quello che si 00:07:58.860 --> 00:08:00.620 occupa sia di creazione del software 00:08:00.620 --> 00:08:02.699 che di prodotto si muova indipendente 00:08:02.699 --> 00:08:04.460 e garantisca un livello d'uso. 00:08:04.699 --> 00:08:06.860 Diciamo che sono due realtà che 00:08:06.860 --> 00:08:07.660 vanno molto a braccetto, 00:08:08.485 --> 00:08:11.285 nel senso dovrebbe esserci ancora più collaborazione, 00:08:11.285 --> 00:08:12.404 sarebbe bello che ce ne fosse 00:08:12.404 --> 00:08:14.004 sempre di più, dove i due temi, 00:08:14.004 --> 00:08:15.925 sia di usabilità che di performance 00:08:15.925 --> 00:08:17.925 del prodotto, collaborino insieme. 00:08:18.164 --> 00:08:20.164 Diciamo che tipicamente è molto una 00:08:20.164 --> 00:08:21.919 scelta di brand, di brand o 00:08:23.360 --> 00:08:24.800 di chi produce il prodotto. 00:08:24.800 --> 00:08:26.079 Si ha un focus più forte 00:08:26.079 --> 00:08:27.519 verso la UX e più forte 00:08:27.519 --> 00:08:31.759 sulla parte tecnologica delle performance. 00:08:31.759 --> 00:08:34.320 Però devono essere coltivati entrambi. 00:08:34.320 --> 00:08:35.839 La cosa molto bella è che 00:08:36.195 --> 00:08:38.835 dove c'è sinergia si può fare sponda. 00:08:38.915 --> 00:08:40.595 Vale a dire ci sono delle 00:08:40.595 --> 00:08:42.915 soluzioni dove una particolare richiesta: 00:08:42.915 --> 00:08:44.195 ho un sito e devo ottenere 00:08:44.674 --> 00:08:46.514 la lista dei miei prodotti acquistati 00:08:46.514 --> 00:08:47.875 negli ultimi 15 giorni, 00:08:47.875 --> 00:08:49.235 è una richiesta che sarà veloce 00:08:49.235 --> 00:08:50.355 se sono un privato. 00:08:50.355 --> 00:08:51.980 Se sono magari un'azienda e sto 00:08:51.980 --> 00:08:53.899 facendo l'elenco degli ordini degli ultimi 00:08:53.899 --> 00:08:55.980 12 mesi perché sono a fine anno, 00:08:55.980 --> 00:08:57.899 chiaramente quel tipo di richiesta dal 00:08:57.899 --> 00:08:59.340 punto di vista tecnologico è più lenta. 00:08:59.340 --> 00:09:01.019 E quindi avere dall'altra parte una 00:09:01.019 --> 00:09:03.420 sponda UX che aiuti a dare 00:09:03.420 --> 00:09:05.580 un messaggio opportuno durante le attività, 00:09:05.580 --> 00:09:07.875 quindi mi disegni un'interfaccia grafica che 00:09:07.875 --> 00:09:09.315 mi faccia capire cosa sta succedendo 00:09:09.315 --> 00:09:10.595 alla macchina e mi giustifichi quel 00:09:10.595 --> 00:09:12.434 tempo di attesa o me lo mascheri, 00:09:12.595 --> 00:09:13.715 succede anche quello e non è 00:09:13.715 --> 00:09:15.154 un pattern cattivo di design, 00:09:15.154 --> 00:09:16.434 però mi dia qualcosa di grafico 00:09:16.434 --> 00:09:18.274 che mi fa percepire un'attesa più 00:09:18.274 --> 00:09:19.394 bassa è molto importante. 00:09:19.634 --> 00:09:20.915 Un esempio classico sono i "loader". 00:09:21.090 --> 00:09:23.009 Se un loader accattivante che mi 00:09:23.009 --> 00:09:25.009 fa percepire, magari mi dice uno 00:09:25.009 --> 00:09:26.850 stato di che cosa sta processando, 00:09:26.850 --> 00:09:28.210 ho processato il mese di gennaio, 00:09:28.210 --> 00:09:30.290 febbraio, marzo, mi dà un feedback 00:09:30.290 --> 00:09:33.649 che mi rende quell'attesa più comprensibile 00:09:33.649 --> 00:09:35.730 e magari anche più piacevole da vedere. 00:09:36.134 --> 00:09:37.575 Quindi diciamo è un gioco di 00:09:37.575 --> 00:09:38.695 sponda che viene fatto. 00:09:38.695 --> 00:09:41.335 Molto spesso, purtroppo è più delegato 00:09:41.654 --> 00:09:43.575 ai singoli che devono trovare poi 00:09:43.575 --> 00:09:44.855 una quadra per cui... 00:09:44.855 --> 00:09:46.455 è legato al punto di test. 00:09:46.535 --> 00:09:48.455 Diciamo che forte pressione in questo 00:09:48.455 --> 00:09:50.934 momento viene messa dal lato sviluppo 00:09:51.149 --> 00:09:52.670 dove vengono chiesti tempi di risposta 00:09:52.670 --> 00:09:54.269 molto ridotti per avere più libertà 00:09:54.269 --> 00:09:55.230 in fase di UX. 00:09:55.230 --> 00:09:57.230 Però da caso a caso varia molto. 00:09:57.790 --> 00:09:59.389 Per fare un esempio - dimmi 00:09:59.389 --> 00:10:01.149 se può essere corretto di quello 00:10:01.149 --> 00:10:02.590 che hai appena detto - penso 00:10:02.590 --> 00:10:03.870 da una parte un sito web 00:10:03.870 --> 00:10:07.375 che premendo un tasto parte il 00:10:07.375 --> 00:10:09.375 caricamento e non succede nulla di 00:10:09.375 --> 00:10:11.134 nulla e dall'altro lato un sito 00:10:11.134 --> 00:10:12.335 che premendo il tasto, 00:10:12.335 --> 00:10:13.855 benché ci sia un limite perché 00:10:13.855 --> 00:10:15.615 come hai detto tu le informazioni 00:10:15.615 --> 00:10:18.415 devono essere recuperate, possono metterci del tempo, 00:10:18.570 --> 00:10:20.649 mi fa vedere una barra di 00:10:20.649 --> 00:10:24.410 progressione di questo tempo di attesa, 00:10:24.410 --> 00:10:24.889 ecco. 00:10:25.049 --> 00:10:27.610 Esattamente, esattamente, questo è lo scenario, 00:10:27.610 --> 00:10:29.690 hai sintetizzato perfettamente il caso. 00:10:30.009 --> 00:10:32.009 E poi penso comunque che sia 00:10:32.009 --> 00:10:34.315 importante investire in questo ambito... 00:10:34.315 --> 00:10:36.154 appunto è un investimento perché come 00:10:36.154 --> 00:10:39.195 dicevi prima sono al rischio di 00:10:39.195 --> 00:10:41.835 perdere il cliente quindi bisogna andare 00:10:41.835 --> 00:10:43.595 avanti di pari passi sia con 00:10:44.875 --> 00:10:47.659 la UX e anche garantire appunto 00:10:47.659 --> 00:10:51.980 queste performance del servizio che si 00:10:51.980 --> 00:10:52.779 mette a disposizione. 00:10:52.779 --> 00:10:55.500 Diciamo che oggigiorno sono proprio effettivamente 00:10:55.500 --> 00:10:56.860 le due parti di una mela, 00:10:56.860 --> 00:10:58.139 cioè la percezione del prodotto è 00:10:58.139 --> 00:10:59.504 data da entrambi i fattori. 00:10:59.504 --> 00:11:01.184 La qualità è difficile riuscire a 00:11:01.184 --> 00:11:02.945 perseguirla con un solo di questi aspetti. 00:11:03.345 --> 00:11:05.825 E a proposito di questo, 00:11:05.825 --> 00:11:07.345 appunto del tema di oggi, 00:11:07.345 --> 00:11:09.585 ci spieghi nella pratica che cos'è 00:11:09.585 --> 00:11:12.465 un performance test, perché appunto è 00:11:12.465 --> 00:11:13.825 importante - questo in parte l'abbiamo 00:11:13.825 --> 00:11:15.899 già capito - e se ci 00:11:15.899 --> 00:11:17.419 sono anche degli esempi concreti che 00:11:17.419 --> 00:11:19.740 puoi farci di come un performance 00:11:19.740 --> 00:11:22.860 test ha salvato una situazione che 00:11:22.860 --> 00:11:25.419 altrimenti sarebbe stata disastrosa. 00:11:25.899 --> 00:11:29.394 Sotto il cappello dei performance test 00:11:29.394 --> 00:11:31.714 c'è un ampio spettro di test 00:11:31.714 --> 00:11:32.835 che vengono eseguiti. 00:11:32.995 --> 00:11:36.595 Sostanzialmente per sintetizzarli in estrema sintesi: 00:11:37.394 --> 00:11:39.475 di fatto vengono simulati i comportamenti 00:11:39.475 --> 00:11:41.860 degli utenti reali verso un prodotto, 00:11:41.860 --> 00:11:42.419 che sia un sito, 00:11:42.419 --> 00:11:44.580 che sia un'applicazione che sia magari 00:11:44.580 --> 00:11:46.100 un insieme di API che vengono 00:11:46.100 --> 00:11:47.860 richiamate dal sito in modo da 00:11:47.860 --> 00:11:49.459 simulare quello che la "journey" di 00:11:49.459 --> 00:11:51.459 utilizzo dell'utente reale in questo modo 00:11:51.459 --> 00:11:53.220 posso andare a vedere come si 00:11:53.220 --> 00:11:55.554 comporta il mio sistema quindi i server, 00:11:55.554 --> 00:11:56.754 banalizzando un po' la cosa ma 00:11:56.754 --> 00:11:59.075 giusto per capirci quindi il database, 00:11:59.075 --> 00:12:01.394 il server web, l'eventuale interfaccia e 00:12:01.394 --> 00:12:02.754 vedere se ci sono decolli di 00:12:02.754 --> 00:12:04.434 bottiglia o dei problemi delle prestazioni 00:12:04.434 --> 00:12:06.514 cioè determinate richieste che causano un 00:12:06.514 --> 00:12:07.875 rallentamento maggiore del sistema, 00:12:08.580 --> 00:12:11.379 un'eccessiva concorrenza degli utenti che possono 00:12:11.379 --> 00:12:14.820 creare problema, o una eccessiva rapidità 00:12:14.820 --> 00:12:16.340 con cui arrivano gli utenti. 00:12:16.340 --> 00:12:17.779 Il sistema del mondo tecnologico in 00:12:17.779 --> 00:12:19.380 questo momento, negli ultimi anni ha 00:12:19.380 --> 00:12:21.074 fatto una migrazione verso cloud molto 00:12:21.074 --> 00:12:22.434 forte e si sta portando sempre 00:12:22.434 --> 00:12:24.195 più verso servizi "serverless" dove non 00:12:24.195 --> 00:12:26.674 ho fisicamente il pezzo di ferro 00:12:26.674 --> 00:12:28.674 a casa quindi che monitoro. 00:12:28.674 --> 00:12:30.754 Questo dà una grossa facilità di 00:12:30.754 --> 00:12:32.274 uso perché posso ampliare molto la 00:12:32.274 --> 00:12:33.235 scalabilità del mio prodotto. 00:12:33.235 --> 00:12:34.639 Quindi posso avere quello che prima era: 00:12:34.639 --> 00:12:36.081 acquisti un server, lo configuri e 00:12:36.081 --> 00:12:37.440 lo metti nella data center; 00:12:37.440 --> 00:12:38.800 adesso è: faccio un click su 00:12:38.800 --> 00:12:40.639 una delle piattaforme cloud e aggiungo server. 00:12:40.639 --> 00:12:41.920 Questo ha portato a team di 00:12:41.920 --> 00:12:44.000 controllo molto superiori. 00:12:44.000 --> 00:12:45.200 Una maggiore scalabilità, una maggior rapidità 00:12:45.200 --> 00:12:47.040 ma anche una potenziale esplosione dei 00:12:47.040 --> 00:12:49.285 costi o un potenziale abbassamento delle 00:12:49.285 --> 00:12:50.725 performance perché ho un controllo meno 00:12:50.725 --> 00:12:52.085 fino in alcuni casi. 00:12:52.404 --> 00:12:55.125 Quindi il test tipicamente nell'ambito delle 00:12:55.125 --> 00:12:57.205 performance ci sono due macro aree: 00:12:57.205 --> 00:12:58.725 una prima macro area è dire 00:12:58.725 --> 00:13:00.725 faccio sul sito o sull'applicazione le 00:13:00.725 --> 00:13:02.039 operazioni che mi aspetto e controllo 00:13:02.039 --> 00:13:04.039 che la parte back-end risponda nei 00:13:04.039 --> 00:13:04.679 tempi congrui. 00:13:04.679 --> 00:13:06.440 Se sono nel mondo web molta 00:13:06.440 --> 00:13:07.480 attenzione viene anche posta... 00:13:07.480 --> 00:13:08.679 una volta che ho recuperato i 00:13:08.679 --> 00:13:10.440 dati dal mio server che il 00:13:10.440 --> 00:13:12.519 browser li renderizzi nel modo corretto. 00:13:12.759 --> 00:13:15.000 Quindi me li mostri nei tempi giusti, 00:13:15.000 --> 00:13:16.285 non perda, diciamo così, 00:13:16.285 --> 00:13:18.125 non investa troppo tempo per renderizzare 00:13:18.125 --> 00:13:20.524 graficamente un contenuto, magari non aspetti 00:13:20.524 --> 00:13:21.565 di avere tutti i dati prima 00:13:21.565 --> 00:13:22.605 di mostrarmi la pagina, 00:13:22.605 --> 00:13:23.965 per cui l'header, il contenuto, 00:13:23.965 --> 00:13:25.085 la parte centrale me le mostri, 00:13:25.085 --> 00:13:25.965 poi se ci sono dati che 00:13:25.965 --> 00:13:28.045 devono essere caricati dinamicamente vengono caricati 00:13:28.045 --> 00:13:28.845 in modo progressivo. 00:13:29.100 --> 00:13:30.940 In tutto questo scenario ci sono 00:13:30.940 --> 00:13:32.379 tanti punti di intervento, 00:13:32.379 --> 00:13:33.980 mi concentrerei più sulla prima parte 00:13:33.980 --> 00:13:34.779 di cui ho parlato che sono 00:13:34.779 --> 00:13:35.899 i test di carico più verso 00:13:35.899 --> 00:13:37.659 il lato server che sono più immediati. 00:13:37.659 --> 00:13:40.539 Abbiamo tanti esempi nell'arco dei progetti 00:13:40.539 --> 00:13:43.259 che abbiamo fatto di potenziali casi disastrosi, 00:13:43.339 --> 00:13:46.404 uno in particolare in preparazione dell'ultimo 00:13:47.284 --> 00:13:51.365 Black Friday dove c'erano due problemi 00:13:51.365 --> 00:13:53.845 lato loro, una struttura relativamente nuova, 00:13:53.845 --> 00:13:55.125 si aspettavano un picco di clienti 00:13:55.125 --> 00:13:57.940 che poi effettivamente c'è stato e 00:13:57.940 --> 00:14:00.500 per come era impostato il database, 00:14:00.659 --> 00:14:03.379 quindi la parte software che memorizza 00:14:03.379 --> 00:14:04.820 i dati, avevano un collo di 00:14:04.820 --> 00:14:06.500 bottiglia molto forte relativo ad alcune 00:14:06.500 --> 00:14:07.700 tipologie di ricerca. 00:14:07.700 --> 00:14:09.940 Quindi facendo certe ricerche era molto rapido. 00:14:10.215 --> 00:14:11.575 Su altre tipologie di ricerche, 00:14:11.575 --> 00:14:13.254 su prodotti più particolari che avevano 00:14:13.254 --> 00:14:14.375 dei dettagli in più: 00:14:14.455 --> 00:14:15.495 una dimensione di taglio, 00:14:15.495 --> 00:14:16.215 una dimensione di colore, 00:14:16.215 --> 00:14:17.575 il rallentamento era molto forte. 00:14:17.575 --> 00:14:19.095 E questo ha fatto sì che 00:14:19.095 --> 00:14:21.335 chi gestisce il database all'interno di 00:14:21.335 --> 00:14:23.095 questa azienda abbia identificato il problema, 00:14:23.095 --> 00:14:24.789 abbia fatto piccole modifiche in realtà, 00:14:24.789 --> 00:14:26.549 ma abbia migliorato del 70% le 00:14:26.549 --> 00:14:27.669 performance di quelle chiamate, 00:14:27.669 --> 00:14:28.870 quindi una cifra molto grande. 00:14:28.870 --> 00:14:29.909 E questa cosa è anche un 00:14:29.909 --> 00:14:31.429 problema poco visibile se non fai 00:14:31.429 --> 00:14:33.029 un test di questo tipo, 00:14:33.029 --> 00:14:34.549 perché non ho un'evidenza, 00:14:34.549 --> 00:14:35.589 ce l'ho su grandi numeri, 00:14:35.589 --> 00:14:36.470 ma non posso vedere. 00:14:36.470 --> 00:14:38.149 Un altro caso è stato la concorrenza. 00:14:38.644 --> 00:14:42.644 Sempre questo cliente ha identificato che 00:14:42.725 --> 00:14:44.085 il sistema resisteva bene, 00:14:44.085 --> 00:14:45.284 aveva dei tempi di risposta molto 00:14:45.284 --> 00:14:47.764 buoni anche con tanti utenti ma 00:14:47.764 --> 00:14:49.445 quando l'arrivo degli utenti era molto rapido, 00:14:49.445 --> 00:14:50.884 quindi tanti utenti che si connettono, 00:14:50.884 --> 00:14:52.804 controllano qualcosa e non proseguono nella 00:14:53.205 --> 00:14:54.164 journey all'interno del sito, 00:14:54.164 --> 00:14:55.639 ma è solo una verifica puntuale, 00:14:55.639 --> 00:14:57.079 il sito andava in difficoltà. 00:14:57.079 --> 00:14:58.759 Questo era molto pericoloso perché potrei 00:14:58.759 --> 00:15:00.120 avere tanta gente che è spinta 00:15:00.120 --> 00:15:01.159 sul mio sito, magari a valle 00:15:01.159 --> 00:15:03.000 di un'operazione commerciale di promozione, 00:15:03.079 --> 00:15:04.600 una pubblicità per esempio. 00:15:04.600 --> 00:15:06.279 Pensate a un sito che vende 00:15:06.279 --> 00:15:08.105 prodotti per la cucina e compare 00:15:08.105 --> 00:15:10.584 come pubblicità all'interno di un programma 00:15:10.584 --> 00:15:13.065 tipo Masterchef, quindi con un grosso 00:15:13.065 --> 00:15:14.264 ritorno di utenti. 00:15:14.264 --> 00:15:15.304 In quel momento io ho un 00:15:15.304 --> 00:15:17.065 picco e quel picco di utenti 00:15:17.065 --> 00:15:20.264 potrebbe compromettermi anche l'utilizzo da parte 00:15:20.264 --> 00:15:21.704 di chi invece è un utente ricorrente, 00:15:22.024 --> 00:15:23.144 è già all'interno di una journey 00:15:23.144 --> 00:15:24.399 di acquisto molto importante, 00:15:24.399 --> 00:15:25.679 quindi anche ha meno percezione di 00:15:25.679 --> 00:15:26.080 un sito. 00:15:26.080 --> 00:15:27.920 Quindi questi sono fattori. 00:15:28.000 --> 00:15:29.679 Annesso a questo noi lavoriamo sempre 00:15:29.679 --> 00:15:31.440 più con applicazioni molto connesse tra 00:15:31.440 --> 00:15:32.720 di loro, per cui io ho 00:15:32.720 --> 00:15:34.320 il mio sito magari si appoggia 00:15:34.320 --> 00:15:35.519 a delle API esterne per fare 00:15:35.519 --> 00:15:37.440 servizi diversi: la verifica della carta 00:15:37.440 --> 00:15:41.345 di credito, piuttosto che magari l'identificazione 00:15:41.424 --> 00:15:42.544 geografica di dove sono, 00:15:42.544 --> 00:15:44.144 il sito che mi restituisce le mappe. 00:15:44.144 --> 00:15:46.384 Questi servizi sono sia gratuiti che 00:15:46.384 --> 00:15:48.705 a pagamento e hanno dei vincoli d'utilizzo. 00:15:49.105 --> 00:15:50.384 Un caso particolare ci è capitato 00:15:50.384 --> 00:15:52.384 con un cliente che gestisce un 00:15:52.384 --> 00:15:55.039 grosso salone italiano, da uno stress 00:15:55.039 --> 00:15:56.879 test è emerso che il sistema 00:15:57.279 --> 00:15:58.480 a cui si appoggiava per l'invio 00:15:58.480 --> 00:16:00.639 delle mail non era stato opportunamente 00:16:00.639 --> 00:16:02.799 dimensionato per i volumi di utenti 00:16:02.799 --> 00:16:04.000 che si aspettavano di avere. 00:16:04.000 --> 00:16:06.559 Pensate, cambio contesto, la vendita di 00:16:06.559 --> 00:16:07.679 un biglietto di Vasco Rossi, 00:16:07.985 --> 00:16:09.825 tipicamente viene aperto, viene aperta la 00:16:09.825 --> 00:16:11.585 capienza magari di San Siro o 00:16:11.585 --> 00:16:13.264 dell'Olimpico a Roma, quindi una grande 00:16:13.264 --> 00:16:16.465 quantità di posti, in pochi minuti 00:16:16.465 --> 00:16:18.865 vengono bruciati tutti quei posti perché 00:16:18.865 --> 00:16:21.200 vengono acquistati, ma tipicamente deve esserci 00:16:21.200 --> 00:16:22.159 dietro un sistema che è in 00:16:22.159 --> 00:16:23.360 grado di mandare quel volume di 00:16:23.360 --> 00:16:25.279 mail in un lasso di tempo congruo, 00:16:25.279 --> 00:16:26.399 perché a valle di un'operazione di 00:16:26.399 --> 00:16:28.000 questo tipo devo ricevere anche la mail. 00:16:28.079 --> 00:16:30.159 Quindi se vogliamo, questo aspetto non 00:16:30.159 --> 00:16:32.320 è forse cruciale nel primo impatto 00:16:32.320 --> 00:16:34.320 di acquisto dell'esperienza d'uso, 00:16:34.320 --> 00:16:35.679 ma è di vitale importanza nell'utilizzo, 00:16:35.679 --> 00:16:36.934 se non mi arriva per mail 00:16:36.934 --> 00:16:38.934 il biglietto per accedere al concerto 00:16:38.934 --> 00:16:40.455 o per accedere all'evento, 00:16:40.934 --> 00:16:42.375 comunque l'esperienza d'uso è molto negativa 00:16:42.375 --> 00:16:44.855 e potenzialmente dannosissima, visti i volumi. 00:16:45.575 --> 00:16:46.615 Sì, molto interessante. 00:16:46.615 --> 00:16:48.934 Quindi bisogna analizzare tutta la catena 00:16:48.934 --> 00:16:51.299 e potenzialmente potrebbe essere non colpa 00:16:51.299 --> 00:16:53.299 dello sviluppatore che ha sviluppato un 00:16:53.299 --> 00:16:55.539 determinato sito web, ma anche a chi... 00:16:55.699 --> 00:16:56.339 si appoggia. 00:16:56.339 --> 00:16:57.940 Fra l'altro hai citato anche la 00:16:57.940 --> 00:17:00.659 questione dei concerti, si potrebbero definire 00:17:00.659 --> 00:17:02.339 anche i cosiddetti "click day" in 00:17:02.339 --> 00:17:05.365 cui molte persone si connettono allo 00:17:05.365 --> 00:17:07.204 stesso sito web tutte insieme, 00:17:07.204 --> 00:17:08.964 ecco, magari quando la portata al 00:17:08.964 --> 00:17:11.444 sito web giornaliero è un centesimo 00:17:12.164 --> 00:17:13.044 di quella. 00:17:13.125 --> 00:17:14.325 E a volte magari non sono 00:17:14.325 --> 00:17:16.164 neanche persone, cioè sono bot. 00:17:16.164 --> 00:17:17.605 Hai fatto l'esempio di un concerto 00:17:17.605 --> 00:17:19.710 e come il fenomeno del "secondary 00:17:19.710 --> 00:17:22.589 ticketing" porta di fatto a dei 00:17:22.589 --> 00:17:24.750 flussi anche superiori a quelli che 00:17:24.750 --> 00:17:26.429 potenzialmente sarebbero... 00:17:26.990 --> 00:17:28.349 Attesi, assolutamente. 00:17:28.589 --> 00:17:30.029 Sì sì, questo è un problema 00:17:30.029 --> 00:17:31.630 molto diffuso e ci sono sempre 00:17:31.630 --> 00:17:33.984 più servizi che nascono per andare 00:17:33.984 --> 00:17:35.664 a intercettare i bot e limitarne 00:17:35.664 --> 00:17:36.704 l'utilizzo dei bot. 00:17:36.704 --> 00:17:39.345 Perché potenzialmente quelli potrebbero essere infiniti 00:17:39.345 --> 00:17:41.664 quindi neanche fare un performance test... 00:17:41.664 --> 00:17:42.545 cioè non si può fare un 00:17:42.545 --> 00:17:45.585 performance test illimitato ecco bisogna calcolare 00:17:45.585 --> 00:17:46.625 quelli che sono le persone. 00:17:47.049 --> 00:17:48.730 Sì, diciamo che uno dei punti 00:17:48.730 --> 00:17:50.170 fondamentali nel momento in cui si 00:17:50.170 --> 00:17:51.210 fa un setup di un test 00:17:51.210 --> 00:17:53.609 di carico è identificare un obiettivo chiaro. 00:17:53.769 --> 00:17:55.529 Quindi, dato una fotografia il più 00:17:55.529 --> 00:17:57.769 possibile completa del servizio o dei 00:17:57.769 --> 00:18:00.250 servizi che concorrono a costruire il 00:18:00.250 --> 00:18:01.369 prodotto che l'utente utilizza, 00:18:02.125 --> 00:18:04.125 avere quante più informazioni possibili su 00:18:04.125 --> 00:18:06.444 quella che è la journey effettiva dell'utente, 00:18:06.684 --> 00:18:08.044 quanti utenti mi aspetto. 00:18:08.204 --> 00:18:10.125 Nel Black Friday precedente quanti sono 00:18:10.125 --> 00:18:11.565 stati gli utenti, quante pagine hanno 00:18:11.565 --> 00:18:14.044 consultato prima di arrivare a finalizzare 00:18:14.044 --> 00:18:15.819 un acquisto, è qual è il 00:18:15.819 --> 00:18:17.259 comportamento dentro la pagina e quindi 00:18:17.259 --> 00:18:19.500 andare a simulare il comportamento quanto 00:18:19.500 --> 00:18:21.659 più vicino possibile al comportamento utente 00:18:21.659 --> 00:18:22.779 e qua la raccolta di dati 00:18:22.779 --> 00:18:24.779 è estremamente importante perché se ho 00:18:24.779 --> 00:18:27.099 uno storico o una proiezione realistica 00:18:27.099 --> 00:18:28.139 a partire da uno storico posso 00:18:28.139 --> 00:18:29.659 fare un lavoro molto più accurato. 00:18:29.659 --> 00:18:31.555 Come dicevi giustamente tu tracciare tutta 00:18:31.555 --> 00:18:33.154 la catena di tutti quei servizi 00:18:33.154 --> 00:18:34.835 che concorrono all'esperienza d'uso e poi 00:18:34.835 --> 00:18:36.355 identificare degli obiettivi, ci sono i 00:18:36.355 --> 00:18:37.875 test di carico che sono complessivi 00:18:37.875 --> 00:18:39.634 sulla journey, e-commerce è il classico 00:18:39.634 --> 00:18:41.795 dell'acquisto o possono esserci test di 00:18:41.795 --> 00:18:43.394 carico puntuali su singoli servizi, 00:18:43.710 --> 00:18:45.630 ho il sistema di registrazione dove 00:18:45.630 --> 00:18:46.829 metto il mio CAP e mi 00:18:46.829 --> 00:18:48.589 restituisce il numero di... 00:18:48.909 --> 00:18:51.869 la via, piuttosto che qualche altro 00:18:51.869 --> 00:18:54.429 dato relativo al mio indirizzo per 00:18:54.429 --> 00:18:55.390 facilitare la mia digitazione, 00:18:55.894 --> 00:18:57.575 vedere che quel servizio che tipicamente 00:18:57.575 --> 00:18:59.014 non è stato sviluppato con una 00:18:59.014 --> 00:19:00.614 pressione di un carico clamoroso, 00:19:00.855 --> 00:19:02.934 in quell'occasione - Black Friday piuttosto 00:19:02.934 --> 00:19:04.134 che l'acquisto di un biglietto appunto 00:19:04.134 --> 00:19:05.894 di un grande artista - sono 00:19:05.894 --> 00:19:07.494 particolarmente sotto stress. 00:19:07.494 --> 00:19:09.500 E in tutto questo si collega 00:19:09.500 --> 00:19:11.179 anche la profilazione del tipo di traffico, 00:19:11.179 --> 00:19:12.139 come dicevi giustamente tu, 00:19:12.139 --> 00:19:14.700 ho tanti bot all'inizio che salgono improvvisamento, 00:19:14.700 --> 00:19:16.859 all'apertura, ho tanti bot che accedono 00:19:16.859 --> 00:19:18.220 al mio sito e poi vengono filtrati, 00:19:18.220 --> 00:19:19.659 vengono eliminati dai servizi che ti 00:19:19.659 --> 00:19:20.779 dicevo prima che ci sono. 00:19:21.179 --> 00:19:23.179 Però devo controllare che finché viene 00:19:23.179 --> 00:19:24.779 identificato quel traffico il sistema stia su... 00:19:24.779 --> 00:19:26.775 che continui a rispondermi in tempo 00:19:26.775 --> 00:19:28.375 utile per cui possa attivarsi il 00:19:28.375 --> 00:19:30.375 sistema che uccide i bot. 00:19:30.615 --> 00:19:33.974 Dall'altra parte devo verificare il comportamento 00:19:33.974 --> 00:19:35.335 discontinuo e il traffico. 00:19:35.335 --> 00:19:37.494 Siamo sempre più orientati a delle 00:19:37.494 --> 00:19:40.630 soluzioni che hanno una struttura scalabile 00:19:40.630 --> 00:19:41.269 nel tempo. 00:19:41.269 --> 00:19:42.549 Che è la questione cloud che 00:19:42.549 --> 00:19:44.710 facevi cioè: posso acquistare potenza di 00:19:44.710 --> 00:19:46.230 calcolo all'occorrenza. 00:19:46.230 --> 00:19:47.029 All'occorrenza. 00:19:47.430 --> 00:19:49.269 E questo fa scattare un passo 00:19:49.269 --> 00:19:50.549 in più nei test di carico, 00:19:50.549 --> 00:19:52.230 cioè un primo impatto è voglio 00:19:52.230 --> 00:19:53.349 essere sicuro che il mio sistema 00:19:53.734 --> 00:19:55.974 garantisca le performance chi si aspetta 00:19:55.974 --> 00:19:56.855 il mio utente. 00:19:56.934 --> 00:19:58.375 Il passo ulteriore è quello che 00:19:58.375 --> 00:19:59.734 io pago di performance e di 00:19:59.734 --> 00:20:02.134 scalabilità è coordinato al traffico che ho? 00:20:02.134 --> 00:20:03.734 Diciamo che potenza di calcolo infinite 00:20:03.734 --> 00:20:05.974 potrei mettere 3000 server che rispondono 00:20:05.974 --> 00:20:07.380 al mio sistema e mi garantisco 00:20:07.380 --> 00:20:08.740 una qualità perché c'è un utente 00:20:08.740 --> 00:20:09.619 che ha il suo server, 00:20:09.619 --> 00:20:11.140 chiaramente è sovrabbondante. 00:20:11.140 --> 00:20:12.420 Questo potrebbe avere senso magari il 00:20:12.420 --> 00:20:13.700 primo giorno di un evento, 00:20:13.700 --> 00:20:14.900 il primo giorno di vendita, 00:20:14.980 --> 00:20:16.740 ma la settimana dopo dove questo 00:20:16.740 --> 00:20:18.259 servizio è ancora attivo è uno spreco. 00:20:18.595 --> 00:20:21.075 Quand è che quantifico la dimensione 00:20:21.075 --> 00:20:23.235 corretta dei miei sistemi per rispondere 00:20:23.235 --> 00:20:25.075 ai diversi livelli di traffico, 00:20:25.235 --> 00:20:26.355 che è uno step ulteriore, 00:20:26.355 --> 00:20:27.875 quindi vado ad identificare quali sono 00:20:27.875 --> 00:20:29.235 le risorse che ho bisogno, 00:20:29.235 --> 00:20:30.755 a dimensionare le risorse rispetto al 00:20:30.755 --> 00:20:31.555 traffico che mi aspetto? 00:20:31.799 --> 00:20:34.519 E uno step ulteriore è andare 00:20:34.519 --> 00:20:35.880 a ragionare come faccio a vedere 00:20:35.880 --> 00:20:38.920 che il mio sistema scali sufficientemente rapidamente, 00:20:38.920 --> 00:20:40.920 quindi aggiunga potenza di calcolo o 00:20:40.920 --> 00:20:42.519 la tolga, in maniera importante. 00:20:42.519 --> 00:20:44.200 Questo, parliamo di alcuni clienti che 00:20:44.200 --> 00:20:45.960 abbiamo avuto che hanno portato un "saving", 00:20:46.154 --> 00:20:47.994 studiando bene questi aspetti e le 00:20:47.994 --> 00:20:49.355 politiche di "scale up" e "scale down", 00:20:49.355 --> 00:20:50.955 quindi di crescita della potenza di calcolo, 00:20:51.195 --> 00:20:52.555 scale up, e di crescita della 00:20:52.555 --> 00:20:54.315 potenza di calcolo in situazioni dove 00:20:54.315 --> 00:20:55.595 non c'è traffico o il traffico 00:20:55.595 --> 00:20:57.275 è ridotto, scale down. 00:20:57.355 --> 00:20:59.369 In questi scenari saving anche del 00:20:59.369 --> 00:21:02.009 40-50% rispetto a un budget annuale, 00:21:02.009 --> 00:21:03.769 quindi parliamo di cifre anche importanti, 00:21:03.769 --> 00:21:04.650 oggigiorno. 00:21:04.809 --> 00:21:07.289 Sì anche perché senza cloud altrimenti 00:21:07.289 --> 00:21:10.410 dovevi fare un investimento iniziale incredibile 00:21:10.410 --> 00:21:12.410 che non tutti potevano permettersi di fare, 00:21:12.410 --> 00:21:15.904 quindi rende più accessibile anche a molti, 00:21:15.904 --> 00:21:17.184 a molte più persone, 00:21:17.184 --> 00:21:21.025 a molti più servizi questo tipo di... 00:21:21.105 --> 00:21:22.704 la possibilità di fare appunto... 00:21:22.705 --> 00:21:24.305 Esattamente, è anche un po' alla 00:21:24.305 --> 00:21:25.904 base del boom delle start-up, 00:21:25.904 --> 00:21:28.329 sentiamo di start-up che hanno cifre 00:21:28.329 --> 00:21:29.691 mila abbonanti e sono 4 o 00:21:29.691 --> 00:21:32.009 6 persone, ma proprio perché possono 00:21:32.009 --> 00:21:35.049 vincolare il costo dell'infrastruttura alla capienza 00:21:35.049 --> 00:21:36.169 dei clienti che hanno. 00:21:36.170 --> 00:21:38.009 Quindi se una scale-up può permettersi 00:21:38.009 --> 00:21:40.464 di dire adesso investo X milioni 00:21:40.464 --> 00:21:42.704 di euro in infrastruttura perché so 00:21:42.704 --> 00:21:43.744 che ho un traffico di un 00:21:43.744 --> 00:21:45.184 certo tipo, ho una clientela di 00:21:45.184 --> 00:21:47.345 un certo tipo, realtà più piccole 00:21:47.345 --> 00:21:49.184 hanno necessità di ancorare i loro 00:21:49.184 --> 00:21:51.345 costi alla quantità di tenti che hanno, 00:21:51.345 --> 00:21:52.704 alla quantità di clienti in questo 00:21:52.704 --> 00:21:53.264 caso che hanno. 00:21:54.450 --> 00:21:57.490 Per quanto riguarda la valutazione che 00:21:57.490 --> 00:21:59.089 fate nel momento in cui bisogna 00:21:59.089 --> 00:22:01.249 porre in essere un performance test 00:22:01.250 --> 00:22:02.490 non c'è il rischio che e 00:22:02.529 --> 00:22:05.569 tu prima facevi l'esempio del Black Friday, 00:22:05.569 --> 00:22:06.769 non c'è il rischio che magari 00:22:06.769 --> 00:22:09.524 tenere in considerazione i dati dello 00:22:09.524 --> 00:22:11.284 scorso anno non sia sufficiente? 00:22:11.284 --> 00:22:13.124 Cioè come fate ad essere sicuri 00:22:13.125 --> 00:22:15.684 che il performance test sia accurato, 00:22:15.684 --> 00:22:17.524 che poi possa rappresentare quella che 00:22:17.524 --> 00:22:19.524 sarà la realtà e quindi non 00:22:19.524 --> 00:22:22.326 creare problemi potenzialmente al servizio o 00:22:22.326 --> 00:22:22.724 al sito? 00:22:23.359 --> 00:22:25.359 Ci sono diverse "proxy" che si 00:22:25.359 --> 00:22:26.320 mettono in essere. 00:22:26.320 --> 00:22:27.440 Quello che dicevo prima, 00:22:27.440 --> 00:22:28.640 più il dato è accurato, 00:22:28.640 --> 00:22:30.080 più la proiezione che ci porta, 00:22:30.080 --> 00:22:32.240 se pensiamo all'e-commerce, più la proiezione 00:22:32.240 --> 00:22:33.919 che ci porta il sito: 00:22:33.920 --> 00:22:36.240 noi l'anno scorso abbiamo avuto 10.000 utenti, 00:22:36.240 --> 00:22:38.184 ci aspettiamo di averne un 30% 00:22:38.184 --> 00:22:40.265 di più, un 20% di più. 00:22:40.345 --> 00:22:41.465 Per cui c'è una parte che 00:22:41.465 --> 00:22:42.664 è un dato che noi riceviamo 00:22:42.664 --> 00:22:44.424 ogni input, una parte sono dei 00:22:44.424 --> 00:22:45.945 margini di sicurezza che a livello 00:22:45.945 --> 00:22:48.664 di procedura vengono impostati. 00:22:48.744 --> 00:22:51.065 Per cui ho X utenti, 00:22:51.420 --> 00:22:53.180 posso ragionare su un carico leggermente 00:22:53.180 --> 00:22:55.019 superiore rispetto a quello che mi aspetto, 00:22:55.019 --> 00:22:56.779 posso ragionare su dei tempi più 00:22:56.779 --> 00:22:58.859 stringenti per la dotazione del performance. 00:22:59.019 --> 00:23:02.059 Poi la certezza proprio non ce l'hai. 00:23:02.059 --> 00:23:03.820 E qui entra il gioco il 00:23:03.820 --> 00:23:05.019 discorso che ti facevo prima. 00:23:05.174 --> 00:23:07.815 Più io, oltre all'analisi del singolo carico, 00:23:07.815 --> 00:23:10.694 posso avere un'analisi di quanto rapidamente scala, 00:23:11.095 --> 00:23:14.055 io posso garantire che il set minimo, 00:23:14.295 --> 00:23:16.134 sempre banalizzando ma giusto per arrivare 00:23:16.134 --> 00:23:18.215 nel concreto: due server riescono a 00:23:18.215 --> 00:23:19.414 gestire bene 200 utenti. 00:23:20.160 --> 00:23:22.400 La politica di scale-up è sufficientemente veloce, 00:23:22.400 --> 00:23:23.519 per cui da due server a 00:23:23.519 --> 00:23:25.440 quattro server riesco a passare in 00:23:25.440 --> 00:23:27.519 un tempo congruo alle "user-journey" del 00:23:27.519 --> 00:23:28.240 mio utente. 00:23:28.559 --> 00:23:30.640 A questo punto, se l'infrastruttura è scalabile, 00:23:30.640 --> 00:23:32.079 diventa un tema, come dicevamo prima, 00:23:32.080 --> 00:23:33.680 numero di clienti, costi. 00:23:33.680 --> 00:23:34.559 Però in questo modo io ho 00:23:34.559 --> 00:23:36.825 la garanzia di essere sicuro, 00:23:36.825 --> 00:23:40.025 di avere un sistema che risponde correttamente. 00:23:40.025 --> 00:23:41.385 Per cui più noi riusciamo ad 00:23:41.385 --> 00:23:42.744 andare a, lasciami dire, 00:23:42.744 --> 00:23:46.585 identificare il gradino base e l'effettiva capienza, 00:23:46.984 --> 00:23:50.105 quanti utenti riesce a soddisfare la 00:23:50.105 --> 00:23:52.960 singola infrastruttura base e quanto vantaggio 00:23:52.960 --> 00:23:54.240 ci dà il delta di un 00:23:54.640 --> 00:23:56.480 gradino di scale-up, più posso andare 00:23:56.480 --> 00:23:57.920 a studiare una risposta. 00:23:57.920 --> 00:23:59.839 Poi questo discorso è molto vincolato 00:23:59.839 --> 00:24:01.200 al picco di traffico. 00:24:01.200 --> 00:24:02.480 C'è anche poi una parte che 00:24:02.480 --> 00:24:03.679 è sul lungo periodo. 00:24:04.005 --> 00:24:06.404 Se prendiamo e-commerce l'attività è puntuale. 00:24:06.484 --> 00:24:08.164 Entro, faccio un mio acquisto, 00:24:08.164 --> 00:24:10.244 esco sostanzialmente o faccio poco altro. 00:24:10.244 --> 00:24:12.244 Se pensate a una soluzione tipo Netflix, 00:24:12.244 --> 00:24:13.765 per esempio, una volta che sono 00:24:13.765 --> 00:24:15.924 entrato - o una piattaforma di qualunque, 00:24:15.924 --> 00:24:19.400 o video, o di conference anche 00:24:19.400 --> 00:24:20.919 - io ho un picco in ingresso, 00:24:21.000 --> 00:24:22.519 posso avere un picco in ingresso, 00:24:22.519 --> 00:24:27.880 pubblicano l'ultima serie più amata, 00:24:27.880 --> 00:24:29.240 ma poi ho anche un long running, 00:24:29.240 --> 00:24:31.720 perché poi quegli utenti permango nell'esperienza 00:24:31.720 --> 00:24:32.840 d'uso all'interno del mio sistema. 00:24:33.285 --> 00:24:35.045 Per cui è articolato e per 00:24:35.045 --> 00:24:36.805 quello dicevo è molto importante la journey. 00:24:36.805 --> 00:24:40.005 Poi la certezza matematica al 100% 00:24:40.005 --> 00:24:41.765 molto spesso non si può avere, 00:24:41.924 --> 00:24:43.365 però sai avere un grado di 00:24:43.365 --> 00:24:44.565 confidenza estremamente alto. 00:24:45.059 --> 00:24:46.340 Sì poi immagino che con il 00:24:46.340 --> 00:24:48.820 tempo potete acquisire dati di quella 00:24:48.820 --> 00:24:51.140 che è la situazione concreta e 00:24:51.140 --> 00:24:53.460 quindi diventa sempre più difficile sbagliare 00:24:53.460 --> 00:24:55.220 ecco da quel punto di vista. 00:24:55.380 --> 00:24:56.580 Assolutamente sì. 00:24:56.580 --> 00:24:58.100 Poi ci sono anche tanti fattori 00:24:58.100 --> 00:24:59.539 ambientali che vanno analizzati. 00:24:59.684 --> 00:25:02.565 Se pensiamo per esempio un salone, 00:25:02.725 --> 00:25:04.164 giusto perché è un caso che 00:25:04.164 --> 00:25:07.445 abbiamo analizzato recentemente, io ho una 00:25:07.445 --> 00:25:09.125 capienza massima della struttura. 00:25:09.125 --> 00:25:10.485 Più di quei biglietti non possono 00:25:10.485 --> 00:25:11.285 essere venduti. 00:25:11.285 --> 00:25:13.525 Posso ragionare sulla simultaneità degli utenti 00:25:13.525 --> 00:25:14.965 e tante volte poi rispetto a 00:25:14.965 --> 00:25:16.539 quella che è l'analisi del massimo 00:25:16.539 --> 00:25:18.779 possibile immaginabile, bisogna andare a ragionare 00:25:18.779 --> 00:25:21.500 sull'esperienza d'uso perché è irrealistico pensare 00:25:21.500 --> 00:25:23.980 che centomila persone entrino allo stadio 00:25:23.980 --> 00:25:25.500 nello stesso istante e nello stesso 00:25:25.500 --> 00:25:26.460 istante aprono l'applicazione. 00:25:26.859 --> 00:25:28.059 Si rischia di fare un calcolo 00:25:28.059 --> 00:25:29.099 eccessivamente ampio. 00:25:29.615 --> 00:25:31.535 Per cui analisi di questo tipo 00:25:31.535 --> 00:25:33.615 e una valutazione di quelli che 00:25:33.615 --> 00:25:36.015 sono gli elementi a contorno dell'utilizzo 00:25:36.575 --> 00:25:38.575 del prodotto ci consente di avere 00:25:38.575 --> 00:25:40.255 una lettura molto precisa. 00:25:40.734 --> 00:25:42.335 Sì, per questo dicevo anche prima 00:25:42.335 --> 00:25:44.460 che potenzialmente i bot, 00:25:44.460 --> 00:25:46.700 in questo senso, possono rappresentare per 00:25:46.700 --> 00:25:48.700 voi una sfida ulteriore se non 00:25:51.339 --> 00:25:54.380 correttamente bloccati perché tutti questi ragionamenti 00:25:54.380 --> 00:25:56.299 che hai fatto non valgono perché, 00:25:56.299 --> 00:25:59.259 come dicevo appunto, non ci sarebbe 00:25:59.259 --> 00:25:59.980 nessun limite. 00:26:00.674 --> 00:26:02.595 Per chiudere quindi ti chiedo quali 00:26:02.595 --> 00:26:04.355 sono i principali errori che vengono 00:26:04.355 --> 00:26:08.754 fatti nei performance test che avete riscontrato. 00:26:09.315 --> 00:26:12.835 Ma probabilmente il primo principe su 00:26:12.835 --> 00:26:15.860 cui siamo trovati a lavorare a 00:26:15.860 --> 00:26:18.259 partire da performance test fatti internamente 00:26:18.259 --> 00:26:19.620 da persone che si sono appena 00:26:19.620 --> 00:26:21.460 affacciate a quel contesto o magari 00:26:21.460 --> 00:26:24.579 realtà più consolidate, è scenari non realistici. 00:26:24.660 --> 00:26:26.460 L'esempio che ti dicevo prima, 00:26:26.460 --> 00:26:28.180 posso avere uno scenario non realistico 00:26:28.180 --> 00:26:30.180 per cui: mediamente al mio salone 00:26:30.180 --> 00:26:32.714 ci sono mille persone all'interno. 00:26:32.955 --> 00:26:34.715 Il giorno di apertura alle 10 00:26:34.715 --> 00:26:36.474 della mattina ce ne sono dieci 00:26:36.474 --> 00:26:38.315 volte tanto, per cui scenari non 00:26:38.315 --> 00:26:39.755 realistici ci sono traffico, 00:26:39.755 --> 00:26:41.275 magari dato su una media che 00:26:41.275 --> 00:26:42.875 considera una finestra troppo lunga, 00:26:42.875 --> 00:26:44.075 non la situazione di picco ma 00:26:44.075 --> 00:26:45.509 magari il numero di utenti nei 00:26:45.509 --> 00:26:49.109 quattro giorni di salone per complessivi 00:26:49.109 --> 00:26:50.630 è una divisione un po' un 00:26:50.630 --> 00:26:51.269 po' forte. 00:26:51.269 --> 00:26:53.509 O scenari non realistici rispetto all'user journey. 00:26:53.670 --> 00:26:54.789 Entro, acquisto un prodotto, 00:26:54.789 --> 00:26:55.029 esco. 00:26:55.029 --> 00:26:57.323 No, tipicamente entro, ne navigo due 00:26:57.323 --> 00:26:59.065 o tre, scelgo quello che mi 00:26:59.065 --> 00:27:00.585 interessa di più, provo le diverse, 00:27:00.585 --> 00:27:02.344 leggo le diverse taglie, 00:27:02.585 --> 00:27:04.825 persisto all'interno della pagina più tempo 00:27:04.825 --> 00:27:06.424 rispetto a quello che è pensato. 00:27:06.585 --> 00:27:08.744 L'altro caso sono ambienti non adeguati. 00:27:08.825 --> 00:27:11.450 L'infrastruttura che tipicamente le aziende hanno 00:27:11.450 --> 00:27:13.529 per fare test, per fare prove, 00:27:13.529 --> 00:27:14.650 per test che non siano di 00:27:14.650 --> 00:27:16.410 carico ma sono test d'utilizzo, 00:27:16.410 --> 00:27:19.130 quindi test o esperienziali o test 00:27:19.450 --> 00:27:22.170 puramente di flusso, in quel caso 00:27:22.170 --> 00:27:24.090 sono scalati verso il basso, 00:27:24.090 --> 00:27:25.529 per cui non è un test attendibile, 00:27:25.785 --> 00:27:27.785 perché mi trovo su un'infrastruttura molto 00:27:27.785 --> 00:27:29.224 scalata verso il basso rispetto a 00:27:29.224 --> 00:27:30.505 quello che sarà quella effettiva. 00:27:30.505 --> 00:27:32.105 L'altro aspetto è il focus sul 00:27:32.105 --> 00:27:33.224 singolo componente. 00:27:33.305 --> 00:27:35.465 La mia infrastruttura l'anno scorso funzionava bene, 00:27:35.465 --> 00:27:37.785 ho aggiunto una funzionalità in più, 00:27:37.785 --> 00:27:38.984 faccio il test di carico solo 00:27:38.984 --> 00:27:40.105 su quella funzionalità in più. 00:27:40.200 --> 00:27:42.759 Bisogna vedere come interagisce il tutto. 00:27:42.759 --> 00:27:43.479 Esattamente. 00:27:43.639 --> 00:27:45.000 L'altro elemento molto importante è la 00:27:45.000 --> 00:27:45.960 mancanza di monitoraggio. 00:27:45.960 --> 00:27:47.240 Ci sono tanti aspetti che devo 00:27:47.240 --> 00:27:48.679 monitorare all'interno del mio sistema. 00:27:48.759 --> 00:27:50.839 Per cui, prendendo il caso base, 00:27:50.839 --> 00:27:52.519 sito web con attaccato un database, 00:27:52.519 --> 00:27:53.319 che è lo scenario un po' 00:27:53.319 --> 00:27:54.519 più semplice, che possiamo andare a vedere. 00:27:54.984 --> 00:27:55.865 Però andare a vedere, 00:27:55.865 --> 00:27:57.304 per esempio, quando io ricerco un 00:27:57.304 --> 00:27:58.744 prodotto dentro il database, 00:27:58.744 --> 00:28:00.424 qual è l'andamento, di RAM, 00:28:00.424 --> 00:28:02.024 di CPU, qual è l'indice, 00:28:02.024 --> 00:28:03.545 quanto lunghe sono le "query", 00:28:03.544 --> 00:28:04.505 quanto si allungano. 00:28:04.505 --> 00:28:04.585 Quindi... 00:28:04.585 --> 00:28:06.664 le query sono le chiamate per 00:28:06.664 --> 00:28:08.024 ottenere il dato dal database, 00:28:08.024 --> 00:28:09.784 perché magari non fosse avvezzo al nome. 00:28:09.930 --> 00:28:12.330 E quindi, monitorare con attenzione tutti 00:28:12.330 --> 00:28:14.970 i componenti dell'infrastruttura, potenzialmente molto complessa, 00:28:14.970 --> 00:28:16.490 è estremamente importante. 00:28:16.890 --> 00:28:18.330 L'altro caso che è quella cosa 00:28:18.330 --> 00:28:21.850 un pochettino che si sta cercando 00:28:21.849 --> 00:28:23.450 di mettere nel test di... 00:28:23.450 --> 00:28:24.970 nei test di performance, 00:28:24.970 --> 00:28:27.714 test di carico, è avere testi discontinui, 00:28:27.714 --> 00:28:29.875 esco quest'anno, ho fatto un test, 00:28:29.875 --> 00:28:33.154 non faccio più indagini sull'efficacia, 00:28:33.154 --> 00:28:34.595 sulle performance del mio sistema, 00:28:34.595 --> 00:28:35.795 faccio un test a fine anno 00:28:36.194 --> 00:28:37.714 in vista della nuova uscita, 00:28:37.875 --> 00:28:39.234 da un Black Friday all'altro, 00:28:39.529 --> 00:28:41.929 mentre se si riescono a mettere continuativi, 00:28:41.929 --> 00:28:43.929 automatici o continuativi nel tempo, 00:28:44.089 --> 00:28:45.929 mano a mano che sviluppo i componenti, 00:28:46.089 --> 00:28:47.690 riesco a indagarli uno per uno 00:28:47.690 --> 00:28:49.210 e garantire delle performance per cui 00:28:49.210 --> 00:28:50.889 mi trovo in prossimità del rilascio 00:28:50.889 --> 00:28:52.569 dove non è il bollino che 00:28:52.569 --> 00:28:54.649 certifica il tuo sistema regge 100 utenti, 00:28:54.734 --> 00:28:57.694 deve essere progressivamente un'infrastruttura dove i 00:28:57.694 --> 00:28:59.054 singoli componenti sono in grado e 00:28:59.054 --> 00:29:00.494 questo è uno degli errori più 00:29:00.494 --> 00:29:02.095 comuni e probabilmente anche una delle 00:29:02.095 --> 00:29:05.694 prospettive più importanti, una delle sfide 00:29:05.694 --> 00:29:07.615 più importanti che ci saranno nei 00:29:07.615 --> 00:29:10.590 prossimi anni, inserirli come altri test 00:29:10.590 --> 00:29:12.589 nel ciclo normale dello sviluppo, 00:29:12.590 --> 00:29:13.630 non con la frequenza magari dei 00:29:13.630 --> 00:29:15.070 test di unità, però con una 00:29:15.070 --> 00:29:16.190 frequenza consistente. 00:29:17.390 --> 00:29:18.109 Perfetto. 00:29:18.110 --> 00:29:20.830 Sì grazie Edoardo perché ci hai 00:29:20.830 --> 00:29:23.214 fatto capire appunto qual è l'importanza 00:29:23.214 --> 00:29:25.375 dei performance test sia da un 00:29:25.375 --> 00:29:27.454 lato per evitare di creare frustrazione 00:29:27.454 --> 00:29:30.174 nell'utente che utilizza un sito web, 00:29:30.174 --> 00:29:31.615 però dall'altro da come mi è 00:29:31.615 --> 00:29:33.214 perso di capire anche per evitare 00:29:33.214 --> 00:29:35.375 un costo eccessivo per una potenza 00:29:35.375 --> 00:29:37.230 di calcolo che non serve a 00:29:37.230 --> 00:29:39.309 niente ecco, o che copre solo 00:29:39.309 --> 00:29:41.789 un singolo picco e basta. 00:29:42.029 --> 00:29:42.909 Alla prossima. 00:29:42.990 --> 00:29:44.029 È stato un piacere. 00:29:44.029 --> 00:29:44.589 Alla prossima. 00:29:53.375 --> 00:29:55.454 E così si conclude questa puntata 00:29:55.454 --> 00:29:57.775 di INSiDER - Dentro la Tecnologia, 00:29:57.775 --> 00:29:59.934 io ringrazio come sempre la redazione 00:29:59.934 --> 00:30:01.775 e in special modo Matteo Gallo 00:30:01.775 --> 00:30:03.775 e Luca Martinelli che ogni sabato 00:30:03.775 --> 00:30:06.095 mattina ci permettono di pubblicare un 00:30:06.095 --> 00:30:07.134 nuovo episodio. 00:30:07.134 --> 00:30:08.850 Per qualsiasi tipo di domanda o 00:30:08.850 --> 00:30:13.410 suggerimento scriveteci a redazione@dentrolatecnologia.it, 00:30:13.490 --> 00:30:16.930 seguiteci su Instagram a @dentrolatecnologia dove 00:30:16.930 --> 00:30:20.210 durante la settimana pubblichiamo notizie e approfondimenti. 00:30:20.210 --> 00:30:22.585 In qualsiasi caso nella descrizione della 00:30:22.585 --> 00:30:24.984 puntata troverete tutti i nostri social. 00:30:24.984 --> 00:30:27.865 Se trovate interessante il podcast condividetelo 00:30:27.865 --> 00:30:29.144 che per noi è un ottimo 00:30:29.144 --> 00:30:30.984 modo per crescere e non dimenticate 00:30:30.984 --> 00:30:32.424 di farci pubblicità. 00:30:32.424 --> 00:30:34.585 Noi ci sentiamo la settimana prossima.