Vintage Computing

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

Building Blocks

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

Back Online

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

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

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

La Sindrome della Prima Volta

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

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

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

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

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

FOSDEM 2010: the Tech Side

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

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

Uno Scalpello per l'Informazione

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

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

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

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

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

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

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

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

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

Stay tuned!

1000000 Ways to Configure

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

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

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

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

Stay Focus

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

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

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

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

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

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

Stay focus. Always.

127.0.0.1 sweet 127.0.0.1

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

Ingenuita' Ingegnerizzata

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