SAIKURON 13.Ned

http://www.infoq.com/presentations/akka-streams?utm_source=infoq 心得 這位Viktor Klang講話方式與外型都很像我前同事XD，現在Akka除了可以提供不用管Thread的執行模型之外，還有Akka Stream可以提供處理資料的模型。其實我對Akka沒很熟啦，不過因為後來都是在寫Backend的關係，所以對Backend處理架構有興趣。看起來Akka Stream除了提供原本基於Actor的好處之外，還提供了對資料流更高階更有效率的抽象化架構，像是Source, Flow, Sink這樣的概念，以前在做M$的DirectShow就有接觸了，不過那個只是單機視訊播放。這個是處理數千數萬的資料流，應用的等級差很大。最後帶到Reactive Stream的概念，那個Dynamic Push-Pull Model看來真的是蠻屌，但應該還在發展中。話說現在typesafe也要改名成lightblend了，看來他們公司搞的技術都頗有看頭，希望他們Live long and Prosper！ 筆記 簡介Akka Akka: Simple message-oriented programming model for build reactive applications. 會用Scala demo因為可以顯示比較完整(!) 不需要考慮Share state, memory visibility, threads, locks, concurrent collections, thread notifications. 高CPU使用率, 低延遲, 高輸出, 有彈性 Supervisor hierarchy可以讓application有彈性 有個root actor當supervisor，管控其下的child actor，有問題就換掉，做得慢supervisor就找其他actor幫忙。 這種是製造業思維，被敏捷洗腦的我聽了有點OOXX，不過Akka處理message就是製造業沒錯啦… Akka的計算單位稱為Actor Actor有address, mailbox, current behavior, local storage Actor週期性的送出message...

http://www.infoq.com/presentations/immutable-servers-docker?utm_source=infoq&utm_medium=email&utm_campaign=03112016Seg3 心得 這篇也算是Docker官方業配文？這位法國來的Jerome Petazzoni講英文我意外蠻好懂的。所謂Immutable這個概念最常就是拿人體的細胞來比。聽起來是很有說服力啦。基本上這樣子的Deploy方式就很像修車模組化整批換掉，而且軟體是虛擬的，完全不會有什麼零件製造品質問題或是什麼物理性問題。而這個架構可以強迫設計者把Storage與Service分開，讓Service成為真正的Stateless，而Data與Service分開的速度部份，我覺得也不用擔心，現在幾乎所有雲端Solution都有Storage Service了，怕延遲就是要用In Mem Cache。我最驚豔的是，有side kick container這種東東呀！裝個Container在正在運作的Container旁邊就可以偷看網路與其它東西…Docker真的是越來越成熟了！不過缺點就是，幾乎什麼都要寫code，想要完成這樣子的架構就是要寫一堆configuration！然後就有比較高的學習曲線，然後就要引進版本管理機制，然後就要管理這些東西的複雜度，然後就要找更厲害的Engineer才能把東西搞好搞大！這樣其實對我們來講是好事啦！在IT界總有新觀念可學習，新東西可以玩~ 筆記 Never change what’t on a server 不要裝新的packages 不要upgrade原來的packages 不要移除或down grade原來的packages 就算有安全性問題！ 不要編輯configuraiton files 不要更新application的code! 如何upgrade 起一個全新的Server然後測試過沒問題之後換掉舊的 那新舊Server可以同時存在，寫DB怎辦？這可能又是一個只新增欄位與換Data Model才能解決的問題 避免server confiugration drift導致難以維護的結果。 導入Immutable Server的佈署...

InfoQ辦的2015 QCon，裡面的Session都很不錯呢！這次看的是： Microservices and the Art of Taming the Dependency Hell Monster http://www.infoq.com/presentations/microservices-dependencies?utm_source=infoq&utm_medium=email&utm_campaign=03112016Seg3 心得 Gilt是在歐洲美國都很有名的線上購物網站，尤其是折扣商品的銷售很猛，雖然我沒買過啦。看他們完全導入Micro Service的數量很驚人，而DB的選擇方式也是相當多元，基本上就是歷史因素以及各取所長。還有就是在Gilt裡，Play+Scala幾乎都是主流了！聽了這場，我覺得學Functional還是應該學Scala啦！裡面講到的Dependecy問題非常有感覺。只要軟體複雜度到一個程度，一定會出現這種問題，還好他們已經先把戰略佈置成Micro Service的形式了。各各擊破比起所有Application或Service大一統簡單。但Micro Service要能減緩Dependency Hell還是要靠REST Service，裡面提出的策略非常有用。就算是想用Remote API Call，這場Session也派的上用場。把Document當成一個產品，放到軟體生產流程裡面成為一個不可或缺的環節，這樣可以完全避免掉Document更新跟不上實作的問題！ 筆記 Gilt從Ruby+Memchache->PostgreSQL to Play+Scala->MicroService+Scala->Legacy Service->PostgreSQL Micro Service 156+個，Application Service 5~9個。 User service, 百萬user，10000 request 1秒，用mongo db(CP)存，有consistency 用Remote API呼叫，回傳Future！可以這樣用喔？ Catalog Service, 取所有product，5000 request 1秒，用postgreSQL...

話說最近正在讀《無瑕的程式碼》這本書，所以一直擺在手邊，三不五十就會瞄這本經典鉅作一下，不過最近眼花常會看錯書名... 當程式寫出來，功能完整，沒啥bug，自我感覺天下無敵的那一瞬間，就會看成「無敵」的程式碼 當不小心打開Open Source的專案原始碼時，一堆看不懂的程式碼在眼前，老鼠怎麼捲都捲不完，眼花撩亂的那一瞬間，就會看成「無窮」的程式碼 當看到某些函式訂了參數，傳進去卻沒用到，咒罵這分明是脫褲子放屁的那一瞬間，就會看成「無用」的程式碼 當看到某些大師的程式碼，想說來重構一下，以證明自己比大師更厲害，卻發覺完全沒地方下手，體會到大師果然厲害的那瞬間，就會看成「無缺」的程式碼 當看到某些程式碼模組交互呼叫，糾纏不清，你濃我濃時，想修個bug卻不知從何下手時，就會看成「無縫」的程式碼 當看到某些程式碼根本只是隨便寫寫，完全不考慮後續維護，魔術數字四散各地，變數名稱與流程邏輯完全對不上，改起來簡直想要跳樓，就會看成「無恥」的程式碼 當bug截止時間將到，知道錯誤在這段，卻完全沒有idea要怎麼改，就會看成「無望」的程式碼 當一直寫一樣的東西，絲毫沒有變化，感覺悶的要死時，就會看成「無趣」的程式碼 當看到某些程式碼內含一堆架構，實際上架構根本就沒做到什麼重要的事，完全是一個熱臉貼冷屁股的那一瞬間，就會看成「無感」的程式碼。 當程式碼架構設計的好，還貼心的附上完整的測試案例，要新增功能，要修bug都是一塊蛋糕，照著架構改好跑跑測試就搞定，感覺人生輕鬆愉快的那一瞬間，就會看成「無痛」的程式碼。 當看到好不容易重構後變得比較簡單的程式碼，一次又一次被加個阿紗布魯，天邊飛來的一朵邏輯的那一瞬間，就會看成「無力」的程式碼 當花了十年參透大師寫的那一行程式碼背後所隱含的大宇宙的奧秘的那一瞬間，就會看成「無極」的程式碼。 軟體進步到現在，開發測試部署全部都可以用程式碼控制，四輪傳動系統、行車主動安全系統，物聯網，OOXX什麼東西都會有程式碼存在，當我想到2XXX年還是有一堆人要寫程式碼的那一瞬間，就會看成「無限」的程式碼。 以上純屬嘴砲，我只是想表達這本書的中文標題，真的意義深遠...

我的BDD物語1 從開始使用TDD之後一年多，發覺不管是解Bug還是做Enhancement，沒有寫Test就會覺得全身不對勁，在這段期間，也看到了許多TDD進階到BDD的分享文章，像是 INTRODUCING BDD ，最有感的應該是這篇 WHAT’S IN A STORY? ，看了之後發覺原來寫User Story是很簡單的，有固定的格式，也可以很好的描述出系統的行為。之前看到那種厚重的文件裡面內含的Use Cases，我心想，到底這種文件誰會來維護，一定不是Developer...，不是Develper維護的結果就是文件跟不上code，基本上這種文件都要準備的很完整的形式，是給某些走 重裝 軟體流程的團隊，而我們寫code的時間都不夠了，哪有時間在那邊改一堆奇奇怪怪的Word、Excel、PDF。而以BDD的方式來作，只要寫出如下的Story: 就可以就寫Behavior Test，文件格式也很簡單，用普通文字檔就可以，也可以用Markdown之類的格式來呈現，在有需要與Product Owner或Feature Owner討論的時候就可以派的上用場，討論完馬上就可修改，寫Behavior Test時一想到其他Case也可以修改。 故事是這麼開始的 有了TDD的經驗與BDD的知識之後，我在開發N功能時就實際應用上去，N功能對我而言是有點莫名其妙的功能，感覺與我們系統的設計背道而馳，這部份我就不多說，總之，開了一次又一次的會，大概對實際需求有個譜，在還沒有開始寫Code之前，我就先寫出了一個又一個的User Story，其實撰寫User Story也沒辦法花太多時間，一開始大概一兩個下午斷斷續續就完成初版，由於系統裡還有很多面向，例如備份、升級、組態模板、事件、還有各式各樣的使用者行為，有些面向我也沒有實際接觸過，所以只能寫出User Story的Title。 接下來開始寫Code之後，我的方式是每個User Story對應一個Class，每個Scenario對應一個Test Method，每個Scenario都代表User的一個行為，當然也有系統因為狀態變化的行為。以TDD的方式來做，當然就是先把Test寫好，然後再去修改Production code裡面的內容，來滿足Test的結果。這個作法的好處在開發時我體會到幾項： 一邊寫會一邊思考...

最近有機會看RESTful API的設計，雖然自己沒有參與，但是也把握機會看了一遍。首先先從Http協定說起，Http協定不只用在傳輸Web的內容上，也有很多Client應用程式與Server溝通都使用Http協定，例如手機App，遊戲，甚至一些雲端的服務都是透過Http協定來提供服務。但是Http只是協定，至於要以什麼順序傳，傳什麼東西，其實都是自由的，所以也造成沒章法隨便亂寫的狀況，而REST風格是一個業界公認，我們自己也可以理解接受的一種解決方案。遵照REST的風格，做出來的架構因為Server不需要記錄執行狀態，所以天生就有較好的擴展性，簡單說，只要後端資料庫夠強，就可以一直水平擴充Web Server，透括負載分配進來Web Server的請求，就可讓支援使用者數量上到百萬。這就是無狀態設計屌的地方。 其實我家老大找到的這篇，就已經完整說明設計RESTful API各種要注意的地方： http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api 以下是個人簡單的筆記： 透過Http協定來提供服務有以下好處： Http協定已經是一個成熟穩定的傳輸協定，累積了業界的經驗，而且有許多的Http Server支援，不用自己再打造協定，只須選擇一種Http Server來使用，並把應用程式佈署進去。 Client端也有許多現成的Open Source實作，不需自行打造穩定可靠的Client端 協定都是以文字為主，理解與除錯較簡單 至於傳輸內容部份，應用程式相關資料，目前業界都是使用肉眼可讀的JSON，怕字串容量過大，各家http server都有現成的工具可壓縮。 安全部份有https可以使用，加密也不需自行處理，可以使用Open Source的Solution Http本身也支援Cache機制，善加利用對於處理大量讀取需求也會很有幫助。 REST：Representational State Transfer，含狀態傳輸，來自Roy Fielding博士的論文 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 是一種軟體架構風格，在目前的Web Service實現方...

來源： http://paulhammant.com/blog/branch_by_abstraction.html 接下來就看看Branch By Abstraction有多厲害，實際看下來，的確是一套很有用的方法，簡單來說，就是把整合的工分散到每日的開發中。但是要實行有一些現實的問題需要克服 當我要新加一個Feature，會改動3個Class，這3個Class可能所有Module都要參考，而且與其它Module的Code綁很緊，要抽成Abstraction要改動的地方也是會很多，根本就是翻了。 就算我做好抽象層，把所有Module參考到這三個Class的地方改為呼叫抽象層，這樣還是對Code有變動，也是有可能對產品造成衝擊。 如果這3個Class的修改連介面都換掉，整個Class改頭換面，煥然一新，原來的使用流程已經不在，就算有抽象層當緩衝，還是免不了對產品造成衝擊。 這些現實的問題，我想是可以克服的，第一就是要有完整的Test，Unit Test，Integration Test，UI Test，但是如果Test不夠完整，可以使用這招嗎？我想答案是肯定的，但是要邊做邊補Test。而沒有任何Feature Branch，大家都只看Trunk，也就是mainline，這件事對目前的我而言，簡直就是美麗的夢境！我自己參與的產品就有遇到這種狀況，目前是分支一個Branch來做，如果用Branch By Abstraction，新的東西就可以不用等好幾個版本之後才進mainline，也不用擔心如果合併回mainline，到底會是怎麼樣的地獄。如果我有機會參與決策，我一定直接就這麼搞。 另一點作者提到除了Release之外，完全沒有其它Branch，這點我還是有點存疑，除非有一套機制讓Developer拿著Commit去取得認證，保證不會Break掉任何東西。不然Developer自己一個人做測試還是有限，如何保證不Break mainline？如果一個產品的開發編制如下： 100個Developer 分成15個Team，有的Team人多，有的Team人少 25個Component，從Web UI，Mobile UI，Database，Domain，Infranstructure..... 有跨Component，跨Team修...