An introduction to Maven 2

This is an hands-on workshop about Maven. It will help you to get up and running with Maven if you don’t know Maven.
I have included the exercise that you can use to get your hands on Maven. This information is relevant also for Maven 3, though it was developed for Maven 2.

The presentation is here:

If you prefer the PDF, you can view it here: http://bit.ly/Ip7UYl

The exercise can be downloaded/viewed here http://bit.ly/KXB6v3

If you any feedback/comment/whatever comment it.


Quick introduction to REST and JAX-RS

Here are some slides introducing to REST world. Examples are using JAX-RS (JSR 311).

If we’re moving to the cloud-era, the undestanding of this architecture style is essential. In the cloud we are presented with services (Storage, Search, Graph, Geolocation, …) that we can and should use to build applications. Almost all of these services, available  in the cloud, provide some kind of interface and happens that, this  interfaces is, generally, a RESTful Web Service. If I want collaborate with these services I must talk the same language!! Moreover, exploring this architectural style in new applications opens the door for realy distributed and scalable systems, while the simplicity is kept high!

Here the slides:

PDF can be downloaded from here.


Software Architecture disruption?

:Adrian Colyer is a smart guy and he  put together, in a talk, what software architectures will look like for the next years. True is, most of the services you’re using online today follow these architecture principles. Nothing new, thought.

Nothing in this architecture is can go wrong,  it’s so simple! This type of architecture is the perfect fit for this ubiquitous platform that is Internet.

Btw,  SpringSource makes it really easy to develop applications in this way, just look to Spring Integration project, for example. They have a plenty of projects, built on top of Spring, that makes development of this type of architectures more, and more fun and easy.

(Ignore the sound problems at the beginning :) )

Contrast this with traditional “enterprise” architectures. Which side of the fence you want to be?


How to violate the Interface Segregation Principle

In my last post, I gave away some slides where OO Design Principles are introduced. I have an though about the big-fail that was the J2EE (before JEE5), in terms of violating the Interface Segregation Principle.

If you you are fortunate enough to have experienced the pain of writing applications with J2EE, then you recall that, for example, when you define an Stateless EJB, you have to implement the SessionBean interface.

Well, this is a clear violation of the Interface Segregation Principle, your EJB component have to implement the EJB lifecycle callback methods, even if you don’t need them. Right?

For instance:

public class MyComponent extends SessionBean {
    public void someCoolBusinessMethod() {
         // Business knowledge is coded here

    public void ejbCreate() {} //Don't have anything to do in this EJB lifecycle callback, but the interface forces me to implement the method

    public void ejbRemove()  {} //Don't have anything to do in this EJB lifecycle callback, but the interface forces me to implement the method

   public void ejbPassivate() { } //Don't have anything to do in this EJB lifecycle callback, but the interface forces me to implement the method

Latest versions of JEE (5 and 6), allows you to bind methods to component lifecycle events declaratively, with annotations of XML. For example:

public void MyOtheComponent {
    public String realBusinessMethod() {
        return "I do really cool stuff";

   private void letMeGo() {
   //Any business that should run before the object is left to the GC

They fixed it, but very behind time…


OO Design Principles, part 2

I’ve put a PDF online for the first part of OO Design principles, or guidelines… . Dowload it from here.

This second part is also the last one of this short introduction to OO design principles. I see these principles a the basic conceptual framework to build Object Oriented programs. It is the base model  for a lots of cool frameworks out there, some of them you’re using today to build really cool stuff!

I have also the PDF online. If you want to download it for future reference, you can do it from here.


Object Oriented Software Design Principles and guidelines

I have been refreshing the SOLID principles in Object Oriented. SOLID  stands for:

  • Single Responsability Principle
  • Open Closed Principle
  • Liskov Substitution Principle
  • Interface Segragation Principle, and
  • Dependency Inversion Principle

These are the principles for Object Oriented design, but not following them don’t make me a bad developer, of course. As with any principle, I can violate it if I have a reason to do it.

I had to give a talk about these principles, so I decided get them out  and in the next posts, I will publish a slideshare, per principle, that supportted my talks.

To get the talk started, I begin by introducing OO Programming. Oo programming introduction

View more presentations from Joao Pereira.

How to improve productivity when developing JEE based web applications

The title of this post was stolen from Stackoverflow, from this discussion:


I really like and agree with this point:

Being “the enterprise stack”, it is often used to create boring, ugly, “good enough” applications and, in general, enterprises tend not to attract great developers who love programming, and think and care about what they do. The quality of software in the enterprise world is not great.

There are exceptions, of course, but mainly from what I’ve seen from the past 10 years, this is, sadly, true. Why?


Programmer testing

Recently I’ve researched a little about programmer testing, which resulted in a slide set that I’m now sharing with you. These slides are the basis for a training, which included a lot of exercises, as I like to do.

It includes some information about:

  • Agile testing
  • Test driven development
  • Unit testing with JUnit
  • Test doubles and Mockito
  • Code coverage

If you have any feedback or question, please let me know by leaving a comment or send me an email.


Fluent interfaces while trying to make sense of Prototype Pattern

Sometimes I don’t have great opportunities to apply some nice concepts, but I have some time to learn them.

While trying to make some sense of the Prototype Pattern, I was doing some experiments and I needed, of course, the tests to prove my experiments.

It was when coding the tests, trying to define the client interface (not user interface :)), that to my mind came this article from Martin Fowler: Fluent Interface.

Well, what it matters are these two points:

  • Making your tests first helps you, a lot, to define not only the behavior, but also importantly, the client API.
  • Using Fluent Interface with a Builder, it’s a great way to send our message to the objects implementing the API.

Example of using a fluent interface:

package eu.jpereira.trainings.designpatterns.creational.prototype;

import static org.junit.Assert.*;

import java.util.List;
import java.util.Properties;

import org.junit.Test;

import eu.jpereira.trainings.designpatterns.creational.prototype.exception.CannotHaveZeroPartsException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.CouldNotCloneLastObjectException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.NeedToPackLastVehicleException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.VehicleDoesNotHavePartsException;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Shell;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Tire;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Vehicle;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.VehiclePartEnumeration;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.VehiclePartPropertiesEnumeration;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Window;
 * @author jpereira

public class ClientTest {

	 * Integration Test
	 * @throws CouldNotCloneLastObjectException
	 * @throws CannotHaveZeroPartsException
	 * @throws NeedToPackLastVehicleException
	 * @throws VehicleDoesNotHavePartsException
	public void testCreateBUS() throws CouldNotCloneLastObjectException, CannotHaveZeroPartsException, NeedToPackLastVehicleException, VehicleDoesNotHavePartsException {
		Client client = new Client();
		//create a bus car
		//Create props for tire
		Properties tiresProps = new Properties();

		//Create props for shell
		Properties shellProps = new Properties();

		Properties windowProps = new Properties();

		//client.createVehicle().with(new Tires()).times(4).
		Vehicle vehicle = client.vehicleBuilder().createVehicle().with(new Tire(tiresProps)).times(3).with(new Window(windowProps)).times(8).with(new Shell(shellProps)).times(1).packIt();
		//Get all windows
		List<VehiclePart> parts = vehicle.getParts(VehiclePartEnumeration.WINDOW);
		assertEquals(8, parts.size());

A hypothetical Builder implementation with a fluent interface:

package eu.jpereira.trainings.designpatterns.creational.prototype;

import java.util.ArrayList;
import java.util.List;

import eu.jpereira.trainings.designpatterns.creational.prototype.exception.CouldNotCloneLastObjectException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.CannotHaveZeroPartsException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.NeedToPackLastVehicleException;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Vehicle;

 * @author jpereira
public class SimpleVehicleBuilder implements VehicleBuilder {

	private List<VehiclePart> vehicleParts;
	public SimpleVehicleBuilder() {
		this.vehicleParts = createNewPartsBag();
	public VehicleBuilder createVehicle() throws NeedToPackLastVehicleException{
		//Just check this is allways the first call on the builder
		if (vehicleParts.size()!= 0) {
			throw new NeedToPackLastVehicleException();
		return this;

	public VehicleBuilder with(VehiclePart part) {
		return this;

	public VehicleBuilder times(int times) throws CouldNotCloneLastObjectException, CannotHaveZeroPartsException {
		if (times==0) {
			throw new CannotHaveZeroPartsException();
		//get the last one and clone it xtimes 
		if ( this.vehicleParts.size()>0) {
			VehiclePart lastObject = this.vehicleParts.get(this.vehicleParts.size()-1);
			//add it xtimes
			for (int i=0; i< times-1; i++) {
				//new object
				try {
				} catch (CloneNotSupportedException e) {
					//Could not clone it. Wrap exception
					throw new CouldNotCloneLastObjectException(e);
		return this;

	public Vehicle packIt() {
		Vehicle vehicle = new Vehicle(); 
		//clear this reference for the chicle parts.
		this.vehicleParts = createNewPartsBag();
		return vehicle;
	//Can be overriden by subclasses
	protected List<VehiclePart> createNewPartsBag() {
		return new ArrayList<VehiclePart>();


That’s it


You do not understand, yet, why do you need tests!

Why do I need tests in my software project? Keep bugs away? Yes! Keep quality high? Maybe. Can you define quality?

I see that people often justify the demand for a high test coverage with their desire to have quality in software projects, however they’re only seeing a part of the quality, the bugs visible to the customer. Quality, that word alone, can be very subjective, meaning different things to different people. Of course, having a bug free software means a high quality software, but if I have a bug free software and cannot add new features or improve existing ones, is this software a high quality software?

Now that we’re all doing “agile development” (right? at least you may think you’re doing, because you have daily meetings, review, sprints, etc), everyone should bear in mind one of the critical purposes of tests.

Big up-front designs do not work anymore, never worked for that matter (you soon loose integrity between the code and the design in the papers). We’re no able to make decisions based on the unknown (though some people may think they can), so we leave every decision to the last possible moment, until we have all, or most, information needed to make a reasonable decision.

One fundamental aspect of agile development is that you evolve your system as you go, you do it in iterations and every iteration is focusing only on what is needed to deliver the features you committed for that iteration. Your system will evolve, iteration after iteration.

With this evolution of your system, you will also evolve your architecture and design. You will not add database support on the first iteration if you don’t need a database, right? It’s waste. Right? So, from iteration to iteration your architecture and design will evolve, based on the features you have to develop and those you have developed. This is what evolutionary architecture and deign looks like, according to Martin Fowler.

But, how do you evolve your design and architecture? One of the key practices to do that is refactoring. Refactoring, again using Fowler’s knowledge, is “the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the changes of introducing bugs.”

Refactoring is one of the key practice of any project using any kind of agile development methodology, backed by testing and continuous integration. There is no way you can refactor your code if you do not have a safety net, i.e., if you don’t have something that keep you away from breaking existing functionality. This is a key point of tests, to allow you to evolve your system design and architecture.. Of course these test must be automated, needless to say that.