Mark Solomon, intervistato da SOMA Magazine:
One interesting detail that differentiates the Pebble Time from competitors, for example, is the use of external buttons rather than a touch screen. “If we have a touch screen, what does that bring to the table?” asks Solomon […] With Pebble, simplicity and ease of use are key.
Ho un Pebble da ormai parecchio tempo (un Pebble Time), e nonostante abbia avuto modo di testare parecchie alternative, rimane comunque uno dei migliori oggetti da polso sul mercato.
Vorrei scrivere qualcosa di più approfondito in proposito nelle prossime settimane.
Apple cambia, ancora una volta, nome al suo “sistema operativo migliore di sempre”. Nel frattempo Microsoft porta la Bash (nativa) su Windows 10, insieme a gran parte della userland di Ubuntu.
Se fossi un coatto, scriverei “ciaone”.
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 :-)
