ToDo, UnDo

Uno dei miei pregi come programmatore e' che sono costantemente ispirato e quotidianamente espello idee. Uno dei miei difetti come programmatore e' che non riesco a concentrarmi su un progetto per il tempo necessario alla sua realizzazione, che subito passo ad un'altro.
Da tempo ho preso l'abitudine di appuntarmi le varie piu' o meno dettagliate folgorazioni che mi colgono, sempre col proposito di tenerle sott'occhio ed integrarle via via che scopro nuove tecnologie e metodi, ma inevitabilmente la coda diventa sempre piu' difficile da smaltire a causa dei tempi di realizzazione che avrebbe ogni oggetto, e sebbene nell'ultimo periodo abbia avuto modo di concretizzare qualcosa qua e la' la massa di progetti latenti diventa sempre piu' imponente. "Il genio e' per l'1% ispirazione e per il 99% traspirazione" (Thomas Edison), e non essendo io un genio sono completamente sbilanciato su un 90% del primo ingrediente ed un 10% del secondo.
Pertanto periodicamente espongo le mie (piu' o meno corrette) illuminazioni pubblicamente, nella speranza che qualcuno sull'Internet possa inciamparvi e magari essere altrettanto ispirato: non credo che avro' mai modo e maniera di far tutto, dunque tanto vale che lo faccia qualcun'altro. Ogni tanto pubblico un post su questo blog, qualche volta riporto sull'Alambicco di BarberaWare, e quando raggiungo una massa critica stipulo una lista forfettaria. Questa e' una di queste occasioni.

• Binding Glib per FUSE. L'idea emerse qualche tempo addietro, quando per lavoro iniziai lo sviluppo di un filesystem in userspace che doveva maneggiare GObjects pescati da una libreria ad hoc e ricevere eventi da una connessione DBus (anch'essa mantenuta per mezzo del binding Glib). Data la natura interna di FUSE ho dovuto aprire un thread separato in cui far girare il mainloop, che appunto restasse in ascolto sulla connessione DBus, ma l'ideale sarebbe implementare il mainloop di FUSE dentro quello Glib e far lavorare insieme i due layer. L'optimum sarebbe avere un GObject che astragga le funzioni low-level di FUSE e le richiami nel loop Glib, in modo che estendendo quello sia banale realizzare un nuovo filesystem pur godendo di tutto lo stack Glib e della pletora di sottolibrerie disponibili.
• Rsync wizard. Qualche settimana addietro, intimorito dagli inquietanti rumorini provenienti dall'interno del mio tablet, decisi che era tempo di adottare una soluzione strutturata per il backup. Diedi una occhiata in giro e trovai solo soluzioni immensamente complesse, con server da configurare e centinaia di parametri da settare, nonche' daemons in esecuzione piu' o meno permanente, ed alla fine optai per il metodo in assoluto piu' scontato: una chiave SSH, rsync ed uno script in cron. Per quanto non perfetto questo meccanismo credo soddisfi la necessita' della stragrande maggioranza dell'utenza domestica, ed ha l'unico difetto di richiedere una serie di passaggi da linea di comando non propriamente adeguati per un occasionale utente. L'idea sarebbe dunque quella di predisporre un frontend che provveda a costruire la riga con cui invocare rsync, metterla in cron ed eventualmente creare ed installare le chiavi SSH (onde poter procedere al trasferimento dei dati da un PC all'altro senza dover immettere la password; di norma il server e' installabile con una configurazione funzionale di default con qualsiasi distribuzione). Progetto estremamente semplice da imbastire, ma non completamente banale se si vuole una soluzione finale a prova di utonto, piu' una sfida di design che di programmazione.
  
• Distribuzione dei files Torrent via GIT. Questo non e' un vero e proprio progetto, quanto piu' uno spunto di indagine: emerse ai tempi della notizia dell'acquisizione di ThePirateBay e della prossima imminente chiusura del tracker torrent piu' noto al pianeta, e sebbene molti altri tracker siano disponibili in Rete e risulti ovvio che il ritmo di chiusura sia piu' basso di quello di creazione di nuovi snodi (rendendo infinetesimale il rischio di trovarsi senza un punto di riferimento) varrebbe secondo me la pena individuare una strategia completamente decentralizzata, quale appunto quella adottata dagli SCM distribuiti - GIT, ma anche Mercurial o Bazaar.
• Vista partizionata in Nautilus. Ho sempre trovato Baobab un programma assai utile: permette infatti di visualizzare il filesystem con spicchi che graficamente rappresentano lo spazio occupato dai vari files (e dalle cartelle che tali files contengono), permettendo di individuare in un colpo d'occhio le aree in cui per un motivo o per l'altro si sono accumulati dati in eccesso e di cui dunque ci si puo' sbarazzare per recuperare preziosa ROM. Tale funzionalita' sarebbe molto utile se integrata a mo' di "vista" direttamente in Nautilus, il filemanager di Gnome: si tratterebbe di prelevare il widget originario di Baobab ed includerlo dentro l'applicativo sfruttando la gia' esistente interfaccia programmatoria per tale frangente, ben poco documentata ma usata da questo hack (da usare come esempio). Rapido, ma merita qualche attenzione nel perfezionamento nell'algoritmo che computa la dimensione delle cartelle, al momento un po' lentuccio.
• Binding Bash per DBus. Il nome e' molto evocativo, anche se ai fatti si tratterebbe di qualcosa di estremamente semplice: un set di micro-applicativi (o uno solo, con piu' opzioni) da invocare da linea di comando e che permettano di dialogare in modo flessibile con DBus (ed ovviamente con i servizi esposti sul canale). Scopo del gioco: avere modo di scrivere script Bash che sfruttino i piu' avanzati servizi di sistema, dall'interrogazione di NetworkManager (per sapere se c'e' connessione o meno) alla manipolazione dello screensaver. Il compito e' meno banale di quanto non ci si possa aspettare, in quanto i metodi invocabili per mezzo di DBus possono presentarsi in una infinita combinazione di parametri, tipi di parametri e valori di ritorno, che dovrebbero essere trattati nel modo piu' trasparente possibile magari sfruttando le tecniche di introspezione proprie del protocollo onde fornire una interfaccia di utilizzo semplice.
• Integrazione autenticazione USB. Nell'ultimo periodo ho constatato (ma forse solo perche' non me ne sono accorto prima...) un incremento dei metodi di autenticazione disponibili su Linux, che fanno uso di PAM nei modi piu' disparati. Tra questi ho trovato particolarmente simpatico questo meccanismo, che coinvolge una pennetta USB da usare come chiave fisica di accesso al PC: accessibile immediatamente a tutti (contrariamente agli scanner per impronte digitali, o alle smartcard), sufficientemente sicuro e di garantito effetto con gli amici. Non sarebbe niente male integrare questo sistema nel pannello "Utenti" di Gnome, si' da mettere a portata di mouse la procedura di creazione e verifica delle chiavette e la poca configurazione richiesta.
• FUSE Installer. Tutti gli utenti informatici casalinghi vengono sconvolti da una particolare feature di Mac: i programmi si installano copiandoli in una apposita cartella, e si disinstallano rimuovendo la cartella stessa. Niente wizards "avanti avanti avanti" a la Windows, niente accrocchi strani a la Linux. Da utente tecnico rimango piu' che soddisfatto del package management tipico dei sistemi Linux (qualsiasi distribuzione ha oramai un sistema automatico di risoluzione delle dipendenze, che evita di portarsi appresso mega e mega di librerie con ogni pacchetto), ma ammetto che molti limiti ancora esistano e che il meccanismo vada al di la' della mentalita' irrimediabilmente compromessa dell'utenza (inutile spiegare che per cercare ed installare qualcosa si deve aprire Synaptic, una forza oscura li spingera' sempre a cercare il setup.exe su Internet). Dunque perche' non provare ad unire il meglio dei due mondi, Mac e Linux? Un filesystem FUSE farebbe le veci della "apposita cartella" in cui copiare gli archivi prelevati in Rete, ed internamente dovrebbe provvedere ad analizzare i nuovi files ivi introdotti e trattarli nella maniera che piu' gli si confa': se possono essere gestito direttamente dal package manager della distribuzione si installano nel modo previsto, se sono pacchettizzati in qualche altro formato li si converte con alien, se sono archivi di sorgenti li si decomprime e si esegue il solito "./configure ; make ; sudo make install", il tutto tentando di fare del proprio meglio con la risoluzione e l'installazione delle dipendenze. PackageKit dovrebbe fornire un supporto decente per triangolare i nomi delle dipendenze, il resto... E' lasciato alla fantasia dell'implementatore.
• Versioning degli snippets. Una idea non mia, bensi' presa da qui e che, al di la' della fattibilita', ritengo ingegnosa: assegnare un identificativo ai frammenti di codice comunemente sparpagliati in Rete, in modo da saperli tracciare ed aggiornare qualora avvenga qualche miglioria o correzione. La realizzazione dell'impresa sarebbe quantomeno difficoltosa: occorrerebbe innanzitutto assegnare gli identificativi, e dunque o convincere le varie piattaforme di condivisione degli snippets a farlo o importare tutto il loro materiale su un'altro sito ad hoc che provveda alla trasformazione, e poi integrare metodi di sincronizzazione all'interno dei maggiori IDE, si' che siano in grado di provvedere da soli alla verifica di aggiornamenti, oppure realizzare un deamon dedicato che dato l'indice dei files sorgenti da sorvegliare implementi il ciclo di controllo in modo centralizzato. Forse utopico, ma lo lascio come spunto.

Per ora basta cosi', anche se non ho completamente svuotato la lista: qualche idea semplice semplice spero di realizzarla nel prossimo periodo, qualcun'altro la conservo per maggiori approfondimenti, qualcun'altra ancora e' correlata ad altri lavori ed attivita' dunque tocca a me occuparmene. Rinnovo comunque la speranza che quanto sopra listato possa ispirare qualcuno: si trovano opere molto complesse ed altre molto semplici, per l'implementazione di nuovi applicativi o per l'estensione di altri esistenti, insomma ce n'e' per tutti i gusti e tutte le capacita'.
Alla faccia dei brevetti...