HTML5 il markup e le API

Insieme a Gianluca Troiani ho scritto HTML5 il markup e le API
Insieme a Gianluca Troiani ho scritto “HTML5 il markup e le API”

Il 17 giugno esce in libreria e nei principali negozi online “HTML5 il markup e le API“. La guida è edita da Apogeo. L’ho scritta insieme a Gianluca Troiani, il divulgatore più stiloso che esista, già autore per Apogeo di diverse guide su CSS e di un bel manuale su Responsive Web Design.
Ci ha guidato Fabio Brivio, più che un editor, un santo, la cui pazienza io e Gianluca abbiamo saggiato a più riprese. Sulla base dei nostri test possiamo confermare quanto essa tenda asintoticamente all’infinito.

Già oggi indice e introduzione sono scaribili in PDF, gratuitamente.

HTML5 è diventata una specifica ufficiale del W3C solo pochi mesi fa. Sarebbe stato impossibile affrontarla integralmente in un unico testo. Crediamo di aver scelto quegli argomenti che possano avere maggiore rilevanza nella convinzione che un taglio pratico fosse più efficace di un tomo delle dimensioni di “Guerra e Pace”. Eppure credo che possiate trovare in questa guida una serie di argomenti che non sono mai stati affrontati in un manuale sul linguaggio di contrassegno. Mi riferisco ad esempio al capitolo 10 “Strumenti di sviluppo e debug”, un capitolo che da solo, vale l’acquisto (beh, però anche gli altri nove vanno letti!).

Buona lettura.

Fai quello che ti pare: licenze in libertà!

Il logo della licenza 'Fa quel cavolo che vuoi'
Il logo della licenza ‘Fa quel cavolo che vuoi’

Ho già scritto di come sia possibile trarre vantaggio da una licenza Creative Commons per utilizzare immagini di terzi nel pieno rispetto dei vincoli posti dagli autori. Ne esistono anche di altre, marginali ma spassose da leggere:

Nelle versioni originali i termini sono più forti ma il senso é lo stesso.
La prima licenza ha un testo ridotto all’osso che ricalca il titolo stesso. Senza dubbio sono i termini e condizioni d’uso tra i più stringati e al contempo permissivi in cui potrà mai accadere di imbattersi.
La licenza “non fare il rompiscatole” vanta una filosofia più articolata, di seguito ho tradotto un paragrafo:

Puoi usare questo codice (e per codice intendo *qualunque* cosa faccia parte di questo progetto) per qualunque scopo. Usi a fini personali, educativi, aziendali, militari e di qualunque altro genere vanno benone! Porre limitazioni a come usare qualcosa di gratuito farebbe di me un rompiscatole.

La prima delle due licenze esiste da 11 anni e per questo si trovano alcune opere, poche a dire il vero, distribuite con essa. La seconda invece è recentissima: ha solo pochi giorni di vita. Scopriremo presto se avrà maggiore fortuna o se si tratta solo di una divertente trovata del suo autore, Evan Tahler.

Mappe mentali come strumento di comunicazione

Alcuni amici apriranno a breve un bellissimo bed & breakfast dalle parti di Stresa e mi avevano chiesto qualche idea su come muoversi per la loro presenza in rete. Avevo talmente tanti punti cruciali da comunicare che temevo di lasciar fuori qualcosa, così prima di presentarmi da loro ho riportato tutto su un documento in forma di mappa mentale. Ecco cosa ne è saltato fuori:

Mappa mentale per la presenza in rete di un bed & breakfast
Mappa mentale per organizzare la presenza in rete di un bed & breakfast

Con la mappa davanti agli occhi ho potuto parlare loro a braccio e rispondere alle loro domande senza perdere mai il filo del discorso. Avevo sempre pensato a questi documenti come strumento utile per riorganizzare i propri pensieri tuttavia ho scoperto quanto sia pratico anche per organizzare un discorso che avesse la naturalezza della conversazione informale.

Il fattore autobus, gli impiegati del catasto e i costi (esorbitanti) di una documentazione inesistente

Un indice di rischio del progetto molto singolare: il fattore autobus!
Foto di Allen Watkin distribuita con licenza Creative Commons.

Il fattore autobus di un gruppo di lavoro (team’s bus factor) è l’espressione utilizzata dai due autori di Team Geek1 – per esprimere il grado di rischiosità di un progetto prodotto dall’improvvisa assenza di uno o più componenti del gruppo di lavoro.

La definizione di questo indice di rischio è:

Il numero di persone (appartenenti allo stesso gruppo di lavoro) che è necessario siano investite da un autobus prima che il progetto possa dirsi spacciato.

Minore è questo numero, maggiore è la concentrazione di conoscenza su aspetti critici del progetto e maggiore ne è la sua rischiosità.

Uno dei modi per ridurre il rischio rappresentato dal fattore autobus è quello di produrre e mantenere in vita una sana documentazione (una parte della quale sarà utile anche nei successivi progetti, ad es. Lessons Report). Tuttavia mentre programmare è affascinante, sembra quasi un’arte, equivale a creare, scrivere documentazione è come ritrovarsi d’un tratto a fare l’impiegato del catasto: non rientra tra quelle attività che generano simpatia, tantomeno entusiasmo.

Non cercherò di convincervi con le parole, proverò con un’immagine.

Costo relativo della correzione di un difetto nelle varie fasi di sviluppo software.
Costo relativo della correzione di un difetto nelle varie fasi di sviluppo software.

Questo grafico a barre2 illustra il costo relativo necessario a correggere un difetto in base alla fase del ciclo di vita di un software in cui questo baco viene scoperto. Il costo aumenta in modo significativo tanto più ci ci avvicina al rilascio in produzione.
Una sana documentazione abbassa il rischio rappresentato dal fattore autobus perché aiuta a distribuire la conoscenza tra tutti i membri del gruppo di lavoro e permette di mantenere i costi sotto controllo. Forse produrre buona documentazione non sarà affascinante ma vi permetterà di avere ancora un progetto, sensato, su cui lavorare!


1. Fitzpatrick, Brian W., e Ben Collins-Sussman. Team Geek: A Software Developer’s Guide to Working Well with Others. O’Reilly Media, 2012.
2. Wiegers, Karl E. Software Requirements by Karl Wiegers 2nd ed. Microsoft Press, 2003

Variabili e tentacoli

Tentacoli si allungano verso il robot Wall-E
Una metafora originale: la variabile come tentacolo. (foto di Donsolo distribuita con licenza Creative Commons).

Una metafora efficace è uno degli strumenti più potenti di cui dispone ogni bravo divulgatore. In “Breve storia di (quasi) tutto“, Bill Bryson vi fa ampio ricorso per dare la possibilità al lettore di comprendere ordini di grandezza infinitamente piccoli (le dimensioni di particelle subatomiche) o grandi (le dimensioni dell’universo).
Allo stesso stratagemma ricorrono spesso molti autori di manuali di informatica per novizi. Una metafora classica, in questo contesto, è quella utilizzata per spiegare cos’è e come funziona una variabile ricorrendo al concetto di contenitore.
Es. breve estratto da The JavaScript Bible 4th Edition di Danny Goodman pubblicato nel 2001:

The most convenient way to work with data in a script is to first assign the data to a variable. It’s usually easier to think of a variable as a basket that holds information.

Una variable è un contenitore, un cestino che contiene un valore. Quando il valore posto al suo interno muta è come se questo valore venisse estratto dalla scatola per essere sostituito con un altro.
La metafora è così immediata nella sua semplicità che è diventata un elemento ricorrente in testi di questo tipo. Persino nei manuali più innovativi nella presentazione del materiale di studio come la divertentissima collana Head First (casa editrice O’Reilly) il modo di presentare questo concetto è rimasto quello ben collaudato utilizzato anche da Goodman 13 anni fa: e lui non è stato certo il primo a farne uso!
Capirete perché il mio stupore è stato grande nel leggere “Eloquent JavaScript” e scoprire quanto segue:

You should imagine variables as tentacles, rather than boxes. They do not contain values, they grasp them ― two variables can refer to the same value. Only the values that the program still has a hold on can be accessed by it. When you need to remember something, you grow a tentacle to hold on to it, or re-attach one of your existing tentacles to a new value […]

(Il grassetto è mio.)
Variabili come tentacoli! Che originalità! La prossima volta che vi capita di spiegare a qualcuno che sia a digiuno di programmazione cosa sia una variable, domandatevi se non esista un’immagine più efficace di quella del classico contenitore.


Aggiornamento del 09/08/2014
Ho letto il divertente "JavaScript for Cats" un breve testo introduttivo gratuitamente disponibile sul web e anche in PDF (5,6MB – 17 pagine): un hip hip hurrah per l’autore @maxogden. Nel paragrafo "Values and variables" ecco definizione alternativa per il concetto di variabile:

[Variables] are pretty much like mailboxes. We put something in a variable, like our sentence, and then give the variable an address that we can use to look up the sentence later. In real life mailboxes have to have PO Box numbers but in JavaScript you usually just use lowercase letters or numbers without any spaces.

Murphy e le maiuscole nei titoli in inglese

La scelta di maiuscole e minuscole nei titoli di documentazione tecnica in inglese è sempre stata ostica per me, questo perché non esistono regole condivise sul tema. Qualcosa è cambiato, in meglio, la settimana scorsa quando durante la lettura di APE: Author, Publisher, Entrepreneur-How to Publish a Book, di G. Kawasaki e S. Welch. mi sono imbattuto in un lungo elenco di gaffes tipiche dell’autopubblicazione. Al primo punto di questa lista si cita la scelta impropria di maiuscole e minuscole nei titoli. Cosa più importante, si indicano un paio di semplici regole per non fare figuracce. A quanto pare sembra sia sufficiente scrivere:

  • in maiuscolo la prima parola, l’ultima e ogni nome, pronome, verbo, aggettivo e avverbio.
  • in minuscolo l’articolo iniziale, preposizioni più brevi di 5 lettere e congiunzioni.

Può darsi che l’elenco non tenga conto delle diverse linee guida oggi esistenti. A questo proposito si vedano i seguenti paragrafi in Wikipedia: Titles in Capitalization e Headings and publication titles in Letter case. Le voci sono dettagliate ma non mi aiutano a capire cosa fare.
Quelle proporste da Kawasaki e Welch nel loro testo invece sono facili da seguire. Credo che questo si ottenga al prezzo di qualche approssimazione: personalmente credo di poterlo sopportare. :)

Armato di questa certezza mi sono detto che scriverò con qualche certezza in più i miei prossimi documenti tecnici, ma la legge di Murphy unica costante di un mondo in evoluzione mi ha mostrato uno dei suoi molteplici volti in un tweet di @rauschma.

Lo stesso giorno in cui facevo definitivamente chiarezza su questo tema scopro che forse è in atto una inversione di tendenza nel mondo anglosassone. Prova ne sarebbe la recente modalità di titolazione del Washington Post (di tipo sentence case ossia seguendo le stesse regole utilizzate per i titoli in italiano :-). Meglio tardi che mai però…

Dannato Murphy!