這次特別報名參加了 Agile Tour Taipei 2015，要來補充一下 Agile 與 Lean 相關知識，兩天的活動包含了議程與 Workshop。不過因為 Workshop 正好辦在週日，雖然有幾個感興趣的活動，最後也只能放棄無法參加。
議程從上午 9 點直到下午 4 點半，上午只有一條 Track，但下午則分為兩條 Track。偏偏下午兩條 Track 都有想聽的題目，被迫要有所取捨，導致在中午午餐時間，我在內心演了好久的內心戲，掙扎許久最後選擇了 Track 2。
首先是第一場議程的筆記與心得：
從敏捷與精實看軟體開發的未來 - 李智樺 Ruddy Lee
講師簡報已經釋出，強烈建議務必要閱讀學習。(立即瀏覽) 同時 Agile Tour Taipei 2015 已經釋出本議程的錄影。
首場議程是由金牌講師 Ruddy Lee 擔任，在議程正式開始之前，講師就已經提前開始與聽眾們有著許多的互動，講師一開始就直接開始在白板上畫出「看板」，並請工作人員拿出便利貼開始整場傳遞，邀請聽眾可以寫下任何與 Scrum 相關的問題貼在白板上。
老實說在那個當下，我一度覺得自己是不是走錯場子？今天不是來聽議程的嗎？怎麼彷彿走到 Scrum Master 教育訓練場。而事實上講師所有的舉動，其實都是在默默的鋪梗，當簡報進行到後半之時，就會恍然大悟，原來白板上的「看板」就是簡報內提到的「Q &A 看板」。
在開場中講師有提到一個我覺得很重要的觀念，意思大約如下：
「敏捷其實並不是一個強調『快速』的開發方法，它是用來處理複雜問題的方法，因為它是一個務實的方法。而正因為它能有效地處理複雜的問題，彷彿很快就能解決問題，因此造成大家覺得它很快！」
我覺得這一個觀念的重要性在於讓人對於「敏捷」建立正確的態度，因為真正重要的需求是什麼？應該是「解決問題」，而敏捷提供你一套方法來有效的「解決複雜的問題」。當你可以一再地「務實且有效地解決複雜的問題」，並且定期不斷的「持續改善」，那麼自然你的效率也就越來越「快」！
接著進入議程的主軸，整場議程主要環繞在「看見」這兩個字。首先講師連續用了幾個範例來讓聽眾體會「看見」，強調人們經常需要看見，看了之後才有感覺，才會產生聯想。
例如單車登山的照片，往往你會看見的照片有兩種，一種是車手順利上山，在山頂上的勝利姿勢，另一種是車隊在半路中努力克服陡坡的奮鬥過程。但實際上的情況卻不是如此美好，事實是山頂或山路上可能是車滿為患，車手在登山過程中經常被卡在車陣之中。你所看到照片不過是一個過度美化的結果，所以「看見」不只是看表象，更要能看見「真諦」。
繼續更多「看見」的例子。
同樣是飛機窗外的景致，但是去程與回程帶給人的聯想是不同的。你若在去程飛機上，看到窗外的景色，恐怕你的聯想是：
「下飛機後要先去哪邊 checkin，接著要去哪邊與客戶碰面，然後⋯⋯」
若是回程飛機，恐怕你所想的則是：
「終於可以放鬆休息了，想念家中的妻小⋯⋯」
同樣類似的景致，但能產生的聯想卻是大不同。
飛機的舉例還延伸講到另一個重點，就是「抽象化」。當面對問題時我們要將問題「抽象化」，就像飛機越飛向高空，則地表物體顯得越來越小，你就能看到更多的「全貌」；這就如同由「極度明確」往「極度抽象」的方向前進，當飛到一定高度之後，你會發現問題就只是地表上的一個小點而已。
接著下一個「看見」的範例是一段影片。
講師播放了這幾天被許多內容農場瘋傳的影片《CANAL+ Football - Cameramen》 不過這裡當然不只是為了博君一笑，講師其實是要借用影片中表現的「因為有賣力的攝影師所以我們才能在電視上看到精彩的足球轉播。」這個概念，來類比「看板與專案」之間的關係。
不同於影片，下一個「看見」的範例是一個故事。
講師提到他曾收過一封 E-mail，有位年輕人請他看一下某個網站，但當年的他並沒有任何的感覺，因此遲遲沒有回覆對方，然而多年之後現在這個網站是人人都在用的 Google。...
不曉得該怎麼替本篇內容命名文章標題，所以最後索性直接拿關鍵字當作標題，就讓我偷懶一回吧。
最後還是改了一個標題，因為之後寫的文章可有能會提到這一篇。
公司新添購了一台 Synology NAS 型號為 DS1515+，明眼人一看這型號應該就明白，這是一台可以運行 Docker 的 Synology NAS。Synology NAS 其實原本就已經可以安裝各種套件，讓使用者享受一機多用的好處。現在變本加厲能直接運行 Docker，這根本是意圖叫人不要把 NAS 當成純粹的 NAS 來使用。 （若想要查詢哪些 Synology NAS 可以運行 Docker 可以參閱 Synology 網站。）
既然廠商如此用心良苦，意圖叫人惡搞善用他們家的產品，我們當然恭敬不如從命。基本上既然可以運行 Docker，那麼其實大部分 Server 能做的事情都有機會可以轉移至 NAS 上，所以首先我便打算在上面運行一個 Container 來取代既有的 Raspberry pi。
預定的使用情境大概如下，我們有一檯 Raspberry pi 在運行 cron，它會替我們定時定期執行一些工作，工作的程式是用 php 編寫，透過 php cli 來執行。由此若要轉移這個工作，所需最簡單的環境就是一個有 php cli + cron 的 Container 即可。
因為已經有許多人分享如何在 Synology NAS 上安裝 Docker，因此本文就不再重述，只能說安裝流程非常簡單，只要滑鼠點幾下即可，沒有任何難度可言。使用 Docker 也與安裝一樣簡單，只要透過管理界面點幾下，很容易就能下載 Images，並運行 Container。
如此一來剩下的麻煩事就只有該如何做出一個有 php cli + cron 的 Container 呢？...
故事是這樣演的，接續上一篇文章《幾個圖片無損的壓縮方案》的研究之後，我們開始在專案之中採用 mozjpeg 來做圖片無損壓縮，從正式採用到現在其實也已經過了數個月，忽然某一天客戶回報了一個奇特的異常狀態。
客戶：「你們的網站圖片載入的時候，會先出現灰階圖片，最後才變成彩色圖片！可以修理一下這個 Bug 嗎！！」
聽見這樣的描述，老實說還真是一頭霧水，霎時間不知道該從何處下手，是瀏覽器問題嗎？是引入某個 javascript 的問題？還是 Server 傳輸？還是圖片本身的問題呢？
當然在文章標題我已經揭曉答案，是 mozjpeg 壓縮造成的問題，不過更正確來說這是 mozjpeg 壓縮的 option 設定不當所導致的問題。
在正常安裝完 mozjpeg 之後，你就會多出一個 cjpeg 的指令可以使用，而我們所採用的 option 如下：
cjpeg -optimize -quality 95
這是讓 mozjpeg 進行圖片最佳化 (-optimize)，並且圖片品質設為 95 (-quality 95)，在這樣的設定之下，可以獲得多大的果效呢？下圖是一個實驗的數據，可以看到檔案容量由 4667854 bytes 壓縮成 1403752 bytes，等於壓縮後圖片只占用原圖約三成的檔案容量，可以說是相當不錯的結果。 可惜這美妙的結果，透過瀏覽器檢閱時，卻會出現灰階圖片的問題。
下圖即是異常狀態的螢幕截圖。當在網路速度較差的時候，瀏覽器還在逐步載入圖片，在視覺上會出現先載入灰階，再載入其他顏色，最後才形成彩色圖片的過程。而這樣的狀況即便改用其他的瀏覽器也會出現。 最後該如何解決呢？其實很簡單，只要在壓縮時補上 -baseline 這個 option 即可：
cjpeg -baseline -optimize -quality 95
這樣壓縮後的圖片，雖然檔案容量比較大一些，但是其實也大沒多少，我們用同樣的圖片當作範例，各位可以看到下圖，也不過就是從 1403752 bytes 變成 1472331 bytes，我想這多出來的些微檔案容量，能用來解決客戶眼中的 Bug，可以說是相當划算。 以上就是本次的「獵奇」案件，報告完畢！
因為專案需求，需要盡可能地降低圖片的檔案容量，可是一旦過度壓縮客戶又會哀哀叫說圖片變得好醜，只好來協尋是否有優質的無損壓縮方案，畢竟人的肉眼分辨能力有限，在壓縮比率、檔案容量與肉眼識別度三者中應該能找到一個平衡點。
在詢問過 Google 大神之後得到了幾個比較多人推薦的方案：
mozjpeg jpegoptim OptiPNG 前兩項是針對 JPG 圖檔壓縮，第三項是針對 PNG 圖檔壓縮，最後選擇了 mozjpeg 與 OptiPNG 運用於專案中。
選擇的原因很直覺，因為 mozjpeg 是由 mozilla 所推出且 Facebook 也有贊助並使用於 FB 上，感覺上比較有保障，至於 PNG 圖檔，找來找去總是先看到 OptiPNG 的參考資料，就先選擇它了。
安裝與使用 OptiPNG 先從簡單的開始講，如果是 ubuntu 使用者，只要透過 apt-get 即可安裝 OptiPNG。
apt-get install optipng
基本用法為「指令 檔案」（注意：它會覆蓋原圖檔）
optipng test.png
進階一點的用法，你可加上一些參數設定：
像是 -o 來設定不同的 optimization level
optipng -o 5 test.png
optipng -o 7 test.png
安裝與使用 mozjpeg mozjpeg 的安裝我採用的是先 make 出一個 .deb，再透過 .deb 安裝，這樣做的原因是為了方便後續可以快速轉移到各台不同的 ubuntu 上安裝。
首先找一檯乾淨的 ubuntu 的 VM（個人潔癖問題），安裝好 bulid 所需的基本軟體（參考官方文件）...
第二天的心得與筆記做得比較少，一方面是連續兩天的大會實在很累，另一方面則是因為下午輪到自己要上場，很難一邊聽講的同時一邊思考並修改簡報，例如我的簡報最前面 DevOpsTaiwan 社群的介紹其實就是現場才新增進去，另外也現場增減了一些簡報內容。
DevOps：IT人的新技能、新文化 - 王宏仁 / iThome 新聞主編
第二天開場的重點就是 2014 State of DevOps Report，所以直接去看報告吧！另一個重點就是選對工具很重要！(但別忘了 DevOps 的重點是人與文化！)
DevOps in the Cloud - Ian Lewis / Google 雲端平臺Developer Advocate 基本上整場的內容就是在推銷 Google Cloud Platform，其中有聽到幾個功能稍微有一點興趣，有機會可以研究一下與其他雲端平台有何不同。
instance group manager Cloud Monitoring dashboard 與 Metrics 廚師與伺服器 - 蔡宗城 / 趨勢科技 資深工程師 感想就是講者應該是 Chef 大師，但實在可惜因為場地的網路問題，導致無法順利的 Live Demo。
Yahoo 行動 App 開發在持續整合與持續交付的經驗分享 - 李卿澄 / Yahoo 亞太區產品研發工程部 軟體工程師 講者提到重點在於「workflow of tasks」，另外兩個重點則是要：
過程全部自動化 盡可能將東西放進版本控制之中 在流程上則有以下幾個步驟： Before Commit (要先做 Code Review) Commit (人工 code review 有時候還是會有錯誤，所以還是要透過 CI 自動化的測試再一次把關，然後才能 Merge) Commit stage (同時會檢驗一些指標，例如：測試覆蓋率…) testing (會做 smoke test 、functional test) non-functional testing ( 效能、穩定性 stability test, Monkey test, performance test…) 中間有時候還會有人工測試 (少數案例，例如：結賬與金流相關功能。) production release (如果上線之後還發現問題，就要修改 testing 流程，增加新的測試項目避免再次發生同樣的問題。) 另外講者也有稍微提到 APP 與一般軟體在 CI / CD 上的差異。 Ansible 實戰：Top-down 觀點 - 葉秉哲 / Gogolook 架構師 又是葉大的場，果然一樣精彩，對於 Ansible 又更認識了一些，再加上葉大的實戰講題都會附上簡報與 github，因此聽完之後還可以自己回家慢慢練一次，實在是太好心了！...
約在今年 6 月中的時候，iThome 即宣布將在 9 月 1 日 ~ 2 日舉辦 DevOps 2015 研討會，並且開始廣邀徵稿至 7 月 6 日。雖然上次投稿 ModernWeb 2015 沒被選上，但不灰心本次再接再厲再次投稿，想不到還真的有幸被選上，所以除了要上台當講師的時間之外，其他時間則可以免費入場聆聽這兩日的 DevOps 2015 研討會。
網路上似乎已經有一些評論與心得文，所以就不打算重述太多細節，以下就只簡單的記錄個人的幾個心得，針對每一場講題簡短的記錄：
開場致詞 - 吳其勳 / iThome電腦報 總編輯 吳總編輯提到今天的現場約有 300 多人，數量比我個人預期的少？稍微查了一下台大集思的國際會議廳座位有 368 人，首日觀察覺得約 9 成滿，所以人數應該確實是 300 多沒錯，第二天的觀察是約 8 成滿，不知是否大家對於第二日的講題比較沒興趣？
DevOps 運動的全球大趨勢 - 王宏仁 / iThome 新聞主編 王主編再次講了 iThome 網站上已經刊登過的非洲銀行導入 DevOps 的案例，這個案例之所以重要的原因是想要強調就連傳統的銀行業都已經導入 DevOps，那麼身處在軟體、網路、資訊產業你還能不知道什麼是 DevOps 嗎？
CI 伺服器全制霸！活用自動化技術重建「最強」團隊 - 直井 和久 / 樂天 旅遊業務開發維運部 旅遊網站團隊經理 iThome 最近的幾次活動都有找樂天來擔任講者，幾次下來可以理解到樂天的背後確實有強大的技術力，這次來的 直井 和久 先生也是，感覺上在 CI、Jenkins 上的經驗豐富，但實在很可惜因為語言表達的問題，導致這次沒辦法與聽眾們有更多深入的 Q&A 互動，看到他在回答時默默地自言自語說了 How to say 還真是為他捏一把冷汗。不過自己也在自我省察，因為個人在英文的「說」這一方面也是很需要加強，若是在台上遇到英文問題我恐怕也是要冒冷汗了。...
八月初的時候，DevOps Taiwan 社團舉辦了第一次的 Meetup，並邀請了三位講者來分享講題。我有幸能擔任其中一位講者並分享《摩登開發團隊的 DevOps 之道》這個講題。
講題乍看之下似乎太過故弄玄虛了一點，因為這題目原本是用來投稿 iThome 與 Taiwan WebConf 主辦的 Modern Web 2015 所準備的，因此故意在題目命名上誇張了一些，其實講題內容很單純，就是想跟大家聊一聊「什麼是 DevOps？」。
當然很可惜當時投稿沒上，因此在這次 Meetup 就可以直接厚臉皮地拿出來講，反正從來也沒人聽過我講，再者「什麼是 DevOps？」這樣的內容用來作為 DevOps Taiwan 社團第一次 Meetup 的開場講題其實是相當合適的。
摩登開發團隊的DevOps之道 (@DevOpsTaiwan) DevOps 之瞎子摸象 DevOps 到底是什麼？我覺得這實在很難用簡單的一句話來解釋，因此我們會看到有人說 DevOps 就是敏捷開發，也有人說 DevOps 就是持續交付 (Continuous Delivery)，事實上這些說法也不能說它錯，但好像有一點不夠完全，無法完整的描繪出 DevOps 的整體面貌，似乎大家就像是「瞎子摸象」一樣，嘗試勾勒出 DevOps 這隻大象，但是會不會 DevOps 根本不是一隻大象？搞不好其實是一隻恐龍或是其他種類的生物？
毋庸置疑 DevOps 就是潮 但不論 DevOps 到底是什麼，有一件事可以肯定，那就是它絕對是目前非常「潮」的一個詞，因為你隨便 Google 你可以找到一堆文章、報導、教學、報告、服務、工具或職務…等，全都掛上了 DevOps，即便你都還不真正的認識它，但你已經無法阻止自己看到它出現在各個地方。
What is DevOps 延續前面提到的，DevOps 很難很簡單的被解釋，那麼有沒有比較複雜又完整的定義或解釋呢？ 答案是有的，除了 Wiki 之外，只要 Google 「What is DevOps」就可以找到一堆，而若你真的去 Google，你很可能會發現目前有滿多人是用 CAMS 來解釋 What is DevOps。...