smalltalk

有鄉民說想看當年八八風災的技術筆記，特此撈出來回憶。這是我 2009 所作，當年 25歲。

=====

有效利用第三方外掛與資源

支援網一上線，是以 Gmaps + 刊登版（可留言）的姿態誕生，後來才漸漸演變成現在的回報互助論壇形式。其實眼尖的程式設計師朋友應該有注意到，整個網站在後期的架構改版上，其實我並沒有「自己多寫」很多功能。

我不是不會寫，我是不願自己花時間下去寫。

這個網站是由我一人 handle（雖然 CNN 記者在聯絡我時，不太相信這網站的背後是一個人而不是一個團隊）。我本人的時間與精力，對這個網站來說是重要資產，不能隨便遭到浪費。

在 COSCUP 的 Q & A 時間時，也有場上的觀眾提問：

他提到現在救災網有好幾個，訊息也很多，有沒有考慮製作 API，與其他網站「整合一下」。

我在當時的回答，大意記得應該是這樣的：( 也許有出入，就當我寫文章時將論點補充的更完整一點）

=== 分隔線 ===

我不會現在做，也許過幾天會作( 整合 / API )，但絕對不是現在( 災情發生的頭幾天）。
第一個，何謂 API？給 API （就算是 RSS），資料的類型或交換格式總得也要討論一下吧。
第二個，給 API 的意義在哪裡？要做到多個網站訊息完全不重複，幾乎是不可能做到的事情。而且「整合資訊」這對整個行動真的有巨型利益的提昇到值得我投注下去時間開發（雖然以 Rails 製作 RSS 輸出不難）嗎？

也有人問我，為什麼我不作個 bot 去撈 twitter / plurk 利用關鍵字把災情資訊倒回來？但這在整個架構想法來說，卻是完全不必要的行為。我的看法是，在這段黃金期間要做的事，是要以同樣的資源能夠做出更多的事。資訊的整合傳播固然很重要，但更重要的卻是回報機制的確立。這樣才能真正有效的減少救災資源被重複浪費的程度。

資訊牆可以刷得很爽沒有錯，但是刷的那麼快，我真的不知道有多少人會去看，能從中幫上多少忙。還有多少重複的訊息在上面是 n 次傳播浪費救災資源。這也是我不製作整合微網誌、新聞進來整個系統的程式的原因。

目前幫忙的鄉民真的非常多。所以我的想法很簡單，我的系統就是寧願以大量的鄉民加上有效分類/回報機制/站內搜尋，去換取降低資源被重複浪費、和加速互助通報的效率。

第三，網站後期拿掉 gmap support，也是基於這個原因。gmap 上一開始的資訊剛開始也許有參考價值，但隨著量爆增到幾千筆之後，也漸漸失去意義。而支援網剛開始只有縣市分類 + gmap 。後來拿掉了 gmap，但多了訊息分類( 這部份，非常感謝 PTT 的志工大力幫忙，七百筆我大概分到吐血），也突出了回報功能，也是基於情勢演變以及上述考量。

=== 分隔線 ===

而我覺得值得讓大家參考的大概是這個想法：「短時間之內要做的事實在太多了，所以在初期真的不要妄想去整合以及做大功能。找出你真的能(短時間）做到，而且一做出來就可以做出巨量貢獻的功能才是最重要的。能不自己做的功能就不要自己手刻。需要人家幫忙 support 的話，就做出一個簡易協調的機制方便使用（如給志工用的管理後台，iframe 內嵌資訊）」

在支援網上「能不自己做的功能就不要自己手刻」這種例子非常多，我整理幾個部份給大家參考。

[ 使用 Registrano 當作志工管理/招募系統 ]

這個想法，是因為 PTT Emergency 志工 willyt 所生，他希望我幫忙做一個志工管理系統。我是做的出來，但要花兩天時間，不符合成本效益。但後來稍微思考了一下，志工管理報名系統到底需要些什麼呢？

1. 登記報名（有額滿限制）
2. 志工與派工者的需求資訊
3. 能寄信
4. 能發簡訊

Registrano 統統符合需求，而且提供了報名表單外嵌以及 widget 功能。於是使用 Registrano 為主體就拍板定案，同時怕有阿宅不會用這個系統，也商請了熱血阿宅朱學恆幫忙寫了教學。

[ 使用 Google Doc + Iframe 整合第三方資訊 ]

說實在，這段期間，請我幫忙加功能或寫程式統整資訊的人真的很多。但老實說，不是覺得這功能沒必要，就是花時間寫處理對方封閉格式的程式實在太花時間。

而這一個方法也是從 PTT Emergency 網頁版 Inspire 來的，PTT Emergency 網頁版 是由 Google Sites 建製，但剛上的頭一天，就因為瀏覽次數過高被暫停使用。隔天復站後，鄉民想到聰明的替代辦法，就是內容以 Google Doc 製作，publish 成 html 版，再以 iframe 內嵌在 Google Sites。 Google Doc 的 html 不但沒有 access limit，同時它也方便使用，又可多人編輯。完全可取代掉自建 CMS 以及帳號控管的麻煩。

因此如果有類似需求，幾乎往後都以此法請對方比照辦理。

[ 使用 Google Custom Search ]

網站上的資訊那麼多，為了降低重複回報的頻率，提供一個搜尋功能是很重要的。以我的技術，製作一個用 Sphinx 為 based 的簡易站內 Search Engine 並不是難事。但問題在於，Heroku 上面沒有辦法跑...冏。最後 Google 的葉平教授，建議我使用 Google Custom Search 輕鬆解決了這個問題。

[ 使用 Google Friend Connect 小工具 ]

這一個網站，雖然本身幾乎是個留言板。所以再做一個留言給站長的留言板，也不是什麼難事，但是真的沒有什麼必要。於是最後使用了 Google Friend Connect 小工具 提供的留言板，只要簡單填一下資訊，copy css / javascript 回來就收工了。

另外補充的一點，連這個系統的 theme （ Web App Theme ) 和 helper （Handicraft Helper）都是 Opensource 的資源。