Fred's blog

曾經想要用 Node.js 開發一些原生的應用程式或是 OpenGL 程式，但無論怎麼問，無所不答的 Google 大神都給我千篇一律的答案：『使用 HTML5 和 WebGL』。這答案其實不令人意外，因為截至目前為止，大多數學習使用 Node.js 的人都是 Web 開發者，其所提出的解決方案，理所當然都是與『瀏覽器』有關。想來有趣，Node.js 就是『與瀏覽器剛分手的 JavaScript Engine』，為何還要回頭與瀏覽器糾纏不清呢？於是，筆者開發並於 GitHub 釋出了一個 Node.js module - 『 jsdx-toolkit 』，讓 JavaScript 開發人員，可以輕易使用 Node.js 開發原生的桌面應用程式，更重要的是，不但可以寫炫麗的 3D UI，而且完全不需要靠『傻大個瀏覽器』。 如果想要載入圖片，並把物件 3D 旋轉，只需要這樣做： var toolkit = require('jsdx-toolkit'); if (toolkit.init() != toolkit.INIT_SUCCESS) { console.log("Failed to initialize jsdx-toolkit."); process.exit(); } /* Create a new stage */ var stage = new toolkit.Stage(); stage.title = 'Rotate'; stage.resize(500, 500); stage.setColor(0, 0, 0, 255); stage.on(toolkit.EVENT_DESTROY, function() { toolkit.quit(); }); stage.show(); /* Load a image */ var texture1 = new toolkit.Texture; texture1.loadFile('fred.jpg'); texture1.setPosition(100, 100); texture1.rotate(toolkit.Y_AXIS, 30, 0, 0, 0); stage.add(texture1); toolkit....

話說微軟(Microsoft) 這兩年為了 XBox 360 所推出的 Kinect 造成一股風潮，一夕之間，把 Wii 打的七零八落，取代了其體感遊戲機王者的地位，相比之下，Sony PS3 同一時期所推出的體感裝置，就顯得乏人問津 。 最近，筆者雖然忙錄，被很多麻煩的公事私事綁住，但每當睡前，仍抽空研究一些新技術。一方面是為了促使腦筋轉得更快，一方面是想加強許多 Idea 和 Business Model 的強度和完整性。於是，撿起丟在一旁生灰塵的 Kinect，嘗試著在上面開發一些應用。 由於『 OpenKinect 』眾高手的努力，所以驅動程式不是太大的問題，很久以前就已經能分別在 Linux、Windows 和 Mac 上驅動 Kinect。不過雖說如此，最困難的還是在於辨識演算法的相關設計，對於開發人員來說，你不過就是能得到攝影機的影像，就如同從 Webcam 上得到一樣，其他的圖學運算以及應用還是要自己動手。 當然，如果 Kinect 只是和一般 Webcam 一樣，那新聞媒體和許多人對他的誇讚，就太言過其實。其最大的不同在於，Kinect 有深度感測，這意味著我們可以得到實際的空間資訊，以工程的方式，大大減少辨識演算法的難度，並提升了辨識系統的精準度。 這次的嘗試，焦點放在辨識演算法之上，便開始思索各種方案。過程中，試了數種別人已經開發好的函式庫，都不甚滿意。倒不是效果不好，而是系統需求太大，開發語言大多採用  Java ，所以需要安裝一卡車的模組程式以及 JVM。有些更是對 Linux 的開發者不夠友善，或開發支援不夠完整。無論哪一種現有方案，都不足以讓筆者可以安心建構在上面然後開發下去，因為產品化和易移植性，對筆者來說是相當重要的考量，不是只要學術驗證而已。所以最後決定，自己手動設計演算法，採用 C/C++。 經過這幾天睡前的努力，可以看到開發過程中的截圖，演算法初步已經能辨識手掌，並抓取指尖位置，精準度已達可用的程度。接著，只要多做些簡單的開發，撰寫 X11 輸入裝置驅動程式，就能實際以多點操控的型式，操作螢幕上的所有應用程式。 此外，這裡有一些心得，Kinect 深度感測的數值範圍是 0 ~ 2047，至於得到的深度數值如何換算成實體距離，這邊有個公式可以換算成公尺(Meter)的型式： Real Dist...

寫系統程式很常會需要碰到實作常駐程式，這意味著你必需要讓程式在背景執行，然後提供服務或是等待事件觸發，如『 親手打造一個背景執行的Daemon程式 』所提到，若用 C 語言，做法大致如此： void main() { pid_t pid; pid = fork(); if (pid>0) { exit(0); } } 而在 node.js 上可以使用『 daemon 』模組，輕易打造常註程式。 $ npm install daemon 使用方法如下： var daemon = require('daemon'); /* Become a daemon */ daemon.start(); /* Loop to do something here in background */ 執行後，程式應該會立即返回並結束，但是若用 ps 等系統工具程式去看目前正在執行的 Process，會發現我們的程式已經運行在背景了。

我們不得不承認，GNOME 為了整合桌面環境，曾經開發了很多好用的整合性的元件，像是桌面背景控制、圖型化元件樣式、螢幕設定監控和更多桌面功能的設定程式。對於我們這些不愛 新版 GNOME 的使用者來說，常常是改用其他桌面環境（如：LXDE、E17 或單純用 Awesome window manager），再配上 GNOME 的這些整合性元件。 不久前，雖然 GNOME 進入了 3.0 時代，但這些整合性元件依然存在著，並不隨著版本上升而有所太大改變，這對我們這些『不肯升級的使用者』是很好的消息，沒有太大的影響。不過，在最近幾個月，GNOME 已經將這些元件一一消滅，整併進去其他的專屬程式當中。在 Debian 上，gnome-control-center 更是已經毀損（如果你沒有裝新版的 GNOME 3.0），更進一步，許多重要的系統常駐程式一一失效（如：gnome-settings-daemon 和 gnome-power-manager 等），不再如同過去可以輕易單獨使用。 GNOME 所帶來的毀滅，已經嚴重影響到筆者現有的使用，所以打算再次繼續原本停滯一段時間的 Juice Desktop Environment （詳情可參考『 新鮮果汁吧！果汁桌面環境(Juice Desktop Environment)！ 』），過去曾開發過『 JuShelf 』，就屬於這計劃的元件之一。 大概評估了工作，主要就是系統監控程式的實現，也就是取代舊有 gnome-settings-daemon 的功能。對筆者個人而言，目前只有幾種簡單需求： 電源管理：螢幕休眠、電腦蓋上後自動休眠、AC 電源切換通知和低電壓通知。 螢幕設定：插上外接螢幕後自動偵測，拔除時也自動恢復成單一螢幕（現在是一片黑）。 OSD支援：調整螢幕亮度、音量時，可以跳出畫面顯示目前亮度和音亮。 日後當然還需要有圖型化程式，可以微調這些細部設定，不過不是初期主要的工作（相信會選擇不用 GNOME 的人，應該都有能力自己改設定檔）。 筆者成立了一個新的 Project -『 JuDaemon 』，就是為了解決這樣的需求，目前只完成了螢幕自動休眠的部份，尚有其他工作待繼續。如果您有興趣，可以提交 patch 或是加入這個專案一同開發。:-) 後記 考慮到...

對於我們這種『宅宅水電工』，唯一的樂趣就是經營技術，閒暇招三五同好，玩玩新東西。但怎麼也沒想到，我們這種人做出來的東西，卻變成有心人『統獨論』的撰文題材，令人又好氣又好笑。原始文章出自這篇『 台灣人缺乏自信之實例 』，是筆者在閒逛 Google 時搜尋到的，因為有提到自己的名字，就特別點進去看了一下。被說成缺乏自信心，甚至要被除去，百般無奈。 還記得 LXDE 剛開始會為人所知，是因為 PCMAN 於一些台灣社群活動中，首度公開設計理念，當時雖然許多人叫好，但真正參與開發或專案的確寥寥無幾，一段時間折騰下來，包括我在內的開發者和參與貢獻者，不過五六人，甚至 PCMAN 寫了大量的程式，一度荒廢了自己的學業和醫生本業。 說起來心酸，為了得到台灣社群的認同，我們無不熱衷於在台灣各個大小場合，推廣和號招開發者以及有興趣的人加入。當然， 我們不是外國人，都是使用『中文』與其他人說明和討論技術問題，也極力確保軟體都有中文的介面。甚至成天掛在 IRC（相當古老的網路聊天系統，目前仍被全世界的駭客和開放源始碼廣泛使用） 上，與網友以『中文』討論諸多相關問題。當時許多文件和簡報，同時存在著中文和英文版，甚至很多只有中文版本。 LXDE 的成員身體力行在台灣走透透，卻沒想到也能招來不少外國人。在推廣過程中，開始接觸到許多國外來的開發者和自由軟體愛好者，也開始在各國都有人自動自發要幫忙翻譯成各種語言，然後台灣以外的許多愛好者也開始大量使用 LXDE 並回報問題，甚至提交他們修改過後的程式 patch，參與貢獻。我只能說一開始， LXDE 只有一堆一般人不易讀懂的程式碼，後來的許多非中文的文件和說明， 很多是出自於這些外國貢獻者之手。 註：差點忘了提，LXDE 的網域名稱，還是一位印度人所贊助的。 『自由軟體和開放源始碼』會為我們這些宅宅水電工所喜愛，就是能與所有的同好者，一同完成這些程式和專案。但是，這些自由軟體本來就只是花費我們的課餘時間和下班閒暇時間，不可能什麼東西都能親力親為，我們唯一能做的，就是將自己的初衷做好 。所以，LXDE 後來在國外會有一些知名度，也不是一開始所能預期的，更別提到是不是以台灣為榮，那都是不重要的後話。 若真要說到活在台灣的心態，我只能說：『我們在台灣長大，只是將在台灣這一二十載所學的一一展現出來，如此單純而已。』。我們挺胸開發自...

這是創業者的心聲，我們永遠為了為數不多的錢，拼老命和客戶周旋。在客戶面前包到好包到腳，扛的責任何其多，回來後又當業務又當 PM 還要當 R&D，最後還得當會計，數不盡的心酸誰知道。沒辦法，對我們來說，現金流（CashFlow）比什麼都還重要，能不能挺過這個月或下個月，維持周轉才是首要任務，為此，任何苦我們也得吃下。 筆者做了幾年的 Outsourcing，雖然不是當初創業的核心目標，但為了養家活口，接案卻成了主要業務。不過，筆者確實也因接案而活了下來並壯大團隊，能夠有機會持續朝理想發展。接案的過程中，風風雨雨自然不在話下，但慶幸受到前輩和朋友間的提攜，近來也總算是開始有個根基，剛好穩住腳。 接案就是這樣，有一頓沒一頓，如果要穩定收入，案子的價與量就必需相應提高，這是所有以接案當食糧的創業者，所都要經歷的過程。但是，往往在提升價和量後，案子開始會吃掉團隊的全部時間，漸漸失去當初創業的核心目標。然後，進入了『招人力』後『招案子』再『招更多人力』後『招更多案子』的惡性輪迴中，最終你會想：『辛苦到快暴斃，工時責任換算下來，賺得比去上班來得少，那我何必創業？』。如果你有同感，不用灰心，因為現在有無數的創業團隊和創業者， 也都正面對著同樣問題，甚至面臨崩潰。 有鑑於此，筆者尋思，何不與大家分享自己的經營成果，讓大家各自都能得到更多時間經營自己的核心目標？創業者、SOHO族和個人接案者所需要的源源不絕的食糧，不必各自重新發展重新耕耘，只需要從筆者這接手過去即可。由於舊有團隊原本已經有業務和PM的佈署，大家也可專注於技術性的工作，並提供如自來水般的技術供應即可。 對筆者來說，自己的核心技術團隊得以鬆口氣， 能慢慢以階段性放下養活自己的短期目標，有更多時間朝自己原本創業的核心目標前進。另一方面，也能給予其他創業者、SOHO族和個人接案者穩定的收入支持，不必重蹈覆徹筆者同樣的道路。如此雙贏的局面，樂見其成。 所以，如果你們是有技術的創業者或創業團隊，SOHO族或個人接案者，趕緊來報到吧！ 後記 無論你是專精或有經驗於哪一領域（Web、Linux、Android System（Integration/Porting）、Android App、iOS App 或 Embedded System... etc），都歡迎來信，最少先交個朋友也是不錯的。:-)

最近一直感覺到系統有時莫名緩慢，CPU 負載也相當高，初期沒去注意，也一味的相信應該都是瀏覽器開太多網頁和 Flash 檔案所造成的，但種種情況令人不解，總覺得不完全是瀏覽器所造成的。將所有瀏覽器關閉後追蹤發現，自己之前寫的『 JuShelf 』（Dock 程式）竟吃掉近 50% 的 CPU 資源。原兇是之前寫的一段程式，用來偵測目前螢幕設定是否有改變，並依據螢幕設定而調整顯示位置，以讓 Dock 永遠顯示在螢幕的中央。 原本的做法相當笨，利用 g_idle_add_full() 讓程式空閒時就去偵測螢幕設定，但由於 Dock 通常是晾在一旁沒有工作的，所以程式經常有空閒時間，這讓程式以每秒百計的次數不停檢查。這還不打緊，由於每次檢查都要與 X Server 做一次至數次溝通，付出的代價更為高昂。 抓到臭蟲以後，便開始著手改進，使用了 XRandR Extension 來取代原有的解決方案。過去筆者曾撰文『 寫支 C 程式用 XRandr Extension 設定你的螢幕解析度 』說明 XRandR 的使用方式，不過當時只著重於取得 X Server 的顯示設定，這次將利用 XRandR Extension 以等待 RRScreenChangeNotify event 來得知螢幕設定何時改變。 由於完整程式太長，這邊只摘錄重點片斷，主要是檢查 XRandR 版本和註冊事件： int rr_major_version, rr_minor_version; int rr_minor_version, xrandr_error_base; /* Initializing X Stuffs... */ /* XRandr extension */ XRRQueryVersion(disp, &rr_major_version, &rr_minor_version); if (rr_major_version < 1 || (rr_major_version == 1 && rr_minor_version < 2)) { printf("RANDR extension is too old (must be at least 1.2)\n"); return 1; } /* Al...

NodeJS 日益強大，相關開發資源也越來越多，許多功能已經不再需要自己寫，通通都可以直接利用官方的 NPM（Node Package Manager）工具，從網路上把別人已經開發好的模組抓回來用。這樣的模組交換平台加快了開發速度，讓開發者可以全心全意專注於當前應用的開發工作。但是也因為如此，讓我們的 Project 總是相依於一大堆的第三方模組，而每當要將我們的程式佈建於伺服器時，就必需手動先將所有的模組先安裝好，甚至是用最笨的方法邊試邊裝遺漏的模組。 事實上，我們可以在程式目錄中，建立 package.json 檔，直接管理 Project 的相依性以及所使用到的模組套件： { "name": "my-website", "version": "0.0.1", "private": true, "dependencies": { "express": "2.4.7", "jade": ">= 0.0.1", "oauth": ">= 0.9.5" } } 一旦目錄中存在 package.json，下次要移到新的環境裝起來時，可以直接利用 NPM 把所有的相依模組一次裝好，省下很多功夫： $ npm install

過去無論哪一種網站應用程式的開發語言，初學者教學中第一次會提到的起手式，八九不離十就是 GET/POST Request 的取值。但是，在 Node.js + Express 的世界中，彷彿人人是高手，天生就會使用，從不曾看到有人撰文說明。 這應該算是開發 Web Service 的入門，在 Client 與 Server 的互動中，瀏覽器發出 GET/POST Request 時會傳值給 Server-side，常見應用就是網頁上以 POST method 送出的表單內容，或是網址列上的 Query Strings （ex: page?page=3&id=5）。然後，我們的網站應用程式透過解析這些參數，得到使用者上傳的資訊。 取得 GET Request 的 Query Strings： GET /test?name=fred&tel=0926xxx572 app.get('/test', function(req, res) {     console.log(req.query.name);     console.log(req.query.tel); }); 如果是透過表單且是用 POST method： <form action='/test' method='post'> <input type='text' name='name' value='fred'> <input type='text' name='tel' value='0926xxx572'> <input type='submit' value='Submit'> </form> app.post('/test', function(req, res) {     console.log(req.body.name);     console.log(req.body.tel); }); 當然也可以 Query Strings 和 POST method 的表單同時使用： <form action=...