The costly whistles

Benjamin Franklin recalls an interesting childhood experience that he had.

When he was seven years old, his friends/family filled his pocket with coppers. He went to a toy shop where he got charmed by the sound of a whistle. Later on they way back he found a similar whistle in the hands of another boy to whom he gave all his coppers in exchange of the whistle. He came back home and happily whistled all over the place in excitement. When his siblings came to know about the bargain, they told poor little Ben that he has paid four times more for the whistle than what it was worth. On this Ben's thoughts shifted focus from the excitement of possessing the whistle to what other good things he would have bought with the rest of the money.


A grown up Benjamin Franklin writes "As I grew up, came into the world, and observed the actions of men, I thought I met with many, very many, who gave too much for the whistle."


All of us have the experience of having paid too much for our whistles. In personal relationships, professional careers, business transactions and personal beliefs. All of us possess whistles which were very exciting initially but turned out to be too costly later.

DCI Architecture

DCI (Data Context Interaction) is a concept that could help us model our business solutions better. Proposed by Trygve Reenskaug (the creator of MVC), and Jim Coplien (well known expert on OOP and patterns).

DCI aims to have a simplified and more commonsense approach to "Object-Oriented Design". The key observation made is that most object-oriented approaches captures the structural aspects of systems well, they are not so good at effectively handling the behavioral and interaction aspects.

DCI stands for: D: Data, C: Context, I: Interaction.

Most software systems has these three aspects. The structural aspects (Data), Interacts with each other in well defined Contexts.

The main article by Jim Coplien could be found here.
A presentation and interview by Jim Coplien.

Ten Principles of Good Design: Dieter Rams

The ten principles of good design from the famous German designer Dieter Rams. They are generic and makes sense in any industry or product:-

1. Good design is innovative.
2. Good design makes a product useful.
3. Good design is aesthetic.
4. Good design makes a product understandable.
5. Good design is unobtrusive.
6. Good design is honest.
7. Good design is long-lasting.
8. Good design is thorough down to the last detail.
9. Good design is environmentally friendly.
10. Good design is as little design as possible.

More details about Dieter Rams & the principles here.

Embedded Jetty Server

A simple utility class to embed Jetty web server:

import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.servlet.FilterHolder;
import org.eclipse.jetty.servlet.FilterMapping;
import org.eclipse.jetty.servlet.ServletContextHandler;
import org.eclipse.jetty.servlet.ServletHolder;

public enum WebContainer {
 INSTANCE;
 private Server server;

 public void startServer(String resourceBase, String contextPath, int port) {
  try {
   server = new Server(port);
   ServletContextHandler handler = new ServletContextHandler(ServletContextHandler.SESSIONS);
   handler.setContextPath(contextPath);
   handler.setResourceBase(resourceBase);
   server.setHandler(handler);
////////////////////////////////////////////////////////
//   add servlet context init params using the following
//   handler.getServletContext().setInitParameter(, );
////////////////////////////////////////////////////////

////////////////////////////////////////////////////////
//   add event listeners using
//   handler.addEventListener();
////////////////////////////////////////////////////////

////////////////////////////////////////////////////////
//   add filters using
//   handler.addFilter(, , );
////////////////////////////////////////////////////////
////////////////////////////////////////////////////////
//   add servlets using
//   handler.addServlet(, );
////////////////////////////////////////////////////////
   server.start();
   server.join();
  } catch(Exception e) {
   e.printStackTrace();
  }
 }
 
 public void stopServer() {
  try {
   server.stop();
  } catch(Exception e) {
   e.printStackTrace();
  }
 }
}

Use WebContainer.INSTANCE.startServer(...); and WebContainer.INSTANCE.stopServer(); to start and stop the server respectively.

Implementing a simple deterministic rule engine

The following is my experience of implementing a simple deterministic rule engine (if at all it can be called such) in JavaScript using Mozilla Rhino. This was part of the enterprise platform we are building in our company. We tried using Rete based JBoss Drools earlier but felt that a simpler deterministic rule engine would better suit our purpose.

The need for such a thing was due to various reasons:-
i) Rete based stateful rule engine was an overkill for our use case
ii) The non deterministic and asynchronous nature of Rete based rule engines makes debugging and testing very difficult (as pointed out by Martin Fowler)
iii) Most of the rules in our case were of the nature of validations or calculations which makes Rete an overkill
iv) A tailor made custom rule engine gives more flexibility and power
v) Our consumers (product developers) were not at ease with the programming style of traditional rule based approach


The approach went something like this:-
i) Enable server side scripting in JavaScript using Mozilla's Rhino engine
ii) Capture rules as metadata in the form of JavaScript statements (majority of them will be of the form if condition then action)
iii) Expose domain objects and other relevant APIs into the rule scripts at well defined lifecycle phases of entities (CREATE, UPDATE, DELETE, etc.)
iv) Execute the rule scripts within the context of domain objects and relevant APIs during the life cycle of domain objects (typically CRUD phases)
v) We also support a MANUAL context wherein developers can set relevant domain objects explicitly and invoke the rule engine

The beauty of LISP (and Clojure)

A couple of years ago, I accidentally came across the strange word Clojure, which I later came to know as a LISP style programming language on the JVM. At that point I was a total newbie to functional programming (and LISP), having spend most of my programming time on C, C++, Java, etc.

The first impression I had when looking at a medium size Clojure program was that of a mess of parenthesis. Why in the world would anybody want to write programs of this sort?

As many others, it took a while for me to truly appreciate the simplicity, elegance and beauty of functional programming in general and LISP in particular.

Clojure might have a popular future due to its clean way of handling concurrency and light weight threads (through Software Transactional Memories aka STM)

Hats off to John McCarthy for creating LISP and Rich Hickey for creating Clojure.

Handling Spring ApplicationContext events in Spring DM based OSGi environment

Listening for and handling Spring ApplicationContext events in a Spring DM setup needs needs two steps:

1) Implement a class for the interface org.springframework.osgi.context.event.OsgiBundleApplicationContextListener

import org.osgi.framework.Bundle;
import org.springframework.context.ApplicationContext;
import org.springframework.osgi.context.event.OsgiBundleApplicationContextEvent;
import org.springframework.osgi.context.event.OsgiBundleApplicationContextListener;
import org.springframework.osgi.context.event.OsgiBundleContextClosedEvent;
import org.springframework.osgi.context.event.OsgiBundleContextRefreshedEvent;

public class BundleApplicationContextTracker implements OsgiBundleApplicationContextListener {
 public void onOsgiApplicationEvent(OsgiBundleApplicationContextEvent event) {
  if(event instanceof OsgiBundleContextRefreshedEvent) {
   // handle bundle start
  } else if(event instanceof OsgiBundleContextClosedEvent) {
   // handle bundle close
  }
 } 
}

2) Expose the above class as an OSGi service by putting the following entries in Spring beans-config.xml

<beans:bean id="bundleContextTracker" class="org.mypackage.BundleApplicationContextTracker" scope="singleton"/>
<osgi:service id="bundleContextTrackerOSGi" ref="bundleContextTracker" interface="org.springframework.osgi.context.event.OsgiBundleApplicationContextListener"/>