Agosto 2019

Il mio metodo

Flusso riassuntivo della struttura di un mio repository GIT.

Master

Questo è il branch principale di produzione. Ne esiste solo un per progetto. In questo branch i commit rappresentano le versioni dell’applicativo pubblicate in produzione. In aggiunta aggiungo anche un tag che identifica la versione, per una rilettura comoda e rapida.
Se sono presenti delle anomalie nelle versioni in produzione che hanno bisogno di essere corrette nel più breve tempo possibile, creo un branch dal commit del master come “Hotfix”.

Release

Quando decido di portare tutti gli avanzamenti del develop in produzione, creo un branch denominato “release_x.y.z” (dove x.y.z è la prossima versione dell’applicativo). Qui vengono eseguite delle modifiche leggere che riguardano l’aggiornamento della versione. Di solito è il cambio della versione e del build number. Una volta pronti per andare in produzione, unisco questo ramo sia nel “master”(taggando il numero di versione) che nel “develop”, in modo tale da avere un punto sincronizzato trai i rami.

Develop

Questo è il ramo dello sviluppo, il campo di battaglia! Ne esiste solo di uno per progetto. Da qui vengono creati i rami per le nuove funzionalità e sviluppi. Io tendo, quando possibile, a creare un branch per ogni funzionalità che voglio implementare (partendo da develop). Ci possono essere dei commit che non prevedono la creazione di un ramo, ma sono modifiche molto lievi, quali pulizia del codice, aggiunta di qualche commento e similari.

Feature

Una volta pianificato e progettato lo sviluppo di una nuova funzionalità, creo un ramo, partendo da develop con il nome “feature_IDENTIFICATIVO-FEATURE”, dove IDENTIFICATIVO-FEATURE è, per l’appunto, l’identificativo della funzionalità. In caso di applicazione progettate e coordinate su JIRA, per esempio, è l’identificativo della storia relativa allo sviluppo (vi consiglio di integrare GIT sul progetto JIRA, la quale permette la creazione, direttamente dalla dashboard, del branch relativo alla storia stessa).

Hotfix

Questi rami vengono creati quando qualcosa va irrimediabilmente storto. Se sono presenti dei bug in produzione sfuggiti ai test, al quale bisogna porre rimedio subito (interrompendo qualsiasi sviluppo in corso), occorre creare un ramo “hotfix_IDENTIFICATIVO-HOTFIX” (come in develop, identificativo della storia in caso di JIRA od un altro che sia leggibile al volo). Essendo una “toppa” da mettere all’applicazione in produzione, bisogna implementare solo gli sviluppi necessari alla risoluzione, senza incorporare niente del ramo develop che potrebbe essere ancora in sviluppo od in test. Questo ramo, quindi, verrà creato dal master ed, una volta terminato e pubblicato, esso sarà unito sia al ramo master che a quello di develop. Questo è l’unico caso che creo un ramo partendo dalla produzione.

I vantaggi di organizzare un repository git

So cosa state pensando, organizzare un repository git visti i tempi stretti di uno sviluppo tutta questa procedura può occupare un po’ troppo tempo inutilmente.
Per esperienza personale, anche se ad una prima occhiata può sembrare tale, sono in disaccordo. Sia che si lavoro come persona singola che si lavori all’interno di un team, capiteranno SEMPRE situazioni in cui siamo costretti a saltare tra una funzionalità ed un altra, risolvere problemi imprevisti o ricompilare versioni vecchie o di test.
Nel caso non si pianifichi una logica strutturata di GIT, arriverete ad un punto in cui vi potrebbe essere problematico e/o rischioso passare da un commit ad un altro. Strutturando i rami in questo modo io ho la sicurezza di poter cambiare lo stato del codice senza nessun effetto collaterale ed ho una lettura chiara e precisa dell’andamento evolutivo del progetto.

Spero che la mia esperienza su come organizzare un repository git vi sia stata utile!
E voi, come strutturate il vostro repository?

Alla prossima e buon coding!

Vi devo confessare una cosa. Sono un amante della pixel art. Il fascino retrò degli anni 80, suscita in me sempre grandi emozioni.
Implementare la Pixel Art in Android nelle proprie applicazione è semplice, ma bisogna utilizzare qualche piccola accortezza affinché le proprie immagini non vengano deformate.

Antialiasing: L’incubo della pixel art

da quando la tecnologia si è evoluta, la nemesi della pixel art è sempre stata l’Antialiasing.
L’Antialiasing, fatta eccezione per la pixel art, è una cosa positiva.

Quando un immagine dalle piccole dimensioni viene ridimensionata in una più grande, viene applicata, nella maggior parte dei casi, una tecnica per impedire l’ aliasing (“Gradinatura”, “Scalettatura”): esso consiste nell’ammorbidire le linee smussandone i bordi e migliorando l’immagine.
La pixel art si basa invece sulla “Scalettatura”. Essa è improntata sul far vedere all’utente i pixel che realizzano l’opera.
L’antialiasing, applicata su un immagine in pixel art, la trasforma come se fosse patinata (effetto miope senza occhiali per essere più precisi!), creando un forte disagio all’osservatore.

Dithering

Il dithering è una tecnica che aggiunge all’immagine del “rumore”, minimizzando eventuali distorsioni causate dal ridimensionamento dell’immagine.
In realtà questa tecnica viene usata anche per disegnare in pixel art.
La pixel art si basa sul colorare il singolo pixel di un determinato colore. Come è quindi possibile in un immagine creare delle sfumature?
“Ingannando” l’occhio umano con dei “pattern” (disposizione in un certo ordine dei pixel) che simulino questa graduazione:

Finché il Dithering è un processo deciso volontariamente dall’autore, nessun problema. Quando il dithering è generato automaticamente dai computer per scalare un immagine, può creare delle mutazioni che rendono l’immagine deformata.
Un immagine in pixel art è creata generando delle simmetrie precise tra i vari pixel. Un solo pixel modificato può rovinare l’intera opera.

Visualizzare Pixel Art in Android: L’approccio sbagliato

Proviamo a visualizzare un icona in pixel art come se fosse un immagine come tante, utilizzando una ImageView. L’icona creata da me è di dimensioni 16×16, e la ridimensioneremo a 160dp:

<ImageView
            android:layout_width="160dp"
            android:layout_height="160dp" 
            app:srcCompat="@drawable/sword"
            android:id="@+id/imageView"/>

Visualizzare un icona in pixel art in una ImageView senza nessun accorgimento

Come vedete, qualcosa non torna. L’immagine sembra opaca. Questo effetto è l’Antialiasing!
Android tenta di smussare le linee, dato che abbiamo aumentato di dieci volte la sua reale dimensione.

Come visualizzare correttamente la pixel art in Android

Per visualizzare correttamente l’immagine, è necessario creare una Bitmap e disabilitare l’antialiasing su di essa. Creiamo nella cartella drawable un xml “sword_pixel_perfect.xml”:

<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
        android:src="@drawable/sword"
        android:antialias="false"
        android:dither="false"
        android:filter="false"
        >
</bitmap>

src
Specifichiamo l’immagine bersaglio.
antialias
Questa variabile permette la disattivazione/attivazione della tecnica di antialiasing. Impostiamola a false.
dither
Possiamo, con questa impostazione, disattivare i dithering.
filter
FilterBitmap, se abilitato, esegue delle trasformazioni dell’immagine simile all’ antialiasing. Questo parametro si usa quando viene rotata un immagine, in modo tale da ammorbidire le linee.

Ora che abbiamo creato la giusta risorsa, non occorre altro che sostituire l’immagine dell’ ImageView con questo xml:

<ImageView
            android:layout_width="160dp"
            android:layout_height="160dp" 
            app:srcCompat="@drawable/sword_pixel_perfect"
            android:id="@+id/imageView"/>

Ed ecco qua la nostra immagine in pixel art perfettamente visualizzata in una applicazione Android!

Anche per oggi è tutto!
Spero che questa guida vi sia stata utile!
Fatemi sapere cosa ne pensate!

Alla prossima!

Buon codice a tutti!

Daniele Bachicchi