SugarscapeJS - Agenti artificiali per società artificiali

Sugarscape è un modello multiagente di simulazione di società artificiali (per un dato valore di società), reso famoso dal libro Growing artificial societies: social science from the bottom up, scritto da Joshua M. Epstein e Robert Axtell nel 1996. Da allora, ha dato origine a una discreta quantità di programmi che emulavano, in forma più o meno completa, il progetto delineato in quello studio, e ancora continua a produrne.
SugarscapeJS, come il nome stesso dovrebbe suggerire, è una sua versione in JavaScript, realizzata da me, in cui cerco di inserire, a mano a mano che procedo col lavoro, il maggior numero possibile degli elementi proposti nello studio originale. Al momento ho incorporato quasi tutte le regole contenute nei capitoli due, tre e nella prima metà del quattro: mancano i prestiti, ossia la seconda metà del quarto capitolo, e le malattie, che occupano il capitolo cinque. Arriveranno anche loro.
Per chi non conosce il testo di riferimento, una breve presentazione della struttura di Sugarscape, che è distinto in tre componenti di base: gli agenti, l’ambiente in cui interagiscono tra loro e le regole in base alle quali interagiscono tra loro e con l’ambiente stesso.
Gli agenti sono gli abitanti della società artificiale. Di fatto, sono quadratini colorati che si muovono sullo schermo, ma voi potete immaginarli più o meno come preferite. Possiedono alcune proprietà, come età, sesso, durata massima della vita, campo visivo, metabolismo e così via: molte di queste proprietà possono essere regolate prima di avviare la simulazione, altre sono assegnate in modo pseudocasuale al momento della nascita. Hanno anche la capacità di muoversi nell’ambiente e interagire con altri agenti, ma di questo parlerò poi.
L’ambiente è una griglia di 50 x 50 caselle, su cui gli agenti vivono e si muovono. Una scacchiera, insomma. Ogni casella può ospitare un solo agente alla volta e possiede una quantità determinata di risorse, rinnovabili col tempo. L’ambiente può presentare una distribuzione delle risorse molto diversa, ma qui ho scelto, per il momento, la struttura più famosa e più spesso associata con Sugarscape, con le risorse concentrate in due “picchi” (o quattro, se si sceglie di usare una seconda risorsa). Le risorse sono zucchero (di base) e spezia (opzionale).
Le regole sono un insieme di comandi che determinano il modo in cui gli agenti si comportano. La regola di base per il movimento, ad esempio, prevede che ogni agente cerchi, all’interno del proprio campo visivo, la più vicina casella libera che contiene la maggiore quantità di risorse, che si muova per occupare quella casella e raccolga tutto il contenuto. Vi sono poi regole che determinano il modo in cui le risorse ricresceranno, il modo in cui l’agente interagisce con altri agenti, sia per la riproduzione, sia per il combattimento, sia anche per la “conversione” di chi appartiene a una cultura diversa, e altre regole ancora arriveranno, per commerciare e determinare come avvenga la trasmissione di malattie all’interno di Sugarscape: in molti casi, è possibile decidere quali regole applicare e quali ignorare, così da simulare ciò che vogliamo e osservare solo i risultati che ci interessano.
Sulla base di questi tre componenti, Sugarscape si ripropone di provare a costruire le dinamiche di una società “dal basso”, ossia impostando solo semplici regole generali e osservando poi il modo in cui si svolge l’interazione tra agenti e territorio, seguendo le suddette regole. Interazione che spesso è interessante, in effetti, e forse anche istruttiva, ma su questo punto non mi pronuncio. A ogni modo, vediamo le regole disponibili finora.
Ogni agente può vedere fino a una certa distanza, stabilita casualmente alla nascita, e ha bisogno di consumare a ogni turno una certa quantità di zucchero (e spezia, se usiamo due risorse) per mantenersi vivo: primo obiettivo è dunque la ricerca di zone con tanto zucchero, da raccogliere e consumare. E già questo produce un notevole effetto-formicaio nella simulazione, oltre a introdurre una selezione naturale che porta alla rapida estinzione di chi ha campo visivo scarso e metabolismo elevato. Se gli agenti morti non sono sostituiti, si arriva presto a uno stallo, che ci dice quale sia la capacità di portata per quell’ambiente.
Introducendo le stagioni, modifichiamo il modo in cui lo zucchero (e la spezia, ma ormai dovreste aver capito l’andazzo) è rigenerato nell’ambiente: se prima era uniforme su tutto il territorio, adesso l’ambiente è diviso in due zone, nord e sud, e in quelle due zone si alternano ogni X turni estate (rigenerazione massima delle risorse) e inverno (rigenerazione minima delle risorse). Gli agenti cominceranno a migrare in massa al cambiamento delle stagioni.
Già sulla base di questo, possiamo osservare come si distribuiscano le ricchezze tra gli agenti, ossia la quantità di zucchero posseduta da ognuno. O almeno, potremmo vederlo: in realtà, per adesso ho solo un grafico con l’indice Gini, ma in futuro introdurrò anche tabelle che mostrino in modo meno tecnico e più comprensibile la tendenza generale a una disparità sociale piuttosto accentuata.
Una vera interazione tra agenti compare solo col capitolo tre del libro. Per prima cosa, si può introdurre la riproduzione sessuale, come alternativa alla rigenerazione causale a ogni decesso: ogni agente in età fertile, e con un quantitativo minimo di risorse, a ogni turno cercherà tra i propri vicini un potenziale partner, che sia di sesso opposto, di età fertile, che abbia risorse e che non sia suo parente stretto (tecnicamente, Sugarscape non vieta l’incesto, nella sua formulazione originaria, ma io ho voluto introdurre questo limite, per renderlo più realistico e “umano”, così come il limite di una sola riproduzione per turno). Questa regola da sola cambia gli equilibri ambientali, portando a una continua oscillazione nel numero di agenti supportati. Possiamo poi introdurre anche l’eredità, ossia la possibilità che i figli ottengano una parte uguale delle risorse dei genitori, alla morte di questi: principale effetto sarà una tendenza ad accentuare le disparità sociali.
Dopo l’eredità, arriva l’ereditarietà. Qualche centinaio di turni ci mostra come, anche senza averla espressamente introdotta, la selezione naturale porta ad avere agenti con visione sempre migliore e un metabolismo che rapidamente crolla al minimo. Una tendenza che avevamo già visto anche in assenza di riproduzione, ma che va alle stelle quando la riproduzione è presente. Curiosamente, però, l’aumento della visione non è costante e di tanto in tanto si può invertire.
Ma una società non è solo sesso, nonostante YouPorn dimostri il contrario. Assieme alla possibilità di riproduzione sessuale, esistono anche due “culture” di base, indicate col colore rosso e blu. Sono di fatto una lista di numeri binari, la cui lunghezza è regolabile a piacimento, ma è meglio che sia sempre dispari: se prevalgono gli 1, il nostro agente apparterrà a una cultura; se prevalgono gli 0, apparterrà all’altra. Le culture non sono stabili e possono cambiare nel corso della simulazione, a seconda del modo in cui gli agenti interagiscono tra loro: le culture si intrecciano al momento della nascita di nuovi agenti, ma anche solo muoversi all’interno di Sugarscape porta gli agenti in contatti con altri agenti, in un continuo influenzarsi a vicenda. Se così vogliamo.
Dalla cultura alla guerra. Un’altra regola opzionale ci permette di decidere che le due culture non coesistano pacificamente in Sugarscape: se così vogliamo, rossi e blu cercheranno di sopraffarsi a vicenda, fino a che ne resterà uno solo, oppure fino a che non si raggiungerà un equilibrio da guerra fredda, con le due culture rinchiuse nelle proprie zone di influenza e in continuo contrasto lungo i confini.
Col capitolo quattro arriva una seconda risorse, che affianca lo zucchero: è la spezia. Grazie alla presenza di due risorse, gli agenti possono adesso commerciare, scambiando il surplus per ottenere i beni di cui hanno maggiore scarsità. In teoria. In pratica, il raddoppiamento delle risorse comporta anche un raddoppiamento delle possibilità di morire e spesso la nostra simulazione si chiuderà con l’estinzione totale degli agenti: quando non succede, però, otteniamo un passabile commercio.
Gli agenti, poi, sono divisi tra due categorie di commercianti: aggressivi e cauti. Un agente cauto scambia solo il proprio surplus, solo nella misura minima e punta a un profitto modesto, ma costante: tipica formica, per intenderci. Un agente aggressivo, invece, si butta negli scambi anche a rischio di perderci, non si ritira mai da una offerta e punta sempre al colpaccio. A volte gli riesce.
I prestiti tra gli agenti costituiscono la seconda parte del capitolo quattro, ma non li ho ancora implementati, proprio come non ho ancora implementato il capitolo cinque, dedicato a malattie e sistemi immunitari. Altra cosa che manca, presente nel capitolo due, è la produzione di inquinamento, che al momento ho escluso in quanto la formulazione data dal libro non è molto interessante e non aggiunge granché alla simulazione. Magari la riesumerò in futuro.
In breve, questo è SugarscapeJS. La velocità della simulazione varia molto a seconda del browser utilizzato, ma dovrebbe comunque funzionare su ogni browser decentemente moderno, anche se non è ottimizzato per dispositivi con schermi piccoli. Raccolta e produzione di dati e grafici avrà bisogno ancora di molto lavoro, ma la simulazione è già utilizzabile e fornisce alcuni risultati. Se si è di bocca buona, almeno.

Prova SugarscapeJS

Scantanador, un roguelike "in fieri"

Cliccate qui per provare Scantanador 0.0.1 Alpha.
Scantanador è il nome di un roguelike programmato da me, in JavaScript, e basato sulla libreria ROT.JS, libreria JavaScript (che sorpresa!) che contiene diverse funzioni per semplificare la vita a chi, per una qualunque forma di pazzia, decida di programmare un nuovo roguelike. Come potete immaginare, io sono tra questi pazzi.
I comandi sono semplici e sono più o meno i classici di un roguelike. Voi siete la @ al centro dello schermo, vi muovete coi tasti freccia, il tastierino numerico o clicando/toccando il quadrante dello schermo corrispondente alla direzione. Premendo [Invio], o cliccando/toccando l'icona @, potete aprire un menu, con le azioni principali. Il tasto [?] vi mostrerà una lista di tasti, coi comandi corrispondenti.
Al momento, Scantanador è poco più di uno scheletro, ancora in ampia fase di lavorazione e con ponteggi e impalcature sparsi più o meno ovunque. Se il mio obiettivo fosse stato quello di creare un 7DRL, ossia un roguelike programmato in sette giorni, il lavoro sarebbe ormai molto vicino alla conclusione: basterebbe annodare un paio di fili, infilarci un mostro finale, magari due o tre oggetti in più e stop, il gioco è fatto. In tutti i sensi. Siccome però, nella mia pazzia o incoscienza, progetto di realizzare qualcosa di molto più ampio, la conclusione è rinviata a un futuro più o meno lontano, ma che prima o poi arriverà. Almeno, è quanto spero.
Il modello a cui più mi sono ispirato, nella progettazione, è stato ToME, storico roguelike degli anni ‘90 e oltre, nonché uno dei pilastri del genere. Per essere precisi, il mio modello è stato la vecchia versione di ToME, ossia quella che ancora si chiamava Troubles of Middle Earth e che ha chiuso i battenti con la versione 2.3.5, per rinascere poi sotto altro nome, ma identica sigla. Perché una versione così vecchia? Perché è la versione che ho giocato e amato di più, e che mi ha fatto perdere piacevolmente una montagna di ore, ai tempi dell’università: il gioco più recente è senza dubbio migliorato e più ampio, ma alla nostalgia non si comanda. E poi tutti i gusti sono guasti, no?
Nella versione definitiva, quando arriverà, Scantanador presenterà più dungeon, collegati tra loro da un mondo di superficie, oppure un solo, lunghissimo dungeon: ancora non ho deciso, ma il tempo per scegliere non mi manca, con tutto il lavoro ancora in corso. Per il momento, questa versione di prova, versione alpha che più alpha non si può, presenta un solo dungeon, di dieci livelli, e senza mostro finale. Insoddisfacente? Certo, ma è anche una versione di base, che serve a me più che altro come palestra in cui provare le funzionalità che vado via via aggiungendo: potete considerarlo una demo, in altri termini, almeno per il momento.
Trattandosi di un roguelike in JavaScript, è quindi destinato a essere utilizzato soprattutto in un browser e da dispositivi di ogni tipo e dimensione, finora mi sono concentrato principalmente sul supporto vari tipi di input: in pratica, può essere giocato utilizzando la tastiera, nella migliore tradizione dei roguelike, ma può anche essere giocato utilizzando il mouse, oppure le ditate sullo schermo. In teoria. In pratica l’ho potuto collaudare soltanto su un ristretto numero di dispositivi, per adesso, per cui ogni segnalazione di malfunzionamento sarà gradita.
Altro aspetto su cui ho lavorato molto, aspirando a un gioco di lunga durata, è il salvataggio delle partite. Il salvataggio utilizza il localStorage, per cui la partita è salvata all’interno del browser che state utilizzando: se riaprite il gioco con lo stesso browser, dovreste pote ripartire dal punto in cui avevate salvato. A meno che non siate morti dopo il salvataggio, ovviamente: come ogni roguelike che si rispetti, Scantanador abbraccia la filosofia del permadeath, ossia “si muore una volta soltanto”. Quando il vostro personaggio muore, i salvataggi sono cancellati. Punto. Ovviamente, utilizzando il localStorage voi potete imbrogliare quanto volete, se avete una minima conoscenza del JavaScript, perché i dati del salvataggio sono nelle vostre mani, facilmente accessibili.
Riassumendo, vediamo di elencare in breve ciò che è già presente in questa prima versione del gioco, (chiamiamola Scantanador 0.0.1) e ciò che sarà introdotto più avanti.
Già sviluppato:
-supporto per tastiera, mouse, touch;
-salvataggio e caricamento delle partite;
-combattimento corpo a corpo, più alcune armi;
-alcune armature, utilizzabili da player e mostri;
-combattimento a distanza (semplificato), più alcune armi;
-pozioni con effetti immediati o prolungati (alcune);
-oggetti con poteri speciali (alcuni);
-player e mostri possono raccogliere, gettare e utilizzare (alcuni) oggetti;
-mostri con poteri speciali (alcuni);
-meccanismo di combattimento riadattato dal d20 system.
Da sviluppare:
-migliorare il combattimento a distanza;
-nuovi mostri, nuovi oggetti, nuovi poteri;
-mostri più intelligenti (o meno stupidi);
-esperienza e passaggio di livello;
-classi per il player;
-abilità speciali per player e mostri;
-nuovi dungeon/ampliamento dungeon;
-mostro finale;
-magia;
-trappole;
-oggetti da identificare;
-correggere singolari/plurali;
-PNG?
E molto altro, al primo posto la correzione di tutti gli errori che troverò strada facendo. In pratica, come dicevo all’inizio, per adesso ho posto le basi: il resto consiste nell’edificare sopra queste basi. Sperando che reggano.
Ah, la grafica è ovviamente in ASCII: sono tradizionalista, ma soprattutto possiedo le capacità artistiche di un merluzzo. Inserire immagini e trasformarlo in un gioco contemporaneo non sarebbe difficile; realizzare immagini decenti lo è, almeno per me. Che poi in realtà non è proprio definibile come ASCII; dato che utilizzo caratteri Unicode, ma non importa.

Scantanador - A roguelike "in fieri"

Click here to try Scantanador 0.0.1 Alpha.
Scantanador is the name of a roguelike in JavaScript, which I’m programming. It utilizes the library ROT.JS, which is a very nice tool to help a poor, distressed programmer, who is working on a roguelike: its author seems to have a difficult relationship with semicolon and suchlike, but that’s another matter. It’s a good library, if you are crazy enough to program a roguelike. I am.
Command keys are quite easy and are, more or less, those you find in any roguelike. You are the @ in the centre of the screen and you can walk around by using arrow keys, numpad, or clicking/tapping the portion of the screen corresponding to a given direction. Pressing [Enter], or clicking/tapping on the @ icon, you can access to the menu, which lists all the main commands. The ? key will show you a list of all the keys used in the game.
Right now, Scantanador is little more than a skeleton, a bare-bone structure on which I am still working and a lot of work is still needed. A lot. If I were aiming for a 7DRL, which is to say a roguelike wrote and concluded within 7 days, I would be almost there: add a little more stuff, a final boss, maybe another pair of objects and the game would be ready. But not. Since I am crazy enough to think about a bigger game (way bigger), I still have a long way to go, before having a game which, somehow, can be seen as completed. Some day I’ll get there, for sure. Or, at least, I hope.
My model is ToME, mainly, which is a historical roguelike from ‘90s, but still alive and kicking. More or less. In truth, the version I’m using as an inspiration is not exactly alive and kicking, being the old 2.3.5 version, which was still called “Troubles of Middle Earth”, before kicking the bucket and being reborn with a different name and quite a different world. Why am I looking and the old version, if there is a new one, which is richer and probably better in every aspect? Because ToME 2.3.5 (and all the previous versions) is the one I played and loved the most, the game on which I wasted away many and many hours, when I was in college. It’s nostalgia, pure and simple, and I know it, but... it’s a matter of tastes, right? And all tastes are a waste, in the end. More or less. Let’s say so, okay?
Ina distant day, Scantanador will posses many dungeons, all connected by a wilderness or maybe just one dungeon, but extremely deep: I’ m not sure, yet, but I still have plenty of time, to make up my mind about it. There is still an awful lot of work, for me. Anyway, this demo version (which is really an Alpha release, but very alpha) has only one dungeon, with 10 levels, and without a final boss. Not satisfying? I know, I know, but it’s a first release, which manly serves to me as a playground, where I can test new stuff and see if everything works correctly, any time I add some new object, monster or power. It’s just a demo, as I said.
Being a JavaScript game, it should work on a very wide range of browsers and devices, and work fine everywhere. Or at least fine enough. This is the reason why I concentrated on supporting many kind of input: you can play it with your keyboard, with a mouse, tapping on a touchscreen and so on. Or, at least, you should be able to: I could only test it on a limited number of devices and browsers, so I’m not sure that it will really work everywhere. If you find something wrong, just tell me and I’ll fix it.
Given that I’m trying to program a game, which could last many hours, I also spent quite some time on the save and load process. The game is saved inside the browser you’re using to play it, in its localStorage object: if you open Scantanador with the same browser, you should be able to restart a previously saved game. Unless you died after the last save, of course: as a true roguelike, at least in spirit, Scantanador follows the philosophy of permadeath, which is to say “you can only die once”. Once you die, your character and all the saved game are deleted. That’s all. Of course, since it utilizes the localStorage, you can cheat the living shit out of a saved game, if you really want and if you have a minimal working knowledge of JavaScript: all the data are in you browser and very easy to access.
In short, let’s see what has already been implemented in Scantanador (version 0.0.1) and what is still waiting in line.
Already here:
-keyboard, mouse, touch support;
-saving and loading of a game;
-melee fight, plus some weapons;
-some armours, which can be equipped by player and monsters;
-ranged fights (simplified), plus some ranged weapons;
-potions with immediate and prolonged effects (some);
-items with special powers (some);
-player and monsters can pick up, drop and use (some) items;
-monsters with special powers (some);
-slightly changed d20 system rules;
Still waiting:
-improving the ranged fight;
-new monsters, items, powers;
-smarter monsters (or at least less stupid);
-experience points and level-ups;
-classes for the player;
-special abilities for player and monsters;
-new dungeons/bigger dungeon;
-last boss;
-magic system;
-traps;
-unidentified items;
-fix singular/plural;
-NPC?
And much more, starting from all the bugs I will surely have to squash. Put another way, as I said at the very beginning, I only put the basis for a game: now I must build over it, hoping that everything will be solid enough to hold.
Ah, graphics are obviously in ASCII: I’m quite the traditionalist, but I am also as artistic as a cod. It would be easy to add graphical tiles to the game and turn it into something more modern, but it’s not easy to make decent graphical tiles, at least for me. And, by the way, it’s not really ASCII, since I’m using Unicode characters, but never mind.

Realizzare semplici animazioni in CSS

Già in precedenza avevo dedicato una serie di post al CSS e al suo utilizzo, per curare la impaginazione e in generale la grafica di uno EPUB. Tornerò oggi nei paraggi, parlando di una delle principali novità introdotte col cosiddetto CSS3 (etichetta di comodo, sotto cui sono raccolte svariate cose), ossia le animazioni. Dubito che potranno essere di qualche utilità, per realizzare uno e-book (o almeno io lo spero, dato che un libro con immagini animate, che si spostano qui e là nella pagina, non è proprio di mio gusto), ma può comunque essere vantaggioso tenere in considerazione questa possibilità.

Quando si pensa ad animazioni più o meno belle e sensate, in una pagina web, di solito il primo strumento a cui le si collega è il JavaScript. Niente di strano: dopotutto, il JavaScript è nato proprio per dare vita ai siti, che agli albori del web erano alquanto statici, e la manipolazione degli elementi di una pagina è tuttora uno dei suoi principali usi, almeno a livello di web design. La possibilità di creare e gestire animazioni utilizzando il CSS, però, ci offre in alcuni casi una valida alternativa, soprattutto in termini di consumo di risorse e di velocità: se tutto ciò che dobbiamo fare è muovere una immagine o modificarne la visibilità, il CSS è la soluzione migliore.

Le animazioni, dunque. Ciò che ci è offerto da questa recente funzione del CSS è la possibilità di animare il passaggio da un insieme di proprietà a un altro, una sola volta o ripetutamente, usando animazioni lineari o con effetti particolari. Ad esempio, se fissiamo come punto di inizio un valore di opacity: 0 e come punto di arrivo un valore di opacity: 1, l'elemento a cui è assegnata questa animazione diventerà visibile a poco a poco, nel tempo di durata della animazione. Se fissiamo invece due diversi valori di color, uno come inizio e uno come fine, sarà il colore dell'elemento a cambiare a poco a poco. In breve, possiamo animare il passaggio da (più o meno) qualsiasi proprietà del CSS a qualunque altra proprietà, per gli elementi che scegliamo.

I passaggi necessari per utilizzare una animazione sono due: creare l'animazione e assegnarla a uno o più elementi della pagina. La prima cosa da fare, dunque, è definire la regola nel nostro foglio di stile CSS; la regola per una animazione è leggermente diversa da una normale regola del CSS, ma non troppo. Questa è la struttura di base.

@keyframes nome {
    from {

    }
    to {

    }
}

La parte più insolita è probabilmente costituita dallo @ iniziale, che contraddistingue questo e altri tipi di nuove regole, ma non è niente per cui perdere il sonno: possiamo considerare il blocco @keyframes come una formula, per introdurre la sequenza di operazioni che compongono la nostra animazione, e vivere serenamente.

Ciò che ho indicato come "nome" può essere un nome qualunque, che caratterizzerà la nostra animazione: scegliete quello che preferite, purché ogni animazione abbia un nome diverso dalle altre. Il nome ci servirà più avanti, per assegnare questa animazione agli elementi che animeremo.

All'interno della prima coppia di parentesi graffe dovremo elencare le varie tappe della nostra animazione; come è ovvio, le tappe dovranno essere almeno due, ossia un inizio e una fine. Dopo la parola from, elenchiamo le proprietà di partenza: il colore che un elemento possiede all'inizio della nostra animazione, oppure le sue dimensioni iniziali, o qualsiasi altra cosa cambierà nel corso del processo. Dopo la parola to, invece, elenchiamo le proprietà che l'elemento possiederà alla fine del processo. Una volta fissato inizio e fine, la transizione sarà gestita automaticamente dalla animazione.

Se la nostra animazione non dovrà passare direttamente dallo stato iniziale a quello finale, ma vogliamo che attraversi particolari fasi intermedie, le possiamo specificare utilizzando un valore in percentuale. Ad esempio,

from {
    color: red;
}
50% {
    color: white;
}
to {
    color: blue;
}

descrive una animazione che modifica il colore di un elemento: si parte dal rosso, si arriva al bianco a metà dell'animazione (ossia al 50%) e si conclude con un colore blu. Se vogliamo, poi, possiamo esprimere in percentuale anche from e to, invece di usare le parole: non farà alcuna differenza. Se ci piacciono particolarmente i numeri, dunque, potremo scrivere 0% al posto di from e 100% al posto di to, il che renderà forse più chiare le fasi intermedie della nostra animazione. Per ogni tappa, come è ovvio, possiamo inserire tutte le proprietà CSS che vogliamo, in base a ciò che è necessario per la nostra animazione: se vogliamo modificare contemporaneamente la posizione, il colore e la dimensione di un elemento, basterà elencare tutte le rispettive proprietà CSS dentro le varie tappe, una dopo l'altra. Ad esempio,

from {
    width: 200px;
    background-color: red;
}
to {
    width: 400px;
    background-color: blue;
}

porterà il nostro elemento da una larghezza di 200 pixel a una larghezza di 400 pixel, modificando nel frattempo il suo colore di sfondo da rosso a blu.

Una volta costruita la regola, dovremo assegnarla a un elemento. Operazione molto semplice: basta aggiungere alcune proprietà alla normale regola CSS, che abbiamo creato per quell'elemento. Le proprietà obbligatorie sono due: animation-name, che avrà come valore il nome della nostra animazione, e animation-duration, che avrà come valore la durata dell'animazione. Se ad esempio vogliamo applicare agli elementi di classe .invisibili una animazione di nome fantasma, che avrà una durata di 3 secondi, scriveremo

.invisibili {
    animation-name: fantasma;
    animation-duration: 3s;
}

Questo è il minimo indispensabile. Ci sono poi altre proprietà, che ci permettono un maggiore controllo sulla nostra animazione, e che probabilmente vorremo usare, ma le uniche strettamente necessarie sono il nome e la durata. Vediamo rapidamente le altre proprietà.

animation-timing-function ci permette di controllare il ritmo con cui la nostra animazione è eseguita. Se le assegniamo un valore linear, il ritmo sarà regolare dall'inizio alla fine; se assegniamo un valore ease, la nostra animazione partirà lentamente, si velocizzerà al centro e rallenterà verso la fine. Esistono diversi valori che possiamo assegnare ed è meglio testarli sul campo, per decidere il più adatto alle nostre esigenze.

animation-delay ci permette di eseguire la nostra animazione con un certo ritardo, espresso in secondi: con un valore di 2s, ad esempio, l'animazione partirà dopo due secondi, invece di partire subito.

animation-iteration-count ci permette di stabilire quante volte dovrà essere ripetuta la nostra animazione (se la vogliamo ripetere): basta assegnare come valore il numero di ripetizioni da eseguire, oppure la parola infinite, se vogliamo eseguirla ininterrottamente, per tutto il tempo in cui la pagina è aperta (attenzione: può diventare molto fastidioso per i visitatori).

animation-direction può essere usata per modificare la direzione in cui sarà eseguita la nostra animazione: assegnandole il valore alternate, l'animazione sarà eseguita alternatamente da from a to e da to a from, se abbiamo scelto di ripetere la nostra animazione.

animation-fill-mode, infine, ci permette di controllare l'aspetto finale del nostro elemento: se le assegniamo il valore forward, l'elemento manterrà l'aspetto che possiede alla fine della nostra animazione; in caso contrario, a fine animazione tornerà al suo aspetto iniziale.

Se non abbiamo voglia di scrivere una sfilza di proprietà extra, possiamo usare la formula abbreviata, proprio come accade per le proprietà font, margin, padding e altre. In questo caso, useremo la proprietà animation, seguita dalla lista di tutti i valori. Ad esempio,

animation: prova 3s linear 4 alternate 2s forward;

è una comoda abbreviazione per questa sfilza di proprietà:

animation-name: prova;
animation-duration: 3s;
animation-timing-function: linear;
animation-iteration-count: 4;
animation-direction: alternate;
animation-delay: 2s;
animation-fill-mode: forward;


Ovviamente non è necessario utilizzare tutte le proprietà, nella forma abbreviate, ma è utile rispettare questo ordine: nome, durata, timing, numero di ripetizioni, direzione, ritardo, fill mode.

Siccome poi questa funzione CSS non è ancora standardizzata su tutti i browser, è molto probabile che vi ritroverete costretti a utilizzare i vari prefissi, per alcuni o per tutti i browser: sperimentate prima le animazioni nella forma senza prefissi, come abbiamo visto sopra e poi, se necessario, aggiungete via via le alternative ci prefissi: -webkit- per Chrome e Safari, -moz- per Firefox, -o- per Opera. Con Internet Explorer, le animazioni funzionano soltanto dalla versione 10 in poi, ma almeno non richiedono prefissi. Lo so, è un lavoraccio, ma per adesso è necessario.

Gli strumenti per sviluppatori di Google Chrome

Tra gli strumenti disponibili nel menu di Google Chrome, la voce Strumenti per sviluppatori è probabilmente la più importante e utile, almeno per chiunque sia interessato anche al “dietro le quinte” di una pagina. Come il nome stesso suggerisce, questa voce raccoglie una serie di strumenti, pensati principalmente per chi si occupa di produrre pagine o applicazioni web, ma in linea generale possono essere utili e interessanti anche per chi non si sognerebbe mai di diventare uno sviluppatore, ma vuole solo saperne un po’ di più e vedere come funzionano le cose.

Gli strumenti disponibili sono otto e descriverli tutti quanti in un colpo solo occuperebbe troppo spazio: per semplificare il mio lavoro, dunque, li dividerò arbitrariamente e li descriverò un poco alla volta. Partirò oggi dalle due schede che, probabilmente, saranno usate più spesso: Elements e Console, ossia la prima e l’ultima nell'ordine in cui Google Chrome ce le offre.

Elements è la scheda in cui possiamo esaminare il contenuto effettivo della pagina che abbiamo davanti: più precisamente, ne possiamo esaminare il contenuto finale. Nel menu di Chrome esiste già una funzione “Visualizza sorgente”, che ci mostra il codice di una pagina: la scheda Elements è simile, ma non identica. Visualizzando il codice sorgente, infatti, noi vediamo il contenuto del file HTML originario, senza le modifiche che possono essere state effettuate utilizzando il JavaScript; la scheda Elements, invece, ci mostra il codice della pagina finale, dopo che tutte le modifiche tramite JavaScript sono state applicate. Inoltre, sempre da qui possiamo anche esaminare il CSS per ogni componente della pagina, nella colonna di destra della scheda.

Una buona norma della programmazione web prescrive che il contenuto di una pagina sia sempre e comunque accessibile, anche per chi ha disabilitato il JavaScript: se questa norma fosse sempre rispettata, la visualizzazione del codice sorgente dovrebbe mostrarci già tutto il testo, tutte le immagini e tutti gli altri elementi contenuti in una pagina. Come la maggior parte delle buone norme, però, non sempre è rispettata alla lettera; di conseguenza, una parte più o meno cospicua del contenuto, in molti siti, è aggiunta successivamente col JavaScript. Sempre attraverso il JavaScript, parti della pagina possono essere nascoste o mostrate, modificando il CSS corrispondente, col risultato che la pagina davanti a noi è spesso molto diversa, rispetto al contenuto descritto nel file HTML iniziale.

Elements ci mostra dunque un file HTML virtuale, che descrive la pagina così come ci appare sullo schermo in questo momento. Se una immagine è stata aggiunta col JavaScript, Elements ce la mostrerà nel punto in cui è stata aggiunta, con tutti i tag HTML e tutte le regole di stile che le sono state assegnate, proprio come se avesse fatto parte fin dall’inizio della pagina. Se una parte della pagina è stata invece nascosta, in seguito a una qualche nostra azione, non la vedremo apparire in questa sezione.

Come è facile da intuire, Elements è molto utile per esaminare il contenuto della pagina, sia mentre noi ci stiamo lavorando, sia quando siamo curiosi di studiare il lavoro altrui, ma questa è solo una parte delle sue funzioni. Oltre a guardare, infatti, in questa scheda possiamo anche modificare il contenuto di una pagina, in modo molto semplice. O almeno, molto semplice se sappiamo orientarci tra i nodi di una pagina HTML e se conosciamo HTML e CSS: dopotutto, questi si chiamano “strumenti per sviluppatori” e la conoscenza dei linguaggi per la programmazione web è data per scontata, essendo rivolti agli sviluppatori di pagine e siti. Non ci piace il colore dello sfondo, oppure il colore dei caratteri? Da qui lo possiamo modificare. Clicchiamo prima col tasto sinistro del mouse sul nodo da modificare e poi, nella colonna di sinistra, cerchiamo la proprietà CSS che ci interessa e clicchiamola col tasto sinistro: in questo modo, la potremo modificare a nostro piacimento.

Se invece clicchiamo su un elemento HTML col tasto destro del mouse, si aprirà un menu contestuale, in cui ci saranno offerte altre possibilità di intervento: ad esempio, potremo modificare lo HTML, selezionando la voce “Edit as HTML”, oppure rimuovere quel particolare nodo dalla pagina, selezionando “Delete node” (se un banner vi ha rotto le scatole, potrete cancellarlo da qui). Eliminare un nodo, ad esempio, può essere un sistema rapido, per levarsi dai piedi quei fastidiosi avvisi, che impediscono di leggere una pagina fino a che non avete cliccato “Mi piace” su una pagina Facebook, oppure fino a che non vi siete registrati e cose simili.

Ovviamente, ogni modifica apportata alla pagina varrà soltanto per noi: ciò che modifichiamo è la copia locale, caricata nel nostro browser, e non la pagina originale, contenuta nel sito. Nonostante questo, è pur sempre uno strumento valido, per adattare le pagine ai nostri gusti o per rapidi interventi di correzione, oltre alle sue normali funzioni di studio ed esame della pagina.

Console è la scheda di chi ama smanettare col JavaScript. Può essere utilizzata per eseguire brevi porzioni di codice nella pagina (sempre sul lato cliente, sia chiaro), ma è molto più importante il suo ruolo di semplice ambiente di sviluppo per JavaScript. Di fatto, la console è uno spartano (ma poi neanche tanto spartano, nel caso di Google Chrome) REPL, ossia uno spazio in cui possiamo dialogare col JavaScript, direttamente nel nostro browser: scriviamo un comando o una funzione, premiamo Invio, e la console ci restituirà subito il risultato del comando o della funzione. Se stiamo studiando o imparando il JavaScript, possiamo trascorrere ore in perfetta letizia, dialogando col nostro linguaggio di programmazione; se invece stiamo lavorando alla realizzazione di una pagina e qualcosa va storto, è qui che ci saranno segnalati gli errori relativi al JavaScript.

Chiunque abbia mai utilizzato un REPL in vita propria, magari trastullandosi col Lisp o altri linguaggi di programmazione affini (anche Scala va bene), non dovrebbe avere problemi con la Console. Un REPL è un Read-Eval-Print-Loop, ossia un ciclo continuo di lettura, esecuzione e stampa del codice: noi scriviamo un comando, una funzione o qualsiasi altra cosa, premiamo Invio, e il comando (o funzione, o altro) sarà eseguito e poi scritto sullo schermo, dopodiché la console sarà pronta per il comando successivo. Ovviamente, comandi e funzioni dovranno essere in JavaScript, per poter funzionare, ma nel peggiore dei casi potete sempre utilizzarla come calcolatrice alternativa.

Come dicevo all’inizio, la console può essere utilizzata fondamentalmente in due modi: come ambiente di sviluppo per il JavaScript, oppure per alterare il contenuto della pagina che abbiamo davanti.

Come ambiente di sviluppo, è spartano ma funzionale, nonché molto utile se stiamo imparando (o se vogliamo imparare) la programmazione in JavaScript. Possiamo usarla per scrivere ed eseguire funzioni, ad esempio, ma con un’avvertenza: se vogliamo andare a capo, non dobbiamo premere Invio, ma Shift+Invio. Se premiamo Invio da solo, il codice sarà eseguito e ci ritroveremo con un messaggio di errore, se la nostra funzione era a metà. Dettagli a parte, ha il vantaggio considerevole di suggerirci i nomi di variabili, metodi, oggetti e funzioni a nostra disposizione: se cominciamo a scrivere qualcosa, la console ci mostrerà tutti i modi validi in cui possiamo concludere quella parola, proprio come accade in ambienti di sviluppo più raffinati. Ad esempio,

La console ricorda anche tutto ciò che abbiamo già fatto, durante la nostra sessione di lavoro: se abbiamo creato nuove variabili globali, oppure nuove funzioni, o nuovi oggetti, anche i loro nomi appariranno tra i suggerimenti, accanto a funzioni, metodi e oggetti già inclusi nel motore JavaScript di Google Chrome. Di fatto, la console offre tutto ciò che è strettamente indispensabile, per programmare in JavaScript.

Se invece vogliamo utilizzarla per alterare la pagina corrente, il principio di base è lo stesso, ma cambia il contesto: dalla console avremo accesso a tutto il JavaScript della pagina su cui l’abbiamo aperta, incluse eventuali altre librerie importate (jQuery, ad esempio, che è spesso presente). Se stiamo allegramente sprecando tempo con un gioco in JavaScript e vogliamo barare, possiamo farlo da qui, modificando ad esempio il numero assegnato alla variabile che contiene il punteggio. Ogni modifica avrà effetto a livello locale, ossia nella pagina aperta sul nostro browser: se dunque abbiamo usato la console, per truccare il nostro punteggio in un gioco, il nostro punteggio truccato non avrò effetto su una eventuale classifica dei migliori punteggi, ospitata nel sito del videogioco. O almeno, non dovrebbe avere effetto, a meno che il gioco non sia stato progettato molto male e abbia un livello di sicurezza pari a zero, ma questo è un altro paio di maniche.

Three.js – Una libreria per un WebGL semplificato

WebGL è una nuova tecnologia, incorporata nei browser (o almeno in buona parte dei browser), che permette di creare e disegnare immagini e animazioni 3D su una pagina web, senza bisogno di utilizzare plugin o programmi esterni, come il Flash, ma basandosi soltanto sul buon vecchio JavaScript. Questo per dirla in modo molto semplice, sorvolando sulla storia e tutto il resto.

Per visualizzare una grafica prodotta con WebGL, o per utilizzare un videogioco basato su WebGL, è sufficiente avere un browser che supporti questa tecnologia: in pratica, più o meno tutti i browser, a parte Internet Explorer, almeno per il momento. per utilizzare WebGL in modo attivo, ossia per programmare grafiche o videogiochi in 3D, gli strumenti necessari sono sempre un browser che lo supporti, una discreta conoscenza del JavaScript e una buona conoscenza di algebra lineare, se siete così pazzi o determinati, da voler programmare a mano le matrici. Se non siete così pazzi o così determinati, non preoccupatevi: praticamente nessuno lo fa, se non in fase di apprendimento. Di solito, la parte più algebricamente hardcore è affidata a librerie JavaScript, che si occupano per noi dei calcoli più complicati, lasciandoci il piacere e il privilegio di lavorare sul risultato dei calcoli. La più usata di queste librerie è Three.js, di cui parlerò oggi.

Se ricordate la versione 3D di Pong, presentata come uno degli ultimi esperimenti su Chrome, la parte grafica è stata realizzata proprio con la libreria Three.js, come accennavo nel relativo articolo: questo per dare un esempio concreto del suo utilizzo. Niente di strano: si possono scrivere a mano le matrici e ci si può occupare personalmente di tutti i calcoli necessari, ma questo va bene solo in fase di apprendimento, quando è necessario capire i meccanismi della grafica 3D. Quando però si passa dall'apprendimento alla produzione, librerie ausiliarie come Three.js sono fondamentali, per ridurre il lavoro e il tempo da spendere sul progetto. In linea generale, usare Three.js per lavorare col WebGL è come usare jQuery per lavorare col JavaScript: entrambe le librerie costituiscono un modo per interagire a un livello più alto di astrazione con la materia grezza che si trova sotto di esse. Esattamente come jQuery, poi, Three.js non è l’unica libreria esistente, per lavorare col WebGL, ma solo una delle più diffuse e più usate.

Le caratteristiche di Three.js, dunque. Prima e principale caratteristica, comune anche alle altre librerie della stessa famiglia, è di occuparsi per conto nostro della matematica necessaria: significa che ci risparmieremo parecchie linee di codice, ad alto tasso di errori e basso tasso di divertimento (soprattutto se non amiamo la matematica). Sempre per conto nostro, Three.js si occupa anche della fase di rendering per ogni oggetto presente in scena: noi dovremo soltanto indicarle cosa fare e la libreria saprà come farlo, senza bisogno di nostre istruzioni. Inoltre, al puro WebGL unisce anche altri elementi, che spesso lo accompagnano ma che non sono parte diretta di quella tecnologia: ad esempio, il supporto per il mouse, così da poter interagire direttamente con la scena, spostando e trascinando oggetti e così via. Infine, ma non meno importante, Three.js permette facilmente di introdurre una soluzione alternativa, anche per quei browser che non supportano il WebGL: se non è presente il supporto per il 3D, possiamo sostituirlo col normale canvas 2D. Come è ovvio, il risultato estetico non sarà identico, ma la grafica o il videogioco funzioneranno ugualmente.

Three.js, poi, è orientata verso una programmazione a oggetti, il che può essere sia un vantaggio, sia uno svantaggio, a seconda dei punti di vista e delle abitudini di lavoro col JavaScript: se decidete di usare questa libreria, preparatevi a dover ricorrere spesso a new, per creare nuovi oggetti, che possono essere figure geometriche, luci, videocamere, la scena che contiene tutta la grafica e così via. Così ha deciso il suo autore.

Una caratteristica curiosa di Three.js, poi, è la presenza di un grande numero di esempi, abbinata a una documentazione alquanto scarna, sul piano dei manuali: quando scaricate la libreria, non aspettatevi niente di più elaborato di un basilare “Hello World”, incluso nel pacchetto. È possibile però trovare altrove guide e tutorial, principalmente in inglese, e anche accenni o capitoli dedicati a questa libreria, nei testi generali sul WebGL. Chi preferisce imparare smanettando col codice, però, avrà appunto oltre cento esempi con cui divertirsi, vivisezionandoli e sperimentando varie modifiche, per capire con la pratica il loro funzionamento. Tra parentesi, molti di questi esempi richiedono la presenza di un server, per funzionare: se ne avete uno installato sul vostro computer, apriteli da lì e ne guadagneranno anche le prestazioni.

I passaggi fondamentali, per creare e popolare una scena, non sono poi molto diversi da quelli che avevamo già visto, parlando di Blender: siamo sempre nel campo della grafica 3D, dopotutto, e a cambiare sono solo il linguaggio e il tipo di ambiente. Per un qualsiasi tipo di progetto con Three.js, avremo bisogno di inserire un renderer, una camera e una scena, al cui interno potremo poi sistemare oggetti (o mesh, per sembrare più professionali), luci e quant'altro. In altri termini, gli oggetti fondamentali che dovremo creare con new, nella funzione iniziale, sono:

THREE.Renderer - un oggetto che si occupa di disegnare la scena sullo schermo.

THREE.Scene - il contenitore di tutto ciò che apparirà sullo schermo.

THREE.Camera - la videocamera virtuale, attraverso cui vedremo la scena.

A questi tre oggetti, indispensabili, potremo poi aggiungerne altri, per avere anche qualcosa da vedere sullo schermo. Questi oggetti supplementari sono

THREE.Light - una sorgente di luce, di un colore a nostra scelta, indispensabile se vogliamo che sia resa la illusione di tridimensionalità degli oggetti (senza luce, appariranno bidimensionali).

THREE.Object3D - la classe base degli oggetti raffigurabili: alcuni tipi sono già definiti e pronti all'uso, altri li possiamo creare noi.

La tipologia base di oggetti, come già abbiamo visto con Blender, è Mesh e a ogni mesh dovremo assegnare due altri oggetti, nel momento della creazione: THREE.Geometry, che contiene la forma dell’oggetto (cubo, sfera, prisma eccetera) e THREE.Material, che contiene informazioni sulle qualità dell’oggetto, come il colore. In un qualsiasi progetto con Three.js, dunque, la funzione iniziale creerà un renderer, una scena, una camera, aggiungerà alla scena i vari oggetti presenti e la camera, infine passerà la mano al loop, che continuerà a ridisegnare lo schermo,a  intervalli regolari. Un esempio di come fare tutto questo lo troviamo già nel pacchetto della libreria, sotto forma di breve tutorial nella cartella "docs"; per il resto, potremo divertirci a squartare la caterva di esempi disponibili.

Esperimenti di Chrome: Cube Slam e WebRTC

Una quarantina di anni fa, quando i computer vivevano la loro età del rame e i videogiochi erano ancora in piena età della pietra, compariva sulla scena Pong, uno dei primi esemplari di gioco. Pong aveva una struttura molto semplice: due lineette verticali, una a destra e una a sinistra, si rilanciavano a vicenda un quadratino, potendosi muovere solo verso l’alto o verso il basso. Con una certa dose di fantasia, era una simulazione di ping-pong.

Curiosamente, proprio questo videogioco “preistorico” è stato scelto da Google, per essere utilizzato come cavia con cui testare e mostrare una nuova tecnologia per la comunicazione web: ne è nato così Cube Slam, uno degli ultimi esemplari appartenenti alla categoria dei Chrome Experiments, ossia applicazioni web sviluppate per mostrare quale sia il supporto offerto da Google Chrome a vari tipi di tecnologie sperimentali. Nel caso di Cube Slam, la tecnologia in questione è il WebRTC, che consente una comunicazione diretta da browser a browser, usando soltanto elementi nativi del browser stesso: niente Flash o altri tipi di plugin esterni, insomma. Ma guardiamo meglio cosa sia Cube Slam.

Questa è la schermata introduttiva, che apparirà se ci colleghiamo alla pagina con Google Chrome. Altri tipi di browser, come Firefox o Safari, potrebbero funzionare, ma non è garantito: dopotutto, è un progetto che serve a mostrare le funzionalità di Chrome e non ci si può aspettare che sia anche ottimizzato per funzionare altrettanto bene su altri browser.

Come possiamo vedere al centro, il campo di gioco è più o meno identico a quello del vecchio Pong, con una notevole variante: Cube Slam è tridimensionale, di conseguenza le due lineette sono sostituite da due parallelepipedi e il quadratino è adesso un cubo. Differenze marginali, si potrebbe dire. Una differenza più notevole è data dal contenuto del gioco, dove il semplice tic toc delle due lineette che si rilanciano l’un l’altra un quadratino è stato arricchito da svariati elementi extra, come campi gravitazionali, ostacoli, bombe e più o meno tutto l’armamentario che si può immaginare in un videogioco di questo tipo.

Sempre dalla schermata introduttiva, possiamo notare un altro particolare, cioè le due modalità di gioco offerte: contro un amico, oppure contro un orso. La seconda, per quanto possa suonare bizzarra, è soltanto un modo per dire che giocheremo contro il computer, ossia contro una tipica AI da videogioco, in questo caso impersonata da un orso. La prima opzione è invece molto più interessante, perché ci conduce al cuore dell’esperimento: la comunicazione diretta via browser, nel caso specifico tra il nostro browser e quello di un amico, contro il quale giocheremo.

WebRTC, ossia Web Real Time Communication, è una nuova tecnologia, per introdurre una comunicazione diretta tra browser, utilizzando solo le risorse a disposizione dei browser, senza appoggiarsi a programmi esterni. In particolare, il fine di WebRTC è quello di rendere la comunicazione audio e video, attraverso i browser, semplice e immediata quando la comunicazione testuale. Cube Slam utilizza WebRTC per collegarci direttamente col browser di un nostro amico, se scegliamo di giocare contro un amico e se l’amico è in linea (ovviamente), gestendo in modo diretto la comunicazione tra noi e lui: noi vedremo sullo schermo il nostro amico e lui vedrà noi. Niente di diverso da una normale video chat, da un certo punto di vista, ma la differenza sta nel modo in cui la comunicazione è realizzata: direttamente dal browser e non utilizzando un plugin di Skype, come ad esempio fa Facebook. peraltro, lo scopo stesso del gioco è proprio quello di abbattere lo schermo del nostro avversario, cosa che avverrà dopo che lo avremo colpito per tre volte.

Per essere giocato contro un amico, quindi, Cube Slam richiede la presenza di webcam e microfono (sì, oltre a vederci, possiamo anche insultarci in diretta, mentre giochiamo): se non utilizziamo un firewall (pessima abitudine), i dati saranno trasmessi direttamente dal nostro browser al browser del nostro amico, senza bisogno di un server, in un modo simile a quanto avviene con programmi P2P, come eMule o BitTorrent.

Per quanto riguarda la grafica, che è in 3D, può essere visualizzata in due modi: se il nostro browser supporta il WebGL, che è una grafica 3D nativa dei browser, il gioco sarà visualizzato utilizzando quella, dato che è stato prodotto con three.js, una libreria JavaScript per semplificare il ricorso alla grafica 3D; in assenza di WebGL, invece, ripiegherà sulla simulazione del 3D attraverso il CSS, così da garantire un risultato simile, anche se non proprio identico, anche su altri browser.

Guida al CSS per EPUB - Introduzione

Già in precedenza mi ero dedicato a una breve introduzione all'uso del CSS negli EPUB, per controllare e modificare lo stile di una pagina in base ai nostri gusti. Tornerò adesso sull'argomento  dedicandovi però più spazio, in una guida che, almeno nelle mie intenzioni, dovrebbe essere più chiara e completa della precedente introduzione. Non escludo che il risultato sarà un bignami di CSS, ma staremo a vedere. Argomento di oggi (e non solo di oggi) è dunque: come usare il CSS in uno EPUB.

Come ho ripetuto fino alla nausea, uno EPUB è fondamentalmente un sito web, compresso e impacchettato fino a sembrare un libro: i vari capitoli di uno EPUB sono altrettante pagine in formato HTML, oppure XHTML, ossia il formato di una normale pagina web, e come ogni normale pagina web possono essere formattati utilizzando un foglio di stile CSS. Un foglio di stile CSS è un normale file di testo, con estensione .CSS, al cui interno è raccolta una lista di regole di stile, che dovranno essere applicate alla pagina che le utilizza, al momento della sua apertura in un browser: quale font usare per il testo, quale colore, quali dimensioni avranno i caratteri, quando spazio lasciare sui margini, quale immagine caricare come sfondo della pagina, se ce ne deve essere una, e così via. Tutto ciò che rende una pagina bella (o brutta) da vedere, in pratica, raccolto e organizzato in un file a parte, che dovrà poi essere aggiunto alla pagina. Ma non è sempre stato così.

Alla fine del ventesimo secolo, quando il web era giovane, libero e selvaggio, gli animi erano coraggiosi, gli uomini erano veri uomini, le donne erano vere donne e le piccole creature pelose di Alpha Centauri erano vere piccole creature pelose di Alpha Centauri (per citare la Guida Galattica), stile e contenuto erano mischiati assieme, in una poltiglia difficilmente distinguibile. Nella pancia delle pagine, ossia tra i tag <body> e </body>, il testo da mostrare sullo schermo era intervallato da tag, che dicevano ai browser come dovesse essere formattato questo testo: c’erano tag che definivano il tipo di font, la sua dimensione, il suo colore, ma anche il colore dello sfondo, la larghezza e il colore delle caselle di una tabella, e così via. Un periodo in cui i web designer finivano spesso vittime di tremende crisi depressive e affondavano negli abissi bui dell’alcolismo, insomma, colti dallo sconforto mentre cercavano di annidare una tabella nell'altra, nel vano tentativo di impaginare il testo in modo decente.

A risolvere questo pasticciaccio brutto è arrivato il CSS.

Il CSS ha portato con sé una nuova e più razionale filosofia di progettazione, per le pagine web: una separazione netta tra il contenuto e lo stile. Nella pancia della pagina, ossia tra i tag <body> e </body>, doveva restare soltanto il contenuto, cioè testo, immagini e altro: in pratica, il cosa vediamo. Tutto ciò che serviva a definire il come lo vediamo, invece, doveva essere spostato altrove: nella parte alta della pagina, ossia tra i tag <head> e </head>, o meglio ancora in un file separato, da caricare assieme alla pagina. In questo file separato potevamo elencare i vari tag utilizzati nella pagina, assieme alle regole di stile da applicare al contenuto di quei tag; in fase di caricamento, il browser avrebbe controllato di volta in volta le regole, per applicarle alla visualizzazione dei tag, a mano a mano che li incontrava. Il file con la lista di tag e di regole è il foglio di stile CSS.

La progettazione di siti web ha poi proseguito su questa strada, aggiungendo un terzo elemento, cioè il funzionamento: se il semplice HTML contiene il cosa vediamo e il CSS si occupa del come lo vediamo, il JavaScript si occupa di far fare qualcosa a quella pagina. Siccome al momento gli EPUB supportano il JavaScript in teoria, ma in pratica siamo ancora abbastanza lontani dal poterlo usare decentemente (per fortuna, aggiungo io, ma questo è solo un parere personale), possiamo ignorare questo elemento e occuparci solo degli altri due.

Primo problema: come aggiungere un foglio di stile CSS a una pagina? Le possibilità sono due: scriverlo direttamente nella pagina, oppure scriverlo in un file a parte e poi dire alla pagina di caricare questo file. Il risultato finale sarà lo stesso, in entrambi i casi, ma le due soluzioni non sono equivalenti, sul piano del lavoro necessario: la scelta più razionale è quella di creare un file a parte, con tutto il CSS necessario per il nostro libro, e poi inserire un link a quel file in ogni pagina del libro, per cui vi invito caldamente a seguirla. Se poi un capitolo avrà bisogno di formattazioni particolari, perché magari contiene porzioni di testi in un altro alfabeto, allora potrete aggiungere una piccola estensione al CSS direttamente in quella pagina, per modificare le regole generali e adattarle al contesto.

Ipotizziamo allora che abbiate deciso di utilizzare un file esterno, in cui mettere tutto il CSS necessario, e lo abbiate salvato come “Stile.css” nella cartella Styles del vostro EPUB. Come fare ad aggiungerlo a ogni pagina? Con un poco di olio di gomito e di pazienza. Con Sigil, apriamo a una a una le pagine del nostro EPUB (ossia quelle contenute nella cartella Text) e passiamo alla Vista Codice. Nella parte alta di ogni pagina, cerchiamo il tag <head> e, al suo interno, il tag <title>: una volta localizzato, nello spazio tra </title> e </head> inseriamo un codice di questo tipo

<link href="../Styles/Stile.css" rel="stylesheet" type="text/css" />

Questa riga dirà al lettore di caricare un determinate file, ogni volta che deve visualizzare questa pagina; lo informerà inoltre sulla posizione in cui si trova il file (la parte che segue l’attributo href) e specificherà anche a cosa serva il file (la parte che segue l’attributo rel). Ovviamente, se il nostro foglio di stile ha un nome diverso, al posto di “Stile.css” dovremo scrivere il nome corretto del file, qualunque esso sia.

Se la pagina non è in XHTML, ma in HTML, il codice sarà quasi identico, ma un poco più corto:

<link b="" gt="" href="../Styles/Stile.css" rel="stylesheet">

Per sapere se la pagina sia in XHTML o in HTML, è sufficiente guardare la sua estensione, che ci è indicate chiaramente da Sigil.

Utilizzare un file esterno è la scelta più semplice e razionale, per risparmiarci fatiche inutili, ma niente e nessuno ci vieta di inserire il CSS direttamente nella pagina. In questo caso, nello spazio tra </title> e </head> dovremo aggiungere due tag, ossia <style type=”text/css”> e </style>: fra i due tag scriveremo poi tutte le regole che vogliamo.

Adesso che sappiamo come aggiungere un foglio di stile CSS alla nostra pagina, dovremo preoccuparci di preparare la nostra pagina ad accogliere il CSS, ottimizzandola cioè per la formattazione, ed è ciò che vedremo la prossima volta. Conclusa questa fase introduttiva, cominceremo a scrivere regole in CSS, per formattare la nostra pagina.

Creare storie interattive con Undum

Avevo già parlato, qualche tempo fa, delle avventure testuali, uno dei più antichi generi di giochi per computer, i cui primi esemplari risalgono a epoche in cui le interfacce grafiche erano pressoché inesistenti. Argomento di oggi sarà un genere a loro “cugino”, ossia le storie interattive, assieme a una libreria JavaScript per realizzarle in modo semplice (anche se non necessariamente facile).

Se siete abbastanza vecchi da aver vissuto gli anni d’oro del libro-game in Italia, allora sapete già cosa siano le storie interattive: storie a bivi, in cui ogni blocco di testo si conclude con una o più scelte, in base alle quali cambierà l’andamento della narrazione. La scelta in questione, di solito, è presentata nella forma di frasi quali “Se vuoi aprire la porta, vai alla pagina 43. Se vuoi continuare lungo il corridoio, vai alla pagina 210”: in base a ciò che scegliamo di fare, continueremo a leggere dalla pagina corrispondente a quella azione.

Col tramonto dei libri-game e la pesante affermazione di internet, le storie interattive si sono evolute, adattandosi al nuovo ambiente: dalla pagina stampata siamo passati alla pagina digitale e lo HTML, utilizzato per produrre pagine e siti web, si è dimostrato un ottimo veicolo anche per le storia interattive. Non l’unico veicolo, perché progetti come Inform hanno scelto una strada leggermente diversa, ma di certo la struttura “a bivi” delle storie interattive si adatta benissimo alla forma di un sito: basta sostituire il numero di pagina con un link da cliccare, ed ecco che la storia si è trasformata in un perfetto inserto per un normale sito web.

Un vecchio libro-game, dunque, può oggi essere trasformato in un insieme di pagine HTML, corrispondenti alle “pagine” del libro cartaceo, e collegate tra loro da link, che permettono di saltellare da una pagina all'altra  senza bisogno di sfogliare il libro. Questo, se non altro, è il modo più semplice in cui si possa realizzare una storia interattiva su computer. Avere qualche centinaio di pagine HTML, però, può essere decisamente scomodo, sia da realizzare che da mantenere, e può dare problemi di lentezza, dovendo attendere i comodi del server ogni volta che clicchiamo su un bivio; per questo motivo, sono state prodotte alcune infrastrutture basate su librerie JavaScript, che permettono di produrre testo in base ai nostri click e mantenendosi sempre sulla stessa pagina HTML, il cui contenuto sarà di volta in volta modificato dal JavaScript, in modo veloce ed efficiente.

Undum è una di queste infrastrutture, probabilmente la più semplice da usare, anche se è bene ricordare che “semplice” e “facile” sono due aggettivi dal significato diverso: Undum è semplice, ma non necessariamente facile. Vedremo il perché.

In linea di massima, Undum è composto da tre elementi fondamentali: una pagina HTML, tre librerie JavaScript e un paio di files CSS. La pagina HTML è il luogo su cui apparirà il testo della storia; le librerie JavaScript servono a contenere il testo e a scriverlo sulla pagina; i files CSS servono a definire la grafica e l’impaginazione della storia. Tutto qui. Per essere usato, è sufficiente modificare la pagina HTML, i fogli di stile CSS e una delle librerie JavaScript, per inserire la vostra storia e adattare la grafica alle vostre esigenze. Una volta fatto questo, basta caricare il pacchetto sul proprio sito e incorporare la pagina HTML nel punto che preferite del vostro sito. Molto semplice, come dicevo: non c’è niente da installare sul vostro computer, ma solo un paio di files da modificare, cosa che si può fare con un qualsiasi editor di testo.

Semplicità non è facilità: sebbene sia semplice, può non essere facile da utilizzare, se si è totalmente ignoranti in fatto di programmazione. Non è necessario molto, perché basta una minima infarinatura di HTML (per modificare la pagina) e di JavaScript, per modificare la libreria, e i files di partenza sono ricchi di commenti, che spiegano come effettuare la maggior parte delle modifiche, ma non è un progetto “visuale”, di quelli in cui basta trascinare qui e là un paio di finestre ed etichette, senza una idea precisa di cosa ci sia dietro. La pagina HTML, in particolare, è piena di indicazioni “modifica qui” e “non modificare qui”, ma anche la libreria JavaScript non scherza, sotto questo aspetto, e dovrebbe essere sufficientemente accessibile anche per un non-programmatore.

Una volta scaricato il file ZIP ed estratto il contenuto, la cartella di Undum che ci interessa (cioè la cartella games), presenta questa struttura:

tutorial.en.html
tutorial.ru.html
media/
css/
games/
img/
js/

I due files HTML che troviamo all'inizio sono appunto due guide, una in inglese e una in russo, che spiegano il funzionamento di Undum e lo spiegano attraverso una sorta di storia interattiva: seguendo il tutorial, potrete leggere sia le spiegazioni, sia verificarle di persona, “giocando” il testo.

La cartella CSS contiene due fogli di stile, undum e undum-mobile, che determinano la grafica della pagina HTML: il primo file ne definisce la grafica per i computer, il secondo per i dispositivi mobili.

La cartella Games contiene il materiale usato da ogni gioco: nello specifico, contiene le tre immagini mostrate nel corso del tutorial e le librerie JavaScript specifiche per ogni singola storia.

La cartella Img contiene immagini di base, utilizzate dai fogli di stile per impostare sfondi, titoli e altri elementi della pagina HTML.

La cartella Js contiene due librerie JavaScript di base, ossia una versione di jQuery e Undum: non toccatele, per evitare danni.

Ciò che possiamo modificare senza problemi, per creare le nostre storie, sono i files HTML, i fogli di stile CSS e tutto il contenuto della cartella Games. Se vogliamo cambiare le immagini di base, possiamo modificare anche il contenuto della cartella Img, ricordandoci però di modificare di conseguenza anche i fogli di stile, se le nuove immagini avranno un nome differente. Il minimo indispensabile da modificare, in ogni caso, è composto da due files: tutorial.en.html e tutorial.game.en.js (nella cartella games). Anche i loro nomi possono essere cambiati; anzi, sarebbe proprio meglio cambiarli. Un gioco, quindi, potrebbe avere una struttura di questo tipo:

storia.html
media/
css/
games/
storia.game.js
img/
js/

In questo esempio, Storia.html è la pagina su cui sarà scritta la nostra storia, mentre Storia.game.js è la libreria che si occuperà di scrivere la nostra storia. Entrambi i files possono essere prodotti, modificando i modelli già esistenti, ossia tutorial.en.html e tutorial.game.en.js: anzi, produrli in questo modo è il sistema consigliato, nonché più semplice. Una volta che abbiamo finito di scrivere la nostra storia, basterà caricare tutto quanto (Storia.html, la cartella Media e tutte le sue sottocartelle) sul nostro sito. Se vogliamo scrivere più storie, potremo riutilizzare sempre la stessa struttura di base, aggiungendo semplicemente i files delle nuove storie:

storia.htmlnuovastoria.htmlmedia/ css/ games/ storia.game.js nuovastoria.game.js img/ js/

E così via: l’unica limitazione è che tutte le storie avranno la stessa grafica, ma a questo si può ovviare facilmente, creando nuove copie dei foglio di stile e modificandoli come preferiamo.

Siccome il tutorial di Undum è disponibile solo in inglese e russo, qui potete scaricare il tutorial in italiano: la traduzione è mia e anche gli eventuali refusi sono miei. Volendo, puoi essere usato anche come base, per scrivere le vostre storie, dato che la struttura è la stessa di Undum inglese.

Il riconoscimento vocale con Google Chrome

Una delle novità introdotte a partire dalla versione 25 di Google Chrome è il completo supporto alla interfaccia per il riconoscimento vocale; l’interfaccia per il riconoscimento vocale, a propria volta, è la Web Speech API, una delle numerose interfacce JavaScript, più o meno utili a seconda dei casi, che stanno spuntando come funghi con la diffusione dello HTML5, supportato ormai da tutti i browser più recenti.

In linea generale, questa interfaccia JavaScript dovrebbe rendere più semplice il lavoro di aggiungere alle pagine web tutte le funzioni connesse al riconoscimento vocale: dettare testi, impartire comandi, eccetera. Se effettivamente riuscirà a semplificare il lavoro, però, dipenderà da quanto sarà diffuso il supporto per questa interfaccia sui vari browser, ma questo è un altro paio di maniche. Intanto, possiamo guardare un primo esempio del suo funzionamento.

Prima di cominciare a dettare un testo, sarà necessario selezionare il linguaggio e, eventualmente, il paese, se è un linguaggio parlato in più paesi. Successivamente, un click sulla icona a forma di microfono, in alto a destra nel riquadro, permetterà al browser di attivare il microfono del nostro computer, per registrare la voce: basterà poi cominciare a parlare e vedremo il testo apparire sullo schermo, in una trascrizione più o meno corretta. Alla fine, clicchiamo di nuovo sul microfono, per avvisare che la registrazione deve essere interrotta. Appariranno a questo punto due pulsanti, sotto il riquadro di testo: il primo ci permette di copiare il testo (per incollarlo dove preferiamo), il secondo ci permetterà di creare una e-mail, il cui contenuto sarà proprio il testo da noi dettato.

Per adesso, i linguaggi supportati sono circa trenta, italiano incluso, ma ovviamente la qualità del risultato varia a seconda del linguaggio: più diffusa è la lingua, migliore in linea di massima è il risultato. In altri termini, con l’inglese funziona generalmente bene, con l’italiano non sempre si otterrà una trascrizione esatta, come potrete verificare con qualche esperimento. Miglioreranno strada facendo.

Un esempio più concreto lo si può ottenere sul sito della Peanuts Gallery, dove sono messi a disposizione vari vecchi filmati in bianco e nero, a cui è possibile aggiungere un testo utilizzando proprio questa interfaccia di riconoscimento vocale: in altri termini, scegliete un video e parlate a voce alta davanti al vostro computer, cercando di non pensare a quanto sia ridicola la scena vista dall'esterno  e la funzione di riconoscimento vocale provvederà a registrare ciò che dite, per poi aggiungerlo al filmato come intertitolo, ossia quella didascalia che, nei vecchi film muti, compariva tra una scena e l’altra.

Dopo questi due esempi di come si possa utilizzare, vediamo anche qualcosa di più preciso sul suo funzionamento: in cosa consiste questa Web Speech API?

Come qualsiasi altra interfaccia, la Web Speech API ci mette a disposizione una serie di funzioni da utilizzare nel nostro codice, con la garanzia che, utilizzando la funzione X, otterremo sempre un certo risultato (se il browser che eseguirà il nostro codice supporta questa interfaccia, ovviamente). Se il risultato è garantito, il modo in cui questo risultato sarà ottenuto è variabile e dipende dai singoli browser: alcuni possono decidere di eseguire il riconoscimento vocale in locale, ossia sul nostro computer, attraverso un apposito “motore” aggiunto al browser; altri, invece, potranno decidere di registrare ciò che diciamo, inviarlo ai propri server e poi restituirci sulla pagina il risultato del riconoscimento. Per inciso, negli esempi di Google Chrome il riconoscimento vocale avviene attraverso un server: altri browser, però, potrebbero svilupparlo differentemente. La Web Speech API supporta entrambe le soluzioni: se vogliamo utilizzarla in una nostra pagina, dunque, non abbiamo bisogno di preoccuparci di come effettivamente avvenga il riconoscimento vocale, ma basta sapere quali comandi utilizzare per avviare il riconoscimento, interromperlo e raccoglierne i risultati.

Se il discorso non è chiaro, prendiamo un esempio più familiare: l’interfaccia di un’automobile. Tutte le automobili hanno un freno; premendolo, la velocità diminuirà. Un automobilista non ha strettamente bisogno di sapere i dettagli sull’impianto frenante montato sulla sua auto: per usare il freno, gli è sufficiente conoscere il pedale corrispondente e conoscere il risultato della pressione, ossia un calo della velocità. Allo stesso modo, se vogliamo arricchire la nostra pagina web con un form, che può essere compilato dettando il testo, invece di scriverlo a mano, ci basterà sapere quali funzioni JavaScript dobbiamo invocare, lasciando poi che sia il browser a preoccuparsi per noi di effettuare il riconoscimento vero e proprio.

Per le funzioni, possiamo fare riferimento alla pagina di presentazione di questa interfaccia, su cui compaiono anche alcuni esempi di utilizzo. In linea di massima, si comincerà sempre con la verifica del supporto offerto dal browser: se il browser non supporta la Web Speech, è inutile proseguire. Se la supporta, per prima cosa creeremo un nuovo oggetto SpeechRecognition e ne utilizzeremo i metodi principali: start() per avviare la registrazione (magari cliccando su qualche elemento della pagina), stop() per interromperla. Esistono poi diversi attributi da impostare, a seconda del tipo di registrazione che vogliamo: registrazione continua o singola, come deve essere processato il testo, quale sia il linguaggio di riferimento, e così via. Per esempi più completi del suo utilizzo, però, è meglio fare riferimento a quelli proposti nella presentazione della interfaccia, oltre anche a quelli che ci ha offerto Google.

Sigil 0.7.0, verso lo EPUB 3

...ma ancora non ci siamo arrivati, né ci arriveremo a breve.

Qualche giorno fa (il 17 febbraio, per la precisione) è uscita la versione 0.7.0 di Sigil, che prosegue il suo cammino di avvicinamento al nuovo standard per il formato EPUB, ossia il cosiddetto EPUB 3. Nuovo per modo di dire, in realtà, dato che questo standard viaggia verso l’anno e mezzo di vita, ma se consideriamo la sua attuale diffusione e il supporto che ha fin qui ricevuto, allora lo possiamo considerare ancora nuovo di pacca, praticamente ancora avvolto nel cellophan. Ma torniamo a Sigil.

Ancora sospeso tra il vecchio EPUB 2, cioè il formato EPUB che conosciamo e usiamo normalmente, e il nuovo EPUB 3, questa versione di Sigil ha rafforzato da un lato il suo supporto per le novità, permettendoci di inserire elementi video e audio in modo più semplice e senza trafficare troppo col codice sorgente, ma dall’altro lato queste modifiche hanno ancora un sapore provvisorio e sembrano più che altro una mano di vernice bianca su un vecchio muro. È vero che adesso possiamo inserire un video in uno EPUB, semplicemente cliccando un pulsante dell’interfaccia, ma è anche vero che dovremo prepararci spiritualmente a litigare con FlightCrew, che continuerà spesso e volentieri a segnalarci come errata la presenza del tag <video> nelle nostre pagine. FlightCrew, il test di convalida usato da Sigil, non è ancora passato allo EPUB 3, a differenza del test ufficiale EpubCheck.

Vediamo intanto come si presenta alla vista la nuova versione di Sigil:

Non molto diversa dalla precedente, vero? In effetti, la carrozzeria è rimasta praticamente invariata, ma diverse cose sono cambiate nel motore. Considerato che tutte le icone, al passaggio del mouse, mostrano una finestrella popup con la spiegazione del loro funzionamento, e considerato che molte icone sono identiche alle versioni precedenti del programma, non sarà necessario descriverle a una a una. Mi limiterò dunque a puntare alle differenze.

Prima di tutto, è stata eliminata la modalità di visualizzazione, che offriva assieme la vista libro e la vista codice: adesso abbiamo solo queste due, che possiamo alternare, ma non soprapporre come prima. Un cambiamento sconvolgerà poche persone, credo. Più “pesante” è il cambiamento di un’altra icona limitrofa, ossia l’icona per l’aggiunta di una immagine. Nella nuova versione di Sigil, questa icona permette l’aggiunta di un file, non solo di una immagine: se vogliamo inserire in modo automatico un elemento video o audio, dovremo cliccare questa icona.

Nella colonna di sinistra, dove sono elencate le cartelle che compongono lo EPUB, troviamo due nuove cartelle, ossia Audio e Video: è piuttosto semplice capire a cosa servano. In effetti, erano state già inserite in un aggiornamento intermedio della versione 0.6 di Sigil, ma adesso l’aggiunta del pulsante per l’inserimento di file audio e video ha dato loro un certo senso. Se clicchiamo su una di queste cartelle col tasto destro del mouse, potremo aggiungere direttamente un file adatto (audio o video, a seconda della cartella) e questo file potrà poi essere aggiunto alla pagina, nella posizione che vogliamo, usando il pulsante Insert File (curiosamente, è l’unico pulsante la cui descrizione non è stata tradotta in italiano).

Unendo le due novità appena descritte, giungiamo a questa descrizione su come inserire un video (per esempio) in una pagina: prima di tutto, aggiungiamo il file al nostro EPUB, cliccando col tasto destro sulla cartella adatta, oppure selezionando File -> Aggiungi -> File Esistenti dal menu in alto; fatto questo, posizioniamo il cursore nel punto in cui il file dovrà essere inserito nella pagina e clicchiamo sul pulsante Insert File, per aggiungerlo in quel punto. E trovare un lettore che supporti anche lo EPUB 3, ovviamente.

Sempre collegato all'uso dei files multimediali, nel menu Strumenti troviamo una nuova voce, ossia Delete Unused Media Files: cliccandola, avvieremo una scansione del nostro EPUB, alla ricerca di files che abbiamo aggiunto, ma che poi non abbiamo utilizzato nel testo. Un buon modo per localizzare subito alcuni degli errori che più spesso sono segnalati dai test di convalida.

Altro cambiamento è la finestra di anteprima. Premendo il tasto F10, possiamo aggiungere una finestra supplementare, dove sarà mostrata un’anteprima del nostro EPUB, così come in teoria dovrebbe apparire a fine lavoro. Siccome questa finestra tende ad apparire in un punto piuttosto scomodo dell’interfaccia, è adesso possibile “staccarla” e spostarla liberamente sullo schermo, come e dove preferiamo.

Altra modifica attesa da tempo è la possibilità di modificare direttamente la Tavola dei Contenuti di uno EPUB, ossia quella lista che compare nella colonna di destra di Sigil e che corrisponde al nome delle varie sezioni in cui è diviso il libro. Sotto al menu Strumenti -> Tavola dei Contenuti – TOC, troviamo adesso Edit Table of Contents: cliccandola, si aprirà una finestra dove potremo spostare, cancellare o aggiungere altre voci. Nel caso non lo abbiate ancora notato, molte delle modifiche in questa versione non sono state tradotte in italiano, per cui è abbastanza facile notare i “pezzi” nuovi.

Utile o meno che sia, da questa versione di Sigil è poi possibile salvare anche gli EPUB che presentano gravi problemi di struttura, ossia errori a livello di codice XML (per esempio tag non chiusi, oppure tag non validi, e così via).

In generale, non è una versione che presenti grandi modifiche, se non un più esteso supporto per alcuni elementi base dello EPUB 3: video e audio, in pratica, quelli che finora sono stati più utilizzati dalle case editrici. Se invece sognate di aggiungere ai vostri libri tanto bel codice JavaScript, per dotarli di funzioni più o meno inutili o dannose, allora dovrete aspettare, anche se lo EPUB 3 vi permette di farlo. Sigil, al momento e ancora per non sappiamo quanto tempo, è un programma che supporta lo EPUB 2, non lo EPUB 3: anche le ultime modifiche lo hanno reso al massimo uno EPUB 2+, che incorpora alcune strutture del formato più recente, ma innestandole su una base differente e vecchia. Proprio per questo, la possibilità di aggiungere elementi nuovi agli EPUB esiste, ma non è molto semplice da usare: è un compromesso, in attesa di tempi migliori e in attesa soprattutto di decidere quale strada dovrà seguire lo sviluppo del programma.

Come descritto dagli stessi sviluppatori di Sigil, al momento il programma ha scelto di adattarsi allo EPUB 3 in una forma ibrida: mantenendo lo EPUB 2 come base, aggiunge a poco a poco quelle porzioni di EPUB 3 che possono essere supportate anche dal formato precedente. Perché questa scelta? Fondamentalmente, perché il supporto per il vero EPUB 3 è ancora scarso, sia a livello di dispositivi di lettura, sia a livello di case editrici. La maggior parte dei lettori che utilizziamo quotidianamente supporta soltanto lo EPUB 2 e anche i prodotti più avanzati, ora come ora, hanno più che altro incorporato gli elementi più commercialmente appetibili dello EPUB 3, ossia i video e gli audio. Una scelta che, di fatto, non è diversa da quella di Sigil. Un giorno la situazione del mercato si chiarirà e lo EPUB 3 sarà adottato ovunque, in forma completa... o almeno, in teoria ciò dovrebbe accadere (il JavaScript negli e-book mi entusiasmo come una gastroscopia, ma questo è un altro paio di maniche e sono gusti personali). Per quel giorno, forse, anche Sigil avrà smesso di essere né carne né pesce, come invece adesso ci appare. Intanto, ci arrabatteremo alla meno peggio.

Let me google that for you

L’argomento di oggi sarà leggero e scherzoso, una pausa rilassante prima di tornare ad argomenti più “sudati” (ho in programma una serie di guide all'uso di Blender e non sarà una passeggiata, né da scrivere né da leggere). Sarà anche una occasione per riflettere su alcuni usi e costumi che la Rete non ha creato, ma che certo ha accentuato.

Avere dubbi, domande e difficoltà varie è cosa del tutto normale. Quando si hanno problemi, le linee di azione possibili sono fondamentalmente due: cercare una soluzione per proprio conto, oppure chiedere ad altre persone. Anche questo è normale. Cercare una soluzione a un problema, al giorno d’oggi, significa molto spesso aprire una finestra di Google (o di Bing, o DuckDuckGo, o qualunque sia il vostro motore di ricerca preferito), digitare una o più parole che descrivano il problema e guardare cosa ne esce: come eseguire una certa operazione col programma X, la lista degli idraulici più vicini a voi, gli orari di treno o aereo, i prezzi di un determinato prodotto, eccetera. E anche qui ci manteniamo nell'ambito della normalità.

Che succede quando invece chiediamo a qualcun altro? Se questa persona conosce già la risposta al nostro problema, allora semplicemente ce la dirà; se non la conosce, probabilmente aprirà a propria volta una finestra di Google (o Bing, eccetera eccetera) e cercherà la risposta. Può darsi che proprio non abbia idea di come risolvere un certo problema, oppure può darsi che voglia assicurarsi della correttezza della sua soluzione, in ogni caso un giro sui motori di ricerca lo si fa quasi sempre. In certi casi, la soluzione è complessa e richiede che i risultati di una ricerca siano combinati con conoscenze precise: è allora normale chiedere aiuto a qualcuno più esperto di noi. Ci sono casi, però, in cui una semplice ricerca può darci la risposta (che probabilmente non sarà quarantadue), ma noi chiediamo lo stesso a qualcun altro, per pigrizia. Let me google that for you è un sito che si rivolge proprio a questi casi.

Come spiegato già nella prima pagina, Let me google that for you è un sito dedicato a tutti coloro che sono troppo pigri per cercare una risposta in prima persona e preferiscono chiedere a qualcuno di cercarla al posto loro. Più precisamente, è dedicato a tutte le persone, a cui di solito sono rivolte queste richieste di aiuto, e suggerisce loro un modo più o meno simpatico (a seconda dei punti di vista) per rispondere a queste richieste. A margine, il sito ha sviluppato anche un merchandising che possiamo tranquillamente ignorare, perché non è di alcun interesse.

Al primo accesso, il sito ci mostrerà una pagina che dovrebbe essere nota a quasi tutti: la classica finestra di ricerca di Google. Anche l’uso è identico a quello di Google: scriviamo ciò che ci interessa cercare e poi lanciamo la ricerca. La differenza è in ciò che avviene dopo: mentre Google ci fornisce la lista delle possibili risposte alla nostra ricerca, Let me google that for you ci risponderà con un link. Questo link può essere aperto direttamente con un click, oppure copiato e spedito a un’altra persona, o ancora incollato in una pagina, in un messaggio e così via. Qualunque sia il modo in cui decideremo di usarlo, il risultato sarà lo stesso: aprendo il link, comparirà una pagina di Google, dove una semplice animazione in JavaScript eseguirà la ricerca che abbiamo scelto, scrivendo le parole all'interno del riquadro di ricerca e premendo il pulsante per avviarla.

Questo è un esempio del suo funzionamento.

Chi è interessato al funzionamento dello script, poi, potrà squartare e vivisezionare la pagina al suo primo caricamento (un bel CTRL+U, subito dopo aver cliccato sul link, oppure un passaggio per la console javascript del vostro browser), per capire come sia gestita l’animazione: di JavaScript ce n’è parecchio e sarà vostro divertimento scoprire a cosa serva ogni script.

A seconda dei punti di vista, questo sito può essere considerato sia come un invito a cercare le risposte con le proprie forze, invece di appoggiarsi sempre ad altri, sia come una presa in giro nei confronti di chi si aspetta la pappa pronta, invece di arrangiarsi da solo. Alternativamente, può anche essere un semplice modo per replicare a un eventuale amico, che ha la tendenza ad abusare di noi e ci rompe le scatole per ogni stupidaggine. A titolo informativo, è possibile imbattersi con una certa frequenza in link provenienti da questo sito sui forum di lingua inglese, soprattutto se di argomento informatico: non lo considero un modo molto simpatico di rispondere, dato che spesso le domande sono poste in buona fede (è legittimo invece usarlo nei confronti di persone assillanti, che continuano a ripetere la stessa domanda, fino a che qualcuno non risponde – di solito in malo modo), ma sono pareri personali.

Come funziona YouTube Video Download

Come probabilmente avrete notato YouTube ha cambiato di nuovo la sua grafica; siccome a ogni cambiamento di grafica corrisponde anche un cambiamento più o meno profondo del codice che vi sta dietro, un risultato diretto di questa modifica è che gli strumenti per scaricare video da YouTube hanno smesso temporaneamente di funzionare. Normale amministrazione, succede con una discreta frequenza, soprattutto perché YouTube non è particolarmente entusiasta di questi strumenti e non si fa mai scappare una occasione per complicare la vita ai sistemi di scaricamento video.

Fra i vari programmi e affini dedicati a questa attività, ossia scaricare video da YouTuube, oggi mi dedicherà a uno dei più semplici e leggeri da utilizzare, ossia YouTube Video Download. Di fatto, YouTube Video Download è un semplice script in JavaScript, di una quarantina di KB circa, che può essere utilizzato con Firefox (attraverso l’estensione Greasemonkey, oppure Scriptish), con Google Chrome e con Opera: ciò che fa è aggiungere un semplice pulsante “Download” sotto a ogni video di YouTube.

Cliccando sul pulsante “Download”, si aprirà un menu con le varie opzioni disponibili per scaricare il video: a voi scegliere il formato e la qualità che preferite. Indicativamente, i livelli sono tre, cioè High definition, Standard definition e Mobile, ma non per tutti i video sono disponibili: video particolarmente vecchi, ad esempio, difficilmente presenteranno High definition e saranno disponibili in un numero minore di dimensioni e formati per i livelli esistenti.

All'interno di questi tre livelli principali esistono ulteriori suddivisioni, indicate con un numero seguito dalla lettera p: tipicamente sono 1080p, 720p, 480p, 360p, 240p e 144p (quest’ultimo solo nel formato Mobile, ossia per cellulari). Questi numeri definiscono la qualità del video attraverso la sua dimensione in pixel: più altro il numero, più grande sarà il video e, di conseguenza, maggiori saranno le sue dimensioni in bytes. Teoricamente dovrebbe essere più alta anche la qualità del video, ma questo va valutato nei singoli casi, perché dipende dalla videocamera con cui il video è stato prodotto. Accanto a questo numero sono più indicati tutti i formati in cui il video è disponibile a quel livello di qualità: solitamente, i formati sono MP4 e FLV, più il 3GPP per i cellulari.

Posizionando il puntatore del mouse sul nome di uno di questi formati, si aprirà una piccola finestra popup, con ulteriori informazioni su quel video: una su tutte, la dimensione in bytes, così avrete una idea di quanto potrebbe durare lo scaricamento e, soprattutto, d quanto spazio vi occuperà. Se poi siete su un dispositivo mobile, con una tariffa a consumo, allora è opportuno studiare con molta attenzione le dimensioni dei vari formati, per scegliere quello più conveniente. Altra informazione che vi è fornita in questa finestrella popup è la qualità dell’audio: i formati dalla qualità più alta sono in genere OGG e Vorbis, mentre lo MP3 ha la qualità più bassa. Questa informazione vi sarà utile, se volete scaricare un video per poi estrarne l’audio: se lo convertirete in MP3, ad esempio, vi conviene scaricare direttamente un formato video che abbia l’audio già in MP3; scaricare un video il cui audio è in MP3 e sperare poi di poterlo convertire in OGG, invece, è una pia illusione.

In alto a sinistra, infine, trovate anche la voce “options”: cliccandola, potrete impostare la ricerca automatica di aggiornamenti per lo script, ma anche il formato del nome con cui sarà salvato il video. Lo schema di base è ${title}, cioè il video sarà salvato utilizzando il titolo come nome: se vi sembra incomprensibile e non sapere dove mettere le mani, non modificate questa impostazione e tutto andrà per il meglio.

Se non sapete come orientarvi in mezzo a tutte queste possibilità e siete vittime di una vertigine da troppa scelta, ecco qualche indicazione.

1. Se il video non vi interessa e lo state scaricando solo per convertirlo poi in MP3, allora scaricate la versione con audio in MP3: di solito si trova attorno al 240p, come qualità.
2. Se vi interessa il video e non avete problemi di banda o di spazio, puntate su un MP4 da 1080p o, in alternativa, il numero più alto disponibile.
3. Se vi interessa il video e avete problemi di banda o di spazio, puntate su un MP4 da 480p o da 360p, a seconda di quale delle due opzioni sia più conveniente nel vostro caso.

Per scaricare e installare YouTube Video Download ci sono diverse possibilità. Se siete utenti abituali di Greasemonkey, conoscerete il sito Userscript, un deposito di script che possono essere usati con quella estensione: potreste scaricare YouTube Video Download da lì, ma ve lo sconsiglio, perché al momento è disponibile soltanto la versione 3.2.1, che non è la più aggiornata e non funzionerà con le ultime modifiche di YouTube. Scaricatelo invece dalla sua fonte, ossia dalla pagina Github del suo sviluppatore, dove troverete la versione più aggiornata, ossia la 4.0, che funziona con le ultime modifiche di YouTube.

Se siete su Firefox e avete installato una estensione come Greasemonkey, allora vi basterà cliccare sul pulsantone INSTALL .user.js, al centro della pagina, e poi seguire le indicazioni per installarlo. Se invece state utilizzando Google Chrome, le sue recenti modifiche alla sicurezza non vi permetteranno di installarlo direttamente: scaricate quindi lo script, aprite la lista delle estensioni di Chrome (che trovate a chrome://chrome/extensions/) e poi trascinate lo script su questa lista, così lo installerete in barba ai limiti imposti.

Un ultimo avvertimento: se avevate già installato una versione più vecchia di questo script, prima di tutto dovrete disattivare (o direttamente disinstallare, a vostra scelta) la versione più vecchia, altrimenti è possibile che il vostro browser continuerà a cercare di caricare quella, invece della versione più aggiornata.