Cosa abbiamo imparato? Docker, Giochi Psicologici e Adobe XD
In Intré non si finisce mai di imparare, del resto il nostro pay off è Learn / Code / Deploy Value.
Protagonisti di questo numero della rubrica Cosa abbiamo imparato sono Carlo Ballabio, Damiano Salvi e Diego Chierichetti.
Per ulteriori link di approfondimento vi rimandiamo al paragrafo finale Riferimenti. Buona lettura.
Giochi psicologici – Damiano Salvi
Nel corso dell’edizione Italian Agile Days del 2019 tenutasi a Modena, Damiano ha partecipato ad un interessante workshop che poco ha a che fare con le capacità tecniche, ma che lo ha molto colpito per gli aspetti di introspezione e di relazione inter-personale.
Partendo da un’introduzione all’Analisi Transazionale, durante il workshop si è parlato e approfondito la tematica dei Giochi Psicologici, ovvero esperienze relazionali a forte connotazione emotiva la cui conclusione produce danni e sofferenze e mai divertimento.
Per ulteriori approfondimenti vi rimandiamo all’articolo di Damiano.
Multi-stage build con Docker – Carlo Ballabio
Cercando di ottimizzare il più possibile la dimensione di un’immagine Docker Carlo è venuto a conoscenza delle multi-stage build.
Le multi-stage build sono disponibili dalla versione 17.05 (rilasciata nel giugno del 2017) di Docker e sono utili per ottimizzare le immagini creando configurazioni più semplici e più facilmente mantenibili.
Con le multi-stage build si hanno più istruzioni FROM nello stesso dockerfile, ognuna delle quali può avere un’immagine diversa di partenza e corrispondente l’inizio di un nuovo stage.
Definito un dockerfile con più stage sarà poi possibile copiare da uno stage all’altro solo i file veramente necessari ottenendo così un’immagine finale più snella.
Questa funzionalità può essere sfruttata per diversi scopi tra cui:
- Utilizzare un solo dockerfile (come nell’esempio seguente) per gestire una compilazione che necessita diverse immagini di partenza (semplificando così leggibilità e manutenzione).
- Creare un’immagine builder più corposa per poi spostare solo la parte compilata in immagine più snella da rilasciare.
- Creare un’immagine ad-hoc per i test senza che questi rientrino nei container che verranno rilasciati sempre usando un solo dockerfile.
Esempio
Di seguito un esempio di dockerfile preso dalla pagina della documentazione ufficiale di Docker (trovate il link nel paragrafo Riferimenti).
FROM golang:1.7.3 AS builder WORKDIR /go/src/github.com/alexellis/href-counter/ RUN go get -d -v golang.org/x/net/html COPY app.go . RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app . FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=builder /go/src/github.com/alexellis/href-counter/app . CMD ["./app"]
Nell’esempio, il primo stage serve a compilare mentre il secondo andrà a generare l’immagine rilasciata contenente solo la parte compilata.
Il comando COPY, con il flag –from=builder, copierà i file da uno stage all’altro.
Senza la multi-stage build si sarebbero dovuto creare due dockerfile separati e probabilmente uno script che eseguisse in sequenza le due immagini per poi copiare i file da un container all’altro.
Progettare una component library con Adobe XD – Diego Chierichetti
Come designer spesso ci si trova a lavorare con elementi, come ad esempio pulsanti navigation bar o campi di input, i quali si ripetono in molteplici pagine o progetti.
Questi cambiano la loro morfologia a seconda del layout in cui si trovano a dover interagire.
A seguito di queste piccole variazioni, a tendere, un designer potrebbe essere portato a perdere le linee fondanti dell’identità del progetto.
Lavorare con una libreria di componenti ben sviluppata come Adobe XD diventa quindi essenziale per evitare queste tipologie di problematiche e semplificare il lavoro.
Quali sono dunque i principali vantaggi del lavorare a componenti? Cerchiamo di capirlo grazie all’articolo di Diego.