今天客戶方服務器上突然有一個功能保存了，查看日志信息后發現，錯誤信息：
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程序員來說，我覺得，這幾年的積累是白做了！這樣的思想永遠都只能停留在寫程序上~
一個產品沒有構件，就如同一個人沒有靈魂一樣！他不是沒有，只是你沒有去思考，沒有去發現他而已！
我記得袁洪剛說過，“一個偉大的產品背后一定有一個偉大構架師！”，我堅信這一點~產品好壞一方面決定于對現實問題的解決程度，另一方面是構架的好壞！
幾年前，中國的軟件公司里面很少出現構架師/架構師這樣的角色，這幾年開始有改觀了，越來越多的人開始認識到很多錯誤的問題，其實從一開始就是錯的。很多事情并沒有謀定而后動。一味的追求簡單，到最后變成了下線很簡單了！
說自己不知道構架的開發人員有兩種，新手和沒有思想的新手，拼命的同時我們也應該停下腳步想想，抬起頭看看天空。別總把經驗的缺失都歸結于時間的長短，更應該想想自己是否真的積累過。