Subversion Server已經轉用新的Linux Server了

因為之前的Subversion Server損壞了，因此我決定安裝新的Linux Server - Ubuntu Server+Xubuntu Desktop，因為Ubuntu的支援較多，有問題也很快便得到解決，而且它的開機時間也較之前的短。

不過不好意思了，你們的Subversion Account也要重新建立，雖然我已經建立了和之前相同的Subversion Account和設定，但是你們放在Server的檔案也給清掉了，你們要重新把你們已經下載的檔案上載了。而且我也不知道你們之前的密碼，我幫你們設定了新的密碼，你們得要問我取回密碼了。

Subversion Server暫時關閉

Subversion Server 將會在以下日期關閉進行維護，時間如下:

 

日期	12月23日(星期日)、12月24日(星期一)
時間	全日

請你們把伺服器上的檔案下載備份，以備不時之需。

Inital Report Comment

comments	簡單說明	Page Ref.
The whole Abstract look like a text book to teach ME what is Project Management. Especially on last paragraph, the first sentence “This Guide is intended to ...” I wonder that you give a report or a guide.	Abstract像一本教科書教人甚麼是Project Management	4
I cannot find any “a general description of document structure and the project” in the section of “Introduction”. This chapter like “Background of Project Management” but is not an introduction.	這裡找不到任何關於Report的介紹，只有Project management的背景。	5
Cannot find any “advantages and drawbacks of the solution”. Furthermore, it likes a functional requirements more than a proposed solution.	這裡像Functional Requirement多於像proposed solution.	6
The contents are too simple and misleading. I suppose the reliability requirements are the requirements of users how to trust the results which are generated from your system but not a “user friendly working environment.” Finally, cannot find any “existing data interface and hardware environment, future extensions of the proposed solution, required implementation language”	沒有可靠性要求說明製造出來的資料有多可信。 沒有資料介面、未來發展和所需的實作語言。	8
I suppose “Procedure” is the section of “Software process model” but it like a text book again. Please remember that I am a Lecturer but not a student, you should tell me how to apply those knowledge to your project but do not teach me.	這裡想知道製作程序多於教我這些東西	9
Only find a Gantt Chart in your project plan, where are “deliverables (Output), software tools needed (Resource), facilities and hardware needed (Resource)”??? Your project is “Project Management Tool” but I find that you do not know what is project management.	Project plan太少資料，看不到你們會project management	81
Only THREE references that you can find in Project Management? The most disappointed thing is these three links are TOTALLY USELESS in your project! Please go to find more useful information about PROJECT MANAGEMENT!!	參考資料太少且沒有用	82

簡單來說，我們沒有依足程序工作，而且我們所做的東西不合老師口味，因此給人一個不好的印象。這些都已成過去，大局已定，怎麼埋怨對Project都沒有幫助，我們只有從這裡找出將來也會再犯的錯誤，想出應對方法便可以了。沒有用的就不應放到心裡去了，影響到將來發展就不好了。

現在最主要的問題不是如何做一份高素質的Project，而是怎樣用最少時間做最多的東西，連要交的也沒有全部繳交，怎能說要做高質素的?時間有限，能做多少便多少，不足之處當然會有，但只要自問自己已盡全力便可以了。

預留時間來實作(Implementation)

　　Extreme Programing是一邉畫圖，一邉編程的開發，與傳統開發方式不同。這樣開發的好處是可以即時看到程式執行結果，不用擔心畫了圖但不知可否完成的問題，也可認清自己實際上的開發速度是多，從而為自己安排可接受的工作量。Extreme Programing的測試帶動開發(Test-Driven Development)能提高產品質量，使產品的品質顯而易見。

　　但是想得到Extreme Programing的好處，最重要的是有充足時間。沒有足夠的時間，程式設計人員為了趕及工期而放棄Extreme Programing的方法，最常見的是跳過寫測試程式而直接寫程式，這除了降低程式質素，也會增加除錯難度。其實除錯難度愈高，所需要的除錯時間就愈長，而且是幾何級數上升。連續熬夜令精神和專注力都減少，使程式出錯機會增加，降低開發速度。最終可能趕及限期，但是產品素質不佳，要繼續開發的話可以說是苦差來了(要補回缺少的測試用例(Test case)，還要除錯)。

　　距離Report和Prototype 1的期限還有20天，我們還要準備約10天時間來寫程式，如果我們的進度還要遲緩的話，要享受Extreme Programing的好處就只可以是一個夢來了。

如何實現SWING界面的自動測試

http://www.cjsdn.net/post/view?bid=46&id=176496&tpg=1&ppg=1&sty=1&age=30#176496

前幾年書寫了一個技術SWING的界面測試的有些JAVA技術還比較有意思給大家分享一下。

SWING界面自動測試關鍵技術：
1， 如何替換掉系統的消息隊列
2， 如何識別事件
3， 如何記錄
4， 如何回放

第1個技術
使用 ActiveEvent

import java.awt.AWTEvent;
import java.awt.ActiveEvent;
import java.awt.Component;
import java.awt.Dialog;
import java.awt.Event;
import java.awt.EventQueue;
import java.awt.MenuComponent;
import java.awt.event.MouseEvent;

import javax.swing.JButton;
import javax.swing.JDialog;

import nc.web.AWTAutoShutdown;

public class EventDispatch extends AWTEvent implements ActiveEvent {

public static EventQueue theQueue;
static{
if (theQueue == null) {
java.awt.Toolkit t = java.awt.Toolkit.getDefaultToolkit();
theQueue = t.getSystemEventQueue();
}
}
public static void replaceSysteEventDispatch() {
try {
//System.out.println("new frame");
if (theQueue == null) {
java.awt.Toolkit t = java.awt.Toolkit.getDefaultToolkit();
theQueue = t.getSystemEventQueue();
}
theQueue.postEvent(new EventDispatch(null));

} catch (Exception e) {
e.printStackTrace();
/** 可以是安全權限不能訪問*/
}
}
/** 虛禮一個對象 */
private static JButton jb=new JButton();
public EventDispatch(Event event) {
super(new MouseEvent(jb,1,1,1,1,1,1,false),1);
}

public void dispatch() {
while (true) {
try {
AWTEvent event = theQueue.getNextEvent();
/** 發送事件,可以在 Dialog.setModal(true) show ,接管事件 */
EventDispatch ed=new EventDispatch(null);
theQueue.postEvent(ed);

if(event.getClass() == EventDispatch.class )
continue;
Object src=event.getSource();
if (event instanceof ActiveEvent) {
((ActiveEvent)event).dispatch();
} else if (src instanceof Component) {
((Component)src).dispatchEvent(event);
} else if (src instanceof MenuComponent) {
((MenuComponent)src).dispatchEvent(event);
} else {
System.err.println("unable to dispatch event: " + event);
}

} catch (ThreadDeath death) {
break;
} catch (Throwable e) {
System.err.println("Exception occurred during event dispatching:");
e.printStackTrace();
}
}
}

}

鼠標事件是最難記錄的，由於鼠標事件前後界面會改變，或者有的需要MousePressed事件 ，有的需要MouseRelease 所以
在鼠標事件發送前後都需要進行處理
在事件隊列拿到的事件，是發送到Window上的底板的。
所以需要根據代碼取道它真正的控件對象
public static Component getMouseEventTarget(Object org,MouseEvent me)
{
Component targComponent=null;
if(org instanceof Component)
{
targComponent = (Component) org;
if(org instanceof Container)
{
Component temp=getMouseEventTarget((Container)org,me.getX(),me.getY());
if(temp!=null)
targComponent = temp;
}
}
return targComponent;
}
鼠標事件究竟發送給誰的需要在不同的點進行識別：
在鼠標 beforeMousePressed 需要識別：
JTree，JTable，javax.swing.plaf.metal.MetalComboBoxButton
需要識別單點雙點

beforeMouseRleased
需要識別：JList
afterMouseReleased
需要識別：JList，JSlider，JToggleButton，JScrollBar
其他事件簡單的介紹一下：
鍵盤事件處理：比較簡單。
記錄發送給具有焦點的對象就可以了。
itemEvent需要處理：javax.swing.JComboBox
TextEvent ：需要處理文字錄入。
WINDOW_CLOSING：處理節點關閉

mouseMove：比較麻煩，大多數時候是無限的。

正確識別事件記錄比較簡單：

主要記錄的是 COMPONENT的相對位置。

比如：他在 XX控件上的YY位置上。

最簡單的辦法是。

將界面控件全部大列表，按照順序，得到他在什麼位置。

什麼控件類型上。

建議大家記錄後以JAVA 代碼的形式記錄，可以編輯重放。

4， 如何回放
回放就是模擬記錄的腳本：
創建事件對象就可以了。
關鍵技術是：
需要等待任務隊列中沒有任務然後再發送下一個模擬事件。

有 興趣的 可以回帖交流一下

Project Work 3A 中期檢討會議議程

1. 檢討進度
   1. PMI(Plus Minus Interest)簡介
   2. 檢視過去的工作模式
      1. 8星期還沒開始編程是否合理?
      2. 把工作時間局限在開會時間是否好的做法?成效怎樣?
      3. 回想當天定立這樣的工作模式，到今天是否需要修改?
         1. 逢星期一、二開會或開工作坊
         2. 等所有人到達才開會
         3. 還有其他......
      4. 有沒使用溝通工具的障礙?
      5. 滿意自己所付出的嗎?分配給你做的喜歡做嗎?
      6. 回首當初我們所定的目標:完成所有項目，並且使我們在各方面的技能都有最大的進步。我們有沒有進步?
      7. 我們所付出的有沒有浪費?
      8. 老師給我們的安排是否合理?
      9. 我們是否應將我們的訴求表達出來?
      10. 在過程中有沒有意見想表達但沒有說出來?(放心，我們不會宰了你的，但如果不可以對所有組員說的可以不說出來)
   3. 檢視Inital Report，你認為我們有能力做出一符合要求的產品嗎?
2. eXtreme Programming簡介
3. 檢視Gantt Chart和Estimated Implementation plan
1. Estimated Implementation plan的編排合理嗎?
2. 在接下來的一個月，你會怎樣安排時間做你的functions?
1. 把答案寫在時間表上。
2. 進行風險評估:你的時間表堅固嗎?讓我們來挑戰你的時間表。
3. eXtreme Programming計畫
1. 多少日為一個週期
2. Release 1 要在多久完成(我們還要替其他Release設計)
1. 切記:第一週期的不會做到太多東西，因為很多問題都在這一週期出現。
3. Pair Programming簡介及時間表

Subversion Server 進行例行更新

Subversion Server 將會進行例行更新，時間如下:

日期	11月26日(星期一)
時間	22:00-0:00

更新期間，你們可以繼續使用這個Server，但可以會有不正常情況出現。

Project Work的資料是機密文件

大家不要忘記Project Work的資料是我們辛辛苦苦做出來的，因此如果沒有得到所有組員同意，Project Work的任何部份都不可以對外人(閒雜人等)透露，包括Report的內容、所得的分數、Supervisor對Report的意見等，以免我們的付出毀於一旦。如果不想每次都要詢問大家的意見，可以一起預先確定有甚麼可以透露給外人。

極限編程的「權利法案」

builder.com.cn

客戶的權利

• 客戶有權利大規模地計劃成本和選擇。
• 客戶有權利安排每週的開發優先順序。
• 客戶有權利在第一週結束的時候以工作系統的形式查看進度，並瞭解之後每週會做些什麼。
• 客戶有權利更新計劃安排、不論是好的還是壞的，只要有信息都要更新。
• 客戶有權利改變他／她的主意而不需要付出太多的費用。

程序員的權力

• 程序員有權利對工作進行評估，其評估的結果應該受到團隊其他成員的尊重。
• 程序員有權利如實地報告進度。
• 程序員有權利在所有的時候都進行高質量的工作。
• 程序員有權利知道下一步要做的、以及最重要的是什麼。
• 程序員有權利詢問面向商業的問題，如果這些問題出現的話。

管理人員的權利

• 管理人員有權利對成本和結果進行全面的評估，確認實際情況將（和預計的）有所不同。
• 管理人員有權利在項目之間調動人員，而不需要支付過高的費用。
• 管理人員有權利每月更新進度，幫助客戶確定總體的優先順序。
• 管理人員有權利根據最新的投資情況取消項目，並保留工作系統。

比TortoiseSVN更好用的SVN Client - SmartSVN

(查爾斯的軟體工房)
介紹一個Subversion Client軟體--SmartSVN 2.1
http://www.syntevo.com/smartsvn/index.jsp
特點：

1. UI很簡潔
2. 以專案為單位瀏覽
3. 整合WORKING COPY與REPOSITORY資訊
4. 功能齊全，就算是免費的版本就有很多好用的功能
5. 內建DIFF功能，可以比對差異並座雙向MERGE變更

缺點：

1. 需安裝JAVA VM
2. 有時候執行反應很慢

整體來說，這套軟體比小烏龜好用，尤其是在COMMIT/UPDATE/RESOLVE CONFLICT（衝突解決）方面是方便多了

我的意見:
這套軟體比小烏龜好用，好處是打一次密碼便可以做COMMIT,UPDATE等操作，十分方便，甚至可以記下密碼，下次用時便不用輸入密碼了。
下載:
http://www.syntevo.com/smartsvn/download.html
有ＪＲＥ和沒有ＪＲＥ版本，如果有裝ＪＲＥ便可下載沒有ＪＲＥ版本。
安裝後第一次使用要選Foundation版本，Professional或更高版本要付費喔!
如果你之前有用小烏龜的話，請選「Project」->「Create from Directory」，然後選取有用SVN的目錄，再給它一個名字便可以了。
之後你可以用SmartSVN或小烏龜來COMMIT,UPDATE，不會有衝突的，不過用了SmartSVN一段日字後你都會移除小烏龜了。

Project Work 3 範本

Project Work 3 Initial Report 範本
ftp://hopebb.com/David/Initial%20Report%20Sample.zip
Password: Project3Intreport

可怕的11月即將到達

每逢11月都是個可怕的日子，因為測驗家課統統在那裡，相信每個人都在這個月中至少要開一次夜車，因為這時的工作時程是非常混亂的。如果不想擔驚受怕地渡過11月，便要未雨綢繆了。以下是11月的CA時間表，紅色是最緊密的時間。

Title	Category	Due Date	Due In (Days)
IT professiom	Assignment	2007/10/22	1
Rapid Application Development & Tools	Fine-grained Assessments	2007/10/26	5
Enterprise Software	Fine-grained Assessments	2007/10/31	10
Human Computer Interaction & Multimedia Computing	Assignment	2007/11/7	17
Rapid Application Development & Tools	Fine-grained Assessments	2007/11/9	19
Enterprise Software	Test	2007/11/15	25
Project Work 3A	Report	2007/11/16	26
Advanced Object Oriented Technology	Test	2007/11/23	33
Rapid Application Development & Tools	Fine-grained Assessments	2007/11/23	33
Human Computer Interaction & Multimedia Computing	Test	2007/11/26	36
Enterprise Software	Fine-grained Assessments	2007/11/28	38

登山的故事--Extreme Programming和傳統程式設計的分別

http://blog.csdn.net/testwin/archive/2007/04/19/1570069.aspx
從前，有一個A型血的人和一個B型血的人去登山。顯然A和B有著不同的登山方法。

　A到了山腳下，總是先停下來，仔細打量山勢。接著，圍著山腳轉轉，看看哪些是小山包，哪個是主峰。然後，設計幾條不同的

　　登山線路，並選擇出最好的登山線路作為首選計劃。同時，他還考慮到如果首選計劃出現問題，則可以啟用第二計劃或第三計劃...

　而此時的B幾經爬上了第一個小山包。B登上小山包的時候，發現這個小山包不是去主峰的路。B並沒有氣餒，稍微打量一下環境，立即從小山包上下來，往更高的一個山峰進發...就這樣，B無時無刻不在後退中前進，在下坡中上山，已經將A遠遠的甩在後面。

　　最後，B成功地登上主峰，而A還在半山腰艱難地攀登。當A終於登上主峰之後，B說了一句很有很有意思的話：你現在知道極限編程的威力了吧！A默然不語...

　一位想學登山的新手來向A和B請教登山的方法。A把他的線路圖和計劃全部給了新手，沒有說一句話。新手看都沒看，就跑去問B。B意味深長地說：努力，努力，再努力，當你到達山頂的時候，就知道了登山的方法！新手由衷敬佩。

　多年以後，A成功地登上了珠穆朗瑪峰。據說B倒下的地方離一號營地只有一百米遠...

　當那位新手終於找到A求教的時候，A還是將所有的登山線路和計劃交給了他，依然沒有說一句話。

　但新手明白：這就是設計！

軟件架構

http://www.itisedu.com/phrase/200602281452595.html
http://www.uml.org.cn/zjjs/200607061.htm
在這裡找到更多

Project work 3 第05次會議記錄

與會者：Charlie, David,啟輝

地點：柴灣IVE

日期：11/9/2007

時間：下午2時30分

會議目的：使我們可以開始撰寫Project Proposal

專案團隊議程：(灰色項目表示未完成討論，必須另行商議)

1. 瞭解Project Proposal的內容和各部份的撰寫方法

1. Statement of problem to be solved:

1. 1個project要用多個software來完成，使花在購買軟體的成本增加
2. 做Project沒有時間的保證，不可靠
3. 為了使Project有效的完成，需要大量人手來處理project management的工作
4. 工作時間表有衝突(A經理給你的時間表和B經理給你的不相同，我應該跟A還是跟B做的好?然後數算兩個經理的是非......)
5. Project沒有系統的管理
6. 現有的Project management tools不易熟練
1. 也不易使用
   

2. Background to the problem:

1. 管理
1. 時間管理
2. 人力資源管理
2. 成本
3. 要寫出：
1. 對domain的描述
2. 有甚麼用途
3. 沒有這方面知識有甚麼問題
   

3. Outline of proposed solution:

1. Charlie：用six-schema project引導(to guide)user去計劃專案(to plan the project)
2. 輝：把Task細分至可以點選它表示已完成，然後計算該task完成了多少，便不用靠主觀的猜測
   

4. Explanation of why proposed solution is appropriate:

1. 即是這個solution的好處
   
5. Main stages involved in the project, with estimated time to completion of each stage:
1. 這部份將交給David去完成
   
6. Main Deliverables:
7. The (tentative) responsibilities of each member:
8. Projected Resource Requirements:

· 列出本次會議的行動項目（何人、何事、何時）。

何事	何人	何時
proposed solution(連優點，寫到proposal中)	每人一個	9月17日前完成
Statement of problem to be solved Background to the problem (寫到proposal中)	All	9月17日前完成

· 為下次會議訂定議程與時間。

地點：青衣IVE

日期：17/9/2007

時間：上午9時30分

與會者：Charlie, David,啟輝

· 對於此次會議給予評價。

1. Charlie:需時較上一次會議短

Project work 3 第05次會議

與會者：Charlie, David,啟輝

地點：柴灣IVE

日期：11/9/2007

時間：下午2時正

會議目的：使我們可以開始撰寫Project Proposal

專案團隊議程：
· 開頭的簡短介紹。
· 議程審查。

1. 瞭解Project Proposal的內容和各部份的撰寫方法

1. Statement of problem to be solved:

2. Background to the problem:

3. Outline of proposed solution:

4. Explanation of why proposed solution is appropriate:

5. Main stages involved in the project, with estimated time to completion of each stage:
6. Main Deliverables:
7. The (tentative) responsibilities of each member:
8. Projected Resource Requirements:

· 列出本次會議的行動項目（何人、何事、何時）。

· 為下次會議訂定議程與時間。

· 對於此次會議給予評價。

你們要預備:

1. 要做一個系統首先要對這個系統有願景，即你期望這樣神兵利器可以幫你做些甚麼，幫你解決甚麼問題。不論怎樣，這份報告就是要寫出計劃軟體的三個步驟，你可以根據你喜愛的順序來思考(即是如果原本的順序想不出甚麼來，便換個順序來想)：
1. 現在有甚麼不妥(我全身都不舒服，醫生，有何解救呢?)
2. 本軟體提供甚麼解決方案(這個時候，你要用我們最新研發的產品，它可以舒緩身體不適，還可延年益壽，好東西耶！)
3. 為什麼解決方案是正確的(我們的產品使用全天然中草藥煉製而成，絕無副作用，不論是寒底還是熱底，只要一劑就見效。不用打針)
2. 以下的資料可以幫你一把：
   

   姑且不論你是否有預知未來，呼風喚雨的能力。每個人在想要規劃一套軟體系統的時候，內心總會有所期待。拿到企業界來說，軟體可以幫你做的事情，不外乎下列幾項：
   •節省成本
   •縮短作業時間
   •精確地收集整理資料
   •提供情報或是對於未來提供更好的預測
   •改善溝通效率
   •增加曝光機會
   •帶來新的生意
   •被客戶或是廠商逼迫
   •老闆指名了要做
   
   如果你想要生一個案子出來，卻沒什麼概念時，就往上面提示的方向去想一想，把分權改成集權，把沒有用的冗員給砍掉，這就可以省錢，省錢就可以節省成本，嗯，大概就差不多可以找出一個方向了。當你有了一個想法，想要實行，這就叫做vision啦。
   

3. 看看各式各樣的Project management tools有甚麼Feature(上官方網站看，或者去其他網站看看軟體評論)，可以解決甚麼問題。

認識彼此-使用九型人格

　　知己知彼，百戰百勝，在團隊(Group)中，一個專案(Project)要做得好，彼此認識便能做得更有效率，也能定出更合適的目標。每個人都有不同的特質，有的很堅強，但有的沒有耐性，不同特質的人最能勝任的工作可以有很大差別。而且不同特質的人在溝通方式也有不同，要知道一個成功的專案良好的溝通不能少的(除了會議，電話、MSN、甚至檔案內的註解都是溝通)。
　　所以我想知道你們更多，我想你們找出你在九型人格中屬於那一類型，你們可以到這裡做測試，題目雖多，但是準確度也會提高。做完後告訴我最高分和次高分的類型及所得分數便可，如果你們不想把這些資料告訴他人(組外的人)就記得告訴我們。也許做好後可以交流心得呢！
　　我建議你們盡快完成測試，因為之後可能會有更多工作要做，到時你會更不願意去完成它了。我不是強迫你們去做，只是你們還記得在第２次會議的e-amil中曾說要你們得到自己真

正愛做的項目，所以我強烈建議你們去做，使這個目標更易達到。做之前先看看注意事項：

1. 你的答案是應該反映現在的你，而不是以往的你或者是你心目中理想的你

2. 請誠實作答﹐不要自欺欺人

3. 不要在情緒波動的時候做這份問卷

４. 部份問卷試題數目較多，需要較長時間完成，作答時建議用紙筆記錄答案，或定時把答案列印出來。因為網站不會記錄你所選擇的答案，萬一電腦發生故障，你之前的努力便會白費，你得要為自己的損失負責任啊！

如果你真的非常非常不願意做的話，請讓我知道，但想做也不要做得馬虎，要知道找錯類型就如斷錯症，輕則痾嘔肚痛，重則要接受深切治療，不能兒戲的。想做其他版本的測試也是可以的，這裡有更多版本可供選擇(也有我做的測試結果呢)，還有問題的話找我吧！(不要做到中了毒就是了)

留些時間思考

新華網 （2003-03-12）
稿件來源：解放軍報

　某公司總經理專車公出，司機有事來找。當時總經理正忙於工作，只是隨意應答了幾句，連頭也沒抬。司機不高興地說：“你這態度不好。不要把自己弄得太忙，應該留些時間給自己思考。”這位總經理聽了下屬的批評不但不以為忤，而是真的思考起來，並且把“人生何必太匆忙，留些時間思考”製成卡片，壓在玻璃板下當作自己的座右銘。“留些時間思考”，說出了思考與學習、思考與工作、思考與生活之間的內在關係，也道出了思考與人生之間的必然聯繫。在世間一切存在之中，只有人善於通過思考不斷提升自身的價值。能否“留些時間思考 ”，也是一個人人生和事業能否成功的重要分水嶺。中國先哲孔子說：“學而不思則罔，思而不學則殆。”當代科學學創始人默頓的研究表明，科學研究猶如百米賽跑，有許多人朝著同一目標前進，在同一跑道上競爭。而最先到達終點取得成功的人，往往是在前進路上用更多的精力和時間進行思考、發揮出更大創新能力的人。愛因斯坦為創建狹義相對論，經過了長達十年的思考，他說：“學習知識要善於思考、思考、再思考，我就是靠這個學習方法成為科學家的。”牛頓從蘋果落地導出萬有引力定律，有人問他有什麼訣竅，他回答說：“我並沒有什麼訣竅，只是對於一件事做長時間的思考罷了。”

事實上，能夠經常“留些時間思考”，把思考作為學習、工作和生活的一部分，對於擔負一定領導責任的各級幹部來說，更是不斷提高自身綜合素質的要求。列寧曾經說：為了能夠分析和思考各種不同的情況，應該在肩上長著自己的腦袋。毛澤東同志明確提出：“對任何事情都要問一個為什麼，都要經過自己頭腦的週密思考，想一想它是否合乎實際，是否真有道理，絕對不應盲從，絕對不應提倡奴隸主義。”現在，我國已進入全面建設小康社會、加快推進社會主義現代化的新的發展階段。面對世界格局多極化、經濟全球化和資訊技術網路化的新的形勢，要完成十六大提出的全面建設小康社會的奮鬥目標，不斷開創中國特色社會主義事業新局面，各級領導幹部肩上的任務艱巨，責任重大。如果不善於“留些時間思考”，或人云亦云、盲從跟風，或沉迷于酒綠燈紅、迎來送往，對事關全局的大事、要事缺乏戰略上的和前瞻性的思考和研究，儘管成天忙忙碌碌、辛辛苦苦，也是很難做好領導工作的。

“留些時間思考”是一個思想方法問題，更是需要各級領導幹部躬身實踐、下苦功解決的現實問題。毛澤東同志曾經提倡以“擠”的方法獲得學習的時間，以“鑽”的方法求得對問題的了解和研究的深入。可以說，思考是做好一切工作的基礎。江澤民同志在黨的十六大報告中告誡全黨，要努力“成為勤奮學習、善於思考的模範”，可謂言之諄諄，用意深刻。如果各級領導幹部都能“留些時間思考”，都能夠擠時間下苦功進行學習和研究，視野定會更加開闊，胸懷定會更加博大，工作定會不斷取得新的進步。

(郭嵐)

Project work 2B 好的方面的補充

　　之前在會議中我想不到在Project Work 2B的後期做得好的原因，今晚看完一擲千金後終於記起了，原來都是個很動人的故事來的。當時，佔該科目總分的一半的製成品已經完成了，在最後一分鐘光碟已經繳交了，但是之後發現很多功能都用不到，在這時候多美好的期待都沒有了，就像一擲千金裡由三百萬跌至只有數萬，但我們不是甚麼都沒有，還有presentation和其他文件可以追回分數，但是分數最多只有１５分(其他文件佔10分)，我還記得在演說前一晚有組員在MSN問我做project先還是做ISP(其他科目的家課)先，我回答說：「做project先。」在演說中大家都很用心的介紹自己所做過的，還有組員擔心時間不足調節速度呢！接著在寫文件中組員們都很用心的去測試製成品，那怕製成品有甚麼缺憾，還忙著為到自己所做的功能提供詳細的說明，到了最後繳交時連同Project Work 2A所寫的文件，合共超過五百頁(Project Work 2A估算佔了總數一半，有錯請提示)。回想起這段情景，就像一擲千金裡的玩家要從幾個寶箱中爭取最大銀碼，即使無法回到有數十萬的時候，相信這是團隊合作最燦爛的一刻來吧！
　　看回MSN的記錄，當時不只Project Work，還有其他科目也是忙著做的，當時其實可以放棄Project Work去做別的科目，用更多時間去爭取其他科目的分數不好麼？但是我們沒有放棄，只知道Project Work不合格的後果是不敢想像的，就是有這份堅持，這一科最後都合格，而且分數也不錯呢！
　　如果當時我在MSN回答的時候不是這樣說，是回答做ISP先的話，我想沒有人會繼續為那些少分數而努力，也沒有這個出人意表成績。跌倒了，要懂得站起來，這樣的團隊才能經歷風浪，為自己，為朋友，留下美好的回憶。

Project work 3 第04次會議

與會者：Charlie, David,啟輝

地點：柴灣IVE

日期：17/8/2007

時間：下午2時正

會議目的：建立有效的專案計劃

專案團隊議程：
· 開頭的簡短介紹。
· 議程審查。

1. 取得上次會議的評價
   
2. 腦力激盪：討論怎樣配合各角色來實踐在編程前的各流程(各角色的工作)
1. Proposal
2. Initial Report(Requirement specification)
3. Design specification
3. 為流程定下具體的時間表(要衡量常見的風險)
1. Proposal - 28/9
2. Initial Report - 11月初
3. Design specification - 明年1月前

· 列出本次會議的行動項目（何人、何事、何時）。

· 為下次會議訂定議程與時間。

· 對於此次會議給予評價。

你們要預備:

1. 回想上一次所做的project，甚麼地方做得好?甚麼地方做得不好?這個結果是怎樣做出來的?
2. 做得不好的地方：如果可以讓你時光倒流，給你多做一次，你會怎樣去改變這個結果?
3. 做得好的地方：如果今次也是這樣做，會否同樣做得好?
4. 當去做這些項目時，有甚麼風險(常見和不常見的)？解決方法留待下次會議討論，放在同一次會議討論恐怕時間不夠。
5. 看看這些文件的撰寫指引，有甚麼東西要做(有點像層層疊)。
   

八福臨門

來源:《號角》八福臨門

中國人講求「五福」、「十全」；《聖經》卻傳講「八福」、「十誡」。所謂「八福」便是《聖經．馬太福音》第五章，耶穌基督在「登山寶訓」中談論的「八 福」。中國人追求「五福」，乃是為了自己今生的享受；而《聖經》內「八福」的含義，卻包括了個人、家庭、社會、今生和來世；若按照「八福」教導而行，以下 提及的福氣都得著了，這豈不是更大的祝福？

想得享「八福」，不妨先明其義：

虛心的人有福了！因為天國是他們的：虛心是自覺不足，而不斷追求進步。「滿招損，謙受益」，太自滿的人，沒有進步的餘地，這包括在學業和事業上。當一個人 開始自滿時，進步便相對減少；而更可怕的是，很多人只滿足於今生的成就，卻沒有虛心追求天國之道，以致失去永生的福分。若認識自己的渺小及生命的短暫空 虛，轉而懂得倚靠上帝，就必成為天國有福的子民了。

哀慟的人有福了！因為他們必得安慰：在人類壽命的紀錄中，一般女性比男性長壽，原因是女性愛哭，懂得發洩情緒；而男士們卻是流血不流淚。上帝要我們作個像 孩子般純真、處處真情流露的人，哀慟又何妨？因為哀慟的時候，必得著一個有福的確據──從天而來的安慰。

溫柔的人有福了！因為他們必承受地土：溫柔不是懦弱，卻是由個性成熟、思想冷靜產生出來的節制能力。在一般人的觀念裡，要得土地必須經過一番爭鬥，甚至強 搶；但是在神的應許裡，不使勁的溫柔人卻可得地土作獎賞。這不就是福氣了嗎？

飢渴慕義的人有福了！因為他們必得飽足：飢渴慕義是一種正確的動機，促使我們行走公義的路。可惜今天很多人渴求的，是金銀財帛、性愛情慾......一些 「喝了還要再喝」，永遠不能滿足的東西。那些追求公義、真理，以致心靈得著飽足的人，所享有的正是滿足的福樂。

憐恤人的人有福了！因為他們必蒙憐恤：孟子說：「愛人者，人恆愛之。」對人有出自愛心的關懷、憐憫、體恤，必得著別人的真正友誼。《聖經》明確記載：神喜歡憐恤；所以作一個憐恤的施予者，也必成為蒙福的接受者。

清心的人有福了！因為他們必得見神（上帝）：「神是個靈，所以拜祂的，要用心靈和誠實拜祂。」清心，是指沒有雜念的心靈境界，當我們以單純清潔的心去親近 神時，神必被我們尋見；一個時常可以與神面對面交流的人，當然最為有福。

使人和睦的人有福了！因為他們必稱為神的兒子：神的獨生子耶穌基督，是和平之君，祂不單教導人互相扶持、彼此相愛；還捨己為人，叫人藉著祂能與神和好。若 我們效法基督的榜樣，廣傳福音，使人與人、人與神和好，就是神的好兒女了。能夠被天地間最偉大的神稱為兒子，世上哪有比這福更大的嗎？

為義受逼迫的人有福了！因為天國是他們的：若要締造一個公義、平等的社會，必須有不畏權勢、為公義發聲的正義者。為義受逼迫的人，有如中流砥柱，就像耶穌 當日為履行神的義而受人逼迫一樣，終必得著天國為賞賜。這個祝福是超越人可以想像的。

這樣說來，得著「八福」豈不比享有「五福」更具永恆價值嗎？祝願大家今年：「八福臨門，人生更豐盛，更滿足！」

願景是甚麼?

來源:《號角》月報2004年5月

「願景」既不是讀書可以讀出來的，那麼是從何而來？願景雖然是領袖的見識和眼光，其實也不是只限於領袖所有。《 聖經 · 箴言》有一句話說：「民無異象，就必放肆。」這句話中「異象」，是古老的譯法，今天可以代之以「願景」，就不會讓人想到見到甚麼怪異的夢兆之類。撰寫《箴言》的智者說，人們如果看不見一個活著的意義和前景，就會出亂子。而這個「看見」這個人生的智慧，是從上帝而來的。《聖經》記載，敬畏上帝是智慧的開端，是同樣的意思。它與聰明不同，那是智商和技巧。它是智慧，一個對人生和社會的願景。

只可惜今日人人都追求聰明，忘記了智慧。只放眼在謀生的技能而沒去為自己的生活尋找「願景」。

Project work 3 第3次會議記錄

與會者：Charlie, David,輝

地點：柴灣IVE圖書館

日期：7/8/2007

時間：下午2時-5時

會議目的：繼續啟動Project Management Tools專案團隊

1. 取得啟輝對Project的意願
1. 願景：完成專案，平過渡過，沒有意外發生。
2. 目標：盡自已努力完成工作。
3. 貢獻：
   • 愛做的：
   • 整理文件、撰寫文件
   • 不愛做的：
   • 編程
4. 擔憂：
• 資料遺失
2. 討論重要事項、團隊規則
• 成員的工作時間：
• David
• 任何時間(星期天全日除外)
• Charlie
• 任何時間(星期四晚上及星期天全日除外)
• 輝
• 稍後才會知道
• 已知逄星期四至六的晚上不可
• 聯絡方法
• 時間不許可時可用MSN進行網上討論
• 文件格式
• 使用統一的範本，以免有兼容的問題
• 臨時動議:：(留待下次討論)
1. 要有程式碼才會有文件
2. 不要使用貪新鮮去使用最新的軟體，以免有兼容的問題
3. 所有要繳交的項目要提早一星期完成，預留時間做檢查，即使項目還有可改進的地方
• 團隊規則會在下次會議討論
3. 列出專案利害關係人的初步清單
1. 有利的：只有我們的老師，同學們會很忙碌，沒有空教我們
2. 有害的：可能是我們的Second reader
4. Project Plan
1. 定下團隊目標
• 目標：完成所有項目，並且使我們在各方面的技能都有最大的進步。
  
2. 建立流程
1. 會議管理：
1. 在會議完畢後寫會議報告，並準備下次的議程。
2. 會議場地佈置簡單即可。
2. 衝突管理：所有人願意花時間尋求共識。
3. 專案流程:
1. Proposal
2. Requirement specification
3. Design specification
4. Coding
5. Test plan
6. User guide
   
3. 分配角色(可隨時變動)
1. 領導者：(可以是任何人，只要不是空著便可)
2. 文書：輝
3. 進程監察：輝
4. 使用者代理：會在編程時才決定
5. 系統測試員：所有成員都會做
6. System Planning：Charlie和David
   
4. 審查project suggestion form的內容，作最後確認。
1. Expected deliverables:
1. project management tool應該以標準為主，切合所以類型的專案，不用「度身訂做」
2. User manual應該合而為一，在不同角色用法不相同的地方分別說明便可。
2. function:
1. 增加Login/logout
   

· 列出本次會議的行動項目（何人、何事、何時）。

何事	何人	何時
尋求supervisor的意見	All	8月中
學習Java	All	9月前完成

· 為下次會議訂定議程及時間。

· 對於此次會議給予評價。

• 這兩個項目會以電郵通知
  

請用原因說服我

喲哪桑 Speaking | 管理．軟體．產品．專案: 請用原因說服我

不知道為何定下這樣的目標，不知道為何做出這樣的決定，就難以瞭解這工作的意義；

不瞭解工作的意義，就難以對工作投入熱情；

人不是棋子，不是工具。人若工作沒有熱情，就難以為繼。

因此，請用原因說服我。告訴我，為什麼要這樣做決定。而不要只是告訴我、通知我，你的決定，我的方向。

當我信了你，你我才是一個 team，有同樣方向的 team。

多表達心中所想，不要讓我變成「北堂傲」

你們也可以在這裡看到這篇文章

席天浩無功而回，得悉後大怒，欲召開武林大會，集七大派之力攻佔天一谷，樓主林遙生雖極力阻止，但北堂傲卻怒羞成怒，利用武林至尊之位，迫七大派屈服。(強劍第18集劇情)

昨晚有看強劍都知道在武林大會中，北堂傲一心想聯合七大派之力攻佔天一谷，但七大派卻因與天一谷有協議而不願攻打。
在大會開始時，北堂傲先簡介是次會議的目的：「但因為他們走進天一谷，為了要除去血影教的餘孽，所以要你們聯手攻打天一谷。」
接著直接進入結論：「既然大家沒有異議，那麼我們......」
樓主林遙生打斷北堂傲的話，說天一族和他們有協議，互不干涉，不應攻打，此時各派掌門都點頭，更有掌門支持。
北堂傲卻反對：「天一族收留血影教的人，已經先行違反協議，是天一族他們自取滅亡。」
當樓主欲再三反對時，卻被他以教主的身份阻止。最後七大派因為怕了他，被迫接受。
結束是怎樣？

林遙生借劍聖之名，取消攻打天一族，北堂傲一怒之下將其擊殺……

這個例子中的會議得不到真正的共識，只是假的共識，表面上好像各人都接受自己的工作，但是大家都是各持己見，結果還是各自為政。
會議時如果不用時間去收集各人的意見，當他們進行任務時便因為不願做這事而令他們產生壓力，使專案不能發揮效能。表面上做的是一套，但心中想做的卻是另一套，組員便會為「交差」而「交差」，不是為專案著想，覺得自己行差踏錯，不應存在於這專案中，輕則拖慢專案進度，重則失去良將，專案失敗告終。
各位如果是我專案的成員，請你們出席所有與你有關的會議，不要借別的事溜走，你的意見十分重要，上下一心才是高效專案的關鍵，我不要做第二個北堂傲呢!(今天北堂傲召開第二次武林大會時除了席天浩外所有人都走光光，把他氣得暈倒了。)

Project work 3 第2次會議記錄

與會者：Charlie, David

地點：小西灣(藍灣半島)

日期：28/7/2007

時間：下午2時

會議目的：開始啟動Project Management Tools專案團隊

議程：

· 歡迎。

· 簡介。

· 分享心中理想(可能)的結果

Charlie:我將會學到如何做一個好的project，過程有良好的時間管理，不會像project 2 的趕。

David: 用過的人都說好，自己也「用」之無愧。

· 分享成員的目標

Charlie:

1. 做好所有項目，沒有任何拖延。
2. 做出來的系統和原來的構想一樣，沒有任何差異。
   

David:

1. 我所寫的程式全都可以輕易合併到其他組員所寫的。
2. 做出來的系統近乎完美，沒有bug。

· 成員可做到的貢獻

成員愛做的:

Charlie:

1. 時間(星期四晚和星期日全日除外)
2. 物資(例如紙張)
3. 編寫程式
4. 做System plan(OOT有關的文件)

David:

1. Program Design
2. 編寫程式
3. 做System plan(OOT有關的文件)

不愛做的:
Charlie和David:

1. 寫報告
2. 通宵趕工

· 所需扮演的團隊角色

1. 領導者
2. 文書
3. 進程監察
4. 使用者代理
5. 系統測試員
6. System Planning

· 疑問和擔憂

1. 團體不能準時完成任務。(內:不能完成承諾的工作;外:不能準時繳交產品)
2. 組員有溝通障礙。

· 解決方案

1. 做好基本的部份，再一步步加上其他function。
2. 時間編排要有彈性以應付超時的工作。
3. 要關心組員，得知他的難處，給予適當的協助。
4. 定期舉行會議檢討進度。
5. 善用各種溝通工具，例如在沒有空的時候以e-mail或MSN通知對方。
6. 盡量安排時間面對面的討論。

· 為下次會議訂定議程及時間。

1. 取得啟輝對Project的意願
2. 討論重要事項、團隊規則
3. 列出專案利害關係人的初步清單
4. Project Plan
1. 定下團隊目標
2. 建立流程
3. 分配角色(可隨時變動)

· 對於此次會議給予評價。

Charlie: OK，討論的時間心情都比較輕鬆的。

· 散會。

Project Work 3的第一次會議

我們會在7月28日(星期六)舉行這個專案的第一次會議。 由於我們彼此沒有深入的認識，因此我希望可以藉今次的會議使大家有深入的認識，從而取得互相的信任、使大家有相同的目標和得到自己真正愛做的項目。
日期:7月28日(星期六)
時間:下午2時
地點:小西灣(藍彎半島)
如果你想更新時間和地點，可以和我們商議。

為了達到使大家有深入的認識的目的，在會議開始前請你們為這次會議準備好要分享的內容，詳情請看這個文件。
http://docs.google.com/Doc?id=dct4np4m_30dfff35&invite=gjfxp9g

寫vision的方法