想看點(diǎn)關(guān)于cluster的理論教材的,
看到Distributed Systems Concepts And Design,
而且書評(píng)也不錯(cuò)，于是就買了.
沒想到講了一堆什么TCP/IP,ATM, 路由，轉(zhuǎn)換之類的,都是
我不感興趣的內(nèi)容,好無聊嘎.雖然好像有章節(jié)講到cluster,
不過貌似在很后面和后面的樣子,要經(jīng)過好多無聊的章節(jié):(

放下書后又看了一下頁(yè)數(shù),天:(,800多頁(yè),那么每一章節(jié)都要是
又臭又長(zhǎng)，有許多boring的內(nèi)容了..
還有抱怨一句，可能是由于影印版的關(guān)系，里頭的每節(jié)的heading,
以及圖里頭的一些塊的顏色，都是淺色，根本看不清楚。我想原書
這些應(yīng)該是來強(qiáng)調(diào)的吧，不過被影印了之后，反倒
需要更加費(fèi)力的看，根本達(dá)不到強(qiáng)調(diào)的效果了。

另,可憐的blogdriver為什么上不去了,一連就成tomcat的默認(rèn)頁(yè)面樣子?..

以前用過一次Norton Goback,整個(gè)恢復(fù)時(shí)間持續(xù)兩小時(shí),太慢了，要比Norton Ghost的恢復(fù)麻煩多了.
昨天機(jī)器慢，又想重裝,發(fā)現(xiàn)可以restore的時(shí)間點(diǎn)就剩下最近的兩個(gè)了，之前的都沒有了，
我的天，那不是沒有用么.
本來Norton Ghost,一個(gè)光驅(qū)+win98安裝盤就是一個(gè)完美的備份恢復(fù)解決方案，可惜的是
公司沒有光驅(qū)，導(dǎo)致這種方案不能用。
另外一種方案就是一個(gè)盤上裝上主操作系統(tǒng)如winxp,另一個(gè)盤裝上win98,雙啟動(dòng)，
然后可以用win98進(jìn)來作恢復(fù)。這種就是針對(duì)沒光驅(qū)的恢復(fù)方案，不過需要一開始
裝系統(tǒng)的時(shí)候就裝成這樣。 explorer /select, $FilePath$ (from webwork in action).webwork in action的源代碼建立了crudStack簡(jiǎn)化crud編程,
而書中也提到了如何建立直接從ide跑resin.

Alternatively, you can set up a Servlet container’s main method to be executed
directly like any other application and pass it the configuration information it
needs to automatically pick up your web application. For example, to set up
Resin 2.1 from Caucho (www.caucho.com) as a standalone application pointing
to a project-specific configuration file, you would set parameters as follows:
Setting up your environment 387
■ Main class—com.caucho.server.http.HttpServer
■ VM parameters—-Dresin.home=. -Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=12345
■ Program parameters—-conf resin.xml
■ Working directory—Root directory of your project
■ Classpath—Classpath of your project plus the Resin JARs www.dontclick.it
Dontclick.it explores a clickfree environment. It wants to explore how and what
changes for the user and the interface once you can't rely on the habit of clicking.
An experimental interface by LXFX 這幾天開始看薩姆爾森的經(jīng)濟(jì)學(xué)，看到市場(chǎng)經(jīng)濟(jì) vs 指令經(jīng)濟(jì)一節(jié)，呵呵，
比對(duì)碰到的iask情況和國(guó)內(nèi)wiki情況,剛好胡言亂語(yǔ)一番。
iask就類似與市場(chǎng)經(jīng)濟(jì)一般，用分?jǐn)?shù)來鼓勵(lì)人們回答問題，在這種利益的驅(qū)策下，
用戶自然會(huì)積極回答問題，貢獻(xiàn)自己的智慧，所以iask實(shí)際上也是在被一個(gè)'看不見的手'
所驅(qū)動(dòng)，由人們自己的利己心而達(dá)到的一個(gè)平衡。
反觀國(guó)內(nèi)wiki現(xiàn)狀，大多發(fā)展不起來，不像國(guó)外，概因國(guó)人的利己心還相對(duì)過于嚴(yán)重，
往往懶得無私貢獻(xiàn)力量，這樣的話，僅靠少數(shù)無私的人，是很難撐起一個(gè)社區(qū)性質(zhì)的平臺(tái)的，
所以國(guó)內(nèi)wiki往往發(fā)展不起來。即便如javaeye的doc工程，也是發(fā)展緩慢，難見后效。
偶爾跑書店，隨便瞅瞅，左一看右一看的，看到那本書吸引了注意，
就隨手拿起翻翻，諸多因素，比方書的頁(yè)面，書的書名，書的位置，
書的內(nèi)容，自己的心情等等，都可能導(dǎo)致選擇一本書或者不選擇一本書。于是每每有一些隨機(jī)的收獲。

家里的藏書，每為通過各種方式買了回來，放在家里，有些買了就看，有些買了卻又不立即看，
僅是放在家里。偶爾有機(jī)會(huì)瞄見引起興致，說不定又拿起來看了，就象在書店
由于某種偶然因素導(dǎo)致隨機(jī)拿起一本書似的。

前面瞥見半年前買的<獵頭>（中國(guó)第一本系統(tǒng)揭示獵頭行業(yè)的書）,
這是半年前買的,買回來就放下了，半年之前買了沒看，半年之來也跟不少獵頭打了交道，偶然瞥見家里有這本書，隨便拿起翻翻，挺感興趣。于是決定開始閱讀了，呵呵。

家書店，隨機(jī)閱讀,呵呵.




發(fā)現(xiàn)hibernate source里頭的log配置，記下來，說不定有用呵呵
http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/etc/log4j.properties?rev=1.7

### direct log messages to stdout ###
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

### direct messages to file hibernate.log ###
#log4j.appender.file=org.apache.log4j.FileAppender
#log4j.appender.file.File=hibernate.log
#log4j.appender.file.layout=org.apache.log4j.PatternLayout
#log4j.appender.file.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

### set log levels - for more verbose logging change 'info' to 'debug' ###

log4j.rootLogger=warn, stdout

log4j.logger.org.hibernate=info
#log4j.logger.org.hibernate=debug

### log HQL query parser activity
#log4j.logger.org.hibernate.hql.ast.AST=debug

### log just the SQL
#log4j.logger.org.hibernate.SQL=debug

### log JDBC bind parameters ###
log4j.logger.org.hibernate.type=info
#log4j.logger.org.hibernate.type=debug

### log schema export/update ###
log4j.logger.org.hibernate.tool.hbm2ddl=debug

### log HQL parse trees
#log4j.logger.org.hibernate.hql=debug

### log cache activity ###
#log4j.logger.org.hibernate.cache=debug

### log transaction activity
#log4j.logger.org.hibernate.transaction=debug

### log JDBC resource acquisition
#log4j.logger.org.hibernate.jdbc=debug

### enable the following line if you want to track down connection ###
### leakages when using DriverManagerConnectionProvider ###
#log4j.logger.org.hibernate.connection.DriverManagerConnectionProvider=trace

原來用Newzcrawler訂閱blog的，好用是好用，但是一換機(jī)器，就啥都沒有了。
bloglines稍微試了一下，還不太習(xí)慣，而且因?yàn)槭莣eb程序，
點(diǎn)起來不能馬上有反應(yīng)，不是很舒服.

so謹(jǐn)以本貼紀(jì)錄一些好的blog,免得再度丟了..
http://jroller.com/page/RickHigh/home


ps:各位同志有什么好的方法么？
我覺得理想的應(yīng)用應(yīng)該是免安裝的，換一臺(tái)機(jī)器也能用的，
另外最好多人之間可以共享一些好的訂閱的，像這樣子的應(yīng)用.

Updated:試了幾個(gè)在線的blogReader,
bloglines難看，reader.google.com難用，幾個(gè)blog都混在一起了，
最后還是live.com好用，而且界面也漂亮，只是blog下面沒有分類，這個(gè)以后訂閱多了
不太方便。
強(qiáng),寒一個(gè)... 今天拿到一個(gè)新鍵盤，真夠有趣的,
中文鍵盤，好些鍵上面除了英文名，還有中文翻譯，
比如Esc上面寫推出，Tab上面寫制表，Ctrl寫控制，
Shift寫上檔，Alt是換檔，Backspace是回格，哈哈，真夠好玩的 現(xiàn)在好像每個(gè)網(wǎng)站都有blog服務(wù)了拉,如雨后春筍一般.
推論一,一個(gè)推論，任何東西過多，最后的贏家都是搜索引擎
推論二,web1.0的時(shí)代是搜索引擎和網(wǎng)站雙贏，那么web2.0時(shí)代就是搜索引擎和blogger雙贏(當(dāng)然還有BSP) 試了一下，發(fā)現(xiàn)當(dāng)結(jié)果網(wǎng)頁(yè)帶錯(cuò)誤javascript的時(shí)候，httpunit就支持報(bào)錯(cuò)，
而jwebunit是對(duì)httpunit的封裝，當(dāng)然也通不過。
再試了htmlunit,也是一樣報(bào)錯(cuò)，
看來只能用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)
看完之后，第一就是佩服的作者的水平
第二就是對(duì)Enterprise Integration patterns這本書產(chǎn)生了興趣

Web 2.0 的課什么時(shí)候開呀?

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