2006年1月6日
#
Java 8之前，同一注解不能在相同的目標元素上多次使用，例如，如下的注解在Java 8之前是不允許的：
public class SampleClass {
@Quality("Security")
@Quality("Performance")
@Quality("Readability")
public void foo(){
//
}
}
Java 8引入了Repeatable注解（@Repeatable）可以解決這一問題，但光有可重復的注解定義還不夠，還需要它的容器注解，兩者一起來實現可重復注解的使用。實例如下：
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
@Repeatable (Qualities.class)
public @interface Quality {
String value();
}
@Target(ElementType.METHOD)
public @interface Qualities {
Quality[] value();
}
其中，Quality是可重復注解，由@Repeatable注解標明，它的容器注解是Qualities，用于存放所有可重復的Quality（存貯在Quality[]中）；同時還要注意可重復注解和它的容器注解的目標元素必須是一樣的（這也不言自明）。如此這般，我們最開始的
SampleClass 在Java 8環境下就可以安全使用了。
以下單例實現思想來自《Java Design Patterns: A Programmer's Approach》.
該方法利用了Java缺省的Lazy類實例化機制克服了傳統單例模式實現中Lazy實例化方式的不足。
public class Singleton {
private Singleton(){}
public static Singleton getInstance(){
return Helper.instance;
}
static class Helper {
private static Singleton instance = new Singleton();
}
}
以下轉自StackOverflow（
http://stackoverflow.com/questions/5074063/maven-error-failure-to-transfer），親測可用。
This worked for me in Windows as well.
- Locate the {user}/.m2/repository (Using Juno /Win7 here)
- In the Search field in upper right of window, type ".lastupdated". Windows will look through all subfolders for these files in the directory. (I did not look through cache.)
- Remove them by Right-click > Delete (I kept all of the lastupdated.properties).
- Then go back into Eclipse, Right-click on the project and select Maven > Update Project. I selected to "Force Update of Snapshots/Releases". Click Ok and the dependencies finally resolved correctly.
當我們寫Groovy腳本代碼的時候，有時會發生編譯錯誤，如下：
- Groovy:Invalid duplicate class definition of class XXX : The source XXXX\XXX.groovy contains at least two
definitions of the class XXX.
- The type XXX is already defined
原因在于Groovy會把.groovy代碼文件作為腳本或類定義來處理，例如如下代碼：
class Order {
def security
def value
private buy_sell(su, closure) {
security = su[0]
quantity = su[1]
closure()
}
def getTo() {
this
}
}
def methodMissing(String name, args) {
order.metaClass.getMetaProperty(name).setProperty(order, args)
}
def getNewOrder() {
order = new Order()
}
Integer.metaClass.getShares = { -> delegate }
Groovy會把上述代碼作為腳本處理，同時缺省用文件名來作為一個外圍類類包括整個腳本程序，此時，如果該文件名恰好也是Order的話，那么就會出現重復的類定義錯誤提示。
解決辦法是將腳本文件名取另外一個不同的名字。
已經申請OCUP中級考試的學員可以在一年內（截止到17年9月份）免費申請OCUP2中級考試的資格（原有考試仍可以參加）。此外，2014年3月份之后參加了原有OCUP中級認證考試的學員可以免費申請OCUP2中級認證考試。詳見OMG網站聲明（http://www.omg.org/ocup-2/exam-info.htm）。
搬家總是難免的，但舊家的東西不能帶走難免會留下些許遺憾，希望它們能永遠留下來.......
歡迎光臨我的新家：
http://blog.sciencenet.cn/?53016 （科學網）
轉自網絡。
3歲，他去上幼兒園了，看著他小小的堅強的背影，心中又喜悅又有點小小的心酸。離別了一整天，孩子看到你高興得奔跑過來，撲在你的懷里。跟你說：媽媽，我想你了。那一刻，抱著孩子就像抱著了整個世界。
6歲，他上小學了，孩子終于走進校門，這是多么值得紀念的事情，孩子的人生從此翻開了新的篇章，卻沒想到，這也是孩子離開我們的第一步。他已經對與你分開一天習以為常了，而且他喜歡每天去學校，這是他更喜歡的生活。甚至，他有時還會說：媽媽，在家好無聊，沒有小朋友和我玩。
12歲，他上初中了，甚至有的開始上寄宿學校，一個月或者幾個月回一次家，見上一次面。他們開始不再依賴你，甚至，他們喜歡和你對著干。你想幫他們做點事情，他們說:媽媽，我自己來吧。突然覺得這句話讓我們覺得好失落，孩子是不是不再需要我們了？
18歲，他離開你去上大學，一年回來兩次。回來的好幾天前，家里的冰箱就裝不下了，為他準備了各種各樣他喜歡吃的東西。可是一回來打個照面，他就忙著和同學朋友聚會去了。從此，你最怕聽到的一句話是：媽媽，我不回家吃飯了，你們自己吃吧。
大學畢業后，孩子留在了遠方工作，一年也難的回來一次了。好不容易回來一趟，幾天就走了。你最盼望的就是孩子的電話，希望，孩子對你說一聲：媽媽，我很好，你保重身體。這樣就足夠了。
孩子結婚了，回家的時間有一半勻給了你的親家，孩子回來的更少了。你已經習慣就老兩口在家了，但是，你最希望聽到孩子對你說：媽媽，今年過年我回家過啊！
當孩子又有了他們自己的孩子，你已經不再是他們的家庭成員了，他們的一家三口（或一家n口）里，已經不包括你們了。
而我們也慢慢的習慣了這樣的日子。只是習慣在閑來無事的時候，經常翻翻相冊，看看我們自己的一家三口，無論孩子身在何方，他卻永遠是我們家庭中無可取代的一員。
是啊，其實當孩子在身邊的日子，我們是多么幸福。可是有時我們卻還會抱怨。抱怨因為他，你做了太多的犧牲。抱怨他晚上老醒來，讓你睡不好，抱怨他無理取鬧，抱怨他愛撒嬌長不大，抱怨他生病，讓你操碎了心，抱怨為了培養他，花費了太多的精力與金錢...可是，如果你想想，10多年后，就算你想要，也沒有機會了。孩子會不停的長大，過了這個時期他就再沒有這個時期的習性。你是不是常常在他斷奶后懷念喂他吃奶的日子，可是那時你卻覺得好累好辛苦好厭倦。是不是常常看他以前吃手的照片覺得好可愛，可是你曾經卻為要不停的給他洗手而煩惱透了。是不是在他褪去童聲后，特別想念他曾經奶聲奶氣的聲音，可是他以前撒嬌的時候你卻很不受用。是不是當孩子去上學后你特別懷念他黏在你身邊的日子，可是以前你卻總在想他要什么時候才能去上學啊。。。
時間無法倒流，過去了就只能永遠過去了。孩子能呆在身邊的日子是多么難得與寶貴。因為這一點，我更加的珍惜與孩子相處的每一刻，也讓我無論遇到什么，都心存感恩。謝謝上天給我這么一個孩子，讓我分享與見證他成長的每一刻。無論帶給我多少困難，煩惱，甚至挫敗，無論讓我失去多少睡眠，時間，金錢，精力，我仍然豁達，因為，這都是上天的恩賜。
當他在身邊的每一天，我都會讓他覺得幸福，也是讓我們都有一個美好的回憶。我不會給他太多壓力，束縛，更不會給他牽絆，阻擾，但是我會適時管教，也會做量力而行的投資，因為我有責任與義務教會他生活的本領，好讓他來日自由快樂的飛翔。同時，我也會告訴他，就算所有的路都行不通時，還有一條路你可以暢行，那就是回家的路。。。。。。。。
今日編輯一PDF文件（用的是Adobe Acrobat Pressional 7.0），刪除了幾頁，然后保存，結果文件大小反而增加了；而刪除幾頁后另存，則文件大小減少。
你也試試看。
Robert L. Glass在《Negative Productivity and What to Do about It》（詳見IEEE Software, September/October 2008, p. 96）闡述了自己對那些影響項目進度的人的親身感受和對此應采取的解決方案。
作者以個體差異開頭（作者指出，在軟件工程文獻中提到過非常大的個體差異：28:1 (for error identification) to 25:1 (for coding ability) to 11:1 (for timing efficiency) to 6:1 (for sizing efficiency)。但不幸的是，這些差異并沒有得到我們足夠的認識，作為實踐者，我們不知道如何鑒別出那些是別人28倍生產力的人，他們對于按時交付高質量的軟件非常重要；作為研究者，在案例研究中也沒有對個人進行足夠的區分，這將導致對結果的誤讀。），然后引出對項目進展帶來負作用（影響項目進度）的人''(someone who has negative productivity—that is, someone whose inclusion on a project actually makes the project less efficient.)''，接著以自己的親身經歷的三個例子做了闡述：
1. Disfunctional labor relations. 項目（與軟件無關）組被抽走一人，卻發現生產力提高了；這個案例讓作者意識到項目中存在讓人不易覺察的對項目生產力產生負影響的人；
2. Moral rebellion. 作者所帶領的項目組中存在一個對公司存在性不認同的人，導致項目進度滯后，使作者受到了軟件職業中最差的評價；
3. Overly high standards. 作者所在的項目組由于一個對質量要求非常嚴的QA，總是對提交的產品不滿意，結果導致產品遲遲不能交付。
對待這些人，作者給出了自己的解決方案：解雇他們。''(If someone on your project is deliberately delaying its progress, there’s probably only one reasonable solution. Fire them! If you don’t, your team will be sorry, your company will be sorry, and, quite likely, you’ll be sorry as well!)''
第九屆全國軟件與應用學術會議（NASAC 2010）如期（11.4～11.7）在蘇州大學舉行，對于本次會議，有以下幾點感受：
1. 學術水平有待提高（投稿主體還是以碩士生為主，尚不能吸引國內高水平文章）；
2. 學術交流有待提高（本次會議的很多短文都未準備Poster，演示和茶歇的環境很有限）；
3. 會議招待有待提高（除了歡迎宴以外，就都是自助了，很單一，應該多樣化一些）；歡迎晚宴很一般，由于專委沒有參加，所以缺少了很多交互，沒有節目，沒有致辭，就是一味的吃
本次會議的收獲是認識了一些同行，并與北大和復旦的相關研究人員就軟件復用和產品線相關實踐以及企業應用實踐的相關問題進行了討論。還有就是吃到了正宗的陽澄湖大閘蟹（一公一母）。
蘇州風光很好，游覽了一些古街，小橋流水，無限柔美，但環境保護還有待加強，經常可以看到吸煙的把煙頭從湖水中扔，還有吐痰的......，要是蘇州在國外，一定會更美。
9.13至9.17日，第十四屆國際軟件產品線會議
（SPLC 2010）在韓國濟州島的
華美達酒店舉行。這是SPLC第二次來到亞洲（上次是2007年在日本。作為軟件工程知名會議，SPLC輪流在美洲、亞洲和歐洲舉行，是系統化軟件復用的專業會議）。
作為與工業界聯系比較緊密、體現軟件工業化的主流會議，SPLC 2010并未得到國內的關注，這在一定程度上體現了國內工業界的相對落后的局面（既沒有產品線的實踐，又缺乏對先進軟件生產方式的跟蹤與研究）。
本次的參會者來自國內的只有 5 人（包括我和導師，分別來自北京大學、上海交通大學、東北大學和公安部第一研究所）當然也有一些海外華人（老師和在讀的博士（后））。會議論文集收錄了來自國內的一篇短文、一篇Poster（我們的），以及一篇工業化論文。對我來講，最大的收獲在于開闊了視野、了解了一些當前最新進展和認識結交了一些新朋友，當然，這也是我第一次出國，雖然離家很近。
值得一提的是，來自公安部第一研究所的李東老師參加了
Software Product Line Fame of Hall競評演講（本次會議唯一的一個），至于能否加入Fame of Hall要等下次會議（SPLC 2011，慕尼黑）才能知曉，不過李老師所展示的航空安檢系統產品線已經得到了與會絕大多數人員（好像沒有發現幾個不贊成的，呵呵）的認可，很可能成為國內第一家啊，祝福。
去年10月份向《計算機工程》投了一篇稿件，審稿加修改共耗時2個月，然后被錄用，說安排在今年11月左右發表，結果今年10月份就發表了，本來是件好事，但我注意到的一個重要問題是文章中刊出的“收稿時間”竟然是今年的5月份，我很驚訝，于是給編輯部留言問是怎么回事，但始終沒有人答復。
如此大的時間差別（去年10月份到今年5月份那可是7個月之久啊），難道是編輯“手誤”，手誤也應該做個解釋啊，怎么就是不回留言呢。之前我也注意到一些發表的論文（10月份之前發表的）中刊出的“收稿時間”大概也在今年的2，3月份，當時我還想怎么這么多在我之后收稿的卻在我之前發表呢，看來這也許是一種故意行為，“潛規則”！！！
難道出版社就為了顯示自己發表周期短欺騙廣大科研工作者嗎？先不說這本身就是學術不端，重要的是它直接給投稿者帶來了巨大的風險——剽竊。試想一篇思想類似的文章如果是在去年10分之后投稿如果發表了（當然前提是其它期刊刊出的收稿時間是真實的），那會是什么情況？？不用說別人肯定認為是我剽竊，所以收稿時間應該是絕對真實的，我想這也是這個信息在文章中出現的主要價值！！！！。另外的小問題就是給投稿者的工作量/績效統計帶來不便，明明是去年的工作量怎么體現的是今年的時間，萬一領導復查，怎么說清楚呢。
結論，再也不向此刊投稿了。
轉自InfoQ：http://www.infoq.com/cn/news/2009/09/study-multitasking-performance
----------------------------------------------------------------------------------------------------------
斯坦福大學上個月在Proceedings of the National Academy of Sciences學報上發布了一個研究結果：“媒體行業中多工人員（multitasker）的認知控制”，強調指出一個顯而易見的事實：從效率的角度考慮同時從事多任務，絕對會影響工作效率。該研究審視了IT領域中一個廣為人知、卻常常為人忽略的現象：不斷出現、正在發生的多任務工作方式。敏捷實施者們這樣寫：這下可算有理由讓團隊只開發一個產品了，而且只能有一個產品負責人——將時間花在多個任務之上絕對是效率低下的工作方式。
Wired雜志指出：雖然其他研究重點關注多任務工作方式的眼前效果（比如：辦公室里的工作人員經常檢查郵件，這種情況下的工作效率），該研究提出了一個不同尋常的問題：“要是人們總在使用多任務工作方式會怎么樣？”Stanford的研究者Clifford Nass、Anthony Wagner和Eyal Ophir調查了262名學生的媒體消費習慣。19名使用多任務方式最多的學生和22名多任務方式最少的學生此后參加了兩個電腦測試，集中精力完成手上的測試。
他們使用了一些標準的心理測試指標，研究結果顯示出：經常在多個信息流之間轉換的學生，他們會在e-mail、網頁、視頻、聊天和電話之間來回切換，他們取得的進展遠低于不怎么采取多任務方式的學生。更令研究人員驚訝的是：在任務切換能力的測試上，“重度媒體多任務人士”表現更差，“似乎他們過濾不相干任務的干擾的能力更差。”
該研究再次強調了認知科學家反復提到的事情：同時處理多個信息流的輸入被認為是人類認知能力的問題。
對于造成差異的原因——被定位使用多任務方式的人是不是先存在心智上的不健全，還是說多任務方式造成了這種情況——“這是一個需要投入上百萬美金才能回答的問題，可是我們沒有一百萬美金去取得答案。”Ness這么說。
Wagner接下來打算用腦部造影方法來研究多任務方式的神經學解釋，而Ness將會研究兒童人群在多任務習慣上的發展。
本文是對：
Linda Wilbanks. IT Productivity = ??. IT Pro, November/December 2009, pp. 64, 63
的總結。
文章探討了什么事生產效率（或工作效率，但并沒有深入，只是個引子），以及如何提高（員工）的工作效率。
文章開頭指出，“productivity”（生產力，此處譯為工作效率）通常被定義為生產效能(efficiency)、度量(metrics)，以及在生產過程中單位輸入得到的產出的衡量。但對IT人員來說，什么是生產效能呢？作者給出了一個非正式的定義“一個有效率的人是指那些能夠在指定的時間內以高質量的方式完成指定工作的人。”這引出下一個問題：我們如何做可以使員工更有效率？
作者援引Mr. Elgan在2009年4月5號的Computerworld那期中的一篇文章“Why Goofing Off at Work Boots Productivity"中的話說，
那些偷偷在Fackbook和Twitter上花少量時間的辦公室“懶鬼”(slacker)比那些全部時間都用來做工作的人能做更多的工作。墨爾本大學的研究人員在一項新的研究中證實了這種真實性。他們的研究發現，一般來說，那些為了個人原因在工作時間內使用Internet的人比不用的人效率高9%。
作者指出，盡管Mr. Elgan沒有指出這些研究者是如何衡量生產率的，但他給出了為什么那些在Internet上花費時間的人更具有效率的一些原因：
- 潛意識仍然關注于工作中的問題，解決方案通常會在隨后出現；
- “游手好閑”(Goof off)的時間是一段清理個人思想、消除個人顧慮的時間。在這一小段時間后，你會回來全身心的投入到工作中；
- 從項目或任務中的短暫休息也可能是在受教育（或學習），例如讀一些與工作無關的東西。這些信息有可能在以后幫你解決另外的問題。
作者接著列舉了一些管理者們在不鼓勵計算機游戲或網絡沖浪的情況下建議所采用的提高員工效率的方式：
- 給員工有意義的工作。
- 承認/賞識員工所完成的工作。
- 給員工為了最好完成工作所需要的工具。
- 批準員工休息。
- 給予員工尊重。
作者還舉了一個例子，說有個復有創造力的同事把鍵盤上的F1~F12都附加了新功能：
F1 Accurately reflect what’s in the building’s vending machines.
- F2 Display the current traffic report for the area.
- F3 Make every piece of software on your machine work exactly as advertised.
- F4 Play your favorite music to lower your blood pressure.
- F5 Bring up your favorite picture of the beach or of the place you plan to retire.
- F6 Show a running clock on how many hours you have left until you retire.
- F7 Show you where your kids or pets are (but be careful, this might not relieve stress!).
- F8 Automatically delete all emails that were sent “Reply All.”
- F9 Delete all meetings for the day, sending emails of regret to all attendees.
- F10 Show what your 401K balance was two years ago instead of today’s value.
- F11 Automatically start dinner/ESPN/CNN/soap opera (programmable to suit individual preferences).
- F12 Advance time to five minutes before quitting time on Friday of the current week.
作者最后指出，作為管理者，需要關注如何現實的鼓勵員工發揮他們最大的效率，還需要決定如何來優化工作環境。只要求生產效而沒有適當的管理支持和資源將適得其反。作者認為，不時地準備一塊蛋糕（不管什么原因）可以鼓勵團隊和溝通。
By the way：作者是美國能源部國家核安全管理局的CIO。
轉自：http://www.sciencenet.cn/m/user_content.aspx?id=275801
1個民工>2院院士
話說我國一特大型國有企業B從A國引進了一條香皂包裝生產線，結果發現這條生產線有個致命缺陷：常常會有盒子里沒裝入香皂。總不能把空盒子賣給顧客啊。沒辦法，B企業向國務院S部打報告，S部指定兩院和C9高校聯合設計一個方案來分揀空的香皂盒，于是組成了一個11人的科研團隊，計有：中科院院士1人、中國工程院院士1人、北京大學863首席科學家1人、清華大學973首席科學家1人、上海交通大學長江學者1人、浙江大學國家重點實驗室主任1人、復旦大學“國家杰青”1人、南京大學國貼專家1人、哈爾濱工業大學國家大科學工程主任1人、中國科技大學引智計劃1人，當中有海龜、陸龜、土鱉，還有博士后、博士、碩士、本科生，綜合采用了機械、微電子、自動化、x射線探測、微機編程等技術，花了100萬元，成功解決了問題。每當生產線上有空香皂盒通過，兩旁的探測器會檢測到，并且驅動一只機械手把空皂盒推走。
南方有個鄉鎮企業也買了同樣的生產線，四川老板發現這個問題后大為發火，找了個湖南的小工來說：你他媽的今天給老子把這個搞定，不然明天你給老子滾蛋......小工很快想出了辦法：他在生產線旁邊放了臺風扇猛吹，空皂盒自然會被吹走。
這個故事告訴我們:
1，知識不一定就是生產力，創造力和學歷、學識、學銜不直接相關。
2，能吹是多么的重要，院士也能吹出來。
3，民科是值得尊重的，應該與官科享受同等待遇。
4，再次證明人民的智慧是無窮的，歷史是群眾創造的，是普通的勞動人民創造的。
本文是對Steve Vinoski. Multilanguage Programming.
IEEE Internet Computing, Vol. 12, No. 3, MAY/JUNE 2008, pp. 83-85 的總結。
本文的主要觀點是：在軟件開發中，要為特定的任務選擇最合適的開發語言。
作者首先介紹了在軟件集成和軟件開發中涉及的術語/技術浩如煙海，但是開發者卻只堅持某種技術，而必須使用其它技術來解決問題。這種現象在開發語言領域也是一樣。開發者總是使用自己喜歡的語言，而非解決問題最優的語言，會造成設計方案的不優。
作者指出在日常開發中了解和使用多種編程語言可以帶來顯著的好處，因為沒有任何一門語言適用于解決所有問題。而語言的存在也主要是由于它適于解決某些特定方面的問題（在解決某些問題方面比其它語言好），因此，不斷有語言出現和消亡。在編程語言設計和開發中涉及許多需要權衡的因素，因此，這為許多不同的方案和變體預留了空間。
作者指出，大部分單一語言開發者傾向選擇用于通用目的的語言（像Java、C++等），而不是特定的編程語言。通用的編程語言可用于解決更廣范圍的問題，但它們通常都是提供的折中的解決方案，不是太好，也不是太壞。當然，一些單一語言開發者盡力去挖掘語言的高級特性，來將語言的能力發揮到極致，但這些程序員仍然受制于這門語言實際的限度。
作者指出語言的選擇對開發效率是一個重要因素，選擇正確的語言所帶來的開發效率的提升是巨大和值得這么去做的。作者以對XML的處理為例闡述了此觀點。通用語言，例如Java在處理XML方面沒有專門設計上的支持，這使得開發人員在使用通用語言處理XML方面忍受這種不匹配，來進行拙笨的開發，造成非優的解決方案。在這種情況下，為了提高效率，他們通常采用一些代碼生成技術，把XML構造塊影射為靜態編程語言的構造塊（通常是類）來盡量緩解這種阻抗，即便如此，這種方式仍然是十分脆弱的。因為把高度靈活的XML構造塊轉化為嚴格的靜態的數據類型很容易造成彼此版本的不匹配。XML文檔的任何改變都需要新的代碼生成、重新構建、....這使得通過代碼生成獲得的一點點好處又被不斷維護帶來的成本所抵消。相比之下，Python、Perl、Erlang等語言都提供了XML處理模塊，甚至還帶版本化功能。更好的像ECMAscript for XML (E4X)和Scala，提供了對XML字面量的支持支持，開發人員可以直接在語言語法中寫XML。消除了阻抗，帶來了更簡化的代碼和更清晰的功能。
作者指出，選擇適當的語言所帶來的效率的提升還體現在對代碼的維護上。作者援引Fred Brooks在《人月神話》中引用的的研究發現說，所需開發和維護的工作量與指令的數目（可以理解為代碼行）是指數關系，而且這與所采用的語言無關。假設這個指數值是1.5的話，那么如果代碼行是原來的3倍的話，那么就需要5倍的開發和維護成本，如果代碼行變為原來的5倍，就需要11倍的開發和維護成本，如果代碼行變為原來的10倍，那么就需要32倍的開發和維護成本。選擇正確的語言，不僅可以減少代碼行，更快的提供解決方案和對需要的響應，這個過程可以變為積極的循環，更少的代碼帶來更好的缺陷和更容易的增強（維護），這又使得用戶更高興，提供免費的廣告宣傳和反饋，進一步促進軟件的發展。
作者指出，多語言編程的一個問題就是如何使它們協同工作。這可以分為兩類。如果是用于分布式應用集成（即不同的應用用不同的語言），那么網絡本身就通過協議提供了一個中立的方案，可以通過網絡消息等。如果不是分布式應用，當前的主流開發語言，比如微軟的CLT（公共語言運行時）所支持的語言越來越多，命令式的、動態的、函數式的，或腳本的。類似的，JVM也從一個單語言平臺演化為一個可以支持許多語言的平臺，包括JRuby、Scala、Groovy、JavaScript、E4X、Jython和其它的。而且，在JVM上，這些語言都容易學，因為都是基于字節碼，這些語言可以與Java進行互調。因此，JVM提供了一個非常好的方式來為應用的不同部分選擇最適合的語言。
作者還指出目前阻礙多語言編程的因素主要有兩個：一個管理因素；另一個開發者認為學習新語言難度很大。對于第一個因素，管理者通常認為只采用一種語言易于管理，因為大家都用同樣的語言，可以容易的替換開發人員，而且某個開發人員寫的代碼，大家也都能看懂，避免陷入只有少數人才能看懂和維護的局面。作者認為這種管理者對軟件開發和維護所涉及的成本沒有充分考慮。在一個JVM或CLR基礎之上，選擇合適的語言可以減少代碼規模和開發維護的工作量，從而降低系統的總成本，而且，較小的系統需要更少的開發者，這又是一個巨大的成本減少。對于第二個因素，相比通用語言來說，那個特定的語言，像Lisp、Python等都很簡練，核心概念并不多，初學者可以很快發現它們更具有生產力，而且，以往語言的經驗可以幫助你學習新語言。如果你掌握的語言越多，你就能更容易的學習一門新語言，也能發現解決問題的最好方式。
最后，作者以“畢竟，難道我們真的認為我們已經學到我們所需要的最后一門（終極）語言了碼？”結尾。
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
歡迎您對自己所在的開發組織對于多語言編程、融合的實踐和經驗發表看法，謝謝！
今天是部門年會活動的日子，活動項目：滑雪、年夜飯、卡啦OK
第一次學滑雪，是挺興奮的，11點鐘開使滑，地點林海滑雪場，剛開始是50多米的小短坡, Easy,吃完午飯，開始在200米的高坡滑，跟頭栽了不老少，也是長了不少經驗。爽！,就是膝蓋太累了...
晚上又是一頓豐盛大餐....
1. 提供了磁盤分區 - 空間方法
在File類中增加了以下方法：
public long getFreeSpace(): 返回一個分區剩余空間
public long getTotalSpace(): 返回一個分區總空間
public long getUsableSpace(): 返回一個分區已用空間
注意，以上File指代的虛擬路徑必須是盤符，否則返回0。
2. Splash Screen
Mustang對于Splash Screen的實現是一個用來顯示gif（可以是動畫式的）,PNG, jpg圖片的沒有修飾的窗口
使用方式：
在java命令行中加入 -splash 選項,示例如下：
java -splash mypic.jpg HelloWorld如果你的類是以jar的方式來運行，那么可以在jar文件的MANIFEST.MF文件中加入如下的一行：
SplashScreen-Image:mypic.jpg你也可以在命令行中寫：
java -splash:mypic.jpg -jar helloWorld.jar
這里用的圖片將替代MANIFESET.MF中定義的圖片（如果有的話）
為了實現自定義的Splash Screen界面，你可以使用如下的方法：
//使用SplashScreen的靜態方法獲得SplashScreen對象，然后自定義
SplashScreen ss = SplashScreen.getSplashScreen ();
if (ss != null)
{
// 自定義代碼。
}
在SpalshScreen中還提供了如下方法，具體使用請看JDK或訪問sun網站
public Graphics getGraphics()
public URL getImageURL()
public Dimension getSize()
public void setImageURL(URL imageURL):
public void update()
值得注意的是：你必須使用 -spalsh選項或MANIFEST.MF的方式來調用SplashScreen，
否則修改是無效的。
昨晚，回到宿舍，正好趕上中央4套在播《名將之約》，這次邀請的名將是現任中國乒乓球隊總教練，劉國梁。
自己小時候就很喜歡乒乓球，到現在也是一樣，因此對于此類人物，自己是欽佩有加，更何況劉的輝煌戰績，在國內也是先有人出其右。本月十號，就是他三十歲的生日，以近而立之年的他，已經是中國乒乓球的總教練，讓人感覺前途不可限量，要登上這個高度是非常之不易。
今年，我也已經27啦，時光飛逝，轉眼就會到30歲的那一天，作為程序員這個行當中的一員，這個年齡雖然不是很大，但絕對不小，自己的明天在哪里？
30歲能達到什么高度？35，40呢？也許每一個IT人都會思考這個問題，當然也許有些牛人已經是扶搖直上九萬里，不必憂心此類問題。
我們的公司很大，部門也很多，好幾千人的規模，項目經理很多很多，而公司級的項目經理，也就是資深項目經理，再加上部門的領導，什么技術總監，項目總監，部長，經理......
人，只有踏踏實實的把他目前的工作做好，才能不斷提升自己，我從不懷疑這樣的真理。
今天又抖出這個老生常談的話題，一是有感而發，再則警示自己：拋棄浮躁，潛心修行。
Oracle ADF（Application Developement Framework)是一套快速開發企業級J2EE的MVC框架. Oracle在Model層和業務服務層上提供的缺省實現對開發基于數據庫的應用提供了極大的便利，尤其是它的ADF BC(Business components),這個微型的MVC框架提供了直接映射數據庫表的能力，結合View端的展現(Oracle 提供了桌面端Swing/JClient和Web端UIX的實現），開發起來就如同用Borland的數據感知控件一樣。
Spring目前是J2EE社區一個比較火的框架，應用的比較廣，那如何進行二者的有機結合呢？
我們已經習慣了Spring的IOC框架，方便的使用getBean()方法來獲得我們想要的對象，因此,如果能通過Spring來生成需要的對象，然后把這個對象注冊為Data Control（Oracle中數據感知組件），這樣就可以利用ADF BC的威力來快速構建一個數據庫應用。問題的關鍵就在于ADF為每一個data control指定了一個工廠類屬性，而這個工廠類屬性的實例值需要我們用Spring來生成，就OK了。舉一個實際的例子：
在Spring中，我們定義了如下的接口：
package nl.amis.spring.hrm;
import java.util.List;
public interface HrmService {
public void setEmployeeDao(EmpDAO employeeDAO);
public List getAllEmployees();
public long getSalarySum();
}配置文件為：
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<bean id="dataSourceDBDirect"
class="org.springframework.jdbc.datasource.DriverManagerDataSource"
destroy-method="close">
<property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
<property name="url" value="jdbc:oracle:thin:@localhost:1521:orcl"/>
<property name="username" value="scott"/>
<property name="password" value="tiger"/>
</bean>
<bean id="employeeDAO" class="nl.amis.spring.jdbc.EmployeeJdbcDAO">
<property name="dataSource">
<ref local="dataSourceDBDirect"/>
</property>
</bean>
<bean id="hrmService" class="nl.amis.spring.hrm.HrmServiceImpl">
<property name="employeeDao">
<ref local="employeeDAO"/>
</property>
</bean>
</beans>在Oracle JDeveloper開發環境下，我們找到
nl.amis.spring.hrmServiceImp這個類，然后用菜單命令把它注冊為一個Data control組件。這個新生成的Data control缺省名字是：HrmServiceImplDataControl,查看它的屬性，有一個Factory class屬性，找到這個屬性所指的類,修改如下源碼：
Object bean = oracle.jbo.common.JBOClass.forName(beanClass).newInstance();上面的代碼就是生成HrmServiceImpl對象的代碼，把它改為：
ApplicationContext springCtx = new ClassPathXmlApplicationContext("SpringConfig.xml");
Object bean = springCtx.getBean("hrmService");這樣主要工作就OK啦，剩下的就是修改一下Data Control的配置文件（在注冊成為Data Control后生成的同名.xml文件），修改
<content>中的<AccessorAtribute>部分，把id改為：allEmployees; BeanClass 改為nl.amis.spring.hrm.Employee; IsCollection="true"; Type改為java.Util.List.
以上修改表明我們需要的是通過employeeDao獲得的Employee的集合，把這個結合作為結果集應用到ADF BC中。
英文原文出自：
http://technology.amis.nl/blog/index.php?p=765