2008年3月2日
今天客戶方服務器上突然有一個功能保存了，查看日志信息后發現，錯誤信息：
Could not instantiate class XXX from tuple at AliasToBeanConstructorResultTransformer...
Google了很久才發現有可能是HQL語句中別名的問題，具體原因未知，現在處理辦法是，將下面的語句中的別名去掉：
StringBuffer hql = new StringBuffer("select new ContractItem(l, "
+ " pi.unitPrice, " + " pi.currencyType, " + "pi.currencyTypeDisplay," + " pi.units, "
+ " sum(pi.quantity + pi.adjQuantity), " + " pp, " + " pi.task) "
+ " from PurchasePlanItem pi " + " join pi.purchasePlan pp"
+ " join pi.priorList l " + " where l.supplierNo = ? "
+ " and pp.id in (");
具體是否可以解決，還要看一會兒的部署情況。
上篇文章中我簡單闡述了軍工企業信息化遇到的困境，而我們公司（西安融智軟件有限公司www.xardmu.com）則主要是面向軍工企業進行軟件產品的研發和定制項目的開發的。
在產品實施和項目研發過程中，我們的前端技術人員需要做大量的瀏覽器兼容性的工作。痛苦至極啊~而且，即便完成了兼容性的修改，瀏覽器端的JS解析又變成了巨大的瓶頸！例如我們有一個項目為了提高用戶使用的時的方便性，使用了EXTJS4，結果在IE6下性能極其低下。我們的P8是一個項目管理軟件，需要使用到基于EXTJS的Gantt組件，但是此組件在IE6下十分不穩定，而且經常導致IE6崩潰。
介于上面的種種問題，我們開始尋找從瀏覽器上解決問題的方法，例如使用FireFox或者Chrome，因為軍工企業都有域，所以通過域安裝一款軟件是十分容易的。經過權衡，我們決定使用Chrome做為我們軟件的入口。
在企業內部署Chrome其實有三種方式：
1.直接使用Chrome的某一個版本，對此版本進行精簡和簡單的參數配置，或者內置一些自定義的插件，直接進行部署。
優點：技術門檻較低，只需要簡單的精簡安裝文件和配置參數即可。
缺點：無法通過統一的策略管理局域網內所有的部署情況和策略。
2.使用Google提供的Chrome商業版，通過Google提供的商業版可以輕松定制自己企業內部的Chrome，并生成分發文件，同時可以通過配合域策略完成對局域網內的客戶端的行為進行限制。
優點：此版本是11年放出的，一直和多個大型企業緊密合作，相信不久將會形成更加完善的方案，從而在企業級應用市場站穩腳跟。
缺點：需要在線安裝。
3.使用Google的Chrome Frame，一個讓披著IE外殼的Chrome，擁有Chrome的所有性能，只是披著IE的外殼而已。
優點：對于較老一些的企業，而且企業內部又擁有大量的IE時代產物的企業，絕對是一個好選擇。
缺點：需要在線安裝。原有軟件代碼需要修改，才能在用戶瀏覽時使用Chrome模式。
看到痛苦了吧？都需要在線安裝。看來下一步只能開始研究Chrome的源碼，修改并編譯屬于自己的瀏覽器了。。。
最近在做項目的過程中，有些時候需要用Oracle的BLOB/CLOB類型存儲一些很長的文章，一直不知道怎么來進行相關的檢索，經過不懈的努力，終于能夠解決這個問題了。查詢語句如下：
select count(*) from 表名 where dbms_lob.instr(表名.列名, utl_raw.cast_to_raw(convert('關鍵詞','utf8')), 1, 1) > 0;
需要注意的是，這個解決方案只能查詢BLOB/CLOB中存儲的是經過處理的字符串。
本方法在Oracle 10g上測試通過
轉自http://commandos.blog.51cto.com/154976/128732
作為一個技術人員，誰不知道構架？
前一段時間公司找開發人員談心，有位領導問一位開發人員，大致對話如下：
A：“你了解咱們現在產品的構架嗎？能不能談談你對構架的看法？”
B：“… …”
A：“說說看吧~”
B：“我不懂構架！構架是什么？咱們現在的產品還有構架呢？”
作為一個有3年工作經驗，2家公司經歷的VC程序員來說，我覺得，這幾年的積累是白做了！這樣的思想永遠都只能停留在寫程序上~
一個產品沒有構件，就如同一個人沒有靈魂一樣！他不是沒有，只是你沒有去思考，沒有去發現他而已！
我記得袁洪剛說過，“一個偉大的產品背后一定有一個偉大構架師！”，我堅信這一點~產品好壞一方面決定于對現實問題的解決程度，另一方面是構架的好壞！
幾年前，中國的軟件公司里面很少出現構架師/架構師這樣的角色，這幾年開始有改觀了，越來越多的人開始認識到很多錯誤的問題，其實從一開始就是錯的。很多事情并沒有謀定而后動。一味的追求簡單，到最后變成了下線很簡單了！
說自己不知道構架的開發人員有兩種，新手和沒有思想的新手，拼命的同時我們也應該停下腳步想想，抬起頭看看天空。別總把經驗的缺失都歸結于時間的長短，更應該想想自己是否真的積累過。
Wazaabi 2.0 基于 Eclipse3.4/EMF/GEF 的動態界面設計和現實組件，依賴EMF進行界面描述，依賴GEF進行界面顯示。
比較起XUI,XSWT，它的設計器更加的完善，功能比較1.0版本也有很大的提高，而且作者也提出了使用EMF進行數據綁定的思路和實現。
麻煩的是它本身只提供了Fill和Row兩種布局，Button、Text、List、Label這些基本控件。還好作者的文檔功底不錯，簡單幾張圖就把自己的設計思路描述的清清楚楚，高手所為，贊一個！
在它基礎上可以很簡單的進行擴展，而且比擴展VE要簡單的多~這是我喜歡的！現在對它的使用本人還是處于觀望態度，一方面等待它的持續更新，另一方面等待E4的激動人心的放出！
有興趣的朋友可以看看http://www.wazaabi.org/index.php?title=Main_Page
明顯第一種構架比第二種構架好很多，但是我們偏偏在第二種構架上面掙扎了半年的時間。
總是有各種各樣的接口和推辭說業務太復雜，客戶催的太緊，沒辦法把業務放到服務器上，成本太高了！已經是2009年了，10年前大家就意識到維護是關鍵，業務一定要封裝，不能分散于客戶端… …10年后的今天我們竟然還在掙扎！完全沒有思想，完全沒有設計，完全沒有接口，完全沒有OO… …！！！
項目告一段落我要拼命的重構，徹底抽離公共業務，徹底剝離特殊業務，我要OO，我要接口，我要設計，我甚至還要SOA！
我錯了！我認錯！可是為什么公司還有那么多的人還是不認錯呢？做了10年的產品，10年前的東西竟然比10年后的東西還好用！做了10年還是死纏爛打在10年前的原型之上~他們比我更悲哀~
粗心大意，老犯錯！
今天上午在調試EJB3調用WebService時一直遇到MySQL報出的這個問題。郁悶壞了，只是執行了一句update而已，就導致這樣錯誤… …
經過半個小時排查，終于找到問題所在了。原因是分布式事務引起的。
場景描述：
EJB3操作A表-->調用WebService-->WebService操作B表
在操作A表的時候需要等待WebService的調用，如果沒有異常，則可以提交事務，如果出現異常，則不能提交事務；
在操作B表的時候需要處理異常；
一個簡單的分布式事務，一般情況下是沒有問題的~但是由于我的粗心大意，做成了EJB3也在操作B表，這樣就導致了表被鎖死的情況出現~真是郁悶啊！
以前我們的產品重啟RCP應用程序的時候都是找到本地路徑的EXE程序，然后使用：
1
Runtime runtime = Runtime.getRuntime();
2runtime.exec("cmd.exe /c " + excuteStr );
重新啟動應用程序，太復雜，而且上次打開的參數都會丟失。
今天早上翻看了一下Eclipse的org.eclipse.update.ui CVS，找到了：
PlatformUI.getWorkbench().restart();
使用這個重新啟動RCP應用程序，非常的方便，而且參數都在，即使在開發環境下也一樣沒有問題！
VE已經死亡很久了，整個Eclipse社區中，最悲壯的真的要屬VE了。
偉大的目標，沒落的貴族！記得去年在北京的時候，經常有朋友問我VE怎么安裝。呵呵VE2.0開始安裝真的很復雜，偌大的Eclipse-WIKI里面還真的沒有寫多少關于VE安裝的內容。
去年下載過VE的源碼，打算在VE的基礎上做一個自己的設計工具，但是研究了很久，發現CVS上的源碼都過于陳舊了，然后就再也沒有關注過它了。
很久沒有真正的關注過Eclipse了，今天上來看看，發現VE真的回來了！
現在VE的領導者是深圳的亞松（在西安有分公司，我還真想去試試... ...），而亞松最讓我崇拜的大牛就是Yves YANG，呵呵，EclipseWord的大牛哦！
我在自己公司的產品里面也引入了建模的概念，下一步就是根據模型來生成界面，再下一步就是改造VE，讓二次開發人員開發起來更容易更加簡單。
祝福VE，希望有了亞松，VE會更好。
預告下一個系列文章：
企業信息系統建模的思考；
新VE源碼分析；
我見過最好的軟件界面繪制工具http://www.balsamiq.com/
真正能達到又快又好！
做人何懼艱險,豪情不變年復一年,做人有苦有甜,善惡分開兩邊,都為夢中的明天！
上面這段簽名是抄老莫的，每讀一次都會有不同的體會。
沒有維護Blog已經有兩個多月了，這兩個月一直在北京出差，已經待了兩個月了，還得再待一個月！每次出差離開西安總是感覺不舒服，而且從心里要好長時間才能適應，所以就一直沒有維護Blog。
晚上和一位美女吃飯，聊天中突然聊到了這個問題，仔細想想為什么做什么都覺得沒有意思？為什么會不適應外界環境的改變？為什么覺得一切都不爽？
是因為沒有了激情，最近缺少了激情！缺少了創造的激情，缺少了生活的激情，缺少了工作的激情，缺少了寫Blog的激情... ...
重拾激情，這才是重要的！做人何懼艱險！人生路上本來就充滿了艱險，要勇敢面對，無論是失意還是快樂... ...何必在乎得失，終究一切都會過去！抓緊時間，去實現自己夢想！
老版本的Eclipse多國語言項目只維護到3.2.1版本，以后就再也沒有維護了，我覺得主要的問題是，語言包太大，一個包中會有多種語言，對于RCP版本的產品漢化起來很不舒服，明明我只要中文，結果要加入N個語言進來，而且還是20M的包~
Eclipse的http://download.eclipse.org/eclipse/downloads/最近剛剛放出一個叫做Babel project的項目，這個項目就是在解決國際化的問題，這個項目旨在為每一個插件提供獨立的單語言包，這樣在做RCP項目的時候，可以根據需要，打不同的包就可以了~！
周五的下午測試了一下，漢化率絕對在99%以上，而且很多地方的漢化還是很到位的~再有哪些客戶看不懂的地方的了~
只是有一個很小的麻煩，就是RCP原來的異常對話框中的內容，每一句后面都會有\n，莫非多國語言的時候\n被轉義了？
希望可以得到改進！
Neil Bartlett的當下工作就是完成《OSGi in Practice》，今天他在Blog中已經放出了本書的一個預覽版本（第二章）。一下是書的目錄：
Introduction
First Steps in OSGi
Bundle Dependencies
Introduction to Services
Example: Mailbox Reader GUI
The Whiteboard Pattern
Declarative Services
The Extender Pattern
Integrating Third-party Libraries
Building Web Applications
從PDF的授權看是“署名的，非商業的，可流傳的”，我估計這本書上市的時間應該很近了，而且官方的PDF版本也會同步推出的~
喜歡的朋友可以下下來看看，寫的很詳細，個人認為是本好書，而且此作者應該是Eclipse基金會的人，所以對OSGI的理解也不錯有什么問題~
ps:連接地址：http://neilbartlett.name/blog/osgibook/
SQL文件中有Functions，Type，那么在sqlplus中要start直接執行SQL文件怎么辦？例如：
CREATE OR REPLACE FUNCTION strcat(input varchar2 )
RETURN varchar2
PARALLEL_ENABLE AGGREGATE USING strcat_type;
將上面的Functions寫入SQL文件中，然后在sqlplus中用start執行此文件，后果是此Functions并沒有被創建到數據庫中，在后面加上commit；也是沒有用處的，提示的效果是SQL并沒有結束，sqlplus并沒有真正執行。
這怎么辦？Google了老半天，也沒有人寫到這個問題，但是看看人家寫Functions和我寫的有一點點區別，修改一下！
CREATE OR REPLACE FUNCTION strcat(input varchar2 )
RETURN varchar2
PARALLEL_ENABLE AGGREGATE USING strcat_type;
/
在Functions最后一行加上一個/，再執行就OK了~看來sqlplus是把/作為一個Functions或者Type的結束符了！大家注意了！
Shell.open()非常重要！
今天在做SWT中顯示OCX控件，照著Demo寫的，但是不知道為什么每次執行到：Variant pVarResult = auto.invoke(dispIdMember, rgvarg);
JVM都會直接退出~error如下：
| #
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x73d321b9, pid=3696, tid=2208
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing)
# Problematic frame:
# C [MFC42.DLL+0x21b9]
#
# An error report file with more information is saved as hs_err_pid3696.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# [error occurred during error reporting, step 270, id 0xc0000005] |
尋便了網絡也沒有解決辦法，剛開始以為是JVM版本的問題，于是換了3個版本都是同樣的問題~真是郁悶！
最后通過和Demo代碼的比較，發現Demo中有一句shell.open(),注釋掉此句，Demo也是引起JVM退出！在代碼中加入shell.open()，搞定！
原來這個open方法還有這么多的玄機啊，但是javadoc上卻只字未提！
早上看到Google的人肉搜索的招聘廣告，興沖沖的發了郵件，申請，結果：
尊敬的朋友，
非常感謝您在4月1日積極參與谷歌人肉搜索志愿者招聘，這是谷歌于2008年4月1日"愚人節"推出的讓大家"會心一笑 暫解煩憂"的小笑話，在此謹祝大家"愚人節"快樂，天天快樂。
如果您對谷歌公司招聘感興趣，歡迎進一步登錄我們的招聘網站尋找自己真正心儀的職位。http://www.google.cn/intl/zh-CN/jobs/
谷歌肉搜組
Dear Friends,
Thank you very much for your interest in the job positions of Google's "Grassroots search" volunteers on April 1. This is a joke that Google China does on April 1, 2008 to give you some light-hearted mood. Hope you laughed because of it :-). Here, we want to wish everyone "Happy April 1st day and Happy Everyday."
Google Grassroots Search Engineer and Product Group
暈~被欺騙了！寫的跟真的一樣的：
關于人肉搜索
什么是人肉搜索？
人肉搜索與刺青、美白、護膚、減肥等直接在人肉上施行的種種行為無關。顧名思義，人肉搜索就是利用現代信息科技，變傳統的網絡信息搜索為人找人，人問人，人碰人，人擠人、人挨人的關系型網絡社區活動，變枯燥乏味的查詢過程為一人提問、八方回應，一石激起千層浪，一聲呼喚驚醒萬顆真心的人性化搜索體驗。人肉搜索不僅可以在最短時間內揭露某某門背后的真相，為某三某七找到大眾認可的道德定位，還可以在網絡無法觸及的地方，探尋并發現最美麗的叢林少女，最感人的高山牧民，最神秘的荒漠洞窟，最浪漫的終極邂逅…… 人肉搜索追求的最高目標是：不求最好，但求最肉。
谷歌為什么要創建人肉搜索引擎？
谷歌自進入中國市場以來，一直致力于根據本地需求改進用戶的搜索體驗。谷歌很早就意識到，自發的、分散的、有意或無意的人肉搜索行為早在中國互聯網誕生之初就存在并茁壯成長著。中國互聯網界發生的幾乎每一起重大事件，尤其是娛樂性事件，都有可能成為人肉搜索技術的試金石。為了豐富人民群眾的業余文化生活，為了使廣大網民在最短時間內趕超人肉搜索的世界水平，谷歌決定投入巨資打造亞太地區最大的人肉搜索引擎。
谷歌人肉搜索引擎有哪些特點？
- 規模最大：第一期工程擬招募人肉搜索志愿者2500萬名，完成后將成為亞太地區最大的人肉搜索引擎。
- 創新最多：256項專利技術，1024篇相關論文，4096次用戶調研，65536輪預覽版測試。
- 領域最全：搜索范圍涵蓋娛樂、影視、體育、社會、名人、百姓、歷史、地理、物種、太空等領域。
- 速度最快：平均查詢響應時間32秒。
- 挖掘最深：曾在預覽版測試中，用時128秒，成功定位了中國大陸生產的第一只自動沖水馬桶。
人肉搜索招聘需求
人肉搜索志愿者管理專員
組織和領導以志愿者為核心的超大規模人肉搜索團隊，整合來自數千萬搜索志愿者的小道消息，從茫茫人海中發掘信息背后的奧秘。嚴格管理，制止人肉搜索過程中可能出現的扯皮、造假、謠傳、起哄、攻訐、謾罵等不文明行為，創造合理、有序、創新、務實的人肉搜索新秩序。
能力要求:
- 博士以上學歷
- 管理學、傳播學或相關專業畢業
- 掌握五種以上方言
- 有八卦主義精神和凡事不著調作風者優先
請將您的中英文簡歷以文本或HTML的格式發至renrou-jobs@google.com, 并在郵件的標題中注明“人肉搜索志愿者管理專員”。郵件正文請使用中文，所有英文信息請以附件形式提交。
人肉搜索志愿者（兼職）
在業余時間為人肉搜索引擎奉獻智慧、汗水和好心情。利用谷歌研發的人肉搜索平臺，與其他數千萬志愿者并肩工作，使用并行人肉計算的方式，對疑難問題堅持不動搖、不軟弱、不拋棄、不放棄的肉骨茶原則，為廣大網民提供第一手的，帶有人情味兒的，具有震撼力和可傳播性的搜索結果。
能力要求:
- 學歷不限，專業任選
- 有強烈的好奇心和求知欲
- 對常人無法獲取的信息有敏銳的感知能力和打破砂鍋問到底的堅定信念
- 自備聯網電腦一臺，電話機一部，粉筆若干，餐巾紙一箱，《八卦人物風云榜》16開大字本一套共40冊
請將您的中英文簡歷以文本或HTML的格式發至renrou-jobs@google.com, 并在郵件的標題中注明“人肉搜索志愿者（兼職）”。郵件正文請使用中文，所有英文信息請以附件形式提交。
致獵頭公司：對于未簽約的獵頭公司提供的簡歷，谷歌將不支付任何費用。
此次RAP放出了draw2d_in_RAP的Demo，主要展示的是draw2D在RAP框架上的應用，還沒有下載真正的Demo試用，但是從視頻上看，好像是融合了flex來做圖形展示和拖拽，有興趣的朋友可以看看Demo的代碼，然后告訴我~
上次e4放出的基于web的IDE就使用flash作為代碼展示和編輯的編輯器，看來Eclipse社團也感覺到純的js基本上不能完成任務了。
Demo下載地址：http://www.innoopract.com/fileadmin/user_upload/Bilder/Films/draw2d_640x480.mp4
關注過上一篇文章的朋友，基本都對最后說到的微軟要支持SWT的開發提出了不少自己的看法。
下面我們再來看看來自cnBate.com的新聞：
|
Java程序員們可能會經常遇到Windows下的UI問題,Java程序總是和Windows的外觀統一不起來,特別是Vista,難度更高.
而現在,微軟微軟宣布它將為Eclipse基金會提供了標準的widget工具,這意味著Java將與Windows Presentation Foundation實現互通,允許應用程序原生采用Windows VIsta的外觀.
這也是微軟未來開放計劃的一部分,微軟認為一個日益開放,透明的方式正在出現.之前,微軟還成立了Linux的互操作性實驗室,并與JBoss,Zend Technologies等公司實現了技術合作.
|
微軟真的在開源，不但支持了Linux，而且還來關注SWT，而且還有微軟最近在收購Yahoo!，它最近非常關注開源事業，也許他真的要攪局，也許他真的是想做些事情，也許幾年之后微軟搖身一變真的變成了一個開源斗士了！
微軟更換了首席構架師，他的做事風格在改變，我想微軟是在向開源界證明自己的實力，是想讓人們相信自己，也許過幾年微軟還果真出了一個開源版本的windows了~
早上，習慣性的打開GoogleReader，看看世界的變化。發現Planet Eclipse上已經有參加EclipseCON2008的朋友把Eclipse4.0（簡稱e4）Demo地址以及一些截圖放到Blog上了~我們就來欣賞一下Eclipse的巨大變化吧！
呵呵，是不是很可怕，一個基于web的開發工具？我在Eclipse的Wiki上已經看到這個截圖的Demo了，但是還沒有時間試用~
此次放出的e4的demo基本上都是swt的調整，比方說可以使用swt來做flex，使用swt來做DOJO~，從這些方面就可以看到Eclipse正在向基金會想想的那樣為e4提供一個基于web應用的平臺，我想這個平臺應該就是RAP了~而且從Demo上看，e4將會大大的涉足到web應用領域中，期待他們為我們帶來再一次的驚呼！！！
http://wiki.eclipse.org/E4/Running_the_demos （e4的demo）
還有一個令人振奮的消息，不知道是好事還是壞事-----微軟已經決定進入Eclipse基金會，并打算開始資助SWT項目了。
Earlier this week, the teams and developers working on the various projects of Eclipse began an intense debate regarding the next steps in the future of Eclipse, all triggered by the announcement of the incubation project titled 'e4' on the Eclipse committer mailing-list:
The Eclipse Project PMC is announcing a new component, called E4, as part of the Eclipse Project Incubator.
Component Description:
During the Eclipse Project 3.4 release cycle, one of the important plan items was "Create the Eclipse 4.0 Plan". The intent of this work was to identify the most pressing issues that would impact the ongoing success of Eclipse, and come up with a plan to address them. The result was the design of a new platform "e4", which will be the basis for Eclipse 4.0.
The goal of the e4 component is to provide a public venue for the initial explorations that were done, leading up to the e4 design. We expect to continue to work in this area until we have reached consensus on how the full e4 effort will be structured.
The e4 moniker is a reference to Eclipse 4.0, which would be the next major release number for the classic Eclipse distribution and platform projects. The last three major Eclipse releases shared these version number relationships:
Callisto corresponded to the Eclipse platform v3.2,
Europa corresponded to the Eclipse platform v3.3, and the upcoming
Ganymede release corresponds to the Eclipse platform 3.4.
Historically it has been common practice for these plan documents to outline the thematic goals for a given release of what is commonly called the
Eclipse top-level project. Traditionally, the top-level project has encompassed the Eclipse platform, the Java development tools, the Plug-in development tools, and all other components of the commonly referred-to Eclipse 'classic' distribution (the Java and Eclipse Plug-in IDE). This plan format has been used since the 2.1 release of Eclipse, and each prior plan is available
on the Eclipse top-level project site. The e4 announcement is a somewhat different approach in that community involvement is being asked prior to the drafting of any plan.
Initially, the e4 project is little more than a community gathering point; a place to track early changes and ideas in code. The goal of opening this project now has been described by many of those involved as an effort to get community input and ideas at
EclipseCon 2008, and to then begin drafting a plan based on the community input after that point. Kevin McGuire, an Eclipse committer who primarily works on the Platform UI team, described e4 in this way:
We on the platform team care passionately about Eclipse. We know you do too. We want to see it live a long, healthy life. We want it to serve its community as best it can. When we can’t achieve that it makes us sad. It’s clear to us that for Eclipse as a platform to remain long lived, vibrant, and relevant, it must be able to change. But the weight of a zillion plug-ins, projects, and API means the path of least resistance is stagnation, and the effort to effect change given the current constraint system is becoming monumental.
Therefore, two things must happen:
- A new space must be carved out in which experimentation can happen, leading to change.
- New people must get involved, bringing with them their energy, ideas, requirements, knowledge, passion.
These two are intrinsically tied.
That is e4.
While there was some heated discussion over the format and approach of the initial project announcement, the e4 project is likely to become a central test-bed for the various transformations that Eclipse will go through to reach its next major milestone. In the past, major version number increments for Eclipse have represented significant changes for the Eclipse project. The transition to Eclipse 3.0 encompassed the move of Eclipse to the OSGi platform, the announcement and creation of Eclipse rich-client platform, and both a look-and-feel and performance overhaul. The expectation is that Eclipse 4.0 will also represent such a major shift.
InfoQ will continue to cover future Eclipse planning decisions as they become available.
EclipseCON2008 only 1 week left!
又一次開源界的盛會EclipseCON2008就要召開了~據我了解此次盛會將會吸引更多的開源廠商，領袖，開發者參與，其中就有來自微軟的Sam Ramji（微軟開源的Labs），關于OSGi的討論依然是重頭戲。
雖然Eclipse的RAP的發布也有半年多了，也在開源界引起了不小的反響，但是RAP還是沒有得到廣泛的應用，來自RAP的主力開發商Innoopract Informationssysteme GmbH的消息，此次EclipseCON2008大會也會給RAP帶來更多的利好消息，畢竟關于RAP的討論被安排在第二場，僅次于第一場OSGi的議題。
Eclipse4.0也被提上了討論日程，在介紹中提到，Eclipse3.0主要在力推RCP平臺，而Eclipse4.0將會將會帶來一個全新的用戶界面以及新的用戶體驗，將帶領Eclipse進入到WEB應用中，我想在Eclipse4.0的時候RAP應用，將變成Eclipse的主推平臺了。
還有很多關于其他項目的討論，但是我一直關注的VE的消息，好像還是不被人們注意，可見VE基本上已經死亡，而且我認為可以算是Eclipse基金會中比較失敗的一個項目了！
預祝此次大會碩果累累，祝Eclipse越走越好！
預言了兩天，終于決定在我們的RCP客戶端中增加執行JRuby的功能。說是預言其實也沒有什么好預言的，JRuby早有耳聞，Ruby也一直在學習。其實要解決的問題只有一個---解決Java實例如何給JRuby，然后有JRuby操作，其實不難，JRbuy官方的WIKI上有一個例子，但是那個例子有太多硬編碼的問題，稍稍改造，將硬編碼的內容抽取到JRuby中，就好了~
我想說的其實是在RCP中加入JRuby的作用是：
實施人員只需要寫腳本就可以隨意操作界面上的任意東西；
使產品更進一步達到零二次開發的階段；
使用JRuby來開發SWT的界面，還是有比較復雜，在熟悉SWT開發和JRuby的情況下畫一個比較復雜的界面時候就會非常復雜！這里還是建議使用類似于XSWT等XML界面描述語言，然后配合腳本完成功能。
下面給出一個可以在運行JRuby的SWTShell：
| package com.glnpu.jruby; import java.util.ArrayList;
import java.util.List; import org.eclipse.swt.SWT;
import org.eclipse.swt.events.SelectionAdapter;
import org.eclipse.swt.events.SelectionEvent;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Text;
import org.jruby.Ruby;
import org.jruby.javasupport.JavaEmbedUtils;
import org.jruby.runtime.builtin.IRubyObject; public class RunJRUBY extends Shell { private RunJRUBY run;
private Text text;
/**
* Launch the application
* @param args
*/
public static void main(String args[]) {
try {
Display display = Display.getDefault();
RunJRUBY shell = new RunJRUBY(display, SWT.SHELL_TRIM);
shell.open();
shell.layout();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}
} catch (Exception e) {
e.printStackTrace();
}
} /**
* Create the shell
* @param display
* @param style
*/
public RunJRUBY(Display display, int style) {
super(display, style);
run = this;
createContents();
} /**
* Create contents of the window
*/
protected void createContents() {
setText("SWT Application");
setSize(500, 375); text = new Text(this, SWT.V_SCROLL | SWT.BORDER | SWT.WRAP | SWT.H_SCROLL);
text.setBounds(0, 0, 492, 312); final Button button = new Button(this, SWT.NONE);
button.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(final SelectionEvent e) {
Ruby runtime = Ruby.getDefaultInstance();
try {
//允許傳對象，作為參數給JRuby
IRubyObject rootRubyObject = JavaEmbedUtils.newRuntimeAdapter().eval( runtime, text.getText() );
JavaEmbedUtils.invokeMethod( runtime, rootRubyObject, "run", new Object[] {run}, null );
//不傳對象，直接運行JRbuy
//runtime.evalScriptlet(text.getText());
} catch (Exception e1) {
System.err.println(e1.toString());
e1.printStackTrace();
}
}
});
button.setText("button");
button.setBounds(335, 326, 48, 22);
//
} @Override
protected void checkSubclass() {
// Disable the check that prevents subclassing of SWT components
} } |
下面是可以執行的JRuby代碼：
| require 'java'
module SWTTest
include_package 'org.eclipse.swt'
include_package 'org.eclipse.swt.layout'
include_package 'org.eclipse.swt.widgets'
include_package 'org.eclipse.swt.events'
end
class TestDialog < SWTTest::Dialog
@shell
@parentShell
def initialize shell
super(shell, SWTTest::SWT::NONE)
@parentShell = shell
open
end
def open
createContents()
@shell.open();
@shell.layout();
end
def createContents
@shell = SWTTest::Shell.new(@parentShell, SWTTest::SWT::DIALOG_TRIM | SWTTest::SWT::APPLICATION_MODAL)
@shell.setSize(500, 375);
@shell.setText("SWT Dialog");
button = SWTTest::Button.new(@shell, SWTTest::SWT::PUSH)
button.setText("Test Button 1")
button.setBounds(147, 116, 48, 22);
end
end
class TestMain
def run shell
TestDialog.new shell
end
end
TestMain.new |
在JRuby代碼的最下面有一個TestMain的類，主要是用于調用的~這一點是和其他的寫法不同的！
至于它有多強大，就看大家怎么用了~而且java和JRuby是運行在同一個JVM之上的，它可以使用此JVM下的所有對象！
不要用年終考評來訂立學習目標，要利用年終考評來記錄個人的成長。
要讓每一位程序設計師都明白，寫出零錯誤程序是很不容易的，所以應該多花功夫用各種方法做最徹底的測試。
糾正程序設計師以為加除錯碼會花太多時間的觀念，應該訓練程序設計師第一個反應是考慮加上除錯碼是否有道理，第二是考慮加除錯碼是否符合項目的目標與工作的優先級。
不要讓凡事不能的態度阻礙了創新。
不要讓程序設計師以為使用者并不在乎軟件的質量。
不要給使用者次品，寧愿延期交貨，務必追求質量完美。
程序設計師必須經常以使用者的觀點來看自己寫的程序，程序設計師必須能體會使用者的感受。
在包裝盒里的每一件東西，都是產品的一部分。
將程序的可共享性當作優先考慮的目標之一，否則程序設計師將經常做重復的工作。
從您的每件工作中創造最大的資源，不管是利用現有的杠桿，或是創造新的杠桿。
如果進度發生落后，那表示有個地方出錯了。您應該找出問題，并加以解決，不要一味要求組員加班，在問題沒有解決之前，加班是沒有用的。
別誤信加班等于增加生產能力，長期的加班只會傷害生產能力，對項目沒有幫助。
周末是屬于組員私人的時間，不是公司的。公司不應該以打敗競爭對手為理由，要求員工周末加班。
強調思考的重要性，而不是長時間工作。
訓練開發小組懂得在正常工作時間內掌握好工作的效率，不要讓他們超時工作，因為超時工作只是浪費時間的假面具。
與程序設計師共同研擬出一份每日活動的時間表，把無法預期的臨時公務變成固定時間處理的事情，并且把程序開發的工作放在最優先的地位，不要讓其他次要的事情干擾到寫程序。
主管應該把自己視為團隊中的一分子，與其他人平等，而不是高高在上。
用看程序的方式找錯，是既懶惰又無效率的方法；
| 隨時睜大雪亮的眼睛，看看是不是有個懸而未決的問題，一定要有個人(或是由主管自己)來負責研究到底哪里出錯，也許這種研究既花時間又無聊，但總比災難發生之后再來花好幾個星期收拾殘局要好得多。 |
問了錯的問題，而導致錯的答案，訓練自己問出正確的問題！
| 如果您能很清楚告訴別人，您想要的究竟是什么，這樣別人才能給您真正需要的幫助，而不是做一些似是而非的虛工。 |
勉強自己接下不可能完成的任務，實在是以長痛代替短痛的做法，而且長痛的是整個團隊，該拒絕的時候絕對不能含糊；
不要為了討好別人而傷害雙方的工作進程，您永遠要根據自己的目標，做適當的決策。
必須保護項目不受外界的左右，尤其是當這種操控來自特權人物之手。
副產品對公司或產品都沒有策略上的價值，充其量只是一種消費者回饋。
不值得開發的功能就不要做。
軟件產品的開發，不能只為了有趣、挑戰性，或是夠有個性夠令人眩目。
遵循標準重于一切，特別是關于使用者界面的部分。
確定您所要求的報告真的值得屬下暫停工作，花那么多時間去寫。
請注意定期會議的價值，確定它值得每個人放下手上的工作。
召開任何會議之前，請確定本次會議的目的是什么，達成這個目的的條件是什么，然后，務必達到開會的目的。
不要利用進程表來驅使項目的進行，這對小組的士氣傷害太大了。
讓日程表維持適度的緊迫，但又是可以做到的，好讓組員振奮、不松懈，專心致力于項目的推進。
絕對不要草率定出不可能的期限，導致組員為了趕進度而損害產品的質量。
把長期的大項目，分成幾個完整而獨立的小項目，各小項目必須有一個主題。
為了保持創意的活力和團隊士氣，必須讓每一個小項目都有令人興奮的結果。
不要讓程序設計師的學習停滯不前，要讓程序設計師有機會磨練不同領域的技術，培養十八般武藝樣樣精通的組員。
訓練新進程序設計師時，先培養他對整個公司所有項目都有價值的技術，然后才培養本項目獨有的技術。
不要舍不得放您最優秀的程序設計師到別的項目去。如果他在您的項目已經沒有新的東西可學，為了公司和他個人的前途，您應該把他推薦到別的項目，讓他的成長永不間斷。
確定每位組員、每兩個月都有一項技術上進步。
一發現某處需要改進，就立即采取更正的行動。
首先還是先看一下書評。
下面是來自china-pub的書評：
| 作者詳細描述了他在美國領導項目的各種實際的策略方法，教您如何開發高質量的軟件，而且絕不延誤。本書是為每一位從事研發工作的朋友而寫，相信您在讀過本書之后，一定急于推薦給您的主管、同事和您的朋友。 |
卓越的領導者從不同的角度看世界。若是公司被大火燒得精光，他非但不為丟飯碗驚慌，反而利用火焰來燒烤一頓大餐。當每個人都搖頭離去，卓越的領導者仍有充分的信心保持樂觀，對每件事都從正面角度來思考。就因為凡事都看光明面，卓越的領導者并不把失敗當失敗，反將其當作學習克服障礙的經驗。正因如此，卓越的領導者樂意嘗試各種稀奇古怪的想法，并從中獲得重大的突破，即使不成功，他只把這次經驗當成獲得信息的方式之一。這種領導人不一定要有經驗，而是需要強烈的進取心和明確的理想，能夠將理想與他人溝通，鼓舞他人共同追尋理想的能力，再加上一點機會，這就是能將理想實現的卓越領導者。
每當有人完成了一項新的功能或特色，就發個e -mail 給大家。
例如：
| “我已完成Faxmangler 的搜尋與取代功能。Frank”
主管應該看一下結果，然后回一個：
“我檢查過F a x m a n g l e r的搜尋與取代，不太順暢，請再修改。Hubie”
或是：
“很好，繼續加油！Hubie”
想想看，如果大家經常收送這類正面的e - m a i l，一定會覺得充滿干勁，這和可恨的進度報告多么不同！程序設計師會很樂意看見這類的好消息，當自己送出完成工作的信息時，也會很有成就感；沒有人會覺得這是很討厭的報告。 |
每當進度快要落后了，就到我的辦公室私下討論原因，我們一起開動腦筋尋求解決之道。
例如：
| 當某位程序設計師覺得自己可能要落后了，我會和他談，研究將來如何避免這種事情。是我們在制定進程時疏漏了某一個重要環節嗎？或是時間表定得太樂觀了？是不是有個錯蟲( b u g )在作祟，害得程序很難寫或無法測試？不論問題是什么，我們一定想辦法解決掉，并且預防它將來再發生。 |
盡可能減少項目中小組彼此間的依賴。
目標越是明確，達成目標的過程就會越有效率。
建立最適當的程序設計優先考慮順序，并且讓所有的程序設計師確實遵守。
| 排出一個優先級表： - 體積大小(size)
- 速度(speed)
- 堅固性(robustness)
- 安全性(safety)
- 可測試性(testability)
- 容易維護(maintainability)
- 簡潔(simplicity)
- 再用性(reusability)
- 可移植性(portability)
|
一旦您掌握了這個概念，把它應用在項目上，您可以大聲說自己確實是在聰明地工作，而不是辛苦地工。
一發現Bug就立即清除掉，別拖延。
作者給出的提示：
錯蟲愈晚清除，時間花得愈多。
在開發的過程就立即除蟲，可以讓您早些學到經驗，然后就不會再犯同樣的錯誤；相反地，如果到了項目后期才發現，您可能已經犯過多次同樣的錯誤而不自知。 發現錯蟲而立即除錯是一種緩沖器，提醒那些講求快速而不夠謹慎的程序設計師，以后多加小心。 若能保持沒有任何錯蟲，您就能比較準確估出項目的完成時間。 要求錯蟲隨時發現隨時改，等于是在開發過程中引進一個小小的質量管理機制，多方的防微杜漸，保護產品的正確性。 |
學習前人的經驗；
好方法要讓大家分享；
項目只要有偏差，就需要調整，絕對不可以放任自流！
定期暫停手邊的工作，然后往前思考，隨時做必要的修正，以避免未來的大障礙。
| 有什么事情是我今天能做，而且可以幫助項目在未來幾個月內順利進行的？ |
總結本書中的54條法則得到：
- 建議一只和諧的團隊；
- 給團隊一個明確的目標，讓大家都知道這個目標并把它印入腦海；
- 讓品保人員明白自己不僅僅是為了Bug而加入團隊的；
- 建立合適的檢查點和里程碑，并利用檢查點和里程碑檢驗團隊的健康度；
- 不要害怕延誤，要不斷的修正方法但不要過度的修正目標；
- 努力讓團隊中成員產生共鳴；
希望大家共勉！