MongoDB with mongoshell (JS), Java 10gen Driver, Casbah 10gen scala driver

Javascript, Clojure, Scala

Presentazione tenuta al Jug Sardegna Meeting su tecnologie Jboss.

La presentazione mostra il funzionamento e le caratteristiche di Hibernate Search

Author:Sanne Grinovero

Presentazione tenuta al Jug Sardegna Meeting su tecnologie Jboss.

La presentazione mostra il funzionamento e le caratteristiche di Infinispan

Author:Sanne Grinovero

Presentazione tenuta al Jug Sardegna Meeting su tecnologie Jboss.

La presentazione mostra i principi REST e come renderli utilizzabili con RESTEasy tramite annotazioni.
Vengono mostrate anche funzionalità avanzate come chiamate e Job asincroni, compressione gzip, cache, integrazione con Spring

Author: Massimiliano Dessì

Scala fornisce la possibilità di definire le astrazioni come nelle Java Interface chiamate Trait, ma in più possiamo anche definire l’implementazione della astrazione dentro il Trait.

Vediamo ora l’utilizzo dei Trait scrivendo del codice usando il pattern Observer.

trait Subject {
    /* definisce la struttura di un observer, possiamo pensarla come una classe anonima java */
    type Observer = { def receiveUpdate(subject: Any) }

    // dichiara la lista di osservatori
    private var observers = List[Observer]()
    // definisce il metodo addObserver per aggiungere osservatori
    def addObserver(observer:Observer) = observers ::= observer
    // definisce il metodo di notifica di un evento a tutti gli osservatori
    def notifyObservers = observers foreach (_.receiveUpdate(this))
}

Definiamo ora un generico Component che realizza un command

class Component(val label: String) {
    def execute() = {
      // Logica del componente
    }
}

Utilizziamo il Trait Subject nella classe ObservableComponent per mostrare come viene utilizzato anche il corpo della astrazione (notifyObservers nel nostro caso).

class ObservableComponent(name: String) extends Component(name) with Subject {
    override def execute() = {
        super.execute()
        notifyObservers
    }
}

Per completare l’esplorazione dei Trait vediamo ora come possiamo “impilare” (stackable) i Trait ed estenderli.

Definiamo ora l’astrazione Command ma questa volta senza dargli nessuna implementazione, in modo che ObservableAction la estenda.

trait Command {
   def execute()
}

Utilizzando la keyword with possiamo creare lo stack dei nostri Trait, l’esecuzione dei Trait avviene in base all’ ordine di dichiarazione con i with,  e questo ci permette di comporre in maniera dichiarativa dei comportamenti.

trait ObservableAction extends Command with Subject {
abstract override def execute() = {
   super.execute()
   notifyObservers
}
}

Per brevità diciamo per ora che i Trait, quando utilizziamo la keyword with vengono chiamati da destra a sinistra, altra cosa importante è che possiamo utilizzarli quando ne abbiamo bisogno.

new Component("Hello") with ObservableAction with ...

Author Massimiliano Dessì

Questa e altre informazioni nella presentazione fatta al Javaday Roma 2010 da Stefano Linguerri:  Multiplayer-iPhone-Darkstar-javaday

In alcune situazioni particolari, richieste da determinati tipi di problemi, si rende necessario avere “memoria” tra una interazione client-server e l’altra per poter realizzare una “macchina a stati”. Per fare questo, dobbiamo appoggiarci alla HttpSession, rendendo l’applicazione Stateful, ma dobbiamo pagare il prezzo di avere un applicazione meno leggera e scalabile (a meno di usare altri strumenti come Terracotta).

Per questo tipo di problemi possiamo usare Spring Web Flow, costruito su Spring MVC che fornisce:

• Un dsl (domain-specific-language) per definire moduli con controller riusabili definiti flows
• Un controller engine per gestire conversational state
• Supporto per utilizzare Ajax per costruire rich user interfaces
• Support per utilizzare le JavaServerFaces con Spring

SpringWebFlow si prefigge lo scopo di creare flussi riutilizzabili attraverso un flow definition language fatto da XML e Unified EL (JSP e JSF) e OGNL (Object-Graph Navigation Language), principalemente tramite configurazione XML, ma anche tramite classi Java. Con questi flussi possiamo costruire macchine “a stati”.

In questo articolo vedremo una trattazione non esaustiva della configurazione di webflow per la costruzione di flussi.

Flows

Vediamo le informazioni che abbiamo a disposizione nei flussi dichiarati nell’ xml.

• currentEvent : Evento corrente, l’ ultimo processato dal flusso attivo
• currentUser : Il Principal ovvero l’utente autenticato
• externalContext : Il contesto “esterno” al flusso ovvero le API Servlet (Session, Request, ContextPath, etc) in cui il flusso vive. L’external Context è a tutti gli  effetti un Facade che fornisce al flusso l’accesso al mondo “esterno”.
• flowExecutionContext : Fornisce l’accesso al Contesto (interno) di esecuzione del flusso.
• flowExecutionUrl : Url relativo al contesto del flusso in esecuzione
• flowRequestContext : Fornisce l’accesso alla istanza corrente della RequestContext
• messageContext : Fornisce la possibilita’ di creare e recuperare messaggi dal flow execution (messaggi success o error)
• resourceBundle : Fornisce l’acccsso al file di properties con i messaggio internazionalizzati
• requestParameters : Fornisce l’accesso ai parameters presenti nella Request

Scopes

Vediamo ora le diverse visibilità fornite

• flow : Questo scope inizia con l’avvio del flusso e viene distrutto al termine del flusso, per essere utilizzati nella definizione xml gli oggetti devono implementare java.io.Serializable
• view : Questo scope visibilità inizia con l’avvio di uno view-state del flusso e viene distrutto al termine del view-state, per essere utilizzati nella definizione xml di questo scope gli oggetti devono implementare java.io.Serializable
• request : Questo scope inizia quando il flusso viene creato e la request viene salvata in questo scope. Viene distrutta quando il flusso restituisce l’elaborazione a seguito della richiesta.
  
• flash : Questo scope viene creato all’ inizio del flusso e viene svuotato dopo ogni view rendering, per essere utilizzati nella definizione xml di questo scope gli oggetti devono implementare java.io.Serializable
• conversation : Inizia con l’avvio del flusso e viene distrutto al termine. Ha visibilità anche nei sottoflussi, e questa è la diferenza che lo caraterizza dal flow scope

Flow States

Un flusso può trovarsi in vari stati, predefiniti attraverso la configurazione xml (o da codice java)

• start-state : Può essere definito esplicitamente o implicitamente uno stato di avvio. Se non definiamo esplicitamente, il primo state definito nel flusso viene considerato start-state. Altrimenti esplicitamente lo definiamo in questo modo:

  <flow start-state="myState"/>

• action-state : Un action state permette l’esecuzione di logica di business. Si possono utilizzare due approcci, utilizzando il tag action-state oppure con il tag evaluate dentro un view-state. Il tag evaluate ha tre campi

1. expression: permette la valutazione di un metodo su un bean accessibile dal flusso
2. result: il risultato dell’ evaluate può essere assegnato ad una variabile con uno scope a piacimento
3. resultType : il tipo del risultato

<evaluate expression="myService.findMyObjById(id)" result="flowScope.myObj"/>

L’ evaluate tag a sua volta può essere utilizzato in vari eventi del flusso:

- All’ avvio del flusso

<on-start><evaluate expression="issueService.findById(id, true)" result="flowScope.issue"/></on-start>

- All’ ingresso in uno stato

<view-state …><on-entry><evaluate…></on-entry></view-state>

- Prima del rendering

<view-state …><on-render><evaluate …></on-render></view-state>

- Al momento della esecuzione di una transizione:

<transition on="store" to="issueStore"><evaluate expression="persistenceContext.persist(issue)"/></transition>

- All’uscita da uno stato:

<view-state …><on-exit><evaluate…></on-exit></view-state>

- Alla fine di un flusso

<on-end><evaluate expression="itemInformationService.enrich(issue)"/></on-end>

• view-state : Nel view state vengono mostrati dei template

- id : identificativo dello stato

- parent : (Opzionale) Se lo stato eredita da un altro

- view : (Opzionale) Nome del view file, se omesso viene usato l’id come nome logico, sono possibili ridirezioni a file o indirizzi esterni

- redirect : (Opzionale) Viene effettuata una ridirezione prima del rendering

- popup : (Opzionale) Viene mostrato il rendering in un popup

- model : (Opzionale) Indica il modello che deve essere bindato sulla view

• decision-state : Un decision state è come un action state ma con la possibilità di utilizzare un if-then-else

<decision-state id="moreAnswersNeeded"><if test="interview.moreAnswersNeeded()" then="answerQuestions" else="finish"/></decision-state>

• subflow-state : Permetto di richiamare un flusso come sottoflusso

<subflow-state id="addGuest" subflow="createGuest"><transition on="guestCreated" to="reviewBooking"><evaluate expression="booking.guests.add(currentEvent.attributes.guest)"/></transition><transition on="creationCancelled" to="reviewBooking"/></subflow-state>

• end-state : Rappresenta la fine del flusso e può restituire un output oppure mostrare una view

<end-state id="objStore" commit="true"><output name="name" value="myObj.name"/></end-state>

<end-state id="issueStore" commit="true" view="externalRedirect:contextRelative:/myflow/obj/all"/>

Transition

Una transizione avviene quando a seguito di un evento si passa da uno stato ad un altro.Una transizione avviene in un view-state o in un action-state.

I parametri utilizzabili nella configurazione della transizione sono:

-bind : Disponibile nel view-state, se è a true viene effettuato il binding e la validazione prima della transizione, se non viene fatto il binding non viene fatta neppure la validazione. Il valore di default è true

-history : Disponibile nel view-state, opzionale, decide come deve essere il comportamento quando viene usato il tasto back, ci sono tre opzioni:

1. preserve (default) : Dopo la transizione è possibile ritornare allo stato corrente
2. discard : Dopo la transizione non è possibile ritornare allo stato corrente
3. invalidate : Dopo la transizione non è possibile ritornare a nessun view-state precedente

- on : Disponibile in action e view-state, è il nome del risultato che scatena la transizione, è una campo solo testo

- on-exception : L’eccezione (fully qualified name) che scatena l’esecuzione della transizione

- to : Il nome dello stato che viene raggiunto

Validation

Nel view state abbiamo visto che è possibile usare il tag model che causa il binding e la validazione di un nostro oggetto di dominio. Per effettuare la validazione abbiamo a disposizione due soluzioni, implementare un metodo che si chiami validate${state}(MessageContext context) dentro il nostro model object oppure creare una classe di validazione annotata come @Component e con il nome del metodo sempre come  validate${state} e con parametri in ingresso il nostro Object model e il MessageContext

Global transition

Nella configurazione è possibile definire delle transizioni globali, visibili in qualunque punto della configurazione

<global-transitions><transition on="login" to="login"><transition on="logout" to="logout"></global-transitions>

On-end

Alla fine di un flusso è possibile compiere delle azioni

ExceptionHandler

Possiamo definire le transizioni da effettuare in caso di eccezioni, specificando il fully qualified name

<transition on-exception="java.lang.NumberFormatException" to="add" />

Input/Output

All’ avvio di un flusso possiamo avere dei valori di input, ad esempio se il flow viene fatto partire da un url come il seguente

<a href="/myapp/myflow/issue/add?id=${issue.id}"/>

possiamo scrivere nella configurazione specificando il tipo in cui vogliamo sia convertito

<input name="id" type="long"/>

oppure recuperandolo da un determinato scope

<input name="id" value="flowScope.issue.id"/>

In output invece

<output name="id" />

In output invece <output name=”id” />

Variabili

Possiamo definire delle variabili a cui ci possiamo riferire in qualsiasi parte del flusso

<var name=”user” class=”com.myapp.User”/>

Flow Execution Listener

Possiamo predisporre dei listener sul flusso, solitamente sono quelli per la sicurezza e per la persistenza

<flow-execution-listeners><listener ref="securityFlowExecutionListener"/>
<listener ref="jpaFlowExecutionListener"/></flow-execution-listeners>

<bean id="jpaFlowExecutionListener">
<constructor-arg ref="entityManagerFactory" />
<constructor-arg ref="transactionManager" />
</bean>

<bean id="securityFlowExecutionListener"
class="org.springframework.webflow.security.SecurityFlowExecutionListener"/>

Conclusioni

Abbiamo visto come tramite la configurazaione xml possiamo dichiarare i nostri flussi, nell’articolo  successivo vedremo come realizzare delle azioni Create Read Update e Delete con una  applicazione di esempio, utilizzando la configurazione vista finora.

L’interminabile processo di formalizzazione di MIDP 3.0 e la scarsissima adozione su dispositivi reali del pur lodevole Java FX hanno però costretto gli sviluppatori a trovare una serie di soluzioni alternative, spesso consistenti in uno sfruttamento estremo dell’infrastruttura grafica a basso livello del “vecchio” MIDP 2.x.

Usando con accortezza le possibilità offerte dalle ridotte API del MIDP 2 è possibile implementare animazioni ed effetti simili a quelli Ajax. In questo post mostreremo alcuni accorgimenti che facilitano la scrittura di una funzionalità “AJAX” simile a quello usata da Google per suggerire termini di ricerca man mano che si scrive in un campo testo. L’implementazione di un client mobile dotato di una UI completamente customizzata è un lavoro lungo e di una certa complessità: in questo articolo forniremo solo le nozioni basilari per affrontare questa problematica.

Il modello applicativo di Ajax è di tipo asincrono; le richieste al server vengono eseguite da un modulo separato da quello che gestisce il disegno della UI, la quale viene modificata in tempo reale per adattarsi ai dati che giungono dalle response.

(fonte: J.J.Garrett from adaptivepath.com)

In Java ME, uno dei modi per ottenere delle UI personalizzate, più gradevoli e facili da usare rispetto a  quelle standard fornite dal sistema operativo del dispositivo è di creare componenti ed animazioni basati sulle classi Canvas e Graphics.

La classe Canvas è la “tela” su cui disegnare i nostri componenti tramite la giustapposizione di elementi geometrici come linee, poligoni e testo aggiunti con i metodi invocati su Graphics. Ad esempio, se g è la nostra istanza di Graphics:

String text = "Fortza Paris";
g.setColor(0xffffff);
g.fillRect(0, 0, Canvas.getWidth(), Canvas.getHeight());
g.setColor(0x000000);
g.drawRect(0, 0, Canvas.getWidth(), Canvas.getHeight());
g.drawString(text, Canvas.getWidth()/2, Canvas.getHeight()/2, Graphics.TOP|Graphics.HCENTER);

il codice soprastante disegna un rettangolo bianco con bordo nero grande quanto lo schermo, al cui centro si trova la stringa text. La UI appena disegnata viene tenuta in un buffer finchè non viene invocato un metodo di “esecuzione” del disegno come paint(), repaint() o serviceRepaints().

Vediamo ora come ottenere un comportamento simile a quello di Ajax in un’applicazione Java ME usando Canvas.

Creiamo una sottoclasse di Canvas (o, se necessario, di GameCanvas) che implementa Runnable, nel cui run() scriveremo il codice che ci permette un refresh ciclico dello schermo, utile per gestire transizioni, animazioni ed eventi della UI (come il cambio di focus da un elemento all’altro). L’esecuzione della UI in un thread separato, inoltre, ci permette di disaccoppiarla dal flusso base dell’applicazione e da altre operazioni potenzialmente bloccanti (es: connessioni).

final public void run(){
[...]
// “Invita” a ridisegnare lo schermo con le relative modifiche grafiche.
repaint(0, 0, width, height);
// Obbliga ad eseguire immediatamente qualunque richiesta di repaint ancora in attesa.
// Attenzione: è bloccante.
serviceRepaints();
[...]
}

Il codice del run() può inoltre comprendere una gestione del framerate (un refresh velocissimo potrebbe risultare troppo dispendioso per alcuni dispositivi, oltre che poco utile) e un metodo per la gestione centralizzata degli eventi, altro aspetto che, usando la Canvas, è gestito a basso livello andando ad intercettare gli eventi base sui tasti/schermo del cellulare.

Una volta scritta la parte che disegna la UI e gestisce i suoi eventi, è necessario scrivere la parte che si connette al server per richiedere i “suggerimenti” da mostrare a video.

Anche in questo caso, come dettano le norme di buona programmazione per applicazioni mobili, creeremo la classe che fa da client HTTP in modo che implementi Runnable, così da poter essere utilizzata in un thread separato e non bloccare la UI dell’applicazione.

Ipotizzando di effettuare delle richieste GET allo stesso server, il run() del nostro client, farà una cosa del genere:

synchronized (this){
		 // Se non vi sono richieste pendenti si aspetta...
                while (queryStrings.size() == 0){
                    try{
                        wait();
                    } catch (InterruptedException e){   }
                    //[...]
                }

                request = (String)(queryStrings.elementAt(0));
                listener = (ConnectionListener)listeners.elementAt(0);
		//[...]
            }
            sendRequest(request, listener);

il vettore listener è un registro di tutte le classi che richiedono una connessione, le cui queryString sono accodate nell’omonimo vettore e inoltrate progressivamente.

Il metodo sendRequest(request, listener) effettua le connessioni HTTP vere e proprie secondo la modalità standard del Generic Connection Framework di Java ME ed invoca il metodo di callback definito da un’interfaccia implementata dalle classi accodate in listener.

Di questa interfaccia e della gestione della response XML parleremo nella seconda parte di questo post.

Autore: Andrea Castello

Conosci i pattern? Questa e’ una domanda che prima o poi qualsiasi sviluppatore software si sentira’ fare, o si porra’ da solo. Mitizzati da alcuni, trascurati piu’ o meno volutamente da altri, i pattern, meglio noti come “design patterns”, rappresentano per la progettazione software l’analogo di quelle norme pratiche, tecniche o accorgimenti basilari che costituiscono il fondamento di ogni arte o mestiere.
L’unica differenza e’ che, mentre la maggior parte dei mestieri con una certa dose di creativita’ provengono da una lunga tradizione e i loro procedimenti sono quindi in qualche modo “standardizzati”, quello del programmatore (ad oggetti) e’ un mestiere relativamente recente, e ancora quindi non perfettamente delineato nei suoi canoni. Era inevitabile quindi che un giorno qualcuno si rendesse conto che era il caso di porre ordine in questa situazione, e di provare quindi a delinerare le “regole
del buon programmatore”.

La “banda dei quattro”

Fu cosi’ che nel 1994 un gruppo di 4 persone formato da Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides diede alla luce il libro che traccio’ per la prima volta le linee guida della buona programmazione ad oggetti: “Design Patterns: Elements of Reusable Object-Oriented Software”. Destinata fin da subito a diventare una delle pietre miliari della letteratura del software, l’opera dei quattro non fu chiaramente realizzata partendo da zero. Il loro lavoro infatti fu quello di trascrivere, astraendole dalle contingenze, le soluzioni migliori a loro note fino ad allora trovate nel campo della programmazione, ordinandole secondo strutture logiche ben definite e dando loro un nome preciso.
Sorprendentemente, alla fine di questo imponente lavoro, venne fuori che tutto questo insieme di soluzioni si rifaceva in summa a soltanto tre casistiche ben definite: la creazione, la composizione e il comportamento degli oggetti.

Incapsulare il concetto che cambia

Molti e importanti sono i principi alla base di queste soluzioni. Norme comuni di buon senso come “favorire la composizione rispetto all’ereditarieta’”, “ridurre le interdipendenze tra gli oggetti” e via dicendo trovano in questo catalogo motivazioni teoriche e dimostrazioni pratiche. Ma in particolare c’e’ un principio, davvero trasversale a tutti i pattern, il quale a mio avviso raccoglie in se’ tutto lo spirito dei design patterns e quindi della buona programmazione ad oggetti.

L’incapsulamento, tra le caratteristiche dei linguaggi Object Oriented, e’ forse quello piu’ difficile da far proprio per i neofiti della programmazione. Non tanto perche’ sia un concetto di per se’ ostico da capire – del resto viviamo in un mondo fatto di oggetti molto incapsulati, sia naturali che artificiali; quanto perche’ in fase di progettazione stabilire cosa davvero un oggetto debba esporre attraverso la propria interfaccia, e cosa no, sembra in partenza una questione in qualche modo soggettiva, o che comunque richieda una certa dose di esperienza per essere applicata al meglio.

Il manuale dei pattern ci insegna invece un principio fondamentale da seguire per essere sicuri di ottenere un buon livello di incapsulamento, e quindi un buon design, nel proprio software.

Il principio e’ quello di “incapsulare il concetto che cambia”.

Una volta studiato un problema, cioe’, si devono individuare quei fattori che possono “cambiare” nel tempo e nel luogo, allo scopo di rendere il nostro design il piu’ adatto a rispondere correttamente a questi cambiamenti. La progettazione deve quindi mirare ad isolare le parti passibili di cambiamenti in punti ben definiti, mascherando la complessita’ alle altre parti: ne viene fuori quindi un sistema “modulare” in cui ogni “pezzo” svolge un compito ben preciso, del cui svolgimento pero’ nulla e’
visibile alle altre parti del sistema.
Per esempio, se progettiamo un’applicazione grafica, ci sono molti fattori che possono variare nel “luogo”: l’ambiente di esecuzione, le librerie grafiche a disposizione, la risoluzione dello schermo etc., e nel “tempo”: una connessione di rete che puo’ andare su e giu’, un aggiornamento di pacchetti etc.

Nella programmazione ad oggetti un buon incapsulamento e’ alla base della stabilita’ e della longevita’ del software, intesa quest’ultima sia come manutenibilita’ che come vita vera e propria.
Un modello ad oggetti ben incapsulato e’ infatti facile da modificare: oltre ad essere nel complesso piu’ semplice da capire, un codice ben incapsulato dentro una classe puo’ essere modificato senza impattare sul resto del modello ad oggetti.
E un modello facile da modificare e manutenere e’ una carta vincente per un software che mira ad essere utilizzato con successo a lungo e da molte persone.

Un esempio

Vediamo un esempio di questo concetto: il pattern Builder.

Lo scopo di questo pattern creazionale e’ quello di astrarre la costruzione di oggetti di cui si conosce la logica di base, ma i cui singoli dettagli (i “pezzi” della costruzione) possono variare o non sono noti in fase di design. Esempi di queste situazioni sono le pagine web composte da moduli custom (es. portlet), oppure le interfacce grafiche con look and feel e/o layout personalizzabile o variabile secondo il sistema (es. swing l&f), etc. Come si puo’ notare, il pattern Builder affronta il problema della variabilita’ di costruzione dei componenti incapsulandone il concetto nell’interfaccia AbstractBuilder.
Il creatore dei prodotti finali, il Director, e’ in grado di assemblare il prodotto finale pur non conoscendo nulla della logica stessa di creazione delle singole parti. Il design che ne risulta e’ altamente flessibile e facilmente manutenibile: la modalita’ di creazione dei pezzi puo’ essere modificata a piacimento senza impattare nel risultato del prodotto finale.

Conclusione

La conoscenza dei design pattern e’ una base fondamentale nella progettazione di buon software. Ancora piu’ importante pero’ e’ far propri i principi che stanno alla base dei pattern stessi, in modo da essere in grado di procedere da soli anche quando le problematiche da affrontare sembrano non immediatamente riconducibili ai casi rappresentati nel catalogo. E perche’ no, magari scoprire da soli un nuovo, fantastico design pattern.

Author: Davide Deidda