詐騙電話

我其實常常接到詐騙電話，有時甚至喜歡跟對方亂哈啦 (反正花他們的電話費)。不過，今天接到的這一通有點不一樣，事實上，我還一度以為他們是真的，情形如下：

我先接到一通有號碼顯示的電話 (看到有電話號碼顯示，先安心一半...)，對方說他是北縣警官，前一陣子破獲一個詐騙集團，因為有發現我的偽照證件與個人資料，所以打電話給我要跟我釐清案情，這第一通電話之所以讓我覺得可能是真的，是因為大部份的時間都是對方在努力說明案情，對方也有問我一些資訊，例如我有哪些銀行帳戶...但因為對方沒有要求進一步的詳細資訊，加上我一時好奇心的作祟，居然一時笨笨的真的告訴人家我有哪幾家銀行帳戶。第一通電話結束前，對方還交代，這是偵辦中的案子，請不要對外公開。另外，他們會把資料傳給檢查官，檢查官會再打電話給我。直到這裏，我還只是半信半疑，直到第二通電話進來...

沒多久，第二通電話就來了 (真有效率)。這通電話是保密號碼，這時我才開始覺得怪怪，對方說他是書記官，要向我詢問問題，以釐清疑點。然而，對方卻只是很努力的圍著我的銀行帳戶資訊打轉，而我就用裝迷糊的方法說我人不在家，所以無法立即提供這些資訊。對方還要我趕快回家：「我們希望在第一時間排除你的涉案關係，如果你無法在第一時間釐清，我就必需發傳票給你，到時你得自己準備資料出庭應詢...」。天啊，我還真是豬罐頭，我一直到這個時候才確定我遇到了詐騙電話。人，有時候太好奇，還真的是很危險。我說：「不然你告訴你的辦公室在哪裏，我直接收收資料去你辦公室...」，然後對方就掛我電話...

不管是警方辦案或是檢查官偵訊，都不會用電話方式做詢問，一定會用正式的郵寄通知。這個我很早就知道了，卻還是因為自己的好奇心而掉入陷井，我想我真的是太大意了。最讓我悔恨的，是我不小心報出了我的身份證字號。第二通電話，那位自稱是書記官的傢伙，跟我核對我的個人資料，而我居然不小心不小心去糾正身份證號碼的錯誤 (我猜他有我一些簡單基本資料，但沒有身份證字號，結果我卻主動奉上)，我想我這下麻煩了...

這是我第一次打防詐騙專案 165，服務人員跟我說，第一通電話所顯示的電話號碼是竄改過的號碼。這還是我第一次知道，原來電話號碼顯示是可以被竄改的。只是因為我是接完詐騙電話立刻打給詐騙專線，所以他們有機會去追蹤來源~~~唉~~~加油吧~~~

陳總統有必要下台嗎-細讀李遠哲公開信後感想

1793年11月8日，法國大革命著名的政治家，羅蘭夫人，在斷頭台上，向著革命廣場上的自由雕像，留下了一句廣為傳誦的名言：「自由自由，天下古今幾多之罪惡，假汝之名以行」。
這樣的話語，聽在法國大革命人士的耳裏，自必是非常的刺耳(也許也有人罵她"騎牆"、"投機")。對當代革命份子而言，"自由"二字就是他們無可侵犯的核心價值。在這大義的旗幟之下，一切對於"自由"可能的牴觸或阻礙的人、事、物，運用任何手段、不計任何代價去剷除、消滅，自是理所當然的應該。對他們而言，這不是"假自由之名行惡"，而是為了自由的真義而努力。
1881年2月，巴黎公社以法國大文豪-維克多‧雨果八十華誕為名，舉行了盛大的慶典，六十萬人從雨果的寓所前遊行通過。而1885年6月1日，巴黎萬人空巷，從凱旋門一路擠到先賢祠，就為了替雨果送靈。維克多‧雨果，不但法國人將他喻為人類的文化遺產，更受到全世界的人所崇敬。他不僅是偉大的文學家，而且是偉大的社會鬥士，他所留下的思考精神，推動了整個社會價值的前進。如雨果的著作《悲慘世界》裏表達的悲天憫人的思想，或是《九三年》書裏所說：「絕對正確的革命之上，還有一個絕對正確的人道主義」。因為這樣的精神，人們才開始發現，追求自由，不值得無所不用其極；維護自由，不應該不計任何代價。
今日細讀了李遠哲院長的公開信，發現一些值得我們深思的重點。信是這麼寫的：「追求民主是台灣人民永不中止的理想，而廉政是民主政治的核心價值。如果陳總統與執政黨仍無意放棄民主政治的核心價值，無意背棄台灣人民對民主政治永不中止的理想，那麼就必需在"小我"與"大我"、"政黨"與"國家"之間，做出正確的抉擇」。看到這一段話，我忍不住會想問，「追求民主政治」是不是我們唯一的理想，而在"民主政治"之上，是否還有其他的核心價值? 讓我們這麼想，如果「在談論民主政治的追求之前，必須先維護國家主權」這樣一段話是正確的，「如果國家的獨立性受到侵蝕或剝奪，則民主政治將無以實現」這樣的想法是確立的，那麼，陳總統其實已經抉擇了"大我"-維護國家主權，而犧牲了"小我"-說謊與報假帳；執政黨也抉擇了"國家"-維護國家獨立，而犧牲了"政黨"-起訴即停權之黨紀的失效。從這樣的角度來看，陳總統真的須要下台嗎?
雨果的《九三年》是我最喜歡的一本書，書中的主角，郭文，領導共和軍海岸部隊，成功粉碎了保皇軍的進攻，並將保皇軍的領導人"朗德納克"，以及其殘部困於城堡裏。朗德納克捉了三個年幼的孩子為人質負隅頑抗。城堡被攻破，朗德納克從暗道逃走，而他的副官在臨死之前放了一把火，想將人質燒死。這時，三個孩子的母親眼見自己的骨肉就要葬身火海，痛哭哀豪。朗德納克動了惻隱之心，返回城堡，救出三個小孩，卻也因此被共和軍逮捕。就在朗德納克送上斷頭台之前，郭文感於他捨身救人的精神，私下放走了他。郭文犯了軍法，他將接受軍事審判。在本書第三部/第七卷/第三章，郭文接受審訓時說：「我做為司令，應當做出表率；你們做為審判官，也該做出表率」。審判官問：「你要我們做出什麼表率?」「判我死刑」。
郭文遵從了他自己的核心價值-純潔的良心，但他也選擇接受他所相信的價值-共和體制，即便這個體制有所瑕疵。觀看郭文的做為，再看看陳總統的言行，不難發現兩者之間價值高度的差異。這也是雨果之所以為人們所尊崇，而陳總統的路卻似乎越走越嘔、越走越難過。
"民主政治"是不是就是唯一的理想? "國家主權"該不該是最高的價值? 我們是否該認同，為了這樣的大義，割捨一些小善小德會是值得的? 我覺得不是這樣的，正如雨果所說：「每一個世紀都有他的使命，這一個世紀完成的是公民的工作，下一個世紀完成的是人道工作」，那麼，進入21世紀的我們，其核心價值與使命該是什麼呢? 我想，應該會是如李遠哲院長在『以色列─巴勒斯坦科學組織』召開的國際科學委員會議中所感受到的，「多元價值衝突的尊重、合作與寬容」。

Powered by ScribeFire.

別再回首看藍天

　每天的、每個時段、每個頻道，不斷重覆插放的連續劇，討論的批評的叱罵的看笑話的焦點話題，"回首藍天的駙馬爺"(也許可以當個暢銷小說的書名)，看了這麼多，聽了這麼多，想了這麼多，卻發現自己罵不出口，也笑不出來。如果，我站在他的位置；如果，我處在他的地位；如果，我就是他，我是不是會做出一樣的的蠢事，是不是會犯相同的錯誤？我會，天呀，我真的會，我就是那個被人罵的豬頭、被人笑的白痴、被人嫌的傻瓜蛋，我似乎已經看到，那個窗外的藍天！
　先不管有無違法情事，單就簡單的投資行為而看。如果我有消息、我有管道、我有快速賺錢機會(而且大概是合法的)，我賺不賺？也許，考慮自己的身份不好太過招遙，可是對於我父母的、兄弟姊妹的、好朋友的，如果我可以幫他們多賺一點點錢(不多不多，比起政府隨便一筆預算都少得多)，我做不做？更甚者，我的父母、朋友、兄弟姊妹，問問看我能不能提供一些訊息、給予一些幫助，我，幫不幫？有多少人知道，什麼是"內線交易構成要件"？又有多少人知道，證卷交易法第157條之1的內容是什麼？我又如何分辦，什麼算合法投資，什麼算違法交易？
　法律，只是最低標準的道德，只要是人所訂定的法律，就必定會有漏洞、缺陷；所以，在法律之上，需要有世俗道德的支撐。只是，在面對現今社會下，許多鑽法律漏洞的事件、走法律邊緣的"壞人"，所有討論焦點，似乎都指向單一的結論，"世風日下，道德淪喪"。"淪喪"？表示以前曾有，現在喪失了，是這樣嗎？相同的道德感可以套用在不同的時空上嗎？讓以前純樸的人們，來到現今的花花世界，就會過得比較好嗎？記得之前看到一篇報導，一位小姐走失了她的狗狗，因為張貼尋狗啟示而被開了張罰單。不少媒體以及其他受訪者，或多或少都表達了一些同情之意，認為法律的執行應該多一些人情。HOW？怎麼做？如果我是那個執法者，我怎麼做？這種無經驗可依無前例可循的鬼情形，我們要如何去找到執行的平衡點，我該如何辨別，什麼時候需要多一點人情？(就只看到沒有按照標準程序操作的鐵路維修工...)
　要說道德淪喪，不如說我們根本尚未建立該有的道德標準。我們的資本市場與民主經驗都還很年經，以人類來算，還只能當是初出茅廬的青年。所以，在這個事件上，我們不該只是把焦點放在誰對誰錯誰說謊誰該負責，而是可以從這個事件裏，討論我們可以從中習得的道德經驗。至少，我學到了一些東西，我也了解了一下什麼是"內線交易"，我也知道，位置愈高，愈要懂得自制避嫌；不只是當位者，還包括他的左右親信支持者，都要有同樣的道德感(一人得道，雞犬避遠)。這不容易呀，尤其是在台灣這樣重人情的社會...

開會技巧知識分享

前言：
開會是是組織溝通最常用的方法，然而多數的會議執行情形，要不就是變得太發散，要不就是變得太封閉，以致常會有”以會養會、越開越不會”的情形。以下分享開會的技巧與知識，期能增進開會的效率。

本文：
這裏將開會技巧分成三個不同的領域：”認清自我”、”責任歸屬”與”執行步驟與技巧”。”認清自我”與”責任歸屬”其實是一個組織在組成的時候就應該注意的問題，而這兩個問題其實也會貫穿整個組織的運作流程。很多時候，一個組織的運作如果不順暢，很有可能就是這兩個領域出了問題。對於會議的執行，其實也一樣，如果這兩個領域沒能釐清，會議的效率必定會大打折扣。以下就分別對這三個領域說明之。

1.認清自我
知道自己組織是什麼、知道自己組織的目標、知道自己組織想要做什麼，這些都是”認清自我”的基本條件。而在面對”會議執行”這件事的時候，主要需要認清的項目包括下列兩點：

(1).組織的情形
組織的情形又分成”人”與”環境”。”人”的情形指的就是組織成員的能力、經驗等問題，而”環境”的情形指的就是組織的文化。面對不同的的成員情形與組織情形，必須運用不同的開會技巧，才能達到應有的效率。這裏將成員的經驗與能力分成”高”與”低”兩種，將組織的文化也分成”開放”與”封閉”兩種。所謂開放的組織文化是說組織成員對於問題的反應踴躍，組織成員熱心於提出問題與意見；反之，封閉的組織文化則會有相反的情形，成員對於提出問題與意見的意願不高。將上述”人”與”環境”的情形組合起來，可能會產生以下四種情形：

A.成員的經驗與能力高+組織文化開放
如果成員的經驗與能力足夠，而如果組織文化又比較開放，則開會很容易因為討論的目標太多，造成討論失去焦點與方向。

B.成員的經驗與能力高+組織文化封閉
這種情形比較特別，通常是因為組織負責人太過專制才會發生，因為如果成員經驗與都夠，通常組織不至變得封閉。如果真發生這種情形，這個組織會有解體的可能性。

C.成員的經驗與能力低+組織文化開放
這種情形是比較好的情形，但因為成員能力經驗不足，會議負責人必須小心導引會議的進行，否則會議的進度可能會不如預期。

D.成員的經驗與能力低+組織文化封閉
因為成員的經驗與能力較低，對於問題的思考比較不易聚焦，開會時的討論容易變得沉悶，討論的結果可能只有宣示的效果而不易成為共識。

不管是上述哪種情形，會議負責人與組織負責人其實都是會議成敗的關鍵。在「第3節-執行步驟與技巧」時會再探討面對相關情形時，會議負責人與組織負責人的對應方式。

(2).會議的形式
這裏將會議的形式分為”開放式”與”收斂式”。所謂”收斂式”的會議，通常都只是在做最後的確認與宣示，因為目標與策略明確，可能發生的問題也少。一個會議會有效率不彰的情形，通常都是”開放式”的會議，這種會議的特色就是「目標與策略不明」。然而，多數的會議其實都是為了釐清問題或探尋方法，所以多數會議本來就常常是「目標與策略不明」，而這也是開會技巧所要面對的問題。
以本專案的某一次會議為例，一開始專案經理請同仁分享客戶問題的管理方法，介紹完之後，專案經理開始提出了一些問題。因為會議之前只有提到會議主題而沒有說到會議目標，而會議一開始就讓同仁進行分享，也沒有提到目標與策略是什麼，所以一開始對於這次會議的目的就不甚了解，在聽了經理提出的問題之後，更對會議目標充滿疑惑，所以忍不住提出這樣的問題：「會議的目標是什麼?」。經理的回答是：「我們的目標是希望找到好的方法幫助同仁執行運作」。這樣的答案是其實是有疑問的：與會同仁是否理解與認同這樣的的目標?
猜想，專案經理應該是沒有花足夠的時間處理會議前置工作；專案經理可能只是認為這樣的會議配上這樣的目標就已足夠，而會議本身只要開放大家討論即可，卻忘了與會人員裏尚有許多未來得及進入狀況的新同仁。這樣的開會效率其實是有限的，這樣的經驗分享的效率也會有所打折，當然，如果主管滿足於這樣的效率，組織同仁大概也沒什麼好抱怨的。(註1)


2.責任歸屬
在上述的文章裏有提到兩種負責人，「會議負責人」與「組織負責人」。組織負責人其實就是”主管”，而會議負責人可能是會議主持人，也可能是主管。這必須看這個會議的發起人是誰，如果發起人就是”主管”，則該”主管”就應該是責無旁代的負責人，即便”主管”是交待別人當會議主持人。
事實上，一個組織的文化跟主管本身有絕大的關係，即便是同一群組織成員，面對不同的主管也可能展現不同的文化情形，所以就算主管交待別人當會議主持人，也無法脫卸責任(除非這個主管不在意會議結果)。當然，如果主管能與會議主持人有充份的溝通，能夠讓彼此對目標與策略有足夠的共識，那至少可以均分責任。
在接下來的執行步驟與技巧裏，重點會放會議負責人身上。所以，會議執行前，責任的釐清與區別是非常重要的。


3.執行步驟與技巧
執行步驟簡單分為三個：會前、會中、會後。多數人應該都知道，會前的準備是非常重要的，可是多數人其實都不清楚”會前的準備”到底要準備什麼。這篇文章的主軸即是放在會前準備的技巧上。當然，很多人可能會因為沒有時間做會前準備，而只好直接依靠開會來解決問題，但卻造成會議的效率的低落。其實這就有點像系統開發時碰到的問題，因為沒有時間做好需求分析就直接開始撰寫程式，最後做出來的東西反而不是客戶要的….
在這裏，我們必須特別注意，會議負責人與會議主持人是不是同一個人。如果會議負責人與會議主持人不是同一個人，那麼在會議之前的充份溝通將是非常的重要。在以下的步驟說明裏，會先假設會議負責人與會議主持人是同一個人，所以只寫出會議負責人的執行重點。對於一個開會技巧尚未成熟的組織而言，建議最好先讓會議負責人與會議主持人就是同一個人。

(1).會前
會前主要的工作步驟有三個：資訊收集、分析與整理、目標與策略擬定。其實這樣的工作步驟跟系統開發是很像的：客戶訪談、需求分析、技術解決。想說的是，很多東西其實是”一法通，萬法通”，養成這樣的思考習慣其實比找到好方法更重要!!

A.資訊收集
資訊收集要做的工作其實就是事先的訪談(有點像客戶訪談)。正如前面所說，當一群人開會時，容易變得太過發散或太過收斂，這就是所謂的”小團體效應”(這裏的小團體指的是5人以上到30人左右)。為避免這樣的情形，事前應該先以2~3人的小小團體溝通為手段，一方面可以收集資料，一方面可以幫助要參與會議的同仁先行了解會議目標並釐清想法，以免到了會議執行時，或是提不出想法，或是想法太過偏離。這樣的小小團體的人數，建議不要超過5人，這個人數也是XP(終極開發流程)所建議的人數。

B.分析與整理
資訊收集之後，就必須進行分析與整理。這個動作可以幫助了解組織的情形，以擬定適當的會議目標與策略。這段過程注意的重點有二個：
a.了解組織情形
利用這段過程，可以了解組織成員對會議主題的經驗與了解程度，這些資訊有助會議負責人擬定適當的目標，並幫助有效控制會議的進行。
b.分析資訊共通性
分析資訊共通性可以了解組織成員對於會議主題上的認知的差異，並可從資訊的共通性裏整理出會議主題的關鍵鏈，這個關鍵鏈可為會議策略之主軸。

C.目標與策略擬定
首先，我們可以從所收集到的資訊，分析組織的情形，來決定適合的目標。這裏談的目標，其實包含”程度”的意念，亦即了解這次的會議執行所能達到的程度。這裏把程度分為三種：
a.如果收集到的資訊多，且共通性也多，那麼會議就可以用”達到共識”做為目標。
b.如果收集到的資訊多，但共通性少，那麼會議目標可能只能以探討共通性為主。這種時候，最好先將會議規模縮小，利用小小團體討論，先找出共通性。
c.如果收集到的資訊很少，尚無法有效分析共通性，那麼建議會議負責人事先做好會議內容，在會議上直接傳達宣示就可以了。(或是根本不要開這個會)

接下來，整理所收集到的資料，並分析出關鍵鏈，就可以擬定會議的目標與策略。所謂的關鍵鏈，可能是一連串的相依性的問題或意見，而這些其實是組織成員共通的問題或意見，會議負責人將這些串連起來，就成為會議進行的方向。接下來，再依據組織的情形決定執行策略。以下分二種情形：
a.如果組織成員資深的比較多，則會議負責人可以將所收集到的資訊直接付諸討論。
b.如果組織成員資淺的比較多(可能在資訊收集時會發現所能收集到的資訊不足)，這時候，會議負責人就必須注意問題導引。建議使用開放性提問的方式(註2)，導引成員思考與提問。事實上，如果在資訊收集時會發現所能收集到的資訊不夠多，建議不要直接執行會議，而應該增加多次的小小團體會議以提高效率。

(2).會中
一旦擬定了策略，會議就可以依策略執行。重點在於如果發現會議執行與所擬定的策略有差距 (可能是事前準備不足所造成)，最好能即時停止討論避免時間的浪費。也可以就地轉成小小團體討論，可能會有更好的成效。

(3).會後
會議結束後，除了留下討論紀錄外，最好也把討論的過程及優缺點記錄下來，例如會議是否有依策略執行，如果有的話，成功的關鍵是什麼? 如果沒有的話，原因又是為何? (如果有做好會議前置準備，這些會後資訊才有保留價值；如果沒有做好會議前置準備，會後這件事最好就算了…)

結語：
良好的溝通是一個組織能夠成功的最重要的關鍵之一，一個溝通不良的組織，幾乎免不了失敗的命運。期待這樣的知識技術分享，能幫助增進組織的溝通效率。

註1：
我其實並不認同「找到好方法」這樣的目標，個人認為，所謂的”好方法”會依目前的資訊發展情形、依成員的能力、依客戶的需要而有所不同。所以覺得，比起「找到好方法」，「找到”幫助同仁找到好方法”的方法」才是更重要的目標。

註2：
人的思考通常不可能真正的天馬行空、不著邊際，絕大多數的人的思考都還是會有所依附，然後再運用聯想的方式，建立自己對問題的思想地圖。所以，在會議進行中，資深同仁可以依附自己的經驗來提出想法；但對於資淺的同仁，則可能會先從其他同仁的話語裏，挑選自己了解的部份為依附，然後再以此為出發點來進行思考聯想(如果沒有挑選到可以依附的東東，大概就會想睡覺)。這時候，組織負責人的提問，很容易成為其他同仁(不管是資淺同仁、甚或是尚未釐清會議目標的資深同仁)的依附目標，結果意外的將整個會議導向了原本非預期的方向。這樣的情形原本就是人之常情，不是組織負責人聲斯力竭、大聲疾呼就會輕易改變的…


附錄：組織文化與組織負責人

組織文化的建立與組織負責人有極大的關係，就像之前所說，同一批人，在不同的主管面前，也可能會展現不同的文化。如果一個組織的文化比較封閉，而組織的負責人希望能有所改變，建議可以從下面兩點著手：

1.接受不成熟的意見
以資工所而言，多數的主管都有接受不同意見的心胸，卻沒有接受不成熟意見的能力(風險容忍)。理論上，所謂的主管，應該也是組織裏經驗與能力較好的人，所以通常組織成員所提之意見相對而言都會是比較不成熟的。這時候，多數的主管多會忍不住想要糾正。多數的主管可能認為這樣的糾正行為是讓成員有所成長的機會，也可能認為導正成員不成熟的意見，避免成員失敗是主管應負的責任；但事實上，這樣的行為對剛入行、有衝勁、缺經驗的人也許是有效的，但對其他多數人反而會造成思考與成長的抑制。
李世民是中國最成功的皇帝，他最有名的事蹟就是「廣納諫言」。但多數人可能只注意到他具有接受不同意見的心胸，卻沒有注意到更重要的是他有接受不成熟意見的能力。事實上李世民是非常聰明的人，他本人的意見很多時候會比他的臣子還要好、還要高明。然而，他的諫臣 魏徵 卻極力要求他去接受那些不成熟的意見。因為，如果主子時常糾正臣子的意見，那臣子自然會減少意見的提出，到時即便賞金封爵，也不會有人再提出諫言。

2.縮減範圍
當然，要接受不成熟意見，必須考慮到所能容忍的風險(畢竟是不成熟的意見)，如果組織本身沒有足夠的風險容忍能力，那就應該縮減執行的範圍。例如，想在一個多人的組織推行一個新方法，可以先分割小團體試行，然後再慢慢擴大(有點像雛形法或漸近法)。但是，這種方法的執行，其組織負責人必須要有很強的能力與控制力，必須有能力區分階段，必須要能清楚掌控各階段的情形與銜接，每個階段都必須要能完成完整驗證。這也意謂，比起”瀑布式”執行法，會多花上好幾倍的時間…

xtags library 使用上的BUG

我們要做一個 Web 介面供人員查詢資料檢核結果。原來的 Web 設計是用JSP讀取資料庫資料，然後 output 成 XML 直接回傳給 Client 的 Browser。而這個回傳的 XML 有標記搭配的 XSL，Browser 在讀取這個 XML 後，會去找到搭配的 XSL 以產出 Html 型態顯示。也就是說，將 XML & XSL 的處理交給 Client Browser。

這樣的方法發現一些問題，會有一些 IE Browser 無法正常顯示 (Mozilla Firefox 好像就沒這種問題)。我們推測是 Browser 對 XML 與 XSL 的支援上有問題 (可是找不出問題在哪!?)。後來，我們決定修改設計，將 XML & XSL 的結合，改由 Server 處理，所以我們在 Tomcat Web Server 上 加裝了 xtags library。

用 xtags library 處理 XML 其實很容易，只要在 JSP 程式裏加上一些 TAG 就好。

例 1 : 直接處理一個已存在的 XML File
<xtags:style xml="test.xml" xsl="test.xsl>>
</xtags:style>

例 2 : 內嵌 XML
<xtags:style xsl="test.xsl">
<root>
<childnode></childnode>
</root>
</xtags:style>

也可以這樣 :
<xtags:style xsl="test.xsl">
<%
out.println("<root>");
%>
<childnode><% =varible %></childnode><br /> </root>
</xtags:style>

然而，如果是用"例 2"的方法，會有怪問題
JSP 的結果會問隔性的出現 "IOException : Stream Closed"
也就是說，執行第一次會成功，第二次失敗，第三次又成功，第四次又失敗....

這個問題是 Tomcat 與 xtags library 的問題，目前無解。但可以改用以下方法來避開這個問題：
<xtags:parse id="myreport">
<root>
> <childnode></childnode>
</root>
</xtags:parse>
<xtags:style document="<%" %>"">


這樣就不會有 Stream Closed 的錯誤，也解決了之前 Browser 的問題....

應該有的心結

最近，客戶希望我幫忙整理一下系統文件，並且也為系統維護人員做一下教育訓練；他希望，如果發生一些問題，可以做一些簡單、初步的處理。其實，這件事他跟我提過好幾次，我同意他的看法，我也認為這是我應該做的事 (而且，如果做的好，還可以減少我的負擔)；然而，實際的工作執行進展，卻與理想差距甚遠。為什麼呢?

理論上，一個系統開發完成後，應該就會有系統文件的產出。所以，所謂的"整理一下系統文件"應該也只不過是把原來的文件做一下整理修改就好；很可惜，不是這樣的，我所產出的系統文件，大概只述說了系統 10% 的事實，而一份只有 10% 的文件，在經過一段時間之後，對我而言，其實用性可能接近於零。要了解為什麼會有這樣的結果，必須了解我的工作流程；不過，在解釋我的工作流程之前，我可以先預測客戶要我"整理一下系統文件"這個工作的最後結果：再做一份涵蓋度只有 10%的系統文件....

OK，下面開始用圖形的方式介紹我的工作流程。這裏不特別對圖形符號多做說明，因為，我好懶。反正，第一張圖是當接到一個工作時，決定執行策略的流程。我們幾乎都是走"分散"的路線，除非這個工作真的被細分到非常的小(1、2個小時)...

接下的第一張圖，就是工作的基礎流程。在這張圖裏面會有一些 "進入：[XX]模式" 的方塊，代表會進入 [XX] 子流程。其中真實的工作模式有四種，也只有經過這四種模式，才會達到工作完成的結果。這四種模式為：[隨便]>顧名思義，就是，隨便了啦...；[決鬥]>就是時間很趕，所以，也有一點隨便了啦...；[真的做]>這種情形，幾乎只發生在程式撰寫的時候(不包括debug)...；[實作練習]>這是我這幾年最常使用的模式。[隨便]、[決鬥]、[真的做]這三種都很容易明白，所以我只對 [實作練習]模式做另外的說明。

接下來，我們來看一下[實作練習]模式。實作練習其是就是因為我們對某項技術的掌握度不足，卻又沒有足夠的練習空間與時間，所以只好用實際的工作來練習。這種運作情形，通常都沒有什麼好結果；比方說以我的情形來看，我的路線通常會變成：沒有把握->很煩->時程逼近->找人討論更煩->隨便啦...

為什麼"找人討論"會更煩呢，那就要看一下接下來的兩張圖。第一張是"準備找人"：

第二張是"討論中"：

有沒發現，我好像常常會進入[煩燥]模式。下面這一張[煩燥]模式的圖；也就是因為經常進入[煩燥]狀態，所以，其實我有一大半的時間都在"發發呆，做雜事"的情形下渡過。

最後，來看一下讓人更加無奈的流程，[下次再說]。這個流程本來就充滿不得已，而且，記住，因為之前的工作被打斷了，所以，就算想起來要從哪裏繼續下去，也都免不了的必須讓腦袋瓜從頭開始。差別只再於，上一次的工作，是否有讓自己了解工作要怎麼做 (有果有的話，可以快樂的進入[真的做])。

好了，回到最上面的問題，今天客戶要我整理系統文件，並且對系統維護人員做教育訓練...如果是要寫使用手冊，並且對使用人員做教育練訓，我大概還有 6成的把握。可是，系統文件到底該怎麼寫，系統維護人員到底該怎麼教，我怎麼可能知道 (有誰知道的，可不可以分享一下呀!?)。好吧，我想我已經進入[煩燥]模式了。我猜，最後大概還是會不得已的進入[決鬥]模式，隨便交差了事...

PS：我在第一張"工作基礎流程圖"的說明，有這麼一段話：「在這張圖裏面會有一些 "進入：[XX]模式" 的方塊，代表會進入 [XX] 子流程」。大家不會想，既然是"子流程"，為什麼不叫"[XX]子流程"就好，偏要叫"[XX]模式"。這是因為，我一開始畫圖的時候，還不清楚我該怎麼畫才好，等到我畫到一個程度，我才發現到原來我的圖的結構會有這樣的階層性，可是，我已經懶得回去改字了。其實，我有一大堆的文件都有這種情形，甚至，我所開發的系統也有這種情形 (原本應該只是雛形，卻愈加愈大，最後還被趕鴉子上架)。這些東西，都會自然的、必然的被我丟到思想的垃圾筒...

颱瘋天

颱瘋天，被叫來加班
原因是塌非斯系統的產品發不出去 (塌非斯系統 Product 程式會當掉)。查了半天，終於找到了原因，以下說明之：
塌非斯系統有關產品的部分，我們有設計各相關產品的Template
在Template裏有各式 Tag，例:中心位置在北緯[lat00]度
上述由中括號 '[' ']' 包圍的就是資訊 Tag
程式找到資訊 Tag，然後會代換成正確的資料
例:中心位置在北緯[lat00]度 --> 中心位置在北緯21.5度

然而，當天發生了如下的情形：
1:　while (String.Pos("[") > 0)
2:　{
3:　　tagstart = String.Pos("[");
4:　　tagend = String.Pos("]");
5:　　String = String.Delete
　　　　(tagstart,tagend-tagstart+1); //將Tag的字串刪除
6:　　String = String.Insert
　　　　(value,tagstart); //將刪除的字串處插入實際值
7: }

上述是一個 while loop 的程式，在找出 '[' & ']'，並將中間的Tag代換。
下面說明一下，出問題的 Template 與實際資料

Template裏的某一行:
[its] [tyname_ch] [tyname]

上面那一行代換成這次這個颱瘋的實際資料時，應該會是:
三十午度颱瘋 阿珠 ANNCHU

然而，程式在跑的時候，卻是以下的情形
進入loop前：
　String="[its] [tyname_ch] [tyname]"
第一次的Loop跑完：
　tagstart=1
　tagend=5
　String="三十五度颱瘋 [tyname_ch] [tyname]"
第二次
　tagstart=10
　tagend=19
　String="三十五度颱瘋 阿珠 [tyname]"
第三次
　tagstart=15
　tagend=12
　String="三十五度颱瘋 阿珠 [tyname]"

第三次跑完時，String 的值沒改變
而且 tagstart > tagend !!!??

接下來，程式就進入無窮迴圈了
(我們的 code review，目的之一就是要避免可能的無窮迴圈)

接下來的問題是，為什麼會進入無窮迴圈!?
原來，"珠"這個字的前半碼，這個BYTE的編碼與 '[' 相同
所以程式第四行處理 "三十五度颱瘋 阿珠 [tyname]" 時
　tagend = String.Pos("]") = 12

........................

後來，加班，連夜趕工
把Template裏的Tag通通改成 '[{' '}]'
這樣子的雙位元處理，就不會有這種問題了...

這個事件給我們三個重要經驗

1.中文字的處理
中文字的編碼問題本來就是相當複雜的問題
像之前有同事的做法，將 BCB 的 AnsiString 轉成 WideString
(雙位元字串) 然後再來處理...事實上，也許我們可以考慮
統一使用 UTF-8 來處理字串問題 (包括資料庫的儲存)
大家思考看看吧!!

2.Code Review
這個就是另外提議的項目，可以把文字處理，當做 Code review
的一個項目。

3.客戶服務
這次的這個問題，真的是一開始設計時未思考到的問題。雖然
大多數的時候，客戶有提出的問題，可能都不是問題；或是說
大多數的時候，客戶其實也說不清楚問題是什麼。所以，這時候
乖乖來加班吧...