Alessio Biancalana Grab The Blaster di Alessio Biancalana

GitLab 7.1 - sempre più simile a GitHub, ma open source

GitLab 7.1

Nonostante in questo periodo stia guardando con interesse qualsiasi notizia proveniente dal mondo open source mi ero perso uno degli aggiornamenti più importanti riguardo - probabilmente - uno tra i miei software preferiti, ovvero GitLab. Il clone open source del sistemone che usa GitHub (non esageriamo, ma in piccolo è così) infatti si è reso veramente molto simile al suo parente chiuso, con alcune feature che, portate in uso stabile in questa release, lo rendono perfetto anche per aziende che dal proprio flusso di lavoro pretendono parecchio anche a livello di frontend per i propri sviluppatori.

Bando alle ciance, il changelog di GitLab 7.1 parla da sé:

  • API per i contributor: adesso possiamo prenderci tutti i contributor di un progetto con una singola chiamata API. Statistics incoming! :D
  • Discussioni: se c’è una cosa che GitHub sa fare bene, è consentire a persone potenzialmente sociopatiche e omicide di esprimersi verbosamente senza causarsi danni fisici. GitLab ha fatto tesoro di tutto questo, implementando un frontend per le discussioi che permette di tirare in ballo linee di codice, emoticon e quant’altro (persino cambiamenti & co.) senza dover sacrificare nessun gallo nero al signore oscuro. Un grosso passo avanti. Mi scusino gli sviluppatori che si sentono vessati da queste osservazioni… ma lo sapete meglio di me che è vero. Vi vengo a portare le arance al gabbio, prometto.
  • Nuova pagina di login: è bellissima. Punto. Forse un filo enterprise, ma ci sta.
  • VERSION nella sidebar: se avete un file VERSION all’interno del repository, vi verrà mostrato nella sidebar il contenuto, ovvero il version number. Mai più persi tra mille rilasci ;)
  • Milestone di gruppo: semplicemente epico. Se abbiamo un progetto suddiviso in più sottoprogetti, le group milestone permettono di raggruppare tutte le issue di tutti i progetti che appartengono a una milestone nominata ugualmente in ogni sezione. Questo significa che per la milestone “pippo” potremo avere una visione di insieme parecchio ampia per quanto riguarda ogni milestone e chiuderla (o riaprirla per lavori dell’ultimo minuto) con molta più cognizione di causa, esaminando la situazione nel complesso.

È sicuramente un bel traguardo, questo, sia per GitLab che per l'intera comunità open source: avere a disposizione sia GitHub (che ormai è lo standard de facto per tutto quello che viene portato avanti in totale apertura) che un software as-a-service per sviluppare qualcosa di interno dove decidere la disponibilità per il pubblico di ogni repository è un grosso valore aggiunto, dato che naturalmente si abbassano i costi della piattaforma di code hosting, e soprattutto chi vuole può installare il proprio software in-house senza dover dipendere da fornitori con comportamenti ballerini.

Auguri GitLab, ancora una volta :-)

KDE: nuova API per la decorazione delle finestre

KDecoration 2

Our decoration API is also showing it’s age. It’s cumbersome to use, too difficult to use. In fact there is a KDecoration and a KCommonDecoration – the latter trying to make KDecoration easier to use by for example providing buttons. The API got extended several times to support more features which are all optional. […] So what makes KDecoration2 better? Obviously it’s no longer QWidget or QWindow based. Instead it’s a pure QObject based API.

La citazione di cui sopra è di Martin Gräßlin, che mi fa sempre impazzire per la qualità eccellente della comunicazione di ciò che accade all’interno del ciclo di sviluppo della decorazione finestre di KDE. In sostanza, adesso KDecoration2 (ovvero il nuovo decoratore delle finestre in KDE Frameworks 5) espone una API basata su QObject, la quale immagino che renderà più flessibile la manipolazione della titlebar in modo da non introdurre solamente oggetti come i bottoni più classici dei classici, ma anche altro.

Un po’ come OS X, per esempio, o le header bar di GNOME Shell. Però fatte un po’ meglio.

Vi(m): impararlo con un solo video

Vim on a Linux shell with dwm

Ormai vi è diventato per me uno strumento di costante lavoro. Quando non mi viene richiesto un IDE lo utilizzo per scrivere codice e parecchio altro; soprattutto mi torna utile in tutti quegli ambiti dove un editor grafico seppur buono come Sublime Text non mi serve allo stesso modo. Proprio oggi sfogliando Reddit sono inciampato in un utilissimo video che insegna come usare vi (e conseguentemente anche vim).

Imparàtevelo. Vi servirà, ne potete star certi.

[youtube=http://youtu.be/h1Utc-zsQJI]

Come mi ricorda il mio amico Claudio che sta seduto qui affianco a me in treno a farmi da umarell mentre scrivo (:-D) su Linux potete servirvi di vitutor, che fa la stessa cosa in maniera leggermente più pratica e meno "videata".

Docker 1.0: impressioni, analisi e previsioni

In questo periodo sono successe parecchie cose, per questo ho preferito tralasciare un pochino il blog, ossia adattarlo ai nuovi ritagli di tempo di cui dispongo (che sono ancora inferiori a quelli che avevo prima) - un po’ tipo Calcare con il suo, non so se avete presente. Dico questo solo per giustificarmi di un’assenza prolungata: c’entra ben poco con quello che sto per introdurre.

Dock

Sul finale di questo mio periodo di assenza infatti è stato annunciato Docker 1.0, ossia una milestone release del progetto che maggiormente, probabilmente, da un anno a questa parte ha attirato la mia attenzione. Docker è, in buona sostanza, un modo intelligente di sfruttare LXC per innestare le applicazioni che configuriamo in dei veri e propri “container” virtuali, i quali poi possono essere esportati su qualsiasi altra macchina. È richiesto solo Docker; fornita un’infrastruttura di base, tutto il resto continuerà a funzionare. Docker è versatile, perché è eseguibile in istanze virtuali, ma anche su macchine fisiche, e così via. La praticità di Docker è innestabile a qualsiasi livello, e questo lo rende una tecnologia perfetta anche a livello enterprise.

Cosa significa Docker 1.0

Docker 1.0 significa un sacco di cose. Principalmente, significa che ora come ora Docker è una piattaforma in rapida crescita, che si appresta ad avere come target il mondo enterprise ad un livello visto sinora solo con tecnologie come OpenStack (e, ehm, Linux? Ma voglio andarci piano coi paragoni). Per questo motivo, mi aspetto che in questi mesi e principalmente nel prossimo anno Docker raggiunga un livello di diffusione planetario, anche perché il suo primo periodo di vita depone molto bene a suo favore: con i numeri che ha alle spalle, sicuramente è diventato una tecnologia su cui investire del tempo, che magari in Italia viene snobbata per alternative vecchie come il cucco e sostanzialmente best-effort, ma che magari può fornire buone opportunità per consulenze in aziende estere, anche di grandi dimensioni.

Docker 1.0 significa feature: la codebase si ingrandirà, tanto che con questo traguardo già abbiamo alcuni importantissimi segnali di un progetto sano e di successo, come un registry pubblico dei container (simile ad npm per Node.js, ma per i propri dock), chiamato Docker Hub, e tantissime caratteristiche come ottimizzazioni sullo scheduling e sulla rimozione dei container che, beh, non fanno che rendere Docker più production-ready di quanto già non fosse. Di quanto già non fosse per un motivo ben preciso: Docker è un software che, a prescindere dalla bontà de facto del codice sorgente, è stato capace di tirare su dei numeri notevolissimi mentre lo stesso team di sviluppo si spolmonava (beh, più o meno) a scrivere ovunque “do not run in production”. E di irresponsabili, per così dire, in giro ce ne sono stati parecchi. Alcune cifre e alcuni nomi ce lo possono testimoniare.

Momentum: numeri e fatti su Docker 1.0

Ce lo dice l’annuncio di rilascio: Docker per tutto l’ultimo anno, dal 20 marzo 2013, è stato praticamente il protagonista dell’innovazione emergente dal punto di vista dei sistemi e della virtualizzazione in container. Quello che abbiamo davanti, da qualche settimana, è un tarball che dietro nasconde questo:

  • 460 contributor;
  • 8.741 commit;
  • 2.75 milioni di download;
  • 14.000 “Dockerized apps”, che suppongo siano container uploadati su quello che ora è il Docker Hub.

Ma non solo: Docker ha subito un pesante endorsement da aziende che fregandosene del suo status hanno cominciato ad integrarlo nella propria infrastruttura e a sperimentarci su. Per esempio, una serie di nomi molto interessanti, anche di aziende che producono software che usiamo sul nostro PC ogni giorno:

Per non parlare dei casi di studio forniti da Atlassian, PuppetLabs, IBM, Netflix, Google.

Docker: risorse interessanti e tutorial

Contestualmente a tutto questo fiorire di Docker nella produzione e nella pre-produzione di aziende il cui fatturato arriva ad essere una parte rilevante dell'economia globale, hanno cominciato a spuntare come funghi risorse su Docker, insieme a degli articoli che spiegano come sfruttare al meglio questo software all'interno di determinati processi. Ne ho da poco cominciato a stilare una piccola collezione, che riporto qui di seguito allo stato attuale, anche per tenere traccia di come ad oggi sia messo il panorama. Periodicamente condividerò anche altro, ma già ora - che Docker non è nemmeno diventato per così dire pronto per il panorama enterprise - ci sono diversi post che hanno suscitato il mio interesse.

  • Persistent volumes with Docker – Data-only container pattern - Un interessantissimo post che segnala come sia possibile creare dei container di soli dati per il management dei contenuti grezzi via Docker, in maniera da non perdere nulla, avere tutto ciò che facciamo tracciato tramite i sistemi di logging dell'infrastruttura e molto altro ancora. Utile, utile, utile. L'ho già detto utile?
  • Red Hat mashes Docker containers into its Enterprise Linux distribution - Yes! Docker è attivamente supportato da Red Hat, il che significa che nella prossima Red Hat Enterprise Linux questa tecnologia sarà installabile con un colpo di yum e un po' di olio di gomito per quanto riguarda la configurazione. Certo, è un endorsement di piccola entità, ma venendo da un colosso come Red Hat che non dà mai niente per niente, sicuramente conta più che il Docker incluso in qualsiasi repository third-party di una distro a caso scalcagnata.
  • Analyzing Docker’s New OSS: libchan and libswarm - L'annuncio di Docker 1.0 non ha significato solo stabilità, ma anche una serie di nuove librerie completamente open source per la composizione di servizi di rete complessi che fanno uso (tra le altro cose) anche di Docker. Libchan, libswarm e libcontainer sono dei fulgidi esempi di come un'azienda possa innovare non solo con il proprio prodotto di punta, ma con un ecosistema di librerie a corredo che rendono possibili delle caratteristiche piuttosto utili. Nell'articolo trovate tutti i dettagli, ad esempio, di come con un banale docker ps sia possibile grazie a libswarm avere una panoramica dei processi in esecuzione in più container. È una lucidissima analisi di come queste librerie appena rilasciate possano letteralmente cambiare il modo in cui è concepita e implementata la cloud che utilizziamo attualmente.
  • Integrating Docker with Jenkins for continuous deployment of a Ruby on Rails application - Un caso di studio piccolo, se vogliamo elementare, ma esemplare. I grandi software possono essere messi alla prova anche e soprattutto con piccoli compiti, e Docker con Jenkins non sfugge a questa logica: con questo tutorial possiamo implementare un piccolo caso di continuous integration dove Jenkins costruisce dei Docker container, e se i test unitari vanno a buon fine, li esegue. Personalmente, apprezzo molto questo tipo di contenuti, anche perché mostrano applicazioni reali di software che altrimenti non avremmo (quasi) idea di come usare. L'idea di utilizzare Docker come layer mediano in una struttura del genere è interessante (e onestamente non so come ho fatto a non pensarci prima. Genio! [cit. René Ferretti])
  • Announcing Docker Automated Builds on Bitbucket - Atlassian non solo si impegna nello sperimentare con Docker, ma offre a tutti noi utenti di Bitbucket (e, ehm, spero presto anche di Stash) un modo per fruire delle Automated Build senza dover per forza ricorrere a GitHub. Un modo come un altro, questa partnership, per avvicinare delle community e generare un impareggiabile valore aggiunto.

Photo courtesy of Tristan Taussac

Telegram per Linux: arriva Sigram (finalmente)

Sigram, Telegram per Linux

Già ho avuto modo di esprimermi molto favorevolmente nei confronti di Telegram, che al tempo dell'ormai "storico" down di Whatsapp aveva preso il volo come l'alternativa per la messaggistica più gettonata. Nonostante i dubbi sulla sua politica per quanto riguarda l'open source e la privacy degli utenti, comunque l'avevo reputato decisamente più sicuro del concorrente Whatsapp e personalmente ho avuto modo di apprezzare la possibilità di avere delle API pubbliche che permettessero lo sviluppo di client di terze parti.

Telegram per Mac è un gran software, con il quale mi sono trovato piuttosto bene negli scorsi mesi, ma sinceramente lavorando la stragrande maggioranza del tempo sul mio desktop Linux (si applari, avete sentito bene) ho sentito la mancanza di un client nativo per questa piattaforma, potendo solo fare affidamento su Webogram, un client web-based di cui è disponibile anche l'app per Chrome.

Per fortuna, come ho letto su WebUpd8, è stato sviluppato Sigram, un client per Telegram che gira su Linux e utilizza tutte le mie tecnologie preferite:

  • C;
  • C++;
  • Qt;
  • QML.

Praticamente un sogno a occhi aperti per chi ama le librerie Qt - e perché no, anche la loro portabilità. L'interfaccia non è nemmeno malaccio, giocoforza QML rende tutto il software un po' webbarolo e il gusto degli sviluppatori, evidentemente deformato da eventuali esperienze in Silicon Valley (se non sono dei residenti), ha fatto si che implementassero questa UI flattona (neologismi come se piovesse oggi eh) che però non si accorda molto bene con Unity o con qualsiasi ambiente desktop presente su Linux. Forse con KDE va un po' meglio, ma siamo lì.

Per quanto riguarda l'installazione, in maniera molto spartana, dagli sviluppatori vengono forniti dei pacchetti .deb che dovrebbero andar bene sia su Ubuntu che su Debian. Viceversa, per le altre distribuzioni, mentre alcune non sono supportate, per le più popolari Fedora (e OpenSUSE?) e Arch Linux abbiamo una assortimento non ufficiale di RPM e PKGBUILD.

Nel complesso, sono molto soddisfatto. Un grande grazie agli sviluppatori, e un buon Telegram come sempre a tutti.

Member of

Previous Random Next