五倍直播間

Blogs - Sidebar

SASS (Syntactically Awesome Stylesheet) 是一種預處理語言 (pre-processing language)，透過 SASS 可以更有效、更結構化的產生 CSS，並有助於減少撰寫重複的樣式，讓你的 CSS 更易於維護。今天要跟大家分享的是 SASS 的 @mixin 與 @include。

SASS 提供兩種語法，分別是 SCSS (Sassy CSS)，以及 Indented，最大的差別在語法上 `{}`、`;`、`=` 的有無，以及前者的副檔名為 `.scss`，後者的副檔名為 `.sass`，筆者在文章內採用 SCSS 的語法來跟大家分享。

## 前置準備
範例中我們使用下列工具：

- 編輯器：Visual Studio Code (以下簡稱 VSCode)
- 安裝套件：Live Sass Compiler、Live Server

套件 Live Sass Compiler 安裝完成後，在 VSCode 的右下方有一個 `Watch Sass` 按鈕，他的功能是將我們撰寫好的 `.scss` 或 `.sass` 編譯過後產生 `.css`，我們在 html 裡要引入的就是這個被產生出來的 CSS 檔案。

當原來的 `Watch Sass` 按鈕變成 `Watching...` 的狀態時，我們還是可以繼續編輯 `.scss` 或 `.sass`，在編輯完成存檔的當下就會自動編譯並更新之前產生的 `.css`。
有關 `.min.css`、`Prefix` 的設定，可以參考 [Setting Docs](https://github.com/ritwickdey/vscode-live-sass-compiler/blob/master/docs/settings.md) 的說明。

套件 Live Server 安裝完成後，在 VSCode 的右下方會出現 `Go Live` 按鈕，在我們編輯好 HTML 並確實引入 CSS 檔案，存檔後按下該按鈕，會自動在瀏覽器開啟網頁，顯示最新存檔後的畫面。(本篇著重在 SASS 的使用分享，所以先暫時略過畫面的部份囉)

## 什麼情況需要用到 @mixin、@include？

- 發現自己在 CSS 裡一直寫著重複的樣式。
- 網頁元件可以歸納出共同的特性時 (可能按鈕都有陰影、或是每個文章區塊都有邊框...等等)。
- 認為自己開發網頁 CSS 效率遇到瓶頸，欲尋更好的撰寫效率。

## 語法
### @mixin
- 以 `@mixin` 開頭，並自定義一個名稱，將需要重複使用的 CSS 放在 `{ }` 裡面。
- 定義好的 `@mixin` 是可以重複使用的。
- 可以在名稱後面加 `()`，放入參數、預設值做進階的使用。
- 參數名稱以 `$` 開頭。

```scss
  @mixin example_base {
    ... // 定義 CSS
  }

  @mixin example_advanced($parameter1, $parameter2) {
    ... // 定義 CSS
  }
```

### @include
- 搭配 `@mixin`，我們在 `@mixin` 定義好 CSS，再透過 `@include` 呼叫使用。
- 若定義的 `@mixin` 有設定參數，那麼在呼叫使用的時候，就要傳入相對應的引數。

```scss
  selector1 {
    @include example_base; // 呼叫使用在 @mixin 定義的 CSS
    ... // 這個 selector 的其他 CSS
  }

  selector2 {
    @include example_advanced(argument1, argument2); // 呼叫使用在 @mixin 定義的 CSS
    ... // 這個 selector 的其他 CSS
  }
```

## 範例一：基本用法
- 假設在網頁中，我們每個按鈕 `.button` 的樣式統一都是邊框加 5px 的圓角再加一點點陰影，每個 `.article` 要邊框加 5px 的圓角但不要陰影，每張圖片 `.image` 也都邊框加 5px 的圓角再加一點點陰影好了，這些 "邊框加 5px 圓角，或許再加一點點陰影" 的樣式，我們就可以把 CSS 拉出來做 `@mixin`，並在需要該樣式設定的時候使用 `@include`:

```scss
  @mixin rounded-border {
    border: 2px #333 solid;
    border-radius: 5px;
  }

  @mixin shadow {
    box-shadow: 1px 2px 2px #666;
  }

  .article {
    @include rounded-border;
  }

  .button {
    @include rounded-border;
    @include shadow;
  }

  .image {
    @include rounded-border;
    @include shadow;
  }
```

- 編譯過後的 CSS 呈現如下：

```css
  .article {
    border: 2px #333 solid;
    border-radius: 5px;
  }

  .button {
    border: 2px #333 solid;
    border-radius: 5px;
    -webkit-box-shadow: 1px 2px 2px #666;
            box-shadow: 1px 2px 2px #666;
  }

  .image {
    border: 2px #333 solid;
    border-radius: 5px;
    -webkit-box-shadow: 1px 2px 2px #666;
            box-shadow: 1px 2px 2px #666;
  }
```

- 將統一的樣式抽出來寫成 @mixin 的好處是，如果該樣式需要做調整的話，那麼只需要改 @mixin 這一個地方就好了，不用再一個一個找(或搜尋)。
- Live Sass Compiler 可以設定 Prefix，在編譯過後的 CSS 會自動加上。

## 範例二：使用參數
- 假設在網頁中，我們有一個遮罩覆蓋的效果，在 `.avatar`、`.product-image` 這兩個 class 都需要用到它，差別在遮罩透明度不一樣，那麼我們可以在 SASS 檔案裡這樣寫：

```scss
  // 定義遮罩覆蓋的基本屬性
  @mixin cover($opacity_value) {
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    opacity: $opacity_value; // opacity 的值由傳進來的參數決定
  }

  .avatar {
    @include cover(0.9); // 呼叫的時候帶入數值
  }

  .product-image {
    @include cover(0.8); // 呼叫的時候帶入數值
  }
```

- 編譯過後的 CSS 呈現如下：

```css
  .avatar {
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    opacity: 0.9;
  }

  .product-image {
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    opacity: 0.8;
  }
```

## 範例三：使用參數 + 預設值

- 定義 @mixin 時若有使用參數，在呼叫的時候必須要依序傳入相對應的引數。
- 以範例一的 rounded-border 再作延伸：

```scss
  /*
    在 rounded-border 這個 @mixin 定義中，我們"依序"使用三個參數，並給它預設值：
    1. $color: border 的顏色，預設為 #333
    2. $line_style: border 的線條樣式，預設為實線
    3. $radius: border-radius 預設為 5px
  */

  @mixin rounded-border($color: #333, $line_style: solid, $radius: 5px) {
    border: 2px $color $line_style;
    border-radius: $radius;
  }

  .article {
    // 全部套用預設值，可以不用加 ()
    @include rounded-border;
  }

  .button {
    /*依序帶入引數：
      $radius 使用預設值，因為是排序在最後一個，可以不用帶入引數
      只要依序帶入前面 $color、$line_style 的值即可*/
    @include rounded-border(#f00, dashed);
  }

  .image {
    /*依序帶入引數：
      $color 使用預設值，因為不是排序在最後一個，若略過它直接帶入第二個值會導致配對錯誤，因此後面帶入的引數必須指定參數名稱*/
    @include rounded-border($line_style: dashed, $radius: 3px);
  }

```

註解看起來好像很複雜？這邊有幾點要稍微留意一下：

1. @include 的時候必須要依序傳入相對應的引數，講白話就是："一個蘿蔔一個坑"，跳過前面的坑，就要指定後面坑的名字，這樣後面的蘿蔔才不會跳錯坑 XD
2. 參數如果一次用太多反而會造成不便，因為自己還要記清楚那些參數的順序、數量，所以在設計 @mixin 時，要考量到使用的彈性跟方便性哦～

- 編譯過後的 CSS 呈現如下：

```css
  .article {
    border: 2px #333 solid;
    border-radius: 5px;
  }

  .button {
    border: 2px #f00 dashed;
    border-radius: 5px;
  }

  .image {
    border: 2px #333 dashed;
    border-radius: 3px;
  }
```

## 結論

  SASS 讓 CSS 寫起來很像在寫程式，對於沒有程式基礎的使用者來說其實也不需要太擔心， `@mixin` 的主要用意就是整理會重複使用到的 CSS，需要它的時候就用 `@include` 把它 "召喚" 出來，需要修改這些大量重複的 CSS 時，只要修改定義的地方即可，不用再大費周章的到處修改(也省去很多複製貼上)，是不是變得更有效率呢？


post-新手也可以輕鬆玩轉 SASS - @mixin and @include

新手也可以輕鬆玩轉 SASS - @mixin and @include


## 前言

這篇文章主要是提供給初學網站設計或由平面設計轉網站設計新手的文章。

我將分享我在設計網站的過程，希望可以幫助新手在開始進行時不至於毫無頭緒。

另外，不管你是新手設計或是已經入行一陣子的設計師，在設計的領域上每個人獲得靈感的方式、設計流程都不同，這邊分享其中一個方式，提供你作為參考，**期許你也可以找到屬於自己的設計流程和工作模式，一起面對各種設計挑戰**。:)

<br>
<br>

## 第一步｜你所要設計的網站類型？

首先，你必須要確認你目前設計的網站是屬於哪個類型？

他要達成什麼目的？他提供什麼樣的服務？解決什麼樣的問題？還有需要使用這個網站的人是哪群人？

亦或者你想要在這個網站上嘗試什麼？

試想一下，[Airbnb](https://www.airbnb.com.tw/) 和 [Netflix](https://www.netflix.com/browse) 的網站，是不是完全不同？

![post-如何著手設計你的第一個網站？](//images.ctfassets.net/8er52l3j5u76/4lFt3O8wTEowalB7qElwaN/15aa3fbf71e61a306e8e268cc987bd58/airbnb_netflix.jpg)

假設，今天是需要設計餐廳網站，是什麼樣的餐廳呢？燒烤還是義式料理？品牌定位又是如何呢？主打的是高單價的精緻料理還是平價小吃呢？
接著我們就可以稍稍想像，如果是家高級料理那麼會是什麼樣的感覺呢？是沈穩低調的？還是金碧輝煌呢？

通常我會聯想這個品牌的所有 **關鍵詞、意象** 列出來或是畫出類似心智圖的草稿。
這些詞彙、意象將有助於我們發想。

<br>
<br>

## 第二步｜開始規劃你的網站吧！別忘了給別人看看你的規劃吧！
有了對這個網站初步的想像後，接著拿出你的筆，先以樹枝狀的方式，列出你需要有哪些頁面、哪些區塊吧！

一般來說，這會由 PM、網站企劃從客戶端或是提出網站需求的部門囊整所有網站的需求，列出網站的功能、網站架構(有哪些頁面)；接著針對單一頁面進行那個頁面的規劃，包含這個頁面有哪些區塊、功能、按鈕，他大概會放在哪個位置？

一般會使用 [wireframe](https://blog.akanelee.me/posts/159788-what-is-wireframe/)  ，大致畫出後向需求的一方(客戶端)、工程師、設計師等人確認，在這個階段讓團隊的不同職位的人了解需求和架構，就比較能夠掌握時程、流程或是開發上可能會遇到的問題。

![post-如何著手設計你的第一個網站？](//images.ctfassets.net/8er52l3j5u76/36U8y2WoGFxi8k4AuWy4m0/fc6391a3796ed2511c9dd7cf7ef09520/wireframe.jpg)

所以，在網站規劃的初期，不妨也給不同專業的朋友看看吧，也許會有助於你釐清你的網站內容和流程喔！

<br>
<br>

## 第三步｜如何尋找靈感？
尋找靈感？不就是看一大堆設計就好了嗎？

沒錯，看大量的設計作品，是提升美感和設計能力的方式之一，但除了 **看** 圖片外，還必須學著分析，將流行的或是你喜歡的設計風格、樣式 **「輸入」** 到你的腦中，等到下次遇到適合的專案時，就有一個基本方向。

那麼該如何讀設計呢？在此也不限於 **設計** 領域，也需要欣賞純藝術、文學、展覽、立體的設計等。

剛開始你可能會搜尋大量的圖片或是在 [pinterest](https://www.pinterest.com/) 上儲存各種 Board，試著分析這些被存取的圖象的共通性？ 他們是不是都用插畫？ 使用什麼樣的色彩？ 畫面構成又是如何？

![post-如何著手設計你的第一個網站？](//images.ctfassets.net/8er52l3j5u76/72FXnx7495f8kLXoIQbqu3/d7a5b17fb6d9eb5d6903a722cd10a036/pinterest.jpg)

<br>

關於靈感搜集部分，以下是我經常瀏覽的網站：

* [Behance](https://www.behance.net/)
* [Dribbble](https://dribbble.com/)
* [Pinterest](https://www.pinterest.com/)
* [Lymma](https://www.lymma.net/)
* [Awwwards](https://www.awwwards.com/)
* [CSS DESIGN AWARDS](https://www.cssdesignawards.com/)
* [1GUU](https://1guu.jp/)
* [Web Design Clip](https://www.webdesignclip.com/)

<br>
<br>

## 第四步｜Case study
除了上述讀設計外，也可以針對現行的網站研究，試著去挖掘別人在製作這個網站時，為什麼會強調這個功能？或是為什麼會這麼設計呢？

再來如果是針對台灣市場做的購物網站，就不得不研究蝦皮、PChome、博客來、Pinkoi、lativ 手機版和電腦版又有哪些差異呢？
如果你對你所設計的網站或是某個功能、介面毫無頭緒時，可以研究的就是那個領域你想到的知名企業的網站或是常用的 app，因為好的網站、app 通常是經由一群團隊劃去維護的，當中不乏 UI/UX 設計、工程師、使用者反饋等，所以在功能設計上多少會有脈絡可循。

![post-如何著手設計你的第一個網站？](//images.ctfassets.net/8er52l3j5u76/4bGxYtGVbOg1uvzjXNtIdi/9c6cd06414f750155e168d8fc934b1ef/shop_ui.jpg)

像是我可能會因為要設計某個畫面，如果不知道這其中一個按鈕應該要放上面還是下面或是要不要很醒目時，這時我會去找同類型網站、相同功能，比較不同網站間這個功能再加上這個按鈕時，是怎麼設計的？

另外也可以閱讀 [Medium](https://medium.com/) 上的文章或是 [設計大舌頭](https://designtongue.me/) 部落格當中的案例分析，然後試著也自己分析看看吧！

更多的 UI / UX 部落格：

* [AAPD-As A Product Designer](https://medium.com/as-a-product-designer)：UI / UX 分享、設計資源與心得
* [獸群之心 / Soking](https://medium.com/@soking)：UX、產品設計分享
* [曝鹿刊物](https://medium.com/@soking)：設計經驗分享、美感養成
* [設計大舌頭](https://designtongue.me/)：UI / UX、互動設計、設計趨勢相關文章
* [嫁給 RD 的 UI Designer](https://blog.akanelee.me/)：UI / UX 設計分享

<br>
<br>

## 第五步｜善用網站的特性，玩設計吧！
你可以經過上述的內容，去學習、挖掘網站的一些特性，像是：

- **網站的畫面是活動的**：RWD 的設計已經是現行網站都必須考量的。你必須知道網站的畫面是具有彈性的，請考慮你的文字、圖片在桌機時和手機版時、不同尺寸的螢幕下該如何呈現？

- **使用者是不具耐心的**：在網路的世界，有太多有趣的事物在吸引使用者，你該為他們整理出網站重點。
    你需要區分出網站的資訊層級，將最重要的區塊或文字用顏色或按鈕的形式凸顯出來，讓使用者短時間了解這個網站的重點或是你希望他做什麼行動？

- **網站是互動的**：網站上你可以和使用者互動，像是滑鼠滑過會有什麼效果？滑鼠點擊又會出現什麼效果？或是滾動畫面時會有什麼樣的變化？透過這些不同的效果，可以豐富這個網站瀏覽的過程。(但是須小心使用，過的動畫或效果反而容易搞亂視覺動線、影響操作等，都會造成反效果。)

- **網站是具層次的**：透過互動效果，你應該 **跳脫平面** 的概念；網站很有趣的部分是透過元件(分頁、按鈕等)你可以有 **資料收合** 的概念。
    試想一下你的資料將會分別有個資料夾，此時在同一張紙上，比較次要的資料就可以收在資料夾內，等使用者需要時再打開來；而不是一次展開所有資料。

<br>

![post-如何著手設計你的第一個網站？](//images.ctfassets.net/8er52l3j5u76/3FQtrX1lMNTfUrTlSSXihR/bde91d7b2126507131e75220f4941569/layouts.jpg)
另外加上前端程式語言發展，網站已經不限於中規中矩的 section 一個一個區塊明顯的設計，他可以擁有圖層前後的概念又或者是分散式、格式的設計、甚至是像鏡頭一樣拉近拉遠的效果、橫式瀏覽的效果等。

最後，現在各種有趣的瀏覽方式正在被不斷產生，網站設計也越來越重視使用者在瀏覽網站當中的 **情境、體驗**，可以用遊戲的方式或是像讀故事書方式等，讓瀏覽網頁有不同的可能性；試著去細細體會那些你覺得有趣的網站，他是哪些細節上讓你多停留、嘗試的？他又是營造出什麼氛圍讓你印象深刻的呢？


posts-如何著手設計你的第一個網站？

如何著手設計你的第一個網站？


（範例會以 Rails 來實作，登入的部分使用 [devise](https://github.com/plataformatec/devise) 套件為例）

### 前言

不知不覺來到了 2019 年末。從 2016 年到現在，[AMP](https://amp.dev/) 也越發成熟完整（但我怎麼還是覺得 bug 還是有點多w），有很多實用的 components 也有豐富的範例可以參考。如果想要大大地提升網站在手機上的搜尋排序，實作 AMP 網頁會帶來相當不錯的效益呢。

由於 AMP 的種種限制，除了拿來實作 content 為主、功能不多的網站，大家很可能仍然對 AMP 望之卻步。今天就要來跟大家介紹透過實作 amp-access 顯示登入狀態的部分。

### 為什麼 Cache 頁面會是未登入呢？

當你開開心心地做了一個 AMP 網站，也丟上 Google Cache（或其他家的 AMP Cache，這裡以 Google 的為例），愉快地在搜尋頁面點下自家網站的連結，讀取速度飛快又美好 ♪

檢查了一下你突然發現：「欸？我不是一直保持登入狀態嗎？為什麼在 Cache 頁面上是沒有登入的呢？」

![post-透過 amp-access 讓你在 Cache 頁面也能順利保持登入！](//images.ctfassets.net/8er52l3j5u76/5hDvzQhSIatSv0Y4YR1ynS/489fb2ba0dca5d3810e614a59ff20359/original-n-cache-site-diff.png)

對於在本站已經登入的使用者來說，明明已經登入你的網站了，但是從搜尋結果進去的頁面卻是未登入狀態，也會感到相當疑惑，體驗上也不甚很好。

我們先來探討，究竟這個狀況到底是怎麼發生的呢？

舉例來說，原本頁面的 view 可能是像這樣：

```erb
<% if user_signed_in? %>
    親愛的 <%= current_user.name %> 你好！
<% else %>
    你還沒登入哦！快點擊
    <%= link_to('這裡', new_user_session_path) %>
    登入吧～
<% end %>
```

當 Google AMP Cache 要來爬你的網站的時候，他當然是沒有登入的狀態，所以就會爬到寫著「你還沒登入哦！快點擊這裡登入吧～」的版本，於是你的 cache 頁面永遠都是沒登入的狀況。

如果希望 cache 到的頁面上可以正常地顯示「親愛的 XXX 你好！」，可以借助 amp-access 這個元件來實現。

### Components

[AMP-access](https://amp.dev/documentation/components/amp-access/) 主要分成這些部分：

#### AMP Reader ID
匿名、唯一、不跨裝置的 ID，如果使用者沒有清理 cookie，有效期會是一年。

根據官方文件：
> Publishers can use their own authentication cookies, or they may rely on the Reader ID, or a combination of both.

如果是透過 cookie 來獲取登入資訊的話其實可以不用到 Reader ID。

#### Access Content Markup
用來定義網頁上的哪些部分要在什麼情況底下顯示或不顯示的 markup。

比方說你希望 signedIn 為 true 時顯示底下的元素，就會在元素上加上 `amp-access` 這個 attribute。

```html
<section amp-access='signedIn'>
    登入的使用者會看到這行字哦！
</section>
```

如果希望是 signedIn 為 false 才顯示：

```html
<section amp-access='NOT signedIn'>
    沒有登入的人會看到這行字哦！
</section>
```

按照上面的寫法，你可能預期一開始元件都不會出現，一直到 Authorization response 回來才會出現元件，但事實上這些元件一開始都會在畫面上，當 Authorization response 回來時才會「跳閃」一下，不該出現的元件才會隱藏起來。

![post-透過 amp-access 讓你在 Cache 頁面也能順利保持登入！](//images.ctfassets.net/8er52l3j5u76/5Rmc2q5rZqsWOrs4iCBD55/72585ece29ff713e1381eab3c3042948/without-amp-access-hide.gif)

如果希望一開始畫面剛 render 時不要顯示這個元件，可以加上 `amp-access-hide` 這個 attribute：

```html
<section amp-access='signedIn' amp-access-hide>
    一開始不會顯示，確定 response 中 signedIn 為 true 的話會看到這行字哦！
</section>
```

更多 access content markup 的語法請參考[官方說明](https://amp.dev/documentation/components/amp-access/#appendix-a:-%E2%80%9Camp-access%E2%80%9D-expression-grammar)。

#### Authorization Endpoint
在 AMP runtime 的時候會打這個 endpoint，根據 response 的 JSON 內容來 render 畫面。

#### Pingback Endpoint
當使用者開始瀏覽畫面或是完成 login 的時候，AMP 會去打 Pingback Endpoint。Pingback Endpoint 不需要 response，有 response 也會被忽略。比方官方提供的 [Paywall 範例](https://github.com/ampproject/samples/tree/master/amp-paywall-demo)，Pingback 就被用在計算使用者已瀏覽幾篇 article 等。

#### Login Link and Login Page
如果會用到 Reader ID 來實作登入的話，就會需要在 AMP-Access configuration 的時候加上 login 相關的 link：

```json
{
  "login": "https://mySite.blah/login?rid={READER_ID}"
}
```

接著在畫面上加上連結讓使用者登入：

```html
<a on="tap:amp-access.login">登入</a>
```

但因為等等的範例會是用自己的 cookie，就不會在 configuration 加上 login link。

### 簡易圖解

到這裡還看得很糊沒有關係，我們來大致了解一下 AMP-Access 大概是怎麼運作的。

1. 一開始 AMP runtime 夾帶著 cookies 會去打你（或你們家的後端工程師）寫好的 authorization endpoint。

![post-透過 amp-access 讓你在 Cache 頁面也能順利保持登入！](//images.ctfassets.net/8er52l3j5u76/7tB2QwtyHMdXK28ZZesPmq/5621d9133f44fdd23fcb2b81b2c48957/request-to-authorization-endpoint.png)

AMP 提供一些 [Access URL Variables](https://amp.dev/documentation/components/amp-access/#access-url-variables）)。比方說如果你的 authorization endpoint url 是像這樣：

```
https://yourSite.blah/api/amp-access/authorization?ref=DOCUMENT_REFERRER&rid=READER_ID&url=CANONICAL_URL"
```

實際上 AMP runtime 打 endpoint 的時候，rid 會變成 `rid=amp-OFsqR4pPKynymPyMmplPNMvxSTsNQob3TnK-oE3nwVT0clORaZ1rkeEz8xej-vV6`，url 變成 `https://yourSite.blah`。

2.這個時候你寫的 authorization endpoint 可能會根據 cookie 辨識使用者，回傳一個 json。

![post-透過 amp-access 讓你在 Cache 頁面也能順利保持登入！](//images.ctfassets.net/8er52l3j5u76/4t34TUCIcNrI5Z1DUVtDiu/831af27f1ac93dd674f11192d201fdc9/access-content-markup-replacement.png)

3.於是在 cache 頁面上，登入狀態也能正常顯示了，開開心心 ♫

### CORS in AMP

然而 AMP 有一些關於 CORS (Cross-Origin Resource Sharing) 的[規範](https://amp.dev/documentation/guides-and-tutorials/learn/amp-caches-and-cors/amp-cors-requests/)。

如果沒有把網頁送上 cache，使用者是直接向你家的 server 送 request。但是如果使用者從 AMP Cache 那邊請求你的網頁， Cache 頁面在 AMP runtime 的時候會向你的 server 打 authorization endpoint，這個時候就會變成跨網域的連線了。

因此 AMP 也有針對這個情境，要求實作簡單的 request verification 並且根據他的要求設定 access control 相關的 header。

基本流程大致如下：
![post-透過 amp-access 讓你在 Cache 頁面也能順利保持登入！](//images.ctfassets.net/8er52l3j5u76/4GK6XyAk6fWlr0z1FVEK3j/ab659b6f1f0b314c7966a5ae2f697eb3/CORS-process.png)

1.如果 Header 有帶 `Origin`，就檢查是否是 allowed origins：

- 你自己的網站 eg. `mySite.blah`
- AMP cache eg. `mySite-blah.cdn.ampproject.org`

origin 不在 allowed origins 的 request 就讓你的 server 回傳 HTTP status 403 的回應，慢走不送。

2.如果沒有 `Origin` header 的，就檢查是否有 `AMP-Same-Origin: true`，有才放行，沒有一樣回 403。

當 AMP Runtime 在送 XHR request 的時候，如果是在 same origin 時，會自動幫你加 `AMP-Same-Origin: true` 這個 header。

3.在 response header 加上 `Access-Control-Allow-Credentials: true` 和 `Access-Control-Allow-Origin: <origin>`

這裡的 `<origin>` 指的是 response 的 origin。

聽到這裡，是不是覺得其實沒有很複雜呢（是嗎

那就來動手試試看吧！

### 三分鐘動手實做！
如果沒有碰壁卡關，view 沒有要大改的話，應該是可以在三分鐘內完成吧（欸

開始之前，請先準備一個有實作 AMP 的 Rails Application。

#### CORS Authentication
我們先來打造一個 base controller，讓之後實作的 API 都繼承這個 controller。（其實要改成 concern 也是可以）

除了 amp-access ，如果實作 AMP 中的 XHR request 等等也會有 CORS 的情境，這個時候就可以直接繼承這個 controller。

```ruby
module Api
  class BaseController < ApplicationController
  end
end
```

如果`Origin` 屬於 allowed origins（你的網站、AMP Cache），或者有 `AMP-same-origin: true` 的 header 才放行。且加上規定的 response header：

```ruby
module Api
  class BaseController < ApplicationController
    before_action :cors_verification
    ALLOWED_ORIGINS = [
      'https://mySite.blah',
      'https://mySite-blah.cdn.ampproject.org',
      'https://mySite.blah.amp.cloudflare.com'
    ]

    def cors_verification
      if request.headers['origin'].in?(ALLOWED_ORIGINS)
        origin = request.headers['origin']
      elsif request.headers['origin'].nil? && request.headers['AMP-same-origin']&.casecmp?('true')
        origin = request.base_url
      else
        render(json: { message: 'Unauthorized Request' }, status: :forbidden) && return
      end

      response.set_header('Access-Control-Allow-Credentials', 'true')
      response.set_header('Access-Control-Allow-Origin', origin)
    end
  end
end
```

#### Authorization Endpoint
接著我們做 authorization endpoint 的部分！這裡直接使用了 devise 的 `#{mapping}_signed_in?`、`current_#{mapping}` 等方法

```ruby
module Api
  class AmpAccessController < Api::BaseController
    def authorization
      render json: { signedIn: user_signed_in?, username: current_user&.name }, status: :ok
    end
  end
end
```

#### 設定 routes
當然不能忘了加 routes。

```ruby
namespace :api, defaults: { format: 'json' } do
  get :authorization, to: 'amp_access#authorization'
end
```

#### AMP Access configuration
記得要在你的頁面上加上 amp-access 的 required script：

```html
<script async custom-element="amp-access" src="https://cdn.ampproject.org/v0/amp-access-0.1.js"></script>
```

接著我們來加上 amp-access 的 configuration 吧。文件上要求 authorization endpoint 和 pingback endpoint 要帶 `READER_ID`。而 `RANDOM` 會回傳隨機亂碼，可以避免被瀏覽器 cache。

```erb
<script id='amp-access' type='application/json'>
{
    "authorization": "<%= api_authorization_url(rid: 'READER_ID', '_=': 'RANDOM') %>",
    "pingback": "",
    "noPingback": true,
    "authorizationFallbackResponse": {
        "signedIn": false
    }
}
</script>
```

#### Access Content Markup
相信剛剛看了 Access Content Markup 的介紹，現在應該已經很了解他的基本語法了。

如果原本你的 view 裡面有長得像這樣的東西：

```erb
<% if user_signed_in? %>
    <section> ... </section>
<% else %>
    <section> ... </section>
<%end%>
```

把它改成用 `amp-access` 和 `amp-access-hide`，管理它要不要在畫面上顯示：

```html
<section amp-access="signedIn" amp-access-hide>
  ...
<section>
<section amp-access="NOT signedIn">
  ...
<section>
```

那如果是要在畫面上顯示 username 呢？這個時候就會需要用到 [amp-mushtache](https://amp.dev/documentation/components/amp-mustache/)。

使用之前要記得加上 required script：

```html
<script async custom-template="amp-mustache" src="https://cdn.ampproject.org/v0/amp-mustache-0.2.js"></script>
```

使用 template 來顯示名稱：

```html
<section amp-access="signedIn">
    <template amp-access-template type="amp-mustache">
        親愛的 {{username}} 您好
    </template>
</section>
```

基本上到這裡就大功告成了！是不是能夠正常顯示登入了呢？

別忘了去試試看你的網站的 cache 版本是不是也運作正常哦 ( ～'ω')～


post-透過 amp-access 讓你在 Cache 頁面也能順利保持登入！

透過 amp-access 讓你在 Cache 頁面也能順利保持登入！


## 所謂「半路出家」的工程師
也許以下的故事對你／妳而言似曾相識：
> 之前沒有程式或相關背景的你／妳，透過自學或參加線上／實體課程，找到了第一份工程師的工作。
> 
> 到了就職報到的第一天才發現，主管跟同事所說的話怎麼都聽不懂；好像當初所學的，其實對於工作情境而言根本就不夠用。過了幾天，把主管交代的任務完成、開始在專案發 PR 。這些 PR 中，有許多部分都被主管評為需要修改。更不幸的是，好像怎麼修改都無法達到標準。每次都得硬著頭皮、一條一條地向主管或同事請教。下班後足不出戶全心全力的付出，為的就是要把不會的東西趕快補齊，才有辦法給公司和自己一個交代。
> 
> ⋯⋯時間快轉到三個月半年後，這樣子的循環在現在雖已有好轉，但心中的挫敗感不減反增。對於工作，還是覺得自己似乎什麼都不懂；「當初公司一定是有誰搞錯了，才會錄取根本不適合這份工作的自己」，你／妳這樣想著。與一些許久不見的朋友碰面、提到了換了工作成為了工程師時，總是覺得有些心虛。「我，真的已經是工程師了嗎？」，你／妳，在心中反問著自己。

今天想要與各位分享的是在面對工作時，心中所產生的「我好像還不夠格」、「我不屬於這邊」、⋯⋯等想法，有時並非自己努力不夠，而是冒名頂替者症候群在作祟。

## 什麼是冒名頂替者症候群（ Imposter Syndrome ）
冒名頂替者症候群，以工作情境論，是指當面對所交辦的任務時，當事人所感到的焦慮感、自我懷疑以及擔心，造成了其對任務過度準備或故意拖延任務（或兩者皆具）。

當任務順利地完成，當事人也會將其成功歸因於自己有下了許多努力（透過對任務的過度準備）或單純地運氣好（因拖延任務、自覺自己沒有下功夫在做）；因完成任務而收到上司或同事的正面回饋，當事人也通常會將這些讚美給「打折扣」，覺得自己並沒有真的這麼好。⋯⋯久而久之，上述狀況演變成覺得自己只是個「還沒有被人發現的騙子」、自我懷疑、憂鬱和焦慮。簡言之，冒名頂替者症候群讓實際上已經成功的當事人，仍覺得自己似乎不應該是團體中的一份子、是位「冒名頂替上來的騙子」。

## 冒名頂替者症候群如何影響你我
![post-總覺得自己在工作上不夠稱職？論冒名頂替者症候群所帶來的影響](//images.ctfassets.net/8er52l3j5u76/3hDXQG7iVxufu6fEBrsQ2y/986d385ad5530496d022cd00b76da6dd/fig-imposter-cycle.jpg)
([Clance’s (1985) model of the Imposter Cycle, as depicted in Sakulku & Alexander (2011)](https://www.apa.org/science/about/psa/2018/09/imposter-syndrome))

可能受到冒名頂替者症候群影響的人有以下[特質](https://mari.umich.edu/news/impostor-syndrome)：

1. 自認不夠努力而總是過度工作
2. 為了避免失誤而拒絕接受工作上新的挑戰
3. 因害怕做出來的成品／成果不夠好而拖延交辦事項
4. 過度加班而疏於照顧自己，甚至犧牲了工作與生活之間的平衡
5. 在工作上遇到狀況時，為了不要讓他人發現其實自己（覺得自己）不夠格而刻意避免向他人請教或求助
6. 總是以犯過的錯，而非成就，來定位自己

若以在工作上表現良好而得到讚美及鼓勵舉例：

- 自覺是因為有準備

	能夠順利完成交辦事項，是自己花了大量時間與心力後的結果。下次要花的努力只能多不能少，才能夠維持著這樣子的表現而不會被識破。

- 自覺毫無準備

	覺得會有如此表現一切都是因為運氣好；自己多學會的技能剛好是工作所需要的、自己才派得上用場。仍然覺得自己德不配位，是個假冒的騙子。

## 在工作上可以如何克服、或至少與冒名頂替者症候群共存
- 用不同的角度看待事物

	工程師經常得面對未知的挑戰，而且結果有時候也往往不盡人意。如果對於要完成的任務感到焦慮，將其當作是個學習的機會；絕大多數情況下，它不會是造成你／妳職涯去留的轉淚點。

- 知道不是只有你會這樣想 

	如果感覺到自己對交辦事務感到手足無措、甚至是在逃避面對時，可以試著找也正經歷類似狀況的夥伴聊聊。當發現不是只有自己覺得事務困難時，可以幫助你對現在的處境做更正確的[歸因](https://en.wikipedia.org/wiki/Attribution_(psychology))。

	假使身邊真的沒有人可以討論，也可以試著讀讀[其他人的故事](https://medium.com/landingfestival/58-of-tech-employees-experience-imposter-syndrome-heres-how-to-overcome-it-78172d8a2258)。

- 允許自己邀功

	當完成了一件困難的任務時，允許自己將功勞歸在自己的身上。若不相信自己也有功勞，可以把為完成任務所做的努力，列成一張表來證明。對於收到他人的讚美不必推託、一句「謝謝」即可。別人不是為了讓你自我感覺良好而才給予讚美的；他們是真心這麼想的。

- 教學相長

	透過指導他人，除了能夠給予需要幫忙的人協助以外，也是對自己工作能力最直接的[賦能（ Empowerment ）](https://zh.wikipedia.org/wiki/%E8%B3%A6%E6%AC%8A)、覺察到自己已有能力可以助人。

## 我如何與冒名頂替者症候群相處（心得分享）
- 理性認知自己現在的狀態，不需要有過大壓力

	拿普遍會被當作比較標的、所謂的「本科系畢業」的工程師來說，即使大學／研究所時並非專精該領域，也在電腦科學的領域耳濡目染了數年。若在學習新技術或概念上，自己比起本科系畢業的朋友「開竅」較慢，需要認知到其僅是因為欠缺此領域所用到的知識與認知架構而已。比起為此而懊惱焦慮，將注意力轉到規劃及調整學習的方式上會來得較實際些。

- 參加聚會

	在聚會中遇到的人，每個人都有值得借鏡，或讓自己「自我感覺更加良好」地方。程式圈和其他領域相比友善許多，大部分的前輩都非常樂意分享所見所得；面對涉世未深、還在理解這個領域是怎麼運作的新朋友，也能透過心得分享與技術交流，體會到自己其實已經有能力理解、甚至是解決別人的問題。以上的聚會互動，除了是人脈積累的一種方式外，也可以是個獲得[社會支持](https://en.wikipedia.org/wiki/Social_support#Links_to_mental_and_physical_health)的地方。

- 休息，是為了走更長遠的路

	如果低落、挫敗的感覺過於強烈，而手邊的事務並沒有急到得要必須得加班完成，允許自己休息一晚。也許是約上好友碰面聊聊近況；也許是找間從未吃過的餐館用餐，重新在戶外體驗許久未仔細端詳的公園巷口；或者是關在房間裡，讓電影與宵夜做今晚的朋友；⋯⋯。不論如何，請把手上的接力棒先傳給明天的自己，並溫柔地告訴自己：今晚的休息，是為了能夠更有精神地面對明天的挑戰。

## 「路，不是比誰走得快，而是比誰走得遠」
這是當還在別的領域時，被一陣陣襲來的挫敗感而無所適從的我，有幸聽到前輩所分享的一句話。希望這篇文章能夠鼓勵到也許還在螢幕前苦惱自己是不是真的適合程式工作的你／妳。

業貴持之以恆。重點不應該放在計較起步的快慢，而是在求進步的同時也照顧好自己身心的需求，才能夠走得更遠、更長。

### 參考資料 
- [Feel like a fraud?](https://www.apa.org/gradpsych/2013/11/fraud) by Kirsten Weir on Amarican Psychology Association

- [Are you suffering from imposter syndrome?](https://www.apa.org/science/about/psa/2018/09/imposter-syndrome) by Lydia Craig on Amarican Psychology Association

### 延伸閱讀
- [Yes, Impostor Syndrome Is Real. Here's How to Deal With It](https://time.com/5312483/how-to-deal-with-impostor-syndrome/) by Abigail Abrams on TIME

- [58% of tech employees experience imposter syndrome. Here’s how to overcome it.](https://medium.com/landingfestival/58-of-tech-employees-experience-imposter-syndrome-heres-how-to-overcome-it-78172d8a2258) by CareerFoundry

- [你有 Impostor syndrome (冒名頂替症候群) 嗎？](https://brianhsublog.blogspot.com/2018/10/impostor-syndrome.html) by Brian Hsu

- [為什麼我無法坦率地擁抱成功？ — 冒牌者症候群](https://medium.com/as-a-product-designer/%E7%82%BA%E4%BB%80%E9%BA%BC%E6%88%91%E7%84%A1%E6%B3%95%E5%9D%A6%E7%8E%87%E5%9C%B0%E6%93%81%E6%8A%B1%E6%88%90%E5%8A%9F-%E5%86%92%E7%89%8C%E8%80%85%E7%97%87%E5%80%99%E7%BE%A4-2c8520a2c710) by Jasmine Lin


post-總覺得自己在工作上不夠稱職？論冒名頂替者症候群所帶來的影響

總覺得自己在工作上不夠稱職？論冒名頂替者症候群所帶來的影響

post-CI/CD 從零開始 - 使用 CircleCI 部署 Node.JS App 到 GCP App Engine

CI/CD 從零開始 - 使用 CircleCI 部署 Node.JS App 到 GCP App Engine

## 前言

「工欲善其事，必先利其器」，通常看到這個開頭，就知道今天要來介紹工具。在寫程式時，大家通常習慣的 Editor 是哪些呢? Vim、Emacs、Atom、Sublime、VSCode、<del>記事本</del>。而上述的 Editor 中，最廣為人知的就是被譽為「編輯器之神」的 Vim 和被譽為「神之編輯器」的 Emacs。由於這兩款 Editor 不同的特色與本質，形成了各自的派系並且相互歧視，因此還引發了 Editor 界的一場聖戰「[Editor War](https://en.wikipedia.org/wiki/Editor_war)」。

回到正題，這次主題的 VSCode 相較與前面兩款成神的 Editor 來講只能算是新生兒而已。但對筆者來說，選擇使用起來順手、舒服的 Editor 較為重要，接下來讓筆者稍微介紹一下這次的主角 VSCode：

- 基於 Electron 開發 <sub><small>註1</small></sub>
- 原始碼在 GitHub 上開源，並採用 MIT 授權條款
- Windows、Linux 和 macOS 等作業系統皆有支援

<small>註1：[Electron](https://electronjs.org/) 是 GitHub 開發的一個開源框架。開頭提到的 Atom 也是基於這個框架開發的。</small>

## 安裝

這邊可以直接到 VSCode 的官方網站來直接[下載](https://code.visualstudio.com/#alt-downloads)，或是透過以下方式安裝：

### MacOS
```shell
$ brew cask install visual-studio-code
```

### Linux
#### Ubuntu / Debian
1. 先到 [VSCode](https://code.visualstudio.com/#alt-downloads) 的網站
2. 下載 `.deb`，並透過 apt 安裝

```shell
$ sudo apt install ./<file>.deb
```

#### RHEL / Fedora / CentOS
- dnf

```shell
$ sudo dnf check-update
$ sudo dnf install code
```
- yum

```shell
$ yum check-update
$ sudo yum install code
```

若使用的工具不在上述或是安裝遇到問題，可以參考官方這份[文件](https://code.visualstudio.com/docs/setup/linux)

## 執行
安裝後，可以直接使用 Command Line 開啟：

```shell
$ code <path>
```

像筆者使用 MacOS，直接官網下載的檔案安裝後，在 Terminal 發現 `code` 不存在的話，請跟著以下步驟：

1. 按下 F1 或是 `cmd + shift + P`
2. 輸入 `Shell Command: Install 'code' command in PATH` 並按下 Enter

完成以上兩個步驟後，重開 Terminal 就可以使用 `code` 來開啟資料夾或檔案了

接著開啟 VSCode 後應該就會看到下面這個畫面：
![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/2AilxHBQcBuem5XGosq5PY/18f22e87da45e0bab501d86b713518e2/eBvhJSk.png)

接著就來看看 VSCode 一些功能：

### 內建 Terminal

- 快捷鍵： `cmd + ｀`

按下快捷鍵後，下方就可以看到 Terminal 的畫面，如下圖所示：

![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/3sqqye24IjeXST1YFpqGTU/419b113bfb5572170eceba630a30195e/gz8sUhu.png)

而 VSCode 預設的 Terminal 字型跟 `Editor: Font Family` 一樣，也就是 `Menlo, Monaco, 'Courier New', monospace`。如果想要更換字體，可以在設定中加入 `"terminal.integrated.fontFamily": "<字型>"`

### 設定

- 快捷鍵： `cmd + ,`

![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/4E9YubFVR6FIIaElLisFpH/8968ee696aa7eea8e64a1e1989916628/wFr1MOM.png)

按下快捷鍵後，就會看到像上方圖片一樣的設定檔畫面，而更改設定的方式有兩種

1. 如上圖，可以直接點選更改設定值
2. 點選圖片中，紅色框框的按鈕，會開啟一個 `settings.json` 的檔案，在上方的 `內建 Terminal` 部分所提到的 `"terminal.integrated.fontFamily": "<字型>"` ，也是直接加到這檔案內即可生效

而眼尖的讀者應該也發現在設定的畫面中，有區分使用者與工作區兩種，接下來就談談這兩種的區別吧！

#### 使用者
這邊的使用者，是指當前登入該台電腦的使用者，所以只要是同一個使用者，無論開啟任何資料夾或檔案，都可以使用到一樣的設定，而各個作業系統的 `settings.json` 檔案路徑如下：

- Windows： `%APPDATA%\Code\User\settings.json`
- MacOS： `$HOME/Library/Application Support/Code/User/settings.json`
- Linux： `$HOME/.config/Code/User/settings.json`

#### 工作區
而這邊的工作區，是指當前開啟的資料夾，更改這邊的設定後會在資料夾的目錄下產生一個 `.vscode` 的資料夾，裡面存著 `settings.json` 的檔案。如果是專案上想要要有些共通的設定的話，就可以更改這邊的設定達到一致性

在這邊要注意的是，工作區的設定優於使用者設定，所以當使用 VSCode 的時候，發現跟原本設定怎麼有些出入時，就先檢查一下工作區的設定吧。

### 快捷鍵
介紹工具怎麼不介紹快捷鍵呢，好好使用快捷鍵可以達到事半功倍呢，接下來讓筆者一一介紹一些筆者常用的快捷鍵：

#### 開啟快捷鍵設定的畫面
- 快捷鍵： `cmd + K` + `cmd + S`
- 更改快捷鍵的方式：
  1. 點選要更改快捷鍵的項目
  2. 點選項目前方的筆，或是按下快捷鍵 `cmd + K` + `cmd + K`
- 設定檔路徑：
  - Windows： `%APPDATA%\Code\User\keybindings.json`
  - MacOS： `$HOME/Library/Application Support/Code/User/keybindings.json`
  - Linux： `$HOME/.config/Code/User/keybindings.json`

#### 將整行向上(下)複製
- 快捷鍵：
  - 向上複製： `alt(option) + shift + up`
  - 向下複製： `alt(option) + shift + down`

有時候遇到一樣的東西要寫很多行，還在使用 複製 + Enter + 貼上嗎？不如來試試看這個快捷鍵，這邊筆者有更改過快捷鍵，只要按下 `cmd + up` 或是 `cmd + down` 就可以快速地向上或向下複製一樣的東西了，如果要複製多行的話，把要複製的那幾行選取起來，再按下快捷鍵即可

#### 更改當前檔案的 language mode
- 快捷鍵： `cmd + K` + `M`

#### 開啟 Markdown 的預覽畫面
- 快捷鍵： `cmd + K` + `V`

#### 快速選取「下一個」與選取項目相同的項目
- 快速鍵： `cmd + D`
- 使用方式： 選取文字後按下快捷鍵
- 示意圖：
  - 點選前： 

![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/5nH9tmBoRPWXzSwyREj2sn/fd59b7197e2fe4fcefe99313f33f7d80/yMXtpc0.png) 

  - 點選後：

![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/1NYaEKcLVCFR0Pl84Cn55E/30ca82d6a8dd78e5b0c6c5e11fa1f7bd/0KiFHRS.png)

#### 快速選取「所有」與選取項目相同的項目
- 快速鍵： `cmd + L`
- 使用方式： 選取文字後按下快捷鍵

#### 快速開啟目標檔案
- 快速鍵： `cmd + P`
- 使用方式： 按下快捷鍵後，輸入要開啟的 `檔案名稱` 或是 `路經 + 檔案名稱` 後，按下 Enter 即可開啟

#### 到達指定行數
- 快速鍵： `control + G`
- 使用方式： 按下快捷鍵後，輸入要到達的行數並按下 Enter，即可到達該行數

#### 註解
- 快速鍵： `cmd + /`

以上就是筆者日常常用的快捷鍵，如果有其他需求，不如先找找快捷鍵的設定裡面，有沒有各位需要的快捷鍵功能喔

### 套件 Extension
在 VSCode 裡面按下 `cmd + shift + Ｘ` 或是前往 [VSCode Marketplace](https://marketplace.visualstudio.com/vscode) 都可以來尋找並安裝所需要的套件。如果是初次使用 VSCode 或是不知道該裝什麼套件的話，可以在 Extension 搜尋的地方輸入 [Show Recommended Extension](https://code.visualstudio.com/docs/editor/extension-gallery#_workspace-recommended-extensions)，就會列出 VSCode 建議安裝的套件，不過這邊還是要依照每個人使用需求去安裝。

如果是其他 Editor 使用習慣的使用者， VSCode 也有對應的快捷鍵可以安裝，只要按下 `cmd + K` + `cmd + M` ，就會列出其他 Editor 快捷鍵的套件以供安裝，以下推薦幾個筆者使用的套件：

- [Ruby](https://marketplace.visualstudio.com/items?itemName=rebornix.Ruby)
- [Live Server](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer)
- [Live Sass Compiler](https://marketplace.visualstudio.com/items?itemName=ritwickdey.live-sass)
- [Material Icon Theme](https://marketplace.visualstudio.com/items?itemName=PKief.material-icon-theme)

## 結語
我們 VSCode 的啟航就到這了，大家或多或少對 VSCode 有進一步的認識 <del>吧（？</del>

透過這次的介紹，希望可以讓各位將 VSCode 打造成更順手的 Editor，而下一次將帶領大家探索 Extension 新大陸，並試著寫出屬於自己的套件。(ง๑ •̀_•́)ง


post-VSCode 的奇幻旅程

VSCode 的奇幻旅程


## 前言

大家自助旅行時喜歡搭車還是自駕呢？有經驗的旅人會說「看情況」。熱門景點大多交通便利，雖然行程多少會受到路線和班次限制，但整體來說一般還是會因為各種方便，選擇搭乘大眾交通工具吧。那如果是要去比較特別的景點的話呢？或者是雖然是要去四通八達的地方，但帶了一家老小呢？ **你確定你真的要帶著父母（或小孩）和大包小包的行李，在沒有電梯的月台狂奔去趕兩小時才一班的車嗎？** 這種情況下，正常人都會勸你們跟團或自駕的。

專案開發其實也是類似的狀況。敝公司的讀者想必對 Ruby on Rails 都很熟悉；Rails 自 2005 年發展至今，除了框架自身已相當成熟之外，周邊更有完整的生態系和社群支撐。也因為如此，即便 [Ruby 每年都被宣告死亡](https://isrubydead.com/)，在競爭激烈、兵貴神速的市場上，Rails 仍然是業界「快速開發」的首選。

> 「速度是非常強力的武器，充滿魅力又帥氣，但即便如此也不是無敵」排球少年第 290 話

然而，就是這個然而，Rails 雖然「各種方便」但絕非萬能。Rails 的哲學是以遵循慣例來換取開發速度，更重要的是市面上大部分的業務需求也確實都能在這個框架下得到很好的成效。但換個角度來說，當你的業務需求就是和所謂的 The Rails Way 無法順利配合，或者你真的就是不喜歡 Rails 包山包海的設計思維的話，Ruby 工程師有其他的選項嗎？

答案是有的！Ruby 社群其實一直都有類似的討論和專案，像是今年 Rubyconf Taiwan 就有勇者挑戰了筆者個人也滿喜歡的 Trailblazer（[開拓者們建立鐵道的辛酸血淚史 by WenchuanLin](https://www.youtube.com/watch?v=fyuSUKfwwVM)），我們最近也有在客戶的 Rails 專案中引進 operators 的概念來整理商業邏輯。不過，今天要介紹的不是 [Trailblazer](http://trailblazer.to/)，而是常和它一起被提到的輕量 MVC 框架，[Hanami](http://hanamirb.org/)。

> Hanami 原本的專案名稱是 Lotus，但後來為了避免和 IBM 的 Lotus 商標混淆就改名了<del>有用過 Lotus Notes 的老人請舉個手</del>。Hanami 就是日文的「賞花」，除了和原本的蓮花相關，也帶了向源自日本的 Ruby 致敬的意義。

世界上沒有完美的技術解決方案，大多數時間我們都是在不同的問題中做取捨（trade-off）。就像自駕雖然給了旅人自由的移動手段，但取而代之的是你必須自己看地圖找路、注意行車安全，還需要掌握加油站、休息站、停車場資訊等，絕對不會比較輕鬆。

如果說 Rails 的特色是鋪好了一套包山包海的軌道，只要照著 The Rails Way 往前進就能到達目的地，那麼 Hanami 的賣點則正好相反：「The web, with simplicity. 」千萬別誤會，這裡說的 simplicity 指的是回歸「單純」，不是說開發上比較簡單（笑）大略整理一下 Hanami 的特色：

- 背後哲學是 Domain-Driven Design
- 尊崇 PORO（plain old ruby object），不對 Ruby core class/stdlib 做 monkey patch <del>AcitveSupport 表示</del>
- 主張顯式優於隱含（explicit over implicit）
- 遵循單一功能原則（single responsibility principle）
- 不做 DB 層的 callback

雖然好像一直在重覆這點，不過 Hanami 和 Rails 真的是完全不同的哲學（笑）Hanami 重視的是專案長期的維護性，這一派的開發者大多認為長期來看黑魔法反而有害（例如框架在背後偷偷做了太多東西，最後卡來卡去互相傷害，像是最近這則 [Rails issue#36844](https://github.com/rails/rails/issues/36844)），因此在設計上採用了完全不同的作法。當然，也因為這樣，相較大家習慣的 Rails，Hanami 自然也是少了很多「開發上的便利性」，更無法否認的是它周圍的生態圈也並不完整<del>不過這邊的心態大多是「這不需要用 gem 啊為什麼不自己刻就好」XD</del>。

由於本文撰寫時 Hanami 的穩定版本為 1.3.3，但「據說」近期會釋出[變動頗大的 2.0](https://github.com/hanami/hanami/pull/975)，為了避免短時間內就被改版的杯具，下面只會以官網提供的範例大致介紹一下現況。如果讀者有興趣的話，建議可以自己走一次[官方教學文件](https://guides.hanamirb.org/introduction/getting-started/)體驗看看。雖然大家回到工作上應該還是繼續以寫 Rails 為主，但如果 Hanami 的思維能為各位帶來一些不同的刺激，那筆者寫這篇文章也算是有點意義了。

## 建立專案

```text
$ gem install hanami
$ hanami new bookshelf
$ bundle install
$ hanami server
```

咦？怎麼好像有點眼熟？不過來看看 Hanami 幫我們建了哪些東西：

```text
$ cd bookshelf
$ tree -L 1
.
├── Gemfile
├── README.md
├── Rakefile
├── apps
├── config
├── config.ru
├── db
├── lib
├── public
└── spec
```

乍看之下依然是 87 分相似，但其實已經出現重大分岐了。Hanami 的架構是將產品的核心（application core）和其對外介面（delivery mechanism）徹底分開；前者安排在 `lib` 目錄下：

```text
$ tree lib
lib
├── bookshelf
│   ├── entities
│   ├── mailers
│   │   └── templates
│   └── repositories
└── bookshelf.rb
```

後者則以應用程式為單位，各自座落在 `apps` 目錄內，每個應用程式另有各自的 controller、view 等。預設的應用程式目錄為 web。

```text
$ tree apps/web
apps/web
├── application.rb
├── assets
│   ├── favicon.ico
│   ├── images
│   ├── javascripts
│   └── stylesheets
├── config
│   └── routes.rb
├── controllers
├── templates
│   └── application.html.erb
└── views
    └── application_layout.rb
```

## Application Core
對照 Rails 就是 MVC 的 model 部分，自動產生的指令也非常眼熟：

```text
$ hanami generate model book
      create  lib/bookshelf/entities/book.rb
      create  lib/bookshelf/repositories/book_repository.rb
      create  db/migrations/20170406230335_create_books.rb
      create  spec/bookshelf/entities/book_spec.rb
      create  spec/bookshelf/repositories/book_repository_spec.rb
```

### Model => Entity & Repository

不過在 Hanami 裡並沒有 `model` 這個目錄，而是依 DDD 的概念，分成 `entity` 和 `repository` 兩部分。簡單來說，`entity` 是商業邏輯的核心，是用來表現持久層（persistance layer）資料的 immutable 物件。實際上和持久層互動的則是 `repository`（和 git 那個無關）。假設我們已經建好 migration，實際操作起來大概是這種感覺：

```text
$ hanami console
irb> repository = BookRepository.new
irb> book = repository.create(title: 'Hanami')
irb> book.title # => 'Hanami' 
```

`Hanami::Repository` 提供了 `create`, `update`, `delete`, `all`, `find`, `first`, `last`, `clear` 的介面。要注意的是，這些全都是 private 方法！這是因為在 Hanami 的思維裡，開發者不應該直接把整串的 query 曝露在外面，像是：

```ruby
BookRepository.new.where(author_id: 23).order(:published_at).limit(8)
```

而是應該要寫出意圖明確的 API：

```ruby
# lib/bookshelf/repositories/book_repository.rb
class BookRepository < Hanami::Repository
  def most_recent_by_author(author, limit: 8)
    books
      .where(author_id: author.id)
      .order(:published_at)
      .limit(limit)
  end
end
```

除了程式意圖明確之外，這樣做的好處還有方便做孤立測試，也可以避免程式和底層資料庫的耦合。這部分的實做是以 [ROM](https://rom-rb.org/) 和 [Sequel](https://github.com/jeremyevans/sequel) 為基礎，有興趣的話可以再自行研究。

另外比較特別的是，由於 Hanami 的 validation 和 Rails 的作法有根本上的不同，`entity` 層是完全不處理 validation 的（後述）。

## Delivery Mechanism

在 Hanami 的架構中，業務邏輯是共用的（集中在上述的 `lib` 裡），但業務邏輯的應用可以有很多種，例如網站（`apps/web`）、管理介面（`apps/admin`）、對外 API（`apps/api`）等。每個對外介面有自己的目錄，裡面有各自的 controller 和 view 等內容。如果用 Rails 的說法，等於是從設計上就鼓勵你把東西拆成 engine 來做。

### Controller => Action

指令開始和 Rails 不太一樣了！由於同一個專案內可以有多個應用程式，因此需要在 generator 中指定。另外要注意的是，參數是 `action` 不是 `controller`（但檔案是建在 `controllers` 目錄裡）：

```text
$ hanami generate action web dashboard#index
      create  apps/web/controllers/dashboard/index.rb
      create  apps/web/views/dashboard/index.rb
      create  apps/web/templates/dashboard/index.html.erb
      create  spec/web/controllers/dashboard/index_spec.rb
      create  spec/web/views/dashboard/index_spec.rb
      insert  apps/web/config/routes.rb
```

相對於 Rails 是習慣把 RESTful 的七大神器都寫在同一個 controller 上，Hanami 的作法是把每個動作（`action`）拆成單獨的檔案，大概是長這樣：

```ruby
# apps/web/controllers/dashboard/index.rb
module Web
  module Controllers
    module Dashboard
      class Index
        include Web::Action
        expose :greeting

        def call(params)
          @greeting = "Hello"
        end
      end
    end
  end
end
```

這裡的 convention 是每個 action 都要實做 `call(params)` 的方法，再用 `expose` 將值開放給 view/template 使用。而 Hanami 將每個 action 拆開來，最大的好處就是方便測試，像是可以輕鬆模擬 request 的 header 和 params：

```ruby
# spec/web/controllers/users/show_spec.rb
require_relative '../../../../apps/web/controllers/users/show'

RSpec.describe Web::Controllers::Users::Show do
  let(:action)  { Web::Controllers::Users::Show.new }
  let(:format)  { 'application/json' }
  let(:user_id) { '23' }

  it "is successful" do
    response = action.call(id: user_id, 'HTTP_ACCEPT' => format)

    expect(response[0]).to eq(200)
    expect(response[1]['Content-Type']).to eq("#{ format }; charset=utf-8")
    expect(response[2]).to eq(["ID: #{ user_id }"])
  end
end
```

### View => View & Template

相形下之 view 還滿單純的；有仔細看 generator 的產出的話，會發現 Hanami 也同時幫我們產生好了 `views` 和 `templates` 的檔案。其中 `view` 是負責把 `template` render 出來的物件，前者大致可以用 decorator 來想像，後者就是等同 Rails 的 view（Hanami 支援包括 erb、slim、haml 在內的各種常見 template engine）。請注意範例中使用了在 controller 中被 `expose` 開放的值：

```ruby
# apps/web/views/dashboard/index.rb
module Web
  module View
    module Dashboard
      class Index
        include Web::View

        def welcome_message
          greeting + " and welcome"
        end
      end
    end
  end
end

# app/web/templates/dashboard/index.html.haml
%h1 Dashboard
%p= welcome_message
```

### 表單

Hanami 本身提供了內建的 form builder，支援所有 HTML5 的表單元件。其最大特色在於「form builder 語法不因 template engine 不同而改變」：

```ruby
# erb
<%=
  form_for :book, routes.books_path do
    div do
      label 'Title'
      text_field :title
    end

    submit 'Create'
  end
%>
```

```html
# 產出以下 html
<form action="/books" id="book-form" method="POST">
  <div>
    <label>Title</label>
    <input type="text" name="book[title]" id="book-id" value="">
  </div>
  <button type="submit">Create</button>
</form>
```

理想上是要能做到像 erb 那樣，一整段可以直接覆製貼上的 block，不過目前 [haml/slim 的支援](https://github.com/hanami/view/issues/122)還有點美中不足，需要自己補上前綴記號：

```ruby
# haml/slim
= form_for: book, routes.books_path do
  - div do
    - label 'Title'
    - text_field :title

  - submit 'Create'
```

雖然也是可以在 haml/slim 裡寫 inline ruby 再去輸出，不過那樣的話還不如直接寫在`view` 裡算了：

```ruby
# apps/web/views/books/new.rb
module Web
  module Views
    module Books
      class New
        include Web::View

        def form
          form_for :book, routes.books_path do
            text_field :title

            submit 'Create'
          end
        end
      end
    end
  end
end

# app/web/templates/books/new.html.haml
= form
```

不過筆者個人的哲學是 `view` 不該處理 HTML（反之，`template` 不該處理邏輯），不管上面哪種寫法心裡都有點抗拒，所以還是希望這點在 Hanami 2.0 裡能有所改善。

### 資料驗證

前面提到 Hanami 和 Rails 在資料驗證上有根本的不同。請回想一下：Rails 的作法是先把物件生出來，再對物件去做驗證。這固然有它方便的地方，但隱藏的風險是我們會產生出很多「[有問題的物件](https://solnic.codes/2015/12/28/invalid-object-is-an-anti-pattern/)」。Hanami 的作法則是先針對 params 做驗證，驗證成功才會產生物件，等於是從源頭迴避掉上述的問題。

除此之外更不一樣的是，在 Hanami 的思維中，「對 params 的驗證」和「寫入持久層時的驗證」這兩件事也是分開的！這也是為什麼 `entity` 本身不會去做資料驗證（因為先驗證成功了才會有 `entity`），`Hanami::Validations` 也[故意沒有提供常見的 uniqueness 驗證](https://github.com/hanami/validations#uniqueness-validation)，而是鼓勵開發者自己去處理 database constraint error。

> 話是這麼說，但具體該怎麼實做[似乎還沒有結論](https://discourse.hanamirb.org/t/what-is-a-proper-way-to-handle-a-uniqueness-constraint/351/4)，然後  Hanami 作者本人是[建議寫在 interactor 上](https://gitter.im/hanami/chat/archives/2017/03/14)。Interator 的實做請參考[官方文件](https://guides.hanamirb.org/architecture/interactors/)。

那麼簡單看一下驗證的範例：

```ruby
# apps/web/controllers/signup/create.rb
module Web
  module Controllers
    module Signup
      class Create
        include Web::Action

        params do
          required(:name).filled(:str?)
          required(:email).filled(:str?, format?: /@/).confirmation
          required(:password).filled(:str?).confirmation
        end

        def call(params)
          if params.valid?
            # ...
          else
            # ...
          end
        end
      end
    end
  end
end
```

不過要講 Hanami 的 validation，就必須來看它底層的 [dry-validation](https://dry-rb.org/gems/dry-validation/1.0/)。dry-rb 也是筆者一直在關心的專案，其中最喜歡的正好就是 dry-validation 所以剛好順便推坑！dry-rb 的 gem 都可以單獨運作，手上如果有 Rails 的 side project 的話可以拿去玩看看，相信會<del>再也不想碰 ActiveRecord validation</del> 感到身心舒暢，大致看幾個範例就好：

```ruby
＃ params 一定要有 :name，需要有值，值需為字串，且長度在 3~10 之間
required(:name).filled(:str?, :size?(3..10))

# 也可以寫成 block
required(:name) { filled? & str? & size?(3..10) }

# params 不一定要包括 :name，如果有送的話也不一定要有值，但若有值的話，需要是字串
optional(:name).maybe(:str?)

# params 一定要有 :age，需要有值，值需為整數，且需要大於 18
required(:age).filled(:int?, :gt?(18))
```

當然也可以自建規則（predicates）：

```ruby
require 'hanami/validations'

class Signup
  include Hanami::Validations

  predicate :url?, message: 'must be an URL' do |current|
    # ...
  end

  validations do
    required(:website) { url? }
  end
end
```

總之是個寫起來很開心的工具，介面很乾淨，誠心推薦大家試用 XD

## 周邊生態系

這塊是 Rails 的無敵強項，天下武功唯快不破，而 Rails 的神速正是建立在這個豐厚的生態系之上。年輕的 Hanami 顯然還在努力中，有興趣的讀者可以自行參考[官方團隊推薦的套件](http://awesome-hanami.org/)，基本的東西像是前端套件、資料分頁、檔案上傳、身份驗證等也都是有的。當然如果你有心投入開源技術開發的話，這裡還是一片藍海等你來貢獻唷～

## 小結

如果你只是在寫單純的 CRUD 網站的話，Hanami 不一定會是最適合的工具。但請想像一下：今天有個功能，資料流有至少三個入口，需要一次處理超過四層以上的巢狀資料，隨便就會影響到五、六張資料表，有錯綜複雜的資料驗證規則和<del>上線前才知道的</del>各種特例，最後還要視情境同步到不同資料表或打外部 API 並持續追蹤狀態…不要說不可能，以上是血淚實例（顯示為對著 ActiveRecord 痛哭）

商業需求總是瞬息萬變，認真的專案做到最後一定會超出一般的 CRUD 的範籌。這種時候，從設計上就鼓勵甚至是強迫開發者要「把東西拆小，使之不互相影響，方便測試和串連」的 Hanami 架構，對「專案的長期可維護性」是很有價值的。

最後也誠心推薦大家可以看一下 [Hanami 作者 @jodosha 今年的演講](https://vimeo.com/339279205)，裡面提到的 FP/OOP callable object 概念非常值得深思，也是貫穿 Hanami 運作方式的核心。基於這個想法而串連在一起的 Hanami、ROM、dry-rb 等專案今後會對 Ruby 帶來哪些改變，也非常令人期待！

### 參考資料
- [Hanami Guides](https://guides.hanamirb.org/)：官方教學文件
- [Awesome Hanami](http://awesome-hanami.org/)：周邊生態系
- [Hanami Cookbook](https://hanami-cookbook.stdout.in/pages/getting-started.html)
- [Rubyist Magazine: HanamiはRubyの救世主(メシア)となるか、愚かな星と散るのか](https://magazine.rubyist.net/articles/0056/0056-hanami.html)
- [What I learned building an app in Hanami](https://rossta.net/blog/what-i-learned-about-hanami.html)
- [Rails vs Hanami](http://teotti.com/rails-vs-hanami/)
- [Controllers: the Rails way vs the Hanami way](https://sipsandbits.com/2018/05/23/rails-controllers-vs-hanami-controllers/)
- [RottonSoftware: Validating records in Hanami](http://www.rottensoftware.com/validation_in_hanami/)
- [RottonSoftware: Hanami - Entities and Repositories](http://www.rottensoftware.com/hanami-entities-and-repositories/)
- [Invalid Object Is An Anti-Pattern](https://solnic.codes/2015/12/28/invalid-object-is-an-anti-pattern/)
- [Luca Guidi - Hanami 2.0 - rubyday 2019](https://vimeo.com/339279205)
- [Hanami 2.0 demo app](https://github.com/jodosha/soundeck)

### 推薦書單

- [Domain-Driven Design](https://www.tenlong.com.tw/products/9780321125217)
- [Clean Architecture](https://www.tenlong.com.tw/products/9780134494166)
- [Practical Object-Oriented Design in Ruby](https://www.tenlong.com.tw/products/9780134456478)

---

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


post-Hanami - 軌道外的風景

Hanami - 軌道外的風景


時間永遠是固定的24小時這麼多，如何掌握在有限的時間內取捨事情的優先順序？

PM 手中可能會有多個專案在進行，最有可能遇到的狀況，例如：

你一早進到公司，正打開電腦要回 A 專案客戶的訊息，結果不到兩秒鐘， B 客戶問你能不能開個簡短的視訊會議討論他剛剛新開的 issue，接著 C 客戶突然又在群組上問你昨天會議的事情，然後同事走過來問你午餐要吃什麼(咦)。

是的，彷彿受到詛咒一般，點開什麼東西，事情就會一卡車的跟著飛來XD

>做事之前，先排列好優先順序，勇者打怪也是要照步驟來的。

## 優先順序
### 以有限的時間為前提，做出取捨

手中有太多事時，如同前面所提到，在有限的時間內優先處理重要且緊急的事情，可以從下面的象限圖，將你手中的事情先大致分為四塊：

(請看我<del>簡單明瞭的</del>象限圖表)

- 緊急且重要的事情
- 緊急但不重要的事情
- 不緊急但重要的事情
- 不緊急也不重要的事情

用上述的四象限去安排優先順序，比起遇到什麼事就先解決什麼事，倒不如從優先緊急的事情下手，對於自己的時間安排會更好掌握。

以專案管理上會遇到的狀況來說，若時程緊縮無法調整的時候，也可以依照此象限表去跟客戶協商哪些功能或是畫面是最緊急重要的，進而做出取捨。

但我有看過另一種說法，通常我們做不重要又不緊急的事情<del>總是最愉快的，有時候甚至最快完成，例如：追劇打遊戲。</del>

## 排程

>我為什麼需要為自己的時間排程？
>—— 排程表可以一眼看出整個時間的分配計劃

確定好需要安排的事項後，將它們記在任何你擅長使用的排程工具上，遇到計畫調整時，可以較為輕鬆直覺地去安排。

排程這個動作也可以運用在專案管理上，你可以使用排程表去和專案成員 or 客戶討論議題，最起碼你手上有個可以直接調整的時程表，方便雙方討論，減少溝通成本。

排時程表除了『提醒自己有這些待辦事情』外，也有『應對突發狀況而需要調整』時，可以一眼看出整個計畫的走向，從而去迅速的協調安排的功能。

>有時候會有這種疑問：專案就算排程了，也只是預估的時間，跟實際上所花費的時間還是會有所差距，那為什麼要排程?

就像出去旅行，也會大致安排幾個今天要吃的食物 / 要去的景點，比起毫無排程，有安排過後的行程可以掌握到大概有哪些事情需要去完成，調好整體專案的速度與步驟，隨時可以應付變動，搭配最前面提到的象限表，做出取捨或是應對方法。

## 適度留白

>那些平時被你疏忽的小事，也會佔據你的時間。

不是當下緊急的事情，常常容易被忽略去估算花費的時間，覺得總會有時間去完成。舉例來說：每天大概會花費30~60分鐘整理各專案的進度，又會花 15-30 分鐘去準備隔日會議的內容。

又例如，預估時程時，開發前的評估+研究，跟開發完成後的測試時間，看起來只是普通的兩件事，但其實這後面有許多隱藏成本，例如評估研究時，跟客戶雙向溝通的時間成本、還有測試時出現 bug 時，解決也需要時間，小事疊加起來，耗掉的時間也是非常可觀的。

所以在行程前後通常會再抓一些餘裕，是用來應對有意料外的狀況發生時，還有緩衝的時間可以消耗。

## 搭配專注的爆發力，不可小覷

在每件執行的事情上，最好將一切外在的干擾排除，保持一定的高專注力，全數貫注於手頭的事情上，將進度衝刺到最大值。

公司工程師們曾經跟我討論過一個話題，打 code 有時候打到一定的程度時需要高度專注與心力投入，被打擾的話，要再度切回原本的思緒與高專注力是有困難的，就像你算數學算到一半，有人叫你寫作文，寫完再繼續切回去算數學一樣，心情很難恢復啊——！

## 結語

上述所提的幾個小主題，可以幫助你在時間上作出較合理的時程安排，避免讓自己陷入什麼事都想做，卻什麼事都沒做完的狀況。

延伸到專案上的話，除了排優先度的先後順序外，難免會有功能必須做出取捨，如同前面提到，可以幫你節省大量的溝通與時間成本，希望對於有興趣研究時間管理與時程安排的你，可以增添一些幫助 :)

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

ASTRO Camp

線上課程

短期課程

技術文章

五倍消息

技術文章

新手也可以輕鬆玩轉 SASS - @mixin and @include

如何著手設計你的第一個網站？

透過 amp-access 讓你在 Cache 頁面也能順利保持登入！

總覺得自己在工作上不夠稱職？論冒名頂替者症候群所帶來的影響

CI/CD 從零開始 - 使用 CircleCI 部署 Node.JS App 到 GCP App Engine

VSCode 的奇幻旅程

Hanami - 軌道外的風景

勇者，成為時間的支配者吧！

訂閱文章

電話 | (02) 2331-5247

信箱 | [email protected]

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

專業課程

ASTRO Camp

線上課程

短期課程

關於我們

關於五倍紅寶石

聯絡我們

媒體報導

加入我們

部落格

技術文章

五倍消息

幫助與政策

常見問題

隱私權政策

服務條款