五倍券 Banner - 首頁 - desktop

五倍券 Banner - 首頁 - mobile

五倍的五倍券優惠活動

Blogs - Sidebar

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

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/)


post-動動手來學 Regular Expression 正規表達式 / cover 

動動手來學 Regular Expression 正規表達式


跑在瀏覽器上的組合語言？在 ban 了 flash 之後，大家在尋找是否有其他可以在瀏覽器上執行原生程式的方案，又或者只是不想寫 Javascript...Webassembly 這個標準被提出了（以下簡稱 wasm），可以是 C/C++ 這種靜態語言的編譯目標，也就是我們可以把現有的 C/C++ 專案編譯成 wasm，[有人就嘗試把 ffmpeg 編譯到瀏覽器上執行](https://www.youtube.com/watch?v=GsGPWSUmP8s)，後來 [golang](https://github.com/golang/go/wiki/WebAssembly) 以及 [rust](https://rustwasm.github.io/book/) 也可以編譯成 wasm ，今天來用 [rust](https://www.rust-lang.org/) 試試看 wasm 吧

> 基本上這篇我是看著 https://rustwasm.github.io/book/ 做的

## Rust

我選擇 rust 純粹只是因為我沒用過，聽說對於 concurrent 有一套很獨特的概念，想嘗試看看而已，首先來把 rust (`rustup`) 安裝起來：https://www.rust-lang.org/tools/install

我對 `rustup` 的理解： rust 官方的 rust 版本管理器

安裝完成之後，安裝現在的 rust 穩定版

```shell
rustup toolchain install stable
rustup default stable
```

## 準備 rust wasm 開發環境以及工具

基本上現在使用 wasm 的方法是比較像是寫底層原生程式給 js 呼叫，[必須先用 js 載入 wasm，接著用 js 呼叫 wasm 的 exports](https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API#Streaming_the_WebAssembly_module)

但是要怎麼讓編譯器知道哪些東西要給 js 呼叫？js 跟 rust 互傳變數/資料的時候如何各自表述？甚至載入 wasm 可能各家瀏覽器的 API 都不盡相同...幸好 rust wasm 已經有許多現成的工具包幫我們解決這些問題，所以接下來要先來把開發環境準備好

### `wasm-pack`

首先 [wasm-pack](https://github.com/rustwasm/wasm-pack) 是 rust 跟 js 橋樑的核心，它的 macro 讓指定的 rust 函式以及資料結構提供給 js 端使用，當然也就處理了兩邊的資料轉換，最後它還幫忙生成 js 讓 webapp 端可以直接 import 使用

```shell
cargo install wasm-pack
```

> `cargo` 是 rust 的 `npm` / `gem` / `bundle`，我的理解是這樣

### `cargo-generate` & `wasm-pack-template`

同時也有人弄了新手模板 [wasm-pack-template](https://github.com/rustwasm/wasm-pack-template)，但是為了使用他我們要裝 `cargo-generate`，於是乎：

```shell
cargo install cargo-generate
```

### `create-wasm-app`

rust 的部份準備好了，但是我們要怎麼弄個能夠載入 wasm 的 webapp？還有個 wasm webapp 的新手模板 [create-wasm-app](https://github.com/rustwasm/create-wasm-app)，這個幫你把 [webpack](https://webpack.js.org/) 設定值都準備好，而且就是拿來跟 `wasm-pack-template` 搭配使用的，但是也意味著我們需要 [nodejs](https://nodejs.org/en/)，而且我用 nodejs `11.6.0` 才能用 npm 從模板建立專案

```shell
node -v # => v11.6.0
npm install -g create-wasm-app
```

## 終於可以來建立專案囉

這邊建立一個叫做 `wasm-glife` 的 [wasm-pack-template](https://github.com/rustwasm/wasm-pack-template) 專案：

```shell
cargo generate --git https://github.com/rustwasm/wasm-pack-template -n wasm-glife
cd wasm-glife
```

還沒完，還要把 webapp 建立起來，弄個 `www` 資料夾來放 webapp：

```shell
mkdir www
cd www
npm init wasm-app
npm install
```

## 看來產生不少東西，看一下哪些檔案值得我們關心

```
tree .
.
├── Cargo.toml <= 給 rust 的 package.json
├── LICENSE_APACHE
├── LICENSE_MIT
├── README.md
├── src
│   ├── lib.rs <= 將會是接下來的重頭戲，我們會在這邊定義給 js 呼叫的東西
│   └── utils.rs
├── tests
│   └── web.rs
└── www <= 大家熟悉的 webpack 專案
    ├── bootstrap.js
    ├── index.html
    ├── index.js <= 將會在這邊呼叫 rust wasm
    ├── LICENSE-APACHE
    ├── LICENSE-MIT
    ├── package.json
    ├── package-lock.json
    ├── README.md
    └── webpack.config.js
```

#### `Cargo.toml`

```toml
[dependencies]
cfg-if = "0.1.2"
wasm-bindgen = "0.2"
```

這邊最重要的就是 `wasm-bindgen` 這個套件，待會會看到相關的 macro

#### `src/lib.rs`

[wasm-pack-template](https://github.com/rustwasm/wasm-pack-template) 產生的 `src/lib.rs` 一開始引入一些東西，configure 一些東西，先不管他，下面這兩個已經完整示範了要怎麼在 rust 使用 js function 以及把 rust function 提供給 js 使用

```rust
#[wasm_bindgen]
extern {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet() {
    alert("Hello, wasm-glife!");
}
```

* `#[wasm_bindgen]` macro 加上 `extern` 表示從 js 拿哪些 function 使用，這邊把我們常用的 `alert` 拿進來
  * [有想法的人應該已經想到問題了，可以看一下 wasm_bindgen 更詳細的說明](https://rustwasm.github.io/wasm-bindgen/examples/import-js.html)
* `#[wasm_bindgen]` macro 加上 `pub fn ...` 讓 js 可以呼叫哪些 rust function，這邊把 `greet` 拿出去給 js 呼叫

#### `www/index.js`

```javascript
import * as wasm from "hello-wasm-pack";

wasm.greet();
```

js 這邊就把 wasm 當成一般的 ES module 引入，接著呼叫 `greet()`

但是我們現在還沒編譯 rust 到 wasm，這時直接去跑 webpack 是編譯不過的，畢竟 `hello-wasm-pack` 還沒編譯出來

## 編譯 rust 到 wasm

```shell
rustup run stable wasm-pack build -d www/wasm
```

* `rustup run stable ...` 的部份，我想是類似 `bundle exec ...`，去執行對應 rust 版本的執行檔
* `wasm-pack build` 就能編譯這個 rust 專案成一個 node module
  * `-d www/wasm` 則是讓編譯出來的 node module 放在 `www/wasm`

按下 enter 之後就會開始下載 dependency，編譯，第一次編譯約莫幾分鐘

> [線上書的做法是產生一個真的 local npm module...](https://rustwasm.github.io/book/game-of-life/hello-world.html#using-our-local-wasm-game-of-life-package-in-www)但是我覺得沒必要這麼麻煩，直接把東西丟在 webpack 專案裡頭就能用了

## 串到 webapp

`wasm-pack` 成功之後會產生蠻多東西的，不過我們 focus 在產生的 node module

```
tree .
...
└── www
    ├── bootstrap.js
    ├── index.html
    ├── index.js
    ├── LICENSE-APACHE
    ├── LICENSE-MIT
    ├── package.json
    ├── package-lock.json
    ├── README.md
    ├── wasm <= wasm-pack 編譯出來的 node module
    │   ├── package.json <= "module": "wasm_glife.js"
    │   ├── README.md
    │   ├── wasm_glife_bg.d.ts
    │   ├── wasm_glife_bg.wasm <= 就是我，wasm
    │   ├── wasm_glife.d.ts
    │   └── wasm_glife.js <= wasm-pack 會把必要的橋接產生在這
    └── webpack.config.js
```

因為產生的是 node module，透過 webpack 可以直接 import 使用，我們只要把 `www/index.js` import 改成

```javascript
import * as wasm from "./wasm";
```

接著把 webpack 跑起來

```shell
npm run start
```

用[支援 wasm 的瀏覽器](https://caniuse.com/#feat=wasm)打開 http://localhost:8080/ 應該可以看到：

![post-Webassembly - run native code on browser using Rust](//images.ctfassets.net/8er52l3j5u76/sHoje69SaGqq0pT3UvuAd/43480e7629a1afe4398aba3047b1c7b4/9PxdcQ7.png)

在打開瀏覽器開發工具切到 Network tab，確實可以看到 wasm 被載入了：

![post-Webassembly - run native code on browser using Rust](//images.ctfassets.net/8er52l3j5u76/6tSTZNDdZcXsVl7wMz3FsA/0bcd4ee963a364154461f8678fca8eb0/1oYjh7R.png)

wasm 是 binary 格式的，需要用工具才能轉回可讀的文字：

![post-Webassembly - run native code on browser using Rust](//images.ctfassets.net/8er52l3j5u76/43B939WRD5hgp9copcxhpV/06ce75b7f82ea9c3c77f97d9b79d62db/Jm7ZdIT.png)

最後偷瞄一下 webpack 怎麼幫我們載入 wasm 的 (`bootstrap.js`)：

![post-Webassembly - run native code on browser using Rust](//images.ctfassets.net/8er52l3j5u76/5lbWXLYGCII6HePMUdmu8e/503a45ecaf91bbbbb23bd21d49bf96fe/eRd7MXb.png)

## 實做一些東西來玩玩：Conway's game of life

因為我看的這本線上書就是要來做 [Conway's Game of Life](https://zh.wikipedia.org/wiki/%E5%BA%B7%E5%A8%81%E7%94%9F%E5%91%BD%E6%B8%B8%E6%88%8F)，基本上就是在一個棋盤上，每個格子可以是死亡或是存活兩種狀態，並且會根據周圍 8 格鄰居格子的狀態決定下回合的狀態

但是我對 rust 還沒這麼熟，所以就邊看邊抄，邊抄邊學，嘗試寫成自己的版本：https://github.com/pastleo/rs-wasm-glife/

* [src/universe.rs](https://github.com/pastleo/rs-wasm-glife/blob/master/src/universe.rs) 實做[核心資料結構](https://github.com/pastleo/rs-wasm-glife/blob/master/src/universe.rs#L10)以及[演算法](https://github.com/pastleo/rs-wasm-glife/blob/master/src/universe.rs#L67)
* [src/main.rs](https://github.com/pastleo/rs-wasm-glife/blob/master/src/main.rs) 讓我可以編譯成傳統 binary 執行檔在 console 上執行並印出棋盤
* [src/lib.rs](https://github.com/pastleo/rs-wasm-glife/blob/master/src/lib.rs#L47) 包裝成 `Game` class 給 js 使用
* [www/index.html](https://github.com/pastleo/rs-wasm-glife/blob/master/www/index.html) 以及 [www/index.js](https://github.com/pastleo/rs-wasm-glife/blob/master/www/index.js) 實做使用者界面
  * [`game.isChanged(i)`](https://github.com/pastleo/rs-wasm-glife/blob/master/src/lib.rs#L63) 決定[是否要 toggle css class](https://github.com/pastleo/rs-wasm-glife/blob/master/www/index.js#L48) 避免不必要的 DOM 改動
  * 使用者可以[按格子](https://github.com/pastleo/rs-wasm-glife/blob/master/www/index.js#L97)來[更改狀態](https://github.com/pastleo/rs-wasm-glife/blob/master/src/lib.rs#L67)

我也把東西放到網站上大家可以上去玩玩：https://static.pastleo.me/rs-wasm-glife/

[結果影片](https://www.youtube.com/watch?v=6PRM-iyNo80&feature=emb_title&ab_channel=%E9%82%B1%E5%86%A0%E5%96%BB "結果影片")

> 蠻好玩的，我可以玩很久

## 心得

其實 conway's game of life 用 rust -> wasm 很可能沒有比純 js 實做來的快，說不定光是在 rust 跟 js 之間的資料轉換的效能犧牲就已經不值得了，現在 wasm 是以 MVP 的概念先在各家瀏覽器支援，我個人比較期待的是還沒定案的這兩個功能：

* [threading](https://github.com/WebAssembly/threads) 讓支援 threading 加速的 C/C++ 程式發揮優勢
* [GC](https://github.com/WebAssembly/gc) 讓瀏覽器執行 ruby, erlang, elixir 等 runtime

這幾天就花點時間試試看 wasm，體驗一下在自己機器開發/執行的感覺（話說在 android chrome 跟 ios safari 都跑得起來）順便學一下 rust


五倍紅寶石・專業程式教育機構

ASTRO Camp

線上課程

短期課程

技術文章

五倍消息

技術文章

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

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

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

Ruby 冷知識：除法篇

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

動動手來學 Regular Expression 正規表達式

Webassembly - run native code on browser using Rust

Git 面試題

訂閱文章

電話 | (02) 2331-5247

信箱 | [email protected]

地址 | 10046 台北市中正區衡陽路 7 號 5 樓

專業課程

ASTRO Camp

線上課程

短期課程

關於我們

關於五倍紅寶石

聯絡我們

媒體報導

加入我們

部落格

技術文章

五倍消息

幫助與政策

常見問題

隱私權政策

服務條款