Date JsonFormat for Jackson

The default format from java.util.Date after serialized into JSON is a long number. That is not at all human readable for a Date like 07/21/2016 14:43:25.  There are many solutions to this, including pre and post formatting on the client side (AngularJS, JQuery)  as well as ObjectMapper on the Server side. But the easiest solution to me is to use com.fasterxml.jackson.annotation.JsonFormat annotation so Jackson will marshal and un-marshal the Date correctly. On the client side, only a Date picker that will restrict the user Date format will do the trick. No other coding is needed!

import com.fasterxml.jackson.annotation.JsonFormat;
import java.util.Date;

 @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "MM/dd/yyyy HH:mm:ss", timezone = "America/New_York")
  private Date update_date;


ngOptions track by to select the matched value from options

Happy Friday!

After AngularJS 1.2, you don’t need to use ng-repeat to display options for <select> element. Instead, it is recommended to use ng-options, such as this below,  where items is an Array of object item.

<select ng-model=”selectedItem” ng-options=”item as item.label for item in items”></select>

However, the above doesn’t display the selectedItem as selected if there is a match with the value of the object in the Array items.


No worries! AngularJS now has a nice expression to make that so easy to achieve, by using track by:

<select ng-model=”selectedItem” ng-options=”item as item.label for item in items track by item.value“></select>

Now if there is a match of values between the selectedItem and one Option in the Array, that Option is selected!

AngularJS really rocks!  well, most of the time 🙂




How to start your OWN microservice?

Happy the 4th! I would like to put down some thoughts about microservice today while I am waiting for the BBQ and fireworks!

Microservice has been buzzing in very recent years, partly due to industrial cloud players like AWS, Azure. True Microservice is really revolutionary because it is against the traditional organizational layout of companies. From front end developers, midware developers to database designers, organizationally they are typically separate groups. The grain goes horizontally instead of vertically. A true microservice relies on vertical grain in that same group of people with a team size of 6-8 handles front/middle/backend. One microservice is cared by only one such a team that knows things up and down. In a big organization, this kind of set up is truly new and generally hard to change into.

Splitting front and middle layer into many modules is not considered microservice. That is modularization or SOA at the best. True microservice should start from the model/DB layer. Splitting DB layer into collections of related entities to me is the most challenging part of microservicing in that it is against our traditional ways of doing things. For the same reason, microservice should start from the model layer, setting up boundaries and interfaces between them, as well as shared concept and models. In my opinion, jobs of developers of microservice should become more focused and simpler (not necessarily easier), and jobs of architects will get harder and harder. Risk of imperfect architecting gets even greater.

So how would you start your own microservice architect in a traditional organizational set up, especially for old monolithic applications? My view is that you can always start with those components in your application that don’t require backend layer or only relies on other services. I know this is basically avoiding the problem of slicing backend layer. But for getting onto the microservice bandwagon, it is a good start with low risk. This approach should provide valuable lessons from both technical and organizational aspects. has microservice that only provides a submit button or only calculates tax. These kind of microservices typically don’t need backend layer redesign or their backend is very simply isolated. I would imaging many common services such as encryption/decryption, logging, scheduling can be implemented as such microservices.

Last, microservices really works well with DevOps. Imagine how hard it is for testers and sysadmins when you have hundreds or thousands of microservices in your data center!  But I will leave DevOps to another post.