Bene e benvenuti su GIT BAR, nuovo anno e nuovo set di ospiti qua per il nostro bar degli sviluppatori Dopo l'episodio che avete sentito sui GIT FIGHTERS, il cui vincitore è stato Davide Di Pumpo che con la sua capacità dialettica ha steso gli altri contendenti adesso ritorniamo al nostro format di default, le interviste.E oggi abbiamo un ospite speciale ma prima di svelarvi il nome e di presentarvelo.Il mio ruolo ormai da un anno lo sapete è quello di ricordarvi i nostri contatti quindi info@gitbar.it via email @brainrepo su twitter oppure il nostro fantastico gruppo telegram.Tra l'altro qualche giorno fa c'è stata una super discussione quindi se non l'avete ancora fatto iscrivetevi lo trovate scrivendo gitbar nella casellina di ricerca di Telegram.Detto questo ho rubato fin troppo tempo quindi ci prendiamo giusto un attimo e poi iniziamo Benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer I mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo eccoci qua mi trovo con Alessandro Lai direttamente da facile.it se dovessi descrivere Alessandro non saprei come farlo credetemi ma questo ormai capita un po' con tutti i nostri super guest Allora Alessandro è team lead developer a facili puntuiti come vi dicevo ma è anche segretario del phpfig poi direttamente lui ci spiegherà che cos'è e quale ruolo ha il phpfig.E' una delle colonne portanti dal 2017 del pug milano e fa altre 50.000 cose ma io non vi spoilerò troppo e vi presento Ciao Alessandro, come va? Ciao Mauro, grazie per avermi dato questo invito, questa possibilità, piacere di essere qui.Il piacere è tutto nostro.Io, sai, ho una marea di domande da fare, tante curiosità da chiederti.La prima cosa che ti voglio chiedere è se oggi Alessandro si dovesse guardare allo specchio, lato professionista, come si descriverebbe? Chi è Alessandro, per capirci? Allora, sono uno sviluppatore dal passato un po', cioè dalla carriera un po' strana, nel senso che ho fatto dei cambi un po' anomali.Ho cominciato, come tanti, studiando informatica all'università e ho sempre avuto due, due due interessi divergenti, diciamo.Da una parte, quello che poi sono finito a fare, che è il PHP e il web, che ho sfiorato, ma che durante gli studi non ho mai approfondito bene.E dall'altra, un po' gli algoritmi e le cose di un po' più di basso livello, e l'informatica grafica, quindi C++, algoritmi geometrici e cose del genere.Tanto è che il mio primo lavoro a lungo termine, così vogliamo definirlo, è stato in una piccola azienda di Sarda, che possede a Quarto, vicino a Cagliari, dove facevamo un CAD per topografie.Quindi una roba che è proprio lontanissima dalla mia carriera attuale.E mi sono divertito tanto.Ho riscritto con un collega più esperto di me un intero modulo di progettazione stradale.Quindi, come capita spesso a noi sviluppatori, impariamo le cose più disparate e più strane.Poi però appunto sono passato o ritornato tra virgolette al PHP, ma non tanto per il PHP in sé, ma perché mi sono fatto convincere al passare in un'azienda che è qui, è ancora facile, quindi forse a differenza di tanti miei colleghi non ho fatto il salto di cambio lavoro ogni due anni, come va di moda nella nostra professione, mi sono fatto attirare più che altro da quello che mi mancava, cioè lavorare in un'azienda un po' più grande, lavorare facendo tante cose bene, nel senso di tutte quelle belle pratiche di cui tanto si parla, sai, di testing, continuous integration, i progetti a lungo termine, tutte queste cose che poi alla alla fine mi piacciono tanto.E quindi è stato quasi un incidente il fatto che si trattasse di PHP, nel senso che sì, poi in realtà mi piaceva, ci avevo già messo il naso, eccetera, ma non è stato quello a portarmi a fare questo cambio.E come dicevo poco fa, ho ottenuto questa scelta per tantissimo tempo.Ormai sono sei anni e mezzo che lavoro in facile, che è ovviamente tanto.E non solo neanche il classico sviluppatore che salta di stack tecnologico ogni tre per due.Forse anche...Beh, questa è una scelta figlia di questa mia storia, no? Nel senso che quando ho fatto questo cambio mi rendevo conto che rispetto a tanti altri colleghi sviluppatori ero un po' indietro, no? Mi sono trovato a...Avevo 26 anni e non avevo ancora approfondito bene il mio stack tecnologico, perché sul CPU+ me la cavicchiavo, ma non l'avevo mai esplorato bene.Sul PHP stavo quasi ricominciando da zero e mi sono trovato a dire "beh, cavolo, però forse è il caso che la smetta di spaziare e approfondisca le mie skill in maniera mirata".E forse questo è anche il motivo per cui sono rimasto così tanto tempo nella mia azienda, perché ho avuto lo spazio di poterlo fare, per tanti motivi, di lavoro e non poi in realtà.Perché appunto mi sono focalizzato tantissimo su PHP, su Symfony e sulle cose che il mio lavoro mi portava da fare tutti i giorni e mi è piaciuto tanto.Mi è piaciuto tanto perché al di là di tutte le critiche che il PHP può ricevere, per tutti i difetti che può avere, in realtà adesso posso dire di essere saltato un po' sul carro del vincitore, perché l'ho detto spesso a tanti miei colleghi che invece facevano PHP da molto più tempo di me, che ho saltato in pieno tutta quella fase del PHP brutto, passami il termine, in cui non c'erano gli oggetti, in cui mischiavi la logica ai template, in cui non esisteva composer, in cui non c'erano le dipendenze, queste cose belle.Io sono arrivato nel momento in cui il linguaggio è partito per la tangente e ha cominciato a migliorare a un ritmo sempre più rapido.Il modo forse più sintetico per riassumere questa cosa l'ho sentita da un altro podcaster come te, che è Cal Evans, col cal come piace farsi chiamare, lui la chiama il rinascimento del PHP.Lui dice ci sono stati tre pilastri portanti che se non ricordo male sono composer, PHP unit e me ne manca un altro che adesso non ricordo, però fondamentalmente queste cose sono le robe che hanno fatto svoltare pagina al mondo del PHP e che l'hanno fatto decollare.Quindi ho proprio vissuto la fase di "abbandoniamo la 5.3" che è stata una buona grossa milestone, passiamo alla 5.6 e poi tutta la corsa dalla 7 in su che ha portato davvero tanta tanta aria fresca in questo ambiente.Assolutamente.Tu ti sei saltato quindi tutta l'epoca del PHP 3 che è stata un bagno di sangue credimi.Io ricordo ancora quelle notate e ancora rimangono tracce di quell'epoca con un API alle volte un po inconsistente.Io ricordo che proprio Rasmus a un phpday fece una una una una una sparata e una parte del tool che era appunto sulla consistenza che lui chiamava "consistenza verticale col C.Cioè i nomi delle funzioni sono allineati ai nomi delle funzioni in C e quindi sono consistenti a modo loro.Mi ricordo che questo aneddoto l'abbia ripetuto da poco quando ha fatto un altro giro di presentazioni su BHP 7.4, se non ricordo male.Effettivamente io venendo dal C++ un po' mi ci ritrovavo, però sì, cioè non è...Sai cos'è? Però mi sempre è sembrato un commento un po', boh, un appiglio stupido.Se proprio devi criticare il PHP ci sono tante altre cose più sensate da dire.E quelle, soprattutto il giorno d'oggi in cui, cioè, hai talmente tanti aiuti allo sviluppo da dall'idea di turno o qualunque altra cosa, boh, se proprio devi trovare delle difficoltà delle cose brutte nel linguaggio ce ne sono davvero di più di più consistenti e più importanti nel lavoro di tutti i giorni di noi sviluppatori.Sì, beh per me in realtà la consistenza nel linguaggio è importante ma penso dipenda molto anche dal punto di vista personale dell' approccio del linguaggio.Io per esempio sono andato a cercarla.Cioè è da dire che però una volta che ci fai la mano conosci quelle funzioni delle API base del linguaggio alla fine le usi.Come dici tu, alla fine abbiamo PHPStorm che scrivi A e sai già tutto quello che puoi fare.Tra l'altro, non voglio esagerare, però molto del successo professionale del PHP dipende anche da un editor abbastanza figo come quello che insomma si ha a disposizione con PHPStorm.Tu lo usi? Sì, devo dire che non tornerei indietro, nel senso che effettivamente è veramente veramente molto potente e fa lavorare veramente a una velocità che è imparagonabile secondo me.Sicuramente richiede avere una signora macchinina perché non è che puoi andare come con un text editor, però è veramente veramente molto molto molto potente come strumento e se si lavora principalmente di PHP non mi puoi non consigliarlo.In realtà credo che anche parte del merito in quest'ultimo forse anno e mezzo, due anni, lo si debba dare anche a JetBrains, nel senso che hanno cominciato proprio a intervenire a livello di community, a livello di sponsorizzazioni, per dire hanno assunto Nikita Popov che è praticamente il fautore degli ultimi degli ultimi delle ultime spinte del linguaggio quindi l'hanno letteralmente pagato per portare avanti il linguaggio e soprattutto dopo la debacle di Zend che ha licenziato ha mollato la barca, poco cacciato perché poi quel lì c'è stato un po' di mistero siccome se ne andate davvero le cose però nel momento in cui appunto è venuto a mancare un supporto corporate dall'azienda storica sono subentrati e l'hanno fatto tra l'altro in maniera molto molto pulita, nel senso non è che hanno fatto un assalto alla diligenza.Esatto, hanno detto "ok contribuiamo a livello di community", non hanno comprato qualcosa, hanno semplicemente detto "noi il il soldo ce lo mettiamo, è ovvio che loro ne abbiano più ovviamente un ritorno d'immagine, un ritorno in termini di influenza sul linguaggio, però hanno letteralmente preso la persona che più contribuiva al linguaggio e l'hanno assunta e pagata per continuare a farlo.E questo insomma è tanto di cappello.Tra l'altro non credo esista niente di paragonabile nel mondo PHP a PHPStorm, non credo di aver visto niente del genere.No, effettivamente no.come ambienti di sviluppo intendo, non come internet.L'unico motivo sensato che ho sentito per non usarlo è se proprio non ti piace l'idea, avere un'idea e vuoi un text editor più semplice, quindi un VSCode piuttosto che un Vim, è l'unico caso in cui posso capire che uno non lo voglia utilizzare, a parte il fatto che ovviamente non è gratis.Insomma, però diciamo che vale i soldi, soldi vale i soldi anche perché se tu ci lavori tutti i giorni quei 120 euro ho rinnovato l'abbonamento l'altro giorno 120 euro qualcosa 119 se li vale tutti se sono 10 euro al mese ci pigli una pizza se non sbaglio poi va a costare meno di anno in anno con il nuovo se non ricordo perché hanno cambiato il pricing da un po di tempo da 4 anni circa costava però 200 euro e poi via via scende fino a 103.Adesso non ricordo precisamente.La cosa interessante è che hanno una licenza molto particolare che è quella per la quale se tu compri l'abbonamento oggi, adesso non so quali versioni, credo sia tre versioni prima o due versioni prima, due versioni minori prima, quella è tua, hai una licenza perpetua.Ah sì.Su quello.E questo è molto interessante anche per il più io adesso ormai lo rinnovo di default quasi mi son dimenticato di disattivarlo ma perché perché anche sviluppando cmp hp è super performante alle volte quando è in javascript scusa quando hai bisogno veramente di autocomplete un po più spinto dei cosetti ne mi capita di doverlo usare e anche perché il plugin di vim funziona un po meglio di come funziona dentro WS Code.Non sono un fan di Veeam, io sono proprio della scuola opposta, però ho avuto anche collega che invece era fanatico di queste cose e apprezzavo anche per quello.Sì, si presta molto bene.Però torniamo al cintura degli attrezzi, ah finalmente in italiano, dello sviluppatore PHP.Cosa c'è nella tua cintura degli attrezzi? Allora, come dicevo io ho cambiato lavoro per il discorso del testing e quindi nel mio caso PHP Unit è un must, non se ne esce.Sicuramente un'applicazione senza test ormai non penso di riuscire a scriverla.Penso che addirittura mi è capitato di fare sotto le vacanze, sai "Advent of Code", quel sitarello? Anche quello lo faccio con i test.Ormai non faccio td di spinto, però ormai per me il test è proprio un must.Sicuramente "Docker".Appena arrivato a "Facile" ancora avevamo Vagrant e piangevamo proprio lacrime di sangue per la lentezza.Siamo subito saltati su Docker appena è cominciato a spuntare nell'ecosistema.È un altro must.Mezz'ora di provisioning.Sì, no, no, mai più, proprio.Non ne posso più fare a meno nemmeno di quello.Prima utilizzavo Fing, che per chi non lo conosce è un porting di Ant in PHP.adesso invece mi sono convertito a usare make, fondamentalmente in tutti i miei progetti fai make setup e quello si accende come un albero di natale e poi vado a utilizzarlo anche per lanciare singoli task, magari c'è un make test o addirittura in genere c'è un make pre commit che fa i check prima di committare e poi sicuramente negli ultimi due anni ho cominciato a tirar dentro PHP stan e poi Psalm.Tra l'altro li consiglio entrambi, li uso entrambi.Ecco poi ti faccio una domanda sugli analizzatori statici, è perché usare uno o l'altro? O in questo caso perché usarli tutte e due insieme? Esatto, esatto.Sì, no, appunto per chi non riconosce sono degli analizzatori statici del codice, quindi significa che semplicemente leggendo il codice ti possono segnalare errori, lo stesso tipo di errori che un IDE ti può segnalare, perché poi l'idea fa la stessa identica cosa in realtà, semplicemente lo fa mentre scrivi invece che da riga di comando.Però sì, ormai anche quelli per me sono un must.Hanno preso subito piede nel mondo dell'open source, ma una volta che sono maturati un minimo adesso sono decisamente un must anche dal punto di vista dello sviluppo professionale.Ci vogliono, ci vogliono.Voglio farti una domanda.Allora io ho avuto modo di utilizzarli entrambi.Tu hai parlato di testing e di testing unitario introducendo PHP Unit, no? Tra l'altro ambito nel quale sei super ninja proprio perché poi ne parleremo.Io ho avuto modo anche di provare PHP Spec e di utilizzare PHP Spec.Dal tuo punto di vista quali sono le differenze e secondo te perché ha senso utilizzare uno o l'altro tool? Allora ti dirò io PHP spec non l'ho usato quasi per niente, uso Proficy che è un sottotool di quel gruppo lì, più che altro mi sono sempre sentito parlare soprattutto a parte anche Samuel Lilli che è un grande promotore del tool e tante volte ha fatto talk in italia per esempio in merito da quello che so alla fine la grossa differenza è il fatto di ragionare col gerking no col fatto di ragionare con scenari con quello quelle di at php spec sto confondendo e fa lo spec testing quindi al posto di fare il test unitario la specifica della classe è un approccio un po' diverso.Se non sbaglio vanno in tandem.No, allora PHP spec non posso dire di conoscerlo bene, nel senso che ho sempre trovato un po' strano, strani test che mi è capitato di leggere, mi è capitato di interagirci quando a me capitava qualche progetto, spesso open source, che lo utilizzava.Non l'ho trovato molto leggibile, il test scritto in quella maniera, perché non è molto esplicito.Ha tutta una serie di convenzioni su come il test viene scritto e su cosa esso implica nel descrivere l'aspect di ciò che stai testando.Non so se l'ho visto usare male o se è proprio quello, ma mi è sembrato proprio che andasse a testare in maniera strana, nel senso che quasi va a sconfinare nel testare le parti private dell'oggetto a volte.E mi è sempre puzzato come approccio.Non ci sono mai ritrovato.>> DL: PHP Unity lo trovo molto più pragmatico del PHP Sphere.esatto, esatto, per quello mi piace di più.Alla fine, a parte che è molto meno opinionato come strumento, cioè ti dice "tu scrivi il tuo test e vai dritto per dritto" e quindi ti dà modo di usarlo come vuoi tu, in realtà.E mi è sembrato di vedere che, più o meno, da quel punto di vista, finché si rispettano quelli che sono i buoni principi del testing, funzioni molto bene, alla fine.È un altro tool che tra l'altro è migliorato tanto negli ultimi anni, ha aumentato la cadenza delle release e si è pian piano liberato di tante, diciamo, reliquie del passato, di come veniva usato in passato, di quante scorciatori aveva sotto il cofano, di quanto codice legacy, diciamo, aveva.Tra l'altro credo che a breve debbano fare un altro salto inserendo un sistema ad eventi nel runner di esecuzione di PHP Unit.Quindi direi che da questo punto di vista è un tool che è rimasto bello fresco nell'ultimo tempo.Beh io un po' mi sono scollegato da quel mondo però ricordo che l'adduzione era assolutamente massiva, cioè non c'era progetto che non avesse almeno qualche test unitario fatto con php unit.sì assolutamente.ti voglio fare un'altra domanda che è collegata al mondo del testing ma in realtà lo prende da un'altra direzione.l'introduzione di un sistema di tipi su php è stata una delle rivoluzioni del php no? assolutamente.che ha reso il php un mondo migliore dal mio punto di vista.Con l'introduzione di questo sistema di tipi sono apparsi e non solo forse anche già da prima usando le apposite annotation sono apparsi analizzatori statici di codice come phpstan e phpsalm.Qual è la differenza tra i due? E come ti dicevo prima perché scegliere uno l'altro o entrambi? Qual è il valore che questi strumenti aggiungono nella tua codebase? Allora come dicevo prima di fatto fanno la stessa correzione che ti può suggerire un IDE, la classica sottolineatura rossa o gialla mentre scrivi del codice e la La cosa bella è che possono farlo nel giro di pochi secondi su tutta la codebase, perché devono solo leggere il codice.Sicuramente sono due strumenti che vanno a braccetto con l'uso di codice tipizzato, quindi qui c'è un po' una scuola di pensiero, diciamo, soprattutto all'interno del PHP, o meglio, due scuole di pensiero contrapposte.Cioè, da una parte, chi preferisce pesantemente il duck typing e usare pochi tipi, e sfruttare un po' la magia di typecasting che ha APHP.Dall'altra, chi invece è come me, ammetto candidamente di essere di questo partito, preferisce spingersi molto di più nella scrittura di tipi sempre più stretti, sempre più rigidi.E questa cosa si sposa bene con questi strumenti perché più si scrive il codice tipizzato, più questi strumenti sono in grado di inferire più informazioni sul codice che viene scritto.Diciamo che io lo vedo un po' come un puzzle, no? Fondamentalmente più scrivi dei tipi stringenti più i pezzi del puzzle sono anche più difficili a incastrare tra loro e quindi arrivi, secondo me, a un certo punto in cui o i pezzi si incastrano o hai scritto un bug, fondamentalmente.Non c'è più gioco tra i pezzi che stai a scrivere, non c'è possibilità di incastrarli male, fondamentalmente.E questi due strumenti secondo me aiutano in questo senso, cioè siccome ragionano sui tipi, ti sanno dire se stai incastrando male i pezzi, di fatto.E scrivere tipi più stringenti ti permette di eliminare delle combinazioni che sarebbero fondamentalmente sbagliate.Il bello di questi tool è proprio questo, cioè tu li fai girare e prima ancora di far per girare i tuoi test, quindi prima ancora di eseguire il codice, solo leggendolo, questi tool ti sanno dire "No, guarda che qui è sbagliato", "Guarda che questa condizione è sempre vera o è sempre falsa", "Guarda che questo tipo qua non si incastra bene con quest'altra chiamata qua", "Guarda che qui non è controllato che questa variabile potrebbe essere null".E sono tutte cose molto molto interessanti e che rubano un concetto dal testing, in particolare dal TDD, il fatto di avere un ciclo di feedback velocissimo.Perché sono dei tool che, grazie alla rapidità, al fatto che non devono eseguire codice, grazie al fatto che hanno un minimo di layer di caching, possono analizzare un milione di righe di codice in meno di un minuto, fondamentalmente, se non anche meno se li viene eseguito più e più volte.E quindi ti danno, a differenza del testing, una copertura totale del 100% subito.Possono spaventare un po', perché introdurrli di botto in un progetto già avviato, esatto, si accende come un albero di Natale con 4.700 errori.Però per fortuna hanno dei meccanismi di baseline, come lo chiamano loro, praticamente tu gli puoi dire "va bene, tutto quello che c'è adesso, ignoralo".Esatto, fai finta di niente, chiudi un occhio.Quindi viene generata una baseline che è un elenco degli errori che tu staticizzi di fatto, rendi, scrivi e da lì in poi puoi anche usarli a livello massimo di analisi, di strictness nelle regole applicate e essere sicuro che puoi solo migliorare.Questo secondo me è ottimo come approccio perché fondamentalmente quello che succede è che applichi la cosiddetta regola del Boy Scout, no? ogni volta che tocchi il codice, sei costretto a rispettare il livello di analisi che ti sei impostato, ma siccome ogni volta che tocchi il codice stai toccando anche qualcosa che era preesistente, sei costretto anche a risolvere una manciata degli errori che avevi messo nella baseline.E quindi, piano piano, commit su commit, vai a erodere questa baseline fino ad arrivare a una situazione in cui finalmente la baseline non ce l'hai più e il tuo codice è proprio un orologio svizzero a quel punto.se davvero, come io spingo, vincioso di quel partito, se davvero hai usato i tipi a tuo favore, arrivi in una situazione in cui quella roba lì ti segnala degli errori talmente in fretta che tutta una serie di bug diventano impossibili, non riesci più a scriverli fondamentalmente, perché se li scrivi, Piakapistan o Psalm si incavola e ti dice "no, questo non è possibile".La prima cosa che per me aveva colpito, una delle prime volte che avevo utilizzato PHPStan in un progetto proprietario, quindi non nell'open source.Avevo un progetto che funzionava, no? Avevo anche una buona coverage, 85-90% di test coverage, test unitari, funzionali, di tutti i tipi.Mi ha beccato un bug lo stesso.Avevo banalmente cannato...C'era tipo un if, qualcosa diverso da base64 encode.non mi ricordo cosa ci avevo messo ma fondamentalmente avevo sbagliato tipo, avevo sbagliato che quella funzione, quel tipo lì non lo ritornava mai e lui ti diceva "no, guarda che questa roba, questo if non passerà mai".Non entrerà mai qua dentro.Non entrerà mai, sì, era un check che verificava che il valore di ritorno non avesse un errore, che è una delle rotture principali del PHP dal punto di vista, cosa che secondo me puoi criticare, cioè il fatto che alcune funzioni del core invece che tirare un'eccezione, ritornano false per esempio, e lì col juggling dei tipi è un attimo sbagliato.E PHPStand mi ha beccato questa cosa, mi ha beccato questa, mi aspettavo un valore di errore che in realtà non sarebbe mai arrivato da quella funzione, che quindi il mio check era assolutamente inutile.Inutile.Poteva esplodere subito dopo e io avevo scritto il mio bellissimo check con "throw exception", si è rotto, attento, hai sbagliato qualcosa, no.Era completamente inutile.immagina se avessi moccato la funzione per fare un test su quel branch proprio del liv che perché capita a me è capitato più di una volta cioè che poi vai a testare i tipi con dei test unitari perché in php l'abbiamo fatto tutti, testare i valori di ritorno chi è che non l'ha fatto sfido chiunque ed è un tipo di testing che ti viene completamente eliminato da quel punto di vista.Cioè se ti alleggerisce anche la tua test suite, quindi meno test da mantenere vuol dire anche essere molto più libero, avere meno codice che ti diventa obsoleto, perché anche i test diventano obsoleti alla stessa velocità con cui diventa obsoleto il tuo codice.Sì, sì, quella è una cosa che per esempio PHP Start suggerisce in automatico.Io me ne sono accorto migrando spesso del codice a PHP 7, che cominciamo a mettere i tipi dappertutto.Come metti i tipi di ritorno, lui comincia a sottolinearti tipo assert instance of nei tuoi test e ti dice "guarda che inutile perché la firma di quello che stai testando ti dice già che il tipo è quello".Ho eliminato tonnellate di righe di questo tipo perché appunto prima con PHP 5 eri costretto a verificare che il tipo fosse quello corretto oppure anche manate di if subito dopo l'inizio di una funzione per per assicurarti che l'argomento fosse del tipo giusto.Sicuramente grazie a queste cose anche il codice diventa più sintetico e più veloce da leggere.Hai un sacco di check in mano da fare.Assolutamente sì.Ti faccio una domanda.Prima comunque stavi parlando di PHPStan ed i PHPSalm.Perché li usi insieme? Qual è il valore che ti dà usare insieme? Perché sono un po' diversi.Sono un po' diversi nel senso che adesso non conosco bene degli internals, ma so che usano due approcci diversi per interpretare il codice, diciamo, quindi per capire i tipi e inferire i tipi delle variabili che girano nel tuo codice.Ma il punto è che nella pratica mi sono reso conto che, a parte gli errori più banali che tutti e due individuano, tendono ad individuare a volte sulle finezze tipi di errori differenti.PHPStan è un pochino più rapido e più veloce.Infatti, quello che io faccio normalmente è questo.Normalmente scrivo codice, poi usando Make, come dicevo prima, normalmente lancio in Make una serie di target in sequenza, che sono CodeStyleFix, quindi corrego il CodeStyle, quindi uso PHP CSS Fixer e automaticamente si ripulisce tutto.PHPStamp, PHPStan, Psalm e poi solo dopo i test.Per il funzionamento di Make, appena ne fallisce uno, si ferma.Continuo con questo rimbalzo tra IDE e console, lanciando questo target finché non vado verde, ok? E quindi li considero quasi un pre-step ai test, perché mi assicurano che quello che ho scritto non è scritto fregneancia, perché spesso capita che anche scrivendo un test, anche scrivendo proprio la verifica stessa del codice che sto scrivendo, intercettano errori ben prima di eseguire il codice.E quindi mi permettono di dire sì, come dicevo prima con l'analogia del puzzle, ho incastrato bene i pezzi.Diciamo che lo stesso step che vedresti tra un test unitario un test di integrazione lo vedo anche tra una analisi statica e test unitari, perché tutta una serie di errori che dovresti verificare facendo esecuzione di codice, li puoi intercettare ben prima e verificare che tu non abbia scritto.Io li faccio girare anche sul codice dei test, per esempio, e arrivano a segnalarmi "guarda che è scritto una sezione che non ha senso, perché quella roba lì non sarà mai di quel tipo", oppure, al contrario, mi capita molto più spesso roba del tipo "guarda che questa asserzione non la puoi scrivere perché questa roba che stai tentando di verificare potrebbe essere null".Allora prima ancora scrivo un'altra asserzione in cui dice "non è null ma è del tipo atteso" che sembra una perita di tempo, no? Perché il test fallirebbe in entrambi i casi.Però non è esattamente così perché se tu scrivi un'asserzione in più l'errore del tuo test è più preciso.se ti dice non è che ti dice ah cavolo null pointer exception o come cavolo la vuoi chiamare PHP e ti scoppia quella regola la devi guardare, guardare qual è la chiamata che è scoppiata, no, prima si riesce che non sia null e quindi l'errore diventa mi aspettavo che fosse tipo fu ed è null e quindi e quindi sai già qual è la cosa che stai sbagliando e quindi mi spinge anche a scrivere del codice migliore.Fondamentalmente usare questi tool ad alto livello, cioè alzando molto il livello di strictness dell'analisi, ti spinge a scrivere il cosiddetto codice difensivo, cioè a controllare bene prima di agire sulle tue variabili che le variabili sono tutte corrette, del tipo giusto, che tu abbia intercettato tutti i casi di errore.Cioè per esempio una cosa che mi ha spinto a fare, diciamo sempre prima, no, delle funzioni PHP che restituiscono false o roba del genere, quando falliscono.Sto usando una libreria che si chiama Safe, che praticamente ti dà un'alternativa alle funzioni che si comportano in questa maniera.Levwrappa e tutte le volte che falliscono tirono un'eccezione invece che ritornare false, null o -1 o qualunque altra schifezza ci sia in giro.E questa cosa viene intercettata da questi analizzatori statici, perché vedono che dopo che quella funzione ha girato, o il tipo è valido o c'è un'eccezione.Quindi proprio il flusso dell'esecuzione viene biforcato, fondamentalmente in quei punti.Ed è fantastico perché significa che, per esempio, usando questa roba, non devo neanche scrivere "if ritorno è false, allora è un errore, quindi cosa faccio?" No.So che lì può passare, so io solo se.E quindi un sacco di volte, in cui magari avresti scritto quel "if" a vuoto, perché magari in realtà sai che a monte non può mai arrivare un valore non valido, eccetera, te ne puoi fregare, scrivi una sfizza di queste robe.Oppure un'altra cosa che ho aggiunto, sempre perché si integra bene con questa analisi statica, è la libreria di assert.Credo, se non sbaglio, sto usando quella di WebMozart, che contiene delle annotation che vengono lette da questi analizzatori statici, E quindi invece che fare if diverso da null, oppure if uguale a null, true exception e robe del genere, scrivo direttamente un assert, perché magari certe cose posso in realtà darle per scontate a livello di visione di insieme del mio codice, perché so per esempio che, che ne so, magari una variabile in ingresso, sono in un controller, una variabile in ingresso è un parametro dell'URL.So che non potrà mai essere una stringa vuota, perché altrimenti il router non avrebbe fatto matching.Però a livello di codice, a livello unitario, non posso darlo, o a livello ancora più basso, di analisi statica, non posso darlo per scontato.E allora scrivo un answer.Non devo scrivere un if, throw, exception, perché quella roba lì non sarò mai in grado di testarla, non potrò mai entrare in quel ramo del codice.Scrivo un answer, che mi costa poco, e mi assicura, appunto, come dicevo prima, fa del codice difensivo, mi assicura che elimino tutte quelle combinazioni che non esistono, quegli stati che nel mio codice non dovrebbero esistere.E lì, come dicevi tu prima, anche i tipi riducono.Stai solo stringendo col paraocchi il più possibile tutto quello che il tuo codice può eseguire, invece che lasciarlo alla magia del typecasting.è arrivato la rovina Altro giorno così per provare ho inserito il pulsante di buy me a coffee all'interno del sito di github come sapete, perchè ne ho parlato con voi nel gruppo telegram questo periodo è stato un po' combattuto sul fatto di mettere la possibilità di contribuire alle spese di Gitbar e alla fine ho ceduto anche se devo dire non ne sono ancora pienamente convinto.Comunque ho messo questo pulsantino e la cosa veramente particolare è che davvero poco, pochissimo tempo dopo la pubblicazione ho visto che è già arrivata la prima donazione a supporto e quindi Io devo ringraziare a Eugenio, Eugenio Carocci, che ha invitato la prima birra virtuale all'interno del Gitbar.Quindi insomma, beviamo tutti alla salute di Eugenio che ci ha invitato questa birra e ha lasciato un messaggio che dice "miglior podcast in assoluto per chi sviluppa software e lo vuole fare nel migliore dei modi".Grazie a te Eugenio perché con questa donazione ci offri una birra a tutti e sai quanto amiamo la birra no? Grazie quindi Eugenio a nome mio e di tutti gli ascoltatori di Geekbar.Detto questo possiamo proseguire Ti faccio una domanda io ti ne presento è che non ho mai approfondito PHPStan e PHPSalm, quindi potrei dire delle imprecisioni e ti prego di correggermi qualora lo facessi.Ho notato che uno funziona andando a leggere i tipi direttamente dal tuo codice, l'altro utilizza delle annotation.Giusto? Ho notato male? In realtà adesso tutti e due leggono un po' le annotation, però diciamo che le annotation spesso e volentieri sono un po' un'ultima spiaggia, nel senso che ti permettono di esprimere quello che il linguaggio non ti dà.Ed è anche uno dei motivi per cui questi due strumenti stanno spingendo avanti il linguaggio, quindi là dove la gente si rende conto che "ah cavolo, ma questa cosa la vorrei esprimere, ma non ci riesco col linguaggio", allora puoi aggiungerci, insomma, degli aiutini.Una delle cose più belle che ho potuto aggiungere con le annotation sono i generics.Una delle cose che la gente chiede al PHP da millenni, che sono proprio il sogno di tutti gli sviluppatori PHP, ma purtroppo sappiamo se le abbiamo già aggiunte.Anche perché le union types, se non ricordo male, ce le hanno già date.Sì, le union types le hanno appena aggiunte, ce le hanno dati, esatto.Le union types ce le hanno dati, quindi evviva.Però, capisci, una delle cose aggiunte sulla spinta di questi però i generics sono ancora complicati.Con le annotation puoi scriverli.In pratica devi scrivere in cima alla tua classe, metti tipo template T, quindi hai un segno a posto T, e poi devi scrivere il fatto che stai facendo un generic di un certo tipo.Quindi puoi fare, all'esempio più banale, puoi fare il generics degli array.degli array.Quindi puoi scrivere array aperte quadre per esempio string virgola int.Cosa significa? Che è un array che ha come chiavi sempre delle stringhe e come valori sempre degli interi.Non è roba banale, cioè il fatto di poter specificare che l'array non è la qualunque, come spesso capita in PHP, ma che contiene delle cose precise è una bella roba.Un'altra cosa che puoi aggiungere con le annotation sono addirittura proprio la la forma della rece, puoi proprio dirgli c'è la chiave PIPPO, la chiave PLUTO e la chiave FU e ognuno gli puoi dire PIPPO è un intero, PLUTO è una stringa e FU è un oggetto di tipo bar e lo sa, cioè il tuo analisiatore statico da lì in poi sa che quella variabile ha quel contenuto.Altri linguaggi hanno già nativamente questa possibilità sicuramente, secondo me questa è la scalinata in quella direzione per PHP, per salire in quella direzione e arrivare in una situazione in cui non è più una stampella data ai tuoi strumenti ma è qualcosa che può essere utilizzato a runtime, dal tuo codice letteralmente.Ti faccio una domanda, ormai l'utilizzo dei tipi sta andando sempre più di moda no? guardati TypeScript che tra l'altro io adoro, non so perché ma lo adoro alla follia, guardati PHP con l'adozione dei tipi.Ma cosa è cambiato? Cioè io ricordo che negli anni 90 il ducktyping e i linguaggi dinamicamente tipati erano un must, cioè era la cosa più figa da poter adottare, mi immagino no, ai primi passi dell'adozione di Python.è il contrario in questo senso, è vero.Ma anche JavaScript che era JavaScript, insomma, cosa è cambiato per spingerci così verso, dal tuo punto di vista? Non lo so sinceramente, nel senso che penso sia una cosa un po' che per Osmosi si trasmette un po' da una parte l'altra.Non so individuare un punto di origine comune, ma penso che siano un po' i corsi e ricorsi storici della tecnologia, perché in realtà se andiamo indietro nel tempo ci sono linguaggi molto più tipizzati di quelli attuali, quindi penso che siano un po' i cicli, tipo delle mode.Però l'altro mio sospetto è che forse anche la potenza dei calcolatori, dei computer che abbiamo in nostra disposizione migliorando ha reso possibile cose che magari prima banalmente non erano possibili, nel senso che anche solo banalmente pensare di analizzare così in fretta talmente tanto codice lo puoi fare solo perché oggi abbiamo delle macchine che sono molto più potenti di quelle di tanto tempo fa, no? Cioè, JavaScript per esempio ha avuto l'esplosione con il V8 di Chrome, no? Quando è diventato davvero performante, non un carrozzone lento perché emulavi su 15 strati diversi dal browser in su e dal browser in giù e tutto il resto.Quindi magari il punto era proprio quello, cioè c'è stata l'esplosione del linguaggio non tipizzato, poi a un certo punto qualcuno si rompe le scatole e dice "cavolo mi sono rotto le scatole di avere tutta questa sfilza di errori, di avere questo codice che sta in su, in piedi" - opinione personale con gli stecchini perché poi secondo me scrivere codice in quella maniera è rapido e veloce, la butti giù con una rapidità pazzesca però poi quando ci ritorni su ti fa un po' piangere.Allora quindi qualcuno si lancia a scrivere un tool del genere e piano piano prende piede.Cioè per esempio da quel che so Salm è nato all'interno di Vimeo perché avevano bisogno di una roba che gli aiutasse a uscire dal malasma del legacy PHP che loro avevano, e avevano della roba veramente vecchia.Grazie a una roba del genere hanno fatto il saltino avanti.TypeScript è lo stesso, è nato perché in JavaScript puoi scrivere tutto il contrario di tutto e insomma troppa libertà a un certo punto ti si ritorce contro.Sì, credo di sì.In realtà se dovessi rappresentare questa cosa è un po' come il ritorno di moda dei pantaloni a zampa come lo stavi raccontando? L'immagine che mi si è proiettata in mente è quella credo però che un po' questo ritorno sia dato dal fatto che se noi pensiamo magari dico una cosa impropria però ci credo in questo se noi pensiamo al sistema di tipi di linguaggi come il C o il C++ adesso la sparo grossa ma anche il sistema di tipi di java erano sistemi di tipi pensati un po' per la macchina prevalentemente quelli del C, con il concetto di macchina in mente.Credo che i sistemi di tipi moderni siano più in un'ottica o comunque fittino più in un'ottica di esperienza utente e di qualità di codice.E questa conclusione magari, ripeto, è scorretta, ma mi viene perché in realtà si è arrivata a questa esigenza facendo tutto il percorso che parte dal TDD.Perché proprio adesso c'è questa massificazione dell'uso dei linguaggi tipizzati? Perché lo sviluppatore medio, il frontender, ha bisogno di usare dei tipi su React? Non c'entra più il principio macchina.Capisci? Il livello di astrazione è sicuramente aumentato.Il punto è proprio quello, nel senso che magari ha proprio linguaggi come il PHP che di fatto è scritto in C a sua volta, quindi è proprio l'esempio perfetto del ulteriore layer in testa ai linguaggi precedenti.Il primo step che ti viene probabilmente, cioè alla fine PHP è nato per non dover scrivere in Perl, per non dover scrivere roba di basso livello dovendo lavorare su pagine web e quindi ti permette di dire "Vabbè, chi se ne frega delle malloc, chi se ne frega delle robe di basso livello, dei go to eccetera, voglio scrivere quasi logica pura, no? E lo voglio fare con la massima libertà, scrivendo quello che mi pare.Poi a un certo punto, come dicevo prima, troppa libertà forse fa male, nel senso che appunto se per rimanere variabile non sai manco che caspetto c'è dentro, poi probabilmente il carico cognitivo dello sviluppatore diventa problematico, perché significa che devi risalire 4 o 5 funzioni prima per capire che caspito ti sta arrivando in quella variabile.Invece se aggiungi tipi, stringi un attimino le possibilità, riduci e sai che il tuo carico cognitivo non è più così grande perché se il tipo che vedi in ingresso è quello, sai che è quello.Cioè non devi riguardare da dove stai arrivando per capire che può essere una stringa o un numero o un oggetto o qualunque altra cosa.Sai che è quel tipo lì e sai che ci puoi ragionare con piccoli mattoncini.Non devi guardare e tenerti in testa l'intera applicazione nel suo complesso.Infatti, per quello ti dicevo, secondo me tanti di quelli che spingono tanto per fregarsene dei tipi, per fare dark typing, per non essere così stringenti, lo fanno perché magari, forse anche per il tipo di lavoro che viene fatto, il beneficio che ne ricevono è superiore a quei problemi.Secondo me i benefici di quell'approccio lì si perdono sul lungo andare, sul lungo raggio.Quando devi tornare e ritornare sul tuo codice e iterare tante volte diventa un problema perché appunto ogni volta devi metterti in testa tutto quello che hai scritto fino a quel momento, in modo che tutto il funzionamento applicativo sia nel tuo cervello e allora lì hai bisogno di dividere in compartimenti stagni e tipi secondo me aiutano in questo senso.Quando invece stai buttando giù un'applicazione rapida, un prototyping o comunque un progetto che non ha una vita lunga nel senso che magari è una roba, un progettino che ti è stato commissionato, lo tiri su, magari fa un po' di manutenzione ma rimane quello, allora sì, allora sì il trade off che hai quando quando impieghi i tipi, quando impieghi questi strumenti eccetera, non è sufficientemente rapido da pagare.Poi secondo me questa cosa a volte è un po' una foglia di fico, nel senso che magari il trade-off migliora anche nel momento in cui tu fai i tuoi questi strumenti.Come dicevo prima, no? Sono passato a fare anche le cose stupide tipo i giochini come advent of code con i test, perché ormai un test lo so scrivere senza problemi, lo so come gira PHP Unit, non devo ristudiarmi la documentazione da capo per capire come scrivere un test in un nuovo progetto e quindi ho ridotto magari quel trade-off, quel costo iniziale da pagare quando inizi a usare uno strumento più avanzato per una roba che magari ti sembra banale.Anche perché ti da out of the box già un modo per rannare il tuo scriptino PHP in un certo contesto, no? Sì, anche.Anche, assolutamente.Per carità, proprio sempre nell'esempio di Advent of Code, io comunque mi sono scritto uno script PHP di tre righe che lo chiamo e invoca la soluzione, ok? Per darmi il risultato senza passare dai test.E quindi, cioè, è proprio quell'esempio lì, no? Se devi fare una roba one shot stupida, non me ne frega niente di scrivere tutto il "Fizzbuzz Enterprise Edition" che tanto viene preso in giro, no? Da chi critica questo approccio, da chi critica Java, che è tanto spinto in quel senso.Per carità, se devi scrivere "Hello World" va benissimo.Però, diciamo che io Io penso che l'asticella per cui conviene usare questi strumenti è sufficientemente bassa, insomma.Però capisco che sia una scelta di vita la mia, nel senso che ho sempre detto di preferire spudoratamente questo tipo di lavoro, quindi tutto quello che è più lontano possibile dalla web agency, dai progetti a breve termine.Ho sempre preferito invece i progetti di grande respiro il lavoro che faccio mi spinge a far questo, fondamentalmente, a scrivere progetti che hanno tre anni come minimo di vita, di sviluppo, fondamentalmente, spesso e volentieri, e quindi mi spingono a usare tool come questi, a preferire framework come Symfony, che hanno una forte policy LPS, a scrivere codice con tantissimi tipi, a scrivere codice che deve passare una marea di test, che deve passare l'analisi statica di PHPSTAM, Epsam contemporaneamente e tante altre cose che sono costose, è vero, cioè è uno sbattimento manutenere tutte queste robe.Però mi rendo anche conto che poi pagano tantissimo.Cioè io ci sono stati dei frangenti in cui ho fatto...cioè una che mi viene in mente era questa.Avevo un piccolo problema in produzione, non mio, ma di chi utilizzava l'API del mio progetto, perché non aveva sufficienti informazioni per operare.Il progetto di cui sto parlando gestisce i maledetti consensi della privacy e quindi praticamente il cliente di questo mio progetto doveva interrogarmi per dire "Ma quest'utente ce li ha, non ce li ha i magari ha chiesto la cancellazione GDPR, questo brutto insieme di cose.La soluzione per tirarlo fuori dal buco senza costringerlo a costruire un castello era esporgli l'elenco, cioè dirgli se il cliente in questione aveva subito una cancellazione GDPR.Se dovessi farlo da zero, insomma è un un lavoretto che richiede un po' di lavoro, devi studiare, buttare giù un API, cominciare a testarla, scrivere, insomma, metto giornate di lavoro, magari.Non lo so, lo sto stimando, buttando giù.Col fatto che avevo un progetto con tutte queste robe, con tutti questi fiocchettini, con la continuous integration, con tutti i test, da quando ho iniziato, quando ero in produzione, ci ho messo 30 minuti.Cioè, ho scritto per intero un endpoint in Get, testato e tutto il giro e l'ho mandato in produzione in 30 minuti.Cioè il tizio che me l'ha chiesto non ha fatto neanche in tempo a scrivere l'integrazione per chiamarmi la mia GATT per fare i suoi check, io l'ho già in produzione.Perché? Perché avevo tutto questo già pronto, no? Il mio progetto era già pesantemente testato, pesantemente verificato, con tutti i tool pronti.Cioè, come ho detto all'inizio, no? Entro nella cartella del progetto, make setup, bram, tutto su, contener aperti, shell dentro il container, apro l'IDE, scrivo il test, scrivo il container, faccio girare i test di analisi statica per essere sicuro di non aver scritto fregnace, push, gira la pipeline, perfetto, merge, deploy.Questo è il bello secondo me, il momento in cui mi godo veramente tutto il sudore.Perché l'effort l'hai fatto prima, ti sei creato un contesto nel quale poter lavorare modo agile.Rimaniamo sempre nel test.C'è un tool di cui immagino tu vada super fiero che è Para Unit.Che se non sbaglio siamo alla versione 2 giusto? 1.2 in realtà l'ho un po' frascurato ultimamente ma è ancora lì e funziona.Cosa fa e com'è nata l'esigenza di Para Unit.Allora è una delle prime cose che ho fatto quando sono arrivato in Facile al di fuori del semplice lavoro sul progetto fondamentalmente su cui ero assegnato ed è un wrapper di PHP Unit che permette di eseguire i test in parallelo.Era una cosa un po' figlia del fatto che io venendo dal C ero abituato a una roba, sai, rapida, vai! E il di HP in confronto.Era lentissimo e soprattutto al periodo che ancora giravamo su Vagrant, non avevamo Docker, era ancora più lento.Ti giuro era una roba mostruosa perché lavoravo su un progetto che si aggirava intorno al milione di righe di codice.Credo che adesso abbia raggiunto il milione quattro e due milioni.È un mostro.Sì, sì, sì.È il progetto più grosso che abbiamo in azienda.E tra l'altro a questi due milioni di righe di si è aggiunto credo una mezza milionata di typescript quindi stanno continuando a macinare e eravamo arrivati al punto che un f5 in locale su una pagina symphony banale ci metteva dieci secondi era proprio la morte sicuramente quello che è arrivato dopo poco dopo che docker ci ha dato una grossa mano ma il problema erano i test cioè far girare dei test e ne avevamo tanti, era una roba mortale.Cioè, è una roba che avevo proprio letto poco prima di cominciare a lavorare per facile, è proprio quello.Cioè, se tu hai una test suite che dura più di dieci minuti, non vale niente.Sì, perché non la anni.Non la fai girare, perché ogni volta, se no, devi andare a farti la passeggiata.Noi non eravamo nei dieci io ho fatto una stima e ho visto che far girare solo i test funzionali di Symphony, ne parlo in un talk che ho fatto da poco e che devo riproporre tra poco al Pug, mi sa avevo stimato che se non fosse crashato dopo 5 minuti, perché era quello che succedeva, ci avrebbe messo 45-46 minuti a far girare tutto.Era una roba improponibile, quindi ci riducevamo ogni volta a far girare solamente i test del pezzo che stavamo sviluppando e basta.Però così ti perdi il bello dei test, cioè ti perdi il fatto che se una roba ne rompi un'altra, te ne dovresti accorgere.Paraunit fa una roba molto banale, cioè usa il process di Symfony, il componente process, per lanciare PHP unit n volte, dove n sono i file di test che tu hai in parallelo.Punto.Quindi ti dà un boost pazzesco, perché quei 45 minuti sono diventati 6, 5 più o meno.Sì, sì, sì, il guadagno è mostruoso, perché in realtà in quel fragente lì ci sono tanti tempi morti di input-output e cose simili, e quindi parallelizzando normalmente si riescono a eseguire 5-10 test in contemporanea e vai che nascheggia.È un tool che ho portato tantissimo avanti da allora, è nato come un bundle Symfony, che poi in bundle non era dentro la nostra applicazione, poi l'abbiamo tirato fuori con un progetto open source, e ci ho fatto sopra il mio primo talk in assoluta a una conferenza nel 2015.E io c'ero.Al Symfony Day.Eh sì, appunto, mi dicevi prima appunto che hai assistito a questo mio esordio.E tuttora lo uso, diversi progetti in azienda lo usano, so che qualcuno qua e là lo usa anche fuori dalla mia azienda, e l'ho scritto perché al tempo non esisteva un'alternativa.O meglio, esisteva Paratest, che però al periodo era mezzo abbandonato.So che nel frattempo è tornato in auge, addirittura è molto più usato del mio tool, a dire la verità.Però so anche che è un po' più complesso, perché fa una paralizzazione meno banale, entra negli interni al CDPHP unit per paralizzare il singolo test, tante altre cose divertenti, insomma.No, al di là di questo è complicato, però, perché come molti che lavorano fuori dal PHP ben sanno, paralizzare i processi è tutt'altro che banale.La concorrenza è una brutta bestia e quindi devi correre ripari per tanti motivi, nel senso che i tuoi test non si aspettano di lavorare in contemporanea a qualcun altro, tanto per dirne una.E quindi poi questo mi ha spinto a spulciarmi tanto di come funzionano i test, a spulciare tanto di come funziona un'applicazione Symfony, di come isolarla, perché poi a quel punto il più banale dei problemi è il fatto che hai n test che accedono in parallelo al db quando hai test funzionali integrazione e devi isolarlo in quel caso e insomma mi ha spinto lungo una strada questa cosa, da una parte con il talk e quindi con il fatto di diventare uno speaker alle conferenze, dall'altra nel mondo dell'open source e nello spulciarmi così tanto gli internals di testing e di framework che mi hanno dato davvero tanto, cioè mi hanno fatto fare davvero tanta strada.è arrivato la rovina bello e immagino ti abbia dato anche tanto dal lato professionale proprio per questo tipo di percorso di studio e di approfondimento hai citato più di una volta symphony symphony insieme a php è stato il mio grande amore nel senso che avere un framework con con quelle fattezze che si presta anche in ambiti enterprise su PHP è stata una scoperta.Fabien e tutti gli altri hanno fatto un lavoro assurdo.Per te cos'è Symfony e perché scegliere Symfony in un ecosistema dove c'è per esempio un outsider come Laravel e vedo un tuo mezzo sorrisetto sulla faccia.No, non era un mezzo.Sono abbastanza di parte in questo senso.Come ho già raccontato, alla fine io proprio ho fatto una scelta del voler lavorare in questo modo.Non dico enterprise, ma quasi.Diciamo lontano dallo sviluppo web più spicciolo, più semplice, se così possiamo chiamarlo, magari semplice non è, semplicemente come dicevo prima, mi piacciono i progetti a lunga durata.E questo si sposa bene con la mentalità di Symfony, in primis con la loro promessa di retrocompatibilità.Cioè loro ti dicono che all'interno della stessa measure, se si spacca qualcosa, se cambia qualche comportamento, per loro è un bug, non esiste, deve essere tutto perfettamente funzionante.E questa cosa si sposa molto con questo approccio, perché significa che che tu da sviluppatore puoi contare su queste tempistiche, puoi essere sicuro che la tua measure sarà supportata per n anni e che se stai al passo sarà abbastanza semplice aggiornare.Cioè adesso la release di Symphony funziona così.Tu hai una measure e poi fanno 5 minor.Punto 0, punto 1, punto 2, punto 3, punto 4.La punto 4 adesso normalmente è la LTS e tu puoi sempre partire dalla punto 0 scalare se non la punto quattro senza toccare nulla normalmente al netto di bug perché allora hanno appunto questa garanzia di retrocompatibilità cioè quindi tutto quello che ha funzionato sulla 5 0 teoricamente deve funzionare senza problemi sino alla 5 4 senza battere il ciglio poi la 6 0 che sarà in futuro se non mi ricordo neanche quando è prevista però manca ancora un po' praticamente dovrebbe essere uguale alla 5 4 meno le deprecazioni e questo è secondo me il meccanismo perfetto perché significa che tu puoi il tempo di starci dietro nel senso che quello che io faccio normalmente è cercare di tenere a zero le deprecazioni però se non hai tempo puoi anche dire ci penso dopo e e anche lì fare tra virgolette il boy scout no? Cioè quando hai tempo ne fai sparire un paio poi se tu arrivi alla 5 e 4 e non hai deprecazioni passare alla 6 è gratis fondamentalmente.Questo è fantastico perché tutti quegli vari incubi di "oh miseria hanno aggiornato e devo cambiare tutto", quei grandi salti costretti a fare ogni tanto perché magari vuoi aggiornare perché ti serve un tool nuovo, ti serve una roba nuova, con Siphony in realtà se sei dirigente non esistono, non ci sono più questi problemi.Riesci davvero a spalmarti questo lavoro negli anni e a non trovarti mai in quella situazione orrenda in cui dici "cavolo, mi costa talmente tanto che forse ci devo rinunciare a fare quell'aggiornamento".Io ho fatto questo brutto salto quando all'inizio l'elbow di symphony ancora mancava tutta questa cosa, il mitico salto dalla 1 alla 2.Sto ancora piangendo, sappilo.Guarda, l'applicazione mostro di cui parlavo prima, quella da un milione e mezzo di codici, era proprio in quella situazione lì.Era nata su Symfony 1, senza test, e andava migrata perché stava...cioè era un problema, fondamentalmente.L'unico modo che abbiamo trovato per farlo è stato questo.Abbiamo creato una seconda applicazione in Symfony 2 e l'abbiamo fatta coesistere.Conosco il problema.Questa roba è stata iniziata da colleghi prima che arrivassi io.Io sono arrivato che praticamente sta roba era già in piedi da un anno e mezzo.Non incubo? No, no, no, per niente, perché la cosa è stata molto furba, nel senso che quello che veniva fatto era, ogni qualvolta c'era da fare una smartellata veloce, un piccolo commit veniva fatto sulla vecchia applicazione.Quando c'era qualcosa di grosso, si riscriveva l'intero pezzo sulla nuova e l'unica cosa che faceva interagire le due applicazioni erano da una parte la sessione che era in comune e il routing, cioè il routing sapeva se una certa rota apparteneva all'uno o al due e quindi c'era questo routing incrociato.Ogni volta che il business ci chiedeva uno sviluppo sostanziale piuttosto che incastrarlo a martellata nel vecchio, lo rifacevamo nel nuovo e ne approfittavamo per riscriverlo meglio e questo secondo me è l'unico modo che hai per vendere al business una roba che che normalmente per loro avrebbe valore zero.Cioè riscrivere una roba in un nuovo framework a loro non gliene frega niente.Porta a zero valore di business.In questo caso invece, visto che tanto c'è da lavorare un bel po', dicevamo, perfetto, guarda, questo è il contesto, il recinto dentro cui vogliamo lavorare, questo pezzettino di funzionalità.Lo vogliamo rifare di là.Quindi oltre alla feature che ci chiedi tu, ma la ripensiamo poco poco meglio, la rifacciamo poco poco meglio dall'altra parte e pezzo pezzo questa cosa veniva fatta.È durato una vita.Mi sa che in totale il processo è durato tre o quattro anni.Ma ne è valsa la pena perché abbiamo ottenuto come risultato finale un'applicazione migliore, ben testata e finalmente a bordo di un framework con tutti i vantaggi di cui dicevamo prima, con tutta la promessa di retrocompatibilità, l'LTS e tutto quello che ne conseguiva.Ha funzionato talmente bene che nell'ultimo anno quasi non toccavamo l'uno e non rimaste l'ultima due o tre cose tra cui c'era l'autenticazione e una funzionalità che non è mai stata toccata perché continuava ad andare, no? Classico pezzo di Legacy che non tocchi mai e quindi chi se ne frega se è Legacy.E un'estate ci siamo svegliati e abbiamo detto "Vabbè, tiriamo la mannaia e uccidiamolo definitivamente, se no...".Cioè, è stato l'unico modo, l'unico modo, perché secondo me è l'unica strategia Io ho roba con un Simfony 1.4 che gira ancora, quindi devo dire...Chiaro, però non è più aggiornata, non puoi aggiornare...Ma scherzi! Dovresti riscriverla.Gira dietro VPN per quello.Meno male, meno quello.No, però io ricordo, per me è stato straziante veramente quel passaggio, perché tanto effort ti ritrovi davvero di...dopo un po' a non...tanto che sono stato talmente scioccato in in quel passaggio che per un attimo mi sono fatto affascinare da The Zend Framework.Che però, nello stesso periodo, stava facendo lo switching anche lui.Io lo ricordo che passava dalla 10 alla qualcos'altro.Quindi alla fine ti trovi orfano in un contesto che dici "e mo' che faccio?".Anche perché col passaggio dalla 1.4 alla 2 ho visto che Symfony ha cambiato completamente mentalità.Se prima avevo un approccio RAD, io lo ricordo, con la Sinfony 1.4 io lanciavo dei comandi e avevo uno scaffolding super super easy, una roba che poi potevi fare i tuoi controller sovrappeso in modo super facile.Poi ti ritrovi in un contesto che a me ha ricordato da subito Java, super strutturato, tanta tanta configurazione che era la cosa che più disorienta di Symfony, tonnellate di YAML o XML, perché comunque io raramente ho visto delle configurazioni su Symfony anche se si possono fare in PHP.Quindi buona parte del glue, della colla che tiene in piedi la tua applicazione sono file di conf.Quello è vero però da quel punto di vista con l'introduzione di Symphony Flex negli anni scorsi hanno secondo me sorpasso perché quello scoglio.Flex fondamentalmente cosa fa? Hanno spinto ancora ulteriormente il concetto dei componenti, quindi non esiste più il framework monolitico e ci hanno aggiunto il fatto che quando tu installi un pacchetto che sia un componente loro o qualcosa che comunque magari è stato consigliato dalla community si porta dietro la posizione recipe, la ricetta, che ti installa una configurazione di default, una configurazione suggerita.Con questo secondo me hanno chiuso il cerchio, perché fondamentalmente hanno spinto al massimo il concetto dei componenti e quindi ti permette di dire non c'è più symphony, bam, blocco unico, framework, web application edition, ti installi tutto.E poi vai a togliere piano piano.No, esatto, al contrario, vai ad aggiungere.Adesso vai ad aggiungere.E poi soprattutto hai questa cosa che avendo le recipi fondamentalmente senza manco guardare il readme ti spara dentro, lo diamo il necessario, ben spacchettato a questo punto, quindi hai quello corrispondente di quel componente, quello di quel bundle, quello di di quel pacchetto vendor che hai installato, eccetera, e costruisci pezzo a pezzo.Quindi hanno proprio eliminato, secondo me, le ultime critiche che gli si poteva fare.Quindi, da una parte, il fatto che fosse un framework troppo monolitico, dall'altra, come dici tu, che magari questa configurazione iniziale potesse un po' spaventare.Adesso, col fatto che viene costruito pezzo a pezzo, aggiungi on demand, di fatto, alla tua applicazione e riesci tranquillamente.sicuramente era un po' costosa la migrazione dell'adozione a Flex inizialmente, l'ho dovuta fare su un paio di applicazioni e non era non era proprio banale, però una volta che sei a bordo ti rendi conto di quanto è più snello.Io ho avuto un paio di applicazioni su cui ho fatto questa migrazione in cui ho letteralmente guadagnato megabyte dalla vendor rimuovendo roba perché toglievi fuori un sacco di roba che non ti serviva.Io ho un applicativo che non usa Doctrine, usa MongoDB e ho levato ma tanta di quella roba che non l'ho usato, era installata ma non la usava l'applicazione.E tra l'altro liberare la vendor in fase di dev in un contesto docker con macchina apple era sempre una delle ambizioni.Io l'ho sempre detto ai miei colleghi ragazzi docker e e Mac non vanno d'accordo.Io uso Linux ormai da una vita e Docker ci va ovviamente a braccetto perché è nativo, non c'è verso.Mac arranca sempre in quel frangente lì.Io mi ricordo 25 secondi per mostrare una pagina perché non era configurato bene, andavi a fare fine tuning a fare archi magie per mettere in cash i vendor.Si ma sono trucchetti in realtà il punto è sempre quello cioè su linux girano attivamente su mac hai per quanto piccola possa essere una vm in mezzo e quindi ritorni al problema di vagrant e quindi a quello che vivevo io sei anni fa del fatto che devi condividere un file system con una virtual machine ed è quello è lento non c'è verso.Assolutamente sì.Stiamo andando tantissimo lunghissimi però io una domanda te la voglio fare voglio chiederti del PHP FIG quindi voglio chiederti che cos'è il PHP FIG e siccome so che tu sei segretario del PHP FIG come abbiamo detto nell'introduzione, qual è il ruolo del segretario in questo contesto? Ok, allora il PHP FIG è fondamentalmente un gruppo di persone che si è formato spontaneamente tanto tanto tempo fa e che prova a scrivere le cosiddette PSR, le PHP Standard Recommendations.Molti ormai che lavorano in PHP le conoscono per forza, ma sono fondamentalmente un tentativo di standardizzare alcune cose all'interno dell'ecosistema PHP.Le prime cose che sono state standardizzate sono l'autoloader, per esempio, che di fatto sono stati il perno di Composer, quindi sono così importante per quello.Poi c'è stato qualche tentativo di standardizzazione del code style, del logger, quindi di fatto...Lo standard de facto era monologue ed è stato di fatto standardizzato con un'interfaccia e poi mano a mano si sono aggiunte varie cose, poi è arrivata la TSR 7 che è quella sui messaggi HTTP e tanto altro.Io come segretario di fatto è come se fossi un "impiegato", sono solo un amministratore in senso stretto del termine, nel senso che aiuto a far girare gli ingranaggi, anche se devo ammettere che negli ultimi mesi ho un po' un po' faticato tra lavoro e pandemia a stare dietro a questo genere di cose ma penso che quello che il PHP Fig ha fatto in passato è stato proprio quello di cercare di cristallizzare in maniera formale quello che di volta in volta diventava diventava uno standard de facto.L'unica cosa che poi c'è quello che poi è cambiato nel tempo, è stata per esempio l'aggiunta di PSR come la PSR 7 e le successive sull'HTTP che invece, al contrario delle precedenti, non hanno cristallizzato uno standard de facto ma ne hanno introdotto uno nuovo, diciamo.E questo è successo perché si sono trovati di fronte al fatto che non esisteva uno standard de facto, cioè c'erano un paio di approcci preesistenti nei framework che esistevano al periodo, ma non ce n'era uno prevalente, come è successo per esempio per monologo, in cui fondamentalmente esisteva solo quello ed era usato dal 99% degli applicativi, altrimenti la gente se lo faceva in casa, il logger, non esisteva un concorrente diciamo sul mercato e quindi non è che si poteva dire "vabbè c'è ragione Symfony", no c'è ragione Zend e tutti tutti gli altri si devono adeguare.Si sono messi davanti a questo problema e hanno detto, vabbè, piuttosto ci inventiamo qualcosa di un po' minimale che rappresenta dei buoni principi di design, per quanto possibile, e proviamo a vedere se questa cosa funziona.Dopo la standardizzazione del messaggio, poi sono arrivate delle PSR successive che hanno definito l'interfaccia per i middleware e tante altre cose che poi hanno guidato tanti sviluppi successivi che hanno fatto nascere o perlomeno crescere anche dei framework preesistenti che hanno preso questo approccio.Però secondo me piano piano siamo arrivati ad avere un po' di cose abbastanza interessanti.L'ultima è la PSR18 che standardizza invece il client HTTP che quindi permette di scrivere del codice senza sapere qual è il client HTTP sottostante.Io, per esempio, ho collaborato, e ancora collaboro, con il mantenimento della libreria open source di Sentry in PHP e abbiamo fatto questo sforzo.Abbiamo cercato di evitare di legarci a un client HTTP specifico.Addirittura nelle vecchie versioni usavamo direttamente siurl con le funzioni di basso livello ed era un pianto da manutenere.E in questa maniera un utilizzatore della libreria può iniettare il suo client preferito.grazie proprio a questo sforzo di standardizzazione.Perché c'è un'interfaccia comune, no? Esatto, esatto.Un po' come prima è stato fatto per Monologue e tutto il resto.Sicuramente non è stato semplice e ha un po' smosso gli animi, nel senso che forse è un argomento un po' delicato da trattare, in cui è difficile mettere d'accordo tutti.In primis Symphony sarei un po', tra virgolette, risentita, nel senso che...Per l'HTTP, no? Sì, ma più che altro perché l'approccio che loro hanno nel loro HTTP Foundation è molto distante e la principale differenza sta nel fatto che la PSR 7 prevede un messaggio HTTP con un oggetto immutabile mentre la loro response è tutt'altro che immutabile e quindi pensare di adottare la PSR 7 per loro era impossibile.Ma nessuno secondo me l'ha preteso, nessuno ha preteso atteso che riscrivessero da zero il loro applicativo.Perché il punto, secondo me, di queste PSR non è uniformare, non è far sì che tutti scrivano codici in quella maniera, ma è appunto vedere nel nome l'interoperabilità, cioè la possibilità di utilizzare in maniera interscambiabile i componenti.Secondo me è una delle grandissime forze del PHP.C'è un ecosistema, una community fortissima ed enorme.Per esempio in ambiente Symfony questa cosa l'hanno un po' risolta scrivendo un bridge, c'è un piccolo componente che traduce in avanti e indietro da PSR 7 a HTTP foundation e viceversa.Secondo me è sufficiente, nessuno pretende che Symfony ripensi da zero la propria architettura interna, però per esempio a me è capitato recentemente di di sfruttare questo bridge per usare una libreria esterna della...Dunque, della PHP League, che è un gruppo di persone che fa dei bei pacchetti open source.Mi serviva in particolare un pacchetto che loro hanno scritto che permette di validare richieste e risposta in relazione con una documentazione OpenAPI.E questa cosa l'ho potuta tranquillamente fare, cioè intercettavo richieste e risposta dei Symfony, le passavo dal bridge e poi le davo in pasto a questa libreria e ho ottenuto il mio scopo grazie a questo discorso di interoperabilità.È stato comodissimo.Sì, quindi...beh, perché in realtà per chi conosce l'argomento e chi ha seguito, insomma, proprio per capire questa dinamica del fig, sono scoppiate le bombette...Sì, in passato ci sono stati dei veri e propri drammi internettiani di epiche dimensioni.Sì, che ricordano un po' le chat di 4chan o cose di questo tipo.Un po' più educate sì però sì, sicuramente gli animi si scaldavano parecchio.Devo dire che da quel punto di vista un po' mi è dispiaciuto ma spero e penso di aver un po' aiutato in quel senso, cioè di aver aiutato a mantenere un po' la discussione civile e a portare a qualcosa di produttivo.Sicuramente ultimamente c'è un po' di calo nelle attività del PHPfig.Recentemente quello che abbiamo fatto per cercare un po' di ravvivare la situazione è stato aprire un server Discord, perché da tempo ci si lamentavano del fatto che "ah, ma sta mailing list, è inutilizzabile".No, la mailing list continueremo a utilizzarla perché è l'unico mezzo duraturo e non legato a una qualche società, qualche piattaforma online che ci permetta di comunicare in maniera stabile.Però sì, è vero, serviva a un qualche tipo di strumento di interazione un po' più informale.Avevamo uno Slack interno che era poco utilizzato, che poco male si sposa con l'apertura alla community, allora abbiamo deciso di aprire questo server Discord per questo motivo.Insomma, per avere un posto in cui si possa chattare informalmente e che chiunque abbia voglia di chiacchierare possa buttarsi là e scambiare due parole con chi è interessato agli stessi argomenti fondamentalmente.Comunque devo dire che da ex utilizzatore seriale di PHP il lavoro fatto dal PHP Fig è stato grandioso anche perché ha tracciato un po' la pista per i framework moderni e la scrittura di codice moderno con quel linguaggio e secondo me molto molto adatto proprio a questo tipo di organismo.Quindi io tra le cose che ho detto all'inizio, tra il composer della situazione e i tipi, ci metterei anche come ruolo il ruolo del PHP FIG come acceleratore dell'evoluzione del PHP.Devo dire che sono passati 25 anni da quando Rasmus Lerdorf ha lanciato il PHP.Secondo te, cosa ha reso il PHP così longevo e cosa lo rende ancora una buona scelta in ambito aziendale? Sicuramente la longevità secondo me dipende da quella che è la croce o la delizia del PHP, cioè la bassa barrera d'ingresso.Nel senso che è veramente semplice iniziare a usare il PHP, perché è gratis, perché ci sono tantissime risorse, perché è talmente banale che basta aprire Notepad e fare F5 dopo che hai un minimo di browser web a disposizione.cioè scusatemi di di server HTTP configurato insomma stavo stavo confondendo lato.Però penso che sia anche stata la maledizione del PHP perché questo ha significato che essendo la barriera d'ingresso così bassa il fatto che può entrare chiunque significa che può entrare chiunque.Quindi nessuno viene fermato all'ingresso ma c'è tanta purtroppo spazzatura in giro se così possiamo chiamarla, soprattutto su internet, di vecchie documentazioni, di codici scritti male, di tutorial scritti ancora peggio o magari talmente datati da usare roba che è più che sconsigliata al giorno d'oggi.Questo, unito probabilmente a WordPress, perché è utile negarlo, è ciò che ha spinto tantissimo i vari hosting condivisi e l'utilizzo di PHP così tanto, oltre appunto al fatto che fosse gratis, l'ha reso una roba che tanti continuano a chiamare morta ma che continua a vivere e a portare avanti tantissime tantissime realtà, compresa quella dove lavoro.Sicuramente sceglierlo adesso non è più così diciamo problematico come un tempo, nel senso che grazie a tante cose che sono migliorate negli ultimi anni ormai comunque sta sempre più diventando un linguaggio maturo, perché sta puntando ad avere tutte quelle feature e tutte quelle cose che servono a un vero professionista, fondamentalmente, piano piano.Non c'è ancora tutto, secondo me.Mancano ancora delle cose da cui i famosissimi generics, però già vederne degli abbozzi in termini di annotation e analisi statica, come dicevamo prima, ti fanno capire che il linguaggio è tutt'altro che morto.Anzi, sta continuando a crescere tantissimo.E il fatto che sia gratuito, il fatto che avviare una community e un ecosistema così ampi, sicuramente ti ci fanno scommettere sopra.Ci sono tanti linguaggi molto più belli, ma che sono quasi d'élite.Uno Scala o linguaggi simili sono fantastici, ok? Io non ci ho mai messo le mani, ma so che hanno delle potenzialità pazzesche.Però viene usato da talmente tanta poca gente che ti puoi confrontare come una persona nel momento in cui hai difficoltà.trovi molta meno materiale, molti meno pacchetti open source, molte meno cose per cui non devi reinventare la ruota.E quindi sicuramente fare una roba in PHP è un grosso accelerante.L'ultima cosa che secondo me è ottima del PHP, e l'ho rivalutata tantissimo negli ultimi anni, è l'architettura share nothing, il fatto che il PHP ti permette di strafregartene di memoria, di condivisione di risorse, di parallelismo.Tu ti scrivi il tuo controller, quello si esegue, nasce e muore, e finisce lì.È uno dei motivi per cui l'ho apprezzato tantissimo, al di là del fatto che mi sono potuto lasciare alle spalle le varie malloc del C++ e tutti quei vari deliri, e anche il fatto che si è sposato straordinariamente bene con una tecnologia che adesso ha preso tantissimo piede che è Kubernetes, perché per il tipo di applicazioni su cui lavoro io ci va una favola.Mi spiego meglio, perché altrimenti sembra il contrario di quello che avevo detto, che non sono uno che segue le mode, sembra invece uno di quelli che parlano di Kubernetes e blockchain ogni tre per due.Abbiamo cominciato ad adottare Kubernetes da un bel po' in azienda e questo è perché abbiamo un grosso reparto IT che sviluppa tanti progetti separati e quindi avere uno strumento che ti permette di dire "sai che c'è? C'ho un unico blocchettone di server su cui posso buttare sulla roba e deployare e chi se ne frega di WMA 1, 2, 3, 10, 15" è stato molto d'aiuto.Fondamentalmente abbiamo diversi cluster, ce n'è uno in particolare che si chiama stranamente Shared perché ci finisce sopra la qualunque, ci girano sopra una quindicina di applicativi completamente separati tra loro, Ma i nostri sistemisti, i nostri DevOps lo manutengono in maniera uniforme, buttano, tolgono dentro nodi, autoscaling, quello che vuoi, e io, sviluppatore, me ne frego.Perché il PHP funziona bene lì? Perché è leggero.A me è capitato di fare un workshop su Kubernetes quando già ci lavoravo già da un annetto, avevo come vicino di banco, e poi anche a pranzo ci siamo fermati a chiacchierare, questo sviluppatore Java.E ha cominciato a chiedermi "Ma perché? Ma quindi tu già ce la vuoi? Come va? Come non va? Ci sto pensando".E come ne parlavamo? Mi ricordava il fatto che per avviare Java, allora lui ha detto "Ah, ho un applicativo, ho tre server, richiede ognuno 8-16 giga di RAM e ci mettono, non mi ricordo quanto tempo, ad avviarsi, eccetera".E ho provato a immaginarmi di inscatolare questa roba in un container dentro un cluster Kubernetes.È un suicidio.È veramente un suicidio, perché Kubernetes fondamentalmente, secondo me, fa la stessa cosa che fai con l'inversion of control e con l'injection del codice, no? Invece di essere tu a pilotare l'infrastruttura e a decidere come funziona, tu inietti il tuo container col tuo codice e poi è il cluster che decide cosa farci.Quindi da questo punto di vista, visto che l'unità di misura dentro un cluster sono le risorse, quindi CPU e memoria fondamentalmente, non è che ti serve molto altro, perché poi il resto è la rete, ma lì difficilmente hai un collo di bottiglia.Poter dire che tu hai un container che ha bisogno di una CPU e se va male di 256 MB di RAM, significa che praticamente Kubernetes è quasi un giocoliere con i tuoi container.a papà.Esatto e non hai tempo di spin up cioè tu lo tiri su e quello appena aperto il socket è pronto.Cioè php fpm e nginx che ricevono traffico e lavorano subito istantaneamente invece che avere un applicativo con la jvm che si ciuccia 4 gb di ram minimo e poi deve fare tutto lo startup eccetera.Da questo punto di vista io l'ho trovato fantastico perché significa che tu hai un piccolo contenitore che di fatto è immutabile nel senso che non non ha stato interno, deve solo macinare le chieste php e basta.Tu lo tiri su, cioè non basta, scali, aumenti il numero dei container, tanto consuma talmente tanto poco che alla fine due, tre container in più, cosa vuoi che sia? Un giga di ram invece che 256? Cavoli, accidenti e via.E questo secondo me è il bello, cioè una tecnologia che come dicevi tu è nata 25 anni fa, ma che si sposa così bene con una roba così recente e così alla moda e che ti permette di deployare con una facilità pazzesca.Certo è che da sviluppatori questa facilità spesso quando è troppa tendiamo a complicare le cose semplici e questa è una provocazione che faccio ma giusto per vedere se riesco a triggerarti e quindi è quasi un gioco no? Però sai questo concetto di richiesta e risposta che da una parte viene snobbato da AWS che non mette l'engine PHP sulle sulle lambda.Dall'altra gli sviluppatori PHP che provano a realizzare e pensano di realizzare già realizzano sistemi di PHP async introducendo problemi di shared memories e problematiche di questo tipo.Quindi mi chiedo, alle volte, specie in linguaggi come PHP non siamo tentati di provare a martellare i chiodi con la chiave inglese? Sì, no no no, assolutamente, assolutamente, ma infatti una delle cose che per esempio stiamo facendo in azienda adesso è diversificare il nostro stack tecnologico, non troppo, cioè non stiamo cominciando a fare 45 linguaggi diversi perché quello è l'estrema opposto sicuramente, però per esempio stiamo aggiungendo pesantemente l'uso di TypeScript e di Frontend, c'è qualche puzza qua e là di roba scritta, un rusting o cose del genere, non ci siamo crespiti tantissimo, però stiamo pensando per affinità di spostare TypeScript anche sul back-end, quindi scrivere qualche servizio in Node, magari in TypeScript, in modo da non avere uno stack troppo differenziato, quindi sempre TypeScript E, anche se sono due mondi un po' diversi, e quindi non usare, come dici tu, la chiave inglese per i chiodi.E questo secondo me ha senso, cioè nel senso che fondamentalmente è vero, PHP non è per tutto, ma nessuno strumento va bene per tutto.Sicuramente quello che posso dire è che PHP va molto bene per tante cose che non ti immagineresti.Poi sì, sicuramente è interessante aver la possibilità di parlare di async o cose simili anche in PHP.Sicuramente però sono strumenti che al momento non sono, diciamo, maturi.E quindi sono un pochino...A un certo punto c'è un punto in cui devi dire "No, sto stiracchiando troppo lo strumento, non c'è verso, è meglio se uso qualcos'altro".Però sicuramente non bisogna sottovalutare il PHP, cioè è sufficientemente potente nello sviluppo web da fare veramente tanto con veramente poco.E questo serve davvero tanto.Alla fine noi abbiamo sviluppato tantissimo in PHP e tuttora abbiamo grandissimi parti del nostro core fatti in PHP e non ci vedo un problema.Il nostro più grande problema non è il PHP in sé, ma magari è un po' il legacy, ma che è il problema di tutti, fondamentalmente.Quindi il fatto di manutenere il codice.Da quel punto di vista, col fatto che il PHP sta facendo grandi balzi avanti, si tratta solo di aggiornare il proprio codice, di rinfrescare, fare manutenzione, insomma rifattorizzare.Ma ripeto, questo è un problema di tutti.È il nostro pane quotidiano.È il nostro lavoro.Esatto.Siamo pagati per quello.Esatto.L'unica cosa che apprezzo del PHP, nell'altro senso, è il fatto che per come è fatto, per come è cresciuto, non è caduto in quello che ritengo invece essere la trappola di ecosistemi come quelli del JavaScript.Che sì, hanno dimostrato di avere tantissima potenzialità, di aver fatto davvero tanto di questi anni, ma hanno esagerato tanto dal punto di vista dell'ecosistema.Il classico discorso del dependency health, del NPM, del fatto che hanno una dipendenza per ogni microscopica cosa, l'heftpad e tutto il resto.Secondo me, PHP ha azzeccato il giusto equilibrio tra scriverti le cose tu e usare dei pacchetti invece open source.Perché se tu apri un progetto qualunque scritto in PHP non ha una vendor mostruosa come la NodeModels.Il buco nero della NodeModels.Esatto, esatto.Vuoi perché la standard library di PHP non è ristretta come quella di JavaScript, vuoi perché il fatto che in Composer tu non possa installare due versioni della stessa libreria a un certo punto ti incastra un pochino.L'unico svantaggio che ha questa cosa è il discorso di aggiornamenti che facevamo prima quando parlavamo di LTS, che però secondo me può essere girata in positivo.Sì, ti costringe a prenderti cura delle tue dipendenze, che è una cosa importante.Esatto, e della tua applicazione, cioè di mantenere l'aggiornata.È proprio quello.Invece con Node cosa succede? Tu hai una sottodipendenza che reinstalla a quattro volte la stessa sottodipendenza, perché tanto la puoi installare con quattro major differenti.E c'è un modus da 4 giga.Quello, secondo me, è l'opposto della situazione...Cioè, gli estremi sono, mi scrivo tutto da solo, e quello l'ho visto spesso nel mondo del C++, che proprio non esistendo, o perlomeno non esisteva quando ci lavoravo io, un package manager affermato, non c'era modo di fare open source spinto come PHP.Dall'altra parte, JavaScript c'era open source spinto, ma una community talmente grande e frammentata che è la solita battuta, no? Del fatto che nasce un framework JavaScript nuovo ogni cinque minuti.E appunto, secondo me, PHP ha azzeccato il giusto equilibrio lì.Perché sì, ci sono 3-4 framework preponderanti, ma non ne nasce uno nuovo ogni cinque minuti.C'è tanto software open source, ma non devi usare 45 milioni di dipendenze per scrivere un award in symphony per dire capito.No su questo concordo, mi hai per un attimo riportato la mente a php classes.Quando parlavo di contenuto datato.No quando parlavi di c'è un packet manager io ho detto se non ci fosse...ah! PHP class! Quando hai parlato di CI adesso, proprio in questo momento.Per chi ha programmato in PHP anteguerra probabilmente ricorda quel sito dove scaricavi direttamente le classi che erano già un'innovazione super figa.C'è da dire io adesso sto lanciando, cioè sto lavorando un piccolo progettino open source che è un progettino che permette la gestione di una sorta di CMS per i podcast.E là però, vedi, ho trovato dei limiti in fatto di librerie, limiti che avrei superato facilmente con NPM perché molte librerie sono presenti.Invece in PHP, specie quelle che ne so, vanno a scrivere i tag mp3 in un certo formato, quel capitolo, alcune cose mancano.e se devi fare un tool in stile, perché ci sono anche questi casi d'uso, in stile WordPress della situazione che le persone se lo possono installare su uno shared hosting per forza devi usare PHP o qualcosa di simile cioè PHP.Certo, no no assolutamente ma in quel caso per esempio una delle scorciatoie che potresti usare ma in caso di shared hosting forse è un po' azzardata sono le FFI che ci sono arrivate con PHP 7.4, le foreign interfaces, il fatto di poter utilizzare moduli di altri linguaggi interfacciati al linguaggio PHP.Mi è capitato di sentirle usare, per esempio, per interfacciarsi con OpenCV e con il machine learning, di fatto.Cioè è uno strumento che ti permette proprio di tappare il buco di questo genere di mancanza del linguaggio.Quelle sono cose di basso livello che magari non vengono fatte perché PHP è nato per il web puro e quindi manipolare MP3 non è esattamente il focus del linguaggio.Però magari se esiste una libreria C, una libreria Go o Rust che può esporre l'interfaccia C, la puoi chiamare dal tuo codice PHP e in teoria funziona.Dovresti farcela.Quindi, comunque, PHP rimane, secondo me, proprio un linguaggio molto multipurpose, molto modellabile alle tue esigenze.Poi sì, a un certo punto ti devi rendere conto che chiama inglese col chiodo o no.Sì, assolutamente.A quel punto o è un esercizio di stile, oppure, se davvero stiamo parlando di guadagnarsi la pagnotta nel lavoro di tutti i giorni, devi gettare la spugna e dire usiamo il tuo migliore per quel genere di lavoro, non sarebbe possibile altrimenti.Assolutamente sì, anche perché credo che un buon sviluppatore sia un buon sviluppatore in tutti i linguaggi, basta solo imparare quelle cose che ti servono, però che non so, quando ti usi la dependency injection o i pattern che hai imparato lungo la tua carriera, che tu li usi in un linguaggio piuttosto che un altro, se capisci rapidamente il contesto ti puoi muovere facilmente, cioè ci sono delle skill che ti porti appresso a prescindere dal linguaggio, non siamo solo il linguaggio che usiamo.Io l'ho sempre detto da quel punto di vista, per esempio il mio salto dal dal C++ al PHP è esattamente proprio decisamente dall'A alla Z, penso di averlo potuto averlo fatto in maniera relativamente agile un po' grazie al il background universitario, insomma, avendo avuto la teoria alle spalle.L'ho fatto perché volevo imparare tutte quelle cose, cioè andare in una realtà che faceva tutte queste cose di dependency injection, di TBD, eccetera, eccetera.Però l'ho potuto fare perché comunque era un linguaggio C-like, che quello che dovevo imparare in realtà non era il linguaggio in sé, ma l'ecosistema, il tooling, eccetera.e conducono il paese dei balocchi.Ah, il paese dei balocchi! Allora, un po' sicuramente il punto di svolta che ho avuto era un po' la parte di Para Unit che abbiamo citato prima, ma quella cosa lì in realtà è nata dalla prima conferenza che ho fatto, che è stato il PHP Day del 2015, che mi ha dato un po' la spinta in quella direzione.Ci sono stati due keynote in quella conferenza, uno di Kyle Evans e uno del cosiddetto CodeRabbi, che ha un nome impronunciabile, non proverò a pronunciarlo, però lo trovate su Twitter come CodeRabbi, che è proprio...ha studiato come rabbino e ebreo di New York.E hanno fatto due talk che mi hanno proprio segnato in quel frangente, perché CodeRabbi ha parlato dell'insegnamento, del mentoring e del fatto di fare automiglioramento come sviluppatori.E poi, tra l'altro, questa cosa è un filone che poi ho seguito nei vari talk di Gabriele Lana, che anche lui stimo tantissimo e che ha fatto tre bellissimi talk sulla professione del programmatore, che consiglio a tutti, li trovate su YouTube, sono magistrali.E E Kalevans, invece, come spesso gli capita di fare, ha fatto un talk sulla community e sul lanciarsi, sul fatto di prendere dalla community, ma anche dare indietro.E in quel frangente è stato probabilmente la scintilla che mi ha spinto a fare open source, e quindi poi Paraunit, e anche a fare talk alle conferenze.Tra l'altro, come dicevo prima, proprio partendo da Paraunit, il primo talk che ho fatto è stato proprio su Paraunit.E questo penso sia stato il più grosso accelerante che io abbia avuto nella mia carriera.Non posso che consigliare di farlo a tutti.Perché spesso mi rendo conto che dall'altra parte della barricata, da semplice utente dell'open source, da semplice anche solo persona che guarda i talk su YouTube, sembra che chi sta dall'altra parte, chi parla, chi fa open source, sembrano quasi delle star.invece non è vero.Io mi sono reso conto in queste cose che siamo dei poveri disperati come tutti gli altri e che l'unica cosa è che ho trovato la spinta nel raccontare quello che faccio al lavoro e poi piano piano, sempre più anche nel tempo libero, però comunque nell'open source, quelle cose che mi sono ritagliato il tempo di fare.Secondo me è è stata la cosa che più mi ha spinto, che più mi ha fatto crescere nella mia carriera.Sembra difficile, ma in realtà non lo è.A me capita anche quando organizzo il Pug e cerco di invitare le persone a venire a presentare.Tutti si fanno il problema, ma non lo so, ma io cosa vuoi che racconti, cosa più che posso dire? Poi ci chiacchiere due due secondi e invece al lavoro fanno delle robe mirabolanti.E non è che ci voglia questo grande sforzo, perché poi in realtà questo genere di cose, proprio perché, anche iniziare a fare i talk, è sempre straconsigliato iniziare dai meet up, dai gruppi locali.Perché? Perché hai una platea familiare che praticamente fa il tifo per te, perché sono lì per ascoltarti, perché vogliono imparare qualcosa, quindi sono contenti se tu gli racconti qualcosa di interessante.E non c'è bisogno di essere dei grandi oratori.Basta saper raccontare quello che stai raccontando.E quindi se tu racconti qualcosa che fai nel lavoro di tutti i giorni, dovresti conoscere intimamente l'argomento.Noi ci hai litigato, ci hai sbattuto la testa sulla tastiera nei giorni scorsi.E anche solo il fatto che tu racconti la cosa che hai imparato in quel frangente è utile alle altre persone.Lì si rientra nel classico discorso della sindrome dell'impostore, che sempre pensi che tutti gli altri sappiano più di te.E non è assolutamente vero.Tutti gli altri sanno qualcosa che tu non sai, ma la cosa è reciproca.Quindi questa condivisione di conoscenze, questa condivisione di codice nell'open source, secondo me è veramente il vero temper developer.Il fatto di avere l'ingegnere che fa dieci volte tanto.È quello lì.Cioè il fatto che tu non lavori da solo nel tuo cubicolo e non puoi chiedere aiuto.In realtà la vera potenza è quella, il fatto che tu puoi fare leva dell'esperienza del lavoro di migliaia di altri sviluppatori che prima di te hanno scritto codice e l'hanno condiviso o che hanno condiviso le loro conoscenze in un talk, in un meetup o anche qui in questo podcast fondamentalmente.Sì è un po' quello che facciamo noi e io dico sempre se comunque sono riuscito a raccontare queste storie nel podcast e ci sono riuscito io che non so parlare l'italiano, che ho l'accento di Oxford Nord, che non riesco a pronunciare le parole in inglese e che so veramente poco, allora a questo punto ci può riuscire chiunque e specialmente ci può riuscire chiunque a dare valore.Secondo me si può fare anche per un motivo quasi egoista, nel senso che non è solo il valore che tu dai ma anche quello che ne ricevi.Io probabilmente ho potuto fare quello che ho fatto e sono arrivato a fare le conferenze all'estero e queste robe qui perché mi sono messo su questa strada.Cioè, non è che stai facendo beneficenza, insomma, da un certo punto di vista, no? O meglio, sì, stai aiutando il prossimo, stai distribuendo conoscenze e codice, però il primo che ne giova sei tu.Perché se devi preparare un talk, ti devi studiare bene un argomento e se riesci a spiegarlo, vuol dire che davvero hai capito bene.Anche se è un argomento piccolissimo, anche se è una frazioncina, va benissimo.Io ho guadagnato tantissimo da queste cose, ho conosciuto un sacco di persone interessantissime attraverso l'open source, attraverso il PHP Fig, che poi è stata quasi la naturale conseguenza di portare avanti questi sforzi.Ho avuto modo di chiacchierare faccia a faccia faccia con i vari maintainer di grandissime librerie, perché poi forse un po' come il PHP ha una così bassa barriera d'ingresso, non ce ne rendiamo conto, ma anche queste cose hanno una bassissima barriera d'ingresso, basta che tu abbia voglia, non c'è un limite, un problema, un buttafuori che ti dice "no, tu non puoi entrare", basta che tu ti metti e provi.In genere il problema è quasi sempre fare il primo passo.E infatti spesso e volentieri consiglio cose tipo o il Pug per i talk, che è il momento ideale, anche se sei timido, anche se pensi di non avere tanto da raccontare, perché hai delle persone che lavorano come te nella tua città, che semplicemente vogliono sapere che caspito combini nella tua vita di sviluppatore.Oppure eventi tipo l'Octoberfest di GitHub per l'open source, no? Non so da dove cavolo iniziare per l'open source.Cerchi di trovare una micro issue da iniziare a fare e da qualche parte inizia.E ti butti.Sì, io ricordo la prima volta che ho fatto un...tornando da un phpday in albergo, da quel phpday 2015, Ricordo che c'era un problema con PHP spec su un operatore di verifica, non mi ricordo cosa fosse, precisamente avevo fatto una pull request proprio spinto da quella carica, anche emotiva, perché questo tipo di eventi, il confronto con persone, ti spinge a carica emotiva e poi quando quella picchiolissima pure questa è stata è stata emergiata non puoi capire la gioia perché dici quel micro pezzo di codice che ho fatto io la stanno usando un gozziliardo di persone e allora vuol dire che anch'io valgo nell'ecosistema salvo poi scoprire che come dici tu le altre persone anche quelli più schillati quelli più figli sono persone come te e e alle volte tu riesci a dare spesso più valore di quanto ne prendi quando ti confronti con loro.No, no, per me è sempre meglio.Assolutamente.Oppure, come dice Mattia, trovi davanti una persona che ama talmente tanto quello che scrive, se non mi sbaglio parlava di Archibald, ma potrei sbagliarmi comunque in Google, dice "quando io mi sono avvicinato e gli ho chiesto", l'ha raccontato nel nostro gruppo Telegram, cosa faceva non mi mollava perché aveva così tanta passione in quello che faceva Che non mi mollava e questo l'ho trovato in tante persone che amano il loro lavoro e che magari ricoprono anche il ruolo di divulgatore conferenziare così questo tipo quindi Buttarsi e mettersi in gioco è senza dubbio il primo il primo passo e va fatto a prescindere senza remore senza paura di dover fare una bella o brutta figura.Non ci sono né belle né brutte figure, c'è solo il mettersi in gioco e provare a entrare in questa dinamica di dare e avere, dove tra l'altro quando stai dando senza neanche prendere stai già prendendo di suo, perché per esempio nel dare, nel raccontare, stai imparando ancora di più e stai facendo ancora più tuo, in modo profondo, l'argomento come detto prima.Quindi sposo appieno e concordo, sottoscrivo col sangue tutto quello che hai detto.Io, Alessandro, adesso ti lascio andare a mangiare perché ormai si è fatto tardissimo.Io ti ho rubato praticamente tutta la mattina.Ti chiedo scusa se sono stato...Naturalmente rinnovo l'invito quando hai qualcosa da raccontare o che ti fa piacere condividere con la nostra community, GIT Bar e anche Casa Tugan, nel senso che essendo il bar degli sviluppatori puoi venire a berti una birra con noi quando vuoi, quindi anzi ci fa super piacere averti tra di noi e quindi noi ti ringraziamo per essere qua e nulla tutto qua.Grazie a te per avermi aspettato.Grazie Alessandro, noi ci sentiamo la prossima settimana ma prima di lasciarvi vi ricordo rapidamente i contatti info@gitbar.it via email o @brainrepo su twitter il nostro gruppo telegram non smetterò di ricordarvelo Gitbar là ci sono tutte le ultime discussioni proprio stamattina vedevo che si discuteva di carring e di applicazione parziale quindi l'argomento mi ha supergasato e nulla cosa sto dimenticando Ah sì, se non l'avete ancora fatto, cercate Gitbar con il vostro client di podcast e iscrivetevi.In questo modo naturalmente riuscirete a essere notificati sulle nuove uscite.E poi se proprio vi fa piacere e se usate un iPhone, aprite l'applicazione podcast e lasciate una recensione.Questo ci aiuterà a portare nuovi ascoltatori e nuovi amici all'interno di questo bar.detto tutto, detto questo e tutto io vi do appuntamento alla prossima settimana con un nuovo ospite qua su Gitbar ciao Gitbar, il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo Parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.[Musica] [Musica]
