Fred's blog

不用覺得奇怪，Hankathon 沒有拼錯，這是取自 HanGee + Hackathon 的命名。是這次為了 9/20 - 9/21 兩天的 HanGee Hackathon 活動，設計的一個騷包倒數計時器，也是我在邊辦活動邊做的成果之一，用來提醒眾參加者們，時間正在毫不留情的流逝！ Source Code:  https://github.com/HanGee/Hankathon 如果你的黑客松、活動需要用到這個倒數計時器，歡迎取用！也歡迎修改成你想要的功能！只是，如果可以的話，麻煩留下蕃薯的小圖，協助讓 HanGee 亮點像吧！:-) 後記 這次的黑客松活動，就在經歷過兩天美好的夜景、日出景色，最後經歷颱風大雨的情境下落幕。雖然中間出了一些烏龍，仍有一些朋友們沒有被好好照顧到，但都在歡樂的氣氛下和滿滿的產出中結束。下我們肯定會再次舉辦，讓更多無論有沒有資身技術背景的朋友，都能夠共同參與並學到東西和經驗回家。:-D 此外，如果有社群或企業想要一同舉行下次的 Hackathon，歡迎連絡我們！

熱血的開發馬拉松活動（Hackathon）來囉！讓我們吃吃喝喝、不眠不休地設計應用吧！一群素不相識的設計人，無論是程式設計師、視覺設計師、UI/UX設計師，還是任何一種從事『設計』和『開發』工作的人們，在短短有限的時間內組隊並相互合作，一起投入設計同一個專案，與不同隊伍相互較勁！ 這次萌點、DOITT 和 HanGee 合作，將於 9/20 - 9/21 兩天，聯合舉辦 80 人不中斷黑客松活動，熱血的朋友們，快來報名並幫忙宣傳吧！如果你願意贊助，也歡迎聯絡！ 報名網址： http://han-gee.kktix.cc/events/hangeehackathon201409 讓我們回歸原點，什麼是黑客松呢？ 由於這幾年國內舉辦過很多大大小小的黑客松活動，大多數人對於黑客松早就耳熟能詳。不過，除了由技術背景的單位和社群自發性舉辦的活動外，許多黑客松活動，比較像是純粹的比賽，讓許多團隊來展示自己研發已久的專案或產品，慢慢脫離了開發馬拉松的原意。所以，因此不免也有許多人對黑客松產生誤解，覺得就只是個普通的比賽活動。 事實上，和時下流行的路跑活動一樣，黑客松並也不是個普通的比賽活動，而是一個讓設計人在閒暇時間，參與的開發運動。解放自己，做自己想做的設計和開發，挑戰自己，在有限時間內做出東西來，才是黑客松活動的原始目的。 我能參加嗎？ 對開放社群的朋友們來說，『黑客松』已經是一個再熟悉不過的名詞了，但對普通人來說，只要看到『黑客』兩個字，就覺得是一個敬而遠之的東西。不只如此，很多技術人員和設計師也對這活動有所誤解，覺得一定要非常有實力才能參加黑客松活動。 其實，黑客松和路跑活動一樣，並非只有專業選手才能參加。只要你有興趣、想實際參與多人設計和開發，無論你是學生、普通程式人員、還是新手設計師、初級自造者，都歡迎帶著學習、共樂的心前來參加！ 你可以來找人一起完成自己天馬行空的想法，也可以和別人一起完成其他人的鬼點子，亦或是在這找到同伴共同想出新點子！ 我能得到什麼？ 在這活動中，參加者將帶著愉快的心情前來，一邊吃吃喝喝交朋友，一邊與從未合作過的朋友和高手們組隊，做出作品！然後你會發現，因為只有短短的一兩天，大家將使出混身解數，在短時間內做出出乎意料的驚人成果。最重要的是，也能從其他高手身上學會不少東西！兩天所獲得的東西，絕對物超所值！ ...

台灣的電玩機臺一直是一個很少人探討的遊戲產業，他們外銷機台到國際各大賭場，除了一直在設計讓人願意掏錢的有趣遊戲機外，也真真實實用到很多資訊科技。在多年前一次南部的經驗，有幸接觸到這樣神秘的產業，也幫他們開發過一些東西。而其中一項專案，就是一個加密檔案系統，讓他們可以保護他們的遊戲程式，避免被對手輕易偷走自家的程式。 於是就有了這個 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 模組是一個無中生有的神器。我們可以用它的 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).toSt...

義大利咖啡館－科技和人文的結合 看到時不時有新聞在報 POS，一時興起，就去把舊照片翻出來，沒想到癮科技還保留了快十年前的照片和報導『 義大利咖啡館－科技和人文的結合 』。 這套 POS，是在當時在經營 Coffee Shop （以現在的角度來看，其實是半個 Working Space）時所開發的，店在板橋江子翠捷運站旁（建築物前還有一座三層樓高的羅馬柱），共三層樓約四五百坪左右，店裡沒有對外掛招牌並擺滿了各種收藏品和古董家具，不知道的人看起來像間古董家俱店，不太敢進來，所以來的都是慕名或是口耳相傳，以及喜歡我們咖啡的人，因此也有人以『神秘咖啡廳』稱呼。 不過，Coffee Shop 其實一直不是主業，只是公司的招待、展示中心和團隊休閒區，而應用、工程、軟體開發和軟硬體整合的產品開發才是我們主要的工作。所以我永遠窩在店裡的某一角，寫著我喜歡寫的程式，周遭來來去去的客人並不真的清楚我是誰。 還記得，點餐系統軟體、平板硬體和後面印單系統整套做出來並實際上線，大概是在 2004 年（大概是高二時），報導則是 2006 年的事了。而且因為這套系統和管理流程設計，讓幾百坪的店面，只需要一兩個人就可以完全掌控、經營和服務，讓我們著實省下不少功夫。雖然很懷念當時的日子，但一想到惡房東後來給我帶來的多年痛苦，以及官司上的問題，至今我仍然還是恨的牙癢癢，因而有很長很長一段時間，我絕口不提這段往事。 所以這也是為什麼，多年後看到這標題，感觸極深，當時『科技與人文的結合』和『科技與藝術的結合』這個標語，一直都掛在店裡的展示大螢幕上，因為這是我們自己對設計的最高期許，也是一直身體力行的方向。許多進進出出拜訪我們的人和國內外大佬們，應該多少都看過。只是後來大多數人再次使用這段話時，是在多年後 Apple 的產品身上，這也算是種台灣的悲哀吧。 很多人不知道，我其實非常喜歡喝咖啡，甚至會燒，只不過後來若不是真的跟我很熟的人，可能從來都沒看過我喝。當時店裡的紀念款 La Marzocco 機器，現在還好好保存著，期盼哪一天能夠在我比較穩定的時候，再次拿出來使用或是與朋友分享。 不曉得還有多少人記得我們這家店？但無論如何，總有一天，我會讓他復業。不為別的，就為了從小所抱著的夢，這是我一頭栽進創業和改變世界的原點。

還記得前陣子，就在書將出版之際，半路殺出來最新的 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 (...

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，是因為多年以來，一直為了重覆開發所苦，很多相同的東西一直不停重覆做了又做，總覺得自己一直在浪費時間，所以想試著尋找個方法來改善眼前的窘境。最麻煩的問題在於，雖然早就應用了許多模組化方法，我們也能把很多功能事先做好打包好，但仍然像個有數不清節點的連連看遊戲，讓人花不少時間在上面編織程式軟體。重點是，當其中有絕大多數的過程是一樣的時候，總讓人做得很無力。 你可以想一想，當你想要寫一個新的專案時，你通常最大的阻力是什麼？又有多少繁雜的事，每次開新專案時都重覆在做？而最令人煩燥的是，因為專案類型的不同，有些微的差異，所以難以用一個標準自動化的方式去完成。 這也是一般人和工程師最大的差別，甚至是造成溝通不良。一般人總是想著是我要什麼功能、再增加哪些功能；工程師則是一直在想著，我要挑選使用哪些功能模組，又該怎麼從數不清的可能中，選一個可行的方法組裝他們？如果想成捏黏土來比喻，一般人會捏個大概形狀，再往上慢慢堆想要的東西，慢慢趨近成果，而工程師會捏好各個部位，再把他一一拼湊起來。 我想，當你能回憶起客戶或老闆跟你說：『這功能很簡單，你應該能馬上做好』，你應該就能更明白我所說的，一般人與工程師的思維差異。不過，事實上，工程師思維和一般人沒兩樣，也是把東西堆起來，只是，工程師所設計出來的各種部位的元件，總是很難拼湊在一起，必需要花些功夫。 到底，有沒有什麼辦法，可以減少各種元件和功能模組的拼湊困難呢？讓我們可以更專心的做一個有更多...

這陣子，最怕的就是有人問：『書什麼時候要發行？』，參加社群聚會或活動時，有人會問我，平常周圍朋友也會問我，工作上隊友和客戶都會問我，只有一些親人根本不知道不知道我在寫書，所以不會問我。如果你問我，寫書這件事上，你最怕的是什麼？我會跟你說，出版社截稿日期的死線（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 技術進行第一次接觸程式開發的人。只不過，...

自 HanGee 國民機運動發起之後，我們開始從一個全新的思維和高度，來看待這個手機科技產業到底需要些什麼東西，甚至是創新發明這件事的困難是什麼。尤其是排除掉鬼遮眼的短線商業問題後，專注考慮怎麼讓產業提升、科技產業改變，更可以發現有很多東西是我們可以去嘗試的 其中，使用者介面（User Interface、UI/UX）是一個相當重要的課題，當人類和使用者越來越依賴顯示和觸控技術與機器溝通，虛擬形式的使用者介面就更是不可缺少。因此近年來，這也是許多科技人之間的熱門話題。只是，在我們深入了解後發現，仍然存在許多可以改進的空間。 講可以改進，並非是我們真有一個絕佳的 UI/UX 想法，或是覺得現今已經存在的使用者介面和模式有什麼不好，而是我們認為，設計方法和工具有很大的進步空間。我們都相信，在手機產業蓬勃的今天，設計師們早就已經花了大量時間去研究使用者的行為，並為其設計出不少使用者界面，甚至直到此時此刻，世界上隨時都有新的 UI 被設計出來。不過最大的問題是，設計師腦中的想法很容易被創造，但可以用的原型（Prototype）卻難以被製造出來，需要很大的成本和很高的門檻。 的確，打造實際可以用的原型（Prototype）無論在哪裡，一直都是人類進步的過程中最大的問題之一，更可怕的是，往往人類的思考和創意，都因為牽就工具和打造原型的方法，而受到挶限。還記得在你設計出一個自認傑作的使用者界面當下，工程師告訴你做不到時，你有多麼難過嗎？還記得你告訴自己開始要有 Sense 的去設計 UI 後，你總是設計出平淡無奇的作品嗎？這些都是我們被制約的實際例子，當我們無法很容易取得或使用多彩多姿的顏料，我們就只能畫沒有色彩的素描，你我的創意和創作就沒有了明天。 那麼，我們可以做些什麼呢？ 事實上，就在 HanGee 國民機運動開始不久後，筆者就建立了一個『 UI 先進技術研究組』，並創造了一個名為 OwaNEXT 的專案，試圖找尋協助設計師更快打造出 UI 的方法，然後進一步設計出可用的工具。如果可以讓不懂程式技術的人和設計師，都能輕易打造出可用的 UI 原型，而且能夠真正直接被使用在實際環境上，勢必能讓 UI/UX 領域的工作和視野往前跨更大一步。 OwaNEXT 的名字由來，一方面是以 Owa （芋頭的台語念法）來呼應蕃薯（HanGee），另一方面是向已逝的 S...

在上個星期剛結束的 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 的部份程式，才能將他們整合在一起。

去年一年在萬里當兵，基隆對我來說就像旁邊的公園一樣，時常去走走逛逛，然後去廟口吃點東西，最後吹吹帶有奇怪味道的海風，然後依依不捨的回去萬里山中隱居。很遺憾，黃色小鴨在我退伍的第二天，才來到基隆，一直沒機會去看看牠，這也是為什麼我為這次的 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++，...

你可能已經知道，我最近相當忙錄，到處奔走，犧牲睡眠，不為別的，就是為了 HanGee （台語發音：蕃薯）國民機運動。過去，心中一直抱持著想改變產業、改變世界的想法，雖然一直在用自己的方式推進，但總是缺少契機去做更大的發展。令人相當意外的是，這次一樣是在自己的 Facebook 動態上許願，許了親手打造國民機的機會，本以為如同過去一樣會石沉大海，但換來的是短短兩天內，幾千個讚的回饋和熱烈支持，一直到現在，關注的人、企業和媒體也越來越多。 說實在的，剛開始我僅僅只是想藉由自己的手，完整參與打造一支手機。但是到了今天， HanGee 國民機運動的目標，已經不僅僅是打造一支手機，更重要的是，藉由打造手機的過程，讓世界能透過『HanGee』看見台灣的科技實力和人才；集結有想法，有能力的人們在這個開放創新的過程中發光發熱，共創價值。 這一個多月以來，看到許多業內外的設計、科技、行銷企劃、學生和富有想法的人才陸續加入，更讓我覺得，當我們能夠靠自己發願的力量，把世界上這最複雜的科技產品打造出來，實踐改變和刺激產業昇華的夢想將不是遙不可及！ 我想，這個共創的過程一定能造就無數種創意可能，而創意最後的落實能力，就是台灣的產業優勢，或許也讓我們在社群共創的開放歷程中邀請他們，HanGee 將試圖打造一個完善的開放平台，廣納各方的想法和資源，然後藉國內產業的能力優勢，進一步成就共創價值。如果 HanGee 運動能成功，除了一支手機會誕生，屆時，這裹也將證明台灣是世界上各種創意的實現中心，世界創新的凝聚地。HanGee  開放創新的構想是一場台灣科技公民的冒險行動，歡迎人人都加入了這個未知且令人興奮的旅程。 接下來，HanGee 將會隨著打造手機的過程，逐一建立起線上共創（Co-creation）平台，包括投稿平台、解決方案整合平台等，並著手打造許多工具和標準，讓各界都能參與過程，建立對話平台，讓產業也能持續創造價值。 有興趣的人可以造訪 HanGee 的官方網站： http://han-gee.com/ 也歡迎加入 HanGee 的 Facebook 社團，貢獻你對國民機的想法，或是出一份力讓我們更接近目標： https://www.facebook.com/groups/HanGee/ 無論你是個人還是組織單位，無論你是否為科技圈的人，亦...