Remove duplications and fix bad names

When do you think a daily stand up is too crowded?

noreply@blogger.com (marcocast) — Wed, 15 May 2013 08:46:00 +0000

Recently, looking at the daily stand-ups in my company, it makes me smile a bit.

I think too many = chaos and dispersion.
Proper and efficient stand-ups should be 4 pigs and occasionally 2 or 3 chickens.

This is my opinion, what is yours?

Building smart Builders

noreply@blogger.com (marcocast) — Fri, 10 May 2013 16:20:00 +0000

When building an API, you should always think about who is going to use it.

When the API is simply and clear to use, then the users are happy. When the users are happy then everyone is happy too :).

But great usability is not always easy to achieve.

There are patterns that help on this, on this post I will focus on the classic builder pattern and how you can enhance it with the step builder pattern in order to build objects with a no brain interface, easy to use, impossible to get wrong.

So lets start painting some context, we have 2 domain objects representing a user configuration to connect to some remote or local server. When remote credentials are required, when local no.

package com.marco.sbp;
public class UserConfiguration {
        private final String name;
        private ServerDetails serverDetails;

        public UserConfiguration(String name) {
                this.name = name;
        }

        public void setServerDetails(ServerDetails serverDetails) {
                this.serverDetails = serverDetails;
        }

        public String getName() {
                return name;
        }

        public ServerDetails getServerDetails() {
                return serverDetails;
        }
}

package com.marco.sbp;
public class ServerDetails {

        private final String host;
        private String user;
        private String password;

        public ServerDetails(String host) {
                this.host = host;
        }

        public void setUser(String user) {
                this.user = user;
        }

        public void setPassword(String password) {
                this.password = password;
        }

        public String getHost() {
                return host;
        }

        public String getUser() {
                return user;
        }

        public String getPassword() {
                return password;
        }
}

We want to abstract the construction of the objects above using 2 different techniques, the classic builder pattern and the step builder pattern.

The classic builder pattern is pretty straightforward, it works masking the creation of the UserConfiguration and the ServerDetails using properly named methods like onLocalHost, onRemoteHost, etc.

package com.marco.sbp.builder;
import com.marco.sbp.ServerDetails;
import com.marco.sbp.UserConfiguration;
public class ClassicBuilder {
        
        private String name;
        private String host;
        private String user;
        private String password;

        
        public ClassicBuilder(String name){
                this.name = name;
        }
        
        public ClassicBuilder onLocalHost(){
                this.host = "localhost";
                return this;
        }
        
        public ClassicBuilder onRemoteHost(String remoteHost){
                this.host = remoteHost;
                return this;
        }
        
        
        public ClassicBuilder credentials(String user, String password){
                this.user = user;
                this.password = password;
                return this;
        }
        
        public UserConfiguration build(){
                UserConfiguration userConfiguration = new UserConfiguration(name);
                ServerDetails serverDetails = new ServerDetails(host);
                serverDetails.setUser(user);
                serverDetails.setPassword(password);                    
                userConfiguration.setServerDetails(serverDetails);
                return userConfiguration;
        }
}

The step builder pattern is still using smart names to construct the object, but it's exposing these methods only when needed using interfaces and proper encapsulation.

package com.marco.sbp.builder;
import com.marco.sbp.ServerDetails;
import com.marco.sbp.UserConfiguration;

/** "Step Builder" */
public class StepBuilder {
        public static NameStep newBuilder() {
                return new Steps();
        }

        private StepBuilder() {
        }

        public static interface NameStep {
                /**
                 * @param name
                 *            unique identifier for this User Configuration
                 * @return ServerStep
                 */
                ServerStep name(String name);
        }       

        public static interface ServerStep {
                /**
                 * The hostname of the server where the User Configuration file is stored will be set to "localhost".
                 * 
                 * @return BuildStep
                 */
                public BuildStep onLocalhost();

                /**
                 * The hostname of the server where the User Configuration file is stored.
                 * 
                 * @return CredentialsStep
                 */
                public CredentialsStep onRemotehost(String host);
        }

        public static interface CredentialsStep {
                /**
                 * Username required to connect to remote machine Password required to connect to remote machine
                 * 
                 * @return BuildStep
                 */
                public BuildStep credentials(String user, String password);
        }

        public static interface BuildStep {
                /**
                 * @return an instance of a UserConfiguration based on the parameters passed during the creation.
                 */
                public UserConfiguration build();
        }

        private static class Steps implements NameStep, ServerStep, CredentialsStep, BuildStep {

                private String name;
                private String host;
                private String user;
                private String password;

                public BuildStep onLocalhost() {
                        this.host = "localhost";
                        return this;
                }
                
                public ServerStep name(String name) {
                        this.name = name;
                        return null;
                }

                public CredentialsStep onRemotehost(String host) {
                        this.host = host;
                        return this;
                }

                public BuildStep credentials(String user, String password) {
                        this.user = user;
                        this.password = password;
                        return this;
                }

                public UserConfiguration build() {
                        UserConfiguration userConfiguration = new UserConfiguration(name);
                        ServerDetails serverDetails = new ServerDetails(host);
                        serverDetails.setUser(user);
                        serverDetails.setPassword(password);                    
                        userConfiguration.setServerDetails(serverDetails);
                        return userConfiguration;
                }

                
        }
}

Lets see now what is the user experience with both of our builders.

The classic builder will be constructed using the name of the user configuration, then it will expose all of its methods leaving the user a bit too free to choose what's next.

For example, a not careful user could end up with a UserConfiguration set with localhost where no authentication is required, still passing user and password.

This is confusing and it can lead to run-time exceptions.

These are some of the possible combinations of UserConfigurations that the user can end up with, some are correct, lots are wrong:

A complete different story is with the step builder, here only one step at the time is exposed:

If the credentials are not needed they will not be exposed and the build() method is offered only when the state of the object is sure to be coherent and complete:

Only 2 possible UserConfigurations can be built with this pattern, and both make sense and are clear to the user.

Conclusion

The step builder pattern is not the replacement of the classic Bloch one, sometimes you want to force the user to fill some parameter before advancing with the creation, in this case the step builder is doing the job, otherwise when a more open approach is required than the classic builder is your guy.

Even in the jdk there is bad code.

noreply@blogger.com (marcocast) — Sun, 28 Apr 2013 15:02:00 +0000

Java 7, TreeSet and NullPointerException.

Recently I tried to compile with java 7 a project developed with java 6.

Lot of fun happened during tests execution, tests that in java 6 were running smoothly, with java 7, they were strangely failing!
So, I had to understand why and this is what I discovered...

The context first:
In that project I have a simple Hibernate Entity more or less like the following.

package com.marco.test;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Table;
import javax.persistence.UniqueConstraint;
import org.hibernate.validator.NotNull;
@Entity
@Table(...)
public class ABean {
        
        ...
        
        private String name;

        @Column(name = "name", nullable = false)
        @NotNull
        public String getName() {
                return name;
        }

        public void setName(String name) {
                this.name = name;
        }
}

note that the field "name" is nullable=false and marked with @NotNull.
This to tell Hibernate to fail the validation in the case a user tries to create or update this column to Null.

I also have a comparator for that Entity.
This comparator uses the name field to compare the Entity ( this is just a simplified version of what I have in the project, of course I don't order a bean based on the string length :) )

package com.marco.test;
import java.util.Comparator;
public class ABeanComparator implements Comparator<ABean> {

        @Override
        public int compare(ABean o1, ABean o2) {
                if (o1.getName().length() > o2.getName().length()) {
                        return 1;
                } else if (o1.getName().length() < o2.getName().length()) {
                        return -1;
                } else {
                        return 0;
                }
        }
}

note that there is no null check on the field name, in my project, Hibernate is already taking care of it.

Now, I have a test that create one empty Entity and it stores it into a TreeSet, and then doees other stuff that we do not really care here.
The beginning of the test is similar to the code below:

package com.marco.test;
import java.util.SortedSet;
import java.util.TreeSet;
public class SortedTestTest {

        public static void main(String[] args) {

                ABean aBean = new ABean();

                SortedSet<ABean> sortedSet = new TreeSet<ABean>(new ABeanComparator());

                sortedSet.add(aBean);
        }
}

If I run this with java 6, everything is OK.

But, with java 7 I have a NullPointerException.

Exception in thread "main" java.lang.NullPointerException
        at com.marco.test.ABeanComparator.compare(ABeanComparator.java:9)
        at com.marco.test.ABeanComparator.compare(ABeanComparator.java:1)
        at java.util.TreeMap.compare(TreeMap.java:1188)
        at java.util.TreeMap.put(TreeMap.java:531)
        at java.util.TreeSet.add(TreeSet.java:255)
        at com.marco.test.SortedTestTest.main(SortedTestTest.java:14)

Why?

This is why:

    public V put(K key, V value) {
        Entry<K,V> t = root;
        if (t == null) {
            compare(key, key); // type (and possibly null) check

            root = new Entry<>(key, value, null);
            size = 1;
            modCount++;
            return null;
        }

In java 7 when the first Object is added ( if (t == null) ) to a TreeSet, a compare against itself (compare(key,key)) is executed.

The compare method will then call the comparator (if there is one) and we will have the NullPointerException on the name property.

    // Little utilities

    /**
     * Compares two keys using the correct comparison method for this TreeMap.
     */
    final int compare(Object k1, Object k2) {
        return comparator==null ? ((Comparable<? super K>)k1).compareTo((K)k2)
            : comparator.compare((K)k1, (K)k2);
    }

This raises more questions than answers:

Why running a compare if you know that the Object in the TreeSet is the first and only one ?

My guess is that what they wanted to do was running a simple Null check.

Why not create a proper null check method ?

No Answer

Why wasting CPU and memory running a comparison that is not needed ?

No Answer

Why compare an object against itself (compare(key,key))??

No Answer

This is the put method of the TreeSet in java 6 and as you can see the compare was commented out.

public V put(K key, V value) {
                Entry<K, V> t = root;
                if (t == null) {
                        // TBD:
                        // 5045147: (coll) Adding null to an empty TreeSet should
                        // throw NullPointerException
                        //
                        // compare(key, key); // type check
                        root = new Entry<K, V>(key, value, null);
                        size = 1;
                        modCount++;
                        return null;
                }

You see the comment? Adding null to an empty TreeSet should throw NullPointerException
So just check if key is null, don't run a useless comparison!

The conclusion? Always try to analyze the code you use, because even in the jdk there is bad code!

How to update apt-get repositories in your old Linux distribution?

noreply@blogger.com (marcocast) — Fri, 22 Mar 2013 10:15:00 +0000

Are you using a Linux distribution that is really old?.
The apt-get repositories for the distribution are not supported anymore, but you would like to update the repositories so that you can install new packages?

Cool, so here it's how to do that:

You need to update /etc/apt/sources.list with new (valid) urls. e.g. in Ubuntu 11.04 (Maverick, no longer supported) you might want to update the URLs to (for example) "oneiric". You might have to do the following:

1) Backup /etc/apt/sources.list

2) Find and replace (inline) the old distro name ("maverick" in this example) with the new one ("oneiric" in this example)

3) Update apt-get cache to see the changes reflected.

sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup
sudo sed -i 's/maverick/oneiric/g' /etc/apt/sources.list
sudo apt-get update

And that's it, make sure the replaced sources.list file has the same permissions as the original one and bear in mind that you might want to use "sudo" since /etc/apt is usually owned by root.

Easy testing SLAs on distributed components with grep4j

noreply@blogger.com (marcocast) — Wed, 27 Feb 2013 22:18:00 +0000

So your distributed architecture looks something like the picture below and you just have received a requirement from the business to make sure that the SLAs of the messages sent by the Producer and then traveling to the downstream systems (consumers) must be fast and never slower than 400 milliseconds.

Requirement says :
The Latency of a message sent from the Producer to any of the Consumers should be never slower than 400 milliseconds.

Sounds familiar? To me yes, and experience taught me that if I want to protect the SLAs in the future, I need as well to automate the test in order to not introduce bottlenecks that then increase the latency of the messages.

But how to do it? Producer and Consumers are in separate machines and some of the consumers are not written in Java.
Also, between the producer and the consumers there is a Queue (or web-service or RMI or an ESB or another component or whatever), so things are not getting easier for me to test.

Well, all components write logs in a similar way, so why not using logs as a data to test?

For example these are 2 sample logs, one from the producer firing a message (id 1546366) and the other from one of the consumer receiving the message (id 1546366):

Producer logs

......

2013-02-19 10:09:05,795 INFO [org.grep4j.demo.input.core.InputCoreMessageSender] (pool-19-thread-9) Input::MessageSender::Message(1546366) Sent Successfully

......

Consumer logs

.....

2013-02-19 10:09:06,161 INFO [org.grep4j.demo.handler.bean.mdb.SingleDestPacketHandler] (Thread-62314 (HornetQ-client-global-threads-989457197)) Handler::Packet::Message(1546366) Received::PacketId(982336426)::State(NORMAL)::Dest(CONSUMER4, 1)::DataLevel(EVENT, 7)::Op(CREATE, C)::GlobalId(1546366)::Priority(1)::Src(GUI, 1::Ids(EventId=1546366,SFBId=1546366,isBirType=false,inBir=false))

.....

And this is how my automated performance test looks like using Grep4j :

package com.gdg.grep4j.demo;
import static com.gdg.grep4j.demo.profiles.Profiles.consumer1;
import static com.gdg.grep4j.demo.profiles.Profiles.consumer2;
import static com.gdg.grep4j.demo.profiles.Profiles.consumer3;
import static com.gdg.grep4j.demo.profiles.Profiles.producer;
import static com.gdg.grep4j.demo.services.TimeService.extractTime;
import static org.grep4j.core.Grep4j.constantExpression;
import static org.grep4j.core.Grep4j.grep;
import static org.grep4j.core.fluent.Dictionary.on;
import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.number.OrderingComparison.lessThan;
import static org.junit.Assert.assertThat;
import org.grep4j.core.result.GrepResults;
import org.testng.annotations.BeforeTest;
import org.testng.annotations.Test;
@Test
public class MessageDistributionPerformanceTest {


        private static final long MAX_ACCETABLE_LATENCY = 400L;

        private long producerTime = 0;

        private GrepResults consumersResults;
        
        @BeforeTest
        public void triggerMessageDispatcher() {
                System.out.println("Producing and firing a Message(1546366) to downstream systems...");
        }
        
        @BeforeTest
        public void extractProducerTime() {
                
                GrepResults producerResult = grep(constantExpression("Message(1546366) Sent Successfully"),     on(producer));
                producerTime = extractTime(producerResult.toString());
        }
        
        @BeforeTest
        public void grepConsumerLogs() {
                                
                consumersResults = grep(constantExpression("Message(1546366) Received"),
                                on(consumer1, consumer2, consumer3));
        }

        public void testConsumer1Latency() {
 
                long consumer1Time = extractTime(consumersResults.filterOnProfile(consumer1).toString());
                assertThat((consumer1Time - producerTime),
                                is(lessThan(MAX_ACCETABLE_LATENCY)));
        }

        public void testConsumer2Latency() {

                long consumer2Time = extractTime(consumersResults.filterOnProfile(consumer2).toString());
                assertThat((consumer2Time - producerTime),
                                is(lessThan(MAX_ACCETABLE_LATENCY)));

        }

        public void testConsumer3Latency() {

                long consumer3Time = extractTime(consumersResults.filterOnProfile(consumer3).toString());
                assertThat((consumer3Time - producerTime),
                                is(lessThan(MAX_ACCETABLE_LATENCY)));

        }
}

A profile is the grep target context, in my case all the profiles are remote machines (for a better understanding of Profiles see Grep4j page).

TimeService is just a simple service class extracting the time in the logs.

package com.gdg.grep4j.demo.services;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.TimeZone;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class TimeService {

        private static final Pattern timePattern = Pattern
                        .compile("([0-9][0-9][0-9][0-9])-([0-9][0-9])-([0-9][0-9]) ([0-9][0-9]|2[0-3]):([0-9][0-9]):([0-9][0-9]),([0-9][0-9][0-9])");

        public static long extractTime(String text) {
                Matcher lm = timePattern.matcher(text);
                if (lm.find()) {
                        SimpleDateFormat sdf = new SimpleDateFormat(
                                        "yyyy-MM-dd HH:mm:ss,SSS");
                        sdf.setTimeZone(TimeZone.getTimeZone("UTC"));

                        String inputString = lm.group();

                        Date date = null;
                        try {
                                date = sdf.parse(inputString);
                        } catch (ParseException e) {
                                e.printStackTrace();
                        }
                        return date.getTime();

                } else {
                        throw new IllegalArgumentException("timePattern not found");
                }
        }
}

In few simple lines of code I have my extremely flexible test (I can test anything that was produced in the logs) .

For the full code : https://github.com/marcocast/grep4j-gdg.git

9 Must read books for developers by Uncle Bob Martin

noreply@blogger.com (marcocast) — Mon, 25 Feb 2013 15:42:00 +0000

Last week Uncle Bob Martin gave a speech in my company about Components and Architecture.
Needless to say it was a great pleasure and fun to listen to him.
At the end of the speech, during the Q&A, a guy asked him which books he considers to be a must in order to improve your dev skills, so here we go with the 9 books a developer should read in his career:

Hope you will have some free time to read these fundamental books!

Note on the picture : I was lucky enough to capture him passing in front of a slide of my opensource library at some point during the speech :)

Baobab to analyse remote disk space

noreply@blogger.com (marcocast) — Thu, 21 Feb 2013 16:00:00 +0000

I just discovered this nice tool to analyze the disk space usage in local or more important, in remote pc.
Baobab is a graphical, menu-driven application to analyse disk usage in any Gnome environment.

This is how my Downloads folder looks like using Baobab

Baobab uses ssh to obtain the data it needs and you can launch it with :

ssh user@url -Y baobab

So you can check easily when some of the remote machines you are working with, is complaining about disk space!

ApacheBench - A quick n' easy performance test for your REST applications

noreply@blogger.com (marcocast) — Tue, 19 Feb 2013 09:20:00 +0000

ApacheBench is only useful for benchmarking POST or GET requests but is quick to set up and gives details results.

ab – ApacheBench is should be installed by default on Ubuntu

Example:

ab -n 100 -T 'application/xml' -A 'user:password' -p customer.xml -d http://172.18.48.67:8080/ws/1.1.1/resources/customers

-n number of requests

-c number of threads

-T content-type

-A authentication

-p POST filename

The output:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 172.18.48.67 (be patient).....done

Server Software: Apache-Coyote/1.1

Server Hostname: 172.18.48.67

Server Port: 8080

Document Path: /ws/1.1.1/resources/customers

Document Length: 1035 bytes

Concurrency Level: 1

Time taken for tests: 660.109 seconds

Complete requests: 100

Failed requests: 0

Write errors: 0

Total transferred: 132700 bytes

Total POSTed: 79000

HTML transferred: 103500 bytes

Requests per second: 0.15 [#/sec] (mean)

Time per request: 6601.087 [ms] (mean)

Time per request: 6601.087 [ms] (mean, across all concurrent requests)

Transfer rate: 0.20 [Kbytes/sec] received

0.12 kb/s sent

0.31 kb/s total

Connection Times (ms)

min mean[+/-sd] median max

Connect: 0 0 1.2 0 11

Processing: 5363 6601 810.4 6590 8179

Waiting: 5362 6600 810.2 6590 8178

Total: 5363 6601 810.3 6590 8179

Pool of ssh connections using Apache KeyedObjectPool

noreply@blogger.com (marcocast) — Mon, 11 Feb 2013 17:08:00 +0000

I found the org.apache.commons.pool extremely useful and robust, but not well documented.

So, I'll try to help a bit here explaining how to use an Apache KeyedObjectPool.

What is a KeyedObjectPool?

It's a map that contains a pool of instances of multiple types. Each type may be accessed using an arbitrary key.

In this example I'll create a pool of JSch ssh connections and I will use a simple getter setter object called ServerDetails as a key.

Basically for each server I want to have a pool of 10 reusable ssh connections.

So first thing to do is to create a Sessionfactory, a class in charge of creating the actual object you want to store in the pool. In our example that would be an ssh connection.

Sessionfactory needs to extend the BaseKeyedPoolableObjectFactory<K,V> where K is the type of keys in this pool and V is the type of objects held in this pool.

All you need to do is implement the makeObject method where you need to actually create the object in the pool and destroyObject where obviously you need to implement the code when the object is released and put back in the pool.

package org.grep4j.core.command.linux;
import org.apache.commons.pool.BaseKeyedPoolableObjectFactory;
import org.grep4j.core.model.ServerDetails;
import com.jcraft.jsch.JSch;
import com.jcraft.jsch.Session;
import com.jcraft.jsch.UserInfo;
/**
 * This class is used to handle ssh Session inside the pool.
 * 
 * @author Marco Castigliego
 *
 */
public class SessionFactory extends BaseKeyedPoolableObjectFactory<ServerDetails, Session> {

        /**
         * This creates a Session if not already present in the pool.
         */
        @Override
        public Session makeObject(ServerDetails serverDetails) throws Exception {
                Session session = null;
                try {
                        JSch jsch = new JSch();
                        session = jsch.getSession(serverDetails.getUser(), serverDetails.getHost(), serverDetails.getPort());
                        session.setConfig("StrictHostKeyChecking", "no"); // 
                        UserInfo userInfo = new JschUserInfo(serverDetails.getUser(), serverDetails.getPassword());
                        session.setUserInfo(userInfo);
                        session.setTimeout(60000);
                        session.setPassword(serverDetails.getPassword());
                        session.connect();
                } catch (Exception e) {
                        throw new RuntimeException(
                                        "ERROR: Unrecoverable error when trying to connect to serverDetails :  " + serverDetails, e);
                }
                return session;
        }

        /**
         * This is called when closing the pool object
         */
        @Override
        public void destroyObject(ServerDetails serverDetails, Session session) {
                session.disconnect();
        }
}

Second thing you need to do, is to create the actual keyed pool Object. In our example we create a singleton that holds a StackKeyedObjectPool.
The number 10 is a cap on the number of "sleeping" instances in the pool.
If 11 clients try to obtain an ssh connection for the same server, the 11th will wait until one of the first 10 will release his connection.

package org.grep4j.core.command.linux;
import org.apache.commons.pool.KeyedObjectPool;
import org.apache.commons.pool.impl.StackKeyedObjectPool;
import org.grep4j.core.model.ServerDetails;
import com.jcraft.jsch.Session;
/**
 * Pool controller. This class exposes the org.apache.commons.pool.KeyedObjectPool class.
 * 
 * @author Marco Castigliego
 *
 */
public class StackSessionPool {

        private KeyedObjectPool<ServerDetails, Session> pool;

        private static class SingletonHolder {
                public static final StackSessionPool INSTANCE = new StackSessionPool();
        }

        public static StackSessionPool getInstance() {
                return SingletonHolder.INSTANCE;
        }

        private StackSessionPool()
        {
                startPool();
        }

        /**
         * 
         * @return the org.apache.commons.pool.KeyedObjectPool class
         */
        public KeyedObjectPool<ServerDetails, Session> getPool() {
                return pool;
        }

        /**
         * 
         * @return the org.apache.commons.pool.KeyedObjectPool class
         */
        public void startPool() {
                pool = new StackKeyedObjectPool<ServerDetails, Session>(new SessionFactory(), 10);
        }
}

How to use it, it's simple and straightforward.
To obtain a ssh connection from the pool, we just need to call :

StackSessionPool.getInstance().getPool().borrowObject(serverDetails)

where serverDetails is our key (we want a pool of ssh connections per server).

When the connection is not needed anymore we put it back on the pool with :

StackSessionPool.getInstance().getPool().returnObject(serverDetails, session);

package org.grep4j.core.command.linux;

import org.grep4j.core.command.ExecutableCommand;
import org.grep4j.core.model.ServerDetails;
import com.jcraft.jsch.Channel;
import com.jcraft.jsch.ChannelExec;
import com.jcraft.jsch.Session;
/**
 * The SshCommandExecutor uses the net.schmizz.sshj library to execute remote
 * commands.
 * 
 * <ol>
 * <li>Establish a connection using the credential in the {@link serverDetails}</li>
 * <li>Opens a session channel</li>
 * <li>Execute a command on the session</li>
 * <li>Closes the session</li>
 * <li>Disconnects</li>
 * </ol>
 * 
 * @author Marco Castigliego
 * 
 */
public class JschCommandExecutor extends CommandExecutor {

        public JschCommandExecutor(ServerDetails serverDetails) {
                super(serverDetails);
        }

        @Override
        public CommandExecutor execute(ExecutableCommand command) {
                Session session = null;
                Channel channel = null;
                try {

                        session = StackSessionPool.getInstance().getPool()
                                        .borrowObject(serverDetails);
                        //...do stuff
                } catch (Exception e) {
                        throw new RuntimeException(
                                        "ERROR: Unrecoverable error when performing remote command "
                                                        + e.getMessage(), e);
                } finally {
                        if (null != channel && channel.isConnected()) {
                                channel.disconnect();
                        }
                        if (null != session) {
                                try {
                                        StackSessionPool.getInstance().getPool()
                                                        .returnObject(serverDetails, session);
                                } catch (Exception e) {
                                        e.printStackTrace();
                                }
                        }
                }

                return this;
        }
}

Remember to close the pool when you don't need it anymore with
StackSessionPool.getInstance().getPool().close();

Hope this will clarify a bit this extremely helpful and robust Apache API.

Monitoring the GC

noreply@blogger.com (marcocast) — Tue, 29 Jan 2013 11:05:00 +0000

GCHisto for Offline Analysis of Garbage Collection Data

GCHisto is a tool designed to do offline analysis, it’s free and it’s hosted on http://java.net/projects/gchisto.

To run it you need to download it, cd into gchisto folder and type:

sudo ant run

You can then load any gc log file and this tool will give you a visual view on the log.

The tab “GC Pause stats” will help you to identify the duration of the young and full GC action.
The overhead column is useful to identify how good your GC is tuned. Documentations says that a concurrent GC should be less than 10% overhead (ideal is 1% or less). If it’s above 10% it may required some tuning (increase the heap space can be one).

It will also provide useful graphs which are always better and less boring the raw data:

The GC Pause Distribution is used to analyse how many pauses occurs and how they are distributed:

a more detailed guide on all the gchisto features can be found here : http://sysadminsjourney.com/2008/09/15/profile-gc-with-gchisto/

—————————————————————-

Visual GC plugin + VisualVM for Live Analysis of Garbage Collection Data

In case you want to monitor what’s happening in the GC in real time you can use the visualVM that come together with your jdk.

To run it just type

jvisualvm

To add the viusualGC click on Tools–>Plugins–>Available plugins and select and install Visual GC

Restart visual VM.

With the basic VisualVM you can monitor memory usage, CPU consumption and how the Threads behave. The visual GC gives you a realtime view on the 3 heap memory spaces usage.

As you can see, a full and immediate vision on the Permanent, old and young space is given, helping a lot during analysis.

You can use this tool locally without any other required step, but it’s also possible to monitor remote VM (UAT,SYS,etc) using the jstatd deamon provided by java in sdk (same place where the jvisualvm is).
The jstatd daemon launches a Java RMI server application that watches for the creation and termination of HotSpot VMs and provides an interface to allow remote monitoring tools such as VisualVM to attach and monitor Java applications remotely, here is how to use it and configure it : http://docs.oracle.com/javase/6/docs/technotes/tools/share/jstatd.html

Hope this will help you a bit guys!

ExecutorService VS CompletionService VS normal loop

noreply@blogger.com (marcocast) — Mon, 14 Jan 2013 11:15:00 +0000

This is to show the difference between handling jobs with a pure ExecutorService VS a CompletionService VS a normal loop.

The CompletionServiceTest class simply prints numbers at predefined intervals ( waittime = 200 that simulates a work done by the thread, for example reading or parsing a file or run calculations, etc).

We do the same job in 3 different ways and we print the result together with the total execution time.

import java.util.Arrays;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import java.util.concurrent.Callable;
import java.util.concurrent.CompletionService;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorCompletionService;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
public class CompletionServiceTest {

        private static final int waittime = 200;
        private static final int numberOfThreadsInThePool = 3;

        private final List<String> printRequests = Arrays.asList("1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                        "1", "2", "3", "4", "5", "6", "7", "8", "9", "10"
                        );

        void normalLoop() {
                for (String image : printRequests) {
                        try {
                                Thread.sleep(waittime);
                        } catch (InterruptedException e) {
                                e.printStackTrace();
                        }
                        System.out.print(image);
                }
        }

        void normalExecutorService() {
                ExecutorService executor = Executors.newFixedThreadPool(numberOfThreadsInThePool);
                try {
                        Set<Future<String>> printTaskFutures = new HashSet<Future<String>>();
                        for (final String printRequest : printRequests) {
                                printTaskFutures.add(executor.submit(new Printer(printRequest)));
                        }
                        for (Future<String> future : printTaskFutures) {
                                System.out.print(future.get());

                        }
                } catch (Exception e) {
                        Thread.currentThread().interrupt();
                } finally {
                        if (executor != null) {
                                executor.shutdownNow();
                        }
                }
        }

        void completionService() {
                ExecutorService executor = Executors.newFixedThreadPool(numberOfThreadsInThePool);
                CompletionService<String> completionService = new ExecutorCompletionService<String>(executor);
                for (final String printRequest : printRequests) {
                        completionService.submit(new Printer(printRequest));
                }
                try {
                        for (int t = 0, n = printRequests.size(); t < n; t++) {
                                Future<String> f = completionService.take();
                                System.out.print(f.get());
                        }
                } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                } catch (ExecutionException e) {
                        Thread.currentThread().interrupt();
                } finally {
                        if (executor != null) {
                                executor.shutdownNow();
                        }
                }

        }

        private class Printer implements Callable<String> {

                private final String toPrint;

                public Printer(String toPrint) {
                        this.toPrint = toPrint;
                }

                public String call() {
                        try {
                                Thread.sleep(waittime);
                        } catch (InterruptedException e) {
                                e.printStackTrace();
                        }
                        return toPrint;
                }
        }

        public static void main(String[] args) {
                System.out.println("Normal Executor Service");
                long start = System.currentTimeMillis();
                new CompletionServiceTest().normalExecutorService();
                System.out.println();
                System.out.println("Execution time : " + (System.currentTimeMillis() - start));

                System.out.println("Completion Service");
                start = System.currentTimeMillis();
                new CompletionServiceTest().completionService();
                System.out.println();
                System.out.println("Execution time : " + (System.currentTimeMillis() - start));

                System.out.println("Normal Loop");
                start = System.currentTimeMillis();
                new CompletionServiceTest().normalLoop();
                System.out.println();
                System.out.println("Execution time : " + (System.currentTimeMillis() - start));

        }
}

The output :

Normal Executor Service
4865447106310711038976137104163378132553196955489824610105761329674254896133105110752911167871022184410147885282715959248479622229673310496981056331010958
Execution time : 9410
Completion Service
1234567891012345678910123456789101234567891012345678109123456789101234567891012345678910123456789101235647891012345678910123456789101234568791012435687109
Execution time : 9405
Normal Loop
1234567891012345678910123456789101234567891012345678910123456789101234567891012345678910123456789101234567891012345678910123456789101234567891012345678910
Execution time : 28013

As you can see the total execution time between Normal Executor Service and Completion Service is the same, while the normal loop was more than 3 times slower. This is easily explained by the fact that the normal loop was single threaded and the others 2 were run with 3 threads.

The difference between Normal Executor Service and Completion Service is visible at runtime, Normal Executor Service always waits for the next thread to finish the job before printing the number, the client needs to wait until a big bunch of threads return all together.
Completion Service is behaving differently, it follows a producer/consumer philosophy: as soon a thread is done, it puts the result into a non blocking queue so that the consumer can take it.

I hope this simple example will help you to better clarify the completion service as it did for me.

Fix for bad performance in Eclipse Juno SR1

noreply@blogger.com (marcocast) — Thu, 03 Jan 2013 15:46:00 +0000

Several major performance defects have been addressed in the Juno SR2 stream (4.2.2). Community members have confirmed that these fixes substantially address the performance problems with editor and view opening, closing, and switching. These fixes will be widely available in the Juno Service Release 2 (February 2013) and Kepler (June 2013) releases. Meanwhile, a patch is available for those using Juno SR1 that provides early access to these fixes. To install this patch:

Ensure you are already running on a package from the Juno SR1 release (September 2012)
Invoke Help > Install New Software
Select this repository: http://download.eclipse.org/eclipse/updates/4.2
Expand Juno SR1 Patches and install Eclipse UI Juno SR1 Optimizations

Source:
http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation

Hope this helps someone

Step builder pattern on youtube

noreply@blogger.com (marcocast) — Mon, 19 Nov 2012 10:33:00 +0000

Djorgje Popovic just published an article on the Step builder pattern which includes a nice video explaining the how and the why of this design.

So thanks to Djorgje and enjoy the video.

Chain of responsibility using Spring @Autowired List

noreply@blogger.com (marcocast) — Thu, 15 Nov 2012 16:11:00 +0000

There is a way in Spring 3.1 to auto populate a typed List which is very handy when you want to push a bit the decoupling and the cleaning in your code.

To show you how it works, I will implement a simple chain of responsibility that will take care of printing some greetings for a passed User.

Let start from the (only) domain class we have, the User:

package com.marco.springchain;
public class User {

        private final String name;
        private final char gender;

        public User(String name, char gender) {
                super();
                this.name = name;
                this.gender = gender;
        }

        public String getName() {
                return name;
        }

        public char getGender() {
                return gender;
        }
}

Then we create an interface that defines the type for our command objects to be used in our chain:

package com.marco.springchain;
public interface Printer {

        void print(User user);
}

This is the generic class (the template) for a Printer implementation.
The org.springframework.core.Ordered is used to tell the AnnotationAwareOrderComparator how we want our List to be ordered.
You don't need to implement the Ordered interface and to override the getOrder method if you don't need your chain to have an execution order.
Also notice that this abstract class return Ordered.LOWEST_PRECEDENCE, this because I want some Printer commands to just run at the end of the chain and I don't care about their execution order (everything will be clearer after, I promise!).

package com.marco.springchain;
import org.springframework.core.Ordered;
public abstract class GenericPrinter implements Printer, Ordered {

        public void print(User user) {
                String prefix = "Mr";
                if (user.getGender() == 'F') {
                        prefix = "Mrs";
                }
                System.out.println(getGreeting() + " " + prefix + " " + user.getName());
        }

        protected abstract String getGreeting();

        public int getOrder() {
                return Ordered.LOWEST_PRECEDENCE;
        }
}

This is our first real Printer command. I want this to have absolute precedence in the chain, hence the order is HIGHEST_PRECEDENCE.

package com.marco.springchain;
import org.springframework.core.Ordered;
import org.springframework.stereotype.Component;
@Component
public class HelloPrinter extends GenericPrinter {

        private static final String GREETING = "Hello";

        @Override
        protected String getGreeting() {
                return GREETING;
        }

        @Override
        public int getOrder() {
                return Ordered.HIGHEST_PRECEDENCE;
        }
}

WelcomePrinter to be executed as first command (After High precedence ones ).

package com.marco.springchain;
import org.springframework.stereotype.Component;
@Component
public class WelcomePrinter extends GenericPrinter {

        private static final String GREETING = "Welcome to the autowired chain";

        @Override
        protected String getGreeting() {
                return GREETING;
        }

        @Override
        public int getOrder() {
                return 1;
        }
}

GoodbyePrinter to be executed as second command

package com.marco.springchain;
import org.springframework.stereotype.Component;
@Component
public class GoodbyePrinter extends GenericPrinter {

        private static final String GREETING = "Goodbye";

        @Override
        protected String getGreeting() {
                return GREETING;
        }

        @Override
        public int getOrder() {
                return 2;
        }
}

These 2 commands need to be executed after the others, but I don't care about their specific order, so I will not override the getOrder method, leaving the GenericPrinter to return Ordered.LOWEST_PRECEDENCE for both.

package com.marco.springchain;
import org.springframework.stereotype.Component;
@Component
public class CleaningMemoryPrinter extends GenericPrinter {

        private static final String GREETING = "Cleaning memory after";

        @Override
        protected String getGreeting() {
                return GREETING;
        }
}

package com.marco.springchain;
import org.springframework.stereotype.Component;
@Component
public class CleaningSpacePrinter extends GenericPrinter {

        private static final String GREETING = "Cleaning space after";

        @Override
        protected String getGreeting() {
                return GREETING;
        }
}

This is the chain context.
Spring will scan (see the spring-config.xml) the package specified in the config file, it will see the typed (List<Printer>) list, and it will populate the list with an instance of any @Component that implements the type Printer.
To order the List we use AnnotationAwareOrderComparator.INSTANCE that use the getOrder method to re-order the List ( the object with the lowest value has highest priority (somewhat analogous to Servlet "load-on-startup" values)).

package com.marco.springchain;
import java.util.Collections;
import java.util.List;
import javax.annotation.PostConstruct;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.core.annotation.AnnotationAwareOrderComparator;
import org.springframework.stereotype.Component;
@Component
public class PrinterChain {

        @Autowired
        private List<Printer> printers;

        @PostConstruct
        public void init() {
                Collections.sort(printers, AnnotationAwareOrderComparator.INSTANCE);
        }

        public void introduceUser(User user) {
                for (Printer printer : printers) {
                        printer.print(user);
                }
        }
}

The spring-config.xml in the src/main/resources.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:util="http://www.springframework.org/schema/util"
       xsi:schemaLocation="
  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
  http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
  http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
  http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
  http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd" default-lazy-init="true">

    <context:component-scan base-package="com.marco.springchain"/>
</beans>

Finally, a main class to test our chain.

package com.marco.springchain;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class MainTest {

        public static void main(String[] args) {
                ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring-config.xml");
                PrinterChain printerChain = (PrinterChain) context.getBean("printerChain");
                printerChain.introduceUser(new User("Marco Castigliego", 'M'));
                printerChain.introduceUser(new User("Julie Marot", 'F'));
        }
}

OUTPUT:

Hello Mr Marco Castigliego
Welcome to the autowired chain Mr Marco Castigliego
Goodbye Mr Marco Castigliego
Cleaning space after Mr Marco Castigliego
Cleaning memory after Mr Marco Castigliego
Hello Mrs Julie Marot
Welcome to the autowired chain Mrs Julie Marot
Goodbye Mrs Julie Marot
Cleaning space after Mrs Julie Marot
Cleaning memory after Mrs Julie Marot

Hope you enjoyed the example. see ya.

JBoss HornetQ for Kids, Parents and Grandparents – Chapter 1

noreply@blogger.com (marcocast) — Thu, 08 Nov 2012 11:48:00 +0000

It’s now almost 4 years that I’m working with HornetQ and I think it’s time to share part of what I learnt so far.

The main purpose of this post is not to rewrite the official documentation, but it’s to clarify, in simple ways, the concepts we use most here in PaddyPower .

What is HornetQ

HornetQ is a JMS implementation. JMS is a message oriented middle-ware API to exchange information between producers and consumers in an asynchronous way.

HornetQ is one of the numerous framework out there that implement the JMS API.

Configuration

All the HornetQ configuration we care about is in 1 folder. How beautiful is that?! The folder is hornetq (or hornetq.sar dipending on the jboss version you are using) and you can find it in your jboss profile deploy folder.

In this folder we have up to 7 xml configuration files. We really care only about 2:

hornetq-jms.xml and hornetq-configuration.xml.

hornetq-jms.xml

This is where you want to define your JNDI names for queues, topics and connection factories.

By default all the Connection factories, the dead letter and the expiry Queue are already configured.

What you need to add is only the queues or topics that your application needs to use.

For example:

<queue name="phaseQueueFromEngine">
     <entry name="/queue/phaseQueueFromEngine"/>
</queue>

the entry name is the JNDI name used by your producer and consumer to discover the queue.

hornetq-configuration.xml

This is where you want to define acceptors, connectors, bridges and other cool stuff.

Understanding Connectors & Acceptors

Ok, this can be tricky, so I’ll try to be simple and essential.

HornetQ run in a server (JBoss for example) or as standalone application.

In any of the above cases, HornetQ works by communicating with his own server, the HornetQ server.

In order to communicate with it, we have to tell how we connect to and what we accept as connection.

Acceptors define which type of connection are accepted by the HornetQ Server.
Connectors define how to connect to the HornetQ server.

Luckily, only 2 kind of connectors and acceptors are possible, in-vm and netty.

in-vm is used when the producer and the consumer lives in the same virtual machine.

Example:

<acceptor name="in-vm">
        <factory-class>org.hornetq.core.remoting.impl.invm.InVMAcceptorFactory</factory-class>
</acceptor>
<connector name="in-vm">
       <factory-class>org.hornetq.core.remoting.impl.invm.InVMConnectorFactory</factory-class>
</connector>

netty must be used when the producer and the consumer lives in different virtual machines.

Example:

Producer/Consumer in the same machine:

<acceptor name="netty">
         <factory-class>org.hornetq.integration.transports.netty.NettyAcceptorFactory</factory-class>
         <param key="host"  value="${host:localhost}"/>
         <param key="port"  value="${port:5445}"/>
      </acceptor>

<connector name=”netty”>
<factory-class>org.hornetq.integration.transports.netty.NettyConnectorFactory</factory-class>
<param key=”host” value=”${host:localhost}”/>
<param key=”port” value=”${port:5445}”/>
</connector>

Producer/Consumer in different machines:

Consumer Box
<acceptor name=”netty-external-acceptor”>
<factory-class>org.hornetq.integration.transports.netty.NettyAcceptorFactory</factory-class>
<param key=”host” value=”172.x.x.62″/>
<param key=”port” value=”5445″/>
</acceptor>
Producer Box

<connector name="remote-engine-connector">
         <factory-class> org.hornetq.integration.transports.netty.NettyConnectorFactory</factory-class>
         <param key="host" value="172.x.x.62"/>
         <param key="port" value="5445"/>
      </connector>

So far so good.

Pay attention when you configure acceptors and connectors because in order to communicate properly they have to be the same kind with the same host and port.

netty acceptor with netty connector (same host and port ) GOOD

in-vm acceptor with in-vm connector GOOD

in-vm acceptor with netty connector BAD

netty acceptor port 5445 with netty connector 5446 BAD

netty acceptor host 172.x.x.60 with netty connector 172.x.x.62 BAD

Understanding Bridges

Another feature I widely used is the bridge.

If you have a producer living in the box 172.x.x.60 and the consumer sitting in the box 172.x.x.62 you need to connect them and you do this configuring a bridge in our beloved configuration file hornetq-configuration.xml

Example :

<bridge name=”from60to62Bridge”>
<queue-name>jms.queue.phaseQueueToEngine</queue-name>
<forwarding-address>jms.queue.phaseQueueFromInput</forwarding-address>
<reconnect-attempts>-1</reconnect-attempts>
<connector-ref connector-name=”remote-engine-connector”/>
</bridge>

Yes, you use the connector to specify where to connect to the other hornetQ server. Easy!

I hope this will clarify a couple of aspects and it will help to understand better the sometime scary Hornetq configuration.

Coming soon.. HornetQ for Kids, Parents and Grandparents – Chapter 2: the magic of address-settings

JUnit4 Parameterized and Theories

noreply@blogger.com (marcocast) — Thu, 08 Nov 2012 11:38:00 +0000

Parameterized

I always relied on TestNG to pass parameters to test methods in order to give a bit of flexibility to my tests or suites.

However, the same flexibility can be achieved using JUnit4.

To use it it’s simple:


package com.marco.test;

import java.util.Arrays;
import java.util.Collection;

import junit.framework.Assert;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

@RunWith(Parameterized.class)
public class ParameterizedTest {

@Parameters
public static Collection data() {
return Arrays.asList(new Object[][] {
/* Sport Nation year totWinners */
{ “basket”, “usa”, 2002, 5, },
{ “soccer”, “argentina”, 2003, 2 },
{ “tennis”, “spain”, 2004, 10 },
{ “chess”, “ireland”, 2005, 0 },
{ “eatingbananas”, “italy”, 2006, 20 }
});
}

private final String sport;
private final String nation;
private final int year;
private final int totWinners;

public ParameterizedTest(String sport, String nation, int year, int totWinners) {
this.sport = sport;
this.nation = nation;
this.year = year;
this.totWinners = totWinners;
}

@Test
public void test() {
Assert.assertTrue(isDataCorrect(sport, nation, year, totWinners));
}

private boolean isDataCorrect(String sport2, String nation2, int year2, int totWinners2) {
return true;
}

}

JUnit will create an instance of the ParameterizedTest class and run the testCombination() method (or any method marked as @Test) for each row defined in the static collection.

Theories

This another interesting feature from JUnit4 that I like. You use Theories in JUnit 4 to test combinations of inputs using the same test method:


package com.marco.test;

import static org.hamcrest.CoreMatchers.is;

import java.math.BigDecimal;

import org.junit.Assert;
import org.junit.Assume;
import org.junit.experimental.theories.DataPoint;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;

@RunWith(Theories.class)
public class TheoryTest {

@DataPoint
public static int MARKET_FIRST_GOALSCORERE_ID = 2007;
@DataPoint
public static int MARKET_WDW_ID = 2008;
@DataPoint
public static BigDecimal PRICE_BD = new BigDecimal(6664.0);
@DataPoint
public static double PRICE_1 = 0.01;
@DataPoint
public static double PRICE_2 = 100.0;
@DataPoint
public static double PRICE_3 = 13999.99;

@Theory
public void lowTaxRateIsNineteenPercent(int market_id, double price) {
Assume.assumeThat(market_id, is(2008));
Assume.assumeThat(price, is(100.0));
// run your test
Assert.assertThat(price, is(100.0));
}

@Theory
public void highTaxRateIsNineteenPercent(int market_id, double price) {
Assume.assumeThat(market_id, is(2007));
Assume.assumeThat(price, is(13999.99));

Assert.assertThat(price, is(13999.99));
}

@Theory
public void highTaxRateIsNineteenPercent(int market_id, BigDecimal price) {
Assume.assumeThat(market_id, is(2007));
Assert.assertThat(price, is(BigDecimal.valueOf(6664)));
}
}

This time you need to mark the test class as @RunWith(Theories.class) and use @DataPoint to define properties that you want to test.

JUnit will call the methods market as @Theory using all the possible combinations based on the DataPoint provided and the type of the variable. PRICE_BD DataPoint will be used only in the last method, the only one accepting BigDecimal in its method parameters.

Only parameters that satisfy the Assume.assumeThat() condition will make through the asser test. The combinations that don’t satisfy the Assume.assumeThat() condition will be ignored silently.

Have fun...

Step Builder Pattern - WIKI-Definition

noreply@blogger.com (marcocast) — Mon, 08 Oct 2012 08:37:00 +0000

Definition

The step builder pattern is an extension of the builder pattern that fully guides the user through the creation of the object with no chances of confusion. ^[1]

The intent of the Step Builder design pattern is to separate the construction of a complex object from its representation by creating defined steps and exposing to the user only selected methods per time.

Advantages of using the Step Builder over the Builder pattern

The user will see only one or few selected methods per time during the Object creation.
Based on the user choice different paths can be taken during the Object creation.
The final build step will be available only at the end, after all mandatory steps are completed, returning an Object in a consistent state.
The user experience will be greatly improved by the fact that he will only see the next step methods available.

Examples

Java

 /** "Product" */
 class UserConfiguration {
    private final String name;
    private final String filePath;
    private ServerDetails serverDetails;
 
    public UserConfiguration(String name, String filePath){
       this.name = name;
       this.filePath = filePath;
    }
    public void setServerDetails(ServerDetails serverDetails)     { this.serverDetails = serverDetails; }
 
    //all the getters
    ...
 }
 
class ServerDetails {
    private final String host;
    private String user;
    private String password;
 
    public ServerDetails(String host){
       this.host = host;
    }
    public void setUser(String user)     { this.user = user; }
    public void setPassword(String password)     { this.password = password; }
 
    //all the getters and isLocalhost() method
    ...
 }
 
 
 
 /** "Step Builder" */
public class UserConfigurationBuilder {
   public static NameStep newBuilder() {
      return new Steps();
   }  
   private UserConfigurationBuilder() {}
 
   public static interface NameStep {
      /**
       * @param name unique identifier for this User Configuration
       * @return FileStep
       */
      FileStep name(String name);
   }
 
   public static interface FileStep {
      /** 
       * @param filePath absolute path of where the User Configuration exists.
       * @return ServerStep
       */
      ServerStep filePath(String name);
   }
 
   public static interface ServerStep {
      /**
       * The hostname of the server where the User Configuration file is stored will be set to "localhost".
       * @return BuildStep
       */
      public BuildStep onLocalhost();
 
      /**
       * The hostname of the server where the User Configuration file is stored.
       * @return CredentialsStep
       */
      public CredentialsStep onRemotehost(String host);
   }
 
   public static interface CredentialsStep {
      /**
        * Username required to connect to remote machine
        * Password required to connect to remote machine
        * @return BuildStep
        */
       public BuildStep credentials(String user, String password);
   }
 
   public static interface BuildStep {
      /** 
       * @return an instance of a UserConfiguration based on the parameters passed during the creation.
       */
      public Profile build();
   }
 
   private static class Steps implements NameStep, FileStep, ServerStep, CredentialsStep, BuildStep {
 
      private String name;
      private String host;
      private String user;
      private String password;
      private String filePath;
 
      @Override
      public FileStep name(String name) {
         this.name = name;
        return this;
      }
 
      @Override
      public ServerStep filePath(String filePath) {
         this.filePath = filePath;
         return this;
      }
 
      @Override
      public BuildStep onLocalhost() {
         this.host = "localhost";
         return this;
      }
 
      @Override
      public CredentialsStep onRemotehost(String host) {
         this.host = host;
         return this;
      }
 
      @Override
      public BuildStep credentials(String user, String password) {
         this.user = user;
         this.password = password;
         return this;
      }
 
      @Override
      public UserConfiguration build() {
         UserConfiguration userConfiguration = new UserConfiguration(name, filePath);
         ServerDetails serverDetails = new ServerDetails(host);
         if (!serverDetails.isLocalhost()) {
            serverDetails.setUser(user);
            serverDetails.setPassword(password);
         }
         userConfiguration.setServerDetails(serverDetails);
         return userConfiguration;
      }
   }
}
 
 
 /** A user creating a configuration. */
 class StepBuilderExample {
    public static void main(String[] args) {
        // A local user configuration
        UserConfiguration localUserConfiguration = UserConfigurationBuilder                                              .newBuilder()
                                              .name("aLocalConfiguration")
                                              .filePath("/opt/conf/user.txt")
                                              .onLocalhost()
                                              .build();  
        // A remote user configuration
        UserConfiguration remoteUserConfiguration = UserConfigurationBuilder                                              .newBuilder()
                                              .name("aRemoteConfiguration")
                                              .filePath("/opt/conf/user.txt")
                                              .onRemotehost("172.x.x.x")
                                              .credentials("user","password")
                                              .build();  
    }
 }

C#

namespace StepBuilder
{
    class Program
    {
        static void Main(string[] args)
        {

         UserConfiguration localUserConfiguration = UserConfigurationBuilder                        .CreateNewBuilder()
                        .SetName(@"aLocalConfiguration")
                        .SetFilePath(@"/opt/conf/user.txt")
                        .OnLocalhost()
                        .Build();
          UserConfiguration remoteUserConfiguration = UserConfigurationBuilder                        .CreateNewBuilder()                         .SetName(@"aRemoteConfiguration")                         .SetFilePath(@"/opt/conf/user.txt")                         .OnRemoteHost("172.x.x.x")                         .SetCredentials("user", "password")                         .Build();         }     }      public class UserConfiguration     {         public UserConfiguration(string name, string filePath)         {             Name = name;             FilePath = filePath;         }          private ServerDetails _serverDetails;          public string Name { get; private set; }          public string FilePath { get; private set; }          public void SetServerDetails(ServerDetails serverDetails)         {             _serverDetails = serverDetails;         }     }      public class ServerDetails      {         public ServerDetails(string host)         {             Host = host;         }          public string Host { get; private set; }         public string User { get; set; }         public string Password { get; set; }          public bool IsLocalhost          {             get { return Host == "localhost"; }         }     }      public class UserConfigurationBuilder     {         public static INameStep CreateNewBuilder()         {             return new Steps();         }          private UserConfigurationBuilder() { }          public interface INameStep          {              /// <param name="name">Unique identifier for this User Configuration</param>             IFileStep SetName(string name);         }          public interface IFileStep          {             /// <param name="filePath">Absolute path of where the User Configuration exists</param>             IServerStep SetFilePath(string filePath);          }          public interface IServerStep         {             /// <summary>             /// The hostname of the server where the User Configuration file is store will be set to "localhost".             /// </summary>             IBuildStep OnLocalhost();              /// <param name="host">The hostname of the server where the User Configuration is stored</param>             ICredentialsStep OnRemoteHost(string host);         }          public interface IBuildStep         {             /// <summary>             /// Returns an instance of a UserConfiguration based on the parameters passed during the creation.             /// </summary>             UserConfiguration Build();         }          public interface ICredentialsStep         {             /// <param name="user">Username required to connect to remote machine</param>             /// /// <param name="password">Password required to connect to remote machine</param>             IBuildStep SetCredentials(string user, string password);         }          private class Steps : INameStep, IFileStep, IServerStep, IBuildStep, ICredentialsStep         {             private string _name;             private string _host;             private string _user;             private string _password;             private string _filePath;              public IFileStep SetName(string name)             {                 _name = name;                 return this;             }              public IServerStep SetFilePath(string filePath)             {                 _filePath = filePath;                 return this;             }              public IBuildStep OnLocalhost()             {                 _host = "localhost";                 return this;             }              public ICredentialsStep OnRemoteHost(string host)             {                 _host = host;                 return this;             }              public UserConfiguration Build()             {                 UserConfiguration userConfiguration = new UserConfiguration(_name, _filePath);                 ServerDetails serverDetails = new ServerDetails(_host);                 if (!serverDetails.IsLocalhost)                 {                     serverDetails.Password = _password;                     serverDetails.User = _user;                 }                 userConfiguration.SetServerDetails(serverDetails);                  return userConfiguration;             }              public IBuildStep SetCredentials(string user, string password)             {                 _user = user;                 _password = password;                 return this;             }         }     } }

Review Check box

noreply@blogger.com (marcocast) — Thu, 20 Sep 2012 13:51:00 +0000

One good and necessary practice when developing software is the code review.

Code review it's an excellent process to reduce bugs in the code and to raise up the quality of the software you are working on.

Basically, it means that before committing your changes to the repository, you ask to another developer to look at your code and see if everything looks fine.

But what is everything?

Well, this can vary between companies standards, but the following can be a good starting point:

OVERALL DESIGN (Is the current design the best design (i.e. is it scalable, maintainable, Are the algorithms following the best practise in order to have the best performances? etc.)
FUNCTIONALITY (Does the code do what is supposed to do? Are we covering all the possible cases?)
CODE READABILITY (Is the code EASY to understand? etc.)
UNIT TEST (Are the tests covering all possible scenarios? Are the tests reusable? If the developed code does not have 100% code coverage, why not?)
ACCEPTANCE CRITERIA (What are the Acceptance Criteria, and if the criteria haven't been expressed as an automated test, why not?)
ERROR HANDLING (Do we really need checked exceptions? etc.)
WARNING (Are the eclipse/intellij warnings acceptable?)
LOG (Is the log useful in order to find issue? Is the log communicating what is necessary? Etc.)

Print this list and stick it in each developer desk. It will help during the review process.

The Meetings ERA

noreply@blogger.com (marcocast) — Wed, 19 Sep 2012 10:15:00 +0000

You just opened your outlook calendar and you feel horrified from what you see??4 meetings in the same day??And maybe you really care about half of them??

I think it’s good to know how to handle meetings and these are few suggestions coming from Robert C. Martin in his “The clean coder” book.

I highlighted the key part on each paragraph, so if you are in rush you can just read the paragraph title and the part in bold ;)

Meetings

Meetings cost about $200 per hour per attendee. This takes into account salaries, benefits, facilities costs, and so forth. The next time you are in a meeting, calculate the cost. You may be amazed.

There are two truths about meeting.

Meetings are necessary.
Meetings are huge time wasters.

Often these two truths equally describe the same meeting. Some in attendance may find them invaluable; others may find them redundant or useless.

Professionals are aware of the high cost of meetings. They are also aware that their own time is precious; they have code to write and schedules to meet. Therefore, they actively resist attending meetings that don’t have an immediate and significant benefit.

Declining

You do not have to attend every meeting to which you are invited. Indeed, it is unprofessional to go to too many meetings. You need to use your time wisely. So be very careful about which meetings you attend and which you politely refuse.

The person inviting you to a meeting is not responsible for managing your time. Only you can do that. So when you receive a meeting invitation, don’t accept unless it is a meeting for which your participation is immediately and significantly necessary to the job you are doing now.

Sometimes the meeting will be about something that interests you, but is not immediately necessary. You will have to choose whether you can afford the time. Be careful—there may be more than enough of these meetings to consume your days.

Sometimes the meeting will be about something that you can contribute to but is not immediately significant to what you are currently doing. You will have to choose whether the loss to your project is worth the benefit to theirs. This may sound cynical, but your responsibility is to your projects first. Still, it is often good for one team to help another, so you may want to discuss your participation with your team and manager.

Sometimes your presence at the meeting will be requested by someone in authority, such as a very senior engineer in another project or the manager of a different project. You will have to choose whether that authority outweighs your work schedule. Again, your team and your supervisor can be of help in making that decision.

One of the most important duties of your manager is to keep you out of meetings. A good manager will be more than willing to defend your decision to decline attendance because that manager is just as concerned about your time as you are.

Leaving

Meetings don’t always go as planned. Sometimes you find yourself sitting in a meeting that you would have declined had you known more. Sometimes new topics get added, or somebody’s pet peeve dominates the discussion. Over the years I’ve developed a simple rule: When the meeting gets boring, leave.

Again, you have an obligation to manage your time well. If you find yourself stuck in a meeting that is not a good use of your time, you need to find a way to politely exit that meeting.

Clearly you should not storm out of a meeting exclaiming “This is boring!” There’s no need to be rude. You can simply ask, at an opportune moment, if your presence is still necessary. You can explain that you can’t afford a lot more time, and ask whether there is a way to expedite the discussion or shuffle the agenda.

The important thing to realize is that remaining in a meeting that has become a waste of time for you, and to which you can no longer significantly contribute, is unprofessional. You have an obligation to wisely spend your employer’s time and money, so it is not unprofessional to choose an appropriate moment to negotiate your exit.

Have an Agenda and a Goal

The reason we are willing to endure the cost of meetings is that we sometimes do need the participants together in a room to help achieve a specific goal. To use the participants’ time wisely, the meeting should have a clear agenda, with times for each topic and a stated goal.

If you are asked to go to a meeting, make sure you know what discussions are on the table, how much time is allotted for them, and what goal is to be achieved. If you can’t get a clear answer on these things, then politely decline to attend.

If you go to a meeting and you find that the agenda has been high-jacked or abandoned, you should request that the new topic be tabled and the agenda be followed. If this doesn’t happen, you should politely leave when possible.

Stand-Up Meetings

These meetings are part of the Agile cannon. Their name comes from the fact that the participants are expected to stand while the meeting is in session. Each participant takes a turn to answer three questions:

What did I do yesterday?
What am I going to do today?
What’s in my way?

That’s all. Each question should require no more than twenty seconds, so each participant should require no more than one minute. Even in a group of ten people this meeting should be over well before ten minutes has elapsed.

Iteration Planning Meetings

These are the most difficult meetings in the Agile canon to do well. Done poorly, they take far too much time. It takes skill to make these meetings go well, a skill that is well worth learning.

Iteration planning meetings are meant to select the backlog items that will be executed in the next iteration. Estimates should already be done for the candidate items. Assessment of business value should already be done. In really good organizations the acceptance/component tests will already be written, or at least sketched out.

The meeting should proceed quickly with each candidate backlog item being briefly discussed and then either selected or rejected. No more than five or ten minutes should be spent on any given item. If a longer discussion is needed, it should be scheduled for another time with a subset of the team.

My rule of thumb is that the meeting should take no more than 5% of the total time in the iteration. So for a one week iteration (forty hours) the meeting should be over within two hours.

Iteration Restrospective and Demo

These meetings are conducted at the end of each iteration. Team members discuss what went right and what went wrong. Stakeholders see a demo of the newly working features. These meetings can be badly abused and can soak up a lot of time, so schedule them 45 minutes before quitting time on the last day of the iteration. Allocate no more than 20 minutes for retrospective and 25 minutes for the demo. Remember, it’s only been a week or two so there shouldn’t be all that much to talk about.

Arguments/Disagreements

Kent Beck once told me something profound: “Any argument that can’t be settled in five minutes can’t be settled by arguing.” The reason it goes on so long is that there is no clear evidence supporting either side. The argument is probably religious, as opposed to factual.

Technical disagreements tend to go off into the stratosphere. Each party has all kinds of justifications for their position but seldom any data. Without data, any argument that doesn’t forge agreement within a few minutes (somewhere between five and thirty) simply won’t ever forge agreement. The only thing to do is to go get some data.

Some folks will try to win an argument by force of character. They might yell, or get in your face, or act condescending. It doesn’t matter; force of will doesn’t settle disagreements for long. Data does.

Some folks will be passive-aggressive. They’ll agree just to end the argument, and then sabotage the result by refusing to engage in the solution. They’ll say to themselves, “This is the way they wanted it, and now they’re going to get what they wanted.” This is probably the worst kind of unprofessional behavior there is. Never, ever do this. If you agree, then youmust engage.

How do you get the data you need to settle a disagreement? Sometimes you can run experiments, or do some simulation or modeling. But sometimes the best alternative is to simply flip a coin to choose one of the two paths in question.

If things work out, then that path was workable. If you get into trouble, you can back out and go down the other path. It would be wise to agree on a time as well as a set of criteria to help determine when the chosen path should be abandoned.

Beware of meetings that are really just a venue to vent a disagreement and to gather support for one side or the other. And avoid those where only one of the arguers is presenting.

If an argument must truly be settled, then ask each of the arguers to present their case to the team in five minutes or less. Then have the team vote. The whole meeting will take less than fifteen minutes.

Some development tips and tricks

noreply@blogger.com (marcocast) — Wed, 29 Aug 2012 23:43:00 +0000

These are just some tips and tricks I learnt over my career that I'd like to share. This list does not contains silver bullets and it doesn't pretend to be complete or be an absolute truth. It's just a list that I hope may be helpful for someone.

1 ) Push the coding to the last

This point can be also be read as think before coding. I found myself, lots of times, especially in the beginning of my career, in rush of writing classes, methods, interfaces as soon as I was receiving a spec for a new functionality.

This impulse turned out 90% of the times into a PAINFUL situation. The spec was unclear and so unclear was my code; The spec was too "code oriented" and so blindly coding this was producing wrong design/ implementation that needed to be trashed out and completely re-designed;

Many other are the disadvantages of writing code straight away after receiving a spec. So, lesson learnt and this is what I'm doing now after receiving a spec/story to develop:

I stay away from the keyboard!
I print the spec (sorry amazonian jaguars ) and I take my time to read them carefully. Do not think that everything you will read there is exempt of mistakes or cannot be done in better and simpler ways. At the end of the day, people who wrote the specs, know little or nothing about the software, what they know is how to make more money with new functionality.
If something is not clear to you, it will not clarify magically by itself if you start to code. Ask questions to other colleagues, to the business, clarify as much as possible and only when you feel confident, when you see the real pitcure of what they really want, then and only then you can switch the monitor on and click on the eclipse icon...

2 ) Simple = perfect

Make the 2 famous principles, KISS and YAGNI, part of your blood, skin and bones. Strive for simplicity, forget about the trends, focus on the most basic thing that will give you what is needed. Don't think straight about XML configuration, spring/seam framework, drools, aspects, multithreading solutions, ejbs, or whatever complex/cool technology you know or you heard out there, nobody really cares about the technologies you use.

What everyone cares is that your code does what is supposed to do, it is READABLE and it is MAINTAINABLE.

Pure java is enough to cover 90% or more of everything you need. Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live. Make him happy, write simple, clear straightforward code.

I remember I read somewhere that, if you read your code after 1 or 2 years and you immediately understand everything is doing and you cannot simplify it more, than your code is PERFECT.

3 ) Paper and pen

I never found a tool more useful than paper and pen to design software.

Before writing software I usually spend a bit of time trying to put the idea of the design down on paper.

I then , if in doubt, go through it with a colleague. Because it is on paper I can fast go to the point with my pair and he can quick tell me if I'm missing something.

Knowing that you are missing something in a piece of paper, it's far way better then knowing that you are missing something in the code!

So don't waste time using UML tools, unless what you are doing is big-fantastic-amazing-new architectural prototype.

4 ) Don't leave for tomorrow what you can do today

If you are fixing a bug or adding new functionality and you notice in the existing code, DUPLICATION or BAD NAMES or a POSSIBLE BUG then FIX IT IMMEDIATELY.

Don't wait for the next sprint and don't add a technical story in the technical backlog. Technical stories laid in the backlog for long time, when/if it will be the time to work on it, it will be more complicated to re-understand the context of the problem and fix it.

The exception it's when the fix/refactoring is too complex and required long time, then it's appropriate to create a story in the technical backlog!

5 ) You have time!

Really, you have time! Don't rush. There is no competition and you are not at the programming Olympics.
Your job is to deliver good quality code. That's it. This is your job!
If you feel that a task takes longer that what you initially estimated, just make the team aware in the next stand up and that's it.
If a client/manager is screaming above your shoulders because he wants something faster than you can deliver, it's not your problem!!! When they say "I want this functionality to be ready asap" translated in Truthlish it means "I want this functionality to be PERFECT with NO BUGS asap". They will be happier to wait more and have less bugs than having a fast release full of issues.
So take your time and be intransigent on the quality level of your software and forget about external pressures!

6 ) Implement leaves first

So, you just received a brand new story to develop and you want to implement it right.
For example the story is about calculating item prices. One price for each item. Each price is obtained with a different calculation.
Choose one item price logic and as first thing write a unit test against this logic. Don't be stressed about implementing the whole design or writing interfaces, abstract classes etc. Focus on one small leaf per time!
When the first leaf is finished, start with a second test for the second small logic you want to implement. The design will come out almost by itself. The tests will tell you which direction is best to take.

7 ) Do Pair programming!

I fully applied this technique only recently (less than 1 year ago) and I have to say, it's powerful! It is twice productive than working alone, the quality of the code is superior, the development speed is increased.
A strength of this technique is the fact that is funny. being funny and so more stimulating means that you are more focused and you pay more attention to details.
You can learn a lot doing pair programming, so push for it as much as you can!

8 ) Rarely use checked Exceptions

Every time I use an API that force me to put around its method call the try and catch block, it makes me nervous, like a violent psychopath, but often I don't know where they leave. Especially if there is nothing I can do about the exception. What the hell I' m supposed to do with this error?
If you want to use checked Exception used them ONLY if the client can reasonably recover from it at run time! Remember that checked exceptions will spread all over your design in case you need to extend the behavior!

9 ) Say NO to Hacks

Programming is like sex. One mistake and you have to support it for the rest of your life. (Michael Sinz). And Hacks ARE mistakes!

Simply don't implement hacks. I did it in the past, for whatever reasons ( no time,pressure, desire to release a feature as soon as possible, managers screaming, Orcs, Leprechauns, whatever), and now after years we need to maintain them. Hacks are difficult to understand,they break the normal logic flow of your code and they are hard to die! You implement an hack today and tomorrow (1 year after maybe ) someone else will need to fix a bug on this hack and ..well good luck with that!
Spend more time on the spec if the hack is a business request, and explain why this will cost a lot to maintain. Propose other solutions, discuss it with your team, a better solution is on the way!

10 ) Forget about comments, just write proper names!

Write proper names when writing packages, classes, methods and variables.
Write names that make sense, ask a review before committing your code, but don't explain verbally what you have done, try first letting your reviewer read the code, and see how good you were in writing self explanatory code!
Comments need to be maintained, otherwise they are misleading. How often did you fix a bug in the code and you changed the class documentation?me, rarely!Use javadoc only if it is really necessary!and if you do,then remember to update them every time you change the code and enforce the same behavior in your team!

11 ) Reinvent the wheels

Read books, blogs, tutorial, etc as much as possible, but always with a critical and open mind! The same apply when listening to your team or leader. Don't be fooled by authorities, think always with your own mind.
If you decide to go for some approach it must be because you believe in it. Because you see good reasons to do so. If you feel that something could be done better or you see problems in the approach you are using , discuss it with your team and try to clarify your doubts. If after talking to the team you still feel that things should be done differently, then push for better approaches and fight for your ideas!
Sometimes, to progress, you need to reinvent the wheels or at this time we were all developing in FORTRAN.

A simple way to test distributed applications

noreply@blogger.com (marcocast) — Thu, 02 Aug 2012 11:10:00 +0000

So, testing distributed applications is not easy, we all know it.
Too many variants to take in considerations which usually lead to an high instability of the tests.

Let say we have a front end application sending messages to a distribution engine which then forward the messages to other remote destinations. Sounds familiar?

OK so, how you test that messages travelling correctly trough all the predefined servers?

What if I want to keep my tests independent from any integration framework?

My solution is in the logs.
Why not rely on the logs to prove that your application is working as expected?

Logs are often underrated for performance/acceptance/smoke tests, but if correctly written, they can provide all the information you need to measure the status of your software at any point of its execution.

Testing relying on logs is a non intrusive way to test and no performances or anything will be affected. Applying this concept to an hypothetical integration test it's easy (at least in UNIX environments :) ), thanks to libraries like Grep4j:

import static org.grep4j.core.Grep4j.grep;
import static org.grep4j.core.Grep4j.regularExpression;
import static org.grep4j.core.fluent.Dictionary.on;
import static org.grep4j.core.fluent.Dictionary.executing;
...

@Test
public void aCreateMessageShouldPassThroughAllTheFinalDestinations() {
  List profiles =  Arrays.asList(distributionServerLog(),
                                 destination1ServerLog(),
                                 destination2ServerLog(),
                                 destination3ServerLog());

assertThat(executing(grep(regularExpression("MessageId(.*)Received"), on(profiles))).totalLines(), is(4));

}

As you can see, in a very simple way you have an efficient end-to-end test across different machines.

I think this approach is also a good option when you want to build acceptance or regression tests around legacy applications. You can treat your legacy app as a black box and just test the expected output in the log.

Finally, I reckon this way of test will force the developers to standardize and uniform the way to log in the code which is always good :)

Fluent mirror methods

noreply@blogger.com (marcocast) — Sun, 29 Jul 2012 21:42:00 +0000

How important is the readability of the code you write?

I think very important, probably one of the key to success in delivering good working and maintainable software.

This article is about a simple technique to help you and the people working on your code to fast understand what's happening.

I called this technique fluent mirror methods, and usually I wrap all these kind of methods in a single class called Dictionary.

A fluent mirror method is a simple static method returning the same object passed. For example:

public static <T> T executing(T type) {
                return type;
        }

You can use these methods as follows:

import static org.grep4j.core.Grep4j.grep;

import static org.grep4j.core.fluent.Dictionary.on;
import static org.grep4j.core.fluent.Dictionary.executing;
import static org.grep4j.core.fluent.Dictionary.expression;
import static org.grep4j.core.fluent.Dictionary.with;
...

assertThat(executing(grep(with(expression("Marco")), on(profile))).totalLines(), is(1));

Step Builder pattern

noreply@blogger.com (marcocast) — Sat, 28 Jul 2012 16:04:00 +0000

Recently I wanted to implement a builder in my Grep4j API, but, as already happened in the past with the builder or other creational patterns, I was not completely satisfied with the result. A Builder pattern is a design you implement when you want to separate the creation of an object from its representation. For example, let say you have a Java Panino object composed of few ingredients:


package com.stepbuilder.bar;
import java.util.List;
public class Panino {

 private final String name;
 private String breadType;
 private String fish;
 private String cheese;
 private String meat;
 private List vegetables;

 public Panino(String name) {
  this.name = name;
 }

 public String getBreadType() {
  return breadType;
 }

 public void setBreadType(String breadType) {
  this.breadType = breadType;
 }

 public String getFish() {
  return fish;
 }

 public void setFish(String fish) {
  this.fish = fish;
 }

 public String getCheese() {
  return cheese;
 }

 public void setCheese(String cheese) {
  this.cheese = cheese;
 }

 public String getMeat() {
  return meat;
 }

 public void setMeat(String meat) {
  this.meat = meat;
 }

 public List getVegetables() {
  return vegetables;
 }

 public void setVegetables(List vegetables) {
  this.vegetables = vegetables;
 }

 public String getName() {
  return name;
 }

 @Override
 public String toString() {
  return "Panino [name=" + name + ", breadType=" + breadType + ", fish="
    + fish + ", cheese=" + cheese + ", meat=" + meat
    + ", vegetables=" + vegetables + "]";
 }
 
 
}

Now, in order to create a Panino you can write your Builder class that, more or less, will look like the following.


package com.stepbuilder.bar;
import java.util.ArrayList;
import java.util.List;
public class PaninoBuilder {
 
 private String name;
 private String breadType;
 private String fish;
 private String cheese;
 private String meat;
 private List vegetables = new ArrayList();

 public PaninoBuilder paninoCalled(String name){
  this.name = name;
  return this;
 }
 
 public PaninoBuilder breadType(String breadType){
  this.breadType = breadType;
  return this;
 }
 
 public PaninoBuilder withFish(String fish){
  this.fish = fish;
  return this;
 }
 
 public PaninoBuilder withCheese(String cheese){
  this.cheese = cheese;
  return this;
 }
 
 public PaninoBuilder withMeat(String meat){
  this.meat = meat;
  return this;
 }
 
 public PaninoBuilder withVegetable(String vegetable){  
  vegetables.add(vegetable);
  return this;
 }
 
 public Panino build(){  
  Panino panino = new Panino(name);
  panino.setBreadType(breadType);
  panino.setCheese(cheese);
  panino.setFish(fish);
  panino.setMeat(meat);
  panino.setVegetables(vegetables);
  return panino;
 }
 }

A user will be then able to nicely build a Panino using this builder.


package com.stepbuilder.bar.client;
import com.stepbuilder.bar.Panino;
import com.stepbuilder.bar.PaninoBuilder;
public class Bar {

 public static void main(String[] args) {
  Panino marcoPanino = new PaninoBuilder().paninoCalled("marcoPanino")
    .breadType("baguette").withCheese("gorgonzola").withMeat("ham")
    .withVegetable("tomatos").build();

  System.out.println(marcoPanino);
 }
}

So far so good.
But what I don't like of the traditional Builder pattern is the following:

It does not really guide the user through the creation.
A user can always call the build method in any moment, even without the needed information.
There is no way to guide the user from a creation path instead of another based on conditions.
There is always the risk to leave your object in an inconsistent state.
All methods are always available, leaving the responsibility of which to use and when to use to the user who did not write the api.

For instance, in the Panino example, a user could write something like this:


package com.stepbuilder.bar.client;
import com.stepbuilder.bar.Panino;
import com.stepbuilder.bar.PaninoBuilder;
public class Bar {

 public static void main(String[] args) {
  Panino marcoPanino = new PaninoBuilder().paninoCalled("marcoPanino")
    .withCheese("gorgonzola").build();

  // or
  marcoPanino = new PaninoBuilder().withCheese("gorgonzola").build();
  // or
  marcoPanino = new PaninoBuilder().withMeat("ham").build();
  // or
  marcoPanino = new PaninoBuilder().build();
 }
}

All the above panino instances are wrong, and the user will not know until runtime when he will use the Panino object.
You can put a validation in the build method of course, but still a user will be not able to recover from a badly builder usage.
You could also put default values around all the required properties, but then the readability of the code will be lost ( new PaninoBuilder().build(); what are you building here?) and often you really need some input from the user (a user and password for a connection for example).

So here is my solution called Step builder, an extension of the Builder patter that fully guides the user through the creation of the object with no chances of confusion.

package com.stepbuilder.bar;
import java.util.ArrayList;
import java.util.List;
public class PaninoStepBuilder {

        public static FirstNameStep newBuilder() {
                return new Steps();
        }

        private PaninoStepBuilder() {
        }

        /**
         * First Builder Step in charge of the Panino name. 
         * Next Step available : BreadTypeStep
         */
        public static interface FirstNameStep {
                BreadTypeStep paninoCalled(String name);
        }

        /**
         * This step is in charge of the BreadType. 
         * Next Step available : MainFillingStep
         */
        public static interface BreadTypeStep {
                MainFillingStep breadType(String breadType);
        }

        /**
         * This step is in charge of setting the main filling (meat or fish). 
         * Meat choice : Next Step available : CheeseStep 
         * Fish choice : Next Step available : VegetableStep
         */
        public static interface MainFillingStep {
                CheeseStep meat(String meat);

                VegetableStep fish(String fish);
        }

        /**
         * This step is in charge of the cheese. 
         * Next Step available : VegetableStep
         */
        public static interface CheeseStep {
                VegetableStep noCheesePlease();

                VegetableStep withCheese(String cheese);
        }

        /**
         * This step is in charge of vegetables. 
         * Next Step available : BuildStep
         */
        public static interface VegetableStep {
                BuildStep noMoreVegetablesPlease();

                BuildStep noVegetablesPlease();

                VegetableStep addVegetable(String vegetable);
        }

        /**
         * This is the final step in charge of building the Panino Object.
         * Validation should be here.
         */
        public static interface BuildStep {
                Panino build();
        }

        private static class Steps implements FirstNameStep, BreadTypeStep, MainFillingStep, CheeseStep, VegetableStep, BuildStep {

                private String name;
                private String breadType;
                private String meat;
                private String fish;
                private String cheese;
                private final List<String> vegetables = new ArrayList<String>();

                public BreadTypeStep paninoCalled(String name) {
                        this.name = name;
                        return this;
                }

                public MainFillingStep breadType(String breadType) {
                        this.breadType = breadType;
                        return this;
                }

                public CheeseStep meat(String meat) {
                        this.meat = meat;
                        return this;
                }

                public VegetableStep fish(String fish) {
                        this.fish = fish;
                        return this;
                }

                public BuildStep noMoreVegetablesPlease() {
                        return this;
                }

                public BuildStep noVegetablesPlease() {
                        return this;
                }

                public VegetableStep addVegetable(String vegetable) {
                        this.vegetables.add(vegetable);
                        return this;
                }

                public VegetableStep noCheesePlease() {
                        return this;
                }

                public VegetableStep withCheese(String cheese) {
                        this.cheese = cheese;
                        return this;
                }

                public Panino build() {
                        Panino panino = new Panino(name);
                        panino.setBreadType(breadType);
                        if (fish != null) {
                                panino.setFish(fish);
                        } else {
                                panino.setMeat(meat);
                        }
                        if (cheese != null) {
                                panino.setCheese(cheese);
                        }
                        if (!vegetables.isEmpty()) {
                                panino.setVegetables(vegetables);
                        }
                        return panino;
                }

        }
}

The concept is simple:

Write creational steps inner classes or interfaces where each method knows what can be displayed next.
Implement all your steps interfaces in an inner static class.
Last step is the BuildStep, in charge of creating the object you need to build.

The user experience will be much more improved by the fact that he will only see the next step methods available, NO build method until is the right time to build the object.


package com.stepbuilder.bar.client;
import com.stepbuilder.bar.Panino;
import com.stepbuilder.bar.PaninoBuilder;
import com.stepbuilder.bar.PaninoStepBuilder;
public class Bar {

 public static void main(String[] args) {
  Panino solePanino = PaninoStepBuilder.newBuilder()
        .paninoCalled("sole panino")
        .breadType("baguette")
        .fish("sole")
        .addVegetable("tomato")
        .addVegetable("lettece")
        .noMoreVegetablesPlease()
        .build();

  
 }
}

The user will not be able to call the method breadType(String breadType) before calling the paninoCalled(String name) method, and so on.
Plus, using this pattern, if the user choose a fish panino, I will not give him the possibility to add cheese (i'm the chef, I know how to prepare a panino).
In the end, I will have a consistent Object and user will find extremely easy to use the API because he will have very few and selected choices per time.

We could have different panino traditional builders, FishPaninoBuilder, MeatPaninoBuilder, etc, but still we would face the inconsistent problems and the user will still need to understand exactly what was your idea behind the builder.
With the Step Builder the user will know without any doubt what input is required, making his and your life easier.

Remove duplications and fix bad names

When do you think a daily stand up is too crowded?

Building smart Builders

Conclusion

Even in the jdk there is bad code.

Java 7, TreeSet and NullPointerException.

How to update apt-get repositories in your old Linux distribution?

Easy testing SLAs on distributed components with grep4j

9 Must read books for developers by Uncle Bob Martin

Baobab to analyse remote disk space

ApacheBench - A quick n' easy performance test for your REST applications

Pool of ssh connections using Apache KeyedObjectPool

Monitoring the GC

GCHisto for Offline Analysis of Garbage Collection Data

Visual GC plugin + VisualVM for Live Analysis of Garbage Collection Data

ExecutorService VS CompletionService VS normal loop

Fix for bad performance in Eclipse Juno SR1

Step builder pattern on youtube

Chain of responsibility using Spring @Autowired List

JBoss HornetQ for Kids, Parents and Grandparents – Chapter 1

It’s now almost 4 years that I’m working with HornetQ and I think it’s time to share part of what I learnt so far.

What is HornetQ

Configuration

hornetq-jms.xml

hornetq-configuration.xml

JUnit4 Parameterized and Theories

Parameterized

Theories

Step Builder Pattern - WIKI-Definition

Definition

Contents

Advantages of using the Step Builder over the Builder pattern

Examples

Java

C#

Review Check box

The Meetings ERA

Meetings

Declining

Leaving

Have an Agenda and a Goal

Stand-Up Meetings

Iteration Planning Meetings

Iteration Restrospective and Demo

Arguments/Disagreements

Some development tips and tricks

1 ) Push the coding to the last

2 ) Simple = perfect

3 ) Paper and pen

4 ) Don't leave for tomorrow what you can do today

5 ) You have time!

6 ) Implement leaves first

7 ) Do Pair programming!

8 ) Rarely use checked Exceptions

9 ) Say NO to Hacks

10 ) Forget about comments, just write proper names!

11 ) Reinvent the wheels

A simple way to test distributed applications

Fluent mirror methods

Step Builder pattern