Edge Side Includes (ESI)

Traditionally web applications were meant to serve static content, wherein the server generated an HTML response to the client’s request (typically HTTP) and sent it back to the client. The response was then rendered on user’s screen (browser window) by the client (browser). In order to increase user-perceived performance, such static content was cached at the edge of Internet so that it could be served faster. Content Delivery Networks (CDNs) have been used commercially for such purposes.

Minting Money!!

Come on guys, this blog will not tell you how to create real money and I have no secret plates which will allow you to print real currency. This blog is about Enterprise Applications and how they deal with money.

We all work for money but no one really understands how money works. Enterprise Applications are mostly concerned with Money and Time. As developers, we always have to simulate this into our system. It is used so frequently in enterprise applications that it could be used as basic data types.

As an ignorant developer, I started developing code with integer. Then I realized that we can also have cents. Hence, I changed money to represent as a float.As far as addition or subtraction is concerned it worked well. The problem started when multiplication and division operations had to be performed on money. This is common during calculations of interest rates and dividend.

The problem here is that only central banks of a country have the right to create or destroy money. So your application is not supposed to create or lose money from your system. However, the computer calculation is not always accurate or precise. What seems obvious to you will not work with computer arithmetic. To elaborate this problem let’s take an example. Suppose you want to divide 12 Dollars into 70% and 30 % you would expect to as below:

12 * 0.3                 = 03.60
12 * 0.7                 = 08.40
   Total                     = 12.00

Java treats 0.3 and 0.7 as double. However, due to the internal representation of the system and rounding the actual calculation happens as below:

12 * 0.3                 = 03.59
12 * 0.7                 = 08.39
Total                     = 11.98

This is incorrect as we are losing 2 cents in the whole calculation, which will scare Accountants.

Use BigDecimal

Now to resolve this problem we have to use BigDecimal. To make this example work we will be using the code as below:

   BigDecimal dotThree = new BigDecimal(“0.3”);
dotThree.setScale(2, RoundingMode.HALF_DOWN);

BigDecimal dotSeven = new BigDecimal(“0.7”);
dotSeven.setScale(2, RoundingMode.HALF_DOWN);

BigDecimal result1 = twelve.multiply(dotThree);
BigDecimal result2 = twelve.multiply(dotSeven);

This will result in calculation which is expected as below:

12 * 0.3                 =   3.6
12 * 0.7                 =   8.4
Total                     = 12.0

To give fine grain control over BigDecimal we create wrapper class of BigDecimal which represents Money. Let’s call this class the same

     class Money {             
         BigDecimal value;

         public Money(String stValue)
value=new BigDecimal(stValue);

To avoid constantly setting the scale of currency class we can add one more constant called DEFAULT_SCALE. This can be different for different countries as well as different applications

     class Money {
             MathContext DEFAULT_SCALE=new MathContext(5,0);
BigDecimal value;
MathContext scale;

Describing Currency

Avoid using String to represent currency. This is error prone and will lead you to confusions like “USD, “usd” “Dollar”, which are same but will have different strings. We already have java.util.Currency class to do this.
Another interesting fact is that we can easily get Currency from Locale via

   Currency currency = Currency.getInstance(Locale.US);

This is useful when you are developing web applications which pass your client browser location. We can also use ISO 4217 codes to create the currency object.

  Currency currency = Currency.getInstance(“USD”);

Combined Result

Using above 3 states we can have different constructors to construct objects from:

           class Money {
           BigDecimal value;
Currency currency;
MathContext scale;

of(Currency curreny,Number number)
of(String currencyCode,Number number)
of(Currency currency,Number number,MathContext)
of(Currency currency,BigDecimal number)

We also have to copy all arithmetic operations which are available in BigDecimal class. They are mainly abs(), ulp(), pow(n), remainder(money),add(), doubleValue(), floadValue(), byteValue() but before applying any operation on this class we have to check the currencies are same.

    public Money divide(Money divisor){
check(this.currency, divisor);
BigDecimal result = this.value.divide(value, this.scale);
return new Money(this.currency, result, this.scale);

        private static final void check(Currency currency, Money amount){
                if (amount == null) {

                      throw new IllegalArgumentException(
                        “Amount should not be null”);
final Currency amountCurrency = amount.currency;

if (!currency.getCurrencyCode().

throw new IllegalArgumentException(

                         “Currency Mismatch happened”);


What is implemented is really the bare minimum to get started. We haven’t covered anything on currency conversions, different money formats and virtual currencies.

If your application heavily uses different currencies, you should look at JodaMoney. This is written by the author of JodaTime. Although not as popular as JodaTime, this is a viable option till JSR354 is part of JDK. It also provides good support for currency exchange.

JSR 354
This is planned to be part of JDK 9 which might be released in year 2016. There are new concepts added in this JSR like CurrencyUnit, MonetaryAmount and other classes.


Since JSR354 is yet to be a part of JDK and JodaMoney was too complicated for our requirements, we somehow built JSR 354 compatible classes in our project with similar public interface. Hence, in the latter JDK version we will be able to rewire and discard these custom classes. Until then, if your application is heavily dealing with currency, JodaMoney is the best available option.


Using Revealing Module Pattern with Web Interface Design

I recently joined a project that required me to develop a mobile website for the client. We already had a fully functional desktop version of the website. There were around 10000+ lines of JavaScript code for the existing desktop website and most of it was not at all reusable for the mobile website. The purpose of this blog post is to identify what went wrong with the original design of the JavaScript code and to provide a solution that could have saved around two to three weeks of (re)work.


The Problems

Following are some issues that made us re-implement the complete functionality from scratch. Later the approach and guidelines that we implemented to avoid the same problem again will be discussed.

JQuery (mis)usage
Many methods implementing some business logic were used $(‘#id’) to access values. To reuse this code, I’d have had to use exactly same id/classes for elements.

Too many document.ready()
Each script included on the page had its own document ready handler. Multiple entry points made it hard to determine the flow of code.

Modular approach
The whole JavaScript code was organized as global functions. Need I say more?

Code Repetition
At some places, very similar or even the same functionality was implemented in different functions. Validation and error handling code was also repeated at a number of places.

Repeated element ids

Same elements id were used at a number of places.

What Affects What?
It was hard to determine which piece of code was intended for which part of the page. Some JavaScript files were being used on multiple pages. There each page was broken into several jspx files that may or may not be included on the page depending on some business logic. Also, some of those jspx had conditions of their own to add or skip some elements.

The Required Solution

Now that we have looked at the major problems with the existing JavaScript code, let’s take each of the problems and see what we can do to avoid them.
JQuery (mis)usage
To fix this, we needed to separate the business logic from UI logic. E.g. code to update user information on server should not be defined in the click handler of the submit button. We should, instead, put the ajax call in a separate function, taking the user details as parameters. The click handler should gather user details from form elements and pass them to the function. Similarly, use callbacks to update UI when a response is received from the server.

In UI code, we should be able to somewhere define ids of various form fields instead of hard coding field ids everywhere.

Too many document.ready()  
There should be only one script with document ready handler, and it should be responsible to initialize various modules used on the page.
Modular approach & What affects what?
We needed an object oriented approach with business and UI logic in separate modules. Also, we needed some sort of mapping between the UI modules and jspx files. This would make it easier to determine exactly what code needs to be updated if something changes on the UI.
Code repetition
We needed to organize modules neatly. The business logic modules should have some sort of hierarchy based on functionality. The UI modules should maintain same hierarchy as the back end jspx files.
The validation and error handling code should be moved outside business and UI logic, in separate modules of their own.
Repeated element ids
It was simple to use unique ids in a single jspx file. However, on a completely rendered page we could still have repeated ids, especially when a jspx file was included more than once on a page. So, while inserting a jspx file, we also needed to wrap it inside a div container with unique id. We also needed some approach to be able to identify each element without specifying complete id-hierarchy.

Coding/Design Guidelines

To implement the changes suggested in the previous section, I had to write some utility modules to handle things such as validation, error handling, a JQuery wrapper to transparently access DOM elements with full id etc.

Following are some design and coding guidelines that I followed while implementing the mobile website.

Jspx Design Guidelines

  • Every id in a jspx file should be unique.
  • Every jspx file should be included inside a div container of its own; the container should be given a unique id in the jspx file.
  • All form fields should use a common markup style at all places e.g. each field should be placed inside a div container with proper classes such as ‘textbox’, ‘disabled’, ‘read-only’ etc

JavaScript coding guidelines

  • Organize the code in some meaningful namespaces, clearly separating business logic, UI logic and form validation and error handling code.
  • None of the code in business logic must interact with UI. Any of the business logic functions must accept required data and callback functions as arguments.
  • The business logic modules should be singletons unless it is required to create multiple objects of the module.
  • A UI module should be created for each jspx file.
  • For each jspx file included, a module must create objects of each of the module respective to included jspx files.
  • Any HTML element should be accessed only by its respective module.
  • While creating a child UI module, the parent module must pass the full id of its child jspx’s container div to the child module.
  • Define all form fields and HTML elements of the respective jspx accessed in the module.
  • While accessing any field by id in a UI module, the field id should be appended to the full id of the container div passed by the parent module. (We implemented a utility module to transparently handle this).
  • Define callbacks in each UI module for any event that might be interesting to the parent module.  e.g. submitButtonClicked, someCheckBoxChecked etc.
  • In case a child module needs to update parent module for some event, it must do so via callbacks. The parent module needs to set these callbacks at the time of creating the child module object.
  • Define public functions for actions requested by parent module. e.g. enableSubmitButton(), showSomeHiddenElement() etc.
  • In case a parent module needs to update UI for a child module, it must do via public functions exposed by the child module.
  • Don’t access HTML element attributes directly. For example, to hide elements don’t change display style. Create CSS classes for each required state of HTML elements and add/remove these classes to update any
  • Avoid creating id based CSS rules and using classes in JavaScript.
Summing up everything, the following is what we achieved by using the new approach for developing the mobile website:
  • The business logic is now completely separate from the UI code, and can be used independent of UI code.
  • The UI code has direct mapping with the jspx files. If a jspx file is modified, only its respective is modified.
  • Since all fields and HTML elements are defined in each module, changing ids of fields in jspx file requires just a single update in its module.
  • All JQuery dependent code has been moved to the ModuleHelper module. Although it might still require a lot of other changes, replacing JQuery with any other library requires minimal UI code changes.
  • Each HTML element is now uniquely identifiable by its module, even if the jspx file gets included multiple times on the same page.
  • Form validations and error handling are now completely removed from the UI code.

Further Reading:

Following are a few links for further reading on some basic JavaScript features and design patterns:
Functions in JavaScript are First Class Objects
JavaScript Closures
JavaScript Design Patterns

MobileJira launched at the Windows App Store

Talentica’s Mobile Team recently launched the Windows version of the popular MobileJira App. The App, which is already available in the Android Play Store, is useful for all IT professionals who use Jira to track issues, bugs, tasks or deadlines for their projects.

Loaded with unique features, MobileJira is designed for simplicity and ease of use. It is targeted towards improving productivity and process compliance of testers, developers and managers. It helps manage JIRA tickets on the go for requirements like progress-update/resolve or close issues. It also supports major functionalities like search, issue details, updating work log/comments and view attachment.

MobileJira supports JIRA® 5.0 or later. It’s based on JIRA® REST API’s and requires the JIRA® server to run as a service. More details are available at Running JIRA as a Service.

Visit the Windows App Store to download the app.

Feel free to send in your feedback or suggestions at support-mobilejira@talentica.com to help us further improve the app.

Multidimensional Drill-downs using Cassandra

Multidimensional data is the type of data that has hierarchies. These hierarchies can be implicit or explicit. One of the most useful ways of navigating multidimensional hierarchies is by using drill-downs. This implies moving from summary information to detailed data by focusing in on something. These drill-downs cannot be handled through RDBMS solutions, as each additional drill-down is essentially a new where clause, and this gets progressively slower for large data.

Traditionally the problem of having consistently fast drill-downs was solved using special multidimensional data structures like OLAP cubes and MDX queries. However, with the advent of NoSQL technologies like Cassandra, we now have faster and cheaper ways of supporting these drill-downs.

Cassandra is an Open Source distributed database management system. The main feature of the system are decentralization, replication support with multi data center replication, elastic scalability, fault-tolerance, tunable consistency, MapReduce support and an SQL like query language (CQL).

To get into the problem of drill-downs, let’s look at some sample data from a shopping cart:

timestamp, transaction_id, item_code, user_id, payment_method
20130304221518, abcd, 3, 5, creditcard
20130304221519, efgh, 4, 6, cashondelivery
20130305180402, ijkl, 4, 5, loyaltypoints

This data isn’t directly useful for analytics. Most analytics is about finding patterns and making marketing or other business decisions based on them. The useful information that can be derived from this raw data is as follows:

{month: march} {number of transactions: 3, unique_users: 2, unique_items_sold: 2}
{month: march, item: 4}{number of transactions: 2, unique_users: 2}
{month: march, day: 4} {number of transactions: 2, unique_users: 2, unique_items_sold: 2}
{item: 4, payment: cashondelivery} {number of transactions: 1, unique_users: 1, items_sold: 1}

Clearly, what we are trying to deduce here are aggregate numbers based on various combination of dimensions. When in RDBMS, the data we require can be found using queries with count, unique and where clauses. It is also evident that when this data grows to large sizes, the potential amount of joins in such queries will result in considerably long-running queries.

Thus, a better way to handle serving these kinds of aggregations in a reasonable amount of time is to pre-compute these aggregates and store them. This is where NoSQL technologies provide a distinct advantage, due to the lack of predefined schemas in them. This allows us to store similar combinations in a single column family (Cassandra’s tables), which in turn lets us serve extremely fast drill-downs. To illustrate this, let’s look at how the above data will be stored in Cassandra:

Column Family: Monthly{
    Rowkey: March {
         number_of_transactions: 3,
         unique_users: 2,
         unique_items_sold: 2

     Rowkey: March, Item:4 {
         number of transactions: 2,

     Rowkey: March, Day:4 {
         number of transactions: 2,
         unique_users: 2.
         unique_items_sold: 2

     Rowkey: March, Item:4, Day:4 {
         number of transactions: 1,
         unique_users: 1,
         items_sold: 1

With the above data model in place, fetching a drill-down on March for items is as simple as forming the key and doing one fetch, fast and join-less.

The logical question to ask here is when we start making these kind of combinations for every value of every dimension in our data, what about data size and data explosion. This is a real problem as the storage requirements for this kind of data is huge. Cassandra helps here by providing elastic scalability with linear performance and storage addition as number of nodes increase.

However, this problem also warrants having some data specific optimizations. One of these is to limit your combinations to only those values which make business sense. Generate data by judicious selection of what subsets you want to produce to serve your end users.

Finally, this is only one of the problem cases where Cassandra is useful and is one of the solutions for this problem. Let us know if you have ever needed to solve this kind of a problem, the way you did it, or if you are using Cassandra to solve any other interesting problems.