星期四, 十二月 31, 2009

My life in 2009

雖然之前都沒寫過,但前幾天想、今年或許是個值得來個 yearly review 的一年。寫行事曆這件事情一旦養成習慣,回顧時也真的挺方便的。

工作

今年一月到四月,我在法鼓大學籌備處工作了一段時間。那段時間過得還不錯,也藉此機會把一直怕離不開的中研院職務轉為了兼職。雖然後來的離開有點意料外,但對比當時的時機也只能說一切都很巧、在無法負擔的時候解除了負擔。幾個月的時間裡面,我們完成了關於數位公益相關的課程規劃。就不說對學校如何,對自己來說是蠻有幫助、讓我在非營利組織的經營上有時間多思考一點,這大概是在這工作中最大的收穫之一。

XXC

因為法鼓大學的職務,所以在中研院創用 CC 計畫這邊自年初起轉為兼職,7 月之後也有新同事來接替我原本的工作。這讓我比較踏實一點,因為你知道、我一直覺得自己在程式這方面的興趣早在大三到了盡頭,接下來不為自己生活所需寫的東西,幾乎可說完全提不起勁。雖然在 CC 相關的數位授權表述資訊這方面,的確是看了不少東西,但對於怎麼實際讓大家得以應用,我想我最好的能力並不在「寫程式、管主機」上。

Pei-yi on Creative Commons licenses

因此八月起,我的職務有所變動。新的職稱「Developement Manager」是老闆在社群事務與技術研究方面折衷下希望我做的事情,而明年的工作規劃也大部份是我自己提的東西。對於自己提的工作,其實我有點擔心,因為其成果並不容易評估。希望到時不會很後悔就好。關於我的工作規劃,我有稍稍在先前的文章提過一些,歡迎有興趣的商業組織來聊聊。

今年最後這兩個月,我幫中研院內的 myID.tw 辦了一個推廣活動,我對自己的評價是:成果不佳、思慮不周、執行尚可。這說實在是有點殘酷的評論方式,而且「成果」從另一個角度來看其實非常好,但最終不是我自己原先就推測得到的部份、讓我對自己的思慮能力打了不小的折扣。或許這是因為我自己唯一還敢說上兩句的就是思慮吧?因此出現大範圍誤差時,最不能原諒我的,就是我自己。但總之,套句 ilya 的話來說,「你就當做你已經爆炸了。」Anyway,第一次受薪做這類行銷推廣工作,離「技術人」這個錯誤印象遠一點讓我挺開心,希望以後還有機會做這樣的事。

IMAGE_384.jpg

上面看完,不曉得讀者有沒有發現我的 5~10 月是半薪狀態?法鼓的計畫結束後我並沒有很積極找新工作,也不想跟老闆討論在中研院轉回全職的事情 -- 請不要因為看到這句打消你進中研院的念頭,中研院真的是個研究的好地方,大家也都很好,我覺得最不好的是我自己。

但這幾個月也並沒能夠閒著… 雖然跟原先「就休息一陣子吧」的期望差異不小,但在「週休五日」外貌的背後,我接了家教、兩個「不大,但太懶,所以做得半死」的小案子。所以其實還是挺忙的… 說「太懶所以做得半死」好像很矛盾,但如果你知道我就是因為現在還不想做、所以才在打這些文章,大概可以想像得到 Deadline 靠近時沒日沒夜的狀況。

要算工作嗎?社群

這方面的事情雖然不算工作,但差不多也就是工作了。

IMG_1099

MozTW 今年比較有進展的東西包括 FoxmosaGFX.tw 網站開發、連續聚的形式固定(雖然一陣子沒辦了)、MozTW Lab 形式固定等等,也的確把工作(小幅地)分給更多人,還算是部分達到年前希望的「提昇社群成員參與」。其實,MozTW 的事情我一向不太愧咎,畢竟大家都是義工,而過去擔心的、「位子被我佔住、結果真正想幫忙的進不來」的問題,也開始看清楚那只是自己的幻想,而不再感到負擔。做這種義工的協調,總是會感謝很多人,今年感謝第一名應該要頒給 Tim。本人在此聲明:個人認真地認為簡冠庭先生只是經驗不及我,判斷能力我們互有所補、而執行能力上他就高我一截了;在許多工作上,我相信簡先生應該可以是貴公司的得力助手、未來領導,明年他退伍的時候,接洽請早喔!COSCUP 是我今年另一個主力所在,議程組的部分著力不深、不過記錄組應該算做得還不壞?比較開心的是請 Toomore 帶了大家進來玩,讓一大堆 End Users 在 MozTW 的攤位玩就是爽。

COSCUP 2009 meeting

軟體自由協會部分,今年終於有點力氣把加入的最大理由「社群贊助機制」做了一些些,目前雖然只能接受五千元以上的捐款、但聊勝於無。接下來要處理的就是更小額的捐款了,不曉得自己這要拖到什麼時候,不過嫌我慢的請記得自己也要出手幫忙,所以就這樣吧。 XD

出國

Friendship from PH, students of law school.

今年有三次出國的機會,二月時因為 CC 亞洲區會議的關係去了菲律賓,是很好的體驗、也是第一次在「真正的國際會議」上有發表的機會。雖然老師說我講得蠻順,但其實不太好就是了… 重要的是認識很多人,也開始對於別人在做什麼有點概念。我非常期待見識韓國CC大量義工的操作方式,可惜原訂明年在韓國辦的亞洲 CC 會議應該會改成兩年左右辦一次,希望日後還有機會去看看。

SANY0244.JPG

第二趟是作為 MozTW 社群的一員,受邀到東京參加 Mozilla Gumi 十周年聚會,並發表社群在台灣的狀況。第二度在國際會議發表演說的機會來得如此迅速,好在這次表現得蠻好,應該可以打 80 分。雖然之前去過日本三次,但東京還是第一回,感覺跟早先的九洲、琉球、北海道差異不小,但或許是更適合一個人的地方,於是…

於是,就跟鐙緯在十一月又去了一次! XD 這兩次的進步就是我會開始花錢買東西了,雖然買的依然是平價品牌、但對於我這個出國也不會買紀念品的人來說著實是一大進步啊!終於在活了 28 年之後開始對自己的穿著決定要有點意識,如果在街上看到我穿得很差、請提點一下。喜歡日本的一大理由是氣候,或許我應該找個中緯度的地方居住。

超陽光店員

最後這一次出國別具意義,因為是第一次實踐「什麼都不規劃、當做放假就好」的花大錢度假法。說不規劃、其實還是有些目標,但可以隨意變動的感覺很不錯,也讓我首度在假期逼近結束時真正出現「好不想回去」的念頭 (以往都是「玩得很開心,好累,明天要上學/班囉!」這樣。) 我想我以後還是會蠻常這麼做的。

雜事

五月起離開住了一年出頭的新店,搬到了士林。雖然搬來第一天時,就覺得當初選擇這裡的理由之一近乎白痴而有點後悔,但實際住下來以後意外地喜歡,而且巷口的麵包店和豆花店的店員真是可愛(炸)。另外住這裡其實搭公車只要一班就可以到中研院,算蠻方便的,而且符合我「要不就超短程、要不就超長程」的搭車想法。


四月去了趟澎湖教召,做夢也沒想到還會有機會用搭軍艦的方式到澎湖去。說是戰鬥營不為過啦,休息一下也不壞;另外一個附加的好處是又與一些很久不見的朋友碰面,話題少了但感覺默契還在,蠻開心的。今年據說是首年度外離島的教召要去現地演練的,我也實際跟著自己的隊伍前往要防守的地方坐簡單的模擬演練。效果雖然不見得就能如何,但應該比以往紙上談兵好些了。


今年的一大進展是拼命啃東野圭吾的書,到目前中譯版大致看完了六成左右,相關感想與評論都在 Anobii 裡,歡迎大家交流。也因為 Anobii,我發現今年居然有看完近 20 本非關工作的讀物耶!真是太神奇!也多虧遙遠的公車距離、以及那幾天的教召 XD


說到教召,教召結束的當天回台北,就跟前女友分手了(也因此五月搬家),或許是今年最重要的事情,也因此重新獲得一次全盤檢視這個世界的機會。其中比較有趣的,是看著、甚至放縱自己的情緒變化來控制自己。有些意見認為沒有必要被情緒影響,不過說實在、如果其實清楚,那麼放縱不見得就有多壞,至少我現在很清楚怎樣的狀況下自己的確會失常、也確認了一些過去「正向思考」時一直沒去想的事。已經沒辦法用相同的態度生活了,但這就是代價,可以接受。


溝通

從 2008 年開始,我又重新進棒球場看比賽了,從國小開始支持的統一獅隊也很爭氣地在這兩年都拿下總冠軍。今年下半年起我進場還算不少,家裡也重新購買了加油棒、汽笛、衣服、帽子等東西,甚至總冠軍戰七場去了五場,人在台北卻參與了台南所有場次(包括史上最長一役),應該算是貢獻度還不錯的球迷吧?總冠軍戰最後一場緯來有清楚地拍到我,觀後感是:「幹,我又胖了。」

我想最近比較覺得生活無味的理由,八成是因為球季結束了 orz


今年進電影院的次數少得可憐,而且從大學畢業以後我就得了自己一個人無法進電影院的病。總計進場看了「天使與魔鬼」、「未來的未來」、「戀夏 500 日」、「福爾摩斯」四部而已,感謝饗樂卡讓我大多時候可以半價看片,不過這張卡絕對是加深我無法獨自觀影之病情的理由之一。在下半年開始發現找不到人一起去看以後,開始覺得有點懷念以前半夜自己跑去「包場」的時期,不過總之就是得了這種病,所以大家週一到週四看電影,可以找我喔!


我不工作然後寫了三個小時回顧,一定會有報應的,一定會。

星期六, 十二月 26, 2009

JeTEDsub 0.4

可以方便下載 TED Talk 字幕檔的 Jetpack 工具,如果你也有需要、請用

跳 Tone 一下討論 CC: TED 的影片跟字幕都是創用CC姓名標示─非商業性─禁止改作授權,我把字幕檔從 JSON 轉為 .sub,算不算種改作呢?就文檔本身而言或許是,不過我想這個授權條款更多只是要用在「翻譯的字句本身」。用程式轉換的方法基本上與智慧無關、任何人轉換都會是一樣的結果,那麼想來是不會被當成「衍生作品」了,不過在 CC 3.0 裡把「衍生作品」放寬為更廣的「改用作品」,這就讓解釋的空間大上非常多。這些多出來的空間,有人稱之為「法律風險」。

風險對每個人來說的意義不見得相同,也曾聽聞有律師建議不要使用創用CC授權過的作品。或許因為如此,商業作品裡看到 CC 作品被再利用的機率還真少(我有看過 PCHome 上面放 CC 授權的照片,nice work!)先前在某次推廣中我提了一下關於風險的事情,立刻引來極大的反應:你有這麼多不確定,那我們為什麼要用、這東西該不會反過來會害人吧?

誠實地說,因為缺乏判例,在法律遊戲的世界裡 CC 確實有不少不確定因子:商業性該如何判斷?改到怎樣才叫做改用作品?組織內部使用算不算散佈、是否該用相同授權條款分享?萬一我用了結果對方反悔怎麼辦?… 諸如此類的。不過我自己其實總很想講一句也很實在的話:

「即便如此,沒有創用CC這種『放話條款』,情況只會更差而已。」

我們生活四周充滿著侵權行為,扣掉刻意為之的那些,其實也有不少根本是誤觸法律。如果你小學也用流行歌曲跳過早操、如果你也曾在簡報裡放別人的照片、如果你在餐廳吃飯時也一邊看著店家接了大喇叭的電視,這些都太可能已經侵權。創用 CC 不會是萬靈丹,硬要求他背負一些東西就有點太過。

很遺憾地,現在你想懂創用 CC 這類授權條款,還是要碰觸一大堆的法律文字;很遺憾地,大部分的時候碰上問題,你還是得找律師。不過如果你是有意識地接觸與了解這些東西(而不是只想著「免費的素材哪裡找」),就已經更進一步了。

只是有感,就不貼 CC Blog 了 :P

星期六, 十二月 12, 2009

Porting JetQRCode from Jetpack to Google Chrome

(將 Jetpack 套件移植到 Google Chrome — JetQRCode 篇, 點我直接看中文版)

As you may know, Google Chrome browser announced their extension gallery a few days ago. The Google Technology User Group in Taipei hosted a Chrome Hackathon today, I was there and did something insteresting: porting extension between Google Chrome and Jetpack. MozTW is all for "open" (standards, source…) and not for a single product, at least that's the way I doing things.

So here it is, JetQRCode for Google Chrome 0.4, a demo about porting Mozilla Labs Jetpack scripts to Google Chrome.

I've learned a few about the difference between the two:

  1. You have to break everything in Jetpack script, which is in a single file, to several parts, like manifest.json, content_script.js / background.html, options.html, to make things work in Google Chrome.
  2. Jetpack is highly related to jQuery. To make life easier, you may want to insert jQuery as content script.
  3. HttpRequest to different domain is not allowed in content script, do it in background html, and pass the result to content if needed.
  4. You have to create a HTML page for user to set preferences, and storage the values in LocalStorage. (But you can't get the setting values in content script, pass them from background html if needed.) Also, there's only one data type in LocalStorage: string. Be careful if you're trying to use boolean or integer in it.
  5. There's no APIs for context menu in Google Chrome yet, you might need to do the same behaviors in different way.

IMO, since Jetpack is still in early stage, extension APIs in Google Chrome is more complete (though more complex) in many way than Jetpack. Porting things between the two framework is not as easy as I thought before, and need creativity to conquer the difference.

If you are a not-so-good web developer like me, I think Jetpack is easiar to create extensions to solve problems in daily life. But anyway, creating an extension in either Google Chrome or Jetpack is much simpler then in Firefox (without Jetpack), which results more productivity.

(To correct my poor English, drop me a line with patches, thank you. :)


因為我懶得把一樣的話重寫一次了,所以這篇的中英文版大概只有重點一樣、內文會差很多 XD

我原先以為讓 Jetpack 與 Google Chrome 互通套件不算很難,但今天參加 Taipei GTUG 的 Google Chrome Hackathon 時實作一下稍稍有點改觀 —— 的確不難,但是有些東西是比想像中麻煩些。所幸最後仍有斬獲,所以各位親愛的 Google Chrome 使用者、這裡是 JetQRCode for Google Chrome

拜雙方都遵循網頁標準所賜,其實原理跟很大一部份的程式碼依然相同 (是說我大多都用 jQuery 就是了… 懶惰鬼!)。有些經驗我想還是蠻值得跟大家分享一下,但中文版我想首先講結論:結論是…

  1. Jetpack 真的比較好寫 (XD),對於像我這種沒有很精的人來說可以輕鬆愉快地達到效果,相對來說 Google Chrome extension 就要考慮比較多架構上的問題 —— 或許是因為得拆成數個檔案吧?有些事情要在哪裡做,得先就權限等問題考量一下。
  2. 無論你喜歡哪個,兩個都比原來 Firefox 的套件實作方式輕鬆許多,當然也大勝 Internet Explorer。 (Opera 跟 Safari 沒研究)

好,那麼柏強在這次的遊戲中學到什麼呢?

  1. Google Chrome 的套件,要完成一件事情就算程式碼再簡單也會需要兩個以上的檔案,例如 manifest.json、content_script.js / background.html、options.html 啥的,所以單一檔案的 Jetpack 要移植過去就要好好想一下該怎麼拆程式。
  2. Jetpack 內建 jQuery,很多事情也跟 jQuery 息息相關,所以移植到 Chrome 時、方便起見先把 jQuery 塞進 content script 比較好。
  3. 在 Google Chrome 的 content script 裡不能做跨網域 HttpRequest,不過background html 沒問題,所以如果需要的話就在背景做、然後把資訊傳到內容去
  4. 兩者設計哲學中大不同的地方之一是偏好設定,在 Google Chrome 裡你必須自己寫整個 Option 頁面,也要自己把設定值存進 LocalStorage —— 相對自由當然也相對麻煩 (而且從 content page 裡目前還沒辦法直接拿設定值喔!記得從 background html 裡傳。) 這邊我撞到的其中一堵牆是對 LocalStorage 不熟,不知道它什麼都是用字串存,如果要用布林值還是數字的麻煩注意一下
  5. 目前 Google Chrome 裡還沒有調整快捷選單的 API,所以有些效果可能要重新想想使用者可以運用的方法。

以上心得供大家參考,也希望網頁設計師們都可以來玩玩看這兩種比較簡單的套件寫作方式,發揮創意製作出一些好玩的套件。日後有機會再來試試把 Google Chrome 的套件移植回 Jetpack…

星期五, 十二月 11, 2009

更動授權方式為創用 CC 3.0 版

是的,又要改了。從發佈這篇文章起,除另有標註外,本站文字部份皆採創用 CC 姓名標示—相同方式分享 3.0 台灣版條款授權大眾使用。

由於先前提過的「不可撤回」特性,本站於 2008/12/15 10:01 AM 至 2009/12/11 01:50 AM 的文章亦採創用 CC 姓名標示—相同方式分享 2.5 台灣版條款平行授權,而於 2008/12/15 10:01 AM 前的文章再加採創用 CC 姓名標示—非商業性—相同方式分享 2.5 台灣版條款三重授權。

聽起來很複雜不過也是沒辦法的事情啊… :P

延伸閱讀

用 Thunderbird 3 玩 Google

Thunderbird 3 有非常方便的帳號設定功能,只要在一開始的精靈畫面輸入比較知名的電子郵件帳號服務提供商 (例如 Gmail),就自動幫你把該點該選的通通準備好了。不過呢… 如果只是這樣,那或許你跟我一樣會撞到一些牆,這邊分享一些設定上的經驗,也順便再度介紹即將現身的 Lightning 1.0。

如果你是信件數要用 G 當單位來計算的 Gmail 老用戶,那使用 Thunderbird 3 幫你設定 IMAP 之後可能會遇到幾個問題:

a. IMAP 好像沒用,收不到信?

請到 Gmail 設定的「轉寄和 POP/IMAP」裡確定已經有打開 IMAP 的選項。如果已經開了,或許代表你身處一個會阻擋這類連線的網路環境中 (例如公司…)?

b. 為什麼好像硬碟一直在跑…

有很多原因:

  • 在預設值中,Thunderbird 會把「所有」的信件都收回來電腦裡當個快取 (這快取真大…),所以如果你是老用戶,想像一下 4G 的信件在空中飄…
  • 由於 Gmail 的特殊 IMAP 實作方式,每一封信都有可能有不同的「分身」出現,例如一封信剛寄到的時候就會同時在「[Gmail] > 所有郵件」以及「收件匣」裡出現;要是設定過自動上標籤的話、還會有更多分身,因此即使信件總量是 4G,實際上要收的可能是 5G 或甚至 8G 的信…
  • Thunderbird 3 的搜尋功能大躍進 (非常值得一試),代價是為了製作搜尋索引要耗掉不少硬碟空間。以我的 4.7 G 信件為例 (在 Gmail 裡這樣顯示,實際上因為前一點的關係,可能不止),整個索引結束後 Thunderbird 個人設定檔資料夾佔去了 18G 的空間 —— 你沒看錯,就是十八基嘎。我後來有做點動作讓整體空間下降到大約 6G (等下會說明),如果經常需要搜尋信件、或許這是值得的,只是一開始硬碟頻頻亮燈就免不了了…

要跑多久?主要看網路速度而定,有得等了!還好這期間還是可以用 Thunderbird 來收發信,只是「搜尋」無法找到所有信件而已。

c. 我遇到了「Account exceeded bandwidth limits. (Failure) 」訊息,然後無法收信了?

其實這才是我寫這篇的原因,如果你還沒有開始用 Thunderbird 來收 Gmail IMAP 的信件,建議先看完這段。

剛說了 Thunderbird 會把所有信件都下載下來,那很容易在使用不久之後就碰上 Gmail 自己對 IMAP 設的流量限制了。遇到這個問題後,會有數小時到將近一天的時間無法用 IMAP 收信。

這個時候你什麼都不能做,只能回去用 Gmail。

有沒有解法?目前沒有很好的方法,不過我在網路上搜尋到一篇文章提供了一個不錯的意見:有些人 (例如我) 在存取 IMAP 時,並不需要「所有郵件」跟「收件匣」之外的任何資料匣 (也就是標籤),那為什麼不把他們隱藏起來呢?這樣可以大幅減少信件往來耗費的頻寬,且既然可以用搜尋方式找到任何想找的信件,那「資料匣」的必要性就降低很多了。

在 Gmail 實驗室裡就有「進階 IMAP 控制項」,首先將其啟用:

接著到設定中的「標籤」一頁,我只勾「收件匣」、「寄件備份」、「所有郵件」及「垃圾桶」,其他全部取消。

這麼一來日常使用中與主機之間訊息來往的機會就會稍微減少一點,「可能」也比較不容易撞壁。

請參考 fauzty 對這點的看法,刪除郵件部份我還沒有驗證但他說的應該是對的、資料匣的部份看各人的習慣如何。

d. 我把寄件備份跟垃圾桶那堆也都取消了!

那… 你可能會發現信寄出去時老是卡住,因為本來 Thunderbird 想存放寄件備份的位置被關掉了 XD 刪除郵件倒是還可以用,不過在 Gmail 那邊會多出現「[imap]/刪除的郵件」這種標籤。有兩條路可選:

  1. 把垃圾桶跟寄件備份打開
  2. 調整 Thunderbird 存放郵件的資料匣

第二種方法要到「編輯 > 帳號設定」 (在 Windows 跟 Mac 上應該是 「工具 > 帳號設定」) 去,點選左側面板 Gmail 帳號下的「備份與郵件匣」一項,把 IMAP 中已經隱藏、信件該丟到本機資料匣的東西都選好即可。 (例如下圖中的「草稿」跟「範本」就是存在本機資料匣。)

「垃圾桶」的設定則在「伺服器設定」一項,一樣是看你 IMAP 有沒有把垃圾桶隱藏起來而決定要放到哪兒去。

e. 好,信件沒問題了,可是 Gmail 的連絡人資料不會一起過來…

那… 就用 gContactSync 把它們叫過來吧,裝完以後在「通訊錄」的選單中可以設定啟用,目前要同步的通訊錄名稱請用英文設定。

f. 我想要有 GMail 實驗室裡的「Google 日曆小工具」

那麼你需要的是 Lightning 套件,也就是 Mozilla 行事曆軟體 Sunbird 的「Thunderbird 雙鳥整合版」。安裝後就可以在 Thunderbird 旁顯示接下來幾天的預定行程,加上 Provider for Google Calendar 就可以輕鬆與 Google 日曆同步!

在 Thunderbird 3 裡,Lightning 的行事曆將以分頁的方式呈現,操作起來比以往更直覺些,搭配 Provider for Google Calendar 也支援直接設定以簡訊方式提醒行程。唯一的缺點是目前還沒有給  Thunderbird 3 用的「正式版本」,你得自己安裝 Lightning 的逐日建置版 (Nightly,每天都會更新的超級測試版) 才行,這畢竟還是測試用的、在這邊就不提供連結了,有興趣的可以等 1.0 版正式出爐,屆時應該也會放入由 Sun Microsystem (以及包括小弟在內許多早期貢獻者) 協助完成的中文語系。

星期四, 十二月 10, 2009

JetQRCode: create QRCode with content on web page

Another Jetpack extension :)

JetQRCode

JetQRCode is a Jetpack extension which can generate QRCode. With JetQRCode, you can easily get QRCode of…

  • (shortened) URL of current tab
  • selected text

And you can choose…

  • the output encoding of the QRCode
  • the image size, from 150px to 500px

Install JetQRCode from Jetpack Gallery. If you don't have Jetpack in your Firefox, Jetpack Gallery will install it first.

For more information on JetQRCode, please check the project page on http://www.bobchao.net/jetqrcode


又見 Jetpack 套件… 我真的愛上它了!JetQRCode 是可以拿來製作 QRCode 的 Jetpack 套件… 不知道 QRCode 是啥?蘋果動新聞全靠它啦!有了 JetQRCode,你可以:

  • 製作目前網頁網址的 QRCode
  • 製作選取文字的 QRCode

接著拿出支援 QRCode 解碼的手機一掃,資訊就跑到手機上囉~

你可以到 Jetpack Gallery 安裝 JetQRCode,關於這個套件的使用方法、未來規劃等等的事項則請參閱 http://www.bobchao.net/jetqrcode

明年 Jetpack API 完整一點再來辦開發熱鬥會 :) 現在如果你有興趣討論的話,可以參加每週一晚間在生態綠咖啡的 MozTW Lab 台北場,我、小 B、Bryan 都有玩 Jetpack。