Undolog.com

Il 2012 è iniziato con qualche ora di deep-debugging a causa di due (noti) bachi abbastanza fastidiosi. Il primo, tra l’altro abbastanza datato, presente nel core di WordPress che riguarda il metodo update() della classe wpdb, con la globale (e famosa) omonima istanza $wpdb. Il difetto appare quando si tenta di aggiornare un campo a NULL. Nonostante le numerose lamentele, il team di sviluppo WordPress sembra non trovare soluzione al fastidioso problema. Infatti, ad oggi, l’unica soluzione è quella di scriversi l’SQL per proprio conto.

Continua...

Impostando nel file wp-config.php la define define('WP_DEBUG', true); si attivano i log a video prodotti da PHP, riempiendo lo schermo di Notice, Warning e quant’altro. Se per controlli “volanti” questo può essere utile, in situazioni di esercizio è vivamente sconsigliato, per ovvi motivi. WordPress fortunatamante permette di suo di “convogliare” questi log su un file, che per impostazione predefinita viene posto in /wp-content/debug.log.

Continua...

Se ci si trova a sviluppare in un ambiente dove è impossibile usare tool di debug come FireBug, come ad esempio il simulatore Apple iPad di Xcode, può diventare frustante individuare problemi, uno tra tutto l’errato accesso alle proprietà di un oggetto. Ecco che l’uso della funziona alert() diventa fondamentale!

Continua...

Quando non si lavora più da soli per tutti gli sviluppatori arriva il momento di trovare delle linee guida nella scrittura del codice. Protocolli e standard che permettano di “leggere” facilmente ed intervenire (sempre facilmente) nel codice altrui.
Quando su un progetto ci lavorano più programmatori, spesso su linguaggi diversi, è obbligatorio trovare una forma comune di scrittura, di standard nella documentazione interna ed esterna al codice. Nel mio lavoro mi trovo normalmente ad interagire con:

• Objetive-C, C/C++
• PHP
• HTML
• Javascript
• Actionscript
• CSS

Continua...

Continua...

Tramite le Preferences di Xcode è possibile impostare il comportamento dell’ambiente durante la fase di debugging di un’applicazione iPhone. Le impostazioni predefinite, infatti, sono assai scomode quando si prova e riprova un’applicazione; ad esempio, dopo aver lanciato la nostra applicazione, bisogna aprire manualmente la finestra Console per vedere l’output dei vari NSLog(). Inoltre Xcode lascia le precedenti sessioni così da costringerci a ripulire la finestra a mano. Fortunatamente è possibile risolvere il problema agendo sulle Preferences:

Come mostrato nella figura qui sopra, basta selezionare una delle voci del menu On Start per decide quale finestra di debug aprire in automatico all’avvio della nostra appicazione (io ho impostato Console & Debugger ma potete scegliere quelle che più vi fa comodo). Sulla destra poi troviamo Auto Clear Debug Console, così da partire sempre con la Console pulita.

Continua...

<a target="_blank" href="http://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/Reference/reference.html#//apple_ref/c/func/NSLog">NSLog()</a> è una funzione utilissima durante le fasi iniziali di un progetto, per il testing e il debug di un’applicazione per Apple iPhone o, più in generale, in ambiente XCode. Essendo appunto una funzione, esattamente come le altre, la sua presenza si farà sentire anche quando rilasceremo (release) il nostro eseguibile. Diventa quindi necessario rimuovere, in qualche modo, tutte le righe di NSLog() dal nostro codice, sia perchè non più necessarie, sia perchè le chiamate a NSLog() potrebbero influire sulle performance della nostra applicazione, soprattutto se abbiamo inserito NSLog() all’interno di loop.

Escludiamo subito la soluzione del “cerca” ed “elimina”; perchè un domani ci potrebbero servire nuovamente. Escludiamo anche la soluzione del “cerca” e “commenta”, scomoda per lo stesso motivo di prima. Fortunatamente una soluzione pulita, semplice e corretta la troviamo sfruttando le istruzioni condizionali del compilatore. Quello che faremo, in pratica, e dire al compilatore di escludere – se si verifica una determinata condizione – durante la compilazione del nostro sorgente le righe che contengono NSLog().

Le direttive di compilazioni e le istruzioni condizionali del compilatore, sono uno strumento molto potente e diffuso. Chi proviene dallo sviluppo ANSI-C le conosce sicuramente molto bene e le avrà utilizzte in moltissime situazioni. La particolarità di queste “istruzioni” risiede nel fatto, sopra accennato, di essere viste dal compilatore e non dall’eseguibile. Questa loro caratteristica le rende utili in moltissimi casi e permette di risolvere problematiche altrimenti assai fastidiose.

Vediamo subito un esempio di codice che, come preannunciato, permette di “eliminare” dalla compilazione parti di codice, nel nostro caso NSLog():

Le istruzioni condizionali del compilatore fanno parte della stessa famiglia della #define; anch’esse, infatti, sono precedute dal carattere “cancelletto” (#). Nell’esempio mostrato abbiamo definito una costante ACTIVE_NSLOG; le successive righe di codice dicono al compilatore di “includere” la riga NSLog() solo se ACTIVE_NSLOG è definito. Se abbiamo avuto la cura, durante la stesura del nostro codice, di inserire le chiamate a NSLog() all’interno del blocco #ifdef ... #endif, basterà eliminare la definizione della costante ACTIVE_NSLOG per far sparire, alla prossima compilazione, tutti i nostri NSLog().

Una soluzione migliore e definitiva

Vediamo adesso come impostare l’ambiente XCode per migliorare ancor di più ciò che abbiamo fatto sopra! Prima di tutto scegliamo un nome di costante che useremo nei nostri progetti per escludere dalla compilazione NSLog(). Potete scegliere il nome che più vi piace, da DEBUG a MIO_DEBUG o quello che preferite. Aprite il vostro progetto, nuovo o vecchio. Inserite tutti gli NSLog() all’interno del blocco (o di un blocco):

Selezionate il file principale del vostro progetto, cliccate con il tasto destro e scegliete la voce Get Info.

Si aprira la finestra con le informazioni sul progetto:

Selezionate la scheda Build, verificate di essere in configurazione Debug (è questa la chicca), andate nella sezione User-Defined e aggiungete, tramite il bottone in basso a sinistra, un nuovo campo chiamato OTHER_CFLAGS. A questo assegnamoli il valore -DMIO_DEBUG=1. La sintassi è -D{mia define}=1.

Questa procedura ha due vantaggi:

1. Non dobbiamo inserire nel codice la #define MIO_DEBUG 1, ma lo facciamo tramite le informazioni sul progetto. Quindi, quando andremo a compilare la versione di rilascio (quella senza gli NSLog()) non dobbiamo ricordarci di eliminare la riga #define MIO_DEBUG 1
2. La costante è definita in relazione alla configurazione, nel nostro caso Debug. Quindi, passando alla configurazione di rilascio (release) la costante sarà assente e le righe con NSLog() non verranno compilate

Conclusioni

La procedura sopra descritta può essere utile in una moltidutine di altri casi che, con NSLog(), non hanno nulla a che fare. Le istruzioni condizionali del compilatore possono aiutarci in una vastissima gamma di contesti. Spesso sono utilizzate dai programmatori per determinare il tipo di sistema operativo, la versione, il target, la presenza di processori matematici, mantenendo uno stesso “identico” sorgente.

Per capirci, come esempio, possiamo utilizzre la nostra costante MIO_DEBUG anche per intervenire in altre zone del codice:

Per completare, ecco alcuni esempi e varianti:

Continua...

Riprendendo il post Da Actionscript ad Objective-C (dove si mettevano a confronto il codice e la sintassi Actionscript e Objective-C), in Actionscript abbiamo la comodissima funzione trace(), usata per il debug delle applicazioni. Questa funzione emette un output sulla console dell’ambiente di sviluppo Adobe Flash. Viene utilizzata principalmente nelle fasi di sviluppo e testing di “filmato”/applicativo. In XCode/Objective-C abbiamo: NSLog(). La sintassi di questa funzione è molto simile alla trace() di Actionscript:

In Actionscript avremmo:

A parte l’uso della chiocciola (@), come potete vedere, sono identiche. Le differenze (e similitudini) iniziano quando si vogliano visualizzare valori di variabili; ad esempio in Actionscript potremmo avere:

In Objective-C abbiamo:

Nota: NSLog() in realtà richiama la più generica funzione NSLogv() che opera sull’Apple System Log. Le funzioni sono di fatto identica, cambiano solo i parametri in ingresso.

Gli sviluppatori C troveranno molto familiare la formattazione delle stringhe, come accade per printf() o sprintf(). Per dettagli si veda String Format Specifiers.

Continua...

Mozilla FireFox permette di gestire più profili, funzionalità utile a chi, come me, sviluppa siti web e necessita di tutta una serie di estensioni dedicate al debug e all’analisi delle pagine Web. Tramite l’uso dei profili è possibile configurare differenti impostazioni di FireFox:

Firefox salva le informazioni personali come i segnalibri, le password e le preferenze in un gruppo di file chiamato profilo situato in una posizione diversa rispetto ai file di programma di Firefox.

Su Windows Vista (vedi qui per altri sistemi operativi) è possibile accedere alla gestione dei profili dal comando Esegui usando:

Uno dei vantaggi nell’uso dei profili è quello di poter avere un FireFox per navigare, senza quindi tutte le toolbar e le estensioni per il debug e un FireFox per sviluppare, corredato da FireBug e tutti gli altri tool di sviluppo.

Continua...

Su Fireclipse è disponibile la release 1.1 beta di Firebug, strepitoso debugger Javascript e non solo per FireFox. Tra le novità di questa beta segnalo il supporto per Firefox 3, la funzionalità eval() ed un external editor interface.

Da seguire con interesse, poi, l’intero progetto Fireclipse, un open project dedicato a tool Javascript!

Continua...