Post

Visualizzazione dei post da settembre, 2018

Apache Groovy un amore a prima vista

Immagine
INTRODUZIONE Prima di introdurre qualche esempio facendo un confronto tra Java e Groovy voglio citare la traduzione della frase principale indicata sul sito ufficiale di Apache Groovy: Apache Groovy è un potente linguaggio opzionale, tipizzato e dinamico, con capacità di tipizzazione statica e di compilazione statica, per la piattaforma Java volta a migliorare la produttività degli sviluppatori grazie a una sintassi concisa, familiare e facile da apprendere.  Forse è un pò troppo? O forse no? Ecco a voi qualche esempio. Scoprirete che groovy a volte è veramente sensazionale! LISTE Le liste sono utilizzatissime strutture dati che manipolarle in java è semplice ma macchinoso.  Vediamo alcune operazioni base! Dichiarare una lista [JAVA] List list = new LinkedList(); [GROOVY] def list = [] Inserire un elemento in lista [JAVA] list.add("FabryProg"); [GROOVY] list << "FabryProg" Inserire più di un elemento in li

Gestione della memoria immagini DOCKER con JAVA

Immagine
INTRODUZIONE JAVA Tutti oramai conoscono java sia perchè quando è nato, alla fine degli anni 90, fu una rivoluzione e sia perchè è stato il precursore dei moderni telefoni cellulari (spero che pochi di hanno avuto il dispiacere di scrivere sofware in J2ME!).  La rivoluzione principale è stata inserire una Virtual Machine dove far girare i software astraendosi dalla reale struttura hardware della macchina. CONTAINER DOCKER Il concetto di "container" nasce già intorno al 1979 con il "chroot UNIX", un sistema in grado di fornire ai processi degli spazi isolati all'interno della macchina in uso.  Dal 2013 Docker inizia a prendere piede ed essere il sistema più utilizzato in campo IT.  Nato principalmente per simulare ambienti controllati e asettici in ambito di sviluppo software fin da subito l'attenzione dell'intera comunità si sposta negli ambienti di produzione dato che viene intuita la potenza di avere un sistema isolato che fu

Capire e sviluppare un componente apache camel

Immagine
INTRODUZIONE Negli ultimi anni sofware sempre connessi e sempre più eterogenei sono stati i protagonisti e sono i framework ESB quelli che permettono di farli dialogare trasformando "il dialogo" in un unico flusso logico. Di ESB (Enterprise Service Bus) ce ne sono diversi. La fondazione Apache ha ormai da più di 10 anni portato avanti una propria implementazione che può contare di una comunità di sviluppatori molto attiva e decine e decine di componenti. Comunità che da qualche anno aiuto saltuariamente pure io. Settimana scorsa però mi sono accorto di una grave mancanza.... Apache Camel, alla fine del 2018, era carente su componenti DLT. A questo punto ho preso un impegno e ho sviluppato il primo componente per IOTA (che spero verrà pubblicato presto) Ma quali sono le classi chiave da imparare per sviluppare un componente Camel? E i requisiti? Vediamo un pò di fare ordine  PREREQUISITI Per sviluppare la versione corrente di Apache Camel occorre la JDK

Maven - Come non perdere il controllo delle dipendenze java

Immagine
INTRODUZIONE Ogni qualvolta che effettuo un packaging di un progetto java oramai è automatico l'utilizzo di apache maven . Non tutti però sanno che maven ha all'interno un ottimo algoritmo per la gestione delle dipendenze java che calcola sia le dipendenze dirette che quelle indirette. Questo algoritmo però è influenzato innanzitutto dalle librerie inserite nel file  pom.xml  (perchè hanno la precedenza) e volte possiamo trovarci con un progetto cresciuto molto negli anni di cui perdiamo l'esatta cognizione di quante e quali libreria utilizza. In questo post grazie a due plugin vedremo come capire bene lo status delle dipendenze incluse. CI SONO LIBRERIE INUTILIZZATE? Il plugin dedicato alle dipendenze (dependency) ha un goal specifico per capire e analizzare le librerie utilizzate (a compile time) L'output di questo comando dependency:analyze  produrrà 3 sezioni: Usate e dichiarate Usate e non dichiarate Inutilizzate e dichiarate Come detto pr

Lightning Network Bitcoin

Immagine
INTRODUZIONE Come spiegato oramai ovunque, l'obiettivo principale Satoshi Nakamoto era di creare un sistema di micropagamenti decentralizzato. Oggi sappiamo che bitcoin (e la sua blockchain), oltre ad essere stata una tecnologia rivoluzionaria, non è propriamente adatta allo scopo iniziale. Cambiare questa situazione o meglio quando un team vuole modificare e/o migliorare una struttura distribuita, occorre effettuare una modifica al codice sorgente che, se la stessa non verrà adottata al 100%, potrebbe far "dividere" (fork) la rete facendo nascere addirittura una struttura parallela e concorrente. Tentativi di miglioramento della rete bitcoin se ne registrano a decine (basti pensare ai diversi fork avvenuti negli ultimi anni). Un nuovo tentativo di migliorare le prestazioni (ferme a poche transazioni al secondo) è all'intera struttura è avvenuta in questi mesi sviluppando un layer aggiuntivo chiamato Lightning Network Bitcoin che si sovrappone alla bloc