Fred's blog

從電腦、資訊科技開始普及後，每過一段時間，企業界就會開始出現新的 IT 轉型計畫，以整頓整個資訊系統、商業運行模式，然後試圖找出下一個世代的新方向。每一個具規模的企業，都生怕與新世代的技術和商業模式脫鉤，於是砸重金、拚人力，說什麼也要追上世界的腳步。當然，中間的技術供應鏈也不斷在改變，上一世代的王者或是贏家，在下一個世代可能不一定跟得上，因此身為終端用戶的企業，每當面臨新的 IT 轉型計畫，往往也跟無頭蒼蠅般， 不知所措甚至不小心會做錯了決定。 回到十幾二十年前，你也許可以有機會一次性把一個大系統整個替換掉。但在今天資訊系統高度介入管理的時代，版本更迭無數次的平台，沒有一個系統能在一夕之間被整個換掉，哪怕你的品管和測試做得非常足夠，甚至是超標達成，也哪怕你事先的需求訪談談到祖宗十八代都瞭然於心。 這常常是系統設計者和規劃者的誤區，看見許多表面問題，於是設計了一套全新、看起來完美的解決方案。而剩下沒照顧到的部分，都覺得只要能配合測試就可以邊走邊補足。事實上，現代資訊系統的維度和複雜度，已經超出人類的想像，太多的例外、不可控、溝通執行問題，遠遠超過理論上的執行方法。 所以從系統規劃設計的角度來看，我們總是要慢慢來，一段段改善、替換，最終達成全面換血。而且越是龐大複雜且重要的系統，越要切割得越細，透過降維度的方法，來慢慢替換。所以我們在討論IT轉型，從一個肥大的系統換到另一個肥大的系統，已經不會是選項，系統架構的去耦合、高擴展性甚至是服務不中斷才是考量的重點。 這也是為什麼「微服務架構」在近年來特別熱門，微服務真正在討論的不是容器化，而是在討論的是怎麼讓一個龐大的系統，更容易受到管控、維護和擴充，除了可以更容易實現災難隔離、例外狀況、整體高可用性，也可以更有彈性做各種變化。 更重要的是，微服務架構下，其系統風險管理上，從在開發階段開始，每個部分就已經受到隔離和管控。也由於每個被拆解後的系統都非常小，遵循 SRP 原則，在開發維護上相對容易，也可以保證每個單元有更低的問題發生率。至少，你不會因為一顆螺絲或換一顆螺絲，導致整個塔倒塌。 不過微服務架構卻也不是說要做就能做，對於規劃設計者來說，他必須很了解各種新舊技術議題、有能力做實務執行面的評估，也需要耐心做各種服務拆解梳理和引入正確的 Pattern 及技術，甚至很多時候要有走一步是一步且可以快速反應...

話說，Isomorphic 一直是 Node.js 開發者的夢想，期望同一套程式碼前後端都可以使用，大幅簡化程式碼和加速開發。此外，動態網頁的 SEO 問題也可以同時獲得解決，許多效能問題也可以得到改善。但是，要實現 Isomorphic 的架構，有很多的問題得先解決，會花大量時間在前期工作上，往往讓許多開發者頭痛。 儘管頭痛，仍然阻止不了大家往 Isomorphic 的世界前進，我也因此建立了一個專案「 Lantern 」，希望能讓更多人能以 Isomorphic 架構，快速建構出自己的網站服務，省去許多前期工作的時間。該專案是一個網站服務的樣板，實作了會員系統、權限管理、第三方登入、多國語系和送信機制等功能，在使用者介面上也做了一個還算美觀的介面。基本上，開發者只要 clone 下來，然後修改設定檔或改改介面、增加點功能，就可以快速完成一個屬於自己的全新網站服務。 最特別的是，「 Lantern 」整合了現今所有最新的技術和概念，包括了 Koa、React、FLUX、ES6/7+、Webpack 以及 Semantic UI，大量運用了 Generator、class 及 decorator 等最新 JavaScript 語言特性來簡化設計。所以，如果你想要接觸最新的技術，完全可以透過修改「 Lantern 」專案來學習和熟悉。 目前「 Lantern 」支援 Facebook 剛發佈的最新 React v0.14+ 和 react-router 1.0.0+，也避免使用像 redux 這類反 FLUX 原始設計的框架，讓原本熟悉 React 和 FLUX 架構的開發者，可以快速上手。也提供一些常見的 Extension，方便開發者寫出前後端通用的程式碼，大多數情況下，開發者不需思考程式碼運行在前端還是後端。 快速安裝使用 若想要使用「Lantern」，方式很簡單，先從 Github 取得程式碼： git clone git@github.com:cfsghost/lantern.git 安裝必要之 NPM 模組： npm install 使用 webpack 編譯專案（若要正式上線，可加上 -p 選項來編譯）： webpack 運行網站服務： node app.js 最後可以使用瀏覽器開啟網址，確認是否成功： http://...

台灣的電玩機臺一直是一個很少人探討的遊戲產業，他們外銷機台到國際各大賭場，除了一直在設計讓人願意掏錢的有趣遊戲機外，也真真實實用到很多資訊科技。在多年前一次南部的經驗，有幸接觸到這樣神秘的產業，也幫他們開發過一些東西。而其中一項專案，就是一個加密檔案系統，讓他們可以保護他們的遊戲程式，避免被對手輕易偷走自家的程式。 於是就有了這個 MDS 檔案系統（Middle Stone Filesystem），採用 blowfish 演算法加密，支援 384-bit key 和同時多組 key 的存取。由於作業系統本身會很容易破解修改，要保留可以將解密工作和 key 放在額外的硬體鎖或晶片上，甚至是多組 key 可跨多個硬體晶片存放，增加破解的難度。所以因此也設計了一些單獨的讀取工具範例，讓硬體鎖的開發人員，可以參考做法，寫在其硬體韌體（Firmware）中。不過，更近一步和硬體整合的版本，礙於敏感，這次就沒有釋出了。 專案網址： https://github.com/cfsghost/mdsfs 其實，這專案多年來一直對周圍的朋友嘴炮說要開放出來，可是一直沒負諸行動（當然也是因為懶惰）。而今天看到 iCloud 被破解的新聞，受到一點資料安全問題的刺激，於是想起這個專案，所以就花點時間挖出來整理一下文件並往 Github 上丟。由於，這個基礎版本很久沒維護了，安全性如何我不能保證，但拿來做學習 FUSE 和加密演算法應用，倒是有點參考價值。如果有人想要接著開發，也非常歡迎！ 另外，有些人反應不知道能拿來幹麻。關於這件事，其實把 MDS 當做一個簡單的加密打包工具，也是可以的。 後記 看到 iCloud 被破解的新聞，不由得讓人重新思考雲端和未來物聯網時代，資料安全的重要性。稍為瞭解真象的人通常都會跟你說，千萬不要相信任何人，將東西和隱私放在雲端。而通常你第一個要害怕的是雲端系統管理人員和系統設計人員的操守，他們是不需要經過任何破解手段，即可全權存取你資料的人。再來，我們要擔心的是系統的安全性，設計者和管理者能否真有能力去保護使用這的資料？這從使用者手上的 App、作業系統、瀏覽器，一直到雲端上的一切系統，都是必需要考量的範圍。也因為這樣種種的複雜情境，使用者實在難以得到真正安全的保護。 原因其實很簡單，當檔案自你手邊的機器準...

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

很久沒更新了，自從十二月底退伍之後，一直忙著將書完稿給出版社，沒空坐下來好好在 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 這樣的設計來解決這問題。有趣的是，Se...

昨日應邀參加『 企業雲端環境建置與應用技術研討會 』，給予一場『AppHouse - 國產 PaaS』的簡報分享，聽眾相當熱情，在會後也一起相互討論了許多技術與非技術等議題。這次的分享，主要在說明 AppHouse Project 的細節，並闡述了 PaaS 在雲端產業中的定位。為了讓聽眾更能理解，也特意以小弟的淺見和觀點，用簡單明瞭的方式描述『什麼是雲端』。 後記 會後與不少人交流，發現過去很多人被『雲端』一詞搞糊塗了，不能理解。如果你也有此困擾，不妨可以看看此簡報。 若您有任何疑問，或需要協助的地方，歡迎與我聯絡。:-)

就在幾天前，MongoDB 邁入了 2.2.0 的穩定版本。我們若回頭來看，MongoDB 一直到了 2.0 前後，比起早期版本，已經有長足的進步，並且支援了相當多的功能，也對規模化和資料庫系統管理下了很多功夫。對於大多數的資料庫應用，已經非常適合。 若你對資料庫相關技術有些了解，就會知道，當資料庫的資料發展一定規模程度，或是要確保系統不當機時，我們就需要用到 Master/Slave 的方式去備份和備援，當主要(Master)伺服器出了問題，次要(Slave)伺服器便即時補上，保持系統運作。但是，既然已經有 Master/Slave 機制，是否可以有更多台備援呢？更或者進一步，將讀寫分開在不同伺服器，以分攤流量和系統負載，並加速讀寫速度。而 Replication 就是這樣的機制，可以用來動態同步多台資料庫伺服器的資料，也可以當主要伺服器因故下線時，讓其他伺服器即時替補主要機器的位置。 在 Debian 上設定 MongoDB 的 Replication 相當容易，首先在想要變成主要(Primary)的機器上，打開設定檔(/etc/mongodb.conf)，並為我們的 Replication 群組命名（在 MongoDB 中稱為 ReplSet，一些書籍內翻譯成『複製組』）： replSet = mydb 重新啟動 MongoDB： $ sudo service mongodb restart 使用指令 mongo，進入 MongoDB 命令模式： $ mongo 於 MongoDB 命令模式中執行： # 初使化 replSet rs.initiate(null) # 加入自己的 IP 位置 rs.add("192.168.11.1:27017") 若是回應成功，請先稍待數秒鐘，等伺服器偵測和初使化。然後會發現 MongoDB 的命令提示字元從『SECONDARY』變成『PRIMARY』，此時，代表這台機器已經變成 ReplSet（複製組） 中的主要機器。 同樣的，你可以開始為 ReplSet 加入其他次要的資料庫伺服器： rs.add("192.168.11.2:27017") rs.add("192.168.11.3:27017") rs.add("192....

數個月前開始做一個計劃『AppHouse』，實作如 Google App Engine(GAE) 般的 PaaS，其志在打造自己的 Node.js 雲端軟體平台。然後發現，除了讓雲端服務可以在平台上跑起來外，資料庫管理也必需有個便於使用的機制和規劃，仔細想想，一個沒有資料庫配合的雲端服務，可沒有什麼太大的價值，於是，『DBHouse』便應運而生。 你可以在 github 上找到這個專案： https://github.com/Mandice/node-dbhouse DBHouse 起初的開發目的，是讓使用 AppHouse 架設以及開發自己雲端服務的人，可以很容易存取資料庫。此外，對我們而言更便於管理資料庫資源，面對許多不同的服務，不需要特別為他們開設資料庫權限，亦或是買許多硬體和主機，建立起許多 VM 並做各種安全性規劃。其實，如果把 DBHouse 的用途，想像成 Google 在做的事，就很容易明白：『在 GAE 上你可以使用統一的 Database APIs，存取 Google 提供的資料庫系統(BigTable)。』，同理，我們也是在做同樣的事。 只不過，學 Google 開發自己的一套資料庫太過於困難，不是一個可以達成的目標，所以我們仍然選用 MongoDB 當做 PaaS 的資料庫底層。僅管資料庫不是自己開發的，我們還是可以提供統一的 API，讓開發者存取。統一的 API 有個好處，若能做到當開發者在使用的時候，不需要知道自己在使用什麼資料庫，日後就可以在這 API 之後串接或替換不同的資料庫系統，有很大的彈性可以擴充。 當然，更遠大的目標是希望在一個 Table(Collection) 內，因應不同的欄位需求，而交由不同資料庫處理，更進一步發揮不同資料庫的特色。但是，這夢想遠大，技術上也有很多盲點待討論，所以能不能實現那是另外一回事，至少，短期內在我們的能力範圍和經濟狀況下，暫時無法達成這一步。 雖然 DBHouse 有這樣的初衷和夢一般的計劃，但不代表 DBHouse 一定得和 AppHouse 配合使用，更準確的說，他們本來就是獨立各自發展的專案，各自可獨立運作。說穿了，DBHouse 本身就只是一個 Database API，你可以在 Node.js 裡使用 DBHouse API 去操作自己的 MongoDB（目前只有支...

很抱歉，因為台北大雨來襲，導致班機延誤，讓小弟無法及時從香港趕回台灣參加 FreedomHEC 2012。相當對不起主辦單位，就這樣讓當天議程開了天窗。但是，之後我有空時，仍會整理資料，依舊會公開原先預定要給予的簡報。 不幸的是，活動第二天被客戶抓住，所以也沒辦法到場聽講。不過，雖然沒參加到 FreedomHEC 2012，為了賠罪，第三天當了司機（Be a driver, not writing driver :-S），開著車載著外國講者們一路到了宜蘭大學，給予學生機會直接面對面與 Kernel 開發者交流。 除了面對面問答解惑，其中當然也有保留一點時間，讓講者們可以自我介紹，也分享一些經驗。我也給予了一份簡短的心得分享，由於對象是學生，時間也有限，所以就不直接討論艱澀的技術，而是以輕鬆的角度切入，分享一下創業的經驗和業界的感想，還有描述就算在面對不利軟體業的環境之下，身為一個軟體人所需要的熱情和自我要求。 衷心期盼我們能培養軟體開發的熱忱，然後才有機會做出軟體的價值。:-)

還記得，尚未投入 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 通訊協定的知識，或後前後端資料處理的經驗，依然可以開發出網站程式。 ...

感謝各位捧場，上周六在『 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 不受限於任何開發領域。

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