GuLinux's $HOME

Test Driven Development, C++ e Qt: refactoring, ottimizzazioni, d-pointer

2012-01-17T08:58:00.001+01:00

Nel precedente post abbiamo dato una messa a punto ai file del progetto. Potrebbe essere il caso di fare qualcosina anche per il codice sorgente...
In questa puntata vedremo alcuni passi di refactoring che ci aiuteranno ad implementare funzionalità future, e renderanno il codice più robusto. Vedremo ad esempio come applicare il meccanismo di Signal e Slot di Qt, particolarmente indicato per la programmazione "ad eventi", e in cosa consiste il pattern d-pointer che in alcuni ambienti (ad esempio nella programmazione per KDE) è divenuto uno standard praticamente obbligatorio
Continua a leggere...»

Test Driven Development, C++ e Qt: ottimizzazioni layout progetti

2012-01-08T21:09:00.000+01:00

Nella puntata precedente abbiamo creato un primo "vero" test di dominio perfettamente funzionante; il ciclo del TDD prevede a questo punto di effettuare un po' di refactoring, se necessario, prima di iniziare la nuova funzionalità.
In questo capitolo ci occuperemo non tanto di refactoring relativi al design (qualcosa si può fare, ma avendo scritto pochissimo codice è davvero poca roba), quanto piuttosto di trasformare quello che adesso è codice "sperimentale" in qualcosa di più professionale, usando layout di progetto, ottimizzazioni e convenzioni che sono da favorire in progetti pronti per la produzione.
Ma che problemi ha il nostro progettino?
In realtà un bel po', cominciamo dalle cose più evidenti: la prima è che i progetti sono collegati tra loro piuttosto malamente.
Sappiamo che il progetto DownloadManager deve usare DownloadManagerCore, ma al momento non c'è nessun riferimento ad esso. Sappiamo anche che il progetto UnitTests deve fare, e in realtà fa già, la stessa cosa. Ma per farlo abbiamo dovuto aggiungere la riga:

    LIBS += -L../DownloadManagerCore-build-desktop/ -lDownloadManagerCore

e di certo non vorremo tenerla così: quando infatti dovremo compilare in modalità release sarebbe necessario modificare manualmente il file di progetto (tanto nel progetto UnitTests quanto in DownloadManager), e non è sicuramente il massimo!
Ma anche nel codice sorgente c'è qualcosina che non va: in downloadmanagercoretest.cpp vediamo la riga

#include "../DownloadManagerCore/downloadmanagercore.h"

che dovremmo ripetere per ogni futuro test case. Non va bene!

Per fortuna qmake ci viene in aiuto con alcune funzioni interessanti.
Aggiungendo al file di progetto la riga

    INCLUDEPATH += ../DownloadManagerCore

rendiamo disponibli tutti gli header di DownloadManagerCore al progetto UnitTests, trasformando quindi la riga precedente in

    #include "downloadmanagercore.h"

Applichiamo questa modifica anche al progetto DownloadManager.

Per distinguere invece tra debug e release, usando anche un path migliore per la direttiva LIBS dobbiamo invece usare una funzionalità un po' più avanzata di qmake.
L'idea alla base è di compilare DownloadManagerCore, installarlo in una directory comune (con suffisso -debug o -release a seconda di come l'abbiamo compilata) e far puntare gli altri progetti a quella directory.
Per far questo dobbiamo aggiungere questa sezione a tutti i file di progetto (quindi DownloadManagerCore, DownloadManager e UnitTests):

win32 {

    build_pass:CONFIG(debug, debug|release)   { COMPILE_MODE='debug'   }

    else:build_pass                           { COMPILE_MODE='release' }

} else {

    CONFIG(debug, debug|release)   { COMPILE_MODE='debug' }

    else                           { COMPILE_MODE='release' }

Brevemente, viene assegnata una variabile COMPILE_MODE con un valore dipendente da come si compila il progetto corrente.
win32 viene gestito a parte perchè ho notato che COMPILE_MODE rimane vuota con la sintassi specificata nel ramo else.
Probabilmente dipende dal tipo di compilatore in uso, la sezione nel ramo win32 è stata testata su visual c++ 2010, probabilmente usando invece mingw non è ncessaria.
In ogni caso, provate a vedere se COMPILE_MODE viene popolata o meno usando l'istruzione

message("Using compile mode: $$COMPILE_MODE")

Adesso che abbiamo definito la variabile, proviamo ad usarla.
Nel progetto DownloadManagerCore aggiungiamo il path per l'installazione.

target.path='../static-libraries.bin/$$COMPILE_MODE'

INSTALLS += target

Questo farà in modo che eseguendo make install la libreria verrà copiata nella directory static-libraries.bin/debug (o release).
È consigliabile anche modificare i profili del progetto in qt creator: in "projects->build settings", tra i build steps, aggiungiamo al passo make l'argomento install. Questo per tutti i profili di DownloadManagerCore.
In questo modo, ad ogni build, la libreria statica verrà installata automaticamente.
Ora nei progetti DownloadManager e UnitTests andiamo ad usare questa nuova funzionalità. Molto semplicemente, la riga "LIBS+= ....." vista in precedenza, diventerà:

LIBS += -L../static-libraries.bin/$$COMPILE_MODE -lDownloadManagerCore

aggiungendola a DownloadManager dove non esisteva ancora.
Il modo migliore per verificare il risultato di quello che abbiamo fatto è cancellare tutte le directory di build, ricompilare da capo il progetto UnitTests (e naturalmente la sua dipendenza, DownloadManagerCore) e verificare che i test passino ancora.

Un' ultima ottimizzazione: risulta spesso utile in molti progetti avere una directory dove inserire script per automatizzare i task più frequenti, che spesso richiederebbero una serie di operazioni manuali non proprio comode. Creiamo quindi una directory "scripts". Che script possiamo scrivere per inaugurarla?
Beh, un primo task noioso e facilmente automatizzabile è la compilazione ed esecuzione automatica dei test: vogliamo uno script che sia in grado di compilare anzitutto il progetto DownloadManagerCore, installarlo nella directory static-libraries.bin, quindi compilare ed eseguire automaticamente i tests.

#!/bin/bash
set -e

PROJECTS="UnitTests"
COLORIZE_CMD="ccze -A"

MAIN_PROJECT="DownloadManagerCore"

BASE_DIRECTORY="$PWD/$( dirname $0)/.."
COMPILE_BUILD_PREFIX="$BASE_DIRECTORY/.build-"


if test "x$TERM" != "xxterm" || test "x$( which $( echo $COLORIZE_CMD | cut -d " " -f 1 ) )" == "x"; then #TODO add other terminals supported by ccze here
        COLORIZE_CMD="cat"
fi

if test "x$1" == "x--help"; then
        echo "Usage: $0 [Test-Project-Name [test-method-name]]"
        echo "It runs every project configured in the PROJECTS variable, or can select from parameters"
        echo "The variable MODE can be used to choose between debug and release compilation"
        echo "Currently supported test projects: $PROJECTS"
        exit 0
fi

if test "x$1" != "x"; then
        PROJECTS="$1"
        [ -f $PROJECTS ] && PROJECTS="$( basename "$( dirname "$PROJECTS")" )"
        echo "**** Project: $PROJECTS"
        shift
fi

BUILD_MODE="${MODE-debug}"

function buildProject() {
        project="$1"
        shift
        make_args="$1"
        shift
        #rm -rf "$project.build"
        mkdir -p "${COMPILE_BUILD_PREFIX}$project"
        cd "${COMPILE_BUILD_PREFIX}$project"
        qmake "CONFIG+=$BUILD_MODE silent" "DEFINES += QT_NO_DEBUG_OUTPUT" "$@" "../$project"
        make $make_args > /dev/null
        cd ..
}


function runTests() {
        suitename="$1"
        shift
        echo -e "Running suite $suitename\n"
        cd "${COMPILE_BUILD_PREFIX}$suitename"
        binary="./$suitename" 
        $binary $@ | while read line; do echo "$line" | $COLORIZE_CMD ; done
        ERRORS=${PIPESTATUS[0]}
        cd ..
        if test "x$ERRORS" == "x0"; then
                echo -e "\nSuite $suitename completed without errors\n"
        else
                echo -e "Suite $suitename finished with errors!\n"
                exit $ERRORS
        fi
}


buildProject $MAIN_PROJECT "all install"
for project in $PROJECTS; do
        buildProject $project "clean all" "LIBS+=-L../${COMPILE_BUILD_PREFIX}$MAIN_PROJECT" 
        runTests $project $@
done

Come al solito, i sorgenti per questa puntata sono disponibili sul mio account github.

Nella prossima puntata ci occuperemo invece di refactoring e ottimizzazioni del codice vero e proprio.

Test Driven Development, C++ e Qt: primi passi (e test)

2012-01-06T15:50:00.000+01:00

Dopo aver creato la struttura del progetto nella prima parte, cominciamo adesso ad implementare l'applicazione.
Guardiamo l'esempio di Qt da cui stiamo prendendo spunto: il main prende in ingresso la lista di downloads (usando QCoreApplication, che li converte automaticamente in una comoda QStringList), e, se la lista è vuota stampa le informazioni di utilizzo, uscendo.
Potremmo andare avanti ad analizzare le successive funzionalità, certo l'applicazione non si limita a far questo, ma il tdd ci impone di creare un primo test (che inizialmente fallisce), ed implementare la funzionalità facendo passare il test prima di procedere troppo oltre. In una applicazione così semplice, è meglio semplificare anche l'approccio evitando di pensar troppo al futuro.
L'esempio mette il messaggio di errore nel main. Così facendo però non potremmo testarlo. D'altro canto è proprio il main che costruisce la lista di argomenti. Un buon compromesso quindi è di creare un metodo download(const QStringList &arguments)* nella classe DownloadManagerCore che come risultato stampi le informazioni di utilizzo, usando gli argomenti creati da QCoreApplication.
Può inoltre aiutare molto far estendere QObject alla classe DownloadManagerCore; in questo modo si ottimizza la memoria (c++ non ha garbage collector, però ogni classe che estende QObject verrà automaticamente distrutta quando viene distrutta la classe parent) e si migliora l'iterazione con le classi che verranno usate, le quali saranno infatti a loro volta derivate da QObject.
Nel main.cpp invocheremo QCoreApplication per estrarre gli argomenti, e invocheremo DownloadManagerCore::download(arguments).

Proviamo quindi a scrivere il primo test. In particolare asseriremo che il metodo download stamperà su standard output (o meglio, su un output stream testabile), se la lista degli argomenti è vuota, la seguente stringa:

Usage: downloadmanager url1 [url2... urlN]

Downloads the URLs passed in the command-line to the local directory.If the target file already exists, a .0, .1, .2, etc. is appended to differentiate.

Creiamo quindi il test case itShouldPrintHelpMessageWithNoArguments.

void DownloadManagerCoreTest::itShouldPrintHelpMessageWithNoArguments()
{
    QString output;
    QTextStream outputStream(&output);
    DownloadManagerCore *lib = new DownloadManagerCore(&outputStream, this);
    lib->start(QStringList());
    QString expected("Usage: downloadmanager url1 [url2... urlN]\n");
    expected.append("Downloads the URLs passed in the command-line to the local directory.");
    expected.append(" If the target file already exists, a .0, .1, .2, etc. is appended to differentiate.\n");
    QCOMPARE(output, expected);
}

Al di là della funzionalità, di per se banale, notiamo un po' di cose importanti su come il test stia definendo in maniera molto precisa il design della classe:

Abbiamo bisogno di testare l'output. È quindi da evitare che la classe stampi direttamente l'output su schermo. Definiamo invece un costruttore che prende in ingresso un puntatore a QTextStream e facciamo delle asserzioni su quello. Lo stream di test, in particolare, sarà uno stream che scrive su una stringa anzichè su stdout.
Abbiamo anche bisogno di una entry point che riceva in ingresso gli argomenti. Definiamo quindi il metodo "start" nella classe DownloadManagerCore, il cui header diventerà quindi questo:

#ifndef DOWNLOADMANAGERCORE_H
#define DOWNLOADMANAGERCORE_H
#include <QObject>

class QTextStream;
class DownloadManagerCore : public QObject {
    Q_OBJECT
public:
    DownloadManagerCore(QTextStream *output);
    void start(const QStringList &arguments);
private:
    QTextStream *output;
};

#endif // DOWNLOADMANAGERCORE_H

Ho anche fatto estendere QObject a QDownloadManagerCore, in questo modo si potrà usare il meccanismo di auto-delete di Qt: se le classi del nostro progetto estendono QObject, e si assegna loro una classe "parent", le classi saranno automaticamente cancellate quando sarà cancellata la loro classe parent, senza nessun bisogno di cancellarle manualmente. In questo modo è possibile ridurre al minimo i rischi di memory leak, potendo assegnare alle classi uno scope ben preciso. Maggiori dettagli qui.

Naturalmente il nostro test non può ancora passare: abbiamo definito l'interfaccia della nostra classe, ma non l'implementazione.
Per avere un primo test verde basta usare lo stream per stampare in output l'help message, senza preoccuparci degli argomenti, dato che per il momento nessun test ne verifica l'utilizzo.

#include "downloadmanagercore.h"
#include <QTextStream>

DownloadManagerCore::DownloadManagerCore(QTextStream *output, QObject *parent)
    : QObject(parent), output(output)
{
}

void DownloadManagerCore::start(const QStringList &arguments)
{
    *output << "Usage: downloadmanager url1 [url2... urlN]" << endl;
    *output << "Downloads the URLs passed in the command-line to the local directory.";
    *output << " If the target file already exists, a .0, .1, .2, etc. is appended to differentiate." << endl;
}

E finalmente, barra verde!

********* Start testing of DownloadManagerCoreTest *********
Config: Using QTest library 4.7.4, Qt 4.7.4
PASS   : DownloadManagerCoreTest::initTestCase()
PASS   : DownloadManagerCoreTest::itShouldLinkToStaticLibrary()
PASS   : DownloadManagerCoreTest::itShouldPrintHelpMessageWithNoArguments()
PASS   : DownloadManagerCoreTest::cleanupTestCase()
Totals: 4 passed, 0 failed, 0 skipped
********* Finished testing of DownloadManagerCoreTest *********

La prossima volta vedremo di ottimizzare il nostro codice prima di aggiungere nuove funzionalità: refactoring, ma anche migliorie del layout del progetto e ottimizzazioni varie.
Qui il codice sorgente per questa puntata.

* la sintassi "const QString &arg" o "const QStringList &arg" è del tutto equivalente a specificare "QString arg". In genere però è molto meglio specificare il "const" e la "&", per ottimizzare le chiamate. In questo modo infatti i parametri saranno immutabili e passati esplicitamente per riferimento, anzichè ricopiate nel metodo, (occupando quindi più memoria e tempo cpu). Sono piccoli accorgimenti da memorizzare ed usare con costanza, che possono però migliorare di molto le prestazioni del proprio codice.

Test Driven Development, C++ e Qt: setup e layout progetto

2011-12-11T20:17:00.001+01:00

I metodi agili cominciano a prendere piede anche in italia, e con essi quello che è probabilmente il loro più conosciuto cavallo di battaglia: il TDD, ossia Test Driven Development. Uno dei linguaggi in cui il TDD viene più spesso è applicato è java: non solo perchè è uno dei più diffusi, ma probabilmente perchè offre allo sviluppatore degli strumenti veramente potenti: da JUnit, scritto proprio da Kent Beck, ad Eclipse, che oltre ad integrare un perfetto supporto a JUnit offre anche dei potentissimi strumenti per il refactoring, che è parte integrante di questa tecnica.
Ma per quanto riguarda altri linguaggi, come il vetusto ma sempre attuale C++? Come si può conciliare la "dinamicità" di un processo come il TDD alla macchinosità di un linguaggio che prevede costante sincronizzazione header-implementazione, build system non sempre amichevoli e pochissimi tool di refactoring?
In questa guida cercherò di offrire uno dei possibili approcci. Dovendo scegliere un IDE e un toolkit ho optato per Qt di Nokia (originariamente di Trolltech) e il suo IDE Qt Creator.
Ovviamente ognuno avrà le sue preferenze, il mondo del C++ è fin troppo ricco. Per quanto mi riguarda, da utente e sviluppatore KDE, conosco Qt da molti anni, lo trovo piuttosto semplice e intuitivo, e altrettanto può dirsi di Qt Creator, sicuramente non un IDE potente e pieno di strumenti come Eclipse, ma che ha dalla sua una notevole leggerezza, nonchè l'essere studiato proprio per Qt.
Qt offre un ambiente molto omogeneo, includendo anche un modulo per i test unitari. Sicuramente ci sono framework di testi anche migliori, ma per continuare sulla via della semplicità ho preferito usare QTest. Ha anche il non indifferente vantaggio di essere orientato al cross platform, il che vuol dire che un'applicazione o libreria creata con Qt girerà sui principali sistemi operativi (Windows, Mac, Linux) senza modificare (o quasi) il codice, ma solo ricompilando per i sistemi desiderati.

Disclaimer: non oso definirmi nè un esperto di C++ nè tantomeno di Qt. Ho imparato entrambi amatorialmente, e sono un po' arrugginito dai molti anni lavorativi in cui ho utilizzato quasi esclusivamente Java.

Come progetto di esempio prenderò spunto dal Download Manager presente nella documentazione di Qt. Si tratta di un eseguibile da riga di comando, senza GUI, anche molto semplice da realizzare.

Andiamo a creare il layout del nostro progetto.
Da QtCreator sceglieremo l'opzione "New Project", scegliendo tra i vari template disponibili "Qt C++ Project << Qt Console Application". Lo chiameremo "DownloadManager", e lo creeremo nella directory "$HOME/qt".
Il progetto verrà a trovarsi quindi in "DownloadManager", avrà un main pressochè vuoto.

Adesso cominciamo a creare le prime classi? Sbagliato. In realtà il progetto "DownloadManager" è praticamente già finito. Tutto il nostro codice andrà invece in una libreria statica: questo perchè dovrà essere accessibile anche dai test. Una libreria statica è molto diversa da una dinamica: essa non verrà infatti "esportata" come una dipendenza, ma viene inglobata dall'eseguibile, avendo però il vantaggio di poter condividere le proprie classi anche con i test che creeremo.
Quindi, nuovo progetto, con tipo "Other Project << C++ Library". Scegliamo nel wizard "Statically Linked Library", assegnamo come nome "DownloadManagerCore" e lo creiamo sempre nella posizione "$HOME/qt". Nella pagina successiva scegliamo di aggiungere i moduli "QtCore" e "QtNetwork". Il wizard creerà anche una classe principale (che potremo usare come un main) DownloadManagerCore.

Adesso è ora di creare il progetto (o come vedremo, i progetti) per i test, cominciando dagli unit: sempre dal menù nuovo progetto, scegliamo nuovamente "Other Project << Qt Console Application", con nome "UnitTests" e solita posizione, "$HOME/qt". Nel file UnitTests.pro creato dal wizard cambiamo la riga

   QT       += core

   QT       += core testlib

Col tasto destro sul progetto selezioniamo "Add New...", quindi scegliamo "C++ Class".
Diamo nome alla classe: "DownloadManagerCoreTest", base class "QObject".
Modifichiamo lo header creando un primo test come private slot:

#ifndef DOWNLOADMANAGERCORETEST_H
#define DOWNLOADMANAGERCORETEST_H

#include <QObject>

class DownloadManagerCoreTest : public QObject
{
    Q_OBJECT
public:
    explicit DownloadManagerCoreTest(QObject *parent = 0);

private slots:
    void itShouldLinkToStaticLibrary();

};

#endif // DOWNLOADMANAGERCORETEST_H

e anche la sua implementazione:

#include <QTest>

#include "downloadmanagercoretest.h"
#include "../DownloadManagerCore/downloadmanagercore.h"

DownloadManagerCoreTest::DownloadManagerCoreTest(QObject *parent) :
    QObject(parent)
{
}

void DownloadManagerCoreTest::itShouldLinkToStaticLibrary() {
    DownloadManagerCore *lib = new DownloadManagerCore();
    QVERIFY2(lib != NULL, "Library should not be null");
}

QVERIFY è una semplice asserzione che verifica il valore booleano passato come parametro.
QVERIFY2 aggiunge la possibilità di specificare un messaggio.
Questi sono un po' i "mattoncini base" per le asserzioni; ne esistono altre, ed è anche possibile implementarne di personalizzate.
Modificare anche il main.cpp come segue:

#include <QtCore/QString>
#include <QtTest/QTest>
#include <QList>

#include "downloadmanagercoretest.h"

class UnitTests : public QObject
{
    Q_OBJECT
private:
    int argc;
    char **argv;

public:
    UnitTests(int argc, char *argv[]);
    int runAll();
private:
    QList<QObject*> tests;
};

UnitTests::UnitTests(int argc, char *argv[])
    : argc(argc), argv(argv)
{
    tests << new DownloadManagerCoreTest(this);
}

int UnitTests::runAll() {
    int testResults=0;
    foreach(QObject *currentTest, tests) {
        testResults += QTest::qExec(currentTest, argc, argv);
    }
    return testResults;
}


int main(int argc, char *argv[])
{
    UnitTests testSuite(argc, argv);
    return testSuite.runAll();
}

#include "main.moc"

Aggiungere nuovi test alla suite è semplice, basta creare dei metodi (void) come "private slots" nelle classi di test.
Se vorremo aggiungere nuove classi di test alla test suite, basterà invece creare nuove classi del tutto simili a DownloadManagerCoreTest: molto semplicemente devono estendere QObject e tutti i metodi dichiarati "private slot" verranno automaticamente usati come test case.
Si deve poi includere lo header corretto nel main.cpp ed aggiungere una riga uguale all'esistente nel costruttore di UnitTests per aggiungere la classe di test alla suite.
Infine, le altre suite di test, come gli integration test e gli acceptance test, possono essere creati esattamente nello stesso modo del progetto UnitTests.

Ma che succede se proviamo ad eseguire il nostro primo test unitario?
Non compila nulla.. o per meglio dire, il link fallisce: questo perchè il nostro progetto di test non "vede" ancora il progetto contenente la classe "DownloadManagerCore". Come Fare?
Beh, basta aprire nuovamente il file "UnitTests.pro" ed aggiungere alla fine del file la riga

   LIBS += -L../DownloadManagerCore-build-desktop/ -lDownloadManagerCore

Visto che anche l'applicazione "DownloadManager" richiederà la libreria può essere utile aggiungere questa riga anche nel suo file .pro.
Può anche essere utile andare nel tab "Projects" di Qt Creator, e nei progetti "DownloadManager" e "UnitTests" selezionare come dipendenza (tab Dependencies) il progetto "DownloadManagerCore".

Adesso basta compilare il tutto per avere la suite di test funzionante:

********* Start testing of DownloadManagerCoreTest *********
Config: Using QTest library 4.7.4, Qt 4.7.4
PASS : DownloadManagerCoreTest::initTestCase()

PASS : DownloadManagerCoreTest::itShouldLinkToStaticLibrary()

PASS : DownloadManagerCoreTest::cleanupTestCase()
Totals: 3 passed, 0 failed, 0 skipped
********* Finished testing of DownloadManagerCoreTest *********

Alla prossima puntata!

p.s.: i sorgenti per questa versione del progetto potete trovarmi sul mio account github.

Leggibilità: meglio fuori che dentro

2011-11-26T00:05:00.000+01:00

Un argomento di cui recentemente si discute non poco nel nostro team è l'argomento leggibilità.
Premesso che la leggibilità è sempre un soggetto altamente personale, ciò che per me può essere perfettamente leggibile può non esserlo per altri, la mia opinione è che, dovendo scegliere, è sempre meglio preferire la leggibilità esterna di una classe, piuttosto che quella interna.

"Meglio fuori che dentro, dico sempre io"

Difatti, in teoria (specie se si vuole rispettare OCP), una classe dovrebbe essere modificata il meno possibile, e se scriviamo del buon design ben orientato agli oggetti è probabile che la classe stessa non sarà modificata mai, ma verranno solo aggiunte nuove implementazioni di interfacce a fronte di nuove funzionalità.
La leggibilità interna ha quindi un valore abbastanza relativo, basta cioè che sia sufficientemente leggibile da rispettare principi come avere metodi corti e ben definiti, pochi (meglio niente) cicli for e if statement innestati in cascata (ma piuttosto estratti in metodi), nessuna ambiguità su ingressi e uscite, meglio ancora se con un forte controllo sui tipi (per quanto in java i generics siano molto verbosi, preferisco usarli sempre e comunque quando servono, perchè offrono forti garanzie sulla correttezza dei tipi in uso).

Un esempio concreto: la classe sottostante effettivamente ha una leggibilità interna sufficiente, ma non esaltante.
Le classi inner e l'uso pesante di reflection (purtroppo inevitabile, dato lo scopo di questa classe) sicuramente confondono molto, e anche la gestione delle eccezioni ci mette il suo zampino.
E' anche vero però che la classe principale ha un costruttore privato, e l'unico modo di istanziarla è usando l'unico metodo pubblico disponibile: il metodo "search(enumClass)". Da lì, navigando il codice seguendo lo stack delle chiamate, è possibile seguire il flusso senza perdersi troppo, dato che le biforcazioni non sono molte.
Inoltre i metodi (così come le inner class) sono abbastanza compatti e focalizzati.
Si riesce a capire cosa fa questa classe? (in basso la risposta...)

package com.gmail.gulino.marco.utils;

import static com.google.common.collect.Iterables.find;
import static com.google.common.collect.Lists.newArrayList;

import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.util.List;

import com.google.common.base.Predicate;

@SuppressWarnings("unchecked")
public class SmartEnums<EnumType extends Enum<EnumType>> {

        public static <EnumType extends Enum<EnumType>> SmartEnums<EnumType> search(Class<EnumType> enumClass) {
                return new SmartEnums<EnumType>(enumClass);
        }

        private List<EnumType> allValues;

        private SmartEnums(Class<EnumType> enumClass) {
                try {
                        Method valuesMethod = enumClass.getMethod("values");
                        this.allValues = newArrayList((EnumType[]) valuesMethod.invoke(enumClass));
                } catch (Exception e) {
                        throw new RuntimeException("Are you trying to apply SmartEnums to a non enum class?");
                }
        }

        public MemberSearch byField(final String fieldName) {
                return new MemberSearch() {

                        @Override
                        protected Object findValueOn(EnumType enumType) throws Exception {
                                Field field = enumType.getClass().getDeclaredField(fieldName);
                                field.setAccessible(true);
                                return field.get(enumType);
                        }
                };
        }

        public MemberSearch byMethod(final String methodName) {
                return new MemberSearch() {

                        protected Object findValueOn(EnumType enumType) throws Exception {
                                Method method = enumType.getClass().getDeclaredMethod(methodName);
                                method.setAccessible(true);
                                return method.invoke(enumType);
                        }

                };
        }

        public abstract class MemberSearch {

                public EnumType havingValue(Object value) {
                        try {
                                return find(allValues, valueFinderPredicate(value));
                        } catch (Exception e) {
                                throw new RuntimeException(e);
                        }
                }

                protected abstract Object findValueOn(EnumType enumType) throws Exception;

                protected Predicate<EnumType> valueFinderPredicate(final Object value) {
                        return new Predicate<EnumType>() {
                                @Override
                                public boolean apply(EnumType enumType) {
                                        try {
                                                return value.equals(findValueOn(enumType));
                                        } catch (Exception e) {
                                                throw new RuntimeException(e);
                                        }
                                }
                        };
                }

        }
}

Certo, come ho già scritto prima la leggibilità interna non è esaltante...
Ma vediamo come viene utilizzata esternamente questa classe, nella fattispecie il suo unit test::

package com.gmail.gulino.marco.utils;

import static com.gmail.gulino.marco.utils.SmartEnums.search;
import static org.hamcrest.CoreMatchers.equalTo;
import static org.junit.Assert.assertThat;

import org.junit.Test;

public class SmartEnumsTest {
        @Test
        public void itShouldRetrieveEnumByField() throws Exception {
                assertThat(search(AnExampleEnum.class).byField("enumFieldToSearchFor").havingValue("first"), equalTo(AnExampleEnum.firstElement));
                assertThat(search(AnExampleEnum.class).byField("enumFieldToSearchFor").havingValue("second"), equalTo(AnExampleEnum.secondElement));
        }
        @Test
        public void itShouldRetrieveEnumByMethods() throws Exception {
                assertThat(search(AnExampleEnum.class).byMethod("enumMethodToSearchFor").havingValue("first"), equalTo(AnExampleEnum.firstElement));
                assertThat(search(AnExampleEnum.class).byMethod("enumMethodToSearchFor").havingValue("second"), equalTo(AnExampleEnum.secondElement));
        }

        public enum AnExampleEnum {
                firstElement("first"), secondElement("second");
                private final String enumFieldToSearchFor;

                private AnExampleEnum(String value) {
                        this.enumFieldToSearchFor = value;
                }

                public String enumMethodToSearchFor() {
                        return enumFieldToSearchFor;
                }

        }
}

Le assert sono chiare: traducendo letteralmente dall'inglese, abbiamo, mettendo tra parentesi le parole sottointese:

Asserisci (che la) ricerca (di) AnExampleEnum per field "enumFieldToSearchFor" avente valore "first" (sia) uguale a AnExampleEnum.firstElement

Le parole sottointese sono ben poche, è quindi evidente che fa la classe:

Ricerca una enum per field "nome del field" avente valore "valore da ricercare".

o, nella seconda delle due interfacce disponibili:

Ricerca una enum per metodo "nome del metodo" avente valore "valore da ricercare".

Ora, il vantaggio evidente è che gli utilizzatori di questa classe non dovranno scervellarsi troppo nel capirla, in effetti non avranno proprio alcun bisogno di aprire l'implementazione e leggerla. Basta solo leggere il suo test (o un eventuale altro utilizzo) per capire cosa fa e come va invocata.

FizzBuzz Game

2011-07-08T21:30:00.012+02:00

E dopo anni di silenzio, qualcosa da scrivere ogni tanto torna in mente...
Questa settimana abbiamo iniziato un nuovo progetto con il nostro team in XPeppers, l'azienda con cui collaboro da diversi anni.
La prima settimana l'abbiamo dedicata allo studio, approfondendo vari design pattern e tecniche per la programmazione orientata agli oggetti.

Un esercizio (ormai quasi un classico :P ) proposto dal nostro Coach, Matteo Vaccari, è di implementare il gioco del FizzBuzz. Brevemente, un'applicazione che dato un numero restituisce lo stesso numero; per multipli di certi numeri però sostituisce la stampa del numero con quella di determinate parole preimpostate.
Un esempio è che per multipli di due restituisce "Fizz", per multipli di tre "Buzz". Il numero "6" quindi restituirà la concatenazione, ovvero "FizzBuzz".

Chiaramente un'implementazione molto semplice potrebbe essere quella di creare una serie di blocchi IF per gestire i casi particolari.
Ovviamente non è scalabile, perchè all'aggiunta di nuove regole la serie di blocchi condizionali verrebbe a crescere in maniera sproporzionatamente complessa.
La sfida era quindi di scrivere con un design il più orientato ad oggetti possibile un algoritmo tutto sommato non semplicissimo (ad esempio, l'output è condizionato dalle regole precedenti).
Ecco la mia soluzione.
Il punto d'ingresso è game.java, che prende in costruzione tre oggetti: RulesBuilder, una factory che crea le regole con le giuste dipendenze, OutputBuilder, che si occupa di comporre i risultati delle regole (che sono a loro volta oggetti di tipo OutputAdder e non semplici stringhe) dando loro uno StringBuilder su cui scrivere del testo, e OutputPrinter, un'interfaccia di rendering su cui OutputBuilder stamperà la stringa risultante.
Le regole sono verificate dalla classe DividerRule; in questo caso si tratta di una classe concreta e ben specializzata; aggiungendo nuovi tipi di regole si potrebbe estrarre un'interfaccia comune.
Da notare che DividerRule ha la sola responsabilità di verificare l'applicarsi della condizione, ma non di scrivere o creare l'output; questa responsabilità è delegata alle singole implementazioni di OutputAdder.
Ad esempio, la DividerRule che deve controllare la divisibilità per 3 collaborerà con un AddToWordOutput istanziato per scrivere "Buzz". Lo stampare il numero senza sostituzioni è delegato a un caso particolare di OutputAdder: la DividerRule corrispondente viene sempre verificata, dato che viene istanziata per dividere per 1, mentre l'OutputAdder AddNumberIfOutputIsEmpty controlla che lo StringBuilder sia vuoto (ossia che le regole precedenti non hanno avuto successo) e in tal caso aggiunge il numero.
Altro caso particolare la divisibilità per 7: in questo caso PatatracAdder cancella tutto l'output delle regole precedenti e sostituisce il tutto con "Patatrac".

Il progetto così realizzato cerca di rispettare tutte le principali regole di buona programmazione: anzitutto SRP, dato che ogni classe è altamente specializzata ed ha una sola responsabilità; OCP, infatti per aggiungere nuove regole non serve modificare il codice esistente (a meno di stravolgimenti logici, ovviamente), ma è sufficiente implementare nuovi OutputAdder o eventualmente nuove Rules; Tell, don't ask, nessuna classe ha statement "return", quindi nessun oggetto chiede ad altri oggetti qualcosa, ma piuttosto comanda ai suoi collaboratori di eseguire qualcosa, ignorando i dettagli implementativi; infine l'architettura esagonale, ossia fare in modo che il dominio non abbia alcuna conoscenza del mondo esterno: difatti le classi di dominio non operano nessuna system.out, nè ritornano valori, piuttosto viene usata una generica interfaccia OutputPrinter, oltretutto non implementata se non nei test, e che potrebbe essere sostituita con una classe qualsiasi in grado di stampare su console, su web, su file.
Ovviamente sono anche rispettati i classici pattern come rimozione duplicazione e semplicità logica (pochi IF o cicli).

Sono graditi commenti :)

Merge Utilities (command line)

2009-12-03T12:51:00.002+01:00

This script helps you merging different branches on a project.
It offers some advantages:

It ignores whitespaces, so you don't have to care (too much) about formatting

it uses a single reject file, so you don't have to find .rej files in all your project for "debug" applying patch

It doesn't use backup files, so you can avoid polluting the project with .orig files too (who needs backup files, when you can do svn revert?)

It can accept both "r1234" and "1234" for revision number (useful for copy&paste from svn log)

Here's the code

#!/bin/bash
function helpMsg() {
 nextMsg="$1"
 echo "Usage: $(basename $0) <command>"
 echo "Available commands: "
 echo "° diff - creates a diff file (using svn diff) to compare different branches"
 echo "° patch - applies the previously created diff file"
 if test "x$nextMsg" != "x"; then
  echo -e "\n$nextMsg"
 fi
 echo ""
 exit 1
}

function doPatch() {
 if test "x$1" == "x" || ! [ -r "$1" ]; then
  helpMSG="Arguments for patch: <diff file> [optional arguments for patch]"
  helpMsg "$helpMSG"
 fi
 FILE="$1"
 shift
 patch -p0 --no-backup-if-mismatch -l -E --global-reject-file=cambiamentiRifiutati.rej -i "$FILE" $@
}

function doDiff() {
      REV1=$1
      REV2=$2
      FILE="$3"
      if test "x$1" == "x" || test "x$2" == "x" || test "x$3" == "x"; then
 helpMSG="Arguments for diff: <first revision> <second revision> <diff file> [optional arguments for svn diff]
Revision number format can either be r1234 or 1234"
 helpMsg "$helpMSG"
      fi
      shift; shift; shift
      #Sostituzione "r1234" con "1234" in modo da facilitare il cut&paste da svn log
      REV1="$( echo $REV1 | sed "s/r//g")"
      REV2="$( echo $REV2 | sed "s/r//g")"
      svn diff -r $REV1:$REV2 --diff-cmd=diff -x -uw $@ > "$FILE"
}

CMD=$1

if test "x$1" == "x"; then
 helpMsg
fi
shift
case $CMD in
 "diff")
 doDiff $@
 ;;
 "patch")
 doPatch $@
 ;;
 *)
 helpMsg
 ;;
esac

Estetica Bash

2008-08-21T11:32:00.004+02:00

Da così...

#!/bin/bash
found_in_application_xml=$(grep ProjectName /bea/one/9/923/apps/BEdomain/BHcluster/ear/h2o/BHapp/app/META-INF/application.xml)
if [ -n "$found_in_application_xml" ]; then
 echo "/bea/one/9/923/apps/BEdomain/BHcluster/ear/h2o/BHapp/app/META-INF/application.xml: OK"
else
 echo "/bea/one/9/923/apps/BEdomain/BHcluster/ear/h2o/BHapp/app/META-INF/application.xml: ProjectName not found"
 sed -i 's/<\/application>/<module><ejb>ejb\/ProjectName\/ejb20_BH_ProjectName_81.jar<\/ejb><\/module>\n<\/application>/' /bea/one/9/923/apps/BEdomain/BHcluster/ear/h2o/BHapp/app/META-INF/application.xml
fi
found_in_log4j=$(grep projectname /bea/one/9/923/system/BEdomain/BHcluster/log4j.properties)
if [ -n "$found_in_log4j" ]; then
 echo "/bea/one/9/923/system/BEdomain/BHcluster/log4j.properties: OK"
else
 echo "/bea/one/9/923/system/BEdomain/BHcluster/log4j.properties: projectname not found"
 echo "
log4j.appender.PROJECTNAME=org.apache.log4j.FileAppender
log4j.appender.PROJECTNAME.File=/log/projectname.log
log4j.appender.PROJECTNAME.layout=org.apache.log4j.PatternLayout
log4j.appender.PROJECTNAME.layout.ConversionPattern=[%t] [%d{DATE}] - %c -%p: %m%n
log4j.logger.it.sella.projectname=INFO, PROJECTNAME" >> /bea/one/9/923/system/BEdomain/BHcluster/log4j.properties
fi
found_in_integrazione_sistemi_esterni_properties=$(grep ProjectName /bea/one/9/923/system/BEdomain/BHcluster/subSystem.properties)
if [ -n "$found_in_integrazione_sistemi_esterni_properties" ]; then
 echo "/bea/one/9/923/system/BEdomain/BHcluster/subSystem.properties: OK"
else
 echo "/bea/one/9/923/system/BEdomain/BHcluster/subSystem.properties: ProjectName not found"
 echo "
#<ProjectName>
Service.SomeSystem.serviceType=ejb
Service.SomeSystem.xmlStrategy=./data/ProjectName/subsystem.xml
Service.TestSomeSystem.serviceType=ejb
Service.TestSomeSystem.xmlStrategy=./data/ProjectName/ise/ise_TestSomeSystem.xml
#</ProjectName>" >> /bea/one/9/923/system/BEdomain/BHcluster/subSystem.properties
fi
found_in_do_post_contabilizzazione_properties=$(grep projectname /bea/one/9/923/system/BEdomain/BHcluster/OtherSubSystem.properties)
if [ -n "$found_in_do_post_contabilizzazione_properties" ]; then
 echo "/bea/one/9/923/system/BEdomain/BHcluster/OtherSubSystem.properties: OK"
else
 echo "/bea/one/9/923/system/BEdomain/BHcluster/OtherSubSystem.properties: projectname not found"
 echo "
#<ProjectName>
DEB03=it.home.projectname.lib.Class
DEB05=it.home.projectname.lib.Class
#</ProjectName>
" >> /bea/one/9/923/system/BEdomain/BHcluster/OtherSubSystem.properties
fi

a così:

#!/bin/bash
PROJECTNAME="ProjectName"
BEADIR="/bea/one/9/923"

BH_JAR_NAME="ejb20_BH_${PROJECTNAME}_81.jar"
MODULEPATH="ejb/$PROJECTNAME/"

APPLICATION_XML="${BEADIR}/apps/BEdomain/BHcluster/ear/h2o/BHapp/app/META-INF/application.xml"

LOG4JFILE="${BEADIR}/system/BEdomain/BHcluster/log4j.properties"
DOPOSTFILE="${BEADIR}/system/BEdomain/BHcluster/OtherSubSystem.properties"
ISEFILE="${BEADIR}/system/BEdomain/BHcluster/subSystem.properties"



function searchIn() {
  FILE="$1"
  SUBSTRING="$2"
  GREPOPTS="$3 $4 $5 $6 $7 $8 $9"
  grep -q $GREPOPTS $SUBSTRING $FILE
  return
}

function stringForSed() {
  echo "${1//\//\\/}"
}

function addEjbModuleToXml() {
  MODULE=$1
  XMLFILE=$2
  APPLICATION_TAG="</application>"
  EJB_TAG="<module><ejb>$MODULE</ejb></module>"
  sed -i "s/$(stringForSed $APPLICATION_TAG)/$(stringForSed $EJB_TAG)\n$(stringForSed $APPLICATION_TAG)/g" $XMLFILE
}

function log4j_properties() {
  FILENAME="$1"
  cat >>"$FILE" <<EOF
log4j.appender.PROJECTNAME=org.apache.log4j.FileAppender
log4j.appender.PROJECTNAME.File=/log/projectname.log
log4j.appender.PROJECTNAME.layout=org.apache.log4j.PatternLayout
log4j.appender.PROJECTNAME.layout.ConversionPattern=[%t] [%d{DATE}] - %c -%p: %m%n
log4j.logger.it.sella.projectname=INFO, PROJECTNAME
EOF
}

function subSystem_properties() {
  FILENAME="$1"
  cat >>"$FILE" <<EOF
#<ProjectName>
Service.SomeSystem.serviceType=ejb
Service.SomeSystem.xmlStrategy=./data/ProjectName/subsystem.xml
Service.TestSomeSystem.serviceType=ejb
Service.TestSomeSystem.xmlStrategy=./data/ProjectName/ise/ise_TestSomeSystem.xml
#</ProjectName>
EOF
}

function OtherSubSystem_properties {
  FILENAME="$1"
  cat >>"$FILE" <<EOF
#<ProjectName>
DEB03=it.home.projectname.lib.Class
DEB05=it.home.projectname.lib.Class
#</ProjectName>
EOF
}


if ! searchIn "$APPLICATION_XML" "$BH_JAR_NAME"; then
  echo "Adding $BH_JAR_NAME in $APPLICATION_XML"
  addEjbModuleToXml "$MODULEPATH/$BH_JAR_NAME" $APPLICATION_XML
fi


for FILE in $LOG4JFILE $DOPOSTFILE $ISEFILE; do
  if ! searchIn "$FILE" $PROJECTNAME "-i"; then
    appenderName="$(basename "$FILE")"
    echo "Updating $FILE..."
    ${appenderName//./_} "$FILE"
  fi
done

Actions handler via filesystem monitoring

2008-07-17T19:53:00.005+02:00

Avendo avuto la necessità di eseguire degli script bash che eseguono il riavvio di servers Weblogic senza avere a disposizione una shell da cui lanciarli abbiamo pensato le più disparate possibilità, ivi compreso smanettare tutto il giorno sulla console di Weblogic, progettare applicazioni standalone jmx, pagine jsp apposite.. oggi pomeriggio mi sono reso conto che in realtà tutto ciò che serve è un crontab funzionante.
Basta creare uno script shell lanciato ripetutamente da quel crontab (tipo ogni minuto) e che controlla l'esistenza di determinati files per lanciare azioni ad essi associate (e cancellare il file che ha scatenato l'azione).
Durante qualche ritaglio di tempo nelle pause ecco cos'è uscito fuori:

#!/bin/bash                  

#ACTIONSDIR="/tmp/actions"
ACTIONSDIR="/nodel/actions"
ACTIONSCRIPTSDIR="$ACTIONSDIR/scripts"
ACTIONS="restart-admin restart-batch crontab"

function doAction() {
  action="$1"
  actionfile="$ACTIONSDIR/$action"
  actionscript="$ACTIONSCRIPTSDIR/${action}.sh"
  if [ -r $actionfile.lock ]; then return; fi
  echo "`date`: running action $action with script file $actionscript" > $actionfile.lock
  echo "doing action $action (script file: $actionscript)"
  chmod +x $actionscript
  $actionscript $action $actionfile
  rm $actionfile
  rm $actionfile.lock
}

function createDir() {
  dirToCreate=$1
  if [ -d $dirToCreate ]; then
      return
  fi
  mkdir -p $dirToCreate
}

createDir $ACTIONSDIR
createDir $ACTIONSCRIPTSDIR

for action in $ACTIONS; do
  actionfile=$ACTIONSDIR/$action
  if [ -r $actionfile ]; then
      doAction $action &
  fi
done

Un paio di commenti:

Per aggiungere/rimuovere azioni basta modificare la variabile ACTIONS e aggiungere gli script nella directory adeguata (specificata da ACTIONSCRIPTSDIR)
gli script vengono lanciati in maniera asincrona dal loop principale, ma in maniera sincrona nel doAction, in modo tale da cancellare il file di lancio solo dopo il termine dello script. Un file di lock impedisce di rilanciare l'azione se è ancora in esecuzione.
Il file di lancio viene passato come argomento (insieme al nome dell'azione) allo script. Questo permette di inserire un target come "crontab", che potrebbe essere usato per aggiornare il crontab appunto leggendo dal file di lancio il nuovo cron da installare.

Fast Scripting Tool

2008-07-12T10:42:00.005+02:00

Spesso per risolvere determinati problemi d'ordine quotidiano mi capita di creare piccolo script shell appositi, da buon maniaco della linea di comando.
La procedura per creare uno script può risultare relativamente noiosa: creare un file con touch, renderlo eseguibile con chmod, modificarlo col proprio editor preferito, specificare in cima l'interprete ("#!/bin/bash" di solito)... ed è sempre la stessa solfa, piuttosto pallosa.
Soluzione: mi sono scritto uno script bash per creare altri script bash.
Ho anche fatto in modo di parametrizzarlo: il primo parametro è lo script da creare, il secondo l'interprete (opzionale, se non specificato di default va su "/bin/bash".
Ecco lo script, da piazzare magari in /usr/local/bin in modo da averlo nel path:

#!/bin/bash
function usage() {
    echo "Usage: `basename $0` filename [interpreter path]"
    exit 0
}


if test "x$1" == "x"; then
    usage
fi

INTERPRETER="/bin/bash"

if test "x$2" != "x"; then
    if ! [ -r $2 ]; then
        echo "Error! Interpreter \"$2\"not found"
        usage
    else
        INTERPRETER="$2"
    fi
fi

cat >$1 <<EOF
#!$INTERPRETER

EOF

chmod +x $1
vim $1 +2

L'ultima riga in particolare apre vim, specificandogli anche su che riga piazzarsi.. per la precisione dopo la seconda, subito dopo la dichiarazione dell'interprete (così non si fa neanche la fatica di premere freccia-giù :P)

Paginazione in Oracle

2008-07-11T17:09:00.010+02:00

A differenza di database come MySQL, in oracle la paginazione dei dati non è così elementare..
Esiste un campo interno ROWNUM che in effetti numera le righe del risultato di una query.
Il problema però è che la numerazione inizia dopo l'invocazione di rownum, non prima, ergo un'espressione come:

select * from ourTable where rownum>2;

non può funzionare, perchè la prima riga (rownum=1) non verrà mai visualizzata, e di conseguenza rownum non verrà mai incrementato.
La soluzione è effettuare tre nested query: la prima con la query alla tabella da noi desiderata, la seconda che limita la finestra all'offset superiore della paginazione, la terza che forza il limite inferiore, trattando rownum come una normale colonna di una tabella.
Ecco come:

select * from
    (select ourTable.*, rownum rowN from
        (select * from ourTable
           where ourCondition=true
           order by ourColumn)
    where rownum <= maxPageOffset)
where rowN >= minPageOffset;

Reprise

2008-07-11T17:07:00.001+02:00

Essì prima o poi sarebbe anche il caso di tornare a scrivere qualcosa...

Vita Milanese

2008-01-20T22:41:00.000+01:00

Vita milanese si fa per dire...
Primi giorni chiuso in casa, vuoi per il freddo, vuoi per il raffreddore, vuoi perchè non ho nulla da fare fuori (e mi scoccia andare in tram a vuoto).

Però aspetto con ansia il 25.. Trio Bobo alla Salumeria della Musica :)
Non posso suonare il basso, ma almeno potrò ascoltare il mio bassista preferito :P