Qix.it
tag: programmazione

Chi ha seguito un po’ le mie evoluzioni in questi ultimi anni, sa che con WP ho da tempo in corso una specie di lotta personale: è il più diffuso sistema di blogging, ha un’infinità di funzioni e tantissimi plugin, l’interfaccia è ragionevolmente comoda da usare, ma il codice è un esempio straordinario di come non si dovrebbe programmare, sia dal punto dell’architettura (quale architettura?), del disegno dei dati, degli algoritmi (quali algoritmi?), che del codice vero e proprio. In breve, ogni volta che ci metto le mani mi viene il rigetto, e ogni volta riscrivo un pezzo grande (il frontend, prima in PHP e ora in Django) o piccolo (varie funzionalità del backend).

Questa volta è il turno delle categorie, con cui sto lottando da qualche giorno. Per preservare la mia (scarsa) sanità mentale ho deciso di sfogarmi qui, in modo da a) avere magari qualche feedback, anche ne se immagino già il tono (da “ma chi te lo fa fare? Sei rimbecillito?” a “WP è una figata sei tu che non capisci una fava” – possibile), e b) inaugurare una “galleria degli orrori”, sempre che non mi stufi prima e decida di scrivere un sistema di blogging da zero. Quei due o tre lettori interessati possono continuare dopo il salto.

Dallla discussione virtuale di ieri (qui, qui e qui) è scaturito un link al bellissimo Concurrency is easy in cui Joe Armstrong sviluppa un’analogia tra l’architettura per processi e messaggi di Erlang e la vita reale. Una lettura illuminante per chi sviluppa, e decisamente consigliata anche a chi si occupa di altro.

Se non ne avete mai sentito parlare, Erlang è un linguaggio di programmazione nato in casa Ericsson verso la metà degli anni ’80, con caratteristiche specializzate per lo sviluppo di applicazioni e logiche di controllo per apparati di telecomunicazione: il funzionamento anche in caso di errori software o hardware, la possibilità di distribuire l’elaborazione su più sistemi e di svolgere processi in parallelo in maniera leggera ed efficiente. In Erlang la Ericsson ha realizzato i software di controllo di alcuni dei suoi apparati telecom più avanzati e di successo (centralini, switch ATM, ecc.) e verso la fine degli anni ’90 ha deciso di rilasciarlo con licenza Open Source.

Erlang è utilizzato, oltre che per applicazioni telecom, in tutti quei casi dove sono necessaria una scalabilità orizzontale a bassissimo costo, performance (Soprattutto di rete) eccezionali, e un’affidabilità spinta. Per avere un’idea di cosa è possibile in Erlang, date un’occhiata a questo benchmark vecchiotto ma sempre interessante tra Yaws (un server HTTP scritto, appunto, in Erlang) e Apache. Se volete capirne un po’ di più, trovate alcuni link a libri e documentazione sulla mia tag di del.icio.us.

Due bei post di oggi sottolineano l’importanza crescente dell’architettura nelle applicazioni Web: Why Processes Scale Better Than Threads su Labnotes, e Evaluating Proxy Engines and Load Balancers sul blog di Joyeur.

Interessante nel primo post il confronto tra i modelli di sviluppo per processi e thread, con una breve analisi storica delle differenze “genetiche” tra stack LAMP da una parte, e Java/Windows dall’altra. Un confronto, quello tra processi e thread, che è particolarmente rilevante nelle architetture dei sistemi fault tolerant come Stratus o Tandem (ora HP Integrity NonStop) o degli ambienti di sviluppo come Erlang, utilizzati per quei servizi che devono garantire una disponibilità prossima al 100%. Che me ne importa delle architetture fault tolerant, direte voi? Fino ad ora poco, in un prossimo futuro credo molto, dato che hanno parecchio in comune con le architetture di distributed computing che stanno assumendo una rilevanza sempre maggiore per tutte le applicazioni Internet, le stesse architetture che stanno alla base dell’infrastruttura di Google.

Passando al post di Jason su Joyeur, oltre all’annunciato benchmark dei più importante reverse proxy e load balancer Open Source e commerciali che vedremo in un futuro prossimo, mi è sembrato molto interessante il concetto di limite di performance applicato all’interfaccia di un servizio: se una istanza di un server HTTP come Mongrel (per Ruby) garantisce un certo numero di connessioni contemporanee, non è detto (anzi non è probabile) che n istanze dello stesso server poste dietro un load balancer garantiscano un aumento delle connessioni lineare, dato che l’interfaccia tra il load balancer e i server in questione può rappresentare un collo di bottiglia, che è appunto quello che si propone di misurare Jason con il suo benchmark. Architetture sempre più complesse, in cui l’esigenza di scalare per reggere carichi di traffico sempre in aumento fanno nascere nuovi problemi di tipo architetturale invece che applicativo. A proposito, sembra che WordPress.com e/o Akismet utilizzino Pound, lo stesso reverse proxy/load balancer di cui vi ho parlato qualche settimana fa.

Che carattere hanno i guru della programmazione? Ci sono tratti comuni che li distinguono dai code monkeys? Una risposta parziale a queste domande, almeno in ambito Enterprise, arriva dal bel post di Rob Walling Personality Traits of the Best Software Developers, visto passare oggi tra i bookmark di labnotes.

Tra le quattro qualità esposte nel post mi ha convinto in particolare la prima: i grandi sviluppatori di solito sono pessimisti nell’immediato, ma ottimisti sul lungo periodo. I bug o gli errori di architettura sono in agguato dietro ogni scelta e ogni linea di codice, ma niente è impossibile se si ha fiducia nelle proprie capacità, voglia di lavorare e pazienza.

Bello anche il richiamo in questo contesto a James Stockdale, uno degli alti ufficiali più decorati della storia degli Stati Uniti e prigioniero per otto anni nel terribile Hanoi Hilton, raccontato con dovizia di particolari nella bella serie di romanzi semi-autobiografici di Mark Berent (se vi interessa e leggete in inglese fatemi un fischio che vi presto i miei ebook).

Nell’era della seconda dotcom bubble, della net neutrality e del miliardo di persone online, può capitare ancora che a un perfetto sconosciuto, un ragazzo polacco che ha appena iniziato a studiare informatica, venga in mente di inviare una serie di domande a dieci tra gli sviluppatori più famosi al mondo, e che questi si prendano la briga di rispondere. Gli intervistati (almeno gli otto che hanno risposto) sono: Linus Torvalds, il creatore di Linux; Peter Norvig, direttore della ricerca a Google, famoso sviluppatore Lisp e autore di testi importanti sull’intelligenza artificiale; Guido Van Rossum, il creatore di Python; Bjarne Stroustrup, il creatore di C++; James Gosling, il creatore di Java; Tim Bray, uno degli ideatori di XML, ora alla Sun; Dave Thomas, autore di Pragmmatic Programmer e Programming Ruby; David Heinemeier Hansson, autore di Ruby on Rails; Steve Yegge, ex di Amazon ora a Google autore di libelli polemici sulla programmazione molto in voga tra la digg/reddit crowd.

Un titolo degno di Enrica per consigliarvi The Adventures Of Scaling, una serie di post sull’ottimizzazione di eins.de, sito tedesco con un buon traffico (>1m di pageviews giornaliere) recentemente riscritto in Ruby on Rails.

Un po’ di scienza, un po’ di black magic e tanto buonsenso, questi gli ingredienti indispensabili per ottimizzare architetture che sono semplici sono in apparenza. Come era prevedibile Rails è lento, la complessità architetturale (proxy, load balancers, ecc.) e la stratificazione del codice ammazzano le performance, e le ottimizzazioni più consistenti sono a livello di base dati (uno dei motivi per cui non mi sono mai piaciuti gli ORM).

FreeTechBooks raccoglie ebook tecnici gratuiti e li espone in formato directory per categorie, e tramite un comodo feed RSS. Non ci trovate certo i testi della OReilly o gli ultimi bestseller, ma qualche valido manuale (specie per avvicinarsi ad un nuovo linguaggio) sì.