五倍直播間

Blogs - Sidebar

React 是 Facebook 2013 年推出的 Javascript 的框架，這篇文章是針對 React component 的重構，對 React 就不多做介紹。Tailwind 是 2017 年正式發佈的 CSS 框架，提供一堆超基本的  class，例如：`font-bold`、`text-white`、`float-right`，這些 class 只要會 CSS 的人一看就懂，非常明確而且容易上手。

個人覺得使用 Tailwind 的好處是提供了一份定義完整的 CSS class 統一命名文件，人人都可以很清楚知道自己和別人在寫什麼，例如：`text-black`，不會被某人定義成 `t-black` 或更簡短但意味不明的 `t-b`，雖然可以少打幾個字母，但卻會造成未來維護上的困難，尤其是文件沒做好的話，就會需要更多時間來理解這個 class 後面所帶有的屬性，會造成隊友的痛扣。另外 Tailwind 和現在流行的前端框架，例如： React、Vue、Angular、Ember 等等都能整合的很好，非常推前端工程師撿起來用。

Tailiwnd 一大特色是全部 class 都 inline 寫在 HTML 標籤 上，例如：

```
<button className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
  Enable
</button>
```

這個 HTML 的 `button` 標籤從頭看到尾就能看出個這個按鈕大概長什麼樣子，但整個網站都這樣全部 inline，當網站大了之後要維護起來也會相當辛苦。所以如果是一些網站中常用的元件，就可以試著做成可重複使用的 component 把一大串的 class 轉成清楚明瞭語義化的 props，如下：

```
<Button size="xs" textColor="white" bgColor="blue-500">
  Enable
</Button>

// Button.jsx
function Button ({size, bgColor, textColor, children}) {
  return (
    <button className=`text-${size} bg-${bgColor} text-${textColor} font-bold py-2 px-4 rounded`>
    {children}
  </button>
  )
};

export default Button;
```

兩段程式碼的差異是第一段，直接用 HTML 的 `button` 標籤加上 inline class，第二段是另外包成一個 `Button.jsx` component，用 props 取代原本寫 class 名稱的方式來設定的按鈕，例如： size、 textColor、bgColor，程式碼的可讀性提昇許多也方便重複使用。

## 搭配 classnames 讓 react component 有點互動感

[classnames](https://www.npmjs.com/package/classnames) 是一個 JavaScript 的小工具，可以用來幫忙處理一些簡單的邏輯判斷把 classNames 串在一起。

classnames 提供了一個 `classNames` 的 function，`classNames` 可以接受傳入 N 個 string 或是 object 參數，然後生出一整段字串。

參數說明：

- object：如果 key-value 裡的 key 給的 value 是 falsy 值 (例如：false、null、0、undefined…) 的話，這個 key 就不會被留著。

- string：`foo` 等於 `{ foo: true }`。

```
// 用法如下：
classNames('foo', 'bar'); // => 'foo bar'
classNames('foo', { bar: true }); // => 'foo bar'
classNames({ 'foo-bar': true }); // => 'foo-bar'
classNames({ 'foo-bar': false }); // => ''
classNames({ foo: true }, { bar: true }); // => 'foo bar'
classNames({ foo: true, bar: true }); // => 'foo bar'

// lots of arguments of various types
classNames('foo', { bar: true, duck: false }, 'baz', { quux: true }); // => 'foo bar baz quux'

// other falsy values are just ignored
classNames(null, false, 'bar', undefined, 0, 1, { baz: null }, ''); // => 'bar 1'
```

有了 `classnames` 可以對 React component 的 class 做一些簡單的控制。舉一個網站也很常用到的下拉式選單 Dropdown，這個 `Dropdown` 已經包成只要給選項 (options) 和點選之後要執行的動作 (onOptionsSelect) 就可以重複使用的 component；然後在 `Dropdown` 裡面定義了按鈕和選單的樣式設定，

```
<Dropdown
  options={\["Edit", "Duplicate", "Archive", "Move", "Delete"\]}
  onOptionSelect={(option) => {
    console.log("Selected Option", option)}
  }
/>
```

`Dropdown` 這邊用了 Tailwind 的 `.hidden` 和 `.block` 控制下拉選單的顯示與否，按下 `<button>` 的時候，觸發 `onClick` 事件，改變 `isActive` 的狀態，選單的部份再對應 `isActive` 顯示或隱藏。

```
import classNames from 'classnames';

function Dropdown({ options, onOptionSelect }) {

  // 用 useState 設定 isActive 的狀態
  const [isActive, setActive] = useState(false);

  const buttonClasses = `inline-flex justify-center w-full rounded-md border border-gray-300 px-4 py-2 bg-white text-sm leading-5 font-medium text-gray-700 hover:text-gray-500 focus:outline-none focus:border-blue-300 focus:shadow-outline-blue active:bg-blue-500 active:text-gray-200 transition ease-in-out duration-150`;

  return (
    <button onClick={() => setActive(!isActive)} className={buttonClasses}>
      Options
    </button>
    // 用 classnames 來控制 .block 和 .hidden class
    <div class={classNames("origin-top-right absolute right-0 mt-2 w-56 rounded-md shadow-lg", {
      block: isActive,
      hidden: !isActive
    })}>
    // 選項列表
    {options.map((option) => <div key={option} onClick={(e) => onOptionSelect(option)}>{option}</div>)}
   </div>
  )
}

export default Dropdown;
```

## 網站視覺設計系統

另一個重構的方式是按照網站視覺設計系統把常用的 component 樣式先集中定義在一個檔案裡面，然後再包成具有語義化且可重複使用的 component。

例如：把 Tailwind 的 class 另外寫在 `theme.js` 裡面，寫 component 的時候只要呼叫 `theme.js` 已經定義好的樣式，這樣 component 檔案裡面的程式碼就會更乾淨一點。

```
// theme.js 可以取自己喜歡的名稱
export const ButtonType = {
  primary: "bg-blue-500 hover:bg-blue-700 text-white font-bold rounded",
  secondary: "bg-blue-500 hover:bg-blue-700 text-white font-bold rounded",
  basic: "bg-white hover:bg-gray-700 text-gray-700 font-bold rounded",
  delete: "bg-red-300 hover:bg-red-500 text-white font-bold rounded"
};

export const ButtonSize = {
  sm: "py-2 px-4 text-xs",
  lg: "py-3 px-6 text-lg"
}
// 看命名就知道，`ButtonType`：定義按鈕的樣式。`ButtonSizes`：定義按鈕的尺寸。
```

定義一個 `Button`， import 剛剛的 `theme.js`：

```
import { ButtonType, ButtonSize } from './theme';

function Button({size, type, children}) {
  const classNames = `${ButtonType[type]} ${ButtonSize[size]}`;
  return (
    <button className={classNames}>{children}</button>
  )
}
export default Button;
```

這樣 `Button` 用起來就可以很清楚他是哪一種按鈕和什麼尺寸，非常簡潔明瞭。

```
// 清楚判斷按鈕的屬性
<Button size="sm" type="primary">Enable</Button>

// 最後顯示在 html 會長成這樣
<button className="py-2 px-4 text-xs bg-blue-500 hover:bg-blue-700 text-white font-bold rounded">Enable</button>
```

如果需要更改按鈕樣式就修改 `theme.js`，就能全部的按鈕一起換，不用一個一個撈出來改。這樣打造一套網站的常用的 components 有助於提昇維護的效率，在未來換專案的時候，只要改成相對應的 class  所有東西都可以帶著一起走，加速專案開發的速度。

## 在 CSS 檔裡面用 Tailwind classes：`@apply`

第三個方法是過去寫 CSS class 的方式，然後在 Tailwind classes 前面加上 `@apply`， `@apply` 可以透過 [PostCSS](https://postcss.org/) 把 Tailwind 的 class 編譯成 CSS。例如現在專案有一套 UI 元件，裡面有一個主要按鈕 (Primary) 和次要按鈕 (Secondary)，如果沒有任何的處理直接把 Tailwind class 的塞在元件裡面會長成下面這樣：

```
<button className="py-2 px-4 mr-4 text-xs bg-blue-500 hover:bg-blue-700 text-white font-bold rounded">Update Now</button>

<button className="py-2 px-4 text-xs mr-4 hover:bg-gray-100 text-gray-700 border-gray-300 border font-bold rounded">Later</button>
```

這裡基於 BEM-style 的設計概念下，button 的 class 加上 `@apply` 會長成這樣：

```
/\* button.css \*/
@tailwind base;
@tailwind components;

// 按鈕基本樣式
.btn {
  @apply py-2 px-4 mr-4 font-bold rounded;
}

// 按鈕種類
.btn-primary {
  @apply bg-blue-500 hover:bg-blue-700 text-white;
}
.btn-secondary {
  @apply hover:bg-gray-700 text-gray-700 border-gray-300 border;
}

// 按鈕尺寸
.btn-xs {
  @apply text-xs;
}
.btn-xl {
  @apply text-xl;
}

@tailwind utilities;
```

`button` 可以使用上面設好的 class：

```
<button class="btn btn-primary btn-xs">Update Now</button>
<button class="btn btn-secondary btn-xs">Later</button>
```

雖然已經比直接 inline 的寫法簡潔，接著可以再整理成 React component：

```
import classnames from "classnames";

function Button ({size, type, children}) {
  const btnSize = "btn-" + size;
  const btnType = "btn-" + type;
  return (
    <button className={classnames("btn", btnSize, btnType)}>{children}</button>
  )
}

Button.propTypes = {
  size: PropTypes.oneOf(['xs, lg']),
  type: PropTypes.oneOf(['primary', 'secondary'])
};
```

之後就可以重複使用這個 `Button`，這樣看起來也是蠻清楚的！

```
<Button type="primary" size="xs">Update Now</Button>
<Button type="secondary" size="xs">Later</Button>
```

一種基本上可以達到設計師和工程師分離的 fu，設計師負責整體樣式 (style)，然後把 CSS 文件建好，工程師只要遵照文件設定 component 屬性，不用知道按鈕要不要圓角、`padding` 多少，什麼顏色；設計師想要改樣式，只要處理 CSS 的部份，工程師有乖乖用 component 的話，樣式是設計師說改就改，分工清楚的話也方便兩邊的使用，CSS 歸一邊，JavaScript 歸一邊，~~呀～理想總是好棒棒~~。目前 Tailwind 尚末支援所有的 CSS 屬性，未支援的屬性必須另外加在 style 上面或是另外新增 class。總之今天就到這邊，看到這裡的各位有空可以了解一下  Tailwind 好用之處，未來能依專案所需選擇重構 React component 的方式，謝謝各位：)

### REF
- [Building Reusable React Components Using Tailwind](https://www.smashingmagazine.com/2020/05/reusable-react-components-tailwind/)

- [還在跟複雜的 CSS 的設定奮鬥嗎？用 Tailwind 來幫你實現真正的高效整潔！](https://5xruby.tw/posts/tailwind-css-plugin/)

- [classnames](https://www.npmjs.com/package/classnames)

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Tailwind CSS 觀念和原理嗎？
>
> 我們有開設 💠 [升級前端技術從 Tailwind CSS 開始](https://5xruby.tw/courses/tailwindcss) 課程唷 ❤️️
>


post-Tailwind 求上車 - 重構 React component/cover

Tailwind 求上車 - 重構 React component


(Photo by <a href="https://unsplash.com/@prateekkatyal?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="nofollow noopener noreferrer" target="_blank">Prateek Katyal</a> on <a href="https://unsplash.com/s/photos/less-is-more?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="nofollow noopener noreferrer" target="_blank">Unsplash</a>)

# Build a URL Shortener from scratch?

大家應該都曾經因為分享方便、想要追蹤點擊等目的使用過 [Bit.ly](http://bit.ly) 或是已關閉的 Goo.gl 網址服務。

自行打造 URL 縮網址小工具，對於任何有一定經驗的工程師來說，都並非難事，但當我們把「要好、要快、要便宜」的標準放入考量中時，一個簡單的縮網址服務也可以從數日、數週的挑戰變成需要數月的工作項目。

人是不習慣知足的動物，有了功能之後，我們會開始要更多：

- 服務需要使用者驗證、授權。組織內的服務可能有多個，最好這些服務的都能有 Single Sign On 的整合，同時我想要讓大家可以用慣用的 Google、Facebook、GitHub 等第三方 Oauth 完成身份驗證。
- 服務的響應速度能不能更快。
- 當有突然湧入的使用者，希望服務可以瞬間擴展到足以吃下所有的需求。反之，當沒有人使用我的服務的時候，能不能降低成本到趨近為零。
- 時間應該浪費在開發新功能、與其他有價值的美好事物上頭，需要定期費心維護的東西能不能再更少。

# Monolith to Microservices

回溯過去，部署服務的起手式曾經是開一台虛擬機器，在裡面安裝好所有需要的環境。隨後由於開始需要確保服務可以服務跨更多區域的使用者、增加服務的穩定、減少需要耗費大量時間逐一 Patch 虛擬機器、資料庫或是 Application 的機會、並讓服務的 Application、Database、CacheWorker 等區塊可以分別按照需要調整資源。

同時現在多數的開發團隊都會使用混合的 Techstack，在同組織、甚至同產品內就會運用多種不同的語言、框架，為了方便可以單元式的開發所需要的模組，Monolith (單體式) to Microservices (微服務) 的概念曾紅極一時。

# Serverless and FaaS (Function as a Service)

## Serverless

講到微服務就不得不提到 Serverless (無伺服器運算) 概念。無伺服器運算的概念被視為是 Cloud Native (雲端原生架構) 的極致展現，雖然名字可能讓人誤解，無伺服器運算事實上仍然是倚賴著雲端伺服器進行，只是我們將大多數的管理成本進一步委派由大型雲端服務商來控管。

無伺服器運算透過盡可能的免除瑣碎、非必要的架構佈署、修正、維護工作，以最大化的減低管理成本，同時提高服務調整與擴展的敏捷度。同時由於可以隨需 (On Demand) 快速的調高與調低佈建的資源大小，可以最大化的減小總體擁有成本 (Total Cost of Ownership)。

如此一來，無伺服器運算得已讓隨時都一直處在人力吃緊狀態的開發團隊得以將心力投注於開發與產品的成長，使得開發優良、高可用 (High Availability)、可擴展 (Scalable) 的產品變得比以往都還要輕鬆。

## FaaS (Function as a Service)

打造微服務的主流作法，不外乎是倚靠容器化 (Container) 技術、或是倚賴 FaaS  (Function as a Service) 雲端服務架構。其中 FaaS (Function as a Service) 因為可以最大幅的降低管理成本 (Admin Overhead) 及學習成本而受到歡迎，三大雲端巨頭都分別推出了對應的指標性產品，包含常見的 Google Functions、AWS Lambda、Azure Functions。

FaaS 透過將服務功能重新拆解，以 Function (函式) 為執行基礎單位，達成只需為各函式運行時間成本支付費用的夢想，同時由於 Function 必須為 Stateless，這使得彈性擴展變得彈指般容易，若妥善搭配全受管 (Fully-Managed) 服務，可以同時達成高可用服務架構的水準。

# Serverless to Functionless

由於 FaaS 將管理成本交付給雲端服務營運商、可以快速調節佈建資源，並同時能達成高可用的要求，不少組織開始大量的採納 Serverless 服務。但事情總是不會如想像般美好，從 Monolith 架構轉換至擁抱 Microservices、進而採用 Serverless 架構，所需要的遠遠不只是把服務打散成 Function、搬移到雲端運營商，未經深思熟慮的貿然遷移，往往為後需服務的擴張留下不可控制的技術債。

表面上看來，Microservices 架構讓你把服務變成多個小單元、每個小單元能夠獨立的擴展、維護，好像很容易分而治之 (Divide and Conquer)，然而隱含的風險是，如果多個小單元處置不善，那其實也就只是在自己的服務中佈下滿地的致命地雷。

問題出現之後，我們學著理解到無伺服器、高效的調節、低廉的成本、新潮的技術架構其實都不是核心，讓大家「專注」在能夠打造更好、更穩定的核心服務體驗，才是技術演進的價值所在。Functionless 的概念就在這樣的反思中應運而生。

Functionless 試圖回歸到服務的核心，開發者們應該盡可能將「專注」放在讓服務與需要上面、應該要盡可能用「事半功倍」的方法達成目的，可能的話，最好連 Function 都別 Provision 就能打造服務。

# 案例探討：AWS Samples - Functionless URL Shortener

沒有了 Function，那後端邏輯在哪、誰來負責答覆請求？讓我們先回到我們的主題：「Functionless 縮網址服務」上頭。

AWS Compute Blog 曾在 2016 年發表了《Build a Serverless, Private URL Shortener》一文，透過 Lambda、API Gateway、S3、CloudFront 等服務，就可以還算輕鬆的完成一個簡單的私有縮網址服務，如果一個月產生 1,000 個縮網址、每個縮網每月收到 1,000 個請求的話，一個月的費用不到 5 塊錢台幣。

四年過去，今年初 AWS Compute Blog 又發表了《Building a serverless URL shortener app without AWS Lambda》系列文，透過 AWS Amplify, Cognito, API Gateway, DynamoDB, S3 等重新完成縮網址服務。

在我們繼續往下以前讓我們先對 AWS 的 Serverless 生態圈重點服務有基本的認識。

## AWS Serverless 無伺服器生態系

- AWS Lambda：FaaS 重點服務，可以透過 Ruby, Go, Python, Node, Java, C# 等語言撰寫 Function，透過「事件」驅動 Function 執行，可以輕易的平行運行 Function
- API Gateway: 讓你可以建立不同的 HTTP API 並連結到不同的後端
- Cognito：使用者 (User Pool) 驗證服務
- DynamoDB：Key Value NoSQL 服務
- S3：靜態資源儲存服務
- CloudFront: CDN 服務

## 部署 API

為了方便近距離感受 Functionless 的特性，讓我們來部署一下 AWS Samples 中的 [Functionless URL Shortener](https://github.com/aws-samples/amazon-api-gateway-url-shortener) 吧！Repo 的 README 中有詳細的部署指引。

- 部署之前你需要確保你的電腦中已經有 AWS CLI、以及 AWS SAM CLI
- Fork Functionless URL Shortener Repo
- 建立一組 GitHub 的 Personal Access Token，並賦予該 Token 所有 Repo Scope 底下的權限
- 將 Repo Clone 到你的電腦上並導引到對應專案目錄
- 執行 `sam deploy -g` 初始化部署，依據提示完成選項的選擇，並進行部署
- 由於過程涉及 CloudFront 的設定，可能會需要至多約 30 分鐘左右才能完成部署，若部署過程比想像中耗費時間，不需過於擔心

## 部署前端

上面的步驟幫你完成了 API 的部署，在這個 Sample App 中還包含了以 Vue.js 撰寫的前端部署，讓我們接著來完成前端介面的部署。這部分同樣在 README 中有詳細的部署指引。

- 到 Amplify Console 中找到剛剛建立的 Apps
- 依據 API 部署後的回傳訊息完成以下環境參數設定
    - VUE_APP_NAME
    - VUE_APP_CLIENT_ID
    - VUE_APP_API_ROOT
    - VUE_APP_AUTH_DOMAIN
- 回到 Amplify Console 針對對應的 APP 執行 Run Build 完成初次部署，整個部署就完成了！
- 試著瀏覽剛剛建立出來的 APP 建立短網址。

## What's special

讓我們已這個 2020 年 2 月發布的 Functionless URL Shortener Sample Project 與 2016 年的 Private URL Shortener 進行比較。

### Apache VTL (Velocity Template Language) instead of Lambda functions

首先最大的差異就是 Functionless！綜觀整個服務中我們會看到完全沒有 Function 存在。

URL Shortener 的核心邏輯並不複雜，任何開發者對於這樣的邏輯應該都十分熟悉

- 你會有一個簡短的 URL Slug 對應至原始的 URL
- 服務的使用者應該可以快速的貼上 URL，並觸發 API
- API 觸發後，需要儲存 URL Slug 與原始目標 URL 對應
- 當其他使用者瀏覽縮短後的網址時，應該要被轉址到原始目標 URL

在這個過程中，收到的縮網址請求內容，與實際需要存進資料庫的部分並未相差太多。當使用者瀏覽短網址時，需要回覆的內容也與資料庫所儲存的資料並未差異太大，這麼簡單的 CRUD 層級的任務，難道還非得要部署幾個 Function 來解決他們？翻找一下 Repository 的內容，你還真找不到對應的 Function。

AWS 不斷的在演進自家服務的進展，原本透過 API Gateway 收到請求後，我們會想要將請求事件交由 Lambda 處理，但 API Gateway 多了對 Apache VTL (Velocity Template Language) 的支援後，我們可以透過 Apache VTL 進行簡單的請求內容轉化後，直接在 DynamoDB 建立對應的請求。

舉例來說，一個簡單的建立 URL 請求：

```json
{
  "id": "aws",
  "url": http://aws.amazon.com,
  "timestamp": "27/Dec/2019:21:21:17 +0000",
  "owner": "ericdj@amazon.com"
}
```

我們可以透過在 API Gateway 建立以下的 VTL 宣告：

```json
#set($inputRoot = $input.path('$'))
{
  "id":"$inputRoot.Attributes.id.S",
  "url":"$inputRoot.Attributes.url.S",
  "timestamp":"$inputRoot.Attributes.timestamp.S",
  "owner":"$inputRoot.Attributes.owner.S"
}
```

將原本的使用者請求轉換為 DynamoDB 的建立請求：

```json
{
  "id": {"S": "aws"},
  "owner": {"S": "me@mydomain.com"},
  "timestamp": {"S": "27/Dec/2019:21:21:17 +0000"},
  "url": {"S": "http://aws.amazon.com"}
}
```

若遇到 Slug 重複的情形，我們可以透過在 API Gateway 建立以下的 Apache VTL 設定，將 DynamoDB 的 `ConditionalCheckFailedException` 錯誤，轉換成回應錯誤回應：

```json
#set($inputRoot = $input.path('$'))
#if($inputRoot.toString().contains("ConditionalCheckFailedException"))
  #set($context.responseOverride.status = 200)
  {"error": true,"message": "URL link already exists"}
#end
```

### Leverage Services instead of libraries / customized solutions

在這個 Sample 中，我們可以看到比起 2006 年的 Private URL Shortener 服務，這個服務有更好的使用者介面、更完整的驗證程序，然而實際上卻沒新增太多的程式碼，從很多角度來看反而簡化了許多需要維護的程式碼。

在新的 Sample 中以 Cognito 完成了服務驗證、以 Vue.js 完成前端部署至 S3 中，所有的服務仍然都以全受管服務打造，你不需要花太多精力在調整伺服器及其他架構，只需要專注於整個服務的核心邏輯身上。

過往我們會透過 Rails, Express, Django 這樣的全端框架來完成從 Routing, Request Handing, Database ORM, Caching, Monitoring 等功能，在這個示範架構中我們最大化的利用雲端服務來來達成所有的功能，唯一需要專注維護的程式碼只有縮網址的核心邏輯。

### Architecture as Code

在這個 Sample App 的架構中，利用 AWS SAM (Serverless Application Model) 來定義需要運行服務的整個架構，任何人只需要透過簡單的 `sam deploy` 指令便能輕鬆複製出一模一樣的架構，架構以 YAML 檔的形式儲存，任何需要維護架構的人都不再需要進 AWS Console 花好幾天的時間想辦法追溯出整個架構的運行狀況，如果需要災難復原 (Disaster Recovery) 時也能在最短的時間內重新還原服務架構。

### No waste

在這個範例中，所使用的服務全都是 Fully Managed Service，只需要告訴 AWS 你所需要的用量跟如何連結各個服務，部署的資源跟費用會隨著需要動態調節，真正的把每一毛錢都花在刀口上，不需要佈建過多不需要的容量，也不需要時時刻刻擔心突然增長的流量會不會讓服務垮掉。

# 結論

就以上 Sample Apps 的範例中，我們可以從中觀摩 Serverless、甚至 Functionless 架構的幾個重點訴求：

## Offloading tasks，Less is more

過往我們習慣透過一個全端的 Application Framework 來包辦工作，透過 Vertical Scaling、Hortzontal Scaling 的方式來擴展佈建容量，Serverless 的思維模式讓你將關注重新放回重要的核心功能中，將可以委派的工作交給雲端服務來處理，達成「事半功倍」的成果。

## Infrastructure as Code / Architecture as Code

在這個案例中，我們也見識到了透過文字 Config 來描述架構的好處，透過 Infrastructure as Code 甚至是 Architecture as Code 的方式，我們得以完整的分享架構的知識、甚至是輕鬆的重建整體服務架構。

## Ensure scalability of your stacks

同時我們可以觀摩透過 AWS Lambda、DynamoDB、S3、Cognito 這些服務，我們得以完全依照流量所需來佈建所需要的資源，輕鬆就能應對突來的流量增長。

## Optimize your Costs

Scale in 跟 Scale out 同樣的重要，透過 Serverless 的原則，我們可以確保當服務處於沒有人使用的時期，所消耗的資源可以自動維持在最低幅度，節省成本，將資本用在真正需要的地方。

# References

- AWS Compute Blog《[Build a Serverless, Private URL Shortener](https://aws.amazon.com/tw/blogs/compute/build-a-serverless-private-url-shortener/)》
- AWS Compute Blog《[Building a serverless URL shortener app without AWS Lambda](https://aws.amazon.com/tw/blogs/compute/building-a-serverless-url-shortener-app-without-lambda-part-1/)》
- A Cloud Guru on Medium《[Serverless is a state of mind](https://read.acloud.guru/serverless-is-a-state-of-mind-717ef2088b42)》
- Stackery《[The Future of Serverless is… Functionless?](https://www.stackery.io/blog/future-of-serverless/)》
- Lego Engineering on Medium《[Don’t wait for Functionless. Write less Functions instead](https://medium.com/lego-engineering/dont-wait-for-functionless-write-less-functions-instead-8f2c331cd651)》

post-From Serverless to Functionless，不寫 Code 也能打造縮網址服務?

From Serverless to Functionless，不寫 Code 也能打造縮網址服務?

(Photo Credit: “Person Standing on Train Rail” by <a href="https://unsplash.com/@clayton_cardinalli" rel="nofollow noopener noreferrer" target="_blank">Clayton Cardinalli</a> on <a href="https://unsplash.com/photos/ik1xoxbLDgM" rel="nofollow noopener noreferrer" target="_blank">Unsplash</a>)

## 目錄
- 前言
- 使用 `reload!` 來重新讀取更改過後的 Code
- 呼叫 Helper Methods 與發送 HTTP Request
  - 呼叫 URL Helper Method
  - 呼叫 View Helper Method
- 用 YAML Module 將資料漂亮地印出
- Rails Console Sandbox Mode
- 其它小技巧
  - 使用 `~/.irbrc` 載入常用的東西
  - IRB 裡的 `_`
- 補充： `$ rails routes` 加 flag （ Rails 5 以上）

## 前言
程式語言 Perl 的作者 <a href="https://en.wikipedia.org/wiki/Larry_Wall" rel="nofollow noopener noreferrer" target="_blank">Larry Wall</a> 在他的書 <a href="https://en.wikipedia.org/wiki/Programming_Perl" rel="nofollow noopener noreferrer" target="_blank">Programming Perl</a> 曾經提到過的<a href="http://threevirtues.com/" rel="nofollow noopener noreferrer" target="_blank"> Programmer 三大美德 （ Three Virtues of a Programmer ）</a>之中，第一點即為「懶惰 （ Laziness ）」。在 Rails 工程師天天中都會使用到的 Rails console ，其實有些更<del>偷懶</del>聰明的使用方式。筆者在這邊整理了一些小撇步，要來帶著大家一起更有效率地使用 Rails console ！

## 使用 `reload!` 來讀取更改過後的 Code
若是在 Rails console 已經開啟的狀態下更動了 code ，只要執行 `reload!` ， Rails 就會讀取更改過後的 code ！

```ruby
# call a model's scope
>> SomeModel.some_scope

# modify the code and use `reload!`
>> reload!
>> SomeModel.some_scope
```

## 呼叫 Helper Methods 與發送 HTTP Request
說到測試 helper ，一般比較直覺的做法會是在 ERB template 或 helper method 的 method body 中插入斷點（如 `byebug` 或 `binding.pry` ）後試圖讓 code 跑到斷點以進行測試。但其實在 Rails console 中是可以呼叫這些 methods 的。

### 呼叫 URL Helper Method
想要在 console 裡呼叫 URL method 的話，只要將 method send 給 `helper` 就可以了。若想要更進一步、直接在 console 內發送 request ，只要將 HTTP Verb send 給 `app` 即可：

```ruby
# example from https://guides.rubyonrails.org/command_line.html#rails-console
>> app.root_path
 => "/"

>> app.get _
Started GET "/" for 127.0.0.1 at 2014-06-19 10:41:57 -0300
...
```

### 呼叫 View Helper Method
想要在 console 裡呼叫 helper method 的話，可以將 method send 給 `helper` 來使用。筆者自己常用的情境有以下：

- 測試 Rails 的 helper method
- Debug 自己寫的 helper method

```ruby
>> helper.number_to_currency 1234.567, unit: '円', precision: 1, format: '約 %n %u'
 => "約 1,234.6 円"
>> helper.some_helper_method
```

## 用 YAML Module 將資料漂亮地印出
若是平常的工作情境上會常常需要呈現資料給夥伴的話，將資料以好閱讀的方式印出，可以<del>有效降低夥伴眼睛脫窗的機率</del>讓夥伴更快速地掌握資料的樣貌。要在 Rails console 中將資料漂亮地印出，除了使用一般常見的 gem <a href="https://github.com/cldwalker/hirb" rel="nofollow noopener noreferrer" target="_blank">Hirb</a> 或 <a href="https://github.com/awesome-print/awesome_print" rel="nofollow noopener noreferrer" target="_blank">Awesome Print</a> 外，還可以使用已經在 Rails 裡面就引入的 `YAML` module 來達到類似的效果。若想要在一般的 IRB 內使用的話，只要先執行 `require 'yaml'` 就可以了。

```ruby
>> y User.first.attributes
---
id: 1
email: email@email.biz
encrypted_password: "somelonglonglonghashedpw"
 => nil
```

```ruby
2.6.0 :005 > y %w[foo bar baz]
---
- foo
- bar
- baz
 => nil
```

```ruby
>> y({ a: 1, b: 2, c: 3 })
---
:a: 1
:b: 2
:c: 3
 => nil
```

若看不慣 YAML 的資料格式，可以用 `PP` module （ Pretty-Printer ），在保留資料原來的樣態下印出 hash 或 array ：

```ruby
>> pp User.first.attributes
---
{"id"=>1,
 "email"=>"email@email.biz",
 "encrypted_password"=>
  "somelonglonglonghashedpw"}
 => # omitted
```

## Rails Console Sandbox Mode
要在不更動到 DB 裡的資料的前提下在 Rails console 裡面進行操作，可以在呼叫 Rails console 時在後方加上 flag `--sandbox` 。沙盒模式運用了 DB 的 savepoint ，在離開 Rails console 後即 rollback 。

**另外需要注意的一點是請不要在 Production 使用，因為沙盒模式會讓被更新的資料列被鎖住，造成其它需要跟該資料列互動的工作被卡住。**

```sh
# short form
# $ rails c -s
$ rails console --sandbox
```

```ruby
Loading development environment in sandbox (Rails 5.2.4.2)
Any modifications you make will be rolled back on exit
>> User.delete_all
  User Destroy (18.5ms)  DELETE FROM "users"
 => 11
>> exit
   (0.3ms)  ROLLBACK
```

平常在新增 migrate 檔時，若擔心在執行 `rails db:migrate` 的過程當中、會因為 migrate 檔內有一部分 code 沒寫好而造成執行失敗，陷入了「 migrate 檔僅跑完部分、但檔案被 Rails 標註為已執行、 DB 資料還壞掉」的這種不上不下的窘境，也可以運用 Rails console 的沙盒模式來放心地進行測試！

```ruby
# credit goes to https://shime.sh/til/testing-migrations-from-sandboxed-rails-console
>> require './db/migrate/20200516140557_create_identities.rb'
 => true

# use #change/#up to invoke the migration
>> CreateIdentities.new.change
-- create_table(:identities)
   (11.1ms)  CREATE TABLE "identities" ( # omitted
```

## 使用 `~/.irbrc` 載入常用的東西
透過在家目錄下定義的 `.irbrc` ，我們可以在每次 IRB 或 Rails Console 被開啟時，將我們所需要的函式庫及設定一次讀取進來：

- 引入需要平常會用到的 modules ，如前面提到的 `YAML` ，或者是 `BigDecimal`
- 設定在 console 內、給特定專案用的 aliases 及 helper methods

```ruby
# ~/.irbrc
LIBS = %w[yaml bigdecimal hirb].freeze
LIBS.each do |lib|
  next if respond_to? lib

  require lib
  puts "Lib is loaded: #{lib}"
rescue LoadError
  puts "\e[31mLoading lib failed: #{lib}\e[0m"
end

if defined? Rails
  app_name = Rails.application.class.parent.to_s

  # tries to match module name string defined in config/application.rb
  if app_name == 'FooBarBaz'
    def me
      @me ||= User.find_by(first_name: 'danny', last_name: 'boi')
    end
  end

  if app_name == 'BazBarFoo'
    # that long query you find yourself typing every day
    def foo
      Foo.where(some_column: 'some_long_value',
                another_column: 'some_long_long_long_value')
    end
  end
end
```

## 其它小技巧
### IRB 裡的 `_`
若是想要使用上一次 IRB eval 的結果來做些什麼的話，可以使用 `_` ：

```ruby
>> Time.now
 => 2020-05-16 10:43:02 +0800
>> now = _
 => 2020-05-16 10:43:02 +0800
>> now
 => 2020-05-16 10:43:02 +0800
```

### 使用 `CTRL` 加 `r` 搜尋歷史 Input
要搜尋之前打過的東西，除了用上下鍵慢慢找以外，其實還有更快的方式。按下 `CTRL` 加 `r` 後就可以輸入關鍵字、往回搜尋曾經輸入過的 code 。

若要離開 `reverse-i-search` 模式，按下 `ESC` 或 `CTRL` 加 `[` 即可跳出。

## 補充： `$ rails routes` 加 flag （ Rails 5 以上）
若要以 `rails routes` 來尋找特定的路徑，最直覺的方式應該是 pipe 給 grep 來過濾出自己想要的路徑：

```sh
$ rails routes | grep users
```

在 Rails 5 以後，可以靠 flag `-c` 或 `-g` 達到類似的效果：
- Controller specific search

```sh
$ rails -c users
$ rails -c admin/users
```

- Pattern specific search

```sh
$ rails routes -g product
```

若專案使用的是 Rails 6 ，還可以使用 flag `-x` 、漂亮地印出路徑：

```sh
# example from https://guides.rubyonrails.org/routing.html#listing-existing-routes
# short form
# $ rails routes -x
$ rails routes --expanded
```

```
--[ Route 1 ]----------------------------------------------------
Prefix            | users
Verb              | GET
URI               | /users(.:format)
Controller#Action | users#index
--[ Route 2 ]----------------------------------------------------
Prefix            |
Verb              | POST
URI               | /users(.:format)
Controller#Action | users#create
# omitted
```

那以上跟直接呼叫 `rails routes` 後再使用 `grep` 有什麼差異嗎？其實沒有<del>，但是可以拿出來炫一下</del>。

## 參考資料
- <a href="https://guides.rubyonrails.org/command_line.html#rails-console" rel="nofollow noopener noreferrer" target="_blank">The Rails Command Line - 1.4 rails console</a>
- <a href="https://shime.sh/til/testing-migrations-from-sandboxed-rails-console" rel="nofollow noopener noreferrer" target="_blank">Testing migrations from sandboxed Rails console</a> by <a href="https://shime.sh/" rel="nofollow noopener noreferrer" target="_blank">Hrvoje Šimić</a>
- <a href="https://guides.rubyonrails.org/routing.html#listing-existing-routes" rel="nofollow noopener noreferrer" target="_blank">Rails Routing from the Outside In - 5.1 Listing Existing Routes</a>

---

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


post-原來 Rails Console 可以這樣用/cover

原來 Rails Console 可以這樣用

有聽說過「編輯體例」嗎？拿起你手邊任何一本有經過出版社印製的書來看看，你應該可以發現：同一本書裡，不論是在排版格式上或是翻譯用語和專有名詞上，是有很高的一致性的。舉個簡單的例子，如果書中主角是「彼得」和「瑪莉」，即便編輯自身比較偏愛「彼德」和「瑪麗」的用法，也必須按照出版社要求的編輯體例，將用語統一為「彼得」和「瑪莉」。因為有共同的標準，同一間出版社下，就算是不同的編輯經手的不同作品，在排版和用語上也會有很高的一致性，例如凡是日期都會統一使用「六月四日」這樣的格式，不會印成「6 月 4 日」。

程式的世界裡也有類似的概念，我們稱之為 coding style。諸如怎麼縮排、括號怎麼斷行（或不斷行）、變數如何命名、判斷式的寫法、是否有行數限制等，每個人都有各自的偏好。這裡面有些是業界公認的 best practice，也有些是見仁見智的宗教戰爭，但無論如何，在團隊協作的情境下，有一個「大家可以接受並願意遵循的 coding style」作為開發的基礎，是相當重要的事情。

Ruby 圈有幾個比較有名的 style guide（字母序）供大家參考：

- [社群版](https://rubystyle.guide/)
- [Airbnb 版](https://airbnb.io/projects/ruby/)
- [Cookpad 版](https://github.com/cookpad/styleguide/blob/master/ruby.en.md)
- [GitHub 版](https://github.com/github/rubocop-github/blob/master/STYLEGUIDE.md)
- [Shopify 版](https://shopify.github.io/ruby-style-guide/)

對於工程師來說，「程式碼的風格統一」這種事情，當然就應該交給工具來處理囉。而在 Ruby 圈裡，最被廣泛使用的檢查工具就是本文要介紹的 [RuboCop](https://github.com/rubocop-hq/rubocop)。RuboCop 大約在 2012 年前後問世，也算是歷史悠久的開源專案了，但時至今日依然還沒有推出 1.0 的版本，官方文件也很大方地承認常會有向後相容的問題，要大家自己注意使用的版號 XD 

那就開始吧。因為沒有現成的例子，就順便工商服務一下，用敝公司的開源工具 [bankai] (https://github.com/5xRuby/bankai) 產生一個新的 Rails 專案：

```
$ gem install bankai
$ bankai demo
```

馬上來執行看看：

```
$ cd demo
$ rubocop
Inspecting 40 files
........................................

40 files inspected, no offenses detected
```

RuboCop 檢查了 40 個檔案，沒有發現問題 ，打完收工 🎉 呃不是啦 XD 再仔細看一下，會發現專案下有這兩個設定檔：

```
$ ls .rubocop*
.rubocop.yml      .rubocop_todo.yml
```

`.rubocop.yml` 一看就是善良市民可以先放一邊， 倒是 `.rubocop_todo.yml` 看起來就很可疑，馬上打開來看看：

```ruby
# This configuration was generated by
# `rubocop --auto-gen-config`
# on 2020-05-13 11:13:56 +0800 using RuboCop version 0.81.0.
# The point is for the user to remove these configuration records
# one by one as the offenses are removed from the code base.
# Note that changes in the inspected code, or installation of new
# versions of RuboCop, may require this file to be generated again.
```
RuboCop 既然是用來檢查 coding style 的工具，自然也是依據某個 style guide 作為標準，而 RuboCop 參照的則是前文提到的社群版本。由於 Rails 和 RuboCop 是由不同團隊開發的，雙方的「出廠預設值」會有衝突也是在情理之中，所以並不是「RuboCop 沒有意見」，而是 bankai 預先把這些「已知不合」的狀況先隔離在 todo 裡，再讓團隊自行判斷後續該如何處理。

> 這裡必須再強調一次：我們在專案中導入 RuboCop 或其他 linter，並不是為了要追求「考試一百分」這樣的價值，而是要讓團隊成員在協作時能有共同遵循的標準。也就是說，在團隊成員有共識的前提之下，RuboCop 的結果只是參考，不需要盲從，預設值可以調整，必要時甚至也可以忽略。

那我們就順手改一下 todo 裡的東西吧！

```ruby
# Offense count: 1
# Configuration parameters: EnforcedStyle.
# SupportedStyles: slashes, arguments
Rails/FilePath:
  Exclude:
    - 'config/environments/development.rb'
```

 把這一條規則（我們稱之為 cop）註解起來後再執行一次，就會乖乖噴錯了：

```
$ rubocop
Inspecting 40 files
.................C......................

Offenses:

config/environments/development.rb:19:6: C: Rails/FilePath: Please use Rails.root.join('path/to') instead.
  if Rails.root.join('tmp', 'caching-dev.txt').exist?
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

40 files inspected, 1 offense detected
```

翻成白話文就是，RuboCop 幫我們偵測到了「未遵循 [Rails/FilePath](https://docs.rubocop.org/projects/rails/en/latest/cops_rails/#railsfilepath) 規則」的原始碼，還很親切地告訴我們是在哪個檔案的哪一行，以及修改的建議。我們通常有以下選項：

- <del>就讓它噴錯，什麼都不做</del>
- 照著 RuboCop 的建議修改程式碼
- 調整規則，不改原始碼
- 保留規則，但將這段程式碼排除在外

> 一般來說，我們會把 .rubocop_todo.yml 中的 cop 逐一註解掉，處理過後使之不再報錯，直到整個 todo 可以被安全移除為止。

#### 照建議修改

在這個例子裡，程式碼的修改很單純，照著建議去改就可以了：

```ruby
 if Rails.root.join('tmp/caching-dev.txt').exist?
```

改過後再執行一次，確認沒有問題：

```ruby
$ rubocop
Inspecting 40 files
........................................

40 files inspected, no offenses detected
```

不過實務上，尤其是在比較有歷史的 code base 裡，是很有機會遇到「只是換個寫法，測試就掛了」「要改就只能整段重寫」等狀況的。因為這真的很重要所以要說第三次：RuboCop 這一類的工具只是幫助我們找出潛在的風險，它給的建議也不是「標準答案」（寫程式本身就沒有標準答案這回事），「怎麼做才是最好的？」最終還是要用自己的專業做判斷。

#### 調整規則

反過來說，如果大家覺得 RuboCop 抱怨的程式碼沒有問題，那就來<del>解決提出問題的人</del>調整 RuboCop 的設定檔就好。一種作法是直接放大絕，把整個規則 disable 掉：

```ruby
# .rubocop.yml

Rails/FilePath:
  Enabled: false
```

逃避雖然可恥但是有用？這雖然也是一種解法，但比較好的作法是去修改規則的內容，而不是把規則整個拿掉。參照官方文件可以得知 Rails/FilePath 預設的樣式是 `path/to/file`，如果希望統一成 `('path', 'to', 'file')` 的格式的話，就要另外指定為：

```ruby
# .rubocop.yml

Rails/FilePath:
  EnforcedStyle: arguments
```

修改後再執行一次看看有沒有問題：

```
$ rubocop
Inspecting 40 files
...................................C....

Offenses:

spec/rails_helper.rb:15:5: C: Rails/FilePath: Please use Rails.root.join('path', 'to') instead.
Dir[Rails.root.join('spec/support/**/*.rb')].sort.each { |f| require f }
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

40 files inspected, 1 offense detected
```

因為規則改了，所以原本沒有問題的地方變成有問題了。照理說，因為規則改了，我們應該要去改 rails_helper.rb 的程式碼才對，但因為正好可以拿來展示語法，我們就順勢來用排除法吧。

#### 排除特定程式碼

當我們希望「這個 cop 有其必要」，但「在這個特例下可以排除」的時候，可以用 inline 的方式對程式段落做 disable：

```ruby
# rubocop:disable Rails/FilePath
Dir[Rails.root.join('spec/support/**/*.rb')].sort.each { |f| require f }
# rubocop:enable Rails/FilePath
```

如果是「這個 cop 有其必要」，但「這些目錄下的檔案可以不用遵守」的話，也可以直接在設定檔裡做排除。例如在 `.rubocop.yml` 中，我們已經預設讓 db migration 和 rake task 之類的程式碼，可以不受 metrics 條件的限制：

```ruby
# .rubocop.yml

Metrics:
  Exclude:
    - db/migrate/*
    - Rakefile
    - Gemfile
    - config/**/*
    - spec/**/*
    - lib/tasks/**/*
```

#### 自動修改

RuboCop 也支援自動修改。要注意的是，並不是每一個 cop 都有支援（請自己看文件確認），就算支援，一般也不建議用在單純語法或排版統一以外的地方。Rails 開發者最常用到的可能是這個 XD

```
$ rubocop --auto-correct --only Style/FrozenStringLiteralComment
```

執行下去後，RuboCop 就會幫我們補好煩人的這一句：

```
# frozen_string_literal: true
```

#### 結語

善用工具，可以讓團隊協作的品質更整齊，但要小心不要陷入追求標準答案和滿分的陷阱，不然很容易本末倒置。Ruby 圈類似的檢測工具還有：

- [reek](https://github.com/troessner/reek): 偵測可能的 code smell
- [rails\_best\_practices](https://github.com/flyerhzm/rails_best_practices): 這個在做什麼應該很明顯
- [flay](https://ruby.sadi.st/Flay.html): 偵測可能的重覆程式碼
- [SandiMeter](https://github.com/makaroni4/sandi_meter): 檢查程式碼是否符合 Sandi Metz 提倡的四大原則

有機會的話都可以拿來玩看看 :)

#### 參考資料

各個 cop 的詳細設定方式和範例都可以在官方文件裡查到：

- [rubocop 官方文件](https://docs.rubocop.org/en/stable/)
- [rubocop-rails 官方文件](https://docs.rubocop.org/projects/rails/en/latest/)

(Photo Credit: "RoboCop" by [Andrew Milligan sumo](https://www.flickr.com/photos/24470821@N04) is licensed under CC BY 2.0)

---

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


post-機器戰警 RuboCop/cover

機器戰警 RuboCop 

post-還在跟複雜的 CSS 的設定奮鬥嗎？用 Tailwind 來幫你實現真正的高效整潔！/cover

還在跟複雜的 CSS 的設定奮鬥嗎？用 Tailwind 來幫你實現真正的高效整潔！


「工程師」是近年來最受人矚目的職業之一。在每天生活不可少的各種便利服務裡，都有工程師付出的影子。
也因為這樣，近年來「轉職當工程師」，變得非常熱門。國內外許多名人也不約而宣導「學習寫程式」的好處，這股學習熱潮甚至讓一些父母從小學就開始讓孩童接受程式教育。寫程式不僅幫助訓練邏輯思考，其延伸的相關 Know-how 對高科技年代追求高薪也非常有用。

更由於工程師屬於「年資加值度高」的工作（亦即越資深薪酬越高），轉職最好趁早，使不少人趨之若鶩踏上轉職當工程師之路。

但說到「轉職工程師」，不少非本科的人會有這種疑惑：
「我不是理組出身的耶，我可以嗎？」
「數學要很好吧？」
「不是輕易就能學會吧，要學個好幾年吧？」
「寫程式這麼難適合我嗎？」

這些都是考慮轉職成為工程師時常見的煩惱。今天我們想藉由這篇文章告訴大家，學寫程式不但不難，轉職當工程師更可以短短幾個月就成功。

五倍紅寶石創建的轉職服務：全端工程師實戰訓練營「ASTRO Camp」，主打從素人轉職全端工程師，如今正在報名下一期，現在的課程也如火如荼進行中。輔導近上百位素人成功轉職工程師的五倍紅寶石程式教育機構，可以很肯定地告訴你：

相關科系重要嗎？數理很好重要嗎？

這些都不是轉職當工程師的關鍵因素。

數理能力固然有助強化邏輯力，但不是左右程式語言能力最大的因素。
簡單來說，轉職工程師只有一件事最重要：「找到你的熱情，並積極，積極，積極！」

## 熱情

找到熱情：在轉職初期，如何維持動力會是最重要的事。
學習一樣新技能時，必定會有碰撞期。所以能明確化動機，具現化想達成的目標，會是非常重要的事。

五倍紅寶石在全端工程師實戰訓練營裡，就精選了網站工程師最熱門的實作主題，以培訓出能建構能實作市場主流服務的能力為目標，從0開始教大家寫程式。
即便是新手，也能預期自己上完課後培養到的技能，目標具體，就不會輕易慌張或打退堂鼓。

## 積極
積極會是幫助你學習時克服困難不斷成長的主因。當然，轉職時也一樣。

課堂上遇到聽不懂的，是否有積極詢問老師、助教？
練習作業時是否有確實完成？
回家後有沒有複習？
教室裡上有沒有積極和同學切磋？
畢業後是否積極求職？

這些課前、課中、課後的功課，如果有按部就班做到。我們有足夠的案例大聲說，雖然是「完全素人」，但能在課程結束甚至課程進行中就找到工作的同學，真的很多、很多、很多。

## 持續進修

畢業後拿到轉職的門票，但是如何讓你從「成為工程師」到「成為高薪的工程師」，關鍵還是在「不斷花時間維繫熱情」。我們鼓勵所有學員每週回到教室跟學長姐同學們切磋、舉辦讀書會拓展知識，甚至如果開始新工作後發現自己想進修特定方面的技能，也可以參與五倍紅寶石的短期假日課程來持續進修。再沒時間，也可以隨時透過 LINE 群組跟同學們持續切磋，讓助教繼續解惑。

從「做得到」到「做得很好」，差異在於，如何持續投入熱情，追求突破。

看到這裡你有沒有發現：轉職工程師的眉角，從來不在是否相關科系、數理底子好不好。
而是唯一一件也最重要的：學習態度。

只要學習態度正確，你也一定能成功搭上轉職科技業就業的浪潮，成為全端工程師，並且成為高薪全端工程師！

系列文章：

- [面試攻略(一) 初心者的三大面試攻略心法](/posts/3skills-of-interview)
- [面試攻略(二) 藏在自薦信 ( Cover letter) 裡的魔鬼](/posts/3skills-of-interview-2)
- [職涯原力：善用企劃力，為自己的生命校正](/posts/career-power-planning)
- [職涯原力：解開千千結的邏輯力](/posts/career-power-logic)

post-想當工程師？學寫程式，只有這件事最重要！/ cover

想當工程師？學寫程式，只有這件事最重要！

post-Vue.js 新手如何製作口罩地圖？一起來貢獻小小力量吧！/ cover

Vue.js 新手如何製作口罩地圖？一起來貢獻小小力量吧！


「工作上出錯了，不知道問題在哪」
「老闆需要我建議最佳方案，不知道從何建議起」

這些狀況對你來說熟悉嗎？

要鍛鍊這種解決問題、評估風險的能力，你就不能略過「邏輯力」。
特別是職場上的困難往往變因極多，如何梳理原委，排序優先順序，解決牽一髮而動全身的問題，正是需要發揮邏輯力的地方。

## 分辨變因屬性

把可能的變因列出來，可以幫助你整理思緒，客觀看待事情全貌。
建議把變因進一步分成「可掌握」（只與自己有關或有權解決）或「不可掌握」（與他人有關，又無法影響他人行為）。

## 排序優先度
依序檢討哪個變因對解決當前情況最有力，列為優先。但如果優先變因的「影響因子」全為不可控，那選擇優先解決它可能吃力不討好。

## 判斷影響力

找出「變因屬性」和「變因優先度」的交集。自己可掌握又排序優先的，影響力最大，應該先解決；然後是自己掌握幅度有限，但排序次優先的項目。雖然無法直接掌握，但可透過其他人事物施力，就能成為次優先的項目。無法施力又優先度低的影響力最小，可選擇最後處理。

這個步驟重要的是採取行動。

以上三個心法如果落實到實際範例上，可為：

假設 Joe 在公司內擔任專案經理，但是無法準時交付開發進度，因此被客戶客訴，老闆十分生氣。

結果來看是無法準時交付成品，但可能的變因有：<br>
1). 沒有即時分辨風險：客戶提出的時程與規格本來就無法合理完成，是風險很高的承諾。<br>
2). 沒有提前預警：工程師遇到障礙沒有或無法反應，導致無法提前告知客戶。

無論是 (1) 或是 (2)，其關鍵因素都在於有沒有辦法迅速判斷需求是否合理：不論是時程或規格的合理性，結果才導致被客訴。所以 Joe 需要即時判斷需求＆規格，團隊是否能準時交付。

要達成這一項目標，又有兩種方式：<br>
A). 掌握「增加判斷能力」必備知識<br>
B). 一律由主管審核確認<br>
C). 請具有該專業能力的要好同事協助判斷<br>

但是選擇 (B)可能會增加主管的工作負擔，並消減自己在職場上的價值。
短期要解決可以選擇 (C), 但是長期要完全治療這個狀況，則是要選擇 (A).

用這種方式來列出所有事物的關聯性與重要度，就變得很好判斷每個解決方案是否該執行。

看起來很複雜嗎？其實你只是需要多加一些判斷指標，就可以很快完成這些思考。
那麼，有沒有訓練邏輯力最有效的方式呢？

很有力的管道就是學寫程式！<br>
程式語言的架構讓你可以預期要達成這些 output 需要多少 input，循線判斷影響因素，並進行除錯。不過，「寫程式」聽起來有點難，是嗎？

其實只要掌握一個要訣，學習寫程式可以是一眨眼的事情。
下一篇，我們就來告訴你那個要訣是什麼。

系列文章：

- [面試攻略(一) 初心者的三大面試攻略心法](/posts/3skills-of-interview)
- [面試攻略(二) 藏在自薦信 ( Cover letter) 裡的魔鬼](/posts/3skills-of-interview-2)
- [職涯原力：善用企劃力，為自己的生命校正](/posts/career-power-planning)
- [想當工程師？學寫程式，只有這件事最重要！](/posts/to-be-an-engineer)

技術文章