Bene, benvenuti su Gitbar, un'altra settimana e un altro episodio, un altro appuntamento qua nel nostro bar degli sviluppatori.È da tanto che vi avevo promesso che sarebbe stato qua a bere una birra con noi e finalmente abbiamo Enrico Zimuel, principal engineer a Elastic, un grandissimo open source contributor ma anche un membro core del PHPfig.uno speaker al TEDx, un co-founder del Pug Torino, insomma ha fatto un gozziliardo di cose, ma quando si parla di PHP non si può parlare se non con Enrico Zimuel.Quindi subito dopo una breve interruzione iniziamo la nostra chiacchierata, ma non prima di avervi ricordato i nostri contati.Info@gitbar.it o @brainrepo su Twitter o sul gruppo telegram perché sì come ben sapete come gli ammutinati lo ricordano abbiamo un gruppo telegram quindi se non l'avete ancora fatto mi raccomando iscrivetevi benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo [Musica] eccoci qua ciao Enrico benvenuto ciao Mauro grazie per avermi invitato in tuo podcast il piacere è tutto nostro tu sei diventato in realtà nella nostra community il simbolo del php quando si parla di PHP si parla di Enrico perché in realtà è da tanto che promettevo questa questa intervista per via di mille vicissitudini non si è potuta fare.In realtà anche noi due la stavamo organizzando da un bel po', no? Sì, infatti, abbiamo scambiato anche di più, sì, diverse mail.E oggi parliamo di PHP, come ben potete sapere.Quindi per tutti i detrattori Decidete se mettere in pausa l'episodio, abbassare il volume oppure sentir parlare di uno di quei linguaggi che a me appassionato e devo anche dire ma dato da mangiare per lungo tempo Sì infatti.No dicevo che molti di quelli che ne parlano male alla fine però ci lavorano, ci guadagnano e fanno la spesa al supermercato quindi mai sputare sul piatto dove si mangia Giustissimo infatti io lo ricordo sempre Però prima di parlare di PHP parliamo di Enrico Zimuel.Come è iniziata questa carriera e soprattutto mi interessa capire qual è il passaggio tra uno sviluppatore e uno sviluppatore che si proietta verso un'ottica, una prospettiva internazionale.Allora, guarda, è successo abbastanza per caso devo dire, nel senso che io ho iniziato lavorare, ho sempre avuto la passione per l'informatica.A 9 anni ho iniziato a smanettare con il Texas Instruments T99/4A, il primo del Commodore 64.Mi sono subito appassionato, mi ricordo che copiavo i listati dalle riviste che comprava mio padre, cercavo di capire cose erano quei data, quei numeri che seguivano questa istruzione così esoterica e quindi ho iniziato a programmare prestissimo, è stata proprio una folgorazione la mia, poi ho fatto l'Istituto Tecnico Industriale Informatica, io vivevo a Pescara, non c'era l'ITIS Informatica, però a Chieti che è una città non molto lontana da Pescara c'era, quindi io tutte le mattine mi alzavo alle 6, tornavo alle 4 di pomeriggio per pultifare informatica, era una passione sfrenata.Quindi ho iniziato a lavorare subito, ho iniziato a lavorare prestissimo, anche a scapito dell'università, nel senso che avevo talmente tante cose da fare di lavoro che l'università in qualche modo è andata in secondo piano, infatti poi mi sono laureato mentre lavoravo.Però quando ho fatto la tesi, l'università l'ho fatta su algoritmi e strutture dati, ovviamente per rimanere sul tema, e il professore mi aveva proposto di andare con una borsa di ricerca all'Università di Amsterdam per proseguire questa tesi sperimentale che avevo.Era l'epoca sui database XML, c'era un periodo negli anni 2000 dove sembrava che l'XML fosse la soluzione ai tutti i mali.come lo YAML avantieri e come in JSON oggi.Basta mettere delle parentesi angolari, un file di testo per così.E quindi c'era un sacco di ricerca su questo settore dell'XML, su linguaggi di interrogazione, XQuery.Infatti avevo proposto un algoritmo efficiente per risolvere interrogazioni di XQuery, scritto in C.Insomma, una cosa che poi...Quindi ho abbandonato il mio lavoro stabile, all'epoca lavoravo anche per un'azienda che l'avevo comprata dall'IPM, quindi un buon stipendio e tutto, sono partito per un contratto di sei mesi all'Università di Amsterdam.E questo è stato, ovviamente i miei genitori non ti lasci immaginare, il feedback che mi hanno dato, però secondo me questa è stata la cosa migliore che ho fatto in vita mia, c'era scelta anche più azzardata, però che si è rivolta poi vincente, perché da lì mi ha aperto un mondo, quando vai a lavorare all'estero migliori la lingua, di fatto puoi anche lavorare con l'inglese a livello internazionale, quindi da quando ho fatto quella scelta mi sono aperto tantissime porte.Una di queste è stata l'azienda, l'azienda Technologies, che sta al PHP, fondamentalmente è stata fondata dai due autori del PHP3, e poi sono rimasto lì per 11 anni, e lì fondamentalmente ho approfondito il tema del PHP, perché io prima lo usavo, ci giocavo, avevo fatto qualche piccolo progetto, il PHP 3 mi ricordo, anzi un progetto anche abbastanza grande, una migrazione mi ricordo da un sito da ASP.net, all'epoca questo linguaggio da Microsoft molto simile al PHP 3.0.C'era un cliente che aveva chiesto una migrazione di questo tipo da ASP a PHP 3.0.Era un sito con tantissime pagine, infatti alla fine avevo fatto un traduttore di linguaggio da ASP a PHP che avevo anche rilasciato.L'epoca non c'era neanche GitHub.Saperlo prima, io per tanto tempo ho lavorato proprio migrando pagina SP in PHP e questo giusto per ricollegarci all'episodio della settimana scorsa dove parlavamo di metà programmazione quindi in realtà quello che è fatto era pura metà programmazione.Sì esattamente perché uno al posto di spendere mesi a tradurre delle pagine anche se la traduzione veniva fatta in maniera non completamente efficiente però un grosso 80% c'era poi le cose, i ritocchi manuali uno se li faceva, però le istruzioni fondamentalmente erano tradotte, anche perché i due linguaggi erano abbastanza complementari all'epoca, quindi si poteva fare.Adesso una cosa del genere è abbastanza impensabile fare da dotto nel TAP HP, adesso cambia proprio il mondo, la struttura che c'è dietro.Quindi questa è la mia storia fondamentalmente.Poi l'azienda Zende è stata acquisita da altre aziende, un po' come le scatole cinesi, un'azienda compra un'altra e così via, quindi si è perso un po' lo spirito che c'era prima, ci sono stati diversi licenziamenti, alla fine della fiera ho deciso di andare via anche perché ci avevano praticamente chiuso i rubinetti nel settore open source all'interno dell'azienda e quindi è stata una scelta quasi obbligata la mia.Per fortuna Elastic mi ha offerto la possibilità di continuare a fare open source, ormai sono due anni che lavoro per Elastic, quindi con le librerie per accedere a Elasticsearch o gli altri prodotti Elastic, in PHP e anche in Perl, sono anche il maintainer della libreria la stick search perle perché sono l'unico che ho avuto il coraggio di buttarsi in perle.In realtà avevo già esperienza in perle in passato, solo che per me è stato un tuffo proprio nel passato perché non è una delle linguaggi più utilizzate al momento.Comunque interessante anche quello, perché per me è sempre programmazione.Non sono un grandissimo fan dei linguaggi, nel senso che mi piace anche sperimentare con nuovi linguaggi.Il PHP lo conosco bene perché ci ho lavorato tanto tempo negli internals, ho conosciuto tutti quelli che ci lavorano negli internals, conferenze eccetera, quindi ovviamente dove più esperienza per forza di cose, però non è che faccio solo PHP, anzi mi piace programmare, quindi linguaggio è uno strumento.Io dico sempre che noi non scriviamo codice ma troviamo soluzioni, che è un modo diverso di vedere il nostro lavoro, però ti devo chiedere una curiosità.che hai riesumato nella mia mente Perle.In realtà il primo anno di università un po' ci stava approcciando, poi è arrivato PHP all'orizzonte, ha catalizzato tutta la mia attenzione e sono scappato a gambe levate.Però ad oggi, essendo tu il maintainer della libreria Perle, come vedi l'adozione? Essendo Elasticsearch uno dei vostri prodotti, diciamo prodotto di adozione massiva perché io credo che sono poche le aziende dove nello stack non c'è almeno un elastic search se non tutto lo stack elk.Quindi ti chiedo mantenendo la libreria Perl che tipo di attività vedi? C'è qualcuno che lo utilizza ancora? E se si è riuscito a identificare più o meno chi ti fa le pull request, che tipo di società o di personaggi ci sono dietro? Guarda, sono tantissime società che utilizzano Perl, che hanno scritto Perl dagli anni 90 in poi e quindi si trovano delle applicativi, anche legacy se vogliamo, da manutenere.Ci sono, vabbè, uno, posso fare un nome di una società che è famosa, che utilizza Perl, che è Booking.Booking.com è quasi scritto tutto in Perl, c'è il back-end, è tutto oggi in Perl, infatti loro cercano programmatori Perl, li pagano molto bene, quindi se qualcuno è nascolto e vuole dedicarsi a questo linguaggio così antico, comunque ci sono diverse aziende che lo utilizzano.Certo che i progetti nuovi difficilmente nascono con Perl, ma per una questione veramente grafica, nel senso che le persone, i programmatori più giovani ovviamente non hanno mai utilizzato questo linguaggio.Poi è un linguaggio onestamente molto ostico, perché è nato come linguaggio semplice da usare quasi una scrittura in inglese per fare parsing di stringhe, le espressioni regolari vengono dal Perl, la maggior parte dei motori sulle espressioni regolari è stato scritto dal Perl, anche la sintassi, che è uguale a quella del PHP, è uguale a quella del Perl.È un linguaggio che è cresciuto molto, però la parte di programmazione oggetti in Perl è un disastro, è veramente difficile programmare oggetti in Perl, infatti ci sono delle librerie a parte dei framework che ti aiutano a programmare in oggetti, come Moo, più usate.Adesso c'è questo progetto nuovo, che è stato rinominato con un "raku", il nome di questo linguaggio dove sembra che le cose siano, noi non le abbiamo ancora utilizzate, ma sembra che la parte oggetti sia un po' più...anche per esempio le funzioni in Perl era un disastro, tu non avevi neanche la possibilità di specificare i parametri, dovevi prendere questo array interno, questo chioccio, l'underscore, andare a fare il parsing per sapere appunto il primo o secondo parametro.Però per esempio ha delle potenzialità enormi il PER perché offre tutta una serie di API per modificare anche l'esecuzione dei programmi, quindi fare cose sofisticate come EPM, il di applicazioni in Perl, il Perl offre già una tabella in memoria di tutte le variabili, di tutte le funzioni, è un linguaggio molto da hacker, si possono fare cose veramente molto sofisticate in Perl, però richiede uno studio specifico, difficilmente uno passa da un linguaggio più strutturato a Perl, perché Perl ha tutta una serie di cose che ha solo il perlo, quindi devi proprio conoscerlo bene per poterlo usare, ma come qualsiasi cosa poi, io non credo nè in tuttologi, sono persone che dicono "io programmo in sei linguaggi", no, impossibile, io ho 25 anni di esperienza di programmazione, ho fatto sempre e solo programmazione e voglio fare quello, non voglio diventare CTO, voglio programmare perché è quello che mi piace fare, però non ti puoi specializzare in sei linguaggi di programmazione, in 25 anni probabilmente tre o quattro, per come li intendo io.Altrimenti scrivi in un altro linguaggio, però avendo la tua formazione sul linguaggio principale, ho visto tantissimi progetti, ne faccio uno, un nome tra tutti, in PHP, Magento, se lo conosci, se non hai mai sentito parlare, è l'e-commerce più famoso.La versione 1 di Magento è stata scritta da programmatori che erano dei programmatori Java, cioè non erano esperti PHP.Infatti si vede l'approccio.L'è scritto in Java, in PHP.Esatto, interfacce, classi, estensioni, file di configurazione in XML.Chi usava mai i file di configurazione in XML e in PHP? Magento è l'unico progetto che li utilizza fondamentalmente.massimamente.La prima versione di Magento non era così performante, bisognava avere dei server abbastanza corpulenti per farla girare, proprio in memoria, consumava tanta memoria.Quindi se uno conosce il linguaggio bene lo sa sfruttare per quello che serve.Vero, Carmine, uno degli speaker di questo podcast dice sempre "esiste una differenza tra chi usa un linguaggio e chi lo conosce", così come esiste una differenza tra un architetto o tra un muratore e un manovale.C'è una differenza sostanziale da una parte la consapevolezza sui costrutti che si usano e anche la profondità di visione verso i costrutti e le semantiche del linguaggio.Poi arriva in qualche modo PHP.PHP che arriva negli anni 90 spazzando via le common graphic interface che ci costringevano a scrivere per le pagine dinamiche del codice C e arriva come outsider.Hai detto tu subito dopo entrano in gioco due studenti di Tel Aviv che sono stati appunto i tuoi capi di allora, che sono appunto i fondatori di Zend e che traghettano il PHP dalla versione 3 fino alla versione 5, dico bene? Sì, in realtà Zend continua tuttora a sponsorizzare con Dimitri che è uno appunto degli sviluppatori, per esempio tutta la parte del Just-in-Time compiler del PHP 8 è un lavoro che è stato sponsorizzato a Zend, cioè che ha fatto Dimitri che è appunto stipendiato da Zend.Poi c'è Nikita Popov che invece è con JetBrains.Esatto, ovviamente se uno vuole fare le cose full time bisogna avere dei meccanotti, qualcuno che ti paghi perché appunto questo mito dell'open source che viene fatto la sera da ritagli di tempo o da persone asociali che stanno davanti al computer 12 ore al giorno, per fare open source serio bisogna creare una community, software, non è tanto scrivere il software open source, sono le persone, infatti open source non è codice, è una conseguenza, è il team, la community che c'è dietro, le persone, quello fa la differenza, infatti tutti i progetti open source che hanno successo hanno dietro una community, delle persone che ci lavorano, altrimenti diventa semplicemente un diletto, poi si fanno i disastri come le varie librerie che ci sono in circolazione, per carità scritte anche in maniera geniale, che però poi non vengono più manutenute, il maintainer che va a cambiare lavoro e quindi la libreria si trova a monca, le issue che rimangono aperte, però quella poi è usata a catena da altri prodotti e quindi si creano dei problemi.Infatti anche la scelta del libri open source è una responsabilità grossa, perché uno non è che può fare su packages per php o npm per node, anche lì node ci sono stati grossi problemi all'inizio perché uno faceva npm, installava, funziona, mette in produzione, però poi la libreria si schianta perché non c'è più nessuno che l'ha.Oppure addirittura le licenze, molti che installavano licenze gpl su prodotti poi che venivano commercializzati e quindi c'è anche il discorso della licenza, è fondamentale capire appunto quando usarla e come usarla.Assolutamente sì, beh c'è da dire che spesso, adesso io la mia esperienza per il 90% è basata sulla piccola media impresa.Mi rendo conto che in realtà quando si sviluppa qualcosa non sempre si ha la consapevolezza di non tanto andare a vedere la resilienza e la stabilità di una libreria perché quello bene o male se siamo dei professionisti lo facciamo però spesso manca quel tipo di consapevolezza di dare qualcosa in cambio cioè io sto usando un tale prodotto per farci del business.Ci sto facendo del business però alle volte sono magari un po' limitato a contribuire se non alle issue che mi tangono o mi colpiscono specificatamente, alle cose che mi servono.Quindi non c'è quel dare e ricevere che in realtà è lo strumento principale, il meccanismo principale che permette a questo mondo di...Guarda su questo, te lo dico per esperienza, è difficile comunque avere un ritorno così puntuale.La maggior parte delle volte sono le grandi aziende che sponsorizzano questi progetti, ma lo vedi appunto a tutti i livelli.Poi i singoli sviluppatori, sì, ogni tanto danno una mano, quelli che appunto hanno una una issue particolare, che già se ti mandano una pull request, anche se incompleta, io ringrazio sempre, perché è un'altra cosa importante, come dicevo prima, dietro ogni riga di codici c'è una persona che l'ha scritta, quindi ha una cultura, un suo modo di pensare, il suo linguaggio, perché non tutti sono madrelingua inglese, quindi anche quello è da… quando si scrive una pull request, una issue, molte persone si possono offendere perché hanno utilizzato dei termini… Insomma è complicato, la parte più difficile dell'open source sono le interazioni umane, come nella vita fondamentalmente.Quindi bisogna essere molto educati sotto questo punto di vista, perché altrimenti la community diventa poi una cosa dittatoriale, dove c'è il fondatore, il produttore principale che fa un po' il bel e il cattivo gioco.Su questi progetti più di successo hanno dietro un team di persone che comunque riescono a dialogare, perché altrimenti la community non cresce, quello è fondamentale.Sì, quando ti ho parlato appunto di piccoli programmatori, di una contribuzione che sì c'è, però non è così, pensavo proprio al mondo e all'ecosistema PHP che adesso la butto grossa, la sparo grossa.Diciamo che il PHP un po' ha democratizzato la programmazione, almeno la programmazione web, con, pro e contro che ha causato.Chiunque a quel punto può programmare in PHP e se noi applichiamo l'etichetta di chiunque può programmare PHP a chiunque sa programmare PHP abbiamo un'incomprensione proprio alla base che in qualche modo etichetta il linguaggio in un certo modo.Però a me viene in mente WordPress, viene in mente il 70% di sistema di Cydia, adesso non ricordo, avevo visto delle statistiche.Sì, software più usato in PHP a tutt'oggi.E anche uno dei software più usati in assoluto nel web.Sì, come software back-end.Però in realtà PHP è altro, è anche altro.Che cosa rende oggi? Oggi la versione attuale è la 7.4, giusto? No, la 8, è uscita la 8.Te l'ho detto, sono un po' indietro.È uscita a dicembre dell'anno scorso.Che cos'è che rende il PHP un linguaggio moderno oggi? Secondo me è quello che hai detto tu.È un linguaggio molto democratico, la barriera di ingresso il php è molto basso, chiunque può iniziare a scrivere in php, non è un linguaggio così strutturato come può essere java o linguaggi c#, dove bisogna già mettere le cose in delle classi, tu apri un editor, scrivi minore punterettivo php e poi inizi a scrivere, puoi scrivere codice per fare un piccolo tool da linea di comando, ma non puoi scrivere una pagina intera.L'altro giorno ho letto su Twitter "remote jobs" che è una singola index PHP che fattura un milione di dollari l'anno.Si ne parlava Mike nella nostra community.Cioè ragazzi tanto di cappello.Se tu riesci a mantenere quella pagina, a metterci sopra delle feature, aggiungerla, insomma, a lavorarla va benissimo.Non è che ti piper forza avere la Gecko on 4 sulla tua scrivania, programmare gli ultimi design pattern, fare programmazione in 20, quelle sono cose che se vuoi le fai per agevolare ovviamente progetti più grandi dove ci sono tante persone, eccetera.Però PHP è bello per quello che puoi approcciare diversi livelli ed è il successo secondo me di questo linguaggio è proprio questo.Adesso con le versioni dalla 5 in poi, quindi dalla 7 soprattutto la 8, puoi approcciare anche il livello "enterprise", anche se a me questa parola mi ha sempre dato un po' fastidio, a livello un po' più da Gang of Four, cioè da design pattern, mettendoci anche delle funzionalità avanzate come il Just-in-time compiler, queste cose qui, quindi può far gola anche a chi ha sempre programmato in linguaggi più strutturati come Java.Quindi questo è successo secondo me del PHP.Tu hai citato il concetto di Just-in-time compiler, che è una delle novità di questo linguaggio.Allora ti chiedo che cos'è, a cosa serve e soprattutto quando è utile questa feature? Allora il Just-In-Time Compiler è un oggetto che lavora a livello di compilazione perché il PHP quando io scrivo uno script in PHP e lo mando in esecuzione, quello che avviene è che in una prima fase c'è il discorso del parsing, la tokenizzazione, quindi il testo proprio del linguaggio PHP viene suddiviso in vari toke, in varie parti.L'evoluzione del PHP dalla versione 2 alla versione 3 è stata proprio perché Ziv Sulavsky e Andy Gutman hanno applicato quelle che sono le best practices di un compilatore, come si scrivono i compilatori in informatica.Infatti loro erano studenti del Politecnico in Israele e dovevano fare proprio l'esame sui compilatori, quindi aveva un'esperienza di come si fa un compilatore e l'hanno rifatto, perché il PHP prima della versione 3 non aveva un concetto di compilazione, era più una roba di esecuzione al volo, di pseudocodice, quindi quella roba lì del compilatore alla fine ha come output un altro programma scritto in bytecode, che è una roba molto simile al linguaggio macchina, quindi quando io seguo uno script in PHP quello che fa il compilatore e convertirlo in questo bytecode, un linguaggio molto simile al linguaggio macchina del processore, che però non è specifico per il processore, cioè è un linguaggio un po' più astratto, però di bassissimo livello.Quindi quando io seguo uno script PHP, quello che succede è che c'è una traduzione, questi pochi lo sanno, perché io dico "beh, PHP è un linguaggio interpretato, quindi io mi immagino che linea per linea l'esecutore legga la linea e lo esegue in realtà quello che fa è un processo di compilazione creazione di questo bytecode e poi il bytecode viene interpretato quindi si crea questo file questo in memoria e io posso rileggerlo quindi anche velocizzare l'esecuzione quindi non devo ogni volta tradurre se io non vario il codice sorgente di un programma in PHP il bytecode rimane lo stesso e questa è una tecnica che si può fare per esempio andando a calcolare l'hash del file quindi se l'hash, l'MD5 per intenderci, di tutto il listato non varia allora vuol dire che l'hash non varia e quindi riutilizzo il bytecode che ho in memoria e quindi quello è il processo standard di esecuzione di un script PHP il Just-In-Time Compiler è una cosa in più perché quando io devo tradurre il codice PHP in bytecode posso anche dire "guarda, questa funzione qui è una cosa che può essere scelta o in fase di configurazione, quando vado a configurare il Just-in-Time Compiler, oppure anche da codice".Questa è una cosa molto interessante.All'interno del mio codice PHP posso scrivere tramite un commento, scritto con PHP doc, che è questo standard per scrivere commenti in PHP, mettendo a punto "jit" che è "just in time" che quella funzione lì deve essere tradotta con il "just in time compiler" e cosa fa questo "just in time compiler"? traduce quella roba lì, quella funzione, non in bytecode ma direttamente in linguaggio macchina eseguibile dalla CPU quindi detta in maniera molto semplicissima "just in time compiler" è una scorciatoia per tradurre il bytecode direttamente in linguaggio macchina e quindi ipoteticamente per eseguire più velocemente le istruzioni, proprio perché elimina questo passaggio di esecuzione del bytecode.Quando usarla? Perché è una novità nel mondo del PHP? In realtà non è così una novità perché Dimitri, che è appunto la persona che l'ha scritto, l'aveva già proposta nel PHP 7, però poi per una serie di decisioni non è stato inserito il PHP 7 e si è aspettato il PHP 8, anche per avere dei feedback ulteriori, per poterlo migliorare.Ed è molto utile per velocizzare istruzioni ripetitive, quindi se uno ha un'applicazione PHP CPU intensive, quindi fa tanti calcoli, per esempio, in quel caso il boost, il miglioramento di performance sono notevoli, perché col con il Just Intent Compiler io praticamente vado a eseguire il linguaggio macchina quindi quel ciclo, quel set di istruzioni, quei calcoli vengono tradotti direttamente in linguaggio macchina quindi il codice è molto più veloce nelle applicazioni che non sono così più intensive non c'è tutto questo boost di performance anzi, in alcuni casi addirittura c'è un degrado delle performance proprio perché c'è questo step di traduzione da bytecode a linguaggio macchina che appunto viene fatto come step ulteriore quindi per dirla in un altro modo, se uno ha wordpress, sono stati fatti dei benchmark non è così necessario gestire in comparanza fa molto io quindi fa letture da database, da file, però se tu hai un'applicazione che fa reportistica, che fa tanti calcoli a quel punto può avere senso, addirittura adesso ci sono, negli ultimi anni sono nate diverse librerie per fare machine learning in php che non è una bestemmia, può sembrare una cosa molto blasfema, in realtà no perché perché PHP è uno dei linguaggi interpretati più veloci al mondo più veloci di Python, più veloci di Ruby, più veloci di tutti questi linguaggi quindi hanno iniziato a fare delle librerie che fanno Machine Learning PHP per sfruttare proprio questa velocità a partire da PHP 7 e adesso, grazie al Just-In-Time Compiler, secondo me vedremo un trend ulteriore sotto questo punto di vista, perché il linguaggio è molto efficiente quindi c'è una tra tutte, PHPML, che ha avuto un successo clamoroso, ci sono tantissimi progetti che hanno iniziato a utilizzare questa libreria in PHP, certo che Python, visto che ce ne sono talmente tante librerie scritte per fare machine learning, data science in Python, è ovviamente difficile combattere questa community, come sempre la differenza la comunità, il numero di persone che… Faccio un altro esempio che potrebbe sembrare strano, in fisica, tutt'oggi, la maggior parte dei progetti di fisica sperimentale sono scritti in Fortran, ma non perché Fortran è il miglior linguaggio del mondo, perché ci sono tantissime librerie scritte da decenni che fanno calcoli di fisica, matematica, e è in Fortran e quindi le persone usano quello.Non è una gara tecnologica, più un discorso di community.È il fattore di massa critica che fa la differenza e questo è importante.Però c'è da dire che a questo punto l'introduzione di queste feature apre le prospettive al linguaggio, in altri ambiti dove prima l'accesso era precluso.Oltre a generare o ridurre drasticamente i costi, io ricordo nel 2016 se non mi sbaglio a un php day venne uno degli ingegneri di Badu, non so se ve lo ricordate ancora, che raccontava come l'adozione del php 7 nel loro stack è stata in grado di far risparmiare un milione di dollari o di euro.Ma stiamo parlando di cifre importanti.Un milione di dollari l'anno.L'anno, mi ero perso questo.Esatto, ogni anno.Stiamo parlando di cifre veramente significative.Quindi mi chiedo, nel ventaglio delle proposte nuove di PHP come linguaggio moderno, ho visto anche che ci sono tutta un'altra serie di elementi, gli "enamed arguments" che sono una cosa che io ho sempre amato di Python, che lo rendono molto più espressivo, le "match expressions" che per chi un po' ha fatto una passeggiata nella programmazione funzionale per rivedersela in PHP un po' fanno piacere Sono state aggiunte tutta una serie di funzioni che hanno preso ispirazione da altri linguaggi perché Community PHP è molto democratica sotto questo punto di vista, c'è proprio gli internals, se uno vuole proporre qualcosa c'è un RFC, lo scrive e poi c'è un sistema di votazione, quindi è molto democratica.Io ricordo sempre questo episodio.Anni fa è stata votata l'introduzione del "go to".Perché appunto, che non conoscesse questa istruzione, era una roba del tipo "io metto un'etichetta da qualche parte nel mio codice e poi faccio "go to" a quell'etichetta", cioè faccio un salto a quell'etichetta.Anche un salto temporale negli anni '70.Esatto, queste istruzioni qui.Che ovviamente, parlando di programmazione strutturata, oggetti è veramente una bestemmia, però il progetto è un progetto democratico, hanno scelto di introdurre questa istruzione e adesso fa parte anche se a linguaggio, per dire che il PHP è veramente democratico, sia come barriera d'ingresso, ma anche come gestione interna del progetto, ci sono volontari che poi per i progetti, per gli official grandi ci sono due o tre persone che vengono stipendiate per fare quello, Dimitri e Nikita, però per il resto sono tutte cose abbastanza volontarie, uno lo fa perché io utilizzo il PHP nella mia azienda, adesso per esempio ho un'altra cosa che è stata introdotta nel PHP 8, che però è più legata a chi vuole sviluppare estensioni per PHP, è l'observability, la di specificare delle istruzioni da eseguire prima o dopo una specifica funzione.Quindi io per esempio se voglio creare un tool di monitoring del mio codice, posso dire "guarda, ogni volta che faccio un'istruzione pdoexec, per esempio l'istruzione per eseguire una query SQL su un database, prima e dopo eseguimi questo codice".per esempio prendimi il tempo di esecuzione, prendimi la memoria, prendimi la query SQL che viene fatta, quindi immagina di avere uno strumento che facilita questa intercettazione di queste esecuzioni, di queste call nel tuo programma e puoi creare un sistema di monitoring molto efficiente, voluto per analizzare come viene eseguito il tuo codice per motivi di debug, per performance, eccetera.Nel PHP 8 è stata introdotta questa feature, è stata fatta da alcune persone che lavorano per un'azienda che ha sponsorizzato questo nel loro daily work, come succede anche con Elastic, io faccio delle proposte anche nel core, se ho bisogno per esempio di migliorare alcune cose relative al parsing del JSON dei file, perché io lavorando molto con direttore client server faccio molte chiamate ovviamente a HTTP, quindi il parsing del JSON, anche quella potrebbe essere migliore di un PHP, infatti appunto sto pensando di fare qualche proposta anche su quel versante, quindi è molto aperto come community PHP, molto democratico.Prima hai parlato dell'Observability e qua ho una domanda, questa avviene a livello C o a livello PHP? A livello C.Ah ok, no perché avvenendo a livello PHP mi apriva la mente a tutto il mondo della programmazione orientata agli aspetti.In realtà c'è una libreria per fare questo che utilizza anche dei trick perché in PHP ha anche delle API che possono essere in qualche modo, per esempio c'è una funzione che si chiama shutdown function, adesso non ricordo bene il nome, che ti permette di eseguire una funzione che vuoi tu quando termina l'esecuzione di un programma.Quindi quella potrebbe essere una cosa interessante perché io faccio una sorta di collect delle informazioni, tempo di esecuzione, memoria eccetera e posso memorizzare un database dove voglio.Ci sono delle API sparse però proprio un API per l'osservabilità è stato introdotto con PHP 8.Fantastico.Allora ci hai accompagnato al mondo o comunque all'ultimissima versione PHP 8.1 la cui release se non sbaglio è prevista per novembre 2021.Sì, la data indicativa è quella.Ovviamente parliamo da qui a novembre quindi i tempi sono lunghi poi c'è stato anche, non so se hai saputo, ultimamente l'hack che hanno fatto.Si volevo parlarne con te dopo infatti perché ho letto il tuo articolo e la discussione su Twitter.Però prima di parlare proprio del hack mi interessava sentire da te, anche perché in realtà io ci ho dato una lettura rapida, qualcosa in merito a fibers e coroutines che sono dei concetti abbastanza nuovi in un linguaggio pensato in un'ottica di richiesta risposta quali più HP che era diciamo la sua caratteristica vincente la sua carta vincente no io ti faccio una richiesta e mi aspetto una risposta tanto che framework famosi come l'aravel hanno investito un po di effort sviluppando dei tool libreria come Octane che si basa proprio su queste funzionalità.De cosa si tratta? Le Fibers sono una sorta di modalità che verrà trattata con il PHP 8.1 per scrivere delle funzioni eseguite in parallelo, quindi non c'è più il discorso della sincronicità, ma sono cose asincrone, quindi che si rifanno un po' a delle librerie, per esempio in PHP, come ReactPHP o anche a Swole, questa famosa estensione cinese che ha avuto una grossissima popolarità.Infatti una delle ultime cose che ho fatto in Zend, prima di andare via, è stata provare a integrare Swole all'interno di Expressive, che è un framework che ho scritto io e i miei colleghi in Zend.Era interessante perché io potevo eseguire un'applicazione PHP senza utilizzare un web server, come si fa in Node.Dall'intercomando io avvio il mio programma PHP e quello sta in ascolto su una porta prestabilita, un indirizzo più prestabilito e gestisce le richieste e le risposte HTTP, con il concetto di loop event.quindi c'è questo loop while true gigantesco sempre in memoria come si fa in Node fondamentalmente quindi quando c'è un evento scateno poi tutta l'esecuzione della mia applicazione e le performance erano notevoli perché ovviamente togliendo il web server e lavorando in parallelo perché ovviamente in maniera asincrona io potevo eseguire più processi a seconda dei thread della CPU su performance, infatti mi ricordo su SQOL hanno fatto appunto un sito su un singolo server che poteva avere un milione di accessi contemporanei, certo ovviamente era una sorta di hello world, però sono sempre un milione, sono tanti, sono veramente tanti.Quindi è un modo per mettere nel linguaggio qualcosa che è più semplice da usare.Se uno non ha SWOL, se uno non ha ReactPHP, fare programmazione asincrone in PHP usando i thread, perché in realtà ci sono le API in PHP per fare thread, però oggettivamente sono veramente difficili.L'ergonomia del linguaggio là! è veramente difficile da usare, hai fatto esami di calcolo parallelo all'università e poi inizia a scriverci qualcosa.Quindi è un modo per finalmente metterlo direttamente nel linguaggio e è sicuramente una cosa nuova per chi non ha mai utilizzato queste librerie asincrone, che sarà sicuramente interessante da vedere.Molte persone che hanno scritto codi scrivono in PHP, poi dovevano fare cose asincrone, allora sono passato ad un JS, adesso potrebbero tornare al PHP.Ci sono tutta una serie di casistiche interessanti che aprono, perché hanno fatto queste feature nuove nel linguaggio, proprio per cercare di coprire le richieste che vengono dal mercato, che sono quelle di scrivere delle API asincrone, in maniera semplice e snella, anche immagina appunto con doc e con i container, io non devo più avere un web server, ho solo il PHP, faccio tutto lì, anche diventa tutto più semplice l'infrastruttura, la gestione.Ti faccio una domanda che più che una domanda potrebbe anche essere una provocazione.L'introduzione delle Fibers.Non snatura un po' quello che in realtà è l'approccio tra virgolette IPHP creando una sorta di Frankenstein che fa un po' tutto? se la sai usare la puoi usare, ma se non la sai usare o non la vuoi usare sei liberissimo di continuare a scrivere il codice PHP che scrivi prima.Non ci sono grosse differenze.E' ovvio che se vuoi approcciarti a quella programmazione devi entrare in un'ottica diversa, è più tutto sincrono, cioè io faccio una, chiamo una funzione, il PHP non aspetta che la funzione termini per eseguire l'istruzione successiva, ma continua il suo flusso e questo cambia il mondo.Sì, sai il perché di questa domanda? Perché io ho sempre visto il PHP come un processo dove ogni richiesta aveva il suo bello stato che poi andava a morire, che a livello di sicurezza è una garanzia, no? Sì, certo.Condividendo lo Stato in un linguaggio come il PHP vedo che in realtà un po' dei benefici di quell'approccio si perdono, quindi sarà forse un mio limite, no? No, no, no, è corretto.Non vedo come un tornare indietro, capito, pur di aggiungere una feature che il mercato chiede, senza dubbio, perché è una feature perché il mercato richiede tantissimo.Sì, ma è questo il motivo per il quale ci sono poi dei framework che aiutano un po' l'utilizzo.Nel senso che questi framework, per esempio, quando avevo fatto l'integrazione con Swallow su Expressive, c'era il problema per esempio delle sessioni.Perché a quel punto i dati in sessione, come fai a gestirli? È un casino.e quindi...ci metti un redis che ti gestisce le sessioni e perdi il vantaggio di non tirare un webserver il punto è, quelle cose lì vanno bene per esempio per fare delle API stateless quindi rest, pull rest in quel caso va benissimo, però se tu vuoi far girare wordpress utilizzando SWALL con un architettura di questo tipo diciamo non è sicuramente la cosa migliore da fare questi concetti che fanno un po' a sbattere con la sincronicità e con la condivisione di dati in memoria.Anche perché per esempio il garbage collector PHP è veramente banale, non è una roba sofisticata, PHP non è un linguaggio che è stato progettato per stare in memoria, come Java, no? Non c'è una Java virtual machine che è sempre in memoria, c'è la virtual machine, lo zend engine, ma quella nasce e muore ogni tot millisecondi, cioè la richiesta e la risposta.Quindi sì, a livello strutturale sono d'accordo con te, stiamo parlando di potrebbe essere una forzatura, però come tutte le cose se le sai utilizzare bene per fare appunto delle API REST va benissimo.Se poi tu ci vuoi fare un'applicazione web classica, a quel punto probabilmente non hai capito bene di cosa stiamo parlando.infatti sono veramente curioso di vedere cosa fa Octan di Laravel e come le usa e se si tratta di una una questione di marketing cosa che insomma per il mondo Laravel non è così diciamo assurda nel senso che Laravel è dal mio punto di vista 70% marketing 30% codice.Altra bold opinion oggi le sto dando Parla uno che utilizza la Ravelin in progetti in produzione.A questo punto volevo passare all'argomento di sicurezza che hai accennato prima.Non tanto sicurezza del linguaggio ma quanto sicurezza nel processo di sviluppo.Qualche giorno fa, a fine marzo, se non ricordo male, il PHP è stato vittima di un attacco.Puoi dirci qualcosa in più? Il 28 marzo sono apparse due commit sui sorgenti PHP in cui c'era scritto "fixed type" in realtà erano due commit, fatte una dietro l'altra, in cui si introduceva una vulnerabilità la vulnerabilità era se qualcuno inviava in un header chiamato user agent con due T finali quindi si mascherava anche con l'header user agent classico, chiamato HTTP quel codice, il valore di quel header veniva eseguito come eval, che è un'istruzione molto pericolosa in PHP, perché io posso scrivere qualsiasi istruzione in PHP, quindi potevo eseguire qualsiasi codice remoto, una cosa molto grave.Però questa commit è stata fatta sotto la luce del sole, quindi le persone che hanno fatto la review, per fortuna c'è una grossa community attorno al PHP come linguaggio, quindi sono subito accorto di questo codice.Poi in realtà l'account con il quale è stato utilizzato era quello di Lerdorf, cioè la Rasmus, l'inventore del PHP, cioè quello che ha fatto la prima versione, quindi sembra ancora più strana questa cosa.E poi è stato fatto subito il revert della commit e dopo poche ore ne è stata rifatta un'altra con un account di Nikita, che è un altro contributor core del linguaggio molto famoso, la stessa identica che è stata ovviamente poi dopo un giro di un'ora già fatto il revert.Sicuramente è stata una cosa grave, nel senso che hanno provato a mettere il codice maligno nel linguaggio, la notizia positiva è stata che la community è talmente pronta che è subito intervenuta in pochissime ore.Poi, indagando su come sono riusciti a fare questo hack, in realtà dopo un po' di giorni, stesso Nikita che ovviamente...Se l'è presa! Se l'è presa ovviamente per questo, fondamentalmente sono riuscito ad entrare in un altro server, perché i sorgenti del PHP erano sul sito git.php.net, che era un git server gestito dalla community PHP, quindi non si usava GitHub, su GitHub c'era soltanto il mirror di questo git.php.net, e c'è un altro server, che è il master.php.net, dove per intendeci gira anche il web della documentazione, il php.net, che era un po' legacy, dove giravano vecchie versioni di web server, altri servizi, anche mi sembrano utilizzati, era non gestito, non aggiornato, quindi degli hacker sono riusciti a sfruttare una vulnerabilità di uno di questi codici, di questi software e all'interno di questo masterphp.net c'era anche un elenco di utenti e quindi presumibilmente sono riusciti a fare per tentativi a decifrare le password degli utenti di Nikita e di Erasmus.Poi, un'altra cosa legacy, questo sito, masterphp.net, aveva un accesso privilegiato su githphp.net tramite HTTP, con un'autenticazione basata su password.quindi fondamentalmente da lì sono riusciti poi a fare la commit sul sito sul git server e quindi ci hanno provato sostanzialmente.La cosa positiva di questo episodio è che adesso non c'è più il git php.net ma c'è direttamente GitHub quindi c'è stata una migrazione che in realtà era già stata schedulata diversi anni fa per motivi di tempo, come accade, perché ripeto, PHP è un progetto, sotto questo punto di vista della gestione, diciamo, di sorgente è tutto volontariato, cioè non c'è un'azienda che paga qualcuno per fare il DevOps o il sysadmin di questi server, questo forse è un aspetto su cui si potrebbe chiedere aiuto, forse, a qualche azienda di sponsorizzare anche questo aspetto, però alla fine della fiera ho detto "vabbè, è successa questa quindi facciamo migrazione su GitHub, che è già stata preventivata.Quindi questa cosa per negativa alla fine è diventata positiva, perché di fatto adesso il progetto è interamente gestito su GitHub, hanno abilitato i doppi fattori di autenticazione su GitHub, e quindi è più sicuro.Quindi questa cosa negativa ha avuto un risvolto positivo.Giusto una domanda, ma attualmente o comunque fino a questo problema, i contributor, specie i core developer, facevano dei commit direttamente sulla master branch o lavoravano per pull request? Per piccolissime modifiche, tipo tipo, loro facevano direttamente la commit però le persone con contributi normali passano sempre su una pull request se vai a vederti le pull requests che ci sono sul PHP SRC, sul repository dei sorgenti sono pull requests corpose, dove ci sono almeno 30 commenti, roba veramente lunghe Quindi passa sotto la luce gli occhi di tutti, il codice PHP è super visionato.A questo punto una domanda te la devo fare però.In un'ottica di progetti open source, secondo te qual è la soluzione migliore utilizzare dei servizi come può essere Github e quindi appoggiarsi ad aziende perché in realtà Github e Microsoft tu stai sviluppando open source ma utilizzando degli strumenti che in realtà appartengono a qualcun altro.Quindi la prima domanda è quella può essere una contraddizione e soprattutto come vedi appunto per progetti di questo tipo l'approccio del self hostare gli strumenti che utilizzi o approcciarti a utilizzare strumenti di terza parte? Allora secondo me non è sbagliato, nel senso che dal punto di vista anche etico, se vogliamo, il fatto di utilizzare una piattaforma che è guitar.com, che è nata per dare ospitalità ai progetti open source, è rimasta così perché di fatto adesso non bisogna pagare per utilizzare github.com per i progetti open source, anche se è stata acquistata da Microsoft, ma Microsoft negli ultimi anni ha fatto un cambiamento radicale dal punto di vista della politica verso l'open source, siamo passati da un'azienda che prima diceva che l'open source è il male, a un'azienda in cui adesso è la prima azienda al mondo a fare open source, di fatto i codici prodotti da Microsoft sono quelli più a livello di numerosità, di più più utilizzati, quindi c'è una grossa rivoluzione nel mondo Microsoft.Ma poi, come dicevo prima, ci deve essere sempre qualcuno che paga le bollette.I server di GitHub costano, l'energia alla corrente costa.Il punto è fare queste cose sotto la luce del sole, ci deve essere trasparenza, ci deve essere etica, questo è l'approccio poi anche l'idea di avere un server, per esempio GitPHP, quella è nata per motivi storici, cioè prima non c'era GitHub, quando è nata il PHP non c'era un GitHub, non c'erano quei servizi, quindi era l'unico modo per farlo, poi ovviamente le cose evolvono, cambiano, adesso non ha assolutamente senso dal punto di vista della sicurezza, dal punto di vista dei costi, costi, da dove la vedi la vedi, non ha assolutamente senso mettere su un kit, infatti anche nelle aziende qualcuno mi chiede "ma ha senso utilizzare il nostro kit interno?" No, assolutamente no, perché devi pagare qualcuno che deve stare lì a fare manutenzione, aggiornamenti, si deve preoccupare della sicurezza quando c'è un'azienda dedicata che fa questo al posto tuo.Abbastanza una follia al giorno d'oggi, a meno che tu non devi fare cose di secretezza militare o robe, ma a quel punto ovviamente...In realtà io non ho ancora un'opinione formata sull'argomento, infatti chiedo sempre a tutti, perché sono in quella fase dove sto raccogliendo le varie visioni, le varie prospettive per farmi un'idea tutta mia fondamentalmente però c'è una cosa che ancora non mi suona benissimo che è la questione dell'accentrare.Faccio una premessa io uso github per qualunque cosa c'è tutto il codice che sviluppo sia per lavoro che per tempo libero sta su github però c'è il concetto di accentrare tutto l'open source del mondo in un unico punto delegando la gestione a un'unica azienda e questa cosa mi sta facendo suonare un campanello d'allarme nel senso che con tutta la buona fede di Microsoft e del progetto GitHub che secondo me c'è altrimenti non ti spieghi resti di per sé è una cosa che un po mi fa riflettere sono fermo su questo su questo punto da qualche anno 4 5 anni da quando vedi un talk di un docente di un'università che adesso non ricordo che stava lavorando per fare un clone completo di tutto il codice open source, un'impresa super ambiziosa no? però con secondo me un principio a priori che è condivisibile, cioè il fatto di rendere il codice open source resiliente a qualunque altro tipo di business.Sì, capisco la tua perplessità, però se tu pensi che il codice open source per definizione è aperto, quindi tu non hai dei segreti, non vedo come queste aziende possono in qualche modo trarre, per esempio Github, come posso trarre beneficio da un software che è completamente open source.Poi la licenza è quella che fa la differenza, quella è l'arma che uno può utilizzare dal punto di vista legale per proteggere più o meno i propri sorgenti, ci sono aziende anche dove lavoro io, c'è l'AssicomongoDB che hanno cambiato la licenza per proteggersi da degli attacchi fatti per un utilizzo non proprio trasparente ed etico del codice fondamentalmente.Però se il codice è open source per definizione, se lo metti su GitHub o su un altro sito, fa qualche differenza.Si usa GitHub perché è quello più utilizzato, le persone sono già lì, la community è già lì, è più comodo.La mia perplessità sta sull'utilizzo di GitHub come una unique source of truth, un'unica sorgente di verità.Domani Microsoft diventa un evil, magari no, però domani Microsoft chiude i rubinetti però in questa chiusura quanta di questa knowledge si perde? In questa migrazione quanta di questa knowledge rischiamo di perdere? queste sono le domande, ripeto, non ho ancora risposte.Capisco la perplessità, però la knowledge la può trasferire, c'è solo una questione di dove mettere i sorgenti fondamentalmente, non è tanto un discorso etico sui sorgenti, sorgenti sono già open, quindi o li metto su un...anche perché poi parliamo, volendo andare più in dettaglio, ok, non utilizzo GitHub, cosa faccio? Utilizzo il mio server.Benissimo, dove gira il tuo server? AWS? Google? Aruba? Se vai a analizzare alla fine della fiera c'è sempre...o ti metti, come alcuni conoscono due personaggi un po' stravaganti che hanno la loro server in casa, con la linea, con il gruppo di continuità, ma parliamo veramente di cose quasi patologiche al giorno d'oggi.La cosa più importante secondo me è la trasparenza, l'etica in quello che fai, il codice è open source, di fatto già legibile da chiunque, l'unica arma che abbiamo sono le licenze e anche lì vorrebbe dire che è un'arma che non tutti conoscono o possono usufruirne alla grande, perché ovviamente se sei una società che ha alle spalle, dietro un aiuto solido, una società medio-grande, allora puoi farti sentire pagare gli avvocati pagare gli avvocati, se sei un piccolo progetto open source o vai a Free Software Foundation, ti aiuti in qualche modo qualche entità, se no è difficile che ti puoi tutelare eh sì quello purtroppo fa parte un po' della vita così come struttura, non c'entra niente, siamo rinformati Enrico La chiacchierata è stata super interessante, ma non ti lascio andare, almeno non prima che abbiamo fatto insieme questo momento.È un momento tipico e anche topico del nostro podcast.Si chiama "Il Paese dei Balocchi" ed è un momento dove i nostri ospiti, che vengono qua a bersi una birra con noi, condividono qualcosa che è stato significativo nel loro studio, nella loro carriera, un tool, un libro, un video, qualunque cosa che in qualche modo possa avere un grande valore magari anche legato all'argomento dell'episodio.Tu hai qualcosa che secondo te può essere importante da condividere con noi? Riconducono il paese dei balocchi.Ah, il paese dei balocchi.Ma guarda, tornando al discorso delle community, quindi delle persone dietro le tastiere, le conferenze, secondo me da quando ho iniziato a girare per conferenze, conoscere persone, con persone che hanno la stessa passione, che condividono il lavoro che faccio io, quella è stata la chiave di volta, cioè le persone, l'aspetto umano, vorrei sottolineare quello, che è la parte più importante in tutto, perché qui non stiamo facendo una gara che scrive il codice migliore o l'algoritmo più efficiente, anche perché per esempio io non lo reputo il linguaggio migliore del mondo, anche se ci ho lavorato e lo utilizzo da anni.C'è una bella definizione, mi ricordo di chi è, diceva che la programmazione è opinioni in codice, ed è bella perché umanizza un po' il lavoro del programmatore, che non scrivere un'istruzione ma è mettere la propria opinione in codice, cioè scrivere la propria opinione in un linguaggio diciamo il più simile per poter farlo eseguire da un computer.Credo che quello che hai detto rappresenta esattamente quello che ho nella testa in merito al codice.Per me il codice è il risultato di un'operazione di creazione, un po' come lo scrivere un libro, ti racconta anche se non parla in prima persona di te, ma ti racconta e soprattutto una volta che l'hai scritto non ti appartiene più, che è un passaggio interessante, specie nell'ambito del podcast.Io al tuo gingilo aggiungerei anche i tuoi libri.Sviluppare in PHP 7, il libro verde, è l'ultima edizione.Sì, l'ultima edizione, sì, corretto.Quindi, se vi interessa approfondire il mondo PHP, non c'è modo migliore per farlo se non con il libro di Enrico.Grazie per la sponsorizzazione, ma...Assolutamente, ce l'ho qua nella libreria quindi.Di solito tendo e non sponsorizzo e non parlo di cose che secondo me non hanno valore.Il motivo per il quale ho scritto questo libro non è sicuramente di natura economica, visto che scrivere libri in italiano tecnici in Italia è una follia.non so se gli ascoltatori lo sanno, ma il lautore di un libro tecnico percepisce più o meno dal 7 al 10% del prezzo di copertina ogni copia venduta, quindi è una follia dal punto di vista economico.L'ho fatto proprio perché non c'erano libri in PHP scritti in italiano recipienti e quindi mi sono sentito, anche perché è una cosa che non ho detto, che io insegno anche all'ITS, qui sotto al clima superiore, questi entri di formazione post diploma, ovviamente PHP, qui a Torino e quindi mi è tornato anche utile come libro di testo fondamentalmente.Ti sei rotto le scatole di ripetere sempre le stesse cose che le hai messe sul libro.Esatto, cattatevillo, scherzo.Quindi mi raccomando se volete approfondire il mondo di PHP veramente non c'è modo migliore per farlo se non leggendo questo libro che fa un po' da pripista, da priporta per approfondimenti ulteriori.Io Enrico ti ringrazio di cuore.Grazie a te Mauro.Spero di poter bere una birra con te dal vivo prestissimo.Ti ringrazio a nome di tutta la community che tanto aspetta questo episodio.Grazie a tutti, è stato veramente un piacere fare due chiacchiere con te.Grazie a Enrico che oggi ci ha tenuto compagnia parlando di PHP.abbiamo tantissime altre interviste programmate e anche dei panel con gli ammuttinati dove tratteremo di una serie di argomenti anche l'argomento licenze lo prometto perché è importantissimo per il lavoro che facciamo detto questo io vi do appuntamento alla prossima settimana ma non prima di avervi ricordato rapidamente i nostri contatti info@gitbar.it @brainrepo su Twitter oppure direttamente nel nostro gruppo Telegram.Mi raccomando se avete un iPhone aprite l'applicazione podcast e lasciate una recensione.Questo aiuterà a far arrivare il nostro bar degli sviluppatori a più orecchie possibile e far crescere la nostra community.Io vi do appuntamento alla prossima settimana.Da Lion è tutto.Ciao! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
