27 Sep 2017
In questo periodo non ho scritto moltissimo sul blog, ed il motivo principale è che oltre al lavoro e a qualche progettino personale, sono stato impegnato con il webserver che avevo da scrivere per il mio esame di Reti di Calcolatori (che è uno dei “perk” dell’essere ancora uno studente di triennale a ventisei anni). Trovandomi a sviluppare su parecchie piattaforme ed essendo il target principale un sistema operativo generico Linux, ho avuto il piccolo problema di sviluppare parte del codice sul mio portatile con macOS: ovviamente non potevo testare bene qualsiasi cosa facessi, e non avevo così tanta voglia di portare a Darwin tutto quello che avevo scritto, quindi mi sono ingegnato per trovare una soluzione nel più breve tempo possibile.
All’inizio ho provato con una macchina virtuale e con qualche server sparso in giro per il mondo. È un buon approccio se uno ha voglia di perder tempo. Viceversa dopo un po’ mi sono detto: “E se provassi con Docker costruendo un container per debuggare?”
Docker to the rescue
Dopo aver dato una scorsa al manuale per togliere la ruggine sulla sintassi dei Dockerfile, ho deciso di creare il mio container per Grocery. Sono partito in realtà da quello definitivo che è veramente piccolino, creando una directory docker all’interno del mio repository e andandoci a scrivere questo file Dockerfile:
FROM alpine:3.6
RUN apk update
RUN apk add --no-cache build-base imagemagick
RUN mkdir /grocery
RUN mkdir /grocery/www
RUN mkdir /grocery/cache
ADD . /grocery
WORKDIR /grocery
RUN make clean release
RUN apk del build-base
VOLUME /grocery/www
CMD ["./grocery", "8080"]
Niente di trascendentale: installo le dipendenze dell’applicazione (che consistono in ImageMagick e pochissimo altro), riempio il container dei file sorgenti, li compilo come se fossi in una fakeroot ed espongo un volume per la directory da cui il webserver dovrà leggere i file. Period. Successivamente, avendo a disposizione un Makefile con vari goal ho inserito quello per fare il build della mia immagine.
...
build_docker:
sudo docker build -t grocery -f docker/Dockerfile .
...
In questo modo attraverso un semplice make build_docker ho potuto costruire ogni volta che ne avevo bisogno un container con una versione “freezata” del programma.
Successivamente, ho visto che non solo questa roba funzionava, ma mi consentiva effettivamente una portabilità del package su qualsiasi sistema operativo senza perdere nulla e senza dover impazzire dietro a cambiamenti infrastrutturali dovuti all’OS che ospita il container. Docker in questo senso essendo un layer di compatibilità ci permette di risparmiare veramente tanto tempo.
Un container per lo sviluppo in C
Dato che il mio container “per la produzione” funzionava, ho deciso di muovermi leggermente oltre, creando un equivalente per lo sviluppo che ad ogni restart prendesse il codice, lo ricompilasse e lo eseguisse senza dover fare repackage. Questo possiamo farlo grazie ai volumi e grazie alle istruzioni per lo start del container.
Ho quindi dotato la directory docker del mio progetto di un file Dockerfile.test, contenente quanto segue:
FROM alpine:3.6
RUN apk update
RUN apk add alpine-sdk imagemagick
RUN mkdir /grocery
WORKDIR /grocery
VOLUME /grocery
EXPOSE 8080
Successivamente ho inserito nel Makefile due goal, uno per costruire l’immagine di test e uno per eseguirla:
...
build_docker_test:
sudo docker build -t grocery_test -f docker/Dockerfile.test .
docker_test:
sudo docker run -d -P -p 8080:8080 --name grtest -v $(shell pwd):/grocery grocery_test \
make debug run
...
Su questo abbiamo un po’ di cose da dire: costruendo il container di test esponiamo un volume, sul quale poi montiamo la nostra directory con i sorgenti. Subito dopo possiamo tramite un make docker_test inizializzare un container che prenda la nostra directory corrente, la monti come volume, e ricompili il codice eseguendo il binario.
Tra l’altro mi sono accorto ora che c’è una inception perché questo è un goal di un Makefile che esegue un altro make, stavolta containerizzato.
In realtà non c’è molto da dire: avremo il container in listen sulla porta 8080 ma possiamo anche rimapparla a nostro piacimento se ci dà fastidio; e questo container ci abilita a fare docker restart grtest (o qualsiasi altro nome voi diate al vostro, di container) per far si che istantaneamente il codice si ricompili e ricominci ad eseguirsi. Il passo ulteriore che potrebbe essere fatto è quello di monitorare per cambiamenti ai file del codice sorgente per l’autorestart del container, ma sinceramente non avevo voglia di arrivare così lontano.
Sono andato rapido, anche un po’ troppo, perché ritengo che questo piccolo lavoro di “ricerca” sia banale e sia ancora meglio guardare un caso di studio reale per poi adattarlo al proprio progetto. In ogni caso, in questo modo ho reso il mio codice C indipendente dal sistema operativo usato per lo sviluppo, quindi da parte mia non posso che consigliarlo a chi fa sviluppo C per processori con architettura i686/x86_64 😸
Il progetto, per chiunque avesse voglia di dargli un occhio, è ovviamente su GitHub.
Image courtesy of Tit Petric, whose post is amazing and full of interesting tips. 😁
Il buon Martin Graesslin ci aggiorna sullo stato dell’arte di Wayland e KDE. In particolare, adesso si sta concentrando sul far partire KWin senza XWayland, ovvero il layer di compatibilità tra X.org e Wayland.
Gran parte del lavoro è fatta, ma c’è ancora parecchio da sistemare:
[…] my personal main goal is to be able to handle a crashing XWayland. This will also be an interesting task as the X11 code in KWin also depends on other libraries (e.g. KWindowSystem) which do not expect to outlive the X server […]
E da parte mia non posso che augurargli buona fortuna.
19 Sep 2017
Ho un po’ di sonno, sono le 11 di sera, ma è troppo tempo che non posto sul blog e mi sono imposto di iniziare di nuovo. Quello che però non avevo previsto era l’iniziare da un argomento che sono sorpreso mi stia così a cuore, ovvero Firefox 57, ovvero Firefox Nightly. (Si: il doppio “ovvero” è voluto; grazie mille grammar nazi!)
Si perché dopo tanti buoni propositi ed essendo stato per tanto tempo utente di Firefox, alla fine ho capitolato: dato che Javascript dentro il browser mi dà da mangiare, e dato che i dev tools dall’altro lato della barricata sono migliori (o almeno, lo erano), ho abbandonato il panda rosso per passare a Chrome e fine della storia. Se non che… se non che Gianguido in chat mi ha avvisato del fatto che Firefox Nightly allo stato attuale è una figata, e mi ha fatto drizzare le orecchie.
Rendering: Servo all the things
Nell’ultima stable release ad oggi di Firefox, e ovviamente nelle nightly build, viene usato Servo come motore di rendering per il CSS – o meglio Stylo, un suo modulo integrato in Gecko. Devo dire che già così, il browser sembra tutto nuovo e il caricamento delle pagine ne risulta già parecchio migliorato.
Ormai anche Firefox è arrivato ad avere la sua versione multiprocesso, quindi ogni tab che apriamo è un processo gestito in maniera separata. Da about:config possiamo gestire il numero di processi separati massimi che Firefox può far partire. È onestamente una figata, anche perché essendo configurabile possiamo impostare un massimo di processi ideale come tradeoff per il nostro hardware.
Photon UI
Il complimento maggiore va alla Photon UI, che sotto Mac OS e sotto Linux fa veramente una grandissima figura. Sotto Windows ancora devo provarla per motivi di tempo e perché ho cambiato computer fisso nel frattempo, ma ci arriveremo; in ogni caso la nuova interfaccia è veramente una gioia per gli occhi.
La cosa che mi fa piacere notare è che oltre ad aver mantenuto lo stesso grado di flessibilità e configurabilità della precedente versione (che pure mi aveva colpito ma stufato in passato dopo qualche mese di uso), Photon ha introdotto anche persino una modalità compatta. Nella versione out of the box la nuova UI è già meno “alta” e massiccia di quella di Chrome. Con la versione compatta devo ammettere di essere arrivato direttamente nel nirvana con un calcio di cui il miglior punter al mondo andrebbe fiero per secoli.
I nuovi dev tools sembrano veramente promettenti. Io ancora non ho avuto modo di farci un giro in ufficio, ma penso dalla settimana prossima di iniziare a vedere come mi ci trovo. Onestamente sono molto, molto abituato alla console di Chrome, e sui debugger non sono uno che cambia abitudine facilmente. Principalmente perché non mi piace usarne. In ogni caso sul blog di Nightly c’è un ottimo approfondimento.
Vi faremo sapere.
Per quanto riguarda l’impressione di base comunque, l’unica cosa che posso rimproverare a queste Nightly che ormai uso da un mese è il fatto di essere delle nightly build appunto, quindi versioni dove accetti che qualcosa possa spaccarsi “because reasons”. Non vedo l’ora che quello che ho sotto le mani diventi la nuova versione stabile di Firefox. Davvero.
14 Aug 2017
Da qualche giorno ho ripreso a usare Firefox. Nello specifico come daily driver per il browsing personale sto usando Firefox Nightly, mentre su Chrome relego tutto ciò che è per lavoro; questo perché inizialmente volevo testare il rendering CSS tramite Servo, e il nuovo Electrolysis per le tab.
Nel frattempo mi sono accorto di una cosa divertentissima:
Nelle ultime nightly build il team, per controllare se la sostituzione dei loghi avveniva come previsto tra un rilascio e l’altro, ha deciso di controllare con un asset grafico un po’ speciale, ovvero il logo di Firebird:
Prossimamente, una review un po’ più seria di come se la sta cavando Mozilla con questa grossa scommessa. Per ora i punti che mi sento di sollevare sono:
- Electrolysis è una gran figata
- Servo pure, e non vedo l’ora che lo attivino su tutto il comparto rendering
- La nuova Photon UI mi ha fatto innamorare
Passo e chiudo. 👍
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”.
