TestedBy

Un’interessante idea di Stefano a proposito dei test. Cambiare il punto di vista: dal test che verifica il comportamento di una o più classi, alla classe a cui sono collegati dei test che verificano il comportamento della stessa e stabiliscono un contratto, cioè esplicitando comportamenti che poi vengono documentati, anche nel javadoc.

public class TestedBySample {

    /**
     * @param args
     */
    public static void main( String[] args ) {
        TestedBySample sample = new TestedBySample();
        System.out.print(sample.add(1, 2));

    }

    @TestedBy( testClass = "it.javalinux.testedby.TestedBySampleTest", testMethod = "addShouldWork" )
    public int add( int i,
                    int j ) {
        return i + j;
    }
 @TestedByList( {@TestedBy( testClass = "it.javalinux.testedby.TestedBySampleTest", testMethod = "addShouldWork" ),
        @TestedBy( testClass = "it.javalinux.testedby.TestedBySampleTest", testMethod = "addShouldWork2" )} )
    public int add2( int i,
                     int j ) {
        return i + j;
    }

Il link del progetto è: http://code.google.com/p/testedby/

JBoss: nuova jBPM Console e altro…

C’entra sempre GWT.

The new BPM console approaches it’s first milestone and I’d like to use that opportunity to introduce you to the most important changes and new features.

Moving to GWT
More and more JBoss projects are moving to GWT. And they do it for a good reason:

• If you are familiar with Java development and don’t want to become the next web developer expert, then GWT is a good choice. With GWT you can stick to eclipse, fire up a debugger and write unit tests.
• It has a rich set of UI widgets that you can use out of the box. The widgets also force a common look and feel across implementations.

Another good example of a successful GWT implementation is the Drools console.

Dagli screen shot sembra che abbiano usato GWT Ext.

Quand’è che toccherà a Wise?

Per la notizia: http://www.jboss.org/feeds/post/first_glimpse_at_the_new_bpm_console

Un post da diario

È un periodo di studio in cui sto prendendo confidenza con nuovi argomenti. GWT, bsd sockets, Mockito, Virtools ed altre cose.

Con GWT ho già realizzato un prototipo d’interfaccia da usare come base di un progetto di prossima realizzazione. Ho usato la 1.4 e mi appresto a provare la 1.5.

Le socket mi servono per un’idea che dei miei amici mi hanno suggerito. Visto che i progetti di prova li sto scrivendo in C++, ne approfitto anche per rinfrescarmi la memoria su questo linguaggio. Più in la mi toccherà rivedere anche le QT, visto che intendo usarle per la GUI del “coso” a cui sto lavorando.

Mockito, che mi ha fatto conoscere il mio collega maeste, è un oggettino utile per fare mock object java, quindi per i test di unità.

Virtools è una tecnologia per lo sviluppo di ambienti virtuali 3D. Mi sta creando indirettamente qualche problema. Per installarlo sulla mia macchina mi serve una copia di Windows perfettamente funzionante, possibilmente non virtualizzata. Dato che non vorrei partizionare il disco del mio MacBook Pro, sto tentando di installarlo su un disco USB esterno, senza successo. Cioè, dopo vari giri sono riuscito a mettere una installazione di XP sul disco esterno, ma non riesco a fare il boot. In compenso però ho conosciuto rEFIt, un boot manager per mac che tra le sue funzioni comprende l’apertura della shell EFI.

Nella lista non ho citato JBoss ESB, che per il momento ho tralasciato, ma che dovrò affrontare quanto prima approfonditamente.

Continuo a prestare attenzione alle novità che riguardano WebKit. Oggi ho letto un articolo su Meta, un porting di WebKit pensato per essere integrato nei videogame. Ne avevo parlato qualche post fa.

Esempi sbagliati

Ok, ieri sera ero stanco, oggi sono poco concentrato a causa di una brutta nottata. Ci sarei potuto arrivare prima. Stiamo parlando sempre dell’errore Expected parameter value, got “null”. Ma C’è anche del dolo nel modo in cui è stata scritta la documentazione di seam:

15.1.1. Attachments

eam makes it easy to attach files to an email. It supports most of the standard java types used when working with files.If you wanted to email the jboss-seam-mail.jar:

<m:attachment value="/WEB-INF/lib/jboss-seam-mail.jar"/>

Seam will load the file from the classpath, and attach it to the email. By default it would be attached as jboss-seam-mail.jar; if you wanted it to have another name you would just add the fileName attribute:

<m:attachment value="/WEB-INF/lib/jboss-seam-mail.jar" fileName="this-is-so-cool.jar"/>

You could also attach a java.io.File, a java.net.URL:

<m:attachment value="#{numbers}"/>

Or a byte[] or a java.io.InputStream:

<m:attachment value="#{person.photo}" contentType="image/png"/>

You’ll notice that for a byte[] and a java.io.InputStream you need to specify the MIME type of the attachment (as that information is not carried as part of the file).

A me serve l’ultima forma del tag attachment. In pratica costruisco un file di excel col Renderer e poi lo codifico in uno stream. Però, dimenticanza grave, un allegato ha bisogno di un nome. Quindi, al contrario di quello che viene detto sopra, non è sufficiente indicare come parametri lo stream (value) e il mime-type (contentType), ma serve anche il nome del file (fileName). Cioè, bisogna scrivere così:

<m:attachment value="#{mail.attachment}" contentType="#{mail.mimeType}" fileName="#{mail.fileName}"/>

Cioè, altre cose che non sopporto sono gli esempi sbagliati.

Messaggi d’errore inutili

Chi scrive codice, ma anche chi si limita ad usare software, sa bene che ogni tanto ci si può imbattere in un problema segnalato da un messaggio d’errore che non dice nulla. Ad esempio, poco fa tentando di usare un componente di seam per inviare mail con allegati, mi si è presentato il seguente errore:

Expected parameter value, got “null”.

Nulla, ne il messaggio d’errore ne il log del container, spiega quale sia questo benedetto value mancante. E da una prima analisi sembra che non manchi il necessario per spedire il messaggio. Sicuramente c’è una ragione (ipotesi da verificare, configurazione del mail sender). Però mi chiedo: perché tanto odio nei confronti dei poveri programmatori che alle sette di sera potrebbero avere qualche difficoltà a mettere a posto tutti i dettagli necessari a spedire una stupida mail?

Già che ci sono, la mail in questione contiene come allegato un file di Excel. Non tutti sanno che per generare file di Excel (ma anche di altre applicazioni di Microsoft Office) è sufficiente creare dei file html seguendo le specifiche che è possibile scaricare da MSDN, per poi associargli l’estensione xls e all’occorrenza il mimetype “application/vnd.ms-excel”. Insomma, niente più export di file in csv.

Android…

Ho scaricato Android. E’ un SDK basato su una libreria java e contenente alcuni strumenti di utilità, tra cui un emulatore ed un plug-in per Eclipse. Insomma, un po più di una semplice press release, come ha sostenuto Ballmer. Ma costui ci ha abituato ad affermazioni idiote che poi alla prova dei fatti sono state prontamente smentite. Ignoriamolo, e concentriamoci invece sui primi particolari interessanti. Non ho ancora avuto modo di guardare un po più a fondo questo SDK però ho fatto la prima scoperta grazie a Surfin’ Safari: Android usa il WebKit. Questo ha già portato e porterà ulteriori contributi al codice di WebKit che lo rendono più adatto ai dispositivi mobile. Al momento non tutte i contributi del team di Android sono entrati a far parte del repository ufficiale. Questi sono comunque disponibili immediatamente, in attesa dell’integrazione già stata pianificata.

Ulteriori notizie in seguito.

Classi Java, singleton ed Objective C

Le classi java non sono un oggetto. Si, esistono le istanze di Class, ma queste sono una supporto per l’accesso alle proprietà delle classi sottostanti (relazioni con altre classi, membri privati, metodi, annotation…). L’interfaccia esposta da Class facilita l’ispezione della classe ma non facilita l’uso di questa classe come componente applicativo. Per spiegare meglio questo concetto farò un esempio che prende spunto dal seguente problema: è meglio usare un singleton o una classe con i suoi metodi statici? Vediamo un attimo le due situazioni:

// definizione classe con metodi statici

class MiaClasse { public static void metodo1() { ... } public static Object metodo2(int valore) { ... }}

// utilizzo classe con metodi statici

MiaClasse.metodo1();...Object r = MiaClasse.metodo2(10);

// classe singleton

class MiaClasse { private MiaClasse() { ... } private static MiaClasse instance = null; public static getInstance() { if (instance == null) instance = new MiaClasse();  return instance; } public void metodo1() { ... } public Object metodo2(int valore) { ... }}

// utilizzo classe singleton

MiaClasse.getInstance().metodo1();...Object r = MiaClasse.getInstance().metodo2(10);

Il singleton è indubbiamente una soluzione che aggiunge complessità, almeno in un primo momento. Però ha un vantaggio: permette di trattare il componente funzionale come un oggetto, con tutto quello che ne consegue. Ad esempio, se il singleton implementa una certa interfaccia M, è possibile passare il singleton ad un metodo che accetta un parametro di tipo M.

class MiaClasse implements M { ...}

class AltraClasse {public void metodoM(M param) { ... } ...}

AltraClasse a = ...;

a.metodoM(MiaClasse.getInstance());

E’ possibile fare la stessa cosa utilizzando l’oggetto Class?

La risposta è… forse… penso di si, ma in modo più complicato, così complicato che il singleton alla fine sarebbe la soluzione migliore.

Queste considerazioni mi fanno venire in mente un fatto: in Objective C le classi sono oggetti al pari di altri e potete permettervi di passarle come parametri ad un metodo ed usarle per richiamare i metodi della classe come si fa con i metodi delle istanze. Ad esempio:

@interface ClasseA{ ...}+ (int) metodo1: (int) valore;

...

@interface ClasseB{ ...}- (void) metodo2: (id) oggetto;

...

@interface ClasseC{ ...}- (int) metodo1: (int) valore;

...

@implementation ClasseB- (void) metodo2: (id) oggetto{ int y = ... ; .... int x = [oggetto metodo1: y] ...}

...

// utilizzo ClasseA come parametro metodo2ClasseB* b = ... ;[b metodo2: ClasseA];

// utilizzo istanza di ClasseC come parametro di metodo2.

ClasseC* c = ...;[b metodo2: c];

Insomma, se Java fosse come l’Objective C, probabilmente si potrebbe evitare il ricorso ai singleton tutte quelle volte che vorrebbe trattare la classe come un oggetto. Il problema è capire quando questo è, più che necessario, possibile. Cioè, che probabilità ci sia che questo prima o poi diventi una necessità.