Aurora

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

Modulare by design

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

Un Castello tra le Nuvole

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.

Una ne pensa, cento ne dovrebbe fare

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

KiazmaIconView

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

Presagio

Oggi apro l'aggregatore RSS, e leggo che...

• Nokia compra Symbian e lo rilascera' open al piu' presto
• OpenMoko rilasciato
• LiPS e LiMO si fondono
• Ubuntu "Mobile Internet Device" Edition rilasciata
• il numero di applicazioni costruite su Google Android cresce
  

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.

Touch Me

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

Web costruttivo, Web distruttivo

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.

Saranno Famosi

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

Quattro chiacchere su ItsMe

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.