Bene e benvenuti su Geekbar, sì siamo ancora in ammutinamento ma questa volta non completamente per colpa nostra per chi si fosse perso la puntata precedente ricordiamo che il nostro affezionatissimo Brain Repo è stato imbabagliato e legato nelle cantine di Geekbar per impedirli di fare un episodio sul PHP ora noi tutto sommato adoriamo e diamo tutta la nostra riconoscenza al PHP ed è per questo che subito dopo l'episodio scorso era nostra intenzione liberarlo Tuttavia il nostro scherzetto ha provocato un piccolo effetto collaterale.Una volta tolto il bavaglio il nostro Brain Repo ha cominciato a cantare in loop le brutte intenzioni, la maleducazione e la tua brutta figura di ieri sera.A cosa si riferisse non ne abbiamo idea.Ma sappiamo che l'unico modo per farlo smettere è quello di farli vedere tutte le puntate di Sanremo dal 1951 ad oggi.Attualmente siamo all'anno 1971 con i ricchi e i poveri che cantano "Che sarà".prima di cominciare la nostra puntata è mio dovere ricordarvi i contatti info@gitbar.it per comunicare con BrainRepo via email su twitter @brainrepo ma soprattutto ricordiamo il gruppo telegram cercando semplicemente Gitbar e che ve lo dico a fare ma bando alle ciance via la sigla e poi cominciamo 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.Io posso pure dire via, ma chi parla? Bene, benvenuti a un'altra puntata di Ammutinamento, quindi il nostro ottimo brain repo è ancora rinchiuso nella cantina e abbiamo ancora gli stessi ammutinati dell'altra volta, più o meno, quindi credo che comunque sia opportuno fare un rapido giro di presentazioni anche se ormai ci conosciamo.Io sono sempre Mattia Tormasone, sempre un grande affezionato sia di Gitbar e del gruppo Telegram e anche di Kotlin, che è un argomento su cui annoio spesso e volentieri il gruppo Telegram suddetto e probabilmente oggi anche voi ascoltatori.E basta, passo la parola a Luca a questo punto.Io sono Luca Rainone, responsabile dell'area della pear a bolzano, programmo, sono uno sviluppatore, programmo in php, in javascript, node, quello che passa, quello che c'è, niente, sono un appassionato di gitbar soprattutto, il mio grande amore e dello sviluppo in generale.Passo il peluche a Carmine.Lo lancio.Ciao a tutti, io sono Carmine Di Monaco e sono un full stack developer in un'azienda di Firenze che si chiama FUPS e sono anche uno degli ammutinati di Gitbar.Mi ha fatto piacere ripresentarmi perché sai, poi si dice "ormai ci conoscete già", è vero però alla fine possiamo dire che ogni puntata noi siamo un riferimento nuovo in memoria no sostanzialmente quindi siamo sempre diversi ogni giorno e ogni puntata e su questa cosa questa battuta bruttissima passo il peluche a Alessio.Ti risponderò con una battuta ancora più brutta ogni puntata noi per siccome siamo molto amanti della programmazione funzionale e parlo con noi tipo Mago Delman, più lave il problema di status.Siamo molto amanti della programmazione funzionale, allora in realtà per l'immutabilità, ogni puntata siamo proprio un'intera entità, tutta restituita di pacca, nuova di pacca.Sono Alessio Biancalana, Senior Software Engineer a WoodSuite.Mi piace, come avete capito, la programmazione funzionale, JavaScript, che può essere a volte un controsenso, Elixir, Language Design e soprattutto la cosa più bella del mondo, GitBar.E sono anche io qui con voi oggi, rivasso il Tolkien Sticker, Mattia.Grazie.Quindi, visto che ogni puntata è un nuovo ammutinamento, che abbiamo una serie di temi che ci portiamo dietro di volta in volta.L'idea nostra di oggi è che nel canale Telegram, e non solo, a noi capita spesso di leggere articoli interessanti, paper interessanti, documenti, libri e quant'altro, ed essere uno dei motivi per cui il gruppo Telegram è così utile per tutti che ci dà anche un ottimo modo di essere aggiornati su quello che succede nella nostra scena e nel nostro mondo.Quindi l'idea di oggi è di fare un po', se volete, di rassegna stampa, partendo da alcuni articoli che abbiamo visto e che abbiamo condiviso tra noi ammutinati di recente, nell'ultima settimana, di discutere un po' di alcuni temi che secondo noi probabilmente sono molto interessanti, o almeno lo sono stati per voi, e spero, speriamo, che lo saranno anche per voi.Il primo articolo che ha catturato la nostra attenzione questa settimana è un articolo di Techradar.com che ha un titolo forse un pochino clickbait, nel senso che il titolo è "Gli sviluppatori open source potrebbero valere miliardi".Detta così, ok.È assolutamente un titolo altisonante e fondamentalmente cita una ricerca, ancora non pubblicata, quindi è fondamentalmente un teaser pubblicata, che invia ripubblicazione da un think tank che si chiama Open Forum Europe, quindi guidato dalla Commissione Europea, per cui sembra che gli imprenditori europei non stiano sfruttando appieno i vantaggi che l'ecosistema e la comunità open source potrebbero dare loro.e la stima appunto di questa ricerca è che si tratti di decine di miliardi di euro che potrebbero essere risparmiati o guadagnati dalle aziende e dagli imprenditori europei se la comunità open source e l'ecosistema open source fosse utilizzato in maniera più efficace.A questo punto io sul tema vorrei sentire il parere di uno dei miei esperti di open source preferiti, che è Alessio.Allora, già mi hai messo in imbarazzo questa cosa.Ricordiamo agli ascoltatori, a chi non lo sapesse, che Alessio ha una mail @paci.org e questo già ti rende autorevole sul tema dell'open source by design.Assolutamente.questo mi rende anche però super investito di un'aura di autorevolezza che assolutamente non mi merito e fatta questa doverosa premessa mi sono venute in mente duemila cose che non mi sono appuntato, quindi andrò a braccio e sicuramente non si capirà niente, però sicuramente è vero che l'Europa non fa come ecosistema geografico, ma è vero che geografico, diciamo, non valorizza abbastanza l'open source, ma non tanto in assoluto il termine di comparazione che mi viene in mente, a me personalmente, è la Silicon Valley, dove è nato...si è fatta tanta retorica nel tempo sulla Silicon Valley, su quello che è San Francisco e l'intorno, In realtà l'immenso valore delle istituzioni che stanno là nei dintorni come Berkeley è stato proprio quello di generare del software, di mettere a terra del software che generasse valore tra virgolette per conto suo.In Europa noi non l'abbiamo mai troppo fatta questa cosa qua.In realtà, tra l'altro, questo è paradossale perché abbiamo un potenziale in espresso infinito.Tant'è che uno dei project leader, nonché il maintainer principale, ora come ora, di CouchDB, che è il progetto Apache in cui io sono maggiormente coinvolto, è John Lennart, che è tedesco.Però in Europa non abbiamo mai fatto qualcosa di...come posso di pivotal in questo senso, cioè che usasse l'open source come volano per fare delle cose simili a quelle che sono nate in Siri Home Valley.Il problema è che secondo me è anche una questione di ecosistema imprenditoriale.L'unico posto in Europa che io riesco a immaginare come ecosistema imprenditoriale simile è la chena startup berlinese, perché è quella più feconda di casi di studio particolari, tipo, che ne so, Number 26, che è stata una delle prime fintech nel mondo proprio, nella nicchia bancaria.E loro fanno anche parecchi open source, che io sappia.Poi l'altra cosa totalmente scorrelata che vorrei dire è che in realtà a parte tutta la scienza che viene tirata in mezzo nella programmazione, io trovo assolutamente giusto che, come dice la prefazione dell'articolo, c'è qualcosa di controintuitivo riguardo open source che è il fatto che tu hai una cosa gratuita da costruire, insomma, da mettere in giro e però quella cosa diventa una cosa su cui si costruisce un business model e si genera valore, si genera denaro.In realtà io ho sempre, andiamo quasi sul versante spirituale, io ho sempre equivarato la programmazione a un atto divino di creazione, quindi in realtà secondo me è totalmente giusto che dalle nostre mani si generi qualcosa che anziché ridurre l'energia che viene trasmessa alla amplifica.Assolutamente, sono assolutamente d'accordo.E secondo me è interessante anche ora parlare di open source, io ne sto parlando sì perché che magari è un tema al cui in questo momento sono un po' più vicino, e parlare di open source quando parliamo di amministrazioni pubbliche.Tra i vari link che vi lasceremo in descrizione c'è il link anche al comitato per il public money e public code.Che cosa significa? significa sostanzialmente che c'è tutta una cerchia di persone, di aziende, di organizzazioni che si impegnano per far sì che il codice scritto per un'amministrazione pubblica che possa essere qualunque sia un codice rilasciato open e c'è, insomma, il claim più grande che si vuole fare è se io sto pagando dei soldi con le tasse dei miei cittadini io voglio che questo codice sia il migliore possibile e sia reso open, che quindi magari che possa su cui i cittadini stessi possono contribuire e possono contribuire a migliorare quello che è il servizio, l'applicazione o semplicemente l'esperienza di sviluppo di quella cosa lì.secondo me questo è un filone importante, che non viene...che quando si parla di open source alcune volte viene diciamo...come posso dire, non considerato o meglio, si parla sempre di open source anche e quasi solo esclusivamente parlando di aziende private.Quindi magari si possono citare i vari casi che ci sono in cui ci sono delle aziende che fanno del software open che però hanno anche un modello di business che gli permette di guadagnare e di essere competitivi con quel software open.Ad esempio immagino che tutti quanti qui dentro abbiamo utilizzato GitLab, stiamo utilizzando GitLab e quello secondo me è un esempio perfetto di qualche cosa che è data sia open, sia magari on premise con i vari servizi che offrono loro nelle varie versioni, ma è un modello di business che comunque è un modello di business vincente, un modello di business che può reggere e regge.E spesso però, quando magari si parla di queste cose, è sempre un discorso tra tecnici o meglio, ad esempio è lo stesso bias che sto avendo io in questo momento.Se devo fare l'esempio di un'azienda che fa open e ci guadagna, ho fatto l'esempio di GitLab, che comunque è qualcosa che è fatta da tecnici per tecnici.Quindi magari secondo me andrebbe anche ricalibrata la discussione per parlare di open source, ma anche non necessariamente diciamo di prodotti che sono tecnici per tecnici.quindi come può essere ad esempio qualunque servizio di infrastruttura pubblica, un paese, un comune, una provincia.Cioè, secondo me va fatto conoscere il pensiero open anche a chi non è tecnico, giusto per fare una piccola divergenza politica.Siamo comunque in un momento storico in cui, diciamo, ci sono tante movimentazioni per un mondo più giusto e per un mondo più eco.Secondo me i cittadini dovrebbero prendere, e le persone in generale, dovrebbero prendere la consapevolezza anche di questa parte del mondo.Anche ora qui sto andando totalmente per la tangente e non c'entra niente.Però nel senso, perché se ne parla solo tra noi tecnici per cose tecniche? Secondo me, perché? Allora, è una buonissima domanda e io tra l'altro ho due domande che poi vi voglio porre a seguito delle cose che avete detto, che sono molto molto interessanti.Credo che ci sia, come dici tu giustamente, un gigantesco problema di barriera all'ingresso, nel senso che ancora l'open source è visto come una cosa da tecnici.Mi aspettavo, tra l'altro le due domande che vi voglio fare sono estremamente legate all'attualità, visto che comunque il tema di rassegna stampa credo che abbia senso che restiamo anche molto ancora qui, al presente e al momento storico che stiamo vivendo, che per chi ci ascolterà nel futuro è marzo 2021 e siamo ancora nel pieno della pandemia.Credo che questo momento storico abbia delle sfide e delle opportunità per il tema dell'open source, nel senso che proprio in Italia, tra l'altro, c'è stato un caso di un'applicazione che a furor di popolo è stata rilasciata a open source, cioè il MooVie, che poteva essere una grossa opportunità di far conoscere il tema dell'open source a un pubblico non necessariamente tecnico.Secondo voi, questa opportunità è stata sfruttata bene o male? O non c'era verso di fare meglio di così o peggio di così? Come è andata, secondo voi, questa cosa rispetto alla percezione dell'open source? Però allora faccio l'altra delle due domande, che è che Alessio in effetti ha detto giustissimamente che molti dei progetti open source che usiamo adesso sono nati, o comunque sono fioriti in un contesto come quello della Silicon Valley, che è di fatto una scena molto localizzata.E solo per il fatto di essere geograficamente in un posto, sei esposto a molto open source e a molto software di qualità.Questo è un tema, io sono un grande appassionato di musica, tema di cui si discute moltissimo e di cui si è discusso moltissimo nell'ultimo anno e prima ancora, ma la pandemia lo ha estremamente accentuato.Esistono ancora le scene locali? Hanno ancora senso le scene locali in un contesto in cui il grosso della gente sta chiusa in casa? C'è ancora davvero un grosso beneficio stare in un posto, geograficamente, in cui attorno hai tante persone con interessi simili oppure la percezione che ho io della comunità open source che è una comunità assolutamente globale e quindi non lo so, vorrei sapere come la pensate voi rispetto appunto al rapporto tra open source e sviluppo software in generale e scene locali, è una cosa che esiste, che è ancora molto importante o che andrà scemando? Mamma mia, cioè mai fatto la domanda delle domande, adesso ti attacco un pippone incredibile...- Tra l'altro è una domanda che facevo sempre ai musicisti, quando stavo con i musicisti, quindi è assolutamente una cosa che mi piace chiedere alla gente.- Allora, io ho due opinioni sulla...cioè io ho tipo la crisi mistica, nel senso che io ho due opinioni distinte sulla cosa, una per metà del cervello, assolutamente contrarie tra loro, però in qualche modo tipo il Tao se riconciliano.Il punto è questo, uno sviluppatore o comunque un creatore, una persona che fa un'attività intellettiva, si trova inserita in un contesto locale.Secondo me non è possibile prescindere dal contesto locale, cioè non è possibile prescindere, io per tantissimo tempo l'ho fatto e dopo arriva anche il momento storiella, però qual è il punto? Io ho scoperto che Ciampino è la nuova Silicon Valley, nel senso che io ho letteralmente una delle persone che reputo più brave in Italia, parlando di sviluppo software, a parte i presenti chiaramente perché sto nell'ecchinaggio subito, Federico Caprari, che è una persona che ha lavorato con me per parecchio tempo, diciamo, e ha rannato, non so come dire, ha presieduto alcuni meetup della scena romana e è praticamente il mio vicino di casa, nel senso che abita un chilometro da me e stiamo tutte e due a Ciampino.Quindi quando si parla, quando c'è il meetup, qualcosa, si va a casa insieme e in generale tanto più è locale la cosa, il meetup, l'evento che si tiene, tanto più ti fa piacere avere qualcuno vicino casa con cui parlare anche se non ti ci vedi di persona, cioè è strano perché comunque in chat c'hai costantemente dei dei riferimenti tipo che ne so ci andiamo a prendere una birra al King Arthur, che è un pub famoso di Ciampino, sono andato in piazza, c'era c'è e sono discussioni che per assurdo sono riferimenti che per assurdo vengono fuori anche nelle discussioni di coding, perché banalmente sono relativi ad esempi che puoi fare eccetera eccetera.Quindi questa è la mia prima barriera di opinione.La seconda qual è però che io per tanto tempo sono stato l'unica persona a occuparsi di Linux, open source, free software, eccetera, eccetera, nel paesino di Palestrina, provincia di Roma, che è un posto a 40 km da Roma, in cui, cioè, non me ne vogliano i palestinesi, però, cioè, non c'è niente, nel senso che comunque è una realtà molto locale, un paesino.Io ho passato, da dopo i 14 anni, fino a che io non ho trovato lavoro praticamente, e anche questo è stato...Cioè, ho cominciato a frequentare alcune realtà online e ho trovato lavoro.Ma prima di quello, la mia unica interazione con l'umanità avveniva attraverso la mia camera da letto col computer.quindi in realtà io per tantissimo tempo non ho mutuato la mia interazione col mondo attraverso dei gruppi locali.Ho fatto direttamente escalation sui canali IRC di qualsiasi distribuzione Linux e mi trovavo sotto mano.E quindi in realtà io ci sono arrivato molto tardi e penso che siano entrambe due facce della stessa medaglia, perché da un lato con il contesto locale vieni immerso in qualcosa e vieni formato in qualche modo e insomma martellato da varie parti, però allo stesso tempo, soprattutto con la pandemia, il contesto globale secondo me su certe cose prende il sopravvento.La cosa importante è che in realtà, soprattutto con la pandemia, io appunto parlo molto di più col mio vicino di casa, cioè molto di più ci parlo allo stesso modo rispetto a quando stavamo in ufficio insieme.Quindi è stranissimo, cioè questo è un racconto, diciamo la morale di questo racconto la lasciamo per esercizio al lettore.Però veramente per me è stato stranissimo tutto questo.Io sono un tipo abbastanza marziale e ti posso spiegare questo semplicemente mettendo in ballo l'energia che comunque vuoi o non vuoi si crea quando sei a contatto fisico con una persona.i cinesi hanno un nome per questa energia che è il "C" e di fatto, essendo io una persona marziale, secondo me esiste ed esiste come e si vede proprio nel momento in cui incontri una persona con le tue stesse passioni o altro e entrate in sintonia e, cavolo, producete idee o, nel nostro caso, anche software, volendo, che da soli, ognuno chiuso nella propria cameretta o nella propria camera, ma in connessione con internet, forse non sarebbe stato lo stesso.Al netto di Al netto di questo, secondo me, ritornando al tema open source, vado un po' controcorrente e butto un sassolino, anzi mi levo un sassolino nella scarpa.Secondo me l'open source crea tanta tanta tanta entropia.Mi è venuta in mente questa parola quando hai nominato proprio l'essere un po' il creatore, un po' il dio e creare dei piccoli universi.Pensavo sì, però nell'universo l'entropia aumenta di continuo e forse l'entropia è il caos che aumenta e questo forse un po' si vede, basta aprire github o github, sì è bello, è tutto open, c'è tutto, alla fine veramente possiamo vedere, possiamo fare, possiamo scrivere di tutto, però orientarci in tutto questo caos non è facile.Qualche tempo fa mi è fatta troppo in mente una cosa che è vera, nel senso che l'open source, il software in generale, è diventato una bolgia per alcuni versi, perché qualche qualche decennio fa tu leggevi le guide per i beginner su Linux, tanto per tornare alle mie prime passioni e la prima cosa che ti dicevano era tu per compilare un software su Linux fai ./configure make and make install, sempre quello, perché tanto su Linux c'era una cosa sola che girava, a parte tempi più recenti, c'era una cosa sola che girava che era C e basta e tu con auto-conf facevi tutto.Il problema è che ultimamente invece con NoJazz, Ruby, Rust, C++, qualsiasi cosa improvvisamente è diventato...cioè non c'è più la regolauria.Io sono una persona molto amante del freeform e freestyle di qualsiasi cosa, quindi sono super contento però quando vedo persone che mi dicono che ne so, la JavaScript fatigue o la Kubernetes fatigue per andare più in ambito DevOps, dove c'era qualche tempo fa ho visto questo chart immenso di tutti i tool disponibili per Kubernetes e mi è venuto il mal di testa persino a me chiaramente lo percepisco, la percepisco la fatica e la lotta e da una parte la capisco veramente, poi questo per dire cosa? Che secondo me c'è anche un discorso politico nel senso che le istituzioni pubbliche possono fare qualcosa in questo senso diventando dei casi di studio esemplari riguardo l'adozione di tecnologie aperte.Noi in Italia c'avevamo una legge bellissima qualche tempo fa che era quella sull'open by default che ovviamente fatta la legge trovato l'inganno hanno trovato 10.000 modi di giracci attorno e fa fare cose alle società di consulenza chiaramente con i soldi dei contribuenti e non dando il codice in pubblico in open source e lo dico contro i miei interessi perché fino a qualche tempo fa lavoravo in società di consulenza.Quindi secondo me, tornando al tema originale, c'è qualcosa che potremmo fare in questo senso, stimolando le istituzioni, solo che il problema è che poi l'omino all'interno dell'istituzione quando va a parlare queste cose col capo suo, visto come un tecnico, purtroppo non è che poi fa una raccolta di firme per chiedere che il ministro dello sviluppo economico rilasci la sua configurazione del cluster kubernetes, sarebbe bellissimo però.No, secondo me hai toccato un punto importante, io ad esempio comunque lavoro per una soledà che fa consulenza alle smart city, quindi sostanzialmente sono enti pubblici insomma.Sono d'accordo con te, quella è una cosa che ho detto già prima, c'è anche il movimento che vuole portare avanti questa cosa così.Poi ovviamente lì secondo me ci si scontra anche con la tipologia di prodotto che si fa.Secondo me è giusto che alcune cose rimangano closed, se magari sono delle cose specifiche, magari l'istituzione sta comprando un prodotto, un servizio che offre quella direzionata azienda, e se è service, magari quindi ci sta che quello rimanga closed.Però, nel senso, quello che io farei, e che poi alla fine è quello che stiamo cercando anche di fare con la mia società da un po', è restituire alla community qualcosa.Quindi magari non mettere tutto open, quello che magari è il core business dell'azienda, che quello avrebbe poco senso, non lo farebbe effettivamente nessuno, ma restituire qualcosa anche come imperativo morale.Quindi magari se io, a questo punto un'azienda che può operare come consulente per il settore pubblico o no, ma ingerà e darsi come imperativo morale quello di restituire qualcosa, quando comunque alla fine dal mondo open si prende quasi tutto, credo.Alla fine anche con quel sondaggio omano possiamo dire comunque che la maggior parte delle tecnologie che si usano sono fondamentalmente open, quindi alla fine anche solo restituire credo che sia importante.Poi è vero anche che secondo me nell'ambito pubblico, ora in Italia non so benissimo come la situazione, non la commento nemmeno perché tanto una volta ogni cinque sei mesi cambia qualcosa.Erano passate dall'applicazione immune open, immuni open, che la faceva Bending Spoons, mi pare che ora abbiano fatto l'handover a Sojay o una cosa del genere, poi c'era l'applicazione io open, applicazione io che è ancora tuttora open, diciamo sembrava che stesse venendo fuori un movimento per cui davvero il codice è fatto dall'istituzione stessa, quindi magari non dalla società di consuenza che ha il suo interesse a tenere quello che è il suo Corp Bid Disclosed, ma i sviluppatori pubblici che sono pagati con le tasse pubbliche, sembrava che si stesse andando verso un filone di "facciamo tutto open".Poi non ho seguito bene che cosa è successo con l'Agid, con l'agenzia per digitale che è stata aperta poi chiusa poi non si è capito quindi effettivamente non so in Italia come siamo messi ma ci sono comunque alcune realtà a livello europeo che sul pubblico stanno investendo molto.Uno di questi comitati, se così possiamo definirli, è quello di di FIWARE, che è sostanzialmente un insieme di persone e di aziende che collaborano per rendere disponibili delle soluzioni che siano open e che magari diventino anche uno standard per le smart city.Ho preso un esempio a caso perché è il dominio con cui sto lavorando, però secondo me alcuni movimenti a livello europeo ci sono e stanno nascendo.Quello che a me dispiace è che nel dibattito pubblico, specialmente quello italiano, si è perso l'interesse, un po' come si diceva prima, 5-6 mesi fa, se il codice di Muni non usciva open, le persone si volevano strappare questi capelli in piazza, quello che è sostanzialmente successo e che ora a chi ne frega più niente a nessuno, indipendentemente poi dall'adozione o meno delle persone.Ho fatto l'ennesimo pippone dove non si capisce niente, però va bene così.Va bene anche così.In realtà il tema è estremamente difficile da gestire perché ha delle implicazioni, come avrete capito, non solo tecniche, ma anche filosofiche, nel senso di cosa ti aspetti che sia il software, che ruolo abbia il software, e quindi anche politiche, nel senso che dipende anche un po' da questa questione, che ruolo ti aspetti che abbia il software nella società e nel contesto in cui poi inevitabilmente è calato, nessuno di noi scrive software in isolamento.Per cui, appunto, secondo me è un argomento su cui è bene e tutti riusciamo a farlo, fare quell'esercizio di cui parlava Alessio, di tenere nella mente contemporaneamente delle idee discordanti e cercare un po' di bilanciarle, perché è proprio la classica domanda, o comunque crea un grosso insieme di domande da cui non c'è una risposta univoca e definitiva.Invece, un argomento altrettanto, diciamo, flame inducing, e su cui ognuno probabilmente ha la sua opinione, e sono molto curioso di conoscere le vostre, è un altro articolo che ho letto questa settimana e che abbiamo letto tutti noi ammutinati, che dice che il futuro delle applicazioni web è servire HTML sui WebSockets.È un articolo di Alistapart, quindi una fonte assolutamente autorevole, che poi all'interno del post, che è, tipo, sullungo e molto ben articolato, racconta di alcune scelte e di un po' dell'evoluzione delle applicazioni web degli ultimi tempi e fa delle scelte controverse.Nella fattispecie, Carmine, so che sei un esperto del tema, alla fine del post parla di Rails.[Carlo]: Ah, solo che Carmine ha due usci.[Carlo]: Ah, eccoci.[Alessio]: No, no, scusate.Cioè, c'è stata una giornata.[Carlo]: Ho fatto la finta.[Alessio]: Ho fatto la finta.No, in realtà, secondo me, è un bellissimo argomento che che poi alla fine è tutta una serie di corsi e ricorsi storici sulla programmazione.Anche nello stesso articolo si cita come, diciamo, grandi framework web monolitici, in questo caso si cita Rails, abbiano fatto nel tempo, abbiano implementato delle soluzioni che sono molto simili a quello che fa poi live view con Phoenix, ovvero quello di servire on demand dei pezzi di HTML e di Java scritto per arricchire l'esperienza dell'utente sulla pagina.Cioè, nel senso, il mio bold statement è "eravamo arrivati al punto in cui qualche anno fa questa cosa non si doveva fare per incapsulamento per il frontend separato, per fare un refactoring più pulito per non averci il monolite, che sono cose che assolutamente condivido e che faccio comunque tuttora.Però è interessante vedere come il tempo passa, però alla fine sono sempre gli stessi temi che ritornano ciclici, quindi ora si può parlare, immagino che comunque Alessio da amante di phoenix avrà tanto da dire su questa cosa qui però poi si si torna tanto sul fatto allora si torna a fare mvc questa mvc per un po' si era detto che c'era un po' rotto insomma e ora si ritorna si ritorna sempre sulle stesse cose secondo me sono tutte soluzioni bellissime per un prototipo, per un MVP, per qualche cosa che è veramente quasi esclusivamente data centrico, nel senso io sto modificando il mio modello, in questo caso per attenersi allo stesso paradigma che usano Phoenix e Rails, e quindi uso questo strumento per poter fare delle modifiche sul mio modello, sulla mia entità e sono disposto a prendermi il compromesso di, diciamo, di andare a fare la classica struttura che sia Fat Model, in questo caso, oppure ci sono anche quelle a cui piace dire "a me piace il Fat Controller", Insomma, doveva avere questa cosa ciccia che poi alla fine diventa anche il centro della mia logica, della mia applicazione.Mi suggerisco dalla regia che prima ho detto crudo, ho detto MVP, ma mi sono dimenticato POC, che era effettivamente quello che volevo dire.Quindi a questo punto lascio anche la parola a voi perché voglio essere contraddetto, cominciano a uscire questi tweet di DHH dove si legge o letto che su Twitter DHH ha detto che è bellissimo.Prego.Nel frattempo siamo anche stati raggiunti da un altro ammutinato che salutiamo.Ciao Andrea, benvenuto nell'ammutinamento e nel backstage di BitBar.Ma questo non è clubhouse, ho sbagliato room? sì io so comunque ciao a tutti tanto vale ciao a tutti, super onorato per entrare a far parte degli ammutinati ed eccoci qui per dire la nostra a discapito di Brain Repo ma no, porra tu...vi faccio la domanda proprio dritta in faccia monolite o microservizi? monolite, tutta la vita la vita.Monolite.Anche io monolite.Basta con tutti questi microservizi, deployare cose ovunque, ti perdi completamente il contesto di cosa è deployato, in quale versione.Ogni volta per portare una modifica devi deployare sette cose differenti con un certo ruolo, uno dopo l'altro, altrimenti si spacca tutto perché non siamo bravi a mantenere le breaking change eccetera eccetera.allora fai tutto un bel bloccone, se funziona tutto qua in locale funziona pure là, quindi dai Emonolite! Io voglio un bello Fat Jar in ogni serve! Adesso mi attacco una pippa partendo proprio dai massimi sistemi, dall'antichità allora io sono un appassionato di gioco di ruolo, in particolare quando tu c'hai nella la terra degli elfi e dei nani, il tuo guerriero che vuole spaccare la faccia a tutti quanti.C'è una cosa che ha preso piede particolarmente negli ultimi anni nelle comunità che frequento, oltre quelle del software, anche quelle del gioco del ruolo, e di cui pure tutto il discorso di prima, che ci sono persone che fanno sti background dei personaggi, che so, delle storie passate dei personaggi prima dell'avventura che stai vivendo che so tipo dei 60 pagine.Questa cosa però tante volte va in contraddizione col fatto che la cosa più bella del gioco di ruolo, almeno per me e per quelli che seguono questo tipo di dottrina, è vedere evolvere il personaggio.Che cosa significa? Che tu parti, che sei di livello moderatamente basso, con degli achievement passati moderatamente bassi, a un certo punto durante l'avventura trovi il motivo per diventare uno forte, tipo Aragorn.Aragorn prima era mingo, poi diventa insomma l'erede dei Isildur perché lui ha questa cosa dentro.Poi all'interno del Signore anelli, lui effettivamente mena una fracca di orchi e diventa il re dei condor perché ha menato una fracca di orchi.Questo che cosa c'entra con i microservizi? Fuggite sciocchi! Esatto! Questo che cosa c'entra con i microservizi? Tu non puoi partire direttamente a microservizi perché in realtà l'idea che tu ti fai di partenza del tuo dominio applicativo è totalmente piena di una serie di bias, di cose, di preconcetti che uno si porta dietro, che poi andando a esplorare in maniera operativa il dominio vengono totalmente scossi e dei quali viene fatto totalmente debunking e quindi in realtà il diagramma iniziale che tu ti hai ripreparato diventa carta straccia, nel momento in cui ti vai a scontrare con le necessità del business, con le necessità del mondo reale, con le necessità di tutto quello che non sta sul blueprint.Quindi il discorso è, come dicono praticamente tutti i libri dei microservizi, tra l'altro in realtà non è che mi invento niente, tu parti col monolite, fai una cosa ragionevolmente splittabile e piccoletta e poi dopo lo porti ai microservizi staccando i pezzi.Questo come si fa? Con i bounded context del domain-driven design.Questo è uno strumento principe tra tutti.Che cosa ci vuole dire l'artista con tutto questo? Dato che stavamo a parlare HTML over WebSocket.che Phoenix e tutto il discorso di LightView Phoenix, per chi non lo sapesse, dato che abbiamo ascoltatori che provengono dai più disparati ecosistemi è il web framework di riferimento per l'ecosistema di Elixir che è un linguaggio che deriva da Erlang è una cosa che se non la conoscete non vi preoccupate E all'interno di Phoenix effettivamente ci sono delle idee che sono abbastanza innovative, tra cui questa libreria che ti consente di fare, la semplifico molto, le stesse cose che fa React, semplicemente comunicando in maniera costante attraverso un WebSocket col back-end che ritorna frammenti di HTML che a loro volta vengono renderizzati.Questo è HTML over WebSocket.Ma stessa cosa di fare Act, un bel bold statement.Questo è bold statement, però sì, dato che il 90% del software è crude, e di questo ne parleremo dopo, c'è delista.Allora, fa quello che fa qualunque, che fa Ember e quello che faceva Meteor e quello che fare art, anche quello che fa esattamente.Assolutamente, sì, io parlo di React perché ci lavoro tutti i giorni.Comunque il discorso è, se tu hai una POC da fare HTML over WebSocket con Rails, con Phoenix, con quello che ti pare è il tuo strumento, perché semplicemente ti evita uno step che è quello di dover trascinare dentro il tuo progetto Webpack e metterci o fare una front-end app separata, come fanno in tantissimi, che è un pezzo però, secondo me, dei microservizi, oppure comunque tirar dentro il progetto webpack, configurarlo, tutto che adesso webpack è zero-conf, perché nelle ultime versioni hanno fatto tantissimi improvement di questo tipo, oppure anche Parcel, comunque hanno il loro grado di complessità.In questo modo tu ti tieni la tua toolchain e grosso modo non c'hai problemi e semplicemente ti descrivi le tue mutation, la tua interfaccia, col template backend, con degli handler che poi vengono eseguiti, in particolare su Phoenix, grazie alla piattaforma OTP che è una cosa potentissima, che mette Erlang a disposizione di chi vuole fare software stateful.Il problema è che questo, secondo me, per esempio, già se non hai la connessione a internet, diventa un problema.Nel senso, come disse Brian Cantril una volta, noi all'epoca di Google Maps ci siamo accorti che i nostri browser embeddavano un linguaggio di programmazione vero.e quindi l'abbiamo usato per fare delle applicazioni ricche.In questo modo invece dipendi da una connessione che non sempre c'è, ma banalmente il manager con l'iPad che sta sul treno e vuole fare data visualization della sua dashboard, mi immagino che a un certo punto con Live View ci avrà qualche problema di latenza.E siccome io ho lavorato a un tool che usavano i manager dal tablet in treno, questi problemi li conosco abbastanza bene e detto ciò, certo, se devi lanciare il tuo prototipo è fantastico.L'importante, secondo me, è sempre non abusare delle cose e soprattutto prendere delle scelte conci e delle motivazioni che ti portano a prendere quelle scelte cioè, perché stai usando LightView o qualsiasi altra cosa tipo Stimulus perché quello che voglio ottenere è questo, nel momento in cui cambia quello che vuoi ottenere devi cambiare anche gli attrezzi.Sì, ma dare soluzioni specifiche a problemi particolari è facile, sono bravi tutti.L'articolo invece parla esplicitamente del futuro del web software in generale, è così.Io mi riallaccio ai corsi e ricorsi storici con la tua metafora su Dungeons & Dragons, sui giochi di ruolo in generale.Quando tu hai il tuo guerriero forte ormai raggiunto livelli epici e quant'altro, ti rendi conto che l'ascia un po' ti stufa e che cosa fai? Lo fai morire, riparti da zero, ti fai il tuo bel maghetto che incanta dapprima i piccoli topi e poi lo fai crescere.Così succede anche nel software, nelle architetture, nei pattern e quant'altro.Si cerca sempre, si segue la moda del momento e si crede che sia la soluzione a tutti i problemi, tutti, proprio in generale, salvo poi stufarsi dei problemi che la stessa soluzione crea e poi, che cosa succede? Si ritorna da capo e si ricomincia a usare quel vecchio pattern abbandonato, che avevamo abbandonato e si ricomincia da zero, però magari i tempi sono cambiati e quindi adesso è meglio e quindi non chiamatelo alla vecchia maniera perché siamo più forti e siamo più innovativi.Appunto, corsi e ricorsi storici.Bicchiani.Ed ecco perché siamo anche così affezionati al monolighe, è difficile che ce ne stacchiamo, perché ci riporta un po' alle basi, dove tutto è più semplice, tutto è più sotto controllo, eccetera eccetera.Però sposa pieno il discorso che faceva Alessio, sempre riguardo a questo, dove secondo me bisogna...abbiamo iniziato il discorso dicendo, mettendo un cartellone enorme che ho scritto "dipende" sopra.Continuo a ribadirlo perché dipende fortemente anche dal proprio team.Cioè, se siamo in quattro persone a lavorare su un prodotto, è normale che la singola codebase ci sta benissimo, ma se siamo in 300 allora iniziare a spacchettare i pezzi del prodotto in tanti pezzi con ognuno la sua migliore tecnologia sicuramente potrebbe essere la strada migliore perché da una parte siamo noi che ce la cantiamo e ce la suoniamo, è inutile che adesso mi scrivo il micro servizio, adesso mi scrivo l'altro servizio, adesso mi scrivo il front end e mi faccio parlare tutte e tre le cose, tutte e tre dockerizzate in locale per farmele parlare eccetera eccetera e poi io stesso so che le deployo.Invece quando invece si hanno tanti team con un pezzo di prodotto dedicato, allora sì che potrebbe essere vincente, qualunque sia l'anatole Cogia.Mi hai rubato il bold statement che volevo fare io, nel senso che io ho fatto la domanda a Monolite Microservizi ma non ho risposto io, perché la mia risposta è che la scelta tra Monolite e Microservizi è proprio che quella non è una scelta tecnologica, è una scelta legata all'organizzazione, è una scelta legata appunto a quello che tu se tu hai un team da 3, 4, 5 persone non ha nessun senso spacchettare un sistema in 20 microservizi.Se hai un team da 300 in cui magari i contesti, i sottotimi sono un po' meglio definiti, invece non ha senso farli lavorare tutti su una codebase unica e farli impazzire per emerge.Per cui, secondo me, la scelta architetturale tra monolitio e microservizio è una scelta che dipende moltissimo da come è fatta l'organizzazione.E questa cosa, tra l'altro, è un bellissimo gancio, non intenzionale, ma è un bellissimo gancio per andare al prossimo articolo.Che è un articolo che si intitola "10 leggi sul software engineering che a tutti piace ignorare".E la prima di queste è proprio la legge di Conway che dice che ogni organizzazione che disegna, che progetta un sistema, produrrà un design la cui struttura è una copia dell'organigramma aziendale, della struttura di comunicazione aziendale.Che se vuoi è un po' la stessa cosa che ci siamo appena detti rispetto a monoliti unico servizi.In questo articolo ci sono alcune leggi molto interessanti, alcune sono super famose, c'è la legge di Brooks, di Dmitri Kolman-Month, che dice che aggiungere persone a un progetto software in ritardo lo rende più in ritardo.Nel libro, che è un libro storico di project management, questa cosa è descritta anche come "9 donne non fanno un bambino in un mese".LM: "Un mese".LM: è come quando si ha un sacco di bisogno di manotopera, quindi ci riempiamo il team di junior.È proprio la cosa che dici "allora adesso andiamo una spada, andiamo velocissimi" e invece non fai altro che rallentarti perché ovviamente l'onboarding di un junior porta le sue conseguenze.un grande investimento da fare nel team, sulla persona specifica, però prima che diventi operativo e capisca tutti i flussi eccetera eccetera, che entra nei ranghi, tra virgolette, vuole il suo tempo, quindi legge giustissima che approvo.- Anche perché aggiungere persone aumenta anche l'entropia, che è un concetto di cui abbiamo parlato prima, e aumenta anche la necessità di comunicazione.Mi ricordo che In The Mythical Man-Month c'è un diagramma molto bello in cui è fondamentalmente un grafo in cui i nodi sono le persone e tutti devono comunicare con tutti.E se tu aggiungi un nodo al grafo, ovviamente i lati di questo grafo aumentano esponenzialmente.Hai aggiunto un milione di archi, certo.Esatto.E aumentano esponenzialmente all'aumentare dei nodi del grafo.per cui quando tu hai un graffo con tanti nodi, aggiungerne uno aggiunge un numero di archi molto molto grande, potenzialmente, e questo aggiunge un sacco di entropia.[Gabriele]: Sì, secondo me sono cose giuste che condivido, però insomma, ritornando a quella cosa sui microservizi, secondo me i microservizi, è giusto partire con il monolite, e sono d'accordo, specialmente se si è pochi, specialmente se magari il dominio non è ben definito, altrimenti ti ritrovesti a dover ingegnerizzare cose che non hanno senso.Secondo me però i microservizi sono anche un'ottima occasione per fare refactoring, di avere anche la consapevolezza del refactoring.Ad esempio io mi sono ritrovato a lavorare su un monolith che aveva i suoi anni, che era diventato enorme, e ci siamo resi conto che la tecnologia con cui era fatto quel monolite non era adatta per fare alcune delle task che noi facevamo di giorno.Quindi stavamo sostanzialmente avvitando una vite con un martello.Il fatto di aver diviso i microservizi, di essersi preso il tempo per fare questa cosa qui, ma con questa cosa qui è stata anche un'occasione per ritrovare tantissima consapevolezza che non ci serveva.Perché abbiamo dovuto riflettere su scelte già fatte e abbiamo capito che per non uscire dalla comfort zone eravamo imposti dei limiti che erano falsi alla fine.E quindi il fatto di averlo splittato in un microservizio diverso che poi anche qui si potrà andare nella domanda "Allora, ma quanto deve essere grande questo microservizio per essere veramente micro?" e per cui si comincia a discutere due ore e vince chi ha il microservizio più piccolo, in questo caso, non vince chi ce l'ha più grosso.E secondo me sono un'ottima occasione per fare factoring.Quindi sì, dipende anche tanto dal team, dalla dimensione del team, ma secondo me i microservizi si rendono necessari anche quando il team è piccolo ma il dominio diventa così grande che c'è la necessità di ritornare a riflettere anche sulle scelte passate.Certo, poi ci sono ovviamente la contro...diciamo la contro...argomentazione, ma allora GitLab, ma allora Basecamp? e vabbè, nel senso, lì non so nemmeno rispondere, però quello che posso dire è che GitHub è scritto in un modo che è diverso dal 99% delle applicazioni Rails scritte in questo mondo, quindi sostanzialmente ci si può mettere mano e sono moduli che sono comunque staccati e permettono il fatto che ci lavorino più persone.Quindi anche il non averlo diviso in un servizio a parte, ma averlo reso così immodulare da essere de facto un servizio a parte, può essere la stessa cosa.Io ti rispondo a questa cosa con un altro principio, a parte che apprezzo tantissimo la battuta "Git l'abbia scritto in maniera diversa da tutte le altre applicazioni Rails e infatti ci si può mettere mano", cioè veramente mai ucciso, perché da ex programmatore tra l'altro io ho anche un passato piuttosto oscuro, un annetto passato a fare queste cose, quindi I can relate, come si dice.Ti rispondo con un altro di questi principi, legato a quello che abbiamo detto prima, che il 99% di tutto il software è crude.Che significa crude? Significa create, read, update, delete, e è il pattern di accesso, modifica, eccetera, di scrittura applicazioni e data management, diciamo, più diffuso.Semplicemente gira tutto intorno al modello e semplicemente noi andiamo a creare, leggere, aggiornare e cancellare quei record dentro il database.Questo è quello che fanno tutte le applicazioni della Terra, a parte chiaramente i servizi delle scale up tipo GitHub, visto che abbiamo citato e continuiamo a citare GitHub, che ormai è diventato il nostro riferimento preferito.Io sono d'accordo.Riguardo monolite e microservizi, ancora di più, il punto è Quando tu parti, esattamente come il tuo guerriero ci avrà sempre quei valori di forza e destrezza, il tuo servizio sarà necessariamente un crude, la tua applicazione.Poi dopo un po' ti verranno in mente delle esigenze che puoi staccare e quello là diventerà magari un servizio a parte, eccetera, eccetera.Passo al prossimo che vuole commentare qualche principio.Ok, in realtà di queste dieci leggi del software engineering che a tutti piace ignorare, la mia preferita è l'undicesima, perché c'è un trick, sono dieci.L'undicesima dice che se vuoi rilasciare in fretta una modifica alle 10 lighe, basta nasconderla in una pull request da 1500.Mi fa molto ridere perché...Perché è azzurra.A parte perché è vera...È un bel trick.È un bel trick.Ma poi perché il mio primo approccio con Gitbar è stata una puntata in cui si parlava proprio di code review e mi ricordo, perché è una cosa che dico spesso, che quello che devi evitare in tutti i modi, se vuoi fare bene le code review, è evitare che mandi una pull request così grossa che il tizio ti dice "sì, vabbè, dai, facciamo che va bene" e te la prova, che è esattamente questo.Quindi è una cosa che ho visto succedere troppo spesso e di cui tra l'altro oggi è martedì, quindi martedì confessioni mi sono macchiato anch'io.Vedi il martedì confessioni funziona.Martedì confessioni che per chi non lo sapesse è una feature bellissima del gruppo Telegram di Gitbar.La legge al quale sono particolarmente legato perché mi ricorda proprio la mia prima settimana di lavoro, il principio di Pareto, cioè che quando hai finito l'80% pensi che ti sia rimasto solo il 20%, ma invece quel 20% ti richiederà l'80% del tuo tempo.Questo l'ho proprio visto le prime due settimane di lavoro, nel mio primo lavoro vero, quando venivo pagato per farlo, e quindi non ero più ammatoriale il ragazzino che faceva le cose da casa e si faceva abbastare quell'80%, al lavoro dovevo finire quel 20%, a un certo punto non ce la facevo più e ho chiesto al mio capo se fosse normale che quel 20% fosse proprio una grande rottura di cazzo.Scusate il francesismo.E lui mi ha risposto "Welcome to Barreto".Praticamente è stato questo.Mentre invece, e quindi quando la leggo mi mi scende una lacrimuccia perché ormai si parla quasi di 15 anni fa.A me succede ancora oggi, tra l'altro, nonostante io sia un senior bla bla bla, ma è tuttora così.Certo, però all'epoca mi era stata una rivoluzione, quantomeno codificare questo mio stato di animo davanti al computer.Mentre invece, una cosa che riguarda il presente è che in una gerarchia, il principio di Peter, una gerarchia ogni dipendente tende a raggiungere il proprio livello di incompetenza.Spero che la mia incompetenza mi porti più in alto, siccome sono stato da poco promosso, questa mi commuove e mi tocca proprio da vicino.Di quello tra l'altro c'è un corollario bellissimo che l'articolo non cita, che è il principio di Gilbert, che dice che la leadership, quindi le promozioni, sono il meccanismo che la natura sia inventata per rimuovere gli idioti dal flusso produttivo.Salutiamo tutti i leader e i manager a cui conico e vediamo bene.Questo lo dice Scott Adams dentro di Alberto Noivi.Forse ci dissociamo.LM: "Vado io.C'era una che a me ha colpito, però prima volevo spendere un'altra parola su quella di Luca che a mio avviso, secondo me, dare le specifiche e i tempi sulle specifiche è una di quelle cose più complicate che ci sia.Quindi già riuscire a dire "sto all'80% di questa tempistica è ancora più difficile.Quindi tanto di cappello a chi ci riesce e ce la può fare.Invece io volevo parlare della legge di Eagleson, sulla quale mi ha colpito e mi ci rivedo molto, che indica che quando si va a riguardare un pezzo di codice stimato su Perciudo dopo sei mesi potrebbe essere stato scritto anche da qualcun altro.Quindi il primo acchitto è "ma chi ha scritto sta merda?" e sei sempre stato tu.Non sono nemmeno passati sei mesi magari.Una settimana.A me succede col codice che ho scritto stamattina.Sì, infatti.La cosa bella è che questa legge porta con sé un corollario, che è quello di Umoma, che dice che l'autore può criticare il codice, invece tutti gli altri feedback negativi devono essere ignorati.Se il feedback negativo è anch'esso costruttivo, non sono molto dell'avviso che debba essere così tanto ignorato.Però diciamo, sposando la causa blameless in questo direi che non ci siamo, quindi sempre avere punti di vista costruttivi, però quando dentro di te dici "sto pezzo di codice fa davvero schifo" e poi sei stato tu a scriverlo, è una delle sensazioni più belle che possiamo vivere nel sviluppatore.Il problema è la combo, nel senso che quando fai sto lavoro per davvero il codice attraversa sempre il percorso dei code review, quindi a volte uno prende il codice in mano e dice chi l'ha scritta sta bestialità e poi vai a fare il git blame e scopri o che l'hai scritta te, che è quello classico, oppure che l'ha scritta magari Mattia o Andrea e poi dici "ma chi ha fatto il review di questa cosa?", vai a chiedere ai reviewer, solo che la VR era delle 1500 righe e quelle sono le 10 righe che il reviewer non ha letto, sono le uniche dieci righe infami e a me è successo tipo due settimane fa, cioè è una storia di vita vissuta e succede sistematicamente.>> MICKA: Però a volte può anche succedere il contrario, Daede, è ugualmente bello.Cioè vedi una bestialità che potresti benissimo aver scritto tu qualche sera prima e tremante fai un git blame e scopri che non sei stato tu e che eri anche in ferie quel giorno e dici "oh, questo è bello!" Queste sono le più grandi soddisfazioni.E ti senti un po' meno solo.Esatto.No, questa cosa qui è bella anche con la combo del "per programmi", quindi magari state scrivendo in due una cosa e da un certo punto tu pensi "ah guarda che bella monnezza che sto scrivendo".Magari quello che sta facendo per programmi ti fa fa proprio schifo sta monnezza, però sulle 7 meno un quarto, vai, scriviamo lo stesso, quindi nel senso quella è ancora di più una soddisfazione, ritrovarsi non soli anche con la consapevolezza di star scrivendo monnezza.Insomma, verso quest'ora diamo sempre cattivi esempi, non vorrei dire, anche l'altra volta.Speriamo che gli ascoltatori abbiano mandato "Vi conduco nel paese dei balocchi!" "Ah, il paese dei balocchi!" Visto che si è fatta una certa, è il momento che gli ascoltatori di Dicquart graziano più di tutti e di cui siamo più affezionati, che è il momento del Paese dei Balocchi.Quindi facciamo un giro di balocchi della settimana, partendo da Andrea, che so che ha un balocco molto bello.Ecco il mio balocco.Il mio balocco è bellissimo, è una conferenza italiana, tutta gratuita, organizzata dal Grusp, dove partecipano tutti i pug italiani.Per chi non lo sapesse, i pug sono i PHP user group locali, ce ne sono sparsi per tutta Italia.Hanno organizzato questo evento è dedicato appunto ai Pug, dove tutti i membri di questi user group potevano mandare la propria proposal.Ci sarà il 18 marzo online, ovviamente, nelle note dell'episodio troverete il link per chi fosse interessato ad iscriversi.Ci saranno 7 track orientate ovviamente al PHP, ma ci sarà anche uno, come posso dire, non mi viene il termine, diciamo, ispirazionale, sensazionale, personale, dove si parlerà della classica sindrome dell'impostore, la fiducia in se stesse, motivazione, eccetera, eccetera.Questo è quanto.Vado io? Vai! Io non avevo un ballocco fino a 5 minuti fa, dopodiché ho detto, visto che io ho il feed reader che mi sputa elementi a macchina, io in realtà lo guardo molto, io uso ancora il feed reader per leggere un sacco di blog, questa settimana, il 7 marzo, per la precisione, di Majors che in due la conosceranno, nel senso che è CTO di una società che si chiama Oneicom, che è una società che fa observabili e lei è una software engineer, diciamo, di grande esperienza, che ha esperienza sia nel development che nell'operations, scusate e pubblica sempre un fracco di roba interessante.Quindi io vi lascio due balocchi.Il suo blog, che è charity.wtf, e in particolare l'ultimo articolo che ha pubblicato, che è "Know your one job and do it first", che tratta della fatica che facciamo noi developer a districarci tra il fare il lavoro per il quale siamo stati "assunti", ovvero scrivere un'applicazione di un certo tipo, e tutto il resto, perché in realtà la vita del developer è anche scrivere, che ne so, della documentazione per un progetto che la compagnia reputa cubare solo il 20% dell'effort che tu magari hai a disposizione.sfruttabile.Quindi in realtà noi abbiamo tutti questi problemi di allocazione personale del tempo perché noi dobbiamo scegliere la mattina che cosa fare, quanto tempo dedicare alle review, alla scrittura del codice, alla scrittura di documentazione, a tutte le interazioni su Slack, banalmente c'è un team che ha difficoltà e io posso facilitargli la vita.Se io non sono un "Devo farlo?" l'articolo di Charity parla proprio di questo.Quindi ve lo lascio nelle note dell'episodio.Io mi collo qua e passo a Carmine.Allora, io per la puntata di oggi ho due balocchi reali e un consiglio, come ho dato anche l'altra volta, che mi sembra sono sempre i balocchi quelli più belli.Il primo balocco reale è qualche cosa che non dico che mi ha cambiato la vita perché poi lì si entra nel mistico, però ha dato davvero un boost alla mia produttività che è un KVM switch.Un KVM switch non è nient'altro che un attrezzo, una parecchiatura che ti permette di controllare più computer utilizzando lo stesso set di periferiche, monitor, insomma alla fine potete avere due computer che sono collegate allo stesso monitor, la stessa tastiera e allo stesso mouse e potete switchare, ecco perché si chiama switch, una spiegazione bruttissima, potete switchare da un computer all'altro.Questa cosa qui in un setup dove io adesso sto lavorando con un Mac ma ho anche un altro computer Linux, mi aiuta a switchare tra entrambi i computer e a combattere anche quella resistenza che ho magari nel non spegnere il mio computer principale, accendere un altro collegarlo, quindi magari utilizzo lo strumento più costano per fare una determinata cosa.Un altro balocco, questa volta è virtuale, per tutti quelli che magari si stanno avvicinando al mondo del front-end o di JavaScript in generale, o magari perché si vuole fare anche una bella ripassata, invito a comprare, perché si compra, oppure gratis, per i primi 6 mesi, se avete il GitHub Student Pack, sono i corsi di front-end masters, che sono sostanzialmente, secondo me, e credo non solo secondo me, la piattaforma più valida per imparare JavaScript o per approfondire tutti i temi del frontend.Hanno diverse path, quella beginner, quella intermediate e da advanced e quindi è adatto sia per chi comincia sia per chi vuole ripassare.E perché dico frontend masters? perché solo su Frontend Masters si trovano i corsi di Kyle Simpson, che è l'autore di "You Don't Know JS".E praticamente c'è la versione del libro, che è un bellissimo libro e vi invito anche a questo punto ad acquistarlo piuttosto che a scaricare direttamente la copia libera.Ci sono, sostanzialmente c'è il libro come corso, lui è bravissimo.Io ho utilizzato Frontend Masters di recente, un annetto fa ho ricominciato e ho seguito il corso su Vue e su come funziona oggi internal di Vue che è stato fatto dallo stesso creatore di Vue.Quindi sostanzialmente non c'è nessun altro posto dove imparare Vue bene se non quello lì, insomma, almeno secondo me.Il terzo balocco è un consiglio ed è un consiglio che può sembrare banale però spesso, vista anche la nostra professione, specialmente in questo tempo ci porta ad essere magari un po' più distanti dagli altri, dai nostri colleghi, se vi sentite sovraffatti, se avete ansia, se avete paura, se avete perplessità sul vostro lavoro o meno, parlatene con qualcuno, non avete paura di parlare.io stesso ci sono passato, io ho visto anche tantissimi colleghi che si sono tenuti dentro tantissime cose e sono andati in burnout in men che non si dica.Vi dico, parlate, sono tempi difficili per tutti e fare un lavoro che ti porta ad essere isolato la maggior parte del tempo può essere veramente logorante.Parlatene.In Italia spesso è un tabù parlare di salute mentale, di ansia, perché si pensa sempre al pazzo che sta in chiusura nel manicomio.Una cosa assolutamente normale che specialmente di questi tempi può capitare a tutti quanti.Parlatene col vostro capo, col vostro collega, con il vostro cane, il prete, l'imam o quello che volete, ma parlatene con qualcuno.Io sto facendo cuori giganti con le mani perché non avrei saputo dirlo meglio.Anzi, uno dei miei balocchi era proprio un post del blog di Calm, che è un'applicazione molto molto ben fatta.Ha vinto, credo nel 2019 o nel 2018, comunque di recente, l'award di Apple come migliore applicazione dell'application ed è un'applicazione che tratta appunto il tema della salute mentale, nota come applicazione di meditazione, ma poi si è un po' espansa su tutto il tema della salute mentale.Il post del blog si chiama proprio "Feeling ok about not feeling ok at work" e dice esattamente quello che hai detto tu, nel senso che dici che in generale, in questo momento storico in particolare, ma in generale è perfettamente normale avere ansia, avere paura, non sentirsi ok.Ed è una cosa su cui in effetti spesso c'è dello stigma.E magari in tanti io per primo ci sentiamo frenati a parlarne.E invece è un tema che soprattutto in questo momento ci tocca a tutti.Mi è capitato di recente, io ho un gruppo WhatsApp di ex colleghi, con cui sono rimasto in contatto perché sono amici, A un certo punto, uno di loro ha mandato un messaggio dicendo "Raga, ma solo io o state impaziendo anche voi in questo periodo?" Ed è stato un momento veramente illuminante, nel senso che in questo momento tutti siamo in difficoltà di nuovo.Per gli ascoltatori del futuro siamo nel mezzo di una pandemia e è un momento difficile per mille modi e per mille motivi diversi.ed è perfettamente ok non sentirsi ok.Ed è estremamente utile parlarne, come ha detto giustissimamente Carmine.Un po' perché ci aiuta a sentirci meno soli, che è un tema di cui abbiamo parlato anche prima, e un po' perché ci aiuta...già solo parlarne, lo so, per esperienza toglie un sacco di peso.Oltre a questo ho anche un balocco, diciamo, fisico, che anche qui arriva dal gruppo di Telegram, nello specifico da Carmine, che me l'ha consigliato, quindi grazie.È un libro che si chiama "A philosophy of software design", che, vi confesso, non ho ancora letto, ma ho sfogliato con molta attenzione e mi sembra davvero interessante, nel senso che parla proprio di questioni filosofiche nell'ambito del software design.Per esempio un capitolo è intitolato "Designing things twice", che è una cosa di cui abbiamo parlato prima, nel senso che tratta del fatto che la prima volta che disegni un sistema probabilmente hai una serie di bias e di cose che non conosci, che poi quando lo ridisegni a quel punto sai e conosci meglio il dominio e quindi sai disegnare meglio quello che devi.Mi aspetto grandi cose da questo libro e ve lo consiglio a priori.Io volevo dire una cosa, ritornando un attimo anche al discorso dei problemi al lavoro.Recentemente ho fatto un corso, un seminario, un webinar proprio sul remote working.è una cosa che hanno detto, soprattutto che hanno consigliato a chi ha ruoli di responsabilità è quella di prevedere un periodo, un'ora a settimana, in alcune aziende fanno ma può essere di meno, in cui il responsabile parla con i propri collaboratori dipendenti di tutto ciò che non è lavoro, quindi fanno proprio una chiacchierata proprio per sondare come si sente se hanno bisogno di qualcosa, da più ore a svagarsi o a lavorare anche magari in modo diverso.E questo in alcune aziende è proprio strutturato, ogni settimana c'è un'ora per parlare.detto questo il mio balocco, anzi sono due piccoli balocchi il primo è Gitty, che l'ho trovato quando cercavo un'alternativa a GitLab è praticamente un mini GitLab, molto molto molto leggero, può girare su un Raspberry è un servizio on premise per Git per gestire i piccoli progetti senza grosse pretese, però fa il suo ed è scritto in Go e molto veloce.Il secondo è un video che mi è venuto in mente parlando dell'open source e del perché per come l'open source è un po' una nicchia per noi sviluppatori.È un video di Salvatore Sanfilippo, un TED, che si chiama "L'open source è un fiume in piena", racconta la sua interessantissima storia, tra l'altro, però spiega anche un po' che cos'è l'open source.parla di redis al caso parla un po' di redis, però non tanto però...no niente, spiega anche in parole semplici cosa potrebbe essere, cos'è l'open source e come può servire sostanzialmente al mondo e basta così Ottimo! A questo punto credo che ci rimangano solo i saluti, se non vado errato.Sì, si è fatta una certa.Come era, abbiamo portato a casa il minutaggio, no? Sì, esatto, abbiamo portato a casa il minutaggio anche per oggi.Speriamo che questa puntata vi sia piaciuta, non sono temi semplici di cui abbiamo parlato, a parte che siamo tecnici o meno, quindi è stata una puntata con il nostro flusso di coscienza sulle varie cose che abbiamo parlato, spero e speriamo che vi sia piaciuto, io vi saluto e vi aspetto alla prossima puntata di BitBar.anche qua.Ciao! Io volevo aggiungere un'ultima cosa che sono 37 minuti che non parliamo del canale Telegram di Gitbar quindi volevo salutarvi così con Telegram e Gitbar.Ciao! Ciao anche da parte mia e quindi a questo punto anche un saluto al canale Telegram.Gruppo Telegram, ciao a tutti! Alla prossima! Gruppo Telegram! Telegram, gruppo, Bremen e Barra.Ma come si fa per entrare? Si cerca su Telegram Gitbar.Si cerca su Gitbar Telegram? No, si cerca su Telegram Gitbar.No, ma anche andando sul sito gitbar.it ci sta il link a Telegram.Mi pare funzioni così, no? Se lo cerco su Google? Non lo so, proviamo.Ma sicuramente uscirà.Se cerchi Beat Bar Telegram, scegli il gruppo Telegram.Insomma, non avete scuse.Dak Dak Vu.Senza mai dimenticare le possibili recensioni da fare sul podcast per chi ha iPhone oppure Android oppure su Play Store, Spotify eccetera eccetera.Lascia il tuo commento, è la tua stellina.Più convincente, Andrea, più convincente.Per i prossimi 100 utenti che entrano nel gruppo Telegram, in omaggio...niente.A questo punto dovremmo fare un sospiro infinito tutti quanti e poi dire tutti insieme "bene e benvenuti su Gitbar".Questa non l'avamo provata, dobbiamo provarla meglio.va bene saluto a tutti ciao a tutti 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 degli strumenti mancabili nella cassetta delle attrezzi dei full stack dev [Musica]
