《I. M. Wright's "Hard Code"》一書的內容係來自作者 Eric Brechner 原先發表於雜誌上的專欄文章，其筆調輕鬆詼諧，有時亦頗辛辣，挺適合躺在床上看。本書還有個特色，就是每篇文章都有附一張作者「玉照」，且每一張都有不同的搞怪表情或動作。不妨到作者的部落格看看，上面的文章也延續了這種搞笑風格。這本書有簡體中文版，書名是《代碼之道》。台北天龍簡體書局可以買到，價格 180 NTD，還蠻划算，便買了一本。雖然很少讀簡體書，但讀起來並沒感覺特別困難。看了第 1 章，聯想到自己陷入參與的專案，便順手寫下一些感想。第 1 章的標題是「專案的不當管理」（Project Mismanagement），其中有一篇名為「2001-06-01：開發時程、飛天豬、和其他幻想」的文章，裡頭提到：我心裡從來沒有特定功能的交付日期，而只有一系列的「專案日期」－－里程碑、測試版、正式版發行等等。一個好的開發時程應該只簡單列出每個里程碑所要完成的功能。第一個里程碑要完成的通常都是那些「必須有」（must...

在 review 一些高抽象層次的系統分析文件時，我發覺經常出現的問題其實跟懂不懂 OO 沒有太大關係，反而跟一些基本的分析技巧以及文件撰寫技巧有關。先解釋一下，這裡的高抽象層次的系統分析文件，指的是在跟使用者訪談會議結束後，根據使用者描述的需求，以使用者目標為出發點所撰寫的初步分析文件。其中應包含使用者的角色定義、主要的事流程、情節描述等等。為了表達這些內容，我們傾向使用 UML 的使用案例圖（use case diagram）和使用案例規格（use case specification）來描述，以求表達方式的一致性。喔，對了，還有活動圖，而且是比較高階的活動圖，主要用來捕捉事務流程。在撰寫高階的系統分析文件（或者說初步的系統分析產出）時，我所碰過的一些常見問題包括：虛應故事的心態。沒有弄清楚使用案例圖和使用案例規格（use...

之前曾聽說過這類問題，但這次總算給自己碰上了：在使用 VS2008 設計 Windows Forms 時，IDE 反應速度慢到令人無法忍受。Speed up Visual Studio 2005 這篇小技巧也適用於 VS2008，依其建議調整了幾個選項之後，感覺 IDE 的反應似乎是有快一些，但滑鼠點選不同項目時還是會頓一下。如果是開發 ASP.NET 網頁時碰到 IDE 龜速或其他問題，可以試試微軟提供的 VS2008 Web 開發環境的 hotfix：VS90-KB946581.exe你也可以在 MSDN Code Gallery 網站上可以找到更多 Hotfix...

有時候覺得，要是自己認識更多艱澀、少見的英文單字，也許翻譯起來就會快多了。但轉念一想，似乎又不是這樣。每次碰到覺得不好翻譯的、猶豫不決的，往往是簡單的詞彙或片語（例如之前提到的 cannot begin to + V），只是沒把握自己譯對了，非得查個字典確認才能放心。萬一正好碰到進度落後或時程很趕的翻譯案子，搞不好就先擱著，待日後校稿時再來推敲...

翻譯時若碰到不太有把握的地方，我常常會先用前後文的語境（context）來「猜」作者想要表達的意思。除了英文之外，這還需要一點點想像力。有時福至心靈，隨手捻來都是順當的中文，但也有些時候，在房間踱來踱去也想不出個所以然來，簡直鬼打牆...

OOADA3 好不容易進入校稿階段，晚上便偷閒去書店逛逛。看到架上一本有關軟體架構設計的書，書籍封面的作者姓名是中文，可是卻又有標示譯者的姓名，不免感到好奇：中文書為什麼需要翻譯...

書名：搞定一切，還有時間玩作者：馬克．佛斯特譯者：鄭文琦這本書講的是如何管理自己的時間和工作。作者從心理層面的角度來剖析為什麼人們常常都是臨時抱佛腳，拖到最後才焦急地熬夜趕工。是啊！如果不從心理層面著手，光只知道怎麼用 Outlook 或行事曆，最後還是一樣堆了一堆做不完的工作。以下是一點筆記：專注，是工作效率提升的原動力。拖延，因抗拒做某件重要的事，而忙著處理其他瑣碎工作。藉著忙碌的假象來減輕拖延的罪惡感，為拖延找理由。但事情拖到後面，往往形成巨大的壓力而不得不去面對，最終演變成臨時抱佛腳，拼了命趕進度。如此反覆循環，永遠無法從容把事情做完。越是拖延，阻力會越大，威脅也越大。我們應該要在壓力小的時候就採取行動－－也就是壓力剛形成的時候。我們常在下意識裡先去做那些阻力較小的事情，因為它們會讓我們有藉口逃避處理那些具挑戰性與更大阻力的事情。殊不知後者才會帶給我們人生與工作真正有突破性的進展（就好像「黑天鵝效應」，真正對我們的生活有重大影響的，是那些極端事件，而非經常出現的瑣事。問自己：「你的時間值多少錢？」如果花一個小時去做某件事，你覺得值得花費你的專注力去做那件事嗎？抗拒的症狀拖延時間常花在處理瑣事與簡單工作上常做讓自己分心的事注意力經常分散有焦慮感經常出現危機與緊急狀況不想別人插手幫忙如何克服抗拒在抗拒形成阻力前採取行動。將大型任務拆解成幾個小步驟。增加不去做的痛苦（刻意增加不便性）。建立良好的習慣，盡量主動完成任務。勇敢說不「效率第一」策略的風險在於，我們極可能將省下來的時間拿去做更多瑣事。學習時間管理的第一步，就是想辦法減輕手邊已有的負擔。說「不」時，口氣要婉轉，不要聽起來像被激怒或騷擾似的。永遠不要找藉口。如果找一些藉口，你會發現你再替自己辯護。可以這麼說：「我很感激你的請託，但這件事目前無法排入我的優先順序。」或者「我目前正在專心做我的新計畫。」你的理由越平常，對方就越不會質疑。如果是老闆要求，則可以說：「我手邊還有正在處理的工作，你希望我先暫緩處理哪些，然後優先處理這件工作？」方法使用...

書名：黑天鵝效應（Tha Black Swan）作者：納西姆．尼可拉斯．塔雷伯翻譯：林茂昌出版社：大塊文化出版日期：2008-4-28一言以蔽之：Random walker 的預測無用論。這本書我是跳著看，感覺作者用很多文字談了很多東西，可是又好像只談了一點點。之所以跳著看，除了許多內容無法吸引我，多少也因為有點受不了作者的敘述方式－－太冗長、談太多拉里拉雜的東西。有點像走一趟遠路，路上的風景似乎不怎麼美麗，但偶爾在路旁的草叢裡可以撿到一點有用的東西。這裡不重複太多網路上已經有的書摘內容，僅寫點自己特別關注的部分就好。氾濫、重複的資訊「我注意到，幾乎所有人對當前事物都知之甚詳。各種報紙的內容嚴重重複，因此，你讀得越多，可以得到的資訊就越少。然而，每個人依然迫不及待地想要了解每一份剛出爐文件中的每一件事......大家成了誰見了誰、哪個政治人物對哪個政治人物說了哪些話的百科全書。然而，這一切都是徒勞無功。」...

在翻譯索引時，有一些自己慣用的譯法。本文只考慮頁頁對譯的情況。英文索引是依字母的順序編排，而且通常是多層巢狀的結構。例如下圖是字母 I 開頭的索引範例：這個範例最深有三層縮排，但只有第一層的第一個字母用大寫，其餘詞彙都是小寫。準備工作建立一份 Word 文件，先把英文索引全複製到這份文件裡。如此一來，往後我們只要直接翻譯這份文件就行了。英文索引通常採 two-column 的編排方式，所以中文索引的文件可以先在第一頁插入一個兩行的表格，然後把第一頁英文索引的文字複製過來。接著調整字型大小和頁面邊界，讓中文索引的一頁正好可以放得下一頁英文索引。調整完畢之後，以後每一頁就可以直接複製第一頁的格式。第一層的詞彙以英文為主，接著用括弧顯示中文範例：IInheritance（繼承）第二層以上的詞彙則以中文為主，必要時加註英文範例：IInheritance（繼承）　　元素語意與～,...

要是你以為穿上一雙 Nike 球鞋，就可以像喬登一當抓球飛身灌籃，這叫做「錯覺」，是自欺欺人，不可能發生的事。－－Phil Rosenzweig, 《光環效應》近日聽到一些有關 OOAD 的正反意見，這篇文章只是在整理自己對這些意見的一點感想。光環效應：過度渲染 OO在碰到推廣 OO 技術的場合，常會聽到傳統的程序導向分析和物件導向分析的比較，並宣稱如果團隊採用 OOAD 方法，軟體專案將能夠獲得許多好處。以下是我最近聽到的一些說法：更模組化。理由：藉由類別封裝，應用程式都會被切成適當大小的單元。（真的嗎？）可提高重複使用性。理由：物件導向有繼承機制。（反面來看：牽一髮動全身的連鎖效應？）應用程式更容易擴充。理由：未來如果需要增加一項新功能，我們只要增加一個類別，再動態「插入」既有的框架就行了，用戶端程式都不用修改。（如果設計得宜的話）應用程式更好維護。理由：將來如果有一個地方要修改，我們就只要改...

《UP 學：所有經理人相見恨晚的一本書》閱...

會寫這個程式，主要是因為一個重要的 Web 應用程式三不五時會掛掉，而系統管理員希望能在第一時間發現這個情況（以免使用者來電開罵）。要偵測伺服器是否掛點，可以用 .NET 的 TcpClient 嘗試連接伺服器的特定 port，這種簡單的方法不僅可以用在 Web 伺服器，也可以用於資料庫伺服器（例如：嘗試連接 Oracle 伺服器的 1521 port）。一旦發現伺服器無法正常運作，程式可以發送 mail 通知系統管理員，可是系統管理員不見得會經常收信，這樣的時效性就不夠快。現在 MSN messenger 已經很普遍，如果發現系統出問題時，能夠發即時訊息給相關人員，似乎是個不錯的辦法。這裡我用來發送 MSN 即時訊息的元件是 MSNPSharp。這個元件有附一個...

《Object-Oriented Analysis and Design with Applications 3rd edition》的附錄 A 裡面有一張圖描繪了自 1960 年以來的部分程式語言編年史（圖 A-1）。這張圖有個蠻明顯的錯誤，就是所有的年代都標示為 1960。中文版會修正這個錯誤，如下圖所示：若讀者有興趣看看完整版的程式語言編年史，可以到 Éric Lévénez 的網站：http://www.levenez.com/lang/。另外，原文書的表 A-1 是一份程式語言受歡迎程度的排行榜，其中第一名是 C 語言，Java 位居第二。此排行榜係取自 TIOBE 的 TCP-index，但從官方網站的長期趨勢圖可以看出，Java...

Configuration Management 這個術語比較常見的譯法有「組態管理」和「建構管理」，另外還有「配置管理」、「形態管理」等等。我在翻譯時採用「組態管理」，主要原因是：Configuration management 跟我們一般講的軟體「建構」不完全一樣。的確，它是有包含軟體建構過程中的版本控制與發行作業，但這些並不等同於 configuration management。「建構管理」很容易聯想成 "construction management"。Configuration 個人多譯為「組態」。這裡無意比較各種譯法，只是......把 configuration management 譯為「形態管理」，並將 configuration...

摘自 Top 100 Best Software Engineering Books, Ever，這裡只列出前 10 名：Steve McConnellCode Complete: A Practical Handbook of Software Construction中文版：軟體建構之道Elisabeth Freeman, etc.Head First Design Patterns中文版：深入淺出設計模式Steve McConnellRapid Development中文版：軟體快速開發Erich GammaDesign Patterns: Elements of Reusable Object-Oriented Software中文版：物件導向設計模式Bruce...

有位網友來信詢問五年前寫的幾篇 Java Web 應用程式設計入門的文章：1.0 前言2.0 Servlet 程式設計初步（含 JDK 與 Tomcat 的安裝與環境設定）3.0 JSP 程式設計初步4.0 JSP、Servlet 與 JavaBean 的組合應用5.0 JDBC 入門6.0 Model-View-Controller 範例我把以上文章全都包成一個壓縮檔，有需要的朋友可按此下載。解開後開啟 index..htm 即可。不過，這些文章有點舊了，裡面有些東西或許有一些過時了，建議可以找一些新發表的文章或...

我的記性不好，平日工作的一些瑣事常過耳即忘，以致於常出槌、鬧笑話，不僅如此，就連小時候的童年記憶都非常少。每聽到有人回憶童年往事，不禁納悶，為什麼小時候的事情我都想不太起來？能記得的事情寥寥可數。照某些心理學的說法，可能我的童年大都是些不堪回首的痛苦回憶，所以大腦選擇忘記它們吧！雖然能記得的童年往事不多，但有些記得的部分卻格外印象深刻，只要受到一些外在事物的刺激，那些記憶就會突然湧現。閱讀蔣勳的《孤獨六講》，便令我想起小時候祖父過世的情景。當時家裡長輩請了和尚來誦經，我們家三個小孩年紀都很小，對喪禮的規矩並不清楚，只知道依大人指示行禮、跪拜。我記得的其中一幕，是一些親戚長輩們對我們猛喊：「快哭！要哭！哭大聲點！」我跟祖父相處時間不多，不能說感情深厚，只覺得他是個慈祥又有點滑稽的老人，可是聽到那些大人的命令，我反而更哭不出來，只覺想笑。不知為何，別的記不牢，這件事情的印象卻特別深刻。蔣先生在書裡面說：「如果你仔細觀察，便會發現在群體文化中，婚禮喪禮都是表演，與真實的情感無關。」群體文化從小時候便不知不覺地影響著我們，逼迫每個人就範，必須待在大人畫的框框裡。長大以後，情況有改觀嗎？好像沒差多少。在生活周遭、職場上，壓抑個人言行的事情還是屢見不鮮。好比說，曾聽一位朋友提起，有一次他穿件...

看書時的一點聯想，順手抄上來。在《Object-Oriented Analysis and Design with Applications 3rd Edition》的第六章〈Process〉一開始提到：業餘的軟體工程師總是在尋找神奇、萬能的方法或工具，冀望它們能把軟體開發工作變得極為簡單。專業的軟體工程師就不同了，他們知道那種東西並不存在。業餘人士經常只想要像煮菜那樣照著食譜一步一步做，專家則知道這種開發方法會設計出呆板的產品，並導致開發人員用一連串的謊言來掩蓋一開始就做了錯誤決策的事實。業餘的軟體工程師往往毫不重視文件，要不然就是太過以文件為中心，只擔心客戶不滿意這些文件，對於文件真正應該呈現的重點反而不那麼在意。專家了解文件的重要性，但是他們絕不會為了寫文件而犧牲掉改進軟體架構的時間。這是業餘和專業開發人員的差別。我又想到薩依德在《知識分子論》當中的論述：....所謂的業餘性就是，不為利益或獎賞所動，只是為了喜愛和不可抹煞的興趣....今天在教育體系中爬得愈高，愈受限於相當狹隘的知識領域。當然，沒有人會反對專業能力，但如果它使人昧於個人直接領域－－比方說，早期維多利亞時代的情詩－－之外的事情，並為了一套權威和經典的觀念而犧牲一己廣泛的文化時，那種能力就得不償失。....專業化也戕害了興奮感和發現感....陷入專業化就是怠惰，到頭來照別人的吩咐行事。因為聽命於人終究成為你的專長。以上摘錄的兩段內容都提到了專業和業餘的不同，看起來兩邊的觀點是彼此衝突，不過，由於取自完全不同領域的書籍，直接拿來比較會有點奇怪。第一段的業餘和專業，講的是對自己吃飯謀生的東西熟不熟，厲不厲害的程度差別。第二段的層次則高一些，談的是忠於自己還是服從他人、是否願意犧牲自由的心靈和廣泛的興趣，以換取特定領域的專業形象（訓練有素的狗？）。我想，專業的軟體工程師也可以有業餘人士的生活態度和價值觀。而不那麼專業（業餘）的軟體工程師當然也可以透過取得高學歷、考證照等方式，為自己塑造出專業的形象（但能維持多久還是得看後面的努力了）。我好像喜歡業餘多一些...

問題應用程式使用 .NET WebClient 類別執行偵測新版本以及線上自動更新的功能，可是如果伺服器因為某些原因無法連線（如網路斷線、伺服器關機等），應用程式在檢查是否有更新版時，就得等 20 秒左右才會發生連線失敗。想要使用 Socket 或 TcpClient 類別事先偵測伺服器的 80 port 能否連線，可是結果還是一樣，因為它們並沒有提供連線逾時的屬性。解決方法可使用非同步的方式解決。以下是利用 TcpClient 類別偵測伺服器 80 port 能否連接的工具函式：/// <summary>/// 偵測指定的伺服器的特定 port 是否可以連接。/// </summary>/// <param...

摘要　　UML 套件圖的 «import» 與 «access» 概念雷同，但語意略有不同，這篇文章主要即在說明這兩個 stereo types 的差異。本文的圖都是引用自《Object-Oriented Analysis and Design with Applications》的第 5 章，部分有稍微修改（以免圖太大）。UML 套件圖基本觀念在進入細節之前，先來看一下 UML 套件圖的基本概念。UML 套件的一個主要用途，是展現系統各元素（例如：子系統、模組、元件等）的組織與分割方式。套件裡面可以包含其他子套件而形成巢狀套件，也可以包含其他 UML 圖形元素，例如：類別、Use Case 等。當我們使用套件圖來表達系統的邏輯或實體結構時，可能會需要在圖中呈現套件之間的相依關係，例如下面這張套件圖：...

當程式需要寄送 e-mail 時，我原本是透過 Hinet 郵件伺服器發送，程式碼大概長這樣： Encoding enc = Encoding.GetEncoding("BIG5"); MailMessage msg = new MailMessage(); msg.From = new MailAddress("寄信人@culala.com", "寄信人姓名", enc); msg.To.Add(new MailAddress("收信人@wulala.com", "收信人姓名", enc)); msg.Subject = "使用者意見回報"; msg.SubjectEncoding =...

使用者回報一個錯誤訊息：「無法處置 BufferedGraphicsContext，因為緩衝作業正在進行中。」而且是當應用程式處理的資料量大到某個程度時才會出現。用 Google 搜尋可以找到一些討論串，但沒有標準答案。我試了幾種方法，最後雖然解決了，但卻只是避開它而已，嚴格來講，我並沒有找到問題的癥結點。底下是我處理這個問題的過程，如果您也碰到同樣的問題，我的作法也許可以提供一點靈感。初步測試首先，我請 user 提供他的資料檔，然後在自己的兩台 Windows Server 2003 機器上測試。結果一台會出錯，一台可順利執行。碰到這種情形，自然會懷疑是因為環境組態的差異造成。由於這是 .NET Windows Forms 應用程式，因此我檢查了兩台機器的...