我實在認為自認有熱情的開發者，一生中都應該至少來體驗一次這種 “燃燒生命、爆肝寫 Code” 的活動！所以之前總是錯過這類活動的我，這次看到比賽消息，立刻在 FB 上揪團參加。
由於這次競賽的要求跟過去以往不同，特別強調 UI / UX 設計，並且要求團隊中一定要有至少一個 Designer 參加，所以造成這次比賽隊伍中，女性比例大幅提高，每隊通常會有一個女性參加（本隊也是），甚至有團隊是完全女性組成的四人隊伍。如果去網路上尋找過去幾屆的比賽作品，相比之下也會發現這屆 DEMO 的作品視覺上質感有大幅提升的效果。
來看看此次比賽的決勝條件：
每隊須在指定的 24 小時內，運用 Open API（鼓勵使用 Yahoo API），開發出可執行的程式，應用範圍不限。
評分標準：
- 創意：30%
- 技術：25%
- UI 設計：25%
- 執行度：25%
比賽前一周參加完比賽行前說明會，團隊相聚一起討論我們的開發主題，這個階段大概就耗掉三天的時間，把腦力激盪的各種莫名其妙的想法重組混合，整理出兩個主要提案，最後在團隊意見分歧、難分難捨中，經由投票表决，定下了此次開發的目標，一個在地化、智慧型、多媒體社群交流分享的手機 APP - 『Bubble』。
關於團隊 GATE（DOWAY）
由於我是先組成團隊，再決定要開發的應用，所以一開始團隊的組成其實包括了可能需要的各類人才：
- Gale：我們的 UI / UX 設計師，除了卓越的美感與藝術天分，同時也擅長 WEB 端技術開發，包含 HTML / CSS / JQuery / Bootstrap … 等 Web UI 框架。
- Alan：我們的 Open Source 與 Open API 專家，對資料庫、統計、與 Big Data 應用頗有研究，是幫我們發想如何應用開放資料和開發串聯的重要智囊。
- Eric：精通各類 Adobe 開發技術，由於透過 Adobe AIR 可以快速開發，非常輕易地跨平台同時發佈 iOS / Android 的行動應用版本，我找來替可能進行的行動應用鋪路。
- Tom：精通手機拍照和錄影剪輯記錄，負責記錄團隊的一舉一動並寫 blog…。哈，其實是負責所有伺服器端的程式開發與環境部署。
團隊名稱的是比賽事後穿鑿而成，理由應該很明顯吧，哈！
基本上，這個團隊的技能分布涵蓋範圍非常完整，團員也都是一時之選，幾乎各種未知可能的應用都能進行開發！但是，先組成團隊最大的缺點，是當開發主題定案時，工作量就瞬間傾倒在某人身上，其他人只能雙手一攤，無法協助分攤...。
真的要在一天 24 hr 的時間內將一個應用 “從無到有” 做出來，絕不是件容易的事情。根據過去參賽者的經驗，事前的準備工作一定要做足！開發的過程中最難掌控也最殺時間的活動是什麼？當然是 DEBUG！為了不要再開發當天才開始查問題，賽前一天，團隊跟公司告假，開始測試各種技術的可行性，把需要的外部資源該買、該申請的都搞定。
前一天（週五）晚上，線上刷卡到國外租買必要的伺服器時遇到開通的障礙，對方透過英語線上客服回覆我們：要等到“下週一”工程師上班時段才能幫我們解決。
隔天六日就要進行比賽的我們當場嚇得屁滾尿流！苦無對策之下，三更半夜，Eric 只好在家忍痛把已經循環利息繳不完的信用卡，在付費頁面連續刷卡刷到機器連線開通為止，不成功便成仁的場面極其壯烈，若非親眼所見，難以想像。
刷信用卡刷到清晨三點才上床睡覺的他，隔天早上九點就跟我在會場集合，開始佈置我們的開發基地，面對接下來不眠不休的 36 小時。但是這時候有沙發的好位置都早已被占光了，我們被迫坐在靠近網路 switcher 設備旁邊的桌椅。
比我們更晚來的人，只能做吧台旁沒有靠背的高腳椅，我還看到有人因為坐到屁股痛，像是跪算盤一樣跪在高腳椅上寫 code，真是悲情。
這次教訓告訴我下次搶位置一定要再提早半小時以上進會場。
比賽現場提供豪華的吃喝玩樂，我就簡單貼些照片簡單介紹。一天供應四餐（三餐＋半夜泡麵宵夜），玩到手酸不用錢的投籃機、手足球、撞球桌⋯⋯。前幾年還有 Wii 這些電動可以打，今年沒看到。
決定走 App 開發，所有的重擔都落在 Eric 身上。從剛開始和我串伺服器的資料，到拿到 Desginer 的圖開始套 UI，沒有休息的時刻，天性溫馴的他也脾氣暴躁了起來。
由於 DEMO 要看 UI 的東西都必須真的有實際互動的視覺效果，沒辦法作假，不像我們後端可以為了定點展示（我們的應用跟地圖地位有關）先寫死假資料串流程，所以幾度他測試測到怎麼資料都不會變，才領悟到我這邊是寫死的假資料，對我比出數次中指叫我吃大便～～。
可憐的他去了廁所還竟然在馬桶上睡著，搞失蹤。
由於後端開發這次 Loading 相對輕鬆，沒有時間壓力，為了多學點新東西，所以這次我經由 Alan 從旁指導，臨時決定捨棄熟悉且最有把握的 MS SQL Server，而改採用 NoSQL 的 MongoDB 來增加開發上的一些困難度和額外的工作量。這種 NoSQL 的使用經驗之前我也用過類似的 Memcached 和 GAE 的 Datastore，所以並沒有很陌生，但是感受到 MongoDB 在資料的運用上有較為靈活強化的功能，且部署使用極為輕便，是這次的一大收獲。
第二天早上發現已經瀕臨崩潰的 Eric 開發進度不如預期，由於上台 DEMO 只有短短兩分鐘的時間，所以我和 Alan 開始根據兩分鐘內要 DEMO 的方式和劇本橋段進行討論，然後決定把所有 DEMO 沒機會展示的“非重點”功能全部砍掉！整個 APP 的開發方向徹底變成為了 DEMO 量身定做的道具而開發，而不是當做一個真正可用的產品！
由於要在 DEMO 時呈現社群使用這個 APP 的假象，我立即開發亂數隨機撒出以假亂真偽資料的程式，並且開始排演串通每個隨機資料撒出的時機點。
然而真正 DEMO 的時候，仍然遇到一些突發狀況，讓我無法及時在兩分鐘內強調完我們這個 APP 的強項而下台一鞠躬。不過從最後得獎得隊伍來看出評審的取向，我們本來就不可能獲得青睞，所以 DEMO 的失誤倒也不算關鍵。
這次得獎的隊伍作品，許多會在我們當初腦力激盪會議中被歸類不實用而被屏除的點子，但這就是評審的取向。
道理很簡單，因為這個比賽是 Yahoo 為了招募人才而舉辦的活動，他們要的並不是一個市場上可行性高的“產品”，而是要找能在最短時間內，套用最炫技術做出成品的高效率“開發人員”。
事後檢討時，老婆說的一句話總結得很好：
大家都知道，F1 賽車平常根本沒什麼用途，家用四門房車的實用性遠高於只能一個人乘坐的賽車。但是如果是造車子比賽，兩天時間做出一輛家用四門房車，和兩天做出一台 F1 等級的賽車，誰會贏？當然是做出賽車的那組啊！
沒錯，我要對自己這個團隊說聲抱歉，是我在腦力激盪會議時主張砍掉那些華而不實的賽車點子，而強留下實用度較高的四門房車點子。這是我賽後心得，自己該學習面對的教訓與經驗。
雖然我們採用 Adobe 的 AIR，但結局我們沒有拿到 Mac 的 AIR，但是卻呼吸到 Hacker 的 AIR！
與一群能力高強、各有專長的朋友在高度專注與高效率配合下，在極短的時間內從無到有完成一個可用的軟體，這種過程真是非常愉快，是我在工作職場上許久都不曾有的爽快感受！我們這個團隊，有信心迎接未來的各類 HackDay 比賽！
沒有留言:
張貼留言