Tarin Gamberini

A software engineer and a passionate java programmer

Storia del sito web della FSFE da Febbraio 2001 a Luglio 2016

Alcuni mesi fa mi sono iscritto alla Free Software Foundation Europe (FSFE) come traduttore (dall'inglese all'italiano).

Siamo una comunità di persone dedite al Software Libero. Per favore unisciti a noi ed al nostro lavoro! Ci sono molti modi per farlo e troverai il modo che meglio si adatta ai tuoi interessi ed alle tue competenze.

I miei interessi e motivazioni per associarmi alla FSFE sono varie:

  • supportare il Software Libero;
  • migliorare il mio inglese e mantenerlo allenato, sia in generale, sia relativamente al gergo politico ed amministrativo in particolare. Un'altra occasione è offerta dalle mailing list della FSFE: capita di scrivere email ad altre persone che vivono nei vari paesi europei;
  • imparare Vim facendo pratica su “veri articoli”;
  • migliorare le mie competenze dattilografiche in modo sano.

Recentemente mi è stato chiesto se fossi stato interessato ad avere i diritti di scrittura al repository dei sorgenti del sito web della FSFE… naturalmente ero interessato :-)

Mi sono immediatamente reso conto che il repository ha più di 15 anni di storia!!! Perciò ho cominciato a pensare che sarebbe stato interessante visualizzare tale storia con Gource. In passato avevo già usato Gource per visualizzare la storia di Parancoe, un meta-framework Java sviluppato da alcuni ragazzi del Java User Group Padova (JUG PD), ma questa volta ero curioso di vedere come la storia di un sito web fosse diversa da quella di un framework.

Così ho registrato un video di circa 10 minuti relativo all'attività di commit sul repository dei sorgenti del sito web della FSFE da febbraio 2001 a luglio 2016.

Controllore di vulnerabilità di dipendenze Java pronto all'uso

La maggior parte del Software Libero o a Sorgente Aperto è costituiti sia da nuovo codice sorgente sia da codice “binario” di terze parti. Quando scriviamo un nuovo software lo facciamo dipendere da molte librerie di terze parti (tali librerie da cui dipende sono anche chiamate dipendenze).

Per dare una idea riguardo a quanto possa essere complesso e profondo il grafo delle dipendenze supponiamo che il nostro nuovo software abbia una dipendenza diretta sulla libreria di terza parte rampart-core-1.3 (sulla sinistra nella figura sopra). Tale libreria dipende a sua volta da librerie di terze parti. Questo secondo livello di librerie di terze parti, rispetto al nostro software, comprende librerie dette dipendenze transitive. Ora pensate che il nostro nuovo software potrebbe avere molte dipendenze dirette ed immaginatevi di quante dipendenze di terze parti potrebbe essere costituito.

Grazie ad alcuni Analizzatori Statici di Codice java pronti all'uso sappiamo come scovare alcuni bug nel codice sorgente, ma cosa possiamo dire dei bug e delle vulnerabilità presenti nelle dipendenze di terze parti?

Il resto di questo post al momento è disponibile solo in inglese.

Diventa un traduttore!

Analizzatori Statici di Codice java pronti all'uso

Un analizzatore di codice statico è un software che ispeziona un dato codice sorgente, o un dato codice compilato, al fine di scoprire problemi di varia natura che spaziano dai bug al codice duplicato, da questioni di prestazioni ad aspetti di leggibilità.

FindBugs, PMD and Checkstyle sono tre analizzatori di codice statico estremamente semplici da usare.

Il resto di questo post al momento è disponibile solo in inglese.

Diventa un traduttore!

Refactoring Esplorativo

Un paesaggio da esplorare

by Andrew Collins - CC-0

Il Refactoring Esplorativo consiste in una serie di piccole modifiche applicate al codice sorgente che sono eseguite dal programmatore allo scopo di rispecchiare meglio ciò che ha compreso del codice esplorato.

Come l'esplorazione è un modo per scoprire luoghi camminandovi attraverso a disegnando una mappa, così il Refactoring Esplorativo è un modo per scoprire cosa fa un frammento di codice leggendolo e riscrivendone una piccola parte.

Il Refactoring Esplorativo è una tecnica che uno sviluppatore, che lavora su del codice legacy, potrebbe usare per capire la logica del codice prima di iniziare con il refactoring vero e proprio.

Il resto di questo post al momento è disponibile solo in inglese.

Diventa un traduttore!