Da SVN a GIT

Git-Icon-1788C

Oggi ho trasferito l’ultimo repository SVN su GIT.
E’ arrivato quindi il momento di salutare SVN! Quando passai da CVS a SVN fu un salto di qualità, tutto appariva più semplice ma “meccanicamente” i due funzionavano allo stesso modo. Grazie quindi SVN!

Il passaggio a GIT invece all’inizio è stato davvero duro, è completamente diverso. Tutte le certezze acquisite negli anni su SVN crollarono, senza considerare poi che con qualche operazione “azzardata” cancellai anche i primi commit! Più volte ho pensato di tornare indietro. Entrare nei meccanismi di GIT non è facile e soprattutto tocca tornare a studiare. Però poi, quando entri “nella testa” di GIT (o meglio, di Linus Torvalds che l’ha creato nel 2005), entri in un altro mondo e non torneresti più indietro!

Su SVN prima di fare un commit ci pensi giorni, controlli e verifichi ogni cosa più volte perchè un commit non è cosa da poco. Su GIT ne fai uno ogni 2 ore. Lo stesso vale per i branch: crearne uno su SVN vuol dire che si sta iniziando qualcosa di grosso, una nuova release strutturalmente diversa. In GIT un branch lo apri anche solo per fixare un bug.

In GIT il repository è sempre con te, c’è tutta la storia. Ogni commit, tag, branch è lì con te, in locale. Ovviamente però anche GIT offre la possibilità di gestire un repo in remoto ma è soltanto una copia di ciò che hai in locale. Semplicemente un altro repo GIT che ti permette di lavorare su un progetto insieme ad altri.

Poi con GIT ti avvicini a GitHub e scopri un mondo nuovo, inizi a gestire le varie librerie come sub-moduli. Crei forks personali dei vari moduli sul tuo GitHub e li tieni allineati con l’origine. Quando impari ad usare i moduli ti rendi conto che GIT ha una marcia in più.

Ovviamente han pensato anche ad una procedura di importazione da SVN a GIT che funziona una meraviglia!

Nuovo template per il nostro sito!

Schermata 2013-07-24 alle 11.06.50

 

E’ arrivata l’ora di dare una rinfrescata a questo sito. Ormai il vecchio template, oltre ad aver stufato, era diventato obsoleto anche dal punto di vista delle funzionalità implementate in WP e siccome non ho mai tempo di metterci mano questa volta l’ho comprato bello e pronto su ThemeForest! Ecco qui il nuovo e fiammante WhiteBlack.

 

Gmail Imap RFC822.SIZE fail (zero)

Gmail_logo.png

I’m working on my BackUp Gmail App for OSX and I got a very strange issue.

This is the Imap transaction on Gmail server:


>> TAG02 UID FETCH 77480:77490 (UID RFC822.SIZE RFC822 X-GM-MSGID)


<< * 22136 FETCH (X-GM-MSGID 1384367682512034576 UID 77480 RFC822.SIZE 0 RFC822 {11012}
Delivered-To: *****@gmail.com
....
....
....
)
TAG21 OK Success

Look at the RFC822.SIZE, it’s 0 (zero)!
But it isn’t really zero because then it starts the RFC822, and it’s complete (11012 bytes).

When I create the backups I got it always at the same time, all the emails after Nov 2011 until Feb 2012 have this issue.
Maybe Gmail had problems in this period?
Anybody knows it?

Updated on 30 May 2013

I posted this issue on the Imap-protocol mailing list and today I received a reply from Jamie Nicolson (Google).
As you can read in this reply it is a temporary Gmail bug: “it affected messages during a certain timeframe in the past … We’re hoping to clean this up”.

 

 

Migrare WordPress su nuovo dominio

Wordpress logo

Migrare un sito in WordPress da un dominio ad un altro potrebbe apparire un’operazione semplice ma in realtà le cose sono complesse. WordPress memorizza in diversi punti nel database alcuni parametri associati al dominio stesso o al percorso locale in cui WP stesso è installato. Tutti questi riferimenti risultano spesso annidati in array serializzati e memorizzati in campi di database. Un’eventuale modifica “a mano” via phpMyAdmin quindi risulterebbe abbastanza scomoda e assai lunga.

Allora ho creato uno script (parser_WP.php) in PHP che modifica ogni riferimento presente nel database in modo da agevolare le operazioni.

Ricapitolando quindi, per migrare un sito WordPress su un dominio diverso, dovete:

  1. Copiare tutti i file e cartelle da un server ad un altro (via FTP, a partire dalla root)
  2. Creare un dump del database
  3. Creare un database vuoto sul nuovo dominio
  4. Importare il dump precedentemente creato
  5. Copiare lo script di cui sopra nella root del nuovo dominio e lanciarlo via browser (dopo aver configurato i dati di accesso al database)

Le modifiche da apportare al database sono di 2 tipi: sul dominio e sul path.
Aprendo lo script noterete che nelle prime righe vi sono 2 variabili da impostare:

$lookFor = "domain-1.com";
$replace = "domain-2.com";

Sostituite domain-1 con il nome del vecchio dominio e domain-2 col nome del nuovo dominio.

WordPress però, come dicevamo, memorizza anche il path assoluto in cui è installato. Dovrete quindi lanciare nuovamente lo script sostituendo le 2 variabili con i path: vecchio e nuovo. Ad esempio:

$lookFor = "/home/myOLDuser/";
$replace = "/home/myNEWuser";

Lanciate nuovamente il file. In questo secondo caso il risultato restituito (lo script restituisce il numero di valori modificati) sarà molto basso rispetto al primo (anche se questo varia a seconda dei plugin, widget, ecc. installati).

Fatto, ricordatevi di rimuovere lo script php dalla root!!

PHP: Nascondere errori “DEPRECATED” via .htaccess

logo-PHP

Sto installando un’applicazione in ambiente di prova, giusto per guardamela un po’ e per approfondire un po’ le funzionalità implementate. Peccato che l’applicativo in oggetto su PHP 5.3 genera una marea di errori di “DEPRECATED” dovuti alla funzione eregi ormai dichiarata obsoleta dal PHP 5.3 in avanti. Per velocizzare il tutto ho pensato di non visualizzare tali errori.

Le alternative sono diverse ma preferisco sempre aggiungere l’impostazione tramite file .htaccess in modo da “non sporcare” il codice sorgente. Ho quindi aggiunto un file .htaccess nella root del progetto aggiungendo questa riga:

php_value error_reporting 22527

Il livello 22527 corrisponde a  “E_ALL & ~E_DEPRECATED“, appunto tutti gli errori tranne i deprecated. Nel file .htaccess non è possibile inserire il testo, si può solo configurare tramite bitmask corrispondente calcolata sulla base delle costanti predefinite per error_reporting.

Se non siete ferrati sull’argomento bitwise operators o non avete voglia e tempo potete rapidamente calcolarvelo tramite queste 2 righe in PHP, la prima imposta il valore che desiderate (utilizzando le costanti e gli operatori bitwise) la seconda stampa a video la bitmask corrispondente (un numero intero) che poi potrete utilizzare per configurare il tutto tramite file .htaccess:

error_reporting( E_ALL & ~E_DEPRECATED );
echo error_reporting(); die;

 

Migrare Repository SVN


Metto qui insieme alcune risorse utili a migrare repository SVN. La soluzione migliore a mio avviso è quella di creare il dump di un repository per poi importarlo nel nuovo. Per creare un dump (se sono disponibili i comandi da riga di comando) lanciare da shell:

# svn dump my_repo_path > myRepo.SVNdump

Dove my_repo_path è il percorso in cui si trova il repository e myRepo.SVNdump è il file di output che andiamo a creare.

Dopo aver effettuato il dump e dopo averlo caricato nel nuovo Repo si blocca se non ha lo stesso UUID. E’ possibile modificare l’UUID di un Repository successivamente alla creazione del dump. E’ possibile inoltre forzare l’UUID quando si carica il Dump nel nuovo repo col comando:

# svnadmin load --force-uuid ...

Altre risorse utili:

 

 

BTO2012 è un successo, e il nostro Appennino?

BTO sta per Buy Tourism Online ed è un convegno, anzi, ormai è IL convegno sul Turismo Online. BTO2012 si è svolto a Firenze il 29 e il 30 novembre ed è stato un successo senza precedenti. I numeri dell’edizione 2012 sono il frutto di anni di lavoro: 3.245 i partecipanti, 6.421 le presenze, 155 relatori, 87 eventi, 198 giornalisti accreditati, 120 tra storytellers e bloggers; 46 aziende al Club degli Espositori.
Il Turismo nel nostro paese (alcuni amano chiamarlo “Brand Italia“) è in forte crisi. Complice sicuramente una governance italiana che lo ha completamente trascurato (basta ricordare lo scandaloso “progetto” Italia.it e gli oltre 50 milioni di euro buttati via). Eppure stiamo parlando di una risorsa importante perchè sarà l’unica a cui potremo aggrapparci un giorno non lontano, forse.

Dopo aver letto qualche articolo sul BTO certe domande sorgono spontanee…

In giro per la città si scorge a tratti la vetta innevata del Monte Cusna, difficile non notarla in questi giorni così limpidi. C’è neve lassù e una volta si sciava pure! Oggi non riesci nemmeno più a capire quali impianti sono aperti e quali no. Devi chiamare o fartelo dire dall’amico che vive in montagna. Tempo fa si parlava di collegare tra loro i vari impianti di risalita (Civago, Febbio, Cerreto, ecc), oggi sono in stato di abbandono o addirittura finiscono all’asta pignorati da Equitalia. Oggi falliscono, e miseramente li si lascia fallire. Oggi, che si scia anche a Dubai. Di certo non avremo mai più un Giuliano Razzoli.

E il Parco Nazionale dell’Appennino Tosco Emiliano? Sì, abbiamo anche un Parco nazionale lassù. Eccellente! Peccato non lo sappia nessuno fuori Reggio.
Abbiamo un potenziale immenso nella nostra provincia, qualcuno si è chiesto come sfruttarlo invece di lasciarlo in stato di abbandono? In occasione del BTO, possiamo porci qualche domanda in più sul futuro dell’Appennino e del Parco?

 

 

Ottimizzare la shell per Git

Oh-My-Zsh è un framework per gestire al meglio la configurazione della shell Zsh. Include oltre 40 plugin (rails, git, OSX, ecc.) e oltre 80 temi. E’ facile da installare sul vostro sistema OSX e già la configurazione base aiuta notevolmente nell’utilizzo dei Repository Git, ad esempio. Come si vede dall’immagine sopra la shell riconosce che nella directory in cui si è posizionati vi è un repository Git e ne segnala il branch corrente. Io, oltre a git, ho abilitato anche il plugin per OSX:

  • aprire il file ~/.zshrc
  • modificare la riga: plugins=(git osx)