|
|
2005年10月30日
blog也搬遷了：http://blog.sina.com.cn/liuwendao
來(lái)武漢快三年了，留在北京的最后一件物件-電吉它，也被我拿到武漢來(lái)了
我們這么混，能成功嗎？
立帖為證
軍事演習(xí)區(qū)，一位婦女駕車在大橋前被一名軍官攔住：“對(duì)不起，公民，您現(xiàn)在不能過(guò)去。”“為什么？”“這座橋在一小時(shí)前被炸毀了。”“您能告訴我這究竟是怎么回事嗎？”“很抱歉，不行。我本人已于2小時(shí)前陣亡。”
伊萬(wàn)看電視，是勃在演講。伊萬(wàn)覺(jué)得無(wú)聊，換了一個(gè)，還是勃在演講，又換一個(gè)，還是他。伊萬(wàn)一連撥了幾十個(gè)臺(tái)，最后累了，準(zhǔn)備關(guān)電視。這時(shí)候電視畫(huà)面變成一個(gè)KGB，怒氣沖沖地叫：“你再敢換？再敢換？再換判你10年大牢！”
某日蘇聯(lián)舉行國(guó)慶**，沿著大街開(kāi)來(lái)了炮兵、機(jī)械化步兵、坦克、自行火炮、戰(zhàn)術(shù)導(dǎo)彈、戰(zhàn)略核導(dǎo)彈，破壞力一個(gè)比一個(gè)大；隊(duì)列末尾卻是兩個(gè)帶公文包的矮子。在看臺(tái)上勃列日涅夫驚訝地說(shuō)：“這兩個(gè)人破壞力比核導(dǎo)彈還大！他們是什么人？”
KGB頭子說(shuō)：“不是我的人。”
國(guó)防部長(zhǎng)說(shuō)：“沒(méi)見(jiàn)過(guò)他們。”
蘇聯(lián)總理說(shuō)：“他們是國(guó)家計(jì)委的...”
戈?duì)柊蛦谭蛞暡燹r(nóng)場(chǎng)，看到豬兒乖乖，一時(shí)興起站在豬中間照了張像。
待到報(bào)紙準(zhǔn)備發(fā)表時(shí)，編輯為照片的標(biāo)題犯了難？？
“戈?duì)柊蛦谭蛲竞拓i在一起”不好。
“豬和戈?duì)柊蛦谭蛲驹谝黄稹币膊缓谩?
報(bào)紙出版后，照片下的說(shuō)明文字是？？
“左起第三位是戈?duì)柊蛦谭蛲尽?
勃列日涅夫和美國(guó)總統(tǒng)卡特在瑞士開(kāi)會(huì)，休息時(shí)間兩個(gè)人很無(wú)聊，就開(kāi)始比誰(shuí)的保膘更忠誠(chéng)。卡特先來(lái)，他把自己的報(bào)膘叫進(jìn)來(lái)，推開(kāi)窗（外面是20層樓）說(shuō)：“約翰，從這里跳下去！”
約翰哭著說(shuō)：“你著么能這樣呢，總統(tǒng)先生，我還有老婆孩子吶。”
卡特被感動(dòng)了，流著淚說(shuō)是自己不對(duì)，叫約翰走了，然后掄到勃列日涅夫，他也大聲叫自己的保膘伊萬(wàn)。
“伊萬(wàn)，從這里跳下去！”
伊萬(wàn)二話不說(shuō)就要往下跳，卡特一把抱住他說(shuō)：“你瘋了？跳下去會(huì)死的！”
伊萬(wàn)一邊掙扎著要跳下去一邊說(shuō)：“放開(kāi)我，混蛋，我還有老婆孩子吶。”
早年莫斯科修地鐵，工程師將方案上報(bào)斯大林審批。不久，方案發(fā)下來(lái)，上面有斯大林的簽字。
細(xì)心的工程師發(fā)現(xiàn)圖紙上多了一個(gè)圓型的茶杯印，于是莫斯科地鐵就多了一條環(huán)形線。
斯大林肅反時(shí)期的蘇聯(lián)。一位內(nèi)務(wù)人民委員部審判員結(jié)束一天的審判工作，回到辦公室，突然一個(gè)人大笑起來(lái)。對(duì)面辦公桌的同事奇怪的問(wèn)道：“有什么好笑的事嗎？”“是啊，”審判員用手帕擦著笑出來(lái)的眼淚：“一個(gè)很好笑的笑話……”“哦？說(shuō)來(lái)聽(tīng)聽(tīng)？”“你瘋了嗎？！我剛判了說(shuō)這笑話的家伙五年苦役！”
蘇聯(lián)30年代肅反擴(kuò)大化時(shí)期。內(nèi)務(wù)人民委員部的一間牢房里關(guān)了三個(gè)人，彼此間談起坐牢的原因。
第一個(gè)人說(shuō)，我因?yàn)榉磳?duì)了黨書(shū)記彼得羅夫；
第二個(gè)人說(shuō)，我因?yàn)橹С至吮说昧_夫；
第三個(gè)人說(shuō)，我就是彼得羅夫。
戈?duì)柊蛦谭蚝退乃緳C(jī)開(kāi)著車在路上，戈?duì)柊蛦谭蛲话l(fā)異想，說(shuō)：讓開(kāi)！我來(lái)開(kāi)。一個(gè)老警察和一個(gè)新警察在路上值勤，見(jiàn)一輛車歪歪扭扭的開(kāi)得瘋快，老警察就對(duì)新警察說(shuō)：去！好好收拾一下。新警察將車攔住之后，又沒(méi)趣沒(méi)趣地回來(lái)了。老警察問(wèn)：怎么？里面是誰(shuí)？新警察回答說(shuō)：我也不知道里面是誰(shuí)，反正給他開(kāi)車的是戈?duì)柊蛦谭颉?
美國(guó)外交代表團(tuán)到蘇聯(lián)訪問(wèn)，蘇聯(lián)接待官員陪他們參觀“建設(shè)的偉大成就”，并且得意的說(shuō)：“到了下一個(gè)五年計(jì)劃，每個(gè)蘇聯(lián)家庭都可以擁有一架私人飛機(jī)！”美國(guó)人驚訝的問(wèn)：“ 他們要飛機(jī)干什么呢？”蘇聯(lián)官員說(shuō)：“當(dāng)然有用啊……譬如你在莫斯科聽(tīng)說(shuō)列寧格勒開(kāi)始供應(yīng)面包了，你可以馬上開(kāi)著飛機(jī)趕去排上隊(duì)。”
一位公民打電話到基輔電臺(tái)問(wèn)主持人：“共產(chǎn)主義到底是藝術(shù)還是科學(xué)？” 主持人說(shuō)：“我也不清楚，但我肯定不是科學(xué)” “為什么？” “如果是科學(xué)的話，他們應(yīng)該拿狗做試驗(yàn)。”
斯大林在大會(huì)上引經(jīng)據(jù)典地說(shuō)：“馬克思和列寧說(shuō)1+1=2，而托洛茨基和布哈林說(shuō)1+1不等于3。是托洛茨基和布哈林說(shuō)的對(duì)呢？還是馬克思和列寧說(shuō)得對(duì)呢？”下面聽(tīng)眾一臉疑惑，“毫無(wú)疑問(wèn)，是馬克思和列寧說(shuō)的對(duì)！”底下熱烈鼓掌，“托洛茨基和布哈林是帝國(guó)主義派來(lái)的間諜，說(shuō)1+1不等于3的人罪不容赦……”
列寧快去世了，叫趕快把繼承人斯大林召進(jìn)克里姆林宮來(lái)，臨終有幾句話要囑托。“不瞞你說(shuō)，我還有一個(gè)隱憂啊，斯大林。”“說(shuō)吧，親愛(ài)的伊里奇。”斯大林專心地聽(tīng)著。“那就是，人們會(huì)跟你走嗎？不知你想過(guò)了沒(méi)有？”“他們一定會(huì)跟我走的。”斯大林強(qiáng)調(diào)說(shuō)，“一定會(huì)！” “但愿如此。”列寧說(shuō)，“我只是擔(dān)心，萬(wàn)一他們不跟你走，你怎么辦？”“沒(méi)問(wèn)題！”斯大林答道：“那他們就得跟你走！”
集體農(nóng)莊莊員伊萬(wàn)在河里捉到一條大魚(yú)，高興的回到家里和老婆說(shuō)：“看，我們有炸魚(yú)吃了！”
“沒(méi)有油啊。”
“那就煮！”
“沒(méi)鍋。”
“烤魚(yú)！”
“沒(méi)柴。”
伊萬(wàn)氣死了，走到河邊把魚(yú)扔了回去。那魚(yú)在水里劃了一個(gè)半圓，上身出水，舉起右鰭激動(dòng)地高呼：“斯大林萬(wàn)歲！”
“瑞典能否建立共產(chǎn)主義”？
“不能。”
“為何？”
“列寧同志說(shuō)了：共產(chǎn)主義不在山那邊。”
一個(gè)蘇聯(lián)KGB特工和一個(gè)美國(guó)CIA特工互相吹噓各自的機(jī)構(gòu)是如何的杰出。
那個(gè)KGB特工首先發(fā)言說(shuō)，“我們擁有你們美國(guó)過(guò)去15年里所有導(dǎo)彈發(fā)射的詳細(xì)數(shù)據(jù)。”
CIA特工說(shuō)：“這不算什么。我們CIA掌握著你們蘇聯(lián)未來(lái)15年里所有當(dāng)選的中央委員名單。”
一艘航行在大海上的輪船快要沉了，船長(zhǎng)叫乘客趕緊跳海，但他喊了半天沒(méi)有一個(gè)人跳，一個(gè)社會(huì)學(xué)家說(shuō)我來(lái)喊，他去喊過(guò)之后所有的人都跳下海去了。船長(zhǎng)覺(jué)得奇怪，問(wèn)他是怎么喊的，社會(huì)學(xué)家回答說(shuō)：我對(duì)法國(guó)人說(shuō)這樣跳下去很浪漫，我對(duì)西班牙人說(shuō)這樣跳下去很瀟灑，我對(duì)英國(guó)人說(shuō)這樣跳下去是一種體育運(yùn)動(dòng)，我對(duì)美國(guó)人說(shuō)這樣跳下去有利可圖，我對(duì)蘇聯(lián)人說(shuō)這樣跳下去是革命行動(dòng)。
在蘇聯(lián)的一趟公交車，一個(gè)男的非常謙恭地問(wèn)站在他身旁的另一個(gè)男的：“同志，請(qǐng)問(wèn)您是克格勃嗎？”
那人答道：“不是。”
又問(wèn)：“那您有沒(méi)有親戚或朋友是克格勃呢？”
答：“沒(méi)有。”
還問(wèn)：“那您是否跟克格勃有些交往或聯(lián)系？”
答：“沒(méi)有，你要干嘛啊！”
該男生氣地說(shuō)：“干嘛，他媽的，你踩著我的腳了！”
赫魯曉夫作報(bào)告，批判斯大林。忽然，有人從臺(tái)下遞了個(gè)紙條，寫(xiě)道：當(dāng)他做壞事的時(shí)候，你在哪里？赫魯曉夫一看這個(gè)條子，大聲怒喝道：“是誰(shuí)寫(xiě)的，給我站出來(lái)。”臺(tái)下雅雀無(wú)聲，沒(méi)有人站出來(lái)。赫魯曉夫接著說(shuō)道：“同志們，我當(dāng)時(shí)就和你們現(xiàn)在一樣，你們知道我當(dāng)時(shí)為什么不敢站出來(lái)了吧”
勃列日涅夫：同志們，美國(guó)人登上了月球，我們不能再等了，黨決定讓你們上太陽(yáng)。
宇航員：總書(shū)記同志，我們會(huì)被燒死的。
勃列日涅夫：沒(méi)關(guān)系，同志們，黨都替你們想好了，你們晚上去。
電影《這里的黎明靜悄悄》試映時(shí)，由于其中有部分裸體鏡頭，因此主管電影審核的官員曾試圖把這部電影禁演，幸虧勃列日涅夫內(nèi)部觀看時(shí)感動(dòng)得熱淚盈眶，這部?jī)?yōu)秀的電影才有幸與觀眾見(jiàn)面，成為世界電影史上不朽的篇章。而另一部電影由于其中有主人公走到教堂時(shí)跪地痛哭的鏡頭，被電影審核官員認(rèn)為是宣揚(yáng)宗教而準(zhǔn)備勒令裁掉這部分內(nèi)容，恰恰勃列日涅夫看到這里時(shí)動(dòng)了感情，因此這個(gè)鏡頭得以幸存下來(lái)。
當(dāng)年的捷克斯洛伐克政府中，設(shè)立了一個(gè)“海軍部”，結(jié)果，蘇聯(lián)老大哥就對(duì)捷克人說(shuō)：你們是內(nèi)陸國(guó)家，設(shè)什么海軍部？
捷克人回答說(shuō)：那你們不是也設(shè)了文化部嗎？
最近看到越來(lái)越多的人使用mina，甚至在線下也碰到合作公司的庫(kù)中使用MINA，出于好奇，嘗試一下用自己的blog做一下調(diào)查，訪問(wèn)本blog的兄弟，如果您使用MINA作為自己的通訊基礎(chǔ)件，請(qǐng)留言介紹一下自己
軟件開(kāi)發(fā)的世界里充滿了不理解， 客戶不理解軟件是怎樣開(kāi)發(fā)的、經(jīng)理不理解開(kāi)發(fā)人員、開(kāi)發(fā)人員不理解指揮者。問(wèn)題在于軟件開(kāi)發(fā)驚人的困難，造成很少有開(kāi)發(fā)人員能夠說(shuō)出軟件自始至終是怎樣開(kāi)發(fā)的，并能夠?qū)@個(gè)過(guò)程中會(huì)遇到的不同選擇所隱含的結(jié)果表現(xiàn)出適度的理解。 在軟件開(kāi)發(fā)人員還很年輕的時(shí)候（十幾歲或二十出頭），他們通常集中精力學(xué)習(xí)和使用技術(shù)，稱自己為perl程序員、Linux專家、EJB開(kāi)發(fā)人員、.NET開(kāi)發(fā)人員等。對(duì)他們來(lái)說(shuō)技術(shù)是最重要的事情。因?yàn)榧夹g(shù)在不斷的變化，年輕的程序員傾向于大致學(xué)習(xí)一個(gè)技術(shù)，在一到兩個(gè)項(xiàng)目中使用，然后重新開(kāi)始學(xué)習(xí)新技術(shù)或者是學(xué)習(xí)以前使用過(guò)的技術(shù)的最新發(fā)展。這里的問(wèn)題是，他們一遍又一遍的重復(fù)的學(xué)習(xí)的不過(guò)是同樣的低層次基本技能的不同風(fēng)味。 幸運(yùn)的是，很多開(kāi)發(fā)人員在經(jīng)過(guò)了幾輪技術(shù)學(xué)習(xí)之后逐漸意識(shí)到：一旦用COBOL、Java、C#等語(yǔ)言為事務(wù)控制編寫(xiě)過(guò)代碼，就會(huì)開(kāi)始認(rèn)識(shí)到基本的、本質(zhì)的東西是不變的。不同環(huán)境下的數(shù)據(jù)庫(kù)訪問(wèn)、用戶界面設(shè)計(jì)等領(lǐng)域也是同樣的情況。不久以后，開(kāi)發(fā)人員逐漸認(rèn)識(shí)到無(wú)論具體的技術(shù)怎樣，很多基礎(chǔ)性的東西是保持不變的，這些基礎(chǔ)性的東西有的在學(xué)校里講過(guò)，有的沒(méi)有。
這種認(rèn)識(shí)經(jīng)常發(fā)生在開(kāi)發(fā)人員接近三十歲或剛過(guò)三十歲的時(shí)候，通常是人們開(kāi)始穩(wěn)定下來(lái)，結(jié)婚、買(mǎi)房的時(shí)候。這是比較幸運(yùn)的情況，因?yàn)樯厦嫣岬降倪@些新的個(gè)人需求意味著他們不可能再投入大量的時(shí)間去學(xué)習(xí)新的技術(shù)，他們需要用這些時(shí)間和家庭成員在一起。突然的，高層次的角色如項(xiàng)目負(fù)責(zé)人、項(xiàng)目經(jīng)理、（非敏捷的）建模人員等對(duì)他們變得非常有吸引力，因?yàn)檫@些角色不需要持續(xù)花費(fèi)大量的時(shí)間和精力去學(xué)習(xí)新技術(shù)。于是，等到開(kāi)發(fā)人員開(kāi)始真正學(xué)到技藝的時(shí)候，他們已經(jīng)處于離開(kāi)開(kāi)發(fā)人員角色的轉(zhuǎn)變過(guò)程中了。所幸的是，新的“小年輕”不斷的跟上來(lái)，這個(gè)過(guò)程在不斷的循環(huán)重復(fù)。最終的結(jié)果是：大部分最活躍的正在開(kāi)發(fā)軟件的人通常不是最稱職的做這件事的人，而他們自己甚至還不知道。
來(lái)自pythoncn的maillist，呵呵，挺有意思
－－－－－－－－－－－－－
像Chris Qie <longroad1999@gmail.com>這樣的在公共論壇用侮辱性言語(yǔ)挑起罵戰(zhàn)并從中獲取某種不知名快感的人，在Usenet文化中有一個(gè)名稱：
-
Troll
。
- Troll作動(dòng)詞是釣魚(yú)的意思，指那些人發(fā)表某種言論后等待別人的攻擊性回復(fù)，從而獲得快感。Troll還有一個(gè)意思是斯堪的納維亞神話中一種長(zhǎng)相丑陋、愛(ài)惡作 劇、令人討厭的巨人，和那些找罵的人有相似之處，因此也被引申過(guò)來(lái)形容那些 人，做名詞使用。回troll的貼則被稱為feed the trolls，即給trolls喂食。
- Trolls有很多種，像Chris Qie只是其中一種，即使用種族歧視性語(yǔ)言激怒別人，好讓別人回帖罵他。comp.lang.python上著名的troll: Xah Lee則是長(zhǎng)年在各個(gè) script語(yǔ)言討論組上交叉張貼無(wú)關(guān)內(nèi)容或用錯(cuò)誤百出的話語(yǔ)對(duì)某種語(yǔ)言或者文化進(jìn) 行攻擊。但無(wú)論那種troll，他們的目的都是一樣的：想通過(guò)怪誕的舉動(dòng)引起別人 的注意。這是一種病態(tài)心理，是一種未成熟，類似小孩“人來(lái)瘋”似的舉動(dòng)。
- Trolls的存在對(duì)公共空間是破壞性的。它們的post會(huì)引起很多人回帖，甚至?xí)星榫w激動(dòng)者采用謾罵的方式回敬，這些人被稱為trollhunter。這些行為正中trolls 的下懷，使他們獲得被罵的快樂(lè)，從而更加積極的trolling。而且即使 trollhunter的動(dòng)機(jī)是好的，也會(huì)給論壇帶來(lái)不好影響，使其他用戶接收到大量無(wú) 關(guān)信息和攻擊性信息，成為受害者。公共空間的和諧性被破壞。
- Trolls最愿意看到別人回他的貼，無(wú)論是正兒八經(jīng)指出他的錯(cuò)誤還是義憤填膺的對(duì)他謾罵。對(duì)一個(gè)troll來(lái)說(shuō)，最能讓他感到沮喪的則是沒(méi)有人理他。而我們，正是 應(yīng)該讓他們沮喪，失去trolling的動(dòng)力。
- 對(duì)待trolls的方法，一方面要靠大家自覺(jué)，克制自己回帖的沖動(dòng)，不給他們喂食。
另一方面，在郵件列表這種有管理員的公共空間，可以向管理員提出封禁trolls的 提案。
- 下圖是我從c.l.python上Keith Thompson對(duì)Xah Lee的trolling行為提醒公眾的帖子中拷貝過(guò)來(lái)的圖片（請(qǐng)使用等寬字體觀看）
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/*-------------------------------------------
? 程序員的進(jìn)化——從學(xué)生到首席執(zhí)行官
翻譯 2002 王詠剛
http://www.contextfree.net/
轉(zhuǎn)譯自 Omri's Computer Humor Page
http://www.cs.bgu.ac.il/~omri/Humor/
-------------------------------------------*/
--------------------------------------------------------------------------------
中學(xué)階段
? ? ? 10 PRINT "HELLO WORLD"
? ? ? 20 END
--------------------------------------------------------------------------------
大學(xué)一年級(jí)
? ? ? program Hello(input, output)
? ? ? ? begin
? ? ? ? writeln('Hello World')
? ? ? ? end.
--------------------------------------------------------------------------------
大學(xué)高年級(jí)
? ? ? (defun hello
? ? ? ? (print
? ? ? ? (cons 'Hello (list 'World))))
--------------------------------------------------------------------------------
初級(jí)程序員
? ? ? #include <stdio.h>
? ? ? void main(void)
? ? ? {
? ? ? ? char *message[] = {"Hello ", "World"};
? ? ? ? int i;
? ? ? ? for(i = 0; i < 2; ++i)
? ? ? ? printf("%s", message
);
? ? ? ? printf("\n");
? ? ? }
--------------------------------------------------------------------------------
編程老鳥(niǎo)
? ? ? #include <iostream.h>
? ? ? #include <string.h>
? ? ? class string
? ? ? {
? ? ? private:
? ? ? ? int size;
? ? ? ? char *ptr;
? ? ? public:
? ? ? ? string() : size(0), ptr(new char('\0')) {}
? ? ? ? string(const string &s) : size(s.size)
? ? ? ? {
? ? ? ? ptr = new char[size + 1];
? ? ? ? strcpy(ptr, s.ptr);
? ? ? ? }
? ? ? ? ~string()
? ? ? ? {
? ? ? ? delete [] ptr;
? ? ? ? }
? ? ? ? friend ostream &operator <<(ostream &, const string &);
? ? ? ? string &operator=(const char *);
? ? ? };
? ? ? ostream &operator<<(ostream &stream, const string &s)
? ? ? {
? ? ? ? return(stream << s.ptr);
? ? ? }
? ? ? string &string::operator=(const char *chrs)
? ? ? {
? ? ? ? if (this != &chrs)
? ? ? ? {
? ? ? ? delete [] ptr;
? ? ? ? size = strlen(chrs);
? ? ? ? ptr = new char[size + 1];
? ? ? ? strcpy(ptr, chrs);
? ? ? ? }
? ? ? ? return(*this);
? ? ? }
? ? ? int main()
? ? ? {
? ? ? ? string str;
? ? ? ? str = "Hello World";
? ? ? ? cout << str << end
? ? ? ? return(0);
? ? ? }
--------------------------------------------------------------------------------
編程高手
? ? ? [
? ? ? uuid(2573F8F4-CFEE-101A-9A9F-00AA00342820)
? ? ? ]
? ? ? library LHello
? ? ? {
? ? ? ? // bring in the master library
? ? ? ? importlib("actimp.tlb");
? ? ? ? importlib("actexp.tlb");
? ? ? ? // bring in my interfaces
? ? ? ? #include "pshlo.idl"
? ? ? ? [
? ? ? ? uuid(2573F8F5-CFEE-101A-9A9F-00AA00342820)
? ? ? ? ]
? ? ? ? cotype THello
? ? ? {
? ? ? interface IHello;
? ? ? interface IPersistFile;
? ? ? };
? ? ? };
? ? ? [
? ? ? exe,
? ? ? uuid(2573F890-CFEE-101A-9A9F-00AA00342820)
? ? ? ]
? ? ? module CHelloLib
? ? ? {
? ? ? ? // some code related header files
? ? ? ? importheader(<windows.h>);
? ? ? ? importheader(<ole2.h>);
? ? ? ? importheader(<except.hxx>);
? ? ? ? importheader("pshlo.h");
? ? ? ? importheader("shlo.hxx");
? ? ? ? importheader("mycls.hxx");
? ? ? ? // needed typelibs
? ? ? ? importlib("actimp.tlb");
? ? ? ? importlib("actexp.tlb");
? ? ? ? importlib("thlo.tlb");
? ? ? ? [
? ? ? ? uuid(2573F891-CFEE-101A-9A9F-00AA00342820),
? ? ? ? aggregatable
? ? ? ? ]
? ? ? ? coclass CHello
? ? ? {
? ? ? cotype THello;
? ? ? };
? ? ? };
? ? ? #include "ipfix.hxx"
? ? ? extern HANDLE hEvent;
? ? ? class CHello : public CHelloBase
? ? ? {
? ? ? public:
? ? ? ? IPFIX(CLSID_CHello);
? ? ? ? CHello(IUnknown *pUnk);
? ? ? ? ~CHello();
? ? ? ? HRESULT __stdcall PrintSz(LPWSTR pwszString);
? ? ? private:
? ? ? ? static int cObjRef;
? ? ? };
? ? ? #include <windows.h>
? ? ? #include <ole2.h>
? ? ? #include <stdio.h>
? ? ? #include <stdlib.h>
? ? ? #include "thlo.h"
? ? ? #include "pshlo.h"
? ? ? #include "shlo.hxx"
? ? ? #include "mycls.hxx"
? ? ? int CHello::cObjRef = 0;
? ? ? CHello::CHello(IUnknown *pUnk) : CHelloBase(pUnk)
? ? ? {
? ? ? ? cObjRef++;
? ? ? ? return;
? ? ? }
? ? ? HRESULT __stdcall CHello::PrintSz(LPWSTR pwszString)
? ? ? {
? ? ? ? printf("%ws\n", pwszString);
? ? ? ? return(ResultFromScode(S_OK));
? ? ? }
? ? ? CHello::~CHello(void)
? ? ? {
? ? ? // when the object count goes to zero, stop the server
? ? ? cObjRef--;
? ? ? if( cObjRef == 0 )
? ? ? ? PulseEvent(hEvent);
? ? ? return;
? ? ? }
? ? ? #include <windows.h>
? ? ? #include <ole2.h>
? ? ? #include "pshlo.h"
? ? ? #include "shlo.hxx"
? ? ? #include "mycls.hxx"
? ? ? HANDLE hEvent;
? ? ? int _cdecl main(
? ? ? int argc,
? ? ? char * argv[]
? ? ? ) {
? ? ? ULONG ulRef;
? ? ? DWORD dwRegistration;
? ? ? CHelloCF *pCF = new CHelloCF();
? ? ? hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
? ? ? // Initialize the OLE libraries
? ? ? CoInitializeEx(NULL, COINIT_MULTITHREADED);
? ? ? CoRegisterClassObject(CLSID_CHello, pCF, CLSCTX_LOCAL_SERVER,
? ? ? ? REGCLS_MULTIPLEUSE, &dwRegistration);
? ? ? // wait on an event to stop
? ? ? WaitForSingleObject(hEvent, INFINITE);
? ? ? // revoke and release the class object
? ? ? CoRevokeClassObject(dwRegistration);
? ? ? ulRef = pCF->Release();
? ? ? // Tell OLE we are going away.
? ? ? CoUninitialize();
? ? ? return(0);
? ? ? }
? ? ? extern CLSID CLSID_CHello;
? ? ? extern UUID LIBID_CHelloLib;
? ? ? CLSID CLSID_CHello = { /* 2573F891-CFEE-101A-9A9F-00AA00342820 */
? ? ? ? 0x2573F891,
? ? ? ? 0xCFEE,
? ? ? ? 0x101A,
? ? ? ? { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }
? ? ? };
? ? ? UUID LIBID_CHelloLib = { /* 2573F890-CFEE-101A-9A9F-00AA00342820 */
? ? ? ? 0x2573F890,
? ? ? ? 0xCFEE,
? ? ? ? 0x101A,
? ? ? ? { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }
? ? ? };
? ? ? #include <windows.h>
? ? ? #include <ole2.h>
? ? ? #include <stdlib.h>
? ? ? #include <string.h>
? ? ? #include <stdio.h>
? ? ? #include "pshlo.h"
? ? ? #include "shlo.hxx"
? ? ? #include "clsid.h"
? ? ? int _cdecl main(
? ? ? int argc,
? ? ? char * argv[]
? ? ? ) {
? ? ? HRESULT hRslt;
? ? ? IHello ? ? *pHello;
? ? ? ULONG ulCnt;
? ? ? IMoniker * pmk;
? ? ? WCHAR wcsT[_MAX_PATH];
? ? ? WCHAR wcsPath[2 * _MAX_PATH];
? ? ? // get object path
? ? ? wcsPath[0] = '\0';
? ? ? wcsT[0] = '\0';
? ? ? if( argc > 1) {
? ? ? ? mbstowcs(wcsPath, argv[1], strlen(argv[1]) + 1);
? ? ? ? wcsupr(wcsPath);
? ? ? ? }
? ? ? else {
? ? ? ? fprintf(stderr, "Object path must be specified\n");
? ? ? ? return(1);
? ? ? ? }
? ? ? // get print string
? ? ? if(argc > 2)
? ? ? ? mbstowcs(wcsT, argv[2], strlen(argv[2]) + 1);
? ? ? else
? ? ? ? wcscpy(wcsT, L"Hello World");
? ? ? printf("Linking to object %ws\n", wcsPath);
? ? ? printf("Text String %ws\n", wcsT);
? ? ? // Initialize the OLE libraries
? ? ? hRslt = CoInitializeEx(NULL, COINIT_MULTITHREADED);
? ? ? if(SUCCEEDED(hRslt)) {
? ? ? ? hRslt = CreateFileMoniker(wcsPath, &pmk);
? ? ? ? if(SUCCEEDED(hRslt))
? ? ? hRslt = BindMoniker(pmk, 0, IID_IHello, (void **)&pHello);
? ? ? ? if(SUCCEEDED(hRslt)) {
? ? ? // print a string out
? ? ? pHello->PrintSz(wcsT);
? ? ? Sleep(2000);
? ? ? ulCnt = pHello->Release();
? ? ? }
? ? ? ? else
? ? ? printf("Failure to connect, status: %lx", hRslt);
? ? ? ? // Tell OLE we are going away.
? ? ? ? CoUninitialize();
? ? ? ? }
? ? ? return(0);
? ? ? }
--------------------------------------------------------------------------------
黑客初階
? ? ? #!/usr/local/bin/perl
? ? ? $msg="Hello, world.\n";
? ? ? if ($#ARGV >= 0) {
? ? ? ? while(defined($arg=shift(@ARGV))) {
? ? ? ? $outfilename = $arg;
? ? ? ? open(FILE, ">" . $outfilename) || die "Can't write $arg: $!\n";
? ? ? ? print (FILE $msg);
? ? ? ? close(FILE) || die "Can't close $arg: $!\n";
? ? ? ? }
? ? ? } else {
? ? ? ? print ($msg);
? ? ? }
? ? ? 1;
--------------------------------------------------------------------------------
黑客有成
? ? ? #include <stdio.h>
? ? ? #define S "Hello, World\n"
? ? ? main(){exit(printf(S) == strlen(S) ? 0 : 1);}
--------------------------------------------------------------------------------
黑客高手
? ? ? % cc -o a.out ~/src/misc/hw/hw.c
? ? ? % a.out
--------------------------------------------------------------------------------
黑客大蝦
? ? ? % cat
? ? ? Hello, world.
? ? ? ^D
--------------------------------------------------------------------------------
初級(jí)經(jīng)理
? ? ? 10 PRINT "HELLO WORLD"
? ? ? 20 END
--------------------------------------------------------------------------------
中級(jí)經(jīng)理
? ? ? mail -s "Hello, world." bob@b12
? ? ? Bob, could you please write me a program that prints "Hello, world."?
? ? ? I need it by tomorrow.
? ? ? ^D
--------------------------------------------------------------------------------
高級(jí)經(jīng)理
? ? ? % zmail jim
? ? ? I need a "Hello, world." program by this afternoon.
--------------------------------------------------------------------------------
首席執(zhí)行官
? ? ? % letter
? ? ? letter: Command not found.
? ? ? % mail
? ? ? To: ^X ^F ^C
? ? ? % help mail
? ? ? help: Command not found.
? ? ? % damn!
? ? ? !: Event unrecognized
? ? ? % logout
--------------------------------------------------------------------------------
還記得孔乙己說(shuō)：茴香豆的‘茴’字有四種寫(xiě)法嗎？現(xiàn)在我們的知識(shí)份子已經(jīng)進(jìn)步了，看看Hello World的196種寫(xiě)法:) http://man.lupaworld.com/content/develop/hello/HelloWorld.shtml
下午寫(xiě)完設(shè)計(jì)，趴在武漢辦公室的窗戶上看風(fēng)景，天氣好的時(shí)候，左面長(zhǎng)江右邊東湖都可以看到，其實(shí)想想在武漢出差也挺不錯(cuò)的，呵呵
彼得·德魯克在他的《 卓有成效的管理者?》當(dāng)中，闡述了知識(shí)工作者管理的秘訣，那就是知識(shí)工作者的工作效率來(lái)自于對(duì)其工作的有效性以及他的工作是否有所成就。這本1966年出版的管理學(xué)書(shū)籍經(jīng)過(guò)近50年的時(shí)間，反而越發(fā)顯得適應(yīng)潮流。 而卓有成效的知識(shí)工作管理者現(xiàn)在顯得比過(guò)去任何時(shí)候都要短缺，也比現(xiàn)時(shí)任何人才都要短缺。在現(xiàn)時(shí)這個(gè)信息爆炸，案例豐富的年代，戰(zhàn)略眼光與部署格局對(duì)于一個(gè)企業(yè)人才不再如此重要，對(duì)于企業(yè)戰(zhàn)略，任何有管理常識(shí)、了解企業(yè)實(shí)情的人大都可以分析得很到位，關(guān)鍵是要找到合適的人去實(shí)施。知道什么樣的人合適，以及找到這個(gè)合適的人，成為企業(yè)家最需要做的事情。而成為那個(gè)合適的人，則成為草根階層走入舞臺(tái)中央的必備能力。 附一篇來(lái)自經(jīng)濟(jì)觀察報(bào)劉軍的《 笨蛋，最重要的是人！》 --------------------------------- ????? 2005年10月8日管理大師彼得·德魯克曾經(jīng)講過(guò)一個(gè)他和《時(shí)代》《財(cái)富》等雜志的出版人亨利·魯斯交往的故事。魯斯有個(gè)很好的新雜志方案——試圖創(chuàng)辦“從美國(guó)人思考角度出發(fā)”的高格調(diào)文化雜志，他去向德魯克求教。德魯克分析了一番說(shuō)，“這份企劃案很棒，不過(guò)晚了50年。”接著，他對(duì)魯斯說(shuō)出了最重要的話：“此外，《時(shí)代》的人也無(wú)法勝任。我猜，你想鼓勵(lì)一些外面的作家來(lái)為這本雜志執(zhí)筆，并以一般大眾為讀者群。但是你的專長(zhǎng)卻是叫自己手下人搞定，因此大有不同。”? ????? 魯斯回答說(shuō)，“我來(lái)向你請(qǐng)教，正因?yàn)槲也孪肽銜?huì)這么說(shuō)。”他因而放棄了這個(gè)計(jì)劃，因?yàn)樗钪说闹匾浴＝?jīng)過(guò)十多年的西方管理教育和知識(shí)傳播，中國(guó)企業(yè)管理者已經(jīng)熟知戰(zhàn)略的理性分析，與重視人比起來(lái)更重視事，另外先建立制度、而不是依靠人的觀念也被廣泛接受。不過(guò)，我卻逐漸感覺(jué)到，在這些問(wèn)題上我們可能有點(diǎn)矯枉過(guò)正，對(duì)于知識(shí)型工作、對(duì)于管理，或許人更重要，是應(yīng)該優(yōu)先考慮的。? ????? 9月底，索尼新任CEO、美國(guó)人霍華德·斯特林格(Howard?Stringer)宣布索尼的戰(zhàn)略調(diào)整計(jì)劃：全球裁員一萬(wàn)人，縮減工廠數(shù)目，出售1200億日元的不動(dòng)產(chǎn)與股票等非核心資產(chǎn)，對(duì)消費(fèi)電子業(yè)務(wù)進(jìn)行架構(gòu)調(diào)整、將權(quán)力集中到這一業(yè)務(wù)的最高主管手中。在過(guò)去五年中，索尼逐漸失去消費(fèi)電子霸主地位，業(yè)績(jī)很不理想，這背后的根本原因正是這些戰(zhàn)略調(diào)整所觸及的問(wèn)題。對(duì)于這一點(diǎn)，大概稍微有點(diǎn)管理常識(shí)的人都知道，我想索尼前CEO出井伸之自然了然于心，他之下的索尼高管也清楚。不過(guò)，大概只有霍華德·斯特林格、索尼歷史上第一個(gè)外國(guó)人CEO、這個(gè)日本文化的局外人才能推行上述改革。? ???? 戰(zhàn)略，有管理常識(shí)、了解企業(yè)實(shí)情的人大都可以分析得很到位，但真正去做，就需要“合適的人”。我一直相信，選擇霍華德·斯特林格作為繼任者，是出井伸之的最重要的決策，體現(xiàn)這個(gè)亞洲最優(yōu)秀的商業(yè)領(lǐng)袖的領(lǐng)導(dǎo)才能。卡洛斯·戈恩已經(jīng)因成功在日產(chǎn)汽車（Nissan）實(shí)現(xiàn)大逆轉(zhuǎn)而成為全球最知名的管理者之一，他當(dāng)初所做的關(guān)閉工廠與裁員、破除日本式企業(yè)聯(lián)盟等措施，都是眾所周知的弊端，但惟有他這個(gè)合適的人才能推動(dòng)變革。斯特林格和戈恩都是在這種情境下最合適的人，只是恰巧他們都是外國(guó)人。? ????? Google、微軟和李開(kāi)復(fù)之間的紛爭(zhēng)一直沒(méi)有停息的跡象。在這個(gè)過(guò)程中李開(kāi)復(fù)把自己再次塑造成了最優(yōu)秀的技術(shù)專家形象，但如果相信這一點(diǎn)，我們就錯(cuò)誤理解了Google的智慧。如果要一流的中文搜索研發(fā)人才，Google的最佳人選絕對(duì)不是李開(kāi)復(fù)，而可能是李彥宏。如果它的戰(zhàn)略訴求點(diǎn)是這個(gè)，它可以百度買(mǎi)下，從而得到李彥宏。但是，Google在中國(guó)，需要的哪里是什么技術(shù)專家、研發(fā)中心？現(xiàn)在Google中國(guó)戰(zhàn)略要的合適的人是據(jù)稱是“技術(shù)專家”的李開(kāi)復(fù)，但他在公眾心目中的號(hào)召力和政府公關(guān)能力才是Google所看重的。? ????? 我們也可以循同樣的視角來(lái)看待雅虎和阿里巴巴之間的聯(lián)姻。這一次是把雅虎中國(guó)的業(yè)務(wù)交道馬云手中去讓他照料，因?yàn)閷?duì)于誰(shuí)了解中國(guó)市場(chǎng)和能夠幫助雅虎發(fā)現(xiàn)中國(guó)市場(chǎng)潛力這個(gè)問(wèn)題，馬云是最佳答案。雅虎在中國(guó)的最近兩次戰(zhàn)略行動(dòng)目標(biāo)都首先是為了“人”。上一次是雅虎在中國(guó)收購(gòu)3721，反而讓其老板周鴻一擔(dān)任中國(guó)區(qū)總裁，從而讓雅虎中國(guó)從跨國(guó)公司在華分支機(jī)構(gòu)這樣的角色變成勇猛的中國(guó)本土企業(yè)。但在經(jīng)歷一段發(fā)展時(shí)期之后，雅虎中國(guó)就需要更合適的人。我們可以認(rèn)為，這是雅虎、阿里巴巴聯(lián)姻的主要原因之一。? ????? 先建立制度、體系，而不是“因人設(shè)事”這樣的觀點(diǎn)被廣泛接受，可是，我們忘記了這個(gè)觀念背后的工業(yè)化背景：所有人的都被當(dāng)成了可替換的零件，所以制度體系最重要。但是，對(duì)于知識(shí)型工作來(lái)說(shuō)，特別是非重復(fù)的創(chuàng)造性工作，每個(gè)人的工作方式、結(jié)果都截然不同。? ????? 我們所設(shè)計(jì)的制度體系，在當(dāng)前的人員安排下也似乎運(yùn)轉(zhuǎn)正常。但是，由于這些人是無(wú)法替換的，人走了，看似精妙的體系也就出現(xiàn)出現(xiàn)問(wèn)題了。這個(gè)時(shí)候，是去做不可能完成的任務(wù)：尋找適合制度體系的一摸一樣的人？還是更改體系？或者看得更遠(yuǎn)點(diǎn)，在現(xiàn)在的情境下，我們根本就不該把制度體系的重要性神話到這種程度？針對(duì)知識(shí)型工作的討論，和上文對(duì)最高管理者的討論并非沒(méi)有聯(lián)系，因?yàn)樵谖铱磥?lái)，管理工作是最重要的、最具創(chuàng)造性的知識(shí)工作。? ????? 吉姆·柯林斯在《從優(yōu)秀到卓越》說(shuō)卓越公司是“先人后事”：這些公司的主管不是先確定目的地（先有方向、愿景、戰(zhàn)略），然后才把人們引向那里；他們首先讓合適的人上車（不合適的人自然請(qǐng)下車），然后才決定去向何處。他所說(shuō)的雖是方向、遠(yuǎn)景，但大體上和制度是同一類型的事物。我們都應(yīng)該了解，合適的人更重要，那些看似嚴(yán)密的戰(zhàn)略分析和完善的制度體系有時(shí)候會(huì)變成令人難以忍受的障礙，因?yàn)樗鼈兒汀昂线m的人”可能是完全矛盾的，這些人通常都難以放到一個(gè)既定的模子中去。?
今天將webwork2.2.1更換成webwork2.2.2，出現(xiàn)了一個(gè)奇怪的異常，每次啟動(dòng)后，都會(huì)報(bào)出： org.xml.sax.SAXParseException:?Element?type?"global-exception-mappings"?must?be?declared.
com.opensymphony.xwork.config.ConfigurationException:?Caught?exception?while?loading?file?xwork.xml
????with?nested?exception?
org.xml.sax.SAXParseException:?Element?type?"global-exception-mappings"?must?be?declared. 如果將xwork.xml中的 global-exception-mappings注釋掉便好
頭疼了幾個(gè)小時(shí)解決不了，不得不求助飛云小俠 飛云小俠一出手果然不同，馬上定位了問(wèn)題所在 就是這句： <!DOCTYPE?xwork?PUBLIC?"-//OpenSymphony?Group//XWork?1.1.1//EN"?"http://www.opensymphony.com/xwork/xwork-1.1.1.dtd">
原來(lái)雖然幾次升級(jí)webwork.jar，但是xwork.xml的DTD解析還是用的原來(lái)的DTD，頂多就是改了DTD的地址，也就是將這句   ?"http://www.opensymphony.com/xwork/xwork-1.1.dtd">
改為這樣 ?"http://www.opensymphony.com/xwork/xwork-1.1.1.dtd">
而實(shí)際上解析DTD是靠的前面那句 <!DOCTYPE?xwork?PUBLIC?"-//OpenSymphony?Group//XWork?1.1.1//EN"?>
原來(lái)一直是 <!DOCTYPE?xwork?PUBLIC?"-//OpenSymphony?Group//XWork?1.0//EN"?>
于是就出現(xiàn)了上面的問(wèn)題 多謝飛云小俠的幫助^_^
自工作以來(lái)，我就養(yǎng)成了睡前讀書(shū)的習(xí)慣，這一年在武漢，實(shí)在買(mǎi)不到一些好書(shū)，每次回北京總要帶很多書(shū)過(guò)來(lái)，最近再次面臨回京購(gòu)書(shū)的局面，在回京之前總不能閑著，于是從去年看過(guò)的書(shū)中亂翻，以第一感覺(jué)來(lái)決定自己最想重讀那本書(shū)，結(jié)果選中了溫博格的《成為技術(shù)領(lǐng)導(dǎo)者－解決問(wèn)題的有機(jī)方法》
兩年前，當(dāng)一位同窗好友集齊全套的溫博格系列的時(shí)候，我曾很不屑的說(shuō)他：一個(gè)人寫(xiě)那么多書(shū)，質(zhì)量顯然沒(méi)保證，買(mǎi)他作甚？現(xiàn)在看來(lái)，當(dāng)時(shí)確是井底之蛙了，溫博格的書(shū)中少有瑕疵，尤其是后期作品，讀來(lái)總是讓人意猶未盡。
過(guò)去的幾年里，我看過(guò)很多書(shū)，無(wú)論是早期GOF的設(shè)計(jì)模式，Martin Fowler的企業(yè)架構(gòu)系列，還是Rod的J2EE開(kāi)發(fā)厚厚的兩卷本，甚至我最喜歡的POSA系列，雖然都會(huì)給人技術(shù)方面成長(zhǎng)的感覺(jué)，但最好情況下也只是讓我感覺(jué)到技藝的變化。
而管理方面的書(shū)籍，則大多走入兩個(gè)極端，要么是學(xué)院式的分析解構(gòu)，要么是江湖術(shù)士式的技巧集合。就像過(guò)去我曾很喜歡DEBORAH G. ANCONA的那本組織行為學(xué)和曾士強(qiáng)的中國(guó)式管理，但現(xiàn)在看來(lái)，DEBORAH關(guān)注組織多過(guò)于關(guān)注團(tuán)隊(duì)，而曾士強(qiáng)則過(guò)于強(qiáng)調(diào)中國(guó)人的心理情結(jié)，實(shí)用歸實(shí)用，但可能不太適合技術(shù)人員的口味，讀他的書(shū)讓人感覺(jué)有些厚黑，讓我常常想到一句俗語(yǔ)：人老精，鬼老靈。
而溫博格的寫(xiě)作方式，如同Ken在英文版序中所說(shuō)，會(huì)引起大量的思考，對(duì)溫博格的文字的思考，思考對(duì)溫博格文字的思考，以及對(duì)自身思考的思考....通過(guò)溫博格的書(shū)，讓我體會(huì)到的事是，讀書(shū)，有時(shí)候是為了實(shí)用，而的有時(shí)候，則純粹是為了過(guò)癮。
本書(shū)中溫博格的MOI模型，實(shí)際上不是一個(gè)行為指導(dǎo)手冊(cè)，而是帶來(lái)了更加宏觀和可思考的空間，讓你對(duì)自己在團(tuán)隊(duì)中的行為更加有目的性，也更加有效。我仍然記得兩年前，上述同窗好友在某技術(shù)論壇發(fā)表的一篇名為《任務(wù)分解和任務(wù)分配》的帖子，現(xiàn)在看來(lái)，在該貼中提出的Effective Communication仍然太過(guò)于關(guān)注技術(shù)視角了，而現(xiàn)在，我則更加注重人文關(guān)懷，包括對(duì)技術(shù)架構(gòu)。這一點(diǎn)，在本書(shū)第十章得到了精彩的闡述。
下面的內(nèi)容，來(lái)自于本書(shū)第三章摘錄
各種各樣的想法是解決問(wèn)題的核心，沒(méi)有想法就不可能找到解決方案，但想法太多又會(huì)雜亂無(wú)章，領(lǐng)導(dǎo)者需要對(duì)想法的交流進(jìn)行有效的管理。以下是領(lǐng)導(dǎo)者常用的12種典型的管理想法交流的方法以及點(diǎn)評(píng)。
??? >? 為團(tuán)隊(duì)提供一個(gè)聰明的想法。盡管這是最顯而易見(jiàn)的領(lǐng)導(dǎo)者行為，而且有時(shí)新的想法的確會(huì)起到關(guān)鍵性作用，但事實(shí)上真正全新的想法是非常罕見(jiàn)的。比發(fā)掘一個(gè)新的聰明想法更重要的是創(chuàng)建一個(gè)合適的環(huán)境，是能夠解決問(wèn)題的想法一旦提出就能被大家意識(shí)到。
??? >? 鼓勵(lì)和借鑒有用的舊想法。盡管有些領(lǐng)導(dǎo)者不愿意承認(rèn)，但他們實(shí)際上是根深蒂固的模仿者。最優(yōu)秀的領(lǐng)導(dǎo)者不僅承認(rèn)這一點(diǎn)，而且將其視為一門(mén)藝術(shù)而精心培育。
??? >? 認(rèn)真完善團(tuán)隊(duì)成員提出的想法。大部分解決問(wèn)題型領(lǐng)導(dǎo)者在完善一個(gè)想法上花費(fèi)的時(shí)間比提出這個(gè)想法多上百倍的精力。
??? >? 放棄自己的想法并支持團(tuán)隊(duì)采納的想法，但只有當(dāng)每個(gè)成員都充分了解你的想法時(shí)才予以放棄。放棄或保留你的想法是相當(dāng)簡(jiǎn)單的，難的是要做到理智和公正。
??? >? 盡管時(shí)間壓力很大，仍然不要吝嗇花時(shí)間聽(tīng)其他人解釋他們的想法。迫于時(shí)間壓力，大部分想法沒(méi)有經(jīng)過(guò)充分理解就被否決了，事實(shí)上，其中一些想法可以為我們節(jié)省的時(shí)間是花在了解錯(cuò)誤想法上時(shí)間的上百倍。
??? >? 檢驗(yàn)別人提出的想法。在任何給定的環(huán)境中，絕大部分的想法都是沒(méi)用的，但到底哪些才是有用的呢？領(lǐng)導(dǎo)者要做的就是分析和檢驗(yàn)這些想法。
??? >? 為了保持想法的交流，不要輕易否定團(tuán)隊(duì)成員的想法。盡管檢驗(yàn)這些想法是非常重要的，但幾乎沒(méi)有什么想法會(huì)危險(xiǎn)到使我們來(lái)不及重新考慮一下我們的第一反應(yīng)，就必須立刻否定。
??? >? 如果你不得不否定一個(gè)想法，那么一定要明確，你所否定的只是這個(gè)想法，而不是提出這個(gè)想法的人。解決問(wèn)題型領(lǐng)導(dǎo)者一直清楚地知道，并不是所有的想法對(duì)每個(gè)問(wèn)題都有幫助，但他們更知道，團(tuán)隊(duì)中的每一個(gè)成員都是有用的。
??? >? 在給出你的想法之前要先對(duì)它進(jìn)行檢驗(yàn)。沒(méi)有人可以聰明到提出所有建設(shè)性的想法，而一個(gè)喋喋不休地發(fā)表自己未經(jīng)仔細(xì)考慮的想法的人卻能有效地阻止其他人給出自己的想法。
??? >? 當(dāng)時(shí)間和人力吃緊時(shí)，不要再考慮新的想法而應(yīng)該專注于現(xiàn)有的想法。
??? >? 鼓勵(lì)團(tuán)隊(duì)成員放棄以前曾經(jīng)成功過(guò)，但并不適用于現(xiàn)在情況的想法。
??? >? 如果一個(gè)已被否定的想法對(duì)問(wèn)題的其他部分有價(jià)值，就應(yīng)該重新采納它。其實(shí)沒(méi)有絕對(duì)不好的想法，之所以“不好”只是因?yàn)樗鼈兂霈F(xiàn)在不適當(dāng)?shù)牡攸c(diǎn)或時(shí)間。
去年年底，osgi R4發(fā)布，eclipse建立equinox項(xiàng)目，標(biāo)志著以osgi為核心的組件管理模型正式進(jìn)入使用階段，鑒于今年年初jsr291的推出，osgi正式走向java世界的前端，遂建立osgi觀察者group，希望能同所有關(guān)心和喜愛(ài)osgi的國(guó)內(nèi)技術(shù)人員共同進(jìn)步。 加入osgi觀察者：
最近的忙碌加上精神壓力，讓我患上了胃病，每天吃完飯都會(huì)難受好一陣子，給自己學(xué)醫(yī)的兒時(shí)好友打電話，被勸之：“人生苦短，要學(xué)會(huì)善待自己每一天”。遂發(fā)此文為戒。
附一篇BJUG中Tin發(fā)的文章《白天紐約黑夜巴黎》
-------------------------------
白天紐約黑夜巴黎
-------------------------------
【王文華／文】
我在趕些什么？我耗盡青春用盡全力，拼命追求身外之物，結(jié)果我真的比別人有錢(qián)、有名嗎？更重要的，我真的因此而快樂(lè)嗎？遠(yuǎn)方有廣闊的地平線，為何我還在原地?fù)u過(guò)時(shí)的呼拉圈？
紐約和巴黎，代表了我人生的兩個(gè)面向。紐約是白天，巴黎是黑夜。紐約是前半生，巴黎是下半場(chǎng)。
三十五歲之前，我認(rèn)定紐約是世上最棒的城市。我在加州念研究所，畢業(yè)后迫不及待地去紐約工作。一做五年，快樂(lè)似神仙。我愛(ài)紐約的原因跟很多人一樣：她是二十世紀(jì)以來(lái)世界文化的中心。豐富、方便。靠著地鐵和出租車，你可以穿越時(shí)間，前后各跑數(shù)百年。人類最新和最舊、最好和最壞的東西，紐約都看得見(jiàn)。
所以在紐約時(shí)，我把握每分每秒去體會(huì)。白天，我在金融機(jī)構(gòu)做事，一天十小時(shí)。晚上下了班，去NYU學(xué)電影，一坐四小時(shí)。在那二十多歲的年紀(jì)，忙碌是唯一有意義的生活方式。活著，就是要把自己榨干，把自己居住的城市，內(nèi)外翻轉(zhuǎn)過(guò)來(lái)。
這種想法并不是到紐約才有的。其實(shí)從小開(kāi)始，臺(tái)灣人就過(guò)著紐約生活。紐約生活，充滿新教徒的打拚精神和資本主義的求勝意志。相信人要借著不斷努力，克服萬(wàn)難、打敗競(jìng)爭(zhēng)。活著的目的，是更大、更多、更富裕、更有名。權(quán)力與財(cái)富，是紐約人的兩個(gè)上帝。而能幫你走進(jìn)天堂的鞋，就是事業(yè)、事業(yè)、事業(yè)。
在這種弱肉強(qiáng)食的生活方式，為了保持領(lǐng)先，每個(gè)人都在趕時(shí)間、搶資源。進(jìn)了電梯，明明已經(jīng)按了樓層的鈕，那燈也亮了，偏偏還要再按幾下，彷佛這樣就可以快一點(diǎn)。出了公司，明明已經(jīng)下班了，卻還要不停講手機(jī)，搖控每一個(gè)環(huán)節(jié)。在紐約，為達(dá)目的，可以不擇手段，甚至趕盡殺絕。在紐約，沒(méi)有壞人，只有失敗者。
臺(tái)灣，是不是也變成這樣？
每一件事，都變成工作。上班當(dāng)然是工作，下班后的應(yīng)酬也是工作。有人談戀愛(ài)是在工作，甚至到酒店喝酒、KTV狂歡，臉上都?xì)怛v騰，準(zhǔn)備拚個(gè)你死我活。
我曾熱烈擁抱這種生活，并著迷于這種因?yàn)闊境晒Χ俺龅慕箲]。這種焦慮讓我坐在椅子邊緣，以便迅速地跳起來(lái)閃躲明槍暗箭。這種警覺(jué)性讓我練就了酒量和膽量、抗壓性和厚臉皮。但也養(yǎng)成了偏執(zhí)和倔強(qiáng)、優(yōu)越感和勢(shì)利眼。在紐約時(shí)我深信：能在這里活下來(lái)的，都是可敬的對(duì)手。黯然離開(kāi)的，統(tǒng)統(tǒng)是輸家。人生任何事，絕對(duì)要堅(jiān)持到底。半途而廢的，必定有隱疾。在這不睡的城市，每天我醒來(lái)，帶著人定勝天的活力，跟著法蘭克辛納屈唱〈紐約?紐約〉：「如果你能在紐約成功，你可以在任何地方成功！」是的，在紐約，現(xiàn)代的羅馬競(jìng)技場(chǎng)，我要和別人，以及自己，比出高低。
這套想法，在我三十五歲以后，慢慢改變。
第一件動(dòng)搖我想法的，是父親的過(guò)世。我父親一生奉公守法、與人為善。毫無(wú)不良嗜好，身體健康地像城堡。七十二歲時(shí)，他得了癌癥、引發(fā)中風(fēng)，經(jīng)歷了所有的痛苦和羞辱。他一生辛勤工作、努力存錢(qián)、堅(jiān)信現(xiàn)在的苦可以換得更好的明天。我們也相信一分耕耘、一分收獲，用在紐約拚事業(yè)的精神照顧他。但兩年的治療兵敗如山倒，最后他還是走了。父親逝世的那天，我的價(jià)值系統(tǒng)崩潰了。我一路走來(lái)引以為傲的「紐約精神」，沒(méi)想到這么脆弱。
不止在病床，也在職場(chǎng)。當(dāng)我在企業(yè)越爬越高，才發(fā)現(xiàn)「資本主義」在職場(chǎng)中也未必靈驗(yàn)。上過(guò)班的都知道，很少公司真的是「開(kāi)放市場(chǎng)」、「公平競(jìng)爭(zhēng)」。大部分的同事都覺(jué)得你不是朋友、就是敵人。職場(chǎng)上偉大的，未必會(huì)成功。成功的，有時(shí)很渺小。很多人一輩子為公司鞠躬盡瘁，最后得到一支紀(jì)念筆。那些卷款潛逃的，反而變成傳奇。
慢慢的，我體會(huì)到：世上有一種比「善有善報(bào)、惡有惡報(bào)」更高、更復(fù)雜的公平。人生有另一種比「功成名就」更幽微、更持久的樂(lè)趣。那是沖沖沖的美式資本主義，所無(wú)法解釋的。
我能在哪里找到那種公平和樂(lè)趣呢？我想過(guò)西藏、不丹、非洲、紐西蘭。然后，我注意到法國(guó)。
住紐約時(shí)，法國(guó)是嘲諷的對(duì)象。身為經(jīng)濟(jì)、科技、和軍事強(qiáng)權(quán)的美國(guó)，談起法國(guó)總是忍不住調(diào)侃一番。法國(guó)是沒(méi)落的貴族，值得崇拜的人都已作古。法國(guó)人傲慢，高稅率讓每個(gè)人都很慵懶。動(dòng)不動(dòng)就罷工，連酒莊主人都要走上街頭。
搬回臺(tái)灣后，普羅旺斯、托斯卡尼突然流行。我看了弗朗西斯?梅思的《美麗的托斯卡尼》，其中一句話打動(dòng)了我：「在加州，時(shí)間像呼拉圈。我扭個(gè)不停，卻停在原地。在托斯卡尼，我可以在地中海的陽(yáng)光下，提著一籃李子，逍遙地走一整天。」
是啊！我在趕些什么？我耗盡青春用盡全力，拚命追求身外之物，結(jié)果我真的比別人有錢(qián)、有名嗎？更重要的，我真的因此而快樂(lè)嗎？遠(yuǎn)方有廣闊的地平線，為何我還在原地?fù)u過(guò)時(shí)的呼拉圈？
當(dāng)我重新學(xué)習(xí)法國(guó)，我發(fā)現(xiàn)法國(guó)和美國(guó)代表兩種截然不同的生活方式。美國(guó)人追求人定勝天，凡事要逆流而上。法國(guó)人講究和平共存，凡事順勢(shì)而為。紐約有很多一百層的摩天大樓，巴黎的房子都是三百年的古跡。紐約不斷創(chuàng)新，巴黎永遠(yuǎn)有懷舊的氣息。巴黎人在咖啡廳聊天，紐約人在咖啡廳用計(jì)算機(jī)。紐約有人潮，巴黎有味道。紐約有鈔票，巴黎有蛋糕。
不論是政府或個(gè)人，法國(guó)人都把精神投注在食、衣、住、行等「身內(nèi)之物」。就讓美國(guó)去做老大哥吧。要征服太空、要打伊拉克、要調(diào)高利率、要發(fā)明新科技，都隨他去。法國(guó)人甘愿偏安大西洋，抽煙、喝酒、看足球、搞時(shí)尚。當(dāng)美國(guó)人忙出了胃潰瘍，法國(guó)人又吃了一罐鵝肝醬。
講到吃，法國(guó)有三百種起司、光是波爾多就有五十七個(gè)酒的產(chǎn)區(qū)。晚上六點(diǎn)朝咖啡廳門(mén)口一坐，一杯紅酒就可以聊三個(gè)小時(shí)。九點(diǎn)再去吃晚餐，一直吃到隔天凌晨。他們?cè)诔陨纤ǖ臅r(shí)間，跟我們上班時(shí)數(shù)一樣。但諷刺的是：他們沒(méi)有「All
You Can Eat」。
吃很重要，但也要會(huì)挑時(shí)間，朋友介紹我去試一家法國(guó)餐廳，提醒我他們禮拜二、四晚上休息。「為什么？」我問(wèn)。他說(shuō)：「因?yàn)橹鲝N要回家看足球。」
聰明的主廚懂法律。法國(guó)法律規(guī)定一周工作最多三十五小時(shí)，大部分的人一年有五周的假期。而美國(guó)人把加班當(dāng)作自己有價(jià)值的表示，度假時(shí)還拿著手機(jī)回E-mail。法國(guó)人比美國(guó)人會(huì)玩。每年六月的巴黎音樂(lè)節(jié)，從午后到深夜，幾百場(chǎng)露天音樂(lè)會(huì)在各處同時(shí)舉行，人多到地鐵都暫停收費(fèi)。每年十月的「白夜」，平日入夜就打烊的店面，徹夜?fàn)I業(yè)到清晨七點(diǎn)。每年夏天，巴黎市政府在塞納-馬恩省河右岸布置了三段、總長(zhǎng)一．八公里的人工海灘。細(xì)砂、吊床、躺椅、棕櫚樹(shù)，自然海灘有的景致這里都有，讓沒(méi)有錢(qián)去海邊度假的民眾，也可以享受到海灘風(fēng)光。
當(dāng)然，法國(guó)這么深厚的文化，不可能只從吃喝玩樂(lè)而來(lái)。美國(guó)人讀書(shū)，為了考證照。法國(guó)人讀書(shū)，為了搞情調(diào)。每年十月的讀書(shū)節(jié)，大城市的火車站內(nèi)，民眾輪流上臺(tái)朗誦詩(shī)句。書(shū)店?duì)I業(yè)到天明，整晚有現(xiàn)場(chǎng)演奏的樂(lè)曲。「美食書(shū)展」選在銅臭味最重的證券交易所舉辦。小鎮(zhèn)書(shū)展的書(shū)直接「長(zhǎng)」在樹(shù)上，讀者必須爬到樹(shù)上，把書(shū)摘下來(lái)品嘗。
一直跟著美國(guó)走的臺(tái)灣人，會(huì)心動(dòng)嗎？
我心動(dòng)了。十一月我到巴黎，一位法國(guó)朋友來(lái)接待我。臨走前我問(wèn)他：「明天你要干嘛？」
「我要去銀行。」
「然后呢？」我問(wèn)。
「我不懂你的意思......」
對(duì)我來(lái)說(shuō)，「去銀行」是吃完午飯后跑去辦的小事。對(duì)法國(guó)人來(lái)說(shuō)，這是他一天全部的行程。法國(guó)人總是專心而緩慢的，每天把一件小事做好。
這樣的生活，對(duì)美國(guó)或臺(tái)灣人來(lái)說(shuō)，實(shí)在是太頹廢了。的確也是。法國(guó)失業(yè)率接近10%，高稅率讓雇主寧愿打烊休息，免得幫員工繳稅。巴黎鬧區(qū)紙醉金迷，但郊區(qū)的少數(shù)民族卻沒(méi)有工作機(jī)會(huì)。這些都是黑暗面，但對(duì)于每日被強(qiáng)光烤焦的臺(tái)灣人，陰暗也許提供了喘息空間。生命的終點(diǎn)都一樣，有錢(qián)人的喪禮只是比較多人上香。不斷的追趕只是提前沖向謝幕，為什么不把時(shí)間花在慢慢為生命暖場(chǎng)？你不需要一輩子鞠躬盡瘁、死而后已。你可以偶爾伸伸懶腰、安步當(dāng)車。
我從巴黎回來(lái)，臺(tái)北并沒(méi)有改變。關(guān)了兩周的手機(jī)再度響起，一通電話找不到我的人會(huì)連續(xù)狂call十通。和朋友見(jiàn)面，他很關(guān)心地問(wèn)我：「好了，你現(xiàn)在工作也辭了、歐洲也去了，接下來(lái)有什么projects？」
「Projects」？多么紐約的字眼。
我真想說(shuō)：「好好生活，不就是人生最大的project？」但我知道在熙來(lái)攘往的臺(tái)北街頭，在不到四十歲的年紀(jì)，這樣說(shuō)太矯情了。況且，我今天之所以有錢(qián)有閑享受法式生活，不也正因?yàn)槲以诿朗缴钪械玫胶芏嗬妫课胰詿釔?ài)工作、熱愛(ài)紐約，但已不用像二十歲時(shí)一樣亦步亦趨、寸步不離。
所以我說(shuō)：「我還是會(huì)早起，白天努力寫(xiě)作。但到了晚上，我想關(guān)掉手機(jī)。」
世界少了我，其實(shí)無(wú)所謂。但我少了我，還剩什么？
他笑一笑：「你這是用紐約來(lái)過(guò)白天，用巴黎來(lái)過(guò)黑夜。」
唉，他講得真好！這應(yīng)該是一個(gè)完美的妥協(xié)吧。也許有一天，我能創(chuàng)造自己的「白夜」，讓白天和黑夜融合在一起。但我還沒(méi)到那個(gè)境界。
「明天星期一，你要干嘛？」他問(wèn)。
「我要去銀行。」
「然后呢？」
我張大眼睛，停頓了一下。
「然后呢？」他追問(wèn)。
「然后我會(huì)摩拳擦掌，認(rèn)真地寫(xiě)一篇文章。」
我們是不是也應(yīng)該學(xué)一學(xué)法國(guó)人呢？提高些生活質(zhì)量，注意身體。
很久沒(méi)更新blog了，實(shí)在太忙，今天看到有朋友在我去年的blog《 MINA is a good framwork 》中回復(fù)提到比較一下MNA和QuickServer，遂寫(xiě)一篇小文： First for all, QuickServer is licensed as LGPL, and MINA as ASL 從我個(gè)人角度而言，去年看過(guò)QuickServer的源碼，我在項(xiàng)目中采用的每一個(gè)框架或類庫(kù)都會(huì)做綜合評(píng)價(jià)，通常不會(huì)是一個(gè)原因?qū)е挛也捎没驔](méi)有采用某個(gè)庫(kù)或框架，具體最后沒(méi)有采用QuickServer的原因忘記了，但是當(dāng)時(shí)給我的總體感覺(jué)是，QuickServer雖然很方便，但不會(huì)讓我在架構(gòu)上得到新的好處。而它最大的優(yōu)點(diǎn)則是，支持JDK1.3（如果沒(méi)記錯(cuò)的話），另外就是License的問(wèn)題 下面看一看來(lái)自TrusinLee的評(píng)論： Thank for the information about another network application framework. I found a few differences: * QuickServer supports blocking mode. (MINA supports only non-blocking mode, but you can make your operation block at your will.) * QuickServer provides GUI-based admin. (MINA doesn't have one yet, but will have full JMX support soon, which is a standard.) * QuickServer uses java.util.logging. (MINA uses SLF4J, which is a safe replacement of commons-logging.) * QuickServer uses its own XML settings. (MINA provides Spring framework integration instead.) * QuickServer can specify maximum number of clients allowed. (MINA can do this using a filter, but not implemented by default. Of course, this will be implemented as an overload prevention filter.) * QuickServer team has one crew. (MINA has three crews.) * QuickServer project started in 2003. (MINA started in 2005.) * QuickServer has a difference event handler interface from MINA. (You'll have to compare it by yourself. IMHO, MINA has one simple enough handler which covers all QuickServer provides.) * QuickServer doesn't support UDP at all. (MINA does) * QuickServer doesn't support client-side API at all. (MINA does) * QuickServer integrated authentication and text protocol in its core. (MINA didn't and they are considered as a cross-cutting concern that a filter should take care of. IMHO, MINA is more extensible here.) 至于對(duì)MINA更詳細(xì)的介紹，可以看看我去年翻譯的MINA的Tutorial
MinaTutorialInChinese
MINA的應(yīng)用，在MINA的Testimonials中有兩個(gè)項(xiàng)目：
開(kāi)源Flash server：red5
http://ludonet.leonardo.it/的game server
還有，就是MINA所在的項(xiàng)目，Apache的LDAP
摘要: Eclipse3.1剛剛release的時(shí)候，它的RCP發(fā)布功能就很吸引我，當(dāng)時(shí)正好有個(gè)小東西要做，就用了這個(gè)功能發(fā)布了一個(gè)小程序，似乎很多人推薦用NSIS，但是我覺(jué)得Eclipse的這個(gè)功能似乎更方便，幾乎不用擔(dān)心任何部署的問(wèn)題。
閱讀全文
Blog有一個(gè)多月沒(méi)有更新了，今年8個(gè)月的忙碌生活，以及最后兩個(gè)月的突擊使我徹底失去了熱情，無(wú)論是工作還是寫(xiě)blog，目前只想每天休息休息，看看書(shū)。
12月底回了一趟北京，然后又順路回大連家中辦了點(diǎn)事情，待了三天，又飛回武漢著手招人和培訓(xùn)的工作，為明年的工作做準(zhǔn)備，技術(shù)上有些事情還得自己動(dòng)手，不知道這忙碌的生活什么時(shí)候可以停歇.....
在妖精群里還跟非魚(yú)說(shuō)要寫(xiě)一篇關(guān)于架構(gòu)師職責(zé)的Blog，暫時(shí)還是沒(méi)心情寫(xiě)，不過(guò)自從那次在群里討論過(guò)架構(gòu)師的職責(zé)之后，似乎已經(jīng)有很多人寫(xiě)了這方面的文章，在blogjava中就有很多了，架構(gòu)師之家的文章數(shù)目也一下激增起來(lái)。
近期blogjava也是好戲連臺(tái)，雖然不寫(xiě)，看著也是過(guò)足癮了。
canonical是個(gè)很好的寫(xiě)手，學(xué)理論物理出身的思維縝密果然不同凡響，關(guān)于架構(gòu)師的職責(zé)那篇，已經(jīng)把能寫(xiě)的都寫(xiě)盡了。江南白衣 搞的springside.org.cn看起來(lái)也很吸引人，有理想的好青年的典范。非魚(yú)的幾篇關(guān)于架構(gòu)的文章也寫(xiě)的很扎實(shí)，預(yù)備役架構(gòu)師是有些謙虛了，呵呵。Jerry在經(jīng)過(guò)一段時(shí)間的忙碌之后，似乎又再次復(fù)活了，以每天一到兩篇的速度持續(xù)更新blog，讓我著實(shí)佩服他的精力，幾篇blog的涉獵范圍so廣，足見(jiàn)積累之深。老莊最近似乎也是瑣事纏身，除了在上月底被Rx反敲喪鐘的時(shí)候露了幾次臉，就沒(méi)怎么出現(xiàn)過(guò)，看來(lái)年底了哪里都是忙碌的時(shí)候。Raimundox近期多次出手，除了對(duì)老莊的《喪鐘》系列的再次釋疑之外，還為我們貢獻(xiàn)了Smalltalk的入門(mén)手冊(cè)，實(shí)為近期技術(shù)blog中風(fēng)頭最勁的一個(gè)了。飛云小俠也更新漸少了，除了今天預(yù)告了WebWork2.2的發(fā)布，已經(jīng)10天沒(méi)更新了。近期weide的技術(shù)架構(gòu)評(píng)估也是頗為扎眼，算是近期最全面完整的一篇技術(shù)文章了，顯然是花了精力了，難怪達(dá)到14709的訪問(wèn)量 :)
2005年讓我感覺(jué)到人的精力畢竟有限，以及，一個(gè)純技術(shù)人員能發(fā)揮的能量實(shí)在太小了，雖然不情愿，但這可能促使我更早的脫離純技術(shù)崗位，真是凌亂的一年......
開(kāi)發(fā)一個(gè)基于消息的解決方案是不容易的事情，在生產(chǎn)中操作這樣一個(gè)產(chǎn)品同樣也是一個(gè)挑戰(zhàn)：一個(gè)基于消息的集成解決方案一天可以產(chǎn)生、路由和轉(zhuǎn)換成千上萬(wàn)的消息。我們不得不處理異常、效率瓶頸或改變合作系統(tǒng)。而為了使事情變得更加有挑戰(zhàn)性，組件經(jīng)常被分布在不同的平臺(tái)和機(jī)器上，甚至位于不同的地理位置。
System Management包含以下幾種模式
l Control Bus
l Detour
l Wire Tap
l Message History
l Message Store
l Smart Proxy
l Test Message
l Channel Purger
除了與生據(jù)來(lái)的復(fù)雜性、分布式集成的規(guī)模以及個(gè)性化的應(yīng)用之外，低耦合的架構(gòu)使得測(cè)試和debug變得更加困難。Martin Fowler將這個(gè)癥狀稱為“架構(gòu)師的夢(mèng)想，開(kāi)發(fā)者的夢(mèng)魘”。低耦合的架構(gòu)原則以及間接的依賴于外部系統(tǒng)提供了靈活性。然而，測(cè)試一個(gè)消息生產(chǎn)者不了解消息消費(fèi)者的系統(tǒng)可能會(huì)是一個(gè)挑戰(zhàn)。另外異步的和時(shí)間相關(guān)的消息使得事情變的更加復(fù)雜。舉例來(lái)說(shuō)，消息方案可能被設(shè)計(jì)沒(méi)有被成消息生產(chǎn)者者必須從接受者那里得到一個(gè)回應(yīng)。同樣的消息基礎(chǔ)設(shè)施通常保證傳輸消息，但不能保證傳輸時(shí)間。這是的開(kāi)發(fā)基于消息傳送結(jié)果的測(cè)試用例變得困難。
當(dāng)監(jiān)控一個(gè)消息解決方案，我們可以在兩個(gè)抽象層面上跟蹤消息流。一個(gè)典型的系統(tǒng)管理方案監(jiān)控多少消息被發(fā)送或者它多長(zhǎng)時(shí)間得到一個(gè)被處理的消息。這些監(jiān)控方案不檢查消息數(shù)據(jù)，除了可能會(huì)檢查消息頭中的幾個(gè)字段（比如消息標(biāo)識(shí)或者消息歷史）。與之相對(duì)的，BAM（business activity monitoring）方案聚焦于包含在消息中的有效數(shù)據(jù)，舉例來(lái)說(shuō)，發(fā)生在過(guò)去一小時(shí)的所有訂單的金額。System Management中的很多模式都足夠通用并可以用在以上兩個(gè)目的中（監(jiān)控消息頭或者消息內(nèi)容）。然而，由于BAM本身就是一個(gè)新領(lǐng)域，并且需要從數(shù)據(jù)倉(cāng)庫(kù)中獲得很多數(shù)據(jù)（有些我們根本就沒(méi)有涉及到），我們決定在系統(tǒng)管理的內(nèi)容中討論這些模式。
系統(tǒng)管理模式被設(shè)計(jì)用于為保持一個(gè)基于消息的復(fù)雜系統(tǒng)的運(yùn)轉(zhuǎn)所提出的需求并提供工具。System Management的模式涉及三個(gè)種類：監(jiān)控和控制，觀察和分析消息流量，測(cè)試和調(diào)試。
監(jiān)控和控制
一個(gè)Control Bus提供一個(gè)單獨(dú)的控制點(diǎn)來(lái)對(duì)一個(gè)分布式方案進(jìn)行監(jiān)控和管理。它將多個(gè)組件連接到一個(gè)中心管理控制臺(tái)，這里可以顯示每個(gè)組件的狀態(tài)并且監(jiān)控通過(guò)每個(gè)組件的消息流量。控制臺(tái)同時(shí)也可以用于發(fā)送控制命令給組件，比如，轉(zhuǎn)變消息流。
我們可能想要在路由消息時(shí)添加附加的步驟，比如驗(yàn)證或者日志。由于這些步驟可能使效率降低，所以我們可以通過(guò)Control Bus來(lái)控制他們開(kāi)關(guān)。一個(gè)Detour為我們提供這種能力。
觀察和分析消息流量
有時(shí)我們想要在不影響主要消息流的情況下觀察消息的內(nèi)容。一個(gè)Wire Tap允許我們接入到消息流中。
當(dāng)我們調(diào)試一個(gè)基于消息的系統(tǒng)，知道一個(gè)特定的消息在哪使很有幫助的。Message History保留一個(gè)消息訪問(wèn)過(guò)的所有組件的日志，而不需要增加組件間的依賴。
然而Message History依賴于單獨(dú)的消息，一個(gè)中心的Message Store可以提供一個(gè)穿越系統(tǒng)的每個(gè)消息的完整記錄。結(jié)合Message History，Message Store可以分析所有消息穿過(guò)系統(tǒng)的可能路徑。
Wire Tap, Message History, 和Message Store幫助我們分析異步的消息流。為了跟蹤發(fā)送到請(qǐng)求-應(yīng)答service的消息，我們需要在消息流中插入一個(gè)Smart Proxy。
測(cè)試和調(diào)試
在部署前測(cè)試一個(gè)消息系統(tǒng)是一個(gè)非常好的注意。但是測(cè)試不應(yīng)該停止在部署前。你應(yīng)該有能力驗(yàn)證正在運(yùn)行的消息系統(tǒng)運(yùn)行持續(xù)的運(yùn)行正常。你可以周期性的發(fā)送一個(gè)Test Message到系統(tǒng)中并驗(yàn)證結(jié)果。
當(dāng)一個(gè)組件失敗或者運(yùn)行不正常，它可以簡(jiǎn)單的終止，并放棄一個(gè)channel中的剩余消息。在測(cè)試期間這是很有用的。一個(gè)Channel Purger可以為我們做這些。
最近身體不太好，轉(zhuǎn)貼一則文章，提醒自己多多休息和鍛煉。 －－－－－－－－－－－－－－－－－－－－－－－－
只要踏入在我們IT這個(gè)行業(yè), 過(guò)不了幾年身體就是亞健康狀態(tài),過(guò)渡的話就可能會(huì)“過(guò)勞死”,要想防止“過(guò)勞死”，就必須了解身體為我們發(fā)出的“過(guò)勞死”信號(hào)。
研究者認(rèn)為：在這27項(xiàng)癥狀和因素中占有7項(xiàng)以上，即是有過(guò)度疲勞危險(xiǎn)者，占10項(xiàng)以上就可能在任何時(shí)候發(fā)生“過(guò)勞死”。同時(shí)，在第1項(xiàng)到第9項(xiàng)中占兩項(xiàng)以上或者在第10項(xiàng)到18項(xiàng)中占3項(xiàng)以上者也要特別注意，這27項(xiàng)癥狀和因素分別是：
1.經(jīng)常感到疲倦，忘性大；
2.酒量突然下降，即使飲酒也不感到有滋味；
3.突然覺(jué)得有衰老感；
4.肩部和頸部發(fā)木發(fā)僵；
5.因?yàn)槠诤涂鄲炇撸?/U>
6.有一點(diǎn)小事也煩躁和生氣；
7.經(jīng)常頭痛和胸悶；
8.發(fā)生高血壓、糖尿病，心電圖測(cè)試結(jié)果不正常；
9.體重突然變化大，出現(xiàn)“將軍肚”；
10.幾乎每天晚上聚餐飲酒；
11.一天喝5杯以上咖啡；
12.經(jīng)常不吃早飯或吃飯時(shí)間不固定；
13.喜歡吃油炸食品；
14.一天吸煙30支以上；
15.晚上10時(shí)也不回家或者12時(shí)以后回家占一半以上；
16.上下班單程占2小時(shí)以上；
17.最近幾年運(yùn)動(dòng)也不流汗；
18.自我感覺(jué)身體良好而不看病；
19.一天工作10小時(shí)以上；
20.星期天也上班；
21.經(jīng)常出差，每周只在家住兩三天；
22.夜班多，工作時(shí)間不規(guī)則；
23.最近有工作調(diào)動(dòng)或工作變化；
24.升職或者工作量增多；
25.最近以來(lái)加班時(shí)間突然增加；
26.人際關(guān)系突然變壞；
27.最近工作失誤或者發(fā)生不和。
針對(duì)如何擺脫過(guò)度疲勞，何永成博士開(kāi)出如下處方：
消除腦力疲勞法：適當(dāng)參加體育鍛煉和文娛活動(dòng)，積極休息。如果是心理疲勞，千萬(wàn)不要濫用鎮(zhèn)靜劑、安眠藥等，應(yīng)找出引起感情憂郁的原因，并求得解脫。病理性疲勞，應(yīng)及時(shí)找醫(yī)生檢查和治療。
飲食補(bǔ)充法：注意飲食營(yíng)養(yǎng)的搭配。多吃含蛋白質(zhì)、脂肪和豐富的B族維生素食物，如豆腐、牛奶、魚(yú)肉類，多吃水果、蔬菜，適量飲水。
休息恢復(fù)法：每天都要留出一定的休息時(shí)間。聽(tīng)音樂(lè)、繪畫(huà)、散步等有助解除生理疲勞。
科學(xué)健身方法：一是有氧運(yùn)動(dòng)，如跑步、打球、打拳、騎車、爬山等；二是腹式呼吸，全身放松后深呼吸，鼓足腹部，憋一會(huì)兒再慢慢呼出；三是做保健操；四是點(diǎn)穴按摩。
哥們, 上面27條在你身上出現(xiàn)幾條癥狀了? 怕怕吧?
建議哥們們每天早上和傍晚各抽出一小時(shí)鍛煉身體,畢竟身體是革命的本錢(qián)!
轉(zhuǎn)自: 電子商務(wù)論壇 http://bbs.eczn.com/
上面下劃線的是我有的問(wèn)題，你都有哪些？
經(jīng)過(guò)這半年的使用，WTP在我們組內(nèi)已經(jīng)從只用于開(kāi)發(fā)Web Service的工具變成web開(kāi)發(fā)的首選插件
雖然只是0.7版，但WTP的設(shè)計(jì)確實(shí)很好，目前WTP1.0已經(jīng)release到了M9，還有20幾天就到達(dá)release date了，熱烈期待中....
在ESB中另外一個(gè)重要的課題就是Message Endpoint，這是關(guān)于一個(gè)應(yīng)用程序如何連接到一個(gè)消息系統(tǒng)，并通過(guò)它來(lái)發(fā)送和接收消息。如果你在面向一個(gè)消息API編程，則你就正在開(kāi)發(fā)一個(gè)endpoint代碼。商業(yè)中間件通常都提供了這些工具。
l Messaging Gateway
l Messaging Mapper
l Transactional Client
l Polling Consumer
l Event-Driven Consumer
l Competing Consumers
l Message Dispatcher
l Selective Consumer
l Durable Subscriber
l Idempotent Receiver
l Service Activator
發(fā)送和接收模式
有些endpoint模式既可以使用在發(fā)送方也可以使用在接受方。它們描述一個(gè)應(yīng)用連接一個(gè)消息系統(tǒng)的一般情況。
包裝消息代碼 － 一個(gè)應(yīng)用不應(yīng)該意識(shí)到正在使用消息同另外一個(gè)應(yīng)用程序通訊，大多數(shù)應(yīng)用代碼應(yīng)該在不知道message的情況下被編寫(xiě)。在應(yīng)用集成的地方，應(yīng)該有一個(gè)薄薄的一層代碼來(lái)執(zhí)行應(yīng)用的集成部分。當(dāng)集成是由消息實(shí)現(xiàn)的，這層將應(yīng)用連接到消息系統(tǒng)的代碼稱為一個(gè)Message Gateway
數(shù)據(jù)轉(zhuǎn)換 － 當(dāng)發(fā)送者和接受者使用不同的數(shù)據(jù)格式，或者不同的消息格式（支持不同的發(fā)送和接收者），在這種情況下，使用一個(gè)Message Mapper來(lái)在應(yīng)用格式和消息格式之間轉(zhuǎn)換數(shù)據(jù)。
外部控制的事務(wù) － 消息系統(tǒng)在內(nèi)部和外部使用事務(wù)，默認(rèn)的，每個(gè)發(fā)送和接收方法在他們自己的事務(wù)中運(yùn)行。Message生產(chǎn)者和消費(fèi)者應(yīng)可選的使用一個(gè)Transactional Client來(lái)控制事務(wù)，當(dāng)你需要將幾個(gè)消息一起發(fā)送伙通過(guò)其他事務(wù)服務(wù)整理消息時(shí)是很有用的。
消息消費(fèi)者模式
其他endpoint模式只適用于消息消費(fèi)者，發(fā)送消息是簡(jiǎn)單的。棘手的問(wèn)題是決定一個(gè)消息應(yīng)該何時(shí)發(fā)送，它應(yīng)包含什么，以及怎樣將它送到接受者 － 這是為什么我們有很多消息結(jié)構(gòu)模式 － 但是一旦消息被構(gòu)建，發(fā)送它是很容易的。另一方面，接收消息 － 很麻煩。因此許多endpoint模式是關(guān)于接收消息的。
接收消息的一個(gè)最重要的主題就是流量控制：一個(gè)應(yīng)用控制，或者調(diào)節(jié)它消費(fèi)消息的速度。一個(gè)潛在的問(wèn)題是任何server都面臨著大量的客戶端請(qǐng)求會(huì)使其超載。通過(guò)遠(yuǎn)程過(guò)程調(diào)用（RPI），server幾乎受到客戶端調(diào)用的支配。同樣的，通過(guò)消息，server不能控制客戶端發(fā)送請(qǐng)求的速度 － 但是server可是控制它處理這些請(qǐng)求的速度。應(yīng)用不必像消息系統(tǒng)傳送消息那么快的接收并處理消息；使用一個(gè)Message Channel可以使它在一個(gè)可接收的速率上處理消息。然而，當(dāng)消息積累太多，而server還有資源可以處理的更快，它可以使用同步message消費(fèi)者來(lái)加快速度。所以使用這些消息消費(fèi)者模式可以讓你的應(yīng)用將速度控制在它可以承受的范圍。
許多消息消費(fèi)者模式都是成對(duì)出現(xiàn)的，你可以任選一個(gè)使用。
同步或異步接受者 － 可以使用輪詢消費(fèi)者或一個(gè)事件驅(qū)動(dòng)消費(fèi)者。輪詢提供最好的流量控制，因?yàn)槿绻?/SPAN>server忙，則它不再繼續(xù)輪詢消息，所以message將阻塞在隊(duì)列。事件驅(qū)動(dòng)的消費(fèi)者傾向于消息到達(dá)便觸發(fā)處理，所以有可能會(huì)使server超載，但是每個(gè)消費(fèi)者每次只處理一個(gè)消息，所以限制消費(fèi)者的數(shù)量可以有效的控制消費(fèi)速度。
消息分派 vs 消息獲取 － 另外一個(gè)二選一的模式是一堆消費(fèi)者如何處理一堆消息。如果每個(gè)消費(fèi)者獲得一個(gè)消息，他們可以并行的處理消息。最簡(jiǎn)單的方法是Competing Consumers，也就是一個(gè)點(diǎn)對(duì)點(diǎn)的channel有多個(gè)消費(fèi)者。每個(gè)都可能獲得任何消息；消息系統(tǒng)的實(shí)現(xiàn)決定那個(gè)消費(fèi)者獲得消息。如果你想控制消息到消費(fèi)者的匹配過(guò)程，使用Message Dispatcher。這時(shí)只有一個(gè)消費(fèi)者接收消息，但是將委派消息到一個(gè)執(zhí)行者去處理。一個(gè)應(yīng)用程序可以通過(guò)限制消費(fèi)者或執(zhí)行者的數(shù)量來(lái)控制流量。當(dāng)然，分派者Message Dispatcher也可以實(shí)現(xiàn)一個(gè)流量控制行為。
接收所有消息或者過(guò)濾 － 默認(rèn)的，任何到達(dá)一個(gè)Message Channel的消息對(duì)于監(jiān)聽(tīng)著這個(gè)channel的Message Endpoint都是可用的。然而有些消費(fèi)者并不打算處理channel上的任何消息，而是希望只處理其中幾種。這樣一個(gè)識(shí)別的消費(fèi)者可以使用一個(gè)Selective Consumer來(lái)描述它將接收什么類型的消息。然后消息系統(tǒng)將只將匹配的消息對(duì)該接受者描述為可用。
當(dāng)斷開(kāi)連接的時(shí)候訂閱消息 － Publish-Subscribe Channels帶來(lái)的問(wèn)題是，如果一個(gè)消費(fèi)者感興趣一個(gè)channel，但是現(xiàn)在網(wǎng)絡(luò)是斷開(kāi)的怎么辦？是不是一個(gè)未連接的應(yīng)用將錯(cuò)過(guò)發(fā)布的消息，即使它已經(jīng)訂閱過(guò)該消息?默認(rèn)的，是的，訂閱只對(duì)連接的訂閱者有效，為了使應(yīng)用不會(huì)因?yàn)檫B接而錯(cuò)過(guò)訂閱的消息，要使用Durable Subscriber。
等冪 － 有時(shí)一個(gè)消息可能被傳輸不只一次，可能因?yàn)橄⑾到y(tǒng)不確定該消息是否已經(jīng)被成功的傳遞過(guò)，或者可能因?yàn)?/SPAN>Message Channel的QoS被設(shè)置較低來(lái)提高效率。另一面的，消息接受者認(rèn)為每個(gè)消息只會(huì)被傳輸一次，并且當(dāng)它們重復(fù)處理相同的消息，它們會(huì)出錯(cuò)。一個(gè)Idempotent Receiver可以優(yōu)雅的處理重復(fù)的消息，并且阻止它們引起接收者應(yīng)用的發(fā)生錯(cuò)誤。
同步或異步服務(wù) － 另外一個(gè)選擇是一個(gè)應(yīng)用應(yīng)該暴露它的service為同步（RPI）還是異步的（Messaging）。不同的客戶端可能喜歡不同的方式；不同的環(huán)境可能需要不同的方式。既然很難選擇，就一起使用。一個(gè)Service Activator連接一個(gè)Message Channel到一個(gè)應(yīng)用的同步服務(wù)以便當(dāng)一個(gè)消息被接收，service就被調(diào)用。同步客戶端可以簡(jiǎn)單的直接調(diào)用service；異步客戶端可以通過(guò)發(fā)送消息調(diào)用service。
Message Endpoint的相關(guān)主題
Message Endpoint的另外一個(gè)重要主題是很難同其他模式共同應(yīng)用Transactional Client。Event-Driven Consumer通常不能適當(dāng)?shù)脑谕獠靠刂剖聞?wù)，Message Dispatcher也必須小心的設(shè)計(jì)這個(gè)問(wèn)題，Competing Consumers的事務(wù)也是個(gè)重大問(wèn)題。最安全的使用Transactional Client是使用一個(gè)單獨(dú)的Polling Consumer，但是這不會(huì)是一個(gè)令人滿意的解決方案。
這里特別要提到應(yīng)該會(huì)保證成功的JMS風(fēng)格的MDB，EJB的一種。一個(gè)MDB是一個(gè)消息消費(fèi)者，它即使一個(gè)Event-Driven Consumer又是一個(gè)支持J2EE分布式事務(wù)的Transactional Client，并且它可以作為Competing Consumers動(dòng)態(tài)的池化，甚至作為一個(gè)Publish-Subscribe Channel。這是在一個(gè)自由的應(yīng)用中實(shí)現(xiàn)這些是一個(gè)困難且乏味的組合，但是這個(gè)功能作為一個(gè)EJB容器的內(nèi)建的功能被提供。（MDB框架如何實(shí)現(xiàn)的？本質(zhì)上，容器通過(guò)一個(gè)動(dòng)態(tài)改變大小的可重用的執(zhí)行者的線程池來(lái)實(shí)現(xiàn)了一個(gè)Message Dispatcher，在那里每個(gè)執(zhí)行者自己使用自己的session和事務(wù)來(lái)消費(fèi)消息。）
最后，緊記一個(gè)單獨(dú)的Message Endpoint可以很好結(jié)合幾個(gè)不同的模式。一組Competing Consumers可以被作為Polling Consumers實(shí)現(xiàn)，同時(shí)也可以是一個(gè)Selective Consumers并且可以作為一個(gè)Service Activator調(diào)用一個(gè)應(yīng)用的service。
一個(gè)Message Dispatcher可以是一個(gè)Event-Driven Consumer和一個(gè)使用Messaging Mapper的一個(gè)Durable Subscriber。無(wú)論一個(gè)endpoint實(shí)現(xiàn)什么模式，它總是一個(gè)Messaging Gateway。所以，不要考慮使用哪種模式 － 而要考慮如何結(jié)合他們。這是使用模式解決問(wèn)題的魅力所在。
要實(shí)現(xiàn)一個(gè)Message Endpoint有很多選擇。Message Endpoint模式用于解釋這些選擇是什么以及如何最好的使用它們。
通常，通過(guò)消息系統(tǒng)集成的應(yīng)用很少有同樣的消息格式。比如說(shuō)，一個(gè)帳務(wù)系統(tǒng)同一個(gè)CRM系統(tǒng)對(duì)客戶對(duì)象是有著不同的概念的。基于這個(gè)，一個(gè)系統(tǒng)可能將消息存儲(chǔ)在關(guān)系表中，另一個(gè)可能存儲(chǔ)在文件中。集成已存在的系統(tǒng)通常意味著我們沒(méi)有修改系統(tǒng)以便使他們更好的一起工作的自由。然而，集成方案不得不協(xié)調(diào)和解決各種系統(tǒng)之間的不同。Message Translator模式提供了一個(gè)通用的解決方案。這里解釋幾種特定的Message Translator。
Message Transformation包含以下幾種模式：
l Envelope Wrapper
l Content Enricher
l Content Filter
l Claim Check
l Normalizer
l Canonical Data Model
大多數(shù)消息系統(tǒng)放置特定的需求在消息頭的格式和內(nèi)容中。我們包裝有效數(shù)據(jù)到一個(gè)Envelope Wrapper中以適應(yīng)消息基礎(chǔ)設(shè)施的需求。如果消息需要穿過(guò)不同的消息基礎(chǔ)設(shè)施，可以結(jié)合多個(gè)Envelope Wrapper。
如果原始系統(tǒng)不能提供目標(biāo)系統(tǒng)需要的數(shù)據(jù)域，可以使用一個(gè)Content Enricher。它可以查找缺少的信息并從已有數(shù)據(jù)中計(jì)算出它。Content Filter正好相反，它從消息中刪除不需要的數(shù)據(jù)。Claim Check也從消息中刪除數(shù)據(jù)，但是它將存儲(chǔ)他們以便以后取回。Normalizer將多個(gè)不同格式的消息翻譯成統(tǒng)一格式。
消除依賴
消息轉(zhuǎn)換在集成中是一個(gè)很深的話題。Message Channels和Message Routers可以通過(guò)消除應(yīng)用必須知道另外一個(gè)應(yīng)用的位置的需求從而解除應(yīng)用間的基本依賴。
一個(gè)應(yīng)用可以發(fā)送一個(gè)消息到Message Channel而不必?fù)?dān)心誰(shuí)來(lái)取出消息。然而消息格式增加了另外一種依賴。如果一個(gè)應(yīng)用不得不將消息格式化成另外一個(gè)應(yīng)用的數(shù)據(jù)格式，通過(guò)Message Channel解耦的說(shuō)法就像一個(gè)幻想。接收系統(tǒng)的任何改變或切換到另外一個(gè)接收系統(tǒng)都需要對(duì)發(fā)送應(yīng)用進(jìn)行改變。Message Translators可以幫助除去這種依賴。
元數(shù)據(jù)管理
將消息從一個(gè)消息格式轉(zhuǎn)換到另一個(gè)格式需要操作元數(shù)據(jù) － 描述數(shù)據(jù)格式的數(shù)據(jù)。
元數(shù)據(jù)在兩個(gè)并行系統(tǒng)之間的集成中扮演著非常重要的角色。一個(gè)處理實(shí)際的消息數(shù)據(jù)，另外一個(gè)處理元數(shù)據(jù)。許多用于處理消息數(shù)據(jù)的模式也同樣可以管理元數(shù)據(jù)。比如說(shuō)，Channel Adapter不僅可以從一個(gè)系統(tǒng)中移進(jìn)和移出消息，還可以從一個(gè)外部應(yīng)用中獲取元數(shù)據(jù)，并將其加載到一個(gè)元數(shù)據(jù)倉(cāng)庫(kù)中。使用這個(gè)倉(cāng)庫(kù)，集成開(kāi)發(fā)者可以定義應(yīng)用元數(shù)據(jù)與Canonical Data Model.之間的轉(zhuǎn)換。
元數(shù)據(jù)集成
舉例來(lái)說(shuō)，上面的圖描述了兩個(gè)需要交換客戶信息的應(yīng)用的集成。每個(gè)系統(tǒng)的客戶數(shù)據(jù)的定義稍有不同。從A到B的消息需要轉(zhuǎn)換一下才能被B接收。如果Channel Adapters可以抽取元數(shù)據(jù)的話，創(chuàng)建一個(gè)轉(zhuǎn)換將非常簡(jiǎn)單。然后這個(gè)元數(shù)據(jù)可以被放入一個(gè)倉(cāng)庫(kù)，大大的簡(jiǎn)化了Message Translator的配置和驗(yàn)證。元數(shù)據(jù)可以被存儲(chǔ)成不同的格式。通常XML消息使用XSD格式。其他EAI工具實(shí)現(xiàn)所有元數(shù)據(jù)格式，但是允許管理員導(dǎo)入或?qū)С龅狡渌袷健?/SPAN>
消息系統(tǒng)外的數(shù)據(jù)轉(zhuǎn)換
這些轉(zhuǎn)換模式組成的很多原則可以被應(yīng)用于非消息集成。比如說(shuō)，File Transfer可以執(zhí)行系統(tǒng)間的轉(zhuǎn)換工作。類似的，Remote Procedure Invocation必須使請(qǐng)求使用要調(diào)用的service的格式，即使應(yīng)用本身的格式可能不同。典型的，需要調(diào)用程序來(lái)執(zhí)行轉(zhuǎn)換。一些最成熟的轉(zhuǎn)換引擎組成了ETL工具，比如Informatica或者DataMirror。這些工具一般都一次轉(zhuǎn)換大量的數(shù)據(jù)，而不是轉(zhuǎn)換單個(gè)消息。
Message System應(yīng)專注于幾種基本的Message Translator模式。而不應(yīng)該關(guān)心實(shí)體間結(jié)構(gòu)轉(zhuǎn)換的細(xì)節(jié)（不同的數(shù)據(jù)模型之間的轉(zhuǎn)換，比如ER模型不支持多對(duì)多關(guān)系而其他的支持這種）。關(guān)于這個(gè)主題最老也使最相關(guān)的書(shū)是Kent的《Data and Reality》。
在前面的關(guān)鍵組件中我們提到了Messages。當(dāng)兩個(gè)應(yīng)用想要交換數(shù)據(jù)，他們將數(shù)據(jù)包裝在一個(gè)message中。但是一個(gè)Message Channel不能傳輸原始數(shù)據(jù)，它只能傳輸包含在一個(gè)message中的數(shù)據(jù)（即傳輸特定格式的數(shù)據(jù)）。
Message在消息系統(tǒng)中處于信息載體的位置，而在ESB中，還消息識(shí)別、序列以及生存周期等職責(zé)。
Message的結(jié)構(gòu)涉及以下幾個(gè)模式：
l Command Message
l Document Message
l Event Message
l Request-Reply
l Return Address
l Correlation Identifier
l Message Sequence
l Message Expiration
l Format Indicator
創(chuàng)建和發(fā)送一個(gè)Message產(chǎn)生以下幾個(gè)問(wèn)題：
消息意圖 － Message最終是為了運(yùn)送一些數(shù)據(jù)，但是發(fā)送者可能有其他目的，比如它希望接受者使用消息做些事情。它可以發(fā)送一個(gè)Command Message，指定它希望調(diào)用的接受者上的函數(shù)或方法。發(fā)送者告訴接受者運(yùn)行那些代碼。發(fā)送者可以發(fā)送一個(gè)Document Message來(lái)傳送它的數(shù)據(jù)結(jié)構(gòu)到接受者。發(fā)送者發(fā)送數(shù)據(jù)到接受者，但是不指定接受者應(yīng)該做什么。
或者它可以發(fā)送一個(gè)Event Message，通知接受者發(fā)送者那里有一個(gè)改變。發(fā)送者不應(yīng)告訴接受者應(yīng)該怎樣適應(yīng)這個(gè)改變，而只應(yīng)提供通知。
返回一個(gè)應(yīng)答 － 當(dāng)一個(gè)應(yīng)用發(fā)送一個(gè)消息，它通常期望得到一個(gè)回應(yīng)來(lái)確定消息被處理并提供一個(gè)結(jié)果。這是一個(gè)Request-Reply場(chǎng)景。Request通常是一個(gè)Command Message，而應(yīng)答是一個(gè)包含返回值或異常的Document Message。請(qǐng)求者應(yīng)該在請(qǐng)求中指定一個(gè)Return Address來(lái)告訴應(yīng)答者使用哪個(gè)通道來(lái)傳回應(yīng)答。請(qǐng)求者可能在一個(gè)處理過(guò)程中發(fā)送多個(gè)請(qǐng)求，所以應(yīng)答應(yīng)該包含一個(gè)Correlation Identifier來(lái)指出這個(gè)應(yīng)答對(duì)應(yīng)哪個(gè)請(qǐng)求。
有兩個(gè)Request-Reply場(chǎng)景需要注意；它們都包含了一個(gè)Command Message請(qǐng)求和一個(gè)對(duì)應(yīng)的Document Message應(yīng)答。在第一個(gè)場(chǎng)景中，Message RPC，請(qǐng)求不但要調(diào)用應(yīng)答者的函數(shù)，而且期望一個(gè)返回值。這是RPC。另一個(gè)場(chǎng)景中，Message Query，請(qǐng)求者執(zhí)行一個(gè)查詢；應(yīng)答者執(zhí)行查詢并在應(yīng)答中返回結(jié)果。這是遠(yuǎn)程查詢。
大量的數(shù)據(jù) － 有時(shí)應(yīng)用想要傳送大量的數(shù)據(jù)結(jié)構(gòu)，放入一個(gè)單獨(dú)的message里面不是很合適。在這種情況下，將他們分解成可管理的消息塊并將他們作為Message Sequence發(fā)送。這些消息必須按順序發(fā)送，以便接受者能夠充足原始數(shù)據(jù)結(jié)構(gòu)。
慢速消息 － 消息系統(tǒng)的一個(gè)問(wèn)題是發(fā)送者通常不知道接受者要多久才能接受到消息。然而，消息的內(nèi)容可能是時(shí)間敏感的，所以如果消息在某一時(shí)間內(nèi)沒(méi)有被接受，它將被忽略并取消。在這種情況下，sender應(yīng)該使用Message Expiration來(lái)指定一個(gè)到期時(shí)間。如果消息系統(tǒng)在規(guī)定時(shí)間內(nèi)無(wú)法傳輸一個(gè)消息，應(yīng)該將它取消并刪除到Dead Letter Channel中。同樣的一個(gè)receiver接受到一個(gè)超出該時(shí)間點(diǎn)的消息，也要取消該消息。
總之，只選擇使用消息是不夠的。使一個(gè)消息工作的其他決定性因素來(lái)自于消息所要完成的任務(wù)。
在前面一個(gè)專題中，我們列出了一個(gè)ESB系統(tǒng)所需要關(guān)心的所有方面的關(guān)鍵組件，這里介紹其中的Message Channels所關(guān)注的問(wèn)題及相關(guān)的模式。
Message Channel主題之下包含以下模式，分別用于解決channel中不同方面的問(wèn)題：
l Point-to-Point Channel
l Publish-Subscribe Channel
l Datatype Channel
l Invalid Message Channel
l Dead Letter Channel
l Guaranteed Delivery
l Channel Adapter
l Messaging Bridge
l Message Bus
當(dāng)兩個(gè)應(yīng)用需要交換數(shù)據(jù)，它們通過(guò)連接兩端的channel來(lái)發(fā)送數(shù)據(jù)。發(fā)送的應(yīng)用可能不知道哪個(gè)應(yīng)用將接受數(shù)據(jù)。然而，通過(guò)選擇特定的channel來(lái)發(fā)送，發(fā)送者知道接受者將是守候在channel另一端等待數(shù)據(jù)的應(yīng)用之一。通過(guò)這種方式，生產(chǎn)數(shù)據(jù)的應(yīng)用有了一個(gè)同數(shù)據(jù)消費(fèi)者通訊的途徑。
Message Channels面對(duì)的各個(gè)主要問(wèn)題：
如果一個(gè)應(yīng)用要傳輸或接受數(shù)據(jù)，它一定會(huì)用到一個(gè)channel。問(wèn)題是你的應(yīng)用要知道要使用什么樣的channel，以及用它來(lái)做什么。
固定的channel集合 － Channel中討論的一個(gè)主題是，一個(gè)應(yīng)用可用的Message Channel集合一般是固定的。設(shè)計(jì)一個(gè)應(yīng)用時(shí)，一個(gè)開(kāi)發(fā)者必須知道將某種類型的數(shù)據(jù)放到哪里可以同其他應(yīng)用共享該數(shù)據(jù)，以及從什么地方可以找到其他應(yīng)用的特定數(shù)據(jù)。這些通訊路徑不會(huì)在運(yùn)行期動(dòng)態(tài)的創(chuàng)建和發(fā)現(xiàn)；它們需要在設(shè)計(jì)期間就確定下來(lái)，以便應(yīng)用知道它的數(shù)據(jù)從哪里來(lái)以及數(shù)據(jù)將去哪里。（ 雖然大多數(shù)channel必須被靜態(tài)定義使正確的，但是也有例外，有些情況下動(dòng)態(tài)channel是很好用的。一個(gè)例外就是Request-Reply模式中的reply channel。請(qǐng)求者可以創(chuàng)建或者獲得一個(gè)應(yīng)答者不知道的新的channel，并在請(qǐng)求消息中指定該channel為Return Address，應(yīng)答者就可以使用它。另外一個(gè)例外是支持集成channels的消息系統(tǒng)實(shí)現(xiàn)。一個(gè)接受者可以訂閱一個(gè)集成體系的根channel，然后發(fā)送者可以發(fā)布消息到一個(gè)子channel，而接受者不需要知道子channel，仍然會(huì)收到消息。這些都是不常見(jiàn)的情況，channel通常仍然是在部署之前被定義，并且應(yīng)用被設(shè)計(jì)連接到一個(gè)已知的channel集合 ）。
決定channel的集合 － 一個(gè)相關(guān)的主題是，誰(shuí)決定那些Message Channel是可用的 － message系統(tǒng)還是應(yīng)用程序？換句話說(shuō)，是由消息系統(tǒng)確定一些channel，然后要求應(yīng)用程序使用它們？還是應(yīng)用決定它們需要什么channel，然后要求消息系統(tǒng)提供它們？這個(gè)問(wèn)題沒(méi)有一個(gè)簡(jiǎn)單的答案，設(shè)計(jì)必須的channel集合是迭代的。首先，應(yīng)用要決定消息系統(tǒng)提供哪些channel。然后應(yīng)用將圍繞這些channel設(shè)計(jì)它們的通訊，但是如果這樣是不可行的，它們將需要添加額外的channel。當(dāng)一些應(yīng)用已經(jīng)使用了一個(gè)確定的channel集合，當(dāng)加入新的應(yīng)用，它們將使用已存在的channel。當(dāng)為應(yīng)用添加新的功能，它們需要新的channel。
單向channel － 另外一個(gè)經(jīng)常引起混淆的是一個(gè)Message channel是單向的還是雙向的。技術(shù)上來(lái)說(shuō)，兩者都不是，一個(gè)channel更像是一個(gè)桶，一個(gè)應(yīng)用放入數(shù)據(jù)，另外一個(gè)應(yīng)用從中取出數(shù)據(jù)。但是由于數(shù)據(jù)是放在消息中從一個(gè)應(yīng)用傳到另一個(gè)，這使得channel具有方向性，使它變成單向的。如果一個(gè)channel是雙向的，應(yīng)用將從中發(fā)送和接受數(shù)據(jù)，雖然技術(shù)上是可行的，但是會(huì)有小小的問(wèn)題，應(yīng)用將有可能持續(xù)的取出自己放進(jìn)去的希望發(fā)送給其他應(yīng)用的消息。所以，為了實(shí)踐性的目的，channel是單向的。作為結(jié)論，兩個(gè)應(yīng)用如果有雙向通訊，它們需要兩個(gè)channel，每個(gè)方向一個(gè)。
如何使用Message channels：
現(xiàn)在我們來(lái)討論以下如何使用channel。
一對(duì)一或者一對(duì)多 － 當(dāng)你的應(yīng)用共享一些數(shù)據(jù)，你希望只將它共享給一個(gè)應(yīng)用還是對(duì)它感興趣的所有應(yīng)用？要傳送數(shù)據(jù)到一個(gè)單獨(dú)的應(yīng)用，使用Point-to-Point Channel。這并不意味著發(fā)送到這個(gè)channel的每個(gè)數(shù)據(jù)都發(fā)送給同樣的接受者，因?yàn)橐粋€(gè)channel可能有多個(gè)接受者。它意味著，實(shí)際上，保證每個(gè)數(shù)據(jù)都被同一個(gè)應(yīng)用接收。如果你想讓所有接收應(yīng)用都能接收數(shù)據(jù)，使用Publish-Subscribe Channel。當(dāng)你通過(guò)這種方式發(fā)送數(shù)據(jù)，channel將高效的復(fù)制數(shù)據(jù)到每一個(gè)接收者。
什么類型的數(shù)據(jù) － 任何內(nèi)存中的數(shù)據(jù)都有一個(gè)類型。另一方面，所有數(shù)據(jù)都是一些bytes集合。消息系統(tǒng)工作同這類似，消息內(nèi)容必須符合某些類型以便接受者了解數(shù)據(jù)的結(jié)構(gòu)。Datatype Channel認(rèn)為在一個(gè)channel中的數(shù)據(jù)必須擁有同樣的類型。這也是為什么消息系統(tǒng)需要很多channel的主要原因（每個(gè)channel一種格式）。如果數(shù)據(jù)可以是任意的格式，那么消息系統(tǒng)在兩個(gè)應(yīng)用之間只需要兩條channel。
無(wú)效的和過(guò)期的消息 － 消息系統(tǒng)可以確定消息被正確的傳輸，但是它不能保證接受者知道如何處理它。接收者對(duì)數(shù)據(jù)格式和意義存在期望。當(dāng)它接收到一個(gè)不符合期望的消息，它什么也不能做。它們能作的，就是將這個(gè)陌生的消息放入到一個(gè)特別設(shè)計(jì)的Invalid Message Channel并希望某些監(jiān)控這個(gè)channel的工具能夠取出這個(gè)消息，并指出該如何處置它們。許多消息系統(tǒng)有一個(gè)類似的內(nèi)建特征，一個(gè)Dead Letter Channel，用來(lái)存放成功送出但卻無(wú)法成功投遞的消息。另外，一個(gè)系統(tǒng)管理工具應(yīng)該監(jiān)視Dead Letter Channel并且決定如何處置這些無(wú)法投遞的消息。
故障檢測(cè) － 如果一個(gè)消息系統(tǒng)發(fā)生故障或停機(jī)維護(hù)，它的消息會(huì)怎樣？當(dāng)它重啟并重新運(yùn)行，它的消息能否還在它的channel中？默認(rèn)的：不會(huì)；channel將消息存儲(chǔ)在內(nèi)存中。然而，Guaranteed Delivery將channel持久化以便將它們的消息存儲(chǔ)到硬盤(pán)上。這會(huì)影響效率，但會(huì)使消息更加可靠，即使消息系統(tǒng)是不可靠的。
非消息客戶端 － 如果一個(gè)應(yīng)用不能連接到一個(gè)消息系統(tǒng)但是仍然想要參與消息怎么辦？通常它只能自認(rèn)倒霉了，但是如果消息系統(tǒng)可以通過(guò)某種方式連接到應(yīng)用系統(tǒng) － 通過(guò)它的用戶界面，它的service API，它的數(shù)據(jù)庫(kù)，或者一個(gè)TCP/IP或HTTP這樣的網(wǎng)絡(luò)連接 － 那么消息系統(tǒng)可以使用一個(gè)Channel Adapter。這允許你連接到一個(gè)或多個(gè)連接到應(yīng)用的channel而不必改變應(yīng)用或者可能也不需要一個(gè)同應(yīng)用運(yùn)行在同一個(gè)機(jī)器上的消息客戶端。有時(shí)‘非消息客戶端’真的是一個(gè)消息客戶端，但是只有連接的是其他消息系統(tǒng)的時(shí)候。
通訊中樞 － 隨著越來(lái)越多的企業(yè)應(yīng)用系統(tǒng)連接到消息系統(tǒng)以便通過(guò)消息暴露他們的功能，消息系統(tǒng)變成了企業(yè)中一站式功能的集散地。一個(gè)應(yīng)用只需簡(jiǎn)單的知道用哪個(gè)channel來(lái)請(qǐng)求功能，以及從哪個(gè)監(jiān)聽(tīng)結(jié)果。消息系統(tǒng)本質(zhì)上變成一個(gè)消息總線，一個(gè)提供所有企業(yè)應(yīng)用甚至變化中的應(yīng)用和功能的中樞。你可以更快速的集成。
如你所見(jiàn)，使用消息構(gòu)建應(yīng)用不僅僅是將他們連接到消息系統(tǒng)并發(fā)送消息。消息必須使用Message Channel來(lái)發(fā)送。Channel必須被設(shè)計(jì)為某個(gè)目的服務(wù)，比如基于被共享的數(shù)據(jù)類型，共享數(shù)據(jù)的應(yīng)用類型，和接收數(shù)據(jù)的應(yīng)用。
企業(yè)集成有很多種模式，隨著技術(shù)的發(fā)展，實(shí)時(shí)的、面向消息的企業(yè)集成越來(lái)越成為主流，面向消息的企業(yè)集成的穩(wěn)定性和兼容性要求其基礎(chǔ)件，也就是message系統(tǒng)必須提供足夠強(qiáng)壯和可擴(kuò)展的設(shè)計(jì)，下面幾種是作為面向消息的企業(yè)集成的基礎(chǔ)件所必須提供的幾個(gè)關(guān)鍵性組件。
消息集成使得message系統(tǒng)負(fù)責(zé)轉(zhuǎn)換兩個(gè)應(yīng)用之間的數(shù)據(jù)格式，從而使得應(yīng)用可以專注于他們需要共享什么數(shù)據(jù)而不是如何共享它們。
以下這些組件，在著名的ESB系統(tǒng)Mule中都可以見(jiàn)到，有興趣的同學(xué)可以去看看Mule的源代碼，雖然Mule對(duì)ESB的實(shí)現(xiàn)有很多不成熟的地方，以至于讓我不敢在生產(chǎn)系統(tǒng)中使用（唉...可恨的Mule），但是畢竟是一個(gè)大而全的系統(tǒng)，值得借鑒一下。
Channels — Messaging應(yīng)用通過(guò)一個(gè)Message Channel傳送數(shù)據(jù)，一個(gè)sender到receiver的虛擬管道。一個(gè)新安裝的消息系統(tǒng)默認(rèn)不包含任何channel；你必須知道你的應(yīng)用需要怎樣通訊，然后才能建立channel來(lái)完成它。
Messages — Message是在channel上傳輸?shù)牟豢煞指畹陌Ｒ虼耍瑸榱藗鬏敂?shù)據(jù)，應(yīng)用必須將數(shù)據(jù)打包成一個(gè)或多個(gè)packets，將每個(gè)packet包裝成一個(gè)message，然后將其傳輸?shù)揭粋€(gè)channel。同樣的，一個(gè)receiver應(yīng)用在接受到message后必須從message中提取出數(shù)據(jù)才能使用。Message系統(tǒng)應(yīng)該能重復(fù)的傳輸message，直到它成功為止。
Pipes and Filters — 最簡(jiǎn)單的情況下，message系統(tǒng)將一個(gè)消息直接從sender計(jì)算機(jī)傳送到receiver計(jì)算機(jī)。然而，通常在消息從sender中發(fā)出后，receiver接受到之前，有一些動(dòng)作需要對(duì)message執(zhí)行。舉例來(lái)說(shuō)，message也許需要驗(yàn)證或者轉(zhuǎn)換。Pipes and Filters架構(gòu)使用channel將多個(gè)處理步驟連接起來(lái)。
Routing — 在一個(gè)大型的、擁有許多不同的應(yīng)用和channel連接的企業(yè)應(yīng)用中，一個(gè)message可能需要穿過(guò)多個(gè)channel才能到達(dá)最終目的地。Message的路由如此復(fù)雜以至于最初的發(fā)送者無(wú)法知道那些channel能將message傳送給最終的receiver。因此，最初的發(fā)送者將message發(fā)送給一個(gè)Message Router，一個(gè)以Pipes and Filters架構(gòu)中的filter形式存在的應(yīng)用組件。Router將決定如何將message發(fā)送到最終receiver或者至少是下一個(gè)Router。
Transformation — 不同的應(yīng)用的數(shù)據(jù)格式可能不同。為了調(diào)節(jié)sender和receiver之間的數(shù)據(jù)格式不同的問(wèn)題，message必須經(jīng)過(guò)一個(gè)中介的filter，一個(gè)Message Translator，它將message從一個(gè)格式轉(zhuǎn)換成另外一個(gè)格式，或轉(zhuǎn)換成一個(gè)公共的格式。
Endpoints — 大多數(shù)的應(yīng)用程序沒(méi)有內(nèi)建的能力來(lái)同一個(gè)message系統(tǒng)交互。因此他們必須包含一個(gè)中間層，它知道應(yīng)用系統(tǒng)如何工作，也知道message系統(tǒng)如何工作，并橋接兩個(gè)系統(tǒng)。這個(gè)系統(tǒng)是一組并列的Message Endpoints，它能夠使得應(yīng)用發(fā)送和接受message。
System manager － 作為一個(gè)大型的消息集成系統(tǒng)，其面向消息的、異步、低耦合的本質(zhì)使得系統(tǒng)更加難以調(diào)試，運(yùn)行期的狀態(tài)也難以跟蹤，所以，我們必須有強(qiáng)有力的手段進(jìn)行系統(tǒng)的運(yùn)行期管理和監(jiān)控，同時(shí)最好能夠在運(yùn)行進(jìn)行動(dòng)態(tài)更新，以保障系統(tǒng)的強(qiáng)壯性。
企業(yè)應(yīng)用集成是一個(gè)巨大而復(fù)雜的系統(tǒng)，作為其基礎(chǔ)件ESB系統(tǒng)，必須能夠提供對(duì)其完全的支撐以及足夠強(qiáng)壯的系統(tǒng)，這正是ESB系統(tǒng)建設(shè)的難度所在。
這個(gè)動(dòng)態(tài)圖片的實(shí)現(xiàn)原理是在servlet的response中寫(xiě)入一個(gè)ImageOutputStream，并由servlet容器將其轉(zhuǎn)成圖片，在非webwork的實(shí)現(xiàn)中，可以直接操作response，但是在webwork中，要想直接操作response的output則必須使用不需要對(duì)response操作的result類型
實(shí)現(xiàn)一個(gè)Result：
不可以用普通的dispatcherResult在response的outputStream中寫(xiě)入東西，否則將覆蓋所有的dispatcher的jsp頁(yè)面
上次的代碼忘記加上response的設(shè)置不緩存了，這樣即使使用IE的回退也會(huì)刷新圖片
private HttpSession session;
/**
* @see com.opensymphony.webwork.dispatcher.WebWorkResultSupport#doExecute(java.lang.String,
* com.opensymphony.xwork.ActionInvocation)
*/
@Override
protected void doExecute(String finalLocation, ActionInvocation invocation) throws Exception
{
HttpServletRequest request = (HttpServletRequest) invocation.getInvocationContext().get(
ServletActionContext.HTTP_REQUEST);
HttpServletResponse response = (HttpServletResponse) invocation.getInvocationContext().get(
ServletActionContext.HTTP_RESPONSE);
response.setHeader("Pragma", "No-cache");
response.setHeader("Cache-Control", "no-cache");
response.setDateHeader("Expires", 0);
VerifyImage verify = new VerifyImage();
OutputStream os = response.getOutputStream();
String str = verify.GetImage(os);
session = request.getSession(true);
session.setAttribute("rand", str);
}
在xwork.xml中配置result-type：
<result-types>
<result-type name="image"
class="com.bnt.afp.action.verify.ImageResult"/>
</result-types>
添加一個(gè)生成圖片的action：
<action name="imageAction"
class="com.bnt.afp.action.verify.ImageAction">
<result name="success" type="image"/>
</action>
在需要生成驗(yàn)證圖片的地方這樣調(diào)用：
<img border=0 src="imageAction.action">
ImageAction里只要簡(jiǎn)單的返回SUCCESS就可以了
public String execute() throws IOException
{
return SUCCESS;
}
VerifyImage中生成圖片的方法：（來(lái)自網(wǎng)上一個(gè)JSP生成動(dòng)態(tài)驗(yàn)證圖片的實(shí)例）
//獲取生成的圖片,返回生成的驗(yàn)證碼，并將ImageOutputStream寫(xiě)入
public String GetImage(OutputStream outputStream){
int width=60, height=20;
BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
Graphics g = image.getGraphics();
Random random = new Random();
g.setColor(getRandColor(200,250));
g.fillRect(0, 0, width, height);
g.setFont(new Font("Times New Roman",Font.PLAIN,18));
g.setColor(getRandColor(160,200));
for (int i=0;i<155;i++)
{
int x = random.nextInt(width);
int y = random.nextInt(height);
int xl = random.nextInt(12);
int yl = random.nextInt(12);
g.drawLine(x,y,x+xl,y+yl);
}
String sRand="";
for (int i=0;i<4;i++){
String rand=String.valueOf(random.nextInt(10));
sRand+=rand;
g.setColor(new Color(20+random.nextInt(110),20+random.nextInt(110),20+random.nextInt(110)));
g.drawString(rand,13*i+6,16);
}
g.dispose();
try {
ImageIO.write(image, "JPEG", outputStream);
outputStream.flush();
return sRand;
} catch (IOException e) {
e.printStackTrace();
return "fail";
}
}
public Color getRandColor(int fc,int bc){
Random random = new Random();
if(fc>255) fc=255;
if(bc>255) bc=255;
int r=fc+random.nextInt(bc-fc);
int g=fc+random.nextInt(bc-fc);
int b=fc+random.nextInt(bc-fc);
return new Color(r,g,b);
}
轉(zhuǎn)載請(qǐng)注明作者和來(lái)源.
最近登陸google，看到了google的主頁(yè)上的新軟件：Picasa2
最新！ Google 的照片管理軟件：查找、編輯和分享您計(jì)算機(jī)上的照片
下載試用了一下，感覺(jué)很不錯(cuò)，設(shè)計(jì)的很人性化，越來(lái)越覺(jué)得google在關(guān)注用戶體驗(yàn)方面不輸于MS
《秘密》
主演：小林熏 廣末涼子
－雖然每個(gè)女人都想再回到18歲，可是以這種方式回到18歲，我想她寧愿不回去。
影片簡(jiǎn)介：
◎譯 名 秘密
◎片 名 Himitsu
◎年 代 1999
◎國(guó) 家 日本
◎類 別 劇情/幻想
◎語(yǔ) 言 日語(yǔ)
◎字 幕 韓文/英文
◎IMDB評(píng)分 6.6/10 (97 votes)
◎IMDB鏈接 http://www.imdb.com/title/tt0211413
◎文件格式 XviD + AC3
◎視頻尺寸 720 x 384 (1.88 : 1)
◎文件大小 15MB x 100
◎片 長(zhǎng) 01:59:53 (119 Min
◎?qū)А ⊙荨ojiro Takita
◎主 演 Ryoko Hirosue .... Monami Sugita/Naoko Sugita
Yuriko Ishida .... Taeko Hashimoto
Hideaki Ito .... Haruki Soma
Ken Kaneko .... Fumio Kajikawa
Kayoko Kishimoto .... Naoko Sugita
小林薰 Kaoru Kobayashi .... Heisuke Sugita
大杉漣 Ren Osugi .... Hiroyuki Kajikawa
Rie Shibata .... Kazuko Yoshimoto
Tomoe Shinohara .... Kuniko Kimura
Hatsuo Yamatani .... Naoko Sugita
◎簡(jiǎn) 介
一對(duì)母女搭巴士準(zhǔn)備回老家祭祖。巴士的司機(jī)（約40～50歲的中年人）因?yàn)橐﹥鹤由蠈W(xué)所以兼職加班，因此睡眠不足，結(jié)果在路上出了車禍。由小林熏所飾演的男主角（劇中約40～45歲）經(jīng)由新聞得知太太跟女兒出了車禍，趕到醫(yī)院時(shí)，太太撐不了多久就死了，結(jié)果當(dāng)女兒清醒時(shí)，他才發(fā)現(xiàn)太太的靈魂進(jìn)入了女兒的身體。總之，就是太太的身體死了，靈魂跑到女兒的身體里，而女兒的靈魂則消失了。
當(dāng)男主角經(jīng)歷了這樣的事故之后，他不知該如何悲傷，原因是太太死的是身體，但還是藉由女兒的身體生活著，而女兒的靈魂消失了，但卻還是看的到人。那失去的到底是什么呢？
當(dāng)女主角（廣末涼子飾演）出院后便與男主角過(guò)著奇異的生活。女主角用著女兒的身體，立志幫女兒生活下去。于是便幫女兒完成了高中的學(xué)業(yè)并且考上了醫(yī)學(xué)院。在這個(gè)時(shí)間里女主角在家中依然扮演著媽媽的角色，但在外面則得假裝是自己的女兒。
男主角跟女主角的生活開(kāi)始有了摩擦。男主角無(wú)法跟女主角過(guò)著夫妻的生活，因?yàn)樗麗?ài)他的太太，他也很愛(ài)他的女兒，所以他無(wú)法跟他太太過(guò)之前的生活。而女主角上了大學(xué)之后，開(kāi)始參加社團(tuán)的活動(dòng)，而且認(rèn)識(shí)了不同的人，于是先生開(kāi)始約束太太的生活，并且私下偷聽(tīng)太太的電話與偷窺太太的私人物品。
女主角無(wú)法接受無(wú)隱私的生活，而她依然深愛(ài)著她的丈夫，然而男主角卻堅(jiān)持生活上需保持父女的關(guān)系，只有在精神上維持夫妻的關(guān)系。在這樣的情形下，深深的傷害了兩個(gè)人的生活，在一次的爭(zhēng)吵之后，女主角假裝女兒的靈魂回到了身體。于是先生快樂(lè)了起來(lái)，因?yàn)榕畠焊鷭寢層峙c他一同生活，只是后來(lái)媽媽出現(xiàn)的次數(shù)越來(lái)越少，最后媽媽終于消失了，只剩下女兒活著。
幾年后，女兒終于要結(jié)婚了，結(jié)婚的對(duì)象是當(dāng)初肇事司機(jī)的兒子。在結(jié)婚典禮完畢后父親與女兒正在話別，此時(shí)女主角不小心做了一個(gè)只有媽媽才知道的小動(dòng)作。這時(shí)男主角才發(fā)現(xiàn)女主角依然是媽媽而不是女兒，而他的太太卻嫁給了別人。這時(shí)兩個(gè)人都非常的難過(guò)，然而這卻是無(wú)法改變的事實(shí)。
Duncan's心情：
這部片子的過(guò)程中是蠻幽默的，而且劇情也很特殊。不過(guò)整片的風(fēng)格讓人有種濃郁的憂傷。到了結(jié)局，更讓人感到深深的無(wú)奈。
一開(kāi)始所思考的第一個(gè)問(wèn)題，即是女兒離開(kāi)的事實(shí)。但是到底應(yīng)如何哀傷呢？失去的是感受的靈魂而不是身體，然而人們都是用眼睛來(lái)思考，那么哀傷是如何的感覺(jué)呢？光是這個(gè)問(wèn)題就讓我思考了很久，我覺(jué)得這是一個(gè)很有想象力的假設(shè)。
第二個(gè)問(wèn)題，原本認(rèn)為兩人仍能快樂(lè)的生活下去。但是這卻突顯了時(shí)間與環(huán)境對(duì)于人們的改變。大多數(shù)的人們都恐懼改變，由于女主角變換了身體，所以生活有了不同的變化，她再度回到學(xué)生的日子，不在是家中的主婦生活，一下子生活的視野寬闊了起來(lái)。然而男主角依然是拉面研究公司的老師，他已經(jīng)是中年人，過(guò)著一成不變的生活，他并沒(méi)有改變，然而女主角的改變卻連帶的影響了男主角的生活。所以世事都是無(wú)常的，有許多是我們無(wú)法去承諾的。
第三個(gè)問(wèn)題是愛(ài)的極限。男主角因?yàn)閻?ài)他的太太與女兒，所以事情發(fā)生后他選擇了痛苦的生活，不論是生活上或是精神上。太太也愛(ài)先生，也深愛(ài)女兒。所以最后她決定以女兒的身分生活，幫她女兒過(guò)完他無(wú)法繼續(xù)的人生。原本他選擇跟她先生一起度過(guò)，然而她先生卻再也無(wú)法快樂(lè)的生活，于是她只好真的扮演她自己的女兒，再也無(wú)法過(guò)她原本的生活，包括私人的時(shí)候。
因?yàn)閻?ài)的太深，所以突顯了生活是如此無(wú)奈。一輩子的誓約，女主角經(jīng)歷了兩次，那是多么的幸福卻又多么的殘酷。
所以愛(ài)能有多深呢？？？
愛(ài)到濃時(shí)，真的是幸福嗎？？？
推薦大家看看這部片子，尤其是感情已經(jīng)到老夫老妻境界的人，也許會(huì)有更強(qiáng)烈的感想吧！
這部片子的主題曲是「天使的嘆息」，真是貼切，所有的感想到后來(lái)便成了深深的嘆息！
|