今天拿到一個新鍵盤，真夠有趣的,
中文鍵盤，好些鍵上面除了英文名，還有中文翻譯，
比如Esc上面寫推出，Tab上面寫制表，Ctrl寫控制，
Shift寫上檔，Alt是換檔，Backspace是回格，哈哈，真夠好玩的 現在好像每個網站都有blog服務了拉,如雨后春筍一般.
推論一,一個推論，任何東西過多，最后的贏家都是搜索引擎
推論二,web1.0的時代是搜索引擎和網站雙贏，那么web2.0時代就是搜索引擎和blogger雙贏(當然還有BSP) 試了一下，發現當結果網頁帶錯誤javascript的時候，httpunit就支持報錯，
而jwebunit是對httpunit的封裝，當然也通不過。
再試了htmlunit,也是一樣報錯，
看來只能用apache的httpclient了

People often criticize asynchronous messaging solutions as too complicated and cumbersome. Or, they believe distributed solutions cannot be successful unless they include a distributed transaction model. There is little doubt that asynchronous solutions require us to think in new ways as we have to deal with concurrency, out-of-sequence issues, correlation and other. However, the real world is full of examples of asynchronous processes that successfully with exactly the same issues. We don't have to go further than the local coffee shop...

Hotto Cocoa o Kudasai

I just returned from a 2 week trip to Japan. One of the more familiar sights was the ridiculous number of Starbucks (???????) coffee shops, especially around Shinjuku and Roppongi. While waiting for my "Hotto Cocoa" I started to think about how Starbucks processes drink orders. Starbucks, like most other businesses is primarily interested in maximizing throughput of orders. More orders equals more revenue. As a result they use asynchronous processing. When you place your order the cashier marks a coffee cup with your order and places it into the queue. The queue is quite literally a queue of coffee cups lined up on top of the espresso machine. This queue decouples cashier and barista and allows the cashier to keep taking orders even if the barista is backed up for a moment. It allows them to deploy multiple baristas in a Competing Consumer scenario if the store gets busy.

Correlation

By taking advantage of an asynchronous approach Starbucks also has to deal with the same challenges that asynchrony inherently brings. Take for example, correlation. Drink orders are not necessarily completed in the order they were placed. This can happen for two reasons. First, multiple baristas may be processing orders using different equipment. Blended drinks may take longer than a drip coffee. Second, baristas may make multiple drinks in one batch to optimize processing time. As a result, Starbucks has a correlation problem. Drinks are delivered out of sequence and need to be matched up to the correct customer. Starbucks solves the problem with the same "pattern" we use in messaging architectures -- they use a Correlation Identifier. In the US, most Starbucks use an explicit correlation identifier by writing your name on the cup and calling it out when the drink is complete. In other countries, you have to correlate by the type of drink.

Exception Handling

Exception handling in asynchronous messaging scenarios can be difficult. If the real world writes the best stories maybe we can learn something by watching how Starbucks deals with exceptions. What do they do if you can't pay? They will toss the drink if it has already been made or otherwise pull your cup from the "queue". If they deliver you a drink that is incorrect or nonsatisfactory they will remake it. If the machine breaks down and they cannot make your drink they will refund your money. Each of these scenarios describes a different, but common error handling strategy:

• Write-off - This error handling strategy is the simplest of all: do nothing. Or discard what you have done. This might seem like a bad plan but in the reality of business this option might be acceptable. If the loss is small it might be more expensive to build an error correction solution than to just let things be. For example, I worked for a number of ISP providers who would chose this approach when there was an error in the billing / provisioning cycle. As a result, a customer might end up with active service but would not get billed. The revenue loss was small enough to allow the business to operate in this way. Periodically, they would run reconciliation reports to detect the "free" accounts and close them.
• Retry - When some operations of a larger group (i.e. "transaction") fail, we have essentially two choices: undo the ones that are already done or retry the ones that failed. Retry is a plausible option if there is a realistic chance that the retry will actually succeed. For example, if a business rule is violated it is unlikely a retry will succeed. However, if an external system is not available a retry might well be successful. A special case is a retry with Idempotent Receiver. In this case we can simply retry all operations since the successful receivers will ignore duplicate messages.
• Compensating Action - The last option is to undo operations that were already completed to put the system back into a consistent state. Such "compensating actions" work well for example if we deal with monetary systems where we can recredit money that has been debited.

All of these strategies are different than a two-phase commit that relies on separate prepare and execute steps. In the Starbucks example, a two-phase commit would equate to waiting at the cashier with the receipt and the money on the table until the drink is finished. Then, the drink would be added to the mix. Finally the money, receipt and drink would change hands in one swoop. Neither the cashier nor the customer would be able to leave until the "transaction" is completed. Using such a two-phase-commit approach would certainly kill Starbucks' business because the number of customers they can serve within a certain time interval would decrease dramatically. This is a good reminder that a two-phase-commit is can make life a lot simpler but it can also hurt the free flow of messages (and therefore the scalability) because it has to maintain stateful transaction resources across the flow of multiple, asynchronous actions.

Conversations

The coffee shop interaction is also a good example of a simple, but common Conversation pattern. The interaction between two parties (customer and coffee shop) consists of a short synchronous interaction (ordering and paying) and a longer, asynchronous interaction (making and receiving the drink). This type of conversation is quite common in purchasing scenarios. For example, when placing an order on Amazon the short synchronous interaction assigns an order number and all subsequent steps (charging credit card, packaging, shipping) are done asynchronously. You are notified via e-mail (asynchronous) when the additional steps complete. If anything goes wrong, Amazon usually compensates (refund to credit card) or retries (resend lost goods).

In summary we can see that the real world is often asynchronous. Our daily lives consists of many coordinated, but asynchronous interactions (reading and replying to e-mail, buying coffee etc). This means that an asynchronous messaging architecture can often be a natural way to model these types of interactions. It also means that often we can look at daily life to help design successful messaging solutions. Domo arigato gozaimasu!

---

About the author

Gregor Hohpe
Blog: http://www.enterpriseintegrationpatterns.com/ramblings.html

Gregor Hohpe leads the Enterprise Integration practice at ThoughtWorks, Inc., a specialized provider of application development and integration services. Gregor is a widely recognized thought leader on asynchronous messaging architectures and co-author of the seminal book "Enterprise Integration Patterns" (Addison-Wesley, 2004). Gregor speaks regularly at technical conferences around the world and maintains the Web site www.eaipatterns.com.
(from http://www.theserverside.net/blogs/showblog.tss?id=TwoPhaseCommit)
看完之后，第一就是佩服的作者的水平
第二就是對Enterprise Integration patterns這本書產生了興趣

Web 2.0 的課什么時候開呀?

微軟也是創新的。關于創新，它一直在微軟的血液里面。微軟內部的達爾文主義（物競天擇，適者生存），從Windows 95時代到現在，從來都沒有改變過。邁克爾-德拉蒙德所寫的《微軟帝國叛逆》就講述了OpenGL組里三個工程是堅持認為世界上有比OpenGL更適合Windows系統的圖形引擎,于是掀起了微軟內部的戰爭，秘密開發DirectX引擎。戰爭最終以更多的內部的部門采用更快更簡單得DirectX而不是OpenGL，并使OpenGL組最終轉變成為DirectX組而告終。這內部的種種創新的故事，已經有很多本書的記述了。
（來源于王建碩的blog) 管理員，沒找到怎么用trackback阿？ http://gzkou.blogdriver.com/gzkou/1034494.html#comment
其實很多功能吧，發明的人一開始并不一定都想到的，
比如一些軍用發明轉民用，你會驚訝的發現，
你的用戶會采用一些你意想不到的方式使用你的系統 http://mt.bookiesky.com/archives/vagabond/2005/10/googleececioeeo.html

  Google給每位工程師20%的自由支配時間。在私人時間里，大家反而創意勃發；誕
生了Gmail郵箱產品和人際網絡產品Orkut

  
  嗯，20%的自由支配時間,真的很吸引人，google就是google,確有獨到之處。
事實上，人在比較free比較自由的時候，確實容易創意勃發，萌生很多想法
  比如我的一些創意想法，就像下面這個曾經在論壇上發表過的想法
google 20%的空余時間可以給世界 創造很有創意的想法  比如我現在覺得，電腦上的字典就很不好用，查一個單詞，還就給出 文字解釋，真是太原始了，應該充分發揮電腦的多媒體優勢， 在解釋一個單詞就給出圖片或者相關動畫，就像小孩子學單詞一樣，由本能 figure out what the word means. 不要文字，或者只在需要時再給出文字解釋。

  還有以前發表的java應該動態化，POHP(Plain Old Html Page)，都是在一些比較閑適，
比較隨意的時候，突然想法蹦到腦子里頭來的。

山德勒銷售研究所(Sandler Sales Institute)曾作過關于推薦人如何影響銷售環節的研究，他們的結論如下：
●電話銷售的成功率只有1%~5%
●如果告訴客戶推件人姓名的話，銷售成功率為15%左右
●如果推薦人能給你的客戶打電話或發送電子郵件的話，銷售成功率就上升到50%
●如果推薦人能出現在你和客戶的會面或電話交談中，那么銷售的成功率就飆升至70%多，甚至超過80%



找工作也是類似的，呵呵，所以人脈很重要，呵呵