Saving Data Safely

http://android-developers.blogspot.com/2010/12/saving-data-safely.html

如何撰寫 Debian init script

http://www.debian-administration.org/articles/28
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit

MIT 2006 年電漿物理課程

MIT 2006 電漿物理課程

MIT 2003 年電漿物理課程

MIT 2003 年電漿物理課程

Mozilla 的 Javascript 文件

Mozilla 的 Javascript 文件

Linus on git branch

Linus on git branch

Game-Like CSS3 Buttons

Game-Like CSS3 Buttons

Super Awesome Buttons

Super Awesome Buttons with CSS3 and RGBA

Forth VM

看了一篇文章，討論 Forth VM 的設計：Updating the Forth Virtual Machine。在傳統的 Forth VM 中有兩個堆疊一個記憶體。這樣的設計不容易執行 C 編譯出來的程式。也不適合用做 DSP 的 VM。為此，文章中提出了對 Forth VM 的修正，多提供了以下四個 registers 用來存取記憶體：A、B、X、Y。

• A、B：有自動加減記憶體指標的功能，適用於 DSP，也可以用做 scratch register。
• X、Y：能對記憶體定址，可以做為 local variable 或 user variable 的指標。

閱讀過此一文章後，比對我所知的 Forth VM 設計，還必須有 TOS、IP、W。這可就用去了七個 registers。仍小於 80x86 系列的 registers 數目 8 。

特別記錄下這文章，因為我考慮以 Forth 做為我某種應用的 VM。

jonesforth

又回到 Forth，繞了一圈，在某些應用領域這個古怪的語言仍遠勝其他的 scripting languages。

在找尋一個適合我未來使用的 Forth 時我發現了 jonesforth ，依照它的文件編譯成功，執行時 Linux 卻發出了 Killed 的異警。瞭解後原來某些版本的 Linux 不允許使用 text segment at zero。

以以下方式編譯後就不會有異警。

gcc -m32 -nostdlib -static -Wl,--build-id=none -o jonesforth jonesforth.S

Ringojs

有一段時間未寫部落格。但不表示這段時間什麼事都沒發生。

這段時間發生了很多事。

首先，在個人工作方面，已經確定要將 javascript 用於自己的產品中。最主要的工具是 YUI 3 和 RingoJS。

此外，在 javascript 世界也有很多值得注意的變化。由於我較重視 Server side，CommonJS 的風起雲湧以至最後的雲淡風清讓我感到一點憂心。早先，有志於 Server Side Javascript 的人們成立了 CommonJS 社群，建立 module 的架構，以及可以讓程式相容的 libraries。但在 NodeJS 出現後，NodeJS 瞬間抓出大家的眼光。以致於 CommonJS 的努力讓人們漸漸淡忘。

在這段時間，原本我極感興趣的 Helma-NG 改名為 RingoJS，採用了 CommonJS 的規範。現在它可以說是最符合 CommonJS 規範的 Server Side Javascript 平台了。比 Helma-NG 還讓我喜歡，也成了我工作上的選擇。雖然有點兒默默無聞，但它的撰寫者十多年來在 Server Side Javascript 上的堅持讓人信賴。最近，更因一篇「RingoJS vs. NodeJS」，它開始被更多的人注意。

身為 RingoJS 的愛用者，我自然也要加入這場戰局。因此，我將這篇「RingoJS vs. NodeJS」中 RingoJS 的優點翻譯於後，和我的讀者分享，在這翻譯中加上了我自己的修正。

1. RingoJS 是最符合 CommonJS 規範的平台。此點勝過 NarwahlJS 及 NodeJS。
2. RingoJS 的執行速度快。RingoJS在執行前會經過 JVM 的編譯，同時，RingoJS 的模組是動態載入的，這使得它的 start up time很短。
3. RingoJS 成熟、穩定、不會當。這是我自己的使用經驗。我還沒遇過 RingoJS 當掉的情況。
4. 直接使用成千上萬的 Java libraries。Ringo架構在 Rhino javascript 引擎之上，它和 Java 之間的關係真是血溶於水般，它可以直接使用 Java libraries 及物件，就好像它們是以 javascript 寫成的。不像 NodeJS 等，呼叫 C 時必須撰寫各種 wrappers。
5. 程式可以在 Linux/Windows 下執行。跨平台呢。（當然也可以在目前正熱的 Android 上執行囉。）
6. 支援同步(synchronous)及非同步(asynchronous)的程式撰寫風格。NodeJS紅的原因是它強調非同步撰寫風格。但是在絕大多數的場合，以同步風格撰寫最簡單。使用 Ringo，簡單的問題可以簡單解決，複雜的問題一樣能解決。
7. 因為「AppengineJS」提供了大量可以在 Google App Engine 上使用的 libraries，RingoJS 很適合用來開發 Google App Engine 上的雲端運算程式。
8. RingoJS 的 Leader 技術一流，又十分親切，願意傾聽使用者的建議。

Scala vs Javascript

在撰寫 javascript 程式時，我較不習慣的是它缺少靜態型別的檢查。一直希望有一種語言能結合動態型別和靜態型別語言的優點。因此最近看到 Scala 時我充滿興趣。

我花了一些時間瞭解 Scala 並撰寫了一些程式。這語言很容易上手。不過我遇到以下的瓶頸：

1. Netbeans IDE 的 Scala plugin 還不成熟。
2. Scala 並不是為 embedding 設計的。
3. Scala 使用 Java classes 沒問題。但是 Java 使用 Scala 的 classes 會有些問題。

因此，我還是回到 rhino，以 javascript 為我的 scripting language。

Netbeans Top Ten APIs

這兒記錄了 Netbeans Top Ten APIs 的影片中的重點：

1. Run time container由五個 APIs 構成：Bootstrap、Startup、Module System、File System、Utility。最小的 Netbeans platform application 只依賴這五個 APIs。
2. Starup API 提供了 Main。
3. Module System API ： Module 可以有個 ModuleInstaller class 來管理 Module 的生命周期。
4. Utility API：Utility API 中最重要的是 Lookup API。扮演 ServiceLoader 的角色。也使用 JDK 6.0 的 ServiceLoader 實現。Service Provider packages 在 src/META-INF/services Folder 中列出提供的 Services。
5. Window System API：TopComponent 取代了 Swing 的 JFrame 的功能。Editor、View及Mode的概念。可使用 layer.xml 及相關的檔案來建造新的 Mode。在 project.properties 中可以以 run.args.extrac=--nosplash 來抑制 splash 畫面。可以在 Properties中的 Window System API 來限制使用者的對 Window 的操作。
6. File System API：介紹了 layer.xml，以及 File System API 中的 Repository、FileUtil、FileObject。FileObject 包裝了 java.io.File，提供更強大的功能。FileObject 和 java.io.File 的轉換可由 File.Util 內的函式實現。Netbeans 提供許多 File Systems，例如 layer.xml 對應的 System File System，磁碟上的 File System，以及可以 FileUtil 建立的 memory file system。
7. 
   

學習 Netbeans Platform 時閱讀的文獻

以下列出我學習 Netbeans Platform 時閱讀的文獻。

• Top Ten Netbeans APIs

以上文獻是英文的 Videos，有時聽來有點困難，因此我還閱讀以下的文獻。

和 Runtime Container 有關的文獻：

和 Lookup API 有關的文獻：

• Creating Extensible Applications With the Java Platform
• Class ServiceLoader

同時為 VisualStudio/Eclipse/Netbeans 開發，可能嗎？

和朋友談及某些公司有同時為 VisualStudio/Eclipse 開發產品的需求。可能嗎？

今日偶然從 Eclipse E4 的 forum 讀到 eFace ，顯然就是針對這樣的需求。

iPad 的出現象徵 Intel 覇權的結束嗎？

前幾天 Apple 發佈 iPad 時，我注意到 iPad 使用的 CPU A4 竟然不是 Intel 的 CPU，而是 ARM 。為此我瞭解了一下原因：這和 ARM 精簡的指令集有關。ARM 的指令集使得 CPU 不必花費太多的電路於指令解碼，這使得 ARM 能以低耗能的方式執行程式，因此被廣泛用於智慧型手機之中。

剛才讀了一篇有趣的文章。

Is the iPad the beginning of the end for intel

文章說 iPad 的出現是否代表 Intel 的沒落？作者作出了以下的觀察：

1. Intel 保証 80x86 指令集的相容性的同時不可能滿足低耗能 CPU 市場的需求。
2. 智慧型手機市場是低耗能 CPU 的市場。
3. 提供雲端運算的這些大公司如 Google 、Amazon 愈來愈關心伺服器的耗能問題。因此伺服器也是低耗能 CPU 的市場。
4. iPad 證明低耗能 CPU 有潛力侵入 Intel 的 PC 市場。
5. GCC 的發展使得原本為 Intel 平台寫的 C 程式可以容易重新編譯後在其他平台上執行。

作者因此質疑是否 iPad 的出現代表了 Intel 世代的結束以及 ARM 覇權的來臨。這的確是很有趣的想法。但是我們不能忘了微軟的存在。除非微軟放棄了 Intel 平台，否則 Intel 還有很多年可以存活。畢竟主宰 PC 市場的不是 Intel 而是 Wintel，是微軟和 Intel 兩大覇權的結盟。

Swing vs. SWT (II)

接續之前的文章，SWT有以下的優缺點：

SWT 的優點：

1. 和底下平台一致的風格(Look and Feel)。
2. 和 Eclipse 的整合。
3. 雖然同樣不是 thread-save。但誤用時會發出異警，在這點上容易除錯。 

SWT 的缺點：

1. 不內建於 JRE 中，因此必須下載特別的函式庫才能執行。
2. 因為使用底下作業系統提供的元件，無法以 java 的 Garbage collector 管理，必須自行管理元件的記憶體，因此容易有 Memory leak。當元件之間的關係是靜態時，只要釋放最上層的元件的記憶體就好，問題會輕些。如果元件之間的關係是動態的，就比較會有 Memory leak了。
3. 不容易製作客製化元件，因為要客製化時常必須瞭解底層作業系統的 API。

有關 SWT 的迷思：

1. 在比較 SWT 和 Swing 時，常誤以為 Swing 的功能比 SWT 強大。但是真正該比較的常是 SWT+JFace 和 Swing，甚至是 Eclipse 對 Netbeans。

Swing vs. SWT (I)

最近基於工作需要閱讀有關 Swing 和 SWT 的比較。以下是我的心得。

Swing 的優點：

1. 內建於 Java JRE 中，只要有 java JRE 就能執行。不必另行下載函式庫。跨平台特性勝過　SWT。
2. 能以 Garbage Collector 管理元件，因此減少了 Memory leak 的風險。
3. 容易對元件客製化，不必瞭解底層作業系統提供的元件。這些客製化的元件馬上具有跨平台的特性。
4. 可以做出完全不同於底層作業系統風格(Look and Feel)的 GUI。

Swing 的缺點：

1. 建造 Swing 元件的程式都必須在 Event-dispatching thread 或是 Worker thread 中執行，而且必須選對 thread，否則會有 GUI 反應太慢、或是顯示出狀況的情形。當沒有使用 thread 或是該用 worker thread 時沒使用 worker thread 的情形下，程式不會發出任何警告，這類的錯誤很難診斷。目前有些輔助的工具，但尚未和 IDE 整合。
2. 主要的 IDE 是 Netbeans。Netbeans 多用於個人私下的開發案。大多數的企業使用 Eclipse，因此選擇 SWT。
3. 如果想使用 Eclipse RCP。就不適何用 Swing。
4. 因為 Oracle 併購了 Sun，使得許多人對 Netbeans 的前途感到疑慮。連帶也對 Swing 感到疑慮。
5. 因為 Sun 在過去幾年力推 JavaFX，使得許多人對 Swing 的前途感到疑慮。

有關 Swing 的迷思：

1. Swing 的速度比 SWT 慢：在 SWT 當推出時猛烈攻擊 Swing 速度慢的弱點。但這幾年 Swing 的速度已經追上，除非該用 Worker thread 的地方未使用 worker thread，否則速度已經沒有明顯的差距。
2. Swing 不支援底層作業系統的風格(Look and Feel)：這也是當年 SWT 攻擊的重點。但是如今 Swing 可以支援各種風格，包括底層作業系統的風格。

解決安裝 narwhal 的問題

在 ubuntu 安裝 narwhal 時遇到以下錯誤訊息：

org.mozilla.javascript.WrappedException: Wrapped java.lang.IllegalArgumentException: Bad language version: 180

搜尋網站找到了以下報告：
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149

執行以下指令可以解決問題：
sudo rm /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar

指令只是刪除一了指向 rhino 的連結，因此可以放心，並沒有真正刪除 rhino，只是使得 rhino.jar 不被自動加入 bootclasspath 中，導致無法使用 narwhal 自己的 rhino。

編譯 Webkit

我於是編譯 Webkit：

1. 從 Webkit 網站下載是新的 tar ball。
2. 執行 autogen.sh
3. make

Webkit/Squirrefish/Nitro Extreme

我一直想找一個可以用於我的產品的 Scripting language 及 Virtual machine。我從 Python/Ruby/Lua/Parrot/LLVM/Forth/Scheme 一路看下來，最後看到 Javascript。在 Javascript 中我先看過了 Tracemonkey，今天又看了 Webkit 的 Squirrefish Extreme (Nitro)。

我想 Nitro 是個好選擇。我已經決定在人機界面使用 Javascript+Java了。在 interpreter 或是 motion 使用 javascript 也會是個好方法。而 Squirrefish 使用 direct threaded codes，這些概念我從 Forth 學過。Squirrefish 有 bytecodes ，這些 bytecodes 可以考慮用在 PLC。

這會是一個長期的學習工作。我甚至想開始一個 Squirrefish 和 Gobo Eiffel 結合，Gobo Eiffel 使用 Squirrefish 的 garbage collector 的計劃呢。