hypo 的開發團隊一向神龍見首不見尾的很少出來說話，不過開發團隊在幕後辛苦的寫出各式各樣的程式，讓網站的前後端交織出一套美妙的編輯器。這些努力其實想要達成的目標很簡單，就是希望能讓使用者容易上手、享受編輯的樂趣。而在這些技術的背後有著許多不為人知的小故事，這次因為推友 @Randylien 的一句話，讓 hypo 的開發團隊決定寫下這些小故事。

▲ 推友 @Randylien 與 @hypo 之間的對話

接下來，將帶你一起瞭解 hypo 有史以來最大的線上編輯產品 WIDE 背後的抉擇與故事。

前身 – hypoBooky

事實上，我們對於這樣大型尺寸書本的線上編輯產品計畫從來沒聽過。因為 hypo 團隊在推出 WIDE 之前，每天總是要收個幾封希望能在 Windows 編輯 iPhoto 產品的建議函。因此 hypo 早在 2008 年就已經在開發相關的產品了。或許有些人還記得 hypoBooky 吧，這是我們的第一次嘗試。 hypoBooky 是使用 Flash 及 PHP 製作的編輯器，曾經在 08 年暑假左右推出過短暫的試用。不過最後卻因為幾個問題確認無法正式上線量產，十分可惜。

▲ 當年 hypoBooky 的編輯畫面

使用 Flash 作為編輯器自然有些先天的優勢，像是處理圖形簡單方便、能夠輕鬆的做出各式各樣的動畫效果等等。這些地方，我們承認當初如果使用 Javascript 來做，不是很難就是根本無法作到。而且 2008 年的瀏覽器也不如今日瀏覽器上所搭載的 Javascript 處理引擎一般快速、高效，更別提說 HTML5 支援了。(Google Chrome 是在當年的九月才正式推出，而又過了好一陣子這些相關技術以及瀏覽器的市場分佈狀況才真正到位。）但是當年採用 Flash 作為編輯器，我們也遇到了許多困難：

• 網站端與 Flash 端資料交換的麻煩
• Flash 生產訂單的緩慢
• Flash 輸出圖片及整合高品質文字的困難
• 開發流程無法緊密整合

這些問題有些確實是可以透過改變、熟悉或是技術上實做的方式解決。不過當初以生產圖片來說，Flash 所寫得產生器必須跳出視窗來進行生產，加上 hypo 有自己的高品質文字輸出方式。確實給我們帶來不少困擾，這代表我們得浪費一台電腦專司於生產訂單 PDF 而無法加以利用。而文字的部份原本擬採用 Flash 內部機制出圖，但是 Flash 的問題在於只能輸出點陣檔案。這樣的檔案送進印刷廠製作出來的成品在文字邊可以很清楚的看到模糊的邊緣，即便是把品質調高到 300dpi 依然有這個問題存在。

最後我們採用了 hypo 原先的文字輸出方式，將原圖文字部份預留空白，讀進來後再將文字疊到同一位置上。但使用的 Rendering Engine 不同，輸出的文字樣式不盡相同。非常容易造成訂單上的爭議。hypo 最後只好放棄了這項「公開測試」的產品，如果您就是當初少數的幸運使用者，有機會製作 hypoBooky 的話。請務必替 hypo 開發團隊好好珍藏，那不但是限量典藏的 hypo 產品還是一段重要歷史紀錄呢！

▲ 限量經典的 hypoBooky 書本

WIDE

▲ hypo 主力產品 – WIDE

WIDE 就是一場長期奮戰了。WIDE 是從 09 年中所開始的計畫，而 hypo 開發團隊的野心也很大。我們希望透過這次的新產品，一舉將 hypoBooky 的缺點一次解決，重新打造屬於 hypo 的編輯器。這項計畫的內部名稱叫做 HUE, Hypo Universal Editor。你看，我們的野心真的是很大吧。 😛

WIDE 為什麼可以說是一場長期奮戰？因為 WIDE 可以說是對 hypo 系統架構的分解及再構築。WIDE 是 hypo 頭一遭在線上編輯推出如此大規模的產品，這個大規模包含了書本的大小及頁數。這樣的產品由於系統必須即時提供使用者精準預覽，對系統造成的負荷會比原來大上很多。為了因應這樣的增長，開發團隊花了非常多心力重新調整了 hypo 的系統架構，由當初的單機伺服器架構重新調整為由 Front-end 及 worker 處理的分散式架構。這樣的架構由於將生圖的負擔移動到了其他機器並且保證了同時間最大的處理數量，其實對於 hypo 整體網站的穩定性及尖峰反應速度來說提供了很大的改善。不過這些系統層面的東西我們暫且表過不提，或許等下一次有推友問起的時候，hypo 開發團隊又會開始分享故事了吧。（請大家愛護 hypo 的開發團隊，不要看完這句馬上就跑來問唷～）

回到正題。WIDE 事實上在一開始開發之初，我們並沒有對 Flash 完全失望。我們稍微嘗試打造了一個簡單的版本，不過還是因為一些因素無法完全達到我們的理想。加上 hypo 團隊的內部人員幾乎都是熟悉 Objective-C, Ruby 為主，考慮到維護的方便性，最後決定採用 Javascript 的解決方案。當然一方面 hypo 團隊一向是對新技術大膽採用、小心部屬的，這點從我們最早的 hypoDot 12平方即是以 Ruby on Rails 撰寫即可見一斑。接下來要講得就是推友最想知道的問題了。

什麼原因讓 hypo 選用了 Cappuccino ？

這問題我想答案非常簡單：hypo 的每位員工都是咖啡因重度成癮者，有咖啡放著不喝怎麼可能呢！（被打）

當然答案不是這麼簡單的，在當初研究有哪些適合工具時，那時候能見到的資訊大至可以分為以下兩種：Web App 以及 Web Site。事實上，光決定使用那一種就讓 hypo 團隊苦惱半天。網站的形式是 hypo 一直以來在 hypoDot 系列產品所採用的，因為主打容易、簡單等等特點，作為一個網站的形式其實比較簡單。透過網頁 / CSS / JS 來設計，是很基礎的選擇。但是我們認為，雖然我們覺得 WIDE 編輯器必須維護這個傳統，但是隨著頁數、版面的拉大，用戶需要的編輯時間也越久。如果我們不能創造出一個讓用戶可以舒適編輯的環境，那就是我們的不對了。

有了這樣的覺悟之後，就直接朝向 Web App 去做了。而在那個當下，Cappuccino 的文件比 Sproutcore 好很多，沒記錯的話 Sproutcore 當時正在面臨一次很大的改版，導致文件跟最新版的程式碼完全對不上。在嘗試過了幾次之後，便決定放棄。而事後看來，Cappuccino 對於 hypo 來說確實很大程度了讓 hypo 員工的 Objective-C 技能再度利用。很多的 design pattern，甚至是一些比較簡單的程式碼都能夠直接拿進來利用。

Cappuccino 很有趣的地方在於，他的網頁架構十分簡單。當網頁載入時，將會載入 Cappuccino 的基礎元件。像是 Objective-J 的分析器，並且透過分析器載入各式各樣的 Frameworks，包括了系統提供的 Foundation, AppKit 以及到上層開發者所實做的 Framework 及應用程式程式碼。接著就依循 Objective-C & Cocoa 的慣例，透過 Main.j 的 entry point 載入 Principal Class，通知 Delegate 進入 App 流程，完全的將 Cocoa 的機制搬到了網頁上來。除此之外他也很完整的實做了 Cocoa 的功能。因此在如此複雜的桌面等級應用程式之中，我們可以透過 CPNotificationCenter 進行不同元件間的交互操作。透過使用通知的方式進行，可以將元件之間的耦合度儘量的降低，使得元件可以被重複再利用。

▲ 通知中心的使用實例—圖片縮放控制器

就以編輯器中的圖片縮放控制器來說明吧。這個元件是由所控制圖片編輯元件直接請求整個程式的 Application Controller 將控制器 overlay 在書本其上，讓使用者控制大小。但是因為超出了書本編輯控制器的控制範圍，所以當使用者點選了「書本設定」等會下拉蓋住整個畫面的功能時。書本編輯控制器無法控制讓其消失。因此我們便設計成讓發生全畫面遮蓋、切換書頁等時候，發出 WideAllOverlayShouldHideNotification 通知，需要的元件可以自行收取此通知，做對應的畫面準備。

這樣的設計模式讓我們省下了很多模組之間互相溝通、掛勾的成本，而能夠以更有擴展性的方式進行程式設計。 還有很多的例子像是偵測滑鼠移進移出編輯範圍時，由於超出書本編輯區的偵測能力，也是由系統所偵測而發出通知，以及維護資料一致性而互相發出的通知等等。

▲ WIDE 的 Google Maps 整合功能

除了跟 OSX 開發環境很像的優點之外， Cappuccino 由於是以 Javascript 為基礎，加上 Objective-J 分析器做的相當的好，可以容許 Javascript 穿插其中。因此讓我們可以快速的整合許多現有的 Javascript 函式庫進來，像是 WIDE 提供了 Google Maps 整合的服務便是透過這樣的機制實做。以 Google 官方的 Javascript API 為基礎，上頭包上了卡布其諾的糖衣，讓其他程式就能與其溝通。這對 hypo 的地圖編輯功能能夠快速的整合標點甚至路徑規劃等等進來可說是工不可沒。

當然隨著 cappuccino 開發，一路上我們也是踩雷不斷，通常是透過 Chrome / Safari 的 Developer Tools 去 trace 找出問題點。從 Chrome 剛出時，開發工具一直當用到現在很穩定，我們開發團隊也可以說是看著瀏覽器長大的呀！

WIDE 推出之後團隊一直努力的在效能上進行調校，透過這些工具的幫忙，加上 Cappuccino 是 open-source 專案，我們可以深入到系統原始碼去找問題，事實上還滿方便的。這些過程雖然很辛苦，不過我想整體上在開發上帶來的好處是遠遠多過於這些壞處的！而現在 cappuccino 也算是到達一個穩定的階段了，我想現在如果想用用看 cappuccino 或許是個不錯的時間點。

好了，夜深了。hypo 的開發團隊也該休息了，故事到這邊先告一段落。希望透過這次的分享，讓各位讀者能一起體驗那段 hypo 有趣的共同回憶。也能讓大家知道為什麼 hypo 在技術上做了這樣一個大膽而有趣的選擇。如果各位讀者不論是希望我們能改進說故事的方式或只是想聽聽不一樣的內容，都能夠在 blog 留言與我們互動。那麼，我們下次見囉… 🙂