“Any sufficiently advanced technology is indistinguishable from magic.” If you don’t know these technologies, you can’t imagine how some things are achievable.
* runtime code generation — cglib and proxies (since jdk 1.3)
* bytecode engineering
* threads in private inner classes
Q: in the web2.0 era, why use swing or any thick/fat client?
spreadsheet — (dozens of) Spreadsheet features. Just compare Excel against google docs.
fast, automatic screen update based on incoming messages
state — sophisticated state maintained inside client JVM.
threads — create multiple threads in client JVM, to do arbitrarily complex things.
DB — access database
Caching — large amount of database records locally.
access ejb, rmi, webservices
disk — access local hard disk
call OS commands or run any executable
MOM — multiple MOM listeners
precise control of real estate — squeezing in the maximum amount of info in a window.
jtable sort, edit, delete, column-move using client (save the server) CPU
Better utilization of client machine processing power.
visual rendering using client machine’s CPU
drag and drop
fully customizable keyboard shortcuts
movable split pane
See also http://bigblog.tanbin.com/2011/02/swing-server-communication-for-wall-st.html
1) MOM – server ==> swing? Best example is market data and trade blotter
2) MOM – swing ==> server? Good for some non-urgent updates originated on UI. How about the server response?
2a) perhaps UI doesn’t care about the response
2b) In Neo, the WPF client sends a message to server and returns. A separate onMsg() thread waits for the server response.
Some user operations must use a synchronous call (like EJB or web service) rather than MOM —
3) separate swing thread to call server and then update UI (by publishing to event queue, or invokeLater)
4) action listener running on EDT makes a synchronous blocking call to server, making the UI temporarily non-responsive.
What if server pushes data to swing but needs some client response? I feel this is less common. Swing could run an RMI server and MOM listener. I feel MOM is better.
background — req/rep is indispensable in trading as it replaces synchronous call.
I feel the scheme below is overly complex.
Note “server” is an vague term in req/rep. I use “broker” and “service” instead.
* Initiator sends request to message broker.
* broker delivers it to the service provider. I feel async allows an overloaded service to control message rate. Sync could overwhelm the service.
* depending on the acknowledgment mode, service might send an REQ-ACK right away, since the reply might take a long time. REQ-ACK can give initiator some useful assurance so it doesn’t need to guess “why no reply?”.
* x seconds/hours later, service sends the “value” to a private queue (initiator’s mailbox).
* broker delivers it to the initiator, async or sync. See post on initiator’s mailbox.
* depending on the acknowledgment mode, initiator might send a VALUE-ACK.
Generalized, request vs value can be considered 2 independent JMS flows. Perhaps 2 independent brokers, 2 independent queues. Zed used this model as the ringtone/joke/horoscope/…. might get generated after a long delay. If the request is a write operation, then more control is needed.
 Further decoupled, an explicit, custom ACK message can go into yet another queue. So the request/reply would use 4 queues. However, i think this is rare. ACK could be a builtin in the broker infrastructure, but perhaps the actual receivers (initiator and server) can issue the ACK.
In a c# method, unlike all other statements the yield statements are not a sequence of instructions. Instead, they form a declarative specification of an iterator. In a sense they have something in common with the annotations/attributes in source code?
In fact, there is no method per se. The entire yield-block is a declarative “iterator block”.
(How about the “using” statement (not the directive)? I feel it still maps to a sequence of instructions.)
See link — covers serialization in RMI.
* serialization = writing a *graph* of objects into a stream of data
* How to Make a Class Serializable
1. Implement the Serializable interface.
2. Make sure that instance-level, locally defined state is serialized properly.
3. Make sure that superclass state is serialized properly.
4. Override equals( ) and hashCode( ).
Making a class serializable rarely involves significant changes to its functionality and shouldn’t result in any changes to method implementations. This means that it’s fairly easy to retrofit serialization onto an existing object hierarchy. The hardest part is usually implementing equals( ) and hashCode( ).
on (2) above, i personally try to compose my objects with primitives, strings and simple arrays. What if there’s a map field? I guess i have to customize its serialization.
The tibrv documentation [[RV concepts]] (https://docs.tibco.com/pub/rendezvous/8.3.1_january_2011/pdf/tib_rv_concepts.pdf) has good examples of when to use Certified Messaging. (minor edits by me)
Certified delivery is appropriate when a sending program requires individual confirmation of delivery for each message it sends. For example, a traveling sales representative enters sales orders on a laptop computer, and sends them to a central office. The representative must know for certain that the order processing system has received the order he sent.
Certified delivery is also appropriate when a receiving program cannot afford to miss any messages. For example, in an application that processes orders to buy and sell inventory items, each order is important. If any orders are omitted, then inventory records are incorrect. It’s like missing a incremental backup.
Certified delivery is appropriate when each message on a subject builds upon previous message (with that subject) — in sequence. For example, a sending program updates a receiving database, contributing part of the data fields in a record, but leaving other fields of the record unchanged. The database is correct only if all updates arrive in the order they are sent.
Certified delivery is appropriate in situations of intermittent physical connectivity—such as discontinuous network connections. For example, consider an application in which several mobile laptop computers must communicate with one another. Connectivity between mobile units is sporadic, requiring persistent storage of messages until the appropriate connections are re-established.
Everything is “over UDP”. See P 19 of [[ RV concepts ]]
TRDP broadcast or multicast protocol over UDP channel
TRDP unicast protocol over UDP channel
–Direct Communication (RV Version 7)
RPTP over UDP channel
Put-call parity equates buy-write to selling puts (naked puts), but there are many differences glossed over.
Background — Buy-write means buying underlier and selling calls. Put-call parity shows the resulting expiration PnL graph resembles a short put position. All the trades reference the same amount of underlier asset, and identical strikes. Note the hockey stick PnL graph is an Expiration snapshot of a RangeOfPossibilities — see other blog posts.
Diff — many (at least for retail investors) BW happens on option exchanges, which are usually American style so no PCP. Notable exception — a few listed index options are European style.
Diff — cash outlay — usually 10 times or higher for BW, because you must pay (at least half) the full cash price for underlier. To short sell a put you probably can get away with lower margin. See p89 [[the math of option trading]] for real examples.
Diff — moneyness — typical BW uses an OTM calls (though ITM is common too). The corresponding (same strike) short puts are ITM.
Diff — recurring income — to the BW trader, but only if she’s consistently lucky that her calls sold always expires OTM.
Diff — BW can make you lose the best stocks in your portfolio if you do that habitually. No such side effect with short puts, because once you get burned you stop playing with fire.
Diff — after expiry — you end up with no position and no risk if using naked puts. With BW, you may still hold large risk, large profit potential and large exposure.
Diff — To execute a buy-write, you would need to overcome 2 bid-ask spreads.
Diff — To execute a buy-write, you would pay 2 commissions.
#1) c++ performs shallow copy at
* pbclone and
Java performs copying only using the clone() method. By default, java methods and assignments copy addresses, never copy objects.
c# IClonable is controversial so let’s remember 1 key concern — ambiguity about deep or shallow clone