Thursday, November 20, 2008

Code Kata: The Business Rules

I'm thinking of an application for JBoss Drools. We are given a task to design a system for order management (OMS), which will sit behind a FIX gateway and serve several internal and external systems. One thing is for sure - we are to take a challenge to organize and maintain a large set of business rules and this brings up some memories.

In 2004 a colleague told me about code kata. These are the good exercises to do when learning a new language, or just empirically solve some common problems. One of the puzzlers sit in my mind permanently since then - The Business Rules Kata, which is about the hard to maintain complex business rules.
How can you tame these wild business rules? How can you build a system that will be flexible enough to handle both the complexity and the need for change? And how can you do it without condemming yourself to years and years of mindless support?

We face all these problems daily while coding the business logic for our banking system. One of the approaches some developers have taken is that
the if-the statements can be avoided while using appropriate OOP techniques

The problem is that sometimes while avoiding those if-statements the code becomes over-engineered due to a large number of classes. And it is still doesn't solve the problem of quick changes that are very hard to implement in a big organization with the "release process".

Recently I've found a discussion at It is dated 2005 but I think not much have changed since then. I think that most of the developers are still fighting the complexity of the business rules and in future it will still be a challenge.

My next step is to create a demo using JBoss Drools, QuickFIX/J. Apache Camel can be used to integrate both into one flow.

Also what is really cool about Drools is that it would allow our clients to maintain the order validation rules apart of the overall release process using Guvnor. So the changes in order validation logic could be introduced rapidly.

The TAGRI Approach To Ducumentation

I found a nice blog post called Developers Aren't Gonna Read It about the software requirements documentation principles, which actually refers to Scott W. Ambler's post called The TAGRI (They Aren't Gonna Read It) Principle of Software Development.
The idea behind these posts is that the developers do not read documentation. And to be honest - yes! it is true! I don't remember myself reading the documentation for a long time. In fact, I don't remember if I really have read a single document produced by analyst from start to end. Thinking of the man-hours spent on the documentation by analysts it may be horrible to calculate the total cost that was spent to produce these documents.
I was responsible for the web UI part of this system (100 pages) but had to understand also how the backend works (200 pages). ... So, did I read the documentation? I didn't. I didn't have to because I preferred direct communication with the guys who know the system throughout.

Indeed, a very familiar situation.
Not all documentation sucks. ... the best documentation is the one that is very easily changeable. Wiki is the best option here - it's easily searchable (through many projects) and changeable.

I love wiki! IMHO, it is one of the best approaches to the communication and to hold the documentation, tips-and-tricks, tutorials, etc.

To me, the best solution is to really communicate verbally. Make it to the whiteboard and draw some concepts together with the analyst. It ensures we both use the same terms, and both understand the domain of the problem. I hope our team members feel the same.

Tuesday, November 18, 2008

Creating Database Link (aka DBLINK) in Oracle

I had to mess with Oracle database links recently. Here's a good reference to the "CREATE DATABASE LINK" sentence syntax.

In my case it was:

'mydb' has to be an entry in ORACLE_HOME/network/admin/tnsnames.ora file on the server side Oracle client installation, so that the host database can see the foreign one (which is 'mydb').

Next, make sure that sqlnet is configured to use tnsnames.ora file. Its configuration is defined ORACLE_HOME/network/admin/sqlnet.ora, which contains client side network configuration parameters (again, on the server side!). For instance:


Next, we could test this database link:

SELECT * FROM dual@mydb;

Now it makes sense to use a synonym to point to the foreign table.


Now the initial query will look as follows:


Saturday, November 8, 2008

GWT vs Flex

We have now some experience with GWT while implementing an enterprise price management system's UI. There are some nice features that GWT provides, but there are a lot of pain also while using some 3rd party widget library, like GWT-Ext. In my mind, the main problem is that while coding the solution using GWT, you loose the feeling of the application (especially if using a wrapper around a native JavaScript library). But this is just my feeing and doesn't really show if GWT is bad or good. Related to the real problems, when we had too many records to render in a data grid, we faced some performance problems - rendering all the records took quite a time and stalled the browser instance until the end of rendering process.
The 3rd issue I find relevant is the amount of code had to be produced for the layout and interactive behavior of the application. The Swing-style coding is a real blocker. IMHO, GWT probably make heavier use of annotations, perhaps even introduce some custom annotations for simplifying the implementation of user actions (i.e. listeners as inner classes).

After we almost finished the prototype, I started to think that probably, GWT is not really what we'd like to use in our application for the UI. I'm still strongly convinced that for this application we need a rich UI to satisfy the user. Adobe Flex was the next technology in our list. More than that, Flex is approved for our internal development by the architects council. So one our colleague presented us how is he using Flex to implement a RIA for loan management.. and smashing!!! I really liked the code separation for the UI: layout is defined in MXML files, events for the UI components are defined in a separate ActionScript files, and some utility code can also be separated into other scripts. Further more, the speed of making a convenient application was really fast. And also the amount of code to be written is much less than with GWT. No layout problems in the resulted swf, rendering a data grid with thousands of rows was just blizzard-fast compared to JavaScript analog.
I found some comparisons of GWT, Flex and Echo2 on the web: one and two
Both GWT and Flex 2 are Rich Internet Application (RIA) frameworks whose code is downloaded and executed on the client side, in the browser. GWT compiles Java code to JavaScript whereas Flex compiles a combination of ActionScript and MXML code to a Flash swf file.

And here's the quote I was waiting for:
...both GWT and Flex 2 have different situation where they each are better suited. HTML, CSS, JavaScript are still the best option when developing a web application intended for the general public. Flex 2 is would fit well when developing flashy business minded applications with a targeted audience.

I think this describes our case the most - a targeted audience.

Disqus for Code Impossible