Torna a tutti gli episodi
Ep.66 - Project management tools - Ammutinati 🏴‍☠️

Episodio 66

Ep.66 - Project management tools - Ammutinati 🏴‍☠️

Ogni giorno li usiamo, li amiamo, li odiamo, li proponiamo, li subiamo... ma sono davvero importanti per gli sviluppatori e non? Quali sono i loro pro e contro? Come sceglierne uno? Quali problemi risolviamo utilizzandoli? Stiamo parlando di strumenti di Project Management per facilitare l'allineame...

25 marzo 202101:19:40
AIMusic
66

In Riproduzione

Ep.66 - Project management tools - Ammutinati 🏴‍☠️

0:000:00

Note dell'Episodio

Ogni giorno li usiamo, li amiamo, li odiamo, li proponiamo, li subiamo... ma sono davvero importanti per gli sviluppatori e non? Quali sono i loro pro e contro? Come sceglierne uno? Quali problemi risolviamo utilizzandoli? Stiamo parlando di strumenti di Project Management per facilitare l'allineamento continuo tra programmatori e stakeholders. A seguire a grande richiesta torna una nuova sfida di GitBar Passaparola™ e per concludere gli immancabili balocchi.Buon ascolto!## Ricordati di iscriverti al gruppo telegram:https://t.me/gitbar## Supportaci suhttps://www.buymeacoffee.com/gitbar## Link:The Basic Laws of Human Stupidity di Carlo M. Cipollahttps://www.amazon.it/basic-laws-human-stupidity/dp/8815233814Clean Agile di Robert C. Martinhttps://www.amazon.it/Clean-Agile-Robert-C-Martin/dp/0135781868Agile Estimating and Planning di Mike Cohnhttps://www.mountaingoatsoftware.com/books/agile-estimating-and-planningLa Stanza Intelligente di David Weinbergerhttps://www.amazon.it/stanza-intelligente-conoscenza-proprietà-della/dp/8875783160Cookie Consent Speed Runhttps://cookieconsentspeed.run/Polacode - Polaroid for your Codehttps://github.com/octref/polacodeLol Commitshttps://github.com/lolcommits/lolcommitsTastiera Meccanica Keychron K3https://www.keychron.com/pages/keychron-k3-wireless-mechanical-keyboardIl blog di Joe Armstronghttps://joearms.github.io/#IndexScheda Audio esterna per persone povere e con poco gusto musicalehttps://www.amazon.it/UGREEN-Esterna-Adattatore-Microfono-Compatibile/dp/B01N905VOY/Kiwi TCMShttps://kiwitcms.org/The Hacker Newsletterhttps://hackernewsletter.com/Extreme Programming Explainedhttps://www.amazon.it/gp/product/B00N1ZN6C0## Contatti@brainrepo su twitter o via mail a info@gitbar.it.## CreditiLe sigle sono state prodotte da MondoComputazionaleLe musiche da Blan Kytt - RSPNSweet Lullaby by Agnese ValmaggiaMonkeys Spinning Monkeys by Kevin MacLeod

Descrizione

BrainRepo sta scappando, ha bruciato le corde con l'alimentatore del 286! Gli ammutinati - Alessio, Andrea, Carmine, Leonardo, Luca e Mattia - parlano di tool di project management. Da Redmine (l'opinione impopolare di Carmine) a Jira (che tutti hanno usato e tutti odiano), da Trello per gli stakeholder non tecnici a GitLab per chi vive di codice. Parliamo di stime impossibili, fibonacci per pesare le issue, e del perché Teams è un inferno rispetto a Slack. Con quiz Passaparola incluso.

Takeaway

  • Redmine è customizzabile all'infinito: Può essere issue tracker, CRM, ticketing system, qualunque cosa. Ma la curva di apprendimento è ripida e serve un consulente per configurarlo bene
  • Jira è brutto ma familiare: La UX non è bella, ma tutti l'hanno usato almeno una volta. La familiarità batte la bellezza quando cambi team
  • Stakeholder non tecnici = tool semplici: Trello, Notion, email. Non puoi dare GitLab a chi usa solo Excel. Il tool giusto dipende da chi lo usa
  • Stimare è l'unico vero problema del nostro lavoro: Fibonacci per le issue weight funziona perché perdi il margine preciso. Una issue da 3 o 5 chili è "circa un giorno"
  • Il diritto all'offline nei tool: Poter decidere selettivamente di che cosa essere notificato è fondamentale, specialmente nel remote working con timezone diverse

Bold Opinion

  • Il tool non risolve il problema. Prima capisci qual è il problema del team, poi scegli il tool. Non viceversa
  • Non puoi partire senza un flusso di lavoro. "Mi adatto al tool" è un errore, il tool si deve adattare al team (o si customizza o si cambia)
  • Teams vs Slack non è una scelta, è violenza. Chi propone Teams come sostituto di Slack non ha capito niente di developer experience
  • Le suite "integrate" (Google, Microsoft) sono il male. Più un tool è generalista, più fa male a qualunque figura specializzata

Trascrizione

Bene e benvenuti su github attenzione attenzione sta scappando prendetelo sta liberando sta liberando sta scappando sta scappando blocchiamolo blocchiamolo è lì è lì si sta aggrappando a quel pisce ha bruciato le corde con l'alimentatore del 286 muahahahah vi beccate gli ammutinati anche questa settimana maledetti maledetti Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene e benvenuti su Gitbar...vedo già facce che ridono eh, non si fa così ragazzi! Bene e benvenuti! Bene e benvenuti su Gitbar! - Una nuova puntata del podcast italiano con più righe di codice del back end di Facebook.Io stasera sarò il vostro moderatore, il Giovanni Floris del software italiano per così dire e sono Alessio Biancalana e passo subito la parola a chissà dopo di me.- Dopo di te c'è Andrea, perché non lo conoscesse si chiama Andrea.E dopo Andrea c'è Carmine che è un umile bracciante del software.Poi c'è Leonardo che è di Firenze.Poi Luca, italiano.E poi c'è Mattia che una volta da Alessio è stato definito il Tiberio Timperi del software italiano, comunque oggi sono in buona compagnia.Grandi nomoni, assolutamente un complimento.Stasera vai subito per la Susi.Per iniziare non c'entra nulla perché ci rimuocino da un po' di tempo, ma da dove viene "bene e benvenuti"? Io ho una mia teoria però volevo sentire prima la vostra.Io non ne ho idea, nel senso che "bene e benvenuti" per me viene dalle puntate precedenti, precedenti, nel senso che lo diceva sempre Mauro e in seguito poi è diventato famoso per il meme che io ho postato sul gruppo di telegram con il Gabiano.Aspetta, stai forse dicendo che abbiamo un gruppo telegram? Abbiamo assolutamente un gruppo telegram.LM: "questo non lo diciamo mai, però lo diciamo, lo diciamo, lo chiamiamo gruppo Telegram." FB: "anche a scuola non stata al contrario si sente il gruppo Telegram." LM: "sì, sì, secondo me viene un po' dal bar, cioè nel senso bene e benvenuti, nel senso entra una nuova persona nel bar e dici "bene, ben arrivato, eccoti la tua birra", capito?" FB: "questo è quello che facciamo noi sempre, però spero che sia così anche la radice della cosa." credo che venga da francese comunque, il bien è benvenuto credo che i francesi questo bien lo mettono un po' dappertutto quindi forse l'ha rubato da lì tipo "dai" c'era una scenetta dello Zoddi 105 dove il personaggio diciamo si introduceva con "bene" e "benvenuti" non lo so, poi chiederemo dopo quando scendiamo giù in catena e storciamo la risposta.Comunque Alessio non ti volevo interrompere anche se l'ho fatto Tra l'altro ricordiamo che bene benvenuti come chi frequenta il gruppo Telegram sa con assoluta certezza si dice si scrive con la b rossa.Esatto, assolutamente e tra l'altro ricordiamo anche visto che Leonardo l'ha detto che poi dobbiamo andare anche a controllare lo stato di salute di Mauro Giucantina perché insomma ecco esatto e portargli una birra perché pure è l'unico modo che ha di ottenere diciamo integrare dei sali minerali.Se sono arrivate delle donazioni di birra, allora gliela possiamo portare, altrimenti il poraccio...Perfetto, questo è bravo.Hai detto una cosa ottima, questo è un ottimo modo per tenere in vita Mauro.Mandateci delle donazioni, perché servono appunto a tenere in vita il podcast e a tenere in vita anche Mauro Nulloscantinato, perché voglio di quello quando gli elevi il bavaglio, magna.Abbiamo quasi finito i libri di Zimuel, quindi effettivamente non sappiamo più nemmeno che fargli leggere.Allora, questa sera fuor di Ciancia parliamo di una cosa molto bella su cui raramente in realtà gli sviluppatori hanno voce in capitolo, almeno nelle realtà lavorative che ho frequentato io, perché c'è sempre un po' questo mito dell'approccio integrato, di cui credo che discuteremo anche tra poco.Stasera parliamo di tool di gestione progetto, quindi, vabbè, chiaramente l'elefante nella stanza gira e chiaramente tutto l'ecosistema di software che ci girano intorno, l'avete capito? Io mi sono immaginato l'elefante nella stanza che gira, proprio che si guarda.Sì, esatto.Conscritto sulla fiancata PHP ovviamente.Esatto.Certo, assolutamente.In realtà io so che, appunto, diciamo che la cosa fondamentale, il tema principale è qual è il software di project management che utilizzate, qual è perché vi piace, perché non vi piace e se ne preferite scusare altri e da là poi diciamo che facciamo rotolare la palla e qualcosa succederà.In particolare io passo la parola a Carmine perché so che ha un'opinione piuttosto impopolare su questo e lui è sorto proprio a mandarla così fuori.Allora, secondo me...il Roberto Saviano del project management è Redmine perché è veramente...scherzo a parte io ho utilizzato diversi tool per fare project management e ho un'opinione impopolare credo che per la gestione del progetto ad alto livello, che poi ci arrivo dopo cosa intendo per l'alto livello, sia il top Redmine, perché veramente è super customizzabile, super leggero, personalizzabile, c'ha una community impressionante e poi nel senso, dai, è fatto in Rails, no? Quindi nel senso, se non vuoi utilizzare Basecamp, l'unica alternativa, credo sia Redmine.Che cos'è Redmine? Redmine può essere qualunque, può può essere qualunque cosa.Diciamo che al suo core è un issue tracker, ok? Quindi diciamo che senza nessuna customizzazione è un issue tracker.Ha il concetto di tracker che è semplicemente la categoria dell'entità che stai mettendo.Quindi può essere un task, può essere una user story, può essere un epic, può essere un bug, può essere una change request, può essere qualunque cosa.E credo che questo essere qualunque cosa sia la vera potenza di Redmine, perché può essere adattato a qualunque cosa.E questo che sono però, diciamo, per la gestione ad alto livello del progetto.E cosa intendo per la gestione ad alto livello? Intendo una gestione che non coinvolga attivamente il codice.Ok, quindi diciamo non userei Redmine per tracciare issue sul codice, per collegare commit, per collegare branch o fare diciamo un'integrazione con la parte di sviluppo software vero e proprio perché credo che su quella parte abbia effettivamente delle grosse mancanze.noi in azienda utilizziamo Redmine per questa parte di gestione dei progetti e poi Bitbucket per tutta la parte proprio di gestione del codice, delle issue sul codice, delle pull request, pipeline eccetera eccetera eccetera.Quindi diciamo...Parola provocazione.Sì? Ti piace la sua user interface? Io sono un feticista della UI vecchia.Io ho un tema di KDE che è ispirato a Windows 3.1, tipo una cosa del genere.Quindi ci vado assolutamente a nozze con quella cosa.Mi spiego molte cose allora.No no, allora, secondo me ha una UI brutta, nel senso se mettiamo a confronto la UI di Redmine con la UI di Jira, che è comunque brutta, ovviamente Jira vince a mani bassissime.Quindi, diciamo, c'ha questo piccolo difetto da questo punto di vista.Però credo che l'usabilità sia veramente al top.Però Redmine credo che soffra dello stesso, diciamo, dello stesso male di Jira.Ovvero che se te lo trovi, come me lo sono già trovato io, che è già stato configurato, il flusso di lavoro è già stato definito, è bellissimo.Ma se dovessi cominciare con installazione da zero, con le infinite possibilità di customizzazione e di intrecci che ci sono, secondo me la curva di apprendimento e del tempo necessario per configurarlo a dovere è immenso.Io mi ricordo che qualche tempo fa sul gruppo Telegram di GitBar, perché sì, abbiamo anche un gruppo Telegram, uno dei presenti qui mi disse che aveva proprio fatto consulenza su come customizzare Gira e io mi sono ritrovato in una realtà in cui c'era la necessità di dover chiamare addirittura un consulente per poter configurare Gira.Quindi secondo me da questo punto di vista...- E qui si esplode Gira.- Sì, sì, esatto, esatto.E quindi credo che effettivamente Redmine soffra di questa curva di apprendimento che è veramente alta.Il fatto che si possa customizzare ovviamente può essere sia un male e sia un bene, perché magari se voglio fare Scrum, ok, con l'installazione base che ho di Redmine, con le customizzazioni che mi dà, diciamo, di default, lo posso fare, ma anche no, ci devo comunque mettere mano.Alla fine ho questo tempo in cui devo imparare sia come funziona Redmine dal punto di vista amministrativo, sia come funziona Redmine dal punto di vista, diciamo, del flow di lavoro.E credo che Redmine possa anche essere un ottimo CRM per chi ne abbia bisogno.Ed è, secondo me, più comodo dare un accesso a Redmine ad un cliente per poter seguire i lavori, la Kanban board, o semplicemente poter aprire un ticket, perché sì, Redmine a questo punto può essere anche usato come ticketing system, piuttosto che magari dare un accesso a una board di Gira, a un GitHub project o a GitLab, perché insomma da questo punto di vista io credo che sia GitLab sia GitHub, nonostante io li ami per il project management a livello di sviluppo software, credo che non siano dei tool adatti anche a chi non è tecnico o magari per organizzare il lavoro in una maniera, diciamo, un po' più ad alto livello.Se già solo pensiamo che alla fine una issue, eh, una issue, una board su GitLab è sostanzialmente legata alle issue di un determinato repository e si interagisce con le label di quel repository o di quel progetto, secondo me è un grande difetto da questo punto di vista.però sicuramente so che mi smentirete e mi prendete in giro, quindi sono pronto.- Mattia! - No, in realtà, sì.Io ho usato Redmine ormai dieci anni fa, e lo usavo principalmente come shoot tracker, nel senso che stavo lavorando su un sistema ormai in produzione da un po' di cui dovevamo fare transfert di ownership a un altro team, e quindi di fatto lo usavamo solo nel senso che loro ci aprivano i bug però tutta questa introduzione l'ho fatta perché volevo flexare una cosa assolutamente ridicola che io nella mia vita ho scritto un plugin per Redmine che è rilasciato per Open Source e serve a cercare gli issue duplicati quando ne stai aprendo uno fa la ricerca per titoli simili e ti dice "forse cercavi, c'è un issue già aperto con un titolo simile" Giuro! Questo va a favore del fatto che, come diceva giustamente Carmine, essendo scritto in Rails e all'epoca con molto jQuery, è abbastanza semplice entrarci dentro da sviluppatore.A livello di interfaccia utente però, ecco, brutto brutto brutto.Almeno io l'ho usato dieci anni fa e dieci anni fa mi sembrava una cosa di dieci anni prima.è uguale a dieci anni fa, non è cambiato niente.Anche se, adesso magari spoilererò il topic di quali sono i sistemi di gestione di project management che non ci piacciono, mi ricordo che quando sono arrivato in questo team che usava Redmine, arrivarci da un team che usava Bugzilla mi sentivo nel futuro.Ah vabbè, chiaramente, certo.Allora io volevo, mettendo da parte Lego perché ho una serie di strangopinion anche io su questo tema, io volevo far alzare la mano tra i presenti nostri, insomma, a chi usa Gira, perché non so se qualcuno lo usa in azienda dei noi.Attualmente è un passato.In passato sì, in passato ho fatto questo peccato.Credevo fossimo di più ragazzi.Orrendemente no, però ho usato chiaramente, ti capita.Sì, io l'ho usato, l'ho installato anche a un certo punto della mia vita.Quanto hai fatturato? Eh, tanto.Io ho fatto una valutazione se si poteva introdurre nel nostro flusso lavorativo, quindi se andava d'accordo con l'integrazione banalmente di GitLab o tutte le integrazioni in un verso nell'altro.Ho fatto dei test così, però ancora non l'abbiamo ne preso, ne inserito in azienda.Cosa usate voi? Tiger.Ah, pensate! Attenzione a Tiger, bello! Self Hosted, ovviamente, è un premise, è open source, sulle nostre macchine, va una bomba.Io non ero assolutamente preparato a questa situazione perché credevo che Leonardo che sta a Nearf, vabbè magari tu usi più spesso quello del cliente che quello vostro.Esatto, esatto.Leo li conosce tutti.Diciamo che ora sono su un progetto dove usiamo Azure DevOps che vorrei far usare TrollBeef a chi dovrà editare questa puntata, però mi ci trovo molto molto male, tutti ci troviamo molto male più che altro per alcune cose che non si capiscono come mai sono in una sezione piuttosto che in un'altra, insomma è molto complicato, devi fare una serie di click per vedere le cose che dovresti fare, è veramente molto complesso, mi astengo anche da dirlo.Gira è complesso, però quantomeno, a parte è molto diffuso, quindi alla fine tutti più o meno l'abbiamo usato e abbiamo un po' un'idea di dove sono le cose.Lì trovi più o meno gli stessi termini, però o fanno cose diverse o sono da altre parti, è veramente tremendo.Scusami adesso, secondo me lei ha sollevato un tema mega interessante che è quanto è effettivamente intuitiva e familiare la UX di un tool.Nel senso che è vero che gira spesso e volentieri, è un macchinone, soprattutto se devi configurarlo è un baraccone di quelli appunto per cui devi pagare un consulente per farlo.Però da utente ha il vantaggio, secondo me, rispetto ad altri tool che o comunque ti è capitato di usarlo in passato o comunque è simile ad altre cose che usi, no? magari non necessariamente belle, però è familiare e quindi è difficile, o almeno nella mia esperienza io ricordo che è difficile trovarsi 100% spaisati.C'è un tema interessante secondo me di UX, nel senso che a quel punto potranno scoperchiare questo vaso e dire "è meglio fare una UX bella o una UX familiare?" Che sia intuitiva per gli utenti.Nelle prossime 150 puntate di Geekbar approfondiremo questo discorso.Infatti è un tema davvero forte, ti dirò anche perché secondo me, dopo l'esperienza taica che tuttora continua, abbiamo fatto anche un tentativo con Open Project, che è sempre un altro strumento open source, che ti permette sempre di generare, diciamo, di la Kanban, la board con i timestamp eccetera eccetera in base ai task.Però ovviamente lì la curva di apprendimento, al cambio di come veniva la configurazione, l'interazione con il flusso di lavoro all'interno dello strumento, era totalmente differente.E questa non è che è stata ripida come curva, è stato proprio un muro che ce l'ha fatto proprio di aree abbiamo detto che lasciamo perdere, meglio Taiga, e quindi abbiamo fatto un passo indietro.Quindi il concetto di UX è molto forte.Però detto questo, visto che c'è la parola, volevo anche fare un approfondimento riguardo a questi strumenti.A mio avviso che non è lo strumento che risolve, diciamo, il nostro problema.Noi dovremmo capire quale problema vogliamo risolvere all'interno della nostra azienda, con il nostro team.E grazie a quello, scegliere lo strumento che ci risolve quel problema.Quindi non andare dritti su uno e basta soltanto perché è quello che ci permette di fare tutto, soltanto perché è quello più bello con le iconcine, quello che ha la grafica più vintage e hipster del caso, ma quello che ci fa stare bene, ci fa lavorare bene e ci fa essere produttivi.Quindi dipende molto da team a team, da produttore a produttore, eccetera eccetera.No, però non è un po' un chicken-egg problem, nel senso il vostro flusso di lavoro lo avete così perché, diciamo, assumo che siete associati a un TAIGA.È chiaro trovare lo stesso flusso di lavoro con un altro strumento, forse è più difficile perché magari siete legati a TAIGA, diciamo che è una mezza provocazione.Ditici, io sto cercando un altro strumento che abbia lo stesso flusso di lavoro e magari un'interfaccia simile a Taiga.Sono espresso male, forse volevo dire, io sono T0, devo cominciare oggi, devo scegliere lo strumento che è meglio per me.Mi riferivo a questo caso d'uso, non a un eventuale switch.Ce l'ho anche per questo allora.Come fai a sapere qual è il tuo flusso di lavoro? hai fatto il flusso di lavoro prima? Nel senso, c'è anche la...Diciamo io apro una software house oggi, non so qual è il mio flusso di lavoro, posso appoggiare...Dico guarda, cerco un software che mi piaccia e mi adatto a quel flusso di lavoro.Poi dopo magari è più difficile tornare indietro, però ci può essere anche questa...cioè adattarsi a un software per come si fanno i prodotti, per esempio.Dico guarda, vediamo come l'imposta gira.Seguo quel modello lì.LM: e secondo me questo potrebbe essere un errore.Cioè nel senso, come voglio impostare io il mio flusso di lavoro? Prima lo facevo con le mail, con un google doc, con notion, diciamo che cosa mi piace tutto questo? Riesco a farlo tutto quanto in uno strumento solo? Se sì, chi me lo permette? Ovviamente se poi vai nella direzione di Gira o Redmond che ti permette di customizzare i flussi eccetera eccetera, hai fatto scopa.Se invece tu vai in uno strumento dove non è customizzabile e ti dicono ok, crea il progetto per fare Scrum, crea il progetto fare l'issue trigger, non lo puoi né customizzare né gestire i flussi per dire quando una cosa è dana o non è dana in pre-approvazione, in QI, in QA e via discorrendo.Sono questi i limiti che io vedo nella scelta, cioè quando non ho possibilità di customizzazione.Ma infatti secondo me adesso io vi faccio un'obiezione davvero accademico e vi dico che un testo che per noi di fatto è un riferimento importante che è il manifesto agile dello sviluppo software dice chiaramente individuals and interactions over processes and tools e secondo me il dipende grosso della situazione visto anche che comunque quasi più di mezz'ora che stiamo parlando non abbiamo ancora detto dipende e questa cosa non è legale.Il grosso dipende della situazione, è quali sono gli stakeholder coinvolti, nel senso che, e qui un po' anche contraddico quello che ho detto prima, è vero che Gira è uno strumento che potrebbe risultare familiare a un primo impatto, ma ci sono tante tipologie di stakeholder per cui magari non lo è, come per esempio delle persone non tecniche.Per cui, secondo me, la scelta di un processo, quindi poi anche dello strumento che c'è stesso atteso, dipende molto da quali sono gli individui coinvolti.Per esempio noi usiamo tantissimo il nostro tool di project management Trend, di fatto, che è uno strumento assolutamente non technical people friendly, nel senso che è molto molto comodo e molto semplice da capire per le persone non tecniche.Ci sono le cose che trascini da una board all'altra ed è super facile, super leggero ed elastico, e tra l'altro noi ci siamo trovati molto bene proprio nel T0 di cui parlava Andrea, nel senso che Trello è uno strumento super elastico, non ha nessun tipo di processo definito, e quindi si adatta molto bene e si presta molto bene al caso in cui non hai un processo definito, ma sai quali sono le persone coinvolte e il processo lo definisci un po' iterativamente.Per cui io credo che alla fine quello che fa davvero tanta differenza e quello che è importante sapere all'inizio o comunque su cui è importante avere della flessibilità è quali sono i tipi di stakeholder coinvolti più che cosa ti fa fare o non fare uno strumento.Completamente d'accordo, anche perché tu ci ti ambienti nel momento in cui tu lavori con persone non tecniche.In contraposizione a questo, se tu hai un team che fa soltanto tecnologia, non parla con produttore, non parla con stakeholder, banalmente ti potrebbe anche bastare semplicemente GitLab, con la gestione delle issue interne sui repo, con la gestione delle milestone interne, la wiki interna al repo, eccetera eccetera.Ti puoi fare anche la board, che diciamo a livello di gruppo, non sul repo specifico, a livello di gruppo così ti gestisci tutta la roba del team là, non hai nessuna interazione con stakeholder, ti può bastare tranquillamente questo e fattici il corso che vuoi e ti ci chiudi le issue anche grazie alle pull request, alle merge request eccetera eccetera.Infatti mi volevo dire proprio questo, allora noi nella mia azienda, il gruppo, l'area tech siamo in 5, il grosso dell'azienda è diviso in altre aree, c'è l'area sales, content e quant'altro.Dover dire a persone non tech e magari anche poco avvezze della tecnologia, cioè ci sono persone che hanno solo un portatile e un foglio excel e oltre non sanno andare, quando va di lusso quando c'è il foglio excel, altrimenti è un libre office.Uno non puoi pretendere di dargli un mattone come gira o anche come gitlab o qualsiasi altra cosa e dire ok allora la issue, quando devi mandare un ticket, mandamelo in questa forma o vedi la label, è impensabile.Infatti da quando sono un po' responsabile ho deciso di non forzare le persone non tech a usare strumenti e tool nati per essere tech e soprattutto vedere un po' loro con che cosa si trovano meglio.questo ha complicato un pochettino il mio lavoro, però poi alla fine a conti fatti ci guadagno e ci guadagno anche tanto.>> SULVENTIRE Su questo io ho una domanda, a parte che io so che tu hai una strong opinion, un'opinione forte, ancora più forte di quella di Carmine sul project management, ma poi semmai ci torniamo.In realtà la cosa che vi volevo chiedere è cosa ne pensate nel caso in cui un team piccolo, in generale una startup, una società piccola, eccetera, scala verso l'alto, verso lo split in più team o comunque insomma cose di questo tipo.Per esempio Andrea, anche se hanno avuto problemi di questo tipo, come vi ponete, visto che il manifesto agile, si dice "individuals and interactions over processes and tools", secondo voi un team può adottare il proprio strumento di project management o definire il proprio flusso di lavoro o dentro l'azienda ci si deve conformare a un flusso di lavoro comune, unico, quanto più possibile? Allora, secondo me ogni team ha il diritto di scegliersi il suo strumento.Nel senso Io sono passato per questa situazione in cui, diciamo, allora, secondo me, dipende innanzitutto tra le interazioni che ci sono tra i vari team.Spesso, secondo me, nelle aziende, diciamo, che hanno una forte componente tecnica, il collo di bottiglia è sempre il Team Tech, perché magari arrivano ticchette, arrivano richieste, arrivano bug, può arrivare qualunque cosa.e secondo me, appunto, come ha detto poco fa Luca, avere il team tech che ti dice "vai per questa strada qui" e quindi se mi devi inviare il ticket, mi devi inviare in questa maniera qui o mi devi inviare una mail o mi devi inviare un Google Doc che deve scrivere su un Excel, è sbagliato.o meglio, secondo me, diciamo, ci deve essere una sorta di hexagonal architecture o meglio, abbiamo bisogno secondo me di definire le porte EG adapter per ogni team e tra ogni team.O meglio, se il team sales deve comunicare con il team tech, c'è un canale dedicato che però non fa sì che il lavoro del team sales o del team marketing si debba adattare a quel canale di comunicazione.Cioè ogni team deve avere l'autonomia di potersi gestire con il tool che ritiene più comodo.Questa cosa qui però secondo me poi si scontra con la realtà dei fatti che è anche quella economica, perché nel senso se un team che magari sono solo 15 persone si compra un tool, se un team con altre 15 persone si va a comprare un altro tool, questa cosa può diventare anche una spesa e non è detto che questa spesa sia poi realmente giustificata.Cioè, nel mondo ideale ci sarebbe un unico tool interno che permetterebbe di fare tutto.E secondo me ci sono tante aziende che si affidano o sulla suite di Google o su quella di Microsoft per ottenere, diciamo, questa omogeneità.E secondo me è un male, perché nel senso, io non so se qualcuno di voi ha mai utilizzato Teams invece di Slack come persona tecnica.Cioè è un inferno.Io non darei Slack per niente al mondo.Forse, forse, forse Mattermost.Però secondo me più il tool è generalista, più fa del male a qualunque figura nell'azienda.Questa è una cosa molto molto bold, però secondo me è la verità.Figura specializzata, Antenna.sì confermo tutto il male possibile per teams altro giusto stamattina leggevo un rumor che parte microsoft voglia comprare discord visto che evidentemente anche loro sanno che teams non è proprio un giochiere beh magari fanno come...lo vogliono rendere come teams cioè fanno il contrario di Remida e non lo possiamo dire come si chiama cioè che lo prendono e diventa non-mida Vai vai Andrea.Io volevo fare un passo indietro e tornare un attimo al discorso che introduceva Alessio che Carmi ha approfondito egregiamente, che è giustissimo che il singolo team si scelga il proprio strumento di comunicazione, ma c'è un grandissimo ma, se questo team lavora un progetto dove il team è un pezzettino del puzzle, quindi che ne so, si lavora un un macro progetto dove io faccio un pezzo, dove un altro time che fa un altro pezzo, che è tutto coordinato da un altro macro team, che è revisionato da un altro team ancora eccetera eccetera.In questo caso, per forza di cose, lo strumento deve essere uno per tutti.Cioè non si può, bisogna veicolare tutta una parte di informazione anche per facilitare le discussioni e che tutti siano a corrente dello stato dei pezzi di ognuno.Ad esempio, quanto ha migliorato l'attività lavorativa nostra, dei nostri colleghi e dei nostri capi, di chi sta sotto di noi, l'utilizza ad esempio della Kanban.Cioè, uno strumento banalissimo, però grazie ad esso capisci perfettamente a che punto ci troviamo, quanto stiamo indietro, cosa dobbiamo fare domani, cosa abbiamo fatto ieri, cosa sta già su staging, cosa sta già in produzione, eccetera, eccetera.Se ognuno si utilizza il suo, tutta questa trasparenza viene meno, la perdi, non riesci a trovare un veicolo che ti mostra questo stato.Quindi in questo contesto io sono per, diciamo, l'elefantone enorme che mi mette in contatto tutti quanti, senza ombra di dubbio.Volevo solo dire questo.LM: ma usare, per esempio, adesso io parlo sempre, secondo la mia esperienza, che comunque siamo un team piccolo e non ha altri team tech con cui dialogare, quindi siamo noi e noi.Noi ci troviamo benissimo con GitLab proprio anche per la gestione dei progetti.Abbiamo dovuto inventarci qualche trucco per rispettare i principi agili, però ormai con milestone e le iterations puoi già avere il quadro generale con le giuste label, con i giusti progetti legati ai vari gruppi che ci sono.Alcuni mi viene a dire un trucco carino che ho utilizzato di recente che pare funzioni miracolosamente, è quella di usare le issue weight, il peso delle issue in GitLab per misurare l'impegno della singola issue, ma la cosa carina è che, non mi ricordo dove l'avevo letto, ho detto "sì proviamoci", è quella di usare i numeri della serie di Fibonacci per dare il peso, in maniera tale che così ti perdi un attimo il margine di quindi tu una ishu sai che puoi impiegare mezza giornata o un giorno, lo sai se sta più verso la mezza giornata o sta più verso il giorno e quindi non puoi sbagliare.Stranamente per i grandi numeri alla fine ci azzecchi sempre, cioè la previsione è praticamente azzeccata.Noi facciamo tipo 300 chili di ishu a settimana, le abbiamo battezzati così e sappiamo che sono quelli e non sgarriamo con tutte le problematiche attorno ed è un buon modo per fare le previsioni e per gestire progetti anche di lungo termine diciamo così.Mattia ti vedo che stai...Sì, ho alzato la mano perché volevo fare una domanda a Luca e una considerazione su questa questa cosa che ha appena detto la domanda è quanto tempo ci avete messo ad arrivare a stabilire quanti chili fate a settimana? Perché la considerazione che mi arriva dall'esperienza passata è che quantificare le cose, quantificare il peso delle cose da fare è uno dei problemi più grossi del nostro lavoro per centomila motivi diversi.da appunto il problema di cui parlavamo prima di avere a che fare con persone non tecniche che ti dicono "ma è solo un bottone, magari quando clicchi quel bottone devi fare internet", al fatto che spessissimo ci capita di non sapere cosa non sappiamo di un problema e sono cose che emergono dopo.Per cui io ricordo chiaramente che in un'esperienza passata abbiamo abbandonato le stime numeriche che facevamo anche noi con la serie di Fibonacci perché è una cosa nota in letteratura e siamo passati alle T-shirt size, quindi S, M, L, X, L perché proprio volevamo che non ci fosse un discorso numerico perché poi era molto difficile far capire alle persone non tecniche che non c'è un mapping diretto tra il peso numerico di un task e il tempo che ci vuole farlo.ti faccio una battuta, a meno che non sviluppi chiaramente cose tipo il kernel di Linux, è più complicato di così, secondo me stimare è l'unico vero problema di questo lavoro.- Cioè, sono assolutamente d'accordo ed è anche questa una cosa di quelle di cui potremmo parlare per le prossime 150 puntate di Game Bar.Quindi aggiungiamo la terza cosa a dare il nome alle cose alla cash e stimare le proposte.C'è anche lo "buy one, earn one".Io sono assolutamente uno del...un fervente credente del movimento "no estimates" e quando mi chiedono quanto ci vuole a fare una cosa, la risposta è "quanto ci vuole".No, questo...questo perché ci ho sbattuto la testa tantissimo in passato, quindi Luca invece se tu mi dici che voi vi trovate bene con questa cosa, volevo sapere quanto ci avete messo, quanto sangue ci hai sputato e come hai fatto, perché da grande anch'io vorrei essere così sereno nel dirlo.No, alla fine c'è come detto la stima della singola issue è difficile farla ed è per quello che si va a volte in eccesso, scentemente, e a volte in difetto perché si è ancora un po' junior nel fondo all'animo.Però in uno sprint abbiamo visto che dividendo per bene i task, quindi cercando di dividere i task in modo che ogni task non prenda più di un giorno nella nostra testa, cioè quando tu dici "ok questa la faccio, sì sì, in un giorno la faccio", poi saranno tre giorni oppure si cambiare colore al bottone la faccio in dieci minuti e poi sono due ore comunque tradurre quell'istinto che ti viene di dire in Kili di Ishu bene o male sicuramente non accetti il singolo task però nel lungo periodo, in quelle due settimane, quelle due tre settimane gli errori si si equivalgono, si azzerano.Ci abbiamo impiegato, allora alla fine dopo 3-4 sprint abbiamo visto che era abbastanza costante però attenzione c'è un piccolo trucco.Noi non lavoriamo solo ed esclusivamente allo sprint corrente.-Sprint scusami da una settimana, da due? -Due settimane.Due settimane.Non lavoriamo esclusivamente allo sprint perché c'è sempre qualcosa che esce.È una di quelle regole che sarebbe bellissimo applicare ma che almeno nel nostro caso non è possibile applicare.Diciamo che abbiamo margini di manovra sul tempo da dedicare ai task dello sprint.Però l'importante è che in quelle due settimane riusciamo a chiudere 300 kg di issue con tutte le problematiche che ci sono.Alla fine non è stato un numero che abbiamo deciso, è stato un numero che alla fine abbiamo visto che viene a seconda delle nostre previsioni, abbiamo visto che più o meno ci siamo.Sicuramente ci teniamo larghi perché qualcuno poi dedica più tempo perché ha una singola issue perché magari è l'ultima che sta facendo invece di impiegarci un paio di ore ci impiega tutto il giorno però quello mi va bene lo stesso l'importante è che quello che avevo previsto di fare si fa poi Leonardo siamo lì io avevo mi ricordo software che una conferenza si teneva a Firenze tanti anni fa su metodologie di sviluppo diciamo c'erano più pm che sviluppatori in quella conferenza, mi ci sono ritrovato.Lo speaker fece questo esempio, proprio parlando di stime, e diceva "quanto è secondo voi la sala, questa sala qua, quanto è lunga?" Allora tutti si guardavano intorno, "non lo so nemmeno io, potrei dire che è lunga 10 metri, però non lo so".Ha fatto tre passi in avanti, ha detto "ecco, ho fatto tre passi.I miei passi più o meno sono di un metro, mi trovo circa a un terzo, posso dire che più o meno sono 10 metri.Cosa vuol dire? Che finché te non metti un po' di mani in pasta e capisci qual è il problema, perché la stessa sala potrebbe essere in salita, che sono sempre 10 metri, ma ci vuole un effort in più, non lo sai spesso.Quindi io trovo molto difficile fare le stime e questa cosa mi aiuta più che altro a spiegarle alle persone che me le chiedono, dicendo "guarda, io non lo so, ci vuole X, però prima fammici lavorare perché potrebbe non essere così".Quello che facciamo noi non è un processo standard per il più delle volte, anche se il 90% è crude, però non sappiamo quanto può essere complesso quel crude, quindi le cose cambiano e bisognerebbe usare la parola "dipende".In psicologia queste si chiamano ancore, infatti quando tu hai un ancora, hai un numero, hai un punto di riferimento e sai che comunque ti puoi muovere attorno a quel numero, un po' più sopra, un po' più sotto.L'importante è avere l'ancora e l'importante è avere l'ancora giusta, perché a volte ci sono studi che dicono che anche se hai un ancora completamente fuori dal mondo, farai previsioni fuori dal mondo, cioè fuori da ogni logica.soltanto il fatto di avere un ancora che sia stata casuale o che sia stata pensata ti ti fa cambiare la tua valutazione Io mi riallaccio un attimo al discorso dei tool ormai mi sembra che puntata dopo puntata sto diventando la sezione RSU di GitLab però...Sei la sezione mindfulness.[risate] Secondo me il tool giusto è anche il tool che ti dà il diritto all'offline.Che il diritto all'offline può sembrare banale, no? Della serie "sì, ok, una volta che ho finito la mia giornata lavorativa spengo il computer, silenzio l'email e ok, basta".secondo me quello non è il diritto all'offline vero.Il diritto all'offline secondo me te lo dà il tool dove puoi decidere selettivamente di che cosa essere notificato e quando esserne notificato.Una cosa secondo me ottima è quello che ti permette di fare Slack, ovvero quello di dire "silenzia le mie notifiche, perché sono fuori, perché ho finito la mia giornata, perché non voglio essere disturbato, io comunque la possibilità, esplicitandolo, di poterti pingare.Secondo me, questa cosa, almeno nella mia esperienza, non ce l'hanno tutti i tool.O meglio, ad esempio, vi faccio un esempio banale perché ormai io sono sono vecchio dentro e mi piace Redmine.Su Redmine ho la possibilità di essere l'assegnatario di una issue, ma non esserne watcher.Io posso decidere di non voler ricevere più notifiche su quella issue.Quindi se pubblicano commenti, se la issue cambia, se succede qualunque cosa, io posso decidere selettivamente di non essere disturbato.E questa cosa mi aiuta tanto a ridurre anche il context switch.perché almeno per me passare da una cosa ad un'altra in un dominio completamente diverso è una cosa che mi fa impazzire.Questo dominio completamente diverso può essere anche una semplice notifica su Slack dove mi dicono "è sta succedendo questo, quell'altro, tu che ne pensi?" che ovviamente mi fa piacere rispondere, mi fa piacere interagire con un collega, ma apprezzo il tool che mi dà la possibilità anche di non farlo.Perché secondo me poi alla fine essere notificati su tutto, avere questo bloating di notifiche, di ping, di poke, come si faceva una volta su Facebook, è una cosa che nel lungo termine, ma anche nel medio forse, può veramente portarti ad un burnout totale, specialmente adesso che stiamo lavorando da casa.Quindi magari non c'è l'ufficio che si chiude e poi finisce lì.Esatto, era esattamente...la tua ultima frase è esattamente quello che volevo aggiungere io, nel senso che quello che dici è vero in generale, ma secondo me è vero a maggior ragione in un momento come questo, che per chi ci ascolterà nel futuro ricordiamo è durante una pandemia, in cui stiamo lavorando tutti da remoto e tutti con orari variopinti e magari anche potrebbe capitare in timezone diverse per cui, per esempio, io faccio spessissimo Code Reblu la sera dopo che mio figlio dorme e ci sta che il resto del mio team non voglia ricevere notifiche alle 10 di sera che io ho approvato una pull request e mi sembra assolutamente il minimo e allo stesso modo succede a me.Diciamo che il tweaking delle notifiche è un tema importantissimo in generale, come hai detto tu, sia per una tematica psicologica ed emotiva di ridurre lo stress da notifica, e in questo momento che siamo con dei tempi più variegati ancora di più.Quindi mi state dicendo che a nessuno di voi manca il trillo di MSN? Assolutamente sì.Pensavo la stessa cosa.No, no, no.Il trillo di MSN è tutta la tua storia.Se eri infame e avevi MSN+ facevi trilli infiniti, che era la cosa più molesta, veramente.A me manca molto.E avevi pure gli emoti con animati con MSN+.Beh queste comunque la conoscono solo i più vecchi, ma proprio vecchi.Infatti noi siamo dei vecchi.Io sono anche fan del bb code comunque, sui forum c'erano i bb code bellissimi.Secondo me Carmine è meno giovane di quello che dice, perché, pensate, Windows 3.1 che gli piace solo perché non l'ha mai usato, un po' come noi diciamo "ah, bella la musica anni '60", ma se...Io non l'ho mai detto, non ce l'avevo mai detto.No, il Luke & Phil mi piace, non mi piace funzionare.Ah, perché Carmine è giovane, per lui queste cose sono vintage.Esatto.>> ARCADIO SILVA Esatto.>> MAURizio Crespo Ma sono tornate di nuovo di nuovo.>> ARCADIO SILVA Col tema d'arte.>> MAURizio Crespo Abbiamo detto un sacco di cose, speriamo che abbiate trovato degli spunti per portare delle sperimentazioni nel vostro team, in azienda, a casa, se insomma siete come noi che fate i pazzi e oltre a lavorare, dopo lavoro, lavorate di nuovo.Adesso c'è una cosa relativamente nuova, nel senso che l'abbiamo fatta lo scorso episodio, è stata molto divertente, abbiamo avuto diversi feedback positivi e quindi in realtà oggi Andrea farà il presentatore, non so se si può dire, ma io lo dico lo stesso del nostro Passaparola di Gitbar.Vai Andrea.LR: Passaparola! Ovviamente qui e poi la regia metterà tutte le musichette giuste, le fiamme, eccetera eccetera.LM: E gli ulla alla ulla.LR: Esatto.Alessio dici benissimo perché i feedback sono stati tantissimi.Non potevamo non ripetere tutto questo visto il grande entusiasmo, grande richiesta.Questa settimana lo faremo con due nuovi concorrenti.Questa settimana saranno Mattia Tommasone contro Carmine Di Monaco a sfidarsi per la lotta per raggiungere chi dirà meno passaparole possibili e conoscerà tutte le risposte alle domande che andremo a fare.Questa settimana l'abbiamo preparato insieme io, Luca e Alessio.Siamo divertiti e divertiti.LM: "Vabbè dai, ti volevo dare un po' di riconoscimento perché hai fatto la review, ci sta.Le regole non sono cambiate, sono sempre 21 domande, le risposte altrettanto 21.Se non sapete la risposta, basta dire passaparola e andremo a quella successiva.tre minuti di tempo a testa e per iniziare inizierei con Carmine soltanto perché il suo nome è più in alto di uno di noi.Sono pronto a mettere le cuffie? Dimmi quando sei pronto che faccio partire il tempo.Sono pronto, vai.Via.Colla A.Sistema operativo per mobile.Android.Ottimo.Android.Ottimo.Colla B, sistema di codifica che consente la traduzione di dati binari in stringhe di testo ASCII.Passa parola.Ok.C, metodo che in molti linguaggi restituisce una copia dell'oggetto su cui viene invocato.Copy, clone.La seconda, ottimo.D, fumetto creato da Scott Adams, i cui protagonisti sono l'ingegnere omonimo e il suo cane.Passaparola.Ok, con la E lo facciamo quando apportiamo un miglioramento o un aumento delle prestazioni al nostro software.Con la E? Passaparola.Ok, con la F, interfaccia utente di una web app che consente all'utente di inviare dati al server.Form.Ottimo.Con la G, abbeveratorio col codice versionato.Git.Abbeveratorio.Git bar.Bravissimo, grande.Questo era difficilissimo, lo so.Con la H, traspiratore che creo Facebook tradurre il codice PHP in C++? H.Quella è la macchina virtuale? Il nome del transpiler? Passaparola.Sempre con la H.Ok, andiamo avanti.I.Di solito, L, una dipendenza? Con la I.La prima dependency.Potrebbe anche andare tra le possibili risposte, dato come buona.L, uno dei framework più usati in PHP.L'Aravel.Ottimo.La M in MVC.Model.Ottimo.N, operatore logico di negazione.Not.Ottimo.O, in JavaScript lo è ogni cosa che non sia una primitiva.P) insieme di regole formate e descritte che definiscono la modalità di comunicazione tra due o più entità.Q) lo fai per interagire con database.R) un lampone di computer e sistema operativo.Raspberry Pi.Bravissimo.S è il soprannome dato all'area della California dove hanno sede le più grandi aziende italiane.Silicon Valley.Bravissimo.T sono in continua guerra con gli spazi con l'identazione del codice.Tab.Ottimo.U, classica label davanti al messaggio di errore, is not a function.LM: bravissimo.V, lo sono i log chiacchieroni.D, Bosie.LM: bravissimo.Fine.Z, Mark, creatore di Facebook.Z, Zuckerberg.LM: e ci fermiamo qui, mi spiace perché abbiamo superato i tre minuti.Quello che hai saltato, con la B abbiamo il sistema di codificazione.Quello è con la B, bravissimo.Mattia, Dilbert, il fumetto creato da Scott Adams.Invece con la B, sistema di codifica che consente la traduzione di dati binari in string di testo ASCII è B64.Invece lo facciamo quando apportiamo un miglioramento, un aumento delle prestazioni al nostro software? Chi la sa? L'efficientamento? Un enhancement.Ah, perché era in inglese, ovviamente era un'ottimizzazione.Esatto.Siamo international qui su Beatrap, scusate.Un po' e un po', e permettevi sempre che abbiate un po' più di difficoltà.Se siete troppo bravi è difficile trovare qualcosa che non sappiate.Comunque ottimo risultato da parte di Carmine, su 21 ne ha assaltate soltanto 3.Posso dire, vuoi fare una menzione sulla pronuncia di Quiri, che è quella corretta, che però in Italia non si può dire per non risultare troppo, per non flexare troppo.Io ti dico solo che a un certo punto della mia vita l'ho sentita chiamare "Qerai".Qerai! No, quello ne vedo io con nome! Questo è un passato remoto! E' Qerai Zed, mi rispose! Va bene, va bene, tornamo al topic! L'unica cosa è il traspiler di Facebook.Ah, è vero, è il pop! che è hip hop, però ci sono anche H, HHWM, tutte cose con la H, non l'avrei mai indovinata manco io, guarda.- Ma in realtà una andava bene, una a caso.- Bastava dirle tutte.- In realtà la domanda era una cosa di Facebook con la H.- Esatto.Vedi che sarebbe stato molto più bello dire la risposta che la domanda.Va bene, torniamo un attimo a serie perché questa è una serie a composizione ed è importante.Mattia sei pronto? Sto facendo stretching, sono pronto.Le regole sono uguali anche per te, vabbè visto che le conosci benissimo.Quindi partiamo con la A.Lo è la classe non istanziabile.- Astratta - Ottimo.B) La criptovaluta attualmente più preziosa al mondo? - Bitcoin - Good.C) Come il C, ma con più classe? - C++ - Sì.D) Soluzione progettuale generale ad un problema ricorrente? - Design pattern - Ottimo.L'animale mascotto è il linguaggio PHP? "Elefante".Yep.F, linguaggio di programmazione nato nel 1954, acronimo di traduttore di formule.Fortran.Grande.B, Bill, fondatore di Microsoft.Con la G, credo che sia Gates.Yep.H, linguaggio di markup, base per lo sviluppo web.HTML.Yes.I, ambienti di sviluppo integrato della Jack Brains.IntelliJ.Yes.L, closure ne un dialetto.Lisp.Esatto.M, l'azienda proprietaria attualmente di GitHub.Microsoft, se vogliono comprare anche GitHub, noi siamo comunque N) classico risultato di una divisione per zero in GIS.Non.Ottimo.O) Eddy, appassionato di strumenti di performance su Google Chrome.Ah, Usmani.Esatto.P) acronimi ricorsivi di Hypertext cosa manca? Passaparola.Ok.Codice a barre bidimensionali tipicamente fatto da quadrati bianche e neri.QR code.R, lo è una funzione che chiama se stessa.Ricursiva.Esatto.S, Salvatore, creatore di? Redis.San Filippo.Esatto.T, li si crea quando si divide un processo in più sottoprocessi, che vengono eseguiti concorrentemente.Thread.Yep.U, sequenza di caratteri che identifichi universalmente ed univocamente una risorsa.URL.Yep.V, framework JavaScript creato da Evan Yu.Z, Enrico avrebbe dovuto fare una puntata con Brian Repo.Esatto.Stop al tempo.Allora, te ne manca soltanto una.Potresti fare l'unplane e hai 20 secondi di tempo.Ti sei superato.Bravissimo.Mattia.Sei pronto con la P? Vai! L'acronimo ricorsivo, Hypertext Processor, cosa manca? PHP? Esatto! Avevo della resistenza a dire che fra di noi! È sempre PHP la risposta! Ma infatti proprio a Mattia l'abbiamo messo su tre o quattro domande il PHP, giusto per farglielo dire.mi avevo avuto un po' i brividi.Speravamo fosse un coefficiente di difficoltà.Ma alla fine le risposte giuste sono sempre o PHP o Java, perché con Java si chiava, insomma, questo è risaputo.Con PHP non lo so.Però tanti non ci sono guadagnati da vivere o lo fanno.Comunque il grande catch all dell'informatica è "hai provato a riavviare".Esatto.Io confesso che rispondo spesso e volentieri formatta a chi non ha risposto.Ma poi mi cancella il group.Già se rispondi così sei a un livello un po' più avanzato.Comunque battuti a parte io vi riporto On Track qui sulla scaletta.Vedo che abbiamo un donatori non ce ne sono saltiamo la parte.io invece non la salto, ragazzi, donate! - Datele un birra al povero brainfreeze! - È importante che voi finanziate Gitbar perché se i presenti non hanno la faccia come il...e qui inseriremo uno strategico bip...- Ula, ula, ula! - ...di dire questa cosa...esatto! Se i presenti non hanno la faccia per dire questa cosa ce l'ho io, quindi donate in massa, mi raccomando! perché verrete poi menzionati in puntata non saprete mai da chi c'ha nel senso e sarà una sorpresa probabilmente il vostro nome magari lo dirà Leonardo che è il bello di Ghibar passerei quindi direttamente...- Purtroppo che siamo un podcast e mai nessuno ha visto la faccia di Leonardo - Come dice Andrea Ciraulo il podcast è lo youtube dei brutti - Esatto [Risate] Tant'è che per te però questa è la cosa e soprattutto per noi, cioè, veramente il registrare con le facce perché noi ci vediamo un video, non siamo in collo solo audio, è veramente un bliss avere Leonardo così superbello, insomma.per i prossimi 100 donatori verrà recapitata a casa una VHS con le registrazioni nostre puntate.Mamma mia sarebbe bellissimo! Non esistono videoregistratori.Esatto! Però è una VHS da collezione.La dobbiamo fare ragazzi, la dobbiamo fare.Dovremmo fare anche l'NFT delle puntate di Duke.Io posso anche lanciare una proposta, se raggiungiamo il numero di 5 donatori regaliamo un elefante PHP a Mattia.Bellissimo, un bel peluccio.lo convertiamo.Grazie davvero, come se l'avessi accettato.Anche qui, dato che ognuna delle nostre sezioni finisce in in Caciara, propongo di iniziare e far finire quindi in Caciara anche la sezione del Paese dei Balocchi.Allora, inizio io.Io ne porto due perché tanto appunto questa sezione ormai se ne porta quante ce ne pare.Allora, uno è la tastiera, una tastiera meccanica, la tastiera della Kikron, il modello K3, che è out of stock, quindi non si può nemmeno prenotare, però quando tornerà in stock vi consiglio di acquistarla.L'ho presa, sono molto contento, a parte ho preso la K3, una tastiera meccanica che ha dei switch particolari sviluppati dalla Kikron, che sono hot-swappable, quindi li potete cambiare e decidere voi quale mettere anche con la tastiera accesa, ha un layout di quelli stretti senza tastierino numerico che non mi soddisfa al 100% ma tutto il resto è top.Per confronto ne ho presa un'altra su Amazon per provare per capire la differenza l'ho restituita subito perché questi switch sono veramente comodi, non sono low profile, vi metto il link in descrizione, comunque segnatevele ogni tanto tanto da vedere se vi interessa la tastiera meccanica, questo è il top tra le due che ho provato.L'altra è Hacker Newsletter, è una newsletter che racchiude il meglio di Hacker News, quindi se non volete stare tutta la settimana a vedere Hacker News, vi prendete questa newsletter, ci sono varie sezioni diciamo, ogni newsletter avrà 20-30 link divisi per sezioni, molto molto interessanti, arriva una volta a settimana, non rompe troppo le scatole e io clicco un sacco i link perché sono veramente veramente interessanti.Quindi questi sono i miei due balocchi.Io che ho un solo balocco ed è un libro tra l'altro mi rendo conto che quasi ogni settimana consigliamo dei libri e se anche voi come me avete il problema della coda di libri da leggere gigantesca questa cosa vi farà piacere.libro molto corto, che sono 71 pagine, ce l'ho di carta in mano in questo momento, probabilmente è un libro vecchio, è del '76 e se uscisse adesso probabilmente sarebbe un post su Medium, perché si legge veramente in poco tempo, ma è densissimo e goduriosissimo.E non è un libro tecnico, perché è un libro scritto da uno storico ed economista che si chiama Carlo Maria Cipolla e si Si intitola "The basic laws of human stupidity".È un trattato scientifico su cosa definisce effettivamente la stupidità nelle persone e quali sono le leggi che la regolano e quindi di conseguenza anche quali sono delle buone strategie per contrastarla.Per esempio, la prima legge dice che il numero di persone stupide in circolazione, uno lo sottostima sempre.e fa poi un'analisi scientifica e matematica di quanto è l'errore di questa stima.Quindi si legge molto in fretta, ma è davvero istruttivo perché, volenti o nolenti, trovo la tesi iniziale che, volenti o nolenti, ognuno di noi ha a che fare con degli stupidi, oppure come ti suol dire nel poker, quando non riesci a trovare lo stupido nella stanza, lo stupido sei tu.LM: bellissimo, grande, ottimo.Io invece ve ne ho portati due.Il primo è un giochino molto divertente che si chiama Cookie Concept Speed Run.Mi ha fatto molto sorridere perché ho una buona introduzione da GTPR, ovviamente qualsiasi sito dove vai c'è un banner dei e diciamo che chi realizza questi banner, ormai siccome hanno imparato, e noi siamo molto bravi a negare immediatamente, ora li fanno sempre più strani e accattivanti in modo da confonderci.E questo giochino, diciamo, mette alla prova le vostre potenzialità e di quanto siete capaci a bloccare, a evitare, diciamo, a tenere il controllo della vostra privacy sui siti che frequentate.Lo troverete nel noterino episodio, come tutti gli altri, e invece l'altro è un'estensione di Visual Studio Code che si chiama Polacode, Polaroid for your code, diciamo che va a effettuare delle immagini a partire dal vostro codice.Spesso vi sarà sicuramente capitato di preparare delle slide, una piccola presentazione dove portate un po' di codice e sicuramente conoscerete carbon.nano.sh, però a differenza di quello dove tu su Carbon devi copiare e andarlo a incollare, con questo bellissimo plugin all'interno di VSCode basterà selezionare la porzione di codice che vi interessa, applicare il layout e le dimensioni come lo portano Resides e poi potete utilizzare l'immagine condividendola con il mondo in maniera facile e veloce.Questa è quanto, da parte mia.A me succede tutte le settimane che poi mi vengono in mente dei balocchi a seconda di quelli che dite voi, perché questa cosa che hai detto mi ha fatto venire in mente un balocco molto bello che usavo in passato che si chiama l'All Comments che fa una cosa simile, nel senso che ogni volta che fai un comment ti scatta un selfie con la webcam e ci mette il messaggio del comment sotto in Impact e quindi fa questo effetto un po' memeggiante, per cui è come se tu avessi un memino per ogni commit che hai fatto.- Ce l'ho avuto per un mese, configurato.- E c'è anche il server HTTP che ti serve a random uno dei tuoi commit ed è molto bello.- È molto divertente.- E poi quando ci torni in passato è sempre divertentissimo.Allora, io invece per i balocchi di questa settimana ne ho diversi, uno meno interessante dell'altro probabilmente.Il primo è Clean Agile, che è un libro di Jan Kolbob che conoscete sicuramente per Clean Architecture, per King Cloud, per la sua tolleranza, vabbè basta.e insomma, conoscerete sicuramente Per Clean Architecture, Per Clean Code.È un bel libro, è in realtà di qualche anno fa, però secondo me è un libro da leggere.Poi, un altro libro, bello vecchio vecchio vecchio, dovrebbe essere del 2004, è Extreme Programming Explained di Kent Beck Ed è veramente, veramente figo.Risente un po' degli anni, secondo me, l'ho letto un po' di tempo fa, però diciamo è un buon libro.E poi c'è, poi ci sono altre due cose.La La prima è Kiwi TCMS.Che cos'è un TCMS? È un Test Case Management System.Quindi può essere usato da chi fa qua o anche semplicemente dal team che vuole tenere traccia dei propri test, sia quelli automatici, sia quelli che necessariamente sono manuali.Insomma, è una piattaforma molto, molto figa può essere serfostata.E l'ultimo balocco, invece, è un consiglio, come anche gli altri, rompete le scatole a chi sta sopra di voi se qualche cosa non vi va bene o avete qualche consiglio.Perché nel senso, io lo sto vedendo tanto in queste settimane, io sono stato sempre una persona che ha fatto polemica però dietro le quinte.Se fate polemica apertamente, le polemiche sono sensate, ne trarrete sicuramente un beneficio voi perché vi sentirete molto più liberi e molto meno frustrati e se lavorate in un'azienda più o meno decente sarà anche un grandissimo raggiunto per l'azienda.Ultima cosa così è, comprate il bietto per il Ruby perché quest'anno secondo me è veramente veramente figo.Tocca a me.Allora io ho solo un balocco che tra l'altro è un libro giusto per aumentare la coda delle cose da leggere se volete, però non è un libro tecnico ma un libro di filosofia così giusto uno magari si stufa di leggere codice o cose esclusivamente di codice.Il libro si chiama "La stanza intelligente, la conoscenza come proprietà della rete perché sostanzialmente risponde alla domanda ma l'intelligenza di una stanza è uguale alla somma dell'intelligenza delle singole persone al suo interno o è maggiore? in realtà la risposta è maggiore a patto che si conosca bene la stanza in cui si è nel nostro caso la stanza è internet o social o quello che è ma potrebbero essere anche i nostri strumenti di lavoro per cui i nostri strumenti di lavoro che abbiamo nominato, sia Gira o GitLab o altro, è comunque un posto che aggrega le persone che hanno una loro intelligenza se si sfrutta al meglio è possibile aumentare l'intelligenza totale delle persone che ci sono dentro per diverse definizioni di intelligenza, questa poi la lasciamo all'elettore per esercizio chi manca? manco solo io, vado per ultimo e ho portato due cose, una è mia, una in realtà l'ho rubata.Allora, la prima è, visto che la quota di libri la smaltite molto velocemente, perché a quanto pare per esempio sul gruppo Telegram, che vi ricordo che abbiamo, nessuno ci ha detto smettete di consigliare libri, quindi io vi consiglio un altro libro, Ok, visto che abbiamo parlato di un sacco di tool agili, metodologie, cose, tool, eccetera, abbiamo citato CleanAgile, abbiamo citato Extreme Programming Explained, io vi porto Agile Estimating and Planning di MyCon, che quando facevo la metodologia agile con un team, con un coach presa tipo dogma, Il nostro coach ce la consigliava, era un libro che ce la consigliava tipo Vangelo, proprio per, veramente.E in particolare trovo che siano fatte molto bene le parti, e non è una battuta, è una cosa vera, trovo che siano fatte molto bene le parti di stocastica, di statistica, che spiegano come funzionano per esempio gli story point, le stime e in generale come funziona stimare una cosa ogni due settimane e alla fine azzeccarci.E anche come non funziona, nel senso che poi pure io sono del partito no estimates, però in generale diciamo che propendo per gli story point o comunque per metodologie agili, quando mi costringono ad adottare una metodologia o un metodo di estimation.L'altra cosa che ti porto è una cosa che ho rubato in realtà a Carmine, nel senso che tante volte noi ci prendiamo in giro perché lui ci dà sempre Redmine, l'altro tool che lui ci dà sempre è TiddlyWiki, che è un affare che credo che conosciamo io, lui e altri due del Linux User Group qua di Roma.E' un wiki, un affare scritto, credo, in PHP, non lo so, che consente di mantenere una wiki e di darla in pagina, veramente, con la Wysiwig, insomma.E' un affare vecchiotto, con un'altra UI/UX vecchiotta, Decarmine.Però la cosa particolare di cui prima stavamo parlando è che tramite Deeply Wiki è mantenuto il blog di Joe Armstrong, che per chi non lo conoscesse, e qua arriva quasi il terzo balocco, per chi non conoscesse Joe Armstrong, è la persona che ha inventato Erlang, che è un linguaggio fortemente orientato alla concorrenza, specializzato per utilizzi nelle telecomunicazioni, infatti Erlang deriva da Ericsson Language.Il blog di Joe Armstrong, io non lo sapevo, è ancora online, mi esce letteralmente una lacrimoccia, perché Joe Armstrong è venuto a mancare il 20 aprile 2019.Purtroppo, oltre ad essere un grandissimo programmatore, era anche una persona molto simpatica.Alcune persone, io non ho fatto in tempo, però alcune persone dell'Elixir Roma, lo user group di Elixir di cui faccio parte, hanno fatto in tempo a faccese una cena insieme e mi hanno detto meraviglie del fatto di poter cena vicino a Johannestrong.Quindi vi mettiamo il link del blog di Johannestrong, andatevelo a leggere perché è veramente stupendo.Con questo io credo che abbiamo terminato, quindi vi ricordo i contatti e che sono info@gitbar.it per l'indirizzo e mail.Scrivete a Mauro per sapere se è ancora vivo a @brainrepo su Telegram e su Twitter.Frequentateci, se volete uscire con noi e prenderci una birra tutti insieme al Gitbar...- Ma non si può uscire.- Cerca...vabbè, non si può uscire.- Ma c'è il gruppo Telegram? - No, sai qual è il fatto? A parte che c'è il gruppo Telegram, il fatto è questo, io sono un orso, non esco mai e quindi io dico uscire ma in realtà è stare sul gruppo Telegram, quindi se volete uscire, questa è la mia accezione di uscire.- Vabbè, c'è uscita e tipo esci da una room per entrare in un'altra room.- Sì, sì, mi nonna che era, insomma, di Avellino, diceva esci dentro e io esco dentro, proprio l'ho interiorizzato tantissimo questo concetto.Salutiamo la nonna Marcella.Appunto quindi uscite dentro con noi sul gruppo Telegram che credo sia t.me/gitbar o qualcosa del genere o comunque cercate gitbar sulla search barra di Telegram e qualcosa vi uscirà.Se esce del porno e trovate il nostro account giratecelo, è importante.Detto questo, saluti.siamo arrivati ai saluti ragazzi abbiamo fatto il minutaggio abbiamo fatto il minutaggio siamo arrivati ai saluti ciao ciao salutiamo tutti ricordiamo che abbiamo il gruppo telegramma che non sembra è stato...ah giusto giusto vi ho fatto bene a dirlo il gruppo telegramma e ricordiamo come sempre che i prossimi 100 iscritti al gruppo telegramma non riceveranno nulla e va bene così bene allora noi ci vediamo nel gruppo telegramma Ciao a tutti! Ciao! Ciao! Ciao! Ciao! Ciao! Ciao! Gitbar, il circolo dei fullstack 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 fullstack dev.[Musica]