Sentimento a 8 Bit

Tra i diversi articoli interessanti apparsi (stranamente, essendo estate) negli ultimi giorni, uno mi ha colpito per due distinti e diametralmente opposti motivi: il fascino del tema toccato, e la sua profonda ingenuita'.
Il brano e' questo qua (originariamente letto sulle pagine del New York Times), e parla delle tecnologie disponibili e/o in fase di sviluppo per l'analisi semantica dei contenuti sparpagliati sul web e l'estrazione di dati statistici. Il fine utilitaristico di tale procedura sarebbe, in sintesi, valutare se un dato prodotto (o avvenimento, o azienda...) e' recepita benignamente o malignamente dal pubblico, consultando blogs, news, tweets ed altre disparate fonti per trarne l'opinione di fondo e convertirla in un valore numerico facilmente rappresentabile in un grafico.
La bellezza gustosamente intellettuale ed accademica di codesti strumenti di misura dell'umore, calibri per i sentimenti e righelli dell'animo, e' pero' a parer mio esclusivamente intellettuale ed accademica: allo stato dei fatti attuale, hanno una utilita' prossima a zero.
Facciamo un semplice esempio pratico, partendo da un prodotto a caso. Per comodita' e pigrizia prendo un libro recentemente recensito sul blog di una amica, "Quella Stronza del mio Capo" (sicuramente non e' il mio genere...). Ne piglio il titolo e lo cerco su Google Blogs, motore di ricerca della blogosfera; risultato: 21 menzioni, riportate ovviamente in linguaggio naturale, dunque da analizzare rigo per rigo innanzitutto per capire se effettivamente si sta parlando di quell'opera e poi per trarne l'impressione positiva o negativa avuta dall'autore del post. Ricopio il titolo e lo cerco su Anobii, community dedicata a persone che vogliono condividere le proprie letture con altri appassionati (e di cui sono membro); risultato: 50 voti, espressi per mezzo di un semplice form di rating e rappresentati in forma di media (le stelline a fianco della copertina) e tabellare (le lineette che appaiono al paragrafo "Dettagli del libro").
Ora: senza nulla togliere al valore certamente piu' completo e puntuale che puo' avere un post su un blog, val la pena dispiegare fior di risorse computazionali per setacciare l'Internet, individuare e cavare un dato che invece gia' mi viene fornito altrove secondo la modalita' a me piu' confacente (un numeretto) e con un campione di utenza ampio piu' del doppio?
Da una parte, quella dei brillanti ricercatori descritti nell'articolo di apertura, si cerca di far comprendere al computer la complessa ed intricata mente umana - e di conseguenza prima di tutto il linguaggio con cui essa si manifesta - per trarne delle conclusioni stocastiche; dall'altra, quella dell'utenza, si cerca piu' o meno consapevolmente di assecondare il computer, e strumenti semplici di interazione garantiscono una piu' immediata partecipazione e condivisione, nonche' una piu' radicata sicurezza - cliccare su una stellina da 1 a 4 difficilmente puo' portare ad errori grammaticali di cui vergognarsi col prossimo.
Ad oggi, disponendo sulle nostre scrivanie di PC fondamentalmente stupidi in grado solo di immagazzinare e visualizzare valori finiti, le applicazioni (web e non) tendono a delegare all'utente la classificazione del contenuto, vincolandolo a ragionare sullo stesso piano della macchina, appunto secondo valori finiti: da qui l'introduzione di tags da assegnare a documenti e foto, flags da settare per memorizzare l'importanza relativa di un dato, stelline per misurarne l'apprezzamento...
Interessante notare pero' come codesti paletti e restrizioni non siano solo soluzioni temporanee indotte dalla necessita' (in quanto come detto il computer non sarebbe in grado di estrarre tali metadati emozionali da solo e dunque l'utente dovrebbe proprio farne a meno), ma al contrario secondi i canoni moderni sono visti come rivoluzionari, condizionano la psicologia della interazione uomo/macchina e sono considerati naturali per chiunque. Da questa tendenza emerge del resto il discreto successo delle community wiki (in cui ciascuno aggiunge qualcosina in merito al suo argomento preferito), l'enorme successo del microblogging (ove non e' necessario stilare sermoni come i miei per esporre il proprio pensiero, 140 caratteri bastano ed avanzano), il gigantesco successo dei social network (in cui i contenuti una volta immessi rimbalzano da un utente all'altro, essendo condivisi con un semplice click, ed ogni tanto spunta un breve commento), tutte modalita' in cui l'utilizzatore fa poco dicendo tanto - o quantomeno piu' che non facendo nulla...
Qual'e' la conclusione di questa serie di osservazioni? Assolutamente nessuna. La riduzione della complessita' dell'espressione non e' ne' giusta ne' sbagliata, in quanto da una parte diminuisce la varieta' ma dall'altra garantisce un coinvolgimento di piu' persone, e va presa per quella che e': una evoluzione antropologica. Proseguira' fino all'estremo di ridurre l'intera comunicazione umana ad un ininterrotto flusso di emoticons? Si invertira' al raggiungimento di un maggiore grado di coinvolgimento delle future generazioni di utenti, smaniosi di dir la propria in modo approfondito? Se sapessi predire il futuro starei qui a scrivere su un blog anziche' correre a giocare al SuperEnalotto?
Nel frattempo dobbiamo accontentarci di quel che abbiamo, ovvero un computer che conserva numeri. E dentro questi numeri, volenti o nolenti, dobbiamo farci stare tutto: cifre, informazioni, misure. E sentimenti.

Smashing Wallpapers

L'estate sta finendo, ed un anno se ne va. Ma di "diventare grande" non se ne parla proprio, anzi credo che questa sia stata l'estate in cui abbia maggiormente impiegato del tempo appresso a programmini di dubbia utilita' (TuxChan), opere lasciate un po' in sospeso (Lobotomy). e frammenti sparsi qua e la' (prossimamente faro' cenno alla mia avventura con Mojito).
Ma in fin dei conti non me ne rammarico: di Lobotomy posso dire di aver iniziato a far qualcosa, dopo mesi o addirittura anni di inerzia, i contributi occasionali ai progetti altrui sono sempre cosa ben fatta (tantopiu' se sono componenti di una piattaforma operativa come Moblin, una delle poche speranze open contro Symbian in ambiente mobile), e i programmini scemi sono sempre utili a sperimentare cose nuove e ad arricchire la base di applicazioni direttamente rivolte all'utenza finale con poco sforzo.
Tant'e' che ieri ne ho realizzata un'altra.
Smashing Wallpapers (che devo ancora trovar la voglia di predisporre al rilascio... Nei prossimi giorni apparira' su BarberaWare) e' una utility che permette di scaricare i graziosi wallpapers che il sito di Smashing Magazine mette a disposizione ogni mese (qui quelli di agosto 2009), e caratterizzati dalla feature di riportare - in armonia con il resto della grafica - il calendario completo del mese in corso; informazione non banale, considerando che non so piu' quante volte alla settimana devo aprire il calendarietto integrato nell'orologio del desktop environment per sapere in che giorno della settimana cade una certa data e decidere se e quando piazzare un incontro o un appuntamento.
Modalita' di utilizzo del programma: metterlo nella lista di esecuzione automatica del proprio ambiente grafico e dimenticarsene. Ad ogni avvio del sistema controlla se il wallpaper del mese corrente e' gia presente, se c'e' si chiude e se non c'e' va a cercare i nuovi contenuti, li scarica e si palesa nella barra di notifica. Da li', con una essenziale interfaccia Clutter si sceglie quello preferito, lo si seleziona, ed esso viene scaricato ed applicato. Fine.
Piazzo qui l'oramai abituale video, anche se per qualche motivo Vimeo me lo mostra solo a smozzichi ed in determinate circostanze (non identificate), spero altri abbiano maggiore fortuna:

Basta cazzeggio programmatorio, da lunedi si torna a lavorare.

ToDo, UnDo

Uno dei miei pregi come programmatore e' che sono costantemente ispirato e quotidianamente espello idee. Uno dei miei difetti come programmatore e' che non riesco a concentrarmi su un progetto per il tempo necessario alla sua realizzazione, che subito passo ad un'altro.
Da tempo ho preso l'abitudine di appuntarmi le varie piu' o meno dettagliate folgorazioni che mi colgono, sempre col proposito di tenerle sott'occhio ed integrarle via via che scopro nuove tecnologie e metodi, ma inevitabilmente la coda diventa sempre piu' difficile da smaltire a causa dei tempi di realizzazione che avrebbe ogni oggetto, e sebbene nell'ultimo periodo abbia avuto modo di concretizzare qualcosa qua e la' la massa di progetti latenti diventa sempre piu' imponente. "Il genio e' per l'1% ispirazione e per il 99% traspirazione" (Thomas Edison), e non essendo io un genio sono completamente sbilanciato su un 90% del primo ingrediente ed un 10% del secondo.
Pertanto periodicamente espongo le mie (piu' o meno corrette) illuminazioni pubblicamente, nella speranza che qualcuno sull'Internet possa inciamparvi e magari essere altrettanto ispirato: non credo che avro' mai modo e maniera di far tutto, dunque tanto vale che lo faccia qualcun'altro. Ogni tanto pubblico un post su questo blog, qualche volta riporto sull'Alambicco di BarberaWare, e quando raggiungo una massa critica stipulo una lista forfettaria. Questa e' una di queste occasioni.

• Binding Glib per FUSE. L'idea emerse qualche tempo addietro, quando per lavoro iniziai lo sviluppo di un filesystem in userspace che doveva maneggiare GObjects pescati da una libreria ad hoc e ricevere eventi da una connessione DBus (anch'essa mantenuta per mezzo del binding Glib). Data la natura interna di FUSE ho dovuto aprire un thread separato in cui far girare il mainloop, che appunto restasse in ascolto sulla connessione DBus, ma l'ideale sarebbe implementare il mainloop di FUSE dentro quello Glib e far lavorare insieme i due layer. L'optimum sarebbe avere un GObject che astragga le funzioni low-level di FUSE e le richiami nel loop Glib, in modo che estendendo quello sia banale realizzare un nuovo filesystem pur godendo di tutto lo stack Glib e della pletora di sottolibrerie disponibili.
• Rsync wizard. Qualche settimana addietro, intimorito dagli inquietanti rumorini provenienti dall'interno del mio tablet, decisi che era tempo di adottare una soluzione strutturata per il backup. Diedi una occhiata in giro e trovai solo soluzioni immensamente complesse, con server da configurare e centinaia di parametri da settare, nonche' daemons in esecuzione piu' o meno permanente, ed alla fine optai per il metodo in assoluto piu' scontato: una chiave SSH, rsync ed uno script in cron. Per quanto non perfetto questo meccanismo credo soddisfi la necessita' della stragrande maggioranza dell'utenza domestica, ed ha l'unico difetto di richiedere una serie di passaggi da linea di comando non propriamente adeguati per un occasionale utente. L'idea sarebbe dunque quella di predisporre un frontend che provveda a costruire la riga con cui invocare rsync, metterla in cron ed eventualmente creare ed installare le chiavi SSH (onde poter procedere al trasferimento dei dati da un PC all'altro senza dover immettere la password; di norma il server e' installabile con una configurazione funzionale di default con qualsiasi distribuzione). Progetto estremamente semplice da imbastire, ma non completamente banale se si vuole una soluzione finale a prova di utonto, piu' una sfida di design che di programmazione.
  
• Distribuzione dei files Torrent via GIT. Questo non e' un vero e proprio progetto, quanto piu' uno spunto di indagine: emerse ai tempi della notizia dell'acquisizione di ThePirateBay e della prossima imminente chiusura del tracker torrent piu' noto al pianeta, e sebbene molti altri tracker siano disponibili in Rete e risulti ovvio che il ritmo di chiusura sia piu' basso di quello di creazione di nuovi snodi (rendendo infinetesimale il rischio di trovarsi senza un punto di riferimento) varrebbe secondo me la pena individuare una strategia completamente decentralizzata, quale appunto quella adottata dagli SCM distribuiti - GIT, ma anche Mercurial o Bazaar.
• Vista partizionata in Nautilus. Ho sempre trovato Baobab un programma assai utile: permette infatti di visualizzare il filesystem con spicchi che graficamente rappresentano lo spazio occupato dai vari files (e dalle cartelle che tali files contengono), permettendo di individuare in un colpo d'occhio le aree in cui per un motivo o per l'altro si sono accumulati dati in eccesso e di cui dunque ci si puo' sbarazzare per recuperare preziosa ROM. Tale funzionalita' sarebbe molto utile se integrata a mo' di "vista" direttamente in Nautilus, il filemanager di Gnome: si tratterebbe di prelevare il widget originario di Baobab ed includerlo dentro l'applicativo sfruttando la gia' esistente interfaccia programmatoria per tale frangente, ben poco documentata ma usata da questo hack (da usare come esempio). Rapido, ma merita qualche attenzione nel perfezionamento nell'algoritmo che computa la dimensione delle cartelle, al momento un po' lentuccio.
• Binding Bash per DBus. Il nome e' molto evocativo, anche se ai fatti si tratterebbe di qualcosa di estremamente semplice: un set di micro-applicativi (o uno solo, con piu' opzioni) da invocare da linea di comando e che permettano di dialogare in modo flessibile con DBus (ed ovviamente con i servizi esposti sul canale). Scopo del gioco: avere modo di scrivere script Bash che sfruttino i piu' avanzati servizi di sistema, dall'interrogazione di NetworkManager (per sapere se c'e' connessione o meno) alla manipolazione dello screensaver. Il compito e' meno banale di quanto non ci si possa aspettare, in quanto i metodi invocabili per mezzo di DBus possono presentarsi in una infinita combinazione di parametri, tipi di parametri e valori di ritorno, che dovrebbero essere trattati nel modo piu' trasparente possibile magari sfruttando le tecniche di introspezione proprie del protocollo onde fornire una interfaccia di utilizzo semplice.
• Integrazione autenticazione USB. Nell'ultimo periodo ho constatato (ma forse solo perche' non me ne sono accorto prima...) un incremento dei metodi di autenticazione disponibili su Linux, che fanno uso di PAM nei modi piu' disparati. Tra questi ho trovato particolarmente simpatico questo meccanismo, che coinvolge una pennetta USB da usare come chiave fisica di accesso al PC: accessibile immediatamente a tutti (contrariamente agli scanner per impronte digitali, o alle smartcard), sufficientemente sicuro e di garantito effetto con gli amici. Non sarebbe niente male integrare questo sistema nel pannello "Utenti" di Gnome, si' da mettere a portata di mouse la procedura di creazione e verifica delle chiavette e la poca configurazione richiesta.
• FUSE Installer. Tutti gli utenti informatici casalinghi vengono sconvolti da una particolare feature di Mac: i programmi si installano copiandoli in una apposita cartella, e si disinstallano rimuovendo la cartella stessa. Niente wizards "avanti avanti avanti" a la Windows, niente accrocchi strani a la Linux. Da utente tecnico rimango piu' che soddisfatto del package management tipico dei sistemi Linux (qualsiasi distribuzione ha oramai un sistema automatico di risoluzione delle dipendenze, che evita di portarsi appresso mega e mega di librerie con ogni pacchetto), ma ammetto che molti limiti ancora esistano e che il meccanismo vada al di la' della mentalita' irrimediabilmente compromessa dell'utenza (inutile spiegare che per cercare ed installare qualcosa si deve aprire Synaptic, una forza oscura li spingera' sempre a cercare il setup.exe su Internet). Dunque perche' non provare ad unire il meglio dei due mondi, Mac e Linux? Un filesystem FUSE farebbe le veci della "apposita cartella" in cui copiare gli archivi prelevati in Rete, ed internamente dovrebbe provvedere ad analizzare i nuovi files ivi introdotti e trattarli nella maniera che piu' gli si confa': se possono essere gestito direttamente dal package manager della distribuzione si installano nel modo previsto, se sono pacchettizzati in qualche altro formato li si converte con alien, se sono archivi di sorgenti li si decomprime e si esegue il solito "./configure ; make ; sudo make install", il tutto tentando di fare del proprio meglio con la risoluzione e l'installazione delle dipendenze. PackageKit dovrebbe fornire un supporto decente per triangolare i nomi delle dipendenze, il resto... E' lasciato alla fantasia dell'implementatore.
• Versioning degli snippets. Una idea non mia, bensi' presa da qui e che, al di la' della fattibilita', ritengo ingegnosa: assegnare un identificativo ai frammenti di codice comunemente sparpagliati in Rete, in modo da saperli tracciare ed aggiornare qualora avvenga qualche miglioria o correzione. La realizzazione dell'impresa sarebbe quantomeno difficoltosa: occorrerebbe innanzitutto assegnare gli identificativi, e dunque o convincere le varie piattaforme di condivisione degli snippets a farlo o importare tutto il loro materiale su un'altro sito ad hoc che provveda alla trasformazione, e poi integrare metodi di sincronizzazione all'interno dei maggiori IDE, si' che siano in grado di provvedere da soli alla verifica di aggiornamenti, oppure realizzare un deamon dedicato che dato l'indice dei files sorgenti da sorvegliare implementi il ciclo di controllo in modo centralizzato. Forse utopico, ma lo lascio come spunto.

Per ora basta cosi', anche se non ho completamente svuotato la lista: qualche idea semplice semplice spero di realizzarla nel prossimo periodo, qualcun'altro la conservo per maggiori approfondimenti, qualcun'altra ancora e' correlata ad altri lavori ed attivita' dunque tocca a me occuparmene. Rinnovo comunque la speranza che quanto sopra listato possa ispirare qualcuno: si trovano opere molto complesse ed altre molto semplici, per l'implementazione di nuovi applicativi o per l'estensione di altri esistenti, insomma ce n'e' per tutti i gusti e tutte le capacita'.
Alla faccia dei brevetti...

Lobotomy Summer of Code

Per chi non lo avesse notato (ovvero immagino tutti i lettori di questo blog, divisi tra Facebook e l'RSS), nella casella dell'account Flickr su questa pagina hanno iniziato a spuntare alcuni screenshots, piu' precisamente uno al giorno negli ultimi quattro giorni. Essi sono per documentare lo stato dei lavori nella prima implementazione di Synapse, componente dell'assai piu' vasto progetto Lobotomy.
Dopo lungo, lunghissimo periodo di meditazione, nonche' di impegno su altri progetti e lavori, ho infine profittato di queste ferie estive per iniziare a mettere insieme un mezzo prototipo della baracca, per valutare la concretezza del modello di interazione previsto e misurarne l'efficacia. Proprio per questo motivo, nonche' per tenere la mano allenata con Java e PHP, e in rispetto a quanto gia' accennato in un lontano passato, e per facilitare eventuali sessioni di test pubblico (tenetevi pronti a farmi da beta-tester!), la prima implementazione e' realizzata con l'apporto del solito WebToolkit di Google, e Synapse non e' altro che una applicazione Javascript con un backend che rappresenta l'effettivo motore relazionale (anche se al momento tutti i dati sono malamente cablati a mano).
La prima cosa che salta all'occhio guardando gli screenshots e' che l'applicazione e' confinata entro un rettangolo anziche' estendersi su tutta la pagina renderizzata nel browser: ebbene, quel rettangolo e' di 480x640 pixel, ovvero la dimensione dello schermo del FreeRunner (volgarmente noto come "OpenMoko"). Questa e' infatti la prima piattaforma su cui intendo usare Lobotomy: una scelta certamente azzardata, in quanto porta una serie di problematiche tecniche (l'OpenMoko va smanettato non poco per apportare una modifica quale la sostituzione dell'intero ambiente grafico) e di interazione (lo schermo nelle dimensioni reali e' proprio piccolo, molte cose vanno divise obbligatoriamente su piu' pannelli), ma tanto vale porsi da subito nelle condizioni peggiori affinche' poi lo sviluppo su piattaforma PC (e non solo...) sia tutto in discesa.
Allo stato attuale una parte del parsing e della costruzione dinamica dei Thoughts e' completa, sebbene manchino alcuni tipi di dati elementari per i metadati (ad esempio non c'e' ancora modo di esprimere un array di valori), alcuni widgets basilari ci sono e come detto il backend e' un'unico ammasso di XML scritto a mano su cui puo' essere eseguito una query sola, quella per l'estrazione del file README che di default appare all'avvio. Comunque fino a questo punto non sono emersi particolari ostacoli alla realizzazione dell'idea, e gli unici problemi li ho riscontrati quando mi son messo a giocare con gli effetti da applicare ai vari elementi dell'interfaccia (il framework per le Animations in GWT e' sufficientemente ostico), ovvero su cose non concernenti il modello Lobotomy in se'.
Ulteriori aggiornamenti a seguire, certamente prima della fine delle ferie!

L'Arte della Pubblicita'

Negli ultimi giorni, navigando il web e piu' in particolare alcuni siti italiani, mi e' cascato l'occhio su certi banner cosi' interessanti che ho deciso di riportarne un commento qui sebbene il tema sia abbastanza fuori dal topic del blog.
Il prodotto pubblicizzato e' un registry cleaner per Windows, uno di quei classici programmini che devono essere usati per tentare di mettere una pezza in quell'enorme falla architetturale tipica dei sistemi operativi Microsoft che appunto e' il registro di sistema, ma la cura riposta nel confezionare tale capolavoro di marketing fa commuovere.
Cliccando sul banner si e' riportati su codesta pagina, in cui non si puo' fare a meno di constatare il grande risalto che viene dato ai concetti "velocizza il PC" e "elimina gli errori". Ebbene: chi ha un minimo di consapevolezza tecnica ed ha avuto a che fare con l'utenza informatica casalinga media, sa che questi sono i due termini in assoluto piu' usati da chi senza arte ne' parte detiene un computer in casa: "velocizzare" e "gli errori". Riferendosi a tali nozioni si e' sicuri di attirare l'attenzione e toccare la sensibilita' di una ampia fascia di rappresentanti della fascia consumer, soprattutto quelli rimasti delusi dall'amico smanettone di turno che non e' riuscito a risolvere il suo problema, che di norma e' riassumibile con "Ho il computer che va in errore, cosa devo fare?". Poco importa che l'indicazione "gli errori" si riferisca ad entita' totalmente aleatorie - se e' al plurale si suppone ce ne siano tanti, i quali si esprimono in maniera diversa e richiedono soluzioni diverse. Se non si esplicita di quale errore si parla, come si fa a risalire alla relativa sistemazione? -, o che il verbo "velocizzare" sia usato totalmente senza cognizione di causa essendo i PC moderni macchine da miliardi di operazioni al secondo e tanto dovrebbe bastare; il punto sta nell'adottare un lessico famigliare, non necessariamente corretto ne' tantomeno con un significato effettivo ma comprensibile, e far sapere all'utente che c'e' qualcuno di esperto che riesce perfettamente a comprendere il suo sentimento di frustrazione dinnanzi al complesso marchingegno elettronico e vuole aiutarlo.
Ma la perfezione psico/grafica della pagina linkata dai banner in oggetti non si limita all'intestazione colorata: scorrendo verso il basso la lunga e dettagliata descrizione il tenore dei contenuti varia con costanza geometrica, passando da "Scansione ultra-veloce e riparazione automatica" (definizione user-proof) a "Errori di Componenti ActiveX" (definizione da smanettoni), ottenendo il duplice risultato di accontentare l'ego del visitatore piu' smaliziato ed accorto (che poi lo voglio vedere un sedicente espero Windows che clicca su un banner "Velocizza il tuo PC"...) ed insieme fornire quella giusta quantita' di terminologia specifica indispensabile per dare una credibilita' all'insieme - se non usa un lessico tecnico, che tecnico e'?
Un'ultima chicca, solo per intenditori. Nel paragrafo "Testimonianze", l'ultimo della pagina, vengono riportati due commenti rilasciati da utilizzatori evidentemente molto soddisfatti del prodotto: un utente casalingo ed uno enterprise (certamente chiamato in causa per strizzare l'occhio a coloro che dovrebbero acquistare la versione "Pro" dell'applicazione). Guardateli bene, leggete i nomi e soprattutto la provenienza: ma poteva non essere che l'utente sfigato fosse un napoletano e l'imprenditore un brianzolo? Quali migliori testimonial potevano essere rintracciati (o inventati...) per promuovere il programma?
Ho sperato in un qualche tentativo di auto-rilevamento del sistema operativo in uso che cercasse di aiutarmi a scaricare la versione XP o Vista del programma, ma con scarso risultato; non mi resta che sperare che sul log sia rimasta traccia del tentativo di download da parte di una macchina Linux, e che cio' provochi un attimo di ilarita' per il povero admin dall'altra parte della barricata.
Un merito a Microsoft bisogna riconoscerlo: senza di lei e senza la sua lunga opera di lobotomizzazione delle masse digitali, noi informatici consapevoli non potremmo godere di tali perle.

TuxChan

Come sempre con l'approssimarsi delle vacanze estive, mentre amici e colleghi partono per trascorrere le ferie nei posti piu' disparati, io colgo l'occasione per sviluppare in santa pace un po' di software per conto mio. Sebbene dovrei lavorare su Lobotomy (ho finalmente iniziato la scrittura del parser di Synapse!), o dare qualche sistemata a GASdotto in vista della messa in opera prevista per settembre, o rifinire libopengdesktop ed aggiungere la pletora di funzionalita' ancora mancanti, in atmosfera vacanziera e di spensieratezza ho ben pensato di dedicare un pochino di tempo ad un ennesimo progettucolo: TuxChan.
La storia del perche' e percome sia arrivato a tale ispirazione la rimando ad un'altro post, per ora mi concentro sull'aspetto tecnico: esso e' un client desktop per 4chan, la popolare imageboard che dal 2003 convoglia il peggio del peggio del cazzeggio e da cui storicamente emergono alcuni dei piu' virali e devastanti meme.
In cosa consiste 4chan? In un sito estremamente brutto ed inutilizzabile in cui nei vari canali tematici si svolgono discussioni incentrate per lo piu' intorno alle immagini postate dagli utenti, ed in cui i contenuti vengono automaticamente cestinati via via che ne arrivano di nuovi. I materiali variano entro un range abbastanza vasto, non esistendo regole o comunque essendo moderatamente rispettate e non vigilate, il file rouge sembra essere il Giappone (Terra Promessa di molti geeks occidentali) ma nella stragrande maggioranza dei casi si tratta di fotografie divertenti (quantomeno secondo la cultura internettiana) oppure a sfondo sessuale.
A cosa serve 4chan? Assolutamente a nulla, se non a far perdere un po' di tempo ai giovanotti col pallino delle giapponeserie e senza nulla di piu' utile da fare che non stare a contemplare lo stream di immagini che freneticamente si susseguono sulle sue pagine.
E dunque, a cosa serve TuxChan? Agli utenti, ad avere una interfaccia un pochino piu' decorosa dell'originale e nella possibilita' di ricevere indirettamente i push sugli aggiornamenti senza stare a ricaricare manualmente la pagina web ogni due minuti (ed all'interno delle community che orbitano intorno a questo tipo di contenuti essere i primi a venire a conoscenza di qualcosa di nuovo e condividerlo con i pari gioca un ruolo sociale non secondario). A me, ad avere un pretesto per giocare finalmente un po' con Clutter.

Da tempo immemore cercavo un qualche applicativo che mi permettesse di mettere alla prova il toolkit, e non potevo scegliere momento migliore che non il recente rilascio della release stabile 1.0. E non mi sembra affatto male: nel giro di un paio di serate (in buona parte buttate appresso a GIO: non usate g_file_copy_async() !!!) e nello spazio di meno di 1000 righe di C (altro argomento su cui dovro' tornare prossimamente) ho ottenuto una interfaccia a parer mio soddisfacente, minimale e proprio per questo efficiente, con le immagini che scorrono ed un pannellino per configurare i channels da seguire. Per essere stabile e' stabile, e l'API pur essendo limitata permette di fare qualsiasi cosa, alla faccia di QtGraphicsView che ad ogni minor release cambia comportamento ed ha una interfaccia troppo complessa per essere fruibile rapidamente.
Come supponevo il paradigma che sta dietro a codesto strumento va un attimo compreso prima di essere utilizzato efficacemente: all'inizio si puo' restare spiazzati dinnanzi alla totale assenza di widgets complessi che implementino le varie modalita' di interazione con l'utente, ma una volta capacitatisi del fatto che qualsiasi cosa si disegni sullo schermo puo' essere spostato, ruotato, e fatto divenire un elemento che reagisce a degli eventi esterni, si comprende il segreto intrinseco del toolkit: permettere di fare di piu', con meno.
Potrei dilungarmi qui in merito ai rischi del non avere alcuna limitazione nella definizione della propria interfaccia, fatto che si presta ad essere preludio alla totale disgregazione della coerenza tra diverse applicazioni, ma per ora interrompo qui: ci sara' modo e maniera di tornare su questi argomenti quando il tutto sara' piu' radicalmente diffuso grazie all'apparente progressiva integrazione in GNOME, e ci si potra' basare su dati concreti anziche' su illazioni.
Maggiori news sulle mie avventure estive a seguire...