Cubelogic Improv

Yesterday I started a new job, which requires to work on a Windows 2000 workstation. The corporate environment is set up to use Outlook as email application. I confess I never had the “luck”-ahem misfortune to actually use that bloated monster. Anyway, I don’t want to digress on why Outlook is a bloated monster, I just want to point out a design error in a very useful function for an email application: the “Find” function. Finding stuff happens at least on two levels in an email client: at the application level, to search through all your emails (or all the emails inside a folder), and at the message level, to search inside the current message. From a user point of view the concept behind the operation is the same, and the logic is almost the same. Yet the following happens in Microsoft Outlook:

• the application level “find” is located under the “Tools” menu (!?), and has a CTRL-E shortcut; moreover, there’s an “Advanced find” feature with a CTRL-SHFT-F shortcut. (By the way, why using two different letters for the same shortcuts? My head gets easily confused!)
• the message level “find” is located under the “Edit” menu and has a F4 (?!? another one?!?) shortcut. There’s no advanced find.

So, for one single concept (“finding stuff”), there are three different, distinct, non-substitutive approaches. Nicely done.

On the Mac, things are a little better. Finding stuff on the Mac is – at least – a coherent experience throughout all applications: the system provides a default search panel, usually located inside the Edit menu, with a default keyboard shortcut. That is, the find function is recognized as a common applications feature by the system native frameworks. However, even Apple’s design is flawed. The default find panel (the one you find in TextEdit for instance), has a dual function: Finding stuff, and (!) Replacing stuff. Why? To save some coding. Yet this is illogical: although the latter subsumes the former, it is not intuitive to click on “Find” to perform a “Replace” operation. I know that to actually replace something you’ve got to find it first (and so there IS a logic in clicking on “Find”), but wasn’t the Mac supposed to be for everyone? It seems like Apple just wanted to reuse the same software component (and same UI) to do two things at once. This is cool, but it makes me angry because it would have been incredibly easy to achieve the same level of code reuse, and make two separate Find / Replace panels. Or even simpler, add an explicit “Replace” menu option that actually calls the same exact panel of the “Find” option.

CSS can be pretty amazing. I just found this game entirely realized with CSS. And the entire site contains many “cutting edge CSS experiments”.

SimpleTimer is finally completed. The current nightly build is going to be pretty much the final build for v1.0. Before officially releasing it, though, I wanted to finish the redesign of the web-site, because it seems like a logical thing to do. The new design is more minimalistic yet efficient IMO. My graphic skills suck but OmniGraffle is my friend.

E.g. During the web-coding redesign efforts of today, I had the need for a nice download icon. Iconfactories, Icongardens, xiconsforyou, …. after 30 min of looking around, I realized, why paying? So I started OG and 15 minutes later I had my icon. OG is art.

Dopo un ennesima ora passata in compagnia di OmniGraffle (by the Omni Group), ho deciso di scrivere una sorta di recensione pubblicata per l’intelligente piazza di antanisoftbbs.org.

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.