DI-524 是一款低階又功能完整的 wireless/broadband router，在英國的 d-link 網站有提供 DI-524 的 source code 可以下載（Technical Support->Download->Product->DI-524），他的授權是以 GPL 釋出，其中核心就是以 Linux 為基礎。不過他所針對的硬體版本應該是 revision E1 的機器，在台灣的機器應該都是 revision A 或 B 開頭的機器。

用 google 找 spreadsheets，可以在右手邊發現廣告欄位。有一個叫做 Zoho 的網站，倒是做了一堆 office 的產品。除了Writer、Sheet、Show，還有 Project、CRM、Planner、Mail 等等一堆，當然 google 也是有，像是 gmail, gtalk 這些。另外 google 在幾天前幫 spreadsheets 加入圖表功能，當然要看一下這家產品有哪些，還好有 sample sheets 可以看一下裡面的功能，首先，界面幾乎蠻類似 office excel，然後圖表種類也是幾乎都有，中文也沒問題，操作起來速度感覺上比 google spreadsheets 還快，還有 API 可以給外部程式來 view、modify、upload/download。在 Spreadsheet Roundup 評比裡面，zoho sheet 排第二名。 再來就是 Safari 可不可以使用，結果是不行，進得去但是看界面就知道無法使用。WebKit 問題比較少，主要是 cell 對齊，使用上可能會有問題。

聽說 SS 社的 L 大作在 '05 狂 crash，銷售也不佳，後來 training 以及 code review 時機乎最重要的重點就是，注意 pointer。只要遇到 pointer 的情況，有 * or -> 就很容易被 focus。例如 function body 前面加入對 pointer 類型的 parameters 做 check，只要情況不對馬上謝絕掉。或許這招不錯用，至少可以馬上降低 crash 次數，畢竟幾乎所有的 invalid segment access 都可以避掉，立竿見影。至少這樣可以避免得到 crash comment 一枚，因為程式沒到該有的功能所以得到 bug functional。（註：只要列出來 call stack 就是 core dump，所以單純 return 沒做事至少不會出事）。 不過源頭呢？為什麼會有 invalid address 傳進去？當然就是程式有 bug，一定有地方出錯了，所以才讓那個 bug 一直存活下來，然後還傳遞給其他地方使用。現在好了，大家看情況不對，就盡量謝絕掉。那最後一定還是會出錯，只是出錯就會錯在無法避免的地方。可能最終的源頭跟最後出鎚地點相差十萬八千里，但是 AE/QA 就會看 call stack 或執行過哪些 commands 就把 bug submit 給誰。更慘的是，如果是遇到無法 reproduce 的 bugs，更是查不到來源，因為無法再重複一次，但是他就是曾經 core dump 出來給你看。最後只是 RD 猛去 disassemble 那個位址的 assembly code 來看，然後找相對應 source code 那邊是否有 pointer access 沒有保護好或有 bug。 再來是，大家一定遇過 core dump，最常見的就是 windows 的程式執行錯誤。或是 firefox 遇到 crash 也會有。Apple 也有 crash report 功能。裡面有什麼東西，大家一定看過，不外乎就是 call stack、thread list、module list、environment variables、registers、stack dump、memory dump。就連 unix-like 的環境，也可以產生一個 core file。最神奇的是 SS 社，雖然有 segment fault handler，雖然有 coredump file，但是其實裡面是 call stack 而已，連個 registers values、stack dump、memory dump 都沒有。如果是單純的筆誤 bug，很容易看一下相對應的 source code 就查到了。但是大型軟體下，又無法 reproduce，什麼都沒有 dump，只有 call stack function chain，查得到來源才有鬼。

更新了 WebKit nightly build，結果使用出現一些小問題，其實也不是大地雷。第一個是，可以看到網頁內容但是上面的連結或控制項卻無法用滑鼠點選。關掉 tab 或是 reload 都無效，只有重開 Safari。第二個地雷是，本來可以用的 google spreadsheets，現在進去變成整頁的觀看模式，無法編輯。 第一個是不定時炸彈，但是幾乎很少遇到；第二個問題就算用原廠 Safari 的 WebKit 也無法用 google docs。再來翻翻看有沒有以前的 nightly build history 好了，看看之前的 nightly build version 再不再。

找到兩全其美的辦法了，因為跑 WebKit 的話雖然也是 Safari 的外殼，但是某些 plugin (Input Managers) 無法使用。後來用了類似 WebKit 在 WebKitTools/Scripts/run-safari script 的方法，在環境變數裡面增加了：

export DYLD_FRAMEWORK_PATH=/path/to/WebKit/framwork/...
export WEBKIT_UNSET_DYLD_FRAMEWORK_PATH=YES

其中的 path to WebKit framework 就是去下載 WebKit 後，進去 WebKit.app/Contents/Resources 可以看到 JavaScriptCore.framework、JavaScriptGlue.framework、WebCore.framework、WebKit.framework 那些檔案，把路徑只到這個 Resources 就可以了。 然後接下來只要下指令 open /Applications/Safari.app 一樣是跑 Safari 但是骨子裡卻是新版的 WebKit，同時一些 plugins 也可以繼續使用 :D ps: 目前似乎有的小問題的就是中文輸入選字時候按空白鍵，同時會被當成網頁按空白鍵，也就是下一頁的功能。不過問題還好也影響不太大。

主旨大概就是以後將以jclin.blogspot.com為主。如果您使用的 feed URL 是 feedburner 所提供的，那就不必做任何更新。
最先的原由是，blogspot.com 在 google 整合之前，提供的服務其實也還蠻陽春的，沒有 category or label，layout 方面也是蠻簡單需要看手工打造細節。所以在種種情況之下，在 wordpress.com 有提供 WordPress 的 blog services，還有 category、trackback、還有一些不錯的 theme 可以選。於是就在申請到 invitation 情況下，將主要的作業都搬到 wordpress.com，而使用 gslin’s copyblog 將文章貼回 blogspot 去。
但是後來也是有些問題陸陸續續產生，像是 wordpress.com 速度過慢，最差的遭遇就是上次恆春地震，震壞了幾條海纜，但是 blogspot 和 google 還上得了速度也不錯，wordpress.com 就連不太上。平常使用的話 wordpress.com 速度上感覺也沒有 blogspot.com 來得快。另外一個問題是 spam 過多，雖然 wordpress.com 有 anti comment spam 的 plugin，但是誤判或是需要手動認證的情況還是不少。
再來自從 google 和 blogspot 整合之後，也提供了 label 功能，也有比較進階的 layout 處理方式，感覺實在是好很多。另外也是 copyblog 的問題因為兩邊無法有 category & label 的同步，導致複製的文章過去那邊都是沒有 labels。所以在一段時間的感覺和判斷後，就又想把主要的作業搬回 blogspot 去。這邊就變成使用 copyblog 方式的備份站。
所以最後等有空把 wordpress->blogspot 的 sync script 改回 blogspot->wordpress 的方式，在這之前，這兩邊的文章可能先會出現不同步和分歧的現象。
另外順便廣告一下，還有新的 wordpress.com invitation 一枚，如果有需要者請私下來信。

WebKit 當然就是 Safari 的 kernel，以前使用 WebKit nightly build 的經驗是，偶而看普通的網頁就會當掉，實在受不了所以只能忍耐用 Apple build 的 WebKit 版本。最近因為在玩 Yahoo! Fantasy baseball，常常會去看一些畫面 layout 比較複雜的頁面和 mlb.com，比較驚訝的是最近開 top 一看發現 Safari 的 RPRVT (Private Memory) 竟然高達 697MB，quit 掉 Safari 後就撿回來不少記憶體空間。第一次遇到這種情況，之前最高也是才 300MB 出頭。所以自己的使用習慣是用一段時間的 Safari 就會 quit 然後重新啟動。不過說也奇怪，把 WebCore cache disable 以及自己寫的 Safari Plugin 來設定 NSURLCache 的 memory/disk size 竟然也限制不了 Safari 一直長大的問題。所以這個問題也就無解，並且不了了之。 最近使用 WebKit 的經驗是感覺蠻穩定了，而且 memory leakage 似乎不會那麼嚴重，至少把頁面該關的都關掉後，就回復到蠻基本的 RPRVT 用量。並且至少新的 WebKit 也可以上 docs.google.com，就不用再開 Camino 來應付。缺點大概就是一些 Safari Plugin 不能用，比如說 SafariBlock，就無法阻擋廣告的出現。