2007年12月22日 星期六

Gmail 地址簿(Gmail Contact Book) for Firefox + GreaseMonkey

很久以前就聽過 GreaseMonkey(中文簡稱:油猴) 的響亮名號,但因為覺得「放在使用者端的 Script(GreaseMonkey 稱之為 User Script) 離開了有安裝的電腦後,就沒有效果了」,所以一直都懶得去嘗試。

直到 2 個星期前朋友給我 Travian 這個遊戲的「輔助工具 Script」之後,才深刻的瞭解到「User Script 的價值在於當下為使用者所創造的便利性,當便利性誘因夠大時,就算到每一台電腦都需要安裝,使用者依然會接受!」

自此,我就花了 1 個星期開始研究 GreaseMonkey 的 UserScript 到底能夠給使用者如何的便利性,或者說能夠賦予 UserScript 開發者何種的能力,讓這麼多人為之瘋狂。

在我安裝了許多大家分享出來的 UserScript 後,突然想到 MARU 之前告訴我的「不使用 Gmail 的理由」,那就是「Gmail 的收件人 E-Mail 地址要用打字的,但每次都記不住別人的 E-Mail 到底怎麼拼,要打收件人變成一件很討厭的事,特別是轉寄的時候,討厭死了!」。

於是我便去 UserScript.org 搜尋有沒有類似的 UserScript 可以用,但卻只找到了一個非常「簡易」的 UserScript,因此我以這個 UserSCript 為基礎開始打造我心中的「地址簿」。

不改還好,一改才發現它為甚麼寫得如此的「簡易」,因為 Gmail 的頁面組成根本就是一堆 iframe 的大雜燴,而在一堆 iframe 裡面做跨 iframe 的 DOM 與 EventHandler 操作,真的是一件十足令人沮喪的事...

幾乎所有本來可以用的 JavaScript 直接指定事件觸發函式的方法都變得不能用,所以只能乖乖的去讀 W3C 所定義的 EventHandler 的正規作法,為自己的觀念重新做一次正規化,最後才產出了這個 UserScript:



Gmail 地址簿 (Gmail Contact Book)

這個 UserScript 為您的 Gmail 在 收件者(To)、副本(Cc)、密件副本(Bcc)輸入框旁,自動加上一本小書。

當您點擊了這本小書後,將會在下方出現一個框框,並於框框中顯示您的所有聯絡人資料,此時您只要以滑鼠點選您要寄送的聯絡人資料,右側的輸入框中將會自動為您加上此聯絡人的資料。

從此寄送 Email 就在也不是一件需要考驗您記憶力的苦差事了!

安裝網址( English with install ):
http://userscripts.org/scripts/show/16784


原始碼修改自 [GMail Contact List]:
http://userscripts.org/scripts/show/10548

Address Book icons 使用 Michael Okeh 所分享之圖片製成.
http://okeh.macthink.org



相關連結:

GreaseMonkey 官方網站:
http://www.greasespot.net/

GreaseMonkey 官方 UserScript 分享網站:
http://UserScript.org


2007年12月21日 星期五

「FIRCH 很搞圍 2.0」開張摟~


說要搬新家已經好久了,這次終於下定決心把舊文章整理過後全部搬到新家來摟~

而且 BLOGGER 的文章可以自訂發佈日期的這個功能,讓我保存下來以前文章的發文時間,雖然真的很難弄,但完成後還是滿開心的!

這次搭配 MARU 幫我設計的新名片而設計了這個新版面,走素雅風格,希望大家會喜歡摟!


2007年7月17日 星期二

郁晨的朋友們,再會了!

我親愛的朋友們,謝謝你們這一年多以來的照顧,讓我從一個毛毛頭小子進步到變成一個毛頭小子~




這一年多來有許多的歡笑、快樂、汗水與淚水,一路從 4 人小公司成長到目前的 20 人,大家所做的努力是毋庸置疑的,期間雖然有許多人員的加入與離開,但總是維持著一個大家庭和樂融融的氣氛,而我始終相信「快樂的工作氣氛是成功的根 基」,這也是大家一起努力經營的結果!


希望大家在接下來的人生道路中,依舊能夠繼續扶持,朋友是一輩子的!我打從心裡珍愛你們這群朋友!要記得我喔~


2007年1月25日 星期四

文件格式的省思


什麼樣的文件格式才是好的?

是可以清楚的表達自己的思路與流程架構的格式?

還是可以符合大家所習慣的文件切割格式,如區分程架構圖與流程圖?

這是一場 隨性 V.S. 制式 的對決!



本來我認為只要可以表達出自己的思路與流程架構,則閱讀者就可以跟隨著我的思路在圖形中看到流程,也在流程中看到架構...但這似乎是行不通的!

因為要在一個圖形中同時表現出 流程(時序) 與 架構 似乎是不可能的事,更遑論閱讀者跟隨自己的思路...好吧...一切都是幻想,你嚇不倒我的!

最後隨性的文件格式中往往隱含了一個最大的條件,就是大量的口述說明!

因為隨著思路而行的文件往往都會省略一些作者認為「不重要」的部份,但這些部份卻時常是串起一幕幕場景的重要連接點,少了這些「不重要」的部份就像相聲演出少了【逗梗】只剩【捧梗】那樣的不知所云。



然而制式化的文件又因為少了交叉的表現方式而時常出現數份文件之間無法連貫的狀況。

例 如【軟體架構圖】中出現了一個區塊需要用到 Thread 與 Semaphore,但卻看不出來有什麼理由一定要用這麼複雜的技術,直到看到了硬體架構圖而且經過系統分析師的講解後才發現:「原來是因為輸出端只有一 個而且速度很慢,但多個輸入端卻需要即時收取資料,不能等待,於是就有許多 Thread 必須爭奪輸出端的使用權」。

然而這件事在大部分情況下都不會被正式的標注在文件上,因為軟硬體架構中都只標示【架構】,而流程圖只標示【流程】...而這個部份的解釋卻不屬於任何的制式化文件內容!

到底文件是為了看起來符合格式而寫,還是為了要清楚表達自己的意思而寫?



在我試著依照制式化格式做了一份文件後,我發現制式化文件還是有其優點的。

例如有一種流程圖可以利用縱軸的多列來表示多個 Process/Thread 而橫軸表示時間序。這樣的格式讓我終於嘹解到要如何表示出多個平行處理 Thread 之間的交互行為!在畫這種圖的時候也讓我更深刻的透析自己設計的流程是否有問題,進而提昇設計的品質。

目前我最想要做到的依然是:「如何在最少的圖形/文字中表現出最清楚的流程、架構與設計思路?」,請問有沒有人可以給我答案或提示呢?