東方未名

1. 在創(chuàng)建Human Task的UI項目時，請注意保證每個Project的package名都不相同，否則在BPM Workspace中會出現(xiàn)DataControl的NullPointerException。最簡單的方法就是不要設(shè)置Application的package prefix，然后讓每個項目都使用auto-generate的package名。
2. 在Human Task中可以動態(tài)指定審批人，具體做法是在Assign標簽頁中，選擇Single類型（當(dāng)然也完全可以是別的類型），然后選擇User，By Expression，后面的表達式是一個字符串，比如'weblogic,wfaulk,jstein'，注意要使用單引號，也可以從payload中讀取。不過這種方式有時會出錯，出錯原因不明，不過在Organization中添加一個用戶，deploy，然后再把這個用戶刪除就解決了，不得不說非常汗。
3. 如果需要對某個Human Task定時做一些操作，可以使用Catch Timer Event，注意這里指向End1，說明Timer觸發(fā)以后直接走Update Database & Send Email這條分支，然后結(jié)束，并不是主流程結(jié)束。
   
   

     摘要: JAVA相關(guān)基礎(chǔ)知識 1、面向?qū)ο蟮奶卣饔心男┓矫?nbsp;  1.抽象： 抽象就是忽略一個主題中與當(dāng)前目標無關(guān)的那些方面，以便更充分地注意與當(dāng)前目標有關(guān)的方面。抽象并不打算了解全部問題，而只是選擇其中的一部分，暫時不用部分細節(jié)。抽象包括兩個方面，一是過程抽象，二是數(shù)據(jù)抽象。 2.繼承： 繼 承是一種聯(lián)結(jié)類的層次模型，并且允許和鼓勵類的重用，它提供了一種明確表述共性的方法...  閱讀全文

     摘要: 使用Hessian開發(fā)C/S模式的小系統(tǒng)
之所以叫小系統(tǒng)，主要是因為Hessian不支持Hibernate的延遲加載，所以需要在DAO層使用Hibernate的同學(xué)請注意了。

Hessian其實是一種RMI技術(shù)，已經(jīng)被集成在Spring Framework中，這樣就很方便了。

首先看客戶端

第一步：
先定義Client與Server交互的接口。  閱讀全文

Another Quiz : " Which Programming Language Are You?"

http://www.bbspot.com/News/2006/08/language_quiz.php

測到最后我才發(fā)現(xiàn)原來我是一個內(nèi)向的人啊～～真是，搞得我一直都不知道呢
大家有空也去玩玩
http://www.psytopic.com/mag/post/820.html

Psytopic分析：您的性格類型是“ISTJ”(內(nèi)向+實感+思維+判斷)

沉靜，認真；貫徹始終、得人信賴而取得成功。講求實際，注重事實和有責(zé)任感。能夠合情合理地去決定應(yīng)做的事情，而且堅定不移地把它完成，不會因外界事物而分散精神。以做事有次序、有條理為樂---不論在工作上， 家庭上或者生活上。重視傳統(tǒng)和忠誠。

ISTJ型的人是嚴肅的、有責(zé)任心的和通情達理的社會堅定分子。他們值得信賴，他們重視承諾，對他們來說，言語就是莊嚴的宣誓。 ISTJ型的人工作縝密，講求實際，很有頭腦也很現(xiàn)實。他們具有很強的集中力、條理性和 準確性。無論他們做什么，都相當(dāng)有條理和可靠。他們具有堅定不移、深思熟慮的思想，一旦他們著手自己相信是最好的行動方法時，就很難轉(zhuǎn)變或變得沮喪。ISTJ型的人特別安靜和勤奮，對于細節(jié)有很強的記憶和判斷。 他們能夠引證準確的事實支持自己的觀點，把過去的經(jīng)歷運用到現(xiàn)在的決策中。他們重視和利用符合邏輯、客觀的分析，以堅持不懈的態(tài)度準時地完成工作，并且總是安排有序，很有條理。他們重視必要的理論體系和傳統(tǒng) 慣例，對于那些不是如此做事的人則很不耐煩。ISTJ型的人總是很傳統(tǒng)、謹小甚微。他們聆聽和喜歡確實、清晰地陳述事物。ISTJ型的人天生不喜歡顯露，即使危機之時，也顯得很平靜。他們總是顯得責(zé)無旁貸、堅定不變 、但是在他們冷靜的外表之下，也許有強烈卻很少表露的反應(yīng)。

您適合的領(lǐng)域有：工商業(yè)領(lǐng)域、政府機構(gòu) 金融銀行業(yè)、政府機構(gòu)、技術(shù)領(lǐng)域、醫(yī)務(wù)領(lǐng)域

您適合的職業(yè)有：

· 審計師
· 會計
· 財務(wù)經(jīng)理
· 辦公室行政管理
· 后勤和供應(yīng)管理
· 中層經(jīng)理
· 公務(wù)（法律、稅務(wù)）執(zhí)行人員
· 銀行信貸員
· 預(yù)算分析師
· 保險精算師
· 稅務(wù)經(jīng)紀人
· 稅務(wù)檢查員
· 機械、電氣工程師
· 計算機程序員
· 數(shù)據(jù)庫管理員
· 地質(zhì)、氣象學(xué)家
· 法律研究者
· 律師
· 外科醫(yī)生
· 藥劑師
· 實驗室技術(shù)人員
· 牙科醫(yī)生
· 醫(yī)學(xué)研究員
· 信息總監(jiān)
· 電腦編程員
· 證券經(jīng)紀人
· 會計
· 文字處理專業(yè)人士

基于求函數(shù)f(x,y,z)=xyz*sin(xyz)最大值問題的演示程序：


截圖：








 

壓縮包：
genetic_algorithm.part1.rar
genetic_algorithm.part2.rar
genetic_algorithm.part3.rar
genetic_algorithm.part4.rar

運行方法：
解壓后在命令行輸入：java -jar genetic_algorithm.jar

     摘要: 最近學(xué)習(xí)遺傳算法，寫了這么一個小程序來計算函數(shù) f(x,y,z) = xyz*sin(xyz)的最大值，這段程序經(jīng)過小小改變就可以適應(yīng)其他的函數(shù)最大值求解問題首先介紹一下遺傳算法，遺傳算法就是模擬自然界中物競天擇，適者生存的法則，通過對解空間進行進化從而求得最優(yōu)方案的方法，遺傳算法的好處在于，即使算法中的某些參數(shù)不起作用了，整個算法還是可以正常地工作，也就是說，整體種群的走向是越來越好的遺傳算法的...  閱讀全文

     摘要: 用Java從控制臺輸入密碼

本來以為是很簡單的問題，查了一下發(fā)現(xiàn)Java居然沒提供這樣一個方法。目前實現(xiàn)的方式有2個，一個是利用JNI來調(diào)用C/C++方法，另一個是使用多線程。
本文使用JNI調(diào)用C/C++的方法實現(xiàn)  閱讀全文

     摘要: JDK6.0發(fā)布有段時間了，新的JDK也有不少新的特性，我去網(wǎng)上搜集了一下，列在下面和大家一起學(xué)習(xí)．１．Desktop和SystemTray. 在JDK6中 ,AWT新增加了兩個類:Desktop和SystemTray,前者可以用來打開系統(tǒng)默認瀏覽器瀏覽指定的URL,打開系統(tǒng)默認郵件客戶端給指定的郵箱發(fā)郵件,用默認應(yīng)用程序打開或編輯文件(比如,用記事本打開以txt為后綴名的文件),用系統(tǒng)默認的打印...  閱讀全文

這幾天突然遇到了一個問題：Tomcat跑不起來了！提示錯誤信息：
Error Listener Start
org.springframework.web.context.ContextLoaderListener
Error Listener Start
....
就這么2行，讓人一頭霧水。昨天檢查了一個下午也沒發(fā)現(xiàn)問題。今天突然在查看錯誤日志時發(fā)現(xiàn)：
Context initialization failed

org.springframework.beans.factory.BeanDefinitionStoreException: Line 14 in XML document from ServletContext resource [/WEB-INF/springctx-datareport.xml] is invalid; nested exception is org.xml.sax.SAXParseException: Element type "bean" must be followed by either attribute specifications, ">" or "/>".

仔細查看了一下配置文件，原來是同組的組員在寫配置文件的時候在class="...."后面多了一個引號！
這個Listener Start的問題太隱蔽，如果沒有做錯誤日志估計一直很難發(fā)現(xiàn)了
不過這次有了教訓(xùn)，以后也有方向了

     摘要: 根據(jù)Ajax in Action書進行調(diào)整，修改了原書上的錯誤，調(diào)試通過。
可重用的Ajax輸入提示類，功能類似Google的輸入提示  閱讀全文

     摘要: JSP與Tomcat亂碼解決方法  閱讀全文

經(jīng)常開各種各樣的會議,要達成共識很不容易，尤其技術(shù)會議更是容易吵架。舊年最后一天，寫點關(guān)于“開會”的想法。

首先，要注意聽別人發(fā)言。盡量不要打斷別人的發(fā)言，抓住對方的主要思想和依據(jù)。不要帶著偏見聽，有時候可能覺得對方不如你，但是不代表他現(xiàn)在說的就不對。把口頭禪從“不，……”改成“對，……”，即使有時候你不同意他的觀點，但是先肯定一下，可以緩和很多氣氛。

然后，盡量先把自己的理論基礎(chǔ)表達清楚，有時候爭了半天，發(fā)現(xiàn)兩個人想法是一樣的，不過是換了種表達方式……

最后，不要長篇大論，給別人一個插口的機會。有些人講話，喜歡停頓一下，然后在別人馬上要開口講話的時候接著講。我很反感這種人，耍猴呢啊？給別人一個提出意見和疑問的機會。盡量把自己放到討論的主導(dǎo)地位上來，就是說，要慢慢地讓大家圍繞著你的觀點提問題，然后你再來進行解答。但是千萬不要不讓別人說話，有時候給別人機會說話對自己理清思路也非常有好處。

最近看一本叫《人件集－人性化的軟件開發(fā)》的書，里面第一篇文章就講如何作出決策和達成一致意見。一致意見應(yīng)該做到綜合各方的優(yōu)點，而不應(yīng)該是各方意見的“折衷”。書里有一個稍顯極端的例子：假如你的團隊正在開發(fā)一個圖形用戶界面的項目，一部分人強烈建議直接將控制按鈕放在屏幕底部，而另一部分人建議在屏幕左側(cè)放置一個控制窗口。兩種意見中，一個是水平放置，一個是垂直放置，形成了兩個極端。那么一個最具代表意義的折衷方案就是，將控制按鈕沿著對角線放置在屏幕的中央。在很多時候，由折衷所產(chǎn)生的解決方案比任何一個原始方案都差勁，但是“技術(shù)性一致意見”就恰恰相反，它所產(chǎn)生的解決方案要比任何一個原有的方案都好。書上給的“一致意見”解決方法是給控制按鈕窗體加上選項，讓用戶來決定是水平放置還是垂直放置。

在團隊中的表現(xiàn)是很重要的，通過一個團隊來改變團隊中的個體，要比單獨改變一個個體容易得多。所以在團隊中發(fā)揮影響，比單獨對每一個人發(fā)揮影響要有用得多。

有人說軟件工程更像是“社會學(xué)”，而不是“工程學(xué)”，我也越來越有這種感覺了。

圣誕到了,祝所有的朋友圣誕快樂!!

原貼地址：
http://news.csdn.net/n/20061221/99748.html

從根本上說，面向服務(wù)的架構(gòu)能夠使企業(yè)內(nèi)部動態(tài)數(shù)據(jù)服務(wù)的創(chuàng)建變得更加方便，同時，還能夠使企業(yè)開發(fā)人員創(chuàng)建影響這些服務(wù)的復(fù)合應(yīng)用程序。Web2.0提供了一個豐富的Web體驗，用戶能夠以高效的、充滿希望的、有益的方式參與合作。

　　如果我們把這兩個現(xiàn)象結(jié)合起來，那么，通過企業(yè)社團成員之間的互相交流，以及成員與不斷變化的企業(yè)數(shù)據(jù)之間的交互，我們就能夠?qū)崿F(xiàn)這一關(guān)鍵的提高效率的新方法。

　　協(xié)作型企業(yè)相互融合，下一代的Web應(yīng)用程序也已露端倪，但是，開發(fā)團體的推測是，為了實現(xiàn)明顯的利益，企業(yè)所采用的各種技術(shù)之間存在著根本性 的差異。標準必須朝哪個方向發(fā)展才能夠滿足SOA與Web2.0概念的結(jié)合，為了更好的理解這個問題，我們將致力于檢驗Java表示技術(shù)的狀態(tài)。

　　Ajax化JavaServer Faces

　　標準奠定了SOA的基本結(jié)構(gòu)，但是，在Web2.0的世界中卻不存在著標準。為了支持Web2.0的功能，市場上出現(xiàn)了太多的方法，其中大多數(shù) 在JavaScript的實現(xiàn)(影響Ajax的技術(shù))上卻非常繁雜。在Java EE的規(guī)范中，JavaServer Faces提供了表示層，但是，相比起Ajax技術(shù)和Web2.0概念的流行，它目前的修訂版出現(xiàn)的更早。

　　事實證明，在組件層，JSF中的可擴展組件架構(gòu)非常適合與Ajax技術(shù)協(xié)同使用，但是，組件層Ajax技術(shù)存在的問題是，它們是存在于狹小的規(guī) 避JSF生命周期的交互空間內(nèi)。解決這一問題所需要的是，一種更加全面的方式，以實現(xiàn)在JSF生命周期內(nèi)的Ajax交互。具體來說，有以下兩點需要著重闡 述。

　　1.改進的用戶交互模型: 在JSF中，目前的用戶交互模型是基于表格的，它過于粗略而無法傳輸豐富的Web2.0特性。組件層的Ajax交互粒度，以及JSF目前依賴的基于表格的子任務(wù)模型，這兩者之間存在著顯著的差異。交互類型應(yīng)當(dāng)包含以下幾種形式：

• 　　純粹的本地客戶端JavaScript交互，沒有服務(wù)器通信、不需要執(zhí)行JSF生命周期。這種類型的例子可以是，在日期選擇組件中通過日歷來進行導(dǎo)航。目前，通過組件層JavaScript實現(xiàn)能夠支持這個模型。
• 　　組件層的Ajax交互，不需要執(zhí)行JSF生命周期。這種類型的例子可以是，基于當(dāng)前用戶在文本框中的輸入，從而形成一個列表。這里的關(guān)鍵是，用戶與組件的交互僅僅影響到該組件的表示。同樣，目前，通過組件層JavaScript實現(xiàn)能夠支持這個模型。
• 　　組件層的提交，引發(fā)JSF生命周期的執(zhí)行。生命周期的執(zhí)行結(jié)果將成為新的表示，該表示可能會影響到頁面中的多種組件。這這種類型的例子可以是，在日期選擇組件中完成日期的選擇，結(jié)果是引發(fā)顯示不同的日期安排信息。目前在JSF中，還無法支持這種形式的交互。

　　2. 增量表示更新: 為了使用Ajaxian 方式(不是頁面刷新)實現(xiàn)第三種交互模型，JSF需要一個增量更新機制，僅僅是把頁面中應(yīng)用到的表示層所做的必要修改從一個表現(xiàn)處理傳向下一個表現(xiàn)處理。 下面這個圖示表明了這個概念。它需要一個Ajax橋，在服務(wù)器端把表示的改變組合起來，在客戶端的DOM把那些變化重組。

JSF Push模式

　　Ajaxified JSF實現(xiàn)和多數(shù)其它的Ajax方式從遺留的Web應(yīng)用程序模型中繼承了一個共同的特征，該模型是一個客戶端發(fā)起的交互模型。這意味著，客戶端的表示層只需要針對用戶與表示層的交互進行相應(yīng)變化。

　　與使用遺留應(yīng)用程序相比，使用Ajax技術(shù)，這個交互是細粒度的，但是，它仍然是客戶發(fā)起的。現(xiàn)在，當(dāng)你檢驗支持應(yīng)用程序的SOA數(shù)據(jù)模型的動 態(tài)特性、了解眾多同步用戶采用這一動態(tài)數(shù)據(jù)所進行的協(xié)調(diào)互操作時，你就能夠意識到，在客戶端推動動態(tài)表示變化的機制是非常重要的，這一點越來越清晰。它是 達到Web2.0模型所需要的真正的動態(tài)特性的唯一途徑。

在產(chǎn)業(yè)中已經(jīng)證明，對于JSF規(guī)范與一個表示push模型的協(xié)作來說，Ajax push技術(shù)，也指Comet，是十分必要的。前文已經(jīng)描述的這個增量更新特性，提供了在實現(xiàn)JSF Push模式時所需要的基于Ajax的更新機制。除此之外，當(dāng)應(yīng)用程序邏輯發(fā)現(xiàn)出現(xiàn)了一些將會影響客戶端表示層狀態(tài)的變化時，延長JSF的生命周期來允許 一個強制的表現(xiàn)處理是很有必要的。

雖然，JSF push模型相對而言實現(xiàn)起來更加容易，但是，生產(chǎn)經(jīng)驗表明，為使得開發(fā)人員能夠有效繼承，僅僅暴露JSF API中底層強制的表示機制是遠遠不夠的。關(guān)于基本的push機制，JSF規(guī)范很有必要對表現(xiàn)API進行介紹，從而呈現(xiàn)給開發(fā)人員一個清晰有效的機制，用 于請求強制表示。API尤其需要提供以下幾個方面：

　　1.觸發(fā)的表現(xiàn):應(yīng)用程序開發(fā)人員應(yīng)當(dāng)能夠在發(fā)出表示處理請求的業(yè)務(wù)邏輯中定義觸發(fā)點。

　　2. 群組表現(xiàn): 一個觸發(fā)點能夠影響一個單一客戶端、多個客戶端，或者是所有連接到該應(yīng)用程序上的客戶端。因此，為觸發(fā)表現(xiàn)提供群組管理結(jié)構(gòu)，這是很有必要的。

　　3. 預(yù)定的表現(xiàn):有許多合適的計劃機制應(yīng)當(dāng)被支持，包括，按需表現(xiàn)、推遲表現(xiàn)，以及內(nèi)部表現(xiàn)。預(yù)定的表現(xiàn)架構(gòu)應(yīng)當(dāng)具備可擴展性，以支持其他用戶預(yù)先設(shè)定的需 求。很重要的一點是，觸發(fā)表現(xiàn)機制應(yīng)當(dāng)能夠更加有效的傳輸。由于存在著大量的觸發(fā)，它們潛在地以各種方式影響著客戶端，因此，管理表現(xiàn)的處理這一任務(wù)不能 僅僅落在開發(fā)人員身上。觸發(fā)表現(xiàn)的實現(xiàn)，必須有效地合并表現(xiàn)處理請求、處理必要的同步，而且，這些操作都是以一種線程有效的方式。

　　多視圖支持

　　現(xiàn)存的為JSF定義的階段和需求范圍，根本不足以支持滿足Ajax的JSF應(yīng)用程序——用戶能夠在同一應(yīng)用程序上獲得多個活動視圖。階段范圍能 夠維護所有視圖共同的狀態(tài)，但是，它不足以處理視圖之間不同的狀態(tài)。由于多個同步請求都必須是活動狀態(tài)，所以，需求范圍也不充分。因此，需要一個新的范 圍，來管理滿足Ajax 的JSF應(yīng)用程序的會話方面。JBoss的Seam 方案提出了會話范圍，它主要提供JSF中所需要的額外范圍。除了支持多視圖之外，會話范圍還能夠帶來其他優(yōu)勢，例如，在應(yīng)用程序中，通過會話中對一系列用 戶交互的明確描述，就能夠有效地支持書簽和返回按鈕特性。

　　長期存在的HTTP請求

　　回到前面所提到的push模型，你可能注意到，機制需要一個特殊的HTTP請求，它能夠異步地響應(yīng)從應(yīng)用程序中發(fā)出的觸發(fā)表現(xiàn)出理請求。依據(jù)更 新的頻率，這個特殊HTTP請求能夠長期存在。由于在響應(yīng)之前，每一個請求都占用其線程，所以，在處理這個長期存在的請求時，現(xiàn)存的Servlet模型無 法很好的響應(yīng)。因此，為了支持push模型，必須對Servlet模型進行改變，使它能夠以線程有效的方式來處理長期存在的請求。再強調(diào)一次，有很多生產(chǎn) 方案與異步Servlets和HTTP服務(wù)器相關(guān)，Java EE規(guī)范能夠在此基礎(chǔ)上定義一個解決方案。

　　結(jié)論

　　人們?nèi)匀挥行┵|(zhì)疑：SOA與Web2.0世界將會發(fā)生抵觸，新一代的協(xié)作型企業(yè)應(yīng)用程序已露端倪。也存在著這樣的質(zhì)疑，現(xiàn)存的Java EE規(guī)范無法完全處理Web2.0提出的請求，以及JSR處理必須開始在直接項中考慮這些請求。然而，產(chǎn)業(yè)中的重大進步，已經(jīng)能夠處理出現(xiàn)的請求，并且能 夠?qū)崿F(xiàn)擴展現(xiàn)存Java EE基礎(chǔ)結(jié)構(gòu)的商業(yè)化的可行方案。即將使用JSR 172來生成JSF2.0規(guī)范，非常重要的是,包含Ajax特性，以及產(chǎn)業(yè)參與者貢獻相關(guān)技術(shù),來確保能夠及時做出基于標準的解決方案。