07 Oct 2016
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
02 Oct 2016
È 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. ;-)
20 Sep 2016
Se penso all’utilizzo che faccio oggi del computer, rispetto a quello che ne facevo ieri, mi metto quasi a ridere. Viceversa, se penso all’utilizzo che ho provato a fare alcune volte del mio tablet, rischiando l’incaprettamento delle dita, mi viene da piangere.
È così, e non possiamo farci niente: per quanto abbiano provato ad inculcarci il concetto secondo cui possiamo fare moltissime più cose dal tablet, dallo smartphone, e chi più ne ha più ne metta, la verità dei fatti è che c’è sempre e ci sarà sempre qualcun altro che non riuscirà minimamente a usare tali strumenti come dei supporti adeguati al lavoro che fa.
Fruizione / Creazione
Purtroppo quello che viene fuori dall’esperienza d’uso di un dispositivo di questi con cui si è tanto spippolato negli ultimi anni è che per quanto potente, è adatto solo alla fruizione di contenuti. La creazione di contenuti che non siano dei meme o delle cose simili è estremamente complicata con questi attrezzi, per cui in realtà molte persone hanno abbandonato progressivamente la voglia di impegnarsi in qualcosa di più profondo (un blog?) per passare a qualcosa di decisamente più temporaneo, effimero, senza sforzo, come un post su Facebook o su Twitter. Figuriamoci quando si passa al montaggio video, al rendering 3D, cose di cui un hardware del genere non è nemmeno capace.
Il sacro monolite
Alla fine il computer desktop tradizionale non è diventato solo uno strumento professionale, ma questi marchingegni così usabili, così lisci, così perfetti, così maneggevoli, hanno contribuito in un certo senso ad aumentare l’aura mistica che circonda l’attrezzatura che normalmente utilizza un “utente normale del PC”. E allo stesso tempo, se vogliamo, ci si è resi piano piano conto che nessun form factor va bene per fare qualsiasi cosa, tranne uno: il personal computer, che così ingombrante rispetto a un tablet, ma versatile come ognuno dei nostri strumenti elettronici combinati, è comunque indispensabile per chiunque decida di fare qualcosa di più che postare su Facebook.
Credits
Questo post è scaturito da una riflessione stimolata da @Linuxbird per la #PinguiniMarciChallenge. Ed esattamente come voleva lui, non è stato pensato, non è stato “scalettato”, non è stato nemmeno (quasi) riletto.
:-)
11 Sep 2016
Era già da un po’ che volevo iniziare a scrivere questo post, ma per impegni personali ho sempre rimandato. E ho rimandato anche quello precedente, il che è divertente: avevo infatti intenzione (e non l’ho fatto!) di scrivere, da agosto scorso, di come io sia tornato a casa, e abbia distrutto tutte le partizioni del disco rigido del mio PC fisso per tornare ad installare, dopo parecchio tempo, Arch Linux.
Back to Arch
Alla fine, renderò quel post un piccolo paragrafo di questo. Tornare su Arch Linux è, nell’ultimo anno, probabilmente la cosa più sensata che io abbia fatto con le mie macchine. Sul laptop per motivi di autonomia e assenza di voglia di sbattimento continuo ad avere macOS, viceversa sul fisso non solo ho sbragato tutto ciò che c’era di preesistente per ripartire con un ambiente pulito, ma stufo di tutti i problemini e gli impuntamenti che le altre distribuzioni mi avevano riservato (frustrandomi) ho deciso di provare a calcare la strada che una volta mi era stata più congeniale, per scoprire che è ancora il mio percorso preferito.
Forse su questo avrò da dire di più in seguito.
Ho scritto pacnews.
Ma soprattutto, ho installato GNOME Shell, la scorsa settimana, per prendermi una pausa di riflessione da KDE; ed il risultato è stato totalmente inaspettato.
Il setup
Per l’occasione, ho deciso di avvalermi di un assistente d’eccezione: così mentre il package manager sbrigava il lavoro sporco ho chiamato Gianguido, che la scena GNOME negli ultimi tempi l’ha seguita molto più di me, e gli ho chiesto consiglio.
$ sudo pacman -Rcs kde
$ sudo pacman -S gnome gnome-extra
Con i comandi di rito ho avuto un setup abbastanza pulito di GNOME sulla mia macchina. Quello che però non sono ancora riuscito a digerire della nuova GUI, purtroppo, è il tema di default che gli sviluppatori hanno deciso di disegnare ed adottare: se infatti dall’esterno può apparire anche gradevole, personalmente non lo trovo molto bello, anche se devo giudicarlo molto funzionale. Essendo stato consigliato da Gianguido riguardo l’installare un tema dato che nel tempo c’è stata una proliferazione discreta, ho optato per sostituire il secolare (ormai) Adwaita con un più ammiccante Arc, sia per quanto riguarda la GUI delle applicazioni, sia per quanto riguarda GNOME Shell.
Estensioni
Già che c’ero, mi sono fatto consigliare qualche estensione per rendere ancora più personalizzata la mia esperienza. Dato che ormai avevo sostituito il tema di default (e non volevo rinunciare a una dock) potevo anche andare all-in con le customizzazioni no?
Attualmente sono arrivato ad avere questo pool di estensioni attivo:
- User themes, per attivare il tema personalizzato Arc per la Shell;
- Dash to dock, per la dock: devo dire che svolge meravigliosamente il suo compito anche se va un po’ configurata;
- Impatience, che è un simpatico trick per configurare la durata delle animazioni della Shell, dato che le performance non mi hanno convinto del tutto anche se di questo parleremo poi.
Sinceramente, il lato performance mi sembra il più grosso caveat di GNOME. Sinceramente credo di aver ritrovato un po’ di pace interiore con questa impostazione attuale (estensioni incluse), quindi sono portato a comparare il tutto al mio vecchio desktop GNOME di anni fa, preso da una memoria lasciata al volo su Facebook:
(Poi dicono che questi social media ci fanno male)
In quanto a performance secondo me il mio ambiente attuale non è paragonabile all’ambiente di cui ho nostalgia, basato su GNOME e Compiz. Trovo però che sia un buon compromesso rispetto all’offerta attuale dei desktop Linux, che trovo funzionale ma poco prestante rispetto alle soluzioni offerte dalla concorrenza.
La cosa secondo me più grave è che per raggiungere qualcosa di decente io abbia non solo dovuto installare un’estensione per far durare meno le animazioni di Mutter (che io, per inciso, trovo esageratamente lente), ma abbia anche dovuto applicare una configurazione particolare al mio driver video che a quanto pare non era abilitata, e senza la quale, detto senza peli sulla lingua, GNOME non gira molto bene.
A lato, va detto che secondo me Mutter e la Shell hanno qualche problema con la memoria, nel senso che ne allocano molta, ne consumano parecchia, e soprattutto la Shell va riavviata dopo qualche giorno di utilizzo continuo altrimenti comincia a soffrire di un po’ di micro-lag.
Applicazioni e user experience
Nonostante l’aspetto relativo alle performance non stia proprio brillando in casa GNOME, e nonostante io venga comunque da un’esperienza Plasma 5 che al contrario è velocissimo in ogni animazione e ogni azione, sono molto soddisfatto dell’uso del desktop nel quotidiano. Le applicazioni si fanno usare volentieri, e non sento nessun tipo di mancanza in confronto ad ambienti desktop molto più blasonati come quello di macOS.
Addirittura, ho cominciato a fare qualche ricerchina per applicazioni che usino tutte le nuove feature delle GTK3, e se ne cominciano a trovare parecchie.
Una cosa che mi ha lasciato stupefatto è quanto Nautilus e l’handling dei file in tutto l’ambiente sia rimasto al top: nonostante qualche funzionalità in meno rispetto al passato (e infatti tempo addietro usavo Nauilus ricompilato con il patchset dell’Elementary Project), il file manager rimane una delle applicazioni più curate. Al contrario di KDE, è possibile trascinare i file da un posto all’altro (tipo, ehm, il browser) senza incorrere in side effect inaspettati. Immagino che questo sia comunque un merito dell’ambiente nel complesso (quindi di file manager, gestore finestre et al.), più che un merito del singolo programma.
L’effetto di preview delle finestre nel workspace, nonostante da queste parti sia ad utilizzo notevolmente ridotto a causa della dock, è comunque abbastanza piacevole e non mi dà così tanta noia come me ne dava i primi tempi in cui provai GNOME. Probabilmente il fattore abitudine influisce tanto su queste scelte e questi “sentimenti”, e devo dire che se ho avuto qualche difficoltà ad adattarmi a GNOME nel tempo è stato anche perché l’aggiornamento improvviso sulle distribuzioni Linux che uso di più mi ha fatto sentire un “homeless di GNOME 2” più di quanto io sia abituato a credere.
La cosa che mi fa storcere il naso di più, in ogni caso, è come il setup di default non soddisfi il mio gusto personale e come sono abituato a lavorare; il fatto che gli sviluppatori di GNOME cerchino addirittura di osteggiare le personalizzazioni è persino più grave. Però nonostante questo comincio ad affezionarmi.
Impressioni finali
Dopo qualche settimana di uso costante di GNOME, posso dire “viva GNOME!” seppur con qualche riserva. Esattamente come KDE va fatto del fine tuning per far funzionare tutto in modo che possa usarlo un essere umano normale. Le applicazioni sono belle, il desktop fa quello che dovrebbe fare e fa quello che ci si aspetta che un ambiente desktop debba fare. È sicuramente meno scarno di altri miei setup passati, e credo che rimarrà comunque il mio desktop environment per moltissimo tempo, dato che è esattamente quello che volevo.
02 Sep 2016
Stamattina ho avuto un’illuminazione da toilette. Dicesi illuminazione da toilette quel momento chiarificatore di ogni cosa, che accade generalmente la mattina tra quando prendi il caffè e quando ti vesti. Ossia quando sei (circa) seduto sul tuo augusto trono casalingo ad espletare le funzioni corporali di un essere umano medio.
Erano mesi che ragionavo su una tematica particolare: questo blog ha sempre usato un hosting esterno per le immagini; come posso fare a portarmele dentro casa, o comunque su una piattaforma dove io abbia un controllo decisamente maggiore? Così ho analizzato varie soluzioni:
- Amazon S3
- Minio
- Apache/nginx e un FTP custom
- Un servizio di image hosting anche a pagamento
Mi è passata circa immediatamente la voglia di fare un censimento di ogni roba simile che ci fosse sull’internet. S3 l’ho escluso perché costa un pacco di soldi. Minio non fa esattamente quello che volevo io, e per concludere, beh, anche Apache o nginx non hanno decisamente la comodità di offrirmi un’interfaccia caruccia per fare queste cose.
Viceversa stamattina, l’illuminazione. Sono andato al computer, ancora con tutto lo sventramento di C aperto dalla sera prima, e ho fatto questo:
Vedrò di gestire le immagini (d’ora in poi) tramite Git, e un repository pubblico su Gitlab creato per l’occasione. Mi sono detto che essendo un fan di Git così assiduo (diamine, persino questo blog è basato su Git), forse ha senso provare ad approfittare un po’ di quello che offre Gitlab.
Vi faremo sapere. :-D
