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 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.
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
– 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).
See also — relevant55.tech.txt, [[ 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
) lock free
) jvm tun` including mem, GC
) sql tun` including EXPLAIN, hints, statistics,
) CHM, concurrent skip list,
) hash table internals, red black tree
) multicast IP address + UDP
) tx isolation levels) solaris/linux tun` && capacity plann`@@ Rember the Solaris 10 seminar?
# also-rans) reflection? not really seen as halo
) thread pool, callable/future
) Oracle/Sybase instance tun`
* 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
* 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
Q: most popular concurrent data structures?
A: concurrent hash map is #1. #2 is blocking queues. Both use Lock.java interface
Q: drawback of concurrent hash map?
Q: most useful utilities in Collections.java?
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,
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