在 Windows 使用 Vue cli ，Vue2 + TypeScript

 首先安裝 Node.js

 官網

windows 使用 win + R ，輸入 cmd 叫出命令提示字元，接著確認 Node.js 有無安裝成功，輸入

node -v。

有出現 Node.js 的版本號就可以進行下一步安裝 Vue Cli，在命令提示字元輸入 npm install -g @vue/cli。

一樣確認版本，輸入 vue -V。

最後可以選擇用指令或是 UI 來操作，我習慣用 UI ，可以不用一直打 npm run serve，在命令提示字元輸入 vue ui 打開 vue cli 的 UI。

正要用 Hexo 做部落格放自己的文章，所以就取叫 blog ，用 Github 可以順便把下面初始化 Git 倉庫打勾，下一步。

這一頁的設定就比較多：

• Babel 是轉譯 ES6 語法...等等向下相容用。
• TypeScript 是 JavaScript 強型別的改進，正要順便練習所以加入。
• Router 是作 SPA 用的路由，如果重視 SEO， 一種是不用 Router，一種是加入 Nuxt.js。
• Vuex 是不同路由之間轉傳資料的倉庫。
• CSS Pre-processors 是 CSS 預處理器，筆者習慣用 SASS 所以要選，沒選也可以之後再加入。
• Lint 是規範，ESLint 多一些，從善如流選起來。
• Unit Testing 單元測試，寫簡單的小測試可以用，選一下。

選擇詳細的自訂選項，筆者比較常用 SASS 、ESLint、Jest，選好就可以按新增嚕。

首頁：

任務：

任務這邊會有常用的需要指令，開發時的編譯、部屬、測試...等等，當然也可以再導入 CI/CD 

工具，先介紹到這，順便幫自己回憶一下 Vue Cli 的安裝與操作。

初學 Vuex

        Vuex 就是比較大型的儲存庫的概念，裡面存儲的數據可以傳給各個 .vue 檔，也可以傳

回來，規模大小是 Vuex(比較有規範跟方法) > store(開一個js檔案存) > eventbus(內外元件)。

首先安裝，筆者是用 Vue Cli 開發，用 npm 安裝，當然 yarn 也可以。

npm install vuex --save

在 main.js 中使用

import Vuex from 'vuex'

Vue.use(Vuex)

new Vue 裡加入 store，ES6 中 store: store 可以簡寫。

同樣在 main.js 中建立倉庫。

state 是儲存資料的地方，可以很多筆，跟 store 差異最大的地方是：改變 state 的資料時，必須

使用 mutation 裡的方法，例如 store.commit('increment', 10)，方法可以加入參數，所以上式就

可以將 count + 10。

在另外一個 .vue 檔實際讀改數據。

頁面還有其他東西，所以 <template> 部分標籤跟 method 的 } 有興趣嘗試的自行補上，count 

跟item 透過 this.$store.state 可以顯示為0 ，當按下按鈕觸發 addStore 的時候，利用 

this.$store.commit('mutation裡的方法',可選的參數)，來更改 state 裡的資料。

目前只看到基本用法，其他就留待日後研究。

Git Flow 與版本控制

 Git Flow 就是利用 Git 的分支功能進行開發流程管理的一種方法，Git Flow 主張利用 master 、

develop 、 hotfix 、 release 、 feature 五種分支進行管理。

master：存放穩定上線版本，並附上版本號。

develop：開發用分支，真正的主分支，要開發的功能從這個分支出去到 feature ，開發完之後也合併回 develop。

feature：開發功能時從 develop 出來，開發完合併回 develop。

release：最後測試用分支，當 develop 版本要上線時，在 release 進行測試，之後上線同時與 master、 develop 進行合併。

hotfix：如果 master 還是不幸出大事( bug )，就開 hotfix 來修，修好合併回 master 及 develop。

從上述過程中，各修正如果修好了都要同時對 master 與 develop 合併，是比較複雜，並且 

develop 看起來比較像 master 主導整個專案運作。

因此就產生了 Github Flow 與 GitLad Flow ，將關注點重新回到 master 上，新功能依然使用

新分支，開發完成合併回 master ，但上線版本時間不一定與 master 相同，因此 GitLab Flow 

主張發布版本額外創一個分支，即 develop --> master --> 上線版本分支，是對於 Git Flow 的

改進。

參考資料：

為你自己學 Git

Git三大特色之WorkFlow(工作流)

Vue Cli 使用 Vue Testing Library 作測試

 打開終端機，輸入 vue ui 先用 Vue Cli 開新專案，選項就一般的 SASS 、 Router 、 ESLint 、

還有這次的主題 Test ，然後會看到 Vue Test Utils 裝好了。然後是神Q超人來六角進行 CI/CD 

講座時的教學，npm Vue Testing Library 可以用簡單的方法 DOM 測試，容後詳述，CI自動化

部屬下篇研究，這篇先介紹寫單元測試：

測試的 JS 檔案有幾種放法：xxx.spec.js、xxx.test.js 或是放在_test_資料夾下，也可以在 

package.json 下作設定

.vue 檔作個簡單的範例：

簡單的按按鈕加一或減一，測試的目標就是按鈕或欄位是否正確。

新增 addtest.spec.js ，測試命名最好簡單直接，可以一眼明白測試什麼用的。

第一步： import 使用到的 Testing Library API ，以及需要測試的 .vue 檔。

第二步：使用 test 寫測試內容，利用 getByTestId 找到 .vue 檔的 data-testId ，選到顯示的數字

第三步： Jest 經典的斷言寫法 expect() ... .toBe ，檢查內容是否相同。

寫完後 npm test 看到勾勾就解決啦。後面還有自動產生錯誤檔的路徑跟內容...等可以延伸，

或是更複雜的測試。

卡關的部分：不會解的地方，如果用 parcel.js 下載下來 postCSS、TailwindCSS，需要 postCSS 

8.0。同樣用 parcel.js 下載，選擇 Vue、SASS、Jest，之後 npm 其他東西，最後寫好作測試的

時候，會有 Cannot find module 'babel-core' 的錯誤，再 google 尋找解法，是 babel7 之後要分開

安裝 babel-core ...等，但始終無法正確執行，找不到是 vue-jest 還是一串哪個路徑錯誤。

三向交握 (Three Way Handshake) 及未來傳輸協議發展閱讀心得

     現今主流的傳輸協議為 HTTP / TCP ，其中由於皆為明文傳輸，因此 HTTP 演進為 HTTPS ，

HTTPS 的差別就是利用加密方法來加密，並且利用信任鏈分散流量，例如 A 是可信賴的憑證發行

機構，那麼通過 A 頒發的 B、C、D ，以及 B 頒發的 E、F、G 皆可信任。

接下來說到 TCP 著名的三向交握傳輸方式，區分為客戶端和伺服器端，算是一種互相試探？

的過程。

首先客戶端向伺服器端發送第一次訊息，內容為簡單可辨識的資料 X 。

伺服器端收到 X 之後，發送第二次訊息，包含收到 X 、

傳送簡單可辨識的資料 Y 、嘗試請求資料 Z 。

最後客戶端發送第三次訊息，包含收到 Y、傳送 Z 。

    這個過程經過簡化，實際上還有傳送一些其他資訊。在參考資料中提到 HTTP/3，與 

HTTP/TCP 相比，差異最大的就是在 UDP 而非 TCP，那麼在加密以及如何省去傳輸內容增加

傳輸速度上就要關心一下。

以下解說引用自參考資料 HTTP/3 傳輸協議 - QUIC 原理簡介：「

初始交握 (Initial Handshake)

在連線的一開始，客戶端會傳送一個哈囉訊息 (CHLO, Client Hello) 到服務端，觸發服務端回傳一個代表交握未建立或是公鑰已經過期的拒絕訊息：REJ 封包，REJ 中包含四比資料：

1. Server Config：包含服務端的長期DH公鑰 (Diffie-Hellman Public Key)
2. Certificate Chain：用來對服務端進行認證的憑證串鏈
3. Signature of the Server Config：經過數位簽章過的 Server Config，讓客戶端可以驗證這些資訊確實是由服務端發出。
4. Source-Address Token：經過認證加密過後的客戶端IP資訊

在客戶端收到 REJ 後，依照 QUIC的 定義，雙方就已經完成了交握，可以開始安全的傳輸資料。這是為什麼呢？讓我們看看從 REJ 中客戶端得到了哪些資訊：

1. 服務端的驗證：透過憑證串鏈和數位簽章，客戶端可以驗證服務端的真實性和資料的可靠性。
2. 初始密鑰 (Initial Key)：客戶端在收到 REJ 後，首先要為這次連線隨機產生一個自己的短期DH密鑰，將自己的短期密鑰和服務端的長期公鑰進行運算後，就可以得到一個初始密鑰。(這邊密鑰的交換使用的是 Diffie–Hellman key exchange，如果對這個方法不熟悉的讀者可以參考WIKI連結：Diffie–Hellman key exchange )

」

此篇先以 Diffie-Hellman Key 作一個斷點，還有其他作法為了速度、以及漏封包...等等的改進

機制，容後再議。

為什麼 Diffie-Hellman Key 可以產生安全的通道？以顏色來舉例：首先 A 與 B 選擇了一個起始

顏色，暫定為 C 與 A 決定其秘密顏色 AC ，B 決定其秘密顏色 BC ，然後分別將起始顏色與

秘密顏色混合 C+AC C+BC ，之後交換 C+AC 與 C+BC的結果，最後將得到的混合顏色加入

自己的秘密顏色得到最終結果， A 為 C+BC+AC、B 為 C+AC+BC，兩者相等，第三者無法

從已知資訊 C 及 C+AC 、 C+BC 推導出 AC 與 BC 的值，當然其中有些數字可以很小，有些

則要非常大，但此處只為了理解如何以簡短的流程產生出第三者無法得知的秘密。

參考資料：

一文搞懂 HTTP 和 HTTPS 是什麼？兩者有什麼差別

[30 天學會 Web 前端效能優化] 4. TCP 三向交握

HTTP/3 傳輸協議 - QUIC 原理簡介

Diffie–Hellman key exchange