Fred's blog

既然會成立新創公司，總有些自己的想法，也期望做一些和其他人不一樣的事，對我們而言，改變世界事小，留下長久價值更重要。也許你有點印象，筆者今年度到處給予的 Talk，多半都是與 Node.js 相關，也透漏許多正在執行的計劃。因此，有些人可能聽過筆者提及『JSDX Framework』，這是『 Mandice 』的長期計劃，也是將 JavaScript 落實在系統、桌面和嵌入式裝置的解決方案。 由於 JSDX 是一個開放原始碼專案，市場上也已經有一些產品和公司專案導入使用，但因為合約的關係，我不能透漏太多細節，所以本文將只討論些許技術細節。說到這，也許你還是沒什麼概念，但若是真要舉出最直接與其相關的專案，就是今年 8 月，於 COSCUP 一場議程中所公開的『JUICE Desktop Environment』（簡報檔詳見舊文： 【COSCUP 2012】閉幕！簡報釋出！ ），完全以 JavaScript 實作的 3D 桌面環境。 JSDX 包括許多元件，從 GUI Toolkit（使用者界面）、Multimedia Player（多媒體播放）、Network Manager（網路管理）到 Sound Manager（聲音管理）等，提供了各類系統控制或硬體相關的 APIs。程式開發者只需要會 JavaScript 語言，就可以使用這些 JSDX 所提供的 APIs ，開發各類應用程式或系統程式。 回應本文標題，JSDX 如果可以拿來開發桌面環境，當然也有電源管理相關的 APIs 可使用。所以在這邊我們要討論的元件是『 jsdx-power 』，你可以在 github 上取的他的 Source Code，亦或是直接透過 npm 安裝。 npm install jsdx-power 這邊簡單示範如何使用 JavaScript 透過『jsdx-power』命令作業系統休眠： var Power = require('jsdx-power'); var power = new Power; power.init(function() { power.suspend(); }); 後記 JUICE DE 的 juice-panel 電量顯示，就是使用了 jsdx-power，有興趣的人可以參考其 Source Code。

如果你原本是一個專業的前端工程師，或許在 Node.js 出來之後，便開始嘗試了 Server 程式的開發。然後發現，使用 JavaScript 開發 Server 程式的過程中，有很多的細節應該注意，尤其是碰上處理大量資料和 I/O 操作時，更要對 JavaScript 引擎的運作原理有一定程度的理解。因為，絕大多數的問題，都是出在非同步（Asynchronize）與同步（Synchronize）的機制上。 許多開發人員，都會認同在開發 Node.js 程式時，盡可能、甚至絕對不要使用『同步』的方法和 API，因為，那會打亂 JavaScript 事件引擎的運作，產生各種詭異的後疑症，而且非常難以除錯。如果你發現你的程式會莫明自己結束，或是程式運作的流程不如預期，可能就是掉入了『同步』與『非同步』的陷阱了。 如果你稍微翻過文件，就會發現，其實 Node.js 本身對很多的 API，已經同時提供了『同步』與『非同步』兩種版本供開發者使用。不過，雖然 Node.js API 都有提供『非同步』版本，但是有些根本東西，卻欠缺『非同步』的方法，像是本文標題所提到的『Array』，就是其中之一。 針對 Array 的諸多操作，最常見的莫過於 forEach 方法，用來處理每一個 Array item： var arr = [ 1, 2, 3, 4 ]; arr.forEach(function(element, index, arr) { // Processing }); console.log('Completed'); 然而，這個方法是『同步（Synchronize）』，也就是會讓整個程式阻塞，等所有 Array item 讀出和處理完之後，才顯示最後的『Completed』字串。 類似的東西，不少人也會使用純 for-loop 來實作，但也都是一樣的狀況： var arr = [ 1, 2, 3, 4 ]; for (var i in arr) { // Processing } console.log('Completed'); 想想看，如果 Array item 的數量相當多，又或者是每個 item 的處理時間相當長，整支程式會像死當一樣沒反應。要知道，讓一段程式跑太久，是 Event...

在普通情況下，整合 GLib Main Event Loop 和 libuv 不是件平常人會做的事，因為，一般人使用著 GTK+、Clutter、DBus 等等函式庫(Library)時，永遠只會使用 GLib 而不會使用到第二套事件引擎。但是，在 Node.js 中，其事件引擎並不是 GLib，而是使用自己的『libuv』，想同時運行兩套事件引擎是不可能的，所以這將注定我們無法以 Node.js 去引入 GTK+、Clutter、DBus 等函式庫來使用。不過，天下文章一大抄，世界上所有事件引擎的設計差異不大，在理解 GLib Context 的運作後，我們還是可以嘗試將兩者整合在一起，協同運行。 簡單理解一下事件引擎，其說白了就是一個跑到天荒地老的無窮迴圈，不停的去檢查是否有事件被喚醒。所以，由此可知，兩套事件引擎不能被同時跑起來，因為任何一個事件處理的無窮迴圈，都將導致另一個事件處理的迴圈無法正常運作。所以，首要解決的課題，就是讓兩個無窮迴圈可以同時運作。 為了解決這樣的問題，你可能會想到去使用 Thread (執行緒/線程)，只要在建立兩個 Thread，然後各自跑不同的事件引擎就可以了。但是這樣做，問題馬上就會出現。由於程式正在運作的過程中，事件數量相當多，事件被安插和喚醒的次數非常頻繁，這將導致兩個 Thread 之間很難維持穩定的資料交換，你得實作 Mutex Lock 等機制來達成 Thread-safe，更還要想辦法解決兩邊各類大小資料交換的需求。種種原因，都會造成兩個事件引擎大量的彼此等待，而效能不彰。此外，也不易同時控制兩邊的事件觸發順序，以及事件被喚醒時間的精確度，如計時器(Timer)。 既然使用 Thread 是不好的做法，是否有其他方式可以解決我們一開始的課題？解決方法是有的，從事件引擎的運作細節，我們可以發現一些端倪。 一般來說，大部份的事件引擎都包括了幾個部份： 從 Initial 出發， Event Loop 的迴圈每運行一次，都經歷了『prepared』、『Polling』和『Dispatching』三種狀態，若用白話來說，他們所代表的意義就是『已準備好事件清單』、『監控事件』、『喚醒、分配並處理事件』。 如果你去參考事件引擎程式碼，會發現在三個狀態之間，分別有『prepare()』、『query(...

就在幾天前，MongoDB 邁入了 2.2.0 的穩定版本。我們若回頭來看，MongoDB 一直到了 2.0 前後，比起早期版本，已經有長足的進步，並且支援了相當多的功能，也對規模化和資料庫系統管理下了很多功夫。對於大多數的資料庫應用，已經非常適合。 若你對資料庫相關技術有些了解，就會知道，當資料庫的資料發展一定規模程度，或是要確保系統不當機時，我們就需要用到 Master/Slave 的方式去備份和備援，當主要(Master)伺服器出了問題，次要(Slave)伺服器便即時補上，保持系統運作。但是，既然已經有 Master/Slave 機制，是否可以有更多台備援呢？更或者進一步，將讀寫分開在不同伺服器，以分攤流量和系統負載，並加速讀寫速度。而 Replication 就是這樣的機制，可以用來動態同步多台資料庫伺服器的資料，也可以當主要伺服器因故下線時，讓其他伺服器即時替補主要機器的位置。 在 Debian 上設定 MongoDB 的 Replication 相當容易，首先在想要變成主要(Primary)的機器上，打開設定檔(/etc/mongodb.conf)，並為我們的 Replication 群組命名（在 MongoDB 中稱為 ReplSet，一些書籍內翻譯成『複製組』）： replSet = mydb 重新啟動 MongoDB： $ sudo service mongodb restart 使用指令 mongo，進入 MongoDB 命令模式： $ mongo 於 MongoDB 命令模式中執行： # 初使化 replSet rs.initiate(null) # 加入自己的 IP 位置 rs.add("192.168.11.1:27017") 若是回應成功，請先稍待數秒鐘，等伺服器偵測和初使化。然後會發現 MongoDB 的命令提示字元從『SECONDARY』變成『PRIMARY』，此時，代表這台機器已經變成 ReplSet（複製組） 中的主要機器。 同樣的，你可以開始為 ReplSet 加入其他次要的資料庫伺服器： rs.add("192.168.11.2:27017") rs.add("192.168.11.3:27017") rs.add("192....

數個月前開始做一個計劃『AppHouse』，實作如 Google App Engine(GAE) 般的 PaaS，其志在打造自己的 Node.js 雲端軟體平台。然後發現，除了讓雲端服務可以在平台上跑起來外，資料庫管理也必需有個便於使用的機制和規劃，仔細想想，一個沒有資料庫配合的雲端服務，可沒有什麼太大的價值，於是，『DBHouse』便應運而生。 你可以在 github 上找到這個專案： https://github.com/Mandice/node-dbhouse DBHouse 起初的開發目的，是讓使用 AppHouse 架設以及開發自己雲端服務的人，可以很容易存取資料庫。此外，對我們而言更便於管理資料庫資源，面對許多不同的服務，不需要特別為他們開設資料庫權限，亦或是買許多硬體和主機，建立起許多 VM 並做各種安全性規劃。其實，如果把 DBHouse 的用途，想像成 Google 在做的事，就很容易明白：『在 GAE 上你可以使用統一的 Database APIs，存取 Google 提供的資料庫系統(BigTable)。』，同理，我們也是在做同樣的事。 只不過，學 Google 開發自己的一套資料庫太過於困難，不是一個可以達成的目標，所以我們仍然選用 MongoDB 當做 PaaS 的資料庫底層。僅管資料庫不是自己開發的，我們還是可以提供統一的 API，讓開發者存取。統一的 API 有個好處，若能做到當開發者在使用的時候，不需要知道自己在使用什麼資料庫，日後就可以在這 API 之後串接或替換不同的資料庫系統，有很大的彈性可以擴充。 當然，更遠大的目標是希望在一個 Table(Collection) 內，因應不同的欄位需求，而交由不同資料庫處理，更進一步發揮不同資料庫的特色。但是，這夢想遠大，技術上也有很多盲點待討論，所以能不能實現那是另外一回事，至少，短期內在我們的能力範圍和經濟狀況下，暫時無法達成這一步。 雖然 DBHouse 有這樣的初衷和夢一般的計劃，但不代表 DBHouse 一定得和 AppHouse 配合使用，更準確的說，他們本來就是獨立各自發展的專案，各自可獨立運作。說穿了，DBHouse 本身就只是一個 Database API，你可以在 Node.js 裡使用 DBHouse API 去操作自己的 MongoDB（目前只有支...

國內一年一度最大的開放原始碼（Open Source）活動，再次順利落幕。很多人都意猶未盡，所以每當活動結束，便會開始思考明年要分享什麼、反省今年哪裡做的不夠，有人會在活動過後的連續幾天，電腦上開著簡報編輯器，盯著空白的內容，靜靜的發著呆。可惜的是，最後總是因為沒有任何想法而放棄。一直到了明年 COSCUP 的徵稿消息發出，一堆人又開始拾起空白了近一年的想法，擠出一個題目，逼著自己在一兩個月內完成，上台發表。就如同學校的期中、期末考，沒有死到臨頭，大多數同學都沒有唸書的動力，也不會激發自己 120% 的腦力和體力。所以，Event-Driven 的開發模式，一直是在很多開發者促使自己進步的方式。 別以為兩個月時間很充足，大家都有外務、有工作、要過生活，所剩的時間實在有限，所以每當到了 COSCUP 的前夕，總是會聽到很多講者在拼命趕工的聲音。其實，這樣都還算是常態，頂多拼命一點，少睡一點，都還可以頂得過去。可是，今年一次給『兩個 Talk』，就真的讓人會虛脫到不行，還好，熱情能戰勝一切。:-) 由於今年活動承辦的分工方式比較特殊，所以被選上了兩個稿，分別是： JavaScript 全面逆襲！使用 Node.js 打造桌面環境！ 用最潮的 JavaScript 盡情開發 KDE/Qt 程式 前者是總結這一年來，我們團隊所開發出來的各種 Node.js APIs，並整合成為一個如同 GNOME/KDE 的桌面環境（Desktop Environment），並展示使用 JavaScript 開發出來的 Juice Desktop Environment（果汁桌面環境）。後者則是為符合 KDE 的議程方向，探討使用 Node.js 開發 Qt 程式的可能。 後記 退學不是件好的事情，請勿模仿。:-S

跳脫出前端應用之後的 JavaScript 語言，所遭遇的挑戰極大，至今還沒有一個非常好的開發模型和原則，讓人不免抱怨。因為沒有前人可學習，也沒有太多文獻可以參考，所以，為了讓自己能夠更快完全領會 JavaScript 在各種極端環境之下的開發情況，在這一年來，花了相當多的時間投入去做各種不同類型的 Project，從 Web service、Embedded System、System Programming 到各式雲端技術開發，嘗試從中累積更多用 JavaScript 打天下的經驗。唉，慣 C 都不慣 C 了。 不過，做了許多東西後，就會開始有機會重覆開發相同的功能，這時就會希望能重覆利用舊的程式碼，讓同一段程式，不用每次都重寫一次而浪費時間。於是，開始慢慢把之前做過的專案整理，然後整併許多功能，獨立出來變成一個個 Node.js 模組。 Courser 就是這樣被獨立出來的專案，而功能是為 Express Web Framework 提供一個管理 HTTP Routing 的方案。你可以從 github 上找到專案首頁： https://github.com/cfsghost/courser Express 範例的傳統做法，是每次增加一個 API 或頁面，就要更動一次主程式檔案(app.js)，以管理 HTTP Routing，相當麻煩，尤其當有許多人協同開發時，更多不必要的程式碼衝突便出現了。此外，管理專案中的 Handler 也是件麻煩事，因為我們總不可能將所有的 Handler 寫在同一支檔案裡，必須適當分類分檔，才能便於維護。隨著專案規模越來越大，需求越來越複雜，這便是件苦差事。 這些問題當然有解決方案，Express Source Code 裡的範例，就提供了幾種不同的方法，供開發者參考，只不過，這些方法大部份很簡陋、不通用，多半還是要靠專案開發者自行想辦法，開發一套機制，才能解決需求。因此，之前為了專案的需要，就實作了 Courser 去管理專案下的 HTTP Routing 和所有的 Handler，嘗試讓 routes 不要每次開發出來，都是這麼醜。 Courser 目前已經釋出 v0.0.2，你可以從 NPM 上直接安裝它： npm install courser 假設你已經會使用 Express Web ...

最近因為忙錄，遲遲未寫下今年六月初飛去香港(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 推出了 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 自行開發了 libu...

最近看到一些網友轉貼的文章，還有聽聞了一些朋友的創業故事，加上自己也是在創業，因此有感而發。其實，過去就一直想寫下『在我眼中的創業』，一方面重新整理自己在創業生涯中的思緒，另一方面鼓勵自己不能倒下。此外，如果可以，讓更多人知道創業的現實面，也不是什麼壞事。這邊要先感謝許多同是創業人的朋友，無論他們現在是否還在這條路上，都給予我很多幫助和啟發，更感激許多親身跳下去『證明』的人，讓我知曉許多悲慘的事實。 依然強調，我尚未成功，也還年輕，我說的話可能影響不了什麼人，也沒什麼說服力，只是單純地將我所見的一切，如實的描述出來。如果你對我所說的一切不以為然，如果你仍然覺得你自己原本想法是對的，請堅持自己所想，無論最後是成功還是失敗，開心或痛苦的，你都能因此得到實質的經驗和正面的回報。 因為我還沒成功，所以我不會告訴你怎麼成功，更不會告訴你創業一定要做到的成功守則有哪些，這些事我都沒有答案。如果你有這樣的困擾，你應該去問的是那些研究創業的部落客專家，或是書報周刊。在這我只會告訴你，我在創業中遭遇到或看到的問題。 首先，恭喜自己。經歷過兩年的努力，好不容易還活著，這是我是創業至今最值得開心的事。相信我，這是真的，在經歷過痛苦磨難、倒閉危機和理想於現實搏鬥後，你會非常慶幸，自己還撐的下去。這一切不像是某些知名的『談創業』部落格文章中，所輕描淡寫的這麼簡單，也不像書店架上滿滿的『各類成功學』所提到的這麼有跡可循，因為你永遠可能被任何一個創業的細節所打倒，一切是這麼出乎意料，現實中的『啊！你已經死了！』天天都可能上演。所以，如果你克服了這些細節，不管落地動作好看與否，你都應該先為自己鼓掌。 問一下自己，什麼才叫做『成功』？ 既然提創業，就得提大家都想要成功這件事。包括我自己，很多人不曉得 創業最中最大的問題，就是『不知道什麼才是成功』 。對許多創業人來說，看到 Facebook 有今天的地位會感覺到相當興奮，為自己『創業的理想』注入了一劑莫大的強心針。是的，因為你認為他是成功的，所以你感覺到了『我也有機會成功！』，夢想實現也近在眼前。 但是，我們應該先問一下自己，什麼才叫做『成功』？ 是上市上櫃？手上握有幾百億美元資產？還是不缺錢用？握有極大的權力？又或者是走到世界各地，都能有人認出你來？如果你回答不出來這個問題，那請試著去想個更簡單的問題，你認為 F...

既然要投入 JavaScript 的發展，一個很重要的目標就是讓 JavaScript 能被用來開發 Native 桌面程式。而為了達成這樣的願景，我們的團隊沒日沒夜的發展各類基礎技術和擴充底階 API，甚至是將以 JavaScript 開發整個桌面環境（Desktop Environment, 如：GNOME、KDE、LXDE 或 XFCE 這類專案）為終極目標。 當然，跳出瀏覽器之後的 JavaScript，缺少了繪圖引擎，所以要拿來做圖型化使用者介面，會更為困難。慶幸的是，前些日子發展出的 jsdx-toolkit 已經解決了大多數的問題，除了有 3D、動畫等支援，也已經有了許多現代桌面有的UI元件（如：Entry、Label、Button... 等），以致我們完全可以放心的開發屬於自己的圖型化應用程式。 不過，目前的情況，在手機、平板或是特定用途的嵌入式系統中完全夠用，一旦回到更為複雜的桌面環境下，就會遭遇到許多的問題。像是回到 XWindow 底下後，會遇到許多 X11 的視窗管理機制，其視窗之間錯縱複雜的交互關係，就是我們要處理的。尤其是當我們在開發桌面環境時，就會發現在一般的桌面環境下，使用者可能會同時開無數個視窗和程式，並且隨機又大量的切換使用，這迫使我們必須去修改 jsdx-toolkit 以處理 X11 底下的更多狀況，符合並更完整支援一般桌面環境下的操作習慣。 你可能用過 GTK+/Qt 這類常見的 Toolkit，也知道在 X11 之下有很多種類型的視窗（Window），像是 Dialog、Splash、Menu、Popup Menu 等等，但你可能不知道這些現代 Toolkit 內部做了多少事。事實上，X11 本身雖定義了各類視窗的類型，但實際上 XWindow 和 Window Manager 並不會完全去照定義去處理你的視窗行為，更準確的說法是，X11 HWMH 中的基本定義和我們實際的認知是有出入的，該定義只是說希望達成的行為，但沒說是由誰（XWindow、Window Manage 還是 GUI Toolkit）去處理。 舉例來說，我們現在寫一支程式，該程式不使用任何現代的 GUI Toolkit，然後單純使用 X11 API 把一個 Window 的類型設成 Popup Menu。但是你會發現，它的實際行為並不像我...

很抱歉，因為台北大雨來襲，導致班機延誤，讓小弟無法及時從香港趕回台灣參加 FreedomHEC 2012。相當對不起主辦單位，就這樣讓當天議程開了天窗。但是，之後我有空時，仍會整理資料，依舊會公開原先預定要給予的簡報。 不幸的是，活動第二天被客戶抓住，所以也沒辦法到場聽講。不過，雖然沒參加到 FreedomHEC 2012，為了賠罪，第三天當了司機（Be a driver, not writing driver :-S），開著車載著外國講者們一路到了宜蘭大學，給予學生機會直接面對面與 Kernel 開發者交流。 除了面對面問答解惑，其中當然也有保留一點時間，讓講者們可以自我介紹，也分享一些經驗。我也給予了一份簡短的心得分享，由於對象是學生，時間也有限，所以就不直接討論艱澀的技術，而是以輕鬆的角度切入，分享一下創業的經驗和業界的感想，還有描述就算在面對不利軟體業的環境之下，身為一個軟體人所需要的熱情和自我要求。 衷心期盼我們能培養軟體開發的熱忱，然後才有機會做出軟體的價值。:-)