發表文章

目前顯示的是 2014的文章

Node.js 的精彩應用!整合 bittorrent 與 FUSE 其實不難!

圖片
寫書寫到通訊協定一章,就想起今年來台灣 JSDC 的 Mathias,在台上展示以 Node.js 開發的 Bittorrent 影片下載工具『peerflix』,該工具可以結合 vlc、mplayer 這類的播放器進行 BT 種子的影片播放,相當有趣。此外,他亦展示了使用 VirtualBox 直接開 BT 上的 Ubuntu 安裝ISO 檔的實作。
很多人都說很神、很有趣,但看完後不見得會去了解實作細節。有些人更覺得這是他們無法碰觸的領域,只是當一個神在展示他的神力而已。這樣的情況,讓我感到難過,因為很多這樣的技術細節並不難,除了 bittorrent 本身的演算法本身的實作,或是開發其 Binding 是有困難度之外,其餘的東西根本上都是相當簡單的概念。
我想,這樣並不困難的東西,如果不去解析或了解它,實在是可惜了 JavaScript 至今的發展。
事實上, bittorrent client 的 binding 早有人開發出來並寫成模組。我們只需要使用種子檔案或是 magnet link,就可以透過 binding 去取得檔案資料,甚至是特定段落的資料,就像我們實作 HTTP 續傳那樣簡單,只需指定資料的開始處而已,全都有現成的 API 可使用。
若要播放這些影片內容,只需要建立一個 HTTP Server,再將從 bittorrent 下載完成的影片資料檔,運用 Stream 的技巧導向 HTTP 輸出即可。實作到此,我們就可以透過支援 HTML5 Video 的瀏覽器或是其他支援串流的多媒體播放器,以 HTTP URL 打開影片觀看。
至於 VirtualBox 怎麼去開啟 bittorrent 上的 ISO 檔,然後讀到哪載到哪的技術,其實也不是非常難,運用 Linux/BSD(Mac OS) 上的 FUSE(Filesystem in Userspace)的技術即可達成。雖然這是熟悉系統開發才會知道的技術,但概念與開發上其實並不難,尤其是也有人寫了 Node.js binding,我們可以完全使用 JavaScript 輕易實作。
簡單來說,使用 FUSE,可以讓我們不必觸碰到作業系統核心的驅動程式技術,就可以開發一個自己的檔案系統。然後,我們可以把自己實作的檔案系統掛載到一個本機目錄上。這代表,當其他應用程式使用標準操作、讀取(如 open、…

Hackathon 活動的『Koa 正在等一個人』簡報釋出!

圖片
很開心,這次十二月的『Hackathon Taiwan』相當多人參與,百人的報到數讓所有工作人員都感到興奮。最重要的,多虧了活動夥伴的遊戲設計,這次讓很多隻身而來的人,化解尷尬、相互認識並熱絡起來,最後順利組成隊伍,這算是種格外特別的創舉,過去很少有黑客松能做到這樣的地步。

有趣的是,這次活動找來了重量級的神秘講師 Jeremy Lu (對,就是那位最近紅極一時的 React.js 講者)開課,讓聽眾大飽耳福,絕對不枉來這一趟。有很多人也衝著 Qt 的課程而來,學習 QML 這樣先進的 UI 技術,這次的 QML 遊戲開發課程,相信讓很多人也開心地學會很多技術。

小弟在第二天的結尾,也給了篇一小時的分享『Koa 正在等一個人』,其內容在探討並帶領上手 Koa 這個下一代的網站框架、ECMAScript 6 Generator,以及 Node.js 和 io.js 的最新動態。(事實上是把最近將要出的書,擷取片段內容出來分享)


後記 對於我而言,活動內容再豐富,都比不上找到了好隊友可以一起創作。這次活動,得到了一個硬體工程師加入我們的團隊,所以可以開始進行硬體設計及控制等工作,而且大家相約了下次一起再來。下次,我們將會開始進行各種智慧家電的控制,以及 IoT 的相關應用。看來,我們只差一個設計師的加入了!如果你有興趣,快來加入我們!:-D
下次黑客松活動預計將於 2015 年 1/31、2/1(六、日)兩天,無論你是軟體開發者、硬體開發者、設計師還是學生,都歡迎來參加!而且,一樣會有神秘講師!

OwaViewer 釋出!不用安裝肥滋滋的 Qt 也可以開發 QML!

圖片
在國內,很多人或許對 Qt 很陌生,但這一直是筆者近年來想要推廣的技術,尤其是 QML 這個自 Qt Project 衍生出來的新 UI 技術,更讓人著迷。具有原生效能和擁有炫麗效果的 QML ,確實是一個打造產品的好東西,如大家近來所聽到的 Tesla 汽車、Jolla 手機等,其 UI 就是使用 QML 所開發。當然,之前舊文章中所展示的 UI 和介面,以及能跑在 Android 手機上的 OwaNEXT,也有不少是結合 QML 技術所開發。
推廣過程中總有人質疑,覺得 QML 不是一個設計師能學會的東西。事實上,它的語法相當簡單且模組化,所以也聽聞一些國外的設計公司,其設計師都直接用 QML 做出 UI ,再交給工程師去接上功能。這也是為什麼 HanGee 國民機在開發手機和各種裝置的 UI 時,要選用 QML 為底層的原因了。

因此,筆者自己的公司最近也在籌備許多課程和分享,也與許多朋友成立了一些社群(你可以在 Facebook 加入我們的 Qt @ Taiwan 社群),並設計開發一些相關的工具,以協助更多人能更快速進入到 QML 的世界。不過,因為 UI 與設計師更密切相關,近期應該會針對不懂技術的設計師,推出許多相關的 UI 開發課程。(如果你對這樣的技術有興趣,歡迎與我們聯絡)

其實,這次的黑客松活動與 HanGee 社群合作開設 QML 課程就是一個嘗試,也想收集一些 Qt/QML 初入門者狀況和資料。其中發現一個最大的問題是,無論是技術還非技術人員(如設計師),在安裝 Qt 時就會碰到各種狀況,而且 Qt 開發環境因為功能繁複且龐大,安裝一整套下來要花上不少時間,在學習上也就是一個阻礙。這對技術人員來說,可能不是什麼大問題,但這對設計師來說,就是一個極大的挫折。

因此,我們、講師和 HanGee 社群合作,開發了一個新的工具『OwaViewer』。原本這個工具只是被設計來開發 HanGee 手機介面,但現在可以用來讀取和執行一般的 QML 檔案。這意味著,你再也不需要安裝 Qt 和學習一堆知識,就可以使用 QML 開發使用者介面了,也可以很容易提供一個成果給客戶直接操作,這對許多設計師來說應該是個好消息。

OwaViewer 是個 Open Source Project,專案網址: https://github.com/HanGee/OwaVi…

逼自己思考:嘗試再次思考 UI 設計

圖片
雖然自己從小喜愛設計,殘害過不少紙筆和滑鼠,但也因為懶惰和時間有限,長大後開始比較少開始動手自己做一些設計。所以,除了突然有一些想法和點子之外,多數時候都會把『設計』這件事推給『設計師』來做,講好聽點叫術業有專攻,講不好聽點就是有想法卻不行動的懶惰派。

如許多人所知,我這幾年一直都在做 JavaScript OS 的開發,嘗試把 JavaScript 應用在各種大大小小的硬體和裝置之中,使嵌入式應用的開發工作更有效率和彈性。又由於這一年來物聯網(IoT)的風潮大爆發,也因此有更多人使用 JavaScript 為基礎的開發,或是形形色色的跨界需求,讓我需要更多時間和金錢去投入這些發展。

不過人總是視覺化的動物,任各種應用發展再多,眼睛看得到的 UI 仍不能缺少。開發的過程中,難免會有一些『有螢幕』的應用。這也是為什麼這幾個月 HanGee 國民機一直在做『OwaNEXT』這樣的 UI 設計工具,而我最近也時常去思考一些 UI 的設計。

如下面展示影片,就是最近這幾周所嘗試開發出來的一個 UI 選單介面概念原型,雖然說是概念原型,但實際上是可以使用的程式,不是一個純展示動畫(畢竟我仍然是一個程式開發者 :-D)。這個 UI 因為是設計給大尺寸螢幕所用,所以是用『Everywhere』為出發點,讓人可以在任何一個地方憑空叫出選單,效果和使用方法都是以一個手掌可掌控為目標:



話說,我一直都不是個走純 Web 路線的開發者,過去有好幾年完不碰 Web 開發,只因為當時 JavaScript 和瀏覽器的效能和效果讓我很不滿意,然後也發現因為太依賴瀏覽器,讓自己的視野窄了許多。也許是因為這樣,這些年許多從前端所發起的各種 UI 設計討論,我沒有接觸太多,也沒有被同化成一份子。

所以,大家在前端很熟悉的 UI 切版、排版等等平常再不過的工作,對我來說反而都是可以再思考和需要再質疑的東西,也仍然保留著強烈的好奇心和探索的意圖。所以最近一直在思考設計 UI 時,一直在想『跳脫出 2D 排版的思維』這個議題。

不知道是因為工具的關係,還是設計方法的關係,現今的 UI 設計,總跳脫不出平面排版的框框,這個東西擺左邊一點、擺高一點、放大一點等等修改,一直是現今許多 UI 設計的討論重點。很少聽到在討論,這個速度要慢一點、緩一點、從哪開始、又從哪定位。

是的,因為討論到這些東西,就會開始討…

Hankathon 黑客松專用倒數計時器!

不用覺得奇怪,Hankathon 沒有拼錯,這是取自 HanGee + Hackathon 的命名。是這次為了 9/20 - 9/21 兩天的 HanGee Hackathon 活動,設計的一個騷包倒數計時器,也是我在邊辦活動邊做的成果之一,用來提醒眾參加者們,時間正在毫不留情的流逝!




Source Code: https://github.com/HanGee/Hankathon

如果你的黑客松、活動需要用到這個倒數計時器,歡迎取用!也歡迎修改成你想要的功能!只是,如果可以的話,麻煩留下蕃薯的小圖,協助讓 HanGee 亮點像吧!:-)

後記

這次的黑客松活動,就在經歷過兩天美好的夜景、日出景色,最後經歷颱風大雨的情境下落幕。雖然中間出了一些烏龍,仍有一些朋友們沒有被好好照顧到,但都在歡樂的氣氛下和滿滿的產出中結束。下我們肯定會再次舉辦,讓更多無論有沒有資身技術背景的朋友,都能夠共同參與並學到東西和經驗回家。:-D

此外,如果有社群或企業想要一同舉行下次的 Hackathon,歡迎連絡我們!

【萌典 x HanGee x DOITT x 黑客松】睡不著嗎?那就不要睡了!

熱血的開發馬拉松活動(Hackathon)來囉!讓我們吃吃喝喝、不眠不休地設計應用吧!一群素不相識的設計人,無論是程式設計師、視覺設計師、UI/UX設計師,還是任何一種從事『設計』和『開發』工作的人們,在短短有限的時間內組隊並相互合作,一起投入設計同一個專案,與不同隊伍相互較勁!

這次萌點、DOITT 和 HanGee 合作,將於 9/20 - 9/21 兩天,聯合舉辦 80 人不中斷黑客松活動,熱血的朋友們,快來報名並幫忙宣傳吧!如果你願意贊助,也歡迎聯絡!

報名網址:
http://han-gee.kktix.cc/events/hangeehackathon201409

讓我們回歸原點,什麼是黑客松呢? 由於這幾年國內舉辦過很多大大小小的黑客松活動,大多數人對於黑客松早就耳熟能詳。不過,除了由技術背景的單位和社群自發性舉辦的活動外,許多黑客松活動,比較像是純粹的比賽,讓許多團隊來展示自己研發已久的專案或產品,慢慢脫離了開發馬拉松的原意。所以,因此不免也有許多人對黑客松產生誤解,覺得就只是個普通的比賽活動。

事實上,和時下流行的路跑活動一樣,黑客松並也不是個普通的比賽活動,而是一個讓設計人在閒暇時間,參與的開發運動。解放自己,做自己想做的設計和開發,挑戰自己,在有限時間內做出東西來,才是黑客松活動的原始目的。
我能參加嗎? 對開放社群的朋友們來說,『黑客松』已經是一個再熟悉不過的名詞了,但對普通人來說,只要看到『黑客』兩個字,就覺得是一個敬而遠之的東西。不只如此,很多技術人員和設計師也對這活動有所誤解,覺得一定要非常有實力才能參加黑客松活動。

其實,黑客松和路跑活動一樣,並非只有專業選手才能參加。只要你有興趣、想實際參與多人設計和開發,無論你是學生、普通程式人員、還是新手設計師、初級自造者,都歡迎帶著學習、共樂的心前來參加!

你可以來找人一起完成自己天馬行空的想法,也可以和別人一起完成其他人的鬼點子,亦或是在這找到同伴共同想出新點子!
我能得到什麼? 在這活動中,參加者將帶著愉快的心情前來,一邊吃吃喝喝交朋友,一邊與從未合作過的朋友和高手們組隊,做出作品!然後你會發現,因為只有短短的一兩天,大家將使出混身解數,在短時間內做出出乎意料的驚人成果。最重要的是,也能從其他高手身上學會不少東西!兩天所獲得的東西,絕對物超所值!

此外,黑客松就像微創業,有限的時間、有限的…

嘴炮不再!MDS 加密檔案系統釋出!

台灣的電玩機臺一直是一個很少人探討的遊戲產業,他們外銷機台到國際各大賭場,除了一直在設計讓人願意掏錢的有趣遊戲機外,也真真實實用到很多資訊科技。在多年前一次南部的經驗,有幸接觸到這樣神秘的產業,也幫他們開發過一些東西。而其中一項專案,就是一個加密檔案系統,讓他們可以保護他們的遊戲程式,避免被對手輕易偷走自家的程式。
於是就有了這個 MDS 檔案系統(Middle Stone Filesystem),採用 blowfish 演算法加密,支援 384-bit key 和同時多組 key 的存取。由於作業系統本身會很容易破解修改,要保留可以將解密工作和 key 放在額外的硬體鎖或晶片上,甚至是多組 key 可跨多個硬體晶片存放,增加破解的難度。所以因此也設計了一些單獨的讀取工具範例,讓硬體鎖的開發人員,可以參考做法,寫在其硬體韌體(Firmware)中。不過,更近一步和硬體整合的版本,礙於敏感,這次就沒有釋出了。

專案網址: https://github.com/cfsghost/mdsfs

其實,這專案多年來一直對周圍的朋友嘴炮說要開放出來,可是一直沒負諸行動(當然也是因為懶惰)。而今天看到 iCloud 被破解的新聞,受到一點資料安全問題的刺激,於是想起這個專案,所以就花點時間挖出來整理一下文件並往 Github 上丟。由於,這個基礎版本很久沒維護了,安全性如何我不能保證,但拿來做學習 FUSE 和加密演算法應用,倒是有點參考價值。如果有人想要接著開發,也非常歡迎!
另外,有些人反應不知道能拿來幹麻。關於這件事,其實把 MDS 當做一個簡單的加密打包工具,也是可以的。 後記 看到 iCloud 被破解的新聞,不由得讓人重新思考雲端和未來物聯網時代,資料安全的重要性。稍為瞭解真象的人通常都會跟你說,千萬不要相信任何人,將東西和隱私放在雲端。而通常你第一個要害怕的是雲端系統管理人員和系統設計人員的操守,他們是不需要經過任何破解手段,即可全權存取你資料的人。再來,我們要擔心的是系統的安全性,設計者和管理者能否真有能力去保護使用這的資料?這從使用者手上的 App、作業系統、瀏覽器,一直到雲端上的一切系統,都是必需要考量的範圍。也因為這樣種種的複雜情境,使用者實在難以得到真正安全的保護。

原因其實很簡單,當檔案自你手邊的機器準備發出去的一刻開始,你的資料便以明碼的方式在程式、…

【Node.js 小密技】使用 crypto 模組亂數產生字串

已非常熟悉 Node.js 的人都知道,crypto 模組是一個無中生有的神器。我們可以用它的 API 加工加密資料,也可以解開加密後的包裹。既然和密碼處理相關,當然也有亂數產生器,可供開發者產生一大堆的亂數資料。

如果你需要一個 32Bytes 長度的亂數資料,可以直接呼叫 crypto.randomBytes() 並帶入長度後生成:
var crypto = require('crypto'); var buf = crypto.randomBytes(32); 註:回傳的結果 buf ,是一個 binary buffer,而每一個 Bytes 都會是範圍在 0 ~ 255 (0x00 ~ 0xff)的數字。

不過,在多數應用中,我們更常需要一個亂數字串,而非二進位的亂數資料,這時就需要做一些進一步的加工處理。方法其實不只一種,如建表、取代不可見字元碼等方式都可以,沒有標準做法。但懶惰的開發者們,多半是直接利用 Buffer 內建的 API 來將資料轉換成字串,並指定編碼方式來達成。

下面兩種方法都可行:
buf.toString('hex'); buf.toString('base64');
只是,使用十六進位(hex),會讓你的最後的字串單純只有 0-9 和 a-f 的字元存在,所以使用 base64 是比較好的選擇,讓字串多變並複雜些。

註:base64 編碼是以 6 bits 為單位來進行處理,而 1 Byte 有 8bits。如果你的資料長度非 6 bits 的整數倍長度,base64 會在結尾補上『=』。有些人覺得多了一些『=』符號很醜,就會用 replace() 替代掉或者是一開始就取 6 bits 整數倍長度的亂數資料(如:3 bytes、6 bytes 等等)。

有些情況,我們需要特定長度的亂數字串,也可以搭配使用 substr(),只是要確定生成的字串長度,比我們想要的字串長度還要長。下面的範例,就是取八個字元長度的字串:
buf.toString('base64').substr(0, 8);
當然,若你想要一次搞定,也可以將之前所說的,全部串在一起寫:
var randomString = crypto.randomBytes(32).toString('base64'…

我的創業原點:科技和藝術的結合

圖片
看到時不時有新聞在報 POS,一時興起,就去把舊照片翻出來,沒想到癮科技還保留了快十年前的照片和報導『義大利咖啡館-科技和人文的結合』。

這套 POS,是在當時在經營 Coffee Shop (以現在的角度來看,其實是半個 Working Space)時所開發的,店在板橋江子翠捷運站旁(建築物前還有一座三層樓高的羅馬柱),共三層樓約四五百坪左右,店裡沒有對外掛招牌並擺滿了各種收藏品和古董家具,不知道的人看起來像間古董家俱店,不太敢進來,所以來的都是慕名或是口耳相傳,以及喜歡我們咖啡的人,因此也有人以『神秘咖啡廳』稱呼。

不過,Coffee Shop 其實一直不是主業,只是公司的招待、展示中心和團隊休閒區,而應用、工程、軟體開發和軟硬體整合的產品開發才是我們主要的工作。所以我永遠窩在店裡的某一角,寫著我喜歡寫的程式,周遭來來去去的客人並不真的清楚我是誰。

還記得,點餐系統軟體、平板硬體和後面印單系統整套做出來並實際上線,大概是在 2004 年(大概是高二時),報導則是 2006 年的事了。而且因為這套系統和管理流程設計,讓幾百坪的店面,只需要一兩個人就可以完全掌控、經營和服務,讓我們著實省下不少功夫。雖然很懷念當時的日子,但一想到惡房東後來給我帶來的多年痛苦,以及官司上的問題,至今我仍然還是恨的牙癢癢,因而有很長很長一段時間,我絕口不提這段往事。

所以這也是為什麼,多年後看到這標題,感觸極深,當時『科技與人文的結合』和『科技與藝術的結合』這個標語,一直都掛在店裡的展示大螢幕上,因為這是我們自己對設計的最高期許,也是一直身體力行的方向。許多進進出出拜訪我們的人和國內外大佬們,應該多少都看過。只是後來大多數人再次使用這段話時,是在多年後 Apple 的產品身上,這也算是種台灣的悲哀吧。

很多人不知道,我其實非常喜歡喝咖啡,甚至會燒,只不過後來若不是真的跟我很熟的人,可能從來都沒看過我喝。當時店裡的紀念款 La Marzocco 機器,現在還好好保存著,期盼哪一天能夠在我比較穩定的時候,再次拿出來使用或是與朋友分享。

不曉得還有多少人記得我們這家店?但無論如何,總有一天,我會讓他復業。不為別的,就為了從小所抱著的夢,這是我一頭栽進創業和改變世界的原點。

Express 4 來了!好用的 Router 機制

還記得前陣子,就在書將出版之際,半路殺出來最新的 Express 4,使得筆者手忙腳亂,緊急通知出版社修改書的內容。將所有使用到 Express 的範例,都特別加上版本號的指定,讓讀者在照著範例做時,能夠使用舊的 Express 3.0,而不會發生任何問題。最新的 Express 4 雖然效能提升不少,也有一些好用的新東西,但和舊版有些微 API 的不相容,此外,也因為是新東西,可能很多東西的支援會發生問題,如果舊版本在上線的產品中運行相當穩定,建議先不要急著升級。

Express 4 做了一些改進,有不少新東西,其中相當值得提的一項就是路由機制(Router)的翻新。如果你以前在使用 Node.js + Express 開發網站服務時,因為 Router 很難管理而痛苦不已,這將是一個你會愛上的功能改進。

傳統的使用方法傳統的 Router 設定方法依然可以運作,我們可以放心使用。

var express = require('express'); // Create express application var app = express(); // Apply this router on (/apis/user) app.get('/', function(req, res) {     // Home }); app.listen(8000);

新 Router 物件的使用方法範例除了舊的方法之外,你可以用 Router() 去建立一個 Express 的 Router 物件,然後管理你一系列的路由規則。

var express = require('express'); // Create express application var app = express(); // Create a router to handle routes for a set of  user API var userAPI = express.Router(); // Sign in (/apis/user/signin) userAPI.post('/signin', function(req, res) {     // ... }); // Sign out (/apis/user/sig…

Feature-oriented Programming with Node.js

Feature-oriented Programming(FOP)這個名詞對很多人來說應該相當陌生,這是一個鮮少人討論的開發模式,尋找了一下,也找不太到中文的說明和翻譯,所以我就暫時稱它為『特色導向程式開發』。如果你有興趣,可以去搜尋它,或使用關鍵字『Feature-oriented Software Development』找到更多資源。也有一個以 FOP 概念所改良的 C++ 語言『FeatureC++』,可以參考。

因為筆者眼前專注於 Node.js 的發展,所以也用 Node.js 實作了一非常個簡單的 Framework 『wag.js』,讓我們可以在 JavaScript 語言的環境下,引用 FOP 的開發概念來設計軟體。你可以用 npm 直接安裝他:

npm install wag.js
之所以會一時興起研究 FOP,是因為多年以來,一直為了重覆開發所苦,很多相同的東西一直不停重覆做了又做,總覺得自己一直在浪費時間,所以想試著尋找個方法來改善眼前的窘境。最麻煩的問題在於,雖然早就應用了許多模組化方法,我們也能把很多功能事先做好打包好,但仍然像個有數不清節點的連連看遊戲,讓人花不少時間在上面編織程式軟體。重點是,當其中有絕大多數的過程是一樣的時候,總讓人做得很無力。

你可以想一想,當你想要寫一個新的專案時,你通常最大的阻力是什麼?又有多少繁雜的事,每次開新專案時都重覆在做?而最令人煩燥的是,因為專案類型的不同,有些微的差異,所以難以用一個標準自動化的方式去完成。

這也是一般人和工程師最大的差別,甚至是造成溝通不良。一般人總是想著是我要什麼功能、再增加哪些功能;工程師則是一直在想著,我要挑選使用哪些功能模組,又該怎麼從數不清的可能中,選一個可行的方法組裝他們?如果想成捏黏土來比喻,一般人會捏個大概形狀,再往上慢慢堆想要的東西,慢慢趨近成果,而工程師會捏好各個部位,再把他一一拼湊起來。

我想,當你能回憶起客戶或老闆跟你說:『這功能很簡單,你應該能馬上做好』,你應該就能更明白我所說的,一般人與工程師的思維差異。不過,事實上,工程師思維和一般人沒兩樣,也是把東西堆起來,只是,工程師所設計出來的各種部位的元件,總是很難拼湊在一起,必需要花些功夫。

到底,有沒有什麼辦法,可以減少各種元件和功能模組的拼湊困難呢?讓我們可以更專心的做一個有更多功能的產品?或是更快將產品…

不一樣的 Node.js!終於完成的新書前來報到!

圖片
這陣子,最怕的就是有人問:『書什麼時候要發行?』,參加社群聚會或活動時,有人會問我,平常周圍朋友也會問我,工作上隊友和客戶都會問我,只有一些親人根本不知道不知道我在寫書,所以不會問我。如果你問我,寫書這件事上,你最怕的是什麼?我會跟你說,出版社截稿日期的死線(Deadline)並不是最可怕的,最可怕的是,它是一種詛咒,讓周圍人都會特別關心你的一種魔法。而這個關心的壓力,讓人喘不過氣來。

還好,書總算從初稿、校稿到排版完成,直到出版社編輯傳來最後的封面設計,才讓人鬆了一口氣。可以告訴大家,書總算要真正出來了!



事實上,國內 Node.js 的書其實並不多,其中幾乎多為翻譯書,或是從簡體直接翻成繁體中文的書。這讓這幾年一直在到處推廣 Node.js 的我,相當困擾。每當有人問起 Node.js 有什麼書可以看時,我總是無法推薦出很多本給大家參考。所以,當出版社的編輯跟我說,希望寫一本 Node.js 的中文書時,我其實相當開心。

還記得當時接下這個任務後,我便開始思考和回想,在推廣和使用 Node.js 時,所遭遇到的困難是什麼?我能否藉這本書來幫助讀者排除這些困難?甚至給讀者一個更大的視野,一個 Node.js 可以發揮在各種領域的可能性。

此外,網路時代來臨後,有太多的新資料都可以從網路上取得,這本書要提供什麼內容,更是需要被探討的問題。尤其是 Node.js 這樣版本號快速上升的新技術,可能書還沒寫完,內容就已經過時。在種種思索下,期望本書的定位,將帶給大家的不是絕對的技術新知,而是一本學習 Node.js 的參考書和技術指南,讓想入門的讀者可以學會怎麼使用 Node.js,讓已經懂的人可以知道 Node.js 還能做些什麼不一樣的事,更進一步知道從哪裡去得到更多 Node.js 的新知。如果這本書在幾年後,仍有六成的資料值得參考,那就算完美達成我賦予它的任務了。

從引領初學者的角度來看,並參考了一些市上的 Node.js 書籍,也從過去教育訓練和推廣的場合發現一個現象。Node.js 不是什麼很難的新東西,如果有人已經很熟悉 JavaScript 語言,而且能寫的很好,Node.js 根本是小菜一碟。所以,多半不得其門而入的人,是對 JavaScript 不這麼熟悉,或是想使用 Node.js 技術進行第一次接觸程式開發的人。只不過,往往市面上的 Node.j…

OwaNEXT 計畫來吧!不懂技術也可以設計可用的 Android Launcher!

圖片
自 HanGee 國民機運動發起之後,我們開始從一個全新的思維和高度,來看待這個手機科技產業到底需要些什麼東西,甚至是創新發明這件事的困難是什麼。尤其是排除掉鬼遮眼的短線商業問題後,專注考慮怎麼讓產業提升、科技產業改變,更可以發現有很多東西是我們可以去嘗試的

其中,使用者介面(User Interface、UI/UX)是一個相當重要的課題,當人類和使用者越來越依賴顯示和觸控技術與機器溝通,虛擬形式的使用者介面就更是不可缺少。因此近年來,這也是許多科技人之間的熱門話題。只是,在我們深入了解後發現,仍然存在許多可以改進的空間。

講可以改進,並非是我們真有一個絕佳的 UI/UX 想法,或是覺得現今已經存在的使用者介面和模式有什麼不好,而是我們認為,設計方法和工具有很大的進步空間。我們都相信,在手機產業蓬勃的今天,設計師們早就已經花了大量時間去研究使用者的行為,並為其設計出不少使用者界面,甚至直到此時此刻,世界上隨時都有新的 UI 被設計出來。不過最大的問題是,設計師腦中的想法很容易被創造,但可以用的原型(Prototype)卻難以被製造出來,需要很大的成本和很高的門檻。

的確,打造實際可以用的原型(Prototype)無論在哪裡,一直都是人類進步的過程中最大的問題之一,更可怕的是,往往人類的思考和創意,都因為牽就工具和打造原型的方法,而受到挶限。還記得在你設計出一個自認傑作的使用者界面當下,工程師告訴你做不到時,你有多麼難過嗎?還記得你告訴自己開始要有 Sense 的去設計 UI 後,你總是設計出平淡無奇的作品嗎?這些都是我們被制約的實際例子,當我們無法很容易取得或使用多彩多姿的顏料,我們就只能畫沒有色彩的素描,你我的創意和創作就沒有了明天。

那麼,我們可以做些什麼呢?

事實上,就在 HanGee 國民機運動開始不久後,筆者就建立了一個『 UI 先進技術研究組』,並創造了一個名為 OwaNEXT 的專案,試圖找尋協助設計師更快打造出 UI 的方法,然後進一步設計出可用的工具。如果可以讓不懂程式技術的人和設計師,都能輕易打造出可用的 UI 原型,而且能夠真正直接被使用在實際環境上,勢必能讓 UI/UX 領域的工作和視野往前跨更大一步。

OwaNEXT 的名字由來,一方面是以 Owa (芋頭的台語念法)來呼應蕃薯(HanGee),另一方面是向已逝的 Steve Jobs 所…

Node.js 的原罪,和 QML 的不合作運動

在上個星期剛結束的 OSDC.tw 2014 活動上給了一個 Talk ,提及用 Node.js 結合 QML 來開發應用程式,讓我們可以使用 Node.js 和 JavaScript 來寫 QML 元件,不需要再使用 C/C++。事實上,這樣的技術看起來簡單,但實際上是困難重重。

其實,要做 Qt 的 Node.js binding,有很多問題要克服,最直接的不外乎是 Event Loop,Node.js 本身是 JavaScript 語言,所以有自己的事件引擎,而 Qt 是一個圖形界面的 Toolkit,一樣也有自己的事件引擎,因此,我們要再解決一次與過去整合 GLib 一樣的問題(詳見舊文:探究如何整合 GLib Main Event Loop 和 Node.js 的 libuv),只不過這次要實作的是 Qt 的 QAbstractEventDispatcher。

為了讓 Node.js 可以順利驅動 Qt,筆者之前花了一些時間研究,所以有了一個實驗性質的 Project 『Brig』在 Github,也為了 Qt 重新寫了一個新的 libuv 版本的 EventDispatcher。很幸運的,在實作完新的 EventDispatcher 後,已經可以順利的將 Node.js 和 Qt 的 Event Loop 接起來。

但別高興的太早,還有個大問題存在。Qt 5.2 之後將 QML 內的 V4 JavaScript 換成了 Google V8 JavaScript Engine,並且為了一些特性,修改了 V8 的部份實作。很不巧的是,Node.js 的核心也是 V8,這意味著,如果我們使用自己的 Node.js Binding 去建立 QML Engine,程式會馬上崩潰並結束(Segmentation Fault)。

種種問題,你可以說這是 Node.js 的原罪所致,這也是為什麼相當難幫 Qt 寫一個 Node.js 的 Binding,你在 NPM 上也根本找不到良好的 Qt Module 存在。最終我們的做法,還是修改了 Node.js 的部份程式,才能將他們整合在一起。

【OSDC.TW 2014 簡報釋出】當 QML 娶了 Node.js

圖片
去年一年在萬里當兵,基隆對我來說就像旁邊的公園一樣,時常去走走逛逛,然後去廟口吃點東西,最後吹吹帶有奇怪味道的海風,然後依依不捨的回去萬里山中隱居。很遺憾,黃色小鴨在我退伍的第二天,才來到基隆,一直沒機會去看看牠,這也是為什麼我為這次的 Talk 取了一個這麼奇怪的題目。當然,在 OSDC 的活動上,大多數人無法理解這樣奇怪的主題,所以我也在場上直接換了一個時事標題,詳見已釋出的簡報檔:



本次簡報的主題,將提到如何使用 Node.js 開發一個 QML 應用程式,以及如何使用 Node.js 去括充 QML 的功能。QML 能讓開發者很快設計出極酷炫的 UI,但最大的問題是他擁有一個殘廢的 JavaScript 支援,所以任何額外的功能擴充,都必需學會 C/C++ 才能達成,相當的難以開發。

此外,在過去如果 QML 要與 Node.js 做橋接,通常都是以 Node.js 建一個本機的 HTTP Server,然後運用 QML 內建的仿 XHR(使用方式和 API 真的完全模仿),去本機 HTTP Server 要資料。或許這對很多 Web 開發者來說相當容易上手,但有趣的是,他不會有 jQuery,所以你要自己手刻 Ajax 的各種機制,甚至是 Long-polling,痛苦至極。

想一下,我們即便是要與本機溝通,取得或監聽機器上的一些資訊,都要使用 Long-polling,這未免也太小題大做,一點也不簡單和直接。所以這也是為什麼要做 Qtjs,讓我們可以用 Node.js 直接來開發 QML 的元件,直接與 QML 溝通和傳遞資料,而不必再透過 HTTP 的方式。

就以本次簡報的例子來說,我們用 QML 設計了一個 IRC 聊天室的前端,然後運用 Node.js 和第三方模組去連線到 IRC Server,最後把聊天內容收回來畫在 QML 的界面上。並使用 Node.js 設計了一個 QML 元件,使用方式如下:

IRC {     onReceived: {         console.log(nickname + ': ' + message);     } }
註:過去開發 QML 元件必需使用 C/C++,現在用 Node.js 即可開發。

這次的範例程式,可以在 Github 上取得:

https://github.com/cf…

HanGee 國民機運動

圖片
你可能已經知道,我最近相當忙錄,到處奔走,犧牲睡眠,不為別的,就是為了 HanGee (台語發音:蕃薯)國民機運動。過去,心中一直抱持著想改變產業、改變世界的想法,雖然一直在用自己的方式推進,但總是缺少契機去做更大的發展。令人相當意外的是,這次一樣是在自己的 Facebook 動態上許願,許了親手打造國民機的機會,本以為如同過去一樣會石沉大海,但換來的是短短兩天內,幾千個讚的回饋和熱烈支持,一直到現在,關注的人、企業和媒體也越來越多。


說實在的,剛開始我僅僅只是想藉由自己的手,完整參與打造一支手機。但是到了今天, HanGee 國民機運動的目標,已經不僅僅是打造一支手機,更重要的是,藉由打造手機的過程,讓世界能透過『HanGee』看見台灣的科技實力和人才;集結有想法,有能力的人們在這個開放創新的過程中發光發熱,共創價值。

這一個多月以來,看到許多業內外的設計、科技、行銷企劃、學生和富有想法的人才陸續加入,更讓我覺得,當我們能夠靠自己發願的力量,把世界上這最複雜的科技產品打造出來,實踐改變和刺激產業昇華的夢想將不是遙不可及!

我想,這個共創的過程一定能造就無數種創意可能,而創意最後的落實能力,就是台灣的產業優勢,或許也讓我們在社群共創的開放歷程中邀請他們,HanGee 將試圖打造一個完善的開放平台,廣納各方的想法和資源,然後藉國內產業的能力優勢,進一步成就共創價值。如果 HanGee 運動能成功,除了一支手機會誕生,屆時,這裹也將證明台灣是世界上各種創意的實現中心,世界創新的凝聚地。HanGee  開放創新的構想是一場台灣科技公民的冒險行動,歡迎人人都加入了這個未知且令人興奮的旅程。

接下來,HanGee 將會隨著打造手機的過程,逐一建立起線上共創(Co-creation)平台,包括投稿平台、解決方案整合平台等,並著手打造許多工具和標準,讓各界都能參與過程,建立對話平台,讓產業也能持續創造價值。

有興趣的人可以造訪 HanGee 的官方網站:
http://han-gee.com/

也歡迎加入 HanGee 的 Facebook 社團,貢獻你對國民機的想法,或是出一份力讓我們更接近目標:

https://www.facebook.com/groups/HanGee/

無論你是個人還是組織單位,無論你是否為科技圈的人,亦或是學生,都可以參與計劃,共同打造出心目中的國民機。…

沒經驗,就別擅做主張

這幾年下來,有一種感觸,覺得自己可以為為某行業做些什麼,是一種錯誤的思考模式,原因是我們根本就沒參與過這個行業,自己憑什麼認為自己的方案是有效的?再者,又有什麼人願意承擔風險,讓你做大量實驗證明自己的想法?在這種情況下,當你做越多,越可能是他們用不到且無法接受的東西,完全失敗也就指日可待。

想要改善,就要親自接觸和體驗,這也是為什麼有些成功的管理者,會跳下去基層做起,感受問題所在。事實上,挖黑幕只是順帶的工作,主要還是找出真正可以改善的問題。

所以,行銷企劃人員雖自己不知道,但會正確使用辦活動和引進噱頭的方法去包裝想法,一方面是就算活動不成功,也只是短暫且單次的實驗失敗,就算發現想引進的想法不可長期使用,也至少在第一時間獲得人流和其他的利益回補而達到損益平衡。

我們必須注意,如果我們沒煮過菜,沒有像快炒店那樣大量煮菜的經驗,我們就不要想設計一個改善煮菜工作的好用鍋鏟。你以為廚師會給你機會而用你的東西?先不論他們會不會買單你的想法、你的想法是不是真能改善你要改善的問題。至少廚師們從一開始就會先入為主,不認為你的東西會是好用的,那怕是他們自己的問題,只要有一次煮出來的東西難吃,他們就會認定你的方案存在問題。還沒切入正題前就阻力重重,失敗機率非常高。

另一個更直接的例子,身為程式開發者,如果你會相信完全沒開發過程式且沒經歷過軟體開發專案的管理者,在無知的情況下,可以設計一套管理流程和工具,或引進一套高科技,幫助你更快速完成你的程式開發工作。那麼,你就繼續自我感覺良好,覺得自己可以為某自己毫無經驗的行業做些什麼吧。:-S

註:會寫程式的人很幸運,就像全民超人中的 Hancock 一樣,有不凡的超能力。但我們要學會控制和感受,才可能很好的發揮能力在正確的地方。

Web 技術中的 Session 是什麼?

圖片
很久沒更新了,自從十二月底退伍之後,一直忙著將書完稿給出版社,沒空坐下來好好在 Blog 上寫點東西。沒辦法,在當兵時閒不下來,就答應了出版社的邀約開始寫 Node.js 的書,因此欠下了書的債。還好,如預期的寫完了,預計這一兩個月應該就會上市,還請各界多多捧場!
會寫這篇文章的原故,是因為在 Facebook 的社群上,有人問起了關於 Session 和 Cookie 相關性的問題。其實,社群的人都很好,有許多熱心的網友願意幫助別人。不過,為了幫忙回答問題,大家七嘴八舌的東說一句西說一句,甚至引起莫明的論戰,實在不是一個好的現象。況且,使用不同語言、有不同技術背景的人,都各自用自己的角度去描述和解說,讓原本就已經不懂的人更有如瞎子摸象,見不到全貌,搞更糊塗了。對發問的人來說,也不知該聽誰的好。
說來湊巧,筆者剛好在剛截稿的 Node.js 書籍中,對 Session 概念也有許多著墨。所以之前稍微在網路上查過,發現鮮少有人提出對 Session 技術的完整說明,而多半是討論 ASP、.Net、Java、PHP 等語言或框架中如何使用 Session,以及一些延伸的特性,以致很多人對 Session 的概念相當片面。因此這次的事件後,一些網友也建議我把在 Facebook 上回應的完整內容,在 Blog 發表記錄下來,讓更多人對 Session 有個比較完整且正確的認識。
本文目標
在 Web 的世界裡,Session 已經是被廣泛使用的一種技術,大多數的 Web 開發者,肯定都能運用自如。在現今的各類 Web 應用程式的開發框架和工具中,Session 也已經被包裝成容易使用的模式,所以本文也就不再多討論 Session 怎麼去使用,而是著重在 Session 的原理和實現上。要知道,無論是使用哪一種語言,這 Session 概念上都是通用的,沒有什麼不一樣。
Session 是什麼?
Session 之所以會存在,是因為 HTTP 為 stateless 的設計,Server 和 Client 不會一直保持連線狀態,也不會有雙方狀態的即時更新,所以,Server 並不知道 Client 的狀態(像是是否已經登入)。因此,後來的網站開發者,採用 Session 這樣的設計來解決這問題。有趣的是,Session 機制在最早的 CGI 年代,是完全要程式設計師徒手寫出…