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
18 Oct 2013
Al solito, le mie considerazioni pre-uscita sul nuovo flagship device di Google. Perché ho messo una foto del Moto X in copertina, anche se stiamo parlando di Nexus 5? Perché, oltre ad essere una bella immagine in sé, il sentimento che ho provato guardando le immagini semi-ufficiali del Nexus 5 per la prima volta è stato molto simile a quello che mi è stato dettato dalla pancia (sono pur sempre un figlio del consumismo) quando ho visto il Moto X di Motorola: un dispositivo al top, costruito bene, capace di garantirmi anni di supporto e anni di hackability in totale tranquillità.
Malgrado i miei sforzi, sto continuando a non possedere telefoni Nexus (per il tablet invece come sapete ho un bellissimo Nexus 7 di prima generazione), e me ne pento amaramente ogni volta che devo metterci le mani in maniera approfondita; questo Nexus 5 invece un po' come tutti i sui predecessori sarebbe un affare diverso, che mi permetterebbe di avere uno smartphone open... almeno in parte - viste le critiche (sensate!) di Jean-Baptiste Queru a tutto il cucuzzaro.
Così, arriva la vera notizia: stanotte Google Play Devices ha aperto i battenti con il nuovo Nexus 5, immediatamente messo "a tacere" da Google stessa, altrettanto immediatamente leakato e diffuso dalla community che gravita attorno ad Android, come sempre attentissima. Cosa intendo fare? Intendo prenderlo. Esattamente come mi aveva stuzzicato il Nexus 4, anche questo Nexus 5 mi attira parecchio, e credo che farò il grande salto: ne vale la pena, specialmente potendo accedere già da subito ad un - seppur non ancora diffuso in forma di codice sorgente - Android 4.4 stock, e guardare personalmente che cosa c'è di nuovo. Il nuovo design del launcher mi attira molto: chissà se sarà effettivamente così.
Butto i miei soldi? Maybe. Sono un consumista nato, un gadget addicted. Sarebbe inevitabile fare altrimenti.
15 Oct 2013
Parlavamo giusto di piattaforme di blogging, e finalmente ci siamo: Ghost, il software che su Kickstarter aveva debuttato come il "nuovo WordPress" ha fatto il suo exploit oggi con un degno annuncio di rilascio via email e un sito web molto ben curato, che ci lascia disporre della nostra bacheca per scaricare il codice e farne il deploy attraverso BitNami (l'avevamo visto insieme con GitLab) o in autonomia. Mi fa molto piacere, ad essere sincero, che finalmente WordPress abbia un concorrente per quanto riguarda il blogging.
Nonostante il proliferare di piattaforme simili, nessuno aveva la stessa estendibilità, e le stesse proprietà di openness come Ghost, che al momento attuale si presenta come l'alternativa più attuabile per chi ha voglia di migrare il proprio CMS a un'infrastruttura simile a quella a cui è già abituato, e al tempo stesso trovarsi con uno strumento migliore con cui scrivere, apposito per questo. Uno strumento migliore con cui scrivere, già, perché Ghost include una serie di cose carine come una live preview di quello che scriviamo, e supporta il Markdown come linguaggio di formattazione.
Mi sono già iscritto per fare un giro di prova: purtroppo per il momento si può solo scaricare il codice per andare "live" in maniera se vogliamo distribuita, che poi è proprio quello che mi aspetto dal progetto. Gli sviluppi immediatamente futuri però prevedono la possibilità di iniziare un proprio blog con Ghost su una piattaforma mantenuta dagli sviluppatori (in maniera simile a wordpress.com per intenderci), ed essendo io più che pigro per accollarmi lo sforzo di un deploy di software che nessuno mi ha chiesto (:D), attenderò questa feature.
Poi oh, ragazzi: è scritto in NodeJS. Vogliamo mettere? ;)
11 Oct 2013
Michel Alexandre Salim ha scritto proprio qualche ora fa un interessante post sulle motivazioni che l'hanno portato ad abbandonare WordPress in favore di Scriptogram. Anch'io non nascondo di aver pensato a qualcosa di simile, ma sono sempre stato fermato da una considerazione di carattere più filosofico che tecnico: come blogging platform infatti WordPress non è il massimo, e ormai in quanto a built-in feature è un carrozzone obsoleto. Non supporta nemmeno nativamente Markdown, al contrario di tutte le piattaforme più "trendy" di adesso.
Però è WordPress che, oltre ad essere l'engine per grossissima mole di siti e blog al mondo, ha stabilito una certa prassi nel rilascio di codice relativo all'infrastruttura di rete distribuita che abbiamo adesso. Mi domando: è giusto favorire meccanismi accentratori che conferiscono più potere ad una piattaforma centralizzata che ad un utente, impossibilitato ad installare il CMS che più gli piace in locale per il suo uso e consumo personale? Quanto possiamo permetterci di cedere il passo rispetto a qualcosa di simile?
Sicuramente WordPress tramonterà: il tempo passa, le tecnologie cambiano e purtroppo va accettato il fatto che i prodotti muoiano per un turnover agile di sviluppatori,società competitor e dei software stessi. Io però mi auguro che WordPress tenga testa a tutti i suoi concorrenti ancora per molto, e soprattutto nella maniera più open source possibile. Certo, è vero che comunque quello che conta è una API affidabile e ben integrabile per mantenere integro un ecosistema (ed RSS lo è, di fatto), ma sarebbe carino che tutti comprendessero che cosa significa essere utenti di un servizio, ed essere invece provider del servizio che usiamo noi stessi.
