Tra il codice e la realtà

Se un investitore azzecca sei volte su dieci è bravo.

Se azzecca sette volte su dieci è molto bravo e fortunato.

Se azzecca otto volte su dieci è bugiardo.

Warren Buffett

Mentre facevo un po’ di pulizia sull’HD, ieri mi sono imbattuto in una cartella che conteneva la mia tesi di laurea.

Devo dire che non mi ricordavo di averci fatto tanto lavoro! E neppure di aver affrontato tanti argomenti d’interesse, pure abbastanza attuali. Mi piace in particolare l’attenzione dedicata alla significanza dei risultati ottenuti, con considerazioni decisamente apprezzabili anche dopo tanto tempo.

Interessante anche il lavoro di programmazione, codice sorgente decisamente ben strutturato, considerando la complessità di alcune implementazioni (come le reti neurali localmente ricorrenti e tutta la parte degli algoritmi genetici).

Insomma, non nego che mi abbia fatto venire un po’ di voglia di riprendere in mano la questione … se qualcuno è interessato i sorgenti e tutta la documentazione, sono a disposizione!

Nel frattempo, potete dare un’occhiata alla presentazione (utile per farsi un’idea) oltre che alla tesi vera e propria.

Non sono un fan di PHP, ma lo uso essenzialmente per utilizzare WordPress (per questo blog ed anche per quello di Caasa); non aggiorno quindi frequentemente la versione di PHP, anche perché sul server utilizzo Centos, che mette sì a disposizione yum come eccellente sistema di aggiornamento, ma non è certo il massimo relativamente alla frequenza con cui mette a disposizioni gli aggiornamenti.

Per farla breve, fino a stamattina avevo installato ed in uso PH 5.1, ma ho scoperto che l’ultimo aggiornamento di wordpress (3.2.1), richiede almeno PHP 5.2. Ovviamente (?) Centos (attraverso i suoi repositories ufficiali) non mette a disposizione che la versione 5.1 e non avevo assolutamente intenzione di “tentare” procedure complesse e “rischiose” (a che fine, in effetti ? :)) . Beh però una ricerca su google potevo pure tentarmela … bene ho trovato qualcuno che ha reso le cose davvero semplici e funzionali: ha creato un repository per yum installabile con un rpm e poi la versione di PHP più aggiornata che si sostituisce a meraviglia a quella “originale” … se siete nella mia stessa situazione (Centos 5.5/5.6 e volete installare/aggiornare WordPress alla versione 3.2.1), date un’occhiata qui.

E non dimenticate di riavviare apache !

E’ online la prima versione alfa di Caasa. Si tratta di un motore di ricerca per annunci immobiliari basato su bot. La parte “visibile” è costituita da 2 portali: http://www.caasa.it è il motore di ricerca degli immobili, mentre http://www.mercato.immobiliare.info fornisce informazioni, news e quotazioni immobiliari ad un dettaglio che arriva ai singoli quartieri per ogni tipologia d’immobile.

Certo, al momento è online una versione alfa e alcune caratteristiche sono implementate parzialmente o addirittura assenti, ma la ricchezza di contenuti, l’eccellente dettaglio nella classificazione geografica, la categorizzazione intelligente delle tipologie e l’interfaccia utente estremamente funzionale, dovrebbero rendere Caasa il posto migliore dove effettuare la ricerca di un immobile. Caasa permette l’utilizzo di chiavi di ricerca multiple sia per le tipologie che per la localizzazione ed utilizza un algoritmo proprietario per l’ordinamento dei risultati in modo che risultino sempre estremamente pertinenti.

Dal punto di vista tecnico Caasa è un progetto complesso e molto interessante: sarò lieto di condividere scelte architetturali, tecnologiche e di design con chi fosse interessato. Appena avrò un briciolo di tempo posterò su questo blog degli articoli sugli aspetti più interessanti o magari renderò disponibile qualche libreria particolare che mi è capitato di sviluppare per risolvere esigenze specifiche ( dall’esame del file robots.txt alla cache asincrona ).

Call for testing!

Nel frattempo sarei grato a chi volesse effettuare qualche test. Sul blog di caasa c’è una mini FAQ per il testing della versione alfa: è il posto giusto da dove iniziare. Grazie in anticipo per i commenti o le segnalazioni di bachi.

Nella realizzazione di uno spider, uno degli aspetti che devono essere garantiti, è il rispetto della volontà del proprietario di un sito, riguardo all’uso dei dati contenuti in esso.

Per quanto esistano degli standard più completi e complessi ( in particolare l’ACAP ), il metodo più utilizzato per la restrizione dell’accesso ad un sito, è sicuramente l’utilizzo di un file di nome robots.txt nella home del sito.

Il protocollo utilizzato è estremamente limitato e consente solamente di impedire (completamente) a tutti o ad uno User-Agent particolare l’accesso ad una o più risorse o cartelle del sito. Non è possibile limitare l’utilizzo delle informazioni ( ad esempio l’elaborazione automatica, la possibilità di visualizzare i dati senza linkare direttamente la pagina da cui sono tratti, la memorizzazione, l’aggiornamento etc ). Non è possibile consentire esplicitamente l’accesso ( ma solo proibirlo ). Non è possibile imporre delle restrizioni rispetto ad altre caratteristiche dello User-Agent come tecnologie supportate ( Javascript ad esempio ) o provenienza geografica, IP, organizzazione, etc. Non è possibile neppure utilizzare uno stesso files per domini o sotto-domini differenti.

Inoltre non esiste uno standard di riferimento e ci sono alcune estensioni ( come Request-rate e Visit-time o l’utilizzo di wildcard per la selezione dello User-Agent o delle risorse ) che sono supportate solo da alcuni bot, ma non da altri.

Anche dalla versione “base” è però possibile stabilire molte informazioni ed è quindi doveroso tentare di assecondare almeno quelle.

La mia è una considerazione di buon senso più che un vincolo legale o morale: non è detto che rispettare i vincoli espressi di robots.txt garantisca completamente da questioni legali, né al contrario non rispettarle sia di sicuro contro la volontà del “proprietario” del sito (che magari ha solo impostato più o meno inconsciamente delle restrizioni più forti di quello che voleva o magari, se interpellato, potrebbe sicuramente concedere l’accesso). Particolare a riguardo è il caso di Pete Warden che è stato costretto a cancellare il db degli utenti che aveva raccolto da facebook, tramite uno spider che rispettava robots.txt.

In sostanza mi sembra ragionevole pensare (entro certi limiti) che i dati presenti su un sito siano in qualche modo del proprietario del sito, anche se non esprime chiaramente le proprie intenzioni tramite un determinato strumento (robots.txt ad esempio) o le esprime in modo non accurato.

Questioni da legali, comunque… veniamo al codice: come realizzare un’analizzatore di robots.txt in JAVA ?

Nell’uso comune del termine, con ‘ottimo’ s’intende principalmente ‘molto buono‘.

In informatica (e in matematica) con soluzione ottima s’intende ‘la migliore possibile’ e ovviamente non è affatto detto che sia ‘buona’.

La differenza principale tra i due termini è (a mio parare) soprattutto il fatto che ottimo è necessariamente contestuale. E’ quindi (spesso) concretamente definibile: ad esempio l’algoritmo che utilizza meno RAM o è il più veloce a produrre i risultati, etc, etc. Ha però anche implicitamente più gradi di libertà, nel senso che il contesto nel quale va ricercato l’ottimo è spesso difficile da definire; anzi è spesso l’aspetto più difficile da definire.

Il fatto è che quasi sempre gli architetti del software non credono di avere certi gradi di libertà o, al contrario, assumono sbagliando di averli.

Io ad esempio ho sempre considerato concettualmente sbagliati i meccanismi di monitoraggio attivo del software (un software che al crash di un altro lo riavvia): non solo si rischia di non risolvere il vero problema (il crash), ma -peggio- si rischia di sviluppare un sistema di monitoraggio complesso che AGGIUNGE problemi alla piattaforma nel suo complesso.

Non per questo però non è detto che (in pratica, in un certo contesto operativo) sviluppare e mantenere un sistema di monitoraggio attivo non sia la soluzione ottima (magari pure non buona in assoluto). E’ quello che hanno pensato anche a reddit all’inizio della loro storia: in sostanza riavviare il server in modo automatico era senz’altro meglio che farlo “a mano”, svegliandosi ogni poche ore 🙂

Più seriamente l’aspetto focale è che un architetto software deve essere sempre ben conscio di dover ricercare dei massimi locali e che spesso, gli intervalli all’interno dei quali cercarli sono parte del problema e che quasi sempre sono tempo-varianti.

Oggi ho provato ad utilizzare Yahoo Pipes: davvero impressionante!

Si tratta di un servizio che consente di aggregare, filtrare, generare feed partendo dalle più disparate fonti. E’ ad esempio possibile recuperare i feed dei principali quotidiani e filtrare gli articoli in base al fatto che contengano o meno alcune parole (o più in generale un’espressione regolare). Potentissima poi la possibilità di utilizzare come fonte una ricerca di google news (o blog search), sfruttandone tutte le potenzialità per ottenere un’inesauribile fonte personalizzata di new di qualità. Putroppo non è possibile utilizzare (direttamente) i risultati di una ricerca sul web (con google), ma è possibile avere a disposizione quelli di yahoo.

Tecnicamente le sorgenti possibili comprendono oltre ad rss e atom, anche XML, JSON, HTML, CSV, consentendo davvero di accedere a qualsiasi fonte disponibile sul web. L’unico limite è che le fonti non devono avere un file robots.txt che ne impedisca l’accesso.

Alle sorgenti è poi possibile applicare un gran numero di “operatori” che consentono di filtrare, dividere, unire, contare, troncare, verificare l’univocità, ordinare, etc, etc. in modo da ottenere davvero qualsiasi risultato si desideri.

Ma l’aspetto davvero straordinario del servizio è l’eccezionale tool grafico di generazione:

yahoo pipes edit

E’ un ambiente visuale estremamente semplice da utilizzare e allo stesso tempo potentissimo. Con qualche click è possibile selezionare le sorgenti, filtrarle unirle ed ottenere poi un feed che si può pubblicare con estrema semplicità.

Date un’occhiata al box qui a lato: trovate il feed che ho costruito per ottenere news simili ai contenuti di questo blog. In pochi minuti un risultato davvero eccellente!

Tra le linee guida di google più “profonde” c’è ovviamente il fatto di evitare il cloaking, ovvero di presentare a googlebot contenuti differenti rispetto a quelli presentati ad un normale utente. Ci sono però alcuni casi in cui presentare un contenuto differente sulla base dello user-agent, non è affatto un “imbroglio”, ma è anzi un modo per fornire migliori informazioni o addirittura una necessità in qualche caso.

In particolare può essere necessario fornire contenuti differenti in base al browser utilizzato (ad esempio in mobilità o con una risoluzione molto bassa) o in assenza di plugin (come flash) o ancora in seguito ad informazioni ottenute automaticamente (tramite cookies) sull’utente.

Altro caso tipico in cui una generazione “specializzata” dei contenuti è utilizzata in modo lecito è legato alla lingua o alla localizzazione geografica dello user-agent. Si tratta di tecniche ormai diffusissime che possono essere estremamente utili e funzionali per gli utenti, anche capisco che possano mettere in difficoltà sistemi puramenti automatici di crawling.

Purtroppo però la posizione di google rispetto all’utilizzo di tali tecniche non è completamente chiaro e mette quindi in grosse difficoltà i webmaster che devono valutare (paradossalmente) se implementare funzionalità a vantaggio degli utenti con il rischio di essere penalizzati dai bot convinti che tali funzionalità siano implementate a loro vantaggio.

Tale problematica ha dato luogo a lunghi dibattiti tra gli addetti ai lavori, tra i quali va senz’altro letto questo post su seomoz blog.

Fortunatamente c’è anche un post sul blog ufficiale di google che fa una buona chiarezza sulla vicenda; lo spirito della “legge” di gogle è estremamente ragionevole:

Googlebot should see the same content a typical user from the same IP address would see.

Ovviamente non è chiarissimo cosa voglia dire “the same content”: identico al byte ? identico solo nei contenuti (ad esempio non nella pubblicità) ? uguale in una buona percentuale del sito ? Sinceramente non credo che sia possibile determinare in mo affidabile al 100% nessuna procedura completamente automatica, visto che mi vengono sempre in mente casi “leciti” estremamente difficili da estrapolare. Ma almeno lo spirito mi sembra estremamente condivisibile.

In un ottimo articolo Kyle Brown, elenca tre “comuni” problemi che affliggono i Web Services basati su XML (SOAP o meno). Merita una lettura attenta perché non mette in evidenza  le meravigliose capacità di un qualche tool, libreria o linguaggio, ma collega a errori di principio nel design i disastri che si riesce a produrre anche in contesti abbastanza semplici e con strumenti tutto sommato ben conosciuti.

Il primo errore è davvero banale e non mette in evidenza nulla di “profondo”: gestire messaggi da parecchi megabyte, magari con dati binari (senza forse neppure accorgersene) è semplicemente una scelta da incapaci; non è certo un problema dell’XML.

Il secondo è invece molto più interessante, perché è davvero una forza che guida spesso il design: definire i servizi ad un livello esremamente basso (ad esempio a livello di ogni singola operazione SQL). Perché (come dice Brown) “[…]such low-level data services often fail.” ? A mio parere il discorso è molto generale: Un Web Service dovrebbe rappresentare un’interfaccia che maschera la complessità che si trova a monte, semplificandone l’utilizzo in base alle esigenze di chi si trova a valle. Purtroppo invece scrivere un XML o richiamare un servizio non è più facile che accedere direttamente ad un DB e scrivere l’SQL relativo, né maschera alcuna complessità o dettaglio implementativo se il contenuto informativo necessario a richiamarlo è in relazione biunivoca con l’SQL utilizzato. Introdurre un layer (o un’interfaccia per l’accesso di una qualche risorsa/servizio) deve essere motivato da concreti vantaggi nel contesto specifico e non è certo buono in astratto e in generale.

Il terzo problema è paradossale e viene fuori soprattutto con SOAP: siccome non è comodo né banale definire gli schema in modo completo e soprattutto non è facile modificarli, spesso alcuni servizi sono solo semi-definiti con una parte (spesso predominate) magari ancora in XML, ma non parte dello schema della richiesta. Questa situazione è spesso solo la spia del fatto che si è sbagliato nel definire le interfacce, che risultano complesse ed devono essere cambiate molto spesso, perché sono poste al livello sbagliato.

Ultima nota a livello generale: in programmazione qualcosa di inutile è quasi sempre dannoso, specie un’astrazione.

In un progetto sul quale ho lavorato di recente, mi è capitato di avere a che fare con flussi (streaming multimediali) a bitrate relativamente alto, per l’hw in questione. Scrivo questo post perché siamo stati vittime di un nostro (banale) bug che ci è costato qualche giorno di test e qualche mal di testa: magari qualcuno potrà evitarseli leggendo questo post… non si trova molta documentazione in giro.

Intanto qualche altro dettaglio sul sistema: un client che riceve flussi multimediali in UDP (fino a 10 mbs) su windows embedded ce 6.0, realizzato in c++ con il visual studio 2005, utilizzando direttamente winsock2. Un thread si occupa della ricezione utilizzando semplicemente una socket in modalità bloccante in un ciclo di lettura che ha anche il compito di effetture alcune operazioni sui dati (poco onerose in termini di CPU) e di copiarli in un buffer dal quale un thread consumatore le preleva. Viene utilizzata la funzione recv(), visto che la modalità bloccante non è affatto un problema (e quindi l’ overlapped I/O è inutile) e le completion routine non sono ben supportate da windows embedded ce 6.0.

Tutto sembra funzionare bene, fino a bitrare inferiori a 2 mbs, ma superando tale valore… si manifestano degli strani problemi. Dopo molta fatica (visto che ovviamente non era possibile andare in debug, ma neppure scrivere su file se non pochi kbytes e quidi il debug stesso non poteva che avvenire anch’esso via rete), sembrava inequivocabile che si trattasse di perdite di pacchetti dallo 0.3% al 3% circa. A ridurre la nostra lucità di analisi si metteva anche il fatto che ad avere problema era solo uno streamer che utilizzavamo per la prima volta, mentre quello che avevamo utilizzato fino ad allora funzionava alla grande (ora sappiamo che dipendeva solo dal bitrate).

Il passo successivo (e molto poco divertente) è stato quello di usare wireshark per verificare se una tale perdita di pacchetti era in qualche modo imputabile alla nostra lettura… provate a cercare in un dump 1 paccheto perso, verificando che non ci siano buchi in un continuity counter a 4 bit e con il parser di wireshark bacato. Davvero poco divertente. Comunque le perdite non c’erano!

Il problema è semplicemente legato al fatto che il sistema operativo allocca un buffer interno, settato di defaut a pochi kbytes, che può facilmente venire saturato se il thread che effettua la lettura non è sufficientemente veloce o se viene sospeso (anche solo per pochi ms).

Fortunatamnte la soluzione esiste: basta settare un buffer di ricezione più grande.

unsigned bufferSize = 1024 * 1024;
::setsockopt(s_, SOL_SOCKET, SO_RCVBUF, (const char FAR*)&bufferSize, sizeof(bufferSize));

con 1 mbyte di buffer, a 10 mbs, si possono gestire circa 800 ms di flusso: si tratta di un valore congruo che ci ha permesso di eliminare del tutto le perdite.

E’ stato lanciato nei giorni scorsi Europeana, quella che sarà la più grande libreria europea con ben due milioni di opere in 23 lingue, fra testi, spartiti, registrazioni audio, video e immagini: tutto pubblicato gratuitamente sul Web per la consultazione degli utenti.

Peccato che il servizio sia già stato sospeso:

The Europeana site is temporarily not accessible due to overwhelming interest after its launch (10 million hits per hour).

We are doing our utmost to reopen Europeana in a more robust version as soon as possible.

La domanda che mi faccio è questa: non sviluppare il sistema perché sopportasse un simile carico è stato un errore completo ed inqualificabile o ha una sua ratio ?

Nel mondo reale, è infatti necessario fare delle scelte che limitino il consumo di alcune risorse (ad esempio il tempo) nella fase di realizzazione di un progetto, con delle conseguenze (non sempre completamente prevedibili) su alcune caratteristiche finali quali ad esempio l’efficienza, scalabilità e affidabilità.

In quasi tutti i progetti sui quali mi è capitato di lavorare, (valutando a posteriori la cosa) abbiamo dedicato troppe risorse all’efficienza (specie locale), meno (ma comunque troppa) alla scalabilità (visti i carichi effettivi che abbiamo dovuto sopportare) e troppa anche all’affidabilità, nel senso soprattutto che abbiamo utilizzato architetture eccessivamente complesse, senza reali vantaggi nel contesto operativo e anzi con qualche problematica dovuta proprio al sistema di monitoraggio. Ovviamente ogni considerazione è fortemente relativa al singolo progetto, ma mi sento di fare qualche considerazione in generale:

I più grandi vantaggi in termini di efficienza, scalabilità ed affidabilità si consegueno a livello di architettura di sistema e un’architettura semplice, pur anche con alcuni limiti bene noti, è il miglior investimento possibile sia in termini di risorse utilizzate che di effettivi risultati ottenibili.

Tornando al caso Europeana, credo che non siano giustificabili. Hanno commesso un grave errore di progettazione, visto che in un caso del genere la scalabilità non puo’ non essere considerata un obbiettivo prioritario. Brutta figura.