黑暗執行緒

漫漫搬家路~~~

2007-01-28T10:27:00.000+08:00

[喬遷啟事: 黑暗執行緒搬家了，未來我的Blog文章將改發表在http://blog.darkthread.net/blogs/darkthreadtw/default.aspx ，新的CS 2.1平台可以享受更多DIY的樂趣，會陸續提供討論區等功能。FeedBurner RSS的部分稍後會移轉過去，訂閱的人應該不受影響。歡迎舊雨新知，繼續支持愛護!]

上週提到我有想讓Blog走向專業化的計劃，Blogger其實在穩定性、速度方面都很優，又有Google撐腰，加上不花一毛錢，Windows Live Writer支援，實在是很不錯的Blog平台。只可惜Blogger的經營策略過於保守，功能少有更新，許多業界標準的Blog功能，例如: 最新留言清單、日曆顯示，甚至連最基本的文章分類都付之闕如(哇~~~ 我又用成語了，杜部長，我對不起您!)，必須去整合del.icio.us之類書籤服務才能辦到。而對我來說最大的問題在於備份不易，圖檔放在Flickr，程式檔案下載則在Google Pages，要彙集統一管理十分不便。更嚴重的一點是，自己平日寫ASP.NET成精，看到自己的Blog平台功能不理想卻無力修改，內心的煎熬實在不足為外人道呀! (Blogger可以Support Javascript其實就很酷了，但有些事在Server-Side處理掉可以省十倍的氣力) 之前有研究修改過Community Server 2.0，它提供SDK可以讓愛寫程式的賤骨頭們發揮的空間，所以就決定進行Blogger->CS 2.1 SP2的搬遷，同時也會租個網路空間，掛上有darkthread的Domain Name重新開張。

以下就是我長達12天夜間搬家的漫長經過:

1.Blogger -> CS 2.1 SP2

我打算先在自己的機器上將CS裝好並匯完內容後再去租空間，一來是在本機操作速度快，也好Trouble-Shooting(後來驗證這個決策是對的，Web Hosting的環境能做的設定及檢查很有限，有時得Call Support人員協助)，二來是還沒Ready前，租空間來養蚊子自然不是摳王的行事風格。

網路已有前人寫好Blogger->CS 2.0的Tutorial與輔助工具，不過其中的VBScript在處理UTF-8格式的中文內容會造成亂碼，我只好照著原本的VBScript寫了.NET版，改用System.Text.RegularExpression，程式意外地變精簡許多。(前述VBScript的目的主要是修改BlogML中Comment UserName Attribute出現HTML Tag的問題及日期要轉成yyyy-MM-ddTHH:mm:ss的xsd:DateTime格式，心想Blogger要搬CS的人應該不多，有需要的朋友再出個聲吧)

依Tutorial掛上Import BlogML的Add-On，一下子所有的文章及意見都匯入CS中了，Tutorial中還有提到要用T-SQL Script處理匿名意見留言者顯示的問題，這部分照方煎藥即可。

2.圖檔!

我Blogger文章中的圖檔，早期是放在BlogSpot中(對，那個沒法瀏覽已上傳照片的特難用機制)，後來則改放在Flickr。為了備份方便，我想將圖檔收錄在CS的相簿中，這樣子，只要備份SQL，整個Blog的內容就一次備足了。

首先，從SQL SELECT將160篇文章做成一個超大HTML，再用IE的Save As HTML功能，在htmlName_files目錄下就一口氣取得了全部的圖檔。下一件事是用程式將圖檔標上文章的編號，再借用Chiwi Gallery Manager的上傳功能。一次上傳完200張圖檔真是令人感動，選用CS這種知名的平台，千萬要善用工具、技術資源豐富的優勢。

圖檔上傳完，下一步苦功是要將文章中的<a href="..."><img src="..">由Flickr的URL換成CS相簿中的相對圖檔，但160篇文章，圖檔多達200張，由於LINK的格式變化不小，寫自動置換程式的時間看來會比手工改的時間更久，加上反正都要人工再校一次內容格式是否受損，這部分就決定以人工處理。(CS的TinyMCE文字編輯器，可以直接Insert相簿中的照片，但URL會用絕對網址，所以本機的http://localhost/會變成圖檔URL的一部分，事後再用T-SQL Replace Function置換。至於用過CS舊版的人可能會懷疑FreeTextEditor呢? 基於對XHTML的相容性，CS 2.1預設用的是TinyMCE，但Editor可以抽換沒問題。)

3.Tags

過去Blogger沒有分類機制，所以這次在檢閱文章時，我就順便為每篇文章加上Tag，使用者就可以由Tag Cloud中標籤文字大小看出Blog的文章走向，也可以一次挑出同一類別的相關文章。

4.Style

厭倦了過去的白底黑字，為了配合"黑暗"二字，這次大膽地採用了灰黑底色的Style，質感不錯，但不妙的是之前在白底色時期常用的藍色、咖啡色等文字，在灰黑底上變得很不清楚。檢視文字時，還要一併改改部分特殊文字顏色，讓它們在新的深底色上看起來不要太慘。

5.Add-On

自己搞Server，就要特別留意不要被網路駭客、垃圾留言攻陷。Comment Spam一向是Blog平台的大敵，CS標榜利用Comment的特徵來阻擋Spam-Comment，但我還是覺得要求使用者輸入雜訊文字圖片內容後才放行的做法比較好，所以另外裝了TimothyHumphrey.CommunityServer Add-On，如下方意見區所示。(這也才知道寫意見或註冊會員時，網頁要求你解讀歪七扭八的英文數字圖片後輸入的做法，其實有個專有名詞: CAPTCHA-Completely Automated Public Turing test to tell Computers and Humans Apart)

一直覺得Blog首頁列出最近的留言意見是很好的功能，但CS沒有內建，所以我加掛了Keyvan Nayyeri的Blog Recent Feedbacks Control。

6.FullText Search Support

之前在2.0時就發現CS所使用的Hash法，在處理中文查詢上會有問題，因此照著過去的改法，我修改成可以用LIKE或CONTAINS進行查詢。

7.前進Web Hosting

參考了Rex的使用經驗，我選擇了口碑不錯，便宜又大碗的ASPnix，一年美金77.7元，提供3G的ASP.NET檔案與SQL 2005共用磁碟空間(後來發現要再花12元註冊一年的DNS名稱，但比起其他選擇還是便宜)。刷卡付完錢，馬上就可以登入使用及FTP上傳ASP.NET專案，DB的部分可以直接用SQL Server Management Studio連線管理，但是備份還原之類的操作，會因為選取檔案位置的權限問題而失敗，Forum上有人提到，可以將備份檔案FTP上去，請Support人員代為Restore。我寫了Mail請Support幫忙，大約幾十分鐘後就收到回覆，Support看我裝的是CS，還經驗十足地自動地替我設好photos/storage, photos/cache等目錄的寫入權限。

只是裝在ASPnix Virtual Directory下的程式運作起來，老是會出現
Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
的訊息，有時Reload一下就又OK，為此又打擾了ASPnix Support好幾次，最後終於Google到這篇說明，原來如DNN、CS等程式，裝在Web Hosting Virtual Directory下，就會因為Medium Trust Level限制而發生這種問題，要改安裝在wwwroot或Sub-Domain下才能解決。ASPnix Support的回應速度挺快的，態度也算親切，Forum上也有很多問題排除討論可以參考，我唯一小小的抱怨是少了一份整理好的FAQ，列出幾乎每個新手都會遇到的問題，應可節省來回Mail及在Forum搜索的時間。

還有一點，我買的Shared Web Hosting方案，IP是跟人共用的，也就是同一個IP 80 Port上也許掛了數百人的Web，IIS則是利用你輸入的Host Header來決定是Virutal Server。換句話說，www.darkthread.net, blog.darkthread.net都指向同一個IP，但輸入http://www.darkthread.net 與輸入http://blog.darkthread.net，會連到同一台IP的IIS，但進入不同的IIS Virtual Server。一開始以為會有自己專屬的IP，所以在Domain Name沒有註冊前用IP連線測試，就得到了HTTP 404 File Not Found的結果，被搞得一頭霧水。

8.大功告成

最後，檢視了一下系統功能大致都OK了，再花12塊美金註冊了darkthread.net這個網域名稱，新Blog就算正式掛牌營運囉! 歡迎光臨，要包入厝紅包或贈送新居禮品的朋友請留言，我會再派快遞去取，哈!

PS: 我還沒有太多時間去調整好CS 2.1的功能及顯示，急著搬是怕在Blogger上寫愈多搬起來愈累，所以大家對介面有建議或想法，可以在討論區提出，

TIPS-解決SandCastle File Helper Builder的Unresolved assembly reference錯誤

2007-01-17T22:41:00.000+08:00

好用的Help檔產生器--NDoc的作者Kevin Downs在2006年7月宣告不再投入NDoc Open Source Project的開發，NDoc中止在1.3版，還來不及加上對2.0版Assembly的支援。讓Kevin決定退出的理由之一是微軟推出了SandCastle(沙雕城堡?)。

SandCastle目前最新的版本是Dec 2006 CTP，不像NDoc是個具有完整介面的GUI工具，主要為兩隻命令列工具程式(MrefBuilder & Build Assembler)，要建立CHM檔得透過一連串的Command Line操作，對用慣NDoc的人來說挺不人性化的，所幸開發社群已有人寫出整合SandCastle的GUI介面，例如: SandCastleGUI、SandCastle Help File Builder(跟NDoc的操作介面相似)。

不過試作了一顆現有.NET 2.0自訂元件的Help檔，卻出師不利。由於元件額外參考了System.Configuration.dll，SandCastle Help File Builder(SHFB)會出現:
Error: Unresolved assembly reference: System.Configuration (System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a) required by YourAsmName 的錯誤。Goggle了一下，原來這是SandCastle CTP的一個大Bug--無法Reference GAC中的DLL檔(見FAQ的Does Sandcastle resolve reference to GAC DLLs?)；改用SandCastleGUI倒可以順利Build出CHM，只是中文會變亂碼的老問題又冒出來了(之前NDoc我也是改了Source才能正常處理中文)，SandCastleGUI沒提供Source Code，沒法動手，所以我又回頭試著解決SHFB的問題。

追了一小段Code之後，我發現其實只要修改Program Files\EWSoftware\Sandcastle Help File Builder\Templates\GenerateRefInfo.bat，加入以下的紅字，連Code都不用改，問題就可以解決囉!

@ECHO OFF
REM Step 1 - Generate the reflection information
"{@SandcastlePath}ProductionTools\MRefBuilder" /config:MRefBuilder.config /out:reflection.org
/dep:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\*.dll {@Dependencies} {@DocInternals} *.dll *.exe

Microsoft MVP!

2007-01-17T01:45:00.000+08:00

幾個月前，從Rex處得知6-2屆MS MVP開始接受報名，整理了自己的著作、代表性Blog文章、網路社群互動等資料，抱著姑且一試的心態遞了報名表，回到每天庸庸碌碌的日子，很快地就忘了這檔事兒。1/2日，收到MS MVP網站寄來的通知信，Yes! 自己在微軟領域的多年深耕，樂於分享的熱忱(其實只是好為人師性格的昇華)終於正式被微軟所肯定，有幸與知名的講師、聞人，一起名列MVP榜上。而我這個"微軟基本教義派民兵"，從此算是正式貼上MS標籤了。

通知信中還提到了MS MVP享有的福利: 一年份的MSDN、可參加MVP年會、有機會與MS產品團隊交換意見、MVP專屬網站、USD 150的MS商品購物金... 等等，對一個成天搞微軟的人來說，每一項都很有吸引力。上週五，DHL送來了MVP Award Kit，一個包裝精美的紙盒子，裡面有證書、小胸章、MVP卡片(信用卡大小)、一本小手冊跟NDA(保密合約)，而最有意思是一個精美皮質方盒，裡面有雷射筆、真皮名片夾跟1G的USB行動碟，很精緻也頗實用。收過MCSE、MCSD的Welcome Kit，這份Award Kit的確能提供了更深刻的"尊榮"感，哈!

為了迎接這份意外的獎項，我重新規劃了今年的努力目標，將會更用心地經營Blog，提供更多專業的技術分享，也會試著開放更多互動的管道。看起來Blogger簡陋的功能應該是不敷使用了，過陣子我就會將Blog遷到Community Server 2.1平台上，屆時還望各位舊雨新知，繼續支持與鼓勵囉!

毅力的極限，再來一顆不一樣的三角點

2007-01-15T23:21:00.000+08:00

整件傻事要從上回摸完不一樣的三角點說起，10月初剛考完初業，滿腦子還塞滿了內線交易要坐幾年牢、罰多少錢的無聊法條。聽說高業跟初業範圍幾乎一樣，只是深度再深些，於是我打起了如意算盤，心想好不容易將這堆沒營養的垃圾塞進腦子，只用一次就丟未免太浪費，何不趁熱再挑戰一下高業?

試著去網站預訂考試日期，卻發現到1月底前的場次全都額滿了! 怎麼忽然大家都搶破頭急著考試? 看了一下網站說明，才發現我完全在狀況外，證基會每年都會換題庫，95年題庫只能用到2007/1/31(後來才Google到老鳥的叮嚀，年初就買書、開始規劃考試時間才是王道!)，無怪今年準備了考試的人，要把握時間博最後一把。不過網站有提，在12/25前寄出報名表的人，他們會負責在1/31前加排場次消化完，一時賭氣不甘心腦中的記憶白白浪費，還是透過網路訂了簡章跟高業題庫(2200題庫+60簡章+1100報名費，小朋友們又離我而去了)，準備再當一次有為的中年人。

拿到書也確定考試日期，才發現失策了!! 第一，考試日期得排到1/15，事隔近三個月! 這類不重要的背誦材料，我一向存在腦中"快取區"，時間一久，讀進去的東西正以等比級數揮發掉，原本想要回收再利用的如意算盤砸了。第二，比起初業，高業的題目可真"高"呀~~~ 在複雜度跟刁鑽度上高出許多，常常一題的四個選頁中就涉及四個觀念，也不再像初業題目常有白目選項大玩消去法。總之，最後的狀況是，因為年代久遠，殘存的記憶有限，加上題目變難變多，即使有題庫可看，多達四五千題的份量，光要全部看完一遍就很嚇人! 不得不，我又開始了每天早上四點半起床、睡眠不足的苦讀生涯，連週六、日的登山活動也只好取消。不過最讓人心慌的還是，看到第三本，第一本已經忘得差不多了...

總之，這次又在極度缺乏自信的情況下，硬著頭皮進考場。看到這次高業的考生群似乎年長些，但也不乏年輕的面孔，看來像學生。有了前次的考試經驗，對報到、進場、作答的流程都很熟悉，不熟的只有題目而已。幸好，跟前次的經驗一樣，實際考題比證基會的題庫簡單，刁鑽的不多。(看來題庫叢書貫徹了古代輕功修練的精髓，先在腳上綁上過重的沙包，待能行走自如後，除去沙包，輕功自成!) 雖說如此，財務分析中艱深繁瑣的會計概念及一卡車的比率、公式，還是讓準備不足的我心慌意亂，甚至擔心會因這科未達五十分破功。(及格分數為三科合計210、單科不可低於50)

跟上回一樣，又用顫抖的手插IC卡刷成績，看到成績單手抖得更厲害... 哈里路亞! 我驚險地救回了一千一百大洋，不用煩惱換了考題，不必再猶豫是否重考，最重要的是，明天起可以睡飽一點了~~

TIPS-XHTML下如何強制指定SPAN寬度

2007-01-08T18:24:00.000+08:00

先前我寫過一篇KB，談過套用XHTML後，TextArea的Width光設定數字時無法生效，必須再註明px才可以。今天在處理SPAN時，又遇到同樣的問題! 以下的寫在如果不加第一列的<!DOCTYPE...>，可以顯示向左靠的Left及向右靠的Right文字。但若加了XHTML宣告，則Left與Right就會接連著擠在一起。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" ><BODY>
<DIV style="WIDTH:305px;">
<DIV><SPAN style="width: 100px;">Left</SPAN>
<SPAN style="width: 200px; text-align:right">Right</SPAN></DIV>
</DIV>
</BODY></html>

Google了一下，找到一篇文章。原來在XHTML中，SPAN預設已經不能強制指定寬度了，而是完全由內含文字、元素的寬度決定。如果要指定寬度，可以利用style的display屬性，過去我只用過none隱藏元素，原來還有block、inline-block等值可以設定。設block時相當於DIV，會造成Left、Right不能排在同一列，因此inline-block是本案例的最佳選擇。改成以下的style宣告，就可以在XHTML中正常顯示囉!

<DIV><SPAN style="width: 100px; display: inline-block;">Left</SPAN>
<SPAN style="width: 200px; text-align:right; display: inline-block;">Right</SPAN></DIV>

KB-Oracle轉SQL的日期陷阱

2007-01-03T23:30:00.000+08:00

在SQL 2005上建了Linked Server連到ORALCE，轉檔的SQLCLR Procedure卻一直發生疑似日期轉換的錯誤:
Msg 8114, Level 16, State 8, Line 1
Error converting data type DBTYPE_DBTIMESTAMP to datetime.

過去這類的錯誤都是因為SQL中不允許NULL的日期欄位，在Oracle中有設了NULL值所引起的，但反覆清查多次，排除光所有為NULL的日期欄位，錯誤依舊。忽然福至心靈，會不會是日期範圍不同所致?

SQL的DateTime型別: 1753/01/01 - 9999/12/31
ORACLE的Date型別: "西元前"4712/01/01 - 9999/12/31

結果用WHERE ArriveDate < TO_DATE('1900/01/01','YYYY/MM/DD')一查，測試資料庫中有名員工的到職日竟是西元998年9月8日，就是這位來自宋朝的老兄，讓SQL轉換日期出了錯。(嘖嘖嘖，以他的年資，退休金應該破億吧!!)

下回再遇到ORACLE與SQL間日期轉換有問題時，記得查一下日期範圍。

【後記】
後來還發生了怪異的事，將ORACLE有問題的資料刪除後，SELECT該Table(假設為Emp)仍有同樣的問題。用CREATE TABLE EmpClone AS SELECT * FROM Emp的方法複製了另一個相同的Table(EmpClone)，卻可以正常SELECT；即使將Emp的資料全部清空、SQL 2005 Restart，SQL 2005還是抱怨無法轉日期。
最後，我將Emp TABLE DROP後重建，再將資料倒回來，居然就OK了。之後另建了一個Table，故意塞入999/01/01，SELECT時會出現日期轉換錯誤，但把資料刪除後就正常，看來先前的情況只好歸入X檔案了。

TIPS-抛棄式的Email信箱

2006-12-29T19:38:00.000+08:00

今天看到Goston分享了一招 [資訊] Google Gmail 防止廣告信的一個小技巧。

跟許多人一樣，我也是今天才發現Gmail有這項方便的功能! 如Goston所提，有時會瀏覽到某些"想看東西必須註冊會員，並需要透過e-mail寄發啟用密碼"的網站，常常註冊後不久，垃圾信就有如淊淊江水，綿綿不絕~~ 弄到每次要在網站留e-mail就心驚膽跳。針對這種不想留下真實e-mail卻又要收信的需求，我就再分享另外一個在ReviewIT Blog文章看過的好東西---拋棄式的電子郵件信箱!

http://www.2prong.com 是一個免費的e-mail服務，它可以自動幫你產生一個e-mail地址(或者你也可以自訂收信人名稱)，只要保持瀏覽器開啟，它便會即時將寄到該信箱的信顯示出來。這樣我們就等於有了一個只用一次的收信專用信箱，非常適合拿來了應付那些需要收信又不想留真實信箱的場合。而且為了怕被鎖定後列入黑名單，它的Domain Name會每週自動更換一次，好個貼心又周到的服務! 不過依我使用的經驗，處理中文信件時會有編碼錯亂的問題，幸好帳號啟動信件中的URL Link才是重點，一般來說，即使內文是亂碼也沒啥大礙!

不過，應用時要留意它"用過即拋"的特性，如果還打算用該信箱未來還需要陸續收到信件，可以考慮前述Gmail或Yahoo的信箱別名功能。

KB-Oracle 9i NVarchar求生守則

2006-12-28T00:00:00.000+08:00

同事反應，一個CharacterSet設為ZHT16BIG5的Oracle 9i的資料庫，其中某個Table的NVarchar2欄位完全不接受非BIG5字元，存入時會變成"?"。攪和了近一個月，反覆嘗試了多種工具、方法，也請教了朋友、求助Oracle Support、查了Oracle KB，結論幾乎都指向---"Oracle 9i的NVarchar在非UTF8字元集資料庫裡無法接受非BIG5字元，而會將其轉為問號。要解決這個問題的唯一方法是是將資料庫字元集設為UTF8，或將Client & Server都昇級至10g R2"。(注意: 後來驗證的結果，這個結論不完全正確，但至少對N'...'表示法來說是如此)

直到今天，有機會重試一份簡單的Sample Code，碰巧又用對了檢查工具，才總算理出些頭緒。先來說說為什麼情況為什麼變得這麼複雜?

1.測量之前，先確定你的尺是直的!
這大概是這次摔最慘的地方: 你所使用的資料庫查詢工具可以正確地顯示非BIG5字元嗎? 用慣MS軟體與工具的人大概自WinNT時代起就很少擔心Unicode相容性問題，但這回常用的Oracle的搭配工具幾乎全軍覆沒! Oracle自家的SqlPlus都到9i版本了還不支援，著名的Toad看來也不行! 倒是發現純Java開發的Aqua Data Studio 只要UI設定支援Unicode的TTF字型，顯示OK；另一個用.NET寫的QueryExpress若選用Oracle Driver(意味要用Microsoft OLE DB Provider For Oracle而不是Oracle Provider For OLE DB)時，也可以順利無誤地顯示Unicode字元。
搞錯了工具，有可能INSERT成功了還不自知，或許一開始就被錯誤的觀察結果給耍了，白繞了一大圈。
[2006/12/28 Update]
還有一把歪歪的尺忘了說，.NET Console Application也不Support Unicode，而會以ANSI方式輸出，因此要視OS設定而定；我的Windows預設非Unicode語系當然是BIG5，這讓用Console App寫Test Code的我又多花了半小時...

2.用英文跟老外搭訕前，先確定他懂英文
MS SQL我用了N年，連我的膝蓋都認同N'...'表示的就是NChar字元。這個語法在Oracle 9i也支援，只可惜處理法則跟想像的很不一樣。即使用N'...'標示的Unicode字串，Oracle 9i資料庫也堅持用自身設定的字元集去解析，把不認得的字元換成?或¿再存入資料庫... 這... 這會不會太雞婆了點? 字串前的N難道是加心酸的?
由於沒想到N'...'在資料庫字元集為BIG5時根本是黑心貨，花了大把時間做的測試純屬虛工。用N'...'測試的結果，加上幾位有Oracle奮戰朋友的佐證，推導出"除非資料庫字元集改為UTF8，否則NChar就只能接受BIG5字元"的悲觀結論。
(Oracle文件倒是提供了一些替代方案，NCHAR(505055)、UNISTR('\20AC')、chr(14844588 USING NCHAR_CS)，但要把原本簡單的欄位值指定程式改成這副德行，讓人想要寫個"慘"字)

最後因緣際會下，用最原始的.NET Sample再試一次，加上湊巧用QueryExpress的Oracle Driver模式查詢，看到Oracle資料表中出現三頭牛疊羅漢(犇是這次拿來測試非BIG5的字元)的一剎那，我當場濕了眼眶~~~

正確來說，Oracle 9i的NChar, NVarchar並不黑心，只是嬌貴的它需要我們留意各項細節，小心對待才能正確地儲存資料。以下我歸納出用.NET正確Insert非BIG5字元進Oracle 9i BIG5資料庫的注意事項:

1.使用cmd.Parameters指定參數，而不要用Ad-Hoc方式組N'...'

OracleConnection cn = new OracleConnection(cnStr);

OracleCommand cmd = new OracleCommand (

"Insert Into NCharTest Values (:VC, :NVC)", cn);

cmd.Parameters.Add("VC", OracleDbType.Varchar2).Value = "牛犇";

cmd.Parameters.Add("NVC", OracleDbType.NVarchar2).Value = "牛犇";

cn.Open();

cmd.ExecuteNonQuery();

cn.Close();

2.記得明確宣告OracleDbType.NVarchar2(ODP.NET)或OracleType.NVarChar(System.Data.OracleClient)。我同事疏忽的地方便是用了cmd.Parameters.Add("VC","牛犇")的寫法，.NET自行決定的OracleDbType顯然不是NVarchar。

3.據Oracle官方文件表示，10g R2以後的版本已移除對NChar不當解析的問題。

KB-Modal Dialog Mini FAQ

2006-12-23T23:41:00.000+08:00

或許有些人對Modal Dialog不是很熟悉，基本上它就是由某個網頁另外開啟的一個網頁，但新開啟的網頁會強制取得焦點，直到該視窗關閉後才歸還，它特別適用於彈出另一個網頁強迫使用者檢視、選擇或輸入後再返回的場合。要套用這種強制使用者選擇、操作後再返回的模式，可以透過window.showModalDialog(sURL [, vArguments] [, sFeatures])函數，以Modal Dialog方式開啟指定的網頁即可。

Modal Dialog在網頁UI設計實務上還挺常見的，例如: 寫信時叫出連絡人清單視窗供使用者挑選收信人、在清單中選取一筆資料編輯後返回清單…等等。使用Modal Dialog可以避免另開的新視窗跑到背景、被最小化後不知去向的混淆。

不過，Modal Dialog是個很有個性的視窗，與一般的Window Object的行為不太相同，以下是一些經驗談:

Q1. Modal Dialog要怎麼控制大小位置?
Ans: 利用dialogWidth, dialogHeight, dialogTop, dialogLeft屬性

Q2. 如何偵測網頁是否開在Modal Dialog中?
Ans: if (widnow.dialogWidth) { alert("I am inside modal dialog!"); }

Q3. 網頁叫出Modal Dialog後，可以對其中網頁DOM進行操控嗎?
Ans: 母網頁跟Modal Dialog間沒有直接控制的管道，只能透過呼叫時傳遞參數過去(我習慣將整個Window Object傳過去，這樣就可以在Modal Dialog中存取完整的母網頁HTML DOM)。但無論如何，母網頁永遠只能扮演被動的角色，存取操作的主導權在Modal Dialog身上，這符合由Modal Dialog取得焦點，並主導操作的原始精神。

Q4. 放在Modal Dialog中的ASPX/ASP，在按下按鈕(Submit/PostBack)或點選連結時會另外開啟新視窗，要如何解決?
Ans: 可加上<base target="_self">宣告，或用Iframe嵌入ASPX網頁(後者實在有點小題大做，當我沒說好了)

Q5. Modal Dialog有什麼不方便的限制嗎?
Ans: 罄竹難書~~~
1) 不支援history.back()或history.go()
2) 沒有地址列(Address Bar)及上一頁/下一頁的按鈕列(Standard Buttons)
3) 不能使用右鍵叫出IE的Context Menu，所以不能列印、不能選取/複製、不能切換語系、不能Refresh...
4) Modal Dialog對於Cache的堅持讓人敬佩，明明網頁都設定Response.Expires=-1或指定No-Cache了，Modal Dialog卻還是有偶爾會去讀到Cache中的舊資料。因此我常會在開啟URL加上亂數加以預防，例如: showModalDialog("a.aspx?rnd=" + Math.random(),window);
5) 我有發生過在Postback前後，同一網頁的Body Margin產生位移的怪事，解決方法是隨便為網頁套用CSS(即使該CSS檔不存在的也成，絕吧?)即可克服。

TIPS-如何停用工具箱的自訂控制項清單產生功能

2006-12-22T23:59:00.000+08:00

這個痛苦只有自己寫Control的人才能體會! 在大型專案中，有時我們會將程式邏輯封裝在自訂的UserControl(使用者控制器)或Custom Control(自訂控制項，我則習慣叫它自訂控件)裡，以求能快速組裝及反覆利用。在我看過的一些專案(例如: Community Server)中，Solution中就包含了近百個UserControl。結果只要一切換到ASPX的Design頁面，就要花上數分鐘看工具箱裡冒出一個個小齒輪...

原來這又是VS 2005提供的新功能，在顯示工具箱時，會自動掃瞄專案裡出現的User Control及Custom Control，一一加入工具箱中，讓你可以在工具箱中找到自訂的Control，直接拖拉到ASPX的頁面上。這個貼心的設計方便歸方便，但當你的專案中的自訂Control數目很多時，忍受漫長的自動清單產生過程，實際上需要直接拖拉自訂Control的時機卻很有限，並不划算!

所幸VS 2005提供了選項，可以讓我停用這個雞婆的自動化功能，如下圖:

Visual Studio 2005 SP1 來了

2006-12-21T09:06:00.000+08:00

最近有點小忙，今天才發現Visual Studio 2005 SP1已經正式Release快一週了，依據Scott Guthrie的說法，VS2005 SP1除了將Web Application Project納為系統內建選項之外，還做了不少效能上的提升。由於一直對VS 2005 IDE的操作流暢性及Build速度有點意見，當然迫不及待想把它裝起來玩玩。(VS 2005 SP1可以在微軟網站下載: 英文版、中文版，430M左右)

可惜安裝過程沒有想像中順利，前後重試了五次:

第一回合，跑了一陣子才警告我要將先前裝的Web Application Project套件移除，移除後重來一次。

第二回合，安裝程式停在"Gathering Required Information"的同一進度上約5分鐘，CPU 100%，HD無動作，耐性不夠的我以為當掉了，Cancel後重來。

第三回合，這次耐心十足地等了快半小時，終於結束了蒐集資訊的程序，卻警告我Windows Live Messenger沒關閉，將Messenger關掉後按Retry，它老兄居然又重頭開始蒐集必要資訊... orz

第四回合，又經過了20分鐘，進度顯示剩53秒時，出現Error 1718 *.msp did not pass the digital signature check，安裝過程整個Rollback! orz Goggle了一下，找到這篇Post及KB，如KB指令修改了Policy再試一次。(記得安裝完後，要將All users except local administrators的例外設定改回All users)

第五回合，又半小時過去，總算安裝成功了!
(過來人的建議: VS 2005 SP1安裝期間常會陷入CPU 100%，HD無動作的冥想狀態，請保持耐性，安裝SP1耗費時間長短將視你安裝VS 2005項目的多寡而定；若VS2005為完整安裝時，花上一小時應該也不稀奇。安裝前建議先依KB的說明修改Security Policy (For Window XP & Windows 2003)，並關閉其他應用程式，發生突發狀況重來的機會會少一點。)

裝好後重新開啟VS 2005，可以看見新的Web Application Project選項。

我嚐試了一下，HTML Source Editor的操作回應感覺有快一點，至於Build Web Site的速度，感覺有些許提升，但不是十分明顯，我認為仍在心理作用的誤差範圍內。Anyway，既是Service Pack，沒有不安裝的理由，大家找個時間，泡杯熱茶，動手安裝吧!

KB-Unicode編碼解析小工具

2006-12-17T10:26:00.000+08:00

以下是一小段我對Unicode的粗淺了解, 希望對深陷其中的云云眾生有所幫助:

1. Unicode是為了應付全世界所有文字符號編碼而發明的，古早的ASCII Code只能表示255個字元，所以Universal Character Set-2(UCS-2)的標準被制定出來，以16bit表示文字，企圖容納世界上所有文字符號，目前(Unicode 2.0)已經制定了38,885個字，但仍有許多國家的文字與符號仍未被納入，餘下的26650個字肯定不夠用。因此目前又有UCS-4的誕生，以4個位元組來表示一個字符，未來將可容納20億個字元集。Windows NT以後的版本，其核心已採用Unicode作為文字編碼標準，採用的便是UCS-2。

2. Big5是古早前制定出來以2個Byte表示中文的編號法則，英文部分仍是以一個位元組表示，在這種混合長度的編碼法則中，由前一個字元來決定接下來的字元與他成為一個中文字或是另一個獨立英文字母。

3. UCS-2固定以兩個位元組表示一個字，即使是英文字母也佔要2Byte，因此UTF(UCS Transformation Format)-8就誕生了。它是UCS-4標準的一部分，和 Big5的原理類似，英文只用一個byte，中文或符號就用2-3個byte。就純英文而言，可以大量減少資料量，但用在中文字上則比UCS-2多了50%(2 bytes vs 3 bytes)的資料量。

維基百科上有關於上述標準的完整說明，有興趣的人可以看看: UCS-2/UTF-16、UTF-8、BIG5、Unicode。另外在台灣，為了彌補BIG5字碼不足的問題，也有BIG5e狗尾續貂，若以與世界接軌的觀點來看，還是應該回歸Unicode，向世界標準看齊才是王道!
(這篇由堃(方方土) 探討 Big5e 編碼的文章，是我了解Unicode的入門讀物，解釋得挺清楚，推薦給大家看)

處理中文亂碼問題，常要檢核二進位資料才能抓出問題所在，所以我寫了一個小工具，可以輸入文字顯示BIG5、GB2312、UCS-2、UTF-8編碼的十六進位資料解析，在檢核編碼是否正確時相當好用，有興趣的人可以按這裡下載。(需要.NET 2.0)

TIPS-如何修改Reporting Service的報表匯出選項

2006-12-15T19:38:00.000+08:00

Reporting Service的每一張報表都可以匯出成HTML、PDF、Excel等多種格式，是很好用的功能。但在某些狀況下，你可能希望限制使用者只能匯出其中的幾種格式。

有兩種做法，如果你希望在停用整個Reporting Service對某種匯出格式的支援，可以修改RSReportServer.config，調整Render Node下的Extension。

如果只想針對某幾張報表隱藏某幾個選項，則可以修改Reporting Services\ReportServer\styles\htmlviewer.css後另存一個新的limitedExport.css，就可以在CSS中動手腳。連線時則要加上rc:stylesheetcommand=limitedExport，就可以讓CSS中的設定或Javascript發威。只是這種做法會在沒有指定StyleSheet時失效，這點要留意!

KB-IIS重裝後的Reporting Service還原

2006-12-14T18:42:00.000+08:00

算是特殊案例，但還是寫出來給萬一遭逢此等不幸的人參考。

狀況是: Reporting Service所在的IIS毀損，但資料庫、Reporting Service的相關檔案安然無恙。重裝IIS後，原本的Reports與ReportServer兩個Virtual Directory當然就遺失了，另外找了一台正常的Reporting Service作為參考，重建Virtual Directory後(注意: Reports的使用權限(Execute Permission)為"指令及執行檔"，而ReportServer則為"無")，連上/Reports，卻得到以下訊息:

The underlying connection was closed: Could not establish secure channel for SSL/TLS.
下列連接已經關閉: 無法建立 SSL/TLS 的安全通道。

Google了一下，找到問題所在。先前在建ReportServer目錄時，對它的使用權限要設"無"就滿心狐疑，心想，明明有asmx，怎麼會是無呢? 後來找到這篇文章，提到了加掛"*"的Appliction Extensions Mapping的步驟，消除了我的疑惑，也解決了問題。Reporting Service又還魂了~~~

KB-VS 2005中拖入自訂網頁控制項時出現錯誤

2006-12-13T18:06:00.000+08:00

在VS 2005中要將自訂Web控件(Custom Web Control)拖入ASPX時發生以下錯誤: (我的經驗多發生在控件改版後)

Control cannot be created because Visual Studio cannot find the control’s type in the control assembly
無法建立控制項，因為 Visual Studio 在控制項組件中找不到控制項的型別。

網路上有不少討論(例如: 這裡、這裡、這裡)，但似乎都跟我的問題不太一樣。最後我找到的解法是將BIN下原本已存在的控件相關.DLL檔刪除，再次拖拉控件時，VS 2005會重新複製一份DLL過去，問題就可以解決了。

KB-失控的HTML物件

2006-12-12T19:55:00.000+08:00

當你在VS 2005中新增一個ASP.NET網頁，預設會套用XHTML標準，也就是你會在頁首看到這麼一列DOCTYPE的宣告: (想多了解一點DOCTYPE的人可以看這裡)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

過渡型的(Transaitional)的XHTML Schema是三種DOCTYPE標準中最隨和的一個，但套用在我們過去慣用HTML的"隨便"寫法上，還是會引發一堆語法警告及錯誤(想眼不見為淨的人可以參考這裡)。除此之外，我開始陸續發現，套用XHTML規格後，在解析既有的HTML Code時，顯示結果有時會有差異。

例如: 我從以前的網頁中Copy了以下這段HTML Code，插入到VS 2005新建立的ASPX中，打算定義一個600x300的TextArea
<textarea style="width: 600; height:300" id=T></textarea>

結果，用IE 6/7看，TextArea會變成只有160x36的哈比人，而且不管怎麼改變width的值，TextArea都不動如山，完全失控。最後我才發現，得修改成style="width: 600px; height: 300px"，它才會正常顯示。

我查了W3C上的XHTML 1.0相容性說明，沒看到這一點，利用W3C的Validator檢查，也未指出此一錯誤。本來的推測是，或許IE解析HTML及XHTML規格的Parser是兩個Team寫的，對這種小細節，雙方處置的標準不一所致，但後來試了Firefox發現也是同樣的結果，因此看來是XHTML對style宣告要求更嚴謹所造成的吧! 不過，先不用緊張要去全面Review HTML Code，反正全世界目前仍有93%的網頁都不符合XHTML的規範，大家就一起同流合污吧!!

總之，若下次網頁移至VS 2005後出現這類異常，記得先將DOCTYPE宣告移除看看。

KB-在Reporting Service群組中顯示頁數

2006-12-06T23:16:00.000+08:00

Reporting Service報表的群組概念十分實用，例如: 若要以報表方式產出信用卡帳單，只需加上Group By ClientId，就可將上百名客戶的數千筆消費記錄，依客戶別彙整成一份份帳單，再整合成一大份報表，方便一次全部列印出來，再分裝寄發。

但問題來了，每個客戶的帳單可能有多頁，帳單印上”第幾頁/共幾頁”本是天經地義的事。Reporting Service中有Global!PageNumber及Globals!TotalPages的屬性，做到這一點似非難事。但是這兩個屬性只能在整個報表的Page Header區使用(也就是只能算報表中所有客戶帳單總頁數)，在Group Header或Detail中呼叫會產生Error，網路上有人試過了Me.Report.Globals繞路法，可以在Group Header或Detail區讀到這兩個數字，但它們的值卻會永遠傳回1。有人想出了Reset PageNumber的巧妙做法，但仍無法知道該Group共幾頁? 我靈光一現，想說何不每個客戶一個SubReport，在SubReport中的Page Header區，總頁數總會正確吧? 很可惜，事情並不像憨人所想的哈泥甘單，SubReport的Header & Footer一律會被忽略而無法顯示，精心想出的妙計又摃龜了。

搞了半天，幾頁之幾這麼基本的要求，Reporting Service做不到就是做不到，我Google了好一陣子，最後自己做過實驗後，終於死心了。由於Group Header跟Detail要全部Render完，Reporting Service才依這些Content的高度算出總共有幾頁，等算出來時，Group Header與Detail的內容早就定死了。故得證，除非Reporting Service改變Rendering的機制，要在Group中取得TotalPages肯定是無解了!! 莫非得砸下銀子改買Crystal Report之類的報表工具才能解脫?

眼看為一個理所當然的小小頁碼，Reporting Service竟形同廢物，心有不甘。我決定換個方向，不再硬碰硬，逃出PageNumber跟TotalPages的死胡同。一個另類的想法是，如果單一份報表中， PageNumber跟TotalPager才能正常使用，那就一個客戶獨立出一份報表吧!

利用ASP.NET設計如下的查詢介面，依User提供的條件，可列出多個客戶的報表連結(每個報表參數不同，等同於多份彼此獨立的報表)，點下連結後可檢視該客戶的報表。這樣就解決了查詢單一客戶報表的功能，足以應付大部分的查詢需求。(如下圖)

然而，這種做法與多客戶帳單組成一份報表，最大差別在於無法一次列印全部的帳單。於是，我從Reporting Service線上列印的功能偷出以下的程式碼，寫成一隻直接印表程式(RptPrint.aspx):

只要在hdnRptSvr及hdnRptUrl中填妥報表相關的網址及參數，RptPrint.aspx就會直接啟動Reporting Service的線上列印功能，跳出選擇印表機的對話框，可預覽報表，或按確定直接列印。(如下圖)

有了這隻好用的直接列印程式，只要在剛才的清單頁面上用javascript跑個for loop，將N個客戶的報表URL當作參數，再以showModalDialog方式循序開啟RptPrint.aspx，就可以一口氣將N個客戶的帳單印完。現在只剩下一個棘手的問題---RSClientPrint.Print()時並不會直接輸出到印表機，而是帶出如上的印表對話框，User必須按下確定後才開始印表。這意味著如果要出1000個客戶的帳單，User得泡杯茶，帶本小說，坐在電腦前等著按1000次確定，既無聊又無奈。

留下這個尾巴，這個解決方案還不算可行。因此我參考IEUnit中威力強大的Win32Dom.Desktoop物件，寫了一個會自動按"確定"的小幫手程式。當要大量印表時，它會不斷監控是否有RSClientPrint彈出的印表對話框，一旦發現，就瞄準"確定"鈕大力按下去，由預設印表機輸出報表。如此，批次印表的流程總算是一氣喝成了!

透過這幾記怪招的巧妙組合，算是克服了頁碼與批次列印無法兼得的困境。但還是祈禱MS能在未來的Reporting Service改版中，從核心層次解決Group中使用頁碼的問題，才是治本之道；在此之前，大家可考慮用這種方法頂著先。

KB-Reporting Service Paging By Group

2006-12-06T19:02:00.000+08:00

Compared to those 3rd party reporting tools (ex: Crystal Report), SQL Reporting Service, which is bundled with MS SQL Server, is almost free and tightly integrated with VS.NET and IIS. It seems the **BEST** option for ASP.NET developers. (Once upon a time, I doubted how Crystal Report can survive?)

After using Reporting Service(RS) at some real, complex, but 100% practical reports, I begin to find features that RS can't support and know why Crystal Report can survive. The most serious problem is -- I can't show page number in group headers.(How serious? It made me want to give up RS and began to survey alternative reporting tools.)

For example, I want to generate credit card bill for 1,000 client, Of course I design a report, using "group by ClientId" to combine several clients' bill in single report. When the client gets his n-pages bill, he surely wants to see the "Page m of n" on the bill header. It's really a common and must-to-have requirement, but I found RS just can't do it!!

You can use Globals!PageNumber and Globals!TotalPages on page header zone to get "Page m of n". But these global properties can't be used outside page header, many smart guys had tried their best, including "Me.Report.Globals!PageNumber" method (failed, it always gets 1/1), resetting page number method (here, here) (it can't get total pages)

Why it's so hard to do so simple work? After some research, I think there is no way to get total pages inside groups! Here's my experiment:

I put three TextBox to trigger log writting and alocate them in page header, group header and list detail area.

Code.WriteLog() will append some information to a log file.

Here's the log:

18:18:39 Group Header
18:18:39 Detail 2301
18:18:39 Detail 2302
... Ignored ...
18:20:28 Detail 2398
18:20:28 Detail 2399
18:20:28 Page Header
18:20:28 Page Header

In the log file, I found the truth!! The group header is rendered only at the first page of group, then details are rendered row by row. Only after all group headers, detail rows are completely rendered, RS begins to assembly group headers, detail rows, calculating content height, split pages and finally gets the number of total pages. When it knows TotalPages, group headers and detail rows are already rendered and can't be modified. So there is no way to know TotalPages inside group header or detail row, unless RS change the way of rendering. (The order of rendering also explained why Me.Report.Globals method always return "1 / 1".) To get total pages inside group, maybe a "preview rendering" is necessary to calculate the total pages, then the "real rendering". But if the height of group header changes (maybe depends on TotalPages) in the "real rendering", then the TotalPages need to be recalculated... (Recursive? orz)

Really hard, right? Maybe it's tough for Microsoft Reporting Service team, too. So this paging by group is not included.

I am still trying to find a solution. The only idea I have is to make the report only for a client, then the PageNumber and TotalPages works fine in page header zone. What if I want to print 1,000 clients' bill? I wrote a ASPX to generate a list of 1,000 report link, use javascript to showModalDialog 1,000 times. In the modal dialog, I use RSClientPrint OCX to print the report.

The only thing we have to worry is RSClientPrint.Print() will popup a printer selection dialog, need user to press "OK" button to print out. The user must sit there, be waiting, and click 1000 times? In IEUnit, there is a powerful Win32Dom.Desktoop class, it can find window in your desktop, get the button on it and click it. Reference the source code, you can write a "OK-button robot", then everything goes fine!

Maybe this solution is a little ugly, but it works. At least, I saved more than 5,000 USD to purchase another reporting tool, but I hope Microsoft can put this feature in the wishlist of reporting service, that's the real way to solve this problem.

KB-無法將放在網路磁碟機的Custom Control加入VS.NET 2003工具箱

2006-11-30T14:36:00.000+08:00

試著在VS.NET 2003的工具箱(Toolbox)裡新增一個來自網路共享資料夾(Shared Folder)或網路磁碟機(Network Drive Mapped to a Shared Folder)的自訂控件(Custom Web Control)時，可能會發生了以下錯誤:

Insufficient state to deserialize the object. More information is needed.
要還原序列化物件狀態不足。需要更多資訊。(中文版)

這個不知所云的序列化錯誤，真正的原因來自於.NET的安全管控機制。在預設的安全原則(Runtime Security Policy)中，來自網路分享的Managed Code，權限會受到限制。網路上找到的一些做法(這裡、這裡)是將Local Intranet的安全等級直接調成FullTrust，省事歸省事，但一口氣對整個Intranet門戶大開似乎違背了"只對絕對必要範圍開放權限"的安全原則，等於認定只要跟你同一個LAN的都是好人，增加了不少被攻擊的風險。

我建議的做法是參考微軟的這篇KB，利用.NET 1.1組態工具，新增一個Code Group Policy，只針對這個放DLL的網路資料夾開放FullTrust權限。設定完成再重新啟動VS.NET 2003，就可以順利將自訂控件加入工具箱了。

女兒的校外活動日

2006-11-27T01:05:00.000+08:00

從今年九月起，我開始多扮演一種角色---學生家長。

幼稚園的活動是多彩多姿的! 前些日子，學校有張通知單說本週六要辦校外登山活動(其實只是政大後山繞一圈，範圍全在政大校園內，但似乎還是得稱為校外活動)，歡迎家長一同參加。由於政大後山是我今年五月展開有機式智慧型程式產生器效能調校計劃的主實驗室，閉著眼睛都可以走完，加上還沒以家長身份出席過女兒學校的活動。因此決定全家一起出動，共襄盛舉!

早上七點不到就把兩個小蘿蔔頭挖起來，跟女兒平日上課的起床時間差不多，問題不大。但對兒子來說就早了點，幸好兒子一向好商量，問他要不要快點起床去爬出，馬上就笑瞇瞇地自己下了床。

8:30到了學校，已屆出發時間，人聲鼎沸。女兒特別得意洋洋地拉著我去看她種的花豆，她那一盆枝繁葉盛，在一群同學的作品中顯得格外高大。不過，小朋友種東西，談不上什麼技巧、用心，只能說這小妮子手氣還不懶吧!

集合完畢，一行人就浩浩蕩蕩向環山步道出發。但很出人意料地，"行軍"速度頗快，完全超脫一般人對"親子活動"錯誤的認知，本以為可以牽著兒子逛大街的我一看苗頭不對，馬上就"裝備上肩"，扛著13公斤的"貴重器材"在熟悉的環山道路上狂奔。

到了後山頂點的涼亭，"部隊"小歇了一陣子。女兒帶她弟弟去之前校外活動去過的小山坡玩滑草，兒子玩到欲罷不能，差點就要抱著樹幹不肯離開，這大概是他從小到大，衣服玩最髒，卻也最盡興的一次野外活動吧! 對我而言，大概也是開始登山以來，負重攻頂的最高記錄! 幸好平日有在運動，雖然汗出如漿，但至少還能不急不喘地走完，沒動用到救護車，體力算是及格了。

忘了提，行前老師有講，我也有在聽，這次的登山活動的目的是為了"尋寶"!! 我一聽到"寶"耳朵就豎起來，但後來發現所謂的"寶"不過是要認識一路上的幾種特色植物! (這這這... 這簡直是騙小孩嗎? 咳! 這位家長，本來就是辦給小朋友的活動，你在激動個什麼勁?)

我一路上拍了幾張"寶物"的照片，你認識幾種呢?

KB-在Oracle中直接取得中文字串長度

2006-11-24T13:12:00.000+08:00

今天接到個頗具挑戰性的需求。

由於轉檔程式要輸出固定寬度的文字欄位，所以要視字串長度在後方補足空白。因中文字在不同Encoding下的長度不同(例如: BIG5 2bytes, UTF8 3bytes)，加上中英文可能交雜，所以用.NET下的System.Text.Encoding.GetEncoding("big5").GetByteCount("中文字串ABC");是最簡便有效的方法(若是VBS、VB6，可以考慮用ADODB.Stream勉強替代)。
不過，問題來了。因為轉檔程式是別人寫好的，改不得，而它只能笨笨地接受從ORACLE資料庫端傳來補好空白的文字內容(這轉檔程式會不會太嬌生慣養呀?)。所以計算文字長度的事情得在ORACLE端搞定，HOW?

如果是SQL Server，我會用Collate處理編碼轉換，用DataLength來取真實資料長度。不過因為ORACLE中沒有直接對應的語法，拼拼湊湊一番，才總算找到解法:

CONVERT Function: 可以將字串轉成不同的Charset
RAWTOHEX Function: 可將欄位內容用16進位表示，所以其長度除2就是原欄位的Byte數!

把這些東西攪在一起，答案就出來了囉~~
(由以下的測試可以看出來，UTF8時，每個中文字要三個Byte，而BIG5只需要兩個)

KB-.NET 2.0 分散式交易新利器---TransactionScope

2006-11-23T16:50:00.000+08:00

古老的ASP時代，要做Distributed Transaction(分散式交易，指跨越異質資料庫的交易，例如: 將SQL Server跟Oracle的更新動作包成一個Transaction)，有個偷懶的方法。在ASP最前端宣告一下<%@ Transaction=Required%>，則整個ASP中的所有資料庫操作，不管Oracle、SQL、Sybase，通通會自動包成Transaction，不用多寫半行Code。

不過，這種寧可錯殺一百，不可錯放一個的做法效能有點鳥(連沒必要的SELECT動作也被包入Transaction)。會寫VB COM的人多半會寫顆Support Transaction的COM+元件，用來執行特定的資料庫的更新。而多顆異質資料庫的Transactional元件可以再包出一個大Transaction。不過，這得另外寫COM，註冊到COM+ Application中，多了些額外手續。

ASP.NET 1.x誕生後，針對分散式交易，提供了一個四不像的做法:
寫一顆繼承自System.EnterpriseService.ServicedComponent的元件，內含更新資料庫的程式邏輯，再設定TransactionAttribute，然後要Strong-Named/Signed，包上COM+的皮，註冊放入COM+ Application中。

呃... 好像比以前寫COM+還麻煩，堂堂的.NET還是得回頭靠COM+才能實踐分散式交易，會不會有點...

終於.NET 2.0中，針對分散式交易做出了改良。System.Transactions.TransactionScope讓大家有機會重回ASP時代的美妙時光，可以將任意一段資料庫操作包成一個Transaction，不需要額外的手工。例如以下的範例: (要Oracle支援Transaction，記得安裝Oracle Service For Microsoft Transaction Server，不然會百忙一場。)

21 TransactionOptions options = new TransactionOptions();

22 options.IsolationLevel = System.Transactions.IsolationLevel.ReadCommitted;

23 options.Timeout = new TimeSpan(0, 2, 0);

24 using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, options))

25 {

26 try

27 {

28 using (SqlConnection sqlCn = new SqlConnection("Data Source=(local); User Id=scott; Password=tigger; Initial Catalog=Lab"))

29 {

30 SqlCommand cmd = new SqlCommand("INSERT INTO tblAccount (Account, Password, Username) VALUES (@acct, @pwd, @name)", sqlCn);

31 cmd.Parameters.Add("@acct", SqlDbType.NVarChar).Value = "EMP" + DateTime.Now.ToString("HHmmss");

32 cmd.Parameters.Add("@pwd", SqlDbType.NVarChar).Value = "PWD";

33 cmd.Parameters.Add("@name", SqlDbType.NVarChar).Value = "NAME" + DateTime.Now.ToString("HHmmss");

34 sqlCn.Open();

35 cmd.ExecuteNonQuery();

36 }

37 //** 實測結果，ODP.NET 9207不Support TransactionScope，必須用.NET 2.0的System.Data.OracleClient

38 using (OracleConnection oraCn = new OracleConnection("Data Source=MYORA; User Id=scott; Password=tigger;"))

39 {

40 OracleCommand cmd = new OracleCommand("INSERT INTO MYTABLE.tblAccount (Account, Password, Username) VALUES (:acct, :pwd, :name)", oraCn);

41 cmd.Parameters.Add(":acct", OracleType.VarChar).Value = "EMP" + DateTime.Now.ToString("HHmmss");

42 cmd.Parameters.Add(":pwd", OracleType.VarChar).Value = "PWD";

43 cmd.Parameters.Add(":name", OracleType.VarChar).Value = "NAME" + DateTime.Now.ToString("HHmmss");

44 oraCn.Open();

45 cmd.ExecuteNonQuery();

46 }

47 //在scope.Complete();後才算Commit!

48 scope.Complete();

49 }

50 catch (Exception ex)

51 {

52 //只要沒有scope.Complete()，先前的動作都會Rollback

53 Response.Write(ex.Message);

54 }

55 }

很簡短吧? (有寫過ServicedComponent的人才能感受出它的好呀!!) 為了證實Transaction效果，我在48行設Breakpoint，則中斷未scope.Complete前，SQL的tblAccount會被鎖定無法SELECT，而ORACLE中則SELECT不到新增的資料(可見SQL用的是Lock大法，ORACLE專攻Snapshot)；scope.Complete後，二者的新資料就都出現了。

同時，我還試了故意ORACLE新增動作失敗或不做scope.Complete()，則SQL的tblAccount的新增資料就不會出現。由此，可以驗證以上的程式的確實踐了分散式交易!! 而TransactionScope的確比.NET 1.x的ServicedComponent方便多了，大幅減少異質資料庫包成交易的複雜度。

我曾試著用ODP.NET 9207取代System.Data.OracleClient，測試結果顯示ODP.NET 9207無法參與TrasactionScope物件所建立的交易。後來找到Oracle的ODP.NET FAQ，提到了從ODP.NET 10.2.0.2.20起才支援.NET 2.0的System.Transactions，想用ODP.NET的人要留意。

最後還有一點要注意，如果你的SQL在遠端主機上，用的又是Windows 2003平台，則還有好幾個關節要打通。包含了MSDTC在Windows 2003 SP1上有些選項要調整。還有，你可能會連線失敗，並得到以下這類訊息:
Communication with the underlying transaction manager has failed.
The transaction has already been implicitly or explicitly committed or aborted.
經驗中多半是防火牆的傑作，我的私房解法是在Windows Firewall上開放MSDTC.EXE程式的所有對外連線，問題就可解決。微軟有篇專題文章，介紹MSDTC與Firewall間的愛恨情仇，有興趣的人也可以去挖挖寶。

KB-VS 2005: 找不到Web Project(.csproj/.vbproj)檔案嗎?

2006-11-20T22:20:00.000+08:00

VS 2005推出的新Web Site Project Model(為了區別，我習慣叫VS 2005的新Model為Web Site Project，VS.NET 2002/2003的則叫Web Application Project)變化還真不小，單一Class檔案不能隨便擺，必須集中放在App_Code目錄下、Code-Behind 變成 Code-Beside、後端程式不需預先Build好，改了.cs/.vb就馬上生效... 坦白說，某些改良在特定情境下還挺方便的，只是我個人覺得微軟有點輕忽了這些改變對熟悉Web Project Model Developer的衝擊，在介紹VS 2005時，對這方面著墨不多。Migration Wizard可以順利將原來的1.1 Web Project自動轉成2.0 Web Site Project，更讓Developer們認定一切照舊，連What's New都懶得翻一翻，結果就在這個變異頗大的新Model中不時碰壁、胡亂摸索，然後罵聲不絕，X聲衝天! (由此可知，新系統在導入時，User的心理建設是很重要滴!)

先前寫過一篇談Web Site Project部署的文章，就是被Publish Web Site功能攪到霧煞煞後的心得。而前幾天，在跟人用VSS Share同一個VS 2005 Web Project時，才赫然發現---我的.csproj到哪裡去了? 沒有.csproj/.webinfo這些檔案，我常用的網站Mapping密技就沒搞頭了。今天，同樣的問題又冒出來，因為VSS操作失誤，.sln中一個Web Project不見了，沒有.csproj，要怎麼重新將Web Site Project加回來??

Google了一下，在MSDN上找到了答案:

Web Site Project用的是File-Based的Project概念，也就是Folder底下的東西自然成為Project裡的一部分，不再需要用.csproj/.vbproj去記哪些檔案Include，哪些Exclude，而一些需要額外記錄的資料則寫在web.config中。所以，Web Site Project已不再需要.csproj/.vbproj了!!

那麼，回到前一個問題，少了.csproj，要怎麼由VSS將現有的Web專案加入Solution呢? 請看下圖:

PS: 或許是因為太多人對Web Site Project適應不良，Scott Guthrie推出了Web Application Project Option，可以讓你在VS 2005中沿用ASP.NET 1.1時代的Web Application Project Model。正式版已在2006-05-08釋出，而它未來將會被包含在VS 2005的SP1裡。要玩VS 2005的人，多了一個選擇。

KB-令人驚豔的.NET 2.0 XmlDocument

2006-11-17T23:49:00.000+08:00

手上有個程式要處理類似以下的簡單XML，DocumentElement之下只有一層，約20個ChildNodes:

.... 省略 ....

</FormContext>

我需要將以上XML中各ChildNode資料取出，而運算頻率還挺高的，要用哪種方法就得講究點。在刻板印象中，我們一直被教導著(尤其是考過MCSD的人)，XmlDocument很笨重，如果只是要查詢，記得要用XPathNavigator取代(雖然語法上囉嗦了許多!)。基於對XmlDocument的不信任感，我甚至想用RegularExpression解析，看看會不會快一點，於是順手做了以下的Benchmark:

string x= @"

...略...

</FormContext>

int totalCount = 50000;

for (int testMode = 1; testMode <= 3; testMode++)

{

Response.Write("<hr><b>");

if (testMode == 1) Response.Write("XmlDocument");

if (testMode == 2) Response.Write("XmlPathNavigator");

if (testMode == 3) Response.Write("RegularExpression");

Response.Write("</b>");

Response.Write("<br>Total Count=" + totalCount);

DateTime st = DateTime.Now;

Hashtable ht = new Hashtable();

for (int i = 0; i < totalCount; i++)

{

ht.Clear();

switch (testMode)

{

case 1: //XmlDocument

XmlDocument xd = new XmlDocument();

xd.LoadXml(x);

foreach (XmlNode n in xd.DocumentElement.ChildNodes)

ht.Add(n.Name, n.InnerText);

break;

case 2: //XmlNavigator

XmlTextReader xtr = new XmlTextReader(new StringReader(x));

XPathDocument xpd = new XPathDocument(xtr);

XPathNavigator xpn = xpd.CreateNavigator();

xpn.MoveToFirstChild();

XPathNodeIterator xpni = xpn.SelectChildren(XPathNodeType.Element);

while (xpni.MoveNext())

ht.Add(xpni.Current.Name, xpni.Current.Value);

break;

case 3: //Regular Expression

foreach (Match m in Regex.Matches(x.Substring(1), "(?ims)<(?<tagName>.+?)>(?<text>.*?)</.+?>"))

ht.Add(m.Groups["tagName"].Value, m.Groups["text"].Value);

break;

}

Response.Write("<br>Get Nodes Count=" + ht.Count);

TimeSpan ts = DateTime.Now - st;

Response.Write("<br>Duration=" + ts.Seconds + "." + ts.Milliseconds);

}

以上的測試方法是用XmlDocument/XmlXPathNavigator/RegularExpression三種方式取出22個ChildNode的資料，存入Hashtable，反覆跑50,000次，並記錄執行時間(Duration單位為秒)。結果讓我大吃一驚!

XmlDocument
Total Count=50000
Hashtable Count=22
Duration=3.468

XmlPathNavigator
Total Count=50000
Hashtable Count=22
Duration=3.546

RegularExpression
Total Count=50000
Hashtable Count=22
Duration=9.593

啥?? XmlDocument比XmlXPathNavigator還快，而RegularExpression慢了近三倍! 難道我被騙了這麼多年??? 忽然想到曾經讀過文章說.NET 2.0對XmlDocument做了改善，於是將同樣的程式搬到1.1上再跑一次:

XmlDocument
Total Count=50000
Get Nodes Count=22
Duration=11.781

XmlPathNavigator
Total Count=50000
Get Nodes Count=22
Duration=4.750

RegularExpression
Total Count=50000
Get Nodes Count=22
Duration=10.859

原來我並沒有被騙，只是時代改變了~~~ 在.NET 1.1的時代，XmlDocument真的比XmlXPathNavigator慢了兩倍以上，也輸給RegularExpression! 而到了.NET 2.0，XmlDocument甚至可能比XmlXPathNavigator還快! 而在2.0的執行的速度也比在1.1跑快26%!

不過，大家要留意，在我的測試中，XML並不大，而且已經以字串形式存在。如果是巨大而複雜的XML檔，結果可能會有差異! 至少，在我這次的應用中，應該可以安心地使用XmlDocument Parse XML，不必擔心遭天讉。

KB-用VS 2005 Build Web Site，總是慢到讓你想哭嗎?

2006-11-16T16:54:00.000+08:00

這大概是所有由VS.NET 2003轉到VS 2005的ASP.NET Developer最重要的感想之一吧! 跟VS.NET 2003時代的ASP.NET Web Application Project相比，VS 2005的Web Site Project Build起來真像老牛拉車，只見CPU猛飆，HD狂轉，以前3-5秒搞定的事，現在沒有個10秒20秒東西出不來，對我這種且戰且走型的Programmer來說，真是痛苦的折磨。

前些日子，看到Scott Guthrie的一篇文章，讓我眼睛一亮，直到剛才有機會試了一下。親愛的史考特，這真是太神奇了! 一個Refrence了四個dll的專案，Build時間足足縮短為1/3(12秒->4秒)，大家看完以下的說明，快點試試吧!

Scott的文章裡提到了一件事，當你的ASP.NET專案參考DLL時，若DLL是來自於檔案(也就是用瀏覽功能去挑DLL檔案)，VS 2005會很"貼心地"自動補上一個yourAssemblyDllName.dll.refresh的檔案，裡面只有一行文字，指向原始參考的檔案路徑，其用意是每次Build Web Project時，雖然BIN下已經有了該DLL檔，VS 2005還是會去原始來源檢查該檔案有沒有更新。若有，會將較新版的DLL檔以及其相依的DLL一併Copy回BIN下面。這樣子，被參考DLL只要一有更新，不勞你動手，VS 2005就會自動抓最新版的回來用。雖然Scott強調的是Dueling Assembly Reference Problem(導因於共用被參考檔的版本衝突)，未必會發生在每個Project中，但那個.refresh的特性，倒讓我想試看看單純.refresh造成的效能衝擊。我找了一個專案，特意以選取檔案的方式參考了幾個DLL檔案，果不其然，.refresh出現了:

開啟專案後第一次Build Web Site耗時12秒，第二次約8秒。接著我將四個.refresh移除，咻~~~ 首次Build大約只花了4秒，之後更是不到2秒，效果驚人!! (剛才在另一台機器不同專案做的實測是25"->10"，快了一倍以上!)

被VS 2005的慢郎中性格氣到吐血的朋友們，不妨試試，再留言分享一下實測的改善效果吧!

KB-ASP.NET 2.0 TextBox.ReadOnly之行為改變

2006-11-16T10:16:00.000+08:00

今天接獲回報，先前寫的控件(繼承自TextBox的數字輸入欄位WebControl)在ASP.NET 2.0下有問題，當控件ReadOnly設為True時，在前端用Javascript修改控件<INPUT>的Value，用Fiddler看，新值明明PostBack回後端了，但是在Server-Side查到的是前端修改前的舊值。

有點懷疑這是ASP.NET 2.0的Behavior改變，用TextBox測試，果然如此!

我的測試是先在Server-Side設定TextBox1屬性
TextBox1.Text=”OldValue”;
TextBox1.ReadOnly=true;
接著前端用document.all(“TextBox1”).value=”NewValue”;改變數值，PostBack後，Server-Side用TextBox1.Text取得的是”OldValue”，同樣的程式在1.1上執行結果為”NewValue”。

Google了一下，印證了這是ASP.NET 2.0的改變，主要是為了安全的考量，因為這樣可以防止前端利用Javascript或其他技巧去篡改已設為ReadOnly的欄位，提高安全性。不過呢，過去有不少專案將加總值等等設成ReadOnly，由JavaScript計算填入再傳入後端。我想若以最高安全標準來看，應該要在後端再重算一次，以免將有心人篡改過的數字寫入資料庫。只是同樣的邏輯要寫兩次(還一次用Javascript、一次用C#/VB.NET)，成本有點高。若該欄位存的是連狗都沒興趣的數字，則便宜行事是可以被接受的(又不是在報特支費發票)，如果你想要找回從前"前端對User設唯讀，但JavaScript修改值可以傳回"的模式，可以試試以下兩種做法:
1.用Request["TextBox1"]的方式取值
2.TextBox1.Attributes.Add("ReadOnly","ReadOnly");

雖然還是有解決方案，但比較煩的是，過去的一些ASP.NET 1.1專案，不少的TextBox.ReadOnly只用來擋使用者輸入，還是接受由JavaScript自動算值後填入；專案轉到2.0，表面上順利無誤，執行的結果可不太妙，全部掃一次Code的功夫看來是少不了，要做1.1->2.0移轉的朋友們要特別留意。

Windows Sysinternals!! Process Monitor 1.0!!!

2006-11-14T23:24:00.000+08:00

微軟用加長型禮車從Borland挖走了Anders Hejlberg(有興趣聽這段故事的人可以看看李維的Borland傳奇)，現在，我的另一個偶像Mark Russinovich也變成微軟人了。(有錢真好!)

Mark Russinovich與Bryce Cogswell經營多年(Since 1996)的SysInternals網站，上面有各式精巧的免費小工具，小小幾百K的執行檔，威力不輸要價數萬元的專業工具軟體，是抓蟲除錯時不可缺少的法寶。File Monitor、Register Moniter在Trouble-Shooting界更可說是無人不知、無人不曉，我自己就有數不清次的成功使用經驗，讓一堆人束手無策的怪問題，FileMon+RegMon一出手，不消五分鐘，問題無所遁形。享受別人稱羨的同時，不免要偷笑，自己又沾了Mark Russinvich的光。

前些日子，由Blog得知Mark Russinovich與Bryce Cogswell加入微軟的消息。今天試著連回http://www.sysinternals.com/，則發現網站已經搬到微軟家裡。微軟不沾了光，還把光環戴到自己頭上哩! SysInternals同時也改名為Windows Sysinternals，將來很有可能這些工具會變成Windows SDK裡的一部分。對我來說，只要FileMon/RegMon不要變成收費軟體，沒啥差別。

不過，不知是否微軟也開始抽調開發人力投入SysInternals工具的研發，SysInternals工具組最近也有了新突破。11/9發表了Process Monitor 1.0，算是把FileMon與RegMon的功能整合在一起，再加上一些Process/Thread的監控功能，過去同時開FileMon跟RegMon再左看右用肉眼比對的時代結束了，ProcMon的出現對茶包射手來說，絕對是一大福音。

希望有一天我也可以寫出讓微軟願意挖角的有名工具程式... 咳咳，這兩天有點感冒，還是早點睡比較實在，別出來胡言亂語。

草湳大榕樹病了

2006-11-10T23:42:00.000+08:00

因為考試、下雨種種因素，已經連著好幾個禮拜沒去爬山。上週日總算趁著天晴，才又重回久違的二格山。雖然幾週沒活動筋骨，還是挑了入口不遠的左叉路，一路由森林上攻，最後與土地公廟路線在南邦寮山(二格西峰)前相銜。此線雖然陡峭，但路程短了不少，因此再次創下新記錄，由大榕樹至二格山頂45分鐘完成。

山上的芒草開了，不知是否受今年暖冬所賜，茂盛異長，比人的身高還高出許多，可惜天雖晴，展望卻不怎麼樣，四望都是灰濛濛的，看來，一望無際的好視野還真是可遇不可求。

回到山下騎車時，這才發現登山界鼎鼎有名的草湳大榕樹，忽然葉子落盡，只剩枯枝。榕樹不是落葉喬木，變成枯樹，恐怕是病了，讓我有些擔心這個許多山友記憶中的老朋友，會不會就此消失。問了讀植物的Lucas，答案是不一定，樹葉落盡的同時，有可能一併擺脫了病蟲害而重生，但也很有可能就此安息。願老天保佑，希望是前者。

TIPS-關掉VS 2005的HTML語法檢查

2006-11-10T18:55:00.000+08:00

Visual Studio 2005支援多種HTML的Schema規範，對HTML格式有更嚴謹的要求。對於要求HTML必須完全遵守某種標準的Project來說是好事，但它預設會開啟HTML格式驗證。結果我從VS.NET 2003轉上來的ASPX，使用HTML檢視時總會出現一堆紅紅綠綠的警告標注，挺煩人的。

龜毛的人可能會選擇將這些不嚴謹的Tag寫法一一校正，但某些配合Javascript前端程式而指定的Attribute(例如上圖中的ISUrl, LeftWidth...)就注定要被貼上無效屬性的標籤。更煩的是，這些警告會跟其他的Build Error一起被列在Task List中，數量龐大，把真正的Build Error擠到阿里山去了。

我的選擇是，關了它! 眼不見為淨，方法是如上圖用右鍵叫出Formatting and Validation選單，然後把HTML Validation的Show Error給關了。頭埋在沙子裡好溫暖哦~~~~

GridView 欠擠 DataGrid, OK ga?

2006-11-07T00:24:00.000+08:00

ASP.NET 2.0問市後，其中有個受人注目的明星---GridView，它以DataGrid接班人的態勢，企圖取而代之(由VS 2005中預設把DataGrid藏起來可見一斑)

其中，GridView最讓人稱道的改良就是以前DataGrid雖然提供了換頁、排序等功能，但仍要自己寫一小段Code。而GridView的換頁、排序等邏輯則全部內建了(其實要靠另一個新控件SqlDataSource幫忙)，光靠設定就可以完全搞定。另外，GridView甚至可以清單項目上編輯後直接更新或刪除某一筆資料(咳，說穿了還是得靠新朋友SqlDataSource，不要幻想DataSource=YourDataTable後就能看到奇蹟)。

理論上，GridView包容了所有DataGrid既有的特性，又加上方便的新功能，既然用VS 2005開發，傻瓜才不換吧?

對一般人來說是無庸置疑的抉擇，對我這種喜歡投時間DIY寫工具的人來說卻未必。因為先前感受DataGrid換頁、排序還要寫Code的痛苦，就開發了一顆名叫ListAssistant的控件，把這些煩人的工作包起來，將清單顯示的資料提供簡化成給DataTable即可，換頁/排序由控件全包。另外，ListAssistant還配合公司環境要求的UI互動模式，提供了額外的支援。比較起來，ListAssistant+DataGrid的組合會比GridView更符合我工作上的需要，但GridView又有一些額外的功能值得期待，值不值得投入時間做出ListAssistant+GridView的組合呢??

引用董大偉先生被ASP.NET 2.0搶走飯碗的Programmer?文章裡的一段話:

… 另外則是採用ASP.NET 1.1作為專案開發的人員(類似筆者這種)。過去我們花了很多心思從ASP轉換到ASP.NET 1.1，沒想到在ASP.NET 1.1才辛苦開發完成的函式庫，到了ASP.NET 2.0後，某些變成基本功能，我要說，心裡除了很X之外，實在也有點佩服微軟，畢竟這是一種進步，過去ASP.NET 1.1上要花長時間才能完成的東西，現在微軟則幫你做好擺在眼前等你享用...

在心裡很X之餘，仔細評估了一下，針對我的應用需求做分析，升級GridView並改寫ListAssistant是值得的嗎? 關鍵在於要了解GridView多了哪些新功能，才能決定成本效益比。所以就把焦點放在GridView多了哪些功能吧! (From: MSDN Comparing the GridView and DataGrid Web Server Controls)

1.Richer design-time capabilities.
最大的演進主要強調換頁、排序功能的整合，由於我的控件(ListAssistant)已提供此類功能，故吸引力不大。而那些在設計階段就可以看到資料型別進行操作的概念，對於較大型的系統，資料源都是執行階段才由DAL決定/提供，很少有人會直接在Page上放SqlDataSource，設Connection String，其實用處不大。

2.Improved data source binding capabilities.
SqlDataSource控件成為DataTable、DataReader之外的新資料來源，它有點DataAdapter的味道，例如要指定SelectCommand、InsertCommand、DeleteCommand、UpdateCommand。GridView而能自動Paging、Sorting絕大部分是它的功勞，而其原理是跟我的ListAssistant很相似，也是將資料全部查回存回記憶體中，再進行Paging/Sorting；EnableCache屬性則可將資料Cache起來，不用每次換頁或排序時都重新查一次(強烈建議要啟用)。原則上，這些功能並沒有超出先前控件所能做的範圍，因此吸引力有限。另外，由於可設Insert、Update、Delete的Command，可以直接在GridView中Edit/Update/Delete這個特性很不錯!
PS: 不要誤會SqlDataSoruce只能連SQL，事實上它支援Support SQL、Oracle、OLE DB與ODBC等多種Provider，只是大家從1.0起就習慣了SqlCommand、OracleCommand、OleDbConnection這種命名慣例，一開始會懷疑它是否是MS偏袒SQL Server所派的紅衛兵。

3.Automatic handling of sorting, paging, updates, and deletes.
跟上一點提的差不多，ListAssistant在1.1時代就已有實作，所以也沒啥值得大書特書的。

4.Additional column types and design-time column operations.
多了BoundField, HyperLinkField, ButtonField, CommandField ImageField, and CheckBoxField幾種新的欄位型式，這點很迷人!

5.A Customized pager user interface (UI) with the PagerTemplate property.
Pager可以100%客製化，由於ListAssistant中己有統一的Pager展現，手上專案則要求所有頁面要一致，所以這條就派不上用場囉!

綜合考量以上的各項特性，ListAssistant+DataGrid的組合跟GridView+SqlDataSource相比，只輸在直接Edit/Delete及新欄位類別等次要的功能上，而預估新特性適用的時機也有限。最後評估，既然功能差異有限，在ASP.NET 2.0上，短中期內打算仍沿用DataGrid，暫無升級/改寫的迫切需求，至於改寫ListAssistant配合GridView一事，就留待機緣成熟囉。

KB-老友歸隊吧! 在VS 2005中使用DataGrid

2006-11-07T00:04:00.000+08:00

ASP.NET 2.0常被拿來大書特書的新特性之一就是GirdView這顆新控件，它是DataGrid的改良版。

目前我手上有不少大量使用DataGrid的ASP.NET 1.1專案，開始陸續轉為ASP.NET 2.0開發。依測試結果，VS 2005在專案自動升級上做得相當不錯，幾乎不用什麼修改，ASP.NET 1.1程式就可以轉為ASP.NET 2.0後如常運作。

向下相容的考驗過關了，可是在VS 2005中發現一個問題: 升級進來的ASPX中看得到DataGrid；開個新網頁，工具箱中卻沒有DataGrid可拉，只看得到微軟大力促銷的新一代GridView控件。過去為了減化DataGrid在Sorting、Paging時還要另外寫Code的麻煩，曾花心思寫了一顆控件叫ListAssistant，原則上只要產生一個DataTable，就可以做到自動排序/分頁，完全不必額外寫Code。由於在ASP.NET 2.0專案中，DataGrid+ListAssistant模式仍有增修的需求，開新網頁時沒DataGrid可用就糗了。想當然，VS 2005還是支援DataGrid的；只是在工具箱中，自然得大力鼔吹大家用新世代的控件，所以預設就沒加入DataGrid，我們得自己手動加上。

我建議在工具箱上加個新的Tab(我取名為Old Friend)以便與原有的控件做區隔。在工具箱按右鍵選”Choose Items”即可帶出清單，用Namespace排一下序，可以發現DataGrid就像Dororo一樣被刻意遺忘了，打個勾就可將它加回工具箱。

另外，原本DataGrid的自動格式化及Property Builder功能一樣可以使用，但要透過右上角的SmartTag小三角型打開選單；直接在DataGrid上按右鍵也會叫出選單，但其中會少了Property Builder功能。

KB-IE6下的網頁縮放解決方案

2006-11-06T23:42:00.000+08:00

你有沒有被使用者抱怨過字型太小?
沒有的人請接受我羨慕的眼光並跳過本篇KB，有的人請繼續往下看。

在網頁設計上，style=”font-size: 9pt;”是很常用的字型標準(事實上，它也是Office、IE等程式預設的選單字型尺寸)。對一些髮蒼蒼、視茫茫的”資深”使用者來說，這個字型卻有點嫌小。雖然可以利用IE內建的字型大小調整功能加以補救，卻可能會因為字型變大時表框尺寸不變，造成文字折行或是排版亂掉的下場，形成不小的困擾。

IE7多了一項不錯用的新功能，在Status Bar的右下角，多了一個縮放網頁比例的功能選單，可以對整張網頁做縮放，而不單單只文字做調整。等於用放大鏡將整篇網頁放大，字變大的同時，仍可保持比例正確，不必擔心版面被破壞。

IE7的功能雖好!! 但等使用者全都換成IE7不知是民國幾年的事，在此之前，恐怕還要被User唸個幾年，有替代的解決方案嗎?

其實，從IE 5.5起就提供了一個style.zoom的屬性，可以任意縮放網頁元素，指定方式是yourHtmlElement.style.zoom="120%"(或是yourHtmlElement.style.zoom=0.5)。將這個屬性套用在document.body物件上，就可以達到全網頁縮放的效果。這種以純Javascript實作的方式，使用者不需要安裝任何額外的元件，也不需要部署。先前雞老大曾介紹過用我的最愛來控制縮放，但要資深使用自己DIY似乎也有點小挑戰，我又再加了點工，把它包成一個AfaZoom.js檔案，任何想要加入放大縮小功能的ASP、ASPX、HTM、JSP、PHP… (扯遠了 :P)，只需在HTML Code的最後方加入以下這列就行了:
<script language="javascript" src="path/AfaZoom.js"></script>

AfaZoom.js提供了以下特性:

按Ctrl-M叫出縮放視窗，縮放視窗會出現在IE視窗的左上角
提供50, 75, 90, 100, 110, 125, 150, 200%等八種預設比例，並支援自訂數字比例。(最大到999%---會想把網頁放到這麼大的人該去看醫生，眼科或精神科)
支援Cookie記憶功能，下次開啟有Include AfaZoom.js的網頁時會自動縮放成指定的大小

我在這張網頁上就放了一個示範，在網頁上按Ctrl-M可以叫出縮放視窗，若勾選”記住縮放比例”時，可以做到甲網頁設125%，開啟乙網頁時，也自動放大至125%。

不過呢，有件很遺憾的事。style.zoom對SELECT物件完全無效，所以會出現字都變大了，但SELECT仍保持原來的糗態(所以，知道為什麼縮放比例選單用的是Radio，而不是下拉選單了吧?)。依IE Team的說法，SELECT不支援z-index、zoom、title等一般網頁元素有的屬性(不支援z-index，所以很多人應該都遇過SELECT莫名其妙跑到動態選單或其他頂層物件上面的狀況吧?... orz)，算是DOM家族中的逆子，也沒得救(是可以考慮特別為SELECT計算出對應的Font-Size、Width去配合，但光用想就頭皮發麻)。所幸，這個問題到了IE7將會有改善，至於它在IE6上的脫序演出，大家姑且睜一隻眼閉一隻眼吧!

PS: 程式尚在草創初試階段，只適用IE(我沒加瀏覽器版本識別)，膽子大的人就拿去用吧! 如果有人發現問題或有其他意見提供，歡迎回饋給我。
<script language="javascript" src="http://darkthread.googlepages.com/AfaZoom.js"></script>

UPDATE 2006/11/10 23:40 發現以上的Script貼在Blogger會導致IE錯誤，所以就先停用。有興趣試試的人還是可以Download回去自己玩看看。

網路如虎口

2006-11-04T00:18:00.000+08:00

沒有做Windows更新的電腦直接曝露在Internet中，可以撐多久?

答案是: 不到四個小時...

以前有幾次經驗，檢查對外IIS的Log時，發現幾乎每天凌晨都有一大串嘗試IIS漏洞的Request，依其頻率及連貫性，判斷應是程式自動發的，而且還分別來自不同的IP，表示不只一個人在網路上用程式尋找犠牲品。我這才第一次發現，看似平靜的深夜，其實卻暗潮凶湧! 即使你不是Yahoo, PCHome等大站，只是給三五好友用，沒註冊DNS的小Web，還是有可能被一群無聊的Cracker(恕我不"尊"稱他們為Hacker，因為有些只是抓了現成程式用用的國中生，不用動啥腦筋，甚至連一行程式都不會寫)以掃瞄IP的方式盯上。

一位朋友基於成本、網路連線速度的考量，打算把原本放在國外虛擬伺服器上的論壇牽回家中，改走ADSL。新Server剛灌好，晚上12點MSN問了我Terminal Service連不通的問題，我跟他說可能是Windows內建的防火牆設定阻攔，請他先關掉試試。不過也提醒他，關掉防火牆很危險的，但得試試才能排除是否為防火牆的問題。由於他要換Monitor才能試，沒等結果我就去睡了。

隔天一大早，朋友跟我說昨天調了PPPoE的防火牆設定後Terminal Service就通了，但Server在凌晨出現"LSA Shell 遇到問題必須關閉"的錯誤訊息，還自動重新開機，我Google了一下，不妙!! 看來像是被Sassar蠕蟲攻擊的結果，電腦剛裝好，沒上Windows Update的機率很高，所以被Worm攻擊的可能性也很大。只是才僅僅數小時就中鏢，速度之快超乎我的想像。我建議朋友快點上Windows Update並加裝防毒軟體，心想幸好是新裝的機器，頂多重灌OS，損害有限。沒想到不久之後，朋友再跟我說他被ISP警告了:

敬啟者 X先生您好：

貴客戶租用之中華電信ADSL帳號HN12345678，遭其他網際網路客戶email檢舉，於2006年某月某日上線期間內，寄發主旨為『Service Deletion Impending donna mason 』之廣告信，為保障您的權益，煩請查證下列可能狀況並參考建議事項：

1.若該廣告信確為貴客戶所為，請立即終止寄發行動。
2.若該廣告信非貴客戶所為(疑似電腦中毒或中後門程式被駭客當跳板發送廣告信時)，

我不確定是否因為機器上開了允許Relay的SMTP Service還是被稙入程式當成跳板，但推論前者的機率較低(因為即使裝了SMTP Service，預設值是不接受Mail Relay的)，若是後者就令人心驚，被稙入程式後，任何事情都有可能發生，說不定還會變成某宗犯罪行動的基地!

由這次事件，我也學到不少，隨手整理出幾條防駭守則:
1.裝好OS，請盡快做完Windows Update並裝上防毒軟體，之後再放上Internet。
2.防火牆功能請保持啟用狀況，永遠只開放必要的Port。
3.網路上的Cracker比你想像的多，不安全的狀態一分鐘都嫌久。

KB-解決Flickr Uploader當機問題

2006-10-26T00:16:00.000+08:00

有用Flickr相簿的人，尤其是只把Flickr當成Image File Storager的Blogger(像我就是: Flickr Uploader上傳->Windows Live Writer+Flickr Plug-In，平時連Flickr的首頁都不進的)，應該都少不了會需要Flickr Uploader這種方便的工具。

現在的Flickr Uploader出到2.3版，網站上註明了For Windows XP，又不是太低階的程式，理論上在Windows 2003上不應該有任何問題。但是安裝完成後，每次新增或拖拉圖檔後，Uploader程式就彈出徹底Crash的錯誤訊息，然後掛點。

最後，我找到了鋸箭解決之道--把程式的相容模式設成Windows NT 4.0 (SP5)，雖然不知道為什麼Windows 2003要設成Windows NT相容才能跑For Windows XP的程式，但是我確定這樣Uploader就不會隨便自盡了，有同樣困擾的朋友可以試看看。

831病毒事件後記

2006-10-25T23:39:00.000+08:00

歷經8月底與不知名病毒的慘烈博鬥後，公司簽約的防毒公司總算在數天之後出了可以識別該病毒的病毒碼更新，得知其代號為Win32.Bacalid(巴卡雷?)，但是防毒程式似乎只能偵測並阻止有毒檔案被執行，並沒有能力刪除或移除病毒，而且當時我查了各大防毒網站，幾乎沒啥關於該病毒的資訊，但總之毒害不會再擴大，我也就沒再繼續Follow。

前幾天，同事跟我說他的主機回報說偵測到有Bacalid的蹤跡，又喚起我的回億，再次Google，發現已經可以找到許多完整的資訊了(有些資料是9/11日以後才公佈的，所以Google不到)。

看過關於病毒的說明，我確認我的確被"巴"了! 其中吻合處包含了:
1.在Temp底下出現vCab.dll(這也是我後來DIY偵測工具的比對依據)。
2.感染EXE或DLL，DOS Stub被修改，長度增加35K。
3.電腦變慢或Explorer會當掉。
4.會下載天堂遊戲的偷密碼程式(難怪後來我的電腦被掃毒程式找出這類怪東西)。
綜合以上的資訊，一切的疑問都有了解答，Case Closed!

另外，試用的結果，賣咖啡(McAfee)的Bacalid Stinger 確實可以將病毒自EXE檔中移除(雖然檔案不會100%還原到原本的大小，可以參考下圖中的winver.exe及winver_virus.exe[中毒後再解毒])，而且可以指定特定目錄做掃瞄，有需要的朋友不妨一試。

KB-將C#程式碼轉成HTML格式

2006-10-25T22:07:00.000+08:00

常常在寫KB、MEMO之類的文件，少不了要附上程式碼讓人參考。在VS.NET/VS 2005的IDE中，關鍵字、註解等等都有特殊的色彩顯示，方便閱讀；而Copy到Word等微軟自家的RichText環境時，它會很貼心地保留顏色及格式設定。但再由Word再轉成HTML就有點小麻煩，一方面HTML Tag又臭又長(我曾寫了個小工具淨化Word轉出來的HTML原始碼)，有時則會Layout大亂，還要不少手工調整。有沒有將Source Code直接轉成HTML的方便工具呢?

有的，同事小熊子介紹過一個CSharpFormat，只要提供純文字的Source Code，可以線上將C#、VB.NET、HTML、T-SQL等原始碼轉成HTML格式。前些日子，在TechEd上認識了小熊子的朋友--"雞"房老板，他的Blog上有篇文章介紹了VS 2005上必備的Add-In，爬了一下文，發現一個好東西，CopySourceAsHTML，可以直接在VS 2005中Copy As HTML，Paste時貼上的就是跟IDE中色彩一致的HTML了，更加方便!! 美中不足之處是它的中文處理有點瑕疵---每個中文字後方都多了一個Big5的十六進位數字(例如: 下圖的'be?)，例如:
//以'a5HJS操'be?作'a7@DOM將'b1N結'b5?果'aaG傳'b6?回'a6^

追了一下Source Code，原來VS 2005在Copy時，有存入一份RTF格式，而它是透過解析RTF格式來保留文字的格式設定(聰明! 這樣只要VS 2005能開出來編輯的檔案格式，它都能原味重現)。只是中文的RTF表示法有點機車，會先用中的Unicode表示，後方再接上'a4?'a4?的Big5原碼，這點大概是作者沒想到的。找到原因，我鋸箭解了一下問題，修改了HtmlBlock.cs，將多餘的文字排掉:

65 //2006-10-19 by Jeffrey

66 //用來跳過中文中後方多餘的字元

67 int skipCounter=0;

69 public void AppendEncoded(char value)

70 {

71 //對於外國文字，&#nnnnn;後方不一定會接

72 if (skipCounter == 4 && value != '\'')

73 skipCounter = 0;

75 if (skipCounter > 0) //&#nnnnn;後方後方的多餘字元，略過

76 {

77 skipCounter--;

78 return;

79 }

81 if (value == ' ')

82 {

83 AppendUnencoded(value);

84 }

85 else

86 {

87 //2006-10-19 by Jeffrey

88 //中文會變成中的格式，後方則會因RTF Parsing問題出現

89 //在此用鋸箭法避開

90 string enc = Tools.HtmlEncode(value);

91 if (enc.StartsWith("&#")) skipCounter = 4;

92 AppendUnencoded(enc);

93 }

94 }

有需要修改版DLL的人可以到這裡下載。使用時請先用CopySourceAsHTML Installer安裝原來的Add-In，關閉VS 2005後，再將My Documents\Visual Studio 2005\Addins\下的CopySourceAsHtml.dll換成修改版就可以了!

不一樣的三角點!

2006-10-25T00:51:00.000+08:00

左邊的照片是兩週來我每天都在爬的山，如果一頁或一題可以換算成一公尺，這座近2000米的險峻大山肯定可以被歸入百岳之列...

前些時候，不知怎麼的，忽然覺得自己很不長進；跨入金融產業一年多了，全部的心思還是放在電腦上，所有空閒、可支配的時間全拿來試軟體、寫程式。當初雄心壯志要跨足到金融界淘金挖寶的，結果SQL 2005上手了，.NET 2.0摸熟了，Domain Know-How卻還是一窮二白。此時，命運做了巧妙的安排! 首先是在檢視新人履歷時，發現了幾個新人有初業(證券商業務員)執照，才稍微了解了一下證券業的證照體系；說來也巧，隔天在討論規格時，提到了一個金融名詞，主管提起這是她在準備初業考試時學到的。這讓我忽然想起十年前在溪邊看小魚的日子... 那個決心要考MCSE認證，而夜夜苦讀NT Resouce Kit的有為青年身影，又在我腦中浮現...

就這樣暗地下了決心，那就考張初業執照好了! 壓力讓煤變成鑽石，在考試的Deadline壓迫之下，應該能逼自己認真看完枯燥的金融教材。(當時一頭熱的我，完全忘了有為青年早已是中年老頭的事實... )

上證券基金會網站花了1800大洋訂了考試題庫叢書，花60塊買了份簡章，然後在網站上預訂了兩個多月後的今天晚上考試，當時的想法是有兩個多月可以準備，又有公開的題庫可以參考，找一天下班從從容容地去把證書"拿"回家就好了。

開始K書的日子是很輕鬆的，心想時間充裕，何況初業設定的學歷是高中職畢，對自己應該是游刃有餘才是。所以蹲廁所時看看，心血來潮時翻翻，一個月、二個月過去了，四本書連一本都沒翻完。而且愈看愈火大: 我又不是趙駙馬，何必知道內線交易要蹲幾年苦窯? 自己也沒本事開一家券商，何苦去記要繳幾千萬交割結算基金給證交所? 之前考電腦證照時可以靠理解、做Lab心領神會；硬綁綁的法規法條、會計原則、財務公式，都得靠死記硬背。更要命的是這才發現，歲月不饒人，過去頗為自豪的大容量"生化HD"，現在已是壞軌一堆，容量所剩無幾。

拖到考前兩週，眼看四本書只看完一本，這才慌了手腳，趕緊改變生活作息，每天早些就寢，四點多就起來唸書。沒想到第三本的投資學、第四本的財務分析比法條更"硬斗"，除了要記一堆公式，每一題都要花大半天按計算機才算得出答案，一小時看不到20頁。看來輕輕鬆鬆應考是不可能了，而週末的爬山行程全部取消，閉關苦讀!! 到考前一天還有一本沒開始看，只好狠下心來，請一天假把進度趕完兼最後衝刺。

凌晨兩點起床，卻到下午才把第四本看完(照片中的兩罐蠻牛應該算我的登山杖吧!)。僅剩的三個小時，只夠再把第一、二本Review一次(說Review還真有點牽強，明明不久前才看過的東西，讀來卻有幾份陌生)，其他就靠這兩天的記憶了。看來1100大洋的報名費這下要化為青煙了~~~

提早到了考場，發現來考的多半是年輕女生，有些的模樣挺像學生的，像我這種老芋仔算是少數。果不其然，考投資學及財務分析時，80題中有超過30題沒把握，當場涼了半截。心想沒做公式整理表、也沒Review，考不過是活該，就當花三倍票價看場兩個半小時的電影好了。按下【結束考試】鈕時一邊想要安排什麼時候重考，還是就此鳴金收兵，反正有被逼到唸到書就好了...

在教室外插入IC卡查成績，等待成績單出來的五秒鐘，真有點像在廟裡拜拜求籤詩... 結果，不知走了什麼狗屎運，測驗成績單上"合格"兩個小字映入眼簾，解脫了，不用煩惱重考的問題囉! 我也應該可以告別"金融小白"的等級，向"小灰"的目標前進。

終於，我征服了這座特別的山，也摸到了它特別的三角點!

PS: 謝謝小娟支援的Casio大台計算機，從沒想到自己有一天會捨Excel不用，在這種會計、行政專用的黑金鋼上敲敲打打，人生的境遇還真奇妙!

KB-相見恨晚的IE Dev Toolbar

2006-10-20T09:28:00.000+08:00

為什麼? 這麼好用的東西我居然到今天才知道??

寫網頁程式的人，難免需要在HTML DOM的茫茫大海中摸索解決前端顯示的問題。我過去常用的方法是利用IE的View Source(檢視原始碼)功能取得HTML Code，簡單的問題直接看TR/TD就可以了；但如果網頁混了一堆絕對座標(style="position:absolute;")的DIV/SPAN，肯定會看到眼睛出血。所以我都會加一列<base href="http://原來的Page Path">，存成本機的HTML後就可用FrontPage檢視試改，還為自己的獨門密技小小得意了一下。

沒想到，早在去年，微軟就出了一個好用的DOM檢視工具--IE Developer Toolbar，可以即時解析目前的網頁DOM，找出各種HTML Tag、在頁面對元素加框顯示、提示CSS class、顯示圖片/連結的特殊資料、放上表尺量長寬... 嘖嘖嘖! 我要說，每個功能都做進了網頁設計工的心崁!! 實在是吾輩日常工作、居家旅行的必備良伴! 多說無益，看完以下的圖例，有在搞網頁的人應該就會迫不及待去下載了。

PS: 愛台灣、護本土的人可以下載中文化版本回去玩。

天梯

2006-10-10T08:46:00.000+08:00

連假的第四天，女兒流浪到阿姨家去小住，今天的活動範圍可以拉大一點。前陣子，Lucas去爬了平溪的孝子山，聽說路程不長，但刺激度頗高。用Papago計算了一下，由木柵到平溪國中約24公里，騎車半個小時可到，3個多小時結束行程應不是問題，因此就決定去一窺"小黃山"的壯麗。

早上六點半出發，由於昨天去爬猴山岳時，再度發生"Oh! My Card!"(揹著1.5KG的DSLR爬到山頂才發現沒帶記憶卡)的慘劇，今天出門前特別再三檢查了記憶卡、電池無誤。但是騎到了半路才想起光顧著攝影器材，居然忘了帶水。不過還好7-11比光華商場普遍多了，路上再買便是了。經過石碇市區時看到一家7-11，但在馬路對面，我懶得迴轉，心想反正7-11比狗還多，到平溪再找就是了。沒想到進入平溪後，沿路就盡是農舍民宅，頂多是還沒開門的柑仔店。到了平溪國中、抵達登山口，也都沒再見到賣水的地方，還好今天路程不長，硬決定著頭皮撐完，回程再說好了。

Lucas上次錯走了慈母鞍那一大段路，其實可由虎嘴口停車場處入山，距離就近多了。今天志在攻克孝子山、慈母峰及普陀山等三大天險，就選擇由停車場入山吧! 我走錯了路，跑到了普陀靈寺停車場，不過似乎還更近一點。寺裡養了一隻黑白狗及白鵝四人組，十分凶悍，只要有生人接近，就會凶狠怒視，不斷發出低吼。千萬別小看白鵝四人組，四隻一起伸脖張嘴，喉嚨發出一長串咕咕的呼氣聲，氣勢可是嚇人的很。幸好我有登山杖在手，用杖尖稍稍指著牠們，對這群小惡煞就足以產生恫嚇作用，不然萬一被喙個兩下，光用想得都很痛! (這幾隻鵝還真是精力十足，後來不管爬到了哪個山頂，都能聽到牠們的叫聲，不知是否有登山客慘遭毒吻?)

孝子山的路程果然不長，沒多久我就爬到了有名的不鏽鋼樓梯處，放眼四望，遠方的山頭正在雲霧間，甚是壯觀，經驗中雲應該很快就會散去，正要快點登頂取景之際，我的"登山獨行俠症候群"發作了...

這些在岩壁上鑿出的石梯，即使有些角度在70度以上，但因為兩旁都有牢固的鐵杆粗繩，只要雙手抓穩並小心腳步，發生意外的機率微乎其微，有人說這是"驚而不險"，十分貼切。但是心理學是很微妙的，當你不是結伴同行，加上四下無人，情況完全不同。由於沒有其他的事務分心，對於高度的恐懼在腦海中不斷被放大，沒人可以交談，無法分散注意，空閒的大腦就"專心地"模擬各種意外發生的情境(最么壽的是，梯腳下的地上居然沒事散著幾張沒燒完的冥紙)，不消五分鐘，我已經沒有任何勇氣再往上爬任何一步，心想就放棄吧! 爬爬慈母峰就好了，但又很不甘心白來這麼一趟。猶豫了十分鐘，忽然不知那裡閃過的念頭，索性將大腦關機、思緒放空，只專心地留意手腳的移動，不知不覺，就抵達了孝子山頂，可惜，在梯腳下的一陣蹉跎，讓遠方的雲也散了，要拍雲海，只有下次再來了。

攻完了孝子山，比較起來，慈母峰與普陀山就簡單多。時間漸晚，也開始看到其他的遊客，許多都攜家帶眷，其中不乏看似只有小一、小二的小朋友，這裡也算是十分熱門的親子路線呢。到了慈母峰，回首孝子山，才能看出了其山勢陡峭，像根牙籤似的從群山間冒出來，岩石摻雜著綠樹，還真有幾份黃山的味道。

在石梯上巧遇登山生涯中第一隻鍬形蟲，看牠在岩石上進退不得，也怕不留神的登山客讓牠變成一張餅，我將牠輕拋到旁邊的樹上。

平心而論，這裡的路程驚而不險，頗豐趣味，挺適合三五好友，或一家大小，"結伴"(咳...)同行，如果時間充裕，還可順路去菁桐老街晃晃，應該是個不錯的半日或一日遊景點。

鐵人。鐵馬。鐵腿。國慶。中秋

2006-10-08T01:14:00.000+08:00

也許是嫦娥托夢，或者是吳剛顯靈，人事行政局忽然在不到一週前發現中秋、國慶間應該要彈性放成連假一下才是王道，急急忙忙在週五晚上宣佈了這項”德政”，讓不少企業、機關搞得人仰馬翻。總之，五天連假就這麼從天下掉下來。

事出突然，也不喜歡急就章地胡亂安排旅遊活動，所以就決定過五天悠閒的生活，當作忙碌上班生活中的小小休止符。昨天早上去爬了睽違了一個多月的二格山，今天早上則提出了申請，將好爸爸行程的收隊時間延長到11點，打算完成一趟木柵-關渡的完成單車鐵人挑戰。

早上不到七點出門，Lucas騎著小白馬，我則跨著銀坦克(咳，車架重、車身低、踏板還會吱拐吱拐亂叫，跟小白駿馬相比，讓我想到史瑞克中那頭驢子)，二人即刻沿木柵路向景美舊橋的河濱自行車道出發。在不服老不服輸的心態下，一路以20-25公里的時速狂飆，快速通過永福穚、馬場町、大稻埕、洲美穚，居然只花了一個半小時多一點就到了關渡，在一群彈簧小馬間宣示50%目標達成! (後來覺得，嚴格來說騎到關渡只能算40%，在體力下滑之際還要騎完同樣的長度，回程才是真正的挑戰)

回程時在高速公路淡水橋下發現國慶煙火的籌備工作區，工作人員正在一艘平底船上將煙火發射管排列整理，這才知道原來發射台是設置在船上的，要施放時再拖到河中央。

隨著離家愈來愈近，雖然還不至於腿軟，但是左膝外側肌肉已開始隱隱作痛，但最慘的莫過於坐了三個小時的硬式椅墊，可憐的屁股痛得凶，只好在扭來扭去跟站著騎間不斷交錯，撐完全程。最後總計花了四小時(含約40分鐘的逗留與休息)，完成里程數60公里的木柵-關渡鐵人鐵馬行! 成績差強人意，但一個下午膝蓋上側的大腿肌肉開始有明顯的酸痛感，之前一再鐵齒自己爬山騎車從不鐵腿，看來這回鐵定是在劫難逃了。

政大附近的萬壽穚在這兩年都會在元旦、國慶時插滿國旗，好久沒見過這種壯觀的景觀了，拍了幾張旗海照。

還記得上週的氣象預報說，今年北部賞月無望，就用這顆看得到玉免的明月打破預言吧! 中秋快樂~~

Scott Hanselman的工具百寶箱(2006版)

2006-09-30T01:11:00.000+08:00

你如果曾留意過，就會發現凡是在江湖打混多年的IT老人，身邊總少不了一些順手的小工具。同樣一件複雜的瑣事，你只會老老實實地敲它數十下鍵盤、加上滑鼠又移又點，一陣手忙腳亂才把苦差事做完。同樣的事交給這些老江湖，他們就是有本事亮出一些不要錢的小程式，兩三個Click就做完你得花半個小時的苦工。再猛的是一些你束手無策的狀況: 網路問題、硬碟掛點、要抓圖、轉mp3之類的，就算有Google也要找上大半天，找到十來樣，也不知哪種最好用又不要錢，但老鳥們總是一出手就能拿出好用又不要錢的程式來... 如果有個人可以推薦各類應用領域的最佳工具，不知可以省掉多少無謂的摸索時間!

.NET Blog界的超人氣巨星: Scott Hanselman(你質疑Scott有何資格被尊稱為名人嗎? 算算他Blog首頁的FeedBurner訂閱人數吧!! 100萬人，夠紅吧!!)一直在維護一張推薦給Developer或Power User的無敵工具清單，2006年版在8月底公布了。快去看看你是否錯過什麼好東西吧!

我這裡以個人的實用經驗，為這份清單錦上添花，強力推薦其中幾個不能錯過的好東西:

* Lutz's Reflector: .NET程式的反組譯工具，看穿別人寫的.NET DLL/EXE只在彈指之間。
* Google Desktop: 簡直就是把Google引擎搬回家，查資料的速度像閃電。
* SysInternals工具組: 如能精通ProcExplorer, FileMon, RegMon，就可以像駭客任務中的尼歐，把各式疑難雜症看成一串串流動的0與1，包你在公司變成救世主。
* Query Express: 跟Query Analyzer幾乎一樣的介面，但只需要一個100K的EXE檔，免安裝，還可以連SQL、ORACLE、OLE DB，對於一般性的SELECT、UPDATE，絕對綽綽有餘。長期被SQL Plus茶毒的人們，快來接受救贖吧~~
* fLogViewer: VB6寫的Log分析程式，可以用Regular Expression, LIKE條件等做簡單篩選。令人驚訝的是這隻VB6程式處理起大型的Log檔(近百MB)，仍具有相當好的效率。
* Fiddler: 想知道為什麼瀏覽網站時會忽然HTTP 404，或是想確定該死的AJAX Code到底有沒跟後端連線? MS IE Team工程師寫的超強HTTP偵錯工具可以助你一臂之力。

最後狗尾續貂一下，再介紹兩個好東西:

* StarDict : Scott Hanselmen當然無法了解非英語系國家人們的痛處，閱讀生澀的英文文章時，好的即時英漢字典，會追隨你的滑鼠，滑到哪，翻譯到哪，這才是王道呀! 我知道講到這個，大家就會提到眼博士，但是有買版權的朋友請舉一下手給我看。不想昧著良心當海盜的人可以試試StarDict，我認為並不會輸給千把元的商業軟體太多。唯一美中不足的是這套軟體有個俗夠有力的中文名稱--星際譯王!!(咳... 聽來像是大陸人取的，不覺這跟"金山詞霸"有異曲同工之妙嗎?) 安裝說明可以參考這裡。(注意: 字典檔下載時，附檔名會變成tar.tar，要改成tar.gz)
* Ethereal: 如果你懂網路，對封包、Socket有點研究，不要錯過這個窮人的原子彈，功能不輸一套數十萬的專業Sniffer，卻完全免費。

KB-活用Visual Studio的Task List

2006-09-28T11:23:00.000+08:00

幾乎所有使用VS.NET或VS 2005的開發者都知道Task List的用法，也就是在Build Project時，所有出錯需要修正的地方都會列在Task List中，並分為黃色(Warning)跟紅色(Error)，在Task上點兩下IDE就會幫你開啟有問題的程式檔，並把游標移到出問題的地方，真是方便到不行!!

其實Task List還有一個較少人知道的用法，我們可以定義一些自訂的Task類別加以列管! 例如: 我最常遇到的情況是程式寫一寫，有一段因為規格還不清楚或需要的元件還沒做好(或是因為太難寫，先用鋸箭法，並立下志願有朝一日，"而且有時間的話"再好好Refactoring一番，咳~~)，會先寫一段替代性的程式，註上TODO，等待日後再補上或修正；另外一種情形，則是為了DEBUG而臨時加的測試Code，我都會加上DEBUG字樣的註解，等測試完再一一刪除。

在沒有特殊工具的情況下，我們可以用尋找文字的方法去逐一找到所有TODO、DEBUG之類的特別註記，但Task List提供了更便捷的做法。例如下圖，只要將Task List的類別切成Comment，所有標註特殊註解的程式碼立即化身為一項項Task，馬上就能享受與"待修正錯誤"Task同等級，點兩下就送到眼前的VIP服務!

哪些註記會列為Task呢?? 系統提供了一些預設的特殊註解標記(Token)，當然，Token也可以自訂。大家不妨善用這些功能，讓你的程式碼管理更上一層樓! (不過，有時看到滿是TODO的特長Task List，心情會忽然不太好，是小小的副作用就是了)

TechEd 2006 Day 2 Sharing -- 從網頁開發者角度看IE7

2006-09-20T21:37:00.000+08:00

IE7的RC1已經開放下載了，不久後，End-User就要陸續迎接IE7所帶來的新功能及花俏把戲，但不少經歷過XP SP2 Release的Web Developer可能已經矬著等了，擔心重演User一更新完Browser，網站就不能使用的災難。

今天聽了一堂IE7的介紹，但我的觀察重點不在於新功能，而在於Developer要如何因應IE6->IE7的改變。很意外地，我個人的評論是好消息勝過壞消息。以下是我的觀察報告，先說壞消息:

Cross-Domain Security限制更嚴苛了! 不過這主要是為了防範XSS(Cross-Site Scripting)攻擊(參1, 參2, 參3)，一般網站在設計時應該不會也不該走這類巧門，影響應該有限。
High Assurance SSL的網站URL會用綠色顯示，這表示當大家都申請了新式的高信賴度SSL憑證時，沒申請的網站就可能因為URL顏色不夠綠(咳...)而受到歧視，屆時網站主非破費申請新憑證不可。
基於安全的理由，網頁中若內嵌ActiveX Control，User將會收到更多的警告及確認。如果是Internet User都會用到的網頁中有用到自行開發ActiveX Control，花點錢取得憑證為控件加上數位簽章會是較佳的解決方式。

接著，說說令人振奮的好消息:

網頁顯示可自由縮放: 對於內容豐富的網頁，9pt Font Size一直是我的最愛。不過後來才驚覺，這對不少開始老花的中年User十分不友善。User多半會將IE的字型調大自力救濟，但是字型的調整會造成版面配置脫離原先的設計，最慘的狀況是Button被擠到火星去，然後不久就會接到抱怨電話。IE7中的網頁可以像Word或Excel設定不同的檢視比例，字要多大有多大，也完全不用擔心配置錯亂。
IE6-的網頁列印在處理大網頁時，常讓人氣結! 要不是右方被裁了，就是右方超長部分被分印在第二張上。IE7的列印可以自由縮放網頁大小，使其可以印在一張A4紙內，甚至也可以自由決定要列印的範圍。有了這個功能，Developer遇爾可以偷點懶，不需再為一些大型網頁另外做列印用的版本。
IE7的CSS效果顯示有兩種模式: quirks(向前相容)及strick mode，網頁相容性問題多半出在strick mode，而IE7判定是否要用strick mode則由DocType宣告決定，所以想要完全避開這個困擾，留意一下DocType宣告即可。

再來，雖然對Developer設計網頁關聯不大，我還是整理一下IE7一些吸引人的新特性:

後知後覺了數年，IE終於內建支援Tab功能了，同一個IE視窗可以同時開啟多個網頁，並以Tab切換。我的最愛、首頁所設定的對象可以是多張網頁，不再只能設單一的URL。(開啟時也會同時開多個Tab)
瀏覽到有提供RSS的網頁時，Toolbar上的RSS Icon可以直接帶出可訂閱的RSS Feed。
可以整合多種Search Provider(Google, Yahoo, ESPN, Amazon, eBay...)，修改Registry可以連結任何以QueryString傳入關鍵字的查詢網頁。
protected mode: IE中的程式在執行時，要寫入HD的檔案會被導到user\Temporary Internet Files\Virtualize目錄下，程式會以為寫入的真的C碟，但實際上個虛擬的環境。這樣可以有效封鎖可能的破壞性。
所有安裝的ActiveX及Plug-In用統一的介面，決定哪些啟用或停用。
Windows Defender會自動掃瞄下載的檔案是否有木馬、間諜程式。
支援最新的CSS及W3C標準，使用CSS就可以做出固定位置的背景圖、半透明、光暈...等效果，對美工製圖的依賴降低不少。

KB-ThinkPad! 把Windows Key還給我~~

2006-09-20T16:07:00.000+08:00

在TechEd 2006上看Vista Demo時發現一個很炫的功能，切換視窗時(即傳統Alt-Tab的切換動作)，可以讓視窗變成一張張直立的照片，然後像摩天輪一樣轉動供User挑選。(這功能的學名叫Flip 3D[介紹在網頁最下方] )
回家開進ThinkPad T43的Windows Vista，試了半天卻只有傳統的Alt-Tab可用! 認真地Google了好久，才發現它要按Windows鍵+Tab啟動，但... ThinkPad的RD工程師們，在設計這樣一台高檔Notebook時，卻很堅持地認定Windows鍵是廢物，所以決定為IBM公司出貨的每台NB省下一顆Key的成本，這下可糗了吧?
所幸，IBM應該是被罵到臭頭，網站上找得到一個工具(Keyboard Customizer Utility)可以Remap一些較少用的Key(例如: 右方的Ctrl, Alt)當成Windows Key。裝好並啟動後，小黑終於有Windows Key可用了...
不過，又掙扎了一陣子，終於又認清了一件事實，Windows Vista的這類特效需要"高檔顯示卡"的晶
片才能展現出Vista Aero效果，並且只有在Theme使用Windows Vista Glass(T43只能用到Windows Vista Basic)時才有資格用Flip 3D, 而T43使用Intel 915晶片組內建的顯示晶片，功能太鳥，無法支援。再會吧！ Flip 3D~~~
PS: 我從來認為商務用途的Notebook又不拿來玩3D Game，使用MB內建的晶片組應該綽綽有餘吧! 看來IBM、Intel與我都沒猜到MS這招!

TechEd 2006 Day 1 Sharing

2006-09-19T23:51:00.000+08:00

屈指一算，從改變我一生的TechEd 97起算，這是第十個年頭參加TechEd了，今年的TechEd比起前幾年來"樸素"許多，沒有Show Girl、沒有開場舞、沒有學員Blog、也不太有額外的活動(雖然我對這些花招向來興趣缺缺)，是主事者換人? 還是"公務機要費"的申報程序變嚴了?? (哈!)

看了一下課表，我最近才開始重用也最感興趣的Visual Studio 2005及.NET 2.0看來在2006年已是舊聞了，今年課程焦點多放在尚未上市的Vista、.NET 3.0、Office 2007及SPS 2007...等新產品。Keynote Speech裡仿"反恐24小時"拍的情境短片很有意思，而本土MS表演的WPF、Excel 2007、Exchange Voice Integration也讓人印象頗為深刻。

今天聽了.NET 3.0 Overview、Office 2007及WSS 3.0，以下我就以QA的方式分享一下我的心得(以淺顯易懂的常識性介紹為主，要再深入我也沒轍)

Q1. 靠! .NET 2.0都還沒開始學，最近冒出來的.NET 3.0又是怎麼一回事，要搞死人嗎?
A: 免驚! .NET 3.0是行銷名詞，代表.NET 2.0加上WPF、WCF、WF、CardSpace四套Framework，基本上.NET 2.0核心完全沒變，只是多了幾個裝滿好用類別的新Namespace。

Q2. Window Presentation Foundation是什麼?
A: 它是XAML語言為基底，一種描述影像、音效... 等等Presentation Layer的XML標準。這個新標準有幾項迷人的特性:
1) 程式師與美工設計師可以分別用Visual Studio跟Microsoft Expression修改同一份XAML，而不會發生美工把程式搞垮或程式師把配置弄爛的衝突。(ASP時代有類似經驗的朋友就知道我在說什麼，哈里路亞!)
2) 同樣的XAML設計，可以直接套用在Window Form及Web上(透過類似Flash Plug-In的方式，WPF/E)，二者的表現結果將會完全一致。(MS要進攻RIA市場了)

Q3. Windows Communication Foundation又是什麼?
A: 過去，要做跨機器的溝通，並同時處理Transaction等議題，有很多種選擇: Web Service、.NET Remoting、CORBA、MSMQ、MQ Series... 走不同的管道有不同的寫法，程式碼寫起來又臭又長。WCF提供統一而簡單的Channel概念，只要改改Config，就可以從原本走Web Service，馬上換成.NET Remoting，程式碼一行都不用改。(個人覺得，WCF取代了靠行COM+的半調子EnterpriseService物件群，算是功德一件)

Q4. Windows Workflow Foundation是會讓Flow廠商矬著等的殺手嗎?
A: Workflow真的很好用，除了刻板印象中的電子表單傳簽之外，企業裡一個步驟接著一個步驟的營運流程(銷售、採購...)，電腦中一個動作接著一個動作的操作程序，都可以用Workflow的概念去分析、實作。所以，MS出了這個WF以提供實作Workflow的重要基礎。但為了化解流程軟體廠商(包含MS自己的BizTalk)的疑慮，MS詮釋說WF像是引擎、輪胎，要能開上路，還有一大段功夫；而流程軟體就像設備豪華的汽車，二者不能相比。(嘿... 不過呢? 要買一台裕隆馬上開，還是自己用Benz的引擎+米其林輪胎組一台夢幻跑車? 每個人的答案未必相同吧!)

Q5. CardSpace? 那是啥?
A: MS的Passport Service固然提供了世界通用的認證機制，但所費不貲，而且帳號資料及管理權完全在別人家中，大部分的企業都會有疑慮。(我向來也都用類似的理由質疑ERP ASP的發展性)
CardSpace回歸以SmartCard(晶片卡)為核心的身份認證技術，開發者主要的職責則在於如何與其溝通，識別使用者身份。

Q6. 今天的Office 2007 Demo中有哪些新功能很吸引人?
A: Word 2007 - 1) 新格式docx有自我壓縮功能，44M->3M 2) Mouse在不用的樣式選單上滑動時，可以立即看到效果，不需真的套用就能看到(當然，電腦要夠快才會順暢) 3) Office2007全系列使用Ribbon式的選單系統，要時間適應，但習慣後非常順手[參考]
Excel 2007 - 1) 圖表樣式、效果種類大增[參考] 2) 在一堆Cells中挑出前10名、以顏色深淺、箭頭、燈號表示數字大小...等酷炫的BI式應用 3) Row數放大16倍，Column數也放大64倍，可以編輯更大張的試算表(但願你有夠快的CPU及夠大的RAM)
PowerPoint 2007 - 傻瓜式的智慧圖形，自動將條列文字變成向上箭頭、金字塔、齒輪等表現手法。[參考 SmartArt]
Outlook 2007 - 1) RSS訂閱功能 2) Sharepoint整合 3) 多人行事曆合併顯示，找空閒時間較方便

KB-To Delete DataRow via DataAdapter

2006-09-14T14:37:00.000+08:00

用DataAdpater+CommandBuilder來新增、修改、刪除資料真是件爽快的事兒，但過去我用它Update資料的經驗不多，所以今天在處理刪除時，出了點問題。
我先簡單介紹一下如何用DataAdapter來更新資料吧!
例如:

//建一個SELECT Command
OracleConnection cn=new OracleConnection("Data Source=ORA;User Id=Blah;Password=Blah");
OracleCommand cmd=new OracleCommand("SELECT * FROM myTable WHERE PK=:pk",cn);
cmd.Parameters.Add("pk",OracleDbType.Varchar2).Value="123";
//用SELECT Command建立DataAdapter
OracleDataAdapter da=new OracleDataAdapter(cmd);
//用DataAdapter建立CommandBuilder
OracleCommandBuilder cb=new OracleCommandBuilder(da);
DataTable dt=new DataTable();
//查詢資料庫後取得DataRow
da.Fill(dt);
//改改資料
dt.Rows[0]["Col1"]="100";
//另外新增一筆
DataRow newRow=dt.NewRow();
newRow["PK"]=555;
newRow["Col1"]="123";
newRow["Col2"]="ABC";
dt.Rows.Add(newRow);
//要在DB上完成以上的更新及新增動作，只要這樣做就可以
da.Update(dt);
//感謝DataAdapter與CommandBuilder!!!

很簡單吧! 舉一反三，我要刪除資料時，就寫了
dt.Rows.RemoveAt(0);
da.Update(dt);

結果資料還是好好地躺在DB中，啥事也沒發生。
原來，DataAdapter要更新資料時，會以DataRow的RowState來決定要新增、修改或是刪除。如果我們把DataRow從DataTable中拔掉了，DataAdapter當然不知道有一列待刪。正確的寫法應該是:
dt.Rows[0].Delete();
da.Update(dt);

參考資料: http://blog.yam.com/thinkingmore/archives/691002.html

KB-SQL 2005資料庫維護計劃要如何設定檔案保存期限?

2006-09-11T23:26:00.000+08:00

SQL 2000一堆簡單易用的管理介面與精靈應該是許多IT新手的最愛吧! (不過，這也讓許多還沒準備好的新鮮人就當起了堂堂的DBA，塞翁得馬，焉知非禍?)
以資料庫維護計劃(Maintenance Plan)來說吧，幾個步驟設定一下，整個資料庫的日常備份機制就算建立起來了，其中我覺得特別好用的是還可以設定備份檔要保存多久，過期的自動刪除!

SQL 2005的介面改了許多，SSIS更是大幅翻修到DTS老手們快要吐血身亡。所幸還是有維護計劃，也有精靈可以選選備份及維護的選項建出維護計劃。但是... 怎麼沒地方可以設定備份檔案的保存期限呢?
不知道什麼原因，SQL 2005的維護計算精靈遺漏了這個選項，得自己手動加上。在維護計畫上按右鍵，選擇Modify打開SSIS編輯介面，在Pipeline後端接上個Maintenance CleanUp Task，就可以設定保存期限並自動刪除過期檔案了。(謝謝Ryan君的火力支援)

KB-ASP.NET 2.0 網站部署的變革

2006-09-05T11:00:00.000+08:00

VS 2005提供了Wizard可以將ASP.NET 1.1 Project無痛升級成ASP.NET 2.0，讓人覺得二者似乎沒啥不同，直到你將網站部署到正式環境時，才會發現人事己非。

在ASP.NET 1.1中，VS.NET 2003預設是用Code-Behind的方式，將所有的aspx的.cs Build成單一顆DLL，若要更新cs時，Rebuild再把dll Copy到正式機即可。如果你還想用這種方式處理ASP.NET 2.0網站的更新，包你傻眼!

ASP.NET 2.0在Code-Behind的概念上悄悄地做了大改變! 首先，ASP.NET 2.0用的是Code-Beside，而不是Code-Behind，也就是.cs直接放在網站上，使用者瀏覽頁面時才動態Complie。這樣的好處是，當你要改.cs的程式時，不須要重新Build DLL出來，只要直接改.cs的內容即可。(又回到ASP時代的方便性了，真是十年河東、十年河西...) 當然，大家馬上想到，那程式碼豈不被看光光?? 這就是方便的代價，如果你要保護.cs的程式邏輯不外露，則ASP.NET 2.0提出了一種Precompiled Web Site的概念(完整的Precompilation Model說明比較可以看這裡)，就比較接近原來Code-Behind的精神。.cs會被事先Compile成DLL，這樣就只要部署aspx與dll到正式台上就可以了。

我們看一下，Code-Beside的網站會長成這樣:

(注意: 在ASP.NET 2.0中，與ASPX無關的獨立.cs要放在App_Code目錄下)
Precompiled Site則像這樣: (每個目錄一個.dll)

而要部署ASP.NET 2.0的網站到正式環境，有四種選擇:

1) XCOPY: 就是直接將檔案COPY過去，但預設的Code-Beside方式會有.cs外露的問題
2) Copy Web Site: VS 2005內建的工具，可以比對檔案新舊作同步，也可指定同步特定的Folder、File，但一樣有Code-Beside的.cs外露Issue。
3) Publish Web: VS 2005會進行Precompile的動作，並將aspx, dll檔案複製到遠端的主機上。但是，我們沒法選擇只更新某幾個檔案，一律全部覆寫!! (包含web.config，額外Copy過去的東西也會被幹掉)
4) Build Setup Project: 建立一個專案，產生MSI自動安裝檔，但如果並不打算做大量部署時，這有點殺雞用牛刀的嫌疑。

老實說，以上三種方法中，3)比較接近實務的需求，但是每次都要"全站更新"的設計叫人不敢恭維，網路上不少人抱怨這一點，也有些改良的建議。其中我覺得較可行的方式是先Publish Web到Local Disk後，再選擇只Copy其中部分檔案到正式機。暫時我會先採行這種做法，等待將來有方便的Add-On或工具問市再說。(Publish Web Site時有個選項是"Use fixed naming and single page assembllies"[參見下方的圖]，則每個ASPX會有其獨立的DLL，名稱也會包含ASPX的名稱以資識別，這有利於我們只更新單一的ASPX或其.CS邏輯，在實務上可以減少更新時Web Application需要重新啟動的範圍。但是網站大而ASPX很多時，DLL數目會多到嚇人是一大缺點。)

最後補充一點，Precompiled Site還有一種特異功能，可以連aspx的內容都全部藏起來，網站上放的aspx會是只有一行文字的空殼子，這應該是保密到家的最高境界了，做法是在Publish Web Site時，取消"Allow this precompiled site to be updatable"。

根目錄下會出現PrecompiledApp.config，bin下會出現幾個.compiled

此時開啟.aspx檔瞧瞧，其中只有一行文字。這個檔案只是用來讓IIS不要判斷檔案不存在而傳回404 Error，真正的HTML內容都藏在DLL裡去囉。

病毒震撼教育

2006-09-02T23:58:00.000+08:00

起初，我只是要幫忙看看網路問題而已，真的!

公司有個部門幾天前換了IP，就開始陸續有人回報某幾程式不能跑或一些奇奇怪怪的狀況。原本推測應該是改IP、網域信任之類的問題，卻一直無法找出直接關聯的證據。最後網管將問題縮小具體化為，有一支放在File Server上的程式，某一樓層的可用、另一樓層的人只要一開啟，我的電腦及一些日常操作就會變得極慢，例如: 用檔案總管下按F5 Refresh時，系統就Hang了，但若點一下其他的開著的程式(什麼都好，例如: Notepad，用Developer的角度詮釋就是讓檔案總管Lost Focus)。由於前晚網管人員忙到十點都無法解決，今早我就接到指令去幫忙看看。

由於剛換過IP，有問題的程式又會去讀取網路分享的檔案，一開始我也朝網路方式偵辦，但由一路蒐集的線索，很快的就把網路問題給排除了。理由是，1) Net Use等測試OK，而且只有在跑過問題程式後，才會發生Hang的情形，只要Logout再Logon Hang的狀況就消失 2) 在放問題程式的目錄下，有另一個免費軟體，用來查郵遞區號，跟問題程式一樣是用Delphi寫的。

莫非Delphi程式都會這樣，請RD寫了一個Hello World Delphi小程式測試，卻是正常的，看來並非Delphi的問題。難道是病毒?? 一時要不到問題程式的原始檔案比對，我設法找到了郵遞區號的1.12版程式，發現它也可以正常跑，會Hang的郵遞區號程式則1.14版。很好，比對了一下兩個程式的二進位碼，發現一開頭就有很大的差異，1.12版有This program cannot be run in DOS mode的Win EXE檔特徵，1.14版則沒有。對EXE檔結構雖沒深入研究，但也看出些不對勁，我心想，小改版應該不會變動這麼多才對，莫非用不同版本的Delphi或不同的方法去Build的? 但實在找不到1.14版來比較。回頭再問了一下問題程式是否有原始檔案可以比對，還是沒下文，我想算了(這是我犯的第一個錯誤)，把檔案帶回去研究看看好了。

檔案Copy到我的機器上後，心想，這些檔案歷經市場上兩大品牌防毒軟體的檢驗，應該有毒的機率很低(這是第二個錯誤)，仗著我的機器有裝防毒及Windows Defender，先執行了1.12版ZipCode程式OK，再試1.14(這是第三個錯誤)，並不會Hang住，但速度略慢，但開始有些怪事發生了，桌面(Explorer.exe)忽然結束又重新啟動，然後在事件檢視器中出現Windows Defender發現疑似木馬行為(mssbupx.dll有可疑活動及Windows Socket 2.0 Non-IFS Service Provider Support Environment服務啟用又用的System Event)。

最後發生了一件事，證實了我的疑慮:
我中毒了! 我中毒了! 我中毒了! 我中毒了! 我中毒了! 我中毒了! 我中毒了! 我中毒了! 我中毒了~~~
在執行1.14版時，UltraEdit通知我1.12版的檔案被更改了! Reload之後驚覺cannot be run in DOS mode的訊息不見了，取而代之的是"PE" NT Signature的程式碼段。

心涼了半截! 此時我得蒐集事證，確認是病毒後通報網管人員做緊急處置。
我使用File Monitor側錄，在Windows目錄下找到了一個只有5K的WinVer.exe檔做誘餌，果然蒐集到足以起訴它的呈堂證供。

這是段犯罪實錄呀! Explorer.exe在檔案後方加了30K的資料，並在EXE檔第64 Byte起插入768 Bytes(這就是cannot be run in DOS mode消失的原因)。接修改檔案長度及把最後更新時間切回修改前的樣子。有了這個，我可以確定Explorer已被病毒附身了。[關於這個病毒的研究心得，我寫在前一篇Blog中了]

通報了網管組的主管，並將被感染的WinVer送交給他們轉送防毒公司。公司開始封鎖疫區，採行一些緊急措施，防止傷害擴大，而無辜的IP更換作業也終於卸下了揹負多日的黑鍋。

防毒公司的反應讓我有些失望，心想連我都可以抓到明確事證，確認是病毒，至少是具有感染性的程式。兩家公司的第一時間反應，似乎就只是用自家的防毒軟體掃一掃，沒查出有已知的病毒，就給了回覆。說什麼經掃瞄後未發現病毒(廢話，掃得到還要通報你們嗎?)，但判斷該程式有可能具有惡意程式，建議不要使用。咳... 所有送交給他們的程式應該都可以套用這個回覆吧?? 再協調爭取的結果，有簽六小時緊急處理時限的公司拒絕承認這是病毒，真是高招，只要在做出解毒劑前二小時再承認就永遠不會違約，好個射箭再畫靶! 另一家未合作的公司則給了二個小時內交付解毒程式的承諾(當時便很懷疑，二小時會不會太短? 後來證實，這比像業務搶案子時的豪氣干雲)。結果是，合約廠商在48小時後總算出了具有偵測能力的病毒碼更新，競爭廠商則仍然沒消沒息。不禁要小小埋怨，連我都能精準抓出感染過程，一家防毒公司想必精通組合語言的高手如雲，又有標本可供研究，我原本預期的解藥製程應在12小時內，居然花了兩三天還沒能100%除根，實在太讓人失望了!!

筆都丟完了。好，平心靜氣，我們還是要來檢討這次的處置過程。對自己研判問題、推理原因及善用工具的表現，並在一天內提出足夠的事證，讓網管人員能及早針對病毒做因應，我給自己80分的高分。但從另一角度來看，我卻犯下了幾個愚蠢的淊天大錯:
1) 當懷疑檔案被感染時，我沒有堅持要到原始檔做比對；郵遞區號程式有版本的差異，讓目已鄉愿地找了藉口，坐視在第一時間咬定是病毒的機會溜走。錯失了時效，還導致後來惹毒上身。
2) 在懷疑檔案有毒的狀況下，我選擇相信防毒軟體，而忽略自己的直覺。Remember what Fox Mulder said, "Trust NO ONE!"
3) 我居然笨到用自己的本機去跑嫌疑的檔案，這種危險的事，叫VM出來當替死鬼就得了。
總結下來，這堂病毒震撼教育，我只給自己49分的難看分數，但由這場戰爭中，我有了全新的體認，下次，我一定會做得更好!!

跟防毒公司比賽--黑暗版的病毒警告

2006-08-31T13:07:00.000+08:00

這幾天為了一個幾家防毒軟體大廠都還無法偵測的病毒(或是SpyWare?)搞得人仰馬翻。因為現成的防毒軟體到目前都還沒有解決方案，這裡就先提出我的觀察心得讓大家知道。不過，我並非病毒專家，以下只是個人見解，大家參考就好，不負任何保證責任。

【症狀】
執行了有毒的檔案後，”我的電腦”或”檔案總管”(Explorer.exe)的動作會變慢，在某些機器上甚至系統會Hang住一段時間。之後你用檔案總管去開啟任何Folder(包含網路分享的Folder，這是它主要跨電腦傳播的管道)，如果其中有EXE檔或是DLL檔，就會受感染，改寫檔案，並在後方加上約26K的病毒碼。

進階說明:
被感染的EXE/DLL檔案，如果用UltraEdit去看二進位資料，會發現原本在第64個Byte起不久應該有一段Window程式專有的”This program cannot be run in DOS mode”訊息不見了，取而代之的是P(0x50) E(0x45)的NT Signature及程式碼。
例如: 正常的EXE程式

感染後的EXE程式

【行為分析】
n            受感染時，機器會變慢，並利用檔案總管傳播感染本機或遠端分享目錄的EXE/DLL。但現在的觀察，並不會全面性的主動掃瞄傳播。
n            可能有些背後的網路木馬動作，所以Outlook、MSN Messenger可能會不正常。(MSN出現超出每分鐘訊息數限制等怪訊息)
n            在一些機器上，只要重新登入，病毒就會喪失感染力。
n            重登後，某些機器則會在檔案總管按右鍵後再次具有感染力(我發現或許與WinZip32 Shell的右鍵選單DLL也被感染有關)。
n            有些機器則在感染及重開機後，一切動作變得很慢，導致電腦幾乎不能用，
n            最悲慘的狀況可能會導致OS無法開機登入。
(影響程度不同或許與受感染EXE、DLL的範圍有關係)

【偵測】
           監看了感染過程，我發現最簡單的檢測方法是開個DOS視窗，執行以下的指令:

           在正常的電腦上應該是找不到任何檔案的，若你發現一個43K的vCab.DLL檔，表示你現在登入的這個User中毒了，或曾中過毒。但沒發現並不代表整台電腦都OK，也許某些檔案已中毒了，或用這台電腦的其他User有中毒，都有可能。
           我寫了一個HTA程式可以代為執行以上的測試。但要再次強調，這個測試僅代表現在登入的User是否已被感染而已，不代表整台電腦都OK。

【解毒】
           目前尚無完善的解毒對策。我有用.NET 1.1 DIY了一個掃瞄EXE/DLL有無中毒徵兆的程式，但無法解毒，也還沒完整測試過，懷疑自己中毒的人再個別向我索取好了。

KB-不可信的LENB函數

2006-08-29T10:30:00.000+08:00

在一個Encoding為BIG5的網頁有以下的Code，你覺得結果會是多少?
<script language=vbscript>
S=”中文123”
MsgBox LenB(S)
</script>

依照LenB的定義，S字串的Big5位元組數應為7，多年來我也一直這樣以為。實際跑過，你會發現它的結果是10!! 也就是123也被視為Double Bytes。

在藍色小舖有篇文章證實了這一點，但文中提到的FN_Len函數已經失傳了，所以我試著自己動手寫了一個(希望夠嚴謹，發現有問題的人再回報給我)，大家可以參考看看:

'取代LENB傳回BIG5字串的正確位元組數
Function GetBytesCount(S)
    Dim I,C,A
    C=0
    For I=1 To Len(S)
       A=ASC(Mid(S,I,1))
       C=C+1
       '如果是ASC 0-255，表示為Single Byte
       '否則為Double Byte，算雙位元組
       If (A>255 OR A<0) THEN C=C+1
    Next
    GetBytesCount=C
End Function

如果要用ASP或VBScript組裝固定欄位長度的字串時，要特別留意這個陷阱!

原來Blogger也會掛點

2006-08-28T23:56:00.000+08:00

Blogger有Goggle撐腰，理論上應該具有跟Google相同等級的High Availability才對。
2006-08-28 12:40 PM左右，看到這個難得的畫面!

鐵馬小試--關渡

2006-08-28T23:48:00.000+08:00

上回與Lucas跑過一趟景美-大稻埕，發現了登山之外的另一種運動新選擇。
這個星期六，趁著小白馬的主人爬山去了，加上兒子不在家，"好爸爸Deadline"可以放寬，就挑戰了一下許多人都跑過的單車道終點--關渡。
小白馬果然是名門出身，騎起來比一兩千元的鐵馬省力許多。騎到手酸時，車身優異的穩定性，還可以讓你安心"放手騎"上好一陣子。想起小時候，放手騎可是苦練多年而不得的絕技，沒想到長大後，在車好、人少、路大條的天時地利之下，來就這麼不費吹灰之力就學成了。
大稻埕之前的景色，上回看過了，便不多停留。抵達時約花了一個半小時，時間與上次相近。此時已經九點半，算算最遲也得在兩小時內走完行程。看著大稻埕碼頭的地圖告示板盤算著，有三種選擇:
1) 立即原路折返，但這有點小無聊
2) 關渡有點遠(當時一直以為要繞完社子島才能接上關渡段)，不如社子島走完走一小段內湖段，時限一到立刻折回圓山坐捷運回去
3) 拼了，把社子島-關渡走完，再坐捷運回程
最後，基於時程的風險考量(靠! 又把運動搞成軟體專案管理了)，我決定採取方案2)...
從大稻埕重新出發，沒多久就到重陽大橋。奇妙的事發生了，前方出現了社子島向左、關渡向右的指標，意思是我可以跳過社子島的一大圈，直攻關渡，於是立刻改變戰略，決心今天把關渡走完!

沿著向關渡的自行車道路標前行，我看到了有名的推車上橋點--洲美大橋。
在上橋點有兩三個自行車騎士(穿自行車賽車服的那種)在聊天，另外有一個歐吉桑(也是賽車服)，為了確定起見，我向歐吉桑詢問往關渡怎麼走。沒想到他老兄開始熱心地指導我要設法從頭上的洲美穚向以北投焚化爐為地標前進，因此要先向回騎，設法上穚北行... 我不好意思直接點破可以推車上橋，只好假裝是不經意看到告示牌，引導他也發現這條捷徑，這才化解了一場尷尬。
照片中的樓梯兩側有推車用的斜坡，但說實在話，即便是小白馬這種鋁合金的輕車架，推起來還是要花點力氣的。快到橋面時，果然就看到有個婦人要推車下來，車子卻不聽使喚，人馬纏鬥的結果，造成後方要下橋的騎士大排長龍。
過了洲美穚，關渡就不遠了，這段車道兩邊都有柵欄，路面感覺就窄多了，但事實上供兩台車高速錯車也綽綽有餘，"窄"純粹是心理層面的感受問題。

距離開大稻埕不消一個小時，看到山邊有座大廟，不知不覺關渡就到了。在碼頭逗留了一下，另外再拍張水筆仔+關渡大橋的"存證照片"，景美-關渡行程就算完成了。

時間不早，決定帶著車子坐捷運回大坪林，節省時間，順便嚐試一下腳踏車坐捷運的不同體驗。由於假日開放自行車搭捷運不論距離都是連人帶車100元，基於坐越遠賺越多的摳王心態，就再騎了一站到竹圍上車(:P 其實是因為竹圍站就在自行道旁邊)。

自行車騎士要到窗口買專用票，同時售票小姐會跟你確認要下車的站名(因為不是每一站自行車都能出入)，然後再親自幫你開門，由團體票的閘門進入。自行車只能上最前及最後一節車廂，每個門邊只容許停兩台車。我進了第一節車廂，發現車上已經有兩名中年自行車手(又是一身賽車手勁裝，故應以自行車手尊稱之)，我一身的Polo衫加短褲，相形之下，顯得特別的瀟灑不羈~~
專用票在下車時會回收，忘了拍張照留念，看一下車廂照片裡夾在車架上的那張紙想像吧!

是洋蔥嗎? 不! 是Windows Live Writer!!

2006-08-19T00:09:00.000+08:00

咦? 這是什麼來著? 有一種感動的感覺。我怎麼會流淚了呢?
是洋蔥嗎? 不! 是Windows Live Writer!!

這幾天，發現在自已訂閱的Blog中，最火紅的話題莫過於Microsoft最近推出的Windows Live Writer了，我已經看到陸續5名以上的Blogger提到它了! Windows Live Writer 是微軟最近推出的Blog寫作工具，我自己也試用了一下，只花了不消五分鐘，就不禁想為它起立鼓掌。

說穿了，Blog Editor不過就是個HTML編輯器罷了，市面上至少可以找到一打以上。Blog Editor好用與否的關鍵就在於整合!!

我的Blog平台策略是走時尚名牌風，採用的是Blogger(Google撐腰)+Flickr(Yahoo相挺)。而Windows Live Writer本身支援了多種知名的Blog系統，可以透過Blog系統提供的API與其溝通，從Live Writer就可以直接看到未來的呈現效果，按下Publish文章可自動送到Blog伺服器端，FrontPage與IIS/WSS等級的整合流暢性，活生生地在3rd Party的Blog服務上展現，這功能體著實做進Blogger們的心崁裡去了。

如果只有如此還不算什麼，支援外掛Plug-In更是讓Live Writer如虎添翼，除了3rd Party提供的Plug-In之外，不滿意還可以自己動手寫(有SDK，這裡還有篇教學)。

目前社群已開發了幾個Plug-In，絕對不能錯過的就是Flickr4Writer ，它可以讓你瀏覽Flickr上的圖片後，直接插入不同尺寸的圖加連結到Blog文章中。我計算過，原先要從Flickr插入一張圖片，大約要七八個Click，Postback3-4次才能Copy到Image URL。透過Flickr4Writer，大約2-3個Click就可以完成。美中不足的是，當圖檔較小時，若選取插入Medium或Large圖片時，Flickr會直接連回原圖，但Plug-In卻還是會推算縮圖JPG的URL，導致連不到圖檔。不過，依我Trace Source Code的結果，這問題出在Flickr.API外部DLL，不算Plug-In的Bug，我想到可用HttpRequest去刺探的方式解決，待有時間來實作看看。

KB-誰在叫我? .NET程式呼叫歷程的追蹤

2006-08-18T11:26:00.000+08:00

在某些情況下，我們會想知道自己的程式碼被誰所呼叫，例如: 當某個共用函數發生錯誤時，若可知是哪一個類別呼叫這個函數時出錯，將十分有助於Debug。

各位應該都看過.NET Debug Build在出錯時，會顯示所謂的Call Stack(即Exception物件的StackTrace屬性)，例如:

X:\>labs.exe
Unhandled Exception: System.DivideByZeroException: Attempted to divide by zero.
at Labs.Program.Lab0818() in F:\Documents and Settings\jeffrey\My Documents\V
isual Studio 2005\Projects\Labs\Labs\Program.cs:line 295
at Labs.Program.Main(String[] args) in F:\Documents and Settings\jeffrey\My D
ocuments\Visual Studio 2005\Projects\Labs\Labs\Program.cs:line 304

那我們可以自己取得這些資訊嗎?
配合System.Diagnostics及System.Reflection的一些類別，這個理想是可能實現的!
我寫了一個簡單的範例:

class Caller
{
    public Caller() { }
    public void CallIt()
    { Tracer.ShowCallerInfo("Called by Caller object"); }
}
class Tracer
{
    public static void ShowCallerInfo(string remark)
    {
        Console.Write(new string('=', 80));
        Console.WriteLine("Caller Remark: {0}", remark);
        StackTrace st = new StackTrace(true);
        StackFrame sf = st.GetFrame(1);
        MethodBase mb = sf.GetMethod();
        Console.WriteLine("Caller Module: {0}",mb.Module.FullyQualifiedName);
        Console.WriteLine("Caller Class & Method: {0}.{1}()", mb.ReflectedType.FullName, mb.Name);
        Console.WriteLine("File Info: Line {0} in {1}", sf.GetFileLineNumber(), sf.GetFileName());
        Console.WriteLine();
    }
}

然後，直接在Console Application呼叫及建立Caller物件後呼叫

static void Lab0818()
{
    Console.WriteLine(calcDiv(1, 0));
    Tracer.ShowCallerInfo("Called by main.cs");
    Caller c = new Caller();
    c.CallIt();
}

可以得到以下的執行結果:

X:\>labs.exe
================================================================
Caller Remark: Called by main.cs
Caller Module: X:\Labs.exe
Caller Class & Method: Labs.Program.Lab0818()
File Info: Line 290 in F:\Documents and Settings\jeffrey\My Documents\Visual Studio 2005\Projects\Labs\Labs\Program.cs

================================================================
Caller Remark: Called by Caller object
Caller Module: X:\Labs.exe
Caller Class & Method: Labs.Caller.CallIt()
File Info: Line 15 in F:\Documents and Settings\jeffrey\My Documents\Visual Studio 2005\Projects\Labs\Labs\Tracer.cs

瞧! 我們自己也有能力取得呼叫者的相關資訊。不過，要注意以下幾點:

1.        不管是Debug Build或Release Build，我們都可以取得呼叫者的程序、類別、Method等資料，但必須有.pdb檔時，才能顯示出在哪個原始檔(.cs)的哪一列
2.        Debug Build沒有pdb時，無法顯示原始檔及所在程式列。
3.        Release Build經設定也可產生pdb。
4.        上述的程式碼中，使用了Reflection的技巧去取得呼叫者資訊，不利於效能，建議節制使用。

KB-Javascript字串的特殊字元處理

2006-08-18T00:00:00.000+08:00

猜猜看，以下的程式碼中，jsAlert函式有什麼"可議之處"?

private void Page_Load(object sender, System.EventArgs e)
{
     string msg="Hello, World!";
     jsAlert(msg);
}
private void jsAlert(string msg)
{
     Response.Write("<script>alert(\""+msg+"\");</script>");
     Response.Write("<button onclick=\"alert('"+msg+"');\">CLICK</button>");
}

問題出在，當msg參數含有一些特殊字元時，這個網頁有可能產生JavaScript Error。

例如: 若msg="L1\r\nL2\rL3\n<Words>\"It's good!\"</Words>"，其中的換行及雙引號會造成<script>列出錯，而單引號及換行則會讓<button>列掛點。

簡單來說，當傳入的參數要形成Javascript的字串內容時，我們要特別留意換行及單雙引號這些特殊字元。廢話不多說，我寫了個函數來處理，大家直接看Code就明白。我想得到，該攔的應該都攔了，沒想到的就有勞大家集思廣義，多多檢舉了。

private void betterJsAlert(string msg)
{
     Response.Write("<script>alert('"+JSStringEscape(msg,false)+"');</script>");
     Response.Write("<button onclick=\"alert('"+JSStringEscape(msg,true)+"');\">CLICK</button>");
}
/// <summary>
/// 字串要被宣告成JavaScript字串時的特殊處理。例如: Response.Write("<script>alert('"+msg+"');</script>");
/// 中的msg有特殊字元如換行時，會造成JavaScript Error。此函數可以進行特殊字元的置換處理。
/// </summary>
/// <param name="raw">原始字串</param>
/// <param name="htmlAttribute">是否要宣告在HTML Attribute中，對單雙引號加入特別處理。
/// 例如: "&lgt;a onclick="alert('"+msg+"');">時，注意Attribute請使用雙引號包含字串</param>

/// <returns>置換特殊字元之後的字串</returns>
/// <remarks></remarks>
private string JSStringEscape(string raw, bool inHtmlAttribute)
{
     raw=raw.Replace("\r\n","\\n").Replace("\r","").Replace("\n","\\n");
     if (inHtmlAttribute)
           raw=raw.Replace("\"", """).Replace("'", "\\'");
     else
          raw=raw.Replace("'","\\'").Replace("\"","\\\"");
     return raw;
}

KB-NetLogon 5774 Error Event

2006-08-15T08:41:00.000+08:00

手邊有幾台Server會出現NetLogon 5774的錯誤: (以下為愛台灣的中文版)

DNS 記錄 d26400ba-960a-479e-a96b-656e6a43d9c6._msdcs.labs.com.tw. 600 IN CNAME LABS-DBS.labs.com.tw. 登錄失敗，因發生下列錯誤: DNS 不存在應該存在的 RR 組。

英文原文如下:

Registration of the DNS record ' d26400ba-960a-479e-a96b-656e6a43d9c6._msdcs.labs.com.tw. 600 IN CNAME LABS-DBS.labs.com.tw ' failed with the following error: DNS RR set that ought to exist, does not exist.

事件發生的頻率大約間接2小時或3小時一次。下圖是一台最會出狀況的主機，不過，注意哦! 它的訊息跟上述有點不同:

不存在應該存在的RR組 vs 存在不該存在的RR組

Google了一下，MS有篇KB說是因為DNS中存在萬用字元”*”的MX記錄，但檢查的結果DNS中並沒有任何MX記錄，故排除此種原因。

另外，找到數篇討論提到，當使用整合AD的DNS時，DC的TCP/IP設定中，DNS應該只指向自己，若指向其他DNS Server，就有可能產生此種錯誤。如果需要指定其他DNS，應採行類似下圖的設定。

檢查了一下，產生錯誤的DC果然在TCP/IP中設定了其他的DNS Server，將該設定移除，改為在DNS主控台中設定。

修改至今已24小時，未再發現類似錯誤，此一問題應可判定解決。

38公里的鐵馬暖身操

2006-08-14T23:38:00.000+08:00

老弟Lucas這陣子迷上了騎腳踏車，前幾天敗了台高檔新車。於是週日約了我一同去享受台北巿民權益，驗收一下河濱自行車道整合的成果。為了配合"好爸爸行程"(定義可以參考這裡)的限制，特別提早在六點集結出發，並約定大約七點半左右折返。

由於政大段的車道尚未與全線銜接，所以比較便利的走法是由政大，走木柵路經考試院、世新大學，在景美舊橋處進入下到河濱自行車道(路線可參考這裡)。

06:47 永福橋

景美起始的這一段仍有一部分在施工，路況不是很好，但沒多久就扺達永福橋，今天天氣不錯，水面平靜，可以看見橋的清楚倒影。

三台鐵馬並列，價值六千大洋的白馬果然光彩奮目。

07:01 馬場町紀念公園

前陣子親綠學者發表倒扁聲明的地方，我到今天才知原來在這裡。

天氣晴朗，水面無波，用Canon 10D挑戰一下河畔倒影照。

07:34 大稻埕碼頭

第一次拜訪，才知這裡也可以坐船。一排飛鳥型路燈及時鐘很有設計感。

水門內就是有名的南北貨總匯--迪化街，古船造景很有。(沒來過這裡，卻一直覺得眼熟，原來是小熊子有來外拍過)

此時已超過預定時間，開始折返。隨著接近中午，太陽愈來愈毒辣，流汗之餘，體力也開始下滑。加速時，開始有腿軟的感覺，看來登山所锻練的肌肉與騎自行車用到的肌肉群還是有點差別的。最後死命苦撐，總算趕在9點前回到家中。

統計了一下相關數據如下:
歷時約三小時，總里程38公里，行前體重81kg，結束時為79kg，但因過度口渴一陣狂飲，不久體重又回測82kg。

黑暗登山團初登場

2006-08-14T20:10:00.000+08:00

我週末的登山活動一向獨來獨往，這個星期六，老同事Jim及Chris無懼於"好爸爸行程"透早就要集合的恐怖挑戰，約好要跟我同行。

早上六點半，三人在政大門口碰頭，坐Jim的車子前往草湳大榕樹。這天天氣還不錯，美中不足的是幾乎無風。

我想了想，猴山岳路線較短，由大榕樹過去再原路折返有點乏味，走90度拉繩垂降對不常爬山的人有點挑戰，而回程得踢馬路回大榕樹取車，有點無聊。所以還是決定帶大家走二格山的寬敞豪華路線，順便見識一下知名的綠豆湯，有機會還可以來上一碗(我至今還沒嚐過哩!)。

就這樣，黑暗登山團第一次出團囉!!

一路上，看著沿途的景色，Jim聊起多次造訪九寨溝的心得，而Chris在西藏高原、四川流浪多月的經歷更是讓人聽得津津有味，與老友一同爬山的樂趣果然跟獨行攻頂完全不同。

途中乍見地上有條斷掉的黃色長橡皮筋，仔細一看居然是條怪蟲，亂噁心一把的，透過Jim放上去的10元，應可以想見它的長度。

在半山腰，向翡翠水庫的山區看去，可以看到類似雲海的景觀。沒想到在木柵除了可以看海，還有雲海可賞，真是了不起。只是要看雲海有些先決條件，水氣要足、不能有風、時間要早，通常到七點半都散得差不多了。

兩位新團員體力挺不錯的，大約只花了一個半小時，我們就抵達了山頂觀景台，留下這張新團員合照留念。

在山頂待了約20分鐘，走階梯下山。到綠豆湯時已超過8:30，聞得到炭火的味道。本想盡一下地主之誼，順道也親嚐綠豆湯的滋味。沒想到，老闆娘搖搖手，說綠豆應該還沒熟，就這樣，與情深緣淺的綠豆湯又再次擦身而過了。

回到大榕樹，坐上Jim的柴油"休閒專車"(柴油車的油耗效率挺好的，7公升就可跑100公里；而這台小車在假日會車尾掛著腳踏車、車頂綁著衝浪板四處遊樂，夠Pro吧!)，不消15分鐘就下到政大，結束了愉快的首次出團。

KB-QueryAnalyzer Bug??

2006-08-10T21:49:00.000+08:00

用Query Analyzer查詢一個Table的Text欄位，發現筆數一多就會發生以下的錯誤
[Microsoft][ODBC SQL Server Driver]Unknown token received from SQL Server
或
[Microsoft][ODBC SQL Server Driver]Protocol error in TDS stream

這導致明明要查一百筆，有時傳回59筆，有時傳回92筆，有時則100筆都傳回。於是我在查詢欄位中加入了DataLength去檢查Text欄位的大小，發現發生錯誤時最後一筆的DataLength會暴增(如下圖，應為3178，卻得到813572)。

我用Terminal Service連上SQL 2000主機，用本機的Query Analyzer做同樣的查詢，就算查500筆也不會出錯。因此研判這個問題與網路傳輸有關!

與網路傳輸有關，那麼是Query Analyzer的Bug或是底層的Driver有問題? 試了一下SQL 2005 Database Management Studio，就算查500筆也不會出錯。所以網路傳輸的部分應是OK的。

用QueryAnalyzer查了另一個Table的Text欄位，發生一樣的狀況

【結論】
Query Analyzer在連線遠端SQL 2000資料庫，查詢大量含Text欄位的資料時，當結果資料長度超過一定大小時，就可能發生中途截斷的狀況，並得到
Unknown token received from SQL Server 或 Protocol error in TDS stream的錯誤訊息。

KB-SQL 2000的資料庫變數(Table Variable)

2006-08-08T19:29:00.000+08:00

汗顏! 今天才發現一個新玩意，自SQL 2000起，除了暫存資料表之外，還有一個選擇—資料表變數(Table Variable)

資料表變數與暫存資料表(Temporary Table, 例如: #myTable)的應用時機很像，但資料表變數具有以下優點:
1.        用於Stored Procedure時，不需要每次Recompile，速度較快
2.        比照Local Variable，Scope定義明確，在不需要時就立刻會被清除
3.        Transaction Lock存在時間短，也不影響實體資料庫，資料的更新操作更有效率

但有得必有失，資料庫變數有以下缺點:
1.        只支援PK及UNIQUE KEY，不能建立Non-Cluster Index，也沒有資料分佈統計機制，不利於大量資料或複雜的查詢，如果Table很大時，又有繁重的查詢時，這個問題會變得明顯。但是不要誤以為資料表變數永遠只用記憶體存資料，其在資料較大時也會引用磁碟空間存放資料。
2.        基於Local Variable的限制，使用sp_executesql時無法存取
3.        不支援SELECT INTO、INSERT EXEC

找到兩篇不錯的參考資料
http://www.developer.com/db/print.php/3414331
http://support.microsoft.com/?kbid=305977

KB-Restore SQL 2000 Backup on SQL 2005的帳號刪除問題

2006-08-07T17:53:00.000+08:00

有個資料庫要從SQL 2000搬到SQL 2005，採用先在SQL 2000 Backup成.BAK，再複製到SQL 2005上Restore的做法，過程順利，但要刪除無用帳號時卻發現以下錯誤訊息:

咳… 伺服器上裝的是本土化兼愛台灣的中文版SQL 2005，一邊碎碎唸一邊Google出訊息原文為:
The database principal owns a schema in the database, and cannot be dropped.

用這個訊息Google了一下，很快就找到善心人分享的Tips。原來SQL 2005強化了Schema的概念，在Restore SQL 2000 Backup檔的同時，自動為User建了同名Schema。

如果你確定原來所有的物件都是以dbo為Owner，則利用以下的UI將這些Schema砍了即可。

環遊世界進度表

2006-08-07T07:59:00.000+08:00

從Steve的Blog看到這個有趣小東西，就輸入了一下我目前旅遊過的地方，果然，見笑了，結果為7國，佔全世界3%，隨便找個大學女生經歷都比我豐富吧! 而活了大半輩子連亞洲都沒踏出去過(最遠的地方是蜜月時去了馬爾地夫)，應該也是項記錄。

現在有工作，要養小孩，要四處走動的難度不低，環遊世界的夢想，就留待中了樂透或退休後再打算了。
(忽然想要，退休後能否成行，還要看兩個小蘿蔔頭將來爭不爭氣哩! 女兒、兒子，要加油呀! 可別讓老爸晚景淒涼哦。)

偷得浮生半日閒

2006-08-06T00:07:00.000+08:00

積了好幾件銀行的事待辦，加上這陣子天氣奇佳，索性就請了一天特休假，辦事之餘的時間剛好拿來征服平日"好爸爸行程"無法涵蓋的山頭。(註: 好爸爸行程意指已婚男子以不荒廢工作、不影響正常家庭作息為前題所從事的個人休閒活動。例如: 凌晨三點出發拍外木山火燒雲、凌晨五點前往至德園拍荷花、早上九點前爬完二格山等等。感謝小熊子提供好爸爸的攝影行程)
由於這等好天氣最適合前往高山享受絕佳展望，決定挑戰台北市第一高峰--七星主峰。此番攻頂適逢情人節及結婚七週年，帶著老婆同行，充分彰顯好爸爸+好情人+好丈夫的形象，真是佩服自己的決策。
車停在小油坑遊客中心的停車場，看了一下導覽看板，由小油坑到七星主峰1.5公里，耗時約一小時。本以為正午12點會熱到不行，沒想到天公作美，湛藍的天空配上清爽的涼風，實在是絕佳的踏青天。
比起冷水坑的登頂路線，小油坑線短但陡，步道兩旁盡是與人等高的箭竹，不若爬二格山時一路有樹蔭相挺，幸好今天老全程有天然電風扇相伴，否則非中暑不可。
一路上看著藍得不像話的天空，我也試了試借來的CPL鏡。果然，CPL的效果要老天爺幫忙，今天的效果比起前幾天薄陰天時強了N倍，不過轉得太極端時，會有色偏的現象。
如導覽所預測的，花了約一小時，果然就到了主峰頂。以前兩次登頂的經驗，只記得去抱那根"台北市第一高峰"石柱跳鋼管，這次終於會留意到在旁邊的一等三角點，當然不能免俗要拍照留念，不過為了紀念這個特別的日子，與三角點相伴的不是手機跟鏡頭蓋，而是我的婚戒。

山頂的風超大，吹得人都快站不穩! 在七星山頂吹風散熱之際，忽然有個身材火辣的外國美眉背著大背包爬上來，然後很興奮地拿著DV在山頂拍360度全景，邊拍還唸唸有詞地加上口白。接著她又拿出數位相機狂拍，一度請我們幫她拍照鋼管照。我隨口問了句"Whare are you from?"(咳... 我少數能開口的幾句洋文)，她說她來自墨西哥，她媽媽在山下，懶得爬上來... 接著，可怕的事來了，墨西哥辣妹指著三角點座子上刻的中文說明問道，"What does it mean?" 媽呀! 叫我用英文解釋Web的傳送原理就算了，我連三角點的英文都不知，更何況解釋了。
"Ummmm... It's umm... kind of mark umm... for geographic!" (喵的，幸好還記得地理怎麼說，這下雖不中亦不遠矣了)
"Ummm... Its term is 'Triangle Point'!" (慘了，比美Long Time No See的洋涇濱英文出現了)
"Ummm... You can use it to mark the exact position on the surface of earth" (還用手比出球狀，有點蠢)
"Ummm... It was often set at the top of mountain, so you can stand here use a telescope(比出望遠鏡的手勢) to see another top of mountain, than you can know the distance, height..." (天哪! 我到底在說什麼呀?)
善解人意的墨西哥辣妹看出我已開始胡言亂語，決定不再為難我，用力地點點頭，做出晃然大悟的表情，為黑暗大師的臨時地理講座敲了下課鐘。
回到小油坑時，仰望天空仍舊蔚藍，只是多了些白雲，一時興起，拍了張仿XP預設桌布的藍天白雲綠地照，為美麗的一天留下註記。

PS: 到現在還好奇什麼是三角點的朋友請看這裡。

XML Attribute的特殊字元處理DIY

2006-08-04T15:39:00.000+08:00

我有段程式為了貪圖效能，沒用XmlDocument，而用StringBuilder自己組XML:
sb.AppendFormat("<Event Log=\"{0}\" Message=\"{1}\" />\n",
                    logName,System.Web.HttpUtility.HtmlEncode(e.Message));
結果，今天突然程式發生Error，才發現這段程式乍看OK，嚴謹性卻大有問題。原因出在e.Message中可能包含一些HtmlEncode認定合法，但XML不接受的特殊字元(例如: 換行、\t之類的)，組出來的XML是不合法的。

於是，我寫了以下的Code做測試(用了一個ASCII 01(笑臉)跟\n(換行)當成非法)
        static void Lab0802()
        {
            XmlDocument xd = new XmlDocument();
            xd.LoadXml("<ROOT></ROOT>");
            XmlElement xe = xd.CreateElement("X");
            XmlAttribute xa = xd.CreateAttribute("N");
            xa.Value = "<ab>\x1\n</ab>";
            xe.Attributes.Append(xa);
            xd.DocumentElement.AppendChild(xe);
            Console.WriteLine(xd.OuterXml);
            Console.WriteLine(System.Web.HttpUtility.HtmlAttributeEncode(xa.Value));
        }

使用XML DOM的結果，合法的XML應為<ROOT><X N="<ab>
</ab>" /></ROOT>，而使用HtmlEncode的結果，\n與\x1都沒被置換。當Attribute中出現這些非法字元，在XmlDocument.LoadXml時，就會發生Error!

找了半天，沒找到現成的函數可以處理這個問題(有個XmlConvert.EncodeName()可處理Attribute名稱的特殊字元(例如: 中文)，但其規則與Attribute Value的Encode不同，所以無法借用)，只好自己DIY寫了這個函數，有類似需求的人可以引用，發現邏輯有錯的話請通知我修改。
        //當字串中可能包含特別的ASCII碼時，做額外的轉換
        public static string XmlAttributeEncode(string raw)
        {
            string s = System.Web.HttpUtility.HtmlEncode(raw);
            StringBuilder sb = new StringBuilder();
            for (int i = 0; i < s.Length; i++)
            {
                char c = s[i];
                //要處理的範圍
                if ((c>=0 && c < 32) || (c > 127 && c<=255))
                    sb.AppendFormat("&#x{0:x};", (byte) c);
                else
                    sb.Append(c);
            }
            return sb.ToString();
        }

從木柵看海的日子

2006-07-31T00:00:00.000+08:00

經過昨天慘痛的教訓後，今天一早見天空仍然湛藍，決定快點把握老天給的第二次機會，整裝再向草湳大榕樹出發。當然，臨行前反覆檢查了三次，確定有帶CF卡才出門。
昨天已經爬過二格山，加上昨天老弟的線報說猴山岳的視野奇佳，於是今天決定由大榕樹走到猴山岳(路線可以參考這裡)，再原路折回，路程輕鬆一些(昨天回程時腳盤小小扭了一下，今天就別太操!)；畢竟這是一趟相機復仇之旅，浪費太多時間在走路上會模糊焦點。
花了約半個多小時就從草湳大榕樹走到了猴山岳前峰，說正格的，今天的天氣比昨天差一點，雲量較多，藍天的面積大減，但視野依舊不錯。從前峰一路向北看去，幾個台北巿的主要地標，101、新光大樓、圓山大飯店、陽明山，都清晰可辨，甚至可以隱約看到北方的海面，實在是難得一見的好天氣! 感覺上昨天的天氣又更好一些，但錯過了就是錯過了，徒呼負負亦於事無補。
猴山岳真是熱門的路線，在我停留的短短二十分鐘內，山頂就換了五批登山客；不過大部分的人多半從指南宮過來，挑戰完90度的向上爬升登頂後，看一下風景離去。(90度的上升坡有多好玩呢? 可以看這裡) 今天時間稍晚，又不想當完猴子後走一大段馬路回大榕樹騎車，所以沿原路回去，帶著笑意完成了今天的復仇之旅。

35℃, 678m, 55min, 1.3Kg-->搥心肝

2006-07-30T00:50:00.000+08:00

清晨起床，發現今天天氣真是出奇的好，天空藍得不可思議，加上風勢不小，足以把台北平日漫天的懸浮塵粒吹散，看來終於有機會拍出風景明信片品質的照片了。
機不可失，抄起了相機Canon 10D(790g)+Canon 28-135mm IS鏡頭(540g)，匆匆灌了盒牛奶(480ml)，就騎著機車(125cc)到達草湳大榕樹(06:55)，停好車立刻向二格山(參考: [1] [2] [3])出發。
這座山由於路況好、加上高度夠(台北市南區的第一高峰)、視野佳(登山術語叫展望良好)，這幾週我幾乎每週都來報到，路線已熟到不行。一路不斷超車(共計7名歐吉桑、9名歐巴桑跟四條黑狗，一條拉不拉多)，終於在55分鐘後抵達山頂(678公尺)的瞭望台。
果不其然，天空藍到不行，但風很透，並不太熱。向北方看去，台北101, 新光三越大樓, 七星山, 關渡... 一路可以看到東海；南面翡翠水庫也十分清晰，雖然仍有薄薄的白霧，但已是幾次經驗中，空前良好的視野了。
迫不及待拿出相機，前照後照了數張，忽然想看看效果，按下Review鈕，No CF Card!
No CF Card! No CF Card! No CF Card! No CF Card! No CF Card! No CF Card! No CF Card...
想起了前幾天為了替女兒照大頭照，拍完立即把卡片拿到PC上檢查效果，就忘了插回去。帶相機沒帶CF卡爬山，這是第三次了! orz
因此，今天的美景，我只能靠回憶，各位只能靠想像，這種境界比看照片高出許多，共勉之。

被Javascript電得哇哇叫--location.href Behavior

2006-07-28T19:05:00.000+08:00

寫了多年的網頁程式，自認精通Javascript，卻在今天又再一次體會活到老學到老的真諦。
同事請我幫忙抓一隻難纏的蟲，程式參考自MSDN一篇關於長時間網頁(Long Run)等待狀態顯示的Design Pattern，目的在避免使用者久候不耐的感受，實務上一些執行時間高達數十秒到數分鐘的網頁，總是讓人搞不清楚是當機還是在處理中。如果在等待的同時可以顯示一些”安撫使用者”的進度資料，可以減少網頁被使用者放棄的機率。
原文中有一段Javascript location.href轉向的特殊用法，讓我頓時丈二金鋼摸不著腦袋。我把相當的邏輯簡化成以下兩個網頁:
Start.htm [用來觸發Long Run網頁，並顯示等待秒數安撫使用者]
<html><body>
<button onclick="process();">Process</button>
Time: <span id=msg></span>
<script>
function process() {
        setInterval("showTimer();",1000);
        location.href="Process.aspx";
}
var i=0;
function showTimer() {
        i++;
        msg.innerText=i;
}
</script></body></html>
Process.aspx [模擬Long Run網頁，Delay 10秒後顯示Finished!]
<%@ Page Language="C#"%>
<html><body>
<% System.Threading.Thread.Sleep(10000); %>
Process Finished!
</body></html>
依我過去的認知，在location.href=”…”之後，目前的網頁應該就會Unload，瀏覽器會立即連上新網頁，若新網頁耗時很久，則使用者勢必會有一段時間看著白色的網頁發呆。但事實不然….
反覆做了幾個測試，即使Process.aspx先Response.Write一些文字，利用Response.Buffer=false或Response.Flush先送一部分內容到IE，Thread.Sleep後再送出第二段文字後結束，結果還是一致的--當使用location.href或location.replace導向其他網頁後，IE會停留在原網頁上，一直到新網頁內容傳輸全部完成為止。
因此，上述的Start.htm程式中的setInterval會啟動讀秒，等待Process.aspx完全執行結束後，IE才會用Process.aspx的網頁內容取代Start.htm。實際Demo可以看這裡。
今天的觀察所得，一下子推翻了多年來深信不移的概念，幸好早年幾位嗜賭成性的老友Max, Ryan, 小毛不在，不然可能已經輸掉一客牛排。沒想到自稱老鳥還是被電得哇哇叫，只能說技術領域實在太浩瀚了，永遠不要自滿，心態才會健康!
另外，今天還學到一個新method—location.replace()，跟location.href一樣，可以用來Redirect，但最大的不同是replace後新URL可以取代Browser的歷史記錄，也就是被取代掉的URL將從回上一頁的清單中消失，如果你不想要某個網頁被Reload，這也是個可以考量的方法。

機器更名大作戰

2006-07-21T23:57:00.000+08:00

公司啟動了新的資安規定，取消了DHCP，要求所有Client PC一律使用固定IP，且依公司所配發的名稱為電腦命名。
辦公室桌上的XPC SB81P是2003年底買的，跟著我流浪過三家公司，OS也一直沿用至今，沒再重灌過。這下被要求改名，沒法預先攤出需要更動的設定有哪些，只有先更名，再用打地鼠的方式，等問題自己冒出來，遇到一個解一個。
IP跟機器名稱改好重開機後，第一步就是試試機器上的各個功能是否正常。為了減少衝擊，我特別在lmhosts及host兩個檔案裡，將新的IP Mapping回我的舊電腦名稱，這樣本機的程式即使Sql Connection String或UNC指的還是舊Machine Name，可以完全不用更動，繼續運作。
不過，當我用IE開啟本機的WSS個人Portal時，第一關來了，IIS Web起不來，所有的Web處於停止狀態，要去啟動時，出現了” The format of the specified network name is invalid
“的錯誤訊息，然後系統事件簿中出現了
HTTP Error Event 15005
Unable to bind to the underlying transport for 10.0.15.91:80. The IP Listen-Only list may contain a reference to an interface which may not exist on this machine.　 The data field contains the error number.
W3SVC Error Event 1004
Cannot register the URL prefix 'http://*:80/' for site '1'. The site has been deactivated.　 The data field contains the error number.
幸好，這兩個訊息非常明確，Google了一下就找到答案。這才想去前陣子為了Try SubVersion，裝了Apache HTTPD，所以指定了HKEY_LOCAL_MACHINE\Service\CurrentControlSet\Services\HTTP\Parameters\ListenOnlyList，讓出一個IP的80 Port給Apache用。ListenOnlyList的IP還是舊的，造成了Web無法啟動。修改Registry，再net stop http /y, net start w3svc一下，Web就可以啟動了。(注意要重啟HTTP，光IISRESET是沒有用的!)
Web Server OK了，此時第二關出現了。連上本機WSS時，出現大大的Server Application Unavailable訊息。幸好，Event Log中可以找到明確的錯誤:
W3SVC Warning Event 1057
The identity of application pool 'WSSPool' is invalid, so the World Wide Web Publishing Service can not create a worker process to serve the application pool.　 Therefore, the application pool has been disabled.
W3SVC Error Event 1059
A failure was encountered while launching the process serving application pool 'WSSPool'. The application pool has been disabled.
原來是IIS Application Pools中開了一個WSS專用的App Pool，其中指定了MachineName\WSSAccount作為執行身份，現在電腦名稱改了，它沒跟著自動更新，就只有出錯的份了。改了Identity，WSS就OK了，SQL Connection的部分完全不需要改，看來是lmhosts發生功效!
晚上回到家，用VPN連回公司，第三關來了! 要用Terminal Service連上XPC時，卻發現無法連通，用ping、net use驗證了一下，機器活著，RPC是通的，看來是Windows 2003的內建防火牆作祟。之前設定過只有特定IP網段才能連上Terminal Service，這下IP改了，鎖定的網段卻沒調整，當然不通。不過，只有RPC可通，要如何解決這個問題呢?
雖然是睡一覺明天上班就可以解決的小事，但利用有限功能取得主機操作權的挑戰，實在太有駭客攻門的味道了，讓我的駭客基因蠢蠢欲動，頓時精神百倍!! 不過由於RPC可通，我又有Administrators權限，事實上並非難事。Google了一下，前後試了幾個方法:
1.       netsh可以修改firewall設定，但我測試的結果似乎只能修改本機firewall，連結遠端主機時，無法使用firewall這個Command。
2.       如果遠端不可用netsh firewall，那麼telnet進去再執行總行了吧? 開啟”電腦管理”的MMC，再連至XPC(因為RPC可通)，啟動了Telnet Server，卻發現Port 23被防火牆擋下來，第二波攻勢無功而返。
3.       再Google了一下，發現了一個好工具-sc.exe，可以控制遠端機器上的Service，利用sc \\MachineName stop SharedAccess，就可停用防火牆。Bingo! Terminal Service可用了。參考資料
這三隻地鼠應該只是先鋒部隊，後面幾週應該還有得打，就等遇到再說吧!

[Updated 2006-07-27 17:35]
又發現地鼠一隻... Scheduled Task中設定的Identity用的是本機帳號，前方會跟著機器名稱，機器更名後記得也要改，另外以此類推: COM+ Application、Window Service裡也可能有漏網之魚。

文字檔Encoding的識別

2006-07-18T22:45:00.000+08:00

從以前DOS時代BIG5的一統江湖，演進到Windows的Unicode時代，看似有唯一的標準，但只要轉換到檔案、網路傳輸時，還是得面對Encoding方法的選擇，應該不少人都有吃過Encoding的苦頭吧?
UltraEdit支援Encoding的轉換，可以在Unicode、ASCII(Big5)、UTF-8間轉來轉去，只是我常常檔案一開啟時，完全搞不清楚現在是什麼Encoding。今天同事小熊子分享了一個Tips，我這才發現原來UltraEdit的Status Bar就有得看!
DOS->ASCII(Big5)、U-DOS->Unicode、U8-DOS->UTF-8

另外，還認識了另一個跟UltraEdit有拼的Text Editor--EmEditor，日本人寫的，大概更是了解非英語系國家使用者的痛苦，Encoding的顯示更是明確到不行。
EmEditor Free版具有大部分UltraEditor的功能，不想花錢註冊又不想黑心”長期試用”的朋友可以試試!

Live Messenger不明連線謎底揭曉!

2006-07-16T07:16:00.000+08:00

前幾天發現Windows Live Messenger開啟了不明的HTTP連線連到幾台Seednet撥接IP的不明伺服器上，追查了一番，才它們是Live Messenger部分動畫快遞(Winks)的檔案來源。
文章貼出後，一位熱心的朋友提供了回應，我才知道原來是自己孤陋寡聞了，Akamai可是有名的網路內容遞送服務，Google了一下，發現Akamai有官方網站，台灣甚至有代理商，而微軟與Akamai也建立了策略聯盟，無怪乎會在Live Messenger身上發現它的影蹤。既然Akamai是MS目前採行分散網路內容傳輸的策略，將來應該也會在其他的產品上發現這種模式。只是Akamai你也幫幫忙，既是國際知名的服務供應者，就算用ADSL來節省在全球部署12,000台伺服器的成本，好歹也設定一下固定IP，申請個DNS Name。不然網管人員一天到晚看到自己公司內的PC在Inernet上的尋常百姓家四處遊走，恐怕也要捏把冷汗吧?

USB 2.0 vs SATA速度測試

2006-07-16T06:56:00.000+08:00

同事小熊子有個3.5" IDE HD外接盒，同時提供了USB 2.0及SATA介面，前幾天他分別採用兩種連接方式連上PC，測了一下速度，並跟我分享了測試結果。結果當然是SATA以44.2 MB/s狂勝USB的17.2 MB/s。速度不敵在預期之內，但由這種測試結果，我才發現到另一個事實: USB 2.0吃CPU也吃得挺凶的，CPU耗用率超過25%! 只是USB插頭幾乎每台PC都用，SATA介面的普及率還不算高，而且不像USB一樣會在機殼前後提供插頭，必須要設法自己牽線，方便性差多了。但是由這個數據來看，如果是長期、重度使用時，還是值得花點功夫去爭取較有效率的連線方式。

頭腦體操--解答版

2006-07-13T22:30:00.000+08:00

有意思的邏輯推理小品，大家來挑戰一下，看多久可以解出來。
這題的難易看來挺適中的，據說有公司拿來當成程式設計師應徵的考題，哈!

P先生、Q先生都具有足夠的推理能力。
這天，他們正在接受推理面試。
他們被告知桌子抽屜裡有以下16張撲克牌：
紅心 A、Q、4
黑桃 J、8、4、2、7、3
梅花 K、Q、5、4、6
方塊 A、5
葉教授從這16張牌中挑出一張牌，
並把這張牌的點數告訴P先生，
把這張牌的花色告訴Q先生。

葉教授問P先生和Q先生：你們能從已知的點數或花色中推知這張牌是什麼牌嗎？

P先生："我不知道是哪一張牌。"
Q先生："我想你一定不知道是哪張牌。"
P先生："現在我知道是哪張牌了。"
Q先生："我想我也知道了。"

請問：這張牌是什麼牌？

黑暗大師解題顯示答案

這是一個設計精巧的推理小品，解題的過程中會發現一字一句都是線索，樂趣十足。
首先，16張牌可不是隨機洗出來的，裡面安排了一些伏筆，在後續推理時，能有效地篩掉部分選項，快速縮小可能選項的範圍。
開始推理前，要先記住三個重點:
1) P先生與Q先生都已知道有哪16張牌
2) 兩人都擅於推理
3) P先生只知點數，Q先生只知花色
以這三點做前題，配合後面的四句對話，答案就會浮現出來了!

1) P先生說他不知道是哪張牌
P先生只知點數，卻無法得知是哪張。表示這個點數不是孤鳥，同一點數應該有兩種以上的花色。所以可以排除黑桃J、8、2、7、3，梅花 K、6。

2) Q先生說他確定P先生一定不知道是哪張牌
Q先生只知道花色，唯有該花色的所有點數都不是孤鳥，Q先生才有自信判斷P先生還沒不知答案。而黑桃跟梅花中都存在數字孤鳥，若P先生知道的數字是孤鳥，則不用知道花色也知道是哪張牌。因此Q先生得知的花色不是紅心就是方塊，由於其中沒有任何數字孤鳥，Q先生才會這麼篤定P先生一定不知道答案。

3) P先生在聽到Q先生咬定他不知道是何張牌後，就知道了答案!
P先生可以像我們一樣引用2)的推理，就能得知花色不是紅心就是方塊，而接著他就知道答案。
所以黑桃與梅花都可以丟了，我們看看餘下的嫌犯:
紅心 A、Q、4
方塊 A、5
會是哪一張呢? 一定不是A，因為如果是A，就算知道花色，此時P先生也不能確定是紅心A或是方塊A，所以答案會是方塊5、紅心Q或4。

4) Q先生在知道P先生得知答案後，馬上也知道答案!
紅心 Q、4
方塊 5
經過三個問題，只剩三張牌。Q只知道花色，如果花色是紅心，則P知道的數字可能是Q也可能是4，Q先生此時不會知道答案。如果花色是方塊，就只剩方塊5一個嫌犯，這才能Q先生在此時確定答案。

KB-Windows Live Messenger可疑連線解密

2006-07-12T22:56:00.000+08:00

無意發現Windows Live Messenger開了多條HTTP連線到一台Seednet撥接IP的主機…

理論上Live Messenger連線的對象應是世界性的Server才對，怎麼會是台來自Seednet撥接網路的機器呢?
試著telnet連上這台機器的80 Port、21 Port及25 Port，都是螢幕全黑後輸入任何字元後被斷線，看來需要特殊規格的Client端才能連。
由以上這些線索，讓我不禁懷疑，該不會是中了木馬吧? 莫非這台是後門程式通訊用的閘道… 想到這裡，神經都繃了起來!
用Ethereal眼睜睜看著它建連線卻抓不到封包，又更讓人冒冷汗。難道這木馬還有特殊的匿蹤功能，Hook了API後為自己作隱身…
又找了個免費軟體VisualSniffer，並重新啟動Live Messenger(或許Ethereal就是卡在Live Messenger沒重啟才沒抓到)，總算看到傳輸的Request了，是一堆menu_*.xml。不過該台主機一直傳回HTTP 304 Not Modified，所以也看不出XML內容是什麼。將IE Cache清空後，再試一次，menu*.xml的內容終於現形了。

由XML中的圖檔追下來，才發現這是所謂”動畫快遞”(Winks)下載目錄的選項資料。

最後證實，原來是虛驚一場。只是為什麼跟Messenger相關的服務卻用的是Seednet撥接上網的Server，真不知其中有什麼祕辛…

世足賽的驚嘆號

2006-07-11T22:58:00.000+08:00

世足賽落幕了，對我來說是個驚嘆號，而不是句點! 席丹的告別作竟然以一張紅牌收場，還賠上他一向沈穩冷靜的形象，叫人惋惜... (新聞在這裡)

馬特拉奇究竟跟席丹咬耳朵說了什麼，讓好脾氣的席丹老大抓狂失控，各方做了多種揣測，我蒐集幾種有趣的版本:
1) 少林足球版(newsgroup: tw.bbs.rec.sports.soccer)
馬特拉奇: 金剛腿是吧? 金剛腿是吧?
席丹: 更! 我是鐵頭功啦!

2) 落健版(大悶鍋: 李熬)
馬特拉奇: 非洲人傳說，只要用頭鎚倒身旁的足球隊員，失去的頭髮就能再長回來...
席丹: 像這樣嗎? 咚~~
裁判: 不要再相信沒有根據的說法了。給你紅牌出場，快去買瓶落健吧!

3) 海霸王版(大悶鍋: 邱異)
馬特拉奇: 海霸王現在10人一桌現在只要2500...
席丹: OK，那我先出場去佔位，你們等下快點來。咚~~

KB-詭異的NOT IN

2006-07-11T12:04:00.000+08:00

今天被一個詭異的SQL查詢結果搞到昏頭，查兩個TABLE
SELECT * FROM A WHERE ID=’123’ à 有資料
SELECT * FROM B WHERE ID=’123’ à 沒資料
由以上結果，推測
SELECT * FROM A WHERE ID NOT IN (SELECT ID FROM B)
該至少有一筆資料才對吧?

答案是不一定!!
若Table B中有部分資料的ID欄位為NULL，則第三個NOT IN查詢的結果將會是空值。

NULL被用來比較時，其結果是很特別的。例如: 以下有五個測試
SELECT 'YES' WHERE 1=null
SELECT 'YES' WHERE 1<>null
SELECT 'YES' WHERE null=null
SELECT 'YES' WHERE null<>null
SELECT 'YES' WHERE null is null
以上五個查詢條件，只有最後一項會為true，這解釋了NOT IN失效的原因。

變調的電腦展

2006-07-10T00:21:00.000+08:00

今天在新聞上看到台北多媒體電腦展的報導，沒介紹今年主打的PC機種、也沒提現場有什麼優惠，兩分多鐘的新聞影片中只看到主辦單位由日本重金禮聘來號稱有J-Cup的"寫真"女優，跟台灣有名的Show-Girl大車拼。依據新聞旁白，有位號稱這方面專家的歐吉桑拿著捲尺東量西量，然後結論是日本女優勝出(廢話! 花大錢找了日本人來還輸，豈不是"潘仔"?)。接著更令人瞠目結舌的表演來了，女優在台上舖了張瑜珈軟墊，開始做起體操，展現"偉大的"胸襟。這段新聞最後以令人傻眼的一段訪問做為結尾: 女優在台上忽然就難過得哭起來，透過翻譯的說明，原來她發現本地的報紙將她誤為"AV"女優，但她是"寫真"女優，讓她倍受委屈，現場看到這麼多媒體(呃... 其實其中夾雜一部分是拿著DSLR的攝影狂，一部分是醉翁之意不在酒的色情狂)，一時悲從中來... 幾年前辣風乍起時，電腦展找來36 G-Cup的女優來台助威，我還認真地替主辦單位思量，研判是Seagate或WD贊助，用以促銷"36G HD"。這次找來J-Cup，又不是IBM Developer大會要替"J"ava打知名度，對不起，我沒法幫忙拗了。
沒想到，一場熱鬧的電腦展，被電視新聞去蕪存菁後，剩下值得報導的訊息只剩J-Cup、AV vs 寫真。近年來台灣的展覽似乎開始變了味道，管他汽車、電腦還是家俱，一律得靠Show Girl軍團、管他寫真還是AV女優來壯聲勢、博版面，至於展覽的重點、內容是什麼，似乎都只是次要的。幾番下來，大家越吃越辣，不辣的反而就變成不上道；就好像開車一路過去，檳榔西施一攤比一攤敢露，中間要是夾雜一攤只有歐巴桑在包檳榔的，少不了會招來一聲"更"吧!
相關新聞: 這裡

陰險的Bug，沈重的一擊

2006-07-05T23:57:00.000+08:00

這張圖中隱藏著一隻邪惡的Bug，讓三日不Coding手就會癢的我，罕見地度過十餘小時萬念俱灰，了無生趣的職業生涯低潮，連多年來累積的自信都差點毁於一旦... 只有orz能代表我此刻的心情~~~
這陣子在寫一隻Window Form程式串接一個已存在的後台系統，目的要取代現行功能、效率不甚理想的終端程式。由於已有別人寫好的程式做為模仿對象，手上有詳細的協定文件(但沒有Sample Code)，而通訊用Library可提供詳細的Log。本以為應該沒啥大問題，卻發現新寫的程式始終得不到Server端的正常回應。
於是分別把老程式與新Code的Log拿來比了又比，甚至還用Ethereal抓了封包，Follow TCP Stream將完整的傳輸內容Dump下來，用UltraEdit開成上下視窗一行一行比對，明明我的傳送內容與老程式完全相同，為何會被Server識破，就是不給我正確的回應??
排除了傳送內容有異的假設，我開始朝一些細微且可能性不高的機車細節推敲，例如: 送出各訊息間的Delay間隔、傳接用的Thread別...等等，由這些看似吹毛求疵的舉動，自己都可以感覺到，此時已經站在喪心病狂的臨界點了，距離拿鍵盤敲頭自殘大概也不遠了。
忽然一個念頭閃過，決定冷靜下來，回頭再仔細思考一次，最大的問題應該還是在於送出的訊息內容有誤! 於是我重新抓了正常與異常的Log，用UltraEdit一個字元一個字元比對，看起來仍然是完全相同的。害怕會是不可見的字元(例如: Tab, \n)之類惹的禍，於是叫出了UltraEdit的二進位比對功能。這才看到，原來要送出01，我卻誤打為O1(字母O跟數字1，這是個離譜的打字錯誤，打字時被鬼附身是我想到比較合理的解釋)，而在UltraEdit、VS.NET中，0與O看起來幾乎是完全相同的，也是我比對了數十次卻一直未能發現的理由。
送錯了訊息內容，但Server未回應內容有錯，卻選擇了沈默不回應；UltraEdit與Visual Studio編輯環境的字型設定讓0與O二者難以用肉眼識別；過快跳離了最有可能的原因(錯送內容導致結果不同)，太早鑽研罕見的狀況... 一連串的巧合，讓這個小小的Bug快速長成巨獸，給了Coding老鳥難以承受的沈重一擊。
不過，這樣的經驗，也讓我回頭檢討自己習以為常的Coding、Debugging Style是否流於過度自信，造成在某些狀況下陰溝裡翻船。謝謝這個Bug給自以為是的老骨頭一個謙卑自省的機會，重新學會用敬畏的心去面對技術議題。
PS: 忽然回想起當年擁有的第一部電腦，Intel 8088 4.77MHz的Acer PC，初學電腦的我，看著滿是綠色字母的單色CRT，老對零中間多的那一撇很感冒，抱怨為何硬要跟平常看的印刷字母不一樣。今天的我，特別想念那些有一撇的零...

蕃薯藤新聞，救甘心ㄋㄟ~~

2006-07-05T00:23:00.000+08:00

中午吃便當時看到這則新聞，忍不住就笑了出來... 只能說蕃薯藤的編輯大人實在是太體貼了，怕大家看到不調薪的新聞太過沮喪，特地跟大家開示一下正確的人生觀。

Word HTML精簡化工具

2006-06-30T00:16:00.000+08:00

多年來，我的KB、備忘錄等等多半是用Outlook編輯及歸檔，一來是背後串接了Mail/公用資料夾可以快速地與人溝通及分享，二來Outlook結合了Word作為文字編輯器，文字格式彈性、排版功能不在話下，又不用花時間學習。前陣子小熊子介紹我裝了Google Desktop，更是讓原本龜爬的查詢功能一飛沖天! 以前為了怕PST太大易出問題，我都會每半年分出一個PST檔。偏偏Outlook每次查詢時只能限一個PST檔，如果年代不確定時，就得半年半年的找(不過應該還是比總統府找發票快一點點，呵!)，甚為煩人。現在只要在Outlook的Google Desktop快速列輸入關鍵字，不消2秒，搜索的範圍就跨越了我從菜鳥工程師到技術老油條的近十年歲月! 這下子，更可確定Outlook將會是我唯一的知識文件管理平台!!
不過有些時候，Mail的內容要轉成網頁貼在討論區或Blog，Word的RichText雖然可以直接轉成HTML，但是如果你懂HTML，檢視一下他的HTML原始碼，包你吐血!!
例如: 簡簡單單一句”用VS.NET Debug時”，Word竟囉嗦到中英文各用SPAN包夾，並且每個SPAN都要加上幾乎100%相同的STYLE設定，再額外插入一堆mso-開頭Word專用的STYLE參數，於是就變成了這副德性:
<span style='font-size:9.0pt;mso-bidi-font-size:10.0pt;font-family:新細明體;mso-ascii-font-family:Arial;mso-hansi-font-family:Arial;mso-bidi-font-family:Arial'>用</span></font><font size=1 face=Arial><span lang=EN-US style='font-size:9.0pt;mso-bidi-font-size:10.0pt;font-family:Arial'>VS.NET Debug</span></font><font size=1 face=新細明體><span style='font-size:9.0pt;mso-bidi-font-size:10.0pt;font-family:新細明體;mso-ascii-font-family:Arial;mso-hansi-font-family:Arial;mso-bidi-font-family:Arial'>時
本來十幾個Bytes可以搞定的事，它硬是用快500 Bytes，長舌得很… 對頻寬很在意的我，不太能忍受這個結果，但要我將Outlook已經打好的東西還要再用FrontPage或UltraEdit重新編一次，太不甘心。於是我寫了個一個Word HTML淨化器，可以將Word囉嗦的作文去蕪存菁，在不破壞原有格式的前題下，減少HTML的資料量。
如下圖，原本20K的大小立刻縮小到1/5不到，只剩3.7K，而且格式仍保持不變!

程式可以按這裡下載。有興趣的人拿去用，記得要先裝.NET 2.0。試用的人順便幫我Debug，有問題再回報給我囉!

VS 2005又偷藏選單了

2006-06-29T23:28:00.000+08:00

用VS.NET Debug時，當例外(Exception)發生，如果拋出例外的Code已被try … catch的例外處理包覆，預設是不會觸發Debugger中斷的。而一旦進入catch的範圍，錯誤發生在哪一行就變得不可考了。我們就可以由選單Debug/Exceptions設定”When the exception is thrown”選項，由Continue改為Break into the debugger，這樣有任何錯誤發生，不管有沒有try..catch，都會觸發Debugger，停在出問題的那行程式碼上!
不過，繼上次歷經了Navigate Forward/Backward失蹤記，發現VS 2005預設又把Exceptions選單給藏起來了。如果要用，可以按快速鍵Ctrl-Alt-E或用下圖的方法把它找回來。

Java牆角挖挖挖

2006-06-27T00:12:00.000+08:00

J2EE與.NET的戰爭，最後鹿死誰手? 沒人知道。不過這幾年來，幾位Java界大將級的人才紛紛倒戈，倒讓我暗自竊喜。

以Java香雞排起家的蔡學鏞先生(http://www.microsoft.com/taiwan/msdn/columns/DoNet/default.htm)在微軟MSDN寫文章好一陣子了，當年此舉讓不少Java基本教義派義憤填膺，激動異常，在CNet的留言版上燒起了熊熊Java霹靂火(http://taiwan.cnet.com/enterprise/column/0,2000062898,20085671,00.htm?PROCESS=show&ID=20059803 )[不禁讓人想起這陣子台灣政治的藍綠生態，原本只是理念各異，最後老搞到像有不共戴天之仇一般，無言…]

當自由人一陣子的前昇陽總監—洪志鵬先生，也在今年決定被加入”當初打得火花四射的競爭對手”(http://www.michaelsoft-taiwan.com/diary.php?day=2006-01-26 ) (在我的看法中，洪Sir之於Java陣營應該像阿輝伯之於台聯吧!)

今天收到一封Seminar 的e-mail DM，意外發現Java界的名講師王森先生也悄悄地換陣營了。(http://www.microsoft.co.ke/taiwan/press/pmm/default.aspx)

說穿了，MS挾著驚人的財力與資源，在這場戰爭中，確實讓瘦小的Sun吃足了苦頭；但對人才而言，見到優沃的待遇、充足的資源、樂觀的願景，死也不動心的人，稱得上是意志力過人的革命志士；只是對講究因地制宜、依環境採用最佳解決方案的Architect而言，把科學邏輯搞成了宗教狂熱，恐怕不是好事吧?

看著我寄生的這半邊西瓜是愈來愈大塊了，好事一椿! 哈!

Blogger小改版? 原來是被當作垃圾Blog了!!

2006-06-23T17:35:00.000+08:00

昨天在Blogger文章時，發現了一件事。現在起，貼文章時也要輸入圖畫文詞驗證了! [以前只有在貼意見(Comment)時要] 不知是否又發生了機器人大舉入侵的情事，所以讓Blogger做了此項修正。但我覺得比較不能理解的是，一般來說，貼Comment可以防止有人有機器貼稿文字在別人的Blog上貼意見打廣告，但是狂貼自己的Blog應該沒啥傷害才對

不過，我好奇地點了一下字詞驗證旁的小”?”，才發現原來我的Blog被判讀為垃圾Blog，所以被加上了字詞驗證這一關:

* 對於可疑的垃圾 blog，相同的分類器可用來要求在張貼表單上額外的字詞驗證欄位。這會讓垃圾 blog 發送者無法輕鬆地設定自動化系統並進行發佈動作，因為只有人員操作才能完成這個步驟。

* Navbar 中的標幟令人反感的內容按鈕讓您可以告訴我們您遇到有問題的 blog，因此我們可以進行審查，並採取適當的動作。

Blogger提供了一個申訴的管道，讓你提出要求去除垃圾Blog的要求，Blogger會在由人工檢核過後，以Mail回覆結果。我檢討了一下，自己的Blog中多是些閒扯胡謅，再雜上些技術知識分享，依Blogger文章判定垃圾Blog的標準，最有可能的就是談布希在Goggle上被人惡搞那件事了! 如果是，要不就是Blogger的垃圾Blog阻擋漫游器的判別Rule不夠好(把我當成Goggle Bomb的一員?)，再不然就是Blogger與Goggle一樣，對於具”政治敏感性”的議題，反應過激了點。總之，等Blogger的回應再說了。

[Updated at 2006/06/27 08:00:00] Blogger Support在24小時內回應了，效率很不錯! 信中向我致歉並解除了我貼文需要文字驗證的程序。由內文來看，應是制式的回答，至於當初被鎖的原因為何? 我想將會是個謎了...

初遇吸血鬼

2006-06-23T00:01:00.000+08:00

幾週前，在一個雨後的週末清早，走完樟湖步道後意猶未盡，於是又去爬了一次鵝角格山。途中有一段溼軟的陰暗小徑，但已爬山成習的我，穿著短褲T-Shirt，輕快而行。下山後，當日適逢政大校慶，還小小看了一下啦啦隊比賽的排練才回家。
結果回到家沖澡時，低頭才發現右腳小腿上有個黑黑的小東西，不像是枯葉或泥土，雖然過去沒有類似的經驗，但我馬上警覺到莫非中了水蛭(螞蝗)!! 小小的東西巴在腿上，不痛不癢，但想到就噁心，也不太敢用手去抓下來。最後是用洗澡巾猛撥了好幾下，才把吸得死緊的小吸血鬼給弄下來，不過一甩就不知跑到哪裡去了，找了一陣子也沒找著。宣告放棄後繼續洗澡，但想一想，有個不知去向的小惡魔心裡還是毛毛的，仔細再找一次好了。
最後在淋浴拉門的門框上找到牠吸盤貼緊框面，尾巴卻不斷向上蠕動探索，甚是惡心。也不敢用手去碰，就把熱水開到最燙，猛沖了有兩分鐘，終於完成了涮水蛭小菜。
洗好澡把牠移到陽台拍了個照留念，這才仔細看清楚了長像，嘴巴是個圓形的吸盤，中有小孔，身上則有類似蝸牛的班紋，整隻吸血吸得肥嘟嘟的! 此時低頭一看，媽呀! 腿上被牠咬出來不到綠豆大的傷口，正源源不斷的流出血來，一連換了好幾張衛生紙也沒有要停的意思。由於急著坐捷運去接小朋友，所以想說塗上藥膏止個血就出門了。沒想到走到公車站，發現行走間，血又流了一片，拿出衛生紙來擦時，被站在旁的一個國小生看到，眼睛張得老大!! 最後上了捷運，找到座位，索性用衛生紙壓著，按了五分鐘，總算傷口凝結，前後折騰了快半小時。

大自然真是奇妙，不起眼的動物有能力製造出如此神效的抗凝血劑，又巧妙的結合環境、身體構造，走出了獨有的生存之道! 只是我已領教過這個"大自然的奇蹟"，希望以後別再碰到了。

免洗筷的可怕--找碴篇

2006-06-19T22:55:00.000+08:00

收到一封同事轉寄的Mail:(我查證了一下，來自國語日報)
免洗筷的可怕　小朋友科展證明
【記者張彩鳳報導】
儘管環保團體提倡自備餐具多年，但是市面上的小吃店、攤販還是充斥著免洗筷。
臺中市葳格小學蔡承訓等五名小朋友，閱讀報紙新聞後，主動研究及測試，證實了「免洗筷的可怕」。小朋友呼籲大眾，為了健康著想，還是少用免洗筷子。五名小朋友的研究，獲得今年臺中市中小學科展化學類第一名。
參與研究的小朋友看了新聞報導，啟發他們的研究靈感，很想找出答案。
蔡承訓說：「真是可怕！免洗筷浸泡漂白水、二氧化硫，使得筷子含有高度的酸性物質，不但種植綠豆無法成長，就連燃燒後也會產生酸性物質，造成空氣汙染。」
蔡承訓和王維德、紀冠宇、江佑庭、黃泓叡小朋友利用午休時間，以「筷裡乾坤」為題展開研究。
他們收集市面上各種免洗筷用水浸泡後，種植綠豆。結果發現，筷子才泡水一個星期就「臭得不得了」。
王維德說：「用這些發臭的酸水種綠豆，結果不但發芽速度遲緩，且豆子長到五六公分就停止生長，最後死掉，可見免洗筷中含有的酸性物質是有害的。」
江佑庭說，最可怕的是：「收集筷子燃燒後的煙霧，再用試紙測試，結果呈現高度酸性，如果排放到空氣中，一定會影響人們健康。」
紀冠宇說，研究過程中曾經不小心被嗆到，感覺很難受。這次得獎真的好高興，希望這次研究能夠引起社會大眾重視，讓「自備餐具成為全民運動」。

這是一篇很環保的研究，但讀著讀著，我無可救藥的強迫邏輯官能症又犯了!
小朋友的研究動機及做出的結論或許是對的，但研究的推論過程看來大有問題!
1) 筷子泡水一週臭得不得了: 發臭的原因未必與毒性物質有關，更何況又摻入了長時間的生化反應當變數! 雞蛋放一週不但會臭，而且還可能長綠毛耶~~ 但不能推論蛋有毒吧!
2) 拿筷子水養綠豆: 適合綠豆不等於適合人! 拿醋來泡綠豆，完全不會發芽，無法證明醋比筷子來得毒? 再不然推出人應該多吃泥土永保健康的話，也很嚇人。
3) 筷子燃燒後的煙溶於水呈酸性: 焦點應該放在正常使用筷子是否會造成傷害，證明燃燒的煙霧有害(文中提到: …如果排放到空氣中，一定會影響人們健康…)跟研究筷子磨尖扎大腿會流血一樣，有點離題了。如果焦點拉回酸雨理論，試著去證明筷子存在二氧化硫，方向就是正確的，只是這個實驗中，沒有對照組(例如: 燃燒未加工的相同竹材)，我們無法得知酸是來自二氧化碳(有機物燃燒會產生大量CO2)或是因為那殘留的少量二氧化硫? (一般雨水因為CO2，PH值就會達5-6.5)
小朋友的天真可愛並沒有錯，這也不是什麼黑心科學研究，要說真有什麼不對勁，我覺得責任也在在指導老師跟評審委員身上吧。科展不應該像YoYo點點名，以讓小朋友高興為目的，而應該讓小朋友學到正確的科學實驗與邏輯推理的精神。不能因為因為結果正確，就認定驗證的過程也是對的，才不會讓科展失去了最核心的精神。
(呵! 好像言重了，小朋友不要難過，叔叔有練過的。)

倔強的DataGridView Header Column

2006-06-15T22:46:00.000+08:00

比較起來，Visual Studio 2005對Window Form程式的開發有十足改良，Friendly程度更高了!!
例如: 現在Button, Label在拖拉時，會自動跑出定位校準線，小小的功能，卻足以讓向來笨手笨腳的我感動落淚…

這幾天在用DataGridView(就是.NET 1.x DataGrid的進化版)時，調Header Style調到快要快狂:
DataGridViewTextBoxColumn c = new DataGridViewTextBoxColumn();
c.HeaderCell.Value = “FieldName”;
c.HeaderCell.Style.Alignment = DataGridViewContentAlignment.MiddleCenter;
dgv.Columns.Add(c);
以上的寫法很單純，不該出錯，但執行結果Header欄仍是靠左:

搞了半天，最後終於發現，置左是為了要留位置來放動態Sorting時的向上/向下箭頭用!!
因此，將DataGridViewColumn的SortMode調成NotSortable，文字才乖乖置中。除此之外，還發現另一件事，當你允許排序時，欄寬要留大一點，也就是欄寬必須容得下你的文字+箭頭。(之前完全無法理解為何字寬不到50px，欄寬設65px居然文字會折行，這下才豁然開朗)

美國版"罄竹難書"

2006-06-15T22:25:00.000+08:00

一直以來，Google查詢結果都是依符合度排序列出結果，其精準公正性是公認的。因為其自有一套運算邏輯，從不對外公開，也不會像其他搜尋引擎會因為廠商贊助而在其中動手腳。不過，老友SC Lu昨天Pass給我一則有趣的消息，讓我發現這個神話已經被打破了。
這陣子，布希總統在美國飽受民意支持度嚴重下滑的打擊，一群好事之徒，找到了Google排序的計算原則，讓Google在查詢關鍵字"Miserable Failure"時，符合度第一的結果就是連向布希的個人網站: (Miserable Failure要我翻譯的話，我會翻成"一敗塗地"、"慘不忍睹"，或是"罄竹難書"也可，哈)
，
這件事上了BBC NEWS，也名留Wiki百科全書。
Google在隨後，以這是一種政治偏見為由，以人工的方式修正了這項結果。
有Geek或Hacker血統的人應不會至此罷休，會想知道如何影響Google的Search排名，答案叫---Google Bomb。點到為止，潘朵拉的盒子打開囉~~
題外話: 我們的趙駙馬也在Wiki中留名囉!

ADO.NET如何處理大小寫有別的欄位

2006-06-14T23:40:00.000+08:00

今天程式寫得正順手時，忽然被狠狠電了一下。
建了一個DataTable物件，定義了一個string型別的DataColumn，並設為Primary Key，結果塞資料時，忽然跳出PK重覆的Error。
檢查之下才發現原來資料來源是區分大小寫的，所以有兩個Id值只差了大小寫，就被判為相同而撞上了。
查了Google，發現不太有人有這類困擾(區分大小寫的識別資料，並不利人的口頭溝通。依我個人的看法，最後會使出這招，多半是原始欄位位數不夠用了，又不想改Schema的偷懶絕技!)，討論不多，還有人直接回答”死了這條心吧!”
心灰意冷之餘，查了一下MSDN，哈! 天無絕人之路，原來DataSet及DataTable有個少為人知的CaseSensitive屬性，設成true就可以解決囉!

ASP.NET Debugging Tips

2006-06-13T22:57:00.000+08:00

這幾天幫忙解決了幾個VS.NET Debug上的小問題，特別拿出來分享一下:

1) 要Debug Localhost上的ASP.NET程式時，彈出一個跟Debugger Users群組有關的錯誤訊息，如下:

此時建議先檢查兩個地方: 1) IIS Web是否已停用匿名存取? 2) 測試時用的使用者是否為Debugger Users的成員?
這兩點都挺明顯的，並不難發現，比較煩的是第三種隱性的狀況，也就是其實與”Debugger Users”沒有關係，也並非真的權限不足，而是IE的自動登入沒有設妥。對第三種狀況來說，這個錯誤訊息”誤導”效果十足。
要檢查是否為自動登入問題，方法很簡單。先確認你的Debug StartPage URL，例如: http://localhost/myweb/test.aspx。接著在IE中輸入這個URL，此時若IE跳出來問Username/Password，就代表自動登入沒生效，也就是所謂第三種狀況。如果你確定已取消匿名存取，而且也開了整合式驗證，則可以看看是不是IE的進階設定被改了。如下圖:

2) 延伸以上的問題，若只能用自動登入啟動ASP.NET的Debug Mode，又要怎麼用其他身份登入做測試呢?
啟動Deugger後，它會咬住ASP.NET Web執行的Process(w3wp.exe on Windows 2003, aspnet_wp.exe on Windows 2000)，此時該Process下的所有Web動作都受到監控，並不只限於VS.NET開出來的那個IE。了解了這個原理，大家應該想到解決方法了吧?
另開一個IE，用另一個身份連到同一Web就OK了! 甚至，我常常會留著這個IE開著，每次重新啟動Debugger後，再Refresh一次就可了囉!

SQL 2005 SP1登場，DB Mirroring封印解除!

2006-06-09T23:44:00.000+08:00

自去年底SQL 2005上巿後，我在新系統規劃上就多半以SQL 2005為主了，主要理由是如果要採購，沒理由買舊版，加上T-SQL強化、SQLCLR等特性讓人很動心。還有很重要的是，SQL 2005推出的Database Mirroring用光華牌PC就可以組出容錯的DB Server，比起富貴人家才架得起的SCluster Solution，實在是一大福音。只是今年初我才發現原來這玩意還有Bug，微軟在官方文件中挑明了拿來用在Production環境的人，後果自負；更設定了啟動時要加特別的Debug Flag作為封印，讓用Mirroring的人沒藉口說是不小心拿來用的。頓時澆了我一頭冷水，沒有官方保證的架構，用在公司系統中，萬一有狀況，不被大老闆推出午門問斬才有鬼。
針對此時問過台灣微軟，大概知道的消息是會在年中出Service Pack時會正式納入。今天接到SQL達人Ryan的MSN，說SQL 2005的SP1出來了，而且日期還是4/18推出的(納悶為什麼台灣微軟沒主動通知，該不會他們也沒發現? 哈)。由SP1的文件，證實了Database Mirroring已確定可用於Production了，而且那個MS用作自保的啟動Flag也作廢了。
Database mirroring has been enabled in SQL Server 2005 SP1. Database mirroring is also supported for production deployments. The trace flag for testing database mirroring (t-1400) has been deprecated. Therefore, this flag has no effect in SP1.
另外，SQL 2005 SP1還加了不少新功能，這些等用過了，發現有好玩的才提吧!

貓空行腳3-待老坑山

2006-06-01T23:24:00.000+08:00

經過幾週的操練，樟山寺儼然成為我週末攻山頭的基地營，由家門口出發，路經行健道(喘)、樟山寺步道(汗)，大約30分鐘內就可以抵達。以樟山寺為起點，可以串接好幾條規劃良好的親山步道及小山頭，這裡先介紹我摸到的第一個三角點-待老坑山。
之所以選擇待老坑山做為我第一個挑戰的山頭是因為它的高度不高，距離也近。我的週末登山行程有個原則，為了要兼顧好爸爸的角色，我都會在兩隻小搗蛋起床前回到家(大約8:30到9:00)，坐在沙發上強作鎮定，假裝剛起床的樣子(這當然是開玩笑的，又不是去偷情)。所以安排的行程都會要必須待合在9:00前返家的要求，而待老坑山是距樟山寺最近的一座山頭(其實樟湖山才是最近的，只是… 後面再交待)。
我走的路線是由樟山寺後方走到馬路後正對的Y字路口，在Y的尖點上有石階步道可以向上行[1]，沿著步道會通過餐廳的後方，接著石階變成水泥方框內舖碎石步道[2]，然後又變成水泥小徑，還會切過一條小車可行的道路[3]，直行一陣子就開始變成泥土小徑，右方是菜園、左方則是被剃光頭的荼樹園[4]。此時右方會有石階可以向上[5]接到花崗岩步道，這條步道向左可通往三玄宮步道、銀河洞還有鵝角板山，向右就是往待老坑山的方向，一路上有明確路標，不必太擔心。比較起來，北市的登山路線雖然略嫌人工化，但路標清楚實在是對登山菜鳥無比的恩澤(幾週後爬了北縣管轄的二格山，就讓我初嚐山中迷航心慌慌的滋味)。

[1]Y字路口向上走階梯	[2]水泥框+碎石子的路面
[3]步道與水泥小徑相切	[4]秃頭茶樹與菜園
[5]右轉向上石階	[6]可由杏花林下山

向待老坑方向走沒久，就到了登山起點，脫離步道改走土路，沿著不太陡的坡度向上走，沒多久就可抵達山頂，在此我摸到人生中第一個三角點。只可惜山頂在樹林中，毫無展望可言。沿原路回到登山口，可以改走杏花林的方向[6]回到指南路，接著右轉前行就能回到樟山寺。杏花林在初春時滿山花海、遊人如織，是很有名的景點之一，用Google查一下可以找到很多資料。
回到樟山寺，在樟山寺的石碑旁有個登山入口，樹上結滿登山隊的布條[7]，還有個小小的鐵牌子寫著樟湖山，沿著向上的泥土小徑不用五分鐘就可以抵達一片依坡而闢的菜園，視野還算不錯[8]。在最高的地方是一畦圍起來的菜園[9]，大家來到這裡，要記得探望一下在坐牢的樟湖山三角點。這個三角點雖然常年被圈在私人菜園中，並長年有水壺相伴[10]，應該也不會寂寞吧!

[7]樟湖山登山口	[8]樟湖山的視野不錯
[9]身陷菜園的三角點	[10]有茶壺相伴的三角點

求學之路的起點

2006-05-28T00:42:00.000+08:00

女兒滿四足歲了，終於到了可以進幼稚園的門檻。之前Survey的結果，公立幼稚園在費用上便宜許多，但多半要抽籤才有得唸，私立幼稚園的學費+點心費+一堆有的沒的費用，原則上比唸研究所還貴。
原本打算今年去報兩個巷子口外的萬興國小附幼，結果某天神奇的事發生了... 出了爺爺家的門，兒子堅持要走另外一邊，害得原本要去買點東西的我得抱著他繞一大圈。但也因此經過了里長辦公室，在公佈欄中忽然發現政大實小附幼招生的公告，而印象中只有政大教職員子女才能就讀的政大附幼，原來也開放社區居民就讀，這才我的女兒有機會來當我的學妹了。
在兩週前報了名，由報名約略的統計來看，發現中籤率並沒有想像中的低，約2/3的機會。或許是少子化的趨勢加上經濟蕭條，導致出生率下降的結果吧! 報名程序單上寫明了今天(5/27)早上9點抽籤，逾時失格。
今天大早就把兩個小鬼挖起來，一家子熱熱鬧鬧地前往幼稚園去賭一把! 到了幼稚園，寬敞的教室的設備讓我大吃一驚，一個班級的教室就近百坪，全部為木地板，前方甚至有一個小舞台，室外則有各式樹木花草、木製的溜滑梯等遊戲設施... (細節就不多說，有興趣可以到政大附幼的網站去看)
通知書上載明了本次保留給社區居民共有22個名額，參加抽籤的共計33個人(據說去年有50多個小朋友抽，是因為龍年嗎?)，所以真的是66%的機率，原則上運氣不要太糟，要抽到應該沒什麼問題。抽籤的方法是將所有小朋友的名條放入透明塑膠管，叫女兒自己將小管子放進籤桶中居然被桶口給彈了出來，這這這...
抽籤的方法很新鮮。由園長抽第一個，第一個的家長或小朋友抽第二個，以此類推，挺有意思的玩法。抽到第一名的媽媽笑著說她的大兒子也是抽第一個(運氣真是好到讓人忌妒)，接著第二個、第三個... 我們的心情也開始往下沈，金包銀的前奏在腦海中緩緩響起，難到連2/3也抽不到嗎??
22個正取都抽完了，女兒仍然榜上無名，此時老婆已經一臉失望的表情。此時忽然傳來熟悉的名字，女兒被抽中備取第一名，哈! 這是可以被接受的結果，因為報到時跟老師打聽的結果，備取前三名入園的機率非常高，更何況我們是備取第一，所以除非中了樂透，否則應該可以如願就讀。
之後前三名備取的家長也被要求留下來聽取幼園簡介及家長注意事項，由於園區完全在政大校園中，所以我現在每天爬的後山及樟山寺步道等也將會是我女兒野外課程的活動範圍；老師們還說了不少小朋友教養、保健的注意事項... 開始愈來愈清楚地體認到自己不再只要寫寫程式、有份好工作就算擁有成功的人生，從此如何當好爸爸的角色也會是我績效考核中重要的KPI。女兒求學路的起點，也是我人生另一段路程的起點。

實戰系列3-UltraEdit游標偏移問題的研究

2006-05-25T22:48:00.000+08:00

UltraEdit實在是Programmer的好朋友，隨著版本的更新，功能愈來愈強大。對不同Language(C++, Java, Javascript, HTML>的保留字、標籤可以彩色標示之外，甚至還可以收合{ }所保含的程式段哩!
不過，印象中，新版本(11+?)的UltraEdit在編輯中文時，有時會有游標定位偏差的問題。最近用UltraEdit在編輯一個XML檔，就被搞得很煩。例如: 滑鼠點在第20欄，但輸入的文字卻被插入在25欄的位置。只是這個問題似乎又不是所有中文檔案都會發生，就更離奇了。
今天找了點時間，總算摸出它的Pattern。這個問題要發生有兩個條件:
1) 文件是UTF-8 Encoding(那個XML不巧就是UTF-8)
2) UltraEdit的字型選的是Courier New(UltraEdit 11的預設值)之類的字型
既然原因這麼明確，要解決就簡單了。在選項設定中，將字型選為"細明體"、"Arial Unicode MS"之類有涵蓋中文的字型，雖然醜了點，但游標偏移的狀況就會消失了。

黑式KM理論

2006-05-25T22:17:00.000+08:00

說起來我也算Coding界的異類。
絕大部分的程式設計師談起搞程式抓問題，無不眉飛色舞；但只要一提到寫文件這檔事，頓時就面如死灰，判若兩人。如果你給一群Programmer兩個選擇:
要寫文件或是掃廁所? 大部分的Programmer會立刻衝向洗手間搶唯一一枝的馬桶刷。
我熱愛Coding，三天沒寫程式就會坐立難安；但是跟大部分Programmer所不同的，只要是邏輯較複雜的程式碼片段，註解列佔程式碼的比例常常會高達30%。而解決技術問題後，我多半會寫下技術心得(姑且稱之為知識庫文章，Knowledge Base，KB)，跟同組的夥伴分享，更重要的是在多年之後再遇同樣的問題時，可以立即回想起所有的細節，而非抱頭苦思數小時，最後重頭Try起。
幾年下來，我大約累積了近千篇的KB文章，也開始進入倒吃甘蔗的境界。這一大堆自己留下的麵包屑變成我多年IT生涯取寶貴的資產，到後期有人向我求援詢問時，有時兩分鐘就能完成搜尋+轉寄的動作，立即結案。這樣的水準，即使稱不上"文件達人"，也總可以說是"KB魔人"了吧?!
除了自己寫，在過去一小段扮演主管角色的歲月中，我也試著去營造撰寫技術文件的風氣。在當年KM喊得震天價響的年代，每每有與KM沾上邊的計劃，也總與我脫不了關係。但幾次經驗下來，我的心得是:
KM最困難的一段在於如何讓大家樂於分享。除了KM理論派一定會提的獎勵外，我個人則主張在蒐集的管道上不要加太多限制，例如: 設計了KB基本資料表，要填一堆類別、關鍵字、適用軟體之類的。當User想到要填就很頭大，往往就是讓KB貢獻量以幾何級數下降的元凶。在我看來，我們能累積的KB數很難達到"罄竹難書"的規模，因此用全文檢索或靠印象多半就能解決搜索的需求，這些詳細的分類與索引工程幫了倒忙，沒在快速檢索上做出貢獻，反而成為扼殺人們分享熱誠的幫凶。
我看過好幾次的KM工程，一開始就花了80%的時間在討論分類方式與項目，決心要用最嚴謹的知識體架構來歸納各個部門千奇百怪的知識。不過要涵蓋這麼大範圍的知識領域實在是件龐大的工程，加上人多口雜，大多被押著來開會的可憐蟲多半只想應付了事，通常還沒能熬到討論出結論，KM計劃就無疾而終了。哈!
所以我的主張是，要做KM，與其想架構、搞機制，不如快建起讓大家可以方便書寫、自由發揮的平台，早點打開知識匯入的水龍頭，這樣還比較實際。Blog、Exchange Public Folder都是很不錯的選擇，至於分類? 等知識多到每次查什麼關鍵字都會查出幾百筆時，再找兩三個人花一星期去整理，都還來得及。
簡而言之，Just Do It!!

黑暗執行緒

漫漫搬家路~~~

TIPS-解決SandCastle File Helper Builder的Unresolved assembly reference錯誤

Microsoft MVP!

毅力的極限，再來一顆不一樣的三角點

TIPS-XHTML下如何強制指定SPAN寬度

KB-Oracle轉SQL的日期陷阱

TIPS-抛棄式的Email信箱

KB-Oracle 9i NVarchar求生守則

KB-Modal Dialog Mini FAQ

TIPS-如何停用工具箱的自訂控制項清單產生功能

Visual Studio 2005 SP1 來了

KB-Unicode編碼解析小工具

TIPS-如何修改Reporting Service的報表匯出選項

KB-IIS重裝後的Reporting Service還原

KB-VS 2005中拖入自訂網頁控制項時出現錯誤

KB-失控的HTML物件

KB-在Reporting Service群組中顯示頁數

KB-Reporting Service Paging By Group

KB-無法將放在網路磁碟機的Custom Control加入VS.NET 2003工具箱

女兒的校外活動日

KB-在Oracle中直接取得中文字串長度

KB-.NET 2.0 分散式交易新利器---TransactionScope

KB-VS 2005: 找不到Web Project(.csproj/.vbproj)檔案嗎?

KB-令人驚豔的.NET 2.0 XmlDocument

KB-用VS 2005 Build Web Site，總是慢到讓你想哭嗎?

KB-ASP.NET 2.0 TextBox.ReadOnly之行為改變

Windows Sysinternals!! Process Monitor 1.0!!!

草湳大榕樹病了

TIPS-關掉VS 2005的HTML語法檢查

GridView 欠擠 DataGrid, OK ga?

KB-老友歸隊吧! 在VS 2005中使用DataGrid

KB-IE6下的網頁縮放解決方案

網路如虎口

KB-解決Flickr Uploader當機問題

831病毒事件後記

KB-將C#程式碼轉成HTML格式

不一樣的三角點!

KB-相見恨晚的IE Dev Toolbar

天梯

鐵人。鐵馬。鐵腿 。國慶。中秋

Scott Hanselman的工具百寶箱(2006版)

KB-活用Visual Studio的Task List

TechEd 2006 Day 2 Sharing -- 從網頁開發者角度看IE7

KB-ThinkPad! 把Windows Key還給我~~

TechEd 2006 Day 1 Sharing

KB-To Delete DataRow via DataAdapter

KB-SQL 2005資料庫維護計劃要如何設定檔案保存期限?

KB-ASP.NET 2.0 網站部署的變革

病毒震撼教育

跟防毒公司比賽--黑暗版的病毒警告

KB-不可信的LENB函數

原來Blogger也會掛點

鐵馬小試--關渡

是洋蔥嗎? 不! 是Windows Live Writer!!

KB-誰在叫我? .NET程式呼叫歷程的追蹤

KB-Javascript字串的特殊字元處理

KB-NetLogon 5774 Error Event

38公里的鐵馬暖身操

黑暗登山團初登場

KB-QueryAnalyzer Bug??

KB-SQL 2000的資料庫變數(Table Variable)

KB-Restore SQL 2000 Backup on SQL 2005的帳號刪除問題

環遊世界進度表

偷得浮生半日閒

XML Attribute的特殊字元處理DIY

從木柵看海的日子

35℃, 678m, 55min, 1.3Kg-->搥心肝

被Javascript電得哇哇叫--location.href Behavior

機器更名大作戰

文字檔Encoding的識別

Live Messenger不明連線謎底揭曉!

USB 2.0 vs SATA速度測試

頭腦體操--解答版

KB-Windows Live Messenger可疑連線解密

世足賽的驚嘆號

KB-詭異的NOT IN

變調的電腦展

陰險的Bug，沈重的一擊

蕃薯藤新聞，救甘心ㄋㄟ~~

鐵人。鐵馬。鐵腿。國慶。中秋