閒聊：那些人年，我們一起跳的軟體開發坑

如果您已熟悉 Agile 方法或軟體工程且有開發經驗

那麼這篇菜鳥文可直接跳過啦！ ... Orz

我跳「坑」了！

出來創業以來，體會到了一件「大家都知道」的事情：
「學界、業界、創業界之間是有資訊落差的，且越差越大！」
主要是因為真實環境變化大而學界動作太慢 ...

這將會使得學生總是用已逐漸成為歷史的「學習方法」學習可能已經成為歷史的「課程」
最終的影響是：「缺乏與外界接觸的學生，畢業後相對沒有實戰力，甚至完全不能用！」
進到大公司表面上還好，因為有新人訓練的規劃，以讓人變成該公司專用的人才
（顯而易見地，訓練內容是不會教該公司不需要的東西的）
若進到小公司或自行創業，則必然會有一段陣痛期，或者說是「鴻溝」必須跨越 ...

身為在大學研究所點了六年學生技能，後來才從軍人轉職成創業者
我在此分享這兩年來寫 Web, App 以來的心得：

1. 要培養「能」寫程式的能力不至於太難 ...

只要「一直」動頭腦想，有空補上一些學校沒教的書
（請謹慎閱讀/使用/或先不讀 Design Patterns）
寫出來的程式大概都會動 ...
（而且因為寫得很爛所以每次重寫都有進步空間）

2. 要培養「能」架構系統的能力也不致於太難 ...

看多就知道自己該用些什麼
試過就知道好不好用
（但是就算跟專家用一樣的架構，效能跟穩定性並不代表就跟人家一樣）

3. 要「能」順利開發專案很難 ...

真的很難！
客戶的「需求變更」等等外界因素固然會影響專案開發
但是更根本的原因是因為開發團隊：「無軟體開發的基礎知識與實作經驗」

這件事情有點恐怖，因為一次的專案開發，往往要花費好幾個人月甚至人年才能完成
缺乏規劃跟執行的專案，最終導致的成果就是：「一延再延」、「做不出來」、「提前終止」...
因此一個糟糕的專案，可以浪費掉一個人數月至年的人生 ...

有人問為何會無基礎知識與實作經驗？
因為學界內寫的大都是功能性程式，測完數據或是能夠 Demo 就功成身退了 ...
分組作業寫的專案，大都一人（或一神人）就可以直接 KO 掉 ...
至於課程所學的軟體工程 != 真實軟體開發
課程內容除了較廣以外，也往往位於過高抽象化的層級
對於根本沒有實際開發經驗的學生而言，修習軟工的課程是難以感同身受而觸發興趣的 ...
所以說，要一群剛畢業的菜鳥們，要從無到有的開發專案，會遇到很多困難

4. 要「能」順利創業登天難 ...

這不是坑，是大峽谷 -> BJ4。


要把程式寫好、架構出良好的系統是一件很難而必須一直學習的事情

然而，開發稍微大一點點的專案的時候
軟體開發的流程問題就會先被突顯出來，且牽涉其中的人員已經不是個人的事情
一個好的流程能夠讓開發者開心而有效率的製造「垃圾」（只要客戶願意付錢）
但是一個不好的流程，就算是在製造「寶物」，開發者也會覺得很痛苦

「坑」在哪裡？

以下條列一些常見的錯誤：
（這裡以中小型專案為例，不考慮短時間、少許人力可以完成的微專案）

搞不清楚客戶的需求

交付能夠讓客戶滿意的程式，並且依照其功能要求開發出產品是軟體開發的第一要務
所有人也都會同意，要經過與客戶密切溝通、互動，才能夠真正理解客戶的需求
更甚者，初步了解客戶的需求以後，團隊成員們該動起腦袋們，想想如何實作時
一定還會想到一些問題要釐清，或是需要客戶下決定的地方
因此，盡可能定期與客戶溝通，以追逐可能會有所變動的需求會是個好主意

問題來了？要怎麼知道自己已經了解客戶的需求？
不用懷疑！寫下來並且與客戶再次確認吧！
所謂的你「以為」已經了解客戶需求，跟客戶的「以為」你已經了解他的需求
都只是「以為」，且只存在於當下，無法有效傳達給不在該時空的人
用客戶看得懂的 User Story 與客戶驗證需求，才是保險且必要的作法

何以必要？因為舉凡專案開發，客戶一定會詢問開發時間要多久？
倘若沒有記下 User Story，那麼便不可能將其進一步擴展成 Use Case，抑或拆解成細部的任務
更不可能根據任務、以及團隊過往的開發效率「眾人一起」來推估出準確的開發時間
如此一來，要向客戶回答時間就只能「靠感覺」、「靠經驗」了
很容易承諾出一個根本做不完的時間 ...
更危險的是，因為沒有僅抓住客戶需求，產品還有可能不是客戶想要的 ...

這裡另一個常見的情況是，客戶找上門時已帶著所謂「寫好」的文件
文件可能是一張手寫的便條紙、兩三頁 A4 的規格書、UI 的畫面 ... 從殘缺到極度詳盡都有可能
此時要做的事情仍然一樣，協助客戶描繪出 User Story 並驗證需求
有可能只要改幾個錯字即可，或須將畫面轉換成描述更加精確的文字及規則 ...

客戶不會想要開發沒有使用情境的軟體
所以委託給你開發的軟體一定是給 User 在某些情境下使用的
（這裡的 User 未必是人，也有可能是動物或是另一個軟體）
藉由描繪並寫下 User Story 才能夠協助團隊捕捉客戶當前的需求
進而確認潛在的需求、知道「不要的需求」以及確定團隊每個人認知的客戶需求一致

缺乏計畫

當確定要開發客戶的專案，就到了為團隊排定行程以進行開發的時候
以下行程的排法都頗恐怖：

• 「上線前一週，client 會和 server 串接以進行測試」（也太晚了吧！）
• 「精密的排定每日行程至半年後」（過度計畫，根本不會準）
• 「直接讓負責各區塊的工程師動工，他們會知道怎麼做」（確定？）

若以上述最末者為例，若 User Story (Use Case) 及任務等等已備齊
雖可確保當時開發的方向不會偏移掉
但，實作的人員是沒有「優先權」的概念，且預設不會對將來的「需求變更」有所準備的

倘若客戶在開發兩個月後，臨時想看 Demo 了解進度（結果程式架構要到第三個月才能串起來 ...）
或是臨時決定拿掉一部分比較不重要的功能（因為他比較好做，所以就先寫了 ...）
這都很可能會造成悲劇
所以說若只是訂出一個最終的 deadline 而不是分階段驗收
搞到後來產品拖延或失敗的機率是會升高的

因此，規劃階段式的開發週期，並且定期與客戶核對需求會比較保險
從更本質上來看，要排定週期內的行程，及預測自己是否做不做得到一定是比較準確的
這樣的作法額外的好處是，週期若固定，那麼過了一個週期後
透過比較「預測」情況與實際情況，是有助於了解團隊開發效率的
也能進一步改善「預測」能力，以便在下一個週期排定恰當量的工作

階段式的開發->展示->與客戶溝通，除了能跟客戶核對原本的需求以外
也能夠因應客戶的要求排入新功能，並且讓客戶決定優先權
有點像是：「您要增加 C 功能，可以喔！但必須延後 A 或 B 的開發，請您決定？」
在各階段開發的過程中，由於功能一項一項的完成，且可以被展示
所以客戶會安心、而開發人員也可以將壓力分散

埋頭苦幹

執行專案時，最忌諱的就是眾人都同時進入長時間的埋頭苦幹期而忘記專案的初衷與規劃
因此，請記得將專案開發的目標與進度透明化

專案開發的目標，對客戶而言自然就是滿足那些 User Story
對開發團隊而言，就是完成那些 User Story 所拆解出的細項任務
且這些細項任務是該被「估計」要多久才能完成的（不然怎知道此階段團隊能完成多少任務）

當這些必要的前置作業都完成後
開發團隊在短期埋頭苦幹以取得最佳工作效率時
才能夠隨時在休息抬頭時，看見工作目標
並透過比較實際花費的時間與估計值，了解工作效率
除了尋求改善，也能以此為經驗重新預估接下來的任務所需要花費的時間

糟糕的執行力與缺乏測試

糟糕的執行力有分許多層次，在此列舉部分：

• 寫不出來
• 寫很久才出來
• 寫出來，但是錯誤百出

造成上述狀況的原因不外乎是「缺乏程式能力」與「缺乏測試」

工程師要有基本的程式能力才能完成需求的功能
要有一定水準的程式能力才能在時間內完成需求的功能
要有一定水準的程式能力與測試概念，才能在時間內完成需求的功能，且正常運作

補足程式能力，是所有程式設計師都知道要做的事情
資料結構、演算法、物件導向 ... 熟悉與否都會影響到開發出來的軟體品質
然而，「測試」的重要性是容易被忽略的
甚至，我個人認為對於使用 OO 語言的新手工程師而言
若有時間進修，學測試的實用性還遠大於 Design Patterns

理由很簡單：「程式碼總得被執行」

就算不套用書上特定情境的 Best Practices 來解問題
你也能用當前已掌握的知識來解決問題（雖然未必是漂亮的解法）
但是無論如何：

• 每當寫完一個小 function，總得知道輸出的結果符合不符合預期
• 每當寫完一個小功能，總得知道運作起來正不正確
• 每當寫完許多小功能，總得知道相互運作使用時正不正確
• 每當新增/修改部分程式碼時，總得知道會不會影響到既有的功能
• 每當完成了一個版本以後，總得驗證在客戶的需求情境之下，系統運作是否正常

在「程式碼總得被執行」才能驗證對錯的情況下
研讀各種技巧、思維來最佳化「測試」這一件事情，是能夠對軟體品質大幅提升的

過度設計

「過度設計」在軟體開發的過程中無處不在，並不是只有在設計初期才會出現
巨觀而言，設計的軟體可能會擁有客戶不需要的功能、或是建構出不合理規模大小的系統 ...
微觀而言，撰寫了很多用不到的 function、為了大量地預留延展性而讓人不易理解抽象架構 ...

可想而知，「過度設計」會帶來的缺點就是「費時」
設計本身要花時間，因為設計而「Block」到其他人進度也會耽擱他人的時間
實作設計會花時間，因為設計太複雜，而得費更多力氣來實作，就得花費更多時間
最後軟體因為複雜度的提高，導致更多的臭蟲，得花額外的時間解決

要克服過度設計非常困難
總結來講，擁有「足夠的開發經驗」就能較妥善的面對「過度設計」的議題
然而，在累積足夠的經驗之前該如何對設計做取捨？

巨觀而言，時時刻刻謹記客戶的需求
微觀而言，隨時記得「程式碼總得跑」這件事情，讓程式碼的目的符合該粒度下的使用情境
甚至，透過優先考量「怎麼跑、怎麼用」這件事，先行實作測試並且同時設計出必要的系統

最後回到創業坑

之所以會有本文，是因為前一陣子看到了一篇文章：

• Spotify 的敏捷擴張之道：部落、班、橫向編組與同業公會 | zonble

對 Spotify 的組織感到震撼、佩服之餘，我也不禁脫口而出：

「這要怎麼打啊？」
「他們可是組織成了一支軍隊來跟別人打群架 ...」
「我們連願意一起打群架的人都還不多 ...」

我只能說 ... 創業要考慮的面向非常多
然而無論如何，資訊人最終還是得進行「軟體開發」才能做出產品
培養其能力與正向生態系的重要性自不可言喻！

備註：
本文非常簡略而不全面地探討軟體開發時常見的坑
（基本上，我都跳進去過了 ...有的還跳不出來 ox@#.） 
我也盡可能避開專業名詞，盡量換句話說，以練一下表達能力 （結果還不太行）
事實上，本文也是我讀完新手村內的「深入淺出軟體開發」後的心得 （有猜到嗎）
推薦給資訊相關科系大二以上的學弟妹讀讀（附上網友整理的筆記）
或許你會因為沒有實際開發過軟體的經驗，因此不能完全理解書中講解的內容
但是留點印象是好的，若能激發你的興趣去了解軟體開發相關的技術就太好了！

活動：AppWorks Demo Day #7

AppWorks Demo Day #7 已在 11/18 於台大醫院國際會議中心順利舉辦結束

詳情可觀看 Jamie 的 一句話介紹版本 與 之初創投部落格的介紹

這是我第五次參加 Demo Day 的活動
從局外人、局內人、記憶猶新到事過境遷（搬到台南）
每次參與都有不同的感觸

若要我快速的摘要這次的 Demo Day
我會說「演講表現是歷屆以來平均水準最好的一次」
儘管團隊數較少，聽起來不夠過癮
但是演說表現得更加沈穩且帶有誠懇
我不太喜歡所謂「套公式」「拍廣告般」的演講
前幾屆太過了點，這屆又好了點

本文不談各個團隊表現該得幾分或是是否有前景
沒意外，一年後至少有半數的團隊會 pivot 成別的方向甚至陣亡 ... Orz
我更在意的是總體的組成、走向、氛圍如何
這些資訊不僅能反應出創業的動向，也能夠知道之初創投挑選及培育創業者的情況如何

舉例而言，最近兩次活動都出現了軟硬整合（及穿戴式）的產品
可見創業者對於創業方向的思考能夠更加開放（本來就不是只有做 Facebook, Google ... 才是創業）
以往非常多人想挑戰的旅遊資訊整合服務，這次沒有人跳坑 ...

說穿了舉辦 Demo Day 就是強制讓各屆的創業者們
進行「DDD」(Demo-day Driven Development) 的創業之旅

對於菜鳥，因為期限已經定出來了，所以無論如何得在這段時間內生出東西
對於老鳥，則是一個規劃好的機會，得好好把握讓大家看見自己
在這段期間，則進行各種培育：「聽演講、參訪、演練、媒合、研討、諮詢、共享資訊 ... 」
要評斷這樣的培育有沒有效？是不是最好的？是難以回答的
同樣的機會成本，創業者如果更專注於做產品會不會更好？也是沒人能夠斷言
難怪乎記得 Jamie 有提到要五年十年後再來看看這一群人組成的生態系是否對大環境帶來影響 ...


但是若以軟體開發的觀點來看創業，這樣子的培育蠻科學的
培育過程就等於定下計畫及每個階段的檢核點以執行一個「創業」的專案

原因是：「新手寫程式容易過度設計，創業者也是如此！」

定下絕對的 Deadline 就等於決定一個開發週期，以聚焦去完成這段時間內可以完成的事情
進而，各小階段完成的作品，都會有現成的測試者可以幫忙檢視、測試
當創業者有了「同學」，則共享的概念使得創業的過程能夠取用到他人願意分享的資源
(有點像取用開放原始碼資源的意味 ...)
在這種環境下，除了有機會修正創業方向（「做對的事情」）
也能夠在過程中一點一滴累積創業能力（「把事情做對」）
整體來講，應該會是一件好事

活動：Tainan.py x MOSUT 2013 11 月聚會

餐會休息時間，朋友們熱烈地互動！

這次聚會的場地回到 Isrlab！

多虧其大力相助，我這次有空去吃鹹酥雞 XD

睽違了兩個月的聚會順利舉辦完成！



這是 Tainan.py 舉辦以來最「南」的一次（無論是講題還是講者組成）
議題涵蓋 Python 的 GC, 部分底層實作, 數學x演算法x安全工程, PyPy, Git ...
紮實而接近 4 個小時的演講，讓聽眾滿載而歸
以下為懶人包的整理：


我負責暖場，重點其實是宣傳花蓮.py 已成立與 *.py 系列的工商服務

投影片

第一位講者為果凍（常在 Python 社群分享底層實作相關講題）
兩個講題為 Garbage collection 與 += vs. join 比較
前者搭配投影片，讓人很快地對 Python 的 GC 有初步的認識
後者 += vs. join 則相當解惑
我個人認為這兩個探討的主題都很有趣、實用而值得一聽

投影片：Garbage collection 介紹

投影片：Python 中 += 與 join比較

第二位講者為 kuku（Isrlab 員工 + hacker）
講題為「數學女孩之機率的崩壞」（數學、演算法與安全工程相遇 - 第一講）
事實上是資安入門及探討亂數產生這一件事情
這是我回台南以後第一次聽到資安相關的講題（真是太棒了！）

餐會交流時間，我們吃了友愛鹽酥雞 + 阿卿杏仁湯/紅豆湯（休息了半小時）



第三位講者為 jserv (神人 ... BJ4)
講題是 PyPy ，這個演講非常珍貴而難得！
怎麼說？一般人用 Python 一段時間以後，總是會想要了解其底層的實作（感謝果凍）
而當想要讓 Python 程式加速時，PyPy 總是會被拿出來討論
究竟 PyPy 是怎麼做到的，他到底是什麼？
由研究編譯器及 ... 多年的 jserv 來向我們介紹是再恰當不過了！（強烈推薦一看！）

投影片 

PyPy 開發部落格

第四位講者是 Descent，表面上投閃電秀，事實上錄影有 45 分鐘 XDDD
講題仍然為 git，介紹各式各樣修改 commit 的方式
如往常般，Descent 的演講都會讓大家打開話夾子
（究竟為什麼會從 git 探討到 3.5 磁碟片到用紙帶幫 CNC 機器開機，請看影片！）

講者  Descent 的部落格

演講結束後，留到最後的幾位朋友就一起去吃府城牛肉湯，圓滿地結束本月的聚會 :p

後記閒聊

會後有學弟（都比我早）寫了 筆記文、心得文
文章提到聚會有上課的 feel，是的，這正是目前 Tainan.py x MOSUT 聚會的特色！

有別於 Taipei.py 20~30 分鐘的短演講
Tainan.py 的演講長度更像上課，常常一場 40 分鐘以上
但是不同的地方在於，聚會時間是週末，大家是抱著放鬆的心情與求知的熱血來參與
我發現，不去限制講者的演講長度與方式以後
講者不但可以分享更多，聽眾受益於輕鬆活潑的氣氛，也更敢問更多問題
雙方互相交流之後，自然而然就學得更多了！

（這或許也是一個理想教學 / 學習環境的雛形）

退伍後出來創業亂衝亂撞兩年以來 ...
多虧了沒有直接拿不知道堪不堪用的成大碩士文憑去大公司要一顆便當
而是彎下腰來種稻自給自足（結果發現自己不太會種，常常肚子餓）
看到自己的不足之時，也藉機不斷地去思考自己所接受過的教育、環境、心態哪裡出了問題
相信隨著麥穗越來越高，我也能用更加宏觀的視野看清楚答案 ...

總結目前的心得，我只能說：「學弟妹們，出來走走吧！」
沒事多關心、參與 open source 的 project
有社群活動、研討會也空去參加一下
最後，就算沒打算創業也稍微留意相關資訊（有個概念也好）

當學校某些課程落後太多，已經變成在教歷史課（ref: jserv）時
其實上課了解一下並無不可，歷史中總是有「教訓」跟當時的核心概念可供學習
但是當學校只教歷史課的時候
要不要到外面修「其他的課」就值得好好思考了。

工商服務： 就在 12/10 19:30 @ Isrlab
kuku 將加開一場數學及演算法與安全工程相遇的演講
歡迎各位朋友踴躍參與！聚會資訊

好便宜書分享：網路強人會

書本實物大概長這樣

（螢幕背後露出來的網頁是 恰好 是敝公司開發的「手滑背單字」App）

先來猜猜這本書多少錢？

299? 還是 199? 難道只要 99?
事實上，不用錢！讀者只需要自行負擔運費 80 元即可取得

這是一本「自寫、自編、自行出版、自備通路」的書
詳情可以到氣勢磅礡的 pre-order page 瞧瞧！

這本書值不值得看？

我認為 Jamie 寫的 推薦文 非常中肯：

「我會把它推薦給想要進入網路及電子商務產業的人，以及在這個領域工作不久的朋友們。」

我拿到書以後，當天就花了 2.5~3 小時把書給掃完了（我看書頗慢 ...）
感想是：有所收益，可觀，且 80 塊很超值

出來創業一兩年內的新手們，其實還蠻推薦看看這本書的
尤其技術出身的創業者，總想著「我要怎麼做出一個偉大如 Facebook, Dropbox, Evernote ...」諸如此類的服務
卻往往特別不會對內容網站、購物網站、個人網站有所思考
本書作者光是能夠概略的點出這些網站分類，考量到台灣環境的情況下分享見解，就算是功德圓滿了

本人平常是少看網路行銷相關的東西，因為很多文章內容都極空泛
至於本書，我認為對我有參考價值
會不會再看一次不確定，但是要查資料時會記得這本書就是了！

備註：
1. 推薦給創業新手、部落客、對電子商務有興趣的朋友
2. 技術人，除非想要看一下專家如何分析各類型網站及經營指南，不然可以不用看
3. 要取得本書必須填寫會員資料進行註冊、作者的網站 滿滿的行銷個人媒體的資訊，完全符合書中見解 XD
（看完書後，我因此知道作者且相信他有料；作者品牌得到宣傳。這樣應該算是雙贏吧！）

好書分享：Remote - Office Not Required

Remote 是世界知名軟體公司 37Signals 的創辦人發表的新書
他們的前一本暢銷書 Rework (工作大解放) 可以說是每位創業者必讀的好書

前言

儘管我積欠了數篇部落格文沒寫（尤其是上個月底的 MOPCON 2013 心得文）
我還是用個人閒暇有頭腦的時間「優先」把這一本書給看完，亦「優先」撰寫本文
之所以這麼做的原因是要驗證我自己的想法、以及找到一些疑惑的解答

中文版還沒出，如何取得此書？

我是在 iBooks 上面購買的！
為此我申請了美國 iTunes 的帳號，並且購買 GiftCard 以支付費用

為什麼想要讀此書？

我在 Startup 工作兩年，工作環境經歷了以下階段：

• 「住辦不分，只有睡覺的地方跟工作區」- 極度燃燒（退伍後，短期這樣回魂最快）
• 「住辦不分，但是是在自己的房間工作」- 效率極佳（但是要跟懶散奮鬥）
• 「住辦略分，有自己房間，一樓是工作區」- 效率略低（意識到「干擾」這一件事）
• 「住辦分離，辦公室在商業大樓內」- 效率極低（驚覺這樣下去不行）

其實隔離在自己房間工作的期間，就有 Remote 的樣子了
自己要調配工作與休閒
在這段期間，我一直嚮往的就是完全的住辦分離
但是很遺憾的，公司租用了辦公室以後，並沒有為我帶來更好的工作效率

我有很多的疑問（且大都心中有底了）
所以我非常急迫的想要閱讀此書

誰適合閱讀此書？

廣義而言，只要您對思考「工作效率」這一件事情有興趣，就很適合閱讀此書
此書或許不若上一本書 Rework 般一直讓人感到「當頭棒喝」
但是它提供了對於 Remote 的全面思考：

• 對於已使用 Remote 的朋友：可供核對自身經驗
• 對於想要 Remote 的朋友：當作 Guidelines 來閱讀
• 對於從沒想過使用 Remote 的朋友：這本書的許多觀點將能解放你的思考
• 對於完全認為 Remote 不可行的朋友：可閱讀後仔細想想「是否真的完全不可行？」

事實上，「老闆」會比員工更加需要閱讀此書 :)

此書內容在說些什麼？

有興趣的朋友可以前往官方網站 REMOTE: The new book from 37signals
內有宣傳影片、搞笑訪問影片以及部分章節試讀的連結
國外也有人整理出五分鐘懶人包：A Book in 5 Minutes: “Remote: Office Not Required”

本書的主要章節有：

• The time is right for remote work
• Dealing with excuses
• How to collaborate remotely
• Beware the dragons
• Hiring and keeping the best
• Managing remote workers
• Life as a remote worker
• Conclusion

書中理性客觀地分析 Remote 工作的優缺點
且透過全面性的思考，告知讀者如何實行 Remote 及解決衍生的問題

部分摘要與筆記

• You can settle into your own productive zone. #Remote 的最大好處之一
• It’s the technology, stupid #能夠 Remote 的最大原因之一
• People go to the office all the time and act as though they’re working remotely: emailing, instant messaging, secluding themselves to get work done. #其實人們只是在辦公室做可以在遠端做的事情...
• Embracing remote work doesn’t mean you can’t have an office, just that it’s not required. #37Signals 總部也是有辦公室的，只是員工可以自己選擇上班的時間地點。另外該公司大多數員工皆分散在世界各地
• The bottom line is that you shouldn’t hire people you don’t trust, or work for bosses who don’t trust you #雇傭關係建立在互信之上
• Why not let people work the way they prefer, and judge everyone on what—not where—work is completed? #工時 != 產能
• If you’re in a room with five people for an hour, it’s a five-hour meeting. #常識
• When you’re used to interrupting anyone any time you want, there’ll be severe withdrawal symptoms when you can’t. #Interrupt 對產能的影響大家應該都感同身受
• You need solid writers to make remote work work, and a solid command of your home language is key. #雇用 Remote 員工時，要特別注重他的書寫能力
• If people can manage to build world-class operating systems, databases, programming languages, web frameworks, and many other forms of software while working remotely, you’d probably be wise to look more closely at how it’s done. #世界一流的開放原始碼專案，不幾乎都是 Remote 開發的嗎？
• Be on the lookout for overwork, not underwork #員工 Remote 時要擔心的真正問題
• But when they become the norm—when they’re abundant—you’ve got a problem. #人類對於易取得的資源總是傾向不珍惜，Remote 可以讓面對面這一件事變得更加被重視，進而好好利用這樣的資源

37Signals 的人是如何工作的？

其實我猜，這是已在 Remote 的朋友最想要知道的事情
這些經驗大都打散在書中的各個部分
看過之後，可以一窺少許面貌：

• Remote 的人要有基本的 Security 防範措施（書中列舉六點）  
• Remote 工作時要與其他人有 overlap，建議 4 hours
• 善用各種軟體以供協力作業（書的附錄有列表）
• 每週進行一次「你最近在忙什麼？」的討論串
• 一周工作以 40 小時附近為佳
• 每個月至少打一通電話給 Remote 的員工，聊聊他們的情況（因為很多員工都在國外）
• 員工會有一張公司的信用卡，使用準則是「spend wisely」（當然，賬單是記錄且公開的）
• 員工如果要請假（無論長短），不用經過審核
• 提防 overwork 而非 underwork
• 有些員工在家會用各種不同的方法來區分出上班模式與休閒模式
• 有人每天去不同的咖啡店工作，觀察細節上的異同
• 書中有提醒到「人體工學設施」的重要性
• 面試重解決問題的能力而不是腦筋急轉彎
• 用 pre-hiring 的方式丟 mini-project 給面試者實作以評估能力（一兩周，給大約 $1500）
• “Have I done a good day’s work?” 可以拿來自己詢問自己（不論是否 Remote）

另外，怎麼從到辦公室上班轉成 Remote？
他們建議可以從一周 Remote 幾天開始
看看發生了什麼事情？再來決定該怎麼做？
（建議要做 Remote 就真的做看看，一次 3 個月）

37Signals 在芝加哥的辦公室總部，有 13 個人有桌子
大多是情況只有 5,6 個人會出現

讀書前的疑惑

在公司租用正式的辦公室之前（住辦略分階段，一樓是辦公區）
我們就為了互相干擾、工作效率等等事情討論過

有同事說：「辦公室只能確保最低產值」
這句話大致上是對的，但是其實辦公室的作息有時候還不能守住最低產值
因為若精神不濟而寫出有 Bug 的程式，那就有機會變成負產值了 ...

隔一陣子以後，公司還是因為要招募設計師跟其他員工的需求，而租用了商辦
並且規定 10~12, 14~18 為工作時間（大致上是超短的工作時數）
儘管如此，工作了一陣子後我還是感到不對勁
當時我自己簡單筆記了一下家中工作與到辦公室工作的優缺表：

• 家中
  
  • 優點 - 作息自己控制（可以無壓力的睡覺睡到自然醒）、自己切割上班/休息時間、工作效率佳
  • 缺點 - 可能會有家中事物的干擾
• 辦公室
  
  • 優點 - 公私分明、有空調、視線明亮、便於溝通、有在工作的安心感、可訂便當
  • 缺點 - 睡眠品質變差、通勤要騎機車 25 分鐘（近 10 km）、很多干擾、中午飯後小憩的休息品質不佳、不喜歡公廁ooxx ...

不對勁的地方在於效率與工時，最終影響的結果是產量
在辦公室工作的效率評等，我自評大概是上午 C 下午 B，下班前會接近 A，工作時數是 6 hours
反之，以前在家中獨處時的平均效率是 B+，偶爾還能夠到達 S，工作時數 8+ hours
兩者的產值對比起來，相差甚遠

「這其中一定有什麼誤會！」

為了讓自己能夠在辦公室發揮更好的產能
我買了機械式鍵盤（讓打字變成樂趣 XD）
買了 111 人體工學椅（可以久坐不累、飯後還可以後躺 60 度休息，堪用）
無奈的是，產能的提升還是不夠 ...
更甚者，我發現下班之後，疲勞會讓我沒辦法在晚上做（與工作無關）其他需要專注的事情
至多只能讀讀少許較簡單的技術文章而已

大致估算一下，我發現一個事實：
我每天需要花 1 個小時通勤 + 8 個小時出門在外上班
然後可以得到中低效率的 6 hours 工作產值跟疲累的身心
荒謬的地方在於，同樣的事情是可以一個人在家中完成的，且效率更好
因此我一直在想「為什麼」跟「怎麼辦」 ...

讀書後的解答

與其說此書直接解答了我的疑惑
倒不如說隨著書中思考的脈絡，再來更加仔細想想「工作」這一件事情
一切就變得清晰易懂了

工作這一件事情建立在「意願」之上，有「意願」才有可能把事情做好
意即，在遵守最少的限制之下，「想工作才工作」「需要休息就休息」才是發揮效率的王道
限制工作的「時、空」並不是對每個人都適用的（或說對大多數人都不適用）
當時空限制被打破後，除了可以省下 context switch 的成本及消除 side effects 以外
有心要做事情的人自然會最佳化自己的「工作/休閒」演算法，以完成工作

舉例而言，上個月 MOPCON2013 結束後，我非常疲累（因為臨時投稿閃電秀）
隔天週一就在身心還沒回復的情況下上班，低效能地撰寫出程式碼
又心心念念該好好寫篇部落格來消化一下思緒跟補充演講的資料
最後 ... 遭遇許多外務後就很丟臉的就拖到現在還沒動工了 ...
理由是「下班已經累了、懶惰、過了最佳的時間點、有更重要的事情要做」

但是，事情是可以更加簡單而且圓滿的：
隔天上班，開完週會後跟處理必要的事務後，就該結束該天的工作的
剩下的時間應該轉為私人休閒時間拿來寫部落格
畢竟，「人要在最想要做的時候就去做那一件事情，才有可能把事情做好」
欠公司的時數，當天晚上或是分散在其他精神好的時候再補回來就好了

如果依循著這樣的思維仔細觀察
那麼就可以發現有許多公司，致力于企圖營造讓人覺得「很棒」的工作環境
比方說不強制上下班時間、良好的設備、能夠專心工作的小房間、休閒區 ...
這些措施的目的在於把對員工「時、空」的工作制約放寬，以提高生產力

會有 Remote 這樣的工作形態也變得合情合理
因為這樣可以打破大多數（並不是全部喔）的時空制約，以最大化效率
而就執行時數來講，Remote 其實也比較吃香：

• 若一個員工一天到公司待 8 hours，則他的真實工作時間大概只有 6~7 hours
• 但若要求 Remote 的員工做滿 8 hours，這可以說是很紮實的 8 hours

至此為止，若您是老闆，員工要求 Remote 工作，您會怎麼看待？

結論

請您也拿出紙和筆，簡單計算一下自己工作的效率與產值
想想看，有遭遇到哪些問題，有沒有辦法能改善與提升？
若您是老闆，也不妨對工作產值重新深思？坐在一起才是上班嗎？何不雇用遠方的優秀人才？

我相信當 Remote 的概念被您領略，即便不完全實行、甚至不實行它
您一定會發現能讓現況更好的契機

至於這一本 37Signals 創辦人撰寫的 Remote
它不但全局地從各個角度看待 Remote （絕非只有像本文般這麼狹隘的探討它）
也內含許多 37Signals 珍貴的思路與經驗，絕對值得一讀！

（對我而言，最大收獲是：告訴了我該如何工作與「生活」！）

介紹：Multi-Mechanize (Performance Test Framework)

最近恰好需要為正在開發的系統進行壓力測試
還記得上一次做壓力測試已經是一年半多以前了 …
出來打混近兩年的創業經驗告訴我
要遇到 scalability 的問題也不是一件很容易的事情（默）

Multi-Mechanize (簡稱 MM) 是 VU-based 的壓力測試軟體
之所以選擇使用他是因為：

• MM 支援報表輸出
• VU-based (Virtual User)的模式，能夠依照需求一定程度的模擬使用者的行為
• 是 Python Solution，且撰寫時可以直接「參考」之前寫過的 functional testing 程式碼

不多說，不講解，直接附上參考資料：

比較入門的投影片：

Performance and Scalability Testing with Python and Multi-Mechanize from coreygoldberg

進階的投影片，且提到其他壓力測試的東西：

Python Load Testing - Pygotham 2012 from Dan Kuebrich

MM 因為使用 matplotlib (相依 numpy …) 來繪圖
所以安裝時間沒意外應該會比看完他全部的文件還要長 … Orz


MM 使用上的特點有：

• 用 multimech-newproject 建立專案； 用 multimech-run 執行壓力測試
• 執行壓力測試時，如果強行使用 control-c/d 中斷，並不會完全停止測試（因為有使用到 multiprocessing）
• mechanize.Browser 可以協助建立一瀏覽器物件，該物件有對 html form 進行操作的相關方法，亦支援 cookies 操作
• 不使用 mechanize.Browser 也無所謂，urllib2, httplib, httplib2, requests … 皆可使用
• 使用 Transaction 此 class 撰寫測試，如果比較喜歡在一個 transaction 內進行比較多測試，可以參考 Python Web 性能和压力测试 multi-mechanize 一文
• 設定檔內如果設定 threads = 50 ，即表示同時（先不管 python 實作的真實情況 XD）使用 50 個 VUs 來進行壓力測試，每個 VU 的行為都是「發送 -> 等回覆 -> 收到 -> 再發」的 loop 行為
• 測試結果會在 results 資料夾內建立新資料夾，含 csv, 圖檔, html … ，且支援直接將測試結果存到 DB 內(未實驗過)

個人小結論是，MM 沒有特別好用，但是也沒什麼不好的地方！


值得一提的是，其 VU 的概念
讓我這種之前用 ab 的業餘人士，花了一點時間才能夠理解過來

VU 的目的該是模擬同時有多少使用者，以此前提進行測試
而 ab 則單純依據參數產生固定的流量，以對伺服器進行測試

大體上，我認為 ab 是看八卦用的指標，畢竟很少有人上線的服務是回傳 hello world
自己家的機器，還是要真的去跑自己家真實的服務，測起來才會準確點 : )

活動：Tainan.py x MOSUT 2013 9 月聚會

由於學校已開學，擔心聚會的參與人數塞爆 Isrlab

所以這次活動便選在成大資工舉辦（人數約 3x 人）

photo by CCC @ Tainan.py

開場後我丟了一個很小的分享
因為是臨時擠出來的，內容頗不全面 Orz

會後有朋友在聚會的 meetup 頁面 發問相關問題
我有推薦前一陣子在 pythontw (FB) 看到的 ghost.py 與 selenium 供參考

程式碼

這次聚會邀請到了「貴公司」的 Kilik 來一次給兩個小講題
第一個講題使人受益匪淺，第二個講題則是相當有趣

這次聚會看到常在 Taipei.py 分享 Python 原始碼相關演講的果凍出現
感覺是衝著第一個講題過來的（後來發現其實只是週末回家路過）

講題一投影片

講題二投影片

備註：Isrlab 的 kuku 在閃電秀時有對第一個講題做補充，非常值得一看

第二位講者是 Wen，講題「使用Linux/C組裝軟體的心得」看似是入門講題
可是演講的密度高而內容有趣，完全不只是給 Linux 新手看的，推薦一看！

這次活動中場休息時間，我們訂的飲料來自波哥 XD

第三位講者是 Nylon，分享了暑假在 RoBoard Lab 實習的經驗

樂於見到現在的學弟妹能夠利用暑假的時候去做「有意義的事情」並且願意分享出來
而演講中，台下亦有前輩補充資訊

投影片

閃電秀/工商服務時間時的講題如下：


Descent 用很短的時間證明了 git 其實沒有表面上看起來這麼簡單
（其實我也不太會用 git ... Orz）

jserv 介紹了這學期在成大開的課程（熱血啊！）

另外，Kuku 介紹了 Zato 與 pyjs  

對於有寫 Web 的朋友，前者務必一看，非常有幫助（儘管不一定有機會用到 XD） 

最後的最後，以開發 App/Web 為主的敝公司（利昇科技）
有計劃徵 Android 實習生/工讀生
有興趣請內恰： joe@lirise.com



這次的聚會感謝 MOSUT 社群的朋友們幫忙出主意跟向成大資工借教室
錄影機是由「創業抬槓」的朋友帶來，借我們使用
演講過程中，感謝果凍幫忙錄影
最後，感謝老闆幫忙訂飲料（是的，那個幫大家訂飲料的人是我老闆）

活動：Taipei.py 2013 8 月聚會

恰好有機緣前往北部，便在颱風中風雨無阻地來到了 CLBC
CLBC 的演講廳，要拿來舉辦小型聚會已經算是綽綽有餘
不過讓我驚艷的，還是做起來很舒服的「共用工作空間 Coworking Space」的 Herman Miller Aeron 椅子 
（事後跌入椅子坑，可是買不起 Aeron 啊啊～） 



以往我會試著整理講者投影片之類的東西來充實文章
可是 Python Taiwan （多虧 Mynt，強大) 實在太迅速
聚會還沒結束，心得文跟整理就都出來了：

活動記錄（含錄影及投影片）

主要的兩場演講講者是果凍與他學弟
同樣皆讓人覺得受益良多（不過學弟的演講節奏太慢，對於台下的老人，可以用兩倍速沒關係）
我投的閃電秀 其實是工商服務「Taipei.py Logo 的小故事」：

原本想說來 Taipei.py 看看朋友們
哈哈，不過常出現的 Keith, Mosky, c3h3 … 怎麼好像都沒出現
害我不能當面邀稿
不過寫 Flask 的朋友果然也不少，會後也與幾位朋友有機會聊到 Flask 與 startup 的經驗，蠻開心的！

活動：Tainan.py x MOSUT 2013 8 月聚會

這一陣子在趕專案，儘管對於 Flask 的使用及 API Server 的規劃有所收獲
卻苦於撥不出時間整理相關資料跟想法，嘗試分享給朋友們以供改進
更慘的是，聚會文跟筆記都完全拖稿 … Orz

趕緊來補一下!

8月炎炎夏日，聚會時間首次（可能也是近期唯一的一次）選在週六晚上舉辦

並且達成了成就：聚會時間破十一點 + 我要征服臺南牛肉湯 的作者領軍帶大家吃牛肉湯續攤

photo by mosky@府城牛肉湯

這次聚會首先邀請到了來自 Taipei.py 的 Tim 分享「Python 打包注意報」

Tainan.py, Experience about package from Tim Hsu

這個演講相當實用啊！
儘管使用 Python 已經快要滿兩年，我對 distutils, setuptools … 的關係都不太瞭解
聽完演講後，毅然決然以後 pip install 都只在 virtualenv 下使用，確保乾淨


第二場演講的講者是來自 pinkoi 的 Mosky，帶來了「Web App 實戰：Mr.Bus」

此為開場部分的錄影，下週陸續上傳後續片段
（檔案放公司電腦 Orz）

此演講涵蓋 nginx, uwsgi, flask 許多願望一次滿足 XD
其中 Mosky 分享的 nginx config 設定小技巧有趣而實用
不過 flask 聽不夠啦 XD 備註：講者還在改投影片，修正錯誤且做完整後才會釋出


中場休息時間時，我們安排了「吃鹹酥雞配綠豆湯」的活動
這次總算讓大家吃到熱的鹹酥雞了 XD


第三場演講是 Descent 帶來的「linux 下中文終端機徹底研究, 輸入法與秀字」

儘管當年大家在用倚天系統的時候，我大概還在玩彈珠跟搜集旋風卡 XD
但是對於沒用過的人來講，此講題仍非常有趣，大家的氣氛非常熱絡！
強烈推薦觀看錄影！


第四場演講是宗翰帶來的「使用有限時域差分法計算電磁波」Reference

什麼？ python 版本比 c++ 還要快 ！！？？

強烈建議不要只讀 Reference ，一定要看錄影
若對數學沒轍，可從影片 13 分開始觀賞，歡樂到結束 XD

常規演講結束後，BitCoin 中文社群的朋友也投了個 lightning talk

縱觀這幾次 Tainan.py x MOSUT 的聚會
發現南部的朋友投稿都很踴躍，講者演講時的參與度也非常高 而每次聚會都有「驚喜」能讓人意外地學到更多 XDDD


--
下次聚會改善事項：錄影, 拖稿
最懶的方法是不是找一個行車記錄器，掛在大電視對面的牆上就好了 XD

筆記：Python 輸出 .csv .xls .tsv …

近期恰好遇到需要在網站上提供輸出 .csv 檔案的功能
而無奈地，由於內含 utf8 中文字元的關係
使得輸出後的 .csv 檔案，透過 excel 開啟後會出現亂碼（明明 google 表單匯入都正常）

為了解決此問題，於是我曾嘗試使用 python 內建的 csv module, 高階版的 unicodecsv, 手動 補上 BOM 的資訊 … 但是透過 excel 2011 for mac 開啟後，中文仍然都是亂碼 Orz

仔細想想，既然假定使用者會用 excel 開啟檔案
那也不用強求一定要輸出 csv, 直接輸出 醜醜的 excel 檔案即可
於是最後找到了 tablib ，神速的短短幾行程式碼便能完成工作：

# 安裝
sudo pip install tablib

# 使用
headers = (u'中文', u'沒在怕的')
data = [
    ('John', 'Adams'),
    ('George', 'Washington')
]
data = tablib.Dataset(*data, headers=headers)

# 轉換成各種格式的字串
data.csv
data.xls
data.xlsx
data.yaml
data.tsv
data.json
… 

活動：Tainan.py x MOSUT 2013 6月 - 首次聚會

第一次正式聚會，人潮馬上擠爆了聚會場地！
講者恰好位於畫面的兩端遙遙對望，此照片構圖真好啊

身為在 PyConTW2013 閃電秀跟大家說要在南部舉辦 Tainan.py 的 用 Vim 男子漢
會後 因為騎虎難下 馬上就寄信與母系成大資工、jserv 大大大橋場地跟邀約演講，且都得到正面回應
更幸運地，才剛搬回台南就參加到了 MOSUT 在isrlab 場地的聚會，認識許多朋友，且得知該場地有協助社群的打算
在鼓勵之下，我立刻斗膽決定在 6/29 （六）舉辦 Tainan.py x MOSUT 的聚會
且於 6/14 就先安排一場「微聚會」，看看能不能約出在台南對 Python 有興趣的人

Bottle Intro @ Tainan.py 2013.6.14

微聚會時我所分享的投影片（又是 Bottle 的簡介），而且我講的頗爛 XD

結果，一切都很順利！

微聚會時已約莫有十位朋友參加活動
正式聚會時，原本預估約 20 位朋友會過來，最後則出現了 35 位朋友！
意外的是，或許由於場地較小，因此講者與聽眾之間非常的「沒有距離」
有問題、有看法，皆能即時進行討論，且反應熱烈
而原本預估，唯一的一場閃電秀過後應不會有朋友臨時想上台演講，結果卻完全相反 …
後面的臨時投稿才開始了聚會的第二回合演講：Abaqus, Forth, MOSUT, isrlab …
各主題、各組織的介紹接踵而來
最後請大家來個自我介紹以後，活動就已經超過六點了 XD
（活動的演講量大概是平常 Taipei.py 的兩三倍以上吧 XDDDD）

開場與自我介紹 @ Tainan.py - 2013.06.29 

至於 Taipei.py Logo 的小故事，就不附在此 下次去台北再上台說嘴 XD）

由 Tim 所帶來的「手把手教你在一分鐘內做 HTML5 Slide」線上觀看投影片

這次 Tagtoo 的 David 所帶來的 google cloud platform 介紹
（截圖是 google 官方的網頁，點擊「View the presentation」可以下載 David 引用的投影片）

這是 MOSUT 朋友 descent 所帶來的 x86 演講！ (好硬啊 XD)

觀看影片時請參考他的 部落格文章

這是 Clifford Yen 所帶來的「Python 在有限元素軟體 Abaqus 的應用」

（臨時出現的隱藏講者！反應非常熱烈！）

強者我學弟小畢 CrBoy 現場寫 投的閃電秀，介紹 MOSUT 

以上還只是聚會的部分內容，有一些演講因為沒有錄到、尚未蒐集到影片或講者未授權等等因素，而尚未出現在上述的介紹中。總之， 既有的錄影 已經放到 youtube 之上，而 Tainan.py 的 meetup 社團 內亦有聚會的補充資訊可供參考！之後若有取得其他的錄影檔案、講者投影片，亦會陸陸續續更新上去！ 

本次的聚會能夠成功舉辦，得感謝：

• MOSUT 社群朋友的幫忙跟 isrlab 對場地、餐點的協助（鹹酥雞 + 杏仁豆腐，好棒啊）
• 北部 python 社群朋友們的火力支援（從 Logo 、講者到聽眾真的是出人又出力！）
• 所有願意過來參與活動的朋友們（尤其是看到許多正在唸書的學弟妹們過來參與活動，非常感動）

有了這次的經驗，我相信下次的聚會會辦得更好！

備註：
搬到台南兩個月後，強烈感受到台南的活力！
無論是「創業抬槓」的活動、「MOSUT 社群聚會」、台南「HPX 讀書會」、
近期剛開始以學生族群為主「Wheel Lab」的 Web, App, 創業相關聚會、
再加上 Rails 社群與 Python 社群的聚會、
還有，八月份 Forth 社群的前輩們亦有與 MOSUT 合辦的聚會、
還有，難以計數的讀書分享會 …
對了，還有堅持在濁水溪以南舉辦的 MOPCON …
(講的好累 … )
這些活動的熱絡，皆再再的證明技術性社群活動在台南已經逐漸發酵 :)
我想，您若是喜歡南部的生活 美食 ，已經可以準備搬過來了 XD

活動：AppWorks Demo Day #6

活動正式開始前，會場放著五月天熱血的音樂，各組要上台的人正努力地準備等一下的演出

仔細算一算，這已經是我第四次參加 Demo Day 了！
這次參加的心境，又有別於前三次
這一次，我所在的公司已經從台北搬遷回台南，而且經歷了半年的多元嘗試
我也鎖定音響、耳機領域，做了些嘗試性質的服務（目前在協辦八月初某一場耳機迷的 聚會）
對於創業無成這一件事情，自認有更深的領會


因此，心態上可以說是老了很多
但，想不到 … 這次上台的團隊大都比我（們）還要老很多 XDDD


對於 Demo Day 的看法，去年 我所寫的文章 已經大致描寫過，亦沒有太大的改變
對於新創的團隊，我永遠都是抱持著多些善意批評、多些鼓勵的態度
畢竟，用說的容易做事難，倘若這個世界沒有人願意嘗試做些新東西
那麼整個環境是無法越變越好的


我之所以說這次的團隊老，其實不只年紀，還包括事業成熟度、產業類型 …
看來，近期 Jamie 招生時的老鳥策略有所奏效
但，卻也可能帶來了一些問題：
（以下為個人的不負責任推理與猜測）

• 真的過得不錯的老鳥是不會進 Appworks 的
• 進來的老鳥，礙於既有的生存模式，參與度與可培育性未必會高
• 老鳥與老鳥間的協力合作、媒合是相對較為困難的，除了心態以外，產業相異就是一個不小的鴻溝
• 老鳥與菜鳥間的互相激勵、帶動，未必能有預計中強大的效果（做的東西很可能差異太大）
• 最後，菜鳥與菜鳥間的互相激勵、幫助，很可能因為團體太小，而無法有 1+1>2 的效果

舉例而言，這次的團隊組成亮點大概是有軟硬整合的團隊，但我卻難以想像這些團隊要怎麼與其他做社群、做旅遊、電子商務 … 的團隊進行溝通或是合作
當然，每個團隊做的東西有所差異，互相交流時是能夠開拓視野的
但是，我似乎更樂見是由 20 個剛出社會的菜鳥團隊全部做 web 與 app 的服務。很有可能很多東西會很蝦而死掉，但是我相信團隊間的隔閡會更小、交流更多、培訓期間的成長更大


這次另一個比較明顯的問題是，有些團隊太不「網路」了 ... 對此我就不再贅述 ：）
我猜測對於 #7 的團隊篩選，Jamie 應該會調整比例


而這次的 Demo Day，整體的 presentation 皆較往年為佳
缺點為，我個人不喜歡所有人都套上樣板用「廣告式」的方式來推銷自己
應該還有更多的可能性才是 （這次的團隊呼叫政府當然是走向另外一個路線了 XD）


最後，附上這次「玄米設計」推出的 Picaca App 的 官方網頁連結，我個人認為此產品在這次 Demo Day 中表現非常突出！

備註：
好吧，我先承認，其實敝公司 利昇科技 與「玄米設計」是有合作關係的
之前也曾一起推出一款文青拍照標價 App - PicValue
歡迎大家一起 下載 試用！

活動：PyConTW 2013

這張海報是我跟一個學妹（偷懶時）貼的，噢耶！

今年的 PyCon 心得很不一樣 =v=:

• 心得文拖搞兩個月 …
• 此次由原本純參加者的身分轉變為志工與小小（閃電秀）講者
• 這次議程沒有現場聽到很多場，所以沒有辦法像去年的文章來拜所有的大神們 Orz
• 取而代之，今年參與到了 PyCon 的籌備，能夠用另外一種角度來看看 PyCon
• 過了兩個月，很多當時的小細節老早都忘了，但或許現在想得起來的部分是比較重要的也說不定（我當然要這樣講）

與其說今年我「參加」了 PyCon，倒不如說，我一起參加了「做」 PyCon 的（部分）過程
而在過程中，我看見了一群 Pythonista 用 Python 的思維做事情的方式：

• 籌備團隊之間的 namespace 分組明確，且大家總能將自己的事情做好
• 籌備時重要的 rules 皆明確地被寫在 handbook 內，遇到爭議時主席會跳出來重申重要的主張
• 即便團隊已有自己的文化與規則，但是遭遇突發的狀況時，仍能夠調整規則並且應變
• 或許同樣身為工程相關人員，同樣熱愛 Python，當遭遇問題時，大家永遠都在尋找在特定情況下的「one obvious way」去解決問題

這次 PyCon 有不少新的嘗試，像是採用三軌制，滿足各領域朋友們的願望；提供早餐餐盒，超級貼心的服務；提供財務協助方案，讓財務較為困難的朋友仍然能夠參與活動；晚宴規劃了表演與夜市，氣氛一級棒！

因為擔任志工，我也參與了
看都看不完的mailing list 籌備信件轟炸、場地佈置、發便當、會後聚餐 … 雖然當天聽到的 talk 少了一點，但是所認識的朋友與講者帶來的收穫是遠遠值回票價的！

擺攤時，各攤位都畫上了有趣的圖案 XD

自行吐槽 XD

這太強大了吧！

台北的 Python 社群 害我跳進 Python 坑的人都在裡面

事實上，我今年生日的時候，某 Taipei.py 使用 Pyra*** 框架的朋友有寄信向我邀搞：

Hi Joe,

你知道的，工作別太累，要留點時間投稿啊 XD

http://tw.pycon.org/2013/zh/blog/2012/11/21/call-for-proposals-zh/

生日快樂在哪裡 XD
還記得去年的心得文我曾寫到「希望某年我能夠熟 python 熟到能上台向大家介紹牠 ... Orz」
結果今年我雖然還是不太會寫 Python ，但是還是丟了個閃電秀上台 …

這是我第一次上台講閃電秀，非常緊張！
事前我大約又花了十來個小時準備投影片跟演講內容
花費的時間真的遠超過預估（我之前已經在 Taipei 介紹過 Bottle 了！）
講題跟內容我刻意一直用前陣子很紅的形容詞「微」當作梗，效果看起來不錯 XD
因為本人沒什麼技術能夠分享出來，所以也就只能簡單跟各位介紹自己使用 Bottle 的經驗
順便搞笑一下
檢討一下自己：

• 原本是以 ipad 做簡報工具，不過轉接線與現場設備不合，會閃爍！好在後來有向 ccc 借到筆電 XD
• 演講前缺乏預演，主要都是前一天睡覺前自己在心中默默演練演講情況
• 因為使用的設備不是自己的，緊張，所以加快了演講速度，結果演講時間比預計短了要整整一分鐘 XD
• 上台後完全就偏一側的麥克風講話，前一兩分鐘非常沒有安全感，整個人都龜起來
• 講話吃了一些螺絲

意外在會場發現了一張必須倒著看的神秘貼紙 XD

最後的心得嗎？
這是我這半年多以來參與北部 Python 社群聚會後，所投入的一個大型活動
在此，除了認識許多熱愛 python 的熱血朋友們以外
我也發現有投搞演講就是有差，自己除了在準備時能夠整理思緒以外，現場演講亦是經驗的累積，而演講後也會有不少朋友們願意主動過來給我意見
（竟然有人說我可以出道了 XD）



付出，而後，得到更多更多。
怎麼看都划算！

夜市結束後，我與帽子的文青圖

週日與籌備的朋友、講者們聚餐後就回家（台南）去啦！

備註：
不嘴砲，Tainan.py 真的成立並且已經舉辦過聚會了！
點此 加入社群可以得知 Tainan.py 的最新消息！

活動：Taipei.py 2013 4 月聚會

這次的聚會下著大雨，即便如此大家還是風雨無阻地來前來參與！

這次的流水帳系列心得文，來的比較慢一點   =口=
因為恰逢公司搬家 與工作上的撞牆期 ... Orz

對於 The Manx 這幾個月以來的協助再次表達感謝！

＃本次聚會照片、投影片皆可至 Taipei.py 的 Meetup 社群 下載

---

Talk 1: Recoverable PDB

講者為在  The Manx 工作的果凍，是從高中就開始使用 Python 的大大
此議題超級有趣！竟然有人在翻 pdb 的 source code ，而且還講解給大家聽，這實在太棒了！
身為一個也是習慣使用 pdb 方式來除錯的人，此演講內容相當具有參考性

這次演講最可惜的地方是由於設備頻頻出問題，使得過程經常被中斷
可能會使聽眾較難集中注意力 ... Orz

補充：其實我平常 debug 用的 tool 是 pdb++
他除了相容於 pdb 以外，還支援語法上色、自動補全、以及一些額外的功能
相當推薦一試！ （額外一提，我使用 bottle 是從不開 debug mode 的！） 

Talk 2: NLTK

講者為  Rueshyna ，帥氣的正妹講者一名

此議題我個人很感興趣，因為目前執行的專案接下來極有可能要去做 text mining
於是就當作吃大補丸般的認真聽講了（握拳）

此演講是有 錄影 的，有興趣者可以參考之。

演講時 demo 的 data source 是來自 stackoverflow 的標題
所以講者也得出了一些有趣的結論 XDDDDD
（有興趣的朋友請參考影片吧！我不能亂爆雷啊 ！）

閃電秀

分別由 Kilik 與 Keith 帶來 RunSnakeRun 及 Ipython Notebook 的介紹
前者可以圖形化 profile 後的結果，讓人一目了然的了解程式慢在哪裡
後者則為一便捷的 web 介面，可用來分享程式碼，及讓人 Try 程式碼！


這次聚會最後的重點，就是與一群志同道合的朋友一同討論 PyLadies 的未來（這好像不是我們這群 Py豬哥該討論的事情？？）

本次聚會除了認領到一個在趨勢當研替的強者我學弟以外，也初次遇到 PyConTW 註冊組的老大 jack ，趕緊向他拜碼頭一下！聚會時，每次遇到從新竹遠道而來的 CCC （這次還有另一位朋友），就覺得非常的熱血 。抱持著這個想法的同時，我所在的公司已於近日從台北搬遷到台南了，所以之後 Taipei.py 的聚會我可能會較少出現吧！但我也希望改天如果出現的時候，能讓人也會對 Python 的社群有熱血感 XD ... 無論如何，秉持著取之於社群回饋於社群的想法，之後我就在台南嘗試組織類似的聚會吧！（就叫做 Tainan.py 吧！）

活動：Taipei.py 2013 3 月聚會

聚會結束後，走在路上，看到一台機車的安全帽長這樣 ！！（Keith 的）

這次由 Tim 發起了「入場先收 50 塊，稍稍補貼一下茶水費」的活動
對於 The Manx 同時提供「人力、場地、器材、餐點」，只能說感謝了 Orz …

＃本次聚會照片、投影片皆可至 Taipei.py 的 Meetup 社群 下載

---

Talk 1: Scrapy - 網路爬蟲框架

講者為在 Tagtoo 工作的 Theon 學長
演講專業而結合範例，讓人能清晰的了解到 Scrapy 此框架的威力
如果熟 XPath 的話，大概真的參數填一填，實作上不用五分鐘就可以寫出爬蟲了！
由於我前陣子有寫過爬 Ptt 的機器人，去擷取備份文章
對比於自己寫的 糟糕 程式，我馬上就能感受到了此一框架的優良架構
雖然我為 XPath 苦手，不過我想現在的瀏覽器都有相關的工具可供協助找到 XPath
之後若有機會，值得一試

另外，對於小型的抓網頁，讀取特定數值的程式
如丟關鍵字給 google，然後抓出搜尋結果的連結 … 這樣的應用
我蠻推薦使用 pyquery 來處理問題
直接使用：d = pq(url='http://google.com/')
接下來就可以使用類似 jquery 的方式存取 html 元素了：d("#hello") …

Talk 2: 先不談 Django，你聽過 Bottle 嗎？

講者 竟然 是我 XD ... 因為沒有辦法自己幫自己的演講給心得文
那我來檢討一下演講準備過程，與附上補充資料
因為近日專案極忙，這次的演講，我一直拖到演講前兩小時才把投影片做完
對我而言有許多第一次：

• 第一次用 iPad 的 Keynote 做投影片
• 第一次用 iPad + 轉接線 投影到螢幕
• 碩論口試後第一次公開演講（當兵的時候倒是主持過很多次莒光園地 … ）
• 第一次在社群中分享自己的經驗

我原本自以為可以用閃電秀的密度，快速的用 15 分鐘把該講的都講清楚
但是做出來投影片的品質太差，又沒有演練過 ... 所以就變成了冗長的碎碎念亂講 … 囧rz
對於這一點，我正在深刻的反省中 …

另外，使用 iPad 製作起來的過程雖然算流暢
但是在投影片內要插入超連結，頗有困難，且輸出成 ppt 或 pdf 以後，格式都容易跑掉
之後得多加注意此問題

這次來不及測試 remote 遙控投影片的功能，小可惜
不然就可以帥氣的走來走去了 …

---

會後補充：

再度推薦一下 gevent 社群的文件：Gevent Tutorial
值得一讀，讀了以後就會發現，在一般的 Python web framework 中
比較難以實作的 Comet 之類的功能，都能透過 gevent 輕易地達成

我記得 Appier 的朋友有問我 Bottle + gevent 能不能夠做效能調教？
（話說，您已經是此搭配的成功案例了：5000 qps …跪求 Bottle 進階演講）
雖然我不知道怎麼做，但我之前查資料時
有看到過 Douban 釋出與 Python 相關的投影片，或許仍可供參考（2011年的）：

Python高级编程（二） from Qiangning Hong

補充一下，對於 bottle 要提供 http auth basic 的話，可以這樣做：

def check_user(usr, pwd):
    acc_pw = { "user1" : "pw1", "user2" : "pw2" }
    return True if usr in acc_pw and pwd == acc_pw[usr] else False

@bottle.get('/admin/')
@bottle.auth_basic(check_user)
def test():
    pass

當然， auth_basic 的參數要直接塞 lambda 也是 OK 的
但是不建議用這個當會員系統啊 XDDDD

最後，至於為什麼我講的是 Bottle、用的是 Pyramid、大多數情況推薦的卻是 Flask 

這個傷心的問題就不要再問我了 囧rz  

PS. 這次演講後與許多朋友交換名片，聊： Web 框架、Testing、用數學變魔術的經驗 … 真的有 Level Up 的感覺！
您若也想來個常規或是閃電秀的演講，可以先加入 Taipei.py 的社群，然後直接找 Tim, Keith （或我）報名！

活動：Taipei.py 2013 2月聚會

這次的場地是由 The Manx Entertainment Group - Taiwan 提供
場地實在是非常的夢幻，以後若能都在這邊舉辦，那就太好了 XDD

The Manx 對我來講是一間神秘的公司，網頁上所寫的關鍵字：
Online-Game, Python, Django, HTML5 都好吸引人啊！

這次第一場 talk 的講者為 Sean 大大
講的主題是：「如何運用 MyHDL來幫助硬體設計者達到快速的驗證和重整」
Ha Ha Ha …
(詭異的笑容，因為聽不太懂 XDDD)
因為是新場地第一場 Talk，所以設備有點沒 Ready，打亂了幾次演講的節奏
由於聽不太懂，所以只好繼續發揮寫這篇文章的目的，整理演講的資料出來：

• Sean 寫的部落格文章：learning plus: example MyHDL
• Sean 在 github 開的 project：funningboy/example_MyHDL · GitHub

第二場是 Tagtoo 的 陳建勳學長(appWorks) 分享使用 GAE 的心得
難得遇到從一開始就使用 GAE 並且到現在的前輩 XD
因為沒有搜尋到投影片，所以附上一個疑似是學長所寫的部落格：
任務日誌 （內容好多 GAE 與 Python，真棒！）


第三場的 lightening talk 是由 c3h3 大大主講
主題是：不用寫程式也可以玩 Machine Learning --- orange 簡介
講者就直接一邊演講一邊 live demo 了，強大！
之前我有想要稍稍 survey 一下 data mining 等等之類的東西
有也看到 orange 卻不知如何入門
這次有機會直接看到專家「玩」給大家看，實在受益良多！ Cool！


會後與大家聊了一陣子，遞送上我目前負責專案的名片，
(只有)名片本身大受好評 XDDD
值得一提的是，我總算遞上了我的名片給 mosky，感謝她為我的部落格帶來流量

本部落格透過 google 關鍵字進入，排名第一的組合是： python mosky 與 mosky python
是的，並不是 Taipei.py ，我也不知道為什麼 … 囧rz
事後，得知隔天閃光參加 pinkoi 的設計師聚會也遇到 mosky，真是太巧了！

總之，這次新年後、新場地、新報名系統 的 Taipei.py 非常的成功！

筆記：Python 使用 Boto 將照片上傳至 S3 （加上存取限制）

Basic

前一陣子在實作一個供使用者上傳照片的功能
想當然爾，現在應該比較不流行自己 Host 這些照片
於是我使用了 Amazon S3 的服務來解決這個問題

1. 想單純玩看看 S3， Amazon 本身的 AWS Management Console 就很好用了，支援上傳、下載、設定權限 …
2. 想在 Command Line 的環境下玩 S3，s3cmd 是一個方便的工具，推薦一玩 …
3. 至於我的需求，是使用 Python 自動化地完成上傳照片的工作，因此 boto 成為了我的首選，使用方式就請直接參考文件吧： An Introduction to boto’s S3 interface

若是要用 2. 3. 的方式，記得產生 AWS access key and AWS secret key 即可
以上講的內容都沒什麼特別的(若無其事的吐槽自己？)

Public vs. Private

Boto 提供了一些包好的 function， 能使用 Access Control List (ACL) 的存取機制來管理 S3 上的檔案
有需要使用的朋友可以自行參閱 Boto 的 文件

補充說明一下，AWS Management Console 介面所提供便捷的檔案「權限設定」
其實背後也是用 ACL 的機制來管理檔案

對我而言，我想要實作的功能是：「將照片傳到 S3 後，設為公開，不接受外連」
因此，我先透過 AWS Management Console 將整個 bucket 設為公開：

-> 點選 Properties -> 選擇要公開的 bucket -> 按下 Add more permissions 
-> 新增 Everyone 使用者 -> 勾選 List (Read) 的權限

接著，接著繼續操作：

＃使用 Amazon S3 Bucket Policy 的存取機制來設定外連的限制
-> 點選 Edit bucket policy -> 填入以下範例（需修改）
{
  "Version":"2008-10-17",
  "Id":"http referer policy example",
  "Statement":[
    {
      "Sid":"Allow get requests referred by www.mysite.com and mysite.com",
      "Effect":"Allow",
      "Principal":"*",
      "Action":"s3:GetObject",
      "Resource":"arn:aws:s3:::example-bucket/*",
      "Condition":{
        "StringLike":{
          "aws:Referer":[
            "http://www.mysite.com/*",
            "http://mysite.com/*"
          ]
        }
      }
    }
  ]
}

範例來自 官方菜單

如此一來，簡單的上傳與基本版防外連功能就完成了！

補充：記得上傳時幫照片設一下 meta data，諸如 cache-control 之類的屬性，以節省開銷 XD

活動：Taipei.py 2013 1 月聚會

這次的場地仍然是在 果子咖啡
就聽演講而言，本月應該算是非常讓人滿足的
表面上是 one talk + one lightening talk
事實上是 one talk + three lightening talk XDDD



第一場 talk 的講者為 Cyberlink 的 Kilik Kuo 大大
講的主題是 Python 的 MRO (Method Resolution Order)
這主題挺有趣的，也需要動點腦想想
（沒意外的話，我想我應該不會碰到這個問題 XDD）
Kilik Kuo 大大的比喻很有趣，「貴公司」的梗也讓人莞爾 XD
我尚未找到投影片（放在 google document ?），不過有找到了 Kilik Kuo 大大的 slideshare 可供追蹤（？）

2013.07.30 Updated: 投影片連結 在這 ！感謝本人留言 Orz

接下來的 lightening talk 是由 WhosCall 團隊提供
他們實在是很有活力的團隊，「走著瞧股份有限公司」也令人印象深刻 XDDD
演講內容主要是分享：從純 client side、建構 server side、 GAE 移至 AWS、改以 python 開發、使用 mongodb 的經驗



這次的自我介紹，有使用 slide 引導大家回答些問題，效果很好
參與者都因此談蠻多的（有人喜歡也有人不喜歡縮排 XDDDD）

意外的是，我竟然遇到了另外兩位也是使用 Bottle 的朋友 ＝口＝
這實在太高興了啊啊 XDDDDD
雖然我只有用 bottle 寫過幾個小玩具
但是還是與兩位朋友相談甚歡 : )



這次的 Taipei.py 大成功！
(下次要換地方！請加入 Taipei.py 的 Meetup 進行報名吧！)

活動：WebConf 2013

這是兩天以來，我唯一拍攝的一張相片!

我恰巧坐在第一排，看到這張具有張力的圖後

身為銀魂愛好者，只能夠乖乖拿出相機了 …

(所以說，我雖然年紀也不小了，但是還是跟大學生頻率很搭的 …)

感謝

這次的 WebConf 對我個人來講，算是 plurk 大大大聚會
難得有此機會一睹大大們的風采！
對於所有舉辦者、講者、參與者的付出，我在此表達謝意 Orz

觀察與建議

一進到會場，報到的流程堪稱順暢
袋子內的紀念品小冊子，實用而好看
蜘蛛與各種動物的 logo 設計給人覺得有活力、有趣而印象深刻
號碼牌上的豬與胡蘿蔔，貼心而能促進效率
我想，這次的活動商業上的贊助商不算多，可能也因此票價不低
不過會議該有的規模，跟體驗算是有辦出來了！
整體演講內容的話，我覺得仍有點小可惜
Web 的主題太發散了，必然難以真正深入特定主題之中
但也因主題 跟正妹 很廣，所以可以擴展宅宅工程師的視野 >///<

我的小建議是，或許下次可以嘗試更加發揮 WebConf 的優勢
讓 正妹 設計師與宅宅程式人能夠有互動的機會
無論是透過聯合的講座或是安排更多能夠串接兩者的議題
而對於「專案開發方法」、「Web 新創公司發展」方面的議題，我個人還想要聽到更多 XD
（己機嘴乎溜溜～對不起，我一直在許願 Orz）

沒重點的簡短心得

原本鎖定要多聽有關設計的場次
想要了解設計師在想什麼
結果第一場去聽 wordpress 發現只能用站的
而且聽完之後，我還是不懂設計師在想什麼 Orz … (hire me 還蠻酷的 XD)
看來我抱著莫名其妙的目的去聽演講，心態果然是有問題 … (去念心理學比較快啦 XD)
我下定決心：「我不要站兩天，我要舒適的坐兩天！」 =口=  (明明就是懶惰 XD)


之後的所有場次我就都待在大廳了 … 以下為大廳的超快速心得：
（建議創業者聽聽看的場次，我使用藍色的字標示出來！）

• 熱心大大們所整理的懶人包 在此
• Making it big in web. (開發 web 的遠大前程)
  • 睿智而有演講經驗的講者，值得學習！（輕鬆，節奏慢而內容發人省思，讓人意猶未盡）
• 面向網站經營者及網站用戶的個資法衝擊
  • Useful！第一次聽到雙人演講，兩個講者說話快而條理分明！（個資法入門，創業者強烈推薦！）
• 無廢話 DRBD + Heartbeat 實戰
  • 真的無廢話，如教科書般精準的向大家介紹知識，我喜歡！（沒聽過此主題的可聽聽看，聽過喜歡再去買書！）
• 你們都誤解了，網路是很安全的！
  • 很好的資安入門，演講的水準高！（就算對資安已有點 sense，此演講也值得一聽，檢查是否漏掉一些觀念）
• 借力使力的乾坤挪移大法 - 以使用者為中心的設計決策奧妙
  • Nice Talk ! 這就是我想聽到的演講，我想聽更多啊啊啊！（推薦一聽）
• 網站分析？我小的時候覺得自己會
  
  • 很「真誠」的經驗分享！ （算是使用 GA 的經驗談跟醒悟！）
• 網站效能調整－網站系統篇
  
  • 講者很全面性地講解了超多東西（使用 php, mysql 者皆建議一聽）
• 錯失過的機會
  • 精彩而具有參考性（沒有推不推薦的問題，是必聽啊！）
• A brief introduction to SPDY - 邁向 HTTP/2.0
  • 這 … 這是網路科班出身的吧！？神人 ihower 講解得非常的好啊！ （略懂 http 者必聽）
• 建置 PHP 應用程式的秘密配方
  • 雖然沒在寫 php 還是被這樣的火力展示嚇到了 Orz （web programer 必聽）
• 敏捷 Web 開發之 Python 工具菜單
  • 文雅的介紹 python，但是廣告打得略大 XD （推薦對 python 有興趣者可聽聽看）
• TypeScript 開發實戰：開發即時互動的 HTML5 WebSocket 聊天室應用程式
  • 務實而有用的演講（使用微軟解決方案者或需要開發大型 javascript 專案者推薦一聽！）
• 打造愛料理開發及營運團隊
  • 誠懇、條理清晰、台風穩健，同樣身為創業者，我只能說佩服（有在 run 專案者都必聽）
• 火狐又老又舊又不夠潮，誰還在用啊
  • 滿滿的熱誠讓人認識火狐（有興趣者可聽聽看）
• (Hacker's) Best Practice - The Upload
  • 有在看銀魂的 大學生，我非常看好這顆橘子的發展，口條跟演講技巧及內容，以後一定會更好！（如題，有實作上傳功能者，可以聽聽看，藉此檢查一下自己的網站）

微議程的話，我個人最喜歡的是：

• thegiive - 關於 Release 的二三事
• Gias Kay Lee - FSM FTW！
• danix - 國內雲端主機 VPS 經驗談

其實 Alansun - You are here 很 cool，可是機器有問題沒有 demo 出來！Orz



以上，以第一次辦來講，這樣的規模超強大的了，祝 WebConf 明年更好！

心得：檢索 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 看看

投影片在此：

Celery in the Django from Walter Liu

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

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

這次的聚會收穫：我又認識了兩位朋友（真是不錯啊～某替代役教官＋長得很像我大學某學長的 openstack 大大）

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