ocowchun

1.reactv15

React v15發佈了，主要的重大更新包含:

1. 不支援IE8
2. 不再需要react-id(前端）
3. 純文字不會需要額外的span

2.continuous delivery

這本書討論談持續交付的觀念與實作，目前看了兩章。 書中提到了持續交付的目標是: 快速且可靠的遞交有價值的軟體 為了做到上述的目標，所以需要進行一系列的活動來改善現有的部署流程。 我對交付的理解是:將完成的程式碼部署到生產環境(production)或是staging的一系列動作，包括軟體的建置，環境的建置，環境參數的設置，軟體的測試與回饋，這些都是交付過程的一部分。

目標可以根據兩個原則: 1. 自動化 2. 頻繁 來達到，沒有自動化交付就很難達到頻繁交付(每次交付都需要專家手動執行，極容易出錯，也很難重複)，而頻繁交付才能儘早獲得回饋(發現錯誤,發現需要的功能,發現錯誤的環境設置…etc)

其中有一段話我覺得很有意思 提前並頻繁進行令你感到痛苦的事 仔細想想其實這是一句很有智慧的話，透過頻繁進行令你感到痛苦的事，逼你去正視問題，有可能透過將問題拆解成小問題的方式來解決問題，又或是使用其他的方式來避免問題的再次發生，是一件很有意思的事情。

持續交付(continuous delivery)執行得好的組織可以在任何時刻輕鬆的將特定版本的應用程式部署到任意環境，對於目前的我們來說還有很長的路要走。

3.AWS Lambda

最近在研究AWS Lambda整合 API Gateway使用AWS Lambda的好處在於，這是真正的完全不用管理基礎建設，所以稱之為 serverless ，開發者只需要專注在每個function就好了，也因此衍生出新的計價模式，按照請求的數目與請求的執行時間來計費。

開發AWS Lambda時使用Apex，來管理function，有了Apex你就可以快速無腦地部署跟測試function，function開發完成之後再使用Terraform來整合AWS Lambda與API Gateway，不過目前有些API Gateway的設置參數還沒有實作完全，這時候就必須自己透過AWS SDK來補齊。設置完成之後會透過CloudWatch來監控使用資源(Lambda的執行時間,請求數,log,error…)，ref，API Gateway還可以將環境變數作容易的控管

相關的連結

Apex:管理 AWS Lambda的工具，協助部署與管理你的functions

serverless: Serverless Framework — Build web, mobile and IoT applications with serverless architectures via AWS Lambda and API Gateway

Pahud Hsieh: 一位專研很多 AWS 相關服務的大大

Henry

1. fastlane

fastlane 可以類比成行動平台的 capistrano，主要的兩大平台 iOS、Android 都有支援。fastlane 由好幾支工具組成，fastlane 指令本身只負責將參數轉送給這些工具。從 測試、編譯、後勤支援 (e.g. 螢幕截圖、更新 app 資訊) 到 打包、上傳 Testflight，甚至最後 送審上架 都可以透過 fastlane 完成。

fastlane 的主體與設定檔採用 Ruby 開發，開發前請注意機器上是否有安裝 Ruby。

這次主要使用到的 fastlane 元件有 match、gym 跟 pilot，分別介紹如下。

A. match

透過 Git 管理開發時使用的各類憑證：

1. private key 存取 Apple 開發者平台所需的私鑰。
2. certificates app 的身分證。
3. provisioning profiles 與開發環境連動的設定檔，主要分為 development (開發用) 與 ad-hoc (內部測試時使用，在這次 app 開發中被 Testflight 取代)。

有開發過 iOS 的工程師大概都經歷過管理這些憑證的痛苦，match 透過 Git repository 配合 spaceship (fastlane 團隊實作的 Apple Developer Portal API)，將這些憑證的簽發與同步的工作透過一個 match 指令完成。

因為一支 Git repository 保存的只有與 app 有關的 certificates 與 provisioning profiles，因此 *一支 repository 對應一支 app*，也就是開發團隊的所有成員如果要參與開發都是 同步同一支 Git repository。

至於 match 的安全性：

1. *match 強烈建議使用者將使用 private repository 管理憑證*，可以大幅降低資安風險。
2. *簽發憑證時 match 會要求使用者輸入 passphrase 做加密*，因此即使 repository 被入侵，如果 passphrase 的強度足夠有心人士短期內也很難解鎖，相對也可以幫團隊爭取到更換憑證的時間。
3. *private key 透過 Mac 的 Keychain 工具程式保存在本機上*，不會同步到 Git repository。所以惡意人士即使取得 repository 的控制權，也無從偽裝成開發者的身份進一步控制 Apple 開發者帳號。

B. gym

由於 Xcode 的 command line 編譯指令十分複雜：

$ xcodebuild clean archive -archivePath build/MyApp \
                           -scheme MyApp
$ xcodebuild -exportArchive \
             -exportFormat ipa \
             -archivePath "build/MyApp.xcarchive" \
             -exportPath "build/MyApp.ipa" \
             -exportProvisioningProfile "ProvisioningProfileName"

透過 gym 則可以大幅降低編譯的指令長度：

$ gym

但卻不失彈性：

$ gym --workspace "Example.xcworkspace" --scheme "AppName" --clean

C. pilot

pilot 負責將 app 打包、簽呈 (將憑證包入 app) 並 上傳 到 iTunes Connect。

iTunes Connect 可以想成是 iTunes 的後台，所有 app 的 測試、送審 與 發布 都在 iTunes Connect 上解決。app 上傳後，已加入該 app Testflight 測試計畫的使用者都會收到更新通知。

2. Testflight

原來是獨立一家公司，主要業務是 iOS app 的測試服務，之後被 Apple 收購。透過 Testflight，Apple 開發者可以邀請 不具備 Apple 開發者身份 的非開發人員或特定客戶，透過 Testflight app 加入 app 的測試流程。

3. recompose

這算是從 React 衍生出來的一套工具程式，在 React ecosystem 中與 Redux 同級。

Forget ES6 classes vs. createClass().

An idiomatic React application consists mostly of function components.

-- recompose

recompose 希望透過 high-order functions 與 functional programming 的實作 (curry、compose 等函數包裝方法) ，而不是 ES6 的 class 操作 React component。

簡而言之，一個 high-order function 就是一個 component。

原來想透過 Redux 重寫 app 的主體架構，順便將排版的 flexbox 從頭到尾整理一次，為接下來串接 API 做準備。打開 Redux 的文件才發現 Redux 有很大一部分的實作都已經非常地 *functionalized*，這才想起之前看過的 recompose，想說如果 Redux 都被 functionalized 了不如直接使用 recompose，API 也比 Redux 簡潔許多。

唯一要注意的是 component 的 lifecycle 在 recompose 中被 implicated 了，很容易不小心就在 render 的部分改動了 state。由於之後的動畫的啟動與重新繪製很容易去踩到這條不明顯的界線，要如何分割 component 是接下來要研究的部分。

Kalan

1. 關於爛 code 的那些事

中

下

上個禮拜的 bug 還有勞科科了🙏。我也順便在網路上找了篇相關文章，算是給自己一個警惕。

寫爛 code 是無法避免的事情，跟寫程式或多或少一定有 bug 是一樣的道理。但重點是如何減少寫爛 code 的次數以及出錯的機率。 這篇文章寫得挺棒的。把一些常見的爛 code 類型、何謂爛 code、何謂好 code，以及一些常見的情景都很詳細地記錄下來了。 最後一篇是描述如何透過實際的行為來提高自己的代碼質量，個人覺得最重要的是以下幾點： 1. 只重構經常修改的部分 2. 刪除無用代碼是提高代碼可維護性最有效的方式 3. 統一環境

讓我們一起往高品質的 code 邁進吧！

2. Postcss

為什麼 postcss 會如此竄紅呢？當初自己玩了一下，發覺其實跟 sass 沒有太大的差別，想要的功能實現靠 sass 也都可以實現。 不過 postcss 的強大之處在於他能夠客製化任何你想要的 function，還有大量的 plugin 幫助你省下不少工夫重造輪子。 而且對我來說最開心的是他能夠支援 cssnext 的語法。（就像是 css 界中的 es6）

搭配 gulp 或 webpack 的幫忙要套用在專案當中其實並不難。不過對於主站來說最大的問題就是 postCSS 並沒有支援 rails 的 sprocket，而我們有用 erb 的方式來放一些 background-image 的部分。所以真正要套用到 production 或許還要一些時間或者只能含淚捨棄也說不定。postCSS 也發布一則推文說：「很抱歉，如果想要用在 rails 上你就只能用 gulp 或 webpack」

3. ServiceWorker

最剛開始的 XMLHttpRequest 到 jQuery 的 ajax 封裝，到了現在透過 fetch 的方式。不得不驚嘆時代的變遷，以及瀏覽器不斷在應用層面思考功能的拓展性。 promise 這個模式非常成功了解決 callback 和狀態的問題。身為一位有 promise 的男人，怎麼能夠不愛上呢？

fetch 不但功能齊全，而且 API 非常好用，而且還提供了對 header 的修改操作，幾乎可以利用 service worker 的方式來達到 http server 的基本功能。而 service worker 也提供了未來開發的模式許多想像空間，包括前後端分離 graphQL 實踐等等

當然目前的 fetch API 還是有一點小缺陷。無法支援進度顯示、abort 請求、也沒有 timeout 處理。

4. 關於事件綁定：

最近在思考事件綁定這件事情。 jQuery 提供了事件委託的功能，之前一直沒注意到呢！ 當容器內的元素觸發事件時，就會冒泡到容器上。此時可以判斷事件的源頭是誰，再執行對應的事件處理函數。由於事件處理函數是綁定在容器元素上的，即使容器為空也沒有關係；只要容器的內容添加進來，整個功能就是準備就緒的。

$ ( ' .tabs > a ' ). on ( ' click ' , function () {
     var htmlTemplate = [
         ' <div> ' ,
             ' <button id="lucky-draw">Lucky Draw</button> ' ,
         ' </div> ' 
    ]. join ( ' ' )
     $ ( ' .tab-panels' ). html (htmlSurpriseTab)

    // BTN READY 
})

這樣子我的事件綁定就一定要寫在 btn ready 那邊，造成了高度耦合。但今天如果用事件委託的方式：

$ ( document . body ). on ( ' click ' , ' #lucky-draw ' , function () {
 // do something
})

在最上層指定 onclick 事件並且委託，這樣接口比較統一，耦合性也不會那麼高了。就算 #lucky-draw不存在也沒關係。

Peter

Font In Use

這週來介紹一個網站「Fonts In Use」愛字人千萬莫錯過。 顧名思義，這是一個有關英文字型應用的網站， 網站以專案、作品的方式呈現英文字型。 網站內透過三個類別供使用者探索、尋找字型： 1. 產業 2. 形式（作品的形式，例如：書、廣告等） 3. 字型應用的類別（適用於新聞標題、唱片封面等等）

設計師設計時常常被選字兩難傷透腦筋， 不然就是毫無頭緒，不知道該使用哪種字型， 這些問題都可以在 Font In Use 找到解答或靈感。

而 Font In Use 也有部落格，別懷疑 部落格每一篇文章都會以某個字型為題目 有時候以專案的形式討論的是該字型如何應用， 有時候是討論字型的設計， 這些都是非常難得的設計經驗，愛字的人趕快看看吧！