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.

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.

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.

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).