Tuesday, December 31, 2013

In matters of style, swim with the current; in matters of principle, stand like a rock.

I like very much that quote in the title(by Thomas Jefferson).
I found it in the programming book "The pragmatic programmer" some months ago.

Inspired by that quote, for the end of 2013 I want to briefly write a little post about an interesting and distinctive object oriented principle: "Tell don't ask"

It encourages "NOT TO" retrieve the state from an object, "IF" it is going to be used by the client code to make a decission on what to do next.

In my opinion, the reason why this is important is because we want to avoid client's decision becoming dependant on some state that is not under their control. Also exposing unnecesarily the state of the object(unless immutable) to the client code may not always be desirable.
We should try as much as possible, to avoid giving to the client code clues about the state of the object they are calling.

Let's have a look at an example that does not worry much about this principle(The Ask don't tell way - The opposite of Tell don't ask):

 public class Bouncer {  
    //...  
    public Person letIntoParty(Person person) {  
     if(person.getAge() >= 18)  
       return person  
     throw new UnderAgeException(person);  
    }  
   //..  
 }  

At first glance, this code doesn't really look wrong, but the thing is, that the logic of the bouncers object, is dependant on the age of the person. This kind of invisible logical dependency that the bouncer has with the persons age, makes the software less object oriented(Is not capable of making decissions by its own).

It may sound funny but in a Tell don't ask scenario, the person should be aware that cannot get into the party if is under 18.

Now an example of how we could do the same via Tell don't ask:

 public interface BouncerFriendly {  
   //...  
   public Person goParty();  
 }   
 public class Person implements BouncerFriendly {  
   private int age;  
   //...  
   public Person goParty() {  
     if(age >= 18)   
      return this;  
     throw new UnderAgeException(this);  
   }  
   //...  
 }  

There can be different ways of implementing it, but I like to "program to an interface not an implementation". As you can see the decision is made by the person and we avoid giving to the client code clues about the state. Therefore dangerous client decisions based on the state of the object that they are calling are no longer possible.

best wishes for the year 2014!

Sunday, November 3, 2013

If you could pick a superpower what would it be?


The other day at lunch time I had a very interesting conversation with my fellow colleagues.
We were talking about which superpower would be the most awesome to have.
There are so many superpowers to pick its difficult to decide which one is the best and most awesome.
I think that pretty much we all agreed that it would depend on which situation you are in.
That evening going back home by London's tube via central line, the huge crowd made me wish I coulda teleport.
I was meditating about this and I came to the conclusion that teleportation could probably be a bit risky(I yet don't know london very well and I didn't want to land in the wrong place so I gave up that idea). I changed my mind and a wished I could travel time, to go back have a little walk and take a tube latter when less people at the station.
Do you think is there one that can allow you to travel time?
The answer is Yes! there is one.
In this screencast I will show you the advantages time traveling can have for your software and your company and also I will show you how to prepare your software for time traveling when things get ugly. 

Note: Don't forget to set the quality to HD in the video player



Saturday, October 5, 2013

Can you please wrap the gift? It is for my grandma.

Have you ever been in the situation where you have to buy a gift for someone's birthday but you completely forgot until the very last moment?


What if that someone was somebody who you loved so much, let's say your grandma?

Thats not a good feeling uh?

Don't worry this things happen...

Mmmm... yeah... but what to do?
Maybe you have just some time to quickly go to the mall and get something simple and small...

Unfortunately, you know that It won't work, everyone will notice that you forgot to buy a gift and you just bought the first thing you found on your way to the birthday party.

Well... unless you are a gift wrapping expert ;)...


Yeah... I bet you guys know what this blog post is about.

The "Decorator" design pattern.
Imagine, you want to include some additional functionality to a method but you don't want to have impact in what it is already doing.
What you can do, is create a decorator class, that will wrap the original call to that method, and make all the clients call the decorator instead.



Step 1 - Extract an interface that exposes the function you want to decorate.

 public interface Task {  
  public void doSomething();  
 }  
 public class TaskImpl implements Task {  
  public void doSomething() {  
    System.out.println("doing something!");  
  }  
 }  

Step 2 - Create the decorator

 //Make it implement the interface  
 public class Decorator implements Task {  
   //Use composition to make sure you are decorating the right thing  
   private Task taskToDecorate;  
   public Decorator(Task task) {  
      this.taskToDecorate = task;  
   }  
   //implement the interface, but don't forget the original call  
   public void doSomething() {  
     taskToDecorate.doSomething();  
     System.out.println("www.javing.blogspot.com");  
   }  
 }  

Step 3 - Make the client use the decorator



 public class Client {  
   public static void main(String [] args) {  
           Task taskToDecorate = new TaskImpl();  
           Decorator decorator = new Decorator(taskToDecorate);  
           decorator.doSomething();  
   }  
 }  


I want to mention that on the internet I see that the decorator is almost in every post implemented using inheritance(e.g http://java.dzone.com/articles/design-patterns-decorator).
It also looks interesting and I will not critic it but I will just paste here a link to an interesting debate on stackoverflow: http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance





Tuesday, September 24, 2013

Keep calm and S.O.L.I.D

Last winter I had the chance to attend a talk by Robert.C.Martin(aka Uncle Bob) in Dublin. I think it was awesome. Uncle Bob is the author of Clean Code(I've got it signed by him in person :p) and also is a very influential person in the software industry.

I've been thinking to write something about some of the contributions he did to the industry and post it here on my blog since that talk.

One of the last things he said to us, was to read as much as we could...
Before starting to write this post I thought about those words for a while...
I think that it was a great advice.
Nobody negates that real experience is probably best, but reading books is also very important.
They carry the experiences of persons who were there before and also the rules and the principles those persons discovered and documented on their way.
Don't get me wrong, following rules and principles strictly does not always guarantee success("the world keeps changing") but understanding them can be of great help when facing great challenges.


So finally I decided to write this post about one of the biggest contributions of Uncle Bob to the world of object oriented programming, and that is the S.O.L.I.D principles.

Principle #1 
Single Responsibility Principle
If we have a class that has multiple responsibilities/features/reasons to change; Modifications done to it carry the risk of affecting other parts of the class(other responsibilities/features/reasons to change). 
In other words: Classes that do more than one thing are difficult to maintain. 


SRP says: "A class should have only one reason to change".
Lets have a look at an example:
 public class BMI {  
     //Stuff...  
      public void calculate(int heightInCm,int weightInGrms) {  
      //Implementation...  
     }  
     public void saveResults() {  
      //Implementation...  
     }   
     public TrainingPlan getTrainingPlan() {  
      //Implementation...  
     }  
 }  
As you can see, it is a clear example of a class with multiple reasons to change:

  •  Future business requirements might involve us changing the calculate method(e.g different metrics)
  •        Future business requirements might involve us changing the way the results are saved.
  •        Future business requirements might involve us changing the way the training plan is created based in the BMI.

We don't want all the above mentioned requirement changes to affect the class. If we don't seek for modularity at an early stage of development, we will very easily end up with difficult to maintain software.

What we need to do is think just on the one unique goal that the class will have.
Also we can think in what the class definitely will not do, so we can distiguish the other reasons to change that should not be there. Follow this way of thinking when fixing a violation of the SRP and it will help you detect the classes that you need to extract:

 public class BMICalculator {  
     //Stuff...  
         public void calculate(int heightInCm,int weightInGrms) {  
      //Implementation...  
     }  
     //Other methods that support the main goal of the class...  
 }  
 public class BMIToStorage {  
     //Stuff...  
         public void save(BMIResults results) {  
      //Implementation...  
     }  
     //Other methods that support the main goal of the class...  
 }  
 public class TrainingPlanCreator {  
     //Stuff...  
         public TrainingPlan getTrainingPlan(BMIResults results) {  
      //Implementation...  
     }  
     //Other methods that support the main goal of the class...  
 }  



Principle #2 
Open Close Principle

The motivation behind the Open Close principle is to extend/change behaviour without modifying the existing code. This principle says:
"modules should be open for extension but close for modification".
You probably think, that this sounds very contradictory, but in many OO programming languages like Java, there are mechanisms that will allow you to do this. 

One of those mechanisms is polymorphism. By defining abstract functions/methods

Let's have a look first at a violation of the open closed principle:

 public class Chef {  
      public void prepareMeal(Meal meal) {  
           if(meal.type.equals("veg")) {  
                prepareVeg();  
           }  
           else if(meal.type.equals("nonVeg")){  
                prepareNonVeg();  
           }  
      }  
      private void prepareVeg() {  
           //Implementation...  
      }  
      private void prepareNonVeg() {  
           //Implementation...  
      }  
 }  
 public class Meal {  
      String type;  
 }  
 public class NonVeg extends Meal {  
      public NonVeg() {  
           type = "nonVeg";  
      }  
 }  
 public class Veg extends Meal {  
      public Veg() {  
           type = "veg";  
      }  
 }  

In the above code, if a new requirement arrives saying to make some other type of meal different than veg and non veg, the class will need to be modified. The given above example is not maintainability friendly.

Let's see how to use polymorphism to remove that conditional logic and improve the solution:
 public class Chef {  
      public void prepareMeal(Meal meal) {  
           meal.cook();  
      }  
 }  
 public abstract class Meal {  
      public abstract void cook();  
 }  
 public class NonVeg extends Meal {  
      public void cook() {  
           //...  
      }  
 }  
 public class Veg extends Meal {  
      public void cook() {  
           //...  
      }  
 }  
As you can see the solution is more flexible, now it is easier to maintain and also we got rid of an evil flag that at long term will cause only problems when manipulating it. The class Meal that contains sensitive methods is open for extension but closed for modification.

The OCP principle is very powerful but we also must have in mind that by adding levels of abstraction(as alternative you can also think about Composition versus inheritance), we also increase the complexity and it is very important to understand that this principle should be applied only in those places where there is more likely to be often requirement changes. 

Principle #3 
Liskov substitution principle
This principle is concern about sub-classes classes replacing the behavior of their base class. 
If this occurs, the new classes can produce undesired effects when they are used/called in other parts of the program.

Liskov's Substitution Principle states that if a client is calling a base class, then the reference to the base class should be able to be replaced with a derived class without affecting the functionality of base class.

Lets have a look at an example of violation of this principle:

 public class Duck {  
      public void quack(){  
           //..            
      };  
      public void swim(){  
           //..  
    };  
 }  

Also a wild duck can quack and swim.
But what about Duck toys?

 public class DuckToy extends Duck {  
     private boolean batteriesIncluded;       
      public DuckToy(boolean batteriesIncluded) {  
           //...  
      }  
      public void swim() {  
           //...(This logic depends on the batteries)  
      }  
      public void playSound() {  
           //...  
      }  
 }  

As you see, some duck toys require batteries and also they don't really quack, they just play a sound. Even if there are no compilation errors and it looks tempting to include duck toy in this inheritance chain, this is clear violation of Liskov's substitution principle.
The reason is that if a client instantiates the base class, the derived class DuckToy, is not capable of replace it because the functionality is being affected.

 public class Pond {  
      public static void main(String[] args) {  
           Duck wildDuck = new WildDuck();  
           Duck duckToy = new DuckToy(true);  
           wildDuck.quack();  
           //This should not quack  
           duckToy.quack();  
           //Compilation error, real ducks don't play sounds or use batteries  
           //duckToy.playSound();  
      }  
 }  

One solution in this case could be to have a separate class by its own, to represent the duck toy.

 public class DuckToy {  
     private boolean batteriesIncluded;       
      public DuckToy(boolean batteriesIncluded) {  
           //...  
      }  
      public void swim() {  
           //...(This logic depends on the batteries)  
      }  
     public void quack() {  
           //Duck Toys don't quack  
      }  
      public void playSound() {  
           //...  
      }  
 }  

Principle #4 
Interface segregation principle

This is a very simple to understand principle, it says that clients should not be forced to implement interfaces they don't use Just that simple. Have a look at a violation of this principle:


 public interface Animal() {  
    public void fly();  
    public void run();  
    public void swim();  
 }  
 public class Dog implements Animal {  
    public void fly() {  
    //This is empty because dogs can't fly  
    }  
    public void run() {  
     //Implementation for running  
    }  
    public void swim() {  
     //Implementation for swimming  
    }  
 }  

That was horrible uh? So there are many ways you can avoid this.
One example could be to combine specific interfaces as per needed:

 public interface Runner() {  
    public void run();  
 }  
 public interface Swimmer() {  
    public void swim();  
 }  
 public interface Flyer() {  
    public void fly();  
 }  
 public class Dog implements Swimmer,Runner{  
    public void swim(){}  
    public void run(){}  
 }  
 public class Seagull implements Swimmer,Flyer{  
     public void swim(){}    
      public void fly(){}  
 }  

Degresion: While writing this example I just remembered a post that I wrote time ago about the use of Marker interfaces, that is also another interesting way of getting flexibility using interfaces. 

Principle #5 
Dependency inversion principle



This principle says "Don't depend on anything concrete, depend only on things that are abstract." So make sure that all of your dependencies point at things that are abstract.
This will bring safety to your code and also make it flexible.
Probably you are thinking that this principle, can be a bit radical; but obiously, in real following it always strictly is just very difficult(maybe even impossible).
A tip that you can use to verify that you are following this principle when you call a function, is to program to the interface and not the realization.

One great example of this principle in practice is the Template design pattern. Lets have a look first at a common violation of the principle:

 public class PizzaMaker {  
   public Pizza makeMeatPizza() {  
      Pizza pizza = new Pizza();  
     pizza.setBase(true);  
     pizza.setCheese(true);  
     pizza.setOregano(true);  
     pizza.setTomato(true);  
     pizza.setMeat(true);  
     cook(pizza);  
   }  
   public Pizza makeVeggiePizza() {  
      Pizza pizza = new Pizza();  
     pizza.setBase(true);  
     pizza.setCheese(true);  
     pizza.setOregano(true);  
     pizza.setTomato(true);  
     pizza.setMeat(false);  
     pizza.setVegetables(true);  
     cook(pizza);  
   }  
   private Pizza cook(Pizza pizza) {  
   //...  
   }  
 }  

The above example is a badly coded class that makes 2 types of pizzas... There are many bad things in this piece of code, but I will just focus on the violation of the principle we are discussing.
Since every call done to the pizza object is to a concrete method, what we get is something very rigid and inflexible.
Every pizza has some ingredients that are mandatory, such as the base, tomato, cheese and oregano,but the rest are optional, so: why do we care about making calls to concrete methods, to set those extra ingredients, if is not even our concern?

In the following snippet of code, a template method is introduced to abstract the optional part and let sub-classes implement them.

 public abstract class PizzaMaker {  
  //A method that has a call to an unimplemented abstract function,   
  //is known as a template method  
   public Pizza make() {  
     Pizza pizza = addBasicIngredients();  
     addSpecificIngredients(pizza);  
     cook(pizza);  
     return pizza;  
   }  
   public abstract void addSpecificIngredients(Pizza pizza);  
   private Pizza addBasicIngredients() {  
     Pizza pizza = new Pizza();  
     pizza.setBase(true);  
     pizza.setCheese(true);  
     pizza.setOregano(true);  
     pizza.setTomato(true);  
     return pizza;  
   }  
   private void cook(Pizza pizza) {  
     //...  
   }  
 }  
 public class MeatPizzaMaker extends PizzaMaker {  
   @Override  
   public void addSpecificIngredients(Pizza pizza) {  
     pizza.setMeat(true);  
     pizza.setVegetables(false);  
   }  
 }    
 public class VegetablesPizzaMaker extends PizzaMaker {  
   @Override  
   public void addSpecificIngredients(Pizza pizza) {  
     pizza.setMeat(false);  
     pizza.setVegetables(true);  
   }  
 }  

The S.O.L.I.D principles, were identified by Robert C.Martin, but the Acronym was created by Michael Feathers in the year 2000, today they are well known in the world of object oriented sofwtare and many there is plenty literature on books and internet about them.

Just for the end of this post I would like to share with you a great podcast interview that I found on the web, were Uncle Bob, explains S.O.L.I.D in detail.



Wednesday, September 4, 2013

In London you will never be hungry.

I recently arrived to London, I have to say that I am very impressed.
Everything is really beatiful and the weather is great. One of the things that kept my attention is the huge amount of places you can pick for eating. I love food, and while eating at an Indian place at whitechappel yesterday, I've got inspired for my next blog post.

Did your programming teacher ever gave you that exercise, where you had to create a program to pick some food from a restaurant menu and try to apply some design pattern to it?
While looking through the menu at that Indian place I was remembering that homework, and I think it was some kind of factory pattern what we were expected to use back then to solve it.

This article is about the "abstract factory" pattern. Because of its purpose, some people may also refer to it as the "Toolkit pattern".
Let's have a look at it...

The "abstract factory" pattern is an enhancement of the "factory method" pattern(maybe better to say-It uses it...). Let's just refresh quickly our minds about the "factory method" pattern.

The "factory method" pattern is a creational pattern that intents to release the client from the task of creating objects.
The main reasons are:
 -objects may have a complex/dependant initialization mechanism which does not interest the client.
 -the client doesn't know which is the object type that he needs until runtime.

To implement a factory method what we need is create a method that will take an argument(passed at runtime) and add to it conditional logic that will create one object type or other based on the passed parameter.

The only way in which abstract factory differs from factory method is that with abstract factory we just create factories and let the client use the factories for create objects.

Both "abstract factory" and "factory method" are widely used in software engineering. Now let's have look a simple example where an "abstract factory".

In this UML diagram, we see how the client interacts only with the abstract factory and even the objects that creates using those factories are abstract(Food). The client does not know or care at all how those objects are created. As a result, the client call is simplier and does not have complex conditional logic to decide the object that is required.


 public class Customer {  
   public void orderFood() {  
     System.out.println("Which type of food would you like?");  
     Scanner scanner = new Scanner(System.in);  
     System.out.println("1- Mexican");  
     System.out.println("2- Chinese");  
     System.out.println("3- Indian");  
     int option = scanner.nextInt();  
     FoodFactory factory = FactoryMaker.getFactory(option);  
     Food food = factory.prepareFood();  
     System.out.print("Here are your " + food.getClass().getName());  
   }  
 }  
In the above code we see what we just mentioned above. The client using the abstract factory only interacts with abstractions, so there is not much client code.
 public interface FoodFactory {  
   public Food prepareFood();  
 }  
If we want to extend our software and have some other types of factories, we need to implement the comon interface that the client uses to access the factories.
 public class MexicanFoodFactory implements FoodFactory {  
   @Override  
   public MexicanFood prepareFood() {  
     Scanner scanner = new Scanner(System.in);  
     System.out.println("Mexican food menu:");  
     System.out.println("1- Fajitas");  
     System.out.println("2- Tacos");  
     return getFood(scanner.nextInt());  
   }  
   private MexicanFood getFood(int choice) {  
     switch (choice) {  
       case 1:  
         return new Fajitas();  
       case 2:  
         return new Tacos();  
     }  
     return null;  
   }  
 }  
This code above is just one sample implementation of one of those factories. As you can see, it has a "factory method" pattern in itself that will help return the appropiate food object(Just notice that the return type is an abstract class)
 public class FactoryMaker {  
   public static FoodFactory getFactory(int choice) {  
     switch (choice) {  
       case 1:  
         return new MexicanFoodFactory();  
       case 2:  
         return new ChineseFoodFactory();  
       case 3:  
         return new IndianFoodFactory();  
     }  
     return null;  
   }  
 }  
But to allow the client create the factories we will need some kind of gadget that will allow the client create one factory or other at runtime. That is why we need this class called FactoryMaker(This is again another sample of "factory method" but it will return an abstract/interface type)
 public abstract class Food {  
 }  
 public abstract class MexicanFood extends Food {  
 }  
 public class Fajitas extends MexicanFood {  
 }  
This 3 classes above are just part of the domain model.If you want you can make abstract those that you don't need to instantiate using the "new" keyword. The factories task is to create each of the concrete objects but use abstract return types so the client does not know about the type of the object being returned.

 Even if this pattern looks really interesting there are 2 important disadvantages of using it:
 - the bigger the model gets(more products), the more difficult is to maintain.
 - it violates the open-closed principle


Bon Appetit!

Friday, July 26, 2013

If you break something you have to pay for it!

Many years ago in Spain(as a kid) I was probably in second or third year of primary school, I had to buy a gift for somebody's birthday.
All I had was 500 pesetas(a bit less than 3 euros) and I wanted to buy something cheap, but at the same time beautiful and also decorative.
I was walking around the neighbourhood and not far away from my house, I found a glass craft shop.
I went into the shop and started walking the corridors, there were all sort of glass crafts: from ashtrays to lamps... and everything was all over the place, not just in selves also there were dozens of crafts on the ground.
Quickly I noticed a little figure with a price tag that said 500, that was the gift I wanted to buy. Unfortunately It was in the ground placed at least 2 meters away from were I was, and there were lots of other glass crafts on the way to it. If I wanted to reach it all I could do was move away each of those other crafts that were on the way. I carefully started doing it until I've got the figure I wanted. When I was ready to go back and turned around the shop attendant was looking at me and said: "If you break something you have to pay for it!", I've got a bit scared and... well... is up to your imagination how this story ended.

This story reminds me a bit to the feeling that we all have sometimes when unit testing some code: "Is this really a unit test?".
Sometimes we think we tested correctly but if we are not extra careful with our unit tests we might unconsciously be creating a poisonous integration test.

Let's have a look at an example:

1:  public class ProductDiscountCalculator {  
2:       public void apply50PercentDiscount(Product product) {  
3:            ProductManager manager = new ProductManager();  
4:            if(product.isExpired()) {  
5:                 product.setPrice(product.getPrice() - product.getPrice() * 0.5);  
6:            }  
7:            manager.updateProduct(product);  
8:       }  
9:  }  

We want to unit test the method in the above class and this is what we do:

1:  public class ProductDiscountCalculatorSpecification {  
2:       private ProductDiscountCalculator calculator;  
3:       private Product sampleProduct;  
4:       @Before  
5:       public void arrange() {  
6:            calculator = new ProductDiscountCalculator();  
7:            sampleProduct = new Product();  
8:            sampleProduct.setPrice(10);  
9:            sampleProduct.setExpired(true);  
10:       }  
11:       @Test  
12:       public void priceDiscounted50Percent() {  
13:            calculator.apply50PercentDiscount(sampleProduct);  
14:            assertThat(sampleProduct.getPrice(), is(5D));  
15:       }  
16:  }  

When we run this test, it will go green, but... Is this really a unit test?
What about this line:
 manager.updateProduct(product);  

That line is very dangerous, maybe it is accessing a database and we are poisoning it every time we run our tests.
That's why we need to have extra careful and make sure that we use techniques to break dependencies, stubs, fakes, spies, mocks... or anything
that takes, to make sure at 100% that we are unit testing.
Lets see how we can break the ProductManager dependency and create a more testable alternative:

1:  public class ProductDiscountCalculator {  
2:       private ProductManager manager;  
3:       public ProductDiscountCalculator(ProductManager manager) {  
4:            this.manager = manager;  
5:       }  
6:       public void apply50PercentDiscount(Product product) {  
7:            if(product.isExpired()) {  
8:                 product.setPrice(product.getPrice() - product.getPrice() * 0.5);  
9:            }  
10:            manager.updateProduct(product);  
11:       }  
12:  }  

In the above example we extract the dependency and make sure that we can set it from outside of the class.  We could do it different ways I just used composition for this example.

1:  public class ProductDiscountCalculatorSpecification {  
2:       class ProductManagerStub extends ProductManager {  
3:            @Override  
4:            public void updateProduct(Product product) {  
5:            }  
6:       }  
7:       private ProductDiscountCalculator calculator;  
8:       private Product sampleProduct;  
9:       @Before  
10:       public void arrange() {  
11:            calculator = new ProductDiscountCalculator(new ProductManagerStub());  
12:            sampleProduct = new Product();  
13:            sampleProduct.setPrice(10);  
14:            sampleProduct.setExpired(true);  
15:       }  
16:       @Test  
17:       public void priceDiscounted50Percent() {  
18:            calculator.apply50PercentDiscount(sampleProduct);  
19:            assertThat(sampleProduct.getPrice(), is(5D));  
20:       }  
21:  }  

In what regards to the test I used the subclass and override technique to make sure that we are not poisoning a the database if the real object was passed. Since the object that we are passing to the constructor of ProductDiscountCalculator is just an stub, we are now 100% sure that this was correctly tested without poisonous integration tests.

Monday, May 27, 2013

Duplication - A bit between your teeth

I presume that pretty much everybody who has been in contact with the java programming language either in studies or professionally even for a little bit, knows that duplication is a code smell.
We all know that some consequences of duplication are: less maintainability, less readability, the code is more likely to contain bugs, performance issues... and many more.

I think there should not be need to explain what duplication is, but just in case let's write only one line to define it and also make sure that we understand it:
"Duplication is the existence of multiple copies of a single concept"


Are there any doubts until this point?...
Please go back and read once more the definition if you still are not sure about it.

So, how do we fix duplication?


But if it is so easy to understand what duplication is and also how simple it is to refactor, why do we find it all over the place, no matter what software we are looking at.

Well... there are many reasons why there is duplication all over the place:
  • sometimes we just rush to get things done and we don't care about it. 
  • maybe we think that refactoring is boring or is not profitable, so we have no patience to do it.
  • other times we think there are always more important things to do and duplication is not really affecting us.
  •  also sometimes when we want to do something about it, we just can't see it even if it is in front of us.             

 So, what do you think?... Any of this may be the reason why you are not fixing duplication?
If your reason is any of the first 3, I am sorry, but this blogpost will not be of any use to you and the best you can do is close this browser tab or surf somewhere else.

But if it is the 4th, the reason why you are not fixing the duplication, then you might find the following lines very interesting....

This is the secret why many programmers sometimes find it so difficult to deal with duplication...

There are different kinds of duplication, this are some of the most important:
  • Literal
  • Structural
  • Semantic

Literal duplication
This is a very easy to spot kind of duplication. It is basically literal values that are repeated in our code.

e.g
 public class RepeaterSpecification {  
      @Test  
      public void repeatsInput() {  
               assertThat("value",is(repeat("value")));  
      }  
      @Test  
      public void repeatsEmptyInput() {  
              assertThat("",is(repeat("")));  
      }  
     //...  
 }  

The most common way to fix this type of duplication is to create a local variable. Let's have a look at a possible refactor:

 public class RepeaterSpecification {  
      @Test  
      public void repeatsInput() {  
         String input = "value";  
         assertThat(input,is(repeat(input)));  
      }  
      @Test  
      public void repeatsEmptyInput() {  
         String input = "";  
         assertThat(input,is(repeat(input)));  
      }  
     //...  
 }  
It looks like we no longer have literal duplication. But unfortunately as you probably noticed, sometimes when fixing one type of duplication we generate another type of duplication. Keep reading to find out more...

Structural duplication
We can recognize this situation when the logic is duplicated but it operates on different data.
See this situation in the following example:

e.g
 public class RepeaterSpecification {  
      @Test  
      public void repeatsInput() {  
         String input = "value";  
         assertThat(input,is(repeat(input)));  
      }  
      @Test  
      public void repeatsEmptyInput() {  
         String input = "";  
         assertThat(input,is(repeat(input)));  
      }  
     //...  
 }  


As you can see I toke this code from the previous example. The assertThat() operation is identical, the only difference is the data that it uses. Let's have a little look at a way how to fix structural duplication:


public class RepeaterSpecification {  
      
      @Test  
      public void repeatsInput() {  
         assertThatInputIsRepeated("value");  
      }  

      @Test  
      public void repeatsEmptyInput() {  
         assertThatInputIsRepeated("");  
      }
 
      private void assertThatInputIsRepeated(String input) {  
            assertThat(input,is(repeat(input)));
      }
     //...  
 }


Now that we extracted the method that does the assertion we no longer have duplication.

Semantic duplication
This is  the situation where different code implementations represent the same functionality or concept.
The definition of semantic duplication teaches us that duplication can be invisible from the point of view of the code("The definition from the start of this post makes a way more sense now, uh? :)" ). This kind of duplication is probably one of the most difficult to spot.

e.g
public class TeamValidator {       
  
      public boolean isThereALeader(List<Members> team) {  
           Iterator<Member> iterator = team.getIterator();
           while(iterator.hasNext()) {
              Member member = iterator.next();
              String role = member.getRole();
              if(role.equals("Leader"))
                return true;
           }  
           return false;
      }  

      public boolean areThereAtLeast2NewJoiners(List<Members> team) {  
            for(Member member:team) {
                DateTime aMonthAgo = DateTime.now().minusMonths(1);
                if(member.startingDate().isAfter(aMonthAgo))
                return true; 
            }
            return false;   
      }
     //...  
 }


At first glance, when we look at the two methods in the code above we cannot really see much duplication. No matter how much we look at it, we will not see it. Semantic duplication is invisible from the implementation point of view. To spot it what we need to do is spot the behavioral anti pattern that is hidden in the code. If we think about it, basically the repetition going on is that both methods iterate one list of the same type and then apply certain criteria(Completely different implementations but one same concept).
Semantic duplication is more difficult to fix than other types of duplication and often requires a bigger refactoring effort. Here is one possible solution that helps us get rid of it using Java generics:

 public class TeamValidator {      
    public boolean isThereALeader(List<Member> team) {   
         return new LeaderVerifier<Member>().evaluate(team);  
    }   
    public boolean areThereAtLeast2NewJoiners(List<Member> team) {   
         return new NewJoinersVerifier<Member>().evaluate(team);  
    }  
 }  


 public abstract class LoopEvaluator<T> {

 public boolean evaluate(List<T> list) {
  for (T element : list) {
   if(evaluateElement(element)) {
    return true;
   }
  }
  return false;
 }
 
 public abstract boolean evaluateElement(T element);
 
}


public class LeaderVerifier<T extends Member> extends LoopEvaluator<T> {

 @Override
 public boolean evaluateElement(T element) {
  return element.getRole().equals("leader");
 } 
}



public class NewJoinersVerifier<T extends Member> extends LoopEvaluator<T> {

 private int newJoiners;
 
 @Override
 public boolean evaluate(List<T> list) { 
  this.newJoiners = 0;
  return super.evaluate(list);
 }
 
 @Override
 public boolean evaluateElement(T element) {
  DateTime aMonthAgo = DateTime.now().minusMonths(1);
  if(element.startingDate().isAfter(aMonthAgo)) 
   this.newJoiners++;
  return newJoiners == 2;
 }
}


Duplication is not a little topic at all. The 3 types of duplication I mentioned in this post are from my point of view some of the most common but there are many more. Here a link where I found where at the bottom you can find a mention to other kinds of duplication: http://blogs.agilefaqs.com/tag/code-smells/


                                                                     
 I am the spaghetti monster, You cant get rid of me!!!! Hahahaha......

Just to conclude this post, I want to say that I have the impression that duplication many times is an  underestimated code smell that undetected grows and grows and ends up transforming systems into spaghetti monsters.

Lets get rid of it while it is just a bit between your teeth! ;)







Thursday, May 23, 2013

How to verify that void methods were called using Mockito

Mockito is one of the most popular mocking frameworks for java.
This post Is just little miscellaneous where I will show you how to mock and verify a void method call.

Sometimes when we test a call to a void method all we want to do is just make sure that at some point in its life cycle, another method will be called with certain parameters.
Let's see the following example:
 public class SomeClass {  
      private OtherClass otherClass;  
     
      public SomeClass(OtherClass otherClass) {  
           this.otherClass = otherClass;  
      }  
      protected void firstMethod(int value) {  
           if(value > 0) {  
                secondMethod("Yes!");  
           }  
           else {  
                secondMethod("No!");  
           }  
      }  
      private void secondMethod(String value) {  
           otherClass.someMethod(value);  
      }       
 }  

In the above piece of legacy code the most important part is a method called "someMethod()". We must make sure that it is called in a proper way, but unfortunately it belongs to a dependency to which we have no access and also to make it more complicated it is inside a private method.

Mockito framework could help us mock and verify that method call.
Here is how we can do it:
 package demo;
 import static org.mockito.Mockito.verify;  
 import org.junit.Before;  
 import org.junit.Test;  
 import org.mockito.Mock;  
 import org.mockito.MockitoAnnotations;  
 import code.OtherClass;  
 import code.SomeClass;  
 public class TestClass {  
      @Mock  
      private OtherClass otherClass;  
      //Class under test  
      private SomeClass someClass;  
      @Before  
      public void prepareDependencies() {  
           MockitoAnnotations.initMocks(this);       
           someClass = new SomeClass(otherClass);  
      }  
      @Test  
      public void is_the_value_greater_than_zero() {  
           someClass.firstMethod(8);  
           verify(otherClass).someMethod("Yes!");  
      }  
      @Test  
      public void is_the_value_smaller_than_zero() {  
           someClass.firstMethod(-1);  
           verify(otherClass).someMethod("No!");  
      }  
 }  

The most important things to highlight in this test class are:
  • The class under test is never mocked.
  • The dependencies of the class under test need to be mocked.
  • By calling a method on a mock object we will mock that method call
  • By using the verify() method we will test that at some point the method from the mock was called  with the exact same parameters.
  • The test class can access the protected method because the package name is the same.(But of course in your project structure test will be under src/test/java and production code under src/main/java)

Monday, May 6, 2013

Using transaction attributes in EJB 3.1 - Container Managed Transactions

When somebody refers to container managed transactions, what we understand is that the EJB container is responsible of managing transactionality for the methods inside EJB's deployed in the EJB container.

The theory behind transaction management in EJB 3.1 is not brief and probably my post would become to long if I tried to explain other important concepts. In this post I want to just focus on an important concept known as the transaction attribute.

To simplify this concept, I will refer to it, as a configuration given to a method/function within an EJB, that will tell the EJB container what to do with the incoming transaction when that method is called.

The thing that will determine what will occur with the transaction when a certain transaction attribute is used will be the transactional context from where the method was called. In other words, if the enterprise method annotated with a certain attribute was called from a non-transactional(e.g a web page) will manage the transaction differently than if it was called from a transactional context(e.g another EJB). And this is the reason why sometimes we have to choose wisely our transaction attributes.

To use transaction attributes in our EJB's its very simple, all you need to do is use an annotation:
 @Stateful  
 public class SomeBean implements SomeInterface {  
   @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)  
   public void someMethod(){  
    //...  
   }  
   //...  
 }  

Now that we know how to annotate the methods, lets see what will occur when each of the transaction attributes is used:

REQUIRES_NEW
When the calling method is not in a transaction: Starts a new transaction.
When the calling method is in a transaction:  Suspends the existing transaction and creates a new one.

REQUIRED

When the calling method is not in a transaction: Starts a new transaction.
When the calling method is in a transaction:  Executes in existing transaction.

NEVER

When the calling method is not in a transaction: It will execute with no transaction.
When the calling method is in a transaction:  It will throw an exception.

NOT_SUPPORTED

When the calling method is not in a transaction: It will execute with no transaction
When the calling method is in a transaction: It will execute with no transaction(No exception will be thrown)  

SUPPORTS

When the calling method is not in a transaction: It will execute with no transaction.
When the calling method is in a transaction:  Executes in existing transaction.

MANDATORY

When the calling method is not in a transaction:  It will throw an exception.
When the calling method is in a transaction: Executes in existing transaction(Execution continues because the caller was already in a transaction).




Saturday, April 13, 2013

How to unzip a .zip file with Zip4j

3 days ago I discovered a  cool easy to use java tool for working with zip files.
It is called Zip4j.

Have a look at this super simple example that will allow you to unzip a file into a given path in your computer:

 String source = "folder/source.zip";  
 String destination = "folder/source/";    
   try {  
     ZipFile zipFile = new ZipFile(source);  
     zipFile.extractAll(destination);  
   } catch (ZipException e) {  
     e.printStackTrace();  
   }  

Use this if the unzip file has a password:

 String source = "folder/source.zip";  
 String destination = "folder/source/";  
 String password = "password";  
 try {  
   ZipFile zipFile = new ZipFile(source);  
   if (zipFile.isEncrypted()) {  
     zipFile.setPassword(password);  
   }  
   zipFile.extractAll(destination);  
 } catch (ZipException e) {  
   e.printStackTrace();  
 }  

That was easy and cool.
Are you now thinking the same as I am thinking?...
Let's go brute force zip passwords!!! :P

Hahaha.... I am just joking don't do that, this is not a hacking blog( yet! :p )  I hope you enjoyed this post. Use Zip4j with care.

Sunday, April 7, 2013

How do I add a project as a dependency of another project and why would I do so? (Maven)

When working in a Java EE distributed system many times we have to manage the dependencies of each of our nodes. Our system will be full of other projects, representing different aspects of the system.


In this post I want to explain how to include a project as a dependency of another project by using an example scenario that is very common in real life: "Sharing the domain model between nodes".

As we know the domain model is the representation of the data that our system works with. To avoid inconsistencies it is a good practice, that each of the projects in our system that are supposed to interact with the domain model do so in a safe way. By interacting safely, we mean look at the domain model as a provided service that the projects use, but without the possibility of corrupting it.

One of the most common ways of achieving our goal would be, to create the domain model, as a separate project, and reference it there where it is needed. Doing this none of the distributed projects of our system will have to be responsible for the domain model, their only responsibility will be to keep the dependency updated, to make sure that they are using the very latest version.


In the following image we can see an example of what could perfectly be a class, in the domain model of a distributed system(Just a trivial example):



This is the project that contains the model and if we want to make sure that it can be use as a dependency in another project, we need to make sure it is packed in a .jar (note the content of the packaging tag in the next image).



When this program is built using the mvn clean install command, it will generate a .jar file that will be stored in the local maven repository(~/.m2). If the build process is successful we should see a message similar to this in our console(Note the message that says that the .jar was installed in the repo):


 A very important thing to understand about this process, is that future versions of this project will need to be increased and also will not have the SNAPSHOT postfix when deployed as stable version. If this process is always done manually by the developer, it possible to make mistakes and that is why in real live, many companies use special tools for building and deploying such as Jenkins and Hudson. The set of tasks and tools that allows distributed software built and deployed automatically in a safe way, is known as Continuous Integration.


Now that we have built and deployed(In this example we just deployed it in the local maven repo) our new domain model, we can reference it in another project.
In this example I will use the model in a project that represents a data access layer for a distributed system, to do so, we will need to add the dependency to the correct version of the model inside the pom.xml file:





Once we build our project we will see that the .jar that contains the model is in the class path and we can use it with no problem in this project:



 When a change is done on those projects on which other projects depend, in order to avoid versions miss matches and inconsistencies, it is a good practice to update all the versions in the dependent projects, re-build and re-deploy.

Now that we know how to add the domain model as a dependency we can add it to other projects that are part of our system(e.g a web app).

Just as a little appendix and even if is not directly related to the post, there is an excellent text about why the Data Transfer Object pattern is no longer needed in JEE in the book: Enterprise JEE Patterns. Rethinking best practices(page 273).  There is a very interesting explanation of why DTO's became superfluous when the JPA entities were introduced. 

Friday, March 22, 2013

How do private methods affect our software testability?

 How many times did we hear the question:
“Should we test private methods?”
In this post I want to share with you my thoughts about this question and how I think we should proceed when having this doubt.
Methods with the access modifier private are code as the rest of the application, so this mean that they can potentially hide bugs.  So after a first impression my answer to that question is: “Yes, we should!”.  
Wait, a second… before you get mad at me. I want to rephrase my statement.
I think that question is completely not in place.  Instead of asking “Should we test private methods?”, we should ask: “How do private methods affect our software testability?”
Let’s consider different approaches to deal with private methods and see their pros and cons from the testability point of view:

Scenario 1 – Ok,ok you leave me no choice but reflection
This is what the official Java tutorials say about reflection: 
“Reflection is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique and can enable applications to perform operations which would otherwise be impossible.”
Ok, let’s  give it a try, imagine we have some private method, such as this one:



Hhmmm… So how to do this? Oh my god, do I really have to use reflection? Are you sure?
Let’s investigate a bit before making any decision.
Weeks ago I spent one full afternoon searching the internet looking for testability assurance pattern to test this in java. The only interesting discovery I did was that C# developers have a pattern for this called  “Internals Visible To Attribute”.  Unfortunately (Or maybe fortunately hehe…) that technique is not compatible with java.
There has to be an alternative, why can’t we just change the access modifier and test it normally?...
The common answer you get, when you ask that is:  You will compromise security, you will break encapsulation, you are lazy…
Ok,ok,you leave me no choice but reflection:

 Please don’t do this at your workplace J
Let’s see the Pros and Cons now.

Pros:
- The test is green and I tested the piece of code that I wanted to test
- I did not compromise the security of my software(:P Whatever….)
- I am an expert because the official java tutorials say that only cool dudes like me can use reflection.
Cons:
- A simple rename done by anybody to the method, return type or parameter will break the test and I will have to come back to rewrite the test. This type of test is very difficult to maintain.
- I broke the Security of my software. What am I talking about??? How is that possible if the method still private in the production code?? Hacking the internals of a class is a security.
- See how long that test is. Imagine you have to do this for a longer and more complex method.
More drawbacks(Taken from Java official tutorials website):



Scenario 2 – There is always a way out.
As mentioned in the previous scenario a design pattern that can help us testing private fields does not exist. But there are always ways out. Here I am going to suggest 2 and explain them:

- Protect your method: Just change the access modifier to protected. This will allow you to stub the method call and test using a pattern called Subclass & Override. Basically on your test package, you will be creating a fake that extends the class under test and then override using your expectations. You will then use that fake on your test.
This is a very common breaking dependency technique, since that private method will for sure be called somewhere else within the class and present a dependency inside other method/s(Must be broken in order to increase testability).
I don’t agree with this being a security risk because various reasons, one of them is that probably that method should not be private or, is too long to be tested indirectly, or probably that method should not even be there.
The only disadvantage I see is a decrease in the quality of the design, but I will justify that as the price we need to pay when we build software without using TDD or having testability in mind.

- Extract until you drop: Robert C. Martin in his book “Clean Code”, describes a refactoring methodology called “Extract until you drop”, the idea is refactor the code as much as possible until the point there the methods have not more than 4 lines of code. He says that a line with just a curly braces also count as a line.  If you think about it, your methods would be able to use an “if else” statement of just one line in each of the clauses.
If we want to unit test, we need to have units.  After doing this exhaustively on the method or class under test, we will probably see how that method was probably refactored into a new class, or maybe became so small that it can be tested indirectly via another method with no risk at all, since there are no longer inflection points(Places where logic of the software can potentially take a different path).
The main disadvantages of this approach will probably be that doing it probably would take too long, also on our way and specially if we are dealing with legacy code, we will need to use a lot of breaking dependency techniques and this will present a learning curve that will push us to break some of the design rules we were highly tight too in the past when the system was initially built.  But the benefit will be visible at short, mid and long term.

If you are concern about testability and you believe that testability is the path to quality in modern software, then the right question is How do private methods affect our software testability?

Sunday, March 17, 2013

PrimePush in Jboss AS 7

It toke me a while to make PrimePush work in JBoss AS 7.
In this post I will just paste the codes of a simple hello world like program that uses PrimePush libraries to submit an String to a web socket.

The requirement for this exercise, is that you know to create a new JSF project with maven and deploy it into the JBoss 7 AS application server. All the steps to do that can be found in one of my previous post:
http://javing.blogspot.ie/2013/01/how-to-create-new-jsf-21-project-and.html

Once you have your project ready, lets make the following changes in the configuration files:

pom.xml


1:  <?xml version="1.0" encoding="UTF-8"?>  
2:  <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
3:       xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
4:       <modelVersion>4.0.0</modelVersion>  
5:       <groupId>my.test.project</groupId>  
6:       <artifactId>my.test.project</artifactId>  
7:       <version>0.0.1-SNAPSHOT</version>  
8:       <packaging>war</packaging>  
9:       <name>Java EE 6 webapp project</name>  
10:       <properties>  
11:            <jboss.bom.version>1.0.0.Final</jboss.bom.version>  
12:            <version.faces.mojarra>2.1.7</version.faces.mojarra>  
13:            <version.primefaces>3.4.2</version.primefaces>  
14:            <version.atmosphere>1.0.8</version.atmosphere>  
15:       </properties>  
16:       <dependencyManagement>  
17:            <dependencies>  
18:                 <dependency>  
19:                      <groupId>org.jboss.bom</groupId>  
20:                      <artifactId>jboss-javaee-6.0-with-tools</artifactId>  
21:                      <version>${jboss.bom.version}</version>  
22:                      <type>pom</type>  
23:                      <scope>import</scope>  
24:                 </dependency>  
25:                 <dependency>  
26:                      <groupId>junit</groupId>  
27:                      <artifactId>junit</artifactId>  
28:                      <version>4.10</version>  
29:                      <type>jar</type>  
30:                      <scope>test</scope>  
31:                 </dependency>  
32:            </dependencies>  
33:       </dependencyManagement>  
34:       <dependencies>  
35:            <dependency>  
36:                 <groupId>javax.enterprise</groupId>  
37:                 <artifactId>cdi-api</artifactId>  
38:                 <scope>provided</scope>  
39:            </dependency>  
40:            <dependency>  
41:                 <groupId>org.jboss.spec.javax.servlet</groupId>  
42:                 <artifactId>jboss-servlet-api_3.0_spec</artifactId>  
43:                 <scope>provided</scope>  
44:            </dependency>  
45:            <dependency>  
46:                 <groupId>org.jboss.spec.javax.faces</groupId>  
47:                 <artifactId>jboss-jsf-api_2.1_spec</artifactId>  
48:                 <scope>provided</scope>  
49:            </dependency>  
50:            <dependency>  
51:                 <groupId>org.jboss.spec.javax.el</groupId>  
52:                 <artifactId>jboss-el-api_2.2_spec</artifactId>  
53:                 <scope>provided</scope>  
54:            </dependency>  
55:            <dependency>  
56:                 <groupId>com.sun.faces</groupId>  
57:                 <artifactId>jsf-impl</artifactId>  
58:                 <version>${version.faces.mojarra}</version>  
59:                 <scope>provided</scope>  
60:            </dependency>  
61:            <dependency>  
62:                 <groupId>org.primefaces</groupId>  
63:                 <artifactId>primefaces</artifactId>  
64:                 <version>${version.primefaces}</version>  
65:            </dependency>  
66:            <dependency>  
67:                 <groupId>org.atmosphere</groupId>  
68:                 <artifactId>atmosphere-runtime</artifactId>  
69:                 <version>${version.atmosphere}</version>  
70:                 <exclusions>  
71:                      <exclusion>  
72:                           <artifactId>slf4j-api</artifactId>  
73:                           <groupId>org.slf4j</groupId>  
74:                      </exclusion>  
75:                 </exclusions>  
76:            </dependency>  
77:            <dependency>  
78:                 <groupId>junit</groupId>  
79:                 <artifactId>junit</artifactId>  
80:                 <scope>test</scope>  
81:            </dependency>  
82:       </dependencies>  
83:       <build>  
84:            <finalName>pushcomment</finalName>  
85:            <plugins>  
86:                 <plugin>  
87:                      <artifactId>maven-compiler-plugin</artifactId>  
88:                      <version>2.3.1</version>  
89:                      <configuration>  
90:                           <source>1.6</source>  
91:                           <target>1.6</target>  
92:                      </configuration>  
93:                 </plugin>  
94:                 <plugin>  
95:                      <artifactId>maven-war-plugin</artifactId>  
96:                      <version>2.1.1</version>  
97:                      <configuration>  
98:                           <failOnMissingWebXml>false</failOnMissingWebXml>  
99:                      </configuration>  
100:                 </plugin>  
101:            </plugins>  
102:       </build>  
103:       <repositories>  
104:            <repository>  
105:                 <id>prime-repo</id>  
106:                 <name>PrimeFaces Maven Repository</name>  
107:                 <url>http://repository.primefaces.org</url>  
108:                 <layout>default</layout>  
109:            </repository>  
110:       </repositories>  
111:  </project>  

faces-config.xml


1:  <?xml version="1.0" encoding="UTF-8"?>  
2:  <!-- This file is not required if you don't need any extra configuration. -->  
3:  <faces-config version="2.0" xmlns="http://java.sun.com/xml/ns/javaee"  
4:    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
5:    xsi:schemaLocation="  
6:      http://java.sun.com/xml/ns/javaee  
7:      http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd">  
8:  </faces-config>  

web.xml

1:  <?xml version="1.0" encoding="UTF-8"?>  
2:  <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
3:       xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"  
4:       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"  
5:       version="3.0">  
6:       <display-name>push-comment</display-name>  
7:       <welcome-file-list>  
8:            <welcome-file>index.html</welcome-file>  
9:       </welcome-file-list>  
10:       <context-param>  
11:            <param-name>javax.faces.PROJECT_STAGE</param-name>  
12:            <param-value>Development</param-value>  
13:       </context-param>  
14:       <context-param>  
15:            <param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>  
16:            <param-value>2</param-value>  
17:       </context-param>  
18:       <context-param>  
19:            <param-name>javax.faces.DEFAULT_SUFFIX</param-name>  
20:            <param-value>.xhtml</param-value>  
21:       </context-param>  
22:       <context-param>  
23:            <param-name>javax.faces.FACELETS_SKIP_COMMENTS</param-name>  
24:            <param-value>true</param-value>  
25:       </context-param>  
26:       <context-param>  
27:            <param-name>javax.faces.STATE_SAVING_METHOD</param-name>  
28:            <param-value>server</param-value>  
29:       </context-param>  
30:       <context-param>  
31:            <param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>  
32:            <param-value>true</param-value>  
33:       </context-param>  
34:       <context-param>  
35:            <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>  
36:            <param-value>true</param-value>  
37:       </context-param>  
38:       <context-param>  
39:            <param-name>com.sun.faces.numberOfLogicalViews</param-name>  
40:            <param-value>5</param-value>  
41:       </context-param>  
42:       <context-param>  
43:            <param-name>com.sun.faces.numberOfViewsInSession</param-name>  
44:            <param-value>3</param-value>  
45:       </context-param>  
46:       <context-param>  
47:            <param-name>com.sun.faces.compressViewState</param-name>  
48:            <param-value>true</param-value>  
49:       </context-param>  
50:       <context-param>  
51:            <param-name>com.sun.faces.serializeServerState</param-name>  
52:            <param-value>false</param-value>  
53:       </context-param>  
54:       <context-param>  
55:            <param-name>com.sun.faces.preferXHTML</param-name>  
56:            <param-value>true</param-value>  
57:       </context-param>  
58:       <context-param>  
59:            <param-name>com.sun.faces.disableVersionTracking</param-name>  
60:            <param-value>true</param-value>  
61:       </context-param>  
62:       <context-param>  
63:            <param-name>primefaces.THEME</param-name>  
64:            <param-value>aristo</param-value>  
65:       </context-param>  
66:       <security-constraint>  
67:            <display-name>Restrict direct access to XHTML documents.</display-name>  
68:            <web-resource-collection>  
69:                 <web-resource-name>XHTML</web-resource-name>  
70:                 <url-pattern>*.xhtml</url-pattern>  
71:            </web-resource-collection>  
72:            <auth-constraint>  
73:                 <description>No roles defined for direct access to XHTML documents.</description>  
74:            </auth-constraint>  
75:       </security-constraint>  
76:       <session-config>  
77:            <session-timeout>20</session-timeout>  
78:       </session-config>  
79:       <error-page>  
80:            <exception-type>javax.faces.application.ViewExpiredException</exception-type>  
81:            <location>/index.jsf</location>  
82:       </error-page>  
83:       <servlet>  
84:            <servlet-name>Faces Servlet</servlet-name>  
85:            <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>  
86:            <load-on-startup>1</load-on-startup>  
87:            <async-supported>true</async-supported>  
88:       </servlet>  
89:       <servlet-mapping>  
90:            <servlet-name>Faces Servlet</servlet-name>  
91:            <url-pattern>/faces/*</url-pattern>  
92:       </servlet-mapping>  
93:       <servlet-mapping>  
94:            <servlet-name>Faces Servlet</servlet-name>  
95:            <url-pattern>*.jsf</url-pattern>  
96:       </servlet-mapping>  
97:       <servlet>  
98:            <servlet-name>Push Servlet</servlet-name>  
99:            <servlet-class>org.primefaces.push.PushServlet</servlet-class>  
100:            <init-param>  
101:                 <param-name>org.atmosphere.useWebSocket</param-name>  
102:                 <param-value>false</param-value>  
103:            </init-param>  
104:            <init-param>  
105:                 <param-name>org.atmosphere.cpr.sessionSupport</param-name>  
106:                 <param-value>true</param-value>  
107:            </init-param>  
108:            <init-param>  
109:                 <param-name>org.atmosphere.useNative</param-name>  
110:                 <param-value>true</param-value>  
111:            </init-param>  
112:            <init-param>  
113:                 <param-name>org.atmosphere.cpr.broadcasterCacheClass</param-name>  
114:                 <param-value>org.atmosphere.cache.HeaderBroadcasterCache</param-value>  
115:            </init-param>  
116:            <init-param>  
117:                 <param-name>org.atmosphere.cpr.broadcastFilterClasses</param-name>  
118:                 <param-value>org.atmosphere.client.TrackMessageSizeFilter</param-value>  
119:            </init-param>  
120:            <init-param>  
121:                 <param-name>org.atmosphere.resumeOnBroadcast</param-name>  
122:                 <param-value>true</param-value>  
123:            </init-param>  
124:            <load-on-startup>1</load-on-startup>  
125:            <async-supported>true</async-supported>  
126:       </servlet>  
127:       <servlet-mapping>  
128:            <servlet-name>Push Servlet</servlet-name>  
129:            <url-pattern>/primepush/*</url-pattern>  
130:       </servlet-mapping>  
131:  </web-app>  

Now that everything should be configured, lets write a very simple JSF 2 program to show a primepush.

index.xhtml


1:  <!DOCTYPE html>  
2:  <html xmlns="http://www.w3.org/1999/xhtml"  
3:       xmlns:h="http://java.sun.com/jsf/html"  
4:       xmlns:f="http://java.sun.com/jsf/core"  
5:       xmlns:c="http://java.sun.com/jsp/jstl/core"  
6:       xmlns:ui="http://java.sun.com/jsf/facelets"  
7:       xmlns:p="http://primefaces.org/ui">  
8:  <f:view contentType="text/html" encoding="UTF-8">  
9:       <h:head>  
10:            <meta charset="utf-8" />  
11:       </h:head>  
12:       <h:body>  
13:            <h:form prependId="false">  
14:                 <p:inputTextarea id="cmt" value="#{myCommentBean.comment}"></p:inputTextarea>  
15:                 <p:commandButton actionListener="#{myCommentBean.publish}"  
16:                      process="cmt @this" update="cmt" value="publish"></p:commandButton>  
17:            </h:form>  
18:            <span id="pushComment" />  
19:            <p:socket channel="/comment" onMessage="handleMessage"></p:socket>  
20:            <script type="text/javascript">  
21:       function handleMessage(data)  
22:        {   
23:        jQuery('#pushComment').text(data);  
24:               }  
25:      </script>  
26:       </h:body>  
27:  </f:view>  
28:  </html>  

MyCommentBean.java



1:  /**  
2:   * The JSF Backing bean that will push the messages into the socket.  
3:   */  
4:  package my.first.push.project;  
5:  import javax.faces.bean.ManagedBean;  
6:  import javax.faces.bean.RequestScoped;  
7:  import org.primefaces.push.PushContextFactory;  
8:  @ManagedBean(name = "myCommentBean")  
9:  @RequestScoped  
10:  public class MyCommentBean {  
11:    public static final String BROADCAST_CHANNEL = "/comment";  
12:    private String comment;  
13:    public String getComment() {return comment;}  
14:    public void setComment(String comment) {this.comment = comment;}  
15:    public void publish() {  
16:     PushContextFactory.getDefault().getPushContext().push(BROADCAST_CHANNEL, this.comment);  
17:     this.comment = "";  
18:    }  
19:  }  

So now that we have the application, compile and deploy it in JBoss.
Run it on your browser by just accessing the URL:
http://localhost:8080/pushcomment/

Open a few browsers and see how all the clients listening to the socket will get the updates:



Download this project from:

http://www.2shared.com/file/Vy8ZSkUQ/pushcomment.html

Share with your friends