I Piccoli Aggiornamenti

Tra le attivita' che maggiormente reputo degne di essere completamente delegate alla macchina in modo da non tediare l'utente c'e' sicuramente l'aggiornamento del software installato. Ad oggi qualsiasi distribuzione Linux monta di default un package manager, che si occupa automaticamente di verificare la disponibilita' di nuovi pacchetti e risolve le dipendenze in fase di installazione ed aggiornamento, ma comunque la sua esecuzione dipende dalla volonta' e dall'attenzione dell'utente che o se ne dimentica o viene periodicamente disturbato da notifiche sul suo desktop.

Ad oggi, comunque, l'esecuzione schedulata e silenziosa di un "apt-get update; apt-get upgrade", magari per mezzo di cron, e' assai poco consigliata: troppo spesso accade che tale operazione venga lanciata nel bel mezzo di un update massivo sul repository di pacchetti di riferimento, e se non ci si prende la briga di leggere cosa viene richiesto di fare basta veramente troppo poco per trovarsi, in virtu' di qualche estroso conflitto nelle dipendenze, il desktop environment o qualche driver importante disinstallato.

Ma d'altro canto c'e' un intero universo di componenti software che non sono affatto gestiti (o comunque sono solo marginalmente trattati) dai package manager, e che produrrebbero un danno limitato anche qualora per disgrazia fossero gestiti male: i plugins.

Ogni applicazione evoluta oggi esistente mette a disposizione una ricca API con cui qualsiasi developer puo' aggiungere funzionalita', a volte modeste e a volte molto pesanti, e la tendenza a distribuire in questo modo lo sviluppo tra il maintainer del core principale e gli occasionali partecipanti e' in evidente crescita (forse anche dopo aver constatato l'enorme successo avuto dal concetto di "estensione" applicato al popolarissimo Firefox).

L'unico problema e' che raramente si trovano repository unici di estensioni e plugins destinati ad una specifica applicazione, ed occorre andarsele a cercare appositamente (assumendo ovviamente che se ne conosca l'esistenza). Il mio esempio preferito e' Inkscape: sul sito esiste una raffazzonata pagina dedicata ad indicizzare alcune estensioni esistenti, ma al fondo di essa si trovano tracce di un eventuale progetto strutturato e mirato a tale scopo che risalgono a maggio 2010.

D'improvviso, leggo oggi sul blog di Aaron Seigo il proposito di fornire una sorta di protocollo di auto-discovery per i DataEngines di Plasma (che, detto terra terra, sono delle estensioni di KDE). In sostanza il personaggio descrive uno scenario che io stesso medito da tempo: utilizzare qualcosa come il formato Open Collaboration Services (da me stesso implementato per Gnome) per comunicare ai clients degli utenti variazioni sullo stato dei componenti installati, ed ai fatti provvedere ad una sorta di package management isolato e dedicato ad una nicchia precisa. In un colpo solo si bypasserebbe il management ufficiale delle distribuzioni (che tendono ad essere in ritardo rispetto alle releases dei pacchetti veri e propri), si avrebbe un sistema di aggiornamento unico per tutte le piattaforme, e si estenderebbero le potenzialita' dell'amministrazione di sistema semi-programmatica anche ai frammenti di software sinora bistrattati ed esclusi dalle cure dei packagers.

Per quanto le mire di Seigo siano di molto basso profilo (appunto, limita la sua stessa idea all'aggiornamento dei DataEngines quando potrebbe essere applicato ad ogni genere di estensione), auspico che qualcuno lo stia a sentire e provveda a studiare una soluzione al problema, da poi riutilizzare in altri contesti.

Uno dei piu' grandi vantaggi di Linux rispetto alle altre piattaforme operative e' proprio l'elevato grado di maneggiabilita' dei pacchetti software installabili; tanto vale spremere il massimo da tale concetto, usarlo per dare risalto a sempre piu' opere e farne uno dei canali di penetrazione piu' aggressivi per il software libero.

Riuso Fai-da-Te

Una delle cose che piu' amo del software libero e' la possibilita' di utilizzare e riutilizzare all'infinito frammenti e porzioni di codice, magari anche in contesti diversi rispetto a quello entro cui sono stati scritti. Spesso e volentieri io stesso mi trovo a copiare e incollare funzioni o intere classi dall'Internet, pescando dai repository, e al "costo" di poche righe di commento destinate ad indicare il copyright dell'autore originale si ottiene in pochi secondi la funzionalita' desiderata.

Tale proprieta' non e' purtroppo sempre applicabile ai componenti software complessi.

In questo periodo mi sono trovato a dover elaborare una soluzione composta, in buona sostanza, da un captive portal, un pannello per la gestione delle utenze, ed una centralizzazione degli accounts su un unico server. Scopo del gioco: esibire i documenti per l'autorizzazione alla navigazione web (grazie, Pisanu) una volta sola, e poter poi accedere a tutti i locali all'interno del network convenzionato e geograficamente sparso usando sempre la stessa utenza.

Di captive portal opensource e' pieno il web. Nessuno di questi prevede una gestione avanzata degli accounts, i quali sono sempre e solo gestiti localmente. E, anche volendo dirottare le connessioni al database con qualche hack (pericoloso, in quanto comunque deve esistere un meccanismo di validazione dei routers periferici nei confronti del server centrale), non sarebbe comunque possibile personalizzare in modo agevole le anagrafiche trattate per fargli fare quel che mi serve (banalmente: associare gli accounts ai soci dei locali nel network, con tutto quel che ne consegue in termini di scadenze delle iscrizioni).

Dopo ardue ricerche incrociate, e valutazione di diversi blocchi di codice pescati qua e la', non son riuscito ad isolare i pezzi che mi servivano ed alla fine ho ceduto ed ho ben deciso di rifare tutto daccapo prendendo ispirazione qua e la'.

Purtroppo non si puo' porre un argine a questo problema, comune a pressoche' qualsiasi applicazione complessa. Isolare in modo chirurgico i componenti e' una best practise che esiste solo sui manuali accademici di ingegneria software, nel mondo reale non si puo' fare in quanto comunque alcuni presupposti (ad esempio: la gestione e la validazione degli utenti) devono essere validi a priori in tutto il sistema ed inevitabilmente vanno a cozzare contro i presupposti usati altrove.

Quel che piu' mi perplime comunque non e' l'utilizzo di componenti separate, quanto l'utilizzo di piu' componenti insieme. In questo periodo mi sto molto interessando alla questione della legge regionale piemontese per la promozione del software libero, e spesso scopro che alcune amministrazioni in giro per l'Italia e per l'Europa hanno gia' rilasciato questo o quest'altro frammento potenzialmente utile per altre amministrazioni, ma temo il giorno in cui esse dovranno essere messe insieme e proposte a mo' di pacchetto chiavi-in-mano a qualche istituzione: ciascuna e' stata scritta con un framework diverso, in un linguaggio diverso, con specifiche ed architetture diverse, e presenta una interfaccia diversa, organizzata in modo diverso. Mettere insieme tutti questi pezzi, che presi singolarmente sono assai utili ma comunque non determinanti, si annuncia come una missione impossibile, e gia' so che il giorno in cui si prendera' di petto la questione molti di essi dovranno essere in buona parte riscritti. I sogni di riusabilita' immediata e propagazione del software pubblico sono destinati ad infrangersi contro lo scoglio del pragmatismo.

Ancora oggi la riusabilita' e' un mito. Che urge sfatare, per sbloccare finalmente in modo completo l'immenso potenziale del software libero.

Zero Upgrade

Nel precedente post ho fatto menzione alle comodita' programmative dell'usare una rappresentazione "uno a uno" degli oggetti manipolati ad alto livello con lo schema del proprio database: poco codice che gestisce tutto quanto, logica abbastanza lineare e necessariamente coerente dunque comprensibile, grande flessibilita'...

Qui vorrei fare una rapida menzione ad un ulteriore vantaggio di questa strategia, che ho l'altro giorno implementato e perfezionato nel codice del mio gestionale per gruppi di acquisto: l'aggiornamento automatico e trasparente del database in caso di upgrade dell'applicazione.

Passando dalla release 1.0 alla release 2.0 mi sono posto il problema di rendere l'upgrade di GASdotto semplice, almeno tanto quanto lo e' l'installazione, ma ho sicuramente fatto le cose un po' di fretta e mi son ritrovato un garbuglio di "ALTER TABLE" che certamente non avrei potuto mantenere anche nella futura release 3.0 (dovendo peraltro gestire i casi di migrazione partendo da 1.0 o 2.0). Alche' mi sono ingegnato ed ho deciso di spremere meglio la mia mappatura degli oggetti sul database, implementando l'operazione inversa: costruire il database partendo dalle classi PHP.

La funzione che effettua davvero le query (resa unica in tutto il programma originariamente con l'intento di centralizzare la gestione degli errori) e' stata modificata in modo che, se una richiesta verso il database fallisce, prima di tentare una seconda volta verifica che tutte le tabelle siano al loro posto e che esse abbiano tutte le colonne che descrivono gli attributi dei miei oggetti PHP di alto livello. L'effetto collaterale di tale meccanismo e' ovvio: GASdotto non abbisogna piu' di una procedura esplicita di upgrade, basta decomprimere l'archivio compresso al posto del precedente (magari salvandosi prima il file di configurazione) e al primo login si arrangia da solo nel modificare il database allineandolo alla struttura richiesta con le nuove colonne e le nuove tabelle.

La procedura deve ancora essere testata con cura, ma i primi esperimenti sono stati soddisfacenti: trovandomi adesso ad attuare qualche correzione alla gestione delle notifiche mi trovo a dover aggiungere qualche attributo alla classe Notification, e laddove prima dovevo rimaneggiare la classe PHP, quella Java e lo schema del database, adesso metto mano solo al codice e la prima volta che ricarico l'applicazione nel browser la query fallisce, esegue il controllo, crea le nuove colonne richieste nelle tabelle e tira dritto.

Sebbene il tutto sia ancora migliorabile (manca la definizione dei valori con cui inizializzare le eventuali nuove porzioni di database) posso ritenermi soddisfatto di questa novita': ho eliminato un passaggio richiesto per l'amministrazione dell'applicazione da parte degli utenti (spianando peraltro la strada ad un futuro automatismo per l'aggiornamento trasparente, come quello gia' esistente nell'ottimo Wordpress), ed io ho ridotto la quantita' di cose di cui preoccuparmi durante lo sviluppo.

Regola 1: essere pigro, e far fare alla macchina quello che non si ha voglia di fare a mano.

Il Pallino del Database

Ogniqualvolta mi confronto con un qualche programmatore in merito ad una qualsiasi applicazione che deve gestire un po' di dati, pare che la prima (ed unica?) preoccupazione sia lo schema del database. Mi e' gia' capitato con numerosi personaggi, tra cui un SAPpista, un imprenditore ex-sviluppatore di gestionali, diversi developers freelance, insomma con chiunque abbia anche una vaga idea di come scrivere codice: quando si parla di un programma, la prima cosa che vogliono vedere e' il database.

Saro' un eretico, ma a me non pare che questo componente necessiti di tali particolari attenzioni.

Certamente dallo schema del database adottato dipende la scalabilita', la possibilita' di aggiungere funzionalita' complesse in futuro, ed in parte la performance del sistema completo, ma da quando ho adottato una nuova prospettiva nel processo di sviluppo di GASdotto ho smesso di preoccuparmi particolarmente della cosa.

Sostanzialmente, in GASdotto il database e' la rappresentazione "uno a uno" degli oggetti maneggiati dall'applicazione, e tutte le interazioni con questi oggetti sono formalizzate secondo una manciata di regole.

Ad esempio: l'oggetto "Order" e' un ordine aperto presso un fornitore. All'interno della classe sono iscritte le proprieta' che compongono tale elemento. Sul database, c'e' una tabella che si chiama "Orders" (tipicamente le tabelle si chiamano nello stesso modo della classe di riferimento, ma ho dovuto fare una eccezione poiche' "order" e' una parola chiave di SQL) che riporta esattamente quelle stesse proprieta'. Dove l'oggetto ha una stringa, sul database c'e' un varchar. Dove c'e' un numero, corrisponde un intero. Dov'e' c'e' un riferimento ad un oggetto descritto da un'altra tabella, vi si trova la chiave esterna a quella tabella. Nel caso particolare delle relazioni "uno a molti" (ad esempio: i prodotti contemplati all'interno dell'ordine), si utilizza sempre una tabella di appoggio che si chiama "nomedellaclasse_nomedellattributo" e due colonne, una per l'entita' di riferimento (l'ordine) e l'altra per i sottoelementi (i prodotti).

Lo schema non e' per nulla ponderato o meditato: ogni informazione che serve e' memorizzata secondo una forma definita a priori, senza soffermarsi mai sul caso specifico.

Durante l'implementazione del supporto alle "varianti" dei prodotti in GASdotto 2.0 ho constatato come questo approccio sia facilmente adattabile: alla fine dell'opera mi son ritrovato con numerose nuove tabelle, ma per quanto complessa sia la relazione tra prodotto, variante, prodotto ordinato, varianti ordinate, prodotti consegnati eccetera, in breve sono riuscito a cavarne una definizione sempre coerente e non eccessivamente arzigogolata.

Il vantaggio maggiore di tale strategia e' che, essendo tutto maneggiato con poche regole sempre valide, il codice necessario alla serializzazione, deserializzazione, e reperimento e salvataggio delle informazioni e' unico in tutti i casi. Il guscio piazzato intorno al database e' ridotto a poco piu' dei minimi termini, una unica classe ("FromServer". Nome assai poco fantasioso...) provvede alla stragrande maggioranza del lavoro. Cosa non da poco, in termini di mantenibilita'.

Sicuramente lo schema finale non e' il piu' ottimizzato che si possa pensare, e non dubito che si potrebbe fare molto di meglio in termini di performance e risorse occupate, ma in fin dei conti la differenza non si nota. L'istanza nota piu' grossa di GASdotto conta attualmente 600 diversi prodotti da 30 diversi fornitori, il dump completo (e compresso con l'opzione -Ft di pg_dump) di PostgreSQL e' di quasi 1 megabyte, eppure il tutto pare sufficientemente reattivo ai 170 utenti registrati (a parte quando la componente Javascript inizia a macinare tutti quei dati in un colpo solo nel browser, ma e' un altro discorso).

Insomma: personalmente, ho smesso di dare tanto peso a come e' fatto il database di backend delle applicazioni. Quantomeno delle mie. Qualche microsecondo di elaborazione in piu' val bene tutta questa flessibilita' compressa in una cosi' modesta quantita' di codice.

Maintainr

Croce e delizia di ogni developer fancazzista, quale sono ad esempio io, sono gli occasionali progettucci in cui sin troppo spesso ci si va ad infognare, in gergo detti "pet projects". Questi ci permettono di passare qualche pomeriggio smanettando su qualcosa di inedito, talvolta fungono da pretesto per metter mano ad una nuova libreria o ad un nuovo concetto appena appreso, e comunemente inducono quella piacevole attivita' cerebrale creativa spontanea che tanto piace alle gioconde menti dei programmatori. Quando si inizia una nuova impresa, parallelamente si iniziano ad innalzare architetture software estrose ed arzigogolate per il puro gusto di contemplare l'infinito, ed intanto si immagina il giorno in cui il nostro programmuccio girera' su tutti i PC del pianeta con schiere di utenti felici e riconoscenti del nostro operato.
Ma la realta' dei fatti e' ben diversa: nella stragrande maggioranza dei casi il progetto parte a razzo e si scrivono cento, duecento, mille righe di codice in pochi giorni, si ottiene una funzionalita' che vagamente somiglia a quello che avevamo in mente in principio, dopodiche' l'attenzione viene sottratta da qualche nuova idea o da una urgenza personale o professionale, oppure l'entusiasmo scema per un decadimento nella fiducia nella vision originaria o tentando di far fronte alle noiose sessioni di debugging che inevitabilmente accompagnano ogni cviclo di sviluppo. A quel punto, il progettuccio resta nella migliore delle ipotesi un repository abbandonato sul web (tanto quanto, qualcuno potra' prima o poi trovarlo e far qualcosa con quel codice, fosse anche solo prenderlo come spunto), nella peggiore viene totalmente perso.
Di mio, ho portato all'esasperazione questa malsana (ma neanche poi tanto...) pratica: avendo una discreta quantita' di tempo libero ho avviato un numero impossibile di piccoli e grandi lavori, dei genere piu' disparati, con ogni grado di pretenziosita', e che si trovano ad oggi ad eterogenei livelli di sviluppo. E per arrestare l'inarrestabile fenomeno dell'abbandono a strascico, ho ben pensato di... avviare un nuovo progetto.
Maintainr si tratta di una applicazioncina molto stupida, il cui scopo e' quello di gestire in un posto solo tutti gli appunti e gli aspetti di promozione del proprio sforzo operativo. Ogni idea ha una sua propria todolist, un proprio pannellino con cui inviare notifiche su identi.ca, e nel prossimo futuro qualche opzione per interfacciarsi con gtk-apps.org ed esporre il proprio software ed i relativi aggiornamenti presso una community decentemente vasta.
Tra tutte, la funzione che preferisco e che ho preteso sin dall'inizio e' lo scheduling semi-automatico: pigiando un tastino posto in alto nella finestra l'ordine dei progetti della lista cambia, spostando in cima il piu' consigliato secondo una banalissima euristica basata sulle priorita' assegnabili ad ognuno di essi, al fine di ciclare periodicamente e dedicare a tutti un poco del proprio tempo per non lasciarne nessuno indietro. Per quanto apparentemente sciocca, quest'ultima funzione e' piu' utile di quanto si possa immaginare: come da me gia' sperimentato (usando Zim, programma il cui impiego mi ha ispirato Maintainr) il fatto di far decantare periodicamente il proprio codice, magari quando pare di essere giunti ad un punto morto o si sbatte la testa per piu' tempo di quanto tollerabile su un bug enigmatico, permette di tornarci poi con maggiore ardore in un momento successivo, in quanto nel mezzo c'e' stato un periodo di "riposo" (ad esempio l'impegno su qualche altro componente piu' soddisfacente) e nel frattempo abbiamo inconsciamente gia' analizzato e risolto la situazione. Questo aiuta a non perdere il coinvolgimento nei confronti di un particolare opera, e dunque di perseguire l'obiettivo per un periodo piu' lungo (sebbene intervallato da altro).
La disponibilita' di strumenti "social" all'interno dell'applicazione mette in luce l'aspetto propagandistico della stessa: per far vivere e prosperare un progetto e' necessario avere un pubblico, anche solo per auspicare di ricevere quel feedback sintomo di interesse degli altri che e' vitale per mantenere viva la passione del developer, e tanto vale sfruttare a proprio vantaggio gli infiniti canali di condivisione messi a disposizione oggigiorno dal "Web 2.0". Dato un modesto sforzo iniziale (registrare appunto il progetto su gtk-apps.org, un account dedicato su identi.ca, un alert Google, e nel futuro magari una pagina Facebook e quant'altro), scopo di Maintainr e' riuscire a tenere aggiornato il resto del mondo sugli sviluppi interni dedicando il minimo tempo possibile a tale occupazione.
Una estremamente limitata release 0.1 e' stata rilasciata l'altro giorno, e si tratta piu' che altro di un primo abbozzo ampiamente migliorabile. Ad ogni modo io stesso ho iniziato ad usare l'applicazione (che di fatto ho costruito basandomi sulle mie proprie necessita'), e sebbene il periodo di prova sia ad ora troppo bene confermo di trovarmici meglio che non con un tool general purpose per gli appunti. Ma ovviamente io sono di parte.
Vediamo se con uno strumento tagliato su misura mi aiuta ad essere un miglior maintainer...

Autocompletamento poco "Auto"

In GTK, cosiccome suppongo in ogni altro toolkit grafico sia desktop che web, si trova GtkEntryCompletion, comoda utility per gestire l'autocompletamento delle caselle di testo. Si popola una struttura dati con gli elementi validi (pescandoli da una history, da un database o quel che e'), e quando l'utente inizia a scrivere qualcosa che combacia almeno parzialmente con uno o piu' di suddetti elementi appare la casellina a tendina da cui si puo' selezionare il testo gia' completato. Il comportamento classico della barra degli indirizzi di un browser, insomma.
Finche' ci si accontenta di far semplicemente selezionare una voce e basta va (quasi) tutto bene, un po' piu' complicato e' far triggerare dall'atto della selezione una qualche azione (nel caso specifico che mi sono trovato ad affrontare: popolare un form con i dettagli relativi al nome scelto). In quanto il widget non copre molti casi d'uso che classicamente si osservano con utenti reali.
Stando a quanto ho visto nella mia esperienza, non sono cosi' tante le persone che sfruttano davvero l'autocompletamento; la situazione classica e' appunto la barra del browser, che sicuramente e' il caso piu' facilmente osservabile in natura. Non conto piu' le volte in cui ho visto utenti scrivere per intero i loro URL, ignorando completamente la casella di selezione del completamento oppure, peggio ancora, vedendola ed usandola come riferimento per copiare a mano la stringa intera. Vuoi per ignoranza sul meccanismo inteso per la corretta fruizione di questo componente grafico, vuoi perche' molti scrivono guardando la tastiera e dunque magari non notano cosa viene proposto sul monitor, vuoi per una qualche abitudine vestigiale a non farsi aiutare dal PC, vuoi per anacronistiche velleita' amanuensi, sperare di triggerare una selezione solo ed esclusivamente con la procedura prevista (inserimento del testo, individuazione della voce completata, attivazione per mezzo di click o di selezione con le freccette direzionali e del tasto Return) e' sintomo di eccessivo ottimismo.
In questo contesto, almeno due situazioni possono capitare:

• l'utente fa quello che ci si aspetta che faccia
• l'utente scrive a mano la voce gia' completata, ignorando il completamento automatico, e pigia Return (universalmente inteso come "terminatore di input"), oppure Tab, oppure cliccando da qualche altra parte alla fine
  

Per provvedere a gestire in modo decoroso il secondo caso, occorre veramente fare i salti mortali: registrare delle callback sugli eventi di focus-out e key-press (quest'ultimo per intercettare il Return), in cui compiere a mano la ricerca del testo immesso nella casella di testo nella struttura dati che contiene i valori buoni, e se opportuno comportarsi come se l'autocompletamento fosse stato attivato come voluto. Spiegarlo a parole e' molto piu' semplice che non implementarlo davvero.
Se cosi' non si facesse, il rischio sarebbe quello di avere un nome perfettamente valido nella casella di testo ma non tutti gli altri buoni altrove. Con le conseguenze piu' nefaste: l'utente riprova piu' volte a riscrivere la stringa, non comprendendo cosa ha fatto di diverso rispetto alle spiegazioni ricevute che mostravano la comodissima e sfavillante attivazione di tutto il resto, oppure l'utente compila a mano i campi che avrebbero dovuto essere riempiti autonomamente, distruggendo la sequenza logica prevista. Nel mio caso: se il form viene popolato quando nessuna voce valida e' selezionata, viene creata una nuova entry nel database; fare un controllo postumo sull'univocita' del nome introdotto sarebbe abbastanza controproducente e frustrante per il povero tapino che nel frattempo si e' riscritto tutto quanto a manina, andando a reperirlo chissa' dove.
Abitudini e limitazioni dell'utenza sono un grande, grandissimo grattacapo, cui purtroppo ci si deve confrontare nel momento in cui si voglia realizzare una interfaccia usabile senza eccessivo sforzo dalla maggior parte delle persone. Una perdita di tempo di due ore da parte mia, che ho dovuto individuare e risolvere il problema dell'attivazione dell'autocompletamento con metodi del resto opinabili, consegue ad un piccolo risparmio di patemi moltiplicato per il numero di tutti i futuri utilizzatori del programma.

Pennello alla Mano

Lo confesso, anche se chi mi conosce come programmatore gia' lo sa: io rientro in quella (nutrita) categoria di developers che dedicano pochissimo tempo alla progettazione ed ogni volta che iniziano un nuovo software o ne modificano un'altro pesantemente aprono l'editor di testo ancor prima di avere ben chiaro cosa fare. L'unico passo intermedio tra la decisione di fare qualcosa ed iniziare a farla sta nella scelta del nome: ogni progetto che si rispetti deve avere un nome!
So perfettamente che si tratta di una pratica malsana, e piu' e piu' volte ne ho pagato le conseguenze, ma d'altro canto sono convinto che l'eccessivo grado di "ingegnerizzazione" oggi in uso nel mondo dello sviluppo sia ugualmente dannoso: una dettagliata pianificazione trasmette un senso di eccessiva sicurezza, e quando le cose sono troppo ben incastrate tra loro si rischia di non avere spazio sufficiente per aggiungere quelle correzioni e quelle modifiche che, nel mondo reale, accadono sempre e comunque in qualsiasi circostanza.
Detto cio', nell'ultimo periodo ho iniziato quantomeno a progettare le interfacce delle mie applicazioni. Direi che e' gia' un passo avanti.
Ho sempre considerato il wireframing alla stregua di qualsiasi altra forma di progettazione, ma mi sono dovuto ricredere: laddove una architettura software e' oggettivamente qualcosa di completamente fumoso e dunque imperfetto finche' non la si traspone in qualcosa in esecuzione sullo stack (per poi immancabilmente fallire perche' non era stata presa in considerazione una data situazione), una interfaccia grafica e' qualcosa di concreto, in quanto anche se cliccando sul tasto non succede nulla il tasto e' comunque li' invece di essere da un'altra parte, occupa un determinato spazio e riporta una data etichetta o icona invece che un'altra.
Il primo esperimento quasi serio l'ho fatto usando MockFlow, strumento online (in Flash) per mettere insieme mockups di pagine destinate al web: la versione gratuita ha una limitazione sul numero di progetti e pagine che si possono creare, ma poiche' quelle poche pagine hanno altezza infinita si possono aggregare insieme piu' contenuti e con un poco di pazienza il paletto viene facilmente aggirato. Il secondo tentativo, rivolto ad un programma desktop (di cui scrivero' dettagliatamente in un'altra occasione), l'ho fatto con Gazpacho: progetto ad oggi leggermente defunto, nel concetto simile a Glade (che dovro' a sua volta provare, essendo pure aggiornato alle ultime evoluzioni di GTK+), funge da editor completo "a la Visual Studio" ma essendo io un programmatore vecchio stile lo ho usato solo per farmi una idea di dove posizionare i widgets che sono andato poi ad implementare a mano.
Entrambe le esperienze si sono rivelate inaspettatamente produttive: disegnare la propria interfaccia prima di riportarla sul codice permette di avere subito una idea di cosa ci si trovera' dinnanzi e, meglio ancora, di cosa ci si vorrebbe trovare; vengono subito identificate e corrette falle estetiche e funzionali nel design, si possono sopprimere o ridefinire aggregati di elementi che nella realta' appaiono molto peggio di quanto ci si era immaginati, e ci si capacita in fretta se nel concetto originale e puramente astratto mancava un qualche dettaglio che, ai fatti, sarebbe determinante ed indispensabile. Tutto questo con un costo estremamente basso, in quanto in un paio d'ore di cliccate si ottengono risultati piu' che sufficienti per condurre una valutazione ed eventualmente ridefinire la proprio linea: tutto tempo che altrimenti verrebbe riccamente sprecato per implementare, compilare, eseguire, cancellare e re-implementare.
Gli strumenti per prototipare e costruire bozze realistiche non mancano, anzi ce n'e' una abbondanza, e val proprio la pena almeno di provarli.

Progress Box

Mentre stavo mettendo insieme una interfaccia grafica per l'editor di feeds in Tracker (attualmente nel repository SVN di Phidias, sebbene ancora non completo) mi si e' presentato il problema di fornire all'utente del feedback durante la fase di download di un ipotetico file OPML da parsare e da cui importare gli indirizzi di interesse: assunto che dal momento in cui si clicca il pulsante per scaricare a quello in cui si mostra la lista di feeds identificati passa del tempo e si compiono una serie di operazioni (connettiti al server, tira giu' qualche kilobyte, leggi l'XML...), cosa visualizzare sullo schermo per informare del fatto che il primo click e' andato a buon fine e il programma sta facendo quel che deve fare?
Una classica progress bar ben si presta alla bisogna, ma il problema rimane: dove piazzarla? Creare una finestrella informativa separata sembra uno spreco, in quanto e' piu' il tempo che ci mette il window manager a gestirla che non quello per completare il task. Le status bar non mi sono mai piaciute, in quanto le considero troppo fuori dal locus dell'utente. Dedicare un'altra qualsiasi area a questo genere di informazione e' uno scempio.
Alche', mi sono "inventato" la ProgressBox.
Questa non e' null'altro che un semplicissimo (e per ora estremamente grezzo) widget GTK+ che incorpora un contenitore orizzontale liberamente riempibile ed una progress bar, mostrati alternativamente a seconda del bisogno. Nel caso specifico dell'editor di feeds: nel contenitore metto il campo ove incollare l'URL del file da scaricare ed il tasto per avviare la procedura, e quando esso viene cliccato il widget mostra la barra di progresso aggiornata in base allo stato del download. Una volta completata la trafila, il widget torna allo stato originale permettendo di incollare un eventuale nuovo indirizzo web.
Grazie a questo modestissimo espediente, si ottengono i seguenti risultati:

• l'utente e' informato del fatto che il programma ha colto il suo input
  
• l'utente e' informato del fatto che il programma sta lavorando
• l'utente sa quanto tempo ci sta mettendo
• si evita la classica situazione in cui, a causa dell'assenza di feedback, l'utente clicca dieci volte sullo stesso pulsante avviando dieci volte la stessa procedura
• l'utente, anche volendo, non puo' interferire con l'operazione schedulandone un'altra uguale prima che la prima sia completata

Come detto l'elemento e' estremamente rozzo ed ha un'API tutta sua (non avevo voglia estendere correttamente quella originale di GtkBox), ma per intanto l'ho reso disponibile come al solito su BarberaWare e ho preparato un video dimostrativo (che "fa figo e non impegna").

Paura e Delirio nel Pannello Configurazioni

Manco il tempo di finire di elogiare l'ottimo Déjà-Dup, che oggi mi son trovato a dover domare l'intricato (e talvolta inestricabile) Evolution. Prova provata della diffusa isteria compulsiva di aggiungere funzioni su funzioni laddove non ce ne sarebbe il benche' minimo bisogno, quasi solo per giustificare l'avanzamento del numero di versione.
Per qualche tempo ho fatto a meno di un client di posta per via di una riorganizzazione dei miei PC ed ho usato solo l'interfaccia web di GMail, che pero' reputo difficile da maneggiare dal momento in cui seguo moltissime mailing lists e senza la vista per thread e' pressoche' impossibile capirci qualcosa. Alche' ho installato su questo PC il summenzionato programma (prima lo usavo solo su un'altro computer), e l'ho dovuto configurare.
Devo ammettere che prima non avevo mai fatto caso alla quantita' di opzioni, sotto-opzioni, caselline, features e settaggi da gestire nel pannello di configurazione: forse perche' e' passato molto tempo dall'ultima volta che ho dovuto metterci mano (avendolo sistemato sull'altro PC non mi son mai piu' posto il problema), forse perche' sclerando alla ricerca della configurazione per la signature me lo son girato in lungo ed in largo scoprendo cose che prima non avevo visto (per la cronaca: alla fine ho dovuto cercare su Google come si imposta la firma al fondo delle mail, e ho scoperto di non essere l'unico a non esserne stato capace), forse perche' inconsciamente ispirato dalla recente analisi appunto di Déjà-Dup sono stato incline a prestare maggiore attenzione alla disposizione ed alla disponibilita' di scelte da far fare all'utente... Sta di fatto che sono attualmente molto deluso da come il programma si presenta.
Tanto per dirne qualcuna:

• in "Mail Preferences / General" si trova una checkbox che dice "Enable Magic Spacebar". E' ignoto cosa sia questa spacebar magica, di default e' abilitata e ho paura di cambiarlo per vedere cosa succede
  
• in "Composer Preferences / General" c'e' una opzione espressamente dedicata a chi ha la pessima abitudine di fare top quoting, permettendo di piazzare la signature sopra al testo quotato insieme al resto. Ed e' pure specificato "Not Reccomended". A che diamine serve una opzione che incentiva e spalleggia un comportamento biasimato da chiunque e pure esplicitamente deprecato nel pannello stesso?
• in "Mail Preferences / Automatic Contacts", che peraltro dovrebbe stare nell'apposita sezione "Contacts" anziche' li', si chiede se si vogliono importare in rubrica i contatti da Pidgin. Ora: per quale assurdo motivo al mondo io, utente, *non* dovrei volere l'integrazione tra queste due applicazioni? Fallo e basta!

La lista di cose palesemente inutili e di quelle che potrebbero essere largamente migliorate e' lunga, ed intendo nel prossimo futuro inviare una mail sulla mailing list dei developer per discutere le mie osservazioni ed eventualmente anche offrirmi per provvedere alle patch necessarie (sul codice di Evolution ho gia' combinato qualcosina in passato), perche' e' intollerabile che una applicazione del genere, una delle piu' importanti nella piattaforma Gnome e riccamente usata in ambienti di produzione (anche perche' sembra essere l'unico client open che si interfaccia in un qualche modo con Microsoft Exchange) debba essere cosi' complicata anche solo da mettere all'opera.
E' uno sporco lavoro, ma qualcuno lo dovra' pur fare...

Building Blocks

Stufo di dover sempre ripopolare la mia installazione di Tracker ogni volta che per ragioni di debug la svuoto, e di dover andare a caricarmi qualche FeedChannel per testare miner-rss, ho incluso oggi in libgrss un parser OPML (prelevandolo come al solito da Liferea) e scritto due righe in croce per provvedere all'importazione dei files formattati in tal modo nello storage semantico. Il codice e' al momento pubblicato qui, alla meno peggio, ma penso che ne realizzero' una versione grafica in GTK+ da distribuire insieme a Phidias.
Attenzione, pero': "da distribuire insieme", non "incluso in".
La differenza sta nel fatto che questa micro-applicazione, se mantenuta come componente standalone, fungerebbe come importer OPML per qualsiasi feed reader basato su Tracker passato presente e futuro. Appunto perche' Tracker fornisce una rappresentazione univesale descritta dalle sue ontologie, cui tutti i programmi capaci di gestire MFO attingerebbero in modo trasparente.
Da innumerevoli anni sono sostenitore di una architettura di sistema basata su componenti specifici e mirati che possano integrarsi tra loro in modo naturale, dove qualsiasi miglioramento o nuova feature si ripercuota su tutte le applicazioni che rientrano appunto nella stessa architettura senza dover necessariamente ritoccarle tutte. Lobotomy, e piu' precisamente il SubConsciousDaemon, e' stato progettato esattamente secondo questo criterio. Ed ammetto che, nonostante i difetti propri della fuffa semantica, Tracker si presti a questo genere di utilizzo.
Per ora continuo la mia opera nella nicchia della gestione dei feeds RSS, aggiungendo qua e la' funzionalita' (o meglio: riadattando le funzionalita' esistenti), ma spero che il concetto di sistema "composito" possa essere apprezzato da qualcun'altro e applicato in altri contesti.

La Sindrome della Prima Volta

Quando l'altro giorno l'amico Gigi ha pubblicato un post menzionando, tra gli altri, il progetto GASdotto, mi sono posto il problema della visilita' di tale opera sull'Internet. Ed il pensiero si e' acuito quando l'altro giorno ho ricevuto una mail da parte di un certo "Alessandro" del GAS di Rimini, che ha spontaneamente aggiunto una menzione al programma nella pagina Wikipedia dedicata al tema e mi chiede informazioni per una piu' approfondita valutazione.
Sinora ho tentennato, in quanto il software e' in perenne stato di sviluppo e sebbene possa essere dichiarato stabile nuove correzioni ed aggiunte arrivano quasi ogni settimana, ma credo che sarebbe ora di iniziare a promuovere sul campo l'applicazione affinche' venga conosciuta ed eventualmente usata dal pubblico di riferimento, ovvero i Gruppi di Acquisto.
In realta' questa voglia di referenzialita' non deriva dal puro e semplice desiderio di veder usato il proprio software, comune a qualsiasi programmatore che produca qualcosa che si spera essere utile al prossimo, ma per il mio timore nei confronti di quella mai documentata ma ben nota tendenza ad estendere le delusioni personali a tutto cio' che anche solo vagamente concerne la sorgente stessa dell'originale malcontento.

Spiego meglio il concetto, facendo un passo indietro e riesaminando la storia vissuta.
Lo sviluppo di GASdotto e' stato avviato oramai piu' di un anno fa' a fronte della constatazione che l'unica alternativa allora esistente era un obrobrioso ed inusabile programma denominato GestiGAS, open e gratuito ma impossibile da usare ed inguardabile. Poiche' la prima preoccupazione dei miei "committenti", il GAS Roccafranca di Torino, era appunto la prospettiva di riuscire a far usare uno strumento tecnologicamente piu' avanzato dei documenti Excel sino a quel momento scambiati per posta elettronica senza pero' restare impantanati nella naturale e diffusa incompetenza informatica dei membri del gruppo, l'unica scelta e' stata quella di implementare tra noi quanto bastava per svolgere i compiti della combriccola. Da allora numerosi e consistenti progressi sono stati fatti, in termini di stabilita' e funzionalita' offerte, e da piu' di un testimone mi e' arrivata la conferma che tale gestionale sia immensamente piu' facile da usare del sopra menzionato "competitor".
Cio' non basta comunque a vincere l'impietoso gioco del pagerank Google, e se oggi eseguo una query come "software gruppo di acquisto" sul piu' usato dei search engine inevitabilmente tutti o quasi i risultati riconducono a GestiGAS, presente da molto piu' tempo e dunque con una ben piu' ricca e diffusa schiera di utilizzatori e commentatori. Posso immaginare che questa specifica ricerca sia gia' stata condotta da buona parte dei numerosissimi gruppi di acquisto che, stando ad un recente rapporto di Coldiretti, sono spuntati nell'italica penisola, e posso immaginare che molti di questi abbiano scaricato, installato e provato ad usare questo arnese con risultati non sempre positivi.
E veniamo finalmente al perche' di questo post, alla "sindrome della prima volta": arrivati a questo punto, di tutti coloro che hanno visto GestiGAS e ne sono rimasti delusi, quanti vorranno intraprendere una piu' accurata ricerca e tentare nuovamente di procedere alla non sempre banale operazione di installazione di un applicativo web sui loro server per vedere se c'e' qualcosa di meglio? E quanti invece saranno sconsolati ed adotteranno a loro volta l'antidiluviano meccanismo degli ordini via mail, certamente piu' immediato da mettere in opera ma perdendo cosi' l'opportunita' di snellire i processi del gruppo e migliorarne l'efficienza con guadagno di tutti?
Il fatto di aver fallito il primo approccio comporta una perdita di entusiasmo, la paura di vedere un'altra volta vani i propri sforzi, ed in questo come in altri casi il fatto di incappare in una soluzione sub-ottimale fa poco sperare di riuscire a trovarne una valida. Pertanto si preferisce lasciar perdere, ed arrangiarsi con il minimo dispendio di risorse possibile.

Ho gia' osservato lo stesso circolo vizioso di riduzione dello stimolo tecnologico in un ambito assai diverso ma conosciuto da molti miei lettori: l'adozione di Linux. Penso che qualunque utente Linux con sufficiente passione da aver mai parlato di tale sistema ad un amico o conoscente con l'obiettivo di generare interesse abbia ricevuto almeno una volta una risposta del tipo "L'ho gia' provato X anni fa', non funzionava niente, ci ho rinunciato". Non ha la benche' minima importanza il fatto che il software incluso nelle distribuzioni migliori ogni singolo anno (o anche ogni sei mesi), e fra tutte le piattaforme operative Linux abbia il piu' forte afflusso di correzioni e miglioramenti: e' gia' stato provato, e l'impegno di eseguire una nuova installazione (con tutto cio' che ne consegue: ripartizionare, defraggare la partizione Windows per evitare ogni rischio di perdersi dati, verificare il funzionamento dei drivers...) non controbilancia l'esperienza negativa passata.

Per quanto riguarda GASdotto, dietro consiglio della mia ragazza (che lavora per una agenzia di SEO) ho installato sul sito un modulo Drupal per arricchire le pagine con meta-tags descrittivi e strizzare l'occhio al crawler di Google, sebbene ritenga quella del "Search Engine Optimization" una arte voodoo che trascenda la logica e non sia eccessivamente speranzoso nei confronti di questa misura. Parallelamente, vedro' di confezionare la prossima release 1.1 nel piu' breve tempo possibile e metterla a disposizione di chi la vorra' scaricare, ed ancora meglio mi piacerebbe avviare nel prossimo futuro una sorta di campagna di "server sharing" per i GAS che non hanno competenze per mettere in opera un virtual private server ma che vogliano comunque usare codesto software.

Con tutto questo non voglio asserire che GASdotto sia a priori meglio di GestiGAS, e che dunque il fatto di scoprire per primo il mio progetto possa stravolgere l'opinione delle masse, ma il fatto di aver gia' ricevuto un discreto numero di giudizi comparativi volti a mio favore mi fa intuire che qualche risultato in piu' lo si possa ottenere. Per fornire strumenti efficienti a chi ha obiettivi importanti, per dare un supporto tecnologico ad una impresa comune.
La prima volta non si scorda mai. Meglio che sia positiva.

Uno Scalpello per l'Informazione

A me piacciono un sacco i feeds: ogni giorno dedico parecchio tempo alla loro consultazione, per essere sempre informato di ogni novita' entro il piu' breve tempo possibile, e ne seguo relativamente pochi appunto perche' altrimenti non farei null'altro. Il mio feed reader ha sostituito la TV (poiche' l'unica cosa che guardavo erano i telegiornali, e questi risultano non solo sempre tremendamente in ritardo e schierati ma nell'ultimo periodo ho pure notato che Studio Aperto ha fatto scuola...), occupa quasi tutti i momenti di transizione in cui non scrivo codice o mail o post sul blog, mi porta continue ispirazioni per nuovi progetti o spunti di riflessione. Sono arrivato al punto di riportare in forma di RSS anche le mailing list.

Ma non ne ho mai abbastanza: per l'uso che ne faccio io, qualunque applicazione di tal genere risulta sempre limitata e limitante. Le shortcut da tastiera sono sempre poco efficienti, l'area per leggere il contenuto degli item e' sempre troppo ristretta, ad uno manca una filter bar per eseguire ricerche veloci, l'altro non permette di nascondere i feeds che non contengono nuovi articoli (feature indispensabile se si hanno piu' di una trentina di sottoscrizioni), e alla fine il layout e' sempre lo stesso (lista sopra, contenuti sotto) impedendo di assortire i contenuti in altre maniere piu' produttive e mirate.

Per questo motivo nella mia spropositata lista di todo c'e' da diversi anni l'implementazione di un feed reader fatto a modo mio. E questa potrebbe essere la volta buona che lo realizzi davvero.

Recentemente, per interesse e sfida, ho messo insieme col supporto di Netvandal un miner per Tracker che popoli il database locale con i feeds online: ogni tot tempo scarica dai vari URL memorizzati, parsa l'XML, e carica gli items nuovi. Insomma, funge da backend.

Nel thread in cui annunciavo al team Tracker la release 0.3 del componente (che ha anche riscosso un discreto successo, tale da essere considerato per l'inclusione nel repository mainstream del progetto), e' saltato fuori il mio proposito di provvedere ad un frontend. Qualcuno se ne e' interessato, mi sono un po' allargato con le dichiarazioni, ed adesso qualcuno si aspetta che io lo faccia davvero. Posso mica deludere i colleghi developers, no?

Ora come ora sto specificando l'architettura interna del programma, ma so per certo che dovra' avere almeno una feature: la visualizzazione degli items plugginizzabile. Data una API con cui indicare quali elementi mostrare e nascondere (in funzione dei nuovi feeds scaricati, e/o della filter bar), il plugin fara' quel che deve. E dunque potra' esserci la solita vista "lista sopra, contenuti sotto", ma anche quello che piazza su una mappa gli elementi marcati con GeoRSS, quello che traccia una tagcloud per i termini usati, quello che visualizza in blocchi proporzionali i posts provenienti dai singoli autori, o quello che permette di scorrere una timeline...

Lo scopo e' quello di visualizzare le news secondo vari criteri, si' da aiutare con la rappresentazione grafica l'individuazione di trends e soggetti interessanti, nonche' di nessi logici non immediatamente palesi tra piu' dati. Detto prosaicamente: scolpire l'informazione. Non per caso il nome del progetto e' Phidias, traslitterazione inglese di quello che nella traslitterazione italiana e' Fidia, scultore greco dell'antichita' con un nome incidentamente assonante alla parola "feed".

Non nascondo che il fulcro dell'iniziativa derivi dal desiderio di riportare in un software reale alcuni concetti nati e raffinati nel contesto del Lobotomy Project. In tale ambito ho iniziato ad elucubrare sull'applicazione di diversi "templates" ad oggetti informativi flessibili, in questo caso i detti plugins e i soggetti RDF prelevati da Tracker, e sebbene questa ne sarebbe una versione assai limitata e vincolata ad un ben preciso utilizzo determina comunque un primo esperimento concreto in tal senso.

Spero di riuscire a produrre un prototipo entro breve tempo: certamente non faro' in tempo per il FOSDEM (cui partecipero', e terro' anche un quarto di talk! Pubblichero' un dettagliato report, qui o sull'altro mio blog) ma qualcosina vedro' di mettere insieme negli oramai sempre piu' centellinati ritagli di tempo.

Stay tuned!

127.0.0.1 sweet 127.0.0.1

Chiunque abbia mai provato a scrivere anche il piu' semplice programmino in C che faccia uso di socket ha una vaga idea di quanto l'API BSD sia delirante: ci sono quintalate di funzioni destinate ai vari scopi, talvolta sembra ce ne sia pure piu' di una per far la stessa cosa, ed i parametri sono passati per mezzo di struct brutalmente castate l'una con l'altra e di cui sconsiglio l'analisi nei relativi header files.
Finche' si fanno cose semplici (apri la connessione TCP, manda il pacchetto UDP e cose cosi') per fortuna esistono fior di tutorial sparsi sull'Internet. Se si vuol fare qualcosa di un pochino piu' complesso (tipo: parlare con uno STUN server) spesso la documentazione non basta e gia' si deve iniziare a cercare con Google Codesearch o all'interno del codice di programmi che a priori si sa fanno quel che serve. Se poi si aspira a realizzare qualcosa che ancora non e' stato fatto da nessuno, e dunque mancano gli esempi da cui prendere ispirazione, la situazione diventa tragica.
Nel mio caso specifico sto realizzando una implementazione di client PubSubHub da includere in libgrss, libreria GObject per la manipolazione dei feeds di cui probabilmente parlero' su questo blog in futuro e destinata a colmare un vuoto ad oggi inammissibile, per ricevere attivamente le notifiche di nuovi contenuti esposti sull'Internet anziche' "pollare" i relativi files RSS o Atom che siano. I maggiori grattacapi attuali derivano dalla necessita' di scavalcare un eventuale NAT che si trovi dinnanzi al client, possibilita' tutt'altro che remota nel caso di una connessione domestica dotata di un modem ed un router che distribuisce connettivita' al resto della casa, affinche' il server remoto possa pushare le notifiche. Per ora mi accontento di configurare il detto router per forwardare le trasmissioni entranti su una certa porta direttamente sul PC bersaglio (o meglio: faccio fare al mio collega Netvandal questi test, giacche' ci si mette pure Vodafone a troncarmi le connessioni entranti, ma e' un'altro discorso), ma per quanto sia una soluzione di ripiego comunque comporta infiniti problemi.
Non esiste un modo pulito per recuperare il proprio IP NATtato, non esiste una syscall che dato un indirizzo sappia dire se e' pubblico sull'Internet o meno, non esiste una syscall che dica quale delle interfacce di rete routa verso la Rete, insomma si fa tutto per intuizione e contando nella buona sorte. Qualcosina son riuscito a recuperare in GNet, libreria Glib dedicata appunto all'astrazione delle operazioni di rete recentemente deprecata in favore di GIO (che pero' e' ancora abbastanza bacato per le operazioni su HTTP), ma sempre si va a tentoni.
Insomma: ogni 3 per 2 si parla di integrazione col desktop con la Rete (e sia ben chiaro che la soluzione alternativa del cloud computing "puro", con tutti i dati online, semplicemente non funziona: oggi mi son trovato gubb.net assediato dai cybersquatter e mi sono perso mesi di appunti ed idee, e questo fa il paio con Ma.gnolia auto-distruttosi a causa di una politica di backup farlocco), ma alle parole non conseguono i fatti, e non esistono strumenti che permettano di costruire tools senza impazzire appresso a documentazione forfettaria o codice da copiare ed incollare tenendo le dita incrociate.
E' dura la vita del programmatore...

Ingenuita' Ingegnerizzata

Avevo scritto un frammento di codice in PHP. Dato un input, impiegava 20 secondi a restituire l'output. Ho aggiunto 10 righe, ed ora ce ne mette un paio.
Il protagonista della storia e' GASdotto (il gestionale per Gruppi di Acquisto qualche volta menzionato su questo blog), applicazione che ho imbastito seguendo il piu' possibile la regola secondo cui e' meglio del codice compatto e generico anziche' una gestione manuale (ed ottimizzata) di tutti i casi possibili. Con risultati evidentemente non sempre gratificanti.
Tutta la componente server del programma (cosiccome del resto anche la parte client, in Java) e' fondata su una classe elementare che funge da astrazione per tutte le altre: le sottoclassi di questa definiscono solo quali sono le variabili che contiene (tipo: lo User ha un firstname che e' una stringa, un lastlogin che e' una data...), e tutta la parte di ricostruzione dell'oggetto dal database, serializzazione e deserializzazione JSON, salvataggio, aggiornamento e cancellazione e' implementata una volta sola nella classe di partenza. Tale meccanismo copre anche il caso in cui un oggetto contenga un array di oggetti di altro tipo, i quali sono mappati sul database seguendo una logica predefinita e dunque uguale per tutti e riportata in forma di codice una volta sola. Insomma: una architettura che mi ha permesso di realizzare pressoche' tutta la parte server del software in 2000 righe di PHP (stando alle attuali statistiche su Ohloh), ed in cui posso aggiungere nuovi elementi completi di tutte le funzionalita' con una manciata di altre righe.
Fin qui tutto bello. Il brutto viene mettendo insieme molti oggetti che contengono a loro volta molti oggetti.
Dato un numero di ordini, i quali contengono un numero di prodotti ordinati, ognuno dei quali fa riferimento ad un prodotto disponibile nell'ordine, ognuno dei quali fa riferimento al fornitore che lo distribuisce, e' evidente (soprattutto col senno di poi...) che la quantita' di componenti coinvolti nella semplice richiesta di avere tutte le merci che sono state richieste dai membri del Gruppo di Acquisto e' elevata. Ed attenendosi al primo modello operativo di riferimento ognuno di essi deve essere ripescato dal database e ricondotto ad un oggetto. Anche se e' gia' stato prelevato all'interno dell'elaborazione della stessa richiesta.
Non voglio neanche sapere quante query venivano eseguite in tal frangente, ma non appena mi sono accorto del problema ho applicato in pochi secondi una soluzione basata su un banale array associativo usato a mo' di cache temporanea per tener traccia di quanto gia' ottenuto e recuperarlo subito senza ricostruirlo daccapo: certamente non ottimale, ma funzionale.
La morale di questa narrazione e' di non fidarsi sempre ciecamente dei dogmi dell'ingegneria software: astrarre e' un'ottima cosa, soprattutto se si e' pigri, ma, giacche' la perfezione non e' di questo mondo, per quanto raffinato il vostro sistema avra' sempre una falla, dunque tanto vale rassegnarsi e prepararsi da subito a dover applicare un salutare ed ingenuo hack di quando in quando.

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!

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

opengnomedesktop.org

Finalmente son riuscito a mettere online questa roba: opengnomedesktop.org e' disponibile per tutti coloro alla ricerca di qualche nuovo tema con cui personalizzare il proprio ambiente Gnome, e possono navigarne una ricca selezione (presa da gnome-look.org) valutandoli per mezzo di thumbnails simili, per non dire uguali, a quelle comunemente disponibili nel pannello "Appearance" del sistema. Allo stato attuale solo i temi GTK+2 e quelli per Metacity sono trattati, prossimamente potrei aggiungere anche quelli per il mouse, i fonts e le icone.
Quanto ora online e' da considerare a malapena un proof-of-concept, ampiamente suscettibile a prossime migliorie: il demone di sync con gnome-look.org va perfezionato per non limitarsi a fetchare gli ultimi contenuti ma per allinearsi con altri dettagli di quanto gia' assimilato, va implementata l'interfaccia Open Collaboration Service per permettere l'accesso programmatico alle risorse, devo trovare un modo furbo per eseguire la generazione delle preview (gia' che per problemi tecnici non posso eseguirla in batch direttamente sul server), va introdotto uno straccio di sistema di news per il sito... Insomma, non sono manco all'inizio.
Ma ho comunque immesso il progetto tra le proposte per il gia' piu' volte citato Social Desktop Contest, anche al fine di raccogliere un po' di feedback, ed un poco alla volta entro nell'ottica di presentare un giorno il pacchetto completo direttamente al team Gnome per l'inclusione nella piattaforma: la libreria Glib per l'accesso ai provider OCS ce l'ho, l'applicazione web che raccoglie i contenuti in modo coerente anche, mi manca un prototipo di client dedicato che ricalchi appunto il layout del pannello Appearance ma tratti il materiale online anziche' quello installato localmente e dovrei avere piu' o meno tutto.
Gia' da qualche tempo in Gnome si sente la necessita' di una piu' stretta integrazione col web, nella prossima release 2.28 saranno inclusi diversi componenti mirati in tal senso, e mi piacerebbe provare a cavalcare l'entusiasmo per spingere anche l'integrazione con OCS: sorvolando sul problema odierno dell'unicita' del fornitore (solo la rete OpenDesktop e' al momento erogatrice di risorse per mezzo del protocollo) considero tale strumento assai importante per coinvolgere con maggior profitto all'interno della community free persone che pur non sapendo nulla di programmazione possono dare il loro contributo, almeno in termini di materiale ludico con cui abbellire il desktop.
La strada per il dominio del mondo passa anche per qualche simpatica icona...

Mail, XML e Thumbs

Questo post non e' per un commento o una divagazione specifica e mirata, ma semplicemente per aggiornare i miei lettori sulle attivita' correnti. Del resto, se non ho tempo di bloggare e' perche' ho altro da fare.
Per conto di Itsme negli ultimi giorni ho dovuto "smontare" Evolution, il client mail di Gnome, e trarne una sorta di mail client batch, che non interagisca con l'utente per mezzo di una interfaccia grafica ma popoli il database del backend con le mail in ingresso ed intercetti le nuove mail create (sempre sul database) per spedirle. Al di la' del gusto intrinseco di codesta attivita' (andare a mettere il naso in qualche progetto open ha sempre il suo fascino...) la cosa interessante e' che, con qualche opportuno ritocco qua e la', codesto componente potrebbe divenire il primo pezzo concreto del SubConsciousDaemon di Lobotomy: il funzionamento e' esattamente quello che contavo di realizzare appunto per il mio ambiente, dunque tanto vale riutilizzare questo codice che sara' comunque prossimamente rilasciato in licenza free.
Sempre in merito a Lobotomy: sembra quasi incredibile, ma son tornato a lavorarci. Negli scorsi giorni ho ripreso in mano il dialetto XML per i Thoughts, per accertarmi del fatto che vengano coperti tutti i casi piu' comuni e che comunque non esistano limiti intrinsechi alla definizione di pressoche' tutte le "applicazioni" utili. A breve, terminati gli altri task gia' in corso (e descritti sotto) conto finalmente di iniziare Synapse, ovvero l'interprete del suddetto XML e piu' in generale il gestore dei templates.
Altrove sto ultimando l'opera sul generatore di thumbs dai contenuti di Gnome-Look.org: nonostante abbia avuto un po' da magheggiare per ottenere il risultato desiderato, in quanto i links dei temi da cui trarre la preview non sono fatti per essere trattati programmaticamente e negli archivi compressi i files sono organizzati spesso in modi totalmente arbitrari, e nonostante le limitazioni tecniche sul VPS su cui andra' poi a girare il sito (non son riuscito ad eseguire X.org non essendoci giustamente una scheda grafica, e senza X.org non si puo' lanciare il codice di generazione batch delle thumbs), il demone preposto al download ed all'elaborazione dei temi GTK e Metacity e' pressoche' pronto ed ora debbo solo rifinire l'interfaccia web del sistema. Una volta completata anche quella sottoporro' pure questo progetto al Social Desktop Contest, che ad un mese dalla chiusura conta un solo partecipante (me!) e da cui posso dunque sperare in una proclamazione: sembra la sceneggiatura di uno spot del Gratta e Vinci, quelli della serie "Ti piace vincere facile?", ma se cio' comporta l'acquisizione da parte mia di un netbook non me ne lamento.
Insomma, c'e' sempre qualcosa su cui lavorare...