04 Nov 2013
Simone Cicero qualche giorno fa mi ha portato a riflettere sulla questione open data, linkandomi un articolo piuttosto interessante, attraverso un tweet che ha scatenato qualche battuta anche da dei miei sodali quali Roberto Sambuco, Salvo Mizzi e Antonio Pavolini:
http://twitter.com/meedabyte/status/396308827257458688
http://twitter.com/RobertoSambuco/status/396318182837071872
http://twitter.com/antoniocontent/status/396365905028206592
http://twitter.com/dottorblaster/status/396389692381609984
(Mi paro preventivamente: sono estratti di una conversazione leggermente più larga. Il resto lo trovate integralmente su Twitter)
Qualche giorno fa, ho letto questo virgolettato di Bill Gates su Business Insider, riferito a quella che ha tutta l'aria di essere (e lo è) una risposta a Mark Zuckerberg, che si professa quale azzeratore del digital divide, portando tutto questo ad essere un fine piuttosto che un mezzo:
Take this malaria vaccine, [this] weird thing that I’m thinking of," Gates told Richard Waters of FT. "Hmm, which is more important, connectivity or malaria vaccine? If you think connectivity is the key thing, that’s great. I don’t.
Possiamo pensare che siano ordini di grandezza differenti, ma non lo sono. Abbiamo davanti, tutti i giorni, tutto il giorno, una serie di persone che difendono con tutte le loro forze un mezzo, senza dichiararne un fine specifico. Ovviamente per loro il fine è farsi entrare in tasca più soldi possibile, ma noi? Noi abbiamo una comunione d'intenti con questi individui, che spesso amministrano i mezzi che propongono? Ecco, ho pensato a un parallelismo tra la questione open data e il digital divide combattuto da Zuckerberg non a caso.
Spesso infatti si parla di open data (e di qualsiasi altra cosa simile) rinforzando l'argomento in sé e non il fine, se non quello della trasparenza, che è un baluardo a cui di solito le pubbliche amministrazioni si attaccano quando non sanno di cosa parlare in un ambito così tecnico. Tramite open data infatti possiamo realizzare tutta una serie di servizi in "stile" Internet of Things, che con la trasparenza c'entrano poco e niente, e se vogliamo si può anche sottrarre tutto il discorso dell'amministrazione pubblica per guardare il tutto da un punto di vista più ampio, quello tecnico/tecnologico dove ci sono macchine comunicanti tra di loro in formato JSON, che recentemente è stato proclamato standard ECMA, assolutamente interoperanti senza intervento umano. Carino no? È veramente un peccato che dal settore privato e dal settore pubblico continuino ad arrivarci dei CSV senza capo né coda, pieni di cose inutili che a nessuno interessano, mentre il fine di tutto questo sarebbe mettere innanzi tutto i developer dinanzi a risorse interessanti, e la cittadinanza di fronte a un'opera di disclosure mostruosamente potente, sfruttando un mezzo, ossia i famosi raw data.
Prendiamo in esame il secondo esempio: la connettività, l'individuo e il digital divide. Quello che alcuni sostengono è che la connettività in sé sia un bene, ma lo troviamo vero in ogni caso? È forse vero che come direbbe un matematico per ogni X esiste un risultato di questa funzione che è ottimo (non lo è mai, in reatà, ma parlando da matematici, approssimiamo...)? È vero, il digital divide oggi più che mai è un male. E stando fuori dalla questione della legittimità delle opinioni personali in alcuni casi, è in assoluto un male che un individuo venga coercito della libertà di esprimersi al mondo attraverso un doppino telefonico o una cella 3G, come avviene adesso per molti di noi. Il problema è che ci facciamo dire (e lo prendiamo per buono) che tutto questo ci è indispensabile da un tizio che fa una montagna di soldi coi nostri dati personali; io sono molto contento per questo tipo di persone, perché hanno tirato fuori un business praticamente dal nulla, ma accettare di far difendere un principio sostanzialmente per il fine sbagliato è il modo perfetto di prostituire un'idea. E andiamo, chiunque abbia anche solo qualche mese più di me lo sa: Internet senza l'NSA a stendere la mano con PRISM era davvero un posto diverso. Non sto dicendo che non ci fosse qualcosa, una parte di questo, già da prima: sto solo dicendo che anche le proteste, le suppliche e i discorsi hanno un fine. Predicare la fine del digital divide solo per poterci spiare meglio, con noi sotto applaudenti, è in definitiva la miglior forma di autoincaprettamento dell'individuo mai vista.
Esattamente come richiedere a gran voce dei CSV senza capo né coda è la miglior forma di autoincaprettamento di varie categorie: utenti, sviluppatori, amministratori pubblici, società civile in toto.
Vogliamo finirla di legarci da soli?
Photos courtesy of Seth Sawyers, Gregory Haley
02 Nov 2013
Francamente, non mi sono aspettato mai molto dalla mia Fedora installata sulla workstation casalinga, se non che funzionasse senza darmi grattacapi. Ultimamente invece ha cominciato a rendermi veramente fiero di usarla (cose configurate automagicamente, uso del PC scordandomi che OS ci fosse sotto) dandomi però qualche liscebusso per controbilanciare la facilità d'uso. In particolare, stavo andando a scrivere qualche riga di codice per TwitAntonio (dato che, a quanto pare, le API non vogliono funzionare come dovrebbero) e facendo partire il demone di MongoDB mi sono accorto come la procedura di start fosse fallita miseramente.
Uhm - mi sono detto - strano, il pacchetto è installato correttamente. E in effetti controllo: è lì, installato, senza fare una piega. Ho anche il client da CLI: me ne servo, ma mi restituisce che non riesce ovviamente a connettersi al mio host, dato che il demone è spento. La faccio breve: dopo una serie di ricerche, mi è venuto in mente che forse quei buontemponi dei developer di Fedora potevano aver cambiato la nomenclatura e lo stato dei pacchetti nei repository.
$ yum search mongodb
E improvvisamente vedo che spunta qualcosa, qualcosa che prima non avevo mai installato né avuto la necessità di usare:
[...]
mongodb-server.x86_64: MongoDB server, sharding server and support scripts
[...]
Eccolo lì, t'ho trovato maledetto. È stato sufficiente per me dare da terminale:
$ sudo yum install mongodb-server
E la questione è andata a posto da sé: MongoDB è tornato a funzionare senza problemi dato che il file relativo al demone si trovava in quel pacchetto insieme al resto della struttura "server". Per far partire il servizio di MongoDB su Fedora successivamente basta usare systemd:
$ sudo systemctl start mongod
01 Nov 2013
Non voglio vantarmi, ma qualche settimana fa, mentre amici mi condividevano i link di vari messenger sedicenti "sicuri" per quanto concerne la sicurezza dei messaggi che ci si scambia tramite questo mezzo, me ne sono uscito - quasi per battuta - "ma non si potrebbe cercare di rendere le email più sicure senza inventarsi un protocollo del tutto nuovo?"
È un'esigenza concreta nel mondo corporate: usiamo tutti le email, e tutt'ora escludendo il traffico di rete generato dai bimbiminkia e gli ormai trentenni papaminkia che si sparano le pose e mandano foto zozze alle loro amanti via Facebook, l'utilizzo del protocollo email è imprescindibile. È uno standard aperto, uno standard che ormai permea la rete, ma non è più sufficiente. Per questo sono stato contentissimo che Lavabit (il famosissimo "provider di posta di Snowden") e Silent Circle abbiano presentato qualche ora fa insieme la Dark Mail Alliance, che si occupa principalmente di fare ricerca in ambito IT Security per rendere le email qualcosa di cui ci si può ancora fidare.
Direttamente dal post ufficiale sul blog di Silent Circle, la risposta concreta alle mie preoccupazioni:
What we call ‘Email 3.0.’ is an urgent replacement for today’s decades old email protocols (‘1.0’) and mail that is encrypted but still relies on vulnerable protocols leaking metadata (‘2.0’).
Non credo ci sia da dire altro: spero che la ricerca prosegua così com'è iniziata, ovvero letteralmente col botto. Che le nostre comunicazioni siano sicure, in questo periodo, è più importante che mai.
Photo courtesy of Dan Budiac
01 Nov 2013
Era già un po' che ci pensavo, e alla fine l'ho fatto: con il vecchio servizio in scadenza, e il nuovo anno di lavoro alle porte, ho deciso di spostare il blog da un banale hosting condiviso al mio VPS dove tengo anche le altre applicazioni che sto sviluppando, eccetera eccetera. Questo significa che da oggi, su questo blog, a questo IP, a questo dominio risponde un serverino (con Debian come OS) totalmente configurato e amministrato dal sottoscritto, in macchina virtuale, con locazione fisica in un data center di Amsterdam.
Il provider che ho scelto per farmi ospitare è DigitalOcean, per tutta una serie di motivi: primo fra tutti, il loro spot su YouTube che mi ha conquistato, insieme ovviamente ai feedback dei miei amici. Su consiglio di Lorenzo infatti ho creato una droplet di test qualche mese fa, e non me ne sono mai pentito, anzi. Di qui, la decisione. Un altro punto a favore di DigitalOcean poi (almeno per me) è l'attenzione all'ecosistema open: ha una comunità fiorente, e ci sono developer (o membri del team) che donano soldi a chi porta avanti progetti che fanno crescere la piattaforma. Una dote rara da trovare, come ha raccontato sempre Lorenzo in un suo post.
In ultimo, ovviamente il prezzo: per 5 dollari al mese, ossia come dicono negli sport di attrezzi per fitness qualche caffè ogni 15 giorni, abbiamo a disposizione delle istanze dove possiamo scegliere noi il sistema operativo e configurarle come preferiamo, con prestazioni assolutamente elevate e un pannello di controllo al top che permette il deploy rapido di nuove macchine, nel caso in cui l'architettura con cui ci troviamo dovesse (e potesse, chiaramente) scalare rapidamente.
Insomma: per adesso sono soddisfatto. Ah, perché Amsterdam? Perché così posso ospitare chi e cosa voglio, senza preoccuparmi del fatto che GPG sia considerato un'arma termonucleare globale. (Ovviamente, adesso la situazione sulla crittografia PGP è più stabile, ma non intendo solo quella: voglio poter usare la tecnologia che mi pare. Simple.)
22 Oct 2013
In questi giorni mi è successa una cosa abbastanza strana (per me, almeno): ho iniziato a sviluppare un'applicazione, poi effettivamente ho scoperto che il nome che le avevo dato non solo era già preso da un'altra app (che mi aveva pure fregato il dominio), ma era registrato come trademark eccetera eccetera, cosicché se l'avessi usato comunque avrei fatto un grave torto al suo utilizzatore primario. Insomma, ho deciso di cambiare nome all'applicazione.
Posto che non voglio discutere se sia giusto o meno assegnare un nome "ufficiale" a dei repository per app ancora in sviluppo, ho cambiato quindi anche nome al repository Git dove facevo push dei miei cambiamenti: essendo lo sviluppo portato avanti su più macchine, ho avuto delle difficoltà di tipo "rottura di cosiddetti" a migrare al nuovo repository, almeno finché non ho deciso di aprire il manuale di Git per controllare se "origin" potesse essere modificato senza particolari rogne. Così, ho studiato un po'.
Per modificare un URL di un qualsiasi repository remoto a cui abbiamo assegnato uno short name, ci basta dare questo comando da terminale:
git config remote.origin.url $URL
Il che ovviamente corrisponde al modificare il repository origin. Se il repository si chiama pippo, ovviamente ci basterà modificare il nome del repository, intuitivamente:
git config remote.pippo.url $URL
Fine della storia. Così possiamo cambiare URL del repository remoto ogni volta che vogliamo. Ovviamente, per team di grandi dimensioni, è necessario avvisare all'interno del flusso di lavoro di stare fermi, pena trovarsi con commit e push mandati a carte quarantotto, specie se chi lavora al progetto fa parecchie push. Ah, la bellezza della continous integration.
Poscritto - Fulvio mi ha appena ricordato su Facebook che c'è anche un altro modo; da Git 1.7 possiamo anche dare il seguente comando:
git remote set-url origin $URL
