Successfully reported this slideshow.
Your SlideShare is downloading. ×

Agile versioning with Git

Agile versioning with Git

Download to read offline

MiniIAD201, Savona, 16/04/2016

Il breve racconto dell'esperienza maturata in questa piccola-grande pratica del lavoro di un programmatore: dietro ciò che sembra una mera prassi, si cela la chiave di volta dell'agilità.
Attraverso un suo uso consapevole, è possibile migliorare sia come professionista (ad es. imparando a suddividere il lavoro in piccoli task al fine di confezionare commit piccoli e significativi, oppure usando branch locali per sperimentare e di conseguenza imparare), sia come membro di un team (ad es. usando le pull-request come modo per condividere il codice ed eventualmente promuovere le code review).
Servono impegno e disciplina, come in tutte le cose importanti, ma alla fine si ottengono dei grossi risultati, sia in termini di crescita professionale che di consapevolezza rispetto ai princìpi delle metodologie agili.
Nella presentazione verrà menzionato Git, ma tutto il discorso prescinde dallo specifico strumento; inoltre non è previsto l'uso o la conoscenza di codice o comandi complessi, ma l'intera discussione cercherà di far leva sulle possibilità che abbiamo di migliorare l'efficacia e la collaborazione all'interno di un team partendo da un uso più “filantropico” di questi potenti strumenti.

MiniIAD201, Savona, 16/04/2016

Il breve racconto dell'esperienza maturata in questa piccola-grande pratica del lavoro di un programmatore: dietro ciò che sembra una mera prassi, si cela la chiave di volta dell'agilità.
Attraverso un suo uso consapevole, è possibile migliorare sia come professionista (ad es. imparando a suddividere il lavoro in piccoli task al fine di confezionare commit piccoli e significativi, oppure usando branch locali per sperimentare e di conseguenza imparare), sia come membro di un team (ad es. usando le pull-request come modo per condividere il codice ed eventualmente promuovere le code review).
Servono impegno e disciplina, come in tutte le cose importanti, ma alla fine si ottengono dei grossi risultati, sia in termini di crescita professionale che di consapevolezza rispetto ai princìpi delle metodologie agili.
Nella presentazione verrà menzionato Git, ma tutto il discorso prescinde dallo specifico strumento; inoltre non è previsto l'uso o la conoscenza di codice o comandi complessi, ma l'intera discussione cercherà di far leva sulle possibilità che abbiamo di migliorare l'efficacia e la collaborazione all'interno di un team partendo da un uso più “filantropico” di questi potenti strumenti.

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Agile versioning with Git

  1. 1. AgileVersioningwithGit FerdinandoSantacroce @JesusWasRasta
  2. 2. me,myselfandI 1999: io, il mio computer, e le cose da fare (ed imparare a fare…) Versioning? Che roba è?! Qualche zip di backup basta e avanza… 2
  3. 3. Aprésmoi,lediluge! Tutto sotto controllo Nessun conflitto, nessun problema Il codice è mio e me lo gestisco io 3
  4. 4. IlmioprimoTeam Nuovi arrivi Si lavora bene in team! Tu fai le tue cose, io faccio le mie… Collaborazione? Sì Cooperazione? No (le due parole non sono esattamente sinonimi, poi ne riparliamo...) 4
  5. 5. Hodeciso,faròilprogrammatore Mi piace l’insegnamento La scuola (italiana) ed i suoi concorsi un po’ meno Un anno interlocutorio, con un paio di lavori poco significativi Poi il grande salto: vengo assunto da una vera software house! 5
  6. 6. Siiniziaafaresulserio Gestionale (COBOL) per farmacisti, up-and-running dal 1984 8000+ farmacie (50%+ del mercato!) 4/5x utilizzatori Se scazzi qualcosa non è così immediato rimediare... 6
  7. 7. ilCOBOL 7
  8. 8. DijkstraeIlCOBOL “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.” Edsger W. Dijkstra 8
  9. 9. “Amazing”GraceHopper ➔Programmed Mark I in 1944 ➔Invented 1st compiler ➔Realized one of the first machine indipendent programming language ➔Coined the term “bug” ➔Admiral of the US Navy Only joked for inventing COBOL... 9
  10. 10. I“veci”Cobolistielaprecisione Loro: cartella condivisa in rete Ognuno “tocca” a turno i file sorgente che deve, senza pestarsi i piedi Incredibilmente… FUNZIONA! :O 10
  11. 11. I“giovaniprogrammatorid’oggi” Io invece se posso combinare un casino, lo combino… Devo trovare qualcosa in grado di salvarmi da me stesso 11
  12. 12. Subversion Cosa usate voi per versionare il codice? Subversion! Ok, vada per Subversion 12
  13. 13. Subversion:dasolo Finché lo usi da solo, tutto ok Figo poter navigare la storia delle tue modifiche! Ok i tag per le release Il diff con la precedente versione ora è più pratico! 13
  14. 14. Unadiscaricadicodicesorgente Faccio cose, ed ogni tot scarico quanto prodotto sul server Il commit delle 18:00 Sto versionando? Mah, non mi sembra granché diverso da prima 14
  15. 15. SubversionelaNONcooperazione Progetti “condivisi”, ma ci si lavora uno alla volta No cooperazione Versione 2.0 del team a scuola: ognuno lavora sulle sue cose Perché? 15
  16. 16. Chiprimacommitta,meglioalloggia 16
  17. 17. Subversioneglieffetti dell’update Lavoro finito, devi committare Commit rifiutato, devi fare update... Una strage… Subversion non consente di separare l’azione di commit da quella di integrazione delle modifiche altrui 17
  18. 18. Subversionelapauradell’update Alla fine l’update diventa una cosa che ti spaventa, che hai paura a fare Quando “funziona” al primo colpo è quasi un evento! (anche se comunque la colpa non è tutta di Subversion… Leggasi spaghetti code) 18
  19. 19. Subversioneiproblemidirete Bello il repo centralizzato, ma se sono offline non posso committare E non posso fare il checkout delle modifiche degli altri E così la prossima volta che dovrò farlo sarà un casino… 19
  20. 20. Pernonparlaredeibranch(sonounacapra) Come gestire la risoluzione di bug? Fare branch e poi merge era un attimino complesso (per me) Diverse cartelle per diversi branch Risultato: lavorare su due funzionalità in parallelo è quasi impossibile 20
  21. 21. Subversion:yunowork?! Ad un certo punto ti sale una carogna che nemmeno Germano Mosconi, Nonno Fiorucci e Lugaresi da Cesenatico messi insieme… 21
  22. 22. LarivoluzioneAgile Primi contatti tramite i colleghi di Brescia (grazie!!) Primo Agile Day (2011, Roma) “Ragazzi, c’è un nuovo modo di approcciare lo sviluppo software!” “Bello! Ma adesso non c’è tempo, abbiamo tante cose da fare... ” 22
  23. 23. L’arrivodelmessia Finalmente l’azienda ci concede qualche giornata con un coach agile Adesso che l’ha detto lui, tutti ci credono… Meglio che niente, l’importante è cominciare! 23
  24. 24. Ruoli,lavagne,storieetask Spezzare il lavoro in piccole parti si può! I “veci” diventano P.O. Storie e task Standup meetings Retrospettive? Mmm... NB: “vecio” = alpino più anziano ed esperto 24
  25. 25. Lepratiche“estreme” Io continuo ad esplorare TDD! BDD! XP? Mmm... Clienti sempre presenti? No. Pair programming? Ma dighet del bù?! (tradotto: “ma dici davvero?!”) 25
  26. 26. Bello,peròpota... Bella ‘sta storia del lavoro suddiviso in piccoli step Però con Subversion non riesco a metterlo in pratica: se capita un bug devo fare copie di cartelle e revertare per poterlo risolvere (o tutt’al più fare delle patch...) I branch? Non li so usare, sono una capra! 26
  27. 27. SaràmicaquestoessereAgile? Agile cosa se poi non posso passare facilmente da un lavoro ad un altro?! Non riesco a fare prove ed esperimenti (e a salvare o a lasciare a metà un lavoro per poi riprenderlo) Sto Subversion ha rotto... 27
  28. 28. HosentitoparlarbenediGit... “Git è meraviglioso!” “Risolve tutti i problemi!” “Le donne lo adorano!” 28
  29. 29. Bello‘stoGit,machecasino... 200 comandi e decine di opzioni File che spariscono al cambio branch Come faccio il diff tra 2 branch? Non ci capisco una mazza! 29
  30. 30. NonècomeSubversion,accidenti... Ogni volta che modifichi un file devi fare git add, ma perché?! Perché mi obbliga a scrivere il messaggio di commit? Reset --hard e --soft… Cosa sono, comandi NSFW? E poi c’è amend, e checkout -- 30
  31. 31. Hopauraaaaaaaaaaaaaaaaaaa!!1! Dai, forza e coraggio, impegnati un pochino… Si ma se sbaglio? Ok, o la va o la spacca: migro tutti i repository al lavoro 31
  32. 32. NonècomeSubversion,perfortuna! Finalmente i branch, che figata! Nuova funzionalità? Feature branch! Bug? No problem, branch dal master! Voi fare una prova? Branch usa-e- getta per spike/esperimenti Era poi così difficile?! 32
  33. 33. C’hounflowchemancoEraclito... Ed ora un buon workflow Feature branches (Github flow) Git flow (bello, bello in maniera assurda!) “Se committi su master ti taglio il dito mignolo, una falange alla volta…” (cit.) 33
  34. 34. Nelpiccoloperòpossoancoramigliorare... Sì, ma… I miei commit sono ancora un po’ troppo cicciotti ed infrequenti… Si può fare di meglio, o no? 34
  35. 35. Quellastoriadelpomodoro…Provaci! Lavora time-boxed! (sì ma io odio quei dannati ticchettii...) Un A.T., un pomodoro (o 2, o 3) L’importante è provare a fare fettine sottili... 35
  36. 36. Ziobobtivede! One change, one commit S.R.P. vale anche per i commit! git add -p is your friend, just in case... 36
  37. 37. Commit-messagedrivendevelopment Scrivi il messaggio di commit prima di iniziare a scrivere codice, ti sfido! (grazie Arialdo Martini!) 37
  38. 38. Cosìlasmettidiscriverestr… E scrivi messaggi significativi! La lunghezza dei messaggi è inversamente proporzionale alla dimensione dei commit (Più c’è roba -> meno sai cosa scrivere -> meno scrivi) 38
  39. 39. Unesempio 39
  40. 40. Bravobambino,faiicompiti! Appuntati tutti i test che dovranno passare su un foglio Falli uno ad uno, integrando la lista man mano che ne scopri di nuovi (ma non devi implementarli per forza subito, anzi!) Commit early, commit often 40
  41. 41. C’ècommitecommit... Separa commit di “valore” da commit di “clean-up” Riassumendo, a good commit is: - Frequent - Small - Decoupled - Meaningful Ma soprattutto, non committare codice che non compila, maledetto! 41
  42. 42. Commitcompulsivo-ossessivo Un commit per ogni step del TDD, ti sfido! (poi puoi/devi fare uno squash e crearne uno di maggior significato prima di pushare) 42
  43. 43. Eureka!Ognicommitèunamicroiterazione! Tratta ogni commit come fosse una sorta di micro-sprint! Set the focus: verifica l’obiettivo, elenca i test, scrivi il messaggio di commit Act: lavora! :) Reflect, adjust, restart: rifletti su quanto fatto e pianifica il prossimo commit/pomodoro 43
  44. 44. Primadiiniziarecolprossimo,svuotalamente... “Svuota la mente” ad ogni commit Scrivi! Anche la nostra RAM è limitata… "Almost everything will work again if you unplug it for a few minutes, including you." Anne Lamott 44
  45. 45. Serve DISCIPLINA!!! Allafineilsegretoèsemprequello... 45
  46. 46. Inconclusione… Git magari c’entra poco con tutto questo, ma ha avuto e sta avendo ancora per me dei side-effects estremamenti interessanti (ok, magari non proprio interessanti come quelli del sildenafil citrato...) 46
  47. 47. GitSideeffects: sharing Code Effort Knowledge → Collective Code Ownership → Feedback and “codeback” 47
  48. 48. GitSideeffects: Freedom Free to fail: you can do whatever you want in your branch, then throw it away Free to work everywhere Free to host your code wherever you want 48
  49. 49. Collaborating ANDCooperating Puoi lavorare al sicuro nel tuo recinto, ma in caso di necessità puoi condividere il tuo codice col mondo in pochi secondi Pull requests e Code reviews Team building 49
  50. 50. Collaborazione:insiemeperprodurrequalcosa Lavorare insieme con qualcuno Ma non necessariamente per lo stesso fine E nemmeno con lo stesso coinvolgimento “Io il mio lavoro l’ho fatto, arrivederci e tanti saluti” 50
  51. 51. Cooperazione:insiemeperlostessofine In etologia, termine utilizzato quando organismi della stessa specie condividono i benefici di un’azione svolta insieme. E’ finalizzata al conseguimento di un obiettivo comune. Esige che ciascuno dei ruoli selezioni solo ciò che è funzionale al raggiungimento di uno scopo condiviso. 51
  52. 52. Eusocialità L'eusocialità (dal greco eu, "buono", e "socialità") è il livello più alto di organizzazione sociale, che si realizza per alcune specie animali. Caratteristica di alcuni insetti, quali formiche, termiti e api; in essa la cooperazione, l’altruismo e la divisione del lavoro tra i membri della colonia si esprimono ai massimi livelli. L’uomo è eusociale? 52
  53. 53. Cosahocapito Un buon programmatore si vede (anche) da come tratta il proprio codice sorgente 53
  54. 54. Grazie:) 54 Domande? @JesusWasRasta www.packtpub.com

Editor's Notes

  • Chiedi!
    Chi usa Git?
    Chi altro?
  • Ecco come apparivo qualche anno fa
    “Come potete notare stavo leggendo specifiche, in perfetto stile waterfall”
    La mattina insegnante tecnico pratico di Informatica, e qualcosa di più
    Il pomeriggio avevo spazio, computer e tempo a disposizione per imparare a creare il sito della scuola
    Lavoravo da solo
    bellissimo periodo, un sacco di cose nuove da imparare
    autodidatta, pro e contro
    Versioning? Boh, manco sapevo cos’era
    Comunque avevo un processo di backup schedulato per copiare tutto ogni ora
    prima di modificare dei file mi copiavo la cartella per poter tornare eventualmente indietro
  • Problemi 0: era tutto sotto il mio controllo
    ero il “webmaster”, ai tempi andava di moda chiamarli così...
    Nessun necessità di collaborazione, scambio files, etc e quindi nessun conflitto
    gli unici conflitti erano con me stesso, quando mi dimenticavo di fare backup dei file prima di modificarli...
  • l’arrivo di altre persone nel “team”
    io mi occupavo del sito della scuola in ASP
    Claudio di cose in Flash
    Stefano di contenuti e grafica
    Tutti felici, tutti d’accordo
  • Fatto di tutto: corsi FSE, patente AICA
    Dopo 7 anni di insegnamento, decido di cambiare e di dedicarmi al lavoro di programmatore
  • azienda di software strutturata
    all’inizio avevano pensato di far lavorare anche me in COBOL!
    fortunatamente però nel CV avevo scritto anche .NET, e quindi mi hanno spostato su quel fronte
  • prendersi gioco dei cobolisti è sempre divertente
    in effetti c’hanno lavorato anche loro sul Millennium Bug, nel GesFar a caratteri; niente di catastrofico, ma l’anno a 2 cifre ce l’avevano anche loro...
    la prima volta con Donant ed il COBOL
    oddio, cos’è sta roba?!
  • COBOL: idea brillante, applicazione troppo ambiziosa!
    parte da un presupposto sbagliato: far capire ai manager la lingua dei programmatori
    Applicata male forse, ma l’idea era buona: BDD fa la stessa cosa!
    “COmmon Business-Oriented Language”, non è forse un BDD ante litteram?
  • Grace Hopper
    Una dei fondatori dell’informatica moderna, e sicuramente una delle donne più influenti insieme a (cerca nome delle altre 2)
  • cartella condivisa coi file sorgente
    “Chi sta toccando il barp0030?” “Chi è nelle tabelle?”
    “vecio”: alpino anziano e di grado superiore
  • Studiofarma ha due sedi, una a BG ed una a BS
    a BS usavano Subversion
    proviamo un po’ ‘sto Subversion
    Mi son fatto il mio serverino a BG
  • Finché fai le solite 4 cose tutto ok
    Bello poter navigare la storia, taggare le release, fare i diff

  • Era solo una sorta di backup remoto, una discarica dove buttare il proprio codice
    Commit una volta la giorno, o anche 2-3...

  • Collaborazione con il team di BS su un paio di progetti
    Alla fine era solo un posto comune dove prendere e mettere codice
    Molta poca collaborazione, anche qui ognuno lavorava alle sue cose
  • si cooperava poco anche perché gli udpate, infrequenti, potevano generare dei bei casini
    anche senza fare branch, l’update del codice da /trunk può essere un affare complicato
    qualcun altro ha fatto un grosso refactor, tu fai l’update (obbligatorio) prima del commit e salta fuori un puttananio…

    http://blog.tfnico.com/2010/10/geek-and-poke-versus-subversion.html
  • Operazione di commit e di push non separabili in Subversion
  • A volte l’update è un casino perché il software che hai scritto è un casino
    Né Subversion, né Git, né nessun altro strumento risolve problemi di errate scelte di design architetturale della propria applicazione...
    Spaghetti code
    Per risolvere i bug mi copiavo la cartella del repository attuale da una parte, facevo revert, e lavoravo al bug
  • I problemi del server centralizzato
    capitato poche volte a dire il vero, però è capitato
  • difficoltà ad andare oltre le solite quattro operazioni
    mia inesperienza: io ero e sono ancora una capra…
    Altro dovuto al fatto che creandoti diverse cartelle per diversi branch ti sminchia percorsi ed altro
  • Non finirò mai di ringraziare i colleghi che mi hanno aperto gli occhi
    Primo Agile Day, 2009
    Un nuovo modo di approcciare lo sviluppo
    Vedere, misurare, migliorare
    Se ne parla, ma i colleghi cobolisti nicchiano
  • una retrospettiva
    qualche (buon) consiglio
    e poi la stasi
  • I colleghi cobolisti più vecchi sono diventati P.O.
    A fatica, ma si abbozzano delle storie
    La suddivisione di storie in task
  • Nel frattempo io andavo avanti ad esplorare pratiche e metodi
    Ho cominciato a fare TDD, o almeno credevo…
    Test messi a posteriori, codice intestabile, soliti casini… Ma almeno avevo iniziato
  • Tutti ne parlano, proviamolo!
    Ah, però, non è proprio immediato…
    Qualche prova lì, qualche prova là, ma finché non inizio ad usarlo per davvero al lavoro non lo capitò mai!
  • fare i branch è molto semplice, è tutto il resto che è un casino...
    un sacco di comandi da imparare
    grafo aciclico?!
    decine di subcommands
  • yeee!!!
    insomma, all’inizio la cosa che più mi piaceva erano i branch
    ero innamorato, e lo sono ancora! dei branch
  • All’inzio andavo matto per i branch!
    GitFlow: sembra facile, ma non è difficile… :)
    Per una applicazione desktop come la mia, con numeri di release, beta version etc, è l’ideale
    Potrebbe andar bene anche per sviluppo mobile
    Forse un po’ overhead per applicazioni Web, ma branch “develop” può essere utile per test in ambaiente di staging
    Linux flow: lieutenant, blessed repository
    Git mantainer is Junio Hamano
  • forse posso fare di meglio…
    mi sono accorto subito che commit piccolo è meglio: quando devi mergiare dei branch è più semplice
    collaborazione con colleghi ancora scarsa, ma ai primi approcci ti accorgi subito che piccolo è meglio...
  • ho quindi cominciato a darmi delle regole!
    timeboxed ok, ma non sono ancora così bravo… Per ora i miei slot sono “a cipponi”, cerco comunque di stare nei 30-40 minuti
    da qui in poi elenco sfide attualmente in corso, non è che sono già così bravo...
  • altre regole
    no, quel typo che hai visto non c’entra nulla con quello che stai facendo, non correggerlo!
  • questa è la cosa più facile da applicare all’inizio!
    Ti permette di definire i limiti del tuo prossimo slot di coding con una certa precisione
    prenditi il tempo per farlo, verrà ripagato abbondantemente!
    Grazie Arialdo Martini
  • nel
  • Un buon messaggio di commit:
    50 lettere per la prima riga
    poi le altre righe di descrizione (max 72 char per riga)
    eventuali bullet point su funzionalità, modifiche, aggiunte
    Non dire quello che hai fatto, quello si capisce dal codice!
    Descrivi il problema che hai risolto, la funzionalità che hai implementato, il cambiamento che hai apportato
    Aggiungi informazioni accessorie utili, tipo n° di ticket se usi un sistema di ticketing
    Usa verbi al presente; il soggetto che parla non sei tu, ma il commit
  • un altra tecnica che ho utilizzato per aiutarmi a creare commit piccoli e significati
  • commit di cleanup NON aggiungono valore al software
    ad es.: pura formattazione di documenti, indentazione, etc
    rimozione di commenti
    rimozione di dead code, file inutilizzati o comittati per errore
  • qui è quasi da manicomio, ma può aiutarti a:
    esercitare la capacità di spezzare in piccoli commit
    mantenere il focus
  • A pensarci bene.. Ogni commit è un micro sprint!
    Tratta ogni commit come un micro-sprint!
    Set the point: prenditi 1 minuto per verificare l’obiettivo e scrivere il messaggio di commit Imposta in maniera chiara l’obiettivo del tuo commit Appuntati i test che dovranno passare, o l’obiettivo che ti poni di raggiungere
    Act: lavoraci
    Next: ed alla fine prenditi 5 minuti per pensare, mini retrospettiva, prendi appunti e prepararti al prossimo commit/pomodoro
    Meglio obiettivi piccoli che non occupano tutto il pomodoro che obiettivi che ti fanno sforare! Soprattutto all’inizio
  • Riflettete bene sull’ultimo punto della precedente slide: rifletti su quanto fatto e pianifica il prossimo commit/pomodoro
    Non dire “Ok, al prossimo pomodoro mi devo ricordare di fare quella cosa”, ma “svuota la mente” ad ogni commit
    La mente va lasciata libera per pensare, anche la nostra RAM è limitata…
    Scrivi i prossimi test che dovranno passare, quel che dovrai/vorrai fare nel prossimo slot di tempo
  • in una parola… Serve DISCIPLINA!!
  • Condividere lavoro usando branch remote
    Lavorare in parallelo a cose diverse
    Diffondere la conoscenza, favorire la collaborazione usando pull requests
    Confronto di idee, tecniche, punti di vista, modi di fare
    “codeback”: feedback su quanto fatto espresso tramite codice “di riasposta”
  • Condividere lavoro usando branch remote
    Lavorare in parallelo a cose diverse
    Diffondere la conoscenza, favorire la collaborazione usando pull requests
    Confronto di idee, tecniche, punti di vista, modi di fare
    “codeback”: feedback su quanto fatto espresso tramite codice “di riasposta”
  • Condividere lavoro usando branch remote
    Lavorare in parallelo a cose diverse
    Diffondere la conoscenza, favorire la collaborazione usando pull requests
    Confronto di idee, tecniche, punti di vista, modi di fare
  • Condividere lavoro usando branch remote
    Lavorare in parallelo a cose diverse
    Diffondere la conoscenza, favorire la collaborazione usando pull requests
    Confronto di idee, tecniche, punti di vista, modi di fare
  • qualcuno di voi ha mai lavorato in cantiere? O meglio, ha mai lavorato per davvero? :)
    ad es. in un cantiere con muratori, elettricisti, piastrellisti…
    E’ vero che alla fine si lavora tutti insieme per realizzare la costruzione
    ma ognuno con le sue libertà di azione
    ognuno con le sue priorità, modi di fare
    Mors tua, vita mea…
    “Io il mio lavoro l’ho fatto, mo so cazzi tua”
    un qualche accordo su obiettivi e valori comuni,
    il mettere insieme competenze individuali a vantaggio del gruppo.
  • Interdipendenza positiva,
    Responsabilità individuale,
    Interazione faccia a faccia,
    La co-decisione: richiede di saper gestire la sincronizzazione delle azioni
    Il coordinamento: si esprime nell’integrazione dei contributi espressi.
    La collaborazione: trova la sua criticità nella progressiva convergenza delle opinioni, delle scelte e dei valori dei partecipanti.
    Ritrovarsi insieme è un inizio, restare insieme è un progresso, ma riuscire a lavorare insieme è un successo. (Henry Ford)
    La cooperazione si basa sulla profonda convinzione che nessuno riesca ad arrivare alla meta se non ci arrivano tutti (Virginia Burden)
  • xxx

×