Proprio oggi sono incappato in questa bellissima notizia che considero una boccata di aria fresca nel panorama server in cui si vedevano sempre le stesse cose. Nello specifico server tradizionali, al massimo un po’ più minuti, da una parte, e l’ascesa di Kubernetes & co. dall’altra.
Boltron is a bit of an anomaly in the Fedora world — somewhere between a Spin and a preview for the future of Fedora Server Edition.
E ancora, per quanto riguarda la sfida tecnica:
The first aspect deals with the problem of installing multiple versions of something in the same user space. […] Early on, the Modularity WG decided not to focus on solving this problem yet again. Rather, they promoted and encouraged OCI containers, System Containers, and Flatpaks to address the different use cases in this space.
Devo dire che tutto questo mi incuriosisce un bel po’. Penso che mi darò da fare con Boltron molto presto, probabilmente in una macchina virtuale per testare un po’ cosa hanno fatto i ragazzi di Fedora.
E sospetto che mi piacerà.
24 Jul 2017
Di recente ho letto un post su come evitare di far diventare le applicazioni mobile che sviluppiamo dei mega blob. È stato veramente interessante, anche se non sviluppo mobile; una cosa però ha particolarmente attirato la mia attenzione:
Say an engineer wants to move up the tech ladder. Shipping features won’t get you a promotion. Building a new layout engine does. The company even gets recruiting-bait for the engineering blog.
The only solution is senior leadership declaring, “We are going to slim down our app.” Unfortunately, tech CEOs don’t use iPhones with 8 gigs of storage, and they don’t live in areas with shoddy speeds.
Questo snippet proviene dalla conclusione di “One Weird Trick to Lose Size”. Mi ha veramente colpito non appena l’ho letto. Perché? Ma per via del mio passato da consulente, ovviamente.
Tradeoff
Quando ancora ero un giovane freelance imberbe puntavo a fare le cose al meglio (almeno secondo me), con uno standard che col tempo ho imparato a riconoscere come piuttosto alto. I miei software hanno sempre avuto una certa raison d’être, risolvevano problemi che generalmente o aveva il mio cliente, o avevo io. Niente di più, niente di meno. E i setup dei sistemi operativi più o meno seguivano lo stesso principio: straight to the point.
Col tempo ho imparato che non funziona così nella maggior parte dei casi: la sovringegnerizzazione prende il sopravvento, insieme al boilerplate code, quando poi lavori con altre persone che non hanno la stessa lista di priorità che hai tu. Ecco che dunque sei costretto a tralasciare pezzi di applicativo per dedicarti ad altro, ad accroccare soluzioni che stanno in piedi alla bell’e meglio solo perché “dopodomani il cliente vuole che gli diamo qualcosa da provare”, lasci stare i test perché nell’immediato non servono e “non ci pagano per questo”.
Lasciando il ventre di vacca della vita da freelance solitario per divenire un membro di un branco ho imparato cose meravigliose, ho conosciuto persone altrettanto spettacolari e sono venuto a contatto anche con queste schifezze. Luci e ombre. Quando era il momento di produrre debito tecnico, buttare fuori codice di cui non eravamo fieri, mettere in piedi un server senza configuration management, in tutti questi casi ho potuto osservare un fattore, che è poi ciò che produce da una parte frustrazione mentre dall’altra: una grandissima diseguaglianza di obiettivi tra lo sviluppatore (voglio fare il miglior prodotto possibile) e il management (voglio il prodotto il più in fretta possibile).
Questo ci fa vivere male il nostro lavoro e, soprattutto, genera dei side effect. Un esempio sono le cose che non funzionano come dovrebbero quando escono dagli ambienti di demo. Purtroppo mi sono accorto che questa condizione è data dalla mancanza di obiettivi comuni e dalla assoluta disparità tra le figure coinvolte nel portare avanti un progetto.
Lateralmente, è anche il motivo per cui le metodologie agili in Italia attecchiscono così poco senza essere snaturate e trasformate in dei waterfall ad alta frequenza: invece di focalizzarsi su MVP ed utenti, alla fine si vuole solo risparmiare tempo su tempo attraverso il micromanagement, cosa che i programmatori digeriscono male. Motivo per cui focalizzarsi sul proprio utente risulta essere un buon tradeoff.
Quello che dico io, quando lo dico io
La necessità di trovare un tradeoff deriva dal fatto che nell’economia del software attuale, quando non abbiamo la fortuna di essere inseriti in delle aziende che abbiano una coscienza seria di cosa sia il loro reparto IT, esistiamo come specialisti per far fare carriera al nostro capo (o al nostro committente). E il nostro committente non farà strada se facciamo cose come snellire il bundle della nostra applicazione. Esso beneficerà, e noi assieme a lui, di un continuo rollout di feature, perfettamente inutili, con delle tempistiche assolutamente fuori dal mondo. Tutto questo, per giunta, a dei ritmi che usualmente non sono niente di sopportabile a lungo termine.
Inutile dire che rispetto a questa piaga globale (dopo la website obesity crisis, possiamo parlare di generica application obesity crisis?) l’Italia non consente nemmeno una buona frequenza di turnover, con l’economia del lavoro IT abbastanza al lumicino, il che servirebbe da deterrente per chi costringe i sottoposti a lavorare, perdonatemi il termine, di merda.
Questo non vale solo per le piccole aziende: di recente ho avuto occasione di confrontarmi con alcune grandi realtà alle quali ho avuto il piacere di dire “guardate ragazzi, ci vediamo un’altra volta eh”, proprio in virtù di questo. Per fortuna ultimamente ho trovato un po’ di pace: saluto con molto affetto il mio teamleader Riccardo, la quale è l’unica persona che in vita mia mi abbia inserito dei task di studio nel backlog dello sprint.
Purtroppo quella a cui mi riferisco è una situazione che sembra non solo italica, ma mondiale. Non si riconosce mai alla riduzione del debito tecnico il peso che merita, tantomeno ai benefici per l’utente (shocking!), e purtroppo questo induce degli errori microscopici se presi uno ad uno, macroscopici se presi insieme, da parte anche di team di sviluppo rodati sottoposti purtroppo alla tortura sempre più ricorrente dello “shit it fast, ship it buggy” – e non solo: spesso vengono partoriti mostri, ai quali è stata data un’impronta originale dai developer, obbligati poi a cambiare direzione (senza ovviamente avere il tempo per rinnegare eventualmente scelte tecniche vincolanti) da un management fermo nelle decisioni quanto un polso nervoso.
Tutto questo flusso di coscienza per dire che si, purtroppo soffriamo di una disparità di mire personali tra development e management che spesso produce il contrario di quello che gli utenti vorrebbero da noi. E questo non è nemmeno detto che faccia schifo a tutti.
Ho un’opinione pessima di Rails. Viceversa, Ruby con tutti i suoi difetti è un linguaggio che mi permette di fare un sacco di cose (e poi devo usarlo perché se lo porta appresso Jekyll).
Diciamo che nel tempo tra scrivere Burst e altri piccoli softwarini di commodity ho apprezzato comunque parecchio di Ruby senza mai toccare Rails manco con un bastone, e quando poi ho dovuto sono rimasto veramente impressionato dalla quantità esagerata di gente che lo usa rispetto ai macelli che permette di fare non appena la codebase cresce di un pelo.
Oggi ho scoperto che i giapponesi la pensano circa come me. Oggi sono una persona felice.
La prima volta che mi sono trovato di fronte a uno switch massiccio a Python 3, è stato con Arch Linux dove mantenevo pacchetti per la community, e in quel momento scoprii di mantenere un sacco di roba in Python. Altrettanto velocemente, imparai a lanciare un mega-sed per cambiare lo shabang di un sacco di roba nei miei PKGBUILD in modo da garantire la retrocompatibilità.
In questi giorni invece mi è capitato sotto mano (smaltendo la roba che avevo in arretrato da leggere) questo interessantissimo articolo che racconta lo switch a Python 3, recente, di Instagram.
La cosa che mi ha colpito più di tutte è stata soprattutto lo stop sui pacchetti, che rappresenta una fetta rilevante del lavoro da fare, soprattutto in caso di un cambiamento di ecosistema così rilevante come Python.
First, the team undertook massive code modification. This took two to three months, and included replacing incompatible third-party packages with ones supporting Python 3 — the working rule was, “No Python 3, no new package” — and also deleting unused packages.
Deliziosi casi di studio da portare al vostro capo che desidera ardentemente che voi sforniate feature a rotta di collo. O no?
