Alessio Biancalana Grab The Blaster di Alessio Biancalana

Cosa c'è dopo il Mac

Macbook

In questi giorni mi sono astenuto dal commentare il nuovo Macbook presentato da Apple, in parte perché non ho avuto tempo, in parte per formarmi un’opinione tutta mia che sostanzialmente, ora, in fondo alla corsa, si riduce a questi punti fondamentali:

  • Il nuovo colore Space Gray per il Macbook è la cosa che mi fa considerare l’acquisto di un nuovo modello;
  • La touchbar è una cosa che per quanto utile, a me non serve;
  • La rimozione del tasto Esc fisico è tamponata con la touchbar, ma ad un utilizzatore compulsivo di Vim come me questa sembra un’eresia;
  • L’hardware all’interno è roba assolutamente non all’altezza di un ultrabook killer;
  • L’unica novità di Sierra, l’ultima release di macOS, è Siri, di cui a me importa ben poco, e a quanto vedo pure agli altri.

Mentre vari fattori contribuivano a formare questo groviglio di sentimenti dentro di me, ho letto vari feedback in merito a questo, che consiglio:

Insomma, tanto per riprendere la frase finale del post di Tim Bray:

My best bet is to buy a fu­ture Mac that’s aimed at peo­ple like me. Which re­quires that Ap­ple wants to build one; they don’t at the mo­men­t, but maybe they will again be­fore this box I’m typ­ing on runs out of gas. But some of the com­bos above don’t sound ter­ri­ble.

Probabilmente non solo per me, che non sono mai stato un grosso affezionato, ma anche per molti altri è tempo di cominciare a pensare a cosa c’è dopo il Mac, dato che quell’aura di potenza senza compromessi comincia a evaporare come la neve al sole. Un tempo possedere un Mac significava avere accesso a un ecosistema Unix vasto, flessibile, senza rinunciare alla comodità di un sistema operativo orientato all’utente finale, ottimizzato per task multimediali, con una bella interfaccia grafica.

Di tutto questo è rimasta solo l’interfaccia grafica, dato che l’ottimizzazione del sistema operativo è andata a donnine col tempo, e l’ecosistema Unix ormai tra Linux che lo offre nativamente e Windows 10 che lo offre tramite subsystem dedicato comincia ad essere una caratteristica che spacciata come inarrivabile pregio sembra quasi naìf.

Nel frattempo i competitor stanno ridefinendo i traguardi a cui puntare, e stanno ormai sorpassando a tutta manetta quelli che Apple vede ancora come tali. Basta guardare come funziona GNOME Shell sul mio computer fisso, o come Microsoft sia riuscita a sfornare un prodotto clamoroso con un consenso globale con il suo ultimo Surface Studio.

Insomma, oltre il confine tracciato dal Mac sembra esserci una terra fatta di meravigliose novità. E forse il fatto che Apple stessa per questo nuovo Macbook abbia spento la mela sempre accesa sul lid del blasonatissimo portatile, è metaforico di un destino in calo.

FreeBSD 11: uno sguardo da vicino

Unix command line

Circa un mese fa, ho deciso di migrare le macchine di una API abbastanza famosa (che ho scritto io, e il cui sorgente è disponibile su GitHub) da Linux a qualcosa di diverso. Tanto per continuare a studiare, ho scelto FreeBSD come sistema operativo di base, e mi sono veramente stupito di quanto sia ben ingegnerizzata l’alternativa a Linux che io stesso avevo sempre sottovalutato.

FreeBSD 11: novità (?)

A dire il vero le novità di questa FreeBSD 11 non sono poi molte: c’è un sacco di carne al fuoco per ZFS, il cui supporto nativo è stato aumentato lungo tutta la catena di utility del sistema come bsdinstall e sade. Per il resto, la cosa che risalta di più olte i soliti bugfix al kernel è chiaramente l’aggiornamento di tutto il parco software, dei port e dei pacchetti.

L’aggiornamento per me che venivo da FreeBSD 10.3 è stato veramente rapido e indolore: qualche colpo di freebsd-update e un giro di pkg hanno fatto avanzare di versione le mie macchine senza che io dovessi fare letteralmente niente. Una volta fatto un piccolo test in laboratorio ho lanciato tutti i comandi in sequenza e olé. La cosa stupefacente (circa) è che durante tutta la procedura le applicazioni funzionano a meraviglia, anche durante gli step intermedi, per via della separazione che avviene tra software applicativo e software di sistema effettuata a monte.

Sistema di base, port e pacchetti

Pur conoscendo un minimo la struttura del sistema operativo, dover usare BSD per il deploy di un servizio REST mi ha permesso di apprezzare e - letteralmente - di farmi innamorare dell’architettura di sistema, che mette a disposizione tre elementi fondamentali: il sistema operativo di base, formato dal kernel e da tutta la userland (quindi i comandi di base, come cp, ls e così via), un sistema di package management che non fa né più né meno di quello che deve, ossia gestire bene i pacchetti scaricabili da un repository, e un gestore di port, che sono tutti quegli script il cui formato ha avuto un successo stellare (basti considerare i PKGBUILD di Arch Linux o gli Slackbuild di Slackware, ma anche gli ebuild di Gentoo), che permettono con un singolo comando di scaricare i sorgenti di un software, compilarli e installare il risultato sul sistema tenendone traccia insieme a tutte le dipendenze.

Questo fa si da un lato che ogni cosa funzioni in maniera molto più isolata, dato che di massima i software continuano a funzionare anche nonostante degli aggiornamenti al layer di base sottostante; nel frattempo, il tutto dà un feeling di massima integrazione al sistema, dato che il tutto viene considerato come un unico prodotto, un unico grande artefatto, e di conseguenza installato, manutenuto e aggiornato come tale.

È espresso in maniera molto, molto chiara quindi il fatto che al di fuori della codebase di BSD, il resto sia proprio “il resto”, ossia pacchetti che si vanno a innestare in cima a una struttura che li accoglie e permette ai software l’esecuzione.

Insomma, anche troppe parole per dire: mi è piaciuta veramente tanto l’architettura del sistema.

Solidità e sicurezza

4.4BSD è un sistema che ha gli anni che ha. FreeBSD stesso è un sistema operativo che, per quanto possa reggere botta in maniera impressionante come abbiamo visto, ha gli anni che ha. Per la precisione ventitré. Nonostante questo, il sistema è robusto e dà ancora oggi la stessa sensazione che all’epoca aveva avuto Daniel Robbins:

Molte delle differenze tra Linux e FreeBSD provengono dalle diverse strutture di sviluppo che li caratterizzano. Lo sviluppo di Linux è molto decentralizzato, e ci affidiamo alle distribuzioni per mettere insieme ed unire i vari pezzi di Linux sparsi per Internet. Confrontate ciò con FreeBSD e gli altri BSD (OpenBSD e NetBSD), dove c’è un team di sviluppo unificato che lavora su di un unico insieme di sorgenti. Bene, ogni BSD ha il suo unico insieme di sorgenti unificati. Questa può essere una cosa positiva ed ha come conseguenza che FreeBSD non ha quel feeling di “messo insieme con le patch” come molte delle distribuzioni Linux.

Successivamente, possiamo confrontare la tecnologia che sta sotto il cofano. Molti dei fan di FreeBSD sosterranno che FreeBSD è predisposto meglio di Linux per essere un server. Vi diranno che FreeBSD è meglio se sottoposto a carichi pesanti e che ha uno stack TCP/IP migliore. Se confrontate Linux 2.2 o precedente con FreeBSD, devo ritenermi d’accordo.

Per quanto Linux abbia integrato dei software di grandissimo valore nel tempo, e possa essere vera anche la seconda parte di quello che Robbins scriveva al tempo della fondazione di Gentoo…

Mi è capitato di essere un grande fan dei kernel di test della serie 2.4 che ho utilizzato. Sono veramente fantastici e contengono un buon stack TCP/IP ed un sistema “netfilter” totalmente riprogettato che è veramente esplosivo. In conclusione, penso che Linux sarà il sistema operativo che definirà nuovi standard di performance e che renderà i server Unix liberi persino più competitivi contro le loro controparti commerciali.

… è altrettanto vero che per quella che è la mia prospettiva alcune scelte compiute all’interno di questo ecosistema (quello Linux) hanno portato una regressione a livello di performance e architetturale, oltre a lasciare Linux a girare attorno a sé stesso senza prendere una direzione del tutto innovativa, che è ciò che mi aspetto da un sistema operativo del genere. Queste regressioni hanno portato addirittura alternative un tempo ritenute molto meno rilevanti a poter trattare alla pari con Linux, se non persino superarlo. Tra i BSD, trovo che OpenBSD ricopra benissimo questo ruolo.

E questo ruolo è ricoperto con eccellenza grazie anche a pf, il firewall di OpenBSD presente anche in FreeBSD, uno dei cavalli di battaglia della scuola BSD VS Linux, ed effettivamente un grande alleato di chi si occupa di security.

Ending theme

Insomma, questo weekend mi sono divertito un sacco con FreeBSD e con i BSD in generale. A breve mi sono ripromesso di cominciare a pistolare con OpenBSD, dato che molti amici (nerdoni) autorevoli tra cui Gianguido e Roberto mi hanno consigliato di farci un giro.

Photo courtesy of lolwho

First – ovvero Google, i Nexus e il bue che dice cornuto all'asino

Ho sempre creduto nell’operato di Google, non tanto in quanto realtà industriale ma in quanto coacervo di progetti innovativi.

John Gruber, sul suo Daring Fireball:

Google then-VP of engineering Vic Gundotra devoted his 2010 I/O keynote to ripping into the iPhone and iPad, pedal to the metal on “open beats closed” and how an ecosystem of over 60 different Android devices (a drop in the pond compared to today) was winning, saving the world from a future where “one man, one company, one device” controls mobile.

Purtroppo, l’unico desiderio di Google sembra ormai quello non di fornire una soluzione il più possibile aperta a quelle che sono le necessità degli utenti, rendendo oltretutto la cosa profittevole, ma semplicemente sostituire a quello che addita come cattivo un altro cattivo, ossia sé stessa.

Questi ultimi Nexus non mi hanno convinto nemmeno un po’, è vero. Ma a convincermi ancora meno è una strategia in cui non mi vedo più preso di mira in quanto “smanettone”, mentre vedo prese di mira categorie di cosumatori a cui Google non ha da dare niente, i quali non hanno la minima voglia di cambiare. E forse, se queste sono le carte sul tavolo, fanno pure bene.

La cosa giusta

Minified Javascript

Nell’ultimo periodo, ho iniziato a rivedere alcune idee che mi ero fatto riguardo un’applicazione da scrivere nel tempo libero per testare alcune tecnologie sul campo. Quello che ho iniziato a scrivere era un banalissimo pastebin, dato che in azienda non avevamo un’istanza di un software del genere, e ho pensato che ci potesse fare comodo.

All’inizio volevo mettere in piedi un backend di API REST, composto di microservizi, con un frontend impostato con VueJS che fosse una single page app. Per un pastebin però è troppa roba. Pur avendo pistolato con un’implementazione del backend primitiva e con un frontendino basato su Materialize, ho iniziato a pensare di “buttare” (non è la parola adatta) tutto e scrivere dei template server-side.

Quello che mi ha sorpreso, è stato leggere in questi giorni una serie di post che mi hanno fatto alzare il sopracciglio. Nell’ordine:

Sto per addentrarmi in una questione squisitamente relativa allo sviluppo web, che mi rendo conto essere una cosa che di riffa o di raffa non ho mai trattato ad un livello così profondamente tecnico su questo blog. Get ready.

We started with a JSON API and a React front end and slowly migrated to server rendered HTML.

Best practice

La cosa che mi ha lasciato impressionato è stata leggere in meno di una settimana svariati articoli, umoristici o meno, che riportavano l’attenzione proprio su questo aspetto: sviluppare la solita single page app con approccio REST e tutto il rest-o (hahah), è veramente considerabile come una sorta di dogma? Ovviamente no. Pare che invece, affrontata nel modo inverso (ovvero, posso non scrivere una SPA?), la questione appaia drammatica. Se non usi React non sei nessuno. Se non hai una single page app da sviluppare non sei nessuno. Se non ti schieri nella faida (perché tale sembra) tra Angular e React, sei irrilevante.

Lo sviluppo web sta subendo sicuramente una svolta in questi anni, ma forse è troppo repentina perché le persone non la subiscano come una sorta di religione emergente, per cui all’interno dei vari user group e delle community ormai si sente parlare in modo ossessivo di nuovi framework che fanno le stesse cose dei vecchi framework, ma cambiando una virgola nei parametri da passare ai costruttori (costruttori? Ho detto costruttori?).

Puoi pronunciare le parole “generiamo HTML server-side” solo se affianco ci infili “il nostro Javascript è isomorfico”. Altrimenti ti inseguono con un forcone.

Ironia a parte, a me pare che ci sia una frazione di persone che al posto di pensare con la propria testa vada appresso alle mode in modo cieco. Questo a volte porta dei risultati, altre volte porta alcuni irresponsabili a fare dei danni non da poco.

Ho scritto un’app MVC e mi è piaciuto

Non c’è nessuna colpa nel seguire un approccio che è ritenuto legacy dalla maggior parte degli sviluppatori “alla moda”. Quando scriviamo un programma, dobbiamo tenere conto di alcuni fattori che non sono solo semplicemente quale approccio, nell’istante in cui apriamo l’editor di testo vuoto, è considerato il più corretto.

  • Quanto debito tecnico abbiamo nei confronti di un approccio più innovativo
  • Che tipo di caratteristiche dobbiamo sviluppare
  • Quanto sarà facile che arrivino contributi complicando eventualmente l’architettura

Sono solo tre delle domande infinite che mi sono trovato ad affrontare progettando un’applicazione da zero. A volte può capitare di dover sacrificare qualche tecnologia molto alla moda perché le persone con cui lavori non la capirebbero mai, perché non hai tempo per studiare e la consegna è tra tre quarti di giornata, o perché semplicemente fare in un certo modo (in quel modo, il modo troppo fico) sarebbe sbagliato (!).

Prendiamo l’esempio del mio stupidissimo pastebin: ha senso immaginare una single-page application con un sistema di rotte per un diamine di affare che prende del testo e lo renderizza un po’ più carino? Decisamente no. Ha senso utilizzare React, invece, per accelerare lo sviluppo di una webapp altamente dinamica? Decisamente si.

Spesso alle persone (e, attenzione, io ricado in questo esempio parecchie volte :-D) piace tirare in mezzo tecnologie e pattern all’ultima moda solo per sperimentare, senza considerare tutti gli aspetti di contorno e l’intento dell’attività che si sta svolgendo.

Ma quindi ti fa schifo React?

No, anzi. Mi sono trovato di recente in una situazione spinosa pur avendo un margine di tempo per studiare. Ero da solo, e improvvisamente mi sono trovato con la richiesta pendente sulla testa di scrivere una webapp che facesse determinate cose. Potendo scegliere cosa tirare in campo per facilitarmi la vita, ho deciso di utilizzare React, e sono ancora vivo nonchè molto soddisfatto.

Tuttavia, il punto della questione è un altro: oggi è il 6 ottobre 2016. Ci sono cose che nel 2016 possono ancora essere impiegate con tantissima efficacia.

JQuery ha ancora da dire la sua nel 2016.

Un’architettura monolitica ha ancora da dire la sua nel 2016.

L’HTML server-side ha ancora da dire la sua (e ne ha ben donde) nel 2016.

E probabilmente, lo sviluppatore più anziano del vostro ufficio ha ancora da dire la sua nel 2016.

Sviluppa responsabilmente

Si, dico proprio a te che stai leggendo. Lo so che ti piace sperimentare. Lo so che è molto più facile ascoltare gli altri in maniera cieca. Ma guarda che stai facendo, stai usando React, che incentiva gli stili inline, quando gli stili inline sono stati demonizzati per anni, insieme al templating schiantato dentro il codice, e insieme a tutta una serie di cose che React fa e ti costringe a fare.

Quando sei davanti a una directory vuota, trepidante nell’attesa di scrivere il primo file del progetto, accendi il cervello, e chiediti quale sia veramente la cosa giusta.

È gratis.

Photo courtesy of ThoroughlyReviewed

There's an app for that

È passato un po’ di tempo dall’ultimo post, perché purtroppo è passato un po’ di tempo dall’ultima volta in cui ho avuto davvero la mente fresca e serena per scrivere con calma. Ho preferito aspettare che questa condizione tornasse da sé senza impormela.

Ma ordunque, tuffiamoci nell’argomento; LinuxBird, in un suo post di cui condivido particolarmente alcuni punti:

Ma poi questo fantomatico mondo delle app esiste davvero? […] Ma ve li ricordate i pipponi della narrazione turbo-ottimista? E il coding, e il mondo delle app che è il futuro, e crea la tua app e diventa milionario, e hackathon di qua, e hackathon di là… Tutta una colossale bolla mediatica.

Ora, non mi soffermo sulla bolla degli hackathon, dato che comunque sono un tipo di eventi che a me piace molto (hackathon inteso come hackathon, quindi come gente che scrive codice in fretta, non altro, beninteso), ma effettivamente l’ecosistema di app merita qualche considerazione tagliente e anche qualche lancia spezzata a suo favore, secondo me.

Infatti, è vero che comunque le persone non usano tantissime applicazioni e per quanto uno possa trovare utile che uno smartphone faccia anche il caffè sicuramente non è che stia tutto il giorno sugli store a spippolare per installare cose, va anche detto che comunque io conosco parecchie persone (professionisti di svariati settori) che hanno più delle cinque applicazioni standard installate sul proprio handset.

Penso che la verità, da questo punto di vista, stia nel mezzo: è vero che non ci dobbiamo aspettare che i nostri terminali contengano più di un tot di applicazioni (a meno di non essere installatori compulsivi di roba a caso), ma in genere qualche app più “specialistica”, particolare, senza dubbio viene installata. Fosse anche solo uno Snapseed, un Aviary per il ritocco di foto, o un giochetto carino, o un gestore di spese.

Rivoluzioni ed involuzioni

Per quanto riguarda la “rivoluzione delle app” tanto acclamata e risoltasi in un nulla di fatto, direi piuttosto di cercare il responsabile nei terminali di fatto poco potenti per fare tante cose che invece vorremmo delegare, appunto, a questi attrezzi. È per questo che usiamo ancora il PC, ed è per questo che secondo me negli anni assisteremo ancora ad evoluzioni inaspettate dell’ecosistema tecnologico che ci circonda, fatto di ciappilli inutili su cui non facciamo altro che fare cippiciappi con le dita, e macchine potentissime che si riducono a Facebook machine da duemila dollari.

È impossibile delegare del calcolo estremo a una CPU che poco ha di dedicato alle operazioni complesse. Quel tipo di CPU (e di interfaccia grafica…) è più adatto alle “cagate”, e l’insieme delle cagate computabili da un hardware del genere, interagibile con un’interfaccia del genere, è piuttosto ridotto.

E l’idea da un milione di dollari?

Non è un problema mettersi a sviluppare adesso qualcosa che possa avere un qualche valore, sia per gli utenti finali che per il nostro portafoglio. Solo che bisogna studiare un po’.

È una sesquipedale stupidaggine che un’applicazione possa sostenersi con un sistema “pay once, get stuff for life”, come qualche tempo fa tutte le applicazioni (soprattutto per iOS) sponsorizzavano. Su Android col tempo si sono andate affermando versioni premium di applicazioni con pubblicità integrata, spesso poco elegante, spesso troppo invasiva. Marco Arment di recente ha cominciato ad affrontare questo discorso con degli approcci interessanti su iOS, sperimentando di fatto un design meno intrusivo per i banner pubblicitari, cosa che ho visto anche in molte applicazioni Android il cui design si è andato affinando col tempo.

Ecco, il modello c’è ed è più o meno questo; quello che manca come sempre è una trovata per far aprire quello che hai fatto alle persone, ma nonostante ormai gran parte delle possibilità sia stata cannibalizzata a dovere, penso che ci siano ancora delle zone d’ombra e delle nicche non soddisfatte (vedasi, appunto, il caso di Arment con Overcast).

Non mi soffermo oltre. Ho del codice da scrivere, per qualche side project :-D

Questo post è dedicato alla #PinguiniMarciChallenge. ;-)