懶人總是要碰到需求了，才會有所行動與長進。
剛剛在 #happydesigner 上被 whiteg 抱怨看不到我的中文，所以趕緊真的去把 irssi with big5/utf8 recode 設好。
此時 wiki.newzilla.org 掛點中，因此看不到其 HowToIRC 與 MiniHowtoUTF8，因此只好求教咕狗大神，找到這篇：《irssi UTF-8 Big5 中文轉換與設定》。這篇比 MiniHowToUTF8 寫的清楚簡單，應該是因為部份環境我已經具備的的緣故。以下整理重點：
首先，我們不必辛苦地編輯 ~/.irssi/config，irssi 會依據使用時所下的指令，自動更新 config 檔。所以，~/.irssi/config 的格式，我們不需要研究，記好下列指令的用法即可：
設定 IRC 網路與伺服器
在 IRC 裡，是由許多個 IRC 伺服器 (server) 分散地串在一起，形成 IRC 網路 (network)。一個 IRC 網路裡面，有著許多的頻道 (channel)，只要是在同一個 IRC 網路裡的人，就可以在其中的頻道裡，互相聊天。
因此，我們需要設定我們有哪些 IRC 網路。目前常見的 IRC 頻道，多位於 ircnet 或 freenode 上。因此，我們主要把這兩個 IRC 網路加上去。
/NETWORK ADD -kicks 4 -msgs [...]
敝小站的 trackback 爛很久了，趁著今天放假有空[1]，追了一下程式，發現原來是啟用「Did You Pass Math?」時安裝的 Did you pass math 這個 plug-in 的問題。
簡單講，這個問題出在於，Did you pass math 乃是註冊 comment_post 這個 action，以進行驗證數學的答案的工作。但 trackback/pingback 時，也都會進行 comment_post，因此就被 Did you pass math 擋了下來，讓 trackback/pingback 失敗。
事實上，每一種 spam checking 的 plug-in，應該都會碰到這個問題。解法很簡單，就是偵測是否此次 comment_post 是否為 trackback/pingback，如果是，就直接通過，否則就進行數學答案的驗證。
但是要怎麼偵測此次 comment_post 是否為 trackback/pingback 呢？我不是 wordpress 達人，所以只好偷看一下 Captcha! 的程式碼，原來關鍵在於，也註冊 pingback_post 與 trackback_post 這兩個 actions，於處理此兩個 actions 時記錄於 $this->is_trackback，然後在處理 comment_post 時，若是 [...]
最近對 JeffHung.Blog 動了一些手術，裝了在《今日連結 (2006-09-20)》時看到的 Sandbox 的這套 theme，並予以改造，準備將外觀改回原來的樣子。Sandbox 是一個 semantic-rich 的 wordpress theme，其設計極端注重語意的保留，是一個很好的，設計自己的佈景主題的起點。
對於 blog 的佈景主題，之前換成 beeblebrox 布景時，我就已經有了基本的想法，最主要的就是要能夠讓我得以清晰的擺放程式碼在文章裡。這當然是因為，實在是文筆不好，只好多填些程式碼充數的關係。再又經過一段時間的觀察與沈澱之後，想法多了一些，以下簡單條列於下，算是再次整理：
在版面配置上，如果有邊欄 (side-bar, side-panel, ... what ever) 的話，必須要放在左邊。這是因為程式碼以及我會使用到的語言，方向都是由左至右的 (left-to-right)，而程式碼有時候又有「不可換行」的特性，當有這樣子的狀況發生時，版面就會被撐大，若邊欄放在右邊，在「由左至右」以及「不可換行」兩個因素的限制之下，邊欄就會對本文的閱讀造成影響。
在版面配置上，本文區塊應當要是 fluid，也就是會隨著瀏覽器的大小而變動。理由正是由於上述程式碼有「不可換行」的特性之故。當版面被撐大時，fluid 的版面配置，就不會讓版面受到破壞。
本文字體大小必須是瀏覽器預設的大小，這是預設閱讀起來最舒適的字體大小。Gslin 在這篇《字形的問題》有聊到相關的考量。以前小時候，總喜歡在一個頁面裡，塞下越多的資訊越好。但現在老了，眼力不行了，所以字還是大一點，看起來比較舒適。
非本文的內容，在樣式上，應該盡可能地不喧賓奪主。這可以用較小的字體，或較淺的前景色來達成。尤其是在邊欄放在左邊的情形下，邊欄的內容更是容易讓使用者分心，因此適度的淡化處理，是必須的。
邊欄存在的目的，應該只是提醒使用者，「還有這些東西可以看」，而不是直接把內容呈現給使用者，內含真正內容的邊欄，只會使使用者分心。因此，放在邊欄的 recent-comments 與 recent-trackbacks 等，應該要只放連結與標題就好，毋需列出部份內容。
內頁的 HTML <title> 必須包含文章標題，考量到 tab browsing 時，tab width 通常不寬，因此文章標題應該置於 blog 名稱之前，如：「Sandbox, look.urs, and blogging frequency [JeffHung.Blog]」。
Search form 應該擺在越上面越好。我通常會擺在 header 的右方。Searching 已經超越 surfing 成為現今主流的瀏覽方式，所以應該放在最立即所得，但又不影響主體的地方，就好像 firefox 的 search [...]
昨天晚上又試了一堆布景主題，雖然有幾個還不錯的，但因為我的一些特殊需求需要另外加改一些東西，要弄在這些布景主題上，也挺麻煩的，所以也就只是玩玩而已。也許真要改的話，得先把我加改的那些技法整理一下，找個可以跟正常布景主題程式碼分離的機制，以便可以快樂更換布景主題。
剛剛則是把 blog 的版面調整了一下：
首先，我把本文大小調整至 1em。本來是 90%，但這個奇怪的數字，想必在新細明體這類有襯字[1]下，會顯示地有些破碎，尤其是以斜體字呈現的時候[2]。所以改成 1em，也就是瀏覽器的預設文字大小，通常這會是 12pt，看起來又大又清楚。
再來，也把段落引文 (即以 <blockquote> 包裹起來的段落) 的顏色，改回和正常文字一樣的顏色。既然引文已經以斜體呈現，且段落引文左方還有特殊的邊界標示，實在沒有必要再以特殊顏色呈現。且，原本的顏色太淡了，我老眼昏花，會看不清楚。
有在考慮 one-column 的版面形式，左方 sidebar 感覺上沒什麼存在的意義。事實上，在內頁裡我早已經把左方 sidebar 的內容，縮減到幾乎沒有內容。我認為重點應該是文章的內容，其他索引用的區塊，平常不會用到，應該隱藏起來。可行的方法有，弄成類似 menu bar 的形式[3]、或提供鍊結，另外開一頁展現，或者最近 lukhnos 的那種「隱藏式功能面版」的作法也不錯[4]。
Serif font，新細明體是 Windows 95 以降，預設的中文字型。在沒有辦法以 CSS 分別指定中文與英文字型的現在，中文字型只能交由瀏覽器使用取代規則，自動以系統預設字型，也就是新細明體呈現。 ↩在習慣上，除了前後加引號以外，當我在引用他人的話語、文字時，還會以斜體呈現，以區分個人的發言與引文。 ↩這是我原先的想法，但據說外國人不太喜歡這種表現方式，在搞 CSS 弄半天也還弄不好的情況下，我暫時打消這個念頭。 ↩但是 lukhnos 的面版太容易觸發了，感覺上反而會影響閱讀。如果觸發區域能夠做更小一點，應該會比較好。 ↩
睡到一半口渴睡不著，所以就來裝裝 wordpress plugins，找到一個 PostTeaser 看起來還不錯，所以就裝起來試試看。PostTeaser 是一個 excerpt 的加強版，其簡介是說：
Post Teaser generates a preview or "teaser" of a post for the main, archive and category pages, with a link underneath to go to the full post page. It includes features to generate a word count, image count, and an estimated reading time.
可惜，裝起來後發現，他的 word count 對中文字感冒，連帶地也算不準 excerpt 的長度。如果是中文字比較多的文章，很容易就帶出一大票文字，喪失了使用 [...]
新的 Firefox 1.03 在前幾天推出，我馬上抓了來，連同所有的 extensions 都一併更新，為避免發生什麼怪問題，我採用先移除舊版本，砍掉舊目錄，然後重灌新版本的方式乾淨更新。因為厭惡中文版的「衝」[1]，所以我灌的是英文版。
不過，一直困擾我的 bug 依然未解，然後又加上了一個小 bug，這實在是讓我用起來，感覺很不愉快：
舊 bug：從網址列或 form 的 <input type="text">、<textarea> 裡，使用「複製」常常失敗，一定要先用「拖拉」的方式把文字拉到另外的 editor 後，才能正常 copy 文字、網址。這實在是很莫名其妙，用拖拉的就可以，用 CTRL-C 或選取 menu item 就不行。這問題從約 1.1 版就開始了，到現在 1.3 版還未解決。
新 bug：當已經設定某些網址不列入 block popup，但 popup blocker 依然把這些網址的 popup 阻擋下來，這樣子用起 bloglines 或我自己的網站，非常難用。
希望 1.1 版能好一些。唉。
用「上」還好一些。逃～ ↩
前幾天我在裝「Did You Pass Math?」的時候，其實也一併裝了「footnotes」，不過這個套件可以討論的東西比較多，所以遲至現在才發表。
我一直認為，寫文章用 HTML 實在是用錯了格式。如果可以的話，我希望 blog 裡的文章，是使用 DocBook 格式為其原始格式，然後再經過某種機制，好比說 XSLT，轉換成 HTML 在 blog 裡呈現。理想狀況是，blog 的後台，內建 Web-based WYSIWYG DocBook editor。但這是理想，在現實上，連 stand-alone 的版本都沒有了[1]，遑論 blog 後台的整合。因此，遷就於工具的問題，也只好將就[2]。
是故，退而求其次，我希望至少能夠在 (X)HTML 裡，呈現出我常用的文章樣式。對偏向技術性文章的我來說，最重要的就是 program listing 與 inline code 的呈現了。這個我已經藉由 FCKEditor 可自訂 CSS 的功能達到[3]，若需要更進一步的 syntax coloring 或 line numbering 的花俏功能，我認為直接在 client 端藉由 javascript 達成[4]即可。
而第二常用的文章樣式，則是 footnote，我個人喜歡使用論文 reference 的寫法，於指涉處與註解處，皆使用方刮號 ( [ 和 ] ) 包裹註解編號，並加上超連結在兩者之間跳躍。這篇《升級到 [...]
今天 comment spam 狂襲，砍到手軟。我不喜歡用 Spam Karma 這類東西，誤判機率蠻大的，重點是其介面又不方便把被誤判的 comment 救回來。另外，為了 web accessibility 考量，AuthImage(trac) 這類機制也不考慮。因此，先裝一個 Did You Pass Math? 試試看效果如何。
Did You Pass Math? 是在發表回應時，要求未登入的使用者，必須回答一個簡單的加法數學題。不像使用圖片的 AuthImage 之流，由於題目是以文字方式呈現，故在 text mode browser 上也可以達到 CAPTHA[1] 的效果。使用 lynx[2] 看的效果如右圖。
目前看來，只有一個問題，就是若不小心答錯了，按上一頁回去時，原本填寫的回應內容，都會遺失。這個還要研究一下 Did You Pass Math? 是怎麼做的，看看可不可以補強。在有結果之前，只好先加點文字說明警告[3]。
CAPTHA: an acronym for "completely automated public Turing test to tell computers and humans apart", trademarked by Carnegie [...]
雖然好不容易有了 4 的 pagerank，可是還是比較喜歡 jeffhung.net 這個網址。因此即日起，本站主網址改到 http://www.jeffhung.net/blog/。如無意外，以後就真的不會變了。
原來的 http://www.jeffhung.idv.tw/blog/ 還是可以用，但 /blog/ 底下的東西，全部強制轉址到新址。意思是說，舊有的書籤、鍊結以及 RSS 網址等等，都還可以用，只要您的 browser 或 rss reader/aggregator 支援 redirect 即可。不過，當然還是希望各位對敝小站有興趣的朋友們，改一下網址囉。
我的規劃是，jeffhung.net 以後就是我正式在網路上的家，取「JeffHung 的網路」的意思，就好像本 blog 名為「JeffHung.Blog」，乃「JeffHung 的 blog」之意一樣。至於工作上的東西，則是留在 jeffhung.idv.tw 裡，因為這是不方便與網路上的朋友分享的東西。另外，窈窕淑女 BBS 站 仍然會繼續下去，雖然我好久沒整頓她了，但基本上還是會活著就是了。
由於內建了 WYSIWYG 的 HTML editor，Wordpress 2.0.* 的 posting bookmarklet 也可以直接以 WYSIWYG 的形式編輯文章了 (之前的 WYSIWYG 靠的是 plug-in，posting bookmarklet 沒有 plug 到)。
但是，官方的 posting bookmarklet 會取代掉目前的網頁，這樣在編輯文章時很麻煩，沒辦法回來參照原文編寫。所以只好下手改改這個 posting bookmarklet。基本上關鍵在這裡 (其中，Q 是目前被選取的文字，如果有的話)：
location.href
= 'http://www.jeffhung.idv.tw/blog/wp-admin/post.php?text='
+ encodeURIComponent(Q)
+ '&popupurl='
+ encodeURIComponent(location.href)
+ '&popuptitle='
+ encodeURIComponent(document.title);
因為是更改 location.href 來啟動 blog 編輯，所以目前頁面會被替換掉，換成 window.open() 開新視窗，應該就可以了。所以我把這段改成這樣：
window.open(
'http://www.jeffhung.idv.tw/blog/wp-admin/post.php?text='
+ encodeURIComponent(Q)
+ '&popupurl='
+ encodeURIComponent(location.href)
+ '&popuptitle='
+ encodeURIComponent(document.title)
);
卻沒想到，雖然新的 blog 編輯視窗有正確出現了，但原來的頁面卻被切換成這樣：
[object Window]
研究了網路上其他的 bookmarklet 的寫法，才恍然大悟，如果 bookmarklet 的最後一個 statement 有「值」的話，browser (firefox) 就會把這個值顯示在頁面上。所以在最後加一個 [...]
