2014年7月31日星期四

筆記:小型 Web Crawler/Automator 個人工具箱

許多 (browser) automation 的工具都用「鬼」命名 XDDDD
phantomjs, slimerjs, casperjs, ghost.py ...
圖片來自:手滑背單字 的懶惰鬼


#以下為我撰寫小型 web crawler / automator 時常使用的工具與思路


觀察 & 分析

釐清要什麼以後,宜先人工操作網頁,並透過以下方式進行初步觀察:
  • chrome 開發人員工具 => network => 勾選 preserve log => 進行操作
    • 觀察 http 封包的發送
  • chrome 開發人員工具 => 點選左上角搜尋圖示 => 直接點擊欲觀察的網頁元素
    • 在該網頁元素的程式碼部分,可以使用右鍵直接取得 xpath / csspath 的資訊
  • 使用 visual event 觀察頁面上 javascript event 與 UI 的 binding 情況


個人工具箱

我慣用的工具有:(程式執行成本由低到高)
  • requests 函式庫,從 http 的層級解決問題
    • 執行效率最佳
    • 雖然位於底層,但最後不一定會是最繁雜的 solution
      • 可無視許多 application UI 的操作邏輯
    • 若上層的 application 過於複雜,會難以找出合法 http request 的格式
      • 要處理的參數過多會導致需要花費很多時間測試
      • 參數值越依賴 application  的運算,越難生成
      • 隨著頁面跳轉、ajax 呼叫 ... 複雜度會上升
      • 需要自行維持  headers / cookies 的值 ... 手動模仿部分瀏覽器行為
  • mechanize / twill / mechanicalSoup 之類的函式庫,用精簡版的瀏覽器解決問題
    • 執行效率次佳
    • 部分瀏覽器的功能已經被實作,能帶來很大的方便
      • 但是不能執行 javascript ,使得適用範圍小很多
    • 函式庫會附帶一些便捷的 API ,協助填寫表單、點擊連結 ...
    • 適合拿來跑簡單的 functional testing
      • 至少可以不用擔心如何維持瀏覽器的狀態
      • 拿來測 API 也並無不可
  • 使用 phantomjs 等等內嵌 webkit 的工具,透過無視窗介面的瀏覽器解決問題
    • 執行效率欠佳
    • 能執行 javascript ,可高度模擬使用真實瀏覽器的情境
    • 有廣大的社群以此為基礎,開發相關的 testing / automation ... tools
      • casperjs 是高階,極為好用的封裝
        • resurrectio 提供了 chrome plugin,可以人工錄製欲自動化的步驟以後,自動生成以 casperjs 寫的測試程式碼
          • 還在開發初期,頗有機會測試程式碼會出錯,需要人工修改
      • ghost.py 是 python 版本仿 casperjs 的函式庫
        • 依賴 pySlide or pyQT ... 安裝得花功夫
        • 能夠使用的 API 仍比 casperjs 少很多,文件亦不足
        • 優點為:使用 python 寫出的程式碼架構,可讀性比 js 版本高非常多
  • 使用 selenium 驅動瀏覽器,直接人工錄製欲自動化的步驟或進而匯出程式碼
    • 執行效率欠佳,且大都需要視窗環境
      • 驅動真實瀏覽器時,會顯示出視窗,好處是較容易除錯
      • 亦可驅動以 phantomjs 為核心的 ghostdriver,不需顯示出視窗
    • Selenium 的 Python 及各語言 binding,能夠讓開發者在習慣的環境下開發程式
    • 直接使用錄製功能時,記錄下來的動作不一定具備正確重現性
      • 亦即播放時仍可能出錯


使用策略、心得

對於簡單的網頁,特別是無須登入那種,requests 可以說是最佳解
甚至直接使用 pyquery 就能快速完成 crawling + parsing 的工作

但是對於較複雜的網頁,常常會陷入 requests vs. casperjs 的抉擇
當評估用 requests 實作要太多時間,而能接受較慢的執行速度時
casperjs 算是一個比較快速的解法

換言之,以下可能是不錯的使用策略:
  • 需要執行頻率高的 crawling 時,推薦用 requests 
  • 需要執行頻率低或有複雜 application 操作的 automation 時,推薦用 casperjs


實務上,要使用 requests 自幹時
千萬記得到 google / github 找找看有沒有人有做過同樣的事情
即便語言不同,只要能夠看懂 http 相關的操作
也很容易可以寫出自己的版本


反之,即便要走 casperjs 路線
也並不代表會一路順遂,因為仍然有一定的學習成本
  • 高階的 resurrectio 能夠自動產生 casperjs  的  code ,但是不一定 work
  • casperjs 有乍看醜醜,但是其實蠻完善的文件(建議讀完他)
  • 分享幾個使用上的經驗:
    • 網頁會有 popup 視窗的行為,要特別注意
    • 使用 evaluate API 之前,盡可能看看其他 API 是否有提供包好的功能
    • 可以關掉讀取圖片的功能,大幅加速程式速度
    • 我個人會透過擷取圖片功能,事後看各個步驟的執行結果

原本我以為若使用casperjs ,就可以在幾個小時之內馬上完成工作
結果一邊撞 javascript / casperjs 的牆,一邊讀文件後
最後還是花費了超過一天才完成工作 ...
當然,熟悉這個工具以後,會認為付出是划算的


歡迎補完

本文沒有探討 parsing 或是  crawling 的深入議題,僅只是介紹寫寫小 scripts 時的工具
若有朋友知道有什麼好物,請推薦給我啊啊啊!





2014年7月26日星期六

活動:Tainan.py x MOSUT 2014 7 月聚會



Tainan.py x MOSUT 2014 7 月聚會 - kuku

Tainan.py x MOSUT 2014 7 月聚會 - jserv



因為走錯路而遲到,在緊張的心情下(人好多)
我拿出輸出 VGA 有點接觸不良的 ipad 開始了這次的聚會 ... Orz


開場:新 Logo + 把玩 supervisord + Python 報報

(此次開場試用  evernote 簡報功能,開場簡報下載

活動開始後我先投稿做好許久,但是忘了拿出來的 MOSUT Logo ...
原圖下載svg)designed by nao


接著怕整場活動 Python 太少
所以快速介紹一下一個用 python 寫的好用程序管理工具:supervisord
接下來我進行簡短的 Python 工商服務後,就是講者的分享時間了!



跟大師學習:講講瀏覽器渲染 - 當內容遇上裝置



等等,第一位上場的講者難道不是 kuku 嗎?
怎麼投影片是第二位講者 jim Huang (jserv) 的?


是的,這就是 kuku 的「跟大師學習」系列演講,詳情請見下圖:

圖片來自 仁傑

以下為 Isrlab 對當天分享的補充:
昨天 Tainan.py X MOSUT,我們分享了最近研究的課題,主標題是 "向大師學習 - 講講瀏覽器渲染",副標題是 "當數位內容遇上裝置"。
這是一個有趣的年代,數位內容的生產者必須多方考慮眾多裝置差異及各家瀏覽器的渲染能力,我們正在嘗試幫數位內容的開發工具,加一些獨家功能,像是 Flash 編譯器的修改;也考慮深度挖掘瀏覽器的優化可能性,像是 Firefox Gecko 層的擴展。
分享給前端工程師,瀏覽器工程師,系統工程師。

kuku 使用的第二份投影片:Rendering Performance Case Studies (強力推薦一看)



一定會扯到 Python 的「情感運算學習網」上線

第二位講者小均這次為我們介紹 情感運算學習網
並且 demo 一個 辨識情感的小程式 (by python)
( jserv 已玩過改過,且說明其辨識能力不佳)


身為「我要征服台南牛肉湯」的作者,小均「順便」分享一下最近做的研究:

點此觀看研究報告
偷渡一下牛肉湯回報:
民生路那間無名牛肉湯,老闆每天都是自己到善化屠宰場選肉再拿回店面 ... 推!


Build A Lightweight Hypervisor for Realtime Linux

伴隨著隔壁在換招牌的陣陣轟聲
jserv 帥(爆)氣登場,為我們介紹 realtime linux:




工商服務


PyConAPAC 後,各地 Python 社群蓬勃揪團,依開台順序排序:


More info: 


Python 台灣使用者群組 


Or


Python Taiwan @ Facebook 
https://www.facebook.com/groups/pythontw/




筆記:把玩 supervisord


本文是從 evernote 筆記中轉存出來的文章,分享於 Tainan.py x MOSUT 2014.07 




# 看完了 wen 分享的文章以後 …




# 也來試看看用 python 寫的 [老字號] supervisor 吧 (推薦用來管理自己的 process)






# 安裝(盡量在 virtualenv 之外裝) 
pip install supervisor --pre


# 建立 config sample file

echo_supervisord_conf  >  /etc/supervisord.conf


# 修改 config file

[program:foo]
command=/bin/cat


# 建議啟動時讀取自己的 config file

supervisord -c supervisord.conf


# 使用 supervisorctl 來管理自己的 process (使用範例)

[tainanpy etc]$ supervisorctl

backup                           RUNNING    pid 26703, uptime 26 days, 18:18:33
main                               RUNNING    pid 26702, uptime 26 days, 18:18:33
sentry-web                    RUNNING    pid 26701, uptime 26 days, 18:18:33



supervisor> ?

default commands (type help <topic>):
=====================================
add    clear  fg        open  quit    remove  restart   start   stop  update
avail  exit   maintail  pid   reload  reread  shutdown  status  tail  version



supervisor> restart sentry-web

sentry-web: stopped
sentry-web: started



supervisor> status main

main                             RUNNING    pid 26702, uptime 26 days, 18:19:42
supervisor>


# 其實啟動時可以帶很多參數,config 檔支援 *更多* 設置方式


-c FILE, --configuration=FILE
  The path to a supervisord configuration file.
-n, --nodaemon Run supervisord in the foreground.
-h, --help Show supervisord command help.
-u USER, --user=USER
  UNIX username or numeric user id. If supervisord is started as the root user, setuid to this user as soon as possible during startup.
-m OCTAL, --umask=OCTAL
  Octal number (e.g. 022) representing the umask that should be used by supervisord after it starts.
-d PATH, --directory=PATH
  When supervisord is run as a daemon, cd to this directory before daemonizing.
-l FILE, --logfile=FILE
  Filename path to use as the supervisord activity log.
-y BYTES, --logfile_maxbytes=BYTES
  Max size of the supervisord activity log file before a rotation occurs. The value is suffix-multiplied, e.g “1” is one byte, “1MB” is 1 megabyte, “1GB” is 1 gigabyte.
-y NUM, --logfile_backups=NUM
  Number of backup copies of the supervisord activity log to keep around. Each logfile will be of size logfile_maxbytes.
-e LEVEL, --loglevel=LEVEL
  The logging level at which supervisor should write to the activity log. Valid levels are tracedebuginfowarnerror, and critical.
-j FILE, --pidfile=FILE
  The filename to which supervisord should write its pid file.
-i STRING, --identifier=STRING
  Arbitrary string identifier exposed by various client UIs for this instance of supervisor.
-q PATH, --childlogdir=PATH
  A path to a directory (it must already exist) where supervisor will write its AUTO -mode child process logs.
-k, --nocleanup
  Prevent supervisord from performing cleanup (removal of old AUTO process log files) at startup.
-a NUM, --minfds=NUM
  The minimum number of file descriptors that must be available to the supervisord process before it will start successfully.
-t, --strip_ansi
  Strip ANSI escape sequences from all child log process.
-v, --version Print the supervisord version number out to stdout and exit.
--profile_options=LIST
  Comma-separated options list for profiling. Causes supervisord to run under a profiler, and output results based on the options, which is a comma-separated list of the following: cumulativecallscallers. E.g. cumulative,callers.
--minprocs=NUM The minimum number of OS process slots that must be available to the supervisord process before it will start successfully.
supervisorctl Command-Line Options

-c, --configuration
  Configuration file path (default /etc/supervisord.conf)
-h, --help Print usage message and exit
-i, --interactive
  Start an interactive shell after executing commands
-s, --serverurl URL
  URL on which supervisord server is listening (default “http://localhost:9001”).
-u, --username Username to use for authentication with server
-p, --password Password to use for authentication with server
-r, --history-file
  Keep a readline history (if readline is available) 





autorestart
May be one of falseunexpected, or true. If false, the process will never be autorestarted. Ifunexpected, the process will be restart when the program exits with an exit code that is not one of the exit codes associated with this process’ configuration (see exitcodes). If true, the process will be unconditionally restarted when it exits, without regard to its exit code.
Default: unexpected
Required: No.
Introduced: 3.0


# 官網


Try it !


(文件 Host 在 Readthedocs <- 三月份若渴:來分享的外國朋友創辦的服務)





2014年6月28日星期六

活動:Tainan.py x MOSUT 2014 6 月聚會

歡迎參加本月的 Tainan.py !



恰逢 wen 正在研讀 regular expression,這次聚會日期未定就收到他的投稿 XD
本演講算是 wen 的筆記與心得,投影片本身非常有參考價值


相關補充:

  • Sam 在公司內部介紹過的 regular expression 投影片
  • float 有補充 online tools,我喜歡這一個: Debuggex
  • Arnan 分享了良葛葛的文章: Regex 的強大與哀愁
  • pyMOTW 對 re 的 介紹 (很好的 cook book)
最後再補充「PythonVerbalExpressions」:(寫法可以變成下述方式)
# Create an example of how to test for correctly formed URLs
verbal_expression = VerEx()
tester = (verbal_expression.
            start_of_line().
            find('http').
            maybe('s').
            find('://').
            maybe('www.').
            anything_but(' ').
            end_of_line()
)

# Create an example URL
test_url = "https://www.google.com"

# Test if the URL is valid
if tester.match(test_url):
    print "Valid URL"

#Print the generated regex
print tester.source() # => ^(http)(s)?(\:\/\/)(www\.)?([^\ ]*)$



第二場演講是 kuku 投稿的「蟒蛇大戰,Bj4」
(最近可能由於 hychen 的關係,大家講話都很 Bj4)
講題涵蓋 psyco, Unladen-swallow, PyPy, Pymoyhoa, Pyston, Numba, Nitrous, Cython, Shed-skin ...
這種題目很明顯是資深愛好者才有辦法講的 ... Orz

相關資料:
  • hackpad 上的 筆記 (來自 bj4 聚會)
  • 投影片 (待補)




本次 聚 餐會的主角




由於日前台南黑客松的活動甫結束,索性邀請參加過的朋友過來一起分享心得
我分享了「用路人小幫手x回報大改造」目前這個專案的情況如下:
  • 台南路平、路證 API
    • 暫時為關掉狀態,有持續維護開發的打算
    • 需要找人一起運用「工人智慧」完善路平專案的資料
  • 回報 API
    • 開放中,也會持續開發
  • Android App
    • 由原開發者小宋作為個人興趣的專案邊學習邊開發
    • github repo
  • iOS App
    • 徵求有興趣的開發者與我們聯絡
    • (開發者 Awei Kuo 有與我們聯絡)



Kiang 則分享了自己做的「台南市議員觀測中心」
  • http://k.olc.tw/tncc/
  • 透過視覺化/整理過資料的介面,議員的所作所為更加能夠被民眾檢視
Kiang 亦表達想要參選台南市議員的意願
意圖透過「公開透明」化的方式來參政
有興趣的朋友可以到他的 個人網站 看看!



活動最後收到智程投稿推 MOOC 學習坑的閃電秀:

好多好棒的課程?不一起學習嗎? FB 互相推坑社團


不嘴砲,在台南累積待了八年的我,不猶豫地的捐了 2k 給 Kiang
希望 Kiang 能夠達到自己給自己設立的參選門檻:20萬的捐款
(他會將捐款結餘再捐給 開放文化基金會


2014年6月25日星期三

台南黑客松:用路人小幫手 x 回報大改造

爆肝了幾天,py.Tainan 在 2014 台南黑客松拿到好成績!
(圖片來自 Punnode 的報導)



此次台南黑客松滿足了「台南」、「政府」、「Open Data」的元素
一直嘴砲說改天要跳 g0v 坑的我,只能責無旁貸的參戰下去了 XD

儘管已經硬拉映瑋幫忙設計 APP,評估起來團隊組成還是不夠全面
於是就在 FB 徵人,想不到馬上就找到阿男與小宋 <=熱血地搭高鐵來台南!


題目發想


檢視過台南市政府提供的開放資料後並沒有很大的共鳴
又考量到如果與他人選了同樣的主題,在有限的時間內並沒有做得比別人好的本錢
索性從自身經驗開始發想 ...

「台南有些路段,路面真他媽的不平 .... 」

由於遇到這種路段,發自內心會真的很生氣
就決定做此題目了!(Anger-Driven Development)

於是我進行以下 survey ,了解到市政府對路平專案、路證核發、交通事件回報 ... 的做法
並發現以下問題:

  • 政府有做事,但是民眾不知道
    • 因為不知道,所以無從監督政府的執行
      • 然後就做得很爛
  • 路平、路證、交通事故的資訊散佈在政府的各網站
  • (我)作為民眾不會想知道市政府底下各單位的權責業務範圍,只希望當下問題能被解決
    • 想要查詢的資訊希望能夠即時得知
    • 想要回報的問題,要有便捷的管道可以使用
  • 台南市的 線上即時服務系統 不好使用


Hack Hack Hack


為了解決上述問題,我決定採用以下方式來 Happy Hacking

  • 沒給路平、施工、交通相關的 API ? ... 那就自幹吧!
  • 回報頁面太難用? ... 那也幫政府自幹出 API 好了!
  • 全民通報 APP (民眾版)太難用? ... 乾脆也自幹一個!
    • 需要從民眾的「使用情境」出發
    • 此產品將應用自幹的 API ,讓大家知道 Open Data 後可以有什麼改變

構思至此為止,之後我除了帶團隊成員一起去吃琴牛肉湯以外
大概就沒什麼貢獻了 XDDDD


阿男是台南少數我知道有用 Python 寫 Web 的朋友(之前用 pylons !!)
他這次也毫無意外的使用 ...
呃 ... nodejs + phantomjs + notepad++ 實作出最重要的路平、路證 API
(證明了寫 python 的人也是很喜歡擁抱其他語言的 ... XD )
而且支援了很多我覺得非常重要的投影片


映瑋畢業於成大工設,擁有多年的 iOS 「使用」經驗
儘管沒有設計過 APP,被我凹了以後,短時間內也能幫忙設計出質量俱佳的 APP
重點是 ... 她不會被「架構」、「Open Data」... 等等的術語迷惑
設計能夠從使用者的情境出發!
例如:相簿樣板、標籤、分享到 Facebook 的概念都是由她提出


研替中的小宋本行不在 APP 開發,這次完全是熱血衝下來,邊學邊改 APP
這次黑客松開發壓力最大的人,鐵定就是他了! XD


我在架構跟目標出來以後,就把台南市線上即時服務系統解構成一系列的回報用 API
並做了一個返樸歸真版的回報 page,以此舉例說明可以這樣使用回報 API


成果


在極度缺乏睡眠的情況下,我們終於完成了第一版的 API 開發
50 % 左右的 APP  功能與完整的 APP 設計
週日早上團隊在一陣忙亂中製作完投影片,就一起抱著快掛的身體前往會場

我們在第四組就上場進行三分鐘的限時簡報
原本準備五分鐘的投影片很明顯講不完 ... Orz  



雖然沒講完頗沮喪,卻因為很早完成簡報,所以能夠放輕鬆地聽聽其他組的報告
以及與場內的熟人聊天、打嘴砲  XD

頒獎時原本是預期得獎機會不大(太早出場 + 沒有完成簡報)
最後卻意外地在 35 組中拿到 No.2 ... T___T

四人累到掛掉後 ... 終於得到了肯定!
我們之後也會買網域,並把 API 整理後再度釋出!

  • 本專案目前 focus 在台南,將來會與 g0v 的專案討論看看怎麼合作
  • 本專案屬性與黑客松同組的 Open311 很像
    • 可以透過 API 串接起來
  • 如果有朋友對於我們設計的 APP 有興趣,可與我們聯絡喔!




隨筆雜記


Day 1 恰巧與主持人穿同一件 T-Shirt .. XDDD

  • data.tainan.gov.tw beta 使用 ckan 架設!(python!!)
  • 比賽前我以為只有 40 人參賽 ... 
    • 怎麼算都很有機會得獎 XD
    • 結果第一天看到有 39 隊上百人參賽 ... 囧rz
      • 後來想通,在 kktix 上一隊只會顯示出一人 ...
  • 我最看好的百年地圖果然得到很高的評價!!
  • 映瑋被團隊一致選為:最適合當 PM 的人
  • 記得嗎?拍照時那張很大的「第二名」板子
    • 「沒有人」毫不猶豫把第一名的板子留給我們
    • 然後映瑋就把第一第二名的板子對切,當作材料回收走了... o.o"
  • 當初團隊取名 py.Tainan 其實就是 Tainan.py 的倒裝
  • 前同事的隊伍其實有做一個超有梗的拍照樣板 XDDDD
  • 主辦單位直接發現金,非常有誠意!
    • 小宋賺回了台北台南來回高鐵錢 : )




2014年6月14日星期六

懶人包:TDD is Dead 戰文總整理


日前 Kent Beck, Martin Fowler, DHH 的三強視訊會談 Part V & VI 甫結束並釋出影片 ...
總算為軟體開發界的 TDD 大戰劃下了句點 ...

我恰好這一系列的討論都有空 follow
於是整理本文作為個人筆記,供有興趣的朋友一同討論

# 本文前半部參考 91 前輩先前整理過的 懶人包
# 文長慎入 ... 可能需要 15 分鐘至  1~2 天才能看完這些資料 ... 
# 有朋友要幫本文寫懶人包嗎? => 懶人包的懶人包?? XDDD


圖片引用自 這裡 ,該公司為了紀念 TDD is Dead
將旗下與 TDD 相關的 e-learning albums 組合成 box set
並且限時給予 50% 折扣進行販售 ...



觀戰前的背景知識

Martin Fowler (Refactoring: Improving The Design of Existing Code 的作者) 有寫過這些文章:

介紹 TDD 的文章:

毋庸置疑地, Kent Beck 的 Test-Driven Development by Example 是了解 TDD 起源的好書:

備註:
如果您對 Testing 毫無概念
可以先到 tutorialspoint 下載 testing 的 電子書 建立基本概念



緣起 ... 

(* 表示建議閱讀)

4/23

  • DHH (David Heinemeier Hansson) 在 RailsConf 2014 演講時,先借由減肥無祕方的例子來暗喻軟體開發不該迷信,之後進而開始抨擊若導入 TDD ,則會為了測 unit test 使得設計出來的架構變糟 ... 
  • DHH 發表 TDD is dead. Long live testing. 一文
該事件發生以來,引起軒然大波
因為他是 Rails 作者 + 知名軟體公司創辦人 + 暢銷作家 ( rework / remote )


事出必有因,若往前追究
我們可以知道至少從 2012 開始,就有人嘗試把六角架構 (Hexagonal) 帶入 Rails
以解放 application 對 Rails 的依賴
  • 2013
    • Jim Weirich on Decoupling from Rails
而 DHH 在 2013 年初亦發表過 Dependency Injection is not a virtue 一文
可以看出對於該怎麼使用 Rails ,身為作者是有一定的想法





Part I:  筆戰

4/24

  • Jim OKelly 發表 Why I can TDD and why DHH can't 一文
    • 認為 DHH breaks shit at the wrong boundaries
    • 推薦 Gary Bernhardt 的演講
    • 說明自己為什麼喜歡 TDD,是因為只寫小、目的單純、stateless 的 object,且搭配 FP style 進行 programming ...


4/25

  • Uncle Bob (敏捷開發、Clean Code ... 的作者) 發表 Monogamous TDD 一文
    • 針對 DHH 文章的開頭用詞「Test-First 基本教義」跟相關比喻進行回擊
    • 說明  TDD 的好處
    • 回應 DHH 使用 integration testing:
      • If you can meet my two predicates of trustworthiness and speed, go for it!
    • 最後又點出只做 integration test 的問題
      • 速度慢(DB, GUI)
      • Coverage 較不足

4/29

  • DHH 發表 Test-induced design damage 
    • 聲明 Jim Weirich Demo  的六角架構不適合使用在 Rails 上
      • Rails 有跑 persistent console process ,且對於 test case 有 transaction wrap ... ... 所以速度已經快很多
    • 說明 controller 就是要拿來跑 integration testing 用的,並且針對 Rails/MVC testing 該怎麼做進行指導


4/30

  • Kent Beck 發表 RIP TDD
    • 本文並沒有回應 DHH 的看法跟觀點,但用反串方式說明 TDD 的存在價值
    • 以下為全文截圖



  • Uncle Bob 發表 When TDD doesn't work 
    • 說明 TDD 不適用的情境:
      • The physical boundary, and the layer just in front of that boundary that requires human interaction to fiddle with the results.
      • The test code itself.
    • 說明將 logic 抽出並不會傷害 application:
      • 這是 good design
      • (有回應 TDD is Dead / Test-induced design damage 的意味)


  • Gary Bernhardt 發表 TDD, Straw Men, and Rhetoric 反擊 DHH 新發表的文章
    • 引用 DHH 的 Slow database test fallacy 的內容:The classical definition of a unit test in TDD lore is one that doesn't touch the database. 
      • 作者透過引用相關文獻以說明 TDD 的發展比 Mock 還早,所以早期的 TDD 定義並沒有要求使用 Mock 或是撰寫 isolated unit test ... 
    • 進而對 DHH 的其他不正確陳述進行一連串的反駁 ...
    • 提到自己不滿足於 integration testing 的速度,自己對測試 feedback 回來的需求是 300 ms
      • 說明在此情況下對生產力的提升(更專注、快速測試-> 短時間內得到更多 feedback)
    •  說明自己對 TDD / test isolation 的看法 


5/1  





Part II:  視訊戰



在筆戰的過程中,其實 DHH 已與 KB (Kent Beck) 及 MF (Martin Fowler) 用 skype 聊過天
最後在 ThoughtWorks 的協助下安排一系列的 google hangout 視訊並且釋出影片
MF 有對這一系列影片做整理並且放在他的 部落格

(以下懶人包部分摘錄自 MF 的部落格,強力推薦閱讀 MF 整理的重點)



5/9  

  • Is TDD dead? [Part I]: TDD and Confidence
    • 錄影 (約 30 分)
    • DHH 提出三個問題:
      • Unit test/TDD 的定義
      • 架構系統若使用 mock 會導致 test-induced damage
      • 自己並不 enjoy TDD flow 的流程
    • KB 點出要達到對自己的 code 有信心 (confidence) 是 programmer 的目標,若在此共識之下:
      • 對他自己來說 TDD 是其中一個能達到這個目的的方法
      • 舉出前幾天在 FaceBook hackathon 時混用 TDD 與一般測試開發方法來幫助自己開發的經驗 (目前 KB 在 Facebook 工作)
    • DHH 表示自己:
      • "...you're not done until you also have tests for a piece of functionality -- I'm completely on board with that."
      • 認為 TDD 適用某些地方,但是套用 TDD 並不會讓自己快樂,在某些領域 用 TDD 會是 bad tradeoff (特別是使用大量的 mock)
    • KB 回答:
      • 自己很少使用 mock、多層 mock 很糟
      • 取得 repeatable feedback loop 是重點
      • 當發現測試難以撰寫,會先 check 是否是架構上的 design 問題
    • MF 補充:
      • 是否要撰寫 isolated unit tests 是個人選擇問題 - 當年自己跟 KB 在推 TDD 的時候,還曾被批評沒有寫 isolated unit tests ...
      • 是否綁定 TDD 與 isolated unit tests 是派別問題 - 自己認為不該綁
      • TDD 是達成 self-testing code 的 approach 之一,如果有其他方式能夠達到,那也很好


  • 5/15 (迴響)
    • Gary Berhardt 發表 Test Isolation is About Avoiding Mocks
      • 引用 KB 在 Is TDD dead 的觀點 nested mock 是不好的,進一步以自己的經驗與例子,闡釋 test isolation 能夠帶來的好處
        • Structured programming clarifies control flow; isolated tests clarify coupling.

  • 5/19 (迴響)
    • Uncle Bob 發表 First
      • 引用 DHH 在 Is TDD dead 的觀點 "...you're not done until you also have tests for a piece of functionality -- I'm completely on board with that.",進一步闡述 testing 的重要性與好處,最後反問 .. 既然很重要為什麼不先做 (First)



5/16  

  • Is TDD dead? [Part II]: Test Induced design damage
    • 錄影 (約 30 分)
    • DHH 從 Jim Weirich 當初展示的六角架構範例,擷取出 gist ,指出架構上許多不必要的設計
      • 程式碼的數量會影響到是否易於改寫
      • 每一個中介層會帶來高成本
      • 就是因為使用 TDD 所以特別容易引誘人寫出這樣的架構
      • KB 指出
        • ascribing test-induced damage to TDD was like driving a car to a bad place and blaming the car for it,表示是否需要設計出這些中介層是要被評估的
      • MF 補充
        • DHH 指出的問題是由於想要 isolation 導致的,而不是 TDD
      • 摘錄自 MF 的部落格:
        • Kent clarified he wasn't talking about TDD, but about software design in general, it's not about TDD it's about how to get feedback. Thinking about software design is the thing, because it pays off so big when you get a good design insight. Getting these insights isn't about your workflow, it's about things like knowing when to work and when to rest, gathering influences from other places, collaborating with other people.



    5/20  

    • Is TDD dead? [Part III]: Feedback and QA
      • 錄影 (約 30 分)
      • KB 提出討論 (TDD 的) tradoff 時,有以下幾點要被考量:
        • Frequency - 要多快取得 feedback?
        • Fidelity - 對於 red/green 這些訊號的準確度要求為何?
        • Overhead - 我們願意付出多少代價
        • Lifespan - 產品的生命週期為何
      • MF 補充我們會希望透過得到 feedback 來得知:
        • Is the software doing something useful for the user of the software?
        • Have I broken anything?
        • Is my code-base healthy?
      • DHH 提到TDD 的成功使得:
        • 有些人會過度自信而忽略該有的 QA
        • 有些人會忽略 cost
          • 對於有些情境 (某些 web 應用) 不需要 high reliability
          • 99% -> 99.99% reliability 付出的代價很大,應注意臨界
      • KB 將討論主題拉回 QA
        • Compared to having an effective QA then no-QA is worse, but no-QA is better than the old dysfunctional relationship.
      •  DHH 提到就算透過 TDD 得到 100% coverage 還是可能有誤,KB 則分享對 Testing 的看法:
        • As soon as you think you don't make mistakes any more, that's a mistake, and you stop growing. 


    5/27  

    • Is TDD dead? [Part IV]: Costs of Testing
      • 錄影 (約 30 分)
      • DHH 提到 TDD 易於導致 over testing 的問題
      • KB 提到:
        • 用 test-first 開發 JUnit 時很順利,無 over testing 
        • 引用 Herd Derby 的 delta coverage,建議檢視 test 的重要性
        • 要勇於丟掉沒有用的 test 
        • (testing code / production code) 的 ratio 數據容易讓人混淆
          • 簡單的系統會有低的比例
          • 看情況比例有可能是 10:1 也有可能是 1:10
      • MF 補充:
        • "you don't have enough tests (or good enough tests) if you can't confidently change the code,"
        • "the sign of too much is whenever you change the code you think you expend more effort changing the tests than changing the code."
      • DHH 提到有許多人將測試視為文件,甚至重視 testing code 更甚 production code,而忽略了 TDD 中 Refactoring 的重要性,亦忽略追求 clean code 才是重點
      • KB 說他最近把部分 production code 丟掉,留下測試進行重寫,並提到:
        • would you rather throw away the code and keep the tests or vice-versa? In different situations you'd answer that question differently.
      • DHH 說人們無法正確量化 code quality 所以只能量化 testing 的數據,一味追求這些事情只是 honey trap:
        • Cucumber really gets his goat - glorification of a testing environment rather than production code
        • Only useful in the largely imaginary sweetspot of writing tests with non-technical stakeholders. 
      • 視訊結束前 DHH 提到 TDD 已經征服各領域,但 MF 不這麼認為



    6/4  

    • Is TDD dead? [Part V & VI]: Answering Questions 
      • 錄影 (約 60 分)
      • 本次會談由三人輪流挑選 google hangout 上的問題,並且回答
      • What is an example of an Open Source Project which has "test-induced design damage"? What is an example of a project which does "TDD right"? 
        • 由 Mike Harris 發問
        • DHH 指出 open source 的情境與真實商業專案的情境不一樣,而 TDD 在開發 open source library, framework ... 是有幫助的
        • KB 指出 JUnit 是完美的例子,但是是肇因於 java 上極度 clear interfaces 的關係(所以算是特例)
      • What could change about the way we write software to make TDD redundant or obsolete for Kent and Martin? What could change about the way that TDD is performed to make it useful or beneficial for David?
        • 由 Graham Lee 發問 
        • KB 引用自己寫的 RIP TDD 表示不會因為難以 TDD 而打算拋掉這項技術
        • MF 回答:"Some contexts are very suitable for TDD, some contexts less so". And people bring their personality into that context.
        • DHH 表示他剛開始使用 TDD 時很喜歡,而嘗試用在所有地方,但是在 MVC 的架構下卻遇到問題 ... 但儘管不用 TDD,達成 self-testing code 仍然是目標
        • MF 補充說每個人應該試著嘗試、overuse 以及找到 TDD 能夠運作的情境
      • How do you think a lack of (design) experience affects TDD and how do you think TDD affects an inexperienced developer?
        • 由 Udor Pavel 發問
        • ML 回答:
          • 不應比較:有經驗的人 vs 沒有經驗的人 用 TDD 的情況
          • 應比較沒經驗的人: 用 vs 不用 TDD 的情況
          • it does seem to be advantageous, and creates a self-testing code base which is easier to improve later through refactoring. So tdd gives you a good start point.
        •  DHH 認為 TDD 在被提出後這十年間,已經被許多人加上其他觀點,當他說 TDD is dead 是指這些改變讓 TDD 變質,所以應該找回初衷
      • KB 說:
        • TDD isn't dead, but is glad David set fire to it so it could come out like a phoenix.
      • DHH 在最後的對談提到:
        • 之所以發起 TDD is Dead 是因為人們沒辦法暢談 TDD 不 work 的地方,而被不斷地灌輸一定要 TDD 的觀念。
      • ML  做最後的結論:
        • 三人對於 self-testing code, TDD 在某些情境下 work 有共識
          • 但對 TDD 是否在其他情境下 work 則沒有共識
        • 在軟體開發過程,每個人應建立對自己及團隊有效的開發流程,不該盲目的套用技術
          • We're not in a codified science, so we have to work with our own experience.




    Part III:  不太相關的花絮

    5/13  

    • Tom Stuart 於 Scottish Ruby Conference 2014 投稿閃電秀:The DHH Problem
      • 演講錄影 (約 3~4 分)
      • 作者提出對於看待 DHH 言行的反思 

    5/17  

    • Joe 於 PyConAPAC 2014 投稿閃電秀:BoF is Dead. Long live eating. (PIZZA) 
      • 投影片
      • 內文對 TDD 的暗喻不太正確
        • 但演講內容其實是介紹當天的 BoF 活動





    Part IV:  戰文心得

    DHH 在發表 TDD is Dead .. 一文之後
    在各界的筆戰中大都處於劣勢
    追根究底,是因為他的主要論點只有:

    • TDD 使得開發者把重心放在寫 (isolated) unit tests 
    • 開發者會為了寫 (isolated) unit tests 導致產生不必要的中介層,破壞系統架構

    可以看得出來,他攻擊的點在於 (isolated) unit tests
    而對於 Test-First 這件事本身沒有提出更有力的批評
    更糟的是,當他論述時誤用了一些詞彙跟定義,例如:
    The classical definition of a unit test in TDD lore is one that doesn't touch the database. 
    他試圖表達「以前 TDD 導入 (isolated) unit tests 情有可原 ... 但現在已不適用 ...」這樣的論述
    但是卻被糾正:其實以前的 TDD 並沒有要求做 isolated unit tests(甚至還因此被人批評)
    使得 DHH 的主要論點變得薄弱許多

    而即便不聊 TDD 只聊 isolated unit tests
    其對系統架構的傷害與否也是未有定論
    DHH 認為 Jim Weirich 用六角架構重構 Rails App 是傷害系統架構
    但 Uncle Bob 認為這樣很好,因為做到 separate concerns 更能應付變化

    我記得 Jim Weirich 在 demo 六角架構時有提到
    一般來講他不會對這樣例子的 Application 做這些操作 ...
    亦即,對於開發小型的 Rails 應用極有可能 Jim/DHH 的用法是一致的

    事實上,若能不帶偏見仔細聽 DHH 發言
    他大多數提出的看法和反思對新手是有價值的

    這系列戰文/視訊看來,他是扮演黑臉的角色
    去把思考不夠透徹的人做 TDD/Testing/Design 時會遇到的潛在地雷挖出來
    並透過與 KB / MF 的討論告訴大家

    至於是否 TDD is Dead ?答案很明顯 : )
    我的結論前半與 KB 一樣,後半與 DHH 原本說的話一樣

    • TDD isn't dead, but is glad David set fire to it so it could come out like a phoenix.
    • Long live testing.


    Part V:  個人經驗

    一兩年前初探 TDD 時,最讓我有共鳴的是重視 context 這件事
    亦即,有了所謂的使用情境,production code「為何而寫」才會清楚 ...

    一陣子之後,我混用 TDD 的概念應用到開發 web API 的使用情境
    透過交替撰寫 testing code  與 production code (順序很隨性 XD)
    進而讓被釋出的 API 品質提高非常多

    但實作上我沒有撰寫所謂的 isolated unit tests 
    而是真槍假彈地跑 integration tests
    事後我才知道,對我負責的系統而言
    我的做法偏向 ATDD ...
    但實作上卻常遇到問題:上游根本沒有定義使用情境或是定義混亂 ... Orz

    藉由這次的 TDD is Dead 大戰
    我把看了好久都沒看完的 Test-Driven Development by Example  讀過
    並且盡可能把相關文章、影片看過,釐清各方思路進而整理出筆記

    雖然花了好幾天的時間,卻也得到海量的收獲
    這些所得對新手而言,絕不是學五分鐘 TDD 或是看一兩篇短文論述就能領悟!


    最後,附上許多問題 + 個人想法結束本懶人包:
    • TDD 會造成 over design 嗎?
      • 基本上不會。如果要說的話是造成 over implementation 
        • 亦即實作上比較費力,但是都還是緊咬著需求
      • Kent Beck 曾說過非常貼切的一句話來形容 TDD:
        •  "Code for tomorrow, design for today." Here's what happens in practice.
    • TDD 適合解未知的問題嗎?
      • 適合。但前提是 ... 
        • 在該領域本來就能透過寫 test 驗證答案
          • 而且越好寫 Test 越適合透過 TDD 解問題
      • 套用 TDD 的 workflow 很像在用數學歸納法解題
    • TDD 會導致系統缺乏全局設計嗎?
      • Kent Beck 曾舉例:
        • "What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure, it's TDD.
      • 我常舉例,只要把手邊的 ToDo list 轉成 ToTest list 就可以開始 TDD 了
        • 意指 TDD 的思維不會打壞原本的設計,只是透過思考 context 讓實作更加實用罷了!
    • 所以我該馬上導入 TDD 到我的專案?
      • 會問這個問題可能是因為
        • 還不夠了解 TDD
        • 還沒有想清楚自己專案情境
      • 建議衝動地想要全面擁抱 TDD 前,思考過 DHH 的論點以避免地雷
    • Jim Weirich 介紹的那種六角架構合不合用?
      • 懶惰點的回答是 - 看情境
        • Jim 有提到一般來講他不會對小程式做這樣的操作 ...
        • 我個人其實之前也是以 integration tests 為主,但是這個架構讓人能夠重新思考 procedure/OOP 的概念
      • 更深入想想則有很多有趣而值得反思的點:
        • Web MVC 是一個怎麼樣的設計?
          • 你撰寫的程式碼是 style 偏 procedure 還是 OOP?會怎麼混合?
        • 為什麼開發者在 Web MVC 的框架下開發,往往會在系統規模變大時讓 Controller 的部分會變得雜亂?
          • 這個時候是不是該抽取出 business logics 或是改變系統的設計?
        • 使用框架的初衷跟需求為何?
          • 想要全盤 or 部分接受 Rails?
          • 如果很不喜歡 Rails 的架構,而花費大多數心力在脫離他?那幹嘛還用它?
        • 會有更加友善且同時支持「開發」與「測試」的框架嗎?
    • 你對 DHH 看法如何?
      • 我買過他跟 Jason 合著的書且寫過 心得 ,你認為呢 XD
      • 附帶一提看完大戰後,我對於 Kent Beck, Martin Fowler 是感到佩服跟尊敬
        • 好在 Uncle Bob 只有寫文章沒有出來視訊(叔叔的文章比較戰 ...)
        • 我相信 Kent Beck, Martin Fowler 是本著想釐清問題跟推廣 TDD 的角度來進行視訊
    • 所以到底該如何開發 Rails App?
      • 呃 ... 我只寫 Python ... lol (魯蛇無誤)


    撰文緣由:

    我在 5/31 的 Tainan.py 投了一場演講
    演講內容從 testing 概念到 unit tests 到 TDD ...
    輪到 TDD is dead 系列文的開頭時就過了一個多小時 Orz
    最後在講得不清不楚的情況下結束演講

    痛定思痛,索性花幾天的時間整理系列文章
    希望對當天的朋友、有興趣的朋友有所幫助

    台灣各地 Python 社群列表:
    Taipei.py - 台北
    PyHUG - 新竹
    Taichung.py - 台中
    Tainan.py - 台南
    Kaosiung.py - 高雄
    花蓮.py - 花蓮