Arriva Chrome 60 abilitata la Touch Bar su macOS, nuove Paint Timing API e CSS font-display

Google ha pubblicato Chrome in versione 60 per Windows, Mac e Linux. Tra le aggiunte degne di nota, troviamo il supporto alla Touch bar nei nuovi modelli di Apple Macbook Pro, le API Paint Timing, il supporto alla direttiva CSS font-display e qualche aggiornamento delle API Credential Management. Come al solito, potete scaricare l’ultima versione da google.com/chrome oppure lasciare che il browser stesso si auto-aggiorni.

Chrome è indubbiamente molto più di un browser. Con oltre 1 miliardo di utilizzatori, è una delle maggiori piattaforme web che noi sviluppatori dobbiamo considerare. Infatti, con gli aggiornamenti costanti di Chrome, dobbiamo sempre essere sicuri di pubblicare progetti aggiornati con le sue caratteristiche per sfruttare al meglio nuove opportunità e avere UI sempre più affilate e soluzioni che favoriscano la UX.

Il primo aggiornamento di questa nuova versione 60, è naturalmente la Touch Bar su macOS. Si potrà customizzare il numero dei pulsanti ed avere delle scorciatoie personalizzare direttamente sulla barra.

Chrome ora supporta le Paint Timing API che ci permetterà di usare le metriche offerte dal sistema First Paint e First Contentful Paint, per capire meglio come funziona il load progressivo di una pagina ed ottimizzarne le performance.

Il successivo update, è quello che riguarda la regola CSS @font-face e font-display, permettendoci di specificare come e quando Chrome visualizza il testo mentre viene caricato il font. Fino ad ora Chrome ha atteso che il font venisse caricato  completamente per poi visualizzarlo, ma questo spesso a portato a caricamenti lunghi e a problemi di visualizzazione per i contenuti”above the fold”.

Curiosità: le taglie sui bug sono sempre presenti: per questa release Google ha sborsato 26.000 dollari!

Al prossimo aggiornamento.

Installare MongoDB su MAMP

Installare MongoDB può risultare un po’ difficile se si usa MAMP come ambiente di sviluppo in locale. Con questi pochi passaggi, però, sarà semplicissimo.

Installiamo brew

Se non l’avete già fatto, installate brew, che è un gestore i pacchetti per macOS, proprio come quelli più famosi yum o apt. Se avete già installato brew, andate al passo successivo. Aprite il terminale e lanciate il comando:

Se non avete installato XCode in precedenza, l’installazione può durare molti minuti.

Installiamo MongoDb

A questo punto, installiamo mongodb:

Non dimentichiamoci di creare la cartella /data/db, nella quale MongoDB conserverà tutti i dati.

Lanciamo MongoDB con il comando

A questo punto potreste avere problemi con la cartella /data/db. Vi consiglio di leggere questo articolo per risolvere il problema.

Aggiungiamo MongoDB a PHP su MAMP

A questo punto scegliamo quale versione già presente in MAMP dotare dell’estensione MongoDB. Navighiamo nella directory e scarichiamo dal php.net la versione corrispondente. Per questo esempio, abbiamo scelto la 7.0.15 già presente nell’installazione di MAMP. Una volta scaricata, estraete il contenuto della cartella in /Application/MAMP/bin/php/php7.x.x/include/php

Passiamo a configurare il pacchetto:

Installiamo l’estensione mongodb

Per prima cosa, dobbiamo settare $PATH per procedere con l’installazione dell’estensione vera e propria:

Installiamo finalmente il driver:

Configuriamo php.ini

Ora che l’estensione è correttamente installata, dobbiamo dire a PHP di utilizzarla. Per farlo, modifichiamo il file php.ini, che si trova nella cartella /Application/MAMP/conf/php7.x.x/php.ini e aggiungiamo, in fondo al file questa riga:

extension=mongodb.so

Fatto. Salvate il file e riavviate MAMP.

MongoDB su macOS non trova la cartella /data/db

MongoDB è uno dei più famosi e, permettetemi, gettonati engine NoSQL ad oggi presente nel panorama. La sua diffusione si deve anche alla facilità di installazione e gestione sui vari sistemi. In qualsiasi modo abbiate installato MongoDB, con brew o direttamente compilando i sorgenti, spesso ci troviamo ad un problema relativo alla directory dove MongoDB conserva i documents. All’esecuzione del comando mongod  che avvia l’engine, potremmo trovarci un errore simile:

Il sistema, in due parole, ci sta dicendo che la directory /data/db non esiste. Di default, MongoDB conserva qui i dati e per questo dobbiamo crearla. Vediamo come:

Attenzione a due cose, primo, lanciarla con i permessi di root (usando sudo ) e, secondo, far cominciare il percorso con /, quindi alla radice del nostro sistema.

Gestire i permessi di /data/db

A questo punto, rilanciando il comando mongod , potremmo trovarci difronte ad un nuovo problema: i permessi della cartella /data/db:

Quello che dobbiamo fare è accertarci che l’utente di sistema abbia i permessi di lettura e scrittura sulla directory. Per farlo, possiamo lanciare questi comando:

Per prima cosa, controlliamo quale utente è attualmente in uso In questo caso, lucamurante. Successivamente lo assegniamo come proprietario della directory /data/db.

Fatto. A questo punto, lanciamo nuovamente il comando mongod , che dovrebbe partire senza problemi.

 

 

Errore Git “Please commit your changes or stash them before you merge.”

Quando ci troviamo ad aggiornare la copia di lavoro locale con Git, usando il comando git fetch  o git pull , spesso ci troviamo di fronte all’errore [..] Please commit your changes or stash them before you merge.[..].

Git ci sta dicendo che il nostro lavoro locale è andato avanti rispetto a quello remoto e che ci potrebbero essere delle perdite. Come possiamo vedere, Git stesso ci consiglia di fare un commit o uno stash e riprovare ad eseguire il comando.

Se invece volessimo scartare le modifiche locali, e forzare la copia locale a sincronizzarsi a quella remote?  Possiamo usare una combinazione di comandi:

Attenzione: questo comando potrebbe farvi perdere le modifiche locali delle quali non avete fatto il commit!

Eseguendo questi comandi, prima scarichiamo dal server le ultime modifiche con git fetch , poi, portiamo il puntatore interno di Git allo stato precedente (cioè l’ultimo commit salvato) e poi effettuiamo una pulizia di tutti i file (e directory) non tracciati.

 

Gestire i rami (branch) in Bitbucket

Cosa sarebbe Git senza le ramificazioni? Esistono molti tool online per la gestione dei repository, e sicuramente BitBucket è uno dei più apprezzati. Quando lavoriamo sulla nostra macchina, però, dobbiamo sincronizzare i rami locali con i rami remoti per rendere tutto più efficace. Esistono due modi principali per creare dei branch in Git e poi sincronizzarli (eseguendo un push origin) con il server remoto di BitBucket. Vediamoli.

Creare un ramo in Bitbucket

  1. Andiamo nella pagina del nostro Repository, in alto clicchiamo su Create branch
  2. Dalla schermata successiva, selezionare il ramo di partenza (solitamente, master) e il nome del nuovo ramo, clicca su Create
  3. A questo punto il branch, in remoto, verrà creato. La nostra copia locale del progetto, però, non lo sa ancora. Sincronizziamola con un git fetch :
  4. Proviamo ora a cambiare un file di lavoro e ad eseguire un git push :
  5. Fatto.

Creare un ramo locale

La seconda opzione è quella di creare un branch in locale e successivamente eseguire un git push. Ovviamente il repository su cui state lavorando deve già essere associato ad un repository BitBucket.

  1. Per prima cosa, creiamo il ramo:
  2. Spostiamoci sul ramo appena creato:
  3. A questo punto, proviamo a cambiare qualche file ed effettuiamo un commit , seguito da un git push :
  4. Fatto.

Verifichiamo che il branch ci sia

Dalla pagina del nostro Repository su BitBucket, verifichiamo che il ramo appena creato sia presente tra i branch:

Ti interessa Git? Consulta la nostra guida a Git.

Come eseguire un backup FTP con wget

Spesso abbiamo la necessità di spostare un sito o un progetto web tra due server o scaricarlo in locale. Per farlo, potremmo usare un comune client FTP e scaricare manualmente i file presenti sul server. Esiste però una via più comoda da utilizzare via shell di comando, utilizzando il comando unix wget .

Molto frequentemente uso questa procedura per scaricare un sito in produzione da una macchina di test. Insomma, è utile anche per effettuare lo spostamento di un progetto web tra due server remoti. È possibile farlo in vari modi, ma con wget  l’operazione risulta particolarmente semplice.

Anatomia del comando

Vediamo la sintassi del comando:

Innanzitutto vediamo che è fondamentale usare l’opzione -m  che dice al comando wget di prepararsi ad un’operazione di mirroring. Questo significa che wget applicherà automaticamente le seguenti opzioni:

  • recursion, cioè scenderà in profondità in ogni directory che incontrerà
  • timestamping, rispetterà la data di modifica dei file, cioè la riporterà sul nuovo server esattamente come l’ha trovata
  • relative links, cioè seguirà i link simbolici all’interno del filesystem
  • inf, cioè eseguirà infiniti tentativi di ricorsione
  • –no-remove-listing, non cancellerà il file temporaneo .listing  trovato sul server

Se ad esempio avessimo questi dati:

Username: admin

Password: 12345678 (non usatela davvero, per favore)

Server: ftp.miodominio.it

Il comando diventerebbe

Fatto. Vedrete a video il download di ogni singolo file.

Password con caratteri speciali

Se la password del server FTP contiene caratteri speciali, il comando potrebbe venire troncato e restituirvi un errore come questo:

Come spesso accade nelle password auto-assegnate, alcuni caratteri vengono letti dall’interprete come “segni particolari” e non come semplici caratteri.  Per risolvere questo problema è possibile usare la forma estesa del comando base. Ipotizziamo di avere un #  tra i caratteri della password abcd#ef :

 

Disponibile l’aggiornamento WordPress 4.7.5

La community di WordPress ha reso disponibile l’aggiornamento targato 4.7.5. Si tratta di una security release e quindi vi incoraggiamo fortemente ad eseguire subito l’aggiornamento. La versione precedente, la 4.7.4 di WordPress aveva alcune falle di sicurezza, tutte risolte:

  • Non gestiva correttamente la validazione HTTP
  • Non gestiva correttamente i meta dati nelle API XML-RPC
  • Era vulnerabile alla Cross Site Request Forgery (CSRF)
  • Se si provava a caricare file pesanti, poteva essere sfruttato un bug di cross-site scripting (XSS)

In più, ci sono 3 fix di mantenimento.

Come vi ho già suggerito, aggiornate prima possibile il vostro WordPress.

Per scaricare questo aggiornamento scaricate direttamente WordPress 4.7.4 

Oppure andate in Bacheca → Aggiornamenti e cliccate su “Aggiorna ora”. Se avete abilitato gli aggiornamenti automatici, questo update è in arrivo su tutti i sistemi.

Spostare dei commit su un nuovo ramo in Git

Molto spesso ci troviamo davanti a questo tipo di problema: per errore o inesperienza, eseguiamo dei commit  mentre ci troviamo sul ramo sbagliato. Come facciamo a spostare gli ultimi commit su un nuovo ramo o su un ramo preesistente?

Ci troviamo in una situazione analoga a questa:

Dove gli ultimi due commit, cioè af65fcd  e e577582  sono quelli da spostare su un branch diverso. Vogliamo, cioè arrivare ad una situazione analoga a questa:

 

Muovere commit su un nuovo ramo

Nel caso volessimo spostare gli ultimi commit  su un nuovo branch , l’operazione è abbastanza semplice e non dovrebbe dare problemi.

Il comando centrale di questa procedura è

che dice sostanzialmente di spostarsi indietro di 2 commit: possiamo indicare il numero di commit che ci serve scavalcare. In alternativa, possiamo indicare l’hash del commit, se lo conosciamo, ad esempio:

Non perderemo alcun commit, semplicemente li abbiamo staccati e associati al ramo nuovoramo.

Muovere commit su un ramo esistente

Il metodo precedente è basato sul fatto che nuovoramo è appunto un ramo creato per l’occasione. Ma se volessimo spostare gli ultimi n commit su un ramo già esistente?

In questo caso dovete effettuare prima un git merge  tra il ramo e il master  prima di eseguire il git reset  come nell’esempio precedente. Se non lo fate perderete il vostro lavoro. Vediamo come eseguire questa procedura:

 

Perché ogni sito ha bisogno di HTTPS

Innanzitutto, cosa significa per un sito usare HTTPS anziché il buon vecchio HTTP? In sostanza ci dice che i dati tra noi e il server viaggiano protetti da SSL (Secure Socket Layer) o dal più recente e affidabile TLS (Transport Layer Security). Se non conoscete o state approfondendo l’argomento, diamo uno sguardo al perché usare HTTPS è così importante.

Quando un utente visita un sito ed usa la versione HTTPS, il vostro browser sta chiedendo al server la versione sicura di quel sito. Detto brevemente, il browser sta controllando l’esistenza di un certificato SSL/TLS per quella connessione. Questo certificato viene garantito da un ente terzo, chiamato Certificate Authority (CA) che fa appunto da garante, dicendo “questo sito è verificato, ed è sicuro”. Solo a questo punto la connessione viene stabilita con successo. La connessione è criptata: nessuno può intercettarla o decodificarla. Anche il vostro ISP, il fornitore della vostra connessione non può: in poche parole può vedere lo scambio di dati tra voi e il server dove risiede il sito, ma non può decifrare il contenuto dei pacchetti dati.

Se il sito accetta connessioni HTTPS, ma non c’è un certificato con un CA a fare da garante, il browser vi avvertirà con un messaggio come questo:

[immagine connessione non sicura]

(Sono sicuro che l’abbiate già visto!) Il browser vi sta dicendo proprio questo: c’è una connessione su protocollo HTTPS ma il certificato non c’è oppure non è garantito da nessuno (o magari è self-signed, cioè auto-generato). Per questo motivo vi invita a non continuare, anche se potreste scegliere di andarecomunque nell’area non sicura.

Adesso che abbiamo un’idea più precisa di cosa accade, andiamo a capire l’importanza di avere un sito protetto da HTTPS. Dovremmo sempre proteggere i nostri siti con HTTPS, anche se non si occupano della gestione di dati sensibili – come per un ecommerce, ad esempio – per diversi motivi.

Posizionamento nei risultati (SEO)

Nel 2014 Google lanciò la campagna HTTPS everywhere con la quale affermò chiaramente che la presenza del protocollo influenza positivamente la posizione del nostro sito fra i risultati di ricerca. Parliamo di qualche anno fa, ma oggi, col senno di poi, possiamo affermare che Google ci è riuscita, dato che l’uso di HTTPS è notevolmente aumentato. Ovviamente non sapremo mai come e quanto ciò incide, non guarderemo mai nell’algoritmo di Google, ma sappiamo che è un indicatore e non vale più la pena essere penalizzati per così poco, non trovate?

Gli utenti si sentono al sicuro

Anche questo motivo ricade nel regno di Google. Secondo un post recente, il browser Chrome a partire dalla versione 56  segnalerà ogni pagina che colleziona dati sensibili (login, registrazione, carte di credito) come non sicura se non è protetta da HTTPS.

Cosa succederà alla confidenza che gli utenti hanno nel nostro sito? Nelle future release probabilmente Chrome segnerà con “Non sicuro” qualsiasi sito non fosse protetto da protocollo HTTPS, così come annunciato anche da Firefox, che segnalerà anche gli stessi campi dei form come non insicuri.

Così, anche se il sito non raccoglie dati sensibili o privati, è una buona scelta installare un certificato SSL per guadagnare la fiducia di nuovi e vecchi utenti.

Gli utenti sono (davvero) al sicuro

Ma l’HTTPS fa molto di più, perché rende realmente sicura la connessione per i nostri utenti. Come abbiamo citato all’inizio di questo articolo, i dati che viaggiano tra utente e server sono protetti e irriconoscibili. Questo vale soprattutto per i form, come quello di registrazione o login, tutto criptato per la massima sicurezza. Una bella garanzia di fiducia che offriamo a chi usa i nostri servizi.

Come iniziare con l’HTTPS

La cosa più semplice ed immediata è acquistare un certificato SSL da installare sul nostro hosting condiviso o dedicato contattando direttamente una compagnia di hosting, come ad esempio il nostro partner b27. Se avete un grosso sito la migrazione può essere un po’ più complesso della semplice installazione, ma non difficile come può sembrare!

Se invece siete utenti esperti e sapete come installare e configurare in autonomia un certificato SSL, Let’s Encrypt può fare al caso vostro: non offre assistenza diretta m vi fornirà gratuitamente un certificato da rinnovare ogni 90 giorni. Per iniziare può andare più bene.

 

10 anni di Git: un’intervista al creatore Linus Torvalds

Più di 10 anni fa, la community di sviluppo del kernel Linux si trovò dinanzi un problema: il sistema di controllo delle versioni BitKeeper aveva interrotto la loro licenza e nessun altro sistema andava più bene per i loro bisogni. Linus Torvalds, il mitico creatore di Linux, prese la situazione in mano e sparì per un intero weekend per riemergere la settimana seguente con Git. Oggi Git è sicuramente il sistema più usato e richiesto nella gestione delle versioni.

Noi abbiamo dedicato un’intera e completa guida a Git e sul come gestire le versioni del software. Se siete qui per imparare, dategli uno sguardo!

Per celebrare questo traguardo, il sito Linux.com ha intervistato Linux Torvalds chiedendogli qualche storia behind-the-scenes e in generale cosa ne pensa dello stato attuale del progetto. Noi vi riportiamo qui questa intervista, tradotta integralmente.

Perché hai creato Git?

Non ho mai davvero pensato e voluto realizzare un sistema di gestione dei sorgenti, e penso che sia la cosa meno interessante in tutta l’informatica (con la possibile eccezione dei database). Ho odiato tutti i sistemi profondamente. Ma poi BitKeetper è arrivato e ha cambiato questa visione che avevo del controllo di versione. BitKeeper ha la maggior parte delle funzioni necessarie e in più offre il merge tra il repository locale e quello remoto ed è davvero una gran cosa. Il fatto che il controllo fosse distribuito ha fatto sparire di colpo i vecchi problemi che avevano gli altri sistemi e tutta la questione del “chi può cambiare cosa”. Mostrò che tutto questo poteva essere evitato semplicemente facendo lavorare ognuno su un repository locale. Certo, aveva i suoi problemi: c’erano alcune scelte tecniche che causavano problemi (rinominare i file era terribile), ma il principale lato negativo era il fatto che siccome non era open source, c’erano un sacco di persone che semplicemente si rifiutavano di usarlo. Così, mentre diversi sviluppatori usavano BitKeeper (perché è gratuito per i progetti open source), non era usato da altri. Ci ha molto aiutato nello sviluppo del kernel, ma resistevano piccoli punti da risolvere.

Si arrivò a un punto quando Tridge (Andrew Tridgell) cominciò a fare il reverse-engineering del (relativamente) semplice protocollo di BitKeeper, cosa che era contro le norme d’uso del software. Ho passato diverse settimane (ma a me sono sembrati mesi) provando a fare da mediatore tra Tridge e Larry McVoy (il capo di BK, ndr) ma alla fine la cosa non funzionò. Così ad un certo punto ho deciso di non poter continuare a utilizzare BK, ma neanche di voler tornare ai tempi bui pre-BK. Tristemente, al tempo, anche se c’erano altri sistemi che provavano ad implementare la logica del software distribuito, nessuno lo faceva davvero bene, soprattutto in remoto. Anche le performance che volevo nel trasferimento dati in remoto non erano soddisfacenti, e inoltre ero preoccupato dell’integrità del codice. Così ho semplicemente deciso di scrivere un sistema nuovo.

Qual è stato il tuo approccio? Sei stato sveglio tutto il weekend o l’hai scritto in orario di lavoro?

Heh. Puoi vedere da te come ha preso forma guardando la storia del repository di Git stesso. C’è voluto circa un giorno per arrivare ad essere “self-hosted” così da poter usare Git per sviluppare.. Git. Il primo giorno quindi, i commit erano, diciamo, nascosti, ma tutto era già lì. Ho lavorato maggiormente durante il giorno, ma se guardate ci sono due istantanee fatte verso la mezzanotte e un paio alle 2. La parte più interessante però è sul quanto velocemente ha preso forma; il primo vero commit nel repository non contiene molto codice, ma poteva già eseguire il commit di se stesso. Il vero trucco però è sul come organizza i dati.

Ho provato a stressare il sistema fin tanto che prendeva forma in circa 10 giorni (a quel punto ho provato a fare il mio primo commit del *kernel*), ma non sono finito nella pazzìa del programmare senza sosta. Infatti la prima versione è abbastanza piccola, non è composta da molto codice, perché tutto dipendeva dal fatto che l’idea base fosse buona. Ci avevo pensato su per un po’ prima che l’intero progetto iniziasse. Avevo visto i problemi che altri avevano. Avevo visto quello che volevo evitare.

Ha raggiunto le tue aspettative? Come sta funzionando oggi secondo te? Ci sono limitazioni?

Sono molto contento di Git. Funziona notevolmente bene per il kernel e sta ancora soddisfacendo tutte le mie aspettative. Quello che mi sembra interessante è il modo in cui è stato adottato da così tanti altri progetti. Sorprendentemente veloce. C’è molta resistenza nel cambiare il sistema di controllo della versione, basta guardare quanto tempo CVS e anche RCS sono rimasti in giro, ma ad un certo punto Git ha preso il sopravvento.

Quale pensi sia il motivo di questa grande diffusione?

Penso che molti altri si siano sentiti frustrati dagli stessi problemi che mi hanno fatto odiare SCM e, sebbene ci siano stati molti progetti che tentassero di risolvere uno o due piccoli casi che facevano impazzire la gente, non c’era veramente niente di simile a Git che davvero affrontasse di petto questi problemi. Anche se molti non capirono l’importanza della parte riguardante la logica “distribuita” (e molti la contrastavano), una volta che si resero conto che ciò consentiva backup semplici e affidabili e che tutti potevano avere i propri repository di test privati senza preoccuparsi di alcuna politica sui permessi del “chi fa cosa”,  adottarono Git senza voltarsi indietro.

Git durerà per sempre o prevedi un altro sistema fra altri 10 anni? Sarai ancora tu a scriverlo?

Non lo scriverò io, no. E forse vedremo qualcosa di nuovo in dieci anni, ma vi garantisco che assomiglierà sicuramente a Git. Non che Git sia perfetto, ma ha realmente aggiustato tutti i problemi basilari degli altri sistemi.

Nessuna falsa modestia 😉

Perché Git funziona così bene per lo sviluppo di Linux?

Beh, è ​​stato ovviamente progettato per il nostro flusso di lavoro, quindi è parte di esso. Ho già citato molte volte l’intera parte “distribuita”, ma vale ripeterla. È stato anche progettato per essere abbastanza efficiente per un progetto grandicello come Linux, ed è stato creato per fare cose che la gente considerava “difficili” prima di Git – perché queste sono le cose che anche *io* faccio ogni giorno.

Giusto come esempio: il concetto di “fusione” tra rami viene generalmente considerato qualcosa di complesso e difficile nella maggior parte degli SCM. Si dovevano pianificare i merge con calma, perché potevano essere distruttivi. Questo per me non è accettabile, dal momento che quotidianamente faccio decine di merge e il problema a cui devo dedicarmi è testare il risultato del mio codice, non perdere tempo sul merge stesso. La “parte Git” del mio lavoro dura giusto un paio di secondi, di solito ci vuole di più solo per scrivere la spiegazione del merge. Quindi Git è stato fondamentalmente progettato e scritto per i miei requisiti, e si vede.

Molte persone sostengono che Git è solo per persone super intelligenti. Anche Andrew Morton ha detto che Git è “espressamente progettato per farti sentire meno intelligente di quello che tu pensi di essere.” Qual è la tua risposta a questo?

Penso che sia stato vero in passato, ora non più. Ci sono diverse ragioni per le quali le persone si sono sentite così, una sola però è rimasta: “puoi fare le cose in tanti modi”.

Puoi fare molte cose con Git perché molte funzioni sono state create per lavorare insieme ad altre persone. Git comprende un set di strumenti molto potenti e spesso all’inizio ci si può sentire sopraffatti, però questo offre anche il vantaggio che la stessa operazione si può fare in modi diversi, e tutti “funzionano”. Generalmente il modo migliore di imparare Git è iniziare con comandi molto semplici e non guardare neanche le altre funzioni finché non si è abbastanza bravi con le basi.

Ci delle ragioni storiche per le quali Git è stato spesso considerato complicato. Una di queste è che è stato davvero complicato. Le persone che hanno iniziato a usare Git molto presto (per lavorare sul kernel), hanno dovuto apprendere davvero un insieme molto scomodo di script per far funzionare tutto. Questo perché tutto lo sforzo all’inizio fu indirizzato per far funzionare “la tecnologia di base” e poco per renderlo semplice. Così Git (meritatamente) si è fatto una brutta fama all’inizio, perché dovevi sapere esattamente cosa stavi facendo. Tutto questo è stato vero soltanto per i primi sei mesi, forse un anno.

L’altro grande motivo che ha fatto pensare che Git fosse difficile è che Git è molto diverso dagli altri sistemi. Ci sono molti sviluppatori che hanno usato CVS (o altri) per un decennio o due. Git non è CVS, neanche lontanamente. I comandi sono diversi. Non abbiamo neanche immaginato di farlo simile a CVS, anzi il contrario. E se hai usato un sistema CVS-like per molto tempo, è ovvio che Git possa apparirti complicato e stranamente diverso. Perché le mie versioni sono basate su un HEX da 40 caratteri e non su una stringa tipo “1.3.1.”?

Git però non è “inutilmente diverso”. Le differenze sono necessario. È solo che ha fatto alcune persone pensano che sia più complicato di quanto lo sia perché provengono da un background molto diverso. La fortuna è che là fuori molti programmatori non hanno neanche mai usato CVS, e il loro prima sistema è proprio Git.

Pensi che lo sviluppo del kernel Linux sarebbe potuto crescere così rapidamente senza Git? Perché sì o perché no?

Beh, “senza Git” di sicuro. Ma avrebbe richiesto che qualcun altro, prima o poi, avesse creato qualcosa di equivalente: un sistema di controllo delle versioni distribuite efficace proprio come Git. Avremmo sentito certamente il bisogno di qualcosa *come* Git.

Qual è la tua opinione su GitHub?

GitHub è un eccellente servizio di hosting. Non ho niente contro. Ora, le lamentele che ho avuto riguardo GiHub come piattaforma di sviluppo- ovvero fare commit, pull, tenere traccia dei bug, etc. – sono che non funziona molto bene per tutti. Non è nemmeno vicino, purtroppo, neanche per il kernel: è troppo limitato.

Questo è in parte a causa del modo in cui il kernel viene sviluppato, ed in parte è dovuto al fatto che certe interfacce di GitHub incoraggiano i cattivi comportamenti. I commit fatti su GitHub, per esempio, hanno messaggi scritti male, proprio perché l’interfaccia non blocca questa prassi. Fixando questi dettagli il tutto lavorerà sicuramente meglio, ma difficilmente sarà  appropriato per il kernel linux.

Qual è l’utilizzo più interessante che hai visto per Git e/o GitHub?

Sono contento che abbia reso così facile avviare un nuovo progetto. L’hosting è sempre stato un punto ostico, e con Git e GitHub è quasi banale creare un piccolo progetto dal nulla. Non importa quale sia il progetto: quello che conta è che tu lo puoi fare.

Hai progetti laterali, attualmente? Magari un software ancora più brillante che dominerà lo sviluppo del software per gli anni a venire?

Niente di programmato. Ma vi terrò aggiornati.