16 Sep 2012
Succede che scrivi un post, su come stiano cambiando certi paradigmi. Illustri quello che hai visto per strada, cioè un pieno clamoroso di nuovi top di gamma Android, iPhone che cominciano a ridursi al minimo, e utenti che nonostante tutto il marketing dello stupore hanno cominciato a farsi stupire da feature reali e handset prestanti.
Succede poi che ti prendi una vagonata di insulti e critiche infondate: c'è chi dice che iOS è l'unica piattaforma stabile sul mercato, che Android "dà problemi", e chi ti viene a confutare con una grammatica da seconda elementare (a malapena) - e argomenti anche più puerili, tant'è che finisce per dire una marea di scemenze confondendo l'apertura di una piattaforma, i processi open source che la contraddistinguono e tutto il resto, con la peculiarità del Play Store di non assicurare un meccanismo di QA alla fonte. Cose, insomma, che vomitate a raffica senza ritegno dalla bocca di presunti tecnici ti fanno seriamente pensare a quanto la mediocrità stia invadendo un settore come quello dell'IT.
In aggiunta a questo, come condimento, come il cacio sui maccheroni, dati di vendita dell'iPhone 5 sciorinati come l'Ave Maria, presunti sold out di prevendite dove non si hanno numeri di richieste e numeri di giacenze reali, tutto pronunciato - virtualmente - con un astio incredibile, come se a chi lo ricorda venisse in tasca qualcosa, o anzi anche più di qualcosa.
Esco, vado a farmi un giro con la mia dolce metà nel "mondo reale": aperitivo del sabato sera. Il mio amico Emiliano tira fuori il suo HTC Explorer, un telefono che costa poco e ti da tanto: "Sai Ale, ho letto il tuo articolo sull'iPhone 5: c'hai veramente ragione. La potenza dell'open source è immensa, pensa che su questo telefono ho messo la CM9 che è arrivata da poco, un tizio s'è messo di buzzo buono a programmare finché non ce l'ha fatta". Prendo il suo terminale in mano, ci faccio il solito giro di prova. 130 euro di costo originale, Android 4.0.4, accelerazione hardware abilitata, esperienza utente molto fluida per l'hardware di cui dispone.
Mi descrive poi come percepisce gli utenti Apple, o almeno quelli (pochi) contenti del nuovo iPhone 5. "Grazie, signora Apple, di aver messo ancora un altro caricabatterie non standard, io volevo la USB come tutti i mortali, ma se tu mi dici che è più figo così, allora sono disposto a tutto pur di averlo" - me ne parla come del migliore dei rapporti sadomasochisti, e io mi trovo totalmente d'accordo. Concordiamo anche sul fatto che ultimamente, a quanto pare, la società sta perdendo consenso a causa di un fallimento insito nella sua strategia di marketing dello stupore. Tra i commenti sensati che ho ricevuto all'articolo: "Steve Jobs era tutta un'altra cosa, adesso c'è Tim Cook che ha presentato il prodotto senza accarezzarlo" - probabilmente sono le conseguenze di aver preso la strada di unire la figura di CEO e quella del testimonial principale della compagnia.
Insomma, fetta di utenti scontenti a parte, c'è ancora chi non solo dice si, ma dice anche sissignore. Ad un padrone che più lo tiene a stecchetto a livello di feature, più lo fa godere ad un livello che sfiora la dimensione sessuale; e sta lì, incapace di dire basta, e di rivolgersi ad altri, per colpa della gabbia dorata in cui si trova, che gli ricorda ogni giorno quanto è bello lui, e quanto è malvagio il mondo.
L'altro giorno ho postato un'immagine finita anche su Mashable, di Obi Wan che maneggia un presunto iPhone 20 (lunghissimo) come una spada laser. C'è da chiedersi come mai abbia collezionato in circa una giornata 500 +1, e 300 reshare.
Photo courtesy of Mike Lau
12 Sep 2012
In questo periodo come sapete sono stato un po' impegnato con il progetto #opencore, di cui vi ho già parlato. Il mio trofeo più grande, ad ora, rimane quello di essere riuscito a porre qualche domanda al CTO di OverBlog, Xavier Hausherr, che si è dimostrato molto gentile ed ha risposto anche a questioni spinose sull'open source. OverBlog è una piattaforma ottima per aprire un proprio blog, ed ero proprio curioso di sapere come fosse composta l'infrastruttura alla base di questa piattaforma che, sin dal primo sguardo, mi ha sempre dato l'idea di uno strumento molto complesso e raffinato sul quale viene svolto ogni giorno tantissimo lavoro.
Ho quindi "marchiato" anche OverBlog con le mie cinque domande, grazie a Paolo Mulè, country manager italiano di OverBlog, che, all'idea dell'intervista un po' più da smanettone, si è subito offerto di fare da intermediario tra me e il team di sviluppo. Un grazie quindi a lui e a Xavier.
L'intervista
Come si pone OverBlog rispetto al concetto di libertà? C'è una roadmap specifica o più generalmente un atteggiamento mentale sul fatto di permettere agli utenti di "smanettare" più a fondo con la piattaforma?
Il nostro desiderio è far sentire i blogger a casa propria quando usano OverBlog. Per far questo, vogliamo offrire loro quanta più libertà possibile, attraverso la creazione e la personalizzazione dei temi, la flessibilità dei layout e l’organizzazione dei contenuti, il rilascio di una API e di alcuni widget che verranno configurati grazie ad un sistema contributivo. Quindi possiamo dire che sulla questione c’è una roadmap molto chiara.
Ogni piattaforma fa affidamento su una serie di applicativi più o meno critici, come un webserver e un'infrastruttra cloud. Questi sono generalmente descritti come uno "stack software". Com'è costruito lo stack software di OverBlog? Quali sono le applicazioni che ne sono alla base? Sono open source?
Il nuovo OverBlog è stato costruito per essere flessibile al massimo in termini di sviluppo e scalabilità. La colonna portante di OverBlog è la Service-oriented Architecture (SOA).
Ogni progetto è indipendente: da una parte abbiamo i cosiddetti “servizi core” (Blog, Commenti, Utenti, eccetera), dall’altra abbiamo i veri e propri “siti web” (nello specifico l’Interfaccia di Amministrazione e il Portale). Questa configurazione permette ad ogni progetto di sfruttare le tecnologie che meglio soddisfano le sue specifiche necessità, senza alcun limite.
Allo stato attuale, per quello che concerne il livello di backend, i nostri progetti sono costruiti in PHP con il framework Symfony 2. Utilizziamo, per lo storage di dati, i seguenti sistemi: Postgresql, MySQL, Redis e Memcache.
Il layer di frontend è anch’esso sviluppato in PHP con Symfony 2. Per il Javascript, usiamo il framework YUI, con un layer di housing chiamato Yoshioka (https://github.com/hadrienl/yoshioka.js), disponibile gratuitamente.
I nostri servizi comunicano l’uno con l’altro attraverso un layer di trasporto binario chiamato Thrift, creato da Facebook e incubato da Apache. Abbiamo fatto parecchio lavoro di ingegnerizzazione su questo punto in particolare, per assicurarci delle ottime performance, e siamo veramente soddisfatti del risultato.
Invitiamo a dare un’occhiata alle nostre slide, presentate al Symfony Live 2012 a Parigi, che spiegano questi punti dettagliatamente: http://fr.slideshare.net/xkobal/the-use-of-symfony2-overblog
Per tutti i server, utilizziamo la distribuzione Linux Debian. Le pagine sono distribuite tramite Apache. Il tutto è ospitato su dei server VmWare che ci permettono una grande flessibilità nel creare nuove macchine e questo, di conseguenza, aiuta tantissimo nella sfida per la scalabilità.
Parliamo di sviluppo e programmatori. Quali sono gli strumenti fondamentali (IDE, VCS, altro) usati dai developer di OverBlog? Puoi descrivermi la tipica workstation di uno sviluppatore di OverBlog?
La cassetta degli attrezzi di ogni sviluppatore di OverBlog comprende quasi sempre gli stessi tool:
- Lavoriamo tutti su piattaforma Mac, con una macchina virtuale Debian-based “fatta in casa” e una configurazione centralizzata grazie a Puppet. Questo rende il tutto molto facile da aggiornare. C’è anche installato tutto il software che serve per eseguire l’intera piattaforma OverBlog in locale!
- Sviluppiamo in PHP 5.4
- I developer del frontend usano NodeJS
- Tutti i nostri sorgenti sono ospitati su GitHub
- Per quello che concerne l’IDE, i nostri tool sono Netbeans, Textmate e, ancora, PhpStorm
Sarebbe carino se Timekiwi/OverBlog fossero open source. C'è qualche piano futuro per rendere tutto questo lavoro open source (sotto GPL, o Apache) e disponibile per i power user?
OverBlog non è concepito per essere open source. Ci sono parecchie ragioni per questa scelta, incluso il fatto che il codice deve in primis performare su un’infrastruttura estesa come quella che usiamo noi. Non è assolutamente inteso per essere utilizzato come motore per un blog singolo su un server, come fanno alcuni dei nostri competitor.
In ogni caso, essendo noi stessi fautori e fruitori di open source, rilasciamo alcune parti dello sviluppo che portiamo avanti e dei miglioramenti che apportiamo come Thrift (al quale abbiamo contribuito), parecchi bundle di Symfony, il nostro framework javascript Yoshioka.js e, sicuramente, un po’ di altri progetti nel prossimo futuro. Questi progetti sono disponibili su GitHub: https://github.com/ebuzzing
Hai 400 caratteri per dirmi qualsiasi cosa sull'open source e l'open culture.
Sin dalla sua creazione, nel 2004, OverBlog ha sempre usato o contribuito a progetti open source, come Postgresql, Symfony, Thrift, o altro. Un’espressione che ci piace, e che riassume il nostro pensiero, recita: “Perché reinventare la ruota quando qualcun altro l'ha creata così bene?”
L’open source ci aiuta a sviluppare OverBlog, il che sarebbe difficile da fare usando software proprietario: la piattaforma che abbiamo creato è estremamente specifica, e necessita di essere spinta molto più lontano di quanto qualsiasi software basilare ci permetterebbe di fare. E conosciamo tutti la difficoltà di far evolvere un software non libero!
In cambio, ripaghiamo la community open source pubblicando i miglioramenti che abbiamo apportato sviluppando il software stesso.
07 Sep 2012
È sempre interessante per uno smanettone come me ottenere dati ufficiali sullo stack software di una determinata applicazione web - soprattutto se ancora chiusa al pubblico, o agli sviluppatori. Nel caso di soluzioni invece aperte, ma gestite da un'azienda che ne controlla in qualche modo il processo evolutivo, mi piace comunque andare a scavare e guardare i servizi offerti da un punto di vista abbastanza diverso da quello del tipico utente finale.
È così che un paio di settimane fa mi sono seduto alla scrivania, e ho cominciato a buttare giù quasi per noia una piccola serie di domande che mi piacerebbe rivolgere (anche in salsa leggermente diversa ogni volta) a figure chiave di ogni startup tecnologica o compagnia operante nel settore dell'informazione, per vedere come è percepito l'open source all'interno del mondo aziendale.
Chiamerò questa "cosa" #opencore; ho già iniziato a porre le mie domande a qualcuno, e probabilmente a breve sentirete parlare di questo piccolo progettino che ho in mente. Il lavoro di selezione delle aziende e delle persone da intervistare è abbastanza difficile, ma credo di potercela fare: ciò che è certo, è che ho iniziato nel migliore dei modi.
Con un progetto di una simile portata, credo, finalmente l'open source conterà su un po' di fattiva documentazione in più non solo cartacea, ma euristica, sull'adozione e lo sfruttamento di tali tecnologie per un processo di innovazione maggiormente aperto, puro e, si spera, community-based.
Photo courtesy of Kristina Alexanderson
27 Aug 2012
Soprattutto in questi ultimi tempi, si è fatto un gran parlare di Arch Linux su alcuni media (specialmente Twitter e Google+) relativamente alla cerchia solita dei Linux user italiani - nonché alcuni blog. Questo mi ha convinto a rispolverare un grande classico per pubblicarlo, ossia i cinque più grandi falsi miti su Arch Linux. Arch è una distribuzione inflazionata, infatti, e col tempo è stata testata praticamente sulle macchine di chiunque: alcuni hanno avuto l'onestà intellettuale di dire "non è una distro che fa per me"; altri hanno semplicemente messo in giro FUD diffondendo opinioni squisitamente personali spacciate come fatti oggettivi, cosa che per il modus operandi dialettico del sottoscritto trasforma queste affermazioni in cazzate.
Dato che sempre più spesso capita di farsi il sangue amaro su persone che non hanno ben chiari filosofia e obiettivi del progetto Arch Linux, ho pensato quindi di stilare, e qui concludo con il preambolo, questo piccolo Bignami che spero torni utile a ciascuno di noi, in un qualsiasi thread di Google+, una conversazione di Twitter, o quando pensiamo di stare per pronunciare (si, noi arcieri) un'offesa marcata contro gli stessi sviluppatori. Ché non sono mica solo quelli che se la prendono facilmente, a scagliarsi contro Arch Linux.
È una rolling release quindi è meno sicura/stabile
Sbagliato. Per due motivi: essenzialmente tutto il lavoro di sicurezza sul software open source viene svolto upstream. Le patch che vengono applicate ad esempio dal ramo Security di Debian sono backport di codice che rende l'applicazione maggiormente sicura ad una versione meno recente, in modo che venga tappata la falla in quella specifica versione del pacchetto. Una distribuzione rolling release, invece, ha cura di fornire all'utente, bene o male, sempre l'ultima versione del pacchetto disponibile; per questo motivo, possiamo dire che le distro rolling release sono orientativamente sicure quanto le distro a ciclo di rilascio periodico - se non di più, ove il patching e il backport del codice non avvengano in tempi ragionevolmente brevi.
Per la stabilità il discorso è lo stesso: l'ultima versione di un software upstream incorpora anche patch provenienti da tutte le distribuzioni. Quelle poche volte che il lavoro di aggiornamento riguardo un bug di stabilità non viene svolto upstream, nulla vieta agli sviluppatori (o agli utenti, dato che è assunto che gli utenti di Arch Linux abbiano tale capacità), se non vogliono attendere, di applicare la patch di un'altra distro al pacchetto e rilasciarlo subito.
Se invece si tratta di bug chiusi upstream, la nuova versione sarà migliore. Le distribuzioni a rilascio periodico invece dovranno attendere che il ramo instabile diventi stabile; per bug non gravi che affliggono un numero moderato di persone, questo può essere un problema.
Inoltre, Arch Linux dispone di un repository Testing, dove vengono testati moltissimi pacchetti prima del rilascio nel ramo stabile. A volte vengono persino creati dei repository ex-novo per impedire che nuove release di un software contaminino la stabilità dell'ecosistema dei package che "vivono" all'interno di Core ed Extra (i due repository che essenzialmente costituiscono il ramo stabile di Arch Linux).
Pacman non è all'altezza di APT/RPM
Falso. Pacman implementa meccanismi largamente in voga nelle distribuzioni Linux, ma in maniera più semplice. Ad esempio il signing dei pacchetti: viene fatto in maniera meno complessa di APT, e molto più user-centrica. È il tool chiave di Arch Linux, e se è vero che non è da meno a gestori di pacchetti più blasonati fornendone le stesse funzionalità, un buon argomento di conversazione potrebbero essere gli innumerevoli miglioramenti di cui Pacman avrebbe bisogno. Dire semplicemente che "Pacman fa schifo" è una goliardata che merita di finire nell'Olimpo delle frasi stupide del panorama Linux.
Un aggiornamento può distruggere il sistema
Falso. Anche se molte persone hanno pensato che fosse vero vista la loro pervicacia nel forzare alcuni aggiornamenti nonostante fosse scritto ovunque di non usare assolutamente l'opzione --force su uno specifico package. Nonostante ci sia stato quest'ultimo caso eclatante (l'ultimo, epico, aggiornamento di glibc), avevo sentito più volte l'affermazione legata anche ad altri aggiornamenti critici. Il punto è che Pacman (per scelta, non ce lo scordiamo) non gestisce i file di configurazione e gli aggiornamenti da fare a questi ultimi. Questo compito in Arch Linux è lasciato all'utente il quale ha come assistenti un ottimo wiki, e soprattutto le indicazioni non appena un pacchetto viene installato.
Utenti che aggiornavano alla cieca quindi si sono visti scomparire il sistema in stato consistente da sotto i piedi, semplicemente perché prima di un reboot non hanno letto il log di Pacman che diceva di aggiungere una banale opzione, una voce aut similia ad un file di configurazione.
Con chi te la vuoi prendere in casi come questi? Ma coi developer naturalmente. I quali avevano l'impegno morale e l'imperativo categorico di telefonarti a casa per avvisarti. Seh.
Di solito l'argomento più efficace contro le persone che affermano una cosa del genere è che forse potrebbero uscire dall'analfabetismo e leggere il log di Pacman, specialmente dopo un aggiornamento ciccione da centinaia di megabyte - o peggio, qualche giga.
Gli utenti di Arch Linux sono spocchiosi
Sbagliato. In realtà, se le cose vengono chieste con cortesia ed educazione, è possibile trovare negli utenti di Arch Linux una risorsa inestimabile in termini di case study, bug affrontati, bug risolti, ecosistema open source, e soprattutto bei birrozzi in compagnia.
Quello che amo della comunità di Arch Linux, allo stesso tempo, è quel latente senso di MIT anni '70 per cui se dici una cavolata, nel giro di trenta secondi lo sapranno tutti (stile condominio con comari annesse) - e comincerà a breve una serie di battute sarcastiche nei tuoi confronti. Niente di cui lamentarsi riguardo la cattiveria comunque: di solito sono prese in giro bonarie (o binarie?) di chi si diverte a ostentare un po' la sua superiorità nei termini della questione che viene discussa sul momento.
Ci sono persone che percepiscono questa cosa come una barriera, e me ne dispiaccio perché ho incontrato spesso persone conosciute sul canale italiano di Arch Linux, o sulla board nazionale, e non mi sono mai trovato male. Mai e poi mai.
In coda, un monito: se un utente Arch Linux - specialmente di quelli della vecchia guardia - sta dicendo che avete torto durante un dibattito su Linux, di solito è bene rivedere le proprie posizioni. Perché state effettivamente, al 90%, avendo torto; e se continuate a dare addosso a questo genere di persone, che sono abituate a dimostrare che quello che dicono è vero coi fatti, è probabile che vi sbugiardino su tutta la linea con una serie di prove schiaccianti. Alla faccia della spocchia: abbiamo solo sempre ragione :D
Gli sviluppatori di Arch Linux sono pazzi e inseriscono nuove feature a caso e in maniera improvvisa
Sbagliato. O meglio: gli sviluppatori di Arch Linux inseriscono nuove feature in maniera improvvisa ma non sono né pazzi, tantomeno lo fanno a caso. In Arch Linux la necessità di aggiornamento è completamente a carico dell'utente, e può capitare, come sopra, che alcuni update siano leggermente più difficili da gestire che premere il tasto y sulla tastiera.
È un rischio potenziale per qualsiasi aggiornamento, ma ci si può accorgere di questo con dei piccoli trucchetti: uno è tenere d'occhio le news, che informano gli utenti di qualsiasi aggiornamento farraginoso. L'altro piccolo trick è guardare la lista dei pacchetti in aggiornamento prima di fare un update casuale a tutto quanto l'ambaradan: di solito pacchetti come glibc possono essere leggermente più pericolosi ed è consigliato prestare attenzione quando si aggiorna il core del sistema. Questo comprende pacchetti come systemd (si, avete letto bene, systemd), kmod, il kernel Linux, o Pacman.
Inoltre, personalmente ci sono alcune settimane in cui ho necessità di essere più produttivo che in altre. In quei periodi evito di toccare lo stack software della mia macchina, perché so che anche un piccolo cambiamento potrebbe inficiare la mia produttività e il mio workflow. Sono piccoli consigli, metterli in pratica non costa veramente niente e la vostra vita da arcieri ne guadagnerà.
Tradotto, questo pistolotto può essere sintetizzato in: se aggiorni alla membro di segugio non è colpa mia.
Arch Linux non è un sistema pensato per rispondere ad esigenze brainless. A soddisfare i vostri bisogni dovete pensarci voi, ed il sistema vi mette a disposizione tutto ciò che serve per farlo. Quindi, quando accendete la vostra macchina, verificate di aver acceso prima anche il cervello. È gratis.
Image courtesy of Jason Ryan
