最近在學習 Ruby 的過程中，接觸到'Mix-in' (混成) 這個新名詞。雖然是個新名詞，但其概念嚴格說來並非 Ruby 所獨有。

Mix-in (混成) 之基本概念在令行為抽象化，使其與特定類別或實例無關。我們再將這些抽象行為組成新的類別或個體。早期的模組化編程概念，其實就已經建立了這種概念， Ruby 則是聰明而有效結合模組與類別，增加許多設計彈性。

由 PHP 資安團隊 Hardened-PHP Project 支持的 month of PHP Bugs 開始了，不到一週已經公布了十筆以上的 PHP 安全漏洞。 PHP 的使用者快去查看自己的 PHP 程式是有否漏洞。

我大略看了一下，去掉那些罕用功能之漏洞，到目前為止有不少一般性的安全漏洞集中在 PHP4 。想想目前多數虛擬主機供應商仍只提供 PHP4 服務，真要為其中運作的 PHP 網站系統之安全性捏一把冷汗。

有兩個結構性的 crash bug: PHP Executor Deep Recursion Stack Overflow、PHP Variable Destructor Deep Recursion Stack Overflow。前者是遞迴深度、後者是巢狀陣列深度，這兩個安全漏洞與函數調用層數過深導致堆疊溢位有關。這是 PHP 解譯器的結構性問題 (其實每種程式語言都會有這類問題與相應限制) ，照 month of PHP Bugs 中透露的消息來看，短時間內 PHP 開發團隊還不會做出相關修正。

jaceju 在 重新認識 JavaScript 一文的回應提到了 JScript 及其用於開發獨立程式的事。我先釐清名詞與觀念： JScript 是 ECMAScript 的實作版本，不是 JavaScript 的延伸。

ECMAScript 是一種語言規範。而 JavaScript 和 JScript 則是這種規範的具體實踐。除此之外 Adobe 用於 Flash 上的 ActionScript 也是 ECMAScript 的實作版本。

說到 JavaScript ，大概每個程序員都會寫一點，但真正把 JavaScript 當作一個程式語言認真學習過的人卻不算多。還是有人分不清 Java 和 JavaScript 的差別，還是有人把 JavaScript 當作 Java 在寫。你知道 JavaScript 如何實現封裝與繼承嗎？你知道 JavaScript 如何作 Reflection 嗎？你知道 JavaScript 如何實現匿名遞迴嗎？如果你無法理解上述內容或者發覺它看似熟悉卻又如此陌生時，那麼就應該拋棄以前的錯誤認知，重新認識 JavaScript 這個老夥伴的真實面貌。

繼《重新認識JavaScript》後，再介紹便於學習與測試的互動模式工具。

動態語言強調立即反應，最好使用者輸入什麼敘述，執行環境就立即顯示結果，發生錯誤亦可立即修改。然而 JavaScript 傳統的執行環境 (host) 是在瀏覽器上，所以我們通常習慣將 JavaScript 程式碼編輯儲存在檔案中，再開啟瀏覽器執行。這方式在學習時有些缺點，像是訊息輸出便非常麻煩。試想，如果你要練習用迴圈顯示一個九九乘法表，在上述環境中你可無法直接 print 、puts 或 echo 在瀏覽器上啊。最簡單的方式也要先指定一個文件節點，然後設定其 innterHTML 屬性才行。

在 Taiwan.CNet 上看到喲哪桑寫的《GPS與軟體流程》，我想到了軟體工程中確實存在著類似 GPS 的智能代理者 (Intelligent Agents) 。

守法是國民的義務嗎？守法是天經地義的，還是可以選擇的呢？

其實在中國道家與西方經濟學中，對法律這玩意就已經有相當深入的科學性探討 (道家原本就是在禮法崩壞之際發展出來的系統性理論；經濟學在一百多年前還是屬於道德科學或法學科目) 。雖然法律也有「規律」的概念，但它絕不是客觀規律、不是任何物理學運動規律。法律純然是主觀性概念之人為產物，法律的內容從來不是天經地義。嘛，有些人認為所有「規律」都是客觀的、天經地義。在那些人眼中，光講出「法律的內容從來不是天經地義」就是反動分子。

在我看來，要真正認真地思考什麼是法律，就要先釐清什麼是天經地義的客觀規律，什麼是人的規律。

TWPUG.net (以定義為基礎的程式架構 - Andromeda) 提到一個 Configuration Driven Development 的 Framework: Andromeda。 Andromeda 開發流程像是在塑模，然後自動產生應用程式。讓我覺得像在 Eclipse 上用 UML 塑模然後產生程式碼一樣。所以我覺得它像是 application platform ，而不像是 framework 。而它在處理 Object/Relationship Mapping 時用自創的語法，不是中介資料格式、不是 UML 、不是 SQL 也不是 PHP 。這麼做有沒有好處呢？目前我還看不出來。

在 developerWorks 上看到《Flip for Flapjax》介紹 Flapjax ，聲稱是比 JavaScript 更好的 Web 應用程式語言 (better-than-JavaScript programming language for modern Web applications) 。官方網站上提到 Flapjax 的特色為：

日前看到 開放原始碼社群的獎金募集系統草稿 和 台灣是不是也有可能發起自由軟體樂捐的活動? 這兩篇的想法。他們都討論我們是否可能建立一個系統化的樂捐、贊助機制，期望進一步活絡開放源碼社群發展。對此，我也提出了一些個人觀點。

這一陣子一邊學 Ruby 語言，一邊翻譯它的文件。這翻譯工作還真累，明明一眼看過去就懂的東西，再用中文寫出來竟然要推敲半天。 Ruby User's Guide 裡的一節至少要花上我一小時。翻譯真累。回想起來，我當年翻 PHP Manual (PHP3/PHP4) 時都沒這麼勤奮，這跟 PHP Manual 的翻譯工作不方便也有關吧。 PHP 要用 XML 格式編輯，還要透過版本控制服務，還有一點，現在正體中文沒有維護者。我就懶得動手了。

現在也跟 Ruby 社群的人搭上線，開始幫忙翻譯 Ruby Programming@wikibooks 的內容了。這是 Ruby 官方網站列出的四本線上 Manuals 之一，有興趣的一起來 wiki 吧。

Ruby User's Guide 的翻譯初稿見此：Rock Say Ruby 。翻完之後，也會提交給 Ruby 正體中文官方網站的維護者。

御宅族不是家裡蹲，オタク≠NEET 。要不是今天看了聯合報的社會新聞「你好宅」(聯合報民國96年2月25日A3版訊)，我還不知道台灣已經自創「宅男」一詞表示「家裡蹲 (NEET)」了。聯合報的記者還算敬業，至少 wiki 做足功課 (御宅族@wiki) ，明白指出「宅男」是台灣人望文生義之下自創的詞語，和「御宅族」的意義有所不同。ACG 愛好者在使用時要小心，對圈外人可別用「宅」這個字，當圈外人說自己很宅時，也要嚴正指出：你搞錯了，我可不是家裡蹲。

常常看到如下例關於自由軟體的觀點：

目前很多人對自由軟體的評價是：不好用。這剛好跟開發者的思維有關。許多自由軟體使用者喜歡功能精簡的軟體，自由軟體開發者自然也有這樣的思維。但是大多數的人想法剛好跟這些人相反。 許多自由軟體現有的問題探討

我以為此一「問題」其實是從以往商業軟體的使用習慣為出發點才存在，同時摻雜了使用者對自由軟體抱有「無私分享」之理想的「偏見」。

我在 網路服務與純 JavaScript 應用之 JSON 資料包裹解決方案 提到的概念，其實最初也是在 Google 上看到這種概念。只是我那時寫著寫著，卻忘了 Google 的方式... 網友忘幽谷提醒才想起。

Google 查詢服務回傳的資料格式是它自家的 GData 文件 (GData uses either of two standard XML-based syndication formats: Atom or RSS) 。為了讓使用者能建立純 JavaScript 應用， Google 就提供了將 GData 資料內容改用 JSON 格式包裹在 JavaScript 程式碼中的服務方式。

本文標題取自《失控的進步：復活節島的最後一棵樹是怎樣倒下的》這本書的副標題。對於該書所談的內容，我從經濟學的觀點來談「復活節島的最後一棵樹是怎樣倒下的」。

在 Web 2.0 的浪潮下，有愈來愈多的網路服務推出，如網路相簿、網路書籤、網路書櫃等等。大多數網路服務都有提供 Blog 使用的小工具 (或稱 Badge) ，從軟體設計的觀點來看，這些小工具才是我們在談的「網路服務」、「服務元件 (service compoent)」。

我最近在玩網路書籤提供的這些服務元件，就我觀察這些服務元件主要分兩種形式：一、以一段固定的 JavaScript 程式碼輸出網頁內容；二、僅提供 XML/JSON 資料，讓使用者自己處理程式邏輯。這兩種形式各有限制。第一種包辦了資料和程式邏輯，使用者只需／只能用 CSS 調整外觀；而且因為包含了 JavaScript 的程式邏輯，所以不同服務者提供的服務元件放在同一個頁面時可能會相衝，有我無他、或者大家一起掛。第二種則受限於 XMLHttpRequest 的安全性限制，基本上不能做成純 JavaScript 的應用。

為 Ruby 在 Blogger 上加了個網誌，叫 Rock Say Ruby，主要用來放置我整理翻譯的 ruby 文件。目前我只整理同樣是以 GFDL 條款散佈的 Ruby User's Guide 和 Ruby Programming (這是 WikiBooks 上的 wiki 版) 。

作為我個人的 ruby 學習筆記，我的翻譯以「快」為主，不求信、達、雅。我在翻譯時最花時間的不是搞清句子的意思，反而是在一些術語、名詞上打轉。如 object ，我最初接觸時翻作「個體」 (資策會翻的) ，但後來反而是「物件」一詞普及。十幾年下來，不難看出「物件」一詞不夠達義，所以我堅持不用「物件」一詞。我秉持「言者在意，得意忘言」的態度，更不覺得一個英文詞就一定要固定對應一個中文詞才叫正確，所以我的翻譯內容可能不會有很多慣用譯詞。反正我都是用 GFDL 散佈，看不下去的人可以自己再重翻。

在《Load and Execute JavaScript on Demand》一文中，我說明了利用 XMLHttpRequest 動態載入外部 JavaScript 程式的技巧。然而那技巧是用於應付某些特殊情境之手段，其限制與特點如下列所示：

1. 受限於 XMLHttpRequest 之安全性管制，不能載入不同主機的外部程式。
2. 易於掌握載入狀況及執行順序。
3. 執行方式較具彈性，甚至可以選擇性執行片段。例如《Load and Execute JavaScript on Demand》之範例程式第74-79行之註解內容，原意是截取夾雜在一般 HTML 文件中的 JavaScript 程式碼，且僅僅執行此片段程式。此亦為該程式實作之最初用途，因為外部 JavaScript 程式碼並非位於純粹 .js 文件中，而是夾雜在網誌的文章中。

唉唉，我差點被 Tokimeki 搞糊塗了。在他的《函數設計準則 (2)》一文中，他設計了兩個函數，一個是一次只處理一筆的 (載入單一模組、寫入單一記錄, etc) ，另一個是批次處理的。

Reflection ，一般譯為「反射」。但我一般說這是 讓 object 看到自己的外貌的功能(PHP5 的動態函數/行為調用效率測試) 。這說法似乎和「反射」一詞扯不上關係。事實上，我稱這種能力為「自識」能力。