JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Java 文章和新聞 » Java電子報  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友   
reply to postflat modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 Java週報 / 2003年7月24日出刊
moliwang

用嘴巴打嘴炮比用鍵盤打嘴炮要來的務實

版主

發文: 1215
積分: 6
於 2003-07-25 00:12 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
~~~~~~~~~~~~~~~ Java週報 2003年7月24日出刊~~~~~~~~~~~~~~~

如需圖文並茂PDF版請到以下網址下載:
http://www.javatwo.net/javaweek/history/javaweek20030724.pdf

*************************************************************

活動快訊> JavaTwo 兩人同行同享優惠

洪志鵬專欄> 神探不出門,能知天下事 (上)

獨孤木專欄> People Management(中)

新課快訊> 利用Netbeans/Sun ONE Studio開發Java應用程式
(7月28日到8月1日)(學生半價優惠)

爪哇教室> 剖析Java Event-Delegation Model(下)(作者:林錦陽)

課程訊息> Java手機/PDA程式設計進階 (8月5日到8月7日)

課程訊息> Java網路服務程式設計進階 (8月20日到8月22日)

課程訊息> 使用 Macromedia JRUN 建立 J2EE 應用程式
(7月28日到7月30日)
========================================================

活動快訊> JavaTwo 兩人同行同享優惠

JavaTwo 活動一推出後反應熱烈,許多來不及在搶先報名的朋友紛紛
來信表示希望能夠延長報名時間,為了嘉惠大眾特別推出兩人同行同
樣可以享有優惠價,社會青年價: 3500元, 學生價: 2500元, 必須是
一起報名同時繳費才可以享有優惠價喔!

一年一度的「JavaTwo專業技術大會」, 於2003年8月12、13日在
台北國際會議中心盛大展開。歷年由Sun舉辦的「JavaTwo專業技術
大會」皆吸引來自全台超過千餘位最頂尖的程式開發菁英共襄盛舉
。今年的JavaTwo年度科技盛會,更不容您錯過!

JAVA將成為一種統合的力量,為任何與Web相連的設備 (行動手機、
醫學設備、set top box乃至於伺服主機等) 提供更大安全性、生產
力、互通性和更強大的處理能力。JAVA[tm]已在全球掀起極大應用
風潮,為開發者、被授權者、企業乃至於消費者提供高附加價值,
並為整個Java社群帶來源源不絕的商機!

「JavaTwo專業技術大會」活動將涵蓋最新的技術發展趨勢,商業
解決方案,及Java應用科技發展等,兩天時間內完整呈現﹗

時間:92年8月12日至8月13日 每日上午9:00至下午5:30
地點:台北國際會議中心全館
活動網址:http://www.javatwo.net/Event/j2/2003/

* 特惠價:  NT$4,500.
  兩人同行:每人  NT$3,500.

* 學生特惠 - 民國68年次(含)以後出生之學生:
學生價:    NT$3,500.
兩人同行:每人   NT$2,500

必須要同時報名以及繳費喔!三個人以上也可以享有優惠價.
請按照一般程序報名, 必請於報名後將您的報名表回傳或者是用
E-MAIL 的方式給 JavaTwo 小組收, 告知你是和哪一位一同報名,
以便我們可以確認您的資料.
傳真電話: (02)2363-9479, E-MAIL:JavaTwo@mindwork.com.tw
請待JavaTwo小組與您電話或E-mail確認過即完成繳費及完整報
名手續。
立即報名: http://www.mindwork.com.tw:8080/students_system/mainPage.jsp
報名截止日: 7/31(必須完成報名及繳費才可享有優惠)  

*凡報名學員皆贈送精美JavaTwo紀念背包及限量T-Shirt 一件。
*本活動備有 「JavaTwo接駁專車」
<http://www.javatwo.net/Event/j2/2003/howtogo.html>,歡迎
多加利用。

今年的主講者包括侯捷先生、葉秉哲先生、蕭松瀛先生、蔡學鏞
先生、王建興先生、黃富鴻先生、歐宣修先生、胡岳偉先生、朱
仲傑先生、恆逸資訊技術總監孫三才先生、耿維德先生、東海大
學周忠信教授、大同大學鄭福炯教授、Borland李匡正先生、資策
會顧忠信先生、戴玉佩小姐、意藍科技劉保國協理、昇陽電腦王
森先生、洪志鵬先生,以及Macromedia、Nokia、Oracle、Novell、
Veritas等公司的技術專家們。

* 詳細的各場講座資訊請至活動網站上查詢 *

http://www.javatwo.net/Event/j2/2003/

--------------------------------------------------------------
洪志鵬專欄> 神探不出門,能知天下事 (上)

台灣教育改革的問題現在又吵得不可開交,現在好像演變成最新的人民
公敵。教改包含的議題千頭萬緒,在這篇文章裡我想討論的只有建構式
數學這一項。建構式數學這個主題我記得在幾個月以前也是很多人在討
論,但是大家也清楚我們的媒體生態,一個議題再怎麼重要也吵不了多
久,這些記者已經被訓練成只會湊熱鬧、照單全收、頭腦簡單的轉述者
,可憐的社會大眾只有任由這些低水準的媒體來操弄我們每天收到的訊
息。所以前一陣子建構式數學吵了半天,好像真的變成落水狗,教育部
也改口說這個東西不是一定要教。但是我覺得很奇怪,每次發生什麼問
題,大家只會跟著瞎起鬨開始交相指責,但是真正這些事情的源頭,或
是講得明白一點就是罪魁禍首,都很少人會去追究。

也許你會說這些都是專業的東西,而且又是將近十年以前開始的東西,
我們哪能夠這麼容易去追根究底,也沒有這麼多閒工夫去查資料找答案
。其實我們可以向幾位偵探小說作家筆下的神探來學習。偵探小說家筆
下的神探有很多種,一種是像福爾摩斯這樣拿著放大鏡仔細查看所有蛛
絲馬跡,也有像阿嘉莎•克莉絲蒂(Agatha Christie)筆下靠”灰白色
的腦細胞”和經由跟關係人詳細訪談來破案的白羅,另外一種特殊的類
型,就是美國作家傑佛瑞•迪佛筆下的「神探萊姆系列」,這個系列中
最有名一本的就是被拍成電影的「人骨拼圖」 (the Bone Collector)。
在片中由黑人影帝丹佐華盛頓飾演這位全身癱瘓的刑案鑑識專家,根本
就沒有辦法移動。他躺在床上靠著豐富的知識和記憶,光是動動手指移
動軌跡球來操作電腦,就可以破大案抓到罪犯。我們的外在條件都比他
要強,但是也可以學習他神探不出門能知天下事的本事。我們的武器不
是別的,正是天下無敵無所不在的高科技-Web網際網路。

網路上有個超級情報員,正是鼎鼎大名的Google。它的網站上蒐集的全
球超過三十億的網址的資料,所以這正是一個最佳的線上資料庫。我們
要找什麼資料,只要是打上這個字(中英文都可以),就能夠將它在網路
上出現過的資料找出來。不少自以為可以在網路上隱形,在BBS上用匿
名亂罵人的人,在很多時候都可以藉由Google的幫助,找出這些像蟑螂
老鼠般躲在陰暗角落傢伙的真實身份。現在要來查教改的起源,或是建
構式數學當時是怎麼成形的,光是在Google上就可以找到許多資料。

Google有個自動程式每天二十四小時不間斷地拜訪全球的網站,把網站
上的資料做成索引,所以就可以納入搜尋的資料庫,別人就可以找到這
個網站上的資料。相信使用過的人都見識過它的厲害,不信的話你可以
上到Google的網站,打上你的中文名字試試看,相信你就會親身體驗到
它的神通廣大。

除了對使用者免費的Google之外,我們也有幾個收費的線上新聞資料庫。
像是中時電子報提供一個月內新聞線上查詢免費,另外也有整理了從1997
年一月一日以來的新聞,一年收費大約一千多塊,可以有不限次數的全
文查詢。聯合報的聯合知識庫的年費要兩千塊,每次查新聞全文還得扣
點數,平均大概每篇新聞的全文要花五塊錢。但是他們號稱整理了五十年
來聯合報系的報紙內容,所以畢竟還是一個很豐富的資料來源。

藉由這些線上工具的幫助,我就花了一些時間去尋找跟教改相關的新聞。
首先我想找當時教改和建構式數學的起源,就打進去關鍵字,然後時間
從遠到近來排序,很容易就列出一缸子資料。經過篩選整理之後,找到
以下幾則來跟大家分享一下。

一開始是幾段跟當時的教育部長吳京先生有關的新聞:

「對於備受批評的建構式數學,吳京承認他是在看到媒體批露建構式數
學缺失後,才回頭去查是那任部長推行,沒想到,竟是自己任內政策。」

「吳京坦承,他根本不知道何為建構式數學,他是直到立委及媒體質疑
建構數學的問題時,才發現建構數學課程綱要是在他任內公佈實施,而
且在他歷次巡視基層時,也未聽見學校或教師反映有問題。」
【2002/11/21 民生報】

看到這一段話,大家會不會嚇出一身冷汗?堂堂的教育部長,然後當時
又被媒體捧成什麼點子王,搞了半天原來自己都搞不清楚在做什麼。什
麼叫做巡視基層時沒聽過學校或教師反應有問題?那麼這樣的巡視基層
有什麼用?都是拍馬屁的校長安排去看樣板班級耍猴戲,看小朋友排隊
拍拍手齊聲高呼部長好,然後對著跟屁蟲媒體的鏡頭發表感言,這樣的
巡視基層跟皇帝出巡有什麼兩樣?我記得很清楚,當年電子雞正流行的
時候,這位吳部長在為服出巡的時候被記者問到這個問題,他反應很快
地說:「那麼學校可以設個養雞場啊。」這下子不得了了,點子王的妙
點子馬上又被捧上了天。就是這樣愛作秀,就是這樣不切實際,現在才
會搞成這個樣子。

看到這裡,這位部長的意思是說雖然他幹過教育部長,但是現在大家在
罵的教改跟他一點關係也沒有。奇怪的是在Google上又找到另外一篇是
康軒教育雜誌第34期上面的專訪,當時是1999年12月,吳京部長下台兩
年的時候。在這篇專訪裡有這麼幾段話:

「過去在教育部所做的各項教改方案,讓教育動了起來,的確也對臺灣
教育帶來很大的衝擊。過去擔任教育部長的二十個月,是我們中華民國
教育史上最活躍的一段期間。」

「九年一貫不僅是在我任內規畫的,九年一貫的名詞也是我提出來的!」

「教改要持續不斷的做下去,速度要快,不但要推行以前的政策而且還
要快速的推行;不僅要放在自強號上,還希望有更多的自強號在這軌道
上,全面快速來推動教改。教育部也要繼續推動更多元化的教育政策,
大家共同來支持!」

大家看看,在1999年教改帶來的負面影響還沒有冒出來的時候,講起話
來是如何地豪氣干雲,多麼洋洋得意。現在教改變成過街老鼠了,點子
王馬上縮起頭來,不但翻臉不認帳,還把責任全部推給別人。沒事的時
候全力攬功,出了事馬上推得一乾二淨。這樣的官員,看了只會讓人搖
頭。

十年以來換了六個教育部長,從1993年郭為藩時代開始研議建構式數學,
到1996年吳京部長的時候神不知鬼不覺連自己都不知道地確定這是標準
教法,然後從此開始實施。1998年接棒的林清江部長因病過世後交給楊
朝祥,到公元兩千年政黨輪替後曾志朗部長上台,在他任內問題才爆發
出來,然後才公開宣布建構式數學不是唯一的標準。最重要的教育政策
是這樣制訂和執行的,我們的教育改革會成功才有鬼。

另外一個重點是,建構式數學這一套教法當時是哪些人推出來的?他們
是不是有藉著推廣建構式數學得到什麼好處?

這個問題,藉由我們王牌大間諜Google的幫忙,再加上以上提到那兩家
收費的報紙資料庫的佐證資料,答案也是白紙黑字無所遁形。我們下星
期再繼續談。(待續)

--------------------------------------------------------------
獨孤木專欄> People Management(中)

Keep Everybody Busy
------------------

吉娜:布魯斯,我看那個溫蒂,上班時間一直在玩ICQ,下班時間一到
人就跑得跟飛的一樣?這樣不行喔。

布魯斯心想,溫蒂不是在寫操作手冊的嗎?系統根本就沒有寫好,她要
忙什麼?況且她已經去支援總機啦。:我會跟溫蒂好好討論這個問題。

吉娜:我們不允許有人idle。公司的財務這麼吃緊,每一分每一毫都要
妥善運用。如果有一個人idle在那裡,公司等於就少了一份生產
力。這樣我們怎麼對股東交代呢?

我小時候也覺得這種理論是正確的。領人家薪水,本來就要在上班時間
鞠躬盡瘁嘛。所以要讓每個人都要發揮最大的生產力。問題是經驗越多
了以後,就越不這樣認為。我通常看起來最沒有生產力的時候,都在思
索一些可以改善生產力的問題。有些時候花太多時間去做,就會花太少
時間去想。此外,對於最沒有生產力的員工來說,你最沒有辦法找事情
給他們做。因為什麼事情他都做不好。

為了要讓這些人不處於idle狀態,你要找個有經驗的人來帶他。結果就
跟找個人揹個六十公斤的沙包去跑步一樣。沙包是會跑了,可是終究是
個沙包,一放下來就不會動了。

那也就算了。問題是這個揹沙包的人就會鐵定跑不快。跑久了還會陣亡
。所以有些時候,讓沒有能力的人閒著,其實對於整體生產力是有幫助
的。況且如果manager的重點都擺在怎麼讓這些沒有生產力的人發揮生產
力上面的話,他就不會有時間花在怎麼讓這些有生產力的人可以工作的
更好,更愉快。這對團隊會是好事嗎?我不這樣認為。

另外一個keep everybody busy的壞處在於

公司會試著同時接下超出他產能可以負荷的工作。以追求每一部份的資
源運用的最大化。

因為工作總會有要交接的階段,軟體開發尤其是如此。分析做完了做設
計,設計做完了以後就寫程式寫測試個案。系統分析師寫完分析文件交
給下一關以後,就會比較空閒。通常我們就會幫他另外找事情做。所以
通常就會有很多個專案同時在進行。

為了要不讓任何resource idle,如果有一個專案的schedule發生變化,
就會有人暫時沒事做。所以通常就會接下超過現有人員可以承受的專案
,這樣就可以確定任何時候,每個人都有事情做。所以呢,我們就會有
一個超出我們產能的需求要去滿足。而resource就會隨著工作的進度變
得紛亂,到最後變成嚴重不足。

Resource不足時,你就會讓比較貴的人力去做比較廉價的工作。所以高
階主管變成要自己等候在影印機前面去影印,因為沒有工讀生可以使喚


在有工讀生的年代,影印一張紙的成本等於租影印機的成本攤銷,加上
工讀生的薪水。現在影印一張紙的成本,等於租影印機的成本攤銷,加
上昂貴工程師,甚至是高階主管的薪水。這好像怎麼算都不划算。問題
是在資源不足的情況下,這種事情總是一而再再而三的發生。而我們從
損益表上,只會看到砍掉了一個工讀生的薪水。因為那些砍不掉的人,
薪水會一直掛在損益表的費用部分。至於他們領薪水做什麼事情,這不
是損益表關心的重點。

Keeping everybody busy的最後一個壞處在於multi-tasking:

「一個人在同一時間內,要處理多個不同的工作。」

Multi-tasking
-------------

開發軟體其實是一種經過思考然後消化的活動。一個人必需要花時間
去了解並思考目前所面臨的問題,依照你的經驗,去整理你的想法,
最後以各式各樣的模型,還是程式語言,來描述這個轉化的結果,才
能順利地找出解決方案。這跟做愛差不多,你需要培養情緒,經過前
戲愛撫之後,加上身體健壯與感官刺激雙重配合之下,才能順利地做
完你想做的事情。

然而對於某些關鍵的工作來說,我們常常會需要某個重要的超人參與
專案的開發。問題是超人通常都忙著拯救世界,所以多半只能在很短
的時間內,蜻蜓點水地幫忙一下,或是指點一下迷途的羔羊。這個時
候問題就來了,對於客戶來說,如果發現超人只是偶爾拯救一下地球
,馬上就會有不斷的抱怨。

如果一個應召女郎,跟客人辦事到一半,忽然說:『對不起,我要轉
檯,隔壁桌來了另外一個老主顧。』就硬生生地中斷這個快樂的過程
,跑去接待另一個客人。你想這個客人會高興嗎?還會高興地付你錢
嗎?有經驗的人告訴我們,最少你也要完成一整個回合,才可以抽身
。否則等你回來時,雙方還得要重新培養情緒,才有辦法繼續辦事下
去,更不用提心裡的那股不爽了。

然而在許多軟體公司裡,就是不停地上演這齣戲碼。他們先打著美女
的招牌,要求比較好的價碼,等到要辦事時,再派一個年華老去的大
姊來陪你。每次客戶問美女在哪裡?軟體公司就把美女找來坐坐檯。
這也就算了,更狠的是,他們還要求客戶準時付美女加上大姐的坐檯
費。

對客戶而言,這種軟體公司,就好像拿了錢,可是跟你做到一半就落
跑的小姐一樣可惡,等到下一次機會來臨的時候,又需要經過漫長的
前戲,才可以挑動已經冷卻的情慾,這不是令人十分不悅嗎?

即使是對於公司內部的開發團隊來說,老實說,也是同樣受傷害。只
是內傷在心裡,外表看不太出來。對於這些想要聆聽教誨的專案成員
來說,才剛開始覺得有一些領悟的時候,佛祖就跑去別家弘法了。下
次相逢,已是千載以後。這樣子怎麼了悟呢?

所以呢,我們不能忽略專案成員的轉換成本。一般人要把心思轉換到
可以很快地學習超人的想法,是需要一點前置的準備時間,還好除了
超人以外,其他人的時間其實都可以浪費。所以這些凡夫俗子可以花
比較多的時間調整心態,做好接客─不是,是學習的準備。平時多多
研讀經書,佛祖駕臨時,可能會比較容易頓悟。

然而對於超人來說,難道他就不需要任何調整與準備嗎?或許偶爾幾
次的轉換,是不需要太多的前置作業時間來準備。可是如果你讓他同
時在多個專案之間游走的話,還想要一直維持高昂的生產力的話,這
就跟要求一個男人需要連續來個十次,中間還不能有任何低潮一樣地
不可能。更不要說這些專案可能會散佈在不同的地點,同時接太多專
案的話,他有可能會需要從一個地點趕著到另外一個地點去,光是這
些交通時間累積起來,就會是相當可觀的資源浪費。

另外一個嚴重的影響是在於整體的等待時間。超人沒空時,其他人就
得等。其實不只是超人所負責的工作,有些工作只要一delay,project
鐵定就會delay,像這種工作都是等不得的。所以只要這些工作一有些
閃失,專案的開發時間就一定會拖得很久。接著整個專案的開發成本
,一定就會跟火箭一樣一飛沖天。

問題是如果一個人同時間接了很多工作,很容易就會因為分身乏術而
拖垮其他專案的進度。例如某甲可能有A、B、C三個專案的工作。每個
工作都要做10天。他做了專案A5天以後,B這個專案的PM跑來找他,要
他趕快去做B。所以他就做了B專案5天。接著是C專案的PM也來找他,
要他幫忙C專案解決問題。所以他就做了C專案5天。接著專案A的PM就
跑來追殺他,他就再花5天把A專案做完,同樣的戲碼上演下去,他花5
天把B專案做完,接著再花5天把C專案做完。

讓我們看看專案經理對於schedule的估計會死在哪裡。每個專案的PM
都想,如果某甲可以專心一志地去做的話,只要10天就作完了。問題
是現在A花了20天才做完,B花了20天才做完,C也花了20天才做完。依
照常理來說,有哪個PM會抓這麼高的buffer嗎?專案A的PM可能會想,
我抓個10%的buffer,所以這件事情應該可以花11天做完。專案B的PM
可能想是12天,專案C的PM可能抓了15天。好吧,結果是每個專案都會
delay。這還是在每件工作沒有轉換成本的考量下喔。某甲並沒有偷懶
,可是每個專案都會delay。

所以現在我每次聽到『你要花15%的時間在專案A,30%的時間在專案B,
55%的時間在專案C…』的這種說法,就想要打哈欠。數字是不會說謊啦
,不過隱藏在數字後面的理論真的是對的嗎?這樣做下去,真的可以
work嗎?

我小時候在學校裡面學軟體工程時,壓根兒沒聽過multi-tasking對於
專案會有多大的危害。直到到了職場以後,才開始領教到50%在專案A,
25%在專案B…的這種說法。這種分配資源的想法,對於大多數主管來
說,是非常直覺的,畢竟我們從小就是第一堂課上國文,第二堂課上
英文的這樣子長大。我想此刻在台灣的某個專案資源分配會議上,一
定還是會聽到類似的說法。可是符合直覺的事情並不一定是對的。
multi-tasking對於專案推行時的副作用,實在是不容忽視。我蠻好奇
為什麼在軟體工程或是專案管理的課程裡面,居然會忽略了這麼重要
的一個課題。

然而除了multi-tasking以外,我們還想了很多辦法,來浪費員工寶
貴的時間。那就是:

「把員工的時間浪費在沒有意義的事情上面。」

把員工的時間浪費在沒有意義的事情上面
-------------------------------------

會計 :布魯斯,你們部門的那個歐尼爾,已經兩個禮拜沒有填time
card了,這樣不行喔。

布魯斯:不好意思啦,我會趕快催他填。

布魯斯:歐尼爾,你已經兩個禮拜沒有填time card了。趕快寫一寫。

歐尼爾剛好寫程式寫到一半,忽然被電話中斷了思緒:喔。好。

五分鐘後,歐尼爾把上上個禮拜的time card copy一份,日期改一改,
送給了布魯斯。

布魯斯:歐尼爾,你上上個禮拜四不是有請假嗎?還有你上個禮拜不是
有出差到台中嗎?而且你charge的project code都填錯。

歐尼爾:Sorry,sorry。你把它退給我。

歐尼爾花了三十分鐘,仔細check他的email信箱,回想這兩個禮拜的行程
,填好了time card、假單、出差申請單、差旅費報銷單,還把相關的收
據通通都貼好,送給了布魯斯。歐尼爾被打斷了以後,大概花了一個小時
,一天以後,這些東西跑到了會計部。

會計 :布魯斯,你在差旅費報銷單那裡簽錯位置了。你拿回去叫歐尼爾
重寫一張啦。

布魯斯:不好意思啦,我會趕快處理…

衙門越多,官僚習氣就越重。我懷疑現代會計的基本假設,就是『每個員
工都有可能當賊,所以需要內部仔細地稽核。』當組織越龐大,裡面的官
僚越害怕沒有事做會影響工作保障時,就會努力設計出各式各樣的表格,
五花八門的單據,以免你做了一件僭越身分地位的事情。於是乎,即使是
一件小事,也會是每個部門都要會,每個主管都要簽。

當然,這也常常是因為政治上擺不平。每個主管,都深怕與他同級的競爭
者,會接觸到什麼他不知道的資訊,而會因此取得升官發財的秘訣,所以
一定都會想要在決策的過程中參一腳。

所以你用高薪請來的程式設計高手,還有專業經理人,就會拿他們寶貴的
時間,可能是一個小時好幾千塊錢的代價,為了公司一定會發給他們的三
五百塊,在那裡填寫單據或是簽名蓋印章。而這樣做的公司,通常還會對
於他們內部控制制度的嚴謹,感到洋洋得意。

另外一種時間殺手就是開沒有意義的會。公司一大,分權分的越散,就會
有越多人來爭取管轄權,人一多開會是很沒有效率的。特別是主管。有些
主管凡是遇到不是他所負責的業務,總喜歡提供良心的建議,厲害的地方
在於這些建議通常可以悖離邏輯,違反常理。根據我的經驗,只要人一多
,就一定會有人扮演這種神奇的角色。此外,大公司常常會找來沒有決定
權的人開會。看起來有決定權的人,又常常沒有肩膀,就會屈服於更上一
層的壓力。

布魯斯:關於網站的風格,我想請教一下貴公司是否有特定的想法?

西恩(IT部門主管經理):為了爭取時效,我想你們先做三種版面給我們查n ,我們會在下個月的主管檢討會議中,找時間請
高階主管背書。

兩個禮拜後,第一次檢討會議會前會。

西恩 :你們做的這三種版面我看了覺得不喜歡,我想請你們的網頁設計
師再設計幾個比較活潑的版面。

布魯斯:可是這是依據你們現有的網站風格設計出來的啊?

西恩 :我們現在的網站被人罵得亂七八糟的。你們還比照這個?你們要
做這種決定之前,要先問我啊。請你們的網頁設計師換一個比較
生動的顏色。

布魯斯:好吧,下個禮拜就是檢討會議了。我會請網頁設計師加班改出新
的版面出來。

西恩 :辛苦你們了,我們三天後再開一次會前會。我會找使用者方面的主
管琳達,還有我老闆潔西卡列席。

三天後,第二次檢討會議會前會。

琳達 :這是什麼東西啊?你們怎麼用了這麼花俏的顏色?

布魯斯:這是依照西恩的建議,我們希望可以用比較活潑的顏色。

西恩 :我只是建議而已,你們應該依據你們的專業發揮啊。

琳達 :這跟我們現在公司的其他網站風格根本就沒有align在一起。潔西卡
,你覺得呢?

潔西卡想,我應該想辦法罩一下西恩,不然場面不好看。對了,公司好像有
另一個部門有類似的規定:我記得公司的跨部門網站標準訂定小組,應該已
經定義出一份我們公司都應該遵循的網站風格標準。西恩,你是否有提供給
vendor參考?

西恩 :我並不知道有這份標準文件。

潔西卡:下回在做決定之前,可以先來問我。你可以去找跨部門網站標準訂
定小組的喬依思討論。我回頭把她的email寄給你。

西恩 :布魯斯,那就請你們依照那個標準來設計網站的新風格。

布魯斯:……..有標準可以遵循當然是最好的啦。(***,有這種東西不
會早一點拿出來?)

檢討會議當天。

大頭甲:這個字體怎麼這麼小?

布魯斯:這是依據跨部門網站標準訂定小組所訂定的標準所設計出來的。

大頭甲:我們這些人年紀大了,都有老花眼了,這字這麼小看不見啦。

大頭乙:對了,你們這個畫面怎麼還要捲動啊?我們這些老頭子要用滑鼠這
樣拉啊拉的,很不習慣也。盡量把內容都放在一個畫面裡面嘛。

潔西卡:對啊,對啊。這個敘述怎麼折行了?你們應該把欄位拉寬一點嘛。

大頭甲:你在點這個,我看看。好,你滑鼠不要動。好,這個滑鼠不要動的
時候,是不是可以出現什麼提示的畫面?告訴人家這個功能在做什
麼嘛。

布魯斯,可是在我們所拿到的標準裡面是禁止這樣的做法啊。

大頭甲:這樣子啊,潔西卡,你回頭幫我call個meeting,我來跟哪個小組的
成員好好討論討論。

潔西卡:沒有問題。

大頭甲:布魯斯,這個功能的提示你們先照著做,我們開完會以後,再告訴你
這個結果是什麼。

大頭乙:現在不是很流行什麼Flash嗎?你們要不要加個動畫?

大頭甲:對啊,我們可以…….

會場陷入了對於動畫效果的討論,大家各自表述自己喜歡的動畫。過了半小
時。終於結束了這個會議。所以布魯斯帶著需要把字放大,欄位加寬,可是
不可以捲動,並且還要加入最新的動畫效果的決議回去。

網頁設計師丹尼爾:這怎麼可能?我們怎麼可能把字變大,欄位變寬,可是
又不要捲動畫面呢?

布魯斯:我也這樣說啊,可是他們說,這是你們的專業,你們這麼專業的網
頁設計師一定可以辦得到的。

丹尼爾:是啊,我還會讓紅海的海水分開哩。…

隔了一個月,大頭們的老大,帶頭大哥來看這個系統了。

帶頭大哥:這個畫面怎麼開這麼久?

布魯斯:這個是因為上次開會決定要做flash動畫,讓我們的畫面更生動活潑
一點。

帶頭大哥:拿掉。我們這是跟供應商之間資訊交換的平台,做這麼多花俏的
東西做什麼?況且我們的供應商的頻寬都很有限啊。

大頭甲:大哥您真是英明。

大頭乙:布魯斯,我們只是要你們增加一些比較好看的效果,可沒有叫你們
要做出這麼大的檔案啊。布魯斯,你們是這個行業的專家,應該知
道不可以使用太大的檔案來佔用網路的頻寬啊。

布魯斯:可是Flash檔的size本來就會比較大啊,要做動畫一定就會有這樣的
結果啊。

大頭甲:我們又不是專家,你應該highlight這個issue啊。

布魯斯:…….

利用讓部屬開無用的會議,接著再用推翻部屬會議的共識,來證明自己的高
瞻遠囑,思慮周密,似乎是許多高階主管調劑辦公室生活的最佳娛樂。類似
這樣的決策過程,可能在現實生活中屢見不鮮。

我曾經在八卦雜誌上看過這樣的報導,唱片公司的企劃人員,為了幫新人取
一個響亮的藝名,經過多次內部開會討論,最後終於提供給老闆三個建議。
結果老闆去找他最喜歡的算命先生,另外取了三個名字,由老闆的小老婆從
算命先生的建議裡面,挑一個最喜歡的,這樣子就成了新人的藝名。接著藝
人大紅大紫,還一再感謝算命先生的神機妙算。

不過這還不是最糟糕的狀況。最慘的狀況是參加那種跨國的會議。某些大公
司特別迷信國外飛過來的consultant。所以在開會的時候,就會請consultant
蒞臨指導。畢竟外國人有洋槍有洋砲,除了人高馬大,船堅砲利以外,大腦
可能也會大一點。因此開會的時候,就會有人先用中文交談,接著為了讓大
腦比較大的外國人也了解會議的內容,就會有人用生硬的英文解釋,接著又
有人認為這個翻譯的人翻譯的不好,就會用更生硬的英文來解釋前面的人所
說錯的地方,最後consultant大概了解狀況以後,就會提出他認為最專業的
建議。

不過因為consultant通常經過層層轉述以後,不是非常了解來龍去脈,所以
他的建議通常就是吃這行飯的人,從小時候開始就已經聽爛了的廢話。接著
呢,就會有狀況外的人,把consultant的廢話,當成是神諭。為了避免大家
的英文太糟糕,就會用中文把consultant的英文再翻譯一次。接著還會有人
繼續指正中文的翻譯。好吧,這種狀況光用寫的手就打字打的很酸了,還要
繼續講下去嗎?

這種會開久了,可以忍住不打瞌睡的人,可以考慮到聯合國上班。每次遇到
這種狀況時,通常我就是負責對話的主角。每次開完這種會議,都會覺得壽
命大概折損一半。

另外一種常見的時間殺手就是過多的文件。SA要寫analysis document,SD
要寫design document,programmer要寫註解,tester要寫test case,test
result跟test report,project manager要寫各式各樣的plan,report,
以及meeting minute;每個人每個禮拜都要寫status report,time card…

軟體業可以說是專門生產文件的工業。生產沒有人有能力看的文件,以及訂
定無聊的標準,要求各式各樣的文件,並寫製作沒有力氣跟著最新的功能同
步更新的文件,就變成了這個業界的常態。在大多數的公司裡,真正必要的
文件可能都沒有人去寫,可是不必要的文件可能會汗牛充棟。而已經寫出來
的文件,大多數都跟不上版本更新的速度。所以內容通常是在描述歷史上的
某一天。而不同的文件,可能講的剛好是不同天。所以文件與文件之間,很
有可能彼此之間還會串不起來。

當然,有很多程式設計師就是厭惡寫文件。必要的文件,對於專案的開發絕
對會有幫助。生產不必要文件所花費的時間,會吃掉撰寫必要文件的時間。
所以在大多數的場合裡,必要的資訊總是被不小心遺漏了,可是不必要與過
時的文件,卻會一而再再而三地淹沒在我們的硬碟中。

有人說過:『錯誤的決策,比貪污更可怕。』對於資源的不當運用,確實是
許多軟體公司最大的問題。然而大多數時候,即使你覺得這樣的措施不好,
你可能還是覺得自己沒有能力改變這一切。要根除multi-tasking,得要建
立多大的共識基礎?要減少施加不當的壓力,高階管理者要更改多少行為模
式?要除去無用的數字管理,得要教化多少腐朽的大腦?要尊重員工的時間
,需要多麼成熟的工作態度?

這些都不是容易做到的事情。所以主管們通常能做的就是採取柔性的訴求,
例如

*鼓吹團隊精神
*激勵
*以身作則

鼓吹團隊精神
-----------

打造一支鋼鐵勁旅,並不是一件容易的事情。不過對於很多主管來說,他們可
以打的牌並不多。公司的人就是那麼多,找來找去就是那麼幾個鳥人,所以呢
,只能把幾個人硬湊在一起,組成一個雜牌軍。通常找人的狀況不外乎如此:

* *在某次的資源調度會議上* *

布魯斯:這個project我現在還需要5個programmer,coding 3個月,測試4個月。
還需要3個tester。

吉娜 :看來我們現在人力吃緊。布魯斯,你有沒有什麼建議?

布魯斯:programmer的話,歐尼爾跟史托雅柯維奇現在有空,我已經問過了。
我還需要3個人,我想要找布萊恩、韋柏跟諾威思基幫忙。

傑克森:不可能,布萊恩最少還要在我的project三個月。

尼爾森:諾威思基最少也還要兩個月才會從現在的project離開。這還是樂觀的
狀況。

艾德曼:韋柏也不行,他已經提出留職停薪,他打算去動膝蓋的手術。他膝蓋自
從上次受傷以後一直沒好。

布魯斯:那怎麼辦?我們還要不要做這個project?

吉娜 :有了,聽說最近剛進來有個叫做艾佛森的工讀生還不錯。

布魯斯:可是我們上次從波士頓找來的那個工讀生華克,根本就不中用啊,會不會
有同樣的狀況?況且說只有艾佛森,這樣也才只有一個人啊。

吉娜 :那先讓艾佛森頂這個位置。尼爾森,你要諾威思基一個月之內加班把那
個案子結掉,不要那副表情給我看。有問題,我負責處理客戶那裡。已
經上線這麼久的案子,沒理由我們要繼續support這麼久。傑克森,布萊
恩只能留一個半月。

傑克森:不行啦,最近這個案子要上pilot run,布萊恩不在,會出大紕漏。

吉娜 :對喔,布魯斯,布萊恩看起來是走不掉了。這樣吧,不然你先把艾佛森
放在你的project organization裡面,我們再找三個工讀生進來。我聯
絡一下華克。

布魯斯:我不要華克啦,他根本就不能算是一個developer,頂多算半個人。不
過我倒是聽說他同學皮爾斯還不錯啦。

吉娜 :那你把華克、皮爾斯、跟艾佛森放到project organization裡面,這樣
加上歐尼爾跟史托雅柯維奇,你就有五個人了。如果諾威思基可以加進
來,這樣就有六個人了。

布魯斯:可是華克、皮爾斯、跟艾佛森都是工讀生。這三個人頂多算一個半,加
上諾威思基我也只能算半個,這樣還差一個人。

吉娜 :有了,我找一下馬龍好了。他前一陣子想離職,我去勸勸他,請他再多
幫忙這個案子。

布魯斯:如果馬龍能來那就太好了。那我只剩下tester有問題…

很多時候,如果討論已經變成了誰是一個programmer,誰只能當半個,這種組隊
的方法,大概也組不出什麼夢幻團隊。

由於可用之兵有限,每個人的才智又有所不同。所以很容易就有勞逸不均的狀況。
主管如果對於每個人的能力了解又不清楚,就會把不對的人放到不對的位置上。接
著能做的通常是:

* *在某次專案的kickoff meeting上* *

布魯斯:我們的專案,有很多人都是初次合作,包含了華克、皮爾斯、跟艾佛森,
他們都是各國立大學的高材生。我想我們一定要請大家相互配合,發揮
團隊精神…

* *一個月後的專案進度檢討會議上* *:

布魯斯:馬龍,看樣子這些年輕小夥子還要麻煩你多指點一下。

馬龍 :那個華克,根本整天都在混,整天在哪裡混時間,不曉得在幹什麼。還有
艾佛森,做事情莽莽撞撞,不照規矩來。上次還不小心蓋掉我寫好的檔案
,還好我local有備份。

布魯斯:馬龍,既然我們是個team,你又資歷這麼深,就只好多麻煩你幫忙啦。我
們現在在同一條船上,你就發揮一下團隊精神,幫他們一把,我看皮爾斯
還不錯。

馬龍想,發揮團隊精神也沒領比較多錢,誰還管這些人這麼多:是啦,這個小子還
不錯。不過可惜可以來的時間有限。

布魯斯:是啊…

又過了一個月。

艾佛森:那個布朗在畫的是什麼圖啊,根本整個設計都不對,我們的功能才會有
這些問題。他到底懂不懂UML啊?

馬龍:這跟UML一點關係都沒有。布朗寫的spec已經夠清楚了,整個東西會寫錯都
是因為你沒有跟其他人好好討論合作的關係。

艾佛森:你怎麼可以這麼說?這樣說一點都不合理。我要求你向我道歉。

布魯斯從桌子底下踢了馬龍一下,看了馬龍一眼,求他先閉上嘴:艾佛森,你先
把你找到的問題列出來,現在布朗不在,單單聽你這麼講,我們根本也不知道事
情到底真相是什麼。我只知道tester找出了很多問題,而這些程式都是你寫的。
這不一定是誰的問題,可是我得要知道我們該怎麼解決現在面對的狀況。現在你
先整理出來你發現的問題。

艾佛森不發一語地走了出去,大力地關上了門。馬龍:布魯斯,你為什麼不讓
我講話?

布魯斯:為了維持團隊的和諧啊。馬龍,我知道你一直都是對的,可是你這樣
子會讓場面變得很僵。只好請你相忍為國了…

大多數人對於團隊的想法,其實都深受軍教片之害,那種要絕對服從命令,誓
死效忠,一個口令一個動作的團隊,其實在現實生活是不太容易存在的。大多
數團隊,都有那種好說話的人,跟不好說話的人。

好說話的好好先生其實跟個單細胞生物差不多,原則上他們會信奉『君要臣死
,臣不敢不死』的這種理念。所以只要跟他們鼓吹一下『要有團隊精神!』,
『犧牲小我,完成大我』『成功不必在我』這種觀念,就願意配合進行不可能
的任務。

不好說話的人通常都自認才高八斗,當然實際上並非總是如此。這些人的特點
就是原則很多,不願意配合。所以通常鼓吹團隊精神只會被他們嗤之以鼻。我
比較建議先吹捧幾句以後,再使用激將法。大凡自視甚高的人,多半都受不得
激。

鼓吹團隊精神,在企業內部通常就是把不好說話的人所推託出來不想做的事情
,交到好說話的人身上。這好像不是什麼很好的分工方式吧。

另外一個常有的想法就是要維持團隊的和諧。好像所有的衝突都不可以浮到檯
面上來,以免影響每個人對於團隊的信心。事緩則圓、相忍為國是這類主管常
掛在口上的名句。

這不禁使我想起很多黑幫電影。在很多這類型的電影裡面,兩個幫派之間起
了衝突,通常就是為了要搶地盤。對砍了一陣子以後,常常會有很多黑道大
哥出來講情,要大家賣他們一個面子,一笑泯恩仇。不過看了這麼多電影,
還沒看過有哪兩個幫派真的就從此風平浪靜。

為了強調團隊的和諧,變成鄉愿俱樂部,其實帶來的壞處遠大於好處。他只
會鼓勵人把事情掩蓋下來,而不是去尋找真正的答案。我個人覺得衝突是每
個團隊成員彼此利害關係不同,必然會有的結果。問題不在怎麼壓制衝突的
發生,而是在衝突產生時,怎麼樣可以找到一個解決的方法。不過對於大多
數的主管來說,要人家賣他一個面子,好像比真正解決問題來得省事多了。
反正我已經請你們要互助合作了,你們沒有團隊精神,怎麼能怪我呢?

團隊精神其實是需要長時間的相處以後才會產生的。人並沒有辦法plug &
play,即使可以,你在音效卡後面接螢幕,畫面絕對還是一片空白。我個人
覺得,專案經理需要製造彼此互助合作的機會。怎麼把對的人放在對的地方,
再讓這些人可以慢慢融合成為一個團隊,絕對是一個軟體專案經理人的首
要任務。光是講幾句要有團隊精神,大家要同舟共濟,這是無濟於事的。

此外,站在組織的立場上來說,我們對於團隊合作到底提供了什麼實質的
獎勵?如果只是『我們在下一次調薪時,會考慮這個因素。』或是頒發幾
張優秀團隊獎狀,其實誘因遠不及發給獎金、股票、認股權來得有效。如
果沒有實質的獎勵,團隊的成功與個人絲毫無關,這樣子的話,人們怎麼
會有動機想要協助團隊的成功呢?    (待續)

--------------------------------------------------------------
新課快訊> 利用Netbeans/Sun ONE Studio開發Java應用程式
(7月28日到8月1日)(學生半價優惠)

講師簡介
========
講師 : 王森 先生
學歷 : 交通大學 科技管理研究所
專長語言 : C/C++ , Java
專長技術 : J2SE, J2ME, Device Driver,Palm,Windows CE,EPOC
經歷 : 系統架構顧問,技術諮詢顧問
現職 : 專欄作家, Sun教育訓練中心技術顧問及講師

課程簡介
========
NetBeans(http://www.netbeans.org)是一個開放原始碼的標準Java
開發工具。而Sun ONE studio (http://wwws.sun.com/software/sundev/jde/index.html)
則是根植於Netbeans,專注於J2EE應用程式開發的官方標準開發工具。
本課程將使以NetBeans為基礎,教導學員如何開發Java程式,使學員具
有Java基礎程式設計的能力.然後再教導如何使用最新版的Sun ONE
Studio來開發J2EE應用程式。本課程將可以成為其他Sun進階課程的
基礎,本課程會贈送?峰出版社最新出版的新書-"從Visual Basic
到 Java 完全手冊"一本。

學習對象
========
任何想進入Java程式設計領域者.想學習利用Sun官方整合開發環境(IDE)
-NetBeans與Sun ONE Studio來開發Java應用程式者。想學習基礎Java程
式設計,或J2EE程式設計者皆適合此課程。

學習資格
========
*有任何程式語言的基礎即可

學習目標
========

1.Java程式語言基礎
2.學習使用最新的Netbeans 3.5 來開發標準的Java應用程式.
3.使用Sun ONE Studio 5來開發J2EE應用程式,包括Web應用程式、EJB,
以及Java WebServices

相關課程
========
學習前:SL-110 Java初階程式設計
:SL-275 Java程式設計

學習後:SL-351 運用 EJB 技術開發進階商業元件
DTX-310 XML Presentation
DTX-330 Java網路服務程式設計
DTX-340 Java網路服務程式設計進階

時 間 :7月28日到8月1日 每天早上09:30-12:00, 13:00-16:00
費 用 : NT$ 10,000 (含稅、含午餐) (Java週報會員享有九折優惠)

**慶祝在學學生放暑假,特別推出學生半價優惠方案,只要憑 **
** "在學學生證"即可以NT$ 5,000,超低價報名此課程。Java週報會**
**員九折優惠恕不適用 **

報名方式 : 週報會員請先到http://www.javatwo.net/javaweek/
登入會員後,到"課程訊息"裡線上報名,可免去重複填資料的麻煩喔!

--------------------------------------------------------------
爪哇教室> 剖析Java Event-Delegation Model(下)(作者:林錦陽)

***********************************************************
如需圖文並茂PDF版請到以下網址下載:
http://www.javatwo.net/javaweek/history/javaweek20030724.pdf
************************************************************

Java Event Dispatch之旅
-----------------------
在之前筆者已經把Java Event的來源以及dispatch的方向點了出來,接
著將繼續探討當EventQueue中的Event被EventDispatchThread拿出來之
後的dispatch過程。還記得前面提過EventDispatchThread如何把Event
dispatch出去的嗎?如果不記得的話,請往前回憶一下吧! 不管是什麼
Event,在它被丟往EventQueue時,有兩個Event的屬性已經被決定(id
和source),而EventDispatchThread會根據Event的source來決定接下
來要dispatch的目標,也就是發生Event的AWT元件。根據之前的討論,
dispatch的目標分成兩類,一個是Component,另一個則是MenuComponent
,為了方便起見,在此筆者僅以Component為例。

既然目標是Component,那麼首先當然是找Component.java囉!由於Event
最後是由source的dispatchEvent(event)這個method開始的,所以就從
dispatchEvent下手,結果發現dispatchEvent會再呼叫dispatchEventImpl
(event),從這個method當中,我們看到了Java對於不同的Event可能會
有不同的處理方式,為了簡化起見,筆者只針對正常Event Model
(normal-processing)的處理流程來作說明(也就是透過processEvent),
部分code如下。

void dispatchEventImpl(AWTEvent e) {
    …
// 3. Deliver event for normal processing
if (newEventsOnly) {
if (eventEnabledEnvelope) {
processEventEnvelope;
}
  }
  else if…
}
而processEvent會根據不同的Event物件繼續dispatch的工作,可能繼續被
呼叫到的方法為processXXXEvent(…),例如: processFocusEvent(...)、
processMouseEvent(...)、processMouseMotionEvent(...)、processKeyEvent(...)、processComponentEvent(...)。processEvent的部分code如下:
protected void processEvent(AWTEvent e) {
if (e instanceof FocusEvent) {
processFocusEvent((FocusEvent)e);
} else if (e instanceof KeyEvent) {
processKeyEvent((KeyEvent)e);
    }else if(…)
      …
}
接下來我們以processMouseEvent為例,code如下:
protected void processMouseEvent(MouseEvent e) {
    MouseListener listener = mouseListener;
    if (listener != null) { //檢查是否有已經註冊過的listener
  int id = e.getID();
  switch(id) {
  case MouseEvent.MOUSE_PRESSED:
  listener.mousePressedEnvelope;
  break;
  case MouseEvent.MOUSE_RELEASED:
  listener.mouseReleasedEnvelope;
  break;
  case MouseEvent.MOUSE_CLICKED:
  listener.mouseClickedEnvelope;
  break;
  case MouseEvent.MOUSE_EXITED:
  listener.mouseExitedEnvelope;
  break;
  case MouseEvent.MOUSE_ENTERED:
  listener.mouseEnteredEnvelope;
  break;
  }
  }
}
看到這裡,不知道各位讀者是否有那撥雲見日的感覺,原來從dispatchEven
t一路下來,一直到processXXXEvent才會透過已經被註冊過的listener來呼
叫對應的Event-Handler。這也就是為何在使用Event時,必須先以
addXXXlistener來註冊的原因了。再來,我們看看Listener如何在Source達
成註冊的動作!在Component.java中,有好幾個用來註冊listener的
addXXXlistener方法如: addComponentListener、addFocusListener、
addKeyListener和addMouseListener…等,因為Component是所有AWT元件的
老祖宗,所以這些用來註冊的方法,其實代表著所有繼承自Component的元件
,都能透過Event Delegation Model來handle這些Events(這其實就是物件繼
承的優勢)。由於這些addXXXlistener的行為大致相同,所以我們就隨便挑一
個來看囉,就addMouseListener好了:
public synchronized void addMouseListener(MouseListener l) {
  if (l == null) {
   return;
  }
mouseListener = AWTEventMulticaster.add(mouseListener,l);
newEventsOnly = true; //透過normal-processing的Event,newEventsOnly
//必須被設為true
  …//以下有一些是跟lightweight component相關的code
  …//不在本篇討論範圍內,所以就不多說囉!
}
嘿嘿…又有新的類別出現了,叫做”AWTEventMulticaster”,相信各位使用
Java Event寫過程式的讀者,應該會聽過Java 1.1之後的Event Model是採用
Multicast的方式來通知處理事件的Event-Handler,沒錯,就是它啦!當元件
(Source)上有事件產生時,該Source會以Multicast的方式通知所有曾經在該
Source註冊過的Listeners來呼叫對應的Event-Handler。透過AWTEventMulticaster
的add靜態方法,會把所要註冊的Listener加到Source的xxxListener(用來判
斷是否有listener被註冊)中,最後再由processXXXEvent來呼叫到對應的
Event-Handler。至於實際註冊的過程,當執行add方法時,會再呼叫到addInternal(..)
方法:
protected static EventListener addInternal(EventListener a,EventListener b) {
  if (a == null) return b;
  if (b == null) return a;
  return new AWTEventMulticaster(a, b);
}
我們可以看到當註冊的Listener只有一個時,會直接把該Listener傳回,否則
將會有一個AWTEventMulticaster的物件被產生並傳回給Source的xxxListener
,至於AWTEventMulticaster的物件為何可以傳回給xxxListener呢?主要是因
為AWTEventMulticaster實作了(implements)所有的Event Listeners。舉例來
說,當只有一個ListenerA透過addMouseListener來註冊,那麼透過
AWTEventMulticaster的add(..)會直接傳回ListenerA給Source的mouseListener。
如果有兩個Listeners註冊時,會先產生一個AWTEventMulticaster物件,並把
這兩個註冊的Listeners分別放到物件的a與b(型別為EventListener),code如下:
protected final EventListener a, b;
  protected AWTEventMulticaster(EventListener a, EventListener b) {
    this.a = a; this.b = b;
}
最後再把AWTEventMulticaster物件傳回給Source的mouseListener。如果有3個
Listeners要註冊時,原理同上,只是此時要傳回之AWTEventMulticaster物件的
a和b之中會有一個是單純的Listener物件,另一個則是AWTEventMulticaster物
件…以此類推之。當所有註冊手續完成,那麼就可以透過之前提及的processXXXEvent
來呼叫對應的Event-Handler了。

基本上Event的dispatch流程筆者就講到這兒囉,最後同樣用一張圖(圖5)來解釋
這整個過程:

圖5 (略)

從以上的說明,相信各位應該已經清楚Event最後究竟往哪裡去了!不過在圖5中還
有一道關卡筆者尚未交代清楚,那就是怎樣的Event才算是enabled Event呢?關於
這部分將在稍後揭曉。

非事件委派者(Event-Listener)不可嗎?
----------------------------------
從以上的討論,各位讀者應該對於Java 1.1之後所採用的Event-Delegation
Model有了更進一步的認識,其實說穿了,”就是將Event委託/委派(delegate)
給Event-Listeners的Event-Handlers來處理,而這個委託的動作必須是透過
addXXXListener(Listener)的註冊手續”。但是難道就一定得透過事件委派者
(Event-Listener)不可嗎?如果Java Programmer硬是不願用Event- Delegation
這套方式,那Event是不是就無從處理了呢? 當然不是。既然沒有委派任何事
件處理者,那就自己來吧! 找不到人幫忙時,也只好自力救濟囉! Smile

從Event dispatch的流程中,我們知道Event離開EventQueue之後,第一站便
是Source(指發生Event的Component)的dispatchEvent方法,既然是Source本
身先接到要處理的Event,那麼實在沒理由一定得透過其他的Listeners,由
Source自己攔下Event不就得了。從圖5中,Event最後會被processXXXEvent
來決定是否將Event丟給適當的Listener (by multicast),如果當下沒有任
何註冊過的Listeners,那麼該Event就不被處理,因為此時的Event類別已經
確定,只要再根據Event的Type(id)來個別處理即可,所以processXXXEvent
正是攔截Event的適當位置。接下來筆者就以攔截WindowEvent的WINDOW_CLOSING
來結束程式的例子做說明。

有寫過Java GUI程式的讀者們,一定都知道程式的結束並不是單純按下視窗
右上角的X按鈕就可以的,而必須由Programmer自行攔截WindowEvent,並呼
叫System.exit(0)來結束程式(註3)。不過為了跟標準的Event-Delegation
Model做區別,在此筆者就以Override的方式由Source Component自行攔截
處理Event。程式碼(MyFrame.java)如下:

import java.awt.*;
import java.awt.event.*;
public class MyFrame extends Frame {
  public MyFrame() {
    enableEvents(AWTEvent.WINDOW_EVENT_MASK);
  this.setBounds(10,10,200,200);
  this.setVisible(true);
  }
  public static void main(String[] args) {
  MyFrame myFrame1 = new MyFrame();
  }

  //Overridden so we can exit on System Close
protected void processWindowEvent(WindowEvent e) {
  super.processWindowEventEnvelope;
    if(e.getID() == WindowEvent.WINDOW_CLOSING) {
    System.exit(0);
     }
}
}
這是一個很陽春的Java GUI程式,只new了一個Frame並顯示出來,由於不
打算採用Event-Delegation Model,所以不會有呼叫addWindowListener註
冊的動作。在此MyFrame直接override java.awt.Window的rocessWindowEvent
,所以當WindowEvent發生時,Event便會被MyFrame的processWindowEvent
攔截下來,如果該WindowEvent為WindowEvent.WINDOW_CLOSING,也就是使
用者按下了X鈕時,那麼便呼叫System.exit(0)來結束程式。

從這個Sample中可以發現,WindowEvent的Source為自己(MyFrame),而
WindowEvent也是由MyFrame自己來處理,跟事件委派者一點關係也沒有。
此外,在processWindowEvent中又呼叫了java.awt.Window的processWindowEvent
方法,基本上這是比較正規的寫法,通常我們會先讓WindowEvent循正常
管道分派處理過後,再針對要攔截的WindowEvent作特殊處理,否則的話,
其他以Event- Delegation Model運作的WindowEvent,將無法被送到適當的
Event-Listeners來處理(當然也可以先針對要攔截的WindowEvent作處理,
再循正常管道分派處理)。攔截WindowEvent的過程如圖6:

圖6 (略)

再來必須跟各位讀者交代的是,上一個單元最後提到:究竟什麼樣的Event
才算是enabled Event呢? 從Event Dispatch的過程中,如果該Event沒
有被enabled,那麼Event將無法繼續被處理(不管是透過Event-Delegation Model
或是Override的方式),而在Component.java中有個方法--eventEnabled
,就是用來檢查Event是否為enabled,該方法部分code如下:

boolean eventEnabled(AWTEvent e) {
switch(e.id) {
  case ComponentEvent.COMPONENT_MOVED:
case ComponentEvent.COMPONENT_RESIZED:
case ComponentEvent.COMPONENT_SHOWN:
case ComponentEvent.COMPONENT_HIDDEN:
if ((eventMask&AWTEvent.COMPONENT_EVENT_MASK)!=0
|| componentListener != null) {
    return true;
}
break;
  case …
  }
}
如果該Event為enabled則傳回true,而Event是否為enabled可由兩點決定:
(1)該Event所對應之Event Mask是否有被啟動Sad註4)
如果已經被啟動,則發生Event的Source Component之eventMask跟對應的
EVENT_MASK常數(定義在AWTEvent.java)做’&’運算後,必不為零。例如: if(eventMask&AWTEvent.COMPONENT_EVENT_MASK)!=0)
=>表示ComponentEvent所對應之Event Mask已被啟動,為Enabled Event
else
=>反之則表示ComponentEvent不為Enabled Event
(2)  該Event所對應之Event-Listener是否存在:
也就是說,只要有對應的Event Listeners曾經註冊過,那麼該Event便是
Enabled Event。

現在我們再回到之前的Sample(MyFrame.java),由MyFrame的建構子中可
以發現到enableEvents(AWTEvent.WINDOW_EVENT_MASK),相信現在各位讀
者已經有能力解釋為何需要這段code了!因為MyFrame是透過Override的方
式來處理WindowEvent,根本不會有WindowListener前來註冊,WindowEvent
自然也不會是Enabled Event,所以只好選擇另一條路,透過enableEvents
來啟動WindowEvent的Event Mask,這才使得WindowEvent能夠正常被處理。

最後提醒各位讀者,儘管在Java中可以透過這種Override的方式來攔截Event
,但是筆者在此並不鼓勵各位讀者使用這種方式,除非您有特殊的需求,例n如設計JavaBeans元件。畢竟標準的Event-Delegation Model在使用上還是比
較有彈性的,而且別忘了,Event-Delegation Model可是以multicast的方式
來呼叫對應的Event-Handler喔,所以如果直接以Override的方式來處理Event
,要達到同樣的效果,恐怕要再多費點心思呢!所以囉,除非必要,不然的話
,其實把Events都委派給其他Listeners來處理,用起來也挺順的啦Smile

註3:其實Win32系統通常也是要自行攔截WM_DESTROY訊息,接著呼叫PostQuitMessage
函式將WM_QUIT訊息置於訊息佇列,當GetMessage遇上WM_QUIT時,才會離開訊
息迴圈,接著結束程式。

註4:”啟動Event Mask”指的是呼叫enableEvents方法,並傳入要enable之Event
Mask,Ex: enableEvents(AWTEvent.WINDOW_EVENT_MASK),就是用來啟動WindowEvent
的Event Mask。

結論
----
有關Java Event的討論就到此告一落了,限於篇幅,所以筆者主要只選擇了
”Event的來源”以及”Event dispatch的流程”等基本議題向各位讀者做
個報告,雖然這些議題其實都不難,不過卻是學習Java Event的我們所不可
不知的。除此之外,給各位讀者一個小小的建議,如果可以的話,花點時間
看看SUN的Class Library Source Code(安裝JDK就有了),這對您絕對會有幫
助的,而筆者在這篇文章中所寫的內容,其實大半都是來自Trace的心得喔!
…嗯…好啦…謝謝各位的捧場,希望這篇文章能對各位讀者有所幫助,謝謝!

參考資料
-------
*Java(tm) Development Kit Version, Sun Microsystems, Inc.
(全文完)

--------------------------------------------------------------
課程訊息> Java手機/PDA程式設計進階 (8月5日到8月7日)

課程簡介
--------
本課程將教授學員如何使用MIDP來開發實際的系統,從用戶端到伺服器端
,完整實作一個小型的企業系統,我們將用到MIDP、JSP/Servlets、以及
JDBC等技術,並使用Apache Tomcat配合MySQL來作為後端系統。本課程也
介紹如果用MIDP完成一個小型的遊戲。其他還有關於MIDP如何處理XML、
MIDP 2.0的新功能介紹。

學習目標
--------
完成本課程後,您將具備下述能力:

•MIDP手機遊戲設計
•用MIDP實作完整企業系統(含client、server)
•效能調校
•MIDP與XML
•MIDP 2.0 介紹

學習對象
--------
已具被MIDP程式設計,想學習如何夠深入應用者

學習資格
--------
為確保學習效率,您必須具備下述能力:

•以上過SL-602者(必備)
•具備Java Servlets程式設計能力

相關課程
--------
學習前:
•SL-275 Java 程式設計
•SL-314 使用Java科技開發Web元件
•SL-602 Java手機程式設計入門

時 間 :8月5日到8月7日 早上09:30-12:00, 13:00-16:00
費 用 : NT$ 20,000 (含稅、含午餐) (Java週報會員享有九折優惠)
報名方式 : 週報會員請先到http://www.javatwo.net/javaweek/
登入會員後,到"課程訊息"裡線上報名,可免去重複填資料的麻煩喔!

---------------------------------------------------------------
課程訊息> Java網路服務程式設計進階 (8月20日到8月22日)

課程簡介
--------
將教導使用高階的應用程式框架與技術來開發Web應用程式。

學習對象
--------

本課程專為已熟悉Java程式設計,並希望能利用Java程式語言開發豐富的
Web應用程式者.本課程需有JSP/Servlt基礎

學習資格
--------
建議學員先參加「學習前」相關課程,或應具備下述能力:
為確保學習效率,您必須具備下述能力:
•Java程式設計經驗
•基礎JSP/Servlet設計經驗
•基礎XML

學習目標
--------
完成本課程後,您將具備下述能力:

•了解各種以Java為基礎的Web應用程式開發架構(Framework),包括W3C標準
XSL(XML樣式語言,包括XSLT與XSL-FO),JSTL(標準標籤函式庫),以及下一代
可以與ASP.net 匹敵的JavaServer Faces標準。

•學習使用XSL技術,並將其應用在Web應用程式的開發上.XSL分成XSLT與XSL-FO
兩大部分.單純的XML,配合XSLT,將能夠讓資料作多方面的呈現.而XSL-FO能夠
將XML資料轉換成各種二進位格式,包括PDF,圖檔等.本課程將告訴您如何善用
XSLT。

•學習使用JSTL(標準標籤函式庫)JSTL已經成為JSP 2.0的標準之一,含有一套豐
富的函式庫,功能包括輸出,條件判斷,迴圈,XML處理,資料庫處理,格式化,
國際化等功能。使用JSTL可以開發出符合MVC Pattern的 Web應用程式。

•學習使用JavaServer Faces為了讓Web應用程式的使用者介面更容易開發,也為
了讓將來能夠更快速的開發Web應用程式使用者介面,Sun推出JavaServer Faces
技術。這是一套能夠與ASP.net抗衡的強大架構,除了使用者介面之外,JavaServer
Faces技術也加強了在輸入驗證,事件處理部份的架構。未來使用Java開發Web應
用程式的程式設計師,都將能夠用更簡單的方式開發Web應用程式。

相關課程
學習前:
•SL-314 Java Servlets 與JSP程式開發設計
•DTX-330 Java網路服務程式設計

時 間 :8月20日到8月22日 早上09:00-12:00, 13:00-16:00
費 用 : NT$ 18,000 (含稅、含午餐) (Java週報會員享有九折優惠)
報名方式 : 週報會員請先到http://www.javatwo.net/javaweek/
登入會員後,到"課程訊息"裡線上報名,可免去重複填資料的麻煩喔!

---------------------------------------------------------------
新課快訊> 使用 Macromedia JRUN 建立 J2EE 應用程式
(7月28日到7月30日)

課程內容
*瞭解何種 J2EE API 最能夠解決特定的商業問題
*結合 J2EE API,開發完整的企業應用程式
*使用 JRUN 建立 Java Servlet
*使用 JRUN 建立 Java Database Connectivity(JDBC)資料來源,
並執行 Standard Query Language(SQL)語句
*使用 JRUN 開發 Java Server Pages(JSP)
*將商業邏輯封裝到 JavaBeans 中
*從 JSP 來使用 JavaBeans
*瞭解 Enterprise JavaBeans(EJB)架構
*開發 Entity Beans
*管理 J2EE Transaction
*部署含有 EJB 及 Web 元件的 J2EE 應用程式
*開發 Web 服務
*利用 JRUN 來使用 Flash

學習對象:
希望建立 J2EE 相容 Web


koji edited on 2003-07-25 00:25
reply to postreply to post
話題樹型展開
人氣 標題 作者 字數 發文時間
8078 Java週報 / 2003年7月24日出刊 moliwang 32631 2003-07-25 00:12
5694 Re:Java週報 / 2003年7月24日出刊 annhy 43 2003-07-25 15:54
» JWorld@TW »  Java 文章和新聞 » Java電子報

reply to postflat modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8