altre destinazioni

ultimi post

ultimi commenti

tag principali

categorie

archivi

powered by

  • WPFrontman + WP

friends

copyright

  • © 2004-2011
    Ludovico Magnocavallo
    tutti i diritti riservati

Voi come leggete il codice?

21 febbraio 2013

1 commento

Sto facendo un lavoro per una società abbastanza nota (vi dico solo che è un plugin per WP), e alcuni dei commenti fatti al mio codice dal mio referente mi hanno un po’ spiazzato: per capire cosa intendesse ho dovuto fare lo sforzo di uscire dalle mie consuetudini di sviluppo.

Dopo qualche meditazione, sono giunto alla conclusione che i nostri rispettivi approcci alla lettura del codice sono radicalmente diversi. Il mio approccio, quando prendo in mano una classe che non ho mai visto, è prima di tutto di farmi un’idea generale di cosa faccia guardando i nomi dei metodi nel class browser. Fatto questo, scendo se è il caso nel dettaglio dei metodi che mi interessano o mi sembrano cruciali per il suo funzionamento. Per me, quindi, un metodo usato una volta sola non solo ha poco senso — e ne privilegio quindi il riuso rispetto ad altre considerazioni –, ma è addirittura dannoso in quanto inquina la comprensione a colpo d’occhio del codice.

Il mio interlocutore invece segue un approccio diverso: quando prende in mano una classe guarda subito al costruttore, e parte da lì per seguire un eventuale flusso di codice. Per lui un metodo usato una sola volta ha un senso, in quanto incapsula determinate operazioni e — se il nome è scelto con criterio — nasconde parte del codice rendendo più semplice e veloce seguire un eventuale flusso di esecuzione.

Nel caso specifico (un plugin per WP) è probabile che il suo approccio abbia senso, dato che il codice viene eseguito più o meno in sequenza, anche se la sequenza è pilotata dai vari hook di WP, cui sono agganciati i metodi pubblici della classe. Certo è che lavorando di solito in Python/Django, un approccio di questo tipo mi sembra un po’ stravagante.

Sarei curioso di sapere come altri leggono il codice, e se la differenza è dovuta più al framework (WP) che porta a pensare in maniera sequenziale, al linguaggio usato, o se è soprattutto un approccio personale. BTW, questo post è scritto usando il plugin di cui sopra, secondo il principio dell’eat your own dogfood.

WP rant #1 - tassonomie

13 luglio 2011

13 commenti

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.

questo post continua, leggi il resto

Erlang e i processi umani

30 agosto 2006

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.

Sempre più architettura

29 agosto 2006

1 commento

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?

23 agosto 2006

Code monkeyChe 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).

I guru della programmazione

5 agosto 2006

3 commenti

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.

questo post continua, leggi il resto

Lo Zen e la scalabilità delle applicazioni web

29 marzo 2006

4 commenti

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).

Ebook tecnici gratis

19 settembre 2005

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ì.

questo post continua, leggi il resto