Fred's blog

數個月前開始做一個計劃『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（目前只有支...

雲端這個詞已經吵得鬧哄哄，也有更多人為了這個『形容詞』下了太多的定義，到底什麼是雲端已經變得不重要，也無法三言兩語說的清楚。身為一個資訊產業的創業小老弟，其實並不期待雲端能帶給資訊業如何的革命和新生態，只視為這是一次新契機，讓政府和台灣科技業的老大們，能靜下心傾聽。 我們暫且不需要討論雲端的格局觀，因為這類的畫餅，大從國家政策，小到百姓家常，已經太多了。我們有預算，有政策，有土地，有銀行，有股票，什麼都不缺，只缺少夠多的實際作為而已。其實，回顧過去，可以看到許多事我們現在可以做，但是大多數人，多半用美國矽谷的角度探討當今的資訊產業，我認為，那無法幫助台灣人省視情勢，因為有太多經驗不是在台灣的業界可以仿效或改進的。所以，既然人在台灣，當以台灣出發的角度，省視這些年來的發展過程，因此，筆者將以自己在台灣的經驗，嘗試省視這個產業，雖可能不算準確，卻是一種不同角度的嘗試。 的確，筆者剛滿 26 歲，年紀不足，在商業上，經驗也不算多。但在上一個世紀末，卻曾趕上過十幾年前 .COM 的最後一班列車。至今，看著當年遺留下來的無價紀念品，那些重量級的網域名稱，是花再多錢都無法獲得的一種經驗，令筆者有著無限的感慨和體會。說實在，如果沒這樣做過，永遠不會理解，不受金錢誘惑，堅持自己認為正確的事，然後去惡搞並使用那些當年叫價上億美元的網域名稱，是多麼痛快的事。 很多人會說我是忌妒，眼紅看著在十多年前還是小學生時，曾經發想和完成過的東西，諸如網路相簿、Blog、購物車、集體購物等，還有更多當時翹課躲書店而寫出來的服務，在今天一一出現或成功於網路上。事實上，比起心中的不平衡，我開心自己從中學到更多當時沒有看清楚的事，讓今天的視野可以更開闊。 還記得當時，所有人對網際網路(Internet)都有一種特別的期待，就像今天的雲端(Cloud)魔力一樣。全世界的人也都像現在一樣，砸進了無數的人力物力，在商業界，更是起了許多不得了的名目，打算大賺一筆。然而，絕大部份獲得勝利的人是誰？不是那些有錢有勢的企業和組織，而是真正做事和成本相對低的車庫公司。在某方面來說，這些大企業意外吃了不少悶棍。 從國內的發展來看，雖然在網路發達的今天，網路速度已經不再是大問題，架設網站的成本也不是太高。你可能很難想像當年，要是你有著一條 64K 專線，都可以成為台灣 ISP 公司的情況。也因為如...