Automated Work in progress (wip) limit is good for agile development

Having limit on number of issues(story,feature ) a developer can work at a time is very effective for agile development . It forces developer not to exceed  limit.Suppose we have issue states like – Backlog,Ready,Progress,Code review,Deployment – then a particular developer can have just 2(whatever is the limit ) stories(issues) against her name in state “Progress”.If she is stuck with issue and she wants to take a new issue in between then she has to drag back at-least one issue to ‘Ready’ state. This is good as other developers can find this issue interesting and can work on that .

Lets take a case of Jira  a great extensible tool for issue tracking and agile development through Green hopper.We have kanban board setup there and we had setup a WIP limit through our in house developed plugin – while transition to ‘Progress’ state , plugin validates that developer is not crossing that “WORK IN PROGRESS” limit.

Wip limit gives very clear picture that who is working on what.

If interested to use that plugin let me know.

Posted in Uncategorized | Leave a comment

How to learn spring quickly !!

1.Use an interesting  reference book like   Spring Recipes by Apress publication.Book presentation is based on  Problem and Solution approach.(Author asks a question and then writes his solution).This approach makes book interesting.

2.Use Spring ROO tool (http://www.springsource.org/roo) -to quickly create a prototype spring application and then tweak with it  .Like it you are reading Spring MVC today .Create a MVC prototype app with ROO and then play with it- experiment with your learnings .For example – You can apply different UrlMaping than default ,error handling ,validation.

3.If you have faith in Certification you can appear for Spring CORE certification exam .They also provide 4 day training on Spring.

Posted in Uncategorized | 1 Comment

Strategy pattern with a game of Cards

I have to design a game of Cards .This game has multiple flavours (like real card games where each game of cards has their own rule ) .Here I have two flavours with these rules -

Rule for flavour A-

In a game of Two player each chooses one card .Player holding higher card is winner.

Rule for flavour B-

In a game of Two player each chooses one card.Player holding lower card is winner.

So I have solved this problem using strategy Pattern .I wrote strategies for each rule and passed it to game.


public interface Comparable<T> {

 public int compare(T obj);

}

public interface WinableUnit extends Comparable<WinableUnit>{

}
//strategy interface
public interface WinningStrategy {

 public WinableUnit getWinner(WinableUnit first,WinableUnit second);

}
//Stategy implementation for Higher score winning rule
public class HighestScoreWinningStrategy implements WinningStrategy{

 public WinableUnit getWinner(WinableUnit first, WinableUnit second) {
 if(first.compare(second)==0){
 throw new RuntimeException("Both Unit have equal score");
 }

 return first.compare(second) >0 ?first : second;

 }

}

//stategy implementation for lower score winning rule
public class LowScoreWinningStrategy implements WinningStrategy{

 public WinableUnit getWinner(WinableUnit first, WinableUnit second) {
 if(first.compare(second)==0){
 throw new RuntimeException("Both players have equal score");
 }
 return first.compare(second)<0 ?first:second;
 }

}

public class Card implements Comparable<Card>{
 Integer number;

 public Card(Integer number) {
 this.number = number;
 }

 public int compare(Card anotherCard) {
 return this.number.compareTo(anotherCard.number);
 }

}
package com.ratn.game;

public class Player implements WinableUnit{

 private Card card;

 public Player(Card card) {
 this.card = card;
 }

 public int compare(WinableUnit anotherUnit) {

 return card.compare(((Player)anotherUnit).card);
 }

}

public class Game {

 private WinningStrategy strategy;
 private Player player1;
 private Player player2;

 public Game(WinningStrategy strategy) {
 this.strategy = strategy;

 player1 = new Player(new Card(getRandomNumber()));
 player2 = new Player(new Card(getRandomNumber()));

 }

 public Player winner(){
 return (Player) strategy.getWinner(player1, player2);
 }

 private int getRandomNumber(){
//returns a random number between range
 return 0;
 }

}

Posted in Design | Leave a comment

Design : putting domain constraint at right place

A common question arises where to put Domain constraints ? Of course in domain object but where ? Most suitable place is constructor .Suppose I have a square grid – a position in grid is represented by x,y  - lower left of this grid is at 0,0 and upper right is at 7,7 .Now In my application I can move a point with in the grid but point should never be outside of grid .If we carefully examine this –It is a domain constraint which says that Coordinate should never be out of grid .One Not good approach would be like this -

public class Position() {
    private int x;
    private int y;
    //assume Grid is autowired by DI
    private Grid grid;
    public Position(int x,int y){
        this.x=x;
        this.y=y;
   }
   public Position add(int x,int y){
       //imposing constraint here
       if (grid.isPostionInsideGrid(this.x+x,this.y+y)){
           return new Position(this.x+x,this.y+y);
       }else {
           throw new RuntimeException("Position " +"(" +this.x+x+","+this.y+y+")" +"is outside grid");
       }
   }
}

If you carefully examine above code ,you would see a big gotcha [Domain constraint violation ] ,It allows you to create an initial position which itself is out of Grid  - like new Position(100,101) .This is outside of grid which is bounded  by lower left 0,0 and upper right  7,7.Lets see a better way -

public class Position()
    private int x;
    private int y;
    //assume Grid is autowired by DI
    private Grid grid;
    public Position(int x,int y){
        this.x=x;
        this.y=y;
        //now this condition would always maintian class invariant that a point is always inside grid
        if (!grid.isPostionInsideGrid(this.x,this.y)){
             throw new RuntimeException("Position " +"(" +this.x+","+this.y+")" +"is outside grid");
        }
    }
    public Position add(int x,int y){
         return new Position(this.x+x,this.y+y);
    }
}

In new code- Domain constraint (Class invariant ) is hold always.You can never have a position which is outside grid.

Posted in Design | Leave a comment

Why use IoC

Lets see one example where code (caller has complete control over callee) has complete control against the philosophy of  IoC -

public class AgainstIoc {

    public List<String> getAllNonIoCProgrammers() {

    ProgrammingDaoImpl programmingDaoImpl = new ProgrammingDaoImpl();

    programmingDaoImpl.getAllNonIoCProgrammers();
}}

public interface ProgrammingDao {

    public List<String> getAllNonIoCProgrammers();

}

public class ProgrammingDaoImpl implements ProgrammingDao {

   public List<String> getAllNonIoCProgrammers(){

   //gets a list from of NoNIoCProgrammers fromDb

   }

}

Here above code has complete control on the flow of code.It knows it is calling getAllNonIoCProgrammers() method from Concrete class ProgrammingDaoImp .Later if I want to add a new Implementation of ProgrammingDao ,every  where I have to go and change for instantiation of new class .This would be too much in a big Project where I have to go change at many lines.

Lets now use IoC -using construction Injection  –

 public class IocWay {

   private ProgrammingDao programmingDao;
       //Inversion of control by constructor injection
       public IocWay(ProgrammingDao programmingDao){

                            this.programmingDao = programmingDao;

       }

   public List<String>  getAllNonIoCProgrammers() {
      //here caller does know about callee,it has no control over callee
      programmingDao.getAllNonIoCProgrammers();
   }
}

In this way code does not  have the control to whom it is calling .Caller does not have  a control over calllee.Caller just know thats eventually it would get a response  from callee.So now we can have different implementation of  ProgrammingDao ,one for development ,another for testing or different one for production ,caller does not have to worry about it because it does not know anything about callee, it does not have a control over callee.

Posted in Design | Tagged | 4 Comments

GWT : use Callback for interaction between UI components

Using GWT you create lot of UI components .And often these components have to interact with each other .Generally we should use some kind of message bus for interaction between the components those are not coupled to each other .But for the components where we have Parent – Child relationship ,In that case Child(callee) should interact with Parent(caller) using CallBack that Parent passed to it .

Suppose in online pizza shop you  order for pizza ,first  you enter your phone number ,application tries to find out your address by your phone number .If your address is not found ,it pop ups a window for you to enter address.Once address is entered application proceeds .Lets see how address pop interacts with its caller.


//callback interface

public interface AddressSubmitHandler {

       public void onAddressSubmit(Address address);

}

public class PizzaOrderPanel extends Composite{

      private Address address;

      private PizzaOrderService pizzaOrderService;

      public PizzaOrderPanel(){

          //if address is not found ,pop up a window and ask user to enter address

          new AddressPopup(new AddressSubmitHandler(){

                  public void onAddressSubmit(Address address){

                          pizzaOrderService.sendPizza(address);

                 }

         });

   }

}

public class AddressPopup extends PopupPanel {

      public AddressPopup(final AddressSubmitHandler addressSubmitHandler){

             //user have submitted address now call callback method

             addressSubmitHandler.onAddressSubmit(address);

      }

}

Posted in GWT | 1 Comment

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

Posted in Uncategorized | Leave a comment