Shake Improv

- WordPress 2.0.4 (motivo principale: poter usare Akismet, che sembra funzionare alla grande, per ora la spam-invasione in atto da un anno a questa parte sembra sotto controllo)
- streamlining del template principale
- nuovo nome
- rimpiazzato tutti i feed con feedburner

Ho scoperto del.icio.us un po’ in ritardo:

my del.icio.us

I just upgraded this blog to WordPress 1.5. Installation went smooth thanks to the excellent instructions provided by the WordPress team. After the upgrade I noticed some pretty big rendering problems in the admin pages using Safari. For instance, the composition page doesn’t display the Quicktags editing buttons; there are many box alignment errors; also, the upper title does not display correctly. Everything works in Camino.

The wife cooked the spiciest thing in the whole fucking world. I swear to god, I just ate it, and I am…. crying. I was crying after the very first bite, and as a consequence, I took a huge plate of it, cos I wanted to prove to myself that I am strong resilient fucker. I am not. That thing is potent. It’s like being high.

Sto finalmente completando SimpleTimer, e in un certo senso non vedo l’ora di poter pensare ad altro, anche se ho imparato varie cose sviluppando questa piccola applicazione. Ciò di cui mi preme dire, tuttavia, è un aspetto dell’attività dello sviluppatore per me assai importante. Io lo chiamo, “mettere le cose a posto”. Se il refactoring è ristrutturare, riadattare, ricompattare la struttura del software che è stata sottoposta a svariate modifiche nel corso dello sviluppo (un’attività fondamentale che provoca sublime piacere), il “mettere le cose a posto” si riferisce ad aspetti meno tangibili, o non pragmatici. (Ad ogni modo è in effetti un figlioccio del refactoring.) In breve, significa imbellire il codice. In genere ciò non comporta la modifica del significato del codice: metterlo a posto significa riformattarlo per renderlo più leggibile, cambiare i nomi di qualche variabile, aggiungere commenti, cancellare alcune vecchie note sparse qua e là nel codice, e dare ad esse una forma, al pari del codice “vero”:

• spostare e raggruppare blocchi di codice correlato,
• riformattare e correggere gli errori di indentatura del codice,
• cercare di contenere ogni statement su una sola riga ed evitare di “andare a capo” (perché andare a capo è cosa riprovevole nei miei standard), e a questo scopo magari:
• cambiare i nomi ad alcune variabili, ai fini della lettura: ciò include guardare al significato della variabile e alla sua lunghezza,
• ottimizzare l’allocazione di variabili,
• eventualmente aggiungere una o due variabili per facilitare la lettura,
• aggiungere commenti,
• riscrivere commenti,
• riformattare commenti,
• riformattare il codice,
• eccetera.

I commenti sono comunque parte del codice secondo me. Ad essi va posta la stessa cura con la quale si progettano le astrazioni. Senza i commenti, risulterà più difficile lavorare attorno alle astrazioni stesse, e potrebbe essere il caso che tali astrazioni vengano confuse durante una seconda rilettura. In aggiunta, mi accorgo di difetti o bug che prima non avevo visto.

Ad ogni modo, non metto le cose a posto per un motivo strettamente pragmatico, ma solo perché mi piace farlo. Mi sembra che il codice acquisti una nuova luce che prima non c’era.

I updated my body “specifications” page.