國三還是菜鳥一枚

壓縮 Firefox 中的 sqlite 資料庫（MAC版）

2009-07-04T03:03:51-07:00

加快你 mac 啟動 firefox3 的速度！

根據Nelson大神的這篇文章，可以藉由壓縮 Firefox3 profile 中的 sqlite3 資料庫來提升啟動 Firefox3 的速度，由於該文中提供的方式是 Linux 版本的，這裡我提供一個可以在 Mac 下執行的 Python script:

使用方式，將此 script 貼在檔案中，並將檔案存成 *.py 檔案（如：compress.py），然後在終端機執行：

python compress.py

即可完成壓縮的動作。當然，你的系統中必須先安裝 sqlite3 才能執行這段 script 。

Update: Linux 下的話，可以修改路徑後再使用。

Android 釋出 Native Development Kit

2009-06-25T18:36:29-07:00

覺得應用程式跑在 Dalvik 虛擬機器上太慢嗎？那就用 Android NDK 自己寫 C/C++ code 來加速吧！

Android 的官方部落格發佈了釋出 NDK 的消息，別於 SDK 的地方是，因為一般 Android 上的應用程式開發時是使用 Java 程式語言，再透過 SDK 建置成 DEX bytecode 在 Dalvik VM 上執行，而今天釋出的 NDK，是讓開發者可以使用 C/C++ 語言寫出可以在 Android OS 上運作的函式庫或是透過 JNI 讓原本用 Java 開發的應用程式能直接呼叫這個用 C/C++ 寫成的函式庫。

目前 NDK 已經開放下載，想要使用 C/C++ 在 android 上開發的人可以開始研究要怎麼利用這個部份了。

雜談 Web（二）：免費還是等於買不到…

2009-06-19T08:24:22-07:00

是啊，大家都喜歡「免費」，但免費真的有得到比較多..？

這幾年大家都看著 Web2.0 喊得很熱，一個個網站開始林立，而且每個網站都打著「免費加入會員」、「免費使用」…的口號，藉此吸引使用者上門，但架設網站、寫網站應用程式都不是免費的，所以網站經營者不管是要自己獲利也好，還是僅僅想讓網站撐得下去也罷，皆無不努力去想、去嘗試很多方法來募得資金、找到財源，因為在大家都免費，使用者也養成「服務就該是免費」的心態下，經營者不太可能直接向使用者收錢（尤其是剛起步的網站），所以最常見到的方式就－－在網站上放廣告。

在網站上放廣告有很多種，一種是利用 Google AdSense、BloggerAds 這類工具，或是直接向廠商拉廣告，在網頁找個區塊把廣告放上；或是將網站會員的屬性作分析、整理，然後針對不同的會員屬性來做所謂的「精準行銷」….不管是哪一種方式，廣告就會儘可能地出現在你必經的操作動線，愈缺錢的網站撒得愈多。

所以人力不足的網站經營團隊會選擇什麼策略？是會花時間設計網站、包裝服務、優化效能？還是會去想怎麼切割版位賣廣告、整頁廣告、置入性行銷？開發團隊要活下去，網站要撐下去，當然是往後者的方向走啦，服務品質下滑也只是剛好而已（君不見某某某站不就是如此嗎？）。正所謂要使用者付費是要了使用者的命，但使用者不付費開發者就沒命啦！

就像強者我朋友，台灣 Mac/iPhone 界不是第一就是第二把交椅的 yllan 也在開發全世界最好用的打B軟體 — NallyTouch 時遭遇到類似的打擊（還好他還有很多熱血，我想他仍然會是熱血優質開發者，所以才有 hypo 這樣十分優質的服務），如果很多開發者都這樣被打擊下去，使用者又還能期待什麼好的服務？（就像是如果學開發的人都不去買書，只想看線上免費文件，那還有誰願意寫出私房秘技來分享給學習的人呢？）

看到這裡，讀者以為我要說：「大家可憐可憐網站主，多付錢給他們」嗎？並不是這樣的，我想說的是，如果網站開發、經營的人不重視應用程式的品質，更妄想能說服使用者掏出荷包裡的血汗錢，導致的後果就是網站主必須不斷地去拉廣告、犧牲使用者使用應用程式的體驗，最後當然還是失去使用者，因為你覺得使用者的忠誠度是免費的，最後還是得不到使用者的心….

雜談 Web（一）：「直接」的威力

2009-05-30T05:25:28-07:00

什麼樣的 application 值得作？我們又可以從現有的 application 學到什麼？

World-wide Web (WWW) 這個名詞早在 1990 年代就已經誕生，一開始多為各大公司的一個資訊媒介，使用者上網的目的很單純

「我要去某個 .com 的網站，因為我需要查詢那個網站提供的資訊。」

對個人來說，就算是做個人網站，大概也只是擺幾個連結、再弄個留言板之類的簡單幾頁的網站，不過單就要做這樣的動作，你就必須去學習 HTML 怎麼寫，或者是學習 FrontPage, Dreamweaver 怎麼使用，更要瞭解如何把「內容」放在網際網路上，總而言之是有些門檻的事。

然而隨著網際網路的發展，很多網站開始讓使用者「較輕易地將自己的『內容』放在網路上」，你可以很輕易有一個自己的「網站」，而透過一些介面把文章或圖片張貼在網站上，於是乎形成了 weblog (blog) 這樣的東西，此時又有人喊出 Web2.0 的口號，於是各種形式的「個人分享、個人發表」等等的東西就在 WWW 蔓延開來。

雖然現在 Web2.0 的發展似乎是從 Blog 的出現開始，但如果認為它成功的主因是「分享」的話，可能還不夠準確，我覺得應該還要再加上「直接」這個條件。

什麼叫做「直接」？試著想想，如果沒有網際網路，若是打算將自己寫的文章讓別人看到，你會怎麼做？投書、投稿或是出書？不管是哪一種要將文章放上媒體，除了要有機會接觸到出版社、文章通過編輯的賞賜等等繁瑣的步驟，最後作品才會被印刷出來，展現在世人面前。

但也許我只是時而興起寫了一點小說，或是一個什麼生活小智慧，抑或是今天吃了哪家餐廳覺得很開心，除了我的朋友外，我還想讓更多人看到我的文章，難道還要透過出版社才能讓我的文章接觸到讀者嗎？所以，早期在台灣，很多人會在 BBS 站裡寫，這比起跟出版社打交道來說要容易得多了，於是作者隨興所至地寫著，也在 BBS 站上找到了不少支持他的讀者，甚至最後還能把 BBS 的文章出版成書（我高中時就在 BBS 站上看「第一次的親密接觸」…）。正因為有這樣的風氣，所以愈來愈多人藉著這個平台完成他成為作家的夢想，因為這比跟出版社打交道的成本要低得多，幾年之後，這個風氣就漸漸從 BBS 轉移到了 Blog。

這就是「直接」的威力，想要提供內容的人有管道「直接」接觸到他的目標客戶、使用者等等。台灣最多人使用過的平台之一，莫過於是 Yahoo! 奇摩拍賣了吧！它一樣有「直接」的條件，他讓想販售商品（不論一手、二手）的人，不必去租店面、不必找通路、不必上架費、更不必被代理商再剝削一筆，他可以很「直接」地在這樣的平台上販售他的商品，這就是他吸引想販賣商品的賣家之魅力所在。

再來看看近日爆紅的 iPhone App Store，其實它也是在做一個「直接」的平台，只是角色變成了軟體開發人員，因為有了這樣的 marketplace，軟體開發者不必再經由人脈、通路、業務才能把自己的作品販賣出去（而且多了這幾道步驟，軟體的「售價」都不知道疊了多少層），寫好軟體就可以直接賣給使用者，所以愈來愈多的軟體開發者都對於這樣的環境（iPhone App Store, Android Market, Nokia Ovi Store）躍躍欲試，這也是因為夠「直接」，才吸引得了軟體開發者來開發軟體，壯大行動市場的聲勢。

其它像是人力銀行、租屋網，也或多或少在做這樣的事情，簡單地說，就是利用 WWW 提供原本需要「仲介」的服務，讓「商品」的製造者及使用者能夠「直接」面對，所以很多人說他們做的 Web 其實是一種 Service，就是這樣的緣故。

也許有這樣提供「直接」的平台很容易吸引到使用族群，可能你也開始在想要做什麼樣的 Web 來取代現有的某個需要仲介的服務，但其實要經營這樣的網站，你不希望這網站提供了一堆垃圾或是有害的「商品」或「內容」，後續的品質管理是一個很重要的問題；而同時你也會希望更多原本需要仲介的人，能夠瞭解這個網站的用途，所以需要去行銷你的網站。這些問題，我們下一篇文章再來討論。

（待續）

Google Maps API v3

2009-05-28T08:58:13-07:00

雖然新的 API 的支援還不是很完整，但很明顯整個 API 的架構變優了 :D

今天 Google Maps 發佈了第三版的 API，從官方目前釋出的訊息看起來，第三版的 API 有幾個特色：

增加並強化對 Chrome, iPhone Safari, 及 Android 瀏覽器的支援，期望可以在 mobile web 上有更好的使用體驗。比方說 iPhone 版就直接支援 multi-touch （在 web 上喔！），而 Android 則是會使用跟 Android Map 一樣的 zoom in/out 的 UI。
載入 Google Maps API v3 不再需要 API Key，這樣可以更方便開發一些 widget，也就不必根據 widget 所在的 domain 來申請 API key。引入函式庫時只要

<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false">

這一行就可以了，其中 sensor 參數是看要不要使用 device 上的 geo sensor 裝置（我猜是透過 gears ???）
重新以 MVC 的概念改寫 API 的架構，減少了函式庫的大小。
自動載入如同 Google Maps 網站上預設的 UI 控制項，不像 v2 還要手動加上需要的控制項，而且控制項也採用了新版的 UI。
API 放在 google.maps 的 namespace 下，而不再是以 G 開頭的名稱。
針對 Geocoder 進行大修改，以改善效能及 bugs。

關於新版 API 的使用，可以參考這份文件，跟原本第二版的 API 有些差距，原本的流程也有做修改，所以如果打算換用新版 API 的話，可能要將原本的 JavaScript 程式碼做一定程度的改寫。

090519 林威助代打全壘打

2009-05-20T00:34:59-07:00

希望趕快從代打變成先發啊啊啊

一直在草創

2009-05-19T10:04:56-07:00

為了避免一整個月都會空下來沒文章，所以胡亂地塞一篇好了 :P

這陣子有點忙，有的是實際要交差的事，有的是忙著提升自己能力所作的準備，而有的是忙著思考現在忙的每一件事究竟有什麼道理。

想著想著，我想到我的人生中經歷過不少「重新草創」的經驗，高中時本來學校沒有合唱團，但就在我進高一的那一年，合唱團就復活了（當然後來又死了）；本來台南一中是沒有資訊研究社（只有電*研究社，缺字請自行帶入），在我升高三時由跟著我們一起混的學弟草創了資訊研究社；到交大唸書時，住進了剛翻修好的交大九舍，後來好像也因此成為第一批用到 100M 宿網的大學部學生 :P；另外，交大南友會在我大一時好像根本上就已經倒了，結果強者我同學一手撐起它來，我就好像草創社員一樣加入這個社團；到台大唸碩士時，實驗室用到新蓋好的（半邊）系館（註），而擔任課程助教時，剛好碰到系上草創「優良助教選拔」制度…

想到這些經驗也蠻有趣的，但就從這樣的經驗看起來，我該是在工作上遇到一些「草創」的事情了….揪～～～竟會是什麼事情呢？真是挺令人好奇 && 期待的啦 XD

–
註：當時我幫實驗室佈了網路線後，擦了擦汗後說：「我看我根本可以去中華電信上班了」，雖然當時根本不知道中華電信在幹嘛…不過兩年多後一語成讖….

–
沒什麼內容的文章，補張正妹圖好了 :D

在 Android Dev Phone 1 上升級 Android 1.5 韌體

2009-04-28T00:37:21-07:00

中文使用者果然被邊緣化了啊….

今天從知名 Android 程式設計師 gasolin 那裡第一時間知道已經有 HTC 官方釋出給 Android Dev Phone 1 升級用的 Android 1.5 韌體，不過在升級前就已經在癮科科討論區那裡看到了一些升級後的消息，得知這份韌體並沒有中文介面（也就是沒有 zh_TW 的 locale，更別說中文輸入法了），雖然 Android 1.5 改進了不少部份，但身為一個中文使用者不免有些遺憾。

不過，身為一個開發者，而手上拿的又是 Dev Phone，那當然是要缺什麼就（盡量）自己搞啦（會用「搞」這個字，是為了區別「寫」，能用 hack 的就盡量 hack 吧 XD），天真的我認為只要寫一個 app 去改系統 configuration 的 locale 就能把中文介面打開。結果當我寫完之後，只有 Google Maps 有中文介面！！！其它的應用程式（包括系統）就一動也不動….我這才猜想應該是這些應用程式並未附有 l10n 的語言檔案，就算系統 locale 換成了 zh_TW，應用程式還是給你英文介面….

不過，還好部份應用程式有放在 Android 的原始碼中，於是我就自己動手 build 一些應用程式啦（如：瀏覽器、日曆等等），果然有放了 l10n 的語言檔案之後，中文介面就出現啦！

至於輸入法嘛….嗯，總之是有了中文輸入法可以用（比方說谷歌拼音輸入法），這裡就不多著墨了。

新版的韌體真的還蠻不錯的，也期待不久的將來，預計在台灣銷售的 android 手機囉。

Google Code Project Hosting 即將採用 Mercurial 版本控制系統

2009-04-26T19:09:27-07:00

目前還是邀請制，而且好像要去參加 Google I/O 的才能先申請到，好想用用看啊～～

根據這篇文章的消息，Google Code Project Hosting 除了原本支援的 Subversion 版本控制系統之外，未來將會加入 Mercurial (hg) 版本控制系統的支援，不過目前只有被邀請的人才能使用 Mercurial，這篇文章也就沒有試用心得啦。

最近在版本控制系統界（尤其是分散式版本控制系統）最火熱的莫過於 Git 了，也許大家都很好奇為什麼 Google Code 的 Project hosting 不是用 Git 而是用 Mercurial 吧！Google 官方有撰寫一篇文章來分析 Git 與 Mercurial 的效能，有興趣的人可以去看看為什麼 Google Code 會選擇 Mercurial，想看懶人包的….我直接把結論翻譯過來，那就是：「以 HTTP 為傳輸介面的話，Mercurial 比 Git 的效能好。另外，就是 Git 太複雜了。」

OSDC.tw 2009 的 GAEO 投影片

2009-04-18T07:32:08-07:00

今天有幸能到 OSDC.tw 的場子做 GAEO 的簡報。

我已將投影片發佈並且可以由此觀看：