Pensieri e parole su HCI, home computing, tecnologie desktop e sul Progetto Lobotomy

martedì 23 dicembre 2008

Usabilita' e Computazione

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

lunedì 15 dicembre 2008

Senza Volto

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

martedì 11 novembre 2008

Strappando la Rete

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

sabato 8 novembre 2008

Sai che c'e' di nuovo?

0 commenti
Da tempo non aggiorno questo mio blog (ma certo non e' questa una novita'), ed ora che mi degno di divulgare un mio pensiero esso e' off-topic e pure abbastanza povero rispetto alla linea che qui dovrei tenere. Pazienza, recuperero' in un'altro momento.

Una cosa Microsoft l'ha imparata da Apple. Forse l'importanza del design? Forse l'astuzia di usare software open e dunque sviluppato da altri nei propri prodotti? No: l'importanza dell'hype con cui stuzzicare il pubblico per ogni nuova trovata che si prevede uscira' sul mercato.
In Rete quotidianamente si legge qualche articoletto sul tanto atteso Windows 7, che dovrebbe (sulla carta) riparare il danno economico e di immagine prodotto da Vista e che si narra uscira' a meta' 2009.
Senza entrare nel merito (?!) gran parte delle informazioni che pervengono a noi comuni mortali trattano sulla nuova, strabiliante, mirabolante e rivoluzionaria interfaccia grafica con cui si presentera' il sistema. Questa.
Ora: io sono assai prevenuto nei confronti della societa' di Redmond, dunque il mio giudizio non puo' essere altro che critico e soggettivo, ma in tutta sincerita' non vedo nulla di particolarmente innovativo in quel che mi capita di leggere. Forse sulla scala di magnitudine dei cambiamenti tradizionalmente affrontati da Microsoft (pochi, e raramente sostanziali) questa settima edizione del sistema operativo piu' diffuso al mondo puo' risultare qualcosa di grandioso, ma certamente non lo e' in termini assoluti: ben altro ci vuole per iniziare a strapparsi i capelli gridando al miracolo.

Alla stagnazione intellettuale che tormenta gli ingegneri al soldo di Ballmer accosto un sentito articoletto ad opera di uno dei primissimi sviluppatori dell'X Window System da secoli usato in ambiente Unix: esso incita i programmatori open a non limitarsi ad imitare i prodotti commerciali nell'implementazione delle loro opere, ma a saper osare e proporre soluzioni di interazione uomo-macchina innovative e sperimentali, da testare e valutare col supporto del resto della community. Di mio non posso che dar ragione a questo appello (per chi non lo sapesse: il progetto Lobotomy stesso nacque a seguito di un editoriale dello stesso tono apparso oramai anni fa' online), nel mio piccolo incoraggiando i developers a proporre qualcosa di nuovo ad un pubblico sempre piu' attanagliato dalla ripetizione dei soliti (e spesso insufficienti) schemi.

I grandi sono lenti ed incapaci di muoversi e rinnovarsi al ritmo richiesto dal mercato, questo potrebbe essere il momento di stringere il cerchio e far realmente emergere una alternativa.

sabato 4 ottobre 2008

lock(&bob)

0 commenti
Per chi segue questo blog e' abbastanza lampante che in questo periodo mi sia dato alla macchia per quanto riguarda il progetto Lobotomy e piu' in generale questo blog e lo studio delle tecnologie di interazione uomo-macchina, ma questo post e' solo per rassicurare i miei fans (...) sul fatto che non mi sono affatto scordato del mio lavoro ma semplicemente sono un po' (troppo) preso da altri affari.
Anche quest'anno sono stato coinvolto nell'organizzazione del Linux Day di Torino e devo star dietro al blog, al sito, agli ordini per magliette e volantini e le altre mille beghe che ogni settembre/ottobre si ripresentano; per conto della mia associazione sto portando avanti un progetto per la realizzazione di un laboratorio informatico permanente ed una collaborazione con una fondazione per l'"archeologia informatica"; quando mi capita (e quando ne trovo la voglia) continuo lo sviluppo di un gestionale online che mi e' stato commissionato ed il cui ricavato andra' a sostenere le spese per la piattaforma di sviluppo collaborativo di cui sono amministratore; ed infine, un amico dei miei mi ha messo una pulce nell'orecchio e da qualche giorno mi sto documentando sulla disponibilita' di software libero per Linux (e freeware per Windows, da portare su Linux) dedicato ai radioamatori.
Prima o dopo, quando almeno qualcuno di questi impegni sara' concluso, vedro' di tornare all'opera sul prototipo la cui concezione e' nata dopo le elucubrazioni di qualche tempo fa'.

sabato 6 settembre 2008

L'Architettura di EyeOS

0 commenti
Per motivi contorti l'altro giorno mi e' capitato di andare a dare uno sguardo alla documentazione del web desktop EyeOS, scoprendo cio' che non mi sarei aspettato.
Dei web desktops ho gia' fatto menzione diverso tempo addietro su questo blog, e nel frattempo la mia posizione nei confronti di tale tecnologia (per cui e' oramai passato il momentum e di cui nessuno piu' discute) non e' variata, ma sorvolando su "cio' che e'" vorrei soffermarmi su "come e' fatto": la pagina introduttiva all'architettura del cosiddetto sistema operativo web illustra come EyeOS sia strutturato su piu' livelli operativi, che vanno dallo strato di presentazione all'utente (quello che disegna gli elementi nel browser) al core di servizi dedicati alle singole funzionalita', passando per un "kernel" che funge da tramite. Dove ho gia' visto una cosa del genere? Nei miei stessi documenti che tracciano la struttura che vorrei dare a Lobotomy!
A ben guardare codesta soluzione e' pressoche' obbligata nel momento in cui si implementa un web desktop: il codice eseguito nel browser puo' essere solo Javascript o al piu' Flash, dunque con potenzialita' assai ridotte, e in ogni caso lo storage risiede sempre in una locazione ben diversa dal PC locale dell'utente (il server che hosta il servizio) e l'unica possibilita' e' quella di suddividere ogni applicazione nelle diverse componenti di presentazione grafica e di computazione.
EyeOS potrebbe essere un discreto punto di riferimento per i prossimi sviluppi del mio progetto: purtroppo oltre appunto alla disposizione dei suoi internals esso non porta assolutamente nulla di nuovo in termini di usabilita' ed interazione (emula in tutto e per tutto un desktop tradizionale, coi suoi pro e contro), ma chissa' che non se ne possa cavare qualche spunto...

martedì 2 settembre 2008

Crisi di Identita'

2 commenti
Da quando ho tra le mani il FreeRunner (ovvero: da ieri sera) sto vivendo una sorta di crisi mistica in merito ai prossimi sviluppi del Progetto Lobotomy. Il fatto di possedere un dispositivo mobile che racchiude buona parte delle potenzialita' dei devices del prossimo futuro sul breve e medio termine, e vederlo cosi' malamente sfruttato da quei disgraziati di OpenMoko Inc. (ho aggiornato poco fa' alla release 2008.8: molto meglio della 2007.2, ma ancora siamo ben lontani dall'avere qualcosa di usabile...), mi da da riflettere su quale sia la direzione da intraprendere nello sviluppo di una piattaforma che intenda essere punto di convergenza tra il mobile, il desktop ed il web.
Devo pensare... Tanto...

domenica 31 agosto 2008

Io, me e l'OpenMoko

0 commenti
E' arrivato. Quasi non ci speravo piu'. Da ieri sono portatore insano di FreeRunner, noto ai piu' come OpenMoko!
Di recensioni sul dispositivo se ne trovano gia' a quintalate sulla Rete, vorrei comunque riportare qualche impressione a caldo (anzi: caldissimo) sulle primissime impressioni acquisite accendendo e provando per la prima volta il dispositivo.

L'apparato e' reattivo, l'avvio di una delle (poche) applicazioni disponibili contempla un'attesa minima, dunque nel complesso la capacita' di calcolo sembra sufficiente. Il touchscreen e' assai preciso finche' si resta con l'orientamente dello schermo verticale, se si passa a quello orizzontale tutte le pressioni vengono riportate addirittura un centimetro a sinistra: han cannato completamente qualche impostazione di Xrandr.
Vorrei riportare qualche considerazione anche sugli aspetti hardware avanzati e probabilmente piu' succulenti (GPS, Bluetooth, WiFi...), ma la dotazione software di default e' estremamente misera e non v'e' nulla che permetta di usufruire di tali potenzialita'.
Rimanendo sul discorso software: quello precaricato (la release 2007.2) fa schifo. Come detto non ci sono programmi di alcun genere, e quelli che ci sono sono inusabili e bacati: addirittura quello per consultare la rubrica non legge correttamente la SIM card e non lista molti dei contatti che vi si trovano. La possibilita' di eseguire un terminale sul proprio cellulare da molta soddisfazione, certo, ma almeno un browser web potevano metterlo!
In questo preciso momento sto effettuando il primo upgrade del software installato, giusto per vedere come si comporta, ma certamente nel piu' breve termine possibile riflashero' un'altra release di tutto il blocco software: provero' la versione 2008.8 di OpenMoko, mista GTK e QT, ma non e' detto che non mi decida a installare Debian (la ben nota distribuzione Linux, portata per l'occasione sull'hardware del FreeRunner) per godere di tutti gli applicativi gia' esistenti ed integrare personalmente le funzionalita' telefoniche.

Insomma: out-of-the-box l'OpenMoko non da molte soddisfazioni, ma e' sufficiente dare uno sguardo al wiki della community per avere l'imbarazzo della scelta su quale funzionalita' e possibilita' esplorare per prima.
Altre news seguiranno in proposito.

sabato 30 agosto 2008

Ubiquity

0 commenti
Brevissimo post per segnalare (anche io come molti altri) l'esistenza di una splendida estensione per Firefox: Ubiquity.
Annunciata nel blog del Mozilla Labs (che ultimamente pare darsi da fare... Evidentemente l'acquisizione di Humanized inizia a dare i suoi frutti...), questa estensione e' difficile da categorizzare, e la definizione che al momento mi pare piu' congeniale e'... un terminale per il Web. Pigiando una combinazione di tasti (Alt+Spazio di default) in alto a sinistra appare una vera e propria linea di comando in cui e' possibile eseguire comandi (implementati in Javascript, e facilmente installabili navigando il web) grazie ai quali si puo' accedere ad una quantita' di funzionalita', dal reperimento di una mappa su Google Maps all'immissione di un twit su Twitter.
Certamente la visione del video di presentazione e' molto piu' esplicativa che non la mia descrizione.
Il post del blog linkato all'inizio pullula di riferimenti ad altri articoli in cui le diverse persone coinvolte nello sviluppo di questa applicazione (tra cui Aza Raskin, figlio del ben piu' noto e mai dimenticato Jef Raskin) si sperticano nel proclamare l'efficacia del miscelare interfaccia testuale con interfaccia grafica, opinione che non solo condivido ma ho a mio tempo (nel 2004) esplorato all'interno di BrainTop.
Oltre che ad un ritorno ai mainframe ed ai thin client, vediamo anche un ritorno alla linea di comando?

mercoledì 27 agosto 2008

Thoughts

0 commenti
Finalmente, dopo mesi di citazioni e rinvii, ho finalmente pubblicato il paper descrittivo del linguaggio XML destinato ad essere interfaccia al sistema di templating che rappresentera' prima o poi l'intero engine grafico del desktop environment Lobotomy.
L'articolo si trova qui, e' scritto in italiano (e non nel mio solito maccaronico inglese...), e sebbene non dettagliato e completo include comunque buona parte di quello che si intende costruire in Synapse.
Si ringrazia l'amico HoX per la revisione e per aver subito evidenziato diversi punti di incompletezza su cui prossimamente lavorero', in attesa di eventuali altri commenti esterni.

martedì 19 agosto 2008

La Noia Nobilita l'Uomo

0 commenti
Poiche' in questo momento mi sto occupando di un lavoro (e non posso dunque concentrarmi sufficientemente sul codice di Lobotomy) assai noioso e di cui mi pento ogni giorno per averlo preso in carico, invece di impegnarmi per terminarlo al piu' presto e levarmelo dalle scatole mi invento ogni possibile scusa per distrarmi e pensare ad altro. Pessimo modo di condurre i propri affari, ma son fatto cosi'.
Ieri ho messo ordine nella pagina Flickr dedicata a Lobotomy suddividendo le poche (= due) immagini disponibili in due gruppi, uno dedicato agli scatti catturati durante il lavoro sul progetto e l'altro per eventuali screenshot dell'opera man mano che evolvera' (se mai evolvera', di questo passo...). Presto o tardi introdurro' anche un'altro gruppo, dedicato ai mockups di cui la mia documentazione e' gia' ricca e soprattutto a studi per possibili templates da introdurre una volta implementato l'interprete in Synapse: proprio ieri grazie a questo video ho avuto ispirazione per un'altra modalita' di visualizzazione "ambientalmente contestuale" dei files (maggiori dettagli a seguire ;-) ).
Un'altra cosa che vorrei fare e' rivedere il sito. Lo so, gia' ci misi mano non troppo tempo addietro, e da allora non ho combinato quasi null'altro sull'intero progetto, ma al momento la pagina fa realmente orrore e non mi stupisce che nessuno se ne curi. Vorrei rifarlo organizzando il layout nello stesso modo (piu' o meno) di come vorrei che si presentasse Synapse, metter su una sorta di prototipo HTML entro cui piazzare ovviamente i contenuti informativi del sito ma comunque entro un certo criterio che possa far presagire quel che si vuole portare sul desktop.
In ultimo comunico che ho quasi terminato il documento descrittivo del linguaggio XML da usare nei gia' menzionati templates da far interpretare a Synapse. Dopo aver rinunciato a stenderlo in inglese (troppo lungo e troppo complesso per le mie capacita'), averne rivisto la struttura e averlo ricominciato daccapo un paio di volte, mi resta solo da ritoccare qualche riferimento interno al paper e sbatterlo online. Ammetto che non sia venuto un capolavoro di chiarezza e semplicita', in quanto non e' semplice illustrare in modo lineare una idea cosi' farlocca come quella dell'abbandono dell'architettura software usata da cinquant'anni a questa parte, e proprio per appurare la sua comprensibilita' lo faro' leggere preventivamente a qualche mia vittima designata.
Con questo, e' tutto. Torno ad occuparmi del mio noioso lavoro.

lunedì 18 agosto 2008

Aurora

0 commenti
Avevo scorto un link a questa cosa tempo addietro, ma poi fattori ambientali mi avevano impedito di approfondire, come al solito me ne ero dimenticato, e ieri contemplando lo stream di del.icio.us ho trovato questo articolo con un nuovo riferimento al video cascato nell'oblio.
L'oggetto della discussione e' Aurora, concepito da Adaptive Path e presentato nel contesto della Concepts Series promossa da Mozilla Labs.
Cos'e'? In parole semplici un browser, all'atto pratico una proposta di modello di interazione ispirata dalla sempre piu' forte spinta del destktop verso il web. Poiche' in un ipotetico futuro la Grande Rete sara' contenitore unico ed universale di informazioni ed applicativi software, l'unico programma con cui l'utente interagira' sara' appunto il browser, modificato e potenziato rispetto a quanto siamo abituati oggi ma pur sempre un browser.
Nella visione di Adaptive Path il programma non solo permette di renderizzare le pagine web (ed e' il minimo...) ma organizza anche la cronologia secondo un ordinamento basato sulle correlazioni semantiche dei contenuti visualizzando poi i dati in gruppi separati navigabili secondo una modalita' spaziale. Non troppo dissimile da quanto vuole fare ItsMe, con la differenza che in Aurora la creazione e la gestione dei gruppi, al pari di pressoche' ogni altro compito di processamento, sembra essere molto piu' automatizzata e a discrezione dell'algoritmo interno.
Nella pagina del concept si trovano almeno quattro video di cui uno solo, il primo, ha una qualche parvenza di realismo, gli altri tre mi sembrano assai pacchiani sebbene in fin dei conti neppure cosi' infondati: i formati universali che descrivano i dati secondo sintassi comprensibili (e dunque elaborabili) dalla macchina si stanno propagando, devices delle dimensioni di una carta di credito non sono ancora possibili ma il progresso delle tecniche di miniaturizzazione lascia pensare che un giorno ci si possa arrivare, ed in merito alla scenetta del terzo filmato non e' poi cosi' impossibile reperire informazioni su un prodotto commerciale facendogli semplicemente una foto considerando che gia' adesso esistono strumenti che associano immagini uguali o simili tra loro (giusto oggi e' entrato in private beta TinEye).
Morale della favola: stiamo tornando al thin client? Stiamo tornando ad usare semplici terminali che vanno a pescare software ed informazioni su macchine remote, cosi' come in voga agli albori della scienza informatica quando un singolo mainframe serviva le richieste di un numero di utenti sparpagliati nel laboratorio con davanti un monitor, una tastiera e null'altro? Forse si (con l'ovvia sostituzione del mainframe con il Cloud Computer), forse no. Ed e' un bene? Forse si, forse no. Di buono in questa prospettiva c'e' la garanzia di accesso ad informazioni sempre aggiornate ed arricchite programmaticamente mischiando i dati dell'utente con il flusso proveniente dal resto della Rete, di cattivo (oltre alle ovvie considerazioni sulla privacy, ma oramai ho smesso di credere che in un mondo interconnesso possa esserci molto spazio per l'intimita'...) c'e' l'eccessiva esposizione e contaminazione di quegli stessi dati, cosi' mutevoli e soggetti a cambiamenti non necessariamente richiesti e graditi. Per non considerare il rischio portato dal fatto di centralizzare il point of failure di qualsiasi attivita' sociale, economica e ricreativa su un'unica struttura (l'Internet) e su un numero limitato di providers per i servizi essenziali.
Piu' passa il tempo e piu' sono convinto della soluzione del "Personal Cloud" (che bel nome, l'ho inventato adesso! Dovrei registrarlo sperando che mi vada meglio che a Dell ;-) ) la cui struttura e' stata menzionata in un precedente post: una rete di macchine personali, alcune da portare con se' ed altre con cui arredare la casa, che interagiscano pienamente tra loro ed in modo contenuto con l'Internet, in modo da usufruire delle potenzialita' della moderna tecnologia senza poggiare necessariamente tutto su pochi nodi cruciali e senza sacrificare troppo alla privacy o al pieno possesso dei propri contenuti.
Sara' sara' l'aurora...

venerdì 8 agosto 2008

Modulare by design

0 commenti
Come talvolta accade questo post viene pubblicato piu' come mio personale appunto, in quanto non viene menzionato nulla di particolarmente nuovo sull'universo Lobotomy: gia' piu' volte ho ribadito la volonta' di spezzettare lo strato funzionale dell'intero sistema in diversi componenti indipendenti tra loro e con cui comunicare (localmente sulla stessa macchina, ma anche remotamente) per mezzo di D-Bus, adesso un poco alla volta sarebbe il caso di fare qualcosa di concreto (tempo permettendo).
Giusto negli scorsi giorni ho esposto questa mia idea su Gnome-Look.org ma ho ottenuto scarso feedback, soprattutto perche' comprensibilmente l'adozione di codesta architettura implicherebbe la riscrittura dell'intero Gnome e delle relative applicazioni e giustamente non e' una ipotesi particolarmente allettante per chi gia' ci lavora da anni, ma in questa stessa settimana ho avuto due pragmatiche dimostrazioni di quanto cio' non solo avrebbe pieno senso di esistere ma e' anche quasi una necessita' nel mondo odierno, ove sempre di piu' sono i devices (computer, laptop o mobili) usati da ogni persona: una volta avrei voluto abbassare il volume del player mp3 in esecuzione sul mio desktop, essendo mollemente adagiato sul divano col portatile sulle gambe ed avendo poca voglia di alzarmi, ed in un'altra occasione avrei voluto scaricare un file Torrent usando il mio server domestico (perennemente acceso, anche di notte) che pero' non ha un monitor attaccato ed e' accessibile solo via SSH. Chiunque potrebbe obiettare a queste mie osservazioni dicendo "bravo pistola, di applicativi che fan quello che vuoi ed usabili in remoto o via interfaccia web ce ne sono quanti ne vuoi, installati quelli e non rompere le scatole!", ma trovo questo genere di soluzioni assai povere e scarsamente flessibili: l'interfaccia sarebbe comunque sempre diversa tra un'applicativo e l'altro, e non v'e' modo di integrare la funzionalita' desiderata al di fuori del programma stesso.
Al momento sto valutando la possibilita' di iniziare a sviluppare uno straccio di client Torrent come dico io, dunque sottoforma di demone di sistema (costruito assemblando l'API gia' esistente) con cui dialogare in principio con un programmino a linea di comando e poi magari con un frontend grafico, ma sempre e comunque tenendo separate le componenti funzionali e quelle di interazione: se e quando mi decidero' a farlo chiaramente lo annuncero' qui e pubblichero' l'opera su BarberaWare, all'inizio lo svilupperei come applicativo a se' ed un giorno potrei riutilizzarlo all'interno di Lobotomy aggiungendo quelle due o tre funzioni per agganciarlo al resto del sistema.
Dopodiche' non sarebbe male esplorare la possibilita' di wrappare D-Bus in XML-RPC (con questo?) per eseguire comandi molto remotamente (non in LAN ma attraverso l'Internet, ad esempio per aggiungere un'altro file nella lista di torrents in download sul proprio server mentre ci si trova fuori casa, contesto in cui il solo D-Bus non se la cava troppo bene), costruire un sistema unico di discovery (con Avahi) e mettere insieme un framework facile facile per implementare interfacce web (un binding PHP di D-Bus ancora sembra non esserci, ma non e' che abbia particolare voglia di studiarmi pure Ruby...), insomma di spunti ce ne sono fin troppi.
Vedro' cosa riusciro' a combinare nelle due settimane di ferie dal lavoro che iniziano oggi...

martedì 5 agosto 2008

Un Castello tra le Nuvole

0 commenti
Da qualche tempo mi son reso conto di essere talvolta un po' troppo influenzabile dalle tendenze (anzi, chiamiamole pure "mode") tecnologiche, ed ora, dopo aver immaginato una interfaccia web based per Lobotomy quando la parola "ajax" veniva menzionata in ogni articolo di blogs ed aggregatori, il mio inconscio geek sta valutando le potenzialita' di quello che e' chiamato "cloud computing".
Non e' nuova l'idea di integrare all'interno del futuro (futurissimo...) Lobotomy strumenti per la distribuzione del calcolo necessario per l'estrazione automatica dei metadati ed altri task con forti richieste computazionali, ma nuove porte si aprono se si gettano nel calderone anche le possibilita' della distribuzione dello storage.
Espandendo il filesystem e e copiando (e ridondando) i files su piu' macchine, all'interno della propria LAN domestica o appunto nella Cloud, in un colpo solo si ottiene il duplice risultato di condividere i contenuti affinche' siano fruibili su piu' devices (il desktop di casa, il portatile, il MID...) e di mantenerne copie di sicurezza da sfoggiare in caso di catastrofe - evento neppure cosi' sporadico data la sempre maggiormente scarsa qualita' dei componenti hardware - mentre applicando lo stesso concetto direttamente al database responsabile di indicizzare i metadati che descrivono ogni elemento si riuscirebbe ad esportare le proprieta' tipiche di Lobotomy anche laddove non sarebbe altrimenti possibile: sugli apparati mobili, che non sarebbero in grado di contenere fisicamente (e dunque usare) tale immensa mole di informazioni, e sul web, al fine di condividere i dati tra piu' utenti (i propri amici e conoscenti, ma anche tutto il resto del mondo).
Proprio con questo secondo obiettivo ho iniziato a documentarmi un pochino su HBase, Hypertable e prodotti analoghi: certamente e' molto presto per mettersi a progettare un sistema cosi' complesso, ma e' bene comunque valutare a priori questa direzione per poterla successivamente integrare nel modo piu' pulito e rapido possibile a tempo debito.

giovedì 17 luglio 2008

Una ne pensa, cento ne dovrebbe fare

0 commenti
E' assai complesso inventarsi un modo sufficientemente flessibile ed elegante per astrarre i tipi di dato estratti da Hyppocampus, soprattutto quando si manipolano link relazionali a files di natura diversa. Come uniformare ad esempio i testi, che possono essere plain o strutturati? O come far collimare le immagini, che sono di numerosi mimetypes diversi?
Notifico che al momento ancora brancolo nel buio sul sistema di trasformazione delle informazioni gia' menzionato nel passato remoto ed ultimamente in occasione della problematica della presentazione delle icone, qualche spunto viene dalla gestione dei GType in GObjects ma ancora non sono troppo convinto ad adottare tale strategia e soprattutto non ho abbastanza tempo libero e risorse intellettuali non allocate per concentrarmi sulla bisogna.
"Keep It Simple", si usa dire... Forse la soluzione e' piu' ovvia di quanto non ci si possa immaginare...

domenica 29 giugno 2008

KiazmaIconView

0 commenti
Questa sera ho in buona parte completato il primo widget effettivo della nuova riscrittura di Kiazma, la KiazmaIconView. Qui il primo screenshot, sebbene non ci sia nulla di speciale da vedere: mancano ancora le icone!
Questo non e' stato un gran traguardo tecnico, in fondo l'algoritmo di disposizione delle icone e' banale (basta metterle in una griglia...), ma nella sua semplicita' rappresenta una importante milestone nella costruzione dell'intero toolkit: prima di arrivare a cio' ho dovuto abbozzare il core di oggetti che sono l'essenza della rappresentazione grafica degli elementi relazionali carpiti dal filesystem Hyppocampus (questa KiazmaIconView ad esempio e' solo una estensione del KiazmaSet, sorgente di ogni altro widget rappresentante un result set) e mettere in piedi il meccanismo di caricamento dinamico dei widget, insomma per arrivare a quei tre quadretti azzurri c'e' stato parecchio da studiare ma adesso posso dire di essere ad un buon punto.
Prima di proseguire su questa via, magari mettendo delle icone vere in sta' iconview, c'e' pero' un'altro grosso passo da compiere: la prima stesura di Staminal. Originariamente pensato per un impiego di estremamente alto livello, nella fase finale del trattamento dei dati prima della presentazione all'utente, mi sono accorto che questo componente del progetto Lobotomy risulta indispensabile per la visualizzazione di qualsiasi item. Per fare un esempio relativo al widget presentato in questo post: una volta estratta una serie di elementi dal filesystem per mezzo di una query in cui sono stati selezionati ben specifici metadati ("SELECT pippo, pluto, paperino WHERE..."), come costruire la relativa icona? Se son stati selezionati metadati dal contenuto solo testuale, cosa appare nel disegno rappresentativo? Questo vale per tutti i widgets futuri in Kiazma, in quanto e' condizione primaria del modello MVC che si sta costruendo che ogni result set sia rappresentabile con un qualsiasi template senza sapere a priori cosa andra' ad essere rappresentato.
Adesso e' tardi (son quasi le 5:00...), vedro' di pensarci domani se passera' poca gente a Willastellone...

venerdì 27 giugno 2008

Presagio

0 commenti
Oggi apro l'aggregatore RSS, e leggo che...
Ora: e' una mia impressione, o la tendenza verso il mobile aumenta ogni giorno di piu'? Sorvolando su questa insolita sfilza di notizie strettamente correlate al settore, inutile non ammettere che comunque almeno una volta al di' capiti di trovarsi dinnanzi a qualche annuncio di una certa rilevanza: forse davvero ci stiamo avvicinando al punto di rottura, il momento in cui lo smartphone acquisira' una importanza maggiore rispetto al desktop?
Dal canto mio so solo che nei prossimi giorni provvedero' ad ordinare il mio OpenMoko presso il distributore francese con l'intento dichiarato di giocarci sopra e sperimentare lo sviluppo su questo genere di apparati, traendo magari ispirazione dal piu' fornito archivio di applicativi mobili sul web.
Per intanto profitto di questo breve post per comunicare che sto dedicando la settimana corrente a rimettermi al passo con l'implementazione di Kiazma: superati i primi momenti di panico dovuti ai primi approcci a Clutter procedo abbastanza speditamente e conto di avere una API sufficiente per costruire una prima demo a giorni.

domenica 15 giugno 2008

Touch Me

0 commenti
Periodo assai magro per lo sviluppo di Lobotomy, essendo io estremamente impegnato su un numero infinito di fronti ed impiegando ogni momento libero per portare avanti una applicazione web commerciale che mi e' stata commissionata (sviluppata per mia volonta' con GWT, al fine di acquisire maggiore dimestichezza con tale strumento e riusare l'esperienza accumulata al servizio del freesoftware).
Ma riuscendo finalmente ad intravedere una luce in fondo al tunnel, e pregustando il giorno in cui potro' tornare a dedicarmi integralmente al mio amato progetto, nel substrato cognitivo di background sono tornato a meditare a funzionalita' e perfezionamenti da apportare. Primo tra tutti (oltre chiaramente all'implementazione del nuovo Synapse in forma di interprete per i templates delle applicazioni interne al desktop environment) lo sfruttamento dei dispotivi di puntamento touchscreen.
Sembra proprio che il mondo abbia finalmente scoperto l'esistenza dei touchscreen (devo considerarmi un precursore, avendo investito gia' tre anni addietro nell'acquisto di un tablet?), e le tecnologie desktop molto puntano su tali apparati: si puo' facilmente prevedere l'uscita di una nuova schiera di tablet PC a partire dal prossimo anno, con l'avvento di Windows7 (di cui l'unica cosa che e' stata mostrata sinora e' appunto il supporto al multitouch), e gia' oggi i piu' moderni laptop targati Apple supportano gestures sul touchpad.
Proprio a proposito dell'uso del comune touchpad presente su ogni portatile in commercio (non solo quelli Mac), ho scoperto che gia' molti di essi sono in grado di identificare il tocco di piu' dita contemporaneamente: stando a questo illuminante articolo le proprieta' di tali device non sono particolarmente precise ed avanzate, ma con un poco di fantasia qualcosa si potrebbe comunque cavare: allo stadio attuale tali funzionalita' sono totalmente inutilizzate (ed ai piu' sconosciute), ed il mio personale obiettivo e' quello di provare ad implementare una sorta di piccola libreria standalone per Linux che faciliti la definizione di gestures elementari da riusare poi nel contesto di Lobotomy.
Chissa' che non riesca a rilasciare qualcosa profittando del tradizionalmente prolifico periodo estivo...

venerdì 9 maggio 2008

Web costruttivo, Web distruttivo

0 commenti
Devo ancora finire di stupirmi guardando i piccoli demo di utilizzo del recentissimamente annunciato Processing.js, ma poiche' la pagina risulta correntemente slashdottata e di difficile consultazione ne approfitto per riportare qui qualche commento a caldo.
Cos'e' Processing.js? Il port Javascript dell'omonimo framework Processing, dedicato all'elaborazione grafica di alto livello e sviluppato in Java. E a cosa serve? Ad eseguire trasformazioni di elementi grafici direttamente nella pagina del browser. Consiglio ovviamente di dare uno sguardo alla pagina dell'annuncio del progetto per rendersi conto di cosa cio' significhi, ma basti dire che gia' qualcuno mormora di una possibile sostituzione di Flash con questo tipo di engines Javascript per il web.
Questo potrebbe sembrare l'ennesimo hack simpatico e divertente fatto dall'ennesimo developer in vena di perdere tempo giocherellando con un poco di codice, destinato ad essere dimenticato una volta scivolato al fondo della homepage di Slashdot, ma ho l'impressione che questa sia una tecnologia di carattere "distruttivo" nei confronti del web design: allo stesso modo in cui le micro-librerie Javascript come script.aculo.us, mootools, jQuery et similia hanno cominciato a proliferare subito dopo che la manipolazione del DOM e dei CSS sono divenuti pane quotidiano per gli sviluppatori di applicativi web (o meglio: Web2.0), o come l'XMLHTTPRequest divenuto cosi' popolare dopo anni di oblio in seguito allo sfruttamento massivo da parte di Google, anche la manipolazione avanzata della grafica in Javascript ha tutte le carte in regola per scatenare una nuova ondata di librerie, estensioni, tools ed amenita' di ogni tipo pronte per essere massicciamente usate prima dai maniaci domestici dell'innovazione homebrew e poi dai grandi colossi che determinano l'andamento della Rete globale.
Quel che piu' mi affascina di questo nuovo giocattolo per nerd e' il nuovo grado di flessibilita' e scalabilita' offerto all'interno del set di tecnologie usabili dai web developers, in quanto contrariamente al gia' menzionato Flash (che nonostante la recente apertura da parte di Adobe e' e rimane uno strumento chiuso ed isolato rispetto al resto) un canvas grafico trattato in questo modo puo' andare a pescare i dati da un server remoto in tempo reale (ed asincronicamente) e risultare assai piu' trasparente e facile da gestire per chi gia' lavora con i moderni tools oggi a disposizione.
Traslascio per ora i commenti personali sull'impiego di questo genere di orpelli nell'implementazione di pagine web, limitandomi a sperare che il loro utilizzo sia sempre ponderato e misurato in modo da risultare una vera innovazione e non uno sperpero di risorse al solo fine di pavoneggiarsi con amici e colleghi.
Il web cambia, si crea e si distrugge, non sempre e' facile starci dietro. Ma l'importante e' che ci sia qualcuno davanti.

lunedì 5 maggio 2008

Saranno Famosi

0 commenti
Non so bene come ho iniziato le mie ricerche, ma sta di fatto che questa sera mi son capitati tra le mani quelli che sono stati i primissimi brani ed articoli in cui hanno iniziato a delinearsi le idee portanti del Progetto Lobotomy. Probabilmente non freghera' a nessuno, e a linkare certi siti e certi pezzi scritti tanti anni fa' non ci faccio una bella figura, ma un po' di nostalgia e di auto-ironia non gusta mai...
Tutto inizio' nel lontano 2004, quando frequentavo la community di Kuth (oramai non solo chiusa ma di cui s'e' pure persa traccia del sito...): lessi questo articolo che parlava del desktop Linux e di come esso non doveva essere necessariamente una copia di quello Windows, lo commentai con fervore nel forum, e alla domanda "E allora te che cosa proporresti, di alternativo?" scatto' la molla.
Scrissi questa pagina in quello che allora era il mio sito personale (bei ricordi, quando il Web non era ancora descritto con numeri di versione...) ed iniziai l'opera su BrainTop, il primissimo componente di quello che allora neppure pensavo sarebbe cresciuto a dismisura fino a diventare Lobotomy. BrainTop era un window manager "potenziato", una applicazione rivolta ad organizzare superficialmente i dati prodotti dall'utente con le applicazioni di tutti i giorni, ma il progetto venne interrotto in breve tempo a causa di un ostacolo: come riuscire ad organizzare i files se su di essi non avevo alcuna informazione sulla loro natura ed il loro utilizzo?
Pensa che ti pensa, giunsi alla conclusione che il window manager avrebbe dovuto essere solo l'ultimo strato di un sistema ben piu' complesso, che doveva erigersi a partire dal filesystem e sostituire non solo la rappresentazione grafica del desktop ma l'intero modello di interazione uomo/macchina: approfondii l'argomento con due ulteriori pezzi (questo e questo, che a tutt'oggi risiedono sul mio server domestico) in merito a quello che chiamavo "BrainFS" e dopo poco divenne Hyppocampus, ovvero un filesystem relazionale che contenesse quei "metadati" indispensabili per mantenere collegamenti logici tra i contenuti.
Il resto e' storia: la costituzione del Progetto Lobotomy, ovvero il nome collettivo con cui accomunare BrainTop ed Hyppocampus (ed in seguito Synapse, il filemanager destinato a facilitare la navigazione della base dati di files), il nuovo sito web, questo blog, e tutti gli ulteriori progressi che a tutt'ora non esistono se non in qualche angolo della mia testa (non avendo mai avuto occasione di documentarli per iscritto).
Ed e' cosi' che, leggendo un breve articoletto neppure troppo interessante sull'Internet, nasce una idea. Regola #1 dell'innovazione: "got inspired".

giovedì 1 maggio 2008

Quattro chiacchere su ItsMe

0 commenti
Da taaanto tempo non aggiorno codesto mio blog, ma tra il lavoro regolare e le altre attivita' non solo non trovo tempo di commentare qui le ultime news a tema ma neppure riesco a meditare piu' approfonditamente sul Progetto Lobotomy.
Sta di fatto che qualche giorno addietro son riuscito a fare un salto a Milano presso l'Universita' Bicocca per scambiare quattro chiacchere con il prof. De Michelis, fautore del progetto ItsMe di cui ho gia' fatto cenno in passato; ebbene, devo dire di aver solo adesso compreso in cosa consiste l'attuale sviluppo del progetto, e tra qualche perplessita' ma anche molta curiosita' lo reputo quantomeno interessante.
Sostanzialmente, diversamente da quanto immaginavo, al momento i ragazzi della neonata azienda meneghina stanno implementando una sorta di layer di astrazione del filesystem che si occupa di filtrare i contenuti scritti e letti operando qualche piccola opera di organizzazione degli stessi in funzione dell'attivita' dell'utente, che di volta in volta si trova a lavorare in un workspace dedicato ad un suo particolare task. Operando al livello del filesystem il sistema puo' essere usato con i normali applicativi software cui tutti siamo abituati, anche se "inconsapevoli" della struttura ponderata che ci sta sotto, e, almeno in questa fase dell'implementazione, non sono previste bizzarre interfacce grafiche o modelli di disposizione degli elementi sullo schermo, se non forse una sorta di "desktop esteso" che permetta di navigare i dati appunto secondo la nuova organizzazione non gerarchica.
Mi ha (piacevolmente) stupito il forte peso che si vuole dare alle interazioni "sociali" dell'utente, al pesante utilizzo delle mail come criterio di discriminazione tra i contenuti per la manipolazione: dall'analisi off-line delle comunicazioni fatte tra persone diverse si vuole fare in modo di "intuire" i nuovi task che ci si trova ad affrontare o le interazioni con essi, in modo da suggerire a chi si trova dinnanzi al monitor correzioni e perfezionamenti al modello.
Forse a questo punto sarebbe d'uopo un confronto tra questa opera ed il Progetto Lobotomy, ma credo che un diretto accostamento sia impossibile: i due lavori partono da presupposti molto diversi tra loro e fungono in maniera quasi opposta (ma non totalmente), mentre ItsMe punta ad un "caos ordinato" tagliato a misura dell'utente che lo usa (e che dunque fallisce se l'utente non segue certe regole) il mio progetto verte sull'immediata richiesta e necessita' (e dunque fallisce sul lungo termine non avendo una visione di insieme); ad ogni modo, loro arriveranno certamente prima di me ad avere qualcosa di usabile, dunque il problema non si pone...
Non ho ben capito a quale grado di sviluppo siano gia' giunti gli sviluppatori di ItsMe, ma mi e' stato riferito che entro non troppo tempo (subito dopo l'estate?) potrebbe essere disponibile online un simulatore atto a far toccare con mano la tecnologia e le implicazioni di un manager automatico per le informazioni: per intanto mi frego le mani in vista di metterci le mani sopra, si' da diventar membro della community e collaborare quantomeno in veste di tester, e vedro' di tenermi aggiornato in merito alle prossime news a riguardo.

sabato 29 marzo 2008

Scritture (molto) asincrone

0 commenti
Ho appena aggiunto nella lista dei TODO per il progetto Hyppocampus la menzione al prossimo sistema di schedulazione delle scritture che vorrei implementare per supportare l'API di salvataggio "discreto".
Non ricordo se ne ho gia' fatto cenno qui, ma un riassuntino non guasta mai: l'idea e' quella di fornire in LibHyppo un set di funzioni che permettano di aggiungere ed eliminare dati pure nel mezzo di un file esistente, in modo da poter poi includere in Kiazma tutto il necessario per eseguire sempre e comunque salvataggi automatici a bassa latenza (nell'ordine di secondi) dei contenuti editati dall'utente all'interno dei widgets.
Il problema sta ovviamente nel fatto che le operazioni di scrittura nel mezzo di un file implicano lo spostamento sequenziale di tutti i blocchi che seguono, e sarebbe assai poco conveniente procedere con la riscrittura completa ad ogni byte cambiato; introducendo in Hyppocampus una sorta di coda di richieste, che scheduli i dati e le posizioni in cui vanno scritti, si dovrebbe riuscire a raggruppare ed ordinare tali dati ed eseguire accessi al disco un po' piu' consistenti ed efficaci, si' da sfruttare l'operazione di memorizzazione effettiva su ROM per far transitare piu' materiale in una volta sola.
L'effetto di tutto cio' sarebbe la disponibilita' di un sistema di salvataggio automatico in tempo reale, per cui ogni modifica ai contenuti viene mantenuta senza esplicita richiesta da parte dell'operatore: niente piu' pulsanti "Salva" o "Salva con nome", solo un costante salvataggio.
Maggiori dettagli a seguire.

mercoledì 26 marzo 2008

Apriti Xesam

0 commenti
Ne avevo sentito parlare, me ne accenno' nuovamente l'amico Gigi tempo addietro, solo adesso ne guardo la documentazione. E non mi e' piaciuta.
Xesam si propone come uno standard per astrarre un qualunque storage di metadati (solitamente ad esso viene associato il ben noto Beagle, ma altri indexer sono gia' compatibili o sulla strada per esserlo) e permettere dunque a qualunque applicazione di attingere alla ricca base dati messa a disposizione; un ottimo esempio ne e' un curioso file manager che organizza i files in funzione della data di creazione...
Peccato che l'intera specifica dello standard sia... un protocollo XML! D'accordo che in questo modo si separa nettamente il formato dell'interrogazione dall'implementazione, e che dunque si puo' usare con qualunque linguaggio e nel modo piu' congruo a seconda dell'occasione, ma... Diamine: non esiste uno straccio di libreria di nessuna forma che implementi una qualsivoglia parte della specifica, non un esempio effettivo, l'unico punto di riferimento e' il codice gia' esistente (per lo piu' in C#... Mah...), e manco son riuscito a trovare una lista vagamente completa (e neppure abbozzata) di attributi che secondo il formato e' legittimo chiedere da una parte all'altra.
Mi ero proposto mesi fa' di rendere SubConsciousDaemon compatibile con lo standard, in modo da sfruttare la base dati di Hyppocampus appunto come collezione di metadati interrogabile da applicativi esterni, ma negli ultimi venti minuti mi e' quasi passata la voglia: con delle indicazioni del genere non so fino a che punto il formato si possa diffondere e radicare, e quanto possa realmente affermarsi nella prossima tornata di software desktop-oriented. A parer mio, o chi sa davvero come funziona la baracca (ed ha dunque le necessarie competenze) provvede a fornire qualche strumento piu' concreto che non una sommaria lista di tags XML piu' o meno validi, si' da incentivare l'utilizzo della tecnologia, o non si va da nessuna parte...

lunedì 24 marzo 2008

Modu

0 commenti
La notizia non e' nuova, gia' l'amico Ninja me ne fece cenno un mese fa', ma solo adesso leggendone menzione su TechCrunch mi e' venuto in mente di riportare la cosa su questo mio blog.
Pare che dei pazzi israeliani stiano mettendo a punto una sorta di telefono cellulare espandibile: forniscono da una parte il core (una piastrina grossa come un biglietto da visita, in cui risiede l'hardware essenziale del telefono) e dall'altra tutta una serie di gadgets elettronici in cui piazzare sto' cosino, dagli chassis stilosi per ogni occasione alle sveglie agli impianti audio alle console portatili. Consiglio di dare uno sguardo al sito di riferimento (na' zozzeria completamente in Flash, ma tant'e'...), tanto per farsi una idea.
L'idea non mi sembra male, si tratta forndamentalmente di una forma di integrazione hardware (e gia' in passato ho menzionato quanto sia importante l'integrazione software...), sebbene credo che una connessione wireless tra componenti sarebbe piu' appropriata: a naso, mi sembra un tantino scomodo il fatto di arrivare a casa la sera e dover sfilare la piastrina dal guscio usato durante il giorno per infilarlo nella sveglia o in qualche altro arnese posto sullo scaffale... E c'e' inoltre chi mette in discussione le potenzialita' prettamente commerciali di questa soluzione...
Il progetto e' interessante, ed e' comunque una fonte di ispirazione in vista del giorno in cui alla FIC si decideranno a mettere in vendita il tanto discusso OpenMoko...

martedì 18 marzo 2008

Uno, Nessuno, Centomila Linguaggi

0 commenti
La lettura di questo brevissimo articolo (trovato oggi su Slashdot) mi ricorda uno dei propositi che vorrei concretizzare nel prossimo futuro in SubConsciousDaemon: permettere la creazione di plugins in ogni possibile linguaggio di programmazione.
La realizzazione di per se' non dovrebbe essere complessa (basta creare un unico plugin che lancia l'eseguibile esterno e ne parsa l'output secondo un certo criterio predefinito... Brutale, ma rapido da implementare ed efficace), ma al di la' dell'utilita' o meno dello strumento ammetto che vorrei fare cio' anche e soprattutto per avere un modo (ed un pretesto) per scrivere un po' di codice in linguaggi diversi da quelli che sinora ho manipolato in modo semi-serio (ovvero: C, PHP, Java e poco altro).
Uno dei punti chiave di "The Pragmatic Programmer" (tomo menzionato anche nell'articolo sopra linkato, e di cui consiglio la lettura a tutti) e' appunto quello di sforzarsi per imparare almeno un nuovo linguaggio ogni anno, giusto per tenere la mente allenata e sufficientemente elastica per saper approcciare ogni sorta di problema secondo punti di vista diversi. Chiaramente, il suggerimento nasconde tra le righe un messaggio ben diverso che non "studia C++, Java, e Perl, PHP e Python ad oggetti": lo scopo dell'esercizio e' quello di affrontare diversi modelli di programmazione, che vadano oltre quella imperativa o ad oggetti, addrendrantosi magari nella programmazione funzionale, logica o di qualche altro tipo.
Sta di fatto che magari gia' stasera daro' una occhiata veloce ad Erlang, che viene citato da piu' fonti in special modo come linguaggio dedicato alla programmazione concorrente...

sabato 15 marzo 2008

... e vissero tutti paralleli e contenti

0 commenti
Sebbene negli ultimi due giorni avrei dovuto scrivere un po' di roba (documentazione, articoli e quant'altro...), ho "perso" un po' di tempo a leggere un paio di interessantissimi documenti che segnalo qui su questo blog.

Il primo e' una serie di slides in merito a OpenMP, framework dedicato alla computazione parallela e da non molto tempo incluso anche in GCC.
La cosa fenomenale di questa tecnologia e' che e' sufficiente aggiungere nel proprio codice C poche direttive di preprocessore laddove si voglia suddividere la computazione su piu' blocchi da eseguire contemporaneamente (sfruttando magari un processore multicore...), e lasciare al compilatore il compito di occuparsi di immettere le istruzioni necessarie a caricare i threads, chiuderli, pescarli da un pool permanente, proteggere le variabili condivise per evitare race conditions, schedulare e molto altro. Il set di direttive e' limitato, e dunque facilmente maneggevole (soprattutto per me che ho scarsa memoria ;-) ), eppure appaiono strumenti per ogni sfumatura e per tutte le necessita'.
Mi spiace non avere sottomano un processore multicore su cui sperimentare pienamente i vantaggi della parallelizzazione, ma mi ripropongo comunque di metter mano a questa potente tecnologia, e chissa' che non finisca con l'usarla pesantemente in Lobotomy... Sarebbe interessante scrivere addirittura una libreria standalone di "utility" che implementi algoritmi e strutture dati disegnate a priori per la parallelizzazione...

Il secondo documento, piu' di carattere teorico ma comunque ricco di spunti di riflessione ed ispirazione, e' in merito ad un kernel scritto con finalita' di sperimentazione e ricerca da quello che era uno studente universitario qualche decennio fa': Synthesis.
In esso sono descritti una quantita' di concetti di fine computazione ed ottimizzazione estrema del codice, soprattutto riguardanti l'implementazione del kernel ma usabili in parte anche a piu' alto livello logico. Anche qui, ampio spazio e' riservato a divagazioni sulla parallelizzazione delle operazioni, col fine di ridurre la latenza e massimizzare la computazione pura, e sulla loro sincronizzazione.
E' un peccato che il tutto sia stato scritto in assembler, e su una architettura hardware oggi visibile al piu' in qualche museo...

Buona lettura :-)

Tutorial su DBus

0 commenti
Poiche' un po' di spam non fa mai male...
L'altro giorno ho messo online, su BarberaWare, un tutorial in italiano sull'utilizzo di DBus, demone di inter-process communication di alto livello largamente usato dalle ultime implementazioni dei componenti in Lobotomy.
Al contrario di quanto precedentemente accennato non ho tradotto il tutorial esistente (in inglese), ma ne ho steso uno mio completamente da zero: spero di essere stato abbastanza chiaro nei contenuti, sebbene per forza di cose taluni argomenti sono complicati e tali rimangono.
Spero che questo documento possa essere utile a qualcuno (primo tra tutti: HS1, cui lo avevo promesso almeno un mese fa' :-P ) e contribuisca a far radicare DBus come standard di interconnessione tra le applicazioni sul desktop Linux: come piu' volte detto, c'e' tanto bisogno di integrazione...
Attendo feedback in merito :-)

mercoledì 12 marzo 2008

Lobotomy nella Blogosfera

1 commenti
Segnalo qui la pubblicazione dei primi due brani della prevista serie di articoli dedicati al progetto Lobotomy, da me scritti e gentilmente ospitati sul blog Pettinix. Lo scopo e' quello di fornire una presentazione informale, stringata e globale del progetto, ad uso e consumo degli occasionali lettori che bazzicano la blogosfera italiana.
Qualcuno si domandera' "Ma perche' sta roba non la pubblichi sul blog tuo, o sul sito di riferimento???". Una risposta non c'e', semplicemente qualche giorno fa' ho lasciato un commento ad una news riguardante un filesystem basato su MySQL ed il maintainer mi ha chiesto di scrivere qualcosa su Lobotomy per conto suo, tutto qui. Del resto, un po' di spam non guasta :-P
Accorrete e leggete numerosi! Io intanto corro a stendere il pezzo sulla LibHyppo!

martedì 11 marzo 2008

Scatole Cinesi

0 commenti
Negli ultimi giorni ho piu' volte preso a lavorare sulla nuova incarnazione di Kiazma, la libreria grafica del progetto Lobotomy, ma solo ieri sera sono giunto ad una di quelle conclusioni che implicano un cambiamento radicale nella progettazione e nel processo di sviluppo. Ad una visione rivoluzionaria deve corrispondere una implementazione rivoluzionaria, o quantomeno assai diversa da quanto visto fino a quel momento.
Come piu' e piu' volte detto (e spero prima o dopo di completare il draft di presentazione dell'approccio in discussione) nella piattaforma a tuttora in sviluppo le applicazioni non saranno altro che descrizioni del layout degli elementi sul video, con forti limitazioni per chi stende i template nel linguaggio formale di riferimento (onde non garantire troppa liberta' e mantenere coerenza nell'ambiente) e pesante sfruttamento delle implicazioni dovute alle relazioni tra le informazioni visualizzate. A questo punto, andando a stravolgere il fondamento dello sviluppo di software per il desktop e ponente uno strato di astrazione tra il programmatore e cio' che viene presentato sullo schermo, quanto vale ancora il paradigma delle "scatole cinesi" implementato in tutti i moderni toolkits grafici? Vale ancora la pena di preoccuparsi di realizzare widgets di contenimento e formattazione variegati, secondo l'ottica di fornire al developer quanti piu' possibili strumenti e mettendo tutto nelle sue mani? Forse no...
In questo momento sto rivoltanto la logica gerarchica in cui dovranno essere organizzati i vari elementi inclusi in Kiazma, e credo proprio che alla fine dell'opera non sara' piu' particolarmente corretto chiamare questa libreria "toolkit", almeno non riferendosi al significato canonico del termine.
Al momento non approfondisco i dettagli, un po' perche' li devo a mia volta studiare ed un po' perche' sarebbe inutile senza l'accompagnamento del gia' menzionato draft sul linguaggio XML il cui interprete dovra' essere incluso in Synapse; rimanete sintonizzati per maggiori informazioni ;-)

Per la cronaca: tra una compilazione e l'altra sto anche esplorando tecniche ed elucubrazioni sulla programmazione parallela e la virtualizzazione... E' probabile che nel prossimo periodo questo blog si popoli di idee bizzarre :-P

venerdì 7 marzo 2008

Giramento di Palle

0 commenti
Chiaramente il titolo di questo post non si rifa' a qualche mio aneddoto particolare (sebbene ne avrei tanti da raccontare su questo tema...), ma ad un curioso dispositivo di input visto or ora in un articolo linkato da Slashdot. Si tratta di una sorta di joystick / mouse / leva / trabiccolo tridimensionale, usato nel video incluso come strumento di interazione con un videogioco ma potenzialmente usabile per tutto.
L'opportunita' di codesto genere di nuovi devices di puntamento sta nell'abbattimento dei limiti imposti dall'odierno mouse, con il quale e' gia' tanto riuscire a manipolare una interfaccia bidimensionale sullo schermo, ma l'altra faccia della medaglia sta appunto nella propagazione dell'oggetto e nell'effettivo sfruttamento della tecnologia: per spremere al meglio la potenzialita' dell'arnese sarebbe bene costruire intorno ad esso un nuovo modello di interazione "fisico" (cioe': non "interazione" nel senso di rappresentazione dei dati, come nel caso di Lobotomy, ma di manipolazione e navigazione di tali informazioni, magari in un ambiente 3D o comunque su piu' livelli), ma come si puo' pensare di intraprendere tale avventura senza manco avere sottomano sto' coso? Indubbiamente un cambiamento del genere imporrebbe una distruzione degli schemi odierni, ma quali sono i margini di una azione siffatta?
Personalmente sono un sostenitore dei nuovi strumenti fisici di interazione con la macchina (e per il mouse nutro lo stesso sentimento che esprimo per la nozione corrente di desktop environment: esiste da trent'anni, ha fatto il suo tempo...), ma sono conscio del fatto che essi prevedano uno shift ben maggiore che non una diversa rappresentazione astratta dell'informazione.
Tempo addietro (mi accorgo adesso di non averne mai fatto menzione sul blog) pensavo alla trackball come parziale alternativa al mouse, in particolare a qualcosa del genere: una grossa sfera e' facilmente maneggiabile, non ha il difetto di dover essere spostata (come appunto il mouse), sa essere veloce o precisa a seconda della necessita'. Vedrei bene la BigTrack sul tavolo della cucina di casa mia ;-)

lunedì 3 marzo 2008

Una Shell User-Friendly

0 commenti
Ho appena scoperto un simpatico progetto, che mi ripropongo di mettere alla prova una volta arrivato a casa e messo mano al portatile.
Il progetto si chiama fish, ed e' una shell. Si, una shell, come bash o zsh, ma orientata all'usabilita'.
E' forse un po' bizzarro associare una shell, applicazione completamente incentrata sulla linea di comando e dunque per definizione ostica per l'utente medio, al concetto di usabilita', ma ammetto che la lettura del breve documento introduttivo al design adottato per l'implementazione e' illuminante: vengono riportate poche e semplici regole universali, che trascendono la presentazione del software nei confronti dell'utente e sono applicabili a qualunque tipo di applicativo.
E fu cosi' che anche la command-line divenne a prova di utente...

domenica 2 marzo 2008

Modularizzare Kiazma?

0 commenti
Da qualche giorno galleggiava nella mia testa l'idea, e per coincidenza giusto pochi minuti fa' ho scoperto che forse la cosa si puo' fare senza particolare sforzo.
L'idea consiste nel permettere l'estendibilita' di Kiazma con moduli esterni: definendo a priori una interfaccia cui devono aderire i widgets rappresentanti ad esempio un result set sarebbe possibile implementare un proprio elemento grafico e piazzarlo in un plug-in, da linkare a runtime a Synapse ed usare quando direttamente menzionato da un viewer. In questo modo sarebbe facile ad esempio costruire un widget che rappresenti un result set come una struttura tridimensionale, o che evidenzi le relazioni di un certo tipo tra gli elementi coinvolti, o in forma di acquario in cui gli items galleggiano (e' solo un esempio, se qualcuno si azzarda a fare una porcata simile gli mozzo le gambe...), ed arricchire le applicazioni costruite per Lobotomy.
Ebbene: trovandomi per non so piu' quale ragione sul sito di GTK ho trovato un breve tutorial su come usare GTypeModule per gestire per l'appunto GTypes dinamici usando l'astrazione dei GModules (inclusa in Glib). Come parte integrante del documento viene fornito anche un simpatico esempio di cui devo ancora esplorare attentamente il codice, ma che in linea di massima sembra fatto apposta per venire incontro alla mia necessita'.
Devo ancora meditare sulle solite implicazioni "tecniche" che si aprirebbero offrendo questa possibilita' agli sviluppatori esterni (come gia' detto tante volte: meno liberta' viene garantita, piu' coerente e' il sistema nel suo complesso), ma e' una idea che andra' analizzata in futuro.

sabato 1 marzo 2008

Un Toolkit in 47 Righe

0 commenti
Questa sera, dopo lunghe e difficili elucubrazioni, sono riuscito ad ottenere un risultato per lo schema XML di cui vado parlando da qualche giorno (e non solo): un DTD di 47 righe, che include quasi tutto quello di cui ci sara' bisogno per definire "applicazioni" nel prossimo Lobotomy.
Manca ancora la definizione di un micro linguaggio di scripting che permetta di aggiungere controlli condizionali e fare qualche minima trasformazione al volo sui contenuti, e chiaramente la lista di funzionalita' che sara' possibile invocare dalla "viewer" verso la componente "controller" del nuovo sistema (ovvero: alla serie di daemons che dovrebbero girare indipendentemente dall'interfaccia grafica), ma almeno gli elementi di formattazione ci sono.
Come e' possibile formalizzare un toolkit in 16 tags e qualche attributo XML? La risposta e' semplice: la stragrande maggioranza delle rappresentazioni e' implicito. Sapendo a priori come trattare un certo metadato (in funzione del suo tipo, definito nella lista in LibHyppo: stringa, numero, o booleano che sia) non c'e' necessita' di esporre ad alto livello text entries, checkboxes o altro; c'e' bisogno solo dell'identificativo univoco di tale metadato. E un riferimento al file da cui tale valore si vuole prelevare.
Ora vorrei scrivere il solito paper informale di presentazione del primissimo draft (che sara' di certo pesantemente rielaborato prossimamente) per meglio illustrare i principi su cui si fonda il tutto, e preannuncio che ho gia' definito un prototipo di client di posta in un paio di files XML da 50 righe l'uno da usare come esempio.

venerdì 29 febbraio 2008

PlexyDesk

0 commenti
Ieri ho scoperto un nuovo (almeno per me...) progetto, segnalato dal ben noto blog di pollycoke (di cui mi ostino a seguire il feed nonostante la scarsa affinita' che provo con il personaggio che lo mantiene...).
PlexyDesk e' un desktop manager che si presenta con la promessa di permettere all'utente di gestire piu' facilmente le informazioni ad esso accessibili. Sebbene mi sia astenuto dal gridare al miracolo guardando i video pubblicati (che si incentrano in larghissima parte alle proprieta' decorative dell'ambiente... Fuffa, insomma...), molto simpatica ho trovato l'idea di organizzare i task in forma di icone sul desktop: ogni iconcina rappresenta un programma aperto, e cliccandoci sopra si apre e si chiude la finestra relativa. Nonostante i forti limiti di questo approccio (per cui gli elementi sulla scrivania virtuale vanno inevitabilmente a confondersi tra riferimenti a processi in esecuzione, files e launchers), vedo che non sono l'unico a reputare la tradizionale taskbar non piu' sufficiente ad un moderno ambiente operativo, e questa soluzione (se opportunamente implementata) potrebbe essere un discreto compromesso verso un futuro in cui saranno le attivita', e non i singoli files, ad essere oggetto dell'attenzione dell'utente.
Nota a margine: la navigazione del sito del progetto mi ha fatto tornare in mente il proposito di usare anche io video e supporti multimediali assortiti per le dimostrazioni dei componenti di Lobotomy; quasi quasi faccio un filmino dell'output dello unit test concernente gli observers del VFS di Hyppocampus 0.3rc2 e lo metto su YouTube :-P

mercoledì 27 febbraio 2008

L'Imbuto

0 commenti
Si sa che maggiore e' l'integrazione software che si vuole raggiungere piu' ricca e flessibile deve essere l'API di riferimento, che deve considerare quanti piu' casi possibile in modo da unificare il comportamento delle applicazioni e convogliare l'informazione in un numero limitato di punti cruciali per poterla smistare e manipolare facilmente.
Sempre nell'ottica di tagliare al massimo lo schema XML per le "view" che dovranno essere rappresentate in Synapse, e lasciare all'interprete (o meglio, al compilatore: sto accarezzando l'idea di compilare i templates descritti, per ovvi motivi di efficienza...), ho buttato un occhio alla lista di idee e propositi per funzionalita' da includere prima o poi direttamente nel framework (se non addirittura nei reconditi meandri del sistema, ad uso implicito per tutti) e mi sono accorto di avere in passato gia' pensato ad alcune cosucce che torneranno utili.
Riporto qui copia di tale lista, commentando gli elementi che maggiormente necessitano di delucidazioni, con la speranza di ottenere un poco di feedback sulla bonta' dell'API e su eventuali side effects non precedentemente previsti.
  • scritture a blocchi mirate. Questo sarebbe da includere in qualche modo nell'interfaccia verso Hyppocampus (ovvero: girando attorno all'attuale interfaccia POSIX che passa per il VFS del kernel), e servirebbe a facilitare ed accelerare la scrittura su supporto permanente di ogni modifica apportata dall'utente a qualunque metadato e soprattutto ai contenuti dei files, si' da eliminare completamente il concetto di "salvataggio" esplicito. Le scritture dovrebbero avvenire ad ogni singolo cambiamento apportato (al piu' schedulando temporaneamente i contenuti e ripetere il ciclo solo ogni N millisecondi), ma il problema sta' nella necessita' di esprimere la posizione assoluta della modifica (ad esempio, se correggo il testo nel mezzo di un file) senza spostare gli altri contenuti che vi stanno attorno (si ricorda che l'interfaccia POSIX nasconde il partizionamento dei files in blocchi e fa apparire il tutto contiguo: se si aggiungono N bytes, gli altri vengono shiftati e dunque riscritti...)
  • attivazione dei processi batch quando il PC e' in idle. Chiaramente questo meccanismo dovrebbe permettere di sfruttare il clock inutilizzato della macchina per procedimenti impliciti (ad esempio l'estrazione automatica dei metadati, o magari anche il fetching della posta e dei feeds RSS), e dovrebbe essere tarato per bilanciarsi autonomamente entro intervalli di tempo brevi: insomma, va bene fare questo genere di operazioni quando ad esempio parte il salvaschermo (come fa Seti@Home), ma personalmente credo che questo sia un approccio molto rudimentale al problema...
  • Staminal. Su questo mi sono gia' espresso in un paper apposito
  • estrazione dei metadati in funzione del contesto ambientale. Largamente ispirato dal gia' menzionato splendido articolo "Magic Ink", ritengo sia una idea potenzialmente buona quella di categorizzare (= popolare di metadati mirati) i contenuti in funzione del luogo, del tempo e, piu' in generale, del contesto in cui sono creati e manipolati. Sarebbe necessario ponderare sulle euristiche da adottare
Ci sarebbe forse altro da segnalare ma per ora mi fermo qui, anche perche' e' venuto tardi e tra l'inizio e la fine di questo post ho mandato una mezza dozzina di mail.
Di materiale su cui concentrarsi ce n'e' a iosa. Tutto sta nel trovare il tempo...

martedì 26 febbraio 2008

Navigator

0 commenti
Serata ricca di complessi ragionamenti tra vecchie e nuove idee: mettendomi all'opera sulla definizione dello schema XML per i templates da far interpretare poi a Synapse (di DTD, XML Schema e Relax NG mi son gia' rotto, sto adottando una mia sintassi estremamente informale che prima o poi formalizzero' meglio...), e partendo dal presupposto di ridurre all'osso il numero di elementi utilizzabili, sono (ri)emersi numerosi concetti solo parzialmente indagati nei mesi scorsi, alcuni qui menzionati ed altri che hanno vissuto solo poche ore nella mia sola testa. Mi stupisce vedere come tutto si ricollega e come molti conti tornino quando ci si ferma un momento a meditare: vedro' di accompagnare la pubblicazione dello schema (o almeno del primo, incompletissimo e bacato draft) ad una ricca spiegazione sulle scelte e sugli apparenti paradossi che verranno adottati.

Ma questo post ha uno scopo preciso che trascende la mia attuale attivita' di yoga creativo.
Scartabellando la lista di widgets che avrei voluto in passato implementare nella libreria Kiazma, di cui si dovrebbe trovare copia incompleta in fondo al file NEWS accluso all'ultima release di Synapse, mi sono accorto che numerosi oggetti non avranno piu' ragione di esistere nella prossima generazione del framework, essendo per lo piu' legati alla canonica concezione di interazione e di desktop: non servira' piu' un file chooser (essendo fondamentalmente impossibile riferirsi direttamente ad un item e dovendo passare tutto per un result set), ne' tantomeno un widget che permetta di selezionare una applicazione installata (non esistendo "applicazioni"...)...
Tra tutti i nomi segnati, uno mi ha fatto tornare in mente una idea forse abbastanza buona ma che ad oggi scarto non essendo piu' in linea con la direzione intrapresa dallo sviluppo, ma che vorrei qui riproporre a futura memoria e con la speranza che possa risultare interessante ed utile ad altri.
Il widget in questione e' il KiazmaNavigator, ed e' stato partorito durante l'osservazione dei video di presentazione del mai sufficientemente discusso iPhone. Di che si tratta? Semplicemente, di un contenitore di pannelli. Piu' o meno come il GtkAssistant, ma a due dimensioni di navigazione.
Fondamentalmente avrebbe dovuto trattarsi di un oggetto volto a facilitare lo sviluppo di interfacce per i piccoli monitor dei devices mobili, entro cui ordinare una serie di schermate (pannelli, liste, immagini...) secondo un ordine tabellare anziche' lineare: alcune potevano essere messi "sotto", altre "sopra", o a destra e a sinistra. Ma "sopra" e "sotto" rispetto a cosa?
Credo che tutti abbiano visto almeno un video sullo scorrimento delle immagini nel gia' menzionato dispositivo targato Apple, in cui trascinando col dito da una parte all'altra si passa al file precedente o successivo; ebbene, perche' non usare lo stesso metodo per navigare dappertutto? E perche' non estendere le direzioni di navigazione alla dimensione verticale?
Immaginando di poter potenziare la sopra descritta interfaccia di visualizzazione delle foto, perche' non aggiungere anche un pannello "sotto" (ovvero: raggiungibile trascinando il dito da sotto a sopra) ad ogni immagine che ne riassuma le proprieta' (dimensione, data di creazione...)? E permettere di tornare alla navigazione delle cartelle spostandosi in alto (trascinando il dito da sopra a sotto)? E visualizzare una cartella o un'altra usando sempre lo spostamento orizzontale? Ed entrare in un'altra cartella spingendo la schermata in giu' con la falange?
Il KiazmaNavigator avrebbe avuto appunto il compito di semplificare la gestione di questo ordinamento, e di implementare il codice di contorno per la gestione dell'"attrito" durante gli spostamenti del dispotivo di puntamento (l'indice della mano).
Non e' detto che l'idea sia completamente rigettata, essendo comunque a tutt'ora valida pure nel Lobotomy che verra' se si ragiona nell'ottica di dover operare su una superficie ridotta come quella di uno smartphone, ma al momento la rimuovo dalla lista.
Se qualcuno nel frattempo vuole trarre ispirazione, faccia pure ;-)

lunedì 25 febbraio 2008

LoboBuilder?

0 commenti
Breve post per annunciare il fatto che nel weekend ho a lungo ponderato sul traduttore di "viewers" da includere in Synapse, ed anzi per meglio analizzare il problema sto abbozzando un DTD.
Prossimamente vedro' di studiare il funzionamento ed il codice del GtkBuilder, widget recentemente introdotto nello stack GTK+ proprio per costruire interfacce a partire da una descrizione XML: quel che vorrei fare e' molto simile, con la differenza che nel mio caso devo rendere piu' esplicita la distinzione tra gli elementi rappresentativi del result set estratto da Hyppocampus su cui il template viene applicato e gli elementi dediti al layout e alle funzionalita' dell'applicazione descritta, si' da innestare automaticamente nell'interfaccia grafica finale presentata concetti come l'environmental mapping e l'aggiornamento per mezzo degli observers.
Tra ieri ed oggi ho abbandonato il proposito di usare XSLT in quanto produrrebbe risultati troppo statici, e sono orientato all'implementazione di un vero e proprio interprete che tag per tag costruisca l'interfaccia con widgets Kiazma (misto JSON?) e provveda a distribuire coerentemente i signals per l'integrazione con gli altri meccanismi impliciti del sistema.
Altre novita' fresche fresche sul modello che voglio costruire: possibilita' di creare templates di rappresentazione per result sets o per singoli items, forte contenimento dei templates (che non potranno descrivere piu' di una schermata, ma potranno comunque riferirsi ad altri templates. Insomma: l'interfaccia per il "client di posta" non sara' descritta in un unico file, ma ci sara' quello per leggere i messaggi, quello per rispondere ad una mail, quello per scriverne una nuova...), e magari anche possibilita' di includere un template dentro un altro in modo da usarli come "super-widget" riusabili.
Ma prima di andare oltre, farei quasi bene a studiarmi decentemente tutti sti' formati XML...

venerdì 22 febbraio 2008

Deja vu: il paper

0 commenti
Ho or ora finito e pubblicato un documento che mira a descrivere meglio l'idea della taskbar cronologica, presentata qui qualche tempo fa'.
Piu' ci penso e piu' il concetto mi garba, credo che lo terro' nel cassetto per un po' prima di arrivare al (lontano, lontanissimo...) momento in cui potro' implementarlo in Synapse.

Per la cronaca: in questi giorni, nonostante i diversi impegni collaterali, mi sto occasionalmente concentrando sul modello da adottare per la gestione della componente "viewer" del sistema che si intende costruire nel prossimo desktop manager / ex file manager Synapse, ed al momento sono particolarmente orientato per l'implementazione di un interprete di "views" espresse in XSLT cui sottoporre i result set estratti da Hyppocampus in XML. Come gia' parzialmente anticipato vedro' di creare una sorta di descrizione JSON dei widgets che andro' a ricostruire in Kiazma, si' da sfruttare almeno un po' la gia' esistente interfaccia ClutterScript e risparmiarmi un po' di lavoro, e dovro' inventarmi una formalizzazione per l'invocazione delle API di sistema rivolte al "controller" dal template XSLT.
In poche parole: non aspettatevi una imminente release...

lunedì 18 febbraio 2008

twitter

2 commenti
Mentre stavo attendendo il checkout del repository CVS di Sun Grid Engine, per poter lavorare alla pacchettizzazione dell'applicazione per Linux su architettura Sparc (luuunga storia, in cui al solito c'entra il mio sistemista preferito...), e dopo aver gia' intrapreso l'avventura su del.icio.us, mi son registrato su twitter, il famoso sito di... microblogging.
Il gioco e' semplice: quando si ha voglia, si scrive li' cosa si sta facendo. Nulla di piu', nulla di meno.
La considero abbastanza una fesseria, popolare piu' per moda che per effettiva utilita', ma lo stesso pensavo di del.icio.us e alla fine l'ho scoperto in forma di valido strumento: chissa' che non finisca a sfruttare concretamente anche questo servizio (per cui gia' mi son installato la relativa estensione per Firefox) per appuntarmi le idee che mi vengono al volo e scrivere di quando in quando qualcosa di potenzialmente interessante e facilmente reperibile...
Chi mi vuole, mi cerchi qui.

domenica 17 febbraio 2008

Hyppocampus 0.3rc2

0 commenti
Finalmente, ce l'ho fatta! E' incompleta, instabile, poco documentata, ma la release 0.3rc2 di Hyppocampus e' stata rilasciata!
Come anticipato, un grosso lavoro e' stato fatto sul layer di VFS in LibHyppo, che ora include una serie di oggetti che astraggono metadati, items e result sets dal filesystem. Per non parlare del meccanismo di observers che si appoggia su SubConsciousDaemon 0.4.3, rilasciato anch'esso pochi minuti fa'.
Ora, prima di potenziare ulteriormente il core del sistema Lobotomy (una lunga lista di features e correzioni e' ancora da implementare, per non parlare del debug e del testing che sinora hanno sempre latitato...), vorrei iniziare a mettere insieme anche la componente di interazione grafica seguendo la direzione del modello MVC gia' piu' volte menzionato: come gia' detto Kiazma verra' prossimamente riscritta interamente usando il toolkit Clutter, e Synapse rinascera' in forma di interprete per le viste di presentazione dei risultati estratti dalla base dati.
Questo e' un piccolo passo verso la release 0.3 final...

"Centers" e "Activities"

0 commenti
Lorenzo Bellini, lo studente milanese menzionato nello scorso post da cui mi sono giunte le prime notizie in merito al progetto ItsMe, rivolto alla creazione di un nuovo modello di desktop, mi ha linkato questo breve documentuccio, incompleto a causa della sua ristrettezza ma sufficientemente chiaro: tra i concetti basilari della nuova prossima implementazione (di cui al momento non ho dati piu' esaustivi e di cui attendo impaziente la pubblicazione di un sito web dedicato) v'e' quello di "center", ovvero un punto gravitazionale di informazione intorno a cui orbitano tutti gli oggetti digitali (files, contatti, logs, mail...) che hanno in comune qualcosa tra loro. Partendo da questo mattone logico, l'utente puo' navigare i suoi contenuti in funzione delle relazioni semantiche che essi hanno.
Sembra bizzarro, ma questa idea mi ricorda la nozione di "attivita'" intorno a cui iniziai a costruire le primissime versioni di BrainTop numerosi anni addietro (qui una pagina di descrizione sommaria, seppellita nelle pieghe dell'Internet e non piu' accessibile direttamente): la differenza maggiore sta nel fatto che all'epoca io, giovine ed inesperto developer che maneggiava per la prima volta codice C di una certa complessita', permettevo all'utente di costruirsi i propri insiemi di files correlati e l'ambiente grafico si limitava a trattare tali scelte passivamente (mai sentito parlare di "semantic desktop" a quel tempo...), mentre in questo caso e' il sistema che si preoccupa di dividere e riordinare i dati secondo criteri automatizzati, ma credo che il concetto rimanga piu' o meno lo stesso.
Concetto che, personalmente, ho in parte abbandonato: sorvolando sul fatto che BrainTop stesso e' ufficiosamente (e presto lo sara' anche ufficialmente) abbandonato, essendo sostituito dal modello MVC che vede impiegato Synapse, credo che il fatto di aggregare piu' o meno esplicitamente gruppi di files rischi di limitare le potenzialita' espressive del sistema. Allo stato attuale il fondamento dell'intero progetto Lobotomy sta nell'informazione atomica del "metadato", entita' singola ed indipendente da qualsiasi altra cosa, che puo' essere raccolta a discrezione di chi si trova dinnanzi al monitor e vuol fare qualcosa: il modo in cui i metadati sono selezionati ed ordinati sul momento, creando di fatto una relazione tra piu' elementi, e' lasciato in mano a chi definisce la query di ricerca, e nessuna decisione a priori viene presa nemmanco sulla presentazione dei dati estratti (che puo' essere cambiata liberamente in qualcunque istante, come dichiarato nel documento introduttivo all'MVC sopra linkato).
Ad ogni modo il proposito e' degno di attenzione ed interesse, e ribadisco nuovamente la mia curiosita' nei confronti di prossimi dettagli su questo intrigante ItsMe...