Grab The Blaster
di Alessio Biancalana
Andrea ha ricondiviso una serie di motivazioni decisamente importanti riguardo al mantenere un blog, a prescindere da quante visualizzazioni possa attirare.
Anche per me è la stessa cosa, identica: da una parte è vero che scrivo per diffondere informazioni che reputo rilevanti. Dall’altra, probabilmente comunque lo scopo primario dello scrivere per me rimane una sorta di rifinitura di me stesso.
E dopo dieci anni, lo consiglio ancora.
Nello scorso post, prima di sparire nell’ombra, ho dato notizia che sarei stato a Build, la conferenza annuale di Microsoft in cui si fa una review più o meno di tutte le novità presenti nelle piattaforme del colosso di Redmond. Ci sono andato invitato da loro, e nonostante la cosa mi abbia fatto molto piacere, ho pur sempre mantenuto l’atteggiamento che mi contraddistingue quando si parla dell’interazione tra me e Microsoft, ovvero un approccio onestamente critico e genuinamente (poco, ormai) sospettoso di cui potete osservare una diapositiva qui sotto.
Scherzi a parte, la prima volta che sono stato contattato da Microsoft ero veramente sospettoso, mentre adesso questo sentimento è quasi svanito. Perché? Perché a partire dalla mia visita alla loro sede di Milano nel 2015, dalla quale era uscita una valutazione più che positiva, Microsoft ha mostrato un sincero commitment sull’ecosistema Linux, portando addirittura la Bash e Linux dentro Windows (e anche ZSH, dato come l’hanno fatto), muovendosi con ancora più coraggio incontro a questa nuova strategia che la vede, in prospettiva, quasi la più grande Linux company del mondo.
Una delle cose che ho letto durante la mia permanenza negli States è stata una frase su Twitter:
So uh, I’ll say it:
2017 is finally the year of Linux on the Desktop.
It’s just that the Desktop is Windows.
E questo è vero, indubbiamente. Una delle cose che sono state presentate riguarda proprio questo aspetto, e sinceramente mi ha deluso che il giorno della keynote tutto questo sia stato affrontato solo con qualche frase di circostanza, anche se posso capirlo.
Ma cominciamo un ricapitolo disordinato per vedere cosa ho portato a casa da questo fantastico Build passato insieme ai miei “colleghi” del Technical Advisory Group.
La nostra prima giornata ha visto al suo centro una visita abbastanza approfondita al campus di Redmond, dove a parte le meraviglie da parco divertimenti abbiamo dato un’occhiata al processo attraverso il quale Microsoft lavora sui suoi prossimi prodotti, attraverso delle demo e un giro nel cosiddetto Envisioning Center. Prima di ciò abbiamo avuto anche una panoramica dell’operatività del Cyber Defense Operations Center, dove vengono continuamente individuate nuove minacce e dove presumo che venga fatto anche parecchio del lavoro su Windows Defender.
Il fatto che il giorno dopo per via di macchine non aggiornate il ransomware WannaCry si sia diffuso per mezza Europa diciamo che ha completato la panoramica. In ogni caso, un dettaglio importante che abbiamo avuto è che adesso i ransomware sono la categoria di malware su cui Microsoft punta la sua lente d’ingrandimento più spesso.
La “spicy sauce” di questa giornata, per gradire, è stata il finale a base di demo su Hololens: avevo già usato Hololens in passato, ma ho avuto la possibilità di afferrarne di più le potenzialità.
Il giorno successivo abbiamo avuto la keynote della conferenza, dove Satya Nadella ha tenuto il suo speech ispirazionale, illustrando ovviamente la compagnia ad oggi e soprattutto dando alcuni scorci sul domani:
We need to build trust in computing of the future, making sure we don’t fall in dystopian scenarios like Orwell’s 1984
Sottolineando l’importanza e la responsabilità degli sviluppatori riguardo questo punto, Satya ha stressato molto il fatto che Microsoft è una compagnia nata dopo tutto come una developer tools company, ed è suo dovere quasi morale muoversi in tale senso. A questo proposito, il resto della keynote ha avuto i suoi punti focali principali su Azure, sulla nuova CLI integrata direttamente nel portale web (che è una Bash, e non una CMD, e nemmeno una Powershell! Kudos Microsoft), e su IoT Edge, ovvero la nuova possibilità svelata dai ragazzi per portare sul proprio datacenter locale le potenzialità dello stack Azure, senza dover effettuare trasferimenti di dati inutili tra la cloud e il cosiddetto edge.
In questo senso, Microsoft ha dimostrato di avere le potenzialità per stare sulla cresta dell’onda riguardo il cloud computing, dato che per ora sembra l’unica ad aver messo l’accento in maniera così marcata sulle potenzialità dell’edge e sulla sua interoperabilità con l’ecosistema cloud.
Insieme a questo, mentre la parte Azure è stata curata da Scott Guthrie (naturalmente), Harry Shum ha presentato una serie di novità su Cortana, sul Bot Framework di Azure, e sui Cognitive Services.
Un capitolo a parte lo merita CosmosDB, annunciato sempre nella keynote del primo giorno, ossia un database in cloud multi-model (relazionale, documentale, graph) con possibilità di replicazione multiregione in un click o due. Devo ammettere che da questo sono rimasto positivamente colpito, e vorrei anche realizzare qualche piccola PoC con questo affarino, sempre che le finanze del mio account Azure me lo permettano.
Insieme a CosmosDB, un altro annuncio particolarmente godereccio è stato quello di PostgreSQL e MySQL come DBaaS (DataBase as a Service) su Azure. Sbav.
Mentre il primo giorno abbiamo assisitito a una carrellata di cose su Azure, il secondo giorno è stato all’insegna del futuro, e di quello che Microsoft farà (e cosa permetterà di fare agli sviluppatori) con i suoi prodotti di punta lato consumer: è stato annunciato il nuovo Fall Creators Update per Windows 10, che oltre ad introdurre una nuova interfaccia per molte app che fa uso di un nuovo paradigma chiamato Fluent Design, ovviamente apporterà altri miglioramenti a una parte che a me interessa tantissimo, ovvero il Windows Subsystem for Linux.
E proprio parlando di Windows Subsystem for Linux arriviamo a quello che per me è stato un punto molto importante, ovvero la disponibilità di Bash direttamente dal Windows Store, pacchettizzata insieme alle immagini delle distribuzioni Linux più blasonate: Ubuntu, Fedora, e Suse. Questo significa che WSL esce dalla beta, e diventa utilizzabile a tutti gli effetti, e devo dire che in questi giorni ho avuto occasione di farci più di qualcosa e ormai come esperienza utente non mi ha lasciato davvero nulla da ridire. Sono orgoglioso del lavoro che Microsoft sta facendo per portare la Bash (con tutto l’ecosistema connesso) su Windows, e come utente sono anche soddisfatto.
Insieme a questi, che per me sono punti focali, sono state annunciate un sacco di novità per quanto riguarda Xamarin e lo sviluppo su iOS/Android, insieme a molte cose in arrivo su Hololens (insieme ai Mixed Reality Kit di Acer ed HP).
Lasciando stare la keynote, in realtà una parte succosa è stata quella delle sessioni (tra cui una molto molto carina sullo sviluppo React con Office UI Fabric), e ovviamente la possibilità di incontrare dal vivo un sacco di personaggi, tra cui Ross Gardler di Azure Compute Service e Exec VP di Apache Foundation, nonché mio “capo” per quanto riguarda il Technical Advisory Group.
Ross è veramente un figo! 😁 Abbiamo avuto occasione di parlare a lungo durante i meetup del TAG, e durante l’hackathon che si è tenuto l’ultimo giorno per tirare fuori feedback a cannone sulla piattaforma Azure da dare in pasto ai ragazzi di Microsoft. Ho persino contribuito con un bug report e svariati chilometri di documentazione 👌
Viceversa, parlando di “cool people”, ho avuto il grandissimo piacere e onore di conoscere Chris Heilmann (!) e ho avuto un’oretta di chiacchierata molto interessante allo stand del Bash for Windows development team con Paul Campbell, che mi ha fatto vedere un sacco di trucchetti interessanti.
Una cosa che mi ha colpito molto è che nel subsystem Linux sia stato inserito un eseguibile cmd.exe, che ci permette di eseguire dei trick clamorosi, tipo eseguire un comando di cmd direttamente da dentro la Bash, senza dover cambiare shell. Usando ZSH, quello che proverò a fare tra poco sarà wrappare tutto questo in un plugin.
Per il resto, ci siamo divertiti veramente tanto. È stata una bella occassione sia di parlare con tante persone (tra cui gente del team di Edge, veramente preparata, che mi ha confermato che non ci sarà mai una release per Mac o Linux) che di stringere amicizia con i vari membri del Technical Advisory Group, con alcuni dei quali ho avuto il piacere di rimanere invischiato in piacevoli dibattiti tecnici, e anche culturali. 🤘
Che altro dire: è stata una settimana meravigliosa, e così intensa che riesco a riprendermi solo oggi per poterne scrivere qualcosa. Probabilmente ho tralasciato tante cose, ma il fine di questo wrap up è quello di mettere insieme il vero valore che ha avuto per me la conferenza, ovvero quello di poter venire a contatto con una Microsoft che raramente viene esposta agli occhi degli outsider, ovvero quella che ha come focus principale il portare valore all’ecosistema open source, di cui Microsoft giorno dopo giorno diventa un player sempre più visibile e importante.
Cose da chiedere a Microsoft? Beh, lo rifacciamo l’anno prossimo? 😎
È già da un po’ di tempo che ho il piacere di stringere (metaforicamente dato che è elettronico) tra le mani il biglietto d’ingresso a Microsoft Build 2017, che si terrà a Seattle la settimana prossima. Lunedì ho il mio volo transoceanico e non potrei essere più eccitato così, soprattutto perché sono pieno di aspettative rispetto a quello che vedrò negli Stati Uniti.
Nello specifico, le cose su cui mi voglio concentrare saranno le sessioni di keynote in cui Microsoft condividerà la sua roadmap e le novità che ha in serbo, e ovviamente l’incontro con gli altri membri del programma Technical Advisory Group, di cui faccio parte.
Ovviamente, in particolare, sono interessato al lavoro che sta venendo fatto per portare l’ecosistema Linux su Windows tramite il progetto Windows Subsystem for Linux; già con il Creators Update è possibile fare tantissime cose in più con la Bash integrata dentro Windows, che sin’ora era stata relegata ad uno stadio di preview, quindi mi aspetto che questa settimana me ne facciano vedere delle belle.
Oltre la shell, però, sicuramente andrò a sniffare qualche cosa d’interessante su:
Come compagni di viaggio d’eccezione, uno dal Technical Advisory Group e uno dal mondo del giornalismo, avrò Piergiorgio Lucidi, già mio collega in Sourcesense, grande esperto di information management e gran chitarrista, e Luca Annunziata, nerd come pochi, runner, e barba d’oro per l’estate 2017. 😎
Nel frattempo devo un grazie speciale a Paola Presutto, Andrea Benedetti (se sfonnamo! 😂) e Shelby Woods per aver reso tutto questo possibile. Kudos guys!
Come se tutto questo non dovesse bastare, qui potete trovare la fantastica introduzione in parte tecnica, in parte fatta di sentimenti e amarcord puro scritta da Andrea.
🍹
Stasera tornando a casa ho avuto la “brillante idea” di mettermi a trafficare con il Rakefile che uso per manutenere questo blog e automatizzare ad esempio la creazione dei file markdown o per eseguire una build locale. Mi è capitato di notare una cosa più del solito: il metodo che usa Rake per passare i parametri ai task fa schifo.
Per passare un parametro a un task bisogna scrivere una cosa tipo rake foo[bar], che per quanto possa essere rapido da scrivere non è nemmeno compatibile con ZSH, che si lamenta. L’equivalente che ho usato sempre sino ad oggi è rake "new[post-slug]", che mette a tacere ZSH ma fa ancora più schifo esteticamente. Viceversa guardandomi intorno per un modo più furbo di passare i parametri a Rake, ho scoperto Thor.
Thor è una figata di software che si compone di due pezzi: una libreria per creare delle utility CLI, piccoli programmini a riga di comando che sbrighino dei task arbitrari. L’esempio di base è questo, preso dal sito ufficiale:
require "thor"
class MyCLI < Thor
# contents of the Thor class
end
MyCLI.start(ARGV)
In realtà sfruttando qualche gabola interna documentata in maniera un po’ allegra (ossia: io non ho trovato documentazione su questo, ma ho rubato in giro) possiamo sfruttare Thor come Rake, per scriverci la nostra classe Ruby che faccia da task runner. Per fare un esperimento ho preso il mio Rakefile:
require 'date'
task default: %w[build]
task :run do
sh "jekyll serve"
end
task 'build' do
sh "jekyll build"
end
task :new, [:title] do |t, args|
fn = "_posts/#{Date.today().to_s()}-#{args.title || "slug"}.md"
File.new(fn, "w")
puts("Successfully create file: #{fn}")
end
E l’ho riscritto usando Thor. Ho creato un Thorfile scritto così:
require 'date'
class Default < Thor
desc 'up', 'Serves the blog locally through Jekyll\'s embedded server'
def up
exec("jekyll serve")
end
desc 'build', 'Builds the static site'
def build
exec("jekyll build")
end
desc 'new SLUG', 'Creates a new post with the provided slug'
def new(slug)
filename = "_posts/#{Date.today().to_s()}-#{slug}.md"
File.new(filename, "w")
puts("Created file: #{filename}")
end
end
Ci sono due trick che usiamo, e che sono leggermente sottintesi nella documentazione: un Thorfile viene sempre cercato come predefinito insieme a qualsiasi file .thor, quindi possiamo chiamare il file in questo modo ed evitare di passare un filename a Thor stesso; l’altro trucchetto è che una classe Default non ha bisogno di prefissi per i nomi dei task. In questo modo leviamo di mezzo un bel po’ di complessità rispetto all’uso classico di Thor, che è ben più potente, definendo i task in maniera molto simile a un Rakefile.
Tutto questo con un plus però: ovvero il fatto che possiamo finalmente passare degli argomenti in una maniera normale e umana ai nostri task, e il check automatico degli argomenti da parte di Thor stesso fa sì che non sbagliamo a passare più o meno parametri di quelli necessari, pena degli alert super sexy.
L’effetto è questo:
$ thor new thor-task-runner
Created file: _posts/2017-05-03-thor-task-runner.md
$ thor new
ERROR: "thor new" was called with no arguments
Usage: "thor :new SLUG"
$ thor new top kek
ERROR: "thor new" was called with arguments ["top", "kek"]
Usage: "thor :new SLUG"
Io per stasera ho trovato il giocattolo nuovo, e sono proprio soddisfatto. Come sempre, è bandita la domanda sulla vita sociale, dato che la risposta è come al solito un no secco. Adoro il mio divano. E adoro anche Thor.
Di recente ho iniziato ad essere insoddisfatto degli editor Markdown che uso - o meglio, loro il loro lavoro lo fanno benissimo, sono io che avendo un flusso di lavoro orientato alla riga di comando non riesco a integrarli perfettamente. Ho provato a scrivere qualche plugin di ZSH per dover passare sempre meno dal cursore del mouse e rendere tutto “streamlined”, ma proprio non ci riesco.
Viceversa la cosa che adoro è usare Vim, e stamattina avendo un po’ di tempo a disposizione ho spulciato un po’ l’Internet; greppa che ti rigreppa è uscito questo meraviglioso post che illustra come creare un setup completo per editing di file Markdown con Vim senza troppi sforzi.
I’ve been struggling with the Vim setup I use to write for a while now. For a geek, I have a pretty standard work flow. iTerm is my terminal emulator. Inside that I run tmux. Inside that I run vim. I write my text in Markdown and commit my work to a Git repository. For ages I’ve been using my regular coding setup with a few hacks to the ftplugin for Markdown. It worked but it didn’t work well. I’ve since decided that it’s time to set about fixing it.
E con questo, diciamo addio a Byword e Typora, dato che almeno per il momento posso definirmi soddisfatto.