frameworks, facades …"simplifiers"?

I have seen a lot of new api (or library, or framework) created to “simplify” something, to shield developers from the “tedious, error-prone details” i.e. complexity. These façades or wrappers often make the common tasks easy but could make the uncommon tasks harder. 
I feel the technical complexities often won't disappear out of thin air. If you have 
– demanding performance requirements (often requires some engineering and tuning)
– complex, unusual business requirements
– fast-changing requirements (which often requires higher flexibility than supported by the simplifiers)
– large distributed team 
… you have to, one way or another, deal with the details beneath the carpet or behind the facade. The raw material is more flexible.
I have heard many veterans comment that swing is very flexible or C is very flexible.
Here are some endorsed/sanctioned “simplifiers”: 
eg: garbage collector
eg: drag-n-drop programming
eg: high-level concurrency constructs
eg: dotnet wrappers over win32 constructs
eg: any tool to make a remote component feel like a local one

#1 of what I enjoy most – body-building

(Avichal asked me …)

#1 of what I enjoy most – body-building. There are various elements that make it challenging, engaging, sustainable

* some value-add for the tech community

* relevant to immediate IV -and- value-add-for-employer, which translates to stable and hopefully rising income…
Example – high performance c++ on linux

* unlocking additional job markets
Example – c++, c#, swing, socket
Example – FX domain knowledge
Example – quant stuff

* Real insight gained only by in-depth study, overcoming a non-trivial entry barrier, and building a lead over competitors
Example – quant trading strategy
Example – threading, STL,
Example – insights into c#
Example – stat risk content, even though not really relevant to my interviews.

* strategic value to my competitive position
counter-example: secDB

WPF binding system queries VM upon PropertyChanged event pointed out …

The INotifyPropertyChanged interface contains an event pseudo-field called PropertyChanged.

Whenever a property on a ViewModel object (or a Model object) has a new value, it can (should?) raise the PropertyChanged event to notify the WPF binding system. Upon receiving that notification, the binding system queries the property, and the bound property on some UI element receives the new value. I believe this is how new data hits the screen.

I believe the callbacks run on the UI thread, just like swing.

In order for WPF to know which property on the ViewModel object has changed, the PropertyChangedEventArgs class exposes a PropertyName property of type String. You must be careful to pass the correct property name into that event argument; otherwise, WPF will end up querying the wrong property for a new value.

For PropertyChanged to work, i think we have to use xaml binding with a prop name. In contrast, the alternative — defining ItemSource in codebehind probably doesn’t work. 

layout in wpf vs swing, a few pointers

Layout is one of the most important tasks of a GUI coder (as well as the artist). I get layout questions in my GUI job interviews. Despite all the advancement, veterans would probably agree layout is non-trivial. Both WPF and swing have tons of features on layout.

Swing layout is sometimes challenging/painful, esp. with window resizing. There are various advanced layout managers created to address the pains – gridbag etc. has some good pointers on wpf with references of swing –

* By default, WPF apps have a base Grid layout. Get rid of it and use “Dock Panel” as your base.  Dock Panels are the same as swing Border layout. The idea is to place the menu on top (DockPanel.Dock=”Top”), status bar bottom (DockPanel.Dock=”Bottom”) and put a Grid at the center. Now you have a well-behaved desktop app that reacts well to window re-sizes. 
* The Grid control is like Swing’s GridBagLayout only easier to use.
* Positioning — Use the AM (Alignment/Margin) to position elements in a container.
* Spacing — Use the margin + padding for spacing. If 2 buttons are side by side, don’t put a blank label in-between them to create space.
** In contrast, swing uses glue — has good pointers too —

– height/width — All controls provide a Height and Width but don’t fixed sizing.
** Set the Width and Height of elements to Auto whenever possible.
** For precise control, use the MinHeight, MaxHeight, MinWidth and MaxWidth properties to define a acceptable range.

2 frontiers between swing/OS

Between the swing layer and OS layer, there are 2 interactions “channels”. In other words, swing relies on 2 services provided by
the “hotel service desk” that’s the OS.

A: upward -> screen update, targetting a particular screen object
B: downward -> keyboard/mouse events when user interacts with a screen object

In both domains, data/events are bound to individual screen/visual objects. Eech screen object maps to one (or more) swing object + one (or more) native object “protected” by the OS. Remember OS is the wrapper layer on top of hardware, and all access to hardware must go through the OS.

You encounter low-level details when digging into either of the 2 domains
A: painting, java 2D, UI delegates
B: event pumping, low-level vs semantic events.

Multicast delegate in c# (+AWT), briefly

cf swing AWTEventMulticaster …
All c# delegate types are multicast. The word “multicast” is /superfluous/redundant/, just like Reentrant in ReentrantLock. You can similarly say silly things like “Secure SSL”, or “Reliable TCP”.

According to, a MulticastDelegate has a linked list of delegates, known as an invocation list. When a multicast delegate is invoked, the delegates in the invocation list are called _synchronously_ in the order in which they appear. says ” We abandoned the distinction between Delegate and MulticastDelegate towards the end of V1.” Even though MulticastDelegate type extend Delegate type, system will not even allow you to derive from Delegate directly. Instead, all delegates extend MulticastDelegate.

a greek’s value converges during expiration #my take

Let’s be clear what I mean — for a given greek (say, delta) of European options, regardless of which underlier, what strike or expiration month, the value of that greek tends to move towards predictable levels as we approach expiration.

Well before expiration, a greek is like a real-value variable which could take on any numerical value within a range. However, during the last days, BS formula predicts that a greek’s value (say delta) always gravitates towards some well-defined convergence points.

delta — either 1.0 or 0 (negative for puts). However, if underlier spot price fluctuates around my strike level (IF you remain very close to ATM), then I’m switching sides between ITM and OTM, so my delta would swing wildly between the 2 convergence 1.0 and 0.

gamma — either infinity or zero. ATM (IF you remain very close to ATM) would go to positive infinity gamma (for long positions); deep ITM/OTM go to zero gamma. However in the last moments there’s no point talking about infinity or zero gamma. If in the last minute spot is still changing around your strike level, then you basically close your eyes and wait to see if you finish ITM or OTM. Even if you finish ITM, the payoff would be a small [1] percentage of strike, and probably a small percentage of premium.

[1] unless you have a Binary option. If you finish ITM with a binary option, you effective win a million dollar bet.

theta — either infinity or zero. Similar to gamma, ATM would go to negative infinity theta; deep ITM/OTM go to zero theta.

option valuation — either $0 or stock price.

jcomponent / listener / event, another analysis shows which (type of) listener can attach to which

(type of) jcomponent. It leaves out the 3rd vital element — the (type of) event. The relationship of the 3 entities is central to


An AWTEvent is an object containing data about some “happening”. It also “contians” a source jcomponent via getSource(). Another

important content is the type of event — mouse move, resizing, checkbox click…via getID(). An event usually comes from a

jcomponent — both user actions and code actions generate events.

When generated, the event doesn't “know” the listeners — similar to how a MOM sender generates an “unaddressed” message. Instead,

the “source” jcomponent keeps the (list of) listeners.

I sometimes prefer to discuss in terms of event-queue task (qtask) rather than events. A qtask is an event + a single listener

object. Now I feel this is educational but imprecise.

Recall a listener object is an initially stateless functor object + optional objects passed in to ctor + optional objects in the

enclosing class or enclosing method. The last group are more tricky.

Here's my hypothesis. When an event occurs,

Event object constructed

Event object euqueued

EDT picks up the event and invokes Component.processEvent(theEvent)

Inside processEvent(), each listener is invoked sequentially. described some of the details in a

MouseEvent.mouseClicked() example.

3 types of high-level external events – swing

An entire swing app is event driven – either 1) user events, 2) “mkt data” events, or (rarely) scheduled timer events. Without these events, entire swing app is idle.

Therefore, event handling logic permeates swing apps.

Actually “Mkt data” event is a misnomer since it can be any external data from MOM, from database response, from loading a file, from RMI response, from a web service response…

These 3 types of external events are not AWTEvents, but “happenings”. They can generate internal events, typically AWTEvents. For example, if a user event hits a JButton, the event handler in the button could fire an AWT event on a TableModel. The TableModel event handler can then modify table data and fire another event to update the screen.

Swing has a notion of low-level events vs semantic events. My 3 types are semantic.

swing propChangeListener: pass info between event generator/callback Methods

background — callback/event-handling/listener is one of the more interesting or tricky part of swing development.

Callback site can use EventObject.getSource() to find the generator Object (for a semantic event), cast to a specific type, then access its specific methods or fields. This requires prior knowledge of the exact data type of the event-generator object. That leads to tight-coupling.

A more generic solution is the This and related classes are part of java.beans package, not limited to swing. PCL is a flexible and practical solution in a wide variety of contexts beyond swing. holds (in addition to source) propertyKeyName, oldValue and newValue fields.
Any Listener class can implement the interface and support a single callback method — propertyChange(PropertyChangeEvent). When the callback runs, at run-time it has access to all 4 constituents of the PropertyChangeEvent instance.