paperclip.io 是我與 zhusee 最近奪得 Facebook World Hack 大賞 的作品。T 客邦在 Facebook 公布大賞得獎名單後 (10/15) 第一時間採訪了我們。
獲得 T 客邦 授權，將 12 道採訪內容轉貼回來我的部落格。
1、為什麼會選擇開發 Paperclip.io 這樣的服務？你們發現了什麼樣的需求？這個點子是怎麼來的？
我平常在使用 Facebook 時，到不錯的連結或頁面就會順手按讚。但是，按完讚之後過後想找自己前幾天曾按過什麼連結，卻很麻煩。Facebook 一直沒有一個入口介面可以讓你找之前讚過什麼。我認為這件事造成我相當大的困擾，就覺得應該要有一個開發者來寫一個這樣的 App 幫助大家....但很明顯應該是沒有人要寫，於是我就打算自己寫。
剛好 Facebook 舉辦這次比賽，我就打算拿來當這次的題目。
2 、在 Facebook Developer World HACK 2012 裡面，因為每個站都是一天的活動，而且比賽時間只有幾個小時，在這麼短的時間內，你們做了什麼準備，讓作品可以贏得比賽？
選題
首先，我認為是「選題」吧。這是一個「夠小」而且「解決真正大眾困擾」的題目。如果我們選擇進行這個題目。可能題目賣相就會高一點。（我猜）
專注
其次，我認為是「專注」。因為這個「題目」夠小，我們可以把我們的火力集中在於完成核心的實作。主要核心就只是兩隻 API 爬蟲 和網頁爬蟲。這兩個部分很快就寫完了，我們剩下的精力都在調整介面的順暢度。
賣相
第三，調整 demo 時的賣相。因為上台前需要寫投影片和 live demo 自己的作品，demo 只有短短的 5 分鐘，我必須在這麼短的時間內讓評審和其他的參賽者，一目了然知道我們的服務在做什麼，解決了什麼問題。於是我註冊了一個假帳號負責 demo，這裡面的內容是我精選過的，可以看完之後就了解我們在做什麼(我本人 like 過的資料其實很雜亂）。 讓評審能夠一下子理解我們想要作什麼，解決了什麼問題。我想也是拉高勝率的一大原因。
炫技
第四，介面炫技。zhusee 是一個很強的前端工程師，我經常提了一堆的點子，他馬上就能用很炫的方式實作出來。我們嘗試在 demo 前能夠讓所有的介面非常的流暢（即便是等待時間）。另外也花時間做了高難度的首頁特效，吸引目光焦點（畢竟是 Hackathon….當然要炫耀一下）。
3、在整個活動過程中，讓你們印象最深刻的事情是什麼？
參賽的台灣隊伍都很強很有創意。我不知道原來大家會拿 Facebook API 惡搞出這麼多的創意。比如說 Memory Millionaire，我就覺得他們的點子相當有意思。
在宣布三大獎項之後，我們其實一度很失望…一度以為自己落選了。
直到評審宣布評審特別獎，我們發現得獎名單也沒有我們（這也落選會讓我受到很大打擊XD），我們才猜測可能是我們拿到了首獎！！
4、開發 Paperclip.io 總共用了多少時間？在這個過程中，有沒有遇到什麼樣的難關？
其實在比賽之前，我有試寫了一個很小的 prototype，練習 FB API 的存取，但是，成品很糟，存在很多問題。但是因為已經熟了 FB API，我大概覺得這個網站主體架構，在比賽的時限之內，我是有把握可以做完的。
原始設計存在不少問題，用改的拿去比賽太麻煩了。我決定到現場重寫一遍。我們從上午九點到會場，就一直馬不停蹄的在寫 code，寫到開始 demo，所以我也不清楚我們整整寫了多久。
不過中間的確有遇到幾個重大難關：
首先是網頁的爬蟲演算法優先順序問題，當初在設計時，設計的 worker 演算法不好，會造成前面使用者資料沒抓完，後面使用者資料就無法開始進行。這在使用者體驗上會非常不好，因為使用者會覺得網站壞掉了。於是我們花了幾乎整整一個小時打掉原先的 worker 重新設計。
再來是搜尋索引效率的問題，我們嘗試讓這些連結是可用關鍵字被搜尋的，但是資料是分批分批抓進來的，所以會有異步索引的問題。我一直都無法好好的解決這個問題，最後心一橫，不解決了。直接用 MySQL 全文檢索…
不然我們可能會被迫在上台前拿掉這個 feature（但我認為搜尋是一個很大的賣點）。
5、Paperclip.io 隊伍的成員有兩位，你們之間如何分工？
我（xdite）主寫整個網站的架構，設計爬蟲、梳理流程、製作投影片以及上台簡報。zhusee 實作強大的視覺特效以及繪製精美的 UI。我會先把需要加工的頁面在第一時間寫出來，交給 zhusee 操刀設計，我們用 git 控制程式碼，基本上可以做到全速各寫各的，毫不干擾。
6、在 Paperclip.io 的功能裡，有個 Recipes 的分類，讓人很好奇為什麼會特別把食譜做個分類出來？又，書本、食譜這兩個分類的內容，是怎麼去判斷的呢？
在把整個網站初稿寫出來之後，我們認為這個網站如果只有連結實在太單薄了....
於是我們決定加一些分類。分類就是按照 og:type 去分，我們發現有幾個 type 做出來的視覺效果不錯，如：Youtube、食譜、Github …於是我們就決定把這些功能加進去了。
7、在得獎之後，是不是打算升級 Paperclip.io 網站的硬體資源，讓匯入的資料可以更快跑出來？
這個網站吃的資源真的很驚人，我不確定我能不能一直養著它…
說到這個，其實在現場邀請一些朋友幫忙測試時，我們就發現一些效能上的問題了。於是，我們還在當場做了一個非常大的賭注，就是現場刷卡升級 linode 機器(伺服器)。這時候已經快要接近 demo 時間了，要是升級當場出了什麼問題，或者機器來不及當場升級完畢，我們可能就直接開天窗了… 還好這件事並沒有發生。
8、對於想要參加類似 Hack 活動的人，有什麼樣的建議？
我參加過好幾次 Hackathon，得過兩次獎。一次是 2008 年的 Yahoo Open Hack Day（那次是公司同事一起出去比賽，作品是「和多繽紛樂」，得了亞軍）。一次就是 2012 年的這次 Facebook World Hack 得到首獎。
在這好幾次的參賽經驗中，我得到幾個寶貴經驗：
(1) 好的題目很重要
評審希望得獎的題目是 valuable 的。搞笑、諷刺、主題模糊的題目，一定不會得獎。（我在 2009 的比賽跟一群大神等級的朋友合作做了一個精美的搞笑網站「我是專家」，但是…我們沒有得獎）
(2) 賣相非常重要
有些 Hackathon 比賽，甚至投影片比網站重要…。有某幾次的 Hackathon 比賽，竟然是投影片贏了網站。這讓我覺得很不公平也很無奈。但我也理解到比賽要贏就需要賣相的現實。 雖然這次 Hackathon 大會是要求需要提供 source code 以證明不是投影片的實戰比賽，舞弊不至於發生。但我還是認真的投資了快要一個小時在調整假 demo 帳號、截圖、寫投影片.....
9、接下來還會參加其他 Hack 活動的計畫嗎？
暫時沒有。因為我們忘記報名今年的 Yahoo Hack Day 比賽。但我想沒有關係，今年拿到這個獎就值得了…
10、如何把 Bootstrap 改得這麼好看？
我們用了一些網路上的免費素材，比如說
簡單抽換了一下材質，然後用了一點 CSS3 技巧，提升介面質感。這些都是我們平常開發時就相當熟練的技巧，用得很自然。
11、從零到完成作品，用了很短的時間，這是怎麼做到的？有什麼樣的密技？工作進度如何管理？是有什麼樣的開發好習慣嗎？
我想主要是幾個重點：
(1) 時間管理
我參加過很多場 Hackathon。大概知道寫 code 時最容易踢到什麼鐵板。或者開發中最容易遇到什麼鬼打牆的事情。
比賽通常只有短短的幾個小時，所以你要把最浪費時間的部分想辦法節省掉。比如說：如果當天再討論 idea，你的時間就很有可能不夠用。網站需要佈署，佈署需要測試，所以最好有只要一鍵就能 deploy 的環境。domain name 全球生效需要時間，所以 domain name 最好先買。
現場再搞這些事，網站鐵定作不完。何況最後至少要留半小時寫投影片....
(2) 知道什麼該放棄
因為時間不夠，所以其實很多功能，不夠時間讓我們寫到夠完美夠好。於是對自己在開發任何元件時，都要設定 deadline。如果一定時間內(15 min' 30 min)寫不完，就要放棄，或者是改採其他 solution。
(3) 平常要有自己的 best practices
作網站的時候，我們知道很多工夫都是重複的。比如說作網站一定要有一個網頁主框架、一個 Facebook 登入系統、一個系統管理介面，一些常見的分享功能。
這些事情都小，但是堆起來還是很花時間。如果比賽時，這部分的時間成本若是 0，我們可以把更多的時間花在寫核心功能上。像我上禮拜釋出的一個 app 產生器 Bootstrappers。
這個 Bootstrappers 其實就是我這次比賽時用的大砲，它可以讓你一鍵就產生一個網站雛形，然後馬上開始刻程式。所以當別人還在討論要作什麼時，我這部分已經作完了....
而我和夥伴已經一起工作將近三個月，彼此有不錯的默契。我們在寫 code 時，了解彼此寫 code 的習慣，於是接力對方的部分，速度就非常快。而我們更用了 git 這套程式碼版本控制系統，可以做到各寫各的，不會干擾。
12、如果 Facebook 邀請你們加入當員工，會進去嗎？
會慎重考慮。