回應「對SqlParameter的不求甚解」一文。SqlParameter 和 Ad-Hoc 這兩種用法的選擇，嚴格來說是 programmer 的態度與技術問題，而不是安全性問題。我的習慣是 Ad-Hoc ，但我同時強調，資料的驗證與查核是 programmer 的份內工作，所以我的程式風格如下。試問這種 Ad-Hoc 寫法的安全性，會比 SqlParameter 差嗎？

基於工作需要，我翻了一下 .Net Framework 中對 XML Schema (XSD) 的支援，想找在程式中維護 XML Schema 的方法。找到了兩種方法，一種是使用 System.Xml.Schema 類別，另一種是透過 DataSet 。以下是分別用這兩種方法產生同一份 XML Schema 的程式。

因工作需求，近日來專注於用 ECMAScript/JavaScript 強化 web application 的互動性。發現了幾套強力的 ECMAScript 工具，可以簡化不少常用功能的開發，更可讓 programmer 無需關注不同新、舊版瀏覽器的行為差異。說明一下，我所稱的「舊版瀏覽器」包含 M$ IE 6 。

對一個個體導向 (Object-Oriented) 的老手而言，敏捷編程和輕量級開發的原則與原理，應該是似曾相識，非常熟悉的。敏捷編程所揭示的原則與原理，和個體導向是分不開的。事實上，那正是個體導向技術所追求的目標。

看了一篇文章Using the SQLXML data type，這篇文章有幾個關鍵字吸引我的注意，其中之一是 SQL:2003 ，另一個是 XML 。想想，我不久之前還在看 SQL-99 的內容，突然之間 SQL:2003 就在我眼前冒出來了，而市面上許多 SQL 書籍的內容，連 SQL-92 都說不清楚。 SQL:2003 現在直接將 XML 視為內定資料型態，更為逼進 OO-RDBMS 的目標了。近期內，更是直接支援 O/R Map (個體／關係映射) 。

既然前面談到了 O/R Mapping ，那就順便再補上一篇參考文章: Object-relation mapping without the container。簡體中文: 无需容器的对象关系映射

最近因工作需要，開始接觸 .Net Framework ，公司用的是 M$ VisualStupid 2003 .Net ，而我在家裡，當然是用 Mono 囉。說到 VisualStupid 這套工具，真是讓我愈用愈氣。我不懂 M$ 在想什麼。

ASP.Net:: 自定控制項的 Property

在自訂控制項類別中，定義 public property 成員，則在 ASPX 頁面標籤中，就可使用相同名稱的標籤屬性(tag attribute)。 ASP.Net 會在 Page_Load() 之前就調用自訂控制項的 property set method ，設定控制項的屬性值。

Validator 驗證動作的執行時機

MSDN: 「因為這個屬性的預設值為 true ，所以如果您在執行驗證前查詢這個屬性，它會傳回 true 。例如，如果您企圖使用網頁之 Control.Load 事件中的這個屬性，則可能會發生這個狀況。」

有一部份人，認為筆劃的簡化是一種「進步趨勢」、「歷史規律」，因此認為正體中文應該當成歷史文物了。我不否認筆劃簡化所帶來的方便性，但我要提醒的是，增加方便性的做法，並非只有筆劃簡化一途。文字簡化還有為了簡化意義，而增加字根 (筆劃) 的情形。不要摸到一根尾巴，就當做自己看到整頭大象了。

為了理解奧地利經濟學派的思想，我開始接觸近代西方的科學哲學思想著作。因為海耶克(Hayek) 的關係，一開始從 Karl Popper 著手，但我愈讀是愈不懂為什麼一般人常把海耶克和 Popper 放在一起講，因為海耶克和 Popper 的方法論之相關性並不高，不像一般人熟知的那麼密切 (與他們的友誼相比)。後來又開始接觸維根斯坦 (Ludwig Wittgenstein) 的著作，他的著作就讓我覺得很貼切。

前往: 向聯合國停用傳統 (正體) 中文說「不」連署活動

經過查證，以上事件係為誤傳。因為聯合國本來就沒在用正體中文字。但那不是我在意的重點，跟我的想法無關，因此以下內容仍然保留。我有時會很懶，有些事情會一直等到一個契機出現後，才會記述於文字上。

什麼文字優美 (正體支持者) 、什麼使用方便 (簡體支持者) ，都不是理由。我覺得講出這種話的人，對「語言」持有很奇怪的幻想。

奧地利經濟學派並不反對使用統計方法，但要求正確使用。對我們而言，統計資料是一種經過整理的歷史資料，這些統計資料幫助我們在有限的時間中，吸收大量的資訊。

奧地利經濟學派學者米塞斯(Ludwig von Mises) 在其著作《人的行為》一書中，一開始就在談「人心的邏輯結構」。當時看反覆看了數次，心中只隱隱約約地抓到一點頭緒，但還不能清晰地說出到底「人心的邏輯結構」所指為何，又有何重要性。直到我前些日子為了編輯《老子》，又重溫先秦百家對人性的討論內容後，我這才有把握能說出人心的邏輯結構所指為何。

另見: 「人心中的邏輯結構與行為元範之臆想」

Ergo Proxy 第2話中的片段內容，我有些不吐不快的想法。人心和電腦一樣，在其中一樣有一個邏輯結構存在，因此一樣地理性，一樣地正確，一樣地受到資料的影嚮而使行為改變。這一點，一般人不了解，人工智慧研究者也不了解。電腦比人要理性與正確，已經是根深柢固的偏見了。

但在本話中，我們可以看到，人工智慧體 (奧特雷) 一樣是依照記憶體中所記錄的資料做判斷，只要資料不存在記憶體中，事情就不存在、從沒發生過。由於奧特雷與中央管理局總是維持連線狀況，因此當管理局將主角被襲擊的資料，從奧特雷的記憶體中刪除 (或是隔離，不讓此資訊被同步到其他人工智慧體中) ，所以奧特雷對於主角被襲擊的事件的回答，是「有這回事嗎？」的「不理性答案」。

人的記憶機制，遠比現行電腦系統的記憶機制複雜，因此電腦系統的資料易於刪除、修改， 但人腦的資料卻無法刪除、修改。那麼要如何讓一個人發出「不理性答案」呢？就是資訊隔 離，當100人中的99人，都不知道那其他的1人所知道的資料時，自然就會將那其他的1人根 據那99人都不知道的資料所做出的答案，認定為「不理性的答案」。

另見：「我對 Mises 所言「人心的邏輯結構」的理解」

在我的碩士論文「從 Copyleft 探討著作權體系的發展」中，第三章是辯駁，第四章才是我個人對智慧財產權的見解及重點。第四章內容若以一言蔽之，即強調應重視一般人「發明」財產權的能力，而非認定只有政府法令所出者才是財產權。

按照芝加哥財產權學派 (依 Hayek (1988) 在「不要命的自負」之用詞，以張五常等學者為代表人物) 的說法，在設立財產權後，可以誘導人們主動進行協商，而降低搜尋與協商之交易成本。此一說法的前提在於，人們必然遵循此一財產權法律而願意進行協商。但若人們不願意遵循此一財產權法律時，則為了維持法律系統的威信，政府必然要增加執行之交易成本。然而在智慧財產權議題之上，我們為了維護政府法令所出的財產權而付出的「執行之交易成本」，依我之見，已經超過訂定此財產權後而省下的「協商之交易成本」。同樣按照芝加哥財產權學派的說法，這是「無效率的財產權」。

2003年時，我在「從 Copyleft 探討著作權體系的發展」一文中寫著：「選擇的交易方式愈適當，則可獲得的利潤也愈大。因此可以得到此一命題：命題4.3：選擇最適當交易方式的人，亦即掌握最適交易方式之知識者，才能獲得最大利潤。」。這句話正可以貼切描述今日資訊軟體業者所面臨的危機／轉機。

小弟的這個問題不知道會不會很笨,一塊高級的音效卡能夠取代一般的擴大機嗎? 還是說有一台高級的擴大機再推喇叭,電腦的音效卡就隨便一塊能支援5.1聲道的 就能製造出環繞的效果?希望有大大能幫我解答!謝謝!

原討論串在「PCDVD數位科技討論區」

在這個 table join 範例中，使用了 inner join, cross join, full outer join, 以 AS 將 sub-select 視為 table 再 join ，以及 group, case 等用法。這個範例雖然很長，但只是一句 SQL 查詢。拆開來是跑不出結果的。

此範例實際上取自我為了我任職的公司所寫的一個進銷存報表程式。我目前任職的公司，採用國內 飛X 公司所設計的零售業進銷存 POS 系統。這個範例中的表格及欄位名稱，直接對應該 POS 系統。另外，我是用 PHP 寫這隻報表程式，所以範例中嵌有 PHP 的變數名稱。此報表程式係依據進貨表格 (pos204) 、銷貨表格 (pos324) 及庫存表格 (product_stock) 中的貨品數量，計算出本期的期末庫存。表格 produt_stock 是我新增的，原先飛X 設計的 POS 系統中，並沒有這個表格。

這是關於 SQL 中的 CASE 敘述的另一篇應用文章。前一篇為「SQL::使用 CASE 修飾資料內容，以便進行 group 操作」。

重點為：一、處理無意義的 NULL ；二、NULLIF() or ISNULL()。