04 Aug 2017
Proprio oggi ho letto su OMGUbuntu che Ubuntu 17.10 non solo utilizzerà GNOME Shell, cosa di cui già si sapeva da tempo e che a me fa solo piacere, ma che oltretutto l’ambiente desktop di Canonical sarà corredato da una dock basata sulla celeberrima Dash To Dock per GNOME, ma non identica.
Questa secondo me è una grandissima opportunità per GNOME; sicuramente gli utenti Ubuntu avranno qualcosa a cui sono stati sempre abituati – e sinceramente io sui miei desktop ho cercato sempre un’esperienza di quel tipo, con dock e tutto il resto – mentre dall’altro lato gli sviluppatori sia di GNOME che dell’estensione più amata dagli “gnomisti” avranno qualcuno che gli fornisca degli spunti alternativi.
La cosa che mi fa più piacere insomma non è che Ubuntu torni ad adottare GNOME come desktop environment, ma che ci sia una ventata di novità nel panorama Linux desktop grazie a questo, e che ci possa essere un graditissimo (si spera) spunto esterno per rendere GNOME “great again”.
30 Jul 2017
Andrea Contino ha scritto proprio l’altro ieri di Twitter e della sua situazione, secondo lui pericolante ma non troppo. È vero quello che ha detto anche lui, ossia che Twitter ancora adesso è capace di guadagnare utenza, però secondo me l’“ultimo cinguettio” non è che sia molto lontano.
Ci sono svariati fatti da prendere in considerazione, tra cui il fatto che le revenue in pubblicità sono calate, ed alcune sedi nazionali sono state chiuse; Andrea ha messo questi fatti in correlazione uno dietro l’altro, a me viceversa piace vederli in maniera inversa, ossia insinuare che alcune sedi nazionali siano state chiuse proprio per via del calo dei ricavi, il che potrebbe porre Twitter in una situazione molto più “short money” del previsto.
Messa a fuoco la situazione di crisi, comunque per me rimane una delle piattaforme social preferite, e devo sinceramente dire che fatico a vedere un mondo senza Twitter, dato che ormai i giornalisti lo usano come fonte principale di dichiarazioni, e molti personaggi pubblici foraggiano questo sistema, preferendo evitare le classiche pagine Facebook che pure possono assolvere allo stesso compito.
È innegabile che Facebook ormai abbia vinto la battaglia sul numero di utenti. Riuscirà Twitter a stare a galla in quella per le nicchie?
Sotto preziosissimo consiglio di Andrea oggi ho letto questo post meraviglioso sulle emoji nel prompt della shell, che viene concluso tramite un paragrafo con cui mi ritrovo molto:
If you just want to be a developer, sure, go ahead, skip the little things. But I think most of us also want to be a Human Being, and that involves more than code. If my experience shows me anything, it’s that the best code comes from those who take the time to be a well-rounded person, and who find ways to make themselves happy throughout the day. To mangle a line from Mary Poppins, “A spoonful of sugar helps the developer stay sane.”
And that’s why, sometimes, I spend too long playing with something ridiculous, like emojifying my prompt. I do more than that to keep myself happy, but these little things can help keep the happy going throughout the occasional long day. Find the dumb things that work for you, and do them.
Fare cose stupide è la cosa più bella al mondo, e a latere è anche il motivo per cui è nato uno dei miei migliori progetti didattici.
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.
