# Salvatore Cordiano > Empathetic Rebel Engineer ### Posts #### A gift for Xmas 2021 Today I want to share with my readers the Ludovico Einaudi Concert playlist. Have a moment to yourself, take an hour to listen to this music, and enjoy. Listen on YouTube Listen on Spotify Happy Xmas 2021! #### Adottare HTTPS Alla luce del numero crescente di problemi di sicurezza informatica e di riservatezza dei dati, sta diventando sempre più importante sostituire HTTP con la versione sicura: HTTPS. Anche se HTTPS esiste da 20 anni, molti siti web servono il traffico sul tradizionale canale HTTP, non sicuro. Agli albori del web, le prestazioni dei server e delle reti sono stati spesso fattori limitanti per l'utilizzo di HTTPS per i siti web. Infatti, il server doveva avere sufficiente potenza computazionale per crittografare e decrittografare i dati e la rete doveva essere in grado di gestire l'attività supplementare (overhead). Molti di questi problemi di prestazioni sono stati ormai superati, il costo di adozione di HTTPS è oggi molto basso tanto che dovremmo cercare di usare ovunque HTTPS. Benefici dell'uso di HTTPS 1. Autenticità delle notizie diffuse Quando si consulta un sito di notizie utilizzando il protoccolo HTTP, il contenuto degli articoli può essere stato alterato da terze parti utilizzando l'attacco man-in-the-middle (MITM). Newstweek mostra come ciò può essere fatto facilmente. 2. Privacy Quando i siti utilizzano il protocollo HTTP, le ricerche effettuate dagli utenti e la cronologia di navigazione sono trasmesse in chiaro. Recentemente l'associazione Freedom of the Press Foundation ha esortato i portali di informazione di passare ad HTTPS. Quando i siti utilizzano HTTPS, i proxy e l'infratruttura di rete non possono facilmente ispezionare il traffico e bloccarlo in base al contenuto. Alcune entità possono forzare o aggirare il protocollo Transport Layer Security (TLS) oppure rubare i certificati TLS. Tuttavia, l'implementazione di HTTPS accresce significativamente la sicurezza in termini di privacy. 3. Sicurezza Quando i siti utilizzano il protocollo HTTP, i cookie che consentono di tenere traccia della sessione utente possono essere intercettati (poichè scambiati in chiaro con il server) ed usati da altri per replicare la sessione utente attiva. Ció è stato dimostrato utilizzando il plugin per Firefox Firesheep. L'uso di HTTPS impedisce la maggior parte degli attacchi MITM, riducendo il livello di vulnerabilità. 4. Migliore posizionamento sui motori di ricerca I motori di ricerca considerano HTTPS come un fattore nel posizionamento nei risultati di ricerca. L’annuncio di Google è un esempio di ció. 5. Informazioni più complete sugli Analytics Quando un utente proveniente da una pagina navigata in HTTPS approda su una pagina HTTP il riferimento alla pagina di provenienza (referral) viene perso. Ció significa che i referral dai siti sicuri, compreso Google in HTTPS, vengono persi per i siti che utilizzano HTTP. 6. Migliore esperienza utente Quando si usa HTTPS, login, registrazione e altre funzionalità e-commerce possono avvenire ovunque nel sito, senza dover portare l'utente su un sito HTTPS diverso. 7. Integrazioni con terze parti Un numero sempre crescente di software e servizi di terze parti richiede HTTPS per usare i propri servizi (ad esempio Facebook per le app). 8. Usando tecnologie in fase di sviluppo I protocoli SPDY e HTTP2, ServiceWorker ed altre nuove tecnologie sono state progettate per lavorare meglio con i siti HTTPS. Anche se ancora essi non sono diventati di uso corrente, adottando HTTPS sarà più facile poterli implementare. 9. Miglioramenti correlati Sostituendo con successo HTTP con HTTPS per un intero sito web, permette di scoprire una quantità significativa di technical debt (magagne nel codice), come ad esempio URL hard-coded. Le sfide Per passare con successo a HTTPS, tutte le richieste alle risorse di pagina devono essere effettuate su un canale sicuro. E' una sfida scoraggiante, e ci sono un sacco di parti da cambiare. Dobbiamo considerare le risorse che attualmente vengono caricate da domini non sicuri e ogni cosa dai JavaScript alle risorse degli advertisement. Se le risorse per un advertisement non possono essere servite su canale HTTPS, la pubblicità probabilmente non sarà mostrata sulla pagina, con conseguenze dirette sulle entrate. Può risultare difficoltoso determinare se ogni adv sarà caricato su HTTPS. Considerando l'importanza degli advertisement, questo è molto probabile che sia un ostacolo significativo per l'implementazione di HTTPS. Mente alcune piattaforme pubblicitarie, compreso Google Double Click for Publishers (DFP), supportano il caricamento degli adv in HTTPS, ci sono ancora un certo numero di reti pubblicitarie che potrebbero non essere compatibili con HTTPS. A parte la pubblicitià, le organizzazioni possono affrontare altri ostacoli nell'implementazione di HTTPS. Il supporto per soluzioni moderne, come HSTS, vale la pena di essere considerato. Invito all'azione Se gestisci un sito di notizie, oppure un qualsiasi altro sito, ci piacerebbe lanciare una sfida amichevole. Impegnarsi a rendere il proprio sito completamente HTTPS entro la fine del 2015 e promettere il proprio sostegno con l'hashtag #https2015. Questo articolo è una traduzione in lingua italiana di Embracing HTTPS, articolo a cura di Eitan Konigsburg, Rajiv Pant e Elena Kvochko (Open Blogs, The New York Times) #### App Transport Security (ATS) e Amazon S3: un matrimonio che non s'ha da fare Nella scorsa settimana ci siamo trovati con Giuseppe a scontrarci nuovamente con App Transport Security, una delle nuove feature di iOS 9. Avevamo già letto la documentazione tecnica e verificato che tutti i certificati SSL delle app in produzione fossero ATS compliant. Fin qui tutto liscio. L'integrazione con un nuova REST API, che restituisce URL di contenuti multimediali ospitati da S3, ci ha però portati ad un'inattesa sorpresa: Amazon Simple Storage Service (S3) non è ATS compliant poichè non rispetta i requisiti imposti da Apple. Strano ma vero, nonostante il certificato SSL sia stato emesso da VeriSign, esso fa uso di SHA1 come signature algorithm, invece del richiesto SHA2. Dell'importanza e dei vantaggi nell'uso di HTTPS ne avevo già parlato nell'articolo Adottare HTTPS. La riflessione da fare - a questo punto - è la seguente: è possibile che a distanza di un mese dal rilascio ufficiale di iOS 9 Amazon non si sia già messa in regola con i requisiti di Apple? Ad oggi sicuramente no, staremo a vedere. Intanto, grazie al ben fare di Apple, con iOS 9 circa il 60% delle applicazioni sullo store non funzionano (fonte: Gruppo iOS Developer su LinkedIn). Cosa ne pensate? #### Arriva Yo Status in beta privata Vi ricordate Yo? Si, intendo proprio l'app Yo, quella che consente di inviare ai propri amici uno «yo» oppure ricevere lo stesso messaggio. «Yo» è un modo tutto americano per dire grande, evvai, pollice in su, etc. Dalla sua pubblicazione (l'1 aprile 2014, non è uno scherzo!) il progetto si è evoluto affiancando al semplice messaggio testuale preconfezionato la possibilità di inviare una foto, la propria posizione su mappa, creare gruppi, accedere ad una serie di applicazioni dello Yo Store, per non parlare della public API. Oggi sono stato invitato a partecipare al beta test di Yo Status (applicazione + API), il nuovo prodotto della Life Before Us, LLC. Yo Status nasce con lo scopo di consentire all'utente di condividere con gli amici il proprio stato d'animo attraverso un singolo emoji. Yo Status su TestFlight Yo Status' main screen Yo Status iOS widget Proprio come il prodotto fratello Yo, con cui condivide l'autenticazione, Yo Status mette già a disposizione un'open API. Yo ha già avuto più di 3 mln di download, chissà quanti ne avrà Yo Status?! Ecco qualche link per chi interessato ad approfondire: Il mio Yo Status http://www.yostat.us/parallel/ L'estensione per Google Chrome https://chrome.google.com/webstore/detail/yo-status/megphakcmhkbapiigancichadbenlgce Il wrapper PHP per l'API https://github.com/salvatorecordiano/yo-status-php Il widget WordPress https://github.com/salvatorecordiano/yo-status-wordpress-widget Per partecipare alla fase di beta testing https://yoapp.typeform.com/to/RNB0qb #### Aruba: i Cloud Server Smart costano meno all'estero Ieri, quasi per sbaglio, sono andato a finire sul sito internazionale di Aruba Cloud ed ho subito notato qualcosa di diverso dal sito italiano: il prezzo dei server smart è drasticamente ridotto rispetto a quello praticato sul portale italiano almeno del 50%. Pensavo si trattasse di un'offerta limitata, invece osservando anche i listini di Francia e Spagna ho scoperto che conviene effettuare l'acquisto dei server smart "da fuori Italia". I Cloud Server Smart sono server VPS basati su tecnologia VMware e con a bordo storage SSD, disponibili in quattro diverse configurazioni preconfezionate. Ecco il raffronto dei prezzi: Cloud Server Smart Italia International Taglia S 4,99 1,00 Taglia M 12,99 6,50 Taglia L 24,99 12,50 Taglia XL 49,99 25,00 Davvero interessante il prezzo della taglia S che consente con meno di 15 euro all'anno di possedere un VPS con 1 vCPU, 1 GB di vRAM, 20 Gb di disco SSD, 2 Tb di traffico dati mensile. Non credo ci siano grossi problemi ad attivare un account per un cittadino italiano. Nei prossimi giorni aggiornerò questo post al riguardo. Aggiornamento del 21/04/2014: Aruba ha sospeso il mio account poichè ritenuto sospetto. Attendono di ricevere un documento di riconoscimento. Aggiornamento del 22/04/2014: L'account è stato attivato dopo la verifica del documento inviato. #### Che cosa sono i microservizi? Contesto Dagli anni ‘90 il modello multi-strato (multi-tier architecture) è stato considerato un pattern architetturale fondamentale per costruire un sistema software. Secondo tale modello le varie funzionalità software sono logicamente separate su più strati che comunicano tra di loro. Ogni strato comunica con gli strati adiacenti in modo diretto richiedendo ed offrendo servizi. In effetti in questa architettura il sistema software, sia pure se logicamente suddiviso in strati, risulta essere un unico sistema monolitico. L’avvento e la diffusione del cloud computing, le pratiche di continuous delivery, l’approccio alla gestione della complessità del software basato sul DDD (Domain-Driven Design), l’organizzazione agile delle aziende in team di sviluppo piccoli ed autonomi (3-7 persone) sono il contesto in cui è emerso il modello dell’architettura a microservizi. Che cosa sono i microservizi? In breve i microservizi sono dei servizi “piccoli” ed autonomi che interagiscono tra di loro e che hanno come finalità quella di fare una cosa e di farla bene; sono a tutti gli effetti dei sistemi distribuiti. Per dare una definizione più precisa possiamo riprendere le parole di Martin Fowler che afferma: Lo stile architetturale a microservizi è un approccio allo sviluppo di una singola applicazione come insieme di piccoli servizi, ciascuno dei quali viene eseguito da un proprio processo e comunica con un meccanismo snello, spesso una HTTP API. Ma quanto devono essere piccoli i microservizi? Non è facile rispondere a questa domanda. Infatti non è possibile fornire una risposta, ad esempio, in termini di numero di righe di codice che definiscono la giusta taglia: alcuni linguaggi di programmazione sono più concisi di altri, riuscendo ad esprimere molto senza essere verbosi, per non parlare poi di librerie e dipendenze o della complessità del dominio del software in oggetto. Secondo Jon Eaves, famoso autore di testi del mondo Java, un microservizio deve essere tale da poter essere riscritto in due settimane. Ovviamente va considerato che tale risposta ha validità nel contesto lavorativo di Real Estate Australia dove Eaves lavora. In sostanza la taglia corretta deve essere identificata in accordo alla struttura organizzativa aziendale. Teniamo sempre in mente che man mano che la dimensione di un servizio decresce, aumentano i benefici relativi all’indipendenza tra le parti, ma cresce anche la complessità di gestire un numero elevato di parti. Autonomia Ogni microservizio è un’entità separata che viene generalmente pubblicata su una piattaforma PaaS oppure eseguita da uno processo di sistema ad hoc. La comunicazione tra i servizi avviene attraverso la rete al fine di garantire l’indipendenza tra i servizi ed evitare ogni forma di accoppiamento. Ogni microservizio si propone all’esterno come una black-box, infatti espone solo un Application Programming Interface (API), astraendo rispetto al dettaglio di come le funzionalità sono implementate e dallo specifico linguaggio o tecnologia utilizzati. Ciò mira a far si che il cambiamento di ciascun microservizio non abbia impatto sugli altri. Vantaggi L’utilizzo dell’architettura a microservizi ha indubbiamente dei vantaggi: Velocizzare i tempi di rilascio del software e reagire velocemente alle esigenze del mercato In generale, nell’architettura a microservizi, ogni singolo servizio è autonomo rispetto agli altri, di coseguenza può raggiungere l’ambiente di produzione in modo indipendente dagli altri, senza che tale attività abbia effetti drammatici sul resto del sistema. Disporre di un processo di deployment snello e veloce consente di poter aggiungere o modificare funzionalità di un sistema software in modo efficace ed efficiente, rispondendo alle necessità di mercato e utenti sempre più esigenti. Sperimentare più facilmente nuove tecnologie Molto spesso, la principale barriera per adottare una nuova tecnologia risiede nel rischio associato all’utilizzo di qualcosa di nuovo e con il quale si ha poca esperienza. Confinando questo rischio ad una piccola porzione di un sistema software, che è possibile riscrivere in appena due settimane di lavoro, il rischio risulta molto contenuto e quindi è una sfida da accettare. Migliori performance grazie all’utilizzo di tecnologie ad hoc L’utilizzo di linguaggi e tecnologie eterogenee consente di poter utilizzare gli stack più performanti per implementare specifiche funzionalità: ad esempio è possibile introdurre una particolare tipologia di base dati che risulta naturale per mappare un determinato dato, oppure eseguire un calcolo in un modo particolarmente efficiente. Resilienza In un’architettura a microservizi, quando una componente non funziona non è automatico che tutto il sistema software smetta di funzionare. In molti casi è possibile isolare il problema ed intervenire mentre il resto del sistema continua a funzionare, cosa non possibile in un’architettura monolitica. Va però sottolineato che l’architettura a microservizi, essendo un insieme di sistemi distribuiti, espone ad una nuova fonte di problemi legati ai disservizi di rete. Scalabilità In generale risulta molto più semplice ed economico scalare un microservizio rispetto ad un sistema software monolitico di grandi dimensioni. Il modello a microservizi consente di poter effettuare provisioning delle parti del sistema software in modo dinamico ed intelligente. Facilità di deployment Modificare poche righe di codice su un sistema software monolitico di grandi dimensioni ed effettuarne il deploy è generalmente un’attività non banale, che espone a rischi significativi considerando anche l’impatto che tali modifiche possono avere. Questa paura generalmente porta a raccogliere un certo numero di modifiche prima di avviare un’attività così onerosa e rischiosa. Con l’approccio a microservizi ogni singolo servizio può raggiungere l’ambiente di produzione in modo indipendente, sicché se si verifica un problema esso è facilmente isolato e possono essere intraprese azioni di rollback più velocemente. Componibilità Tra le opportunità più interessanti dell’architettura a microservizi vi è la possibilità di riusare le funzionalità. Infatti è possibile che una stesso servizio venga utilizzato in modi differenti e per scopi diversi. Si pensi ad esempio ad un sistema software che deve poter dialogare non solo col mondo web ma anche con applicazioni mobile, dispositivi wearable, etc. Sostituibilità Quando un sistema software è organizzato a microservizi, il costo di sostituire un servizio con un altro più efficiente e migliore è limitato a circa due settimane di sviluppo, così come banale è il costo di rimuovere un servizio inutile. Svantaggi Da quanto fin qui trattato, potrebbe sembrare che l’architettura a microservizi risulti essere la manna dal cielo, non è così. Infatti non possiamo dimenticare di ribadire che utilizzare tanti servizi che dialogano tra di loro attraverso la rete, vuol dire di fatto avere a che fare con un sistema distribuito, con tutti i problemi dal caso. Si pensi, ad esempio, a cosa vuol dire autenticare un utente su un’architettura distribuita volendo garantire il single sign-on, oppure a come gestire la mutua autenticazione tra i servizi che compongono il sistema software. E ancora: cosa vuol dire testare un sistema software di questo tipo? Infine, vengono fuori altre tematiche tipiche dei sistemi distribuiti come la gestione di situazioni in cui è necessario che il sistema software sia in grado di riconfigurarsi al volo quando una nuova istanza di un servizio viene creata e il resto della rete può automaticamente trovare essa ed iniziare a comunicare con essa. Questo processo è chiamato service discovery. Bibliografia Appunti della CloudConf 2015 di Torino Building Microservices, Sam Newman, O’Relly Micro services, what even are they? Jon Eaves http://techblog.realestate.com.au/micro-services-what-even-are-they/ Microservices, Martin Fowler http://martinfowler.com/articles/microservices.html Road to Microservices, Salvatore Cordiano http://www.slideshare.net/parallelit/road-to-microservices About Microservices, Salvatore Cordiano http://www.slideshare.net/parallelit/about-microservices #### Checklist per validare gli OKRs Ho conosciuto e iniziato ad apprezzare la validità di OKRs nel dicembre 2019 grazie al mio lavoro. OKRs è l'acronimo di Objectives and Key Results. E' una metodologia che supporta le organizzazioni per creare un chiaro e ben definito allineamento tra obiettivi e risultati da raggiungere. Su cosa sono e perché usare OKRs ho scritto un articolo l'estate scorsa. Al termine di un anno in cui ho iniziato a prendere confidenza con OKRs nel lavoro, sperimentando anche in altri momenti non professionali (organizzazione di un meeting, la stesura di un documento e perfino per le vacanze estive), ho costruito una checklist di domande che mi pongo dopo avere terminato una proposta di OKRs. Spero che questa checklist di validazione "formale" possa essere un buon punto di partenza con cui rivedere, in modo critico, la definizione degli obiettivi e dei risultati chiave. Sugli obiettivi: L'obiettivo è qualitativo? L'obiettivo è sufficientemente ambizioso? L'obiettivo è motivante? L'obiettivo è vincolato da scadenza? L’obiettivo ha almeno 2 key results e non più di 5? L’obiettivo si può considerare raggiunto quando tutti i suoi key results sono soddisfatti? L'obiettivo è definito senza dettagliare i sistemi, i progetti e/o le iniziative su cui il team lavorerà? L’obiettivo rispetta la cultura aziendale? L’obiettivo è scritto in modo semplice ed è facile da ricordare? Riguardando nel complesso tutti gli OKRs: Gli obiettivi definiti sono almeno 3 e non più di 5? Ci sono connessioni con gli obiettivi della tua organizzazione (top-down)? Ci sono obiettivi specifici proposti dal Team (bottom-up)? Sui risultati chiave: Il key result ha un numero? In altre parole il key result è quantitativo e misurabile? Il key result sta misurando un risultato e non l’effort? Il key result esprime una metrica di successo e non suggerisce cosa bisogna fare Il key result è un outcome? Un outcome è una misura del cambiamento del comportamento dell'utente/cliente Il key result indica il target e la baseline? Il key result è self-contained? In altre parole nella definizione del KR c’è scritto tutto ciò che serve per la sua misurazione? Il key result è time bound? Il key result è il componente di una metrica che produce valore per l’azienda? Valore è diverso da fatturato e EBITDA. Cosa ne pensi? Quali domande ti poni al termine della definizione dei tuoi OKRs? Fammelo sapere nei commenti. Bibliografia John Doerr, Measure What Matters, PENGUIN Business, 2018 Felipe Castro, The Beginner's Guide to OKR Jeff Gothelf, Using OKRs to win at work and in life #### Collegare un canale Telegram ad un feed RSS In questo post vedremo come alimentare automaticamente un canale Telegram con i post pubblicati su un blog WordPress, Joomla, Drupal o qualunque altro CMS che metta a disposizione un feed RSS. Questo articolo è stato pubblicato ad agosto 2016, ma è stato aggiornato il 13 aprile 2020. Per iniziare definiziamo gli step che seguiremo: Creazione account IFTTT Configurazione bot Telegram di IFTTT Creazione canale Telegram Rendere il bot di IFTTT amministratore del canale Telegram Configurazione della ricetta IFTTT Creazione account IFTTT Prima di creare l'account IFTTT cerchiamo di capire cos'è IFTTT. IFTTT è l'acronimo di "If This Then That" che potremmo tradurre liberamente in italiano: "se accade questo allora fai quello". E' un servizio web che consente di eseguire delle azioni automatiche (that) al verificarsi di eventi (this). La coppia evento scatenante ed azione viene chiamata ricetta. Nel nostro caso l'evento scatenante è la pubblicazione di un articolo (quindi un nuovo elemento nel feed RSS) e l'azione da eseguire è la pubblicazione di un aggiornamento su canale Telegram. Procediamo con la registrazione dal sito ifttt.com facendo click sul link sign up. Apparirà la seguente schermata Facciamo click sulla voce in basso "sign up" se vogliamo procedere con la registrazione con email e password, altrimenti possiamo utilizzare la registrazione con account Apple, Google o Facebook. Nella schermata che ci appare viene richiesto l'inserimento dell'indirizzo email e della password. Inseriamo i dati e facciamo click sul bottone "Sign up". La registrazione è terminata. Configurazione bot Telegram di IFTTT Facciamo click sul bottone "Explore" in alto a destra. Apparirà una pagina come quella di seguito riportata. Inseriamo nella barra di ricerca "Search" la parola "telegram". Facciamo click sulla barra "Services" e poi sull'icona blu di Telegram. Apparirà la seguente pagina. Per proseguire dobbiamo collegare il nostro account Telegram ad IFTTT. Ci sono due modi per procedere. Il primo è quello di navigare IFTTT sul proprio telefono dove è installata l'applicazione di Telegram. Autenticarsi con IFTTT e fare click sul bottone "Connect" da mobile. Oppure possiamo accedere a Telegram dal client web all'indirizzo https://web.telegram.org e fare click sul bottone "Connect". Visualizzeremo un pagina come quella più avanti. Facciamo click su "OPEN IN WEB". Vedremo una schermata come quella mostrata qui sotto. Facciamo click su "START" e poi sul bottone "Authorize IFTTT". Se tutto è andato bene, ritorneremo sulla pagina di partenza e il bottone "Connect" non è più presente, invece in alto a destra appare un nuovo bottone "Settings". Procediamo con il prossimo step. Creazione canale Telegram Il procedimento che segue è riferito all'utilizzo di Telegram su un dispositivo iOS. Andiamo sulla finestra delle chat e facciamo tap sul bottone nuovo messaggio. Nella schermata che appare facciamo tap su nuovo canale. Inseriamo il nome e la descrizione del canale, impostiamo una foto e facciamo tap su successivo. A questo punto scegliamo la tipologia di canale in pubblico e impostiamo lo URL del canale nel formato t.me/{nomescelto}, ad esempio t.me/salvatorecordiano. Facciamo tap su successivo, Telegram ci invita ad invitare persone al canale, possiamo fare tap direttamente su successivo per saltare questo step. Il canale è stato creato. Rendere il bot di IFTTT amministratore del canale Telegram Per consentire al bot di IFTTT di pubblicare automaticamente contenuti sul canale è necessario renderlo amministratore, esattamente come se si trattasse di un utente. Entriamo nel canale appena creato dall'applicazione mobile. Facciamo tap sull'immagine che rappresenta il canale. Facciamo tap su Amministratori. Poi facciamo tap su aggiungi amministratore. Nella schermata di ricerca inseriamo il nome del bot IFTTT. Facciamo tap su Fatto. Se tutto è andato bene troveremo IFTTT nell'elenco degli amministratori. Configurazione della ricetta IFTTT Torniamo su IFTTT.com e facciamo click su "Create" nel menu, come mostrato nello screenshot seguente. Apparirà questa pagina. A questo punto dobbiamo definire il this, cioè l'evento scatenante del nostro recipe. Facciamo click su this. Inseriamo nella casella "Search" la parola "feed" e selezioniamo l'icona arancione "RSS Feed". Facciamo click su "Connect". Selezioniamo la voce "New feed item". Inseriamo adesso lo URL del nostro feed RSS che IFTTT controllerà periodicamente alla ricerca di un nuovo elemento pubblicato. Per proseguire facciamo click sul bottone "Create trigger". Abbiamo configurare il this ora è il momento di configurare il that. Facciamo click su that. Scriviamo nella casella di ricerca "telegram" e facciamo click sull'icona blu di "Telegram". Facciamo click su "Send message". Ci apparirà una schermata come quella riportata sotto. Scegliamo alla voce "Target chat" il canale Telegram che abbiamo creato in precedenza. A questo punto clicchiamo sul bottone "Create action" in fondo alla pagina. Infine facciamo click su "Finish". Il tutorial è terminato. Non ci rimane che attendere la pubblicazione di un nuovo contenuto per ricevere la notifica sul canale Telegram. #### Come richiedere il numero telefonico ad utente Telegram da un bot Uno dei motivi per cui trovo estremamente pratico Telegram rispetto ai suoi rivali sta nel fatto che è possibile entrare in contatto con altri utenti conoscendo soltanto il loro username, senza perciò dover richiedere il numero telefonico. Più di un utente mi ha chiesto come fare per ottenere il numero telefonico dell'utente da un bot. Telegram spiega nella propria documentazione come è possibile utilizzare le API per ottenere il numero telefonico dell'utente attraverso l'uso della keyboard. A scanso di equivoci ci tengo a sottolineare che il bot non è in grado di ottenere il numero telefonico dell'utente se non richiedendo esplicitamente all'utente di condividere il proprio numero telefonico. Ho pubblicato un semplicissimo gist qui in cui inviamo un messaggio ad utente e inoltre utilizziamo l'opzione request_contact descritta nella doc. L'immagine accanto riproduce il comportamento del bot. #### Cosa ci insegna "A Philosophy of Software Design" Nei giorni scorsi Andrea ha condiviso con il team una video-intervista davvero interessante: Gergely Orosz (The Pragmatic Engineer) intervista il professor John Ousterhout, autore del libro A Philosophy of Software Design. La trovate qui sotto. https://www.youtube.com/watch?v=lz451zUlF-k Questa intervista ruota attorno a un libro che ha avuto un impatto importante su di me e sul team. Lo abbiamo scoperto durante la pandemia grazie a Iacopo, ed è diventato uno degli appuntamenti più significativi del nostro book club di team. "A Philosophy of Software Design" è uno dei testi fondamentali nella mia crescita come engineer. Ousterhout non offre ricette facili o best practice da applicare in modo meccanico: propone piuttosto un nuovo modo di pensare al codice. Un modo che rende il software più umano, più collaborativo, e soprattutto più duraturo nel tempo. Consiglio questo libro a chiunque scriva codice. Il libro si apre con una frase emblematica: Writing computer software is one of the purest creative activities in the history of the human race Qui sotto trovate un riassunto dell’intervista, buona lettura. Una carriera tra accademia e industria Doing both has actually made me better at both John Ousterhout ha sempre desiderato lavorare sia nel mondo accademico che in quello industriale. Dopo il dottorato, ha seguito il consiglio di iniziare dalla carriera accademica, approdando a Berkeley, dove ha trascorso 14 anni fruttuosi. Tuttavia, col tempo è cresciuta in lui la voglia di costruire software reale e affrontare sfide pratiche, il che lo ha portato a lasciare l’università per tuffarsi nel mondo delle startup nella Silicon Valley. Durante i successivi 14 anni, ha lavorato a Sun Microsystems e ha fondato alcune aziende. Nonostante i risultati fossero solo "moderatamente" soddisfacenti, ha imparato moltissimo. Tuttavia, sentiva che la sua vera passione era insegnare e riflettere sulle fondamenta della progettazione del software. Questo lo ha spinto a tornare nel mondo accademico, accettando una posizione a Stanford. Per Ousterhout, il passaggio continuo tra industria e accademia ha arricchito entrambe le esperienze. L'esposizione a contesti diversi gli ha dato una prospettiva unica, permettendogli di affrontare sia l’insegnamento che la progettazione pratica con maggiore profondità. Le vere differenze tra industria e accademia In academia, if a project doesn't work, you just say "oops" and move on. In a company, you can't do that Nonostante le apparenze, Ousterhout sostiene che lavorare nell’industria, soprattutto in startup, non sia così diverso dall’accademia: in entrambi i casi si lavora in piccoli team su progetti innovativi. Tuttavia, il contesto industriale introduce una varietà di interlocutori – come venditori, investitori e manager – che raramente si incontrano nel mondo accademico. Una differenza sostanziale è nella cultura del fallimento. Nel mondo accademico è accettato che un progetto possa fallire, mentre nel mondo industriale spesso si cerca di “salvare la faccia”, alimentando pressioni e strategie di marketing che a volte sfociano nell’inganno. Questo aspetto è uno dei motivi per cui Ousterhout ha preferito tornare all’università. L’onestà intellettuale e la libertà di dire “non ha funzionato” sono per lui elementi centrali per un lavoro sano e produttivo. Questo contrasta con le dinamiche dell’industria, dove anche gli insuccessi vanno “mascherati” per sopravvivere. Tactical Tornadoes: genio o caos? Tactical tornadoes leave a wave of destruction behind and typically other engineers must clean up the messes Ousterhout introduce il concetto di “tactical tornado”: programmatori incredibilmente rapidi nel consegnare codice, ma che operano in modo esclusivamente tattico, trascurando la qualità a lungo termine. Sono spesso considerati eroi dalle aziende per la loro produttività apparente, ma lasciano dietro di sé un codice difficile da mantenere. La loro figura è diffusa in startup e contesti dove la velocità è più apprezzata della sostenibilità tecnica. Tuttavia, il danno cumulativo generato da queste persone – debito tecnico, mancanza di coerenza architetturale – può avere un costo altissimo per l'organizzazione nel lungo termine. Per Ousterhout, il vero “10x engineer” è colui che crea design puliti e facili da evolvere, anche se scrive meno codice. È una figura strategica, che pensa al futuro del sistema più che alla consegna immediata. L’impatto dell’AI sulla programmazione Software design is going to become more and more important... and it's sad that we don't teach it in our universities at all Con l’esplosione degli strumenti AI e LLM, la scrittura di codice di basso livello sta diventando sempre più automatizzata. Ousterhout osserva che queste tecnologie sono simili ai “tactical tornadoes”: producono codice rapidamente, spesso su richiesta, ma non necessariamente con una buona architettura. Il vero punto interrogativo riguarda la capacità dell’AI di affrontare compiti di progettazione ad alto livello. Secondo Ousterhout, al momento gli strumenti non mostrano capacità significative in questo campo. Per questo, la progettazione software diventerà ancora più centrale nel lavoro degli sviluppatori umani. Purtroppo, sottolinea con rammarico, il design software non viene insegnato sistematicamente nelle università. I corsi si concentrano su linguaggi e strumenti, ma trascurano le competenze necessarie per progettare sistemi complessi, esattamente quelle che l’AI fatica a replicare. Che cos’è davvero il design del software? Decomposition is the most important idea in all of computer science Per Ousterhout, la progettazione software è un problema di decomposizione: prendere un sistema complesso e suddividerlo in componenti più piccoli e indipendenti. Questo processo è al centro di tutta l’informatica, e distingue la progettazione dall’implementazione vera e propria. Con l’evoluzione degli strumenti, oggi è possibile creare applicazioni intere partendo da template o prompt AI. Ma la capacità di decidere come suddividere un sistema rimane una competenza umana. La progettazione non è solo struttura, ma anche empatia per chi dovrà leggere e mantenere il codice. In un mondo in cui l’AI scriverà sempre più codice, Ousterhout crede che il valore degli ingegneri si sposterà verso le decisioni di design. Saper progettare bene diventerà il vero “superpotere” nel software engineering. Oltre TDD e Design Patterns There’s so much more to design than just picking one of a half a dozen patterns Ousterhout riflette sulla diminuzione dell’interesse verso metodologie come il Test-Driven Development (TDD) e i design patterns classici (come quelli del “Gang of Four”). Negli anni 2000, queste pratiche erano molto in voga e considerate fondamentali per una buona progettazione. Tuttavia, oggi sembrano essere diventate meno centrali nel dibattito tecnico. Secondo il professore, TDD non è propriamente una tecnica di design e, anzi, potrebbe ostacolare una buona progettazione perché induce a pensare solo a piccoli passi, senza considerare l’architettura nel suo insieme. I design pattern, invece, rappresentano solo soluzioni prefabbricate per problemi comuni e coprono una minima parte del lavoro di design. La progettazione vera richiede creatività, riflessione sui compromessi, e capacità di astrarre problemi complessi, elementi che vanno ben oltre l’applicazione meccanica di pattern o test. Due strategie per affrontare il design The actual process of design is some combination... an iterative kind of back and forth Quando si inizia a progettare un sistema, esistono due approcci principali: top-down e bottom-up. Nel primo si parte dalla visione globale e si suddivide progressivamente in componenti. Nel secondo, si costruiscono prima elementi locali per poi integrarli. Ousterhout spiega che nessuno dei due approcci funziona da solo: il design è sempre un processo iterativo che alterna visione d’insieme e dettaglio. Il problema è che, spesso, i progettisti inesperti adottano un approccio bottom-up perché più immediato, trascurando l’architettura generale. Questo può portare a soluzioni poco coerenti. Al contrario, un design esclusivamente top-down rischia di non tener conto delle complessità reali che emergono durante lo sviluppo. La verità sta nel mezzo: bisogna essere pronti a sperimentare, sbagliare e correggere. Il buon design nasce da un continuo ciclo di tentativi, feedback e miglioramenti. Come gestire la complessità There are things you can do to eliminate complexity completely... and others where you must hide it La gestione della complessità è al centro della progettazione software. Ousterhout distingue due strategie principali: la prima consiste nell’eliminare del tutto la complessità, ad esempio evitando casi speciali attraverso un design più generale. La seconda, inevitabile in molti casi, consiste nel nascondere la complessità dietro interfacce ben progettate. Non tutta la complessità può essere evitata. Alcuni aspetti sono intrinsecamente complicati, ma è fondamentale che restino isolati in punti precisi del sistema, così da non contaminare il resto del codice. Un buon design deve saper usare entrambe le strategie. Eliminare la complessità dove possibile e modularizzarla altrove permette di costruire sistemi più semplici da capire, evolvere e manutenere. Deep Modules: semplificare nascondendo You want the most functionality you can get for the simplest possible interface Il concetto di “deep module” è centrale nella filosofia di Ousterhout. Un modulo “profondo” ha un’interfaccia semplice ma incapsula molta logica interna, mentre un modulo “superficiale” ha un’interfaccia estesa ma poca sostanza. Il primo è preferibile perché riduce il carico cognitivo per chi lo utilizza. I moduli profondi nascondono la complessità e proteggono gli altri componenti del sistema dai dettagli implementativi. Questo favorisce la coerenza architetturale e migliora la manutenibilità. Un errore comune, secondo Ousterhout, è frammentare eccessivamente il codice – ad esempio spingendosi troppo nella direzione del “Clean Code” – perdendo così la profondità. A volte unire due moduli correlati porta a una struttura più profonda e semplice. Errori: meglio non doverli gestire Every exception you throw is imposing complexity on the users of your class Ousterhout considera la gestione degli errori una delle principali fonti di complessità nei sistemi software. Ogni eccezione introduce un caso speciale che l’utente del modulo deve gestire, aumentando il rischio di bug e difficoltà nella manutenzione. Il suggerimento è cercare di “definire gli errori fuori dall’esistenza”, cioè progettare i moduli in modo che certe condizioni problematiche non possano nemmeno verificarsi. Così, si semplifica il codice e si riducono le possibilità di errore. Attenzione, però: questa filosofia può essere fraintesa. Eliminare gli errori non significa ignorarli. È necessario valutare caso per caso, con empatia verso l’utente del modulo, riducendo al minimo le eccezioni reali e fornendo interfacce robuste e prevedibili. Il valore di ripensare la prima idea Smart people often underperform because they insist on implementing the first idea that comes to mind Un tema ricorrente nei corsi di Ousterhout è l’importanza di non fermarsi alla prima idea. Molti programmatori brillanti si innamorano della propria intuizione iniziale, ma questo li porta a ignorare alternative migliori e a limitare la qualità del design. Progettare due volte – ossia esplorare almeno un’alternativa concreta prima di decidere – non è una perdita di tempo. Anche se si spende solo l’1-2% del tempo totale del progetto a confrontare idee, i benefici in termini di semplicità, chiarezza e stabilità possono essere enormi. Il vero progettista sa fare compromessi, valutare scenari alternativi e scegliere la soluzione che meglio gestisce la complessità. Il design non è un atto istantaneo, ma un processo esplorativo. Documenti di design: la lezione da Uber Durante la sua esperienza a Uber, si è affermata la pratica di scrivere documenti di design prima di implementare un sistema. Questi documenti includevano obiettivi, scelte architetturali, e – cosa fondamentale – una sezione con le alternative considerate. Questo approccio obbligava a confrontare diverse soluzioni prima di impegnarsi su una sola strada. Secondo Ousterhout, questa pratica è perfettamente in linea con l’idea di progettare due volte. Anche se apparentemente richiede più tempo, migliora la qualità delle decisioni, stimola il confronto e previene errori a lungo termine. Nel contesto di un progetto, dedicare anche solo l’1–2% del tempo totale alla valutazione di più alternative può generare un impatto sproporzionatamente positivo sul risultato finale. Empatia: la dote nascosta del buon designer The most important attribute of a really good designer is the ability to change their mindset Per Ousterhout, un buon progettista non deve solo pensare alla funzionalità interna del modulo, ma anche mettersi nei panni dell’utente – che sia un altro sviluppatore o il cliente finale. Questa capacità di cambiare prospettiva è ciò che rende possibile creare interfacce semplici, intuitive e robuste. L’empatia è spesso sottovalutata nell’ingegneria del software, ma è alla base di ogni buon design. Quando si progettano interfacce o API, bisogna evitare di esporre dettagli inutili e offrire un'esperienza prevedibile e coerente. Questa capacità ha valore anche nei contesti sociali: pensare come l’altro riduce incomprensioni, migliora la collaborazione e rende il software più umano. Design Review: il potere della collaborazione When multiple people think about a design, you usually end up with better ideas Le design review sono incontri nei quali un team discute e valuta piani progettuali prima di iniziare a scrivere codice. Ousterhout ne sottolinea il valore, affermando che coinvolgere più menti porta quasi sempre a soluzioni migliori rispetto al lavoro individuale. Durante la sua carriera e nei suoi corsi a Stanford, ha sempre incentivato queste pratiche, seppur con approcci informali. L’importante è evitare la “paralisi da analisi”, trovando il giusto equilibrio tra discussione e azione. Una cultura del confronto aperto, dove si esplorano alternative e si discutono i trade-off, è alla base dei team ad alte prestazioni. Lavagne e idee: la forza della presenza fisica There's something special about in-person just getting your ideas out there Ousterhout celebra l’uso delle lavagne fisiche come strumenti potenti per stimolare la creatività nei team. Nei contesti più innovativi, è comune vedere lavagne ovunque: servono per esprimere idee rapidamente, visualizzare problemi e costruire soluzioni collaborative. Rispetto agli strumenti digitali, le lavagne favoriscono una comunicazione più fluida e istintiva, specie in discussioni complesse dove diagrammi e flussi aiutano a chiarire i concetti. La collaborazione di persona, specialmente durante la fase di ideazione, ha un impatto significativo sulla qualità del design. Anche in un mondo sempre più remoto, questo tipo di interazione resta insostituibile. Discussioni strategiche alla lavagna Everyone's argument goes on the board and the discussion just naturally reaches a point Ousterhout ha sviluppato una tecnica per facilitare le decisioni nei team: durante una riunione, tutte le argomentazioni pro e contro vengono scritte su una lavagna. Ogni partecipante è libero di contribuire, ma nessuno può ripetere punti già espressi. Questo approccio permette di strutturare il confronto, evitando circoli viziosi e discussioni senza fine. Al termine, si effettua un “voto di paglia” (straw poll) per capire quale opzione abbia il consenso maggiore. Sorprendentemente, anche quando le discussioni sembrano molto polarizzate, questo metodo porta spesso a decisioni quasi unanimi. È uno strumento potente per sbloccare team intelligenti e motivati. Il giusto equilibrio tra design e azione Design permeates the entire development process Ousterhout rifiuta l’idea che si debba scegliere tra progettazione anticipata e sviluppo iterativo. Secondo lui, la progettazione dovrebbe essere continua, presente in ogni fase: dalla pianificazione iniziale al debugging finale. Un minimo di design iniziale è fondamentale per orientare lo sviluppo, ma bisogna essere pronti a modificare le scelte man mano che emergono nuovi elementi. È inutile pianificare tutto in anticipo, ma è anche dannoso iniziare a codificare senza una visione. Il segreto sta nell’agilità mentale: partire con un’ipotesi, testarla nel codice, e poi riflettere e adattare. La progettazione non finisce mai. Perché scrivere "A Philosophy of Software Design" Ousterhout ha deciso di scrivere il libro dopo anni di frustrazione nel constatare che nessun corso universitario insegnava veramente la progettazione software. Non strumenti, non processi, ma il pensiero progettuale vero e proprio. Dopo essere tornato a Stanford, ha creato un corso per colmare questo vuoto. Il libro è nato come estensione naturale di quel corso: una raccolta di principi e riflessioni maturate in anni di esperienza sia accademica che industriale. Per l’autore, il design è una delle attività creative più profonde dell’ingegneria, e merita lo stesso livello di attenzione e sistematizzazione della scrittura o della matematica. Le novità della seconda edizione The notion of depth captures the trade-offs and keeps you from going astray Nella seconda edizione del libro, Ousterhout ha ampliato il concetto di “profondità” (depth) per guidare meglio le decisioni di design. Questo principio aiuta a bilanciare la complessità nascosta con la semplicità delle interfacce. Ha anche affrontato critiche e malintesi legati alla sua posizione su metodi brevi e microservizi. Spesso, la spinta verso la frammentazione estrema compromette la chiarezza e aumenta il debito cognitivo. La nuova edizione punta a fornire strumenti concettuali più solidi per evitare approcci troppo estremi, promuovendo un design centrato sulla coerenza e sulla comprensibilità. Il corso a Stanford: imparare come si progetta l corso di Ousterhout a Stanford è costruito sull’idea che il design software possa essere insegnato anche a chi ha appena imparato a programmare. Ispirato ai laboratori di scrittura, il metodo didattico prevede che ogni studente realizzi un progetto, riceva un feedback dettagliato e lo riscriva più volte. Questo processo iterativo permette di interiorizzare i concetti, migliorare concretamente e sviluppare una maggiore consapevolezza progettuale. Il progetto centrale del corso è la realizzazione del protocollo di consenso Raft, articolato in due fasi. Gli studenti iniziano da zero, senza schemi o indicazioni predefinite, affrontando le complessità reali dei sistemi distribuiti. Tutti ricevono una code review personalizzata, con decine di commenti mirati, e sono tenuti a rielaborare il codice sulla base del feedback ricevuto, proprio come accade nei laboratori di scrittura. Questo approccio intensivo e strutturato ha un impatto profondo: gli studenti non solo imparano a scrivere codice, ma acquisiscono un modo di pensare più riflessivo e professionale. Imparano a progettare software con rigore e chiarezza, e spesso portano queste competenze nel mondo del lavoro, dove riescono a distinguersi anche rispetto a colleghi con maggiore esperienza. Conclusioni Nella parte finale dell’intervista, Ousterhout riflette brevemente su alcuni temi a bruciapelo. Quando gli viene chiesto di consigliare libri, ammette che non ci sono molte risorse valide là fuori, ma segnala una lista disponibile sul suo sito web. Esprime anche interesse per il feedback: è sempre aperto a critiche costruttive, perché considera il design un campo ancora in evoluzione. Nessuno ha tutte le risposte, e la comunità degli sviluppatori dovrebbe sentirsi parte di un percorso collettivo di apprendimento. Il messaggio finale è chiaro: più che trasmettere verità assolute, l’obiettivo del suo lavoro – sia nei corsi che nel libro – è stimolare una maggiore consapevolezza. Se più persone iniziano a pensare seriamente al design, la qualità del software globale potrà solo migliorare. #### Creare un Bot Facebook: guida passo passo In un precedente tutorial ho spiegato come creare un bot su Telegram, ora vedremo come fare la stessa cosa sulla piattaforma Facebook utilizzando Messenger Send/Receive API presentata durante F8 2016 Facebook Developer Conference. Questo articolo è stato pubblicato a maggio 2016, ma è stato aggiornato il 7 aprile 2020. Prima di proseguire è necessario evidenziare che, a differenza di Telegram, la disponibilità di un bot accessibile a tutti richiede di superare il processo di approvazione da parte di Facebook. Il superamento di tale step è subordinato al rispetto della policy che è possibile consultare all'indirizzo https://developers.facebook.com/policy/#messengerplatform In questa guida costruiremo un bot dimostrativo che non svolge nessuna azione utile se non quella di ripetere ciò che gli scriviamo. Esso ha lo scopo di farci prendere confidenza con le API di Facebook, ma non è idoneo per poter essere pubblicato. Questa guida è rivolta a chi ha dimestichezza con il linguaggio PHP e dispone di un hosting PHP. L'hosting è uno spazio web dove sono ospitati i file che compongono il tuo sito. Se non disponi di un tuo spazio hosting puoi utilizzare un servizio gratuito tra i tanti disponibili sulla rete. In questo tutorial vedremo utilizzare Hostinger come servizio di hosting gratuito. Se vuoi utilizzare un hosting gratuito e italiano, allora ti consiglio in alternativa a Hostinger il provider Altervista. In questo articolo spiego come attivarlo. Warning dell'1 agosto 2020: Hostinger non consente più di ospitare bot poiché non permessi nei termini e condizioni. Iniziamo! Per prima cosa procediamo alla registrazione su Hostinger all'indirizzo https://it.000webhost.com/. Facciamo click su "Registrati gratis" come mostrato nello screenshot sopra. Apparirà il modulo di registrazione che richiede un indirizzo e-mail valido ed una password. Compilato il modulo facciamo click su "Registrati". Riceveremo una conferma di registrazione via e-mail, come quella riportata di seguito, con un link di conferma da cliccare. Facciamo click su "Verifica email". Dopo il messaggio di conferma apparirà una pagina come quella seguente. Questo step ci consente di creare uno spazio web da dedicare al nostro bot. Compiliamo il nome del progetto e impostiamo una password. Il nome del progetto è importante perchè determina il nome dello spazio web. Nel caso di esempio ho scelto facebook-bot e quindi lo URL a cui sarà raggiungibile lo spazio web sarà di conseguenza https://facebook-bot.000webhostapp.com. Per proseguire scegliamo la terza opzione proposta: "Upload your site". A questo punto apparirà la schermata che riporta i file presenti sull'hosting web appena creato. Facciamo click sulla cartella "public_html" dall'icona a sinistra della pagina. Scarichiamo da questo link gli script PHP necessari per il funzionamento del nostro bot. Carichiamo nella cartella public_html i file: FacebookBot.php index.php webhook.php Per caricare i file facciamo click sul bottone "Upload Files" che si trova in alto a destra. Il bottone è contraddistinto dall'icona di una nuvoletta e una freccia. Apparirà una finestra che consente di selezionare i predetti file dal computer. Facciamo click su "Upload". Se tutto è andato bene navigando l’indirizzo https://facebook-bot.000webhostapp.com dove facebook-bot deve essere sostituito con il nome del progetto scelto in precedenza, apparirà una schermata come quella seguente. L'indirizzo https://facebook-bot.000webhostapp.com ci servirà più avanti ed è lo URL del nostro spazio hosting. Adesso è ora di creare il nostro bot su Facebook. Andiamo su Facebook for developers al link https://developers.facebook.com, dopo esserci autenticati. Il bot è a tutti gli effetti un'applicazione Facebook. Scegliamo la voce "Create App" sul menu "MyApps" in alto a destra. Apparirà la seguente schermata. Impostiamo: Display Name: il nome della nostra applicazione, es. Echo Bot Contact Email: l'indirizzo email di riferimento della nostra applicazione Per completare facciamo click su Create App ID. Apparirà la schermata che segue. Facciamo click su "Set Up" all'interno del box "Messenger". La pagina di setup ci consente di creare una pagina Facebook a cui collegare il nostro bot. E' possibile configurare il bot per una pagina già esistente. Se non siamo in possesso di una pagina Facebook è possibile crearne una come mostrato nella procedura seguente. Il mio consiglio è di creare in ogni caso una pagina Facebook da utilizzare per test, tale pagina dopo essere stata creata può essere resa non pubblica. L'immagine di profilo e il nome della pagina saranno l'identità del bot nelle conversazioni con gli utenti. Per creare una nuova pagina Facebook facciamo click sul bottone "Create New Page" nella sezione "Access Tokens", come mostrato nello screenshot seguente. Scegliamo la tipologia "Business or Brand", impostiamo: Page name: il nome della pagina, es. Echo Bot Test Page Category: la categoria di appartenenza della pagina, es. Entertainment Website Per completare facciamo click su Continue. Facciamo un passo indietro sulla schermata "Access Tokens". Facciamo click su "Add or Remove Pages". Seguiamo le istruzioni mostrate di seguito. Facciamo click su "Continue as...". Selezioniamo la pagina creata in precedenza dalla lista delle nostre pagine. Nel nostro caso selezioniamo "Echo Bot Test Page" e facciamo click su "Next". Nella schermata successiva assicuriamoci che sia su "Yes" l'opzione "Manage and access Page conversations in Messenger" e facciamo click su "Done". Se tutto è andato a buon fine apparirà il seguente messaggio: "You've now linked Echo Bot to Facebook". Il messaggio ci informa che abbiamo collegato il bot alla pagina Facebook con successo. Facendo click su "OK" ritorneremo sulla pagina di configurazione che mostra nella tabella in basso la pagina appena collegata. Il numero al di sotto del nome della pagina "Echo Bot Test Page" è l'id della pagina Facebook. Tale numero va inserito all'interno del file config.php. Modifichiamo il file config.php con un editor di testo. Al suo interno sono presenti le seguenti 4 righe: <?php define('FACEBOOK_PAGE_ID', 'Insert here'); define('FACEBOOK_VALIDATION_TOKEN', 'Insert here'); define('FACEBOOK_PAGE_ACCESS_TOKEN', 'Insert here'); Il testo Insert here in corrispondenza del campo FACEBOOK_PAGE_ID va sostituito con l'id della pagina Facebook. Sostituiamo, inoltre, in corrispondenza di FACEBOOK_VALIDATION_TOKEN il testo Insert here con una stringa casuale, ad esempio 123456. Facciamo click sul bottone "Generate Token". Apparirà una schermata come quella che segue. Spuntiamo l'opzione accanto al testo "I Understand", copiamo il token presente nella casella di testo e facciamo click su "Done". Il token appena copiato andrà incollato nel file config.php al posto del testo Insert here in corrispondenza di FACEBOOK_PAGE_ACCESS_TOKEN. Carichiamo il file config.php utilizzando la funzione "Upload Files" già utilizzata in precedenza sul pannello di gestione file di Hostinger. Ritorniamo sulla pagina Facebook di configurazione del bot sulla sezione "Webhooks" facciamo click sul bottone "Add Callback URL". Impostiamo: Callback URL: https://facebook-bot.000webhostapp.com/webhook.php Verify Token: 123456 Il valore di Callback URL corrisponde allo URL dello spazio hosting individuato all'inizio di questo tutorial a cui abbiamo aggiunto la stringa /webhook.php. Il valore di Verify Token corrisponde al valore impostato sul file config.php in precedenza. Facciamo click su Verify and Save. Se tutto è andato a buon fine visualizzeremo una schermata come quella che segue. Facciamo click su "Add Subscription" e spuntiamo, sulla finestra che ci appare, le voci "messages" e "messaging_postbacks". Facciamo click su "Save". La configurazione del bot è terminata. Non ci rimane che iniziare ad utilizzarlo. Torniamo sulla nostra pagina Facebook e facciamo click su Nuovo Messaggio, impostiamo come destinatario Echo Bot Test Page (il nome della pagina). Iniziamo a scrivere al bot e attendiamo le risposte. Se vuoi approfondire le potenzialità della Facebook Messenger API puoi consultare la documentazione ufficiale qui. #### Creare un Bot Telegram senza hosting Nel 2016 ho scritto una guida per creare un bot Telegram step by step, oggi a distanza di più di 4 anni provo a riproporre un modo alternativo per fare la stessa cosa senza richiedere un servizio di hosting. Anche in questo caso vedremo passo dopo passo come creare bot per Telegram semplicissimo. Il bot non svolge nessuna azione utile se non quella di ripetere ciò che gli scriviamo. Per prima cosa procediamo con la creazione del nostro bot su Telegram. Per procedere alla creazione di  un bot dobbiamo chiedere ad un bot chiamato BotFather di crearlo. Questa operazione può essere effettuata tramite l'applicazione mobile Telegram scrivendo a @BotFather oppure dal client web all'indirizzo https://web.telegram.org. Dopo aver avviato la conversazione digitiamo il comando /newbot e poi rispondiamo ai messaggi del bot. BotFather ci scrive di scegliere il nome del bot: Alright, a new bot. How are we going to call it? Please choose a name for your bot. Rispondiamo: Echo e poi invia. Successivamente BotFather ci chiede di scegliere lo username del bot: Good. Now let's choose a username for your bot. It must be end in "bot". Like this, for example: TetrisBot or tetris_bot. Rispondiamo: echobot e poi invia. Se lo username è disponibile ed è valido il bot ci risponde come segue: Done! Congratulations on your new bot. You will find it at t.me/{YOUR BOT NAME}. You can now add a description, about section and profile picture for your bot, see /help for a list of commands. Use this token to access the HTTP API: {YOUR TOKEN HERE} Keep your token secure and store it safely, it can be used by anyone to control your bot. For a description of the Bot API, see this page: https://core.telegram.org/bots/api I campi {YOUR BOT NAME}, {YOUR TOKEN HERE} saranno opportunamente valorizzati, in particolare il secondo dei due è fondamentale per le fasi successive di configurazione del bot. La fase successiva consiste nella creazione di un account sulla piattaforma Autocode.com che funzionerà da hosting del nostro bot Telegram. Andiamo sul sito autocode.com, apparirà una pagina come quella seguente. Facciamo click su Start building for free. A questo punto apparirà il seguente form. Procediamo con la registrazione inserendo il nostro e-mail address, lo username da associare al nostro account ed una password. Per completare la registrazione facciamo click sul bottone Sign Up FREE. Autocode ci porrà una serie di domande per conoscerci meglio. Al momento qualunque risposta diamo alle domande non ha alcun impatto sul nostro account. L'ultima domanda ci chiede quale tipologia di piano vogliamo usare, noi sceglieremo Basic Free, quindi la versione gratuita. Per proseguire facciamo click su Continue to Autocode. Apparirà la seguente schermata. Facciamo click sul bottone Save in basso a destra. Nel popup che appare ci verrà richiesto di definire il nome del progetto. Inseriamo ad esempio echo-bot e facciamo click su Save new project. L'area mostrata dalla figura seguente è l'editor che contiene il codice di esempio dello script __main__.js. Cancelliamo il contenuto dell'editor e sostituiamolo con il codice contenuto su GitHub qui. Così facendo l'editor apparirà come nella schermata seguente. Facciamo nuovamente click sul bottone Save per salvare le modifiche fatte. Adesso dobbiamo comunicare a Telegram come raggiungere il nostro script Node.js pubblicato su Autocode. Per fare ciò dobbiamo recuperare il deploy url da autocode, che si trova in basso, racchiuso tra parentesi quadre. Come mostrato nell'immagine sopra, il deploy url inizia con https ed è colorato di blu. Proseguiamo con la modifica della stringa dell'indirizzo web che segue, sostituendo {YOUR TOKEN HERE} con il token generato da Bot Father ad inizio guida e {YOUR URL HERE} con il deploy url appena copiato. https://api.telegram.org/bot{YOUR TOKEN HERE}/setWebhook?url={YOUR URL HERE} Per costruire correttamente lo url come mostrato nell'immagine sottostante è necessario sostituire i testi segnaposto {YOUR TOKEN HERE} e {YOUR URL HERE} con i valori ottenuti durante il tutorial. Nell'immagine che segue è mostrato un url ben formato. Copia ed incolla l'url ben formato sulla finestra del tuo browser. Se tutto è andato bene la pagina web mostra il seguente messaggio {"ok":true,"result":true,"description":"Webhook was set"} Altrimenti controlla di aver effettuato le sostituzioni correttamente. Il nostro bot è pronto. Non ci resta che aprire un client Telegram (app o web) ed avviare una chat con il bot cercandolo attraverso lo username scelto in precedenza. #### Creare un Bot Telegram: guida passo passo In questa breve guida vedremo come creare un semplice echo bot su Telegram. Questo articolo è stato pubblicato a gennaio 2016, ma è stato aggiornato il 18 ottobre 2020. Il bot non svolge nessuna azione utile se non quella di ripetere ciò che gli scriviamo. Questa guida è rivolta a chi ha dimestichezza con il linguaggio PHP e dispone di un hosting PHP. L'hosting è uno spazio web dove sono ospitati i file che compongono il tuo sito. Se non disponi di un tuo spazio hosting puoi utilizzare un servizio gratuito tra i tanti disponibili sulla rete. In questo tutorial vedremo utilizzare Hostinger come servizio di hosting gratuito. Warning del 18 ottobre 2020: Hostinger e Altervista non consentono più di ospitare bot poiché non permessi nei termini e condizioni. Ti consiglio di procurarti uno spazio hosting PHP per poter procedere con questo tutorial. Se non disponi di uno spazio hosting PHP puoi seguire la guida Creare un Bot Telegram senza hosting. Iniziamo! Per prima cosa procediamo alla registrazione su Hostinger all'indirizzo https://it.000webhost.com/. Facciamo click su "Registrati gratis" come mostrato nello screenshot sopra. Apparirà il modulo di registrazione che richiede un indirizzo e-mail valido ed una password. Compilato il modulo facciamo click su "Registrati". Riceveremo una conferma di registrazione via e-mail, come quella riportata di seguito, con un link di conferma da cliccare. Facciamo click su "Verifica email". Dopo il messaggio di conferma apparirà una pagina come quella seguente. Questo step ci consente di creare uno spazio web da dedicare al nostro bot. Compiliamo il nome del progetto e impostiamo una password. Il nome del progetto è importante perchè determina il nome dello spazio web. Nel caso di esempio ho scelto telegram-bot e quindi lo URL a cui sarà raggiungibile lo spazio web sarà di conseguenza https://telegram-bot.000webhostapp.com. Per proseguire scegliamo la terza opzione proposta: "Upload your site". A questo punto apparirà la schermata che riporta i file presenti sull'hosting web appena creato. Facciamo click sulla cartella "public_html" dall'icona a sinistra della pagina. Scarichiamo da questo link gli script PHP necessari per il funzionamento del nostro bot. Carichiamo nella cartella public_html i file: index.php webhook.php Per caricare i file facciamo click sul bottone "Upload Files" che si trova in alto a destra. Il bottone è contraddistinto dall'icona di una nuvoletta e una freccia. Apparirà una finestra che consente di selezionare i predetti file dal computer. Facciamo click su "Upload". Se tutto è andato bene navigando l'indirizzo https://telegram-bot.000webhostapp.com dove telegram-bot deve essere sostituito con il nome del progetto scelto in precedenza, apparirà una schermata come quella seguente. Adesso è ora di creare il nostro bot su Telegram. Per procedere alla creazione di  un bot dobbiamo chiedere ad un bot chiamato BotFather di crearlo. Questa operazione può essere effettuata tramite l'applicazione mobile scrivendo a @BotFather oppure dal client web all'indirizzo https://web.telegram.org. Dopo aver aperto la conversazione digitiamo il comando /newbot e poi rispondiamo ai messaggi del bot. BotFather ci scrive di scegliere il nome del bot: Alright, a new bot. How are we going to call it? Please choose a name for your bot. Rispondiamo: Echo e poi invia. Successivamente BotFather ci chiede di scegliere lo username del bot: Good. Now let's choose a username for your bot. It must be end in "bot". Like this, for example: TetrisBot or tetris_bot. Rispondiamo: echobot e poi invia. Se lo username è disponibile ed è valido il bot ci risponde come segue: Done! Congratulations on your new bot. You will find it at t.me/{YOUR BOT NAME}. You can now add a description, about section and profile picture for your bot, see /help for a list of commands. Use this token to access the HTTP API: {YOUR TOKEN HERE} Keep your token secure and store it safely, it can be used by anyone to control your bot. For a description of the Bot API, see this page: https://core.telegram.org/bots/api I campi {YOUR BOT NAME}, {YOUR TOKEN HERE} saranno opportunamente valorizzati, in particolare il secondo dei due è fondamentale per le fasi successive di configurazione del bot. Apriamo il file register.php e individuiamo le seguenti righe: $WEBHOOK_URL = 'https://{PROJECT NAME}.000webhostapp.com/webhook.php'; $BOT_TOKEN = '{TOKEN}'; Sostituiamo {PROJECT NAME} con il nome del progetto creato su Hostinger ad inizio tutorial e {TOKEN} con il token comunicato dal FatherBot. Carichiamo il file register.php utilizzando la funzione "Upload Files" già utilizzata in precedenza sul pannello di gestione file di Hostinger. Adesso visitiamo con un browser lo url https://{PROJECT NAME}.000webhostapp.com/register.php. In questo modo invocheremo lo script register.php che ha lo scopo di comunicare a Telegram l'indirizzo dell'applicazione web che risponderà alle richieste del bot. Se tutto è andato bene la pagina web mostra il seguente messaggio: {"ok":true,"result":true,"description":"Webhook was set"} Rimuoviamo il file register.php dal file manager di Hostinger selezionando il file e poi facendo click sull'icona del cestino "Delete". Il nostro bot è pronto. Non ci resta che aprire un client Telegram (app o web) ed avviare una chat con il bot cercandolo attraverso lo username scelto in precedenza. Se vuoi approfondire come funziona lo script webhook.php, che è il cuore del bot, puoi leggere il codice commentato qui. Se vuoi realizzare un bot che risponde a specifiche richieste testuali, qui trovi un esempio. Se vuoi realizzare un bot che risponde diversamente a seconda del tipo di messaggio (audio, video, etc.) ricevuto, qui trovi una bozza. Se vuoi realizzare un bot che risponde ad ogni messaggio inviandoti un'immagine, qui trovi un esempio. Se vuoi utilizzare la keyboard standard, qui trovi un esempio. Se vuoi utilizzare la inline_keyboard, qui trovi un esempio. #### Daily stand-up meeting Lo stand-up meeting è una delle cerimonie previste dalle metodologie agili come Scrum, che ha un valore estremamente importante nella vita del team di sviluppo. Disclaimer: quelle che seguono sono delle considerazioni personali e sono frutto del lavoro quotidiano all'interno del team di sviluppo. Alcune considerazioni sono generali, altre vengono da Scrum o Kanban, altre probabilmente non sono applicabili oppure sono errate in considerazione della propria organizzazione. L'obiettivo di questo post è quello di fotografare il nostro stand-up. Lo stand-up meeting è un momento di condivisione tra i componenti del team di tecnologia. Il team di tecnologia racconta cosa sta facendo e condivide, in primo luogo con gli altri team members, come sta evolvendo il progetto. Allo stesso tempo è un momento di trasparenza, in cui quindi si descrive come stanno andando le attività prese in carico durante la pianificazione. Al nostro stand-up vi partecipa il Product Owner (PO) e il suo team. Per noi l'ulteriore valore di questa cerimonia è quello di mantenere alto il livello di fiducia tra prodotto e tecnologia, attraverso la condivisione. Lo stand-up meeting si svolge ogni giorno, alla stessa ora (a noi piace farlo prima di pranzo, così da essere tutto il team al completo), nello stesso posto, in piedi e generalmente davanti alla board di team. Ogni partecipante risponde alle seguenti domande: Cosa ho fatto ieri? Cosa ho intenzione di fare oggi? Quali sono i fattori che bloccano, rallentano o mettono a rischio la mia attività? Ci sono modifiche importanti al lavoro pianificato? Qual è il mio livello di confidenza sul raggiungimento dell'obiettivo? Inoltre, è molto utile che in questo momento vengano fuori le richieste di aiuto al team. Penso a piccole e grandi difficoltà che sono normali durante lo sviluppo del software, per le quali l'esperienza di un altro developer può aiutare ad uscire velocemente da un'impasse. Lo stand-up è timeboxed. I libri di Agile dicono che dovrebbe durare dai 5 ai 30 minuti. Credo che in medio stat virtus, per cui la durata ideale è di 15-20 minuti al massimo. E' questo, infatti, il motivo per cui si svolge in piedi. A volte ci si organizza per cronometrare il tempo a disposizione di ogni partecipante, ma non è indispensabile. La cosa importante è che ogni partecipante arrivi dritto al punto del discorso e che la risoluzione di eventuali problemi sia rimandata ad un momento diverso dello stand-up. Lo stand-up ha il compito di evidenziare l'esistenza di situazioni fuori controllo o non previste dalle specifiche. Per rendere sempre nuovo il format dello stand-up è utile cambiare l'ordine degli speech (siamo programmatori e siamo pigri, per fare questo abbiamo scritto un bot su Slack che determina in modo random l'ordine delle presentazioni) e concludere la cerimonia con un tocco di positività (penso ad esempio ad applaudire ad uno sviluppo o rilascio andato bene, etc.). Ai tempi del COVID-19, stiamo facendo gli stand-up in video call e per mantenere il contatto con il resto dell'azienda ci siamo inventati la presenza di una guest star diversa ogni giorno. Anche se lo stand-up è una cerimonia che appartiene totalmente al team di sviluppo, questa cosa non ci dispiace. Domanda 1: Qual è il ruolo del PO nello stand-up meeting? Secondo alcune metodologie agili il Product Owner non dovrebbe prendere parte allo stand-up meeting. Personalmente credo che tenere il PO fuori da un momento di così importante valore non sia una scelta saggia, perché il PO può - ad esempio - intervenire per chiarire le incertezze di una user story e quindi prevenire futuri ritardi. A dirla tutta noi ci siamo anche spinti oltre: il nostro PO non partecipa solo da spettatore, ma partecipa alla pari del team di sviluppo, rispondendo alle domande precedentemente elencate. E' importante però vigilare affinché lo stand-up non venga confuso con un meeting di aggiornamento. L'errore tipico commesso dai PO è quello di dire: "Non è già online?" oppure chiedere: "Questo task quando andrà in produzione?". Questo comportamento non va permesso, perché va nell'ottica del micromanagement. Domanda 2: Qual è il ruolo dello Scrum Master nello stand-up meeting? Per chi fa Scrum come da dottrina, la figura mitologica dello Scrum Master è un must. Nel nostro caso non facciamo né Scum né Kanban e facciamo a meno dello Scrum Master. In Scrum, lo Scrum Master assicura che il team di sviluppo faccia la cerimonia di stand-up ogni giorno, rispetti la durata prevista e risponda alle domande viste prima. Inoltre si fa garante del fatto che non ci siano interventi di disturbo esterni al team di sviluppo, che è l'unico owner dell'evento. #### Debug dei messaggi di update di un bot Telegram Negli ultimi mesi mi è capitato più volte di dover fare debug del messaggio di update JSON-serialized che Telegram invia al webhook del bot o che viene restituito invocando il metodo getUpdates. La documentazione di Telegram è ineccepibile ma - come in molti casi - l'esperienza di utilizzo di un'API ti porta a saltare alcuni step per la voglia di prototipare. Per semplificarmi la vita ho così creato un bot speciale, che consente di fare un var_dump dei messaggi ricevuti. In pratica il bot restituisce in output come messaggio di testo l'update JSON ricevuto. Ecco un esempio: Nell'immagine sopra il bot mostra un update relativo al messaggio testuale "Ciao!". Per interagire con il bot cerca sulla chat Telegram @vardumpbot ed inizia la conversazione. Il bot consente, inoltre, di fare debug dei messaggi ricevuti su canali e gruppi ed è in funzione sul canale @vardump e sul gruppo https://t.me/joinchat/AAAAAER1KNaf6HzUjF0ZNg. Il bot è estremamente semplice da realizzare ed il codice completo è disponibile qui. #### Decadenza agevolazioni "prima casa": cosa fare per non incorrere in sanzioni? Questo è un articolo un po' diverso dai miei soliti post. Ho pensato di scriverlo, per aiutare chi si è trovato nella mia stessa situazione. Per motivi personali, mi sono ritrovato a vendere la mia "prima casa" prima dei 5 anni dall'acquisto e senza riacquistarne un'altra entro i 12 mesi. Mi sono messo alla ricerca della possibilità di "autodenunciarmi" al fine di essere in regola ed evitare di essere sanzionato. Sul web ho trovato tanta confusione: si parla di sanzioni, multe, ravvedimento operoso, F24, etc. In questo post vorrei raccontare quanto ho capito e fatto per essere in regola nei confronti dell'Agenzia delle Entrate, almeno spero! La perdita delle agevolazioni della prima casa può avvenire generalmente per 2 motivi: mancato trasferimento della residenza entro 18 mesi dall'acquisto; vendita dell'immobile "prima casa" prima dei 5 anni dall'acquisto e mancato riacquisto entro l'anno. In entrambi i casi esiste la possibilità di mettersi in regola, regolarizzando l'acquisto come se non si fosse usufruito delle agevolazioni. Per mettersi in regola è necessario presentare un'istanza all'Agenzia delle Entrate per comunicare la decadenza delle agevolazioni e la richiesta di riliquidazione dell'imposta di registro: prima dei 18 mesi per il caso di mancato trasferimento della residenza; prima dei 12 mesi per il caso di mancato riacquisto. Le agevolazioni I ragionamenti proposti, valgono solo quando il venditore dell'immobile è un privato o un'impresa che vende in esenzione IVA. Prima di proseguire, proviamo a capire in cosa consistono brevemente le agevolazioni: imposta di registro proporzionale nella misura del 2%; imposta ipotecaria fissa di 50 euro; imposta catastale fissa di 50 euro. Cosa cambia perdendo le agevolazioni Perdendo le agevolazioni "prima casa" quello che cambia è una differente percentuale dell'imposta di registro che passa dal 2% al 9%, rimangono invariate l'imposta ipotecaria fissa e l'imposta catastale fissa. La base imponibile su cui viene calcolata l'imposta di registro è generalmente il sistema del "prezzo-valore", che corrisponde alla tassazione catastale. Volendo fare due conti, se la rendita catastale dell'abitazione è di euro 500,00 avremo che: Con agevolazioni prima casa (imposta agevolata 2%) valore catastale = rendita catastale x 1,05 x 110 = 500,00 x 1,05 x 110 = 57.750,00 euro imposta di registro = 2% del valore catastale = 2% di 57.750,00 euro = 1.155,00 euro Senza agevolazioni prima casa (imposta ordinaria 9%) valore catastale = rendita catastale x 1,05 x 120 = 500 x 1,05 x 120 = 63.000,00 euro imposta di registro = 9% del valore catastale = 9% di 63.000,00 euro = 5.670,00 euro La differenza tra il valore delle due imposte di registro è: 5.670,00 - 1.155,00 = 4.515,00 euro Nel caso di esempio 4.515,00 corrisponde a quanto dovuto, al netto degli interessi da riconoscere all'Agenzia dell Entrate, a partire dal momento dell'acquisto dell'immobile prima casa. Mettersi in regola Mi sono recato presso l'Ufficio dell'Agenzia delle Entrate di Milano, per presentare l'istanza con cui mettermi in regola. Il consulente mi ha fornito un modulo da compilare per fare istanza di riliquidazione degli interessi che allego qui: Modulo rinuncia agevolazioni "prima casa" È importante: indicare gli estremi di ricontatto sul modulo; allegare una copia del documento di riconoscimento valido; indirizzare l'istanza all'ufficio dove è stato registrato l'atto di acquisto dell'immobile. È possibile inoltrare l'istanza attraverso l'indirizzo e-mail o PEC disponibili sul portale dell'Agenzia delle Entrate. That's all folks! Riferimenti: Agenzia delle Entrate - L'acquisto con i benefici prima casa Agenzia delle Entrate - Risoluzione 112/E Agenzia delle Entrate - Risoluzione n. 105/E #### Domani cinque anni di App Store Sebbene criticato dai sostenitori del mito della “mela marcia”, domani 10 luglio App Store, il sistema per scaricare e acquistare le applicazioni per iPhone, iPod Touch ed iPad, compie 5 anni. Non dimentichiamo che dobbiamo al market dell’azienda di Cupertino la rivoluzione del modello di business legato alla commercializzazione del software. Chi avrebbe mai pensato 10 anni fa che il prezzo medio di un’applicazione software potesse abbassarsi ad 1,5 dollari? Durante questo quinquennio si è parlato tanto di numero di app a catalogo e di numero di download facendo continui confronti col concorrente Google Play Store e non poche sono state le polemiche. Per l’occasione Apple ha già reso gratuito il download di alcune app di successo, ma nella giornata di domani sembrerebbe (Apple non ha ufficializzato nulla) che Timothy Donald Cook e compagni ci sorprenderanno con eleganza ed effetti speciali in adeguato stile Apple. Una cosa è certa, con l’impressionante statistica di 50 mld di applicazioni scaricate, domani App Store si accinge a spegnere le sue prime cinque candeline. That’s all folks! #### E' tutta colpa di PHP OPCache? Di solito cerco di non mischiare il lavoro con quello che scrivo su questo blog, ma questa volta non ho potuto farne a meno. Nelle ultime settimane ho dedicato un po' di tempo a capire il perchè di un problema che riscontriamo a lavoro: dopo ogni deploy in produzione continuiamo a vedere il vecchio codice online per un intervallo di tempo non trascurabile (circa 2 minuti). In particolare, il problema si è intensificato quando siamo migrati al nuovo ambiente di produzione. In prima istanza la colpa è ricaduta su OPCache, l'estensione di PHP che si occupa di conservare in memoria il codice PHP compilato (OPCodes). In realtà - al termine dell'indagine - ho compreso che il vero colpevole andasse ricercato nel mix tra link simbolici e il modo in cui PHP risolve i path. L'articolo è disponibile sul blog di Facile Engineering. Is it all #PHP OPCache's fault? Nice article about realpath_cache issue in deploy by @parallelit from @FacileIt_Engr https://t.co/euiMnOlYym — Enrico Zimuel (@ezimuel) October 5, 2017 Un grazie al mio team leader Luca che mi ha supportato e spronato a studiare l'argomento ed al prezioso lavoro di revisione fatto dalla redazione di Facile.it #### Edo, l'antica Tokyo: come l'acqua e il fuoco ci insegnano a costruire software resiliente Abstract Attraverso la visione del documentario “Alle origini di Tokyo”, il team ha esplorato come la storia di Edo, l’antica Tokyo, offra preziose lezioni per progettare architetture software resilienti. Due forze, l’acqua e il fuoco, hanno plasmato la città e ispirato riflessioni su adattabilità, semplicità, gestione del cambiamento e spirito di comunità. Il percorso, articolato in due incontri, ha evidenziato l’importanza di creare sistemi vivi e modulari, capaci di evolversi senza rompersi, dove il vero valore non risiede solo nella tecnologia, ma nel mindset e nella collaborazione tra le persone. Attraverso Edo, il team ha riscoperto principi fondamentali per costruire software flessibile, robusto e capace di prosperare nel cambiamento. Cosa c’entra la storia di Tokyo con le architetture software? Apparentemente nulla, ma in questo articolo voglio raccontare il percorso che abbiamo intrapreso con il Team per rispondere a questa domanda, partendo dalla visione del documentario “Alle origini di Tokyo” e arrivando a riflessioni preziose per il nostro lavoro quotidiano. L’ispirazione Poco più di un anno fa, in un momento di confronto con Nicola Bonicelli, Software Architect in Facile.it, discutevamo di architetture software e, in particolare, della ricerca di un equilibrio tra semplicità e capacità di adattamento al cambiamento. Nicola, appassionato sia di software che di cultura orientale, mi ha suggerito di guardare due puntate del programma “a.C.d.C.” su Rai Play, intitolate “Alle origini di Tokyo”. Da subito ho riconosciuto il volto di Alessandro Barbero e ho capito che avrei assistito non solo a un documentario affascinante, ma anche a un contenuto di qualità. Purtroppo, ad oggi, entrambe le puntate non risultano più disponibili su RaiPlay. Dopo aver visto le puntate, il confronto con Nicola si è approfondito: ci siamo trovati a riflettere su come la crescita di Edo (l’antica Tokyo) potesse essere un modello sorprendentemente efficace per pensare a sistemi software resilienti e adattivi. Abbiamo deciso di coinvolgere uno dei miei Team in questo viaggio: due meeting prima della pausa estiva, ciascuno dedicato alla visione di una delle due puntate, seguita da una discussione libera. Due puntate, due elementi: acqua e fuoco Le due puntate si concentrano su due forze naturali opposte che hanno modellato Edo: l’acqua e il fuoco. L’acqua, fonte di vita e sviluppo commerciale, è stata sfruttata con intelligenza attraverso un sistema di canali che fungeva sia da difesa che da arteria commerciale. Il fuoco, invece, elemento distruttivo, ha costretto Edo a sviluppare strategie di resilienza e rigenerazione continua, trasformando ogni grande incendio in un’opportunità di crescita. Figura 1 - Un momento della proiezione di "a.C.d.C." Le riflessioni del Team Primo meeting (21 luglio 2023): Edo, città dell’acqua Dal primo incontro sono emersi due filoni principali di riflessione: il mindset e le scelte di design. Sul fronte del mindset, abbiamo osservato come la cultura di Edo mostrasse una straordinaria capacità di vivere il cambiamento in modo collettivo. L’approccio era quello di accogliere il cambiamento come parte naturale della vita, adattandosi insieme agli altri, piuttosto che ostinarsi a mantenere lo status quo. Questa mentalità, molto diversa da quella europea che celebra il genio individuale, si basa invece sull’intelligenza collettiva e sulla forza della comunità. Per quanto riguarda le scelte di design, il sistema dei fossati di Edo rappresenta una metafora potente. A differenza delle mura europee, che difendevano ma anche limitavano la crescita delle città, i fossati di Edo erano flessibili e ampliabili. Questa caratteristica è stata collegata al concetto di architettura software: progettare sistemi troppo rigidi - come i monoliti - può ostacolare l’evoluzione. Meglio, invece, costruire architetture modulari - come i microservizi - capaci di espandersi e adattarsi nel tempo. Figura 2 - Monolite Vs Microservizi Una lezione chiave che abbiamo tratto è l’importanza di “sapere cosa è sufficiente”: un principio che guida scelte pragmatiche e che permette di evitare soluzioni eccessivamente complesse o sovra-ingegnerizzate. Secondo meeting (28 luglio 2023): Edo, città del fuoco Il secondo incontro ha arricchito ulteriormente le nostre riflessioni. Abbiamo compreso che sbagliare fa parte naturale del processo evolutivo. Gli abitanti di Edo non si sono mai demoralizzati di fronte agli incendi devastanti, ma hanno saputo apprendere dai propri errori e migliorare continuamente. Questo atteggiamento ci ha fatto riflettere su quanto sia importante, anche nel nostro lavoro, accettare l’errore come occasione di crescita e non come fallimento. Riconoscerlo non significa attribuire colpe, ma aprire la strada alla correzione e all’apprendimento. Perché ciò avvenga, serve un ambiente che incoraggi la condivisione degli errori e faccia sentire le persone libere di parlarne senza timore. Oggi parliamo di psychological safety. Un altro aspetto emerso è la gestione del transitorio. Il fuoco, in fondo, rappresenta il cambiamento: un evento che mette in discussione lo status quo ma apre anche la possibilità di rinnovamento. I giapponesi erano in grado di ricostruire parti della città mentre la vita quotidiana continuava. Nel nostro mondo, questo si traduce nella capacità di effettuare refactoring senza bloccare il funzionamento dei sistemi: un parallelismo diretto con le pratiche moderne di software engineering, dove il cambiamento avviene “a caldo”, senza fermare la produzione. La mentalità pragmatica e comunitaria di Edo si è dimostrata ancora una volta centrale. L'obiettivo principale non era proteggere ogni singolo edificio, ma salvare le persone e preservare la vitalità della città. È un parallelismo significativo con il modo in cui dovremmo pensare alle soluzioni software: ciò che conta è il beneficio per il sistema nel suo insieme, non per i singoli componenti. In entrambi i casi, non esistono scelte “giuste” in senso assoluto, ma scelte “adatte” al contesto e alle priorità del momento. Durante la discussione è emerso anche un confronto interessante tra Edo e Londra. Dopo il grande incendio, Londra rispose con una regolamentazione stringente sull’uso di materiali non infiammabili, ma questa rigidità contribuì a rallentare la crescita demografica e urbana. Edo, invece, puntò su soluzioni flessibili e comunitarie, che permisero una ripresa più rapida ed efficace. Abbiamo riflettuto sul valore della semplicità: costruzioni leggere, materiali economici, capacità di ricostruire in pochi giorni. Questa semplicità operativa, applicata anche al mondo software, suggerisce di evitare soluzioni troppo complesse che possono ostacolare la manutenzione e l’evoluzione. La preparazione e l’osservabilità sono risultate condizioni fondamentali. Gli abitanti di Edo erano pronti a reagire agli incendi perché sapevano cosa fare. Allo stesso modo, nei sistemi software, la capacità di osservare in tempo reale e di sapere dove intervenire rapidamente fa la differenza tra una crisi gestibile e un disastro. Una delle intuizioni più potenti emerse dai meeting è che “ciò che fa davvero la differenza non si vede”: sono le persone, la mentalità, la capacità di collaborazione. Non basta la tecnologia più avanzata: è il modo in cui viene usata, è il mindset condiviso a determinare il successo. Gli abitanti di Edo affrontavano gli incendi quasi col sorriso: sapevano di essere preparati e, soprattutto, di poter contare gli uni sugli altri per ricostruire. Questa fiducia collettiva ci invita a riflettere su quanto sia importante, anche nel lavoro, creare le condizioni per affrontare serenamente le difficoltà e rendere ogni iterazione davvero sostenibile. Abbiamo anche toccato concetti più tecnici, come il teorema CAP: nei sistemi distribuiti, non è possibile ottenere contemporaneamente consistenza immediata, disponibilità continua e tolleranza alle partizioni. Edo ci insegna che a volte è meglio accettare piccoli compromessi locali - ad esempio una consistenza eventuale - pur di garantire la resilienza e la disponibilità del sistema complessivo. Infine, il tema della velocità di reazione ha trovato una potente analogia nei racconti moderni: ad esempio, la capacità di ricollegare due linee ferroviarie a Tokyo in sole tre ore, grazie a una preparazione minuziosa e a una collaborazione perfetta tra migliaia di persone. Lezioni per il nostro lavoro Il percorso attraverso la storia di Edo ci ha lasciato insegnamenti profondi: L’adattamento è centrale: è necessario progettare con la consapevolezza che il cambiamento è inevitabile e fa parte della natura stessa dei sistemi software. Il senso di comunità è un moltiplicatore di valore: costruire team che collaborano davvero è più importante di qualsiasi tecnologia. Le soluzioni devono essere “sufficienti”, non necessariamente perfette: cercare sempre un equilibrio tra qualità e semplicità. Occorre evitare barriere rigide: progettare architetture capaci di evolvere nel tempo. E’ fondamentale privilegiare il refactoring continuo e l’approccio iterativo rispetto a strategie “big bang”. L'observability è cruciale: sapere cosa sta succedendo è fondamentale per reagire in tempo. La resilienza è una condizione imprescindibile: costruire sistemi capaci di sacrificare parti senza compromettere l’intero è una filosofia vincente. Conclusioni Guardando a Edo e alla sua storia, abbiamo ritrovato un’immagine potente del modo in cui possiamo e dobbiamo pensare le nostre architetture e il nostro lavoro: come sistemi vivi, flessibili, pronti a cambiare senza perdere il sorriso. Ringrazio Nicola per avere ideato insieme questo momento e tutto il Team per l’entusiasmo, la profondità delle riflessioni e la partecipazione. Non è stato solo un esercizio culturale: è stato un autentico momento di crescita professionale e personale. #### Event-driven Serverless Applications con AWS Lambda In un precedente articolo abbiamo visto che cosa sono i microservizi. In questo post cercheremo di fare un passo avanti conoscendo il servizio Lambda di Amazon Web Services (AWS). Prima di parlare di Lambda facciamo però un breve passo indietro. Quando parliamo di cloud computing siamo abituati a pensare subito alle virtual machines (VMs) ed ai containers. Sebbene le differenze tra questi due modi di fare calcolo non siano banali, VMs e containers rappresentano l'ambiente ideale per fare il deployment di architetture software basate su microservizi. In entrambi i casi l'impegno nella gestione dell'infrastruttura (provisioning, scaling, managing OS updates, infrastructure monitoring, etc.) diventa un nostro onere certamente non banale. E' proprio a questo "problema" che prova a dare una soluzione Amazon con Lambda. AWS Lambda consente di eseguire codice senza fare provisioning o doversi occupare della gestione di server. Si paga solo il tempo di calcolo utilizzato e quando il nostro codice non è in esecuzione non paghiamo nulla. Con Lambda chi sviluppa deve esclusivamente preoccuparsi di scrivere il codice e farne l'upload sulla console di gestione AWS. Sarà Lambda ad occuparsi di mettere in piedi tutto il necessario per eseguire, scalare e garantire alta disponibilità alla nostra applicazione. Quando utilizziamo Lambda dobbiamo disegnare ciascun nostro microservizio composto da parti di codice che implementano delle funzionalità. Il codice eseguito su AWS Lambda è chiamato "Lambda function". Ogni Lambda function è indipendente dalle altre, è stateless e non ha alcun legame con l'infrastruttura sottostante, in questo modo è possibile eseguire tante copie di una funzione quante sono necessarie per rispondere alle richieste del momento (scaling). L'esecuzione di una funzione può essere sincrona quando fornisce un risultato oppure asincrona quando scateniamo l'azione senza dover attendere il suo completamento e/o il suo esito. Una Lambda function include il codice da eseguire e alcune informazioni di configurazione tra cui il nome della funzione e le risorse richieste. L'immediato vantaggio di spalmare la business logic di un'applicazione in funzioni, oltre alla già citata scalabilità, è la possibilità di effettuare il deployment delle funzioni in modo totalmente isolato. Una Lambda function può essere invocata direttamente da un'applicazione web, un'applicazione mobile o da un oggetto intelligente (IoT). Oppure può fargli da trigger un altro servizio AWS (ad esempio Amazon S3, Amazon DynamoDB, Amazon SNS, etc.) al verificarsi di un particolare evento (es. l'aggiunta di un record in una DynamoDB Table, la cancellazione di un file in un S3 Bucket, etc.). Il modello proposto da Amazon per Lambda è totalmente event-driven. Utilizzando Lambda ci orientiamo, quindi, verso un modello di event-driven serverless applications. Pensando ad un'applicazione web concepire il modello event-driven è immediato per il front-end, dove il submit di un form può essere un banale esempio di evento. Diverso è, invece, il discorso per il back-end dove ragionare per eventi può apparire meno scontato ma il concetto è in ogni caso facile da afferrare. Attualmente AWS Lambda supporta Java, Node.js e Python, non è richiesto di imparare un nuovo linguaggio per creare le nostre applicazioni. E' evidente in questo elenco la pesante assenza di un linguaggio open-source come PHP, ma sono sicuro che a breve quelli di Amazon si faranno sentire. Amazon offre fondamentalmente tre strade per invocare le funzioni Lambda: la prima è quella di utilizzare lo SDK, disponibile anche per mobile, per farne trigger; la seconda è quella di “mettersi in ascolto” di un evento su un altro servizio AWS; la terza è quella di utilizzare il servizio API Gateway per fare mapping tra una Web API ed una funziona Lambda. Chiudiamo questa introduzione a Lambda accennando al modello di prezzo proposto da Amazon. Il costo viene calcolato in base al numero totale di richieste per tutte le funzioni e in particolare è funzione della durata e della quantità di memoria allocata. Lambda conteggia una richiesta ogni qual volta che viene avviata un'elaborazione in risposta alla notifica di un evento o a una chiamata (invoke). Il primo milione di richieste ogni mese è gratuito. Non ci resta che dare sfogo alla nostra fantasia ed iniziare a sviluppare con AWS Lambda. #### Factory Method e Abstract Factory: differenze e analogie In questo post cercherò di spiegare le differenze e le analogie tra due dei più noti design pattern creazionali: Factory Method e Abstract Factory. Prima di entrare nello specifico di ciascun pattern rinfreschiamo la definizione di design pattern. Un design pattern è una soluzione pronta all'uso e adattabile per specifici problemi applicativi. Quando si parla di un pattern è necessario sempre tenere a mente 4 cose: il nome del pattern; il problema che risolve; la soluzione al problema proposta; l'implementazione. L'esigenza generale a cui mirano i pattern è quella di isolare gli aspetti che cambiano per rispettare il principio open/closed. In breve, seguire il principio open/closed significa essere aperti ai cambiamenti (openness) con l'aggiunta di nuove entità lasciando invariate le entità preesistenti (closeness). Senza voler fare filosofia ciò si traduce nella possibilità di estendere, ovvero modificare, il comportamento di un'entità senza modificare l'entità stessa, quindi non mettendo mano al codice che definisce quella entità. Per fare ciò bisogna sfruttare tutte le opportunità della programmazione agli oggetti, in primis ereditarietà e polimorfismo. Quando parliamo di entità software intendiamo classi, metodi, funzioni, moduli, package, etc. Factory Method Nome: Factory method. Problema: Creare oggetti senza dover specificare la classe esatta dell'oggetto che verrà creato. Soluzione: Di norma la soluzione è rappresentata sui libri in UML, perché è più facile capire tutto dal diagramma delle classi. Nel post trascuro volutamente l'implementazione. Prima di andare avanti facciamo alcune considerazioni: AbstractProduct "is-a" IProduct; ConcreteProduct1 "is-a" AbstractProduct; ConcreteProduct2 "is-a" AbstractProduct; ConcreteProduct1 "is-a" IProduct; ConcreteProduct2 "is-a" IProduct. Ritorniamo al diagramma delle classi di prima e ripuliamolo lasciando solo questi quattro componenti. Possiamo osservare che: IProduct è una interfaccia; AbstractProduct è una classe astratta; ConcreteProduct1 e ConcreteProduct2 sono classi concrete. Nella classe astratta AbstractProduct possiamo iniziare a definire quei comportamenti comuni degli oggetti di tipo IProduct, ma la classe rimane astratta poiché non abbiamo tutti gli elementi per istanziare un oggetto concreto. Ora guardiamo la seconda parte del class diagram iniziale. Client è la classe che ha necessità di avere un oggetto di tipo IProduct e quindi è un’entità che richiede la creazione di un oggetto di tipo IProduct. Il Client è il "creator" ed è una classe astratta perché il Client ha bisogno di un oggetto di tipo IProduct concreto ma non sa quale di preciso. Anziché cablare all'interno del Client la dipendenza con uno specifico prodotto (ConcreteProduct1, ConcreteProduct2, etc.) si estende Client definendo ConcreteCreatorX, il quale sa come e quale specifico oggetto di tipo IProduct deve creare. Ad esempio ConcreteCreator1 crea oggetti di tipo IProduct che sono istanze concrete di ConcreteProduct1. Avrò quindi tanti ConcreteCreatorX per ogni IProduct che voglio utilizzare. In altre parole l'onere di istanziare un particolare oggetto di tipo IProduct viene spostata nell'erede concreto di Client. Questo modo di fare corrisponde alla massima di Erich Gamma: "Program to an interface, not an implementation". Per chi non lo sapesse Erich Gamma insieme a Richard Helm, Ralph Johnson e John Vlissides è uno degli autori del libro: "Design Patterns: Elements of Reusable Object-Oriented Software", una raccolta dei 23 design pattern fondamentali tra cui Factory Method e Abstract Factory. Riepilogando parliamo di factory method quando: Una classe A (Client) non deve conoscere quale classe di un tipo B (IProduct) creare; La sottoclasse di A (ConcreteCreatorX) specifica quale oggetto deve essere creato (ConcreteProductX); La classe padre A (Client) sposta l'onere della creazione alle sue sottoclassi (ConcreteCreatorX). Abstract Factory Nome: Abstract Factory Problema: Creare famiglie di oggetti tra di loro correlate senza dover specificare la classe esatta dell’oggetto che verrà creato Soluzione: Abstract Factory è una generalizzazione del Factory Method. Senza fare giri di parole, guardiamo IFactory e ConcreteFactoryX. IFactory è l'interfaccia che definisce una serie di Factory Method, ciò metodi che costruiscono oggetti. IFactory definisce il concetto di "famiglia" senza specificare di quale famiglia stiamo parlando. ConcreteFactoryX è una famiglia ("is-a" IFactory) perché implementa l'interfaccia IFactory ma è una specifica famiglia, non una in generale. Il Client in questo caso usa un erede di IFactory (quindi ConcreteFactoryX) per ottenere un prodotto di tipo IProductA e un prodotto IProductB. Si noti che IProductA e IProductB non sono classi "parenti" (non hanno un erede in comune, però potrebbero) ma sono semplicemente correlati. Ecco un riepilogo delle differenze tra Factory Method e Abstract Factory. Factory Method Abstract Factory E' un metodo. E' un'interfaccia per creare oggetti correlati. Abstract factory è implementato spesso (non per forza) attraverso factory method. Gli oggetti vengono creati attraverso l'ereditarietà (vertical indirection). Gli oggetti vengono creati attraverso la composizione (horizontal indirection). Crea un solo tipo di oggetto. Crea famiglie di oggetti. Per creare nuovi oggetti dello stesso tipo è sufficiente creare una sottoclasse del Client. Per creare nuovi oggetti della stessa famiglia è necessario ridefinire l'interfaccia di IFactory. Per creare nuove famiglie di oggetti è necessario creare una sottoclasse di IFactory. #### Google cambia il modo di mostrare gli URL su mobile Con un post pubblicato sull'Official Webmaster Central Blog, Google ha annunciato ieri l'aggiornamento dell'algoritmo che mostra le URL nei risultati della ricerca su mobile. Ecco il prima e dopo: Prima Dopo             In pratica si passa dall'URL classico ad un formato breadcrumbs-like ed in particolare: il nome a dominio viene sostituito dal nome del sito (es. www.google.com diventa Google); la struttura dell'URL viene mostrata come breadcrumbs (es. www.google.com/about/company/history diventa About > Company > History). Google ha, inoltre, aggiornato la documentazione sui dati strutturati al fine di consentire di specificare il nome del sito in aggiunta alle già documentate breadcrumbs. La conseguenza immediata di questa scelta di Google, anche se allo stato confinata solo alle ricerche su mobile, è l'elevatissima importanza di avere URL ben strutturate. #### Happy Birthday WordPress Buon compleanno WordPress! Era il 27 maggio del 2003 quando un giovane 29enne, chiamato Matt Mullenweg, annunciava il rilascio della prima versione di WordPress (WP). Da allora sono trascorsi 10 anni, durante i quali WordPress ha fatto tanta strada registrando ben 18 major releases. Nato come piattaforma software di personal publishing, oggi WP è a tutti gli effetti un Content Management System (CMS) che consente la creazione di un sito Internet con contenuti testuali e multimediali, facilmente gestibili ed aggiornabili senza dover conoscere nulla sulla programmazione HTML delle pagine web. WordPress è un progetto Open Source, completamente gratuito, implementato da una community internazionale di developers che mettono a disposizione le loro conoscenze ed il loro know-how come contributo per lo sviluppo di questo software. Ha tra le sue main features l’architettura a plug-in ed il sistema dei temi. Attraverso un plug-in è possibile modificare, personalizzare e migliorare il comportamento del blog; i temi consentono, invece, di adattare la “skin” di WP e di presentarsi graficamente in modo più vicino allo scopo del portale. WordPress è attualmente la più popolare piattaforma di blogging sul web, con oltre 60 milioni di siti web all’attivo (fonte Wikipedia) grazie alle sue caratteristiche di duttilità, stabilità e sicurezza. Secondo Brian Gardner, fondatore di StudioPress, WordPress è “un buon pezzo di software combinato con una grande comunità che permette lo sviluppo di un solido ecosistema in cui tutti vincono”. “Code is Poetry”, buon compleanno WordPress! That’s all folks! #### Hosting PHP gratuito italiano In alcuni tutorial che ho pubblicato su questo blog, faccio uso di un hosting PHP ad esempio per costruire un bot Telegram. Nei tutorial ho mostrato come utilizzare Heroku e poi Hostinger. Adesso vedremo come utilizzare un servizio hosting italiano molto pratico e potente. Sto parlando di Altervista. Warning dell'18 ottobre 2020: Altervista non consente più di ospitare bot poiché non permessi nei termini e condizioni. Ti consiglio di procurarti uno spazio hosting PHP alternativo se userai lo spazio hosting per questo fine. In alternativa puoi seguire la guida Creare un Bot Telegram senza hosting. Per iniziare andiamo all'indirizzo web https://it.altervista.org/. Apparirà una schermata come quella seguente: Facciamo click su "CREA SITO", verremo portati sulla pagina riportata sotto. Altervista ci consiglia di creare un hosting WordPress, ma nel nostro caso vogliamo un hosting da configurare come i veri pro. Facciamo click sul link "Vuoi il solo servizio di hosting?". Scegliamo un indirizzo web per il nostro spazio hosting. Nell'esempio ho scelto mytesthosting. Di conseguenza lo spazio web sarà raggiungibile all'indirizzo http://mytesthosting.altervista.org. Proseguiamo inserendo tutti i dati richiesti: nome, cognome, sesso, anno di nascita, indirizzo email, condizioni d'uso e privacy. Facciamo click su prosegui. Ci apparirà una pagina come quella che segue:  Per proseguire con la registrazione accedi all'indirizzo email inserito nel modulo allo step precedente. Altervista invia una email come quella che segue per confermare l'indirizzo. Facciamo click su primo link presente nell'email. Cliccando sul link ci apparirà una pagina come quella che segue: In pochi istanti il nostro hosting sarà attivo. Facciamo click su prosegui. La schermata che ci appare è la seguente e mostra il pannello di controllo di Altervista. Per rendere il nostro hosting idoneo per i bot Facebook o Telegram è necessario procedere con l'attivazione del servizio HTTPS. Facciamo click sulla voce "RISORSE" posta sul menu in alto e troviamo la sezione HTTPS. Facciamo click su "Attiva HTTPS", ci apparirà la seguente pagina: Facciamo click su "Attiva il servizio HTTPS". Altervista ci chiede di inserire il nostro numero di telefono per verificare l'identità. Compiliamo il numero di telefono e facciamo click su "Procedi con l'identificazione". Riceveremo sul nostro cellulare un codice di verifica da inserire nella casella mostrata nella pagina successiva. Inseriamo il codice di verifica e facciamo click su "Invia". La procedura non è immediata e richiede qualche minuto. Quando il servizio HTTPS sarà attivo, sul pannello di controllo sarà mostrato un blocchetto come quello che segue. Facciamo click sulla voce "APPLICAZIONI" posta sul menu in alto e facciamo click su "Accedi" nel blocchetto "Applicazioni" accanto alla scritta "Gestione file". Ci apparirà una pagina come quella che segue, che consente di fare il caricamento dei file sul nostro spazio hosting. Per caricare un file è necessario fare click su "Invia files" e poi con "Seleziona files" procedere alla scelta dei file da caricare. Il tutorial termina qui. Happy coding! #### HTTP Error 500.50 - URL Rewrite Module Error su IIS [RISOLTO] Questo tutorial descrive come risolvere l'URL Rewrite Module Error (Error 500.50) generato da Internet Information Services (IIS) sui file caricati con uno script di upload PHP. L'errore non si manifesta in fase di upload dei file, ma bensì in fase di consultazione degli stessi con una richiesta HTTP GET. L'errore è dovuto a un problema di permessi, in particolare quando si effettua un upload, IIS scrive il file in una cartella temporanea sulla quale il gruppo utenti IIS_IUSRS non ha i permessi, il file viene successivamente spostato nella cartella di upload desiderata dall'applicazione non ereditando i permessi della web directory. La cartella temporanea usata per l'upload è generalmente C:\Windows\Temp, il percorso è definito nel php.ini alla voce upload_tmp_dir. La soluzione al problema consiste nel dare al gruppo utenti IIS_IUSRS sulla cartella indicata nella chiave upload_tmp_dir il diritto di scrittura, oltre a quello di lettura già presente. Permessi per il gruppo IIS_IUSRS #### Il log è il migliore amico del programmatore Immaginiamo questo scenario: è trascorso po’ di tempo dall’ultimo deploy in produzione della nostra web application e scopriamo che c’è qualcosa che non va. Qual è il primo “strumento” che ci può supportare nell’identicazione e analisi del problema? Il log, ma la nostra applicazione non genera file di log! Ecco persa un’opportunità di risolvere il problema. La situazione precedentemente descritta, molto spesso è la routine. Infatti, quando uno sviluppatore scrive del codice è difficile che per sua spontanea abitudine introduca il logging nell’applicazione. Quando il logging è un requisito dell’applicazione succede allora che i messaggi di log risultino poco significativi e irrilevanti. Ciò accade perchè al logging non viene data la giusta importanza, anzi la si considera generalmente una perdita di tempo, a maggior ragione quando si tratta di progetti di piccole dimensioni. Succede che per individuare il problema si faccia ricorso ad altri log, ovviamente non dell’applicazione, ma ad esempio del web server o magari dell’interpetre PHP, con la speranza che su di essi si trovi traccia di qualcosa che non va. La ricerca produce i risultati sperati se il problema genera un errore o una situazione eccezionale tale da essere riportata nei predetti log. Logging e monitoring di un sistema software in produzione dovrebbero essere la normalità. Anche se il nostro software sembra funzionare egregiamente, l’attività di analisi dei log dovrebbe essere un’attività che accompagna quanto meno i momenti successivi al go live. Leggendo i log e gli errori generati dall’applicazione si trovano molto spesso bug subdoli che a lungo andare possono creare anche danni insapettati in considerazione del dominio applicativo. Qual è la soluzione al problema? E’ semplice: introdurre all’interno delle applicazioni un utile strato di logging. Il log è il mezzo attraverso il quale la nostra applicazione ci parla. E’ lo “strumento” più utile per risolvere problemi operazionali. Il log non deve interessare solo i casi negativi delle azioni: ad esempio se l’azione è memorizzare un’informazione sul database il log deve registrare sia quando l’azione va a buon fine, sia quando essa fallisce. In quest’ultimo caso è bene avere quante più informazioni possibili per poter analizzare il caso di errore e prendere le dovute precauzioni affinchè ciò non accada (quindi informazioni dettagliate sull'errore ma anche informazioni sul contesto che ha generato l'errore). Alcuni sistemi di logging prevedono che in base alla gravità dell'informazione registrata si produca una notifica verso il gestore dell’applicazione attraverso i più disparati mezzi di comunicazione: e-mail, SMS, push notification, Twitter direct message, etc. Lo standard RFC 5424 definisce il “syslog protocol”. All’interno del documento di IETF si definisce il livello di importanza di ogni messaggio di log. Ecco la tabella che riepiloga “Syslog Message Severities”: Numerical code = Severity 0 = Emergency: system is unusable 1 = Alert: action must be taken immediately 2 = Critical: critical conditions 3 = Error: error conditions 4 = Warning: warning conditions 5 = Notice: normal but significant condition 6 = Informational: informational messages 7 = Debug: debug-level messages Il numerical code è un intero da 0 a 7 che indica la gravità del messaggio di log. Più l'errore è grave, più il numerical code tende a 0. Ogni linguaggio e framework mette a disposizione specifiche librerie per il logging. In PHP ad esempio Symfony2 e Laravel 4/5 sposano il progetto Monolog che è basato sullo standard di logging PSR-3. Le cose si complicano quando ad esempio se parliamo di un'applicazione web che è servita da più web server. In questi casi è necessario avere un sistema di logging che si presenti all'utente attraverso un unico punto di accesso. Inoltre i tool che supportano la gestione dei log consentono di effettuare un'efficiente ricerca all'interno delle interminabili righe di log. Esistono poi soluzioni in cloud per il logging come LogEntries.com. Esso prevede persino un piano gratuito per progetti di dimensioni contenute. Quanto detto fin qui in merito al logging non è da riferirsi solo alle applicazioni tradizionali web e desktop, ma deve essere applicato anche al mondo delle applicazioni mobile e dell'Internet of Things. Si pensi a quanto possa essere utile che la propria mobile app supporti lo sviluppatore nella ricerca e correzione di crash, fornendo stack trace e metadati. #### Il MIX supera 1.1 Tbit/s di traffico Il Milan Internet eXchange supera 1.109 Tb/s di traffico il 10 marzo 2020 a seguito dell'entrata in vigore delle misure restrittive di contenimento del COVID-19. E' interessante notare che, anche se di norma siamo tutti connessi in contemporanea, la cosa inusuale è che per la prima volta siamo tutti connessi da casa. Inoltre, come è possibile notare sul primo grafico, il picco giornaliero si concentra nelle ore serali. Peccato non poter fare un confronto per gli stessi intervalli temporali su Milan Neutral Access Point (MINAP) e Nautilus Mediterranean eXchange point (NaMeX). #### Installare Asterisk 13 su Ubuntu Server 14.04 LTS In questo breve tutorial vedremo come installare Asterisk 13 su un server Ubuntu 14.04 fresco di installazione. Il processo descritto è stato eseguito su una VPS Small di Aruba Cloud (1 vCPU, 1 GB di vRAM, spazio disco 20 GB SSD, Hypervisor VMware). Per risparmiare sui cloud server Aruba ti consiglio di leggere questo articolo. Per chi non conoscesse Asterisk, è un framework open-source promosso dalla Digium che consente di realizzare un centralino VoIP (PBX) in modo estremamente professionale. Prima di iniziare l'installazione di Asterisk partiamo da alcune attività preliminari come la configurazione di lingua e paese sul server: sudo locale-gen en_US en_US.UTF-8 sudo dpkg-reconfigure locales sudo update-locale LC_ALL=en_US reboot sudo apt-get update sudo apt-get upgrade sudo apt-get install ntp reboot Posizioniamoci all'interno di una cartella temporanea, nel nostro caso pbx. mkdir pbx cd pbx Effettuiamo il download di Asterisk ed estraiamo l'archivio tar. wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz tar -zxvf asterisk-13-current.tar.gz Dobbiamo installare tutte le dipendenze necessarie al processo di compilazione di Asterisk. Eseguiamo il comando: sudo ./asterisk-13.6.0/contrib/scripts/install_prereq install Durante la procedura ci verrà richiesto di specificare il prefisso telefonico del nostro paese (39 per l'Italia). Procediamo adesso con l'installazione vera a propria. cd asterisk-13.6.0 ./configure make menuconfig make sudo make install make samples sudo make config Se tutto è andato bene possiamo verificare che Asterisk sia up and running digitando: asterisk -rvvvv Apparirà la command line interface di Asterisk, simile all'immagine seguente. Per chiudere la CLI è sufficiente digitare exit. Asterisk CLI Da questo momento Asterisk è in esecuzione come utente root, l'ideale sarebbe creare un utente ad hoc e dare ad esso i permessi sulle cartelle strettamente necessarie al suo funzionamento. #### Installare PHP 7 su Internet Information Services (IIS) 8.5 Il giorno di PHP7 è arrivato. Proprio ieri, infatti, è stata pubblicata versione 7.0.0 del linguaggio di scripting più diffuso del web. Abbiamo dovuto attendere dal 2004 ad oggi  la nuova major release che si propone come la più veloce, la più performante e la più sicura di sempre. E' il momento giusto, quindi, per procedere all'installazione di PHP7 su tutte le postazioni di sviluppo. I seguenti passaggi sono validi su Microsoft Windows 8.1 con IIS 8.5 e l'ultima versione di Web Platform Installer (Web PI), precisamente la versione 5.0. La procedura è identica per Microsoft Windows 2012 R2, in ambiente di produzione è necessario prendere in considerazione il php.ini-production come template di riferimento. Installeremo PHP utilizzando FastCGI e PHP Manager. Iniziamo dai prerequisiti: installa la versione x64 di Visual C++ Redistributable for Visual Studio 2015 (VC14) effettuando il download dal sito Microsoft Effettua il download di PHP nella versione VC14 x64 Non Thread Safe e estrai il contenuto dell'archivio zip in una cartella a tua scelta (es. C:\Program Files\PHP\v7.0\) Copia il file php.ini-development e rinominalo php.ini Apri il file php.ini e modifica i valori come di seguito indicato: extension_dir = "C:\Program Files\PHP\v7.0\ext\" error_log = "C:\Windows\Temp\php-7.0.0_errors.log" upload_tmp_dir = "C:\Windows\Temp\" session.save_path = "C:\Windows\Temp\" upload_max_filesize = 8M post_max_size = 8M date.timezone = "Europe/Rome" cgi.force_redirect = 0 cgi.fix_pathinfo = 1 fastcgi.impersonate = 1 fastcgi.logging = 0 Decommenta le righe seguenti togliendo il ";" davanti: extension=php_curl.dll extension=php_gd2.dll extension=php_gettext.dll extension=php_mbstring.dll extension=php_openssl.dll extension=php_pdo_mysql.dll extension=php_soap.dll extension=php_xmlrpc.dll A questo punto è necessario registrare su IIS la nuova versione di PHP. Dalla gestione di IIS apriamo il PHP Manager e facciamo click su "Register new PHP version". Selezioniamo il file php-cgi.exe nella cartella di PHP. L'installazione è conclusa, verifichiamo che sia tutto ok utilizzando "Check phpinfo()" disponibile sempre sul PHP Manager. Non mi resta che augurarti Happy PHPing! #### Installare PHP7 e nginx su Ubuntu In questo breve tutorial vedremo quanto è facile e pratico installare nginx e PHP 7 su un server Ubuntu 14.04 fresco di installazione sul cloud di Aruba. Il processo descritto è stato eseguito su un cloud server smart e precisamente una VPS small (1 vCPU, 1 GB di vRAM, spazio disco 20 GB SSD, Hypervisor VMware). Questa guida tralascia gli aspetti di sicurezza, fondamentali per un progetto web. Pertanto non può essere sufficiente seguire i seguenti step per costruire un idoneo ambiente dove pubblicare applicazioni esposte su Internet. Partiamo da alcune attività preliminari: sudo locale-gen en_US en_US.UTF-8 sudo dpkg-reconfigure locales sudo update-locale LC_ALL=en_US reboot sudo apt-get update sudo apt-get upgrade reboot Ora iniziamo l'installazione di nginx e php-fpm attraverso i seguenti comandi: sudo apt-get install -y language-pack-en-base sudo apt-get install python-software-properties sudo LC_ALL=en_US.UTF-8 add-apt-repository ppa:ondrej/php apt-get update apt-get upgrade sudo apt-get purge php5-common -y sudo apt-get install php7.0 php7.0-fpm php7.0-mysql -y sudo apt-get --purge autoremove -y sudo apt-get install nginx A questo punto nginx e php-fpm sono attivi sul nostro VPS. Per verificare che sia tutto ok navighiamo sul nostro browser l’indirizzo ip del server (es. http://127.0.0.1) e verifichiamo che appaia la pagine di default di nginx, come mostrato nella figura seguente: Procediamo alla configurazione di PHP7 intervenendo sul php.ini, digitando: sudo nano /etc/php/7.0/fpm/php.ini Sul php.ini è necessario cercare e modificare le seguenti chiavi: cgi.fix_pathinfo=0 upload_max_filesize = 8M date.timezone = "Europe/Rome" Eventuali altre modifiche del php.ini devono essere effettuate in base alle esigenze delle applicazioni web da ospitare. La configurazione proposta è valida per WordPress e Laravel 5. Riavviamo PHP FastCGI Process Manager (fpm) con il seguente comando: sudo service php7.0-fpm restart Posizioniamoci sulla root del file system e creiamo una cartella che dovrà contenere i siti ospitati dal nostro webserver. cd / mkdir webserver cd webserver mkdir default mkdir site0.cordiano.it mkdir site1.cordiano.it mkdir site2.cordiano.it ... All'interno della cartella default appena creata sarà contenuto il sito di default di nginx. Creiamo un file di test nella cartella default cd default nano index.php All’interno del file inseriamo la stringa: <?php phpinfo(); Proseguiamo modificando la configurazione del sito di default digitando: sudo nano /etc/nginx/site-availables/default Il file di default deve essere come il seguente: server {     listen 80 default_server;     listen [::]:80 default_server ipv6only=on;     root /webserver/default;     index index.php index.html index.htm;     server_name localhost;     location / {         try_files $uri $uri/ =404;     }     location ~ \.php$ {         fastcgi_split_path_info ^(.+\.php)(/.+)$;         fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;         fastcgi_index index.php;         include fastcgi_params;     } } Riavviamo nginx. sudo service nginx restart Per verificare che la configurazione sia corretta navighiamo sul nostro browser l’indirizzo ip del server (es. http://127.0.0.1) e verifichiamo che appaia la pagina col phpinfo() creata prima. Per motivi di sicurezza è bene sostituire il file index.php del sito di default che mostra la configurazione di PHP con un testo generico. Possiamo, infine, procedere alla configurazione di un nuovo sito. Per ciascun sito è utile creare un file di configurazione separato, in modo da poterlo attivare e disattivare senza impatto sugli altri siti. Supponiamo di voler configurare l'hosting per site0.cordiano.it il cui contenuto è disponibile nella cartella /webserver/site0.cordiano.it Per fare ciò creiamo un server block (su Apache avremmo parlato di virtual host) per il nostro sito nella directory /etc/nginx/site-availables. Creiamo un file denominato site0.cordiano.it e inseriamo il seguente testo al suo interno: server {     listen 80;     listen [::]:80;     root /webserver/site0.cordiano.it;     index index.php index.html index.htm;     server_name site0.cordiano.it;     location / {         try_files $uri $uri/ =404;     }     location ~ \.php$ {         fastcgi_split_path_info ^(.+\.php)(/.+)$;         fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;         fastcgi_index index.php;         include fastcgi_params;     } } Per attivare il sito è necessario creare un link simbolico del file site0.cordiano.it appena creato nella cartella /etc/nginx/sites-enabled sudo ln -s /etc/nginx/sites-available/site0.cordiano.it /etc/nginx/sites-enabled/site0.cordiano.it e riavviare nginx. sudo service nginx restart Quello che abbiamo configurato non è uno stack LEMP (Linux, Nginx, MySQL, PHP) completo, infatti all’appello manca MySQL. Considerata la taglia della VPS, appesantire il server con MySQL a bordo è rischioso. La soluzione più semplice è quella di affiancare alla VPS un database MySQL disponibile come add-on dell’hosting Aruba il cui costo è irrisorio. In questo modo il costo di un hosting dedicato minimale si aggira su circa 80 euro all’anno, una cifra davvero vantaggiosa. Con questa configurazione è attualmente in test un progetto web con WordPress che ogni mese registra 60K sessioni, 30K utenti, 125K visualizzazioni di pagina e un picco massimo di 400 utenti contemporaneamente online. #### Introducing git switch and git restore When you work with Git using the command line, you know the git checkout command for sure. git checkout command is the overused command, and it does many things. We mainly use git checkout to switch or create new branches and restore files in the working tree. Let’s see some examples of usages. # switch to an existing branch $ git checkout <existing_branch> # create and switch to a new branch $ git checkout -b <new_branch> # restore filename.ext from the index git checkout filename.ext These two completely different purposes could lead to confusion, so Git developers have taken this into account. In fact, Git 2.23 release introduces the git switch and git restore commands. It is clearer how to switch/create branches and restore files with two different commands. Disclaimer: git switch and git restore are still marked as experimental on the docs. Their behavior may change. But let’s go deeper with both commands. git switch in action # switch to an existing branch $ git switch <existing_branch> # create and switch to a new branch $ git switch -c <new_branch> # switch to the previous branch $ git switch - git restore in action git restore is used to revert non-committed changes: changes in the working copy; content in the index (also called staging area). # discard the local changes of filename1.ext and filename2.ext git restore filename1.ext filename2.ext # discard all local changes git restore . The restore command will take the contents from HEAD by default. You can change this behavior, as shown in the following examples. # restore filename.ext from the commit with hash 049c0bb432 git restore --source 049c0bb432 filename.ext # restore filename.ext from 2 commits before # the current tip of the master branch git restore --source master~2 filename.ext You can restore the index and the working tree using the --worktree option. $ git restore --worktree filename.ext The last command does two things: revert your working copy to HEAD; unstage previously staged work. That’s all Folks! #### La lezione (dimenticata) di John Nash Poco meno di 15 giorni fa perdeva la vita il matematico statunitense John Forbes Nash a causa di un incidente stradale. Nash è divenuto famoso al grande pubblico nel 2001 dopo l'uscita del film A Beautiful Mind del regista Ron Howard. In realtà Nash è stato tra i matematici più brillanti ed originali del XX Secolo, avendo rivoluzionato con la sua matematica l'economia, tanto da vincere nel 1994 il Premio Nobel. Avevo già sentito parlare di equilibrio di Nash guardando qualche video del corso di Teoria dei Giochi del professore Fioravante Patrone. Poi nel 2010 era il momento del corso di Intelligenza Artificiale tenuto dal professore Luigi Palopoli e sono tornato sull'argomento da una prospettiva e con un interesse diversi. In quella occasione mi sono imbattuto nell'intervista del matematico italiano Piergiorgio Odifreddi fatta a Nash durante il Festival della Matematica del 2008 a Roma. In un passaggio Odifreddi chiede a Nash di spiegare in "quattro parole" la teoria dell'equilibrio: «Un gioco può essere descritto in termini di strategie, che i giocatori devono seguire nelle loro mosse: l'equilibrio c'è, quando nessuno riesce a migliorare in maniera unilaterale il proprio comportamento. Per cambiare, occorre agire insieme». In altre parole l'equilibrio si raggiunge quando due giocatori, dopo aver giocato la propria mossa, non hanno nulla da dire poichè avrebbero giocato la stessa e identica mossa anche se fosse stata già nota a loro la mossa dell'avversario. Segue una nuova domanda di Odifreddi: «Italo Calvino, ha scritto una frase che molti usano per descrivere la teoria dell'equilibrio di Nash: a volte nella vita non riusciamo a raggiungere il meglio, ma almeno possiamo evitare il peggio. È una buona descrizione della sua nozione?». Ecco la risposta: «Direi di sì. Perché unilateralmente possiamo solo evitare il peggio, mentre per raggiungere il meglio abbiamo bisogno di cooperazione». Volendo semplificare al massimo: la cooperazione e la collaborazione nelle decisioni strategiche risulta migliore rispetto ad un approccio competitivo. Per completezza precisiamo che una decisione strategica è un caso particolare di decisione, in cui  lo stato di natura è determinato, in tutto o in parte, dalle decisioni di altri decisori, sicché il risultato di quella decisione dipende non solo dalla stessa ma anche da decisioni altrui. Riferimenti John Nash genio e follia. http://espresso.repubblica.it/visioni/cultura/2008/03/11/news/john-nash-genio-e-follia-1.7633 Odifreddi intervista Nash. https://www.youtube.com/watch?v=Evvs3u8rtR4 #### La ricetta del successo secondo Fabio Lalli Questo weekend sono stato al MaSeM (Master di Secondo Livello in Sviluppo Applicazioni Web, Mobile e Social Media) a Lamezia Terme, dove ho avuto il piacere di incontrare e dialogare con una persona che seguo da anni sul web e che reputo un “idolo” per i nativi digitali. Sto parlando di Fabio Lalli, inventore di Followgram: l'esperienza di Instagram reinventata. Fabio ha approfondito due tematiche molto interessanti: Digital PR e Mobile Marketing. 
Ho scritto questo post per riassumere in breve la “ricetta del successo" che l’innovatore di Palizzi (si Fabio Lalli è calabrese) ci ha trasmesso con una lezione sempre leggera, ma ricca di case study ed esempi concreti della vita “reale". D’emblée mi vengono in mente quattro tweet presi dallo storytelling che ho fatto durante la lezione e che trovate sul mio profilo Twitter (@parallelit) contrassegnati dall’hashtag #masem e sono: La rete è buon senso e consapevolezza. La creatività si stimola. La co-creation puó essere un buon modo di portare la creatività all’interno di un progetto/prodotto. Quando si costruisce un’app mobile si deve sempre tenere a mente che essa non deve essere il porting del web sul mobile ma la creazione di una nuova esperienza secondo le regole del mobile. La nuova frontiera nello sviluppo di idee innovative è la misurazione dell’esperienza reale dell’utente. That’s all folks! #### La rivoluzione delle memorie si chiama 3D XPoint E' del 28 luglio un interessante breaking news di Intel che rivoluzionerà le performance di computer, Data Center e non solo. Intel e Micron annunciano assieme l'inizio della produzione di una nuova classe di memoria non-volatile basata sulla tecnologia 3D XPoint. Al momento i media internazionali non hanno ancora dato il giusto risalto a questa importante novità che - di fatto - è la prima nuova categoria di memoria dopo l'introduzione delle NAND flash datata 1989. Le fondamenta di questa rivoluzione nel mondo delle memorie possono essere riassunti nei seguenti punti: La tecnologia 3D XPoint consente alle memorie non-volatili di essere 1.000 volte più veloci delle NAND flash. I materiali e l'architettura delle nuove memorie basate sulla tecnologia 3D XPoint consentono di essere 10 volte più dense delle memorie comuni. Secondo un articolo apparso su DZone l'introduzione delle memorie 3D XPoint avrà un impatto significativo sulle performance dei database relazionali. Infatti, le ricerche basate sugli indici, diventano più efficienti quando si riduce il tempo di accesso casuale al dato, cosa che già avviene nel passaggio dai più tradizionali HDD agli SSD. Cosa succederà con l'avvento della tecnologia 3D XPoint? Cambierà il modo di scalare i database che usano logiche relazionali: anziché orientarsi  verso lo scaling orizzontale, che prevede di aumentare il numero di macchine in parallelo con tutti gli svantaggi di mantenere sincronizzate n basi di dati, si opterà per quanto possibile allo scaling verticale, che prevede di aumentare CPU e RAM delle macchine. Da questo punto di vista sembrebbe che il declino dei database SQL a cui stiamo assistendo negli ultimi anni è scongiurato. La conclusione più interessante di quanto fin qui trattato è riassunta nella seguente frase di Lukas Eder: Don't believe your data fits in RAM? Think again. With recent advancements, RAM is the new SSD. Riferimenti RAM is the New SSD. https://dzone.com/articles/ram-is-the-new-ssd-1 Does your data fit in RAM? http://yourdatafitsinram.com/ RAM is the new SSD. http://blog.jooq.org/2015/08/05/ram-is-the-new-ssd/ #### La roulette russa I one-to-one sono i meeting di maggiore valore nella mio lavoro quotidiano. La mia agenda ideale prevede di dedicare 60 minuti per ciascun 1:1 ogni 2 settimane. Mi sono trovato fino a qualche mese fa ad avere 8 riporti diretti e non riuscire nel mio intento di fare i meeting con ciascuno 2 volte al mese. Ho cercato, allora, un modo per rimanere sempre aggiornato dal mio team, ma riducendo la durata degli incontri. Aggiornandosi frequentemente il numero degli argomenti su cui discutere si riduce. Pianificando un incontro ogni 2 settimane, ho pensato che fosse possibile alternare un one-to-one tradizionale con uno veloce che ho chiamato la roulette russa. Quando racconto questo format di meeting, la prima reazione dell’interlocutore è di preoccupazione. Infatti, la roulette russa è un gioco d’azzardo letale, di cui sicuramente avremo letto in un racconto o visto in qualche film. Il meeting roulette russa ha, invece, lo scopo di condensare in 15 minuti la discussione di 3 cose positive e 3 cose negative accadute nelle ultime settimane. Ciascuno degli argomenti di discussione è “colpo” che viene “sparato”. Cerco di fare in modo che i sei punti in discussione siano sempre proposti dall'interlocutore e non portati sul tavolo da me. Nel tempo ho notato che questo format si presta anche molto bene per darsi un feedback veloce da manager a riporto e viceversa. E tu cosa ne pensi? Troveresti utile questo format per il tuo team? #### Le stime in Scrum Molte aziende adottano Agile e Scrum perchè le considerano una moda da inseguire e non perchè credono, in fondo, alla bontà delle metodologie. Succede, allora, che i manager e i team leader propongono l'approccio del comando e del controllo per monitorare il progresso di un'attività. A volte ciò degenera diventanto controllo dei componenti del team. In generale in Agile la stima dell'effort può essere proposta da qualunque componente del team durante lo Sprint Planning. Secondo Mario Lucero, Agile Coach Freelance, il compito di stimare l'effort di una User Story è di chi lavora ad essa. Nella mia limitata esperienza professionale aggiungo che solo chi lavora o può lavorare a quella storia ha "diritto" a stimarla. Certamente l'onere della stima non è dell'architetto - il cui compito è quello di proporre una soluzione tecnica - e neppure del business analyst, il cui compito è quello di scrivere le User Story. #### Maggio è il Mese della Salute Mentale Maggio è il mese della 🧠 salute mentale dal 1949, anno in cui la Mental Health America (MHA) istituì questa ricorrenza. Nonostante siano passati quasi 75 anni dalla sua istituzione, ancora oggi parlare in Italia di salute e malattia mentale genera pregiudizi e timori, in parte è un tabù. Generare consapevolezza, è il primo passo da compiere per fermare questo nemico subdolo, potente e allo stesso tempo invisibile. Benessere psicologico e mentale sono basi fondamentali in tutte le fasi della nostra carriera e soprattutto della nostra vita. Personalmente sono abbastanza ignorante sull’argomento, ma mi permetto di condividere due link che ho trovato particolarmente utili. 📺 Corso online in italiano su “Benessere psicologico nel lavoro” disponibile gratuitamente sulla piattaforma Learnn e costruito dal team di Serenis. 🔗 Link 🧪 Il Mental Health Toolkit, disponibile in lingua inglese, realizzato dalla MHA e consultabile liberamente. 🔗 Link Buon mese di Maggio! #### Occhio alla latenza! Nell'epoca in cui affiancare la parola cloud a prodotti di web hosting è sempre più una questione di marketing, risulta tra i fattori determinanti dell'esperienza utente sul web la velocità del servizio di hosting. A influenzare la velocità lato server vi sono elementi come il tipo di hypervisor utilizzato, le quantità di memoria e CPU garantite, le caratteristiche della connessione di rete, il tipo di storage (SAN, SSD). Altri aspetti da tenere a mente sono il tipo di tecnologia utilizzata per costruire la propria web application (Java, PHP, Node.js, ASP.NET, RoR), la presenza/assenza di strati di cache (Redis, Memcached) e/o di minimizzazione delle pagine HTML e degli asset, etc. Dulcis in fundo lato client non possiamo trascurare di considerare in prima istanza le caratteristiche del dispositivo e la qualità del servizio di connettività dell'utente. A quanto fin qui trattato dobbiamo necessariamente aggiungere la latenza come metrica che affligge le performance dei servizi web. Prima di proseguire nel ragionamento rinfreschiamo la definizione di latenza da Wikipedia. La latenza (o tempo di latenza), in informatica, di un sistema può essere definita come l'intervallo di tempo che intercorre fra il momento in cui arriva l'input al sistema ed il momento in cui è disponibile il suo output. In altre parole, la latenza non è altro che una misura della velocità di risposta di un sistema. La latenza è strettamente dipendente dalla posizione dell'utente rispetto alla server farm che ospita l'applicazione web: maggiore è la distanza tra il server e l'utente, maggiore è la latenza. A ben guardare il rapporto che c'è tra la distanza e la velocità di comunicazione può essere compreso considerando che, ad esempio, se esistesse un collegamento diretto in fibra ottica tra l'utente e il server, la velocità di comunicazione sarebbe legata alla velocità della luce che a sua volta è dipendente dalla distanza end to end. In realtà dobbiamo precisare che la latenza dipende anche dall'efficienza della rete e dalla qualità del routing. Secondo lo scienziato americano Van Jacobson, uno dei principali artefici del protocollo TCP/IP, l'utente percepisce il ritardo di latenza a 400 ms. Attualmente la latenza di un sito particolarmente "veloce" si attesta attorno al valore 10 ms. Per calcolare la latenza di un sito è sufficiente effettuare un traceroute   (traceroute su Mac e Linux, tracert su Windows) e calcolare il valor medio considerando tutti gli hop. E' importante fare questa verifica cercando di mettersi nelle stesse condizioni del pubblico di riferimento. La morale della favola è che nel valutare un cloud provider è cruciale considerare anche la disponibilità di una region vicina alla target audience, quindi occhio alla latenza! #### OKRs for Summer Vacation Nel mese di dicembre 2019, la mia Azienda ha organizzato un WorkShop di introduzione ad OKRs, al quale - per questioni di opportunità - non mi è stato possibile partecipare. Il corso è stato il preludio dello shift della metodologia di valutazione aziendale da un approccio soggettivo ad uno scientifico ed oggettivo. Prima di arrivare a capire il legame tra OKRs e vacanze estive, proverò ad introdurre OKRs partendo dalle domande che mi sono posto quanto ne ho sentito parlare per la prima volta. Che cosa sono gli OKRs? OKR è l'acronimo inglese Objectives and Key Results. E' una metodologia utilizzabile da un'organizzazione per creare un chiaro e ben definito allineamento tra obiettivi e risultati da raggiungere. OKR è applicabile ad un'intera azienda, ad un gruppo di lavoro, come ad un singolo individuo. La paternità di OKR si deve all'ingegnere ungherese Andy Grove (Andrew Stephen Grove), tra i fondatori di Intel Corporation, come racconta John Doers nel libro Measure What Matters. Oggi molte aziende come Google, Spotify e Facebook usano questa metodologia. https://www.youtube.com/watch?v=1ht_1VAF6ik Che cos'è un obiettivo? Un OBIETTIVO è semplicemente COSA deve essere raggiunto, né più né meno. Ogni obiettivo per definizione deve essere significativo, concreto, orientato all'azione e motivante. Quindi, l'obiettivo è dove vogliamo andare. Non fa altro che dare la direzione e indicare la meta. Che cos'è un Key Result? I KEY RESULTS analizzano, valutano e monitorano COME arriviamo all'obiettivo. KRs efficaci sono: specifici (orientati al soddisfacimento dell'obiettivo), con scadenza, misurabili, verificabili e aggressivi ma realistici. Alcuni esprimono il concetto della precedente frase affermando che i KRs dovrebbero essere SMART, dove SMART è il solito acronimo di Specific, Measurable, Achievable, Realistic and Time-bound. Il mio manager Alessandro aggiunge sempre a quanto detto sopra che: "Un KR deve essere auto-contenuto (self-contained)". Con questo intende sottolineare che nella definizione stessa del KR deve esserci scritto tutto ciò che serve per la sua misurazione, senza lasciare spazio ad alcun dubbio. Per semplificare ancora ripropongo una frase di Marissa Mayer che riassume il concetto di KR in modo estremo, ma efficace: "Non è un KR a meno che non abbia un numero". Perchè usare OKR? In un mondo ideale ogni azienda definisce gli OKRs aziendali e poi questi vengono declinati sulle business unit, sui team fino ad arrivare al singolo. Questo modo di procedere fa si che gli obiettivi siano chiari, ben definiti e condivisi. OKRs ha un approccio collaborativo: ad ogni livello aziendale esiste un solo grado di libertà che è legato al come (how) raggiungere gli obiettivi, invece il cosa (what) è già definito. La conseguenza immediata è l'allineamento a tutti i livelli sugli obiettivi e la crescita della delega. Infatti, per OKRs devono essere chiari obiettivi e priorità aziendali, ma è lasciata libertà sul come raggiungere gli obiettivi stessi. OKRs prevede trasparenza totale, sicché obiettivi e key results devono essere pubblici ed accessibili all'interno dell'organizzazione. Cosa c'entra OKR e le vacanze estive? Leggendo il libro di Doerr, ho capito il potere di obiettivi e risultati chiave già dal primo capitolo: in particolare quando l'autore racconta della presentazione della metodologia fatta a Larry Page e Sergey Brin di Google. Da quel momento ho iniziato a scrivere OKRs per qualunque cosa. I primi tentativi di scrivere OKRs sono stati per motivi di lavoro, ma non è stato un compito semplice e indolore. Il motivo principale delle mie difficoltà va ricercato nel fatto che il business non usa questa metodologia, di conseguenza gli obiettivi proposti erano molto vicini per granularità a dei task . Alla fine abbiamo trovato la formula giusta per definire al meglio i nostri OKRs. In seguito, ho scritto OKRs per altri motivi professionali come un talk, un meeting e la stesura di un documento. Poi ho iniziato ad usare OKRs anche per motivi personali, tant'è vero che parte dei miei OKRs personali sono finiti all'interno di quelli aziendali. In vista delle vacanze estive mi sono detto: "Perché non applicare OKRs anche alle ferie?". Il mantra di OKR rimane ugualmente: "Ideas are easy. Execution is everything". Ed ecco i miei OKRs estivi: Obiettivo 1: Stop lavoro KR 1.1 Non ricevere notifiche da Slack, Sentry, Jira, New Relic, Confluence, E-mail, Trello, Grafana e VPayment KR 1.2 Inviare al massimo a 2 risposte a commenti/messaggi/e-mail aziendali in tutto il periodo di ferie KR 1.3 Limitare lo screen time (mobile + desktop) ad un massimo di 50 minuti a settimana KR 1.4 Non intervenire nelle cose del Team Obiettivo 2: Mens sana in corpore sano KR 2.1 Visitare almeno 3 nuove città, fare 2 escursioni in montagna e trascorrere 10 gg al mare KR 2.2 Dedicare almeno 60 minuti al giorno all'attività fisica e perdere 4 Kg KR 2.3 Mangiare la frutta tutti i giorni KR 2.4 Leggere 3 libri, vedere almeno 30 video TED/TEDx e arricchire il vocabolario imparando 100 nuove parole Obiettivo 3: Vita familiare KR 3.1 ... KR 3.2 ... KR 3.3 ... Non entrerò nel merito del gli obiettivi che mi sono proposto, essi sono sono strettamente personali. Qualcuno potrebbe dire che alcuni dei miei OKRs non siano realmente sfidanti. Qualcun altro potrebbe vederli più come una mera lista di attività da fare. Entrambe le obiezioni sono errate. Gli obiettivi ambiziosi ed "esagerati" di cui parla la metodologia, anche chiamati stretch goals, devono portarci fuori dalla confort zone e farci raggiungere cose che prima non pensavamo di poter fare. Nel mio caso è proprio così! Per l'obiettivo #3 non me la sono sentita di scrivere KRs, devo essere onesto. Ragione ed affetti non possono essere mischiati e non credo si possano pianificare i rapporti umani e familiari. Utilizzare OKRs per le vacanze estive potrebbe sembrare un controsenso. In vacanza si pensa solo al relax, la pianificazione è quasi del tutto assente e il cervello è in stand-by. Conoscendo come ragiona la mia mente, per staccare dalla routine ho bisogno di pormi delle sfide, anche in vacanza. OKRs è lo strumento ideale per fare ciò, quindi perché non usarlo? E' ovvio che gli obiettivi scritti sopra sono solo un sottoinsieme di tutti gli obiettivi di un momento come le ferie, ma raggiungere il 100% dei KRs sopra è condizione necessaria, ma non sufficiente, di avere imboccato la strada giusta per lo svago, la spensieratezza e la tranquillità. E tu cosa ne pensi? Sei pronto a scrivere i tuoi OKRs personali? Scriveresti anche tu gli OKRs della tua vacanza? Se sei curioso di sapere alla fine come è andata, non dimenticare di visualizzare il report degli OKRs qui. Bibliografia John Doerr, Measure What Matters, PENGUIN Business, 2018 Marco Imperato, OKR: cosa sono, come usarli e perché sono fondamentali, Product Heroes, 2019 John Doerr, Why the secret to success is setting the right goals, TED, 2018 Felipe Castro, How ambitious should your OKRs be?, 2016 #### Osservare gli utenti mentre navigano il proprio sito Osservare gli utenti di un sito web mentre interagiscono con esso credo sia sempre stato il sogno di chi sviluppa web e ancor di più di chi si occupa della UX di un prodotto web. Conoscere il flusso di comportamento e gli analytics può aiutare, ma fino ad un certo punto. Sono tante le cose che sfuggono se ci limitiamo ad utilizzare eventi e pageview. Immaginiamo, invece, di trovarci al cinema: il film proiettato è la nostra web application ed attore protagonista è un utente-visitatore, ignaro del fatto che noi stiamo osservando tutte le sue azioni inclusi click, scroll, movimenti del mouse o touch gesture. Oggi fare ciò non è fantascienza, ma è realtà e si chiama Peek in. Peek in è una piattaforma cloud che consente, attraverso l'inserimento di appena due righe di codice all'interno di un'applicazione web, di poter realizzare quanto precedentemente descritto. Inserito lo snippet di codice javascript prima della chiusura del tag </head> è tutto pronto per iniziare lo spettacolo. Non ci rimane che attendere il primo visitatore ed accendere la macchina da presa. <script> peekin = {api_key: "blablabla"}; </script> <script src="//cdn.peekin.io/peekin.js" async></script> Peek in è integrato con piattaforme di chat come LiveChat, Olark e Intercom questo al fine di consentire ai proprietari dei siti un supporto real-time al visitatore efficace e diretto, non richiedendo all'utente - quindi -  conoscenze tecniche e maggiore dettaglio nello spiegare i problemi che sta riscontrando nel fare qualcosa. I punti di forza di questo prodotto sono: facilità e rapidità di installazione: poche righe di codice per iniziare ad usare Peek in senza richiedere l'installazione di alcun software all'utente; gratuità: in realtà sul sito si parla di gratuità per tutto il periodo in cui Peek in sarà in beta; scalabilità: nessuna limitazione sul numero di pageview della web application; sicuro e rispettoso della privacy: da quanto riportato sul sito la piattaforma Peek in non memorizza alcun dato dell'utente. E' possibile esplicitamente escludere la registrazione di alcuni campi dei form (password, numero carte di credito, etc.). Inoltre l'accesso alle sessioni è possibile solo al proprietario del sito previa autenticazione. Sull'ultimo punto (sicurezza e privacy) ho riportato le esatte parole della homepage di Peek in. Certamente il prodotto è ancora allo stadio alpha e sono convinto che verrà ben presto introdotta la possibilità di registrare e rivedere le sessioni utente senza doversi trovare a «spiare» l'utente solo in diretta. La domanda che nasce spontanea è: dal punto di vista della privacy, quanto è legale utilizzare Peek in? Aggiornamento del 31/03/2016: Facendo una ricerca mi sono imbattuto in un altro servizio simile a Peek in, ma migliore. Si chiama Smartlook e consente addirittura di registrare l'utente anche quando noi non siamo online. Inoltre supporta HTTPS, richieste AJAX e dynamic pages. #### People first, delivery second Questo post racchiude una mia riflessione sull'importanza del Team e delle Persone. E' frutto degli ultimi due anni di lavoro e soprattutto di tanti errori fatti. Spero dopo un'attenta lettura di ricevere qualche feedback nei commenti. Quando per la prima volta ho letto l'Agile Manifesto sono rimasto molto colpito dalle parole con cui si apre: Individuals and interactions [1, left side] over processes and tools [2, right side] Esso è il primo dei 4 valori che, insieme ai successivi 12 principi, costituiscono una possibile sintesi di riflessioni sulle metodologie di sviluppo software definite "agili". Questa frase, che ho cercato di fare mia nel tempo e con tanta fatica, non è il primo dei 4 valori del Manifesto per pura casualità. Credo che esso sia il più difficile dei valori da mettere in pratica. Il primo valore mette subito il focus sulle persone e le interazioni tra le stesse. Valorizzare le persone più di processi e strumenti è facile da capire, ma non è così semplice da farsi. Le persone rispondono alle richieste del business e sono loro a condurre (dal latino "cum" insieme e "ducere" guidare) il processo di sviluppo. Quando la situazione è capovolta processi e strumenti guidano lo sviluppo. In questi casi il risultato più immediato è la burocratizzazione del lavoro, il comodo rimbalzo di responsabilità e soprattutto l'incapacità da parte del team di reagire e di soddisfare le esigenze dei clienti. Il secondo pilastro della parte sinistra della frase [1] è l'interazione tra le persone, del quale mi preme sottolineare uno degli aspetti più importanti: la comunicazione. Sulla comunicazione e il suo ruolo cruciale nelle organizzazioni sono stati scritti interi libri, quindi non mi voglio dilungare. Quando la comunicazione è pianificata, richiede contenuti specifici o formalizzati ed è guidata da un processo definito e rigido, è la fine dell’agilità. Usando un termine che va molto di moda in questi ultimi anni, credo che la comunicazione debba essere fluida, vada favorita e debba essere innescata tutte le volte che c’è un bisogno. Penso, ad esempio, a quelle situazioni in cui per un task su Jira (o ancora peggio e-mail) si legge un thread di commenti che supera il numero magico 5. Il 5º commento, nella mia esperienza, è la soglia su cui mettersi in allarme. Non è meglio sentirsi su Slack o ancora fugare ogni dubbio de visu, piuttosto che estendere il carteggio? Ci tengo a sottolineare che ho sostituito volutamente il termine individui con persone, per sottolineare l'aspetto più umano del termine. Infatti, quando penso ad una persona, penso alla sua capacità di pensare e provare emozioni, al personale bagaglio di skills e di interessi e alla personalità. Non solo alle capacità strettamente tecniche, sic! Ciascuno di noi porta il proprio modo di essere unico nel lavoro quotidiano. Un'organizzazione non può prescindere o dimenticare queste ultime argomentazioni se vuole mettere in pratica il primo principio, anzi deve riconoscere e incoraggiare le capacità delle persone. Mi riferisco, per fare qualche esempio, alla capacità di risolvere problemi, di imparare, di sperimentare e di innovare, ma anche alla creatività, all'autonomia e al senso di responsabilità. Inoltre, è molto importante incentivare la condivisione. Su quest'ultimo punto aggiungo una considerazione sulla base di un'espressione che sono solito ripetere: "Il team protegge il team". Con questo intendo affermare che ogni team member possa attingere, senza abusare, dalla professionalità ed esperienza degli altri componenti, per fare meglio il proprio lavoro. Il verbo proteggere (dal latino "pro" davanti e "tegere" coprire) qui non è usato nell'ottica di nascondere le malefatte a chicchessia, ma va inteso nel senso di complementarietà e condivisione della conoscenza. Per riassumere: "Sharing is caring". Avviciniamoci adesso alle ragioni del titolo di questo articolo. Attualmente ricopro il ruolo di lead di uno dei team di tecnologia della mia Azienda. Da definizione, il mio ruolo mi espone al business come primo responsabile delle performance e della delivery del Team. Non arrivo subito al dunque, mi piace mantenere alto l'hype. Apro una breve digressione riportando un pezzo di un dialogo tratto da "Le città invisibili" di Italo Calvino dedicato alle pietre, al ponte e all'arco. Esso mi aiuta attraverso un'immagine a "visualizzare" meglio la mia idea. Marco Polo descrive un ponte, pietra per pietra. ⁃ Ma qual è la pietra che sostiene il ponte? - chiede Kublai Kan. ⁃ Il ponte non è sostenuto da questa o da quella pietra, - risponde Marco, - ma dalla linea dell'arco che esse formano. Kublai Kan rimase silenzioso, riflettendo. Poi soggiunse: ⁃ Perché mi parli delle pietre? È solo dell'arco che mi importa. Polo risponde: ⁃ Senza pietre non c'é arco. Se si approfondisce qualcosa in più del curioso esploratore Marco Polo e del distaccato imperatore Kublai Khan è possibile definire questo dialogo un vero esempio di "pensiero critico" nell’accezione più nobile di questa espressione. Inoltre, questo dialogo - a me caro sin dai tempi dell'università - è un modo diverso e nello stesso tempo una rappresentazione "tangibile" di quello che per me è un Team. Il team di sviluppo è il ponte che consente alle idee del business di raggiungere l’altra parte: il cliente. The Team is the bridge between business ideas and production environment. Ma il team è soprattutto la "linea dell'arco che esse [le pietre] formano", non un insieme di pietre a caso. Affiatamento, condivisione, complementarietà non sono caratteristiche che si ottengono semplicemente mettendo più persone nella stessa stanza. Calvino spiega: "senza pietre non c'è arco e senza arco non c'è ponte", parafrando mi sento di dire: "senza le Persone non c'è il Team e senza il Team non c'è la delivery". L'ultima frase racchiude in estrema sintesi la lezione appresa ed è la milestone che cercherò di tenere sempre a mente nel prosieguo della mia carriera lavorativa. Bibliografia Agile Manifesto Appunti del corso di Arduino Mancini (Tibicon) "Gestire efficacemente i Collaboratori". Milano, 2018 Treccani 2017. Dizionario della lingua italiana Italo Calvino, Le città invisibili, Mondadori, Milano, 1993 #### Perché si parla di "canary" release? Qualche giorno fa parlavamo con Ilario e il Team di questo simpatico aneddoto, ho pensato allora di condividerlo con tutti. Quando parliamo di canary release, intendiamo un pattern di deploy del software, che prevede di distribuire i rilasci di una nuova versione ad un sottoinsieme di utenti per validarla e successivamente renderla disponibile a tutti gli utenti. Ma perché si chiama "canary" release? Storicamente, il nome deriva dall'abitudine dei minatori di portare con sé in una gabbia un canarino quando operavano nelle miniere di carbone. Lo sfortunato canarino aveva il compito di pre-allarmare l'uomo della diffusione di gas tossici. Infatti, il diffondersi del monossido di carbonio, del metano o dell'anidride carbonica viene percepito prima dal canarino che dall'uomo. Quindi, la sofferenza dell'animale era un precursore del fatto che le condizioni in miniera non erano più sicure. Per gli amici animalisti: l'uso dei canarini nelle miniere è stato gradualmente eliminato dal 1987. Bibliografia: CanaryRelease #### PHP 7, ci siamo quasi! Appena 2 giorni fa il team di sviluppo di PHP ha annunciato la disponibilità dell'alpha 1 di PHP 7.0.0. Essa è la prima release che segna l'inizio dell'era contrassegnata dal numero 7, in realtà è la sesta visto che PHP 6 non ha mai visto la luce. Si tratta, ovviamente, di una development preview per cui è fortemente sconsigliato l'uso in ambiente di produzione. PHP 7 arriva con la nuova versione di Zend Engine e con tante nuove funzionalità tra cui: Improved performance: PHP 7 is up to twice as fast as PHP 5.6 Consistent 64-bit support Many fatal errors are now Exceptions Removal of old and unsupported SAPIs and extensions The null coalescing operator (??) Combined comparison Operator (<=>) Return Type Declarations Scalar Type Declarations Anonymous Classes Dalla roadmap apprendiamo che la seconda alpha è attesa per il 25 giugno 2015, invece per la general availability (GA) dovremo attendere ancora fino a metà ottobre 2015. #### Programmare non è andare in bicicletta Mi capita molto spesso nel lavoro di programmatore di sentire la parola esperienza. Rendo già l’idea di ció di cui voglio parlare se aggiungo l’espressione l’esperienza insegna. È vero, man mano che gli anni passano si prende sempre più coscienza e praticità del proprio lavoro, si acquisiscono nuove conoscenze e se ne consolidano altre. Come dissi qualche anno fà: “sei mesi d’azienda sono più di cinque anni di università” perchè le esperienze aziendali hanno un forte pragmatismo e concretezza. Inoltre il ritmo incalzante della logica aziendale detta tempi di apprendimento ben diversi. Fare esperienza non vuol dire solo lavorare. Vuol dire apprendere, studiare, crescere, sbagliare, raccontarsi, raccontare, condividere, ascoltare, ascoltarsi, migliorare… Ma la programmazione e l’informatica in generale hanno qualcosa di diverso da tanti altri ambiti: il continuo cambiamento. Ogni anno vengono fuori nuovi linguaggi, nuove tendenze stilistiche di scrittura del codice e nuove tecnologie. Non è reinventare la ruota, ma rimpiazzarla con un altro oggetto ed a volte in modo radicale. Pensiamo all’attività di andare in bicicletta. Quando da bambini si impara, poi come direbbe la pubblicità “è per sempre”. Non è così per la programmazione. Essa è più paragonabile ad una palestra, quando si smette di allenarsi si perde quanto fatto e riprendere è dura. That’s all folks. #### Responding to change or following a plan? Qualche tempo fa ho condiviso una riflessione sul primo valore dell'Agile Manifesto, oggi vorrei provare a fare un passo avanti. Nella mia esperienza lavorativa, più di una volta ho sentito ripetere: Responding to change [1, left side] over following a plan [2, right side] In quasi tutte le circostanze, questa frase è stata strumentalizzata, raccontandola come la favola secondo cui l'unica cosa che conta è rispondere al cambiamento. E' importante rispondere al cambiamento, non lo metto in dubbio. Aggiungo, però, che chi ha scritto il Manifesto non intendeva arrivare alla precedente fuorviante conclusione. Infatti, ripropongo - per non essere di parte - le esatte parole riportate nel Manifesto: While there is value in the items on the right, we value the items on the left more C'è del valore nelle voci a destra. Adesso è tutto più chiaro: rispondi al cambiamento, ma non dimenticare che hai bisogno di un piano. Ecco che svaniscono gli alibi per chi pensa che si possa sempre navigare a vista, non pianificare e vivere la quotidianità in emergenza. Completo l'argomentazione con un aspetto sottolineato dal collega Christian: rispondere al cambiamento ha un costo, che talvolta può tradursi in un cambio di scope. Considerando che la capacity del team è fissa, devi operare una scelta come ad esempio cambiare la data di consegna, rinunciare allo sviluppo di qualcosa o abbassare la qualità di quello che fai. Lo stesso warning proposto nel ragionamento fatto sull'ultimo dei quattro valori, vale ovviamente anche per i precedenti. #### sendmail lentissimo su Ubuntu Mi sarà capitato già oltre 10 volte nell'ultimo mese, ma dimentico sempre come risolvere il problema della lentezza di sendmail su Ubuntu. Dopo aver installato sendmail col seguente comando: sudo apt-get install sendmail Proviamo ad effettuare un invio dummy verso un nostro indirizzo email myemailaddress@mydomain.com echo "Test email sent from sendmail" | /usr/sbin/sendmail myemailaddress@mydomain.com Se l'email arriva ma l'esecuzione del comando tarda a terminare, ecco la soluzione. Verifichiamo quale sia l'hostname digitando appunto hostname. Ora supponiamo che l'hostname sia salvatore, modifichiamo l'/etc/hosts come segue: sudo nano /etc/hosts Aggiungiamo in testa al file la seguente stringa: 127.0.0.1 salvatore salvatore.local salvatore.localhost Ora riconfiguriamo sendmail digitando: sudo sendmailconfig Non ci rimane che ripetere il test per l'invio dummy e verificare che tutto sia ok. #### Si chiama Li-Fi ed è 100 volte più veloce del Wi-Fi Introdotto per la prima volta durante il TED Global del 2011 dal Prof. Harald Haas, docente dell'Università di Edimburgo, Li-Fi è l'acronimo di Light Fidelity, una tecnologia che consente di trasmettere dati attraverso la luce. Per funzionare Li-Fi richiede una sorgente di luce come una comune lampada LED, una connessione internet e un fotorilevatore. I LED sono semiconduttori che hanno la caratteristica peculiare di consentire la modulazione dell'intensità di luce a velocità molte elevate. Sfruttando questa possibilità e avendo a disposizione tutta la porzione di luce visibile dello spettro elettromagnetico (Visible Light Communication, 400-800 THz) è possibile trasmettere dati in codice binario fino a 1Gbps utilizzando la modulazione spaziale OFDM (o SIM-OFDM). Li-Fi ha degli evidenti vantaggi: Non interferisce con altri segnali radio e può essere utilizzata, ad esempio, sugli aerei e negli ospedali. Utilizza la luce visibile e quindi ha a disposizione uno spettro 10.000 volte più grande di quello delle onde radio. E' sicuro poichè limitato alla portata ottica. Ma ha anche degli svantaggi: Non può funzionare all'aperto dove vi è la luce solare diretta che può causare interferenza. Non può oltrepassare i muri degli edifici. Nel talk Harald Haas ha mostrato Li-Fi in azione attraverso un esempio di trasmissione di un video in HD. L'intervento si conclude affermando che: So, all we would need to do is to fit a small microchip to every potential illumination device. And this would then combine two basic functionalities: illumination and wireless data transmission Questa settimana, a distanza di qualche anno, le parole di Harald Haas sono tornate alla ribalta grazie a Velmenni, una start-up dell'Estonia che ha deciso di investire su Li-Fi testando questa tecnologia in prima persona. Staremo a vedere! #### Tre minuti in Italia con San Pellegrino La San Pellegrino, azienda italiana vanto del nostro paese, marchio famoso in tutto il mondo per la produzione di acqua minerale e bevande soft drink, ha lanciato in questi giorni una campagna dal titolo “Tre minuti in Italia" (Three minutes in Italy). La campagna, che si rivolge al pubblico straniero ma che sta spopolando anche in Italia, non ha lo scopo di promuovere direttamente San Pellegrino, ma far conoscere l’Italia comodamente seduti a casa. Potremmo definire questa iniziativa una forma di promozione del turismo ispirata dal brand. Attraverso la pagina Facebook del marchio è possibile “teletrasportarsi” virtualmente in Sicilia e precisamente nella ben famosa Piazza IX Aprile della splendida Taormina, dove si assumerà il controllo di un proprio robot per 3 minuti. Il robot, capace di muoversi in base agli input remoti dell’utente, è dotato di iPad attraverso il quale l’utente può vedere e farsi vedere, sentire e farsi sentire, esattamente come se si trovasse in Italia per 3 minuti. Davvero geniale l’integrazione reale/virtuale e la strategia di promuovere un paese anzichè un brand. La campagna “Three minutes in Italy” è stata ideata da Ogilvy & Mather, una tra le più importanti agenzie pubblicitarie del mondo con sede a New York. That’s all folks! #### Un anno di soDDisfazioni Un anno sportivo concluso con la promozione in Serie D della squadra di calcio della mia città: la Nuova Gioiese. Un anno indimenticabile, trascorso a bordo campo per seguire la passione viola che dal 2009 mi ha travolto grazie al progetto GioiaSport. Un anno che ho gioito a raccontare attraverso le mie foto apparse sui principali giornali online e cartacei della Calabria. Un anno che posso riassumere nei seguenti numeri: 6000 foto scattate 16 Gb di spazio occupato 50 foto pubblicate tra Il Quotidiano della Calabria, Calabria Ora, Gazzetta del Sud 155.000 visualizzazioni su Flickr 12 trasferte a bordo campo 1 obiettivo rotto 1 memoria SD bruciata 20 foto rubate dai colleghi della stampa #### Un regalo per Natale 2021 Per augurare un buon Natale 2021, ho pensato di condividere la scaletta del concerto del maestro Ludovico Einaudi, al quale ho assistito lo scorso 2 dicembre 2021 presso il teatro Dal Verme a Milano. Certamente l'emozione della musica dal vivo non può essere trasmessa da una playlist, ma la musica riesce in ogni caso a solleticare l'anima. La tracklist è disponibile, di seguito, per YouTube e Spotify. https://youtube.com/playlist?list=PL-XZpetpBZ9_6ZgBx1aFSaP561RYecDy- https://open.spotify.com/playlist/1fw0KtnbB89aWd0c8UsqXs?si=Lgvj4JRHQfSNF9ZjuAIpKw Ecco, invece, la suddivisione del concerto. Part I Atoms, Wild Song, Oltremare I Giorni, Luminous, Rolling Natural Light, Una Mattina, Nuove Bianche Part II Full Moon, Cold Wind (7DW) L'Origine Nascosta, Petricor, Fly, Fossils Bis Walk, Twice, Divenire, Experience. #### Utilizzare Squid come HTTP proxy per bloccare l'accesso in LAN ad alcuni siti web Squid è tra i più diffusi caching proxy. Può essere facilmente utilizzato come HTTP proxy per bloccare l'accesso ad una lista di siti. I passi che seguono sono stati seguiti su un'istanza di Linux Debian 7.8 fresca d'installazione. Procediamo all'installazione di squid: apt-get update apt-get install squid Creiamo il file con i siti non permessi: sudo nano /etc/squid/blocked_sites.squid Inseriamo all'interno del file blocked_sites.squid i siti da bloccare, ad esempio: .salvatorecordiano.it .facebook.com Modifichiamo, poi il file di configurazione di squid che si trova nel percorso /etc/squid/squid.conf com segue: 1) In coda alle regole ACL aggiungiamo acl blocked_sites dstdomain "/etc/squid/blocked_sites.squid" 2) Aggiungiamo, invece, prima della prima regola http_access le seguenti due righe: http_access allow localnet http_access deny blocked_sites Ho supposto l'esistenza di una regola ACL che definisca la LAN locale (localnet) come segue acl localnet src 192.168.0.0/16 Riavviamo squid col seguente comando sudo service squid restart A questo punto non ci rimane che configurare sui client il server proxy. La porta di default usata da squid è 3128. #### Windows 8, errore 812 sulla connessione VPN [RISOLTO] Recentemente mi è capitato di imbattermi in uno strano errore nella connessione in VPN alla rete aziendale utilizzando il client VPN integrato in Windows 8. Tale problema non si è mai verificato utilizzando Windows XP/Vista/7. Ecco l'errore: Errore durante la connessione a Xyz VPN. Errore 812: Impossibile stabilire la connessione a causa di un criterio configurato nel server RAS/VPN. Il metodo di autenticazione utilizzato dal server per verificare il nome utente e la password potrebbe non corrispondere al metodo di autenticazione configurato nel profilo della connessione. Contattare l'amministratore del server RAS per informarlo dell'errore. Osservando le impostazioni di sicurezza della connessione VPN ho constatato che "Crittografia dati" era impostato su "Nessuna crittografia" ed ho, quindi, modificato come di seguito: Crittografia dati: Richiedi crittografia (disconnessione in caso di rifiuto da parte del server) Consenti i protocolli seguenti: Microsoft CHAP versione 2 (MS-CHAPV2). Per completezza preciso che il server RAS utilizzato è configurato per accettare una connessione VPN di tipo PPTP. ### Pages #### About Me Short Bio I'm a leader and an engineer at heart with a solid product taste and strong business acumen. My work consists of building the best People-first, happy workplaces. I help engineering organizations drive impactful business outcomes through operational excellence and empathy. Long Bio An empathetic rebel engineer with a strong passion for numbers, technology, and teams' happiness. He has a natural ability to care about people, furthermore, inspire, motivate, and build effective relationships. Salvatore has over 15 years of software engineering experience building and designing scalable applications and high-traffic distributed systems. He also has more than 8 years of hands-on people management experience, mentoring, and growing high-performing teams. He loves maximizing engineers’ effectiveness in both organization and tech side (VCS, CD/CI, and development workflow) and loves making evidence-based decisions. He hires and builds highly skilled and highly-performing engineering teams, and he has a track record of achieving great things with his squads. He builds and influences a culture of ownership, empathy, and inclusivity, not only within his teams but also within the whole engineering department. Salvatore has a proven experience of working efficiently, end-to-end, with cross-teams. He partners with Product, Design, Data Science, Marketing and DevOps people to build and deliver product roadmaps incrementally, effectively, and with a high level of quality. He has a deep understanding of Web technologies and DevOps tools, such as PHP, Symfony, Node.js, Docker, Git, CI/CD pipelines, and Kubernetes. #### dig me! Open a terminal and type: dig -t txt bc.salvatorecordiano.it. +short #### Favorite Quotes Two things fill the mind with ever-increasing wonder and awe, the more often and the more intensely the mind of thought is drawn to them: the starry heavens above me and the moral law within me. Immanuel Kant We believe that ideas are easy, execution is everything, and in anything worth doing, it takes a team to win. John Doerr Simplicity is prerequisite for reliability. Edsger Wybe Dijkstra Dubium sapientiae initium. René Descartes Whatever you do, passion makes things easier. Erasmus Of Rotterdam The only way to do great work is to love what you do. Steve Jobs Leadership is all about people. It is not about organizations. It is not about plans. It is not about strategies. It is all about people-motivating people to get the job done. You have to be people-centered. Colin Powell Photo by Vincenzo Fondacaro #### Get in Touch 👋 Hey! Nice to meet you 🤝. The best way to contact me is via e-mail. I usually answer within 1 day. If that doesn't happen, feel free to ping me on X. If you need to communicate with me privately, use my PGP public key. Its fingerprint is AA41 FBBF 4CAD 5611 1076 CE92 E7AE D55D EFB7 7973. If you prefer modern alternatives, we can use Signal. DM me asking for my Signal number. E-mail: hey (at) cordiano (punto) it X: @parallelit LinkedIn: Salvatore Cordiano Instagram: parallelit #### Legal Pages The following documents are available in Italian only. Privacy Policy Cookie Policy Disclaimer #### Links Il Valore del 1:1. Con Salvatore Cordiano, Engineering Manager @ The LeadershIT Podcast Viaggio nella terra dei bias. E non vale solo per gli ingegneri del software Ok la fuga dal lavoro ma qual è la ricetta per coinvolgere i dipendenti? Pixels of the Week – September 18, 2022 Web Developer, sapreste riconoscere un bravo professionista? Realtime Presentation Remote Control with reveal.js and PubNub Is it all PHP OPCache's fault? PHP Annotated Monthly – October 2017 Come fare Messenger Marketing in modo semplice Slide sui Design Pattern dal Corso di Ingegneria del Software, Politecnico di Milano, Mattia Salnitri, 2020 Quadrans Notarize Bot Chatbots, applicazioni nel mondo Retail Gestione delle mail #### Re-Add Text Justify Button The most simple plugin to re-add text justify on WordPress 4.7+ Description This plugin allows to re-add text justify button in the WYSIWYG on WordPress 4.7+ Installation This section describes how to install the plugin and get it working. Upload the plugin files to the /wp-content/plugins/re-add-text-justify-button directory, or install the plugin through the WordPress plugins screen directly. Activate the plugin through the "Plugins" screen in WordPress That's all folks. Download plugin #### Side Projects Milan Metro Status Projects Website: Milan Metro Status Telegram Bot: @UndergroundStatusBot Telegram Channel: UndergroundStatus Alexa Skill: Metro Milano Other projects Telegram bot: @quadransbot Telegram bot: @vardumpbot reveal.js PubNub Remote Control Plugin WordPress plugin: Re-Add Text Justify Button Telegram bot: @CIDRCalcBot Alexa Skill: Regolo Ostetrico Bias cognitivi: Elenco di 52 pregiudizi cognitivi selezionati Alexa Skill: Bella Ciao Alexa Skill: Milano Developers