2008年2月14日
題外話：我其實想說的是一個被人所忽視的問題。形式有沒有價值？我承認，形式化是不好的。但是這個世界有個東西，叫做儀式。
舉個例子，在國外，有種組織叫兄弟會，（電影里很常見）他們的有些會設置很多可笑的考察儀式來考察你夠不夠入會的資格。有些會有危險，有些只是純粹搞出些恐怖氣氛嚇你看你會不會被嚇退。這種東西有價值嗎？心理學告訴我們，設置準入門檻可以提高組織成員的忠誠度。如果你覺得這玩藝太可笑了，給取消掉。你會莫名其妙的發(fā)現(xiàn)后來加入的人對組織的認可度忠誠度都不高。這就是儀式的價值。
今天說的是Retro，全名retrospective，中文名“回顧會議”，網上有很多相關文章，就不再這里贅述了。這里提到的Retro是最常見的一種模式，分Well, Less Well, Puzzle三個維度的模式。該模式的Retro的特點是會讓我們更多的關注less well，關注我們做的不好的那些。這點有好有壞。本文只揭示它好的一面。做為補充，還有一種海星圖的模式，感興趣的人可以自己查詢。
我個人認為retro是敏捷開發(fā)中很重要的一道防線。是團隊健康度的晴雨表，是溝通的橋梁，是共識建立的契機，是改進的開始。
對于團隊本身就存在大量問題，而這些問題可能都在敏捷方法的問題域里時。Retro是一個很好的發(fā)力點。他的效果可能沒有持續(xù)集成那么立竿見影，往往是潤物細無聲。他可以幫我們把痛點暴露出來，但是不一定是根本問題。就像醫(yī)生看病也得先問你哪不舒服。而Retro就能幫團隊說出來哪不舒服并達成共識。某種意義上講，它是個報警器。
如果已經采用了大量敏捷實踐的團隊呢？比如我們團隊，在我們團隊的開發(fā)中，我們一直推進著各種改進，期望讓我們的工作更有效率，交付更多價值，同時也讓我們的生活更美好一些，這是一件雙贏的事情。 可是我們也要看到改進是需要成本的，而且也是有風險的，所以有的時候難以推動。對于客戶（ 有時是PM等內部角色）來說，他討厭一切成本和風險，而更感興趣的是新功能，當碰到短視的負責人，或者交付壓力占了上風的時候，難以推動這點感覺尤為明顯。不過商業(yè)社會里競爭如此激烈，這也無可厚非。雖然我們也知道出來混，欠下的遲早是要還的。
不過這不是我們今天討論的角度。今天我們站在推動改進的角度來看這個問題，開發(fā)時，在開發(fā)第一線的我們往往是第一個了發(fā)現(xiàn)開發(fā)中的問題，然后我們會發(fā)現(xiàn)改進最困難的是溝通，明明這是個問題，但是讓各方都接受這個問題并改進它需要證據(jù)，需要溝通，需要資源，最重要的需要時間。我曾眼睜睜得看著客戶只是加幾臺機器提升持續(xù)集成的構建效率這件事竟然推動了近一年才成功，那么在這個問題被發(fā)現(xiàn)但不能改進的時間里，團隊會怎樣呢？首先士氣會被打擊，接著如果問題長期不能解決并影響了工作效率，一種不愿追求卓越的氣氛會漸漸感染團隊成員，進而使得大家會在其他實踐上表現(xiàn)漸漸變差。（ 相對于每個人自己，而不是團隊其他成員）改進的意愿也會不同程度的變低。這符合
破窗效應。
這時候，很容易出現(xiàn)的一個傾向會是干脆我們不要retro了，反正也改進不了，完全是浪費時間。 這就成了自毀長城。不能干因為報警器老響就把報警器拆了的事。出來混欠下的始終要還，學鴕鳥是沒用的。當retro不能給我們提供更多實際改進價值的時候，它還能提供最后一個價值：懺悔的儀式。
曾經一直不明白西方人為什么定期去教堂懺悔，周周去，周周都有值得懺悔的，甚至犯過的錯還有很多類似的。看起來沒什么用。但這就像房間，天天打掃天天都有的打掃的，心靈的房間也是一樣。一位有信仰的朋友告訴我，定期經常向神懺悔會更愿意改進自己，如果一段時間不去對自己的要求就會放松。人的心理就是這么奇怪。這揭示了一個道理，人是會逐漸放松對自己的要求的，所以需要一種手段讓我們保持對自己的高標準。
我個人認為retro就是一個很好的手段。尤其我前面說過了，這里討論的這種Retro的模式的特點就是讓我們更關注于Less Well。定期，經常，回顧，反思。當我們無法變得更好的時候可以幫助我們反觀團隊自身，不要變得更差。讓破窗效應難以發(fā)生。
（本來只是想寫一個敏捷團隊碰到讓人沮喪的情況時Retro提供的價值，結果越寫越多，有點跑題了⋯⋯）
在我們的開發(fā)中，有些實踐的價值是容易感受到的，比如重構，比如TDD，比如持續(xù)集成。
有些實踐的價值則不容易感受到，比如Retro（回顧會議），比如IPM（迭代計劃會議）。
以IPM為例，在我們的IPM上我們一般會做兩件事Kick off cards和Estimation。也就是選擇下個迭代要做的卡和評估每張卡的點數(shù)。這兩件事情似乎第一件事沒必要所有人都參與，第二件事感覺一定程度上是瞎蒙，尤其是一群人來蒙，顯得尤為的不靠鋪。而且似乎我們IPM就是為了選出下個迭代能做完的卡，就是為了知識傳遞，就是為了給客戶可視的數(shù)據(jù)和計劃，讓他們心理好過。
假設說我們不必所有人都參與就能保證選出適合下個迭代做的卡，我們通過每日Code Review等實踐使得每個人都不會缺少相關卡的知識，而客戶也不特別在意我們的進度（或者說我們的進度他們總是滿意），是不是我們就不需要IPM了？是不是我們就不需要集體Estimation不需要集體Kick off了？
實際上，我們的項目就符合前面的假設，在項目的最后，我們真的取消了IPM。這時，才感覺出來IPM的價值。
整個團隊的效率慢慢開始下降。對于目標的理解開始不一致。雖然團隊整體的表現(xiàn)并不差，雖然沒有出現(xiàn)任何實質的問題，但容忍度低的人開始不舒服。跟團隊自己以前的狀態(tài)比，確實有點退化的感覺。怎么會這樣呢？
每當說到這種狀態(tài)出現(xiàn)在敏捷團隊中的時候，我最常聽到就是人的問題，態(tài)度問題等等說法。其實我一直覺得，如果追究態(tài)度，空談人的問題有用的話，我朝應該是世界第一而不是那個人人自我的美帝。人一直是有問題的，不然要管理學干什么？敏捷里提倡自組織團隊，自我管理。但決不是松散組織，不管理。自組織它也需要組織，自我管理它也是管理。像IPM這樣的活動，就是管理的一部分。
IPM上做的兩件事，看起來完全不靠鋪，實際上卻非常有價值。整個IPM活動就是一個承諾的儀式。像古代行軍打仗前的誓師大會一樣，可以調動起團隊在下一個迭代中的士氣。通過集體參與評估和制定計劃，通過各個角色的共同作用，使得每個人都參與到整個計劃制定中來。自然而然的對下一個迭代許下承諾。而承諾一旦許下，就會像一個耳語的惡魔，暗中催促著人們的行為與其保持一致。
生活在我朝的人們，似乎對承諾這個東西的效果是完全不相信的。這也難怪，不過出于眾所周知的原因，咱不談我們?yōu)樯恫恍湃纬兄Z。從心理學的角度，承諾是有實際意義的。《影響力》“第三章 承諾和一致”中就講了這個極為簡單卻極為有用的心理學原理：人人都有一種言行一致（同時也顯得言行一致）的愿望。
其中有很多很有趣的實驗，揭示了承諾的力量。 感興趣的人推薦讀一讀。里面有個小例子提到，兩個星期前一個愿意在自家的草地上插一個小牌子為交通安全做點貢獻的小承諾，使得該社區(qū)76％的人都在兩個星期后接受了在自家草地上插一個擋風景的大牌子的請求。而對照社區(qū)只有17％。巨大的反差可以讓我們看到承諾的力量。
當然我們對承諾的不信任也是有道理的，當承諾真的難以完成的時候，幾乎所有人都會違背承諾。在傳統(tǒng)的瀑布式開發(fā)過程中，使得計劃這種承諾難度大大上升，而可信度也就大大下降。這也是為什么我們需要迭代的原因。
一個成功的企業(yè)需要積累。當你坐在電腦旁，看著一個運行達十年之久的軟件的源碼時，相信我，你一定會更深刻的感受到積累這個詞，確確實實是個中性詞。
軟件多種多樣的功能支撐著一個企業(yè)帝國的運轉，它源源不斷的在為這個帝國創(chuàng)造著財富，毫無疑問它隨著時間積累了很多掙錢的能力。可是如
同歷史上其
他的帝國一樣，在繁華的背后，很多黑暗的東西同樣隨著時間積累了下來，臨時性的策略被固化在核心流程中，為擴展留下的空白成了每次擴展必須繞行的彎路，精妙的手法隨著時間的變遷顯得復雜過時，分工協(xié)作使得同樣事情得處理方式大不相同，預先的設計又使得本不相同的東西硬造成了相同的樣子，管理的疏忽使得簡單的功能用了復雜的模式實現(xiàn)。
坐在代碼面前，仿佛在讀一本被囚禁了靈魂的魔書，你能在注釋中讀出興奮與痛苦，你能在代碼中看到驕傲與彷徨。每當完成一次重構就像解救了一個被困的靈魂。那代碼又仿佛一個人的臉，你可以看到各個技術歷史階段在它臉上留下的歲月痕跡。暢游在代碼中，有些時候我們好像穿梭在時光的河流中，你能看到一個愚昧的風格是如何從一個有價值的需求中演變而來。如今再看，仿佛一群羊在不斷的跳過一個早已不存在的柵欄一樣詭異。而有些時候，我們只能看到一些遺跡，原野中矗立的大石柱根本無法自己告訴我們他們到底是為何矗立在那里的。以及移動他們會不會帶來什么災難。
能力很強，問題很多。是任何一個已經有歷史的公司都會有的。軟件不過是公司的一個表現(xiàn)方面。就像一個擁有完整公司基因的細胞。準確的說，任何時候，任何公司都不可能沒有問題的。但是何時解決？這個問題就跟什么時候重構一樣，答案也是一樣，隨時。解決問題的時機會影響解決問題的難度。越晚解決，就越難解決。說起來容易，做起來談何容易。是的，解決問題總是需要鼓勵的，但是談何容易四個字卻很容易瓦解我們前進的意志。低下頭埋到土里，是可以讓一切都清靜了。但不管我們做不做，甚至于即便我們在做，問題也永遠不會停止它產生并進化的腳步。面對問題，只有應戰(zhàn)，沒有第二條路可以走。經濟危機教會了很多企業(yè)只顧賺錢而忽略企業(yè)的問題會有什么后果。我相信有很多人會選擇遺忘并在遙遠的未來繼續(xù)重犯同樣的錯誤，但是我也相信，也會有很多人會選擇記住并把教訓提煉成一種知識或制度，讓后世人學會警惕。
進來聽聞最大的CMM堡壘DNV要搞敏捷。大票的獵頭紛紛出動，四處搜羅敏捷咨詢師。使敏捷這個本來只有小眾在實踐的一類開發(fā)方法陡然變得要大眾化了。本來以為是件好事。卻在昨天看到z叔大喊，敏捷要倒。當時只是覺得有點道理。晚些時候卻切身體會到了。
收到某非知名公司舉辦的scrum培訓的郵件。頓時心里一緊。在這個時間，用這個操作手法有點可怕，各培訓公司都找到了敏捷里面最好切入的一個點---Scrum。
Scrum是個筐，什么都能往里裝啊。為什么這么說呢，他并不能算是一個完整的開發(fā)方法。只是一個框架。不領會敏捷的精神，沒有其他具體的開發(fā)方法，他只能是一個大面的東西，如果用上這種東西就號稱敏捷了。那真是可怕。而且，scrum證書也在這波浪潮中量產。一個人，花幾千塊錢，上兩天的課，拿著一張紙就號稱敏捷了。沒辦法，誰讓咱們崇拜證書這種看得見摸得著的東西呢。但這樣大量量產出來的敏捷項目經理。一實踐肯定不對勁，就會用自己的理解去曲解敏捷。然后大家認為敏捷就是早晨開個會，月末開個會。最后的結果就是你在罵敏捷，我在夸敏捷，可是你嘴里的敏捷和我嘴里的敏捷根本就不是一個東西。
記得曾經見過一個CMMI的咨詢師，張口閉口卡耐基梅隆，一付兄弟當年在英國的時候的樣子。生搬硬套的CMMI流程。最后搞的那套流程根本不可操作，大家都為流程湊數(shù)據(jù)。當下如果大家都從CMMI倒向Scrum，這種人咋生存呢？會掛掉？錯，搖身一變，舉起敏捷大旗開始搖旗吶喊。沒這兩下子怎么能在忽悠界縱橫這么多年呢。像這樣的人都來搞敏捷了。敏捷不臭，那除非老天開眼了。那原來搞敏捷的人呢？本來就是小眾，在這大浪里面，估計很快就看不見了。。。。從今開始，我還是少說兩句敏捷了。。。
我習慣于在午飯后午睡一下。上班時午睡，只能是趴著睡。最近才注意到，寫字樓的空調大多是從上往下吹得，所以這個時候整個后背是暴露給空調的。從中醫(yī)上講，背上主要是兩條經絡。督脈和膀胱經。其中膀胱經主人體一身之陽氣。號稱人體最大的排毒通道。膀胱經不通的人可能會怕風怕冷，容易得濕疹等病，常年排毒不暢，可能會導致更多疾病。
體的經絡不管哪一條，都怕六邪，風濕熱火燥寒。對于處處空調的現(xiàn)代人，火燥熱遠不如風濕寒需要擔心。比如像這樣天天把后背暴露給空調，而且是在睡覺這種放松狀態(tài)下。就等于天天讓空調的風寒入侵膀胱經。加上很多辦公室都有加濕器。那濕也是跑不了。當然，人體自身有防御的能力，肯定不會馬上出問題的。但是天天這么搞，難免不出問題。上個禮拜加了幾天班覺得左肋靠近腋窩的地方疼。周末好一點了，今天下班前又痛了。引起我一點警惕。所謂猝死，大概就是這么一點點演變來的。干咱們這行撐不死可也別累死。
溫熱可以驅寒，我想把背緊靠一會靠背取暖。這時發(fā)覺我的椅子后背只到肩胛骨中部。好像很多公司的椅子都是這樣的，不能很好的護住背部（除了老板椅。老板椅上面似乎還要往前多出一塊來，連后脖頸子都能護住。倒是很養(yǎng)生。）
所以，辦公室可以放一件外衣，睡覺的時候披上來防風防寒。另外，可以偶爾的去做一些保健。比如拔罐，刮痧等。基本上背部拔罐就是在疏通膀胱經。背部刮痧也是。不過要注意的是：
一，拔罐的話，頻率不宜過高，拔罐是排毒比較猛的一種方式，體內毒多的時候倒是在排毒，毒少了以后，排的就不只是毒了。有一種說法，拔得太頻繁反而會有損陽氣。我比較認可這種說法。一個月一次或者隔一個月一次為宜。拔罐后六個小時不能洗澡。
二，刮痧倒是可以頻繁點，但最好找干凈的地方或讓自己家人做。肉少的地方盡量少刮。最近發(fā)現(xiàn)一種叫魔蝎刷的東西，個人感覺比刮痧板好用，可以替代刮痧板刷背。刮痧后半小時不能洗澡。從時間上也能看出哪個比較猛。
最后，多多運動是最好的保健方法。自我鍛煉總是要勝過別人伺候。愿程序員們都能度過一個健康的夏天。
沒“貢
獻”的田鼠
在田野里，住著三只田鼠。
秋天到了，三只
田鼠開始準備過冬的東西。
第一只田鼠每天都到田野上運糧食，準備冬天食用。
第二只田鼠每天都到田野上運野草，準備冬天取
暖。
而第三只田鼠每天都跑出去游玩，對糧食和野草一點兒也不關心，好像冬天永遠也不會到來一樣。
前兩只田鼠勸它為即將到
來的冬天多準備一些必要的東西，但它只是笑笑，仍然每天都出去游玩，經常玩到天黑才回來。
寒冷的冬天很快到來了，三只田鼠住在洞里，餓了
就吃第一只田鼠運回來的糧食，冷了就用第二只田鼠運回來的野草取暖，而毫無貢獻的第三只田鼠自然也得到了前兩只田鼠的嘲笑。
然而日子一
天天地過去，每天都無所事事地待在洞里，做著同樣的游戲，吃著同樣的糧食，三只田鼠漸漸厭煩起來，感覺到了無聊的空虛。
這時，第三只田鼠
開始為前兩只田鼠講故事，講它在秋天出去游玩的時候見到的許多新鮮有趣的故事，前兩只田鼠聽得津津有味，生活開始重新變得充實而有意義。
作
為感謝和報答，前兩只田鼠經常把自己的糧食和野草挑出一些送給第三只田鼠。
原來，有些貢獻并不是從一開始就能看得出來的，然而我們卻經常
因為暫時看不到它的“用處”就舍棄了它。
這篇文章是受啟發(fā)于要求我寫一些設計和spec的文檔的面試要求。趁這個機會整理整理自己的思路。
什么是軟件開發(fā)呢，最常見的一種說法是，軟件開發(fā)是一門藝術。我覺得更現(xiàn)實的講，軟件開發(fā)應該是一種生產。跟其他所有的生產一樣。要考慮成本和收益。收益這塊，跟其他很多外部因素相關，對開發(fā)者或者說開發(fā)者的管理者來說無法控制，開發(fā)者從職業(yè)的角度出發(fā)更多需要考慮的是成本。這也是我們職業(yè)的目標。
軟件這種產品的生產，材料本身的損耗也就是電腦，電費，基本屬于沉沒成本。不會因為咱們任何努力而改變。（也不是完全不能改變，只能是變多。。。。）那么，最大的成本損耗在時間上。一方面，程序員都屬于高薪人士（相對，相對）。每一天的損耗都意味著大量的錢打水漂了。另一方面，隨著時間的推移，商業(yè)價值在降低，風險卻在增加。
對軟件開發(fā)來說，需求實現(xiàn)速度，應該說是很重要的，但是實現(xiàn)速度本身并不是考量的標準單位。作為最大成本考量標準的時間，從對她的消耗來看：除去簡單的功能點實現(xiàn)需要，需求的變化浪費的時間則更客觀。而無數(shù)實例證明，我們在需求分析階段投入時間誠然可以減少需求的變化，但是并不能達到我們滿意的高度，所以對需求變化的反應也是我們的重要標準。
敏捷這個詞，我覺得非常好。做為一門方法學，從名字上就說明了軟件開發(fā)需要關注的兩個重要的點：需求實現(xiàn)速度和對于需求的反應速度。當然，說到這里有點虛了。我想，回歸到不太實際的本質，能更好的指導我們的實踐。Rails框架為什么這么火熱，恰恰因為它做到了這兩點。我們想想，為什么要設計？我讀過讓人舒爽的代碼，也讀過看著讓人想吐的代碼。拋掉個人的感情因素，這兩種代碼有什么區(qū)別呢？大部分讓我想吐的代碼里出現(xiàn)的是一些重復的代碼，看起來稍有不同，卻不肯費點心思除掉這些“壞味道”。重復代碼的問題在哪里呢？最大的問題就是隨著代碼量的增多，工作量的與日劇增。維護量也會增大。而且，復雜度絕對不是O(n)。其實我常常覺得，我們最早學程序的時候要學算法與數(shù)據(jù)結構。其實這個課程很早就告訴了我們編程最重要的兩塊：算法，結構。好的設計就是好的結構。可擴展，可維護，最起碼，可以分工。
好的設計可以大量的減少代碼。減少代碼就意味著成本的降低。也就是文初說的，我們職業(yè)的目標達到了。但是現(xiàn)實往往不是那么美好，雖然我們有很多OO的設計模式，我們有很多最佳實踐。但是在現(xiàn)實中，我們往往需要妥協(xié)。一般是三個原因：性能、穩(wěn)定性、各種接口，在左右著我們。其實，很多時候，這也是最考驗一個程序員的功力的地方。如何在這三個沼澤上跳舞，才是軟件開發(fā)真正可以被稱之為藝術的地方。而怎么做，則只能靠一行一行的代碼鍛煉，一篇一篇文章和文檔整理經驗，沒法一句半句說得清楚的了。
晨會是Scrum里的一個實踐。
最近才意識到，這種東西一點都不時髦。很多理發(fā)店，飯店，他們早晨都有這個。今天在大鴨梨看到他們的晨會，頗有感覺。看著他們都站在那里，覺得跟站立式晨會差不多。不同的是他們的員工，年齡層比較低，處于還比較毛糙的年齡。也就是說，不僅需要教育怎么做事，還得教他們怎么做人。所以在這個晨會上，經理教育他們說，不要混日子，十年后，你們如果沒做出什么來，一生就這么過去了。跟他們說，要當面說壞話，背后說好話。也就是進行人性和行事風格上的教育，也可以說是一種文化上的教育。經理教育完，幾個像老員工的來說加單要寫名字，不要怕寫了名字會怎么著等等。雖然是端茶倒水送飯，但是需要注意的還真是不少。前臺，服務員，后廚，這之間也是需要溝通規(guī)范，任何一個溝通不符合規(guī)范，就會出亂子。
比較起來，敏捷的實踐只是要求個人說自己做過什么，要做什么，有什么問題。不過我發(fā)覺，有些話，其實是應該在晨會的時候應該強化與灌輸，不見得是每天，但是隔三差五的就該講講。關于工作態(tài)度，配合。這是員工培訓的最好時機。在這里用力，雖然不會有奇跡般的效果，但每隔一段時間肯定會有一點切實的進步。企業(yè)與企業(yè)都是不同的，有自己的氛圍，那所謂的文化，就是企業(yè)的性格。員工與員工更是不同。但是企業(yè)喜歡的員工其實都很相似。不喜歡的員工卻各有各的不同。所以企業(yè)經常培訓員工。但我是不相信給員工搞一兩次課可以改變一個人的。有天在快餐店，聽到一個老銷售教育一個新銷售說，鴨子聽鷹講怎么飛。上完課，鷹飛回家了，鴨子還是走回家的。不能飛的鴨子又不缺什么，野鴨就能飛。所以，僅僅幾天的員工培訓能改變什么呢？不能指望著幾天就能給公司制造出好用的員工來。公司對教育的重視不夠說小了是不把自己的錢當回事，說大了其實是社會責任的缺失。
你們10年后還一事無成，這是給員工灌輸?shù)囊环N危機意識。要當面說壞話，背后說好話，這是對員工進行人性的教育。這像是領導說的話，有人說，領導兩個字是領袖+導師。身為導師不引導人光明磊落，就不能怪人言可畏。有喜歡以流言御人的領導才有大量到處嚼舌頭的下屬。現(xiàn)代企業(yè)不是古代的官僚衙門。該專心搞的是經營而不是政治。
散會后，員工繼續(xù)去工作了。你說這個晨會有什么作用嗎？不知道，就像一顆石頭扔進了平靜的水里。一陣激蕩過后我們什么都看不到了。但是，我想，日積月累，石頭扔得多了。在你不注意的時候，水面會悄悄上升的。
敏捷作為方法學，其實還是比較虛的。哪怕是其中比較實的最佳實踐，也是非常難以掌握運用的。原因其實很簡單。人要想通過敏捷偷懶是絕對不可能的。敏捷的實施，在最初肯定是非常累的。因為改變總是痛苦的。回顧豐田的歷史，他們在創(chuàng)造TPS的時候，工人們也是想把大野耐一的那些破爛東西都給砸咯。
不過很多時候，痛苦是幸福的開始。一個人完成很多人合作完成的工作，咋看起來是非常勞累的。但是習慣了，也就那樣了。TPS里面基礎就是讓一個工人具備兩項以上的技能。程序員也是一樣。不能為自己的懶惰找理由。大家都是人，都想懶，但是今天懶了，總會有一天被逼著勤快。就好像沒有時間鍛煉，就有時間生病一樣。只有每個團隊成員都變得敏捷了，敏捷的方法才有意義。
時間。。。曾經是我最害怕的東西。。。如今卻變成了最喜歡的東西。。。
這個世界紛紛擾擾有那么多的真實與虛假
只有時間能把它們分離開來。
時間，跟所有自然的偉力一樣，從來都是緩緩的，慢慢的顯示著自己的力量。
人可能等不及看到它的效果，可它卻一直履行著自己的職責
一切浮于表面的虛幻，終會在時間的侵蝕下消逝，只留下最真實的東西。
google上搜這個詞，搜到的很多是征文，和一些扯淡的文章。
跟這篇文章一比就差的比較遠咯：
http://www.dapenti.com/blog/more.asp?name=xilei&id=15410
節(jié)選精華“中國夢”解釋如下：
如果有人問什么是中國夢？我說，只要你看看這個國內的精英怎么選擇的，你就知道了：
【1】讀書，考上清華北大，然后，到外企工作，出國，拿綠卡；
【2】唱歌跳舞，不惜一切代價成名，出國，變更國籍；
【3】當官，貪污腐敗，找機會逃跑到國外，躲起來過一擲千金的日子；
【4】做生意，賺到足夠的錢，然后，出國定居，想生幾個孩子就生幾個孩子，讓小孩都在國外上大學。
BlogJava，應該是一個技術博客。倒回來看自己寫的東西，卻感覺離題越來越嚴重。
對技術的熱情在衰退。所寫的技術相關的東西越來越少。
從Java到Flex到Grails。技術照理增長了不少，人卻越來越迷茫。
對文科的興趣在增長，已然超越了對程序設計的興趣。
可是做的工作又不得不繼續(xù)從事程序設計的學習，不然一旦失業(yè)了，我又能做什么呢？
所以每當看一些文科的書，就會有一種罪惡感。人活成這樣，不得不說是一件悲哀的事情。
其實心里明白，所謂悲哀在旁人看來不過是一種吃飽了撐著的心態(tài)。
買了域名和空間，準備換一個獨立博客了。到時想寫些什么就寫些什么了，也不用擔心站方有問題。
最近一直在看跟豐田生產體系有關的書，得到一些很有意思的知識點
- 剛明白原來這些個名詞他們是JIT->TPS->Lean->Agile這么一個關系。
-
豐田老總一拍腦袋提出3年之內超越福特。這種感覺就像好像有一家中國軟件公司一拍腦袋說，三年之內超越微軟一樣。我要是執(zhí)行人，只會覺得上邊又發(fā)神經了，這不是瘋了嗎？結果大野耐一到底是大野耐一，竟然真的找到了方法。
- 生產過剩的浪費
- 制造不良品的浪費
- 停工等活的浪費
- 動作上的浪費
- 搬運的浪費
- 加工本身的浪費
- 庫存的浪費
-
豐田的思路其實簡單到了不能再簡單，利潤=銷售價格-成本。那么在經濟增長無望的時代，減少成本就等于創(chuàng)造利潤。過去的時代是一個經濟高速發(fā)展的時代。就像日本泡沫經濟時代一樣。但是泡沫破裂的時候，豐田反而崛起。類似的如學習TPS的佳能，在5年內銷售沒有增加的情況下，利潤增長十倍。
- 面對一個即將來臨的經濟增長放緩的時代，成本開始成為管理者嘴上流行的新詞應該是下一步的趨勢。
-
軟件開發(fā)中的浪費有哪些呢？我現(xiàn)在想不到太多。但是跟朋友聊天我突然意識到，猶豫也是一個巨大的浪費。作為一項腦力勞動，開發(fā)時的猶豫就如同停工等活的浪費和動作上的浪費。這種事情其實可以避免，我開始明白TPS這樣一個強調變化與改進的過程，為什么還如此強調標準化。應該就是通過整理最佳實踐并確定為標準流程來減少重復犯錯與猶豫造成的浪費。那么結對對效率造成的改進，別的不提，減少了猶豫的時間應該是很重要的一點。而這也是在水面以下最不容易被發(fā)現(xiàn)的浪費。因為猶豫和謹慎，從表面上看，似乎是一樣的。
通往天堂的輪船和通往地獄的輪船燒得都是同一種燃料，那就是人類的欲望。
記得小時候看《讀者》這本雜志，里面有一個故事，上帝帶一個人去參觀地獄，地獄里支著一口大鍋，鍋周圍坐著一群人，每個人拿著一個很長的勺子，因為勺子太長了，想要吃東西，經常會碰到別人，所以互相之間總會打起來，結果所有人都吃不飽，人人臉上充滿著憤怒和痛苦。然后上帝帶他又去參觀天堂，結果天堂里跟地獄的擺設一模一樣。但是人人臉上洋溢著幸福，原來，這里的人會用長勺子喂對面的人，所以，每個人都能吃飽。
同樣的配置，同樣的人，同樣都有吃飽的欲望。一處是天堂，一處是地獄。現(xiàn)實中也是如此，一個好的游戲規(guī)則，游戲中便是天堂，一個不好的游戲規(guī)則，游戲中便是地獄。
相傳，有兩個嫌疑犯,合謀殺死了一個人，之后被警察抓住，警察將他們分開審訊。并告訴他們說，如果你們兩個人都不說的話，以我們現(xiàn)在的證據(jù)，我們可以讓你們坐一年的牢。如果你招供了，而你的同伙沒有招供，那么我們將當庭釋放你，你的同伙關20年。如果你和你的同伙都招供了，那么我們也就沒有必要照顧你們任何一個，你們一人關10年。
這就是著名的囚徒困境。處于困境中的囚徒，該如何選擇呢？
如果我是那個囚徒，我不說，你說了，我被關20年。你說了，我也說了，我關10年，只有你不說我不說的情況下，我還要關1年。這里還有一個極大的誘惑，那就是我說，你不說，我可以當庭釋放。人性如此不可靠，綜合判斷的話，還是說最保險，保不齊還能當庭釋放呢？不如賭一把。
這就是我全部的如意算盤，可惜，另一個囚徒他又不傻，他也會這么想。于是，利益最大化的可能性變成了永遠不可能達到的彼端。而10年這個選項變成了我唯一的下場，也是我們雙方唯一的下場。這個次壞的結局被稱之為雙輸。我們追求的利益最大化的那一點被稱之為單贏。而每人都得到次好的那個看起來更不可能的選項被稱之為雙贏。
這個故事中其實并不虛幻，現(xiàn)實中的我們都是這樣的囚徒。想想日常中遇到的一些類似的情況，真的是非常的熟悉。
現(xiàn)實中的情況復雜一些，可是道理相同。我們每個人都追求自己的利益最大化，可是長遠來看，最大化的利益或不曾降臨，或稍縱即逝。我們最終得到的只有那個次壞的選項。不過還好我們還可以合理化，安慰自己說，總算沒有到最壞的結果。但實際上我們明明可以到達雙贏的結局。
從剛知道這個故事的時候，我就發(fā)覺工作中的情況與此非常類似，于是我想，應該找辦法擺脫這個困境，遠離雙輸，通往雙贏。我覺得，憑借敏捷方法我可以不用陷入這個困境。可是我錯了，以前的困境拼圖并不完整，敏捷方法恰恰是補完了這個困境通向雙贏的那最后一塊拼圖，至此一個完整的囚徒困境才算是建立完成了。有誘惑，有陷阱，有希望，于是也就有了困惑。于是，困境始成。
在這個困境里，企業(yè)那點道道，就不說了，大家都很熟悉，可是作為我們程序員，就多么高尚嗎？
敏捷要求全能小團隊，可對于程序員來說，只干自己擅長的那一攤事，然后拿工資是利益最大化的選擇。抽空還能自己學點東西提升一下自己。或者聊聊天、泡個論壇、玩?zhèn)€網游什么的。我們自己做出了并不比企業(yè)高多少的選擇。通過雙方的不懈努力，終于，企業(yè)和我們達到了雙輸?shù)慕Y局。簡直就是悲劇。悲劇一再上演著，卻沒多少人太在意，至少大家都可以安慰自己說，總算沒有到最壞的結果，一定是哪里做的不夠好，再改進一些會好的。可惜，自然規(guī)律是很無情的。你做了這個選擇，就只有這個結局，于是悲劇一再上演。
沒有解決的辦法嗎？有，當囚徒困境不是模型里的單次博弈而是多次博弈時就有解。可以采用一報還一報的方式，當一方選擇個人利益最大化的選擇時，那另一方也選，直到對方放棄。也就是不停的雙輸，并且溝通，直到大家一起回到雙贏境地下。這就是囚徒困境的唯一破解之法。只可惜這個方法也有問題。第一個選擇個人利益最大化的人會在這個方法中獲利。如果利益比較大的話，反復幾次，他就可以有機會破壞這個平衡，將雙贏博弈再次變?yōu)榱愫筒┺摹Ｋ裕瑧土P機制也是很需要的。
方法有了，可是模型畢竟是模型，現(xiàn)實比這復雜得多。在囚徒困境之外，你會發(fā)現(xiàn)，還有團隊這個群體存在。當一個人做選擇很容易，當一群人做選擇的時候，就很難了。按照大眾心理學的說法，群體幾乎是沒有意識的。所以這個時候，我是只能感慨個人的渺小了。
價值,所有的方法學都會指向這個詞。
可是所謂的價值，有的時候說得清楚，而有的時候很難說得清楚的。客戶說出來的清楚，但有可能根本不是他最需要的。如果天下的人都清楚的知道自己要什么，也許也就不會有什么方法學了。
就考慮我們自己吧，我們想要什么？錢，沒錯，誰都需要錢。但要錢干嗎呢？在錢的背后是我們追求的價值。大家都想讓自己的價值得到體現(xiàn)。可是這簡單的一句話在每個人身上卻有不同的含義。
客戶提出需求的時候總是欲求不滿的，仿佛跟上帝許愿一般。可是我們畢竟不是上帝，只是勤勞的工匠。工匠是一種介于藝術家與科學家之間的職業(yè)，是兼顧感性與理性的一群人。在我們的身上有像藝術家一樣追求超越自我的性格也有像科學家一樣鍥而不舍追求真理的性格，制造出對人們有用的工具是我們最大的價值體現(xiàn)吧。可復雜的現(xiàn)實，讓我們這么利他的追求也難以實現(xiàn)。
紅警、星際、暗黑。還有人記得當年的這三個偉大的作品同臺競技的那個時代是怎樣的情景嗎？
不記得也沒關系，因為這個時代又要來臨了！
這次是紅警3、星際2和暗黑3.哇咔咔，未來的幾年不會太無聊了。不要太沉迷于游戲中才好，呵呵。
昨天，蓋茨離開了微軟。對我來說那一天只是一個普通工作周的結束，對微軟來說，卻是一個時代的結束。
用蓋茨大叔的操作系統(tǒng)的歷史跟我接觸電腦的歷史一般長。從最早的dos到win32到win95、98、me、xp、2000、2003、vista。我?guī)缀跤眠^微軟的每一代操作系統(tǒng)。經常會罵微軟垃圾，可我也從來沒掏錢買過正版操作系統(tǒng)，這種罵多少有點齷齪。
時隔若干年之后，總算我也用上了正版的windows（筆記本送的Vista）。回想起來，一些往事不由得浮上心頭
最早的時候接觸的dos已經記不得是哪個版了，286時代的，而那個286電腦大概長成這樣：
但是開始正式學的dos應該是6.22的：
那個時候裝機只需要一張5存盤：
后來才有的3.5寸盤：
那個時候盤經常壞，所以3.5寸盤的塑料盒和5存盤的紙袋是很重要的東西。
后來，接觸到的第一個圖形化的操作系統(tǒng)是windows 3.2，那個時候我并不知道apple是什么：
操作起來大概是這么個感覺：
沒有任務欄、沒有開始菜單，非常詭異。再后來的，就是windows95了吧：
win95的界面比較經典，可以看出來現(xiàn)在的windows界面相比win95其實沒有太大的變化：
當時的游戲大多都是在dos下的，機器內存又小，為了玩游戲需要切到dos下，關掉95。即便在這么困難的環(huán)境下，依然有偉大的作品誕生：
。。。。
那個時候，很多游戲的安裝需要靠一個叫arj的解壓工具：
中間還有一個改進版的95，被稱之為win97，至今我也不知道到底有沒有那么一個正式的97出現(xiàn)過，反正很快，98就誕生了：
回想起來，那年開始，我接觸的游戲開始變多，我永遠忘不了我看到星際的時候的感受：
在那個時代，還有一個稱得上傳奇的病毒---CIH，以其可以對電腦造成物理傷害而聞名：
98是一個及其不穩(wěn)定的操作系統(tǒng)，解決98里一些較大問題的唯一法寶往往就是重裝，也許正是因為他如火鳳凰一般的再生能力，一直到2000和xp誕生之后都有人選擇他做自己的操作系統(tǒng)。
而win me。。。很多人根本就不知道他的存在：
不知道現(xiàn)在有幾個人知道win me安裝完第一次啟動時必須忍受那個開機動畫的事。再后來就是2000了，其實在win32時代就有windowsNT，微軟用它在服務器市場里戰(zhàn)斗，不過我個人并沒有用過，windows 2000是我接觸的第一款微軟的服務器級別的操作系統(tǒng)：
到了windows 2000之后我對微軟的怨言已經少很多了，呵呵。之后微軟家族的產品越出越好，只不過漏洞和病毒依舊多不勝數(shù)。XP和2003就不回顧了，反正他們還不算歷史。看看前面的這些東西，想想蓋茨大叔的退休，該說些什么呢？私底下罵了微軟若干年了，反過來看，微軟也給我?guī)砹撕芏鄻啡ぁＲ苍S，應該對他說一聲，謝謝。
前些天跟朋友聊天，聊得很激烈，我也收獲很多。
中間聊到過程，朋友認為，管理的最高境界應該是沒有過程，但仔細一問發(fā)現(xiàn)，還是有過程的，只不過是一些更人性化的過程而已。結合我另一些朋友的觀點，看來“過程”這個詞有點招人恨了。（當然如果是瀑布式的過程的話，我會第一個跳出來恨的,:P）
我一直認為過程這種東西，做不好就是枷鎖，做好了就是鎧甲，讓你在工作中左沖右時保障你的安全。這次敏捷大會跟o6z聊天時，他說，雖然他老說敏捷，但他
其實是一個很偏好重型過程的人。其實還是我的那個比喻，只不過重型的鎧甲也是鎧甲，更適用于直線沖鋒陷陣的重裝騎兵，但是你要是隨便找個步兵團隊來配上重裝騎兵的鎧甲，估計還沒打就被壓死了。
關于過程這個東西，很有趣。既然想到這了，就像抽取一些自己的零散思維放上來。
我琢磨XP有很長一段時間了，Scrum也看了一段時間，就個人來說，不是很喜歡Scrum。總覺得這個東西天生帶有一點滋生官僚這種細菌的潛質。常聽說
XP沒有管理的內容，Scrum在這方面做的更好。可我還是覺得Scrum沒提供什么東西，完全可以把Scrum的一些東西吸收到XP中，結合自己的團隊
實踐搞一些混合敏捷（Hybrid
Agile）。因為Scrum在管理方面做的東西并沒有多少，實在算不上盔甲，頂多是個盾牌。比較起來，XP的話，倒是有豐富的價值觀和配套的實踐，在吸
取了它的一些本質的東西之后集合公司實際做一些定制化的管理框架更好。
下一步準備研究一下FDD，再考慮跟前面?zhèn)z方法混搭一下。我感覺這搞過程越來越像J2EE開發(fā)了：Struts + Spring + Hibernate一樣的玩法。
第110集的銀魂非常的搞。桂入獄了，而且是號稱從未有人逃出來過的監(jiān)獄，里面關的都是罪大惡極的人，但是入獄的領袖到底還是領袖，很快他就成為了監(jiān)獄中的老大，并且給這些終生無望的人帶來了改變，每天的勞改變得不再無聊，人人都有了目標，臉上都洋溢著希望，乏味的人生從此有味道起來。。。。。當然，這終究是一部搞笑的動畫片，前半截不管鋪墊的怎么熱血，最后一幕還是抖出包袱：前面只是陰錯陽差得演了一場各懷鬼胎的陰謀鬧劇。。。囧rz
雖然是搞笑的，但是那些洋溢著希望的臉，卻在腦海中怎么也驅之不去。監(jiān)獄是人生的地獄，那里的色彩只有一種---灰色。如果是終生監(jiān)禁，這種顏色還會伴隨你一生，成為你余生的主色調。進入監(jiān)獄的人，在第一夜關燈的剎那開始明白，自己的人生從此完了。彩色的世界已經離自己遠去，剩下的時間里只有單調的監(jiān)獄生活，不會再有希望。在那個世界里，幾乎不會有那樣的神情、那樣的臉，只有充滿戾氣的臉才跟那個環(huán)境般配。當這個動畫以夸張搞笑的手法把一張張這樣的臉呈現(xiàn)在我眼前的時候，我的第一感想竟然是羨慕。。。。
是啊，羨慕。我驚奇的發(fā)現(xiàn)，希望在我的詞典里被擠到某個小角落很久了。感謝一些人，讓我看透了一些事情。同樣也虧得他們，我開始不再抱有幻想，變得更加理性，雖然人生不再有明確的方向，卻敢于邁出自己堅實的腳步。這種沒有方向感的自信我不知道是什么，但是在這種自信的世界里，沒有希望的存在。偶爾升起的希望很快會被我的理智所設下的“幻想偵測系統(tǒng)”預測到并驅散。（目前這個系統(tǒng)的誤殺率還真不是一般的高啊。）
走在地鐵站中，看過往的人群，有各式各樣的臉，有幸福的、有木訥的、有暴戾的、有冰冷的，也有洋溢著希望的，對于見過的部分人們，說實話，真的有很多看起來充滿希望的，不過有些是因為沒心沒肺，有些不好說是因為勇敢還是無知，或者說不準是因為無知而勇敢，更多的是讓通過一種眼不見為凈的手法，讓自己的人生有希望起來，可是當真想到未來時，總會有一陣陣恐慌。
我想，希望這種若有似無的東西，看起來很沒有價值，實際上卻可以很有價值。一個人生活中充滿希望，那么他是幸福的，他就會有安全感，工作也會賣力許多。有什么理由不給人們帶來更多的希望呢？如果我們的團隊被希望所籠罩，我們的團隊就會有更大的活力。對于軟件這個行業(yè)，非常需要注重人。希望，是對人非常重要的一個東西。那么我們的團隊建設者們，是不是也應該注意一下這個東西呢？
早在工作之前，就有學長們、老師們諄諄教導說，語言不要貪多，學一門語言學到精，其他語言再學就很容易了。
我是這么做的，而且，做的有點過。很長時間里都扎在Java的世界里不肯出來，找開源工具也一定要找基于Java的。最早找一個Wiki都執(zhí)意要找Java的，找到了JSPWiki。也因此認識了BeanSoft和Java Ajax群的朋友們，呵呵。
但是，隨著開發(fā)任務的變化，不得不去學一些其他的語言。沒辦法，人在江湖身不由己啊，所以，也就開始了多門語言的學習之路。javascript可以說是我學的第一門“外語”。最早的時候對js的應用，也就簡單用一下得了。后來隨著時間的推移，覺得將來脫不了要靠它吃飯，也就主動買了幾本JavaScript的書，慢慢的去啃，甚至啃到了很多對我沒什么用的高級的特性，再后來工作需要，接觸了Flex，js用的就少了，也就慢慢的放下了。
ActionScript是我接觸的第三門外語。也是用心比較大的，呵呵，很長一段時間里甚至熱情超越了Java。中間根據(jù)個人興趣還看了點Ruby。
隨著實踐的增多，對語言的恐懼心理下降了。反而發(fā)現(xiàn)了各個語言所在世界的優(yōu)勢。每個語言所在的世界里都有非常優(yōu)秀的東西。最早想做一個手腳架，看了一下Rails，是基于Ruby的；為了測試Flex，研究了FunFX，也是基于Ruby的；前不久在部門里搭建了一個wiki，是基于PHP的；這段時間又研究了一下Trac，是基于Python的；研究Trac的時候發(fā)覺它可以跟Bugzilla集成，而Bugzilla是基于Perl的。這么多優(yōu)秀的東西，讓我覺得學習多門語言的困難變得無所謂了。
上次去OpenParty，參與了鄭曄的那個session。他講了自己在項目中使用多種語言的經歷。其實很有趣，作為只會一種語言的人來說，他覺得學多門語言會讓自己泛而不精，然而真正掌握多門語言的人卻發(fā)覺，他山之石可以攻玉，當你學會別的語言之后反過來在使用以前的語言的時候，思路會變得異常開闊。不管是對設計模式的領悟上還是對架構的組織上，都達到了一個更高的高度，反而更加精深了。
回來后，我也想了很多。記得早前看o6z一個帖子講，SOA之所以風行，很大原因是因為企業(yè)已經積累了一些設備和軟件。因為金融風暴也好，因為經濟衰退也好，因為成本考慮也好，因為這這那那也好，不想統(tǒng)一成一個，需求決定供給，所以SOA才風行起來。那么這樣一個環(huán)境對我們開發(fā)人員的會不會有什么影響呢？而且開源風行的今天，我們的軟件行業(yè)也已經積累了一批財富。我們業(yè)內的人，也是不想統(tǒng)一替換成一類語言的，那么市場上的需求會不會慢慢變得要求我們程序員必須掌握多種語言呢？其實現(xiàn)在已經這樣了，我就是一個例證，我的變化不是我主觀想這么做的，而是一只看不見的手---市場推動的。不過我個人預測未來可能會更嚴重，如果JVM成功變成一個可以跑各種動態(tài)語言的超級平臺的話。
瘋泉的故事一直困擾著我---相傳，有一個國家，有一口瘋泉，喝了泉水的人都會瘋，很快全國人民都瘋了，只有國王是正常的，在國民眼中看來國王是不正常的，其結果就是國王被灌下瘋泉水，成為了瘋子，全國狂歡。作為旁觀者看來，你告訴我，國王是對的？還是國民是對的？
可是跟所有的故事一樣，故事總是只強調問題的一方面，我反過來講這個故事，如果全國人民都沒瘋，就國王瘋了，國王認為，不行，全國人民得跟我這樣，于是想法設法讓全國人民喝上瘋泉水。那么現(xiàn)在作為旁觀者你告訴我，國王是對的？還是國民是對的？
現(xiàn)在有一個國家，有兩口泉，一口是瘋泉，一口是醒泉。喝了瘋泉的人會變成瘋子，喝了醒泉的人會變成正常人。最早國家的人全變成了瘋子。機緣巧合，國王喝下了醒泉。清醒過來的國王想讓國民都醒過來，想讓國民喝醒泉。而國民發(fā)現(xiàn)了國王與自己不一樣的地方，于是將國王灌下瘋泉水，國王再次瘋了。那么現(xiàn)在作為旁觀者，你告訴我，國王是對的，還是國民是對的？
其實三個問題都挺簡單的，第一個：國王是對的，第二個，國王是錯的，第三個，還是國王是對的。可是，我現(xiàn)在再給旁觀者的你一個新情報，三個故事是一件事，只不過是三個人講的，所以出現(xiàn)了三個版本。其實我還能講一個故事，就是把第三個故事反過來講，大家自己想去吧，相當于第二個故事的擴展版。如果是這四個故事一塊看，你說誰是對的呢？是“群眾的眼睛是雪亮的”呢？還是“真理掌握在少數(shù)人手中”呢？
如果到現(xiàn)在你還沒有被我繞暈了的話，應該心中還能響起柯南的那句話：“真相只有一個”。沒錯，所以你只要找到那兩個泉，搞清楚到底哪個是醒泉哪個是瘋泉就好了。真理，自然就知道是掌握在誰手中了。繼而也就可以證明國王是對的，還是國民是對的。
可是，事情沒有那么簡單，你率領的觀察隊發(fā)現(xiàn)，兩個泉水是兩口魔泉，你喝下一口泉水的水，你就有擁有了一種價值觀，喝另一口泉的水，就擁有了另一種價值觀。兩種價值觀是對立的，但是，誰知道哪種是瘋的呢？事情變得更復雜了。。。難道在這個事件中我們無法證明什么嗎？誒，還真有一個，你證明了，這個國家有兩口魔泉，不是一口。
這世界上有很多事情就是這樣，撲朔迷離的，就算最終謎底揭曉，發(fā)覺反而不知道對錯了。可是如果我們一開始就知道這些，我們就能知道對錯了嗎？還是不知道啊。不過呢，這種問題，我們苦惱，精英們比我們更苦惱。早在我們考慮之前，精英賢者們就在考慮這些問題了，并得到了一些結論。最早的時候，老子就說，有錯才有對。這說法比較言簡意賅，乍一看就是句廢話。我以前也覺得他是句廢話，知道有一天看到了另一句話，才明白他老人家的微言大義。這句話就是：“可以被證偽的命題才是科學的命題”。這話聽著跟我們日常里對科學的印象不太一樣呢，我們常說，你這個說法不科學，那意思就是不對。科學當然是對的，證偽，證明是錯誤的，那種東西怎么能算是科學的呢？可惜，事實正是如此，所有科學的命題都是可以被證偽的。科學也正是因為信奉這一條原則，所以才可以自我修正，自我進化，以致今天的高度。
所謂可以被證偽不是說這個東西有錯誤，而是說，你這個命題天生帶著可以被推翻的情況出生的。比如，曾經有人懷疑進化論的科學性，說你這個東西無法被證偽，進化論的擁護者就說，你只要找到一批侏羅紀的兔子或者猩猩化石什么的，那么進化論就被證偽了，因為進化論說物種的進化一定是從低級到高級。這種情況，我們稱之為可被證偽。指一個命題能夠被推翻。什么是不可被證偽的呢？比如說什么是美的，我們常說情人眼里出西施，那美自然是無法被證偽的東西。藝術的東西，大都是無法被證偽的。無法被證偽的東西，自然沒有錯誤，沒有錯誤的東西自然就沒有正確。像這樣的東西，就不要追求什么對錯了，硬要追求，只有自討苦吃。
前一陣跟一做企業(yè)文化咨詢的哥們混了一陣，從他那瞅見一書，挺有意思。叫《公司基因》，看著不錯就買了。
這OpenParty是不興推薦書了，下次再有機會就推薦這個。
這書里認為企業(yè)文化不管怎么變，他的DNA都是由四個元素組成的，即：組織架構（原詞是structure）、決定權、信息、激勵機制。
它根據(jù)這四個元素把企業(yè)分成了七種類型
- 消極進取型
- 時進時停型
- 過度膨脹型
- 過度管理型
- 隨機應變型
- 軍隊型
- 韌力調節(jié)型
其中前四者看名字就知道不是什么好東西，書中也定義為不健康的企業(yè)。后三者，雖然都算是健康的，但最好的其實是最后一個。
敏捷常常被說是一種文化，我也這么覺得。所以，我最近一直讓自己從這四個角度看敏捷的方法學。分析來分析去，反而搞不清敏捷應該塑造一種文化，還是某種文化是維持敏捷的土壤。有點雞生蛋蛋生雞的意思。不過不管哪個生哪個，如果目的是養(yǎng)雞，那誰先誰后就不是我關心的了。
這本書前面部分寫了太多關于案例的內容。沒有足夠形象的講解Scrum。也沒有充分描述Scrum的假設、適應情況和不適應情況。講Scrum的風格跟微軟的講師講座倒是真挺像。
書中的Service1st公司的案例跟我們部門的情況極其相似。最后他也沒解決，只是說Scrum在現(xiàn)有的形勢下帶來了什么好處，有些失望。不過仔細想想，這個團隊的問題不是軟件開發(fā)方法的問題，而是企業(yè)文化的問題。所以Scrum解決不了是意料之中的。
但是這本書，說實話，不是特別經典的一本書，大概看看吧。
敏捷是以消除浪費、提高質量為目標的。但是有些時候總能見到一些原教旨主義者指出，重構也是浪費、結對也是浪費、討論也是浪費。然后呢，又有人提出，XX是必要的浪費這種說法。
想了一下，XX是必要的浪費這個說法其實不確切，只能說，這些東西是必要的成本支出。所謂浪費，必須從經濟學角度講才行。不然世間一切都可以帶上這個難看的帽子。
從牛博網最近新來的騙銀老師那里學來一個概念：“經濟學上有個奇怪的概念叫‘冤死的損失’（deadweight loss），英文的直譯是‘未被釋放出來的能量損失’，那是說，有一部分損失，...”誰也沒拿走，“...但因為效率原因，它就那么憑空損失掉了。”
因為聽起來很玄，為了讓大家更好理解，騙銀老師在后面講的一個非常耳熟能詳?shù)睦樱?br />
“
我雇了一幫人，天天就負責刨坑，刨了然后填上，然后再刨開，再填上（這例子不荒謬，中國隨處可見），我發(fā)給他們工資，這一來一往國民生產總值（GDP）就上去了。看起來誰也沒損失什么，對不對？只是簡單的財富轉移。其實不然，這里面有巨大的浪費，因為這些錢、這些勞力本來可以用在其他更為有效的生產上，可都用來刨坑了，那就是浪費。”（其實個人這個例子還不夠形象，如果挖坑和填坑的不是一批人，他們自己根本就不知道自己做的是浪費的事情，就知道干了活，拿錢，而且還為挖坑和填坑做了很多過程改進，提高工作效率。那就更形象了。）
所以說，您不能因為某些工作做了您能看到效果了，就不稱之為浪費，而有些工作做了您看不到效果就稱之為浪費了，應當反思一下是不是自己眼界不到。
離職將近，我在交接工作之際，因為我最熟，所以要我把依賴我負責模塊的其他模塊的適配器類改至新版。自己搬著Mingle寫了一些故事卡，又用CC寫了一
些持續(xù)集成的腳本。接下來，我還會去寫測試用例。整個過程中，沒有一行有效代碼的產出。在以代碼計績效的角度看，我的工作就算是浪費。可是，大家應該知
道，沒有這些東西，先不說我會不會在開發(fā)的時候保證質量。就說我離開以后，當產品質量出問題了，誰來保證？我可以根據(jù)異常一眼看出問題可能出在哪里，新接手的人能嗎？如果他改了程序，能保證不會按下葫蘆起來瓢嗎？他需要時間去犯錯去學習，這個時間，沒有產生新的價值，這才是真正的浪費。而且這也就成了挖坑-填坑的模式了。
問題反過來了，我做好這個CI的環(huán)境走了，來了一個新人接手，會怎樣？一天，系統(tǒng)報異常了。他有我的測試環(huán)境，而且，還是可以運行的。他可以很快的寫一個測試用
例，并開始調試，即便他無法理解整個設計，那不妨礙他快速的修復Bug。而且，因為以前的測試用例可以自動運行，他還可以保證自己的修改不會導致之前的功
能出現(xiàn)問題。一個為產品而組織的團隊，離開了某個特定的人，產品仍然可以自我完善，能完成這樣的目標的手法才是最有價值的。
很多人擔心前期花費的時間太多，后期就更沒時間，問題又來了。前期花費的時間多，是浪費掉了，還是合理的用掉了？如果是浪費掉了，自然不應該，如果是合理的用掉了，那是必須的。我們學軟件工程的時候都學過，一個問題發(fā)現(xiàn)的越晚，改正他的成本就越高。后期所謂的沒時間，就是因為前期太多問題沒有修正。
說道這個前后期的問題就不得不提最近一次結對的經歷。在我的堅持下，總算完成了一次與同等水平開發(fā)人員的結對編程。持續(xù)時間有三天。與同等水平的人結對，感覺是不一樣。也發(fā)現(xiàn)了很多以前沒有發(fā)現(xiàn)的問題。這都是個人問題，脫離我本人就沒有意義了，所以也就不說了。主要說一下心得。這三天的時間里做了一件什么事呢？推翻以前分成兩個模塊的應用，合成一個。兩個人做一件事，大家可以隨時根據(jù)今天剩余的時間做工作的調節(jié)，精確到小時。因為了解的信息不同，可以快速傳遞，合作互補，當他提出一方案的時候我可以快速告訴他，我這邊沒有問題，減少了嘗試造成的時間浪費。因為兩個人一起做，腦子根本停不下，一個人停了，另一個人還在轉，帶著你不得不進行。一天的有效工作時間在6小時以上。而分開的話，基本上能有3個小時就不錯了。
（中間發(fā)生的一點插曲。因為結對開發(fā)從不了解的人看來，是一件很浪費時間的事情。所以出現(xiàn)干預結對的現(xiàn)象出現(xiàn)，理由是擔心做不完。我覺得，如果不是堅持的話，就真的做不完了。從現(xiàn)實中看來，強調浪費，很容易被偷歡概念。而偷換概念的人很多人都沒有做過仔細的考慮。純粹的想當然。）
今天公司過了CMMI 4級，5級沒過，聽老外講述什么是5級也就是說什么是持續(xù)改進以后，感覺到CMMI的持續(xù)改進和Agile的消除浪費其實是一枚硬幣的兩面，持續(xù)改進就是消除浪費，為什么這么說呢？CMMI的持續(xù)改進本來就是高級別的過程域，那個時候指望重大變革基本就不靠譜，所以這個時候，看不管哪個行業(yè)，都會走向消除浪費的方向，軟件開發(fā)也不例外。CMMI的持續(xù)改進要求一直做一直做，那跟敏捷要求的追求精益的觀點是一致的。
CMMI認為通過4級的度量形成了穩(wěn)定的過程之后，5級就應該是對4級過程的不斷改進，什么時候看，都是不滿足的，值得修改的。那種精神不正是敏捷的世界觀嗎？CMMI給出了一堆過程域和目標，并沒有告訴我們怎么實現(xiàn)，Agile就更粗狂，不過大家提到Agile其實想到的是XP。所以覺得Agile就是一堆實踐而已，沒關系，不去爭辯這個問題。我就看XP，XP的那12個最佳實踐，跟CMMI的思想一點都不矛盾。（細節(jié)不可考，因為很多時候我很難清到底是CMMI里面就定好了這細節(jié)還是我們的EPG定的）。以前的時候只是粗略的感覺這兩者可以不矛盾，現(xiàn)在培訓過后，更證實了這點。
============
縮寫解釋：
Agile 敏捷
CMMI 能力成熟度模型集成
XP 極限編程
EPG 企業(yè)過程小組
不知不覺做這個產品已經一年了，其實除了技術積累，對這個產品的概念基本是處于原始階段。雖然早已經過了企業(yè)內容管理與網站內容管理的疑問階段。但是內容管理本身是對企業(yè)有什么價值，問了很多人。很多人的回答都不讓我們滿意，因為他們回答的其實是工作流有什么價值、OA有什么價值、文檔管理有什么價值、ERP有什么價值。
昨天聽一位曾經實施過FileNet的同事說了一句話才明白過來這個東西的價值在于“提供一種海量非結構化異構文檔的查詢服務”，其余的都是在其之上的附加價值。
價值有了，可是越看越沒底：“海量”、“非結構化”、“異構”僅一個關鍵字就夠麻煩的了，三個拼一塊。。。很好，很強大。。。。。
這兩天為了Fluorida的closePopUp功能，讀了點Flex框架的源碼，對Alert，TitleWindow以及Flex的PopUp功能做了簡單的分析。
【Alert和PopUp】
Alert內部其實是調用了PopUpManager.在parent參數(shù)為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處的位置沒什么區(qū)別，我想說的是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哪里學到界面開發(fā)過程方面的一些非常優(yōu)秀思路，今天參加RIAmeeting的時候還討論了更細節(jié)的開發(fā)人員和設計人員配合的問題。這次的好topic太多了，只能挑著最感興趣的聽了，次感興趣的其實也很想去聽得，比如精益、CMMI & Agile、巨富客戶端，這一說起來好像哪個都想聽了，但只有在好看簿上看了，這種不完美別有一番吸引力，還有些沒選上的topic其實也不錯的。希望下次有機會聽到。Open Party給我的東西太多了，每次想說的時候就被教育一次自己的語言能力有多貧乏。
這次RIAmeeting也不錯，見到一些老朋友，也見到了沒有見過面的朋友。而topic呢，說實話，我已經過了對技術普及的topic感興趣的階段了。所以兩個主要的topic都不是很吸引我，而這半途蹦出來的一位90后的小兄弟貢獻的topic給了我不小的震撼，他的作品雖然還有點稚嫩，但是可以看到很多創(chuàng)新點和一些真正的產品級設計。看到了一個如此鮮活，沒有被教育體制的“壓模機”殘害過的頭腦，感覺真是不錯。（腦子中閃過“炸學校”短片里的那個壓模機）一年、3萬行代碼，高二，這幾個關鍵加在一起，讓我覺得這個小兄弟的時間管理能力應該不錯，于是問了一下，他還真給出了一個時間表，很有意思。會后的討論也很有趣，大家就美工與開發(fā)人員如何配合展開了很深的討論。那對美工與程序員的搭檔給我留下深刻印象，他們說的一些話體現(xiàn)出來態(tài)度讓我仿佛看到了一個優(yōu)秀的團隊，尤為欣賞，尤其那位美工那種追求更高效交流以期減少浪費的“敏捷”態(tài)度在美工中真的是非常少見。（說實話，程序員中這種態(tài)度也不忒多見）
兩個活動都參加之后，個人比較來看，Open Party比RIAmeeting精彩，大概是因為RIAMeeting更像是Flex的傳播活動，偏向普及，缺乏高級點的交流，而OpenParty則是從業(yè)人員的經驗交流，門檻稍微高一點。其實對于線下的交流我還是比較喜歡門檻高一點，那樣比較過癮。
【花絮】
在OpenParty上我們講解了FunFX之后。熊節(jié)跟我說他剛才也做了一個自動化測試的框架。雖然我已經把敏捷和熊節(jié)這兩個詞關聯(lián)起來很久了，但是這等速度還是讓我吃了一驚（導致現(xiàn)在我還在懷疑是不是我聽錯了，
已經證實。。。我聽錯了）。那個框架當天就被熊節(jié)發(fā)到了google code上，當時他的名字是：
Fluorine，還寫了一句很有趣的話：Fluorine makes your teeth FLASH。可惜這個名字有人用過了，現(xiàn)在改名為Fluorida。
Fluorida的原理說白了很簡單，使用dispatchEvent的方式模擬操作，若干個月之前我也這么干過，當時是對這種方式的可行性表示懷疑的。在后來在Google code上下載了代碼并閱讀一遍之后，我開始覺得這個做法沒啥問題。而且相比FunFx，他不需要Flex程序員再去學Ruby。今天很榮幸的加入到這個項目組中。
如今預覽版--0.0.1版已經發(fā)布，廣泛征集回饋和建議中，有任何建議可以到
http://code.google.com/p/fluorida/wiki/Announcement001 發(fā)表評論
======
主要相關報道及文章：
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不容易實現(xiàn)某些設計模式（比如單例）而煩惱，跟我一樣煩惱的人有福了，這里有一本很棒的書：
http://www.tkk7.com/Files/tj19832/flex/Adobe.Press.Advanced.ActionScript.3.with.Design.Patterns.Nov.2006.rar
這本書一定要讀，一定要讀，一定要讀，不然開發(fā)的時候會犯很多錯誤，走很多彎路，產生很多錯誤的認識。后果很嚴重的：P
從來沒有想過把“炫”這個詞跟諾基亞的產品聯(lián)系在一起，通常這個詞都是給apple之類的公司的，但是在開始看這個視頻不到30秒，我的觀念就被徹底顛覆了。據(jù)說，七年之后，這款手機將上市。期待啊。。。。。
這就是我參加完第二次OpenParty的感覺，這次的topic有十幾個。很可惜最后進行的只能有9個。我跟Thoughtworks的韓鍇一起準備了一個關于Flex的session。沒想到還得到最多人的支持。虛榮心得到極大滿足，咔咔。
坐在里面，參與或主持Session，感受知識的傳播與再造，那真的是一件非常快樂的事情。我可以感受到自己的成長和別人的成長。往大了說可以感覺到中國的軟件界的成長，因為大家都是來自不同的公司，等大家?guī)еR回到公司，又會對公司成長產生作用也就一點點得對業(yè)界產生了作用。就像蝴蝶效應，雖然這是一只頗大個的蝴蝶。（PS:但是出了門沒多遠就看到Police坐著車慢游，頓時緊張是不是查證的，唉有推動力就有障礙么）
整個活動是idea的碰撞、攪拌。這種感覺遍布各個角落，經常看到session已經結束，但是思維的碰撞仍在繼續(xù)。甚至這一期的OpenParty結束了，他的效果卻才剛剛開始，一直綿延到很久以后。在那種氛圍下，頭腦在一刻不停的思考、汲取知識，同時不自覺的就想去跟人交流。這半天過得是非常充實的。
也正是因為前面的原因，等回到家中，興奮勁稍微過去之后，大腦似乎才剛剛意識到累了。其表現(xiàn)就在于一回想白天的某一個topic，腦子里就爆炸式得蹦出一堆東西，有自己的想法，有別人的話，甚至當時的場景，一遍遍像過電影一樣閃現(xiàn)，最終崩潰，所有的畫面連不成一個有序的思維。于是打開優(yōu)酷看美劇，同時上網跟人聊天，讓大腦停止思考。這招百試百靈，這次也不例外。直到現(xiàn)在，好象才從中稍微的恢復過來。可也想睡覺了。。。。。。
我的操作系統(tǒng)是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發(fā)布了Flex 3和AIR 1.0。宣布一個新時代的正式來臨。Flex的時代。
回顧多年以前，當它僅僅是Flash的時候，那時的它也可以運行在網頁中和桌面上，大家覺得它很漂亮，僅此而已，那時的它只是個非常可愛的小玩具。不要說巨人微軟沒有注意到它身上隱藏的潛力，就連他現(xiàn)在的主人Adobe也對它不感興趣。也正是這樣，他在每一個平臺上都很好的生存了下來。
在這個世界上，有另外一個技術，叫做Java。它以跨平臺為理念，努力打造一個統(tǒng)一的軟件世界。在后臺，它取得了無與倫比的成功，可是在前臺，它總是不那么順利。我，就生活在這樣的世界里。
日子一天天過去，F(xiàn)lex迎來了3.0。FlashPlayer9也占據(jù)了世界上94%的PC（如果算上以前的版本，這個占有率逼近100%）。而相比只下，JRE之占據(jù)了84.6%,在蘋果和其他操作系統(tǒng)的沖擊下，windows也降到了90%以下。毫不客氣的說，F(xiàn)lashPlayer已經是世界上覆蓋率最大的運行環(huán)境。昔日的星星之火開始呈現(xiàn)燎原之勢。
今年，毫無疑問會有很多的開發(fā)人員轉向或者開始接觸Flex，中國的Flex資源還比較貧乏，不過已經有一群人在努力了。雖然已經有了AnyFlex，RIAchina之類的論壇，但是相比較傳統(tǒng)的論壇，下面的幾個更有特色：
以
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發(fā)布Flex 3和AIR 1.0的正式版。
在這個日子里我在干啥捏？配CruiseControl，嘗試將持續(xù)集成引入我們部門，順便，考慮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
完成之后，系統(tǒng)會提示你
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下。如果系統(tǒng)安全性設置太高的話，最后可能不生成LocalSettings.php
硅谷創(chuàng)業(yè)公司 BeyondMedia 高薪招聘 (北京)
BeyondMedia 是位于美國硅谷的一家提供媒體服務的互聯(lián)網公司, 主要為美國所有的媒體和客戶提供一個中間平臺.
現(xiàn)在公司處于快速成長期, 希望在國內發(fā)展一個研發(fā)中心, 目前正在招聘研發(fā)人才.
本公司是一家正在快速發(fā)展的互聯(lián)網公司, 公司為員工提供良好的工作環(huán)境, 具有吸引力的薪水以及股票期權, 履行正規(guī)的保險權益.
有意者,請發(fā)送中英文簡歷到
cnscud@gmail.com 郵件, 并請注明期望薪水,外語情況等, 謝謝.
以下要求僅供參考.
==============================
====
高級Flash工程師
主要工作職責:
* 和整個開發(fā)/設計團隊協(xié)作
* 完成相關的Flash設計, 制作, 維護
* 其他相關的設計工作
* 編寫相關文檔
基本要求:
* 3年+工作經驗
* 美術設計專業(yè)或有相關從業(yè)經驗
* 熟悉Flash制作
* 熟悉Flash編程 (Flex, ActionScript等)
* 熟悉JavaScript, Html, XML
* 有網站設計經驗更佳
個人:
* 能熟練閱讀英文文檔, 能編寫英文文檔更佳
* 良好的溝通能力, 能與團隊緊密協(xié)作
* 富有責任感
* 能積極主動完成工作
* 善于學習
===============================================
高級網站美術設計師
主要工作職責:
* 和整個開發(fā)/設計團隊協(xié)作
* 了解整個平臺網站的結構, 對網站進行設計, 實現(xiàn)和維護
* 編寫相關文檔
基本要求:
* 3+年工作經驗
* 美術設計專業(yè)或相關從業(yè)經驗
* 熟悉Photoshop, Dreamweaver等相關軟件的使用
* 熟悉網頁的制作編輯, Html, CSS. (Div+Css方式)
* 了解歐美網站風格者優(yōu)先考慮
* 熟悉Javascript更佳
* 熟悉Flash制作更佳
個人:
* 能熟練閱讀英文文檔, 能編寫英文文檔更佳
* 良好的溝通能力, 能與團隊緊密協(xié)作
* 富有責任感
* 能積極主動完成工作
* 善于學習
高級J2EE軟件工程師
工作職責:
* 和開發(fā)/設計團隊進行協(xié)作, 了解系統(tǒng)需求,架構和設計
* 設計, 實現(xiàn)和維護系統(tǒng)平臺
* 編寫相關文檔
技術要求:
* 4年+ 的J2EE應用開發(fā)經驗
* 熟悉Struts2, Webwork或類似MVC框架
* 熟悉Spring和Hibernate
* 熟悉Javascript, Html, Jsp
* 有Ajax的使用經驗更佳
* 數(shù)據(jù)庫方面的經驗, 例如數(shù)據(jù)庫設計和SQL
* 熟悉Mysql, Oracle或者其他數(shù)據(jù)庫
* 有Web services的使用經驗更佳
* 熟練使用Java IDE, 例如Idea, Eclipse
* 了解Weblogic, Tomcat, JBoss或Resin的部署
* 熟悉Linux系統(tǒng)更佳
* 有網頁制作編輯(美工)經驗更佳
個人要求:
* 能熟練閱讀英文文檔, 能編寫英文文檔更佳
* 良好的溝通能力, 能與團隊緊密協(xié)作
* 富有責任感
* 能積極主動完成工作
* 善于學習
===============================================
J2EE軟件工程師
工作職責:
* 和開發(fā)/設計團隊進行協(xié)作, 了解系統(tǒng)需求,架構和設計
* 設計, 實現(xiàn)和維護系統(tǒng)平臺
* 編寫相關文檔
技術要求:
* 2年+ 的J2EE應用開發(fā)經驗
* 熟悉Struts2, Webwork或類似MVC框架
* 熟悉Spring和Hibernate
* 熟悉Javascript, Html, Jsp
* 有Ajax的使用經驗更佳
* 數(shù)據(jù)庫方面的經驗, 例如數(shù)據(jù)庫設計和SQL
* 熟悉Mysql, Oracle或者其他數(shù)據(jù)庫
* 熟練使用Java IDE, 例如Idea, Eclipse
個人要求:
* 能熟練閱讀英文文檔, 能編寫英文文檔更佳
* 良好的溝通能力, 能與團隊緊密協(xié)作
* 富有責任感
* 能積極主動完成工作
* 善于學習
目前Flash是不支持運行時加載SVG的。必須使用Embed的方式。
已經有人向Adobe提出了請求，不知道什么時候才能實現(xiàn)了：
http://bugs.adobe.com/jira/browse/SDK-11619
目前來說，使用SVG就會增Flash的體積，用來做些Logo之類的小東西還可以，做別的還是免了吧。