Source

svn-slide / index.html

Full commit
<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=Edge;chrome=1">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>Galrey presentation system</title>
    <link rel="stylesheet" type="text/css" href="galrey/themes/default.css">
    <link rel="stylesheet" type="text/css" href="theme.css">
    <script src="galrey/bootstrap.js"></script>
    <script>

    Galrey.options = {
      dimensions: "auto",
      transition_ms: 300,
      autoplay_ms: 3000,
      autostart: false,
      message_ms: 500,
      mouse_click: 'smart',
      numbers: true,
    };

    Galrey.fonts = {
      google: {
        families: [ 'Tangerine', 'Cantarell' ]
      },
      custom: {
        families: ['Droid Sans'],
        urls: ['galrey/fonts/fonts.css']
      }
    };

    </script>
  </head>
  <body>

    <div id="galrey">

      <header>Versionamento del codice</header>
      <footer>By Christian &ndash; &lt;christian@nohup.it&gt;</footer>

      <div class="galrey_slides">

        <article>
          <section>
            <h1 class="shout galrey">Sistemi di versionamento</h1>
            <h1>Introduzione</h1>
            <p>La presentazione è stata realizzata con <a href="http://www.galrey.com/"><strong>Galrey</strong></a>.</p>
            <p>Questa presentazione contiene un compendium di cos'è un sistema di versionamento, come funziona e perché usarlo, con il fine che diventi un <strong>must have</strong>.</p>
          </section>
        </article>

        <article>
          <section>
            <h1><span class="galrey">Sistema di versionamento</span></h1>
            <ul>
              <li>Cos'è</li>
              <li>Come funziona</li>
              <li>Perché utilizzarlo... sempre! :-)</li>
              <li>Glossario</li>
              <li>Subversion, tool di utilizzo</li>
              <li>Non solo SVN!</li>
            </ul>
          </section>
        </article>

       <article>
          <section>
            <h1>Cos'è</h1>
            <ul>
                <li>Mantiene traccia di tutti i cambiamenti del codice sorgente e della documentazione.</li>
                <li>Mantiene traccia di chi ha effettuato la modifica, su quali file e un log di descrizione del lavoro fatto.</li>
                <li>Mantiene un repository centrale dove vengono salvate tutte le modifiche e le versioni.</li>
                <li>Permette il lavoro in team su uno stesso progetto o un insieme di file.</li>
                <li>E' un sistema remoto, quindi è gestito su un'altra macchina server</li>
                <li>Se opportunamente configurato può avvertire via email gli altri sviluppatori con un riassunto di quanto fatto.</li>
            </ul>
          </section>
        </article>

       <article>
          <section>
            <h1>Perché utilizzarlo... sempre! :-)</h1>
            <ul>
                <li>Permette di lavorare facilmente su uno stesso file ed evita duplicazioni, come ad esempio
                    una varietà di file con '_', '.old' o addirittura una serie di directory con il backup giornaliero.</li>
                <li>Evita la frase 'non posso modificare quel dato file perché un altro lo sta modificando...'</li>
                <li>Dà la possibilità di vedere la storia del singolo file, tornare indietro e ripristinare una versione precedente.</li>
                <li>Facilita l'introduzione di un altro membro nel team di sviluppo, perché si troverà lo storico del progetto e l'ulitma versione sviluppata.</li>
                <li>Le modifiche vanno 'committate' se non rompono l'attuale progresso dello sviluppo del codice, ad es bug conosciuti, codice non funzionante ecc...</li>
                <li>Le commit vanno fatte spesso se ci sono più attori in gioco e si ha bisogno di vedere cosa sta succedendo. (un es è server http che fa update ogni x tempo)</li>
                <li>Anche se si lavora soli è buona abitudine utilizarlo, si può tornare indietro!</li>
            </ul>
          </section>
        </article>

       <article>
          <section>
            <h1>Pragmatic Tips</h1>
            <ul>
                <li>Utilizzare delle <strong>regole</strong> per scrivere codice, <strong>coding standard</strong>; es. dove metto le parentesi?</li>
                <li>Utilizzare un <strong>vocabolario</strong> di termini comuni; es. per evitare di chiamare <em>box</em> quello che il cliente chiama <em>modulo</em>.</li>
                <li>Conoscere bene l'editor in uso e configurarlo con le <strong>regole di coding-standard</strong> comuni.</li>
                <li>Committare spesso e avvertire gli altri della commit è una buona pratica per non avere conflitti, se non si ha un avviso via email.</li>
                <li>Dove svn non arriva, c'è bisogno dell'intervento dell'utente.</li>
                <li>Le commit non dovrebbero rompere il progetto.</li>
           </ul>
          </section>
        </article>

       <article>
          <section>
            <h1 class="message">Pragmatic Tips (continua)</h1>
            <ul>
                <li>Il copia incolla furioso e la duplicazione di codice sono il male, questi pattern vanno usati con parsimonia e
                    soprattutto con la coscienza di sapere quello che si sta facendo.</li>
                <li>Attenzione ai generatori di codice, talvolta fanno magie nere (es. scaffolding)</li>
                <li>Il vostro codice, oltre che capito da voi, devono capirlo anche gli altri sviluppatori.</li>
                <li>Conoscere il linguaggio non è solo conoscere la sintassi.</li>
                <li>Utilizzare al meglio gli strumenti di lavoro.</li>
                <li>Per progetti di una certa dimensione, avere un sistema di integrazione continua è importante.</li>
                <li><strong>Comunicare</strong> è la chiave per non avere conflitti e vivere felici :-)</li>
            </ul>
          </section>
        </article>

        <article>
          <section>
            <h1>Glossario</h1>
            <ul>
              <li><em>repository</em>: identifica il server dove vengono archiviati i file e le versioni.</li>
              <li><em>working copy</em>: è la copia locale, quindi sul proprio pc di lavoro, dove effettivamente vengono apportate le modifiche.</li>
              <li><em>revisione</em>: numero assegnato dal sistema ad ogni commit.</li>
              <li><em>HEAD</em>: l'ultima versione/revisione nel repository, è uno shortcut.</li>
              <li><em>checkout</em>: scarica il repository in locale e lo si fa solo una volta.</li>
              <li><em>commit</em>: manda al repository le modifiche effettuate, solitamente va anche messo un messaggio per il log.</li>
              <li><em>update</em>: porta l'HEAD nella working copy; va effettuata al mattino e a ogni modifica nel repository se si lavora nello stesso gruppo di file, per non incorrere in conflitti e per agevolare il merge.</li>
            </ul>
          </section>
        </article>

        <article>
          <section>
            <h1 class="message">Glossario (continua)</h1>
            <ul>
              <li><em>add</em>: aggiunge uno o più file alla working copy; andrà fatto un commit per rendere effettive le modifiche.</li>
              <li><em>remove</em>: rimuove uno o più file dalla working copy; andrà fatto un commit per rendere effettive le modifiche.</li>
              <li><em>rollback</em>: ritorna ad una versione precedente per uno o più file o l'intero repository.</li>
              <li><em>merge</em>: l'azione che unisce le modifiche su un file, solitamente il sistema le fa in automatico, altrimenti richiede l'intervento dell'utente (conflict).</li>
              <li><em>conflict</em>: è il caso che si genera quando il sistema di versionamento non riesce a unire i file da solo e serve l'intervento dell'utente.</li>
              <li><em>diff</em>: permette la visione delle differenze tra due versioni di un file o gruppo di file o revisione.</li>
              <li><em>ignore</em>: permette di ignorare un file o gruppo di file/direcotry che non devono essere versionate.</li>
            </ul>
          </section>
        </article>


        <article>
          <section>
            <h1 class="message">Glossario (continua)</h1>
            <ul>
              <li><em>svn</em>: comando base, anche abbreviativo di subversion.</li>
              <li><em>trunk</em>: è la directory che contiene la revsione attuale e dove solitamente si fanno i commit.</li>
              <li><em>tags</em>: è una directory sotto versionamento che contiene una revisione taggata, quindi con specifiche funzionalità definite e rilasciate.</li>
              <li><em>branches</em>: è una directory dove uno sviluppatore può lanciarsi in modifiche spregiudicate del progetto e vedere se poi portarle in trunk.
              Serve per sviluppare certe funzionalità che possono anche non essere mai messe in produzione.
              Per portare in trunk, serve fare un merge, ma qui entra in gioco <a href="http://www.orcaware.com/svn/wiki/Svnmerge.py">svnmerge</a>.
              Solitamente i branches sono utilizzati quando il progetto richiede tante funzionalità e i rilasci devono essere stabili. Un esempio sono la maggior parte del software open source.</li>
            </ul>
          </section>
        </article>

        <article>
          <section>
            <h1>Subversion, tool di utilizzo</h1>
            <ul>
              <li>Per Windows c'è <a href="http://tortoisesvn.tigris.org/">Tortoise svn</a> e tutti comandi del glossario sono gestiti comodamente dal tasto destro del mouse.</li>
              <li>Esistono tools cross platform, ad esempio <a href="http://rapidsvn.tigris.org/">RapidSVN</a>.</li>
              <li>Nei sistemi unix like è possibile interagire direttamente con il repository lanciando comandi dalla shell.</li>
              <li>Esistono plugin per i maggiori editor/ide che integrano le funzionalità precedentemente descritte, a pagameto e liberi.</li>
              <li>Risorse online, il sito di <a href="http://www.tigris.org/">Tigris</a>, gli sviluppatori di subversion.</li>
              <li>Se volete giocare un po' andate su <a href="http://sourceforge.net/">sourceforge</a> oppure su <a href="http://code.google.com/hosting/">google code</a>.</li>
            </ul>
          </section>
        </article>

        <article>
          <section>
            <h1>Non solo SVN!</h1>
            <ul>
              <li>Nel corso degli anni i sistemi di versionamento si sono evoluti, sono più efficienti e permettono di avere una distribuzione maggiore del codice versionato.</li>
              <li>Sistemi di versionamento distribuiti, tra i più usati sono <a href="http://git-scm.com/">Git</a> e <a href="http://mercurial.selenic.com/">Mercurial</a>.</li>
              <li>Repository remoti, se volete far qualche prova: <a href="https://bitbucket.org/">bitbucket</a>, <a href="https://github.com/">github</a>.</li>
              <li>Un po' di storia e altre info su wikipedia: <a href="http://en.wikipedia.org/wiki/Revision_control">revision control</a>.</li>
            </ul>
          </section>
        </article>


        <article>
          <section>
            <h1>Risposte?</h1>
            <p>Graze per l'attenzione!</p>
            <p>Armatevi di PC che ora passiamo all'azione!</p>
            <!-- <p>E se incontri del genere diventassero frequenti una volta al mese, o quando siamo tutti riuniti, dove chi ha voglia presenta qualcosa che ha visto provato o vuol far vedere come ha sviluppato una certa cosa?</p> -->
          </section>
        </article>

      </div> <!-- slides -->

    </div> <!-- galrey -->

  </body>

</html>