Sulla mailing list del JUG Lugano è stato di recente postato il link del podcast del primo meeting dedicato a Scala.

Se siete interessati a questo nuovo linguaggio di programmazione di cui si parla molto nell’ultimo periodo ve ne consiglio vivamente la visione

Se non sapete cosa sia Scala e volete approfondire l’argomento vi consiglio due link in italiano:

• http://scala.ugolandini.com/page0/book.html: Dove potete trovare un libro gratuito ma in corso di lavorazione scritto da Ugo Landini.
• http://roma.javaday.it/javaday2009/presentazioni/DellAversana-Scala.pdf: La presentazione tenuta la JavaDay 2009 a Roma  e quda Raffaele Dell’Aversana

Di recente mi è capitato di dover sviluppare un applicazione web utilizzabile in cluster su JBoss 5 e con la sessione http replicata.

Il primo problema con cui ci troviamo a combattere è far partire 2 istanze di JBoss sullo stesso computer. Per risolvere ciò è necessario creare delle copie identiche della cartella [jboss-X]/server/all e chiamarle rispettivamente node1, node2.
Queste cartelle saranno tutte identiche e rappresentaranno il “workspace” della nodo.
Per eseguire il primo nodo basta scrivere:

> sh run.sh -c node1

Dove la parola che segue “-c” indica la configurazione da utilizzare per l’avvio.
Ora il primo nodo partirà sulla porta 8080.

Se andiamo ad avviare il secondo nodo cambiando solo node1 con node2 non funzionerà perchè andrà ad occupare la stessa porta. Per evitare ciò andiamo ad aggiungere una opzione al comando che diventerà:

> sh run.sh -c node2 -Djboss.service.binding.set=ports-01 -Djboss.messaging.ServerPeerID=1

l’opzione della virtual machine jboss.service.binding.set indica che questa configurazione dovrà partire sulla porta 8180.

Ora possiamo accedere ai due nodi agli indirizzi:

http://localhost:8080
http://localhost:8180

Ma come possiamo sapere se tutto è andato a buon fine? Per fare questo ho creato 2 semplici jsp:

set.jsp:

id di sessione: <%=request.getSession().getId()%>
<br />
<%request.getSession().setAttribute("test", "test ok");%>


get.jsp:

id di sessione: <%=request.getSession().getId()%>
<br />
Parametro: <%=request.getSession().getAttribute("test").toString()%>

E nel web.xml subito dopo il tag display-name o comunque all’interno del tag web-app inseriamo:

<distributable />

Questo dirà al nostro application server che questa applicazione è distribuita.

Entrambe le pagine jsp create in precedenza stampano a video l’id della sessione.
La pagina set.jsp imposta un valore nella sessione, mentre la pagina get.jsp lo legge, quindi se accediamo agli indirizzi:

http://localhost:8080/[nome_webapp]/set.jsp
http://localhost:8180/[nome_webapp]/get.jsp

Verificheremo che l’id della sessione siano identici e che in get.jsp venga stampato il messaggio: “tutto ok!”.

Se il test è andato bene vuol dire che la sessione è stata replicata con successo.

Per il momento questo è tutto. Se avete bisogno di aiuti, chiarimenti e simili commentate pure.

Domani Davide Cerbo e Stefano Linguerri presso Asset Data in Roma terranno 2 talk sull’utilizzo di Javascript come linguaggio Object Oriented e sul framework Google Web Toolkit.

Primo Talk (18:00-19:00 ca)

OBJECT ORIENTED JAVASCRIPT CON PROTOTYPE

Javascript viene sempre consiederato un linguaggio di serie B in cui
è impossibile seguire le buone regole della programmazione ad oggetti.
Ma non è così! In questa presentazione scopriremo come questo sia un
linguaggio in continua evoluzione e come sia possibile sviluppare
seguendo i paradigmi della programmazione ad oggetti. Scopriremo tool
e librerie che ci permetteranno di sviluppare creando batterie di
test, oggetti mock e inserire istruzioni di log nel nostro codice.
Durante questa presentazione illustreremo anche la libreria Prototype
che ci sarà di supporto durante gli esempi.

Secondo Talk (19:00-20:00 ca)

YAGTWO: Yet Another GWT Overview

La programmazione web sta facendo passi da gigante e oggi l’utente si
aspetta che l’esperienza di utilizzo si avvicini sempre di più a
quella a cui è abituato nei classici applicativi desktop.
Il mondo degli sviluppatori ha risposto inventanto una nuova sigla:
RIA, cioè Rich Internet Application.
Google non è stata a guardare e ha fornito la sua risposta a questa
esigenza donando alla community Google Web Toolkit.
Questo nuovo framework permette di sviluppare in Java tutta
l’interfaccia utente per poi ottenere un codice javascript che
funzionerà su qualsiasi browser web senza l’installazione di plugin
aggiuntivi.
In questa presentazione vedremo:

• perchè sviluppare applicazioni RIA
• perchè usare GWT
• come GWT utilizza AJAX per comunicare con il server
• le ottimizzazione che avremo utilizzando GWT
• come uscire dal browser con Google Gear e Mozilla Prism
• e non solo…

Alla fine della presentazione sarà disponibile anche il codice
sorgente degli esempi.

Per altre informazioni: http://www.jugevents.org/jugevents/event/15294

Domani parteciperò al Working Capital Camp di Catania e parlerò di:

Enterprise Social Network

Ecco le slide della presentazione che ho tenuto a Javaday di Roma il 24 gennaio 2009!.

The Hitchhiker’s Guide to testable code

Se volete lasciare commenti fatelo qui.

Grazie

La legge di Demetra (Law of Demeter o LoD o Principle of Least Knowledge) è una regola alla base della programmazione ad oggetti che consiglia di far conoscere ad un dato oggetto il minor numero di informazioni riguardo la struttura o le proprietà degli altri oggetti.

Ad esempio la seguente classe viola questa regola:

class WordDocument {
private String title;
…
WordDocument(HtmlDocument htmlDocument){
this.title = htmlDocument.getTitle();
}
…
}

Mentre il seguente esempio la rispetta:

class WordDocument {
private String title;
…
WordDocument(String title){
this.title = title;
}
…
}

Perchè WordDocument deve conoscere HtmlDocument? Il vantaggio potrebbe essere quello di convertire facilmente un documento Word in uno Html, ma non è questo il caso perchè l’unica informazione che realmente serve è il titolo del documento. Gli svantaggi invece sono tanti:

• posso costruire un documento Word solo a partire da un documento html, qualcuno potrebbe suggerire l’inserimento di due costruttori nella classe, ma in tal caso assegnerei una responsabilità impropria a WordDocument, una soluzione potrebbe essere l’utilizzo del pattern Factory.
• non è chiaro all’utilizzatore della mia classe di cosa veramente abbia bisogno un documento word per essere inizializzato.
• la complessità nella creazione di test unitari in isolamento aumenta perchè abbiamo a che con un altro oggetto di cui potremmo non conoscere il comportamento e per avere un test in isolamento dovremmo ricorrere a oggetti mock, ammesso che HtmlDocument sia una interfaccia.
• il livello di accoppiamento nel codice aumenta e tutti noi sappiamo che non è cosa buona: vero?

Qualcuno potrebbe obiettare che questo esempio non è attendibile perchè troppo semplice. Ad esempio per la costruzione di un WordDocument potrei avere bisogno di altre informazioni:

class WordDocument {
private String title;
private String subtitle;
private String authorName;
private String authorSurname;
private String description;
private  int pageNumber;
…
WordDocument(String title, String subtitle, String authorName, String authorSurname String description, int pageNumber){
this.title = title;
this.subtitle = subtitle;
this.authorName = authorName;
this.authorSurname = authorSurame;
this.description = description;
this.pagenumber = pagenumber;
}
…
}

E’ facile notare che il costruttore è cresciuto non poco e utilizzare una istanza di HtmlDocument avrebbe semplificato notevolmente il codice.
Una soluzione consigliata da Craig Larman nel libro “Applicare UML e pattern” è l’utilizzo delle “classi descrizione” che trai vari vantaggi hanno quello di ridurre informazioni ridondanti o ripetute, infatti il costruttore simile a quello di WordDocument potrebbe essere presente in HtmlDocument, quindi:

class DocumentInfo {
private String title;
private String subtitle;
private String authorName;
private String authorSurname;
private String description;
private  int pageNumber;
…
DocumentInfo(String title, String subtitle, String authorName, String authorSurname String description, int pageNumber){
this.title = title;
this.subtitle = subtitle;
this.authorName = authorName;
this.authorSurname = authorSurame;
this.description = description;
this.pagenumber = pagenumber;
}
…
}

e WordDocument diventa:

class WordDocument {
private DocumentInfo documentInfo;
WordDocument(DocumentInfo documentInfo){
this.documentInfo = documentInfo;
}
}

Ora sono quasi soddisfatto, ma la legge di Demetra è ancora violata dall’utilizzo di authorName e authorSurname per descrivere le informazioni relative all’autore del documento. Questo proprio non va perchè stiamo rappresentando con dei semplici attributi una classe concettuale, cioè la classe Author:

class DocumentInfo {
…
DocumentInfo(String title, String subtitle, Author author, String description, int pageNumber){
this.title = title;
this.subtitle = subtitle;
this.author = author;
this.description = description;
this.pagenumber = pagenumber;
}
…
}

In questo caso la creazione di una classe porta al rispetto della legge di Demetra perchè al documento non interessa conoscere il nome e cognome dell’autore ma l’entità autore. Questo avviene perchè se nel mondo reale non pensiamo a una determinata classe concettuale X come a un numero o a un testo, allora probabilmente X è una classe concettuale, non un attributo (sempre grazie a Larman per questa linea guida).

E se ancora non avete capito bene la legge di Demetra pensate a questo:

“Se in un negozio comprate qualcosa e dovete pagare €20. Date al commesso €20 o gli date il portafogli e gli dite di prendere €20?”

Bibliografia:

• Clean Code Talks – Dependency Injection di Misko Havery
• Applied UML and Patterns di Craig Larman
  

Uno dei problemi più comuni dello sviluppo con Javascript sono il logging ed il debugging.

Il primo di questi problemi lo possiamo risolvere con Blackbird, un simpatico script js ed un css che una volta inseriti nella nostra pagina web ci daranno la possibilità di visualizzare una accativante console dove inserire i nostri messaggi di log tramite i classici metodi log.debug(…), log.warn(…), per capirci proprio come se stessimo usando il nostro amato log4j

Altro poblema molto comune è invece il debug. Qui non posso che consigliare uno dei migliori plugin per Firefox che la mente umana abbia mai partorito: Firebug.
Oltre a permettere l’inserimento di breakpoint nel codice javascript tramite questo plugin è anche possibile ispezionare visivamente il codice di una pagina html, editare in tempo reale i CSS e molte altre funzionalità utilissime nello sviluppo di applicativi web.

(p.s.: Questo sito parla per lo più di programmazione Java, ma è anche vero che spesso ci troviamo a lavorare con Javascript e quindi, ogni tanto, mi sembra anche giusto parlarne)

Il 21 ottobre 2008 a Milano si svolgerà il

La partecipazione è totalmente gratuita. Il calendario sembra interessante, anche perchè oltre ad ascoltare si potrà anche mettere in pratica tramite dei laboratori.

JSON, è un formato di scambio dati che utilizza la notazione letterale fornita da JavaScript per rappresentare dati strutturati. È a tutti gli effetti un sottinsieme del linguaggio JavaScript. Ok, ma non esiste già il nostro simpaticissimo XML? Giusta osservazione, ma come vedremo JSON permette l’uso di dati che vengono interpretati direttamente come oggetti JavaScript o come array.
Quindi a differenza di XML, JSON fa uso di primitive ben supportate dai browser più comuni ce ne rendono estremamente efficiente la gestione.
Tutto ciò risulta molto comodo in Ajax, dove lo spreco di banda ed il parsing delle response sono sempre cruciali.

Ovviamente JSON è completamente indipendente dal tipo di linguaggio di programmazione utilizzato. Inoltre è ampliamente supportato dalla maggior parte dei linguaggi di programmazione grazie alla disponibilità di numerose librerie.

Tipi di dati e sintassi

I dati che si possono rappresentare in JSON sono di tipo:

object: ovvero una collezione di coppie chiave:valore separate da virgola e racchiusi all’interno di parentesi graffe. (ad es. { “cpu” : “AMD K10”, “ram” : “Kingston DDR3” } )

array: sequenza ordinata di valori separati da virgola (ad esempio “email” : [ “pincopallino@pippo.it”, “pluto@pippo.it” ] )

value: un singolo valore che può essere una stringa racchiusa tra virgolette, oppure un number, un object, un array o un boolean.

Esempio

Vediamo ora un esempio di testo in formato JSON:

{“person”: {
	“personalData”: {
		“firstName”: ”Giuseppe”,
		“lastName” : ”Pace”,
		“email”    : ”giuseppe.paceATpronetics.it”,
		“phones”   : [ “123456789”, “123456789”, “089123456”]
		“age”	     : 26
       }
}

Abbiamo un oggetto root “person” e un oggetto nodo “personalData”. Quest’ultimo a sua volta contiene (come da definizione di oggetto JSON) delle coppie chiave:valore. Notiamo che la chiave “phones” in realtà è un array, quindi una sequenza di valori.

JSON in JavaScript

Ora supponiamo di aver ricevuto dal server il testo dell’esempio precedente e supponiamo di volerlo “parsare” tramite JavaScript. Per fare questo basterà semplicemente usare la funzione JavaScript eval() come segue:

var myObject = eval(‘(‘ + myJSONtext + ‘)’);

Se ad esempio volessimo recuperare il valore del campo “email” contenuto all’interno del testo basterà usare la sintassi myObject.person.personalData.email.
Bisogna però stare attenti al fatto che eval() esegue qualsiasi codice JavaScript gli venga passato.Di conseguenza l’uso di questa funzione è indicato solamente quando sappiamo che la sorgente del messaggio è sicura. Inoltre non è detto che il messaggio JSON ricevuto sia valido.
Per questo è meglio usare un JSON parser come segue:

var myObject = JSON.parse(myJSONtext, reviver);

dove il parametro opzionale reviver è una funzione che verrà eseguita per ogni coppia chiave:valore.
Ogni valore sarà sostituito dal valore restituito dalla funzione reviver.
Il JSON parser fornito da questa libreria accetta solo testi in formati JSON, quindi niente script maliziosi!

Bene dopo aver visto cos’è JSON e come può essere usato in JavaScript non resta che chiedersi quale formato di interscambio è preferibile usare nelle nostre applicazioni.
Ovviamente dipende dal contesto e dai requisiti dell’applicazione stessa. Inoltre bisogna anche valutare quanto un certo formato piuttosto che un altro sia supportato dal linguaggio di programmazione usato.
Di conseguenza è importante la disponibilità di librerie per il ‘marshalling’ degli oggetti e ‘unmarshalling’.
A questo proposito mi piacerebbe approfondire la cosa con i membri del JUG!

Peppe Pace.

Ho letto sul sito della Sun un HowTo su come settare alcuni parametri
riguardanti la garbage collection in modo da renderla meno
“penalizzante” su sistemi che hanno vincoli stringenti in termini di
troughput o tempi di risposta. Provo a sintetizzare quel che mi è
parso di capire.

Non sono elencati tutti i parametri di “fine tuning” del
gc, nè tantomeno vengono spiegati tutti i principi di funzionamento
indicati nei documenti (che ho elencato in fondo a questo post) o i
casi in cui è meglio optare per una soluzione piuttosto che un’altra.
Ho seguito gli esempi presentati sul sito e mi sono occupato
principalmente delle ottimizzazioni maggiorimente utili per
applicazioni enterprise.

Se qualcuno ha avuto modo di sperimentare direttamente altre questioni
collegate alla configurazioni del garbage collection, sono benvenute
integrazioni (ho visto che nelle versioni più recenti di java esistono
altre opzioni, alcune però utilizzabili solo su macchine Solaris in
quanto vanno ad agire in modo strettamente correlato col sitema
operativo – es. si può decidere di non trasferire alcune pagine di
memoria su disco)

dalla jvm 1.3 in poi si possono usare 2 tipi di garbage collection

(a)- una è bloccante ma parallelizzabile (quindi su sistemi
multicore/multicpu scala bene). tale tipologia è anche chiamata
“throughput garbage collector”

(b)- una è composta di 4 fasi, 2 brevi e bloccanti e 2 più lunghe ma
concorrenti… può essere utile per migliorare i tempi di risposta, ma
non viene parallelizzato. anche noto come “concurrent garbage collector”

- per jre 1.4.2+ oltre ai collector “troughput” e “concurrent” esiste
il gc “incremental” (detto anche “train”)

il ciclo di vita di un oggetto, dalla creazione alla garbage
collection, passa attraverso 3 aree di memoria, su cui le policy di
garbage collection sono diverse
- eden
- young (o survivor)
- old

per gli oggetti che si trovano nello stato “old” viene adottata la
policy (b), per gli altri la (a)

ci sono diversi parametri per stabilire quando un’oggetto passa da
un’area di memoria all’altra e quanto l’intervento del gc deve essere
aggressivo, intendendo con cioò sia quanta (poco) spazio sull’heap
deve restare prima che il gc intervenga, quanto tempo debba essere
trascorso dall’ultima operazione di gc e quanto spazio si debba
effettivamente tentare di liberare.

benché la garbage collection resti un evento imprevedibile, a seconda
del contesto applicativo si possono comunque regolare questi parametri
al fine di avere interruzioni più brevi, menoi frequenti o comunque
meno bloccanti per l’applicazione

le opzioni sono

-XX:+UseParNewGC (jre 1.4.1+) parallelizzazione della GC per “young”
-ovvero la policy (a), può essere usato contemporaneamente alla policy
(b) per gli old
-XX:ParallelGCThreads=n che ritengo autoesplicativo e va settato al
numero di cpu o jvm sul sistema in uso
-XX:+UseParallelGC (jre 1.3+) viene usata esclusivamente la policy (a)
-XX:+CMSParallelRemarkEnabled da utilizzare per ridurre le pause nella
fase di remark (la terza su 4)

-XX:+AggressiveHeap (RAM 256+Mb) ottimizza per applicazioni
“memory-allocation intensive”… è pensato per sistemi con molta
memoria e molti processori, ma – per jre 1.4.1+ – funziona bene anche
con “solo” 4 cpu

-XX:+UseAdaptiveSizePolicy regola automaticamente l’utilizzo di una
parte dell’heap (young/tenured ratio)

-Xincgc per abilitare l’utilizzo del GC “incremental”

-XX:+UseConcMarkSweepGC (jre 1.4.1+) uso della GC concorrente per
“old”, può essere usato contemporaneamente alla policy (a) per gli
young
-XX:CMSInitiatingOccupancyFraction=n indica la frazione di heap
occupato prima che avvenga la gc… impostarlo all’80-90% può
garantire interruzioni meno frequenti. Attenzione! Siccome il GC in 4
fasi non disabilita i setter metre libera la memoria, impostarla ad un
valore troppo elevato può causare problemi di OutOfMemory quando con
l’utilizzo della policy (a) non se ne avrebbero avuti

-XX:SurvivorRatio=z quanta parte del “survivor space heap” deve essere
usata prima che gli oggetti vengano promossi ad “old”. il default è
50%

-XX;MaxTenuringThreshold=y quanto gli oggetti debbano “invecchiare”,
ovvero quante volte debbano essere copiati, prima di diventare “old”

in ambito web, dove molti oggetti sono usati una o poche volte prima
di essere dereferenziati, è possibile settare y a zero per forzare
l’intervento della policy b e quindi causare interruzioni + brevi. è
conveniente associare questo parametro ad un valore molto alto di
-XX:SurvivorRatio in modo che si passi direttamente da “eden” a “old”

-XX:+AggressiveOpts utilizza ottimizzazioni che saranno probabilmente
attive di default nella prossima release della jvm… attenzione: le
prestazioni possono variare da versione a versione… da una relese
all’altra potrebbero cambiare le opzioni e non è garantito che le
ottimizzazioni che attualmente hanno luogo se si attiva quest’opzione,
effettivamente poi saranno di default.

un esempio pratico evidenzia che in un’applicazione SIP migliori le
performances semplicemente cambiando i parametri che regolano il
funzionamento del GC

caso 1:
java -Xmx512m -Xms512m -XX:MaxNewSize=24m -XX:NewSize=24m -XX:SurvivorRatio=2

“old” latency 3s (!!!!)
“young” latency 110ms
GC sequential overhead 18.9%

caso 2:
java -Xmx512m -Xms512m -XX:MaxNewSize=24m -XX:NewSize=24m
-XX:SurvivorRatio=128 -XX:+UseConcMarkSweepGC
-XX:MaSInitiatingOccupancyfraction=60

“old” latency 115ms
“young” latency 100ms
GC sequential overhead 8.6%

caso 3:
java -Xmx512m -Xms512m -XX:MaxNewSize=24m -XX:NewSize=24m
-XX:SurvivorRatio=2 -XX:UseParNewGC +UseConcMarkSweepGC
-XX:MaSInitiatingOccupancyfraction=60

“old” latency 145ms
“young” latency 50ms
GC sequential overhead 5.9%

passare da 18.9% a 5.9% non mi pare male
e nemmeno dai 3 secondi di interruzione per una GC a 145ms…

non dimetichiamoci che, oltre alle opzioni relative al garbage
collector, per applicazioni enterprise è necessario
- aumentare la dimensione massima dell’heap (quella di default è
veramente bassa)
- settare -Xms e -Xmx allo stesso valore in modo da avere un
comportamento più costante nel tempo

per determinare in che modo dimensionare le varie parti dell’heap si
può procedere nel seguente modo
- di fa una raffigurazione del ciclo di vita degli oggetti sul piano
cartesiano e si stima la quantità di “young” e “old”… è bene
comunque fare diverse prove
- se ci sono molte pause dovute alla gc, conviene assegnare via via
più memoria per “young”
- va tenuto conto che quando ci si avvicina a metà della dimensione
dell’heap assegnato a “young”, le prestazioni peggiorano

riferimenti
http://java.sun.com/docs/hotspot/gc1.4.2/
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html (più
aggiornato ma non contiene la spiegazione di tutti i dettagli)

http://java.sun.com/developer/technicalArticles/Programming/turbo/

http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp (elenco
di varie opzioni per la vm)