Ada Hsu 的胡思亂想

Chrome 擴充功能 - Plus Plurk 介紹

2011-08-12T17:55:00.036+08:00

基本上這是一個協助格揆我將發佈在 Google Plus 上的訊息同步到 Plurk 的 Google 瀏覽器擴充套件 / 功能。原本只是格揆個人單純在同步文字訊息使用，但是經過一陣加油添醋式的亂改後覺得也許可以開放給 Google Plus 及 Plurk 的重度使用者試看看，於是就把它上到 Chrome 線上應用程式商店了。

開發源由歷程

當不小心偷渡進 Google Plus 後，格揆一度因為專心在 Google Plus 上打混而幾乎放棄了在 Plurk 上的活動，此作為連帶使得卡馬值在短短幾天就從 98.x 掉到 97.y，在發現這種情形時原本一度考慮要使用凍結卡馬的方式來欺瞞自己。但此刻一個由 Google Plus 同步訊息到 Facebook 的 Publish Sync 擴充功能上線到線上應用程式商店，經過簡單試用後就有了『不然我也來寫一個從 Google Plus 將訊息同步發送到 Plurk 的擴充功能』的念頭並真正的開始研究 Plurk API ，隔了幾天後突然到 Chrome 線上應用程式商店付了 US$5 的入場券，然後還拗了他踢幫忙拉了一個 ICON，最後還賺了一場由火焰銘王提供的美國隊長電影，終於在 08/02 開始了募集測試人員的測試流程，然後就是因為一時恍神而在 08/11 莫名其妙的正式把它給弄上 Chrome 線上應用程式商店。

核心思想

和 Publish Sync 的規劃不同，這個擴充套件是基於使用者以 Google Plus 為唯一發言人，並想將相關資訊散佈到 Plurk 上的散播模式而開發。換句話說如果您是希望以 Plurk 為主要發言來源，但想將訊息同步到 Google Plus 上訊息傳播模式的話，那這個套件就不會適合您的需要。在安裝前請先理解此一核心思想所造成的設計上的差異。

功能特色

本擴充套件 / 功能的主要特色如下：

直接對 Plurk 發送訊息：所有的訊息都直接對 Plurk 進行操作，訊息分享沒有延遲
訊息分享限制：本擴充功能支援『僅限朋友閱讀』之私噗模式，也能設限回噗對象的範圍
訊息分享格式：依訊息內容的差異，提供 5 種轉噗到 Plurk 上的訊息格式
訊息長度預覽：Plurk 屬微網誌系統，本套件可以預判訊息長度，提前避免傳送失敗的情形
多段訊息轉噗：擔心個人感想太長無法轉送到 Plurk 嗎？沒關係，只要您分段得宜，本套件會自動將各段轉成回噗送上 Plurk

安裝與授權

本套件為 Google 瀏覽器 Chrome 所屬的擴充套件，如果您尚未使用 Google 瀏覽器可以在 Google 瀏覽器產品頁面下載安裝。另外提醒的是 Google 瀏覽器安裝並不需要系統管理者權限，只要作業系統為 Windows XP 以上的使用者都能直接下載安裝。

安裝 Plus Plurk

請使用您已安裝的 Google 瀏覽器連接到 Plus Plurk - Chrome 線上應用程式商店上並按下『加到 Chrome』按鈕即可，如附圖：

權限要求

本擴充功能僅存取以下三個網站資料：

www.plurk.com: 將資料傳輸給 Plurk
plus.google.com: 擷取在 Google Plus 上預定發佈的訊息、在 Google Plus 上啟用本擴充套件
www.googleapis.com: 將預定分享到 Plurk 的網址預先進行網址為 http://goo.gl/xxxxx 之用

重新載入 Google Plus

完成安裝後套件會自動將相關程式載入 Google Plus 頁面中，不過您也可以重新載入 Google Plus 頁面，確保相關程式正確的嵌入 Google Plus。只要相關程式已正確嵌入，那麼在輸入訊息時會在分享鈕右側看到多出一個 Plurk Share 圖示。但是因為目前還沒有取得 Plurk 服務授權，所以此刻暫時無法點選。如附圖：

取得 Plurk 服務授權

套件安裝後會自動開啟 Plus Plurk 選項設定頁面以利噗友進行 Plurk 服務授權，另外您也可以按下 Chrome 右上角的 Plus Plurk 圖示，它會直接開啟 Plus Plurk 選項設定頁面，如附圖：

點選『進行授權』鈕後會開啟 Plurk 服務授權存取頁面，不同意的話是沒辦法發送訊息給 Plurk 的喲~~

授權完成後會自動關閉該頁面回到 Plus Plurk 選項設定頁面，其中『授權狀態』欄位會變更為『已完成授權』，同時『授權人』欄位會取得 Plurk 的使用者名稱資訊，如附圖。特別注意的是一旦更換電腦，這個授權動作就要執行一次！

如果授權後發現授權人的名字不是您的名字請先登出 Plurk 後再重新進行授權；如果這是一台公用電話的話請在使用完畢並登出 Google Plus 後一併記得登出 Plurk 及清除 Plus Plurk 授權設定（請注意：Plus Plurk 並非透過 Plurk 帳號及密碼登入 Plurk ，故光是登出 Plurk 並不會取消 Plus Plurk 存取 Plurk 的權限），清除授權設定後則『受權狀態』欄位會恢復為『尚未授權』，如附圖。

一般使用

Plus Plurk 只要完成 Plurk 服務存取授權後，就可以將訊息同步分享到 Plurk 上。不管是心情碎碎念、文章心享、心得感言、照片紀念、還是影音記錄等等等，只要沒有超過 Plurk 內文長度限制，Plus Plurk 都可以幫你噗到 Plurk 上。以下都是將 Google Plus 上輸入的資訊與 Plurk 實際獲得的噗文結果合併後的圖例。

心情碎碎念 / 純文字訊息

心得分享

純文章分享

與『心得分享』最大的差異就是... 沒有心得... (被毆)

內嵌文章分享

0.3.2.2 調整功能

如果是 Plurk 支援的文章連結，則 Plurk 會以部落格區塊轉貼方式呈現，如附圖。

目前 Plurk 支援的 oEmbed 網站列表如下（請參考 Plurk Labs (Chinese)）：

YouTube
Vimeo
Slideshare
Wordpress.com
PIXNET痞客邦部落格、相片/相簿
未來事件交易所
ted.com
itunes.apple.com
Flickr
scribd
Xuite 隨意窩部落格、相片/相簿
蘋果日報新聞

圖片分享

噗文管理

Plus Plurk 一開始預設的 Plurk 訊息是可在河道上自由被檢視及回噗的，但是人生總有些訊息並不想如此大方的公開或是讓人家插花回覆的，有一些開關可以應付這方面的需求。

檢視限制

可以選擇是公開給所有人檢視或僅朋友能檢視。

回噗限制

可以限制是否同意任何人皆可回噗，僅限朋友可以回噗、或完全不能回噗！

同步限制

0.3.1.0 新增功能

應該有不少噗友是利用 Plurk 提供的 Facebook 同步功能將訊息同步到 Facebook 上的，而 Plurk 其實也提供了如何不同步到 Facebook 的方式。Plus Plurk 自 0.3.1.0 版起也提供了指定是否開放讓 Plurk 自動同步臉畫的選項開關，如附圖。

訊息格式管理

和 Twitter 不同（應該吧），Plurk 本身並不是純文字型態的微網誌系統，因此 Plus Plurk 在分享訊息到 Plurk 時依訊息種類提供不同的訊息分享格式。這些設定可以在 Plus Plurk 的選項設定頁中進行修改，修改完後記得要『儲存』後相關設定才會生效。至於那些變數所對應的資料項目可透過點選符號查閱之。

戳記：在 Facebook 上我們可以看到每一筆訊息的來源為何，但是 Plurk 上卻沒有這方面的設定，所以格揆很堅持的希望在 Plurk 上能一眼的看出來這筆噗文的來源為何。它的預設值為『[fr. G+]』，但因為會佔用到噗浪內文的空間所以格揆已自行改成『[G+]』，您也可以直接設為空白。
訊息 / 純文字分享：如果某筆訊息沒有包含文章連結、影像連結、或圖片連結時，視為單純的訊息分享。此時能使用的變數只有代表訊息的 ${MESSAGE} 及戳記 ${STAMP} 兩種。
心得分享：為預設的分享模式，一份完整的心得分享中會包含個人的心得、感想（${MESSAGE}）、文章連結（${LINK}）、文章標題（${TITLE}）、以及文章圖片（${PICTURE}）。
內嵌文章分享：針對 Plurk 能自動讀取特定網站資訊所採取的對應格式，只需文章連結（${LINK}）即可由 Plurk 自動帶出連結網址標題及第一張圖片。
文章分享：少了個人心得、感想（${MESSAGE}）的訊息分享屬之。
影片分享：目前以連結 ${LINK} 為 Youtube 或 Vimeo 的網址時視為影片分享，Google Plus 在捉取影片資訊時會提供影像連結（${LINK}）及影像擷圖（${PICTURE}）兩種資訊，由於 Plurk 也會自行捉取影像內的資訊，故通常不會使用到影像擷圖（${PICTURE}）這個變數。
圖片分享：當訊息中不含文章連結（${LINK}）及文章標題（${TITLE}）時即屬圖片分享。您可自行決定圖片要放前面還是放後面。

另外『${DESCRIPTION}』這個變數主要是指一篇文章或影片的內容描述，但因為它本身經常超出 Plurk 內文的上限，所以不建議各位使用。

0.3.3.2 新增功能

自 2011-08-23 起 Plurk 支援訊息斷行顯示，因此在格式設定上也新增了斷行的符號『|』，如上圖中的『訊息分享』即使用了這個斷行符號，斷行的輸入範例如下圖：

需要特別注意的是 Plurk 官方允許的斷行行數是 4 行，如果在格式設定中使用了斷行符號『|』，那麼實際能輸入的訊息行數就只剩下 3 行，下圖即為超過上限行數時的檢查結果，出現第 5 行的原因就是因為 | 多產生了一行戳記（${STAMP}）列所導致。。

多段式噗文

因應 Plurk 單則訊息 140 個字的限制，Plus Plurk 支援將訊息分成數段噗在同一筆噗浪主文下成為回噗。但這並不是自動分段，Plus Plurk 的分段依據是透過使用者預先安排的。

Plus Plurk 在處理 ${MESSAGE} 時會針對連續兩個 ENTER 鍵進行訊息切割，訊息切割之後再依序將訊息內容送往 Plurk 河道，這個發送的時間間隔是每秒一筆，以下介紹的兩種應用方式，它們之間的差異只在於有沒有先空個兩行再輸入個人的心得或意見而以。

訊息長度檢測

有時候在下筆如神助、文思如泉湧時的摸門特是很難有心思力氣去一個個數每一段落各有多少字。每次數的結果都不一樣也就罷了，就怕是還沒數完前就讓原本澎湃的思緒化為枯竭的溝流，這樣怎麼有資格當文青呢？

沒關係，Plus Plurk 可以透過某種不明確、不科學、沒有保證的計算公式提前告知這一篇文章中最長的那一段總共有幾個字，如附圖。特別注意的是這裡的第一段指的是文章的連結、標題、文章內附圖的連結等等的綜合計算結果，並不是心得部份的文字字數。

另外這個燈泡的顏色會隨著文字長度是否超過 140 字上限或是 Plurk 斷行上限而變色，綠色（通常）表示可安心噗文，紅色（幾乎確定）表示有某一段訊息過長或行數過多請予修正。特別注意的是這個檢查結果並不會阻止『分享』鈕的功能，而 Plus Plurk 在收到 Plurk 拒絕噗文的回覆時則會停止後續訊息的發送以便有辦法一行行手動將訊息補進河道內。

常見問題與說明

問：為什麼在 Google Plus 上明明只是換行，但在 Plurk 上卻成多段式噗文呢？
這通常是發生在訊息內容是從剪貼簿貼到 Google Plus，Google Plus 雖然顯示上看起來像換行，但實際上捉出來的訊息卻是每行一段，故轉送到 Plurk 時就變成多段式噗文了。

成果示範

在本文剛撰寫時格揆提過當時的卡馬值一度落到 97.y ，經過本套件的協助後在三週內竟然已提升到 99.81，您看看，這套件是不是真的很有用？~~廢話！老是把 Google+ 上的資料倒進 Plurk 當然會提高卡馬值啊，而且三週才提升 2 似乎有點...~~

多語系支援

目前並未支援其他語系，非常歡迎有意願者協助翻譯！

感謝

感謝以下網友介紹本擴充套件：

就是教不落：Google Chrome擴充套件【Plus Plurk】同步Google+訊息到噗浪，支援圖片及影片連結
于老師教室討論版：好用的Google Chrome同步擴充---Plus Plurk
WEBOK部落格：省時省力的社群與微網誌訊息擴散行銷技巧

改版記錄

一個恐龍法條 + 一個愛現的官僚 = 什麼？

2011-07-25T15:23:00.001+08:00

基本上這原本是在 Google+ 上針對台北市政府法規會與 Google 對 Android Market 7 日鑑賞期事件所留的一段心得，不過因為近日又多了一點心得，加上北市府額外奉送的兩週延議期也快到了，所以趁機把它搬到部落格中作為歷史遺跡，順便為這個荒廢多時的部落格灌點水... :p

整個故事的發展演進請直接參閱『Google Android Market、Apple App Store 7日鑑賞期事件懶人包』及『北市府裁罰事件，Google：法律解讀有疑慮，app 繼續下架』兩篇文章說明而不再贅述，以下即為個人的看法：

台灣消費者從此與世界豐富的應用程式無緣
和中國一樣出現一大堆山寨版應用程式在電信公司的市集上騙錢
因為台灣看不到付費軟體，所以也不會有人幫作者翻譯使用者界面為正體中文
iPhone/iPad 使用者也不用太高興，別以為世界各地的應用軟體開發者就會認同或支持台灣 Apple Store 的特別條款；也不要天真的以為 iOS 軟體開發者都有那種力氣來面對、統計、或處理台灣的退費條款_{（狀態可能有所改變，容後述）}
以目前的狀況來看，恐怕也讓某些原本想要寫 Android App 的開發人員陷入躊躇不前的困擾中，iOS 的開發人員可能就稍好一點，至少可以樂觀的相信被退款的機率應該不會太高。但總體來看似乎並不利於行動應用軟體業的發展
免費軟體的使用一併受到影響：這是近日的感想，應該也會是 iPhone 軟體開發者比 Android 軟體開發者有利的地方

基本上到了 07/15 後，Apple 正式增列台灣專屬條款『您得自產品收受之日起七日內，取消對產品之購買。在您通知iTunes您已刪除產品所有備份之前提下，iTunes將會退還您已支付之價款。自您取消購買時起,您不再被授權繼續使用該產品。此項權利不可拋棄。』，但是軟體內 (In-App) 購買、訂閱部份目前看來是無法退費的。這個差異可能會轉移軟體開發者對於軟體功能的規劃：『表面上是免費軟體，但是多數功能都要另行在軟體內付費啟用』，而且此作法某種程度下還能對抗盜版軟體。

有趣的地方就在這兒，在 iTunes / Apple Store 下雖然付費軟體有七日退費條款，但是開發者可以讓軟體免費下載，之後再透過 In-App 方式付費購買擴充功能，這些付費功能無法退費，所以 iOS 開發人員其實也不見得需要特地處理台灣地區軟體的退費事宜；但與過去比較起來消費者可能會發現連寫信退費的權利恐怕也沒了。

Android Market 也提供所謂的 In-App 付費功能，也有許多軟體開始透過此付費模式提供購買特殊裝備或啟用特別功能（個人覺得這些也算是騙子軟體），不過因北市府法規會介入的關係導致 Market 整個付費功能被 Google 關閉後，自此每次在開啟這類具 In-App 付費功能的軟體時就會看到一個很刺眼的訊息：『Can't make purchases』且一而再、再而三的提醒台灣的使用者因為一個愛現的官僚所造成無法付費購買軟體的窘境。

距上次北市府美其名對 Google 釋出善意再給兩週寬限期的時間又快到了，不知道這個號稱天龍國的地方政府有沒有任何方案足以應對 Google 不接受七日退費期費要求的因應作為？

還要用 Google 有挾消費者以令天子之嫌 那招開罰嗎？

其他討論：

小歪碎碎念: 2011-06-27 偉哉台北市政府幹掉了Google台灣的Android Market付費區
INET6 - 對Google關掉台灣Android Market付費App下載的觀察
連 Market 都有這種東西 - 抗議臺北市政府干預Android市場

本格文章詞頻分析

2011-03-23T16:29:00.000+08:00

看了 timdream 的文字雲工具後，也把這個部落格的資料給餵進去看看，然後就出現了以下這個分析圖...

簡單的說，格揆我對『可以』這個詞兒的使用頻率實在太高啦~~ 同時這也更加明確的確認出這個部落格確如其名的只是一份胡思亂想鬼扯蛋的雜記而以...

智慧型手機綁約方案選擇

2011-02-19T23:45:00.028+08:00

電信業者透過一定程度的補貼手段以爭取用戶的方式其來由自，但早期功能型手機世代時其實並不是那麼划算而在這方面沒有太多的困擾。但是直到 iPhone 3G/3Gs 登陸台灣後，因為合約中綁定了無線數據上網的部份，所以開創了鄉民們針對電信業者智慧型手機綁約方案的研究與心得整理。這一篇也是網海中注定會浮沉的一個片段，但在它還尚未沉沒前應該還是有一絲絲的參考價值... 吧！

同手機、同上網資費但不同話務資費比較

格揆我曾在噗浪/Plurk 上隨手寫了一段綁約資費方案的選擇條件，這篇文章算是進一步對這些條件加以說明。先來看看當時留的選擇條件如下：

網路使用習慣：隨時隨時要取得朋友的各種資訊、只需要行事曆/天氣/郵件通知、還是完全不使用
各資費下的總支出金額：並不是低資費就一定會繳的少
該資費下的免費通話量：有些資費方案是能月租折抵通信費用，有些甚至是直接贈送固定金額的通信費用
個人的通話量：把自己過去 6 個月的平均通話量套到前述條件內，看看那一個方案的額外花費最少。

前兩個條件很容易數據化，下表即為假設在中華電信辦理 iPhone 4 32G 手機，選擇 mPro 950 上網吃到飽方案時（即前述第一條件）分別選擇大家講-589及大家講-289（前述第二條件）時不同資費的支出試算。這個試算表中把話務月租費分成兩段的原因在於某些優惠方案可以在滿足一定月份（通常是 12 個月）後調降話務月租費，不過此表中的這兩個 iPhone4 超值方案都無此選項。

至於數據上網月租費方面也有分吃到飽和限量飲食的選擇，由於 mPro 950 是屬於一個價碼吃到飽的模式，所以上、下限都是 NT$950 元打八折的 NT$760 元。

仔細看看這份試算表可以發現：雖然表面上看來『大家講-289』方案的每月支出只要 NT$1,049 元，但若加上手機費用及預繳折扣後反而比『大家講-589』方案的總支出要再貴上 NT$500 元。這就是為什麼網路上及格揆我所一再強調的 並不是低資費就一定會繳的少 的原因啊！

這裡簡單說明一下各項數值的來源吧，然後就可以看看其他幾種方案的比較。當然如果覺得這些數據有什麼疑問之處歡迎一起討論。

話務月租費總支出：就兩年下來總共要繳多少通話費
數據上網月租費總支出：一樣是指兩年下來總共要繳多少上網費，不過因為某些上網方案並不是吃到飽的，所以這裡分成上、下限兩個數據。注意：通常這個上限值不應該發生才對。
購機準備金：這是指要領到手機所必須先付出的費用，通常是手機優惠價加上購機預繳費用。若電信公司有推出免預繳方案（通常是 VIP 或 NP）時，購機準備金就會降低。不過看了幾個方案後發現電信公司不管什麼方案要準備的預算都一樣... XD
綁約期內月支出：這是指帳面上每個月要繳給電信公司的費用，但是目前這個試算表沒辦法精確區分出話務費及上網費都會變動的情形。例如，如果話費為先 589 後 289 而上網費則是先 450 後 950 時，這個試算表只會捉出下限為 289 + 450 = 739 的數字而不是實際的 589 + 450 = 1039 這個數值。
綁約期內總支出：話務月租費總支出 + 上網費用總支出 - 預繳贈送金額。中華電信以前的方案是折抵預繳金額的 20%，現在的方案只剩下 10% 而以。
賣出價格：若綁約所取得的手機不為自用的話，可以透過售出方式減少費用支出
另購新機價格：若把綁約手機賣了又需要另一隻手機的話，就得另外花一筆費用。6. 和 7. 之前的價差即俗稱為洗機所得，後續會談到
洗機後最低總支出：洗機的目的是要壓低約期內的總支出，所以此處就只考慮最低總支出費用

同資費但不同手機間比較

上一段內容是以同手機但不同資費作為比較，這段則改成同資費但手機分別選擇 iPhone 4 32G 及 HTC Desire HD 時各自會有什麼不同？

基本上 HTC Desire HD 的空機價格本來就比 iPhone 4 32G 要便宜 NT$8,000 上下，所以單單從總支出來看的話選擇 HTC Desire HD 一如預期的必然會比選擇 iPhone 4 32G 的花費要少。但是不對啊？為什麼 HTC Desire HD 的總支出只比 iPhone 4 32G 便宜約 NT$1,000 而以呢？不是說價差約 NT$8,000 嗎？於是有人想到了是不是可以辦 iPhone 4 32G 後，把 iPhone 4 稍微降個價、打個折賣了再到通訊行買隻 HTC Desire HD 來貼補一下月租費的支出呢？

是啊，這方式就是大家常常聽到的洗機。又因為有電信公司是否受制於各家手機制造商的微妙關係，iPhone 系列手機通常會享有電信公司較高的貼補金額，這也是為什麼網路上都建議洗 iPhone 的原因。

下表就是以中華電信『大家講-589』為基礎，在分別選擇 iPhone 4 32G 及 HTC Desire HD 時的各項支出數據。其中 iPhone 4 32G 空機價依 PChome 報價為 NT$32,900 元，但為了要能脫手以免造成庫存壓力（什麼跟什麼啊）所以此處料敵從嚴的把售價訂在 NT$25,000。當然兩者間的差距不算小，能夠賣的愈高價則所能貼補的月租費就愈多，總支出也會跟著下調，這部份就要看個人機運了。如何賣掉 iPhone 的方式很多，不少人是透過網路拍賣進行競價，但是也有部份的人因為懶惰或其他原因而選擇直接把手機賣給通訊行吧？至於 HTC Desire HD 也依 PChome 報價的話是 NT$20,900 元，不過通訊行的價格應該不會這麼硬才對！

其他不同方案的比較

這篇是以智慧型手機綁約為前提所寫的介紹文，那麼有沒有單純針對通話為唯一要件的方案建議呢？

答案可能讓人失望，格揆我會建議 直接用空機價格購買功能型手機，然後向電信商辦理通信費用補貼 即可。

以下繼續對各種不同基礎所進行的方案比較，但各比較表僅僅只能作為參考、計算示範之用。任何方案的付費細節請參閱各家電信公司官網或聯絡其客服以取得最新、最正確的資訊。

是否一定要選擇 mPro 950 吃到飽方案實際取決於每個月的上網傳輸量是否僅少量甚至是不超過方案上限值。不過可以確定的是如果有 7 個月以上因傳輸爆量達 mPro 450 收費上限 NT$1,200 的話，那麼選用 mPro 450 的費用支出就會開始超過 mPro 950 了。

如果比較一下各家電信業者的資費方案，可以做為是否 NP 的決策。不過各家對 NP 的補貼倒是不一定能享受到就是了！另外這份表中的遠傳資費不一定正確，因為格揆不太瞭解遠傳資費的解讀方式，有可能因為認知錯誤給了一個不正確的數值。

結論

其實整個評估作業最簡單的方式不過就是計算月租費及手機費用的總支出，少數電信公司的預繳費用會有更多的折扣，那就再扣除這些多的折扣就是最終取得手機的實際支出。聰明的你應該馬上能計算出自己所需的優惠方案了吧？

追加報導 - 《中華電信 - 平板＋智慧新機成對帶著走！「天生一對」方案》

個人看法：

個人覺得綁約三年的各種合約都儘量少碰，尤其像手機這種半年就一款旗艦機的情形下更沒有再堅持一年的必要性
mPro 450 每月有 500MB 的額度，和 mPro 750 相比上限值雖然多 NT$100，但是一般以 WI-FI 環境為主的情形下月租費卻可以少掉 NT$300，個人認為是買空機情形下比較划算的選擇
個人認為如果真有行動平板電腦的需求，透過洗手機（目前效果差很多）的方式可能比較划算
對了，除非辦了兩組上網門號，不然 Flyer 要上 3G 時要拔 SIM 卡進行交換... XD

次世代主機的體感創意落差

2011-01-28T15:22:00.000+08:00

我是看了『老任第三季營收掉了46個百分比，狂賣缺貨的日子已是往日榮光？』這篇文章時突然覺得老任營收會下調營收預測似乎是必然的，畢竟這是一台老主機，加上 XBox 360 Kinect 的出現明顯搶了 Wii 的風采。

以下是格揆我對三大主機在體感創意方面的自我主張，大家可以參考參考：

任天堂 Wii Remote/Remote Plus：這玩意兒無疑是對體感遊戲的可能性具有重大貢獻，但是年代已久早顯疲乏；不過在某些需要精準控制的遊戲需求上仍有其重要性存在。
微軟 Kinect：可視為自 Wii Remote 發表以來的重大演進，不光是少了遊戲過程中額外控制器的需求，還能被應用在各種肉人體動作補捉上。
索尼電腦娛樂 PS Move：雖然看來有一些和 Wii Remote/Remote Plus 不同的運用方式，但原始創意來源怎麼看都覺得是抄自任天堂的，所以目前看不出有何氣勢似乎也是很合情合理的。

所以，格揆我不小心在過年前從電腦家訂了一組 XBOX 360 + Kinect 同綑包要回家孝敬爹娘了... XD

如何在 Shell Script 中捉取 MySQL 資料庫中的指定記錄值

2011-01-19T17:52:00.004+08:00

很久沒寫 Blog 了，也許是因為撞牆期吧？

總之，來寫個跟 Shell Script 及 MySQL 有關的東西吧：如何在 Shell Script 中直接取得 MySQL 資料庫中某記錄的值！

需求起因

事情的發展是這樣的：為了確保系統發出的 EMAIL 能有效的送達用戶手上，所以懶人如格揆我就很順手的把 /var/log/maillog 中的郵件寄送記錄給解出來了，反正不需要我每天動手做的任何方式都是最佳的方式。但是，代誌毋係憨人想ㄟ哈呢甘單，沒多久就有人寄信來希望能加上信件主旨，於是格揆很快的又回到每日人工查資料的機械生活中，這完全是忤逆懶人天性，違乎常理的發展啊。

就因為『懶散要超越懶散』，格揆我其實一直希望能把這動作併入 Shell 中自動補完，終於在今天找出了正確的解法，先記錄一下以免腦殘之後忘了該怎麼辦！

編碼問題

在讀取資料庫中的資訊前有一點很重要：系統編碼！

mysql> status
--------------
mysql  Ver 14.12 Distrib 5.0.77, for redhat-linux-gnu (i686) using readline 5.1

Connection id:          2468601
Current database:       *** 不要問 ***
Current user:           *** 很恐怖 ***
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         5.0.86-community-log MySQL Community Edition (GPL)
Protocol version:       10
Connection:             *** 您知道的 ***
Server characterset:    latin1
Db     characterset:    utf8
Client characterset:    latin1
Conn.  characterset:    latin1
TCP port:               3306
Uptime:                 428 days 21 hours 44 min 57 sec

Threads: 8  Questions: 115577998  Slow queries: 8  Opens: 81015  Flush tables: 1  Open tables: 64  Queries per second avg: 3.119
--------------

如果登入 MySQL 時看到了像是上圖中顯示了不同的編碼狀態，那麼任何 select 到的中文字都會變成亂碼！這問題不難處理，在使用 MySQL Command line Tools 加上 --default-character-set=encodename 即可，如上例即應改由以下方式登入 MySQL：

[ada@myhost ~]$ mysql --default-character-set=utf8

加上了預設編碼設定後後，再到 mysql 命令列工具中下達 status 指令就會看到編碼設定已經被改過了，如下：

Server characterset:    latin1
Db     characterset:    utf8
Client characterset:    utf8
Conn.  characterset:    utf8

Select 取值方式

之前在對 Oracle 進行操作時，它有提供如何在 Shell 中去讀取資料庫內容的作法，這裡用讀取資料庫系統時間作為例子：

[ada@ora ~]$ NOW=$(sqlplus -s << END
> set heading off
> set feedback off
> select sysdate from dual;
> exit;
> END)
[ada@ora ~]$ echo $NOW
2011-01-19 17:02:48

但如果想要在 MySQL 中如法泡製的話，輸出結果顯然需要額外再加工才行，如下所示：

[ada@myhost MYSQL]$ NOW=$(mysql --default-character-set=utf8 --silent -E <<END
select now();
END)
[ada@myhost MYSQL]# echo $NOW
*************************** 1. row *************************** now(): 2011-01-19 16:40:25

靠杯，為什麼兩台的時間差這麼多？

還好 MySQL 另外提供一個方式可以讓我們只看到實際輸出資料而沒有欄位名稱什麼的，如下例：

[ada@myhost MYSQL]$ NOW=$(echo "select now()" | mysql --default-character-set=utf8 --silent)
[ada@myhost MYSQL]# echo $NOW
2011-01-19 17:07:56

好啦，想要在 Shell 中去讀取 MySQL 中的某個值就是這麼簡單。如果要撈的是多筆、多欄位的資料呢？沒有問題，系統會用空白串接所有擷取出的欄位值，這樣會比較難處理，但它確確實實還是能夠加以操作。

[ada@myhost MYSQL]# LIST=$(echo "select status, time_start, creator from epaper" | mysql --silent)
[ada@myhost MYSQL]$ echo $LIST
0 2012-08-03 00:00:00 admin 1 2010-09-01 00:00:00 admin 0 2011-09-08 00:00:00 admin 0 2011-09-03 00:00:00 admin 1 2010-10-02 00:00:00 admin 1 2010-10-05 00:00:00 admin 1 2010-10-05 00:00:00 admin 1 2010-10-05 00:00:00 admin 0 2011-11-11 00:00:00 admin 1 2010-11-03 00:00:00 admin 0 2011-11-05 00:00:00 admin 0 2011-11-07 00:00:00 admin 1 2010-11-05 00:00:00 admin 1 2010-12-01 00:00:00 admin 1 2010-12-02 00:00:00 admin 0 2012-12-06 00:00:00 admin 1 2011-01-15 00:00:00 admin

其實也可以改成以下這樣啦，只不過這樣會多出欄位標題出來，需要自行濾除...

[ada@myhost MYSQL]$ mysql --default-character-set=utf8 --silent -e 'select status, time_start, creator from epaper'
status  time_start      creator
0       2012-08-03 00:00:00     admin
1       2010-09-01 00:00:00     admin
0       2011-09-08 00:00:00     admin
0       2011-09-03 00:00:00     admin
1       2010-10-02 00:00:00     admin
1       2010-10-05 00:00:00     admin
1       2010-10-05 00:00:00     admin
1       2010-10-05 00:00:00     admin
0       2011-11-11 00:00:00     admin
1       2010-11-03 00:00:00     admin
0       2011-11-05 00:00:00     admin
0       2011-11-07 00:00:00     admin
1       2010-11-05 00:00:00     admin
1       2010-12-01 00:00:00     admin
1       2010-12-02 00:00:00     admin
0       2012-12-06 00:00:00     admin
1       2011-01-15 00:00:00     admin

[ada@myhost MYSQL]$

五都選舉馬後砲

2010-11-28T23:03:00.004+08:00

前言

台灣首場五都首長選舉已於 11/27 晚上拍板定案，就上榜率而言藍軍以過半的 60% 大勝綠營的 40%，但以得票率來看的話則是綠營以近 5 成的 49.87% 大勝藍營的 44.54% 共 40 餘萬票。於是照慣例，格揆我一定要放個馬後砲留點紀念，反正格揆我也只會放放馬後砲以免惹上意圖使人不當選（沒想到它還是目前的 Google Suggestion 呢）的麻煩。

台北市

就個人情感上對台北市是希望蘇貞昌當選的，不過個人一向對天龍人的民主養成教育沒啥信心，選舉結果也如預期般由在新生高及花博等工程中浪費人民血汗錢的現任市長連任。對司法一向沒啥信心的格揆我也只能說這些爭議案件都將不會有什麼結果了。

另外蘇貞昌在整個竸選期間曾親到台北市各處探查民情，但似乎找不到類似個 Issue Tracker 的問題追踪系統並公開給大眾監管執政者是否已解決問題？個人倒是挺建議蘇這邊把相關資料整理後移交給民進黨台北市議會黨部（或是移交給 TBA 也行？），不只可以讓議員們持續追踪這些問題，搞不好四年後還能用來翻舊帳呢！

對了，每次看到好冰冰市長的台北起飛、Fly High 選舉手勢時總會莫名其妙的想到國家地理頻道中的空中浩劫節目，為什麼？因為空難事件絕大多數都發生在起降時刻呀~~

新北市

老實說在過去民進黨多任縣長的先例下，本來並不覺得新北市是一個藍色為主的政治環境，但從此次的選舉結果看來新北市大概就此被劃入藍色版圖內了吧？

至於對這兩位候選人而言，個人沒有太多意見。對小英而言其實本來就不太贊成她出來竸選，至於老是批評小英是選假的的朱市長個人則覺得實在過於小鼻子小眼睛就是了。讓一個現任的新北市長去選總統搞不好可以讓任內已規劃的所有建設一次到位，對新北市民搞不好受益更多呢！再說為什麼每次都只能由選台北市長的人去競選總統呢？這明顯是對其他縣市的一種歧視嘛...

不過，其實北二都失守也不一定要那麼悲觀到又要勞駕精神科醫師 Billy Pan 大叔再辦一次療傷網聚啦，阿Ｑ點想，也許這是因為北二都的民眾們比較希望兩位市長候選人能專心準備 2012 總統大選也說不定呢～

台中市

個人是覺得台中市最近幾年實在是沒啥發展，不過反正又不住那邊所以不需要太過在意。只是這次再由胡志強當選讓人好奇台中市民過去九年來對胡市長的臉都不覺得膩嗎？

說到胡志強他這次猛推不少競選廣告，吹牛被捉包的就不管了，反到是在大台中大未來所提的 與香港競爭、追趕新加玻 （這樣看起來新加破贏香港）口號應該先問問胡市長把台北市放那邊去了吧？

另外胡市長還有一個在競選末期某幾天內曾強力放送的廣告中不知為何總覺得他口齒不清，不知原因是不是我耳朵生繭的關係？

台南市

基本上我對這兩位候選人都不熟悉，但比較想說的是台南縣蘇縣長接受初選結果且即表態支持黨提名人這件事比較有印像；而許市長雖然最後也放棄脫黨參選，但總覺得他本來也想循高雄縣長模式脫黨的，只是不知什麼原因使其放棄而以！

高雄市

對高雄市而言比較有印象的並不是花媽陳菊，反倒是脫黨參選的現任高雄縣長讓人印象深刻。雖然他後期極力訴求不分藍綠、政治中道的企圖明顯，可惜顯然大家對他的『昨是今非、昨非今是』非常有意見。但在這種情形下仍有 40 餘萬票其實力也算是異常雄厚，只不過我覺得他這次真的是賭輸了，未來如果想再走政治這條路應該是會異常艱困吧？

政治光譜的改變

在假圖天圖有篇【台灣觀察】藍綠光譜的改變! 提到現今的政治光譜已不光是藍綠而以，由於騜式詐騙集團的快速傾中導致這群詐騙集團的政治光譜比較像是紅色而不是國民黨黨徽上的藍色。本來以為在六年級上段班之前這些受過國民黨反共抗俄教育的這一代應該會全力反抗騜的傾中現象，不過實際上看來似乎還有很多人只是單純的效忠黨徽而不是去看領導人有沒有在亂搞的嘛，顯然過去國民黨的愚民教有真是成功呢！

大話新聞

呃，大話新聞不屬於五都的成員，只是因為就幾次選舉下來發現大話新聞的成員總會認為騜式詐騙集團即然這麼糟糕，相信所有台灣人都已經覺醒，必然會給騜一個嚴正的教訓！但每次的期昐的結果總是與預期相去甚遠，這究竟是什麼原因呢？也許就只是別高估台灣民主教育成就而以吧？

意圖使人不當選

以下是網路上討論到的相關文章：

選後第三天最新心得

今天聽說民進黨那些老灰呀全部跑出來批評小英，呃... 這群人實在該乖乖退休比較好...
還有人批評都是蘇光頭執意參選台北市長才會打亂原本的必勝配置，呃... 我也不認為新北市民願意看到回鍋的新市長...
個人一直不覺得那顆子彈對選情有啥影響，不過似乎全台灣都認為影響可大了？

Maven、Java 1.5 與 xdoclet 的相處之道

2010-11-26T16:41:00.004+08:00

最近幾年來的 Java 專案都使用 Maven 2 進行自動化部署程序，講白一點就是不想每次都要依環境差異而透過手工進行設定調整及打包程序。不過有趣的是還是有很多軟體開發人員仍然堅持手工打造然後因為一點疏失就上錯程式捅下漏子！

但是不知道為什麼，整個 Maven 中的 xdoclet plugin 預設一直使用舊版的 xjavadoc 套件，導致在處理 JDK 1.5 新增的泛型特性（Generics）時因為不認識角括號 < 而吐出一大堆錯誤訊息，並連帶使的 Maven 原本提供的 javadoc 操作失敗（產生的 javadoc 不完整），對開發公用程式庫且必須提供 javadoc 的人員來講就變的很困擾。

一直逃避不是辦法，所以今天花了點時間找了網路上的資料後試出了解決方法。基本上是參考解決xdoclet-maven-plugin於jdk5上跑發生問題的說法，但文中所提的 plugin 來源 http://quebbemann.kicks-ass.net/maven2/repository/ 被威猛的趨勢科技世界級創新Smart Protection Network主動式雲端截毒技術擋在門外... 只好另外找其他的 plugin 來源。

總之，要讓 xdoclet 叫用新版的 xjavadoc 模組的方法是覆寫 xdoclet-maven-plugin 的相依性設定，使 xdoclet-maven-plugin 正確叫用新版的 xjavadoc 1.5 去解析 Java 原始碼，因此需要在 xdoclet-maven-plugin 設定區塊下新增相依性設定如下：

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>xdoclet-maven-plugin</artifactId> <version>1.0</version> <dependencies> <dependency> <groupId>ant</groupId> <artifactId>ant</artifactId> <version>1.6.5</version> </dependency> <dependency> <groupId>xdoclet</groupId> <artifactId>xjavadoc</artifactId> <version>1.5-snapshot050611</version> </dependency> </dependencies> <executions> <execution> <id>xdoclet</id> <phase>generate-sources</phase> <goals> <goal>xdoclet</goal> </goals> <configuration> <outputEncoding>UTF-8</outputEncoding> <tasks> <webdoclet destDir="${basedir}/src/main/webapp/WEB-INF" encoding="UTF-8" docencoding="UTF-8" mergeDir="${basedir}/src/main/resources/webdoclet" verbose="true" force="true"> <fileset dir="${basedir}/src/main/java" includes="**/*.java" /> <deploymentdescriptor displayname="${project.name}" xmlencoding="UTF-8" description="${project.description}"> </deploymentdescriptor> </webdoclet> </tasks> </configuration> </execution> </executions> </plugin>

但是光這樣還不夠，因為 Maven 官方的套件庫中並未包含 xjavadoc 1.5 相關資訊，所以必須另外指定去那邊下載 xjavadoc 套件，這只要在 pom.xml 中加入以下設定區塊即可。唯一要注意的是這個套件庫有可能隨時不見... XD

<pluginRepositories> <pluginRepository> <id>jahia</id> <url>http://maven.jahia.org/maven2/</url> </pluginRepository> </pluginRepositories>

好了，經由以上設定後 xdoclet 就不會因為程式碼使用到 JDK1.5 的泛型功能時只會吐出一堆 warning 了！

試乘捷運蘆洲線

2010-11-04T00:14:00.000+08:00

聽說今天是捷運蘆洲線試營運的第一天，格揆我也湊個熱鬧調整了下班路線跑去試試看免費的蘆洲線究竟如何？

整個回家所需時間約為 80 分鐘，比原本路線的時間差不多得多花個 20 分鐘以上才行，為了早點兒奔向溫暖的床舖我相信蘆洲線應該只會搭這麼一次吧？

從 18:57 離開辦公室到回到家裡的時間 20:15 各種狀態（咦？狀態圖？）如下：

狀態	時刻	花費分鐘數	原路線所花時間
離開辦公室	18:57	-	-
出辦公大樓	19:00	3	3
搭上南港展覽館接駁公車	19:09	9	9
到達捷運南港站下公車	19:13	4	4
捷運南港站發車	19:17	4	4
捷運忠孝新生站下車	19:31	14	-
捷運蘆洲線忠孝新生站發車	19:37	6	-
捷運三重國小站到達	19:50	13	-
出捷運三重國小站	19:53	3	-
出捷運台北車站	-	-	17
台北車站-忠孝候車站	-	-	3 ~ 5
等待公車(藍1/39)	-	-	3 ~ 5
扺達三重大同路口	-	-	10 ~ 20
開家門	20:15	21	5
合計		77	67

其實從南港轉捷運蘆洲線回三重所需時間不算很多，但是從三重國小站要回到天台這一帶的話是要花上一點時間的。如果晚餐想在三和夜市中解決的話是可以考慮這一條回家路線，不然的話從台北車站經忠孝橋回三重通常會比較快才是！

還有從上表中可以發現在忠孝新生站轉車的等待時間偏久，不過如果以上班不遲到為考量的話搭乘捷運上班有其優勢存在（但是捷運三不五時會突槌，那叫做正常能量釋放）。最後整條蘆洲線的月台設計似乎都給人一種空間上的壓迫感，在等車的時候可能會造成心情上的不快！

[公告] 切換部落格網址

2010-10-30T22:59:00.000+08:00

原本就計畫將目前的 adahsu0521.blogspot.com 網址連結到原本使用的 blog.adahsu.net 上，今天正式完成了這個設定。不過因為 DNS 同步的問題可能最遲會到一星期後才能正常訪問。

Android Froyo 2.2.1 升級失敗

2010-09-30T00:12:00.002+08:00

前陣子 Google 䆁出了 Froyo 2.2.1 的小升級，身為 Nexus One 持有者當然會優先收到 OTA 通知，只是這次的升級... 失敗了...

因為使用過一鍵 ROOT 工具，所以早早就以節省 ROM 空間的理由把 /system/app 中的東西砍的砍、搬的搬，而這個沒有官方更新資訊的 Froyo 2.2.1 除了已知的解決了一鍵 ROOT 所使用的系統漏洞外還順便更新了系統內建的 GMail.apk 到 2.3 版。

問題在於 GMail 2.3 這個升級版本來就可以從 Android Market 中下載，所以我也早就把原始的 GMail.apk 給弄走換成新版的 GMail ，於是 Froyo 2.2.1 在更新的過程中因為找不到 GMail.apk 的關係所以 patch failed ... 想當然，於是 OTA 就這麼莫名其妙的失敗了... 還好雖然 OTA 失敗但系統仍然可以透過組合鍵重新開機，只是 OTA 更新就這麼不見了...

重新開機後原始的 ROOT 環境還在（呼~~ 好佳在），趕快把 GMail.apk 搬回去再把 GMail 2.3 移除後，至今為止（才過了一天而以啦）還沒重新收到 OTA ，也許我得堅守在 Froyo 2.2 了吧？

※如果還有更新其他套件的話，那下次 OTA 應該還是會失敗吧...

2010-10-03 補充：
昨天再次收到 Froyo 2.2.1 升級通知，這次也沒太多考量就莫名其妙給它按下更新... 然後... 又失敗了... XD

這次它去更新 Google Goggles，但... 我移掉了... XD

2010-10-08 補充：
今天三次收到 Froyo 2.2.1 升級通知，這次也沒太多考量就莫名其妙給它按下更新... 然後... 又失敗了... XD

這次它去更新 Amazon MP3，但... 我移掉了... 而且是沒備份的移除了... XD 顯然只能重刷 Froyo 2.2 後再進行升級了... @@

促銷價格的背後

2010-08-26T01:02:00.000+08:00

有家超商喜歡用第二件六折的方式拉抬產品銷量，也有一家超商總是以二件 79 折方式來吸引消費者的眼光，畢竟第二件六折的實際意義就是二件八折，這個 79 折策略聽起來就是有那麼一點佔人家便宜的感覺。

上圖就是 79 折的實際案例，只是這個整箱特價似乎有點問題...

以一罐鋁泊包飲料 10 元來計算，192 元其實是打八折時的價格，如果以 79 折來計算的話應該是 189.6 元，只是超商是否會進位到 190 元則不太確定，而且超商的 POS 會刷出多少錢出來也有待測試。

嗯，不過在這邊計較這兩塊錢會不會顯的太窮酸樣了呢...

昨日的冒險旅程

2010-08-14T15:06:00.000+08:00

昨日 ( 2010/08/13 ) 下班所搭乘的公車在剛過新莊思源路時，忽聞司機伯伯一聲廣播：『抱歉，請各位準備更換車輛，本車爆胎了... 』！正當大家還莫名其妙摸不著頭緒時，車身一震，原本轟隆（這是誇飾法）的引擎聲嘎然而止.... 我想，再怎麼狀況外的人也都知道該下車了... XD

不過，下車後所看到的景像可就讓人心驚膽顫了...

寄件者危險

那麼它的右後退呢？

寄件者危險

點選照片可以連到有地圖標示的 Picasa 相簿！

最佳英文翻譯獎

2010-06-07T22:00:00.000+08:00

這個翻譯真是超贊的...

如何在下載動作中正確顯示中文檔名？

2010-04-14T17:16:00.003+08:00

總而言之，除了為人垢病的 CSS 問題外，各家瀏覽器在下載中文檔名時也有各自的脾氣...

以下是 JAVA 程式碼範例，大致上就分成兩派：支援 RFC-2231 的 Firefox/Opera 系和不支援的 IE /Webkit 系兩種，在 Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding 網站中有對各家瀏覽器是否支援 RFC-2231 規範的測試記錄，就結果來看除了純 ASCII 編碼的檔名頗受大家都支援外 (?)，其他混雜有各地語言的檔案名稱就得依瀏覽器的派別個別處理了。

if ( StringUtils.contains( userAgent, "MSIE" ) || StringUtils.containsIgnoreCase( userAgent, "AppleWebKit" ) ) {
    res.setHeader("Content-Disposition", "attachment; filename=\"" + URLEncoder.encode( fileName, "UTF-8" ) + "\"");
} else {
    res.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" + URLEncoder.encode( fileName, "UTF-8" ) );
}

就目前測試結果得知：

IE 6：可以正確彈出下載視窗，但存檔時的不一定能顯示正確的中文檔名
IE 7/8：可以正確彈出下載視窗及中文檔名
Chromium 5.0.360.5 / Chrome 5.0.375.3 dev：可以正確彈出下載視窗及中文檔名，其 AppleWebKit 核心版本分別為 533.3 及 533.4
Safari 4.0.5：在 AppleWebKit/531.22.7 時兩種方式都不行，但因 Chrome 的經驗猜測更新 AppleWebKit 到 5.33 以後版本即可正確顯示中文檔名
Firefox 3.x：可以正確彈出下載視窗及中文檔名
Opera 10.51：可以正確彈出下載視窗及中文檔名

OpenTTD 簡單心得

2010-03-18T11:58:00.004+08:00

最近不務正業的在玩豪華運輸大亨，都忘了要趕快規畫倒底要寫那類型的 Android 軟體了... 不過還是簡單記錄一下大亨的入門心得好了。

這個遊戲的重頭大戲其實在鐵道規劃上，如何利用鐵道號誌讓一大堆的火車可以在雙向兩條軌道上正常運行而不會有對撞、追撞等事故算是最簡單的入門（雙軌雙向軌道真的比單軌雙向軌道簡單多了）。雖說只是入門，但看著二、三十輛車在軌道上依序運行卻總能帶給玩家滿滿的成就感。以下是釀成多起追撞、對撞事故後的注意事項清單！

如果要賺錢的話可以搞航空運輸，不過個人覺得很空虛...
如果要搞鐵道貨運的話網友都會建議以媒炭為主
雙軌鐵道要先統一是左出右進還是右出左進，像台灣的鐵道記得都是左出右進的！
雙軌鐵道在分歧點時都需要設置號誌，簡單的概念是左邊出口處要放入口號誌，右邊進(入)口處則放置閉塞號誌，號誌應設置在前進方向的右側，以左出右進來看號誌就會集中在鐵道中央。有興趣者可以參考這裡！
如果軌道上有多輛車次的話則視鐵道長短酌量設置閉塞號誌，不然的話車子會卡在車站出口處。而車站出口處一被卡死就會造成同軌道上的車輛要不就跟著卡死，要不然就是追、對撞事故。
維修機場不要設在離車站太近的地方，距離至少要超過車輛長度（7格14節）及號誌設置區，不然有很大的機會出現車輛卡在車站與機場之間動彈不得的情形。

嗯，有新的心得會繼續補充！圖片的部份再想辦法生出來...

陷入無限迴圈的火車...

敢搶我礦產者，必阻之！

Android Developer Lab 參加心得

2010-03-03T21:18:00.001+08:00

好吧，我承認這一篇是炫耀文，其實沒啥心得可言！

忘記是去年底還是今年初在噗浪上看到葉教授發佈 Android Developer Lab 台北場開放報名時，因為天真的幻想能在 Android 平台上撰寫自己需要的軟體，於是莫名其妙的就填完單子完成報名手續。因為 Google 沒有立即回覆任何訊息，所以也差不多忘了這件事，直到過年前收到 Android Developer Lab 報到通知時才想起來要留一天年假去參加這個我戲稱為 Android 開發者聯誼會的活動。

聯誼會的日子很快的到來，因為入場時間是在 12:30 這個挺微妙的時間，所以早上硬是逼著自己不可太晚吃早餐以免中午吃不下結果在會場內昏倒的蠢事發生。還好，當葉教授說要出發前往會場時確認沒有供應午餐後，我也在 11:15 時分出門搭乘 638 前往六福皇宮會場。午餐是先在附近的小吃店以榨菜米粉湯（真的沒有肉絲）解決。

這是今天 Android Developer Lab 的入場券，並且憑券得兌換小禮物乙份！

到了 12:37 時活動正式開始，然後就聽到令人振奮的一句話：『今天活動要以英語為主』... 雖說插大時英文考的比國文好，但好像我的國語遠比英語像樣很多，於是老灰呀注意力無法長時間集中的問題就發作了，時而恍神、時而回魂是今天活動中最主要的精神運作模式...

總而言之，第一段是葉教授簡短介紹 Google Taiwan 及 Taipei GTUG，接下來換人介紹手機上網的趨勢；然後是 Android Marketplace 的上架辦法及一些注意事項。這部份雖然大致聽懂講者的內容大意，但全程英語還是有一定的催眠效果。就在恍神模式下時忽然看到這個 Google Japan 所拍的 Nexus One 忍者開箱動畫。正沉浸在影片中 KUSO 的宣傳手法時竟然聽到要送手機的字眼，你知道的，有東西吃或是有禮物拿時總是可以讓人眼睛為之一亮，於是所有人就全部擠出門去排隊領 ~~長崎蛋糕~~ Nexus One 禮盒。在等待的過程中不少人還抱持懷疑態度以為手機只是借用，會後需要歸還的。但一切都在有人按耐不住的詢問工作人員後獲得解答：『不用還，手機真的是送的』！Google 大神啊，您真是佛心來著呢！

因為在領取手機前有說到接下來的兩堂課會實作，如果電量不足的話腳邊有插座可用（後來覺得應該是聽錯了），於是大部份人都在現場玩起開箱遊戲。不過最後發現其實手機可以原封拎回家好好開箱的，現場實作用模擬器就可以了。這也是我覺得之前提到的插座應該是為了給筆電沒電的人使用的，並非說是對手機充電之用。

這就是憑入場券所兌換的長崎蛋糕禮盒（誤）

由於聽說第三節開始是實作說明，所以有個笨蛋就把筆電開機了。可是搞了半天原來是介紹 Android SDK 2.1 的許多新特性，於是白白浪費了 50% 的電量在這堂課中（6 cells 電池是撐不久的），等到真正 Coding 練習時我的筆電就在低電量警告訊息中沉沉睡去........

CodeLab 練習的題目是動態桌面的實作，講師提供了一個基礎 Eclipse 專案設定作為練習，但因為投影片的字是真的有夠小所以最後我下載 FINAL 版進行比對，在程式碼確認的差不多時當然會想要執行看看，然後就在模擬器啟動途中看到低電量警告，原本以為來的及看到程式效果的幻想則在筆電自我感覺沒電不太好自動關機的情形下完全破滅...

還好這時候講師也實作完畢，時間進入 Q&A 時段... 看著鄰兵打包走人後，我也開始找地方塞剛領到的長崎蛋糕禮盒，然後出門去搭車回家。

搭車時有在想，動態桌面這個題目是不是有點雞肋呢？我以為大部份開發人員應該不會對這種不以實用為目的的特色有太多關注，那麼今天這個 CodeLab 範例選擇這個題材是否有啥特殊意義呢？和 Widgets 搶食桌面空間？其實到現在我還是沒有任何答案就是了...

對了，今天領到 Google 高科技小禮物雖然很 High ，但是 5800XM 上原本同步來的通訊錄整個不見也令人很駭... 回家第一件事是上 Google 看看通訊錄內容有沒有跟著消逝，還好，它們還在！

全劇終... ！

ONE PIECE: STRONG WORLD

2010-02-07T23:44:00.003+08:00

上週到國際書展時才發現原來 ONE PIECE 電影版 STRONG WORLD 強者天下已經上映後（剛好上映的隔天去書展的），就幻想著一定要趁過年前先看一看。今天是過年前最後一個假日，我也很努力的在京站威秀售票口前排了將近一小時的隊。不知道為什麼場次的安排似乎不是連續的，還好大家顯然都跑去看 MONGA 而沒來和我搶 ONE PIECE 的座次。雖然尚未滿座，但是這個可容納百餘人的小場地其實在輪到我購票時也沒剩幾個位置可以選了，此刻倒是有一種為什麼早上不先多花 20 元手續費直接網路購票的悔恨... (泣)

就劇情上來講可能要扯到 OnePiece 第 0 卷，另外在動畫版部份魯夫於到達海底監獄『推進城』時也有加入一段金獅子的故事（426話開始）。總而言之，這是一場世界政府的危機但最後世界政府啥都不能做的故事。至於為什麼世界政府啥都不能做的理由還請進電影院瞧瞧！

另外在各橋段中總是一直穿插著各式各樣的笑點，不過印象最深刻的應該是布魯克被食肉蟻小看時說的那句『我只是局部型肥胖』吧！這真是中廣型阿宅最需要的一句救世密令啊... XD

沒想到 WIKI 上已經有人整理了電影相關資料了！
除了娜美的裸露演出外，羅賓的馬尾 + 眼鏡娘造型倒也是讓人印象深刻，雖然她最後沒啥表現機會！
MONGA 發音要正確，不然會變成 MANGA。
對了，這是 MONGO 預告片！
如果有人想請客的話，我還很願意再進電影院看一遍.... XD
啊對了！個人覺得本劇場版應該歸為輔導級，因為裡面抽煙的人太多了卻沒有打馬賽克...

把 SFTP 關起來 (CHROOTED)

2010-01-15T16:21:00.004+08:00

前言

為了提供少量的檔案共享但又不願意特地去設定 FTP 服務的話，通常第一個想到的會是附屬在 SSH 服務下的 SFTP 傳輸模式，事實上 SFTP 這個服務雖然因為加密的關係會導致傳輸時間略長，但卻一直是格揆我作為檔案傳輸的唯一方式。但這方式雖方便卻有個大問題：登入的使用者可以看到所有的檔案目錄甚至直接下載檔案內容。這在多人使用的環境下顯然會有資安上面的困擾，有沒有辦法把 SFTP 服務關在某個指定的目錄下呢？

格揆經由 Google 大神的協助並多方測試後終於實作出可行方案，就... 再貢獻回給大神吧... XD

設定步驟

※ 本文以 OpenSSH 5.2_p1-r3 為設定環境！

選定封鎖目錄：如果對像是單一個人時即為該用戶登入 SFTP 時的根目錄；如果對像是一個群組時則該目錄為這群使用者目錄的根目錄。

在 /etc/ssh/sshd_config 中啟用 sftp subsystem：特別注意要啟用的是 internal-sftp 這個 Subsystem。

# override default of no subsystems
#Subsystem      sftp    /usr/lib64/misc/sftp-server               # 系統中原來的設定
Subsystem       sftp    internal-sftp                                       # 改用 internal-sftp

一樣在 sshd_config 中指定需要被關起來的使用者資訊及要關到什麼地方去，請在前述修改處之後加上以下設定：

Match User ada                                 # 要被關起來的使用者，如果是群組的話則將 User 改為 Group 再接群組名稱
                                                          # 例如： Match Group rootedSFTP
ChrootDirectory /chroot                    # 要關在什麼地方，如果對像是個群組且群組內的每個人有個別目錄設定時，
                                                          # 可以加上 PATTERNS (man ssh_config) 做區隔，如 /chroot/%u ，
                                                          # /chroot 為這群使用者目錄的根目錄。
ForceCommand internal-sftp            # 一樣要使用 internal-sftp 這個 Subsystem

設定 Chroot 目錄權限：錯誤的目錄權限設定會導致在 log 中出現 "fatal: bad ownership or modes for chroot directory XXXXXX" 的訊息。根據 openssh 5.1 chrootdirectory permissions issue 這篇文章的資訊顯示，目錄的權限設定有兩個要點：
- 由 ChrootDirectory 指定的目錄開始一直往上到系統根目錄為止的目錄擁有者都只能是 root
- 由 ChrootDirectory 指定的目錄開始一直往上到系統根目錄為止都不可以具有群組寫入權限
重新載入 sshd 後即可透過 FileZilla 等支援 SFTP 的軟體測試有無被關起來了...

Gentoo Linux 與 Windows 7 安裝心得

2009-12-15T16:09:00.000+08:00

這幾天一直在安裝 Windows 7 和 Gentoo Linux 10.1 之間奮戰，浪費了不少時間踩了不少的地雷，恰好可作為部落格的文章以為紀念... XD

Dual Boot

首先因為 Windows 7 在安裝時會在硬碟中產生兩個 Primary Partition ，這讓我在評估是否雙系統共存時有了很慎重的考慮，並為此選擇在 VirtualBox 3.1 中先行試驗確認。不過，經過多次測試總無法經 Grub 對 Windows 7 開機，在最後關頭時決定直接上機測試成功時，才驚覺整整浪費了 2 個工作天在無任何產值的測試作業中... (嘆)

另外對於 Dual Boot 這件事，Gentoo 其實沒有先 Windows 再 Linux 之類的條款，因為它不會幫你建立預設的開機環境設定。Grub 裝在 MBR 也無所謂，反正 Windows 7 開機是從第一個 Partition 中的特定檔案啟動的。最後我還放棄了 SWAP 分割區的設置，將 4 個 Primary Partition 平均分給兩個作業系統，Gentoo 就一個 / partition 及一個 /home partition 。

發行套件的選擇

基本上這是因為安裝過程不太順利下，為什麼還選擇 Gentoo 的原因說明

Gentoo 之所以在某些群體中受到歡迎經常受到誤解，認為這些愛用者是因為迷信自行編譯所帶來的無上效能。其實在目前的中、高階 CPU 及便宜的記憶體市場下，自行編譯所帶來的效能改善情形非常有限，很多人應該也不是那麼心甘情願的願意浪費 1 ~ 2 天的時間進行系統編譯的工作（尤其 Windows 7 安裝一遍只要 20 分鐘），只因為目前還沒有看到更有彈性的軟體套件管理機制，導致短時間內無法轉投入另套發行套件。像格揆本人我就一直想要知道 Arch Linux 究竟有沒有類似 Portage USE 選擇的機制，只是說從所有的範例中似乎嗅不出類似機制的可能性，我也只好繼續使用 Gentoo 系統了！

基楚系統建置

在進行 Gentoo 基礎系統建置時切記不要過早投入 Portage Overlay 的設定，雜亂的套件相依設定是造成系統編不出來的主要原因，尤其在桌面管理系統上影鄉尤為深遠。

另外為了簡化系統的複雜度，一開始也不宜過早加入 ACCEPT_KEYWORDS 的設定，儘量先以系統預設的、穩定的套件版本為基礎完成配置後再加以強化為宜。

ExtJS 筆記 - EXTJS 的事件處理函式

2009-11-16T01:48:00.007+08:00

和 jQuery 不同，ExtJS 的事件處理函式略顯複雜了些！原因在於 jQuery 的事件綁定機制永遠只作用於 jQuery 物件，但 ExtJS 的事件綁定機制卻必須先確定事件綁定對象的種類。

在 ExtJS 中有兩種類型的 Ext 物件可以進行事件綁定，一種是 Ext.Component，另一種是 Ext.Element。雖然它們都會對應到頁面上的 HTML Element ，但實際上來看 Ext.Component 算是以 Ext.Element 為基礎進行擴充的衍生物件，常因為特別需要而自行提供許多自定的事件，例如 Ext.form.Checkbox 這個 Ext.Component 物件會額外提供 check 事件，當然你可以把這個 check 事件當成原本 click 事件的再包裝。

所以說只要弄清楚事件綁定的對象後也就能夠確定所使用的事件處理函式的參數型態，對 Ext.Element 而言它的事件處理函式參數格式為：

/* 此的處 element 是一個 HTML Element ，也就是原本的 HTML DOM 物件 */
function eventHandler( event, element, object ) { }

但若是 Ext.Component 的話它的事件處理函式則為：

function eventHandler( component [, value/state ] ) { }

其實寫 ExtJS 應用系統很容易遇到事件處理函式未能如預期反應的情況，這是因為搞錯了事件作用的對象以及事件處理函式的參數匹配不正確所導致，要不是因為此次的系統開發時用到了 Ext.form.Checkbox 這個元素，也許格揆我還沒發現原來 ExtJS 的事件模型有分成兩種情形，而大致搜尋了一下也沒有啥文章特別提到這個明明就在 API 文件中，但工程師顯然不會特別注意到的情形。

但我們該怎麼取得 Ext.Component 或 Ext.Element 物件呢？只要記住除了 Ext.getCmp() 外，其他的 DomQuery 函式都只會傳回 Ext.Element 或 Ext.CompositeElement（可把它當成多個 Ext.Element 物件的集合）物件。

以下的範例可看出 Ext.Component 及 Ext.Element/Ext.CompositeElement 在注冊事件處理函式時的差異：

<html>
    <head>
        <link rel="stylesheet" type="text/css" href="http://www.extjs.com/deploy/dev/resources/css/ext-all.css" />
        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
        <script type="text/javascript" src="http://www.extjs.com/deploy/dev/adapter/jquery/ext-jquery-adapter.js"></script>
        <script type="text/javascript" src="http://www.extjs.com/deploy/dev/ext-all.js"></script>
        <script text="text/javascript">
            function init() {
                var viewport = new Ext.Viewport({
                    layout: 'form'
                    ,defaults: {
                        xtype: 'checkbox'
                        ,labelWidth: 70
                        ,labelAlign: 'right'
                    }
                    ,items: [
                        {
                            fieldLabel: '選項一'
                            ,id: 'chbox1'
                        }
                        ,{
                            fieldLabel: '選項二'
                            ,id: 'chbox2'
                        }
                        ,{
                            fieldLabel: '按鈕一'
                            ,id: 'btn1'
                            ,xtype: 'button'
                            ,text: '按鈕一'
                        }
                    ]
                });
  
                // 對 Ext.Component:chbox1 物件注冊 check 事件處理函式
                Ext.getCmp( 'chbox1' ).on( 'check', function ( chbox, checked ) {
                    alert( chbox.getId() + ' is ' + checked );
                });
  
                // 對所有的 Ext.CompositeElement:Checkbox 物件注冊 click 事件處理函式
                // 實際上有兩個物件被注冊了事件處理函式
                // 如果想在 Ext.Element 物件上綁定 check 事件的話，它是不會生效也不會有錯誤的喔！
                Ext.select( 'input[type=checkbox]' ).on( 'click', function( evt, el ) {
                    Ext.Msg.alert( 'Event Tester', el.id + ' is ' + el.checked );
                });

                // 對 Ext.Component:btn1 物件注冊 click 事件處理函式  
                Ext.getCmp( 'btn1' ).on( 'click', function( button ) {
                    alert( button.getId() + ' clicked' );
                });
  
                // 對所有的 Ext.CompositeElement:button 物件注冊 click 事件處理函式
                // 實際上有一個物件被注冊了事件處理函式
                Ext.select( 'button' ).on( 'click', function( evt, el ) {
                    Ext.Msg.alert( 'Event Tester', el.id );
                });
 
                return viewport;
            }
     
            $( document ).ready( init );
        </script>
    </head>
    <body>
    
    </body>
</html>

參考資訊：

ExtJS入门之二事件

閃擊點行動 - 龍之堀起 ( Operation Flashpoint - Dragon Rising )

2009-10-26T01:12:00.000+08:00

閃擊點行動 - 龍之堀起 ( Operation Flashpoint - Dragon Rising ) 是 CodeMasters 公司前陣子新堆出的遊戲，同時支援 PC / XBox 360 / PS3 三平台。

總括而言，這是一套除了畫面遠勝 2001 年首次推出的閃擊點行動 - 冷戰危機外其他部份都完敗的失敗作，甚至嚴格而言本遊戲也不算是冷戰危機的續作，至少從遊戲命名中是完全看不到 2 這個字眼的。

簡單條列個人覺得這套遊戲和冷戰危機相比失敗的地方：

從班戰鬥縮水成小隊戰鬥：沒錯，這是個精英小隊，但是一次 12 個人可以有更多的戰術配置。沒記錯的話在冷戰危機中有一個關卡還是一整個排去打敵人的設定呢！這項改變大致上可以猜到是因為 PS3 / XBox 360 操控手把所做的限制。
戰術指令缺乏細節設定：記得冷戰危機中可以命令隊友去撿拾槍枝和補充彈藥，也可以把整個班透過撿拾殂擊槍的命令而變成殂擊班。本遊戲中似乎電腦隊員都沒有缺彈危機？把戰術指令大幅刪減的原因大概也是為了配合遊戲機的操控吧！對了，我曾對隊員下達接敵指定對象的命令，但是... 他們都不鳥我... (怒)
可遠觀而不可褻玩焉的載具：在冷戰危機及其資料片中有一大堆的載具（飛機、輪型車輛、民車、以及裝甲車等）可以操作，但到了龍之堀起時真的開過的只剩下悍馬車和最後關卡的直昇機而以。不過看電玩快打介紹的影片中有戰鬥直升機可以操作，但我的軍旅生涯回憶錄中只有被戰鬥直升機追殺的慘烈而以.... (嘆)
過關條件的限縮：冷戰危機最為人所贊頌的是他無特定規則的過關選擇，在冷戰危機中除了從外圍一路殺進敵營外，還可以先溜進敵營偷一台裝甲車或雌鹿攻擊機後再殺出來，這是龍之堀起總是走進去敵營又一路打出來的固定模式難以超越的。
隊員養成：在冷戰危機是可以透過經驗值累積以提昇班兵的能力的，但是龍之堀起中每次帶的隊員都一定不同，隊員陣亡也只需等到檢查點後就會重新復活，當然也就少了經驗值作為隊員養成的依據了。
關卡的變化性不足：在冷戰危機中有防禦、有攻擊、有步行機動、有車輛接送、也有裝甲車專屬關卡，還有直昇機攻擊，而龍之堀起則是突擊後防禦為主。其中雖然有一關是監控解放軍將領 - 韓將軍逛大街的特殊關卡，但最後用 JDAM 轟掉房子的設定其實覺得挺空虛的... (默)
關卡過短，故事性不足：記得冷戰危機約有 20 關... 吧，龍之堀起只有 10 關的樣子，搞的玩家還沒融入故事情節時遊戲就結束了.... -.-

認為龍之堀起不如原本冷戰危機的原因大致如上，如果不是 CodeMasters 和原開發冷戰危機的波西米亞工作室鬧僵的話，也許真正的 Operation Flashpoint 2 早就推出了。

S60 手機平台與 Google Service

2009-10-19T01:53:00.225+08:00

註：Mobile01 新版的 Symbian^3 系統如何設定 Google Service 同步的說明，見N8同步於Google服務(聯絡人、行事曆) + N8社群介紹！

老實說，從因故購入 Nokia 5800XM 這半年以來，我一直沒有一次就完成 Nokia 智慧型手機（S60 作業系統）在商務需求上的設定。今次經由一再的重試與手機硬格後，似乎有了一點點可以依據的脈胳可循。

商務需求包括那些呢？我想至少會包含通訊錄、行事曆、還有 EMAIL 三者間與原作業平台的相互同步，除了一般企業內部常見的 Microsoft Exchange Server 外，一般個人所能接觸到可同時提供這些服務的公司顯然以 Google 最廣為人知（其實 Nokia 自己也有提供一個整合性服務叫 Ovi ，除包含前述服務還有些其他的）。本文的主要目標是設法將 Google 上的資料與 S60v3/v5 手機相結合。

說到 Google 採用 Microsoft 的 ActiveSync 技術協定的目的就是希望能一次滿足前述三個願望，可惜事與願違，Google 目前在 S60 平台上確實還無法達成 EMAIL 同步，因此整個作業要分成兩部份來進行：通訊錄與行事曆可以合併處理、至於 EMAIL 則需另尋他法。

Push EMAIL

說 EMAIL 要另尋他法其實也不是說需要多複雜的設定，只要透過第三方服務即可達成，這服務就是 Nokia Messaging。

首先，把手機扔一邊吧！如果你一心想找 Nokia Messaging 的用戶端軟體自行安裝的話，保證事倍功不成。

如果是第一次使用 Nokia Messaging 服務時必須先建立一個 Nokia Messaging 帳號，但這帳號並不需重新選擇 ID/PWD ，實際要做的只是選擇一個需要被 Push 到手機的現有 EMAIL 帳號即可。Nokia Messaging 支援 POP3/IMAP 郵件協定，也支援包括 Yahoo! Mail、Google Mail、Windows Live Hotmail、Ovi Mail 以及郵件代管類型的 Google Apps、Yahoo! Small Business 等郵件資源，總而言之挑一個出來當主信箱帳號即可。另外 Nokia Messaging 可以支援最多 10 個郵件的推播服務，可以依需要自行增減信箱個數。

當然如果不放心把 EMAIL 交給 Nokia 的話，可以考慮只設定那些非日常使用的次要信箱即可。一般來說次要信箱通常很少主動去開啟的，讓 Nokia Messaging 協助追蹤這些信箱似乎也不錯！

決定好主要信箱後即可 Sign Up 進行申請程序。在申請的過程中會發送簡訊到手機上以便開始下載及安裝 Nokia Messaging 用戶端軟體。這程序很重要，整個啟用 Nokia Messaging 用戶端軟體的相關設定都包含在這則簡訊中，當你讀取這則簡訊時會觸發軟體下載、安裝然後手機自動重開機的流程。這過程需要一點時間，也許可以趁這時間回到 Nokia Messaging 官網中把需要 Push 的各郵件信箱設一設。

當手機重新啟動後有機會看到一個標為『簡訊佈建』的畫面，這時手機會進行一些內部設定，完成後即可看到 Nokia Messaging 手機軟體的登入畫面（請參考 Nokia的Push mail--Nokia Messaging 一文中的第二張圖），輸入前述申請作業中設定的主信箱帳號的密碼即可登入。

Nokia的Push mail--Nokia Messaging 一文是以 E71 做說明，如果是 S60v5 平台的話則主要畫面如右圖所示，可以選擇要看那個信箱，也可以另外新增其他信箱。

另外，如果因為某些因素必須重新安裝 Nokia Messaging 手機端軟體時也請切記一定要從 Nokia Messaging 網站上進行，只需在登入後點選頁面右方的 Install now 即可。如果是自行由手機內安裝先前下載的 .sisx 檔的話是不會與 Nokia Messaging 服務有任何關連的，這個時候對 Nokia Messaging 手機軟體的各項操作都會被寫進手機訊息中心內的電子郵件項目中，在 Nokia 5800XM 上會發生一件很糟糕的情形 - 這些 EMAIL 帳號設定無法刪除...

以上是個人選用為 S60 手機與 EMail 整合的一種方式，目前 Nokia Messaging 服務仍然免費但後續可能會改為收費服務，此點請特別注意。（別擔心，Google Sync 屆時就可以支援 Symbian 平台上的 EMAIL 同步了.... 我猜的... ）

※ 2010-01-17: 目前 Nokia Messaging 10.1 版用戶端程序已經可以自行重新建立相關設定了！

在 Nokia Messaging 10.1 版直接點選電子郵件設定時會開啟新的（大概吧）設定頁面，按下開始後即可進行設定。
接下來這頁是選擇郵件種類，不過格揆懷疑這是為了方便給新使用者所提供的選項。像格揆這種早就有申請 Nokia Messaging 的使用者可以直接選其他即可。
然後分別輸入原先 Nokia Messaging 服務中指定的郵件帳號及密碼後即進行驗證。
如果在進行帳號匹配時未插入 SIM 卡的話，Nokia Messaging 會要求手動輸入電話號碼以便和原登錄的資料進行驗證，是否有實際用途則不確定（誰沒事常換號呢？）
一旦帳號密碼匹配成功後即可看到 歡迎再次使用 的訊息，同時也告知還要再輸入一次 Nokia 訊息密碼。
Nokia 訊息密碼就是 Nokia Messaging 服務的密碼，不太瞭解為什麼還要再輸入一次？輸入後即可看到熟悉的 Nokia Messaging 畫面，原先的設定也會同時自動下載。

※其實我是想反正 Nokia 開始收費時我就跳到 Android 去了，沒差啦！

行事曆、通訊錄同步

再來就是如何同步行事曆和通訊錄，大致上請先參考 Google Sync 的說明。~~至於格揆則需要花點時間擷圖... 擷圖的目標放在如何同步 Google Apps 上的個人行事曆與通訊錄。請大家等個一、兩天吧... :p~~

先期準備 - Google Apps 管理設定

如果需要同步的通訊錄、行事曆來源是 Google Apps 服務，那麼必須先確定 Google Apps Manager 已同意開啟手機行動 Google Sync 支援，詳見 Enable Google Sync via ActiveSync 內說明。

更新 Mail for Exchange

Mail for Exchange 必須要 2.0(9).158 以上版本才能支援，Symbian 手機可以透過內建的更新機制進行軟體更新，在更新的過程中會有警告訊息提醒一旦使用 Mail for Exchange 後就不可以再使用其他同步軟體。

雖然也可以從 Mail for Exchange 官網自行下載手機端程式，不過似乎還是比透過手機更新的版本來的舊。

Mail for Exchange 同步設定

執行 Mail for Exchange（以下簡稱 MfE）後即可進行同步設定，併隨 MfE 安裝的公司目錄工具是用來查詢 Microsoft Exchange Server 上的通訊錄用的，因為 Google Sync 使用 ActiveSync 協定進行同步作業，所以日後可以使用這個工具查詢 Google 通訊錄上的內容。

第一次執行 MfE 時會因為沒有任何同步設定而詢問是否建立操作模式，反正只能選擇是不然就沒得用。

首先填入 EMAIL 基本資訊，不管是 GMail 還是 Google Apps 都請在電子郵件位址及使者用名稱部份填入完整的 EMAIL 信箱全名。至於網域部份則因為軟體限制直接填入 google 即可，存取點則通常設為網際網路，如果有申請 mCool 49 之類的 WAP 上網吃到飽的則可以選擇 WAP 。

輸入完 EMAIL 基本資訊無誤後即可按下確定鈕，MfE 會嘗試擷取郵件伺服器的設定。如果是在一般企業內部的話應該可以自動捉取到 Exchange Server 的相關資訊，但 Google 的手機服務似乎是透過另一個獨立主機做橋接的，因此 MfE 會出現擷取失敗的訊息並要求手動輸入 Exchange Server 的相關資訊。

在 MfE 中總共有八個設定頁籤分別對應到連線、認證、同步排程、行事曆、工作、通訊錄、郵件、不在辦公室，不過一開始第八個設定頁是看不到的。

連線設定：主要就是指定 Exchange 伺服器的名稱，請填入 m.google.com 即可。

認證：先前輸入的完整 EMAIL 全名會自動帶入這個設定頁中，完全不用更改。

同步排程：此頁籤用於設定同步的頻率，預設為尖峰時段永遠連線，離峰時段則每 30 分鐘連線同步乙次。基本上因為電信訊號並不穩定且人員也不一定都在 WiFi 訊號範圍內之故，把同步頻率改為定時更新應該比較適合。

行事曆：Google Sync 目前可以支援行事曆同步，原則上雖然可以保留手機上即有的行事曆內容，但這麼做很容易把行事曆搞亂（N82 時代同時同步 Outlook 及 Google Calendar 的心得，每重建乙次手機設定就會多一倍的行事曆項目）。所以這裡通常會選擇先清空手機上的行事曆資料。

工作：待辦事目前尚不支援同步作業，請選擇不同步。

通訊錄：一樣建議先刪除手機上的內容後再進行同步。如果手機上的資料完全沒有和 GMail / Google Apps 上重覆的話可以考慮保留以便傳回 GMail / Google Apps 上。

郵件：目前 Google 仍不提供在 Symbian 支援郵件同步，而且前面不是已經使用 Nokia Messaging 提供 Push Mail 服務了嗎？

不在辦公室：這必須先能連上 Exchange 伺服器後才能檢視，目前 Google 也不支援。

完成各頁籤的設定且確認無誤後就可以按下選項→儲存將設定保存下來，之後回到首頁時會看到 MfE 已開始嘗試連線進行同步了！

當你專心的注意畫面上的訊息時，會發現目前狀態這項訊息會依序改變： 連線中→已連線→閒置，那麼結果究竟成功了沒？經由檢視記錄的功能應該會看到這個畫面：

同步作業

什麼？搞半天竟然沒成功？嗯，稍安勿噪！之前格揆都只進行到這個步驟就放棄了，所以不知原來事有蹊蹺。其實啊，真正的同步作業現在才要開始呢！不如，再試著同步一下看看？

咦？它顯示出正在同步行事曆耶！趕快檢查記錄也確認有 5 筆行事曆記錄被匯入。

可是為什麼通訊錄沒有同步呢？再來同步一次好了，又發現通訊錄的也開始匯入了，記錄中也確認有 34 筆記錄被匯入。靠么，原來同步作業是需要耐心和勇於嘗試的作為啊？

基本上同步的設定到此即算完成，若不是還放心的話可以嘗試分別在手機及 GMail / Google Apps 中分別新增一筆行程及一筆通訊錄，然後等排程時間一到看會不會完成同步。

結論

之前一直朝著完整重新同步的想法去進行測試，結果沒有一次成功。沒想到最後是因為選錯項目才發現只要一直同步就有機會完成整個同步程序，這實在有夠瞎就是了。

Tomcat: Cannot create PoolableConnectionFactory

2009-10-12T15:06:00.002+08:00

因為在修改某系統的部署方式而遇到這個問題，特此記之！

錯誤訊息：

12:15:11,605 ERROR jsp:228 - Cannot create PoolableConnectionFactory (IO 異常: The Network Adapter could not establish the connection)

據說這個例外的成因還不少，但在使用 Oracle 資料庫的情形時有個比較特殊的原因：連線設定參數與資料庫設定不符。最直接的驗證方式是將資料庫連線設定改用 tnsnames.ora 檔案內的寫法取代即可。Ex:

<Resource 
    name="jdbc/oracle" auth="Container"
    type="javax.sql.DataSource"
    driverClassName="oracle.jdbc.OracleDriver"
    url="(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP))(HOST=192.168.1.1)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=MY_DB)))"
    username="賣哀滴"
    password="賣怕死我"
    maxActive="8"
    maxIdle="4"
    maxWait="30"/>

部落格搬家紀實 - 從 SnipSnap 到 Blogger

2009-10-12T01:00:00.000+08:00

前言

基本上在已經營部落格 5 年的情形下搞搬家是需要很大的勇氣的，當然也可能只是因為愚蠢的關係... XD

會決定部落格要搬家的首要原因是因為前陣子系統硬碟陣亡後，一時間找不到/想不起來把 SnipSnap 的 Source 塞那邊去了。沒了 Source 就沒辦法再加新功能，所以開始考慮搬家的問題。

決定要搬家意謂著得把過去所有的文章統統帶到新家，但是由於 SnipSnap 是一套極小眾化的部落格共筆系統，所以完全找不到任何工具可以快速的達成這項作業，於是退而求其次是自行寫小工具進行搬家。最原始的想法是將資料庫內的文章記錄全部翻出來後轉成 Blogger 的備份檔案，這樣只要直接 Import 馬上完成辦家作業，任務終了！

有了方向就開始進行測試了。弄了幾篇文章後匯出成 Blogger 匯出備份檔，東刪西砍後弄了一份假檔案去玩匯入功能，先是被 Blogger 吐槽說不支援別人家的備份檔，再修改後的測試則讓 Blogger 吐出一串奇怪的錯誤訊息。查詢過 Google 後確定應該不是因為我這個簡化過的備份檔的關係（難不成大家都有偽造備份檔的習慣？），顯然這個想法的可行性有執行上的問題...囧rz

雖然生出 Blogger 可用的匯出備份檔是個問題，但實際上 SnipSnap 儲存在資料庫內的資料和頁面上顯示的內容也因為 Macro 的存在而有極大的差異。因為沒辦法自行呼叫 SnipSnap 內建或自行開發的 Macro 去解析原始資料，很快的便把腦筋動到內建 RSS 輸出功能，至少從 FeedBurner 上可以確定產生的 RSS 檔已經將所有 Macro 、Filter、Formatter 等等都套用過了，更重要的是 Blogger 就是收這種 HTML 格式成為一篇文章的。

不過有點可惜的是內建的 RSS Servlet 只能輸出首頁的指定筆數資料，為了能夠倒出所有的文章內容，我必須安裝修改過的 Servlet 到 SnipSnap 內。這個問題不算難，確認那個 class 才是系統用來轉換 RSS format 的部份則花了點時間。最後實際執行 RSS 匯出的時間好像才 30 秒不到而以。

有了所有文章的 RSS 檔後就可以開始匯入了。於是我開始搜尋 rss2blogger 這個關鍵字，還真的在 Google Code 中找到一個 rss2blogger 開源專案，可惜的是他完全沒有記載怎麼使用。

之後，我決定自行開發匯入工具，本來名稱就叫做 RSS2Blogger，不過因為和上面那個開源專案名稱衝突，所以實際上真正 commit 進去的名稱叫做 RSS2Blogspot ，對！這是 Blogger 的另一個名字。

之所以需要自行開發匯入工具的主要且唯一的原因在於必須更正原本指向 SnipSnap 內其他文章的連結。如果使用現有工具直接導入 Blogger.com 的話，後續顯然得要花上更多的時間去修正所有文章中的連結，連結問題一直是所有搞部落格搬家工程的部落客心中最大的傷痛。

RSS2Blogspot

初期對這個匯入工具的想法除了採用 Google Data API 外，在功能上應當要具備以下功能：

可以設定是否存為草稿
可以濾除指定字串
可以標示出該文章有 Blog 內部參考連結

符合以上要求的第一個版本就是以下這張圖的執行畫面：

匯入一些文章進行測試後認為程式碼部份應該可以再美化些（最後還是一樣醜），功能可以再增強些（還好達成了），以及訊息應該改回英文。想要只顯示英文的原因在於先前的 ass2srt 工具因為都是中文字結果造成網路上一些外國朋友使用上的問題，也許用一些不太工整、破破的英文訊息就可以讓這個工具活久一點（ass2srt 比我想像的活的還久）。

正式上傳到 Google Code 的 rss2blogspot 就是修改過後的版本，它提供了（在 RSS2Blogger 開發記錄中曾提到過）：

可以單篇或全部 RSS 內文章都指定為草稿：其實後來我都指定為直接發佈了！
將濾除功能改為替換功能：原本濾除功能就是一種替換作業，加上我有一大堆的表情符號要重新指定連結網址，所以這個功能就被強化了。
使用參數方式檢驗文章內部的連結。
加入分類標籤設定：因為原本的 rss 檔中就有 <category /> 元素，所以直接拿來當做文章分類標籤使用。

因為功能上的強化，所以我又回頭改寫了 SnipSnap 的 RSS 輸出，將所有表情符號的對照表及內部連結格式等資訊統統直接輸出到 rss 檔案內，這樣子當開始搬移 Blog 文章後需要再檢核的項目就會大符減少。

匯入前檢查

至於實際上在匯入的時候，我會先檢查 rss 檔內部的發佈時間及文章標題是否正確。在早期發文習慣不良時是有少數幾篇文章沒有捉到文章標題的。另外也會針對文章內容是否有保留價值進行篩選，因為早期好像真的有一些無病呻吟的搞怪文章，這些後來都決定予以放棄了。

至於什麼時候可以搬完呢？我想應該還是會花上 1 ~ 2 個月吧！畢竟人懶的時候會忘了要上傳文章... :p

應用

因為目前 RSS 資料是如此的容易取得，這個工具的應用似乎也挺有看頭的。舉一個最最簡單的例子來說，這個工具可以協助建立一個 Blog 備份站台。只要在原本的 BSP 中編寫完文章，然後捉下 rss 檔後馬上就可以再 Post 到 Blogger 內。除了一般的部落格文章外當然還可以用來處理別的資料類型如 picasaweb / flickr 的圖像記錄，只是這需要再修改程式進行客製化就是了。