發表文章

現實中,我的創業,問題,解答,手札。

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

實作 X11 底下的 Popup Menu

既然要投入 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 開發者交流。 除了面對面問答解惑,其中當然也有保留一點時間,讓講者們可以自我介紹,也分享一些經驗。我也給予了一份簡短的心得分享,由於對象是學生,時間也有限,所以就不直接討論艱澀的技術,而是以輕鬆的角度切入,分享一下創業的經驗和業界的感想,還有描述就算在面對不利軟體業的環境之下,身為一個軟體人所需要的熱情和自我要求。 衷心期盼我們能培養軟體開發的熱忱,然後才有機會做出軟體的價值。:-)

如何當一個優秀的救火員之打蛇打七寸

經歷過許多救火任務(這邊當然是指軟體系統專案的問題),從 Kernel、Driver、Porting 到各類系統應用程式、Web 應用程式,幾乎無所不救,有社群內的朋友嘲笑著說:『在國內大概沒有團隊,像我們一樣什麼火都救。』。有許多的感觸是肯定的,從問題發生的那一面看去,加以急迫時間的摧化之下,感受到許多程式開發者最真實的思維和邏輯,當然,還有發案老闆的著急,以及清楚看到許多關係人暗地裡的算盤。我不敢說自己是優秀的救火員,但至少一旦承諾並接下案子,有再大的困難和阻礙也總是使命必達,哪怕連續數個月每天平均只睡兩小時,三四天只睡一次,也不會倒下。我想,最少我可以談談如何救火,還有從火堆中看到的許多『人』的問題。 其實,救火沒什麼訣竅,撲滅它是其次,主要是確保不會再燃起。俗話說『打蛇打七寸』,解問題時也要解到夠力才行。但是,或許你常聽有人說:『產品要出貨,能動最優先,好不好其次。』,似乎恰恰與我所提到的相反。沒錯,因為要確保火不會再燃起,理論上是要找出問題根源,從根源著手和解決,很多人乍聽之下,都會覺得是費工又花時間的工作。但是,每次的經驗都告訴我,實際上,找出問題根源,並解決他,往往比修補來得快很多,而且一勞永逸。尤其是碰到死線(deadline)將至,卻一直解不掉的一大坨 Bugs(指同類相關或互相影響的問題),從根本上並深入解決問題才是最快的辦法。 這邊有個簡單的案例: 有一個應用程式,與 Library、System API 和 Driver 都有相關,他們相依關係是: 應用程式 -> Library -> System API -> Driver 假設現在有個問題,這支應用程式出現了一個 Bug,而這個問題最終被發現是 Driver 缺少一些功能,而造成功能不正常。那我們應該從哪裡去解決? 一般人的做法,若是為了因應『產品要出貨,能動最優先』,所採取的方法當然是拿掉應用程式上的某些受影響的功能,或是改寫應用程式以另循途徑的方法達成同功能。但是,若你選擇這樣的做法,最可怕問題是,如果應用程式太過複雜,修改起來會有更多的副作用(Side effect),你要花更多時間去處理更多原先不存在的問題。 況且,這都還沒講到,我們根本都還不知道 Driver 造成的影響範圍有多大,有哪些 System API 、Library API 和...

簡單理解 JavaScript 的記憶體管理機制

不像其他的語言,JavaScript 開發者永遠沒有辦法自己去釋放記憶體,頂多只能移除物件的 Reference (代表這物件已經沒有人在使用),而且這物件所佔的記憶體並不會馬上被釋放,而是 Garbage Collection 在滿足某些條件的情況下,才在背景自動去尋找沒有被使用的物件,然後釋放。若你嘗試過尋找釋放記憶體或移除物件 Reference 的方法,得到的解答,應該不外乎是使用 delete 關鍵字或是將變數設為 null,但是你真的了解它的意義嗎?事實上,有很多人都是在不瞭解的情況下使用它們,還可能因此產生 Memory leaks 的狀況。欲弄清楚這一切,我們必須先簡單理解一下 JavaScript 的記憶體管理機制,更準確的說,是物件的管理機制。 從 JavaScript 開發者角度來看,JavaScript Engine 在運作時,記憶體使用是呈現樹狀結構,也就是所有命名或建立的變數或物件,都是存放在一個全域(global)的 Object 中。在 Node.js 中,你可以直接讀取 global 變數看到目前 Context 的環境狀態: console.log(global); 我們可以做個實驗理解一下: var myVar = 'Hello'; function myFunc() { return 123; } var myObj = { a: 1, b: 2 }; console.log(global); 執行以上程式,你應該可以從 global 中找到我們自己定義的變數和函式: { ...(已省略基本預設的環境變數)... myVar: 'Hello', myFunc: [function], myObj: { a: 1, b: 2 }, ... } 從結果可以發現,所有的物件都以樹狀的形式被 global Object 保存著,無論是變數還是任何一種類型的物件,都是一組組 Key/Value 的存在。而 Value 就是各種不同形態的物件,如字串、函數、陣列、數值等。 所以,移除某物件的 Reference,就意味著將把物件從這棵樹上拔除掉。因此,我們可以直接將該變數設為 nul...

【JSDC.tw 2012 簡報檔釋出】Non-MVC Web Framework

由於一些因素,被徵招去救火,在 JSDC.tw 2012 (JavaScript Developer Conference 2012) 給與了一場 Talk,由於準備時間相當緊迫,就把最近在研究和試驗的半成品匆匆拿上場展示和說明,題目是『Non-MVC Web Framework』。你可能在議程上沒有看到這場 Talk,實際上是因為主辦單位的一些小疏忽,議程上仍是寫著之前的舊題目『Build Node.js Module』,而且小弟的名字也打錯了,從 Fred 變成了 Frend,差一點就變成二十世紀少年的友民黨教主。:-) 本次議程其實和前幾天發的舊文『 前端工程師也可以淡定的開發網站應用!RedTea Web Framework! 』息息相關,探討的是改善 MVC 的開發流程,和引入 JavaScript/Node.js 後的大膽嘗試,而且進一步討論實作細節。此外,因為 RedTea 本身只是一個實驗性的專案,目的只在於驗證可行性,還不到實際使用程度,所以藉著這次機會,公開並宣布新專案『 Kamalan Web Framework(葛瑪蘭) 』,Kamalan 引入了 Express Web Framework 為基礎,然後將結合 RedTea 的成果,並更進一步簡化其中細節和使用方法,讓前端工程師能真正無痛上手。 雖然還沒完全將 RedTea 的機制完全整合進 Kamalan,但目前 Kamalan 最少可以和 Express 一樣使用,你如果有用 Express 寫的程式,直接將 require() 引入的模組名改成 Kamalan 即可。由於 Kamalan 在根本上就是 Express,甚至是可以使用 Express 的所有 Middleware。 後記 這場 Talk 後,引起了一些 JavaScript Developer 趕的迴響,一些建議和聽眾的期待相當令人開心,討論過程也非常愉快。感謝大家的參與。:-)

【GNOME.Asia 2012】Enjoy Writing a Modern Desktop Application in JavaScript

圖片
依稀記得,當年去越南(Vietnam)參加 GNOME.Asia Summit 2009 的情景,當時甚至寫了一篇[ 遊記心得 ]。因為那是首次以講者身份參加國外的 Open Source 研討會活動,意義非凡。更重要的是,那也是當時和 Penk 組成的 ULLab(/usr/local/lab) 第一次出征,如今這樣的組合雖不復存在,但仍在心中藏有很多回憶。 今年度的『 GNOME.Asia Summit 2012 』將在 6/9 - 6/10 於香港舉行,很感謝 GNOME Foundation 再次贊助,讓小弟幸運的又能以講者身份飛去參加這次活動,而這次要給予的主題是『Enjoy Writing a Modern Desktop Application in JavaScript』。 今日科技變革相當快速,但桌面應用的開發一直跟不上節奏,原因是『開發效率差』和『入門門檻高』一直都是 C/C++ 這類中低階的語言的痛處,不足因應這個時代對應用的大量需求。因此使用有高生產力的腳本(Script)語言來開發桌面應用程式,便是目前可行的解決之道。 JavaScript 自 World Wide Web 澎渤發展以來,一直處於相當重要的地位,用於處理 User Interface 的工作,已經有快要二十年的時間,可說是非常成熟。事實上,GLib/GTK+/Clutter 等底層的事件模型,就與 JavaScript Engine 本身的機制大同小異,在同樣解決使用者介面的工作上,可說是殊途同歸。因此,有這樣豐富的前線作戰經驗當後盾,我們可以確信,JavaScript 非常適合被用於開發桌面應用程式。若是與 GTK+/Clutter 這類底層 Toolkit 相結合,跳脫出瀏覽器,寫原生的桌面應用程式也未嘗不可。 這次的議程,小弟將提及: 回顧 JavaScript 歷史和發展 探討如何使用 JavaScript 開發原生的桌面應用程式(搭配 GTK+/Clutter/Mx) 既然這次活動的主角是 GNOME,主要將以探討原生的桌面程式為主,當然也會因應未來發展,提及 Web Application 的部份。 期待與香港和世界各地前來的朋友相見。:-)

前端工程師也可以淡定的開發網站應用!RedTea Web Framework!

還記得,尚未投入 Node.js 前,一直覺得 Node.js 帶來了未來,讓我們可以用 JavaScript 同時開發 Web 前端(Front-end)和後端(Back-end),等到真的投入 Node.js 後,發現雖然事實的確是如此,但由於前端和後端應用所需要的背景知識不盡相同,開發模式和概念更是大異其趣,所以,雖然同樣是使用大家熟悉的 JavaScript 語言,但前端開發者仍然不見得能夠如願地來開發後端應用。 這樣的情況讓我想起有位來台灣工作的外國朋友,曾告訴過我一個多年前發生在他身上的笑話。故事是: 他原本是個美術方面的設計師,然後,但有一天老闆對他說:『你從現在起,去做開發程式的工作吧。』 他問:『為什麼?』 老闆回答:『寫程式是用英文寫,而你又會英文,不就可以寫嗎?』 是的,同樣道理,雖然對前端工程師而言,JavaScript 是最熟悉的程式語言,而 Node.js 又可以讓你使用 JavaScript 寫整個 Web 應用,但這不代表對這些人而言,就可以輕易上手 Web service 的後端開發。要真正讓前後端開發合而為一,不只是語言要統一,開發經驗也要相同才是,這才是所有 Web 開發者最期盼的事。 於是筆者基於 Node.js,開發了『 紅茶(RedTea) 』,這是一個和現有的網站框架(Web Framework)所不一樣的全新的嘗試。以前端開發者視角和經驗為出發點,專門設計給前端工程師上手使用的網站框架,讓前端工程師也可以『淡定』的開發網站應用。由於 RedTea 不是傳統 MVC 模型的 Framework(至於 RedTea 採用的是哪種開發模型,筆者一時也說不上來。),所以,如果你是一個已經被 MVC 涂毒已深的開發者,可能要先花點時間重新理解一下。:-) 此外,RedTea 有一個最大的特點,就是支援了在瀏覽器環境下,呼叫後端 JavaScript Class/Function 的功能,就像在使用本地端的 JavaScript 物件般。因此,前後台交換資料,不用再以 GET/POST、URL Path Routing 或 Ajax 相關的方法實作,只要學會怎麼使用 JavaScript Class 即可。重點是,即使你沒有任何 HTTP 通訊協定的知識,或後前後端資料處理的經驗,依然可以開發出網站程式。 ...

想寫好 JavaScript,遞迴技能要練好

V8 JavaScript Engine 的運作,主要是以事件驅動(Event-driven)來執行所有的程式碼,如果你有開發過 GTK+ 程式的經驗,使用上應該不陌生。不過這對一般人其實相當不好理解,因為事件驅動會讓你的程式看起來像是多工在運作(如使用執行緒),所以有些人對於 JavaScript 的理解是,有些東西可以丟背景執行。 要了解事件驅動,可以先從 JavaScript 的行為說起。如果你正在使用 Node.js,你就會發現 Node.js 通常對同樣功能提供了兩個 API,分為『同步(Synchronize)』和『非同步(Asynchronize)』兩種類型。例如下面這刪除特定檔案的例子: 同步(Synchronize) API: fs.unlinkSync('/home/fred/badfile'); ... 非同步(Asynchronize) API: fs.unlink('/home/fred/badfile', function(err) { if (err) { console.log('Failed to delete file.'); return; } console.log('Successfully delete a file.'); }); ... 簡單觀察同步與非同步的執行結果,可以知道前者(同步)會停住並阻塞在此 API,等檔案刪除成功後才繼續下一行程式;而後者(非同步)有如將刪除檔案的工作丟到背景執行,並繼續往下一行程式執行,完全不會像同步 API 一樣停住。等刪除檔案的工作完成後,便觸發事件去呼叫 Callback function。而這樣非同步的機制就全靠事件驅動(Event-driven)來達成,雖看起來像是把程式丟到背景跑,實際上是在 JavaScript Engine 上註冊了一個事件,等到工作完成以後,事件被觸發時才接續執行 callback function。 非同步的做法通常會用在需要花大量時間的 API 上,如檔案系統、資料庫系統的操作等,以避免因為單一 API 造成整個程式鎖死或卡住不會動的問題,尤以前端和需要即時反應的工作上,特別需要。 至於這樣的事件驅動是怎...

【OSDC.tw 2012 Hackathon 成果分享】用 JavaScript 打電話囉!

圖片
以為 OSDC.tw 2012 在 4/15 號時就結束了嗎?其實並沒有。在活動的一個星期後,於 4/21 星期六,OSDC.tw 接著舉行了 Hackathon 的活動。很多人可能不知道 Hackathon 是什麼,有人叫他『駭客鬆』、『駭客松』或是『駭客爽』,其實總歸來說,就是讓開發人員盡情開發程式的活動。 這類活動的規則是,參加的開發者可以自由組隊,提交想法,然後當場實作。最後,在活動結束前,讓各隊伍一一上台展示成果。由於開發者的創意常常天馬行空,又能看到實際成果,所以這類活動都相當有意思。這次,OSDC.tw 提供了無限量供應的食物還有場地,活動時間是從當天早上 9:00 到下午 6:00,成果發表是從下午 4:30 開始,每個隊伍約有七個半小時實作自己的提案。 這次 Hackathon 活動,我與『魏藥』組隊,選的主題是『使用 JavaScript 打電話』,意即使用 JavaScript 開發出一支 Linux 應用程式,可以像手機一樣撥出電話並與對方通話。選這主題是因為我們的機器上剛好有 3G 數據卡(Modem),所以這個提案的目的,主要是撰寫一個 Node.js 模組『jsdx-ofono』,去提供控制 Modem 的 JavaScript API,讓開發者可以透過這組 APIs 撥打甚至是傳接 SMS/MMS 之類的訊息。最後,為了驗證並展示,運用了之前開發的『jsdx-toolkit』,用 JavaScript 撰寫了一個簡單的撥號介面『jsdx-app-voicecall』。 註:因為時間太趕,後來才發現,撥號 UI 忘了放倒退按鈕,所以撥錯號時要把程式重啟。:-P 如專案名,其主要整合了 oFone ,應用了之前開發的 node-dbus,所以省下了不少時間,最後再以 jsdx-toolkit 快速實作了一個 UI。原本希望,如果時間再充足一些,我們計劃幫 jsdx-ofono 加上 SMS/MMS 和讀寫 SIM 卡電話簿的功能,可惜最後沒來得及。 註:因為時間也不足,我們還來不及將 Linux 上的麥克風接上 oFone,所以目前接通後,只能聽到對方手機傳來的聲音。 此外,這次展示的兩個元件『jsdx-ofono』和『jsdx-app-voicecall』都有在 github 釋出,歡迎取用: https...

我所慣用的討論問題之方法

在處理技術問題時,我喜歡和他人討論,因為這是有助於大家提升技術的機會,也是種讓自己覺得不孤獨的方式,互相放下身段然後交換意見,每次都能不亦樂乎。這無關乎誰技術高低,只要大家能夠共同解決問題,除了是種樂趣也是種團隊集思廣益的機會。 由於有些人可以接受反證的方式,而有一些人比較能接受列舉推導的證明方式。所以,難免會碰到種情況,就是有人會大玩文字遊戲,讓你分不清他到底是真心想要找出問題,還是為辯而辯。其實,他們常常只是因為無法接受其他人的證明手段而已,所以互挑對方的骨頭。造成公說公有理,婆說婆有理,沒有交集點的局面。 一旦碰到這種情況,為避免文字遊戲混淆主題,我總是會請在乎『文詞精確』的人,先自己定義一些文字和用詞,然後再行討論。或是請有一些想法的人,針對問題先列舉出他們自己認為的所有可能性,然後接著追加自己認為的可能性,最後再行討論。這樣做的目的是,試圖採用他們們各自喜歡的證明方法,正反舉證,然後以交集去找出問題,除了讓兩邊都沒有話說之外,也能更快讓大家有『同樣的語言』可以溝通。此外,有時候為使討論順利進行,我也會一項項以詢問的方式進行,有時問題相當愚蠢,甚至會穿插基本面的問題。 很幸運的,使用這種方法後,在多數情況下,在大家列舉和回答問題之後,通常都能透過排除矛盾的方式,將問題給釐清,找到可能的疑點或是直接得到問題的解答。 不過世界不是這麼美好,既然過程中有愚蠢或基本面的問題,有些自認有本事的人被問到時,難免會覺得你在污辱他或是瞎扯蛋,有些人會回嗆:『自己去看 Spec』 、『連這麼基本的問題都不會,還問、還想討論?』。一旦扯到人的問題,就會讓整個討論進行不下去。 而有些人,在討論不下去後,會搬出多年來死背活背的聖經,在你面前推導了無數公式,繞了一大圈,最後『告訴你無解』或『證明自己沒有錯』。好一點的狀況,他們最後會『猜測問題』所在,回到討論的主題;不好一點的情況,他們就會告訴你『絕對不會有問題,是個無法解釋的靈異事件』,終結討論。 值得注意的是,如果問題的原因是:『執行那本聖經的理論時出現了 Bug』,你會更容易從他們口中得到『無解』和『不可能』的回答,因為這是『完美的聖經理論』內不會記載的東西。 不過,當碰到這種人時就沒辦法了,只能等他們自己想通後給你解答,亦或是另請高明。所以,如果你是他們的主管,又不想得罪他們,你需要給他們更多時間讓...

【OSDC.TW 2012】Let's Enjoy Node.js - All Development in JavaScript 簡報檔釋出

感謝各位捧場,上周六在『 OSDC.TW 2012 』所分享的『Let's Enjoy Node.js - All Development in JavaScript』,旨在介紹『 Node.js 』這新興的 Open Source 專案,我們可以預見,其將帶來軟體業相當重大的變革,並為 JavaScript 程式語言開拓了嶄新的局面。目前簡報檔釋出,歡迎各界取用和參閱。 自 2009 年 Node.js 公開發表以來,備受世界各地開發者囑目,在 2011 年 12 月更一度榮登 github 關注排行的第一位,超越了 Ruby on rails。Node.js 的出現意味著 JavaScript 語言從前端應用走進了 Server 的殿堂,除了效能表現不俗之外,使用其開發應用也相當迅速,未來 Web 開發者可以完全使用 JavaScript 語言打造網站服務,甚至是可大規模括展的雲端應用,堪稱 Web 開發者的夢想。 值得一提的是,Node.js 其實不僅限於 Web 應用,甚至可以用於各類系統程式開發,比較廣為人知的例子是 HP WebOS(前身是 Palm WebOS)。其採用了 Node.js ,做為系統服務的開發途徑之一。此外,Node.js 有模組化的設計,讓開發人員可以輕易使用各類其他語言(C/C++/Python... etc)為其擴充功能,彈性相當高,更讓 Node.js 不受限於任何開發領域。