五倍直播間

Blogs - Sidebar


專案中很常出現按鈕點下跳出 "確認視窗" 的行為，有時候是刪除的警告確認、有時候是資料送出的確認。這些有共同操作行為的 Component 都應該做成共用的元件以方便在各種情況下重複使用， 才不會某 A 做一個版本，某 B 做另一個版本，大家都自己寫自己的造成維護上的困難。

此文章不會詳細列出各項程式碼，如果有興趣可以 clone [source code](https://github.com/treekey999/react-promise-modal-example) 下來研究研究。

封面圖來源：[https://mrdoob.com/lab/javascript/effects/ie6/](https://mrdoob.com/lab/javascript/effects/ie6/)

---

期望可以用以下程式碼達到我要的目的：

```jsx
import React from 'react'

import { confirmBox } from './promiseModal'

class App extends React.Component {
  render() {
    <button
      onClick={() => {
        confirmBox({
          title: 'Logout',
          description: 'Are you sure to logout?',
        }).then(() => {
          console.log('Confirm, Do some logout action...')
        }).catch(() => {
          console.log('Cancel, Nothing happened...')  
        })
      }}
    >
      Logout
    </button>
  }
}

```

`confirmbox` 執行並帶入客製化 params，期望最後會回傳 `promise` 物件，並由 `.then()` 或是 `.catch()` 來知道使用者點下 `Confirm` 還是 `Cancel` 再做後續的動作。

---

### 實作步驟分析

* 準備一個基本的 popup modal component（確認視窗）。

* 因為 modal 是一個蓋版視窗，使用者必須要按下 `Confirm` 或 `Cancel` 按鈕才能繼續操作，所以選擇使用 `Promise` 物件來等待使用者按下按鈕。

* 執行 `confirmBox` 的時候，預期會 create 一個 `promise` 物件，並在裡面將 React Component 掛載到某個 div 上面(`ReactDOM.render`)，並將 `resolve`、`reject` function 當作 props 一併傳到 modal 中使用。

* 因為 modal 擁有了 `resolve`、`reject` 這兩個可以繼續 `promise` 的 function，所以可以在按下 `Confirm` 按鈕的時候呼叫 `resolve`，按下 `Cancel` 按鈕的時候呼叫 `reject` 來達成 `Promise Chain` 的目的。

* 無論按下哪一個按鈕後都應該要清除、卸載，動態掛上去的 React Component。

* 以下解說都會省略 css code, 有興趣可以看 [source code](https://github.com/treekey999/react-promise-modal-example/commits/master)

---

### Step 0. 準備範例按鈕

```jsx
class App extends Component {
  render() {
    return (
      <div className="App">
        <button
          type='button'
          className='btn-example logout'
        >
          Logout
        </button>

        <button
          type='button'
          className='btn-example submit'
        >
          Submit
        </button>

        <button
          type='button'
          className='btn-example delete'
        >
          Destroy
        </button>
      </div>
    );
  }
}
```

![post-React Promise Modal](//images.ctfassets.net/8er52l3j5u76/7ELSNkT1Mp68uD5EOFVEW0/5db4be62d877273c8c463acc58ad802c/hChnSKR.png)

---

### Step 1. 準備基本 popup modal

使用 [react-modal](https://github.com/reactjs/react-modal) 來快速建造一個確認視窗的 modal。

```jsx
import React, { useState } from 'react'
import PropTypes from 'prop-types'
import Modal from 'react-modal'

const ConfirmBox = (props) => {
  const {
    color, // 客製化顏色
    title, // 客製化文字
    description, // 客製化文字
    onConfirm, // 預期收到 resolve function
    onCancel, // 預期收到 reject function
    confirmText, // 客製化文字
    cancelText, // 客製化文字
  } = props

  // `useState` 是 react 16.8 新功能 hooks, 等同於 state/setState 效果
  // 初始值為 true
  const [isOpen, setIsOpen] = useState(true) 

  const onClickConfirm = () => {
    // 按下 Confirm 將 modal 關閉, 並執行 onConfirm (resolve function)
    setIsOpen(false)
    onConfirm()
  }

  const onClickCancel = () => {
    // 按下 Confirm 將 modal 關閉, 並執行 onCancel (reject function)
    setIsOpen(false)
    onCancel()
  }

  return (
    <Modal
      overlayClassName='promise-modal-overlay'
      className='confirm-box'
      isOpen={isOpen}
      onRequestClose={onClickCancel} // 點下 modal 之外的區域時觸發 (modal overlay)
      shouldReturnFocusAfterClose={false}
    >
     <div className={`modal-container color-${color}`}>

      <div className='modal-header'>
        <h3>{ title }</h3>
        <button
          type='button'
          className='close-btn'
          onClick={onClickCancel}
        >
          X
        </button>
      </div>

      <div className='modal-content'>
        <p>{ description }</p>
        <div className='button-list'>
          <button
            type='button'
            className='cancel'
            onClick={onClickCancel}
          >
            { cancelText }
          </button>
          <button
            type='button'
            className='confirm'
            onClick={() => onClickConfirm()}
          >
            { confirmText }
          </button>
        </div>
      </div>
     </div> 
    </Modal>
  )
}

```

測試一下剛剛做的 Component Render 有沒有正確，丟到測試頁面看看 js/css 有沒有正確。

![](https://i.imgur.com/v5jsT8W.png)

---

### Step 2. 製作 Promise function

流程可以拆分為以下：

  * 動態產生不重複的 div element，為了讓 `ReactDom.render` 掛載上去。
  * new 一個 `Promise` 物件，並在第一個 promise 裡面將 `Modal Component` 掛載上去。
  * 成功 render React Modal 之後就會在介面上看到蓋版 Modal，並等待使用者按下按鈕之後接續呼叫 `resolve`、`reject` function。
  * 卸載、移除先前動態產生的 Component、Element。

```jsx
import React from 'react'
import ReactDOM from 'react-dom'
import Modal from 'react-modal'

// 卸載、移除先前動態產生的 Component、Element
const unsetPromiseModal = (wrapper) => {
  setTimeout(() => {
    ReactDOM.unmountComponentAtNode(wrapper)
    wrapper.remove()
  }, 300)
}

// 動態產生不重複的 div element
const findOrCreateWrapper = (identifyID) => {
  let wrapper = document.getElementById(identifyID)
  if (wrapper === null) {
    wrapper = document.body.appendChild(document.createElement('div'))
    wrapper.id = identifyID
  }
  return wrapper
}

// params 預期接收要被掛載的 Component, 跟客製化 options
const promisableModal = (Component, options = {}) => {

  // 動態產生不重複的 div element
  const wrapper = findOrCreateWrapper(`promise-modal-wrapper-${Date.now()}`)

  // 無障礙網頁辨識用, 參考：http://reactcommunity.org/react-modal/accessibility/#
  Modal.setAppElement(wrapper)

  const promise = new Promise((resolve, reject) => {
    ReactDOM.render( // 掛載 React Component
      <Component
        {...options} // 帶入客製化參數(props)
        onConfirm={resolve} // resolve 傳給 onConfirm
        onCancel={reject} // reject 傳給 onCancel
      />,
      wrapper,
    )
  })

  return promise.then(() => {
    // 使用者按下 Confirm 之後執行此段
    unsetPromiseModal(wrapper)
    return true
  }, () => {
    // 使用者按下 Cancel 之後執行此段
    unsetPromiseModal(wrapper)
    return Promise.reject(false)
  })
}

export default promisableModal

```

由於最後回傳的是一個 `promise` 物件，如果接續著呼叫 `.then()` 會在使用者按下 `Confirm` 後接續執行；如果接續著呼叫 `.catch()` 會在使用者按下 `Cancel` 後接續執行。

---

### Step 3. 組合

```jsx
import './style.scss' // base modal overlay csss

import promisableModal from './promisableModal'
import ConfirmBox from './components/ConfirmBox'

// 將 ConfirmBox 和 promisableModal 做組合
const confirmBox = props => promisableModal(ConfirmBox, props)

export {
  promisableModal,
  confirmBox,
}
```

因為已經寫好了可以 `promisable` 的 function，所以未來如果想要擴充其他種類型的 modal，都可以透過 `promisable` 輸出，例如未來我如果想做一個編輯蓋版視窗：

```jsx=

... 省略

import EditBox from './components/EditBox'

const editBox = props => promisableModal(EditBox, props)

export {
  promisableModal,
  confirmBox,
  editBox, // 新的擴充
}

```

---

### Step 4. 使用

三種不同情境的確認視窗，都只要呼叫同一個 promise function 來達成目的，達到 reuse 的目的。

```jsx
import React, { Component } from 'react'
import './App.scss'

import { confirmBox } from './promiseModal'

class App extends Component {
  render() {
    return (
      <div className="App">
        <button
          type='button'
          className='btn-example logout'
          onClick={() => {
            confirmBox({
              color: 'primary',
              title: 'Logout',
              description: 'Are you sure to logout?',
            }).then(() => {
              console.log('%c Click Confirm!, prepare to logout ...', 'color: blue')
            }).catch(() => {
              console.log('%c Click Cancel!, nothing happened ...', 'color: blue')
            }) 
          }}
        >
          Logout
        </button>

        <button
          type='button'
          className='btn-example submit'
          onClick={() => {
            confirmBox({
              color: 'info',
              title: 'Submit Form',
              description: 'Are you sure to submit form?',
              confirmText: 'Submit',
            }).then(() => {
              console.log('%c Click Confirm!, prepare to fetch data to backend api ...', 'color: green')
            }).catch(() => {
              console.log('%c Click Cancel!, nothing happened ...', 'color: green')
            }) 
          }}
        >
          Submit
        </button>

        <button
          type='button'
          className='btn-example delete'
          onClick={() => {
            confirmBox({
              color: 'danger',
              title: 'Delete Product',
              description: 'Are you sure to delete this product?',
              confirmText: 'Delete',
            }).then(() => {
              console.log('%c Click Confirm!, prepare to fetch data to delete product ...', 'color: red')
            }).catch(() => {
              console.log('%c Click Cancel!, nothing happened ...', 'color: red')
            }) 
          }}
        >
          Destroy
        </button>
      </div>
    );
  }
}
```

![](https://i.imgur.com/acalG7Y.gif)

---

Don't Repeat Yourself，這個範例的元件在我先前的幾份專案中都有用到，而且都只是複製最初的那一份出來調整 css 而已。

寫 React 的時候不妨思考一下專案中哪些是常常共用的元件，試著練習抽離出來做成 shared component，會省下未來不少時間。

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 React 觀念和原理嗎？
>
> 我們有開設 💠 [React 全攻略入門班](https://5xruby.tw/courses/react) 課程唷 ❤️️
>


post-React Promise Modal

React Promise Modal


[calc()][0] 是一個 CSS function 作用於屬性設定是數值的時候可以進行加減乘除的運算，例如： `<length> 長度`、`<frequency> 頻率`、`<angle> 角度`、`<time> 時間`、`<number> 數字`或者是 `<integer> 整數`這幾個屬性值都可以使用 `calc()`。

```css
/* property: calc(expression) */
/* 屬性: calc(運算式) */
width: calc(100% - 50px);
```

## calc() 語法

calc() 這個 function 需要傳入 1 個加減乘除的運算式，在設定 `width`、`height` 這種 \<length\> 相關的屬性時， 在不同單位間也可以進行運算，如剛剛上面的範例：`width: calc(100% - 50px);`。calc() 的運算式一樣是按照先乘除後加減進行計算，如果需要進行複雜的運算，在 calc() 裡面也可以再加入括號 `()`，就可以設為括號先決裡面的先算。

- `+`：加
- `-`：減
- `*`：乘。其中一個運算參數必須是數字 (number)
- `/`：除。除數必須是數字，除數不可為零，會造成 HTML 解析錯誤。

必須注意在使用 + 和 - 的時候，在前後一定要加上空白，不然會被誤為是給了個負值。* 和 / 可以不用加，但為了格式統一方便和閱讀建議還是加一下。

```css
width: calc(50% + 8px)
/* 意思是 50% 的寬度 + 上 8px */
width: calc(50% + -8px)
/* 意思是 50% 的寬度 + 上 -8px，也等於 '50% - 8px' */
```

## Example 應用範例

### 定位

calc() 可以用來定位，如下面所設定的 CSS，就能作出一個滿版的藍色 banner 區塊有固定 40px 的邊距，也是一種將區塊置中的寫法。

```css
.banner {
  position: absolute;
  left: calc(40px);
  width: calc(100% - 80px);
  background-color: #6C92AF;
  padding: 6px 0;
  text-align: center;
  color: #FFF;
}
```

```html
<div class="banner">Hello banner/div>
```

<p data-height="265" data-theme-id="light" data-slug-hash="PEgoZq" data-default-tab="css,result" data-user="fokayx" data-embed-version="2" data-pen-title="CSS_calc" class="codepen">See the Pen <a href="https://codepen.io/fokayx/pen/PEgoZq/">CSS_calc</a> by fokayx (<a href="https://codepen.io/fokayx">@fokayx</a>) on <a href="https://codepen.io">CodePen</a>.</p>
<script async src="https://production-assets.codepen.io/assets/embed/ei.js"></script>

### 根據父層容器尺寸自動調整尺寸

設定 width 或 height 屬性使用 calc() 計算的數字是 100% 的時候，會自動去抓父層容器的尺寸。例如：做 autocomplete 的時候，希望在輸入框下，出現和輸入框等寬的列表：

```css
.container1 {
  width: 30%;
}

input {
  width: 100%;
  padding-left: 1rem;
  padding-right: 1rem;
  padding-top: 1rem;
  padding-bottom: 1rem;
  margin: 0;
  border-left: 2px solid #6c92af;
  border-right: 2px solid #6c92af;
  border-top: 2px solid #6c92af;
  border-bottom: 2px solid #6c92af;
}

ul {
  background-color: #6c92af;
  margin: 0;
  padding: 0;
  width: calc(100% + 1rem + 1rem + 2px + 2px);
  color: #FFF;
  list-style: none;
}
```

```html
<div class="container1">
  <input placeholder='container1'/>
  <ul>
    <li>show item 1</li>
    <li>show item 2</li>
    <li>show item 3</li>
  </ul>
</div>
```

由於 CSS 在加上 border、padding 的時候都是從原本設定得尺寸再往外加，所以長出來的東西看起來的尺寸會比原本設定的 width 還要大，因此要做到 ul 和 input 等寬的結果，在 input 加上的 padding 和 border 在算 ul 的 width 的時候也要幫他算進去，所以 `ul { width: calc(100% + 1rem + 1rem + 2px + 2px); }` 指的是：符合父容器的 100% 寬度，加上 input 的 `padding-left: 1rem` 和 `padding-right: 1rem`，再加上 `border-left: 2px` 和 `border-right: 2px`。用 calc() 計算尺寸非常方便，即使不同單位也沒有問題。如：codepen 第一個區塊。

如果在 ul 有設定 border、padding，ul 自己也會長大，在 calc() 計算的時候就必須扣掉這部份，例如：codepen 第二個區塊。

```css
.container2 {
  width: 30%;
}

.container2 input {
  width: 100%;
  padding-left: 1rem;
  padding-right: 1rem;
  padding-top: 1rem;
  padding-bottom: 1rem;
  margin: 0;
  border-left: 2px solid #6c92af;
  border-right: 2px solid #6c92af;
  border-top: 2px solid #6c92af;
  border-bottom: 2px solid #6c92af;
}

.container2 ul {
  background-color: #6c92af;
  margin: 0;
  padding: 0;
  border: 1px solid #212c35;
  width: calc(100% + 1px + 1px);
  color: #FFF;
  list-style: none;
}
```

```html
<div class="container2">
  <input placeholder='container2'/>
  <ul>
    <li>show item 1</li>
    <li>show item 2</li>
    <li>show item 3</li>
  </ul>
</div>
```

<p data-height="265" data-theme-id="light" data-slug-hash="JMqyyP" data-default-tab="css,result" data-user="fokayx" data-embed-version="2" data-pen-title="css_calc_ex2" class="codepen">See the Pen <a href="https://codepen.io/fokayx/pen/JMqyyP/">css_calc_ex2</a> by fokayx (<a href="https://codepen.io/fokayx">@fokayx</a>) on <a href="https://codepen.io">CodePen</a>.</p>
<script async src="https://production-assets.codepen.io/assets/embed/ei.js"></script>

### 將 calc() 巢狀包入 CSS 變數中

只要用括號 () 包好包滿，就可以無限次使用 calc() 方法，會一層一層從括號裡面計算出來。

```css
.foo {
  --widthA: 100px;
  --widthB: calc(var(--widthA) / 2);
  --widthC: calc(var(--widthB) / 2);
  width: var(--widthC);
}
```

在上面這段程式碼裡面展開所有變數之後 widthC 就等於：

`--widthC: calc( calc( 100px / 2) / 2)`

所以 .foo 的 width 最後算出來的值就是 25px。

[0]: https://developer.mozilla.org/zh-TW/docs/Web/CSS/calc 'calc at mdn'

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 HTML / CSS 觀念和原理嗎？
>
> 我們有開設 🪁 [HTML 網頁設計新手村](https://5xruby.tw/courses/html) 課程唷 ❤️️
>


post-CSS： calc() 數值運算 / css calc xuemei

CSS： calc() 數值運算

最近因為參加聚會聽到了在不同領域擔任專案管理的分享，談到專案管理過程中幾個共通的問題，剛好趁這個機會，想回顧一下，這兩年內學會了什麼，心態上又改變了什麼？於是整理出五件我覺得改變我工作方式的重要小事

1. 事情分輕重緩急，追蹤問題
2. 學習談判，細心與耐心
3. 專案的建議，但把選擇權交回客戶
4. 建立團隊從小原則開始
5. 抓好時間管理，讓客戶感受到被重視

### 1. 事情分輕重緩急，追蹤問題

> 剛開始做 PM 工作的第一個月，每一封信每一個對話我都回的戰戰兢兢，深怕遺漏掉任何事情，只要客戶一問「這東西進度怎麼樣啦？」我就會緊張的跑到工程師旁邊問他所以進度怎麼樣，弄的大家都很緊張...

雖然說工作上是以客為尊，快速的回應會讓顧客有好印象，但若只為了這樣而中斷自己甚至工程師的工作時，就可以停下來想一下客戶提出來的問題是不是真的這麼的迫切？

適時的讓客戶知道，我們已經收到你提出來的疑問了，並且會盡快為他處理這些問題
也因此 PM 身上也會一串長長的追蹤事項，每天固定找一個時間，重新檢視一次今天需要追蹤的問題，把處理掉的問題劃掉，

### 2. 學習談判，細心與耐心

PM 其中一個重要的工作在於如何溝通協調，對外我們要判斷需求，並適時的給予客戶專業建議、對內需要學著跟工程師協調任務的先後順序，這也是為什麼大家常說 PM 學著說不同的話，在面對不同領域的人有著不一樣的腦袋，如何聽懂對方的話、使彼此交流順常，找出最適的解決方案，溝通是專案管理最重要的軟實力。

關於協調與談判，我自己的心得是可以從耐心的傾聽以及換位思考開始練習，在 <卡內基溝通與人際關係：如何贏取友誼與影響他人> 書中，戴爾‧卡內基（Dale Carnegie）曾提到，假如你在職場上只學會一樣東西，就是能從自己與別人的角度思考、去看事情，那很有可能是你人生、事業成功的踏腳石。

### 3. 專案的建議，但把選擇權交回客戶

>「這樣不行，那樣不好，不然你告訴我你覺得怎麼樣才行？」

從第二點延伸，許多時候客戶會提出不太明確的需求或是天馬行空的想法，在我們傾聽完客戶的需求後，對於一些複雜的需求我們可能將需求帶回去在和工程師討論可行的方案，而最後我們可以怎麼呈現給客戶？

在想解決方案的過程中透過換位思考的方式，重新站在客戶考量他的需求，這裡的需求有時不單只是產品需求，還有成本、時間的考量也要加在這當中，透過提案的方式，列出可行的解決方案的優缺點後、需要開發的時間、成本後，將最後的選擇權交回給客戶。

透過良好的表達方式呈現我們解決問題的專業，同時也尊重客戶的選擇，除了能把問題解決之外最重要的是贏得客戶的信任。做 PM 給我一個很大的訓練是，我們得先聽懂並且了解對方的需求，在以專業的建議表達自己的需求，從中找尋交集的解決方式，就可以創造雙贏。

### 4.  建立團隊從小原則開始

理想上我們都希望能待在一個好的團隊，團隊裡的成員會自發性的去學習、並且積極地完成工作。但有時就算很幸運的遇上一群擁有很高熱忱的成員，若能有一些小的原則在這團隊當中發酵，更能將大家的力量凝結起來，發揮團隊最大的作用。

我覺得可以從每日的站立會議開始

站立會議其實是 Scrum（敏捷軟體開發過程）中的一部份，但我自己的心得是不一定只能用在 Scrum 的專案中 (畢竟不是每個專案都適合 scrum) ，每日的站立會議，能夠讓團隊成員有更多時間專注在工作上，同時也讓 PM 更輕鬆、即時地掌握實際情報

有效的站立會議我覺得有幾個要點：

  *  每天固定的時間
  *  會議時間不超過 15 分鐘
  *  一次只有一個人發言，並只針對三個重點說明，包括「昨天完成了哪些任務」、「今天的預計要執行的任務」、「碰到的問題」
  *  遠端的工程師可使用一些視訊軟體輔助，一樣可以參加站立會議

PM 在這當中有點像是引導者，透過發問的方式，讓團隊成員們慢慢的熟悉站立會議的模式，同時也讓自己更能掌握實際的狀況。

### 5. 要讓客戶感受到被重視

由於 PM 身上可能會不只處理一個專案，如何在不同專案之間做好顧客關係管理，我想很大一部分跟時間管理有關係。

在第一點時我提到了事情要分輕重緩急，分完後依序地處理每件事情之外，另外也可以透過一些工作摘要整理成進度跟客戶做回報，表現出主動追蹤處理問題的態度，重點式的回報進度給客戶，客戶在知道專案狀況後通常會比較放心。

許多時候 PM 除了專注於管理專案的進度之外，也需要服務客戶的心理狀態，讓客戶放心也感受到備受重視

### 最後，我對 PM 工作的想法

專案管理有趣卻也困難的是在於許多事情沒有完美或唯一正確的解答，只有能被大家接受的解決方法，當 PM 需要學會在這灰色地帶中透過有效的溝通作出決定，並學習接受現實世界中不可能滿足所有人的狀況下，如何使專案能夠向前推進。


preview stefan-stefancik-257625

專案管理起步走：五件重要的小事


之前曾經寫過一篇我們公司專案使用敏捷開發的案例，當時我們在預期的時間讓 MVP 的產品能夠上線，讓敏捷開發的價值得底被證明。不過這一次我想從另一個同樣是跑敏捷開發卻跑的不盡理想的專案中，重新探究敏捷開發的價值。

專案的背景是與國外企業的 RD 部門將部分的產品委外給我們開發，產品的規劃、設計由他們主導，我們只要負責好開發的部分，聽起來是非常單純的委外開發。但短短的半年期間，雙方經歷過多次的調整，才終於催生出產品進到使用者測試的階段。

### 溝通的高牆

敏捷開發宣言裡提到：個人與互動重於流程與工具

在最剛開始接下這專案時，負責管理我們的是客戶公司（以下簡稱Ａ社）的 Tech Lead 以及負責這個產品的 Product Manager、Product Owner，我們與其他 RD 的溝通幾乎是零。

我們走我們的 Scrum，他們走他們的 Scrum，只有 Tech Lead 和 PM 知道雙方在做什麼。
這樣延伸出來的主要問題是功能開發的速度會變的緩慢。

在一個有打算做跨部門的組織裡，要讓這件事情得以實現，我想還是需要讓對於同一功能再進行開發的相關人員有能夠溝通的管道，不然的話兩個團隊各做各的狀況其實還是一種 waterfall 的流程，只是裝上了敏捷開發流程的殼。

當時為了解決這個問題，Ａ社的新 CTO 在剛上任時找了我們幾位同事到他們公司一起共事幾天，和他們一起每日站立會議，確實與他們的工程師面對面的溝通時，許多之前需要等待很長時間回應的狀況就馬上等到解決，但由於我們終究不是駐點的團隊，這一次的面對面溝通只是暫時化解當時正在開發功能上的一些問題，並沒有真正解決之前溝通的高牆。

### 小小的調整，讓問題提早被發現

舉例來說我們當時遇到的狀況是開發功能的流程是固定的，功能設計與圖完稿後才會進到功能開發，我們沒有機會可以對設計圖上問題提出改善建議，必須要照圖開發，直到一個不正確的功能被開發完成後再重新由 Product Manager 開新需求進行調整，理想上這雖然是一個完整程序，但開發者及設計師就會面臨一種時常在打掉重練的挫敗感，對產品而言則是不停地在累積技術債。

![post-從失敗案例重新思考敏捷開發價值](//images.ctfassets.net/8er52l3j5u76/YZvwV2YPJmVMCYRNUDTjy/8d065402c363e2c7ede151388dcf0271/WSH7bjP.png)

後來，針對上面提到的情境我們做了一點溝通上的調整，使得一些邏輯面上的問題在交付給客戶之前就能得到解決，雖然說交付給客戶之後，有一定的機率客戶會要求修改或調整功能，但至少工程師們在開發過程中就發現的邏輯問題能夠在交付給客戶前就得到討論，減少一些未來開發上所累積的技術債。

![post-從失敗案例重新思考敏捷開發價值](//images.ctfassets.net/8er52l3j5u76/TNL6tqgGxTEmwTxMyxbkS/706a5061943dc3457d92b492cd8b6cef/nkTtpPC.png)

### 不再只有單一對話窗口，多團隊看板開發

除了剛才提到一點流程上的改變，在我們回國後，CTO 下了一個決策，我們從一開始的 Scrum 換成了 Kanban 的管理方式。
過去不同團隊做的事情如果會相互影響到，很難在各自的站立會議中發現，因此非常倚賴 Tech Lead 來同步溝通個團隊的狀況，導致開發速度一直都很緩慢，大家都互相的等來等去，而且還不知道到底等的是誰。

改成看板開發後，以這家公司規模（工程師在20位以內）還可以在同一時間一起開會，主要由 CTO 擔任會議主持人瀏覽看板，因為不同部門的正在負責的票都在同一個看板上，Ａ團隊的票被 B 團隊影響著的狀態就能夠在看板上一目瞭然。

解決了之前不同團隊對於進度瞭解上的高牆。

### 持續堅持站立會議

站立會議是大家耳熟能詳在 Scrum（敏捷軟體開發過程）中的一部份。

在專案的這段時間內，不論有沒有和客戶那邊一起站立會議，我們自己這邊則是一直都有進行著，我想除了同步彼此的進度狀況，發現專案的問題、進度的問題、技術的問題之外，我另外有個心得是覺得站立會議同時還是一個建立團隊默契及感情滿重要的會議。

這個專案中有過幾次工程師上的人力調整，除了全職的工程師外也有一些 Remote 工程師在我們的團隊當中，透過每日的站立會議，讓新進的工程師或是無法常常面對面對話的  Remote 工程師們都有一段時間和其他團隊成員對話、溝通，能夠幫助他們更快地融入團隊中，這點是我覺得站立會議在敏捷開發中的另一個價值。

在這專案中，客戶有客戶團隊自己的開發腳步，站在外包團隊的角度正好可以觀察到這些事情，更加讓我體會到敏捷開發絕對不是單單只有那些原則、圖表和方法，還會牽扯到組織的文化及管理。我想要做到資深的管理者（或說 Scrum Master）需要有效且精準地找出組織問題的癥結點並加以改善，才能夠讓敏捷開發一直保有他敏捷的優勢，而不是只是流於形式。

post-從失敗案例重新思考敏捷開發價值/cover

從失敗案例重新思考敏捷開發價值

我大學是讀電子係偏光電類的，雖然都是理工科，但和程式是完全無關的，所以我根本也不會寫程式。

一直從電子系讀到電子所碩士畢業，但我根本就不喜歡當工程師，所以碩士畢業後，就跑到一家銀行當人力派遣領個 22k 的工作 (當時晚上在補英文) 待了 2 年有。後來又去到一家社團法人協會當秘書，是屬於兩岸交流相關的協會，因為有這個機緣，就會時常到大陸出差及開會，也透過這個機會，了解到兩岸對於資訊人才的需求是很大的。

為了公司勞心勞力的工作及加班，但在我的心中很明白，行政這類型的工作，對男生而言，很難當個專業技能更不可能靠這個吃一輩子及養家活口。在前年 7 月的時候，更被老闆一句話，就調離現職的工作崗位，更讓我決定了，一定要轉換跑道，脫離目前的環境。

## 想學程式的原因：想證明自己的極限在哪

我覺得我已經 34 歲了，一直對於未來都是很茫然的，同期的同學工作穩定，也都結婚有了小孩，真心覺得我怎麼會這樣 ? 因此同學會或聚餐之類的也都不參加，我覺得這是一件很丟臉的事，我心想難道真的就這樣了嗎?

那時正好看在網路上，看到一個全端網路開發的線上學習課程，一套課程就可以學到前後端網路開發技能，心想這根本是為我打造，因此就算是高達好幾萬塊，但我是抱著也許這就是我人生最後的機會了，因此就報名了。

從一開始每天利用下班後，獨自一人留在辦公室花 4 小時練習，週末至少花 10 小時寫程式，我很了解距離轉職工程師還是有一大段路要走，然而過程如何辛苦，我給自己的目標，要在一年左右的時間，一定順利正式轉職工程師。

## 這不是盡頭，而是另一個起頭
但是花了許多時間自學這個線上學習課程，由於並沒有沒有得到適當的回應，所以導致學習效果不好 (而且還不是只有我一個人這樣認為)，整個學習狀況遇到了瓶頸及失去動力，在加上 Demo Day 選拔的落選，讓我失落了一段時間。

很感謝同時期學習的同學，告訴我五倍紅寶石這家公司，要幫助我們重新建立對 Ruby on Rails 的信心，我便又開始長達 3 月個的實體課程學習，在這期間中我也把工作辭掉，把全部心力放在寫程式這檔事。心想，這次這次我真的拚了，除了到五倍上課外，其它日子就是一睜開眼睛就寫程式寫到睡覺，不出去玩、完全也不參加任何聚餐及各種活動，過年也不回外婆家，完全閉關苦練。

最後很順利的在去年 10 月，透過五倍的媒合機制，我終於順利正式轉職工程師，現職為前端工程師，但是現在的我，不管是下班還是假日，依然的不斷進修磨練我手上所會的技能，早日成為獨角獸 (一個精通 UI / UX 設計，還能同時進行前端和後端開發的厲害角色)。

在此感謝五倍的眾大神們，龍哥、蒼時、澤清、悉剛、Alan、KT、Sandy、典禎、Tea、Amos 及 Kuro 兩位老師還有同期的同學們及常被我打擾的助教們。

## 鼓勵想轉職的人 別再說：「我辦不到」
想要轉職是一件需要勇氣的事情，而實際去執行才是真正拿出勇氣的人，所以如果你跟我一樣也對轉職網頁工程師有興趣，記得隨時都可以開始，像我在 34 歲的年紀都可以了，我相信您也一定可以的 !過程中會遇到很多需要挑戰的地方，千萬不要忘記當初下這個決定的時候，那一個充滿勇氣與熱忱的自己，莫忘初衷 !

## 讓生命繼續發光發熱
在 2019 年的 1 月 15 日很順利的通過試用期考核，算是真正的踏入這個行業。接下來，我要以 senior 全端工程師為目標，在公司持續學習且能夠有更好的表現。

以下幾點和各位分享，希望會有幫助。

規劃達成目標的每一步：俗話說的好，不怕慢，就怕站。利用每天、每週、每月完成小目標的規劃，達到自我的成長。
在社群培養軟實力：積極參與社群活動，建立自己的網絡人脈。就好比在臉書上可以找到各式各樣的程式社群來加入，獲取新知。
撰寫部落格：平時多經營個人的 GitHub 和部落格，適時的輸出一些自己學程式的過程和心得。很多新創公司的老闆或是工程師們都在看 GitHub，他們透過這個平台，會了解您是否活躍地持續創造、進步、對社群貢獻。
善用網路資源：網路上學習資源很多，各式各樣的學習平台都有，最建議的是直接學習閱讀英文網站，來獲取最新知識。
五倍默默會：每週二的晚上，五倍都會有一個實體聚會，有關程式的任何問題及對於程式這條路的想法，都可以透過這裡獲得良好的解答。這聚會可能跟你想像的有一點不一樣，來就找個位置坐下來做自己的事，也歡迎上台分享自由與會眾交流，同時也希望大家可以「默默待在這邊就會了」。(截自默默會官網介紹)
就這樣分享給大家，也鼓勵自己繼續人生的另一段旅程。

原文出處為：[vita shela](https://medium.com/%E5%89%8D%E5%BE%80%E7%8D%A8%E8%A7%92%E7%8D%B8%E4%B9%8B%E8%B7%AF/34%E6%AD%B2%E6%89%8D%E9%96%8B%E5%A7%8B%E8%87%AA%E5%AD%B8%E5%AF%AB%E7%A8%8B%E5%BC%8F%E6%9C%83%E4%B8%8D%E6%9C%83%E5%A4%AA%E6%99%9A-%E7%9C%9F%E7%9A%84%E6%9C%89%E5%BF%83-%E6%B0%B8%E9%81%A0%E9%83%BD%E4%B8%8D%E5%AB%8C%E6%99%9A-91b46bcad9bb)

post-34 歲才開始自學寫程式會不會太晚？真的有心，永遠都不嫌晚。

34 歲才開始自學寫程式會不會太晚？真的有心，永遠都不嫌晚。


相信大家小時候都學過四則運算。以 Ruby 進行四則運算時，**整數**的加法、減法、乘法相當單純：

```
> 1 + 2
=> 3

> 9 - 2
=> 7

> 3 * 2
=> 6
```

為什麼要強調整數呢…因為換成**浮點數**的話就會混進奇怪的東西 XD

```
> 0.1 + 0.2
=> 0.30000000000000004

> 0.3 - 0.1
=> 0.19999999999999998

> 0.1 * 0.2
=> 0.020000000000000004
```

簡單來說，由於電腦記憶體有限，**浮點數的 0.1** 和一般人腦認知的**小數點 0.1**有著極微妙的誤差。這是有名的「浮點數不精確問題」，不論任何程式語言都會遇到。不過今天的主題是除法，這部分就跳過吧。

## 那除法呢？
和加減乘法比起來，除法的花樣就多了。首先，從數學上來說，除法運算必然會產生**商數**和**餘數**：

```
被除數 = 商數 * 除數 + 餘數
# 14 = 4 * 3 + 2
```

因此，對人腦來說是簡單的 `x ÷ y`，對電腦來說就是黑人問號了：「所以你現在是想知道除數還是餘數還是什麼？」

### 我兩個都想知道，不行嗎？
可以喔！使用 `x.divmod(y)` 方法，可以同時取得商數和餘數：

```
> 14.divmod(3)
=> [4, 2]
```

### 我想知道商數

#### 總之先幫我隨便算一下吧
好喔，那就是最經典的 `x / y` 方法：

```
# 整數相除，得到整數的商數
> 14 / 3
=> 4

# 非整數相除，得到非整數的商數
> 14 / 3.0
=> 4.666666666666667
```

#### 就是要整數

使用 `x.div(y)` 方法，結果會轉為整數：

```
> 14.div(3)
=> 4

> 14.div(3.0)
=> 4
```

#### 浮點數錯了嗎？

使用 `x.fdiv(y)` 方法，結果會轉為浮點數：

```
> 14.fdiv(3)
=> 4.666666666666667

> 14.fdiv(3.0)
=> 4.666666666666667
```

#### 整數什麼的最討厭了

使用 `x.quo(y)` 方法，會得到更精確的商數：

```
# 整數相除，得到分數物件（Rational）
> 14.quo(3)
=> (14/3)

# 非整數相除，得到浮點數物件（Float）
> 14.quo(3.0)
=> 4.666666666666667
```

### 我想知道餘數

我們先從最單純的情況開始。

#### x, y 的正負值相同時

`x.modulo(y)` 和 `x.remainder(y)` 可以取得餘數：

```
> 14.modulo(3)
=> 2
> 14.remainder(3)
=> 2
```

兩邊同樣都是負數時也是一樣：

```
> -14.modulo(-3)
=> -2
> -14.remainder(-3)
=> -2
```

其中 `x.modulo(y)` 也可以寫成（比較常見的？） `x % y`，兩者意義是一樣的。

#### x, y 的正負值不同時

好，問題來了。當 `x` 和 `y` 的正負值不同時，也就是像是 `14 ÷ -3` 或 `-14 ÷ 3` 這樣的計算時，會發生什麼事情呢？

```
> 14.divmod(-3)
=> [-5, -1]
> 14.modulo(-3)
=> -1
> 14.remainder(-3)
=> 2
```

咦？為何同樣是取得餘數的 `x.modulo(y)` 和 `x.remainder(y)`，得到的結果卻是不一樣的呢？還記得剛才的除法復習嗎：

```
被除數 = 商數 * 除數 + 餘數
```

當被除數和除數的正負值不同時，例如 `14 ÷ -3`，按照數學上對餘數的定義（詳細請參考[維基百科](https://zh.wikipedia.org/wiki/%E4%BD%99%E6%95%B0)），以下兩個解法都是成立的！

```
14 = (-5) * (-3) + (-1)
14 = (-4) * (-3) + 2
```

這也就是說，在數學上，`14 ÷ -3` 的餘數同時有可能是 `-1` 和 `2`。因此，Ruby 同時提供了 `x.modulo(y)` 和 `x.remainder(y)` 兩種方法，以分別取得兩個不同解法所得到的餘數。

簡單地說，能使 `x = a * y + b` 成立的**最小商數解**`a`，與其搭配的餘數 `b` 就是 `x.modulo(y)` 會取得的值：

```
# 14 = (-5) * (-3) + (-1)
> 14.modulo(-3)
=> -1
```

而另一個解法所得到的餘數，就是 `x.remainder(y)` 的結果。它和被除數的正負值會是一致的：

```
＃ 14 = (-4) * (-3) + 2
> 14.remainder(-3)
=> 2
```

前述 `x.divmod(y)` 所取得的餘數，則是以 `x.modulo(y)` 的值為準。

### 特殊狀況

再補充一些和零有關的特殊狀況：

```
＃ 除數是零的話會噴錯
> 1 / 0
=> ZeroDivisionError

＃ 但可以是 0.0 XD
> 1 / 0.0
=> Infinity

# 被除數是零的話，怎麼除都會是零
> 0 / 3
=> 0

# 除非用 0.0 去除 XD
> 0 / 0.0
=> NaN
```

## 結語

以上是關於 Ruby 除法的介紹，雖然實用性應該很低（笑）想更深入理解 Ruby 的數學運算的話，可以參考官方文件的 [Numeric API](https://ruby-doc.org/core-2.4.0/Numeric.html)，還有很多不常用的冷門方法等大家去認識喔～

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>

post- Ruby 冷知識：除法篇 / cover

Ruby 冷知識：除法篇


即便是到了 2019 年，每次長途通勤我仍然是飽受行動網路速度不穩定的折磨，特別是每次搭乘臺鐵經過臺北到板橋區間，時有時無的訊號簡直快要把我逼瘋。這時只能夠透過提前下載好的 Netflix 影集、Audible 的有聲書或是 Kindle 來消磨時間，但若手癢拿起手機點開電子報中的文章，緩慢的載入速度還是立刻把人打回現實。

為了帶來更好的體驗，現在大家開始提倡諸如 Accelerated Mobile Pages (AMP)、Progressive Web App (PWA，漸進式網絡應用程式) 的標準，想要盡可能改善在網路不穩定的情況之下，行動存取的體驗。

早期我們都會被要求透過 Google 的 [PageSpeed](https://developers.google.com/speed/pagespeed/insights/?hl=zh-TW) 服務，來稽核手邊的網頁服務是否有做到基本的優化。去年 (2018) 年末，Google 更是一舉發布 [web.dev](https://web.dev) 這個服務，試圖逼死所有的開發者，透過 [Lighthouse](https://developers.google.com/web/tools/lighthouse/?hl=zh-tw) 的檢測，直接數值化網站中可能影響瀏覽體驗的瓶頸。

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/10JCwFSh4NyqZSwpbMPOMM/f92a496ba2bd75f56743295606f31375/XHozjUs.png)

在這個前提之下，大家開始汲汲營營的著手試圖消滅網站中可能的效能瓶頸，於是前端開始向我們提出許多調整伺服器設定、優化回應速度等的要求。

今天以圖片作為討論的重心，你最常會在檢測報告中看到跟圖片相關的效能建議包含：

- Properly size images
  - Guide: [Serve responsive images](https://web.dev/fast/serve-responsive-images)
- Efficiently encode images
  - Guide: [Use Imagemin to compress images](https://web.dev/fast/use-imagemin-to-compress-images)
- Serve images in next-gen formats
  - Guide: [Use WebP images](https://web.dev/fast/serve-images-webp)
- Defer offscreen images
  - Guide: [Use lazysizes to lazyload images](https://web.dev/fast/use-lazysizes-to-lazyload-images)

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/78WRffQbCVdST24WsfZMYf/1ee270d71ec774b06251c49fe16d3bf6/6HaXOX1.jpg)

令人感動的是 [web.dev](http://web.dev) 的檢測不單單只是提出問題與抱怨，他還直接在檢測報告的後面附上了詳細的指南，幾乎是 Step by Step 的告訴你應該又如何改善，完全就是網站優化的明燈。

Defer offscreen images 算是被抱怨的項目中最容易改善的項目，只要針對不是在 First View 中需要的圖片，進行 Lazyloading 的處理就能搞定，Google 甚至還連處理這件事情的套件都幫你選好了。

其他項目分別是 Properly size images、Efficiently encode images、Serve images in next-gen formats：

- Property size images 基本上是針對螢幕大小，回傳足夠尺寸的圖片
- Efficiently encode images 是要求針對圖片品質進行必要程度的無損 / 有損壓縮
- Serve images in next-gen formats 則是考量到圖片轉換為 Webp 之後可以大約減少 [25% 到 34% 的大小](https://developers.google.com/speed/webp/)，要求在支援 Webp 的瀏覽器中，以 Webp 格式回應圖片請求。

如果處理的圖片項目屬於靜態資源，那麼以上三個項目都可以很輕易的透過現代化的打包工具 (Eg: Webpack) 來達成，但如果今天網站的多數資源來自於 User-Generated Content (UGC，用戶生成內容)，就必須得要在使用者上傳圖片之後進行壓縮。一般來說我們會期望這樣相對耗時的處理過程，不要影響到使用者發布內容的體驗，所以通常會在背景程式中進行處理。

但是假設使用者每次會上傳 5 - 20 張不等的圖片，根據需求必須要壓成至少 3 種不同的大小、2 種不同的格式，我們得要設定一定等級的伺服器等待處理使用者的圖片。而這些提前準備好的圖片，有時根本沒有見天日的時刻。尤其當設計改變、圖片顯示的大小改變時，可能得要重新壓過所有的過往圖片。於是我們開始想

> 如果這些圖片能在需要時即時長出來，那該有多好。

這樣的處理模式可以透過 [Cloudinary](https://cloudinary.com/pricing) 之類昂貴的第三方服務做到 Image Processing on the fly 的功能，或是是透過 [Thumbor](http://thumbor.org) 之類的 Open Source 專案來打造出自己的 On-Demand Imaging service。

要自行打造這樣的服務，你需要

- 原圖儲存的空間 (諸如 AWS S3 Bucket 或是 Google Cloud Storage)
- 一個運作 Thumbor API 服務的伺服器
- 一般來說我們還會希望有個 CDN 服務來快取處理過的圖片

要讓這樣的服務達到最小可用的等級，會需要夠快的處理速度、夠快的平行處理能力。網路上有許多教你如何打造這類服務的教學，其中有不少是透過  AWS Lambda、Google Cloud Functions 等 Serverless 架構來達成優異的效能、與穩定的平行處理表現。

就在我閱讀相關的教學與分享的過程中，我無意間看到了 [AWS Serverless Image Handler 的白皮書](https://s3.amazonaws.com/solutions-reference/serverless-image-handler/latest/serverless-image-handler.pdf)，這個服務的架構可以說是幾乎與我夢想中的藍圖相當符合：

## Serverless Image Handler 架構

- 原圖存於 AWS S3 Bucket
- 透過 API Gateway 接收對於圖片的請求
- 請求由 AWS Lambda 這個 Serverless 服務來執行
    - 自 S3 Bucket 中取出圖片
    - 由 Thumbor 為基礎的 Function 來進行圖片的壓縮、裁圖、格式轉換、加上浮水印等動作
    - 在 API Gateway 的前面以 CloudFront 完成 CDN 服務，快取處理過後的圖片

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/2s0CKRhnQSRWbRVsjnZXkX/e05955e236dfdda08d84ae7930a62527/lNrA1vm.png)

(Serverless Image Handler 架構示意圖，摘自：AWS Serverless Image Handler Implementation Guide)

## 部署

這份白皮書當然不僅僅止步於概念化的階段，在線上的 [AWS Serverless Image Handler Implementation Guide 關於 Deployment 的章節中](https://docs.aws.amazon.com/en_us/solutions/latest/serverless-image-handler/deployment.html)，可以找到關於如何透過 AWS 提供的 CloudFormation Stack 部署這個服務的詳細教學，首先你應該有 1 個儲存 S3 圖片用的 Bucket，這邊因為篇幅關係，就不對於 AWS 帳戶設定、S3 Bucket 設定做 Step by Step 的解說。

按下文中 「[Lauch Solution](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=ServerlessImageHandler&templateURL=https:%2F%2Fs3.amazonaws.com%2Fsolutions-reference%2Fserverless-image-handler%2Flatest%2Fserverless-image-handler.template) 的按鈕」，你就會被導引到 AWS CloudFormation 的服務中，並自動帶入這個 AWS 預先幫你寫好的 Templates

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/62ocy9iNST7PdkZRRpX3wE/0a69d5229b8b9028a52099cf073b01d8/WIzX4iR.png)

接著你需要至少填入

- Origin S3 Bucket：需要處理的圖片儲存的 S3 Bucket 名稱
- Origin S3 Bucket Region：該 S3 Bucket 位於的區域

若需要 CORS 設定來避免別人在他們的網站中嵌入你的圖片

- Enable CORS 選項改為 「Yes」
- CORS Origin 設定為可嵌入圖片的網站位址，這邊必須注意包含域名、協定等資訊都必須要完全符合，以我們官網為例，必須要為 https://5xruby.tw
- 需要特別注意的是，目前並不支援 Multiple CORS Origin 的設定

關於 Deploy UI 的設定

- 若勾選 Deploy UI 為 「Yes」、且設定 UI Prefix 為 「demo/」，則部署完成後可在 `https://[CLOUDFRONT_ENDPOINT]/demo` 中看到一個示範用的 UI 介面
- 請特別注意，在撰文時的最新 Serverless Image Handler 版本 `v 3.1.0` 中，當 Deploy UI 的選項被開啟，那麼 Serverless Image Handler 可能會沒有辦法處理設定好的 Origin Bucket 的圖片，若沒有特別想要玩玩看示範用的 UI 介面，建議不要開啟 Deploy UI 的選項

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/2uthWAAAZLVrmtGAmWHa1C/086768cf7dd2178051eae737cbda69bf/zRobQ1Z.png)

- 依據需求在下一頁的選項中，為這個 CloudFormation Stack 中的資源建立 Tag、指定 IAM 角色或是進階選項，這邊除了建議以有意義的 Tagging 標註這個 CloudFormation Stack 生成的資源外，其他選項沒有需求的話可以暫時保留預設就好。

- 最後在 Review 步驟中勾選：「I acknowledge that AWS CloudFormation might create IAM resources with custom names.」，同意 AWS Cloudformation 可能幫你建立有自訂名稱的 IAM 角色中並按下「完成」，就會被導引到 CloudFormation 的頁面中了

- 此時你應該會在頁面中看到剛剛設置的 CloudFormation Stack 在「Create In Progress 的狀態」，並且可以在下面的 Event 中看到詳細的各 Resorce 設定的情形，按官方的文件中表示，整個過程大約需要 25 分鐘。

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/5PeqotOEEyjU1RgSCj6izH/dffa86e7cb0f11240e98826a66334441/Dc3ZJqm.png)

## 價格

在白皮書的 Overview 章節關於 Cost 的段落，指明了可能會產生的費用包含來自於 S3 Bucket、CloudFront、Lambda 與 API Gateway 的費用，以服務設定於美東區域 (N. Virginia) 為例，每月一百萬次的圖片處理請由、15 GB 的圖片儲存、以及 50 GB 的資料傳輸費用，會產生的費用大致如下：

| AWS Service        | Estimated Price |
|--------------------|----------------:|
| Amazon API Gateway |          $ 3.50 |
| AWS Lambda         |          $ 3.10 |
| Amazon CloudFront  |          $ 6.00 |
| Amazon S3          |          $ 0.23 |
| Total              |         $ 12.83 |

需要注意的是 AWS 的 PUT 跟 GET Requests 所產生的費用會因為每個網站性質、圖片數量有很不一樣的情況，所以並沒有被計算於其中，另外若有使用到「智慧裁圖」的功能，必須支付 AWS Rekognition 的圖片辨識費用。

## 真的可以達成需求嗎？

部署完成後，你應該可以在 CloudFront 中看到對應的 Endpoint 設定，或是在剛剛 CloudFormation Stack Detail 的 Output 中找到部署後的 Endpoint。

透過請求 `https://[CLOUDFRONT_ENDPOINT]/[THUMBOR_FILTER]/[STORAGE_PATH]` 的方式，就能夠動態的達成圖片的動態縮圖。

為了示範，我特意的打開了 Demo UI 的選項：

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/3Y7sBqVJ0v4ZWVTbgGD6v1/0b0497fcce01555a93a825606a324f2a/LfBgFRf.jpg)

可以在畫面中看到，除了基本的長寬的切圖、格式轉換、 Quality 壓縮等設定外，甚至包含動態浮水印、智慧裁切的方式。

以上面那張大圖（[點我看原圖](https://github.com/awslabs/serverless-image-handler/blob/master/source/ui/img/face2.jpg)）進行以下的裁切設定：

```
200x200/smart/filters:format(png):watermark(https://d3soe0wkhi4rba.cloudfront.net/demo/img/aws-logo-watermark.png,120,130,0)
```

- 大小：200x200
- 智慧裁切
- 轉換為 PNG
- 以 AWS Logo 在右下角進行浮水印繪製

可以得到如下的結果：

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/5Ze25N9HocnGmzArW9eE7m/819bd1ed51dfe42311805707d476fd87/mM4Cq0N.png)

關於支援的 Filter 及詳細用法，可以參閱

- AWS 白皮書中的 [Appendix A: List of Supported Filters](https://docs.aws.amazon.com/en_us/solutions/latest/serverless-image-handler/appendix-a.html)
- [Thumbor 官方文件中的 Filters 章節](https://thumbor.readthedocs.io/en/latest/filters.html)

## 安全性考量

除了可以透過 CORS 設定來避免別的網站盜用你的圖片以外，也可以透過 Thumbor 的 SafeURL 避免其他任意修改網址中的 Thumbor 參數，以獲得其他樣貌的圖片，要啟用 Safe URL 的功能，可以在對應的 AWS Lambda Function 中設定以下的 Environment Variables:

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/4OPqAcscaU53WDbkJUQ8pB/63661fc8985549d5673b6a4d08711d06/iADN3x0.png)

- ALLOW_UNSAFE_URL: True
- SECURITY_KEY: 設定為任何你喜歡的密鑰

更新完 Lambda Function 後，以後的請求必須要加上 `HMAC-SHA1` 加密過的參數才可以被 Serverless Image Handler 接受，步驟上為：

- 將請求的 Path 以 HMAC-SHA1 算法與你設定的密鑰加密為 Signature
- 將 Signature 以 URL Safe Base64 算法編碼
- 將請求網址改為：https://[CLOUDFRONT_ENDPOINT]/[ENCODED_SIGNATURE]/[原先的請求 PATH]

更多相關資訊，詳見

- [AWS Serverless Image Handler Implementation Guide 關於 Security 的章節](https://docs.aws.amazon.com/en_us/solutions/latest/serverless-image-handler/deployment.html)。
- [AWS Serverless Image Handler Implementation Guide Appendix D: Safe URL](https://docs.aws.amazon.com/en_us/solutions/latest/serverless-image-handler/appendix-d.html)。
- [Thumbor 文件關於 SafeURL 的章節](https://thumbor.readthedocs.io/en/latest/security.html?highlight=safe%20url)

## 黑魔法?

截至目前為止，我們好像都沒有實際看到 AWS 幫我們部署到 Lambda 上面的 Code、也沒有看到 CloudFormation Template 裡面的內容，感覺好像裡面有很多黑魔法發生，其實 Serverless Image Handler 的原始碼開源在 AWS Labs 的 GitHub 帳號中，可以前往 [Serverless Image Handler 的 Repo](https://github.com/awslabs/serverless-image-handler) 中檢視完整的原始碼，甚至加上自己需要的功能之後部署自己的版本，在 Repo 的 README 中有關於如何打包新的 Lambda Function 的教學。

## Auto WebP
當瀏覽器支援 WebP 這個較好的壓縮格式時，瀏覽器會在請求的 Header 中加上類似的 `Accept: image/webp,image/*` 設定，Thumbor 便能接收這樣的設定並自動以 `image/webp` 回傳。

由於 AWS Serverless Image Handler 的 Lambda Function 其實只是幫你運行了 Thumbor，你可以輕易的在 Lambda Environments 中加上新的設定來開啟這樣的功能。

- 新增新的 Environment Variables `AUTO_WEBP` 為 `True`
- 在對應的 CloudFront 中允許 Accept Header 作為 Caching 條件

讓我們透過 CURL 來檢查一下結果，如果是沒有對應 Accept Header 的請求，預設以原始格式回傳：

```shell
curl -I "https://CLOUDFRONT_ENDPOINT/500x200/prop/5/8856b82425b926b2d93ef314e893e0a7.jpg"

HTTP/2 200
content-type: image/jpeg
content-length: 25121
date: Tue, 22 Jan 2019 14:00:13 GMT
x-amzn-requestid: 09c9e79d-1e4e-11e9-9aaf-6748fac7bc66
x-amzn-remapped-content-length: 25121
x-amz-apigw-id: T6I9EFhAtjMFnHg=
cache-control: max-age=31536000,public
expires: Wed, 22 Jan 2020 14:00:13 GMT
etag: "3e260286d1529193c185ffa93650ee4d37166ed4"
x-amzn-trace-id: Root=1-5c4721ed-c9282248e551fab4a0798714;Sampled=0
x-amzn-remapped-date: Tue, 22 Jan 2019 14:00:13 GMT
vary: Accept
x-cache: Miss from cloudfront
via: 1.1 fbf94e317a2eadeb551cc7c3ef6e546d.cloudfront.net (CloudFront)
x-amz-cf-id: _Mc6-ERgc6my1EpWsEIIjM-7aUr9ELAqYXCULfrCEz7pYfEFmG1uJQ==
```

如果是有 Accept Webp 格式的請求：

```shell
curl -I --header "accept: image/webp,image/*,*/*;q=0.8" "https://CLOUD_FRONT_ENDPOINT/500x200/prop/5/8856b82425b926b2d93ef314e893e0a7.jpg"
HTTP/2 200
content-type: image/webp
content-length: 17458
date: Tue, 22 Jan 2019 13:55:18 GMT
x-amzn-requestid: 58bfca53-1e4d-11e9-8e00-63a2ea8deee6
x-amzn-remapped-content-length: 17458
x-amz-apigw-id: T6IOpEdrtjMFc5Q=
cache-control: max-age=31536000,public
expires: Wed, 22 Jan 2020 13:55:18 GMT
etag: "a4fdc702a62407d8d08fdefdeaccb2279bf282fd"
x-amzn-trace-id: Root=1-5c4720c4-6329e9b86ed8d27cf33ed564;Sampled=0
x-amzn-remapped-date: Tue, 22 Jan 2019 13:55:17 GMT
vary: Accept
age: 421
x-cache: Hit from cloudfront
via: 1.1 3c61ae3f6890de150027c363309d9c7f.cloudfront.net (CloudFront)
x-amz-cf-id: z0i0Yn3WBtjzMlVDId0Do1GjNUQMIRs3p8hMA9b2i0sqvdarhGUIfg==
```

可以看到相同大小的圖片請求，硬是小了 30% 的大小，而且透過 Accept Header 判斷回傳格式，還可以確保 HTML DOM 節點的乾淨，是個非常優雅的解決方法。

## Known Issues

這個方案也並非盡善盡美，除了上述提到的不支援 Multiple CORS Origin 設定、Demo UI 無法跟現存的 Bucket 並用外，這篇文撰寫時最新的 Serverless Image Handler 版本 `3.1.0` 所搭配的 Thumbor 版本為 `6.5.1`，在處理透明 PNG 的智慧裁切時會遇到預期外的錯誤，暫時也不支援 SVG 的圖片格式。

另外由於 Lambda 服務本身對於 Response Body 的限制，若裁切後的圖大於 6MB 可能會造成回傳失敗。

## 結語

AWS Serverless Image Handler 結合了 S3 Bucket 的儲存服務、API Gateway 跟 AWS Lambda 搭建出動態縮圖 API，並以 CloudFront 作為 CDN 快取服務，可算是一個相當完整且具有潛力的解決方案，雖然目前仍有些功能上的欠缺或是問題，但是使用者可以透過開源的原始碼自行針對自己的需求客製。

Lambda 的平行處理及優異的效能，讓自行搭建 On Demand Image Processing Service 這件事情變為不再遙不可及，也讓工程師能夠專心於提供使用者更好的服務體驗。


post-透過 AWS ServerlessImageHandler 實現動態圖片處理

透過 AWS ServerlessImageHandler 實現動態圖片處理


`\[a-zA-z]{3,}|^\D$|^[0-9a-z]*$|^[0-9A-Z]*$\`

相信大家在寫程式的過程當中，一定都曾看到過像上面這種，有點像亂寫的程式碼，有些可能看起來沒那麼複雜，而有些則是長到讓人難以招架，光是看到就讓人頭痛，更不用說去讀懂它了。

事實上，這種程式碼叫做正規表達式(RegExp，Regular Expression），是處理文字非常重要的利器，當你希望規範文字的格式、或者是限制使用者的文字格式時，正規表達式是不可或缺的存在。

文首的表達式是我超級討厭的銀行密碼格式（還有 PlayStayion Network 的密碼格式），會找出這些格式：

* 超過連續三個英文字母（不分大小寫）
* 沒有任何數字
* 沒有任何大寫字母
* 沒有任何小寫字母

只要你設立的密碼符合以上任何一個格式，程式就會拒絕你使用這組密碼，以這樣的方式來讓使用者建立出一個安全性相對高的密碼——雖然很多時候都是徒勞無功的。

在這篇文章當中，希望可以透過簡單明瞭的方式來講解正規表達式，並且讓大家在未來撰寫或閱讀正規表達式的時候，能夠得心應手，無所畏懼。

在 Ruby 裡面，有幾種方式可以定義正規表達式，比較普遍的方式是用 slash(/) 將正規表達式包起來，像是 `/[a-zA-Z]*/`，而另一種方式則是用 Ruby 的 class生成，變成、 `Regexp.new('[a-zA-Z]*')` ，值得注意的是，使用第二種方式不需要加入 slash，只要將內容以字串方式傳入即可。大部分情況下我們會看到第一種方式，少部分的情況下，特別是需要動態產生正規表達式的時候，第二個方式會比較好用。最後則是將利用 `%r{[a-zA-Z]*}` 這樣的方式也可以定義正規表達式。

> 使用 %r 的情況下，不需要將 {} 裡面的表達式包成字串

在正規表達式當中，我們有幾個比較常用的 Match Character 來表示我們的規則：

| Match Character | 規則                 |
|-----------------|----------------------|
| .               | 所有字元             |
| \w              | 所有字母，包含大小寫跟數字 |
| \d              | 所有數字（0-9)       |
| \D              | 除了數字以外的字元   |
| [ ]              | 指定的範圍，例如[a-f]|

當然，只有 Match Character 還不夠，我們還必須指定字元是否重複，或者重複的次數，否則預設都是一個字元。

| 重複表示 | 規則                         |
|----------|------------------------------|
| ?        | 未出現或出現一次             |
| *        | 未出現或出現多次             |
| +        | 出現一次或多次               |
| {a}      | 出現 a 次                    |
| {a,}     | 至少出現 a 次以上            |
| {,b}     | 最多出現 b 次                |
| {a,b}    | 最少出現 a 次，最多出現 b 次 |

舉個例子來說，台灣的市話號碼有可能是七碼或者八碼，我們就可以利用 {a, b} 這個重複規則來做出正確的格式：`/^\d{7, 8}$/`。這個正規表達式的意思，我們希望找出一個有七到八個數字的字串，而前面的 `^` 以及後面的 `$` 分別代表字串的開頭開始和字串的結尾，這在很多場合是非常重要的。假設沒有規定必須從字串的最前面開始或在最後結束，他便會抓取最前面或是最後面符合的字串，如此一來便不符合我們希望的規則。

舉例來說，如果我們的規則是這樣 `/^\d{7, 8}/`，沒有最後結束的符號，那麼即使當我輸入手機號碼 0955555555，他還是會回傳最前面的八位數字給你。

```ruby
# incorrect
pry(main)> '09555555555'.match /^\d{7,8}/
=> #<MatchData "09555555">

# correct
pry(main)> '09555555555'.match /^\d{7,8}$/
=> nil
```

如此一來我們可以回頭看一開始的表達式
> `\[a-zA-z]{3,}|^\D$|^[0-9a-z]*$|^[0-9A-Z]*$\`

這邊可以注意到，中間我們用 pipe `|` 來做分隔，其實 pipe 就是 or 的意思，我們可以利用這個方式來加入多個條件，因此我們也可以將表達是分開來解讀。

- `[a-zA-Z]{3,}` 這個部分則表示我們要找出無論大寫或是小寫的字母，三個連續字母連在一起的組合。
- `^\D$` 這裡則表示找出整個字串都完全沒有數字的組合。
- `^[0-9a-z]*$` 這段則是找出整個字串中只有小寫和字母，意思就是字串中完全沒有大寫的組合。
- `^[0-9A-Z]*$` 和上面那段相似，只是找出沒有小寫的組合。

利用這個表達式，我們就可以順利做出一個討人厭的密碼規則囉，是不是很簡單呢？

在文章的最後，提供一個方便的線上工具，你可以在這個網頁上任意嘗試各種 RegExp 的組合，並且確認規則是否正確，非常地方便：[http://rubular.com/](http://rubular.com/)

希望透過這篇文章，讓大家可以輕鬆地解讀正規表達式，並且也能夠順利地用正規表達式寫出簡潔的程式碼。

photo by [Christiaan Colen](https://www.flickr.com/photos/christiaancolen/)


技術文章