Java in un Espresso, Parte III: April

Nei precedenti articoli abbiamo visto come creare un applicazione Java agile, evitando il blasone delle specifiche J2EE. Dopo aver valutato (scartandola) una soluzione 2-tier molto simile a quelle fattibili in PHP, ci siamo focalizzati su una soluzione basata su Spring.

Come test, abbiamo sviluppato a Gioorgi.com una applicazione didattica che abbiamo chiamato “April”.

April si serve di Spring e AspectWerz per mettere in pista un semplice monitor di file, che gira all’interno di una webapp. Le performance del file monitor sono misurate tramite un bean chiamato PerformanceMonitor, che è istrumentato tramite Aspetc Oriented Programming.

Il risultato è che il sistema crea un numero di thread variabili a runtime, finché i tempi di risposta del FileMonitor non si avvicinano a quelli richiesti dalla configurazione di Spring.

Il Performance Monitor ha dei limiti sul numero di thread che può creare, per evitare di sovraccaricare il sistema.

Inoltre pochissimo codice (circa cinque classi su una trentina) hanno riferimeni a interfacce Spring (per lo più per supportare la creazione di oggetti che siano gestibili con l’AOP di Spring).

April è un buon esempio di una applicazione strutturalmente semplice, che fa una cosa abbastanza complicata. Non sarebbe stato facile sviluppare April in un linguaggio di scripting, né sarebbe stato facile ottenere le performance che ha, come vedremo.

Autowiring

April sfrutta l’autowiring in modo semplice, per istanziare (e monitorare) degli startup task.

Contrariamente alle servlet, i task non devono essere servlet: è sufficiente che implementino una maker interface chiamata StartupTask.

Nel file di configurazione di Spring, vengono dichiarati i task di startup, che Spring provvederà ad istanziare per conto nostro. Inoltre Spring “inietterà” tutte queste istanze in una particolare collezione tipizzata che si trova in una classe chiamata “Startup”.

Al boot, viene creata una sola istanza di Startup da parte di Spring, e questa classe si occupa di creare un thread per ogni istanza che implementa l’interfaccia StartupTask.

Potete scaricare April da questo link: [download id=”2″] … e restate in ascolto!

Performance

April è stato proavto sia sul jdk 1.5 che sul jdk 1.6. Come si sa, cambiando versione di JDK le performance migliorano in modo apprezzabile. In particolare il JDK 1.6 si è dimostrato molto più veloce nella gestione dei file (è quasi dieci volte più veloce nella scansione degli oggetti file). Rispetto al vecchio jdk 1.4, la concorrenza è gestita in modo molto più efficace, ed è stato possibile raggiungere livelli di parallelismo dei thread molto spinti, semplicemente con un uso accorto delle zone di sincronizzazazione

Java Espresso, parte II

A Gioorgi.com abbiamo una sezione di ricerca e sviluppo, dove abbiamo la necessità di provare diversi tipi di ambienti in situazioni live: prova e ti riprova, abbiamo consolidato una certa esperienza in soluzioni Java Enterprise a “consumo ridotto”.

In questa serie di articoli (di cui state leggendo la seconda puntata) vediamo come ottenere un’ambiente Java leggero, LAMP-like che gira in una manciata di Megabytes…

Continue reading “Java Espresso, parte II”

Java in un Espresso, Parte I

Introduzione

Quando Java nacque nel 1995, aveva parecchie frecce al suo arco, ma anche molta incertezza. Ricordo che in università fu accolto con favore dall’ambiente accademico, per le sue spiccate doti didattiche.

Java era più semplice da insegnare del C++, e aveva una libreria di base molto ben organizzata. Era già previsto l’uso della proto-annotazione “@deprecated” perché Sun sapeva che avrebbe dovuto far evolvere l’API, e questo evidenziava la cura e l’attenzione per l’organizzazione del lavoro del project management.
Ai tempi Sun puntava sulle Java Applet e sugli aspetti di sicurezza, in cui Java eccelleva. Benché la vocazione di Sun fosse enterprise, ancora le specifiche EJB erano al di là da venire.

L’osservazione dei miei colleghi più scafati, che usavano PHP e Perl er ache Java era troppo pesante (in termini di memoria consumata) e lento (essendo interpretato) per i piccoli microcomputer da 12Mb che affollavano le nostre case.

Nel 2009, quattordici anni dopo, le cose sono cambiate e ora anche i pc di casa hanno sistemi a due processori e 4GB di RAM. Java è ancora lento e pesante ?

Vediamo come sviluppare applicazioni leggere e compatte in Java…

Continue reading “Java in un Espresso, Parte I”

The Valueteam PDFGenerator

 

Per un importante cliente di ValueTeam, ho sviluppato per un'applicazione chiamata PDFGenerator, che è stata pacchettizzata come un vero e proprio prodotto.
PDFGenerator nasce in una situazione caratterizzata da un alta variabilità dei requisiti utente.

Le specifiche del progetto hanno subito variazioni significative nell'arco di quattro anni, ed alla fine i requisiti utente erano parecchio mutati.  L'applicazione, già fatturata, non era ancora stata validata dal Cliente finale, ed era passata di mano moltissime volte.
Da un lato c'era la necessità di fornire uno strumento semplice da utilizzare, dall'altro la possibilità di espanderlo nel momento in cui le esigenze di Business del Cliente fossero cambiate, contenendo i costi di sviluppo.
Questi due aspetti erano acuiti in questo contesto, poiché i dati potevano provenire da fonti assai eterogenee per tipologia (database o personale del marketing) e l'utente finale doveva elaborarle in modo uniforme e rapido.
Per queste ragioni la specifica era cambiata spesso nel tempo, e la sfida era notevole.
PDFGenerator è semplice dal punto di vista software, e la sua forza sta nell'idea, e nella capacità di capire l'utente finale.

Si tratta di una applicazione che è in grado di caricare dati da un backend, e di generare poi a partire da esso una serie di documenti Word parametrici, da cui l'utente genera documenti pdf.
Tali documenti sono una serie di informative sui prodotti erogati dal Cliente verso i loro partner commerciali.

Si tratta di gestire agevolmente oltre 500 documenti, simili tra loro ma divisi in moltissime tipologie.

L'applicazione consente all'ufficio marketing di creare informative personalizzate, ed è integrata con Microsoft Office.
Il back end può essere esteso in diversi linguaggi (Java, .NET ecc) purché generi in uscita un file Excel.
Un modello MS-Word poi si occupa di integrare, con una serie di macro, i dati provenienti dall'Excel e di consentire, in modo guidato, la generazione di un vasto numero di documenti MS-Word.
E' quindi possibile estendere l'applicazione nelle due direzioni:
+ dal lato backend, arricchendo i moduli che forniscono i dati.
+ dal lato del front end, personalizzando l'interfaccia utente
L'estrema attenzione al Cliente si è concretizzata nello sforzo di fornire una interfaccia di amministrazione semplice e gradevole, seguendo i più moderni dettami dello Human Interface Design.

Inoltre, l'aspetto più importante è stato comprendere le esigenze del cliente attraverso lo sviluppo incrementale di una serie di prototipi operativi. Lo sviluppo di prototipi operativi in tecnologia WebJ2EE risulta difficoltoso,  mentre appoggiandosi agli widget grafici di MS-Office è stato possibile ridurre di quasi tre volte lo sforzo operativo.

Per maggiori informazioni, mandate un email