Davide Petrillo

Si dice che l’IDE sia estensione stessa dello sviluppatore: se ne trova uno che abbia le funzionalità che ci servono e si impara ad usarlo in maniera veloce e produttiva.

Nella notte dei tempi usavo Homesite di Adobe, buono per creare pagine HTML tempestate di codice PHP (e viceversa) ma davvero poco per lo sviluppo serio (infatti l’hanno dismesso). Poi c’è stato Eclipse PDT, completo ma davvero troppo pesante e dal crash facile su Ubuntu. Mi sono quindi buttato su cose più leggere: Kate e GEdit (con le modifiche trendy & cool per farlo assomigliare a TextMate).

Infine, eccoci qua: Netbeans. Non l’avevo mai considerato perché non pensavo avesse un’estensione per PHP, e invece non solo ce l’ha ma, con sorpresa, gestisce tutto quello che mi può servire: debugging, unit testing (con PHPUnit), integrazione con Symfony. E quelle funzionalità base, come l’auto completamento del codice e la navigazione dei sorgenti, sviluppate in maniera intuitiva e che non richiedono troppi smanettamenti nella configurazione.

Vi ricordate il post in cui affermavo di andare al Wordcamp? Beh – scordatelo, non ci andrò più, visto che sarò in Sardegna per una sessione di lavoro! (e no, non è un villaggio turistico)

In compenso, durante il weekend appena trascorso, ho avuto il piacere di partecipare al phpDay 2009, evento organizzato dal GrUSP, la community italiana su PHP appunto.

I talk, tranne qualche – soporifero – caso, sono stati interessanti; evito di tediarvi con i verbali, ecco comunque le keyword che maggiormente mi sono rimaste impresse, o perchè ho avuto il riscontro della loro validità, o perchè sicuramente avrò voglia di approfondire:

• Cloud computing
• REST
• Test Driven Development
• Design Patterns

Salta niente all’occhio? A me sì: nessuna di queste keyword è strettamente legata a PHP

Diciamolo: a (quasi) tutti piace PHP per la propria facilità d’uso. Semplice da installare e configurare, altrettanto da programmare. Ma quando il gioco si fa duro, ecco che si sente la mancanza di quegli strumenti che rendono un linguaggio di programmazione solido. Nello specifico, di un debugger.

Ok lo ammetto, per anni anche io mi sono districato tra echo e print_r inseriti nelle pagine per andare alla ricerca degli errori. Naturalmente la musica è cambiata non appena ho perso quell’oretta necessaria ad installare e configurare un debugger PHP. Vediamo come.

Per prima cosa, installiamo Xdebug.
Xdebug è un modulo PHP, probabilmente già disponibile attraverso il vostro pacchettizzatore di fiducia sotto Linux. Altrimenti, sorgente compilabile o modulo per Windows sono disponibili sul sito ufficiale.

Il modulo va copiato nella extension_dir di PHP (verificarne la locazione nel php.ini).

Sempre nel php.ini, vanno aggiunti alcuni parametri di configurazione. Nel mio caso, ne sono stati necessari solo alcuni, ma controllate la documentazione in caso fosse necessario specificarne di diversi:

[XDebug]
zend_extension = "path/to/xdebug.so"
xdebug.remote_enable = On
xdebug.remote_log = "/path/to/logs/xdebug.log"

Riavviate quindi Apache e verificate la corretta installazione del modulo tramite il classico phpinfo().

Ora che disponete del motore, passiamo all’abitacolo: il client. La lista è lunga, io ho fatto in tempo a testarne positivamente un paio, ovvero VIM e Eclipse. Eclipse in particolare, nella forma del PHP Development Tools, permette un debugging completo, con breakpoints, watch e tutto il necessaire. La configurazione sotto Eclipse dovrebbe essere piuttosto semplice: basta settare XDebug come debugger principale, al posto dello Zend, gli altri parametri dovrebbero essere già a posto.

Un’altra funzionalità della quale non riesco più a fare a meno è quella del profiling. Tramite questo processo siamo in grado di individuare quali parti del nostro programma impiegano la maggior percentuale del tempo totale di esecuzione, permettendoci di risolvere eventuali colli di bottiglia.

Per abilitare il profiling, è necessario tornare sul php.ini e aggiungere queste righe:

xdebug.profiler_enable = On
xdebug.profiler_output_dir = "/path/to/profiles/"

Il profiler non necessita di un client; è sufficiente aggiungere il parametro XDEBUG_PROFILE=1  alla nostra pagina web per avviarlo (es. http://localhost/test.php?XDEBUG_PROFILE=1).

In quella che avete settato come directory di xdebug.profiler_output_dir, verranno creati dei file del formato cachegrind.out.xxxx; apriteli con kcachegrind (Linux) o wincachegrind (Windows) per vedere come si è comportato il vostro script.

Recentemente mi sono messo a cercare degli interpreti Javascript scritti in PHP.

Le ultime versioni dei browser eseguono senza problemi anche gli applicativi Javascript piu’ avanzati (chi si ricorda gli online desktop di un paio di anni fa?), senza contare che i vari framework JS sono sempre piu’ ottimizzati e veloci.

Tuttavia, volevo sondare quanto fosse possibile delegare parte della computazione Javascript, lasciandola al PHP e quindi al server.

Beh, i risultati sono sconsolanti; i parser che ho visionato sono lenti, elementari e ancora in fase beta.
Comunque sia, a scopo informativo, eccoli qui:

PHP-JS (utilizza il Mozilla SpiderMonkey)

J4P5