Parlo di www.tinoleggio.it, portale di ricerca comparata per il noleggio di mezzi di trasporto, dall’automobile alla barca, creazione di una giovane start-up milanese che nel suo arsenale web annovera anche www.tiprovo.it e altri diversi progetti interessanti ancora in cantiere. TiNoleggio permette di trovare le tariffe (teoricamente) più basse sul mercato grazie alle numerose partnership intrecciate con società di noleggio o altri aggregatori di prezzi. Queste partnership commerciali devono naturalmente essere tradotte in software: e qui arriviamo al perchè sono stato chiamato 15 giorni fa a dare il mio contributo al progetto (se ve lo state chiedendo: sì, è squillato il telefono rosso che tengo nascosto dietro il quadro di Rembrandt)

Ci sono due problemi da risolvere. Il primo è che le modalità di accesso ai dati forniti dai partner, tramite le quali effettuare le ricerche, sono abbastanza variegate: database, API, siti web sui quali lanciare spider. Il secondo è che, all’aumentare dei partner, aumenta anche il tempo computazionale di ricerca, ed è fondamentale evitare di raggiungere il famigerato TAU (Traguardo di Assopimento Utente).

Uniformare i partner

La soluzione al primo problema è semplice: incapsuliamo i partner e i loro meccanismi di ricerca all’interno di una serie di classi polimorfe. Abbiamo quindi diverse classi Partner, contenenti definizioni e dettagli relativi ai partner, e PartnerSearchEngine, che incorporano la logica di ricerca sui dati del partner. In questo modo viene definita una linea guida per creare un futuro partner, in modo totalmente indolore, in quanto il motore di ricerca di TiNoleggio non dovrà essere riadattato per gestire la nuova integrazione: saprà già quali metodi chiamare per ottenere ciò che gli serve.

Parallelizzare le ricerche

Anche qui non parliamo di rocket science: se 3 processi ci mettono 3, 5 e 7 secondi ad eseguirsi, e vogliamo che il tempo di esecuzione totale sia sotto i 15 secondi, dovremo eseguirli in parallelo. Il tempo di esecuzione totale sarà quello di esecuzione del processo più lento (in linea teorica; bisogna tenere in considerazione l’overhead e il maggior consumo di risorse hardware).
In PHP, abbiamo due modi per eseguire processi paralleli: l’utilizzo delle fork e la chiamata di script lanciati in background (su Unix, in questo caso) Dato che le fork sono assolutamente sconsigliate in ambiente Apache, si ricade forzatamente sulla seconda opzione. Ci sono diverse funzioni che permettono di eseguire script in background: io ho utilizzato proc_open, flessibile e potente.

Oltre alla parallelizzazione dei processi di ricerca dei partner, è stato implementato un ulteriore livello di parallelizzazione: quello delle richieste HTTP, nel caso in cui la ricerca preveda l’utilizzo di chiamate ad API del partner o spidering del loro sito. Tutto ciò è stato ottenuto utilizzando la libreria cURL (modulo PHP da installare a parte), della quale ho incapsulato le funzinoalità in un paio di classi, per facilitarne l’utilizzo.

Come sempre, consigli e commenti sono sempre ben accetti!

Ma cosa sono gli iteratori? Sono l’implementazione di un design pattern – l’Iterator, appunto – che ha come scopo quello di risolvere un problema: manipolare collezioni di dati in maniera semplice, utilizzando un’interfaccia uniforme e comune a tutti gli iteratori.

Vi capitasse di fare un giro sulla documentazione della Standard PHP Library vi si potrebbe aprire un mondo; per chi ha fretta, invece, ecco una serie di slide con un po’ di applicazioni pratiche. Codice più uniforme, meno ripetizioni, meno errori.

Ah, fosse stato così anche all’università!

Sto però iniziando ad avere qualche dubbio.

Poco tempo fa ho trovato un’offerta di lavoro della Nintendo in cui si specificava che la certificazione sarebbe stata titolo gradito; senza contare che in qualità di web developer ho sviluppato i miei progetti più grossi perchè girassero su intranet, e che quindi non ho un portfolio da portare in dote ad un eventuale colloquio di lavoro.

Oggi ho provato il test di certificazione online, acquistabile sul sito Zend: passato senza troppi patemi, ma l’impressione è che chi non ha una vasta esperienza con PHP possa avere difficoltà. E che quindi la certificazione possa essere una discriminante tra chi usa PHP come linguaggio tutto fare e chi lo usa per applicazioni complesse.

Insomma, che dite: mi iscrivo ad una sessione di esame?

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.

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

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.

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