延續去年的盛況，今年 iThome 再次舉辦了 Container Summit。當舉辦的消息剛釋出時，本來是沒有太多興趣的，是一直等到議程公佈，發現有邀請了數位國外講師，包含 Mesos、Rancher 及 DaoCloud⋯⋯等，才改變心意，立馬向公司申請公差決定要來好好朝聖一番。
這次的議程我覺得可以分成三種類型，分別是「大師推坑」、「觀念分享」及「就是來賣產品」。因此並非每一場都需要做詳細的筆記，有些場次只有幾個重點需要記錄，剩下的時間都是在欣賞講者的推坑功力，看看能不能順利讓聽眾們買單。
這次「小城故事不多-科技部」以團體戰術在第一時間就釋出了各場重點筆記，有興趣者可以直接參閱他們的兩篇筆記文，內含每一場的重點筆記。
https://smalltowntechblog.com/2015/12/10/ithome-container-summit-day-1/ https://smalltowntechblog.com/2015/12/11/ithome-container-summit-day-2/ 在這一次的 Container Summit 2015，iThome 依然邀請了葉秉哲（以下簡稱：葉大）為大家分享議程，這次葉大同樣帶來一場屬於「觀念分享」的題目「擁抱或對抗？談 Docker 對傳統 DevOps 工具鏈的衝擊」。
簡報已釋出，可直接線上瀏覽。
開場葉大先用幾則笑話調侃了一下 DevOps 的現況，基本上就是 DevOps 的定義問題、DevOps 涵括太多的領域及 DevOps 的工具種類與數量多而繁雜。
有鑒於 DevOps 目前的現況，因此若想要在一場分享中介紹這麼多 DevOps 相關的內容是不可能的，必須換個角度思考，只能針對有限的關鍵問題分享。
那麼到底在實際面上 DevOps 切身相關的問題是什麼？
於是葉大借用了 Brian Brazil 在文章中提出的三個嚴肅的問題來回答。這三個問題分別是：
How to recreate your system（如何重建你的系統 ） How to safely change your system（如何安全地改變你的系統） When something has gone wrong（你有辦法知道系統出狀況並解決它） 相信 Ops 一定會立刻認同這三個問題的重要性，因為不論是重新打造或修復重建系統，系統建立是 Ops 最基本的關鍵工作。
而系統建立之後，還會遇到需求變更或軟體升級⋯⋯等原因導致系統必須被改變。
最後即便放了綠色乖乖也不代表系統永遠不會出問題，因此系統監測絕對是第三項不可缺少的關鍵項目。
可以說對 Ops 而言若想要提供一個穩定的系統，這三項是絕對逃不了的關鍵問題。所以在談更多 DevOps 的內容之前，不如先好好的討論這三個問題。...
接續同系列文章《Agile Tour Taipei 2015 筆記與心得》，本文繼續記錄 Agile Tour Taipei 2015 下午的議程筆記與心得。
下午選擇的是 Track 2，當時在午飯時間苦惱了一陣子，雖然一度很受到 Track 1「How to apply Agile to Growth Hack - Someda Takashi, 染田貴志」的議題吸引想要先聽 Track 1 再換場 Track 2，但 Track 2 的場地視野不佳、座位也少，考慮到換場一定搶不到好位子，因此最後整個下午都留在 Track 2。
邁向 Scrum of scrums - 杜秉穎
講者簡報已經釋出，可以前往線上觀看。
下午第一場是「邁向 Scrum of scrums - 杜秉穎」，但必須要先自首，因為精神不佳，在這場議程中一度陷入昏迷，所以記錄到的內容超少。
這場議程在劇情上是接續上午「如何在組織內有效引領敏捷變革 - 蕭存喻」的案例，也就是遊戲橘子內部的敏捷變革經驗分享。
首先講者向聽眾問了幾個問題：
團隊類型？ 是新創、公司自開發產品、接外包或其他。 團隊規模？ 5 ~ 50 以上是落在哪一個區間。 開發方法或流程？ 是 Waterfall、Being Agile、Doing Agile或自以為 Agile。 透過問題開場之後，講者開始進入正題，前面的題目也是講者在爲自己鋪梗，因為講者所處的團隊正是經歷由小變大與持續引入敏捷變革的過程。
在他們持續引入的中途遇到了一個狀況，即是乍看之下「團隊好像很 Agile」，感覺該做的都有做 (testing、CI、CD)，但隱約還是感覺有些問題，例如會議時間很長、沒效率且難以達成共識、對 sprint failed 好像沒感覺又好像很害怕。因此驅使他們決定新一波的敏捷改革。...
接續同系列文章《Agile Tour Taipei 2015 筆記與心得》，本文繼續記錄 Agile Tour Taipei 2015 上午第三場議程「從Agile到Lean Startup：趨勢的軟體開發之旅 - Jason L Lin」的筆記與心得。
從Agile到Lean Startup：趨勢的軟體開發之旅 - Jason L Lin
講師的簡報已經釋出，可以由此瀏覽。
第三場議程是由趨勢科技 SQA/SEPG 部門的林立仁為大家分享。講者在自我介紹時特別強調了 SQA/SEPG 部門，根據講者所言趨勢科技很重視軟體開發方法，因此 SEPG 部門的工作之一就是將一些優良的軟體開發實踐帶入公司之中。
趨勢科技推動這些實踐主要是由 Bottom-up 的方式進行，企業文化鼓勵員工做中學並勇敢嘗試錯誤。這種鼓勵學習、容許犯錯的企業文化不知道會戳中多少困在傳統企業文化的開發者？據說趨勢仍然有在徵人，有興趣者不妨可以考慮看看。
（提供一個對照組，上次在 iThome DevOps 2015 研討會中，Yahoo 就提到 Yahoo 推動 CD 時的方式就是 Top-down。）
簡報的前面兩頁是公司簡介，不過講者在提到「經營理念」時，特別強調了「自我提升、保持創新領先地位」，用這一點呼應為何趨勢會在企業內部大力推動導入 Agile 與 Lean statup及前面自我介紹提到企業內部會成立 SEPG 部門。一再的強調趨勢實在是一間鼓勵學習、創新的公司。
接著作為前情提要，講者先快速地介紹趨勢科技導入 Agile 的歷史，主要有幾個重點：
從 2007 年開始嘗試導入。 接著 Bottom-up 遍地開花。 目前已正式成為公司開發者的必讀準則。（但非強制遵守） 現在全公司約 60% 的專案有採用 Agile。 既然趨勢科技已經大幅度的導入 Agile 了，那麼是什麼原因導致趨勢科技仍需要接著導入 Lean startup 呢？主要是因為有下面幾個新的問題與挑戰：...
接續上篇文章《Agile Tour Taipei 2015 筆記與心得 (一)》，本文繼續記錄 Agile Tour Taipei 2015 上午第二場議程的筆記與心得：
如何在組織內有效引領敏捷變革 - Richard Hsiao, 蕭存喻
這場議程是屬於「經驗分享型」的內容，講者將過去的經驗歸納重點後，將過程中遭遇的狀況與經驗談一一向大家分享。整場簡報的主軸即是講者所處的團隊如何逐步引入 Agile 的心路歷程。
講師的簡報已經公佈上網，可以直接線上瀏覽。 同時 Agile Tour Taipei 2015 已經釋出錄影。
首先講者用一個問題及一張圖作為開場帶出主題「組織在引入敏捷時常見的阻礙爲何？」
這問題的答案有很多，有來自上層或下層的不同的阻礙，例如常見的阻礙有「如何說服老闆接受 Agile？」或「如何說服工程師開始寫測試？」⋯⋯，當然還有更複雜的阻礙。講師則利用簡報 P.3 的圖片作為說明。
圖片中的 X 軸代表的是 Autonomy 由低至高、Y 軸代表的是 Alignment 一樣是低至高。
那麼你的團隊是屬於哪一個象限呢？是左上角的象限，需要由上層下達明確的指令，團隊才能準確的依據指令行動；或是右上角的象限，同時具備高度 Alignment 與 Autonomy，上層只要提需出問題，團隊即能展現高度自治完成任務。又不幸的是左下角，上層與團隊是一整個渾沌的狀態？
以此開場之後，講師延伸提到了當年他有了一個機會可以開始在團隊中引入 Agile，而這個經驗帶來的第一個心得是「危機就是轉機」，但有一個重要前提是「你需要證明給其他人看」。
「危機就是轉機」這句話大家都能朗朗上口，可是現實社會並沒有這麼簡單。「轉機」來到不等於後面全都會一帆風順，等著看你落水的人比比皆是。所以「轉機」只是一個開始，讓你有機會能取得權責來解決問題。只有在你真正解決了問題，你才能贏得別人的信任，為自己開創新局。
接著講師開始分享過去團隊引入 Agile 的實際經歷，共分成三個階段。細節我就不多描述，因為閱讀簡報就足以說明其中 7~8 成的內容。
第一階段：
這是滿常聽見的一種團隊窘境。團隊處於將要發展並力求表現之時，卻遇到專案進展不順及新主管的介入干擾，面對此窘境想要有所突破，因此決定引入 Agile 嘗試帶來新的火花。
當然團隊不可能立馬全面 Agile，所以在此階段先從可運行的最小實踐開始，先嘗試在團隊中導入了一個 Scrum 看版與 Daily Scrum 會議。
而第一階段最寶貴的經驗是「透明度」！
Scrum 不是萬靈丹，不會因為導入 Scrum 就能讓已經延期的專案忽然變得準時。重要的是導入 Scrum 之後讓一切的資訊變得「透明」，在資訊公開且交流順暢的狀況之下，團隊都能了解明白目前的現狀，這有助建立團隊彼此（包含上層與下層之間）的信任。
第二階段：...
這次特別報名參加了 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，可以說是相當划算。 以上就是本次的「獵奇」案件，報告完畢！