Recensione generale

In una parola: ottimo. Anche se migliorabile.

A memoria credo sia il primo a trattare l’integrazione tra PHP e MongoDB.
Lo stile è molto scorrevole. I concetti sono spiegati in modo chiaro nella maggior parte dei casi. Fanno eccezione i concetti di programmazione funzionale nel capitolo dedicato a map-reduce, che avrebbero beneficiato di un maggiore approfondimento.
Ogni capitolo presenta diversi esempi di codice per gli argomenti trattati.
I quiz di cui è costellato aiutano a richiamare i concetti appena appresi e a capire se sia il caso di rileggere quanto appena studiato. Peccato che non siano molto numerosi. Le soluzioni ai quiz si trovano alla fine del libro.

Vengono presentati anche alcuni “compiti per casa” (di cui non viene data soluzione, naturalmente) che invitano ad implementare soluzioni diverse da quelle presentate o software che utilizzando i concetti esposti li espandano per creare software più complessi.

La caratteristica che ho apprezzato di più è la presentazione degli esempi: prima viene esposto il codice completo di tutti gli script, e in seguito, durante la spiegazione, vengono riportati i frammenti di codice. Questo consente di avere una visione globale e di poterla studiare da soli. Molti altri testi spezzano i sorgenti rendendoli illeggibili, o integrano la spiegazione in commenti lunghissimi che, senza colorazione della sintassi, li rendono altrettanto illeggibili.

Lo stile adottato sembra distaccarsi un po’ dal classico dei manuali tecnici, per tendere a quello dei testi universitari.

In alcuni casi si ha la sensazione che ci sia molto di più dietro (e spesso a ragione), e che il libro copra solo l’uso base di alcune caratteristiche.
In altri casi è scritto chiaramente (con relativo link) che per approfondire si possono consultare fonti online.

Alcuni piccoli errori tipografici come campi di array separati da :  (come in javascript) invece che da => in PHP, o virgolette dimenticate  nelle chiavi di accesso agli array sono facilmente individuabili e non pregiudicano la qualità del libro.

Capitolo 1 – Installazione

Inizia con una breve panoramica del “movimento NoSQL”, ne spiega brevemente i fondamenti, e poi passa alla procedura di installazione vera e propria, sia per Windows che per Linux, mentre per OSX dice semplicemente “è come su Linux”.
In tutti i casi la procedura è tanto semplice da richiedere non più di un paio di pagine.
Passa velocemente all’avvio del server, coprendo le principali opzioni di configurazione, alla creazione di database e collection, per finire con l’installazione, tramite PEAR, dei driver per PHP e a un primo script dimostrativo.

Capitolo 2 – La prima applicazione

Ormai diventato l’”hello world” dei libri che trattano web, si parte costruendo un piccolo blog senza troppe pretese: inserimento, cancellazione, modifica degli articoli. Quindi si passa ad
approfondire tramite paginazione dell’archivio per finire con l’inserimento di commenti ai post.
Durante il percorso vengono spiegate le classiche operazioni CRUD (Create, Read, Update, Delete), spiegando anche il particolare linguaggio di query di MongoDB, le operazioni di limit e skip, il concetto di cursore e di scrittura safe.
Si conclude con alcune operazioni particolari (upsert, incremento di un campo, rimozione di un campo) e con la distinzione tra documenti embedded e esterni, spiegando anche come fare le “select” cercando dati su documenti embedded.

Capitolo 3 – Session Manager

Dopo una breve introduzione a cosa sia una sessione, passa subito a definire un session handler personalizzato. Con l’occasione viene anche creata una classe (singleton) per la connessione al DB, che verrà utilizzata nel resto del libro.
Viene quindi creata una classe per la gestione della sessione tramite MongoDB, facilmente riutilizzabile in altri progetti in quanto quasi totalmente
trasparente.
Il capitolo si conclude con un esempio di gestione di login/logout degli utenti.
Molto utile non solo per capire come come astrarre l’accesso a MongoDB tramite una classe e come usare upsert, ma anche per capire come usare un DB generico (anche SQL) per le sessioni in PHP.

Capitoli 4 e 5 – Aggregazioni e statistiche

Accorpo la descrizione dei due capitoli perché trattano più o meno lo stesso argomento: map-reduce e group().
Il primo è forse l’argomento più difficile per chi è abituato a linguaggi procedurali o ad oggetti, in quanto riprende concetti della programmazione funzionale, mentre il secondo si avvicina di più a concetti conosciuti come quelli dell’SQL.
Due capitoli non facili da assimilare, nei quali avrei forse visto bene un numero maggiore di esempi. Fortunatamente quelli che ci sono riguardano applicazioni pratiche (tag cloud, statistiche di accesso alle pagine, ecc.) e non argomenti astratti.
Vengono introdotte anche le capped collections.

Capitolo 6 – Integrazione con i RDBMS

Forse il capitolo meno interessante per me, anche se tratta un argomento importante. Vengono portati diversi esempi di come usare in parallelo MongoDB e un database SQL (MySQL): come usare MongoDB per fare cache delle query complesse fatte su MySQL, o per archiviare vecchi dati in modo da scaricare MySQL.

Capitolo 7 – GridFS

Capitolo un po’ scarno, ma che fornisce tutte le informazioni necessarie per iniziare a lavorare con GridFS per lo storage di file dentro il DB.
Anche qui MongoDB eccelle per semplicità, quindi gli esempi sono brevi e chiari.
Uno degli esercizi invita ad implementare una gallery con thumbnail, dicendo di salvare le thumbnail assieme all’immagine originale, ma non spiega se si possano avere due file nello stesso ducumento (hint: non si può).

Capitolo 8: Geolocalizzazione

Introduce le funzionalità di geolocalizzazione di MongoDB, fornite sia da indici bidimensionali che da procedure predefinite nel server per la ricerca in base alla distanza da un punto.
Una buona introduzione, anche se lascia un po’ il dubbio sulle unità di misura (gradi, radianti, metri?) che vanno utilizzate.
Ottima la spiegazione di come integrare queste funzionalità con le mappe di Google per la visualizzazione dei risultati.

Capitolo 9: Sicurezza

Questo è il capitolo con meno codice PHP. Si concentra sull’amministrazione dalla console di MongoDB per la creazione di utenti con relative password, e di vari tipi di indice, comprese le procedure per analizzarne l’efficacia.
L’argomento indici forse sarebbe stato meglio trattato in un capitolo precedente.

Capitolo 10: RockMongo e phpMoAdmin

Una rapida panoramica di due interfacce web (scritte in PHP) per l’amministrazione, l’interrogazione e, soprattutto, il backup e il restore di database o di collections.
Copre pro e contro delle due soluzioni, l’installazione e l’uso di base.

Già da un po’ avevo notato rallentamenti quando scrivevo un “uguale” (=), ma dopo 3-4 secondi mi mostrava l’autocomplete e mi lasciava continuare a scrivere, salvo perdermi uno spazio ogni tanto. Ho provato a disabilitare l’autocomplete durante la scrittura (lo voglio solo quando premo ctrl-space), ma non ci sono riuscito.

Ma ieri quei 3-4 secondi sono diventati più di 10 minuti. Non so quanto, e non so se si sarebbe mai ripreso. L’ho killato dopo un buon gelato. E ho iniziato a cercare soluzioni in Internet.

Sembrava un problema legato al fatto di avere troppi file nel progetto, e infatti linkando lo Zend Framework questo numero superava abbondantemente i 1000. Pur perplesso dal fatto (alcuni miei progetti si avvicinano a quella cifra, non oso pensare progetti più importanti), disattivo lo ZF, chiudo tutti gli altri progetti, e continuo a programmare per un po’, finché non si ripresenta il problema anche con “miseri” 150-200 file nel progetto.

Allora cancello il workspace e tutte le config di Eclipse e riprendo, pensando a una config corrotta. Dopo aver riscaricato tutti i plugin. Illuso. Dopo 2 ore per ripristinare tutto si ripresenta lo stesso errore. Decido quindi di aggiornare Eclipse, cosa che non avevo fatto perché sembra che la nuova versione abbia problemi con l’SDK Android.

Helios

Ho quindi scaricato la nuova versione (Helios), direttamente con PDT integrato, e ho (re)iniziato a configurare e scaricare plugin.

Ma i plugin non funzionavano.

Apparivano nella finestra dei moduli installati, se tentavo l’update mi diceva che non c’erano aggiornamenti, non potevo abilitarli o disabilitarli, solo rimuoverli. Ma non facevano niente. Niente nuove perspective, niente nuovi progetti, niente finestre aggiuntive.

Scavando (per ore) tra le configurazioni e su Internet non ho trovato niente di risolutivo, finché, alle 9 di sera, ho deciso di insospettirmi del fatto che Helios (Eclipse 3.6) creasse una cartella di nome .eclipse/org.eclipse.platform-3.5.0 nella mia home, e ho messo questo in Google, trovando finalmente il bug report nel tracker di Eclipse.

A quanto pare il nuovo Eclipse vuole scrivere nella directory di installazione quando si installano nuovi plugin. Controllando, infatti, si trova un permesso rws sul gruppo in diverse sottodirectory.

A questo punto ho semplicemente fatto un

chown -R root.adm /usr/local/eclipse-3.6

e ho assegnato il mio utente al gruppo adm (lo era già, in realtà). Tutto ha ripreso a funzionare senza problemi. Mi riservo di valutare i rischi di questa operazione, ma a una prima occhiata sembrano abbastanza limitati (un plugin può spattumare Eclipse, ma nel caso lo reinstallo, e lo poteva fare già prima).

Android

Lo so, sono masochista.

Sul sito di Android è scritto chiaramente di NON usare Helios perché ci sono dei bug irrisolti. Ma io ho la testa dura. E comunque ho tenuto la vecchia versione di Eclipse installata, giusto in caso…

Con Helios ho provato a creare un nuovo progetto di test, con target Android 2.2 e minSdk 3 (Android 1.5). Lo crea e mi dà subito errore dicendo di non trovare la package “android”. Lo aggiungo a mano tra le Referenced Libraries del progetto, e gli errori spariscono, ma ora mi dà errore di conversione da Java a Dalvik. Indagherò nelle prossime ore/giorni.

Io pensavo che i problemi si limitassero a un bug già segnalato, peraltro correggibile in modo abbastanza semplice (Window->Preferences, XML->XML Files->Editor, togliere la spunta a “Use inferred grammar…”).

Update 10:10

Il problema con il package android si risolve semplicemente: Window->Preferences, quindi General->Workspace->Linked Resources, attivare la spunta su “Enable Linked Resources”. Bisogna farlo prima di creare o scaricare qualsiasi progetto Android, altrimenti non ho idea di come aggiungerlo in seguito.

Dopo esattamente due mesi di silenzio, finalmente mi ricordo che ho anche un blog, e torno a scriverci per parlare un po’ di questo mio primo PHPday.

Complice la vicinanza e un’interesse crescente, dopo l’annuncio, su come potesse essere una giornata immerso tra i programmatori PHP, ho fatto la pazzia e mi sono iscritto, approfittando dell’offerta early bird. Arrivato lì in auto, la prima (e unica, direi) brutta sorpresa: l’hotel non aveva un parcheggio proprio, e i Carabinieri, coadiuvati da un carro attrezzi, stavano portando via auto in divieto lungo le strade. Per fortuna dopo 15-20 minuti ho trovato un buco anche abbastanza vicino.

Veloce passaggio alla registrazione, dove mi hanno riempito di gadget (maglietta, cappellino, portacellulare a forma di sedia/antistress, oltre al tesserino identificativo) che non sapevo dove infilare visto che avevo le mani impegnate dall’Eee e dall’ombrello, e poi l’attesa per l’inizio che, come nella migliore tradizione di tutte le conferenze, è partito con mezz’ora di ritardo. Un plauso agli organizzatori che in 30 secondi hanno condensato i saluti per cui era prevista una mezz’ora, per cui tutti i talk sono stati abbastanza in orario.

L’affluenza, nonostante i timori visto il prezzo di iscrizione, è stata molto buona.

Tranne uno, per cui mi aspettavo tutt’altro, tutti i talk sono stati interessantissimi, e mi è dispiaciuto veramente tanto doverne perdere 2 o 3 a causa delle sovrapposizioni (c’erano tre “percorsi” contemporanei).

Interessante l’intervento di Rasmus Lerdorf (di cui parlerò probabilmente in un altro post) riguardo lo sviluppo di PHP, anche se purtroppo era subito dopo pranzo e mi sono perso l’inizio.

Zend Italia ha inoltre organizzato una sessione straordinaria di esame per la certificazione in PHP5, ed ha offerto l’iscrizione gratuita ai primi 10 iscritti. Ne ho approfittato subito e mi è andata bene. Anche l’esame è andato bene, visto che ora sono Zend Certified Engineer.

L’unica nota dolente è che l’esame mi ha fatto perdere altri due talk che mi interessavano. Ma pazienza!

I pranzi e i buffet sono stati un’ottima occasione per intavolare, nonostante la mia timidezza cronica, quattro chiacchiere con altri appassionati. Venerdì sono finito a pranzo con due relatori, tra cui il rappresentante di PayPal Italia…

“Incluso nel prezzo” c’era anche l’iscrizione al GrUSP, il Gruppo Utenti e Sviluppatori PHP italiani. Solo da ieri sono stato iscritto anche alla mailing list dei soci e mi ci sto ambientando, ma vista la chiacchierata fatta sabato sera in finale dei lavori tra i membri del gruppo e la cinquantina di persone rimaste, sembrerebbe una cosa molto interessante (tra sconti, contatti, collaborazioni, ecc.)

Approfitto per ringraziare gli organizzatori per l’ottimo lavoro svolto, e per salutare Cesare e Michele (se mai passeranno di qua).

Sul sito dell’evento ci sono i video registrati durante i vari talk, quindi se non ci eravate potete farvi un’idea di come è stata.

L’anno prossimo l’appuntamento è a Rimini (a meno di inconvenienti). Farò il possibile per esserci.

Il PHPday quest’anno si sposta a Verona, e cerca di dare un taglio ancora più ampio all’evento, allungando la durata a due giorni e introducendo il canale “community” per la presentazione di prodotti opensource. Ci saranno inoltre dei lightning talk, dei “dibattiti” improvvisati dai partecipanti.

Consultate il sito per il programma completo, tuttora non definitivo, ma già con diversi argomenti interessanti sul piatto, almeno per me. Inoltre sarà una buona occasione per incontrare sviluppatori preparati e competenti, merce abbastanza rara, purtroppo.

La novità mal recepita (al punto da generare un post molto risentito del presidente del GrUSP, il gruppo organizzatore) dai partecipanti, invece, è il prezzo di iscrizione, fissato in € 100 per la partecipazione a entrambe le giornate (60 per una sola), che aumenta a 160 (e 90) se ci si iscrive dopo il 16 aprile.

Secondo me, visto quello che viene offerto (soprattutto il pranzo e due buffet per ogni giornata) non è per niente alto, ma posso capire che, per chi è abituato a parteciparvi gratis dagli eventi precedenti, rappresenti un po’ un trauma.

Probabilmente l’affluenza sarà inferiore agli anni scorsi, ma di contro il pubblico sarà più mirato e interessato.

Credo che farò il possibile per partecipare.

Un paio di giorni fa è uscita la nuova versione dello Zend Framework, la 1.7.5.

L’ho testato con alcuni siti che ho realizzato con le versioni precedenti (1.5 e 1.6) e non ho riscontrato nessuna incompatibilità, ma c’è stata una modifica abbastanza importante nella gestione delle Zend_View, per evitare attacchi di tipo Local File Inclusion.

Vi rimando al post nel blog di Matthew Weier O’Phinney per i dettagli, ma vi anticipo che se usate dei path relativi  per risalire nel fs (quindi i vari /../ ) nella definizione del path a cui trovare gli script delle view, incorrerete nella nuova protezione, e il vostro sito non funzionerà più.

Il workaround è specificato nel post di cui sopra, ma io vi consiglio di rivedere il codice per evitare i path contenenti “..”, perché probabilmente nelle nuove versioni del framework (2.x e successive) il workaround verrà tolto. Inoltre comunque attivando il workaround state rischiando di introdurre una vulnerabilità nel vostro sito.

Meglio fare le cose per bene subito.

Siamo quasi alla fine del 25 dicembre, ma non potevo esimermi dal fare i migliori auguri ai miei fedeli lettori.

Quest’anno non sono riuscito a preparare un regalino di Natale da scaricare, ma in compenso il team di LXDE ne ha fatto uno a me, accettando oggi alle 16:19 (15:19 UTC, 23:19 ora del maintainer) la patch a LXterminal per l’impostazione dei colori e del traceback, ad opera mia e di Giggio.

Grazie Fred e PCman!

Update 26/12/2008

Fred ha rilasciato oggi la nuova versione di LXterminal, la 0.1.4, che comprende questa e altre patch!

Grazie al lavoro di Giggio, che, oltre a creare il pacchetto per Ubuntu di lxterminal ha anche modificato il sorgente in modo che le modifiche alla configurazione vengano applicate al volo, oggi vi presento un’altra versione di lxterminal.

Ma bando alle ciance, ecco i pacchetti da scaricare:

• Paccetto tar.gz (debianizzato)
• Pacchetto deb per Debian Lenny x86-32
• Pacchetto deb per Debian Lenny x86-64 (amd64)
• Pacchetto deb per Ubuntu 8.04 x86-32

Oltre ai pacchetti deb già pronti per l’installazione, potete scaricare il tar.gz dei sorgenti, già debianizzato, nel caso vogliate compilarlo da soli, fare altre modifiche o semplicemente se non vi fidate dei pacchetti già pronti.

Da un po’ di tempo uso lxterminal (dal progetto LXDE) al posto di gnome-terminal, ma mi sono scontrato subito con alcune sue limitazioni. E come me anche altri utenti, come Giggio che me l’ha segnalato nei commenti del mio articolo su Debian sull’Eee900.

Ho quindi preso il coraggio a quattro mani e mi sono messo a studiarne il sorgente. Nonostante sia in C, è scritto in modo molto pulito, quindi sono riuscito facilmente a risolvere i due problemi grossi che aveva: un buffer di scrollback troppo limitato (il valore di default, credo un centinaio di righe), e le scritte in grigio su fondo nero, che rendevano stancante o anche impossibile la lettura.

I miei sforzi si sono concretizzati in una patch che ho segnalato all’upstream (che spero verrà integrata presto), e già che c’ero ho rimesso in ordine anche l’interfaccia di configurazione, che era un po’ confusionaria con due parametri, figurarsi ora che sono 5.

Ora vi potete sbizzarrire come preferite coi colori, con combinazioni anche oltre il limite dell’assurdo.

Per ora (e forse per sempre) la modifica delle impostazioni non ha effetto sulle finestre e sulle tab già aperte, ma solo su quelle che aprirete dopo le modifiche.

Ho fatto un confronto a spanne sull’occupazione di memoria di lxterminal contro gnome-terminal, e sono rimasto abbastanza sorpreso.

lxterminal, per risparmiare RAM, al momento del caricamento verifica se c’è già un’istanza di sé stesso in memoria, e se c’è le segnala di aprire una nuova finestra, quindi esce. In ogni momento avrete una sola copia di lxterminal in memoria.

Perciò, anche se non occupa molta meno RAM di gnome-terminal (circa 1.5 o 2 MB in meno), il vantaggio lo vedrete quando ne aprirete diverse finestre. Come potete vedere dallo screenshot di top, qui a fianco, 5 finestre di lxterminal occupano 17 MB (meno 8.8 condivisi, quindi 9.2 MB), mentre 5 finestre di gnome-terminal occupano ognuna tra i 15 e i 18 MB, meno i 9.3 condivisi, sono tra i 5 e gli 8 MB ognuna, per un totale di 25-30 MB circa.

La patch e i pacchetti deb

Potete scaricare la patch da applicare alla versione attualmente nel subversion ufficiale (838), il pacchetto deb di lxterminal per Debian Lenny, o il sorgente debianizzato di lxterminal da cui potete compilare il pacchetto deb per altri sistemi (Ubuntu, Sidux, ecc.).

Per compilare dal mio sorgente, scaricatelo (purtroppo WordPress mi ha segato tutti i punti nel nome del file tranne l’ultimo…), poi aprite una shell e digitate:

sudo aptitude install fakeroot
mkdir temp
cd temp
sudo apt-get builddep lxterminal
tar -xzovf /path/al/file/scaricato/lxterminal-0131tar.gz
cd lxterminal-0.1.3.1
fakeroot debian/rules binary

A questo punto, dentro temp/ dovreste avere (se la compilazione è andata a buon fine) il pacchetto lxterminal-0.1.3.1-1.deb che potete installare con

sudo dpkg -i lxterminal-0.1.3.1-1.deb

In caso di dubbi, chiedete pure, vedrò di aiutarvi, nei limiti del possibile.

Se qualcuno si volesse prendere la briga di compilarlo per Ubuntu e volesse inviarmelo, sarò felice di ospitare qui il pacchetto.

Con la release 4.4.9, rilasciata il 7 agosto, si chiude la storia di PHP4. Era già stato annunciato un anno fa, e dall’8/8/8 (8 agosto 2008) la versione 4 di PHP non verrà più supportata né sviluppata. Non ci saranno nemmeno patch di sicurezza, se non da parte di terze parti (come Debian, che sicuramente lo supporterà almeno fino al 2010, visto che in lenny c’è ancora).

Era ora!

PHP4 ha segnato una discreta svolta rispetto a PHP3, con l’introduzione della programmazione a oggetti.

Ma PHP5 è su un altro pianeta. La programmazione a oggetti è enormemente migliorata rispetto al 4, e sono state deprecate diverse feature che rappresentavano enormi buchi di sicurezza o fonti di inefficienze o di mal di testa da parte dei programmatori, tra cui il maledetto register_globals, ma anche il safe mode, le magic_quotes, ecc.

Queste, con PHP6, spariranno del tutto. Quindi conviene iniziare subito a sistemare i propri software, e/o a disinstallare dai propri server i software che ne fanno uso. E con PHP6 (e 5.3) verranno introdotte altre novità tra cui i namespace e un maggior supporto a UTF-8.

Il problema finora è stata l’enorme mole di software scritti in PHP3, portati in PHP4 contando su queste caratteristiche, e mai aggiornati, per pigrizia o perché “finché funziona, non ripararlo”. Questo ha condizionato la diffusione di PHP5 che, dopo quasi 4 anni dall’uscita, è adottato ancora da solo il 30% dei provider a livello mondiale.

Chi glielo fa fare di installare PHP5 se nessuno sviluppa col 5, e chi ce lo fa fare di sviluppare in PHP5 se nessun provider ce lo fornisce?

Per fortuna diversi grossi progetti, tra cui Drupal, hanno deciso di abbandonare PHP4 per “costringere” i provider a fornire il 5, e questo ha convinto la Zend a dare l’annuncio della morte di PHP4.

Ora speriamo che i sysadmin vengano autorizzati all’upgrade al più presto, anche se ci saranno sicuramente milioni di utenti che si lamenteranno che il loro PHPNuke (una polveriera con la miccia già pronta) in PHP3 non gira più.

Aggiornate!

Da un po’ di tempo seguo lo sviluppo di Clutter, una libreria che permette di scrivere interfacce 3D basate su OpenGL, e quindi automaticamente accelerate se avete i driver 3D per la vostra scheda, in modo molto semplice.

Non andando molto d’accordo con il C (mi si ingarbugliano spesso i puntatori e i cast ), aspettavo che fossero stabili e utilizzabili i binding per Vala, e dopo il recente rilascio della versione 0.8.0 di Clutter, finalmente anche i binding sembrano a buon punto, quindi mi sono messo a smanettarci. L’unica “fregatura” è che per ora bisogna scaricarli via SVN e installarli a mano in /usr/share/vala/vapi/.

Purtroppo non si trovano molti esempi in Vala, e quelli che si trovano sono basati sulla versione 0.6.x di Clutter, quindi ho cercato di fare un mix di questi e degli esempi in C sul sito ufficiale, seguendo il manuale ufficiale di Clutter che, nella migliore tradizione Gtk/Gnome, è utilissimo se sapete già usarlo, ma molto rognoso se state iniziando, e me ne sono uscito col primo programmino:

using Clutter;
using GLib;
using Gdk;

public class Scena : GLib.Object
{
    public Clutter.Label label;
    public Clutter.Timeline timeline;
    public Clutter.Color label_white;
    public Clutter.Color label_red;

    construct {

        this.timeline = new Clutter.Timeline(720,15);
        this.timeline.loop = true;
        this.timeline.new_frame += this.frame_cb;

        Clutter.Color label_white = {0xff, 0xff, 0xff, 0xff };
        this.label_white = label_white;

        Clutter.Color label_red = {0xff, 0x00, 0x00, 0xff };
        this.label_red = label_red;

        this.label = new Clutter.Label();
        this.label.set_font_name("Sans 24");
        this.label.set_text("Prova");
        this.label.set_color(ref label_white);
        this.label.set_position(10,10);
        this.label.set_reactive(true);
        this.label.button_press_event += this.button_press;
        this.label.button_release_event += this.button_release;
        this.label.enter_event += this.enter_event;
        this.label.leave_event += this.leave_event;
    }

    public void frame_cb(Clutter.Timeline tl, int frame_num)
    {
        if (frame_num <=360) {
            this.label.set_position(10+frame_num, 10+frame_num);
        } else {
            this.label.set_position(730-frame_num, 730-frame_num);
        }

        this.label.set_rotation(Clutter.RotateAxis.Y_AXIS, frame_num, 0,0,0);
        this.label.set_opacity((uchar)(frame_num%255));
    }

    public bool button_press(Clutter.Label label, Clutter.ButtonEvent event)
    {
        stdout.printf("Button press\n");
        return false;
    }

    public bool button_release(Clutter.Label label, Clutter.ButtonEvent event)
    {
        stdout.printf("Button release\n");
        return false;
    }

    public bool enter_event(Clutter.Label label, Clutter.CrossingEvent event)
    {
        label.set_color(ref this.label_red);
        return false;
    }

    public bool leave_event(Clutter.Label label, Clutter.CrossingEvent event)
    {
        label.set_color(ref this.label_white);
        return false;
    }

}
public class Test : GLib.Object
{
    static void main (string[] args) {
        Clutter.init (ref args);
        Clutter.Stage stage = (Clutter.Stage) Clutter.Stage.get_default ();
        Clutter.Color background;

        stage.get_color(out background);
        background.red = (char) 0x61;
        background.green = (char) 0x64;
        background.blue = (char) 0x8c;
        background.alpha = (char) 0xff;
        stage.set_color (ref background);

        stage.set_size(640, 480);

        var scena = new Scena();

        stage.add_actor(scena.label);
        scena.timeline.start();

        stage.show_all ();

        Clutter.main ();
    }
}

Il programma, se mi passate il francesismo, è di una stupidità disarmante.

Si limita a creare un “attore” (nel gergo di Clutter) rappresentato da una label (un testo) con font Sans 24 punti, di colore bianco, e a metterlo sulla scena (stage), data da una finestra da 640×480 pixel con sfondo azzurrognolo.

Tutto il resto è magia! Viene reso sensibile l’attore, e vengono intercettati i segnali di base: il puntatore si muove sopra la label, il puntatore esce dalla label, viene premuto il tasto sinistro del mouse, viene rilasciato il tasto sinistro del mouse. Poi il tutto viene animato tramite una timeline, formata da 720 frame a 15 frame al secondo (è già abbastanza fluido. Ho provato anche con 30 e 60, ma la differenza quasi non si nota, tranne per la velocità di movimento della scritta). I 720 frame li ho scelti per non complicarmi la vita, visto che le rotazioni sono in gradi, ma potete usare quello che volete.

La label si muove dall’angolo in alto a sinistra a quello in basso a destra, e nel frattempo ruota su se stessa e appare piano piano, per poi sparire di nuovo. Il tutto avviene nel callback frame_cb() che, in base al frame in cui si trova, applica le variazioni all’attore.

Se vi muovete col mouse sopra la label, questa diventa rossa, se ne uscite, torna bianca (enter_event e leave_event). Se ci cliccate vi appare un messaggio nella console (button_press e button_release). Il tutto anche mentre la label si muove!

Le possibilità sono veramente infinite.

Si possono muovere gli attori (che però sono limitati ad essere 2D) in uno spazio completamente 3D. Li si vede rimpicciolire quando si allontanano lungo l’asse z, e ingrandire quando si avvicinano, e si deformano quando si allontanano dal centro (il punto di fuga della scena). Si possono caricare immagini in diversi formati, compreso l’SVG (vettoriale).Si possono raggruppare diversi elementi (immagini, testi, video ed altro) in un gruppo che è a sua volta un attore, e può essere spostato, scalato, ruotato, ecc.

Grazie a Pango, il testo non ha limiti di nazionalità e di caratteri strani. Si possono inserire filmati supportati da GStreamer, renderizzare su superfici Cairo, embeddare il tutto in finestre Gtk+ e, tramite librerie esterne, utilizzare un motore basato su leggi fisiche o embeddare il motore WebKit per visualizzare pagine HTML.

Inoltre sono supportati diversi dispositivi di input e si possono definire le animazioni tramite scripting in JSON.

Io ho appena iniziato a scalfire la superficie di questo enorme iceberg, ma già intravedo sviluppi spaventosi. D’altronde non serve nemmeno fantasticare tanto. Se avete presente l’interfaccia dell’iPhone/iPod Touch o quelle che ho linkato qualche giorno fa per Android, ecco, avete un’idea di cosa ci si possa fare. Anche Intel, per Moblin, probabilmente userà clutter per la GUI.

Clutter è anche multipiattaforma, e Vala, dopo aver installato le GLib ed eventualmente le GDK e le Gtk+ sotto Windows/Mac, può essere compilato anche su questi sistemi, quindi i software gireranno senza problemi su tutti e tre i sistemi.

In questi giorni sono pieno di lavoro fin sopra la testa, quindi perdonatemi se posto poco, ma oggi sono venuto a conoscenza di una cosa che mi ha fatto perdere parecchia della stima che avevo in Google.

Sembra che Google stia distribuendo le nuove versioni dell’SDK per Android solo ai programmatori che hanno superato la prima fase del concorso per lo sviluppo di applicazioni, quello che aveva suscitato le ire degli italiani e anche un’interrogazione in parlamento, a causa delle nostre leggi sui concorsi.

Tutti gli altri sviluppatori stavano aspettando le patch da oltre 4 mesi, e avevano segnalato diversi bug, anche gravi, nell’SDK stesso, ed ora un dipendente di Google, per sbaglio, ha inviato alla mailing list degli sviluppatori, invece che a quella dei vincitori del concorso, un messaggio in cui li informa che la nuova versione dell’SDK è disponibile della loro area privata di download.

Si è scoperto poi che quegli sviluppatori hanno firmato un NDA (Non Disclosure Agreement) che vieta loro di rilasciare informazioni sull’SDK.

Ora molti sviluppatori sono delusi dal comportamento di Google, e io sono d’accordo con loro. Che senso ha rilasciare l’SDK solo ad alcuni e non a tutti? Potrebbe essere comprensibile dare un canale preferenziale per le informazioni o per il debug all’SDK a questa elite, ma lasciare indietro tutti gli altri significa semplicemente che non c’è alcun interesse nello sviluppo open source, ma solo nello sfruttamento della comunità per la scoperta di bug, senza dare loro nulla in cambio.

Cercando informazioni ho poi scoperto che Google non ha nemmeno mai rilasciato i sorgenti di Android, e che si riserva di farlo solo dopo che sarà uscito il telefono vero e proprio, e che David “Lefty” Schlesinger, che se ne è lamentato nella mailing list, è stato moderato per averlo chiesto.

Non mi meraviglia che molti stiano abbandonando Android per sviluppare per l’iPhone, anche se avrei preferito si fossero rivolti a OpenMoko, che ne ha più bisogno. Ma solo sicuro che qualcuno tra loro lo farà.

Pessima figura, Google.

Oggi, con un po’ di tempo a disposizione, mi sono messo a lavorare su Esse ed Essedue, e ho implementato alcune modifiche che mi hanno convinto a portare la versione alla fatidica 1.0:

• In fase di chiusura viene controllato che non ci siano file aperti e modificati ma non salvati, e viene chiesta conferma
• Si possono aprire file direttamente dalla linea di comando. Se non esistono o sono illeggibili viene aperto un requester di errore
• Ho aggiunto un file .desktop, in modo da farli apparire nei menu di Gnome, KDE e dei WM e DM che seguono le direttive freedesktop.org
• Entrambi sono stati debianizzati. I file per creare il pacchetto deb sono inclusi assieme ai sorgenti.

Ora anche chi non era interessato a Vala o alla programmazione in genere, potrà scaricarsi il pacchetto deb della versione che preferisce, presente nella pagina di progetto di Esse, ed utilizzarlo. Non ho testato, ma in teoria il pacchetto dovrebbe essere compatibile anche con Ubuntu 8.04.

Se non vi piace, aptitude remove è vostro amico.

Se trovate dei bug non esitate a segnalarmeli.

Sviluppi futuri

A meno che a qualcuno (anche solo uno) non interessi in modo particolare, questa 1.0 sarà l’ultima versione di Esse (la versione che utilizza Glade), mentre proseguirò lo sviluppo solo di Essedue (la versione “standalone”). Il motivo principale è che è noioso fare il porting delle modifiche e delle correzioni tra una versione e l’altra. Purtroppo glade usa prototipi di chiamata delle callback diversi da quelli di signal_connect(), quindi non basta un copia/incolla, ma devo verificare riga per riga che ogni modifica funzioni in entrambi i casi.

Vista la natura “piccolo è bello” di Esse, togliere la dipendenza da glade e da un file esterno è il passo più logico per mantenere semplice il software.

La versione 1.0 resterà comunque a disposizione anche per studiarne il sorgente, e correggerò i bug che si presenteranno.

La versione 2.x (con supporto per configurazioni e, forse, stampa) sarà solo per Essedue.

Segnalo a chi fosse interessato, nella pagina dedicata ad Esse, il mio micro-editor scritto in Vala, la disponibilità di Essedue.

Si tratta dello stesso micro-editor, con le stesse caratteristiche minimali, a cui è stata completamente rimossa la dipendenza da Glade. Ora la GUI viene costruita interamente da codice, e per i menu e la toolbar ho utilizzato UIManager.

Il pacchetto è più piccolo, in quanto XML non è proprio un formato “risparmioso”, mentre l’eseguibile è cresciuto leggermente, da 36 a 40 KB. In compenso, in memoria, esse occupa 13.3 MB (di cui 8.1 condivisi, quindi 5.2) ed essedue 12.6 (di cui 7.6 condivisi, quindi 5.0). In pratica tutto il risparmio, come previsto, è dato dalla libglade (500 KB) e dal DOM XML per la stessa (circa 200 KB). Il risparmio non è enorme, soprattutto in un sistema che usa già glade per altri software, ma in un sistema embedded come un palmare anche solo quei 200 KB potrebbero essere utili per qualcos’altro.

Per fare un confronto molto spannometrico, geany occupa 19.2 MB (di cui 9.5 condivisi, quindi 9.8) e gedit  28.5 (di cui 15 condivisi, quindi 13.5).

Ora non mi resta che capire dove vadano a finire quei 5 MB, viste le dimensioni dell’eseguibile, ma presumo in strutture di sistema, aree allocate dalle librerie, bitmap dei widget, ecc. Mi piacerebbe capire se si possono ridurre.

Come promesso, ho trovato il tempo di ripulire un po’ il codice del mio primo programmino in Vala, e per l’occasione ho creato una sezione apposita del sito dedicata a Vala, con una sottosezione dedicata a questo programmino, che ho chiamato Esse (spero non ci siano altri software con lo stesso nome…).

Il codice non è molto denso di commenti, anche perché, secondo me, è talmente chiaro e lineare che avrei finito col riscrivere in italiano quello che già si capisce leggendolo. L’unica cosa che forse confonde un po’ le acque sono i continui cast tra un oggetto e l’altro. Spero che nelle future versioni di Vala il tutto venga un po’ automatizzato e reso più trasparente.

Che altro aggiungere? Scaricatelo, guardate il sorgente, provatelo e fatemi sapere le vostre impressioni. La licenza è GPL2.

Vi ricordo che avrete bisogno del compilatore Vala (e del GCC) per compilarlo. In Debian Lenny (testing) è già presente da diversi mesi, quindi basta un

aptitude install valac

Happy hacking.

Come mi ero ripromesso, in questi 5 mesi ho dato un’occhiata a questi due nuovi linguaggi che sono apparsi sulla scena, e mi sono fatto un’idea sommaria delle loro capacità.

Vediamone velocemente le caratteristiche, i pro e i contro.

D

D è un linguaggio sviluppato dalla digitalmars, cercando di prendere il meglio da C++, Java, C# ed Eiffel. Ne è venuto fuori un linguaggio molto potente, che supporta programmazione ad oggetti, metaprogrammazione, moduli, unit testing integrato nel linguaggio e gestione automatizzata della memoria con garbage collector. Si può inoltre scrivere codice assembly direttamente nei sorgenti D.

Il tutto viene compilato in codice macchina, ed usa solo una libreria compilata staticamente nel software per tutte le funzionalità di base, mentre si avvale di due librerie dinamiche (tango e phobos) per alcune caratteristiche più avanzate.

Il codice sorgente è generalmente abbastanza pulito, e le prestazioni dei programmi generati sono, in alcuni casi, migliori degli equivalenti in C++.

La comunità è già molto vasta, e ha creato (o sta creando) bindings per le più comuni librerie, che comunque richiedono un lavoro di programmazione scarsamente automatizzabile, oltre a software di supporto come IDE o generatori di documentazione direttamente dai sorgenti, oltre a librerie apposite per questo linguaggio.

Tra gli svantaggi più gravi, secondo me, il fatto che il linguaggio viene portato avanti praticamente da una sola persona (Walter Bright) che, per quanto bravo, rallenta lo sviluppo del linguaggio. Ancora peggio, sempre secondo me, il fatto che la licenza con cui viene distribuito il compilatore ufficiale (DMD) non è di tipo open source, e per questo non è possibile inserirlo in alcune distribuzioni, come Debian, che usano solo software open.

In realtà esiste una versione open source del compilatore, GDC, che però è anch’essa sviluppata da una sola persona, per di più spesso latitante, e che usa un frontend coperto da copyright (di DigitalMars), per cui non può essere integrato in GCC, dove avrebbe una comunità di sviluppatori molto più vasta. Inutile dire che Bright non ha alcuna intenzione di cedere il copyright a FSF.

Il linguaggio sembra ottimo come general purpouse, è in gran parte multipiattaforma, ma sotto Linux presenta alcuni problemi che me l’hanno fatto scartare a favore di Vala. Per esempio il fatto che molti software devono essere adattati a livello sorgente per poter essere compilati con GDC (che è presente in Debian), ed altri che proprio non funzionano con GDC. Tra questi ci sono anche i binding per le librerie Gtk+, chiamati GtkD. Questo costringe ad usare il compilatore closed source dmd per scrivere programmi gtk, e quindi li esclude automaticamente da un’eventuale inclusione in Debian (infatti non esiste il pacchetto deb per GtkD).

Anche la libreria che dovrebbe essere standard di D (Tango) non esiste in formato opensource, mentre si trova solo Phobos, che sembra sia deprecata. In generale la situazione intorno a D è spesso molto confusionaria, anche se si stanno sviluppando progetti particolarmente interessanti.

Questo non ha impedito a Kenta Cho di sviluppare degli ottimi giochi per Linux che sfruttano SDL sotto Linux (li trovate sotto “Windows”, ma molti possono essere compilati quasi senza modifiche per Linux, e sono presenti in Debian).

I programmi compilati con D possono non richiedere alcuna libreria, il che lo rende buono/ottimo per scrivere software di sistema come driver, daemon e simili. Purtroppo, per ora, si portano dietro una libreria compilata staticamente che porta la dimensione minima di un eseguibile oltre i 350 KB anche per un semplice Hallo World.

Vala

Tutt’altro percorso ha portato allo sviluppo di Vala, che nasce come wrapper intorno a GObject, uno dei componenti di GLib da cui ereditano anche tutti gli oggetti di Gtk+.

Il linguaggio si ispira molto a C# per la sintassi, ed è puramente ad oggetti. In effetti ogni oggetto definito in Vala dovrebbe essere dichiarato come figlio di GObject per garantire il corretto funzionamento del software con tutte le caratteristiche previste.

Questa stretta dipendenza porta, per esempio, ad avere supporto diretto per tutti i tipi supportati dalle GLib (quindi interi da 8 a 64 bit, numeri floating point a vari livelli di precisione, ma anche array, hashtable, liste, ecc.), ed al sistema di gestione dei segnali di questa libreria, che permette di definire con una sintassi semplicissima l’associazione tra un segnale emesso da un oggetto (come un click su un pulsante) e la callback corrispondente (la funzione che gestisce il segnale).

Anche per Vala la gestione della memoria è automatizzata, in questo caso dai meccanismi già collaudati di GLib. Le variabili vengono liberate automaticamente quando non servono più, e le liste e le hash table si estendono automaticamente quando serve più spazio.

Il codice Vala viene “compilato” in codice puro in C, che viene quindi passato a GCC per la compilazione definitiva. Questo doppio passaggio, al di là di una (piccola) perdita di prestazioni in fase di compilazione, garantisce invece ottime prestazioni in fase di esecuzione (anche qui, in alcuni casi migliori dell’equivalente scritto in C++), ed una compatibilità perfetta con altri software.

Si può quindi scrivere in Vala una libreria che poi si potrà usare in C o in qualsiasi altro linguaggio, così come si può usare in Vala una qualsiasi libreria per Linux tramite la scrittura di un file di definizione (VAPI) per le sue funzioni. In alcuni casi questo file può essere generato in modo quasi automatico da alcuni tool, e in pochi mesi sono nati decine di binding a librerie più o meno conosciute, a partire, naturalmente, dalle Gtk, passando per molte librerie di Gnome (tra cui GStreamer, Canvas, GIO, Glade, ecc.), per finire con Gecko e Webkit, SDL, Hildon, JSON, Curses, SOUP, USB, ecc.

Il linguaggio è quindi ottimo per scrivere software con interfaccia grafica, principalmente Gtk, e rimane ottimo anche per software di base come i daemon o i plugin per Gnome, in quanto l’unica libreria essenziale per il funzionamento è appunto la GLib. Non è adatto a scrivere driver per il kernel, anche se, con un po’ di attenzione, forse ci si può riuscire.

Tra i difetti del linguaggi, sicuramente, la sua giovane età, che implica che lo sviluppo sia a volte vorticoso al punto da rendere incompilabile un software scritto per una versione sulla versione successiva. Nella maggior parte dei casi, comunque, si tratta di correggere pochi punti del codice per adeguarsi alle nuove caratteristiche.

Ci sono ancora alcuni bug aperti su cui gli sviluppatori non hanno ancora messo le mani, ma in generale per quelli più gravi la velocità di risposta e di correzione è molto alta, nonostante il numero esiguo di programmatori, in pratica solo uno fisso, Juerg Billeter, con il contributo di Raffaele Sandrini e, sporadicamente, di una decina di altri che seguono la mailing list e propongono patch.

Stando alla Roadmap, verso la fine dell’anno è prevista la versione 1.0, e finora i rilasci sono stati abbastanza ben rispettati.

Forse il difetto più grosso che ho riscontrato, ad oggi, è la documentazione molto carente. Fortunatamente gli esempi che si trovano in giro e il supporto della mailing list del progetto spesso aiutano a portare avanti il lavoro, anche se un po’ a braccio.

La scelta

Immagino che dal mio entusiasmo nella descrizione si sia già capito cosa ho scelto.

“Purtroppo” la gran parte del software che scrivo ha a che fare con le interfacce e coi database (e tutto è per il web o per Linux), quindi per me è fondamentale che siano ben supportate le librerie Gtk (non mi piacciono le Qt…), e D era troppo limitato da questo punto di vista, oltre ad essere molto più complicato compilare i vari moduli-binding per le altre librerie come SQLite, MySQL, ecc.

Non è un brutto linguaggio, tutt’altro, e mi riprometto di studiarlo meglio in futuro, sperando che nel frattempo il supporto del compilatore GDC e, soprattutto, dei binding per le varie librerie vengano migliorati. Purtroppo in questi 5 mesi non ho visto molto fermento nella comunità, mentre lo sviluppo di Vala procede con una velocità che non avevo mai visto prima, nonostante il numero molto più ridotto di partecipanti.

Nel giro di un weekend ho quasi completamente finito di scrivere in Vala un editor (molto semplice) a tab in Gtk, in meno di 400 righe di codice, che compila in un eseguibile di circa 35 KB (in memoria occupa di più, circa 12 MB, ma in gran parte sono librerie condivise come gtk, pango, ecc., quindi l’occupazione reale è inferiore ai 4 MB).

Appena riuscirò a trovare il tempo di renderlo compilabile (e magari avrò ripulito un po’ il codice) lo metterò scaricabile da qui. L’ho sviluppato con la versione 0.3.1 del compilatore ma, in seguito a una mia segnalazione di bug sui binding per GLib Module, Juerg ha separato, nella versione 0.3.2, il vapi di GModule da quello di GLib, quindi devo rivedere le inclusioni. Credo sia questione di 15 minuti sistemarlo, ma voglio vedere bene cosa ha combinato.

Qualche giorno fa Donald Knuth, uno dei mostri sacri della programmazione, autore di vari libri della serie Art of Computer Programming, ha rilasciato un’intervista a InformIT in cui, tra le altre cose, esprime un parere estremamente negativo sulla attuale tendenza dei produttori hardware verso le architetture multi-core.

Il suo pensiero si può riassumere più o meno con: i produttori hardware non sanno più come migliorare le prestazioni dei loro chip, quindi hanno riciclato l’idea del multiprocessing, mantenendo le prestazioni fisse (o inferiori) su un singolo core, e mettendo diversi core per poter dire che la CPU è più veloce. In questo modo fanno ricadere la “colpa” nel mancato rispetto della legge di Moore (il raddoppio della potenza di elaborazione ogni 18 mesi) sui programmatori, dicendo che non sono in grado di scrivere software adatto alle nuove architetture.

Io, come diceva un saggio, sono “completamente d’accordo a metà col mister”.

Il problema hardware

Tutto si riconduce alla sostanziale stagnazione delle prestazioni delle CPU single-core da qualche anno a questa parte. Si sono raggiunte miniaturizzazioni oltre le quali si rischia di creare corto-circuiti tra i componenti, e frequenze oltre le quali si rischia di generare interferenze tra le piste o, peggio, surriscaldamenti e consumi sproporzionati, che possono portare la CPU a fondere o a esplodere letteralmente in mancanza di sistemi di raffreddamento che sono sempre più esagerati (dai ventoloni da 6″ a 5-6000 giri/minuto a sistemi di raffreddamento a liquido o a celle di Peltier).

Semplicemente sembra che la tecnologia abbia quasi raggiunto il suo limite e, a meno di un “breakthru” nei metodi costruttivi, che comunque molti stanno cercando nel campo ottico o quantistico, sarà difficile spremere ulteriore potenza ai chip.

La soluzione, quindi, è stata quella di riciclare la vecchia idea del multi-processore, ma ottimizzandola: si mettono più processori sullo stesso chip, in modo da non occupare il bus principale di sistema durante le sincronizzazioni tra core, che quindi rimane libero per i trasferimenti da e per la RAM e il resto del sistema. Sono ormai diffusissimi i dual core, e si vedono tri-core, quad-core e anche chip a 8 core.

Il risultato, indubbiamente, è quello di raddoppiare, triplicare, quadruplicare o ottuplicare la “potenza” disponibile.

Il problema software

Dal punto di vista software le cose non sono così semplici, purtroppo.

Il primo problema è quello a carico del Sistema Operativo, che deve garantire una certa sicurezza all’utente: che i suoi dati siano integri. In un’architettura multiprocessore (o multi-core, che è praticamente la stessa cosa) fisicamente vengono eseguite più operazioni contemporaneamente. Questo significa che ognuno dei core può (o potrebbe) modificare la stessa cella di memoria, o magari leggerla mentre un’altro la sta scrivendo, per non parlare dell’accesso contemporaneo a una periferica.

Parte di questo problema viene risolta dall’hardware, che arbitra l’accesso al bus ai processori, ma buona parte viene comunque delegata al S.O., visto che comunque una operazione che un software ritiene “elementare” come può essere scrivere un carattere sullo schermo viene spezzettata in decine o centinaia di istruzioni a livello assembly.

Inoltre il S.O. deve mantenere una certa affinità di un processo con una CPU, per evitare che dopo un context switch, un processo rimbalzi tra una CPU e l’altra, svalidando continuamente la cache relativa, e quindi ammazzando le prestazioni. Ma anche l’affinità deve essere tenuta sotto controllo, per evitare che, morti tutti i processi che giravano su una CPU, i restanti sfruttino solo l’altra, dimezzando le prestazioni.

Questo porta quindi a dei rallentamenti per proteggere zone di memoria o semplicemente per decidere su quale CPU/core debba essere eseguita una certa operazione.

L’altra faccia della medaglia è rappresentata dagli algoritmi: se c’è un solo processo che gira (e che fa calcoli pesanti, per esempio), questo occuperà una sola CPU, mentre l’altra sarà completamente inerte, dimezzando le prestazioni nel caso di un dual-core, o riducendole a 1/8 nel caso di un 8-core. Nel caso di 64 core…

Alcuni algoritmi possono essere resi paralleli, ma anche in questo caso si presentano diversi problemi: per esempio l’algoritmo potrebbe essere parallelizzabile in due “stream” di calcolo, ma allora in una CPU ad 8 core ne sfrutterebbe solo due. Oppure potrebbe essere parallelizzabil, per esempio, con un numero di processi pari a 1/4 del totale dei dati. Ma allora con 16 “dati” si potrebbero sfruttare bene 4 core ma non sfruttarne 8, ma soprattutto con un milione di “dati” si sfrutterebbero bene 250.000 core, ma avendone solo 2 si creerebbero 125.000 processi per core, costringendo il S.O. a gestire questa enorme coda di processi, con la possibilità di passare più tempo a sincronizzare i processi che ad eseguirli.

Visto l’attuale tendenza (2 core, 4 core, 8 core e in aumento costante) è difficile pensare ad algoritmi “ben parallelizzabili” su diverse architetture. In pratica è un bersaglio mobile.

La “terza faccia della medaglia” è data dal fatto che non è affatto semplice, oggi come oggi, scrivere codice parallelo.

Si possono scrivere programmi multiprocesso per isolare i dati da elaborare e comunicare solo tramite dei “bus” (code messaggi, buffer, ecc.) tra i vari processi in esecuzione, oppure multithread, condividendo la stessa area di memoria per evitare l’overhead dei suddetti bus, ma col rischio di andare a sovrascrivere aree di memoria sbagliate e quindi mandando a monte tutti i calcoli effettuati.

I linguaggi di programmazione attuali raramente offrono facilitazioni da questo punto di vista, quindi si tratta di un lavoro fondamentalmente manuale di sincronizzazione e trasferimento dati. Operazioni che rischiano di azzerare i vantaggi di un multicore, se effettuate in modo meno che ottimo.

Conclusioni

La situazione è abbastanza complessa, ma è già stata affrontata in passato, ed esistono tecniche di programmazione e librerie ben collaudate, ma rimane lo scoglio della difficoltà di ottimizzazione, soprattutto rispetto ad architetture che cambiano continuamente numero di core.

Dall’altra parte il multicore è un “male necessario”, altrimenti saremmo ancora fermi a 2 anni fa con le prestazioni, ed il nuovo processore Atom di Intel ne è la dimostrazione: single core a 1.6 GHz più lento del Celeron M a 900 MHz. Certo, consuma meno, ma fornisce prestazioni maggiori solo se in modalità dual-core.

Dovremo quindi abituarci a convivere con questa architettura almeno per qualche anno (poi, per i soliti corsi e ricorsi storici, si tornerà al single core, magari quantistico, finché non si riterrà nuovamente necessario ricorrere ai multi-core quantistici, ecc. ecc.).

Per i programmatori significa adeguarsi ad imparare la programmazione concorrente, e la mia speranza è che i nuovi linguaggi che si stanno affacciando ora sul mondo (D, Vala, ecc.) forniscano strumenti semplici per ottenerla. Con alcuni linguaggi semplicemente è impossibile programmare in modo concorrente, quindi potrebbero essere destinati se non all’oblio almeno a un forte ridimensionamento, in caso non si adeguassero.

Per gli utenti significa capire il proprio PC, e sfruttarlo al meglio. Per esempio lanciare due istanze della stessa applicazione contemporaneamente al lavoro su dati diversi per sfruttare entrambi i core, se l’applicazione non li supporta di suo. Un caso emblematico: compilando software su Linux con make è sufficiente specificare l’opzione -j seguita dal numero di job contemporanei da eseguire. Conviene usare n+1, dove n è il numero di CPU/core, quindi 3 per un dual-core, 5 per un quad-core, ecc. (il +1 serve a sfruttare tutte le CPU in compilazione mentre il processo extra legge o scrive su disco).

Assieme a un restyling del sito, che trovo molto meglio del precedente (almeno ora è fluido in verticale), anche se ha ancora qualche link rotto, è stata annunciata oggi la nuova versione di Zend Framework, la 1.5.

Le principali novità di questa versione sono Zend_Layout, che permette di avere un layout comune a tutte le pagine invece di doverlo ripetere per ogni View o di dover usare accrocchi per includere i pezzi in ogni View, e Zend_Form, che permette di creare dei form da passare alla View e di inglobare negli stessi le informazioni per la validazione dei campi oltre a permetterne la validazione al volo anche tramite AJAX (informando il browser tramite JSON sugli eventuali errori).

Ci sono moltissime altre novità, naturalmente, oltre a diversi bugfix.

Più veloce della luce Akrabat, che in contemporanea ha rilasciato la sua nuova versione (anche questa 1.5) del tutorial per Zend Framework, includendo già le informazioni su Zend_Layout e Zend_Form.

Trovo molto intelligente la sua scelta di categorizzare i vari form come Model, ma devo ancora vedere la documentazione ufficiale, se già lo prevedeva.

In realtà ad una prima occhiata avevo classificato Zend_Form come una feature utile al massimo per chi scrive CMS, perché rimuove dalla View le informazioni sul form, rendendo la vita difficile ai grafici/HTMListi quando si lavora in un ambiente misto, ma ora sto meditando se ricredermi. Forse lo proverò direttamente sul campo per vedere le reazioni.

Ho già installato il nuovo framework in parallelo al precedente 1.0 (che mantengo per non rischiare la compatibilità di alcune applicazioni già scritte) e nei prossimi giorni lo proverò sicuramente.

Durante una conferenza a Las Vegas, Miguel de Icaza, sul palco assieme a rappresentanti della Microsoft, incalzato da alcune domande di Mike Shcroepfer (di Mozilla) ha prima cercato di spiegare come l’accordo con Microsoft protegga solo chi scarica Moonlight dal sito Novell e non da altri siti, e infine ha ammesso che, se fosse stato per lui, l’accordo con Microsoft non si sarebbe dovuto fare, ma non era in posizione di decidere.

De Icaza, cofondatore del progetto GNOME e della (ormai estinta) Ximian, ora è vice presidente di Novell.

Moonlight, per chi ancora non lo sapesse, è l’implementazione “open source” (tra virgolette perché appesantita dai brevetti Microsoft) di Silverlight, la risposta di MS, appunto, a Flash/Flex/AIR di Adobe. Per come la vedo io, sono entrambe tecnologie chiuse, anche se apparentemente open, quindi da evitare finché possibile.

Di recente Nokia (probabilmente stressata da MS) ha annunciato che avrebbe reso disponibile Silverlight sui suoi cellulari intelligenti (le serie S40 e S60).

Novell aveva già ricevuto pesanti critiche dalla comunità per il suo accordo con “il nemico”, soprattutto dal sito BoycottNovell, che non ha mancato di criticare anche Moonlight. Forse De Icaza si sta accorgendo che nel mondo Linux perdere il supporto della comunità può essere molto rischioso.

Secondo me, semplicemente, Linux non ha bisogno di Mono. Nessuna applicazione (che io sappia) scritta per .Net funziona su Linux, nemmeno le più semplici. E tutte quelle scritte per Linux sfruttano Gtk o meccanismi di Linux, per cui non funzionano con Windows, quindi il motivo principale dell’esistenza di Mono viene a cadere. Ritengo che ci siano già molti strumenti per sviluppare rapidamente su Linux (dall’immensità di librerie disponibili per C e C++ a Python, passando per Gambas, Ruby, e anche Java. E perfino PHP, volendo, anche fuori dal web), e che sarebbe meglio spendere energie per sviluppare progetti più significativi, come Vala e GDC, che hanno una cronica mancanza di sviluppatori, ma nonostante ciò stanno crescendo.

Sono state annunciate ieri le due nuove versioni dello Zend Framework.

La 1.0.4 è una maintenance release, che corregge un centinaio di bug. Sarò stato fortunato, o magari non uso ancora molte delle funzioni del framework, ma non mi è ancora mai capitato di incappare in un errore da quando ZF è alla versione 1.0.x. Ne ho trovati un paio mentre era in beta, corretti rapidamente.

La 1.5RC è la prima release candidate della nuova versione, che dovrebbe uscire in versione definitiva entro 1 mesetto. Qui le novità rispetto alla 1.0.x sono moltissime. La più importante, forse, è il nuovo modulo Zend_Layout che dovrebbe risolvere molti problemi dell’attuale modello di View in caso di siti con layout molto simile in molte pagine: la maggior parte, insomma. Altre innovazioni sono lo Zend_Form (che personalmente non mi piace molto perché sembra mischi la logica di Controller e View, ma dovrò approfondire) che supporta form potenziati da AJAX, nuovi helpers per Action e View per un migliore supporto AJAX, nuovi componenti per Advanced View, nuovi componenti per l’autenticazione tramite Information Card e OpenID, e miglioramenti importanti a Lucene (un “motore di ricerca” integrato nel framework, per indicizzare documenti di vari tipi), per la generazione di PDF (ora con supporto UTF-8) e ai web services (Technorati e Slide Share).

Entrambe richiedono almeno PHP 5.1.4 per funzionare, ma io consiglio di passare direttamente a PHP 5.2.

Spero solo di trovare un po’ di tempo per smanettare con la 1.5. Alcuni dei nuovi moduli sembrano molto interessanti.

Devo però muovere una critica agli sviluppatori: nella documentazione non si capisce da quale versione un certo modulo o una certa funzione sono state implementate, col risultato che ci si trova magari a cercare di usare con la 1.0.4 una funzione o una classe che esistono solo nella 1.5 e non si capisce dove sia l’errore finché non si va a vedere il sorgente del framework. Appena mi verrà attivato l’account nel bug tracker credo che aprirò una segnalazione a proposito.

Purtroppo ho scoperto sulla mia pelle che APC non serve a niente se si usa PHP via CGI, perché tiene tutte le pagine precompilate in shared memory, che naturalmente viene liberata alla fine di ogni processo CGI.

Quindi se state usando PHP come CGI, lasciate perdere APC. eAccelerator funziona, perché salva i precompilati su disco oltre che in RAM, ma non supporta (che io sappia) il monitoraggio degli upload.

Dovrò decidermi prima o poi a passare PHP4 in CGI e promuovere PHP5 a modulo di Apache, ma servirà un po’ di tempo per verificare che funzioni tutto senza problemi.

Dopo il post per gli auguri di Natale sicuramente non ve ne aspettavate uno per gli auguri di buon anno, vero?

Voevo postarlo poco dopo mezzanotte, ma la baldoria prima e la stanchezza poi mi hanno fatto desistere. Non credo sareste comunque stati lì a quell’ora a leggerlo, quindi non penso vi cambi molto la vita.

Siccome a capodanno si elencano i buoni propositi per l’anno che sta arrivando, ho pensato di raccogliere qui i miei. Magari qualcuno è d’ispirazione anche per voi. Sono in ordine sparso, man mano che mi vengono in mente.

Studiare il D (e altri linguaggi)

Da quello che leggo in giro, D è un ottimo linguaggio di programmazione, e in realtà ho già dato un’occhiata alle specifiche del linguaggio e agli esempi sul sito ufficiale. Quello che ho visto mi ha favorevolmente impressionato. In pratica è un linguaggio che cerca di prendere le parti migliori di C/C++ e di Python/Ruby. Molto flessibile, dinamico (non del tutto, naturalmente) e soprattutto compilato. Le prestazioni dei programmi scritti in D sono ottime e, a giudicare dagli esempi, è anche semplice scrivere programmi. Mi ricorda vagamente il linguaggio E che esisteva sull’Amiga, anche se in quel caso derivava da Pascal e Oberon, quindi con una sintassi più rigida.

Una delle sorprese più gradite è stato scoprire che ci si potevano fare cose come Torus Trooper e TUMIKI Fighters (non fatevi ingannare dalla grafica, sono molto divertenti ) in modo quasi completamente cross-platform.

Anche Vala sembra interessante. Si tratta di un linguaggio inventato dal team di Gnome, ispirato a C#, e molto orientato a scrivere applicazioni per Gnome (anche se, dagli esempi, sembra adatto un po’ per tutto). Lo stanno già usando per scrivere Scratchpad e anche Mickeyl per riscrivere openmoko-terminal2. Il vantaggio principale rispetto a C# stesso è che è completamente compilato, quindi non ha bisogno di virtual machine o di ambienti di runtime, o anche solo di librerie aggiuntive. A detta degli stessi sviluppatori è ancora acerbo, e molte cose sono in via di sviluppo, ma quello che c’è ha già un bell’aspetto.

Tornare in Giappone

Questo probabilmente è un proposito che non riuscirò a portare a termine entro il 2008, ma ci spero comunque. Mi mancano l’ordine e la cortesia dei giapponesi, mi manca Akihabara, mi manca il cibo giapponese. Insomma, non vedo l’ora di tornarci.

Mi sono messo come limite la primavera del 2009. Ce la posso fare! Ganbatte!

Finire i programmi e i siti che ho in corso

Questa forse è la parte più difficile di questi buoni propositi. Purtroppo la parte che mi “prende” di più di un progetto è la preparazione, le prime fasi di stesura del codice, l’organizzazione dei moduli, mentre odio totalmente e profondamente la fase di debug. Di solito il dover debuggare un software è motivo sufficiente per abbandonarlo a sé stesso. Probabilmente aspetterò l’uscita della quarta edizione di D&D per rimettere mano (e riscrivere per la terza volta) il mio Mastertools, software (in Python+Gtk+SQLite) di gestione delle campagne, con annesso database di magie (già funzionante), talenti e oggetti magici (non ancora funzionanti).

Spero di riuscire nei prossimi giorni a buttare giù almeno le basi di due siti che ho in testa da almeno un paio di mesi e di un altro paio di programmini che sto progettando da altrettanto tempo. Ma non voglio rivelare niente, anche per scaramanzia.

Comprare l’Asus Eee

In realtà sto aspettando la versione con schermo a 8, 9 o 10 pollici. Mi andrebbero bene anche i 7″ della versione attuale, ma con risoluzione almeno 1024×600. Meglio ancora 1280×768. Una bella formattata alla flash, una bella Debian con Gnome al posto della Xandros, una SDHC da 16-32 Gb montata come /home e via!

Se non sarà l’Eee sarà sicuramente un altro subnotebook di caratteristiche analoghe: 1 Kg di peso, dimensioni molto ridotte. Gradirei molto anche una durata maggiore della batteria.

Mi sono accorto che il notebook che ho ora (Dell Inspiron 8600) non lo uso mai (praticamente solo per masterizzare partite di D&D): troppo pesante (3.5 Kg), troppo ingombrante (schermo 15,4″, quindi notebook di oltre 17″), e relativamente fragile, avendo un HD al posto di una flash. E la tastiera è comunque ridotta rispetto al fisso, quindi difficile da usare. In proporzione uso di più lo Zaurus, sia per leggere e-book sia per scrivere.

Migliorare la conoscenza di PHP, Javascript e Python

Programmando in PHP per lavoro, la prima parte di questo proposito è abbastanza semplice da portare a termine, basterà continuare a lavorare . Ci sono comunque diversi argomenti che mi piacerebbe approfondire. Per esempio ho l’impressione di star usando poco e male lo Zend Framework, e che abbia ancora molte qualità nascoste da esplorare. Per di più, sta uscendo la nuova versione 1.5 con supporto per View estese e Layout!

Javascript è ridiventato molto interessante (per me, naturalmente) di recente, grazie all’arrivo di librerie e framework come jQuery che nascondono abbastanza bene le differenze più ostiche tra i browser e permettono di concentrarsi meglio sul lavoro da svolgere, più che sulle incompatibilità tra le varie versioni. Spero di poterlo approfondire maggiormente.

Purtroppo ho un po’ lasciato in disparte Python per motivi di tempo, e comunque non ero un esperto nemmeno prima. Devo impormi di riprenderlo in mano e di studiarmi bene le caratteristiche della nuova 2.5 (decoratori e compagnia cantante).

Lo nascondo qui ma non fateci caso: mi piacerebbe anche studiare un po’ Ruby. Tra l’altro è appena uscita la 1.9 che sembra abbia prestazioni molto superiori alla precedente. Tutti ne parlano, ma ora che l’hype iniziale dato da Rails si sta esaurendo, forse è il momento giusto per vedere cosa offre di veramente vantaggioso rispetto agli altri (rails a parte).

Postare più frequentemente sul blog

Questo non sarà proprio facilissimo. A volte un argomento mi pare troppo scontato o trito per parlarne qui, e voglio evitare di parlare di politica o cose del genere (che sono una flame-bait non da poco). Per scrivere post tecnici preferisco informarmi bene ed evitare di scrivere porcherie non verificate, anche se a volte devo fidarmi di quello che trovo in giro, non avendo la possibilità di provarlo direttamente.

Ciononostante, cercherò di trovare qualche argomento di cui parlare. Magari portare avanti i propositi di cui sopra mi darà anche qualche spunto interessante.

Dulcis in fundo…

Ah, naturalmente riportare la pace nel mondo! (Ecco il link diretto al sito. O una variante, se la preferite, in fondo i gusti sono gusti).

jQuery è una libreria in javascript per semplificare lo sviluppo client-side di siti, che offre in pochissimo spazio (20 Kb compressa, meno di 100 non compressa) funzioni utilissime per la navigazione e la modifica del DOM, per le richieste AJAX e per alcune animazioni di base (fading, folding, ecc.).

Per mantenere minimo l’impatto sui download è stato scelto di lasciare a plugin esterni la gestione di funzionalità aggiuntive, e di inglobare solo le più usate nel core. Uno dei plugin più famosi è UI, per la realizzazione di interfacce interattive.

Koller Juenger, nel suo blog, ha raccolto una lista di più di 240 plugin per jQuery, suddivisi anche per categoria e uso. Un lavoro titanico e molto utile.

O meglio, si può fare con la normale documentazione, ma se il nostro software deve girare su una delle distribuzioni esistenti conviene adeguarsi alle “usanze del luogo”.

OpenEmbedded è una “meta-distribuzione” nel senso che è un calderone da cui si possono generare delle distribuzioni. Le due più famose sono Angstrom e OpenMoko. Saper usare i tool forniti da OpenEmbedded significa quindi saperli usare anche per Angstrom e OpenMoko.

A parte la documentazione sul sito OpenEmbedded stesso, oggi ho trovato un’articolo su IBM DeveloperWorks sulla programmazione per OpenMoko. Sono 13 pagine (in realtà 9, il resto sono link e schede autore/articolo), e si parte dall’installazione dell’ambiente per arrivare a sviluppare un’applicazione completa che riporta alcune informazioni sul sistema. Molto chiaro e semplice da seguire. Naturalmente dà per scontato che si conosca il C e utilizza Gtk+, le librerie alla base di tutte le applicazioni grafiche di OpenMoko.

Quando una persona diventa programmatore o sistemista, la maggior parte delle volte viene affascinato da cose a cui non dovrebbe nemmeno pensare. Un cristiano potrebbe chiamarle “tentazioni demoniache”, un buddista “ricchezze terrene”, ecc. ecc. Invece sono da evitare il più possibile, e da abbandonare per poter raggiungere la Vera Illuminazione. Vediamone qualcuna.

chmod 777

Questo semplice mantra (che per i file può anche essere “chmod 666″, notate il numero diabolico) permetterà a chiunque di andare a letto con la vostra ragazza, di venire a cena a casa vostra in qualsiasi momento, di “prendere in prestito” la vostra macchina, di leggervi la posta direttamente dalla cassetta, ecc. ecc. ecc.

Seriamente: Questo semplice comando permette, su sistemi Linux e Unix, di accedere a qualsiasi risorsa (a un file, in realtà, ma in Unix/Linux TUTTO è un file) senza alcuna limitazione. Guardatevi da esso, poiché è il male. A parte dare il permesso di esecuzione (che nelle directory serve per poterci entrare, ma nei file rende eseguibile il file stesso) concede pieni poteri sul file a qualsiasi utente: lettura, scrittura, modifica, azzeramento. Forse l’unica cosa che non si può fare è cancellarlo (servono permessi equivalenti sulla sua directory). Può sembrare che risolva tutti i propri problemi (non devo più diventare root per modificarlo!), ma ci sono un sacco di motivi per cui Windows è pieno di virus e Linux no. Il fatto che le distribuzioni non usino mai chmod 777 è uno di questi.

Se un fiile ha un certo set di permessi è proprio perché nessuno, per errore o intenzionalmente, lo modifichi. Aprendo in questo modo i permessi di accesso si consente a programmi impazziti, a servizi bucati da cracker o semplicemente a un errore di digitazione di fare danni seri. Pensate a quale sia la differenza tra un “rm -Rf /” dato da utente (cancella solo i file a cui ha accesso l’utente, quindi solo la sua home e pochi file in /tmp) e dato da root (cancella tutto il sistema operativo).

goto

Qui entriamo nel campo della programmazione. Ormai è risaputo che goto è la fonte di tutti i mali, l’anticristo, il limone sulla Nutella. Lo dicono perfino Dijkstra e Wirth! (I link sono alla Wikipedia italiana, ma quella inglese è più completa). goto vi farà uscire di strada in macchina (goto fosso), vi farà entrare nello sgabuzzino invece che in bagno (goto bin). Potreste perfino finire a letto con un uomo invece che con una ragazza (goto man)! Attenti!

Seriamente: goto, se usato male (e nel 99% dei casi viene usato male) rende “spaghetti-code” i vostri programmi. Fa perdere velocemente il flusso logico delle procedure/funzioni, e porta a errori inaspettati (“ma questo codice non doveva essere eseguito quando questa variabile ha questo valore!”). Linus Torvalds lo può usare perché lui sa quello che fa.

global

Qui parlo in generale delle variabili globali. C’è un motivo per cui sono state inventate la programmazione strutturata e quella ad oggetti. Le variabili globali sono una macchina del tempo rotta, che ci porta solo indietro di 50 anni: guerra (o primo dopoguerra), malattie, dispersi, fame, ecc. ecc.

Seriamente: usare variabili globali è pericoloso quanto e forse più che usare goto: queste variabili possono venire modificate da altre funzioni che non c’entrano niente con quello che stiamo facendo, ed è impossibile sapere con esattezza, guardando il codice, che valore hanno in un certo punto. Passate valori alle funzioni, impostateli in qualche variabile di classe, ma guardatevi sempre dall’usare variabili globali. Hanno senso solo in pochissimi casi, e, se siete dei principianti, in NESSUN caso.

In PHP questo comprende anche l’uso di register_globals. Questa direttiva (che per fortuna verrà disabilitata e sarà reso impossibile abilitarla conla versione 6 di PHP) prende tutte le variabili che arrivano dall’esterno del vostro script (quindi GET e POST, i cookies, i valori in sessione, le variabili d’ambiente) e le mette tutte in un minestrone, rendendole variabili globali. C’è un ordine preciso di “riempimento” di questo minestrone, ma vi sfido a capire, a colpo d’occhio, se una variabile sia stata passata da GET o se arrivi dalla sessione dell’utente. Molto meglio usare le superglobals: $_GET, $_POST, $_COOKIES, $_SESSION e $_ENV (oltre a $_SERVER).

addslashes()/stripslashes()/magic_quotes

Qui si parla specificatamente di PHP. Il giorno che queste funzioni verranno tolte da PHP probabilmente smetterà di piovere folgore dal cielo, o più probabilmente un\\\’infinita\` di pagine web l\’una coi caratteri più sballati dell\\\’altra, e parecchi casi di SQL-injection spariranno dalla rete.

Seriamente: poche cose in una pagina web hanno bisogno delle barre prima di un carattere. Può sembrare giusto prima di infilare una stringa in MySQL (per cui la ‘ è un carattere speciale e, se contenuta in una frase, fa “escapata” con \’), ma, per esempio, in PostgreSQL il modo giusto di fare l’escape è ” (due virgolette singole) e non \’, quindi i vostri script non funzioneranno cambiando DB. Usate mysql_real_escape_string(), pg_escape_string() o, meglio ancora, PDO o un framework come Zend Framework. Per passarle su un URL (un link con <a>, per esempio) la funzione giusta è urlencode(). addslashes non è quasi mai la risposta giusta. Vale la stessa considerazione di global: se siete principianti, addslashes() non è MAI la risposta giusta.

<font>, <b>, <i>, <frame> (guest stars: <table>, <br>)

Entriamo nel mondo del web dalla porta sul retro: HTML. Il poveretto era nato con buonissime intenzioni: l’ipertesto, la digitalizzazione e il collegamento delle informazioni, la diffusione della cultura. Ma tre bambini cattivi (non facciamo nomi, solo iniziali: MS, NS e MM) gli hanno regalato le caramelle fuori dalla scuola, e da allora si sta disintossicando in diverse comunità di recupero. Per fortuna ultimamente ha trovato un bel po’ di amici che lo stanno tirando fuori dal tunnel, ma ci sono ancora un sacco di bambini cattivi in giro!

Seriamente: L’HTML è nato per descrivere la struttura delle informazioni, non la loro rappresentazione sullo schermo. Usare editor WYSIWYG facilita sicuramente lo scrivere pagine web, ma avete mai provato a modificare il posizionamento di un’immagine senza usare quegli editor, o ad aggiungere un’immagine in mezzo alle altre, anche CON quegli editor? Da un po’ il W3C ha preso una posizione netta sulla questione: l’HTML deve descrivere solo COSA è una certa informazione, mentre il COME FARLA VEDERE è compito dei CSS. COME SI COMPORTA è compito di Javascript (o ECMAscript), e con questo il cerchio si chiude. font, b e i sono (finalmente) tag deprecati. Un testo non è “Arial 18px bold italic”, ma “titolo di sezione”, quindi <h2> (per esempio). Una frase importante non è “bold”, ma “importante” (strong) appunto! Prima si impara a usare i tag giusti, meglio è.

Ho messo come guest star <table> e <br> perché si devono ancora usare, ma solo quando è giusto usarli. Non si usa <table> per definire il layout di una pagina, ma solo per intabellare dati. Non si usa <br> per fare spazio con le righe vuote, ma solo per andare a capo senza chiudere un paragrafo (che è <p>).

Una malattia molto diffusa per chi si avvicina ai CSS è la DIVite (accompagnata dalla SPANite): quando non si sa cosa mettere, si mettono un div o uno span, dimenticando che esistono decine di tag che non usa nessuno. Una lista della spesa è <ul>, una lista di passi per una ricetta è una <ol>. Una lista di definizioni da vocabolario è <dl>. Un’etichetta da dare a qualcosa è <label>. La legenda di una tabella è <caption>. Una breve citazione è <q>, mentre una citazione lunga è <blockquote>. Un indirizzo è <address>. Ecc. ecc. Imparate a usare i tag giusti al momento giusto, e il vostro codice sarà molto pià leggibile (e modificabile, che è la cosa più importante). Quando ci sarete arrivati, date un’occhiata anche ai Microformati, tenendo conto che ci sono già estensioni per Firefox che li usano, e che in futuro saranno sempre più diffusi e richiesti. E non dimenticate di impostare il DOCTYPE corretto!

Conclusione

Per ora chiudo qui, ma sono sicuro che ho dimenticato un sacco di cose. La morale è sempre la solita: diffidate delle strade che sembrano troppo semplici. Sicuramente c’è qualcosa che non va.