Studying biz rule tables used on Wall St

Background: many rule based systems (on Wall St or elsewhere) have thousands of rules in database tables. The simplest and most used pattern is the lookup table. A lookup table has one (or more) input columns and one (or more) output columns.

Each combination of input fields maps to exactly one row. There should be a unique composite index on the input columns as a group.

The concept is simple, but sometimes needs to be hand-crafted and perfected, because
* these rules are often part of the most important 1% source code in a big code base
* users change rules frequently, at least in some Wall St firms
* we often need to query the tables with complex criteria. Such complex queries are usually implemented in source code, but for quick production support we often need to run them by hand, tweak and rerun. In some cases, we end up learning all the intricacies by heart. If your full time job is a spell-checker you won’t need the dictionary much.
* we often need to explain how rules are disqualified, filtered out, ranked, grouped, applied, overlayed, re-applied…. Many IT veterans would say blow-by-blow knowledge of a code module is needed in extremely rare situations.. Welcome to Wall St these business rules are examined and tweaked on a daily basis by multiple groups of users.

Compare with Informatica lookup transform.


2 ways for http sessions to share a single object

2 ways for sessions to share a single huge object

Requirement: a huge object to be instantiated before the first session, and kept alive after all sessions end. Object is not immutable.

Solution 1: put that object in an app-scope bean.

Solution 2: static field in a special class. Your huge object will be reachable from the persistent class-object.

Objects used by each method call

When studying method calls (aka messages) among objects, look for the objects used by each call. For a “call” (a better focus than “method”), the most important objects in practice are, ranked by usage

– member objects in the args — folks often pass in a collection or “composed” object just to pass in member objects.

– member objects in the host

– args

– host object — If the host object is not used by the call, then this method should be static.

– caller object must appear as args, like m1(this,.) — Without “this” as an argument, the call can’t access the caller object. Caller object exists as a “local” variable upstairs the call stack (thread).

## IV halo across domains #specific=better

See also —, [[ further improve ]], [[ towards an architect ]]. This halo list is not that rigorous, only a /sideshow/.

If you invest more than enough into …. say, java concurrency, you may grow an invisible little halo in the eyes of peers and interviewers. Other halos: google brank, microsoft brank, GS brank

  1. [a] lock free, CAS, statement reordering, membar, volatile^atomic
  2. conditionVar, spurious wake-up
  3. [a] read/write lock, tryLock, deadlock prevention
  4. [a] tail recursion
  5. sql tun` including EXPLAIN, hints, statistics,
  6. [a] hash table internals, red black tree
  7. [a] O(n) sorts
  8. [a] Morris

C++ specific:

  1. [ah] compile-time template meta-programming
  2. smart pointers used with factory, class field etc
  3. epoll,
  4. [h] reinterpret_cast

Java specific:

  1. jvm tun` including mem, GC, profilers
  2. thread pool usage and internals
  3. callable/future
  4. [h] remote debugging
  5. [h] reflection? not really seen as halo
  6. [h] JMX
  7. [a] concurrent skip list,


  • [a] tx isolation levels
  • solaris/linux tun` && capacity plann`@@ Rember the Solaris 10 seminar?
  • serialization

[a=academic, could be considered zbs, never really needed in GTD]
[h=hacky, powerful black magic, rather useful but often frowned upon]

STL creators’ design priority

Simplicity and ease of use was a low priority for the STL creators. Efficiency is perhaps #1 design priority. Both time cost and space cost. I guess STL was designed to be usable in telecom and other real time small equipment with limited memory and CPU resources.

Whenever people optimize for efficiency, they *specialize* their components for various scenarios. I think that explains the proliferation of iterators. Also, many algorithms overlap, as methods and as free functions.

Template itself was invented for efficiency, at the cost of simplicity. STL exemplifies template usage. Efficiency in terms of code reuse and algorithm abstraction.

The father of STL doesn’t believe in OO. Any OO design in STL? STL was designed just like C (without classes) — for maximum algorithm efficiency and maximum abstraction. Classes and templates were employed as a means to that end.

top 5 tibRV objects for Java developers

* msg objects — well-defined entity beans
* transport objects

The 3 objects below build on top of msg and transports … These are described in one single chapter [[Events and Queues]] in the java documentation.

* listener objects
* callback objects, implementing onMsg()
* queue objects and dispatchable interface

Less important:
* dispatcher object (subclass of Thread)

Once you understand the above, you can see that certified messaging builds on top of them:
* CM transport objects
* CM listener objects
* CM review callback — for reviewing “missed calls”
* CM msg objects

java collections — practical questions

Q: most popular concurrent data structures?
A: concurrent hash map is #1. #2 is blocking queues. Both use interface

Q: drawback of concurrent hash map?
A: size()?

Q: most useful utilities in
A: sort, synchronized….

Q: what’s concurrent modification exception?

Q: what’s fail fast?
A: see javadoc on ConcurrentModificationException

Q: interviewer’s favorites?
A: hash tables is #1, also array list, linked list,

eclipse Factory refactor — keywords

Background: you apply this operation “introduce factory” on an existing contructor.

* new factory class or same class — new factory method can be created in the same class as the contructor or in a new factory class. Both are standard practices.

* return interface — instead of classes. Eclipse can’t automatically.

* static — method. Usually the factory method is static, to allow everyone to call it.

* private — by default the original contructor gets privatized

y Trigger

A few benefits of triggers in the mortgage commissions system

* testability — To test the triggers, just run one or a bunch of inserts. Use sqsh, aqua studio, fitnesse or any other tool. If the logic is in Perl/Java, i don’t think it would be so simple.

* Modular — All (and only) the logic related to inserting records are contained in the triggers. This is separate from other logic. Separation of concern. Other developers are shielded from the complexity of saving records.

* complexity — The insert trigger in the MtgAccts table involves more than 5 queries. To implement the same logic using Java or Perl would take 3-5 times more lines of code, by my estimate.

* flexibility — during production support. Suppose we need to load a few records for a production issue. Just write the query by hand and test in QA and then run it in sqsh/aqua or another tool.
* reuse — 70% of the trigger code in MtgAccts table are used in other tables and also used in the spApproveMtg stored proc.

There are some concerns …

* performance — is not a top priority. Each month’s load job takes less than 30 seconds now.

* UDB — There’s some concern over migrating stored proc and triggers to UDB. Trigger support in UDB is probably richer than sybase. Therefore the triggers are probably UDB-friendly.

no throw from destructors please is a short and clear explanation. Here are my comments:
No throw please until you catch the original exception. In fact, Most if not all the methods in exception class are declared with an empty throw()

The C++ rule is that you must never throw an exception from a destructor that is being called during the “stack unwinding” process of another exception. For example, if someone says throw Foo(), the stack will be unwound so all the stack frames between the throw Foo() and the } catch (Foo e) { will get popped. This is called stack unwinding.
During stack unwinding, all the local objects in all those stack frames are destructed. If one of those destructors throws an exception (say it throws a Bar object), the C++ runtime system is in a no-win situation: should it ignore the Bar and end up in the } catch (Foo e) { where it was originally headed? Should it ignore the Foo and look for a } catch (Bar e) { handler? There is no good answer — either choice loses information.
So the C++ language guarantees that it will call terminate() at this point, and terminate() kills the process. Bang you’re dead.
The easy way to prevent this is never throw an exception from a destructor. But if you really want to be clever, you can say never throw an exception from a destructor while processing another exception. But in this second case, you’re in a difficult situation: the destructor itself needs code to handle both throwing an exception and doing “something else”, and the caller has no guarantees as to what might happen when the destructor detects an error (it might throw an exception, it might do “something else”). So the whole solution is harder to write. So the easy thing to do is always do “something else”. That is, never throw an exception from a destructor.
Of course the word never should be “in quotes” since there is always some situation somewhere where the rule won’t hold. But certainly at least 99% of the time this is a good rule of thumb.