2008年1月13日
題外話：我其實想說的是一個被人所忽視的問題。形式有沒有價值？我承認，形式化是不好的。但是這個世界有個東西，叫做儀式。
舉個例子，在國外，有種組織叫兄弟會，（電影里很常見）他們的有些會設置很多可笑的考察儀式來考察你夠不夠入會的資格。有些會有危險，有些只是純粹搞出些恐怖氣氛嚇你看你會不會被嚇退。這種東西有價值嗎？心理學告訴我們，設置準入門檻可以提高組織成員的忠誠度。如果你覺得這玩藝太可笑了，給取消掉。你會莫名其妙的發現后來加入的人對組織的認可度忠誠度都不高。這就是儀式的價值。
今天說的是Retro，全名retrospective，中文名“回顧會議”，網上有很多相關文章，就不再這里贅述了。這里提到的Retro是最常見的一種模式，分Well, Less Well, Puzzle三個維度的模式。該模式的Retro的特點是會讓我們更多的關注less well，關注我們做的不好的那些。這點有好有壞。本文只揭示它好的一面。做為補充，還有一種海星圖的模式，感興趣的人可以自己查詢。
我個人認為retro是敏捷開發中很重要的一道防線。是團隊健康度的晴雨表，是溝通的橋梁，是共識建立的契機，是改進的開始。
對于團隊本身就存在大量問題，而這些問題可能都在敏捷方法的問題域里時。Retro是一個很好的發力點。他的效果可能沒有持續集成那么立竿見影，往往是潤物細無聲。他可以幫我們把痛點暴露出來，但是不一定是根本問題。就像醫生看病也得先問你哪不舒服。而Retro就能幫團隊說出來哪不舒服并達成共識。某種意義上講，它是個報警器。
如果已經采用了大量敏捷實踐的團隊呢？比如我們團隊，在我們團隊的開發中，我們一直推進著各種改進，期望讓我們的工作更有效率，交付更多價值，同時也讓我們的生活更美好一些，這是一件雙贏的事情。 可是我們也要看到改進是需要成本的，而且也是有風險的，所以有的時候難以推動。對于客戶（ 有時是PM等內部角色）來說，他討厭一切成本和風險，而更感興趣的是新功能，當碰到短視的負責人，或者交付壓力占了上風的時候，難以推動這點感覺尤為明顯。不過商業社會里競爭如此激烈，這也無可厚非。雖然我們也知道出來混，欠下的遲早是要還的。
不過這不是我們今天討論的角度。今天我們站在推動改進的角度來看這個問題，開發時，在開發第一線的我們往往是第一個了發現開發中的問題，然后我們會發現改進最困難的是溝通，明明這是個問題，但是讓各方都接受這個問題并改進它需要證據，需要溝通，需要資源，最重要的需要時間。我曾眼睜睜得看著客戶只是加幾臺機器提升持續集成的構建效率這件事竟然推動了近一年才成功，那么在這個問題被發現但不能改進的時間里，團隊會怎樣呢？首先士氣會被打擊，接著如果問題長期不能解決并影響了工作效率，一種不愿追求卓越的氣氛會漸漸感染團隊成員，進而使得大家會在其他實踐上表現漸漸變差。（ 相對于每個人自己，而不是團隊其他成員）改進的意愿也會不同程度的變低。這符合
破窗效應。
這時候，很容易出現的一個傾向會是干脆我們不要retro了，反正也改進不了，完全是浪費時間。 這就成了自毀長城。不能干因為報警器老響就把報警器拆了的事。出來混欠下的始終要還，學鴕鳥是沒用的。當retro不能給我們提供更多實際改進價值的時候，它還能提供最后一個價值：懺悔的儀式。
曾經一直不明白西方人為什么定期去教堂懺悔，周周去，周周都有值得懺悔的，甚至犯過的錯還有很多類似的。看起來沒什么用。但這就像房間，天天打掃天天都有的打掃的，心靈的房間也是一樣。一位有信仰的朋友告訴我，定期經常向神懺悔會更愿意改進自己，如果一段時間不去對自己的要求就會放松。人的心理就是這么奇怪。這揭示了一個道理，人是會逐漸放松對自己的要求的，所以需要一種手段讓我們保持對自己的高標準。
我個人認為retro就是一個很好的手段。尤其我前面說過了，這里討論的這種Retro的模式的特點就是讓我們更關注于Less Well。定期，經常，回顧，反思。當我們無法變得更好的時候可以幫助我們反觀團隊自身，不要變得更差。讓破窗效應難以發生。
（本來只是想寫一個敏捷團隊碰到讓人沮喪的情況時Retro提供的價值，結果越寫越多，有點跑題了⋯⋯）
在我們的開發中，有些實踐的價值是容易感受到的，比如重構，比如TDD，比如持續集成。
有些實踐的價值則不容易感受到，比如Retro（回顧會議），比如IPM（迭代計劃會議）。
以IPM為例，在我們的IPM上我們一般會做兩件事Kick off cards和Estimation。也就是選擇下個迭代要做的卡和評估每張卡的點數。這兩件事情似乎第一件事沒必要所有人都參與，第二件事感覺一定程度上是瞎蒙，尤其是一群人來蒙，顯得尤為的不靠鋪。而且似乎我們IPM就是為了選出下個迭代能做完的卡，就是為了知識傳遞，就是為了給客戶可視的數據和計劃，讓他們心理好過。
假設說我們不必所有人都參與就能保證選出適合下個迭代做的卡，我們通過每日Code Review等實踐使得每個人都不會缺少相關卡的知識，而客戶也不特別在意我們的進度（或者說我們的進度他們總是滿意），是不是我們就不需要IPM了？是不是我們就不需要集體Estimation不需要集體Kick off了？
實際上，我們的項目就符合前面的假設，在項目的最后，我們真的取消了IPM。這時，才感覺出來IPM的價值。
整個團隊的效率慢慢開始下降。對于目標的理解開始不一致。雖然團隊整體的表現并不差，雖然沒有出現任何實質的問題，但容忍度低的人開始不舒服。跟團隊自己以前的狀態比，確實有點退化的感覺。怎么會這樣呢？
每當說到這種狀態出現在敏捷團隊中的時候，我最常聽到就是人的問題，態度問題等等說法。其實我一直覺得，如果追究態度，空談人的問題有用的話，我朝應該是世界第一而不是那個人人自我的美帝。人一直是有問題的，不然要管理學干什么？敏捷里提倡自組織團隊，自我管理。但決不是松散組織，不管理。自組織它也需要組織，自我管理它也是管理。像IPM這樣的活動，就是管理的一部分。
IPM上做的兩件事，看起來完全不靠鋪，實際上卻非常有價值。整個IPM活動就是一個承諾的儀式。像古代行軍打仗前的誓師大會一樣，可以調動起團隊在下一個迭代中的士氣。通過集體參與評估和制定計劃，通過各個角色的共同作用，使得每個人都參與到整個計劃制定中來。自然而然的對下一個迭代許下承諾。而承諾一旦許下，就會像一個耳語的惡魔，暗中催促著人們的行為與其保持一致。
生活在我朝的人們，似乎對承諾這個東西的效果是完全不相信的。這也難怪，不過出于眾所周知的原因，咱不談我們為啥不信任承諾。從心理學的角度，承諾是有實際意義的?！队绊懥Α?#8220;第三章 承諾和一致”中就講了這個極為簡單卻極為有用的心理學原理：人人都有一種言行一致（同時也顯得言行一致）的愿望。
其中有很多很有趣的實驗，揭示了承諾的力量。 感興趣的人推薦讀一讀。里面有個小例子提到，兩個星期前一個愿意在自家的草地上插一個小牌子為交通安全做點貢獻的小承諾，使得該社區76％的人都在兩個星期后接受了在自家草地上插一個擋風景的大牌子的請求。而對照社區只有17％。巨大的反差可以讓我們看到承諾的力量。
當然我們對承諾的不信任也是有道理的，當承諾真的難以完成的時候，幾乎所有人都會違背承諾。在傳統的瀑布式開發過程中，使得計劃這種承諾難度大大上升，而可信度也就大大下降。這也是為什么我們需要迭代的原因。
一個成功的企業需要積累。當你坐在電腦旁，看著一個運行達十年之久的軟件的源碼時，相信我，你一定會更深刻的感受到積累這個詞，確確實實是個中性詞。
軟件多種多樣的功能支撐著一個企業帝國的運轉，它源源不斷的在為這個帝國創造著財富，毫無疑問它隨著時間積累了很多掙錢的能力?？墒侨?
同歷史上其
他的帝國一樣，在繁華的背后，很多黑暗的東西同樣隨著時間積累了下來，臨時性的策略被固化在核心流程中，為擴展留下的空白成了每次擴展必須繞行的彎路，精妙的手法隨著時間的變遷顯得復雜過時，分工協作使得同樣事情得處理方式大不相同，預先的設計又使得本不相同的東西硬造成了相同的樣子，管理的疏忽使得簡單的功能用了復雜的模式實現。
坐在代碼面前，仿佛在讀一本被囚禁了靈魂的魔書，你能在注釋中讀出興奮與痛苦，你能在代碼中看到驕傲與彷徨。每當完成一次重構就像解救了一個被困的靈魂。那代碼又仿佛一個人的臉，你可以看到各個技術歷史階段在它臉上留下的歲月痕跡。暢游在代碼中，有些時候我們好像穿梭在時光的河流中，你能看到一個愚昧的風格是如何從一個有價值的需求中演變而來。如今再看，仿佛一群羊在不斷的跳過一個早已不存在的柵欄一樣詭異。而有些時候，我們只能看到一些遺跡，原野中矗立的大石柱根本無法自己告訴我們他們到底是為何矗立在那里的。以及移動他們會不會帶來什么災難。
能力很強，問題很多。是任何一個已經有歷史的公司都會有的。軟件不過是公司的一個表現方面。就像一個擁有完整公司基因的細胞。準確的說，任何時候，任何公司都不可能沒有問題的。但是何時解決？這個問題就跟什么時候重構一樣，答案也是一樣，隨時。解決問題的時機會影響解決問題的難度。越晚解決，就越難解決。說起來容易，做起來談何容易。是的，解決問題總是需要鼓勵的，但是談何容易四個字卻很容易瓦解我們前進的意志。低下頭埋到土里，是可以讓一切都清靜了。但不管我們做不做，甚至于即便我們在做，問題也永遠不會停止它產生并進化的腳步。面對問題，只有應戰，沒有第二條路可以走。經濟危機教會了很多企業只顧賺錢而忽略企業的問題會有什么后果。我相信有很多人會選擇遺忘并在遙遠的未來繼續重犯同樣的錯誤，但是我也相信，也會有很多人會選擇記住并把教訓提煉成一種知識或制度，讓后世人學會警惕。
進來聽聞最大的CMM堡壘DNV要搞敏捷。大票的獵頭紛紛出動，四處搜羅敏捷咨詢師。使敏捷這個本來只有小眾在實踐的一類開發方法陡然變得要大眾化了。本來以為是件好事。卻在昨天看到z叔大喊，敏捷要倒。當時只是覺得有點道理。晚些時候卻切身體會到了。
收到某非知名公司舉辦的scrum培訓的郵件。頓時心里一緊。在這個時間，用這個操作手法有點可怕，各培訓公司都找到了敏捷里面最好切入的一個點---Scrum。
Scrum是個筐，什么都能往里裝啊。為什么這么說呢，他并不能算是一個完整的開發方法。只是一個框架。不領會敏捷的精神，沒有其他具體的開發方法，他只能是一個大面的東西，如果用上這種東西就號稱敏捷了。那真是可怕。而且，scrum證書也在這波浪潮中量產。一個人，花幾千塊錢，上兩天的課，拿著一張紙就號稱敏捷了。沒辦法，誰讓咱們崇拜證書這種看得見摸得著的東西呢。但這樣大量量產出來的敏捷項目經理。一實踐肯定不對勁，就會用自己的理解去曲解敏捷。然后大家認為敏捷就是早晨開個會，月末開個會。最后的結果就是你在罵敏捷，我在夸敏捷，可是你嘴里的敏捷和我嘴里的敏捷根本就不是一個東西。
記得曾經見過一個CMMI的咨詢師，張口閉口卡耐基梅隆，一付兄弟當年在英國的時候的樣子。生搬硬套的CMMI流程。最后搞的那套流程根本不可操作，大家都為流程湊數據。當下如果大家都從CMMI倒向Scrum，這種人咋生存呢？會掛掉？錯，搖身一變，舉起敏捷大旗開始搖旗吶喊。沒這兩下子怎么能在忽悠界縱橫這么多年呢。像這樣的人都來搞敏捷了。敏捷不臭，那除非老天開眼了。那原來搞敏捷的人呢？本來就是小眾，在這大浪里面，估計很快就看不見了。。。。從今開始，我還是少說兩句敏捷了。。。
我習慣于在午飯后午睡一下。上班時午睡，只能是趴著睡。最近才注意到，寫字樓的空調大多是從上往下吹得，所以這個時候整個后背是暴露給空調的。從中醫上講，背上主要是兩條經絡。督脈和膀胱經。其中膀胱經主人體一身之陽氣。號稱人體最大的排毒通道。膀胱經不通的人可能會怕風怕冷，容易得濕疹等病，常年排毒不暢，可能會導致更多疾病。
體的經絡不管哪一條，都怕六邪，風濕熱火燥寒。對于處處空調的現代人，火燥熱遠不如風濕寒需要擔心。比如像這樣天天把后背暴露給空調，而且是在睡覺這種放松狀態下。就等于天天讓空調的風寒入侵膀胱經。加上很多辦公室都有加濕器。那濕也是跑不了。當然，人體自身有防御的能力，肯定不會馬上出問題的。但是天天這么搞，難免不出問題。上個禮拜加了幾天班覺得左肋靠近腋窩的地方疼。周末好一點了，今天下班前又痛了。引起我一點警惕。所謂猝死，大概就是這么一點點演變來的。干咱們這行撐不死可也別累死。
溫熱可以驅寒，我想把背緊靠一會靠背取暖。這時發覺我的椅子后背只到肩胛骨中部。好像很多公司的椅子都是這樣的，不能很好的護住背部（除了老板椅。老板椅上面似乎還要往前多出一塊來，連后脖頸子都能護住。倒是很養生。）
所以，辦公室可以放一件外衣，睡覺的時候披上來防風防寒。另外，可以偶爾的去做一些保健。比如拔罐，刮痧等?；旧媳巢堪喂蘧褪窃谑柰ò螂捉?。背部刮痧也是。不過要注意的是：
一，拔罐的話，頻率不宜過高，拔罐是排毒比較猛的一種方式，體內毒多的時候倒是在排毒，毒少了以后，排的就不只是毒了。有一種說法，拔得太頻繁反而會有損陽氣。我比較認可這種說法。一個月一次或者隔一個月一次為宜。拔罐后六個小時不能洗澡。
二，刮痧倒是可以頻繁點，但最好找干凈的地方或讓自己家人做。肉少的地方盡量少刮。最近發現一種叫魔蝎刷的東西，個人感覺比刮痧板好用，可以替代刮痧板刷背。刮痧后半小時不能洗澡。從時間上也能看出哪個比較猛。
最后，多多運動是最好的保健方法。自我鍛煉總是要勝過別人伺候。愿程序員們都能度過一個健康的夏天。
沒“貢
獻”的田鼠
在田野里，住著三只田鼠。
秋天到了，三只
田鼠開始準備過冬的東西。
第一只田鼠每天都到田野上運糧食，準備冬天食用。
第二只田鼠每天都到田野上運野草，準備冬天取
暖。
而第三只田鼠每天都跑出去游玩，對糧食和野草一點兒也不關心，好像冬天永遠也不會到來一樣。
前兩只田鼠勸它為即將到
來的冬天多準備一些必要的東西，但它只是笑笑，仍然每天都出去游玩，經常玩到天黑才回來。
寒冷的冬天很快到來了，三只田鼠住在洞里，餓了
就吃第一只田鼠運回來的糧食，冷了就用第二只田鼠運回來的野草取暖，而毫無貢獻的第三只田鼠自然也得到了前兩只田鼠的嘲笑。
然而日子一
天天地過去，每天都無所事事地待在洞里，做著同樣的游戲，吃著同樣的糧食，三只田鼠漸漸厭煩起來，感覺到了無聊的空虛。
這時，第三只田鼠
開始為前兩只田鼠講故事，講它在秋天出去游玩的時候見到的許多新鮮有趣的故事，前兩只田鼠聽得津津有味，生活開始重新變得充實而有意義。
作
為感謝和報答，前兩只田鼠經常把自己的糧食和野草挑出一些送給第三只田鼠。
原來，有些貢獻并不是從一開始就能看得出來的，然而我們卻經常
因為暫時看不到它的“用處”就舍棄了它。
這篇文章是受啟發于要求我寫一些設計和spec的文檔的面試要求。趁這個機會整理整理自己的思路。
什么是軟件開發呢，最常見的一種說法是，軟件開發是一門藝術。我覺得更現實的講，軟件開發應該是一種生產。跟其他所有的生產一樣。要考慮成本和收益。收益這塊，跟其他很多外部因素相關，對開發者或者說開發者的管理者來說無法控制，開發者從職業的角度出發更多需要考慮的是成本。這也是我們職業的目標。
軟件這種產品的生產，材料本身的損耗也就是電腦，電費，基本屬于沉沒成本。不會因為咱們任何努力而改變。（也不是完全不能改變，只能是變多。。。。）那么，最大的成本損耗在時間上。一方面，程序員都屬于高薪人士（相對，相對）。每一天的損耗都意味著大量的錢打水漂了。另一方面，隨著時間的推移，商業價值在降低，風險卻在增加。
對軟件開發來說，需求實現速度，應該說是很重要的，但是實現速度本身并不是考量的標準單位。作為最大成本考量標準的時間，從對她的消耗來看：除去簡單的功能點實現需要，需求的變化浪費的時間則更客觀。而無數實例證明，我們在需求分析階段投入時間誠然可以減少需求的變化，但是并不能達到我們滿意的高度，所以對需求變化的反應也是我們的重要標準。
敏捷這個詞，我覺得非常好。做為一門方法學，從名字上就說明了軟件開發需要關注的兩個重要的點：需求實現速度和對于需求的反應速度。當然，說到這里有點虛了。我想，回歸到不太實際的本質，能更好的指導我們的實踐。Rails框架為什么這么火熱，恰恰因為它做到了這兩點。我們想想，為什么要設計？我讀過讓人舒爽的代碼，也讀過看著讓人想吐的代碼。拋掉個人的感情因素，這兩種代碼有什么區別呢？大部分讓我想吐的代碼里出現的是一些重復的代碼，看起來稍有不同，卻不肯費點心思除掉這些“壞味道”。重復代碼的問題在哪里呢？最大的問題就是隨著代碼量的增多，工作量的與日劇增。維護量也會增大。而且，復雜度絕對不是O(n)。其實我常常覺得，我們最早學程序的時候要學算法與數據結構。其實這個課程很早就告訴了我們編程最重要的兩塊：算法，結構。好的設計就是好的結構?？蓴U展，可維護，最起碼，可以分工。
好的設計可以大量的減少代碼。減少代碼就意味著成本的降低。也就是文初說的，我們職業的目標達到了。但是現實往往不是那么美好，雖然我們有很多OO的設計模式，我們有很多最佳實踐。但是在現實中，我們往往需要妥協。一般是三個原因：性能、穩定性、各種接口，在左右著我們。其實，很多時候，這也是最考驗一個程序員的功力的地方。如何在這三個沼澤上跳舞，才是軟件開發真正可以被稱之為藝術的地方。而怎么做，則只能靠一行一行的代碼鍛煉，一篇一篇文章和文檔整理經驗，沒法一句半句說得清楚的了。
晨會是Scrum里的一個實踐。
最近才意識到，這種東西一點都不時髦。很多理發店，飯店，他們早晨都有這個。今天在大鴨梨看到他們的晨會，頗有感覺?？粗麄兌颊驹谀抢?，覺得跟站立式晨會差不多。不同的是他們的員工，年齡層比較低，處于還比較毛糙的年齡。也就是說，不僅需要教育怎么做事，還得教他們怎么做人。所以在這個晨會上，經理教育他們說，不要混日子，十年后，你們如果沒做出什么來，一生就這么過去了。跟他們說，要當面說壞話，背后說好話。也就是進行人性和行事風格上的教育，也可以說是一種文化上的教育。經理教育完，幾個像老員工的來說加單要寫名字，不要怕寫了名字會怎么著等等。雖然是端茶倒水送飯，但是需要注意的還真是不少。前臺，服務員，后廚，這之間也是需要溝通規范，任何一個溝通不符合規范，就會出亂子。
比較起來，敏捷的實踐只是要求個人說自己做過什么，要做什么，有什么問題。不過我發覺，有些話，其實是應該在晨會的時候應該強化與灌輸，不見得是每天，但是隔三差五的就該講講。關于工作態度，配合。這是員工培訓的最好時機。在這里用力，雖然不會有奇跡般的效果，但每隔一段時間肯定會有一點切實的進步。企業與企業都是不同的，有自己的氛圍，那所謂的文化，就是企業的性格。員工與員工更是不同。但是企業喜歡的員工其實都很相似。不喜歡的員工卻各有各的不同。所以企業經常培訓員工。但我是不相信給員工搞一兩次課可以改變一個人的。有天在快餐店，聽到一個老銷售教育一個新銷售說，鴨子聽鷹講怎么飛。上完課，鷹飛回家了，鴨子還是走回家的。不能飛的鴨子又不缺什么，野鴨就能飛。所以，僅僅幾天的員工培訓能改變什么呢？不能指望著幾天就能給公司制造出好用的員工來。公司對教育的重視不夠說小了是不把自己的錢當回事，說大了其實是社會責任的缺失。
你們10年后還一事無成，這是給員工灌輸的一種危機意識。要當面說壞話，背后說好話，這是對員工進行人性的教育。這像是領導說的話，有人說，領導兩個字是領袖+導師。身為導師不引導人光明磊落，就不能怪人言可畏。有喜歡以流言御人的領導才有大量到處嚼舌頭的下屬?，F代企業不是古代的官僚衙門。該專心搞的是經營而不是政治。
散會后，員工繼續去工作了。你說這個晨會有什么作用嗎？不知道，就像一顆石頭扔進了平靜的水里。一陣激蕩過后我們什么都看不到了。但是，我想，日積月累，石頭扔得多了。在你不注意的時候，水面會悄悄上升的。
敏捷作為方法學，其實還是比較虛的。哪怕是其中比較實的最佳實踐，也是非常難以掌握運用的。原因其實很簡單。人要想通過敏捷偷懶是絕對不可能的。敏捷的實施，在最初肯定是非常累的。因為改變總是痛苦的?；仡欂S田的歷史，他們在創造TPS的時候，工人們也是想把大野耐一的那些破爛東西都給砸咯。
不過很多時候，痛苦是幸福的開始。一個人完成很多人合作完成的工作，咋看起來是非常勞累的。但是習慣了，也就那樣了。TPS里面基礎就是讓一個工人具備兩項以上的技能。程序員也是一樣。不能為自己的懶惰找理由。大家都是人，都想懶，但是今天懶了，總會有一天被逼著勤快。就好像沒有時間鍛煉，就有時間生病一樣。只有每個團隊成員都變得敏捷了，敏捷的方法才有意義。
時間。。。曾經是我最害怕的東西。。。如今卻變成了最喜歡的東西。。。
這個世界紛紛擾擾有那么多的真實與虛假
只有時間能把它們分離開來。
時間，跟所有自然的偉力一樣，從來都是緩緩的，慢慢的顯示著自己的力量。
人可能等不及看到它的效果，可它卻一直履行著自己的職責
一切浮于表面的虛幻，終會在時間的侵蝕下消逝，只留下最真實的東西。
google上搜這個詞，搜到的很多是征文，和一些扯淡的文章。
跟這篇文章一比就差的比較遠咯：
http://www.dapenti.com/blog/more.asp?name=xilei&id=15410
節選精華“中國夢”解釋如下：
如果有人問什么是中國夢？我說，只要你看看這個國內的精英怎么選擇的，你就知道了：
【1】讀書，考上清華北大，然后，到外企工作，出國，拿綠卡；
【2】唱歌跳舞，不惜一切代價成名，出國，變更國籍；
【3】當官，貪污腐敗，找機會逃跑到國外，躲起來過一擲千金的日子；
【4】做生意，賺到足夠的錢，然后，出國定居，想生幾個孩子就生幾個孩子，讓小孩都在國外上大學。
BlogJava，應該是一個技術博客。倒回來看自己寫的東西，卻感覺離題越來越嚴重。
對技術的熱情在衰退。所寫的技術相關的東西越來越少。
從Java到Flex到Grails。技術照理增長了不少，人卻越來越迷茫。
對文科的興趣在增長，已然超越了對程序設計的興趣。
可是做的工作又不得不繼續從事程序設計的學習，不然一旦失業了，我又能做什么呢？
所以每當看一些文科的書，就會有一種罪惡感。人活成這樣，不得不說是一件悲哀的事情。
其實心里明白，所謂悲哀在旁人看來不過是一種吃飽了撐著的心態。
買了域名和空間，準備換一個獨立博客了。到時想寫些什么就寫些什么了，也不用擔心站方有問題。
最近一直在看跟豐田生產體系有關的書，得到一些很有意思的知識點
- 剛明白原來這些個名詞他們是JIT->TPS->Lean->Agile這么一個關系。
-
豐田老總一拍腦袋提出3年之內超越福特。這種感覺就像好像有一家中國軟件公司一拍腦袋說，三年之內超越微軟一樣。我要是執行人，只會覺得上邊又發神經了，這不是瘋了嗎？結果大野耐一到底是大野耐一，竟然真的找到了方法。
- 生產過剩的浪費
- 制造不良品的浪費
- 停工等活的浪費
- 動作上的浪費
- 搬運的浪費
- 加工本身的浪費
- 庫存的浪費
-
豐田的思路其實簡單到了不能再簡單，利潤=銷售價格-成本。那么在經濟增長無望的時代，減少成本就等于創造利潤。過去的時代是一個經濟高速發展的時代。就像日本泡沫經濟時代一樣。但是泡沫破裂的時候，豐田反而崛起。類似的如學習TPS的佳能，在5年內銷售沒有增加的情況下，利潤增長十倍。
- 面對一個即將來臨的經濟增長放緩的時代，成本開始成為管理者嘴上流行的新詞應該是下一步的趨勢。
-
軟件開發中的浪費有哪些呢？我現在想不到太多。但是跟朋友聊天我突然意識到，猶豫也是一個巨大的浪費。作為一項腦力勞動，開發時的猶豫就如同停工等活的浪費和動作上的浪費。這種事情其實可以避免，我開始明白TPS這樣一個強調變化與改進的過程，為什么還如此強調標準化。應該就是通過整理最佳實踐并確定為標準流程來減少重復犯錯與猶豫造成的浪費。那么結對對效率造成的改進，別的不提，減少了猶豫的時間應該是很重要的一點。而這也是在水面以下最不容易被發現的浪費。因為猶豫和謹慎，從表面上看，似乎是一樣的。
通往天堂的輪船和通往地獄的輪船燒得都是同一種燃料，那就是人類的欲望。
記得小時候看《讀者》這本雜志，里面有一個故事，上帝帶一個人去參觀地獄，地獄里支著一口大鍋，鍋周圍坐著一群人，每個人拿著一個很長的勺子，因為勺子太長了，想要吃東西，經常會碰到別人，所以互相之間總會打起來，結果所有人都吃不飽，人人臉上充滿著憤怒和痛苦。然后上帝帶他又去參觀天堂，結果天堂里跟地獄的擺設一模一樣。但是人人臉上洋溢著幸福，原來，這里的人會用長勺子喂對面的人，所以，每個人都能吃飽。
同樣的配置，同樣的人，同樣都有吃飽的欲望。一處是天堂，一處是地獄?，F實中也是如此，一個好的游戲規則，游戲中便是天堂，一個不好的游戲規則，游戲中便是地獄。
相傳，有兩個嫌疑犯,合謀殺死了一個人，之后被警察抓住，警察將他們分開審訊。并告訴他們說，如果你們兩個人都不說的話，以我們現在的證據，我們可以讓你們坐一年的牢。如果你招供了，而你的同伙沒有招供，那么我們將當庭釋放你，你的同伙關20年。如果你和你的同伙都招供了，那么我們也就沒有必要照顧你們任何一個，你們一人關10年。
這就是著名的囚徒困境。處于困境中的囚徒，該如何選擇呢？
如果我是那個囚徒，我不說，你說了，我被關20年。你說了，我也說了，我關10年，只有你不說我不說的情況下，我還要關1年。這里還有一個極大的誘惑，那就是我說，你不說，我可以當庭釋放。人性如此不可靠，綜合判斷的話，還是說最保險，保不齊還能當庭釋放呢？不如賭一把。
這就是我全部的如意算盤，可惜，另一個囚徒他又不傻，他也會這么想。于是，利益最大化的可能性變成了永遠不可能達到的彼端。而10年這個選項變成了我唯一的下場，也是我們雙方唯一的下場。這個次壞的結局被稱之為雙輸。我們追求的利益最大化的那一點被稱之為單贏。而每人都得到次好的那個看起來更不可能的選項被稱之為雙贏。
這個故事中其實并不虛幻，現實中的我們都是這樣的囚徒。想想日常中遇到的一些類似的情況，真的是非常的熟悉。
現實中的情況復雜一些，可是道理相同。我們每個人都追求自己的利益最大化，可是長遠來看，最大化的利益或不曾降臨，或稍縱即逝。我們最終得到的只有那個次壞的選項。不過還好我們還可以合理化，安慰自己說，總算沒有到最壞的結果。但實際上我們明明可以到達雙贏的結局。
從剛知道這個故事的時候，我就發覺工作中的情況與此非常類似，于是我想，應該找辦法擺脫這個困境，遠離雙輸，通往雙贏。我覺得，憑借敏捷方法我可以不用陷入這個困境?？墒俏义e了，以前的困境拼圖并不完整，敏捷方法恰恰是補完了這個困境通向雙贏的那最后一塊拼圖，至此一個完整的囚徒困境才算是建立完成了。有誘惑，有陷阱，有希望，于是也就有了困惑。于是，困境始成。
在這個困境里，企業那點道道，就不說了，大家都很熟悉，可是作為我們程序員，就多么高尚嗎？
敏捷要求全能小團隊，可對于程序員來說，只干自己擅長的那一攤事，然后拿工資是利益最大化的選擇。抽空還能自己學點東西提升一下自己?；蛘吡牧奶?、泡個論壇、玩個網游什么的。我們自己做出了并不比企業高多少的選擇。通過雙方的不懈努力，終于，企業和我們達到了雙輸的結局。簡直就是悲劇。悲劇一再上演著，卻沒多少人太在意，至少大家都可以安慰自己說，總算沒有到最壞的結果，一定是哪里做的不夠好，再改進一些會好的?？上?，自然規律是很無情的。你做了這個選擇，就只有這個結局，于是悲劇一再上演。
沒有解決的辦法嗎？有，當囚徒困境不是模型里的單次博弈而是多次博弈時就有解?？梢圆捎靡粓筮€一報的方式，當一方選擇個人利益最大化的選擇時，那另一方也選，直到對方放棄。也就是不停的雙輸，并且溝通，直到大家一起回到雙贏境地下。這就是囚徒困境的唯一破解之法。只可惜這個方法也有問題。第一個選擇個人利益最大化的人會在這個方法中獲利。如果利益比較大的話，反復幾次，他就可以有機會破壞這個平衡，將雙贏博弈再次變為零和博弈。所以，懲罰機制也是很需要的。
方法有了，可是模型畢竟是模型，現實比這復雜得多。在囚徒困境之外，你會發現，還有團隊這個群體存在。當一個人做選擇很容易，當一群人做選擇的時候，就很難了。按照大眾心理學的說法，群體幾乎是沒有意識的。所以這個時候，我是只能感慨個人的渺小了。
價值,所有的方法學都會指向這個詞。
可是所謂的價值，有的時候說得清楚，而有的時候很難說得清楚的。客戶說出來的清楚，但有可能根本不是他最需要的。如果天下的人都清楚的知道自己要什么，也許也就不會有什么方法學了。
就考慮我們自己吧，我們想要什么？錢，沒錯，誰都需要錢。但要錢干嗎呢？在錢的背后是我們追求的價值。大家都想讓自己的價值得到體現?？墒沁@簡單的一句話在每個人身上卻有不同的含義。
客戶提出需求的時候總是欲求不滿的，仿佛跟上帝許愿一般?？墒俏覀儺吘共皇巧系郏皇乔趧诘墓そ?。工匠是一種介于藝術家與科學家之間的職業，是兼顧感性與理性的一群人。在我們的身上有像藝術家一樣追求超越自我的性格也有像科學家一樣鍥而不舍追求真理的性格，制造出對人們有用的工具是我們最大的價值體現吧?？蓮碗s的現實，讓我們這么利他的追求也難以實現。
紅警、星際、暗黑。還有人記得當年的這三個偉大的作品同臺競技的那個時代是怎樣的情景嗎？
不記得也沒關系，因為這個時代又要來臨了！
這次是紅警3、星際2和暗黑3.哇咔咔，未來的幾年不會太無聊了。不要太沉迷于游戲中才好，呵呵。
昨天，蓋茨離開了微軟。對我來說那一天只是一個普通工作周的結束，對微軟來說，卻是一個時代的結束。
用蓋茨大叔的操作系統的歷史跟我接觸電腦的歷史一般長。從最早的dos到win32到win95、98、me、xp、2000、2003、vista。我幾乎用過微軟的每一代操作系統。經常會罵微軟垃圾，可我也從來沒掏錢買過正版操作系統，這種罵多少有點齷齪。
時隔若干年之后，總算我也用上了正版的windows（筆記本送的Vista）。回想起來，一些往事不由得浮上心頭
最早的時候接觸的dos已經記不得是哪個版了，286時代的，而那個286電腦大概長成這樣：
但是開始正式學的dos應該是6.22的：
那個時候裝機只需要一張5存盤：
后來才有的3.5寸盤：
那個時候盤經常壞，所以3.5寸盤的塑料盒和5存盤的紙袋是很重要的東西。
后來，接觸到的第一個圖形化的操作系統是windows 3.2，那個時候我并不知道apple是什么：
操作起來大概是這么個感覺：
沒有任務欄、沒有開始菜單，非常詭異。再后來的，就是windows95了吧：
win95的界面比較經典，可以看出來現在的windows界面相比win95其實沒有太大的變化：
當時的游戲大多都是在dos下的，機器內存又小，為了玩游戲需要切到dos下，關掉95。即便在這么困難的環境下，依然有偉大的作品誕生：
。。。。
那個時候，很多游戲的安裝需要靠一個叫arj的解壓工具：
中間還有一個改進版的95，被稱之為win97，至今我也不知道到底有沒有那么一個正式的97出現過，反正很快，98就誕生了：
回想起來，那年開始，我接觸的游戲開始變多，我永遠忘不了我看到星際的時候的感受：
在那個時代，還有一個稱得上傳奇的病毒---CIH，以其可以對電腦造成物理傷害而聞名：
98是一個及其不穩定的操作系統，解決98里一些較大問題的唯一法寶往往就是重裝，也許正是因為他如火鳳凰一般的再生能力，一直到2000和xp誕生之后都有人選擇他做自己的操作系統。
而win me。。。很多人根本就不知道他的存在：
不知道現在有幾個人知道win me安裝完第一次啟動時必須忍受那個開機動畫的事。再后來就是2000了，其實在win32時代就有windowsNT，微軟用它在服務器市場里戰斗，不過我個人并沒有用過，windows 2000是我接觸的第一款微軟的服務器級別的操作系統：
到了windows 2000之后我對微軟的怨言已經少很多了，呵呵。之后微軟家族的產品越出越好，只不過漏洞和病毒依舊多不勝數。XP和2003就不回顧了，反正他們還不算歷史?？纯辞懊娴倪@些東西，想想蓋茨大叔的退休，該說些什么呢？私底下罵了微軟若干年了，反過來看，微軟也給我帶來了很多樂趣。也許，應該對他說一聲，謝謝。
前些天跟朋友聊天，聊得很激烈，我也收獲很多。
中間聊到過程，朋友認為，管理的最高境界應該是沒有過程，但仔細一問發現，還是有過程的，只不過是一些更人性化的過程而已。結合我另一些朋友的觀點，看來“過程”這個詞有點招人恨了。（當然如果是瀑布式的過程的話，我會第一個跳出來恨的,:P）
我一直認為過程這種東西，做不好就是枷鎖，做好了就是鎧甲，讓你在工作中左沖右時保障你的安全。這次敏捷大會跟o6z聊天時，他說，雖然他老說敏捷，但他
其實是一個很偏好重型過程的人。其實還是我的那個比喻，只不過重型的鎧甲也是鎧甲，更適用于直線沖鋒陷陣的重裝騎兵，但是你要是隨便找個步兵團隊來配上重裝騎兵的鎧甲，估計還沒打就被壓死了。
關于過程這個東西，很有趣。既然想到這了，就像抽取一些自己的零散思維放上來。
我琢磨XP有很長一段時間了，Scrum也看了一段時間，就個人來說，不是很喜歡Scrum?？傆X得這個東西天生帶有一點滋生官僚這種細菌的潛質。常聽說
XP沒有管理的內容，Scrum在這方面做的更好?？晌疫€是覺得Scrum沒提供什么東西，完全可以把Scrum的一些東西吸收到XP中，結合自己的團隊
實踐搞一些混合敏捷（Hybrid
Agile）。因為Scrum在管理方面做的東西并沒有多少，實在算不上盔甲，頂多是個盾牌。比較起來，XP的話，倒是有豐富的價值觀和配套的實踐，在吸
取了它的一些本質的東西之后集合公司實際做一些定制化的管理框架更好。
下一步準備研究一下FDD，再考慮跟前面倆方法混搭一下。我感覺這搞過程越來越像J2EE開發了：Struts + Spring + Hibernate一樣的玩法。
第110集的銀魂非常的搞。桂入獄了，而且是號稱從未有人逃出來過的監獄，里面關的都是罪大惡極的人，但是入獄的領袖到底還是領袖，很快他就成為了監獄中的老大，并且給這些終生無望的人帶來了改變，每天的勞改變得不再無聊，人人都有了目標，臉上都洋溢著希望，乏味的人生從此有味道起來。。。。。當然，這終究是一部搞笑的動畫片，前半截不管鋪墊的怎么熱血，最后一幕還是抖出包袱：前面只是陰錯陽差得演了一場各懷鬼胎的陰謀鬧劇。。。囧rz
雖然是搞笑的，但是那些洋溢著希望的臉，卻在腦海中怎么也驅之不去。監獄是人生的地獄，那里的色彩只有一種---灰色。如果是終生監禁，這種顏色還會伴隨你一生，成為你余生的主色調。進入監獄的人，在第一夜關燈的剎那開始明白，自己的人生從此完了。彩色的世界已經離自己遠去，剩下的時間里只有單調的監獄生活，不會再有希望。在那個世界里，幾乎不會有那樣的神情、那樣的臉，只有充滿戾氣的臉才跟那個環境般配。當這個動畫以夸張搞笑的手法把一張張這樣的臉呈現在我眼前的時候，我的第一感想竟然是羨慕。。。。
是啊，羨慕。我驚奇的發現，希望在我的詞典里被擠到某個小角落很久了。感謝一些人，讓我看透了一些事情。同樣也虧得他們，我開始不再抱有幻想，變得更加理性，雖然人生不再有明確的方向，卻敢于邁出自己堅實的腳步。這種沒有方向感的自信我不知道是什么，但是在這種自信的世界里，沒有希望的存在。偶爾升起的希望很快會被我的理智所設下的“幻想偵測系統”預測到并驅散。（目前這個系統的誤殺率還真不是一般的高啊。）
走在地鐵站中，看過往的人群，有各式各樣的臉，有幸福的、有木訥的、有暴戾的、有冰冷的，也有洋溢著希望的，對于見過的部分人們，說實話，真的有很多看起來充滿希望的，不過有些是因為沒心沒肺，有些不好說是因為勇敢還是無知，或者說不準是因為無知而勇敢，更多的是讓通過一種眼不見為凈的手法，讓自己的人生有希望起來，可是當真想到未來時，總會有一陣陣恐慌。
我想，希望這種若有似無的東西，看起來很沒有價值，實際上卻可以很有價值。一個人生活中充滿希望，那么他是幸福的，他就會有安全感，工作也會賣力許多。有什么理由不給人們帶來更多的希望呢？如果我們的團隊被希望所籠罩，我們的團隊就會有更大的活力。對于軟件這個行業，非常需要注重人。希望，是對人非常重要的一個東西。那么我們的團隊建設者們，是不是也應該注意一下這個東西呢？
早在工作之前，就有學長們、老師們諄諄教導說，語言不要貪多，學一門語言學到精，其他語言再學就很容易了。
我是這么做的，而且，做的有點過。很長時間里都扎在Java的世界里不肯出來，找開源工具也一定要找基于Java的。最早找一個Wiki都執意要找Java的，找到了JSPWiki。也因此認識了BeanSoft和Java Ajax群的朋友們，呵呵。
但是，隨著開發任務的變化，不得不去學一些其他的語言。沒辦法，人在江湖身不由己啊，所以，也就開始了多門語言的學習之路。javascript可以說是我學的第一門“外語”。最早的時候對js的應用，也就簡單用一下得了。后來隨著時間的推移，覺得將來脫不了要靠它吃飯，也就主動買了幾本JavaScript的書，慢慢的去啃，甚至啃到了很多對我沒什么用的高級的特性，再后來工作需要，接觸了Flex，js用的就少了，也就慢慢的放下了。
ActionScript是我接觸的第三門外語。也是用心比較大的，呵呵，很長一段時間里甚至熱情超越了Java。中間根據個人興趣還看了點Ruby。
隨著實踐的增多，對語言的恐懼心理下降了。反而發現了各個語言所在世界的優勢。每個語言所在的世界里都有非常優秀的東西。最早想做一個手腳架，看了一下Rails，是基于Ruby的；為了測試Flex，研究了FunFX，也是基于Ruby的；前不久在部門里搭建了一個wiki，是基于PHP的；這段時間又研究了一下Trac，是基于Python的；研究Trac的時候發覺它可以跟Bugzilla集成，而Bugzilla是基于Perl的。這么多優秀的東西，讓我覺得學習多門語言的困難變得無所謂了。
上次去OpenParty，參與了鄭曄的那個session。他講了自己在項目中使用多種語言的經歷。其實很有趣，作為只會一種語言的人來說，他覺得學多門語言會讓自己泛而不精，然而真正掌握多門語言的人卻發覺，他山之石可以攻玉，當你學會別的語言之后反過來在使用以前的語言的時候，思路會變得異常開闊。不管是對設計模式的領悟上還是對架構的組織上，都達到了一個更高的高度，反而更加精深了。
回來后，我也想了很多。記得早前看o6z一個帖子講，SOA之所以風行，很大原因是因為企業已經積累了一些設備和軟件。因為金融風暴也好，因為經濟衰退也好，因為成本考慮也好，因為這這那那也好，不想統一成一個，需求決定供給，所以SOA才風行起來。那么這樣一個環境對我們開發人員的會不會有什么影響呢？而且開源風行的今天，我們的軟件行業也已經積累了一批財富。我們業內的人，也是不想統一替換成一類語言的，那么市場上的需求會不會慢慢變得要求我們程序員必須掌握多種語言呢？其實現在已經這樣了，我就是一個例證，我的變化不是我主觀想這么做的，而是一只看不見的手---市場推動的。不過我個人預測未來可能會更嚴重，如果JVM成功變成一個可以跑各種動態語言的超級平臺的話。
瘋泉的故事一直困擾著我---相傳，有一個國家，有一口瘋泉，喝了泉水的人都會瘋，很快全國人民都瘋了，只有國王是正常的，在國民眼中看來國王是不正常的，其結果就是國王被灌下瘋泉水，成為了瘋子，全國狂歡。作為旁觀者看來，你告訴我，國王是對的？還是國民是對的？
可是跟所有的故事一樣，故事總是只強調問題的一方面，我反過來講這個故事，如果全國人民都沒瘋，就國王瘋了，國王認為，不行，全國人民得跟我這樣，于是想法設法讓全國人民喝上瘋泉水。那么現在作為旁觀者你告訴我，國王是對的？還是國民是對的？
現在有一個國家，有兩口泉，一口是瘋泉，一口是醒泉。喝了瘋泉的人會變成瘋子，喝了醒泉的人會變成正常人。最早國家的人全變成了瘋子。機緣巧合，國王喝下了醒泉。清醒過來的國王想讓國民都醒過來，想讓國民喝醒泉。而國民發現了國王與自己不一樣的地方，于是將國王灌下瘋泉水，國王再次瘋了。那么現在作為旁觀者，你告訴我，國王是對的，還是國民是對的？
其實三個問題都挺簡單的，第一個：國王是對的，第二個，國王是錯的，第三個，還是國王是對的?？墒?，我現在再給旁觀者的你一個新情報，三個故事是一件事，只不過是三個人講的，所以出現了三個版本。其實我還能講一個故事，就是把第三個故事反過來講，大家自己想去吧，相當于第二個故事的擴展版。如果是這四個故事一塊看，你說誰是對的呢？是“群眾的眼睛是雪亮的”呢？還是“真理掌握在少數人手中”呢？
如果到現在你還沒有被我繞暈了的話，應該心中還能響起柯南的那句話：“真相只有一個”。沒錯，所以你只要找到那兩個泉，搞清楚到底哪個是醒泉哪個是瘋泉就好了。真理，自然就知道是掌握在誰手中了。繼而也就可以證明國王是對的，還是國民是對的。
可是，事情沒有那么簡單，你率領的觀察隊發現，兩個泉水是兩口魔泉，你喝下一口泉水的水，你就有擁有了一種價值觀，喝另一口泉的水，就擁有了另一種價值觀。兩種價值觀是對立的，但是，誰知道哪種是瘋的呢？事情變得更復雜了。。。難道在這個事件中我們無法證明什么嗎？誒，還真有一個，你證明了，這個國家有兩口魔泉，不是一口。
這世界上有很多事情就是這樣，撲朔迷離的，就算最終謎底揭曉，發覺反而不知道對錯了?？墒侨绻覀円婚_始就知道這些，我們就能知道對錯了嗎？還是不知道啊。不過呢，這種問題，我們苦惱，精英們比我們更苦惱。早在我們考慮之前，精英賢者們就在考慮這些問題了，并得到了一些結論。最早的時候，老子就說，有錯才有對。這說法比較言簡意賅，乍一看就是句廢話。我以前也覺得他是句廢話，知道有一天看到了另一句話，才明白他老人家的微言大義。這句話就是：“可以被證偽的命題才是科學的命題”。這話聽著跟我們日常里對科學的印象不太一樣呢，我們常說，你這個說法不科學，那意思就是不對?？茖W當然是對的，證偽，證明是錯誤的，那種東西怎么能算是科學的呢？可惜，事實正是如此，所有科學的命題都是可以被證偽的?？茖W也正是因為信奉這一條原則，所以才可以自我修正，自我進化，以致今天的高度。
所謂可以被證偽不是說這個東西有錯誤，而是說，你這個命題天生帶著可以被推翻的情況出生的。比如，曾經有人懷疑進化論的科學性，說你這個東西無法被證偽，進化論的擁護者就說，你只要找到一批侏羅紀的兔子或者猩猩化石什么的，那么進化論就被證偽了，因為進化論說物種的進化一定是從低級到高級。這種情況，我們稱之為可被證偽。指一個命題能夠被推翻。什么是不可被證偽的呢？比如說什么是美的，我們常說情人眼里出西施，那美自然是無法被證偽的東西。藝術的東西，大都是無法被證偽的。無法被證偽的東西，自然沒有錯誤，沒有錯誤的東西自然就沒有正確。像這樣的東西，就不要追求什么對錯了，硬要追求，只有自討苦吃。
前一陣跟一做企業文化咨詢的哥們混了一陣，從他那瞅見一書，挺有意思。叫《公司基因》，看著不錯就買了。
這OpenParty是不興推薦書了，下次再有機會就推薦這個。
這書里認為企業文化不管怎么變，他的DNA都是由四個元素組成的，即：組織架構（原詞是structure）、決定權、信息、激勵機制。
它根據這四個元素把企業分成了七種類型
- 消極進取型
- 時進時停型
- 過度膨脹型
- 過度管理型
- 隨機應變型
- 軍隊型
- 韌力調節型
其中前四者看名字就知道不是什么好東西，書中也定義為不健康的企業。后三者，雖然都算是健康的，但最好的其實是最后一個。
敏捷常常被說是一種文化，我也這么覺得。所以，我最近一直讓自己從這四個角度看敏捷的方法學。分析來分析去，反而搞不清敏捷應該塑造一種文化，還是某種文化是維持敏捷的土壤。有點雞生蛋蛋生雞的意思。不過不管哪個生哪個，如果目的是養雞，那誰先誰后就不是我關心的了。
這本書前面部分寫了太多關于案例的內容。沒有足夠形象的講解Scrum。也沒有充分描述Scrum的假設、適應情況和不適應情況。講Scrum的風格跟微軟的講師講座倒是真挺像。
書中的Service1st公司的案例跟我們部門的情況極其相似。最后他也沒解決，只是說Scrum在現有的形勢下帶來了什么好處，有些失望。不過仔細想想，這個團隊的問題不是軟件開發方法的問題，而是企業文化的問題。所以Scrum解決不了是意料之中的。
但是這本書，說實話，不是特別經典的一本書，大概看看吧。
敏捷是以消除浪費、提高質量為目標的。但是有些時候總能見到一些原教旨主義者指出，重構也是浪費、結對也是浪費、討論也是浪費。然后呢，又有人提出，XX是必要的浪費這種說法。
想了一下，XX是必要的浪費這個說法其實不確切，只能說，這些東西是必要的成本支出。所謂浪費，必須從經濟學角度講才行。不然世間一切都可以帶上這個難看的帽子。
從牛博網最近新來的騙銀老師那里學來一個概念：“經濟學上有個奇怪的概念叫‘冤死的損失’（deadweight loss），英文的直譯是‘未被釋放出來的能量損失’，那是說，有一部分損失，...”誰也沒拿走，“...但因為效率原因，它就那么憑空損失掉了。”
因為聽起來很玄，為了讓大家更好理解，騙銀老師在后面講的一個非常耳熟能詳的例子：
“
我雇了一幫人，天天就負責刨坑，刨了然后填上，然后再刨開，再填上（這例子不荒謬，中國隨處可見），我發給他們工資，這一來一往國民生產總值（GDP）就上去了?？雌饋碚l也沒損失什么，對不對？只是簡單的財富轉移。其實不然，這里面有巨大的浪費，因為這些錢、這些勞力本來可以用在其他更為有效的生產上，可都用來刨坑了，那就是浪費。”（其實個人這個例子還不夠形象，如果挖坑和填坑的不是一批人，他們自己根本就不知道自己做的是浪費的事情，就知道干了活，拿錢，而且還為挖坑和填坑做了很多過程改進，提高工作效率。那就更形象了。）
所以說，您不能因為某些工作做了您能看到效果了，就不稱之為浪費，而有些工作做了您看不到效果就稱之為浪費了，應當反思一下是不是自己眼界不到。
離職將近，我在交接工作之際，因為我最熟，所以要我把依賴我負責模塊的其他模塊的適配器類改至新版。自己搬著Mingle寫了一些故事卡，又用CC寫了一
些持續集成的腳本。接下來，我還會去寫測試用例。整個過程中，沒有一行有效代碼的產出。在以代碼計績效的角度看，我的工作就算是浪費。可是，大家應該知
道，沒有這些東西，先不說我會不會在開發的時候保證質量。就說我離開以后，當產品質量出問題了，誰來保證？我可以根據異常一眼看出問題可能出在哪里，新接手的人能嗎？如果他改了程序，能保證不會按下葫蘆起來瓢嗎？他需要時間去犯錯去學習，這個時間，沒有產生新的價值，這才是真正的浪費。而且這也就成了挖坑-填坑的模式了。
問題反過來了，我做好這個CI的環境走了，來了一個新人接手，會怎樣？一天，系統報異常了。他有我的測試環境，而且，還是可以運行的。他可以很快的寫一個測試用
例，并開始調試，即便他無法理解整個設計，那不妨礙他快速的修復Bug。而且，因為以前的測試用例可以自動運行，他還可以保證自己的修改不會導致之前的功
能出現問題。一個為產品而組織的團隊，離開了某個特定的人，產品仍然可以自我完善，能完成這樣的目標的手法才是最有價值的。
很多人擔心前期花費的時間太多，后期就更沒時間，問題又來了。前期花費的時間多，是浪費掉了，還是合理的用掉了？如果是浪費掉了，自然不應該，如果是合理的用掉了，那是必須的。我們學軟件工程的時候都學過，一個問題發現的越晚，改正他的成本就越高。后期所謂的沒時間，就是因為前期太多問題沒有修正。
說道這個前后期的問題就不得不提最近一次結對的經歷。在我的堅持下，總算完成了一次與同等水平開發人員的結對編程。持續時間有三天。與同等水平的人結對，感覺是不一樣。也發現了很多以前沒有發現的問題。這都是個人問題，脫離我本人就沒有意義了，所以也就不說了。主要說一下心得。這三天的時間里做了一件什么事呢？推翻以前分成兩個模塊的應用，合成一個。兩個人做一件事，大家可以隨時根據今天剩余的時間做工作的調節，精確到小時。因為了解的信息不同，可以快速傳遞，合作互補，當他提出一方案的時候我可以快速告訴他，我這邊沒有問題，減少了嘗試造成的時間浪費。因為兩個人一起做，腦子根本停不下，一個人停了，另一個人還在轉，帶著你不得不進行。一天的有效工作時間在6小時以上。而分開的話，基本上能有3個小時就不錯了。
（中間發生的一點插曲。因為結對開發從不了解的人看來，是一件很浪費時間的事情。所以出現干預結對的現象出現，理由是擔心做不完。我覺得，如果不是堅持的話，就真的做不完了。從現實中看來，強調浪費，很容易被偷歡概念。而偷換概念的人很多人都沒有做過仔細的考慮。純粹的想當然。）
今天公司過了CMMI 4級，5級沒過，聽老外講述什么是5級也就是說什么是持續改進以后，感覺到CMMI的持續改進和Agile的消除浪費其實是一枚硬幣的兩面，持續改進就是消除浪費，為什么這么說呢？CMMI的持續改進本來就是高級別的過程域，那個時候指望重大變革基本就不靠譜，所以這個時候，看不管哪個行業，都會走向消除浪費的方向，軟件開發也不例外。CMMI的持續改進要求一直做一直做，那跟敏捷要求的追求精益的觀點是一致的。
CMMI認為通過4級的度量形成了穩定的過程之后，5級就應該是對4級過程的不斷改進，什么時候看，都是不滿足的，值得修改的。那種精神不正是敏捷的世界觀嗎？CMMI給出了一堆過程域和目標，并沒有告訴我們怎么實現，Agile就更粗狂，不過大家提到Agile其實想到的是XP。所以覺得Agile就是一堆實踐而已，沒關系，不去爭辯這個問題。我就看XP，XP的那12個最佳實踐，跟CMMI的思想一點都不矛盾。（細節不可考，因為很多時候我很難清到底是CMMI里面就定好了這細節還是我們的EPG定的）。以前的時候只是粗略的感覺這兩者可以不矛盾，現在培訓過后，更證實了這點。
============
縮寫解釋：
Agile 敏捷
CMMI 能力成熟度模型集成
XP 極限編程
EPG 企業過程小組
不知不覺做這個產品已經一年了，其實除了技術積累，對這個產品的概念基本是處于原始階段。雖然早已經過了企業內容管理與網站內容管理的疑問階段。但是內容管理本身是對企業有什么價值，問了很多人。很多人的回答都不讓我們滿意，因為他們回答的其實是工作流有什么價值、OA有什么價值、文檔管理有什么價值、ERP有什么價值。
昨天聽一位曾經實施過FileNet的同事說了一句話才明白過來這個東西的價值在于“提供一種海量非結構化異構文檔的查詢服務”，其余的都是在其之上的附加價值。
價值有了，可是越看越沒底：“海量”、“非結構化”、“異構”僅一個關鍵字就夠麻煩的了，三個拼一塊。。。很好，很強大。。。。。
這兩天為了Fluorida的closePopUp功能，讀了點Flex框架的源碼，對Alert，TitleWindow以及Flex的PopUp功能做了簡單的分析。
【Alert和PopUp】
Alert內部其實是調用了PopUpManager.在parent參數為null或者為Application的時候，彈出的窗口將跟當前Application在一個容器下。Alert在最頂層，Application在最底層，中間那層是一個稱之為modalWindows的控件，其實就是Alert后面那個磨砂的層。為了點到Alert上的按鈕，寫了一個小程序分析Alert的結構，不是很好讀，但是可以運行一下，看看分析出的Alert的內部結構：（大略說一下，Alert的Child有一個AlertForm，而AlertForm的Child除了第一個是TextField以外，都是按鈕）
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="horizontal">
<mx:Script>
<![CDATA[
import mx.core.IChildList;
import mx.core.UIComponent;
import mx.core.IFlexDisplayObject;
import mx.managers.ISystemManager;
import mx.managers.PopUpManagerChildList;
import mx.managers.PopUpManager;
import mx.controls.Alert;
import mx.events.CloseEvent;
import mx.core.Singleton;
import mx.managers.IPopUpManager;
private function showSimpleAlert():void{
Alert.okLabel="oKey";
Alert.show("Hello, World!","",15,null,alertCloseHandle);
var myTimer:Timer = new Timer(1000, 1);
myTimer.addEventListener("timer", timerHandler);
myTimer.start();
}
private function alertCloseHandle(event:CloseEvent):void{
simpleAlertShower.label = event.detail.toString();
}
private function timerHandler(event:TimerEvent):void{
var text:String = "elements:";
var sm:ISystemManager = (Application.application.root as ISystemManager);
text+=sm.numChildren.toString();
text+=";\n modalWindows:";
text+=sm.numModalWindows.toString();
for(var index:int = 0; index < sm.numChildren; index++)
{
text += "\n" + index + " : ";
text += sm.getChildAt(index).toString();
}
var alert:Alert = sm.getChildAt(sm.numChildren - 1) as Alert;
text += "\n buttonFlags : "+alert.buttonFlags;
text += "\n alertChildren:" + alert.numChildren;
for(var index:int = 0; index < alert.numChildren; index++)
{
text +="\n" + alert.getChildAt(index).toString();
}
var alertForm:UIComponent = alert.getChildAt(0) as UIComponent;
text += "\n alertFormChildren:" + alertForm.numChildren;
for(var index:int = 0; index < alertForm.numChildren; index++)
{
text +="\n"+index+":"+ alertForm.getChildAt(index).toString();
}
popupChildText.text = text;
alertForm.getChildAt(1).dispatchEvent(new MouseEvent(MouseEvent.CLICK));
// var popupContainer:IChildList = (application.root as IChildList);
// PopUpManager.removePopUp(popupContainer.getChildAt( popupContainer.numChildren - 1 ) as IFlexDisplayObject);
}
]]>
</mx:Script>
<mx:Button id="simpleAlertShower" click="showSimpleAlert();" label="Click Me"/>
<mx:Text id="popupChildText"/>
</mx:Application>
【關于TitleWindow】
TitleWindow作為彈出窗口的時候，跟Alert處的位置沒什么區別，我想說的是TitleWindow的closeButton在哪里。下面這個同樣不好讀的程序可以幫助你分析TitleWindow或者說Panel里面都有用什么，以及closeButton在哪，其實就是在rawChildren的最后一個。
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="horizontal">
<mx:Script>
<![CDATA[
import mx.containers.TitleWindow;
import mx.core.IChildList;
import mx.core.UIComponent;
import mx.core.IFlexDisplayObject;
import mx.managers.ISystemManager;
import mx.managers.PopUpManagerChildList;
import mx.managers.PopUpManager;
import mx.controls.Alert;
import mx.events.CloseEvent;
import mx.core.Singleton;
import mx.managers.IPopUpManager;
private function showSimpleAlert():void{
var popUpWindow:TitleWindow = TitleWindow(PopUpManager.createPopUp(this,TitleWindow,true));
popUpWindow.width = 400;
popUpWindow.height = 300;
popUpWindow.visible = true;
popUpWindow.showCloseButton = true;
var myTimer:Timer = new Timer(2000, 1);
myTimer.addEventListener("timer", timerHandler);
myTimer.start();
}
private function alertCloseHandle(event:CloseEvent):void{
simpleAlertShower.label = event.detail.toString();
}
private function timerHandler(event:TimerEvent):void{
var text:String = "elements:";
var sm:ISystemManager = (Application.application.root as ISystemManager);
text+=sm.numChildren.toString();
text+=";\n modalWindows:";
text+=sm.numModalWindows.toString();
text+="\n top children: ";
for(var index:int = 0; index < sm.numChildren; index++)
{
text += "\n" + index + " : ";
text += sm.getChildAt(index).toString();
}
var titleWindow:TitleWindow = sm.getChildAt(sm.numChildren - 1) as TitleWindow;
text += "\n popUpWindowrawChildren:" + titleWindow.rawChildren.numChildren;
for(var index:int = 0; index < titleWindow.rawChildren.numChildren; index++)
{
text +="\n" + titleWindow.rawChildren.getChildAt(index).toString();
}
var titleBar:UIComponent = (titleWindow.rawChildren.getChildAt(2) as UIComponent);
text += " has " + titleBar.numChildren;
text += "\n" + titleBar.getChildAt(3).toString();
popupChildText.text = text;
// var popupContainer:IChildList = (application.root as IChildList);
// PopUpManager.removePopUp(popupContainer.getChildAt( popupContainer.numChildren - 1 ) as IFlexDisplayObject);
PopUpManager.removePopUp(titleWindow);
}
]]>
</mx:Script>
<mx:Button id="simpleAlertShower" click="showSimpleAlert();" label="Click Me"/>
<mx:Text id="popupChildText"/>
</mx:Application>
最近的一個月事情真不少，公司內：要過CMMI，公司外：活動接連著就有倆。接連參加了OpenParty和RIAMeeting之后覺得自己應該總結一下了。
上次的OpenParty質量奇高。從那里學到了很多知識，從gigix那里學到基礎的價值，在session的學習中還順帶自己想明白了迪米特法則的價值，了解了壞的制度是如何作用于公司氛圍的，親眼目睹到設計欠債的后果，以及補救僅能做到的程度有多高。從Tin哪里學到界面開發過程方面的一些非常優秀思路，今天參加RIAmeeting的時候還討論了更細節的開發人員和設計人員配合的問題。這次的好topic太多了，只能挑著最感興趣的聽了，次感興趣的其實也很想去聽得，比如精益、CMMI & Agile、巨富客戶端，這一說起來好像哪個都想聽了，但只有在好看簿上看了，這種不完美別有一番吸引力，還有些沒選上的topic其實也不錯的。希望下次有機會聽到。Open Party給我的東西太多了，每次想說的時候就被教育一次自己的語言能力有多貧乏。
這次RIAmeeting也不錯，見到一些老朋友，也見到了沒有見過面的朋友。而topic呢，說實話，我已經過了對技術普及的topic感興趣的階段了。所以兩個主要的topic都不是很吸引我，而這半途蹦出來的一位90后的小兄弟貢獻的topic給了我不小的震撼，他的作品雖然還有點稚嫩，但是可以看到很多創新點和一些真正的產品級設計。看到了一個如此鮮活，沒有被教育體制的“壓模機”殘害過的頭腦，感覺真是不錯。（腦子中閃過“炸學校”短片里的那個壓模機）一年、3萬行代碼，高二，這幾個關鍵加在一起，讓我覺得這個小兄弟的時間管理能力應該不錯，于是問了一下，他還真給出了一個時間表，很有意思。會后的討論也很有趣，大家就美工與開發人員如何配合展開了很深的討論。那對美工與程序員的搭檔給我留下深刻印象，他們說的一些話體現出來態度讓我仿佛看到了一個優秀的團隊，尤為欣賞，尤其那位美工那種追求更高效交流以期減少浪費的“敏捷”態度在美工中真的是非常少見。（說實話，程序員中這種態度也不忒多見）
兩個活動都參加之后，個人比較來看，Open Party比RIAmeeting精彩，大概是因為RIAMeeting更像是Flex的傳播活動，偏向普及，缺乏高級點的交流，而OpenParty則是從業人員的經驗交流，門檻稍微高一點。其實對于線下的交流我還是比較喜歡門檻高一點，那樣比較過癮。
【花絮】
在OpenParty上我們講解了FunFX之后。熊節跟我說他剛才也做了一個自動化測試的框架。雖然我已經把敏捷和熊節這兩個詞關聯起來很久了，但是這等速度還是讓我吃了一驚（導致現在我還在懷疑是不是我聽錯了，
已經證實。。。我聽錯了）。那個框架當天就被熊節發到了google code上，當時他的名字是：
Fluorine，還寫了一句很有趣的話：Fluorine makes your teeth FLASH?？上н@個名字有人用過了，現在改名為Fluorida。
Fluorida的原理說白了很簡單，使用dispatchEvent的方式模擬操作，若干個月之前我也這么干過，當時是對這種方式的可行性表示懷疑的。在后來在Google code上下載了代碼并閱讀一遍之后，我開始覺得這個做法沒啥問題。而且相比FunFx，他不需要Flex程序員再去學Ruby。今天很榮幸的加入到這個項目組中。
如今預覽版--0.0.1版已經發布，廣泛征集回饋和建議中，有任何建議可以到
http://code.google.com/p/fluorida/wiki/Announcement001 發表評論
======
主要相關報道及文章：
http://www.matrix.org.cn/resource/news/7cf0239a-ebe6-11dc-91da-b599c3ba16ef.html
http://dreamhead.blogbus.com/logs/16533990.html
http://gigix.thoughtworkers.org/2008/3/6/announcement-fluorida-0-0-1
項目地址：
http://code.google.com/p/fluorida/
這世界上有很多界限，有些是看的見得，有些是看不見的。看得見的界限我們想辦法總能突破，而看不見的，則無法可想。
最可悲的是當看到本來看不見界限的時候，剎那的無力感會將自己的一切驕傲粉碎。
我很喜歡《褻瀆》的一個詞--位面。不一樣強大的人們就像活在不同的位面。在一個位面里，沒什么障礙是無法突破的，可位面間的界限，有時候你連他在哪都不知道。何談突破。
像我這樣從Java平臺進入Flex平臺的人經常會為ActionScript不容易實現某些設計模式（比如單例）而煩惱，跟我一樣煩惱的人有福了，這里有一本很棒的書：
http://www.tkk7.com/Files/tj19832/flex/Adobe.Press.Advanced.ActionScript.3.with.Design.Patterns.Nov.2006.rar
這本書一定要讀，一定要讀，一定要讀，不然開發的時候會犯很多錯誤，走很多彎路，產生很多錯誤的認識。后果很嚴重的：P
從來沒有想過把“炫”這個詞跟諾基亞的產品聯系在一起，通常這個詞都是給apple之類的公司的，但是在開始看這個視頻不到30秒，我的觀念就被徹底顛覆了。據說，七年之后，這款手機將上市。期待啊。。。。。
這就是我參加完第二次OpenParty的感覺，這次的topic有十幾個。很可惜最后進行的只能有9個。我跟Thoughtworks的韓鍇一起準備了一個關于Flex的session。沒想到還得到最多人的支持。虛榮心得到極大滿足，咔咔。
坐在里面，參與或主持Session，感受知識的傳播與再造，那真的是一件非常快樂的事情。我可以感受到自己的成長和別人的成長。往大了說可以感覺到中國的軟件界的成長，因為大家都是來自不同的公司，等大家帶著知識回到公司，又會對公司成長產生作用也就一點點得對業界產生了作用。就像蝴蝶效應，雖然這是一只頗大個的蝴蝶。（PS:但是出了門沒多遠就看到Police坐著車慢游，頓時緊張是不是查證的，唉有推動力就有障礙么）
整個活動是idea的碰撞、攪拌。這種感覺遍布各個角落，經?？吹絪ession已經結束，但是思維的碰撞仍在繼續。甚至這一期的OpenParty結束了，他的效果卻才剛剛開始，一直綿延到很久以后。在那種氛圍下，頭腦在一刻不停的思考、汲取知識，同時不自覺的就想去跟人交流。這半天過得是非常充實的。
也正是因為前面的原因，等回到家中，興奮勁稍微過去之后，大腦似乎才剛剛意識到累了。其表現就在于一回想白天的某一個topic，腦子里就爆炸式得蹦出一堆東西，有自己的想法，有別人的話，甚至當時的場景，一遍遍像過電影一樣閃現，最終崩潰，所有的畫面連不成一個有序的思維。于是打開優酷看美劇，同時上網跟人聊天，讓大腦停止思考。這招百試百靈，這次也不例外。直到現在，好象才從中稍微的恢復過來。可也想睡覺了。。。。。。
我的操作系統是Vista Home Basic版，Adobe網站上有兩個地方下載Flex Builder。我從http://www.adobe.com/go/flex_trial下載的怎么也裝不上。而從https://www.adobe.com/cfusion/tdrc/index.cfm?product=flex下載的就能裝（這個地址需要你有Adobe的id，注冊一個就好）。雖然解壓出來也是前一個的文件，但就是能裝，實在是有點暈。不知道是不是vista都這德行，反正跟我一樣裝不上Flex Builder3的話，去后一個地址下載就可。
最近，Adobe發布了Flex 3和AIR 1.0。宣布一個新時代的正式來臨。Flex的時代。
回顧多年以前，當它僅僅是Flash的時候，那時的它也可以運行在網頁中和桌面上，大家覺得它很漂亮，僅此而已，那時的它只是個非常可愛的小玩具。不要說巨人微軟沒有注意到它身上隱藏的潛力，就連他現在的主人Adobe也對它不感興趣。也正是這樣，他在每一個平臺上都很好的生存了下來。
在這個世界上，有另外一個技術，叫做Java。它以跨平臺為理念，努力打造一個統一的軟件世界。在后臺，它取得了無與倫比的成功，可是在前臺，它總是不那么順利。我，就生活在這樣的世界里。
日子一天天過去，Flex迎來了3.0。FlashPlayer9也占據了世界上94%的PC（如果算上以前的版本，這個占有率逼近100%）。而相比只下，JRE之占據了84.6%,在蘋果和其他操作系統的沖擊下，windows也降到了90%以下。毫不客氣的說，FlashPlayer已經是世界上覆蓋率最大的運行環境。昔日的星星之火開始呈現燎原之勢。
今年，毫無疑問會有很多的開發人員轉向或者開始接觸Flex，中國的Flex資源還比較貧乏，不過已經有一群人在努力了。雖然已經有了AnyFlex，RIAchina之類的論壇，但是相比較傳統的論壇，下面的幾個更有特色：
以
Kenshin為首的人做的
RXNA是一個非常棒的Flex相關RSS信息整合站，類似國外的mxna
而
閑云野鶴則建造了一個Flex搜索引擎計劃：
http://blog.eshangrao.com/index.php/2007/02/27/352-googleflex
以及同樣是他搞得Flex Wiki計劃：
http://blog.eshangrao.com/index.php/2007/05/12/390-flexwikiflex
還有促進線下交流的
RIAmeeting
有聲有色的活動和網站正在一點點多起來，今年將是Flex星火燎原的一年。我對此充滿信心。
所有關注Flex的博客上都在寫這個，那我也跟風好了。
Adobe發布Flex 3和AIR 1.0的正式版。
在這個日子里我在干啥捏？配CruiseControl，嘗試將持續集成引入我們部門，順便，考慮CI in Flex的解決方案。
我人生的道路上，我在做的事情有意義嗎？不知道。我的幸福是什么呢？不知道。我如此努力會不會是無謂的付出呢？不知道。我只知道，有一種力量在逼迫我行動，我不知道是在向前還是在向后。它讓我很累，很充實，同時很失落。我今天的努力可能在明天被證明是無謂的。我正在做的事情也可能會在將來被我意識到是沒有意義的。我的幸福，可能早已被我錯過。但是我依然不能停止我行進的步伐，向著幻想中的希望前進。這，就是我的人生吧。
今天應用維基百科的程序搭建了一個wiki，想架設知識庫的伙計們可以參考
部署方式如下：
下載Apache2.2,相關地址：
http://httpd.apache.org/ windows下要下載msi那個版本。雙擊將其安裝在機器上，我選擇的目錄是：C:\Apache2.2。如果不想使用80端口，在安裝過程中設置
下載php5，相關地址：
http://www.php.net/downloads.php 我下載的是windows的zip包那個版本，將其解壓在c:\php下。
下載mysql，這個就不廢話了。
安裝完后，將C:\Apache2.2\conf下的httpd.conf打開，在LoadModule一組處加上LoadModule php5_module "c:/php/php5apache2_2.dll"，在AddType處添加的
AddType
application/x-httpd-php .php 在LoadModule下面加上PHPIniDir
"C:/php"。把"c:/php"下的"php.ini-recommended"文件復制一份，改名為"php.ini",在php.ini中將
extension=php_mysql.dll
extension=php_mysqli.dll
兩行前的;去掉。
將extension_dir = "./"改為extension_dir = "C:/PHP/ext"
下載wikipedia：
http://sourceforge.net/projects/wikipedia/
將所有文件拷到"C:\Apache2.2\htdocs"下
運行開始菜單里Apache Http Server下的Start Apache in Console
打開瀏覽器，輸入：http://localhost:8080/index.php，在頁面上點擊 set up the wiki,頁面跳轉到：http://localhost:8080/config/index.php
輸入wiki name，和Admin username的名稱（默認是WikiSysop）和密碼
配置mysql的屬性，Database name，Database host，DB username，DB password還有超級用戶的用戶名密碼
全部設置完畢后點擊 install mediaWiki
完成之后，系統會提示你
Installation successful! Move the config/LocalSettings.php file into the parent directory, then follow
this link to your wiki.
將"C:\Apache2.2\htdocs"下的config/
LocalSettings.php拷貝到父目錄里即可
===================
以上部署過程在vista下測試通過。那些安裝路徑都可以換掉，但是不要安裝在Programe Files下。如果系統安全性設置太高的話，最后可能不生成LocalSettings.php
硅谷創業公司 BeyondMedia 高薪招聘 (北京)
BeyondMedia 是位于美國硅谷的一家提供媒體服務的互聯網公司, 主要為美國所有的媒體和客戶提供一個中間平臺.
現在公司處于快速成長期, 希望在國內發展一個研發中心, 目前正在招聘研發人才.
本公司是一家正在快速發展的互聯網公司, 公司為員工提供良好的工作環境, 具有吸引力的薪水以及股票期權, 履行正規的保險權益.
有意者,請發送中英文簡歷到
cnscud@gmail.com 郵件, 并請注明期望薪水,外語情況等, 謝謝.
以下要求僅供參考.
==============================
====
高級Flash工程師
主要工作職責:
* 和整個開發/設計團隊協作
* 完成相關的Flash設計, 制作, 維護
* 其他相關的設計工作
* 編寫相關文檔
基本要求:
* 3年+工作經驗
* 美術設計專業或有相關從業經驗
* 熟悉Flash制作
* 熟悉Flash編程 (Flex, ActionScript等)
* 熟悉JavaScript, Html, XML
* 有網站設計經驗更佳
個人:
* 能熟練閱讀英文文檔, 能編寫英文文檔更佳
* 良好的溝通能力, 能與團隊緊密協作
* 富有責任感
* 能積極主動完成工作
* 善于學習
===============================================
高級網站美術設計師
主要工作職責:
* 和整個開發/設計團隊協作
* 了解整個平臺網站的結構, 對網站進行設計, 實現和維護
* 編寫相關文檔
基本要求:
* 3+年工作經驗
* 美術設計專業或相關從業經驗
* 熟悉Photoshop, Dreamweaver等相關軟件的使用
* 熟悉網頁的制作編輯, Html, CSS. (Div+Css方式)
* 了解歐美網站風格者優先考慮
* 熟悉Javascript更佳
* 熟悉Flash制作更佳
個人:
* 能熟練閱讀英文文檔, 能編寫英文文檔更佳
* 良好的溝通能力, 能與團隊緊密協作
* 富有責任感
* 能積極主動完成工作
* 善于學習
高級J2EE軟件工程師
工作職責:
* 和開發/設計團隊進行協作, 了解系統需求,架構和設計
* 設計, 實現和維護系統平臺
* 編寫相關文檔
技術要求:
* 4年+ 的J2EE應用開發經驗
* 熟悉Struts2, Webwork或類似MVC框架
* 熟悉Spring和Hibernate
* 熟悉Javascript, Html, Jsp
* 有Ajax的使用經驗更佳
* 數據庫方面的經驗, 例如數據庫設計和SQL
* 熟悉Mysql, Oracle或者其他數據庫
* 有Web services的使用經驗更佳
* 熟練使用Java IDE, 例如Idea, Eclipse
* 了解Weblogic, Tomcat, JBoss或Resin的部署
* 熟悉Linux系統更佳
* 有網頁制作編輯(美工)經驗更佳
個人要求:
* 能熟練閱讀英文文檔, 能編寫英文文檔更佳
* 良好的溝通能力, 能與團隊緊密協作
* 富有責任感
* 能積極主動完成工作
* 善于學習
===============================================
J2EE軟件工程師
工作職責:
* 和開發/設計團隊進行協作, 了解系統需求,架構和設計
* 設計, 實現和維護系統平臺
* 編寫相關文檔
技術要求:
* 2年+ 的J2EE應用開發經驗
* 熟悉Struts2, Webwork或類似MVC框架
* 熟悉Spring和Hibernate
* 熟悉Javascript, Html, Jsp
* 有Ajax的使用經驗更佳
* 數據庫方面的經驗, 例如數據庫設計和SQL
* 熟悉Mysql, Oracle或者其他數據庫
* 熟練使用Java IDE, 例如Idea, Eclipse
個人要求:
* 能熟練閱讀英文文檔, 能編寫英文文檔更佳
* 良好的溝通能力, 能與團隊緊密協作
* 富有責任感
* 能積極主動完成工作
* 善于學習
目前Flash是不支持運行時加載SVG的。必須使用Embed的方式。
已經有人向Adobe提出了請求，不知道什么時候才能實現了：
http://bugs.adobe.com/jira/browse/SDK-11619
目前來說，使用SVG就會增Flash的體積，用來做些Logo之類的小東西還可以，做別的還是免了吧。
用了twitter之后這些小小的心得都有點不想往博客上寫了。
這兩天用BlazeDS做個小軟件，在用BlazeDS的時候發現，服務端的異常會被直接拋到客戶端，去了我心里一個疙瘩。雖然我還不知道他給拋哪去了，是去了回調函數，還是在調用代碼那里。不過他既然能拋回來，我就能處理咯，這都是小問題。
另外服務端返回的Java中的List，在BlazeDS中，都是給映射成了ArrayCollection。以后可以放心的處理了。
BlazeDS的文檔還只有在線的，看著十分不方便，尤其是公司那個網速，整個就是撥號時代的速度啊。
BlazeDS文檔地址：
http://livedocs.adobe.com/labs/blazeds/html/index.html
最終確定，這個東西是用flexmdi做的，而不是用的ventanas。不管用哪個，我都郁悶了一天，想不明白他是怎么做的旋轉，結果看了代碼發現，他把Flexmdi給改了。把人家的MDIWindow改成繼承ViewStack的了，恍然大悟。。。。。
【前言】早在半年前的項目之處就想采用TDD的開發方式，最起碼也要做到較完備的自動化測試。當時調研了很久找到一個叫FunFx的開源框架?？上н@個框架的試用之路并不平坦。最初找到的只有文檔，照著文檔做，失敗了?？吹轿臋n上還是Flex2的，換成Flex2，編譯都通不過,原來Flex2需要lcds的license只好回到flex3。被逼無奈去看代碼，我的Ruby水平是二把刀，盡管改代碼了，但還是通不過。懷疑是不是不支持Flex3，而且項目進度又容不得我們慢慢研究，只好自己寫了一個功能有殘次的測試框架，湊付著用，后來因為框架的擴展速度慢慢跟不上開發的速度，最終連寫自動化測試用例的計劃也放棄了。隨著FunFx出了0.0.2，又對這個測試框架產生了一點希望，再次搭建的結果還是一度失敗，經過不懈努力，總算在大年三十的下午運行了第一個Hello World！。
【正題：搭建TDD測試環境】（下面我說的過程是我個人運行的過程，應該是運行FunFx的充分條件，但不保證都是必要條件，如果有人發現哪個步驟是不必要的。請在回復中指出。）
FunFX是一個基于Ruby的自動化測試框架，所以，我們必須要裝Ruby，我安裝的Ruby版本是Ruby-186-26。我的Ruby IDE是eclipse上的RDT插件。我的操作系統是筆記本自帶的Vista Home Basic，因此我的IE是ie7。我的Flex IDE是Flex Builder 3 beta3。
運行環境就這些，那么開始講解搭建過程吧。我們從下載開始說起，首先，我們要去
RubyForge下載FunFx 0.0.2，那是一個zip文件，記得要把Source包也下載下來，在后面我會說到它的用處。
下載完畢之后，將其解壓，我們可以看到三個文件：
- AutomationGenericEnv.xml
- FunFX-0.0.2.gem
- FunFXAdapter.swc
接下來，我們在FlexBuilder3中新建一個工程：LearnFunFx，在libs文件夾里加入下面三個swc文件：
- automation_agent.swc
- automation.swc
- FunFXAdapter.swc
這里面的前兩個swc文件來自flex的sdk里面。后面的一個就是FunFx里面的swc，但是這個swc有可能是無法使用的，因為它是為flex 2編譯的，這時就需要我們前面下載的源代碼文件了。源代碼文件解壓開之后可以找到FunFXAdapter文件夾。里面就是FunFXAdapter.swc的源代碼（包括測試代碼）。將其編譯成swc（如果你不會編譯成swc，請查閱相關文章或自己琢磨，給你個提示，可以用library project）。將我們自己編譯出來的swc文件拷到libs里。這樣我們就收集全了所有的類包。
接著將AutomationGenericEnv.xml拷貝到src文件夾下，然后在LearnFunFx.mxml中加入如下代碼：
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
<mx:Script>
<![CDATA[
import mx.controls.Alert;
]]>
</mx:Script>
<mx:Button id="test" x="255" y="146" label="Button" click="Alert.show('Hello World!');"/>
</mx:Application>
代碼實現的功能很簡單，單擊按鈕，彈出Hello World!的對話框。
代碼準備完了，接下來是編譯了。下面我們在我們的工程：LearnFunFx上點擊右鍵：選擇Properties，再選擇Flex Compiler，在Additional compiler arguments文本框中輸入：-include-libraries "XXXX\LearnFunFx\libs\automation.swc" "XXXX\LearnFunFx\libs\automation_agent.swc" "XXX\LearnFunFx\libs\FunFXAdapter.swc"
XXX表示工程根文件夾，自己補齊。
接下來，一個囫圇的swf文件就被編譯出來了。這里還有一個問題,html文件里面的Object標簽一定要有一個name屬性，其值要跟id一樣，這就需要我們改html-template文件夾下的index.template.html了。我的做法是把body標簽里的js代碼刪掉，只留下html標簽版本的，然后在Object標簽里面加上一個屬性：name="${application}"。再次編譯一個，將 bin文件夾下的所有文件拷到一個web應用中。
flex端的處理完畢了，接下來是Ruby，還記得那三個文件嗎？
在三個文件所在的文件夾中地址欄里運行cmd（這是vista的小技巧，其他的windows可以通過傳統的方式進入cmd窗口,并進入該文件夾），在命令行上輸入：
gem install FunFX-0.0.2.gem等待一小會兒，屏幕上提示：Successfully installed FunFX,
version 0.0.2，表示已經安裝成功。
然后進入Eclipse 新建一個ruby項目LearnFunFx，也將AutomationGenericEnv.xml拷到源文件同級目錄下，新建LearnFunFxTest.rb，輸入代碼：
require 'test/unit'
require 'funfx'
class LearnFunFxTest < Test::Unit::TestCase
def setup
@ie = Funfx.instance
@ie.start(true)
@ie.speed = 1
@ie.goto("http://localhost/.../LearnFunFx.html", "LearnFunFx")
end
def test_control
@ie.button("test").click
end
end
“...”是web應用的名字，自己補齊。代碼非常簡單，功能是打開網頁，找到名為LearnFx的swf，點擊id為test的按鈕。在運行之前，我們還要做一件事，不然的話，我們之前的所有努力都白費了。打開IE，按下alt，選擇“工具”-> “Internet選項”，點擊“安全”tab頁，將“本地Intranet”安全級別設為低，將http://localhost加入可信站點，并將可信站點的安全級別設為低。（這里是我不確定是否多做了什么的地方之一）。做了這些之后，ruby調用js就不會被瀏覽器阻攔了。（剛才試了一下，運行完測試用例之后再改回去也不會被阻攔了，搞得我很郁悶，但是在我修改這里之前，確實是無法運行的。）
然后我們運行該測試用例，我們就會看到一個瀏覽器窗口被彈出，swf中的按鈕被按下，一個Hello World!的對話框彈出。一切成功：）
（完）
因為二把刀的Ruby水平，導致我反反復復研究FunFX，最后問題居然出在IE的安全性上。不管怎么說，終于在今天測試通過了。新年里，這是一個非常鼓舞我的事件，終于可以給自己一個交代了，Flex對TDD是友好的。
最后，新年新氣象，跟所有看到這篇blog的朋友們拜個年。
今天在首頁看了一篇很有意思的博文：
談一談在家辦公的利弊
其實在家辦公對我來說是一個很遙遠的夢想。但是人總不能放棄夢想啊。也來一個假想吧。
說是假想，其實這些手法也是來源于一些分布式開發的討論。而在家辦公在一定程度上構成了分布的情景。
最早聽說分布式開發是一篇講分布式敏捷的文章，之后一直對這種神奇的開發模式十分向往，也看過一些討論貼，借著這個話題也來寫一些東西，主要考慮一下Web2.0產品對分布式開發可能會有的一些幫助。在那篇文章曾說到分布式開發的基本原則：
（注：可以接觸到實際客戶的一端一般稱為on-site，另一端可相應的稱為off-site）
原則說得很到位，總之，無條件的提高交流的效果。在手段上我覺得在web2.0時代，我們有很多更好的工具可以幫助我們進行交流。
首先，對那個MSN和Y！的做法我就不是很同意，相比較的話Twitter不是更好嗎？項目組成員一人注冊一個Twitter帳號，所有人互相Follow。制定一個制度（先不考慮制度的建立過程）每隔一個小時寫一個正在干什么。Twitter不就是干這個的嗎？就像Twitter輸入框上面寫的：“What are you doing？”Twitter還能對話，而且所有的對話都是公開的，方便每個人加入進來，天生是個開放的環境。Twitter還能發到手機上，外出有事也能接到小組成員的工作動態。并且隨時插入討論。當然Twitter畢竟是國外的，可能會有很多問題，比如哪天被盾掉，那么嘰歪，飯否也是可以選擇的。相傳磯歪的功能比Twitter更強大。
接下來我說的更多像是給Google做廣告了，但是不管你承不承認，Google這些工具確實很有幫助。
第一個，Google日歷，Google日歷可以拿來做計劃和工作日志，每個人一個日歷，項目組再做一個計劃日歷。每個人的日歷寫自己的計劃和日志，項目組的日歷寫項目計劃和日志?？梢詭椭椖拷M跟蹤計劃和統計工作量。甚至項目經理或組長可以拿日歷分配任務。拿任務日歷和日志日歷跟蹤進度情況。
第二個，Google Group，google的這個論壇可以拿來做項目組討論的地方，每一個發起的討論都可以記錄下來，還避免了平?？陬^討論時不容易回溯的問題。但是單純的GoogleGroup還是比較麻煩的，只有在結合了Google的另一個拳頭產品之后，這個手段才是可用的。那就是Gmail。
第三個，沒錯，Gmail，Gmail中可以直接對Group發帖或對討論貼進行回復，并且每一個討論貼都可以折疊和展開起來。同時各個Gmail用戶可以直接聊天，聊天記錄也可以被保存在Gmail中。一切都是便捷且可回顧的。
第四個，Google Doc，不管我們怎么討厭文檔，大多時候文檔是逃不掉的。大家分布的情況下，文檔的管理和共享是個問題，但實際上，即便是不分布的時候，我們的文檔的管理共享也是問題（我總是在飛鴿上收到大量的文檔，導致我的文件夾中文件膨脹速度太快，產生大量垃圾，每次到找的時候總也找不到需要的文檔。）。為啥不使用Google Doc呢？文檔可以輕松共享，且大家可以協作完成一份文檔。且支持版本控制。
第五個，Google NotePad,這是一個很有趣的記事本工具，他有很多種用途，在我看來，他可以做能夠共享的TODO List，而且一些點子可以隨手記在上面，當哪天差不多了可以導出到Google Doc，我們可以用它來制定自己的計劃，并共享給組長或組員。
Google的廣告做完了，再來吹吹Adobe的，Adobe推出了一款在線會議室：BRIO，目前還是測試版。
我申請了一個個人會議室試用了一下，還是挺不錯的。可以共享桌面、聊天、語音對話、視頻，上傳文件。這些對于幫助在家辦公的人開會是很有幫助的。不過因為外國服務器的關系，速度有點慢。
即便這個東西因為網速等人力不可戰勝之原因跑不了，我們還有qq嘛，雖然因為眾所周知的原因，用QQ一般是降低工作效率的，不過我們可以申請一個工作用QQ嘛，這樣聊天、語音、視頻、共享桌面也都全了。而且在twitter的幫助下，配上TDD和持續集成的手法，偷懶應該是很容易被發現的。
以上就是我想到的可以輔助我們在家辦公或者說分布式開發的web2.0產品。
===========================
寫完之后我到回來想，其實有些用在辦公室里也未嘗不可。
FunFX是flex平臺下的一個開源自動化測試工具，可以對Flex進行TDD開發，目前，我已經進行了三次嘗試,可FunFX總也搭建不起來，心情極度惡劣。
最近突然想回顧一下設計模式，很多東西是要回過頭來總結一下的。今天先回顧一下單例吧。
很多時候覺得挺搞笑的，去面試的時候如果人家問你設計模式，一般都是要你寫個單例模式。去年來北京好幾家面試都是問我這個。當時我就想這個能反映出一個人的水平來嗎？還是說更多的是反映出這個公司的水平呢？
隨著一年的應用，很多地方都用過之后覺得，單例這個東西雖然簡單，可是現實是復雜的。所以單例這個簡單的模式也不能太小瞧咯。
單例其實有很多種實現，這是其中的一種，延遲加載的（好像英文叫Lazy？）：
[下面代碼中所有的構造器都是私有的，這里我就省略不寫了。]
public class ClassName {
public static ClassName getInstance(){
if(instance == null)
{
instance = new ClassName();
}
return instance;
}
private static ClassName instance;
}
這種的好處是我們的單例使用時才進行初始化，這樣方便我們在系統啟動時做些小動作。但是這個方式不是線程安全的，想要完成一個線程安全的單例，有幾種方式：
（一）
public class ClassName {
public static ClassName getInstance(){
return instance;
}
private static ClassName instance = new ClassName();
}
這種方式，可以保證我們的單例是線程安全的，畢竟我們唯一的實例在系統初始化的時候就構造了?？墒荍ava的機制是static級別的變量初始化時互相調用是會報異常的。所以隨著系統的擴展，尤其還會有一些新手或者粗心大意的家伙（比如說，我）會亂用你的方法。一不小心就造成問題了。而且，你也失去了第一個方式中的一個小優勢，不能在系統啟動時做點小動作了。
（二）
public class ClassName {
public static synchronized ClassName getInstance(){
if(instance == null)
{
instance = new ClassName();
}
return instance;
}
private static ClassName instance;
}
這樣倒是線程安全了，也可以延遲加載，但是從今以后這個getInstance方法就是
synchronized的了，那絕對是很影響效率的。我跟朋友討論提出了幾種寫法，以期既能使單例可以在系統啟動不至于數據已經煮成熟飯又是線程安全的：（少數人討論結果，代碼可能會比較丑陋，僅供參考，歡迎拍磚）
public class ClassName {
public static ClassName getInstance(){
if(instance == null)
{
instance = ClassName.createInstance();
}
return instance;
}
private static synchronized ClassName createInstance(){
if(instance == null)
{
return new ClassName();
}else{
return instance;
}
}
private static ClassName instance;
}
這種寫法就很好的解決了這些問題。
還有一種寫法是這樣的，這個不是延遲加載的。而是采用了一種取巧的方式。
public class ClassName {
public static ClassName getInstance(){
if(!instance.isInit)
{
instance.initSingleton();
}
return instance;
}
private synchronized void initSingleton() {
if(!isInit)
{
reset();//這名字是有點怪異，我沒時間想太好聽的名字
isInit = true;
}
}
public void reset(){
//.....真正進行數據初始化的地方
}
private boolean isInit = false;
private static ClassName instance = new ClassName();
}
將所有的初始化代碼搬到構造器之外。這是專為數據初始化和復位進行的設計。所以我把reset開放了出來。
（【轉載者按：】雖然不是技術文章，相信對我們很多人都有教育意義，所以發到了首頁）
=========
剛在天涯看見一個HR的文章，總結他的經歷，以一個面試官的角度看求職者的種種。
不能不說寫的很好，總結得相當全面，而且非常體現細節決定成敗的觀點。
但是，一如一個網友所說的，這些東西對剛畢業的學生比較有用，對于打滾過幾年的人，就幫助不大甚至相反了。
當你的能力處于同一水平線的時候，一家公司要你不要你，開多少價錢，你選擇去哪家公司，都是很隨機的事情。只要沒有嚴重出格的行為，那么幾乎就是運氣主導一切。
就像《太傻十日談》中所說的那樣，各種各樣的面經都是成功者歸納的，也許他們注重了某一方面，在某個地方做得比別人好，所以他們就將自己的成功歸功于哪一方面。
而實際上呢？可能和他們總結的原因南轅北轍。
同樣，經驗都是失敗者總結的，心有郁郁者對自以為的某一失策耿耿于懷，于是將自己應聘失敗的帳算在這頭上，實際上也可能根本不是這么回事。
運氣，真的是運氣而已，一切都是命運的隨機。
唯一提高自己應聘成功可能的只有能力而已。
當你是不可取代的一員的時候，你可以穿任何一件衣服應聘，甚至可以以任何態度來對待面試官，無他，硬營銷而已。
當你的水準超過其他應聘人員，足矣讓對方眼前一亮的時候，一些細節可以忽略。
當你水準和別人差不多的時候，你必須三分人才七分打扮，才有十足的力氣去拼。
當你遠遠不適應這個職位的時候，再熟讀面經也是無用，就算是對方一時眼花招了你，且不說對他，光是干一份自己不適合的工作就夠痛苦了。
那天和朋友聊起她最近的一次面試，很平淡地談著，雖然也積極展現自己，但是不再扭曲，懶得偽裝，也不會激動甚至忘形。而她看見一個小男生面試，激動地面紅耳赤，一如我們當年。
呵呵，我第一次應聘失敗，把原因歸結于我要回學校寫論文和答辯；
第一份實習工作面試，我連自創營銷學派的狂言都說得出口；
第一次辭職，差點掉眼淚；
對于一個有著試用期女郎名聲和作為職業跳蚤的我來說，面試過無數公司，拿到過無數個OFFER，也被無數個公司拒絕過，回想起來，其實自己的成功和失敗，選擇與放棄，都是相當隨機的事情，并沒有什么很確定的理由。
而對于公司，選擇我還是選擇別人，為什么拒絕我，大多數時候只怕也是很隨機的事情吧。
而我在哪家做，做得如何，同樣也是這個詞語可以概括了。
成功的經驗也是那么多，名人們寫著出，飛來飛去地演講。比起來，我更喜歡他們的人生態度而不是具體到某個公司的工作經歷，或者自己總結的一些職場勵志類東西。
所處的環境不一樣，成功的方式怎么可能復制？
病癥不同，難道亂吃藥？只怕就是好了，也是撞大運罷了。
以前我一直覺得自己混得不夠好的一大原因是因為自己不夠堅持，不會忍耐，求成心切。當然，這也的確是我的毛病，但是并不能就將失敗歸結于此。
曾經想過要改，但是看看兢兢業業踏踏實實的人混得還不如我的時候，又迷茫了，到底該如何？
如今，我只做我自己，除了努力提高自己外，個性上的東西，不再做什么強求了。
也許這錯了，但是誰又能確定地說什么是對呢？
當你的能力有所局限的時候，你所能達到的高度也有了瓶頸，這是所有的技巧都不能彌補的。無論你如何在面試中偽裝，在工作中積極，能力缺陷始終會是你的天花板，即使偶爾沖破這層玻璃，但是碎玻璃一樣會劃傷自己，一旦跌落，體無完膚。
的確，一個好的平臺會給你很多，甚至有可能從此在職場上一帆風順，但是這真的只是運氣而已。我們敢用自己的一輩子去賭運氣嗎？
這個輪盤上唯一能增添獲勝幾率的，還是能力。至少，有能力的時候，你可以多一些選擇機會，這家不合適，換一家，還可以選擇自己做老板。相反，則是你必須去適應公司。
扭曲自己是很痛苦的，也會影響發揮。當然，很多成功人士說適應環境的重要性，但是同樣我們可以找到大量的案例說明扭曲自己不但沒有獲得成功反而弄得自己痛苦不堪。
然而時間是單程的，所以我們永遠不會知道自己如果選擇了另外一家公司，換了另一種做法，會是什么樣的結果？更好，更差？
想多了那個問題，只會給你帶來現實的困擾。
都是不確定的未來，為什么非要扭曲自己呢？有禮有節，不卑不亢，就足夠了。
也許，只是因為我老了，累了，懶了，開始給自己找一個玄乎乎的借口罷了。
但是真的不愿在為什么而扭曲自己，不想再去拼命考慮自己該如何做如何說，除非這不會違背我的本性，并且我知道這么做有一個很確定的好結果。
其實十多年前我就明白一件事情，為什么這么多年我卻忘記了？
當你知道該說什么的時候，就說；當你不知道該說什么的時候，就說實話。
回憶起來每當這么做的時候，事情也許沒有變得更好，但是的確沒有變得更糟。
祝我們好運！
=================================
轉自非著名作家--白水加冰的博客，更多精彩文章請移步：
http://blog.sina.com.cn/gyy101081
過去的半年，因為對于Flex的認識較淺，全部采用的HttpService的方式構建的我們程序的通信，這里面java對象與as對象的映射與解析是一份工作量不小的工作，不是沒考慮用DataSerive的RPC，因為考慮到收費就放棄了，前不久從InfoQ上一篇新聞得知，有開源的DataService：GraniteDS，而Adobe自己也在去年12月14日開源了一個:BlazeDS。
這下清除了我們成本和許可的障礙。前天下載了BlazeDS，稍微研究了一下，部署了一個應用。
結果非常的成功，一切都變得那么簡單了，我們可以輕松的調用后臺的Java方法。就好像調用flex本地的方法一樣。而且不用寫Java類和as類的映射(還是要寫兩行代碼的，在映射的類上寫這些：[Bindable] [RemoteClass(alias="Java全類名，自己替換")])，我昨天試了，非常好用。傳參和返回值都是跟直接調flex的函數一樣（除了是異步的。這里我們看得出Flex對Java是非常友好的），還沒試異常。而且配置也是非常簡單的，在WEB-INF/flex/remoting-config.xml 下配置一個類似這樣的標簽就可以了：
<destination id="product">
<properties>
<source>flex.samples.product.ProductService</source>
</properties>
</destination>
調用也非常簡單（以mxml中的調用為例）： <mx:RemoteObject id="srv" destination="product"/> destination屬性的值就是配置文件里<destination>標簽的id屬性的值，之后我們就能像使用as對象一樣使用他了。
前后臺的對象保持一致的辦法也只是有一個什么樣的Java對象就寫一個什么樣的as對象。
部署也非常簡單，將BlazeDS下載到之后，解壓完畢我們可以看到三個war包，三個文件夾，和一個license,其他的不看，三個文件夾分別是：
顧名思義，第一個是文檔（現在還不全，想看全的還得去網站上看在線的）；第二個是一些可能會用到的資源，比如Jar包什么的；第三個是保存有例子的tomcat，webapps里面有三個web應用，分別對應那三個war包，但其中最有用的就是blazeds-samples這個了從里面我們可以看到所有豐富的例子，而且單擊右鍵選擇View Source還能看到代碼，而blazeds就是我們部署一個基于BlazeDS的web應用的空文件夾，所有該web應用需要的Jar包和配置文件都全了，而且都在他們該在的文件夾里。不過你要真的跑起來，在你的tomcat里還要部署些server級的東西，那個就在我們的resources/security/tomcat里，參照該文件夾下的readme.txt部署。
另外，即便是對HttpService和WebService的應用方面他都有一個很好的框架，他還有一個message框架，目前我還不清楚是干什么用的，猜測也許像JMS。
在對J2EE的支持方面，GraniteDS號稱已經支持EJB3.0,Spring,Guice,Seam，BlazeDS我還不知道，不過GraniteDS的作者對BlazeDS是持一個開放的態度的，且兩者的開源協議是同一個，可以互相拷貝代碼，所以我相信將來兩者都會更強大。
簡單的配置，清晰的結構，強大的功能。在試用之后，我堅信Flex中J2EE開發的王道一定是各種Data Service。
=========================
BlazeDS的網址：
http://labs.adobe.com/technologies/blazeds/
題外話，推薦一個Flex for Java的網址，希望對Java程序員有幫助：
http://flex.org/java/
短到只有幾個字的前一篇就當是序好了。還不至于厚臉皮到那么幾個字就當成是一，雖然我是很想。。。。
我想了一天，我為什么要選Ajax？或者說Ajax的優勢在哪里？大概有：
- 對公司而言，有豐富的現有資源可供整合（Applet、ActiveX控件）。
- 完全開放的平臺、完美的技術組合：HTML+CSS+Javascript、技術框架已經非常成熟。
- 容易上手，普及率高（這對項目經理來說是多致命的誘惑），足夠多的在線資源可供搜索，無數同行的blog和論壇為你的應用之路保駕護航。（尤其在中文方面，一個js的問題查找解決辦法很容易的，幾乎你的每一個問題都有人解決過了，而一個Flex的，麻煩輸英文吧，還不一定有人解決過，我就找到了好多許愿的帖子，愿這個問題在下一個版本中解決。。。。。。）。
- 單個頁面足夠小，幾乎沒有加載時間（相對于Flex）
- 各層次完美的分離，而且是真的分離了（相對于Flex，Flex只是程序結構上分離了，部署了之后不會有太大的區別）。你不得不承認，作為前輩Ajax的結構相當完美。
- 對“敏捷”友好，容易TDD。
- 配有強大成熟的自動化測試工具助你完成健壯的程序。
如果以上還不足以讓你覺得Ajax有什么吸引人的，那么麻煩點擊下面幾個鏈接：
什么叫豐富的資源，以此為例：
http://www.java2s.com/Code/JavaScript/CatalogJavaScript.htm
http://www.java2s.com/Tutorial/JavaScript/CatalogJavaScript.htm
http://www.java2s.com/Code/JavaScriptReference/CatalogJavaScriptReference.htm
http://www.java2s.com/Code/HTMLCSS/CatalogHTMLCSS.htm
http://www.java2s.com/Code/HTMLCSSReference/CatalogHTMLCSSReference.htm
什么叫成熟的框架，HTML和CSS已經在全世界廣泛應用了許多年，在JavaScript領域也有成熟的類庫和控件庫，比如：
http://www.prototypejs.org/
http://www.extjs.com/ 不知道ext又怎么踩著gfw尾巴了，鏈接被重置，友情提示，請準備好穿墻工具查看
http://jquery.com/
如果上面的那些還不能讓你滿足，那么Tin的ppt應該可以喂飽你了，其中甚至推薦了可以使ie6的bug消失的神奇js庫和CSS框架：
http://www.haokanbu.com/story/5889/
http://www.haokanbu.com/story/5892/
如果你覺得Flex的開發工具非常好，相對于Flex Builder我們也有這些開發工具（雖然他們也支持Flex）：
http://www.aptana.com/
http://www.jetbrains.com/idea/features/javascript_editor.html
有上面的這些東西輔助，基本的項目我們都可以搞定，為什么要選擇Flex呢？而且根據我的開發經驗Flex有下面幾個缺點：
- Flex編譯出的程序過于龐大，什么都不做都有幾百K，如果加入一個字庫的話更是會有上M的大小，雖然現在采用了RSL的方式，解決了一些尷尬局面，但是也不能改變其無法廣泛使用在廣域網上的境地。
- Flex的編譯速度慢，相傳全部用as而不使用mxml可以提高編譯速度（可問題出來了，那我的Flex操作性就變差了，跟Ajax有啥區別）
- 如果選擇AIR，那就不能利用公司現有的web資源，比如一些activex控件、applet等，需要重新開發。說句題外話，當你不得不調用這些本地相關的玩意時，從一定程度上影響了他的跨平臺的能力。
既然這樣，Flex這種玩意還有啥選擇的必要嗎？
休息。。。。。。
聽Tin的Topic之前就在考慮自己應該在什么情況下用Flex，聽了Tin的topic之后更得考慮這個問題了。
Ajax（我暫且借用這個名詞）在強大的開源庫及現代化的ide的支持下，已經很強大。
Flex這時過來橫插一杠子，實在是很沒意思。取代Ajax，絕不是一個很好的主意。（雖然我曾經這么想過）
面對強大的Ajax和超炫的Flex，我總是會問自己很多問題：
Flex可堪大用嗎？Flex和Ajax是進一步互補還是在一次握手之后分別向兩個領域發展呢？Flex會是前端的Java嗎？AIR是Flex的未來嗎？BS模式會不再成為主流，CS模式會再一次流行嗎？
夜已深，悍然歇晌，暫時先給自己挖個坑好了，省的自己忘了這個問題。
早在AgileChina上聽過關于Lean的只言片語，OpenParty上沖著這個名字于是跑去聽路寧的《Lean Thinking with Examples》。
這個Session很有意思，討論也很激烈，以至于嚴重超時。雖然聽了之后還是對單件流一知半解。即便Google了一些也沒完全搞明白這個東西在生產中的價值，以及操作的手法。不過對于Lean--識別和消除浪費的技術（路寧的ppt中還有對浪費的解釋：不產生附加值的活動。我個人認為這個解釋反而讓我糊涂，于是給去掉了。），總算有了一定的初步認識。
路寧在講演中，一直在強調要考慮端到端、對最終用戶價值的重視。這是一個很棒的新思維。我們的思維慣性里，對短板效應比較重視，總是對最短的那個木板進行優化，但是豐田直接把木桶扔掉了。因為在他們的模式里，木桶接水，是一種浪費。這種讓人耳目一新的思路，不由得使我想起了郎咸平的那個案例：時裝行業的SARA。
他們為了解決3家大工廠和400家小工廠之間的物流問題，建了200公里的地下隧道，用高壓空氣運輸；他們用空運而不是海運；他們款多量少；他們根據銷售情況快速反應制作下一個款式；他們從設計到出現在店里的時間（又稱前導時間）為12天。而我們國內一般最快的是60天，最慢的能到180天。因為我們會怎么做？3家大工廠與400家小工廠太分散，集中。海運便宜，選海運。一個款式還在熱銷我傻了我不大量生產？比較來看，我們的手法從常識上來講似乎是減少了浪費：集中了，更有效率，減少了運輸浪費。海運便宜，減少了運輸成本，把每一個款式的銷售額發揮到了極限。結果，我們的前導時間是他們的幾倍甚至十幾倍更不要提他們因反應敏捷帶來的快速設計新的款式的加成效果了。他們引發了時裝界的革命，我們只能惡性競爭，一塊死掉。
這就是說，浪費有很多是反常識的。讓我們考慮，時裝行業，對最終用戶來說最大的價值是什么？新潮、時髦的衣服。最好能不要跟人撞衫。
從這個角度上再來看，考慮端到端，最大的浪費是什么？前導時間、同一款式過多的量?，F在你再倒回去看Sara模式，他不成功誰成功？咱不失敗誰失?。?br />
李劍在session中提到一個故事，一個人外出，準備了各式各樣的預防措施，最后走到橋上，橋折斷了。這個故事說明，我們經常為了害怕的風險做一些無謂的預測行為，反而變成了浪費。我們要找到我們真正的問題，我們軟件開發中，也常常做預測（預先設計），以防項目中會發生的變化措手不及。這本無錯，可是我們經常把本質問題扔到一邊，熱衷于預先設計了。做那么多預先設計不一定能預防項目中發生的變化造成的措手不及，這是一種極大的浪費。（有時候我看到人們對預先設計的熱衷，不由得感覺，那有點像對祈雨之舞的迷信，同學們，我們的目的是讓他下雨，不是跳舞，當然你一直跳一直跳他總會下雨的，不過你不覺得那是蒙的嗎？）我們真正的問題是為了變化不會殺死我們的項目（起碼最壞的打算是這樣的），別的都是手段而已。再回到sara的例子上，3家大工廠與400家小工廠的分散，從表面上看，不集中會帶來浪費。但實際上，真正的問題是不集中會導致物流的不暢通，這個問題解決了，管你集中不集中呢，對吧。集中往往還會因為臃腫而導致效率低下呢。
我們要透過現象看本質，消滅慣性思維。通過這個session，我又一次認識到了這個思維的重要性。。。。。。
=========
附：
路寧Session的報道：
http://www.infoq.com/cn/news/2008/01/lean-2008-beijing
如果使用VideoDisplay，那么他有一個屬性，叫cuePoints，值類型為數組，數組中的每個元素要求有兩個屬性，一個是name，類型為字符串，一個是time，類型為數字，表示觸發時間的秒數。例如下面的代碼，當播放到3s時將彈出一個對話框。這用來解決一些播放到某一時間點觸發某事件的情況。
<?xml version="1.0" encoding="utf-8"?>
<!-- LearnCurPointEvent.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="init()">
<mx:Script>
<![CDATA[
import mx.controls.Alert;
import mx.events.CuePointEvent;
[Bindable]
private var myCuePoints:Array = [
{ name: "first", time: 3}];
private function init():void{
this.c_mainVideoDisplay.cuePoints = myCuePoints;
this.c_mainVideoDisplay.addEventListener(CuePointEvent.CUE_POINT,cue_PointHandler);
}
private function cue_PointHandler(event:CuePointEvent):void{
c_mainVideoDisplay.pause();
Alert.show("It plays " + event.cuePointTime +"s.","",4,null,go);
}
private function go(event:Event):void{
c_mainVideoDisplay.play();
}
]]>
</mx:Script>
<mx:VideoDisplay id="c_mainVideoDisplay" width="320" height="240"
cuePointManagerClass="mx.controls.videoClasses.CuePointManager"
source="phone.flv"
autoPlay="false" />
<mx:Button label="播放" click="go(event)"/>
</mx:Application>