Social Software

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

"Lobotam"?

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

xPUD

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

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

L'Efficienza di un Cesso

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

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

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

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

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

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

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

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

Migrazione!

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

Piastrelle Semantiche

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

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

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

Un Task per Domarli Tutti

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

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

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

Un Futuro che Non C'e'

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

Metodo

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

La Sottile Linea

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