想看点关于cluster的理论教材的,
看到Distributed Systems Concepts And Design,
而且书评也不错，于是就买了.
没想到讲了一堆什么TCP/IP,ATM, 路由，转换之类的,都是
我不感兴趣的内容,好无聊嘎.虽然好像有章节讲到cluster,
不过貌似在很后面和后面的样子,要经过好多无聊的章节:(

放下书后又看了一下页数,天:(,800多页,那么每一章节都要是
又臭又长，有许多boring的内容了..
还有抱怨一句，可能是由于影印版的关系，里头的每节的heading,
以及图里头的一些块的颜色，都是浅色，根本看不清楚。我想原书
这些应该是来强调的吧，不过被影印了之后，反倒
需要更加费力的看，根本达不到强调的效果了。

另,可怜的blogdriver为什么上不去了,一连就成tomcat的默认页面样子?..

以前用过一次Norton Goback,整个恢复时间持续两小时,太慢了，要比Norton Ghost的恢复麻烦多了.
昨天机器慢，又想重装,发现可以restore的时间点就剩下最近的两个了，之前的都没有了，
我的天，那不是没有用么.
本来Norton Ghost,一个光驱+win98安装盘就是一个完美的备份恢复解决方案，可惜的是
公司没有光驱，导致这种方案不能用。
另外一种方案就是一个盘上装上主操作系统如winxp,另一个盘装上win98,双启动，
然后可以用win98进来作恢复。这种就是针对没光驱的恢复方案，不过需要一开始
装系统的时候就装成这样。 explorer /select, $FilePath$ (from webwork in action).webwork in action的源代码建立了crudStack简化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 这几天开始看萨姆尔森的经济学，看到市场经济 vs 指令经济一节，呵呵，
比对碰到的iask情况和国内wiki情况,刚好胡言乱语一番。
iask就类似与市场经济一般，用分数来鼓励人们回答问题，在这种利益的驱策下，
用户自然会积极回答问题，贡献自己的智慧，所以iask实际上也是在被一个'看不见的手'
所驱动，由人们自己的利己心而达到的一个平衡。
反观国内wiki现状，大多发展不起来，不像国外，概因国人的利己心还相对过于严重，
往往懒得无私贡献力量，这样的话，仅靠少数无私的人，是很难撑起一个社区性质的平台的，
所以国内wiki往往发展不起来。即便如javaeye的doc工程，也是发展缓慢，难见后效。
偶尔跑书店，随便瞅瞅，左一看右一看的，看到那本书吸引了注意，
就随手拿起翻翻，诸多因素，比方书的页面，书的书名，书的位置，
书的内容，自己的心情等等，都可能导致选择一本书或者不选择一本书。于是每每有一些随机的收获。

家里的藏书，每为通过各种方式买了回来，放在家里，有些买了就看，有些买了却又不立即看，
仅是放在家里。偶尔有机会瞄见引起兴致，说不定又拿起来看了，就象在书店
由于某种偶然因素导致随机拿起一本书似的。

前面瞥见半年前买的<猎头>（中国第一本系统揭示猎头行业的书）,
这是半年前买的,买回来就放下了，半年之前买了没看，半年之来也跟不少猎头打了交道，偶然瞥见家里有这本书，随便拿起翻翻，挺感兴趣。于是决定开始阅读了，呵呵。

家书店，随机阅读,呵呵.




发现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的，好用是好用，但是一换机器，就啥都没有了。
bloglines稍微试了一下，还不太习惯，而且因为是web程序，
点起来不能马上有反应，不是很舒服.

so谨以本贴纪录一些好的blog,免得再度丢了..
http://jroller.com/page/RickHigh/home


ps:各位同志有什么好的方法么？
我觉得理想的应用应该是免安装的，换一台机器也能用的，
另外最好多人之间可以共享一些好的订阅的，像这样子的应用.

Updated:试了几个在线的blogReader,
bloglines难看，reader.google.com难用，几个blog都混在一起了，
最后还是live.com好用，而且界面也漂亮，只是blog下面没有分类，这个以后订阅多了
不太方便。 http://www.start.com.my/blog/finding_warez_using_google

这个连接是个老外写的，教别人如何用google china来搜索盗版软件，比如输入"flash 正式完整版"，中间还教他们学习中文字....

强,寒一个... 今天拿到一个新键盘，真够有趣的,
中文键盘，好些键上面除了英文名，还有中文翻译，
比如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%



找工作也是类似的，呵呵，所以人脉很重要，呵呵

首页充满了技术的教学文章，看多了是不是会有点审美疲劳呢，呵呵，我来推荐超越技术之外的一些东西。
第一个就是joel on software,获得jolt震撼大奖的，joel的水平可谓一流，书中充满了睿智的想法和有趣的言论，绝对值的一读，关于书的读法，我并不是顺序读取的，而是按照感兴趣的来，你们也可以像我一样，
先看看介绍或者amazon上的书评，读取感兴趣的部分。有些章节绝对值得一看，比如冰川下的秘密，漏洞抽象定律(leaky abstraction),看完了会让你对软件开发有更深邃的思考。我希望推荐的是joel的文章和joel的风格。

第二个是2本书，
<User Interface Design for programmers>，讲User Interface Design的，头一条原则，研究表明，用户的frustration是add up的，而不管每一个造成frustration的原因多大或多小，只是感受最重要，所以软件应该尽可能的减少frustration,符合用户的expectation.
<Don't Make me think> 讲Web Usability的，头一条rule就是Don't Make me think,也就是说，页面的大部分应该用户一看即懂。
User Interface Design和Web Usability这两个话题其实focus基本一样，主要都是围绕如何设计出更好的让用户使用的软件，这两本书可以结合着看，观点互相补充，互相印证。

blog搬家，应江南白衣之邀，从http://femto.blogdriver.com搬过来
之前的那些贴子可以察看blogdriver