TiNoleggio & Partners
Posted by Davide | Filed under PHP, Work
Non allarmatevi, non mi riferisco ad una manifestazione con cantante lirico e ospiti internazionali, nè ad una società di revisione conti, ma all’ultimo progetto che sto seguendo.
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.
;+execute()]+->[Curl].jpg)
Come sempre, consigli e commenti sono sempre ben accetti!
La potenza degli iteratori in PHP
Posted by Davide | Filed under PHP
Il titolo è forse un po’ troppo ad effetto, però se siete arrivati a leggere fin qui è proprio perchè incuriositi dalla roboanza. Ora siete imprigionati in questo post e userete iteratori vita natural durante.
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.