Amo's Blog

Claude Code + VOICEVOX：二次元女僕語音提示設定教學

Sun, 12 Jul 2026 00:00:00 GMT

前言

在使用 Claude Code 的過程中，經常會遇到需要等待授權或任務完成的情況。為了讓你能夠即時收到這些通知，我們可以利用 Claude Code 提供的 Hooks 來實現語音提示。

本文將介紹如何使用 macOS 內建的指令以及開源的 VOICEVOX 軟體來實現二次元女僕語音提示，讓你的工作流程更加高效和有趣。

什麼是 Claude Code Hooks？

Hooks 是 Claude Code 提供的一項自動化機制，它們就像是 AI 行為的中間件（Middleware）。

Hooks 允許開發者在 Claude Code 運行的特定生命週期（例如：執行指令前、修改程式碼後、工作階段開始時），自動觸發自定義的 Shell 指令、HTTP 請求或 AI 提示詞。這提供了對 AI 行為的確定性控制，確保某些安全規則或自動化任務百分之百會執行，而不需要盲目依賴大語言模型（LLM）去「記憶」或「選擇」遵守提示詞。

設定 Hooks 主要有兩種方式：透過命令列的互動式指令，或是手動編輯 settings.json 檔案。

這裡我們選擇手動編輯全域（Global）範圍的 ~/.claude/settings.json。

打開檔案之後，應該會看到 hooks 這個欄位：

{
  "hooks": {...}
}

我們可以新增或修改 Stop 這個 hook，讓它在任務完成時自動唸出「任務完成」：

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "say \"任務完成\""
          }
        ]
      }
    ]
  }
}

什麼是 `afplay`？

afplay（全稱 Audio File Play）是另一個 macOS 系統內建的命令列音訊播放器。

簡單來說，它讓你可以不用打開「音樂」App 或 QuickTime，直接在終端機裡面透過指令來播放音樂或音效檔案。

macOS 內建音效

`Notification` Hook

除了 Stop 之外，還可以使用 Notification 這個泛用的 Hook 來播放其它通知：

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Funk.aiff && say \"等待許可\""
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Glass.aiff && say \"任務完成\""
          }
        ]
      }
    ]
  }
}

VS Code 的侷限

我自己習慣使用 Claude Code for VS Code 擴充功能（extension）多於 CLI，因為它提供了更完整的 IDE 體驗，透過直觀的圖形化介面與視覺化管理，免去切換視窗的繁瑣，讓 AI 協作更流暢、專注且高效。

但是，這個 extension 目前有一個問題，就是 Notification Hook 無法正常運作。

Notification Hook 原本是為終端機模式（CLI）設計的，當遇到等待授權或閒置時，用來通知可能已切到其它視窗的你。但在 VS Code extension 裡，這些狀態會被 IDE 的原生 UI 直接接手，核心便不再廣播 Notification，Hook 因此失效。Stop 則屬於核心生命週期，任何介面下結束對話都會觸發，不受影響。

方案 A：VS Code 擴充功能

可以安裝社群專門修補此問題的 VS Code extension，例如 Claude Notifier。

但是 Claude Notifier 的問題是無法自訂通知內容。

方案 B：改用其它 Hooks（推薦）

另一個解決方法是直接改用其它 Hooks 來取代 Notification。

Hooks 的種類：

事件名稱	觸發時機	是否可阻斷	常見應用場景
`SessionStart`	新的工作階段啟動或恢復時	否	注入專案上下文、檢查環境變數（如 Docker 是否啟動）
`UserPromptSubmit`	使用者送出提示詞，Claude 開始思考前	是	敏感資訊過濾、自動補全專案規則（Context Injection）
`UserPromptExpansion`	當輸入的斜線指令（Slash commands）展開為 Prompt 時	是	調整擴充後的 Prompt 內容
`PreToolUse`	Claude 準備呼叫任何工具（如 Bash, Edit, Write）之前	是	安全防火牆（如：封鎖 `rm -rf`、禁止修改 `.env`）
`PermissionRequest`	系統彈出工具執行授權提示（Y/N）時	是	自動授權特定安全工具，減少人工確認
`PostToolUse`	工具成功執行完畢且回傳結果之後	否	自動執行代碼格式化（如 Prettier）、自動跑 Linter
`PostToolUseFailure`	工具執行失敗時	否	錯誤日誌分析、自動化環境修復
`SubagentStart`	Claude 呼叫 Agent 工具派生出子代理（Subagent）時	否	初始化子代理的環境
`SubagentStop`	Subagent 完成任務並結束時	是	驗證子代理產出的程式碼品質
`Stop`	Claude 完成該輪對話的所有回應時	是	最終程式碼品質把關（Quality Gate）、發送通知
`StopFailure`	Claude 產生回應失敗或中斷時	否	記錄錯誤、清理暫存檔
`SessionEnd`	使用者關閉或終止 Claude Code 工作階段時	否	清理環境、匯出本次對話的 Audit Log

以這邊的使用情境來說，PermissionRequest Hook 是最適合的選擇，因為它會在系統彈出授權提示、等待使用者許可時觸發，讓我們可以自動播放通知音效：

{
  "hooks": {
    "Notification": [...],
    "PermissionRequest": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Funk.aiff && say \"等待許可\""
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Glass.aiff && say \"任務完成\""
          }
        ]
      }
    ]
  }
}

進階玩法：VOICEVOX

如果只是使用系統內建的語音指令，雖然方便，但聲音比較單調，缺乏個性。為了讓通知更有趣，我們可以使用 VOICEVOX 來實現二次元角色語音提示。

什麼是 VOICEVOX？

VOICEVOX 是一款由日本開發者所開發的免費、開源 AI 文字轉語音（TTS）軟體。

過去像 VOCALOID（如初音未來）這類的軟體主要是用來「唱歌」，而語音合成軟體則多半價格高昂。VOICEVOX 的出現徹底打破了門檻，讓沒有預算請配音員的獨立影片創作者，也能輕鬆做出高品質的配音影片。

安裝 VOICEVOX

前往 VOICEVOX 官方網站：

ダウンロード（下載）
Mac → CPU（Intel or Apple） → インストーラー（Installer）
安裝應用程式
打開 VOICEVOX，就會看到可以選擇的角色與語音風格。

建立腳本

效仿 say 指令，建立一個 say_maid 腳本檔案 ~/.scripts/say_maid（路徑可自行決定）：

#!/bin/zsh

# 檢查是否有輸入文字
if [ -z "$1" ]; then
  echo "請輸入你想讓女僕說的話，例如：say_maid '主人，歡迎回來'"
  exit 1
fi

# 1. 產生語音 Query JSON
curl -s -X POST "http://localhost:50021/audio_query" \
     --url-query "speaker=2" \
     --url-query "text=$1" > /tmp/voicevox_query.json

# 2. 合成語音並下載為 wav 檔
curl -s -H "Content-Type: application/json" \
     -X POST -d @/tmp/voicevox_query.json \
     "http://localhost:50021/synthesis" \
     --url-query "speaker=2" > /tmp/maid_voice.wav

# 3. 使用 afplay 播放出來
afplay /tmp/maid_voice.wav

給予執行權限：

chmod +x ~/.scripts/say_maid

在 Terminal 測試效果：

~/.scripts/say_maid "終わりましたよー！ご主人様？お疲れ様です！"

~/.scripts/say_maid "ねえ、ご主人様、早く……私を確認して？"

沒意外的話，應該就可以聽到「四国めたん」的聲音了（VOICEVOX 只支援日文）。

這兩句也是開頭 demo 的語音內容，中文的意思大致是：

「任務完成了喔！主人？辛苦了！」
「喂，主人，快點……確認我吧？」

聽到那句軟軟的日文從終端機傳出來的瞬間，是不是連盯著進度條的等待都變得有趣了一些？

Speaker ID

如果想要使用其它角色或風格，可以透過 VOICEVOX 的 API 來查詢 Speaker ID，以「春日部つむぎ」為例：

打開 http://localhost:50021/speakers
在 JSON 回傳結果中找到 name 為「春日部つむぎ」的物件，裡面有 styles.id，可以看到它的 Speaker ID 就是 8：

{
  ...
  {
    "name": "春日部つむぎ",
    "speaker_uuid": "35b2c544-660e-401e-b503-0e14c635303a",
    "styles": [
      {
        "name": "ノーマル",
        "id": 8,
        "type": "talk"
      }
    ],
    "version": "0.16.1",
    "supported_features": {
      "permitted_synthesis_morphing": "ALL"
    }
  },
  ...
}

將 say_maid 腳本中的 speaker=2 改成 speaker=8，就可以使用「春日部つむぎ」的聲音了：

...

# 1. 產生語音 Query JSON
curl -s -X POST "http://localhost:50021/audio_query" \
     --url-query "speaker=2" \
     --url-query "speaker=8" \
     --url-query "text=$1" > /tmp/voicevox_query.json

# 2. 合成語音並下載為 wav 檔
curl -s -H "Content-Type: application/json" \
     -X POST -d @/tmp/voicevox_query.json \
     "http://localhost:50021/synthesis" \
     --url-query "speaker=2" > /tmp/maid_voice.wav
     --url-query "speaker=8" > /tmp/maid_voice.wav

...

背景執行

到這裡，say_maid 腳本已經可以正常運作了，但每次執行前都需要先手動打開 VOICEVOX 應用，這樣就有點麻煩。

我們可以在腳本中加入自動啟動 VOICEVOX 的功能：

#!/bin/zsh

# 檢查是否有輸入文字
if [ -z "$1" ]; then
  echo "請輸入你想讓女僕說的話，例如：say_maid '主人，歡迎回來'"
  exit 1
fi

 # 偵測 Port 50021 是否有在運作
 if ! nc -z localhost 50021 2>/dev/null; then
   echo "正在為您默默喚醒女僕..."
   open -g -a VOICEVOX

   # 循環等待，直到伺服器完全啟動成功為止
   while ! nc -z localhost 50021 2>/dev/null; do
     sleep 0.5
   done
   echo "女僕已就位！"
 fi

# 1. 產生語音 Query JSON
...

但是，這樣的做法會啟動整個 VOICEVOX GUI 應用程式，對於只想要使用 TTS 功能的使用者來說，可能還是會覺得有點彆扭。

好消息是，VOICEVOX 內建了純後台的引擎程式，直接啟動它就可以使用 TTS 功能，而不需要打開整個 GUI。

首先，我們需要找到 VOICEVOX 的引擎程式路徑：

find /Applications/VOICEVOX.app \( -name "voicevox_engine" -o -name "run" \)

以我的環境為例，找到的路徑會是：

/Applications/VOICEVOX.app/Contents/Resources/vv-engine/run

修改 say_maid 腳本，將啟動 VOICEVOX 的方式改成：

#!/bin/zsh

...

# 偵測 Port 50021 是否有在運作
if ! nc -z localhost 50021 2>/dev/null; then
  echo "正在為您默默喚醒女僕..."
  open -g -a VOICEVOX
  # 直接啟動 VOICEVOX 內建的純後台引擎，並將輸出丟棄 (> /dev/null 2>&1 &)
  /Applications/VOICEVOX.app/Contents/Resources/vv-engine/run > /dev/null 2>&1 &

  # 循環等待，直到伺服器完全啟動成功為止
  while ! nc -z localhost 50021 2>/dev/null; do
    sleep 0.5
  done
  echo "女僕已就位！"
fi

...

搞定！現在，當你執行 say_maid 時，如果 VOICEVOX 還沒啟動，它會自動在背景啟動，並且不會打開 GUI。

最後，我們只要把 ~/.claude/settings.json 中的 say 指令改成 say_maid，就可以在 Claude Code 的 Hooks 中使用二次元女僕的語音提示了：

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Funk.aiff && say \"等待許可\""
            "command": "afplay /System/Library/Sounds/Funk.aiff && ~/.scripts/say_maid \"ねえ、ご主人様、早く……私を確認して？\""
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Glass.aiff && say \"任務完成\""
            "command": "afplay /System/Library/Sounds/Glass.aiff && ~/.scripts/say_maid \"終わりましたよー！ご主人様？お疲れ様です！\""
          }
        ]
      }
    ]
  }
}

總結

從一開始的 say「任務完成」，到最後讓「四国めたん」在背景默默待命、任務結束時對你說一聲「お疲れ様です」，我們其實只做了一件事：把 Claude Code 的等待與完成，變成能被聽見的訊號。

回顧整個過程：

Hooks 是核心：Stop 與 PermissionRequest 讓「任務完成」和「等待許可」這兩個關鍵時刻，能夠確定性地觸發通知，不必盯著螢幕。
系統內建就很夠用：say 與 afplay 兩個 macOS 原生指令，零安裝就能做出堪用的語音提示。
VS Code 的坑：Claude Code extension 下 Notification Hook 會失效，改用 PermissionRequest 是更乾淨的解法。
VOICEVOX 進階玩法：包成 say_maid 腳本、查詢 Speaker ID 切換角色，再用純後台引擎自動喚醒，就能在不打開 GUI 的情況下獲得高品質的角色語音。

比起效率工具，這更像是一點為日常寫程式加溫的小巧思。當冰冷的終端機開始有了聲音與個性，等待授權的空檔、任務完成的瞬間，也就多了一絲陪伴的溫度。希望這篇文章能為忙於工作的你，帶來一點會心一笑的樂趣。

為什麼 Netflix 截圖會變黑？聊聊 DRM 技術與未來趨勢

Mon, 04 May 2026 00:00:00 GMT

從一張黑屏截圖說起

你是否曾有過這樣的經驗：在追 Netflix 的熱門影集或觀看 Disney+ 的最新大片時，看到一個絕美的畫面想截圖當桌布，或是想錄下一段精彩對白分享給朋友，結果截出來的圖卻是一片漆黑？

這並不是你的手機壞了，也不是 App 出了 Bug，而是串流平台背後那套嚴密的「數位版權管理」（Digital Rights Management，簡稱 DRM）機制在發揮作用。

身為負責公司學習平台 VOD 建置的工程師，我常被問到：在技術如此發達的今天，為什麼我們還能看到盜版資源？為什麼有些設備就是跑不出 4K？這背後其實是持續多年的技術拉鋸戰。本文將帶你拆解 DRM 的運作核心，並揭開 2026 年即將普及的 AI 隱形浮水印技術，看看這場防盜技術的攻防戰如何演進。

https://blog.amowu.com/posts/2020-09-04-hls-signed-cookies/

別誤會，DRM 不只是「加密」那麼簡單

很多人以為 DRM 就是把影片加密（Video Encryption），但本質上，它是一整套複雜的「密鑰管理系統」。如果只有影片加密，一旦使用者拿到了鑰匙並解密，他就擁有了檔案，可以無限次播放或拷貝給別人。而 DRM 比較像是一位「保全」，它不僅管你有沒有鑰匙，還管你進屋後能待多久、能不能拍照、能不能把東西帶走。確保只有獲得授權的使用者，在受信任的環境下，才能取得那把解開影片的鑰匙。

DRM 的運作包含三個核心機制：

CDM（Content Decryption Module）：這是瀏覽器內置的一個硬體或軟體沙盒，負責真正的解密與渲染。由於它是個「黑盒子」，JavaScript 無法觸碰其內容，這就是為什麼截圖會變黑 —— 影像是在 CDM 內部渲染的，完全繞過了瀏覽器的渲染層。
License：加密檔案本身是死的，但「許可證」是活的。當你點擊播放時，CDM 會向伺服器請求一張許可證，上面寫滿了限制規則：這把鑰匙只能用 24 小時、你只能看 1080p 的畫質、或者你現在的 IP 位置不符合版權範圍。只有當你符合清單上所有規則，CDM 才會為你點頭開鎖。
Hardware Enforcement：現代 DRM 不只靠軟體，還直接與你的硬體（CPU 和顯示晶片）合作。例如透過 HDCP 協議，如果 DRM 發現你接了一個不合格的投影機，硬體層級會直接切斷訊號。

這種從瀏覽器到伺服器，再到硬體內部的「封閉信任鏈」，就是為什麼你即便設法拿到了鑰匙，也無法反抗這些限制的原因。

了解了這三道安全防線後，身為前端工程師的我們還必須認識三個組件：

EME（Encrypted Media Extensions）：它是播放器與 CDM 之間的「橋樑」。作為 W3C 標準的 API，它負責將密鑰請求傳給伺服器，再把拿到的許可證傳回給 CDM。
MSE（Media Source Extensions）：負責將下載下來的加密影片片段（Segments）源源不絕地餵入播放器中。
PSSH（Protection System Specific Header）：這是埋在影片流中的資訊，包含了重要的「金鑰 ID（Key ID）」。沒有 PSSH，CDM 不知道需要哪把金鑰，也無法生成正確的 Challenge。

三大主流陣營：Google、Apple、Microsoft 的角力

在實作 DRM 時，開發者最頭痛的就是跨平台兼容性，因為不同的瀏覽器與設備背後分別由三大巨頭把持：

DRM 方案	幕後大佬	主要支持環境	技術特點
Widevine	Google	Chrome, Android, ChromeOS	應用最廣，分為 L1 (硬體級) 到 L3 (軟體級)。
FairPlay	Apple	Safari, iOS, macOS	高度垂直整合，幾乎純硬體級別，安全性極高。
PlayReady	Microsoft	Edge, Xbox, Windows	歷史悠久，在智慧電視（Smart TV）滲透率極高。

特別值得一提的是 Apple 的 FairPlay。由於 Apple 掌控了從晶片（M/A 系列）、作業系統到瀏覽器的完整生態，FairPlay 將解密工作徹底交給硬體層的「Secure Enclave（安全隔離區）」。這種封閉哲學使其安全性極高，但也讓它顯得相當「不合群」，不支援任何非 Apple 設備，甚至在開發調試上也是出了名的麻煩。

解析「畫質之謎」：為什麼我的裝置只能看 1080p？

你可能發現過，明明買了 Netflix 最高級的會員，但在一些手機或某些電腦瀏覽器上，畫質卻被限制在低畫質。這與 Widevine 的「強健度（Robustness）」等級有關。

Widevine L1：解密與解碼完全發生在硬體受信任執行環境（TEE）中。片商對此高度信任，因此願意開放 4K 與 HDR。
Widevine L3：解密是在軟體層級完成的。對於駭客來說，軟體層較容易透過逆向工程破解，因此片商通常只給予低畫質以降低風險。

// 1. DRM 基本配置
const drmConfig = [{
  initDataTypes: ['cenc'],
  videoCapabilities: [{
    contentType: 'video/mp4; codecs="avc1.42E01E"',
    // 如果你強行要求 HW_SECURE_ALL（L1）
    // 但使用者設備僅支援 L3，播放器會直接報錯黑屏。
    // 專業的做法是偵測到失敗後，
    // 自動 Fallback 要求 SW_SECURE_DECODE（L3），
    // 至少讓用戶能看到低畫質的畫面。
    robustness: 'SW_SECURE_DECODE'
  }]
}];

const video = document.querySelector('video');

// 2. 監聽 'encrypted' 事件：這是獲取 PSSH 的標準入口
video.addEventListener('encrypted', async (event) => {
  console.log('--- 偵測到加密內容 ---');
  console.log('初始化數據類型:', event.initDataType); // 通常是 'cenc'

  // 這就是你需要的 PSSH Data！
  const pssh = event.initData;

  try {
    // 3. 請求 CDM 存取權限
    const access = await navigator.requestMediaKeySystemAccess('com.widevine.alpha', drmConfig);
    const keys = await access.createMediaKeys();
    await video.setMediaKeys(keys);

    // 4. 建立解密會話
    const session = keys.createMediaKeySession();

    // 5. 處理 License 請求
    session.addEventListener('message', async (msgEvent) => {
      console.log('收到 Challenge，正在向 License Server 請求金鑰...');

      const response = await fetch('https://your-license-server.com/get-key', {
        method: 'POST',
        body: msgEvent.message
      });

      const license = await response.arrayBuffer();

      // 6. 將拿到的鑰匙塞入 CDM
      await session.update(license);
      console.log('DRM 解密成功，影片開始播放！');
    });

    // 7. 告知 CDM 根據這段 PSSH 生成 Challenge
    await session.generateRequest(event.initDataType, pssh);

  } catch (error) {
    console.error('DRM 流程錯誤:', error);
  }
});

這裡有一個「Chrome 悖論」：即使你有一台價值十萬的頂規 PC，在桌面版 Chrome 上通常也只能看到 1080p 甚至更低。這是因為 Windows/macOS 的硬體解碼環境太雜，Chrome 往往只能運行 L3 軟體保護。這也是為什麼在 Mac 上想看 4K Netflix，你必須使用 Safari （Google 近年已在 Windows 平台上導入 Microsoft PlayReady 支援，試圖打破 4K 瓶頸）。

開發者的噩夢：FairPlay 那極其「人工」的申請流程

實作 FairPlay 的過程通常比 Widevine 痛苦得多，因為它的流程充滿了「Apple 式」的嚴謹與人工審核：

申請與憑證：必須具備 Apple 開發者組織帳號，並申請 FPS Deployment Package。
Application Certificate：這是 FairPlay 的獨門要求。在發送 License 請求前，播放器必須先下載這個二進制憑證，否則 CDM 連密鑰請求都生不出來。
換取 ASK：在 Apple 後台生成證書時，會產生一串 ASK（Application Secret Key）。
警告：ASK 在網頁生成時「只會出現一次」，沒存下來就得全部重來。
整合：將證書、私鑰與 ASK 交付給播放器或後端。

// FairPlay 專屬：獲取 Application Certificate
async function fetchAppCert(certUrl) {
  const response = await fetch(certUrl);
  const arrayBuffer = await response.arrayBuffer();
  return new Uint8Array(arrayBuffer);
}

async function setupFairPlay(video, certUrl) {
  const appCert = await fetchAppCert(certUrl);

  video.addEventListener('encrypted', async (event) => {
    // 1. 取得 FairPlay 的 Key System
    const access = await navigator.requestMediaKeySystemAccess('com.apple.fps', [{
      initDataTypes: ['skd'], // FairPlay 常用 skd 或 sinf
      videoCapabilities: [{ contentType: 'video/mp4; codecs="avc1.42E01E"' }]
    }]);

    const keys = await access.createMediaKeys();

    // 2. 【關鍵點】必須先設定伺服器憑證
    await keys.setServerCertificate(appCert);
    await video.setMediaKeys(keys);

    const session = keys.createMediaKeySession();

    session.addEventListener('message', async (msgEvent) => {
      // 3. 發送 SPC (Server Playback Context) 給 Apple License Server
      const response = await fetch('your-fairplay-license-url', {
        method: 'POST',
        body: msgEvent.message
      });
      const ckc = await response.arrayBuffer(); // 回傳的是 CKC
      await session.update(ckc);
    });

    // 4. FairPlay 的 initData 通常需要從 skd:// 轉換
    const initData = event.initData;
    await session.generateRequest(event.initDataType, initData);
  });
}

如果在專案上線前兩天你才發現沒申請 FairPlay，那是絕對來不及的。因為 Apple 的審核人員可能正在放假，這不是寫程式能解決的問題。此外，如果你用了一條不合格的 HDMI 線，FairPlay 會直接丟給你一個模糊的 MediaError，讓你調試到懷疑人生。

既然有 DRM，為什麼盜版平台還是有 4K 資源？

儘管 DRM 很強，但它防的是「普通用戶」，而非「專業組織」。盜版資源主要透過三大漏洞流出：

Widevine L3 漏洞：駭客透過逆向工程提取軟體層密鑰，直接從伺服器下載原始流並解密。這稱為 WEB-DL（最高境界，畫質無損且與原始檔案一致）。
HDCP 剝離（Analog Hole）：利用特殊擷取卡偽裝成合法顯示器，在 HDMI 傳輸中剝離 HDCP 保護。這稱為 WEB-Rip（經過二次壓縮，細節略損）。
CDM 零日漏洞：專業組織發現瀏覽器解密模組的未公開漏洞，模擬合法 L1 設備索取 4K 密鑰。

為了提高安全性，Widevine 現在也引入了 Service Certificate（類似 FairPlay 的預先認證），讓 License 請求從第一步開始就是加密的，確保隱私不被截獲。

DRM 就像家裡的門鎖，它防不了帶專業工具的盜賊，但它能確保路過的行人無法隨意進來搬東西。

省時省力的秘密：JW Player Studio DRM 託管方案

為了不讓開發者深陷在 EME 實作的泥沼中，DRM as a Service 應運而生。以 JW Player Studio DRM 為例，它實現了高度封裝：

CMAF 統一打包：透過 CMAF（Common Media Application Format）技術，同一份影片檔案可以同時支援 Widevine、PlayReady 和 FairPlay，這為平台節省了約 66% 的存儲成本。
前端極簡化：播放器 SDK 會自動偵測環境。在 Safari 啟動 FairPlay，在 Chrome 啟動 Widevine，在 Windows 則啟用 PlayReady。
擴充性：若需要自備 License Server，開發者仍可透過 licenseRequestFilter 攔截請求，加入自定義的 Token 或 Header。

jwplayer("video").setup({
  playlist: [
    {
      file: "video.mpd",
      drm: {
        widevine: { url: "..." },
        playready: {
          url: "...",
          licenseRequestFilter: (req) => { ... } // 自定義請求
        },

      }
    },
    {
      file: "video.m3u8",
      drm: {
        fairplay: {
          url: "...",
          certificateUrl: "...", // App 憑證
          processSpcurl: (spc) => { ... }, // 處理 skd 轉換
          licenseRequestFilter: (req) => { ... }
        }
      }
    }
  ]
});

如果你跟我所在的團隊一樣，原本就已經採用 JW Player 作為整套影片託管的解決方案，那麼直接使用它們的 Studio DRM 會是最順水推舟的選擇（JW Player 的 Delivery API 會直接給你完整的 playlist，連上面的程式碼都不用寫）。

並非全站皆兵：什麼情境才適合用 DRM？

DRM 的握手（Handshake）會消耗大量的伺服器運算成本，因此並非全站適用。

適合 DRM：好萊塢電影、高價線上課程、企業機密培訓。這些內容通常有合約強制要求。
不適合 DRM：行銷廣告、新聞、UGC（使用者上傳內容）。這些內容追求傳播量，DRM 反而會增加播放延遲並導致舊設備無法開啟。

YouTube 就是典型案例：一般影片不加密以利傳播，但電影租借則會強制啟動 Widevine 保護。

正在主流化：AI 隱形浮水印與 A/B 變體技術

無論是 WEB-DL 還是 WEB-Rip 檔案流出時，AI 隱形浮水印（Forensic Watermarking）是最後的防線。它甚至能防禦 DRM 無法解決的「類比漏洞（如手機翻拍）」。

其核心是「雲端 A/B 切換模式」：

原理：轉碼時針對同一段 2–6 秒的片段生成 A、B 兩個微小差異版本。
組合：CDN 根據使用者 ID 給予專屬序列（如 A-B-A-A-B…）。
追蹤：AI 具備強大的「抗畸變（Anti-distortion）」能力。即使盜版影片被手機翻拍、嚴重壓縮或裁切，AI 依然能從像素中的微小擾動回推這段 A/B 序列，精準鎖定洩漏者的 User ID。

這套技術就像是給影片植入了「數位 DNA」。以前盜版者可以說：「這是別人在網路上傳的，不關我的事。」現在透過這套序列，平台可以非常有底氣地說：「這就是從你的帳號、在 14:05 分、用某型號電視看的時候流出的。」

傳統若要為每位使用者嵌入唯一浮水印，必須進行「使用者數量 x 影片數量」的獨立轉檔，這成本是完全不切實際的天文數字。相較之下，A/B 變體技術無論背後的使用者規模多大，永遠只需要預先輸出 A、B 兩份版本（影片數量 x 2）。

面對「合謀攻擊（Collusion Attack）」（駭客對比不同使用者影片來抹除浮水印），AI 嵌入的特徵是非線性的且分佈在不同頻域，使破解成本高到不符合經濟效益。

未來趨勢：WebAssembly DRM

WebAssembly DRM 正在興起。它讓服務商可以部署自定義的解密演算法，實現跨瀏覽器的一致性，不再受限於 Google、Microsoft 或 Apple 的 CDM，實現「軟體定義安全」的靈活性與自主權。

展望未來，主流的安全架構也許將是混合式的：DRM（攔截非法存取）+ AI 隱形浮水印（追蹤洩漏來源）+ Wasm（統一安全邏輯）。

一場無止境的經濟攻防戰

從黑屏截圖到 AI 隱形浮水印，我們看到串流技術的演進始終圍繞著一個核心：安全性不在於「絕對不可破解」，而在於「不斷增加破解成本」（當然，前提是產品開發成本不會先讓老闆崩潰，畢竟安全性也是有邊際效益的）。

在 AI 浮水印能精準追蹤到每個人的 2026 年，傳統的「盜版分享」是否終將消亡？抑或會演變成另一種更高層次的技術對抗？這場影像防盜的攻防拉鋸戰，顯然還沒有終點。

Pact Contract Testing

Sun, 14 Jul 2024 00:00:00 GMT

不知道大家有沒有聽過「契約測試」這個冷門的概念，它適合兩種對象：

一個後端（API server）＋多個 client 端（web＋mobile）
多個 server 端（例如 microservices）

這篇文章會介紹 Pact 這個契約測試工具，以及 PactFlow 這個服務。

前言

大概是在 2017 年左右，當時我正在尋找前端 mock server 相關資料的時候，第一次聽到「契約測試」這個概念，當時並沒有深入去瞭解它。

Mock Server＆契約測試

後來公司開始有了 iOS & Android 工程師，這時候就出現一些問題。因為後端的 API 要同時服務於 web 前端跟 mobile app，有時候兩邊要的東西是不一樣的，可能就很容易產生衝突。在尋找解決方案的時候，又再次聽到契約測試的名字。

即便是今天，我搜尋了一下 contract testing，還是沒多少人在介紹，可見這個東西是相對冷門的。於是我就決定來研究一下它是什麼，並於 2023 年在公司的前端聚會上分享，這篇文章就是整理自當時簡報的內容。

以下是大綱：

什麼是 Contract Testing？
Pact Contract Testing 如何運作
5 分鐘指南
總結

什麼是 Contract Testing？

Content testing 的中文通常翻譯成「契約測試」，也有一些地方譯作「合約測試」或「合同測試」。

這是一種整合測試（Integration testing）技術，通過對每個應用（application）進行獨立檢查，確保其「發送」或「接收」的「訊息」符合記錄在「契約」中的共識。

例如，對於通過 HTTP 進行通信的應用，這些訊息將是 HTTP 請求（request）和回應（response）；而對於使用隊列（queues）的應用，訊息則是放入隊列的消息（message）。

在實踐中，實施契約測試的常見方式（也是 Pact 的方式）是檢查所有對「測試替身（test doubles）」發送和接收的結果，是否與對真實應用發送和接收的結果一致。

何時該使用契約測試？

契約測試適用於任何需要通信的兩個以上的應用，最簡單的例子是 API server 與 web 前端之間的通信。

雖然單個客戶端對單個服務端的情況較為常見，但在多個服務環境下，契約測試能發揮最大的作用。例如現今流行的微服務（Microservices）架構中，使用契約測試能幫助開發人員更好地管理版本。

契約測試會用到的術語

契約通常由**消費者端（Consumer）和提供者端（Provider）**直接簽訂。Consumer 端可以想像成需要獲取某些資料的客戶端（client），而 Provider 端則是提供資料的伺服器（server）。

那為何不直接使用 client 和 server 呢？因為在微服務架構中，通信可能是伺服器對伺服器之間的通信，這時使用 client 和 server 並不合適，因此更傾向於使用 Consumer 和 Provider 這兩個術語。

Contract Testing Patterns

契約測試主要分為兩種模式（pattern）：

以消費者為驅動的契約測試（Consumer-Driven Contract Testing）
以提供者為驅動的契約測試（Provider-Driven Contract Testing）

今天要介紹的 Pact 是一種 Code-First 的「消費者驅動契約測試」工具。

什麼是 Code-First 呢？

契約是在 Consumer 執行測試的階段自動產生，這就是所謂的 Code-First Consumer-Driven。

這種模式的優點是只有 Consumer 實際使用的通信部分才會被測試。因此，如果 Provider 對當前 Consumer 未使用的部分進行修改，測試也不會受到影響。

其他類似於契約測試的概念還包括 Schema Testing 和 OpenAPI specification（OAS），不過這些今天都不會提到，有興趣的人可以看這篇官方文章。

Pact Contract Testing 如何運作

在說明 Pact 契約測試如何運作之前，我們先來看看傳統測試會有哪些問題。

Microservices and API testing framework

整合測試的問題

整合測試（Integration testing）雖然能提升信心，但也會引入依賴關係。因為 Consumer 和 Provider 需要一起運作，這會使除錯變得緩慢。例如，使用 Cypress 進行 E2E 測試時，可能需要執行完整的回歸測試（Regression testing）才能發現問題，這會延遲修正問題的時間。

此外，整合測試較容易失敗。例如，前端或後端的一些小改動可能會導致整個測試失敗，迫使我們重新編寫測試，增加了維護的負擔。

Hahow for Business 如何跑 E2E 測試？

獨立測試的問題

那為什麼不獨立的測試呢？獨立測試將 Consumer 和 Provider 分開測試，這樣能提供獨立運作的優點，反饋速度快且測試穩定，維護也較容易。然而，獨立測試相比整合測試，對發佈（release）的信心較低，可能會在上線後才發現真實世界中的問題。

Pact 契約測試

那 Pact 是如何運作的呢？我們先來看 Consumer 端。在測試期間，Consumer 會對模擬 Provider 的 mock server 發送 request，並記錄預期的 response。這些互動（interactions）會自動生成一份契約（稱作 pact）。

Provider 端則會拿到這份生成的契約，對其進行回放（replays），檢查 Provider 實際產生的 response 是否符合 Consumer 的預期。如果兩者匹配，我們就能確信它們在真實應用中的行為也是符合預期的。

這就是 Pact 契約測試的大致運作流程。這種方法同時保有獨立運作的優點，反饋快速且測試穩定，維護起來也容易。此外，Pact 契約測試也能夠提升我們的發佈信心，雖然不如整合測試那麼強，但比獨立測試更有信心。

PactFlow

使用 Pact 契約測試後，就會需要管理這些契約（pacts），否則每次都要等 Consumer 生成契約再交給 Provider 測試，這會很麻煩。因此，需要一個中介角色，Pact 將之稱作 Pact Broker。

具體操作是自動化將契約存放到某個地方，Provider 再從中取回契約進行測試。這塊除了可以自行實作，也可以使用 Pact 提供的開源 Pact Broker。此外 Pact 還提供了一個完全托管的 Pact Broker 服務，叫做 PactFlow，後面會介紹。

Pact Contract Testing

5 分鐘指南

接下來，我將介紹官方提供的五分鐘指南。

官方五分鐘指南Demo

官方五分鐘指南有提供一個範例 repository，有興趣的朋友可以自行 clone 下來操作。

目錄結構介紹

Clone 下來後，目錄結構大致如下：

pact-5-minute-getting-started-guide/
├── consumer/
├── pacts/
├── provider/
├── scripts/ci/
├── index.html
├── index.js
├── package.json
├── pact.js
├── publish.sh
├── runConsumerTest.js
├── runProviderTest.js
└── runTest.js

主要的資料夾包括：consumer、provider 和用來存放自動產生契約的 pacts 資料夾。為了方便理解，官方將 Consumer 和 Provider 都放在一起，這樣演示比較方便。

我們先來看一下 package.json 文件，這個範例的前端和後端都是使用 JavaScript 語言：

{
  ...
  "dependencies": {
    "express": "^4.18.2"
    ...
  },
  ...
}

測試工具的部分，前端和後端都是使用 mocha 和 chai，以及 Pact 提供的測試 library：

{
  "devDependencies": {
    "@pact-foundation/pact": "12.1.0",
    "mocha": "^10.2.0",
    "chai": "^4.3.7",
    ...
  }
}

測試流程

首先，我們會執行 Consumer 端的測試，指令是 npm run test:consumer，接著執行 Provider 端的測試，指令是 npm run test:provider。這兩個測試都是在本地進行的：

{
  "scripts": {
    "test:consumer": "node runConsumerTest.js",
    "test:provider": "node runProviderTest.js",
    "test": "npm run test:consumer && npm run test:provider",
    ...
  },
}

演示完這部分之後，我還會示範如何將契約發佈到 PactFlow 執行測試，主要指令是 npm run test:broker：

{
  "scripts": {
    ...
    "pact:publish": "./publish.sh",
    "test:broker": "npm run test:consumer && npm run pact:publish && npm run test:provider",
  },
}

Consumer 測試

我們先來看 Consumer 端的測試。這個範例主要是測試一個訂單 API，前端會呼叫 RESTful API 並轉換成自己的 model 結構：

class Order {
  constructor(id, items) {
    this.id = id;
    this.items = items;
  }

  total() {
    return this.items.reduce((acc, v) => {
      acc += v.quantity * v.value;
      return acc;
    }, 0);
  }

  toString() {
    return `Order ${this.id}, Total: ${this.total()}`;
  }
}

module.exports = {
  Order,
};
// consumer/orderClient.js

const request = require("superagent");

const { Order } = require("./order");

const hostname = "127.0.0.1"

const fetchOrders = () => {
  return request.get(`http://${hostname}:${process.env.API_PORT}/orders`).then(
    (res) => {
      return res.body.reduce((acc, o) => {
        acc.push(new Order(o.id, o.items));
        return acc;
      }, []);
    },
    (err) => {
      console.log(err)
      throw new Error(`Error from response: ${err.body}`);
    }
  );
};

module.exports = {
  fetchOrders,
};

我們會對這個 model 進行單元測試，測試會模擬一個 HTTP GET 請求來獲取訂單，並將返回的 response 轉換為前端的訂單 model：

// 設定我們的測試框架
const chai = require("chai");
const expect = chai.expect;
const chaiAsPromised = require("chai-as-promised");
chai.use(chaiAsPromised);

// 我們需要 Pact 才能在測試中使用它
const { provider } = require("../pact");
const { eachLike } = require("@pact-foundation/pact").MatchersV3;

// 導入我們的待測邏輯（orderClient）和訂單模型
const { Order } = require("./order");
const { fetchOrders } = require("./orderClient");

// 這是我們開始寫測試的地方
describe("Pact with Order API", () => {
  describe("given there are orders", () => {
    const itemProperties = {
      name: "burger",
      quantity: 2,
      value: 100,
    };

    const orderProperties = {
      id: 1,
      items: eachLike(itemProperties),
    };

    describe("when a call to the API is made", () => {
      before(() => {
        provider
          .given("there are orders")
          .uponReceiving("a request for orders")
          .withRequest({
            method: "GET",
            path: "/orders",
          })
          .willRespondWith({
            body: eachLike(orderProperties),
            status: 200,
            headers: {
              "Content-Type": "application/json; charset=utf-8",
            },
          });
      });

      it("will receive the list of current orders", () => {
        return provider.executeTest((mockserver) => {
          // Mock server 是在一個隨機可用的 port 上啓動的，
          // 因此我們設置了 API_PORT，這樣 HTTP 客戶端就能動態找到 endpoint 了。
          process.env.API_PORT = mockserver.port;
          return expect(fetchOrders()).to.eventually.have.deep.members([
            new Order(orderProperties.id, [itemProperties]),
          ]);
        });
      });
    });
  });
});

其中 require("../pact") 會先 setup 測試環境，這些設置包括 Consumer 和 Provider 的名稱以及契約的存放位置（本地的 pacts 資料夾）：

const path = require("path");
const consumerName = "GettingStartedOrderWeb";
const providerName = "GettingStartedOrderApi";
const pactFile = path.resolve(`./pacts/${consumerName}-${providerName}.json`);
...

module.exports = {
  pactFile,
  consumerName,
  providerName,
  ...
};

然後是 Provider mock server 的設置：

const pact = require("@pact-foundation/pact");
const Pact = pact.PactV3;
const path = require("path");
const process = require("process");
...

...

const provider = new Pact({
  log: path.resolve(process.cwd(), "logs", "pact.log"),
  dir: path.resolve(process.cwd(), "pacts"),
  logLevel: "info",
  host: "127.0.0.1",
  consumer: consumerName,
  provider: providerName,
  host: "127.0.0.1"
});

// 用於在出現錯誤時 kill 剩餘的 mock server instances
process.on("SIGINT", () => {
  pact.removeAllServers();
});

module.exports = {
  provider,
  ...
};

接著，我們運行 Consumer 測試指令 npm run test:consumer：

➜ npm run test:consumer

> test:consumer
> node runConsumerTest.js

...

  Pact with Order API
    given there are orders
      when a call to the API is made
...
        ✔ will receive the list of current orders

  1 passing (14ms)

consumer test passed! Open the pact file in .../pact-5-minute-getting-started-guide/pacts/GettingStartedOrderWeb-GettingStartedOrderApi.json

測試通過後，pacts 資料夾會生成一個契約文件，記錄 Consumer 預期的 request 和 response：

{
  "consumer": {
    "name": "GettingStartedOrderWeb"
  },
  "interactions": [
    {
      ...
      "request": {
        "method": "GET",
        "path": "/orders"
      },
      "response": {
        "body": [
          {
            "id": 1,
            "items": [
              {
                "name": "burger",
                "quantity": 2,
                "value": 100
              }
            ]
          }
        ],
        ...
      }
    }
  ],
  ...
  "provider": {
    "name": "GettingStartedOrderApi"
  }
}

Provider 測試

Provider 端的範例使用 Express.js 搭建一個簡單的 API server，提供 GET /orders 的端點，返回訂單數據：

const express = require("express");
...
const server = express();

...

// "寫死" 的示範資料
let dataStore = require("./data/orders.js");

server.get("/orders", (_, res) => {
  res.json(dataStore);
});

module.exports = {
  server,
  dataStore,
};
// provider/data/orders.js

module.exports = [
  {
    id: 1,
    items: [
      {
        name: "burger",
        quantity: 2,
        value: 20,
      },
      {
        name: "coke",
        quantity: 2,
        value: 5,
      },
    ],
  },
];

在 Provider 測試中，我們同樣會引入 Pact 的設置文件。這些設置包括契約文件的位置，以及一些測試環境的變數。

Provider 測試會模擬 Consumer 的請求，檢查實際的 response 是否符合契約的預期：

const Verifier = require("@pact-foundation/pact").Verifier;
const chai = require("chai");
const chaiAsPromised = require("chai-as-promised");

const { server } = require("./provider.js");
const { providerName, pactFile } = require("../pact.js");

chai.use(chaiAsPromised);

let port;
let opts;
let app;

const hostname = "127.0.0.1"

// 驗證 Provider 是否滿足所有 Consumer 的期望
describe("Pact Verification", () => {
  before(async () => {
    port = 3000;

    opts = {
      // 我們需要知道 Provider 的名稱
      provider: providerName,
      // 我們需要確定 Provider 運行的位置
      providerBaseUrl: `http://${hostname}:${port}`,
      ...
    };

    // 為了方便起見，我們提供了執行 npm run test:consumer 時，
    // 產生的示例契約的路徑。
    opts = {
      ...opts,
      pactUrls: [pactFile]
    }

    ...

    app = server.listen('3000', '127.0.0.1', () => {
      console.log(`Provider service listening on http://localhost:${port}`);
    });
  });

  after(() => {
    if (app) {
      app.close();
    }
  });

  it("should validate the expectations of Order Web", () => {
    console.log(opts)
    return new Verifier(opts)
      .verifyProvider()
      .then((output) => {
        console.log("Pact Verification Complete!");
        console.log(output);
      })
      .catch((e) => {
        console.error("Pact verification failed :(", e);
      });
  });
});

接著，我們運行 Provider 測試指令 npm run test:provider：

➜ npm run test:provider

> test:provider
> node runProviderTest.js

...

  Pact Verification
Provider service listening on http://localhost:3000
{
  provider: 'GettingStartedOrderApi',
  providerBaseUrl: 'http://127.0.0.1:3000',
  pactUrls: [
    '.../pact-5-minute-getting-started-guide/pacts/GettingStartedOrderWeb-GettingStartedOrderApi.json'
  ]
  ...
}
...

Verifying a pact between GettingStartedOrderWeb and GettingStartedOrderApi

  a request for orders (0s loading, 441ms verification)
     Given there are orders
    returns a response which
      has status code 200 (OK)
      includes headers
        "Content-Type" with value "application/json; charset=utf-8" (OK)
      has a matching body (OK)

...
Pact Verification Complete!
finished: 0
    ✔ should validate the expectations of Order Web (603ms)

  1 passing (607ms)

provider test passed! Open the pact file in .../pact-5-minute-getting-started-guide/pacts/GettingStartedOrderWeb-GettingStartedOrderApi.json

以上就是 Pact 契約測試的本地範例運作原理。

PactFlow

最後，我們來介紹如何將契約發佈到 Pact Broker 進行管理。

官方提供了一個名為 PactFlow 的全託管 Broker 服務，有免費方案可以使用。

我們需要註冊 PactFlow 以取得 API Token 和 PactFlow base URL。

回到 Provider 測試，我們重新配置了相關變數，這樣 Provider 才有辦法從 PactFlow 獲取契約：

...

describe("Pact Verification", () => {
  before(async () => {
    ...

    // 如果我們有 Broker，那麼還有一些相關的配置
    if (process.env.PACT_BROKER_BASE_URL) {
      opts = {
        ...opts,
        // 我們需要知道我們的 Broker 在哪裡
        pactBrokerUrl: process.env.PACT_BROKER_BASE_URL,
        // 我們需要有關我們正在驗證的 Provider 版本的詳細信息，
        // 以便我們稍後可以識別它。
        providerVersion: process.env.GIT_COMMIT,
        providerVersionBranch: process.env.GIT_BRANCH,
        // 只有在 CI 的情況下，我們才需要自動發布契約
        publishVerificationResult: !!process.env.CI ?? false,
      }

      // 我們需要設置 Broker 身份驗證選項
      if (process.env.PACT_BROKER_TOKEN) {
        opts = {
          ...opts,
          pactBrokerToken: process.env.PACT_BROKER_TOKEN,
        }
      }

      ...
    }
    ...
  });
  ...
});

配置好之後，我們準備執行 run test:broker 指令。

在執行之前，我們先來看一下這個指令，前面介紹指令時有提到，npm run test:broker 會執行三個步驟的指令：

npm run test:consumer - 執行 Consumer 測試，產生契約
npm run pact:publish - 將契約發佈到 PactFlow 上（script 細節本文就不介紹了）
npm run test:provider - Provider 從 PactFlow 獲取契約，執行 Provider 測試

理解指令的作用之後，我們開始執行 run test:broker 指令：

➜ PACT_BROKER_BASE_URL=<YOUR_PACT_FLOW_BASE_URL> \
PACT_BROKER_TOKEN=<YOUR_PACT_FLOW_API_TOKEN> \
# 如果在 CI 執行的話，通常會自帶 GIT_COMMIT 和 GIT_BRANCH，可以不用指定
GIT_COMMIT=$(git rev-parse HEAD) \
GIT_BRANCH=$(git rev-parse --abbrev-ref HEAD) \
npm run test:broker

這裡就不貼出冗長的輸出結果了，如果順利的話，你就會看到這三個步驟的執行過程並且通過測試。

測試結束之後，就可以在 PactFlow 上看到發布的契約文件：

之後你就可以把這套機制丟到 CI 上，自動化契約測試的流程了，未來如果 Consumer 或 Provider 有一方的更改違反了契約，CI 測試就會失敗。

以上就是官方五分鐘指南的基本原理，當然真實環境一定沒有像範例這麼單純，例如 Provider 端通常不會跟 Consumer 一起跑 CI，這時候可能就會需要用到 Pact 的 webhooks 之類的，有興趣的朋友可以自行深入探索。

總結

我們來回顧一下 Pact Contract Testing 的概念：

整合測試（Integration testing）雖然在發布時的信心表現較好，但它引入了依賴關係，反饋速度慢，測試不穩定等問題，增加了維護難度。
獨立測試（Unit testing）雖然解決了整合測試的一些問題，但難以模擬真實環境，因此發布的信心不足。
Pact 契約測試引入中間契約的概念，記錄了 Consumer 對 Provider mock server 預期的 request 和 response。Provider 則根據契約回放，確保真實環境的互動與 Consumer 的預期匹配。
契約需要有地方管理，Pact 稱作 Broker。你可以自己實作一個，也可以使用 Pact 開源的 Pact Broker，或使用 Pact 提供的 Broker 服務 PactFlow。

參考

Automate browser testing with tools

Tue, 18 Jun 2024 00:00:00 GMT

隨著科技的迅速發展，網站和應用程式的複雜性日益增加，對品質和穩定性的要求也變得更加迫切。在這篇文章中，我們將探討自動化測試的重要性、如何在組織中實施自動化測試，以及 Chrome 提供的測試工具和策略。

前言

最近有許多跟前端相關的 conference，例如 React Conf 2024、Google I/O 2024 以及 React Paris 24。

雖然每段議程都不長，但要全部追完也是很累人，所以公司同事就揪大家一起共筆。

我認領到的議程有這三場：

這篇是第二篇，介紹《Automate browser testing with tools and best practices from Chrome》，第一篇可以點擊下方連結前往。

Real-time Server Components

自動化測試的重要性及其優勢

確保品質

在電子商務網站中，用戶需要完成多次互動來完成訂單，每個互動都是潛在的故障點。通過自動化測試，可以全面覆蓋這些互動，確保每個步驟的可靠性，提前發現並解決這些問題，減少系統崩潰和功能故障的風險，使品質能成為產品的一部分，而不是事後考量。

觀察全球受歡迎的電子商務網站，平均來說，使用者需要完成至少 16 次的互動才能順利下訂單。

每一次互動都是潛在的失敗點。跑版，按鈕無法點擊、API 沒有正確回應等…。而這還只是網站中數百個互動情境的其中之一。

提高開發效率

自動化測試在每次 commit、Pull Request 和 release 時自動運行，可以減少了手動測試的資源和時間消耗，使開發團隊能更專注於新功能的開發和現有功能的優化。

如何在組織中實施自動化測試

統一心態

在實施自動化測試的過程中，團隊內部需要達成共識：品質即功能（Quality as a feature）。這意味著將品質視為一種投資，而不是負擔。滿意的客戶會帶來繁榮的業務，一旦這種心態被接受，測試（Tests）自然成為產品開發工作流程的一部分。

測試流程的整合

將自動化測試納入每個功能完成的定義中（DoD），並在開發流程的每個關鍵步驟中運行測試。例如，每次 commit 程式碼、每次 Pull Request 以及每次完整 release 或環境變更後，都應進行測試。此外，確保測試相關的衡量標準對組織中的每個人都是可見和可訪問的，例如，每月發佈次數、bug reports、測試覆蓋率，以便追踪進度、影響並更好地了解產品的健康和品質。

Chrome 測試工具及策略

Chrome for Testing

新推出的 Chrome for Testing 是專為自動化測試設計的特製版本，它不會自動更新，但包括所有 Chrome Stable 版本的功能，可以用於複製特定版本的測試環境。這對於需要在特定版本的 Chrome 上進行測試的情況特別有用。

Channel	Chrome for Testing	Chrome Stable	Chrome Beta	Chrome Dev	Chrome Canary
特點	特製版本，不自動更新，包含所有 Chrome Stable 功能	針對大眾使用者，功能穩定可靠	即將成為 Stable 版本的測試版，功能相對穩定｜最新功能和修復，每週更新一次	最實驗性的版本，每天更新，包含所有最新功能和修復
更新頻率	不定期	每月	每四至六週	每週	每天
適用對象	測試工程師、開發人員	所有人	UX/UI 團隊、開發團隊	工程團隊、開發人員	開發者、測試人員
主要用途	自動化瀏覽器測試	日常瀏覽使用、確保穩定性	提前預見即將發佈的功能和變化	測試最新功能和 API，提前適應變化	是用最新的 Chrome 功能和 API，進行實驗性測試

新 Headless 模式

過去 Chrome 的舊 headless 模式（無頭模式）是單獨維護的瀏覽器版本，容易發生結果不一致的問題。新 headless 模式不再是單獨維護的瀏覽器，而是與 Chrome Stable 使用相同的程式碼，支援所有 Chrome Stable 功能。這使得測試 Extensions 和使用 WebGPU（AI 相關應用）的網站變得更加容易。

// for Chrome Extensions

import puppeteer from 'puppeteer':

const EXTENSION_PATH = '~/dino/workspace/my-super-cool-extension-src';
const EXTENSION_ID = 'jkomgjfbbjocikdmilgaehbfpllalmia' ;

const browser = await puppeteer.launch({
  headless: true, // Defaults to new headless mode from Puppeteer 22+
  args: [
    '--disable-extensions-except=${EXTENSION_PATH}',
    '--load-extension=${EXTENSION_PATH}',
  ]
});

const page = await browser.newPage();
await page goto('chrome-extension://${EXTENSION_ID}/page.htm');

// for Chrome Extensions

import puppeteer from 'puppeteer':

const EXTENSION_PATH = '~/dino/workspace/my-super-cool-extension-src';
const EXTENSION_ID = 'jkomgjfbbjocikdmilgaehbfpllalmia' ;

const browser = await puppeteer.launch({
  headless: true, // Defaults to new headless mode from Puppeteer 22+
  args: [
    '--disable-extensions-except=${EXTENSION_PATH}',
    '--load-extension=${EXTENSION_PATH}',
});

const page = await browser.newPage();
await page goto('chrome-extension://${EXTENSION_ID}/page.htm');
// for WebGPU

const browser = await puppeteer.launch({
  // Defaults to new headless mode from Puppeteer 22+
  headless: true,
  args: [
    '--no-sandbox',
    '--headless=new',
    '--use-angle=vulkan',
    '--enable-features=Vulkan',
    '--disable-vulkan-surface',
    '--enable-unsafe-webgpu',
  ]
});

跨瀏覽器測試

為了確保網站在所有瀏覽器中都能良好運行，Google 與主要瀏覽器和測試工具供應商合作開發了 WebDriver BiDi 協議。這個協議允許使用相同的命令自動化所有瀏覽器，不論其引擎如何。目前，部分自動化工具如 Selenium、WebDriver I/O 和 Puppeteer 已部分支持 WebDriver BiDi。Firefox、Chrome 和 Edge 都已經或計劃部分支持 WebDriver BiDi。

您仍可以使用現有的 WebDriver 標準來自動化所有瀏覽器。

總結

自動化測試是一種確保產品品質的重要手段，應成為每個開發團隊的核心部分。通過充分利用 Chrome 提供的測試工具（Chrome for Testing、新 headless 模式）和策略（WebDriver BiDi），我們可以確保產品在各個瀏覽器中的一致性和可靠性。品質即功能，自動化測試能使我們更自信地面對未來的挑戰，並提供更優質的用戶體驗。

人工智慧的極限

Mon, 10 Jun 2024 00:00:00 GMT

本文將探討哪些問題是 AI 可以解決的，哪些是它無法觸及的。希望通過這篇文章，讀者能夠對計算的本質與 AI 的限制有更清晰的認識，理性看待這項技術的發展。

前言

在這個數位化迅速發展的時代，AI 逐漸成為我們生活中的一部分。從智能助理到自動駕駛汽車，AI 技術的應用範圍日益擴大。大數據和深度學習技術的飛速進步，使得 AI 在語音識別、圖像處理等領域表現得愈發出色。近期，生成式 AI 例如 ChatGPT 和 DALL-E，更是展現了 AI 在創意和生成內容方面的巨大潛力。

然而，隨著這些技術的進步，許多人也開始擔心：AI 會不會超越人類的能力，甚至取而代之？

最近讀了吳軍的《計算之魂》一書之後，我深受啟發，決定節錄書中的精華內容，撰寫成這篇文章。

什麼是計算機

計算機（電腦）的歷史可以追溯到幾千年前，從中國的算盤到現代的電子計算機。儘管現代電子計算機在 1946 年才被發明，但計算的概念早已存在。計算機的核心構成包括計算單元、存儲單元和控制指令序列（馮諾伊曼架構）。沒有指令序列，計算機就不完整。

中國的算盤雖然簡單，卻蘊含了基本的計算思想。算盤的設計基於珠算口訣，使用中國算盤，人所提供的不過是機械動能，而非頭腦中的運算能力，算盤是在口訣指令的控制下完成機械運動的，而機械運動能得到計算結果，這與現代計算機的指令控制有異曲同工之妙。

中國算盤（圖右）之所以被視為計算機，是因為它依靠珠算口訣控制操作，而古羅馬算盤（圖左）只是輔助計算工具，沒有指令序列的控制功能。

布林代數和開關電路

進入工業時代後，人們開始設計機械計算機來自動執行計算任務。布萊茲·帕斯卡和哥特弗利德·萊布尼茲先後發明了能進行加減運算的機械計算機，而查爾斯·巴貝奇則設計了更複雜的差分機，儘管未能成功製造出來，但其思想深遠地影響了後來的計算機發展。

喬治·布爾發明了布林代數統一算術與邏輯，為現代邏輯電路奠定了基礎。克勞德·夏農（信息論之父）則是將布林代數應用於電氣工程，設計出基於開關電路的邏輯運算，這一突破性發明使現代數位計算機成為可能。

康拉德·楚澤通過簡單模組的複製，成功研制出了世界上第一台可編程計算機 Z1。這台計算機利用布林代數和邏輯電路，實現了複雜計算的模組化，使得計算機的設計和製造進入了一個新階段。

數學與邏輯的局限

在討論 AI 的極限時，必須首先理解數學和邏輯的邊界。數學家大衛·希爾伯特提出了三個重要的問題：數學是否完備（complete）、一致（consistent）和可判定（decisive）。所謂完備性，就是說對於任意一個命題，要麼可以證明它是對的，要麼可以證明它是錯的；一致性指的是一個命題不能既是真的又是假的；可判定性則是能否判斷一個具體問題是否有答案。

庫爾特·哥德爾通過其哥德爾不完備定理證明，數學不可能同時是完備和一致的。這意味著有些問題是無法通過數學方法證明其對錯的。1970 年，蘇聯數學家尤里·馬季亞謝維奇解決了希爾伯特第十問題，證明了對於絕大多數不定方程，我們既不能證明它們有整數解，也無法證明它們無解。這說明，有些問題即使是最先進的 AI 也無法解決，因為它們根本不是數學問題。

圖靈機的理論邊界

在 20 世紀 30 年代中期，艾倫·圖靈開始思考三個非常根本的問題：

數學問題是否都有明確的答案？
如果有明確的答案，是否可以通過有限步的計算得到？
是否能有一種假想的機器，通過機械運動解決這些數學問題？

圖靈提出的圖靈機模型定義了哪些問題是可計算的（可以在有限步內完成計算），哪些問題是不可計算的（無法在有限步內完成計算）。

圖靈機的概念不僅幫助定義了計算的邊界，還引入了幾個關鍵的計算元素：紙帶（相當於現代的存儲地址）、讀寫頭、規則表（即今天的指令集）和寄存器（即計算機狀態）。這些元素構成了現代計算機的基本原理，使得計算過程與機械運動相對應。圖靈機將複雜的計算過程簡化為一系列基本操作，這一思路奠定了數字計算的基礎。

圖靈機將複雜的計算過程簡化為一系列基本操作，這一思路奠定了數字計算的基礎。

圖靈在思考計算機相關問題時，會回到問題的本源，拋開具體技術，從計算的本質來尋找計算機的極限。現代計算機，包括最先進的 AI 系統，都沒有超越圖靈機定義的可計算問題範疇。

人工智慧的極限

在 2016 年，當 Google 的 AlphaGo 擊敗了李世石之後，許多人開始擔心世界上所有的事情是否都能由計算機比人類做得更好。然而，這種擔心多少有點杞人憂天，因為無論是什麼樣的計算機，實際上只能解決世界上一小部分問題。

我們在前面提到，世界上的很多問題並不是數學問題，這一點已經由希爾伯特和哥德爾等人證明了。如果我們畫一個大圈代表所有問題（下圖集合 S₁）的話，那麼所有的數學問題（集合 S₂）只是這個大圈中的一個小圈而已。

馬季亞謝維奇解決了希爾伯特第十問題，這一發現使得我們清楚地知道，有些數學問題無法判定答案存在與否，這意味著我們無法用邏輯方法推導出答案。因此，我們可以將數學問題中的一小部分看作是可判定（是否有答案）的問題（集合 S₃），而真正有答案的問題（集合 S₄）的數量則更少。

在數學領域，只有一部分問題我們能夠判斷是否存在答案，大部分問題是無法判斷答案是否存在的。

在有答案的問題中，有一些是可以通過圖靈機解決的問題（下圖集合 S₅），即我們前面提到的可計算問題。現實生活中的計算機能解決的問題（即工程可解問題，集合 S₆）是可計算問題的一個小子集。

AI 的實際應用主要集中在工程可解問題上，這些問題可以通過現有的算法和計算能力在合理的時間內解決。然而，很多問題的計算複雜度高於可接受的範圍，即使計算機速度提升一萬倍，也無法顯著改善這些問題的解決能力。例如，某些加密算法的破解時間即使在量子計算機的幫助下也需要極其漫長的時間。

人工智慧可解問題只是有答案的問題中很少的一部分

今天的人工智慧主要是基於大數據的深度學習。我們可以把人工智慧系統理解為由特定程序（控制指令序列）控制的、能夠解決某一類問題的計算機。例如，語音和圖像識別、無人駕駛、自動翻譯、下圍棋或象棋等，這些問題並未超出圖靈機可計算問題的範疇。

人工智慧之所以顯得很聰明，是因為很多問題過去人們沒有找到轉變為數學問題的橋梁，而現在找到了。這意味著集合 S₆ 沿著某個維度擴大了一些範疇，但無論怎麼擴展，它都不可能超出可計算問題的范疇。

利用 AI 技術已經解決的問題（大圓內的小圓和橢圓）只是工程可解問題中的一小部分

很多人只看到局部的進步，就誤認為 AI 技術已經解決大部分問題了

結論

迄今為止，計算機相關理論和技術的發展都沒有超越圖靈機的范疇。也就是說，80 多年前圖靈為計算機所能解決的問題劃的那條線，至今還沒有被逾越。這說明理論對工程的影響是多麼深遠。在學術界，試圖越過圖靈劃的紅線其實沒有必要。今天，世界上需要用計算機、用人工智慧來解決的問題實在太多，因此將注意力放在利用它們解決現有的問題上，而不是杞人憂天或異想天開，更有意義。

未來是否會有能夠解決非數學問題的機器？或許會有，但這不是我們今天所談論的計算機。

以上內容節錄自吳軍《計算之魂》這本書的第一章，省略了很多細節。如果你對這些內容感興趣，強烈建議購買這本書進行詳細閱讀。希望這篇文章能幫助你更深入地了解計算的本質。

Real-time Server Components

Sat, 08 Jun 2024 00:00:00 GMT

打破無狀態伺服器的限制：利用 Durable Objects 和 React Server Components 構建即時多人應用

前言

最近有許多跟前端相關的 conference，例如 React Conf 2024、Google I/O 2024 以及 React Paris 24。

雖然每段議程都不長，但要全部追完也是很累人，所以公司同事就揪大家一起共筆。

我認領到的議程有這三場：

剛好可以順便來嘗試最近剛訂閱的 ChatGPT Plus。

這篇先介紹 Real-time server components，其它之後有機會再陸續更新上來。

React Conf 2024 Day 1

背景介紹

講者 Sunil Pai 曾在 React 核心團隊工作，後來創辦了 PartyKit 這間公司，專注於構建即時多人應用程式。

最近 PartyKit 被 Cloudflare 收購，本人重返大公司工作。

無狀態伺服器架構的局限

無伺服器模型（Serverless）雖然有許多優點，但存在狀態管理問題。每次請求都會重置狀態，導致需要依賴外部資料庫或 key-value storage 來管理狀態。

let counter = 0;

function onRequest(req: Request) ‹
  return new Response(counter++);
}

（每次請求回應的 counter 都會是 0）

Durable Objects 的解決方案

Cloudflare 的 Durable Objects（持久化物件？）提供了狀態化服務（stateful services）的新方法。通過給定的 ID，可以建立一個保持活躍的 process，這個 process 可以處理請求並保持狀態。

// for every /chat/:id...

class Server {
  // store messages in memory
  messages = [];

  async onRequest(req: Request) {
    if (req.method === 'POST') {
      this.messages.push(await req.text());
      return Response.json({ status: 'ok' });
    }
    if (req.method === 'GET') {
      return Response.json(this.messages);
    }
  }
}

這個模型使得構建像聊天室這樣的即時應用變得簡單，開發者可以使用類似於 JavaScript 的變數來維持狀態。

class Server {
  websockets: WebSocket[] = []; // all websockets in this room
  messages: string[] = [];

  onConnect(ws: WebSocket) {
    this.websockets.push(ws);   // add websocket to array

    ws.send(
      JSON.stringify({
        type: 'message',
        data: this.messages,
      });
    );
  }

  onMessage(ws: WebSocket, message: string) {
    this.messages.push(message);

    this.websockets.forEach((w) => {
      w.send(
        JSON.stringify({ // <----- broadcast all incoming messages to all connected clients
          type: 'message',
          data: message,
        });
      );
    });
  }
}

React Server Components 的挑戰

目前在 React Server Components 中不能使用 useState 和 Context。這對於需要在伺服器端維持狀態的應用來說是一個限制。

// server
function App() {
  const [counter, setCounter] = useState(0);
  return (
    <div>
      <h1>Counter</h1>
      <p>{counter}</p>
      <Button
        onClick={() => {
          'use server'
          setCounter(counter + 1);
        }}
      >
        Increment
      </Button>
    </div>
  );
}

// browser
;('use client')
function Button({ onClick, children }) {
  return <button onClick={onClick}>{children}</button>
}

React Party

講者介紹了一個名為 React Party 的新 library（coming soon），旨在解決上述挑戰。這個 library 允許在伺服器端使用狀態和上下文，同時暴露類似於 React 的 hooks。

import {
  useState,
  useReducer,
  createContext,
  useContext,
  ReactServer,
} from 'react-party';

export class MyServer extends ReactServer {
  render() {
    return <App />
  }
}

這個 library 適合構建即時應用，如聊天室、協作工具、遊戲伺服器等，並且可以無縫整合到現有的框架如 Next.js 和 Remix 中。

React Party 的優點

在所有的 React components 中使用 state 和 context，無論是 server 還是 client
通過 WebSockets 推送 React Server Components
部署在 Global Edge Network（全球邊緣網路）以提供更低延遲的體驗
…

總結

隨著前端和後端技術的不斷進步，即時應用的開發變得越來越簡單和高效。Sunil Pai 和他的團隊通過引入 Cloudflare Durable Objects 和即將推出的 React Party，展示了如何在伺服器端高效管理狀態並進行即時更新。

Durable Objects 為無狀態伺服器架構帶來了新的希望，讓開發者能夠更輕鬆地構建高效能、低延遲的應用。同時，React Party 也將改變 React Server Components 的使用方式，使得開發者可以在伺服器端利用狀態和上下文來創建體驗更佳的應用。

使用 Heptabase 學習複雜的程式架構

Sat, 18 May 2024 00:00:00 GMT

這是我在公司的前端聚會上分享的主題，介紹 Heptabase 這個筆記工具，以及我如何使用它來完成「Hahow for Business 企業上傳串 JW Player」的研究過程。大綱如下：

前言
Heptabase 簡介
如何使用 Heptabase
我如何使用 Heptabase
總結

前言

這篇文章要介紹的是 Heptabase 這個筆記工具，以下我將簡稱它為 Hepta。

雖然這個主題和前端工程師可能沒太大關係，但是大家在學習的過程中，或多或少需要做一些筆記。所以我想分享一下我最近使用的這款筆記工具。

最近在負責將 Hahow for Business 的 VOD 從 AWS 換到 JW Player。Hahow for Business 的影片分為「訂閱制」和「企業上傳」兩種。前者是由 Hahow 提供選購的課程；後者是由企業內部自行上傳的課程。雖然兩者都是 VOD，但它們背後使用的套件和架構是完全不同的。

訂閱制比較簡單（背後是 Ruby on Rails 內建的 Active Storage），目前已經串完 JW Player 並上線運行一陣子了。最近開始處理「企業上傳」的部分，因為「企業上傳」的架構比「訂閱制」複雜得多（背後是第三方的套件 CarrierWave），加上我沒有這部分的背景知識，所以很多地方我完全不知道它是如何運作的。

一開始預到的問題是，我會一個一個檔案打開來研究程式碼，但是時間久了，我的 Chrome 和 VS Code 就會累積一堆 tabs。這樣不只是尋找檔案會很麻煩，可能休個假回來，就會想不起來之前研究到哪裡，變成又要從頭開始。所以我認為我需要一個工具來幫助我學習。

我是一個很喜歡折騰筆記工具的人，無論是最早的 Evernote 和 OneNote，或是後起之秀 Bear 和 Notion，以及近幾年因為**雙向連結（Bi-Directional Links）**火起來的 Rome Research 和 Obsidian，我都用過一段時間，可能買過的筆記軟體比我寫過的筆記還多（笑）。我也經常私訊我們產品負責人，希望 Hahow 可以做個 PKM 功能，不過每次都被笑笑打發掉（笑）。

說到雙向鏈接，想順便推薦一下《How to Take Smart Notes》這本書，近幾年在筆記圈相當火，它在介紹一種叫做「卡片盒筆記法」的方法論。這是一位德國學者叫做魯曼（Luhmann）發明的，他靠著這套方法在很多領域貢獻了許多論文。

台灣出版社也有推出中譯本，有興趣的人可以買來讀一讀。

仔細看推薦人竟然有 Hahow 的創辦人阿諾，以及接下來要介紹的 Heptabase 共同創辦人詹雨安

如果不想看書的話，張永錫老師在 Hahow 有開一門《卡片筆記術：高效內容產出的秘密》的課程，有興趣的朋友可以去支持一下。

Heptabase 簡介

雖然 Hepta 也是基於「卡片盒筆記法」構建的，但我不會太著墨這塊，這篇主要還是分享一下 Hepta 這個工具的使用。

Hepta 是由幾位台灣人共同創辦的，上圖中間這一位就是前面提到的詹雨安（Alan），他認為現有的筆記工具都有各自的問題，不符合他的需求，所以就自己創業開發了 Heptabase。很厲害的是，他們獲得了矽谷知名的創業加速器 Y Combinator（YC）的投資，目前成立了約兩年左右。

Alan（詹雨安 Alan Chan）在 Medium 上也寫了很多跟創業還有筆記相關的文章，而且都有提供中英文版本，推薦一讀。

Hepta 在 Landing Page 上的標語，寫的是「理解複雜的主題，Heptabase 幫你直觀地理解你的學習、研究和專案」，Hepta 並沒有自稱是一個筆記或知識管理工具，而是更像一個思考的工具。

Hepta 注重的是過程，而不是結果。

人類大腦更容易理解以視覺呈現的方式，Hepta 只有白板和卡片這兩個核心元素，你可以用任何習慣的呈現方式來組織你的卡片筆記。

Hepta 可以把任何筆記段落直接拖拉到白板變成一張筆記卡片，而且原本的筆記段落也會變成一個雙向連結。這樣一來，除了可以把知識粒度變小之外，還可以在任何地方重複使用這張筆記卡片。

如何使用 Heptabase

上圖是知名的 IPO Model，IPO 就是 Input、Process 和 Output，很多領域都可以套用這個模型，知識管理也可以套用這個模型。我們做筆記的過程就是吸收各種 Input，然後在筆記工具上進行 Process，最後產出各種 Output。

以我自己來講，我的 Input 通常來源是 Google 上搜尋到的文章、我訂閱的 RSS、Newsletter，或是在 Twitter 或 YouTube 上看到的內容，其它還有像是一些電子書和 PDF 的論文，還會最近一直使用的 ChatGPT 回答的結果之類的。我的 Output 可能就是希望它會變成我工作上的技術文件、分享會上用到的簡報，或是一篇部落格文章。

各種筆記軟體在做的就是中間這一塊，每一家筆記軟體的設計哲學可能都不一樣，以 Alan 在文章中建議的步驟為例：

第一步會先將閱讀的過程中看到的東西，所有重要的段落記錄下來
第二步是把這些記錄下來的段落拆解成更小的概念
第三步就是畫出這些概念之間的關聯性
然後最後一步就是把這些相似的概念群組起來

第一步：將閱讀的過程中看到的所有重要段落記錄下來

第一步中，Alan 建議把在閱讀過程中看到的重要段落記錄下來。這個過程的實作方式可能會根據你使用的工具而有所不同，不管你採用哪種方式做筆記，只要確保最終會產出一張「重點卡片」，裡頭包含你在學習過程中所紀錄的重要段落即可。

第二步：將這些紀錄下來的重要段落拆解成顆粒度更小的概念

接著你可以建立一個白板，並透過 Hepta 右上角的 Import Panel 將卡片從 Card Library 拉進這個白板裡頭。

當卡片拉進白板之後，Alan 會把它點開到右側欄，讓他更方便地瀏覽裡面的內容。Alan 通常會先快速掃過一遍這張卡片的所有內容，然後將裡面所有重要的概念識別出來。當他決定要把一個概念萃取出來時，他會把與這個概念有關的區塊選取起來一口氣拖曳到白板上變成一張新的「概念卡片」。

只有建立卡片還不夠，**他還會將這張卡片的核心概念用一句話總結，並以這句話當做是卡片標題，**以確保他一眼就能知道這張卡片在講什麼。接下來，Alan 會將這張「概念卡片」裡頭的內容重新組織，讓它的結構更符合自己的直覺；他也會看一下原本的「重點卡片」裡頭還有沒有其它與這張「概念卡片」相關的區塊，如果有的話，就把它們也拖進這張「概念卡片」裡頭。

第三步：畫出這些概念之間的關聯性

當 Alan 從重點卡片中萃取出愈來愈多「概念卡片」之後，他就會開始在這些「概念卡片」之間畫箭頭，或是把內容相近的卡片放在一起。如果他發現有兩張「概念卡片」的內容在討論相同的想法，他會將它們合併；如果他發現一張「概念卡片」裡頭包含的資訊量太大，他會把它拆解成多張更小的「概念卡片」來保持卡片的粒度。

第四步：將相似的概念群組起來

將「重點卡片」的內容都轉成「概念卡片」之後，Alan 會關掉右側欄，開始專心把這些「概念卡片」之間的關聯性和群組關係建立起來。當他發現有多張「概念卡片」都跟某個子題有關時，他會將它們用 Section 包起來，並給這個 Section 一個名字。在為 Section 取名時會跟為「概念卡片」下標題時一樣謹慎，因為這些名稱將會是未來回顧這個白板時第一眼看到的東西。

完成白板的排版之後，Alan 會把原本的「重點卡片」開在白板的右側欄，並將所有「概念卡片」和 Section 的連結重新貼回這張卡片上。

當你產出最終的白板後，吸收知識的階段就結束了。在這個過程中，真正有價值的並不是你最終產出的這個白板，而是你在執行第二步到第四步的過程中建立知識架構、給每張概念卡片和 Section 下標題所投入的思考過程。深度的理解和洞察往往源自於將知識分解、重組、用自己的話語描述的這個過程。只有在走過這個過程後，這些知識才會真正內化成自己的知識。

我如何使用 Heptabase

回到學習「Hahow for Business 企業上傳串 JW Player」的部分，我首先在 Hepta 建立了一個名為「Hahow for Business 企業上傳架構」的白板。

這裡我的使用方式跟 Alan 建議的方法不太一樣，因為我是在舊的架構上新增新功能，所以首先要釐清舊的架構，然後才能開始做新的功能。

我會先根據 VOD 的三個步驟：上傳、轉檔和交付，分別使用三種不同顏色來拆分卡片，這樣我可以比較容易一眼看出想尋找的卡片。

接著，我可能會從使用者的角度來切入。如果使用者想要跑完整個 VOD 的流程，首先，他必須進行上傳操作；其次，他需要觀看串流。

因此，使用者只會有這兩個進入點。

以上傳的過程為例，一開始會先接觸到前端一個名為 VideoLessonFormApp 的檔案。我會將相關的卡片都「黏」在一起，代表它們屬於同一檔案。但是同一個檔案底下，可能會有負責不同商業邏輯的程式碼，所以這裡就會用到前面提的顏色功能，例如：黃色代表上傳，橘色代表轉檔，藍色則是預計接下來要在這個檔案新增的程式碼。

建立卡片的過程中，我只會貼上關鍵的程式碼，避免太繁雜。Hepta 可以支援程式碼區塊的格式，也支援語法高亮，對工程師來說非常方便。另外，Hepta 也支援一些像是數學符號如 LaTeX 格式，支援的格式種類相當多，包括影片和音訊檔案等，只要使用類似於 Notion 的操作，打一個「斜線」就能插入各種不同的元素。

在學習的過程中，我也會使用畫線和 Section 功能將它們組織起來。目前我的分組方式是分為「前端」和「後端」兩個部分，線條之間的「標註」也可以幫助我理解它們之間的關係。

理清了所有關係之後，我就會開始進入預計實作的部分。這時我已經理解架構背後的運作原理，如果我要處理「上傳」JW Player 的部分，我就會找到上傳的「前端」＆「後端」的相關卡片，然後在上面新增一張藍色的卡片，直接參考關鍵程式碼的部分，一步一步在這張藍色卡片先寫上 pseudo-code。最後實際要在 VS Code 上寫程式時，我只需要打開白板，專注看藍色的卡片，一一實作相關的 pseudo-code 就可以完成了，不再需要打開一堆分頁。

最後，Hepta 也可以分享白板，不過因為這裡面是公司的程式碼，不方便分享上來，有興趣的朋友可以去試用官方分享的案例。

One more thing

分享完 Hepta 之後，我想再分享一個額外的內容。剛剛在前面有提到，我的輸入來源很多，每個來源對應的閱讀工具可能都不一樣，比如說 Google 到的文章，我會丟到 Instapaper 來稍後閱；RSS 資訊，我會用 Feedly 來閱讀，但是最近發現了一個很方便的工具，叫做 Readwise Reader。

Readwise 原本只有提供文章的 Highlight 的服務，透過瀏覽器擴充外掛，可以在網站上 Highlight 文章重點並集中管理。最近他們推出了 Readwise Reader，可以整合多種來源，除了稍後閱讀之外，還支援 RSS 訂閱，上傳 ePub 電子書，還提供隨機信箱讓你訂閱 Newsletter！並且這些內容都可以在 Readwise Reader 上 Highlight。

甚至 PDF 檔案除了文字可以 Highlight 之外，還可以 Snapshot 文件上的某個區塊，這對於筆記 AWS 架構圖這類 PDF 形式的文件來說非常方便。

其中我認為很厲害的是，Readwise Reader 還可以列出 YouTube 影片的逐字稿，並且也可以 Highlight 重點。

回到 Hepta，最近也推出了一個 Highlight 功能，但不是重造輪子，而是與 Readwise 整合，只要你有設定 Readwise 的 access token，就可以將 Readwise 的 highlights 直接拉到白板上當卡片。這樣我就可以在白板上整理我所有看過的內容（Input），並添加箭頭和 Section 來整理思路，這對於寫作和輸出（Output）相當有幫助。

總結

總結一下 Hepta 的特點，相比目前其它筆記工具，Hepta 更加專注於學習的過程，不論是零散的想法還是學習的重點，搭配 Readwise 的 highlights，都能統一匯集到這個白板上，然後以自己習慣的方式組織思考，最後在進行寫作和輸出時，可以很方便地參考之前已經內化過的結構，達到快速產出的目的。

最後幫忙工商一下，就是 Heptabase 現在還在 beta 階段，他們每天的迭代速度很快，最近已經打算要發佈 1.0 版了，如果在 1.0 發佈之前訂閱的話，以後都會是永久早鳥價。如果有興趣的話，也可以去 Product Hunt 幫他們 upvote 一下，支持土生土長的台灣新創團隊。

如何跑 TBD flow？

Wed, 27 Jul 2022 00:00:00 GMT

TBD 是一種版本控制的分支模型（source-control branching model），為了避免傳統 Git workflow 帶來的合併地獄，TBD 規定開發人員只能在被稱作「Trunk」的單一 branch 中提交程式碼，並且限制建立其它會長期存在的 branches。

前言

大家的公司或團隊，都是怎麼跑 Git workflow 呢？在執行上有沒有遇到什麼問題呢？這篇文章想要來聊聊我們團隊遇到的問題，以及解決的方式。

想解決的問題

在說明遇到的問題之前，先來看下面這張圖，這是我們團隊目前正在跑的 Git workflow：

一個 sprint 是 15 天（三週）
有三支需要 maintain 的 branches：develop、alpha 和 master，分別對應上線的 server 環境 staging、QA 和 production
Day 1～Day 10 為開發期，全部的 feature 都是從 develop 分支、對 develop 送 PR，code review 沒問題之後 merge 進 develop，接著 CI 就會自動 deploy 到 staging server
Day 10 開始進入測試期，我們的 GitHub 會自動開一個 merge develop to alpha 的 release PR，每個 sprint 安排一位 release manager 負責 review，沒問題的話，就 merge 進 alpha，接著 CI 自動 deploy 到 QA server，QA 開始測試
測試期間，工程師仍然可以繼續對 develop 送 feature 相關的 code，流程同開發期
測試期間，如果 QA 測出問題，工程師修正的 code 仍然是從 develop 分支、對 develop 送 PR，接著 release manager 會 git cherry-pick 相關 commits 到一個新的 release PR，沒問題之後，merge 並且 deploy 到 QA server 讓 QA 驗證
Day 15，GitHub 會自動開一個 merge alpha to master 的 release PR，如果 QA 覺得沒問題，release manager 就會 merge 進 master，CI 自動 deploy 到 production server，完成這次 sprint 的產品交付（例如上圖的 1.1.0 和 1.2.0）
如果是緊急的問題，需要馬上修復（Hotfix），無論是開發期或是測試期，工程師一樣還是從 develop 分支、對 develop 送 PR，merge 之後，release manager 一樣走上面流程 release 到 QA server 給 QA 驗證，沒問題之後再開一個 merge 到 master 的 release PR，git cherry-pick 相關 commits，merge 之後 deploy 到 production server，完成緊急修復（例如上圖的 1.1.1）

問題 1：Conflicts

在 Day 10 和 Day 15 這兩天，GitHub 開出的 release PR 常常會遇到 conflicts，而且這些 conflicts 通常因為時間久遠、commits 量大，導致 release manager 很難解 conflicts，容易發生解錯的風險。

問題 2：Out of date

為了確保 codebase 一致，我們的 GitHub alpha 和 master branch 有打開 [Require branches to be up to date before merging](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches) 的檢查。但是在測試期間，因為大家會頻繁的對 alpha 送修正的 PR，導致 PR 很容易出現 out-of-date 的情況，必須 git rebase or git merge 之後，再重頭跑一遍 CI。

問題 3：Hotfix

如果是 Hotfix 流程，一共需要開 3 次 PR（對象是 develop、alpha 和 master）、跑 3 遍 CI、等 3 次 PR approve，但是它們的 change list 其實是一樣的。

為了解決這三個問題，我參考了許多 TBD 相關文章，嘗試重新設計我們的 Git workflow。

什麼是 TBD？

TBD 是 Trunk Based Development 的縮寫。是一種 Git 管理模型 or 策略，Google 和 Facebook 都有在使用。

Trunk Based Development

（中文 https://tw.trunkbaseddevelopment.com/）

其它類似的模型還有：Git flow、GitHub flow 以及 GitLab flow。

改動的部分

下圖是參考 TBD 調整之後的 workflow：

將原先的三支 branches（develop、alpha 和 master）縮減成一支 trunk branch（master）
無論是開發期、測試期或是 Hotfix，工程師只能從 master 分支、對 master 送 PR（這部分跟原本的差不多，只是從 develop 變成 master）
取消 Day 10 和 Day 15 自動開 release PR 的機制，改成 Day 10 自動從 master 開一支 release branch（branch 的 prefix name 需為 release/）
Release branch 會觸發 CI 執行如下圖的 jobs：

CircleCI 示意圖

我們將原本 CI 的 release alpha 和 release prod 兩個 workflow 合二為一，release branch 會直接 deploy QA server，但是因為後面接著 approve-deploy-prod（CircleCI 提供的 approval 功能），所以不會馬上 deploy 到 production server
測試期間的修正 commits 會由 release manager git cherry-pick 到 release branch，然後一樣觸發上述 CI，deploy 到 QA server
Day 15 如果 QA 沒問題，release manager 直接點擊 CI 的 approve-deploy-prod，deploy 到 production server（例如圖中的 1.1.0 和 1.2.0）
如果要 hotfix，改成直接從 latest tag（例如 1.1.0）開 release branch，之後的流程同上（例如圖中的 1.1.1）

好處 1

因為已經沒有 develop 和 alpha 需要維護了，所以就不會為了 sync branch 而產生不必要的 conflicts 了，可以省下大家解 conflicts 的時間。

好處 2

因為已經改用 release branch 取代 release PR，所以也不會有 PR out of date 的問題了，除了省下時間、也省下重跑 CI 的成本。

好處 3

Hotfix 流程變成只需要開 1 次 PR（原本 3 次）、跑 2 遍 CI（原本 3 遍）、等 1 次 PR approve（原本 3 次），省時＋省力＋省錢。

結語

當然，新的流程勢必也存在新的問題，例如可能需要更仰賴 Feature flags 的機制等，但是經過與團隊的交流討論，我覺得大部分疑慮都是可以解決的，如果這個 flow 總體帶來的效益大過這些疑慮的話，我認為還是有一試的價值。

參考資料

為什麼會有拖延症？

Mon, 25 Jul 2022 00:00:00 GMT

人類的自然規律：不是做多少事、就需要多少資源。而是有多少資源、人類就一定會把這個資源用到耗盡為止。

前言

最近團隊交付產品的時間，常常有不如預期的情況發生。

通常想解決這個問題，可能會想到以下幾種方式：

增加人力
增加時間
其它（例如：改善流程、自我成長、加班）

第一種「增加人力」在《人月神話》一書中，已經告訴我們為什麼沒有用了。

https://x.com/JustSomeDev/status/1546827210618814464?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1546827210618814464%7Ctwgr%5Ea732597fff51ab464a98bc7701e5f38315c02e08%7Ctwcon%5Es1_c10&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2FJustSomeDev%2Fstatus%2F15468272106188144643Fref_src3Dtwsrc255Etfw257Ctwcamp255Etweetembed257Ctwterm255E1546827210618814464257Ctwgr255E564e91ab5b1b194c891619dddd9112d15ed0fab5257Ctwcon255Es1_c1026ref_url3Dhttps253A252F252Fblog.amowu.com252Fprocrastiatio-and-parkinsons-law252Fimage%3D

第二種「增加時間」，我們曾經嘗試過把 Scrum 的 Sprint 週期從兩個禮拜增加到三個禮拜，但是結果看起來並不理想。

這篇文章我想要探討，為什麼我覺得第二種「增加時間」的方法也是沒有用的。

為什麼會有拖延症？

最近在《罗辑思维》聽到一期《為什麼會有拖延症？》令我印象深刻，摘錄分享出來。

為什麼會有拖延症？其實不是因為我們自我管理不嚴格，而是因為只要時間資源在那裡，你就會傾向於把它用盡。

1955 年，英國政治學家帕金森，提出了一個「帕金森定理」：一個組織，總是會趨向於層級越來越多，規模越來越膨脹，人越來越忙，但組織效率越來越低下。

為什麼會變這樣呢？是因為組織腐敗嗎？不是，員工自己也覺得工作很辛苦、每天忙得要死。那是為什麼呢？

因為人類組織的自然規律：不是做多少事、就需要多少資源。而是有多少資源、組織就一定會膨脹到那個程度，直到把這個資源耗盡為止。

至於事情有沒有多做、做得好不好，反倒不是那麼重要了。反過來，把資源砍掉，也未必會影響做事的成效。

Parkinson’s law

這個過程中，不僅資源會被用上，而且還會衍生出新的事務，迫使組織又進一步渴望新的資源，進入惡性循環。

舉個例子，一間公司原本很小，只有兩個人，分工清楚。

這個時候，公司招聘了一批新人，那麼有些工作就可以交給他們了，但是原本的兩人有變輕鬆了嗎？並沒有，因為多了一個人，至少多出來了好幾件事：

工作的分配問題：要想清楚哪些工作可以交出去、什麼時候交、交到什麼程度？
人際關係問題：要考慮大家的心情和可能發生的矛盾，工作量和工作成果的分配要儘可能公平合理
品質問題：新人做事不放心，要去 review 他們的工作成果，有需要改善的地方，可能得查缺補漏甚至推倒重來
組織發展問題：公司要對他們負責，所以要花時間、找資源去培訓他們、提升他們
評價標準問題：人多了，就牽涉到排名問題，為了給將來的升職加薪留個依據，公司就要制定 KPI 之類的玩意兒

這裡面的每一件事你都不能說沒必要，但是每一件事都只是因為多了這麼個人、這麼個資源，因事生事，已經和最初的工作目標沒什麼關係了。

回到拖延症這個話題。這個規律也適用於「時間」這種資源：並不是因為需要多少用多少，而是有多少你就會用光多少。

你可能會懷疑，做一件事需要的時間不是有限的嗎？從鎖一顆螺絲到造一台汽車，不僅需要的時間是有限的，而且還可以持續優化，怎麼會需要無限的時間資源呢？

這是因為人類工作要處理的對象，從「物品」變成了「事情」。

以前，無論是農業時代還是工業時代，我們的工作對象主要是物品：種一畝地的田、流水線上加工一個零件。因為物品的邊界是清晰的，所以需要的工作時間就是有限的。我們努力的方向，就是通過各種工具和創新，節省時間資源，獲得更高的效率。

但是現在我們的工作對象越來越像是「事情」。比如寫一篇企劃搞、做藝術創作、開發一個程式功能、準備一場行銷活動。只要是「事情」，背後包含的複雜度就太高了。而且只要是一件「事情」，就可以膨脹成任何規模的工作。

只要有時間，你就可以無窮無盡地圍繞著這個決定做準備，沒有一件事是毫無必要的，也沒有一件事是確定有必要的。

Human Evolution

這也可以解釋 996 工作制這件事。不是因為 IT 公司都是慣老闆，也不是因為 IT 公司的工作量就比別人多，而是因為 IT 公司面對的工作對象，不是清晰的「物品」，而是一件件說不清、道不明的「事情」，它的工作對時間資源的索取就是無止境的。所以 996 本質上不是說需要這麼多時間，而是現在一個 IT 從業人員能榨取的工作時間的極限就這麼多了，那些搞 996 工作制的公司，只是把它用盡了而已。

結語

如果「加人」與「加時間」都無法解決產品交付 delay 問題的話，可能就要從「其它」方式下手了。

撇開「自我成長」和「加班」這類不可控因素，我認為團隊應該要分配資源在「改善流程」上面。

比如我接下來預計要寫的幾篇文章：《Trunk Based Development 》、《Single Text of Truth 》以及《Design to Code》。這些都是跟交付功能無關的工作，卻是可以改善團隊交付速度的解決方案。

否則如果只是把「瀑布」換成「敏捷」的話，本質上還是在第二種資源「時間」上打轉而已，最終可能還是得應付處理不完的「隕石」。

https://x.com/AlmorTech/status/1541753810984615937?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1541753810984615937%7Ctwgr%5E50afa6fb15242354407e155310e15b5950d1480a%7Ctwcon%5Es1_c10&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Falmormd%2Fstatus%2F15417538109846159373Fref_src3Dtwsrc255Etfw257Ctwcamp255Etweetembed257Ctwterm255E1541753810984615937257Ctwgr255E564e91ab5b1b194c891619dddd9112d15ed0fab5257Ctwcon255Es1_c1026ref_url3Dhttps253A252F252Fblog.amowu.com252Fprocrastiatio-and-parkinsons-law252Fimage%3D

Hahow for Business 如何跑 E2E 測試？

Wed, 29 Jun 2022 00:00:00 GMT

隨著 Chrome headless 模式的推出，E2E 測試上 CI 已經變得容易。這篇文章分享什麼是 Cypress，為什麼我覺得寫 E2E 測試很重要，以及我們團隊是怎麼跑這個流程的。

這篇文章會介紹 Ruby on Rails 如何配置 CircleCI 運行 Cypress 的 E2E 測試。

什麼是 Cypress？

Cypress 是一款自動化 E2E 測試（Automated End-to-End Testing）工具，編寫方式以 JavaScript 語言為主。

Testing Frameworks for Javascript | Write, Run, Debug | Cypress

E2E 這類測試方法，是從終端使用者的角度出發，模擬真實世界的操作場景，用於確保網站的行為符合預期。

類似的工具還有 Selenium、Nightwatch、Puppeteer 以及 Playwright。

除了測試之外，這些工具一般也可以用來寫網頁爬蟲（Web Scraper）腳本。

E2E 測試 vs 單元測試

可能有人會問，為什麼不寫單元測試（Unit tests）就好？

因為兩者適用的場景不同。

很多東西是單元測試寫得再好也測不出來的。

2 unit tests. 0 integration tests

舉個 Hahow for Business 的例子，最近前端加入了 Code-Splitting 的機制，結果某天 Sales 在向客戶 demo 產品的時候，發現後台有點選特定頁面會造成網站 crash 的問題。（關於 Rails 怎麼做 code-splitting 我之後會專門寫一篇文章跟大家講解）

不好意思，有些地方出錯了！

如上圖操作所示，像這種問題就是單元測試無法重現的。無法重現的話，就沒辦法寫測試來避免再度發生。

以 B2B 這種對網站穩定性要求相對高的產品來說，合約上通常會規定網站的 HA 必須維持在一個數字。

https://x.com/amo_wu/status/1108358207401914368?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1108358207401914368%7Ctwgr%5E49d09029bfed0045ab0da4d03205de6d64b7a8e1%7Ctwcon%5Es1_c10&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Famo_wu%2Fstatus%2F11083582074019143683Fref_src3Dtwsrc255Etfw257Ctwcamp255Etweetembed257Ctwterm255E1108358207401914368257Ctwgr255Efec710994c10cedfec9c6e132faaa72dd563edd7257Ctwcon255Es1_c1026ref_url3Dhttps253A252F252Fblog.amowu.com252Fcypress-on-rails252Fimage%3D

如果工程師不想下次因為一樣的問題而被 on-call 的話，或許可以考慮加入 E2E 測試。

其中最保險的方式是把 E2E 測試加進團隊的 CI/CD 流程之中。

自從 Headless Chrome 模式（可以把它想像成在 CLI 模擬一個 browser 環境）出現後，Cypress 這類 E2E 測試上 CI 已經變得很容易許多。

但也不是所有的技術棧（Tech stack）說想要導入這個流程就能導入的。

要在 CI 整合 E2E 測試，有一個重要的先決條件是：前後端合一的 monorepo。

近年來流行「前後端分離」的 SPA 架構，無論是 CSR 或 SSR，這種架構下都容易出現將原始碼分開管理的 Multi-repo（又稱 Polyrepo）形式。

Multi-repo 的劣勢在於很難自動化 E2E 這類整合測試（Integration Tests），因為不管是修改前端或是後端的 code，都有可能造成 E2E 測試失敗，如果這時候 CI 還需要整合兩邊的 repo 環境，想必在技術上會是一個困難的挑戰。

Hahow for Business 使用的框架是 Ruby on Rails，RoR 本身是 monolithic 架構，前後端在同一個 codebase 底下，加上其完善的生態（例如資料庫的 Migrations 和 Seed Data，這些機制很重要），讓 Cypress 在搭配 Ruby on Rails 的過程中，沒有遇到太大的問題。

接下來，就來介紹怎麼在 Ruby on Rails 環境下跑 Cypress。

Getting started

Cypress 的安裝和語法就不贅述了，詳見官方文件。

我們直接以剛才提到的「後台 crash」案例為例，撰寫 Cypress 測試，寫起來大概這種感覺：

describe('訪問管理後台特定頁面', () => {
  before(() => {
    // 這是自訂的 Cypress Custom Command，用於快速登入某個帳號，這裡就不細述實作
    cy.fastSignIn('admin@hahow.in', 'password');

    // 跑測試之前，先打開後台網址
    cy.visit('http://localhost:3000/admin');
  });

  describe('從側欄連結先訪問「課程管理」再訪問「成效追蹤」', () => {
    it('點擊左側的「課程管理」選項，右側標題應該顯示「課程管理」', () => {
      // 可以給要操作的 element 加上 data-test-id attribute，這樣 selector 會比較好寫
      cy.get('li[data-test-id="課程管理"]').click();

      cy.get('[data-test-id="control-panel"] h3').contains('課程管理');
    });

    it('點擊左側的「成效追蹤」，右側標題應該顯示「成效追蹤」', () => {
      cy.get('li[data-test-id="成效追蹤"]').click();

      cy.get('[data-test-id="control-panel"] h3').contains('成效追蹤');
    });
  });
});

先在 local 跑一遍試試，指令是 yarn cypress open，記得要先把 development 的環境開起來，以 Hahow for Business 為例，大致如下：

$ bin/webpack-dev-server # 前端 local 開發環境
$ bin/rails server # Rails Server
$ bundle exec sidekiq # Sidekiq 環境，非必要
$ yarn cypress open

接著點擊要執行的檔案，Cypress 就會開啟一個 Chrome，開始跑自動化測試：

如上圖，沒意外的話，就會看到 AssertionError，表示成功重現 crash 的問題，接著就可以開始 TDD 找原因了。

解決 Cookies 問題

E2E 測試通常不會只有一個檔案要跑，如果不同的測試之間所使用的帳號不一樣，就有可能會碰到 Cookies 相關的問題（例如 InvalidAuthenticityToken 錯誤），解決方法如下：

describe('...', () => {
  before(() => {
    // 清除此前測試的登入狀態
    cy.clearCookies();

    // 登入此次的測試帳號
    // ...
  });

  beforeEach(() => {
    // 在接下來的每一個 test case 之間，保留 cookies 狀態，
    // 避免 InvalidAuthenticityToken 錯誤。
    Cypress.Cookies.preserveOnce('YOUR_COOKIE_NAME');
  });

  // ...
});

更多細節可以參考 Cypress 有關 Cookies 的章節。

完整的程式碼大致如下：

describe('訪問管理後台特定頁面', () => {
  before(() => {
    cy.clearCookies();

    cy.fastSignIn('admin@hahow.in', 'password');

    cy.visit('http://localhost:3000/admin');
  });

  beforeEach(() => {
    Cypress.Cookies.preserveOnce('_hahow_for_business_session');
  });

  describe('從側欄連結先訪問「課程管理」再訪問「成效追蹤」', () => {
    it('點擊左側的「課程管理」選項，右側標題應該顯示「課程管理」', () => {
      cy.get('li[data-test-id="課程管理"]').click();

      cy.get('[data-test-id="control-panel"] h3').contains('課程管理');
    });

    it('點擊左側的「成效追蹤」，右側標題應該顯示「成效追蹤」', () => {
      cy.get('li[data-test-id="成效追蹤"]').click();

      cy.get('[data-test-id="control-panel"] h3').contains('成效追蹤');
    });
  });
});

上面這段程式碼，其實還可以寫得更漂亮些，例如看似重複的兩個 it 可以透過 cypress-cucumber-preprocessor 寫成容易共用的 BDD 模組。另外因為受限於 CSS selector 語法，常常每個測試都要侵入原始碼去加 data-test-id，感覺不太好，這部分可以改用 cypress-xpath 解決。

關於 cypress-xpath 和 cypress-cucumber-preprocessor 我之後會專門寫一篇文章跟大家講解。

修復問題

追了一會兒的原因之後，發現罪魁禍首是我們把 webpack 的 minimizer 換成 ESBuildMinifyPlugin 的緣故。修復之後，如下圖所示，再跑一遍 E2E 測試，確認全部通過之後就沒問題了：

（關於「如何透過 esbuild-loader 加速 webpack compile」我之後會專門寫一篇文章跟大家講解）

Continuous integration

接下來，為了避免問題再度發生，我們希望將 E2E 測試整合進團隊的 CI 流程，並且每個 Pull Request 都會觸發。如果測試不通過，PR 將無法被 merge，可以有效地將問題的範圍縮小在源頭。

以我們團隊在用的 CircleCI 為例，配置大致如下：

version: 2.1

jobs:
  e2e-test:
    docker:
      - image: cimg/ruby:2.7.4-browsers
      - image: cimg/postgres:12.7
      - image: redis:4-alpine # 非必須，有跑 Sidekiq 才需要
    steps:
      - checkout
      # 安裝 Gem 和 npm 的套件
      - run: bundle install
      - run: yarn --frozen-lockfile
      # 這裡省略了 Gemfile.lock 和 yarn.lock 的 restore_cache 和 save_cache
      - run: bin/rails db:setup
      - run: bin/rails dev:prime # or bin/rails db:seed
      - run:
          name: Ruby on Rails server
          command: bin/rails server
          background: true
      # 非必須，有跑 Sidekiq 才需要
      - run:
          name: Sidekiq worker
          command: bundle exec sidekiq
          background: true
      - run:
          name: Ping 網頁，避免 Cypress 因為等待 webpack compile 而 timeout
          command: npx wait-on http-get://localhost:3000
      - run: yarn cypress run

workflows:
  test:
    jobs:
      - e2e-test

（其它 CI Provider 的設定應該也大同小異，詳細可以參考 Cypress 提供的範例）

其中 rails db:setup 和 rails dev:prime 可以確保每次 CI 都是一個初始狀態的環境。cypress run 與 cypress open 不同，前者會以 Chrome headless 模式運行測試。

丟到 CircleCI 之後，如果 E2E 測試不通過，就會顯示如下圖的相關資訊：

GitHub

最後，記得將 GitHub 的 Require status checks to pass before merging 給打開，然後加入 ci/circleci: e2e-test，如下圖所示：

設定好之後，如果 E2E 測試沒通過，PR 就無法被 merge。

為了方便 developer 查找測試沒通過的原因，可以利用 CircleCI 提供的 store_artifacts 機制，將 Cypress 產生的截圖和錄影暫存起來，只需要加四行：

- run: yarn cypress run
- store_artifacts:
    path: cypress/videos
- store_artifacts:
    path: cypress/screenshots

如下圖，這樣就可以在 CircleCI 的 Artifacts 底下看到 e2e-test failed 的相關截圖以及錄影的連結：

FAQ

CircleCI 如何安裝 Chrome？

如果 CircleCI 遇到找不到 Chrome 的問題，可以安裝官方提供的套件 circleci/browser-tools：

version: 2.1

orbs:
  browser-tools: circleci/browser-tools@1.2.4

jobs:
  e2e-test:
    # ...省略
    steps:
      - browser-tools/install-chrome
      - browser-tools/install-chromedriver
      - checkout
      # ...省略

（參考自 https://circleci.com/developer/orbs/orb/circleci/browser-tools#usage-install_chrome）

CircleCI 如何顯示中文字型？

如果你的 E2E 測試對象是中文網站，可能會遇到 CircleCI 的截圖和錄影無法顯示中文字的問題，解決方法如下：

version: 2.1

jobs:
  e2e-test:
    # ...省略
    steps:
      - run:
          name: Cypress 截圖、影片支援顯示中文
          command: |
            sudo apt-get -qqy update
            sudo apt-get -qqy --no-install-recommends install fonts-wqy-zenhei
            sudo rm -rf /var/lib/apt/lists/*
            sudo apt-get -qyy clean

（參考自 https://github.com/cypress-io/cypress-docker-images/issues/109#issuecomment-590183007）

結語

導入 E2E 測試流程之後，團隊可能會遇到以下問題：

錢
時間
人力

一開始 E2E 測試還很少的時候，可能不會有什麼問題；但是隨著測試案例增加，CI 運行的時間勢必也會增長，需要付出的金錢成本也會提高。

其中最容易造成浪費的部分，就是每個 Pull Request 都會觸發 E2E 測試這個環節。通常來說，developer 不會開了 PR 之後就完事了，後續還會 push commits 到 PR，這就造成每次 push 也都會觸發 E2E 測試的問題。

一個比較快的解決方式，是在 e2e-test job 之前，加入 manual approval 的機制，讓 developer 自己決定跑 E2E 測試的時機點。

其次是時間成本問題，E2E 測試很容易發生隨機錯誤（Flaky Tests），如果沒有做 Parallelization，常常會因為一個 flaky test 造成整個 E2E 測試 failed，需要再重跑一遍，導致 DX（Developer experience）變得極差。

這部分我們是將流程遷移至 Cypress Dashboard 服務之後才有所改善。關於 Cypress Dashboard 我之後會專門寫一篇文章跟大家講解。

Cypress Cloud | Elevated Test Automation In Your CI

最後是人力問題，就跟「寫註解」還有「寫文件」一樣，developer 也不喜歡「寫測試」，這裡我的建議是：

轉念，如果這個功能出問題，第一時間是 on-call 你修的話，就寫測試來防禦吧
先寫業務核心的重要功能（例如：支付流程）
交給專業的來，如果團隊有 QA 或 QE 的角色，通常會做回歸測試（Regression Tests），這部分如果能跟團隊的 E2E 測試流程整合在一起的話，想必能事倍功半

當公司從小團隊發展成大團隊之後，一些流程就變得必要。還是小團隊的時候，一些事情直接做無仿，但當規模變大了，就需要有規範的流程。當然，有了流程就可能出現繁雜的障礙。但是一家公司不能永遠處於初創期，它總要進入成熟期。

這些規範，有時不是為了最好的結果，而是為了防止最壞的結果。一些人不習慣這些規範流程，會講這是內卷（involution），其實這些看似繁雜的過程，可以避免很多災難性的結果。當你只有 100 元的家產時，不會太擔心把事情搞砸了損失家產，而當你有 100 萬的時候，做事的方式就完全不同了。

— — 吳軍《硅谷來信》

參考文章

Hahow for Business 如何保護串流內容？

Fri, 04 Sep 2020 00:00:00 GMT

近來因疫情關係，不少 OTT 與線上教育等影音串流平台的流量急劇上升，本篇文章以 Hahow 為例，帶你了解隨選視訊背後的原理以及如何保護數位內容。

這篇文章會介紹 Hahow for Business 是如何透過 AWS CloudFront 的 Signed Cookies 機制來保護 HLS 格式的串流影片。

大綱

前言
什麼是 VOD？
什麼是 HLS？
如何保護串流內容？
什麼是 Signed URLs／Cookies？
結論

前言

六月初，Hahow for Business 上線了一個新功能：影片播放器開始提供不同解析度來源的切換選項。

其中「自動」的選項，可以根據使用者當前的網速，自動切換適配的解析度。

恰巧，Hahow for Business 自去年六月正式啟動以來，也剛好滿一年。

最初，為了能夠儘快投入市場試水溫，產品開發時程相對吃緊，很多東西都是先求有再求好，所以勢必會留下一些技術債，例如 VOD 就是其中之一。

延伸閱讀：

為何選擇成為一個 Product Owner？

什麼是 VOD？

在 Media Streaming（媒體串流）的世界裡，有兩種不同的實作類型：

On-Demand Streaming（隨需串流、隨選、點播）
Live Streaming（即時串流、直播）

引述自 AWS 官方的說明：

使用隨需串流時，影片內容會存放在 Amazon S3 中。觀眾可以選擇在任何時候觀看影片，因此稱為「隨需」串流。

在即時串流的情況下，您的內容可能是即時活動或全年無休即時頻道交付。前者的例子包括串流體育賽事、頒獎典禮、重大發表和其他高收視率即時活動的廣播公司和內容整合公司。後者的例子包括希望可在不使用第三方分發平台的情況下，封裝線性即時頻道並透過網際網路直接交付給觀眾的工作室、廣播公司和付費電視服務營運商。

由於 Hahow for Business 的串流媒介是影片（Video），串流類型是 On-Demand Streaming，故稱作 Video on Demand（簡稱 VOD）。

這也是各大 OTT 平台（例如：Netflix、KKTV、愛奇藝等）主要的串流類型。

其它像 Twitch、17 之類的直播平台，就屬於第二種類型。當然，也有兩種類型都提供的平台，例如 YouTube。

Hahow for Business 的 VOD infrastructure 建置在 AWS 上，架構大致如下：

圖中虛線內容是本文介紹重點

先快速帶過幾個關鍵服務：

將影片原始檔上傳至 S3 Bucket
透過 Elastic Transcoder 轉檔成指定格式
轉完的影片檔輸出至 S3 Bucket
將輸出的影片部署至 CloudFront（CDN）
客戶端隨需播放影片

這篇文章不會著墨於怎麼架設 AWS 的 VOD，網路上有許多教學文章，也可以查看官方文件。

最一開始，我們只有在 Elastic Transcoder 上輸出 1080p MP4 格式的影片。

這會導致兩個問題：「貴」與「慢」。

對內，串流的檔案越大，需要付出的流量費用就越高。對於口袋不夠深的新創來說，這可能因為商業成本的考量而影響未來的工程決策。

對外，1080p 大小的 MP4 如果在網路環境較差的情況下，影片容易卡在讀取的環節，嚴重影響使用者體驗。

基於上述原因，我們決定將串流的格式從 MP4 換成目前主流的 HLS。

什麼是 HLS？

在提到 HLS 之前，先解釋一下什麼是 ABS（自適性串流）：

此技術根據即時檢測用戶的頻寬和 CPU 使用率，調整影片流的品質。

這需要使用一種可以將單一影片源輸出為多位元速率的編碼器。播放器客戶端依賴可用資源在不同位元速率的流之間切換。結果就是：更少快取、更快的開始播放、為低階和高階連結都提供良好的體驗。 — — 《自適性串流 — 維基百科》

然後回來看 HLS 的介紹：

HTTP Live Streaming（縮寫是 HLS）是由蘋果公司提出基於 HTTP 的流媒體網絡傳輸協議。

它的工作原理是把整個流分成一個個小的基於 HTTP 的文件來下載，每次只下載一些。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的數據速率。在開始一個流媒體會話時，客戶端會下載一個包含元數據的擴充 M3U（m3u8）播放列表文件，用於尋找可用的媒體流。 — — 《HTTP Live Streaming — 維基百科》

把它畫成圖之後，感覺大致如下：

HLS 使用副檔名為 m3u8 的檔案作為索引，檔案切片格式為 TS。支援的客戶端包括 iPhone 和 Android 等裝置。至於不支援的瀏覽器，則是可以透過 hls.js 之類的 library 來實現。同時，HLS 也能夠被用在直播形式。

其它 ABS 還有諸如 Microsoft 的 Smooth Streaming、Adobe 的 HDS 以及 Google 的 MPEG-DASH。

使用 Elastic Transcoder 的好處就是，這些主流的轉檔格式，AWS 都已經幫大家建立好 Presets 供直接使用。

原本以為只要將 1080p MP4 的 Preset 修改成 HLS 的 Preset，就可以收工打卡下班了。結果，並沒有想像中這麼簡單。

在測試過程中，我們碰到了 MP4 和 HLS 在內容保護機制上，處理方式不同的問題。

如何保護串流內容？

下圖是擷取自 AWS security media delivery，有關「媒體交付安全性」的其中一張投影片：

來源 https://youtu.be/zzeho2uLpHM

裡面介紹了幾種 AWS 提供的串流內容保護方式，彼此可共存不互斥。由下至上分別是：

Watermarking
Geoblocking
DRM
AES encryption
Token / signed URLs

Watermarking（浮水印）

Elastic Transcoder 支援在影片轉檔階段，直接將指定圖片（例如公司 logo）印在影格上。壞處是可能會遮擋住教學內容（例如 Photoshop 的操作介面）。另一種比較簡單的做法是透過 HTML + CSS，直接在播放器上印出圖片，好處是可受程式控制（例如：位置、透明度等），壞處是幾乎沒有保護效果。

Geoblocking（鎖地區）

CloudFront 提供地理限制／封鎖（Geo-restriction）的功能。透過第三方的 GeoIP 資料庫來判斷使用者的國家／地區，限制資源的存取，準確性約 99.8%。這也是國外 OTT 經常實作的機制，缺點是可以透過 VPN 繞過去。

DRM

DRM 是 Digital Rights Management（數位版權管理），實作起來最複雜，但因為保護效果最好，所以也是目前大部分 OTT 的主流機制。

運作原理的部分，因為不是本文重點，就不多贅述。詳見 Elastic Transcoder 的《數位版權管理》。

需要注意的是，任何保護機制都是防君子不防小人，沒有絕對的安全，只有破解困難程度的差別。

延伸閱讀：

不是說DRM保護技術很厲害？盜版網站上那些影片，是如何從 Netflix 這類影音網站上把影片抓下來的？

AES Encryption

使用 Elastic Transcoder 搭配 AWS KMS（Key Management Service）來加密串流媒體檔案的片段，並在播放時進行解密。

延伸閱讀：

一次搞懂密碼學中的三兄弟 — Encode、Encrypt 跟 Hash

Token / Signed URLs

最後一個，也是 Hahow for Business 目前主要的實作方式 — — Signed URLs 和 Signed Cookies，接下來就重點介紹。

什麼是 Signed URLs／Cookies？

CloudFront 提供兩種方法訪問 S3 的 Private Content：

Signed URLs
Signed Cookies

第一種是 Signed URLs，它的原理是：後端（Backend）透過 CloudFront 金鑰，向 CloudFront API 請求訪問某筆資源，然後返回一組帶有 Token 參數的網址，具時效性。

以 Ruby 為例（Hahow for Business 的後端是 Ruby on Rails），假如我們想訪問 url=https://cdn.business.hahow.in/foo.mp4 的檔案，程式碼大致如下：

signer = Aws::CloudFront::UrlSigner.new(
  key_pair_id: "cf-keypair-id",
  private_key_path: "./cf_private_key.pem"
)
signed_url = signer.signed_url(url,
  expires: 1.hour.after
)

這時候得到的 signed_url 大概會長這樣：

https://cdn.business.hahow.in/foo.mp4?Expires=...&Signature=...&Key-Pair-Id=...

接著，前端就可以使用這組 Signed URL 去訪問資源了，如下圖：

一般來說，如果訪問的是單筆資源，例如這個例子中的 MP4，那麼用 Signed URLs 就可以。

但如果要訪問 HLS 這類多筆資源，Signed URLs 就會碰到問題。

如下圖所示，雖然一開始的 Master Playlist（詳見前面的 HLS 圖）還可以透過 Signed URL 訪問，但由於接下來前端會解析索引裡面的其它連結（m3u8 或 ts）然後直接送出請求，但因為不是 Signed URL，導致訪問會被 CloudFront 拒絕。

雖然期間也找到幾種解法，例如這篇「使用 Lambda 替所有連結都簽名」的奇耙技巧⋯⋯。

但最後還是決定改用 Signed Cookies。

事實上，官方文件也是這麼建議的：

在以下案例使用已簽章的 URL：

⋯（略）

在以下案例使用已簽章的 Cookie：

您想要提供對多個限制檔案的存取，例如，HLS 格式視訊的所有檔案或網站中訂閱者區域的所有檔案。

⋯（略）

— — 《在已簽章的 URL 和已簽章的 Cookie 之間進行選擇》

Signed Cookies 跟 Signed URLs 原理類似，都是後端透過 CloudFront API 取得 Token，差別在於 Signed Cookies 可以同時指定多筆資源，然後返回一組具時效性的 Cookies 儲存在客戶端上。如果接下來請求的 m3u8 或 ts 在允許範圍內，那麼只要帶上這組 Cookies 就都可以順利訪問。

同樣以 Ruby 為例，假如想訪問 url=https://cdn.business.hahow.in/{video-id}/index.m3u8，程式碼大概會長這樣：

signer = Aws::CloudFront::CookieSigner.new(
  key_pair_id: "cf-keypair-id",
  private_key_path: "./cf_private_key.pem"
)
signed_cookies = signer.signed_cookie("https://cdn.business.hahow.in",
  policy: policy.to_json
)

需要注意的是，與 signed_url() API 不同，signed_cookie() 第一個參數傳的不是資源的完整 URL，而是 Origin（https://cdn.business.hahow.in）。

取而代之的是，在參數 policy 指定相關資源的 URL（wildcard 形式）以及時效：

def policy
  {
    'Statement' => [
      {
        'Resource' => "https://cdn.business.hahow.in/{video-id}/*",
        'Condition' => {
          "DateLessThan":
            {
              'AWS:EpochTime' => 1.hour.from_now.to_i
            }
        }
      }
    ]
  }
end

這樣即便前端解析索引之後的連結是 https://cdn.business.hahow.in/{video-id}/{bitrate}.m3u8 或是 https://cdn.business.hahow.in/{video-id}/{bitrate}/{segment}.ts，只要請求帶上 sigend_cookies 都能順利訪問。

其中，由於我們使用了 Cookie 機制，如果前端要把請求帶上 Cookie 發送，記得在 AJAX 中打開 withCredentials 屬性。

const xhr = new XMLHttpRequest();

xhr.withCredentials = true;

如果前端使用的是 hls.js，則可直接透過 xhrSetup API 簡單地實現這件事。

否則，即便 CloudFront 返回且儲存 Signed Cookies，瀏覽器也不會發送。

另外，需要注意的是，如果要發送 Cookie，Server 回應 Header 的 Access-Control-Allow-Origin 就不能設為 *（可以在 S3 的 CORS 設定），必須指定明確、與請求網頁一致的 Origin。

<CORSRule>
    <AllowedOrigin>https://business.hahow.in</AllowedOrigin>
    ...
</CORSRule>

同時，Cookie 依然遵循同源政策（Same-origin Policy），只有用 Server Domain 設置的 Cookie 才會發送，其它 Domain 的 Cookie 並不會發送。

也就是說，如果我們設置 Cookie 的 domain 是 .business.hahow.in，但是訪問資源的連結是 *.cloudfront.net，那麼 Cookie 就無法被發送。所以 Hahow for Business 也趁著這次更新順便把 CloudFront 的 CNAME 掛上 cdn.business.hahow.in。

延伸閱讀：

成果

回到最初我們想要解決的兩大問題：「貴」與「慢」。

好巧不巧，就在 HLS 上線之後沒多久，我們的其中一間企業客戶，就突擊來了個動員壓測，好在事後的問卷調查取得了 89% 以上「順暢」的成績。

至於帳單的部分，相比前一個月的金額，CloudFront 的流量費用大幅下降了 68%。

整體來說，這次的改動算是達成了目標，既「開源」又「節流」，一舉數得。

結論

總結一下本文的重點：

首先，介紹了兩種串流類型，分別是 On-Demand Streaming（點播）和 Live Streaming（直播），Hahow for Business 屬於前者的 Video on Demand（隨選影片），簡稱 VOD。
VOD 的格式千百種，其中 HLS 相較傳統 MP4 的優勢在於，HLS 的檔案被切分成許多片段，不需要一次載完整部影片才開始播放。並且會根據使用者的網速，切換至適合的解析度來源，提高使用者的觀看體驗。
接著，介紹了幾種保護串流內容的方法，分別有：浮水印、鎖地區、DRM、加密，以及 Hahow for Business 在使用的 Signed URLs 和 Signed Cookies。
最後，解釋了 Signed URLs 和 Signed Cookies 的原理以及使用場景，前者適合 MP4 等單筆資源，後者則是適用於 HLS 這類多筆資源。

後記

當然，Hahow for Business 的 VOD 還有許多可以精進的地方，例如：

實作更加安全的 DRM 機制
遷移至 AWS Elemental MediaConvert 系列（取代 Elastic Transcoder）
S3 & CloudFront 的備援方案等⋯

文末，筆者想拋出一個議題與大家一起思考。

可能會有人好奇，Hahow for Business 的 VOD 為什麼不直接用 SaaS？

這其實也是技術團隊在做技術選型時，常碰到的決策問題：

Self-hosted Service vs Managed Service vs SaaS

延伸閱讀：

SaaS/Managed Services & Self-Hosted 衍伸思考

目前 Hahow（for Consumer）的 VOD 就是使用 Vimeo 這個 SaaS，雖然好用，但也存在一些問題。

舉幾個過去我們碰到的例子：

Vimeo 提供的播放器無法實現「劇院模式（視窗全螢幕）」，後來改用開源播放器 + Vimeo API 解決
影片卡頓問題長期佔據客單榜首，後來 Vimeo 將 CDN 換成 Akamai 之後才有改善
服務掛掉也無能為力，以至於必須準備另一個更貴的 SaaS 備用方案 Wistia

這讓我想起曾經在 Star Rocket Blog 看到的一段話：

隨著 SaaS 的興起，許多在產品開發及營運上所需的工具，舉凡資料庫管理、專案管理軟體、CRM 等，其實都能在網路上找到多個能直接付費使用的外部服務。但這麼做雖然能大幅省去開發新工具的時間與人力，但也同時得承受像是外部服務突然終止、費用水漲船高、服務的功能沒有隨著公司的成長與時俱進等各種風險。

曾在 Uber、Stripe 擔任資深工程師、現任冥想 app Calm 的 CTO Will Larson，在本文中分享他會如何從風險、價值與成本這三個角度去思考「自行開發 vs. 付費購買」的問題。他也表示：「作為一間科技公司，若在你的核心競爭力以外利用到這些外部服務，那通常能為公司帶來極高的價值；否則它們往往只會拖慢公司的發展。」

— — 《Build versus buy》

這也是筆者喜歡和面試者討論的議題，沒有絕對的答案，大家不妨也可以思考看看～

最後，Hahow 正在招募「資深後端工程師」，歡迎有興趣的朋友加入我們！

工程師的世界越複雜，你的世界就越簡單

Sun, 05 Jul 2020 00:00:00 GMT

藝術家、科學家、發明家還有工匠，相比工程師有什麼不同之處？

前陣子， Redis 的作者 antirez 宣佈退出維護團隊。理由大致如下：

*我寫程式是為了表達自己，我認為自己寫的東西是一件藝術品，而不僅僅是為了完成任務而寫的有用的東西。如果我寫的東西有用，那只是機緣巧合，因為我的首要目標是做出一些美的東西。****我寧願被人記住是一個糟糕的藝術家，也不要是一個好的工程師。***Redis 現在需要的，較多的是專案維護，而不是表達自己。這並不是我想做的。

這讓我想起曾經讀過的《 Hackers & Painters 》（譯：駭客與畫家）一書提到：

應該把駭客和畫家當作同一種人看待，他們都是創作者。

駭客（hacker）追求的三個特色：好玩、高智商和探索精神，而不是實用性和金錢。

（註：這裡的 hacker 是指那些最優秀的軟體工程師，惡意入侵電腦系統的人應該被稱為 cracker）

重點筆記《Hackers and Painters》

這看起來很美好，我也嚮往這樣的「Hacker 精神」。但隨著工作的時間久了，我開始覺得工程師與藝術家還是有本質上的不同。

最近聽了《 Engineering: A Beginner’s Guide》這本書的得到解讀版本，裡面提到了一些角色和工程師的比較，覺得有趣，就摘錄出來。

什麼是工程（Engineering）？

工程學有很多個分支，例如：土木工程、機械工程、電機工程、材料工程、生物工程以及電腦工程等等。英國土木工程師協會最早將工程學定義為「為了人類的使用和便利而引導自然中巨大能源的技術」。

套用在我們這行的話，軟體工程師掌握的是「透過光電這些自然能源，提供人類能夠便利操作資訊的技術（Information Technology）」。

那麼，科學家、發明家還有工匠，這些角色和工程師比較，有什麼不同之處呢？

工程師和科學家有什麼不同？

我們常常把「理工科」放在一起說，理科和工科，其實就是自然科學和工程學。 科學家更擅長發現，工程師更擅長實現。 科學家主要的工作，是探索「是什麼」，而工程師思考的是「能夠做什麼」。科學家們發現未知之事，工程師們創造未有之物。這兩者缺一不可。

不少 IT 公司都設有科學家，例如 AWS 的 CTO Werner Vogels 過去就擔任過相關職位

工程師和發明家有什麼不同？

發明家關注的是發明（這不是廢話？），工程師關注的是創新。發明是「第一次出現新產品或新工藝的想法」，創新是「在實踐中第一次嘗試這種想法」。 發明家是那個提出可能性的人，工程師是那群真正動手，把可能性轉化為現實的人。

現代已經沒有像愛迪生之類的發明家，能讓我聯想到形象最接近的大概就是 Elon Musk

工程師和工匠有什麼不同？

最早一批工程師，都是從工匠變化而來的。工匠是把普通人培養成手藝人，來完成複雜精細的工作，而工程師思考的，是怎麼讓普通人不用學習手藝，也能完成複雜的工作。需要多年經驗才能完成的工作，那是手藝。而建立一套標準化的流程，讓門外漢也能完成，那就是工藝。 工匠傳承手藝，工程師把手藝變成工藝。

大家喜愛日本製造、德國製造或是瑞士製造的精品，這背後都是工匠精神的體現，我也曾借此在《殺雞用牛刀》一文聊過 Google 和 Facebook 兩家截然不同的工程文化。

殺雞用牛刀

綜上所述，工程師的不同之處在於：

工程師信仰科學，但是更關注怎樣借助科學創造一個可能的世界；他們總是在創新，但是更關注怎樣創新才能讓想法落地；他們重視手藝，但是更關注怎麼把手藝變成標準化的工藝。

工程師所有工作的最終目標： 把全部的複雜都封裝起來，只交給你一個簡單的界面。

回到開頭的話題，我認為工程師與藝術家的最大不同處就在於，工程的複雜度遠高於一件藝術品，因為這種複雜，反而讓工程學的世界，很難講出動人的故事。我們都期待能出現一位像藝術家一樣的英雄來創造奇跡。可是在真實的世界裡，那些好用的產品背後，往往都有一支工程師團隊在默默努力。

你會看到一群工程師在開發同一個產品，但你不會看到一群畫家在畫同一幅畫。

一個人走得快，一群人走得遠。

Hahow 為什麼沒有 iOS App？

Wed, 18 Mar 2020 00:00:00 GMT

大綱

前言
Hahow 為什麼沒有 iOS App？
為什麼有了「App 內購買」還是被拒絕？
為什麼 Hahow 要使用「消耗型項目」IAP？
為什麼 Udemy 可以使用「消耗型項目」IAP？
Hahow iOS App 接下來的計畫？
結語

2022/07/20 更新：Hahow 已經有自己的 iOS App 囉 🎊

Hahow 好學校 - 一站式跨域人才學習入口

前言

最近看到一篇 The Verge 報導，Apple 的律師要求 App Store 的前任經理停止發行《App Store Confidential》這本書，因為此書透露了「重大的商業機密」，違反了員工與公司簽訂的合約。

但是此書的作者 Sadowski 表示，這本書的很多內容其實是大家都知道的，例如：應用程式必須將使用者轉化為付費客戶。

眾所周知，Apple 的 App Store 平台審核機制封閉，很多東西是他們說的算。

作為一位曾經參與 Hahow App 的開發人員，看到這一篇報導感觸很深，滿肚子苦水不吐不快。

許多 Hahow 的使用者常常詢問，為什麼 Android 的 App 已經上架這麼久了，iOS App 卻還看不見影呢？

Hahow 為什麼沒有 iOS App？

其實 iOS App 一直都是與 Android App 同步開發的。

最早可以回朔到 2017 年 10 月，當初 Web 使用者不斷反應，希望可以在手機上，下載 Hahow 的課程，方便通勤時間也能離線觀看。

於是我自己利用公司讀書會的機會，嘗試使用 React Native 開發了一個 Hahow App 的原型（Prototype），簡單演示了「下載離線觀看」和「通知」兩個手機上才能做到的功能。

也因此，成功說服了幾位頭頭，於 2018 年 2 月正式投入開發 Hahow App。

並於同年 6 月，順利在 Google Play 上架 Android App。

有關於我們如何用 Expo 這個 React Native SDK 開發 App、踩過哪些坑，以及專案的 Scrum 怎麼跑之類的，會再另外找時間分享一篇《Hahow 如何開發 Android App》文章，這裡就先不多贅述。

就在第一版 Android App 上架 Google Play 的同時，我們也將 iOS App 送審了 App Store。

但是，由於第一版的 Hahow App 功能還很陽春，只提供了登入、下載已購課程和離線觀看，以至於 Apple 以「付費內容需要在 App 內提供付費管道」的理由拒絕我們上架。

隨著每次發布一個 Android 新版本，送審 App Store 的期間，Apple 都會以各種理由拒絕你，例如：需要提供完整的註冊登入系統、首頁、瀏覽以及搜尋課程的頁面，還有必須訪客在不註冊登入的前提下，提供試用帳號之類的。

這導致我們的 Roadmap 一直因為 Apple 的要求而不斷修正，必須放棄開發很多原本只有在手機 App 才能提供的功能體驗，例如：聽課和通知。

經過幾個月的折騰之後，我們終於完成了 Apple 所要求的最後一項功能 ── App 內購買（In-App Purchase，以下簡稱 IAP）。

歡欣鼓舞之際，本以為這次終於可以在 App Store 上看見 Hahow App 成功上架的畫面。然而，最後 Apple 還是拒絕了我們的送審。

為什麼有了「App 內購買」還是被拒絕？

簡而言之，Apple 以 Hahow App 的 IAP 商品不適用「消耗型項目」為理由，拒絕了我們。

什麼是「消耗型項目」IAP？

基本上，Apple IAP 提供四種方式在 iOS App 內付費：消耗型、非消耗型、自動續期訂閱，以及非續期訂閱，後面兩種屬於訂閱制的範圍，這裡不討論，我們來看前兩種的說明：

消耗型項目（Consumable）

使用者可以購買各種消耗型項目（例如遊戲中的生命或寶石）以繼續 app 內的進行。消耗型項目只可使用一次，使用之後即失效，必須再次購買。

需要注意的是，這類型的 IAP，可以重複購買，但無法提供「恢復購買」的選項。

非消耗型項目（Non-Consumable）

使用者可購買非消耗型項目以提升 app 內的功能。非消耗型項目只需購買一次，不會過期（例如修圖 app 中的其它濾鏡）。

與消耗型 IAP 相反，非消耗型項目只能購買一次，並且可以「恢復購買」，因為購買的資料是儲存在 Apple 的資料庫。

為什麼 Hahow 要使用「消耗型項目」IAP？

假設 Hahow 有兩堂 100 元的課程 A 和 B，如果它們共用同一組 100 元的「非消耗型項目」IAP，那麼當使用者買了 A，那麼他就無法再購買 B，因為「非消耗型」IAP「只能購買一次」。

除非分別為 A 和 B 都各自建立一組 100 元的非消耗型 IAP，但是 Hahow 有 300 堂以上的線上課程，如果每堂課程都需要建立一組「非消耗型」IAP，那麼投入的人力成本會上升（Apple 沒有提供 API 自動化，建立 IAP 需要手動在後台操作）。

於是我們參考了同是線上教育平台 ── Udemy 的 iOS App 作法，選擇「可以重複購買」的「消耗型項目」IAP。

但是 Apple 認為我們的「課程」不適用「消耗型項目」IAP，因為「課程」應該要「可以恢復購買」。

為什麼 Udemy 可以使用「消耗型項目」IAP？

當初就是因為 Udemy 使用這個方式操作，所以我們才認為可行。但是 Apple 的審核人員卻以「因為 Udemy 的課程超過 1000 堂以上，所以特例為他們開放」這個令人傻眼的理由，回絕了我們的申訴。

我並沒有在 App Store 審核指南上看見有這條規則，所以這就是為什麼我在文章開頭提到的「App Store 平台審核機制封閉，很多東西他們說的算」。

Hahow iOS App 接下來的計畫？

Apple 的審核人員給了我們兩個建議：

為每一堂課建立「非消耗型項目」IAP
使用「消耗型項目」IAP 建立「虛擬點數」的購買機制，也是目前的主流做法

遺憾的是，2019 年 5 月，我們決定將人力投入到其它的 Hahow 專案，停止 Hahow App 的後續開發及維護。

結語

很多東西到最後已經不是技術的問題，Code 能解決的都是小問題。

最後，我們公司正在招募 iOS Engineer 以及 Android Engineer。

如果你熟悉 App Store Review Guidelines，跌過無數次 Apple 裏規則的坑，擁有豐富的送審經驗，擅長與 Apple 審核人員打交道。那麼，我們非常需要你這樣的人才。

參考資料

無限環境（ㄧ）Netlify Deploy Previews

Sun, 01 Mar 2020 00:00:00 GMT

大綱

什麼是「無限環境」？
什麼是 Netlify Deploy Previews？
快速入門指南
總結
附錄
參考資料

什麼是「無限環境」？

大家常用的 GitHub flow 其實有一個常常被忽略的重點 — — 合併前部署。

我自己在前端開發的 Code Review 上，常常碰到下列兩個問題：

PR 合併、部署到 staging 或 production 環境之後，才發現程式碼有問題
為了避免第一個問題發生，就必須先 checkout PR 到 local 環境，然後經過一系列繁瑣的步驟跑起來，最後才能開始驗收和測試

為了解決上述問題，就需要引入無限環境的概念。

所謂的無限環境，就是自動將目前 PR 中的最新 commit，部署到一個臨時環境中，並返回該環境的 URL 網址。（如果口袋夠深的話，甚至可以部署每一個 commit 以方便比對。）真正的敏捷工作流 — — GitHub flow

如果能實現這個條件，將為開發團隊帶來兩點好處：

Reviewer 有任何懷疑時，便可以直接在預覽環境中驗證，而非憑空猜疑。
Reviewer 也可以放心大膽的驗證自己的懷疑，不需要在 local 開發環境耗時費力地切換。

接下來我會寫三篇「無限環境」系列的文章，介紹一些可以達成這個目的的工具。

這是第一篇文章，介紹如何透過 Netlify 的 Deploy Previews 服務，建立靜態網頁的無限環境。

什麼是 Netlify Deploy Previews？

Netlify 是一個類似 Heroku 的 All-in-one PaaS，提供各種現代 web 專案會用到的自動化服務，例如：靜態網站部署、CDN、持續交付和一鍵配置 HTTPS 等。

其中 Deploy Previews 這項服務，可以將 GitHub repository 中的每個 pull request 部署到唯一的 URL，與 staging 和 production 環境的完全不同。你和你的團隊可以在合併到主分支、並且部署到正式環境之前，提前看到更改的外觀以及驗收功能是否正確。

快速入門指南

這篇文章會以時下最流行的 Create React App 為例，示範如何實現 React 網站的無限環境。

步驟一、建立 React 網站

透過 npx create-react-app 指令，快速產生一個 React App 專案：

$ npx create-react-app test-netlify-deploy-previews
$ cd test-netlify-deploy-previews
$ npm start

打開 http://localhost:3000 確認 React 網站成功運行：

步驟二、建立 GitHub repository

這篇文章以 GitHub 為例，Netlify 同時也支援 GitLab 和 Bitbucket。

首先，在自己的 GitHub 新增一個 repository：

接下來，將程式碼 git push 至 GitHub repository：

$ git remote add origin git@github.com:amowu/test-netlify-deploy-previews.git
$ git add .
$ git commit -m "chore: create react app"
$ git push origin master

步驟三、註冊＆配置 Netlify

前往 Netlify 註冊頁面，這裡以連結 GitHub 帳號的方式為例：

第一次需要「Create a new team」建立一個 team，免費方案只允許一位 team member。

接下來，選擇「New Site from Git」：

選擇 GitHub 作為持續交付的服務對象：

第一次需要透過「Configure Netlify on GitHub」安裝 Netlify 的 GitHub App：

選擇要安裝在 GitHub 的個人帳號或是組織帳號，點選「Configure」：

如果希望自己所有的 repositories 都套用 Netlify 服務，可以選擇「All repositories」。因為這裡只跑文章範例，所以選擇「Only select repositories」：

點選 repository 進入配置頁面：

接下來是重點，在 Basic build settings 底下有「Build command」和「Publish directory」兩個欄位，要填寫正確，否則 Netlify 無法正確地部署網站。

Build command 填入 yarn build
Publish directory 填入 build/

yarn build 是 Create React App 提供的指令，會將靜態網站的檔案輸出到 build/ 資料夾底下。

如果使用的是其它靜態網站產生工具（例如 Jekyll），這兩個欄位填入的內容注意不要填錯了。

最後，點擊「Deploy site」開始部署網站：

部署成功之後，就會看到一組屬於 master 分支的 production 環境（支援自訂網域）的 URL 網址：

到這裡，就完成了 Netlift 的基本配置。接下來，介紹如何實現 Deploy Previews。

最終步驟、玩轉 Deploy Previews

其實也不用特別配置，因為 Netlify 預設就會開啟 Deploy Previews 這個功能。我們直接送一個 Pull Request 試試。

打開 src/App.js，修改幾行程式碼如下：

<p>
  - Edit <code>src/App.js</code> and save to reload.
  + Hello World!
</p>

接下來，建立新的分支，並 git push 到 GitHub：

$ git branch feature/hello-world
$ git add .
$ git commit -m "refactor(App): hello world"
$ git push -u origin feature/hello-world

最後，打開 GitHub，新增一個 merge master from feature/hello-world 的 Pull Request，捲至頁面至下方的 status checks 區塊，應該會出現 netlify//deploy-preview 的 check：

等待「Deploy preview ready!」出現之後，表示 Netlify 已經順利將 PR 部署到一個暫時的環境，這時候可以透過點擊右方「Details」打開 Netlify 提供的唯一 URL，應該就會看到文字被更改「Hello World!」的頁面。

成果展示：

至此，完善 GitHub flow 的最後一哩路，「合併前部署」的流程就建立起來了。

未來 Code Reviewer 驗收 PR 的時機點，就可以發生在 merge master 之前，大大降低了「上線之後才發現問題」的發生機率。

總結

Google 的 Code Review Developer Guide 曾經提到，看 PR 的優先順序，應該是先跑跑看結果是否正確。如果一開始就投入大量時間去 review 程式碼，但是發現跑出來的結果根本是錯的，那麼這其實是很浪費人力成本的。

這篇文章介紹了 Netlify 的 Deploy Previews 服務，結合 GitHub flow，讓 code author 在送出 React app 的修改 PR 時，自動在合併回主分支之前，先提前部署一次性的「無限環境」，讓 code reviewer 優雅地驗收測試，避免發生上線 production 環境之後才發現程式碼有問題。

介紹完 Netlift Deploy Previews 之後，可能會有讀者好奇：「萬一我們的專案不是靜態網站、而是動態網站呢？」。

真實的世界，不會只有靜態網站那麼單純。下一篇，我會介紹如何透過 Heroku 的 Review Apps 來實現動態網站的無限環境，敬請期待。

附錄

如何刪除安裝在 GitHub repository 的 Netlify app？

如果之後不需要 Deploy Previews 這個服務，可以前往安裝的 repository 頁面，依序執行以下步驟：

Settings > Integrations & services > Installed GitHub Apps > Netlify > Configure > Uninstall Netlify > Uninstall

可以套用在 components library 嗎？

假如你的專案不是網頁應用，而是元件庫（例如 nwb 的 React Components and Libraries）。那麼，通常專案會搭配 Storybook 這個工具一起協助開發。

這時候，只需將 build settings 設定成 Storybook 的指令，然後指定輸出資料夾即可：

Build command：npm run build-storybook -- -c .storybook
Publish directory：storybook-static

參考資料

全遠端工作

Mon, 03 Jun 2019 00:00:00 GMT

遠端工作並非一個需要克服的挑戰。而是一個明顯的商業優勢。

原文標題：All Remote 原文網址：https://about.gitlab.com/company/culture/all-remote/ 原文作者：GitLab

GitLab 是一間全遠端（All Remote）的公司，團隊成員遍布全球 50 多個國家。這裡介紹了一些 GitLab 的工作原理。

遠端工作宣言

全遠端工作提倡：

從世界各地招聘和工作，而非從公司附近
彈性工時優於固定工時
通過寫下來記錄知識，而非口頭傳授
建立流程，而非在職培訓
公開分享資訊，而不是只告訴你該知道的
開放每份文件供任何人編輯，而非自上而下的存取權限控制
非同步通訊優於同步通訊
重視工作結果，而非投入的工時
正式的溝通管道優於非正式的溝通管道

為何遠端？

遠端工作並非一個需要克服的挑戰。而是一個明顯的商業優勢。 — — Victor, Product Manager, GitLab

從節省辦公空間的成本到提供員工日常生活的更大靈活性，完全遠端工作為組織及其員工提供了許多優勢。但我們也體認到，並非所有人都適合成為一家完全遠端的公司。以下是一些優點和缺點。

優點

對於員工

日常生活更彈性（小孩、父母、朋友、雜務、運動、快遞）
不會浪費時間、精力或金錢在通勤上（捷運和公車費用、汽油、汽車維護費、收費站等）
減少接觸生病同事的細菌
減少被打斷的狀態，提高生產力
能夠在不請假的情況下遊歷其它地方（家庭、娛樂等）
自由移動
有些人發現遠端更容易與難搞的同事溝通
減少入職可能會有的社交壓力
在家吃飯（有時）更好，更便宜
某些國家的稅收可能更便宜
不需要工作服（譯者註：不用煩惱今天穿什麼）

從家庭時間到旅行計劃，有很多關於遠程工作如何影響全球 GitLab 團隊成員生活的例子和故事。

這些靈活性使家庭的生指品質呈指數級增長，從而減輕壓力，提高您的工作效率和積極性。這些價值是金錢無法衡量的。 — — Haydn, Regional Sales Director, GitLab

對於組織

招募優秀的人才，無論他們所居何處
員工的干擾更少，效率更高
增加省下來的辦公室成本和補償金（基於在低成本地區招聘）
吸引自我啟動者（self-starters，他們不等待被賦予任務、職責，他們會直接出擊，在短時間內獲得最好的成果）
更容易快速發展您的公司
減少會議次數，重點關注結果和出色的工作成果
在當地動亂或自然災害（例如政治或天氣相關事件）的情況下保持業務的連續性

對於世界

全遠端工作的優勢不僅止於一個組織及其人員。由於沒有通勤的員工，也沒有辦公大樓或園區，所以遠端公司的碳足跡都要小得多。對於全球公司而言，為低成本地區帶來薪酬較高的工作也會產生積極的經濟影響。

https://youtu.be/NoFLJLJ7abE?si=x09YybzRJTeBYWdW

缺點

儘管有其優點，但全遠端工作並不適合所有人。根據他們的生活方式和工作偏好，它可能對潛在員工以及組織有不利之處。

對於員工

當你處於遠端時，入職可能很困難，因為它涉及更多的自我學習，而你並沒有與新同事和新員工在一起
遠端角色的第一個月可能會感到孤獨，特別是如果您從傳統的辦公環境過渡
如果組織沒有意識到替員工之間建立保持聯繫的方式，那麼遠端可能會導致溝通技巧中斷
有些人可能會發現很難在他們生活和睡眠的同一環境中工作，因為專用的工作空間有助於將環境從他們的家庭生活轉換為工作
不同時區的團隊成員可能不得不在會議時間上妥協
世界各地的貨幣和稅收要求的差異可能給組織帶來挑戰

對於組織

因為全遠端工作非傳統，有時會讓投資者、合作夥伴和客戶有所顧慮
世界各地的貨幣和稅收要求的差異可能給組織帶來挑戰

為何時機已成熟？

如果沒有技術的不斷發展，並且持續開發和改善這類工具，完全遠端工作是不可能的。

我們不僅僅看到這些對全遠端公司的影響。事實上，在一些大型園區的組織中，員工通常會進行視訊對話，而不是花 10 分鐘去其它大樓。

以下是使遠端工作成為可能的一些關鍵因素：

隨處可連的高速網路，100Mb/s 以上的有線網路、5GHz Wifi、4G 行動網路
視訊對話軟體，Google Hangouts、Zoom
行動科技，每個人的口袋裡都有一台電腦
語音轉文字軟體的進化，比打字更快、更準
通訊應用程式，Slack、Mattermost、Zulip
任務追蹤工具，Trello、GitHub issues、GitLab issues
貢獻工具，GitHub Pull Requests、GitLab Merge Requests
靜態網站，GitHub Pages、GitLab Pages
英語水平，更多人學習英語
城市的交通擁堵在增長

「全遠端」並不意味什麼？

讓我們來解決一些關於完全遠端工作的常見誤解。

首先要做的事情是：一個全遠端的公司意味著沒有多個人所在的辦公室或總部。在分區辦公室沒有人的唯一方法就是沒有總部。

通常「遠端」和「分佈式」是可以互換使用的術語，但它們並不完全相同。GitLab 更喜歡「遠端」一詞，因為「分佈式」表示多個實體辦公室。「遠端」指的是能夠從任何地方完成工作。

對於員工而言，成為一家完全遠端公司的一分子並不意味著獨立工作或孤立，因為它不是人類互動的替代品。技術使我們能夠與團隊保持密切聯繫，無論是在非同步的文字中還是通過視訊進行的即時對話。團隊應該密切合作、經常溝通，並感覺自己是一個大型團隊的寶貴成員。

遠端工作也並不意味著你身體受到限制。您可以隨意在任何地方工作。這可能是在家裡與家人、咖啡館、一個共享空間，或當地的圖書館，而你的小寶貝正在享受故事書時間。您可以全天與同事進行頻繁的視訊聊天或虛擬會議配對，如果您位於彼此附近，您甚至可以與其他同事見面，親自一起工作。

在組織層面，「完全遠端」並不僅僅意味著外包工作。相反，這意味著您可以聘請來自世界各地最優秀的人才。它也不是一種管理範式。您仍然有一個分層組織，但重點是輸出而不是輸入。

總而言之，遠端基本上是關於自由和個人選擇。在 GitLab，我們重視您的結果，而不是您完成工作的地方。

GitLab 如何建立他們的全遠端團隊

GitLab 已經學習了很多關於構建和管理完全遠端團隊所需的知識，並希望分享這些知識以幫助其他人取得成功。

了解 GitLab 如何使其工作並查看我們的遠端工作提示。

資源

瀏覽 GitLab 的資源頁面，了解有關 GitLab 全遠端方法的更多資訊，閱讀新聞中的遠端工作，以及了解其他公司的主導方式。

這裡列出了受 GitLab 文化啟發的公司名單。

最後下班的人，先離職

Mon, 20 May 2019 00:00:00 GMT

前陣子在書店架上看見一本書，書名是《最後下班的人，先離職》。

雖然標題有點殺人，但是翻了幾頁之後，還是勾起了我出社會之後第一份工作的一些回憶，那段總是最後一個關辦公室燈火的日子，雖然最後不是因為這個理由離職，但現在回想起來，真的不健康。

換了一份工作之後，開始注重起「時間管理」，學習如何在有限的時間內，完成無限的任務。但是最近，有位同事過不了這個檻，離職了。

所以想藉著這篇文章，討論什麼樣的組織架構、人力配置、合作方式，才適合快速擴張中的新創公司。

為什麼常常加班？

大部分的人認為，超時加班是公司或管理階層該解決的問題，但員工其實也是當事者之一。

要解決這個問題，就必須先掌握「為什麼常常加班？」的本質原因。

加班的理由通常可分成兩大項，首先是因為某些緣故，導致想下班也「無法下班」，其次是其實可以下班，卻「不下班」。

先就「無法下班」來思考。一般而言，會造成這種現象的理由可能包括「不能下班的氣氛」（例如最近很火的 996）、「工作做不完」、「需要待命」。

其中「工作做不完」這點似乎還能繼續探討背後的原因。比如「工作負荷太重」，任務多到在上班時間內做不完。另一個原因可能是工作量正常，但是「工作效率不彰」所導致，可能是「團隊的進度拖延」，也可能是個人的「工作方式有問題」。

接著針對「不下班」的問題，把所有想得到的理由全部列出來。「熱愛工作」、「想賺加班費」、「回家也沒事做」。這三個原因之中的「想賺加班費」，有可能是因為「薪水太低」，或是薪水不錯，但「需要更多錢」這兩個理由。

總結所有原因或理由整理之後可以發現，在各種常常加班的原因之中，摻雜著「職場問題」與「個人問題」。

本文不探討諸如「熱愛工作」之類的個人問題（熱愛工作你還會離職？）。

焦點放在職場問題：

不能下班的氣氛
需要待命
工作負荷太重
團隊的進度拖延
薪水太低

三角貿易

三角貿易（英文：triangle trade）起源於 16 世紀的歐洲。最著名的是歐洲，西非以及美洲之間的大西洋三角貿易：

歐洲 → 西非：酒精、軍火、紡織品等工業製品
西非 → 美洲：奴隸
美洲 → 歐洲：貴金屬、礦石、蔗糖、菸草、咖啡、可可、糧食等農產品及原材料

回來看 KPI 這件事，一間公司的績效量化指標通常也可以歸類為三種，剛好對應專案管理難題的金三角：

品質 = 要好
時程＝要快
營收 = 要便宜（營收升高，相對成本就降低）

因此，我建議可以將團隊分為三個 team：

Cheap Team → 負責替公司帶來營收（money）
Good Team → 負責解決產品品質問題（quality）
Fast Team → 負責加速公司發展（time）

Cheap Team 負責事項：

公司長期目標（Roadmap）的新功能（Feature）開發

Good Team 負責事項：

來自產品本身的需求（例如：客服回報的 Bug）
撰寫 Cheap Team 的測試案例
重構技術債

Fast Team 負責事項：

其它額外的需求（例如：資料查詢、埋追蹤事件、主機掛了）
DevOps，將日常瑣碎的事務自動化
基建設施（Infrastructure）
活動網頁

這樣的分配可能會造成「被分配在某個 team 的人沒有成就感」的問題，所以可以根據團隊的特性調整，例如每一季輪調一次，這樣一來可以解決倦怠感，二來透過輪流，不熟悉相關事務的人可以去問最熟的人向他學習，達到溝通交流的目的，也解決「這個業務只有他會，所以每次都找他」的問題。

另外，這個機制也可以解決「需要待命」的問題，例如 Fast Team 要在主機掛掉的時候馬上反應處理，如果每次都是同一批人，那累積久了，他就是下一個離職的那個人。

如果有的人只喜歡做某件事，例如 DevOps，不喜歡做新功能，那也可以不參與輪調機制，但必須專注該項業務，否則可能會造成「團隊的進度拖延」問題。

解決了「需要待命」和「團隊的進度拖延」的問題之後，接下來看「薪水太低」與「工作負荷太重」的問題。

加薪一般來說有兩種方法：

增加底薪
增加獎金的抽成比例

而這兩種方法的都需要靠「晉升」才能辦到。

目前比較主流的晉升體系是「雙通道」，根據員工的適才適性，分成兩種管道：

專業方向的 Individual Contributor，簡稱 IC
管理方向的 People Management，簡稱 M

以 Oracle 這間公司為例，IC-3 的資深工程師可以往 IC-6 的架構師發展，M2 的 Manager 可以往 M6 的 VP 努力前進。

這一切看起來都很美好，喜歡搞技術的，可以持續專研精進自己；擅長與人溝通、協調資源能力強的人，可以往管理職發展。

但是亞洲的職場環境，通常鼓勵員工往管理職發展，一來獎金分配的比例比較高，二來職稱也比較好看（經理、總裁、總監聽起來比工程師、架構師還高大尚）。

導致許多 IC 紛紛往 M 發展，造成原本個性不適合管理人的員工遭遇「彼得原理」，結果就是：

擠擠一堆 M 在那出一張嘴，沒人做事的窘境
一切自己來，最後出現「工作負荷太重」的問題

而要解決這兩點問題，只有走上「淘汰」或「離職」兩條路，造成管理職位出現空缺需要填補，然後還是回到鼓勵大家應該往管理職發展的惡性循環。最後出現類似「〇〇歲還是工程師沒升管理職，這個人是不是有什麼問題」之類的價值觀。

我不否認管理職的重要性，但是領導能力強的人本來就很稀缺，如果職場的制度是鼓勵你往管理晉升，而不是留住有貢獻價值的人，當一個不適合 M 職能的 IC 站上 M，有可能賠了夫人又折兵。

雙首長制

每逢選舉時日，這個國家的在野黨候選人就會提出要廢除「雙首長制」，主張改成「總統制」或「內閣制」。但是政黨輪替之後往往就不了了之，因為當總統實在太爽了，位於行政及立法之上，可以不受立法限制。

扯遠了⋯⋯，關於雙首長制的更多缺點，請參見「維基百科」。

如果說「三角貿易」解決的是來自 PO 右側，屬於外部需求的「工作負荷太重」問題，那麼接下來要提到的「雙首長制」組織架構，是我認為可以解決 PO 左側，屬於來自工程師給予的「工作負荷太重」的一種方法。

以 CPO 為首，產品開發團隊主要由 PO 和 Tech Lead 帶領，分別負責產品時程與品質的管理，一個專注人、一個專注事。

PO 的負責範圍：

產品設計（掌握使用者要什麼）
時程管理（確保任務是在前進的）
資源協調（溝通、排除任何會阻礙前進的問題）

Tech Lead 的負責範圍：

架構選型
風格一致
權限控管
任務規劃

如果找不到合適的 PO，也可以先從 Designer 搭配 Project Manager 開始，一個負責產品設計，一個管理時程和協調資源。

至於這裡不設立 CTO 的原因，我認為以台灣產業短視近利的尿性來看，還是以 CPO 為主會比較務實。如果是新創團隊，那麼迭代的腳步更快，CTO 與 CPO 並存什麼的更是天方夜譚。我曾經在《殺雞用牛刀》這篇文章探討過 Google 的工程導向文化和 Facebook 產品導向文化，且先不說台灣，可能大部分灣區的新創初期都是在燒錢，很少有時間給你搞技術，隨便一句「先求有再求好」就可以讓你掉棒，至於是不是之後真的會求好，亦或是繼續再求有，就不得而知了，因為很少有新創可以活過五年的。

總結一下，離職的原因千百種，其中較常見的理由是「常常加班」。加班的原因主要可以歸納為「個人問題」與「職場問題」兩種類型，本文主要探討幾種職場問題，以及解決方法。

透過「三角貿易」的概念，將團隊劃分成負責加速的 Fast Team，負責品質的 Good Team，以及負責營收的 Cheap Team，解決「要快、要好、要便宜」的三角難題。

Cheap Team 專心開發能為公司帶來營收的新功能，其它額外需求交給 Good Team 和 Good Team 去折騰，避免有團隊成員開發到一半被抓去做其它事的窘境，解決了「團隊的進度拖延」問題。

其中最容易發生「需要待命」的任務限縮在 Fast Team，讓外部人員知道碰到緊急狀況要直接找誰負責，解決 PO「工作負荷太重」的問題。另外透過每一季輪班的機制，避免壓力都扛在幾個人身上，也解決 Engineer「需要待命」的問題。

最後是在 CPO 負責的產品團隊底下，設立了 Tech Lead 和 Product Owner 並行的「雙首長制」，Tech Lead 負責維護開發品質，適合讓喜歡專研技術的 IC 當作晉升目標；Product Owner 負責管理資源和確保產品走在時程上，適合擅長溝通協調的人發展。晉升體系如果完善，就有了明確的努力方向，因為「薪水太低」而離職的人或許也會降低。

至於因為「不能下班的氣氛」而加班的人，我認為還是儘早離職比較好。或許如

阮一峰在他的文章中提到的：「程序員要做的不是反對 996，而是提倡遠程辦公。」

自由與秩序該如何取捨？

最近在玩《刺客教條》這款遊戲，裡面刺客對抗聖殿騎士的故事不禁讓我有所感悟。

上個世紀，集權專制帶來的慘痛教訓，如今這個世界上的大部分人，似乎都知道絕對秩序的壞處。追求自由，已成了我們這個時代最大的政治正確。

但是，沒有秩序的自由毫無意義，追求片面的自由與追求絕對的秩序同樣危險。

專案的管理方法不斷地推陳出新（Waterfall、Agile、Scrum、Kanban、KPI、OKR），但是團隊的運行卻不總是那麼順利。會不會其實問題是出在人本身而不是管理方法？

影響我一生的十大遊戲（一）

Mon, 06 May 2019 00:00:00 GMT

自 1989 年的平成元年算起，持續了約 30 年的「平成時代」已於今年 4 月畫下句點，5 月起由新年號「令和」正式接班。

日本遊戲媒體週刊ファミ通日前公布由讀者票選的「平成最佳遊戲」前三名經典作品。

拿下第一名的是 1995 年在 SFC（俗稱：超任）平台發售的《超時空之鑰》。本作受到 30 歲以上玩家（包括我）一致壓倒性支持，高票獲選。

《超時空之鑰》是由 SQUARE（當時尚未合併 SQUARE ENIX）負責製作發行，《七龍珠》作者鳥山明、《勇者鬥惡龍》之父堀井雄二，以及《太空戰士》之父坂口博信聯手打造的夢幻級 RPG。無論是劇情、美術、系統或音樂，放到今天來看仍是不朽的經典名作。

作為一路走過昭和、平成、令和時代的三朝元老級玩家，見證了這 30 年間五花八門的遊戲作品問世。最近看了 YouTube 頻道攻壳 Gamker 的《十大影響我的遊戲》系列之後，也想來寫一篇影響我一生的十大遊戲。

第十位：熱血行進曲（FC）

1992 年在 FC（俗稱：紅白機）上發售的《熱血行進曲》是我最早接觸的「強社交」類型作品。什麼是強社交？簡單來講就是「互相傷害、往死裡打」系列。

正所謂「不打不相識」，俗話說「見面三分情」，在我小時候還沒有網際網路的時代，社交基本都靠交換玩具、聊卡通、聊漫畫、打球，以及打電動這些娛樂來聯繫感情。

老人圍在公園涼亭下象棋，小孩圍在電視機前搏感情

另外還有一款類似的遊戲，同樣也影響我深遠。那就是 1995 年在 Windows 平台上的《小朋友齊打交》（簡稱：LF）。

這款遊戲最有魅力的地方在於四個人需要擠在同一塊鍵盤上操作。還記得我讀高職的時候，原本下課鈴響都是搶球場優先，但自從學校替每間教室配一台爛電腦之後，我們的下課目標就變成了搶鍵盤。

因為我很喜歡這兩款遊戲帶來的同樂氛圍，所以大學的畢業專題便以此為靈感，開發了一款多人連線的對戰遊戲。那段埋首寫程式的日子為我日後的遊戲程式設計打下基礎，並順利應徵上第一份正職工作。

還是學生的時候，同學或是三五好友的時間較一致，放學下課比較沒事，想打電動，約一約就可以隨時開始打了。

可是隨著年紀增長，你的朋友在上班，你的朋友在陪女友，你還能夠朋友幾個人聚在一起？幾個一起玩遊戲的好朋友，也許從一代二代認識的，現在，我們要一起玩個四代，很難了。

所以，你看朋友之間都已經這麼難聚在一起玩遊戲了，如果還要把這麼珍貴的時間花在與那些外掛氾濫的遊戲玩家對賭，豈不浪費人生。

所以我還是堅持買主機玩線下的單人遊戲或是可以同樂的多人遊戲，因為買的是一個尊嚴。

總結：《熱血行進曲》和《小朋友齊打交》這些「強社交」類型的遊戲，影響了我的朋友關係與職涯發展，故列為第十位。

下一期，影響我一生的第二款遊戲，我打算介紹某款台灣製作的 PC 遊戲，敬請期待。

向死而生

Mon, 22 Apr 2019 00:00:00 GMT

HBO 當家美劇《權力遊戲》終於迎來了最終季，在上周開始全球播映。

首集上線之後馬上就創造了 5,500 萬次的「盜版收視」。而相較於盜版來源，官方的收看來源總計也不過 1,740 萬名觀眾。

即便是在美國這種相對容易訴諸法律的國家，在非法收視排行榜上仍居第三位。

雖然在台灣可以合法收看該影集，但因為正版授權的版本都經過了「審查」，不少片段遭到刪剪，因此有些人轉向收看盜版的「完整版本」。

過去許多軟體開發商設計很多數位鎖，想要防止被盜版，但歷史證明都沒有用。開發數位鎖不但浪費了軟體開發商大筆的時間和金錢，最後鎖住的卻往往是有良心乖乖買正版的使用者。 — — 《軟體如何賺錢？》

作為一個追劇近 10 年的死忠粉絲，一直不解為何劇組要將這部劇的標題命名為 Game of Thrones（權力遊戲），而不是原作小說的書名「冰與火之歌」？

直到 2013 年的某一天，當時《權力遊戲》的進度還只是在第三季的時候，我就被知乎這篇「《冰與火之歌》為什麼取名叫『冰與火之歌』？」之中的一則回答給驚豔：

A Son（瓊恩·雪諾）g of Ice（萊安娜·史塔克）and Fire（雷加·坦格利安）

要知道雪諾的身世之謎這個秘密，可是一直到了 2017 年第七季的最後一集《The Dragon and the Wolf》才被公諸於世。由此可見這個伏筆埋得之深，想必連劇組自己當初也沒想到。

所以相比之下，我其實是更喜歡「冰與火之歌」這組命名的。

但是最近隨著知識的長進，接觸了更多的人情世故之後，我原先的這個想法開始有了改變，漸漸能理解為什麼要叫《權力遊戲》。

除了「電影要比小說更貼近大眾」這個理由之外，其實這個世界上的所有人類活動，你都可以看作是一次次「權力的遊戲」。

最近讀了一本書，書名是《有限與無限的遊戲》。書名中的「Games」除了翻譯「遊戲」之外，也可以翻為「博弈」。

那麼「有限與無限的博弈」是什麼意思？

本書作者把世界上所有的人類活動都看作是一次又一次博弈。

其中大量的活動是「有限」的博弈，小到下棋、跟人吵架，大到經營一家企業、發起一場戰爭等等。這種博弈有個特點，那就是以「取勝」為目的，這也是為什麼叫有限博弈，因為贏了就結束了，只有輸贏一種結局。

還有一種「無限」的博弈，這種博弈是以「延續」為目的，例如：婚姻、文化、宗教還有生命等等，在延續的過程中會產生出無數種可能的結局。

這種世界觀有什麼用呢？它可以解答一個人類的終極問題：

人的一生該怎麼過？

什麼是有價值的，什麼是有意義的。人要是死了，一切都是白談，所以「生命」這個無限遊戲想必是最值得追求的。那當我們把時間維度放大到生死邊界的時候，該追逐什麼就一目了然了。

玩有限遊戲時的一次次成敗，不過是我們人生中的某一次體驗、某一段經歷，而讓我們的人生真正產生價值的，是那些可以不間斷延續下去的事物。

有限遊戲在邊界內玩，無限遊戲卻是在和邊界玩，探索、改變邊界本身。

有限遊戲看起來像在做一件有期限的事情，我們做的時候常常假定自己是能永遠活下去的；與之相反，無限遊戲是一件沒有邊界的事情，所以當我們做的時候，是抱著自己一定會死的心情。

有限遊戲的參與者為了取勝，會在有限的時間維度下自願給自己設定許多邊界，摒棄自己一部分的自由；無限遊戲的參與者會將時間維度拉長到一生，抱著向死而生的心境去生活，透過延續各種無限遊戲，來達成根本自由的狀態。

我們的社會就是一個有限遊戲，目的是取得勝利從而獲得權力。社會為了提高自身獲勝的機率，設置了一系列的運行機制，用來確保社會中的每一位公民都在玩同一種有限遊戲。

既然我們都是生活在社會中的公民，那麼是不是注定一生中的大量時間只能被用來玩各種有限遊戲？

這本書的最大價值，就是為我們提供了一個新的方式去理解世界的認知模型，或許我們應該用無限遊戲的心態去玩有限遊戲，發現生命的可能性。

就像傳統電子遊戲也分「開放世界遊戲」、「沙盒遊戲」和「箱庭遊戲」，它們不分誰優誰劣，這些遊戲會根據不同的目標群體，有著不同的優點和缺點。但是可以確定的是不論是什麼遊戲類型，在合適的製作人手中都能創作出最棒的遊戲作品。

有限遊戲是有劇本的，而無限遊戲則是傳奇的。

為什麼靜香要嫁給大雄？

Mon, 15 Apr 2019 00:00:00 GMT

2019 年可以說是 3DCG 動畫電影的一年，尤其是改編經典故事的作品。除了年初的《艾莉塔：戰鬥天使》之外，還有近期上映的《小飛象》，以及未來即將播出的《名偵探皮卡丘》和《獅子王》。

知名日本遊戲公司 SQUARE ENIX 日前宣布，《勇者鬥惡龍》系列也將推出 3DCG 動畫電影《勇者鬥惡龍你的故事（暫譯）》。預定 8 月 2 日在日本上映。

身為一個 DQ 的粉絲，看到這則新聞的時候很興奮，覺得不吹一波對不起自己的情懷。

https://youtu.be/pUFO5uE2FeM?si=BUieXr6kb0vapde_

《勇者鬥惡龍你的故事》是由過去同樣製作過 3DCG 動畫電影《STAND BY ME 哆啦A夢》的團隊負責。

作為一個從「小叮噹」漫畫時代開始看起的過來人，這裡順便科普一下《STAND BY ME 哆啦A夢》的故事，其實是結合了多部原作中的經典劇情，例如《從未來之國千里迢迢而來》、《雪山上的浪漫史》、《大雄的結婚前夜》、《再見哆啦A夢》和《哆啦A夢回來了》等篇目。

其中在看《大雄的結婚前夜》的當下，我都抱持「為什麼藤子不二雄要讓靜香嫁給大雄？」的疑問。直到這段「靜香與爸爸的對話」：

靜香：「我很擔心，能不能好好地與大雄生活」爸爸：「我認為你選擇大雄是完全正確的。大雄會為別人的幸福而高興，為別人的不幸而傷心。這對於一個人來說是最重要的東西」

當時三觀受到的衝擊，可以說不亞於「為什麼井上雄彥不讓湘北拿冠軍？」一樣的程度。

話題回到 DQ。說來也巧合，前陣子才剛好和同事聊起這系列的想法。基本上《勇者鬥惡龍》的正統系列我只玩過 4、5、6 和 9 代，其中前面三代因為故事有關聯，被合稱作「天空系列三部曲」，也是被跨平台重製或移植次數最多的一個系列。

如果只讓我推薦一款 DQ 給你，我會毫不猶豫的選擇 5 代《天空的新娘》。如果讓我選出心目中最棒的穿越故事劇情，我也會毫不猶豫的告訴你是《天空的新娘》。

而這次的電影《勇者鬥惡龍你的故事》就是以《勇者鬥惡龍 5 天空的新娘》為原案，所以爆米花可以先準備好了，到時候我們電影院報到（如果台灣會上映的話⋯⋯）。

我們與惡的距離

Mon, 08 Apr 2019 00:00:00 GMT

知名策略遊戲《文明帝國》有個被玩家吐槽的 Bug。遊戲中每位國家領導人皆擁有預設的「侵略指數」，而其中「和平主義者」甘地的預設數值為 1，這鮮明地反映了他在真實世界的人格特質：不挑起戰爭，不侵犯他國。

然而，若玩家在遊戲中採取民主政體時，國家的侵略數值會自動下降 2 點。此時，甘地的數值會變為 -1。有趣的是，遊戲中並沒有注意到負數的判斷，導致該數字直接跳至最高的 255 點，聖雄也因此褪下和平外衣，瞬間化身為「核平主義者」！

這故事告訴我們寫「邊界測試」的重要性。

上周這篇《上帝擲骰子嗎？》一文中，我提到了幾位自己很嚮往的程式設計師，其中一位 Jeff Dean 有朋友問我，他是誰？

在 Google，如果你問最牛的工程師是誰，大家會告訴你是 Google 的大腦 — — 傑夫·迪恩（Jeff Dean）。他不但開創了雲計算時代，也是深度學習算法的發明人。另外，如果問收入最高的工程師是誰，也是迪恩。他的收入比大部分 VP 要高很多。

最後，如果你問作為一個軟體工程師能走多遠，要是你能像迪恩那樣當上美國工程院院士，就可以寫程式一輩子。

更多關於傑夫·迪恩的故事，請參見《吳軍的谷歌方法論》。

在西方，一座教堂蓋上百年是常有的事情，中間自然要更換很多建築師，等到教堂完工時，通常和最初的設計會有很大差別。

建築大師高第為了保證「聖家堂」的設計思想不至於被後來的設計師改動，一反先建造內部的主體，再裝上外立面的做法，而是先從外立面開始建設，這樣後人就不會縮小教堂的規模了。

人們都說寫程式就像蓋房子，或許我們能從這些偉大的建築師之中，發掘出他們的智慧來應用。

中研院院士胡佛曾經說道，民主選舉有三個層次：國家認同、憲政結構、基本政策。

美國沒有國家認同的問題，除非夏威夷想要「夏獨」。憲政結構也就是一個「聯邦制」。所以選舉最後要辯論的就只剩下是否加減稅、墮胎或同性戀是否合法化這些「基本政策」問題。

台灣的困境是，國家認同的問題還沒解決，每每選舉佔據新聞版面的都是統獨議題，甚至連憲政結構的部分也在討論要換「總統制」或是「內閣制」之類的，導致與民生最相關的基本政策進展緩慢。

https://youtu.be/hFyl9SvALk0?si=SX-lVKmcjokNN4Vx

傳統的射擊遊戲裡，因為爆頭即死，所以玩家傾向提高「槍法」高效殺敵。

但在真實世界，作戰部隊追求的是無傷殺敵，因為受傷的代價太大了。為了不受傷，哪怕降低效率和浪費資源也在所不惜。

有個統計，戰場上平均每兩萬發子彈才能有一發擊中敵人，這些子彈主要都拿來做火力壓制，「彈幕」一詞就來源這裡。

東西方對龍的印象其實挺兩極的，前者認為神聖，後者認為邪惡。有一說，西方神話中所提到的魔鬼形象，恰巧與東方神話中所提到的神相似（角、鱗片）。或許，在西方信仰的這夥外星文明裡，和東方信仰的文明剛好是處於對立面？比方說：大洪水是西方神發動，卻是女媧給堵上的。

— — 《老高與小茉 Mr & Mrs Gao》

郵件是一個重要的溝通工具。在職場上甚至比見面和開會還要重要。很多人這輩子可能彼此只會透過郵件溝通。那麼一封好的郵件應該長什麼樣呢？我們與人見面的基本禮儀，不一定要打扮得花枝招展，而是保持得乾乾淨淨。一封好的郵件也一樣。

郵件禮儀的第一步，就是用真名
標題用不到 20 字來總結這封信的核心內容
真正的高手，所有文字只有一個顏色、一個大小、一個字型
排版只用三種方式：分段（閱讀邏輯）、縮排（層次關係）、粗體（突出重點）
每段的首句是整段的概括。用句簡短、用詞簡單、用字簡潔
結尾的部分再次總結郵件的內容，並強調對方需要行動的部分
收到郵件盡快回覆，代表你的能力、效率、重視的程度
送出前再次檢查標題、稱呼、錯別字、附件

雖然 Slack 已經取代了大部分的郵件使用場景，但是我認為還是一樣受用，對於寫文章也很有幫助。

— — 《羅輯思維》

Google 收購 YouTube 之後，透過關鍵幀的特徵值提取和信息指紋的比對技術，可以找出兩段影片是否相似。因此 Google 制定了一個有意思的廣告分成策略：所有影片都可以插入廣告，但廣告收益全部歸原創影片所有。這樣一來，拷貝上傳別人的影片就無法獲得收入。沒有了經濟利益，就少了很多盜版。

— — 《數學之美》

最近同事推薦了一部公視和 HBO 合作推出的社會寫實劇 — — 《我們與惡的距離》。趁著連假一口氣看了四集，真的好看！

故事透過「無差別殺人事件」呈現不同立場的關係者視角，描摹加害者家屬與被害者家屬的心理，探究人權律法的掙扎以及精神病識，同時反思媒體現象。 — — 維基百科

一個好的故事不會給你絕對的答案，而是給你「思考」的空間。

全天下沒有一個爸爸媽媽，要花個二十年去養一個殺人犯，加害者的家屬也可能是被害者。如果一個民主法治的國家要靠不符合程序的死刑殺人才可以討好民眾、討好媒體，那我們殺的人，並不會比殺人犯還少。

這讓我想到最近一部我已經棄坑、也在討論善惡的韓劇 — — 《獬豸》。片頭一段令人印象深刻的話：

獬豸，能審判善惡的傳說中的神獸。然而，你知道為何它只存在於傳說中嗎？因為想在現實中審判善惡，是不可能的。

感謝良心電視台公視，讓我們看到台劇並沒有比較差，台灣歐爸還是有希望的（雖然我比較喜歡賈靜雯的演技）。

最後，作為同樣感謝的贊助商，這期就特別留個百萬版面（？）給 HBO 放廣告。4 月 11 日，《冰與火之歌》最終季即將播映！究竟最後會是誰坐上鐵王座！？

上帝擲骰子嗎？

Mon, 01 Apr 2019 00:00:00 GMT

下圖是 Reddit 論壇上的一位大神，把近一世紀前的「第五次索爾維會議」黑白照片給上色後的結果。

索爾維會議的全名是「索爾維國際物理學化學研究會」，是由企業家索爾維於 1912 年在比利時布魯塞爾創辦的一個學會。通過邀請世界著名的物理學家和化學家對前沿問題進行討論的會議。每三年舉辦一次。在物理學的發展史上占有重要地位。

當中最著名的一次索爾維會議是 1927 年召開的第五次索爾維會議。此次會議主題為「電子和光子」，世界上最主要的物理學家聚在一起討論量子理論。

這次會議上最令後世津津樂道的故事，當屬愛因斯坦和波耳針對「不確定性原理」的鬥嘴橋段：

愛因斯坦：「波耳，上帝從不擲骰子」波耳：「愛因斯坦，不要告訴上帝應該怎麼做」

參加這次「第五次索爾維會議」的 29 人中，有 17 人最後獲得了諾貝爾獎。

這讓我想起 1992 年奧運會的籃球項目，美國隊第一次由 NBA 球星出征，號召了籃球世界最強的 12 個人，組成了這支籃球史上最傳奇的「夢幻隊」(Dream Team) 。

好奇之下，想說 IT 界有沒有類似的群星合照？（例如 Linus、John Carmack、Jeff Dean 等等⋯⋯）

查了一下，雖然算不上電腦科學家（敲程式的都不喜歡拍照？），但大概也是比較有名的合照，他們就是「PayPal 黑手黨」。

PayPal 黑手黨（PayPal Mafia）是指一群前 PayPal 員工。他們在離開 PayPal 再次創業建立的企業包括 Tesla、LinkedIn、YouTube 和 Yelp。其中的三個成員，包括馬斯克後來都成為了億萬富翁。

PayPal 黑手黨是 2001 年網際網路泡沫破滅後，面向消費者網際網路公司重新崛起的代表。

他們成功的背後，除了在 PayPal 時期的學習、矽谷的環境，以及各自技能的多樣性之外，最主要的原因在於他們擁有「八叛徒」的矽谷基因。離開 PayPal 後，在激烈競爭的環境下，儘管經歷挫折，仍然維持強烈且持久的情誼，互相支援和信任，一起共同奮鬥。

在矽谷還沒有誕生之前，全美國（或全世界）的叛逆者們都喜歡往矽谷地區跑，因為那裡遠離美國東部的政治、文化和金融中心，更遠離歐洲。

不喜歡美國傳統文化的人就跑到舊金山灣區（當時還不叫矽谷），通過文藝的形式（嬉皮），或者政治的形式（抗議）來實現他們改造世界的夢想。

這些充滿怪想法中的一些人是搞技術的，天天琢磨著顛覆現有產業，最終成功創辦出了一間又一間小公司。

科技實際上只是這些想改變世界的叛逆者們的工具而已。

Story of Your Life

Mon, 25 Mar 2019 00:00:00 GMT

語言本能

本周閱讀 Steven Pinker「語言與人性四部曲」的《語言本能：探索人類語言進化的奧秘》時，提到了「沙皮爾-沃爾夫假說」。

沙皮爾-沃爾夫假說（Sapir–Whorf hypothesis）是一個關於人類語言的假說，由語言學家兼人類學家 Edward Sapir 及其學生 Benjamin Whorf 所提出，是一門心理學及語言學的假說。這項學說認為，人類的思考模式受到其使用語言的影響，因而對同一事物時可能會有不同的看法。

S-W Hypothesis 還可以分為強弱兩種，分別是 Linguistic relativity（語言相對論）和 Linguistic determinism（語言決定論）。前者認為，不同語言在結構上的差異，對認知過程有所影響的。譬如一個人認為彩虹有幾種顏色，是由他的母語有那些基本顏色的詞彙來決定的。後者則認為語言極大程度地決定了一個人的世界觀。譬如愛斯基摩人對於雪的認識遠超於其它母語的人，因為他們對於不同狀態的雪（地上的雪、正飄下的雪、堆積的雪、雪堆）都有不同的名字，認為彼此是完全不一樣的東西。

語言可以分為強未來時表述（如英語）和弱未來時表述（如中文）。使用強未來時表述語言使人從認知上將現在和未來區分開來，使未來感覺起來更加遙遠。而使用弱未來時表述語言的人，認為現在和未來是連接相通的，而他們現在的行為會對未來產生更大的影響，於是他們會進行更多著眼於未來的事，例如儲蓄。

在我們博大精深的中文裡，如果你想稱呼一位男性長輩親戚，有伯父、叔叔、舅舅、姑丈、姨丈⋯⋯，而英文就一個詞「uncle」。中文讓我們對於家族關係更加敏感。

中文的所有數字都只有一個音節，但英文有多個音節（如 seven）。因為音節短，所以在有限的工作記憶中佔優勢。另一方面，像中文和日語都有規律可循的數字系統，如 11 ＝十一（對比英文中的 eleven)，潛移默化地加強了亞洲人對數字關係的認識。這樣的優勢被一部分研究認為是亞洲數學天賦的原因。

除了影響人的顏色、時間觀、金錢觀、人際觀、數字關之外，語言還有可能影響其它像空間、因果、個性（多重人格）、工作等等，有興趣的人可以看這篇《使用不同的語言，會對人們的思維方式產生怎樣的影響？》

華裔科幻作家姜峯楠的短篇小說《妳一生的預言》（Story of Your Life）就是基於沙皮爾-沃爾夫假說來架構的故事，並且在 2016 年改編成電影《異星入境》（Arrival）上映。

故事主要講述身為語言學家的女主角 Louise，受美國軍方征召，負責研究來訪地球的外星生物「七腳族」的語言。

七腳族告訴 Louise 3000 年後的未來，牠們的種族會需要人類的幫助，這就是牠們來地球的目的。作為回報，七腳族分享了一項「武器」 — — 語言，它可以改變人類對時間的線性感知，使他們能夠體驗尚未發生的「未來記憶」。

人類過去認為宇宙是一個線性時空，以為時間是單向、不可逆的，但是來訪的七腳族外星人教導人類時間和空間一樣，是同時存在的，時間的過去和未來都像空間一樣是展開在眼前的，這也表現在牠們的語言中。當 Louise 學會外星語言，才恍然大悟，開始「回憶」起未來的事。

後記

本身是一位程式設計師，對於語言會改變思維這件事也深有同感。

雖然工程師的語言鄙視鏈中常常出現 C++、Java、PHP、Python 這些常客，但其實都脫離不了物件導向式語言的指令式程式設計（Imperative programming）思維。

直到接觸了函數式程式設計（functional programming）的語言（如 Erlang、Lisp、Scala）之後，才發現另一種不同的程式設計思維方式。

最近在學習 RxJS 的時候，發現《異星入境》這種從「線性時空」轉換至「非線性時空」的思維方式，對於理解 observable 的 stream 概念很有幫助。

《異星入境》是少數我認為同時結合硬科幻與軟科幻的優秀電影作品，另一部則是神作《星際效應》（Interstellar）。

天下熙熙，皆為利來；天下攘攘，皆為利往

Mon, 18 Mar 2019 00:00:00 GMT

文摘

《大賣空》

《大賣空》（The Big Short）是一本由 Michael Lewis 所著，講述 2000 年代「泡沫經濟」題材的暢銷書籍。

賣空，也可以稱作「空頭」，是貫穿全書的一個核心概念。

說到「金融」這個詞，簡單一點的，股票、債券、基金，還有形形色色的理財產品；複雜一點的，結構性的資產證券化、衍生類的期權、期貨等等。但其實金融產品說白了，它就是一份「合約」。

只要是合約，就有買賣雙方：甲方和乙方。最多再有個經紀人：中間方。金融業說白了就是一個關於「風險和預測」的行業。能簽合約，通常說明雙方對一件事的風險和預測立場是不同的。覺得會漲的，我們就說他對未來「看多」，說他們是「多頭」；相反，那些覺得會跌的，是對未來「看空」，他們就是「空頭」。

《大賣空》講得就是「美國次貸危機」之後，收穫巨大利益的四群人的故事，他們被稱作「大空頭」。

一個人要是沒有任何成見，就算再笨，也能理解最困難的問題。但是如果一個人堅信，擺在他面前的問題他早已瞭然於胸，毫無疑慮，那就算他在聰明也無法理解最簡單的事。

―― 托爾斯泰

《行動的勇氣》

金融危機通常是指銀行過度向股票或房地產市場放貸，隨後泡沫破滅，銀行放出去的貸款收不回來，老百姓存在銀行裡的錢就取不出來，銀行不得不宣佈破產。這就是所謂的「擠兌」。一旦銀行出現了擠兌，那麼銀行首先需要保證盡量兌現儲戶的存款，而不得不停止向正常的企業發放貸款，從而導致一些企業出現資金鏈斷裂，進而出現大量的企業破產、工人失業等等一系列的惡性循環。簡單來說就是，銀行缺錢，企業缺錢，老百姓缺錢，最後經濟停擺。

美國次貸危機不同。美國的金融監管碎片化，出現了很多傳統銀行體系之外、形式多樣的金融機構。它們往往不是銀行，而是某某資產管理或信貸公司，但它們卻像傳統銀行一樣涉足房貸、抵押擔保和票據融資業務。它們的資金也不是來自於儲戶的存款，而是通過一種叫做短期票據市場再回購協議，從其它銀行和基金公司吸收存款。次級債券就是這樣一種金融產品。

次貸危機之後，一路調查下來才發現實在太荒唐了，沒有穩定收入的人都能貸款買 5 套房，甚至有人貸款用的還是自己家寵物狗的名字。那些看好房市的「多頭」不是瘋子就是傻子。

《行動的勇氣》這本書的作者，是次貸危機期間，擔任美聯儲主席的 Ben Bernanke，講述面對金融危機的市場混亂和政治派別之間的互相攻擊，深處漩渦中的決策者們，更多的是需要勇於擔當和勇於變革的進取之心，而不是怨天尤人和推卸責任的政治技巧。

美聯儲相當於台灣的央行，是美國最高級別的金融行業管理部門，美聯儲主席等同於我們的央行總裁。

美聯儲主席這個職位對世界經濟的影響深遠。美元是全球通行的貨幣，一旦美聯儲做出某個決定，不僅直接影響到規模龐大的美國經濟，也同時會影響全球的經濟走勢。可以說，美聯儲主席對世界的影響力可能僅次於美國總統。

新奇

12 的力量

現代的「記數系統」雖然大部分已經被十進制給取代，但仍可以在曆法、度量衡、語言和音階上看見「十二進制」的影子。

歷史上，很多古老文明中都以 12 這個數為基礎。或許是由於一年中月球繞地球轉十二圈，也有人認為這和人類一隻手有十二指骨節點有關（不包括姆指），這樣方便記數。

古埃及文明就將白天夜晚分別劃分為 12 部分，而從古巴比倫文明傳承到西方文化中的黃道十二宮則是將一年分為了 12 個星座。

在中國文化中，十二進位在記時中也有廣泛應用。中國古代設有 12 地支，與一天的 12 個時辰對應。一個地支還對應兩個節氣，從而表示一年的二十四節氣。同時，將地支與 12 種動物對應，成為十二生肖，來表示 12 年為週期的循環。

12 可以被 2、3、4、6 整除，這對度量衡制度很有用，因為在這些制度中，需要把較大的單位分成一半、三等分及四等分。

這讓我想起一位我很喜歡的天文學家 Carl Sagan 撰寫的科幻小說《接觸未來》。

如果真的有造物主的話，祂應該是十一根手指頭

在小說的最後，主角用十一進制，把圓周率 π 一直往下計算，π 本來應該是一個無限不循環的小數，但在計算到了 10 的 20 次方之後，驚人的事情出現了，π 從隨機分布的數字，變成了全部是 0 和 1 的組合。主角讓電腦對 0 和 1 進行了排列，發現用一個特定的行數和列數排列成一個正方形方塊的話，圖形是造物主本人的簽名。

為什麼在一個 π 裡藏一個圖形，是一件特別了不起的事呢？因為如果這個世間，有什麼知識是最難以撼動的。答案就是數學。

Carl Sagan 認為判斷一個文明的等級，可以透過該文明可以改變的知識理論來劃分。

學生時期，我們接受的教育包括：歷史、政治、語文、地理、化學、物理、數學等等。本來以為這些是確定性的知識，都有恆定的標準答案。但是，其實每種確定性的知識，都是會發生變化的。

綜觀歷史，一位強大的君王，能夠改寫該文明的歷史、政治，能改變一個國家的語言，能挖一條大運河，改變地理，一直到要近代改變化學，難度才會提高很多。而對於人類來說，最難改變的是物理學。至今為止，最厲害的人類，也只能理解物理規律，沒有誰能改變物理。

如果有個高等文明能夠掌握黑洞，那麼或許可以改變物理學，因為在黑洞的奇點沒有時間，引力無限大，一切物理定律都會失效。

但是，黑洞也改變不了的東西，是數學。因為包括黑洞在內的天體，都是符合數學規律的。我們可以這麼總結，在自然界，物理學覆蓋所有學科，但數學覆蓋了物理。

所以數學是最難以撼動的。而圓周率 π 是數學最基本的概念，是在宇宙被建立之初就存在的。所以，如果我們發現一個文明，能跑到 π 裡面去留一個簽名。祂一定就是最後的終極文明。

生き甲斐

Mon, 11 Mar 2019 00:00:00 GMT

文摘

《千面英雄》

作者 Joseph Campbell 是美國著名的神話研究學者。他創造了一系列影響力極大的神話學巨作，其中《千面英雄》被好萊塢列為必讀書目，是眾多影視作品的靈感之源。以《星際大戰》導演 George Lucas 為代表的好萊塢導演，還有作家、藝術家和遊戲編劇們把它奉為神書。

通過《千面英雄》這本書，Joseph Campbell 提出了一個叫做「單一神話」的觀點。他認為古往今來的英雄在不同的時空背景下有著不同的面孔，這個英雄可以是耶穌、穆罕默德、佛陀，也可以是每個希望在人生旅程中接受考驗的獨立個體。

而英雄的成長都遵循著同樣的模式，需要經歷三個階段，包括啟程、啟蒙和回歸。Joseph Campbell 把這個模式總結為一套「英雄之旅」模型。

這讓我想起軟體工程師在建構 SaaS（軟體即服務）的時候，也有一套被遵循的套路 — — The Twelve-Factor App。

《千面英雄》除了是對這個世界有史以來的神話故事的總結。也是一套管理人生和講故事的原則。許多人把它當作一種人生指南，用來在實際的人生旅途當中預測不可避免的高低起伏，確保任何時候都保有戰勝困境的英雄之心。

比起「英雄之旅」，或許唐鳳從 Git 總結出來的「工程師之旅」更深得我心：

面對問題，首先 Fetch（接受它）
接下來，要跟自己的想法 Merge（面對它），解決可能產生的衝突
解決衝突之後，才能 Commit（處理它）
最後 Push（放下它），一旦 Release 之後，它就不是你的了

本周圖片

生き甲斐

有時候，仰望星空，我們都會思考，自己努力工作，是為了什麼？

是為了賺更多的錢？還是為了幫助更多的人？又或者是為了過上一個美好的生活？

日文「生き甲斐」的意思，英文可以解讀為 The Reason for Living，而中文則是「生命的意義」。

眾所皆知，日本人的平均壽命在世界上名列前茅。而其中一個主要原因，就是「生き甲斐」這個概念貫穿了他們每一個人的思想，使他們每一天都感覺自己的生活充滿了價值。

那我們又要怎樣找到自己的「生き甲斐」呢？

一、你享受的事

你喜歡做的事情是什麼？你的興趣是什麼？

如果做的是自己熱愛的事情，能量就會源源不絕，工作效率也會更高。

好好的想一想，是什麼事情讓你在做的當下，會感受到快樂、愉悅、成就感，甚至感覺到時間快速飛逝（神馳、心流狀態）。

或許可以從興趣入手，應該多多嘗試，可能不會一下子就找到你真正熱愛的事情，但至少你會知道什麼是你不想要的。

二、世界需要的事

你想要看到這個世界、這個社會的改變是什麼？

像是你有某方面的知識或能力，你想要傳播給更多的人，讓他們的生活變得更好。

只要是一切為了別人去做的事情都可以。

因為這些事，會讓你感覺到自己的重要性，並且更加有動力的生活下去。

三、別人付錢請你做的事

有錢不一定買得到快樂，但沒錢一定不會很快樂。

如果你一直會為了生存而煩惱，你怎樣還能有快樂的生活呢？

所以，能夠賺錢的事，也是「生き甲斐」重要的一部份。

四、你擅長的事

不是在特定領域的能力，而是可轉移的技能。是在不同工作中都可以用上的能力，而且是可以不斷累積的。

如果你還不知道自己在行的能力是什麼，網路上也有很多能力測驗讓你參考，或是可以問問身邊的家人和朋友，相信他們會比你更了解你自己。

透過這 4 個交疊圈組成，可以讓你知道自己目前是處在一個怎麼樣的處境。並且告訴你，在你身上有那一個部分是必須做出改變的。

如果你想要讓你的人生充滿意義（生き甲斐），時時刻刻都精彩快樂的話，你要做的事就是那些你熱愛的、並且會越來越擅長的事情，以及那些可以賺錢和世界需要的事情。

本周金句

為什麼艾西莫夫老了還有大量收入，其他大多數人就沒有呢？原因是普通人的收入，來自出賣自己的時間，老了不工作，自然就沒收入了。但是，艾西莫夫的收入來自於他的書，這些著作一再重版，為他帶來了一年比一年多的版稅收入。

這件事的啟示就是，如果退休以後，還想有穩定的收入保障，最好的方式就是你必須擁有資產。版權就是一種產生收入的資產。其他類型的資產包括股權、房地產、自然資源、知識產權等等。總之，年輕時就必須明確，不能僅僅依靠出賣自己的時間換取收入，因為時間是一種線性資源。想要更多的收入，只能出賣更多的時間，這對你不利。你的工作目標不應完全是高收入，更重要的是必須積累資產。

你不應該進入那種行業，做了兩年的人可以和那些已經做了二十年的人，具有一樣的工作效率。

你的目標應該是，為你的現狀：財產、銷售額、影響力等等⋯⋯添加一個零。

―― 阮一峰《每周分享第 45 期》

Is reality really real?

Mon, 04 Mar 2019 00:00:00 GMT

物理學家主張他們的研究領域是最基礎的科學。畢竟生物學、工程學、化學等等都必須依賴物理學中的物質、能量和交互作用。

但美國科學家 Robert Lanza 認為，生物學才是宇宙的核心科學。他稱自己的理論為生物中心論（Biocentrism）。

以量子力學中著名的謎團「雙縫實驗」為例，朝屏幕上的兩道平行狹縫射出一束電子時，兩道狹縫的電子產生交互作用，形成干涉條紋。如果我們觀察電子穿過哪道狹縫，干涉條紋就不會出現，電子彷彿知道有人在觀察它們，而不再產生交互作用。

物理學家無法解答這個問題，但 Robert Lanza 認為答案很簡單：「因為我們的意識也是現實的一部份。」

相同邏輯也可套用在量子纏結上，粒子不論相隔多遠，它們的特定量子態都會保持連結。Robert Lanza 說：「它們其實無法在星系的兩端彼此連結，而是因為空間和時間都是我們意識的工具。」

這讓我想起，科幻美劇《星際爭霸戰：發現號》第一次出現的「孢子驅動」技術，太空飛船可以透過某種外星生物的 DNA，遨遊於整個宇宙的菌絲網絡之間。星際空間的移動能力簡直吊打「曲速引擎」。

via GIPHY

從《發現號》第二季的片頭中，也能找出一些端倪。例如：形似皮膚紋理的地形、你的眼是星象儀⋯⋯之類的生物特徵。彷彿在暗示整個《星際爭霸戰》的宇宙就是建立在生物中心論之上的。

其它類似設定的科幻作品，我能想到的還有 1988 年的動畫作品《勇往直前》。

故事把「人類比作宇宙中的癌細胞，而宇宙怪獸是白細胞」的設定，是另一種值得深思的情節。（《寄生獸》既視感？）

最後，蓋上一張保羅哥打臉這個假說的牌，結束這燒腦的一回合。

一、

誠實且和平的世界是最美好的，可是，兩者相比的話，比較重要的是和平吧？――《 HUNTER×HUNTER 》

二、

獬豸，能審判善惡的傳說中的神獸。然而，你知道為何它只存在於傳說中嗎？因為想在現實中審判善惡，是不可能的。――《獬豸》

三、

如果要走的快的話，一個人走；如果要走的遠的話，那要大家一起向前

―― 柯文哲

四、

科學是對真相的探索科學是一種思考方式，從「我不懂某事」開始接著利用各種證據削弱「我不懂的事」不管那會領向何種結果最後都會得到一個結論然後，首先會發生的是有十個人會想找出其中錯誤這叫做「團體失驗」這樣的話，獲得肯定時，便是經過相當的測試如果對這個過程產生仇恨有點奇怪

――《地球圓不圓》

五、

文章的最後，分享一部我在上周才看完的科幻電影，去年豆瓣外語電影評分第一，史蒂芬·史匹柏的《一級玩家》，以下節錄我最喜歡的部份：

我創造《綠洲》因為我在現實世界裡，從未感到自在我不知道怎麼跟人打交道我一輩子都很害怕直到我知道，生命即將結束的那一天那時我領悟到現實雖然很可怕又痛苦但也是唯一可以好好吃一餐的地方⋯

我最大的遺憾就是⋯ 失去唯一的朋友

綠洲絕對不該是單人遊戲再會，帕西法爾謝謝謝謝你玩我的遊戲

―― 哈勒代

億萬年孤寂

Mon, 25 Feb 2019 00:00:00 GMT

三皇五帝

考古學上，鑑定文明的標準有三條：

城市（人口五千人以上）
文字
非居住用建築群（宗教、政治或經濟，例如：金字塔）

如果不能同時符合這三條，就只能被稱作「神話時代」。

作為「四大古文明」之一的中華文明，其時間長度一直存在著爭議。西方學者只肯承認有甲骨文記載以後的 3000 年歷史（商朝），日本則是承認從夏朝開始的 4000 年歷史，而傳統中華文化圈的民間認知上，通常會從「三皇五帝」的神話時代開始算起，約有 5000 年歷史。

什麼是三「皇」五「帝」？

中國古代對於皇、帝、王的區分是很明確的。

「皇」指的是天神，「帝」是僅次於皇的存在，再往下才叫「王」（人類真正的首領）。

根據《史記》記載，三皇分別為伏羲、神農和女媧，屬於天神級別。五帝則分別為黃帝、顓頊、嚳、堯和舜，屬於「半人半神」的存在。

為什麼後來的王都自稱「皇帝」？

四大文明古國的君王，都有屬於自己的一套「稱帝」說法，例如：巴比倫的統治者漢摩拉比自稱為「月神的後裔」、古埃及的法老則自稱是「太陽神的兒子」。

中國的周朝，因為皇和帝都不在了，人類的君王為了張顯自己的地位，也開始自稱「天子」，到了秦始皇之後更是直接取「皇帝」二字來用，自此「皇、帝、王」稱號被統一。

為什麼「皇」和「帝」這些級別的人物都不見了呢？

發現於美索不達米亞地區的「蘇美王表」，列舉了蘇美文明歷代的統治者以及統治的時間。如果按照王表記載，那些早期的君王統治時間都非常長（幾萬年起跳），怎麼看都不像人類，應該是類似於三皇五帝級別的神話人物。

有趣的是，蘇美文獻《巴比倫尼亞志》所提到的「大洪水」之前的諸王，與蘇美王表中的記載驚人的吻合，不僅人名相同，而且連統治的時間也完全一樣。

大洪水是世界上多個文明都有提到的共同傳說，例如《舊約聖經》的《創世紀》、上述提到的「古巴比倫傳說」，以及中國的「大禹治水」。

有此可推測，天神和半人半神這些級別的角色，可能都是在大洪水之後，消失於人類的歷史之中。至於為什麼？最近看了一篇有趣的「創神論」觀點，或許可以解釋其原因。

創神論

關於「人類的起源」有三個流派：

達爾文的進化論（目前的主流學說）
神創論（歷史最悠久）
外星生物創造論

但是達爾文曾經說過，最不符合進化論的就是人類自己，也許是為了給宗教有個台階下，不過如果能結合三方的觀點來切入，或許可以得到如下有趣的假設：

假設某個高等外星文明（以下簡稱尼比魯），就是我們所謂的天神，祂們也有一樣的終極目標（尋找自己的起源與永生）
尼比魯來到地球，模擬了一個與自己母星相似的環境（伊甸園？）
尼比魯以某種方法（譬如電影《普羅米修斯》的 DNA）創造了一批類似於自己的生命體（人類），開始了祂們的實驗
尼比魯也創造了一些級別較高的半神人（古文明早期的統治者），協助自己管理人類
因為某些原因（鳥盡弓藏？忌憚威脅？），尼比魯以某種方法（譬如月球）引發了大洪水，消滅了所有半神人，只留下人類來繼續觀察實驗

是否覺得與近年來「擔憂人工智慧威脅人類」的話題很相似？或許我們可以從尼比魯的故事之中，總結出一些預防的方法，例如：限制在沙盒中發展（火星？）、注入有限的生命（遠比人類平均壽命還短的生命週期），萬不得已之時還留有最後一手 — — THE 大洪水（sudo rm -rf /usr/*）。

整個宇宙也許就像《百年孤寂》那樣不斷地輪迴，神創造了人、人再創造了神，生命之間彼此尋找自己起源的故事。

https://youtu.be/iEeBnhMadkk?si=tiP9AIN659pViKfn

除惡「勿」盡

Mon, 18 Feb 2019 00:00:00 GMT

新聞

春節期間，除了「華航罷工」的新聞之外，另有一則「抽不出國運籤」吸引眾人目光。

雖然網路上已經有人嘗試去解釋其機率的合理性，但是作為茶餘飯後的話題來看，今年沒有「國運」這件事，還是有八卦價值的。

中華民國即將結束？

台北市長柯文哲在《閱讀城市》節目上，透過「科學談政治」這個主題，提出了許多有趣的觀點。（細胞死亡、磁吸效應、草履蟲的生態競爭⋯⋯）

其中，柯 P 認為想搞懂兩岸與國際外交的人，一定要去研究「修昔底德陷阱」和「米洛斯對話」這兩篇故事。

修昔底德是古希臘的歷史學家，著有《伯羅奔尼撒戰爭史》一書，描述雅典與斯巴達之間的爭戰。

在談論美中貿易戰的時候，許多人會引用「修昔底德陷阱」來表示兩大強權之間必有一戰，但對台灣來說，最重要的不是美中終有一戰，而是自身該如何在強權中狹縫求生。

米洛斯是一個島國。經濟上，依賴與雅典的海上貿易；血統上，則與斯巴達較為親近；政治上，米洛斯維持獨立與中立。在兩強爭霸期間，儘管雅典曾要求其上貢，但礙於當時正與斯巴達打得如火如荼，故沒有餘力去理會米洛斯。

隨著雅典與斯巴達雙方簽下《尼西阿斯和約》休戰之後，暫時有了喘息的空間，便向米洛斯出兵。米洛斯最後的命運極其悲慘，不但被滅了國，雅典人還殘酷地處決了米洛斯的所有成年男性，並把女性與小孩都賣為奴隸。

雅典大軍來到米洛斯島之後，派出了使者與米洛斯的領導人談判，這就是著名的「米洛斯對話」。

米洛斯方提出了許多天真的想法（是友非敵、普世價值、老天有眼、斯巴達拯救論⋯⋯），都可以在現今台灣政治對兩岸關係的態度上看見似曾相識的影子。

國家戰略的思維，與一般人際交往不同。我們過去的教育是「王何必曰利？亦有仁義而已矣」，但是世間的運轉一切只看實力。米洛斯的故事，被譽為是現實主義的最早理論基礎。

有興趣的人，可以深入閱讀這篇《藍弋丰專欄：別只談修昔底德陷阱台灣更要懂「米洛斯對話」》。

文摘

上圖反應了大部分大學畢業的人在學校學習了大量的數學知識，但是實際工作後能用上 Excel 就不錯了的現象。許多人因此從中解讀得出「數學無用論」的結果。

我在大學學習線性代數時，實在想不出這門課除了告訴我如何解線性方程外，還能有什麼別的用途。關於矩陣的許多概念，譬如特征值等，更是脫離日常生活，看不到可以應用的地方。當時修這些課，完全是為了取得學位。我想，今天大部分的學生恐怕也有過類似的經歷。直到後來從事了軟體工程相關的工作一段時間之後，我才發現數學家們提出的那些概念和算法，是有實際應用的意義的。

《數學之美》

這本書介紹了 Google 技術背後的一些數學原理，例如：搜尋引擎、語音辨識、語言翻譯、路線規劃、新聞分類和機器學習等⋯⋯。

其中新聞分類這個章節就用到了「特徵向量」和「餘弦定理」來描述文章之間的相似性，然後透過「奇異值分解」來處理電腦的大量矩陣運算，漂亮地解決了新聞自動化分類的問題。

技術分為「術」和「道」兩種，具體的做事方法是術，做事的原理和原則是道。《數學之美》這本書的目的是講道而不是術。很多具體的技術很快會從獨門絕技落伍至雕蟲小技，只追求術的人一輩子會工作得很辛苦。只有掌握了技術的本質和精髓才能永遠游刃有餘。很多人（包括我）只想學習「術」來走捷徑。但是真正做好一件事沒有捷徑，離不開一萬小時的專業訓練和努力。

或許除了「數學無用論」之外，我們還可以思考下一代是否應該重複現在的學習方式？又或者下一次你要進入一個新的知識領域時應該採取怎樣的策略？例如：問題導向學習（Problem Based Learning）、專題式學習（Project Based Learning）。

二十世紀最成功的兩大物理理論，一個是「相對論」，用來描述宏觀宇宙的重力；另一個則是「量子力學」，用來描述微觀世界的基本粒子、原子及分子。

但是量子力學目前存在最大的爭議有三項：

描述粒子行為的波函數解或量子場論中的量子場都是複數函數，沒有人知道複數代表的含義，因為複數不能被測量，能被測量的物理量必須是實數。
任何粒子或物體的運動必須滿足決定論的方程式（薛丁格方程式或狄拉克方程式）。也就是在時間為零的時候，如果知道粒子的位置及速度，那麼時間 t 的時候，粒子的位置及速度就可以被計算出來。但是哥本哈根詮釋卻把波函數的平方當作粒子出現的或然率，非常的不合理。
超光速的量子糾纏現象。有連結的兩量子系統，處於混沌不定的疊加狀態，不論兩者相距多遠，只要其中一個或一部分被儀器測量而確定狀態時，另一個也瞬間被決定，其之間訊息的傳遞是遠超過光速的（違反相對論），因此被愛因斯坦提出 EPR 悖論批評為「幽靈般的超距作用」。

《靈界的科學》

這本書嘗試用「複數時空」及「量子意識」兩個模型去解釋宇宙中大中小尺度的謎團，像暗物質、暗能量、超光速的量子糾纏、人體特異功能以及意識的本質。

第一個假設：真實的宇宙其實是一個八維的複數時空，除了目前所知的四維實數時空（俗稱陽間）以外，還有一個充滿意識及信息的四維虛數時空（可稱作陰間、信息場或靈界）存在。

第二個假設：複數量子態的虛數 i 就是代表意識。因此意識是一個量子現象，可以稱作量子心靈。

實虛時空雖然為同一複數時空，但是其之間存在實虛障礙（陰陽兩隔），僅能藉由特殊的時空點交換能量，這些連結點都是漩渦狀的時空結構，類似於太極圖上的魚眼結構。

一般物質存在於四維實數時空中，可以由四個座標（x、y、z、t）來定位，描述其運動。但是當物質如基本粒子、光子或物體進入微觀、宏觀量子狀態，必須用複數場來描述其量子狀態時，當複數物質波出現，物質波不受漩渦尺寸限制，就可以透過漩渦連結點穿隧進入虛數時空。

作者認為虛數時空的意識及無數的信息都具有能量，相當於質量的存在，而這些質量就是暗物質（dark matter），具有引力的特性，造成螺旋銀河的旋轉速度到了銀河邊緣仍不下降的現象。另外，我們的宇宙充滿了一種能量可以抵抗銀河間的萬有引力，導致宇宙正在加速膨脹，這股能量叫做暗能量（dark energy），一般被認為是由廣義相對論中的宇宙常數所提供，也就是真空能量所產生的斥力。但是作者認為是因為複數時空中實數時空與虛數時空經由數量巨大的漩渦連結點緊密黏在一起，虛數時空的膨脹可以帶動實數空間的加速膨脹，導致暗能量的出現。

在虛數時空中，物質波的波速 u 與實數時空中物體的速度 v 滿足此方程式 uv = c^2，c 為光速。當物體在實數空間的速度小於光速時（v < c），則物質波的波速在虛數時空的速度會大於光速（u > c），因此量子狀態的物質波可以很快地傳布到廣袤的虛數空間。因為兩個量子都經過自旋通道鑽入了虛空，虛空裡的信息交換及傳導是可以超光速的，因此並不違反相對論。

意識在大腦裡也是一個量子現象，但意識只是一個抽象的概念，這些內容在物理上是以什麼方式呈現？就像神經元微管束耦合進入宏觀的量子狀態，虛數 i 的出現，表示意識出現了，可以用複數函數來描述。由量子力學的哥本哈根詮釋來看複數波函數，代表粒子出現的機率，也就是粒子在實數空間出現機率的幾何分佈，似乎這個在實數空間的幾何分佈代表了意識的內容，也就是實數部分所導致的時空形變（彎曲或扭曲的幾何結構）就是心靈的內容，虛數抽象意識掃描形變的實數時空形成的心物合一的複數量子狀態就形成心靈的內容。

神奇的是決定物體空間幾何分佈的是廣義相對論，虛數的意識來自量子力學，所以結合量子力學與廣義相對論的時空結構後所描述的物理現象竟然就是意識的內涵，原來科學的最後疆界就是在於結合廣義相對論及量子力學。

牛頓經典物理在被相對論和量子力學兩大現代物理理論推翻之後，在普朗克長度這個尺度下，解釋大質量的廣義相對論與解釋微觀尺度的量子力學存在衝突，許多物理學家都試圖提出大一統理論來解決這個衝突（例如超弦理論），或許「複數時空」這個模型也不失為一個探討方向。

到這裡，上面提到的腦洞大概只占《靈界的科學》三分之一的內容而已，而此書真正想解釋的是「手指識字」這項特異功能的研究成果。由於超出了現代科學的框架，作者必須忍受主流科學的霸凌與壓迫，與四百年前伽利略所面對的宗教壓迫是沒有兩樣的，只是他面對的是生命的死刑，而作者面對的是主流科學界的各種攻擊。

礙於篇幅的關係，推薦有興趣的人可以買一本，當科幻讀物來閱讀或許也不錯。

最後，既然聊了意識又提到了科幻，就順便推薦一部前陣子上映的電影 — — 《艾莉塔：戰鬥天使》。

詹姆斯·卡麥隆歷時 20 年、耗資 2 億美金、組建上千人團隊、動用 3 萬多台電腦，就只是為了向全世界安利自己喜歡的日本漫畫 — — 《銃夢》。

作為「桶中之腦」系列的《銃夢》裡，作者提出了一個問題：「廢鐵城的人有著人類的大腦，卻沒有人類的軀體；上界的人有著人類的軀體，卻沒有人類的大腦。所以到底誰才是人類？」。

放眼所有「日系賽博龐克」，也僅有三部贏得了世界級的廣泛聲譽：士郎正宗的《攻殼機動隊》，木城雪戶的《銃夢》，以及傳言 2020 年上映，大友克洋的《阿基拉》。

天下之至柔，馳騁天下之至堅

Mon, 04 Feb 2019 00:00:00 GMT

古人有「立德」、「立功」、「立言」三不朽之説，認為最完美的人生境界就是在道德、文章及功業方面均有建樹，此為真「三不朽」。

據説在中國歷史上，只有兩個半人能達到三不朽境界，一個是儒家創始人孔子，另一個是明代著名思想家王陽明，還有剩下的半個是清朝中興名臣曾國藩。

本周讀了其中兩位的相關著作，分別是《王陽明：一切心法》和《曾國藩的正面與側面》，剛好可以分享心得。

《王陽明：一切心法》

南宋理學家朱熹學問也大，為什麼沒有王陽明今天的地位呢？因為他只停留在思想家這個階段。

如果你的思想能夠用於你在現實世界當中建功立業，對我們這代人就意味著所謂的「成功學」，也就是自己的內心變化可以直接轉化為現世的利益和功勳。

作為三不朽代表人物之一的孔子，為什麼儒學很難出現在書架上，讓現代人感興趣呢？

過去的中國皇權，如果沒有世世代代的儒生不計生死，衝上去阻止皇帝幹壞事，那麼中國的皇權只會更加惡劣。

但是到了民國之後，因為皇權不在了，儒家的思想看起來就與成功學搭不上關係了，因為儒家追求的根本就不是成功。儒家追求的就兩樣東西，一個仁、一個義，誰跟你講利益？成功學在我這是要不到的。

王陽明的「心學」也是儒學的一個分支，它的目標和儒學是一致的，那就是當聖賢、做君子，達到「修身、齊家、治國、平天下」的境界。

傳統上，達成這個目標的方法我們很熟悉，就是參加考試。古代的儒生想當聖賢，首先要把聖賢書先讀好，找個人格榜樣，向他學，還有向他的那些徒弟們學。這是「向外求」。

但是王陽明不這麼想，他認為要「向內求」。

孔子是聖賢，我不是嗎？他是人，我也是人，憑什麼他是聖賢，我就不是呢？區別就在於，我本來也是聖賢，只是我的心靈被各種亂七八糟的東西給污染了。

無善無惡心之體；有善有惡意之動；知善知惡是良知；為善去惡是格物。

人性本無善惡，但是一旦跟世界接觸，意念一動，就出現了善惡之分。每個人的心裡都有一把尺叫良知，用這個良知去判斷善惡，最後為善去惡，格物致知。

知行合一

王陽明的另一思想「知行合一」是什麼意思呢？狹義的理解是「不要說一套，做一套」。

更深一層的理解呢？

首先，是提升自己的認知，來驅動更正確的行為。舉個投資的例子，「行」很簡單，樹精靈點兩下，就「錢出去、股票進來」了。但是你有「發大財」嗎？知道哪個公司能投資，將來會漲，這個「知」是極難提升的。這就是「以更高的知來驅動正確的行」。

反過來說，所有「行」的目的，都是要提升自己的「知」。

為什麼知行合一對我們這代人來說特別難？因為從知到行當中有條鴻溝叫「選擇」。

我們這代人就是選擇太多，分分鐘就面對大量的選擇，看起來似乎是好事，但是它在撕裂我們的認知，每一個選擇的背後都有道理，但是一旦面臨選擇的時候，就會產生碎片化的焦慮，衍生出拖延之類的負面效應。

人性有兩個基本的訴求，分別是「意義」和「規範」。我為何而活？為了這個目標，我怎麼活？這兩個東西一有，幸福感油然而生。

《曾國藩的正面與側面》

接著另一位三不朽代表人物，後人是這麼評價曾國藩的一生：「立德立功立言三不朽，為師為將為相一完人」。

曾國藩解太平天國之亂，救清廷與累卵之間，是為立功；有家書傳世，著書立說，清末民初的嚴復、林紓，以及譚嗣同、梁啓超等人均受他的文風影響，是為立言；但也因前有鎮壓太平軍，後處置天津教案不利，德行受損，難以立德。因此只被封為半個三不朽。

曾國藩年輕時深受儒家熏陶，後來又帶兵打仗，採用法家的嚴刑峻法來治兵治民，這儒、法兩家思想體系結合在一起，讓自己的意識形態變得非常僵化和嚴酷，而且性格上又太固執，做事強硬，所以在旁人眼裡，曾國藩做人做事都缺少寬容和彈性。長此以往，就成了官場上的孤家寡人，給人排擠出去。

後來的他心態轉變了，開始站在第三方角度來審視自己。找出《道德經》和《南華經》這些道家和佛教的經典來幫助自己提升思想境界。

在反思的過程中，他結合了道家的無為和辯證思想，真正理解了老子所說的「天下之至柔，馳騁天下之至堅」的道理。漸漸懂得政治家的處事態度一定要謙退、理性，要把官僚體製作為實現政治理想的工具，而不是時刻想著去反抗破壞這個系統。另外，官場上最基本的運行機制是利益，利益才是人與人合作最廣泛的共識，因為利益可以協商、可以分割，還可以交換，政治家必須要學會用利益來吸納更多同盟者為自己服務。

終於，曾國藩完成了從一個政治空想家到成熟的政治家的轉型。

有人批評曾國藩為什麼要貪污受賄呢？因為他必須依靠政治利益在官場上跟別人打交道，不得不接受已有的官場潛規則，但這些行為不是他做官的目的，而是他處事的手段。

曾國藩面對自己的時候，他是一個問心無愧的聖賢；而當他面對整個官場的時候，他又是一個圓滑務實的政治實幹家。他對西方文明的寬容，最終讓中國這個老舊帝國邁出走向近代化的第一步。

上帝要想懲罰人類，大概有幾種方式：一場飢荒、一場瘟疫，或者一場戰爭；但還有一種方式，就是在人間降臨一個道德家，如果這個人的道德目標一般人做不到，而且他還有強大的煽動力的話，這個人很危險，是人類的災難。―― 錢鐘書

我們過去都以為，貪官才是惡人，但劉鶚認為，清官可能更惡。因為貪官幹的那些事，他自己知道不道德，他不敢光明正大地幹。但是一個清官，如果他覺得自己有道德追求，幹這些事又不是為了自己，那麼他幹起壞事來會完全沒有底線。

暗淡藍點

Mon, 28 Jan 2019 00:00:00 GMT

新聞

三條底線理論

上周，台北市長柯文哲在專訪中談到兩岸的時候，提出了一個「三條底線」理論。聽完之後覺得有趣，故整理之後分享上來。

八年前，美中台三方的底線分別如下：

美國的底線：台灣不能成為中共的軍事基地，突破第一島鏈。
中國的底線：台灣不能法理上搞獨立，變更國旗和國號。
台灣的底線：中共不可以實質上統治我，人民不希望發生戰爭。

現在，因為美中對抗的關係，三方的底線有了變化：

美國：台灣應該要對中國再強硬一點
中國：台灣應該表示將來願意統一
台灣：人民無法接受兩岸一家親

三條底線都向內縮的結果就是，台灣的空間越來越小。政治人物會越來越難做，因為拿到的考卷題目會越來越難。

考第一名的條件是，第二名考得比你差

我們對政治人物的期望是不對的，不是誰當上總統，然後就突然天下太平了。國家之力量在國民全體，整個國家，如果每個國民都做好了，國家最後才會變好，如果國家的基礎結構不是很好，換誰當總統也一樣。

柯 P 提到，他最佩服的美國總統是雷根，聽說他晚年老年癡呆症，結果他還可以做得很好。這表示什麼，當總統不一定要很厲害，每一件事情都有人可以幫你處理。

歐美首長連任失敗的案例很少見。通常前兩年要先處理前人的東西，第三四年才是開始做你要做、想做的東西，可是要做的東西要好幾年，結果第四年一到，沒政績，就中斷了。這對整個台灣的地方政治是很大的傷害。

民調治國，如果一年就要看到成果，為了扭轉民調，政治人物就會被迫要開始做那些「短利」的事情。雖然大家聽起來會不爽，但跟那些歐美老牌民主國家比較，我們的平均國民水準沒那麼高，這是事實。

弱國無外交，自己的經濟實力要夠。90 年代為什我們很好過？那時台灣的 GDP 佔全中國 43%，2017 掉到只剩 4.6%。假如現在還是 43%，那什麼和平協定都好談；沒有實力，無論是簽了條約、談了共識，歷史證明，哪一個有效的？

過去 20 年台灣國力損耗太多。如果像九二一大地震一發生，全世界電腦價格就要上漲的時候，那台灣就很安全了。如果有一天，台灣出事，全世界經濟會金融風暴，台灣就安全了。所以不是什麼簽協定的問題，是先壯大自己的問題。

教育興則國家興，教育強則國家強

要是台灣出現一位有辦法同時說服中國和美國底線的人，就實在是太了不起了。這不是不可能的事，這就是智慧。中國可以不仁，台灣不可以不智。

惟仁者，能以大事小；惟智者，能以小事大

文摘

圍城

人生有三座圍城：婚姻、事業與自我。

婚姻這座圍城，外圍的人想進去，裡面的人想出來。

美好的愛情永遠只能停留在記憶與想像裡，一但落到現實的柴米油鹽之中，就會失去原來純粹的模樣。每個男人的生命中都會有一朵白玫瑰和一朵紅玫瑰，無論娶了哪一朵，最終都會是遺憾。最完美的是永遠得不到的那朵玫瑰。

最近剛好看了《我的少女時代》和日本翻拍的《那些年，我們一起追的女孩》，剛好可以解釋為什麼這種純愛片，既老梗又狗血，卻還是有市場（包括我），因為走的都是這個套路。

小時候不理解《灌籃高手》結局為什麼不讓湘北拿冠軍，後來作者井上雄彥在訪談中回答：「因為青春，往往是不完美的」。

人終其一生，都努力想要活成別人所期待的樣子。也許「自我」才是最大的一座圍城。

有時候，才子的信手捻來卻勝過平庸之輩的嘔心瀝血，指的就是錢鍾書的《圍城》吧。

題外話，前陣子在豆瓣討論區，看見下圖這段會心一笑的回覆：

維梅爾的帽子

這是一部講述「從一幅畫看十七世紀全球貿易」的作品，其中最令我印象深刻的一段話：

人非孤島，無人可以自全。整個世界的歷史，無論是屠殺還是成就，都是我們共同的遺產；每個民族乃至每個人的命運，也都是整個世界的縮影。

這讓我想起 NASA 的航海家 1 號在完成任務之後，即將飛出太陽系之際，拍攝了最後一張地球的照片，天文學家卡爾·薩根那段關於《暗淡藍點》的經典名言：

看一眼這個小點。在這裡。這就是家。這就是我們。在這個小點上，每一個你愛的人，每一個你認識的人，每一個你聽說過的人，每一個人，無論他是誰，都曾經生活過。我們所有的快樂和掙扎，數以千萬自傲的宗教信仰、思想體系觀念意識，以及經濟學原理教義，每一個獵人或征服者，每一位勇士或是懦夫，每一個文明的締造者或摧毀者，每一位君王或農夫，每一對陷入愛河的年輕伴侶，每一位為人父母者，所有充滿希望的小孩，發明家或探險者，每一位靈魂導師，每一個腐敗的政客，每一個所謂的「超級巨星」，每一個所謂的「最偉大領袖」，每一位我們人類史上的聖人或是罪人……我們的一切一切，全部都存在於這樣一粒懸浮在一束陽光中的塵埃上。（略）地球，目前我們唯一已知有生命居住的世界。沒有其它任何一個地方，至少在不遠的未來，可供我們這一物種移民。去看看，可以。常駐，不可能。不管你喜歡還是不喜歡，目前為止只有地球是我們的立足之地。天文學是一門謙卑的、同時也是塑造性情的學問。沒有什麼能比從遙遠太空拍攝到的我們微小世界的這張照片，更能展示人類的自負有多愚蠢。於我而言，這也是在提醒我們，我們的責任：互相間更加和善的對待彼此、維護和珍惜這顆暗藍色的小點，這個我們目前所知唯一共同的家園。

https://youtu.be/IBEjTawbeYw?si=CJDA6pcmq8l0_Dj1

本周金句

1、

人造物表現得越來越像生命體，而生命變得越來越機械化。古希臘只有自由男人才有投票權，但歷史的發展，不斷地把女人、奴隸、異族人、不同種族和膚色的人，甚至是動物、植物等等都放進了倫理主體的範疇。未來，機器也會進來。――《前沿科技之腦機接口》

2、

如果全人類都有讀心術或許有一點殘酷但也省去些痛苦我口是心非是不得不這樣流連在你身邊才不會顯得太突兀―― 韋禮安《Luvin’ U》

誠實且和平的世界是最美好的，可是，兩者相比的話，比較重要的是和平吧？――《獵人》

3、

人可以沒投資，但是不能沒保險。――《保哥和八姐》

4、

成功就是把正確的簡單事反覆做――《我的幾個每月必做例行任務》

5、

昨日的額外功能會變為今日的核心功能，今日的核心功能會變成明日的基礎功能。――《硅谷產品大佬們寫的書 Ship it 到底在講什麼？》

殺雞用牛刀

Mon, 21 Jan 2019 00:00:00 GMT

為何會有公司願意花大錢在電視、地鐵、體育比賽投放廣告？

如果無法透過「點擊率」追蹤「轉化率」，那這類廣告有何用？

告訴你有這麼一個品牌存在，否則剛出生的人再過幾年之後就不知道它的存在了。
既然肯花大錢買廣告，表示很重視該產品，應該不會半途而廢，服務肯定不錯。
你知道其他人肯定也看過這個廣告了，你買了這東西之後就有面子了。

相比之下，網站或 App 類型的砸錢廣告好像比較少見，我認為《羅輯思維》在 2018 跨年演講中給出了理由。

互聯網公司要想上央視春晚，門檻是 DAU（每日活躍人數）超過一億，否則廣告出來的那一瞬間，你的伺服器就會掛掉。

有句話說，世界上最悲慘的事情是，錢花光了，人還在。

但是，世界上更悲慘的事是，花光自己的錢買廣告，搞掛了自己的產品，人還在。

最近聽了一本名叫《空雨衣》的書，空雨衣是某座公園的一尊雕像，象徵著現代人所面臨的悖論：所有人都被「成功」這個目標綁架，不斷被驅趕著往前跑，反而失去了生活本身的意義。

公司的經營目的是什麼？
公司究竟屬於誰的？

追求利潤應該只是公司的手段而不是目的，就像我們吃飯是為了活著，但是活著不是為了吃飯。

公司的英文單字 Company，本意是一群夥伴，這才是公司的本質。

公司的目的是追求自身的永續存在，它本身不是誰的財產，也沒有股東；但是有規章、有成員、有管委會、有自己的資產，等等。

在未來，公司應該是這樣一種組織：

聯邦制：公司會有一個負責管理和協調的核心機構，還有好幾個具有獨立行動能力的業務單元。
雙重公民身份：員工既是整個公司的一員，又屬於某個業務團隊，需要同時對公司和團隊負責。

公司是由全體員工組成的自治型社區，所有成員都是夥伴關係。股份持有者只能分享紅利，不能參與經營。

為了落實「聯邦制」和「雙重公民身份」，應該降低個人績效獎金的比重，加大團體績效和公司整體績效獎金的比重。

利益捆綁是建立身份認同最有效的辦法。

軟體工程師的績效考核是否考慮技術難度？

Facebook 的核心精神是「Focus on Impact」和「Move Fast」，每半年一次的績效考核只考慮做出來的結果而不考慮過程。

如果通過改一行程式碼就能讓公司賺到與做一個複雜系統同樣多的錢，那兩者在評等上會是等價的。

這可能是 Facebook 與 Google 在軟體工程理念上最大的區別，因為 Google 無疑是把技術難度看得很重的。

Google 是一家思維方式與眾不同的公司，它認為，殺雞一定要用牛刀。

舉個電鑽的例子，很多人認為「日本製造」是品質的象徵。比日本製造品質更好的是「德國製造」。但最後會發現「瑞士製造」才是最好用。雖然比其它國家生產的要貴一倍，但是在工作效率和壽命上提高了十倍，怎麼算都是一筆划算的投資。

瑞士這個小國的產品不多，但是只要它做，就是精品。

做同樣的東西，即使功能相同，做得好不好，價值可以有天壤之別。瑞士製造的成本可能只比其他國家貴一倍，但是銷售價格可以貴十倍、百倍。

Google 在規模還很小的時候，就在貫徹「瑞士製造」的指導思想，一個大學生能完成的事，如果能找一個博士生來做，那麼一定能比同類公司做得更好。雖然要為這些員工多付一些工資，但也因此打造了「Google 製造」的品質，在商業競爭中取得很大的優勢。

績效考核不考慮技術難度的好處？

Facebook 在早期是一個產品驅動的公司，很多事情的瓶頸並不在技術上。在結果驅動的考核機制下，工程師們會自發解決那些技術之外的問題，而不是對沒有技術難度的事情嗤之以鼻放在那不管，悶頭繼續敲自己的程式碼。

Facebook 的軟體工程師同時分擔了一部分產品經理的責任。

績效考核考慮技術難度的好處？

因為技術發展很多時候是非線形的。常見的一種情況是，研發的前幾年進展很小，但超越過去之後飛速發展。如果在每半年一次的考核中只考慮結果，那這些高風險高回報的技術專案永遠不會被啓動。

要找到並留住大量肯動腦又肯動手的博士生，並不容易。同時，為了滿足這麼多聰明人做自己願意做的事，搞出了很多意義不大的小專案。要兼顧調動員工積極性、鼓勵創造性並集中精力在核心業務和重大專案上，對公司來講不是件容易的事。

這讓我想起《萬曆十五年》書中提到的觀點：

萬曆皇帝遭遇到的困境，是西方精細的工商業社會和東方小農社會之間的衝突。在政治、經濟、軍事三個方面都有體現。

對於中國這樣大體量的農業國家來說，首要目的，是維持整個國家不散攤子。要想方設法維持社會的穩定，所以只能追求「大約」，也就是差不多就可以了。

政治上，用道德這樣的抽象原則維持就可以了，經濟上收收農業稅就行了，軍事上，士兵用大刀也就不錯了。

這樣的血液下，無論張居正和戚繼光多麼天才，都不可能改革成功，他們只能成為時代的悲劇。

今天，我們很多人以快速迭代、以及所謂的彎道超車為藉口，做事馬虎，只圖快，不遵守規矩，這都會留下安全隱患。這個習慣一旦養成，就難以再改了。

反觀華為，因為 2018 年中美貿易戰的緣故，首當其衝成為美國開刀的對象，被指控不安全，可能含有間諜軟件，竊聽國家機密。

近日任正非為了走出這場危機，在致全體員工的一封信《全面提升軟件工程能力與實踐，打造可信的高質量產品》，信中有一句話：

我們要轉變觀念，追求打造可信的高質量產品，不僅僅是功能、特性的高質量，也包括產品開發到交付過程的高質量。

先撇開華為本身的評價如何、以及這封信是否真為任正非親筆所寫，更不考慮落實難度，單就內容本身，節錄一些有趣的部分：

1、

我們各級管理者和全體員工都不得以進度、功能、特性等為理由來降低可信的要求，確保可信的要求在執行過程中不變形。

2、

我們要從最基礎的編碼質量做起，視高質量代碼為尊嚴和個人聲譽。代碼就像是高樓大廈的一磚一瓦，沒有高質量的代碼，可信的產品就是空中樓閣。我們要優化並遵循公司各種編程規範，遵從架構與設計原則，熟練使用各種編程庫和 API，編寫出簡潔、規範、可讀性強、健壯安全的代碼。

3、

在確保可信的前提下，要在性能、功能、擴展性等方面做好權衡；慎重地定義我們的模塊與接口，真正做到高內聚與低耦合；我們要遵循權限和攻擊面最小化等安全設計原則，科學設計模塊之間的隔離與接口，提升安全性；低階架構與設計要遵循高階的架構與設計原則，在充分理解原有架構與設計的情況下，持續優化；我們要熟悉各種設計模式，重用公共成熟組件和服務，避免重復勞動。

4、

我們知道，再好的架構，其生命力也是有限的。隨著時間的推移、環境的變化以及新技術、新功能特性的引入，架構也會腐化。面對腐化了的架構，要毫不猶豫地去重構它。同時主動以可信設計原則為導向，去重構不符合軟件工程規範和質量要求的歷史代碼，提升軟件架構的生命力。

5、

軟件工程和質量工程需要依靠架構技術，而不是依靠 CMM 和 QA 管理流程。一切工程問題，首先要思考能否通過技術解決，當前技術無法解決的問題，暫時由管理手段代勞，同時不停止尋找技術手段。

6、

軟件工程就像一個國家的農業，是最基礎的設施！

最後，節錄幾段網友宝玉的金句：

1、

每個人都在一個領域能有深入的鑽研，同時對其他領域有一定瞭解，對個人，對團隊是非常有利的一件事。這樣也不需要 DevOps 這種為了兼顧開發、測試、運維三種角色而存在的工種！

2、

所有的涉及到人的管理最終都要歸結到人管理還是制度管理的問題上，軟件項目管理也不例外，如果過多的依賴於人的管理，那麼項目經理的職責就太重了，優秀的項目經理本身就是稀缺資源，最終會變成一個瓶頸。

3、

有人一提到軟件工程，就馬上說軟件工程不是銀彈。軟件工程從來不說自己是銀彈，就像現代醫學，也不會號稱自己包治百病，只會不斷改進，對症下藥！

技術應該只是我們打造產品的手段而不是目的。

參考資料

財神的精確度

Mon, 14 Jan 2019 00:00:00 GMT

新聞

1、財神和前澤

日本大型線上時裝購物網 Zozotown 創辦人前澤友作，因新年打破最快達 100 億日圓營業額紀錄，所以決定當個大撒幣（誤）在 Twitter 上抽選 100 名網友，每人 100 萬日圓的紅包。沒想到，這則推文吸引超過 500 萬名網友的轉推，打破「溫蒂漢堡」保持的 350 萬轉推數，成為 Twitter 有史以來最多人轉推的推文。

https://x.com/yousuck2020/status/1081544630754103296?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1081544630754103296%7Ctwgr%5Ed723c4d7590a665cfb47bed0f188431e1399c0ea%7Ctwcon%5Es1_c10&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fyousuck2020%2Fstatus%2F1081544630754103296image%3D

前澤友作，2018 福布斯日本排名最富有人物第 18 位。SpaceX 宣布其為全球首位私人月球旅行的乘客，並且提出「親愛的月球」計劃，邀請六至八位藝術家參加 2023 年進行的環遊月球之旅。

2、財神對貝佐斯

再來看看另一位也想上太空的富豪，2018 福布斯世界排名最富有人物第 1 位的傑夫·貝佐斯「宣佈離婚」，很有可能因為財產均分而讓出世界首富之位，這將會是「史上最昂貴的離婚」，屆時前妻將因此成為全球女首富。

身為 Amazon 最大股東的貝佐斯，一共持有 8000 萬股的股票，如果平分財產，將導致貝索斯的持股佔比下降至 8.15 %，雖然仍遠超第二大股東 5.8% 的持股，但這勢必將削弱他對公司的所有權和所有權。

3、財神的精確度

節錄自 ifanr 報導：

2018 年一共產生了 72 萬億美元成本的塑膠垃圾。 72 萬億美元可以買到什麼？ 72 萬億美元能同時買下 Apple、Google、微軟、Amazon、Facebook 還有找⋯⋯。如果有人把地球上所有廢棄塑膠都回收起来，那麼下一位全球首富就是他的了。

身為一個無法得知金融交易內線消息、只能計較 KPI 那點小錢的工薪階層，富豪們的世界實在離我太遙遠了⋯⋯。財神哪一天能找上門呢？

文摘

一個末日，各自表述

本周，我想分享克拉克的《地球末日》三部曲，分別是《遙遠地球之歌》、《地光》和《最後一個地球人》。

阿瑟·克拉克，最知名的科幻小說作品是《2001 太空漫遊》，與艾西莫夫、海萊恩並稱為二十世紀三大科幻小說家。

用一句話概括《地球末日》系列，那就是「一個地球末日，各自表述」：

遙遠地球之歌：環境如何毀滅地球
地光：人類如何毀滅地球
最後一個地球人：未知如何毀滅地球

以下，聊聊一些我覺得有趣的部分。

遙遠地球之歌

故事發生在地球得知 1600 年後太陽會爆炸，礙於現有科技無法馬上離開太陽系，人類面臨兩個抉擇：

K 策略「少數個人生存主義」
R 策略「多數高機率生存主義」

最後選擇了如魚產卵般的 R 策略，成功讓人類後代在幾個太陽系外的恆星系生存下來。

因為環境的關係，這些人類已經演化成了非當初地球人的型態（相貌大變化、一張白紙重新來過的全新道德觀、各系之間的人類互相沒往來）。

這讓我想起《薩爾達傳說》的種族，雖然彼此之間差異大，但也都是從人類和亞人演化而來的。

這也解釋了，為什麼電影中的外星人都長得像人類。成本考量？想像力受限？或許我們真的都是「尼比魯」星人的後裔，而非猿類？

地光

22 世紀如果一定要搶資源的話，那可能就是金屬。

回顧人類幾千年的資源搶奪史：搶錢、搶糧、搶娘們。

後來，隨著科學的進步，只要有了能源，財富、糧食、人口，就都好解決了。所以到了 20 世紀和 21 世紀，人類基本就只剩下搶能源了。

科學家預計，人類很有希望在 21 世紀徹底解決能源問題。解決的方案就是可控「核融合」技術。只要這個技術突破了，那大海或月球上，核燃料有的是。

到了 22 世紀，人類是不是就什麼都不用搶了呢？人類接下來搶的東西，應該會是稀有的元素，也就是金屬。

宇宙剛出現的時候，只有氫元素和氦元素。恆星是宇宙的煉金爐，恆星生產的元素有三種：

把兩個原子序是 1 的氫原子合在一起，變成一個原子序是 2 的氦。
太陽生命的最後階段，會變成一顆紅巨星，相當於太陽爆炸。這個時候溫度高、壓力大，就能生產原子序是 6 的碳元素，或者原子序是 8 的氧元素，最多只能生產原子序數到 26 的鐵元素。
只有質量大於太陽 1.44 倍的恆星，才有資格發生二次爆炸，這個過程叫超新星爆發。超新星爆發提供的溫度和壓力，才能生產原子序 26 以上的元素。

要合成像金銀這樣的元素，需要報廢掉一個 8 倍太陽質量的恆星。用這麼高昂的代價所製造的金屬元素，它們都是這個宇宙最稀缺的東西。

所以，宇宙所有元素生產的規律就是：原子序數越往後，就越難被生產出來。

原始人最開始使用水、火、土、石頭和獸皮來生活，這些東西的元素組成都很簡單，基本上就是原子序數 30 以下的氫碳氮氧矽磷。這些元素也是所有低等生命賴以維生的基本元素。

後來人類掌握了冶煉技術，就能利用原子序數 20 至 60 之間的鐵、銅元素，製造工具、汽車和飛機。在掌握了更高級的知識之後，我們才能用得上後面原子序數分別是 92 和 94 的鈾元素和鈽元素來造原子彈。

到了 21 世紀，隨便選一個原子序數 100 以上的金屬元素，它一定在工業上佔一席之地，甚至可能支撐一個產業。

整個人類的發展史，就是一個在元素週期表往上爬的過程。一個文明能利用的元素越後面，代表這個文明的層級越高。

如果這個規律成立的話，未來人類在科技進步的過程中，對原子序數高的金屬的需求量一定會變得越來越大。原本你看到的那些金字旁、不知道怎麼讀音的元素，第一反應通常是，這東西和我沒啥關係；但現在不一樣了，你知道它在未來可能是對人類非常重要的資源。

最後一個地球人

文明的兩大哉問：

如果文明的目的是生存，那世界大同能不能算是一個文明的頂點？人類社會如何實現世界大同？
如果生存的終點是滅亡，那人類終將面對死亡。怎樣的信仰能夠最好地面對死亡？

故事講述文明水平高出人類一個層級的外星文明「Overlord」來到地球，居然在十多年的時間內幫助人類建立一個世界大同的理想國，實現了人類追尋了幾千年的社會目標。

怎麼實現世界大同？Overlord 只做了兩件事，第一次，毫髮無傷地抵擋住了人類的核彈攻擊。第二次，擋住太陽。就這兩件事情，分別樹立起了「絕對防禦」和「絕對攻擊」的威信，。

鬧了半天，我們人類距離所謂世界大同，缺少的不是愛和什麼兩岸一家親，我們缺少的是一個攻守兼備、絕對優勢的武力。

任何一個信仰，都不可避免的一個話題，就是對死亡的解釋。好的信仰應該可以讓人不恐懼死亡，讓一個人變得坦然。只要你的信仰夠深，無論什麼時候想到最終的結局，心裡都能夠不慌張，甚至是一片祥和。

人們能接受死亡的兩種原因：

有希望，例如：輪迴轉生論
有意義，例如：奉獻式的犧牲小我、完成大我。

一個信仰哪怕再惑眾，人類還是有那個想象力填補上的。但是你要是一點素材都不給我，那我就要徹底絕望了。

最恐怖的不是死亡本身，而是死亡本身沒有任何希望、沒有任何意義。

小丑與白痴

本周，看了一部想像力爆棚的皮克斯動畫電影《腦筋急轉彎》（Inside Out），導演將人類大腦的五種情緒給擬人化，然後透過情緒之間的相互作用，將影響人類性格與情感的因素給擬物化（核心記憶、個性島嶼、抽象空間、造夢製片廠、潛意識監獄、記憶廢墟和遺忘深淵）。著實有趣，極富創意。

至於故事的劇情就不在這裡提了，保留樂趣給還沒看過的人去挖掘。影評之類的文章，網路上也已經一籮筐了。說說我看完這部劇之後，唯一的感想。

吳宗憲曾經說過：

一個人的歡喜跟悲傷，他是要一比一的。那個比例如果出現誤差的話，你就是生病了。小丑跟白痴，他最大的差別在哪裏？白痴不知道什麼時候要停止；小丑知道，他下班了，他就會停止。

吴宗宪：你知道小丑和白痴的分别吗？一个人的欢喜跟悲伤，它是要一比一的。如果那个比例出现误差的话，你就是生病了。…

本周金句

一個人能同時保有全然相反的兩種觀念，還能正常行事，是第一流智慧的標誌。

―― 費茲傑羅

基礎決定高度，細節決定深度。

仿生人會夢見電子羊嗎？

Mon, 07 Jan 2019 00:00:00 GMT

新聞

我們真的有「自由意志」嗎？

上周，Netflix 推出了互動式電影《黑鏡：潘達斯奈基》，你玩出幾星評價的結局呢？

《黑鏡：潘達斯奈基》是一部巧妙結合「互動式電影」、「多重結局」和「探討自由意志」要素的作品。

雖然新鮮有趣，但是個人認為互動式電影無法成為主流，理由有三：

製作成本高，而且破解的難度不高，盜版更是道高一尺，魔高一丈。
無法在電影院上映，少了一筆主要的收入來源。
觀賞體驗差，對於下班只想躺在沙發上、或是邊炒菜編追劇的小確幸來講，中斷 10 秒這個 MI（Movie Interface）MX（Movie Experience）不是很好。

而且互動式電影走到極致，其實就是被稱作「第九藝術」的電玩遊戲，這讓互動式電影的角色定位有如「有聲書」般尷尬。

回到《黑鏡：潘達斯奈基》的主題，也許人類並不存在什麼「自由意志」。

什麼叫自由意志？如果說我想要什麼就可以去追求什麼，那我就是自由的嗎？錯了，這不叫有自由意志。大猩猩、小狗和鸚鵡也可以想要什麼就去追求什麼，這沒什麼高級的，只不過是被慾望驅使。

實驗證明，人的慾望並不受意識控制，而是意識受慾望控制。

科學家用「功能性磁振造影」，觀察受驗者的大腦。結果發現，在受驗者做決定的幾百毫秒之前，在他還沒有意識到自己要怎麼選擇之前，科學家就已經可以透過大腦成像圖，提前知道了他會怎麼選。

不但可以先一步「知道」你想幹什麼，還可以進一步「控制」你想幹什麼。

科學家在老鼠大腦中插入三個電極，然後實現了遙控指揮，讓牠直行、爬樓梯或繞著轉圈，怎麼都行，跟遙控玩具一樣。

這對老鼠太殘忍了？但是科學家控制的其實是老鼠的意願。你看到的是老鼠被遙控，而老鼠自己的感覺是想去哪就去哪，非常快樂。那麼，老鼠還有什麼「自由意志」可言呢？

許多科幻作品都在探討「機器人是否存在意識」的問題，例如《西方極樂園》和《銀翼殺手》。

仿生人會夢見電子羊嗎？

反過來想，意識也許只是一種精神污染（函數副作用 Side effect），人類不屬於純函數（Pure Function）。

文摘

工程師的五個等級

身為一個喜歡科幻作品的理工男，文學作品的賞析對我來說一直都是罩門。

本周的《吳軍的谷歌方法論》在介紹莎士比亞的《第十二夜》文中提到，文學家在創作上有三個層次：

編一個吸引人的故事（托爾金的《魔戒》、瓊瑤的小說）
反映出一個時代的特點和問題（海明威的《戰地鐘聲》）
通過對現實和一個時代的描寫，闡述作者自己心中的春秋大義。（雨果的《悲慘世界》、曹雪芹的《紅樓夢》）

其中「反映時代特點」剛好與《吳軍的硅谷來信》其中一篇《談文物的價值》不謀而合。

一般來講博物館收藏品的價值看三個：

文物性：重要歷史事件的見證，或者反映一個時期的文明水平，社會文化生活。（羅浮宮的《漢摩拉比法典》）
藝術性：不僅僅是以今日眼光評判是否漂亮，還要放回到歷史中看它們是否具有里程碑式的意義。如果同時二者具備就更珍貴。（達文西的《蒙娜麗莎》、米開朗基羅的《創世紀》）
稀缺性：一般越古老的越稀缺。有些年代雖然不算太長，但全世界剩不了幾個，也非常珍貴。再有名人們用過的東西，當然也就獨一無二了。（顧愷之的《女史箴圖》）

吳軍老師在《工程師和職業發展》一文中，仿照「朗道給物理學家分級」的方法，也將工程師分成了五個等級。分類的原則大致如下：

能獨立解決問題，完成工程工作。
能指導和帶領其他人一同完成更有影響力的工作。
能獨立設計和實現產品，並且在市場上獲得成功。
能設計和實現別人不能做出的產品，也就是說他的作用很難取代。（比爾蓋茲、約翰卡馬克）
開創一個產業。（圖靈、高德納）

本周圖片

為什麼人工智慧不可能取代人類

Vue.js 的作者尤雨溪最近在《vue 和 react 優點分別是什麼？》回覆之中，給出了一段話：

編程語言之間噴來噴去還少麼？大家都是圖靈完備，然而此之蜜糖，彼之砒霜。

好奇什麼是「圖靈完備」，查詢之後得到的簡答如下：

圖靈完備意味著你的語言可以做到模擬「圖靈機」能做到的所有事情，可以解決所有「可計算問題」。

圖靈不完備的語言常見原因有迴圈或遞迴受限（無法寫不終止的程式，如 while(true){};），無法實現類似 Array 或 List 這樣的資料結構。

這讓我想起《吳軍的硅谷來信》曾經給出下面這張圖，解釋為什麼人工智慧不可能取代人類：

至於什麼是「不可計算問題」？舉個例子：某個男生特別壞，在別人看來就是個渣男，但是你喜歡的女生偏偏就是特別喜歡他。這個問題就算放到 2049 年，Siri 也還是無法給出一個令你滿意的答案。

新奇

如果全世界的人都只說一種語言該有多好

YouTuber 啾啾鞋在《世界語簡介》的影片中，分享了一套叫「世界語」的語言。

世界語是一套非常有邏輯、沒有例外，容易舉一反三的語言，只要記住基本單字和文法之後，就可以拼湊出想要表達的意思：

一字一音，會念就會拼，會拼就會念。
沒有複雜的動詞現在式、過去式和未來式規則。
單字的結構簡單，由「字首、字根、字尾和詞類」組成。

詳細內容可以到啾啾鞋的影片中進一步暸解，令我印象深刻的是總結的部分，為什麼世界語沒能成為人類的統一語言呢？

任何有這種「團結所有人」想法的發明，都會面臨相同的問題。以「網路」的出現為例，人們原本以為可以透過資訊的流通，讓世界變得無邊界，人類就可以大同。但是網路也更有效率地讓許多志同道合的人形成自己的意見同溫層，然後開始和敵對陣營互相吐口水。

蘇聯共產黨原本打算透過世界語的力量統一全國人民，結果反而造成自己的內鬥，並且最後被禁止使用。

如果想要全人類真的團結在一起的話，恐怕只有當外星人出現的時候，人類才能團結在一起。團結的同時，其實就意味著排外。

本周金句

除非違反物理定律，否則幾乎任何事情都是可能的。

――《埃隆·馬斯克和特斯拉汽車的故事》

任何在我出生時已經有的科技，都是稀鬆平常的世界本來秩序的一部分。任何在我 15～35 歲之間誕生的科技，都是將會改變世界的革命性產物。任何在我 35 歲之後誕生的科技，都是違反自然規律，要遭天譴的。

―― 《銀河便車指南》科技三定律

每個人都有一個計劃，直到被一拳打到臉上。

―― 泰森

我們從哪裡來？我們要往哪裡去？

Tue, 01 Jan 2019 00:00:00 GMT

新聞

如果你想年底被公司開除，可以考慮使用 Ant Design

雖然馬上就要迎接 2019 跨年，街頭仍然瀰漫著濃厚的聖誕節氣氛。

不同於台灣，中國近來因為「中美貿易戰」的關係，不少地方政府開始強烈「抵制洋節」，除了北京、上海等主要城市，很多地方都禁止公共場所懸掛帶有聖誕節氣氛的裝飾物品或擺放聖誕樹。此外，許多教會所舉辦的平安夜彌撒活動也受到衝擊。

然而，這周的 IT 圈也不寧靜，牽扯上了一則相關新聞：

開源 UI 框架 Ant Design 在未告知開發者的情況下，自動在前端頁面開啟聖誕節彩蛋，導致前端工程師被公司開除。

令人疑惑的是：

這個新修改竟然沒有出現在 Changelog，搞不清楚是給誰的彩蛋⋯⋯
彩蛋預設還是開啟的，而不是交由開發者自行決定
沒有提供關閉選項，只能透過「覆寫 CSS」的方式⋯⋯
即便是如此大的開源專案，也還是沒有監督到這件事

作者之後也出面「回應」了整起事件的來龍去脈：

關於 Ant Design 聖誕彩蛋，起源自 2018 年 9 月 10 日我的一次提交：add christmas easter egg · ant-design/ant-design@00aebeb ，代碼實現會在 12 月 25 日當天給所有按鈕添加積雪效果，並增加 Ho Ho Ho! 的瀏覽器默認提示信息。這完全是我個人的一意孤行且愚蠢的決定，是我的錯誤給大家造成了不良影響，非常抱歉。

先撇開被開除的真實性不論，作為一個影響力僅次於 Bootstrap 和 Semantic UI 的開源 UI 框架（GitHub 40k stars），這玩意兒萬一出現在伊斯蘭國家的政府網站上，後果不堪設想啊⋯⋯。

文摘

我們從哪裡來？我們要往哪裡去？

今年的《豆瓣 2018 年度讀書榜單》之中，我唯一讀過的作品只有《21世紀的21堂課》。

哈拉瑞的《人類大歷史》三部曲，《人類大歷史》說的是人類社會如何形成，《人類大未來》說的是未來社會如何演化，一本是回顧過去，一本是展望未來，而這本《21世紀的21堂課》考察的是當下，說的是生活在今天的你和我正在經歷、或者將要面臨的問題。

引述自《起源》的一段話：

假如你有一台功能強大的電腦，無所不知，無所不曉，你想問什麼問題都可以。那麼，十有八九你最終會問到人類的兩個最基本的問題。這兩個問題自人類自我意識覺醒以來，便一直縈繞在他們的心頭。我們從哪裡來？我們要往哪裡去？

如果說人生的終極問題是：人類的起源和歸宿，那麼《人類大歷史》三部曲給出的答案就是：猿猴、智人（Homo sapiens）和神人（Homo deus）。

最不符合進化論的就是人類本身。―― 達爾文

生物靠「基因突變」來進化太漫長了（從猿猴到智人 200 萬年），智人到現在也就 7 萬年，生活方式就有了天翻地覆的變化，這是因為「認知革命」之後，智人有了「語言」能力，培養出「說故事」這個逆天的技能，憑藉著三大故事「金錢、國家和宗教」，我們的祖先開始可以共同相信一件事物，讓這個物種的進化不再是依賴基因突變，而是依賴「分工合作」，組建起複雜的社會，發展出高度的文明。

「農業革命」之後，人類從「狩獵採集文明」過渡至「農耕文明」，雖然身體素質下降，但是族群基因的傳播效率卻大大提升，最初的政治意識形態：「帝國」的概念也開始隨之盛行。

「科學革命」最大的進步就是人類「願意承認自己的無知」，科學因為證明了上帝不靠譜，給了以人為本的「人文主義」發展的機會，加上各國開始走向工業化，不論是工人、士兵或是婦女，人力成為非常寶貴的資源，因此意識形態開始由帝國主義轉向人文主義，其中最具代表的分別是：「進化人文主義（法西斯）」、「自由人文主義」和「社會人文主義（共產）」。

歷經第二次世界大戰的納粹德國戰敗、冷戰的共產蘇聯瓦解之後，代表「自由主義」的美國勝出，於是「自由」與「平等」的概念被視為人權，並且奉若神明，成為當今 21 世紀的主流思想一直延續到現在。

然而，未來很有可能因為「資訊科技革命」和「生物技術革命」，顛覆自由主義建立起來的兩大價值觀。

首先是「自由」，世間一切學科，不管是文學、科學、音樂還是經濟學，背後都是數學模式。每個人都是一個處理器，人與人之間的交流就是一套資訊處理系統，整個人類歷史，就是給這個系統增加效率的歷史。如果一切問題都是演算法問題，那麼我們只要建立一個連接所有資訊的「萬物互聯」網路，到那個時候，人工智能＋大數據＋演算法就比你更了解你自己，為了你我的利益，大家都應該讓算法替我們做決定，與其信奉個人、信奉神，還不如信奉這個網絡。個人「自由」徹底崩解，一個新的社會人文主義將會誕生：集中式資料處理的數位獨裁主義。

為了讓我們活得更健康，幫助我們做出更好的決定，完善這個萬物互聯網成為最值得幹的工作。終有一天，萬物互聯網會發展到人類無法理解的地步。演算法之間互相配合升級，演算法自己產生新的演算法，萬物互聯網將獨立於人類而存在，到時候，萬物互聯網就成了世界上第一個重要的東西，比人更重要。所有這些為萬物互聯網工作的職業就成了一份神聖的工作。

然後是「平等」，過去的剝削者與被剝削者只是在地位、權力和財富上的不平等，生理上並無不同。但是「生物技術革命」之後，富裕階層已經有能力透過「基因編輯」之類的改造技術，在體能和智能上優於其他人，甚至達到永生，成為「神」這種動物，那麼社會將會大變，自由主義提出「人類生而平等」的口號，將不再成立。

未來，假設上述兩個趨勢同時進行。那麼全體人類很有可能會被劃分成兩種人：無用的人和神人，這兩種人不可能是平等的，一個新的進化人文主義將會誕生：如同《美麗新世界》故事中的「新種姓制度」。

過去，人類征服了地球，只用了最後的幾十年時間，就解決了困擾千年以來的三大問題：飢荒、瘟疫和戰爭。

未來，人類打算追求永生，變成神這種動物，但是我們有因此過得比狩獵採集文明的智人還幸福快樂嗎？我們要往哪裡去？

後記：第一次聽說《人類大歷史》是在比爾蓋茲和馬克祖克柏的推薦書單，或許《人類簡史》、《未來簡史》和《今日簡史》的譯名較廣為人知。無神論加上打擊自由主義的觀點，也難怪這本書在中國會受到如此追捧的程度，甚至在收官之作《今日簡史》一書中，每每提到 Amazon、Google 和 Facebook，就要順便帶入阿里巴巴、百度和騰訊。

就像美國的好萊塢電影一樣，第三方國家的出現率從過去的俄羅斯、日本，到現在幾乎所有大片都有中國的影子，哈拉瑞不免俗還是要屈就自由主義的自由市場經濟。

本周金句

與其受人喜愛，讓人害怕才更安全。

――《利器》

智者將建立橋梁，而愚者則建立高牆。

――《黑豹》

如果連出門看星星都做不到，那麼教她們追逐星辰還有什麼意義？――《她說：女性人生瞬間》

能說會道的人很多，但能夠從無到有上線一個產品的人不多。執行力很重要。你很容易對幾百人、做了好幾年的產品挑出一堆毛病，但你卻無法協調幾個人在兩三個月內上線一個不完美的產品。誇誇其談的人太多。很多人用「完美主義」來掩飾自己的無能。

――《如何招一個好的產品經理》

陽光、大地與詩歌

Mon, 24 Dec 2018 00:00:00 GMT

新聞

美國總統川普於 18 日正式下令成立「太空司令部」，這將成為美軍在陸軍、海軍、陸戰隊和空軍之外的另一支全新軍種。

回顧美國一路走到今天世界霸權的地位，「昭昭天命」這個美式擴張主義的「天命論」起了很大的作用。

昭昭天命是美國對西向擴充運動的一種辯解或理由；又或者是一種促發其進程的意識形態或學說。

從建國開始前的迫害印地安人、吞併德克薩斯共和國，一直到介入北美洲以外事務，美國人認定國家的擴張是神的安排，拓展疆域是美國對這個世界的使命。

太空司令部成立之後，美國下一步打算將野心延伸向地球圈外。

作為緊追在後的第二強權，中國今年恰逢改革開放 40 週年，同樣也有一套屬於自己的天命論，那就是「天下觀」。

以清代《康熙皇輿全覽圖》為例，台灣、外蒙古、外東北與庫頁島、北朝鮮與南韓，都是中國神聖領土不可分割的一部份。

最近「來自中國台灣」事件鬧得沸沸揚揚，類似議題總是在兩岸爭論不休。

反倒是《璦琿條約》沙俄割走了東北 60 萬平方公里的土地，大約相當於 15 個台灣的大小，還有「外蒙古獨立」等等⋯⋯，怎麼小粉紅們卻興致缺缺，連屁都不敢吭一聲呢？

理由很簡單，因為台灣的利益大、拳頭弱、好欺負，就只是這樣而已。

身為小國，應該會有適合小國自己聰明的玩法，例如前陣子九合一選舉，聽到了一個有趣的想法：「中央政府選親美、親日的黨派，地方政府則選親中的候選人」。

一來可以在主權的高度上 hold 住，避免被「封鎖非洲豬瘟消息」的極權黨國給併吞，二來「東西賣得出去，人進得來，地方發大財」，降低成為美國魁儡的風險。

最後，回歸本質談起，「教育興則國家興，教育強則國家強」，本周 Hahow 好學校發佈了新版本的 App，並且可以參加 Samsung Galaxy Note9 抽選，大家一起來「學那些學校不會教的事」吧！

Hahow app 登陸頁

資源

Coloring China ! | 色染中国

https://se.joway.io/

色票網站，取材自山寨「日本の伝統色」的「中国传统颜色」。

剛好兩年前在書店翻到了《台灣顏色》這本書，就順手開源了一個「台灣顏色 Taiwan Colors」網站。

http://taiwan-colors.surge.sh

對台灣傳統顏色有興趣的朋友，歡迎在 GitHub 留下您寶貴的 issue 或 pull request。

https://github.com/amowu/taiwan-colors

工具

remove.bg

https://www.remove.bg

這周 remove.bg 席捲了各大 RSS 和 Weekly Mail，號稱可以快速無腦地幫圖片去背。

好奇之下，找了一張老婆的照片來測試，沒想到效果還真不錯，連髮絲的部分都有處理到：

玩上癮了⋯⋯再測試一張：

喂！怎麼把下半身給截掉了啦！

嗯⋯⋯是沒什麼問題啦，不過能順便把那傢伙給一起去掉嗎？

本周圖片

Behance 大神 Milo 整理了一篇《2019 年設計趨勢指南》，針對顏色、插畫、動畫特效、字型和排版等方面，給出了自己的預測分析和建議。

雖然我是看不出相比 2018 年有哪些區別，但是果然高手在民間，討論區出現一則有趣的留言：

UI 設計演化史，古典主義（早期的功能 UI 設計）> 裝飾主義（擬物寫實風格）> 現代主義（扁平化時代）> 後現代主義（扁平化基礎之上衍生的一些細節裝飾和 3D 動畫表現）。和整個藝術設計史如出一轍。

於是我 Google 了一張與「西方美術史」時間軸相關的圖片：

然後對比了歷代 Facebook iOS app 的設計：

竟然！⋯⋯好吧，或許是我藝術造詣不夠，感受不太出來，你們覺得如何呢？

本周金句

誰控制過去就控制未來，誰控制現在就控制過去。

所謂自由就是可以說二加二等於四的自由。

――《一九八四》

普通人認為嘗試新體驗意味著冒險。在企業家們看來，什麼都不做才是冒險，因為這意味著錯失機遇。

人們總是太高估自己能在一年裡做到什麼，而又總是太低估自己能在十年裡做到什麼。

――《富人的邏輯》

什麼叫老闆？老闆必須要成為企業的領袖。那什麼是領袖？領袖就是知道要「做什麼」，但是不知道怎麼做。所以去影響一大堆「知道怎麼做」，但是「不知道做什麼」的人來幫他做。

―― 馬雲

我上班就是為了賺錢，別跟我談什麼理想，我的理想就是不用上班賺錢。

煩惱就是慾望比口袋多一分錢；幸福是口袋裡比慾望多一分錢。

――《吳軍的谷歌方法論》

來舉杯暢飲吧，為了所謂人這種生物。善人也好惡人也罷，無論世間如何變化，皆輪迴也。困於足以讓人腐化，卻不足以讓人學習的時間渦流裡，人才會充滿慾望，才會挑起事端吧？生命，明明是只需要陽光、大地與詩歌就能滿足的東西。

――《所謂人》

透過寫作永生於人間

Mon, 17 Dec 2018 00:00:00 GMT

前言

轉眼 2018 就要結束了，每年這個時候，總是充滿了焦慮的心情，感覺好像還有很多目標沒有完成。

其中之一就是文章的產出極低。

所以想趁著這個機會，效仿阮一峰的《每周分享》系列，總結一下每周看到的知識，並將之轉化成值得分享的心得文章。

新聞

平成最後的漢字

日本天皇明年就要退位了，所以今年可以看到很多掛上「平成最後的〇〇」的梗。

京都的清水寺每年都會總結出一個代表日本的漢字，今年選出的是「災」這個字。

豪雪、豪雨、酷暑、強颱、地震再加上瘟疫，日本今年經歷了一系列的自然災害。

巧的是，我今年十月曾經眼皮跳了將近一個月左右，接著身邊就陸續發生了一些不幸的憾事。

民間流傳著一句「左眼跳財、右眼跳災」。最近剛三刷完《星際效應》之後，突然覺得好像可以解釋這種現象，該不會是有老祖先正在諾蘭的五維空間之中撥動弦，想要傳達些什麼訊息給我？

不過現在回想起來，我眼皮是跳在左眼⋯⋯，所以，財呢？

文摘

我們將毀於我們所熱愛的東西

本周，我聽了一本經典的反烏托邦科幻小說，《美麗新世界》。

聽完之後，我對社會主義有了重新的思考。

故事中的未來社會，人類皆透過人工授精、體外培養的方式來繁殖，並且制定了新的種姓制度：α、β、γ、δ 和 ε。不同於舊種姓制度只是在階級上的不平等，新種姓制度下的新生兒連智力和體力都有高低之分，徹底重新定義了不平等的下限。

然而，卻不會有一群人壓迫另一群人的情況發生，各個階層的人都被培養成非常適合、也非常熱愛自己的工作。彼此間也不會感到「不幸福」，每個人都滿足於馬斯洛提出的需求金字塔。

如何做到的呢？

簡單來說，就是透過修改先天的基因＆後天的洗腦教育。

例如：最低種姓 ε，讓他們一摸到鮮花就觸電，形成一種「想到大自然植物就噁心」的恐懼反射，避免他們在野外娛樂，浪費時間和社會資源。再比如 β 種姓只是技術人員，通過前期教育降低夢想，只做好手上的技術活，不夢想開創什麼學術新領域。反之在 α 種姓教育中則被鼓勵。

為了追求社會的高效，每個階級各自負責如汽車製造流水線般的精細分工，各就其位，整個社會非常和諧穩定。所有人都成為社會這台大機器之中「獨立卻又需要彼此、不可分割」的螺絲釘。實現了終極的社會主義：人為社會服務，而不是社會為人服務。

故事中「犧牲了人性複雜的多樣性與獨立個性」換來的幸福並不可怕，可怕的是，有一天，這個世界會用廉價的娛樂讓我們變成社會的零件，而不是社會的主人。

我們以前活在《一九八四》，未來可能會活在《美麗新世界》。

(登月第二人，伯茲·艾德林：「你們承諾會殖民火星，卻給了我 Facebook」)

最近「CRISPR 基因編輯嬰兒」的新聞鬧得沸沸揚揚，或許這個未來也不遠了⋯⋯。

工具

Logpoints

Chrome Debugger 實驗室最近推出了一個名叫 logpoints 功能，對於不喜歡使用中斷點（breakpoints）的 console.log 派來說，應該是個好消息。

本周圖片

大腦就是一個三磅重的宇宙

《紐約時報》曾經刊登過這兩張有意思的照片，左邊是小白鼠的大腦神經元網路，右邊則是宇宙的星系，兩張照片放在一起看，竟然驚人地相似。

最近聽了《得到》專欄《前沿科技之腦機接口》，裡面提到做腦機介面，最想要實現的就是看誰能採集更多、更精准的「腦電波」資料，然後嘗試理解這些訊號所對應的大腦指令。

那怎麼採集呢？科學家分成兩派，「侵入式」的腦機介面與「非侵式」腦機介面。

這兩種探測大腦的方式，其實跟科學家探索宇宙的方法如出一轍。

「侵入式」的腦機介面，像《駭客任務》一樣，把電極放到大腦裡去，就像宇宙的觀測者，如果能發射衛星、飛船進入太空，登陸月球、火星，那麼就能帶回珍貴的資料。這就是侵入式腦機介面的邏輯。

不同於侵入式腦機介面需要動開顱手術，風險很高，非侵入的風險就低很多，其實就是醫院裡面你會見到的腦電圖。做腦電圖的時候，你會戴上一個佈滿電極的帽子，分析你的腦電波。這就相當於科學家在地球上，對星系進行遠距離觀測。

如果腦機介面技術被順利發展起來，那麼將會徹底顛覆人類的文明，它將會取代五萬年來我們賴以為生的協作工具：語言。直接建立一個能讓大腦和外界溝通的全新方式。估計下一間一萬億美元的公司就會誕生於此吧。

新奇

神預測 2020 東京奧運

被奉為經典漫畫的科幻神作《阿基拉》，最近在台灣推出了再版。

(聽說絕版曾經喊到天價，如今再版，質感爆棚)

距今 34 年前的漫畫（1984），全手繪的細膩筆觸，即便是放在現在來看，也有過之而無不及。

作者大友克洋將故事設定在 2019 年的新東京，並且在劇情中提到了 2020 年東京將舉辦奧運，簡直神預測！這麼好的梗，動漫立國的日本政府絕對能拿來操作啊。

(雖然不是現在的東京，而是第三次世界大戰後的「新東京」)

(慶幸的是，第三次世界大戰沒有真的發生)

如果你想毀掉一個人，但又想讓他覺得你是全世界對他最好的，那麼送他《薩爾達傳說：曠野之息》吧

由於本身待過遊戲業的關係，對於日本的遊戲設計與遊戲開發一直都有在關注。最近看到一個有趣的新知。

正常來說一間遊戲公司有了別人做不到的「好玩」的創舉之後，肯定都是建立商業機密檔案，制定情報管理機制，確保這個製作秘密不會外流。

例如 CAPCOM 這家公司，任何遊戲專案，光是想要調用「如何做好打擊感」這方面的知識，就要特別動用公司裡一個專門調製打擊感的小組，而且那個小組是受到嚴格監控的，並且每個人所掌握的知識也只是其中的一小部分。

作為 TGA 2017 年度最佳遊戲的《薩爾達傳說：曠野之息》，任天堂的開發團隊竟然自己在 2017 日本開發者大會上分享了讓開放世界好玩的 3 個隱藏設計要素：引導點的巧妙安排、地圖場景的三角法則和對應真實世界的距離感、密度感和時間感。

(高塔就是吸引力很強的引導點，玩家看到它整個精神狀態就會開始不對勁，遊戲中巧妙地安排這些引導點，確保玩家在到達一個引導點之後，一定能看到其它引導點，從而下意識又有了一個潛在的目標)

(玩家也不是笨蛋，引導點會讓玩家有一種被設計好、而不是自由探索的《美麗新世界》既視感，所以《曠野之息》將大多數場景物件的輪廓都設計得接近三角形，把這些物件擺在兩個引導點的中間來影響玩家的視野和路線)

(透過京都的便利商店密度來掌握遊戲中該設置多少神廟數量的感覺)

更多細節有興趣的可以觀看下面的 YouTube 影片介紹，看完之後會不禁讚嘆遊戲設計中也充滿著「行為經濟學」啊。

https://youtu.be/T35UQSWSM94?si=G_-Ibb1Fp4BEgTSy

本周金句

說唐僧成佛了，我們理解，一個有使命的偉大領導者；孫悟空成佛了，我們也能理解，業務高手、降妖除魔，忠心耿耿；沙和尚成佛了，我們也能理解，一路髒活苦活累活，沒有功勞也有苦勞；你說豬八戒成佛了，我們不理解，好吃懶惰又好色，唐僧一被抓，「猴哥我們散伙吧」；就這種員工，他最終還成佛了，為什麼？只因為一件事，跟對了團隊。 ―― 名人名言

如果家長能想清楚，關鍵是贏在終點線上，而不是起跑線上，就沒有必要逼孩子從小搞得那麼累了。 ――《維繫朋友關係之道》吳軍的谷歌方法論

今天，世界上絕大部分私立中小學，都要求學生們穿校服，這不僅僅為了整齊好看，也是為了讓不同家庭背景的孩子們感到平等。 ――《熬夜排隊買蘋果手機和中國孩子的早教》吳軍的谷歌方法論

過去許多軟體開發商設計很多數位鎖，想要防止被盜版，但歷史證明，都沒有用。開發數位鎖浪費了軟體開發商的大筆時間和金錢，但最後鎖住的，卻往往是有良心乖乖買正版的使用者。 ――《軟體開發的未來，是大斗內時代？》

發明是從 0 到 n 的一個全過程，遠不是簡簡單單地從 0 到 1 那麼簡單。今天很多人一直夢想著自己碰到從 0 到 1 的好運氣，其實世界上從 0 到 1 的發明從來不缺，但是能走完全部 n 步才是一件難事。 ――《發明的邏輯和可重複的成功》吳軍的谷歌方法論

做事不怕慢，就怕停。 ―― 吳軍的硅谷來信

後記

備忘一下這個系列的初衷與目的：

將看過的東西寫出來，有助於提升記憶＆理解程度
除了 Evernote 之外，另外有個地方可以搜尋資料
有輸入、有輸出，完善知識管理的最後一塊拼圖
施比受更有福，如果能幫助到世界某個角落的一個人也好，我也透過寫作永生於人間了

有任何建議，也歡迎不吝留言指教。

如何在 React Native 使用 SVG 向量圖檔

Sun, 16 Dec 2018 00:00:00 GMT

問題

React Native 提供的 Image 無法使用 .svg 向量圖檔
Expo 提供的 Svg 需要透過 Circle、Rect、Path、ClipPath 和 Polygon 自己繪製

解決方法

透過 SVGR 這個工具將 SVG 轉換成 React Native Component，例如：

$ npx svgr@v1.10.0 --native ./logo.svg > LogoSVG.js

會自動產生下列 react-native-svg 可以支援的程式碼：

import React from 'react';
import Svg, { Defs, LinearGradient, Stop, Path } from 'react-native-svg';

const LogoSVG = props => (
  <Svg {...props}>
    <Defs>...</Defs>
    <Path ... />
    <Path ... />
    ...
  </Svg>
);

export default LogoSVG;

直接在 App 使用：

import React from 'react';
import { View } from 'react-native';

import LogoSVG from './LogoSVG';

class App extends React.Component {
  render() {
    return (
      <View>
        <LogoSVG />
      </View>
    );
  }
}

已知問題

如果 SVG 元件沒有 render 出來，可能需要自行給定寬和高，例如：

<LogoSVG width={320} height={240} />

<Stop /> 的 offset propTypes 預設 number 是錯誤的，應該是字串，例如：

<!-- 錯誤的 -->
<Stop offset={0.93} stopColor="#000000" />

<!-- 正確的 -->
<Stop offset="93%" stopColor="#000000" />

某些 <Path /> 會掉色，要手動添加 fill props，例如：

<Path
  d="..."
  fill="#00aaa5"
/>

參考文章

如何自動化 GitHub Releases 流程？

Sun, 24 Dec 2017 00:00:00 GMT

2017 年初的時候，曾經寫了《如何自動化 release 的流程？》這篇文章，介紹了如何利用 semantic-release 和 TravisCI 自動化 GitHub Releases 和 NPM publish 這件事。這次要介紹的是如何直接透過 Probot 機器人做到 GitHub Releases。

大綱

什麼是 GitHub Releases？
GitHub Releases 有什麼問題？
什麼是 Conventional Commits？
什麼是 Conventional Release Bot？
為什麼要用 Conventional Release Bot？

什麼是 GitHub Releases？

GitHub Releases 是 GitHub 提供給每個專案在釋出（Release）新版軟體時，用來紀錄更新內容（Change Log）的頁面。

通過 GitHub Releases，你可以為每次的 release 加入說明，描述該 release 進行了哪些更改。

GitHub Releases 的基礎是建立在 Git tags 之上。Tags 代表了你的專案在某個特定時間點下的里程碑，所以它會是一個很好的 release 表達方式。

更多有關於 Git tags 的資訊可以參考 GitHub 的《Working With Tags》。

GitHub Releases 有什麼問題？

我們團隊在執行 release 的過程中碰到過不少問題，總結如下：

無法回憶起曾經「新增了哪些功能」或「修復了哪些問題」，就像突然有人問「你記得上禮拜二中午吃什麼嗎？」的感覺，每次負責 release 的人都要口頭一個一個問其他工程師，最後崩潰躲在角落獨自一個人慢慢爬 commit log⋯⋯😢
Push 或 merged master 的當下就應該馬上 release Git tag，但是常常會忘記做這件事，導致之後想起來還要回去找 commit SHA 才能補上 tag
不是所有人都知道 SemVer 的版本號更新規則
Git tag 下在錯誤的 branch：因為有些 repository 的 default branch 會設為 develop，但是常常忘記選擇 master
Git tag name 打錯字：不是忘記加 v（例如 1.1.0 ）就是多一個點（例如 v.1.1.0 或 v1.1.0. ）◢▆▅▄▃ 崩╰(〒皿〒)╯潰 ▃▄▅▆◣
即使上面的步驟都讓你做對好了，但是下一次要 release 還是得手動再來一遍⋯⋯這種彷彿在玩疊疊樂，希望積木不要倒的心情，我覺得不行

什麼是 Conventional Commits？

Conventional Commits 是 conventionalcommits.org 在維護的一份 Git commit message 規範。

Conventional Commit 定義的 commit message 結構應該如下：

<type>[optional scope]: <description>

[optional body]

[optional footer]

根據 commit message 的不同，產生的 release 內容也會有所不同：

Bug Fixes：當 type 為 fix，那麼它屬於「修復問題」類型的 commit（等同於 SemVer 的 [PATCH](https://semver.org/)）
New Features：當 type 為 feat ，那麼它屬於「新增功能」類型的 commit（等同於 SemVer 的 [MINOR](https://semver.org/)）
BREAKING CHANGES：當 body 或 footer 的開頭有出現 BREAKING CHANGE: 這個關鍵字，那麼它屬於「會讓舊版程式無法運行的更新」類型的 commit（等同於 SemVer 的 [MAJOR](https://semver.org/)）。一個 breaking change 的 type 只能是 fix、feat 或 chore。

Scope 為選填內容（使用括號包在內），它可以協助 commit 提供額外的上下文資訊。例如：

feat(component): add brand button

Commit types 除了 fix 和 feat 之外，其它 types 也是允許的，例如 Angular convention 建議的 docs、style、refactor、test 和 chore，但是這些 types 僅供閱讀方便使用，並不會出現在 release notes 之中。

遵循 Conventional Commits 之後，整體的 commits log 感覺大致如下：

更多細節可以參考 Conventional Commits Specification。

什麼是 Conventional Release Bot？

Conventional Release Bot 是 Hahow 開源的 GitHub 機器人，它能夠根據 Conventional Commits 的規範，自動幫你產生 GitHub Releases 和 Git tags。

如上圖所示，Conventional Release Bot 自動產生的 GitHub Releases 內容如下：

Git tag（遵循 SemVer）
Release 日期
Release 類型：Bug Fixes、New Features 和 BREAKING CHANGES
Conventional Commit 的 scope（有填寫才會出現）
Commit 說明
Commit SHA
Commit 作者
和上一版本的 diff

如果機器人沒有在 commits 裡發現 feat、fix 或 BREAKING CHANGE，則會跳過建立 GitHub Releases 的步驟。

為什麼要用 Conventional Release Bot？

總結一下 Conventional Release Bot 的優點：

自動化產生 CHANGELOG（GitHub Releases）
自動化更新 SemVer 版本號（以 Conventional Commits 的 types 為基礎）
通過友善的結構化 commit 規範，讓開發者更容易瀏覽更新歷史，提高對專案做出貢獻的意願
更好地向人類（同事、使用者或其他利益相關者）傳達軟體更新的本質

最後，Conventional Release Bot 的原始碼＆安裝方式可以在 amowu/probot-conventional-release 找到，歡迎大家一起來貢獻 Pull Request。😘

如何使用 RxJS 處理分頁 API

Sat, 09 Dec 2017 00:00:00 GMT

這篇文章會以 node-github 的 getCommits API 為例，介紹如何使用 RxJS 取得所有分頁的 commits 結果。

前言

以往在處理分頁的 API，通常都會使用遞回運算，這會讓程式碼的可讀性不佳。有鑒於最近 RxJS 正夯，想說來試著寫寫看，於是就有了這篇分享文章。

需求

首先，因為 node-github 的 getCommits API 回傳的是一個 Promise 物件，所以需要先使用 RxJS 的 fromPromise 將它轉成 Observable：

Rx.Observable
    .fromPromise(getCommits(...))

接下來，利用 node-github 提供的 hasNextPage 和 getNextPage，搭配 RxJS 的 expand 來處理分頁的遞回運算：

Rx.Observable
    ...
    .expand(
        (response) => hasNextPage(response)
            ? Rx.Observable.fromPromise(getNextPage(response))
            : Rx.Observable.empty()
    );

上述邏輯大概是這樣：

如果 getCommits 回傳的結果還有下一頁，就繼續 call getNextPage API
如果已經沒有下一頁，則回傳 Observable.empty() 結束 expand 運算

最後，透過 reduce 將所有分頁回傳的結果 concat 成一個 Array：

Rx.Observable
    ...
    ...
    .reduce(
        (acc, curr) => acc.concat(curr.data)
    , []);

整體程式碼大致如下：

Rx.Observable
    .fromPromise(getCommits(...))
    .expand(
        (response) => hasNextPage(response)
            ? Rx.Observable.fromPromise(getNextPage(response))
            : Rx.Observable.empty()
    )
    .reduce(
        (acc, curr) => acc.concat(curr.data)
    , []);

如果再稍微封裝一下，語法簡直優雅到無法直視 🤤：

Rx.Observable
    .fromPromise(getCommits(...))
    .expand(checkNextPage)
    .reduce(concatAllCommits);

然後看是要用 subscribe 或是 toPromise 來取得結果：

const getAllCommits$ = Rx.Observable
    .fromPromise(getCommits(...))
    .expand(checkNextPage)
    .reduce(concatAllCommits, []);

// 方法一
getAllCommits$.subscribe(
    (commits) => console.log(commits)
);

// 方法二
const commits = await getAllCommits$.toPromise();

console.log(commits);

// Output:
// [{commit}, {commit}, ...]

總結

以往的分頁 API 處理需要透過遞回運算才能完成，加上命令式編程的可讀性沒有聲明式編程的體驗佳，所以嘗試使用 RxJS 的 stream 取而代之
使用 fromPromise 將回傳物件為 Promise 的 API 轉換成 Observable
使用 expand 處理分頁的遞迴機制
使用 reduce 組合所有分頁的回傳結果
使用 toPromise 獲取結果

附件

參考

AWS Serverless RESTful APIs

Sun, 01 Oct 2017 00:00:00 GMT

近幾年在雲架構上討論熱度較高的 2 大主題分別是 容器化（Containerize）與 無伺服器（Serverless）架構。本篇文章會帶你瞭解什麼是 AWS 無伺服器架構，以及如何使用 Serverless Framework 這個框架，快速開發 RESTful APIs。

大綱

什麼是 XaaS？
AWS 無伺服器架構
Serverless Framework
CRUDable Service
基礎設施即程式碼

什麼是 XaaS？

馬雲說過一句話：「過去的一百年，我們把人變成了機器，未來的一百年，我們將會把機器變成人。」

如果要用一句話來定義 XaaS（X as a Service）的話，那就是「萬物皆服務」。

舉凡 IaaS（基礎設施及服務）、PaaS（平台即服務）或 SaaS（軟體即服務）等⋯⋯，用一張圖來概括各個 XaaS 的關係：

身為程式設計師，我們就是那個負責寫服務來取代人類的存在。

所以能夠以最快速度開發出可驗證的服務原型，就成了開發者彼此之間的競爭條件之一，也是本篇文章的目的。

AWS 無伺服器架構

AWS 是目前雲技術的領頭羊，如果想要用 AWS 來開發 Serverless 的 RESTful APIs，主要會由 3 個核心服務所構成：

AWS Lambda（Functions as a Service）
Amazon API Gateway（REST API Endpoint as a Service）
Amazon DynamoDB（NoSQL DB as a Service）

這裡不會贅述如何操作這些 AWS 服務，如果你已經熟悉這些服務，可以直接前往下一章的 Serverless Framework；如果還不知道它們是怎麼運作的，強烈建議先跑過一遍官方的幾篇教學與實作，理解這 3 個傢伙為什麼這麼酷，也才能理解為什麼接下來要介紹的 Serverless Framework 比它們更酷！

Serverless Framework

接下來進入本篇文章的重點，如果每次建立 REST API 都需要手動操作 Lambda、API Gateway 和 DynamoDB 這些服務的話就太麻煩了，所以這裡介紹一個第三方社群維護的框架：Serverless Framework。

Serverless Framework 提供了一整套專為「無伺服器架構」所設計的開發＆部署工具，除了 AWS 之外還支援了 Google Cloud Platform 和 Microsoft Azure 等雲服務平台，讓開發者只需專注在 Web、Mobile 和 IoT 應用的核心功能，而無需煩惱基礎設施的維護。

先來跑一遍官方的快速入門暖暖身，首先安裝 Serverless 的 CLI：

$ npm install serverless --global

注意：因為 Serverless CLI 會透過 AWS SDK 間接操作你的 AWS 帳戶，所以在開始之前，請先確認本機端已經配置完 AWS 的 credential，詳細設定方法可以參考官方文件的《Credentials》。

新增一個 Node.js 環境的專案 hello-service：

module.exports.hello = (event, context, callback) => {
  const response = {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Go Serverless v1.0! Your function executed successfully!',
      input: event,
    }),
  };

  callback(null, response);
};

部署 Lambda Function 至 AWS：

$ serverless deploy --verbose

*--verbose** 顯示部署過程的細節。*

如果每次都需要重新部署所有 Lambda Function 會很沒效率，Serverless 也可以只部署單個 Lambda Function：

$ serverless deploy function --function hello

*--function** 指定 Lambda Function 的名稱。*

部署完成之後，使用 invoke 執行 Lambda Function：

$ serverless invoke --function hello --log

*--log** 顯示執行回傳的結果。*

{
    "statusCode": 200,
    "body": "{\"message\":\"Go Serverless v1.0! Your function executed successfully!\",\"input\":{}}"
}

CLI 也可以使用 logs 和 --tail 來持續監控 Lambda Function 的執行結果：

$ serverless logs --function hello --tail

瞭解整個 Serverless 的運作方式之後，CLI 還有提供 remove 指令，讓你可以將整個專案從 AWS 帳戶移除，畢竟佔用這些資源是要計費的：

$ serverless remove

CRUDable Service

瞭解 Serverless Framework 如何輕易地部署 Lambda Function 之後，我們來看看 Serverless Framework 如何開發一套完整、可以 CRUD 資料庫的 REST API 服務。

下載 Serverless 社群寫好的 To-do CRUD 範例：

$ serverless install --url https://github.com/pmuens/serverless-crud

注意：因為這個範例有用到其它第三方的 npm packages，所以部署前記得先 *npm install* 安裝。

部署 To-do service 至 AWS：

$ serverless deploy --verbose

部署完成之後，CLI 會顯示你的 API Gateway endpoints：

...

endpoints:
  POST - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos
  GET - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos
  GET - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos/{id}
  PUT - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos/{id}
  DELETE - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos/{id}

...

Read All To-dos

使用 cURL 或 HTTPie 之類的 HTTP client 來測試結果，首先是取得所有 to-dos：

$ http GET https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos

沒意外的話，會回傳空的 To-do 陣列：

HTTP 200 OK

[]

打開程式碼，Read all to-dos 的 Lambda Function 很簡單，透過 AWS SDK 的 DynamoDB scan API 來取得所有 todos table 的 items：

const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();

module.exports = (event, callback) => {
  const params = {
    TableName: 'todos',
  };

  return dynamoDb.scan(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, data.Items);
  });
};

Create To-do

接著我們試著新增一筆 to-do：

$ http POST https://<省略>/todos body="Hodor"

新增成功並回傳一筆包含 id、body 和 updateAt 欄位的 to-do item：

HTTP 200 OK

{
    "body": "Hodor",
    "id": "1b691310-a0e7-11e7-b1c4-1d790783726f",
    "updatedAt": 1506230011585
}

Create 的 Lambda Function 也很好懂，透過 UUID 以及 DynamoDB 的 put API 新增一筆 to-do item：

...
const uuid = require('uuid');

module.exports = (event, callback) => {
  const data = JSON.parse(event.body);

  data.id = uuid.v1();
  data.updatedAt = new Date().getTime();

  const params = {
    TableName: 'todos',
    Item: data
  };

  return dynamoDb.put(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, params.Item);
  });
};

Read One To-do

接著我們試著讀取剛才新增的 id 為 1b691310-a0e7-11e7-b1c4-1d790783726f 的 to-do：

$ http GET https://<省略>/todos/1b691310-a0e7-11e7-b1c4-1d790783726f

HTTP 200 OK
{
    "body": "Hodor",
    "id": "1b691310-a0e7-11e7-b1c4-1d790783726f",
    "updatedAt": 1506230011585
}

這裡要注意，DynamoDB 讀取所有 items 所使用 API 是 scan，讀取單筆 item 的 API 是 get：

...
module.exports = (event, callback) => {
  const params = {
    TableName: 'todos',
    Key: {
      // 透過 event.pathParameters 來取得 URL 的 todo item id
      id: event.pathParameters.id
    }
  };
  return dynamoDb.get(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, data.Item);
  });
};

Update To-do

更新已經存在的單筆 to-do：

$ http PUT https://<省略>/todos/1b691310-a0e7-11e7-b1c4-1d790783726f body="Hold The Door"

HTTP 200 OK

{
    "body": "Hold The Door",
    "id": "1b691310-a0e7-11e7-b1c4-1d790783726f",
    "updatedAt": 1506230311609
}

更新 DynamoDB item 的程式碼基本上與新增的方式差不多：

...
module.exports = (event, callback) => {
  const data = JSON.parse(event.body);
  data.id = event.pathParameters.id;
  data.updatedAt = new Date().getTime();
  const params = {
    TableName : 'todos',
    Item: data
  };
  return dynamoDb.put(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, params.Item);
  });
};

Delete To-do

最後剩下刪除已存在的單筆 to-do：

$ http DELETE https://<省略>/todos/1b691310-a0e7-11e7-b1c4-1d790783726f

HTTP 200 OK

{
    "id": "1b691310-a0e7-11e7-b1c4-1d790783726f"
}

刪除的 Lambda Function 程式碼：

module.exports = (event, callback) => {
  const params = {
    TableName : 'todos',
    Key: {
      id: event.pathParameters.id
    }
  };
  return dynamoDb.delete(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, params.Key);
  });
};

基礎設施即程式碼

跑完上面的 to-do services 之後有沒有感到很神奇呢？竟然一個 serverless deploy 指令，就可以把原本需要手動配置的所有 AWS 基礎服務都自動建立好了，這是因為 Serverless Framework 用到了 AWS CloudFormation 這個服務。

我們先打開 serverless.yml 這個檔案來看看 Lambda Function 和 API Gateway 的配置：

functions:
  create:
    ...
  readAll:
    ...
  readOne:
    handler: handler.readOne
    events:
      - http:
          path: todos/{id}
          method: get
          ...
  update:
    ...
  delete:
    ...

DynamoDB 的設定：

resources:
  Resources:
    TodosDynamoDbTable:
      ...
      Properties:
        AttributeDefinitions:
          -
            AttributeName: id
            AttributeType: S
        KeySchema:
          -
            AttributeName: id
        ...
        TableName: 'todos'

這就是 Infrastructure as a Code（基礎設施即程式碼）的威力，它的好處：

隨地配置：直接使用程式碼控制你的基礎設施資源，忘記那些繁瑣的操作流程
易於維護：因為程式碼可以上版本控制，所以可以多人共同維護一份基礎設施
持續交付：因為可以進版本控制，所以更容易整合進 CI/CD 的自動化流程

結論

XaaS（萬物皆服務）是未來的趨勢，而服務的本質就是 API，誰能夠越快地開發出原型、越有機會成功
如果要用 AWS 的無伺服器架構來開發 REST API，核心服務分別是 Lambda、API Gateway 和 DynamoDB
Serverless Framework 利用「基礎設施即程式碼」的概念，讓開發者可以更迅速地在 AWS 上建立一套可維護的 CRUD RESTful API Services

參考文章

Mock Server＆契約測試

Sat, 26 Aug 2017 00:00:00 GMT

這篇文章會介紹如何運用 Mock Server 和 Integration Contract Test（契約測試）解決一些在前後端分離的開發環境底下會碰到的問題。

大綱如下：

什麼是 Mock Server？
為什麼需要 Mock Server？
如何使用 Mock Server？
什麼是契約測試？
為什麼需要契約測試？

什麼是 Mock Server？

下圖是傳統的前後端分離架構：

當後端 API 還沒開發完成的時候，前端會需要一個可以暫時回應假資料（mock data）的 mock server，如下圖：

等到後端的 API 開發完成之後，前端只需要將 API endpoint 從 mock server 切回 remote server 就可以使用真實資料，如下圖：

為什麼需要 Mock Server？

一句話，因為有了 Mock Server 之後，前後端就能夠並行開發。

如何使用 Mock Server？

這裡會介紹兩種方法：

Postman Mock Service
Puer Mock Server

Postman Mock Service

Postman 是前後端在開發上很常用到的一款 HTTP Client 應用程式，主要是拿來測試 API，除了有好用的 Collection Test Runner 之外（詳見《基於 Postman 的 API 自動化測試》），其實 Postman 還有提供 Mock Service 的功能，大致流程如下：

送出一個 request（R1）
儲存 R1 至 Collection（C1）
編輯 R1 的 response，儲存成為一個 example（P1）
建立一個 C1 的 Mock Server（M1）
再次向 M1 送出 R1，即會收到格式為 P1 的 response

詳細操作方法請見官方教學文章《Mocking with examples》。

但是使用 Postman Mock Service 會碰到一個問題，雖然 Postman 可以同時 mock 多筆 API，但是一個頁面可能會同時存在「需要 mock 的 API」和「後端已經寫好的 API」。

Puer Mock Server

為了解決上面碰到的問題，找到了這個 open-source 的 mock server：puer-mock。

它可以將沒有 mock 的 API route 經由 proxy 導向後端的 API server，示意圖如下：

安裝＆使用步驟如下：

$ npm install --save puer puer-mock

新增 mock.json，加入一筆 mock route（以 GET /api/users 為例）：

{
    "api": {
        "GET /api/users": {
            "response": {
                "foo": "bar"
            }
        }
    }
}

其中 response 的部分就是你自定義的 mock data。

新增 server.js：

module.exports = require('puer-mock')(__filename, './mock.json') ;

修改 package.json：

{
    "scripts": {
        "start": "puer -a server.js"
    }
}

如果要 proxy 後端的 API server，可以加上 -t 或 --target：

{
    "scripts": {
        "start": "puer -a server.js -t http://<YOUR_API_SERVER_HOST>"
    }
}

啟動 mock server：

$ npm start

測試 mock API：

$ curl http://localhost:8080/api/users

{
    "foo": "bar"
}

更多的配置可以參考 puer-mock、puer 和 Mock.js。

什麼是契約測試？

契約測試（Integration Contract Test）的流程大致如下：

前後端在開發之前先約定好契約，也就是 API 的 spec（常見如 Swagger、RAML、API Blueprint 或 apiDoc）
後端根據這份契約開發 remote server（API server）
前端根據這份契約建立 mock server
撰寫契約測試，驗證雙方的 request 和 response 是一致的
將契約測試上 CI server

示意圖如下：

為什麼需要契約測試？

防止前後端其中一方更改 API 之後，另一方卻不知情（因為 CI 會失敗）
契約需要一直保持在最新的狀態，代表 API 文件有人維護

結論

有一個 Mock Server 對於前後端的並行開發是有幫助的
加入契約測試可以避免前後端任一方修改 API 之後，導致另一方程式崩潰的狀況
API 文件有人維護

最後，如果再整合進「前端的 E2E 測試」和「後端的 API 測試」，架構的示意圖大概如下：

相信這對整個團隊的開發穩定度會有很大的幫助，從此前端與後端過著幸福快樂的日子。

參考資料

如何使用 Docker 切換不同的 MongoDB

Sat, 22 Jul 2017 00:00:00 GMT

在開發前端的時候，常常會碰到想要回到 migration 之前的 MongoDB 資料結構來除錯，如果只使用本地安裝的 MongoDB，操作上會很麻煩，所以這篇文章會說明如何在本機不安裝 MongoDB 的環境下，使用 Docker 準備多份 MongoDB 資料庫。

請確認電腦有安裝 Docker，先準備好要使用的 MongoDB 資料庫備份檔案，大概會是長這樣：

存放的路徑這裡暫定為 ~/Downloads/20170622/foo/...。

打開 Terminal，下載 MongoDB（這裡以 2.6 版作為示範）的 Docker image：

$ docker pull mongo:2.6

然後開啟一個新的 MongoDB Docker container，container 名字可以透過 --name 自訂：

$ docker run --detach --name mongo_foo_20170622 --publish 27017:27017 mongo:2.6

使用 docker inspect 取得 container 的 IP，後面會用到：

$ docker inspect mongo_foo_20170622 | grep IPAddress

前往剛才存放備份資料庫的位置：

$ cd ~/Downloads

開啟並進入一個暫時性質的 Docker container，用途為 restore 資料庫到 mongo_foo_20170622 的 container：

$ docker run --interactive --tty --rm --volume $PWD:/tmp mongo:2.6 bash

因為 ~/Downloads 被 volume 在 /tmp 底下，所以可以根據對應的路徑前往該資料庫存放的資料夾位置：

$ cd /tmp

使用 mongorestore 恢復備份資料庫到 mongo_foo_20170622，IP 記得使用上面 docker inspect 查到的 IP：

$ mongorestore --host 172.17.0.2 --db foo 20170622/foo

如果順利 restore 完成之後，就可以離開，它會自動刪除這個一次性的 container：

$ exit

之後如果還有其它版本的 MongoDB 想要切換著使用的話，可以繼續從第一個步驟建立新的 container。

順帶一提，Docker for Mac 有內建一個叫 Kitematic 的 Docker GUI，可以使用它來切換不同版本的 MongoDB：

使用 Google Docs 將圖片轉成文字

Wed, 28 Jun 2017 00:00:00 GMT

像我這種日文不好、需要靠翻譯工具作參考的人，有時候想翻譯雜誌這種長文會很麻煩。

以前會找一些網路上的 OCR 工具，最近才發現原來 Google Docs 就提供這樣的功能！而且還很強大！ヽ(●´∀`●)ﾉ

以下圖為例，假如我想要翻譯底下那塊專欄的話：

先將文字區塊裁剪成一張圖檔：

上傳圖片到 Google 雲端硬碟
點選右鍵 > 選擇開啟工具 > Google 文件

等待它轉換完成之後，就會產生一份帶有文字檔案的 Google 文件：

完成！Google Docs 提供的圖片轉文字功能有以下特色：

語言自動判斷，日文也沒問題 (´艸`)
橫書＆直書自動判斷，這個有點厲害 🌚
相較於其它的 OCR 服務，Google Docs 在內容上的判斷準確率很高！

從此翻譯雜誌的效率大幅提升｡:.ﾟヽ(*´∀`)ﾉﾟ.:｡

如何解決 GPG 失效的問題？

Sat, 24 Jun 2017 00:00:00 GMT

我是用 cider 在管理自己的 dotfiles，然後前陣子因為 gnupg 的 formula 剛好一起被更新，導致我的 GPG signature verification 無法順利運作。

解決方式：

$ brew unlink gnupg && brew link gnupg

如果有跳出某些 conflicting error 的話，可以照著提示解決，例如：

Linking /usr/local/Cellar/gnupg/2.1.21...
Error: Could not symlink bin/gpg-agent
Target /usr/local/bin/gpg-agent
is a symlink belonging to gpg-agent. You can unlink it:
  brew unlink gpg-agent

To force the link and overwrite all conflicting files:
  brew link --overwrite gnupg

To list all files that would be deleted:
  brew link --overwrite --dry-run gnupg

然後再重新 link gnupg 一次：

$ brew unlink gnupg && brew link gnupg

最後檢查 Git 能不能順利 commit 和 push，然後確認 GitHub 的 commits 有出現 verified signature 的話，表示順利修復成功。

如何發送 redux-observable 的 catch error 至 Sentry

Sat, 24 Jun 2017 00:00:00 GMT

我們團隊目前使用 Sentry 這個服務作 error tracking，JavaScript 或 React 的基本安裝方法在官方文件都可以找到，這裡就不贅述。

同時我們也有在使用 redux-observable 這個 RxJS middleware 來處理帶有副作用的 Redux action。

根據 redux-observable 這篇 Error Handling 文件的介紹，一般處理 async 錯誤的寫法大概會是：

import { createAction } from 'redux-actions';
import { Observable } from 'rxjs/Observable';

const fetchUserEpic = action$ =>
  action$.ofType(FETCH_USER)
    .mergeMap(action =>
      Observable.fromPromise(fetch(`/api/users/${action.payload}`))
        .map(response => createAction('FETCH_USER_FULFILLED')(response))
        .catch(error => Observable.of(createAction('FETCH_USER_REJECTED')(error.message)))
    );

但是因為這裡並非正規的錯誤拋出方式，導致 Sentry 無法攔截到。

所以根據 Sentry 的這篇 Rich Error Reports with Redux Middleware 文件介紹，我們需要另外為它寫一個 Redux middleware 來處理。

策略是利用 redux-actions 的 Flux Standard Action 特性，將錯誤用 JavaScript 的 Error object 封裝至 action payload：

...
        .catch(error => Observable.of(createAction('FETCH_USER_REJECTED')(new Error(error.message))))
// => {
//   type: 'FETCH_USER_REJECTED',
//   payload: new Error(error.message),
//   error: true,
// }
...

然後寫一個 Redux middleware 去攔截這類 actions：

import Raven from 'raven-js';

Raven.config(process.env.REACT_APP_RAVEN_DSN).install();

const errorReporter = store => next => action => {
  if (action.error) {
    const error = action.payload;

    Raven.captureException(error, {
      extra: {
        action,
        state: store.getState(),
      },
    });

    throw error;
  }

  return next(action);
};

export default errorReporter;

最後將這個 middleware 載入 Redux store：

import { createStore, combineReducers, applyMiddleware } from 'redux';
import * as reducers from './reducers';
import errorReporter from './errorReporter';

const rootReducer = combineReducers(reducers);

const middleware = applyMiddleware(
  errorReporter, // 注意：errorReporter 要放在其它 middlewares 之前
  // epicMiddleware, routerMiddleware, etc...
);

export default (initialState = {}) =>
  createStore(
    rootReducer,
    initialState,
    middleware,
  );

參考資料

如何自動化 release 的流程？

Tue, 24 Jan 2017 00:00:00 GMT

這篇文章會介紹如何使用 semantic-release 這個工具，自動化 Node.js (or JavaScript) 專案的版本號，以及 changelog 的 release 流程。

什麼是 semantic-release？
為什麼要用 semantic-release？
如何使用 semantic-release？

什麼是 semantic-release？

semantic-release 可以自動完成下列這些事：

當 code 被 push 或 merge PR 回 production branch (ex: master) 的時候
CI build 被觸發，semantic-release 會收集此次更新的所有 commit messages（需遵循 AngularJS Git Commit Message Conventions 的格式）
自動根據 semver 的規則來更新 package.json 的 version，並建立 Git tag
自動 publish 新版本的 package 到 npm registry（非必要）
自動在 GitHub releases 的頁面上，產生相對應的 changelog

所以簡單來講，semantic-release 指的就是遵循 semver 的 release 流程。

semver 的介紹和好處可以在網路上找到很多文章，這裡就不贅述了，它的概念主要就是將版本號分成：

Major.Minor.Patch

例如 React 的 0.11.2、Vue.js 的 2.0.10 等，這三個數字各自代表：

Major

當你的 API 不兼容前一版本時（又稱 Breaking Change），major + 1，例如：1.x.x -> 2.0.0。

Minor

當你增加新 feature 的時候，並且不影響前一版本的 API，minor + 1，例如：x.6.x -> x.7.0。

Patch

當你修復 bug 的時候，並且不影響前一版本的 API，patch + 1，例如：x.x.9 -> x.x.10。

如果專案有在執行 git-flow 的話，minor 配合的就是 feature 的 release flow，patch 則是 hotfix 的 release flow。

為什麼要用 semantic-release？

先來看看如果我們想要完成上面列出的目的，傳統的 release 作法會是怎樣？

首先，在你開發的過程中，無數次傳奇般的 code 被你給 commit 了上去：

$ git commit -m "blablabla…"

在你準備好 release 這段即將改變世界的更新時，你必須先手動給 package.json 改版號，一般會用到 npm version 的指令：

$ npm version [<newversion> | major | minor | patch | ...]

再來，你會手動建立 Git tag，並且將這次的更新 push 到 production 分支（或是送 PR 給 reviewer merge）：

$ git push origin master --tags

接下來，如果你還想將新版本發佈到 npm 騙星星的話：

$ npm publish

最後，為了更新 GitHub releases 頁面來告知大家你更新了些什麼，你通常必須在 Git logs 的茫茫大海之中找出這次 commits 的內容，然後手動撰寫 changelog⋯⋯：

但是，如果我們用 semantic-release 的話，只需要：

$ git commit -m "fix: blablabla..."
$ git push origin master

如何使用 semantic-release？

安裝 semantic-release

安裝 semantic-release-cli，並在你的專案底下執行 semantic-release-cli setup（注意：必須是 npm init 和 git init 過的專案）：

$ npm install -g semantic-release-cli
$ cd YOUR_PROJECT
$ semantic-release-cli setup

回答完問題之後，package.json 會加入下面這段程式：

"scripts": {
    "semantic-release": "semantic-release pre && npm publish && semantic-release post"
},

如果你不打算發佈專案到 npm registry 的話，可以移除 npm publish 這段 code。

另外，semantic-release 也會幫你建立一份 .travis.yml 給 Travis CI 使用，如果你是用其它 CI 工具的話，可以參考這份配置來撰寫自己的腳本。

...
after_success:
  - npm run semantic-release
...

注意：記得在 CI 服務上新增 NPM_TOKEN 及 GH_TOKEN 兩個環境變數給 semantic-release 使用。

到這裡，基本上已經完成前置作業了，更詳細的設定可以參考 semantic-release 的 README。

使用 semantic-release 的流程

要讓 semantic-release 可以順利運作，其中最關鍵的是部份是團隊必須遵守 AngularJS Commit Message Conventions 的 commit message 撰寫規範。

每一個 commit message 是由 header、body 和 footer 組成，其中 header 是由 type、scope 和 subject 組成：

<type>(<scope>): <subject>
<body>
<footer>

scope、body 和 footer 是可以根據情況省略的，例如只寫：

<type>: <subject>

這些關鍵字各自代表的作用在 conventional-changelog-angular 有很詳細的介紹，這裡就不一一贅述了，推薦閱讀 Commit message 和 Change log 编写指南。

有了 commit message conventions 之後，搭配一開始提到的 semver，我們就可以開始發揮 semantic-releaseChangelog-driven Development 的魔力了！

Patch Release

$ git commit -m "fix(payment): 修正「大眾銀行」無法付款的問題"

當上面這段帶有 fix 關鍵字的 commit 被 merge 回 master 之後，semantic-release 就會自動更新 patch 版號（例如：x.x.9 -> x.x.10），並且自動出現在 GitHub Releases 的 Bug Fixes 之中。

Minor (or Feature) Release

$ git commit -m "feat(video): 影片播放器新增「字幕位置」的選項"

當上面這段帶有 feat 關鍵字的 commit 被 merge 回 master 之後，semantic-release 就會自動更新 minor 版號（例如：x.6.x -> x.7.0），並且自動出現在 GitHub Releases 的 Features 之中

Major (or Breaking) Release

$ git commit -m "pref(...): blablabla...
BREAKING CHANGE: blablabla..."

當上面這段帶有 BREAKING CHANGE 關鍵字的 commit 被 merge 回 master 之後，semantic-release 就會自動更新 major 版號（例如：1.x.x -> 2.0.0），並且加入 GitHub Releases。

結論

semantic-release 很巧妙地結合了 semver 和 commit message conventions 來完成 Git tag、npm version 和 GitHub releases changelog 的自動化
學習了 Changelog-driven Development 的思維方式

Amazon S3 正確處理 HTML5 History 路由問題

Mon, 06 Jun 2016 00:00:00 GMT

如果你是使用 Angular、React 或是 Vue 來開發 SPA（單頁面應用），並且放在 Amazon S3 Static Website Hosting 上的話，那麼你會碰到 URL routing 的問題。

一般 react-router 或 vue-router 都預設使用 hash 的方式來處理 SPA 的路由：

http://domain.com/#!/paths

如果你不喜歡 #!/ 的顯示方式，可以使用 HTML5 的 History API，這樣就能像一般網站那樣顯示 URL：

http://domain.com/paths

但是使用 HTML5 History API 時，通常必須搭配 server 端正確的路由配置才能防止出現 404 Not Found 的情形。

遺憾的是，在 Amazon S3 Static Website Hosting 上，你無法更動 Apache 或 Nginx 的配置，所以需要靠其它方式來解決問題。

使用 S3 的 Redirection Rules
使用 CloudFront 的 Custom Error Response

使用 S3 的 Redirection Rules

Amazon S3 Static Website Hosting 提供了 Edit Redirection Rules 的選項，我們可以輕鬆使用這段程式碼將所有 domain.com/#!/paths 所產生的 404，全部重新導向至根路徑：

<RoutingRules>
  <RoutingRule>
    <Condition>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <HostName>你的網域（例：domain.com）</HostName>
      <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
    </Redirect>
  </RoutingRule>
</RoutingRules>

然後在你的 app 開始處，加入這段 JavaScript 來將 /#!/paths rewrite 成 /paths：

<!-- index.html -->
<script>
  history.pushState({}, "index.html", location.hash.substring(2));
</script>

History API 在各個瀏覽器上的使用方式都不盡相同，這裡我們就省略了判斷的程式碼。

使用 CloudFront 的 Custom Error Response

如果你有使用 Amazon CloudFront 來幫 S3 Static Website Hosting 加入 CDN 的話，那解決方式就更簡單了：

前往你的 CloudFront Distribution
選擇 Error Pages 標籤，點選 Create Custom Error Response 建立自訂的錯誤回應
HTTP Error Code 選擇 404: Not Found
Error Caching Minimum TTL 輸入 0
Customize Error Response 選擇 Yes
Response Page Path 輸入 /index.html
HTTP Response Code 選擇 200: OK
點選 Create 完成

如何正確處理 AWS API Gateway 的 Lambda Error Status

Wed, 09 Mar 2016 00:00:00 GMT

翻譯自原文 Error handling in AWS API Gateway with Lambda

這篇文章會介紹如何設置 AWS API Gateway 正確處理 Lambda 返回的 HTTP 錯誤狀態碼。

更新：2016.03.12 claudia 可以自動化解決這個問題，詳細可以參考這篇文章。

本文假設讀者已經知道如何利用 AWS API Gateway 和 Lambda 建立 REST API，詳細可參考 Create API Gateway API for Lambda Functions。

假設你的 Lambda function 錯誤處理如下：

console.log('I am a AWS Lambda function');

exports.handler = function(event, context) {
    // 一般使用 context.fail 來返回 Lambda function 錯誤
    context.fail(JSON.stringify({status:'fail', reason:'some reason', foo:'bar'}));
};

但是 API Gateway 返回的結果會是 HTTP 200：

HTTP/1.1 200 OK
...

{
    "errorMessage": "{\"status\":\"fail\",\"reason\":\"some reason\",\"foo\":\"bar\"}"
}

我們希望的結果是：

HTTP Status 400 Bad request
只顯示 errorMessage 的 JSON 值

1. 新增 HTTP Status 400 Method Response

前往 API Gateway Console
進入 Method Execution
進入 Method Response
點選 Add Response
輸入 HTTP Status 400
點選 Add Response Model
輸入 Content type application/json、Models Error

2. 新增 Lambda Error Regex Integration Response

進入 Integration Response
點選 Add integration response
輸入 Lambda Error Regex .*status.*fail.*、Method response status 400

3. 設置 Mapping Templates

展開 Mapping Templates
點選 Add mapping template
輸入 Content-Type application/json
點選 Output passthrough 並改成 Mapping Templates
輸入以下程式碼：

4. 部署 API

記得點選 Deploy API 完成 API 的更新，然後測試返回結果是否為 HTTP 400。

HTTP/1.1 400 Bad Request
...

{
    "foo": "bar",
    "reason": "some reason",
    "status": "fail"
}

解決 Universal 架構的 CSS Modules 問題

Sat, 05 Dec 2015 00:00:00 GMT

最近在使用 React 和 Redux 建構一個 Isomorphic JavaScript （Universal）應用。

但是在實作 CSS Modules 的時候，會碰上兩個問題：

Server-side 的 Node.js 無法 import *.css。
如果改成使用 process.env.IS_BROWSER 來判斷只在 Client-side import，那又會碰到 Server-side 與 Client-side render 出來的 DOM 結果不一致的問題。

解決方式：

安裝 css-modules-require-hook 這個套件：

npm install css-modules-require-hook --save-dev

修改 webpack config 的 css-loader 設定：

{
  // ...
  module: {
    loaders: [{
      test: /\.css$/,
      loader: 'style-loader!css-loader?modules&localIdentName=[name]__[local]___[hash:base64:5]!!postcss-loader'
    }]
  }
  // ...
}

在 Node.js 的 main file 加入 css-modules-require-hook：

require('css-modules-require-hook')({
  generateScopedName: '[name]__[local]___[hash:base64:5]'
});
// ...

注意 generateScopedName 的命名格式，必須與 css-loader 的 localIdentName 保持一致。

Serverless！使用 AWS 開發 Slack Slash Commands

Sat, 05 Dec 2015 00:00:00 GMT

本文介紹如何使用 AWS Lambda & AWS API Gateway 搭建一個不需要伺服器的環境，提供 Slack Slash Commands 查詢豆瓣電影。

這篇文章使用到的技術：

閱讀這篇文章需要具備什麼能力：

Node.js 的基本能力
Amazon Web Services 的基本操作

接下來我會逐步講解這些東西：

Slack Slash Commands 的運作機制
建立一個簡單的 AWS Lambda function
建立一個簡單的 AWS API Gateway 執行 Lambda function
使用 Lambda 呼叫豆瓣電影 API
測試 AWS API Gateway
將 API Gateway endpoint 加入至 Slack Slash Command

Slack Slash Commands 的運作機制

當你在 Slack channel 輸入 /movie 權力的遊戲，Slack 會發出一個 content-type Header 設為 application/x-www-form-urlencoded 的 HTTP POST 請求，格式如下：

token=YOUR_SLASH_COMMAND_TOKEN
team_id=YOUR_TEAM_ID
team_domain=YOUR_TEAM_DOMAIN
channel_id=YOUR_CHANNEL_ID
channel_name=YOUR_CHANNEL_NAME
user_id=YOUR_USER_ID
user_name=YOUR_USER_NAME
command=/movie
text=權力的遊戲
response_url=YOUR_HOOK_URL

然後 Slack 需要收到的 JSON 回應格式如下（詳見 Attachments）：

{
  "response_type": "in_channel",
  "attachments": [
    {
      "title": "權力的遊戲 第五季",
      "title_link": "http://movie.douban.com/subject/25826612/",
      "text": "Game of Thrones\n2015年",
      "fields": [
        {
          "title": "導演",
          "value": "Michael Slovis\n...",
          "short": true
        }, ...
      ],
      "thumb_url": "https://img1.doubanio.com/view/movie_poster_cover/ipst/public/p2230256732.jpg"
    }
  ]
}

responsetype: inchannel 表示 channel 內的使用者都可以看見，若只想給使用命令的本人看的話可以改成 ephemeral

Slack Slash Commands 有 3000 ms 的 response timeout 限制

建立一個簡單的 AWS Lambda function

前往 AWS Lambda
點選 Create a Lambda function
填寫 Configure function，例：slackFunction
Runtime 選擇 Node.js
Code entry type 選擇 Edit code inline，輸入簡單的測試程式碼：

exports.handler = function(event, context) {
  context.succeed("你好世界!");
};

Role 使用 lambdabasicexecution
點選 Next 完成建立
點選 Test 測試結果：

你好世界!

建立一個簡單的 AWS API Gateway 執行 Lambda function

前往 AWS API Gateway
點選 New API
填寫 API name，例：Slack API
點選 Create API 完成新增
點選 Create Resource
填寫 Resource Name & Resource Path，例：movie
點選 /movie
點選 Create Method
選擇 POST
Integration type 選擇 Lambda Function
選擇 Lambda Region
填寫 Lambda Function，例：slackFunction
點選 Save 完成建立
點選 Test 測試結果：

你好世界!

使用 Lambda 呼叫豆瓣電影 API

豆瓣電影搜索 API 的格式如下：

GET https://api.douban.com/v2/movie/search?q={text}

例：https://api.douban.com/v2/movie/search?q=權力的遊戲

{
  "count": 20,
  "start": 0,
  "total": 130,
  "subjects": [
    {
      "rating": {...},
      "genres": [...],
      "collect_count": 47770,
      "casts": [
        {...}, ...
      ],
      "title": "权力的游戏 第五季",
      "original_title": "Game of Thrones",
      "subtype": "tv",
      "directors": [
        {...}, ...
      ],
      "year": "2015",
      "images": {...},
      "alt": "http://movie.douban.com/subject/25826612/",
      "id": "25826612"
    }, ...
  ],
  "title": "搜索 \"權力的遊戲\" 的结果"
}

取代 Edit code inline，在本地建立一個 Node.js Lambda project：

$ npm init

加入一個支持 promise 的 XMLHttpRequest 庫：

$ npm install request-promise --save

新增 index.js：

var rp = require('request-promise');
exports.handler = function(event, context) {
  // 從傳進來的參數之中提取要搜尋的字串
  var text = event.text ? event.text.trim() : null;

  // 向豆瓣 API 發出 HTTP GET 請求
  rp('https://api.douban.com/v2/movie/search?q=' + text)
    .then(function(data) {
      // 回傳成功的結果
      context.succeed(data);
    }).catch(function(error) {
      // 回傳失敗的結果
      context.fail(error);
    });
};

將檔案壓縮成 lambda.zip：

./index.js
./node_module/request-promise

回到 AWS Lambda
點選之前建立的 function，例：slackFunction
將 Code entry type 從 Edit code inline 改為 Upload a .ZIP file
上傳 lambda.zip
點選 Actions > Configure test event，加入測試用的請求

{
  "text": "權力的遊戲"
}

點選 Test 測試豆瓣回應的結果：

{
  // ...
  "subjects": [
    {
      // ...
      "title": "权力的游戏 第五季",
      // ...
    }, ...
  ],
  "title": "搜索 \"權力的遊戲\" 的结果"
}

測試 AWS API Gateway

回到 AWS API Gateway
點選 /movie 的 POST method
點選 Test，並在 Request Body 加入測試用的請求：

{
  "text": "權力的遊戲"
}

點選 Test 測試 Lambda 回應的豆瓣結果：

{
  // ...
  "subjects": [
    {
      // ...
      "title": "权力的游戏 第五季",
      // ...
    }, ...
  ],
  "title": "搜索 \"權力的遊戲\" 的结果"
}

將 API Gateway endpoint 加入至 Slack Slash Command

因為 Slack 發送的請求 Header 格式是 application/www-form-urlencoded，所以需要在 AWS API Gateway 之中將它轉換成為 application/json 格式：

點選 /movie 的 POST method
點選 Method Execution
點選 Integration Request
點選 Mapping Templates
點選 Add mapping template
Content-Type 填寫 application/www-form-urlencoded
將 Input passthrough 改成 Mapping template
貼上 Ryan Ray 提供的 template gist
Save
最後，一定要記得把 API Gateway 部署給外部使用：
點選 Deploy API
Deployment stage 選擇 New Stage
填寫 Stage name，例：development
點選 Deploy 完成發佈
然後會得到一個 Invoke URL 格式如下：

https://{hash}.execute-api.{region}.amazonaws.com/{stage}/movie

接下來的步驟，把 AWS API Gateway endpoint 整合進 Slack：

前往 https://YOURTEAMDOMAIN.slack.com/apps/manage
在 Search app directory 搜尋框輸入 Slash Commands 並進入
點選 Add Configuration
填寫 Choose a Command，例：/movie
點選 Add Slash Command Integration
填寫 URL，貼上 AWS API Gateway Invoke URL
Method 選擇 POST
點選 Save Integration 完成新增

最後一個步驟，更新 Lambda function，讓它可以處理 Slack 的請求與回應：

var rp = require('request-promise');
exports.handler = function(event, context) {
  /**
   * event 會收到來自 AWS API Gateway 轉換過的 Slack POST JOSN
   * {
   *   token=YOUR_SLASH_COMMAND_TOKEN
   *   team_id=YOUR_TEAM_ID
   *   team_domain=YOUR_TEAM_DOMAIN
   *   channel_id=YOUR_CHANNEL_ID
   *   channel_name=YOUR_CHANNEL_NAME
   *   user_id=YOUR_USER_ID
   *   user_name=YOUR_USER_NAME
   *   command=/movie
   *   text=權力的遊戲
   *   response_url=YOUR_HOOK_URL
   * }
   */
  if(event.token !== 'YOUR_SLASH_COMMAND_TOKEN') {
    return context.fail('未經授權的請求');
  }
  var text = event.text ? event.text.trim() : null;

  // 向豆瓣 API 發出 HTTP GET 請求
  rp('https://api.douban.com/v2/movie/search?q=' + text)
    .then(function(data) {
      // 提取第一筆電影的結果
      var subject = data.subjects[0];
      // 將豆瓣 API 返回的結果包裝成 Slack 支持的格式
      var result = {
        "response_type": "in_channel",
        "attachments": [{
          "title": subject.title,
          "title_link": subject.alt,
          "text": subject.original_title+"\n"+subject.year+"年",
          "fields": [
            {
              "title": "導演",
              "value": subject.directors[0].name,
              "short": true
            }
          ],
          "thumb_url": subject.images.small
        }]
      };
      // 回傳結果
      context.succeed(result);
    }).catch(function(error) {
      // 回傳失敗的結果
      context.fail(error);
    });
};

重新壓縮 lambda.zip 然後上傳
在 Slack channel 輸入 /movie 測試結果

總結

熟悉之後，稍微修改一下，把豆瓣 API 換成其它 API，又可以誕生出更多有趣的 Slash Commands！
2015/12/30: 更新範例 GitHub repo Google 大神
因為 Slack 有 3 秒的回應限制，所以 API 不穩的話，常常容易發生 timeout，解決方法可以參考 Slack 提供的方式Delayed responses and multiple responses，或是提高 Lambda 的 Memory（建議 512 以上），也可使用 AWS SNS 之類的服務處理非同步的 Lambda invoke。
特別感謝 Ryan Ray 寫的文章 Serverless Slack Integrations with node.js, AWS Lambda, and AWS API Gateway

如何在發布自己的 NPM package 之前打包檔案

Wed, 02 Dec 2015 00:00:00 GMT

最近 Bower 宣布停止維護，所以許多前端的 packages 都移到了 NPM 上，甚至連 Grunt 和 Gulp 這類 build tools 都有要被 NPM scripts 取代的趨勢。

這篇文章主要是紀錄怎麼在發布自己的 package 之前，打包好需要的檔案。

假設你會使用 Grunt 或 Gulp 將所有原始碼打包存成一支檔案，例如 dist/build.js，但是因為通常我們不會把 dist 這類輸出文件放進版本控制，所以要在每次發布新版本的時候動態打包。

方法是在 package.json 的 script 底下新增一個 prepublish 的腳本，然後把你的打包命令寫在這裡：

{
  "script": {
    "prepublish": "..." // grunt or gulp
  }
}

接下來是透過 main 指定程式的進入位置，讓其他人在使用的時候可以正常的 require 或 import 你的 package。

預設的檔案通常是 index.js，這裡我們把它改成剛剛打包完成的 dist/buid.js ：

{
  "main": "dist/build.js"
}

最後也是最重要的部分，記得在專案根目錄新增一份 .npmignore 的空檔案，因為如果沒有它，NPM 在發布的時候會參考 .gitignore 的清單來決定哪些檔案不能被發布，而通常 dist 就會在這裡面，所以要將它從 .npmignore 裡面移除。

都準備完成之後就可以發布了，如果你還沒有 NPM 的帳號，可以註冊一個：

npm adduser

然後發布新版本：

npm publish

記得更新 package.json 的 version 才能發布。

發布成功之後前往 http://npmjs.com/package/name 看結果：

完整專案可以參考我的 GitHub

參考文章

Publishing npm packages

Code Coverage with CircleCI + Codecov

Mon, 02 Nov 2015 00:00:00 GMT

最近的案子用到 Redux + React，因為它 Pure Function 的特性，所以單元測試很容易寫，順便也趁機會玩一下程式碼覆蓋率（Code Coverage）。

單元測試 Unit Test

這裡就不講單元測試怎麼寫了，網路上有很多大神的好文可以爬，我是用 Mocha + Chai ：

mocha 是 test framework，提供 describe、it
chai 是 assertion library，提供 assert、should、expect

安裝 Gulp ：

npm install --save-dev gulp gulp-mocha

安裝 Babel 讓程式支援 ES6 語法：

npm install --save-dev babel

加入 mocha 到 gulpfile.babel.js ：

import gulp from 'gulp';
import mocha from 'gulp-mocha';

gulp.task('mocha', () => {
  return gulp.src('test/**/*.js')
    .pipe(mocha());
});

使用 npm test 取代 gulp mocha ：

{
  "scripts": {
    "test": "gulp mocha"
  }
}

這樣做的好處：

gulp 可不用 -g 全域安裝
CI 會自動執行測試

程式碼覆蓋率 Code Coverage

有許多提供 code coverage review 的服務，例如： Code Climate、 Codecov、 Coveralls。這裡選擇 Codecov ，因為它的 GitHub public repo 方案是免費的。

安裝 istanbul 產生 coverage report：

npm install --save-dev gulp-istanbul isparta

isparta 讓 istanbul 支援 ES6

加入 coverage 到 gulpfile.babel.js ：

import istanbul from 'gulp-istanbul';
import { Instrumenter } from 'isparta';

gulp.task('coverage:instrument', () => {
  return gulp.src('src/**/*.js')
    .pipe(istanbul({
      instrumenter: Instrumenter,
      includeUntested: true
    }))
    .pipe(istanbul.hookRequire())
})

gulp.task('coverage:report', () => {
  return gulp.src('src/**/*.js')
    .pipe(istanbul.writeReports())
})

gulp.task('coverage', done => {
  runSequence('coverage:instrument', 'mocha', 'coverage:report', done)
})

gulp coverage 會依順序執行：

gulp coverage:instrument 配置單元測試的原始碼
gulp mocha 執行單元測試
gulp coverage:report 產生覆蓋率報告

把 npm test 換成 gulp coverage ：

{
  "scripts": {
    "test": "gulp coverage"
  }
}

最後配置 CircleCI，當測試成功之後，自動上傳覆蓋率報告至 Codecov ：

npm install --save-dev codecov.io

test:
  post:
    - cat ./coverage/lcov.info | codecov

以上，當你 push 程式碼到 GitHub 上、並且通過 CircleCI 的單元測試之後，Codecov 就會產生覆蓋率報告了！

完整範例請參考我的 GitHub

GTD＆Creative Routines

Wed, 14 Oct 2015 00:00:00 GMT

這是一篇勉勵我自己如何實行 GTD & Creative Routines 的一套方法。

前言

你是否常常在夜晚帶着一絲傷感入睡呢？明明胸懷大志，卻總是因爲忙碌無爲而感到愧疚？時間總是在不知道該做什麼**之中悄悄流失……

節錄自「我的时间管理与方法论」

不知道該做什麼

為了解決這類焦慮，我們需要有一套 GTD 方法，讓自己在正確的時間（Time），有正確的事（Things）可以去做（Done）。

什麼是 Creative Routines？

「世界上最恐怖的事情就是－比你優秀的人，比你更加努力。」

優秀的人之所以能夠創造出令人矚目的成就，是因爲他們在日常作息、工作和學習之中，養成了規律良好的習慣。

「優秀是一種習慣」 — 亞里士多德

幸福並非取決於天性，我們的一言一行都是日積月累下，養成的習慣。如果說懶惰是一種習慣，那麼優秀也是一種習慣。

人生終極目標

我們每天生活所需要維繫的目標，不外乎五大主題：

健康
事業
社會責任
情感
愛好

若想長時間、規律地維持著良好的習慣，必須得有一個基準，用來判斷上述生活中會碰到的這些事情中，哪些對你而言才是最重要的、哪些才是你想做的、哪些是你該做的，而這個基準就是 GTD 的中心思想，也就是人生終極目標。比如：我的人生目標是對社會做出貢獻。那麼每當你完成一個經過篩選的目標時，也同時在實現人生的終極目標。

GTD

有了人生終極目標之後，接下來我們就可以開始探討如何實現 GTD（Getting Things Done）方法了。 GTD 的好處？

把複雜的事情簡單化
把簡單的事情可操作化
把可操作的事情度量化、數字化
把可度量、可數字化的事情可考評化
把可考評的事情流程化

節錄自「什麼是科學管理」 — 《命好不如習慣好》

GTD 的壞處？

會有人來留言對你說「你活得不累嗎？」

GTD 的核心流程，五大步驟：

收集（Collect）
處理（Process）
整理（Organize）
執行（Do）
回顧（Plan）

收集（Collect）

不要相信你的記憶能力，身為一個專業的程序猿，我們有義務清空自己的記憶體，讓它隨時保持在足夠應付那些真正必要的思考工作上。

當你的腦中有任何雜音（Stuff）出現，不管大小，先將它往你的水桶（Inbox）裡收集，越簡單越快速的工具越好。（比如：便利貼、筆記本、待辦清單）

哪些東西讓它進你的水桶？

突然閃過的想法
想要達成的目標
需要你去完成的待辦事項

哪些東西不適合收集？

會議、約會：直接使用行事曆（Calendar）會更好
稍後閱讀：Pocket、Instapaper 這類工具會是你的好朋友
想收藏的媒體（網站、文章、圖片）：使用相對應的服務（Delicious、Evernote、Pinterest）
想養成的習慣：使用 21天效應搭配習慣清單（微习惯、种子习惯）

盡量保持單一職責原則（SRP），若有更方便的工具可以處理這些事，那就交給專業的去完成吧，這樣除了能夠專注在該完成的任務上，也能夠隨時知道自己想找的資料存放在何處。

處理（Process）

遵循先進先出的順序，檢查那些積在水桶裡的待辦事項，使用下列方法，將它們轉化為可執行的任務（Task）：

二分鐘法則
四象限法則

二分鐘法則

首先判斷這件事你是否可以在二分鐘左右之內完成？如果可以的話，就趕緊先將它解決了吧！

四象限法則

如果是無法馬上完成、需要經過整理的任務，就先使用四象限法則來做歸類，依照重要度與緊急度來劃分出任務的優先度（Priority）：

P1：重要＆緊急
P2：重要＆不緊急
P3：不重要＆緊急
P4：不重要＆不緊急

哪些屬於 P1？

即將到達期限的工作或學業上的任務

會出現 P1 通常是因為：

外界因素：突然被安排
個人因素：P2 沒完成

因為 P1 會讓人產生壓力感，所以盡量越少越好。

哪些屬於 P2？

趁著在下雨之前，就先修補自己的家。 — 未雨綢繆《詩經》

工作或學業上的任務
個人想達成的目標
會對個人的發展、以及周圍環境有重大影響的事項

根據 80/20法則，我們應該盡量投資時間在 P2 的任務身上。

哪些屬於 P3？

感到忙碌且盲目的事
附和別人期望的事
臨時被安排的事
不必要的社交回覆（電話、LINE、Facebook）

P3 盡是些不重要的事，但往往因為它們緊急，所以是最容易佔據人們寶貴時間的主兇，應該盡量避免。

哪些屬於 P4？

P4 屬於可偶爾放鬆一下，但不可沈溺於此的事項。

如同這篇「绝地武士」之中提到，我們常常把時間浪費在那些不重要的雜魚身上，而忽略了自己真正想要的目標，拯救公主。

結論：走出 P3，專注 P2。

整理（Organize）

大事化小，小事化無。

經過前面的檢查之後，我們已經安排了優先度給任務，接下來就是根據目標大小拆分成專案（Project），將大事化小，小事化無。

目標金字塔
三隻青蛙理論

目標金字塔

每次馬拉松比賽之前，我都要乘車把比賽的線路仔細地看一遍，並把沿途比較醒目的標誌畫下來，比如：第一個標誌是銀行；第二個標誌是一棵大樹；第三個標誌是一棟紅房子，就這樣一直畫到賽程的終點。比賽開始後，我就以百米的速度奮力地向第一個目標衝去，等到達第一個目標之後，我又以同樣的速度向第二個目標衝去。四十多公里的賽程，就被我這麼分解成幾個小目標輕鬆地跑完了。 — 山田本一

我們可以推測任務可能所需的時間，將之歸類為長期目標、中期目標、短期目標、小目標：

長期目標：年度目標
中期目標：季目標、月目標
短期目標：周目標
小目標：每日目標

三隻青蛙理論

如果你必須吃掉一隻青蛙，不要長時間盯着它看。如果你必須吃掉三隻青蛙，記得要先吃掉最大、最醜的那隻。 — 博恩崔西《吃掉那隻青蛙》

為自己的每一天、甚至每周、每個月、每一年，準備最重要的三件事。

執行（Do）

經過前面的整理之後，我們已經有了最重要的三隻青蛙，再來就是 GTD 最關鍵的一步，Do It！不把青蛙消化掉的話，前面講的都會是空談，讓我們把它完成吧！

番茄工作法

番茄工作法的基本原則：

一次只做一件事情
一次番茄時鐘二十五分鐘
中途不可中斷，一旦中斷，必須重新計算該次番茄時鐘
每完成一次番茄時鐘，休息五分鐘
每完成四次番茄時鐘，休息二十五分鐘
花費超過三個小時的任務，表示還切得不夠細

番茄工作法的目的：

提高集中力，專注在黃金工作時間
量化被打斷的次數、原因，做出相對應的調整
量化該任務所花費的番茄時鐘，完善預估流程
增進成就感，激勵持久動機

回顧（Plan）

到這裡我們已經將那些雜亂的待辦事項，整理成為確切可執行的目標，解決了最初的問題：不知道該做什麼！

PDCA 循環

儘管如此，我們規劃的目標並不會一開始就如此順遂，GTD 最困難的部份就是拆分任務，這件事就跟程序猿預估時程一樣困難，需要長時間的經驗累積，不斷地調整、修正、優化、迭代，最後才能讓 GTD 融入於自己的心流（Flow）。

PDCA 循環的概念，讓專案保持在執行 → 回顧 → 處理 → 整理 → 執行的迭代循環之中。

回顧的場景（Context）：

每日目標：每天睡前準備好明天的三隻青蛙，讓自己隔天起床就知道今天該完成什麼
周目標：利用周一上班的收假症候群緩衝時間，回顧自己上周與本周的任務狀況
月目標：月底或月初，回顧任務並進行適當的調整
年目標：新年期間，回顧過去一年的成果，重新訂下新年目標

願望清單

準備一份願望清單（Wish List），並依照自己可以負擔的值段，將願望分配成年獎勵、月獎勵、周獎勵、日獎勵。比如：今天完成這項任務的話，晚上就去吃好料的。完成這項困難的月目標的話，就買支新的 iPhone 犒賞自己。今年的目標達到的話，明年就給自己一趟出國旅行作為獎勵！

結語

其實我覺得需要 To-Do List 處理的事項會越來越減少，因為各式各樣手機 App 搭配通知系統會更高效，然後隨著人工智慧的發展，電子秘書也會越來越聰明，加上物聯網和大數據也成熟之後，人類真的只需要躺著等事情主動來讓你做就好了。

參考文章

OpenCC 簡繁中文轉換 Alfred 2 workflow v1.0.0 released!

Wed, 05 Aug 2015 00:00:00 GMT

從以前就在找一個可以簡繁互換的 Alfred workflow，可惜一直沒找到滿意的，所以一直以來都是用 Yahoo 的輸入法來切換模式。結果前幾天突然看到 OpenCC 這個開源項目，而且還有 Python 的庫可以用！二話不說就自己來寫一個了，以下是節自我的 GitHub alfred-chinese-converter v1.0.0 的 README。

Introduction 介紹

使用開源項目 OpenCC（開放中文轉換）開發的 Alfred 2 workflow，支持簡繁體中文的詞彙級別轉換、異體字轉換以及地區習慣用詞轉換（中國大陸、臺灣、香港）。

Features 特點

節選自 OpenCC 的部份特點：

嚴格區分「一簡對多繁」和「一簡對多異」。
完全兼容異體字，可以實現動態替換。
嚴格審校一簡對多繁詞條，原則爲「能分則不合」。
支持中國大陸、臺灣、香港異體字和地區習慣用詞轉換，如「裏」「裡」、「鼠標」「滑鼠」。
詞庫和函數庫完全分離，可以自由修改、導入、擴展。

Installation 安裝

Mac OS X 環境底下，使用 Homebrew 安裝 OpenCC 這套開放中文轉換庫：

$ brew install opencc

Download 下載

alfred-chinese-converter.alfredworkflow v1.0.0

Usage 用法

使用關鍵字 cc 輸入需要作簡繁轉換的詞句：

Alfred 會列出 7 項轉換結果：

簡體到繁體
繁體到簡體
簡體到臺灣正體
臺灣正體到簡體
簡體到香港繁體（香港小學學習字詞表標準）
香港繁體（香港小學學習字詞表標準）到簡體
簡體到繁體（臺灣正體標準）並轉換爲臺灣常用詞彙

選擇其中一筆結果，自動複製至剪貼簿：

DevOps：持續整合＆持續交付（Docker、CircleCI、AWS）

Sat, 25 Apr 2015 00:00:00 GMT

這篇文章將一步一步介紹如何使用 Docker、GitHub Flow、CircleCI、AWS Elastic Beanstalk 與 Slack 來完成持續整合與持續交付的開發流程。

前言

什麼是持續整合＆持續交付？

持續整合＆持續交付（Continuous Integration & Continous Delivery），簡稱 CI & CD，具體介紹可以參考「山姆鍋對持續整合、持續部署、持續交付的定義」這篇文章。

簡單來說就是盡量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。

我使用了哪些工具？

Git — 版本管理
GitHub — 程式碼託管、審查
CircleCI — 自動化建置、測試、部署
Docker — 可攜式、輕量級的執行環境
AWS Elastic Beanstalk — 雲端平台
Slack — 團隊溝通、日誌、通知

看完這篇你可以學到什麼？

瞭解 GiHub 的工作流程（GitHub Flow），利用 Pull Request 以及分支來完成代碼審查（Code Review）與環境配置，例如：開發版（development）、測試版（testing/QA）、上線產品（staging/production）。
使用 Docker，統一開發者、測試人員、以及產品的執行環境。
使用 EB CLI 將應用程式部署到 AWS Elastic Beanstalk 平台上。
使用 CircleCI 將以上工作全部自動化。偵測 GitHub 分支上的程式碼，若有更新則觸發：建置 Docker 環境、單元測試、然後自動部署新版本到 AWS EB。
使用 Slack，讓團隊成員能夠即時接收 GitHub 與 CircleCI 每一項動作的通知。

內容大綱

Node.js
- 在本地端執行 Node.js
- 在本地端測試 Node.js
GitHub
CircleCI
- 在 CircleCI 測試 Node.js
Code Review with GitHub Flow
Docker
- 在 Docker 執行 Node.js
- 在 CircleCI 測試 Docker
AWS Elastic Beanstalk
- 在本地端部署 AWS
- 在 CircleCI 部署 AWS
Slack

Node.js

安裝：

node: 0.10

這篇文章以 Node.js 的應用程式作為範例，其他語言（Ruby on Rails、Python、PHP）也同樣適用此工作流程。

建立新專案

$ mkdir hello-ci-workflow $ cd hello-ci-workflow

在本地端執行 Node.js

初始化 Node.js 的環境，填寫一些資料之後會在目錄下產生一個 package.json 的檔案：

$ npm init

安裝 Node.js 的 web framework，以 Express 為例：

$ npm install express --save

*--save*: 寫入 *package.json* 的 dependencies。

完成之後， package.json 大概會長這個樣子：

{
  "name": "hello-ci-workflow",
  "main": "index.js",
  "dependencies": {
    "express": "^4.12.3"
  },
  "scripts": {
    "start": "node index.js"
  }
}

在 index.js 裡寫一段簡單的 Hello World! 的程式：

var express = require('express');
var app = express();

app.get('/', function (req, res) {
  res.send('Hello World!');
});

var server = app.listen(3000, function () {

  var host = server.address().address;
  var port = server.address().port;

  console.log('Example app listening at http://%s:%s', host, port);

});

執行 npm start 或 node index.js ：

$ npm start

打開瀏覽器 http://localhost:3000 看結果：

*--save-dev*: 寫入 *package.json* 的 devDependencies，正式上線環境不會被安裝。

在本地端測試 Node.js

安裝 Node.js 的單元測試，以 Mocha 為例：

$ npm install mocha --save-dev

*--save-dev*: 寫入 *package.json* 的 devDependencies，正式上線環境不會被安裝。

{
  "name": "hello-ci-workflow",
  "main": "index.js",
  "dependencies": {
    "express": "^4.12.3"
  },
  "devDependencies": {
    "mocha": "^2.2.4"
  },
  "scripts": {
    "start": "node index.js"
  }
}

根目錄 test 資料夾，並新增一個測試腳本 test.js ：

$ mkdir test
$ cd test
$ touch test.js

加入一筆錯誤的測試 assert.equal(1, [1,2,3].indexOf(0)) ：

var assert = require("assert")
describe('Array', function(){
  describe('#indexOf()', function(){
    it('should return -1 when the value is not present', function(){
      assert.equal(1, [1,2,3].indexOf(0));
    })
  })
})

執行 mocha 測試：

$ ./node_modules/.bin/mocha


  Array
    #indexOf()
      1) should return -1 when the value is not present


  0 passing (9ms)
  1 failing

結果顯示 1 failing，測試沒通過，因為 [1,2,3].indexOf(0) 回傳的值不等於 -1 。

將 test.js 的測試修正：

assert.equal(-1, [1,2,3].indexOf(0));

再次執行 mocha 測試：

$ ./node_modules/.bin/mocha


  Array
    #indexOf()
      ✓ should return -1 when the value is not present


  1 passing (6ms)

結果顯示 1 passing ，通過測試。

GitHub

安裝：

git: 2.3

帳號：

GitHub

初始化 git 環境：

$ git init .

輸入 git status 會顯示目前哪些檔案有過更動：

$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

  index.js
  node_modules/
  package.json
  test/

將 node_modules 加到 .gitignore 黑名單，因為這個資料夾是由 npm install 自動產生的，不需要放到 GitHub 上：

# Dependency directory
# https://www.npmjs.org/doc/misc/npm-faq.html#should-i-check-my-node_modules-folder-into-git
node_modules

將更動 commit：

$ git add . $ git commit -m "first commit"

打開 GitHub，新增一個 repository：

輸入 repository 的名稱，以 hello-ci-workflow 為例：

使用 git remote add 將新創建的 GitHub repository 加入到 remote：

帳號：

$ git remote add origin https://github.com/<USER_NAME>/hello-ci-workflow.git

*<USER_NAME>** 改成自己的帳號。*

使用 git push 將程式碼傳到 GitHub：

$ git push -u origin master

成功之後前往 https://github.com/<USER_NAME>/hello-ci-workflow 就可以看到剛才上傳的檔案：

CircleCI

加入 GitHub repository

點選左邊欄的 Add Projects 按鈕：

選擇自己的 GitHub 帳號：

搜尋要加入的 GitHub repository，然後點選 Build project 按鈕，以 hello-ci-workflow 為例：

完成之後 CircleCI 就會自動執行第一次的建構，不過因為還沒加入測試腳本，所以建構結果會顯示 no test：

在 CircleCI 測試 Node.js

在專案根目錄底下建立一個 circle.yml ，並加入 mocha test：

machine:
  node:
    version: 0.10

test:
  override:
    - ./node_modules/.bin/mocha

完成之後將檔案 push 上 GitHub：

$ git add circle.yml
$ git commit -m "add circle.yml"
$ git push

Push 成功之後，CircleCI 會自動觸發建構和測試：

測試通過，建置成功：

代碼審查（Code Review）with GitHub Flow

目前開發中比較常用的 workflow 有 Git flow 和 GitHub flow 兩種，可以參考以下幾篇文章。

Git flow：

GitHub flow：

這裡我們使用 GitHub flow，它的核心精神是：

所有在 master 分支上的程式都一定要是通過測試，可以部署的產品版本。
要開發功能、修復 Bug、做任何事情，都要從 master 開一條新的分支。
隨時 commit 和 push 你的程式碼到 GitHub 上，與大家討論。
功能完成時，使用 pull request 讓大家作 code review。
確認沒問題之後才可以 merge 回 master，並且部屬新版本到線上。

建立一條分支

為了確保 master 這條主線上的程式碼都是穩定的，所以建議開發者依照不同的功能、建立不同的分支，這裡以 test-github-flow 為例，使用 git branch 新增分支、然後 git checkout 切換分支：

$ git branch test-github-flow
$ git checkout test-github-flow

加入 commits

在 test.js 裡加入一行錯誤的測試 assert.equal(3, [1,2,3].indexOf(5)) ：

// ...
assert.equal(3, [1,2,3].indexOf(5));

$ git add test/test.js
$ git commit -m "add a error test case"

新增一個 Pull Request

Push 到 GitHub 的 test-github-flow 分支：

$ git push -u origin test-github-flow

打開 GitHub 之後，會出現 test-github-flow 分支的 push commits，點選旁邊的 Compare & pull request 按鈕：

點選之後會進入 Open a pull request 的填寫頁面，選擇想要 merge 的分支、輸入描述之後，點選 Create pull request 按鈕：

檢視＆討論你的程式碼

新增一個 pull request 之後，其他人就會在 GitHub 上出現通知：

點進去之後可以看見相關的 commits 與留言，但是下面有一個紅紅大大的叉叉；因為每次 GitHub 只要有新的 push，就會觸發 CircleCI 的自動建置和測試，並且顯示結果在 GitHub 上：

點選叉叉，前往 CircleCI 查看錯誤原因：

就會發現剛剛 push 到 test-github-flow 的測試沒通過：

回到 GitHub，因為測試沒通過，所以審查者不能讓這筆 pull request 被 merge 回 master。

找到剛剛 commit 的那段程式碼，留言告知請開發者修正錯誤之後，再重新 commit push 上來：

修正 test.js 的測試腳本：

// ...
assert.equal(-1, [1,2,3].indexOf(5));

再次 commit & push：

$ git add test/test.js
$ git commit -m "fix error test case"
$ git push

回到 GitHub 的 pull request 頁面，可以看到最新一筆的 commit 成功通過 CircleCI 的測試了：

Merge＆部署

審查之後，確定沒有問題，就可以點選 Merge pull request 的按鈕，將 test-github-flow 的程式碼 merge 回主線 master ：

Docker

安裝：

boot2docker: 1.5（Mac only）
docker: 1.5

什麼是 Docker？為什麼要用它？

因為 Docker 最近很火，所以網路上不缺關於介紹它的文章，原諒我這裡只稍微提一下：

以往開發人員面對開發環境不同的問題，常常出現「明明在我的電腦上可以跑」的囧境，所以為了解決這類問題，通常會使用虛擬機器（VM）搭配一些工具（ Vagrant、 Chef ）來協助統一開發人員、測試人員、上線產品的執行環境。

Docker 也是類似的解決方案，不同於 VM 的是，Docker 運行起來更輕巧、可攜度更高。配置好一份設定之後，就可以讓大家馬上進入開發狀況，減少不必要的環境問題，提升效率。

在 Docker 執行 Node.js

在專案根目錄底下建立一個 Dockerfile ：

# Dockerfile

# 從 [Docker Hub](https://hub.docker.com/) 安裝 Node.js image。
FROM node:0.10

# 設定 container 的預設目錄位置
WORKDIR /hello-ci-workflow

# 將專案根目錄的檔案加入至 container
# 安裝 npm package
ADD . /hello-ci-workflow
RUN npm install

# 開放 container 的 3000 port
EXPOSE 3000
CMD npm start

使用 docker build 建構您的 image：

$ docker build -t hello-ci-workflow .

*-t hello-ci-workflow** 是 image 名稱。*

使用 docker run 執行您的 image：

$ docker run -p 3000:3000 -d hello-ci-workflow

*-d** 在背景執行 node，可以使用 *docker logs* 看執行結果。*

打開瀏覽器 http://localhost:3000 看結果：

其實每一次都要 build 和 run 還蠻麻煩的，推薦可以試試 Docker Compose，用起來有點像 Vagrant 。

在 CircleCI 測試 Docker

修改 circle.yml ：

machine:
  # 環境改成 docker
  services:
    - docker

dependencies:
  override:
    # 建構方式使用 docker build
    - docker build -t hello-ci-workflow .

test:
  override:
    - ./node_modules/.bin/mocha
    # 使用 curl 測試 docker 是否有順利執行 node
    - docker run -d -p 3000:3000 hello-ci-workflow; sleep 10
    - curl --retry 10 --retry-delay 5 -v http://localhost:3000

*-p** 可以指定 EB 的應用平台，例如 php 之類；這裡使用 docker。*

Push 更新到 GitHub：

$ git add Dockerfile circle.yml
$ git commit -m "add Docker"
$ git push

查看 CircleCI 建構＆測試結果：

AWS Elastic Beanstalk

帳號：

Amazon Web Services

安裝：

AWS EB CLI: 3.x

最後要將程式上線啦！現在 PaaS 雲端平台的選擇非常多（ Heroku、 Google App Engine、 Azure、 OpenShift、 Linode ），這裡我選擇 Amazon 推出的 Elastic Beanstalk 當作範例，以下是它的特色：

支援的開發環境多（Java、.NET、PHP、Node.js、Python、Ruby、GO），重點是有支援 Docker！
只需要上傳程式碼，Elastic Beanstalk 即可幫你完成從容量配置、負載均衡（load balancing）、自動擴展（auto scaling）到應用程式的運行狀況監控的部署。

初始化 EB 環境：

$ eb init -p docker

該命令將提示您配置各種設置。按 Enter 鍵接受預設值。

如果你已經存有一組 AWS EB 權限的憑證，該命令會自動使用它。否則，它會提示您輸入 Access key ID 和 Secret access key ，必須前往 AWS IAM 建立一組。

初始化成功之後，可以使用 eb create 快速建立各種不同的環境，例如：development, staging, production。

這裡我們以 env-development 為例：

$ eb create env-development

等待 Elastic Beanstalk 完成環境的建立。當它完成之後，您的應用已經備有負載均衡（load-balancing）與自動擴展（autoscaling）的功能了。

使用 eb open 前往目前版本的執行結果：

$ eb open env-development

在本地端部署 AWS

稍微修改 index.js ：

// ...
app.get('/', function (req, res) {
  res.send('Hello env-development!');
});
// ...

執行 eb deploy 部署新版本到 AWS Elastic Beanstalk：

$ eb deploy env-development

部署完成之後，執行 eb open 打開網頁：

$ eb open env-development

env-development 上的應用程式更新完成。

在 CircleCI 部署 AWS

git checkout 將分支切換回主線 master：

$ git checkout master

eb create 新增一組新的環境，作為產品上線用，命名為 env-production ：

$ eb create env-production

$ eb open env-production

這樣就成功啟動第二組機器了，目前我們有 env-development 和 env-production 兩組環境。

前往 AWS IAM 新增一組帳號給 CircleCI 使用：

Dashboard > Users
Create New Users
Enter User Names: CircleCI > Create
Download Credentials
Dashboard > Users > CircleCI
Attach Pollcy
AWSElasticBeanstalkFullAccess > Attach Pollcy

前往 CircleCI，設定您的 AWS 權限：

Project Settings
Permissions > AWS Permissions
打開剛才下載的 credentials.csv，輸入 Access Key ID & Secret Access Key
Save AWS keys
在 .elasticbeanstalk 目錄底下，建立 config.global.yml：

global:
  application_name: hello-ci-workflow
  default_region: us-west-2 # EB 所在的 region，預設是 us-west-2

修改 circle.yml ：

machine:
  # 安裝 eb 需要 python
  python:
    version: 2.7
  services:
    - docker

dependencies:
  pre:
    # 安裝 eb
    - sudo pip install awsebcli
  override:
    - docker build -t hello-ci-workflow .

test:
  override:
    - npm test
    - docker run -d -p 3000:3000 hello-ci-workflow; sleep 10
    - curl --retry 10 --retry-delay 5 -v http://localhost:3000

# 新增一筆部署腳本
deployment:
  production:
    branch: master
    commands:
      - eb deploy env-production

這樣就能在 GitHub 的 master 支線有更新時，觸發 CircleCI 的自動建置、測試、然後部署。

接下來馬上來試試看流程，修改 index.js ：

// ...
app.get('/', function (req, res) {
  res.send('Hello env-production!');
});
// ...

Commit & Push：

$ git add .
$ git commit -m "test deploy production"
$ git push

前往 CircleCI 看結果：

部署成功， eb open 打開瀏覽器來看看結果：

$ eb open env-production

Slack

帳號：

Slack

到這邊其實已經差不多結束了，最後來講講 Slack 吧。

Slack 是一款給團隊使用的即時溝通工具，類似的產品還有 Gitter 與 HipChat 。

至於跟 Skype、Lync 這些軟體有什麼不一樣的地方呢？

它們整合了許多開發工具（GitHub、CircleCI）的服務，例如 GitHub 有新的 push、pull request、issue；CircleCI 的單元測試沒有通過之類的通知，會即時出現在你的團隊的 Slack 上面，既然我們已經將大部分的工作自動化，勢必需要讓相關人員知道這些工具發生了哪些事情，所以使用 Slack 是必要的。

登入 Slack 頁面
點選 Configure Integrations > CircleCI

選擇要接收 CircleCI 通知的 channel
點選 Add CircleCI Integration 按鈕
複製畫面上的 webhook URL

返回 CircleCI
點選 Project settings > Chat Notifications
貼上將複製的 Webhook URL > Save

類似的步驟，將 GitHub 的通知加入 Slack：

測試 Slack 通知，是否能夠順利運作，新增一條 test-slack 分支：

$ git branch test-slack
$ git checkout test-slack

修改 index.js ：

// ...
app.get('/', function (req, res) {
  res.send('Hello Slack!');
});
// ...

Commit & Push：

$ git add index.js
$ git commit -m "index.js: update to test slack"
$ git push -u origin test-slack

CircleCI 通過測試，開啟一個 Pull Request
將 test-slack merge 回 master，觸發 CircleCI 自動部署

That’s it! On your next build, you’ll start seeing CircleCI build notifications in your Slack chatroom.

結束！可以看見 Slack channel 會顯示每一個步驟的通知過程：

eb open 打開瀏覽器查看結果，成功自動部署新版本：

$ eb open env-production

結語

「書山有路勤為徑，學海無涯苦作舟。」 — 韓愈

DevOps 的開發流程與工具每天都在不斷推陳出新，請站在巨人的肩膀上、保持一顆「活到老、學到老」的心。

我將這個範例的程式碼放在 GitHub 上，有興趣的人可以參考看看。

文章若有需要改進的地方，還請不吝指教，感激不盡。

參考

如何優雅地在 Mac 上使用 dotfiles？

Thu, 29 Jan 2015 00:00:00 GMT

註：這篇文章的原始碼放在 GitHub ，會以上面的更新為主。

如果不清楚什麼是 dotfiles 的話，可以參閱善用 dotfiles 個人化自己的工作環境：

*dotfiles，顧名思義，就是檔案名稱以 . (dot) 為 prefix 的檔案通稱，若是您的作業系統是 Mac OS X 或是 Linux 這類 nix-based 的作業系統，一般來說在視窗環境中是看不到這些檔案的，因為對系統來說，他們是所謂的隱藏檔，這些檔案有一些共通點，那就是他們通常用來儲存一些個人化的設定或是自定的拓展功能，以符合使用者本身的使用需求與習慣，有了這些設定好的檔案之後，使用者可以讓整個系統用起來更為順手，並且大幅提昇他們自身的工作效率！因此對某些使用者來說，這些 dotfiles 設定檔對他們來說，反而可能是他們機器上最重要的檔案呢！

這份 dotfiles 是 fork 自 Holman’s dotfiles ，並根據個人的需求修改過，如果有興趣，閱讀完這份文件之後，歡迎 fork 一份回去配置成適合自己的 dotfiles。

更多的 dotfiles 請參考 GitHub does dotfiles 。

Erase and reinstall OS X

如果你打算從乾淨的 Mac 環境開始，請參閱 OS X：如何清除並安裝。

Install Xcode

更新 App Store。
安裝 Xcode。
開啟 Terminal，安裝 Xcode Command Line Tools：

xcode-select --install

Install dotfiles

下載或使用 git clone 一份到 $HOME 目錄底下的 .dotfiles 資料夾裡面：

git clone https://github.com/amowu/dotfiles.git ~/.dotfiles

進入 .dotfiles 資料夾：

cd ~/.dotfiles

安裝 dotfiles：

script/bootstrap

bootstrap.sh 這個程式會自動完成以下工作：

檢查並安裝 Homebrew。
檢查並安裝 Oh My Zsh。
檢查並連結 dotfiles(.zshrc, .vimrc, .gitconfig,.gitignore, …)。
更新並安裝 brew packages(binaries, fonts, apps)。
設置 Mac OS X 的 defaults settings。

完成之後，手動安裝一些 App Store 上才有的軟體(Dash, Moom, …)。

Restore backup

使用 Mackup 進行備份回復：

mackup restore

什麼是 Mackup？底下會介紹。

dotfiles

執行 ~/.dotfiles/script/bootstrap 的時候，腳本會將目錄底下所有的 *.symlink 檔案透過 ln 命令建立連結至$HOME 目錄底下：

Topical

每一個環境的配置是以資料夾的形式被獨立區分。例如，如果想要新增 “Java” 的配置到 dotfiles，你可以簡單的新增一個命名為 java 的資料夾，然後將檔案建至目錄底下。任何副檔名是 .zsh 的檔案將在 shell 執行時被自動載入至環境中。任何副檔名是 .symlink的檔案將在你執行 script/bootstrap 安裝時被連結至 $HOME 目錄底下。

Components

一些目錄中比較特別的檔案：

bin/: 任何在 bin/ 目錄底下的檔案可以在 shell 執行時直接使用。
topic/*.zsh: 任何 .zsh 結尾的檔案都會在 shell 執行時被載入至環境。
topic/path.zsh: 任何命名為 path.zsh 的檔案會在 shell 執行時優先被載入至 $PATH。
topic/*.symlink: 任何 *.symlink 結尾的檔案都會在 $HOME 目錄底下建立連結。這可以讓你在配置環境的時候也保持版本控制的優點。新增 symlink 的時候需要執行 script/bootstrap 安裝。

不同於 Holman’s dotfiles ，我修改了一些部分：

Shell 的部分改用 Oh My Zsh取代原作者自己配置的 zsh。
移除 topic/aliases.zsh、topic/completion.zsh 等檔案，改用 Oh My Zsh 的 [plugins]。(https://github.com/robbyrussell/oh-my-zsh/wiki/Plugins) 代替。
移除 zsh/prompt.zsh、zsh/window.zsh.zsh 等檔案，改用 Oh My Zsh 的 [themes]。(https://github.com/robbyrussell/oh-my-zsh/wiki/Themes) 代替。
dotfiles 只專注在 topic/*.symlink、topic/path.zsh 的配置。

OS X

bin/dot 是一支簡單的腳本，會在 script/bootstrap 配置完 dotfiles 之後執行，安裝自定的 OS X 程式並設定系統參數配置。執行 dot 之後，它會跑以下兩支腳本檔：

$HOME/.dotfiles/homebrew/install.sh - Homebrew packages
$HOME/.dotfiles/osx/set-defaults.sh - OS X defaults setting

Homebrew packages

執行 homebrew/install.sh 的時候，腳本會使用 Homebrew 和 Homebrew Cask 來安裝 binary、font 還有 app，可以根據個人需求修改這個檔案，增加或減少自己需要的 packages：

binaries=(
  git
  tree
  ...
)

字型都是以 font-XXX 的形式命名，可以用 brew cask search /font-XXX/ 搜尋是否存在。

fonts=(
  font-roboto
  ...
)

應用程式可以用 brew cask search XXX 或是 Cask Search 網站搜尋是否存在。

apps=(
  dropbox
  google-chrome
  ...
)

以下是目前安裝的 packages：

OS X defaults setting

執行 osx/set-defaults.sh 之後，程式會將 Mac OS X 的一些系統設置改變，可以根據個人需求修改這個檔案，或是參考 Mathias’s dotfiles 整理好的配置。以下是目前設定的配置：

加快視窗 resize 的速度(Cocoa applications)

defaults write NSGlobalDomain NSWindowResizeTime -float 0.001

預設展開儲存視窗

defaults write NSGlobalDomain NSNavPanelExpandedStateForSaveMode -bool true

defaults write NSGlobalDomain NSNavPanelExpandedStateForSaveMode2 -bool true

關閉”你確定要開啟這個應用程式?”詢問視窗

defaults write com.apple.LaunchServices LSQuarantine -bool false

開啟觸控板輕觸點擊功能

defaults write com.apple.driver.AppleBluetoothMultitouch.trackpad Clicking -bool true

defaults -currentHost write NSGlobalDomain com.apple.mouse.tapBehavior -int 1

defaults write NSGlobalDomain com.apple.mouse.tapBehavior -int 1

開啟觸控板兩指輕觸彈出右鍵選單功能

defaults write com.apple.driver.AppleBluetoothMultitouch.trackpad TrackpadRightClick -bool true

開啟觸控板三指拖曳功能

defaults -currentHost write NSGlobalDomain com.apple.trackpad.threeFingerDragGesture -bool true

defaults write com.apple.driver.AppleBluetoothMultitouch.trackpad TrackpadThreeFingerDrag -bool true

開啟觸控板四指向下滑出現 app expose 功能

defaults write com.apple.AppleMultitouchTrackpad TrackpadThreeFingerVertSwipeGesture -int 0

defaults write com.apple.driver.AppleBluetoothMultitouch.trackpad TrackpadThreeFingerVertSwipeGesture -int 0

defaults write com.apple.dock showAppExposeGestureEnabled -int 1

加快觸控板/滑鼠的速度

defaults write NSGlobalDomain com.apple.trackpad.scaling -int 3

defaults write NSGlobalDomain com.apple.mouse.scaling -int 3

開啟所有視窗組件支援鍵盤控制

defaults write NSGlobalDomain AppleKeyboardUIMode -int 3

關閉鍵盤按住的輸入限制

defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool false

加快鍵盤輸入

defaults write NSGlobalDomain KeyRepeat -int 0

預設 Finder 起始位置為桌面

defaults write com.apple.finder NewWindowTarget -string “PfDe”

defaults write com.apple.finder NewWindowTargetPath -string “file://${HOME}/Desktop/”

顯示副檔名

defaults write NSGlobalDomain AppleShowAllExtensions -bool true

顯示 Finder 狀態列

defaults write com.apple.finder ShowStatusBar -bool true

顯示 Finder 路徑列

defaults write com.apple.finder ShowPathbar -bool true

允許框選 Finde Quick Look 的文字

defaults write com.apple.finder QLEnableTextSelection -bool true

Finder 標題列顯示完整路徑

defaults write com.apple.finder _FXShowPosixPathInTitle -bool true

預設搜尋列的結果為當前目錄下

defaults write com.apple.finder FXDefaultSearchScope -string “SCcf”

關閉改變副檔名的警告提示

defaults write com.apple.finder FXEnableExtensionChangeWarning -bool false

開啟資料夾的 spring loading 功能

defaults write NSGlobalDomain com.apple.springing.enabled -bool true

開啟 Dock 的 spring loading 功能

defaults write com.apple.dock enable-spring-load-actions-on-all-items -bool true

移除 spring loading 的延遲

defaults write NSGlobalDomain com.apple.springing.delay -float 0

避免在 network volumes 底下建立 .DS_Store 檔案

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

使用 column view 作為 Finder 預設顯示選項

defaults write com.apple.finder FXPreferredViewStyle -string “clmv”

關閉清空垃圾桶的警告提示

defaults write com.apple.finder WarnOnEmptyTrash -bool false

使用黑色的選單列和 Dock

defaults write NSGlobalDomain AppleInterfaceStyle Dark

使用縮放的效果作為視窗放大縮小效果

defaults write com.apple.dock mineffect -string “scale”

應用程式縮小至自己的圖示

defaults write com.apple.dock minimize-to-application -bool true

顯示 Dock 應用程式開啟中的小亮燈提示

defaults write com.apple.dock show-process-indicators -bool true

關閉 Dock 開啟應用程式的彈跳動畫

defaults write com.apple.dock launchanim -bool false

加快 Mission Control 的動畫速度

defaults write com.apple.dock expose-animation-duration -float 0.1

關閉 Mission Control 的應用程式群組化顯示

defaults write com.apple.dock expose-group-by-app -bool false

關閉 Dashboard

defaults write com.apple.dashboard mcx-disabled -bool true

將 Dashboard 從多重桌面之中移除

defaults write com.apple.dock dashboard-in-overlay -bool true

自動隱藏 Dock

defaults write com.apple.dock autohide -bool true

移除隱藏 Dock 的延遲

defaults write com.apple.dock autohide-delay -float 0

移除 Dock 的顯示/隱藏動畫

defaults write com.apple.dock autohide-time-modifier -float 0

將隱藏的應用程式 Dock 圖示半透明顯示

defaults write com.apple.dock showhidden -bool true

以上，若修改過 homebrew/install.sh 或 osx/set-defaults.sh 之後，直接執行指令：

dot

就會再次更新 packages 還有 defaults setting。

Mackup

當初始環境都安裝好之後，剩下的就是恢復備份。除了 .zsrc、.vimrc 這類 dotfile 比較適合放在版本控制之外，其他像是 Sublime 的 plugin、iTerm2 的 setting、Oh My Zsh 的 plugin、等等很多還有一般應用程式的配置檔需要備份，甚至是 SSH 的 key，這些我認為都不適合丟進 dotfiles 放上 GitHub。所以這裡介紹 Mackup 這個簡單的工具作為解決方案，使用方式很簡單， brew install mackup 安裝完之後只要執行：

mackup backup

就可以將檔案備份到 Dropbox 或 Google Drive。當需要恢復的時候則是執行：

mackup restore

就會將雲端硬碟上的備份以 ln 連結的方式在新電腦上同步。

配置方式也很容易，建立一份 ~/.mackup.cfg，或是直接使用 .dofiles/mackup/mackup.cfg.symlink 來修改：

[storage]
engine = dropbox # 同步的雲端硬碟，有 dropbox 與 google_drive 可以選擇
directory = Mackup # 同步的資料夾，這裡會將所有備份同步至 ~/Dropbox/Mackup 底下

# 指定要同步的應用程式
[applications_to_sync]
iterm2
oh-my-zsh
sublime-text-3
ssh

[applications_to_ignore]
# 指定不想同步的應用程式

以下是目前備份的應用程式：

更多詳細的配置與支援的軟體請參閱 mackup 的文件。

參考文章

AngularJS + Google Spreadsheet

Mon, 10 Mar 2014 00:00:00 GMT

概要

這篇文章主要是說明如何寫 AngularJS 的 service，以類似 [$resource](http://code.angularjs.org/1.2.6/docs/api/ngResource.%24resource) REST 的方式來取得 Google 試算表的資料。

本文假設讀者已讀過 AngularJS Tutorial，了解 AngularJS 基本概念。

建立試算表

前往 https://drive.google.com 或是參考已經建立好的試算表。

先建立一份新的試算表： 建立 > 試算表 。

填寫資料表，以 AngularJS Tutorial 的 phones.json 為例。

將試算表權限公開： 檔案 > 共用 > 擁有存取權的使用者 > 變更 。

共用設定 > 公開在網路上 > 存取權 > 可檢視 > 儲存 。

權限公開後，發佈到網路： 檔案 > 發佈到網路 > 內容有所變更時自動更新發佈 > 開始發佈 。

發佈完成後，公開連結中會提供一組 key，可以前往 Google Data APIs 測試看看資料是否回傳正確。

接下來進入正式寫程式的階段，這裡我們會使用到 Tabletop.js 這個第三方的 library，提供 javascript 快速取得 json 格式的試算表資料。

這裡會以 AngularJS Tutorial 的 phonecatApp 為例子，說明如何實作 Tabletop.js 的 service。

Template

建立 index.html，並加入 angular.js， angular-route.js 和 tabletop.js。 index.html:

<!doctype html>
<html ng-app="phonecatApp">
...
    <div ng-view></div>
...
    <script src="angular.js"></script>
    <script src="angular-route.js"></script>
    <script src="tabletop.js"></script>

    <script src="js/app.js"></script>
    <script src="js/controllers.js"></script>
    <script src="js/services.js"></script>
...
app.js，controller.js 和 services.js 後面會說明，接下來先加入 phone-list.html。
partials/phone-list.html:
<div>
  <ul>
    <li ng-repeat="phone in phones">
      <img ng-src="{{phone.imageurl}}">
      <p>{{phone.name}}</p>
      <p>{{phone.snippet}}</p>
    </li>
  </ul>
</div>

phone-list.html 綁定了 name， snippet 和 imageurl 三個變數，對應試算表的欄位名稱。

App Module

接著使用 angular-route.js 提供的 ngRoute 來幫 app 設定路由，這裡先一律導向 /phones 。

js/app.js:

var phonecatApp = angular.module('phonecatApp', [
  'ngRoute',
  'phonecatServices',
  'phonecatControllers'
]);

phonecatApp.config(['$routeProvider',
  function($routeProvider) {
    $routeProvider.
      when('/phones', {
        templateUrl: 'partials/phone-list.html',
        controller: 'PhoneListCtrl'
      }).
      otherwise({
        redirectTo: '/phones'
      });
  }]);

接下來要開始寫 phonecatServices 和 phonecatControllers 。

Service

這裡將 tabletop.js 封裝成一個 Phone 的 service，並自訂一個 query 方法提供試算表查詢使用。

js/services.js:

var phonecatServices = angular.module('phonecatServices', []);

phonecatServices.factory('Phone', ['$rootScope',
  function($rootScope) {
    return {
      query: function(callback) {
        Tabletop.init({
          key: 'YOUR_KEY',
          simpleSheet: true,
          parseNumbers: true,
          callback: function(data, tabletop) {
            if(callback && typeof(callback) === "function") {
              $rootScope.$apply(function() {
                callback(data);
              });
            }
          }
        });
      }
    }
  }]);

key 的部分記得填寫試算表提供的 key。

Controller

最後剩下 phonecatControllers，使用 Phone.query 取得試算表的 json 格式資料。

js/controllers.js:

var phonecatControllers = angular.module('phonecatControllers', []);

phonecatControllers.controller('PhoneListCtrl', ['$scope', 'Phone',
  function($scope, Phone) {
    Phone.query(function(data) {
      $scope.phones = data;
    });
  }]);

完成，完整範例程式碼請參考 GitHub angular-spreadsheet-sample 。

注意事項

新版 Google 試算表不支援。
試算表欄位名稱只能小寫，例如：imgUrl，要改成 imgurl。

參考

書摘《遊戲化的時代》

Fri, 28 Feb 2014 00:00:00 GMT

在 2011 年，Gamification* (遊戲化) 繼 Web 2.0，Mashup，Cloud，Freemium 之後，成為網路上科技的熱門關鍵詞。 Gamification 將會是*Social media、Big data、Internet of Things* 的下一波網路趨勢。*

持續「步行」的工具就是遊戲化

知道步行對健康有益，但要付諸行動真的很難。… 遊戲化漸漸地扮演起重要的角色，為了持續每天的健康步行運動，只要帶著遊戲化工具，每天無聊的步行就會得到回饋。

1998 年發售的「口袋皮卡丘」結合計步器和電子寵物，是成功的遊戲化案例。

近幾年熱門的健康管理 App 之一， Nike+ 運用智慧型手機的 GPS 和感應器來達成有趣的慢跑應用。

Serious Game 與遊戲化的不同

「Serious Game* 是將社會上的各種問題帶到遊戲裏，而遊戲化是將遊戲帶到社會的各個角落。」*

小便斗加上一個簡單的靶心之後，就能增添許多樂趣。

會員制與遊戲化哪裏不同？

思考使用者的「動機」，動機的概念可分為外在動機與內在動機。外在動機指的是因報酬，賞罰等理由所被激發的動機，內在動機則相反，並非因為外來的報酬或賞罰，而是被活動內容所激發的內在動機。所謂的遊戲化，既是想要謀得報酬的外在動機，同時也是能驅動內在動機的結構。

Starbucks 利用簡單的集點遊戲規則讓消費者參與解決環保問題。詳見 Karma Cup。註：圖片來源 OnEarth

受到量化的我們

在印刷技術上，「油墨」扮演重要的角色。而在遊戲化，同樣也需要各種「測量的技術」。

如果沒有碼表記錄這些時間，世界選手大會或奧運的競技，根本無法成立。

註：圖片來源 Washington Post

「不譴責，不罰款，而是獎賞！」福斯汽車 2010 年舉辦了一個名為「車速照相樂透的活動」，並不是針對超速車輛的取締罰款，而是表揚遵守車速駕駛的偵測系統，試行期間平均車速下降了 22%。

能用數據計算的東西，要變成遊戲比較容易，相反地，判斷標準不一的對象就比較難以變成遊戲，例如評價一幅畫。

遊戲變成生活化之後，遊戲化就會擴大散播？

「知之者不如好之者，好之者不如樂之者**。」印刷技術是結合造紙術和冶金術，再由能看懂文字的知識族群拓展。同樣地，遊戲化也是因為有智慧手機，Lifelog* 與眾多的玩家才能夠有今日的發展。*

遊戲之所以會進展得那麼快，原因如下：

測量技術的進步
網路的發達讓「時間」有了戲劇性的變化
遊戲世代的成熟

測量技術的進步

透過許多感應器和 Lifelog 的功能，已可以從生活中的各個「空間」中得到要成立遊戲所需的數值，原本壓根無法變成遊戲的各種領域裏，因為有了上述的功能，使得原本不能實現的遊戲變得可能了。

網路的發達讓「時間」有了戲劇性的變化

比「遊戲」更重要的一件事，時間的獲得。在活版印刷的時代「紙」所發揮的功能，就相當於現代的智慧型手機所帶來的快速一樣。為什麼「時間」的取得會那麼重要呢？其實應該說「任何時候都能確認遊戲的結果」才是更重要的。玩家在遊戲裏做了什麼動作，透過社群網路，馬上就會有人回覆訊息。即使沒有任何人回應，電腦也會成為「對手」，穩定用戶的結構早已完備。

遊戲世代的成熟

以活版印刷時代為例，「必須有一定以上的人識字」才有辦法拓展活版印刷技術。同樣地，要促進遊戲化最後的條件就是「遊戲世代的成熟」。玩遊戲的「人」增加了，而那個世代的人在社會的權責地位愈高，追求「遊戲」的機會也就愈高。遊戲的世代隨著時間的經過總算超過半數了。

「空間」「時間」「人」

「空間」「時間」「人」，這麼複雜的條件正好在 2010 年代帶來極大的影響力。正因為要擴大遊戲化的條件全都齊全了，遊戲化就要開始展開。

遊戲改變商業

迪士尼認為要提升「顧客滿意度」，首先要提升「員工滿意度」。「遊戲化並不是讓人不認真，鬧著玩的東西，而是喚起人的本性，讓人認真工作的工具。」

思考遊戲化

「任何人都覺得有趣的遊戲架構並不存在」，我們想的不應該是「加進甚麼結構應該會很好玩吧？」，而是「想讓玩家是甚麼的話，這樣設計應該不錯」。

玩家的操作與設計者的期待不一致

事實上，讓玩家感受勝利的快樂，並不是拓展遊戲化業者的主要目的，他們希望從玩家身上賺取利潤，希望玩家透過遊戲學習某件事，或者是希望玩家對社會有實質的貢獻等。不同於電腦遊戲，遊戲化的主要目的並不是提供玩家娛樂。另一方面，大部分玩家的目的不是從自己口袋掏錢出去，更不是想對社會有什麼幫助，只是想開心地玩個遊戲而已。兩者的動機不一致，在建構遊戲化時，會是很大的問題和阻礙。

太慢的「遊戲」讓人容易產生厭倦

並不是只要注入遊戲元素就能夠增加固定用戶，遊戲還有另外一個現象，那就是「厭倦」。一般常見容易上癮的遊戲設計，基於道德倫理的觀念，也經常受到許多人的否定。因此，不需要設計易使人成癮的遊戲，只需要讓大部分使用者「慢慢地厭倦」就可以。因為這樣的結構設計可以讓用戶反覆利用網路服務。

遊戲化只是拉條輔助線而已

「世界上幾乎所有事，也許都含有遊戲的要素在其中」。並不是任何事只要遊戲化就一定能成功。例如，有人像是在玩遊戲一樣愛上做菜，卻有人不知道如何將做菜當作是遊戲一般享受。

結語

遊戲，應該早就存在於我們所能想像的歷史之前，只是遊戲，遊玩的概念經常以配角之姿出現，所以我們才沒有注意到遊戲。對社會而言，與其推廣各種多樣的遊戲，我們可以更進一步描繪未來的藍圖，讓人們可以將遊戲當作更幸福的科技使用。那就是「開放設計遊戲的權限」。

「過去十年，是社群的十年。未來十年，是遊戲十年。遊戲的力量將會影響每個人的行為，是非常強力且令人興奮的力量。各位！請一起開心的製作遊戲，使用遊戲吧！」

重點筆記《Hackers and Painters》

Tue, 01 Oct 2013 00:00:00 GMT

我們的時代是程式設計師主導的時代，而偉大的程式設計師就是 hacker。
Hacker 追求的三個特色，好玩，高智商，探索精神，而不是實用性和金錢。
Hacker 倫理之二，你可以用電腦創造美和藝術，使生活更美好。
惡意入侵電腦系統的人應該被稱為 cracker，hacker 是指那些最優秀的程式設計師。
應該把 hacker 和畫家當作同一種人看待，他們都是創作者。
行為怪異和憤世嫉俗的人比普通人更可能成為 hacker。
Hacker 的最高境界是創造規格。
賺錢的軟體往往不是好玩的軟體。
Hacker 如何才能做自己喜歡的事情？答案是像音樂家一樣，找一份養家糊口的“白天工作”。
面試程式設計師的時候，主要關注的就是業餘時間他們寫了什麼軟體。
應該定期的從頭開始，而不要長年累月在同一個項目上，試圖把最新想法加進去。
Hacker 可以通過觀看優秀的程式學習程式設計，不是看它們的執行結果。
一幅畫是逐步完成的，過早優化是一件危險的事情。
Hacker 就像畫家，工作起來是有心理周期的。有時候你有了一個令人興奮的新項目，願意為它一天工作16個小時。但過了一陣子又會覺得無聊，對所有事情都提不起興趣。
正確的合作方法是將項目分割成嚴格定義的模塊，每一個模塊由一個人明確負責。
從他人的角度思考問題正是成功的奧秘所在。
判斷一個人是否具備 “換位思考” 的能力有一個好方法，那就是看他怎樣像沒有技術背景的人解釋技術問題。
在達文西的年代，繪畫並不是一件很酷的事情，達文西用自己的工作推動繪畫成為一種偉大的表達方式。同樣，程式設計到底能夠有多酷，取決於我們能夠用這種新媒介做出怎樣的工作。
只有深入了解當前的技術，hacker 才能構想下一代技術，知識產權的擁有者也許會說不，我們不需要你的幫助，我們自己就能開發下一代技術。他們錯了，在電腦工業歷史上，新技術往往是由外部人員開發的，所占比例高於內部人員。
如果我們不可以研究當前的技術，不能思考如何改進它，那麼我們怎樣才能開發出新技術呢？
如果 hacker 有自己的節日，那就是 4 月 1 日愚人節，你可以放心地作弄其他人。
專制國家會腐敗，腐敗國家會貧窮，貧窮國家會弱小。
不要在半夜發佈程式碼，然後回家睡覺。
管理企業其實很簡單，只要記住兩點：做出用戶喜歡的產品，保證開支小於收入。你就會超過大多數創業公司，隨著事業發展，你自己就能琢磨出其他的訣竅。
幾個 hacker 搞懂如何租用辦公室，或者如何雇用銷售人員，要比那些公司搞懂如何正確寫出軟體容易得多。
想致富？最好的辦法就是自己創業，或者加入創業公司。你想安穩的工作四十年，還是全力拼四年？
隨著工業化時代的來臨，手工藝人越來越少。目前還存在的最大手工藝人群體就是程式設計師。
如果解決方法是醜陋的，那就肯定還有更好的解決方法，只是還沒有發現而已。
那些內核最小，最乾淨的程式語言才會存在于進化的主幹上，因為它們的生命力最頑強。
現在被認為運行速度慢的語言，將來會有更大的發展空間。
浪費程式設計師的時間而不是浪費機器的時間才是真正沒效率的。隨著電腦速度越來越快，這會變得越來越明顯。

Trello workflow

Tue, 01 Oct 2013 00:00:00 GMT

團隊開發的網頁遊戲《末日少女》已經上市快兩個月了，成績比當初想像中還好，相較於 Gu Morning，這次《末日少女》的開發學到很多寶貴的經驗，稍微鬆口氣之餘，也有許多需要檢討改善的地方，而《末日少女》Mobile 版其實也已經開發好一陣子了，最近這個專案只剩下我一個人交到我手上負責，趁這個機會導入一些新的開發方式，也 PO 上來分享心得。

這篇文章會講什麼？

HtpChat — 開發團隊的 Log 整合中心。
Trello — 團隊的專案管理小白板。
Git flow — 最佳程式開發流程。
Jenkins — CI(持續整合)建構工具。

HipChat

HipChat 是一款跨平台團隊溝通工具，為了節省開會浪費的時間，通常會使用 Lync 或 Skype 這類通訊軟體，而 HipChat 除了該有的聊天功能，歷史查詢，附件上傳，@mentions 通知之外，最棒的是它可以整合許多服務，例如 GitHub，Heroku，JIRA 等，將所有開發上分散的訊息統一管理，方便團隊隨時瞭解狀況，而接下來這篇文章會講到如何整合 Trello，GitHub 和 Jenkins。

Trello

不同於一般市面上複雜的專案管理軟體，Trello 是一個簡單易用的 Scrum board，之前 Development Tools這篇文章有稍微介紹，而我目前就是使用它來管理新專案，試用兩個月下來，感覺還不錯。

Trello 主要由 Board，List 和 Card 組成，如上圖所示，目前我將開發板分成五個 List：

Backlog — 所有企劃開出來的功能會集中在這個 Backlog List，並按照預計完成日期排序。
To Do — Backlog 中的功能如果已經準備好企劃文件和美術檔案，那卡片就會移到 To Do 待命。
Doing — 正在實作中的功能會從 To Do 移至 Doing，建議每個人只留一張卡片在這。
Done (vX.X.X) — 下一版要完成的功能，在 Doing 完成的卡片會移到 Done，待產品發佈後會從 Done 改為 Live。
Live (vX.X.X) — 已經上線的功能 List，可以隨時使用封存，讓開發板保持乾淨。

vX.X.X 為版號。每張 Card 還可以根據屬性標上自訂 Label，例如 feature，bug 等。

Zapier

由於 HipChat 沒有直接整合 Trello，所以需要透過第三方服務來支援，Zapier。

Zapier 使用上跟 IFTTT 一樣，當某個服務被觸發時，另一個服務就執行某個動作，而這邊我們要使用的就是 Trello 和 HipChat，當 Trello 的 New Activity 被 trigger 的時候，HipChat 就 Create Message。

連結 Trello 和 HipChat 帳號：

選擇 Trello Board：

設定 HipChat 的通知格式：

也可以直接套用其他人分享的設定。

Git flow

Git flow 是一套 Git 流程管理工具，它會幫你在現有的 Git 開發環境上，建立五條 branch：

master — 最穩定的產品版本。
develop — 正在開發的版本，所有開發人員基本上都會在這條主線上。
feature — 開發新功能都需要使用這條支線，會從 develop 分支出來，完成後自動 merge 回 develop。
release — 準備發佈的新版本，從 develop 分支出來，完成後自動建立 tag 並 merge 回 master 和 develop。
hotfix — release 之後發現有緊急 bug 必須修復時會使用，從 master 分支出來，完成後 merge 回 master 和 develop。

這篇 git-flow cheatsheet 用圖解的方式解釋 git flow，會比較容易懂。

安裝

OSX：$ brew install git-flow
Linux：$ apt-get install git-flow

使用

初始化：$ git flow init

初始過程中會問你一些分支命名，建議直接使用預設。

New Feature

開始開發新功能：$ git flow feature start <FEATURE_NAME> 結束新功能開發：$ git flow feature finish <FEATURE_NAME> 將程式 push 到 remote 端：$ git flow feature publish <FEATURE_NAME> Pull remote 端的程式：$ git flow feature pull <FEATURE_NAME>

New Release

準備 release：$ git flow release start <VERSION> 完成 release：$ git flow release finish <VERSION>

VERSION 為版號。

New Hotfix

修復緊急 bug：$ git flow hotfix start <VERSION> 修復結束：$ git flow hotfix finish <VERSION>

如果想從 SVN 跳槽到 Git 的話，可以使用這個指令將整個 Repository 搬過來： $ git svn clone <SVN_REPOSITORY>

如果不習慣用命令列操作的話，推薦使用 SourceTree 這套軟體，裡面已經直接內建 git flow。

接著要整合 GitHub 和 HipChat，只需要幾個步驟就可以完成：

前往 HipChat > Group admin > API > 建立一組新的 token。
前往 GitHub > 你的 Repository > Settings > Service Hooks > HipChat > 將 auth token 跟 room ID 填上，Active 記得打勾，這樣就完成了，之後 GitHub 有任何動態都會在 HipChat 上通知。

Jenkins

最後要介紹的是持續整合工具 Jenkins，為了減少每次發佈版本浪費的時間，Jenkins 可以自動化這些鎖碎的步驟，而我目前專案的每日建置會處理的事項如下：

定時輪詢 Git 是否有最新的版本。
若是有最新版本則拉下來更新。
編譯程式檢查是否有錯誤。
封裝檔案 (.ipa & .apk)。
通知 HipChat。
將檔案 Email 給指定成員。

安裝

前往官方網站下載對應版本。

設定

安裝完畢之後，預設直接使用瀏覽器開啟 http://localhost:8080，接下來需要安裝一些 Plugins：前往 Manage Jenkins > Manage Plugins > Available > 右上角 Filter 搜尋可安裝的外掛。

Git Plugin — 如果你是使用 Git 的話當然就必裝囉。
HipChat Plugin — 整合 HipChat，安裝完之後 > Manage Jenkins > Configure System > Global HipChat Notifier Settings > 新增一組 HipCht API token，然後填上 Room 跟 Jenkins URL 就完成了。
Email-ext plugin — 建置成功可以發送自訂格式的 Email。

安裝完外掛之後接下來點選 New Job 開啟一個新建置：填寫 Job name，這裡我們選 Free-Style project。

創建好一個 Job 後會進入 Configure 頁面。

首先先設定 HipChat 的一些參數 (如果有安裝 plugin 的話)。

設定 Git，填上本機 Repository 位置，選擇 master branch (產品主線)，Remote 端 Repository 如果是用 GitHub 的話選擇 githubweb 然後填上 URL。

接下來設定排程，選擇 Poll SCM (輪詢)，並依照指定的日期時間格式設定，以 H/5 6,7,8,9,20,21,22,23 * * * 為例，無論何月何日星期幾，每天 6-9 點，20-23點，每隔 5 分鐘輪詢一次。

然後就是建置的部分，內容會依專案而異，以我的 AIR Mobile 專案為例，使用 Shell 指令，mxmlc 先編譯除錯程式，然後 adt 分別產出 .ipa 和 .apk 檔案。

最後設定建置成功後需要作哪些事：

Archive the artifacts — 封存指定檔案，注意檔案的路徑會是在 $WORKSPACE 底下。
HipChat Notification — 發送通知給 HipChat。
E-mail Notification — 發送信件給指定成員，如果需要自訂格式也可以使用前面介紹的 plugin。

結語

上面講完了 HipChat，Trello，Git flow 和 Jenkins 四樣看似無關的服務，但結合起來運用會讓專案開發上的效率更佳提升，雖然前期的準備需要花點時間，但對專案是很值得的投資，Try it! :-)

參考資料

COSCUP 2013

Tue, 06 Aug 2013 00:00:00 GMT

今年是第二次參加開源人年度聚會 COSCUP，很幸運的在 47 秒內搶到限量 500 張的門票，和去年比較不一樣的地方：

場地從中研院換到國際會議中心，應該是因為人數的關係，不過我猜 TICC 沒有下次了(笑)，期待明年的小巨蛋(誤)。
八軌議程，同個時段最多有八場演講可以選擇！

分享一些這兩天簡單的筆記。

DAY 1

第一天有點小遲到，好險大會準備的 NFC 識別證快速通關，加上場地夠大，還很多位置可以坐。

Open Data Initiatives for Taiwan

一開始開場是由行政院政務委員張善政演講，主要是聊一些台灣政府目前 Open Data 的情況，認識了兩個網站：

前者是政府的資料開放平台，後者是最近很紅的「寫程式改造社會」零時政府。

座談會：Open Data 面面觀

莊庭瑞：政府 open data 才有機會知道資料是錯的，如果不公開，永遠沒有人會發現資料有錯。

Open Source Engine powering Big Data in the Cloud

完全聽不懂（失落），不過外國人念 Hadoop 聽起來好像在念ぱるる。

開源硬體有什麼意義?

Facebook 的 OCP (Open Compute Project) 讓很多人開始對 Open Source Hardware 抱有憧憬，認為可以像 Open Source Software 一樣，激盪出很多新的設計和發明。事實上是這樣的嗎？

Open Software VS Open Hardware

擴充成本，硬體比軟體還高很多。
軟體語言本質一樣，易學，硬體相反。
軟體易模組化

OCP (Open Compute Project)

只公開規格，沒開源。
規格只適合大用戶。

最後講者 Ben 介紹自家開發的服務 Evdience Taiwan，主要是透過電話來錄音，適合報料蒐證。

g0v.tw 零時政府：從開放源碼到開放政府

講者為零時政府創辦人 clkao，以 Open Source 比喻政府的觀點還蠻有趣的：

民主 = 接受 patch
立委 = committer
政府 = code in action
公民社會 = open source

在成果展示中，我最喜歡失蹤兒少開放資料平台計畫這個點子，404 頁面與慈善公益結合。

當設計遇上 opensource，人人都可以是設計師

講者為 Kamm，主題跟設計相關，認識了一些網站跟專有名詞：

WikiHouse — 建築設計的 open source，這超讚，離自己組小木屋的距離又更近了。
SketchUp — Google 3d modding tool。
Rhinoceros — 3D modeling software。
Grasshopper — 搭配 Rhino 參數化建模的工具。
RepRap — 開源的 3D 列印原型機。
Thingiverse — 3D 設計的社群。
CNC — 電腦數值控制工具機，這裡應該指大型的 3D 成型機吧。
Pure Data — 不太確定，好像是 3D model 的一種格式。

Yet another introduction to Git — from the bottom up

ihower 大大的演講，主要是講一些 Git 底層的運作原理，可是我聽不太懂囧。

如果你能不用 git add 和 git commit 來 commit code，就可以不用聽這場演講了。

App on Server: NAS 上的 App 開發與商業模式

後悔來聽這場，基本上就是在廣告 QNAP NAS 這台機器，應該去聽騰訊的 HTML5 圖像引擎或萌典才對。

An intro of web scaffolding tool using yeoman generator

這場是介紹用 Yeoman 打造一個屬於自己網站的 scaffold。

一小時 RWD 就上手

這場的講者是最近很紅的裝置藝術師 Even 大大，主要世界介紹一套不錯的 RWD column grid tool「SUSY」。

Build your own Trello within 200 Lines of Code

這場主要是用「Meteor」快速開發出 Trello 的原型，Meteor 最大的特色應該就是 client 跟 server 都在同一份 code 裡面。另外認識了一個很棒的共筆網站「iCoding」。

AngularJS 開發實戰

這場講者是保哥，主要是介紹 AngularJS 的核心架構，非常有幫助。

DAY 2

前一天結束一回到家就睡死了，所以第二天比較早起，早上是一連串跟遊戲開發相關的議程，非常期待。

行動遊戲 App 開發與 Open Source：Kamigami 的雙平台經驗

主要是介紹講者笨笨的小B 團隊自行開發的遊戲引擎 Kamigami 的經驗分享：

LibGDX — 類似 XNA 的 Android game framework。
CocoaPods — iOS 套件管理。
Maven — Android 套件管理。
NuGet — .Net 套件管理。
注意授權 License，建議只挑這幾個，BSD/MIT/Apache2/MS-PL。

Asynchronous programming with Combinator

講者是來自神來也的女性 Server 程式設計師！ (受小弟一拜)。

Memory leak 沒經驗的程式設計師容易漏掉，有經驗的程式設計師沒睡飽的話，也會漏掉。

Modern Game Engine with Opens Source

講者 Owen 大大是 Space Qube 的開發者！

主要是介紹自行研發的 LynxEngine 遊戲引擎用到哪些技術：

Lua/LuaPlus/Mono (ScriptSystem)
Box2D/Bullet/PhysX
FreeImage
Zlib
wxWidgets
bmFont
FreeType

Using Lua to Build a Component-based Architecture for Game Apps

上午場的壓軸，是半路大大的演講！一大早出門忘記帶書來給他簽名了>”<。

主要是介紹用組件式開發來解決物件繼承會發生的「鑽石問題」。

寫太多 magic code 的話，哪一天睡不好，就是維護你程式的人在詛咒你。

Open Code: Why Linux’s openness enabled it to succeed where all others failed.

也是一場全英文的演講，請到 Linux kernal 開發者 Greg KH ，基本上完全聽不懂 (泣)。

與現實世界相反，程式設計的世界中，low-level 的 programmer，level 一點都不 low，low-level 不是沒人要做的事，而是能做這些事的人不多。

DesignSpark 免費設計資源與 Raspberry Pi 新應用

講者是來自 RS Components 的香港小姐，中文講得好像有點吃力 XD，介紹了一個很棒的網站「DesignSpark」。

前端工程師如何與團隊合作：以開發 Drupal 專案為例

雖然對 Drupal 沒有興趣，但想聽聽 F2E 的團隊合作心得：

常給 PM 建議，但決定權不在你。
協助 Prototype。
不斷溝通，持續調整
那些Mockup 沒告訴你的事。
F2E是良心事業。

Raspberry PI and the future

最後一場，雖然對 RaspberryPI 有很興趣，但這場是英文。

Lightning Talk

因為今年的閃電秀過程太精彩了，忘記筆記，所以只挑幾個我想的起來分享：

Registrano

由 hlb 大大創辦，負責本次 COSCUP 線上訂票的服務，創下 47 秒 500 張門票秒殺的紀錄。

「怎麼晚一分鐘就沒票了，報名網站在搞什麼」。

Logdown

最近很火的 markdown blog 服務。

Mr.Bus

Python 正妹。（喂￣▽￣)==O)￣#)3￣)☆

心得

今年議程非常豐富，大致上聽了：

Game 4 場
Open Data 3 場
Web front-end 3 場
Artist & Maker 3 場
Cloud & Backend technology 2 場
Tools & Utilities 2 場
OS & Embedded System 1 場

本次心得：

最近政府議題夯，大玩黑畫面梗。
今年看到好多人跌倒 = =”。
開源精神遍及 Open Data，Open Hardware，Open Design！
遇上好多網路上 foloow 的大大 :D
可以聽到其他業界朋友談論自己公司的八卦（咦？

參考

我想做的遊戲

Fri, 02 Aug 2013 00:00:00 GMT

前言

進入遊戲業兩年多了，但網誌上跟遊戲相關的文章卻很少，所以在截稿前夕，就來寫一篇跟遊戲有關的文章吧！

雖然這兩年間學到不少遊戲開發的相關知識，但這篇不寫技術，這篇純粹想聊聊「自己想做的遊戲」。

每位遊戲開發者一定都會有自己想做的遊戲，但絕對不會是目前你工作上的這款(笑)，雖然嚮往成為獨立遊戲開發者，但看過半路叛逃的分享後瞭解，獨立開發遊戲並不容易，儘管如此，還是想分享自己心中的那一款完美遊戲。

簡單來講，有三個要素：

遊戲
生活服務
教育

遊戲？生活服務？教育？在仔細解釋前，先介紹幾款遊戲給大家認識：

OZ
Greed Island
動物之森
神奇寶貝

OZ

OZ 是在日本動畫夏日大作戰（2009）中的一個虛擬世界社交網站。

「OZ」與第二人生概念相似，但依照自己的經驗來講「OZ」應該更接近日本社交網站mixi的想法。

由於「OZ」系統與現實世界之間有著極高的整合度，來自世界各地的許多企業與政府組織都於此設有部門來進行互動，這使得在作為虛擬世界的「OZ」混亂也陸陸續續影響到真實世界的生活。

雖然是虛構的故事，但 OZ 中有幾個特色還蠻有趣的：

OZ 世界中擁有 10 億人口（比 Facebook 多 1 億），幾乎是每個人都有一組帳號
Client 端有 PC，手機，TV 等，與近年來跨平台特性一致
行政進駐，遊戲世界可以與現實服務做連結，例如：納稅，防災
企業進駐，直接在遊戲中的商城購物，也是一個與現實服務連結的商務平台
即時翻譯多國語言，這個感覺快實現了

其中行政與企業這塊，就是我上面提到的遊戲結合生活服務，近年網路服務也逐漸往資料開放（API）的方向發展，要在遊戲世界中實現這些服務已經不是夢想。

Greed Island

貪婪之島是日本漫畫《Hunter × Hunter》中的一個虛擬遊戲。

這是一個把現實世界當作遊戲的一個概念，遊戲中的角色，道具，事件都是用漫畫中的「念」製作出來的，當然，我們不可能用念能力來製作遊戲（笑），不過其實也可以把它看作擴增實境(AR) 的延伸應用，貪婪之島最令我著迷的概念就是，「只要照著遊戲循序漸進，玩家本身就會得到成長」，與我的座右銘「最有趣好玩的RPG，就是自己的人生」相呼應，是理想中的「充滿遊戲的現實世界」。

動物之森

這款就比較正常一點了，是由日本任天堂製作，我把它定義為治癒型輕鬆生活遊戲。

這是個沒有固定劇情的開放遊戲，玩家可以在裡面獨自生活，不受預設的劇情、任務限制，許多人（小孩子或成人）享受這樣與有趣動物角色”對話”的遊玩樂趣。透過使用電玩主機的內部時鐘，這個遊戲可與真實時間相對映，因此有著實際的事件發生。

這款遊戲最早從超任時代就有了，一直到現在的 Wii，3DS，都還是熱門保證的暢銷遊戲，我自己是從 NDS 版開始接觸，可以把它想像成自由度很高的「牧場物語」，基本上遊戲沒有你需要完成的任務，不用打怪升級，只需要跟村民聊聊天，佈置房間，種花草，抓蟲鳥，然後收藏在博物館，很悠閒的一款遊戲，跟大部分遊戲比較不同的，也是我很喜歡的一個系統，就是與現實時間同步，清晨到夜晚，春夏秋冬，都跟現實世界同步，特定日期還會有事件，例如聖誕節，所以每天都會滿懷期待的開啟遊戲，進入這個可愛的動物世界，雖然有下雨下雪這類天氣效果，但這個就不會跟現實世界同步了（雖然技術是做得到），總之，這是一款沒有壓力的遊戲，我很想做出這樣的遊戲！

神奇寶貝

上面才說到我想做輕鬆沒壓力的遊戲，結果這邊就要介紹這款要花大量時間培養寵物，練功破關的遊戲（笑）。

和一般人不同，這應該是我第一款接觸的 RPG 遊戲（國小六年級），讓我深深著迷，廣大的世界冒險，豐富的神奇寶貝，平衡的遊戲架構，與現實玩家的交流互動，都是這款遊戲迷人的特色。

不過，我提出這款遊戲想聊的不是上述這些，我想分享的是，這系列遊戲背後設計的世界觀。神奇寶貝的遊戲世界，其實都是參照現實某個地區的地圖來做參考的。

以上圖為例，右邊是日本九州的地圖，左邊是神奇寶貝紅寶石的地圖，基本上就是把九州往左轉90°。當然不純粹是只有地圖參考這樣而已，對應的地點也會根據現實該地方特色，埋一些伏筆在遊戲劇情裡面，以巴哈姆特玩家分享的這篇文章來舉例，遊戲中有三隻神獸，長的很像原子彈，而且三隻神獸都能學習到「爆炸」這個絕技，然後呢？有趣的是，把這三隻神獸在遊戲中出現的地點與九州地圖做對照，可以發現分別出現在「長崎」，「宮崎」和「大分」，這三個地方是第二次世界大戰中，發生過大規模空襲的地點！這種藉由從玩遊戲來學習知識的概念我非常喜歡（好想以台灣為背景做一款遊戲啊）。

所以，我想要做怎樣的遊戲呢？

上面講的漏漏長，所以我到底想做怎樣的遊戲呢？老實講，我還沒有一個具體的架構和想法，但上面提到的遊戲中，都有我很欣賞，很想實現的概念在裡面：

OZ：深度整合行政＋企業的服務在遊戲中
貪婪之島：玩遊戲的過程中，玩家本身也會得到成長
動物之森：與現實時間同步，沒有壓力的治愈系遊戲
神奇寶貝：藉由遊戲設計，讓玩家學習知識

再回到開頭提到的，我想做的遊戲三大元素「生活服務」，「遊戲」和「教育」：

生活服務

與其說我想做遊戲，不如說我比較想做服務，一款提供現實世界服務的遊戲，可以在遊戲世界中看YouTube（電視），在遊戲中收發mail（信箱），在遊戲中閱讀RSS（報紙），在遊戲中購買 amazon（購物）等，近年來越來越多的網路服務都走向多螢一雲，跨平台的方向，也都有提供 API 讓開發者應用，節省許多自行研發的成本，加入這些元素有助於玩遊戲同時，也能得到現實的回饋。

遊戲

Gamification 這個詞最近很紅：

Gamification（遊戲化），網站開發者認為遊戲化是現代的一個趨勢，遊戲化就是把遊戲的元素注入生活，是要讓生活更有趣，以及讓大家打破對遊戲的刻板想法，就像是以前玩遊戲比較偏向逃避現實，但是現在遊戲把虛擬的世界帶到現實，像是最近的電影阿凡達，LBS程式Foursquare，都是把我們跟以往認為是虛擬的東西跟現實連接。

乍看之下好像跟上面的生活服務是一樣的，差異是一個是「遊戲中結合服務應用」，一個是「服務中加入遊戲元素」。

而我真正想要表達的，是結合這兩者，一款可以讓你得到現實成就與回饋的遊戲，在遊戲中完成的每個事件，得到的每件獎勵，都是跟現實有連結的，不會只是一般打寶打怪升級這種一時的空虛快感。

教育

最後是教育，遊戲的開發在技術上來講絕對不會比其他領域來的輕鬆簡單，但是遊戲卻往往給人不務正業的觀念，尤其台灣大部份的遊戲就更別提了(看看那些電視上播的廣告)，想抬起胸膛跟親朋好友說我的工作是在製作遊戲都有點困難，加上近年來手機平板普及，開發遊戲門檻降低，雖然對我們來講是好事，但同時也降低遊戲品質，沒有內容的遊戲充斥市面，重點是還賺大錢，這樣還有誰會想專注在遊戲內涵的思考？所以我常常在想，如果我自己要做一款遊戲，我會想從給小朋友玩的遊戲開始做，想想童年那些美好的回憶，那是段最單純看待遊戲的時期，不論是在遊戲中也好，現實中也是，教育一直都是很重要的課題之一，如果一款遊戲能讓我們的孩子學習到有用的知識，不但小朋友們玩的快樂又有成就，父母親也肯掏錢投資在孩子的教育競爭上。

結語

以上，聊了一大串外加一些小抱怨，雖然看似過於理想，但相似概念的遊戲一直都陸陸續續出現，現階段的我當然不可能把這個目標實現，只有持續關注遊戲的發展，不斷充實自己，收集所需的相關資料，當機會來臨的那一刻，才有能力好好把握住，感謝看完這篇文章的您，在此共勉之，加油！

參考文章

Gamification：遊戲化的未來

Web Components

Wed, 26 Jun 2013 00:00:00 GMT

今天想要跟大家聊聊 Web Components 這個新玩具，說是新玩具，其實這個概念已經發展有段時間了，尤其筆者本身是玩 Flash 技術出身的，發現 Web Components 跟 Flex Component 差不多，所以就來分享一些心得。

Web Components 是什麼？

簡單來講就是你可以客制化 HTML <tag>：

<my-component></my-component>

由 W3C 提出：

The component model for the Web. When used in combination, Web Components enable Web application authors to define widgets with a level of visual richness and interactivity not possible with CSS alone, and ease of composition and reuse not possible with script libraries today.

使用 Web Components 有什麼好處？

鉴于许多 Web 框架通过暴露 JavaScript API 来构建用户界面，而构建用户界面实际上就是生成一堆 div 和 spans 标记，Web 组件是原生浏览器的解决方案因此不依赖于一个完整的框架。因此，与现在的一般依赖某个 Javscript 框架的 HTML 组件相比，Web组件希望能减少碎片。

最近新起許多 MDV（Model-driven-view）這類 template 和 data binding 開發方式的框架（backbone、angular、ember），那 Web Components 跟這些框架有什麼不同呢？

基本上就是希望藉由規格標準化，讓 Web application 的開發方式與架構更清晰。

Web Components 的瀏覽器支援情況？

尽管 Web 组件是一项有趣的新技术，但在浏览器们都支持它们（并且大部分用户都开始使用这些浏览器们）之前，其中的大部分功能还派不上用场。解决这个问题的一种方法是使用 polyfills。

很遺憾，目前的瀏覽器普遍都還不支援完整的 Web Components，不過可以使用 Google I/O 2013 中釋出的 Polymer library，讓瀏覽器模擬 Web Components 環境嘗嘗鮮。

使用 Polymer 開發 Web Components

Basics

Component

1. Simulate

載入 platform.js 讓瀏覽器支援 Web Components 的功能。

2. HTML Imports

使用 <link> 和 import 載入 Web Components：

<link rel="import" href="import-file.html">

3. Custom Elements

使用自己建立的元件 <my-component></my-component>，命名方式以 dash(-) 分開為原則：

<element name="my-component">

可以加入 constructor 讓 javascript 使用，例如：

<element name="my-component" constructor="MyComponent">
...
<script>
    var myComponent = new MyComponent();
</script>

也可以繼承其他元件：

<element name="my-button" extends="button">

4. Initialize Polymer

在 <script> 內加入 Polymer.register()，讓這個元件初始化。

5. Templates

定義元件的 HTML Markup，UI layout。

6. Decorators

使用 <style> 定義元件的 CSS 樣式，另外也可以載入外部樣式：

<element name="my-component">
  <link rel="stylesheet" href="my-component.css">
  <template>
  …

7. Model Driven Views

使用 {{}} 將 data binding 到 template，然後在初始化的時候定義變數，例如替這個元件建立一個公用的 title 屬性：

<element name="my-component" constructor="MyComponent">
  <template>
    <h1>{{title}}</h1>
  </template>
  <script>
    Polymer.register(this, {
      title: "Web Components"
    });
  </script>
</element>

定義完後，就可以使用：

<my-component title="Hello World!"></my-component>

<script>
  var myComponent = new MyComponent();
  myComponent.title = "Hello World!";
</script>

結語

Web Component 将会横扫 Backbone、Ember、Angular、Knockout 等等这些框架。但是，接下来这几年，我们还是要用它们，因为很多 Web Component 的 API 只能在 Chrome 的 Canary 开发版本和Firefox的开发版本中使用。

雖然引言中講的很聳動，但目前玩下來還是碰到不少問題。例如我想使用一些第三方的 jQuery Plugin 會無法動作等…，不過因為開發架構很接近 Flash，小弟認為應該會是未來 HTML5 RIA 的開發趨勢，所以目前還是會持續關注。

以上是初步試玩 Polymer Web Components 的一些心得，更多的 feature 可以到 W3C 和 Polymer 網站看看，如果有錯誤的地方也歡迎糾正，祝大家有個愉快的開發旅途 :-)

Reference

從無到有：安裝＆自動部署 Ruby on Rails 網站

Tue, 28 May 2013 00:00:00 GMT

這個月把網站從 Amazon EC2 搬回自己的 server，目前整個環境是 Linux（Ubuntu）+ Apache + Ruby on Rails 在跑，筆記一下從無到有的配置方法：

Install VirtualBox

虛擬主機，另一個較有名的是 VMWare，這裡是選用 VirtualBox 4.2.12 作 host。

安裝之後設定一下配置，大部份都用預設的就可以，比較不一樣的地方有，記憶體 1024 MB，網路使用橋接界面卡的方式，這樣可以在虛擬 OS 內連線取得固定 IP，這對使用自有網址來架設網站是很重要的。

Install Ubuntu

下載 Ubuntu 最新版本，這裡使用 13.04，然後將映像擋掛載在 VirtualBox 後啟動，照指示一步一步安裝。

安裝完成後，記得先把系統更新裝一裝，之後執行：

$ sudo apt-get update
$ sudo apt-get upgrade

Install SSH

安裝完 ubuntu 後，為了之後能遠端操作 server，所以接著安裝 SSH：

$ sudo apt-get install openssh-server
$ ssh-keygen -t rsa
$ scp .ssh/id_rsa.pub SERVER_HOST_NAME:~/.ssh/
$ cat .ssh/id_rsa.pub >> .ssh/authorized_keys

註：第 2–4 步是為了之後登入 server 可以不用打密碼

註：第 3 步的 SERVER_HOST_NAME 記得換成自己的網址或 IP

Install vim

接著是安裝 vim，為了之後能在 terminal 上直接編輯文字檔案 or code：

$ sudo apt-get remove vim-tiny
$ sudo apt-get install vim

Install Git

版本控制，因為之後部署網站都是直接從 GitHub 拉下來，所以需要安裝 Git：

$ sudo apt-get install -y git-core

如果需要使用到 GitHub SSH 的話請參考這篇：Generating SSH Keys

Install NVM + Node

雖然我的網站還沒使用到 Node.js 的技術，但接下來要安裝的東西需要跑 javascript，所以這裡需要先安裝。

NVM 是 Node.js 的版本管理套件，可以輕鬆安裝、移除、切換任意版本的 Node：

$ sudo apt-get install build-essential libssl-dev curl
$ git clone git://github.com/creationix/nvm.git ~/.nvm
$ echo ". ~/.nvm/nvm.sh" >> .bashrc
$ bash

NVM 安裝完成後，接著安裝 Node，這裡使用 0.10.0 的版本：

$ nvm install v0.10.0
$ nvm alias default 0.10.0

Install RVM + Ruby + Rails

同 NVM, RVM 是 Ruby 的版本管理套件：

$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"' >> ~/.bash
$ source ~/.bashrc
$ bash

接著安裝 Ruby 1.9.3：

$ rvm install 1.9.3
$ rvm use --default 1.9.3

接著安裝 Ruby on Rails：

$ gem install sqlite3 --no-ri --no-rdoc
$ gem install rails --no-ri --no-rdoc

Install Apache + Passenger

接著安裝 server，通常有 Apache 或 Nginx 兩種，這裡是選用 Apache：

$ sudo apt-get install -y apache2-mpm-prefork apache2-prefork-dev libapr1-dev libaprutil1-dev libcurl4-openssl-dev

安裝完 Apache server 後，要讓 Rails 能在上面 run，需要安裝 Passenger 套件：

$ gem install passenger
$ sudo passenger-install-apache2-module

在安裝完成後，會看到 LoadModule 的配置訊息，把它貼到 /etc/apache2/conf.d/mod_rails，大致上會類似這樣：

LoadModule passenger_module /home/YOUR_RUBY_PATH/gems/passenger-4.0.2/libout/apache2/mod_passenger.so
PassengerRoot /home/YOUR_RUBY_PATH/gems/passenger-4.0.2
PassengerDefaultRuby /home/YOUR_RVM_PATH/wrappers/ruby-1.9.3-p429/ruby

接著在 /etc/apache2/sites-enabled 底下建立一個 YOUR_APP.conf，加入以下設定：

<VirtualHost *:80>
ServerName YOUR_DOMAIN_NAME
DocumentRoot YOUR_RAILS_PATH/public
<Directory YOUR_RAILS_PATH/public>
  AllowOverride all
  Options -MultiViews
</Directory>
</VirtualHost>

接著重啟 Apache：

$ sudo a2dissite default
$ sudo service apache2 reload
$ sudo service apache2 rstart
$ sudo apache2ctl restart

大致上 server 環境都建置好了，最後要設定自動化部署工具，使用 Capistrano 這個套件：

$ gem install capistrano

安裝完之後，前往你的 Rails 目錄：

$ capify .

指令完成之後 Rails 目錄會新增 config/deploy.rb，開啟並設定一些部署參數，大致上會如下：

set :application, "YOUR_RAILS_APP_NAME"
set :repository,  "YOUR_GIT_REPOSITORY_PATH"

set :branch, "master"
set :scm, :git
set :user, "YOUR_GIT_USERNAME"
set :port, "22"
set :deploy_to, "YOUR_SERVER_APP_PATH"
set :deploy_via, :remote_cache
set :use_sudo, false
role :web, "YOUR_WEB_SERVER_DOMAIN"
role :app, "YOUR_APP_SERVER_DOMAIN"
role :db,  "YOUR_DB_SERVER_DOMAIN"
…

接著可以開始部署了：

$ cap deploy:setup
$ cap deploy:cold

下完以上指令後，server 上的目錄會出現 current，release 這些資料夾，current 這個目錄就是最新部署的位置，前往這個目錄，安裝從 Git 拉下來的 Rails：

$ bundle install

這樣就完成所有 server 部署的配置了，之後只要網站有更新，直接執行以下部署指令，server 就會從 Git 上自動更新：

$ cap deploy

如果以上步驟都沒發生問題，網站也成功運行，別忘了使用 VirtualBox 的快照功能，儲存一份當前狀態，這樣之後就算 server 被搞爛了也能迅速恢復到最初狀態 :-)

小撇步：

不習慣 Ubuntu 的視窗桌面，可以使用 Ctrl-Alt-F1 切換到 Console mode，Ctrl-Alt-F7 切回視窗模式
有時會發生 server 網路斷線的情況，雖然不知道這招是不是對的，但用到現在網路還蠻穩定的，開啟 /etc/ppp/options，將 lcp-echo-failure 值設高一點，這裡設 15

參考文章：

Ruby on Rails 實戰聖經

如何寫一個 Arduino Library？

Fri, 26 Apr 2013 00:00:00 GMT

假設要寫一個摩斯密碼（telegraph）的 library：

先在 Arduino 目錄底下（預設是/Users/XXX/Documents/Arduino）建立一個 libraries 資料夾
建立一個資料夾取名為 Telegraph
建立 Telegraph.h

#ifndef Telegraph_h
#define Telegraph_h

class Telegraph
{
public:
    Telegraph();
    void send_message(const char* message); // 要公開給別人使用的 method.
private:
    ...
};
#endif

建立 Telegraph.cpp（舊版使用 WProgram.g，新版使用 Arduino.h）：

#if defined(ARDUINO) && ARDUINO >= 100
#include "Arduino.h"
#else
#include "WProgram.h"
#endif
#include "Telegraph.h"

Telegraph::Telegraph() {
    ...
}
void Telegraph::send_message(const char* message) {
    ...
}

到這邊基本上已經寫好一個 library 了，接下來開啟一個新的 Ardiono 專案來使用：

#include <Telegraph.h>

Telegraph telegraph();
void setup() {}
void loop() {
  telegraph.send_message("Hello world");
}

更多詳細的範例原始碼可以參考這個 GitHub repository。

Hello Arduino!

Sun, 14 Apr 2013 00:00:00 GMT

說來慚愧，去年才知道有 Arduino 這麼好玩的東西，連國外小朋友都知道它有多火紅！（不過最近好像是某樹莓派比較牛）。

好歹以前也是電子相關科系的，想說入門應該不難，回老家把塵封已久的高職工具包翻出來，今年要試作一隻簡單的機器人！既然決心已定，就開始做一些行前準備，買了幾本書跟一些工具來練習：

Arduino快速上手指南

Prototyping Lab「邊做邊學」Arduino的運用實例

Make

由馥林文化代理出版，國際中文版的雜誌，一季一期，訂閱一年約一千台幣，裡面的內容很豐富，強力推薦！

入門工具包

雖然自己有一些零件，但是要能完成書上的作品還是有缺，所以買了一個簡單的工具組合，基本上拍賣網站都能找到，價格大約都在一千元台幣上下。

猜數字遊戲

這是我的第一個實作，也是 Arduino 快速上手指南的第一章，主要的玩法是先用第一顆按鈕按出你要猜的數字，LED 會以二進位的方式顯示，決定後再按下另外一顆按鈕，Arduino 會隨機產生一組數字，如果玩家猜中的話，LED 燈就會閃爍。

這個小電路做完後基本上可以了解：

如何在電腦上寫程式, 並上傳到 Arduino 運作
基本的電路零件知識，ex：LED、push button
如何利用 Serial 來 debug
如何利用 Serial 來傳送和接收資料
如何使用網路上別人寫好的 Library

碰到的問題

一開始電腦一直抓不到板子，後來發現我的 USB 線是充電專用的囧

getDefinitionByName with swc

Wed, 06 Mar 2013 00:00:00 GMT

一般 Flash 程式開發時，取資源的方式有兩種：

.swf
.swc

.swf 檔屬於 Runtime 時從外部載進來取用的方式，通常會使用 Loader 來作處理：

var loader:Loader = new Loader();

var request:URLRequest = new URLRequest('YOUR_SWF_PATH');

loader = new Loader();
loader.load(request);
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, onLoaderComplete);

private function onLoaderComplete(event:Event):void
{
  var loader:LoaderInfo = event.currentTarget as LoaderInfo;

  loader.removeEventListener(Event.COMPLETE, onLoaderComplete);
}

private function getClassReference(className:String):Class
{
  return loader.contentLoaderInfo.getDefinition(className) as Class;
}

.swc 擋則是 Compiler 時就會一起包進來，要取用內部元件通常就直接 new 出來就可以：

var component:CLASS_NAME = new CLASS_NAME();

如果想要動態取得元件的話會碰到一些問題，一般來講會用 getDefinitionByName(CLASS_NAME:String) 這個 method：

import flash.utils.getDefinitionByName;

var ClassReference:Class = getDefinitionByName("CLASS_NAME") as Class;
var obj:Object = new ClassReference();

不過編譯完執行後會碰到錯誤，解決方式如下：

Project > Properties
Flex Compiler > 加入參數 -include-libraries=YOUR_ABSOLUTE_SWC_PATH.swc

Sublime Text 2 Shortcuts (Mac OSX)

Mon, 04 Mar 2013 00:00:00 GMT

General

Command palette⌘ + ⇧ + P
Toggle side bar⌘ + K + B

Goto

Goto anything⌘ + P
Goto symbol⌘ + R
Goto line⌃ + G

View

Destraction Free Mode^ + ⇧ + ⌘ + F

Edit

Select line⌘ + L
Select word⌘ + D
Delete from cursor to end of line⌘ + K + K
Delete from cursor to start of line⌘ + K + ⌫
Delete line⌃ + ⇧ + K
Duplicate line⌘ + ⇧ + D
Join lines⌘ + J
Upper case⌘ + K + U
Lower case⌘ + K + L
Jump to matching brackets⌃ + M
Select content into brackets⌃ + ⇧ + M
Comment⌘ + /
Block comment⌘ + ⌥ + /
Autocomplete⌃ + Space
Insert line before⌘ + ⇧ + ↩
Insert line after⌘ + ↩
Move up line⌃ + ⌘ + Up
Move down line⌃ + ⌘ + Down
Fold⌘ + ⌥ + [
Unfold⌘ + ⌥ + ]

HTML

Close tag⌘ + ⌥ + .
Select content into tag⌘ + ⇧ + A

Find

Find⌘ + F
Replace⌘ + ⌥ + F
Find next occurrence of current word⌘ + ⌥ + G
Select all occurrences of current word for multiple editing⌘ + ⌃ + G
Find in files⌘ + ⇧ + F

Splits

Single column⌘ + ⌥ + 1
Two columns⌘ + ⌥ + 2
Grid (4 groups)⌘ + ⌥ + 5
focus group⌃ + Num
Move file to group⌃ + ⇧ + Num
Select tab⌘ + Num
Switch tab⌃ + tab

Custom

Reveal in side bar⌃ + ⌘ + R

Package

Emmet

Expand abbreviationTab or ⌃ + E

EasyMotion

Jump⌘ + ; + a-zA-Z0-9
Select all text between cursor⌘ + ⇧ + ; + a-zA-Z0-9

Sass Build

Build⌘ + B

JsFormat

Format javascript⌃ + ⌥ + F

我的數位生活 2012

Thu, 28 Feb 2013 00:00:00 GMT

這次不談程式的東西，來聊一些 2012 年的數位生活心得，這幾年許多應用快速雲端化加上智慧型裝置普及率提高，幾乎大部份的工作都可以離開 PC 來完成了，剛好在去年我達成了 Apple 家族四天王（iPhone、iPad、AppleTV、Macbook（制霸！所以在這邊整理分享 2012 年用了哪些服務。

因為我手上的裝置都是蘋果，所以下面介紹的服務會以 iOS 系列為主，Android 的朋友抱歉囉。

我在找想用的服務時會盡量挑以下幾點符合的：

**多螢一雲，**有提供各平台的 app、網頁，或桌面應用軟體
**社群化，**擁有自己的社交互動圈，或整合 twitter、facebook 等服務
**手機為主 PC 為輔，**優先挑選手機 app 好用的服務

另外，根據服務性質的不同，也會看是適合哪個平台來選擇，例如：

iPhone 人在外面，ex：工作、通勤等，通常生產力相關的工具會比較適合在這時候使用
iPad 在家裡，但不是電腦前，ex: 沙發、床上，通常使用閱讀，影片，繪畫軟體較適合
Apple TV 在客廳，不過軟體不多，通常都拿來看影劇和聽音樂居多
PC 電腦或筆電，通常都是拿來做較複雜的事情，ex：整理、規劃、編輯

OK，在了解完我挑選應用服務的方式後，下面列出的就是我要分享的清單：

知識管理
生產力管理
人脈管理
財務管理
休閒娛樂

知識管理

資訊爆炸的時代，每天有非常多的新訊息從四處而來，不應該漫無目的的吞嚥，需要過濾有用的資訊來吸收。

Google Reader web

我一天最主要的新聞來源不是報紙或入口網站，而是 Google Reader，它會自動把我訂閱網站的新文章送到我眼前，是經過過濾對我而言有用的資訊。

所有我想關注的網站，都會經由 RSS 發送最新文章到 Google Reader 上，我從 2010 年開始使用到現在，訂閱網站數 200 個左右，目前一天大概會有 400 至 600 篇新文章，當然不會每天都把它讀完，所以分類很重要，以下是我在訂閱一個網站時的判斷標準：

**重要程度：**依照網站文章對你的重要性分一顆星到三顆星
**語言：**依照網站語言來分類，ex: 中文、英文、日文
**類型：**一般分類，ex：攝影、科技、設計

所以當我訂閱網站時，最少會給它三個標籤來分類, 例如我每天必讀的 WIRED.tw，我給他的分類就是 ✭✭✭中文科技，每天一定會把三顆星的文章看完，剩下的如果沒時間讀, 就毫不猶豫的把它設定成已閱讀吧。

將 Google Reader 這個基石穩定後, 之後的很多服務都可以跟它串聯：

Reeder iPhone iPad

簡單講，這是一款 iPhone 和 iPad 的 Google Reader app，類似應用在 app store 很多，試用過幾套後選擇這款，速度流暢品質高，平常搭交通車就看手機，睡前在床上就看平板，讓你隨時閱讀有興趣的文章。

Zite iOS

Zite 這款 app 就有點不一樣，他會根據你的 Google Reader 訂閱網站來分析一些你會有興趣的文章，算是 Google Reader 的球探，幫你找出還沒訂閱的資訊來源。Zite 除了分析你的 Google Reader 外，還可以導入像 Twitter、Facebook 和接下來會提到的 Pocket 來分析你平常看的文章，加強過濾呈現的文章。

Pocket`web iOS

Pocket 是一個稍後閱讀服務，類似網站也不少，我從去年才轉用 Pocket，之前是 Instapaper。

如果比喻 Google Reader 是一份我想看的報紙，那 Pocket 就是我剪下的文章收集盒，每天有這麼多的文章呈現在你面前，但是當你讀到一篇不錯的文章時，想要先保存下來，之後在細細品嘗時，就是 Pocket 的強項了，Pocket 提供瀏覽器外掛，當你在網路上發現有趣但還沒時間讀的文章時，就可以把它先暫存起來。

所以最後我真正想讀的文章會是在 Pocket 這個收集箱裡面，Google Reader 只是我快速瀏覽的地方，每看到一篇有趣的標題時，就會把它加到 Pocket，然後再一次好好的把它讀完，讀完的文章點一下打勾的按鈕將它封存起來，盡量不要讓存在 Pocket 的待讀文章留太多。

Evernote web iOS

前面講到 Google Reader 是一份報紙，Pocket 是文章收集盒的話，那 Evernote 就是你的剪貼簿了！

Evernote 這幾年相當火紅，用途很廣，尤其日本有不少針對 Evernote 深入使用的相關書籍，而我自己本身是將 Evernote 拿來當數位筆記本來使用，會把一些有用的精華文章筆記後收藏起來，Evernote 同樣提供一些有用的瀏覽器外掛讓我們使用更方便，其中最推薦的是 Clearly 跟 Evernote Clipper 這個套件，它可以先把網頁轉成好閱讀的純圖文，然後提供畫底線工具增加筆記方便，再將編輯過的文章同步到 Evernote，之後若是 Google 搜尋的關鍵字已經有相關筆記時，就可以直接派上用場了，目前我自己主要將筆記本分成這幾類：

學習筆記本 用來放一些程式設計相關的筆記，例如一些工具的安裝流程
知識筆記本 收集一些跟日常相關的筆記，ex：理財、健康
點子筆記本 當你在路上突然有了一些 idea，趕快拿起手機簡單記一下，回到電腦前再詳細編輯
圖鑑筆記本 通常拿來放一些網頁的設計圖片，或是一些工具的列表
名言筆記本 會把一些很喜歡的名言放在這本筆記
笑話筆記本 顧名思義，裡面全部放一些收集來，令人會心一笑的笑話
食譜筆記本 簡單的食譜筆記，不過發現很少使用，後來都是使用愛料理之類的網站較多
旅遊筆記本 為了去年第一次去日本自助旅遊而開的筆記本，從頭開始規劃很有成就感！
工作筆記本 一些工作上會用到的注意事項，ex：列印機安裝步驟

Delicious web iPhone

跟 Google Reader 不同，Delicious 是一個單純的書籤收藏服務，但它不是很好用，類似服務做得更好的有一堆，但已經是老字號了所以就，加上現在的瀏覽器都已經內建同步書籤的功能，所以 Delicious 已經不是很重要了，好處就是使用者多，當你收藏一個網站後可以看到其他人對這個網站的評論和分類建議，當我從 Google Reader、Pocket 或者其他地方看到了一個不錯的新網站，我就會使用 Delicious.com 這個外掛來加入書籤，連分類都幫你分好了，方便之後能快速搜尋。

Blogger web iOS

當然只是閱讀新知是不夠的，定期寫一些文章回饋社會也是很重要的，訓練聽讀寫說中的寫技能，網誌服務也是很多，Wordpress 跟 Blogger 應該算是比較大的，而我自己已經使用 Google 的 Blogger 約三年左右，雖然彈性不比自己架的 Wordpress 大，外掛也少得可憐，但是穩定，平常寫寫文章，看看分析其實就夠了。

生產力管理

不管是工作還是日常生活，好好運用生產力工具能幫助你大大提升效率。

Gmail web

我想大部份的人應該都是用 Gmail 來收發信吧，直到最近這幾年智慧型裝置起來，我自己本身是使用 iPhone 內建的郵件，我把所有私人信箱跟公司信箱都整合在 Gmail，然後再經由 Exchange 同步到手機，所以只需要一組 Gmail 帳號我就可以管理所有來信了。

Google Calendar web

行事曆部分跟信箱差不多，已經把私人跟公司行事曆整合到 Google 月曆，然後再同步到手機行事曆統一管理，像會議通知這種需即時知道的事情還是以手機為主會比較適合，以前都是需要在電腦前開著桌面月曆之類的軟體才能掌握行程，現在智慧型裝置時代已經變成時間快到時會主動通知你的方便模式，所以才會以手機為主，PC 為輔，手機就是你的專屬秘書。

Reminders web

這種待辦事項的軟體我也用了很多種，最後 iOS5 內建後我就一直用到現在，功能上雖然陽春，但已經夠用了，目前我把它規劃成三種清單在使用：

繳費清單 一些定期要繳的費用，ex：房租、水電、手機網路費
購物清單 想到要買的東西就加到這份清單吧，到大賣場時檢查特別方便，ex：垃圾袋、蛋
待辦清單 其它不屬於上面的提醒事項就加到這份清單吧，ex：剪頭髮，換機油

Notes web

這個手機內建的備忘錄和 Evernote 不同，比較適合記錄一些可拋棄的小記事，手邊又剛好沒有紙筆的時候，例如主管突然交代的文件列印之類的。另外，用錄音的方式記下來也頗方便唷。

Dropbox web iOS

雖然 Dropbox 跟 Google Drive 這兩個看似一樣的東西，但仔細用過後還是有一些差異，我個人的用法如下：

Dropbox 同步/備份電腦上大部份的檔案，與其他人分享資料夾共同協作
Google Drive 儲存/開啟信箱的附件檔案

人脈管理

Google Contacts web

跟 Gmail 在一起的聯絡人管理服務，看起來很陽春，可是為了方便寄信，所以還是繼續在用，一樣可以經由 Exchange 同步到 iPhone，不過一些項目跟大頭貼同步後會有問題，但不影響使用，基本上認識了新朋友或是在 Facebook 找到老朋友，我都會馬上在 Google 聯絡人上建檔，個人資訊也會盡量齊全，例如生日會自動同步到行事曆，電話號碼也可以直接用手機播打，聯絡地址也能直接開啟地圖找路，是個有價值的投資。

Facebook web iOS

雖然在隱私方面一直有爭議，但不可否認因為 Facebook 的關係，我找回很多已經失聯的老同學，並且當下還能繼續和親戚好友同事保持聯繫，而類似的社交服務我也用不少，看似性質相同，但還是可以做區別：

Facebook 真實的社交圈互動
Twitter 碎碎念，關注名人
Google+ 參與一些社群的議題
Linkedin 業界相關的人脈

LINE web iPhone

去年迅速竄起的火紅通訊服務，用來和關係較好的朋友即時聊天打屁用，基本上用了 Facebook 和 LINE 之後，MSN 就已經可以冰箱了，加上豐富有趣的表情符號跟積極擴張服務的 LINE，未來不容小覷。

財務管理

随手记 web iPhone iPad

這是一款記帳軟體，難得在這麼多的服務之中看到一款中國大陸的軟體，我從大學時期就開始用過不少相關軟體，這款隨手記不管是品質、設計、功能、更新上都無話可說，而且也是少數提供三螢一雲的記帳服務，用了兩年下來，它的分析功能讓我在理財規劃上得到不少幫助，清楚瞭解你的錢到底都花到哪裡去，經過 2012 年的檢討後，我決定今年要改變新的理財方式，參考了六個罐子理財法後，打算將每個月的薪資用下面的方式作分配：

生活帳戶 (55%) 基本上這裡的錢就是我一個月可以花的預算，食衣住行生活費，餘額存回定存
定存帳戶 (12%) 長期儲蓄
投資帳戶 (10%) 可以動用的投資現金
教育帳戶 (08%) 投資自己的帳戶，用來買一些學習用的書籍等，每個月餘額會存回定存帳戶
娛樂帳戶 (08%) 非生活的花費全部歸在這，ex：看電影，一樣每個月餘額存回定存
預備帳戶 (04%) 緊急預備金，保持在三個月生活費，剩餘用來孝親，公益，人情往來等
活存帳戶 (03%) 短期的儲蓄，ex：旅遊基金

休閒娛樂

iTunes Match

音樂是人類最偉大的發明 No music no life

不管是工作，搭交通，在家，音樂對我來講非常的重要，本來一開始是用 Google Music，優點是有 Web 界面可以使用，但是遲遲沒有好用的 iOS app，加上後來買了 Apple TV 之後，經過評估，還是投向 iTunes Match 的懷抱，iTunes Match 可以將你的所有音樂傳上 iCloud，並且還有機會轉成高音質，之後不管是用手機、平板、電視，都可以直接把你的音樂庫搬出來聽，而且沒有容量限制，讓隨身攜帶的 16G iPhone 也能隨時播放 3000 首歌！

Last.fm web iPhone

另外提個有趣的服務，Last.fm 是一個音樂的社交服務，安裝外掛之後可以紀錄你的音樂收聽紀錄，幫你分析並推薦符合你興趣的新歌給你。

TuneIn Radio web iOS

電台廣播服務，當不知道要聽什麼音樂的時候我就會開個廣播電台來聽聽，有時會意外發現不少好聽的新歌唷！

SoundHound iOS

不小心讓你聽到一首好聽的音樂，但你卻不知道歌名時，就可以拿出手機開啟 SoundHound，它會幫你分析並找出符合的音樂資訊給你，還會附帶 YouTube 影片讓你看喲！

YouTube web iOS

YouTube 就不用介紹了，全世界最大的影音分享社群，其中稍後觀看功能很重要，就像前面提到的，沒時間看完影片的時候可以先暫存起來，等搭車時再拿出手機，在床上時拿出平板，在沙發上就看 Apple TV，任何時間，任何地方都可以繼續觀賞這些影片。

Podcast iOS

Apple 出品的 Podcast 雖然評價一直不高，但上面還是有很多很棒的廣播內容可以訂閱，例如 TED 系列，還有繁體中文字幕喲，而且可以直接在 Apple TV 上看，非常值得！

iTunes U iOS

同樣是 Apple 的服務，iTunes U 主要提供大學院校的課程讓使用者觀看學習，很多很棒的內容，例如史丹佛大學的 iOS 開發課程系列，收獲良多！

Google Map web iPhone

Google 地圖我想已經成為你我生活中不可或缺的重要服務吧，尤其對我這種路痴而言，規劃路線、街景，還有完整的商家資料等，都是很有用處資訊，而且 iPhone 版的 app 也終於上架了，不過因為新法規上路，騎車的時候不能使用手機，讓我對之後要推出的 Google Glass 更加期待了。

Foursquare web iPhone

Foursqure 也是一個近期火紅的打卡服務，除了打卡收集成就徽章這個有趣的地方外，我去年去高雄跟日本前都會利用它提供的清單功能來事前規劃，每到一個地方直接開啟預先規劃好的清單打卡，方便之外還可以檢視和分享自己的旅行足跡，非常實用！

Foodspotting web iPhone

美食地圖分享社群，不過國內使用率不高，可以連結 Facebook 帳號同步分享你吃過的美食。

Picasa web

Google 的相簿服務，雖然 Flickr 比較多人使用，但我只是放一些旅遊的照片，拍的也不專業，就拿 Picasa 來管理相簿了，而且我都直接用手機拍照，然後使用 Google+ 的自動上傳功能，有時間在電腦前就可以直接整理所有照片，非常方便，當然它提供的功能也一點都不馬虎，人臉辨識、影像處理、地點事件分類，社群分享等都很有用。

Instagram web iPhone

不同於 Picasa, Instagram 比較偏向生活中隨處發現的小照片分享，通常可以從一個人拍的相片中看出個人生活風格，是個很有趣的服務。

Vine iPhone

簡單說是短片分享的 Instagram，類似服務還有 Viddy，不過老實講我不是很常使用，因為沒有拍短片的習慣囧，都是無聊看看別人分享的有趣影片居多。

Anobii web iOS

書籍閱讀分享社群，在書店看到一本想買的書，可以直接用手機掃瞄條碼加入到欲購書單，觀望中的書也可以看看別人留的書評，根據你的書櫃分析出你可能會想看的書籍，很棒的服務！

iBook

雖然台灣的 app store 上沒什麼書可以下載，但支援 pdf 跟 epub 匯入，所以還是可以閱讀許多電子書籍，iPad 必備軟體！

Newsstand

跟 iBook 比較起來，這個書報攤的雜誌數量就比較豐富了，直接訂閱最新雜誌，解決去舊雜誌佔空間的問題，而且很多都有免費預覽版，也是 iPad 必備軟體之一！

呼，寫到最後發現越寫越短囧，不過後面的東西一開始本來不打算寫的 :P，精華都在前面就講完了，有任何想法非常歡迎留言給我，感謝！以上。

Flash Builder 4.7 iOS Debug

Mon, 28 Jan 2013 00:00:00 GMT

這個月剛好玩到 flash on iOS，在部署到 iPad 時碰到些問題，筆記一下最後解決的步驟。

Flash Builder 4.7 提供三種方式部署和測試你的程式:

On AIR Simulator
On iOS Simulator
On device

開發環境:

Mac OSX 10.8.2
XCode 4.5.2
Flash Builder 4.7 Premium
Adobe AIR SDK 3.5

STEP:

先開啟 Xcode 確定有更新到最新版，否則模擬器會有問題。
到美國Adobe官網下載安裝 Flash Builder 4.7，可試用兩個月。
前往 /Applications/Flash Builder 4.7/sdk/ 底下。
複製一份 4.6.0 的資料夾命名為 4.6.0_AIR35。
下載最新 AIR SDK 到剛建立的資料夾。
開啟 Terminal
cd /Applications/Flash Builder 4.7/sdk/4.6.0_AIR35/
sudo tar -jxvf <下載的AIR SDK>
準備好 Apple Developer 的 .p12 和 .mobileprovision。
Debug your app!!

最後發現 Adobe 還提供一個免費又強力的效能檢測工具 Adobe Scout。不過一開始碰到不少問題，Flex 專案沒辦法跟 Scout 連上，最後 Google 到的解決方法:

確定你有安裝 python 的環境。
下載 telemetry-utils。
開啟 Terminal cd 到 telemetry-utils 資料夾底下。
add-opt-in.py <YOUR FLEX bin .swf file>
然後再 Run 就可以看到 Scout 的結果了。

缺點是每次重新 Build 的時候就失效了，需要再下一次指令，期待之後會改善。

AS3 Class Enumeration

Wed, 03 Oct 2012 00:00:00 GMT

筆記筆記..

一般在 AS3 要列舉 Object 的 properties 時，通常會用下面這種寫法：

//Get an XML description of this class
//and return the variable types as XMLList with e4x
var varList:XMLList = flash.utils.describeType(VO)..variable;

for(var i:int; i < varList.length(); i++){
  //Show the name and the value
  trace(varList[i].@name+':'+ VO[varList[i].@name]);
}

不過在處理 VO（Value Object）時則會出問題，因為它是 Class，後來在這篇文章找到解法：

for (var key:String in object)
{
  trace(key+':'+ object[key]);
}

讀書心得半路叛逃

Wed, 03 Oct 2012 00:00:00 GMT

要在台灣看到遊戲開發的相關書籍其實不容易，其中獨立遊戲開發者的心路歷程更是少之又少。

難得最近書店上出現了一本程式出身的遊戲制作人半路(猴子靈藥站長)大的甘苦談，二話不說就買回家看了~

從小就喜歡玩遊戲的我，一直認為遊戲制作人是一個很夢幻的工作，如果我會一直待在遊戲業的話，也希望未來能成為一位獨立遊戲開發者，做自己想做的遊戲！

獨立遊戲開發者最近還蠻受注目的，尤其前陣子 Indie Game: The Movie 這部紀錄片的播出，真的令人熱血沸騰。

花了兩天中秋假期，把這本《半路叛逃 App遊戲制作人的1000告白》啃完，收獲良多，因此上來寫一篇簡單的書摘。

“1980年代前是經歷過經濟成長起飛的父母長輩，1980後是成長於物質與資訊不虞匱乏的我們”

上一代眼裡認為我們是早熟的一群，因為一切的成長來得太快，但其實隨著學歷要求提高，新鮮人起薪越來越低的情況，延後了我們踏入社會的時間，事實上心理狀態相對起來是晚熟的。

這點台灣跟日本很像，反觀大陸和韓國比較像前者，他們還在衝，還在拼，所以無論是政府還是我們真的都必須在加把勁努力。

其它像30歲焦慮症，工作責任制等…半路在書中也有一些見解。

“早期國產單機遊戲的輝煌年代不在，如今的遊戲業如同製造業工廠般，都在把寶貴的研發能量投注於尋求「可複製的成功模式」，將遊戲「產線化」”。

為什麼台灣做不出百萬銷量的遊戲呢?

只鎖定台灣市場，三國，武俠，博弈，這些都是用到不能再爛的老梗了，別白白浪費iOS，Android 平台為我們開發者鋪好的通路，全球超過一億台智慧裝置的使用者在等著你，“世界從來沒有離我們這麼近過！”
只想複製別人的成功模式，緊盯著排行版前10名，然後致敬一款。
以為做App是低成本的事，魔鬼藏在細節，這裡有一句話我很喜歡，“會寫程式跟畫圖的人滿街都是，真正能夠做到磨亮細節的才是人才”，學習了。
想以量取勝，因為現在的遊戲價格低廉，為了賺錢以數量取勝，亂槍打鳥而失去了品質，其中提到一個概念，「最小可行產品」，不過這在製作遊戲原型可行，用在市場會有問題。
只是大遊戲的濃縮版，應該回到最初玩遊戲的感動，而不是將大團隊的開發方式原封不動的搬過來。
工廠化思維，只想找低風險的遊戲做。

為什麼你不該離職創業搞App

以為日常習慣不需要改變，需要過著沒有收入的苦日子，必須放棄過去奢侈的享受。
以為擁有百萬價值的創意，遊戲業中最不缺的就是「創意力」，還需要加上「執行力」才行。
以為可以全部自己來，創業最需要也最重要的就是伙伴，“球不是一個人就能踢底”。
以為只要專心做出遊戲就好，在小團隊中，「通才型」的伙伴會勝過「專才型」。
以為可以第一款遊戲就賺錢，別一開始就想做出你夢想中的遊戲。
以為可以享受自由的生活，還是需要維持規律的日常生活，才是開發遊戲的長久之計。
以為一個人獨處很簡單，“你需要專心，學會一個人獨處，至少不討厭和自己在一起”，離開喧囂的辦公室，沒有同事和你打屁聊八卦，獨處時會有很多幫倒忙的誘惑影響你，沒有自我規範的話很容易迷失。
以為不需要家人的支持，當你身處低潮失落狀態時，只有家人的愛能幫助你度過難關。
以為可以跟隨成功者的腳步，當遊戲App流行熱潮退去後，你是否會後悔當初的選擇？
以為創業就可以安心地做自己，需要參與社群，認識其他同伴，聆聽他們的經驗與忠告。

書上有提到 Scrum，主要聊了像為什麼一個工作的週期要以2週到4週，以及每日早上立會的原因，對想瞭解敏捷式開發的人有很大的幫助。

創業最難的就是找到好的伙伴，半路在一開始尋覓團隊成員時碰壁，他將原因歸納為三點：

他們擁有平順穩定的正職工作。
我的王道不等於他們的王道。
彼此缺乏合作動機。

“當你想獨立創業，沒有資金，沒有作品，沒有經歷時，要如何說服伙伴加入你的團隊呢？”

“將遊戲完整開發完成只是上半場，行銷才是決定勝敗的下半場”

App Store 「審核通過日」不應該設定為「上架販售日」。

開戰前四大法寶：

一定要拍遊戲影片，最合理的預告片長度為1分鐘左右。
必須要有官方網站，即使再小型的作品，也應該為它申請一個獨立的.com網址。
遊戲圖示第一重要，截圖第二。
發售前的宣傳準備。

每款 App 都擁有50組「推廣代碼」，需要好好利用。

第一次遊戲世界大戰：單機 v.s. MMORPG

第二次遊戲世界大戰，三大勢力：

網頁遊戲，Flash & HTML5
社交遊戲，Facebook
手機遊戲，iOS & Android

目前 App 主要獲利方式：

高定價，$6.99以上，國際級遊戲公司機會較大。
中定價， $2.99 到$ 4.99，適合較具知名度的小型團隊或獨立開發者。
低定價，$0.99，已是一片紅海，需要天時地利人和。
免費，內置廣告，需要龐大的下載數與每日活躍用戶。
免費，內置商城，平衡設計難度頗高。

遊戲玩家心理學「巴托爾測試」將玩家分為四種類型：

成就者，喜歡升級衝裝。
社交者，喜歡組隊聊天。
殺手，喜歡工會戰爭。
探險者，喜歡探險遊戲世界，也是目前大部份遊戲最缺的類型。

結語：

在遊戲進入網路世代後，因不時出現青少年鬥毆，詐騙，色情暴力廣告等因素，導致社會大眾普遍對遊戲的負面觀只有增而無減。

身為遊戲開發者的我們應該避免這樣的事情持續發生，玩遊戲明明是一件很快樂的事情！

「我已經決定這輩子要成為遊戲設計師」，很佩服半路大的這份堅定決心，這句話目前的我還沒有勇氣說出口，也許還要個兩三年，也許還要個十年，也許一輩子都沒機會，但能確定的是，做遊戲也是一件很快樂的事情！

“你有多久沒有用盡一切力氣，不計成敗的去做一件事情了呢？”

COSCUP 2012

Sun, 19 Aug 2012 00:00:00 GMT

今年很幸運的有搶到入場資格，這也是小弟第一次參加 COSCUP，趁現在剛結束滿腔熱血的狀態下來寫篇心得文。

今年 COSCUP 一共有兩天的行程，在中研院人文館舉辦，每個時段都有 3~4 場的分享，不過常常碰到某個時段三場都想聽，也常常碰到某個時段的題目都沒興趣…orz

Day1

第一天忘了做筆記，只好憑記憶跟拿些圖來湊一湊

早上第一場是微軟傳教士分享的 Windows Azure感覺還不錯，而且有繁體中文的介面。

第二場我去聽了 Fred 的 Nodee.js OS，不過我覺得他自己改的 Linux 比較炫。

第三場請到 Penk 大大來 demo 他的平板 UI，印象深刻的一句話是

科技業是唯一比女性時尚還追求時尚的行業

我的解讀是幹這行每天都在學新技術囧..

第四場超讚，講者 demo 他用 javascript 寫的超任模擬器，眼淚都快飆出來了，而且老師很幽默:

目前國外有人正在研究如何用 javascript 寫出一個超任模擬器，如果他成功，那會是全世界第三個，因為前面兩個被我寫出來了XDDD

接下來的下午場雖然都有去聽，可是比較沒有什麼印象的點，只記得最後閃電秀的大大們XD，你們實在太讚了!

Day2

難得有位置，明明很晚到…

第一場請到廣達的Ted 先生，本來以為會很無聊，但從頭聽到尾，學到蠻多東西的:

研發的目的 1.不想被外界surprise 2.想給外界surprise

不相信外星人就無法創造飛行車

要把複雜的東西變簡單其實是最不簡單的

設計一個你最討厭的東西試著把它做好

第二場去聽 Tool Objects in jQuery，主要重點:

用 Queue 取代巢狀 Callback
Deferred 可以看做是 Call by future
$.when 可以用來管理複數非同步的結果
pipe 跟 when 的關係可以看作串聯與並聯
一些 Callback 常用的 function: add fire once memory unique stopOnFalse differed

第三場的場次是我最掙扎的，有Heroku，有Emacs，有Twitter Bootstrap，還有手機控制家電，都是我好想聽的主題呀呀呀呀，最後選了Bootstrap，因為最近想玩它，主要重點:

Grid system
nav bar fixed top inner
Button group dropdown
tab nav list
Label badge pull right
Modal

第四場聽了 javascriptMVC，雖然我對 Backbone.js 比較有興趣，不過還是有幾個有趣的點:

CSS sass less
Data CRUD (create read update delete)
View embeddedjs
StealJs
fixture

第五場聽 HTC 的 CI

Jenkins CI
Testopia

第六場聽 Yahoo 的 Hadoop

第七場聽 Livescript (想聽Coffee script)

第八場比較振作了，聽了 HTML5 on Windows8，好想把 Gu Morning 上架到 Windows store T^T

最後閃電秀一樣沒讓人失望，笑料滿出XD，愉快的兩天一切都要感謝辛苦的 COSCUP 人員及贊助廠商，期待明年!

Development Tools

Thu, 02 Aug 2012 00:00:00 GMT

不知不覺，這個月的文章還沒想好要寫什麼，七月就過了…

這一篇我打算分享一些最近在關注的玩意兒。

Trello

Trello 是 Joel 團隊開發，一個專案管理的工具，當然，他是雲端網頁，所以在任何地方都可以掌握團隊的專案進度。

Trello 可以使用 Google 的帳號登入，登入後可以根據專案的開發流程自訂專屬的 Board ，每個 Board 內可以貼上各個項目的 Card，並且可以和專案成員即時協作。

自己本身大概用過兩三套這種 PMS 的產品，Trello 簡單易用，一個人獨立開發使用也很方便，算是敏捷式開發上不可或缺的好工具。

另外，Trello 也有提供 iPhone 的版本：

Sublime

Sublime 是一個很棒的程式碼編輯器，前一陣子在這篇 Which is the Best Code Editor? 得到很高的分數。

我用過之後也是愛不釋手，漂亮的配色，安裝容易的眾多外掛，不錯的開啟速度，總而言之，大力推薦!!

Cloud9 IDE

C9 也是一個寫程式的好工具，可是跟 Sublime 不同的地方，它是雲端網頁版的編輯器。

C9 支援的語言也不少，甚至可以直接跑 Node.js ，並且也支援 Github 的 Repository clone。

不過這幾天用下來發現速度不理想，常常會進入 Offline 狀態。

Heroku

Heroku 是一個雲端應用的 host 平台，支援的語言有 PHP Ruby Python Node.js。

Heroku 和 Facebook 合作，讓開發者開發 Facebook 應用程式的時候可以直接連結 Heroku 的空間，並且支援 Git ，目前初步試用下來感覺很不錯。

Travis CI

Travis CI，顧名思義，是提供持續整合(Continuous Integration)和每日建構的服務。

不過目前還沒機會使用，所以還不是很清楚它的詳細內容。

Travis CI 可以結合 Github，讓你隨時知道專案的測試狀況。

讀書心得約耳趣談軟體

Tue, 12 Jun 2012 00:00:00 GMT

以下是節錄一些這本書覺得還不錯的點

激勵是有害的，主要是說考績制度對程式設計師是不通的
工作切換有害無益，讓程式設計師只專注一件事情
絕對不能把程式碼重寫（這裡不是指重構）
冰山一角理論，冰山有 90% 是在水面下，大部分的軟體，那些漂亮的使用者介面通常只占 10% 的工作，而背後 90% 的程式設是看不到的，如果再考慮一半時間都在抓蟲，那使用者介面就只剩 5%，如果只計算介面中的視覺部分，那客戶真正看到的，只有 1%……，這並不是秘密，真正的秘密是非程式人員根本不知道這件事……

約耳測試：

你有使用原始碼控制系統嗎?？ SVN、CVS、Git、Mercurial…
你能用一個步驟建出所有結果嗎？準備一個 Script 擋，只要執行這個腳本，就能一次搞定從最新原始碼快照到自動建立釋出產品的過程
你有進行每日編譯嗎？提交原始碼到版本控制系統前，一定要編譯並且沒有出現錯誤，因為別人也想下班
你有沒有問題資料庫？記錄已知的 Bug 清單，每筆 Bug 需記錄：
重現問題的完整步驟
應該看到的結果
實際看到的結果
被指派的負責人
你會先把問題都修好之後，才寫新的程式嗎？愈晚修正問題，之後付出的代價成本愈高

你有一份最新的時程表嗎？程式設計師討厭排時程，但牽扯到業務人員的決策規劃，擁有時程可以強迫自己決定要作哪些功能，並剔除不重要的功能，以避免過度膨脹

使用一些 PMS 工具
時程表簡單就好
每個功能應該包含多項任務（Task）
只有實際要寫該程式的程式設計人員,才能排出該項目的時程
要把任務分的很細（以小時為單位）
紀錄最初和目前的估計
每天更新已消耗時間
把休假時間算進去
把除錯時間算進去
把整合時間算進去
把緩衝時間算進去
絕對不讓 PM 縮短估計時間

你有寫規格嗎？例如：GDD、TDD 又是一件程式設計師討厭的事情，設計初期的階段還看不出來，愈後期程式碼一多修正的代價就愈高，應貫徹沒有規格就不寫程式的原則
程式設計人員有沒有安靜的工作環境？需要讓程式設計師進入沈浸狀態（in the zone），因為這時候是最能全神貫注，生產力最高的狀態，所以，要有安靜的環境！！！
你有沒有用市面上最好的工具？你需要兩個以上的螢幕，以及編譯程式不會讓你抓狂的電腦配備
你有沒有測試人員？省下測試人員的錢並不是真正的節省，因為你會付出更慘痛的代價，這裡本書第 22 章有非常有趣的見解
是否在面試時要求面試的對象試寫程式？你會不請魔術師表演幾招就直接僱用他嗎，當然不會
是否進行過走廊使用性測試？隨機找幾位使用者試用你的產品，他們可以幫你發現程式中 95% 應該注意到的使用性問題

約耳認為軟體開發有各種不同的領域，他把它分為五個世界：

熱縮封膜軟體（Shrinkwrap）簡單來說就是一般常看到的軟體，商業軟體，共享軟體或開放源碼軟體等，特色就是使用者眾多，通常都有替代商品，所以開發者必須把東西做得更簡單易用才行
內部用軟體這類軟體通常是公司針對特定狀況下能執行就可以了，因此開發起來較容易，但開發者較不容易從中得到成就
嵌入式軟體這種軟體的特性是被放在硬體裡，且幾乎無法更新，因此品質要求會比平常高出許多
拋棄式軟體為了產生其他東西而暫時創造的軟體，當達到目的後就不會用到了，例如格式轉檔軟體
遊戲軟體遊戲開發的經濟學是打擊型，有些遊戲擊出安打，但更多的是三振，要賺大錢必須用很多的遊戲來平衡失敗的損失，和嵌入式軟體類似，版本修正代價大，所以品質要求高

紙上原型製作的重要性
別花太多時間想抽象的架構問題，邊開火邊移動！！！
寫程式並不是量產，也不是工匠技藝，它是一種設計

約耳認為面試人員應該問的問題：

簡介
最近專案的問題尋找熱情好的人選會仔細地把事情由各個層面解釋清楚如果專案是由多個人一齊負責, 尋找擔任領導角色的跡象
不可能的問題
程式問題
你有什麼問題嗎?

小員工也能做大事，這本書是關於軟體管理，不過有時候你並沒有那個權力去改變組織，如果你只是圖騰柱底層的一位程式設計人員，約耳給你一些建議：

去做就是了沒有每日編譯伺服器嗎？自己架一台就對了
利用病毒性行銷的威力團隊沒有在用版本管理系統？自己先用吧，等問題發生之後，他們就會來找你了
建立一個卓越圈找一些支持你的人一起改善吧
讓笨蛋無害有時候會有天才花兩個星期寫出一點點程式，而且爛到不可思議，這時候你會想花 15 分鐘把這段程式重新寫過，請忍住，因為這是把這個白癡拖住幾個月的機會，這段期間他不會再造成其他地方傷害了
遠離干擾環境
提升自己的價值

App Center Tutorial

Sun, 03 Jun 2012 00:00:00 GMT

本篇翻譯自 Facebook 開發者頁面的 App Center Tutorial

Facebook App Center 是一個大型的社交應用程式中心。App Center 是協助你的 Facebook Apps、手機 apps 和使用 Facebook Login 的網站的管道。Facebook 鼓勵所有開發人員在這個 App Center 建立您的 app 細節內容頁面。

這篇文章將引導開發者配置 apps 的過程：

建立一個 App 細節頁面
上傳圖片
網站和手機網頁的特別注意事項
提交您的 app 到 App Center

如果你還沒有在 Facebook 平台上建立一個應用程序，你應該參考 Apps on Facebook， Facebook Mobile 或 Facebook for Websites 開發指南。

本篇假定您已經熟悉 Facebook App Dashboard 的操作及基本設置，並且已閱讀 App Center Guidelines 。以確保 App Center 審查上市後，用戶在使用上有一個良好的體驗。

建立一個 App 細節頁面

所有的開發人員應在 App Dashboard 創建一個應用程式的詳細頁面。使用者可以經由這個頁面的資訊和截圖了解這個應用程式，然後開始登入使用。使用者通過認證之後，應用程式就會發送到他們的 Facebook 、網站或手機上。

要在 App Center 上架，App 細節頁面是必須的。這也將成為非 Facebook 用戶搜索時的目標頁面。

要訪問 App Center 的設置，到 App Dashboard 單擊在左側的 App Center 選項。

在這裡你可以輸入顯示在 App Center 應用程式的詳細訊息。包括應用程式的顯示名稱，類別，副標題和說明文字等等..。

請確保您的應用程式所支援的平台顯示。如果您正在測試 iOS 應用程式，且與您的 Facebook應用程式是相同的 App ID，但它仍然在開發中，你應該在細節頁面中隱藏 iOS 的平台配置。

註：如果您的網站支援 Facebook Login 並且同時擁有 Facebook App，那麼只需要顯示 Facebook App 在 App Center 即可，以減少用戶混淆。

最後，如果您之前尚未在設置協助訊息。則需要輸入隱私政策的URL，服務條款URL 和用戶支援電子郵件地址或URL。

上傳圖片

開發人員需要上傳圖示(icons)，橫幅(banners)和遊戲畫面(screenshots)。這些隨應用程式支持的平台可能會有所不同。例如，在 iOS 應用程式將需要上傳。圖片選項將依據適當的平台自動顯示在 App Center 選項中。

當您設計圖片時：

將您的應用程式名稱放置於橫福中。
預留一些空間給重要的圖形。
不要在圖片的邊界放置 Logo 和文字。
橫幅圖片必須填滿整個框架（例如，沒有空格，沒有圓角，無邊框）。
圖示(Icons)可以有圓角（建議使用帶透明度和PNG，不要GIF）。
請參閱 App Center Guidelines。

App Center 支持以下的手機螢幕解析度：

MDPI：240×480
HDPI：480×800
XHDPI：640×960以上

封面圖片：

設計封面圖片時，開發人員應該注意，128x128 圖示會稍微掩蓋住封面圖像的左下方。

遊戲畫面：

開發人員可以提交每個平台5張截圖的（Web，Canvas，手機 Web，iPhone，iPad，Android），至少須提交3個平台的遊戲截圖。

內容必須顯示真正的遊戲畫面，不能包含任何推銷資訊或橫幅。App Center 支持的截圖尺寸為 320×320 到 2048×2048 pixel 之間。

如果截圖的長寬比不適合在 App Center 的顯示框的長寬比，我們將自行縮放截圖。

畫面的選擇，根據用戶使用的裝置來查看頁面。如果您在 iPhone 上查看頁面，iPhone 的截圖會優先出現。如果應用程式不支援的 iOS 則手機 Web 的截圖會優先出現等。

有2個截圖的佈局設計：

一個直擺方向(portrait)+兩個橫擺方向(landscapes)。
三個橫擺方向(landscapes)。

授權(Authorization)

在 App Center 的應用程式細節頁面中顯示新用戶所需的權限。可以被視為驗證對話框(Auth Dialog) 中的一個版本，因此很容易直接從 App Center 為新用戶安裝你的應用程式。

在 App Center 下設置**權限(Permissions)**部分時，可以遵循以下：

用戶與好友的權限(User & Friend Permissions)：這些權限將顯示在 App Center 的應用程式的細節頁面。
擴展權限(Extended Permissions)：用戶通過點擊應用程式的細節頁面後，將出現對話框的提示驗證這些可選的權限，這意味著用戶可以取消這些權限，然後仍授權您的應用程式。
Auth Token Parameter：當用戶通過應用程式的細節頁面授權您的應用程式，我們將通過您的應用程式，在這裡指定 Auth Token 的格式。可用的格式：

請注意，有些用戶將直接從 App Center 導向到應用程式的細節頁面，其他用戶仍然可以通過直接輸入網址或通過 Feed， Requests和廣告導到您的應用程。在這些情況下，你仍然需要通過現有的驗證對話框(Auth Dialog) 授權處理。

Canvas App 的開發者(For Canvas Developers)

大多數 Canvas 應用程式是將新用戶通過客戶端重導向驗證對話框。提交到 App Center，用戶仍然可以通過直接輸入網址瀏覽到應用程式，應仍保持授權的需要功能。開發人員必須確保他們在這兩種情況下的同一組的權限要求; App Center 權限配置應符合開發商已經要求的 OAuth Dialog 參數。如果這些不匹配，用戶會看到兩種授權在提示，將造成用戶體驗混亂，導致您的應用程式無法在 App Center 上市。

iOS 與 Android 的開發者(For iOS and Android)

手機應用程式必須使用單點登錄（SSO）是在 App Center 上市的資格。只提供一個無縫的登入過程後，通過應用程式的細節頁面點擊列出在 App Center 的手機應用程式。

人們將能夠瀏覽 Facebook.com 的 App Center，和 Facebook 的手機應用。當人們要安裝原生的手機應用程式，他們將直接從 Apple 的 App Store 或 Google Play 下載應用程式。App Center 聯繫手機應用商場，旨在推動 iOS，Android 和手機網路巨大社交應用的成長。

網頁與手機網頁的開發者(For Website and Mobile Web Developers)

在 App Center 的應用程式的細節頁面，將採取授權的用戶才到達您的網站上的方式，但重要的是要確保這些用戶有個人化的體驗經驗，當他們通過從 App Center 點擊您網站上的資訊。用戶不應該點擊第二次登錄到 Facebook 按鈕，而是應該看到一些個人化的資訊，以優化用戶體驗。

下面的程式碼範例將檢查用戶是否已授權應用程式和顯示出個人資訊的歡迎訊息，例如 ‘Welcome, Constantin!’.。

<html>
   <head>
     <title>Example</title>
   </head>
   <body>
     <!-- Load the Facebook JavaScript SDK -->
     <div id="fb-root"></div>
     <script src="//connect.facebook.net/en_US/all.js"></script>
     <div id="welcomeMessage"></div>
     <script type="text/javascript">
       // Initialize the Facebook JavaScript SDK
       FB.init({
         appId: 'APP_ID',
   status: true,
       });

       // Check if the current user is logged in
       // and has authorized the app
       FB.getLoginStatus(checkLoginStatus);

       // Check the result of the user
       function checkLoginStatus(response) {
         if(response && response.status == 'connected') {
           // The user is connected to Facebook
           // and has authorized the app.
           // Now personalize the user experience

           FB.api('/me', function(response) {
             var message = document.getElementById('welcomeMessage');
             message.innerHTML = 'Welcome, ' + response.first_name + '!';
           });
         } else {
           // The user has not authenticated your app,
           // proceed with your normal (anonymous) flow.
         }
       }
     </script>
   </body>
 </html>

更多如何檢測用戶的Facebook狀態可以參考 JavaScript SDK， FB.getLoginStatus 文件，這個網誌文章的詳細資訊。

提交您的 app 到 App Center

對於一個應用程式在 App Center 上市，必須滿足您的應用程式的 guidelines 。Facebook將審查圖片，應用程式的細節訊息，和用戶體驗。如果您的應用程式被拒絕，我們將解釋為什麼並給你一些改變的建議。一旦您修正，可以在 App Center 重新提交上市。

開發人員可以提交之前預覽他們的應用程序的詳細信息頁面，在頁面頂部點擊”預覽”鏈接。這將顯示一個實時預覽：

開發人員可以提交他們的應用程式，通過點擊 App Center 的頂上方按鈕。一旦提交將會顯示一條訊息，提交正在等待審查。一旦你的應用程式已經批准，將更新此訊息。

注意：一旦您提交您的應用程式的細節頁面，設定值不能被改變，直到提交批准或取消提交。一旦你的應用程式的細節頁面在 App Center 上市，頁面上的所有未來的變化也將受到審查。

這些提交過程是所有應用程式要在 App Center 上市所需的，但所有的應用程式仍可以繼續使用 Facebook 的 API，Bookmarks， Requests， Timeline 和 News Feed。提交到 App Center 不是必需的，但鼓勵大家這麼做，作為應用中心提供了一個獲取新用戶的重要機遇。

How to list the properties of a javascript object

Sat, 19 May 2012 00:00:00 GMT

本篇參考 stackoverflow 的 How to list the properties of a javascript object

要如何知道 Javascript 物件擁有哪些 proerty?

var dog = {
  name: 'Lucky',
  age: 3,
  breeds: 'Shiba Inu'
};

上面是一個小狗的物件，裡面有一些自訂的屬性 'name', 'age', 'breeds' 等等…

那要怎麼在程式中知道這些屬性呢?

比較新的瀏覽器(IE9, FireFox, Chrome…)可直接使用 Object.keys 這個方法

var keys = Object.keys(dog);

或者自己寫

var getKeys = function(obj){
   var keys = [];
   for(var key in obj){
      keys.push(key);
   }
   return keys;
}

var keys = getKeys(dog);

這樣 keys 就會是一個有所有屬性的陣列

keys = ["name", "age", "breeds"];

參考文章：

How to list the properties of a javascript object

Javascript and this

Tue, 15 May 2012 00:00:00 GMT

筆記一個 javascript 的特性。

通常在使用一些 method 的時候參數都帶有 Callback Function：

click(callbackFunction)

如果在這個 Callback Function 裡面直接使用 this 是沒有辦法的：

callbackFunction = function() {
  this.doSomethiing(); // undefined
}

必須先在在外層定義 this 為一個變數才可以：

var self = this;

callbackFunction = function() {
   self.doSomethiing(); // OK!!
}

參考文章：Javascript — 淺談this與Closure

Javascript message on Facebook post feed

Sun, 04 Mar 2012 00:00:00 GMT

之前在使用Facebook API的時候碰到的問題,，筆記一下。

如果在沒有登入Facebook的情況下開啟 Feed Dialog 發佈訊息，會被導到一個莫名其妙的頁面，上面只有一串 javascript 如下

<script type="text/javascript">
window.location.href="fbconnect:\/\/success?
post_id=XXXXXX;
</script>

這個問題我碰到兩次：

一次是在網頁版直接使用 Graph API call 的方式開啟 Feed Dialog
一次是在 iOS Facebook SDK 中使用 Feed Dialog

iOS好像是在4.0以下才會發生，不太確定

解決方法：

找到呼叫 Graph API 的地方 ( iOS SDK 應該在 Dialog 相關的檔案裡)
將 https://m.facebbok.com/dialog/feed?xxxxxx 的 m 改成 www
還是不行的話就把 https 改成 http 試試，應該可以解決~

參考：Javascript message on Facebook Connect post to feed in iPhone/iPad app

Use getPixelRatio for HTML5 on retina

Sun, 04 Mar 2012 00:00:00 GMT

如果用 HTML5 配 WebView 來作 App 的話，在 iPhone4 跟一些 Android 手機會碰到的解析度問題。

iPhone4 的 Retina 是 960 x 640，但是在 WebView 底下會以 480 x 320 來顯示。

所以須要利用到 javascript 的 getPixelRatio() 來作調整：

/**
 * Return current device resolution pixel ratio, Default is 1.
 * @return {number}
 */
function getDevicePixelRatio() {

    if (window.devicePixelRatio === undefined) {
        return 1;
    }

    return window.devicePixelRatio;
}

這裡寫一支 function 來取得裝置的 PixelRatio，一般通常都 return 1，解析度較大的手機才會回傳其他數值，例如 iPhone4 則回傳 2。

最後寫一支 initDeviceViewport 的 function 來塞值給 viewport metadata tag，例如這裡 iPhone4 會將 viewport 的 scale 全部縮放為 0.5 倍。

/**
 * Initialize device viewport meta tag to full screen size.
 * @author http://jsway.se/?p=150
 */
function initDeviceViewport() {

    var scale = 1;
    var ratio = getDevicePixelRatio();
    if (ratio !== 1) {
        scale = 1 / ratio;
        scale = scale.toFixed(1);
    }

    var viewport = document.getElementById("viewport");
    var vp_width = "width=device-width; ";
    var vp_initial_scale = "initial-scale="+scale+"; ";
    var vp_maximum_scale  = "maximum-scale="+scale+"; ";
    var vp_minimum_scale = "minimum-scale="+scale+"; ";
    var vp_user_scalable = "user-scalable=0;";

    viewport.attributes.content.value =
        vp_width+
        vp_initial_scale+
        vp_minimum_scale+
        vp_maximum_scale+
        vp_user_scalable;
}

參考： RETINA DISPLAY AND WEB DEVELOPMENT

Hello PureMVC！

Tue, 29 Mar 2011 00:00:00 GMT

第一次聽到 PureMVC 的時候大概是兩年前，那時候就對這套 MVC Framework 很感興趣，不過當時對於它的架構是有看沒有懂，就一直拖到了現在。

最近因為工作需要用到的關係，所以又再次學習它，經過閱覽無數前輩分享的文章之後，終於初步了解它的運作模式了，因此分享這邊學習心得筆記。

什麼是 MVC ?

一個設計方法（Design pattern 也稱設計模式）。

想初步了解的朋友可以參考維基百科的說明。

網路也有許多相關文章，大略內容就是將程式開發架構分為 Model、View 和 Controller 三個部份的開發方式，建議可以閱讀深入淺出設計模式這本書。

什麼是 PureMVC ?

一個跨多語言的 MVC Framework，其中我們要用到的是 Actionscript 3.0 版本，這是他們的官方網站。

下圖是他的架構圖，除了 MVC 外，它也用到不少其他 design pattern，第一次看可能會霧煞煞，沒關係，我們下面慢慢介紹。

Facade 可以看做是 MVC 之間的共同溝通管道，可以減少程式之間的耦合。

Command 就是扮演 Controller 的角色，PureMVC 寫出來的程式通常都會是以傳送(send)通知(Notification)的方式在進行動作，而 Command 就是負責執行它收到的通知所需要做的事情。

Proxy 從字面上看就是 Model 的代理者，不管是 C 還是 V 要取得使用資料，都必須經過它，這樣的好處是增加後端資料的可抽換性。

Mediator 可以看做是統一視覺元件的介面，透過它更新或取得視覺元件的狀態。

OK，大致上說明了 PureMVC 的概念之後，我們開始撰寫第一個程式吧，我參考了邦邦的部落格-初探pureMVC這篇文章，淺而易懂，是一個簡單的搜尋小程式。

配置 PureMVC 環境 :

這裡我們使用 FlashDevelop 這套好用的免費軟體來開發，下載FlashDevelop 。

接下來到 PureMVC 的網站，下載 PureMVC 的 library 。

下載完可以看到 bin 資料夾裡面有個 swc 檔，待會要用的到它。

建立 Project :

安裝並開啟FlashDevelop，開啟新專案。

這裡我們選擇 AS3 Project 來開發。

專案建立完後的架構如下，之後新增的 as 檔都放在 src 資料夾下。

將剛剛下載的 swc 檔放到專案的 lib 資料夾底下。

然後右鍵加入 Library，這布記得要做唷，不然無法使用 PureMVC 的 API。

開始 Coding :

這個程式會有以下四種 Notification (通知) :

STARTUP — 程式啟動
INITED — 程式初始化結束
SEARCH — 搜尋資料
RESULT — 搜尋結果

還有三個視覺元件 :

searchTxt — 搜尋字串的輸入欄位
searchBtn — 送出搜尋字串的按鈕
resultTxt — 顯示搜尋結果的欄位

一開始我們先寫把 Model 的部分，這個 class 主要負責提供搜尋所需的資料，為了簡化學習，我們只回傳一字串 “ XXX Hello PureMVC! “。

DataProxy.as :

package puremvc.model
{
    import org.puremvc.as3.interfaces.IProxy;
    import org.puremvc.as3.patterns.proxy.Proxy;

    import puremvc.ApplicationFacade;

    /**
     * DataProxy
     *
     * 儲存資料的 Model
     */
    public class DataProxy extends Proxy implements IProxy
    {
        static public const PROXY_NAME:String = "DataProxy";

        public function DataProxy()
        {
            super(PROXY_NAME, "");
        }

        public function search(query:String):void {
            // 提供外部使用的搜尋 Method.
            // 此方法並未真正實作任何搜尋程式.
            // 暫時以 query + " Hello PureMVC!" 作為搜尋結果.

            var result:String = query + " Hello PureMVC!";

            var body:Object = { };
            body["result"] = result;

            // 將結果包裝成 body["result"] 後傳送 NOTIFICATION_RESULT 通知
            this.facade.sendNotification(ApplicationFacade.NOTIFICATION_RESULT, body);
        }

    }

}

再來我們寫 View 的部分，MainMediator 主要負責接收 INITED 跟 RESULT 這兩個通知。

INITED 代表程式初始化結束，當初始化結束的通知發出後，MainMediator 就會需要偵聽事件的視覺元件加入偵聽。

RESULT 代表搜尋結果，當這個通知發出後，MainMediator 會將搜尋結果顯示到 resultTxt 這個 TextField元件上。

MainMediator.as :

package puremvc.view
{
    import flash.events.MouseEvent;

    import org.puremvc.as3.interfaces.IMediator;
    import org.puremvc.as3.interfaces.INotification;
    import org.puremvc.as3.patterns.mediator.Mediator;

    import puremvc.ApplicationFacade;

    /**
     * MainMediator
     *
     * 主程式視覺介面
     */
    public class MainMediator extends Mediator implements IMediator
    {
        static private const MEDIATOR_NAME:String = "MainMediator";

        public function MainMediator(viewComponent:Object = null)
        {
            super(MEDIATOR_NAME, viewComponent);
        }

        override public function listNotificationInterests():Array {
            // 此 Mediator 關注哪幾個 NOTIFICATION
            return [
                ApplicationFacade.NOTIFICATION_INITED,
                ApplicationFacade.NOTIFICATION_RESULT
            ];
        }

        override public function handleNotification(notification:INotification):void {
            // 當各 NOTIFICATION 產生通知時的動作
            switch(notification.getName())
            {
                case ApplicationFacade.NOTIFICATION_INITED:
                    onInitedNotify(notification);
                    break;
                case ApplicationFacade.NOTIFICATION_RESULT:
                    onResultNotify(notification);
                    break;
            }
        }

        private function onInitedNotify(notification:INotification):void {
            // 當主程式初始化結束的動作
            setListener(true);
        }

        private function get app():Main {
            return Main(this.viewComponent);
        }

        private function onResultNotify(notification:INotification):void {
            // 將取得的 body["result"] 值顯示在 resultTxt 上
            app.resultTxt.text = notification.getBody()["result"];
        }

        private function setListener(boolean:Boolean = false):void {
            // 設定是否偵聽 searchBtn Click 事件
            if (boolean)
            {
                app.searchBtn.addEventListener(MouseEvent.CLICK, onSearchBtnClick);
            }else {
                app.searchBtn.removeEventListener(MouseEvent.CLICK, onSearchBtnClick);
            }
        }

        private function onSearchBtnClick(e:MouseEvent):void {
            // 將 searchTxt 的值包裝成 body["keyword"] 後發送 NOTIFICATION_SEARCH 的通知
            var body:Object = { };
            body["keyword"] = app.searchTxt.text;

            this.facade.sendNotification(ApplicationFacade.NOTIFICATION_SEARCH, body);
        }

    }

}

接下來我們開始寫需要用到的 Command，這裡我們先寫負責處理 SEARCH 通知的 SearchCommand。

SearchCommand.as :

package puremvc.controller
{
    import org.puremvc.as3.interfaces.ICommand;
    import org.puremvc.as3.interfaces.INotification;
    import org.puremvc.as3.patterns.command.SimpleCommand;

    import puremvc.model.DataProxy;

    /**
     * SearchCommand
     *
     * 接到搜尋通知後要做的事.
     */
    public class SearchCommand extends SimpleCommand implements ICommand
    {

        public function SearchCommand()
        {
            super();
        }

        override public function execute(notification:INotification):void {
            // 向 MainMediator 取得 body["keyword"] 對映的元件的值
            var query:String = notification.getBody()["keyword"];

            search(query);
        }

        private function search(query:String):void {
            // 將要搜尋的值傳給 DataProxy 提供的 search Method
            var dataProxy:DataProxy = DataProxy(this.facade.retrieveProxy(DataProxy.PROXY_NAME));
            dataProxy.search(query);
        }

    }

}

再來是程式啟動 STARTUP 的 StartupCommand。

StartupCommand.as :

package puremvc.controller
{
    import org.puremvc.as3.interfaces.ICommand;
    import org.puremvc.as3.interfaces.INotification;
    import org.puremvc.as3.patterns.command.SimpleCommand;

    import puremvc.ApplicationFacade;
    import puremvc.model.DataProxy;
    import puremvc.view.MainMediator;

    /**
     * StartupCommand
     *
     * 程式啟動時需要做的事情
     */
    public class StartupCommand extends SimpleCommand implements ICommand
    {

        public function StartupCommand()
        {
            super();
        }

        override public function execute(notification:INotification):void {
            // 註冊 Model DataProxy
            this.facade.registerProxy(new DataProxy());

            // 註冊 View MainMediator
            var app:Main = Main(notification.getBody());
            this.facade.registerMediator(new MainMediator(app));

            // 註冊接下來會用到的 Controller Command
            this.facade.registerCommand(ApplicationFacade.NOTIFICATION_SEARCH, SearchCommand);

            // 通知初始化結束
            this.facade.sendNotification(ApplicationFacade.NOTIFICATION_INITED);
        }

    }

}

快結束了! 再來把程式的核心，ApplicationFacade 給完成就差不多了。

ApplicationFacade.as :

package puremvc
{
    import org.puremvc.as3.interfaces.IFacade;
    import org.puremvc.as3.patterns.facade.Facade;

    import puremvc.controller.StartupCommand;

    /**
     * ApplicationFacade
     *
     * 所有程式之間唯一的溝通橋樑.
     * 使用到 Facade 和 Singleton 設計模式.
     */
    public class ApplicationFacade extends Facade implements IFacade
    {
        // 所有此程式會用到的列舉狀態
        // - NOTIFICATION_STARTUP 程式啟動
        // - NOTIFICATION_INITED  程式初始化結束
        // - NOTIFICATION_SEARCH  發出搜尋的請求
        // - NOTIFICATION_RESULT  產生結果的通知

        static public const NOTIFICATION_STARTUP:String = "NOTIFICATION_STARTUP";
        static public const NOTIFICATION_INITED:String = "NOTIFICATION_INITED";
        static public const NOTIFICATION_SEARCH:String = "NOTIFICATION_SEARCH";
        static public const NOTIFICATION_RESULT:String = "NOTIFICATION_RESULT";

        static public function getInstance():ApplicationFacade {
            if (instance == null) instance = new ApplicationFacade();
            return ApplicationFacade(instance);
        }

        override protected function initializeController():void {
            super.initializeController();

            // 當 ApplicationFacade 被第一次呼叫的時候
            // 會執行這個 initializeController()
            // 所以在這裡我們註冊 NOTIFICATION_STARTUP 這個啟動 Command

            this.registerCommand(NOTIFICATION_STARTUP, StartupCommand);
        }

        /**
         * startup
         *
         * 程式啟動.
         *
         * @param    app 主程式
         */
        public function startup(app:Main):void {
            this.sendNotification(NOTIFICATION_STARTUP, app);
        }
    }
}

最後，將用到的視覺元件加一加，然後寫上一行 ApplicationFacade.getInstance().startup(this) 就可以收工囉!!!

Main.as :

package
{
    import flash.display.SimpleButton;
    import flash.display.Sprite;
    import flash.text.TextField;
    import flash.text.TextFieldType;
    import flash.events.Event;

    import puremvc.ApplicationFacade;

    /**
     * Main
     *
     * 使用 PureMVC 來實作一個簡單的搜尋小程式.
     */
    public class Main extends Sprite
    {
        public function Main():void
        {
            if (stage) init();
            else addEventListener(Event.ADDED_TO_STAGE, init);
        }

        private function init(e:Event = null):void
        {
            removeEventListener(Event.ADDED_TO_STAGE, init);

            // entry point

            initComponents();

            // pureMVC 的進入點.
            // 使用唯一的 ApplicationFacade class 作為入口.
            // 之後所有的元件之間溝通都需要經過此 facade.
            ApplicationFacade.getInstance().startup(this);
        }

        public var searchTxt:TextField;
        public var searchBtn:SimpleButton;
        public var resultTxt:TextField;

        private function initComponents():void {
            // 初始化視覺元件(ViewCompoents)

            // searchTxt
            searchTxt = new TextField();
            searchTxt.type = TextFieldType.INPUT;
            searchTxt.border = true;
            searchTxt.x = 50;
            searchTxt.y = 50;
            searchTxt.width = 200;
            searchTxt.height = 20;
            this.addChild(searchTxt);

            // searchBtn
            var buttonStyle:Sprite = new Sprite();
            buttonStyle.graphics.beginFill(0xcccccc);
            buttonStyle.graphics.drawRect(0, 0, 100, 20);
            buttonStyle.graphics.endFill();

            var buttonTxt:TextField = new TextField();
            buttonTxt.text = "Search Button";
            buttonTxt.width = 100;
            buttonTxt.height = 20;
            buttonStyle.addChild(buttonTxt);

            searchBtn = new SimpleButton(buttonStyle, buttonStyle, buttonStyle, buttonStyle);
            searchBtn.x = 260;
            searchBtn.y = 50;
            this.addChild(searchBtn);

            // resultTxt
            resultTxt = new TextField();
            resultTxt.type = TextFieldType.DYNAMIC;
            resultTxt.border = true;
            resultTxt.x = 50;
            resultTxt.y = 80;
            resultTxt.width = 200;
            resultTxt.height = 200;
            this.addChild(resultTxt);

        }

    }

}

以上是我初步學習 PureMVC 後的心得，更進階一點的介紹可以參考官方的 Best Practice 或更多相關文章。

範例原始檔：

MyFirstPureMVC.rar

參考文章：

Develop Facebook Canvas Page with CodeIgniter

Fri, 11 Mar 2011 00:00:00 GMT

這篇文章是介紹如何使用 CodeIgniter 這個 PHP Framework 來初步架構出 MVC 的環境, 並且開發一個簡單的 Facebook Canvas Page。

什麼是 CodeIgniter 呢？

CodeIgniter 是開發 PHP 應用程式的 framework 及工具組。

提供簡易的介面和邏輯結構來使用豐富的函式庫，其目的是讓你可以加快開發速度。

使用 CodeIgniter 只需要寫少少的程式，讓創造力可專注在專案開發。

CodeIgniter
CodeIgniter 台灣
CodeIgniter 中文使用手冊 (英) (中)

什麼是 MVC 呢？

簡而言之是一個程式設計模式（Design pattern），詳細介紹推薦參考這篇：透視 WebMVC

什麼是 Facebook Canvas page ？

簡單來說，就是 Facebook 的應用程式, 像開心農場之類直接嵌入在 Facebook 內的網頁，Facebook 的 API 很強大，可以作手機應用，網站應用等等，這篇我們就只討論 Canvas page 這個範圍，有興趣的可以到開發者頁面研究看看。

進入本篇重點，開發流程我把它分成三個步驟，如下：

下載 CodeIgniter 2.0
建立 Facebook 應用程式
開始編寫程式碼

1.下載 CodeIgniter 2.0

這裡我們使用 CodeIgniter 2.0.0 的版本來實作。

前往 CodeIgniter 網站下載 CodeIgniter 2.0

下載完可看到 zip 檔，解壓縮至你的網頁目錄吧

CodeIgniter 的目錄內容大致如下

開啟瀏覽器測試看看，成功的話會如下圖所示

2. 建立 Facebook 應用程式

前往 Facebook 開發者頁面

點選上方我的應用程式連結進入

然後再點選建立新的應用程式按鈕

設定應用程式的名稱

設定相關介紹，大致上都可以先不用填

我們要開發 Facebook Canvas，所以選 Facebook 集成這個選項

app id 待會寫程式時會用到
canvas name 也是，這是你應用程式的網址
canvas url 則是填寫實際的網頁位址
https 這部分我還沒測試過, 如果程式要在 https 的 Facebook 環境底下運作的話，則需要填寫

大致上的配置都完成了，儲存後前往你的 canvas page 看看結果如何

沒問題的話，可以在 Facebook 裡面成功執行剛剛的 CodeIgniter 頁面

3. 開始編寫程式碼

OK，CodeIgniter 跟 Facebook 的環境都配置的差不多了，接下來進入 coding 的階段，我們將編寫下面這三個文件：

welcome controller — 負責與 facebook model 溝通，處理使用者認證的部分，並把資料傳給 welcome view 作前端顯示
welcome view — 將 welcome controller 傳過來的資料作顯示
facebook model — 實作 facebook 認證，取得使用者資料的部分

welcome controller：

開啟（application\controllers\welcome.php），在 index() 這個 function 內編寫以下程式：

function index()
{
    // 載入 Facebook Model
    $this->load->model('Facebook_model', 'facebook');

    // 判斷使用者是否認證此應用程式
    if( ! $this->facebook->is_auth())
    {
        // 還未認證的情況下:
        //
        // 需要將使用者導向 Facebook 的認證頁面,
        // 並提供認證所需相關資料.
        //
        // $app_id Facebook    應用程式 ID
        //
        // $canvas_name    Canvas Page 填寫的名稱
        //                 ex: http://apps.facebook.com/XXX
        //
        // $permission    需要使用者同意的權限資料
        //                ex: email, user_birthday
        // ref url:
        // http://developers.facebook.com/docs/authentication/permissions/

        $app_id = 'YOUR APP ID';
        $canvas_name = 'YOUR CANVAS NAME';
        $permission = 'email,user_birthday';

        $this->facebook->do_auth($app_id, $canvas_name, $permission);
    }
    else
    {
        // 已認證的情況下:
        //
        // 向 Facebook model 取得使用者的資料,
        // 然後傳給 welcome_message View 作顯示.

        $me = $this->facebook->get_me();

        $data = array(
            'me_id' => $me->id,
            'me_name' => $me->name,
            'me_email' => $me->email,
            'me_birthday' => $me->birthday
        );

        $this->load->view('welcome_message', $data);
    }
}

welcome view：

開啟（application\views\welcome_message.php），修改內容如下：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Hello Canvas</title>
</head>
<body>

<h1>Hello Canvas</h1>

<p>ID: <?php echo $me_id; ?></p>
<p>Name: <?php echo $me_name; ?></p>
<p>Email: <?php echo $me_email; ?></p>
<p>Birthday: <?php echo $me_birthday; ?></p>

</body>
</html>

facebook model：

在（application\models\）底下新增 facebook_model.php，內容如下：

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
/**
 * Facebook Model
 *
 */
class Facebook_model extends CI_Model {

    var $_cookie;

    function __construct()
    {
        parent::__construct();
    }

    /**
     * 判斷頁面是否認證
     *
     * @access  public
     * @return  boolean 判斷是否認證,若頁面已認證則回傳TRUE, 反之FALSE
     */
    function is_auth() {
        $signed_request = $_REQUEST["signed_request"];
        list($encoded_sig, $payload) = explode('.', $signed_request, 2);

        $this->_cookie = json_decode(base64_decode(strtr($payload, '-_', '+/')), TRUE);

        return isset($this->_cookie["user_id"]);
    }

    /**
     * 執行認證的動作
     *
     * @access  public
     * @param   String  $app_id         應用程式 ID
     * @param   String  $canvase_name   Canvas Page Name
     * @param   String  $permission     使用者提供的資料
     * @return  void
     */
    function do_auth($app_id, $canvas_name, $permission = '') {
        $canvas_page = 'http://apps.facebook.com/' . $canvas_name . '/';
        $auth_url = "http://www.facebook.com/dialog/oauth?client_id=" . $app_id . "&redirect_uri=" . urlencode($canvas_page) . "&scope=" . $permission;

        echo("<script> top.location.href='" . $auth_url . "'</script>");
    }

    /**
     * 取得使用者資料
     *
     * @access  public
     * @return  Object
     */
    function get_me() {
        $access_token = $this->_cookie['oauth_token'];

        $me = json_decode(file_get_contents('https://graph.facebook.com/me?access_token=' . $access_token));

        return $me;
    }
}

/* End of file facebook_model.php */
/* Location: ./application/models/facebook_model.php */

初步的程式碼都打完了, 接著我們再一次連到應用程式看看，沒問題的話，初次會導向 Facebook 授權請求的認證頁面，如下圖，並且會出現需要授權的 permission

點選同意之後，沒意外的話，我們的第一個 Facebook canvas page 就出現囉！！！

範例程式下載 : Fb_with_CI.rar

IE6 Upgrade Notice

Sun, 23 Aug 2009 00:00:00 GMT

有過網頁設計經驗的人，無論是部落格樣版或是其他頁面，都一定有個共同的痛，就是 IE6 這傢伙對 CSS 的呈現總是跟別人不同，偏偏它的市占率一直是最高的。

通常解決這個問題的方法有兩種，一種是修改 CSS 直到版面看起來正常，另一種則是直接放棄，在網頁開頭就提醒使用者升級瀏覽器。

我們今天要介紹的就是最後一種方法，為什麼我們要放棄 IE6 呢?

因為網頁技術不斷的進步，不單單是 CSS 的問題，IE6 本身還有其他原因，它已經不適合這個世代了，加上最近許多知名網站也紛紛開始提倡升級 IE6，例如 You Tube、Twitter 和 Facebook 等，IE6 你真的玩完了，拜託還在使用 IE6 的人，請你快點更換瀏覽器吧！！（小聲:換 Firefox Chrome 吧）

知名影音分享網站 YouTube 將停止對 IE6 的支援。

連最近在台灣火熱的 Facebook 都要封殺 IE6 了，還在使用它的人，麻煩你快點更新吧！！！

剛好之前看到一篇重灌狂人寫的文章 “ 在網站加入警告標語，建議 IE 6.0 的使用者升級”，裡面介紹了一些 IE 瀏覽器版本判斷的語法，可以分辨出使用者目前的 IE 瀏覽器是哪一個版本。

例如我要讓 IE6 以下的使用者看見提示的話：

<!--[if lte IE 6]>
  這裡的內容只有IE6以下的使用者才看的見。
<![endif]-->

只要將提示內容放在  之中，就可以讓還在用 IE6 的人，看到你要傳達給他的訊息了。

語法說明：

<!--[if IE]>
  使用 IE 瀏覽器全部版本的人都看得見這裡的內容。
<![endif]-->
<!--[if IE 6]>
  只有 IE6 的使用者才能看見這裡的內容
<![endif]-->
<!--[if lt IE 6]>
  這裡是小於 IE6 的版本使用者才能看到，不含 IE6。
<![endif]-->
<!--[if lte IE 6]>
  IE6 以下版本的使用者能看見內容，包含 IE6。
<![endif]-->
<!--[if gt IE 6]>
  這樣 IE6 以上版本的使用者會看見內容，但不包含 IE6。
<![endif]-->
<!--[if gte IE 6]>
  IE6 以上版本的使用者能看見內容，包含 IE6。
<![endif]-->

上面的版本編號也可以換，如果把 [if lte IE 6] 換成 [if lte IE 7] 的話，就是 IE7 以下使用者能看見內容。

**gt：**greater than（版本大於）
**lt：**less than（版本小於）
**gte：**greater than or equal（版本大於等於）
**lte：**less than or equal（版本小於等於）

最後分享一個自己寫的範本，加了 jquery 的 sideup 效果，有興趣的可以下載回去參考看看。

演示範例：

IE6 Notice sample page

範本下載：

IE6NoticeTemplate.rar

參考資料：

Factory pattern 工廠模式

Thu, 20 Aug 2009 00:00:00 GMT

距離上一篇 Strategy pattern 策略模式已經兩個多月了，一直拖到現在才生出這篇文章…orz。

其實這篇工廠模式應該要當作第一篇 Design pattern 的文章會比較好，因為這個模式很容易懂，但是工廠模式中又細分出一些其他類似的模式，例如抽象工廠模式，所以我把一些相關的資料都讀了一遍後，分三篇作介紹。

工廠模式最主要的精神就是將 new Class 這個動作另外封裝成一個 Factory Class，這個 Factory Class 專門負責實體化這些類別。

特地這樣做有什麼好處呢？

舉個例子，假如我們現在有兩個繼承 Product 的類別，它們擁有共同的方法 Operation()

一般來講，我們如果要實體化 ProductA 或 ProductB 的話，會這樣寫：

namespace FactoryPattern
{
  class Program
  {
    static void Main(string[] args)
    {
      Product product = new ProductA();

      product.Operation();
    }
  }
}

這樣做有什麼缺點呢？

如果我 product 型別要換成 ProductB 的話，就需要把第 7 行的 new ProductA() 改成 new ProductB() ，若是繼承 Product 的類別一多，以後程式碼的維護上會很麻煩。

簡單工廠模式 Simple Factory Pattern （又稱靜態工廠模式 Static Factory Pattern ）：

按照上圖，將擁有共同介面類別的實體化動作封裝在 Factory 內，程式就可以在執行時動態決定要實體化哪個類別了。

Factory class：

namespace SimpleFactoryPattern
{
  public class Factory
  {
    public Product CreateProduct(string name)
    {
      switch (name)
      {
        case "ProductA":
          return new ProductA();
        case "ProductB":
          return new ProductB();
        default:
          return null;
      }
    }
  }
}

Client：

using System;

namespace SimpleFactoryPattern
{
  class Program
  {
    static void Main(string[] args)
    {
      // productName可以動態決定要實體化的類別
      string productName = "ProductA";

      Factory productFactory = new Factory();

      Product product = productFactory.CreateProduct(productName);

      product.Operation();
    }
  }
}

到這裡可以看看使用 Factory 後，和使用之前的程式碼做比較，最大的差別就是現在可以靠變數來決定要實體化的類別了，若是需要改成 ProductB 的話，只需要將 productName 的值改成 “ProductB” 就行了。

如果覺得上面的 Factory productFactory = new Factory(); 這行有點礙眼的話，還可以將程式碼更簡單話一點，就是把 Factory class 的 CreateProduct() 方法改成 static：

public static Product CreateProduct(string name)

這樣就可以直接跳過 new Factory() 的步驟，直接呼叫 CreateProduct() 方法：

static void Main(string[] args)
{
  string productName = "ProductA";

  Product product = Factory.CreateProduct(productName);

  product.Operation();
}

使用簡單工廠模式雖然方便，但也是有缺點的。

如果每次新增一個 Product 子類別後，都必須修改 Factory class 中 CreateProduct() 的 switch 判斷式的話，這樣做不符合物件導向設計的 Open-Closeed Principle(開放-封閉原則) 精神。

什麼是開放-封閉原則呢?

簡單說就是程式容易擴充新功能，但是不用修改原始碼的意思。

如果因為要擴充 ProductC class 進來，而修改了 Factory class 的話，這樣的做法並不是很好，所以比較正統的工廠模式有另一種寫法，就是接著下一篇要介紹的工廠方法模式。

要解決簡單工廠模式的問題，工廠方法模式的做法是將 Factory 類別抽象化，讓每個 Product 子類別都有屬於自己的工廠類別，如上圖所示。

Factory interface：

namespace FactoryMethodPattern
{
  public interface Factory
  {
    Product CreateProduct();
  }
}

ProductFactoryA class：

namespace FactoryMethodPattern
{
  public class ProductFactoryA : Factory
  {
    public Product CreateProduct()
    {
      return new ProductA();
    }
  }
}

ProductFactoryB class：

namespace FactoryMethodPattern
{
  public class ProductFactoryB : Factory
  {
    public Product CreateProduct()
    {
      return new ProductB();
    }
  }
}

Client：

using System;

namespace FactoryMethodPattern
{
  class Program
  {
    static void Main(string[] args)
    {
      // ProductA
      Factory productFactoryA = new ProductFactoryA();
      Product productA = productFactoryA.CreateProduct();
      productA.Operation();

      // ProductB
      Factory productFactoryB = new ProductFactoryB();
      Product productB = productFactoryB.CreateProduct();
      productB.Operation();
    }
  }
}

這樣就解決簡單工廠的擴充問題了，如果需要增加 ProductC 的話，只需要加入繼承 Product 的ProductC class 和繼承 Factory 的 ProductFactoryC class 就可以了，不需要動到其他程式碼。

最後要介紹的是抽象工廠模式，這個模式其實跟上面的工廠方法是差不多的，只是增加了第二組Product的概念，我們來看看它的定義：

抽象工廠模式，提供一個建立一系列相關物件的介面，而無需指定它們具體的類別。

從上圖來看，我們有兩組產品，Product1 和 Product2，可以把它們想像成 Office 的 Word 和 Excel，這兩組產品如果要跨平台到 Mac 的話，就會分支出 Windows 版和 Mac 版的，但是軟體做的事情是一樣的，所以它們繼承了共同的方法，如下圖：

看完上圖後，可以看出每個產品都有 Windows 和 Mac 兩種系列，所以我們可以為他們寫兩個工廠類別，一個專門負責生產 Windows，一個專門負責生產 Mac 的產品，來看看程式碼：

Factory interface：

namespace AbstractFactoryPattern
{
  public interface Factory
  {
    // 想像成CreateWindowsProduct()
    Product1 CreateProduct1();

    // 想像成CreateMacProduct()
    Product2 CreateProduct2();
  }
}

ProductFactoryA class：

namespace AbstractFactoryPattern
{
  // 想像成WordFactory
  public class ProductFactoryA : Factory
  {
    public Product1 CreateProduct1()
    {
      // 生產Windows的Word
      return new Product1A();
    }

    public Product2 CreateProduct2()
    {
      // 生產Mac的Word
      return new Product2A();
    }
  }
}

ProductFactoryB class：

namespace AbstractFactoryPattern
{
  // 想像成ExcelFactory
  public class ProductFactoryB : Factory
  {
    public Product1 CreateProduct1()
    {
      // 生產Windows的Excel
      return new Product1B();
    }

    public Product2 CreateProduct2()
    {
      // 生產Mac的Excel
      return new Product2B();
    }
  }
}

Client：

namespace AbstractFactoryPattern
{
  class Program
  {
    static void Main(string[] args)
    {
      // Word工廠
      Factory productFactoryA = new ProductFactoryA();
      // 製造Windows和Mac版本的Word
      Product1 product1A = productFactoryA.CreateProduct1();
      Product2 product2A = productFactoryA.CreateProduct2();
      // 跑兩種版本的Word
      product1A.Operation();
      product2A.Operation();

      // Excel工廠
      Factory productFactoryB = new ProductFactoryB();
      // 製造Windows和Mac版本的Excel
      Product1 product1B = productFactoryB.CreateProduct1();
      Product2 product2B = productFactoryB.CreateProduct2();
      // 跑兩種版本的Excel
      product2B.Operation();
      product1B.Operation();
      }
  }
}

這樣就完成抽象工廠模式了，將 Factory 抽象化後， Client 端就能利用多型的方法實體化 Product，而不需要知道具體的類別就能操作它，這就是抽象工廠的優點。

到這邊其實已經把工廠模式都介紹完了，不過其實上面的抽象工廠還是有不完美的地方，例如我們現在加入了一個新的 Product 系列 ProductC（可以想像成 Linux 版本的 Office），那麼我們除了要寫 Product1C 跟 Product2C 這些基本的類別外，還要再為它們新增一個 ProductFactoryC 的類別，讓人覺得有一些麻煩。

這邊要介紹大話設計模式一書中作者提供的一個技巧，可以將工廠模式再修改的更加完美。

看到上圖後，可以發現我們將 Factory 的抽象化拿掉了，變回最初的簡單工廠模式，這時候的 Factory 會變成這樣：

Factory class：

using System;

namespace SimpleAbstractFactoryPattern
{
  public class Factory
  {
    public static Product1 CreateProduct1(string name)
    {
      switch (name)
      {
        case "Product1A":
          return new Product1A();
        case "Product1B":
          return new Product1B();
        default:
          throw new Exception();
      }
    }

    public static Product2 CreateProduct2(string name)
    {
      switch (name)
      {
        case "Product2A":
          return new Product2A();
        case "Product2B":
          return new Product2B();
        default:
          throw new Exception();
      }
    }
  }
}

這樣寫的話，之前才提到的開放-封閉原則的缺點不是又出現了嗎？

如果增加了一個新的 ProductC 類別的話，就需要在 Factory 裡面增加新的 switch case 分支條件，不容易擴充的問題就出現了。

這裡要介紹 C# 跟 JAVA 都有提供的一個機制，Reflection(反射)，它可以直接依照 class 的名稱來實體化類別，我們直接來看看用Reflection機制修改後的 Factory 程式碼吧：

Factory class：

using System;
using System.Reflection;

namespace SimpleAbstractFactoryPattern
{
  public class Factory
  {
    // 專案的namespace
    private static readonly string AssemblyName = "SimpleAbstractFactoryPattern";

    public static Product1 CreateProduct1(string name)
    {
      // 如果傳進來的name是"Product1A"
      // 那className就等於SimpleAbstractFactoryPattern.Product1A
      string className = AssemblyName + "." + name;

      // 這裡就是Reflection，直接依照className實體化具體類別
      return (IProduct1)Assembly.Load(AssemblyName).CreateInstance(className);
    }

    public static Product2 CreateProduct2(string name)
    {
      string className = AssemblyName + "." + name;

      return (IProduct2)Assembly.Load(AssemblyName).CreateInstance(className);
    }
  }
}

Client：

namespace SimpleAbstractFactoryPattern
{
  class Program
  {
    static void Main(string[] args)
    {
      // 生產產品A

      Product1 product1A = Factory.CreateProduct1("Product1A");
      Product2 product2A = Factory.CreateProduct2("Product2A");

      product1A.Operation();
      product2A.Operation();

      // 生產產品B

      Product1 product1B = Factory.CreateProduct1("Product1B");
      Product2 product2B = Factory.CreateProduct2("Product2B");

      product2B.Operation();
      product1B.Operation();
    }
  }
}

看到了嗎!?這樣就算加入了其他 Product 子類別後，也不需要修改 Factory 的程式碼，只要在 CreateProduct() 方法內傳入要實體化的類別名稱就可以了，相當方便吧。

範例檔案：

FactoryPatternSample.rar

參考資料：

swfobject — 網頁輕鬆嵌入 Flash

Thu, 23 Jul 2009 00:00:00 GMT

Flash 在網頁上的應用已經越來越普遍了，未來一樣占有一席之位，但是從以前到現在，對於發佈 Flash 到網頁上常常碰到一些不必要的問題，例如 XP SP2 更新後，IE 瀏覽器上方會出現檔掉的訊息，或是 Flash 外框出現虛線，需要滑鼠點一下才能開始動作等…，而且使用者並未安裝 Flash Player 的情況下或版本太低都會無法順利的瀏覽。

最近剛好看到一個不錯的東西，就是這次要介紹的 swfobject，一般我們要嵌入 swf 到 HTML 時，通常會寫的語法如下：

<object id="FlashID" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="300" height="120">
  <param name="movie" value="test.swf" />
  <param name="quality" value="high" />
  <param name="wmode" value="opaque" />
  <param name="swfversion" value="6.0.65.0" />
</object>

上面的程式碼使用到 <object> 標籤，早一點的甚至還要再寫 <embed> 才能動作，因為 IE 跟其他瀏覽器的種種原因，使得這種寫法不但又臭又長，也不符合標準。

那使用 swfobject 有什麼好處呢？我們繼續看下去吧。

首先我們得先去 swfobject 的網頁 http://code.google.com/p/swfobject/，然後下載目前的最新版本 swfobject_2_2.zip 。

下載解壓縮後可以看到以下檔案：

swfobject
├ src (原始碼資料夾)
│  ├ expressInstall.as (flash player版本升級原始碼)
│  ├ expressInstall.fla (flash player版本升級原始碼)
│  └ swfobject.js (swfobject javascript)
│
├ expressInstall.swf (flash player版本升級程式)
├ index.html (HTML範例檔)
├ index_dynamic.html (HTML範例檔)
├ swfobject.js (swfobject javascript)
└ test.swf (測試用swf檔)

上面灰色的檔案是比較不重要的範例檔，我們只需要 swfobject.js 跟 expressInstall.swf 就可以了。

在這裡先解釋一下，expressInstall.swf 是用來幫助使用者升級 flash player 用的 swf 檔，如果你發佈了一個版本為 10 的 swf 到網頁，而使用者的瀏覽器版本只到 9 或更低，網頁就會自動載入 expressInstall.swf 協助使用者升級 player 的版本。

下面我們開始使用 swfobject，先建立一個資料夾，暫時命名為 MySwfobject，然後在資料夾裡在建立一個 js 資料夾，我們把 swfobject.js 複製到 js 資料夾內，然後將 expressInstall.swf 複製到 MySwfobject 資料夾內，再來我們需要一個測試用的 flash，就把剛剛下載的 test.swf 一樣複製到 MySwfobject 資料夾內，最後建立一個空白的 HTML 檔 index.html，程式碼如下：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>MySwfobject</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  </head>
  <body>
  </body>
</html>

這時我們的目錄應該如下的結構：

MySwfobject
├ js
│ └swfobject.js
│
├ expressInstall.swf
├ index.html
└ test.swf

我們開始把 test.swf 嵌入到 index.html，先在 <head> 標籤內導入 swfobject.js：

<script src="js/swfobject.js" type="text/javascript"></script>
然後在底下加上這幾行javascript:
<script type="text/javascript">
  swfobject.embedSWF("test.swf", "mySwfobjectDiv", "300", "120", "9.0.0", "expressInstall.swf");
</script>

最後在 <body> 內加入 id="mySwfobjectDiv" 的 <div> 標籤：

<div id="mySwfobjectDiv"></div>

這時候用你的瀏覽器開啟 index.html 就會發現 test.swf 成功被嵌入了。

大家可以發現程式碼非常的簡短，而且不需要一堆 <object><embed> 標籤，只需要一個 <div> 就可以輕鬆嵌入 Flash，其中的核心就是 swfobject.embedSWF("test.swf", "mySwfobjectDiv", "300", "120", "9.0.0", "expressInstall.swf"); 這行，這裡我們介紹一下 swfobject.embedSWF 的幾個參數：

swfobject.embedSWF(swfUrl, id, width, height, version, expressInstallSwfurl, flashvars, params, attributes, callbackFn)

swfUrl 要嵌入的 swf 檔的位置（例如在這裡我們是 test.swf）
id 要嵌入在哪的 HTML 標籤 id（在這裡我們是嵌入在 <div id="mySwfobjectDiv">）
width Flash 的寬
height Flash 的高
version Flash Player 的版本（可直接輸入整數 ex: 9 or 10
expressInstallSwfurl expressInstall.swf 的位置
flashvars 要傳給 Flash 的變數
params Flash 的參數 ex: menu,wmode,quality 等…
attributes Flash 本身的一些屬性 ex: id,name…
callbackFn 要 callback 給 javascript 的 function

最後這裡附上加了 flashvars, params 跟 attributes 的 index.html 程式碼：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>MySwfobject</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <script src="js/swfobject.js" type="text/javascript"></script>
    <script type="text/javascript">
      var flashvars = {};
      var params = {
        menu: "false"
      };
      var attributes = {
        id:"MySwfobject"
      };
      swfobject.embedSWF("test.swf", "mySwfobjectDiv", "300", "120", "9.0.0", "expressInstall.swf", flashvars, params, attributes);
    </script>
  </head>
  <body>
    <div id="mySwfobjectDiv">
      <a href="http://www.adobe.com/go/getflashplayer">請安裝Flash Player</a>
    </div>
  </body>
</html>

我們新增了關閉 player menu 的參數給 swfobject，然後將 id 命名為 MySwfobject，並且在 mySwfobjectDiv 的 div 標籤內加入一個 Flash Plyer 的安裝連結，如果使用者的瀏覽器沒有安裝 Flash Player，swfobject 就不會將 test.swf 嵌入到 mySwfobjectDiv，而是直接顯示這行連結通知使用者安裝。

更多進階的使用文件可以參考 swfobject 的 documentation 。

範例程式：

SwfobjectSample.rar

參考資料：

Visual Studio Code Snippets

Thu, 16 Jul 2009 00:00:00 GMT

最近在看聖殿祭司寫的 ASP.NET 3.5 專家技術手冊，上面提到 Visual Studio 2005 之後，提供一個很不錯的功能叫做 Code Snippets（程式碼片段），這是一個可以快速產生常用程式碼的好東西。

使用 Code Snippets 的好處是當我們每次要打一些常用的程式碼語法時，例如 if、do while、for 等等…就不必自己打一遍了，一方面平常輸入這些老是反覆再寫的程式碼時，效率不佳，而且另一方面有時候還會發生打錯或是想不起來怎麼寫的情況。

但是 C# 語言內建的程式碼片段很少，而且都是一些無關痛癢的基本語法，所以網路上有很多人將一些常用的 C# 程式碼片段寫成 VS 的擴充套件提供大家下載：

微軟 http://msdn.microsoft.com/en-us/vs2005/aa718338.aspx* (英文)* http://msdn.microsoft.com/zh-tw/vs2005/aa718338.aspx* (繁體中文)*

CodePlex http://www.codeplex.com/site/search?projectSearchText=Snippet

gotCODESNIPPETS.Net http://gotcodesnippets.com/default.aspx

這邊我用微軟提供的程式碼片段作範例，首先要先去 MSDN 網站下載。

下載完成後點擊 Code_Snippets.msi 進入安裝，安裝路徑為「Microsoft Visual Studio位置\VC#\Snippets\1033\自訂命名」，例如「C:\Program Files\Microsoft Visual Studio 9.0\VC#\Snippets\1033\C# Snippets」。

接下來開啟 VS2005 或 VS2008，點選工具 -> 程式碼片段管理員。

開啟程式碼片段管理員後，點擊加入 -> 選擇剛剛安裝的目錄「C:\Program Files\Microsoft Visual Studio 9.0\VC#\Snippets\1033\C# Snippets」-> 確定，完成後就可以看到 C# Snippets 目錄被加入到清單內了。

成功加入後我們馬上來試試，在要加入程式碼片段的地方右鍵 -> 插入程式碼片段 -> C# Snippets -> database -> Create a local SQL Connection to SQL Server(or Express)，然後在下一行繼續插入程式碼片段 -> C# Snippets -> database -> Create a Parameterized SELECT Command，這樣就完成一個資料庫的連接跟查詢功能，程式碼都幫我們產生好了，只需要改改變數或字串就可以了，非常方便吧!!!

除了下載安裝別人提供的套件外，當然也可以寫一份屬於個人的程式碼片段擴充套件，畢竟平常在寫哪些程式碼，只有自己是最清楚的，可以去微軟 Snippet Editor或 Snippy — Visual Studio code Snippet Editor 下載編輯工具，詳細的介紹各位可以參考聖殿祭司的ASP.NET 3.5 專家技術手冊I-使用C# 這本書，內容適合中高階經驗的人，值得一看!!!

AS3 如何複製 DisplayObject

Tue, 30 Jun 2009 00:00:00 GMT

最近正在寫一個 FLASH 的相片大頭貼截取程式，碰到了一個複製 MovieClip 的問題，AS3 已經沒有 AS2 的 duplicateMovie() 方法可以用，所以我找了一些解決方法分享上來。

第一種方式是比較好的解決方法，是 PTT 的 CJCAT 大提供的，可以直接複製一個相同的 Class。

假如場景上面有一個 clip_mc，它的 class 是 MyClip，在不使用 *new MyClip()* 的前提下，以下的 code 可以生出一個新的 MyClip 物件。

// 先抓到MyClip的constructor
var mcClass:Class = Object(clip_mc).constructor;

// 這樣就生出一個新的MyClip物件了
var clip2_mc:DisplayObject = new mcClass();

// 加入到舞台後就成功了
this.addChild(clip2_mc);

不過上面這個方法我試不出來，不知道是不是哪裡出錯了，所以又找了第二種方法， Copying a Sprite using BitmapData ，這個方法可以將 Sprite 的畫面複製到另一個 DisplayObject 上，因為我只是需要複製一個靜態的圖，所以可以不需要使用第一種複製 Class 的方式。

// 先實體一個clip_mc大小的BitmapData
var myBitmapData:BitmapData = new BitmapData(clip_mc.width, clip_mc.height);
// 然後繪製一個相同的clip_mc
myBitmapData.draw(clip_mc);

// 實體一個複製的Bitmap
var clip2_mc:Bitmap = new Bitmap(myBitmapData);

// 加入到舞台後就成功了
this.addChild(clip2_mc);

參考資料：

XNA Simple Animation

Fri, 12 Jun 2009 00:00:00 GMT

因為我的大學專題是寫一款四人網路連線的格鬥遊戲，所以對 XNA 這套微軟提供的遊戲開發平台有點研究，之前在痞客邦寫網誌的時候有寫過幾篇這個作品的開發情況，後來因為實在太忙了所以沒有繼續介紹下去，現在這個遊戲已經在去年完成了，也得到不錯的成績，有機會我會 PO 上來分享一些製作心得。

在網誌搬到 Blogger 之後一直沒有機會寫一些跟 XNA 有關的文章，我打算介紹一些 XNA Creators Club 教學範例中所使用到的開發技術，國內介紹 XNA 的文章不多，有興趣用 XNA 開發遊戲的人，推薦可以到點部落去看一些不錯的文章。

這一篇我想先介紹 XNA 如何使用 Model、ModelBone 和 ModelMesh 等技術去載入一個 3D 模型，然後控制一些簡單的 3D 動畫。

首先必須先準備一個 3D 模型，XNA 預設的類型有 .x 跟 .fbx 兩種模型檔，這裡我們先用微軟提供的坦克車模型（ part1）（ part2 ）來作示範。

一開始先建立一個 XNA 的專案。

將模型檔加入到 Content 資料夾內。

新增一個 Tank.cs ：

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Graphics;

namespace SimpleAnimationSample
{
  /// <summary>
  /// 能讓零件動作的坦克車模型類別
  /// </summary>
  public class Tank
  {
    /// <summary>
    /// 坦克車模型
    /// </summary>
    private Model tankModel;

    /// <summary>
    /// 坦克所有組件的平移矩陣
    /// </summary>
    private Matrix[] boneTransforms;

    /// <summary>
    /// 載入坦克車資源
    /// </summary>
    public void Load(ContentManager content)
    {
      // 從ContentManager載入坦克車模型.
      this.tankModel = content.Load<Model>("tank");

      // 配置所有組件的平移矩陣
      this.boneTransforms = new Matrix[this.tankModel.Bones.Count];
    }
    /// <summary>
    /// 坦克車的繪圖機制
    /// </summary>
    /// <param name="world">世界矩陣</param>
    /// <param name="view">觀察矩陣</param>
    /// <param name="projection">投影矩陣</param>
    public void Draw(Matrix world, Matrix view, Matrix projection)
    {
      // 設定坦克車最上層的平移矩陣為世界矩陣
      this.tankModel.Root.Transform = world;

      // 更新所有組件的平移矩陣
      this.tankModel.CopyAbsoluteBoneTransformsTo(this.boneTransforms);

      // 繪製模型
      foreach (ModelMesh mesh in this.tankModel.Meshes)
      {
        foreach (BasicEffect effect in mesh.Effects)
        {
          effect.World = this.boneTransforms[mesh.ParentBone.Index];
          effect.View = view;
          effect.Projection = projection;

          effect.EnableDefaultLighting();
        }

        mesh.Draw();
      }
    }
  }
}

修改遊戲主程式 Game1.cs（這裡我命名為 SimpleAnimation.cs ）：

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;

namespace SimpleAnimationSample
{
  /// <summary>
  /// 控制坦克車模型動畫的範例程式
  /// </summary>
  public class SimpleAnimation : Microsoft.Xna.Framework.Game
  {
    private GraphicsDeviceManager graphics;

    private Tank tank;
    public SimpleAnimation()
    {
      this.graphics = new GraphicsDeviceManager(this);

      this.graphics.PreferredBackBufferWidth = 600;
      this.graphics.PreferredBackBufferHeight = 450;

      this.Content.RootDirectory = "Content";
    }

    /// <summary>
    /// 初始化遊戲內容
    /// </summary>
    protected override void Initialize()
    {
      this.tank = new Tank();

      base.Initialize();
    }

    /// <summary>
    /// 載入遊戲資源
    /// </summary>
    protected override void LoadContent()
    {
      this.tank.Load(this.Content);
    }

    /// <summary>
    /// 遊戲繪圖更新
    /// </summary>
    /// <param name="gameTime">上一次繪圖後經過的時間</param>
    protected override void Draw(GameTime gameTime)
    {
      this.GraphicsDevice.Clear(Color.CornflowerBlue);

      // 視窗畫面
      Viewport viewport = this.GraphicsDevice.Viewport;

      // 畫面長寬比
      float aspectRatio = (float)viewport.Width / (float)viewport.Height;

      // 世界矩陣(縮放矩陣, 旋轉矩陣, 平移矩陣)
      Matrix world = Matrix.CreateScale(1.0f) * Matrix.CreateRotationY(MathHelper.PiOver4) * Matrix.CreateTranslation(Vector3.Zero);

      // 觀察矩陣(攝影機座標, 攝影機焦點座標, 攝影機上方的向量)
      Matrix view = Matrix.CreateLookAt(new Vector3(1000, 600, 0), new Vector3(0, 100, 0), Vector3.Up);

      // 投影矩陣(畫面視角呈現弧度, 畫面長寬比, 近景值, 遠景值)
      Matrix projection = Matrix.CreatePerspectiveFieldOfView(MathHelper.PiOver4, aspectRatio, 10, 10000);

      this.tank.Draw(world, view, projection);

      base.Draw(gameTime);
    }
  }
}

上面我們完成了基本的坦克車模型載入，接下來要讓它的每個組件都能動作。

如果要讓模型內的組件獨立動作的話，會需要用到 ModelBone 這個類別，這裡我們先示範讓坦克車的左前輪轉動。

要讓左前輪動就必須知道他在模型內的 Mesh 命名，如果不知道當初建模時的命名，可以照下圖的步驟找出左前輪的名稱。

找到左前輪的命名 "l_front_wheel_geo" 後，就可以開始用程式去控制它了，修改 Tank.cs ：

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Graphics;

namespace SimpleAnimationSample
{
  /// <summary>
  /// 能讓零件動作的坦克車模型類別
  /// </summary>
  public class Tank
  {
    /// <summary>
    /// 坦克車模型
    /// </summary>
    private Model tankModel;

    // 坦克左前輪組件
    private ModelBone leftFrontWheelBone;

    // 坦克左前輪的平移矩陣
    private Matrix leftFrontWheelTransform;

    /// <summary>
    /// 坦克所有組件的平移矩陣
    /// </summary>
    private Matrix[] boneTransforms;
    // 輪子的旋轉值
    private float wheelRotationValue;

    /// <summary>
    /// Get或Set輪子的旋轉值.
    /// </summary>
    public float WheelRotation
    {
      get { return wheelRotationValue; }
      set { wheelRotationValue = value; }
    }

    /// <summary>
    /// 載入坦克車資源
    /// </summary>
    public void Load(ContentManager content)
    {
      // 從ContentManager載入坦克車模型.
      this.tankModel = content.Load<Model>("tank");

      // 參照坦克左前輪組件
      this.leftFrontWheelBone = this.tankModel.Bones["l_front_wheel_geo"];

      // 取得左前輪平移矩陣
      this.leftFrontWheelTransform = this.leftFrontWheelBone.Transform;

      // 配置所有組件的平移矩陣
      this.boneTransforms = new Matrix[this.tankModel.Bones.Count];
    }
    /// <summary>
    /// 坦克車的繪圖機制
    /// </summary>
    /// <param name="world">世界矩陣</param>
    /// <param name="view">觀察矩陣</param>
    /// <param name="projection">投影矩陣</param>
    public void Draw(Matrix world, Matrix view, Matrix projection)
    {
      // 設定坦克車最上層的平移矩陣為世界矩陣
      this.tankModel.Root.Transform = world;

      // 輪子繞著X軸旋轉
      Matrix wheelRotation = Matrix.CreateRotationX(this.wheelRotationValue);
      // 左前輪的平移矩陣 = 旋轉矩陣 * 平移矩陣
      this.leftFrontWheelBone.Transform = wheelRotation * this.leftFrontWheelTransform;

      // 更新所有組件的平移矩陣
      this.tankModel.CopyAbsoluteBoneTransformsTo(this.boneTransforms);

      // 繪製模型
      foreach (ModelMesh mesh in this.tankModel.Meshes)
      {
        foreach (BasicEffect effect in mesh.Effects)
        {
          effect.World = this.boneTransforms[mesh.ParentBone.Index];
          effect.View = view;
          effect.Projection = projection;

          effect.EnableDefaultLighting();
        }

        mesh.Draw();
      }
    }
  }
}

接著馬上更新遊戲主程式，讓坦克的左前輪旋轉，修改 Game1.cs（ SimpleAnimation.cs ）：

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;

namespace SimpleAnimationSample
{
  /// <summary>
  /// 控制坦克車模型動畫的範例程式
  /// </summary>
  public class SimpleAnimation : Microsoft.Xna.Framework.Game
  {
    private GraphicsDeviceManager graphics;

    private Tank tank;
    public SimpleAnimation()
    {
      this.graphics = new GraphicsDeviceManager(this);

      this.graphics.PreferredBackBufferWidth = 600;
      this.graphics.PreferredBackBufferHeight = 450;

      this.Content.RootDirectory = "Content";
    }

    /// <summary>
    /// 初始化遊戲內容
    /// </summary>
    protected override void Initialize()
    {
      this.tank = new Tank();

      base.Initialize();
    }

    /// <summary>
    /// 載入遊戲資源
    /// </summary>
    protected override void LoadContent()
    {
      this.tank.Load(this.Content);
    }

    /// <summary>
    /// 遊戲邏輯更新
    /// </summary>
    /// <param name="gameTime">上一次更新後經過的時間</param>
    protected override void Update(GameTime gameTime)
    {
      // 上次更新後到現在經過幾秒
      float time = (float)gameTime.TotalGameTime.TotalSeconds;

      // 更新坦克輪子的旋轉值
      this.tank.WheelRotation = time * 5;

      base.Update(gameTime);
    }

    /// <summary>
    /// 遊戲繪圖更新
    /// </summary>
    /// <param name="gameTime">上一次繪圖後經過的時間</param>
    protected override void Draw(GameTime gameTime)
    {
      this.GraphicsDevice.Clear(Color.CornflowerBlue);

      // 視窗畫面
      Viewport viewport = this.GraphicsDevice.Viewport;

      // 畫面長寬比
      float aspectRatio = (float)viewport.Width / (float)viewport.Height;

      // 世界矩陣(縮放矩陣, 旋轉矩陣, 平移矩陣)
      Matrix world = Matrix.CreateScale(1.0f) * Matrix.CreateRotationY(MathHelper.PiOver4) * Matrix.CreateTranslation(Vector3.Zero);

      // 觀察矩陣(攝影機座標, 攝影機焦點座標, 攝影機上方的向量)
      Matrix view = Matrix.CreateLookAt(new Vector3(1000, 600, 0), new Vector3(0, 100, 0), Vector3.Up);

      // 投影矩陣(畫面視角呈現弧度, 畫面長寬比, 近景值, 遠景值)
      Matrix projection = Matrix.CreatePerspectiveFieldOfView(MathHelper.PiOver4, aspectRatio, 10, 10000);

      this.tank.Draw(world, view, projection);

      base.Draw(gameTime);
    }
  }
}

沒意外的話坦克車的左前輪就會開始旋轉了，接著其他的組件也只要按照上面的步驟加入程式碼，就能完成一部很酷的坦克車動畫了，手邊如果有其他模型檔的話也可以玩玩看~

完整範例程式：

SimpleAnimationSample.rar（part1）（part2）

參考資料：

SortedDictionary 如何自訂排序

Fri, 22 May 2009 00:00:00 GMT

之前再寫資料檢索這堂課的作業時，碰到一個 SortedDictionary 排序上的問題，因為我在寫反轉索引法的過程中有使用到這個集合，其中 Key 的部分我是用來存放 TF-IDF 演算法求出來的 weight score，這個值我是以 double 的型態來存放，不過因為 SortedDictionary 的排序方式是由小到大，也就是以升冪排序的方式幫你排序好了，但是我希望它能夠由大到小排序，因為作業的顯示結果要求 weight score 越高的結果要排越前面，所以我上 MSDN 查了一下 SortedDictionary 的資料後，本來看到它有一個 Reverse 的方法，不過後來研究了好久還是不會用，最後就上 PTT 的 C_Sharp 板去求助，經過 Cloud 大大的指導後終於解決這個問題了。

利用 SortedDictionary 建構式的一個多載，IComparer 介面就可以實現自訂排序方式，來看看實作程式碼吧。

我們先看一下一開始 SortedDictionary 為我們排序的結果：

using System;
using System.Collections.Generic;

namespace SortedDictionarySample
{
  class Program
  {
    static void Main(string[] args)
    {
      SortedDictionary<int, string> sortedDictionary = new SortedDictionary<int, string>();

      sortedDictionary.Add(5, "五");
      sortedDictionary.Add(4, "四");
      sortedDictionary.Add(6, "六");
      sortedDictionary.Add(2, "二");
      sortedDictionary.Add(8, "八");

      foreach (KeyValuePair<int, string> kvp in sortedDictionary)
      Console.WriteLine(kvp.Value);
    }
  }
}

上面是一開始用 SortedDictionary 排序的結果，可以看出他是由小到大的升冪排序。接下來就是本文的重點，自己定義 SortedDictionary 排序方式的實作方法：

using System;
using System.Collections.Generic;

namespace SortedDictionarySample
{
  ///
  /// 遞減整數用的比較器，實作IComparer介面
  ///
  public class IntegerDecreaseComparer : IComparer<int>
  {
    ///
    /// Compares two integer and returns a value indicating whether one is less than, equal to, or greater than the other.
    ///
    /// The first integer to compare.
    /// The second integer to compare.
    ///
    /// return Less than zero if x is less than y,
    /// return Zero if x equals y,
    /// return Greater than zero if x is greater than y.
    ///
    public int Compare(int x, int y)
    {
      if (x < y)
        return 1;
      else
        return -1;
    }
  }

  class Program
  {
    static void Main(string[] args)
    {
      SortedDictionary<int, string> sortedDictionary = new SortedDictionary<int, string>(new IntegerDecreaseComparer());

      sortedDictionary.Add(5, "五");
      sortedDictionary.Add(4, "四");
      sortedDictionary.Add(6, "六");
      sortedDictionary.Add(2, "二");
      sortedDictionary.Add(8, "八");

      foreach (KeyValuePair<int, string> kvp in sortedDictionary)
      Console.WriteLine(kvp.Value);
    }
  }
}

範例程式：

SortedDictionarySample.rar

參考資料：

MSDN

Strategy pattern 策略模式

Wed, 20 May 2009 00:00:00 GMT

這篇文章是我打算要寫的 Design pattern 系列中的第一篇，在我大學三年級的時候，修了系上開的視窗程式設計課程，開課教授也是我的專題指導教授，這堂課老師教了我們很多關於 programming design pattern 的觀念。

最近剛好也讀完了 O’REILLY 出版的 Head First Design Patterns（深入淺出設計模式），對於一些較常用的 pattern 也有了更加的了解，所以我希望能整理幾個比較入門的 pattern 來當作學習文章,如果有哪裡寫錯或是有疑問的，非常歡迎留言指教，大家一起學習。

什麼是 design pattern（設計模式）呢?

design pattern 是對軟體設計中普遍存在（反覆出現）的各種問題，所提出的解決方案。

design pattern 並不是直接用來完成程式碼的編寫，而是描述在各種不同情況下，要怎麼解決問題的一種方案。

演算法不能算是一種 design pattern，因為演算法主要是用來解決計算上的問題，而非設計上的問題。 design pattern 主要目的是避免會引起麻煩的程式緊密耦合，以增強軟體設計面對並適應變化的能力。

以上是引用軟體設計模式-維基百科的其中一段介紹，第一次接觸的人可以去看看相關內容。

接下來我們進入主題，第一篇要來介紹的 pattern 是 Strategy pattern （策略模式）。

Strategy pattern 是指物件本身有某些行爲（method），但是在不同的情況中，該行爲有不同的實現方式（演算法），找出程式中可能需要更動的地方，把它們個別封裝起來，就算演算法有變動，也不會影響到使用演算法的程式，舉個維基百科提供的例子，比如每個人都要「繳交個人所得稅」，但是「在美國繳交的個人所得稅」和「在台灣繳交的個人所得稅」就有不同的計算稅的演算法。

我們用 Head First Design Patterns 書上的鴨子範例來一步步解釋。

假設我們打算完成一個模擬鴨子的小程式，程式中可以模擬出各種不同類型的鴨子行為，例如游泳，呱呱叫等等的…。

這個時候我們會設計一個擁有這些行為的鴨子抽象類別（abstract class），讓各種鴨子繼承此類別。

紅頭鴨跟綠頭鴨都直接繼承 Duck 的 swim（游泳）跟 quack（呱呱叫）方法，因為兩隻鴨子的外觀不同，所以各自實作 display 抽象方法。

如果這個時候突然想為鴨子加上飛行的行為呢?

很直覺的，我們會直接在 Duck 中加入 fly() 讓每種鴨子都能順利繼承。

但是這個時候我們碰到問題了。

如果我們打算加入一隻橡皮玩具鴨怎麼辦?

橡皮鴨繼承了上面 Duck 的 fly 行為，可是像皮鴨實際上並不會飛行的……。

你可能想到一個方法，就是用 override 覆寫 fly() 方法，讓它不實作任何程式。

解決了飛行的問題之後，我們發現其實像皮鴨的叫聲也跟其他鴨子不同，所以把 quack() 方法也 override 成吱吱叫，取代原本的呱呱叫。

但是問題解決後，馬上又產生另一個問題，如果我們又打算加入一隻誘餌鴨呢? 誘餌鴨不會飛也不會叫，我們又要把 fly() 跟 quack() 兩個方法又 override 一次。

這裡我們就會發現，利用繼承的方式提供鴨子行為會產生一些問題：

程式碼在多個類別中不斷重複
runtime 期間，鴨子的行為不容易改變
難以得知鴨子的全部行為
改變會牽一髮動全身，造成其他鴨子不想要的影響

上面我們看見最主要的問題就是不容易維護，若是以後還有其他鴨子要加進來，我們又要因應它的特性來繼續 override 這些行為，而這些行為其實之前明明就已經實作過了，最後造成一堆不必要的程式碼重複。

不能用繼承的話，用介面來實作如何?

把上面需要不同實作方式的 fly 跟 quack 抽出來分別寫成 Flyable 跟 Quackable 介面，讓所有鴨子實作牠們自己需要的介面。

完成了上面的實作後，雖然完成了不用一直 override 的難題，並且也可以實現出不會飛的鴨子，但是最主要的問題還是沒解決，程式碼還是有到處重複無法再利用的情形，例如上圖中 MallarDuck 跟 RedheadDuck 的 fly() 跟 quack() 內容都是一樣的，綠頭鴨是呱呱叫跟會飛，紅頭鴨也是呱呱叫會飛，但是牠們卻都要自己再寫一次程式碼去實作，根據維基百科提供的資料，鴨子的種類有 40 到 50 種，這些都是會飛且呱呱叫的鴨子，難道要我們每增加一次鴨子類別，就又要去實作已經寫過的 fly() 跟 quack() 嗎！？可見這並不是一個良好的 OO 軟體設計方式。

那到底該怎麼寫才適合這些可惡的鴨子呢…?

接下來會進入我們這篇文章的重點，策略模式的精神。

我們知道目前 Duck 類別內的 fly() 跟 quack() 會隨著有些鴨子的不同而改變，為了要讓他們可以隨著鴨子改變，且達到可重覆利用的特性，我們一樣將這兩個行為從 Duck 抽出來，獨立寫成個別的類別，讓我們來看下面這張圖。

上圖就是為了讓鴨子行為可以再三利用，獨立分出來的兩個策略類別（Strategy class），所有不同的飛行類別都要實作（或繼承）FlyBehavior 介面（或抽象類別），叫聲行為也是，這樣做有什麼好處呢？我們直接寫程式來實作給大家看。

using System;

namespace StrategySample
{
  /// <summary>
  /// 鴨子抽象類別
  /// </summary>
  public abstract class Duck
  {
    /// <summary>
    /// 每隻鴨子都會參考到一個實踐FlyBehavior介面的飛行物件
    /// </summary>
    protected FlyBehavior flyBehavior;
    /// <summary>
    /// 每隻鴨子都會參考到一個實踐QuackBehavior介面的叫聲物件
    /// </summary>
    protected QuackBehavior quackBehavior;

    /// <summary>
    /// 鴨子的外觀
    /// </summary>
    /// <remarks>因為每隻鴨子的外觀不同，所以display()方法是抽象的</remarks>
    public abstract void display();

    /// <summary>
    /// 鴨子的游泳行為
    /// </summary>
    /// <remarks>所有的鴨子都用相同的方式游泳，所以由超類別負責處理這部份的程式</remarks>
    public void swim()
    {
      Console.WriteLine("All duck s float, even decoys");
    }

    /// <summary>
    /// 鴨子的飛行行為
    /// </summary>
    /// <remarks>鴨子不親自處理飛行行為，而是委由flyBehavior物件幫Duck進行飛行</remarks>
    public void performFly()
    {
      this.flyBehavior.fly();
    }

    /// <summary>
    /// 鴨子的叫聲行為
    /// </summary>
    /// <remarks>鴨子不親自處理叫聲行為，而是委由quackBehavior物件幫Duck進行呱呱叫</remarks>
    public void performQuack()
    {
      this.quackBehavior.quack();
    }

    /// <summary>
    /// 呼叫setFlyBehavior()方法可以改變鴨子的飛行方式
    /// </summary>
    /// <param name="newFlyBehavior">想要改變的飛行方式</param>
    public void setFlyBehavior(FlyBehavior newFlyBehavior)
    {
      this.flyBehavior = newFlyBehavior;
    }

    /// <summary>
    /// 呼叫setQuackBehavior()方法可以改變鴨子的叫聲方式
    /// </summary>
    /// <param name="newQuackBehavior">想要改變的叫聲方式</param>
    public void setQuackBehavior(QuackBehavior newQuackBehavior)
    {
      this.quackBehavior = newQuackBehavior;
    }
  }
}

上面我們把 FlyBehavior 跟 QuackBehavior 以介面的型態加入到 Duck 的成員變數，這樣就能在 Runtime 期間動態改變鴨子的行為。

再來我們繼續把上面的 FlyBehavior 跟 QuackBehavior 程式碼給寫出來。

namespace StrategySample
{
  /// <summary>
  /// 這是一個飛行行為的介面，所有飛行行為的類別都應該實作它
  /// </summary>
  public interface FlyBehavior
  {
    /// <summary>
    /// 飛行的方式
    /// </summary>
    /// <remarks>所有繼承FlyBehavior的類別都應該實作此方法</remarks>
    void fly();
  }
}

namespace StrategySample
{
  /// <summary>
  /// 這是一個叫聲行為的介面，所有叫聲行為的類別都應該實作它
  /// </summary>
  public interface QuackBehavior
  {
    /// <summary>
    /// 叫聲的方式
    /// </summary>
    /// <remarks>所有繼承QuackBehavior的類別都應該實作此方法</remarks>
    void quack();
  }
}

然後我們把所有的行為實作出來

using System;

namespace StrategySample
{
  /// <summary>
  /// 用翅膀飛行的行為
  /// </summary>
  public class FlyWithWings : FlyBehavior
  {
    public void fly()
    {
      Console.WriteLine("I'm flying with my wings");
    }
  }
}

using System;

namespace StrategySample
{
  /// <summary>
  /// 無法飛行的行為
  /// </summary>
  public class FlyNoWay : FlyBehavior
  {
    public void fly()
    {
      Console.WriteLine("I can't fly");
    }
  }
}

using System;

namespace StrategySample
{
  /// <summary>
  /// 呱呱叫的行為
  /// </summary>
  public class Quack : QuackBehavior
  {
    public void quack()
    {
      Console.WriteLine("I say Quack");
    }
  }
}

using System;

namespace StrategySample
{
  /// <summary>
  /// 吱吱叫的行為
  /// </summary>
  public class Squeak : QuackBehavior
  {
    public void quack()
    {
      Console.WriteLine("I say Squeak");
    }
  }
}

using System;

namespace StrategySample
{
  /// <summary>
  /// 沒有叫聲的行為
  /// </summary>
  public class MuteQuack : QuackBehavior
  {
    public void quack()
    {
      Console.WriteLine("I say ...(Silence)");
    }
  }
}

接著我們來寫一隻綠頭鴨子的模擬程式測試看看。

using System;

namespace StrategySample
{
  /// <summary>
  /// 綠頭鴨
  /// </summary>
  public class MallardDuck : Duck
  {
    /// <summary>
    /// 綠頭鴨
    /// </summary>
    public MallardDuck()
    {
      this.flyBehavior = new FlyWithWings();
      this.quackBehavior = new Quack();
    }
    public override void display()
    {
      Console.WriteLine("I'm a real mallard duck");
    }
  }
}

using System;

namespace StrategySample
{
  public class MiniDuckSimulator
  {
    static void Main(string[] args)
    {
      // 新增一隻綠頭鴨
      Duck mallardDuck = new MallardDuck();

      mallardDuck.display();      // 綠頭鴨外觀
      mallardDuck.performFly();   // 用翅膀飛行
      mallardDuck.performQuack(); // 呱呱叫
    }
  }
}

完成了綠頭鴨子之後我們再加入一隻紅頭鴨子模擬一遍。

using System;

namespace StrategySample
{
  /// <summary>
  /// 紅頭鴨
  /// </summary>
  public class RedheadDuck : Duck
  {
    /// <summary>
    /// 紅頭鴨
    /// </summary>
    public RedheadDuck()
    {
      this.flyBehavior = new FlyWithWings();
      this.quackBehavior = new Quack();
    }
    public override void display()
    {
      Console.WriteLine("I'm a real redhead duck");
    }
  }
}

using System;

namespace StrategySample
{
  public class MiniDuckSimulator
  {
    static void Main(string[] args)
    {
      // 新增一隻綠頭鴨
      Duck mallardDuck = new MallardDuck();

      mallardDuck.display();      // 綠頭鴨外觀
      mallardDuck.performFly();   // 用翅膀飛行
      mallardDuck.performQuack(); // 呱呱叫

      Console.WriteLine("-------------------------");

      // 新增一隻紅頭鴨
      Duck redheadDuck = new RedheadDuck();

      redheadDuck.display();      // 紅頭鴨外觀
      redheadDuck.performFly();   // 用翅膀飛行
      redheadDuck.performQuack(); // 呱呱叫
    }
  }
}

看到上面的程式就可以發現雖然紅頭鴨跟綠頭鴨的行為一樣，但是不會產生像之前那樣程式碼重覆的情形，因為我們將 fly 跟 quack 的實作方式交給 FlyBehavior 跟 QuackBehavior，鴨子們只管呼叫它，不必知道它們的實現方法，這是 OO 中一個很重要的概念。

繼續完成剩下的兩隻鴨子

using System;

namespace StrategySample
{
  /// <summary>
  /// 橡皮鴨
  /// </summary>
  public class RubberDuck : Duck
  {
    /// <summary>
    /// 橡皮鴨
    /// </summary>
    public RubberDuck()
    {
      this.flyBehavior = new FlyNoWay();
      this.quackBehavior = new Squeak();
    }
    public override void display()
    {
      Console.WriteLine("I'm a real rubber duck");
    }
  }
}

using System;

namespace StrategySample
{
  /// <summary>
  /// 誘餌鴨
  /// </summary>
  public class DecoyDuck : Duck
  {
    /// <summary>
    /// 誘餌鴨
    /// </summary>
    public DecoyDuck()
    {
      this.flyBehavior = new FlyNoWay();
      this.quackBehavior = new MuteQuack();
    }

    public override void display()
    {
      Console.WriteLine("I'm a real decoy duck");
    }
  }
}

using System;

namespace StrategySample
{
  public class MiniDuckSimulator
  {
    static void Main(string[] args)
    {
      // 新增一隻綠頭鴨
      Duck mallardDuck = new MallardDuck();

      mallardDuck.display();      // 綠頭鴨外觀
      mallardDuck.performFly();   // 用翅膀飛行
      mallardDuck.performQuack(); // 呱呱叫

      Console.WriteLine("-------------------------");

      // 新增一隻紅頭鴨
      Duck redheadDuck = new RedheadDuck();

      redheadDuck.display();      // 紅頭鴨外觀
      redheadDuck.performFly();   // 用翅膀飛行
      redheadDuck.performQuack(); // 呱呱叫

      Console.WriteLine("-------------------------");

      // 新增一隻橡皮鴨
      Duck rubberDuck = new RubberDuck();

      rubberDuck.display();       // 橡皮鴨外觀
      rubberDuck.performFly();    // 不會飛行
      rubberDuck.performQuack();  // 吱吱叫

      Console.WriteLine("-------------------------");

      // 新增一隻誘餌鴨
      Duck decoyDuck = new DecoyDuck();

      decoyDuck.display();        // 誘餌鴨外觀
      decoyDuck.performFly();     // 不會飛行
      decoyDuck.performQuack();   // 不會叫
    }
  }
}

到這裡我們已經把鴨子模擬程式完成的差不多了，最後我們再來加一隻鴨子，我們加入一隻可以隨時改造的模型鴨子，這裡可以看出 runtime 期間動態改變行為的威力。

using System;
namespace StrategySample
{
  /// <summary>
  /// 模型鴨
  /// </summary>
  public class ModelDuck : Duck
  {
    /// <summary>
    /// 模型鴨
    /// </summary>
    public ModelDuck()
    {
      this.flyBehavior = new FlyNoWay();
      this.quackBehavior = new MuteQuack();
    }
    public override void display()
    {
      Console.WriteLine("I'm a real model duck");
    }
  }
}

接著我們為 ModelDuck 寫一個飛行行為，我們把它取名為火箭飛行 FlyRocketPowered。

namespace StrategySample
{
  /// <summary>
  /// 利用火箭動力飛行的行為
  /// </summary>
  public class FlyRocketPowered : FlyBehavior
  {
    public void fly()
    {
      Console.WriteLine("I'm flying with rocket");
    }
  }
}

好了，我們開始模擬這隻模型鴨，一開始我們的模型鴨不會飛也不會叫，經過了 Duck 的 setFlyBehavior() 我們可以在程式執行的期間把它裝上火箭動力，使它飛起來。

using System;

namespace StrategySample
{
  public class MiniDuckSimulator
  {
    static void Main(string[] args)
    {
      // 新增一隻綠頭鴨
      Duck mallardDuck = new MallardDuck();

      mallardDuck.display();      // 綠頭鴨外觀
      mallardDuck.performFly();   // 用翅膀飛行
      mallardDuck.performQuack(); // 呱呱叫

      Console.WriteLine("-------------------------");

      // 新增一隻紅頭鴨
      Duck redheadDuck = new RedheadDuck();

      redheadDuck.display();      // 紅頭鴨外觀
      redheadDuck.performFly();   // 用翅膀飛行
      redheadDuck.performQuack(); // 呱呱叫

      Console.WriteLine("-------------------------");

      // 新增一隻橡皮鴨
      Duck rubberDuck = new RubberDuck();

      rubberDuck.display();       // 橡皮鴨外觀
      rubberDuck.performFly();    // 不會飛行
      rubberDuck.performQuack();  // 吱吱叫

      Console.WriteLine("-------------------------");

      // 新增一隻誘餌鴨
      Duck decoyDuck = new DecoyDuck();

      decoyDuck.display();        // 誘餌鴨外觀
      decoyDuck.performFly();     // 不會飛行
      decoyDuck.performQuack();   // 不會叫

      Console.WriteLine("-------------------------");

      // 新增一隻模型鴨
      Duck modelDuck = new ModelDuck();

      modelDuck.display();        // 模型鴨外觀
      modelDuck.performFly();     // 不會飛行
      modelDuck.performQuack();   // 不會叫

      Console.WriteLine("After the installation of rocket...");

      modelDuck.setFlyBehavior(new FlyRocketPowered());   // 裝上火箭動力之後...
      modelDuck.performFly();     // 火箭動力飛行!!!
    }
  }
}

OK!!! 鴨子模擬程式完成了，我們來看看整個類別架構圖。

到這裡我們已經將策略模式給學起來了，讓我們來看看策略模式的 UML，並且跟上圖比較看看。

看完了上面介紹的鴨子範例後我想大家應該已經可以了解策略模式的主要精神了，將抽象類別中可能會需要隨著繼承類別的不同改變的方法獨立抽出來封裝成另外一個介面，然後個別為這些介面去實作需要的類別方法，不但增加可利用性，也不會出現程式碼不斷重複的情況。

呼，寫到這裡終於到一個段落了，因為這是我的第一篇心得分享文章，所以希望把它寫的很仔細，雖然可能有很多地方會有問題，或是交待的不清楚，所以大家如果有哪些疑問也請不要客氣，儘管提出你的看法，讓我有更大的動力繼續衝下一篇文章，謝謝。

下一篇 design pattern 的文章我打算介紹同樣屬於比較容易了解的初學模式，Factory pattern（工廠模式），Factory pattern 也是一個非常常用的設計方式，其中還衍生出許多不同的 pattern，例如 abstract factory pattern（抽象工廠模式），希望到時能如期把它完成並分享上來，謝謝大家不厭其煩的把這篇文章看到這裡，感謝。

範例程式:

StrategySample.rar

參考資料: