15 Apr 2016
Doverosa introduzione: non parlo quasi mai di Apple, ma per una volta che non parlo di Linux ci sta dai :D
La prima volta che ho visto un Macbook Air mi ha fatto ridere. Ma veramente: in un tempo in cui usavamo un sacco CD e altre cose del genere, questi matti erano usciti sul mercato con una cosa che praticamente non soddisfaceva alcun bisogno attuale se non quello dei businessman ai quali il portatile aziendale pesava troppo. Uno strumento perfetto per i trasfertisti intercontinentali.
Viceversa col tempo, il Macbook Air ha cambiato form factor, e con il nuovo form factor sono arrivati altri utenti, spingendo la concorrenza a produrre gli ultrabook e tante altre belle cose del genere; nel frattempo comunque gli Air hanno assunto la forma di macchine OSX a basso costo, macchine con un processore vero e utilizzabili anche per sviluppare qualcosa di sensato.
Già l’anno scorso la release del primo Air 12” mi ha lasciato abbastanza perplesso, oggi ho letto John Gruber e Jack March in cascata, e devo dire che non sono d’accordo con lui (intendo Jack):
By removing the ‘Air’ brand, Apple can contrast their MacBook lineup as Good vs Better (MacBook vs MacBook Pro) rather than “Meh” vs Good (MacBook Air vs MacBook Pro).
Alla fine, gli Air sono buone macchine, e per quanto possano significare un compromesso, è una lineup che ho sempre apprezzato perché comunque rappresenta l’entry point nell’ecosistema Apple per chi non vuole spendere un fottiliardo. Il che, onestamente, è più che legittimo per qualsiasi consumatore.
Nice try, Apple.
14 Apr 2016
E insomma, in questi giorni oltre che di scrivere software ho avuto anche la possibilità di fermarmi a riflettere come non facevo da un po’, specie dopo aver fatto la mia entrata in scena su GitLab con quella cretinata di commit. Non è l’unica pull request piccola (o merge request per dirla nel loro gergo) che ho fatto, anzi.
Ce n’è una su Docker, una scemissima su Oh My Zsh. La lista non è corta, anzi; semplicemente ogni volta ho risolto delle piccole cose. Cose che, probabilmente, se non ci fossi arrivato io col ditino ci sarebbe semplicemente arrivata un’altra persona. Ho pensato che nel tempo ho cambiato radicalmente la percezione che ho dei commit. Alcuni estratti del mio pensiero:
- Per quanto piccolo possa essere, un commit idealmente dovrebbe sempre apportare un miglioramento. È inutile adottare una posizione di biasimo nei confronti di chiunque ti mandi del codice, fosse anche solo una riga;
- La documentazione, specie se fatta bene, è sempre la benvenuta; prima avevo un punto di vista diverso nei confronti dei traduttori e di chi si occupava del manuale. Adesso, probabilmente, considererei un commit di documentazione quasi più importante di un bug risolto;
- La tua facezia è sempre il bug di qualcun altro: quante volte vi è capitato di dire “vabeh, questo lo sistemo dopo”? Tutt’ora Burst si spacca se non gli viene passato un argomento
title, anche se tramite l’argument parser l’ho dichiarato opzionale. Per me non è un problema; magari se qualcun altro lo risolvesse sarei comunque contento (io non ho tempo di farlo adesso).
E così via, e così via, e così via. Un esempio bellissimo di come una pull request di peso infimo possa essere trasformata in qualcosa di veramente fico, per esempio, è come è stata trattata la mia proposta su Oh My Zsh per uno snippet che cambiasse l’identità di Git sul momento.
I think there is some hidden potential that we can tap into for a more straightforward way to switch identities, which possibly would become an entirely new plugin. I understand if you don’t want to take on that much work, but as is now I’m not very inclined to pull this in. Thanks!
Interessante vero? E se fosse proprio quello che avevo intenzione di fare? Volevo pastrugnare un po’ con Go per realizzare un programmino da shell che fosse in grado di fare questa roba, viceversa adesso sono più che incline a scrivere un po’ di codice per Oh My Zsh :-)
Questo per dimostrare che no, non esistono pull request ridicole, anzi: contribuire al codice aperto, in ogni modo, arricchisce il software, arricchisce gli altri, e arricchisce noi.
08 Apr 2016
Un software che apprezzo veramente tanto (e chi segue questo blog lo sa visto che ne parlo abbastanza spesso) è GitLab. Visto che ultimamente ho avuto anche un’esperienza ravvicinata con GitLab in un ambiente enterprise con migliaia di push giornaliere, ho imparato anche un po’ più profondamente com’è fatto il progetto in sé: con questo presupposto, ho deciso di inviare un contributo scemo.
Non mi piaceva infatti la disposizione di alcuni elementi grafici, e secondo me mancava un margine in un punto preciso; così mi sono letto le contribution guideline, e ho fatto una piccolissima modifica, sottoponendola poi tramite merge request al core team.
Devo dire che tutto il processo mi ha lasciato molto soddisfatto; grazie alla continuous delivery pipeline che hanno in casa loro, oggi ho visto applicato in produzione il cambiamento che ho apportato (una scemenza, ma ne sono comunque fiero :-D), e a valle di questo processo di contribuzione conclusosi nel migliore dei modi mi sento di fare un po’ di appunti:
- Il triaging delle merge request è lento, ma questo dipende anche dal fatto che ci sono “pochi” addetti, mentre il numero di contributor esterni è abbastanza alto;
- Le contribution guideline indicano come processo ideale quello di fare fork, creare un feature branch, poi chiedere la merge request dal feature branch in master. Secondo me questo non è ottimale, dato che la creazione del feature branch per modifiche di poco conto (come la mia) non inficia la review della richiesta che viene fatta dopo ed è solo uno step in più che appesantisce il workflow;
- Mi è stato chiesto di assicurarmi che la build del mio commit fosse verde. Questo è sacrosanto, viceversa secondo me non è sacrosanto che uno step della pipeline di testing restituisca un esito non deterministico.
Tenendo a mente soprattutto l’ultima pillola e fissandola come un antipattern dell’ambito QA/operations, sono molto contento del risultato.
Daje :-)
E insomma, Jekyll ha cambiato ormai da una mesata a questa parte le proprie regole di contribuzione al progetto. Non ho ancora avuto tempo di farlo ma credo di poter cominciare ad inviare qualche pull request anche solo per risolvere qualche baco minore (per non dire atomico), esattamente come ho fatto con GitLab in settimana.
Il punto più interessante di tutto il nuovo iter mi sembra questo:
Second, this week, we created six community interest groups, we’re calling Jekyll affinity teams. If you’re interested in a particular aspect of the project (or just want to learn more), you can join any one of these teams (or two, or three), to participate in discussions about potential bugs and proposed improvements. And the best part is there’s no commitment. If you just want to listen, or if at any point you want to leave (or switch teams), that’s totally fine. We won’t say a thing. To learn more about the various affinity teams, or to join one (please do!), just head on over to teams.jekyllrb.com.
Penso che uno di questi giorni scriverò un commentario più ampio relativo a queste policy di contribuzione.
Robby Russell ha messo per iscritto tutto quello che gli è successo e tutte le lezioni che ha imparato dal suo progetto più fulgido, ovvero Oh My Zsh.
Don’t try to make it perfect. Worrying how other people are going to react about your code shouldn’t be your biggest concern. Does it work? How do they feel when they’re interacting with it should be a higher concern. In my case, I’ve had some great contributors over the years who have helped tidy up and improve the quality of the code that I originally released.
Rarely has anyone said anything critical about my old code — maybe they should have, though. ;-)
Don’t try to be everything to everyone. There have been a few points in the history of the project where we hit a crossroads. In particular, there was a time when a huge rebuild was proposed, which I was quite excited about until I was able to wrap my head around some of the changes.
Sinceramente, non solo reputo Oh My Zsh un tool must-have per chiunque sia patito della shell, ma reputo anche questo progetto come uno dei più bei casi di studio di cose community-driven di successo, nonché una comunità estremamente accogliente sia nei confronti di questioni tecniche poste da membri esistenti, sia nei confronti di nuovi membri che iniziano a guardarsi intorno e cercano di avviare un processo di contribuzione direttamente al codice, o anche con semplici domande. Provare per credere.
