2013年1月8日 星期二

心得:檢索 PTT 的資料


我所撰寫的一個小玩具 =口=

前言


近期因為新專案的關係,需要嘗試去分析 PTT 特定看板的資訊
於是我陸陸續續撰寫了一些小程式:例如「推文分析器」、「發 P 幣機」、「PTT 尋寶機」
本文將針對「PTT 尋寶機」的開發,分享自己的心得! 以下先簡要的列出一些我對 PTT 的觀察:
  • PTT 的看板與文章,其實都有對應的 Web 網頁 (兩者之間有時間上的誤差)
  • 每篇文章的 Web 網頁中 <pre> … </pre> 之間的內容就是文章原文
  • 每篇文章的 Web Url 都不重複
  • PTT 的 Web 介面,可接受 1~2 秒間隔的 query 頻率(我沒有 try 到底線)
  • PTT 的看板有文章數限制,對應到 Web 網頁的話,大約有 900 頁左右(頁數或變動)
  • 透過 PTT 的 Web 介面連到已刪除的文章時,伺服器會回噴 404
  • PTT 上的控碼跑到 Web 網頁會呈現亂碼,壞掉!
  • 因為有「修文」的情況,所以文章的內文格式會「非、常、不、固、定」

心得


而在製作 「PTT 尋寶機」的實務上,我的心得為:
  • 我採取透過 Web 介面檢索文章,並沒有使用 telnetlib 透過 telnet 進行檢索(懶惰!)
  • 我並沒有使用 Scrapy 來協助抓取文章,而選擇自幹
    • 時間有點趕,沒空玩新玩具了 Orz
    • 加上我之前其實有寫過一些 Checkers 去鎖定交易文 … (爆!)
  • 推薦使用老字號的 httplib2 … 雖然我覺得他也有些小問題 Orz
    • 如果是抓取一般「正常的英文」網頁,其實我推薦使用 pyquery,支援直接填入 Url 當參數,然後就可以使用類似 jquery 的語法直接取得內容,方便度最高
    • 如果是抓取一般「正常的各國」網頁,其實 requests 寫起來很順手,讀取抓到的值時還會根據 header 自動做 decode 的動作
    • 我會建議使用 httplib2 是因為 PTT 的 Web 網頁編碼為 Big-5 ,且可能包含一些壞掉的控碼字元。因此,無論在做 decode 或 encode 時,都必須要手動加上 "ignore" 的選項,不然一遇到那些壞掉的字元就會噴出 exception … 。而 pyquery, requests 在使用上較為不方便(恩 … 後者也是支援讀取 socket 的 raw data 啦 … ),所以我就繼續使用 httplib2 了。( 我猜測 Scrapy 應該會對這種包含壞掉的字元的資料來源有處理的函式?)
  • 對於 parse data 而言:
    • pyquery 很方便,一句話就可以從網頁中抓出文章內容:
      • article = d("div#mainContent div pre").text() #possible be None
    • 對於之後文章的 parsing 我採用「硬幹」 + 「regular expressions」,其實如果後者強的話,就一切都沒問題了 …
  • 對於資料庫文章與 PTT Web 介面文章的同步而言,我採用懶人政策:
    • 每天看看最近 100 篇文章有沒有變動
    • 當有人要下載指定文章時,我才會將該文章同步到最新狀態

補充


資料庫我使用 mongodb,因為我常常亂改欄位(攤手),反正就一個極簡單 collection 而已
我並沒有使用專業檢索用的套件去分析文章,抓出關鍵字等等
我僅只是將資料庫內的文章做一些社交上的簡單統計
然後開了 nginx + gevent + bottle 的簡單組合提供 Web 介面
就完成小玩具了!(其實迴響還不錯 XD)

有趣(發人省思?)的社交分析

過程中,技術困難點大概還是在抓資料這一件事情
雖然我前端也卡了不少時間 … ( 囧rz 我不會寫前端啊啊啊
我是用 google 寫的啊
效能的話,我則是完全沒有優化 XDDDD
玩具的目的很簡單,就只是協助板友備份文章、以及提供查詢自己的資料
以使用率來看,不會有讓伺服器有什麼負擔的可能性
兩天的使用情況是不重複訪客 800 人瀏覽(畢竟是耳機、音響還算小眾市場)
總之,寫個小玩具,能讓我多摸到一些 python 的 module 及被強迫摸前端的東西
然後又能創造出一些價值給板友、鄉民
也算是皆大歡喜了!

新版的個資法實在非常嚴厲
各位如果有撰寫相關程式請務必小心 Orz
雖然我自認此服務,不營利、不為蒐集特定對象而寫且純粹出於善意
但是我還是願意提供反檢索功能 (目前是沒有人跟我說他不要被檢索啦 … )
歡迎有興趣的大大與我一起交流相關技術 ~~

-----------------------------------------------------------------
2014.05.28 本文補充說明:

由於 ptt 的 web 版在 2013 年有多次的改版
所以本文內容已經不適用現在的情況
只能當做是一個記錄

目前 ptt 的 web 版已經是輸出 utf8 編碼的內容
且作者、標題、推文等等資訊都已經被存放在特定的 xpath 路徑之內
所以可以用  pyquery 等套件,用類似 jquery 的方式輕鬆取得內容

又,上述說明了這麼多
其實強者我學長 c3h3 已寫好 crawler 且 open source
需要的朋友請取用!

https://github.com/c3h3/PlaYnlp-Corpus/tree/master/crawlers/ptt_crawler


活動:Taipei.py 2012 12 月聚會


這是我第二次到 果子咖啡 參加活動
或許是因為 … 天氣冷?今天反常地,場地大約只有八九分滿
沒有像十月份那樣誇張地爆滿

本月的講者為在趨勢科技擔任 Architect 的 Walter Liu 大大
演講的內容為 Celery 的簡介與應用
我對這個題目還蠻有興趣的,演講的內容對我非常有幫助
聽過演講後,我打算將手邊的 Project 在下一階段嘗試使用 Celery 看看

投影片在此:




本週在只有一位講者的情況下,演講時間排太短了有點小可惜
應該要請 Walter Liu 大大多講一點的 XDDD(以上純屬玩笑,講者很辛苦的)

由於我已經報名參與 pyconf2013 的籌備
因此會後就與 CCC 聊了一下註冊組的情況
(後來我也加入註冊組了 … 算是被洗腦成功?)

這次的聚會收穫:我又認識了兩位朋友(真是不錯啊~某替代役教官+長得很像我大學某學長的 openstack 大大)


吐槽自己一下:
話說,這篇超低質量的文章在幹嘛啊?
要不是有 Walter Liu 大大的投影片
本文就像多餘的註解一樣沒用 XD

2012年12月5日 星期三

心得:Taipei.py 2012 11 月聚會

這是我第一次到 創立方 參加活動
交通指南講得很清楚:「從東門站3號出口左轉直走到金華街,只要3分鐘即可到達政大公企中心」
結果我還是迷路了 …
真的!不要懷疑,3 號出口一走出來就直接左轉,往小巷子那邊一直走過去吧!
不要傻傻的先右轉走到大馬路再左轉 …

對於這次聚會地點的印象就是:
  • 雙投影幕耶!椅子弧形排列圍繞講者,效果似乎還不錯!
  • 可能天氣太冷、地點較遠 、沒有正妹店員、然後很多人跟我一樣傻傻的迷路 等等因素,出席的人數較少
  • 會議室空間較大,人數雖然也不少了,可是因為填不滿,所以看起來略為冷清

這次的演講由 Pinkoi 的創辦人/技術長 Mike 開場
演講內容提到了該平台現況(7k+ 的設計師)
以及使用的一些技術:
  • 圖片放在 amazon、有使用到 ec2
  • git 版本控管
  • Nginx + Gunicorn
  • Django -> 僅使用到 url routing 功能
  • Memcache
  • CouchDB
  • RabbitMQ (用來協助處理低優先權的工作,如:與ibon溝通、寄送 email)
  • 自行開發匯款給設計師、列印發票的自動化架構

我認同 Mike 大大提出來的的三個觀點:
  • User first
  • Tech. (用技術解決人力問題)
  • Done is better than perfect
受限於時間,我認為 Mike 大大的演講屬於點到為止
有些細節還是不太清楚,可惜演講後結束我又到處閒聊
沒有辦法請教一些問題 Orz



第二場演講是由 marr 大大向大家介紹 Plone
我有找到大大分享的投影片:
(所以可以不用節錄重點了 XDDD)
Plone 提供的 solution 很乾脆,也很專業
感謝 marr 大大開拓了我的視野 Orz







微。演講是由正。妹 mosky 分享她撰寫的新工具: enhancedyaml
其實我對 YAML 並不熟悉,記得都是在套件的 config 檔案會見到這種格式
有空再來研究研究!
畢竟我都用 markdown 在寫部落格了 … 認真理解一下 YAML 應該不為過 …



本月的聚會結束得較早一點點,或許是沒有用餐的關係?
不過我還是努力的湊熱鬧、當跟屁蟲、聽八卦

回家的路上緊跟著一群大大們回家
受到精神感招後,看來我該去報名 pyconf 2013 的志工了!

補充:
1. marr 大大有針對 Plone 的 scalibility 在 python.tw簡要的說明
2. Pinkoi 其實辦公室就在創立方內!(而且正在徵人)
3. 其實這次 Taipei.py 跟團隊的行程是衝到的 … 我當然是選擇參加 python 了!(握拳!)
(狀態顯示為一個月沒寫 python)
4. 我如果再一直寫不出文章,這裡就要變成 Taipei.py 心得文部落格了 Orz
(上一篇還被 keith 大大抓包~)
        5. 原來這裡有 Taipei.py 的 聚會歷史 可以直接找到講者的投影片跟資料
        (糟糕,下次不能用講者的投影片充心得文的版面了 Orz)

2012年11月8日 星期四

心得:AppWorks Demo Day #5

圖片來自 AppWorks,可以點此觀看 出場團隊簡介



前天我參與了 AppWorks 第五屆的 Demo Day,老實講,我很感動很佩服
我先在簡單此整理我所找到的資源:



加入一間新創公司 剛好滿一年左右
我參與過了三次的 AppWork Demo Day,心境卻有著非常大的差異:
  • 第一次,可以說是創業前期,抱持的想法是要來找有趣的東西,思考尖銳,自以為看得很清楚
  • 第二次,自身牽涉其中,嚴格來講,DEMO Day 前就是一直寫程式跟 DEBUG,這件事情一直做到當天清晨
  • 第三次,我好像看得懂比較多東西了,我知道他們的努力,他們面臨的情況,另外一方面也能夠明顯看出他們哪裡做不好或是做得很好

我想要從另一個觀點來聊聊 DEMO Day,他能帶來的效應有:
  • 「推」團隊趕快想出、做出東西
  • 訓練團隊表達、行銷能力
  • 提供團隊與其他人(創業者、專業使用者、創投、)社交、互動、甚至媒合的機會
  • 整場 DEMO Day 就是一個大型的行銷活動,宣傳團隊跟 AppWorks 本身
    老實講,是否能藉由單一活動博得很多主流媒體的版面,我認為這不是那麼重要
    好的東西,透過日積月累的動腦筋行銷,自然而然就能夠推廣出去,時間早晚的問題罷了!

就我的觀點,「創意」這一件事情並不是觀看 Demo Day 最需要考量的地方
創業不是僅只是創意競賽,他其實最大的成分叫做執行力競賽
我甚至認為 Demo Day 上面呈現的「產品」本身也可以不是最大的重點
台上的講者所呈現出來的熱情、團隊的向心力跟合作能力才是最重要的
如同 Jamie 所提,需要 5-10 年網路公司才會逐漸成熟
對 Demo Day 的團隊們不宜太苛刻

這次的 Demo Day 中,各團隊的的商業模式較為穩固,甚至有很多人已經算是創業的小鳥或是老鳥了
就 presentation 這一件事情,我個人認為:
  • 1/4 表現方式不佳或是根本內容上就不恰當,很可惜
  • 1/2 能夠講出自己想要表達的東西,不過表達方式如果想要說服我,仍然小有進步空間
  • 1/4 表現佳!
抱歉,其實我自己很也毒蛇、苛刻啦…
但是就是曾經參與其中,我才會知道「把產品做好」以及「上台講清楚」這兩件事情其實並不容易做好
舉例來講,我的團隊講的其實也是屬於還不行的那一群(上台的版本算是可以了,練習的時候,我聽得想切腹)
(可以參考這篇文章:心得:PIPOSEA @ Appworks Demo Day #4)

取其優點學習,注意其缺失叮嚀自己
隨時問自己「如果是我的話,我會怎麼做這一個產品?我會怎麼 present 我的東西?」
這是我希望自己能夠做到的
新創團隊需要鼓勵,可以批評,因為這也是讓大家成長的好方法
如果只是無建設性的謾罵,就可以省下來了


備註:
最近團隊在進行腦力激盪思考下一個 Project
提 idea 時,總是會有讓大家大笑,覺得很蝦的東西
但是靜下心來仔細想想,卻又往往有其可行性
如果只是一直負面的打槍別人,那麼團隊大概也想不出、或是能夠理性的思考出比較有趣的東西了
創業的夥伴們,共勉之!YO! (直銷?

2012年10月30日 星期二

心得:Taipei.py 2012 10 月聚會


這是我第一次到 果子咖啡 參加活動
對於此地的印象就是對
宅宅工程師的聚會非常友善:
  • 要吃晚餐的話,有兩杯飲料、一份果凍、一份主餐,對於腦力消耗大需要吃粗飽的人有所滿足
  • 宅宅 工程師的襯托下,女性店員氣質佳,看了心情就好 >///<
  • 提供了場地跟器材的協助(其實這一點才是重點啦!)
儘管我上個月沒有參加到 Taipei.py September Meeting
不過我剛剛找到「覺得用 Python 的都是好人」的講者 Tim Hsu 的 投影片 及另一位大大的 筆記
(同感啊~
用 Python 的男生都是好人,女生都是正妹

對於本月有關 ML 的演講,老實講,我聽不懂
儘管如此,其實我認為能夠在活動中跟同樣是 Python 的愛好者聊聊,才是最大的收穫
在這一篇紀錄性質文章的結尾,感謝本月講者 c3h3 、感謝活動舉辦人,並且附上投影片 Orz



2012年10月16日 星期二

心得:使用 Vim 編輯器的第一年

Photo from: Jesse Huey. Mountain Madness photo


記得當年大一剛學寫程式時,曾經被老師強迫要遠端登入助教的電腦用 Vi 寫作業
那個時候根本不懂怎麼使用他,就只記得 yy dd p :wq …,大概十支手指頭內數得完的指令
我對 Vi 的印象就是難用
雖然看起來比較帥 …
之後陸陸續續在:
  • Windows 用 Visual Studio 或是 Notepad++
  • Linux 用 Eclipse, Gedit 或是其他替代品
多年以來在 linux 終端機環境下,我就算只要編輯某個檔案一兩個字
絕對也是輸入 gedit filename 來開啟編輯器
只要能夠躲開 Vim ,就竭盡所能的逃開他 …
一年前我也還是這樣想
只是我大概沒有想到一年以後,情況卻相反
對於撰寫後端程式這一件事情,我現在認為 Vim 是最能讓我發揮高效率的編輯器
因此我試著撰文閒聊 Vim 這一個編輯器
這篇文章,不是教學,比較像是 Vim 嫩咖的經驗分享
文章的技術含量不高,不過可能會出現奇奇怪怪、有趣
(或不有趣)的東西 :p




開端是因為不得不使用 Vim

Photo Source


大約一年前,我 加入一間新創公司,當我聽到要寫 Web 時
腦中一瞬間浮現了唸書時的 100% 微軟完美解決方案:
  • Visual Studio
  • ASP.NET
  • C#
  • MS-SQL (但是新創公司哪來的錢買這些工具!)
很遺憾的,現在不是單純作學術,成本跟效能都得慎重考量
以 Linux 為主的解決方案才是大多數人選擇做 Web 的方式
很幸運的,我們團隊搭上了 AWS 的列車,我也被迫必須開始跟 Linux 做好朋友
而在必須遠端連線到工作環境的情形下,我不得不使用 Vim 來編輯設定檔、程式碼
初使用時,早已習慣 Visual Studio 的我只覺得超級不方便 (
上下左右移動時手指頭敲得好累)
但是隨著 .vimrc 的調整、plugins 的安裝
卻越來越習慣這樣的開發環境,我想 Vim 有幾個決定性的優點:
  • 少了滑鼠的干擾,Vim 讓我雙手不用離開鍵盤,可專注於打字以完成眼前的工作
  • 便捷的文字處理功能,非常適合撰寫及修改程式碼
    舉例來講,撰寫一般的文章時大都想好後循序打出即可
    但是寫程式卻常常要塗塗改改或是重複使用剛剛命名的變數…
    Vim 的文字處理功能從低粒度的修改到全域的修改都能支援,使得撰寫程式這一件事情是有效率的!
  • 可以依照自己的使用習慣客製化出自己喜愛的 Key Bindings
  • 可以安裝 Plugins 來補足想要的文字處理或是 IDE 功能
  • 內建於非微軟的大多數環境,到處都可以使用到 Vim

當然,Vim 也有著「學習曲線長」、「使用者需要載入比較多記憶體以記憶快捷鍵」 … 的缺點
我認為 Vim 無法成為短時間內好上手,且高效率幫助開發的工具
但是如果一個編輯器要用十年,那麼具有高度成長可能性的 Vim 會是很好的選擇




跟著比自己好學的人學 Vim 比較快

Photo from: saxon. Follow my lead


事實上,使用 Vim 的前兩三個月,我還是處於不太會使用 Vim 的狀態
我覺得自己「真的」開始學 Vim 的時間點其實是在今年初
而學習 Vim 的方式很簡單,就是每天定時看噗浪
剛退伍時由於整個人腦殘,為了恢復腦袋,我會在噗浪上面「搜尋」特定關鍵字(如:Vim 或 Python …)
以訂閱各領域大大的噗來吸收經驗值
我很幸運的剛學 Vim 沒有多久,就遇到噗浪上的 某大大 也在學 Vim
因此我的學習方式為:
  • 每天看大大們分享的連結或文章學 Vim
  • 一看就懂得就馬上學起來
  • 要花時間吸收或練習的,就擺著慢慢吸收(有時候一篇文章會擺一兩個禮拜)
  • 真的看不懂或覺得 Level 超過自己太多就自動忽略 (反正重要或好用的東西會一直出現!)
學習的過程中我發現越是大大越好學
而自己找資料學習的能力太弱,倒不如先跟著學,然後再偷看大大都到哪裡學 …
截至目前為止,Vim 對我而言已經是一個高效率的編輯器
我相信持續學下去,總有一天使用 Vim 寫程式的速率應該可以達到大大們的 1/3 吧!?
其實我認為 Git 的流行對於 Vim 的推廣跟使用是有所幫助的
使用 google 趨勢搜尋「github vim」整體來講熱門度不斷上升
現在只要稍微找一下,就可以看到國內外神人們所分享出來的 Vim 相關 Source code
而每個人使用的小技巧,也很容易可以分享給他人知道




Vim 是一把可變形、可升級的武器


Source



透過修改 .vimrc 及安裝 plugins,Vim 能夠變得很不一樣
我在此分享一些我常用的
瘋狂設定:
  • 在 Normal Mode,我喜歡使用 ',' 鍵 當作 leader key
    • let mapleader = ","   
  • 建立開啟 .vimrc 的快捷鍵
    • map <leader>v :e ~/.vimrc
  • 建立快捷鍵以使用 source 來重新讀取當前的 .vimrc
    • map <leader>R :source ~/.vimrc
  • 如果與同事共用主機帳號,怕自己的 .vimrc 會干擾對方 讓對方吐血而亡,那麼可以在 .vimrc 放上這兩行
    • let mapleader = ","
      map <leader>vv :so ~/.real_vimrc
    • .real_vimrc 才是你真正的設定檔,而你的設定檔只在你使用快捷鍵 ,vv 的組合之後才會讀取進來
  • 在分頁之間切換時,我喜歡對分頁 1~9 用下列方式設定快捷鍵
    • map <leader>1 :b1
  • 鍵盤上的「上下左右」方向鍵不用白不用,我拿來將上下改為翻頁且置中、左右改為前後分頁切換且置中
    • nnoremap <up> <C-U>zz
      nnoremap <down> <C-D>zz
      nnoremap <left> :N<CR><Esc>zz
      nnoremap <right> :n<CR><Esc>zz
  • 我是瘋子請大家不要學 我從小打電動上下左右移動都是 wsad,常用的方向鍵也是倒 T 字型 …
    • 所以我認為使用 hjkl 移動 不如使用 ijkl 倒 T 字型移動
    • 對!我用 h 取代了 i,大家天天打 i,我卻天天打 h …
    • (太瘋狂了,相關設定不附上)
  • 另外我認為從 Insert Mode 回到 Normal Mode 需要按 Esc 鍵,我的指法適應不過來,因此我選擇使用 ;; 代替 Esc
    • inoremap ;; <Esc>
    • 事實上 ; 符號成為了我在 Insert Mode 下的 leader key,例如以下用法可以切換到 Normal Mode 並選取當前字:
    • inoremap ;v <Esc>viw 
    • 在 Insert Mode 下單鍵存檔
    • inoremap <F6> <Esc>:w<CR>
    • 輸入單一個 ; 符號時會發現速度較慢,可以透過 ; + <Space> 來輸入 ;
    • inoremap ;<space> ;
  • 如果需要直接以 Python 執行此檔案,可以使用以下的設定:
    • autocmd BufRead,BufNewFile *.py map <leader>r :% w !python<CR>
  • 個人奇怪的 Key Binding 還蠻多的 畢竟連 i 都敢改掉了,有興趣者請告知,我整理後再釋出!




Vim 仍然需要維護、需要管理

Source


對於 .vimrc 的內容我一直很隨便,看到有趣的語法就隨便找空位插進去
Vim 的 plugins 也是看到感覺不錯就安裝一下
結果這樣子胡搞到後面,我根本不知道我自己裝了哪些 plugins 跟設定哪些快捷鍵
除了快捷鍵之間可能有所衝突以外,更糟糕的是 Vim 的速度也被拖累 …

前一陣子我總算痛定思痛,乖乖把 .vimrc 整理一下並且打上給自己看的簡單註解
Vim 的 plugin 管理工具,也從 Pathogen 換到更強大的 Vundle

此後只要帶著 .vimrc 走就可以在不同環境自動把 plugins 給安裝好,一切變得便捷許多
對於 .vimrc 及 plugins 的使用,我目前傾向「真的要用到再加入、安裝」
盡可能使其保持乾淨狀態或說讓其為可掌握的




對於 Vim 的看法

Photo Source


Vim 的進入門檻跟學習曲線其實還是頗高
我也認為他還不夠友善,印象中 Linus 大大大大…
好像在某訪談中有提到,他手邊有一個編輯器能夠讓 Vim 看起來像記事本 …
或許改天釋出後會八掉 Vim!?

我認為 Vim 的優點是 Normal Mode 與 Insert Mode 的區分
缺點卻也是這兩個模式的轉換成本
客觀來講,的確是有可能讓這兩個模式相處得更好
(事實上,許多人會從設定 Insert Mode 下的快捷鍵開始著手改善)

對我而言,使用 Vim 後的確讓我仔細的思考過自己的打字習慣及弱點
例如我發現原來我只會打注音符號跟 abcd ,有許多標點符號跟數字並不在我的反射神經之內…
在這種情況下,使用 Vim 的效率就降低啦 Orz

我相信,無論使用任何編輯器
只要願意用心分析自己的使用情況及思考編輯器實際上能夠提供的幫助
就一定能夠找到最佳化自己工作效率的方法

總之,寫程式還是要靠大腦,編輯器升級人也要跟著升級,才不會發生悲劇
在接下來的一年內,希望我可以學跟寫一下 Vim Script,期許自己能夠更加掌握這一個能夠用十年的神器!
各位再見啦~明年 Emacs 的心得文見!


備註:
1
如果有人還沒玩過 Vim, NCTU CS 有對 Vim 做很好的介紹
現在在成大教書的 Jserv 大大… 很久以前也做了一張 Vim 的 好用小抄
另外到 google 搜尋 「Jserv 自幹」,點選第一部影片,就可以看到 Vim 的火力展示
2
本文風格可能有點詭異,不像技術文章,不是專家見解,但也不是那麼純粹的喃喃自語
我也不知道這種文章怎麼歸類,但是大致上是整理過後的心得文
無論如何,我也還在試著學習怎麼寫出有自己風格的部落格文章
如果您有任何看法或建議,請告訴我一下,以幫助我升級 Orz
3
這是我寫於四年後的另一篇 Vim 心得文:閒聊:使用 Vim 編輯器的第五年

2012年9月13日 星期四

活動:Facebook World Hack Taipei 2012


會場在 101 對面,風景好的很,還有真實的憤怒鳥彈弓可以玩

開發人員目測應該有 150 ~ 200 人,雖然活動很低調,可是來的人還是很多啊!


這是我第一次參加 Hack Day 類型的活動
活動的場地實在很不錯,風景好且放嗨歌寫 Code 真的頗熱血
我還記得我把憤怒鳥玩偶用真的彈弓射出界且又高又遠
旁邊的工作人員一直偷笑 XD
整個 Hack Day 的規格確有國際水準

為了這次的 Hack Day, 我從現有 全民電視 的專案
整理出了一個基本版的 Facebook Login/Logout API Framework
只要套上申請好的 Facebook Key/Secret 等等設定,就可以提供 client 端基本的登入登出等等 API 功能
這套 framework 當然是 open source 的!
不過現在沒有什麼價值,運作方式只會讓人覺得很詭異
因為專案中夾雜著剛學 Python 時所寫的 Child Code 以及許多我們平台綁定的格式及 Code
此 framework 目前 不推薦使用也不推薦觀看
希望接下來幾個月,能夠有時間整理出一個乾淨且泛用的 API Framework, 甚至提供 Long-Polling Class 的 Support …


此次的 Facebook Hack Day 活動,在活動開始前我們團隊發現幾件事情:
  • 這次的活動異常的低調,似乎知道的人很少,有相關討論的人也很少
  • 整個 Hack Time 只有六個小時
  • 獎項很不明,只知道最大的獎項是可以去跟 Facebook Team 見面
  • 之前其他地區舉辦的 Facebook Hack Day 系列相關活動的得獎作品,大都概念很簡單,如:製作生日快樂罐頭訊息的 APP …

仔細想想整個 Hack Day 對於 Facebook 而言,目的可能是:
  • 推廣自己 (Open Graph, Mobile SDK … )
  • 看到許多人開發 Facebook 相關的 App, 而且此 App 是對 Facebook 有所幫助的
  • 找到他們所感興趣的團隊
  • 有關讓 Developers 之間互動等等的目的就不再贅述 …

Hack Time 只有六個小時很明顯是不太夠的,從認識朋友、組隊、討論、實作、準備 DEMO …
這些程序恐怕就要花上一整天才有辦法產生比較完整的東西
所以 Facebook 不想要收到完整的東西?
我認為他們要的就只是一個對他們而言有創意的 Idea, 一個善用他們提供的資源所做出的產品
(且此產品要對其核心價值有所幫助)
Idea 是不是事先想好,甚至事先偷跑了都不是他們最 Care 的事情!
當然,如果只是把整個早就弄好的產品也不修改就拿來參賽,那就會完全失去了 Hack Day 的樂趣 …
這一切都取決於參賽者的心態跟目的


我們考量到既然要參賽,那就乾脆做一個自己覺得有趣,且 Facebook 一定也感興趣的 App
於是比賽前幾天,我們做了以下準備(偷跑):
  • 每天真的都在 Hack Facebook 的怪咖 CEO 負責系統設計,撰寫文件跟設計 DB 格式
  • 我開始整理 API Framework
  • 負責前端有時候還要跨後端的強者我同事則是開始玩 twitter bootstrap, angularjs …
  • 手邊有國際等級 APP 的 iOS 工程師,因為家裡有事情,臨時無法參加
簡單講,我們的 Hack Day 很不要臉的從週末就提早開始了!
由於萬事具備,比賽當天我們能夠當場申請新的 Facebook App, 即時調整 Serer 的設定
然後 Oauth Login 的功能,花幾分鐘改個設定就會動
要存取 Graph API 的 Function 早就寫好了,連要使用 Graph API Batch 功能的 Function 也都包裝好,可以馬上使用
(很遺憾我們沒時間申請網域跟處理 SSL 憑證,所以只有直接的 IP Adress … 造成了後來的一些問題)
當天 Hack Day 下午,我就看著文件拼命寫 Code !(事實上,前一天我還先寫了兩支 API)
最後我爆氣大概寫了 300 ~ 400 行 Python Code ,對我這種 Coding 嫩咖,已經算是突破自我了

Demo List


輪到我們團隊做 Presentation 時,遇到了很囧的事情:
  • 電腦被 似乎沒用過 windows 8 的 工作人員重開機,事先準備好的頁面都沒了 …
  • 遇到解析度跑掉的問題,整個頁面都看不完整
其實當下應該要拒絕馬上開始,堅持把環境處理好以後再開始 present
不過我們本身隨機應變的能力還不夠 … ,且就算扣掉上述問題,我們的整個 presentation 本身也處理不好
因此最後我們家的老闆跟怪咖 CEO Terry 拖了大家很多時間
Presentaion 過後,大家其實頗為沮喪,一個有趣的 Social Game 被 present 得很不有趣 Orz
仔細想想,其實整個 Hack Day 最大的重點是 presentation 是否能夠:
  • 表達出自己的 Idea
  • 說出此產品哪些特點符合 Facebook 的需求
  • 給大家看到產品完成的樣貌(但是不用全部沒關係)
亦即,很多產品非關緊要的細節其實不用實作 只要能夠完成基本要求(例如使用 Open Graph)得到分數即可
重要的還是想辦法在時間內讓大家印象深刻、理解我們想要作什麼!



遊戲首頁



進去後的個人畫面


遊戲畫面(先跟當事人抱歉,我幫你們做了馬賽克 XD)



最後的最後,很幸運的評審們應該知道我們在做什麼
我們得到了 最佳遊戲獎
禮物有: iPad, shuffle*2, $250 Facebook 廣告費用 …
最重要的是得到了 Facebook 的肯定
我們能夠在短時間內原創、設計,並且手工打造出了一個 Social Game: Memory Millionaire !
(雖然內含許多 BUGS)
這樣快速開發一個產品的過程(發散、收斂、衝突、妥協、爭論、配合),才是我們團隊所得到的最珍貴經驗!


之後我們會討論如何推廣並且讓大家都能夠玩到 BUG 比較少的這一款遊戲!
Cheers!