發表文章

目前顯示的是 4月, 2012的文章

【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 不受限於任何開發領域。

【Node.js Taiwan 心得分享】How to Write Node.js Module 簡報檔釋出

於本週四所分享的『 Node.js Taiwan 社群聚會 - How to Write Node.js Module 心得分享 』,簡報檔經整理後釋出,對 Node.js Module 開發有興趣的人可以自行參閱。若有不瞭解之處,可與小弟聯絡和討論。如有發現問題,請不吝賜教。 本次分享主要有三大部份: 使用 JavaScript 開發 Node.js Module 學習使用 NPM 註冊帳號和上傳模組(Module)  進階議題:開發 Node.js 的 C/C++ Addon 簡報展示: 後記 由於小弟於 people.linux.org.tw 上的 SSH Key 遺失了,短期內沒空處理,所以無法像過去一樣直接上傳 PDF 供大家取用。因此,日後會使用 slideshare 來分享簡報。

各式 JavaScript Class 的效能比較

圖片
我們在做 JavaScript 開發時,常會使用到類別(Class) 的設計方法,但事實上,JavaScript 根本沒有所謂的類別(Class) 概念,此功能完全是靠動態物件(Object) 所模擬出來。因此,在 JavaScript 中,有數種方法可以定義和設計我們自己的類別(Class) 。可是哪一種方法的效能比較好呢?這便是本文的主題。 為免空口白話,筆者在 jsperf.com 建立了一個 Test Case『 Prototype Operator Performance 』以便實驗,並邀請各方網友使用瀏覽器前來測試,比較使用和未使用 Prototype 兩種情況,以及不同寫法的速度。(若你有興趣幫忙做實驗,進入該網站後, 請點選 Run Tests 開始測試) 註:在測試過程中,請確定你的瀏覽器,沒去跑其他的吃重的網頁,以確保實驗結果的準確性。 你可以在該網站上,觀察其他網友們的測試結果。但是,由於本次目的,主要測試的是同一種 JavaScript 引擎,處理不同建構方法的速度,所以,大家只要專注於在同一個瀏覽器下,其測試結果就可以。不同電腦,不同系統和不同瀏覽器的速度,並不是我們這次比較的重點。此外,因為 Node.js 使用的是 V8 JavaScript Engine,在本文中主要會拿 Chrome (因為 Chrome 使用的是 V8 JavaScript Engine)的結果討論。 這個測試有兩組實驗,第一組是測試呼叫類別(Class) 中方法(Method) 的速度,我們分別測試三種,用不同方法建構出來的類別(Class): 未使用原型(Prototype),直接在 Constructor 內定義 方法(Method) A = function() { this.message = function(s) { var msg = s + ''; }; this.addition = function(i, j) { return (i * 2 + j * 2) / 2; }; }; A_instance = new A(); A_instance.message('Hi'); A_instance.addition(i, 2); 使用原型(Prototype

Node.js Taiwan 社群聚會 - How to Write Node.js Module 心得分享

無論你是否已經相當熟悉,還是想要嘗試入門 Node.js,應該都想要尋找興趣同好,找機會共同研究和分享彼此心得。已經辦了多次聚會和心得分享的『 Node.js Taiwan 社群 』,將於 4/12 (星期四)舉辦第五次的 Node.js 聚會,邀請廣大朋友們參加。 小弟有幸受邀,將於這次聚會交流心得分享,主題是『How to Write Node.js Module』。 在不久的文章『 我為什麼大舉投入 JavaScript 的相關開發 』內有提到,今天的 JavaScript 已經不再只是網頁前端的專利,除了能開發網站後端,也可以撰寫系統程式,甚至是嵌入式系統和跨平台的各類應用。而 Node.js 因為實作了許多基本的 JavaScript 函式庫,讓 JavaScript 可勝任許多的應用,所以近年來受到不少關注。此外,Node.js 的模組(Module)機制,更是讓我們能輕易擴充各種不同的功能,以及使用 C/C++ 為 Node.js 實作低階的 API。所以,想要完全不受限制的運用 JavaScript 開發各類應用,學會寫 Node.js Modules 是個必需要經歷的過程。 有鑑於此,本次的分享內容會提及: Node.js Ecosystem Pure JavaScript Module Development NPM(Node.js Package Manager) C/C++ Addon Development 若時間允許,會進一步探討 C/C++ Addon 所衍生的應用範例: System Programming in JavaScript Desktop Programming in JavaScript 詳細 Node.js Taiwan Party 聚會訊息如下: 官方公告: http://nodejs.tw/post/20631976641/nodeparty20120412 時間:2012/04/12 (星期四) 19:30 – 22:00 地點:台北市大安區金華街 122 號正對面 d.cafe 地下室 W-B05 室(創立方) (政治大學城區部,可從旁邊的小門直接進到地下室,找不到的人『 看圖 』) 有興趣的朋友們,歡迎前來參加,不吝指教。:-)

用 Node.js 實作多個 Process 監聽並處理同一個 Port

Node.js 實作了一個內建的模組『cluster』,目的在於提供開發者一個容易的方式,針對多核心機器進行支援。可惜的是,截至今天 Node.js v0.6.14 版本,『cluster』功能還是不夠完整,從官方文件上可以得知,其 API 仍處於實驗(Experimental)階段,在日後會有極大的變動(Drastic changes in future versions)。 而就 git repository 上最新的 Node.js 開發版本來看,『cluster』模組已經大幅度更改,也從簡單的 function call 變成了物件的設計。所以,目前非常不建議在自家產品中大量使用 『cluster』,至少短期內,他都不是穩定可用的,會有很大的改動空間。 不過,你如果是要實作 Web Service,會想要使用『cluster』的目的就顯而易見:『透過多個 Process 分擔流量和工作量』。若只是單單要做到這一點,我們可以自己來實作。 通常我們有兩種方式達成這個需求: 反向代理(Reverse Proxy) 技術 使用多個程序(Process) 監聽並處理同一個 Port 前者的做法,是建立一個常駐程式或機器,統一處理所有連線的需求,然後將這些連線做流量平衡(Load Balance),轉送並分配給後端多個程序或機器處理,待處理完成後,再將後端的回應送回給使用者。這樣的 Proxy 機制,你可以用已經相當成熟的解決方案達成,像是 Nginx 或 Apache。亦或是自己使用 Node.js 撰寫,但由於這不是本文的重點,日後再來討論這個實作的細節。 而後者,使用多個程序(Process) 監聽並處理同一個 Port,是本文的主題,也是『cluster』模組正在做的事。如果你有看過『cluster』的程式碼,就會發現它其實主要運用了兩個技術:『取得 net._handle』和『利用 process.send() 傳送 Handle 給子行程(child process)』。 知道了關鍵後,實作上就不是什麼大問題,主要流程是: 運用『net』建立一個 Server,目的在於監聽(listen) 80 Port 建立多個子行程(child process) 準備處理連線 將『net』的內建 Handle 傳給子行程(ch

發佈 AppHouse-Manager 圖型化管理介面!

圖片
繼前文『 不靠別人!親手佈建自家的雲端服務平台 AppHouse 』所提到,我們以當今主流的雲端平台的佈建習慣為參考,開發了一個自己的 Hosting Platform,做為投入雲端產業的基礎建設。雖然與許多雲端業界的老前輩(如:Google、Amazon 等等)比起來,仍然不夠看,但研發仍逐步朝完整的解決方案前進。 在使用『 AppHouse 』時發現,網站應用程式的佈建雖然相當快速,但若是要直接在 AppHouse 上開發應用程式,會有相當多的麻煩,也不夠便捷。於是,撰寫並釋出了一套圖型化的管理程式『 AppHouse-Manager 』,用來管理 AppHouse 上所有的應用程式(Application)。 目前提供了功能,可以重啟特定的應用程式,讓開發者可以在撰寫和測試服務時,依自己的需要重新啟動自己的程式。 也實作了即時監控 Console ,我們可以透過瀏覽器即時偵錯(Debug)。 目前 AppHouse-Manager 還相當不足,只能說堪用而已,並還有許多欠缺改進的地方。不過,已經足夠讓工程師在 AppHouse 上進行開發工作。

不靠別人!親手佈建自家的雲端服務平台 AppHouse

現在,凡事只要扯上『雲端』兩字,價值就上漲好多倍,所以,任誰都想狹著『軟體奈米』之勢,大做文章。此外,在大多數人的印象中,雲端就是 Google App Engine(GAE) 、 Amazon E2 或 Microsoft Windows Azure 的代名詞,無論是誰,只要是能將服務放在上面,或是將公司搬到了台北 101 的 Google 樓上,就叫做上了雲端。而那些所謂專家說的 IaaS 、 PaaS 、 SaaS 專有名詞,其實都是舊瓶新酒,只是商業界幫雲端和網路生態的各個部份做了劃分,方便於解釋給投資人或政府單位的『難懂標題』而已。 簡單來說,雲端對一般的企業,最重要的是發展自家應用,提供更多的『加值』且『不需大量人力』的服務,然後對客戶進行『綁樁』;對中間維護伺服器的廠商,就是『租出更多的伺服器』,得到更『大規模的需求和機會』,進一步『降低機房建設和維護的成本』;而對電信單位,就是賣出更多『通信產品』和『頻寬線路』,也能換到更多『國家預算』。 雲端對不同的企業有不同的意義,但對終端的一般企業和使用者來說,建立一個不用擔心擴展性和極限的網路服務,是他的真正價值所在。所以講穿了,雲端並不是什麼新東西,多企業會將服務放在雲端上,求的不過就是為了量化的『擴展性(Scalability)』,如果你很熟悉網路產業,就會發現其實這就是以前,當一個網路服務長大到一定規模,才開始要考慮的事。只是現在這個時代,網路服務搭上了終端實體產品的『量產列車』,許多服務的第一時間規模就相當龐大,所以直接跳過網路服務的發展期,馬上得考量第二步的事。這也是為什麼現在雲端熱哄哄的原因。 假設業界使用雲端的真正原因,主要是為了追求擴展性,我們不能親手打造嗎?我們是否可以自己建構一個像 Google App Engine(GAE) 的平台,將自己的 Web App 輕鬆佈建在上面?也保留日後擴展的可能性? 於是『 AppHouse 』應運而生,我們開始投入開發這樣的專案,目前開放原始碼,以 GPL 做為授權而公開。雖然初期是自己使用為主,但這對在國內還未投入實際行動的雲端市場來說,算是一種相當特別的嘗試。如果可以,也希望能找到機會,在國內能建置公開的平台,供業界或軟體開發者使用。 『AppHouse』最終目標是提供一個 Hosting Platform,就如 Google