Tom's IT notebook

　　.NET 1.1 已經是微軟不可能再回頭支援的過時玩意了，.NET 2.0 的核心才是他未來技術發展的基石 ( 目前推出的 .NET 3.5 仍是以 2.0 為底層 )。對於微軟這種全面性推翻舊東西硬是逼著你升級的做法，我是很感冒，由其是對於過去 1.1 時代就選擇支持它的群眾，如今卻被逼著必須同時安裝多套不同的 IDE 來回在不同版本的程式間作維護。 　　如今許多方便好用的功能都已經內建在  .NET 2.0 之上，回頭看看當初 1.1 寫的東西總是很想掉下眼淚，無奈自己已經誤上賊船，為了降低將來維護成本並且增加未來發展的視野性，最近幾天就鐵下心來，籌畫著將私底下仍在經營的網站，升級到 ASP.NET 2.0。 　　為了讓整個升級過程無痛，我不想讓使用者發覺停機過久，盡量讓網站無法運作的時間縮短在一個「瞬間」，所以我決定利用 ASP.NET 2.0 / CLR 2.0 仍可以執行 1.1 版本的向下相容特性，決定先透過變更 IIS 內的版本設定讓 ASP.NET 1.1 開發的網站先執行在 2.0 的環境底下，等到平穩後，再找個機會以迅雷不及掩耳的速度，將重新編譯過的新版網站上傳到 FTP 蓋過舊的，這個過程理應只有幾個線上的使用者的 Session 失效，重新登入或是重新整理網頁就一切正常。 　　其實整個過程說來蠻單純的，風險應該不大，但讓我拖了一年半載遲遲沒有動手的原因，主要就是用 ASP.NET 2.0 去執行 ASP.NET 1.1 的向下相容性並沒有很好，實際跑起來還遇到蠻多問題的，一直讓我怯步。 　　首先，為了讓我的網站能同時支援以不同語言來顯示畫面 ( 目前同時支援 繁中 / 簡中 / 英文 的操作畫面 )，所以我網頁上的顯示文字是根據使用者下拉語言的選單動態產生的。我實做的方式很簡單，就是以一個 XML 檔儲存所有控件顯示的文字訊息。例如我有一個網頁 Index.aspx 上面還有一個顯示訊息的 Label ，其 ID = Label_Welcome，那我在繁中的 XML 語言檔 (  zh-tw.xml ) 就是如下： < root >     < Index >         < Label_Welcome >歡迎光臨</ Label_Welcome >     </ Index...

　　完成連續四天的課程後，昨天從 恆逸 拿到我這輩子第一張電腦技能的修業證書，沒想到既不是 .NET ，也不是 Java，竟然是做夢也沒想到的 BizTalk 2006 。 　　雖然上面印著 Certificate 的 Title ，但這只是個無足輕重的修業證明，並不是證照。然而岳父卻非常看重這個證照橫行的時代，每每面對我這個除了駕照以外一無所有的軟體工程師，總是碎碎念，認為我技不如人 、遲早被社會淘汰 。 　　Anyway，這張假證照或許日後可以幫我唬弄過去，反正他甚麼也搞不懂。 　　對於有程式開發背景的人來說， BizTalk 大體上並不難理解與入手，一本我目測約三百多頁的原文教材，包含上機實做練習，四個全天就講完了。但是我極度懷疑沒有程式開發背景的人員能夠理解 BizTalk 這套軟體的操作，所以基本上，我看待這個產品並不是取代程式開發人員的工具，但「或許」是節省開發人員時間與負擔的工具。 　　強調「或許」，是對於開發老手，他早以手邊累積不少現成的套件或是函式庫，熟悉 OpenSource 的開發資源與現成的 Class，旁徵博引的開發效率未必會比滑鼠設定 BizTalk 內的各個 Pipeline / Adapter / Schema 來得慢，甚至可能還快上許多。但是對於新進的開發人員，BizTalk 提供許多現成的基礎環境設施與視覺化設定，應該可以幫助菜鳥進入實戰階段，所以充其量，BizTalk 是個拉近新手和老手之間差距的工具。 　　也許有人會說，產品的設定與視覺化開發比起程式碼來得好維護，這應該是 BizTalk 該勝出的地方，但事實卻不然。 　　我承認菜鳥工程師的程式碼解讀時會冒出無名火，但現在比較的狀況是，[ 經驗老道的工程師   vs ( 菜鳥工程師 + BizTalk ) ] ，如果常常去看 OpenSource 的開發人員會知道，有經驗的開發人員寫出的程式碼其實不難端倪，而且可修改的彈性高出甚多，逐步除錯也容易。但是，BizTalk 的除錯非常困難，且修改不易。整個上課過程中，我就飽受「一步錯，整個重來」的痛苦，一個 Schema 建錯，可能牽涉到的 Flow、Mapper、Pipeline、Ports...全部都得跟著調整或是重建，而且如果漏掉任何一個環節沒修正，非常不容易發覺，只知道訊息有進無回。 　...