2011年12月6日
#
轉(zhuǎn)發(fā) http://blog.chinaunix.net/uid-23093301-id-90459.html
問題來源：
創(chuàng)建一個游戲系統(tǒng)，其將運(yùn)行在互聯(lián)網(wǎng)的環(huán)境中。客戶端通過WWW服務(wù)或特定的客戶端軟件連接到游戲服務(wù)器，隨著流量的增加，系統(tǒng)不斷的膨脹，最終后臺數(shù)據(jù)、業(yè)務(wù)邏輯被分布式的部署。然而相比中心化的系統(tǒng)，復(fù)雜度被無可避免的增大了，該如何降低各個組件之間的耦合度。
挑戰(zhàn)：
需要保證可伸縮性、可維護(hù)性、可更新性，需要將服務(wù)劃分為各個相對獨(dú)立的組件，組件被分布式的部署，它們之間通過進(jìn)程間通信方式實現(xiàn)交互。服務(wù)的增加、刪除、改變都應(yīng)該被支持。理想情況，以開發(fā)者的角度看，集中化的系統(tǒng)和分布式的系統(tǒng)在中心邏輯上沒有什么不同。為實現(xiàn)這個目標(biāo)：
l 可以遠(yuǎn)程的訪問服務(wù)，而對于訪問者，服務(wù)的位置應(yīng)該是透明的。
l 提供服務(wù)的組件可以增加、刪除、改變，而且這些在運(yùn)行期同樣應(yīng)該被支持。
l 訪問服務(wù)的客戶端不應(yīng)該關(guān)心服務(wù)的實現(xiàn)細(xì)節(jié)。
解決方案：
引入一個Broker組件，解耦客戶端和服務(wù)端。服務(wù)端注冊自己到Broker，通過暴露接口的方式允許客戶端接入服務(wù)。客戶端是通過Broker發(fā)送請求的，Broker轉(zhuǎn)發(fā)請求道服務(wù)端，并將請求的結(jié)果或異常回發(fā)給客戶端。通過使用Broker模式，應(yīng)用可以通過發(fā)送消息訪問遠(yuǎn)程的服務(wù)。
這一架構(gòu)模式允許動態(tài)的改變、添加、刪除服務(wù)端，從客戶端的角度，這些都是透明的。
結(jié)構(gòu)：
Broker模式定義了6中類：Client，Server，Client_Proxy，Server_Proxy，Broker，Bridge。
Server：
l 責(zé)任：處理特定領(lǐng)域的問題，實現(xiàn)服務(wù)的細(xì)節(jié)，注冊自己到Broker，處理請求并返回結(jié)果或異常。
l 協(xié)作類：Server_Proxy，Broker
Client：
Client是需要訪問遠(yuǎn)程服務(wù)的應(yīng)用程序，為此，Client發(fā)送請求到Broker，并從Broker上接收響應(yīng)或異常。Client和Server只是邏輯上相關(guān)而已，實際上Client并不知道Server的確切位置。
l 責(zé)任：1. 實現(xiàn)用戶端功能，2. 發(fā)送請求到Broker，3. 接收相應(yīng)和異常。
l 協(xié)作類：Broker，Client_Proxy
Broker：
Broker可以被看成消息轉(zhuǎn)發(fā)器。Broker也負(fù)責(zé)一些控制和管理操作。它能夠定位服務(wù)端的位置，若發(fā)生異常，能夠?qū)惓２东@傳給Client。Broker需要提供注冊服務(wù)的接口給Server。如果請求來自其他的Broker，本地的Broker需要轉(zhuǎn)發(fā)請求并最終將結(jié)果或異常回應(yīng)給相應(yīng)的遠(yuǎn)程Broker。Broker提供的服務(wù)和name service非常相像（如DNS、LDAP）。
l 責(zé)任：1. 注冊服務(wù)。2. 提供服務(wù)API。3. 轉(zhuǎn)發(fā)消息。4. 容錯處理。5. 與其他Broker的交互。6。 定位服務(wù)。
l 協(xié)作類：Client_Proxy,Server_Proxy,Bridge
Client_Proxy：
連系Client和Broker，這一層保證了通訊的透明性，使Client調(diào)用遠(yuǎn)程服務(wù)就像調(diào)用本地的服務(wù)一樣。
l 責(zé)任：1. 封裝特定的系統(tǒng)調(diào)用。2. 封裝通訊的參數(shù)、控制信息等。
l 協(xié)作類：Client,Broker。
Server_Proxy：
Server_proxy是與Client_Proxy相對應(yīng)的，它接受請求，解包消息，解析出參數(shù)并調(diào)用服務(wù)的實現(xiàn)接口。
l 責(zé)任：1. 封裝特定的系統(tǒng)調(diào)用。2. 封裝通訊的參數(shù)、控制信息等。3. 調(diào)用server的服務(wù)接口。
l 協(xié)作類：Server,Broker。
Bridge：
Bridge用來連接各個Broker，一般這個組件是可選的。當(dāng)系統(tǒng)是發(fā)雜的網(wǎng)絡(luò)組成時，有可能需要這一角色。
l 責(zé)任：1. 封裝特定的網(wǎng)絡(luò)特性。2. 傳遞Broker之間的通訊。
l 協(xié)作類：Broker。
應(yīng)用場景一：
直接通訊方式。Client和Server相互理解他們之間的通訊協(xié)議。Broker主要完成Client和Server之間的握手。之后所有的消息、異常都是由Client與Server直接交互。（想象DNS）。簡單對象交互如圖：
應(yīng)用場景二：
l Broker啟動，完成自身的初始化，之后進(jìn)入事件循環(huán)，等待消息到來。
l Server啟動，首先執(zhí)行自身的初始化，然后注冊自己到Broker。
l Broker接收Server的注冊請求，將其加入到可使用服務(wù)的列表，并回應(yīng)Ack給Server。
l Server接收Ack，進(jìn)入事件監(jiān)聽循環(huán)，等待消息到來。
l Client調(diào)用遠(yuǎn)程服務(wù)對象的方法，Client_Proxy封裝消息請其發(fā)送給Broker。
l Broker查詢可使用的Server，將請求轉(zhuǎn)發(fā)給Server。
l Server_Proxy解析消息，分離出參數(shù)和控制信息，并調(diào)用特定的Server實現(xiàn)接口。Server處理完的結(jié)果通過Server_proxy封裝成消息轉(zhuǎn)發(fā)到Server。
l Broker將相應(yīng)消息轉(zhuǎn)發(fā)給正確的Client_Proxy，Client受到響應(yīng)繼續(xù)其他邏輯。
簡單對象交互如圖：
應(yīng)用場景三：
l Broker A接收到請求，交由Server處理，但是發(fā)現(xiàn)該Server位于其他的網(wǎng)絡(luò)節(jié)點(diǎn)。
l Broker A將請求轉(zhuǎn)發(fā)給Bridge A，Bridge A將請求進(jìn)行必要的格式化，傳送給Bridge B。
l Bridge B將請求進(jìn)行必要的格式化，轉(zhuǎn)化成Broker B可以理解的格式，并轉(zhuǎn)發(fā)給Broker B。Broker B執(zhí)行場景二中的過程，處理的結(jié)果按如上逆序返回。
簡單對象交互如圖：
部署示意圖：
總結(jié)：
u 優(yōu)點(diǎn)：
1. 服務(wù)的位置透明性。
2. 組件的可變性及擴(kuò)展性。由于Server是注冊到Broker上的，所以Server可以動態(tài)的增加、刪除、改變。
3. Broker之間可交互。
4. 可重用性。
5. 由于組件的耦合度較小，調(diào)試和測試的工作也是可控的。
u 缺點(diǎn):
1. 效率；增加了一層Broker的消息轉(zhuǎn)發(fā)，效率有所降低。
2. 容錯能力必須要特別考慮。
3. 調(diào)試和測試的工作加大。
大師的非凡能力來源于何處？思維方式是關(guān)鍵。科學(xué)證據(jù)告訴人們，沒有天生的大師，只有煉就的專家。只要擁有專家的思維，你就能成為大師！
1909年的一天。多張象棋桌圍成了一個圈，一個男子在圈內(nèi)慢慢踱步。他的雙眼不斷掃描周圍的棋局，每隔兩三秒鐘就會下一步棋。而在圈外，數(shù)十位象棋迷不停地搔頭、苦想對策。這個人是誰？為什么他能以一人之力抗衡數(shù)十人的智慧？他就是國際象棋界的傳奇人物，古巴象棋大師卡帕布蘭卡（José Raúl Capablanca）。比賽結(jié)果毫無懸念，卡帕布蘭卡28局全勝。這只是他巡回表演賽中的一站，在整個巡回表演賽中，卡帕布蘭卡贏了168局。
為什么眨眼間他就能作出最正確的決定？面臨巨大的壓力，他能提前計算幾步？卡帕布蘭卡輕描淡寫地說：“我只提前看一步，但總是最正確的一步。”
這句話再簡單不過，卻開創(chuàng)了心理學(xué)研究的新紀(jì)元：象棋大師優(yōu)于新手的地方就在于那電光火石間的思考。這種快速的、由知識引導(dǎo)的知覺，有時叫做“領(lǐng)悟”。在其他領(lǐng)域，專家們同樣具有“領(lǐng)悟”的本領(lǐng)。一次比賽完畢，象棋大師能記住自己走過的每一步棋；對于一段音樂，哪怕只聽過一遍，資深音樂家也能寫出樂章的曲譜。無論多么困難，象棋大師也能在瞬間想到最妙的棋著；不管多么復(fù)雜，經(jīng)驗豐富的專業(yè)內(nèi)科醫(yī)生有時只須瞥上病人幾眼，就能作出準(zhǔn)確的診斷。
專家們的非凡技藝從何而來？源于天賦，還是得益于強(qiáng)化訓(xùn)練？通過對象棋大師的研究，心理學(xué)家找到了答案。一個世紀(jì)的探索積累了大量研究成果，新的理論應(yīng)運(yùn)而生，人腦處理信息（信息的組織與提取）之謎也由此破解。這項研究的意義還不僅在于此，人類的教育事業(yè)也將從中受益：象棋棋手提高棋藝的技巧，可否用于提高學(xué)生們的閱讀、寫作和計算能力呢？
象棋是最好的研究對象
人類何時開始擁有專業(yè)技術(shù)？這也許要從祖先們的狩獵說起。對于他們而言，狩獵技術(shù)是維系生命的重要工具，不掌握它就難以生存。經(jīng)驗豐富的獵人不僅知道獅子在哪里出沒，而且還能推斷出獅子的行蹤。從孩提時代開始，他們就得跟隨長輩練習(xí)追蹤技術(shù)。隨著年齡的增長，追蹤技術(shù)也日益嫻熟。“技術(shù)的熟練程度隨著年齡的增長而增長，35歲左右達(dá)到技術(shù)的巔峰，”美國加利福尼亞大學(xué)富勒頓分校的人類學(xué)家約翰?博克（John Bock）說道。練習(xí)追蹤技術(shù)要花費(fèi)很多時間，可能比培養(yǎng)優(yōu)秀的腦外科醫(yī)生還要費(fèi)事。
相對于新手，如果在技術(shù)上沒有絕對優(yōu)勢，那就難稱專家，只不過是多了一張唬人的文憑。這種披著專家外衣的人比比皆是。過去20年的研究結(jié)果表明，所謂的專業(yè)炒股者并不比業(yè)余者賺的錢多；知名品酒家對酒類的鑒別能力并不比饞酒的老農(nóng)強(qiáng)；高學(xué)歷的精神病醫(yī)生并不比低文憑的同行出色……即使真的存在專業(yè)技術(shù)，如教學(xué)、工商管理，都很難去衡量，更別提如何去闡釋。
不過，棋藝卻可以度量、可以分解、可以接受試驗研究，并且十分直觀，尤其在比賽時，任何人都能隨時觀看。正是基于以上原因，認(rèn)知科學(xué)家如獲至寶，將象棋作為研究思維理論的最佳試驗對象。于是象棋被稱作“認(rèn)知科學(xué)的果蠅”。
對象棋手棋藝的度量，已經(jīng)走在了其他任何比賽、運(yùn)動或競技活動的前面。運(yùn)用統(tǒng)計學(xué)公式，對棋手曾獲得的所有成績進(jìn)行分析，就可以得到棋手的實力等級。然后根據(jù)棋手的等級與對手的實力，即可準(zhǔn)確地推算出棋手的獲勝幾率。如果A棋手的等級分高于B棋手200點(diǎn)，那么在比賽中，A戰(zhàn)勝B的平均幾率為75％。不管棋手是頂級的還是普通的，這種預(yù)測都很準(zhǔn)確。例如，俄羅斯特級象棋大師加里?卡斯帕羅夫（Garry Kasparov），他的等級分是2812點(diǎn)，而荷蘭象棋大師揚(yáng)?蒂曼（Jan Timman）的等級分是2616點(diǎn)。如果二者對弈，那么卡斯帕羅夫就有75％的勝算。同樣，中等水平的棋手（1200點(diǎn)）與另一個1000點(diǎn)的棋手對弈，前者亦有75％的勝算。選手的等級分代表著他們的真正實力，以選手的等級為標(biāo)準(zhǔn)，心理學(xué)家就可以客觀地評估他們的專業(yè)技術(shù)，動態(tài)追蹤他們整個象棋生涯，而不會受到選手名氣的影響。
為什么認(rèn)知科學(xué)家沒有選擇臺球或橋牌作為研究模型，而偏偏選擇象棋呢？可能是因為象棋比賽最考驗人的智慧。正如德國詩人歌德所言，象棋是“智慧的試金石”。象棋大師的技藝出神入化，令人嘆為觀止，人們將他們的能力歸因于他們“擁有魔力”的大腦。這種魔力在下盲棋時體現(xiàn)得淋漓盡致。法國心理學(xué)家阿爾弗雷德?比奈(Alfred Binet)是首個智力測驗的發(fā)明人之一。1894年，他曾請象棋大師描述他們下棋的過程。起初，他認(rèn)為棋盤就像照片一樣存在于象棋大師的大腦中，但是他很快斷定，大師們大腦中的圖像還要抽象得多。他們整體把握棋子的位置關(guān)系而不注重具體細(xì)節(jié)，就像只關(guān)心馬而不關(guān)心馬的鬃毛一樣。
通過把握比賽的即時細(xì)節(jié)以及回想走過的棋步，盲棋大師能將腦海中的棋局補(bǔ)充完整。假設(shè)大師忘記了卒的準(zhǔn)確位置，該怎么辦呢？他立即開始回想開局時的套路，因為在開局時，套路相對固定，而且已經(jīng)爛熟于胸，因此很容易找到卒曾經(jīng)所在的位置。他也可以回憶走過的棋步，通過推理來找到卒的位置――“前兩步我沒能抓住他的相，所以當(dāng)時一定有卒在擋路……”他不必糾纏細(xì)節(jié)不放，利用組織完善的連接系統(tǒng)，可以重獲任何想要的細(xì)節(jié)。
如果大師們的魔力――超凡的計算、計劃能力都是以復(fù)雜的知識結(jié)構(gòu)為基礎(chǔ)，那么就可以肯定，專業(yè)技術(shù)多半來源于刻苦訓(xùn)練，而非上天的恩賜。荷蘭心理學(xué)家阿德里安?德赫羅特(Adriaan de Groot)是一位象棋大師。1938年，荷蘭舉行了一場國際象棋錦標(biāo)賽，他利用主場之便，對普通棋手、專業(yè)棋手與世界頂級大師進(jìn)行比較后，進(jìn)一步鞏固了上述觀點(diǎn)。他曾使用的一種方法就是請棋手觀看節(jié)選自比賽的棋局，然后說出自己的想法。他發(fā)現(xiàn)，盡管專業(yè)棋手的分析能力要比普通棋手強(qiáng)，但是當(dāng)他們的實力提升至大師級時，反而不會去思索更多的下法。因為在高手的心中，只會留下最妙的棋著――正如卡帕布蘭卡聲稱的那樣。
近來研究表明，德赫羅特的發(fā)現(xiàn)只展示了象棋大師的部分實力。在一場對弈中，如果大量而精確的計算無法避免時，大師們就會拿出真功夫，深入研究各種可能的棋步走法。這種能力，會讓普通棋手望塵莫及。同樣，知識淵博的物理學(xué)家遭遇難題時，也會比他的學(xué)生想出更多的解決辦法。然而在上述兩種情況下，專家依靠的不是與生俱來的強(qiáng)大的分析能力，而是多年來逐漸建立起來的知識結(jié)構(gòu)。面對困難的棋局，一個實力平平的棋手可能會耗費(fèi)大半個小時去計算、提前看許多步，然而總是錯過最正確的一步。相反，一個大師級的棋手根本不用有意識地去分析，立即就能看到精妙入微的一步。
德赫羅特還讓參加試驗的棋手在短時間內(nèi)審視棋局，然后憑記憶重建棋局。在這樣的試驗條件下，任何棋手的實力都會暴露無遺。就算用長達(dá)30秒鐘的時間去回憶棋局，新手能記起的細(xì)節(jié)也是支離破碎的。而象棋大師，即使只瞟上幾眼，也能輕松重建棋局。這種差別源于一種特殊記憶，也就是對棋局的特異性記憶。特殊記憶是訓(xùn)練的結(jié)果，因為在一般性的記憶測試中，大師的表現(xiàn)并不比其他人好。
同樣的現(xiàn)象還能從橋牌牌手（多場牌局后，仍記得出過的牌）、計算機(jī)程序設(shè)計師（能重組大量的計算機(jī)編碼）和音樂家（能記住大段大段的樂章）身上看到。在特殊領(lǐng)域，對主題事務(wù)的記憶能力，是衡量專業(yè)技術(shù)水平的重要標(biāo)準(zhǔn)。
一個不常見的案例也能證明，知識結(jié)構(gòu)才是專家們戰(zhàn)無不勝的法寶。一個叫D.H（姓名不全）的業(yè)余棋手，經(jīng)過9年的訓(xùn)練，終于在1987年成為了加拿大一流的象棋大師。美國佛羅里達(dá)州立大學(xué)的心理學(xué)教授尼爾?蔡內(nèi)斯（Neil Charness）指出，盡管這個棋手的實力已經(jīng)今非昔比，但是他對棋局的分析范圍并不比從前廣泛，反而是日益精深的棋局知識和相關(guān)策略幫助他連連告捷。
非凡能力來自何方
在上世紀(jì)60年代，美國卡耐基－梅隆大學(xué)的心理學(xué)家赫伯特?西蒙（Herbert Simon，1978年諾貝爾獎得主）和威廉?蔡斯（William Chase），試圖通過研究專家的記憶局限性來更好地洞察專家的記憶能力。按照德赫羅特的研究思路，他們請各個級別的棋手重建曾被人動過的棋局。不過這盤棋局不是大師對弈后的殘局，而是一盤亂擺的棋局。在重建這盤隨機(jī)棋局時，棋手間的差距并不明顯。
因此，象棋運(yùn)動中的特異性記憶不只取決于象棋這項運(yùn)動，還取決于棋局的類型。這些實驗驗證了早期的研究結(jié)果，有力地證明了能力的非通用性，不同的領(lǐng)域需要不同的能力。早在一個世紀(jì)前，美國心理學(xué)家愛德華?桑代克(Edward Thorndike)就首先提出了上述理論。當(dāng)時他指出，拉丁語說得好不等于英語水平高，幾何證明也不能教會人們在日常生活中運(yùn)用邏輯思維。
象棋大師要處理的信息，數(shù)量極其龐大，似乎已經(jīng)超越了人類記憶的極限。為了解釋他們這種超凡的能力，西蒙引入了模塊理論。1956年，美國普林斯頓大學(xué)的心理學(xué)家喬治?米勒(George Miller)曾發(fā)表過一篇著名的論文――《非凡的數(shù)字7±2》。米勒在論文中指出，人的記憶有一定的限度，每次只能處理5～9條信息。西蒙強(qiáng)調(diào)說，通過把不同層次的信息構(gòu)建成一個一個模塊，大師就能突破記憶的極限。通過這種方法，他們會去捕捉5～9個模塊，而不是5～9個具體細(xì)節(jié)。
以“Mary had a little lamb”（瑪麗有一只小羊羔）這句詩為例。詩里的信息模塊數(shù)取決于讀者對詩歌與英語的熟悉程度。對于以英語為母語的人，這句詩是一個非常大的模塊――著名詩歌的一部分；對于懂英語卻不懂詩歌的人，這就是一句話――一個完整的模塊；對于記得單詞卻不明白含義的人，這句話是5個模塊（單詞）；而對于認(rèn)得字母，卻不認(rèn)識單詞的人，這句詩就是18個模塊（字母）！
在象棋新手和象棋大師之間就能清楚地看到這種差別。假如有一個擺著20個棋子的棋局放在面前，新手和大師會怎么處理其中的信息呢？新手滿眼都是棋格，而棋子又有多種擺法，因此他獲取的信息模塊遠(yuǎn)多于20個。那么大師呢？他會將棋局整體化，然后把整個棋局分割成5～6個模塊，這樣記起來不就輕松多了！根據(jù)獲取一個新的記憶模塊所花掉的時間，以及普通棋手成長為大師級選手所需要的時間，西蒙估算出了象棋大師的大腦中存儲的信息模塊數(shù)：5萬～10萬個！就像我們聽幾個字就能背出一首古詩一樣，象棋大師只要看一眼棋局，就能從記憶中提取出相應(yīng)的信息模塊。
但是模塊理論還有缺陷。對一些記憶現(xiàn)象，例如當(dāng)大師們精力分散時，他們的表現(xiàn)并沒有受到明顯影響，模塊理論就無法給出合理的解釋。佛羅里達(dá)州立大學(xué)的K?安德斯?埃里克森（K. Anders Ericsson）與蔡內(nèi)斯認(rèn)為，可能還存在另外一種機(jī)制，使得專家可以把長時記憶當(dāng)作暫存區(qū)使用。埃里克森說：“訓(xùn)練有素的棋手在不看棋盤的情況下，能以幾乎正常的水平下棋，要用模塊理論來解釋這樣的事例，幾乎不可能。因為你必須先了解棋局，然后才能在記憶中把它翻出來。”這一處理過程需要改變已有的信息模塊，就像倒背 “Mary had a little lamb”，雖然可以做到，但是很難，而且還會錯誤不斷。然而在下盲棋的時候，象棋大師仍然可以精準(zhǔn)快速地下棋，讓對手無所適從。
埃里克森還引證了內(nèi)科醫(yī)生的學(xué)習(xí)過程。醫(yī)生們先把信息變?yōu)殚L時記憶，當(dāng)需要使用這些信息來診斷疾病時，再把它從記憶中提取出來。埃里克森還列舉了一個最普通、最常見的例子――閱讀。1995年，他在研究中發(fā)現(xiàn)，越是熟練的讀者越不容易受到干擾。就算閱讀被打斷，熟練的讀者也能在幾秒鐘的時間內(nèi)恢復(fù)原有的閱讀速度。研究人員用長時工作記憶來解釋這一現(xiàn)象。這一說法似乎自相矛盾，因為長時記憶與工作記憶是兩個相互對立的概念。不過在2001年，德國康斯坦茨大學(xué)進(jìn)行的大腦成像研究卻為這一說法提供了依據(jù)。研究結(jié)果表明，較之新手，專業(yè)棋手的長時記憶顯然更容易激活。
上世紀(jì)90年代末期，西蒙曾提出過一種競爭理論。英國倫敦布魯內(nèi)爾大學(xué)的費(fèi)爾南德?戈貝特（Fernand Gobet）對它推崇備至。競爭理論實際上是模塊理論的延伸，它引入了“模板”的概念，也就是一種極其典型并包含了大約12只棋子的大型布局。模板擁有許多插口，大師可以插入卒或者相這樣的變量。再以詩句“Mary had a little lamb”為例，如果某個詞的韻律與詩句中的詞等同，那么就可以用這個詞來替換詩中的詞。例如，用“Larry”替代“Mary”，用“pool”來替代“school”等等。任何知道原始模塊的人，都能在瞬間插入另一個詞。
天才是怎樣“煉”成的
要想在大腦中建立復(fù)雜的知識結(jié)構(gòu)，就得不斷努力。西蒙提出了“十年規(guī)則”，他認(rèn)為要掌握任何技藝，十年的艱辛歷程是無法避免的。即便是數(shù)學(xué)天才高斯，音樂奇才莫扎特，象棋神童菲舍爾，也得去拼搏、去奮斗，也許他們所付出的努力是常人難以想象的。
近年來，象棋天才似乎不斷涌現(xiàn)，但這都?xì)w因于計算機(jī)的強(qiáng)大功能。計算機(jī)能讓孩子們研究海量的大師級比賽，頻繁地與大師級程序?qū)梗谑窃谳^短的時間內(nèi)，他們就能積累豐富的實戰(zhàn)經(jīng)驗。1958年，15歲的菲舍爾獲得了象棋大師的稱號，當(dāng)時這一消息震驚了全世界。而目前的記錄保持者、烏克蘭的謝爾蓋?卡爾亞金（Sergey Karjakin）獲得大師稱號時，僅有12歲零7個月！
埃里克森認(rèn)為，光是練習(xí)遠(yuǎn)遠(yuǎn)不夠，還需要全身心投入，不斷挑戰(zhàn)極限、超越自我。就像業(yè)余愛好者，他們可能會用大量的時間來練習(xí)下棋、打高爾夫球、演奏樂器，卻始終達(dá)不到專業(yè)水平；然而一個經(jīng)過正規(guī)訓(xùn)練的學(xué)生，卻能在較短的時間內(nèi)超過他們。這是一個很有趣的現(xiàn)象，說明練習(xí)和比賽對棋手的幫助似乎不如踏踏實實地學(xué)習(xí)。訓(xùn)練和比賽的主要價值在于，新手可以從中發(fā)現(xiàn)自己的缺陷，從而在以后逐漸彌補(bǔ)。
在學(xué)習(xí)初期，新手往往興趣濃厚，鉆研勁兒十足。他們剛開始學(xué)習(xí)打高爾夫球或者開車時，技術(shù)的進(jìn)步速度可用“神速”二字來形容。但是技術(shù)一旦攀升到一定的階段，例如跟上了高爾夫球友的節(jié)奏，或者考取了駕照，大多數(shù)人就松懈了。于是，他們變得懶散，技術(shù)也被荒廢。相反，訓(xùn)練專家總是讓人不停地思考，因此參與學(xué)習(xí)的人就會自覺自律地去鉆研、不斷提高技術(shù)，從而縮小與高手之間的差距。
人類在進(jìn)步，衡量專業(yè)水平的技術(shù)標(biāo)準(zhǔn)也在不斷提高。現(xiàn)在的高中生能在4分鐘內(nèi)跑完一英里(約合1.6公里)；學(xué)音樂的學(xué)生敢于演奏曾經(jīng)只有名家才敢嘗試的曲子。如果說上述比較還不能讓人信服，那么我們再來看看象棋上的證據(jù)。英國人約翰?納恩（John Nunn）既是數(shù)學(xué)家，又是象棋大師。他利用計算機(jī)，比較了1911年和1993年舉行的兩屆國際象棋錦標(biāo)賽。結(jié)果發(fā)現(xiàn)，現(xiàn)代棋手出錯的幾率要小很多，換言之，他們比前輩們下得更準(zhǔn)確。納恩還研究了1911年的一個棋手下過的所有棋局。在當(dāng)時，這個棋手算是一個中等級別的選手。按照今天的標(biāo)準(zhǔn)，他的等級分不會多于2100點(diǎn)，離大師級標(biāo)準(zhǔn)還有一大段距離。與普通棋手相比，百年前的大師仍然實力強(qiáng)勁，不過與今天的大師相比，可能就有一定的差距。
在卡帕布蘭卡的那個時代，計算機(jī)、象棋數(shù)據(jù)庫都還沒有出現(xiàn)，他們只能靠自己解決一切問題，正如巴赫、莫扎特和貝多芬。如果說今天的大師在技術(shù)上已經(jīng)超越了曾經(jīng)名滿天下的先輩們，然而在創(chuàng)造力方面他們卻難以望其項背。今天，剛畢業(yè)的物理學(xué)博士掌握的物理知識，恐怕連牛頓也要自嘆弗如，但是在這些博士中，有誰能像當(dāng)年的牛頓一樣發(fā)現(xiàn)萬有引力定律？
說到這里，很多懷疑論者的耐心可能會蕩然無存。他們肯定會說，要步入卡耐基殿堂，除了練習(xí)、練習(xí)、再練習(xí)之外，還要付出更多的東西。雖然相信天資的重要性，尤其是專家和他們的學(xué)生對此深信不疑，然而奇怪的是，沒有任何證據(jù)來支持這一觀點(diǎn)。2002年，戈貝特曾做過一項研究。研究中，他用圖形記憶測驗衡量各級別棋手的視覺空間智能。結(jié)果發(fā)現(xiàn)，棋藝的高低與視覺空間智能的強(qiáng)弱根本沒有聯(lián)系。還有研究人員發(fā)現(xiàn)，職業(yè)裁判預(yù)見賽馬結(jié)果的能力與他們的數(shù)學(xué)能力也沒有什么關(guān)系。
... ...
摘要: 熵是信息理論中非常重要的一個概念，用來度量信息，在實踐中大量使用。
信息檢索最重要的概念ＴＦ／ＩＤＦ（term frequency/inverse document frequency)就是基于信息熵理論。搜索引擎、新聞分類、文本相似度計算都使用這個概念。
閱讀全文
看Chomsky的書是因為在編譯原理課程中多次提到這個人，這是個變態(tài)天才，神一般的存在，而且還是活的。
Chomsky的語言學(xué)理論觀點(diǎn)在語言學(xué)、心理學(xué)和哲學(xué)領(lǐng)域都產(chǎn)生了廣泛而深刻的影響。Chomsky的哲學(xué)思想是一個貫穿了唯實論、自然主義和心智主義的連貫的、完整的體系。這一體系的核心是內(nèi)在語言理論。但是這一理論觀點(diǎn)與傳統(tǒng)觀點(diǎn)分歧很大 ,因此遭受到哲學(xué)界的強(qiáng)烈攻擊。Chomsky正是在這些爭論的過程中不斷地發(fā)現(xiàn)問題并對自己的理論和觀點(diǎn)進(jìn)行修改和補(bǔ)充 ,從而使其哲學(xué)系統(tǒng)乃至語言學(xué)理論系統(tǒng)更趨完善。哲學(xué)問題咱不關(guān)心這么無聊的問題留給哲學(xué)家們?nèi)コ丁?/p>
理論方法
Chomsky語言學(xué)的理論方法概況起來講，是自然科學(xué)中形式主義的演繹方法，用Chomsky自己的話講，叫伽利略研究風(fēng)格(Galileo Style),像伽利略為宇宙建立抽象的數(shù)學(xué)模型一樣，構(gòu)建有關(guān)語言知識的抽象數(shù)學(xué)模型，相信類似數(shù)學(xué)一樣的形式主義的演繹推理模型具有自足自明的真理性。Chomsky的語言研究所追求的是從世界各種語言五花八門的句子樣式中抽象出幾個簡單的句法規(guī)則。
Chomsky的句法結(jié)構(gòu)一書中把語言學(xué)看成跟自然科學(xué)中的其他科學(xué)一樣，可以從假設(shè)出發(fā)，進(jìn)行推演并形式化。換句話說，非經(jīng)驗主義是可能的。《句法結(jié)構(gòu)》有一半篇幅用于英語語法的形式化。非經(jīng)驗主義和形式化是轉(zhuǎn)換生成語法的首要標(biāo)志。
把句法關(guān)系作為語言結(jié)構(gòu)的中心并以此說明語句的生成是這場革命的又一表現(xiàn)。為了描寫和解釋語言現(xiàn)象，Chomsky在《句法結(jié)構(gòu)》中論證了語法的生成能力，認(rèn)為應(yīng)該把語法看成是能生成無限句子的有限規(guī)則系統(tǒng)。
它以"核心句"為基礎(chǔ)，通過轉(zhuǎn)換規(guī)則描寫和分析不同句式之間的內(nèi)在聯(lián)系。該書分析了以"馬爾可夫過程"為基礎(chǔ)的通訊理論，認(rèn)為它只能生成有限狀態(tài)的語法，而這種"有限狀態(tài)的語法"不能生成象英語這種語言里含有不連續(xù)結(jié)構(gòu)的所有合乎語法的句子。基于此，喬姆斯基提出了轉(zhuǎn)換語法模式，認(rèn)為它才能生成所有合乎語法的句子而不會生成不合乎語法的句子。轉(zhuǎn)換語法模式由短語結(jié)構(gòu)規(guī)則、轉(zhuǎn)換規(guī)則、語素音位規(guī)則三套規(guī)則構(gòu)成。
短語結(jié)構(gòu)規(guī)則有三種：合并、遞歸、推導(dǎo)式，其基本形式是x→y 。→讀作"改寫"，這個公式就是將x改寫成y。短語結(jié)構(gòu)規(guī)則生成的是"核心語符列"，不經(jīng)過轉(zhuǎn)換直接由這種語符列得出的基本句型叫"核心句"。
轉(zhuǎn)換規(guī)則包括：移位、刪略、添加。最后運(yùn)用語素音位規(guī)則得出實際說出的句子。這三套規(guī)則中，最引人注目的是轉(zhuǎn)換規(guī)則，因為短語結(jié)構(gòu)規(guī)則和語素音位規(guī)則實際上繼承了描寫語言學(xué)的"直接成分分析"和語素音位的分析，轉(zhuǎn)換是一種創(chuàng)新，它使語法具有更強(qiáng)的解釋力。
《句法結(jié)構(gòu)》把語義排除在語法之外，這一時期的理論框架不包括語義部分。喬姆斯基認(rèn)為，語法理論不應(yīng)該建立在語義的基礎(chǔ)上，而應(yīng)該用某種嚴(yán)格的、客觀的方法去代替對于模糊的語義的依賴。不過這一理論在后來的發(fā)展中做了重大的修正。
Chomsky 定義的四種形式語言文法中， 0 型文法又稱為 （ A ）文法； 1 型文法又稱為 （ C ） 文法； 2 型語言可由 （ G ） 識別。
A ．短語結(jié)構(gòu)文法 B 前后文無關(guān)文法 C 前后文有關(guān)文法 D 正規(guī)文法
E 圖靈機(jī) F 有限自動機(jī) G 下推自動機(jī)
文法是用來定義語言的一個模型，常用的文法體系為Chomsky文法體系。
文法定義
文法G(Grammar)是一個四原組，G=(N,T,P,S)，N(Non-terminator)是非終結(jié)符集合，T(Terminator)是終結(jié)符集合，P(Production)是產(chǎn)生式集合，S(Start)是起始符
其中：
N 交 T = 空集
P 是形式為 α -> β 的產(chǎn)生式
α ∈ (N∪T)*N+(N∪T)*，也就是說α中必須有一個非終結(jié)符
β ∈ (N∪T)* ,也就是說β可以是空串
S∈N
分類
0型文法（短語文法或無限制文法），識別0語言的機(jī)器叫做圖靈機(jī)
定義：P中產(chǎn)生式a-->b，其中a屬于V正閉包且至少含有一個非終結(jié)符,b屬于V星閉包
注：任何0型文法都是可遞歸可枚舉的
對0型文法作某些限制，可以得到其他文法的定義
1型文法 又稱上下文有關(guān)文法。生成式形式為 α->β, 且 |α| < |β| 并且不存在 A->ε
2型文法 又稱上下文無關(guān)文法。生成式形式為 A->α,即左邊必須只有一個非終結(jié)符
3型文法 又稱正則文法。
生成式 A->wB或A->w,稱為右線性文法
生成式 A->Bw或A->w,稱為左線性文法
0型文法 對生成式?jīng)]有任何限制的文法稱為0型文法。從0到3都是包含的關(guān)系，但是有特例，包含 A->ε 產(chǎn)生式的2,3型文法不屬于1型文法。
四種文法產(chǎn)生的語言分別稱為 上下文有關(guān)語言，上下文無關(guān)語言，正則語言，無限制性語言。
2型語言的表示法
2型語言是很重要的一種語言，除了用四元組的方法表示，此處再介紹兩種表示方法。
當(dāng)人們要解釋或者討論程序設(shè)計語言本身時，經(jīng)常又需要一種語言，被討論的語言叫做對象語言，即某種程序設(shè)計語言，討論對象語言的語言稱為元語言，即元語言是描述語言的語言。BNF范式通常被作為討論某種程序設(shè)計語言語法的元語言，而語法圖是與BNF范式的描述能力等價的另一種文法表示形式，因其直觀性而經(jīng)常采用。
(1)巴科斯范式(Backus Normal Form,BNF)
2型文法生成式左端只有一個非終結(jié)符，所以可以把左端相同的生成式合并在一起，右端用|隔開，用::=代替->，所有非終結(jié)符用<>括起來，這是Backus為了描述AIGOL語言首次提出并使用的。
用BNF描述十進(jìn)制整數(shù)的生成語法：
<無符號整數(shù)> ::= <數(shù)字>|<數(shù)字><無符號整數(shù)>
<數(shù)字> ::= 0|1|2|3|4|5|6|7|8|9
(2)語法圖
語法圖有四種基本形式
(3)推導(dǎo)樹
2型文法還經(jīng)常用推導(dǎo)樹表示
節(jié)選自java.g
modifiers
:
( annotation
| 'public'
| 'protected'
| 'private'
| 'static'
| 'abstract'
| 'final'
| 'native'
| 'synchronized'
| 'transient'
| 'volatile'
| 'strictfp'
)*
;
Strictfp —— Java 關(guān)鍵字。
strictfp, 即 strict float point (精確浮點(diǎn))。
strictfp 關(guān)鍵字可應(yīng)用于類、接口或方法。使用 strictfp 關(guān)鍵字聲明一個方法時，該方法中所有的float和double表達(dá)式都嚴(yán)格遵守FP-strict的限制,符合IEEE-754規(guī)范。當(dāng)對一個類或接口使用 strictfp 關(guān)鍵字時，該類中的所有代碼，包括嵌套類型中的初始設(shè)定值和代碼，都將嚴(yán)格地進(jìn)行計算。嚴(yán)格約束意味著所有表達(dá)式的結(jié)果都必須是 IEEE 754 算法對操作數(shù)預(yù)期的結(jié)果，以單精度和雙精度格式表示。
如果你想讓你的浮點(diǎn)運(yùn)算更加精確，而且不會因為不同的硬件平臺所執(zhí)行的結(jié)果不一致的話，可以用關(guān)鍵字strictfp.
import語句可以導(dǎo)入一個類或某個包中的所有類
import static語句導(dǎo)入一個類中的某個靜態(tài)成員（方法或?qū)傩裕┗蛩徐o態(tài)成員
語法舉例：
import static java.lang.Math.sin;
import static java.lang.Math.*;
例子：
//導(dǎo)入Math類中的所有static方法和屬性。
//這樣我們在使用這些方法和屬性時就不必寫類名。
import static java.lang.Math.*;//import static java.lang.Math;//這樣寫報錯
public class StaticImport {
public static void main(String[] args) {
// System.out.println(Math.max(3, 5));//沒有使用靜態(tài)導(dǎo)入
// System.out.println(Math.abs(1-9));//沒有使用靜態(tài)導(dǎo)入
System.out.println(max(3, 5));
System.out.println(abs(1-9));
}
注意：1默認(rèn)包無法用靜態(tài)導(dǎo)入。
2如果導(dǎo)入的類中有重復(fù)的方法和屬性則需要寫出類名，否則編譯時無法通過。
}
概述：
在設(shè)計開發(fā)過程中經(jīng)常會出現(xiàn)開發(fā)庫與測試庫不一致，測試庫與生產(chǎn)庫不一致，每次手工比對是個辛苦的活。
以前用java寫過一個數(shù)據(jù)庫結(jié)構(gòu)比較工具，最近騰出功夫來學(xué)習(xí)了一下python,用python重寫了一下，已經(jīng)提交到了github和sourceforage.
版本控制使用github
https://github.com/zhengys/dbcompare.gitsourceforage上邊放了exe文件(用pyinstaller打包的程序發(fā)現(xiàn)在部分win7上不能正常工作，
又用py2exe打包了一個64位版本的，已經(jīng)上傳sourceforage , 感謝itshu的反饋)http://sourceforge.net/projects/databasecompare/files/通過這個工具可以做到簡單明了的看出區(qū)別。
對于數(shù)據(jù)庫和設(shè)計文檔不一致的情況，目前只能是先根據(jù)文檔生成數(shù)據(jù)庫，再和原來的庫做比對。未來考慮增加powerdesinger和數(shù)據(jù)庫的間直接比較。
目前只支持oracle,mysql,sqlserver，要是用的人多了再增加其它類型的數(shù)據(jù)庫。
使用：
功能類似文本比較工具，分別輸入數(shù)據(jù)庫連接信息，在結(jié)果頁面顯示比對結(jié)果。
操作很簡單看圖就知道怎么用了。
如圖：
打包說明
一開始用py2exe打包，發(fā)現(xiàn)在winxp下用不了
改用pyinstaller打包，360會誤認(rèn)為是木馬攔截，文件夾形式打包，比較占地方，壓縮后也得36MB.
可根據(jù)源碼自行打包。
首先解釋一下為什么它被稱之為SOCKS。其實該協(xié)議設(shè)計之初是為了讓有權(quán)限的用戶可以穿過過防火墻的限制，使得高權(quán)限用戶可以訪問一般用戶不能訪問的外部資源。當(dāng)時設(shè)計者考慮到幾乎所有使用TCP/IP通信的應(yīng)用軟件都使用socket（套接字，實際上是一組應(yīng)用程序接口）完成底層的數(shù)據(jù)通信。為了方便軟件開發(fā)者使用該協(xié)議，協(xié)議設(shè)計者就刻意對應(yīng)了幾組socket編程最經(jīng)典的操作，并且將協(xié)議定名為SOCKS。
最先被廣泛使用的SOCKS協(xié)議是其第四版本，就是SOCKS4。IE和一些其他應(yīng)用程序直接用“Socks”表示SOCKS4協(xié)議。該版本支持TCP的connect（作為客戶端連接）和listen（打開一個監(jiān)聽端口），不支持UDP協(xié)議。SOCKS4A對SOCKS4作了一點(diǎn)增強(qiáng)，即允許客戶端將域名發(fā)送給SOCKS服務(wù)器，讓SOCKS服務(wù)器進(jìn)行域名解析。
SOCKS5是第五版，相對第四版作了大幅度的增強(qiáng)。首先，它增加了對UDP協(xié)議的支持；其次，它可以支持多種用戶身份驗證方式和通信加密方式；最后，修改了SOCKS服務(wù)器進(jìn)行域名解析的方法，使其更加優(yōu)雅。經(jīng)過這次脫胎換骨的升級，SOCKS5于1996年被IETF確認(rèn)為標(biāo)準(zhǔn)通信協(xié)議，RFC編號為1928。經(jīng)過10余年的時間，大量的網(wǎng)絡(luò)應(yīng)用程序都支持SOCKS5代理。
SOCKS5雖然可以支持多種用戶身份驗證方式，但是應(yīng)用程序真正實現(xiàn)的一般也只有兩種：不驗證和用戶名密碼驗證。所以大多數(shù)應(yīng)用程序SOCKS5代理設(shè)置也只有用戶名/密碼這一種可選驗證方法。另外，盡管從SOCKS4開始，就支持打開TCP監(jiān)聽端口，但是直到SOCKS5，也只允許這個端口接收一個客戶端連接。因此網(wǎng)絡(luò)服務(wù)提供者（如http服務(wù)器）不能使用SOCKS。實際上，很多SOCKS服務(wù)器的實現(xiàn)也不支持打開TCP監(jiān)聽端口。
由于SOCKS5實際上仍然對應(yīng)了socket的經(jīng)典操作，所以有人利用這一點(diǎn)編寫了一種通用軟件，可以讓不支持SOCKS5協(xié)議的應(yīng)用軟件也能通過SOCKS5服務(wù)器進(jìn)行網(wǎng)絡(luò)通信，而應(yīng)用軟件則對此一無所知。這類軟件最著名的莫過于SocksCap32了，它是Permeo公司（其前身是NEC北美公司的一個部門，而SOCKS最初就是NEC北美公司的工程師開發(fā)并維護(hù)的）早期推出的一款產(chǎn)品。用戶可以免費(fèi)使用其試用版。試用版和正式版相比，沒有功能上的限制，只有使用時間的限制。但是到目前為止，Permeo總是會在老版本到期之前推出一個延后了期限的“新”版本，所以用戶實際上可以免費(fèi)使用。SocksCap32是利用API鉤子，截獲應(yīng)用軟件對socket函數(shù)的調(diào)用來實現(xiàn)對SOCKS5客戶端的模擬。盡管SocksCap32很有名，但是由于推出的時間較早，對很多現(xiàn)代應(yīng)用軟件時常表現(xiàn)的力不從心，所以Permeo又提供了Permeo
Security
Driver（以下稱為PSD）。這款產(chǎn)品使用了驅(qū)動技術(shù)從底層直接截獲應(yīng)用軟件的socket通信，因此幾乎可以為所有應(yīng)用軟件提供SOCKS5客戶端的支持。PSD不提供試用版，但是可以找到其早期版本的注冊碼。
雖然說設(shè)計SOCKS協(xié)議的初衷是在保證網(wǎng)絡(luò)隔離的情況下，提高部分人員的網(wǎng)絡(luò)訪問權(quán)限，但是國內(nèi)似乎很少有組織機(jī)構(gòu)這樣使用。一般情況下，大家都會使用更新的網(wǎng)絡(luò)安全技術(shù)來達(dá)到相同的目的。但是由于SocksCap32和PSD這類軟件，人們找到了SOCKS協(xié)議新的用途——突破網(wǎng)絡(luò)通信限制，這和該協(xié)議的初衷實際上正好相反。比如某些網(wǎng)游的部分服務(wù)器設(shè)置為只接收部分地區(qū)的IP地址的連接。為了突破這種限制，可以找一個該地區(qū)的SOCKS5代理服務(wù)器，然后用PSD接管網(wǎng)游客戶端，通過SOCKS5代理服務(wù)器連接游戲服務(wù)器。這樣游戲服務(wù)器就會認(rèn)為該客戶端位于本地區(qū)，從而允許進(jìn)行游戲。還有一種情況是：防火墻僅允許部分端口（如http的80端口）通信，那么可以利用SOCKS5協(xié)議和一個打開80端口監(jiān)聽的SOCKS5服務(wù)器連接，從而可以連接公網(wǎng)上其他端口的服務(wù)器。利用一些額外的技術(shù)手段，甚至可以騙過內(nèi)部的http代理服務(wù)器，這時在使用內(nèi)網(wǎng)http代理上網(wǎng)的環(huán)境下也可以不受限制的使用網(wǎng)絡(luò)服務(wù)，這稱之為SOCKS
over HTTP。通通通（[url]www.tongtongtong.com[/url]）是老牌SOCKS over
HTTP代理提供商，實現(xiàn)了所有的SOCKS5的連接功能，且有多組國內(nèi)外服務(wù)器。信天游（[url]www.xtyproxy.com[/url]），則是最近剛剛出現(xiàn)的代理服務(wù)提供商，功能和通通通相比還有差距，但是目前完全免費(fèi)。當(dāng)然，使用代理服務(wù)器后，將不可避免的出現(xiàn)通信延遲，所以應(yīng)該盡量選擇同網(wǎng)絡(luò)（指網(wǎng)通/
電信），距離近的服務(wù)器。
sock5代理的工作程序是：
1.需要向代理方服務(wù)器發(fā)出請求信息。
2.代理方應(yīng)答
3.需要代理方接到應(yīng)答后發(fā)送向代理方發(fā)送目的ip和端口
4.代理方與目的連接
5.代理方將需要代理方發(fā)出的信息傳到目的方，將目的方發(fā)出的信息傳到需要代理方。代理完成。
由于網(wǎng)上的信息傳輸都是運(yùn)用tcp或udp進(jìn)行的，所以使用socks5代理可以辦到網(wǎng)上所能辦到的一切，而且不輿目的方會查到你的ip,既安全又方
便
sock5支持UDP和TCP,但兩種代理是有區(qū)別的，以下分類說明
如何用代理TCP協(xié)議
1.向服務(wù)器的1080端口建立tcp連接。
2.向服務(wù)器發(fā)送
05 01 00 （此為16進(jìn)制碼，以下同）
3.如果接到 05 00 則是可以代理
4.發(fā)送 05 01 00 01 + 目的地址(4字節(jié)） +
目的端口（2字節(jié)），目的地址和端口都是16進(jìn)制碼（不是字符串！！）。 例202.103.190.27 -7201 則發(fā)送的信息為：05 01 00 01 CA
67 BE 1B 1C 21 (CA=202 67=103 BE=190 1B=27
1C21=7201)
5.接受服務(wù)器返回的自身地址和端口，連接完成
6.以后操作和直接與目的方進(jìn)行TCP連接相同。
如何用代理UDP連接
1.向服務(wù)器的1080端口建立udp連接
2.向服務(wù)器發(fā)送
05 01 00
3.如果接到 05 00 則是可以代理
4.發(fā)送 05 03 00 01 00 00 00 00 +
本地UDP端口（2字節(jié)）
5.服務(wù)器返回 05 00 00 01 +服務(wù)器地址+端口
6.需要申請方發(fā)送 00 00 00 01
+目的地址IP（4字節(jié)）+目的端口 +所要發(fā)送的信息
7.當(dāng)有數(shù)據(jù)報返回時 向需要代理方發(fā)出00 00 00 01 +來源地址IP（4字節(jié)）+來源端口
+接受的信息
注：此為不需要密碼的代理協(xié)議，只是socks5的一部分，完整協(xié)議請RFC1928
在linux下開發(fā)，mysql數(shù)據(jù)庫是經(jīng)常用到的，對于初學(xué)者來說，在linux怎么安裝卸載mysql數(shù)據(jù)庫，也許可能比較痛苦，這里簡單介紹下，怎么卸載msql數(shù)據(jù)庫。
a）查看系統(tǒng)中是否以rpm包安裝的mysql
- [root@linux ~]# rpm -qa | grep -i mysql
- MySQL-server-5.1.49-1.glibc23
- MySQL-client-5.1.49-1.glibc23
[root@linux ~]# rpm -qa | grep -i mysql
MySQL-server-5.1.49-1.glibc23
MySQL-client-5.1.49-1.glibc23
卸載MySQL-server-5.1.49-1.glibc23和MySQL-client-5.1.49-1.glibc23
- [root@linux ~]# rpm -e MySQL-client-5.1.49-1.glibc23
- [root@linux ~]# rpm -e MySQL-server-5.1.49-1.glibc23
[root@linux ~]# rpm -e MySQL-client-5.1.49-1.glibc23
[root@linux ~]# rpm -e MySQL-server-5.1.49-1.glibc23
b)查看有沒有mysql服務(wù)
- [root@linux ~]# chkconfig --list | grep -i mysql
- mysql 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@linux ~]# chkconfig --list | grep -i mysql
mysql 0:off 1:off 2:on 3:on 4:on 5:on 6:off
刪除mysql服務(wù)
- [root@linux ~]# chkconfig --del mysql
[root@linux ~]# chkconfig --del mysql
c)刪除分散mysql文件夾
- [root@linux ~]# whereis mysql
- mysql: /usr/lib/mysql /usr/share/mysql
[root@linux ~]# whereis mysql
mysql: /usr/lib/mysql /usr/share/mysql
分別刪除
- [root@linux lib]# rm -rf /usr/lib/mysql/
- [root@linux lib]# rm -rf /usr/share/mysql
[root@linux lib]# rm -rf /usr/lib/mysql/
[root@linux lib]# rm -rf /usr/share/mysql
通過以上幾步，mysql應(yīng)該已經(jīng)完全卸載干凈了
原文地址：
http://blog.csdn.net/love__coder/article/details/6894566
一、 解析Linux應(yīng)用軟件安裝包：
通常Linux應(yīng)用軟件的安裝包有三種：
1） tar包，如software-1.2.3-1.tar.gz。它是使用UNIX系統(tǒng)的打包工具tar打包的。
2） rpm包，如software-1.2.3-1.i386.rpm。它是Redhat Linux提供的一種包封裝格式。
3） dpkg包，如software-1.2.3-1.deb。它是Debain Linux提供的一種包封裝格式。
而且，大多數(shù)Linux應(yīng)用軟件包的命名也有一定的規(guī)律，它遵循：
名稱-版本-修正版-類型
例如：
1） software-1.2.3-1.tar.gz 意味著：
軟件名稱：software
版本號：1.2.3
修正版本：1
類型：tar.gz，說明是一個tar包。
2） sfotware-1.2.3-1.i386.rpm
軟件名稱：software
版本號：1.2.3
修正版本：1
可用平臺：i386，適用于Intel 80x86平臺。
類型：rpm，說明是一個rpm包。
注：由于rpm格式的通常是已編譯的程序，所以需指明平臺。在后面會詳細(xì)說明。
而software-1.2.3-1.deb就不用再說了吧！大家自己練習(xí)一下。
二、 了解包里的內(nèi)容：
一個Linux應(yīng)用程序的軟件包中可以包含兩種不同的內(nèi)容：
1） 一種就是可執(zhí)行文件，也就是解開包后就可以直接運(yùn)行的。在Windows中所 有的軟件包都是這種類型。安裝完這個程序后，你就可以使用，但你看不到源程序。而且下載時要注意這個軟件是否是你所使用的平臺，否則將無法正常安裝。
2） 另一種則是源程序，也就解開包后，你還需要使用編譯器將其編譯成為可執(zhí)行文件。這在Windows系統(tǒng)中是幾乎沒有的，因為Windows的思想是不開放源程序的。
通常，用tar打包的，都是源程序；而用rpm、dpkg打包的則常是可執(zhí)行程序。一般來說，自己動手編譯源程序能夠更具靈活性，但也容易遇到各種問題和困難。而相對來說，下載那些可執(zhí)行程序包，反而是更容易完成軟件的安裝，當(dāng)然那樣靈活性就差多了。所以一般一個軟件總會提供多種打包格式的安裝程序的。你可以根據(jù)自己的情況來選擇。
三、 搞定使用tar打包的應(yīng)用軟件
1. 安裝：
整個安裝過程可以分為以下幾步：
1） 取得應(yīng)用軟件：通過下載、購買光盤的方法獲得；
2）解壓縮文件：一般tar包，都會再做一次壓縮，如gzip、bz2等，所以你需要先解壓。如果是最常見的gz格式，則可以執(zhí)行：“tar –xvzf 軟件包名”，就可以一步完成解壓與解包工作。如果不是，則先用解壓軟件，再執(zhí)行“tar –xvf 解壓后的tar包”進(jìn)行解包；
3） 閱讀附帶的INSTALL文件、README文件；
4） 執(zhí)行“./configure”命令為編譯做好準(zhǔn)備；
5） 執(zhí)行“make”命令進(jìn)行軟件編譯；
6） 執(zhí)行“make install”完成安裝；
7） 執(zhí)行“make clean”刪除安裝時產(chǎn)生的臨時文件。
好了，到此大功告成。我們就可以運(yùn)行應(yīng)用程序了。但這時，有的讀者就會問，我怎么執(zhí)行呢？這也是一個Linux特色的問題。其實，一般來說， Linux的應(yīng)用軟件的可執(zhí)行文件會存放在/usr/local/bin目錄下！不過這并不是“放四海皆準(zhǔn)”的真理，最可靠的還是看這個軟件的 INSTALL和README文件，一般都會有說明。
2. 卸載：
通常軟件的開發(fā)者很少考慮到如何卸載自己的軟件，而tar又僅是完成打包的工作，所以并沒有提供良好的卸載方法。
那么是不是說就不能夠卸載呢！其實也不是，有兩個軟件能夠解決這個問題，那就是Kinstall和Kife，它們是tar包安裝、卸載的黃金搭檔。它們的使用方法，筆者會另行文介紹。在此就不加贅述了。
四、 搞定使用rpm打包的應(yīng)用軟件
rpm可謂是Redhat公司的一大貢獻(xiàn)，它使Linux的軟件安裝工作變得更加簡單容易。
1. 安裝：
我只需簡單的一句話，就可以說完。執(zhí)行：
rpm –ivh rpm軟件包名
更高級的，請見下表：
rpm參數(shù) 參數(shù)說明
-i 安裝軟件
-t 測試安裝，不是真的安裝
-p 顯示安裝進(jìn)度
-f 忽略任何錯誤
-U 升級安裝
-v 檢測套件是否正確安裝
這些參數(shù)可以同時采用。更多的內(nèi)容可以參考RPM的命令幫助。
2. 卸載：
我同樣只需簡單的一句話，就可以說完。執(zhí)行：
rpm –e 軟件名
不過要注意的是，后面使用的是軟件名，而不是軟件包名。例如，要安裝software-1.2.3-1.i386.rpm這個包時，應(yīng)執(zhí)行：
rpm –ivh software-1.2.3-1.i386.rpm
而當(dāng)卸載時，則應(yīng)執(zhí)行：
rpm –e software。
另外，在Linux中還提供了象GnoRPM、kpackage等圖形化的RPM工具，使得整個過程會更加簡單。這些軟件的具體應(yīng)用，筆者會另行文介紹。
五、 搞定使用deb打包的應(yīng)用程序
這是Debian Linux提供的一個包管理器，它與RPM十分類似。但由于RPM出現(xiàn)得更早，所以在各種版本的Linux都常見到。而debian的包管理器dpkg則只出現(xiàn)在Debina Linux中，其它Linux版本一般都沒有。我們在此就簡單地說明一下：
1. 安裝
dpkg –i deb軟件包名
如：dpkg –i software-1.2.3-1.deb
2. 卸載
dpkg –e 軟件名
如：dpkg –e software
Linux中find常見用法示例·
find path -option [ -print ] [ -exec -ok command ] {} \; #-print 將查找到的文件輸出到標(biāo)準(zhǔn)輸出
#-exec command {} \; -----將查到的文件執(zhí)行command操作,{} 和 \;之間有空格
#-ok 和-exec相同，只不過在
操作前要詢用戶 ==================================================== -name filename #查找名為filename的文件
-perm #按執(zhí)行權(quán)限來查找
-user username #按文件屬主來查找
-group groupname #按組來查找
-mtime -n +n #按文件更改時間來查找文件，-n指n天以內(nèi)，+n指n天以前
-atime -n +n #按文件訪問時間來查GIN: 0px">-perm #按執(zhí)行權(quán)限來查找
-user username #按文件屬主來查找
-group groupname #按組來查找
-mtime -n +n #按文件更改時間來查找文件，-n指n天以內(nèi)，+n指n天以前
-atime -n +n #按文件訪問時間來查找文件，-n指n天以內(nèi)，+n指n天以前
-ctime -n +n #按文件創(chuàng)建時間來查找文件，-n指n天以內(nèi)，+n指n天以前
-nogroup #查無有效屬組的文件，即文件的屬組在/etc/groups中不存在
-nouser #查無有效屬主的文件，即文件的屬主在/etc/passwd中不存
-newer f1 !f2 找文件，-n指n天以內(nèi)，+n指n天以前
-ctime -n +n #按文件創(chuàng)建時間來查找文件，-n指n天以內(nèi)，+n指n天以前
-nogroup #查無有效屬組的文件，即文件的屬組在/etc/groups中不存在
-nouser #查無有效屬主的文件，即文件的屬主在/etc/passwd中不存
-newer f1 !f2 #查更改時間比f1新但比f2舊的文件
-type b/d/c/p/l/f #查是塊設(shè)備、目錄、字符設(shè)備、管道、符號鏈接、普通文件-size n[c] #查長度為n塊[或n字節(jié)]的文件
-depth #使查找在進(jìn)入子目錄前先行查找完本目錄
-fstype #查更改時間比f1新但比f2舊的文件
-mount #查文件時不跨越文件
系統(tǒng)mount點(diǎn)
-follow #如果遇到符號鏈接文件，就跟蹤鏈接所指的文件
-cpio #對匹配的文件使用cpio命令，將他們備份到磁帶設(shè)備中
-prune #忽略某個目錄 ====================================================
$find ~ -name "*.txt" -print #在$HOME中查.txt文件并顯示
$find . -name "*.txt" -print $find . -name "[A-Z]*" -pri26nbsp; #對匹配的文件使用cpio命令，將他們備份到磁帶設(shè)備中
-prune #忽略某個目錄 $find . -name "[A-Z]*" -print #查以大寫字母開頭的文件
$find /etc -name "host*" -print #查以host開頭的文件
$find . -name "[a-z][a-z][0--9][0--9].txt" -print #查以兩個小寫字母和兩個數(shù)字開頭的txt文件
$find . -perm 755 -print
$find . -perm -007 -exec ls -l {} \; #查所有用戶都可讀寫執(zhí)行的文件同-perm 777
$find . -type d -print 打印目錄結(jié)構(gòu)
$find .
! -type d -print
打印非目錄文件find /usr/include -name '*.h' -exec grep AF_INEF6 {} \; 因grep無法遞歸搜索子目錄，故可以和find相結(jié)合使用。 在/usr/include 所有子目錄中的.h文件中找字串AF_INEF6
$find . -type l -print $find . -size +1000000c -print #查長度大于1Mb的文件
$find . -size 100c -print # 查長度為100c的文件
$find . -size +10 -print #查長度超過期作廢10塊的文件（1塊=512字節(jié)） $cd /
$find etc home apps -depth -print | cpio -ivcdC65536 -o /dev/rmt0
$find /etc -name "passwd*" -exec grep "cnscn" {} \; #看是否存在cnscn用戶
$find . -name "yao*" | xargs file
$find . -name "yao*" | xargs echo "" > /tmp/core.log
$find . -name "yao*" | xargs chmod o-w ====================================================== find -name april* 在當(dāng)前目錄下查找以april開始的文件
find -name april* fprint file 在當(dāng)前目錄下查找以april開始的文件，并把結(jié)果輸出到file中
find -name ap* -o -name may* 查找以ap或may開頭的文件
find /mnt -name tom.txt -ftype vfat 在/mnt下查找名稱為tom.txt且文件
系統(tǒng)類型為vfat的文件
find /mnt -name t.txt ! -ftype vfat 在/mnt下查找名稱為tom.txt且文件
系統(tǒng)類型不為vfat的文件
find /tmp -name wa* -type l 在/tmp下查找名為wa開頭且類型為符號鏈接的文件
find /home -mtime -2 在/home下查最近兩天內(nèi)改動過的文件
find /home -atime -1 查1天之內(nèi)被存取過的文件
find /home -mmin +60 在/home下查60分鐘前改動過的文件
find /home -amin +30 查最近30分鐘前被存取過的文件
find /home -newer tmp.txt 在/home下查更新時間比tmp.txt近的文件或目錄
find /home -anewer tmp.txt 在/home下查存取時間比tmp.txt近的文件或目錄
find /home -used -2 列出文件或目錄被改動過之后，在2日內(nèi)被存取過的文件或目錄
find /home -user cnscn 列出/home目錄內(nèi)屬于用戶cnscn的文件或目錄
find /home -uid +501 列出/home目錄內(nèi)用戶的識別碼大于501的文件或目錄
find /home -group cnscn 列出/home內(nèi)組為cnscn的文件或目錄
find /home -gid 501 列出/home內(nèi)組id為501的文件或目錄
find /home -nouser 列出/home內(nèi)不屬于本地用戶的文件或目錄
find /home -nogroup 列出/home內(nèi)不屬于本地組的文件或目錄
find /home -name tmp.txt -maxdepth 4 列出/home內(nèi)的tmp.txt 查時深度最多為3層
find /home -name tmp.txt -mindepth 3 從第2層開始查
find /home -empty 查找大小為0的文件或空目錄
find /home -size +512k 查大于512k的文件
find /home -size -512k 查小于512k的文件
find /home -links +2 查硬連接數(shù)大于2的文件或目錄
find /home -perm 0700 查權(quán)限為700的文件或目錄
find /tmp -name tmp.txt -exec cat {} \;
find /tmp -name tmp.txt -ok rm {} \; find / -amin -10 # 查找在
系統(tǒng)中最后10分鐘訪問的文件
find / -atime -2 # 查找在
系統(tǒng)中最后48小時訪問的文件
find / -empty # 查找在
系統(tǒng)中為空的文件或者文件夾
find / -group cat # 查找在
系統(tǒng)中屬于 groupcat的文件
find / -mmin -5 # 查找在
系統(tǒng)中最后5分鐘里修改過的文件
find / -mtime -1 #查找在
系統(tǒng)中最后24小時里修改過的文件
find / -nouser #查找在
系統(tǒng)中屬于作廢用戶的文件
find / -user fred #查找在
系統(tǒng)中屬于FRED這個用戶的文件
查當(dāng)前目錄下的所有普通文件
--------------------------------------------------------------------------------
# find . -type f -exec ls -l {} \;-rw-r--r-- 1 root root 34928 2003-02-25 ./conf/httpd.conf
-rw-r--r-- 1 root root 12959 2003-02-25 ./conf/magic
-rw-r--r-- 1 root root 180 2003-02-25 ./conf.d/README
查當(dāng)前目錄下的所有普通文件，并在- e x e c選項中使用ls -l命令將它們列出
=================================================
在/ l o g s目錄中查找更改時間在5日以前的文件并刪除它們：
$ find logs -type f -mtime +5 -exec -ok rm {} \;
=================================================
查詢當(dāng)天修改過的文件
[root@book class]# find ./ -mtime -1 -type f -exec ls -l {} \;
=================================================
查詢文件并詢問是否要顯示
[root@book class]# find ./ -mtime -1 -type f -ok ls -l {} \;
< ls ... ./classDB.inc.php > ? y
-rw-r--r-- 1 cnscn cnscn 13709 1月 12 12:22 ./classDB.inc.php
[root@book class]# find ./ -mtime -1 -type f -ok ls -l {} \;
< ls ... ./classDB.inc.php > ? n
[root@book class]# =================================================
查詢并交給awk去處理
[root@book class]# who | awk '{print $1"\t"$2}'
cnscn pts/0 =================================================
awk---grep---sed [root@book class]# df -k | awk '{print $1}' | grep -v 'none' | sed s"/\/dev\///g"
文件
系統(tǒng)sda2
sda1
[root@book class]# df -k | awk '{print $1}' | grep -v 'none'
文件
系統(tǒng)/dev/sda2
/dev/sda1
1)在/tmp中查找所有的*.h，并在這些文件中查找“SYSCALL_VECTOR"，最后打印出所有包含"SYSCALL_VECTOR"的文件名 A) find /tmp -name "*.h" | xargs -n50 grep SYSCALL_VECTOR
B) grep SYSCALL_VECTOR /tmp/*.h | cut -d':' -f1| uniq > filename
C) find /tmp -name "*.h" -exec grep "SYSCALL_VECTOR" {} \; -print
2)find / -name filename -exec rm -rf {} \;
find / -name filename -ok rm -rf {} \;
3)比如要查找磁盤中大于3M的文件：
find . -size +3000k -exec ls -ld {} ;
4)將find出來的東西拷到另一個地方
find *.c -exec cp '{}' /tmp ';' 如果有特殊文件，可以用cpio，也可以用這樣的語法：
find dir -name filename -print | cpio -pdv newdir
6)查找2004-11-30 16:36:37時更改過的文件
# A=`find ./ -name "*php"` | ls -l --full-time $A 2>/dev/null | grep "2004-11-30 16:36:37
二、linux下find命令的用法
1. 基本用法：
find / -name 文件名
find ver1.d ver2.d -name '*.c' -print 查找ver1.d,ver2.d *.c文件并打印 find . -type d -print 從當(dāng)前目錄查找，僅查找目錄，找到后，打印路徑名。可用于打印目錄結(jié)構(gòu)。
2. 無錯誤查找：
find / -name access_log 2 >/dev/null
3. 按尺寸查找：
find / -size 1500c （查找1,500字節(jié)大小的文件，c表示字節(jié)）
find / -size +1500c （查找大于1,500字節(jié)大小的文件，+表示大于）
find / -size +1500c （查找小于1,500字節(jié)大小的文件，-表示小于）
4. 按時間：
find / -amin n 最后n分鐘
find / -atime n 最后n天
find / -cmin n 最后n分鐘改變狀態(tài)
find / -ctime n 最后n天改變狀態(tài)
5. 其它：
find / -empty 空白文件、空白文件夾、沒有子目錄的文件夾
find / -false 查找
系統(tǒng)中總是錯誤的文件
find / -fstype type 找存在于指定文件
系統(tǒng)的文件，如type為ext2
find / -gid n 組id為n的文件
find / -group gname 組名為gname的文件
find / -depth n 在某層指定目錄中優(yōu)先查找文件內(nèi)容
find / -maxdepth levels 在某個層次目錄中按遞減方式查找
6. 邏輯
-and 條件與 -or 條件或
7. 查找字符串
find . -name '*.html' -exec grep 'mailto:'{}
ln是linux中又一個非常重要命令，它的功能是為某一個文件在另外一個位置建立一個同不的鏈接，這個命令最常用的參數(shù)是-s，具體用法是：ln –s 源文件 目標(biāo)文件。
當(dāng)我們需要在不同的目錄，用到相同的文件時，我們不需要在每一個需要的目錄下都放一個必須相同的文件，我們只要在某個固定的目錄，放上該文件，然后在 其它的目錄下用ln命令鏈接（link）它就可以，不必重復(fù)的占用磁盤空間。例如：ln –s /bin/less /usr/local/bin/less
-s 是代號（symbolic）的意思。
這里有兩點(diǎn)要注意：第一，ln命令會保持每一處鏈接文件的同步性，也就是說，不論你改動了哪一處，其它的文件都會發(fā)生相同的變化；第二，ln的鏈接又 軟鏈接和硬鏈接兩種，軟鏈接就是ln –s ** **，它只會在你選定的位置上生成一個文件的鏡像，不會占用磁盤空間，硬鏈接ln ** **，沒有參數(shù)-s， 它會在你選定的位置上生成一個和源文件大小相同的文件，無論是軟鏈接還是硬鏈接，文件都保持同步變化。
如果你用ls察看一個目錄時，發(fā)現(xiàn)有的文件后面有一個@的符號，那就是一個用ln命令生成的文件，用ls –l命令去察看，就可以看到顯示的link的路徑了。
指令詳細(xì)說明
指令名稱 : ln
使用權(quán)限 : 所有使用者
使用方式 : ln [options] source dist，其中 option 的格式為 :
[-bdfinsvF] [-S backup-suffix] [-V {numbered,existing,simple}]
[--help] [--version] [--]
說明 : Linux/Unix 檔案系統(tǒng)中，有所謂的連結(jié)(link)，我們可以將其視為檔案的別名，而連結(jié)又可分為兩種 : 硬連結(jié)(hard link)與軟連結(jié)(symbolic link)，硬連結(jié)的意思是一個檔案可以有多個名稱，而軟連結(jié)的方式則是產(chǎn)生一個特殊的檔案，該檔案的內(nèi)容是指向另一個檔案的位置。硬連結(jié)是存在同一個檔 案系統(tǒng)中，而軟連結(jié)卻可以跨越不同的檔案系統(tǒng)。
ln source dist 是產(chǎn)生一個連結(jié)(dist)到 source，至于使用硬連結(jié)或軟鏈結(jié)則由參數(shù)決定。
不論是硬連結(jié)或軟鏈結(jié)都不會將原本的檔案復(fù)制一份，只會占用非常少量的磁碟空間。
-f : 鏈結(jié)時先將與 dist 同檔名的檔案刪除
-d : 允許系統(tǒng)管理者硬鏈結(jié)自己的目錄
-i : 在刪除與 dist 同檔名的檔案時先進(jìn)行詢問
-n : 在進(jìn)行軟連結(jié)時，將 dist 視為一般的檔案
-s : 進(jìn)行軟鏈結(jié)(symbolic link)
-v : 在連結(jié)之前顯示其檔名
-b : 將在鏈結(jié)時會被覆寫或刪除的檔案進(jìn)行備份
-S SUFFIX : 將備份的檔案都加上 SUFFIX 的字尾
-V METHOD : 指定備份的方式
--help : 顯示輔助說明
--version : 顯示版本
范例 :
將檔案 yy 產(chǎn)生一個 symbolic link : zz
ln -s yy zz
將檔案 yy 產(chǎn)生一個 hard link : zz
ln yy xx
1.Linux的變量種類
按變量的生存周期來劃分，Linux變量可分為兩類：
1.1 永久的：需要修改配置文件，變量永久生效。
1.2 臨時的：使用export命令聲明即可，變量在關(guān)閉shell時失效。
Linux 的變量可分為兩類：環(huán)境變量和本地變量
環(huán)境變量，或者稱為全局變量，存在與所有的shell 中，在你登陸系統(tǒng)的時候就已經(jīng)有了相應(yīng)的系統(tǒng)定義的環(huán)境變量了。Linux 的環(huán)境變量具有繼承性，即子shell 會繼承父shell 的環(huán)境變量。
本地變量，當(dāng)前shell 中的變量，很顯然本地變量中肯定包含環(huán)境變量。Linux 的本地變量的非環(huán)境變量不具備繼承性。
Linux 中環(huán)境變量的文件
當(dāng)你進(jìn)入系統(tǒng)的時候，linux 就會為你讀入系統(tǒng)的環(huán)境變量，這些環(huán)境變量存放在什么地方，那就是環(huán)境變量的文件中。Linux 中有很多記載環(huán)境變量的文件，它們被系統(tǒng)讀入是按照一定的順序的。
1. /etc/profile ：
此文件為系統(tǒng)的環(huán)境變量，它為每個用戶設(shè)置環(huán)境信息，當(dāng)用戶第一次登錄時，該文件被執(zhí)行。
2.設(shè)置變量的三種方法
2.1 在/etc/profile文件中添加變量【對所有用戶生效(永久的)】
用VI在文件/etc/profile文件中增加變量，該變量將會對Linux下所有用戶有效，并且是“永久的”。
例如：編輯/etc/profile文件，添加CLASSPATH變量
# vi /etc/profile
export CLASSPATH=./JAVA_HOME/lib;$JAVA_HOME/jre/lib
注：修改文件后要想馬上生效還要運(yùn)行# source /etc/profile不然只能在下次重進(jìn)此用戶時生效。
2.2 在用戶目錄下的.bash_profile文件中增加變量【對單一用戶生效(永久的)】
用VI在用戶目錄下的.bash_profile文件中增加變量，改變量僅會對當(dāng)前用戶有效，并且是“永久的”。
例如：編輯guok用戶目錄(/home/guok)下的.bash_profile
$ vi /home/guok/.bash.profile
添加如下內(nèi)容：
export CLASSPATH=./JAVA_HOME/lib;$JAVA_HOME/jre/lib
注：修改文件后要想馬上生效還要運(yùn)行$ source /home/guok/.bash_profile不然只能在下次重進(jìn)此用戶時生效。
2.3 直接運(yùn)行export命令定義變量【只對當(dāng)前shell(BASH)有效(臨時的)】
在shell的命令行下直接使用[export 變量名=變量值]
定義變量，該變量只在當(dāng)前的shell(BASH)或其子shell(BASH)下是有效的，shell關(guān)閉了，變量也就失效了，再打開新shell時就沒有這個變量，需要使用的話還需要重新定義。
3.環(huán)境變量的查看
3.1 使用echo命令查看單個環(huán)境變量。例如：
echo $PATH
3.2 使用env查看所有環(huán)境變量。例如：
env
3.3 使用set查看所有本地定義的環(huán)境變量。
unset可以刪除指定的環(huán)境變量。
4.常用的環(huán)境變量
PATH 決定了shell將到哪些目錄中尋找命令或程序
HOME 當(dāng)前用戶主目錄
HISTSIZE 歷史記錄數(shù)
LOGNAME 當(dāng)前用戶的登錄名
HOSTNAME 指主機(jī)的名稱
SHELL 當(dāng)前用戶Shell類型
LANGUGE 語言相關(guān)的環(huán)境變量，多語言可以修改此環(huán)境變量
MAIL 當(dāng)前用戶的郵件存放目錄
PS1 基本提示符，對于root用戶是#，對于普通用戶是$
指令名稱 : chmod
使用權(quán)限 : 所有使用者
使用方式 : chmod [-cfvR] [--help] [--version] mode file...
說明 : Linux/Unix 的檔案存取權(quán)限分為三級 : 檔案擁有者、群組、其他。利用 chmod 可以控制檔案如何被他人所存取。
只能文件屬主或特權(quán)用戶才能使用該功能來改變文件存取模式。mode可以是數(shù)字形式或以who opcode permission形式表示。who是可選的，默認(rèn)是a(所有用戶)。只能選擇一個opcode(操作碼)。可指定多個mode，以逗號分開。
options：
-c，--changes
只輸出被改變文件的信息
-f，--silent，--quiet
當(dāng)chmod不能改變文件模式時，不通知文件的用戶
--help
輸出幫助信息。
-R，--recursive
可遞歸遍歷子目錄，把修改應(yīng)到目錄下所有文件和子目錄
--reference=filename
參照filename的權(quán)限來設(shè)置權(quán)限
-v，--verbose
無論修改是否成功，輸出每個文件的信息
--version
輸出版本信息。
who
u
用戶
g
組
o
其它
a
所有用戶(默認(rèn))
opcode
+
增加權(quán)限
-
刪除權(quán)限
=
重新分配權(quán)限
permission
r
讀
w
寫
x
執(zhí)行
s
設(shè)置用戶(或組)的ID號
t
設(shè)置粘著位(sticky bit)，防止文件或目錄被非屬主刪除
u
用戶的當(dāng)前權(quán)限
g
組的當(dāng)前權(quán)限
o
其他用戶的當(dāng)前權(quán)限
作為選擇，我們多數(shù)用三位八進(jìn)制數(shù)字的形式來表示權(quán)限，第一位指定屬主的權(quán)限，第二位指定組權(quán)限，第三位指定其他用戶的權(quán)限，每位通過4(讀)、2(寫)、1(執(zhí)行)三種數(shù)值的和來確定權(quán)限。如6(4+2)代表有讀寫權(quán)，7(4+2+1)有讀、寫和執(zhí)行的權(quán)限。
還可設(shè)置第四位，它位于三位權(quán)限序列的前面，第四位數(shù)字取值是4，2，1，代表意思如下：
4，執(zhí)行時設(shè)置用戶ID，用于授權(quán)給基于文件屬主的進(jìn)程，而不是給創(chuàng)建此進(jìn)程的用戶。
2，執(zhí)行時設(shè)置用戶組ID，用于授權(quán)給基于文件所在組的進(jìn)程，而不是基于創(chuàng)建此進(jìn)程的用戶。
1，設(shè)置粘著位。
實例：
$ chmod u+x file 給file的屬主增加執(zhí)行權(quán)限
$ chmod 751 file 給file的屬主分配讀、寫、執(zhí)行(7)的權(quán)限，給file的所在組分配讀、執(zhí)行(5)的權(quán)限，給其他用戶分配執(zhí)行(1)的權(quán)限
$ chmod u=rwx,g=rx,o=x file 上例的另一種形式
$ chmod =r file 為所有用戶分配讀權(quán)限
$ chmod 444 file 同上例
$ chmod a-wx,a+r file 同上例
$ chmod -R u+r directory 遞歸地給directory目錄下所有文件和子目錄的屬主分配讀的權(quán)限
$ chmod 4755 設(shè)置用ID，給屬主分配讀、寫和執(zhí)行權(quán)限，給組和其他用戶分配讀、執(zhí)行的權(quán)限。
指令名稱 : chown
使用權(quán)限 : root
使用方式 : chown[-cfhvR] [--help] [--version] user[:group] file...
說明 : Linux/Unix 是多人多工作業(yè)系統(tǒng)，所有的檔案皆有擁有者。利用 chown 可以將檔案的擁有者加以改變。一般來說，這個指令只有是由系統(tǒng)管理者(root)所使用，一般使用者沒有權(quán)限可以改變別人的檔案擁有者，也沒有權(quán)限可以自己的檔案擁有者改設(shè)為別人。只有系統(tǒng)管理者(root)才有這樣的權(quán)限。
基于spring開發(fā)了個自定義標(biāo)簽，功能測試正常，在myeclipse中提示編譯錯誤:
Multiple annotations found at this line:
- cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'fw:annotation-handler'.
- schema_reference.4: Failed to read schema document 'http://www.300.cn/schema/annotation-handler.xsd', because 1) could not find the
document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
這個問題在以前改動struts配置文件的時候也出現(xiàn)過。在引入一些第三方j(luò)ar容易出現(xiàn)這個問題。
雖然不影響使用，但是看著挺討厭的，找了一下解決方法。
菜單-->windows-->prefreneces 找到XML Catalog,在User Specified Entries添加xsd文件
有兩個地方要注意:
1.Key type設(shè)置為Schema location;
2.key 設(shè)置虛擬xsd地址，即
xsi:schemaLocation=" http://www.springframework.org/schema/task
http://www.springframework.org/schema/task/spring-task-3.0.xsd“
名稱對后邊的這一個。
自從搬到東邊住以后就很少去海淀圖書城了，因為想?yún)⒓?1月的軟考，端午去海圖找本考試大綱。
前幾年去海圖的時候，java方面的圖書都放在最顯眼的地方，能占好幾排書架，現(xiàn)在已經(jīng)被andriod、ios取代。找了一圈才在一個不起眼的角落找到j(luò)ava系列圖書。c/c++這樣的書倒不見減少，比印象中還有增加。
從書市上看java最風(fēng)光的時候已經(jīng)過去了，一直做java方面的開發(fā)，對這方面的變化不敏感，還是賣書的對市場感受更直接。
各領(lǐng)風(fēng)騷好幾年。
這幾天抽空看了本《問題分析與決策》，蘭德公司出版的，就是那個預(yù)言中國將出兵朝鮮的公司。挺好的一本書，不知道為什么中文版的特別少，找了半天。
老外做研究的風(fēng)格，很少那種大而無當(dāng)?shù)目赵挘瑢栴}分析的過程和分析者的心理活動做了大量研究工作。
我做過一段時間的系統(tǒng)分析工作，書中有些觀點(diǎn)讓人看起來心有戚戚焉，還有部分觀點(diǎn)是自己沒想到的，讀后很是能解惑。
做些簡單摘錄
很多人采用的處理問題與決策的辦法，根本沒有多大用處，甚至完全沒有用處。
引言蘭德提出這種問題分析方法的思路，從一個公司的某一個問題著手，追溯到解決這一問題的程序，仔細(xì)剖視每一步驟中的思想過程。
根據(jù)這些研究得出了很多概念和方法，認(rèn)為問題分析與決策時管理上的行為，必須自覺和有系統(tǒng)的去做。
而且必要的話，還應(yīng)該記錄下來。
分析問題是一項依照邏輯體系而進(jìn)行的程序，首先是確定問題，然后是經(jīng)過分析以及尋求原因，最后做決定。
每個階段包括若干基本的概念，其中一項基本概念是，一個問題乃是一件事“應(yīng)該怎么樣”和“事實上是怎么樣的”兩者之間的偏差。
另一項概念是，這種偏差是由于某一種“變化”二造成的。除非先把這一變化準(zhǔn)確的予以確定，否則一切糾正這一偏差的措施都只是揣測而已。
概念與方法
問題分析的兩個主要概念：
1.每個問題都是標(biāo)準(zhǔn)的預(yù)期效果所發(fā)生的偏差；
2.某種變化是造成這一問題的根本原因。
分析問題的七項基本概念
1.有標(biāo)準(zhǔn)；
2.問題就是情況與標(biāo)準(zhǔn)之間的偏差
3.偏差要準(zhǔn)確的認(rèn)定
4.分析問題的獨(dú)特性，受影響和沒受影響部分各有什么特點(diǎn)，區(qū)分開來；
5.只考慮與特殊變化有關(guān)的情況，通過界定問題范圍找出原因。
6.造成偏差的原因是從分析問題時發(fā)現(xiàn)的變化中推導(dǎo)出來的 。
7.最可能造成偏差的原因，是能解釋界定范圍內(nèi)一切事實的那一項原因。
如何界定一個問題1.什么；2時間；3.地點(diǎn)4.幅度
如何尋求特點(diǎn)與變化
任何問題發(fā)生的原因，乃是一種變化；這種變化的影響是有限度的，只在某些地方有影響，在其他地方?jīng)]有影響。
這種變化，只存在于特定的范圍之內(nèi)，或者只發(fā)生與那些可以區(qū)分出問題的“是”的一面某些因素上。
因此，要追究什么樣的變化會發(fā)生某一種影響，最有效的方法是只尋求那些僅存在于界定問題時所發(fā)現(xiàn)的各項特點(diǎn)的變化。
我們要找出來把事物區(qū)分開來的因素，分析問題的人必須從事物的不同點(diǎn)去思考。
(么東西出了問題，不是什么出了問題，減小范圍)
發(fā)生變化的線索就在，區(qū)分“是”與“不是”的特點(diǎn)中。
能看出特點(diǎn)與變化的能力是智慧的主要表現(xiàn)之一，在問題分析上是非常重要的。
一個問題的形成可能受許多因素的影響，但是真正動搖了事態(tài)均衡而引發(fā)問題的卻只有一種變化。
事先不界定問題和研求特點(diǎn)，一發(fā)現(xiàn)某項變化立即斷定這就是問題的原因所在是很危險的。
決策分析1.訂立決策的目標(biāo)；
2.依據(jù)重要性將目標(biāo)分類；
3.擬定可供選擇的措施；
4.把各種可行的辦法與目標(biāo)加以對照衡量；
5.選擇最好的辦法作為暫時決策；
6.研究決策是否會有不良影響；
7.同時采取防止不良后果的措施。
之前做過一版工作流引擎，自己開發(fā)的。這段時間又以jbpm為內(nèi)核做了一版流程系統(tǒng)，有些思考就記錄下來。
有一句話說的好，如果你手里有一把錘子你就看什么都像釘子。做流程系統(tǒng)的時候也遇到這類現(xiàn)象，因為對流程系統(tǒng)的不熟悉，在開發(fā)過程中就想到處都用工作流來處理問題。
其實引入一個新的東西，一定要先搞明白的它的適用場景，有什么價值。把握了這點(diǎn)后結(jié)合具體場景，就能很好的使用，而不會亂用。
一、工作流適用場景
以下兩種情況需要引入流程系統(tǒng)
1.分散系統(tǒng)整合(企業(yè)應(yīng)用集成)
2.簡化業(yè)務(wù)系統(tǒng)的開發(fā)；
工作流的價值
1.業(yè)務(wù)流程獨(dú)立化；
2.優(yōu)化改進(jìn)流程更容易；
3.提供統(tǒng)一的監(jiān)控頁面。
Ⅰ 、相對于分散系統(tǒng)，提供了統(tǒng)一的操作和監(jiān)控頁面。對用戶更友好，過程可監(jiān)控，業(yè)務(wù)規(guī)則更明確。
1.業(yè)務(wù)流程獨(dú)立化，業(yè)務(wù)規(guī)則不僅僅存在與工作人員的頭腦中。
2.提供了統(tǒng)一的監(jiān)控界面，實現(xiàn)業(yè)務(wù)過程可監(jiān)控；
3.有明確的規(guī)則，可以監(jiān)控運(yùn)行情況，為流程的優(yōu)化提供了便利；
4.對用戶更友好；
Ⅱ 、相對于傳統(tǒng)業(yè)務(wù)系統(tǒng)方式
1.業(yè)務(wù)流程獨(dú)立化，業(yè)務(wù)規(guī)則不會淹沒于業(yè)務(wù)系統(tǒng)代碼中。避免業(yè)務(wù)系統(tǒng)開發(fā)完成后再次改動成本高的情況。
2.提供了統(tǒng)一的監(jiān)控界面，實現(xiàn)業(yè)務(wù)過程可監(jiān)控；原業(yè)務(wù)系統(tǒng)提供的報表對環(huán)節(jié)執(zhí)行時間可能信息不足，一般只是簡單反應(yīng)狀態(tài)變化。
3.有明確的規(guī)則，可以監(jiān)控運(yùn)行情況，為流程的優(yōu)化提供了便利；
4.對于工作人員來講，這些改進(jìn)其實是透明的，從用戶體驗的角度沒有什么變化。
所以對原業(yè)務(wù)系統(tǒng)的用戶來講，變化不大。引入流程系統(tǒng)更多的是為了監(jiān)控和優(yōu)化流程的方便，是從管理的角度考慮問題。
從流程系統(tǒng)提供的待辦事項列表進(jìn)行操作，還是從業(yè)務(wù)系統(tǒng)的功能菜單進(jìn)行操作，哪個更友好是UE設(shè)計的問題，跟流程系統(tǒng)無關(guān)。
業(yè)務(wù)系統(tǒng)功能菜單的劃分可能相對于待辦事項列表更直觀、定位更準(zhǔn)確。(見下圖紅色箭頭對兩種方式的表示)
考慮到業(yè)務(wù)流程的復(fù)雜性，對于企業(yè)信息化系統(tǒng)引入流程系統(tǒng)可以便于優(yōu)化流程，對于成熟的業(yè)務(wù)系統(tǒng)如財務(wù)軟件引入流程系統(tǒng)完全沒有必要。
補(bǔ)充說明：
1.當(dāng)前任務(wù)列表方式，需要用戶不停的查看有沒有新任務(wù)到來；優(yōu)點(diǎn)是在一個頁面可以看到全部待辦事項。
2.業(yè)務(wù)系統(tǒng)功能菜單方式，需要用戶不停的查詢工作進(jìn)展并作出處理。優(yōu)點(diǎn)是任務(wù)類型劃分更明確；
二、業(yè)務(wù)系統(tǒng)接入方式
1.在jsp頁面增加環(huán)節(jié)信息(環(huán)節(jié)編號，流程編號...);
2.業(yè)務(wù)系統(tǒng)aciton不變；
3.在業(yè)務(wù)系統(tǒng)action完成操作后，流程攔截器處理流程變化并記錄到數(shù)據(jù)庫；
4.流程監(jiān)控頁面和待辦事項列表，不斷從流程數(shù)據(jù)庫查詢。
5.對于專業(yè)性比價強(qiáng)的的狀態(tài)值還是在業(yè)務(wù)系統(tǒng)維護(hù)，避免流程系統(tǒng)壓力過大。在需要監(jiān)控改進(jìn)的業(yè)務(wù)點(diǎn)交由流程系統(tǒng)調(diào)度，其它部分還是由業(yè)務(wù)系統(tǒng)處理。
.jpg)
--------------------------------------
下邊是對struts項目接入流程系統(tǒng)的一個分析
1.業(yè)務(wù)系統(tǒng)jsp,action調(diào)用關(guān)系
2.采用攔截器在業(yè)務(wù)系統(tǒng)action執(zhí)行完成后，進(jìn)行流程驅(qū)動，并在下一個jsp頁面注入流程信息。
主要邏輯都在beforeResult()方法中。3.數(shù)據(jù)結(jié)構(gòu)
數(shù)據(jù)結(jié)構(gòu)說明：
1.對于通用的流程數(shù)據(jù)可以在beforeResult()方法自動嵌入，為考慮交互效果在jsp自行設(shè)置流程信息;
2.jsp頁面流程數(shù)據(jù)應(yīng)該包括:
1.nodeName
節(jié)點(diǎn)名稱，環(huán)節(jié)在流程定義中的名稱；
2.transitionNames
流向名稱列表，需要作出選擇的列表。
3.entityId
實體id,用于查詢流程實例ID。
3.在action執(zhí)行完成后驅(qū)動流程所需要的數(shù)據(jù)：
1.definitionId
流程定義，說明是新啟動一個流程。
2.nodeName
節(jié)點(diǎn)名稱，根據(jù)流程實例ID和節(jié)點(diǎn)名稱查詢?nèi)蝿?wù)ID,每個節(jié)點(diǎn)只能是單任務(wù)的，否則jsp頁面無法提供taskId.
3.transitionName
流向名稱，根據(jù)流向選擇流程下一步跳轉(zhuǎn)的節(jié)點(diǎn)。串行節(jié)點(diǎn)不用transitionName 可為空。
4.entityId
實體id,查詢流程實例ID用。
4.對與工作流無關(guān)的action實行過濾，不做處理。
兩種過濾方式：
1.在action方法加注解；
2.在數(shù)據(jù)結(jié)構(gòu)中增加數(shù)據(jù)項標(biāo)記。
5.對與工作流無關(guān)的jsp頁面，不使用工作流tag即可。
-----------------------------
上邊是我一開始的想法，后來和同事討論后又做了些調(diào)整。編輯web文字比較麻煩，就不合在一起了。
1.對執(zhí)行業(yè)務(wù)操作的action和進(jìn)入jsp頁面的初始化action進(jìn)行分類；
2.參數(shù)傳遞過程補(bǔ)充說明
一個分為三步
倒著說
第三步，功能頁面jsp在提交參數(shù)時需附加(節(jié)點(diǎn)名稱、流向名稱、工單編號)，流程引擎才能驅(qū)動流程；
第二步，要能夠向第三步提供數(shù)據(jù)，jsp頁面必須包含(節(jié)點(diǎn)名稱、流向名稱列表、工單編號)，這些數(shù)據(jù)有兩個來源：1.收到在jsp頁面寫入;2.從第一步接收。
第一步，有同事建議，提供節(jié)點(diǎn)和資源路徑的關(guān)系表，通過資源路徑查找節(jié)點(diǎn)名稱。減少流程系統(tǒng)對業(yè)務(wù)系統(tǒng)的侵入。
----------------------------------
上傳的時候圖片丟了，重新補(bǔ)一下。
今天抽空整理些有關(guān)rest方面的理論。主要參考了幾篇網(wǎng)上的文章，做了些整理，原文見附錄。
一、起源
越來越多的人開始意識到，網(wǎng)站即軟件，而且是一種新型的軟件。
這種"互聯(lián)網(wǎng)軟件"采用客戶端/服務(wù)器模式，建立在分布式體系上，通過互聯(lián)網(wǎng)通信，具有高延時（high latency）、高并發(fā)等特點(diǎn)。
網(wǎng)站開發(fā)，完全可以采用軟件開發(fā)的模式。但是傳統(tǒng)上，軟件和網(wǎng)絡(luò)是兩個不同的領(lǐng)域，很少有交集；軟件開發(fā)主要針對單機(jī)環(huán)境，網(wǎng)絡(luò)則主要研究系統(tǒng)之間的通信。互聯(lián)網(wǎng)的興起，使得這兩個領(lǐng)域開始融合，現(xiàn)在我們必須考慮，如何開發(fā)在互聯(lián)網(wǎng)環(huán)境中使用的軟件。
RESTful架構(gòu)，就是一種互聯(lián)網(wǎng)軟件架構(gòu)。它結(jié)構(gòu)清晰、符合標(biāo)準(zhǔn)、易于理解、擴(kuò)展方便，所以正得到越來越多網(wǎng)站的采用。
二、名稱
Fielding將他對互聯(lián)網(wǎng)軟件的架構(gòu)原則，定名為REST，即Representational State Transfer的縮寫。我對這個詞組的翻譯是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。
如果一個架構(gòu)符合REST原則，就稱它為RESTful架構(gòu)。
要理解RESTful架構(gòu)，最好的方法就是去理解Representational State Transfer這個詞組到底是什么意思，它的每一個詞代表了什么涵義。如果你把這個名稱搞懂了，也就不難體會REST是一種什么樣的設(shè)計。
三、資源（Resources）
REST的名稱"表現(xiàn)層狀態(tài)轉(zhuǎn)化"中，省略了主語。"表現(xiàn)層"其實指的是"資源"（Resources）的"表現(xiàn)層"。
所謂"資源"，就是網(wǎng)絡(luò)上的一個實體，或者說是網(wǎng)絡(luò)上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務(wù)，總之就是一個具體的實在。你可以用一個URI（統(tǒng)一資源定位符）指向它，每種資源對應(yīng)一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨(dú)一無二的識別符。
所謂"上網(wǎng)"，就是與互聯(lián)網(wǎng)上一系列的"資源"互動，調(diào)用它的URI。
四、表現(xiàn)層（Representation）
"資源"是一種信息實體，它可以有多種外在表現(xiàn)形式。我們把"資源"具體呈現(xiàn)出來的形式，叫做它的"表現(xiàn)層"（Representation）。
比如，文本可以用txt格式表現(xiàn)，也可以用HTML格式、XML格式、JSON格式表現(xiàn)，甚至可以采用二進(jìn)制格式；圖片可以用JPG格式表現(xiàn)，也可以用PNG格式表現(xiàn)。
URI只代表資源的實體，不代表它的形式。嚴(yán)格地說，有些網(wǎng)址最后的".html"后綴名是不必要的，因為這個后綴名表示格式，屬于"表現(xiàn)層"范疇，而URI應(yīng)該只代表"資源"的位置。它的具體表現(xiàn)形式，應(yīng)該在HTTP請求的頭信息中用Accept和Content-Type字段指定，這兩個字段才是對"表現(xiàn)層"的描述。
五、狀態(tài)轉(zhuǎn)化（State Transfer）
訪問一個網(wǎng)站，就代表了客戶端和服務(wù)器的一個互動過程。在這個過程中，勢必涉及到數(shù)據(jù)和狀態(tài)的變化。
互聯(lián)網(wǎng)通信協(xié)議HTTP協(xié)議，是一個無狀態(tài)協(xié)議。這意味著，所有的狀態(tài)都保存在服務(wù)器端。因此，如果客戶端想要操作服務(wù)器，必須通過某種手段，讓服務(wù)器端發(fā)生"狀態(tài)轉(zhuǎn)化"（State Transfer）。而這種轉(zhuǎn)化是建立在表現(xiàn)層之上的，所以就是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。
客戶端用到的手段，只能是HTTP協(xié)議。具體來說，就是HTTP協(xié)議里面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應(yīng)四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用于更新資源），PUT用來更新資源，DELETE用來刪除資源。
六、綜述
綜合上面的解釋，我們總結(jié)一下什么是RESTful架構(gòu)：
（1）每一個URI代表一種資源；
（2）客戶端和服務(wù)器之間，傳遞這種資源的某種表現(xiàn)層；
（3）客戶端通過四個HTTP動詞，對服務(wù)器端資源進(jìn)行操作，實現(xiàn)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。
REST關(guān)鍵原則
一個簡單扼要的定義：REST定義了應(yīng)該如何正確地使用Web標(biāo)準(zhǔn)，例如HTTP和URI。如果你在設(shè)計應(yīng)用程序時能堅持REST原則，那就預(yù)示著你將會得到一個使用了優(yōu)質(zhì)Web架構(gòu)（這將讓你受益）的系統(tǒng)。總之，五條關(guān)鍵原則列舉如下：
- 為所有“事物”定義ID
- 將所有事物鏈接在一起
- 使用標(biāo)準(zhǔn)方法
- 資源多重表述
- 無狀態(tài)通信
為所有“事物”定義ID
在這里我使用了“事物”來代替更正式準(zhǔn)確的術(shù)語“資源”，因為一條如此簡單的原則，不應(yīng)該被淹沒在術(shù)語當(dāng)中。思考一下人們構(gòu)建的系統(tǒng)，通常會找到一系列值得被標(biāo)識的關(guān)鍵抽象。每個事物都應(yīng)該是可標(biāo)識的，都應(yīng)該擁有一個明顯的ID——在Web中，代表ID的統(tǒng)一概念是：URI。URI構(gòu)成了一個全局命名空間，使用URI標(biāo)識你的關(guān)鍵資源意味著它們獲得了一個唯一、全局的ID。
值得被URI標(biāo)識的事物——資源——要比數(shù)據(jù)庫記錄抽象的多。標(biāo)識所有值得標(biāo)識的事物，領(lǐng)會這個觀念可以進(jìn)一步引導(dǎo)你創(chuàng)造出在傳統(tǒng)的應(yīng)用程序設(shè)計中不常見的資源：一個流程或者流程步驟、一次銷售、一次談判、一份報價請求——這都是應(yīng)該被標(biāo)識的事物的示例。
將所有事物鏈接在一起
接下來要討論的原則有一個有點(diǎn)令人害怕的正式描述：“超媒體被當(dāng)作應(yīng)用狀態(tài)引擎（Hypermedia as the engine of application state）”，有時簡寫為HATEOAS。（嚴(yán)格地說，這不是我說的。）這個描述的核心是超媒體概念，換句話說：是鏈接的思想。鏈接是我們在HTML中常見的概念，但是它的用處絕不局限于此（用于人們網(wǎng)絡(luò)瀏覽）。
使用標(biāo)準(zhǔn)方法
在前兩個原則的討論中暗含著一個假設(shè)：接收URI的應(yīng)用程序可以通過URI明確地做一些有意義的事情。如果你在公共汽車上看到一個URI，你可以將它輸入瀏覽器的地址欄中并回車——但是你的瀏覽器如何知道需要對這個URI做些什么呢？
它知道如何去處理URI的原因在于所有的資源都支持同樣的接口，一套同樣的方法（只要你樂意，也可以稱為操作）集合。在HTTP中這被叫做動詞（verb），除了兩個大家熟知的（GET和POST）之外，標(biāo)準(zhǔn)方法集合中還包含PUT、DELETE、HEAD和OPTIONS。這些方法的含義連同行為許諾都一起定義在HTTP規(guī)范之中。
資源多重表述
在實踐中，資源多重表述還有著其它重要的好處：如果你為你的資源提供HTML和XML兩種表述方式，那這些資源不僅可以被你的應(yīng)用所用，還可以被任意標(biāo)準(zhǔn)Web瀏覽器所用——也就是說，你的應(yīng)用信息可以被所有會使用Web的人獲取到。
無狀態(tài)通信
首先，需要著重強(qiáng)調(diào)的是，雖然REST包含無狀態(tài)性（statelessness）的觀念，但這并不是說暴露功能的應(yīng)用不能有狀態(tài)——
事實上，在大部分情況下這會導(dǎo)致整個做法沒有任何用處。REST要求狀態(tài)要么被放入資源狀態(tài)中，要么保存在客戶端上。
或者換句話說，服務(wù)器端不能保持除了單次請求之外的，任何與其通信的客戶端的通信狀態(tài)。這樣做的最直接的理由就是可伸縮性—— 如果服務(wù)器需要保持客戶端狀態(tài)，那么大量的客戶端交互會嚴(yán)重影響服務(wù)器的內(nèi)存可用空間（footprint）。（注意，要做到無狀態(tài)通信往往需要需要一些重新設(shè)計——不能簡單地將一些session狀態(tài)綁縛在URI上，然后就宣稱這個應(yīng)用是RESTful。）
但除此以外，其它方面可能顯得更為重要：無狀態(tài)約束使服務(wù)器的變化對客戶端是不可見的，因為在兩次連續(xù)的請求中，客戶端并不依賴于同一臺服務(wù)器。一個客戶端從某臺服務(wù)器上收到一份包含鏈接的文檔，當(dāng)它要做一些處理時，這臺服務(wù)器宕掉了，可能是硬盤壞掉而被拿去修理，可能是軟件需要升級重啟——如果這個客戶端訪問了從這臺服務(wù)器接收的鏈接，它不會察覺到后臺的服務(wù)器已經(jīng)改變了。
REST風(fēng)格的一個“化身”便是HTTP（以及一套相關(guān)的一套標(biāo)準(zhǔn)，比如URI）。
附錄:
1.深入淺出REST
http://www.infoq.com/cn/articles/rest-introduction2.理解Restful 架構(gòu)
http://www.ruanyifeng.com/blog/2011/09/restful.html3.Rest和soap比較
http://www.infoq.com/cn/articles/rest-soap-when-to-use-each4.Rest和Rpc比較
http://xinklabi.iteye.com/blog/807220
定時程序時間格式，原文見http://blog.csdn.net/remote_roamer/article/details/6573173
一個cron表達(dá)式有至少6個（也可能7個）有空格分隔的時間元素。
按順序依次為
秒（0~59）
分鐘（0~59）
小時（0~23）
天（月）（0~31，但是你需要考慮你月的天數(shù)）
月（0~11）
天（星期）（1~7 1=SUN 或 SUN，MON，TUE，WED，THU，F(xiàn)RI，SAT）
7.年份（1970－2099）
其中每個元素可以是一個值(如6),一個連續(xù)區(qū)間(9-12),一個間隔時間(8-18/4)(/表示每隔4小時),一個列表(1,3,5),通配符。由于"月份中的日期"和"星期中的日期"這兩個元素互斥的,必須要對其中一個設(shè)置?.
0 0 10,14,16 * * ? 每天上午10點(diǎn)，下午2點(diǎn)，4點(diǎn)
0 0/30 9-17 * * ? 朝九晚五工作時間內(nèi)每半小時
0 0 12 ? * WED 表示每個星期三中午12點(diǎn)
"0 0 12 * * ?" 每天中午12點(diǎn)觸發(fā)
"0 15 10 ? * *" 每天上午10:15觸發(fā)
"0 15 10 * * ?" 每天上午10:15觸發(fā)
"0 15 10 * * ? *" 每天上午10:15觸發(fā)
"0 15 10 * * ? 2005" 2005年的每天上午10:15觸發(fā)
"0 * 14 * * ?" 在每天下午2點(diǎn)到下午2:59期間的每1分鐘觸發(fā)
"0 0/5 14 * * ?" 在每天下午2點(diǎn)到下午2:55期間的每5分鐘觸發(fā)
"0 0/5 14,18 * * ?" 在每天下午2點(diǎn)到2:55期間和下午6點(diǎn)到6:55期間的每5分鐘觸發(fā)
"0 0-5 14 * * ?" 在每天下午2點(diǎn)到下午2:05期間的每1分鐘觸發(fā)
"0 10,44 14 ? 3 WED" 每年三月的星期三的下午2:10和2:44觸發(fā)
"0 15 10 ? * MON-FRI" 周一至周五的上午10:15觸發(fā)
"0 15 10 15 * ?" 每月15日上午10:15觸發(fā)
"0 15 10 L * ?" 每月最后一日的上午10:15觸發(fā)
"0 15 10 ? * 6L" 每月的最后一個星期五上午10:15觸發(fā)
"0 15 10 ? * 6L 2002-2005" 2002年至2005年的每月的最后一個星期五上午10:15觸發(fā)
"0 15 10 ? * 6#3" 每月的第三個星期五上午10:15觸發(fā)
有些子表達(dá)式能包含一些范圍或列表
例如：子表達(dá)式（天（星期） ）可以為 “MON-FRI”，“MON，WED，F(xiàn)RI”，“MON-WED,SAT”
“*”字符代表所有可能的值
因此，“*”在子表達(dá)式（月 ）里表示每個月的含義，“*”在子表達(dá)式（天（星期） ）表示星期的每一天
“/”字符用來指定數(shù)值的增量
例如：在子表達(dá)式（分鐘）里的“0/15”表示從第0分鐘開始，每15分鐘
在子表達(dá)式（分鐘）里的“3/20”表示從第3分鐘開始，每20分鐘（它和“3，23，43”）的含義一樣
“？”字符僅被用于天（月）和天（星期）兩個子表達(dá)式，表示不指定值
當(dāng)2個子表達(dá)式其中之一被指定了值以后，為了避免沖突，需要將另一個子表達(dá)式的值設(shè)為“？”
“L” 字符僅被用于天（月）和天（星期）兩個子表達(dá)式，它是單詞“last”的縮寫
但是它在兩個子表達(dá)式里的含義是不同的。
在天（月）子表達(dá)式中，“L”表示一個月的最后一天
在天（星期）自表達(dá)式中，“L”表示一個星期的最后一天，也就是SAT
如果在“L”前有具體的內(nèi)容，它就具有其他的含義了
例如：“6L”表示這個月的倒數(shù)第６天，“ＦＲＩＬ”表示這個月的最一個星期五
注意：在使用“L”參數(shù)時，不要指定列表或范圍，因為這會導(dǎo)致問題
| 字段 |
|
允許值 |
|
允許的特殊字符 |
秒 |
|
0-59 |
|
, - * / |
分 |
|
0-59 |
|
, - * / |
小時 |
|
0-23 |
|
, - * / |
日期 |
|
1-31 |
|
, - * ? / L W C |
月份 |
|
1-12 或者 JAN-DEC |
|
, - * / |
星期 |
|
1-7 或者 SUN-SAT |
|
, - * ? / L C # |
年（可選） |
|
留空, 1970-2099 |
|
, - * / |
這篇也是轉(zhuǎn)載，改了中間部分內(nèi)。
在基于注解方式配置Spring
的配置文件中，你可能會見到<context:annotation-config/>這樣一條配置，他的作用是式地向 Spring
容器注冊
AutowiredAnnotationBeanPostProcessor、CommonAnnotationBeanPostProcessor、
PersistenceAnnotationBeanPostProcessor 以及 RequiredAnnotationBeanPostProcessor 這 4 個BeanPostProcessor。
注冊這4個 BeanPostProcessor的作用，就是為了你的系統(tǒng)能夠識別相應(yīng)的注解。
例如：
如果你想使用@Autowired注解，那么就必須事先在 Spring 容器中聲明 AutowiredAnnotationBeanPostProcessor Bean。傳統(tǒng)聲明方式如下：
- <bean class="org.springframework.beans.factory.annotation. AutowiredAnnotationBeanPostProcessor "/>
如果想使用@ Resource 、@ PostConstruct、@ PreDestroy等注解就必須聲明CommonAnnotationBeanPostProcessor
如果想使用@PersistenceContext注解，就必須聲明PersistenceAnnotationBeanPostProcessor的Bean。
如果想使用 @Required的注解，就必須聲明RequiredAnnotationBeanPostProcessor的Bean。同樣，傳統(tǒng)的聲明方式如下：
- <bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"/>
一般來說，這些注解我們還是比較常用，尤其是Antowired的注解，在自動注入的時候更是經(jīng)常使用，所以如果總是需要按照傳統(tǒng)的方式一條一條配置顯得有些繁瑣和沒有必要，于是spring給我們提供<context:annotation-config/>的簡化配置方式，自動幫你完成聲明。
不過，呵呵，我們使用注解一般都會配置掃描包路徑選項
- <context:component-scan base-package=”XX.XX”/>
該配置項其實也包含了自動注入上述processor的功能，因此當(dāng)使用 <context:component-scan/> 后，就可以將 <context:annotation-config/> 移除了。
本文轉(zhuǎn)載：http://mushiqianmeng.blog.51cto.com/3970029/723880
有一段時間沒有關(guān)注spring了，spring2.5就蠻夠用的，spring3出來后一直沒怎么關(guān)注。
這幾天抽空關(guān)注一下。干咱這行的還是要緊跟時代變化啊。
下邊這些內(nèi)容是轉(zhuǎn)載51cto的一篇文章。
1、項目結(jié)構(gòu)與構(gòu)建變化
解壓后的立即發(fā)現(xiàn)，Spring 3.0的項目結(jié)構(gòu)已經(jīng)發(fā)現(xiàn)了巨大變化：
1、Spring3采用多項目結(jié)構(gòu)源碼組織，不再是以前的單一方式，共26個項目，差不多每個項目對于一個分發(fā)的jar包，不過有些項目是空的，或者是為了構(gòu)建而設(shè)。
2、不再提供完整打包文件spring.jar，而是20個jar（或稱bundle），一方面應(yīng)該也是向osgi靠攏。
Spring 3.0的readme中說道：
Note that this release does not contain a 'spring.jar' file anymore, in contrast to previous Spring generations. Furthermore, the jar file names follow bundle repository conventions now.
（51CTO編輯快譯：與之前的Spring版本相反，此次發(fā)布不再包括spring.jar文件了。新版本中的jar文件命名由bundle版本庫的規(guī)則所決定。）
3、采用Ivy為主構(gòu)建方式，當(dāng)然仍然有Maven，項目結(jié)構(gòu)由Maven管理。另外沒有打包全部的依賴包了，整個下載包比2.5的小了近一半
4、Spring3已經(jīng)完全采用Java5/6開發(fā)和編譯構(gòu)建，因此應(yīng)該是不再支持Java1.4及更早版本了
2、框架結(jié)構(gòu)的變化
框架結(jié)構(gòu)的架構(gòu)圖也進(jìn)一步演變了，不再是原來那個簡單的方塊圖：
Spring3架構(gòu)圖
跟原來的相比，DAO、ORM、JEE等模塊被劃歸到了一起，成為“數(shù)據(jù)訪問/集成”部分，Web層突出了自己的MVC(Servlet)和Portlet，核心容器增加了表達(dá)式語言。另外，對測試的支持也放到了整個架構(gòu)中來了。所以整個框架重新劃分成了五部分。
因此，典型的全應(yīng)用場景也相應(yīng)變化，并提示使用自家的Tomcat：
關(guān)于eclipse的一些應(yīng)用，開發(fā)過程中用到了就隨手記下。
1.Web App Libraries and Eclipse Build Path
在eclipse下創(chuàng)建web項目，在build path下會對應(yīng)包含Web App Libraries 動態(tài)加載項目下/WebContent/WEB-INF/lib所有的jar文件。
好處是在項目增加或刪除jar包時不用總是修改build path配置文件，從cvs同步代碼的時候保持這部分不變。
2.system library
有些jar在開發(fā)的時候要用到，但是部署的時候不用部署到服務(wù)器。
比如:jsp-api.jar,servelet.jar，這些文件在tomcat jboss 下已經(jīng)包含，重復(fù)部署的話會引起錯誤。
我以前的做法是在anr build.xml文件中打包生成war時刪除對應(yīng)的jar包。
剛發(fā)現(xiàn)還有這么一種用法，在eclipse添加system library把jar添加到該庫下就不會部署到服務(wù)器。
如圖:主要tomcat-jar 一定要設(shè)置成system library
關(guān)于在創(chuàng)業(yè)公司工作的話題，以前跟同事討論過，剛看到這么一篇，轉(zhuǎn)載一下。
有人在Quora問了這個問題：What startup could make me a millionaire in four years if I got hired as an emplyee today？
Symbolic Analytics的創(chuàng)始人Brandon Smietana在下面做了很長的回答，內(nèi)容很精彩，不過請勿對號入座：
大多數(shù)創(chuàng)業(yè)公司的退出（exit)，都是通過M&A（并購），而不是通過IPO(首次公開募股），現(xiàn)在大多數(shù)的M&A價格都低于3000萬美元，最典型的價格是1500萬美元，現(xiàn)在我們來假設(shè)一個最樂觀的退出案例，從其中的數(shù)據(jù)中算出，我作為創(chuàng)始人和CEO，能夠拿多少錢；從而計算出，你，作為一個員工可能賺得的利益。
（一）
假定案例
1）我拿到1000萬的投資。
2）投資人擁有公司50%的股權(quán)（樂觀估計）。
3）我將公司以3000萬的價格出售。
4）我擁有30%的外流通股（Outstanding Share) ，非常樂觀的估計。
投資人還擁有優(yōu)先股，通過并購，他們首先把自己投入的錢收回來，然后再參與省下的股權(quán)收益分紅。
1）在3000萬的退出中，投資人首先拿回他們投入的1000萬，剩下2000萬。
2）然后，優(yōu)先股股東吃掉省下2000萬的50%的利益分紅，于是他們拿走另外1000萬。
3）現(xiàn)在，整個脫售的現(xiàn)金只剩下1000萬，分享這份利益的關(guān)系者包括大眾股東，公司員工，創(chuàng)始人和管理團(tuán)隊。
我，作為創(chuàng)始人和CEO，享有最多的普通股股權(quán)，價值這1000萬美元的大概600萬。省下的400萬利益歸屬其他所有的普通股股東（包括所有的公司員工）
最典型的早期員工，在利益分紅中能拿到的資產(chǎn)不足CEO的1/30，因此，一位非常重要的早期員工，能夠從脫售中取得20萬美元的利益。
現(xiàn)在，讓我設(shè)想得不那么樂觀，相對實際一點(diǎn)。70%進(jìn)入A輪融資的創(chuàng)業(yè)者，除了工資，其他什么利益都無法從公司獲得。因此作為一名員工，
1）有70%的可能，如果你在A輪融資的時候加入創(chuàng)業(yè)公司，你的普通股是沒有價值的。
2）與A輪以前的早期員工相比，A輪以后的員工通過股權(quán)或者期權(quán)能拿到的利益要少很多。
3）在A輪融資以后，新員工能夠拿到的最好的股權(quán)大概在0.3%左右。
4）無論什么樣的員工，他們的股權(quán)都會在管理層更換或者新一輪融資中被稀釋。
（二）
如果我進(jìn)入的公司是”下一個Facebook”呢？
硅谷在過去的十年里發(fā)生了驚天動地的變化。這些變化，同時作用并且影響著IT員工們能從公司那里獲取的利益。
如果你在1998年以前（包含1998年）加入了一家在將來很成功的創(chuàng)業(yè)公司，那你一定已經(jīng)賺了很多錢。但是，如果你加入的是Facebook，你所能獲取的利益價值可能就無法跟前者媲美了。那么，那些加入“下一個Facebook“的哥們兒，希望可能就更小了，以下是原因：
谷歌的早期員工在加入時，谷歌的估值還很低。
1）谷歌的估值，一路從4000萬漲到了2000億。
2）那些最早加入谷歌的清潔工，從谷歌獲得價值1000美元的股權(quán)，在2008年也價值400萬美元。
3）一個獲得了5萬美元股權(quán)的工程師，他的股權(quán)在2008年價值1億美元。
4）谷歌的大廚也獲得了價值2800萬的股權(quán)。
有四點(diǎn)原因說明，谷歌的員工為何能夠金融上收益如此好：
1）他們在公司處于很低估值的時候獲得股票期權(quán)。
2）從A輪融資到現(xiàn)在，谷歌的估值漲了4000倍。
3）公司員工以人為的超低協(xié)議價格獲得購買期權(quán)（大概只相當(dāng)于每股股價的1/10還要低），因為當(dāng)時IRS(美國國稅局）的409（a)條款還不存在呢。
4）由于協(xié)議價格足夠低，因此員工在行權(quán)時，繳納的是資本利得稅15%（Capital Gain Tax），而不是收入稅50%（Income Tax treatment)。
當(dāng)谷歌發(fā)行股票給他的員工時：
1）公司處于低估值階段，而非后來的頂峰估值階段。
2）那時，美國國稅局還沒有執(zhí)行409(a)條款，409（a)條款明確規(guī)定了員工期權(quán)的估值。
在十年以前，創(chuàng)業(yè)公司都會以低于估值的協(xié)議價格發(fā)給員工期權(quán)，以吸引有識之士。員工因此有可能通過公司IPO而一夜致富，他們行權(quán)的協(xié)議價格大概之相當(dāng)于估值價的1/10。
而到今天，這么做就是不合法的了。現(xiàn)在，公司的主管們，依據(jù)83（b)條款，依然有權(quán)通過限制性股票（restricted stock)獲得低估股票（undervalued stock)；但是，現(xiàn)在獲得將理性期權(quán)（Incentive Stock Options)的員工，就必須遵循IRS的的409（a)條款。同時，現(xiàn)在的員工，在行權(quán)時更可能繳納50%的收入稅，而不是15%的資本利得稅。
隨著更高的早期估值，現(xiàn)在的員工已經(jīng)不太有可能有現(xiàn)金能夠行權(quán)，而且也不太有可能繳納資本利得稅，一般都繳納收入稅。409（a）條款通過明確規(guī)定，也防止了員工行權(quán)價像十年前那么低。現(xiàn)在，一個創(chuàng)業(yè)公司的員工，如果行使價值200萬美元的ISO期權(quán)（國際標(biāo)準(zhǔn)期權(quán)），在繳納了加州稅或者德州稅之后，仍然可能面臨50%的收入稅。
一般情況下：創(chuàng)始人和主管們獲得的是依據(jù)83（b)條款的限制性股票（Restricted Stock),并且繳納的是15%的資本利得稅，員工則更可能時取得福利期權(quán)（Incentive Options), 稅率相對更高。
因此，作為一名員工，即便有一天你的公司被賣了，你也可能要繳納50%的收入稅。
200萬瞬間就只剩100萬，而現(xiàn)在，舊金山的房價是300萬。
（三）創(chuàng)業(yè)公司估值之于員工的影響
以前所有關(guān)于谷歌員工勝出的理由，現(xiàn)在都有可能不復(fù)存在了。
新的創(chuàng)業(yè)公司，如Facebook，獲得很高的早期估值，因此，早期員工能獲得的利益相比以前的創(chuàng)業(yè)公司，就少很多了。
更重要的是，現(xiàn)在只有越來越少的大型IPO，取而代之的是越來越多的小型M&A。
圖片一： 1992年 — 2009年 風(fēng)險投資也IPO和M&A交易的比例
大多數(shù)公司并沒有谷歌和Facebook那樣做得很好。即便在Facebook，也只有一小部分員工積累財富。
Zuckerberg在Facebook的股權(quán)大致相當(dāng)于Facebook所有非主管的員工股權(quán)的總和（24%vs30%).。前50個Facebook的非主管員工所獲得的股權(quán)，差不多相當(dāng)于后面25000個員工的總和。
股權(quán)就是金字塔，越升一級，差俱就越大。
在一個以3000萬被并購的公司退出案例里（見上），一個很成功的M&A退出。公司的CEO也差不多只能賺600萬美元。
（四）創(chuàng)業(yè)領(lǐng)域與員工回報的關(guān)系
有很多創(chuàng)業(yè)公司扎根在大眾互聯(lián)網(wǎng)領(lǐng)域（Customer Internet Space), 但是這個領(lǐng)域的投資回報率也最低。就拿Facebook舉例（最成功的消費(fèi)者互聯(lián)網(wǎng)公司之一），它從每一個月度活躍用戶那里只能產(chǎn)生3美元/年的利益。
很少的大眾互聯(lián)網(wǎng)公司能夠通過廣告獲得盈利，像Ad.ly, Digg, Myspace, Twitter,還有很多其他的公司都很難達(dá)到大規(guī)模盈利，即便是用戶量非常龐大。
一個大眾互聯(lián)網(wǎng)公司，如果每個月的活躍用戶數(shù)有50萬，依照Facebook的盈利推算，一年的盈利也只有150萬美元。因此，不要把大眾互聯(lián)網(wǎng)當(dāng)做救命稻草。
現(xiàn)如今，B2B/SaaS模式，以及生物技術(shù)市場，仍然能夠在市場上攫取上億的資金，但是，很少有人能有能力和經(jīng)驗在這個市場里把公司做起來。但是，在這領(lǐng)域，卻有比大眾互聯(lián)網(wǎng)市場更多的盈利機(jī)會。
最有盈利空間的市場，最難發(fā)現(xiàn)創(chuàng)業(yè)公司。特別是，金融領(lǐng)域每年攫取的利潤占全美公司利益的70%，但是，在硅谷卻很難發(fā)現(xiàn)金融創(chuàng)業(yè)公司，即便有，也基本是大眾金融服務(wù)。
Protip: 從數(shù)據(jù)和理論上看，如果你是A輪以后加入大眾互聯(lián)網(wǎng)公司的員工一枚，你的股權(quán)幾乎就不值錢了。
Hadoop最近很火，到處都能看到，查了一下資料大概先了解一下其運(yùn)行原理。
google在05年公開了Map/Reduce論文，MapReduce在處理巨量數(shù)據(jù)方面有明顯優(yōu)勢。
google公司一個技術(shù)大牛jefffery Dean提出的這個算法，隨后很多小牛紛紛實現(xiàn)了Mapreduce,Hadoop是它的java實現(xiàn)，MapReduce概念直接推動了云計算概念的火爆。
沒有優(yōu)秀算法云是沒法搞的。
這篇文章對Map/Reduce原理講的很清楚。
http://www.chinacloud.cn/download/Tech/MapReduceOverview.pdf
這個是Apache關(guān)系Hadoop的文檔，安裝、開發(fā)示例都有。
http://hadoop.apache.org/common/docs/r0.19.2/cn/mapred_tutorial.html
因為一直在做企業(yè)信息化方面的開發(fā)，有必要了解一下相關(guān)的理論。
同事推薦的幾本書。
霍頓(F.W.Horton)的信息資源管理(IRM)理論
威廉。德雷爾的數(shù)據(jù)管理(DA)理論
詹姆斯馬丁的信息工程方法論(IEM)
看了之后有些吃驚，很多概念和理論都是上世紀(jì)80年代，還有60年代就提出的概念，做了這么久的開發(fā)居然沒聽說過，在規(guī)劃方面沒有一定的理論指導(dǎo)，都是些野路子方法。
還有許多平時用到的概念和方法找到了淵源，原來是這哥們或那哥們提出，老外的版權(quán)意識就是強(qiáng)對幾十年前提出的理論都會整理出哪個觀點(diǎn)是哪個人提出的。
不然很多方法一直覺得理所當(dāng)然是那么用的，看過這些資料才知道理論提出的背景，除了這種理論解決哪些問題還有哪些方法，各有什么優(yōu)缺點(diǎn)。
信息工程理論總結(jié)起來，就是以數(shù)據(jù)規(guī)劃為基礎(chǔ)，自定向下規(guī)劃。并提供了一系列的技術(shù)用于自下向上的設(shè)計方法。對企業(yè)信息化中比較重要的業(yè)務(wù)流程有很大的篇幅。
目前的收獲是，1.在系統(tǒng)規(guī)劃方面有了完整的理論指導(dǎo)；2.了解了規(guī)劃、分析、設(shè)計階段會有哪些技術(shù)，哪些已掌握的技術(shù)需要加強(qiáng)、哪些技術(shù)需要學(xué)習(xí)。
老外的書翻譯過來的在中文版看著費(fèi)勁，找了本國內(nèi)編譯出版的，寫得不錯。
信息工程與總體規(guī)劃概述。
本書討論計算機(jī)信息系統(tǒng)總體規(guī)劃的方法論，重點(diǎn)是總體數(shù)據(jù)規(guī)劃。
第一章是本文的綜述，目的是使讀者盡快了解信息工程概念和總體數(shù)據(jù)規(guī)劃方法的大意，因此是全書的提綱。
第二章到第四章是信息工程產(chǎn)生的背景和方法論的分析。這三章按三個主題展開：數(shù)據(jù)處理危機(jī)與轉(zhuǎn)折；信息工程的原理、方法與工具；信息工程與結(jié)構(gòu)化方法。
第五章到第十章比較全面深入地介紹總體數(shù)據(jù)規(guī)劃的一整套方法，是本書的主體。編者根據(jù)近幾年參與中大型企業(yè)計算機(jī)信息系統(tǒng)總體規(guī)劃設(shè)計工作的實踐，深感探討先進(jìn)科學(xué)的方法論的極端重要性，特別是總體數(shù)據(jù)規(guī)劃的內(nèi)容、方法，以及與后續(xù)開發(fā)工作的銜接等問題，更是迫切需要解決的。為此，我們較全面地翻譯介紹了詹姆斯·馬丁所倡導(dǎo)的一整套方法，供有興趣的讀者參考，從而盡快形成適合我國國情的總體規(guī)劃方法論。
第一章
從需求分析開始的傳統(tǒng)生命周期開發(fā)方法論
數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)是相對穩(wěn)定的，而數(shù)據(jù)的處理過程則是經(jīng)常變化的。總體數(shù)據(jù)規(guī)劃方法。
軟件工程僅僅是關(guān)于計算機(jī)軟件的規(guī)范說明、設(shè)計和編制程序的學(xué)科，實際上信息工程的一個組成部分。
信息工程的基本原理和前提是：
1.數(shù)據(jù)位于數(shù)據(jù)處理的中心。
2.數(shù)據(jù)是穩(wěn)定的，處理是多變的。數(shù)據(jù)類型是不變的。
只有建立的穩(wěn)定的數(shù)據(jù)結(jié)構(gòu)，才能是行政管理或者業(yè)務(wù)管理上的變化為計算機(jī)信息系統(tǒng)所適應(yīng)，這正是面向數(shù)據(jù)系統(tǒng)所具有的靈活性，面向過程系統(tǒng)往往不能適應(yīng)管理上的變化需求。
3.用戶必須真正參與開發(fā)工作。Design with,not design for.
第二章
信息工程的組成部分
自定向下規(guī)劃和自下向上設(shè)計方法論
重點(diǎn)分為三個部分：
企業(yè)模型、實體關(guān)系分析和數(shù)據(jù)模型的建立（即主題數(shù)據(jù)庫的規(guī)劃），以及數(shù)據(jù)分布規(guī)劃。
總體數(shù)據(jù)規(guī)劃簡介
四類數(shù)據(jù)庫環(huán)境
1.數(shù)據(jù)文件；
2.應(yīng)用數(shù)據(jù)庫
3.主題數(shù)據(jù)庫
4.信息檢索系統(tǒng)
規(guī)劃方法
1.進(jìn)行業(yè)務(wù)分析建立企業(yè)模型
2.進(jìn)行實體分析建立主題數(shù)據(jù)庫模型
3.進(jìn)行數(shù)據(jù)分布分析
第三章
信息工程概貌
1.關(guān)于全面開放的規(guī)劃
2.關(guān)于業(yè)務(wù)分析
3.關(guān)于數(shù)據(jù)分析，數(shù)據(jù)可以表達(dá)成與使用無關(guān)
4.關(guān)于自動化工具
信息工程的基本組成
1.企業(yè)模型，企業(yè)模型的開發(fā)是在戰(zhàn)略數(shù)據(jù)規(guī)劃期間進(jìn)行的。
2.借助實體關(guān)系分析，建立信息資源規(guī)劃。這是自頂向下的數(shù)據(jù)類型分析，這些數(shù)據(jù)是必須被保存起來的，還要分析他們之間是如何聯(lián)系的。
3.數(shù)據(jù)模型的建立，產(chǎn)生詳細(xì)的數(shù)據(jù)庫邏輯設(shè)計
導(dǎo)致信息工程產(chǎn)生的一個重要認(rèn)識，是組織中存在的數(shù)據(jù)可以描述成與這些數(shù)據(jù)如何使用無關(guān)的形式，而且數(shù)據(jù)需要建立起一定的結(jié)構(gòu)。這一點(diǎn)較面向?qū)ο蟮乃枷牒芙咏梢园褦?shù)據(jù)模型任務(wù)是數(shù)據(jù)對象。
信息工程的建設(shè)基礎(chǔ)
戰(zhàn)略的數(shù)據(jù)規(guī)劃工作
信息工程方法論
1.關(guān)于企業(yè)信息化戰(zhàn)略規(guī)劃的方法
2.關(guān)于信息系統(tǒng)設(shè)計實現(xiàn)的方法
3.關(guān)于自動化開發(fā)工具
第四章結(jié)構(gòu)化方法與信息工程
信息工程是在進(jìn)行戰(zhàn)略需求規(guī)劃，信息需求規(guī)劃，總體數(shù)據(jù)規(guī)劃和數(shù)據(jù)分布規(guī)劃的基礎(chǔ)上，使用結(jié)構(gòu)化設(shè)計和結(jié)構(gòu)化編程的方法。
結(jié)構(gòu)化系統(tǒng)分析
數(shù)據(jù)流圖
結(jié)構(gòu)化系統(tǒng)設(shè)計
信息工程是面向數(shù)據(jù)的方法，結(jié)構(gòu)化方法是面向過程的方法。前者可以使用未來，后者只能使用過去和現(xiàn)在。
戰(zhàn)略需求規(guī)劃
戰(zhàn)略需求規(guī)劃是信息工程的基礎(chǔ)工作，不僅要對現(xiàn)有需求規(guī)劃，還要對未來需求規(guī)劃。
1.加強(qiáng)用戶之間的溝通合作。
2.加強(qiáng)高層領(lǐng)導(dǎo)者之間的溝通并為之提供支持。
3.提高資源需求預(yù)測和分配的準(zhǔn)確性。
4.提供內(nèi)部mis的可行點(diǎn)。
5.提出新穎而高質(zhì)量的應(yīng)用系統(tǒng)。
信息需求規(guī)劃
信息需求：
1.事務(wù)處理工作的管理信息需求；
2.高層領(lǐng)導(dǎo)者的管理信息需求；
3.企業(yè)發(fā)展和改革發(fā)展方面的信息需求；
傳統(tǒng)的軟件工程和數(shù)據(jù)庫技術(shù)盡管有分析設(shè)計方法，但缺乏自頂向下的規(guī)劃，不能適應(yīng)大型復(fù)雜系統(tǒng)的建設(shè)。信息工程強(qiáng)調(diào)總體規(guī)劃，形成了一套自頂向下規(guī)劃與自下向上設(shè)計的完成的方法學(xué)，為大型復(fù)雜系統(tǒng)的建設(shè)提供了保障。
第五章總體數(shù)據(jù)規(guī)劃的組織
戰(zhàn)略規(guī)劃
1.戰(zhàn)略業(yè)務(wù)規(guī)劃
2.戰(zhàn)略信息技術(shù)規(guī)劃
3.戰(zhàn)略數(shù)據(jù)規(guī)劃
戰(zhàn)略數(shù)據(jù)規(guī)劃，即總體數(shù)據(jù)規(guī)劃是信息工程規(guī)劃工作的核心和基礎(chǔ)，需要研究它的組織方法。
戰(zhàn)略規(guī)劃的目的是使信息系統(tǒng)的各部分能共同工作。
對戰(zhàn)略規(guī)劃的詳細(xì)程度要有恰當(dāng)?shù)睦斫狻?br />
第六章 企業(yè)模型
..........................
今天看了五章的內(nèi)容，休息一下。
忙完手頭工作繼續(xù)學(xué)習(xí)，2012-2-28
總體數(shù)據(jù)規(guī)劃的第一步是進(jìn)行業(yè)務(wù)分析，建立企業(yè)模型。(編者按：目前電信行業(yè)都已經(jīng)建立起了完善的企業(yè)模型，其他行業(yè)還沒看到)
企業(yè)模型是對企業(yè)結(jié)構(gòu)和業(yè)務(wù)活動 本質(zhì)的、概況的認(rèn)識。
用職能區(qū)域--業(yè)務(wù)過程--業(yè)務(wù)活動 這樣的層次結(jié)構(gòu)來描述。
1.研制一個表示企業(yè)各職能區(qū)域的模型；
2.擴(kuò)展上述模型，使它能表現(xiàn)企業(yè)的各項業(yè)務(wù)過程；
3.繼續(xù)擴(kuò)展上述模型，使它能夠表現(xiàn)企業(yè)的各項業(yè)務(wù)活動。
依靠企業(yè)高層，分析企業(yè)的現(xiàn)行業(yè)務(wù)和長遠(yuǎn)目標(biāo)，按照企業(yè)內(nèi)部的各種業(yè)務(wù)的邏輯關(guān)系，將他們劃分為不同的只能區(qū)域，弄清各職能區(qū)域包括的全部業(yè)務(wù)過程，再將各個業(yè)務(wù)過程細(xì)分為一些業(yè)務(wù)活動。
建立分析企業(yè)模型的過程，是對現(xiàn)行業(yè)務(wù)系統(tǒng)再認(rèn)識的過程。
職能區(qū)域
職能范圍、業(yè)務(wù)范圍，是指一些主要的業(yè)務(wù)活動區(qū)域，如銷售、市場、財務(wù)、認(rèn)識、生產(chǎn)。
職能模型，職能區(qū)域圖表
業(yè)務(wù)過程
企業(yè)模型的二級結(jié)構(gòu)是業(yè)務(wù)過程的識別、命名、定義。這項工作主要由分析人員來完成。
1.業(yè)務(wù)過程與組織結(jié)構(gòu)
2.識別業(yè)務(wù)過程的參考模式
產(chǎn)品、服務(wù)和資源四階段生命周期
計劃，獲得，保管，處置(編者按：原書有一張圖表，這里就不列出來了)，模式的每一階段都有一些業(yè)務(wù)過程的類型。
3.業(yè)務(wù)過程與負(fù)責(zé)人
4.經(jīng)驗
業(yè)務(wù)活動
每個業(yè)務(wù)過程中都存在一定數(shù)量的業(yè)務(wù)活動
業(yè)務(wù)活動分析
1.功能分解的程度
2.凝聚性活動，1.產(chǎn)生清晰可識別的結(jié)果，2.有清楚的邊界，3.是一個執(zhí)行單元，4.自封閉的，獨(dú)立于其他活動。
3.冗余活動和功能組合，
企業(yè)模型的建立過程
可以理解為邏輯模型
企業(yè)模型的特點(diǎn)
完整性、適用性、永久性
關(guān)鍵成功因素
3~6個決定成功與否的因素
1.關(guān)鍵成功因素的確定
關(guān)鍵成功因素應(yīng)該成為最高層管理人員管理控制企業(yè)系統(tǒng)的基礎(chǔ)，對一個行業(yè)來講關(guān)鍵成功因素差不多是相同的。
如食品公司：廣告效果，貨物分發(fā)，產(chǎn)品革新
2.關(guān)鍵成功因素的審查
第七章主題數(shù)據(jù)庫
獨(dú)立于應(yīng)用的數(shù)據(jù)
數(shù)據(jù)庫環(huán)境的原則
1.企業(yè)的數(shù)據(jù)應(yīng)該得到直接管理，與使用的職能分開；
2.數(shù)據(jù)描述不應(yīng)由使用數(shù)據(jù)的應(yīng)用包含，而應(yīng)當(dāng)由獨(dú)立的數(shù)據(jù)管理員設(shè)計；
3.數(shù)據(jù)應(yīng)該獨(dú)立于現(xiàn)有機(jī)器資源；
4.使用統(tǒng)一的工具和設(shè)施管理資源；
5.有適當(dāng)?shù)陌踩捅Ｃ芸刂疲?br />6.高層管理人員要參與數(shù)據(jù)庫的總體規(guī)劃和決策。
面向過程的系統(tǒng)分析方法
面向數(shù)據(jù)的系統(tǒng)分析方法
主題數(shù)據(jù)庫與組織內(nèi)各類人、事、物相關(guān)，而不是與傳統(tǒng)的應(yīng)用相關(guān)。
總的來說這部分沒什么干貨，就是對前面方法論的細(xì)化和再次說明。
這本書側(cè)重于方法論和理論概念。在規(guī)劃部分有具體的指導(dǎo)，在具體分析和設(shè)計技術(shù)上著墨不多。
第八章實體活動分析
第九章數(shù)據(jù)分布規(guī)劃
第十章規(guī)劃與開發(fā)建議
這兩天比較忙，后邊章先顧不上看了。
第八章和第九章應(yīng)該跟軟件工程里的內(nèi)容是一致的，原來項目開發(fā)時經(jīng)常要用到。第十章討論BSP方法，要了解一下。
因為項目需要做了一個簡單的工作流引擎，用于集成訂單管理(IOM)的生產(chǎn)調(diào)度。之前的文章有提到。原想著有這樣一個引擎來進(jìn)行生產(chǎn)調(diào)度，設(shè)計好業(yè)務(wù)流程后就可以面朝大海，春暖花開。在還生產(chǎn)系統(tǒng)對接的時候發(fā)現(xiàn)有一部分還是人工處理更好，畢竟不是所有的流程都能那么細(xì)致合理。
下面是我們的解決方案，圖片是從wps里另存出來的，不知道咋就變成黑底了。
1.1 問題描述
工作流引擎處理流程調(diào)度部分的內(nèi)容。客戶下訂單之后，協(xié)調(diào)各生產(chǎn)部門進(jìn)行工作。
最理想化的情況是對客戶發(fā)起的每一種操作都定義一組流程，在流程執(zhí)行的過程中每種狀下態(tài)當(dāng)有新的操作進(jìn)來也相應(yīng)定義一組流程，但這樣一來流程設(shè)計工作極其繁瑣，容易出錯，不利于降低管理難度減輕管理工作量。
一個折中的方案是對執(zhí)行中的流程進(jìn)行流程合并。選擇對一部分操作不創(chuàng)建新流程，給用戶提示信息，由用戶覺得如何進(jìn)行手工操作。
1.2 問題分析
1.2.1 概念定義
生產(chǎn)平臺：生產(chǎn)平臺是由人和機(jī)器構(gòu)成的,能將一定輸入轉(zhuǎn)化為特定輸出的有機(jī)整體。對應(yīng)于工廠中的生產(chǎn)車間概念。
生產(chǎn)線：生產(chǎn)是與相關(guān)的一個部門或一組操作對應(yīng)的組織。類似于項目組的概念，是依據(jù)生產(chǎn)流程對生產(chǎn)能力的一種劃分方式。
產(chǎn)品：產(chǎn)品是指中企動力運(yùn)用營銷手段，將業(yè)務(wù)或業(yè)務(wù)組合附加上銷售對象、銷售地域、資費(fèi)計劃、銷售渠道、服務(wù)水平及配套資源屬性后的產(chǎn)物，是向客戶最終交付的、客戶可以購買的產(chǎn)品單元組合實例。
產(chǎn)品單元：產(chǎn)品單元是業(yè)務(wù)在生產(chǎn)系統(tǒng)的具體表現(xiàn)。
產(chǎn)品單元與生產(chǎn)線之間是多對多的關(guān)系。如果一個產(chǎn)品單元需要跨多個生產(chǎn)線，引擎需要調(diào)度產(chǎn)品單元在不同生產(chǎn)線的生產(chǎn)過程。
流程組：流程組指由一系列操作流程組成的流程集合，有流程間的先后順序。流程組在此是由產(chǎn)品和操作類型共同決定的。
流程：流程是一系列操作環(huán)節(jié)的集合。環(huán)節(jié)間有并行和串行的關(guān)系。流程在此處是由平臺和操作類型決定的。
環(huán)節(jié)：環(huán)節(jié)是一系列操作的集合。環(huán)節(jié)此處定義是由一個人的一個或多個可并行的操作決定的。
任務(wù)：任務(wù)是可執(zhí)行的最小單位。任務(wù)具有原子性，是環(huán)節(jié)的組成部分。一般一個任務(wù)完成一個事務(wù)。
一個環(huán)節(jié)包含多個任務(wù)，一個流程包含多個環(huán)節(jié)，一個流程組包含多個流程。
1.2.2 問題描述
以一件定制服裝的過程為例，只是為了說明問題對流程做了簡化。見下圖。
定制服裝生產(chǎn)流程：
最簡化的情況，客戶在提交了定制服裝生產(chǎn)的要求后便不再干預(yù)，生產(chǎn)線就按流程走就可以了。
但是客戶可能會在生產(chǎn)的各個環(huán)節(jié)提出變更要求，已經(jīng)制作完成了客戶要求加個兜，已經(jīng)質(zhì)檢完成了客戶要求加個紐扣，已經(jīng)包裝好了客戶要求領(lǐng)子樣式改改。
如果把每一種可能都定義一組流程，就這個簡化流程全部列出來也夠貼一面墻了。所以我們采取了一種折中的方案，在大多數(shù)情況下正在生產(chǎn)時客戶要求有變化，通過一個描述性的工單告訴生產(chǎn)線負(fù)責(zé)人暫停生產(chǎn)、并由負(fù)責(zé)人來決定回退到那個環(huán)節(jié)重新進(jìn)行。
如果都包裝好了客戶還要改，那就暫停當(dāng)前流程，走和客戶打官司的流程了，這種情況下需要一個流程。
本方案通過對生產(chǎn)中的流程進(jìn)行合并，減少流程定義的工作量和復(fù)雜程性度。
1.3 問題解決
1.3.1 工單
1.3.1.1 邏輯模型
訂單生成工單的過程，稱為合單。
|
訂單工單關(guān)系 |
工單屬性 |
|
|
|
現(xiàn)在所描述的都是對同一個訂購實例所下各種訂單的合單處理情況。
1.訂購實例第一次下訂單，根據(jù)訂單生成工單和工單明細(xì)。
2.訂購實例第二次下訂單
a) 之前生成的工單已經(jīng)竣工，生成新工單和新工單明細(xì)。
b) 之前生成的工單還未生產(chǎn)，廢棄該工單，生成新工單和新工單明細(xì)
c) 之前生成的工單生產(chǎn)中，廢棄該工單，繼續(xù)沿用原工單編號，合并生成新工單和新工單明細(xì)。新工單狀態(tài)為生產(chǎn)中。
在工單明細(xì)表增加字段“產(chǎn)品單元變更標(biāo)識”，如果產(chǎn)品單元對應(yīng)的屬性內(nèi)容在兩次訂單中沒有變化，引擎不暫定產(chǎn)品單元觸發(fā)的流程。
1.3.2 流程實例化
1.3.2.1 邏輯模型
流程定義模型見下圖，概念定義部分對名詞有描述。
|
流程定義 |
流程實例化 |
|
|
|
在業(yè)務(wù)支撐系統(tǒng)經(jīng)常使用的一個概念，實例化。
用戶購買一個產(chǎn)品后，就產(chǎn)生一個產(chǎn)品的實例化，區(qū)別于別的客戶購買的同類產(chǎn)品，稱為訂購實例。
定義一組流程用來處理產(chǎn)品生產(chǎn)過程，具體到某個訂購實例的生產(chǎn)過程的實例化，就有了流程組實例、流程實例、環(huán)節(jié)實例和任務(wù)實例。
1.3.2.2 流程定義過程
有了流程定義的模型，我們就是可以設(shè)計或者叫定義產(chǎn)品的生產(chǎn)流程。
完成一件復(fù)雜的工作，總是需要一個步驟一個步驟的完成，每個步驟稱為一個環(huán)節(jié)，在這個環(huán)節(jié)下可能需要做幾個事情，每個要做的事情稱為一個任務(wù)。
1.根據(jù)生產(chǎn)部門劃分生產(chǎn)線
2.根據(jù)生產(chǎn)線+操作，定義流程，把流程中的任務(wù)根據(jù)負(fù)責(zé)人劃分為不同的環(huán)節(jié)。
3.按照產(chǎn)品涉及的流程劃分為不同的流程組。
1.3.2.3 流程實例化
1.實例化約束
a) 一個訂購實例當(dāng)前只有一個運(yùn)行中的流程組實例；
b) 流程合并前先暫停，避免和引擎并發(fā)競爭。
2.實例化過程
a) 接收工單，檢查訂購實例當(dāng)前是否有流程組實例在運(yùn)行中；
i. 無，實例化一個新的流程組實例
ii. 檢查是否屬于同一個流程組定義
1. 是同一個流程組，進(jìn)行流程合并。
2. 不是同一個流程組，暫不實例化，待下一次輪詢再處理。
流程合并細(xì)節(jié)見《流程合并詳細(xì)設(shè)計》
1.3.3 流程引擎
1.3.3.1 模型狀態(tài)
1.已實例化
2.已分配(負(fù)責(zé)人)
3.執(zhí)行中
4.暫停
5.已完成
流程啟動后按順序執(zhí)行，當(dāng)要回到上一步驟時，監(jiān)控頁面支持回退和回滾兩種操作。
回退，當(dāng)前執(zhí)行中/暫停的環(huán)節(jié)設(shè)置為已分配，上一環(huán)節(jié)由已完成設(shè)置為執(zhí)行中。
回滾，對任務(wù)可以執(zhí)行其反任務(wù)。
1.3.3.2 功能描述
1.引擎輪詢程序，檢查處于執(zhí)行中狀態(tài)的環(huán)節(jié)，如果環(huán)節(jié)下所有關(guān)鍵任務(wù)都已完成則環(huán)節(jié)進(jìn)入已完成狀態(tài)，下一環(huán)節(jié)進(jìn)入執(zhí)行中狀態(tài)。
2.環(huán)節(jié)實例化后處于已實例化狀態(tài)，用戶在任務(wù)分配頁面指定環(huán)節(jié)負(fù)責(zé)人，環(huán)節(jié)處于已分配狀態(tài)，上一環(huán)節(jié)完成后由引擎設(shè)置本環(huán)節(jié)進(jìn)入執(zhí)行中狀態(tài)。
3.鑒于引擎對執(zhí)行中的環(huán)節(jié)進(jìn)行調(diào)度工作，實例化程序和頁面監(jiān)控程序在對執(zhí)行中的環(huán)節(jié)操作時，需先暫停環(huán)節(jié)。
4.監(jiān)控頁面支持對流程、環(huán)節(jié)的回退，支持對任務(wù)的回滾。
之前做了一個簡單的工作流引擎，干完了活做點(diǎn)理論總結(jié)。
項目見
工作流應(yīng)用---理論基礎(chǔ)篇、
工作流應(yīng)用---概念、模型這個工作流引擎主要是根據(jù)項目需求和網(wǎng)上看到的一些文章提到的概念做出來的，估計比較野路子，想著把概念和名詞向大師靠攏。
過了年剛來不忙，這幾天抽空看了兩本工作流方面的書，《工作流管理技術(shù)基礎(chǔ)》和《工作流管理：模型、方法和系統(tǒng)》，講的比較細(xì)致、對基礎(chǔ)概念講的很清楚，就是書老了點(diǎn)。
書中對XPDL標(biāo)準(zhǔn)做了詳細(xì)描述，對新出的BPEL沒有涉及。
我自己項目中用到的概念和大師們基本一致，大方向不錯，看來網(wǎng)上找到的那幾篇文章挺靠譜的，當(dāng)時應(yīng)該隨手整理出來。
工作流引擎做的比較簡單，沒有使用主流的petri技術(shù)，只支持項目需求更負(fù)責(zé)的需求就夠嗆了，回頭有空再改一版。看了書才發(fā)現(xiàn)有這么多種模型實現(xiàn)方法早都有人研究很多年了。
這兩本書在超星網(wǎng)站都能找到電子版。
IPO模型，過程中的每一個活動都由輸入(I)、處理(P)、輸出(O)三部分組成。
理論來自《科學(xué)管理》提出的科學(xué)管理原則：
一個組織的工作可以描述為一系列的任務(wù)，每個任務(wù)都是工人們具體、嚴(yán)謹(jǐn)?shù)幕顒舆^程，管理就是在一定的計劃下讓這些任務(wù)以最優(yōu)的方式進(jìn)行。
常用的工作流模型：
1.基于活動網(wǎng)絡(luò)的過程模型
組成模型的元素包括過程、活動、模塊、控制連接弧、數(shù)據(jù)連接弧和條件。
以活動作為構(gòu)成過程的基本單元，以連接弧體現(xiàn)過程邏輯，可以靈活的實現(xiàn)企業(yè)經(jīng)營過程的建模，我做的那個基本上采用的就是這種模型。
過程：為完成目標(biāo)而定義的一系列步驟；
活動：過程中的步驟；
模塊：跟過程的概念類似；區(qū)別在于是否可以多次重復(fù)使用
控制鏈接弧：定義兩個活動間的執(zhí)行順序
數(shù)據(jù)連接弧：定義兩個活動間的信息流
條件：定義過程執(zhí)行中的約束
定義在控制連接弧上的條件：轉(zhuǎn)移條件
活動可以執(zhí)行和活動被執(zhí)行：開始條件、結(jié)束條件。
優(yōu)點(diǎn)：
從系統(tǒng)分析的角度來看，有利于通過過程模型提取功能視圖和信息視圖、便于深入分析
從系統(tǒng)實現(xiàn)的角度來看，控制流管理和數(shù)據(jù)流管理分離，是不同性質(zhì)的流管理獨(dú)立。
2.事件驅(qū)動的過程鏈模型
兼顧模型描述能力強(qiáng)和模型易讀兩個方面。
業(yè)務(wù)事件、業(yè)務(wù)功能、控制流、邏輯操作符、信息對象、組織單元
3.基于語言行為理論的工作流模型
IPO模型對于觀察信息和物流的流動過程比較合適，但不利于不同角色間的委托和承擔(dān)行為。
語言行為理論則側(cè)重與解決，數(shù)據(jù)、物、人協(xié)作中IPO模型對人直接協(xié)作描述不足的情況。
聽上去不錯，實際中沒有看到用這種模型的，google了一下相關(guān)資料，還只是一個理論在軟件領(lǐng)域用來進(jìn)行協(xié)作過程建模的很少。
簡單了解一下先，等大師們研究明白了咱再學(xué)習(xí)。
4.基于petri網(wǎng)的工作流模型
這個東西看著挺復(fù)雜的，不過好多人都說是好東西，研究一下先。
找了兩本有關(guān)petri的書，都太理論化看不懂。還是《工作流管理：模型、方法和系統(tǒng)》講得比較通俗。
petri基本概念很好理解，不同于過程化分析，更接近面向?qū)ο蟮乃枷搿？雌饋砦以谶@個項目中采用的分析方法更接近與petri，原來俺們樸素的想法跟大師很接近哦。
一般的面向?qū)ο蠓治龈鼈?cè)重與靜態(tài)結(jié)構(gòu)，在動態(tài)模型部分描述的都不夠清楚。petri在動態(tài)過程方面感覺很細(xì)致有效。據(jù)說還是經(jīng)過嚴(yán)格熟悉驗證的分析方法，不過那些公式?jīng)]看懂，太費(fèi)勁。分析時用petri分析建模方法就可以了。
.....
上一篇講了工作流的主要概念和用途。
知道了要依靠工作流引擎來推動流程向前。
這一篇講一個具體實現(xiàn)的例子,比較簡單，對于復(fù)雜的流程關(guān)系定義處理不了，上下文參數(shù)構(gòu)建也不支持，這些依賴具體的業(yè)務(wù)領(lǐng)域模型處理了。
好在工作流基本的概念是有了，對于復(fù)雜的應(yīng)用可以借鑒成熟的產(chǎn)品，知道工作流是怎么回事了其他產(chǎn)品也就容易上手了。
工作流概念這一塊，目前也沒個統(tǒng)一規(guī)范，就自己搞了一套，沒采用那些推薦標(biāo)準(zhǔn)太復(fù)雜用不上。
要開發(fā)一個工作流引擎出來，跟其他開發(fā)沒有不同，概念、需求、建模。
一、搞清楚都要用到哪些概念
二、能夠提供哪些功能、準(zhǔn)備用例
三、建模
1.靜態(tài)模型
依據(jù)關(guān)鍵流程的用例推導(dǎo)概念、明確概念定義、支持概念所要用到的數(shù)據(jù)結(jié)構(gòu)
2.動態(tài)模型
定義各功能模塊操作，并檢查是否覆蓋所有關(guān)鍵用例。
實際例子，懶得敲那么多字了，直接上圖
1.用例,用來確定系統(tǒng)邊界
2.主要概念，及概念見關(guān)系
3.流程生命周期定義
說明一下，分配狀態(tài)和運(yùn)行狀態(tài)是兩個維度的東西，為了省事就定義在一起了。
4.系統(tǒng)架構(gòu)
描述引擎的內(nèi)部構(gòu)成、引擎與外圍系統(tǒng)的關(guān)系。
這段時間因為項目需要做了一小的工作流引擎，總結(jié)一下經(jīng)驗。
大概會分為這么幾個階段來介紹。
1.理論基礎(chǔ)
2.實現(xiàn)技術(shù)
3.實際開發(fā)的一個例子。
如圖:
一、理論基礎(chǔ)
只是簡單的討論原理，詳細(xì)數(shù)學(xué)理論不再這里討論，會在附錄里列出來，有興趣的同學(xué)自行查看。
1.概念
為了實現(xiàn)業(yè)務(wù)過程自動化提出的概念。
以前去政府部門辦過事大家都有體會，那個迷茫啊困惑啊，很多連個辦事指南都沒有。
辦一件小事要蓋十幾個章，材料交上去后你根本不知道現(xiàn)在到了哪個部門，審核通過了沒人通知你，沒通過的話少什么資料也不告訴你，告訴你也不是一次都說，跑一趟說一點(diǎn)。通過了這個部門審核下一步應(yīng)該去哪也沒人告訴你。
這個時候有個對機(jī)關(guān)門清的人，知道哪里水深水淺，領(lǐng)著你辦下來該有多好，該請客請客該送禮送禮，少跑很多冤枉路，還能隨時查詢狀態(tài)。
這就是工作流引擎要做的事情。
2.發(fā)展歷史
工作流技術(shù)起源于二十世紀(jì)七十年代中期辦公自動化領(lǐng)域的研究，由于當(dāng)時計算機(jī)尚未普及，網(wǎng)絡(luò)技術(shù)水平還很低以及理論基礎(chǔ)匱乏，這項新技術(shù)并未取得成功。
老外也是被扯皮扯怕了試圖改進(jìn)。
3.作用目標(biāo)
工作流將作為一個公共基礎(chǔ)子系統(tǒng)服務(wù)于整個平臺產(chǎn)品的人力工作流和業(yè)務(wù)工作流環(huán)節(jié)。
通過將工作活動分解成定義良好的任務(wù)、角色、規(guī)則和過程來進(jìn)行執(zhí)行和監(jiān)控，達(dá)到提高生產(chǎn)組織水平和工作效率的目的。
人多了事情多了，扯皮的情況也就多了。為了避免扯皮建立一個協(xié)調(diào)中心，提供辦事指南，負(fù)責(zé)進(jìn)度管理，公共信息維護(hù)。
處理這種有復(fù)雜流程的事情目前有兩種解決思路:
1.針對業(yè)務(wù)領(lǐng)域開發(fā)一個系統(tǒng)，一個模塊處理完成一件事件后根據(jù)情況來決定下一步跳到哪個模塊，帶點(diǎn)什么參數(shù)。適應(yīng)于流程比較固定的業(yè)務(wù)，像財務(wù)系統(tǒng)雖然很復(fù)雜，但是各種處理規(guī)則都清清楚楚明明白白，也不會隨便變動。
2.工作流方式，講流程跳轉(zhuǎn)規(guī)則由工作流引擎統(tǒng)一維護(hù)，每個具體執(zhí)行任務(wù)的模塊只管干自己的活，干完了告訴一聲引擎，由引擎通知下一個模塊。目前只能處理相對簡單的一些工作流程，OA公文流轉(zhuǎn)，IOM生產(chǎn)系統(tǒng)調(diào)度這類規(guī)則不是很復(fù)雜，流程上下文較簡單的情況。
對于特別復(fù)雜的流程，開發(fā)量反而比定制業(yè)務(wù)系統(tǒng)還要多。工作流理論需要再有一次提升才能解決這個問題。
4.體系特點(diǎn)
可維護(hù)性和可擴(kuò)展性
與業(yè)務(wù)系統(tǒng)實際關(guān)聯(lián)低偶合
可以擴(kuò)充表達(dá)式引擎，與界面綁定由界面引擎決定
可以適應(yīng)與審核等人力流程，也可以適用在無人干預(yù)的商業(yè)自動化流程
安全性
易用性
5.模型表示
用例模型
應(yīng)用用例
擴(kuò)展用例
分析模型
架構(gòu)性重要分析元素
架構(gòu)性重要用例實現(xiàn)
設(shè)計模型
組件結(jié)構(gòu)
部署結(jié)構(gòu)
6.定義語言
7.參考資料
這幾天抽空把How tomcat works看了一遍。
這本書寫得很好，把tomcat這么一個牛B的大家伙拆成一堆零件，然后告訴你怎么組裝，真是做到了掰開了揉碎了講。
簡單記一下
第一章講web服務(wù)器，如何接受和響應(yīng)http請求，還舉了個sokcet的例子。算是入門，從很底層的技術(shù)講起。
第二章講servlet容器，javax.servlet.Servle接口，接受到http請求后如何查找servlet,執(zhí)行servlet。
第三章講連接器的概念，前兩章看下來你會覺得把http請求接受響應(yīng)跟容器放在一起太亂了，這章就講如何把http操作提出來作為一個連接器。
第四章講tomcat默認(rèn)連接器，http協(xié)議操作講得很詳細(xì)，不過我沒怎么看哈，用的時候直接把tomcat這段代碼拿過來就是了。
第五章講容器，在第三章的基礎(chǔ)上對容器進(jìn)行分層分類，事情復(fù)雜了就分成幾部分，“治眾如治寡，分?jǐn)?shù)是也”這個我們都知道。
tomcat講容器分成這幾個概念：
Engine：表示整個Catalina的servlet引擎
Host：表示一個擁有數(shù)個上下文的虛擬主機(jī)
Context：表示一個Web應(yīng)用，一個context包含一個或多個wrapper
Wrapper：表示一個獨(dú)立的servlet
類型復(fù)雜了，要做的事情也復(fù)雜了。
不僅僅是執(zhí)行service()方法，還要前邊執(zhí)行一堆，后邊再來一堆。引入了流水線任務(wù)Pipelining Tasks的概念，在流水線上可以執(zhí)行多個Valve（有翻譯成閥），類似于攔截器的概念。
第六章講生命周期，人多了要講究個步調(diào)統(tǒng)一，引入了Lifecycle接口的概念，方法包括啟動之前干什么、啟動之后干什么、啟動后把子容器也啟動了。
包括引入監(jiān)聽接口，都是些java常見實現(xiàn)方式，沒什么特殊。
第七章講日志系統(tǒng)，沒看。
第八章講加載器，可以參考
tomcat類加載器及jar包沖突問題分析 http://m.tkk7.com/zyskm/archive/2011/12/06/365653.html 就不重復(fù)了。
第九章講session管理，沒什么特別的。
第十章講安全，沒看。
第十一章講StandardWrapper，在第五章的基礎(chǔ)上重點(diǎn)分析了wrapper的運(yùn)作機(jī)制。
其余章節(jié)目前工作中用不到，有空再看了。
作者:zyskm
http://m.tkk7.com/zyskm