其他

　　工作流程，在其存在的價值上主要是應對各種任務之間的資訊傳遞，尤其是流程的各種啟動、完成等資訊。考慮到這一個問題上，一個很顯而易見的是工作流程沒有許可權的概念，所謂的許可權，只是在業務處理上出現的資訊控制而已。　　看到各位網友徘徊於研究工作流程組織和許可權問題，感到不得不說，希望讓一些剛對工作流程入門的同行少走彎路。國內懂得這個的朋友都閉帚自珍，不太願意開班授徒，學術風氣之閉塞，實在令人感歎。那也只好讓我這個水平不怎麼樣的，來一個拋磚引玉。1.

　　"前面開車的是個女的"，一眼瞟到這個情況，我便作出了超車的決定。　　路上的車不多，前面幾輛車稀疏的並排，但是中間的空隙似乎不足夠進行大刀闊斧的超車動作。但是我終究還是超了--帶著一點點爭強好勝，一點點年輕人的血氣方剛。　　交通燈就像馬路上的革命者，對車流進行結構重組，對車群進行資源整合--大家又排到了十分相近的起點上。那匹紅色的寶馬又與我齊頭並進了，從車子的效能來看，下一輪我不太可能再超越這個對手，實力相差太遠了，我座駕的價值大概只相當於寶馬的零頭。不得不承認，剛才超車的舉動是虛榮心占的因素

文章目錄 基本配置依賴配置 本文不想討論Maven是什麼、能做什麼、我們選擇Maven有什麼好處……本文只是提出在公司大規模開發環境中使用Maven技術的一個案例、一次實踐、一種思路，供大家借鑒和參考。至於是不是“最佳”？當然不是！因為沒有“最佳”，只有“更佳”:-)POM，不得不說一下對Maven而言，POM（Poject Object，項目對象）檔案就是一個項目的全部，再不需要其他的設定檔來描述項目了！當在 cmd / shell

因為技術選型的需要，瞭解或再次認識了幾個開源的小東西，感覺還是收到了一定啟發效果的，雜談一下吧:-)螞蟻——Ant (another neat tool)使用IDE來完成項目構建不是更方便麼，為什麼還要使用Ant？一般來說，IDE設計初衷都是為了提高程式員的個人生產率，而不是Team

1. 理論模型　　這一個模式實際上是一種相同分支的同構情況　　　　注意，當 A、B 分支到達這個合并結點的時候，並不是合并，而是繼續相同的後續分支。如 A 先完成，那麼就觸發 C1（這裡要區別一下，第一次觸發這個 C 我們稱之為 C1），然後 B 完成後，再觸發C2（第二次觸發的 C 叫 C2）。所以實際上是觸發了兩次 C。按照理論模型來講，及時 A、B 同時完成，仍然觸發兩個 C，但實際中卻不存在同時完成的情況，電腦處理總有先後次序。2.

1. 理論模型　　我覺得這個模型中文名字應該為"自然迴圈"，可能更貼近其實際意圖。　　　　這個模式可以說不是針對直接"套現"的情況，主要是流程設計的過程中自然形成迴圈。而這種在繪製流程圖時候所形成的自然迴圈，沒有明確的迴圈入口或者出口。就如在編寫程式上使用 goto 而形成的迴圈情況。2. 應用　　這個模式從純模型的角度來說，屬於 XOR-join、XOR-split

1. 理論模型　　這一個模式是為了應付Multi-Choice 或者通常意義所說的 OR-Split 所產生的分支。　　　　首先這個分支的合并，需要瞭解內容相關的關係。前面若是只產生了 A 分支，那麼來到這裡只需要 A 分支就可以觸發後軀，B 分支亦然。若是 A、B 分支是並發的，那麼注意標題中"Synchronizing"的字眼，這個合并必須等待 A、B 分支都完成了才能觸發後軀

1. 理論模型　　這個模式叫隱式結束，或者自然結束。就是當所有正在運行結點都沒有後繼結點，流程就視為結束了。2. 應用　　這個模式現在 BPEL、XPDL、BPMN 等流程的標準都支援，就是不需要指明結束的結點，只要跑完所有的結點（或者沒有找到後繼結點），就視為流程結束。　　比較有趣的是基於 Petri nets 的系統對這種模式的支援可能需要點額外的處理。在 Petri nets

在互連網應用，特別是“動態”網站的應用中，隨著網站訪問量的增加，我們總是會發現效能的瓶頸最先來自資料IO，而非CPU、記憶體、網路頻寬……而資料IO瓶頸一般表現在資料庫查詢上。當然我們可以通過使用諸如 Memcache 之類的叢集緩衝方案替資料庫“擋”那麼一下，也可以考慮使用 HBase 之類的NoSQL解決方案分散資料存取。但是最經濟、最快速的辦法莫過於SQL語句最佳化了——幾乎零成本且立杆見影。最佳化一條糟糕的查詢，能輕鬆的提高千百倍的執行效率，而獲得的結果不會有任何不同。說出來也許都知道，

Field的convert配置項是可以自己定義如何顯示field裡的資料。範例如下{ name: 'name'},{ name: 'first name' convert: function(value, record) { var firstName = record.get('name').firstName; return firstName;

1. 總論　　在旁觀者看來，商務程序設計這一概念投影到大腦皮層，大抵就是一張狀態圖，裡面刻畫著各種分工的步驟。其曆史的考究，最早應該是從經濟學的角度觀察到運用這種分工所帶來的生產力激增，然後轉而從管理學的角度來學習並使用這種技術。直到今天有了一個時髦的名字，大抵叫做 Business Process。　　不過這種技術雖然滲透到管理的各個層次，卻仍然無法在管理的理論體系中獨樹一幟。在我的觀察看來，商務程序的學問，實在管理學中的"形而上道"。一個流程的設計，牽涉到戰略、計劃、人員、組織、授權、溝通、

資料分析是一種靠譜的產品研究方法，這玩意有很多誤區，也不能迷信，最終到頭來還是要人來做決策。忽略沉默的使用者二戰時英國空軍為了降低飛機的損失，決定給飛機的機身進行裝甲加固。由於當時條件所限，只能用裝甲加固飛機上的少數部位。他們對執行完轟炸任務返航的飛機進行仔細的觀察、分析、統計。發現大多數的彈孔，都集中在飛機的機翼上；只有少數彈孔位於駕駛艙。從資料上說, 加固機翼的性價比最高. 但實際情況缺恰恰相反, 駕駛艙才是最應加固的地方, 因為駕駛艙被擊中的飛機幾乎都沒飛回來."發聲"的資料是最好擷取的,

導讀：　　層級： 進階　　Brett D. McLaughlin, Sr.(brett@newInstance.com), 作家兼編輯, O'Reilly Media, Inc.　　2007 年 11 月 26 日　　Castor 項目為開源領域提供了資料繫結功能。其原理跟 Sun 的 JAXB 很相似，並且向關聯式資料庫表添加了增強映射和綁定功能。在本文中，我們將討論運行 Castor 所需的首要步驟，包括下載、安裝、設定、配置、類路徑問題等等。　　資料繫結風靡一時　　在 XML

1. 理論模型　　此模型翻譯可叫多執行個體併發模式。其一般的如下：　　　　途中，運行到B 的時候，便產生了 N =3 各工作單元。　　然而這個並不能說明多執行個體模式的各種細節，具體區分的4種不同的情況。而這裡要將這四個模式放在一起論述，是因為我覺得這四種模式一般不會單獨使用，很可能是其中的2種之間的契合。2. 四種多執行個體　　(12)Multiple Instances without Synchronization　　注意看到這個模式，主要是用於表示執行個體之間的運行相互"非同步"的狀態。

不要按照使用者的壞習慣去設計，也不要按照程式員的思維去設計！do not according to user bad habits to design, also do not according to programmers thinking design!有好的想法要堅持，不要被其他人的觀點的雜訊掩蓋你真正的內心的聲音。當你的想法站不住時，立即大度的丟棄，這其實是更是一種堅持。have good ideas are going to insist, don’t be others’

1. 理論模型　　一般和 AND-split 配對使用。　　　　這種模式只處理 A、B 分支同時執行的情況，最直接的上文是採用 AND-split 使得 A、B 並發執行。這裡 A、B 執行，若 A 先完成，則觸發後軀結點 C，然後 B 完成以後，則到了這個 Discriminator 後就忽略其執行結果。反之亦然。2. 應用　　提到這個 Structured，就有點上下文關聯的意味。這裡也一樣，根據 A、B

程式員們每天為之忙碌而編寫的程式歸根到底是由什麼組成的？——資料和演算法。想想是不是這樣？ 那麼，究竟是“資料/結構”重要？還是“演算法”更重要呢？思考一下我們為什麼要編寫程式？——處理資料。不是麼，無論是儲存和讀取、發送和接收、監聽和訂閱、服務端與用戶端，我們翻來覆去，玩的就是一堆“數”。因此可以想象，如果程式建立在一個不佳的資料模型之上，改進的成本將遠遠大於建立在不佳的演算法之上。資料建模是構建好系統的第一步，如同建造一座高樓，好的基礎是最重要的，而優秀的演算法如同華麗的裝飾，可以看作是後來

　　現在講述的四種模式，包括：Multi-Choice、Structured Synchronizing Merge、Multi-Merge、Structure Discriminator，一般將其歸納為進階的分支和同步模式（Advanced Branching and Synchronization Patterns）。1.

前言如果資料庫系統（database systems）像受人尊敬的智者講述的條理清晰的故事，那麼工作流程（workflow）就像一群乳臭未乾的小子在大談各自的“哲理”。之所以這樣講，我是想指出，工作流程系統（workflow management systems）還處於技術發展曲線（technology hype curve）上的初級階段。在這個領域我們將面臨一個激動人心的階段。為了描述這一點，可以和關聯式資料庫系統（RDBMS）做一個對比。當在軟體Team

等冪性——是系統的介面對外一種承諾（而不是實現），承諾只要調用介面成功，外部多次調用對系統的影響是一致的。聲明為等冪的介面會認為外部調用失敗是常態，並且失敗之後必然會有重試。查詢、刪除一般是等冪性的更新、插入視情況而定吧對於BS應用而言，要注意Post方式對等冪性的影響，至少要阻止重新整理時重複提交推薦Get方式Rest風格的SOA架構，來保證等冪性對於Schedul（計劃任務、定時任務、Worker）叢集環境的應用，如何保持等冪性是個技術點，有很多成熟的架構來解決……