Setting up sharded mongodb cluster in localhost

I have been playing around with MongoDb, thanks to the M101J Course offered by Mongodb University. These NoSQL datastores are gaining popularity due to a number of reasons and one among them being the ease with which they can be scaled out i.e horizontal scaling. This horizontal scaling in MongoDB can be achieved by creating a sharded cluster of mongodb instances.

You might want to understand the concept of sharding before continuing. The MongoDB reference has a very clear explanation for the same here.
Continue reading “Setting up sharded mongodb cluster in localhost”

Getting rid of Getters and Setters in your POJO

We all have read in Java books about encapsulation of fields in Java class and also when ever you code you are asked to take special care in encapsulating the fields and providing explicit Getters and Setters. And these are very strict instructions. Lets step back a bit and find out the reason behind encapsulating the fields. Its all done to have a control over the access and modification of the fields. One might want to allow the user of the class to access data from only few fields or control the update of data of the fields in the class and so on. And on other occassions the frameworks would need these getters and setters to populate your POJOs(Plain Old Java Objects).

Now the pain involved in adding these getters and setters is quite a bit and this pain has been reduced by the IDEs which allow you to generate the getters and setters for the fields. But these generated code make your class definition very verbose and hide the actual business logic, if any, which you might have it inside the class definition. There have been lot of ways by which you can get away with defining the getters and setters explicitly and I have even blogged about using Project Lombok to use annotations to declare the getters and setters. I have come across another approach to avoid defining the getters and setters and this approach doesn’t even auto generate the code or use annotations to define them. I am sure I have read this approach somewhere but unable to recall, so its something which has been used and I am trying to create an awareness among my readers about this approach via this blog post.

Let me first define the class with the getters and setters and then show how to get rid of them

class TaskWithGettersSetters {
  public TaskWithGettersSetters(String title, String notes,
      LocalDateTime deadline, String assignedTo) {
    this.title = title;
    this.notes = notes;
    this.addedOn = LocalDateTime.now();
    this.deadline = deadline;
    this.assignedTo = assignedTo;
  }

  public TaskWithGettersSetters() {
  }

  private String        title;
  private String        notes;
  private LocalDateTime addedOn;
  private LocalDateTime deadline;
  private String        assignedTo;

  public String getTitle() {
    return title;
  }

  public void setTitle(String title) {
    this.title = title;
  }

  public String getNotes() {
    return notes;
  }

  public void setNotes(String notes) {
    this.notes = notes;
  }

  public LocalDateTime getAddedOn() {
    return addedOn;
  }

  public void setAddedOn(LocalDateTime addedOn) {
    this.addedOn = addedOn;
  }

  public LocalDateTime getDeadline() {
    return deadline;
  }

  public void setDeadline(LocalDateTime deadline) {
    this.deadline = deadline;
  }

  public String getAssignedTo() {
    return assignedTo;
  }

  public void setAssignedTo(String assignedTo) {
    this.assignedTo = assignedTo;
  }

}

There is nothing to explain in the above code, pretty clear with fields being private and public getters and setters. The class definition is about 60 lines. Let see how we can define class without providing getters and setters:

class Task {

  public Task(String title, String notes, LocalDateTime deadline,
      String assignedTo) {
    this.title = title;
    this.notes = notes;
    this.addedOn = LocalDateTime.now();
    this.deadline = deadline;
    this.assignedTo = assignedTo;
  }

  public final String        title;
  public final String        notes;
  public final LocalDateTime addedOn;
  public final LocalDateTime deadline;
  public final String        assignedTo;

}

The above is what I call class definition on diet 🙂 It is less verbose and is just 18 lines. You must be scared looking at the public modifiers for the fields and also confused looking at the final modifiers to the field. Let me explain the ideology behind this approach:

  1. As the fields are final they cannot be modified after initialized so we need not worry about the scare of data in the field getting modified. And we have to provide a constructor which will initialize these fields, otherwise compiler will shout at you for not understanding what final modifier is.
  2. The data in the fields can be accessed by using the fields directly and not via the getter methods.
  3. This approach enforces immutability of objects i.e if we have to update the field we have to create a new object with the updated value of the field.

Now having Immutable objects provides lots of advantages few of them being:

  • Writing concurrent code is quite easy because we need not worry about getting locks on the object as we are never going to modify the object, we can just read the object data and cannot modify due to the use of final.
  • Immutable objects leads to having lot of short lived objects which helps in reducing the GC overhead involved in managing long lived objects and objects with lot of live references.

We can even provide a factory method for creating instances of Task. Lets see the above class in action:

import java.time.LocalDateTime;

public class GettingRidOfGettersSettersDemo {
  public static void main(String[] args) {
    //One can make use of Factory method to initialize the data
    Task task1 = new Task("Task 1", "some notes", LocalDateTime.now().plusDays(5), "sana");
    //Very clean approach to access the field data - no getYYY() noise 
    System.out.println(task1.title + " assigned to " + task1.assignedTo);
    Task task2  = new Task("Task 2", "some notes", LocalDateTime.now().plusDays(6), "raj");
    System.out.println(task2.title + " assigned to " + task2.assignedTo);
  }
}

Update:
Thanks a lot for the comments and your thoughts both here and on DZone. I spent some time in identifying how one can work without the need for getters and setters in scenarios mentioned where without getters and setters its not possible. One such scenario is marsalling and unmarshalling of JSON and another scenario is where we have a List of some values as property and we need to give an read only access to the users of the object. The below are examples of using POJOs without getters and setters in JSON marshalling and unmarshalling using GSON and Jackson JSON libraries:

The below is the code for using GSON JSON Library:

public class GsonParserDemo {

  public static void main(String[] args) {
    HashMap<String, Object> jsonData = new HashMap<String, Object>();
    jsonData.put("name", "sanaulla");
    jsonData.put("place", "bangalore");
    jsonData.put("interests", Arrays.asList("blogging", "coding"));
    Gson gson = new Gson();

    String jsonString = gson.toJson(jsonData);
    System.out.println("From Map: " + jsonString);
    

    Person person = gson.fromJson(jsonString, Person.class);
    
    System.out.println("From Person.class: " + gson.toJson(person));
  }

  class Person {
    public final String name;
    public final String place;
    private final List<String> interests;

    public Person(String name, String place, List<String> interests) {
      this.name = name;
      this.place = place;
      this.interests = interests;
    }
 
    public List<String> interests(){
      return Collections.unmodifiableList(interests);
    }
  }
}

The output of above code is:

From Map: {"name":"sanaulla","place":"bangalore","interests":["blogging","coding"]}
From Person.class: {"name":"sanaulla","place":"bangalore","interests":["blogging","coding"]}

To note : GSON doesn’t use constructor nor getters and setters to map JSON to Java class.

The below is the code for using Jackson JSON Library:

public class JacksonParserDemo {
  public static void main(String[] args) throws JsonGenerationException,
      JsonMappingException, IOException {
    HashMap<String, String> jsonData = new HashMap<String, String>();
    jsonData.put("name", "sanaulla");
    jsonData.put("place", "bangalore");

    ObjectMapper objectMapper = new ObjectMapper();

    String jsonString = objectMapper.writeValueAsString(jsonData);
    System.out.println("Json from map : " + jsonString);

    Person person = objectMapper.readValue(jsonString, Person.class);
    System.out.println("Json from Person : "
        + objectMapper.writeValueAsString(person));
  }

}
class Person {
  
  public final String name;
  
  public final String place;

  @JsonCreator
  public Person(@JsonProperty("name") String name,
      @JsonProperty("place") String place) {
    this.name = name;
    this.place = place;
  }

}

The output of the above code is:

Json from map : {"name":"sanaulla","place":"bangalore"}
Json from Person : {"name":"sanaulla","place":"bangalore"}

I am investigating some concerns raised about Object Relational Mappers and the Joda Time.

Strategy Pattern using Lambda Expressions in Java 8

Strategy Pattern is one of the patterns from the Design Patterns : Elements of Reusable Object book. The intent of the strategy pattern as stated in the book is:

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

In this post I would like to give an example or two on strategy pattern and then rewrite the same example using lambda expressions to be introduced in Java 8.

Strategy Pattern: An example

Consider an interface declaring the strategy:

interface Strategy{
  public void performTask();
}

Consider two implementations of this strategy:

class LazyStratgey implements Strategy{

  @Override
  public void performTask() {
    System.out.println("Perform task a day before deadline!");
  }
  
}

class ActiveStratgey implements Strategy{

  @Override
  public void performTask() {
    System.out.println("Perform task now!");
  }
  
}

The above strategies are naive and I have kept it simple to help readers grasp it quickly. And lets see these strategies in action:

public class StartegyPatternOldWay {

  public static void main(String[] args) {

    List<Strategy> strategies = 
        Arrays.asList(
          new LazyStratgey(), 
          new ActiveStratgey()
        );
                      
    for(Strategy stg : strategies){
      stg.performTask();
    }
  }
}

The output for the above is:

Perform task a day before deadline!
Perform task now!

Strategy Pattern: An example with Lambda expressions

Lets look at the same example using Lambda expressions. For this we will retain our Strategy interface, but we need not create different implementation of the interface, instead we make use of lambda expressions to create different implementations of the strategy. The below code shows it in action:

import java.util.Arrays;
import java.util.List;

public class StrategyPatternOnSteroids {
  public static void main(String[] args) {
      
    System.out.println("Strategy pattern on Steroids");
    
    List<Strategy> strategies = 
      Arrays.asList(
        () -> {System.out.println("Perform task a day before deadline!");},
        () -> {System.out.println("Perform task now!");}
      );
    
    strategies.forEach((elem) -> elem.performTask());
  }
  
}

The output for the above is:

Strategy pattern on Steroids
Perform task a day before deadline!
Perform task now!

In the example using lambda expression, we avoided the use of class declaration for different strategies implementation and instead made use of the lambda expressions.

Strategy Pattern: Another Example

This example is inspired from Neal Ford’s article on IBM Developer works: Functional Design Pattern-1. The idea of the example is exactly similar, but Neal Ford uses Scala and I am using Java for the same with a few changes in the naming conventions.

Lets look at an interface Computation which also declares a generic type T apart from a method compute which takes in two parameters.

interface Computation<T> {

  public T compute(T n, T m);
}

We can have different implementations of the computation like: IntSum – which returns the sum of two integers, IntDifference – which returns the difference of two integers and IntProduct – which returns the product of two integers.

class IntSum implements Computation<Integer> {

  @Override
  public Integer compute(Integer n, Integer m) {
    return n + m;
  }

}

class IntProduct implements Computation<Integer> {

  @Override
  public Integer compute(Integer n, Integer m) {
    return n * m;
  }
}

class IntDifference implements Computation<Integer> {

  @Override
  public Integer compute(Integer n, Integer m) {
    return n - m;
  }
}

Now lets look at these strategies in action in the below code:

public class AnotherStrategyPattern {

  public static void main(String[] args) {
  
    List<Computation> computations = 
        Arrays.asList(
          new IntSum(), 
          new IntDifference(), 
          new IntProduct()
        );
    
    for (Computation comp : computations) {
      System.out.println(comp.compute(10, 4));
    }
  }
}

The output for the above is:

14
6
40

Strategy Pattern: Another Example with lambda expressions

Now lets look at the same example using Lambda expressions. As in the previous example as well we need not declare classes for different implementation of the strategy i.e the Computation interface, instead we make use of lambda expressions to achieve the same. Lets look at an example:

public class AnotherStrategyPatternWithLambdas {
  public static void main(String[] args) {

    List<Computation<Integer>> computations = 
          Arrays.asList(
              (n, m)-> { return n+m; },
              (n, m)-> { return n*m; },
              (n, m)-> { return n-m; }
          );
    computations.forEach((comp) -> System.out.println(comp.compute(10, 4)));
  }
}

The output for above is:

14
6
40

From the above examples we can see that using Lambda expressions will help in reducing lot of boilerplate code to achieve more concise code. And with practice one can get used to reading lambda expressions.

Simple example to illustrate Chain Of Responsibility Design Pattern

GoF Design pattern book states the intent of Chain of Responsibility pattern as:

Avoid coupling the sender of a request to the receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

The main intention in Chain Of Responsibility is to decouple the origin of the request and the handling of the request such that the origin of the request need not worry who and how its request is being handled as long as it gets the expected outcome. By decoupling the origin of the request and the request handler we make sure that both can change easily and new request handlers can be added without the origin of the request i.e client being aware of the changes. In this pattern we create a chain of objects such that each object will have a reference to another object which we call it as successor and these objects are responsible for handling the request from the client. All the objects which are part of the chain are created from classes which confirm to a common interface there by the client only needs to be aware of the interface and not necessarily the types of its implementations. The client assigns the request to first object part of the chain and the chain is created in such a way that there would be atleast one object which can handle the request or the client would be made aware of the fact that its request couldn’t be handled.

With this brief introduction I would like to put forth a very simple example to illustrate this pattern. In this example we create a chain of file parsers such that depending on the format of the file being passed to the parser, the parser has to decide whether its going to parse the file or pass the request to its successor parser to take action. The parser we would chain are: Simple text file parser, JSON file parser, CSV file parser and XML file parser. The parsing logic in each of these parser doesn’t parse any file, instead it just prints out a message stating who is handing the request for which file. We then populate file names of different formats into a list and then iterate through them passing the file name to the first parser in the list.

Lets define the Parser class, first let me show the class diagram for Parser class:

The Java code for the same is:
[java]
public class Parser {

private Parser successor;

public void parse(String fileName){
if ( getSuccessor() != null ){
getSuccessor().parse(fileName);
}
else{
System.out.println("Unable to find the correct parser for the file: "+fileName);
}
}

protected boolean canHandleFile(String fileName, String format){
return (fileName == null) || (fileName.endsWith(format));

}

Parser getSuccessor() {
return successor;
}

void setSuccessor(Parser successor) {
this.successor = successor;
}
}
[/java]

We would now create different handlers for parsing different file formats namely- Simple text file, JSON file, CSV file, XML file and these extend from the Parser class and override the parse method. I have kept the implementation of different parser simple and these methods evaluate if the file has the format they are looking for. If a particular handler is unable to process the request i.e. the file format is not what it is looking for then the parent method handles such requests. The handler method in the parent class just invokes the same method on the successor handler.

The simple text parser:
[java]
public class TextParser extends Parser{

public TextParser(Parser successor){
this.setSuccessor(successor);
}

@Override
public void parse(String fileName) {
if ( canHandleFile(fileName, ".txt")){
System.out.println("A text parser is handling the file: "+fileName);
}
else{
super.parse(fileName);
}

}

}
[/java]

The JSON parser:
[java]
public class JsonParser extends Parser {

public JsonParser(Parser successor){
this.setSuccessor(successor);
}

@Override
public void parse(String fileName) {
if ( canHandleFile(fileName, ".json")){
System.out.println("A JSON parser is handling the file: "+fileName);
}
else{
super.parse(fileName);
}

}

}
[/java]

The CSV parser:
[java]
public class CsvParser extends Parser {

public CsvParser(Parser successor){
this.setSuccessor(successor);
}

@Override
public void parse(String fileName) {
if ( canHandleFile(fileName, ".csv")){
System.out.println("A CSV parser is handling the file: "+fileName);
}
else{
super.parse(fileName);
}
}

}
[/java]

The XML parser:
[java]
public class XmlParser extends Parser {

@Override
public void parse(String fileName) {
if ( canHandleFile(fileName, ".xml")){
System.out.println("A XML parser is handling the file: "+fileName);
}
else{
super.parse(fileName);
}
}

}
[/java]

Now that we have all the handlers setup, we need to create a chain of handlers. In this example the chain we create is: TextParser -> JsonParser -> CsvParser -> XmlParser. And if XmlParser is unable to handle the request then the Parser class throws out a message stating that the request was not handled. Lets see the code for the client class which creates a list of files names and then creates the chain which I just described.

[java]
import java.util.List;
import java.util.ArrayList;

public class ChainOfResponsibilityDemo {

/**
* @param args
*/
public static void main(String[] args) {

//List of file names to parse.
List<String> fileList = populateFiles();

//No successor for this handler because this is the last in chain.
Parser xmlParser = new XmlParser();

//XmlParser is the successor of CsvParser.
Parser csvParser = new CsvParser(xmlParser);

//CsvParser is the successor of JsonParser.
Parser jsonParser = new JsonParser(csvParser);

//JsonParser is the successor of TextParser.
//TextParser is the start of the chain.
Parser textParser = new TextParser(jsonParser);

//Pass the file name to the first handler in the chain.
for ( String fileName : fileList){
textParser.parse(fileName);
}

}

private static List<String> populateFiles(){

List<String> fileList = new ArrayList<>();
fileList.add("someFile.txt");
fileList.add("otherFile.json");
fileList.add("xmlFile.xml");
fileList.add("csvFile.csv");
fileList.add("csvFile.doc");

return fileList;
}

}
[/java]

In the file name list above I have intentionally added a file name for which there is no handler created. Running the above code gives us the output:
[shell]
A text parser is handling the file: someFile.txt
A JSON parser is handling the file: otherFile.json
A XML parser is handling the file: xmlFile.xml
A CSV parser is handling the file: csvFile.csv
Unable to find the correct parser for the file: csvFile.doc
[/shell]

My First steps in Test Driven Development- A Win-Win strategy

Agile practitioners talk about Test Driven Development(TDD), so do lot of developers who care about their code quality and workability. And I once upon a time, not so long ago managed to read about TDD. The crux of TDD as I have understood is:

  1. Write Test, and fail
  2. Code, make the tests succeed
  3. Automate the tests
  4. Refactor the code to improve the quality
  5. Repeat

Pretty easy to understand. A annoyed developer shouts- “A developer writing tests? How can you expect us to develop and test and yet finish the feature in time?”. After all developers dont want to do the boring testing work. I have been a developer for around 2 years know and there were times when I reacted that way, during those initial days. But with time, I have started to understand the crux of software development. And this time around I thought of trying out TDD.

My work involves wiring up the data in the db with the UI using an Java EE web framework- A typical web application work.

Let me explain my testing strategy before I adopted TDD:

  1. Write the complete code which includes- PLSQL procedures, Java code to invoke PLSQL procedures, Java code for the UI bindings and the JSP page itself.
  2. Manually test the functioning of the db layer and the UI layer code. It involves navigating to the page and then testing various operations. In this case both the UI issues and the Backend code issues would crop up.
  3. As I would play around with the UI further, I would unearth few bugs in the code, otherwise write a selenium test to automate testing of a few use-cases.

With the above 3 steps, I spent a lot of time-

  1. waiting for the backend code to compile and the restart the server for the UI to reflect the changes. Even if its a simple 1 word/1 statement change I had to wait for approximately upto 5 minutes and in some cases 8 minutes. While I would wait for this to restart, I would have lost focus to some other task and there by take sometime to come back to the main task.
  2. trying to debug and find out if the exception/bug is due to the UI code issue or the backend code issue.
  3. in waiting for the pages to load and navigate through the pages to the right page.

Ok, those were the pre-historic times. Now coming to the Modern Age. I thought TDD would not have been possible in the kind of work I do, it was because I wrote a badly coupled backend and UI code. I couldn’t think of ways to test my back end code independently and then move to the UI code and then test it via selenium tests. Keeping aside these notions, I gave it a shot. I know I wasn’t very close to the actual TDD, but I felt somewhat closer.

  1. I had a fair idea of how to implement the logic, created a basic implementation and let it compile successfully.
  2. Created a few data population tests to get the kind of data to be used for the testing.
  3. Created JUnits to tests the basic functionality. Mostly in terms of the correct execution of PLSQL procedure via the Java API.
  4. Updated the JUnits to add more tests to test out the actual functionality required and updated the code to implement those functionalities.
  5. Refactor the code to remove bad smells and then run JUnits to see to it that nothing is broken.

The reasons why I felt excited, why I felt it was a Win-Win strategy:

  • I began to think in terms for the user of the API more than its creator. This kept me away from adding hacks which could fix the issue but would be difficult to test. This tremendously improved the code structure then what I had written before.
  • No server restarts, no wasting of ~ 8 minutes per restart, no wasting of navigating to the pages. I just had to edit the code, run the junits and see the tests decide the fate. This is more useful for the backend code I have written.
  • No loss in focus as I am deeply involved in Code-Test cycles.
  • Sense of achievement as I see the tests show up green bars.
  • Possibility of creating a code with good unit tests to test the backend features, which also helps in refactoring the code more easily.

Now I just have to write the glue code for the UI and the backend and test the glue code via the selenium tests.

Anyone had any similar experiences when they started to use TDD?

[ Image Source: http://www.doolwind.com/blog/]

Using JDeodorant to refactor java code

I got to know about JDeodorant– a tool for identifying bad smells in code and helping it to refactor. I got curious and downloaded its Eclipse plugin, I then picked the first bad smell code which Martin Fowler explains in his book: “Refactoring: Improving the design of existing code”. I tried my hand at refactoring a long method by Extract Method refactor move. Here’s the long method:
Continue reading “Using JDeodorant to refactor java code”

Why is the legacy code is the way it is?

What is legacy code?

At the start of the post I tried to get some definition for the term: “legacy”. (we wish if the noun was true! but indirectly they are one of the reasons for our pay). The adjective definition is somewhat closer to our “legacy code”.

Legacy code is something:

that has been written previously ( may be years old or even months, may be written by another developer or by the same developer) and continues to work just well to satisfy the customer needs.

that is being written as I am writing this post (and it is something which evolves to a legacy code stature in no time) and just enough to implement the requirements.

google search for define: legacy gives:

leg·a·cy/ˈlegəsē/

Noun: An amount of money or property left to someone in a will.

Adjective: Denoting software or hardware that has been superseded but is difficult to replace because of its wide use.

Most of us would have worked on legacy code OR are working on it OR are even creating legacy code (!!). Just the thought of working on legacy code makes developers spend sleepless nights (yeah, slight exaggeration, but required to highlight the pain). We have yelled and cursed while working on legacy code. Lets step back and reflect a bit about legacy code and see how it can be tackled (if at all!) Continue reading “Why is the legacy code is the way it is?”