Script di backup ne ho già trovati, letti e scritti diversi in passato. Più o meno funzionavano tutti bene ma nessuno faceva davvero quello che mi serviva, cioè offrirmi un solo comando per effettuare il backup differenziale di files e database, impacchettamento del tutto e salvataggio su un luogo al sicuro anche da danni fisici alla macchina stessa. Così ne ho fatto uno nuovo :) Ma partiamo dal fondo. 

Mega.co.nz

Ho scelto di usare mega.co.nz per diversi motivi: il primo è che mette un sacco di spazio a disposizione gratuitamente (50gb) ed un'infinità di spazio con i piani a pagamento. Il secondo è che i files vengono criptati lato client prima di essere trasferiti. Questo aiuta la protezione durante il traferimento ed evita che i dati vengono salvati in modo leggibile sul cloud. Infine ci sono degli ottimi tool da riga di comando per usare mega su linux, cosa fondamentale visto che dobbiamo utilizzarli in uno script BASH. Per il trasferimento dal server al cloud ho optato per un tool scritto in Python chiamato megacl, che è incredibilmente comodo e facilmente installabile su qualunque sistema operativo linux (ho provato anche megacmd, ma su debian wheezy andava in segmentation fault).

Ma io voglio salvare i backup in locale!

È un tuo diritto. Vai nelle configurazioni (vedi sotto) ed imposta la variabile BACKUP_ON_MEGA a false. In questo modo non avrei necessità di installare megacmd, ed i backup verranno mantenuti nella directory di destinazione (naturalmente i backup vecchi vengono cancellati, mantenendo solamente gli ultimi 2 backup completi ed almeno gli ultimi 7 differenziali).

Backup

I backup, come dicevo, sono differenziali: il primo backup è ovviamente completo mentre gli altri contengono solamente i file che sono cambiati rispetto all'ultimo backup completo. Ogni primo giorno del mese viene fatto un altro backup completo. Vengono salvati sia i files che i database (tutti, oppure solo quelli specificati in un apposito file).

Configurazione

La configurazione richiede il minimo indispensabile:

MAIL='miamail@email.com'

ORIGIN='/var/www'
DESTINATION='/media/External/Backups'

BACKUP_ON_MEGA=true

DB_USER='root'
DB_PASS=''

Abbastanza semplice, no? :)

Puoi trovare lo script a questo indirizzo.

Per lanciarlo è sufficiente eseguire ./megabackup.sh da utente, mentre per automatizzarlo si può usare crontab... Più semplice di così!

Ho pubblicato oggi la nuova versione 0.2 di CakePHP Supercache plugin, che porta con se un paio di succose novità. Prima di tutto il sistema è ora basato su una configurazione di tipo whitelist / blacklist, che significa rispettivamente "non fare la cache di nulla tranne ciò che specifico" e "fai la cache di tutto tranne ciò che ti specifico". La blacklist è comoda per tutti quei siti con molte pagine che possono essere visualizzate senza aver bisogno di interrogare o lavorare con il database. Quello che fa un CMS come questo, per esempio :) La whitelist, al contrario, è utile per tutti quei siti con molte pagine che "scrivono" sul database, come può essere un gestionale in cui le pagine "statiche" sono poche.

Altra novità importante è che ora la cache viene automaticamente sospesa nel momento in cui CakePHP imposta un messaggio di sessione (i classici $this->Session->setFlash(), per intenderci). Ovviamente non vogliamo che questo genere di messaggi vengano mostrati ad utenti che non c'entrano nulla con chi l'ha fatto generare (per esempio compilando il modulo contatti), e da ora è più semplice gestire questo genere di eccezioni.

Nella prossima versione ho intenzione di concentrarmi sull'ottimizzazione delle pagine html: tidy, compressione e via dicendo... sono aperto a consigli in merito :)

Link: https://github.com/ToX82/cakephp-supercache

Ho da poco acquistato questo (enorme) telefono e dopo soli due giorni di utilizzo non riesco a resistere alla tentazione di installargli qualche sistema operativo diverso da android stock: penso in particolare a ubuntu touch (perlomeno per provarlo, anche se non credo sarà il mio sistema predefinito), ma anche a cyanogenmod (da usare normalmente).

Su internet ho trovato decine di guide ma tutte richiedono l'installazione di drivers, applicazioni, cose... finché non mi sono imbattuto in un piccolo tool che rende davvero semplice il tutto: è sufficiente lanciare un comando per ritrovarsi il telefono resettato (questo avviene con qualunque sistema, purtroppo) e rootato.

Ecco i passaggi:

• Per prima cosa bisogna scaricare ed estrarre questo file sul proprio computer.
• Poi bisogna spegnere il telefono e riaccenderlo tenendo premuto il tasto volume +, volume - ed il tasto di accensione. Il nexus si riavvierà in modalità "sala operatoria", con tanto di logo android con il "cofano" aperto.
• Infine si collega il telefono al computer utilizzando un normale cavetto usb.

A questo punto è sufficiente lanciare root-windows.bat, root-linux.sh o root-mac.sh a seconda del sistema operativo che stiamo utilizzando. La procedura guidata farà comparire una richiesta sul telefono per sapere se vogliamo sbloccare il boot loader oppure no (e noi lo vogliamo, naturalmente), e dopo un paio di riavvii avremo il nostro nexus sbloccato.

Facile, no? 

Ok, debugger non è il termine corretto. In realtà questo pacchetto si occupa di "linting", cioè controlla il codice per potenziali errori e li evidenzia in modo tale da renderli chiaramente visibili allo sbadato programmatore.

Per esempio, niente più ; mancanti al termine di un'istruzione PHP, sublimeLinter evidenzierebbe subito la riga di rosso. Così come niente più parentesi non chiuse in CSS, niente più dichiarazioni duplicate, niente più... dimenticanze o sviste di questo tipo. Con grande risparmio di tempo e di energia nel cercare di debuggare una funzione semplicissima che si ostina a non funzionare... diavolo di una virgola mancante :)

L'installazione è semplicissima, così come ogni altro plugin per Sublime Text: si apre il package installer, si seleziona "sublime linter" e... si installa :)

Funziona tutto fin da subito , senza troppi sbattimenti e volendo c'è anche un piccolo menu per configurare più facilmente il comportamento del plugin. L'unica altra modifica che ho fatto è stata disabilitare gli avvisi durante il linting dei file CSS, per fargli ignorare l'uso dell'istruzione !important e degli ID .

Per farlo, è stato sufficiente aprire il SublimeLinter settings - user, andare alla riga degli ignore per il csslint e sostituirla con :

"ignore": "important,ids",

L'unica cosa che manca a questo pacchetto è il linting per i Javascript, che è da abilitare a parte. Per farlo è sufficiente installare il pacchetto sublimelinter-jshint, installare jshint... e godersi anche quest'altra sciccheria.

user@linuxbox:~$ npm install -g jshint

Facile, no? :)

CakePHP è lento, dicono. E forse hanno anche ragione, benchmark alla mano, ma la vita reale è molto diversa da un benchmark ed io tutta questa lentezza non l'ho mai realmente percepita. Discorso ben diverso invece è gestire un sito molto visitato su un server con risorse limitate, cosa che può causare una lentezza dovuta, appunto, alle scarse prestazioni del server più che a quella del framework in se.

Tempo fa scoprii un fantastico plugin di Matt Curry che permetteva di creare dei file html statici, in modo del tutto trasparente all'utente finale, che fossero una copia esatta di una precedente elaborazione di CakePHP. Per farla semplice: la prima volta cakephp genera la pagina, la salva in un file html e la seconda volta visualizza direttamente il file html invece di ri-elaborare il tutto. Figata!

Implementai quel sistema ma mi resi conto che non era ancora una soluzione ottimale: il tutto si basava infatti comunque sull'infrastruttura di CakePHP (che quindi faceva comunque lavorare il server, se non altro per caricare il framework). Volevo qualcosa di più radicale.

CakePHP supercache plugin

Così mi misi a lavorare su qualcosa che facesse più o meno la stessa cosa e decisi di operare alla fonte: il file app/webroot/index.php. Questo mi permise di saltare totalmente l'infrastruttura di CakePHP facendo richiamare direttamente il file cache, quando richiesto. In pratica, poche righe di php (puro) per decidere cosa fare, per poi richiamare il framework o la cache a seconda delle necessità. Senza praticamente alcuno sforzo per il server. Non appena poi un utente effettua il login la cache viene automaticamente svuotata, così da evitare il rischio di mantenere in cache file obsoleti.

Installazione

Per installare questo plugin è necessario:

• Creare la cartella app/webroot/cache, con permessi di scrittura;
• rinominare il file app/webroot/index.php in app/webroot/index_cake.php;
• scaricare il file index.php da github;
• curiosare nel file ed indicare quali tipi di pagine debbano essere salvate in cache (il tutto è gestito in stile whitelist: di default nessuna pagina viene salvata tranne quelle specificate);
• godersi il risultato.

Risultati

Per avere un'idea del risultato ho fatto qualche misurazione del consumo di memoria necessario alla visualizzazione della home page di questo stesso sito: senza il plugin abilitato la memoria utilizzata dal server per mostrare l'home page è di 3,78mb e 0.075281 secondi di elaborazione. Con il plugin attivato è di 768kb e 0.000977 secondi.

Mica male per un plugin così semplice da implementare, no?