Da utente, un’attività che detesto è il backup: da sviluppatore, il debug. Entrambe sono fondamentali, però richiedono tempo e non producono dei risultati “entusiasmanti” — perciò tendono a essere sottovalutate. I problemi che possono essere risolti col debugging non sono soltanto legati alla sicurezza del software, perché creando un sito non è obbligatorio che ne subentrino e la maggioranza delle vulnerabilità dovrebbe essere risolta dal provider. Soprattutto se non gestite direttamente il server sul quale risiedono le pagine.

Oggi, è impossibile che un sito non preveda l’integrazione di contenuti da terze parti: se utilizzate il codice fornito dai social network, dovete soltanto controllare che non sia cambiato, rispetto a quando l’avete inserito. Se, invece, “richiamate” delle Application Programming Interface (API)… dovete necessariamente affidarvi al debug. Confermato il corretto funzionamento degli script, il lavoro non è finito. Le API cambiano nel tempo e una funzione già verificata potrebbe incontrare delle difficoltà, da un momento allaltro.

Il debug periodico ha più livelli e non è sempre difficile da predisporre. Se sfruttate una connessione sicura in HTTPS, potete limitarvi ad appuntare sul calendario la scadenza del certificato: quello di Twitter – utile a dialogare con le API via SSL – scadrà il 31 dicembre, ad esempio. E se dovesse cambiare un URL, con l’aggiornamento delle API del determinato portale? Suggerisco di creare una funzione che invii automaticamente un messaggio d’errore al proprio indirizzo di posta elettronica. Gestendo più siti, è molto comodo.

Come sostenevo poc’anzi, il debugging può essere molto più elaborato. Ogni API restituisce degli errori personalizzati, dichiarati dal servizio che la eroga, e le singole funzioni del linguaggio utilizzato hanno i propri: conoscerle tutte a memoria sarebbe l’ideale, ma è sufficiente memorizzarne il codice e consultare la documentazione ufficiale. Salvare un log è «cosa buona e giusta», però – se gestite numerosi progetti – il tempo di leggerlo potrebbe mancare. Perciò consiglio d’impostare delle notifiche via e-mail al bisogno.

Un metodo ancora più efficace potrebbe essere quello di formattare il log in XML, pubblicarlo come RSS o Atom e iscriversi al feed: Google prevede già qualcosa del genere su FeedBurner, sempre che non sia dismesso. Potete anche “sbizzarrirvi” e creare una app che supporti le notifiche PUSH, per rendere il debug più piacevole. Ovviamente, dopo dovreste effettuare il debugging dell’applicazione. Non utilizzate delle API di terze parti? Lo stesso sistema è applicabile alle funzioni di Content Management System (CMS) come WordPress.

Me ne rendo conto, è un discorso scontato e qualcuno ha sicuramente concluso che abbia «scoperto l’acqua calda». Quante volte l’avete dimenticato, però? Io l’ho fatto per anni — pagandone le conseguenze. Ormai, ho raggiunto un tale livello di “paranoia” da non consegnare un lavoro… se prima non ho predisposto un sistema di notifiche per qualunque componente lato-server che dialoghi con terze parti. Che siate dei professionisti di lungo corso o alle prime esperienze, secondo me dovreste comunque prestare attenzione al debugging.

Photo Credit: Steve Jurvetson via Compfight (CC)