Lobotomy Project Developers' Blog

Tab Groups

2011-08-03T18:20:00.003+02:00

L'altro giorno, seguendo un filo logico partito dalla visione degli ennesimi presunti mockups per le future versioni di Firefox (cui pero' credo poco: cose del genere sono in giro gia' da tempo, e mai sono state implementate nella release mainstream), ho riaperto e riesaminato il ben noto browser targato Mozilla. L'ho sempre tenuto installato, e apt ha sempre provveduto ad aggiornarlo insieme al resto dei pacchetti della mia Debian, ma gia' da un pezzo ero passato a Chromium dunque non mi ero piu' curato della sua evoluzione e dei suoi progressi.
Quando l'ho avviato ho notato la sua rapidita', sia nelle fasi di caricamento che di rendering delle pagine, ma essendo gia' abituato al browser di Google non mi sono lasciato impressionare piu' di tanto. Ho apprezzato, ma nulla di piu'. Ho fatto un giretto tra le opzioni di configurazione, ho scoperto che la barra dei menu puo' essere ridotta ad un pulsantino anziche' alla solita inutile striscia che spreca spazio verticale, e... Ho trovato, in alto a destra, una inspiegabile icona. L'ho cliccata, e mi si e' aperto un mondo.
Gia' avevo letto qualcosa in merito alla funzione di "Tab Groups", ma mi era sfuggita l'informazione che e' stata inclusa in Firefox gia' dalla versione 4. O forse avevo ignorato tale dettaglio, avendo deciso di metterci una pietra sopra. Sta di fatto che venti minuti di esplorazione mi sono bastati a ri-migrare nuovamente da Chromium.
"Tab Groups" e', in breve, un metodo per aggregare le tabs aperte. Si clicca la famigerata iconcina e si apre uno spazio in cui si possono editare i propri gruppi, crearne di nuovi, spostare le tab da una parte all'altra ed altre operazioni essenziali. Si clicca su una delle tab aperte e si ritorna alla modalita' classica, ma in alto appaiono solo le linguette appartenenti a quello stesso gruppo. Detto cosi' pare semplicistico, ma dopo pochi giorni di utilizzo posso dichiarare che mi ha cambiato la vita.
Un po' per pigrizia, un po' per comodita', sono solito tenere sempre almeno 30 tab aperte. Alcune sono per le amenita' social (Facebook e Google+ in primis), alcuni sono articoli rintracciati sui feed RSS, troppo lunghi per essere letti subito e dunque tenuti da parte per i momenti di calma (qualcuno potra' dire: "Usa Read-It-Later!". Ci ho provato, finivo con l'accumulare dozzine di links ma non avendoli sempre sotto agli occhi me ne dimenticavo e non li riprendevo piu'), altre sono tabs di servizio in cui tengo permanentemente alcuni dei wiki e degli strumenti che uso per appuntarmi le cose che raccatto in giro. Si puo' immaginare quanto sia scarsamente efficiente tale comportamento in un contesto normale. Appena scoperto Tab Groups ho subito creato i miei gruppi: "Da Leggere", "Da Bloggare", "Appunti", "Social"... E ora non ho piu' di cinque/sei tab alla volta davanti, riesco a leggerci sopra i titoli delle pagine (e a identificare al volo quello che serve), non sono continuamente tentato di andare a consultare Facebook (che sta in un gruppo separato, dunque devo recuperarlo volontariamente e coscientemente) ma al contempo ogni volta che entro nella modalita' di navigazione dei gruppi inevitabilmente scorgo la lista di cose da leggere e noto se sta crescendo troppo e richiede attenzione.
Decisamente, consiglio a tutti i disordinati come me di valutare l'uso intensivo di codesta funzionalita'. Non aiutera' forse a ridurre la quantita' di ciarpame web che vi ostinate a lasciare in giro e a consultare, ma almeno servira' a tenerlo separato dalle cose piu' utili.

Social Cloud

2011-07-10T19:38:00.003+02:00

Come in diversi altri casi passati, scrivo questo post piu' per avere un appunto personale reperibile in futuro che per condividere una idea fatta e finita: per ora si tratta solo di una meditazione, non approfondita e non documentata (e dunque potenzialmente fallace), ma chissa' che non sfoci in un (ennesimo!) progetto da sviscerare.
Tutto e' nato dalla combinazione di diversi fattori: il mio recentissimo ingresso in Google+, la mia occasionale lettura della mailing list degli sviluppatori presso la Freedom Box Foundation, e una mezza chiaccherata in chat con un amico.
Sul primo non c'e' molto da dire, bene o male e' sempre la solita frittata: si condividono le foto, lo status e commenti di ogni tipo e genere, si leggono quelli degli altri, ma il progetto non porta nulla di nuovo sul fronte dell'innovazione. Sulla seconda ci sarebbe molto piu' da riferire, ma riassumo in una semplice frase: una congrega di nerd che si fanno pippe cosmiche sulla privacy e sulla crittografia senza riuscire ad individuare i reali problemi, le reali esigenze e le reali soluzioni. Fino a qui, il punto e': sulle tecnologie "social" esiste il totale monopolio delle grandi corporation, le quali per contratto posseggono tutto quello che gli utenti pubblicano e fanno a gara per rendersi incompatibili le une con le altre ostacolando cosi' di fatto l'esplosione delle reali potenzialita' del concetto, mentre i presunti difensori delle liberta' digitali sono del tutto incapaci di fornire alternative sia perche' perdono tempo ad inveire sia perche' oggettivamente riscrivere l'intero stack di software libero orientato al web per venire incontro alle nuove prospettive non e' cosa semplice o banale.
Veniamo dunque al sodo.
La menzionata chiaccherata di ieri sera verteva sulla dispersivita' dei materiali che transitano sui social network, in quanto ognuno scrive ogni cosa ed e' difficile estrarre dal flusso costante di caotiche informazioni qualcosa di specifico. Ironicamente ho consigliato all'amico di lasciar perdere i social e procurarsi un aggregatore di feed RSS con cui seguire i blog tematici che trovava, e all'osservazione che i feed RSS non sono interattivi (un post non puo' essere commentato direttamente dal feed reader, ne' tantomeno essere "like"ato) ho replicato che esiste gia' una estensione RSS che permette di integrare i commenti. Ma, effettivamente, solo in lettura.
Alche', sorge spontanea la domanda: e se i feed RSS fossero commentabili? Cioe': se esistesse una API standard, estremamente banalizzata, che permetta di spedire un commento o una nota ad un hook indicato nel feed senza necessariamente accedere al blog/sito da cui e' stato prelevato, permettendo l'integrazione esterna dell'intero processo di comunicazione? In un colpo solo si riprodurrebbe una delle funzionalita' essenziali dei social network, ovvero la pubblicazione di testi, la loro aggregazione e la possibilita' di rispondere, ma al di fuori dei social network, percui ognuno potrebbe pubblicare usando Wordpress (su wordpress.com o hostato privatamente), o identi.ca (idem), o qualsiasi altra cosa che generi un RSS. E ci vorrebbe poco ad estendere la stessa nozione a foto (Gallery, Mediagoblin...), links (scuttle), e ogni altro genere di contenuto tipato per cui esista una piattaforma web in grado di distribuire.
Come fare a "farsi amica" una persona? La si cerca con WebFinger o si importa un file FOAF o hCard contenente l'insieme di feeds RSS che indicizzano i suoi contenuti. Come fare a seguire i contenuti generati da tale persona? Con un qualsiasi feed reader (desktop o web) arricchito con il supporto all'ipotetica nuova estensione per la scrittura dei commenti.
In un certo qual modo le Web Activities promosse recentemente da Mozilla (ed ancora in fase ultra-sperimentale) vanno in questa direzione, proponendo uno strato operativo all'interno del browser che permetta di integrare servizi web diversi cercando il minimo comun denominatore delle rispettive API ed incrociandole tra loro, ma il succo resta lo stesso: che esista un protocollo standard o un "dispatcher" estendibile per mezzo di plugins, l'obiettivo resta sempre quello di mettere insieme i vari componenti che compongono il web. Costituendo quella che potrebbe essere definita (molto fuffosamente...) "social cloud": una galassia di applicativi separati ed indipendenti tra loro, sparpagliati sull'Internet, che convettano dati ed opinioni senza alcuna forma di centralizzazione.
Gia' lo dissi, e qui lo ripeto: il segreto del successo non sta nel re-implementare daccapo Facebook (o Google+ che dir si voglia), ma nell'utilizzare in modo sensato e ponderato quel che gia' esiste.

La Sindrome di Teodoro

2011-06-04T01:49:00.004+02:00

Qualche tempo addietro ho gia' citato su questo blog la mia esperienza con un anziano signore che ho avuto modo di assistere presso un corso di alfabetizzazione informatica. A distanza di mesi posso dire che il personaggio in questione pur non essendo diventato un sysadmin ha comunque acquisito una modesta dimestichezza col PC, tanto da passare le giornate a compilare fogli di calcolo su OpenOffice Calc per generare coloratissimi quanto inutili (ma evidentemente soddisfacenti) grafici. Mai piu' avrei creduto che, dati i forti limiti dimostrati all'inizio del corso (ed appunto elencati nel mio precedente post) e la distanza intellettuale tra la macchina da scrivere cui era abituato ed un computer moderno, sarebbe arrivato al punto cui e' arrivato, ma tant'e': tanto di cappello al signor Teodoro.

Ad ogni modo: questo articolo non parla di lui ma di me.

Da un po' ho acquistato un nuovo PC (anzi due, l'altro e' l'Abaco di cui ho gia' parlato), un desktop, e l'ho dotato di due monitor da 19 pollici in modo da sperimentare questa per me inedita' modalita' operativa e verificare se davvero impatta sulla produttivita'. La risposta e' "si", ma non e' neanche questo il tema del giorno.

Il punto e' che la presenza di due schermi ha fatto emergere una confusione inconscia dettata dall'abitudine: ci sono spesso due finestre a tutto schermo, ma il focus e' sempre uno solo. Mi spiego meglio: da sempre lavoro con le finestre massimizzate sul desktop, e switcho da una all'altra con la classica combinazione Alt+Tab. Ben rari sono i casi in cui tengo una finestra fluttuante sul monitor, un po' per non essere distratto da quelle sotto e un po' appunto per abitudine: come detto in passato, quando mi capita di aprire una nuova applicazione e vedere la finestra non massimizzata subito premo Alt+F10 per ingrandirla. Questo pero' implica che il mio cervello e' portato a pensare che la finestra che sto guardando e' anche quella che riceve gli input da tastiera, ovvero che ha il focus, ma questo non e' piu' vero nel momento in cui appunto ci sono due schermi con due diversi programmi aperti: il focus, o sta a destra o sta a sinistra.

Per quanto scontata sia questa considerazione, mai va sottovalutato il potere dell'abitudine.

A tutt'oggi, ovvero dopo un paio di mesi di utilizzo quotidiano del doppio monitor, ancora mi trovo ad essere afflitto dalla "Sindrome di Teodoro": se guardo una finestra sono convinto di poterci interagire direttamente, dimenticando di spostare il focus. Esattamente come succedeva al signore cui ho insegnato i rudimenti dell'informatica moderna, anche io mi trovo adesso nella sua condizione: sono portato a scrivere nelle caselle di testo semplicemente dopo averle individuate e guardate sullo schermo. Nel suo caso tale impostazione mentale era probabilmente dovuta all'abitudine alla carta e alla penna, in cui effettivamente la sequenza "trova il punto in cui scrivere / sposta la mano con la penna li' sopra / scrivi" e' un continuum omogeneo che si svolge usando un unico strumento (la penna) che funge sia da dispositivo di puntamento che di input, mentre come detto nel mio caso l'errore e' dettato dall'inclinazione al fatto di avere sempre e solo una finestra con cui interfacciarsi.

Da qualche giorno ho pertanto abilitato l'opzione "Select windows when the mouse moves over them" nel pannello di configurazione per le finestre di Gnome, e la situazione e' un pochino migliorata: muovere il cursore, e dunque il focus, da un monitor all'altro mi riesce in modo abbastanza naturale, dunque non devo stare troppo a pensarci e piu' raramente mi capita di pigiare i tasti giusti per la finestra sbagliata.

Dopo 10 anni di esperienza nell'uso del PC, e' incredibile constatare l'impatto distruttivo che comporta una piccola variazione nel proprio ambiente di lavoro...

In Punta di Pennino

2011-04-03T17:56:00.006+02:00

Anni fa' - oramai ne saranno passati almeno sei - acquistai il mio primo portatile. Ed era un convertibile tablet. Piu' precisamente, un Acer C310. Ai fatti l'ho sempre usato molto poco in modalita' tablet, in quanto pesava troppo per essere davvero utilizzato a mo' di "blocco note" su cui scrivere a mano o anche solo come lettore di e-books, ma ha passivamente ispirato una gran quantita' di idee che sono poi finite in quel calderone pseudo-intellettuale che e' il Lobotomy Project.
Adesso ho acquistato il mio primo netbook. E non poteva che essere a sua volta un convertibile tablet.
L'altro giorno ho aperto la scatola dell'Abaco T102 che ho ordinato un paio di settimane fa', ed ho avuto modo di fare una prima analisi. Che adesso riporto al mondo, usando questo stesso PC.
Innanzitutto, qualche presupposto. Benche' marchiato "Abaco", trattasi questo del leggendario Intel Classmate (di cui, a quanto mi risulta, Abaco e' l'unico rivenditore italiano), ovvero la risposta del mercato all'ancor piu' leggendario progetto OLPC di Nicholas Negroponte. Quello del PC a 100 dollari, per capirsi. Che incidentalmente si e' schiantato nel momento in cui Microsoft ci ha messo lo zampino, ma sorvoliamo sulle facili polemiche. Sta di fatto che questo prodotto non e' un netbook qualsiasi, ma un computer pensato e progettato per essere usato dai bambini a scuola. A prima vista esso sembra un giocattolo particolarmente sofisticato, l'ultima versione del Sapientino Clementoni, ma dopo un po' ci si capacita che il colore azzurro dell'apparecchio e' dovuto al guscio di spessa plastica anti-scivolo applicata intorno al case ed al monitor per proteggere i componenti piu' delicati dagli urti che facilmente i poco curanti pargoli (e/o i distratti nerd) possono provocare. Partire da queste nozioni, ovvero aspettarsi a priori che aprendo la scatola ci si trovera' dinnanzi ad un apparentemente assai poco affidabile arnese, e' condizione imprescindibile per godersi da subito il proprio acquisto.

L'apparecchio ha un peso superiore agli altri netbook con analoghe specifiche video (schermo da 10 pollici widescreen), e la differenza e' probabilmente imputabile appunto alla protezione di plastica supplementare. A occhio pare che lo spazio non sia stato ottimizzato al meglio, e ad esempio sul retro sporge un pezzo (quello cui e' attaccato la simpatica maniglia di gomma) che sembra del tutto inutile ai fini della funzionalita' elettronica. C'e' una sola presa d'aria, sul lato destro, e sotto oltre alla batteria estraibile c'e' un unico pannello incastrato che copre la componentistica.

La qualita' costruttiva e', nel complesso, abbastanza mediocre. Il gia' citato guscio non sembra essere particolarmente rifinito o accuratamente applicato, in alcuni angoli sembra non aderire perfettamente al case (nel mio caso: i due lembi che circondano la webcam ruotabile posta in testa al monitor sono asimmetrici, hanno un dislivello di un paio di millimetri). Ed i simboli sulla tastiera sembrano essere appiccicati in modo grezzo, molti non sono perfettamente centrati e quasi tutti i caratteri non alfanumerici ('@', '*'...) sono veramente piccoli, a malapena leggibili.

Sempre in merito alla tastiera, ci sono luci ed ombre. In linea di massima ci si scrive molto bene, sicuramente meglio che con altri netbook che ho provato (il ben noto Asus EeePC, ad esempio), eppure alcuni tasti (in particolare il tasto 'Fn' di destra) non sono particolarmente sensibili e piu' volte capita di dover ripetere compulsivamente la loro pressione per ottenere il risultato desiderato.

Anche la configurazione "out-of-the-box" della macchina lascia un po' perplessi. Benche' il monitor ruoti correttamente e abbastanza rapidamente (ma qualche volta nella direzione sbagliata...) quando l'apparecchio viene girato o posto in modalita' slate, purtroppo basta entrare ed uscire dalla sospensione del sistema per non far piu' funzionare i tasti funzione posti attorno allo schermo (pagina su, pagina giu', home e fotografia) e neppure la rotazione automatica. La sospensione, si sa, e' da sempre una croce in ambiente Linux, ma ci si aspettava una maggiore cura nella prevenzione di questa problematica.

Lo schermo e' widescreen, e la risoluzione massima bassina: appena 1024x600. Certo una risoluzione piu' alta su 10 pollici renderebbe il tutto troppo picccolo ed illeggibile, ma occorre smanettare un po' per proprio conto per correggere la configurazione del desktop e recuperare un po' di spazio fra i pannelli di Gnome e visualizzare i propri contenuti.

Il touchscreen, essendo resistivo, non ha una grandissima precisione e va un po' calcato, ma in compenso puo' essere usato anche con le dita e non solo col pennino. Certo non basta pigiare col polpastrello, come su uno smartphone, bensi' con la punta del dito o addirittura con l'unghia, ma ammetto di averlo gia' maltrattato un pochino ed il monitor non sembra risentirne o essere incline a graffiarsi tanto facilmente.

La batteria dura un po' piu' di 4 ore con il wireless acceso e senza sforzarlo troppo, dovrei fare qualche analisi piu' approfondita ma in linea di massima mi sembra una durata accettabile.

In conclusione: l'Abaco T102 non e' un prodotto entusiasmante, e la perfezione e' tutt'altra cosa, ma trovandosi in una nicchia di mercato ove le opzioni disponibili sono estremamente limitate fa la sua porca figura. 400 euri per un netbook convertibile tablet fruibile come blocco note o e-book reader (dotandosi di qualche applicazione specializzata: leggere un PDF li' sopra rasenta l'impossibile...) e' un discreto compromesso, consigliabile per chi non ha grandi pretese e vuol provare qualcosa di inedito senza necessariamente incastrarsi sulle limitazioni di un tablet "puro" (senza tastiera QWERTY) o vendersi un rene per un Fujitsu Lifebook.

Minimi Termini

2011-03-14T02:33:00.006+01:00

Grandi dibattiti ha generato sulla blogosfera la decisione, presa abbastanza all'ultimo momento, di rimuovere i tasti per massimizzare e minimizzare le finestre in Gnome-Shell. La discussione si e' poi persa tra i mille rivoli della polemica innescata da Shuttleworth e dal team KDE, che a sua volta abbisognava di un capro espiatorio su cui scaricare la tensione accumulata dal matrimonio Nokia/Microsoft e del conseguente sgretolamento dei sogni di gloria costruiti intorno al toolkit Qt, ma questa e' un'altra storia...
Si diceva: massimizzare e minimizzare le finistre all'interno del window manager. Sorvolando sul fatto che, come detto, questo cambiamento certamente non proprio marginale e' stato attuato in un momento decisamente sbagliato, con Gnome3 all'orizzonte e dunque poco tempo a disposizione per raccogliere il feedback necessario alla validazione dell'idea, personalmente mi ritengo favorevole alla scelta. Con tutte le precisazioni del caso.
Da una parte l'interazione che viene in questo modo promossa ed anzi forzata nei confronti dell'utente prevede un uso intensivo dei workspace virtuali, che in ambiente Linux esistono dalla notte dei tempi ma che su altre piattaforme operative o non esistono affatto o hanno fatto la loro comparsa da poco tempo. Il che' vuol dire creare diverse difficolta' a chi non e' abituato ad organizzare comodamente le proprie finestre distribuendole su piu' desktop, ed ha fatto della minimizzazione una questione di sopravvivenza digitale. Ed in questa categoria ricadono non solo gli esuli di primo pelo del mondo Microsoft, ma anche i numerosi habituee' linuxari che vuoi per zelo o vuoi per forte radicazione ai metodi passati non hanno mai fatto il callo a questa stravagante idea dei desktop multipli.
Dall'altra parte, c'e' da dire che nel momento in cui si prende un minimo di confidenza con la nozione di "workspace" i tasti per massimizzare e minimizzare le finestre sono veramente inutili.
Io, di mio, sono un grandissimo utilizzatore di desktop virtuali: ne tengo sempre almeno 10 a disposizione, e sebbene sia capitato solo rarissimamente di occuparli tutti (ma e' comunque successo...) almeno tre o quattro sono perennemente occupati da una o piu' finestre. Ho il workspace per il cazzeggio sul web, con il browser ed il feed-reader ed il client di posta, quello dedicato esclusivamente al player multimediale che riproduce la radio in streaming, e minimo minimo uno con una sessione Kate (straripante codice) ed un terminale (da cui lanciare le compilazioni di suddetto sorgente) su cui lavorare. Quando devo cercare un qualche file per mezzo del file manager, o leggere qualche documento, o editare qualche immagine con Inkscape e/o Gimp, mi sposto su un altro. Da cio' ne deriva che ogni workspace abbia al massimo quattro finestre aperte, ed essendo cosi' poche non esiste ragione alcuna per cui ne debba minimizzare una per vedere le altre. Credo di non aver usato il tasto "minimizza" per anni.
Lo stesso si puo' dire del tasto "massimizza". Tant'e' che piu' di una volta non sia riuscito a distinguerli l'uno dell'altro alla prima occhiata: essi mi sono totalmente estranei. Ma ammetto che, in questo caso, ho barato: talvolta mi capita di massimizzare le finestre, ma uso la shortcut Alt+F10 mappata di default su Gnome. Cio' accade solo perche', avendo appunto poche finestre per desktop da gestire, mi piace tenerle tutte a tutto schermo e talvolta capita che esse partano a dimensioni ridotte.
Sta di fatto che, al fin della fiera, la scelta operata e' coerente con la linea di sviluppo di Gnome-Shell, che appunto punta moltissimo sui workspaces. Dunque, la reputo immensamente condivisibile. Non ultimo perche' si risolve con la rimozione di due tasti, ed io sono quasi sempre favorevole alla rimozione degli elementi a video. Che gli utenti, aggrappati alle loro abitudini come cozze allo scoglio, si lamentino occasionalmente di qualsivoglia modifica alla loro interfaccia grafica, indipendentemente da quanto la modifica sia benefica e sensata, e' normale, endemico, inevitabile. E, per questo, ignorabile.

L'Indirizzo che non C'e'

2011-02-02T03:17:00.007+01:00

Leggendo l'ennesimo apocalittico articolo in merito all'allocazione dell'ultimo blocco di indirizzi IPv4 disponibili, e memore di alcune osservazioni che io stesso ho fatto in un post dell'altro mio blog a sfondo "culturale", mi sono capacitato di una emergenza imminente nel campo dell'interazione uomo-macchina: quando IPv6 sara' la norma, e anche la mia LAN sara' routata su tale protocollo, come diamine faro' a ricordarmi a memoria gli astrusi ed assolutamente poco mnemonici indirizzi delle macchine di casa mia per potervi accedere? Bene o male con IPv4 ci si arrangia, assunto che la classe di una rete domestica e' quasi sempre una di quelle appositamente lasciate riservate per scopi locali (o, per meglio dire: e' quasi sempre 192.168.0.0), ed anche un identificativo arbitrario sulla Rete globale e' pur sempre costituito da soli quattro numeri che con un poco di sforzo si riescono a fissare nel cervello, ma chi mai potrebbe memorizzare la sfilza di caratteri, cifre e segni di interpunzione mescolati in un indirizzo di nuova generazione? Certo, anche in IPv6 esiste il concetto di indirizzo privato che puo' essere espresso in forma abbreviata, in cui comunque si trovano ben 10 cifre esadecimali a caso; un numero in base 10 (ad esempio: 134) si ricorda sicuramente meglio di un agglomerato impronunciabile (ad esempio: 21F4).

Il problema e' piu' grave di quanto non si possa immaginare, in quanto a tutt'oggi ci troviamo a maneggiare gli indirizzi numerici piu' spesso di quanto non si creda.

Per individuare e navigare i filesystem delle altre macchine nella rete locale, esposti con i protocolli piu' disparati (NFS, NetBIOS/Samba, SFTP...), esistono gia' fior di tools perfettamente integrati con ogni desktop environment minimamente completo (cfr. Gnome e KDE). Dunque in questo caso il dubbio non esiste. Lo stesso puo' dirsi per le stampanti (nativamente di rete, o esposte in rete per mezzo di CUPS). Ma quanti sono gli strumenti di backup, con cui periodicamente duplicare i propri dati importanti su un altro PC e/o un altro disco rigido remoto, che supportano il discovery delle istanze sparpagliate sul network? E come fare a trovare le interfacce di amministrazione web dei vari routers, access point e modem che popolano le mensole polverose delle nostre case? Senza parlare di tutte le esigenze assai piu' complesse degli utenti piu' smaliziati, i quali tanto per dirne una hanno questa fissazione di accedere ai propri PC via SSH...

Le odierne limitazioni dei meccanismi di amministrazione delle reti, unite alla crescente necessita' di essere connessi all'Internet ed alla moltiplicazione di apparecchi digitali di cui ognuno dispone (ben poche sono le case in cui ci sia un solo PC, senza contare smartphones e tablets ed altre diavolerie), implicano che l'interazione diretta con gli indirizzi IP e' oramai pratica assai diffusa e pervasiva, anche tra l'utenza di basso rango: negli ultimi mesi mi e' capitato piu' di un utonto contemplare il relativo pannello di configurazione sul proprio sistema operativo alla ricerca di una soluzione abbozzata per potersi agganciare ad un vicino access point, spinto e motivato in questa sua estemporanea avventura nerd dal desiderio di consultare la propria bacheca su Facebook.

Siamo davvero pronti a questo salto? Gli strumenti di assistenza per i quotidiani task relativi al networking (locale e remoto) sono all'altezza? Mi piacerebbe metterli alla prova, switchando la mia LAN appunto al routing IPv6, non fosse che la versione di dd-wrt flashata sulla mia Fonera non supporta tale protocollo e non riesco a fare l'upgrade alla versione successiva: partiamo subito male...

Una Mela in Testa

2011-01-20T02:30:00.002+01:00

Da quando ho iniziato a leggere e documentarmi sul tema dell'usabilita' delle interfacce utente ho piu' volte sentito parlare nell'Apple Newton, PDA uscito agli inizi degli anni '90 e di breve vita sul mercato, indicato da molti come un ottimo esempio di efficienza e rappresentativo di alcuni concetti particolarmente interessanti. Ma ammetto di non aver mai indagato approfonditamente su tale oggetto, prendendo sempre per buone le entusiastiche dichiarazioni ma inconsciamente pensando che le funzionalita' di tale apparecchio fossero, a causa dell'evidente anzianita' del prodotto, cosi' limitate da non meritare neppure di essere prese in considerazione.

Finche' l'altro giorno mi sono trovato a leggere un articolo (peraltro generatore di infinita ispirazione, dovro' tornarci sopra in futuro), in cui viene indirettamente linkato un video su YouTube che dimostra l'utilizzo del leggendario Newton. E ne sono rimasto sbalordito.

L'utilizzo del device e' molto semplice: c'e' uno schermo completamente touchscreen, ci si scrive sopra quel che si vuole (con la tastiera virtuale o a mano: stando al video l'handwriting recognization del '90 non era cosi' tanto male, e' un peccato che nel ventennio seguente non sia piu' stata migliorata), e... il contenuto viene trasformato in un altro tipo di contenuto a seconda di quello che viene riconosciuto, o dietro suggerimento dell'utente. Insomma: se si scrive "pranzo con Mario" si puo' andare a piazzare il nuovo appuntamento nel calendar, se si scrive "chiama Pippo" viene lanciata la chiamata, se si immette un numero telefonico si apre il form per la creazione di un nuovo contatto.

Chiaramente, il primo richiamo che ho avuto e' stato il progetto Lobotomy e l'originale idea di rendere trasversali i dati indipendentemente dal formato con cui venivano trasmessi o manipolati. Anche se il concetto introdotto nel Newton e' un poco diverso: non quello di trasformare i vari contenuti in qualcos'altro, ma trasformare caso per caso un unico tipo di contenuto (la nota, atomo primario del modello di interazione) in qualcosa di piu' strutturato e specifico.

Resta il fatto che gia' allora gli ingegneri Apple avevano avuto l'illuminazione e l'avevano trasposta in un prodotto commerciale e alla portata degli utenti (si, d'accordo: solo degli utenti facoltosi, considerando il prezzo, ma ci siamo capiti...): ignorare totalmente nozioni tecniche e nerdeggianti come il "file" o il "formato", ma occuparsi in modo semi-automatizzato di tali dettagli e lasciare che l'utilizzatore si concentrasse sull'informazione nuda e cruda.

Il PDA in oggetto spari' rapidamente dal mercato, vuoi perche' le tecnologie hardware dell'epoca erano ancora troppo limitate per uno sfruttamento del concept (una agenza cartacea delle stesse dimensioni poteva tranquillamente contenere una mole di informazioni molto superiore rispetto ai suoi modesti circuiti di rame e pietra), vuoi perche' il popolo di consumatori non era ancora pronto per esso (nell'era pre-Web2.0 quanti sarebbero stati disposti a spendere quella cifra per un blocco note molto sofisticato?) e vuoi anche perche' essendo tutto il sistema integrato non c'era spazio per l'ingresso di altri vendors che fornissero applicazioni e servizi (come e' invece adesso per apparati tipo l'iPad) dunque nessuno poteva essere realmente interessato alla sua diffusione priva da sbocchi commerciali e profittevoli per chiunque altro non fosse Apple. Ma a distanza di vent'anni varrebbe la pena rivalutare e riesaminare i concetti che all'epoca sono stati compressi nello scatolotto nero, poco apprezzabili negli anni '90 ma perfettamente attuali ed anzi impellenti nel mondo di oggi.

Perche' reinventare la ruota, quando buona parte del lavoro e' gia' stata svolta?

Aggiornamento nell'Ombra

2011-01-14T12:52:00.004+01:00

Manco il tempo di finire di scrivere il precedente post sui potenziali vantaggi di un meccanismo di aggiornamento interno alle applicazioni, in grado di pescare autonomamente informazioni sulla disponibilita' di nuove versioni da scaricare ed installare in modo trasparente e senza disturbare l'utente, che subito salgono agli onori della cronaca notizie sulle prossime evoluzioni di Chrome, il web browser targato Google.

Stando alle ultime presentazioni per il prossimo futuro di tale prodotto si prevede di soppiantare la tendenza prettamente tecnofila di rilasciare le varie versioni identificandole da un numero sequenziale, ed invece impacchettare piccoli cambiamenti ad intervalli regolari e tra loro ristretti (sei mesi) e diffonderli sui desktop del pianeta con un automatismo silenzioso. A ben guardare Chrome da sempre gestisce in questo modo gli aggiornamenti di se' stesso, addirittura compiendo un controllo sul repository centralizzato ogni cinque ore, ma evidentemente il concetto e' stato migliorato e raffinato ulteriormente. Si mormora inoltre che pure la prossima major release di Firefox, la 4 includera' tale funzionalita'.

Come intuibile, appunto, dal post pubblicato l'altro giorno su questo stesso blog questo genere di soluzioni mi garba assai. Tantopiu' per applicativi come i web browser, diventati strumenti essenziali nella vita digitale di ciascuno e cosi' frequentemente bersagliati da attacchi mirati alla loro sicurezza da patchare il piu' presto possibile a prescindere dalla noncuranza dell'utente. Certo chi sviluppa un browser non ha tutta questa urgenza di diffondere nuove features, in quanto in fin dei conti tale classe di software operativo non espone particolari funzionalita' necessariamente sempre nuove (renderizzano le pagine, salvano i bookmarks, aprono e chiudono le tabs, poco altro), ma le migliorie per quanto piccole e discrete son sempre gradite, soprattutto quando non ci si deve attivare in prima persona per ottenerle.

D'altro canto, immagino che nel momento in cui i singoli programmi provvedano per conto proprio all'aggiornamento si possano creare non pochi grattacapi per i packagers delle distribuzioni. Cosa mettere nei repository? Cosa succede se all'atto dell'invocazione di un "apt-get upgrade" la versione proposta e pacchettizzata e' piu' vecchia di quella scaricata autonomamente? Come fronteggiare eventuali aggiornamenti che richiedono librerie e pacchetti particolari, e dunque da installare o a loro volta aggiornare per il supporto di una nuova funzionalita'?

Per non parlare dei futuri (ma comunque non immediati) problemi tecnici che potrebbero sorgere qualora tale pratica dovesse diffondersi: come arginare la potenziale esplosione di comunicazioni verso l'Internet, dovute al fatto che ogni singolo programma pretenderebbe di contatterebbe ad intervalli periodici il proprio server di riferimento in cerca di qualcosa di nuovo da scaricare? E come reagirebbe quella nicchia di utenti cultori della privacy e del pieno controllo dinnanzi alla necessita' di dover disabilitare (o nella peggiore delle ipotesi filtrare con metodi piu' radicali) siffatte transazioni non richieste per ognuno dei software utilizzati?

La soluzione ad entrambi i suddetti tipi di ostacoli potrebbe stare in una evoluzione degli attuali package managers, affinche' forniscano nativamente la funzionalita' di auto-upgrade per i programmi che lo richiedono, coordinando ed ottimizzando le connessioni verso l'esterno e provvedendo un unico centro di configurazione per chi ha il tempo da perdere verificando chi sta facendo cosa. Dirottando tutto al manager centralizzato esso sarebbe sempre consapevole di quale precisa versione e' in uso in un dato momento, quali sono i pacchetti che si auto-aggiornano per fatti propri e quali devono essere allineati con i repository della distribuzione secondo lo schema classico, e come comportarsi con le dipendenze.

Forse adesso e' troppo presto per porsi questo genere di domande, in quanto appunto solo Chrome e Firefox si stanno muovendo verso la direzione dell'autogestione. Ma nel momento in cui dovesse essere osservato un trend piu' cospicuo sarebbe opportuno correre ai ripari il prima possibile, mettendosi d'accordo tutti insieme su come amministrare in modo pacifico la legittima richiesta di aggiornamenti frequenti con la necessita' di far convivere numerosi pacchetti ognuno con una propria sequenza di versioning, ed evitare che codesta emergente moda dilaghi fino a minare uno dei pilastri su cui si poggia il successo del desktop Linux, appunto il package management.

Prevenire e' meglio che curare.

I Piccoli Aggiornamenti

2011-01-05T14:44:00.005+01:00

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

2010-11-24T02:29:00.006+01:00

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

2010-11-14T22:27:00.002+01:00

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

2010-11-11T19:31:00.002+01:00

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.

La Prova

2010-10-31T00:31:00.005+02:00

In questo periodo sto dando una mano presso un corso di alfabetizzazione informatica organizzato dall'Officina Informatica Libera di Torino, frequentato per lo piu' da anziani ed extracomunitari. Talvolta mi trovo ad affiancare gli utenti mentre svolgono gli esercizi mirati a fargli prendere dimestichezza con mouse e tastiera, e sin troppo spesso finisco nei paraggi di un baffuto signore in particolare.

Questo personaggio, nella sua immensa ignoranza (in senso non offensivo, ovviamente) ed ingenuita', e' la dimostrazione vivente di quando sia complicato utilizzare un computer al giorno d'oggi. Facilmente va nel panico, percui si dimentica quello che gli e' stato spiegato cinque minuti prima e tenta di intuire qual'e' l'operazione giusta da fare in un dato momento, puntualmente non riuscendoci e ripetendo l'errore che aveva gia' compiuto prima della spiegazione.

Il mio preferito e' la confusione esistente tra il cursore del mouse ed il cursore lampeggiante del testo. Spesso egli punta il mouse laddove vuole apportare una modifica in una frase (cancellare un carattere, o aggiungerne un'altro), non clicca, ma comunque pigia il tasto della tastiera corrispettivo. Applicando ovviamente tale modifica da tutt'altra parte.

Fa uscire di testa guardarlo mentre tenta di selezionare del testo usando il mouse, in quanto tale tecnica per quanto famigliare per molti e' costituita da infinite "regole" non esplicite e di non immediato apprendimento: la selezione e' monodirezionale (inizia nel punto in cui si e' iniziato a cliccare e finisce nel punto ove il cursore viene spostato, dunque non e' possibile agire contemporaneamente sopra e sotto l'inizio della selezione), deve essere eseguita in un colpo solo (tutte le righe senza mai lasciare il tasto sinistro del mouse), e' suscettibile di speciali comportamenti e un testo selezionato puo' essere spostata in blocco (dunque e' buona norma deselezionare tutto prima di tentare una nuova selezione)... Tutto questo contribuisce a far perdere l'orientamento al buon utente volenteroso (e la pazienza al volenteroso assistente che gli sta accanto), al decimo tentativo di prendere cinque righe egli ha gia' sparpagliato tutto in giro per il documento cliccando e trascinando a casaccio.

I tasti sulla tastiera sono decisamente troppi. Le lettere dell'alfabeto sono sparpagliate, ma le si puo' cercare facilmente. Gia' i tasti con due o peggio tre simboli sono complicati, perche' ogni carattere e' attivabile pigiando il relativo "modifier" (che non viene mai scelto correttamente). Il dramma e' che i simboli selezionabili con Shift non sono attivati quando e' attivo il CapsLock, dunque tutto il vantaggio di spezzare la procedura in piu' parti (pigia CapsLock, pigia tasto, ripigia CapsLock) viene perso ed anzi e' richiesto di coordinare il movimento di ben due dita (un dito fisso su Shift, l'altro sul tasto desiderato). Stendiamo un velo pietoso sui pulsanti Return e Enter, i quali sono vicini e pur facendo cose totalmente diverse riportano entrambi il disegnino della freccia diretta a sinistra...

Tutte e altre considerazioni sono emerse dopo due incontri, facendo solo input di testo vagamente formattato. Sara' dura instradare correttamente il suddetto personaggio, comunque indipendentemente dai risultati che si raggiungeranno (o piu' probabilmente non si raggiungeranno) cerchero' di osservare e registrare i comportamenti della mia cavia per trarne qualche spunto.

Attivita' Collaterale

2010-10-15T14:05:00.005+02:00

In un recente post sul suo blog, Aaron Seigo (project leader di KDE) ci spiega il concetto di "attivita'" e la differenza che tale termine assume nelle piu' recenti incarnazioni dei desktop environment Gnome e KDE (non mancando ovviamente di sottolineare quanto il tutto sia molto migliore nel progetto da lui rappresentato).

In breve: una "attivita'" e' un agglomerato eterogeneo di files (e di relative applicazioni per aprirli) che rientrano all'interno di uno specifico task dell'utente, definito manualmente (ed eventualmente anche in modo automatico), invocabile on-demand a seconda di quel che si sta facendo. Per fare un esempio: se lo sviluppo di un dato pezzo di codice comprende i sorgenti, la documentazione dell'API usata e qualche altro contenuto, posso pigiare il tasto "aprimi questa attivita'" ed il desktop environment mi presenta il tutto senza dover aprire ogni singola cosa a mano.

Mi spiace per Seigo, ma io tutto questo lo avevo gia' valutato ed analizzato nel 2004 (come conferma archive.org) nel contesto del fu' progetto BrainTop. E l'ho gia' scartato.

Il concetto e' molto semplice: quel che gli utenti fanno col PC non sempre e' classificabile all'interno di un singolo task, anzi cio' accade piu' raramente di quanto non si creda. L'esempio piu' banale e' quello del player multimediale che in background riproduce musica di sottofondo: esso e' totalmente scorrelato da qualsiasi attivita', e ben difficilmente una data colonna sonora e' univoca e definita per un task. Esempio meno banale sono le comunicazioni sincrone ed asincrone che ognuno di noi si trova a gestire in qualunque momento della giornata: la gente mi contatta in chat indipendentemente da quel che sto facendo, cosiccome mi arrivano continuamente mail da ogni mittente e su ogni tema; tale mole di attivita' de-contestualizzate dovrebbero essere identificate in quanto tali, ed il sistema dovrebbe riconoscere (non si sa come...) l'incongruenza logica evitando di contemplate all'interno della mia sessione di lavoro il programma risvegliato da un input esterno.

Piu' complesso e' il ragionamento sulla quantita' di compiti che in ogni momento si svolgono. La scienza dice, giustamente, che le persone non possono fare piu' di una cosa alla volta. O meglio: che tale pratica e' deleteria. Eppure tutti lo fanno. Una mezza occhiata a Facebook o alle news o alla posta la si da anche lavorando, o magari ci sono momenti in cui si stanno effettivamente mettendo le mani su due cose completamente diverse (in questo preciso momento io sto bloggando a smozzichi tra una compilazione e l'altra di GASdotto). Come dovrebbero comportarsi le "attivita'" in questo caso? Dovrebbero forse mergiare i task tra loro? O includere gli applicativi consultati occasionalmente?

Insomma: dopo averci gia' a lungo ragionato, io sono giunto alla conclusione che codesta suddivisione del lavoro e' perfetta in un mondo ideale e perfetto ma non calza affatto i casi d'uso reali. Attendo di vedere quanto tempo sara' necessario ai team KDE e Gnome per accorgersene a loro volta.

Mappa Geo/Mentale

2010-08-26T20:12:00.003+02:00

Qualche tempo addietro il buon Seif Lofty, maintainer dello stravagante progetto Zeitgeist, ha pubblicato un esempio di cio' che e' possibile fare appunto con il suo collettore di informazione.

In una applicazioncina, approntata a mo' di hack, viene presentata una mappa geografica, e cliccando su di essa vengono visualizzati i files editati o consultati mentre ci si trovava in tale posto. O anche, come dimostrato nello screencast, le persone con cui si ha chattato stando in tale locazione.

Il concetto mi garba assai, perche' aggiunge un ottimo criterio di ricerca per facilitare l'individuazione dei files cui si e' interessati: lo spazio fisico. Accade infatti piu' spesso di quanto non si creda (almeno a me) di ricordare di aver fatto o visto qualcosa di interessante mentre ci si trovava in un dato luogo, magari a casa di un amico o nel bel mezzo di un raduno di smanettoni, e nel suo piccolo codesto simpatico software si presenta come ottimo connubio tra facilita' d'uso ed efficienza del risultato.

Dal canto mio avevo gia' iniziato a valutare tempo addietro questo genere di correlazioni "ambientali" per facilitare la navigazione dei contenuti, tant'e' che nella lista di possibili Thoughts per Lobotomy avevo immesso anche una fantomatica "Timeline" che mettesse in parallelo l'accesso ai documenti con altri parametri apparentemente totalmente scorrelati tipo gli eventi del calendario (per sapere cosa e' stato consultato mentre ci si trovava ad un dato appuntamento, concetto gia' superficialmente implementato dal file manager Nemo) o addirittura le condizioni meteo ("L'altro giorno pioveva e ne ho approfittato per scrivere quel file, dove l'ho messo...?").

Piu' in generale credo che tale genere di espedienti multisensoriali siano una ottima strada da esplorare nella corsa al data management moderno, in questi tempi cosi' ricchi di materiale da gestire e cosi' scarsi strumenti per farlo. Il fatto di estendere le capacita' di ricerca entro una dimensione, appunto lo spazio e le condizioni fisiche, cui il nostro cervello e' assai ben abituato da qualche centinaio di migliaia di anni di evoluzione e' un inestimabile valore aggiunto, esattamente perche' rende l'operazione di ricerca estremamente piu' naturale.

Si avvicina il momento in cui l'odierna gerarchia a cartelle sara' sostituita da qualcos'altro, magari una cartina geografica...

Pensieri Androidi

2010-08-26T01:37:00.006+02:00

Poco tempo fa' ho finalmente acquistato un HTC Desire, simpatico smartphone che monta di serie il ben noto sistema operativo Android di Google. Manco a dirlo tre giorni dopo l'acquisto ho scaricato l'SDK ed ho iniziato a dare una occhiata alle guide per i developers, anche se solo adesso (dopo una settimana di vacanza a zonzo per il nord Italia e l'urgente lavoro per la release 2.0 di GASdotto) comincio a comprendere le nozioni di base della piattaforma.

Non nego di essermi un poco stupito nello scoprire l'estrema somiglianza tra quelli che in Android vengono chiamati "Layout" e i "Thoughts", alla base di un po' tutta l'architettura grafica di Lobotomy.

In entrambi, l'intera interfaccia di ogni schermata viene definita all'interno di un file XML, che verra' poi interpretato per piazzare i widgets al posto dei tags definiti. Contrariamente a XUL codesti files non contengono alcuna componente funzionale, solo ed esclusivamente la disposizione degli elementi grafici.

In entrambi, ogni file rappresenta una singola schermata. In Android, se una applicazione prevede piu' sezioni ciascuna di esse deve essere definita all'interno di un suo specifico XML, che vive una vita propria e prende il nome di "Activity".

In entrambi, i componenti sono riutilizzabili, miscelabili e richiamati da una parte all'altra in modo trasparente, anche tra applicazioni diverse. Sulla piattaforma di Google il meccanismo prende il nome di "Intents" (da "Open Intents", progetto nato come piattaforma all'interno della piattaforma e alla fine incastonato nel core vero e proprio di Android), e benche' a prima vista sia poco sfruttato dal software attualmente nel Market ha ricche potenzialita'.

Ovviamente esistono anche differenze tra i "Thoughts" di Lobotomy ed i "Layouts" di Android: i primi prevedono una assai piu' netta separazione tra interfaccia grafica e codice funzionale, e la possibilita' di creare i propri widgets da usare e riusare all'interno della definizione XML. E' comunque molto interessante constatare come tali concetti, fino ad ora esistiti solo nei miei appunti, vengano adottati all'interno di un ambiente di questo spessore, ed ancora piu' interessante e' misurarsi con essi sul piano pratico tentando di costruire qualcosa partendo da siffatti strumenti.

Per ora, continuo ad indagare sulla visione degli ingegneri Google provando a capirci qualcosa.

Informazione Colorata

2010-07-31T13:01:00.006+02:00

Nella oramai imminente release 2.0 di GASdotto (stando alla roadmap attuale dovrebbe essere rilasciata entro la fine di agosto) e' stato introdotto un nuovo pannello dedicato ai grafici: per mezzo della Google Visualization API, integrata in GWT, ho aggiunto qualche disegnino che rappresenta graficamente in forma di barre e torte il numero di utenti che hanno ordinato qualcosa presso un fornitore, a quanto ammonta la cifra totale degli ordini effettuati in un dato intervallo di tempo, e quali sono i prodotti piu' richiesti. Credo che sia venuto abbastanza bene, i grafici sono graziosi ed abbastanza ben leggibili.
L'altra sera ero a casa dell'amico che mi da una mano con lo sviluppo, o meglio che mi guida suggerendo features e migliorie: essendo uno dei responsabili di uno dei Gruppi di Acquisto piu' grossi di Torino, il quale gruppo e' peraltro il maggior fruitore "ufficiale" dell'applicazione, ha accesso ad una mole di dati immensa ed estremamente utile per effettuare test piu' che significativi sul software.
Ero a casa sua, dicevo, ed insieme a noi c'era un altro amico, anche lui all'interno dello stesso GAS, e stavamo contemplando lo stato attuale della piattaforma (il cui codice, seppur non rilasciato, e' accessibile a tutti dal repository SVN) su uno snapshot della base dati realmente utilizzata dal gruppo. Quando e' stato aperto il pannello delle statistiche, il grafico a torta rappresentante la spartizione dei quattrini tra i diversi fornitori visualizzava uno spicchio grosso quasi quanto un quarto del totale. "A chi diamo tutti questi soldi?", e' stata la reazione del nostro ospite. Ne e' emerso che, per un motivo o per l'altro, un singolo produttore (su circa 17) assorbiva appunto quasi un quarto delle attenzioni della combriccola, in evidente contrasto con quello che dovrebbe essere lo spirito di equita' e solidarieta' che anima questo genere di iniziative.
Tutto questo fior fior di aneddoto per ribadire qualcosa di non nuovo: una rappresentazione grafica che riassuma in un colpo solo una discreta quantita' di dati fornisce nozioni che sarebbero afferrabili solo analizzando molto attentamente i dati stessi, o per meglio dire nozioni che altrimenti a nessuno verrebbe mai in testa di analizzare.
Coloro che seguono Information is Beautiful, noto blog interamente dedicato agli infographics (nome altisonante per indicare l'arte di far grafici che siano anche belli da vedere), sanno bene a cosa mi riferisco: non e' raro trovarsi dinnanzi a pochi pixel colorati che spiegano una quantita' infinita di cose, cui magari non si e' mai pensato. Nel mio piccolo anche io ho iniziato recentemente ad esplorare questo particolare settore con l'esperienza di Masciap, blog in cui ogni settimana i dataset pubblicati sull'apposito portale della Regione Piemonte vengono tradotti in numeri e grafici, e nonostante la giovane eta' del progetto qualche considerazione significativa e' gia' saltata fuori.
Vorrei nel prossimo futuro includere grafici e tabelle in ogni posto dove sia possibile farlo (gia' tale genere di funzionalita' e' prevista nella roadmap a lungo termine di Maintainr, per riassumere il tempo dedicato ad ogni progetto gestito dal programma), in quanto essi sono un valore aggiunto di inestimabile valore: poche semplici barre possono drasticamente aiutare ad individuare situazioni anomale, e permettere all'utente di agire per correggere il tiro nei confronti dei suoi propri obiettivi, richiedendo del resto uno sforzo minimo da parte di chi implementa l'applicazione.

Automazione per Induzione

2010-07-17T00:19:00.006+02:00

Qualche tempo addietro vidi che in KMail era stata introdotta una simpaticissima feature: dato un indirizzo mail e la relativa password, esso autoconfigurava l'account identificando il server SMTP, il server POP3, le porte di accesso, l'autenticazione SSL attivata o meno, insomma tutti quei dettagli che raramente un utente domestico comprende e che nella migliore delle ipotesi copia e incolla pedestramente dalla pagina di supporto del sito web del provider di fiducia.
Sul momento ho pensato che il suddetto programma dovesse appoggiarsi ad un qualche database online di configurazioni, e dopo qualche indagine sono giunto ad una succulenta scoperta: il meccanismo si chiama ISPDB ed e' stato ideato da Mozilla per Thunderbird (il loro client di posta), e sebbene l'API sia pressoche' inesistente (un URL cui accodare il dominio che interessa, che ritorna indietro un XML) e ben nascosta (ho ravanato un poco per trovare un riferimento al sopra menzionato URL) risulta comunque vagamente usabile. Tant'e' che persino Evolution supporta da poco tale sistema.
Chiaramente mi sono precipitato a mettere insieme del codice per usare tale base di dati, e piu' precisamente ho accrocchiato una funzione PHP che verra' nel prossimo futuro integrata in GASdotto per facilitare la configurazione delle mail in uscita generate dal programma.
Sorvolando sulla mia fregola programmatoria, mi compiaccio del fatto che qualcuno abbia avuto questa bella idea di voler automatizzare qualcosa di facilmente automatizzabile ed abbia messo in piedi un sistema tutto sommato semplice e scontato per ottenere qualcosa che, per l'utente casalingo, semplice e scontato non e'. ISPDB e' un Uovo di Colombo, implementato come detto molto alla buona, ma io credo che nella sua modestia sia un ottimo esempio di come si possa parecchio facilitare la vita all'utente finale: pescando parametri del resto sempre uguali tra loro da una base dati condivisa si evita di dover effettuare la procedura a mano, eliminando peraltro tutti i rischi e le frustrazioni dovute a copia&incolla malamente eseguiti a causa del fatto che chi opera non capisce realmente cosa sta facendo.
La dimostrazione di come un pugno di dati forniti di una semantica possano risolvere problemi, anche grossi, concreti e sotto gli occhi di tutti.
Probabilmente ci sono molti altri casi in cui si potrebbe procedere per metodo induttivo, individuando alcuni patterns ripetitivi ed incastonandoli in un unico flusso gestibile in larga parte per via automatica. Tutto sta nello scoprirli ed ingegnerizzarli.

ZUI, Ma Anche No

2010-07-10T20:14:00.003+02:00

Constato adesso il fatto di non aver mai menzionato le ZUI (Zooming User Interface) su questo blog, ma ora, dopo la lettura di The Humane Interface, mi e' inevitabile.
Nel suo pluri-osannato saggio, il fu' Raskin dedica ampio spazio alla descrizione di interfacce per sistemi general purpose incentrate sul fatto di poter navigare sostanzialmente in tre dimensioni le informazioni, distribuite non gia' all'interno di un albero bidimensionale (la ben famigliare gerarchia a cartelle) ma su una serie potenzialmente infinita di piani "trasparenti" cui accedere zoomando una data porzione dello schermo fintantoche' ci sia qualcosa da zoomare. A tale sistema viene attribuita la capacita' di mostrare moli importanti di dati in un unico colpo d'occhio, una migliore intuitivita' nell'interazione, e l'implicita' possibilita' di embeddare nella stessa interfaccia funzionalita' complesse che, ai fatti, possono sostituire le canoniche applicazioni cui siamo abituati con un agglomerato onnipotente ed onnipresente ben piu' omogeneo.
Personalmente, non sono particolarmente favorevole al paradigma suggerito dalla ZUI. Certamente sono propenso all'ultima nozione di eliminazione delle singole applicazioni (del resto, buona parte del Progetto Lobotomy si basa su tale concetto), ma non posso essere d'accordo in merito all'effettiva efficienza sul trattamento delle informazioni.
In primis: seppur tridimensionale anziche' bidimensionale, pur sempre di una gerarchia si tratta. Gli elementi a video sono sempre raggruppati tra loro secondo un unico criterio arbitrario e non riproducibile o prevedibile definito dall'utente: laddove nell'albero a cartelle i files si trovano nelle directory scelte (spesso malamente) dall'utilizzatore qui vanno posizionati all'interno dello spazio, ma comunque sempre in una qualche "zona" la cui reperibilita' e' sempre delegata alla (fragile) memoria del povero tapino che sta dall'altra parte del monitor. Anzi, in uno spazio tridimensionale si aggiunge una ennesima dimensione entro cui potersi perdere: nel momento in cui sto cercando un documento non devo ricordarmi solo in quale gruppo di documenti l'ho messo, ma potrei benissimo non rintracciarlo essendo esso visibile solo ad un livello di zoom minore o maggiore rispetto a quello attuale.
Per estensione, anche il vantaggio della quantita' di dati visualizzati in un colpo solo viene minato appunto dalla mancanza di conoscenza a priori del giusto livello di zoom entro cui un dato si trova: quel che sto cercando potrebbe benissimo essere stato piazzato in uno strato "superiore", e dunque essere identificabile solo "allargando" la visuale e perdendo la percezione di quel che si trova negli strati "inferiori".
Nel tomo del Raskin viene illustrato l'esempio di una ZUI usata per descrivere l'organizzazione di una serie di cliniche: certamente un impiego del genere sarebbe ben piu' appropriato di un sistema "general purpose", in quanto le informazioni da maneggiare sono gia' distribuite entro una gerarchia nota che si vuole riprodurre metaforicamente (le cliniche, ovvero gli edifici, composti da piani, composti da stanze, popolate da letti in cui stanno i pazienti), ma il problema della navigabilita' rimane: per accedere ai dettagli relativi ad una persona devo sapere a priori dove essa si trova (quale edificio, quale piano, quale stanza, quale letto), e per quanto una funzione di ricerca full-text possa essere facilmente innestata in modo che dato un nome l'interfaccia possa zoomare da sola dove richiesto non e' chiaro quale dovrebbe essere il comportamento in caso di risultati multipli (schermo splittato, ove ogni parte visualizza la porzione corretta dello schema completo???).
Numerosi altri punti sono altrettanto mai risolti, in particolar modo a riguardo del comportamento da adottare con contenuti non testuali: se ho una immagine, mi sposto a destra, ingrandisco finche' non vedo piu' nessuna parte di suddetta immagine, e mi sposto a sinistra, cosa succede? Ho girato dietro l'immagine, e dunque vedo uno spazio bianco? Vedo la stessa immagine zommata? Se creo li' un documento, esso dove andra' a finire? Sotto l'immagine? Dentro l'immagine? Tornando indietro e zommando l'immagine, essa diverra' prima o dopo "trasparente" e mi permettera' di accedere a quello che c'e' sotto o dovro' sempre aggirarla? A tutte queste domande puo' dare una risposta l'eventuale implementatore, e gia' ho visto diverse implementazioni piu' o meno abbozzate di tale meccanismo, ma personalmente credo che almeno per i quesiti qui sopra esposti non esista nessuna soluzione che al tempo stesso permetta una aderenza stretta al paradigma e una sufficiente facilita' di utilizzo: da una parte lo zoom infinito su di una fotografia e' fondamentalmente inutile ed implica di perdere totalmente l'accesso a tutta la parte di spazio che vi sta sotto ma viene richiesto dalla specifica, dall'altra la possibilita' di considerare i contenuti troppo allargati come "saltati" aggiunge una complessita' non da poco alle operazioni di esplorazione dello spazio (di cui alcune parti sono occasionalmente nascoste e pressoche' impossibili da trovare senza premeditazione).
Piu' in generale, ribadisco che per quanto certamente migliore della suddivisione a cartelle anche questa forma spaziale rappresenta pur sempre una gerarchia la cui organizzazione e' lasciata alla cura (o, meglio, alla noncuranza) dell'utente, ed e' dunque destinata a fallire trovando il suo punto critico proprio nell'elemento meno affidabile di tutto il percorso di interazione uomo-macchina. Per quanto mi concerne continuo a preferire di gran lunga la possibilita' di "trovare" piu' che di "cercare", e non sono l'unico.

Maintainr

2010-06-23T03:46:00.004+02:00

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"

2010-06-21T14:02:00.004+02:00

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.

Notifiche Relazionali

2010-06-06T19:44:00.002+02:00

Gia' diverso tempo addietro ebbi una mezza idea per una funzionalita' da implementare (mai, come al solito) all'interno di Lobotomy: una gestione relazionale delle notifiche che occasionalmente si presentano sui nostri monitor. Ne ho scritto in questi giorni una pagina sul wiki del progetto, ma l'originale l'ho steso in italiano e dunque tanto vale pubblicare anche questo sul blog ad uso e consumo di chi non comprende l'inglese maccaronico o vuole ridere della mia pessima traslazione comparando le due versioni.

Le notifiche sono croce e delizia dell'esperienza sul desktop: spesso disturbano ed interrompono il lavoro, ma al contempo ci permettono di intervenire laddove necessario in un dato momento. Un caso di "notifica inevitabile" e' quella che ci avverte in merito ad una nuova sessione di chat aperta da qualcuno dei nostri contatti: essendo questo un mezzo di comunicazione real-time l'attenzione dell'utente e' immediatamente richiesta per mezzo di icone lampeggianti, finestre che appaiono in popup, suoni e quant'altro. Un esempio di "notifica non inevitabile ma consigliata" e' quella che ci avverte dell'arrivo di nuove e-mail: se ne potrebbe fare a meno, non fosse che senza un meccanismo che ci informa in tal senso saremmo portati a consultare compulsivamente la nostra casella di posta per fare a mano quello che il computer farebbe automaticamente.
Assunto dunque che non ci si puo' esimere dalla gestione di notifiche attive nei confronti di particolari eventi che accadono nel nostro ambiente operativo virtuale, si possono sfruttare le potenzialita' di un desktop relazionale per meglio raffinare le attivita' per cui vogliamo essere eventualmente disturbati, ponendo un argine al numero di notifiche inutili e non desiderate.
Lobotomy e' pensato dall'inizio per visualizzare insiemi arbitrari di dati, selezionati con query piu' o meno complesse. Non sarebbe difficile predisporre un sistema di notifiche che si attivino nel momento in cui il result set descritto dalla query cambi, o per la creazione di un nuovo elemento che ricada all'interno della definizione o per la modifica di un elemento esistente.
Le implicazioni sono ben delineate con un semplice esempio: se in un dato momento sto aspettando una mail da parte di un data persona posso selezionare tutte le mail finora ricevute dal contatto ed abilitare la notifica, con un meccanismo standard e sempre uguale per tutti (ad esempio: premendo un pulsante funzione). In tal modo il relativo segnale visivo/sonoro/animato verra' presentato non quando una qualsiasi nuova mail viene ricevuta, facendomi accorrere al client un numero eccessivo di volte solo per scoprire che qualcuno vuol vendermi del Viagra, ma se e solo se arriva una mail che abbia tutti i requisiti che le mail precedentemente visualizzate avevano in comune (in linea di massima, il contatto).
Altri esempi validi possono essere l'arrivo di una richiesta di chat da parte di un determinato insieme di contatti, o la creazione di un nuovo documento all'interno di uno specifico device condiviso, o l'aggiornamento di un preciso feed RSS.
In questo scenario la notifica resterebbe attiva fintantoche' non sia disabilitata esplicitamente, e l'accesso ad un preciso insieme di icone permetterebbe di accedere ai result set monitorati sul momento.

Belli e Brutti

2010-05-31T01:57:00.006+02:00

Poco tempo addietro ho avuto la pessima idea di iniziare a seguire per mezzo dell'apposito feed RSS le mie sottoscrizioni su del.icio.us, per vedere cosa gli altri reputano interessante nei contesti da me scelti. L'idea e' "pessima" perche' provoca una quantita' immensa di traffico (almeno 200 items al giorno, che solo in minima parte posso ovviamente consultare), il feed non viene epurato dai doppioni e dunque spesso e volentieri la consultazione risulta complicata dalla necessita' di scartare a mente i links che sono gia' stati visitati, e quel che e' peggio un singolo tag ("UI") su tre ("UI", "HCI" e "filesystem") ha il monopolio dello stream.
Dati 100 elementi in totale, 90 sono taggati come "UI". Di questi, 85 parlano di design espressamente rivolto al web. Un quarto del totale (25) sono riferimenti a plugins ed estensioni per jQuery. Circa 10 sono elenchi di soluzioni grafiche da cui prendere spunto ed ispirazione, e molte sono anche le liste in stile "i 20 migliori stili CSS" o "i 10 migliori set di icone" (buona parte di queste enumerazioni arrivano da Smashing Magazine). Un'altra fetta importante e' rappresentata da tools e suggerimenti per fare mockups e wireframes, e non faccio mistero di aver iniziato io stesso a prototipare le mie interfacce leggendo piu' e piu' volte al giorno questi temi nel mio feed reader.
Par proprio che ad oggi l'unico contesto apprezzato dai designer sia il web. Un po' per moda ("cloud computing" e' a tutt'ora una buzzword estremamente diffusa ed apprezzata), ma anche (e soprattutto?) perche' HTML, CSS e JavaScript forniscono strumenti immensamente piu' flessibili in termini di formattazione e decorazione che non i classici widgets per lo sviluppo sul desktop, piattaforma in cui l'evoluzione dell'interfaccia utente si e' fermata poco dopo la sua stessa nascita. E laddove si possono facilmente aggiungere animazioni, sfumature, sfondi e inserti di ogni genere, li' trova ristoro il creativo sinora relegato a pulsanti tutti uguali tra loro da incasellare sullo schermo.
Ma la situazione attuale implica uno stallo.
Da una parte, appunto, i migliori designer si lanciano gioiosi sul web, plasmabile a proprio piacimento, bistrattando il classico desktop, e ben pochi si curano piu' dell'aspetto delle applicazioni native, lasciate a marcire in previsione di una imminente (?!) decentralizzazione di ogni attivita' digitale sull'Internet. Dall'altra, nessuno e' realmente pronto per questa migrazione di massa: i produttori di software perche' molti fondamenti tecnici per diversi generi di implementazioni mancano (ad esempio: solo adesso qualcuno inizia a pensare alle notifiche), e gli utenti per l'innata resistenza a cambiamenti radicali. Risultato: il web e' bellissimo ma vuoto di funzioni, il desktop fa tutto ma e' brutto come un debito.
Uscire da questo imbarazzo e' impossibile, se non attendendo pazientemente una risoluzione portata o dall'implementazione degli standard mancanti per una piena funzionalita' della cloud (per sfruttare webcam e microfono via HTML5, ad esempio) o viceversa da una esplosione delle tecnologie grafiche per il desktop (come ad esempio il Clutter Toolkit o la gestione avanzata di CSS in QT, giusto per menzionare quanto disponibile almeno su Linux e che suppongo abbiano analoghi su altri sistemi). La prima opzione e' piu' probabile, considerando gli ampi sforzi che da ogni direzione si muovono verso la Rete, ma non pongo limiti alla provvidenza.
Quando questo accadra', nessuno lo sa.

Pennello alla Mano

2010-05-24T23:34:00.008+02:00

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.

La Mia Radiosveglia

2010-05-08T14:53:00.003+02:00

Io, come credo una buona maggioranza della popolazione dei paesi industrializzati, ho un pessimo rapporto con le sveglie. Ne ho gia' cambiate diverse nella mia vita, ma il problema principale si e' sempre riproposto: dopo un po' di tempo l'udito e tutta la parte cognitiva di riferimento diventa assuefatta, ed il suono ripetitivo e costante o non sortisce effetto alcuno (quando mi sveglio trovo l'interruttore di attivazione ancora sollevato, ovvero l'aggeggio ha suonato indisturbato per almeno 40 minuti per poi cedere nel suo tentativo e tornare al silenzio) oppure stuzzica la corteccia quel tanto che basta per far compiere al mio corpo il gesto meccanico ed automatico di spegnimento senza pero' riuscire a penetrare la nebbia dell'incoscienza onirica. In entrambi i casi, mi sveglio sempre troppo tardi.
Per tali motivi, qualche tempo addietro mi sono procurato una radiosveglia.
La radiosveglia elimina perfettamente il problema dell'abitudine: poiche' ogni giorno alla stessa ora viene trasmessa una canzone diversa, o gli speaker dicono cose diverse con diversi toni, la trappola psicologica permette di tentare il conscio e di farlo uscire dalla sua tana notturna.
O almeno in linea teorica: qualche volta, anche codesto metodo fa cilecca.
Ho meditato sulle motivazioni di tale fallimento, imputandolo dapprima al volume: se troppo basso, il suono risulta inintelligibile e dunque non sufficiente a stimolare la ripresa di coscienza, in modo del tutto analogo al trillo ripetitivo e monotono della sveglia classica; se troppo alto, si rischia di indurre una reazione di shock cui si risponde con un riflesso incondizionato di spegnimento dell'apparecchio. Ma questa tesi non reggeva: in fin dei conti non ho un udito cosi' fine da percepire una differenza di quei pochi decibel di scarto impostabili con l'apposita rotellina, una volta trovato il compromesso giusto non c'e' piu' ragione per cui non debba funzionare.
Ma ieri sera, riponendo l'infernale aggeggio sul comodino, ho forse inteso la reale causa del problema.
Vanno fatte due premesse. La prima e' che cambio relativamente spesso l'orario in cui la sveglia deve operare, in quanto qualche volta devo prendere il treno presto, altre volte posso stare nel letto fino alla tarda mattinata, ed altre volte ancora vado a dormire alle prime luci dell'alba e solo per pudore imposto la sveglia al primo pomeriggio. La seconda e' che la suddetta radiosveglia e' analogica, senza auto-tune, e per selezionare la frequenza desiderata c'e' una manopolina abbastanza sensibile, che richiede una discreta precisione per riuscire a trovare l'angolazione per cui si sente bene una stazione, e che facilmente perde la taratura.
Detto cio', cosa accade? Che quando ripongo l'aggeggio dopo averlo innescato la mano va a cascare proprio sulla rotellina della frequenza, posta sul lato opposto rispetto a me e dunque percepibile solo al tatto (potete immaginare quanto io mi curi delle sensazioni tattili quando mi corico a seguito di una sessione di programmazione...), pertanto e' facile che si perda l'impostazione giusta e, giunta l'ora di suonare, dall'altoparlante esce poco piu' che rumore bianco. Il quale, notoriamente, invece che aiutare a destarsi facilita il rilassamento e non incide sul conscio, lasciandolo placidamente sonnecchiare sul cuscino.
Gia' intuii il fenomeno in passato, tant'e' che quasi senza badarci troppo di quando in quando ho sempre provveduto a controllare e reimpostare le due manopole (volume e frequenza), ma appunto solo ieri sono stato folgorato sulla via di Damasco giungendo alla conclusione qui sopra esposta. Spero che tale consapevolezza mi aiuti a svegliarmi ad orari un poco piu' decenti.
E la prossima radio che acquisto dovra' irrevocabilmente avere l'auto-tune.

Progress Box

2010-04-28T02:07:00.004+02:00

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

L'ovvio che non dovrebbe essere ovvio

2010-04-26T00:03:00.007+02:00

Potrebbe sembrare quasi strano che la maggior parte di critiche e lamentele nei confronti dell'usabilita' generale dei PC arrivino da utenti esperti ed in grado di usare il computer con cognizione di causa, ma a ben guardare e' una cosa ovvia. Il motivo si evince piuttosto chiaramente leggendo ad esempio uno degli ultimi articoli pubblicati in merito, che ha pure riscosso un discreto successo nel giro (stranamente, trattandosi di argomenti sin troppo noti a tutti gli addetti ai lavori): per l'utenza di bassa lega e' normale che il PC non funzioni.
E' normale avere qualche problema installando o disinstallando una applicazione, e' normale che il computer non si avvii piu' da un giorno all'altro o si spenga all'improvviso, e' normale non riuscire ad aprire un file in qualche formato stravagante, e' normale prendersi un virus, e' normale non capire come si utilizza un dato software. Nel gergo informatico dei non-informatici, "computer" e' sinonimo di "errore".
Chi paga le spese di suddetti capricci digitali sono per l'appunto coloro che hanno maggiore dimestichezza con la tecnologia informatica, che sanno come risolvere i propri problemi e, per estensione, vengono puntualmente interpellati da amici, parenti e conoscenti che incappano in qualche banale condizione di malfunzionamento affinche' risolvano anche i loro. Tutti, ma proprio tutti gli smanettoni hanno carrettate di aneddoti ed esperienze di tal fatta. E' un fenomeno talmente comune e radicato da essersi meritato pure una maglietta dedicata su ThinkGeek. Qualsiasi giovanotto col pallino per i PC e' ben conscio dei pericoli che rischia, ed evita accuratamente di dare la mail o peggio il numero di telefono a chiunque gli dica "Ah, allora tu sei capace di aggiustare i computer!" sapendo che se il suo contatto finisse nella mani sbagliate sarebbe continuamente tirato in ballo per sistemare, aggiustare, configurare e spiegare i mille e piu' difetti dei sistemi moderni.
Ma il fatto che il PC sia "rotto di default" non e' per niente normale.
Tanenbaum sostiene da decenni che l'esempio di riferimento dei sistemi operativi dovrebbe essere il televisore, ovvero un elettrodomestico che funziona continuativamente dal momento in cui si attacca la spina elettrica a quando i suoi componenti interni cedono strutturalmente per usura. Raskin sosteneva la teoria per cui ogni dispositivo elettronico dovrebbe fare una singola cosa (ad esempio: un cellulare dovrebbe solo permettere di telefonare e ricevere telefonate) ed essere dotato solo dei tasti e del software necessari a fare quella cosa, e null'altro, per arginare e limitare al massimo i rischi di errore da parte dell'utente. Nessuna di queste visioni e' mai stata applicata nel mondo reale, o comunque si e' mai diffusa, se non forse in parte.
Forse perche' quella di realizzare apparati general purpose, e per questo necessariamente complessi (e bacati), e' la norma sia per i produttori che per i consumatori. Forse perche' ben pochi hanno mai realmente esplorato le potenzialita' commerciali di questo genere di soluzioni, e nessuno ha voglia di provarci. Forse perche' il fatto di tenere in ostaggio l'utenza inconsapevole permette di generare fior di introiti in servizi di assistenza e supporto, dunque non e' economicamente conveniente farli campare felici e sereni. Forse perche' a priori si preferisce spendere meno per comprare un singolo dispositivo che faccia tutto che non tanti dispositivi che facciano cose specifiche (senza considerare minimamente il costo successivo del software, che pareggerebbe i conti), ed il risparmio immediato oscura il risparmio in termini di tempo e scocciature dopo.
Si assistera' mai ad una inversione di tendenza, dettata dal buon senso anziche' dagli istinti di conservazione monetaria? Per conto mio credo che prima o dopo dovro' procurarmi una qualche schedina "SoC", buttarci sopra un kernel ed il software essenziale per disegnare qualcosa sullo schermo, e fare qualche esperimento...

Paura e Delirio nel Pannello Configurazioni

2010-04-20T22:05:00.002+02:00

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

User-proof

2010-04-18T02:05:00.006+02:00

Da molto tempo esiste l'ironico motto secondo cui i developers Gnome saranno soddisfatti della loro opera solo quando l'intera interfaccia del sistema sara' ridotta ad un tasto solo. Ma l'altro giorno sono incappato per caso in una applicazione che fa davvero proprio il concetto: la schermata principale di Déjà-Dup presenta infatti due soli grossi pulsanti, "Restore" e "Backup".
Chiaramente esiste anche un pannellino per selezionare cosa backuppare e dove, o automatizzare la procedura in modo da dimenticarsi completamente della sua esistenza e lasciare che faccia da solo (se non e' automaticamente attivato, il backup non serve a niente), ma mi ha colpito la scelta estrema nel design del pannello primario. In fin dei conti una volta manipolati i diversi parametri non c'e' ragione di metterli continuamente sotto al naso all'utente, che di volta in volta e' interessato solo a sincronizzare i suoi dati locali con la cartella remota, dunque mi sembra piu' che azzeccata.
E le accortezze in termini di usabilita' non si limitano a questo. Tra i commenti pubblicati su OSSBlog, da cui appunto ho appreso l'esistenza di questo programmillo, qualcuno lamenta la limitazione di poter selezionare un solo insieme di cartelle da duplicare in un solo repository distaccato, ma anche in questo caso mi trovo a dar ragione al developer: il target del software e' chiaramente l'utenza domestica, che non ha particolari esigenze ed anzi ancora grazie se si premura di effettuare una copia di salvataggio dei propri dati, dunque inutile e' fornirgli un necessariamente complesso sistema per incrociare cartelle su cartelle. Se l'utilizzatore dovesse mai abbisognare di tale genere di funzionalita', potra' trovare una risposta in una qualsiasi tra le altre dozzine di applicazioni esistenti nel settore senza necessariamente rendere piu' difficile la vita a chi vuole campare lieto e sereno con una cartella sola.
In breve: a parte il nome pieno di accenti ritengo Déjà-Dup un esempio assoluto di pulizia, facilita' di utilizzo e design, una perla rara in un oceano di applicazioni troppo spesso raffazzonate o strabordanti di features inutili. Gli utenti necessitano urgentemente di piu' software fatto cosi'.

Faldoni VS Database

2010-04-16T23:51:00.005+02:00

L'altro giorno mi sono recato con un amico presso un piccolo produttore agricolo con lo scopo (che non intendo qui approfondire nel dettaglio) di appurare come utilizzasse lui il computer nello svolgimento delle sue pratiche burocratiche e produttive. Ne e' emerso uno scenario perfettamente prevedibile e scontato, ma non per questo meno disarmante: il PC viene usato pressoche' esclusivamente come macchina da scrivere, per compilare bolle e fatture da stampare e maneggiare poi analogicamente (= su carta).
L'apoteosi dello sconforto l'ho raggiunta quando il suddetto agricoltore (lui, come lo potrebbe fare la stragrande maggioranza dell'utenza informatica di basso livello odierna) ha apertamente ammesso che il computer, massima espressione della scienza tecnologica nella sua esistenza rurale, e' un problema inevitabile piu' che una soluzione desiderabile: difficile da usare, incomprensibile, caotico, con l'unico pregio che con un paio di copia&incolla si velocizza qualche sporadica operazione nella compilazione dei moduli che se altrimenti fatta a mano richiederebbe piu' tempo. Mentre diceva cio', io guardavo il vicino armadio carico di faldoni e carte accumulate dopo essere uscite dalla stampante del vituperato marchingegno digitale, certamente perche' il personaggio riesce meglio a scartabellare e cercare cio' che gli serve su supporto fisico anziche' tra le cartelle virtuali del filesystem.
Del resto, neppure mi sento di dargli tutti i torti: il computer ha un costo, cosiccome la licenza di Excel installata sopra (suppongo sia stato originale, acquistato in bundle con la macchina numerosi anni addietro, e se anche fosse stato pirata glielo ha installato qualche pseudo tecnico in qualche negozietto di informatica facendosi comunque pagare per il disturbo), e tale applicativo viene usato per compiti ben piu' complessi ed avanzati che non quelli per cui e' stato ideato. L'acquisto di un software specifico per la sua attivita' costerebbe 3000 euri (e non e' una stima: il programma esiste davvero e gli e' stato offerto esattamente a quella cifra), e per esperienza gia' so che si tratterebbe comunque di un accrocchio Visual Basic + Access messo in piedi alla meno peggio con lo scopo esplicito dell'azienda produttrice di trarre profitto ulteriore con i corsi per sommariamente imparare ad usarlo e l'assistenza. Pertanto ci si arrangia con quel che si ha, ovvero qualche programma realizzato da vendors diversi tra loro nient'affatto integrati, con interfacce diverse e carichi di features introdotte per giustificare le nuove release, e appena possibile si ricorre al tasto "Stampa" per portare le informazioni importanti fuori dal ronzante scatolone di plastica e alluminio.
Non oso neppure immaginare cosa la piu' scarsa e umile tecnologia digitale oggi esistente potrebbe realmente fare per quest'uomo: i dati, se immessi in un database, potrebbero essere spulciati e tra loro intersecati con dettaglio estremo in pochi secondi; le anagrafiche di fornitori e clienti, se formattate in hCard e gestite direttamente dagli interessati, potrebbero essere pescate dall'Internet ed aggiornate automaticamente, e istantaneamente accessibili digitando tre caratteri del nome; i documenti potrebbero calcolarsi per conto proprio quantita' totali, prezzi totali, IVA e altri parametri burocratici partendo da pochi valori relativi alla merce ricevuta o da consegnare; gli stessi totali potrebbero essere trasmessi al commercialista in formato digitale, e questo potrebbe a sua volta importarli nel suo proprio programma per farci quel che deve farci; i pagamenti, se trasferiti per via telematica, sarebbero usati seduta stante per computare bilanci ed introiti (o al contrario innescare sollecitazioni automatiche se non arrivati in tempo). Senza parlare del risparmio di carta, inchiostro e spazio.
Se nell'Anno Domini 2010 tutte le attivita' produttive e commerciali ancora non hanno trovato nella tecnologia un valido ed appropriato supporto la causa non e' solo delle ovvie resistenze riscontrate presso il grande pubblico nei confronti delle novita' ma anche e soprattutto da imputare a coloro che dovrebbero provvedere alla messa in opera di questi semplici e talvolta persino banali (per un tecnico, intendo) strumenti, e che speculano sulla scarsa consapevolezza e dimestichezza dei propri clienti per spremere ogni singolo centesimo dalla loro ingenuita'.
Le cose possono cambiare. Devono cambiare. Poche righe di codice, se stese con criterio, possono allo stesso tempo ridurre il tempo (e dunque il costo) necessario a svolgere una operazione, aiutare a massimizzare i profitti incentivando particolari scambi monetari, e salvare un albero destinato a diventare carta da stampa. E' venuta l'ora di iniziare a scriverle.

Vintage Computing

2010-04-07T22:31:00.003+02:00

Oramai ogni tre per due si annuncia la morte del PC desktop, pronto per essere assassinato dalla piu' nuova, promettente e modaiola tecnologia: una volta incombe il web desktop ed il cloud computing, una volta avanza a grandi passi il mobile, una volta l'iPad sembra destinato a stravolgere la vita di ogni essere sul pianeta. L'ultimo articolo letto in merito e' questo qui, che definisce "legacy" (= obsoleto) il desktop.
Esistono pero' almeno due falle nella logica di questo genere di conclamazioni.
La prima e' che tutti assumono che gli utenti si dividano in due categorie: chi produce e chi consuma. Chi produce (contenuti, documenti, codice...) abbisogna di tastiere fisiche, grossi monitor e software di editing audio e video performante, chi consuma (contenuti, documenti, applicazioni...) puo' largamente accontentarsi di un monitor touchscreen ed una tastierina virtuale per i pochi commenti che puo' al massimo scrivere su Facebook. Ma, per fortuna o purtroppo, il mondo non e' bianco e nero. Anche l'utente piu' negletto e passivo della Rete spesso scrive a lungo e relativamente lunghi testi, prova ne e' la capillare diffusione di Messenger e altri client di instant messaging con cui abitualmente alla sera gli studentelli spettegolano sui loro compagni e gli adulti spettegolano sui colleghi di ufficio. La chat e' una delle attivita' piu' comune per ogni categoria di cittadino digitale, gli smanettoni complottano su IRC ed i profani discutono del piu' e del meno su GTalk, dunque per quanto strano possa sembrare tutti abbisognano di una bella tastiera su cui scrivere i propri pensieri a qualcun'altro, da li' non si scappa. Inoltre, moltissime sono le persone che, pur capendone poco, col computer ci devono lavorare: tanto per dirne una chiunque abbia una attivita' commerciale o produttiva deve gestire fatture e rendicontazioni, e sebbene tale genere di applicazioni potrebbe benissimo essere adattato per i devices moderni (il tablet ad esempio sarebbe perfetto per tenere allineato un magazzino con la propria base dati) il traguardo prevede una congiunzione astrale tra offerta da parte del mercato, richiesta da parte dell'utenza, e disponibilita' della piattaforma hardware.
Cio' introduce alla seconda mancanza del ragionamento secondo cui il desktop debba perire a breve, ovvero l'innata resistenza a qualsiasi genere di innovazione da parte del grosso mercato consumer. Credo che la diffusione di Internet Explorer 6, browser risalente a 9 anni fa' e che in marzo 2010 deteneva il 9% di share, sia constatazione sufficiente per confermare la tesi. Se il pubblico oppone cotale ritrosia nell'effettuare un upgrade software, pressoche' indolore e gratuito, per quale ragione dovrebbe cambiare in modo radicale le sue abitudini andando pure a spendere qualche centinaio di euri per un nuovo arnese elettronico? Molto meglio tenersi quel che si ha il piu' a lungo possibile. E di conseguenza continuare ad istigare il mercato a proporre soluzioni per quello, anziche' intraprendere mosse azzardate su un terreno popolato in larga parte da entusiasti di tecnologia e poco altro. Certamente i developers web, iPhone, iPad, Android e compagnia cantante abbondano, ma ne passera' di tempo prima che provvedano alternative valide a tutto quello che e' stato sinora realizzato sul desktop, magari da qualche cane in Visual Basic e Access, che non solo facciano le stesse cose ma pure meglio (si' da giustificare il costo della migrazione), e fino ad allora le possibilita' di convincere qualcuno ad abbandonare il sano vecchio scatolone sibilante sono nulle.
In quanto freesoftware advocate so bene quante e quali sono le difficolta' che si parano dinnanzi all'adozione di qualsiasi strumento anche solo di poco diverso rispetto a quanto gia' familiare e consueto, indipendentemente dalla facilita', comodita' e bellezza dello stesso. E, per quanto sostenitore di quasi ogni novita' sensata che spunti sull'orizzonte di Slashdot, mi guardo bene dal dare credito a ogni affermazione eccessivamente entusiasta sull'imminenza di un cambiamento di paradigma. In qualita' di nerd sarei ben lieto di vedere la gente per strada leggere la versione digitale del quotidiano sul proprio tablet ("Il futuro e' adesso!"), ma in qualita' di osservatore so che questo scenario e' ben lungi a venire, checche' ne dicano i santoni del marketing.

Building Blocks

2010-03-28T18:40:00.005+02:00

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.

Back Online

2010-03-23T18:38:00.005+01:00

La visita di un paio di tecnici Telecom (per conto di Infostrada), un cavo telefonico acquistato al volo (non riuscendo piu' a trovare quello che certamente tengo da qualche parte), e da circa un'ora ho - nuovamente - l'ADSL.
Anche un anno fa' l'avevo, ma Tin.it, il mio provider, e' stato chiuso. Sono passato ad una connessione 3G Vodafone, traballante e con banda minima, un mese fa' si sono lamentati che occupavo troppa banda, e dietro minaccia di restare privo di connettivita' ho dunque deciso di ripassare all'ADSL a costo di dover pagare la disattivazione quando comprero' casa e mi trasferiro' da qui (progetto in attesa da molto tempo, comunque...).
Sembra assurdo che un nerd del mio calibro sia riuscito a sopravvivere tanto a lungo senza connettivita' fissa, eppure ci sono riuscito. Ed ho imparato ad apprezzare il valore di questo bene cosi' prezioso.
Per quanto da molti considerata banale, la disponibilita' di una connessione in banda larga e non NATtata (dunque, raggiungibile dall'esterno) apre le porte ad una infinita' di possibilita', tanto che non so da che parte cominciare a recuperare il tempo perso sinora. Giusto per elencare le prime attivita' che mi vengono in mente, da domani potro':

far aggiornare automaticamente opengnomedesktop.org . Da quando ho messo in piedi il sito ho avuto poche occasioni di allinearne i contenuti con quelli di GnomeLook, in quando avrei dovuto farlo a mano di quando in quando (scomodo), o far eseguire periodicamente uno script (impossibile, gia' che non tenevo alcun PC perennemente connesso per non fondere la chiavetta), o eseguire la procedura dal VPS su cui e' hostato lobotomy-project.org (impossibile, in quanto e' necessario avere X in esecuzione per generare le thumbnails dei temi)
sperimentare su PubSub. Ne ho aggiunto una implementazione client in libgrss, ma non ho mai avuto modo di provarla a sufficienza a causa del fatto che la connessione Vodafone era NATtata. La disponibilita' di un feed reader in grado di supportare PubSub permetterebbe di avere news quasi in tempo reale sul proprio desktop, feature non certo vitale per le notizie di tutti i giorni ma che puo' avere piu' di una applicazione
sviluppare comodamente applicazioni che necessitano di grandi moli di informazioni prelevate dall'Internet, come ad esempio quella descritta qui ed ora in fase di progettazione con la complicita' dell'amico Seven. Il fatto di tenere in casa la macchina che scarica, analizza e categorizza i dati dovrebbe accellerare lo sviluppo di un prototipo da lasciare sul VPS una volta stabilizzato
far scaricare automaticamente il podcast del giornale radio di Radio1 e riprodurlo all'ora in cui dovrei svegliarmi. Anche in questo caso e' un progetto che non l'ho mai potuto realizzare a causa dell'impossibilita' di tenere un PC sempre connesso, ma finalmente potro' aprire i miei occhietti al mattino ascoltando le notizie fresche e rotolandomi tra le lenzuola un altro po'

Mi e' mancata tanto, l'ADSL...

La Sindrome della Prima Volta

2010-03-07T20:45:00.003+01:00

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.

FOSDEM 2010: the Tech Side

2010-02-28T02:24:00.004+01:00

[Premessa: questo post narra i contenuti tecnici visionati e sperimentati durante la mia esperienza al FOSDEM 2010, per una descrizione degli aspetti sociali si veda l'apposito articolo sull'altro mio blog.]

Il presupposto e' uno: in una manifestazione creata e vissuta completamente dalla community open, all'interno della quale l'informazione circola a priori senza vincoli, non ci si puo' aspettare di recepire qualcosa che non sia gia' stato letto in un blog o in un aggregatore di notizie. Jobs organizza i suoi keynotes badando di generare prima un grande hype senza pero' sbottonarsi troppo sui contenuti da svelare sul palco (cfr. iPad), quelli di Google sembrano preferire le dichiarazioni a sorpresa (cfr. Wave), ma laddove non ci sia qualcuno che impone il silenzio stampa per esigenze di marketing ed immagine tutti sanno tutto di tutti. Per questo motivo al FOSDEM, il piu' grande meeting di sviluppatori open in Europa, non ho visto assolutamente nulla di nuovo.
Relativamente pochi i talks che ho seguito, anche a causa della disposizione completamente randomica delle sale e della difficolta' a raggiungere i pochi appuntamenti interessanti (nel mio caso, quelli su XMPP) prima che le aule si riempissero e venissero chiuse.
Tra questi, da menzionare sono il progetto OpenIntents, framework per piattaforma Android che esaspera la nozione di "trigger" tentando di spezzare il workflow di qualunque tasks eseguito dall'utente in una serie di passi eseguiti da componenti dedicati ed intercambiabili da miscelare in diversi modi, e la presentazione dell'equivalente di ChromeExperiments da parte del team Mozilla: una raccolta di arzigogolati quanto inutili hacks che portano al limite le piu' recenti tecnologie per lo sviluppo web.
Con grande sorpresa (almeno da parte mia) la devroom dedicata a Gnome ha ospitato solo superficiali e poco stimolanti talks. Niente su Zeitgeist, niente su Gnome Shell, niente su GTK+ 3.0, niente su GIR, poco su Tracker (parte del talk l'ho tenuto io!), insomma niente sulle reali novita' del settore. E' presumibile che i relatori abbiano preferito tenersi questi argomenti per il prossimo GUADEC, ma a parer mio avrebbero fatto molto meglio ad approfittare della visibilita' offerta verso un pubblico un po' piu' eterogeneo che non gli specifici addetti ai lavori che si presenteranno a luglio in Olanda.
Nota a margine ed in semi-anteprima (nel senso che nel giro sono gia' tutti consci della cosa, ma e' bene diffonderla all'esterno): Rob Taylor, mio co-relatore, ha gia' in progetto da qualche tempo una sorta di contest per il miglior hack costruito su Tracker e dovrebbe annunciarlo sul suo blog. La scadenza dovrebbe quantomeno imminente (verso la meta' di marzo), ma magari qualcuno ha una bella idea che richiede poco lavoro e produce risultati immediati. Premio: un Nexus One. Direi che il gioco val la candela.
Trascendendo dalle applicazioni software, curiosa la RepRap, di cui era presente un esemplare: gia' l'idea di una "stampante 3D" e' stravagante, se poi e' pure open e lowcost diventa meravigliosa.
Ora non mi resta che attendere la pubblicazione dei video degli speech che mi sarebbero stati congeniali ma che, come detto, per un motivo o per l'altro mi sono perso. Ed iniziare a ponderare qualcosa di simpatico da far vedere alla prossima edizione.

Uno Scalpello per l'Informazione

2010-01-31T20:11:00.003+01:00

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!

1000000 Ways to Configure

2010-01-30T00:27:00.004+01:00

Per una volta, mi trovo a dar ragione ad Aaron Seigo: codesto articolo non sta ne' in cielo ne' in terra.

L'autore di quest'ultimo mette in discussione i miglioramenti in termini di usabilita' del progetto KDE4, completa riscrittura e revisione del ben noto K Desktop Environment, usando come (infelice) argomentazione la decimazione delle proprieta' configurabili in gwenview, image viewer incluso appunto in tale ambiente. Credo che di per se' questo stringatissimo riassunto basti gia' a farsi una idea dell'inconsistenza della posizione assunta, secondo cui per induzione un software "usabile" e' quello che mette l'utente in condizione di rifinire ogni singolo comportamento dell'applicazione anche laddove tale comportamento sia del tutto secondario e minimale, anziche' fare quel che s'ha da fare e basta. Anche volendo condividere l'opinione generale in merito alla scarsa maneggevolezza ed intuitivita' di KDE4 (di cui recentemente ad esempio mi e' capitato di metter mano all'edizione dedicata ai netbooks: totalmente incomprensibile), comunque viene qui presentata nel peggiore dei modi ed assumendo quello che forse e' il meno rappresentativo dei casi.

Contrariamente a quanto asserito, gli sviluppatori di gwenview meriterebbero un premio per aver rimosso l'armageddon di pulsantini, opzioncine, caselline e iconcine che era il loro pannello di configurazione. E che, non dubito, sono stati via via aggiunti solo ed esclusivamente per la pigrizia del momento nell'individuare un comportamento realmente valido e delegando al disgraziato utilizzatore l'onere di prendere una decisione. Il fatto che l'applicazione ne risulti meno configurabile e personalizzabile, al limite dell'estremo (e della pazzia), e' del tutto irrilevante ai fini pratici: la fascia di utenti disposti a passare un pomeriggio a tarare manualmente la dimensione della cache, o mettersi col righello a scegliere l'esatta larghezza dello spazio vuoto tra una immagine e l'altra, e' infinitesimale o nulla rispetto alla quantita' di persone che desiderano avere un programma che gli permetta di navigare tra le proprie immagini senza patemi. Quei quattro power-user in croce che volevano essere in grado di selezionare ogni minimo dettaglio si sentono "frustrati" di queste nuove limitazioni? Ebbene: il loro sacrificio e' compensato dalla mancata frustrazione di tutti gli altri, la stragrande maggioranza, che facilmente si sarebbero persi in quel marasma di quisquillie gustosamente tecniche rinunciando a fare quello che volevano. E poi i suddetti quattro hanno pur sempre il codice sorgente a disposizione: con quello a disposizione, ed un compilatore, sono liberissimi di cambiare ancor piu' impostazioni di quante siano immaginabili all'interno di un pannello grafico.

Pertanto: un plauso al team gwenview e di tutti gli altri sotto-progetti KDE che hanno approfittato o stanno approfittando della migrazione da 3 a 4 per rimuovere quanti piu' orpelli e facezie possibili tra quelle che si sono accumulate col passare del tempo nelle loro creazioni, e che con buon senso hanno deciso di pensare piu' ai propri utenti che non all'assecondamento del proprio ego programmatorio.

Stay Focus

2010-01-22T02:54:00.006+01:00

"Stay focus" e' una espressione spesso usata dal mio attuale project manager in Itsme. Mi piace, nella sua infinita semplicita' (e nella mia personale interpretazione) esprime bene la necessita' di mantenere l'attenzione entro un dato contesto e su determinati obiettivi. Proprio a me, che quasi continuamente zompo tra un blocco di codice e l'altro senza soluzione di continuita'...

La citazione mi e' tornata alla mente leggendo questo articolo, ennesima colonna da opinionista sul gossip nerd del momento, l'oramai imminente iSlate. Al di la' delle speculazioni dell'autore, che tendenzialmente posso anche approvare ma che in mancanza di un prodotto concreto da commentare risultano sterili chiacchere da bar, i primi paragrafi sono assai interessanti. Un po' per i contenuti, un po' per gli stimoli: in essi viene menzionata la figura di Jef Raskin, mia inesauribile fonte di ispirazione diretta ed indiretta, e la sua posizione radicale nei confronti dell'usabilita' degli apparati tecnologici.

Consiglio la lettura del pezzo ma non commento qui nel dettaglio ne' la prima ne' la seconda parte: basti sapere che rileggere tali spunti e tali prospettive e' stato sufficiente per riportarmi alla mente i sopiti ma mai defunti propositi di applicarmi in prima persona, nel mio piccolo, per rendere piu' accessibili e a misura d'uomo gli strumenti offerti dal progresso.

Proprio ieri sera ho partecipato ad una riunioncina con gli altri personaggi coinvolti nel progetto GASdotto, per fare il punto dopo la pausa imposta dalle vacanze natalizie. Pare che gli attuali utilizzatori, in tutto circa un centinaio, siano entusiasti della facilita' d'uso di questa applicazione, e sebbene ci sia ancora parecchio da fare sia in termini operativi che estetici ci siamo spinti a delineare le funzionalita' da includere nella prossima versione 2.0 . Alla luce degli istinti suscitati e risuscitati dalla summenzionata lettura, mi vengono i brividi alla schiena ripensando alla quantita' di pulsantini e opzioncine che tra una birra ed un po' di vino sono stati idealmente introdotti per azioni tutto sommato minime ed oziose, che potrebbero forse risultare comode per chi oramai avvezzo all'impianto ma risulterebbero totalmente incomprensibili a chi si avvicina per la prima volta o anche ad un utente gia' preparato che (ovviamente) non si trova dinnanzi a queste schermate tutti i giorni e legittimamente puo' scordarsi il significato di un determinato quadratino colorato sul monitor. Nei prossimi mesi dovro' studiare qualche soluzione per automatizzare l'automatizzabile, celare il celabile, e svelare alla vista qualcosa solo quanto realmente necessario ed indispensabile. Onde evitare il classico "effetto acccumulo" per cui quasi inevitabilmente ogni nuova versione di qualsiasi software stratifica qualche orpello, qualche ammenicolo, qualche cineseria in piu' rendendo il tutto a lungo andare una accozzaglia indefinita e pesante, sia da vedere che da usare.

Lo stesso vale per ogni altro progetto attualmente in corso, che come al solito sono tanti - e anche troppi -: ad esempio negli ultimi giorni ho giocato un pochino con jQuery con la mira di metter su una sorta di servizio web, e non nego di essermi fatto prendere la mano dalla semplicita' con cui e' possibile aggiungere effetti ed animazioni estremamente cool ma dalla assai scarsa utilita'. Tale genere di garbugli possono sedurre l'occhio la prima volta, la seconda, alla terza diventano una perdita di tempo ed un carico in piu' per il processore.

Insomma: mi rendo conto di aver ultimamente un po' lasciato da parte lo scopo globale, il "focus" appunto, e di essermi fatto coinvolgere un po' dalla immediatezza e dalla spettacolarita' degli strumenti programmatori oggi a disposizione ed un po' dalla necessita' di far le cose magari non proprio sempre in modo ponderato - e di conseguenza male. Dovro' fare un esame di coscienza e stare piu' accorto, rinunciare a qualche evoluzione ed immolarmi maggiormente alla linearita', tenendo sempre ben presente cosa c'e' da fare nel suo insieme.

Stay focus. Always.

127.0.0.1 sweet 127.0.0.1

2010-01-03T03:50:00.004+01:00

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

2009-12-13T01:51:00.004+01:00

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.

Il Nome della Cosa

2009-11-25T01:06:00.006+01:00

Qualche tempo fa' in Itsme sono passati alcuni ospiti: come sempre abbiamo fatto la nostra presentazione del progetto, come sempre ci sono state domande tecniche e meno tecniche, e tra tutte le osservazioni emerse una in particolare mi ha ispirato il qui presente post. In realta' si tratta di un commento piu' e piu' volte sollevato in merito all'opera in corso, carpito in circostanze piu' o meno ufficiali e che suona come "Itsme e' basato su Linux, ma Linux e' difficile da usare".
Sorvolando sulle obiezioni di natura culturale e pedagogica, per cui un meccanismo complesso come un intero sistema operativo non puo' essere a priori "facile" o "difficile" ma necessariamente richieste un periodo di addestramento ed un disadattamento all'attivita' su altre piattaforme analoghe rendendo di fatto "difficile" tutto quello che non si e' usato fino al giorno prima, cio' che mi perplime e' il pregiudizio di fondo nei confronti di Linux.
Per quanto nel corso delle dimostrazioni Itsme si parli dell'interfaccia che stiamo completamente ri-disegnando e re-implementando per adattarsi alla metafora di riferimento, cosiccome stiamo ri-disegnando e re-implementando gli automatismi di fondo che permettono la configurazione, "Linux e' difficile". Tale assioma e' assunto indipendentemente dalla modalita' grafica con cui il sistema si presenta, degli strumenti di tuning messi a disposizione, dei wizards automatici gia' previsti per sopperire ad eventuali mancanze ed integrare componenti gia' noti nel piano: "Linux e' difficile".
Eppure a me non pare che nessuno si sia mai grattato il capo in modo imbarazzato usando un cellulare Motorola, spedendo richieste a Google, o anche facendo un biglietto della metropolitana qui a Torino. Questo perche' i tre fruitori di cui sopra, e buona parte di tutti gli altri fornitori di hardware e servizi Linux-based, dell'amato sistema operativo utilizzano la tecnologia di base ed hanno personalizzato per conto proprio la parte con cui l'utente interagisce, rendendo piu' o meno "facile" l'uso dell'apparato a seconda del fine predestinato. Ne' piu' ne' meno di quanto fatto da Apple con MacOS X, partendo da una base BSD (che di per se' puo' essere considerato ancor piu' ostico che Linux stesso) e costruendoci sopra il proprio stack applicativo, rinomato come il piu' user-friendly sul mercato: sarebbe sensato affermare che MacOS e' "difficile" da usare perche' ha nel kernel lo stesso scheduler di BSD, laddove l'utilizzatore non sospetta neppure l'esistenza di un'arnese chiamato "scheduler"?
E se anche fosse vero che, diciamo, una Ubuntu e' meno usabile di un Windows (argomento discutibile ed opinabile), e' altrettanto vero che godendo di una netta separazione tra i layer operativi Linux si presta molto di piu' ad una drastica personalizzazione dell'insieme e da esso e' molto piu' facile cavare qualcosa di realmente nuovo e pratico mantendendo intonse le porzioni di basso livello (gestione dei devices, librerie software, toolkits grafici, alcuni applicativi) e stravolgendo il resto, a propria discrezione e secondo la propria necessita'. Stando alla mia esperienza sinora ho lavorato su un apparato embedded per telecomunicazioni ed una workstation desktop, e su entrambi il software di basso livello era lo stesso, ovvero un kernel e qualche libreria.
Stat Linux pristina nomine, nomina nuda tenemus.

Hands on Google Wave

2009-10-19T18:22:00.005+02:00

In merito a Google Wave ho gia' fatto un commento (negativo) ai tempi del suo annuncio e della pubblicazione del lungo video di presentazione. Ora che grazie ad un amico ho ottenuto un invito ed ho potuto provarlo con mano, aggiorno il commento e lo rendo ancora piu' negativo.
L'intera Internet, o quantomeno coloro che gia' hanno ottenuto il modo per fare qualche prova col suddetto prodotto, si chiede a cosa serva: non e' uno tool di instant messaging perche' i messaggi sono disposti in threads, non e' un forum perche' e' realtime, non e' uno strumento di editing collaborativo perche' ha una struttura predefinita. Insomma non e' nulla di gia' noto, ma al tempo stesso prende tutti i difetti dei canali menzionati sopra: e' lento e macchinoso come un forum e per pubblicare un nuovo messaggio c'e' da cliccare qua e la', essendo realtime non e' banale tenere una conversazione con qualcuno in quanto viene spontaneo rispondere prima che l'altro abbia finito di esprimersi completamente, ed ha un modello gerarchico dunque non puo' essere usato per scopi "generici" come un foglio su Google Docs.
A seguito del test drive, i miei dubbi diventano certezze: questa baracca non serve a niente. In molti si scervellano per cercare di dargli un significato, una dimensione, un ruolo, ma credo che sforzarsi di assegnare un titolo ad un prodotto solo perche' proviene da una fonte (piu' o meno) amata come Google sia un eccesso. Ammetto di non aver letto proprio tutte le recensioni quotidianamente proposte, ma tra tutte quella che maggiormente mi ha colpito e' questa qui: l'autore sostiene che l'utente piu' indicato per Wave sia quello che in genere e' il peggior consumatore di tecnologia informatica, ovvero l'utente business/corporate, quello che ancora non ha scoperto l'IM o gli altri ammenicoli collaborativi online e a tutt'oggi scambia coi suoi pari via mail gli stessi documenti centinaia di volte per apportare modifiche e correzioni. Ma io mi domando e chiedo: se questo "utente tipo" e' talmente radicato alle sue abitudini da non aver manco mai pensato ad aprirsi il piu' stupido account MSN (e figuriamoci un account su Zoho), come si spera che da un giorno all'altro inizi ad usare Wave???
Da notare poi che codeste mie critiche si limitano al puro scopo funzionale dell'applicazione, in quanto se dovessi puntualizzare anche sul versante tecnico non finirei il post entro oggi: l'interfaccia e' ridondante, non fa niente eppure ci sono troppi tasti e pulsanti e icone (quasi che lo scopo fosse quello di dimostrare la fighettosita' di una applicazione realizzata con GWT anziche' impostare un frontend chiaro ed intuitivo), l'organizzazione dei contenuti e' abbozzata, innumerevoli i difettucci legati alle notifiche ed all'allineamento dei messaggi nonche' le incoerenze dell'interazione. Cui si sommano le limitazioni contingenti di ogni applicazione web, che essendo vincolate all'interno del browser non hanno modo di interagire col window manager e dunque portare all'attenzione dell'utente notifiche e segnalazioni.
Se mai Wave avra' un qualche riscontro e sara' usato da qualcuno il merito sara' certamente piu' della campagna di marketing e dell'hype sorto intorno a codesto oggetto che non per un reale valore operativo. Chi ancora non ha un invito non se ne disperi troppo, non si sta perdendo niente e puo' tranquillamente attendere l'apertura del servizio a tutti.
Anche oggi, l'Internet resta la stessa.

Vapore Multitouch

2009-10-13T19:26:00.005+02:00

Risale a qualche settimana fa' il meme del tablet targato Microsoft, chiamato Courier. Molti hanno detto la propria, io (sebbene con un poco di ritardo) dico la mia: secondo me, e' una bufala.
Le motivazioni di un gesto di tal fatta sono scontate: rosicchiare un poco della attenzione e della visibilita' offerte sull'argomento "tablet" a seguito dei reiterati rumors in merito ad un nuovo prodotto Apple, destinato (vuoi per tendenza modaiola, vuoi per effettivo grado innovativo tradizionalmente iniettato sul mercato dall'azienda di Cupertino) a ridare nuova vita ad un settore esistente da anni ma che non ha mai scalfito l'interesse del grande pubblico consumer.
Ma la mia affermazione non e' fondata solo sulla pura intuizione (oltretutto neanche tanto originale) e sul pregiudizio nei confronti di Microsoft, ma su riflessioni indotte dalla visione del video di introduzione al suddetto Courier. Osservando quei quattro minuti di filmato, spacciati per tech demo dell'imminente prodotto, a me sembra abbastanza evidente che il modello di interazione e' cosi' artefatto da non poter essere reale: comportamenti grafici diversi, ovviamente sempre i piu' adatti alla regia, si ottengono a seguito delle medesime operazioni dell'utente, ed il pannello giallo che ogni tanto appare (e non ho neanche capito a cosa serva...) sembra dotato di una propria coscienza tanto da apparire solo quando scenicamente opportuno. Per non parlare delle barre in cui si scrive a mano per raggiungere un dato contenuto (bella forza immettere l'URL "afi.com" nel browser, ma come ce lo faccio stare "slashdot.org"?), le tabelline che magicamente vengono estratte e trascinate senza manco sapere qual'e' la porzione di interesse per l'utente, il tratto dello stilo che diventa testo o evidenziatura gialla in modo totalmente arbitrario...
Insomma, piu' che un prototipo di interazione a me sembra un film di azione, in cui i cattivi sparano dozzine di proiettili senza mai neppure ferire i buoni e l'eroe fa di ogni colpo un centro: molto divertente da vedere, ma non credibile. Poi, per la carita', qualcosa di interessante lo si trova anche, come il concetto di piazzare i contenuti di traverso tra le due pagine per, all'atto pratico, metterlo in clipboard, ma cio' non toglie nulla alla mia incredulita' di vedere davvero questo arnese sugli scaffali nei prossimi mesi.
Al contrario, sono ben contento di vedere che una fascia di prodotti su cui da tempo ripongo la mia attenzione stia in qualche modo uscendo dalla nicchia in cui e' stata relegata per anni ed i grandi produttori nel bene e nel male procedano con sperimentazioni e ricerche: continuo a ritenere l'idea del tablet una direzione quasi obbligata per gli sviluppi tecnologici futuri, in virtu' del rapporto dati esposti / superficie ingombrante di cui tali dispositivi godono, e nella speranza di poter presto trovare un degno sostituto al mio Acer C310 (quattro anni fa' il miglior convertibile che ho trovato sulla piazza, e da allora rimasto tale a causa della scarsita' di alternative) continuo a seguire gli sviluppi.

Bronzo

2009-10-13T16:35:00.003+02:00

Ed alla fine della fiera al Social Desktop Contest mi sono classificato terzo.
Con libopengdesktop (tra le mie due candidature, quella a minor contenuto innovativo), e dopo l'ExtendedAboutDialog (in effetti molto grazioso) ed il Knowledge Base Widget (quattro righe di C++ in croce, destino vuole scritte da uno di un paesello relativamente vicino a Torino).
Non mi dilungo ulteriormente in commenti, che non possono che essere di parte (esattamente come la giuria del contest, promosso dalla combriccola di KDE e dunque con qualche inevitabile lieve inclinazione...), e soprassedo anche sul fatto che abbiano scritto il mio nome al contrario, prima il cognome e poi il nome; attendo solo di ricevere la gift card da 50 dollari da spendere ancora non so come su Amazon.
Piu' che all'occasione sfumata di ottenere un netbook o un disco da 1TB (rispettivamente, primo e secondo premio della competizione), rifletto sull'immensamente scarso riscontro ottenuto da una iniziativa tutto sommato, come gia' detto, lodevole, mirata a stimolare la produzione di un po' di software in un contesto che merita attenzione da parte della community quale la condivisione di contributi non programmatori al freesoftware. Nonostante la decentemente ampia promozione e risonanza nella pagina dedicata alle candidature appaiono solo nove proposte, di cui almeno due completamente fuori concorso; due di queste sono mie, dunque volenti o nolenti qualcosa avrebbero comunque dovuto assegnarmelo per ragioni statistiche piu' che di merito. Frank Karlitschek, mente dell'attivita' (e proprietario del network di opendesktop.org), con rara maestria dialettica ha prima posticipando la deadline per le consegne ufficialmente adducendo ad una mole di aspiranti partecipanti che non hanno fatto in tempo a completare le rispettive opere (partecipanti i quali, inutile dirlo, non si sono piu' fatti vedere ne' sentire) e poi si e' deciso dopo lungo ritardo a dichiarare concluso il contest, sperticandosi in entusiasmi per l'ottima riuscita del concorso.
Io, che tanto ottimista non sono, mi domando e chiedo il perche' di un cosi' moderato approccio all'opportunita' fornita. Si potevano vincere dei bei premi con uno sforzo limitato, eppure come gia' detto le proposte avanzate sono state ben poche e pressoche' tutte di scarso impatto. La comunita' KDE (cui Social Desktop e tutta la corte di Karlitschek sono strettamente legati) gode di enorme hype e grande coinvolgimento, a volte persino troppo, e non trovo le ragioni di un cosi' netto fallimento.
Il dubbio e la perplessita' si fanno ancora piu' forti adesso che qui in Italia si approssima il Linux Day, apice del lavoro comunitario di promozione del software libero e occasione in cui emergono i piu' disparati propositi (tra cui i miei) per massimizzare il profitto comunicativo verso il grande pubblico: non c'e' bisogno di arguzia per sapere che tra il discutere una idea e realizzarla ce ne corre, e non poco, ma se persino un progetto della popolarita' di opendesktop.org attrae si' ristretta manodopera non c'e' da star sereni per l'avvenire.
Investire nelle nuove leve, su quella schiera di giovini che ad oggi maturano l'interesse al freesoftware solo in virtu' di cubi rotanti e velleitarie filosofie da ostentare nei circoli nerd? Inventare nuove forme di partecipazione, per abbassare la sbarra ed allargare il bacino di contributors? Le possibilita' sono molteplici, forse non tutte valide ma degne di esplorazione. Sta di fatto che l'utenza Linux su desktop si allarga, i numeri sono ancora piccini ma in costante crescita, e la quantita' di apporti non cresce con lo stesso ritmo.
Se un pugno di tecnici altamente specializzati hanno prodotto i risultati oggi sotto gli occhi di tutti, creare e mantenere un ecosistema realmente attivo e partecipativo puo' portarci la' dove nessun PC e' mai giunto prima.

Sentimento a 8 Bit

2009-08-25T02:29:00.008+02:00

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

2009-08-23T01:06:00.006+02:00

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

2009-08-20T21:54:00.003+02:00

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

2009-08-14T01:26:00.003+02:00

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'

2009-08-11T02:33:00.006+02:00

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

2009-08-08T01:43:00.004+02:00

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

RDF = Rendiamo Difficile Fare

2009-07-28T01:30:00.003+02:00

Ci sono giorni in cui mi ricordo perche' le tecnologie semantiche non mi convincono affatto. Oggi e' uno di essi.
Dal mio reclutamento tra le fila Nepomuk e' passato del tempo, ma sinora si e' prodotto poco: qualche altra discussione in lista Xesam, mi son migrato a mano i tickets dal vecchio tracker al nuovo, e poco altro. Evidentemente tutta la fretta imposta all'inizio non esisteva affatto, ma di questo ho gia' parlato.
Ieri son stato direttamente precettato per dire la mia in merito ad una questione che potrebbe portare ad una pesante revisione nella gestione delle mail in NMO, l'ontologia destinata al trattamento dei messaggi. I ragazzi di Tracker hanno avuto la bella pensata di riportare nella struttura semantica una mappatura 1:1 delle mail, suddividendole nei vari componenti MIME di cui sono assemblate, ed adesso che sono fuori specifica gli urge che tali correzioni vengano integrate in Nepomuk per essere compatibili con Strigi; in sostanza, hanno buttato all'aria la precedente struttura che manteneva un minimo di coerenza tra tutti i tipi di messaggi contemplati nell'ontologia.
Il bello e' che neppure gli posso dar torto, in quanto il fatto di mantenere l'informazione integra della mail cosi' com'e' non e' forse da considerare vitale ma comunque importante. Dunque, come si fa?
Cio' che si evince da questa vicenda (tutt'ora in corso: ci sara' da bestemmiare per trovare non solo una soluzione che mantenga uno straccio di coerenza ma che vada bene pure a sti' fenomeni che hanno implementato la loro propria soluzione senza chiedere niente a nessuno) e' che forse forse l'idea di "etichettare" ogni genere di contenuto nel minimo dettaglio permette certo di maneggiare con piu' rapidita' e disinvoltura il dato, ma presuppone comunque una conoscenza approfondita del dato stesso. Nello scenario di cui sopra, qualora si mantenga la struttura proposta, chiunque vorra' trattare una mail dovra' essere ben cosciente di cosa e' MIME, quali sono i metadati usati per tenere le informazioni rilevanti, ed ovviamente dovra' cambiare strategia nel momento in cui vorra' reperire un messaggio di altro tipo, ad esempio un SMS. Ed evitiamo di parlare del caso in cui vorra' far convergere questi due elementi...
Il problema intrinseco, almeno nel momento in cui tali strumenti si applicano al desktop, credo sia nella eterogeneita' dei contenuti che si dovrebbero rappresentare: i files son fatti tutti a modo loro, secondo formati propri, talvolta noti e talvolta chiusi, e la loro rappresentazione richiede troppo spesso o una mappatura completa del formato stesso o una perdita: totalmente inutile se si vogliono far collassare piu' cose secondo un criterio unificato.
Ce n'e' ancora di strada da fare per rendere usabile sta' baracca.

opengnomedesktop.org

2009-07-26T01:42:00.004+02:00

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

2009-07-17T22:52:00.004+02:00

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

libopengdesktop

2009-06-29T04:33:00.008+02:00

Come precedentemente annunciato negli ultimi giorni mi son messo ad implementare una piccola libreria che permette l'accesso ai servizi web compatibili Open Collaboration Services con un wrapper Glib, e dunque facilmente usabile in Gnome e XFCE. Sebbene certamente non ancora all'altezza di attica, ovvero l'implementazione per KDE, credo che libopengdesktop sia gia' usabile per piccoli applicativi senza pretese: mancano ancora le funzioni che permettono di comunicare con il server remoto in modalita' asincrona, indispensabili per l'utilizzo in una qualsiasi applicazione grafica che interagisca direttamente con l'utente, ma gia' il GTK+ Theme Thumbnailer menzionato nel precedente post sarebbe realizzabile senza eccessivo sforzo.
Per quanto questa faccenda del Social Desktop Contest in parte non mi torni, in quanto sembra abbastanza una bufala architettata a tavolino per l'interesse di pochi (e come al solito approfondiro' queste tematiche sull'altro mio blog), ha comunque stimolato i miei neuroni gia' peraltro eccitati dal bioritmo estivo, ed ora mi trovo con una quantita' di idee grandi e piccine che potrebbero essere presentate o comunque messe in opera per il puro gusto di far qualcosa di utile. Poiche' gia' so che non riusciro' mai a realizzarle tutte le condivido nella speranza che qualcun'altro si prenda carico di qualcuna di esse: se cio' dovesse succedere, lasciate un commento a questo pezzo cosi' evitiamo di lavorarci in due...

una implementazione AGPLv3 della piattaforma Open Collaboration Services (per quanto incredibile lo stesso OpenDesktop, riferimento stesso della specifica, sembrerebbe costruito su una piattaforma web closed source... Andiam bene...). Questo di per se dovrebbe essere il progetto che andrebbe ad includere anche il GTK+ Theme Thumbnailer, ed il primo su cui mi mettero' a lavorare non appena avro' un poco di tempo
un driver Gwibber per le funzionalita' di microblogging incluse nel formato
un driver Evolution per gestire i messaggi privati tra gli utenti
un'altro driver Evolution (o comunque un convertitore iCal) per importare nel calendar le informazioni relative agli eventi che vengono pubblicati
una qualche forma di integrazione con GeoClue per la gestione ad alto livello delle informazioni geografiche (magari una estensione di libopengdesktop?)
una applicazioncina Facebook che condivida su tale popoloso network le attivita' svolte su una piattaforma Open Desktop

C'e' sempre qualcosa di nuovo da sviluppare. Peccato manchino sempre gli sviluppatori...

GTK+ Theme Thumbnailer

2009-06-19T03:07:00.005+02:00

Giusto il tempo di commentare il Social Desktop Contest, che in quattro e quattr'otto contro ogni piu' rosea aspettativa son riuscito ad implementare (sebbene sia da rifinire) la prima proposta che avevo in mente. Non si tratta di nulla di eclatante, per la carita', ma la trovo comunque una opzione nella sua semplicita' originale ed utile.
Partiamo da un presupposto: i contenuti solitamente accessibili sui vari siti della rete OpenDesktop hanno il grosso problema di non essere programmaticamente gestibili. Bellissimi i Nautilus Scripts, o le applicazioncine su kde-apps, ma fintantoche' la loro installazione ed il loro utilizzo richiedono un intervento consapevole dell'utente (che deve decomprimere l'archivio e leggere il README per sapere di volta in volta quali files prendere e dove spostarli), e non esiste dunque alcuna forma di pacchettizzazione, non si puo' pensare ad uno strumento che faciliti la propagazione di codesti micro-applicativi con una modalita' di interazione fruibile dagli utilizzatori domestici (ovvero: "Clicca qui e faccio tutto io"). Dello stesso difetto, o meglio di una sua variante, soffrono i materiali meno impegnativi e destinati all'abbellimento grafico del proprio desktop: splendide le sfilze infinite di GTK+ engines e decorazioni per le finestre di Metacity, ma se ognuna di esse e' rappresentata da uno screenshot preso alla meno peggio dal rispettivo sviluppatore/artista ed in situazioni sempre diverse e' difficile poterne valutare la gradevolezza e tocca comunque scaricare ed installare prima di accorgersi che la personalizzazione sulla propria postazione di lavoro non piace.
Proprio a questa seconda problematica e' rivolto il mio modestissimo progetto: un servizio web che wrappi alcuni dei contenuti di gnome-look generando automaticamente le preview dei vari temi disponibili sempre secondo lo stesso layout di widgets.
Mettendo il naso nel codice di gnome-control-center, ovvero l'applicativo che in Gnome permette la selezione di vari parametri di visualizzazione, si scopre che le thumbnails sono generate dinamicamente partendo sempre dalla stessa configurazione di widgets (si vedono rispettivamente un pulsante, una checkbox ed un radiobutton) si' da affiancare in modo equo e confrontabile le differenti opzioni; da li', e' stato un attimo isolare le funzioni che provvedono a tale generazione e realizzare un eseguibile standalone capace di produrre una JPEG a partire da un qualunque tema, da poi fornire in accompagnamento ai contenuti esposti da un ipotetico server che come detto funga da provider per un altrettanto ipotetico pannello Gnome arricchito da un tasto che permetta di pescare da esso (come gia' succede nel pannello dei wallpapers di KDE).
Paradossalmente adesso arriva la parte piu' noiosa e complessa, ovvero quella di provvedere ad una libreria C (e magari GObject oriented...) che wrappi l'API REST descritta dalla specifica Open Collaboration e permetta di comunicare col server senza doversi ogni volta parsare l'XML, e gia' da solo questo task meriterebbe di essere contemplato come entry a se' stante per il Contest. Ad ogni modo credo che l'ostacolo piu' imponente, ovvero la creazione di preview coerenti, sia stato abbondantemente superato, e da adesso la strada e' in discesa: non so se una trovata cosi' modesta possa realmente avere uno spazio all'interno della competizione internazionale (e anche se lo fosse, l'Italia e' storicamente tagliata fuori dei concorsi a premi che si svolgono nel resto del mondo...), ma ribadisco l'intento puramente materialistico dell'opera.
Ogni tanto un qualche simpatico hack per passar la serata e' d'uopo...

L'Unione fa... il Desktop

2009-06-18T01:25:00.008+02:00

Sembra che la community di sviluppo freesoftware si sia svegliata tutta d'un colpo per concentrare almeno una parte delle risorse in tema di design ed usabilita' dei prodotti open: dopo il recentemente commentato contest di Mozilla (per cui ammetto di aver abbandonato il proposito di partecipare in modo serio, avrei voluto mettere insieme un piccolo prototipo ma le incombenze sono sempre troppe...) nel giro di pochi giorni sono spuntati fuori il progetto "One Hundred Paper Cuts" ed il "Social Desktop Contest".
Il primo si tratta di uno "sprint" che punta ad individuare e correggere 100 piccoli bugs all'interno dell'interfaccia di Ubuntu (notoriamente: Gnome) entro un breve periodo di tempo, puntando l'attenzione soprattutto sulle piccole ma fastidiose incoerenze che possono peggiorare la user expericence dell'utente novizio ma d'altro canto possono essere sistemate con poco sforzo. La lista delle segnalazioni e' ricca, e posso sperare che i developers coinvolti non chiuderanno la baracca arrivati al centesimo ticket chiuso ma lavoreranno comunque per sistemare il sistemabile. Considero l'iniziativa ottima, purtroppo non ha molto senso che a condurla sia un'unico vendor (Ubuntu, appunto, considerando che alla fine il codice corretto e' quello di Gnome) ma e' un modo efficace per coinvolgere l'utenza domestica, piu' sensibile ad imprecisioni che potrebbero passare inosservate ad un esperto, e perfezionare alcuni dei dettagli che fanno la differenza tra un prodotto buono ed uno eccelso.
Di tutt'altro genere e' il contest indetto da Social Desktop (che in realta' e' solo un'altro nome per OpenDesktop...), che mira a stimolare la produzione di qualche applicativo nuovo e creativo che sfrutti la specifica Open Collaboration Services by Freedesktop.org per l'integrazione del desktop Linux con funzionalita' di social networking. Sebbene in lavorazione da qualche tempo il formato per il recupero, la condivisione e la valutazione di contenuti addizionali per i PC casalinghi (wallpapers, icone, piccole utility...) non ha mai preso particolarmente piede, forse anche perche' l'unico fornitore degno di nome del servizio e' appunto OpenDesktop (quelli, per capirci, che mandano avanti gnome-look e kde-look), e solo ultimamente l'implementazione di una parte dei servizi all'interno di KDE4 (come al solito annunciata con le fanfare) ha riportato l'attenzione sul tema. Io credo che alla specifica manchi ancora molto per essere davvero utilizzabile e non rappresentare solo un guscio di fuffa "duepuntozero", ma tornero' prossimamente su tali considerazioni: al momento sto accarezzando l'idea di assemblare qualcosa per suddetto contest, sperando di produrre qualcosa di piu' che non per la sopra menzionata competizione Mozilla, e quando opportuno esporro' un approfondimento.
Insomma, la morale del post e': basta un poco di ingegno per architettare iniziative ampiamente fruibili dalla community (e non solo dagli sviluppatori, che paradossalmente sono sempre piu' una minoranza), in grado di condurre a ricchi risultati con un impiego modesto di risorse. Mi auguro di continuare a vedere spesso questo genere di imprese da parte dei team piu' grandi e con maggiore risonanza mediatica.

CustomCaptionPanel per GWT

2009-06-08T03:57:00.008+02:00

Come ogni altro framework, anche il Google Web Toolkit (gia' piu' volte menzionato in questo blog) inizia a dare soddisfazioni quando lo si riesce ad usare decentemente. Oggi, ispirato da un colpo di genio (o meglio di memoria...), questo articolo e la consultazione del codice interno di alcune classi, ho implementato ed incluso in GASdotto questa semplice classe che permette di utilizzare un fieldset come Cristo comanda, ovvero con le label.
Grazie a questo piccolo espediente e' possibile generare una gerarchia DOM che formatta i contenuti senza fare uso di tabelle (non tanto per questioni di accessibilita', comunque compromessa trattandosi di roba compilata in Javascript, ma interessante in termini di elementi che il layout engine del browser si trova a dover manipolare), e riccamente configurabile per mezzo di CSS come nell'esempio incluso nel codice della classe sopra linkata.
Il risultato ottenuto e' esteticamente assai gradevole, ed ovviamente ancora migliorabile se solo fossi capace di spremere CSS in modo esaustivo, e sebbene ancora non perfetto (il CaptionPanel cosi' taroccato non permette di installare listeners sugli elementi trattati, per intercettare ad esempio il focus, e non ho ancora capito come aggirare...) spero che questo pezzetto di codice torni utile a qualcuno.

Tanto va il Bob al Largo...

2009-06-05T23:59:00.006+02:00

Ci sono situazioni della vita in cui non si puo' non restare affascinati dinnanzi agli inaspettati risultati che una caotica serie di eventi puo' produrre: ho piu' volte conosciuto per puro caso persone che a distanza di tempo ed in intricate circostanze si sono rilevate indispensabili, ho vissuto esperienze incredibilmente belle o incredibilmente brutte che mi hanno permesso di accedere ad altri scenari ancora piu' estremi, e mi sono trovato in condizioni paradossali a seguito di non meglio descrivibili catene di cause ed effetti.
Questa e' una di quelle situazioni.

Io, eterno scettico nei confronti del desktop semantico, e acceso critico nei confronti di organizzazioni ufficiali e para-corporate nel contesto dello sviluppo free, sono da oggi co-maintainer di un componente di Nepomuk.
Non sto qui a spiegare il come ed il perche' di tale evoluzione, e se lo facessi comunque pubblicherei il resoconto sul mio blog piu' "politicamente attivo" a causa dei risvolti che la vicenda ha e continuera' ad avere, ma basti qui menzionare il fatto che nel prossimo periodo avro' modo di approfondire persino piu' del dovuto il tema delle tecnologie semantiche ed i loro risvolti.

L'incarico si prospetta tutt'altro che semplice, considerando che in fin dei conti la definizione di una ontologia non e' null'altro che un confronto dialettico tra due o piu' persone che vogliono imporre la propria visione soggettiva delle cose senza poter fondare la discussione su aspetti tecnici e misurabili, lunghissimi flames sono gia' stati prodotti nei confronti di innumerevoli dettagli che avrebbero dovuto essere inclusi, esclusi o modificati ed il mio compito sara' quello di moderarli. Se a cio' aggiungiamo l'hype che Nepomuk detiene, avendo galvanizzato una buona fetta della community a seguito dell'implementazione (comunque a tutt'ora in corso d'opera) in KDE, ed il fatto che dovro' confrontarmi con personaggi di un certo spessore e di una certa esperienza (nella pagina sopra linkata appaiono, oltre al mio, i nomi di almeno un paio di maintainer di Tracker ed il co-maintainer di Xesam), la sfida si fa ancora piu' ardita.
Ridendo e scherzando gia' so che passero' il weekend a documentarmi sui tickets gia' in passato aperti sul componente a me assegnato e sulle modifiche che qualcuno ha arbitrariamente apportato senza pero' passare per la validazione da parte della community, preparandomi mentalmente e fisicamente al ciclo di sviluppo che iniziera' nel prossimo periodo a causa della chiusura dell'originario progetto Nepomuk sponsorizzato dall'Unione Europea ed alla migrazione della baracca sotto l'egida della fantomatica OSCAF, ambigua organizzazione il cui compito non e' ancora chiaro e per la quale indirettamente mi son trovato in codesta situazione.
Vabbe', guardiamo il lato positivo: con tutte le mail di insulti internazionali che dovro' mandare, magari il mio inglese scritto migliorera'...

Mozilla Design Challenge, parte 1

2009-06-02T12:41:00.003+02:00

Essendomi perso il contest per il re-design di OpenOffice, qualche giorno fa' ho deciso di partecipare a quello indetto da Mozilla per l'ideazione di una alternativa alle classiche tabs per la navigazione di piu' pagine contemporaneamente in Firefox.
Si parte dal presupposto che (cito testualmente) "oggi avere 20 o piu' sessioni parallele e' cosa comune", e nell'ottica di fornire un nuovo strumento di gestione della propria vita digitale si sta cercando un mezzo piu' efficiente che non le comodissime ma comunque limitanti tabs tradizionalmente poste al di sopra delle pagine.
Ieri sera ho confezionato una prima proposta, anche se ammetto apertamente che sia piuttosto banale: come si vede in questi mockups (e nell'orribile video che riporto anche qui sotto) ho piazzato le tabs in una sidebar, ispirandomi all'oramai diffuso utilizzo di monitor widescreen che offrono tanto spazio orizzontale, anche se tale presupposto non vale per gli altrettanto diffusi netbooks e tale approccio contempli comunque una semplicissima reimplementazione dello stesso identico concetto gia' esistente.

Poche le "innovazioni" introdotte da questo concept: il fatto che le tabs che vengono attivate da un qualche evento interno (ad esempio: una modifica nel DOM da parte del JavaScript correlato, che magari ha pescato dal server un nuovo frammento di informazione quale ad esempio una nuova mail in GMail) vengono esposte in primo piano all'utente, e l'ordinamento per dominio (che permette di aggregare piu' pagine provenienti dallo stesso sito). Ma comunque gia' esistono implementazioni di tale idea sottoforma di estensioni Firefox, dunque non c'e' molto altro da dire
se non che si e' trattato di un (neppure tanto riuscito) esercizio di stile.

Ma come gia' detto, questa si tratta solo di una prima proposta: un'altra ne ho nel cassetto, in buona parte ispirata ed adattata dal meccanismo di navigazione dei templates pensato per Synapse. Certamente un "template" (nell'accezione assunta all'interno di Lobotomy) e' cosa diversa da una pagina web, dunque qualche revisione va apportata, ma provero' quanto prima a confezionare anche quest'altra proposal da inviare al team Mozilla.

Apprezzo immensamente lo sforzo profuso da Mozilla nella ricerca in campo di usabilita' e HCI, settore in cui tipicamente il software open deficita: il fatto di trattare l'interfaccia della propria applicazione con la stessa cura con cui si tratta il codice e' sintomo di consapevolezza nei confronti del "mercato" e dell'utenza, ed evidenzia l'intenzione di elevare la qualita' del software secondo canoni troppo spesso tralasciati e considerati secondari.
Con i miei modestissimi interventi non conto di lasciare un segno particolare presso il team Mozilla, ma il solo fatto di fomentare la creativita' di collaboratori freelance avvezzi al design ed all'usabilita' permette di avere una ricaduta su tutto il panorama e di generare concepts che potranno essere facilmente riutilizzati in altri progetti. Ben vengano dunque iniziative di questo genere, che dovrebbero anzi essere intraprese da tutti i progetti open di un certo spessore.

Fuori Onda

2009-06-01T15:19:00.003+02:00

Giacche' il web sembra in fermento per l'ultima trovata Google, inutile non volerne discutere anche su questo blog.
In poche parole: Wave e' un tool per far convergere diverse forse di discussione, tra cui instant messaging e commenti sui blogs, e di editing collaborativo. Sara' che gli esempi forniti nel corso della presentazione ufficiale del prodotto (di cui e' disponibile il video nella homepage del progetto) sono abbastanza banali ed ingenui, ma al contrario della maggior parte della blogosfera a me non pare nulla di particolarmente eccitante.
Per la carita', una API che permetta di gestire in modo complesso gli stream di discussioni e commenti e' piu' che benvenuta, e gia' pregusto il momento in cui la includero' in GASdotto per arricchire le possibilita' di interazione degli utenti, ma in fin dei conti di strumenti per l'editing collaborativo ne esistono gia' a quintalate (sia web che desktop), e neanche si contano i mezzi con cui due o piu' persone possono comunicare in modo piu' o meno sincrono.
Probabilmente l'aspetto piu' innovativo del prodotto sta nella formalizzazione di un protocollo per l'aggregazione di contenuti, che garantisce la possibilita' di implementazioni inedite e maggiori spazi per l'integrazione di servizi offerti da diversi providers (nonche' di applicativi di interfaccia magari un po' piu' usabili che non il client Wave proposto da Google stessa, che mi pare tutto fuorche' immediato e semplice da utilizzare), ma come sempre c'e' da vedere se davvero tale arnese verra' portato laddove ce ne sarebbe bisogno, ovvero social networks e piattaforme di (micro)blogging, oppure se ancora una volta le divergenze del libero mercato concorrenziale imporranno limiti alla radicazione della specifica.

Piu' in generale, il mio giudizio nei confronti di questo genere di strumenti di carattere "social" e' sempre abbastanza critico: bellissima la possibilita' di condividere commenti, informazioni, notizie ed opinioni, ma se alla fine tutto questo popo' di tecnologia viene usato per far divulgare le foto delle vacanze non si ottiene nulla di piu' che non la versione globalizzata e 2.0 della "serata a casa degli amici a vedere le diapositive della settimana al mare". Quel che mancano non sono i mezzi, ma i contenuti, o comunque un qualche criterio che faccia emergere i dati realmente utili per la conduzione dei processi di decision making.
Gia' mi sono altrove espresso favorevolmente nei confronti dei nuovi media e dei canali di comunicazione "peer2peer" offerti dalla moderna Internet, ma giunti a questo punto ci si aspetterebbe da un colosso come Google (o da chiunque altro con un forte potenziale innovativo) qualcosa di piu' che non un servizio di instant messaging potenziato.
Forse la salvezza arrivera' dal semantic web, ma i tempi sembrano tutt'altro che maturi. Forse la salvezza arrivera' da Lobotomy, o da Itsme, o da qualche altro progetto che porta l'aggregazione dell'informazione al centro del modello di interazione, ma l'attesa sembra essere tutt'altro che breve. E nel frattempo aumenta la mole di informazione da filtrare a mano, e troppo spesso succede di perdersi i pezzi per la strada.

Strutture Algoritmiche

2009-05-18T23:52:00.004+02:00

Un post gustosamente tecnico, inevitabile epilogo di una giornata interamente passata a programmare manipolando una infinita' di strutture dati.
Gia' da tempo ho constatato l'enorme gap che esiste tra le strutture dati comunemente conosciute, usate ed implementate nelle piu' svariate librerie, e l'architettura di un qualsiasi sistema la cui complessita' e' maggiore del classico hello world: laddove, seguendo i canoni della programmazione strutturata, si isolano (e stratificano...) le routines in modo da essere quanto piu' generiche possibili, alla lunga molto facilmente si arriva a replicare gli stessi dati in piu' e piu' posti semplicemente perche' in diversi posti si necessita di un diverso ordinamento, di una diversa gerarchia o di un diverso tipo di elemento che possa essere passato alle funzioni esposte da un diverso framework. E la pigrizia, prima virtu' di ogni developer, induce a ridurre, se non eliminare del tutto, l'implementazione di nuove strutture dati ad hoc da adottare caso per caso, ma ad adoperare due o tre o quattro istanze delle strutture normalmente fornite da qualsiasi libreria di utility e gestite su piu' piani differenti.
Un esempio concreto, fresco fresco e tratto dall'esperienza di oggi: ho usato una GHashTable per mantenere i riferimenti ad alcuni oggetti presi da un'altro componente e da restituire ad un'altro. Ma tali componenti ai due estremi del flusso sono fatti per "ragionare" secondo parametri diversi di cotali oggetti, mentre l'hash table permette di indicizzarli secondo un criterio solo. Risultato: quando le richieste arrivano da una parte l'accesso e' immediato, quando arrivano dall'altro devo convertire in una GList allocata sul momento, iterare, e liberare la struttura temporanea. Quanto sarebbe piu' efficiente il tutto se realizzassi una hash table personalizzata con due (o meglio ancora, un numero arbitrario di) indici distinti, o meglio ancora perfezionassi la gia' esistente GRelation (che non sembra godere di molta attenzione da parte del team Glib)? Molto, tutto sta nell'avere tempo di farlo.
E ancora: come detto gli oggetti sono presi da una parte e passati dall'altra, ma questo comporta una duplicazione delle stesse informazioni. Informazioni che sono rappresentate in modi completamente diversi, ma che vanno ordinate piu' e piu' volte, iterate piu' e piu' volte, sincronizzate piu' e piu' volte... Quanto sarebbe piu' rapido e performante l'insieme se si provvedesse ad una qualche forma di struttura condivisa mantenuta allineata una sola volta per tutte? Molto, ma richiederebbe non poco sforzo per la realizzazione di qualcosa di stabile date le condizioni di concorrenza.
E' probabile (anzi pressoche' certo) che la' fuori esistano centinaia di concetti nuovi, magari gia' anche implementati e testati e debuggati, ma che non sono ancora stati "scoperti" ed introdotti nei toolkit piu' popolari, i quali spesso magari neppure implementano le gia' ben note strutture piu' di nicchia e raffinate.
Nel contesto del Progetto Lobotomy iniziai ad esplorare, insieme ad altri spunti per esotiche strutture dati tra cui una ispirata dalle architetture multi-core, il concetto di "extension", ovvero estensioni dei tipi di dato fondamentali con altri oggetti che li descrivessero in modi diversi e ad essi direttamente agganciati al fine di avere un'unica lista in cui aggiungere e rimuovere elementi ed in cui cercare secondo un criterio ed ottenere immediatamente la diversa rappresentazione (ad esempio: cercare un HyppoVFSItem ed avere subito il relativo all'interno della GtkIconView senza dover iterare altrove), ma tanto per cambiare non ebbi modo di approfondire ulteriormente le potenzialita' del concept e non ottenni alcunche' di effettivamente usabile.
Un giorno o l'altro dovro' tornarci, su questo e su altre ricerche. Per intanto mi accontento delle mie hash table tradotte in liste...

Social Software

2009-05-10T19:03:00.003+02:00

Nella 2020 FLOSS Roadmap, il documento (assolutamente non ufficiale, ma comunque fonte di ispirazione) che descrive i punti chiave in cui sviluppare e promuovere il software libero nei prossimi anni affinche' possa viralmente innestarsi sul panorama IT precedendo le controparti proprietarie (ed alla fine conquistare il mondo!!! Mhuahahaha!!!), uno spazietto e' dedicato al "Social Software".
Mettendo le mani avanti in merito al significato che tale buzzword dovrebbe avere, e che nella mia interpretazione differisce dalla definizione fornita da Wikipedia, il termine mi ispira un concetto che val la pena di esplorare ed implementare, o quantomeno di uniformare a partire dalle gia' esistenti sporadiche incarnazioni. Tale concetto e' quello di applicare una dimensione "social" (nell'accezione di "social networking") alla distribuzione del software, integrando servizi collaterali come il rating e l'aggiunta di commenti per ogni pacchetto installabile per mezzo del package manager, si' da arricchire quasi passivamente la documentazione relativa alle applicazioni accessibili dagli utenti.
L'idea e' tutt'altro che nuova, viene gia' marginalmente applicata in Ubuntu (che rappresenta la popolarita' delle applicazioni con delle stelline di merito) ed in Entropy (il package manager di Sabayon, progetto che ho modo di seguire abbastanza da vicino e che non nascondo abbia in buona parte influenzato la mia posizione sui temi qui trattati), ma trattandosi di applicazioni indipendenti, non compatibili e limitate risultano solo parzialmente utili ai fini dello sfruttamento intensivo dell'idea. Per questo motivo ho gia' provveduto a gettare il sasso nello stagno di PackageKit, progetto FreeDesktop che punta all'astrazione del package management sulle piu' disparate distribuzioni ed esporre questa funzionalita' in modo che sia programmaticamente raggiungibile anche da applicativi che non siano il package manager in senso stretto, ed attendo qualche commento in merito.
In un futuro il proposito potrebbe essere esteso anche a forme di contenuti "user generated" piu' significativi che non gli sterili commenti, come ad esempio una maggiore interazione in caso di errore dell'applicazione (e conseguente bug report) e l'avanzamento di idee e proposte per nuove features e migliorie: anche in questo caso esistono gia' parziali implementazioni dai singoli vendor (ad esempio Firefox provvede a presentare il dialog di bug reporting in caso di errore, mentre il team Ubuntu gestisce un suo proprio collettore di suggerimenti online), e provvedere una soluzione unica, riusabile e facilmente gestibile (per evitare gli ovvi doppioni che scaturirebbero da una adozione di massa del sistema, da individuare nel modo piu' automatico possibile) permetterebbe di incrementare notevolmente le possibilita' di produrre software di gran qualita'.
Il sofware libero siamo noi, dunque tanto vale fornire strumenti efficaci per lo svolgimento del proprio compito.

"Lobotam"?

2009-05-01T18:29:00.005+02:00

Negli ultimi tempi, per motivi legati in qualche modo al lavoro, mi sono documentato in modo abbastanza approfondito su Xesam, ovvero il protocollo FreeDesktop che intende unificare l'accesso ai dati piu' o meno semantici raccolti dai vari indexers quali Tracker, Beagle e compagnia cantante. E sebbene un anno fa', in occasione del primo approccio col progetto stesso, espressi una critica alla modalita' di utilizzo del formato, dopo aver rovistato il wiki in lungo ed in largo ed aver constatato l'incredibile frammentazione esistente nel mondo open in merito al tema del desktop semantico mi sono cosi' convinto della necessita' di questa opera che non solo mi sono iscritto alla mailing list ed ho preso (modestissima) parte all'atto finale che prelude al rilascio della versione 1.0 della specifica (oramai imminente) ma mi sto anche persuadendo che, almeno per ora, potrei utilizzare tale strumento all'interno di Lobotomy, sostituendo il mio personale storage relazionale Hyppocampus con un indexer canonico acceduto appunto grazie al protocollo standard.
Questo porterebbe all'impossibilita' di implementare alcune delle features avanzate che avevo elaborato, come il versioning dei singoli metadati e l'utilizzo ortogonale di informazioni cronologiche, ma certamente il fatto di non dovermi occupare personalmente di una componente grossa ed impegnativa come l'estrattore, indicizzatore e fornitore dei metadati mi permetterebbe finalmente di ottenere qualcosa di concreto nell'ambito del mio oramai anzianissimo ma poco produttivo progetto. E si puo' anche immaginare che in questo modo Lobotomy, inteso come ambiente operativo, potra' anche piu' facilmente essere adoperato, valutato e testato all'interno di un desktop environment canonico, ed essere utile a qualcuno per gestire i propri dati senza necessariamente dipendere dall'approccio distruttivo e radicale che presupporrebbe l'utilizzo esclusivo della mia esotica interfaccia.
Conto di concentrarmi prossimamente sui task prettamente presentativi del sistema, nella fattispecie su Synapse, e faro' in modo di wrappare l'interfaccia Xesam in modo che sia facilmente sostituibile il giorno in cui disporro' di uno storage relazionale fatto a modo mio.
Lobotomy + Xesam = Lobotam!

xPUD

2009-04-08T20:20:00.004+02:00

E' successo di nuovo: non faccio in tempo ad avere una idea, che subito trovo qualcuno che l'ha gia' applicata.

Da poco tempo sono allo studio delle gia' esistenti soluzioni che permettono di costruire interfacce grafiche partendo da una descrizione formalizzata in XML, al fine di cercare di recuperare qualcosa per la prossima implementazione dell'interprete di "Thoughts" da integrare in Synapse, e sono giunto alla conclusione che probabilmente l'eccellenza in questo campo sia stata raggiunta da XUL, tecnologia a mio tempo gia' esplorata che sta alla base di prodotti del calibro di Mozilla Firefox. Ho dato uno sguardo all'immensamente complesso ed arzigogolato codice sorgente dell'interprete al fine di estrapolarne la tecnica adottata per il parsing e la ricostruzione della grafica, e sono anche arrivato al punto da lasciar perdere il vago pensiero dell'integrazione dell'intero XUL all'interno di Lobotomy a causa della sintassi troppo permissiva e della pesante quanto inutile dipendenza da Javascript, ed immediatamente mi trovo davanti agli occhi una intera distribuzione Linux con una interfaccia completamente costruita su tale piattaforma.
Di xPUD ho letto la prima volta tra le news di Distrowatch, qualche giorno fa', ho scaricato la .iso e me ne son dimenticato; oggi me lo ritrovo su OSNews, dunque inevitabile e' stato riportare l'attenzione sul progetto.
Purtroppo non ho potuto ancora provare il prodotto, a causa della scarsita' dei miei mezzi di virtualizzazione per verificare il CD live almeno su macchina virtuale, ma almeno sulla carta questa sottospecie di interfaccia ultraminimale (come riportato da OSNews stesso) estremamente ben si adatta ai netbooks o ad un ipotetico "sistema operativo di emergenza" da avviare all'occorrenza per la fruizione dei contenuti del PC (senza far partire tutto l'ambiente canonico). Non sara' forse l'erede futuro del desktop, ma certamente il concetto di tirar via tutto il superfluo e mettere sotto il cursore quello che realmente serve, implementandolo oltretutto con una tecnologia cosi' propensa alla customizzazione e di rapidita' di stesura e perfezionamento, merita un elogio.
I miei piu' vivi auguri al cinese che sta portando avanti questa impresa, con la speranza di vedere qualcosa del genere sui prossimi netbooks in commercio anziche' gli orribili Linpus e compagnia cantante.

L'Efficienza di un Cesso

2009-04-02T20:45:00.002+02:00

Questo e' un aneddoto che, contrariamente alla tradizione di questo blog, tratta di usabilita'... analogica.

Viaggiando sulla tratta Torino-Milano a bordo di un "VivAlto" (il treno con le carrozze a due piani sporadicamente usato sulle linee ad alta densita', quello con il monitor che indica la velocita' del mezzo e forse l'unico "regionale" dotato di prese elettriche che qualche volta addirittura funzionano), capita che mi scappi la pipi'. E quando la Natura chiama non si puo' esitare nella risposta.

Ma un fenomeno curioso stuzzica piu' che il mio spirito di osservazione la mia vescica: dalla mia posizione priviligiata proprio sopra alla toilette constato che, nonostante la modesta quantita' di viaggiatori presenti sul treno, la ritirata della carrozza e' sempre occupata, e la porta si apre e si richiude costantemente indicando un continuo ricambio di avventori. Dopo molti turni di attesa, ed una volta arrivato gia' nell'area urbana milanese, finalmente riesco ad introdurmi nella cabina desideroso di sbrigare la pratica.

Ma devo attendere che la tazza abbia finito di girare. Mentre il cono di acciaio che ha preso il posto dell'ergonomico sedile di porcellana termina il suo ciclo di pulizia automatica getto una occhiata all'ambiente: il malamente illuminato sbaguzzino si presenta come un desiderio non soddisfatto di modernita' e ottimizzazione, uno spazio ispirato dalla visione in seconda serata di Blade Runner dopo una cena a base di peperonata, e come se non bastasse l'assai modesto intento stilistico la natura umana, che e' pur sempre di stampo animale, unita all'azione esponenziale della seconda legge termodinamica (quella che parla di entropia e caos...), concedono all'insieme un tocco di decadenza nichilista sparpagliando sulle superfici lisce e plasticose schizzi incontrollati di acqua (e non solo, si puo' immaginare) e pezzi di carta strappati e bagnati. L'asettico futuro ritratto da "2001 Odissea nello Spazio" e' ancora distante.

Finalmente il giuoco d'acqua intorno al piu' contemporaneo erede della seduta medievale termina, e posso assolvere ai doveri nei confronti del mio essere biologico. Terminata la procedura, mentre le mani si occupano di serrare la patta gli occhi vagano alla ricerca di un pulsante, una catena, un interruttore che azioni lo sciacquone. Non e' stato immediato collegare la precedente immagine descritta, quella del cono sciacquato automaticamente al termine della sessione ed alla riapertura della porta, con il fatto che non v'era alcun bisogno di tirare l'acqua, in quanto il treno avrebbe pensato da se' a liberarsi del fardello. Da qui, la considerazione (o la riconferma del fatto) che l'abitudine e' la maggiore nemica dell'innovazione, in quanto induce le persone a comportarsi sempre nello stesso modo ed ostacola l'adozione di nuovi atteggiamenti: anche una operazione insignificante come quella della pulizia del bagno, che ha tutto il senso di essere automatizzata essendo (dovendo essere) ripetuta ad ogni iterazione, riesce a mettere in crisi chi ha sempre eseguito gli stessi gesti per decenni e non si trova sotto le dita l'atteso tastone che permette di comunicare al mondo la chiusura della propria pratica. Certo che una notifica piccola piccola sopra la tazza avrebbero potuto anche metterla...

Soddisfatto l'animale, e' d'uopo ricondursi a schemi civilizzati. E dunque mi volto per lavarmi le mani. Davanti a me trovo una specie di armadietto che fa tutt'uno con la parete, compatto, con una apertura dell'altezza di 40 cm all'altezza delle mani. Al suo interno, il lavandino. Nessuna traccia del rubinetto, ne' tantomeno di un modo per far scendere l'acqua. Non c'e' il pedale, come sui normali treni regionali ed in molti altri locali pubblici; non c'e' fotocellula che attivi il flusso al passaggio della mano, essendo evidentemente una soluzione troppo propensa ad atti di vandalismo. Mi guardo attorno, e l'attenzione di sofferma sulle tre "icone" bianche disposte sul bordo superiore dell'apertura, tutte con simboli stilizzati, tutte con la descrizione in Braille dell'oggetto rappresentato, tutte disegnate e lisce. O forse no. Quella al centro, raffigurante un rubinetto, ha un leggero rilievo. Senza troppa convinzione lo premo, ed ecco l'acqua scendere.
In codesto frangente opera l'apprendimento, che induce a cercare soluzioni gia' note per problemi gia' affrontati: in questo caso il problema e' stato procurarsi dell'acqua, la soluzione era diversa da qualsiasi altra cosa avessi visto in precedenza e dunque non ancora parte del mio bagaglio, dunque neanche presa in considerazione e tentata. Nonche' particolarmente nascosta ed infida. Anche qui, un esplicativo testo "Premere qui" non avrebbe fatto male.

Ammetto di aver rinunciato all'idea di trovare le salviette di carta, mi sono asciugato sui pantaloni.

Tempo totale per far la pipi': due minuti. Adesso mi si spiega il perche' del precedente rallentamento nello smaltimento della coda.
Niente di cio' che e' umano mi e' estraneo.

Migrazione!

2009-03-28T02:27:00.003+01:00

Come forse precedentemente annunciato, da qualche tempo ho un Virtual Private Server su cui intendo migrare (nonche' riavviare...) lo sviluppo del Progetto Lobotomy.
Per lungo tempo l'opera e' rimasta sospesa a causa dei numerosi impegni professionali e non, ma nell'ultimo periodo un po' di urgenze sono state smaltite e mi trovo con non molto ma sufficiente tempo libero per riprendere le fila dell'antico ma mai dimenticato progetto, che ridendo e scherzando occupa la mia affollata testolina da numerosi anni. Da notare comunque che tale pausa mi ha permesso quantomeno di ponderare in linea teorica sul piu' recente modello che sta alla base della piattaforma che intendo costruire, e dal primo abbozzo presentato alla piu' aggiornata revisione l'idea e' stata arricchita di numerosi perfezionamenti ed apparentemente impercettibili dettagli.
Su http://lobotomy-project.org e' raggiungibile una istanza di Trac, il cui wiki e' attualmente in fase di popolamento al pari del tracker su cui sto raccogliendo (seguendo lo spunto offerto) idee sparpagliate da poi riassemblare e validare globalmente, e da cui partire per una prima implementazione. Nel frattempo sto provvedendo alle questioni amministrative, annunciando sul vecchio sito e sulle varie pagine in cui i diversi componenti del sistema sono state sparpagliate sinora la migrazione in atto.
Ovviamente non sono in grado di fornire una roadmap precisa in merito ai prossimi sviluppi, trattandosi questo di un progetto amatoriale e a piu' bassa priorita' rispetto agli altri impegni, ma faro' in modo di presentarmi all'inizio dell'estate, periodo dell'anno tra i piu' prolifici essendo il meno professionalmente impegnato, con un piano preciso di cose su cui passare le mie giornate svaccato sul futon.

Piastrelle Semantiche

2009-03-23T01:50:00.003+01:00

Su questo blog e altrove ho piu' volte criticato le tecnologie semantiche. Ma forse sarebbe bene fare distinzione tra "semantico" e "semantico".

Non tutte le tecnologie etichettate con tale altisonante classificazione, cosi' di moda oggi e dunque cosi' abusata e di cui in fin dei conti in pochi (non me) hanno ben chiaro il significato, offrono infatti gli stessi vantaggi a fronte dello stesso impegno. Si va dall'estremo del "desktop semantico" - l'attuale KDE4, che implementa lo stack Nepomuk e che incentra buona parte delle sue funzionalita' intorno alla capacita' dell'utente di assegnare tags ai suoi propri files - all'opposto del "web semantico", ovvero la "Rete di dati" cui gia' qualcuno arditamente (o stupidamente) appunta la nomea di "Web 3.0". Mentre la prima categoria di applicazione e' lungi dal ricevere un mio consenso, soprattutto a questo stadio di sviluppo ed alla luce del fatto che esse sono completamente inutili se non manipolate a dovere dall'utilizzatore finale (che, per definizione, non usa mai le cose come dovrebbe), la seconda classe e' motivo di discreto interesse, almeno dal punto di vista del potenziale in campo. In generale non vedo troppo di buon occhio la frammentazione (seppur controllata e documentata) dell'informazione in dialetti e sottodialetti, come appunto si vuole fare con l'iniezione di una quantita' infinita di "ontologie" da applicare ad informazioni diverse a seconda del loro contesto, ma certamente se sufficientemente diffusi e propagati tali mezzi risulterebbero di infinita utilita'.

Purtroppo il grande difetto del "semantic web" e', paradossalmente, la sua stessa community di sostenitori, costituita in larga parte da accademici esaltati che amano riempirsi la bocca con nozioni di filosofia spiccia e produrre i piu' stravaganti ed incomprensibili formati e protocolli per il solo gusto di constatare poi quanto siano stati bravi nel far delle cose cosi' complesse, pertanto ho sempre osservato da lontano l'ambiente senza approfondire piu' del tanto necessario a comprendere il senso delle occasionali news che capitano sotto gli occhi. Ma qualcosa potrebbe forse cambiare nel prossimo futuro.
Tra le news di Techmeme trovo un riferimento all'intenzione del team di Twine (scarsamente conosciuto servizio di social bookmarking a la del.icio.us) di piazzare online un "editor di ontologie", ovvero una applicazione che faciliti la produzione, la pubblicazione e la condivisione di "descrizioni" di oggetti da impiegare poi per marcare i dati sull'Internet ed implementare poi all'interno dei programmi che potranno cosi' interpretare il dato e miscelarlo e/o presentarlo in modi nuovi. Sinora la tecnologia (o quantomeno: la discussione di essa, e qualche basilare applicazione) e' stata confinata nelle aule accademiche o sui blog tecnofili da geek, dunque impiegata al piu' in nicchie ben lontane dal mondo dei comuni mortali, ma se davvero si riuscisse a coinvolgere individui non-tecnici nella definizione di nuove astrazioni semantiche pronte per essere adottate in campi di pubblico interesse e fruizione sarebbe forse la volta buona per radicare lo strumento ed iniziare davvero a sfruttarlo.
Io stesso qualche tempo addietro stavo meditando sull'utilita' che avrebbe un web service esposto da GTT (l'azienda di trasporto pubblico torinese; ovviamente il discorso si applica anche a tutte le altre citta') per reperire in un formato programmaticamente trattabile le informazioni relative al traffico urbano, che al momento sono completamente raccolte e gestite dall'ente ma divulgate per mezzo di canali scarsamente riconducibili a qualsiasi forma riutilizzabile, ma dopo rapida ricerca ho notato la mancanza di una specifica adeguata a tale esigenza e che potesse realmente essere definita standard. Di casi simili ne esistono a volonta' e Swoogle non e' di particolare aiuto, ma cosi' come Wikipedia e' la piu' grande enciclopedia del mondo grazie anche e soprattutto al contributo di persone specializzate in settori non necessariamente legati alla tecnologia che hanno imparato quelle poche operazioni richieste per editare il wiki e riportare la loro conoscenza, allo stesso modo puo' esistere la possibilita' di far convergere nozioni ed esperienze diverse per costruire il substrato di interoperabilita' necessario ed indispensabile ad ogni altro futuro sviluppo del web semantico.

Un Task per Domarli Tutti

2009-03-22T15:15:00.002+01:00

Non nego che, sebbene continui a seguire la mailing list di sviluppo del progetto OpenMoko, da tempo abbia perso buona parte dell'interesse in merito a tale opera e solo di sfuggita legga le mail che transitano: troppo forte e' stata la delusione di avere tra le mani un FreeRunner completamente inusabile, e di vedere come OpenMoko Inc invece di darsi da fare per completare uno straccio di framework di sistema per il suo proprio dispositivo giocasse a mischiare tutto quanto ogni sei mesi ottenendo solo di spazientire la community.
Per un caso fortuito, seguendo il classico filone di links che rimandano da una news all'altra (sempre sia lodato l'ipertesto...), sono approdato alla pagina di uno dei componenti di cui piu' spesso ho visto menzionare il nome nella mailing list senza peraltro capire troppo bene di cosa si trattasse: Paroli. Assunto che non ho troppo ben capito come esso dovrebbe porsi nei confronti delle prossime versione della distribuzione OpenMoko (non doveva migrare tutto su Android???), di per se' il proposito mi sembra interessante; non fosse altro che e' lo stesso criterio con cui voglio costruire il prossimo SubConsciousDaemon!

Paroli (lemma che in esperanto significa "discussione": ottima scelta) non e' altro che un daemon di sistema il cui servizio e'... offrire servizi. In sostanza, wrappa l'uso di librerie e sottocomponenti rendendoli accessibili con una interfaccia (DBus) unificata, che descrive le operazioni piu' comuni e di interesse generale nel sistema (nel caso di OpenMoko: il networking, il GPS, il GSM...), permettendo di implementare una sola volta funzionalita' avanzate e renderle disponibili per tutti gli altri. Accentrando cosi' il codice prettamente funzionale si riduce la ridondanza di codice (da sviluppare, correggere e mantenere) e si induce al suo riuso ed alla creazione di inediti miscugli sinora non esplorati soprattutto per la complessita' della loro gestione.

Un poco alla volta, dunque, constato che la tendenza di accentrare le componenti funzionali di sistemi complessi isolandole e circoscrivendole dalle componenti grafiche si diffonde a si radica in sempre diversi frangenti: di anni dalla mia prima descrizione di tale architettura ne son passati assai, sono lieto che il tempo stia dando ragione (o quantomeno fiducia) a tale struttura. E non attendo altro che l'occasione di offrire la mia propria implementazione dell'idea, estremizzata all'interno del Progetto Lobotomy.
Non fosse per il fatto che tutto cio' e' in Python (linguaggio da me assai poco amato, e che a tutt'oggi mi domando e chiedo come si possa pretendere di utilizzare su un'apparato mobile con una potenza computazionale ridotta) potrei quasi pensare di riutilizzare tale componente all'interno della prossima incarnazione del mio personale progetto, correntemente in fase di progettazione e specificazione, ma e' probabile che esso sara' quantomeno fonte di ispirazione almeno per quanto riguarda la definizione dell'interfaccia programmatica con cui agganciare e rimuovere servizi e plugins.

Un Futuro che Non C'e'

2009-03-05T12:33:00.003+01:00

L'altro giorno mi e' passato sotto gli occhi un bellissimo filmato che, strano a dirsi, viene da Microsoft: esso rappresenta la "vision" dell'azienda per l'adozione massiccia di tecnologie oggi esistenti solo in forma prototipale e sperimentale, e piu' precisamente in previsione di cio' che gli utenti potrebbero avere a disposizione nel 2019. Superfici tattili di ogni tipo, interfacce completamente touch che mutano a seconda del dato presentato o del device su cui vengono impiegate, carta elettronica su cui viene proiettata l'informazione...
Certamente affascinante. Un ottimo cortometraggio di fantascienza.
Con cio' non voglio assolutamente dire che quanto espresso sia irrealistico ed infondato, anzi ho precisato fin dall'inizio che in fin dei conti questa non e' che una artistica raffigurazione di strumenti hardware e software gia' oggi esistenti ed in fase di piu' o meno avanzato sviluppo, ma tra il dire (non senza un pizzico di ingenuita', perdonata per le evidenti esigenze di copione) ed il fare vi e' il baratro dell'interpretazione dell'informazione.
Splendido sarebbe copiare una porzione di un grafico da un device all'altro semplicemente puntando e guardando attraverso l'apposito vetrino, ma per far cio' i tre componenti (mittente, destinazione, e chi trasporta il dato) devono comunicare nello stesso linguaggio, secondo lo stesso protocollo, scambiando bytes di cui conoscono il significato; impagabile sarebbe variare l'informazione numerica in un documento tabellare girando la manopolina virtuale proiettata sulla scrivania, ma per fare cio' chi proietta suddetta manopola e chi traduce il numero prodotto in barretta colorata devono condividere la nozione su come trattare l'input; meraviglioso sarebbe "esplodere" il disegno tecnico pigiando il ditino sulla scrivania su cui e' appoggiato il mazzo di chiavi, ma per far cio' la scrivania deve sapere cosa c'e' scritto nel suddetto schema ed in che modo i componenti rappresentati sono interagibili o meno.
Insomma: il semplice "pezzo di ferro", per quanto sofisticato, semi-trasparente, mobile e reattivo al tocco, non serve a nulla se chi lo gestisce non sa cosa fargli visualizzare, e come. Questo popo' di apparecchiature e' perfettamente inutile se non esiste una capillare ed universale adozione di standard aperti, che possano essere trattati in modo univoco all'interno dell'intera infrastruttura integrata. Che lo si voglia o no, finche' l'informazione e' tenuta prigioniera all'interno di files Office, o Photoshop, o AutoCAD, solo Office, Photoshop ed AutoCAD potranno accedervi. Non il vetrino da puntare, non la manopolina proiettata, non la scrivania.
E il problema non e' certo rimandabile al 2019, ma va affrontato subito, per il semplicissimo fatto che prima di arrivare allo scenario dipinto nel filmato in oggetto sara' necessaria una graduale migrazione dalle tecnologie odierne a quelle prossime venture: e' chiaro che coloro che inizieranno a commercializzare i singoli prodotti che compongono il puzzle dovranno avere la possibilita' in prima istanza di interagire in qualche modo con l'informazione esistente e farsi strada poco alla volta nella vita di tutti i giorni, sia essa quella casalinga o produttiva, ma fintantoche' tale informazione non e' accessibile e manipolabile all'interno di tali nuove interfacce le possibilita' di concretizzazione entro tempi umanamente accettabili sono estremamente scarse.
Dunque: se il video vi e' piaciuto, e non vedete l'ora di utilizzare quotidianamente strumenti di tal fatta, assicuratevi di lasciare campo aperto all'innovazione ed alla penetrazione di tali tecnologie. Pensateci due volte prima di bloccare la vostra informazione (o peggio ancora, l'informazione da condividere con altri) all'interno di files chiusi e non interoperabili.
Partecipate alla costruzione di un futuro che non c'e', ma con il buon senso di tutti potra' essere.

Metodo

2009-02-12T21:17:00.002+01:00

Da quando ho preso a lavorare per ItsMe un nuovo e stravagante mondo mi si e' aperto dinnanzi. Non parlo qui del contenuto del progetto stesso (su cui probabilmente in futuro avro' modo di soffermarmi), ma proprio della metodologia di lavoro con cui i diversi componenti del team di sviluppo interagiscono e si coordinano.
Specifiche, prototipi, diagrammi... Tutti concetti di cui ho forse sentito parlare molto lontanamente ai tempi dell'universita' ma su cui non mi sono mai soffermato, anteponendo ad essi la necessita' immediata: avendo negli ultimi tre anni scritto software ancor prima di sapere cosa dovesse fare, per riuscire a stare dentro a tempistiche e consegne gia' fissate ancora prima di mettere piede per la prima volta nell'ufficio torinese, ho sempre contemplato con distacco e diffidenza i dogmi dettati da questa strana dottrina chiamata Ingegneria del Software, e per abitudine e dimestichezza ho finito col gestire nello stesso modo un po' tutti i progetti con cui ho avuto a che fare sia professionalmente che amatorialmente.
Eppure ora scopro che il tempo passato a progettare e pianificare la propria applicazione, soprattutto se complessa e strutturata e ricca di interazioni, non e' proprio tutto tutto tempo perso.
Certo, non sono tutte rose e fiori: nessuno al mondo mi convincera' mai che uno schema UML abbia una qualsivoglia utilita', sia pratica che teorica, e neppure credo che l'"astrazione a tutti i costi" porti ad un approccio sano a quello che, volenti o nolenti, un giorno o l'altro dovra' essere tradotto in codice usando strumenti e librerie fatte in tutt'altro modo rispetto alla rappresentazione concettuale che ci si era fatti. Pero' molto altro si salva dalla mia osservazione critica: in primis il fatto di partire con la propria analisi non gia' dalla struttura del sistema ma da quello che dovra' fare e da cosa ci si aspetta che faccia in determinate condizioni, criterio apparentemente scontato ma non cosi' banale, ed in secundis la volonta' di implementare un prototipo per valutare sul campo l'API disegnata; a tutt'oggi storco un pochino il naso all'idea di scrivere del codice (in Python, oltretutto...) che ha lo scopo di essere buttato dopo una rapida occhiata, ma non nego che tale concetto possa risultare vincente nell'ottica di poter profilare l'architettura basandosi su dati reali anziche' su un disegnino tracciato su un foglio.
Ieri sera, per questioni personali, ho noleggiato un Virtual Private Server (cosa che suggerisco a tutti: oramai si pigliano ottime macchine a bassissimo costo, ed avere a disposizione una macchina sempre esposta sull'Internet e' una immensa comodita'), e tra i desideri del prossimo periodo vi e' quello di spostare su di esso lo sviluppo del Progetto Lobotomy: il sito, il repository (quando ci sara' del codice da condividere...), il futuro prototipo web di cui da tempo parlo, ma da principio credo che, al pari dei miei colleghi milanesi, installero' una istanza di Trac da usare come collettore di impressioni ed idee, da ordinare poi disciplinatamente e da cui estrarre poi una raccolta di "requirements" da usare come guida e riferimento in fase di definizione del sistema vero e proprio.
E che sia la volta buona che riesco a concretizzare almeno una parte delle infinite idee che ho in merito a tali ciclopica impresa.

La Sottile Linea

2009-02-12T00:29:00.003+01:00

Abbastanza inevitabilmente, dato il mio interesse sia per i progressi nel campo dell'interfaccia uomo-macchina sia per le novita' nel mondo freesoftware, mi trovo a leggere talvolta in merito a KDE4.
Sorvolando sui commenti piu' o meno soggettivi in merito alla stabilita' del prodotto o alla presunta somiglianza con il non propriamente amato Windows Vista e' interessante vedere come il team del progetto sia proiettato verso la sperimentazione di nuove forme di interazione e presentazione, e l'ultimo bollettino proveniente dall'ennesimo meeting degli sviluppatori menziona una serie di interventi che si vogliono apportare per perfezionare l'integrazione fra le componenti.
Ma il punto e' proprio questo: al di la' dell'introduzione del supporto alle animazioni, la sommaria integrazione con OpenDesktop, e la serie di nuovi plasmoidi che man mano vanno ad infoltire il set di quelli con cui l'utente puo' personalizzare, nell'attuale versione 4.2 ed in tutte le possibili evoluzioni annunciate e non, cosa c'e' di realmente nuovo? Quello che dall'intero mondo free viene osannato ed indicato come rivoluzionario e radicale progetto, cos'altro e' se non il solito desktop arricchito da qualche animazione? Persino il team di Gnome, environment che da sempre si caratterizza per la coerenza anche fra applicazioni diverse e la pulizia dell'API, sta cedendo alle lusinghe della popolatita' e per non essere da meno a KDE sta includendo deplorevoli funzionalita' di dubbio gusto.
So di aver ripetuto questa manfrina piu' di una volta, anche su questo blog, ma ogni qualvolta torno a leggere gli stessi entusiastici commenti rivolti a qualcosa che di entusiasmante ha poco se non gli screenshots torno a riflettere sulla questione: si cerca di elevare un pochino il grado di integrazione reciproca tra le diverse applicazioni, si aggiungono strabilianti features grafiche (che non fanno altro che aggiungere possibilita' di infrangere ogni genere di coerenza tra le applicazioni), eppure la sottile linea che separa l'innovazione dal rimaneggiamento non viene mai oltrepassata.
Mi capacito del fatto che tale linea, in fin dei conti, tanto "sottile" non e', in quanto implicherebbe una riscrittura drastica dell'intero concetto di "computer general purpose con una interfaccia grafica", ma chiaramente ci si trova sempre a scontrarsi con l'abitudine della becera utenza e l'impossibilita' di diffondere agevolmente presso la massa elementi di novita'.
Ah, ho una gran voglia di tornare a lavorare su Lobotomy...

Ma il Multitouch...

2009-02-07T00:11:00.003+01:00

Da lungo tempo, e soprattutto da quando l'iPhone rappresenta uno dei maggiori centri di gravita' dell'informazione spiccia tecnologica, si fa un gran parlare di multitouch. Ogniqualvolta esce un nuovo dispositivo, in particolare mobile, uno dei primi criteri di valutazione e' il suo supporto a tale meccanismo di input: se e' possibile usare piu' dita per manipolare l'interfaccia e' figo, altrimenti no.
Poco tempo addietro ho marginalmente toccato l'argomento facendo notare che ancora non avevo espresso un mio parere completo nei confronti di tale strumento, ed e' venuto il momento di approfondire.
Quando vidi il primo (o comunque il piu' noto) video in cui veniva mostrata una interfaccia di tal fatta ne rimasi come tutti entusiasta, anche se chiaramente la maggior parte della mia ammirazione derivava dalla novita' e dalla teatralita' dell'effetto in se'. Da allora altri filmati sono spuntati in Rete a decine, a centinaia, in ogni dove, in cui si vedevano persone che navigavano mappe, ridimensionavano e spostavano foto, e... Beh, nulla di piu'.
Alla fine e' evidente che allo stato odierno la tecnologia c'e', ma non ne esiste alcun utilizzo pratico: certamente questa e' solo una impressione dettata dal fatto che la stragrande maggioranza dei demo puntano a stupire l'utente medio, ed il software per trattare il ridimensionamento delle immagini allontanando ed avvicinando le dita e' sufficientemente banale (di librerie, anche open, che permettono di farlo e' pieno) da garantire un bel risultato scenografico con un minimo sforzo, ma finche' non esistera' una innovazione che renda codesto meccanismo realmente appetibile temo che cio' restera' semplicemente un decorativo orpello da nerd ed una strategia di marketing.
Gia' ce n'e' voluto del buono per ottenere qualche progresso nella fase di studio per un paradigma di user interface adatto al touchscreen, e comunque siamo ancora lontani da un risultato ottimale; figuriamoci quanto si dovra' attendere prima che il multitouch diventi parte integrante di tale paradigma. Ed io stesso non riesco a figurarmi particolari funzionalita' speciali che potrebbero essere implementate solo in virtu' del tocco multiplo.
Dunque: al momento non mi faccio particolarmente impressionare quando nel corso di una presentazione l'imbonitore di turno orgogliosamente fa vedere le sue agili ditina andare parallelamente su e giu' sullo schermo, e neppure mi curo del fatto che un tale apparato abbia o meno tale supporto hardware. Di strada da fare prima di arrivare a quello ce n'e' ancora tanta.

Divide et Impera

2009-01-29T00:26:00.003+01:00

Oramai ho cosi' tanti e variegati impegni che finiscono col sovrapporsi l'un l'altro secondo i piu' arzigogolati percorsi, ma cio' ha il lato positivo che con un singolo task ottengo piu' risultati utili per contesti completamente diversi. E' questo il caso del modestissimo progettino (sarebbe meglio chiamarlo "giocattolo") che ho aperto l'altro giorno su BarberaWare: Mignon, un client per le webradio.
In un colpo solo ho ottenuto: un playground ove iniziare a pacioccare e a prender mano con Python, orribile ed ingestibile linguaggio che mi tocca apprendere per assolvere ad alcune richieste del mio nuovo prossimo lavoro; un programmino da eseguire prossimamente nel PC recentemente installato in cucina, e con cui ascoltare il giornale radio cenando pur senza dover portare a spasso il laptop come attualmente faccio; una prima implementazione sperimentale di un concetto che gia' riportai su questo blog, in merito alla netta divisione di funzionalita' ed interfaccia del software. Sorvolo qui sulle invettive all'indecente linguaggio sopra menzionato ed alle mie abitudini domestiche, mentre mi soffermo su qualche considerazione in merito all'ultimo punto (l'unico dei tre in-topic su questo blog), forse banale e non particolarmente ricca a causa della modestia della mia attuale esperienza ma che quantomeno riporto per conoscenza.
Sviluppare una applicazione ove funzionalita' e interfaccia sono distinte non e' complesso, quantomeno non piu' che non progettare e realizzare un qualsiasi altro software con un po' di criterio: l'unico elemento cui probabilmente occorre prestare particolare attenzione e' la quantita' e la frequenza degli scambi di informazione tra i due strati: avendo a che fare con un protocollo IPC (che sia DBus o una coda di messaggi poco importa, sempre un qualche tipo di syscall esplicito o implicito e' necessario) meno memoria si sposta e meglio e', e le risposte non possono essere ne' istantanee ne' in realtime come all'interno di un unico processo. Di contro, come ci si puo' bene immaginare la flessibilita' della piattaforma e' completa: al momento il mio modesto programmino dispone solo di una umile interfaccia a linea di comando, ma gia' sto progettando di realizzare quella grafica in QT (altra tecnologia che mi tocca apprendere per intraprendere il mio nuovo mestiere) e quella web senza intaccare minimamente il core dedito all'interrogazione dei vari servizi di directory dei canali radio e alla riproduzione audio.
In sostanza: il paradigma mi garba e mi sembra utilizzabile senza particolare sforzo.
Un colpo al cerchio ed uno alla botte, alla fine qualcosa riesco sempre a combinare...

Canale Libero

2009-01-19T00:11:00.004+01:00

Gia' da qualche tempo avevo scoperto identi.ca, servizio di microblogging in tutto e per tutto simile a Twitter ma la cui piattaforma e' interamente opensource e costruita intorno a standard aperti. Ma all'epoca mancavano ancora tanti servizi e tante features, quelle che rendono davvero utile (se davvero il microblogging puo' essere definito "utile"...) una applicazione del genere, cosi' lasciai perdere e rimasi sul piu' noto e supportato Twitter.
Questa sera per qualche strano motivo sono tornato a dare uno sguardo al sito, ed ho visto che grandissimi passi avanti sono stati fatti: molte piu' funzionalita', una serie di correzioni piu' o meno evidenti, ed un numero di applicazioni che sfruttano i contenuti pubblicati per mezzo del servizio per trasformarli in mille modi. E cosi', dopo una mezz'oretta passata a ritoccare qua e la', sono riuscito a ricostruire la catena di strumenti da me usata: con Ubiquity aggiungo nuovi "post" nella mia pagina, una applicazione dedicata li piglia e li usa per aggiornare il mio status su Facebook, ed un'altro servizio preleva il feed RSS e ne ricava il bagde visualizzato nel mio blog.
Per quanto identi.ca non raggiungera' forse mai la popolarita' di Twitter (ma non e' detto: spesso quest'ultimo e' fuori servizio, e la prossima messa a punto del suo businness model potrebbero renderlo meno aperto verso gli innumerevoli servizi esterni forniti) e' bello vedere che una community abbia realizzato tutto questo, soprattutto alla luce degli avvenimenti recenti: sempre piu' pressioni si fanno per adoperare e far adoperare standard aperti sull'Internet in modo da garantire interoperabilita' tra le piattaforme, e non pochi sono coloro che sostengono l'utilizzo di software a codice aperto anche sul web in modo da stimolare la nascita di sempre nuovi e ricchi strumenti non solo da parte dei colossi (che in questo periodo di crisi certo non hanno troppi soldi da creare e mantenere iniziative eccessivamente stravaganti) ma anche e soprattutto per mezzo di volontari col pallino per la programmazione; persino Google sta ponderando il rilascio del codice di Jaiku, altro sito di microblogging spesso identificato come l'anti-Twitter, a fronte dell'eccessivo carico di risorse necessarie per mandare avanti la baracca.
E da oggi anche le mie microfacezie sono free as in speech...

Tooltip o non Tooltip

2009-01-16T00:10:00.003+01:00

Da qualche tempo sto sperimentando all'interno di GASdotto una soluzione che, nell'idea, dovrebbe essere un compromesso per l'esposizione di un help contestuale da fornire all'utente per permettergli di muoversi tra le opzioni offerte dall'interfaccia.
Partiamo da qualche assunzione: per quanto le icone possano rappresentare un bell'aiuto in termini di individuazione dei tasti e delle funzionalita' desiderate in ogni momento, purtroppo non sempre possono essere universalmente autoesplicative e comunque l'utente, almeno la prima volta che vede l'interfaccia, non ha idea di dove trovare cosa e non si puo' dunque giocare sulla sua consuetudine. Soprattutto in un programma (come appunto GASdotto) destinato ad essere usato saltuariamente, senza una frequenza costante, e per cui dunque ogni nozione appresa dall'utente puo' essersi persa nell'intervallo tra una sessione e l'altra.
Una qualche sorta di aiuto contestuale che guidi e sostenga l'utente nell'utilizzo e' pressoche' d'obbligo, sebbene sia indispensabile raggiungere un compromesso affinche' tale help in linea sia efficace ma non risulti invasivo.
Quel che e' quasi uno standard de facto in tale contesto, almeno sul desktop, sono i tooltips, ovvero quelle frasette che appaiono passando e soffermando il cursore del mouse sull'elemento di cui si vuol conoscere la funzione. Tale metodo, pero', mi pare estremamente poco efficiente e prono ad ogni genere di abuso: ci sono tooltips lunghi venti righe che includono tutto lo scibile in merito al dato tasto, altri che non riportarno null'altro se non il testo del pulsante stesso (risultando percio' poco informativi...), ma la situazione peggiore in assoluto (nonche' la piu' comune) si verifica quando solo alcuni elementi sono forniti di un tooltip ed altri no: quante volte e' capitato a me stesso di constatare la presenza della finestrella gialla in sovraimpressione passando in un dato punto, spostare il mouse laddove mi serviva, attendere un istante la comparsa della descrizione, muovere ancora un poco il cursore per essere ben certo di aver centrato il tasto di cui avrei gradito un commento, ed alla fine capacitarmi del fatto che nessun tip era disponibile per quello!
La soluzione da me adottata trae ispirazione dalla piu' recente versione di Wordpress: editando uno dei numerosi blogs che mantengo su tale piattaforma ho visto come passando il mouse sui titoli dei posts che appaiono nella lista di articoli modificabili spuntino i links che ne permettono la correzione, la cancellazione ed altre attivita', tutte opzioni che se visualizzate tutte insieme avrebbero appesantito la pagina ma in questo modo risultano comodamente raggiungibili e molto facilmente "scopribili". Per il prossimo futuro vorrei meglio analizzare questo approccio, ma per adesso mi sono limitato a scopiazzarlo impunemente per trattare, come detto sinora, l'help.

Per accertarmi che ogni utente sapesse come comportarsi nei confronti delle tre icone associate ad ogni elemento editabile (salva, elimina, o annulla operazione) ho pensato di piazzarvi sotto una descrizione che apparisse solo al passaggio del cursore del mouse, affinche' il testo non andasse ad incidere sulla linearita' della pagina ma al contempo fosse visibile nel momento opportuno.
Sono abbastanza soddisfatto di questa soluzione anche se ammetto necessiti forse di migliore implementazione (il codice e' talmente elementare che non sto manco a pubblicarlo), cerchero' di riutilizzarla anche in altri contesti per valutare la sua bonta'.

Una Idea... Rimane una Idea

2009-01-11T02:59:00.003+01:00

Dopo aver visto il video integrale del keynote in cui e' stato presentato il nuovo sistema Palm, ed avere avuto nuova conferma che le fonti di informazione spesso risultano eccessivamente fuorvianti ed e' indispensabile ricorrere a news di prima mano, inevitabilmente stendo un seguito al post di ieri aggiustando la mira.
E' vero che l'intera piattaforma e' costruita su tecnologie web, ma falso che i dati saranno cosi' tanto integrati quanto lasciato intendere negli entusiastici dispacci giunti dal CES (fiera tecnologica in cui il Pre' e' stato presentato).
Piu' nel dettaglio, di seguito le impressioni che mi sono fatto.

Idee vecchie fatte passare per grandi innovazioni, e/o autentiche fesserie:

liste che scrollano con l'attrito, foto che si scorrono spostando il dito a destra e a sinistra, zoom delle pagine web, rotazione automatica dello schermo... Le solite menate cui il pubblico applaude senza un motivo preciso, mi sa che anche nei grandi eventi fieristici ci sono gli omini che sollevano il cartello "Applausi" come negli studi televisivi...
interfaccia multi-touch: molto carina da far vedere nel corso dei keynote dinnanzi ad una folla di geek ma gia' popolarizzata da Apple e a parer mio poco usabile all'atto pratico. Mi accorgo adesso di non aver mai parlato su questo blog del mio parere in merito ai multi-touch, dovro' farlo prossimamente
sincronizzazione con servizi web: qui sta il nocciolo della decantata fusione ed astrazione tra i dati che mi aveva fatto pensare ad un plagio delle mie idee, ma molto piu' banalmente l'apparecchio gestisce in modo unificato le mail che arrivano da piu' accounts o gli eventi che arrivano da diversi calendar o i contatti i cui frammenti di informazione arrivano da sorgenti sparpagliate. Nulla di cosi' rivoluzionario, anzi era ora che si provvedesse ad un wrapper decente dei numerosi servizi web e ad una interfaccia comune per tutti, anche se mi perplime immensamente il fatto che sta' baracca sia particolarmente integrata con Facebook: ai fatti sara' poi possibile aggiungere nuovi moduli per wrappare anche altri servizi di mail, calendar e contatti, o GMail e Facebook sono inclusi e gli altri si attaccano al tram?
totale incoerenza delle applicazioni: una ha particolari colori, un'altra ne usa altri, tasti decorati in un modo qui, tasti decorati in un'altro modo la'. E' evidente che ogni sviluppatore potra' personalizzare l'aspetto del proprio programma come gli garba, nel bene e nel male

Idee carine e/o molto azzeccate:

la discriminazione tra notifiche semplici e notifiche grandi: in alcuni casi basta passare all'utente una stringa che apparira' nell'apposita area per le notifiche discretamente piazzata al fondo dello schermo, in altri urge adottare una interfaccia piu' complessa, in entrambi i casi l'attivita' corrente non viene interrotta o disturbata piu' di tanto
task management: sebbene non mi strappi i capelli gridando al miracolo e' stato comunque implementato decorosamente il meccanismo per aprire nuove applicazioni, passare da una all'altra, e chiuderle. Il rinomato paradigma delle "cards" si risolve in una lista di finestrelle che si possono scorrere e riordinare (non si capisce per quale motivo lo si dovrebbe fare...)
interfaccia a scomparsa: nel caso del Pre' e' stata implementata solo in quella che potrebbe essere definita l'equivalente della taskbar, ovvero una barretta invisibile che compare (con una bellissima quanto inutile animazione) con una particolare gesture e permette di ricondurre rapidamente ad una applicazione gia' aperta, ma di per se' il concetto di avere porzioni di interfaccia che compaiono solo su richiesta e solo per il tempo necessario per scorrere col dito sulla funzionalita' desiderata non e' malaccio. Ci dovro' fare un pensiero...

Nel complesso la mia curiosita' nei confronti della piattaforma rimane immutato, anche se devo rimangiarmi quanto precedentemente affermato in merito alla gia' menzionata questione dell'interpretazione e manipolazione universale dei dati. Il mondo non e' ancora pronto a trattare ogni frammento di informazione in modo flessibile, come al solito dovro' far da solo.

Una Idea e' Sempre una Idea

2009-01-09T17:47:00.006+01:00

Vi e' mai capitato di avere una idea per qualcosa di completamente nuovo, mai visto prima, e dopo pochi giorni vedere l'annuncio di qualcuno che sta facendo quella stessa cosa? A me si, anche piuttosto di sovente, ma mai ho percepito il plagio come in questa occasione.

Nei tempi passati ho su questo blog fatto cenno ad un mio proposito per i prossimi sviluppi del Progetto Lobotomy, anche se non ho mai approfondito sia a causa dello scarso tempo a disposizione per ponderare sull'intuizione ed esprimermi qui sia per il desiderio di provare ad implementare uno straccio di modello sperimentale prima di fare annunci in pompa magna. In sostanza, quel che avevo in mente era di costruire una sorta di prototipo del modello descritto nell'ultimo documento di definizione dell'interfaccia di Lobotomy usando strumenti web, magari lo stesso Web Toolkit con cui da qualche tempo nel bene e nel male lavoro impratichendomi sempre piu', onde accellerare lo sviluppo e verificare se tale soluzione potesse essere adottata anche in via definitiva nell'implementazione finale del sistema, portando di fatto alla realizzazione di una interfaccia pienamente integrata con l'Internet, di rapido sviluppo e velocemente adattabile al mondo desktop ed a quello mobile senza troppi stravolgimenti.
Ci ho pensato un po', mi sono interessato a tutti i piu' recenti strumenti che avessero potuto essere usati a tale scopo, ho iniziato a pensare a riutilizzare un po' del codice e dei concetti sinora strutturati per GASdotto, ed oggi... Leggo su OSNews che, in modo del tutto imprevedibile, Palm presenta sul mercato con una cosa identica.

Un nuovo sistema operativo, una interfaccia completamente costruita su tecnologie web, la possibilita' di integrare i propri componenti in HTML, CSS e Javascript.
Ma se la similitudine al mio pensiero si limitasse solo a quello lo potrei accettare: l'idea di usare gli oramai potentissimi strumenti per la Rete per implementare una soluzione destkop non e' nuova, i web desktop esistono da anni e numerosi sono stati i tentativi di integrare locale con remoto. Quel che realmente mi suona ancor piu' famigliare e' l'architettura del nuovo ambiente introdotto da Palm per i suoi dispositivi mobile.
Leggo dall'articolo:

The fact that smartphones today are all application-centric shows where their software comes from and where their roots lie: the desktop operating system. Palm is changing all this with its card-based interface, where the application is irrelevant - it's all about the task.

Per farla breve: niente applicazioni standalone, solo delle interfacce (da loro chiamate "cards") da applicare ai dati per interagire con essi. Ne' piu' ne' meno di quanto io scrissi mesi fa' immaginando il metodo ideale per ottenere il massimo dell'integrazione e dell'estensibilita' con il minimo sforzo.

Che ci sia qualche ingegnere Palm che comprende l'italiano e legge il mio blog?

Ad ogni modo, sorvolando su improbabili plagi e scopiazzature, sono ben lieto di vedere che qualcuno abbia avuto la mia stessa visione, e che questo qualcuno non sia il primo che passa ma anzi un affermato colosso: evidentemente non sono tutte campate per aria le mie supposizioni. Non mi resta che attendere di dare una occhiata a quello che sara' il prossimo SDK (e certamente ce ne sara' uno, se Palm intende far concorrenza all'iPhone inevitabilmente permettera' a tutti di lavorare su software addizionale che arricchiscano la piattaforma) e vedere in che modo e' stata stabilita l'interfaccia verso il sistema, cosa viene lasciato alla discrezione del developer e cosa e' implicito nella struttura stessa, e come le "cards" interagiscono tra loro e con il contenitore che le circonda.

Ah, non avessi tutti questi impegni e potessi dedicarmi integralmente a Lobotomy per un po'... Ma, se potessi mangiare un'idea, avrei fatto la mia rivoluzione...

Utenti Ribelli

2009-01-04T03:30:00.004+01:00

Che gli utenti facciano sempre il contrario di quanto dovrebbero fare per un corretto uso degli strumenti informatici e' cosa gia' detta e risaputa, ma talvolta incorro in episodi che mi lasciano interdetto.

L'aneddoto di oggi: in questi giorni sto passando il tempo realizzando un applicativo web che ha lo scopo di semplificare ed automatizzare le operazioni di gestione e manutenzione di un GAS (Gruppo di Acquisto Solidale), permettendo ai responsabili di definire gli ordini per i vari fornitori e agli altri membri di avanzare richieste per tre chili di carne di vitello con certificazione biologica o una latta di olio extravergine siciliano.
Questa sera, dopo aver caricato online la prima demo dimostrativa da far provare ai miei collaboratori (e di cui non pubblico l'URL: e' ad uno stato talmente primordiale di sviluppo che finirei solo col fare una figuraccia se la si vedesse...), ho fatto un giretto sulla Rete e sono involontariamente incappato nel blog del GAS di Avigliana, ridente paesello a poca distanza da Torino. Scorro rapidamente i post, e noto che essi hanno adottato come soluzione gestionale un tal GestiGAS, applicativo nelle finalita' analogo a quello di cui mi sto occupando ed altrettanto freesoftware ma risultato (tanto per cambiare...) eccessivamente ostico ed inopportuno nell'utilizzo da parte di persone con scarsissima dimestichezza col computer, come appunto la maggior parte dei membri dei gruppi di acquisto.
Fatto sta che scendendo di poco nella pagina trovo, in mezzo alle altri frasi ed al termine della descrizione di una serie di prodotti, una frase in verde isterico e con carattere ingrandito:

CONCLUDENDO .... compito delle vacanze: andate su gestigas (sigh!) ed inserite le vostre prenotazioni!!!

Mi son chiesto il perche' di quel "sigh" tra parentesi, e sono andato a leggere i commenti del post: ben quattro persone hanno riportato le loro richieste di arance e limoni direttamente sul sito, totalmente incuranti dell'esistenza di un form da compilare. Ho guardato i commenti di tutti gli altri post, ed in tutti appariva la stessa cosa: sfilze di richieste immesse da individui che hanno ritenuto piu' conveniente scrivere in una frase sulla bacheca pubblica quel che desideravano anziche' aprire un'altro sito, autenticarsi, cercare la pagina relativa all'ordine ed inserire i valori nei campi giusti. Con buona pace del tapino che di volta in volta deve andare a controllare cosa e' stato scritto e da chi (dovendo poi richiedere conferma via mail o telefono, in quanto la stragrande maggioranza di tali commenti riportano il nome del committente ma sono inseriti senza autenticazione, anonimi da un punto di vista digitale, e dunque potenzialmente fasulli), e riordinare il tutto prima di contattare l'allevare o l'agricoltore di turno e sapere cosa dirgli badando di non sbagliare nel farsi mandare qualche cassetta di agrumi di troppo che poi non si sa a chi rifilare.

Esiste modo di ovviare a cotanto sperpero di strumentazioni tecnologiche e a siffatta pigrizia da parte dell'ingenuo consumatore equosolidale e velleitariamente consapevole? La risposta e' "no".
O meglio: non v'e' modo di convincere l'utente a fare la cosa che andrebbe fatta (ovvero: mettere la quantita' di cassette di arance che vuole nella casellina del form, in modo da avere alla fine informazioni precise e puntuali), per tante motivazioni: la consueta ed oramai scontata resistenza dinnanzi a qualcosa che vada al di la' della sua abitudine ("E' troppo complesso, non sono capace", detto solitamente ancora prima che qualcuno gli spieghi il comportamento che dovrebbe tenere), l'effettiva incapacita' nello svolgere il task (questo molto dipende da quanto e' ben fatta l'interfaccia davanti cui si trova, se non e' assolutamente chiaro qual'e' il percorso virtuale di tasti e pannelli da affrontare per arrivare alla casella da riempire per avere delle arance e' facile che ci si trovi da tutt'altra parte ed alla lunga si desista), e sopra ogni altra cosa l'innata pigrizia che caratterizza una buona percentuale della popolazione, in particolare quella italiana.
Ma, in fin dei conti, se Maometto non va alla montagna la montagna va da Maometto: basta saper uscire dai soliti schemi, quelli per cui il programma e' quello che si vede nella relativa finestra sul monitor (o al relativo URL, nel caso del web) e basta. Se l'utente non va all'applicazione, l'applicazione andra' dall'utente: da ieri sera contemplo la pagina di documentazione dell'API Gadgets provvista da Google, con l'idea di realizzare una versione ridotta e "embeddabile" del mio modesto software in iGoogle, Blogger ed altre piattaforme simili e compatibili. Scopo del gioco: rendere trasparente l'interazione con il programma, e mettere a portata di mouse i pochi tasti necessari ad avanzare la propria richiesta di una cassetta di arance affinche' risulti ancor piu' rapido e conveniente che non scrivere una mail o lasciare un commento nel blog. Gestendo in modo opportuno autenticazioni (da richiedere il minor numero di volte possibili), links (fatti apposta per identificare sia l'utente che un determinato prodotto con hash salvati a monte sul database in modo da poterne invertire il significato) ed una serie ristretta di informazioni rilevanti per l'utente, il gestionale esce dalla sua sede e va a mettersi proprio sotto gli occhi di chi deve usarlo.

Partito come un semplice favore da fare ad un amico e come pretesto per affinare l'utilizzo delle tecnologie di sviluppo web, questo lavoretto sta poco alla volta rivelandosi una succosa sfida tra me ed una pletora di personaggi con una scarsissima voglia di collaborare.
Riuscira' il vostro eroe a realizzare un software che sia realmente utilizzato ed amato da individui con competenze tecniche pari a quelle di una zucchina (rigorosamente biologica)?. A noi non e' dato sapere cio' che il destino gia' sa.

Snippets

2009-01-02T13:29:00.003+01:00

Gia' mi son ripromesso di farlo piu' di una volta, ma cavalcando l'onda di entusiasmo e buona volonta' che ha accompagnato l'inizio del nuovo anno mi ci son messo davvero. In realta' unisco una idea vecchia ad una nuova: quella di arricchire la comunicazione con il mondo esterno con il supporto di contenuti multimediali (foto e video), e quella di impegnarmi per meglio ingegnerizzare frammenti di codice ideati per le mie opere ma che siano facilmente riutilizzabili da chiunque.
Ho or ora attivato un account su Vimeo (dopo aver provato con scarsa soddisfazione YouTube), e vi ho caricato un primo video dimostrativo di una classe per GWT che pubblicai qualche tempo addietro su BarberaWare e che ho preso ad utilizzare con regolarita' nelle mie applicazioni web.

Suddetta classe implementa un concetto piu' volte ritrovato nel blog di Humanized e di Aza Raskin, nonche' implementato con discreto successo in Songza ed in Amarok (sotto il nome di OSD, On-Screen Display): evitare i dialog modali e sostituirli con notifiche temporanee, visibili ed identificabili dall'utente ma che non richiedano un suo intervento per essere chiuse. Nel caso specifico della mia classe e' possibile includere questo genere di notifiche nelle proprie applicazioni web scritte in GWT, personalizzandone l'aspetto attraverso il CSS e lasciando che il codice si occupi di schedulare le visualizzazioni e trattare il fading del messaggio mostrato.

Conto di produrre e discutere qui altri frammenti nel prossimo futuro, che andranno a coprire via via le aree in cui mi trovo a lavorare; nel piu' imminente periodo fin troppo mi soffermero' sullo sviluppo web, essendo all'opera su ben due applicazioni (una privata ed una open), e vedro' di produrre per ognuno un piccolo demo video che ne dimostri la funzionalita': lungi da me dall'arrivare ai livelli del celeberrimo MacSlow, che di filmati ne divulga pochi ma ogni volta sa stupire con incredibili effetti speciali, ma nel mio piccolo spero di contribuire con qualche poco di codice e qualche osservazione che possa risultare utile ad altri.

Un Blog per Domarli Tutti

2009-01-01T01:42:00.003+01:00

Un po' mi spiace iniziare l'anno con un post cosi' fortemente off-topic, ma in fin dei conti se non mi faccio "pubblicita'" da solo non posso sperare che il mio messaggio si propaghi.
Con l'inizio del nuovo anno avvio da subito la concretizzazione dei propositi raccolti sinora, iniziando da... il blog.
Da quando il mio contratto ADSL con Tin.it e' stato chiuso e non posso mantenere il mio server domestico a causa del NAT dietro cui mi trovo con la connessione (neppure cosi' stabile, in fin dei conti) di Vodafone non ho piu' potuto esporre sull'Internet madbob.homelinux.com, mia storica nicchia telematica che mi ha accompagnato fin dall'inizio della mia permanenza in Torino. Ma mi e' assai dispiaciuto non avere piu' una pagina su cui esprimere le mie critiche ed i miei giudizi, soprattutto adesso che sempre piu' forte e' la necessita' di far emergere le magagne del mercato IT ed offrire spunti di riflessione per la ricostruzione del Nuovo Mondo che ci si aspetta sorga dalle ceneri lasciate dal rogo della crisi internazionale.
Lascio pertanto spento il mio server casereccio (che, diciamocelo, su una Rete in cui si parla solo piu' di cloud computing e' diventato cosa obsoleta e fatiscente) ed intraprendo una nuova avventura: da qualche minuto e' sull'Internet madbob.wordpress.com, prossimo contenitore dei piu' arditi ed intransigenti post che possano scaturire dalla mia usurata tastiera. lobotomy-dev.blogspot.com continuera' ad essere collettore di divagazioni squisitamente tecniche, mentre chi vorra' di quando in quando leggere un mio commento di natura piu' trascendente potra' fare un salto a tale URL; nel prossimo futuro conto anche di raggruppare i feeds provenienti dall'uno e dall'altro blog in un unico RSS, si' da permetterne l'importazione su Facebook e garantire a tutti la fruizione del Bob-pensiero in ogni sua forma e sfumatura.
Che sia un buon anno per tutti. Un po' anche per me.

Usabilita' e Computazione

2008-12-23T22:05:00.003+01:00

Festeggio il mio prorompente ritorno alla Grande Rete (ho ritirato oggi la chiavetta USB per la connettivita' 3G, alla faccia di Tin.it che mi ha sospeso l'ADSL) con un post sul mio bistrattato blog.
Quello che voglio esporre e' qualche considerazione sul ruolo dell'usabilita', o quantomeno dello studio dell'interfaccia utente con cui si presenta un software, non gia' in un'ottica estetica o funzionale ma prestazionale.
Come sempre, un riferimento a fatti realmente accaduti: come forse gia' citato in passato al momento sto lavorando a tempo perso su un gestionale web costruito con tecnologia Ajax (nella fattispecie con GWT), il cui piu' grosso difetto e' il committente. Questo arnese mi e' stato richiesto da gente con scarsissime competenze di sviluppo software, che campa spacciando prodotti altrui ma farebbe piu' bella figura ad andare a vendere il pesce al mercato, e che vuole ad ogni costo dir la sua non solo sull'aspetto ma su tutto il paradigma d'uso dell'applicazione; all'inizio ho tentato di raggiungere un compromesso, cercando di farli ragionare e fargli comprendere nozioni essenziali (ad esempio il fatto che un applicativo web non funziona esattamente come un applicativo locale), ma alla lunga mi son stufato e con mio sommo rammarico sto un poco alla volta mettendo insieme un accrocchio di pulsanti sparpagliati, campi anonimi e dati presentati a casaccio. Il punto sta nel fatto che per riuscire a gestire la quantita' di baggianate che devo visualizzare in un dato momento (ovvero, quello sbagliato) e non impazzire con un trattamento granulare dello stream proveniente dal server ho via via astratto e stratificato le componenti, tanto che in determinati contesti la quantita' di bytes da scambiare asincronicamente attraverso l'Internet (e, dunque, lentamente) e' talmente grande da rappresentare la causa di ogni rallentamento nell'utilizzo del programma.
Certamente molti passaggi si potevano risparmiare con una piu' accurata analisi progettuale (cosa impossibile, dato che il mio cliente cambia idea piu' spesso di quanto cambi le mutande. Mi consolo all'idea che, stando a quanto raccontato da amici con esperienze ben piu' ricche delle mie, tutti i clienti siano cosi'...), o con una piu' ponderata gerarchia di oggetti con una migliore interfaccia, ma guardando il risultato vedo come certe funzionalita' siano talmente poco consistenti rispetto all'interfaccia da richiedere la generazione di un massiccio traffico client/server per poter andare a recuperare informazioni che non c'entrano nulla con quanto gia' prelevato, visualizzato ed in cache.
La morale di questo post e' che talvolta uno studio effettivo dell'interfaccia non abbia solo finalita' "filosofiche" (perche', ricordiamolo, spesso l'usabilita' e' considerata un fattore prettamente filosofico ed inconsistente, scorrelato dalla funzionalita'...), ma puo' far risparmiare grosse dosi di computazione inutile. E sul monitor appaiono tasti che non hanno ragione di esistere.

Senza Volto

2008-12-15T14:35:00.003+01:00

Inevitabili le mie scuse per la sempre maggior rarefazione dei post su questo blog, ma l'ultimo periodo e' stato sufficientemente delirante, sono temporaneamente senza connessione casalinga (causa assorbimento di Tin.it in Telecom e susseguente chiusura dei contratti ADSL), ed i prossimi mesi saranno ancora peggio. Numerose volte ho letto o sentito qualcosa che mi ha ispirato commenti che avrebbero dovuto essere riportati qui, ma il tempo di stendere un testo decoroso e' sempre quel che e'.
Veniamo al sodo, ovvero a qualche constatazione sulla disponibilita' di applicazioni grafiche open.
In capo a pochi mesi mi e' gia' arrivata da piu' fonti nella mia cerchia di conoscenze tecnologicamente consapevoli una stessa osservazione, che ho a mia volta per incidenza constatato lavorando su tutt'altro: il panorama opensource e' ricco, florido, traboccante di librerie e framework per fare qualunque cosa, ma... mancano applicativi utente che rendano accessibili tali funzionalita'.
Un esempio tratto dalla mia esperienza recente: un amico da poco con il pallino da radioamatore insiste affinche' implementi un certo strumentino (rigorosamente per Linux) per l'analisi dei segnali audio, qualcosa di abbastanza semplice per poter fare un ben specifico tipo di studio. Di per se' tale programma non dovrebbe far altro che prendere un file .wav, tirarne fuori una trasformata di Fourier, e trarre qualche conclusione in funzione della distanza di determinati picchi a determinate frequenze. Mi sono assai stupito di non trovare qualcosa di gia' pronto nell'apparentemente vasto insieme di software free dedicato appunto ai radioamatori: ci sono dozzine di applicativi che eseguono analisi assai spicce e sommarie, disegnano simpatici grafici di scarsa utilita' se non coreografica, ma ben poco che si avvicini a quanto sinora descritto. Eppure della Fast Fourier Trasformation, funzione matematica alla radice di un po' tutta la scienza dell'analisi audio, esistono numerose implementazioni (fra cui una in particolare e' stata ottimizzata e perfezionata in ogni modo possibile): perche' non vengono sfruttate in software completi ed usabili dall'utente finale?
Qualcuno potrebbe obiettare che il mio esempio tratti una ristretta nicchia di utenza e che l'interesse nell'impiegare risorse umane per realizzare quanto richiesto e' limitato, ma analoghe situazioni si trovano anche in settori di assai piu' ampio consumo: tanto per dirne un'altra, poco tempo addietro un ennesimo amico mi ha fatto notare l'assenza di un qualsivoglia banale programma che permetta di ricavare un video a partire da un insieme di immagini statiche (a mo' di slideshow, insomma), ed io stesso, che nel prossimo futuro dovro' confezionare una serie di filmati mettendo insieme appunto foto, testi e qualche breve spezzone, con ogni probabilita' mi trovero' nella condizione di dover implementare un programmello che faciliti l'aggregazione di slideshow multimediali con effetti decenti materializzati con Clutter e passi il tutto a gstreamer.
Come si giustifica un tale prodigarsi di strumenti software di basso livello, di librerie e frammenti di codice atti a ogni genere di trasformazione matematica (e, dunque, di qualsiasi altro genere), cui non si controbilancia l'esistenza di reali applicativi che portino cotanto popo' di scienza alla portata del mouse? Il quesito e' di difficile risoluzione: indubbiamente una delle motivazioni e' la lontananza che c'e' nella natura di chi ha realizzato suddetto codice di analisi (persone di non scarso intelletto, capaci di tradurre complessi algoritmi in istruzioni elementari per il computer ma di principi sin troppo pragmatici ed immediati) e di coloro che potrebbero trarne programmi ad uso desktop (di ampia sensibilita' estetica ma misurate conoscenze matematiche, e troppo spesso rivolti all'utenza di massa anziche' alle piccole esigenze mirate), che frammenta ulteriormente il gia' mai sufficientemente grande bacino di developers esistente, e poi guardando all'altra sponda (le piattaforme non "libere") vediamo come all'atto pratico certe radicate modalita' di sviluppo e distribuzione del software, fondate non sempre sul profitto economico ma certamente sulla chiusura del codice (dicesi: freeware), assorbano la maggior parte di programmatori al mondo, instancabili produttori di programmini e utilities ma ben lontani dalla consapevolezze necessaria per aderire ad una licenza free as in speech.
Purtroppo non esiste un metodo unico ed universale per riuscire ad invertire questa tendenza, se non lavorare per realizzare semplici utilities e stimolare altri a fare altrettanto affinche' la potenza del software free esistente non resti a disposizione di una infinitesimale parte delle persone.

Strappando la Rete

2008-11-11T23:15:00.003+01:00

La notizia l'ho letta oggi pomeriggio, e mi ha talmente entusiasmato che la riporto qui: qualcuno ha sviluppato un binding DBus per Javascript. O meglio: una versione taroccata degli engine di Gecko e WebKit in grado di interpretare istruzioni Javascript destinate appunto all'interfaccia verso quello che si sta affermando come lo strumento di IPC standard sul desktop Linux (e non solo).
Il Browser DBus Bridge rappresenta non solo una grande innovazione, ma uno sforzo che oserei definire pionieristico nei confronti della piu' e piu' volte paventata integrazione del Web con il desktop casalingo: con poche righe di codice un sito potrebbe interagire con l'intero sistema operativo locale, non solo per mezzo della pagina visualizzata nel browser ma con tutto il set di altri applicativi utilizzati comunemente dall'utente. Importare ed esportare (o anche combinare) dati da e verso l'Internet non sarebbe piu' questione di usare programmi dedicati e limitati per una specifica area, ma diverrebbe piu' immediato che scaricare un file e salvarlo sul disco.
Con ogni probabilita' questa opera non godra' mai di capillare diffusione (troppo vincolanti le implicazioni sulla sicurezza e sulla privacy, per cui non e' tollerabile che un qualunque sito possa andare a ravanare informazioni che non gli competono, e troppo limitata la diffusione di Linux sul desktop per giustificare una massiccia adozione), ma a parer mio merita comunque una menzione d'onore per la sua semplicita' e la valenza di tecnologia potenzialmente "distruttiva".
Ad ogni modo mi son marcato la pagina al fine di meglio approfondire il tema e tentare (quando avro' tempo...) di lavorarci un pochino sopra, anche e soprattutto all'interno del Progetto Lobotomy.