2012年7月16日 星期一

GNOME.Asia Summit 2012 香港遊之簡報釋出

Standard
最近因為忙錄,遲遲未寫下今年六月初飛去香港(Hong Kong)參加 GNOME.Asia 2012 的心得,以及將當時在活動中的簡報檔釋出。:-)

對一個台灣來的人而言,香港不會讓人感到陌生,若不說新發展的地方,走在街頭,讓人有走在台北西門町的感覺,或是像台灣一些繁華的老市區以及夜市,站在路中央看過去,當下可以感受到早期台灣和香港之間的微妙關係,其共同點難以言喻。事實上,除了廣東話,還有那些銅板和五花八門的紙鈔外,沒有什麼會讓台灣人不習慣的地方。

話說回來,今年的 GNOME.Asia 2012 是在香港城市大學舉行,據當地朋友所說,這是一個與大型商場(百貨公司)纏綿的學校,由於學校、商場和交通樞紐的動線很密切,走在裡面,你會感覺到商場就像學校的一部份,走沒有幾步路,就會走入了商人的魔掌,錯進了名牌服飾的專櫃。

不過,身為一個宅宅開發者,當然不會被這些名牌服飾所迷惑,它們是嚇不倒我的!活動,當然才更重要!

我能了解,很多人在今天看到 GNOME 幾個大字就興趣缺缺,GNOME 讓大家又愛又恨,許多人不喜歡 GNOME 3 將桌面大改,像是 Linux 之父 Linus Torvalds 前些日子跳出來劈天蓋地的砲轟;也有很多人(像是我)對於許多元件被改壞或是效能不彰而感到很不悅。但由於歷史因素,太多人無法逃脫出 GNOME 所設計出來的大框架,就算你不想用 GNOME 的桌面環境,在 Linux 等 Unix-like 系統中,你還是免不了要去使用基於 GTK+/GLib 所設計的軟體,可以說 GNOME 無處不在,已經不是單單『桌面環境』一詞可以概括。

喜不喜歡新一代的 GNOME 桌面環境是其次,對於我而言, GNOME 是一座作業系統『操作機制』的兵工廠,他生產了太多元件讓我們可以自由使用,然後提供方法讓使用者和開發者可以用『人的角度』去控制作業系統。所以,如果你真的不滿意新的 GNOME 圖形介面設計,自己將 UI 打掉重練也不會是件難事。

這次去香港參加活動,見到了不同地方的開發者和使用者,尤以『中文輸入法(包括輸入框架)』這個議題特別引起討論。這些同是非英語系的 CJK 開發者和使用者們,有頗多的交流。雖然有些議程全程是以廣東話進行討論,我完全聽不懂,但好在有些坐旁邊的香港朋友自動自發充當即時翻譯,還順便介紹了許多當地輸入法開發者的來歷,讓我也能聽懂他們在討論什麼東西。(由此可見中文這語言多難,雖然都是用中文字,但你頂多只能看的懂,卻聽不懂)

至於我,在這次活動中,介紹了以 Node.js 開發現代桌面程式的解決方案,以及我正在做的開放原始碼專案『jsdx-toolkit』。簡報也在此公開供各界取用:
 

後記

為了公事,此行我也順道從香港搭地鐵去了深圳一趟,其中通關、走老遠再通關,回程還錯搭了一班深圳當地的公車,花了好幾個小時繞了一大圈,也算是遊了深圳,但累垮了我的雙腿和屁股。

此外,這圈子真的是很小,活動上也碰到了在 OpenSUSE Team 的開發者(前身是 Novell,OpenSUSE 現在獨立運作),由於我過去也在 Novell 待過,所以有許多共同的話題。:-)

2012年7月7日 星期六

Node.js v0.8 大變革?!Native Module 開發者的福音!

Standard
最近 Node.js 推出了 v0.8 穩定版,除了改善 I/O 的效能和一些 API 外,最大的變動就是跨平台開發環境的改進。包括了決定徹底使用 GYP 取代 node-waf(wscript)、宣布 libev 將死。或許,這些變動這對大部份的 Node.js 使用者來說不是什麼問題,但對於我們這些寫 Native API 和底層的開發者來說,關係到自己程式能不能跑在未來 Node.js 的新版本上,而且產生了很多移植性的工作。但是整體來說,好處其實大於壞處,因為以後我們的程式更容易跨平台了。

轉用 GYP

GYP 是 Google 發展出來的 Build script tools,就像是傳統 Autotools、Makefile 或 CMake 這類的工具。GYP 最早被應用在廣為人知的 Google Chrome/Chromium Project ,是個跨平台的解決方案,這也是為什麼 Node.js 決定要採用的主要原因。

在以前,不同的平台上,你需要為 C/C++ Addon 製作不同的 Build script,沒有統一的方法和途徑去設置和編譯程式,這讓跨平台的工作非常麻煩。使用 GYP 後,可以大幅減少這樣的問題。

棄 libev ,轉用 libuv

首先,有一點要注意,Node.js 開發者打算在下一個穩定版(應該是 v1.0)拿掉 libev 的支援,所以請所有的開發者盡快轉用 libuv。

libev 是 Node.js 在非 Windows 平台上所使用的 Event loop 解決方案,讓 C/C++ 開發者可以開發 Event-driven 的程式,除了可以用來監聽 FileSystem 等用途,也更容易整合 Thread 進 Event-driven 的設計模式中,要是你有印象,GLib 其實也是類似的解決方案之一,只不過 libev 更為輕量。不過, libev 主要還是被應用在 Unix-like 的系統上,若 Node.js 要支援多個平台,在其他系統上,就必需尋求別的解決方案,如 Windows 的 IOCP。

而過去這樣的情況,對我們 Node.js Native Module 開發者來說,是個莫大的挑戰,你必需在不同系統上,採用不同的寫法,導致開發上很困難。所以 Node.js 自行開發了 libuv,包裝了 libev 和 IOCP 等機制,讓所有的開發者,只要統一使用 libuv API 即可,不用再管跨平台的問題。

換句話說,如果你直接使用 libuv,在 Linux 等 Unix-like 的系統上,其底層依然還是使用 libev,如果你是在 Windows 上,則底層會使用 IOCP。所以,與其說是棄 libev,其實是避免開發者直接使用它。

libuv 直接支援 Thread 操作

在 Node.js v0.6 以前,libuv 還並不支援直接的 Thread 操作,若你要達成這樣的需求,只有使用 uv_queue_work() 去模擬,不然就是要使用作業系統原生的 Thread API。不過,若直接使用作業系統原生的 Thread API,也同樣有跨平台的問題存在,所以 libuv 在新版中已經提供 Thread 的包裝 uv_thread_t,也提供相關的 API,讓開發者使用。