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!

Il primo spunto viene da questo post intitolato Killing Distractions. Per quanto la mole di distrazioni che mi assalgono sia molto inferiore a quella di chi ha svariati clienti con i quali trattare durante la giornata, anche io sento che parte della mia produttività si disperde tra una lettura dei feed, risposte agli instant messages e mantenimento della mia presenza sul web perennemente “live”. E per fortuna sto evitando Twitter!

Lavorando nel web, sento la pressione di dovermi tenere costantemente aggiornato riguardo a nuove tecnologie, pratiche, linguaggi. Ma è necessario trovare un equilibro, limitando le distrazioni in finestre di tempo ben definite. Un metodo per riuscirci è pensare a tutte le persone che, non lavorando di fronte ad un computer, durante il giorno non possono nemmeno controllare la posta!

Sempre sul tema, recentemente parlavo con i colleghi di un metodo di lavoro per aumentare la produttività (e vivere felici): lavorare un giorno in meno! Guarda caso, l’autore dell’articolo è il buon Ryan Carson, l’organizzatore di FOWD, FOWA ed altri eventi simili.
Quella del non lavorare il venerdì è sicuramente una sfida interessante, ma, paradossalmente, praticabile soltanto quando si ha una grossa mole di lavoro (e quindi, di richiesta); di certo in periodi di crisi non dispiacerebbe a nessuno lavorare anche durante il weekend

Si tratta di consigli sul come convincere il proprio datore di lavoro a farci spendere un po’ di tempo lavorativo a casa, rendendoci più produttivi e felici. Si inizia chiedendo un giorno di prova al mese, poi a settimana, tentando di sfruttare l’occasione dataci, mostrando di poter fare lo stesso – e meglio – di quello che si fa tra le mura aziendali.

Io in realtà sono terrorizzato dal lavoro da casa, e l’ufficio me lo sono andato a cercare, ma quello sul lavoro flessibile è comunque un argomento che mi sta molto a cuore, in tutte le sue forme.

Dopo la pausa forzata della settimana scorsa, causa disconnessione dal mondo, da ieri sono felicemente tornato al Cowo.

Mi chiederete: cos’è il Cowo?

E’ un bellissimo open space milanese, recentemente convertito a spazio di lavoro condiviso per liberi professionisti in cerca di un nido, ed aperto ad ospitare altre anime di passaggio bisognose di una scrivania e di un po’ di banda navigabile.

Nasce dal concetto di coworking, tanto diffuso oltreoceano (verso ovest!), ma ancora quasi sconosciuto qui da noi; tanto che solo il partecipare al progetto mi fa sentire davvero un pioniere. In realtà è solo l’espletazione di un bisogno piuttosto naturale: quello di uscire di casa, ritagliarsi ore di produttività ben definite e avere un collega con cui chiacchierare, condividere opinioni e scambiarsi stimoli durante le pause caffè. Il problema più grande è che questi caffè non riesco mai a pagarli!

Lo so che dalla descrizione sembra che questo posto ve lo debba vendere, ma probabilmente è l’effetto che mi fa stare a contatto con tutti questi pubblicitari!

Ma non solo di pubblicitari & informatici si tratta: oggi la sala riunioni era invasa da ingegneri aeronavali. Sicuramente ‘aeronavali’ non è la definizione giusta e mi scuso in anticipo per l’errata!

E segnali d’interesse al coworking arrivano anche da scrittici-food stylist. Un grazie quindi anche a Roberta per avermi fatto conoscere il concetto di Jelly.

Insomma, la voglia di condivisione, vuoi per necessità, vuoi perchè è più bello, straborda dal web e invade la vita reale. Ma il web è fatto di persone vere: vuoi vedere che finora siamo stati così timidi da non riuscire a dirci che abbiamo bisogno di scambio, se non attraverso un monitor?