Ada Hsu 的胡思亂想

SHELL 下輸出貼齊的訊息

2018-05-10T16:29:00.002+08:00


function getPosition {

    echo -ne "\033[6n"            # ask the terminal for the position
    read -s -d\[ garbage          # discard the first part of the response
    read -s -d R pos              # store the position in bash variable 'foo'
    Y=$(echo "$pos" | cut -d\; -f 1)
    X=$(echo "$pos" | cut -d\; -f 2)
}


## 以指定顏色在 TERMINAL 右側顯示指定內容
function showStatus {

    WIDTH=$(tput cols)

    COLOR=$1
    MSG=$2

    LENGTH=$(echo ${MSG} | wc -c)

    # 取得目前座標 X: col, Y: row
    getPosition

    NEW_POS=$(expr ${WIDTH} - ${LENGTH})
    REPEATE=$(expr ${NEW_POS} - ${X})
    printf '.%.0s' $(seq 1 ${REPEATE})
    echo -e "${COLOR}${MSG}${COLOR_RESET}"

}

COLOR_HIGHWHITE='\033[1;37m'

echo
echo -n "This is a Book"
showStatus "${COLOR_HIGHWHITE}" "[YES]"

以下是執行範例：

在 macOS 上設定炫酷的終端機操作環境 - 使用 oh-my-zsh w/ Powerlevel9k

2017-11-10T14:50:00.001+08:00

2018/10/25 補充：更多的客製化：Powerlevel9k: personalise your terminal prompt for any programming language

2018/08/15 補充：如果喜歡 Fira Code 字體的話，可以套用 font-firacode-nerd-font

這兩天把個人在使用的終端機環境改造了一番，很能自嗨，所以留個記錄... XD

先裝 Homebrew
再安裝 caskroom
```
brew update
brew install cask
```
參考這裡完成 zsh / oh-my-zsh 的安裝
安裝 Powerlevel9k
安裝相關字型
- 基本上就是 Powerline / Awesome / Nerd 三類字型選一個，個人建議 Nerd 類字型即可，因為它的 icon 最完整
- 以下指令可以啟用 caskroom 的字型庫管理
```
brew tab caskroom/fonts
brew update
```
- nerd 相關的字型很多，可以挑一個自己喜歡的來裝，這裡安裝 Source Code Pro 版本
```
brew search nerd
```

編輯 ~/.zshrc ，設定 Powerlevel9k 運作模式


# 找到 ZSH_THEME 字串位置，改成如下：

POWERLEVEL9K_MODE=nerdfont-complete
ZSH_THEME="powerlevel9k/powerlevel9k"

參考作者的說明及別人的設定，組合出自己最酷炫的終端機界面，重點可先放在以下幾項測試：
- POWERLEVEL9K_LEFT_PROMPT_ELEMENTS
- POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS
- POWERLEVEL9K_PROMPT_ADD_NEWLINE
- POWERLEVEL9K_PROMPT_ON_NEWLINE

個人的設定如下，加在 ~/.zshrc 檔案末端：


POWERLEVEL9K_SHORTEN_DIR_LENGTH=2

POWERLEVEL9K_TIME_BACKGROUND="white"
POWERLEVEL9K_TIME_FOREGROUND="black"
# POWERLEVEL9K_TIME_FORMAT="%D{%H:%M:%S}"

POWERLEVEL9K_VCS_GIT_ICON='\uf1d3'
POWERLEVEL9K_VCS_GIT_GITHUB_ICON='\uf09b'
# POWERLEVEL9K_VCS_CLEAN_FOREGROUND='blue'
# POWERLEVEL9K_VCS_CLEAN_BACKGROUND='black'
# POWERLEVEL9K_VCS_UNTRACKED_FOREGROUND='red'
# POWERLEVEL9K_VCS_UNTRACKED_BACKGROUND='black'
# POWERLEVEL9K_VCS_MODIFIED_FOREGROUND='black'
# POWERLEVEL9K_VCS_MODIFIED_BACKGROUND='black'

POWERLEVEL9K_STATUS_VERBOSE=true
POWERLEVEL9K_STATUS_OK_IN_NON_VERBOSE=false

POWERLEVEL9K_VPN_ICON='\uf023'

POWERLEVEL9K_PROMPT_ON_NEWLINE=true
POWERLEVEL9K_PROMPT_ADD_NEWLINE=true
POWERLEVEL9K_FOLDER_ICON='\uf114'

# Bateria
POWERLEVEL9K_BATTERY_CHARGING='yellow'
POWERLEVEL9K_BATTERY_CHARGED='blue'
POWERLEVEL9K_BATTERY_LOW_THRESHOLD='20'
POWERLEVEL9K_BATTERY_LOW_COLOR='red'
POWERLEVEL9K_BATTERY_CHARGED_BACKGROUND='46'
POWERLEVEL9K_BATTERY_CHARGED_FOREGROUND='235'
POWERLEVEL9K_BATTERY_CHARGING_BACKGROUND='178'
POWERLEVEL9K_BATTERY_CHARGING_FOREGROUND='235'
POWERLEVEL9K_BATTERY_LOW_BACKGROUND='88'
POWERLEVEL9K_BATTERY_LOW_FOREGROUND='235'
POWERLEVEL9K_BATTERY_CHARGED_ICON='\UF240'
POWERLEVEL9K_BATTERY_LOW_ICON='\UF240'
POWERLEVEL9K_BATTERY_CHARGING_ICON='\UF1E6'
POWERLEVEL9K_BATTERY_DISCONNECTED_FOREGROUND='white'
POWERLEVEL9K_BATTERY_DISCONNECTED_BACKGROUND='red'
POWERLEVEL9K_BATTERY_ICON='\UF1E6'

# Anaconda
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(anaconda battery)
POWERLEVEL9K_ANACONDA_RIGHT_DELIMITER='>'
POWERLEVEL9K_ANACONDA_LEFT_DELIMITER='<'
POWERLEVEL9K_ANACONDA_BACKGROUND='24'
POWERLEVEL9K_ANACONDA_FOREGROUND='111'
# POWERLEVEL9K_ANACONDA_ICON=''

POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(os_icon context dir dir_writable vcs )
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(status root_indicator background_jobs command_execution_time time battery anaconda)

記得在終端機中選定使用的字型為剛剛安裝的 Nerd 字型，不然只會看到亂碼 1/2 ... (這哏好冷)
效果如下，謝謝收看！

從 Google Container Engine 連線到 Google SQL for MySQL / 以 Java 為例

2017-07-28T08:42:00.000+08:00

看了一下發文記錄，這應該是此格在停業六年後重新生出來的文章，就... 留個記錄吧！

這篇內容是以個人已理解的資訊為基礎所撰寫，特色是知其然而不知其所以然，所以不保證理解上的正確性，請參考官方文件進行相互確認，謝謝。

源起

我是在 2016 年時開始接觸容器應用的，不過實務上一直沒啥機會應用。後來在前公司的 2017 年計劃中原本有一項重點是預訂將營業相關的應用系統自單機移轉到雲端上（因為服務是面向全球），但公司停業了（所以我失業了），這項計劃也就不了了之。

不過工作好像不是那麼好找，於是趁著找工作時的空檔，試著把這個計劃驗證一遍。

營業系統的核心架構是 APIs + MySQL，原本是在 Google 上開設兩台 VM 各司其職，實務上它並不具有 Non Stopping 的服務等級要求，也就是說若 API Server 或 MySQL 資料庫崩潰了，在管理人員進行修正前服務都是停擺的。

這次選擇的是雲端平台是 Google Cloud Platform，理由只是因為它直接提供了 Cloud SQL for MySQL，在資料量不多的情況下相信可以直接透過 mysqldump 無痛轉移資料庫內容。

示範平台

本案範例是在 macOS Sierra 上進行驗證，系統上包含了 Docker for Mac 17.06.0-ce、Java SDK 1.8.0_102、以及 MySQL Client for 5.7.17。Java 打包工具則為 Apache Maven 3.5.0，但應該 3.x 以上版本都能適用。

範例中使用的操作指令大致上都可以在各平台下操作，必要時會針對 Windows 平台部份進行猜測說明。

試用 Google Cloud Platform

Google 針對 Google Cloud Platform （以下稱 GCP）提供了 12 個月 300 美金的試用額度，這對於懶人測試員有很大的誘因，如果你不想在 2 ~ 3 星期內完成一大堆的測試，那麼 GCP 可以讓你安心的將測試項目安排在 52 星期內慢慢進行... XD

啟用的方式很簡單：

準備好一個 Google Account
準備好一張信用卡，Google 聲稱未取得使用者同意前不會扣款（有加入 Android Pay 的話應該會直接使用相關的設定）
登入 Google Cloud Platform Console 後，按下 TRY IT FREE 或申請免費試用按鈕
依頁面指示填寫資料，這部份我忘了要填什麼了... XD
然後就正式啟用了

建立 GCP 專案

GCP 透過專案的概念協助管理人員於單一介面內管理與專案有關的各種 Google 服務，所以第一個就是建立 GCP 專案，上圖中紅框部份都能進入建立 GCP 專案的流程。

建立專案所需要填寫的基本資料不多，就是給定一個專案名稱而以，然後 Cloud Console 會在專案名稱不衝突的情形下會將這個專案名稱設定為專案 ID，這個專案 ID 在之後會常用到。

決定好專案名稱及專案 ID 後即可建立一個新的 GCP 專案，Console 需要一點時間進行資源配置，當配置完成後即可在專案的資訊主頁上方確認當前的操作所影響的專案名稱，而專案資訊這張卡片也會顯示目前使用中的專案名稱及專案 ID。

建立專案後會看到一個入門指南的卡片，可以花點時間看看。

建立 Cloud SQL 資料庫

回到前面所提到過的『營業系統的核心架構是 APIs + MySQL』這件事，大部份開發人員所想到的第一個問題應該就是如何建立一個雲端資料庫了！

在 Cloud SQL 上建立一個 MySQL 資料庫很簡單，除了透過 Google Cloud SDK 以指令方式建立外，還可以透過 Cloud Console UI 建立。

首先在 Cloud Console 資訊主頁中拉出左側的產品與服務選單、點選 SQL 服務然後進入 Cloud SQL 管理界面。

建立 MySQL 執行個體

目前並無任何執行中的 SQL 執行個體，所以必須點選建立執行個體鈕進行資料庫的建置動作，這邊可以選擇使用 MySQL 或 PostgreSQL（但是 Beta 中）資料庫，本案將使用 MySQL。

選擇使用的資料庫種類，此處選 MySQL

依照建議選擇 MySQL 第二代的執行個體類型

填寫 MySQL 基本參數

執行個體 ID：日後要用什麼名字來識別這個資料庫
根密碼：即 MySQL root 使用者的密碼
位置：資料庫要放在哪個區域，其中 asia-east1 指的是台灣，此處建議連分區也一併指定，後續建立其他環境時可以集中在同一機房內
※詳細的區域資訊可以參考 Cloud Locations

調整進階參數

點選顯示進階選項後有一些額外設定，設定後請記得按下關閉鈕以確保相關的變更被記錄下來。

選擇資料庫版本：指定 MySQL 資料庫的版本，預設是 5.7
設定機器類型和儲存空間：指定 MySQL 運作環境的資源，請依用途妥善選擇對應的資源環境
啟用自動備份與高可用性：決定是否進行自動備份，此處全部勾選以作為日後驗證備份機制之參考；建立容錯移轉備用資源指的是會在另一個機房建立一個資料庫備份，所有對資料庫的操作都會複製一份到備用資源這個執行個體來
授權網路：開放哪些 IP 可透過 MySQL Client 連接資料庫
新增 Cloud SQL 標記：等同於 my.cnf 中的設定，對於效能的最佳化參數都在此調整；lower_case_table_names 這是為了讓表格名稱可以不分大小寫（事實上就是強制小寫）之用
設定維護時間：用途不明，不予解釋

本案最後的參數設定如下，確認沒有問題後按下建立鈕開始建置 MySQL 資料庫。

建置 MySQL 資料庫中的畫面，它需要一點時間，可以先泡個咖啡再回來。

完成後的資訊主頁會像這樣，其中可以注意會有兩個對外 IP 且分佈於不同機房。

點選各 Instance ID 後即可管理該執行個體，除了檢視運作狀態外還包含修改配置、匯入、匯出、開關服務、複製、甚至刪除資料庫等操作。

測試是否可以透過 MySQL Client 分別連上這兩個執行個體。

主資料庫
容錯資料庫

建立空白資料庫

為了後續測試所需，此時先在主資料庫 demo 上建立一個空白資料庫，名稱為 springbootdemo，這個資料庫會自動複製到容錯資料庫 demo-failover 去。

CREATE DATABASE springbootdemo
  DEFAULT CHARACTER SET utf8
  DEFAULT COLLATE utf8_general_ci;

IP 參照設定

為了便於操作，可將 Cloud SQL for MySQL 的兩個 IP 寫入 /etc/hosts （Widnows 平台請參考手動設定網址與 IP 對應的 hosts 檔教學，適用 Windows、Mac OS X 與 Linux 系統一文說明）內，此處設定 mysql.gcp 對應到主資料庫，failover.gcp 對應到容錯資料庫。

Spring Boot 示範程式

再來是開發一個可以存取 Cloud SQL for MySQL 的應用程序，這裡選擇使用 Spring Boot 開發框架。

選擇 Spring Boot 的理由主要是因為它可以整合 Tomcat 這類型的 Application Server，當我們需要將服務置入 Docker Container 中執行時就可以不必額外處理 Tomcat 在各種不同 Linux 散佈套件的差異。

複製範例程式

這個範例程式的功能是模擬兩個 API，分別是顯示被呼叫的主機名稱及中止應用程序（模擬程序崩潰）。請自 Github 上複製 SpringBootDemo 這個專案，關於 Spring Boot 的設定細節請自行參考網路文章，此處不特別說明：

以下命令列指令可以將 SpringBootDemo 專案複製到本地工作：

git clone https://github.com/AdaHsu/SpringBootDemo.git

整個示範程式的目錄結構如下圖，需要自行調整的參數設定都在 Maven 的設定檔 pom.xml 中：

修改 Maven 設定檔

在 pom.xml 中要修改的地方有 3 個，主要和資料庫存取有關：

local profile 下的 JDBC 連線資訊：確認已設定好 mysql.gcp 的 IP 參照，或直接將 mysql.gcp 替換為 Cloud SQL for MySQL 提供的對外 IP
JDBC 的使用者帳密設定：一般環境下應該要建立應用程式專屬帳號

測試程式運作狀態

完成修改後即可進行功能測試，測試前請先確認 Cloud SQL for MySQL 執行個體已啟用，然後下達以下指令打包程式，-P local 是指定產生本地測試用的版本，若為 -P gcp 則會產生 GCP 上適用的版本，可以從打包出來的檔名確認對應的執行環境。

mvn -P local clean package

完成打包後會產生 target 目錄，此處已設定打包後的 jar 檔檔名會依指定的 Profile 不同而變化。

為確保程式運作正常，建議先檢查資料庫連線參數是否正確設定，此參數應與 Maven 設定檔中設定的內容一致。

head target/classes/application.properties

如果是 Windows 平台，那麼指令應該要改成如下：

type target/classes/application.properties

預先以 MySQL Client 連上資料庫，確認資料庫內未建立任何表格。

啟動 Spring Boot 應用程式，若 JPA 能連接資料庫的話就不會有錯誤訊息，否則就會崩潰結束。

java -jar target/SpringBootDemo-local.jar

檢視資料庫，確認 access_logs 表格已被建立出來。

驗證 API

第一個 API 的用途是將呼叫記錄寫入資料庫內，並且傳回提供服務的主機名稱，在部署到 Google Container Engine 時將用於識別是哪一個容器 / Pod 提供服務的。

curl http://localhost:8080

第二個 API 的用途是中斷 Spring Boot 應用系統的執行，目的是模擬系統異常導致服務終止的情形。

curl http://localhost:8080/crash

呼叫結束後可以確認到 Spring Boot 應用程式被終止。

檢視資料庫，確認兩次呼叫記錄已被保存。

確認容錯資料庫內容也已同步更新。

echo "select * from access_logs;" | mysql -u root -h failover.gcp -p springbootdemo

打包 Docker 映像檔

從 Github 上下 clone 下來的檔案庫中包含兩個協助打包的 Dockerfile ，分別對應到打包成 local 及 gcp 兩個環境。

打包本地測試用映像檔

以下指令可以打包一個本地進行測試用的 docker image，MYSQL_IP 是記錄 /etc/hosts 中 demo.gcp 所指向 Cloud SQL for MySQL 的 Public IP，Windows 平台使用者請直接將 ${MYSQL_IP} 替換成 IP 位址即可：

MYSQL_IP=$(grep mysql.gcp /etc/hosts | cut -d\  -f 1)
docker build -t spring-boot-demo:1 \
  --add-host=mysql.gcp:${MYSQL_IP} \
  -f Dockerfile.local .

若是已將 pom.xml 中的 JDBC 連線字串替換成 IP 位址的話，那麼打包指令中的 --add-host 這段參數可以拿掉。

若是 Windows 平台可以直接給定 mysql.gcp 所對應的 IP，以下指令請記得替換 <mysql public ip> 為實際 IP：

docker build -t spring-boot-demo:1 --add-host=mysql.gcp:<mysql public ip> -f Dockerfile.local .

驗證映像檔

打包完畢後可以啟動這個 Container 映像檔確認是否正常運作。

docker run --rm -p 8080:8080 spring-boot-demo:1

檢視 API 是否可被呼叫？

打包 GCP 線上版本

GCP 下載 Docker Images 的來源有二：第一種是上傳到 Docker Hub，另一種方式則是上傳到專案所在的 Cloud Storage 中。上傳到 Cloud Storage 時需指定 Docker 映像檔的 Tag，格式為 gcr.io/<專案 ID>/<映像檔名>:<標籤>，其中 <專案 ID> 請參考專案資訊主頁中的專案資訊卡片。

以下指令可以打包一個在 GCP 上運行的 Docker 映像檔，為了避免包裝映像檔失敗，此處會重新打包 Spring Boot 範例程式：

mvn -P gcp clean package
docker build -t gcr.io/springboot-demo/spring-boot-demo:1 -f Dockerfile.gcp .

稍候會將這個映像檔上傳到 Google Cloud Storage 中供 Container Engine 叫用。

建立 Google 容器叢集

Google Container Engine (GCE，有時會看到 GKE 指的是同一個服務) 是 Google 提供的容器服務，在使用容器服務之前需要建立一個用於部署容器的容器叢集。

拉出左側產品與服務選單，點選 Container Engine 功能項後即可進入 Container Engine 資訊主頁，第一次進入這個主頁時可能需要一點時間啟用 Container Engine 服務。

有時候可能會發生沒有 Compute Engine API 權限而無法啟用 Container Engine 服務的問題，通常只要重新進入 Container Engine 資訊主頁即可改善。

建立容器叢集

在 Container Engine 資訊主頁中可以透過建立容器叢集按鈕建立新的叢集。

容器叢集基本上是透過 Compute Engine 裡頭的 VM 組建而成，它需要決定這個叢集的運作能量（財力決定能力？）。

設定叢集參數（一）

名稱：本叢集的名稱
說明：若有多個叢集共存的情形下，可以在此填寫一些說明內容
區域：要將叢集放在哪個機房，此處放在先前建立的 Cloud SQL for MySQL 相同的機房內
叢集版本：這個應該不用動
機器類型：視需要自行調整，老話一句：財力決定規格、規格決定能力

設定叢集參數（二）

節點映像檔：此案單純將 VM 當成容器載體，所以都選擇 Container-Optimized OS 這種映像檔
大小：指的是叢集大小，也就是多少個叢集節點（主機數），此處選 3 是為了後續驗證負載平衡及應用程序崩潰時是否會影響服務之用
其他參數暫時不需理會，直接按建立鈕即可開始建立容器叢集

花一點時間（聽說 Google 優化過了，現在來不及去泡咖啡了）讓容器叢集成功建立後就可在 Container Engine 資訊主頁中看到叢集的相關資訊
切換到 Compute Engine 資訊主頁中可以看到 3 個 VM 執行個體
可以直接在瀏覽器中連接 VM 進行操作，有瀏覽器就能進行管理（但好不好用要看平台，用手機相信是很難用就是了）
這是個 Kubernetes 專屬 VM，必然會看到一堆 Kubernetes 相關的容器在運作
有些網路工具像是 ping、traceroute 等等預設是未安裝的，可以透過執行 toolbox 指令另外弄一個容器來提供這些功能

安裝 Google Cloud SDK

Google Cloud Platform 雖然是以專案方式管理某項服務所需的各種資源，例如本案中的 Cloud SQL for MySQL、Container Engine 等等，但 Cloud SQL 和 Container Engine 之間並無互通，要讓 Container 能連接上 Cloud SQL 必須透過 Cloud SQL Proxy 進行轉接。目前這些設定步驟尚無法完全透過 Web UI 加以操作，取而代之必須使用 Google Cloud SDK 進行設定。

回到專案的資訊主頁，在入門指南這個資訊卡片下有一個『安裝 Cloud SDK』的連結，點擊它後即可取得各平台的安裝檔案（macOS 可以透過 Homebrew-Cask 安裝），請依指示完成 Cloud SDK 安裝。

初始化 Cloud SDK

安裝完 Cloud SDK 後需要進行初始化操作以授權存取 Google Cloud Platform，指令如下：

gcloud init

初始化過程中會透過瀏覽器進行線上認證
需同意 Google Cloud SDK 這些權限
指定預設的專案
設定 Compute Engine 預設的機房：應該是指若是透過 Cloud SDK 指令方式建立的 VM 都會以這個設定為準，這裡選 asia-east1-a
初始化完成後會提示目前登入的帳號、預設專案、以及預設機房
日後隨時可以檢視這些設定，也可以修改
```
gcloud config list
```

管理 Cloud SDK 設定檔

若有多個 GCP 專案，則重覆執行 init 指令即可建立相應的設定檔。

檢視目前已建立的專案 / 設定檔，新建立的設定檔會自動啟用。

gcloud config configurations list

在多個設定檔同時存在的情形下，可以依需要啟用所需設定檔：

gcloud config configurations activate <proejct id>

不需要的設定設定檔可以刪除，但不能刪除啟用中的設定檔。

gcloud config configurations delete <proejct id>

使用 Cloud SDK 進行管理 Cloud SQL

前面使用 Google Cloud Console 資訊主頁的各項操作都可以透過 Cloud SDK 完成相關設定，但是 Cloud SDK 之所以重要是因為它能讓管理人員在任何地方皆能連接 Cloud SQL for MySQL，此特性讓維運人員即使是在 4G 環境下仍然可以隨時檢視 Cloud SQL for MySQL 的資料庫狀況。

檢查專案中資料庫列表：

gcloud sql instances list

連線資料庫進行管理，為了讓管理人員隨時連線，Cloud SDK 需要一點時間調整防火牆設定：

gcloud sql connect <db instance name> -u <user name>

設定 Cloud SQL Proxy

雖然覺得很蠢，但目前想要從 Google Container Engine 連接 Cloud SQL 服務的話，必須另外設定 Proxy，帶來的好處是應用程式開發時使用的 JDBC 資料庫連線都是指向本機 localhost 的，和一般開發過程中直接連線本地 MySQL 狀況相似。以下說明皆依據官方說明文件進行整理，並加入個人驗證經驗。

安裝 kubernetes 管理元件

透過以下指令可以協助安裝管理 kubernetes 所需的管理元件。

gcloud components install kubectl

將 Cloud SDK 使用中的憑證授權給 kubectl 使用。

gcloud container clusters get-credentials <叢集名稱>

以下指令可以檢視 Cloud SDK 目前支援的、已安裝的元件列表。

gcloud componets list

啟用 Cloud SQL API

請透過這個連結啟用 Cloud SQL 管理 API，也可以從 產品與服務 --> API 管理員 的資訊主頁中選擇啟用 Cloud SQL API。

建立服務帳號

Cloud SQL Proxy 需要一個服務帳號串接 Container 及 Compute 平台，請從 Console 的 產品與服務 --> IAM 與管理 --> 服務帳戶 功能選項中進入，或者直接點選這個連結進入前述資訊主頁（需再指定專案 ID）。預設會有一個用於連接 Compute Engine 的服務帳號。

點選資訊主賈上方的建立服務帳戶連結，填入相關資訊後按建建立鈕。

服務帳戶名稱：用來識別帳戶用途的名稱，隨便取
角色：請選擇 Cloud SQL --> Cloud SQL 用戶端
服務帳號 ID：若有需要可以自行修改
提供一組新的私密金鑰：請勾選，並且設定金鑰類型為 JSON，在帳號建立後會下載一個金鑰檔，請妥善保存；可以使用 SERVICE_KEY_FILE 這樣的變數去記錄保存位置，之後在匯入金鑰時會參照到

取得 Cloud SQL 執行個體連線字串

透過以下指令可以取得指定 Cloud SQL 執行個體的細節資訊，此處擷取的是它的連線字串，格式是：<專案 ID>:<區域>:<執行個體名稱>，此連線字串請標記為 CONNECTION_NAME 供後續使用。

gcloud sql instances describe <MySQL Instance Name> | grep connectionName

若是 Windows 平台那就去掉 | 及之後 grep 指令，直接用眼睛找一下 connectionName 這個關鍵字。

建立識別資訊

為了讓 Container Engine 可以連接到 Cloud SQL，必須將剛剛建立的 MySQL 用戶端服務帳號匯入 Kubernets 中讓 Cloud Proxy 可以參照到：

kubectl create secret generic cloudsql-instance-credentials \
  --from-file=credentials.json=${SERVICE_KEY_FILE}

編輯 K8S 部署設定檔

在專案目錄下有一個 k8s-deploy-config.yaml 的 kubernetes 部署 (Deployment) 設定檔，可以協助在 Container Engine 中建立一個應用系統部署單位。

請修改部署設定檔中的以下設定：

第 14 行的 Docker 映像檔標籤：請確認已打包成 GCP 線上版本所需設定，格式為：gcr.io/<專案 ID>/<映像檔檔名>:<標籤>
第 20 行的 Cloud SQL 執行個體連線字串

在 Container Engine 上啟動 Spring Boot 應用程式

完成前述設定後會得到兩個檔案：一個給 GCP 啟動用的 Docker 映像檔及一個給 Kubernetes 啟動部署作業所需的設定檔。第一件事就是將 Docker 映像檔上傳到 Google Cloud Storage 中。

上傳 Dcoker 映像檔到 Cloud Storage

以下指令可將先前打包過的 Spring Boot 應用程式映像檔上傳到 Cloud Storage 中，其中 <映像檔標籤名稱> 也就是編輯部署設定檔時指定的 Spring Boot 時的映像檔標籤。

gcloud docker -- push <映像檔標籤名稱>

要確認是否上傳成功有兩個方式：

透過瀏覽器瀏覽 https://gcr.io/<專案 ID>/<映像檔名稱> （不含標籤）進行確認。
嘗試下載映像檔：若映像檔未正確上傳則會出現 not found 訊息
```
gcloud docker -- pull <映像檔標籤名稱>
```

透過設定檔啟動 Kubernetes Pod

透過指定設定檔方式啟動 Pod。

kubectl create -f k8s-deploy-config.yaml

檢查 Pods 有沒有異常

Kubernetes 在啟動服務時可以透過以下指令，經檢視 RESTARTS 次數確認 Pods 啟動有無異常？

kubectl get pods

開放 Spring Boot 應用程式供外界使用

確認 Pod 沒有一直重啟後即表示相關設定沒有問題，可以正式發佈供外界存取。Kubernets 開放服務的指令是 expose，如下例：

kubectl expose deploy <deploy name> --port=<對外開放的埠號> --target-port=<Container 實際開放的埠號> --type=LoadBalancer

<deploy name>：請參考啟動 Pod 時的輸出或是部署設定檔內的設定
<對外開放的埠號>：這個服務實際要開放給外界連接的埠號
<Container 實際開放的埠號>：在 Docker 映像檔中實際接受服務的埠號

當 service 被 expose 後，可以檢視該 service 的狀態，其中 EXTERNAL-IP 即為外界可以存取此服務的入口：

kubectl get services

實際連線可以看到 API 回覆了 Pod 的名稱：

若需要提供多個 Pods 以確保外界有機會繼續使用服務的話，可以擴充多個 deployment 。

kubectl scale deploy <deploy name> --replicas=<Pod 數量>

此時檢查 Pod 狀態會看到產生指定個數的 Pods：

經多次存取後，可以發現 Kubernets 確實將流量分散到不同 Pod 去，雖然分流的規則不明，而且還有很高機率會導向正在重啟的 Pod 去。

在此可以呼叫第二個 API 將 Container 弄壞，然後看看 Kubernetes 會不會自動重啟新的 Container 出來。

Kubernetes 日誌追查與異常排除

檢視 Pod 日誌記錄

kubectl logs -f <Pod Name> -c <Container Name>

<Pod Name> 即 kubectl get pods 時取得的 Name 欄位
<Container Name> 即部署設定檔中設定的 containers 設定中的 name 欄立

範例一：檢視 springboot 的執行日誌

範例二：檢視 Cloud SQL Proxy 的執行日誌

Spring Boot 無法連線 Cloud SQL

如果 Spring Boot 無法連線到 Cloud SQL 時必然會導致 Container 崩潰，此時的問題通常是因為先前的服務帳號沒有完整。請到 產品與服務 --> IAM 與管理 --> IAM 資訊主頁中確認先前建立的服務帳號是否被正確建立（包含該服務帳號的角色）。

若服務帳號沒有正確顯示在 IAM 資訊主頁中，請複製服務帳號內完整的 EMAIL 設定到 IAM 資訊主頁內自行新增即可，角色一樣請指定為 Cloud SQL 用戶端。

與官方作法不同處說明

在 Cloud SQL Proxy 時並沒有建立 cloudsql-db-credentials 這個識別 (secret)，這是因為這邊是由 Spring Boot 應用程式提供資料庫連線的帳密
若想將資料庫帳密放到 識別檔 (secret) 內的話，可以參考 cloudsql_deployment.yaml 這個範例設定部署檔

參考文件

後續的驗證與調整

有空的話會來驗證一下這些操作...

如何更新應用程式版本：目前不知道是不是只要上傳新的映像檔即可？
如何真正達到服務不中斷：Kubernetes 預設的分流規則會把流量導向隨便一個 Pod，即使該 Pod 正在重建立，此時就會出現系統無回應的錯誤訊息
打開 Dashboard：據說檢視 Kubernetes 運作狀態好方便... ？

關於 Load Balancer

標準型（就上面那個例子）的 Load Balancer 是沒有做 Healthy Check 的，所以導致前面說到的經常性的把流量導到掛掉的那個 Pod ... XD
Ingress 的 Load Balancer 似乎有相關的 Healthy Check ，還支援跨區域的分流 XD

Chrome 擴充功能 - Plus Plurk 介紹

2011-08-12T17:55:00.037+08:00

※本 Chrome Extension 已廢止，感謝大家支持，造成不便懇請見諒！

基本上這是一個協助格揆我將發佈在 Google Plus 上的訊息同步到 Plurk 的 Google 瀏覽器擴充套件 / 功能。原本只是格揆個人單純在同步文字訊息使用，但是經過一陣加油添醋式的亂改後覺得也許可以開放給 Google Plus 及 Plurk 的重度使用者試看看，於是就把它上到 Chrome 線上應用程式商店了。

開發源由歷程

當不小心偷渡進 Google Plus 後，格揆一度因為專心在 Google Plus 上打混而幾乎放棄了在 Plurk 上的活動，此作為連帶使得卡馬值在短短幾天就從 98.x 掉到 97.y，在發現這種情形時原本一度考慮要使用凍結卡馬的方式來欺瞞自己。但此刻一個由 Google Plus 同步訊息到 Facebook 的 Publish Sync 擴充功能上線到線上應用程式商店，經過簡單試用後就有了『不然我也來寫一個從 Google Plus 將訊息同步發送到 Plurk 的擴充功能』的念頭並真正的開始研究 Plurk API ，隔了幾天後突然到 Chrome 線上應用程式商店付了 US$5 的入場券，然後還拗了他踢幫忙拉了一個 ICON，最後還賺了一場由火焰銘王提供的美國隊長電影，終於在 08/02 開始了募集測試人員的測試流程，然後就是因為一時恍神而在 08/11 莫名其妙的正式把它給弄上 Chrome 線上應用程式商店。

核心思想

和 Publish Sync 的規劃不同，這個擴充套件是基於使用者以 Google Plus 為唯一發言人，並想將相關資訊散佈到 Plurk 上的散播模式而開發。換句話說如果您是希望以 Plurk 為主要發言來源，但想將訊息同步到 Google Plus 上訊息傳播模式的話，那這個套件就不會適合您的需要。在安裝前請先理解此一核心思想所造成的設計上的差異。

功能特色

本擴充套件 / 功能的主要特色如下：

直接對 Plurk 發送訊息：所有的訊息都直接對 Plurk 進行操作，訊息分享沒有延遲
訊息分享限制：本擴充功能支援『僅限朋友閱讀』之私噗模式，也能設限回噗對象的範圍
訊息分享格式：依訊息內容的差異，提供 5 種轉噗到 Plurk 上的訊息格式
訊息長度預覽：Plurk 屬微網誌系統，本套件可以預判訊息長度，提前避免傳送失敗的情形
多段訊息轉噗：擔心個人感想太長無法轉送到 Plurk 嗎？沒關係，只要您分段得宜，本套件會自動將各段轉成回噗送上 Plurk

安裝與授權

本套件為 Google 瀏覽器 Chrome 所屬的擴充套件，如果您尚未使用 Google 瀏覽器可以在 Google 瀏覽器產品頁面下載安裝。另外提醒的是 Google 瀏覽器安裝並不需要系統管理者權限，只要作業系統為 Windows XP 以上的使用者都能直接下載安裝。

安裝 Plus Plurk

請使用您已安裝的 Google 瀏覽器連接到 Plus Plurk - Chrome 線上應用程式商店上並按下『加到 Chrome』按鈕即可，如附圖：

權限要求

本擴充功能僅存取以下三個網站資料：

www.plurk.com: 將資料傳輸給 Plurk
plus.google.com: 擷取在 Google Plus 上預定發佈的訊息、在 Google Plus 上啟用本擴充套件
www.googleapis.com: 將預定分享到 Plurk 的網址預先進行網址為 http://goo.gl/xxxxx 之用

重新載入 Google Plus

完成安裝後套件會自動將相關程式載入 Google Plus 頁面中，不過您也可以重新載入 Google Plus 頁面，確保相關程式正確的嵌入 Google Plus。只要相關程式已正確嵌入，那麼在輸入訊息時會在分享鈕右側看到多出一個 Plurk Share 圖示。但是因為目前還沒有取得 Plurk 服務授權，所以此刻暫時無法點選。如附圖：

取得 Plurk 服務授權

套件安裝後會自動開啟 Plus Plurk 選項設定頁面以利噗友進行 Plurk 服務授權，另外您也可以按下 Chrome 右上角的 Plus Plurk 圖示，它會直接開啟 Plus Plurk 選項設定頁面，如附圖：

點選『進行授權』鈕後會開啟 Plurk 服務授權存取頁面，不同意的話是沒辦法發送訊息給 Plurk 的喲~~

授權完成後會自動關閉該頁面回到 Plus Plurk 選項設定頁面，其中『授權狀態』欄位會變更為『已完成授權』，同時『授權人』欄位會取得 Plurk 的使用者名稱資訊，如附圖。特別注意的是一旦更換電腦，這個授權動作就要執行一次！

如果授權後發現授權人的名字不是您的名字請先登出 Plurk 後再重新進行授權；如果這是一台公用電話的話請在使用完畢並登出 Google Plus 後一併記得登出 Plurk 及清除 Plus Plurk 授權設定（請注意：Plus Plurk 並非透過 Plurk 帳號及密碼登入 Plurk ，故光是登出 Plurk 並不會取消 Plus Plurk 存取 Plurk 的權限），清除授權設定後則『受權狀態』欄位會恢復為『尚未授權』，如附圖。

一般使用

Plus Plurk 只要完成 Plurk 服務存取授權後，就可以將訊息同步分享到 Plurk 上。不管是心情碎碎念、文章心享、心得感言、照片紀念、還是影音記錄等等等，只要沒有超過 Plurk 內文長度限制，Plus Plurk 都可以幫你噗到 Plurk 上。以下都是將 Google Plus 上輸入的資訊與 Plurk 實際獲得的噗文結果合併後的圖例。

心情碎碎念 / 純文字訊息

心得分享

純文章分享

與『心得分享』最大的差異就是... 沒有心得... (被毆)

內嵌文章分享

0.3.2.2 調整功能

如果是 Plurk 支援的文章連結，則 Plurk 會以部落格區塊轉貼方式呈現，如附圖。

目前 Plurk 支援的 oEmbed 網站列表如下（請參考 Plurk Labs (Chinese)）：

YouTube
Vimeo
Slideshare
Wordpress.com
PIXNET痞客邦部落格、相片/相簿
未來事件交易所
ted.com
itunes.apple.com
Flickr
scribd
Xuite 隨意窩部落格、相片/相簿
蘋果日報新聞

圖片分享

噗文管理

Plus Plurk 一開始預設的 Plurk 訊息是可在河道上自由被檢視及回噗的，但是人生總有些訊息並不想如此大方的公開或是讓人家插花回覆的，有一些開關可以應付這方面的需求。

檢視限制

可以選擇是公開給所有人檢視或僅朋友能檢視。

回噗限制

可以限制是否同意任何人皆可回噗，僅限朋友可以回噗、或完全不能回噗！

同步限制

0.3.1.0 新增功能

應該有不少噗友是利用 Plurk 提供的 Facebook 同步功能將訊息同步到 Facebook 上的，而 Plurk 其實也提供了如何不同步到 Facebook 的方式。Plus Plurk 自 0.3.1.0 版起也提供了指定是否開放讓 Plurk 自動同步臉畫的選項開關，如附圖。

訊息格式管理

和 Twitter 不同（應該吧），Plurk 本身並不是純文字型態的微網誌系統，因此 Plus Plurk 在分享訊息到 Plurk 時依訊息種類提供不同的訊息分享格式。這些設定可以在 Plus Plurk 的選項設定頁中進行修改，修改完後記得要『儲存』後相關設定才會生效。至於那些變數所對應的資料項目可透過點選符號查閱之。

戳記：在 Facebook 上我們可以看到每一筆訊息的來源為何，但是 Plurk 上卻沒有這方面的設定，所以格揆很堅持的希望在 Plurk 上能一眼的看出來這筆噗文的來源為何。它的預設值為『[fr. G+]』，但因為會佔用到噗浪內文的空間所以格揆已自行改成『[G+]』，您也可以直接設為空白。
訊息 / 純文字分享：如果某筆訊息沒有包含文章連結、影像連結、或圖片連結時，視為單純的訊息分享。此時能使用的變數只有代表訊息的 ${MESSAGE} 及戳記 ${STAMP} 兩種。
心得分享：為預設的分享模式，一份完整的心得分享中會包含個人的心得、感想（${MESSAGE}）、文章連結（${LINK}）、文章標題（${TITLE}）、以及文章圖片（${PICTURE}）。
內嵌文章分享：針對 Plurk 能自動讀取特定網站資訊所採取的對應格式，只需文章連結（${LINK}）即可由 Plurk 自動帶出連結網址標題及第一張圖片。
文章分享：少了個人心得、感想（${MESSAGE}）的訊息分享屬之。
影片分享：目前以連結 ${LINK} 為 Youtube 或 Vimeo 的網址時視為影片分享，Google Plus 在捉取影片資訊時會提供影像連結（${LINK}）及影像擷圖（${PICTURE}）兩種資訊，由於 Plurk 也會自行捉取影像內的資訊，故通常不會使用到影像擷圖（${PICTURE}）這個變數。
圖片分享：當訊息中不含文章連結（${LINK}）及文章標題（${TITLE}）時即屬圖片分享。您可自行決定圖片要放前面還是放後面。

另外『${DESCRIPTION}』這個變數主要是指一篇文章或影片的內容描述，但因為它本身經常超出 Plurk 內文的上限，所以不建議各位使用。

0.3.3.2 新增功能

自 2011-08-23 起 Plurk 支援訊息斷行顯示，因此在格式設定上也新增了斷行的符號『|』，如上圖中的『訊息分享』即使用了這個斷行符號，斷行的輸入範例如下圖：

需要特別注意的是 Plurk 官方允許的斷行行數是 4 行，如果在格式設定中使用了斷行符號『|』，那麼實際能輸入的訊息行數就只剩下 3 行，下圖即為超過上限行數時的檢查結果，出現第 5 行的原因就是因為 | 多產生了一行戳記（${STAMP}）列所導致。。

多段式噗文

因應 Plurk 單則訊息 140 個字的限制，Plus Plurk 支援將訊息分成數段噗在同一筆噗浪主文下成為回噗。但這並不是自動分段，Plus Plurk 的分段依據是透過使用者預先安排的。

Plus Plurk 在處理 ${MESSAGE} 時會針對連續兩個 ENTER 鍵進行訊息切割，訊息切割之後再依序將訊息內容送往 Plurk 河道，這個發送的時間間隔是每秒一筆，以下介紹的兩種應用方式，它們之間的差異只在於有沒有先空個兩行再輸入個人的心得或意見而以。

訊息長度檢測

有時候在下筆如神助、文思如泉湧時的摸門特是很難有心思力氣去一個個數每一段落各有多少字。每次數的結果都不一樣也就罷了，就怕是還沒數完前就讓原本澎湃的思緒化為枯竭的溝流，這樣怎麼有資格當文青呢？

沒關係，Plus Plurk 可以透過某種不明確、不科學、沒有保證的計算公式提前告知這一篇文章中最長的那一段總共有幾個字，如附圖。特別注意的是這裡的第一段指的是文章的連結、標題、文章內附圖的連結等等的綜合計算結果，並不是心得部份的文字字數。

另外這個燈泡的顏色會隨著文字長度是否超過 140 字上限或是 Plurk 斷行上限而變色，綠色（通常）表示可安心噗文，紅色（幾乎確定）表示有某一段訊息過長或行數過多請予修正。特別注意的是這個檢查結果並不會阻止『分享』鈕的功能，而 Plus Plurk 在收到 Plurk 拒絕噗文的回覆時則會停止後續訊息的發送以便有辦法一行行手動將訊息補進河道內。

常見問題與說明

問：為什麼在 Google Plus 上明明只是換行，但在 Plurk 上卻成多段式噗文呢？

這通常是發生在訊息內容是從剪貼簿貼到 Google Plus，Google Plus 雖然顯示上看起來像換行，但實際上捉出來的訊息卻是每行一段，故轉送到 Plurk 時就變成多段式噗文了。

成果示範

在本文剛撰寫時格揆提過當時的卡馬值一度落到 97.y ，經過本套件的協助後在三週內竟然已提升到 99.81，您看看，這套件是不是真的很有用？~~廢話！老是把 Google+ 上的資料倒進 Plurk 當然會提高卡馬值啊，而且三週才提升 2 似乎有點...~~

多語系支援

目前並未支援其他語系，非常歡迎有意願者協助翻譯！

感謝

感謝以下網友介紹本擴充套件：

就是教不落：Google Chrome擴充套件【Plus Plurk】同步Google+訊息到噗浪，支援圖片及影片連結
于老師教室討論版：好用的Google Chrome同步擴充---Plus Plurk
WEBOK部落格：省時省力的社群與微網誌訊息擴散行銷技巧
Tech - Kuma：同步你的社群網站 - Plus Plurk

改版記錄

一個恐龍法條 + 一個愛現的官僚 = 什麼？

2011-07-25T15:23:00.001+08:00

基本上這原本是在 Google+ 上針對台北市政府法規會與 Google 對 Android Market 7 日鑑賞期事件所留的一段心得，不過因為近日又多了一點心得，加上北市府額外奉送的兩週延議期也快到了，所以趁機把它搬到部落格中作為歷史遺跡，順便為這個荒廢多時的部落格灌點水... :p

整個故事的發展演進請直接參閱『Google Android Market、Apple App Store 7日鑑賞期事件懶人包』及『北市府裁罰事件，Google：法律解讀有疑慮，app 繼續下架』兩篇文章說明而不再贅述，以下即為個人的看法：

台灣消費者從此與世界豐富的應用程式無緣
和中國一樣出現一大堆山寨版應用程式在電信公司的市集上騙錢
因為台灣看不到付費軟體，所以也不會有人幫作者翻譯使用者界面為正體中文
iPhone/iPad 使用者也不用太高興，別以為世界各地的應用軟體開發者就會認同或支持台灣 Apple Store 的特別條款；也不要天真的以為 iOS 軟體開發者都有那種力氣來面對、統計、或處理台灣的退費條款_{（狀態可能有所改變，容後述）}
以目前的狀況來看，恐怕也讓某些原本想要寫 Android App 的開發人員陷入躊躇不前的困擾中，iOS 的開發人員可能就稍好一點，至少可以樂觀的相信被退款的機率應該不會太高。但總體來看似乎並不利於行動應用軟體業的發展
免費軟體的使用一併受到影響：這是近日的感想，應該也會是 iPhone 軟體開發者比 Android 軟體開發者有利的地方

基本上到了 07/15 後，Apple 正式增列台灣專屬條款『您得自產品收受之日起七日內，取消對產品之購買。在您通知iTunes您已刪除產品所有備份之前提下，iTunes將會退還您已支付之價款。自您取消購買時起,您不再被授權繼續使用該產品。此項權利不可拋棄。』，但是軟體內 (In-App) 購買、訂閱部份目前看來是無法退費的。這個差異可能會轉移軟體開發者對於軟體功能的規劃：『表面上是免費軟體，但是多數功能都要另行在軟體內付費啟用』，而且此作法某種程度下還能對抗盜版軟體。

有趣的地方就在這兒，在 iTunes / Apple Store 下雖然付費軟體有七日退費條款，但是開發者可以讓軟體免費下載，之後再透過 In-App 方式付費購買擴充功能，這些付費功能無法退費，所以 iOS 開發人員其實也不見得需要特地處理台灣地區軟體的退費事宜；但與過去比較起來消費者可能會發現連寫信退費的權利恐怕也沒了。

Android Market 也提供所謂的 In-App 付費功能，也有許多軟體開始透過此付費模式提供購買特殊裝備或啟用特別功能（個人覺得這些也算是騙子軟體），不過因北市府法規會介入的關係導致 Market 整個付費功能被 Google 關閉後，自此每次在開啟這類具 In-App 付費功能的軟體時就會看到一個很刺眼的訊息：『Can't make purchases』且一而再、再而三的提醒台灣的使用者因為一個愛現的官僚所造成無法付費購買軟體的窘境。

距上次北市府美其名對 Google 釋出善意再給兩週寬限期的時間又快到了，不知道這個號稱天龍國的地方政府有沒有任何方案足以應對 Google 不接受七日退費期費要求的因應作為？

還要用 Google 有挾消費者以令天子之嫌 那招開罰嗎？

其他討論：

小歪碎碎念: 2011-06-27 偉哉台北市政府幹掉了Google台灣的Android Market付費區
INET6 - 對Google關掉台灣Android Market付費App下載的觀察
連 Market 都有這種東西 - 抗議臺北市政府干預Android市場

本格文章詞頻分析

2011-03-23T16:29:00.000+08:00

看了 timdream 的文字雲工具後，也把這個部落格的資料給餵進去看看，然後就出現了以下這個分析圖...

簡單的說，格揆我對『可以』這個詞兒的使用頻率實在太高啦~~ 同時這也更加明確的確認出這個部落格確如其名的只是一份胡思亂想鬼扯蛋的雜記而以...

智慧型手機綁約方案選擇

2011-02-19T23:45:00.028+08:00

電信業者透過一定程度的補貼手段以爭取用戶的方式其來由自，但早期功能型手機世代時其實並不是那麼划算而在這方面沒有太多的困擾。但是直到 iPhone 3G/3Gs 登陸台灣後，因為合約中綁定了無線數據上網的部份，所以開創了鄉民們針對電信業者智慧型手機綁約方案的研究與心得整理。這一篇也是網海中注定會浮沉的一個片段，但在它還尚未沉沒前應該還是有一絲絲的參考價值... 吧！

同手機、同上網資費但不同話務資費比較

格揆我曾在噗浪/Plurk 上隨手寫了一段綁約資費方案的選擇條件，這篇文章算是進一步對這些條件加以說明。先來看看當時留的選擇條件如下：

網路使用習慣：隨時隨時要取得朋友的各種資訊、只需要行事曆/天氣/郵件通知、還是完全不使用
各資費下的總支出金額：並不是低資費就一定會繳的少
該資費下的免費通話量：有些資費方案是能月租折抵通信費用，有些甚至是直接贈送固定金額的通信費用
個人的通話量：把自己過去 6 個月的平均通話量套到前述條件內，看看那一個方案的額外花費最少。

前兩個條件很容易數據化，下表即為假設在中華電信辦理 iPhone 4 32G 手機，選擇 mPro 950 上網吃到飽方案時（即前述第一條件）分別選擇大家講-589及大家講-289（前述第二條件）時不同資費的支出試算。這個試算表中把話務月租費分成兩段的原因在於某些優惠方案可以在滿足一定月份（通常是 12 個月）後調降話務月租費，不過此表中的這兩個 iPhone4 超值方案都無此選項。

至於數據上網月租費方面也有分吃到飽和限量飲食的選擇，由於 mPro 950 是屬於一個價碼吃到飽的模式，所以上、下限都是 NT$950 元打八折的 NT$760 元。

仔細看看這份試算表可以發現：雖然表面上看來『大家講-289』方案的每月支出只要 NT$1,049 元，但若加上手機費用及預繳折扣後反而比『大家講-589』方案的總支出要再貴上 NT$500 元。這就是為什麼網路上及格揆我所一再強調的 並不是低資費就一定會繳的少 的原因啊！

這裡簡單說明一下各項數值的來源吧，然後就可以看看其他幾種方案的比較。當然如果覺得這些數據有什麼疑問之處歡迎一起討論。

話務月租費總支出：就兩年下來總共要繳多少通話費
數據上網月租費總支出：一樣是指兩年下來總共要繳多少上網費，不過因為某些上網方案並不是吃到飽的，所以這裡分成上、下限兩個數據。注意：通常這個上限值不應該發生才對。
購機準備金：這是指要領到手機所必須先付出的費用，通常是手機優惠價加上購機預繳費用。若電信公司有推出免預繳方案（通常是 VIP 或 NP）時，購機準備金就會降低。不過看了幾個方案後發現電信公司不管什麼方案要準備的預算都一樣... XD
綁約期內月支出：這是指帳面上每個月要繳給電信公司的費用，但是目前這個試算表沒辦法精確區分出話務費及上網費都會變動的情形。例如，如果話費為先 589 後 289 而上網費則是先 450 後 950 時，這個試算表只會捉出下限為 289 + 450 = 739 的數字而不是實際的 589 + 450 = 1039 這個數值。
綁約期內總支出：話務月租費總支出 + 上網費用總支出 - 預繳贈送金額。中華電信以前的方案是折抵預繳金額的 20%，現在的方案只剩下 10% 而以。
賣出價格：若綁約所取得的手機不為自用的話，可以透過售出方式減少費用支出
另購新機價格：若把綁約手機賣了又需要另一隻手機的話，就得另外花一筆費用。6. 和 7. 之前的價差即俗稱為洗機所得，後續會談到
洗機後最低總支出：洗機的目的是要壓低約期內的總支出，所以此處就只考慮最低總支出費用

同資費但不同手機間比較

上一段內容是以同手機但不同資費作為比較，這段則改成同資費但手機分別選擇 iPhone 4 32G 及 HTC Desire HD 時各自會有什麼不同？

基本上 HTC Desire HD 的空機價格本來就比 iPhone 4 32G 要便宜 NT$8,000 上下，所以單單從總支出來看的話選擇 HTC Desire HD 一如預期的必然會比選擇 iPhone 4 32G 的花費要少。但是不對啊？為什麼 HTC Desire HD 的總支出只比 iPhone 4 32G 便宜約 NT$1,000 而以呢？不是說價差約 NT$8,000 嗎？於是有人想到了是不是可以辦 iPhone 4 32G 後，把 iPhone 4 稍微降個價、打個折賣了再到通訊行買隻 HTC Desire HD 來貼補一下月租費的支出呢？

是啊，這方式就是大家常常聽到的洗機。又因為有電信公司是否受制於各家手機制造商的微妙關係，iPhone 系列手機通常會享有電信公司較高的貼補金額，這也是為什麼網路上都建議洗 iPhone 的原因。

下表就是以中華電信『大家講-589』為基礎，在分別選擇 iPhone 4 32G 及 HTC Desire HD 時的各項支出數據。其中 iPhone 4 32G 空機價依 PChome 報價為 NT$32,900 元，但為了要能脫手以免造成庫存壓力（什麼跟什麼啊）所以此處料敵從嚴的把售價訂在 NT$25,000。當然兩者間的差距不算小，能夠賣的愈高價則所能貼補的月租費就愈多，總支出也會跟著下調，這部份就要看個人機運了。如何賣掉 iPhone 的方式很多，不少人是透過網路拍賣進行競價，但是也有部份的人因為懶惰或其他原因而選擇直接把手機賣給通訊行吧？至於 HTC Desire HD 也依 PChome 報價的話是 NT$20,900 元，不過通訊行的價格應該不會這麼硬才對！

其他不同方案的比較

這篇是以智慧型手機綁約為前提所寫的介紹文，那麼有沒有單純針對通話為唯一要件的方案建議呢？

答案可能讓人失望，格揆我會建議 直接用空機價格購買功能型手機，然後向電信商辦理通信費用補貼 即可。

以下繼續對各種不同基礎所進行的方案比較，但各比較表僅僅只能作為參考、計算示範之用。任何方案的付費細節請參閱各家電信公司官網或聯絡其客服以取得最新、最正確的資訊。

是否一定要選擇 mPro 950 吃到飽方案實際取決於每個月的上網傳輸量是否僅少量甚至是不超過方案上限值。不過可以確定的是如果有 7 個月以上因傳輸爆量達 mPro 450 收費上限 NT$1,200 的話，那麼選用 mPro 450 的費用支出就會開始超過 mPro 950 了。

如果比較一下各家電信業者的資費方案，可以做為是否 NP 的決策。不過各家對 NP 的補貼倒是不一定能享受到就是了！另外這份表中的遠傳資費不一定正確，因為格揆不太瞭解遠傳資費的解讀方式，有可能因為認知錯誤給了一個不正確的數值。

結論

其實整個評估作業最簡單的方式不過就是計算月租費及手機費用的總支出，少數電信公司的預繳費用會有更多的折扣，那就再扣除這些多的折扣就是最終取得手機的實際支出。聰明的你應該馬上能計算出自己所需的優惠方案了吧？

追加報導 - 《中華電信 - 平板＋智慧新機成對帶著走！「天生一對」方案》

個人看法：

個人覺得綁約三年的各種合約都儘量少碰，尤其像手機這種半年就一款旗艦機的情形下更沒有再堅持一年的必要性
mPro 450 每月有 500MB 的額度，和 mPro 750 相比上限值雖然多 NT$100，但是一般以 WI-FI 環境為主的情形下月租費卻可以少掉 NT$300，個人認為是買空機情形下比較划算的選擇
個人認為如果真有行動平板電腦的需求，透過洗手機（目前效果差很多）的方式可能比較划算
對了，除非辦了兩組上網門號，不然 Flyer 要上 3G 時要拔 SIM 卡進行交換... XD

次世代主機的體感創意落差

2011-01-28T15:22:00.000+08:00

我是看了『老任第三季營收掉了46個百分比，狂賣缺貨的日子已是往日榮光？』這篇文章時突然覺得老任營收會下調營收預測似乎是必然的，畢竟這是一台老主機，加上 XBox 360 Kinect 的出現明顯搶了 Wii 的風采。

以下是格揆我對三大主機在體感創意方面的自我主張，大家可以參考參考：

任天堂 Wii Remote/Remote Plus：這玩意兒無疑是對體感遊戲的可能性具有重大貢獻，但是年代已久早顯疲乏；不過在某些需要精準控制的遊戲需求上仍有其重要性存在。
微軟 Kinect：可視為自 Wii Remote 發表以來的重大演進，不光是少了遊戲過程中額外控制器的需求，還能被應用在各種肉人體動作補捉上。
索尼電腦娛樂 PS Move：雖然看來有一些和 Wii Remote/Remote Plus 不同的運用方式，但原始創意來源怎麼看都覺得是抄自任天堂的，所以目前看不出有何氣勢似乎也是很合情合理的。

所以，格揆我不小心在過年前從電腦家訂了一組 XBOX 360 + Kinect 同綑包要回家孝敬爹娘了... XD

如何在 Shell Script 中捉取 MySQL 資料庫中的指定記錄值

2011-01-19T17:52:00.004+08:00

很久沒寫 Blog 了，也許是因為撞牆期吧？

總之，來寫個跟 Shell Script 及 MySQL 有關的東西吧：如何在 Shell Script 中直接取得 MySQL 資料庫中某記錄的值！

需求起因

事情的發展是這樣的：為了確保系統發出的 EMAIL 能有效的送達用戶手上，所以懶人如格揆我就很順手的把 /var/log/maillog 中的郵件寄送記錄給解出來了，反正不需要我每天動手做的任何方式都是最佳的方式。但是，代誌毋係憨人想ㄟ哈呢甘單，沒多久就有人寄信來希望能加上信件主旨，於是格揆很快的又回到每日人工查資料的機械生活中，這完全是忤逆懶人天性，違乎常理的發展啊。

就因為『懶散要超越懶散』，格揆我其實一直希望能把這動作併入 Shell 中自動補完，終於在今天找出了正確的解法，先記錄一下以免腦殘之後忘了該怎麼辦！

編碼問題

在讀取資料庫中的資訊前有一點很重要：系統編碼！

mysql> status
--------------
mysql  Ver 14.12 Distrib 5.0.77, for redhat-linux-gnu (i686) using readline 5.1

Connection id:          2468601
Current database:       *** 不要問 ***
Current user:           *** 很恐怖 ***
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         5.0.86-community-log MySQL Community Edition (GPL)
Protocol version:       10
Connection:             *** 您知道的 ***
Server characterset:    latin1
Db     characterset:    utf8
Client characterset:    latin1
Conn.  characterset:    latin1
TCP port:               3306
Uptime:                 428 days 21 hours 44 min 57 sec

Threads: 8  Questions: 115577998  Slow queries: 8  Opens: 81015  Flush tables: 1  Open tables: 64  Queries per second avg: 3.119
--------------

如果登入 MySQL 時看到了像是上圖中顯示了不同的編碼狀態，那麼任何 select 到的中文字都會變成亂碼！這問題不難處理，在使用 MySQL Command line Tools 加上 --default-character-set=encodename 即可，如上例即應改由以下方式登入 MySQL：

[ada@myhost ~]$ mysql --default-character-set=utf8

加上了預設編碼設定後後，再到 mysql 命令列工具中下達 status 指令就會看到編碼設定已經被改過了，如下：

Server characterset:    latin1
Db     characterset:    utf8
Client characterset:    utf8
Conn.  characterset:    utf8

Select 取值方式

之前在對 Oracle 進行操作時，它有提供如何在 Shell 中去讀取資料庫內容的作法，這裡用讀取資料庫系統時間作為例子：

[ada@ora ~]$ NOW=$(sqlplus -s << END
> set heading off
> set feedback off
> select sysdate from dual;
> exit;
> END)
[ada@ora ~]$ echo $NOW
2011-01-19 17:02:48

但如果想要在 MySQL 中如法泡製的話，輸出結果顯然需要額外再加工才行，如下所示：

[ada@myhost MYSQL]$ NOW=$(mysql --default-character-set=utf8 --silent -E <<END
select now();
END)
[ada@myhost MYSQL]# echo $NOW
*************************** 1. row *************************** now(): 2011-01-19 16:40:25

靠杯，為什麼兩台的時間差這麼多？

還好 MySQL 另外提供一個方式可以讓我們只看到實際輸出資料而沒有欄位名稱什麼的，如下例：

[ada@myhost MYSQL]$ NOW=$(echo "select now()" | mysql --default-character-set=utf8 --silent)
[ada@myhost MYSQL]# echo $NOW
2011-01-19 17:07:56

好啦，想要在 Shell 中去讀取 MySQL 中的某個值就是這麼簡單。如果要撈的是多筆、多欄位的資料呢？沒有問題，系統會用空白串接所有擷取出的欄位值，這樣會比較難處理，但它確確實實還是能夠加以操作。

[ada@myhost MYSQL]# LIST=$(echo "select status, time_start, creator from epaper" | mysql --silent)
[ada@myhost MYSQL]$ echo $LIST
0 2012-08-03 00:00:00 admin 1 2010-09-01 00:00:00 admin 0 2011-09-08 00:00:00 admin 0 2011-09-03 00:00:00 admin 1 2010-10-02 00:00:00 admin 1 2010-10-05 00:00:00 admin 1 2010-10-05 00:00:00 admin 1 2010-10-05 00:00:00 admin 0 2011-11-11 00:00:00 admin 1 2010-11-03 00:00:00 admin 0 2011-11-05 00:00:00 admin 0 2011-11-07 00:00:00 admin 1 2010-11-05 00:00:00 admin 1 2010-12-01 00:00:00 admin 1 2010-12-02 00:00:00 admin 0 2012-12-06 00:00:00 admin 1 2011-01-15 00:00:00 admin

其實也可以改成以下這樣啦，只不過這樣會多出欄位標題出來，需要自行濾除...

[ada@myhost MYSQL]$ mysql --default-character-set=utf8 --silent -e 'select status, time_start, creator from epaper'
status  time_start      creator
0       2012-08-03 00:00:00     admin
1       2010-09-01 00:00:00     admin
0       2011-09-08 00:00:00     admin
0       2011-09-03 00:00:00     admin
1       2010-10-02 00:00:00     admin
1       2010-10-05 00:00:00     admin
1       2010-10-05 00:00:00     admin
1       2010-10-05 00:00:00     admin
0       2011-11-11 00:00:00     admin
1       2010-11-03 00:00:00     admin
0       2011-11-05 00:00:00     admin
0       2011-11-07 00:00:00     admin
1       2010-11-05 00:00:00     admin
1       2010-12-01 00:00:00     admin
1       2010-12-02 00:00:00     admin
0       2012-12-06 00:00:00     admin
1       2011-01-15 00:00:00     admin

[ada@myhost MYSQL]$

五都選舉馬後砲

2010-11-28T23:03:00.004+08:00

前言

台灣首場五都首長選舉已於 11/27 晚上拍板定案，就上榜率而言藍軍以過半的 60% 大勝綠營的 40%，但以得票率來看的話則是綠營以近 5 成的 49.87% 大勝藍營的 44.54% 共 40 餘萬票。於是照慣例，格揆我一定要放個馬後砲留點紀念，反正格揆我也只會放放馬後砲以免惹上意圖使人不當選（沒想到它還是目前的 Google Suggestion 呢）的麻煩。

台北市

就個人情感上對台北市是希望蘇貞昌當選的，不過個人一向對天龍人的民主養成教育沒啥信心，選舉結果也如預期般由在新生高及花博等工程中浪費人民血汗錢的現任市長連任。對司法一向沒啥信心的格揆我也只能說這些爭議案件都將不會有什麼結果了。

另外蘇貞昌在整個竸選期間曾親到台北市各處探查民情，但似乎找不到類似個 Issue Tracker 的問題追踪系統並公開給大眾監管執政者是否已解決問題？個人倒是挺建議蘇這邊把相關資料整理後移交給民進黨台北市議會黨部（或是移交給 TBA 也行？），不只可以讓議員們持續追踪這些問題，搞不好四年後還能用來翻舊帳呢！

對了，每次看到好冰冰市長的台北起飛、Fly High 選舉手勢時總會莫名其妙的想到國家地理頻道中的空中浩劫節目，為什麼？因為空難事件絕大多數都發生在起降時刻呀~~

新北市

老實說在過去民進黨多任縣長的先例下，本來並不覺得新北市是一個藍色為主的政治環境，但從此次的選舉結果看來新北市大概就此被劃入藍色版圖內了吧？

至於對這兩位候選人而言，個人沒有太多意見。對小英而言其實本來就不太贊成她出來竸選，至於老是批評小英是選假的的朱市長個人則覺得實在過於小鼻子小眼睛就是了。讓一個現任的新北市長去選總統搞不好可以讓任內已規劃的所有建設一次到位，對新北市民搞不好受益更多呢！再說為什麼每次都只能由選台北市長的人去競選總統呢？這明顯是對其他縣市的一種歧視嘛...

不過，其實北二都失守也不一定要那麼悲觀到又要勞駕精神科醫師 Billy Pan 大叔再辦一次療傷網聚啦，阿Ｑ點想，也許這是因為北二都的民眾們比較希望兩位市長候選人能專心準備 2012 總統大選也說不定呢～

台中市

個人是覺得台中市最近幾年實在是沒啥發展，不過反正又不住那邊所以不需要太過在意。只是這次再由胡志強當選讓人好奇台中市民過去九年來對胡市長的臉都不覺得膩嗎？

說到胡志強他這次猛推不少競選廣告，吹牛被捉包的就不管了，反到是在大台中大未來所提的 與香港競爭、追趕新加玻 （這樣看起來新加破贏香港）口號應該先問問胡市長把台北市放那邊去了吧？

另外胡市長還有一個在競選末期某幾天內曾強力放送的廣告中不知為何總覺得他口齒不清，不知原因是不是我耳朵生繭的關係？

台南市

基本上我對這兩位候選人都不熟悉，但比較想說的是台南縣蘇縣長接受初選結果且即表態支持黨提名人這件事比較有印像；而許市長雖然最後也放棄脫黨參選，但總覺得他本來也想循高雄縣長模式脫黨的，只是不知什麼原因使其放棄而以！

高雄市

對高雄市而言比較有印象的並不是花媽陳菊，反倒是脫黨參選的現任高雄縣長讓人印象深刻。雖然他後期極力訴求不分藍綠、政治中道的企圖明顯，可惜顯然大家對他的『昨是今非、昨非今是』非常有意見。但在這種情形下仍有 40 餘萬票其實力也算是異常雄厚，只不過我覺得他這次真的是賭輸了，未來如果想再走政治這條路應該是會異常艱困吧？

政治光譜的改變

在假圖天圖有篇【台灣觀察】藍綠光譜的改變! 提到現今的政治光譜已不光是藍綠而以，由於騜式詐騙集團的快速傾中導致這群詐騙集團的政治光譜比較像是紅色而不是國民黨黨徽上的藍色。本來以為在六年級上段班之前這些受過國民黨反共抗俄教育的這一代應該會全力反抗騜的傾中現象，不過實際上看來似乎還有很多人只是單純的效忠黨徽而不是去看領導人有沒有在亂搞的嘛，顯然過去國民黨的愚民教有真是成功呢！

大話新聞

呃，大話新聞不屬於五都的成員，只是因為就幾次選舉下來發現大話新聞的成員總會認為騜式詐騙集團即然這麼糟糕，相信所有台灣人都已經覺醒，必然會給騜一個嚴正的教訓！但每次的期昐的結果總是與預期相去甚遠，這究竟是什麼原因呢？也許就只是別高估台灣民主教育成就而以吧？

意圖使人不當選

以下是網路上討論到的相關文章：

選後第三天最新心得

今天聽說民進黨那些老灰呀全部跑出來批評小英，呃... 這群人實在該乖乖退休比較好...
還有人批評都是蘇光頭執意參選台北市長才會打亂原本的必勝配置，呃... 我也不認為新北市民願意看到回鍋的新市長...
個人一直不覺得那顆子彈對選情有啥影響，不過似乎全台灣都認為影響可大了？

Maven、Java 1.5 與 xdoclet 的相處之道

2010-11-26T16:41:00.004+08:00

最近幾年來的 Java 專案都使用 Maven 2 進行自動化部署程序，講白一點就是不想每次都要依環境差異而透過手工進行設定調整及打包程序。不過有趣的是還是有很多軟體開發人員仍然堅持手工打造然後因為一點疏失就上錯程式捅下漏子！

但是不知道為什麼，整個 Maven 中的 xdoclet plugin 預設一直使用舊版的 xjavadoc 套件，導致在處理 JDK 1.5 新增的泛型特性（Generics）時因為不認識角括號 < 而吐出一大堆錯誤訊息，並連帶使的 Maven 原本提供的 javadoc 操作失敗（產生的 javadoc 不完整），對開發公用程式庫且必須提供 javadoc 的人員來講就變的很困擾。

一直逃避不是辦法，所以今天花了點時間找了網路上的資料後試出了解決方法。基本上是參考解決xdoclet-maven-plugin於jdk5上跑發生問題的說法，但文中所提的 plugin 來源 http://quebbemann.kicks-ass.net/maven2/repository/ 被威猛的趨勢科技世界級創新Smart Protection Network主動式雲端截毒技術擋在門外... 只好另外找其他的 plugin 來源。

總之，要讓 xdoclet 叫用新版的 xjavadoc 模組的方法是覆寫 xdoclet-maven-plugin 的相依性設定，使 xdoclet-maven-plugin 正確叫用新版的 xjavadoc 1.5 去解析 Java 原始碼，因此需要在 xdoclet-maven-plugin 設定區塊下新增相依性設定如下：

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>xdoclet-maven-plugin</artifactId> <version>1.0</version> <dependencies> <dependency> <groupId>ant</groupId> <artifactId>ant</artifactId> <version>1.6.5</version> </dependency> <dependency> <groupId>xdoclet</groupId> <artifactId>xjavadoc</artifactId> <version>1.5-snapshot050611</version> </dependency> </dependencies> <executions> <execution> <id>xdoclet</id> <phase>generate-sources</phase> <goals> <goal>xdoclet</goal> </goals> <configuration> <outputEncoding>UTF-8</outputEncoding> <tasks> <webdoclet destDir="${basedir}/src/main/webapp/WEB-INF" encoding="UTF-8" docencoding="UTF-8" mergeDir="${basedir}/src/main/resources/webdoclet" verbose="true" force="true"> <fileset dir="${basedir}/src/main/java" includes="**/*.java" /> <deploymentdescriptor displayname="${project.name}" xmlencoding="UTF-8" description="${project.description}"> </deploymentdescriptor> </webdoclet> </tasks> </configuration> </execution> </executions> </plugin>

但是光這樣還不夠，因為 Maven 官方的套件庫中並未包含 xjavadoc 1.5 相關資訊，所以必須另外指定去那邊下載 xjavadoc 套件，這只要在 pom.xml 中加入以下設定區塊即可。唯一要注意的是這個套件庫有可能隨時不見... XD

<pluginRepositories> <pluginRepository> <id>jahia</id> <url>http://maven.jahia.org/maven2/</url> </pluginRepository> </pluginRepositories>

好了，經由以上設定後 xdoclet 就不會因為程式碼使用到 JDK1.5 的泛型功能時只會吐出一堆 warning 了！

試乘捷運蘆洲線

2010-11-04T00:14:00.000+08:00

聽說今天是捷運蘆洲線試營運的第一天，格揆我也湊個熱鬧調整了下班路線跑去試試看免費的蘆洲線究竟如何？

整個回家所需時間約為 80 分鐘，比原本路線的時間差不多得多花個 20 分鐘以上才行，為了早點兒奔向溫暖的床舖我相信蘆洲線應該只會搭這麼一次吧？

從 18:57 離開辦公室到回到家裡的時間 20:15 各種狀態（咦？狀態圖？）如下：

狀態	時刻	花費分鐘數	原路線所花時間
離開辦公室	18:57	-	-
出辦公大樓	19:00	3	3
搭上南港展覽館接駁公車	19:09	9	9
到達捷運南港站下公車	19:13	4	4
捷運南港站發車	19:17	4	4
捷運忠孝新生站下車	19:31	14	-
捷運蘆洲線忠孝新生站發車	19:37	6	-
捷運三重國小站到達	19:50	13	-
出捷運三重國小站	19:53	3	-
出捷運台北車站	-	-	17
台北車站-忠孝候車站	-	-	3 ~ 5
等待公車(藍1/39)	-	-	3 ~ 5
扺達三重大同路口	-	-	10 ~ 20
開家門	20:15	21	5
合計		77	67

其實從南港轉捷運蘆洲線回三重所需時間不算很多，但是從三重國小站要回到天台這一帶的話是要花上一點時間的。如果晚餐想在三和夜市中解決的話是可以考慮這一條回家路線，不然的話從台北車站經忠孝橋回三重通常會比較快才是！

還有從上表中可以發現在忠孝新生站轉車的等待時間偏久，不過如果以上班不遲到為考量的話搭乘捷運上班有其優勢存在（但是捷運三不五時會突槌，那叫做正常能量釋放）。最後整條蘆洲線的月台設計似乎都給人一種空間上的壓迫感，在等車的時候可能會造成心情上的不快！

[公告] 切換部落格網址

2010-10-30T22:59:00.000+08:00

原本就計畫將目前的 adahsu0521.blogspot.com 網址連結到原本使用的 blog.adahsu.net 上，今天正式完成了這個設定。不過因為 DNS 同步的問題可能最遲會到一星期後才能正常訪問。

Android Froyo 2.2.1 升級失敗

2010-09-30T00:12:00.002+08:00

前陣子 Google 䆁出了 Froyo 2.2.1 的小升級，身為 Nexus One 持有者當然會優先收到 OTA 通知，只是這次的升級... 失敗了...

因為使用過一鍵 ROOT 工具，所以早早就以節省 ROM 空間的理由把 /system/app 中的東西砍的砍、搬的搬，而這個沒有官方更新資訊的 Froyo 2.2.1 除了已知的解決了一鍵 ROOT 所使用的系統漏洞外還順便更新了系統內建的 GMail.apk 到 2.3 版。

問題在於 GMail 2.3 這個升級版本來就可以從 Android Market 中下載，所以我也早就把原始的 GMail.apk 給弄走換成新版的 GMail ，於是 Froyo 2.2.1 在更新的過程中因為找不到 GMail.apk 的關係所以 patch failed ... 想當然，於是 OTA 就這麼莫名其妙的失敗了... 還好雖然 OTA 失敗但系統仍然可以透過組合鍵重新開機，只是 OTA 更新就這麼不見了...

重新開機後原始的 ROOT 環境還在（呼~~ 好佳在），趕快把 GMail.apk 搬回去再把 GMail 2.3 移除後，至今為止（才過了一天而以啦）還沒重新收到 OTA ，也許我得堅守在 Froyo 2.2 了吧？

※如果還有更新其他套件的話，那下次 OTA 應該還是會失敗吧...

2010-10-03 補充：
昨天再次收到 Froyo 2.2.1 升級通知，這次也沒太多考量就莫名其妙給它按下更新... 然後... 又失敗了... XD

這次它去更新 Google Goggles，但... 我移掉了... XD

2010-10-08 補充：
今天三次收到 Froyo 2.2.1 升級通知，這次也沒太多考量就莫名其妙給它按下更新... 然後... 又失敗了... XD

這次它去更新 Amazon MP3，但... 我移掉了... 而且是沒備份的移除了... XD 顯然只能重刷 Froyo 2.2 後再進行升級了... @@

促銷價格的背後

2010-08-26T01:02:00.000+08:00

有家超商喜歡用第二件六折的方式拉抬產品銷量，也有一家超商總是以二件 79 折方式來吸引消費者的眼光，畢竟第二件六折的實際意義就是二件八折，這個 79 折策略聽起來就是有那麼一點佔人家便宜的感覺。

上圖就是 79 折的實際案例，只是這個整箱特價似乎有點問題...

以一罐鋁泊包飲料 10 元來計算，192 元其實是打八折時的價格，如果以 79 折來計算的話應該是 189.6 元，只是超商是否會進位到 190 元則不太確定，而且超商的 POS 會刷出多少錢出來也有待測試。

嗯，不過在這邊計較這兩塊錢會不會顯的太窮酸樣了呢...

昨日的冒險旅程

2010-08-14T15:06:00.000+08:00

昨日 ( 2010/08/13 ) 下班所搭乘的公車在剛過新莊思源路時，忽聞司機伯伯一聲廣播：『抱歉，請各位準備更換車輛，本車爆胎了... 』！正當大家還莫名其妙摸不著頭緒時，車身一震，原本轟隆（這是誇飾法）的引擎聲嘎然而止.... 我想，再怎麼狀況外的人也都知道該下車了... XD

不過，下車後所看到的景像可就讓人心驚膽顫了...

寄件者危險

那麼它的右後退呢？

寄件者危險

點選照片可以連到有地圖標示的 Picasa 相簿！

最佳英文翻譯獎

2010-06-07T22:00:00.000+08:00

這個翻譯真是超贊的...

如何在下載動作中正確顯示中文檔名？

2010-04-14T17:16:00.003+08:00

總而言之，除了為人垢病的 CSS 問題外，各家瀏覽器在下載中文檔名時也有各自的脾氣...

以下是 JAVA 程式碼範例，大致上就分成兩派：支援 RFC-2231 的 Firefox/Opera 系和不支援的 IE /Webkit 系兩種，在 Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding 網站中有對各家瀏覽器是否支援 RFC-2231 規範的測試記錄，就結果來看除了純 ASCII 編碼的檔名頗受大家都支援外 (?)，其他混雜有各地語言的檔案名稱就得依瀏覽器的派別個別處理了。

if ( StringUtils.contains( userAgent, "MSIE" ) || StringUtils.containsIgnoreCase( userAgent, "AppleWebKit" ) ) {
    res.setHeader("Content-Disposition", "attachment; filename=\"" + URLEncoder.encode( fileName, "UTF-8" ) + "\"");
} else {
    res.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" + URLEncoder.encode( fileName, "UTF-8" ) );
}

就目前測試結果得知：

IE 6：可以正確彈出下載視窗，但存檔時的不一定能顯示正確的中文檔名
IE 7/8：可以正確彈出下載視窗及中文檔名
Chromium 5.0.360.5 / Chrome 5.0.375.3 dev：可以正確彈出下載視窗及中文檔名，其 AppleWebKit 核心版本分別為 533.3 及 533.4
Safari 4.0.5：在 AppleWebKit/531.22.7 時兩種方式都不行，但因 Chrome 的經驗猜測更新 AppleWebKit 到 5.33 以後版本即可正確顯示中文檔名
Firefox 3.x：可以正確彈出下載視窗及中文檔名
Opera 10.51：可以正確彈出下載視窗及中文檔名

OpenTTD 簡單心得

2010-03-18T11:58:00.004+08:00

最近不務正業的在玩豪華運輸大亨，都忘了要趕快規畫倒底要寫那類型的 Android 軟體了... 不過還是簡單記錄一下大亨的入門心得好了。

這個遊戲的重頭大戲其實在鐵道規劃上，如何利用鐵道號誌讓一大堆的火車可以在雙向兩條軌道上正常運行而不會有對撞、追撞等事故算是最簡單的入門（雙軌雙向軌道真的比單軌雙向軌道簡單多了）。雖說只是入門，但看著二、三十輛車在軌道上依序運行卻總能帶給玩家滿滿的成就感。以下是釀成多起追撞、對撞事故後的注意事項清單！

如果要賺錢的話可以搞航空運輸，不過個人覺得很空虛...
如果要搞鐵道貨運的話網友都會建議以媒炭為主
雙軌鐵道要先統一是左出右進還是右出左進，像台灣的鐵道記得都是左出右進的！
雙軌鐵道在分歧點時都需要設置號誌，簡單的概念是左邊出口處要放入口號誌，右邊進(入)口處則放置閉塞號誌，號誌應設置在前進方向的右側，以左出右進來看號誌就會集中在鐵道中央。有興趣者可以參考這裡！
如果軌道上有多輛車次的話則視鐵道長短酌量設置閉塞號誌，不然的話車子會卡在車站出口處。而車站出口處一被卡死就會造成同軌道上的車輛要不就跟著卡死，要不然就是追、對撞事故。
維修機場不要設在離車站太近的地方，距離至少要超過車輛長度（7格14節）及號誌設置區，不然有很大的機會出現車輛卡在車站與機場之間動彈不得的情形。

嗯，有新的心得會繼續補充！圖片的部份再想辦法生出來...

陷入無限迴圈的火車...

敢搶我礦產者，必阻之！

Android Developer Lab 參加心得

2010-03-03T21:18:00.001+08:00

好吧，我承認這一篇是炫耀文，其實沒啥心得可言！

忘記是去年底還是今年初在噗浪上看到葉教授發佈 Android Developer Lab 台北場開放報名時，因為天真的幻想能在 Android 平台上撰寫自己需要的軟體，於是莫名其妙的就填完單子完成報名手續。因為 Google 沒有立即回覆任何訊息，所以也差不多忘了這件事，直到過年前收到 Android Developer Lab 報到通知時才想起來要留一天年假去參加這個我戲稱為 Android 開發者聯誼會的活動。

聯誼會的日子很快的到來，因為入場時間是在 12:30 這個挺微妙的時間，所以早上硬是逼著自己不可太晚吃早餐以免中午吃不下結果在會場內昏倒的蠢事發生。還好，當葉教授說要出發前往會場時確認沒有供應午餐後，我也在 11:15 時分出門搭乘 638 前往六福皇宮會場。午餐是先在附近的小吃店以榨菜米粉湯（真的沒有肉絲）解決。

這是今天 Android Developer Lab 的入場券，並且憑券得兌換小禮物乙份！

到了 12:37 時活動正式開始，然後就聽到令人振奮的一句話：『今天活動要以英語為主』... 雖說插大時英文考的比國文好，但好像我的國語遠比英語像樣很多，於是老灰呀注意力無法長時間集中的問題就發作了，時而恍神、時而回魂是今天活動中最主要的精神運作模式...

總而言之，第一段是葉教授簡短介紹 Google Taiwan 及 Taipei GTUG，接下來換人介紹手機上網的趨勢；然後是 Android Marketplace 的上架辦法及一些注意事項。這部份雖然大致聽懂講者的內容大意，但全程英語還是有一定的催眠效果。就在恍神模式下時忽然看到這個 Google Japan 所拍的 Nexus One 忍者開箱動畫。正沉浸在影片中 KUSO 的宣傳手法時竟然聽到要送手機的字眼，你知道的，有東西吃或是有禮物拿時總是可以讓人眼睛為之一亮，於是所有人就全部擠出門去排隊領 ~~長崎蛋糕~~ Nexus One 禮盒。在等待的過程中不少人還抱持懷疑態度以為手機只是借用，會後需要歸還的。但一切都在有人按耐不住的詢問工作人員後獲得解答：『不用還，手機真的是送的』！Google 大神啊，您真是佛心來著呢！

因為在領取手機前有說到接下來的兩堂課會實作，如果電量不足的話腳邊有插座可用（後來覺得應該是聽錯了），於是大部份人都在現場玩起開箱遊戲。不過最後發現其實手機可以原封拎回家好好開箱的，現場實作用模擬器就可以了。這也是我覺得之前提到的插座應該是為了給筆電沒電的人使用的，並非說是對手機充電之用。

這就是憑入場券所兌換的長崎蛋糕禮盒（誤）

由於聽說第三節開始是實作說明，所以有個笨蛋就把筆電開機了。可是搞了半天原來是介紹 Android SDK 2.1 的許多新特性，於是白白浪費了 50% 的電量在這堂課中（6 cells 電池是撐不久的），等到真正 Coding 練習時我的筆電就在低電量警告訊息中沉沉睡去........

CodeLab 練習的題目是動態桌面的實作，講師提供了一個基礎 Eclipse 專案設定作為練習，但因為投影片的字是真的有夠小所以最後我下載 FINAL 版進行比對，在程式碼確認的差不多時當然會想要執行看看，然後就在模擬器啟動途中看到低電量警告，原本以為來的及看到程式效果的幻想則在筆電自我感覺沒電不太好自動關機的情形下完全破滅...

還好這時候講師也實作完畢，時間進入 Q&A 時段... 看著鄰兵打包走人後，我也開始找地方塞剛領到的長崎蛋糕禮盒，然後出門去搭車回家。

搭車時有在想，動態桌面這個題目是不是有點雞肋呢？我以為大部份開發人員應該不會對這種不以實用為目的的特色有太多關注，那麼今天這個 CodeLab 範例選擇這個題材是否有啥特殊意義呢？和 Widgets 搶食桌面空間？其實到現在我還是沒有任何答案就是了...

對了，今天領到 Google 高科技小禮物雖然很 High ，但是 5800XM 上原本同步來的通訊錄整個不見也令人很駭... 回家第一件事是上 Google 看看通訊錄內容有沒有跟著消逝，還好，它們還在！

全劇終... ！

ONE PIECE: STRONG WORLD

2010-02-07T23:44:00.003+08:00

上週到國際書展時才發現原來 ONE PIECE 電影版 STRONG WORLD 強者天下已經上映後（剛好上映的隔天去書展的），就幻想著一定要趁過年前先看一看。今天是過年前最後一個假日，我也很努力的在京站威秀售票口前排了將近一小時的隊。不知道為什麼場次的安排似乎不是連續的，還好大家顯然都跑去看 MONGA 而沒來和我搶 ONE PIECE 的座次。雖然尚未滿座，但是這個可容納百餘人的小場地其實在輪到我購票時也沒剩幾個位置可以選了，此刻倒是有一種為什麼早上不先多花 20 元手續費直接網路購票的悔恨... (泣)

就劇情上來講可能要扯到 OnePiece 第 0 卷，另外在動畫版部份魯夫於到達海底監獄『推進城』時也有加入一段金獅子的故事（426話開始）。總而言之，這是一場世界政府的危機但最後世界政府啥都不能做的故事。至於為什麼世界政府啥都不能做的理由還請進電影院瞧瞧！

另外在各橋段中總是一直穿插著各式各樣的笑點，不過印象最深刻的應該是布魯克被食肉蟻小看時說的那句『我只是局部型肥胖』吧！這真是中廣型阿宅最需要的一句救世密令啊... XD

沒想到 WIKI 上已經有人整理了電影相關資料了！
除了娜美的裸露演出外，羅賓的馬尾 + 眼鏡娘造型倒也是讓人印象深刻，雖然她最後沒啥表現機會！
MONGA 發音要正確，不然會變成 MANGA。
對了，這是 MONGO 預告片！
如果有人想請客的話，我還很願意再進電影院看一遍.... XD
啊對了！個人覺得本劇場版應該歸為輔導級，因為裡面抽煙的人太多了卻沒有打馬賽克...

把 SFTP 關起來 (CHROOTED)

2010-01-15T16:21:00.004+08:00

前言

為了提供少量的檔案共享但又不願意特地去設定 FTP 服務的話，通常第一個想到的會是附屬在 SSH 服務下的 SFTP 傳輸模式，事實上 SFTP 這個服務雖然因為加密的關係會導致傳輸時間略長，但卻一直是格揆我作為檔案傳輸的唯一方式。但這方式雖方便卻有個大問題：登入的使用者可以看到所有的檔案目錄甚至直接下載檔案內容。這在多人使用的環境下顯然會有資安上面的困擾，有沒有辦法把 SFTP 服務關在某個指定的目錄下呢？

格揆經由 Google 大神的協助並多方測試後終於實作出可行方案，就... 再貢獻回給大神吧... XD

設定步驟

※ 本文以 OpenSSH 5.2_p1-r3 為設定環境！

選定封鎖目錄：如果對像是單一個人時即為該用戶登入 SFTP 時的根目錄；如果對像是一個群組時則該目錄為這群使用者目錄的根目錄。

在 /etc/ssh/sshd_config 中啟用 sftp subsystem：特別注意要啟用的是 internal-sftp 這個 Subsystem。

# override default of no subsystems
#Subsystem      sftp    /usr/lib64/misc/sftp-server               # 系統中原來的設定
Subsystem       sftp    internal-sftp                                       # 改用 internal-sftp

一樣在 sshd_config 中指定需要被關起來的使用者資訊及要關到什麼地方去，請在前述修改處之後加上以下設定：

Match User ada                                 # 要被關起來的使用者，如果是群組的話則將 User 改為 Group 再接群組名稱
                                                          # 例如： Match Group rootedSFTP
ChrootDirectory /chroot                    # 要關在什麼地方，如果對像是個群組且群組內的每個人有個別目錄設定時，
                                                          # 可以加上 PATTERNS (man ssh_config) 做區隔，如 /chroot/%u ，
                                                          # /chroot 為這群使用者目錄的根目錄。
ForceCommand internal-sftp            # 一樣要使用 internal-sftp 這個 Subsystem

設定 Chroot 目錄權限：錯誤的目錄權限設定會導致在 log 中出現 "fatal: bad ownership or modes for chroot directory XXXXXX" 的訊息。根據 openssh 5.1 chrootdirectory permissions issue 這篇文章的資訊顯示，目錄的權限設定有兩個要點：
- 由 ChrootDirectory 指定的目錄開始一直往上到系統根目錄為止的目錄擁有者都只能是 root
- 由 ChrootDirectory 指定的目錄開始一直往上到系統根目錄為止都不可以具有群組寫入權限
重新載入 sshd 後即可透過 FileZilla 等支援 SFTP 的軟體測試有無被關起來了...

Gentoo Linux 與 Windows 7 安裝心得

2009-12-15T16:09:00.000+08:00

這幾天一直在安裝 Windows 7 和 Gentoo Linux 10.1 之間奮戰，浪費了不少時間踩了不少的地雷，恰好可作為部落格的文章以為紀念... XD

Dual Boot

首先因為 Windows 7 在安裝時會在硬碟中產生兩個 Primary Partition ，這讓我在評估是否雙系統共存時有了很慎重的考慮，並為此選擇在 VirtualBox 3.1 中先行試驗確認。不過，經過多次測試總無法經 Grub 對 Windows 7 開機，在最後關頭時決定直接上機測試成功時，才驚覺整整浪費了 2 個工作天在無任何產值的測試作業中... (嘆)

另外對於 Dual Boot 這件事，Gentoo 其實沒有先 Windows 再 Linux 之類的條款，因為它不會幫你建立預設的開機環境設定。Grub 裝在 MBR 也無所謂，反正 Windows 7 開機是從第一個 Partition 中的特定檔案啟動的。最後我還放棄了 SWAP 分割區的設置，將 4 個 Primary Partition 平均分給兩個作業系統，Gentoo 就一個 / partition 及一個 /home partition 。

發行套件的選擇

基本上這是因為安裝過程不太順利下，為什麼還選擇 Gentoo 的原因說明

Gentoo 之所以在某些群體中受到歡迎經常受到誤解，認為這些愛用者是因為迷信自行編譯所帶來的無上效能。其實在目前的中、高階 CPU 及便宜的記憶體市場下，自行編譯所帶來的效能改善情形非常有限，很多人應該也不是那麼心甘情願的願意浪費 1 ~ 2 天的時間進行系統編譯的工作（尤其 Windows 7 安裝一遍只要 20 分鐘），只因為目前還沒有看到更有彈性的軟體套件管理機制，導致短時間內無法轉投入另套發行套件。像格揆本人我就一直想要知道 Arch Linux 究竟有沒有類似 Portage USE 選擇的機制，只是說從所有的範例中似乎嗅不出類似機制的可能性，我也只好繼續使用 Gentoo 系統了！

基楚系統建置

在進行 Gentoo 基礎系統建置時切記不要過早投入 Portage Overlay 的設定，雜亂的套件相依設定是造成系統編不出來的主要原因，尤其在桌面管理系統上影鄉尤為深遠。

另外為了簡化系統的複雜度，一開始也不宜過早加入 ACCEPT_KEYWORDS 的設定，儘量先以系統預設的、穩定的套件版本為基礎完成配置後再加以強化為宜。

ExtJS 筆記 - EXTJS 的事件處理函式

2009-11-16T01:48:00.007+08:00

和 jQuery 不同，ExtJS 的事件處理函式略顯複雜了些！原因在於 jQuery 的事件綁定機制永遠只作用於 jQuery 物件，但 ExtJS 的事件綁定機制卻必須先確定事件綁定對象的種類。

在 ExtJS 中有兩種類型的 Ext 物件可以進行事件綁定，一種是 Ext.Component，另一種是 Ext.Element。雖然它們都會對應到頁面上的 HTML Element ，但實際上來看 Ext.Component 算是以 Ext.Element 為基礎進行擴充的衍生物件，常因為特別需要而自行提供許多自定的事件，例如 Ext.form.Checkbox 這個 Ext.Component 物件會額外提供 check 事件，當然你可以把這個 check 事件當成原本 click 事件的再包裝。

所以說只要弄清楚事件綁定的對象後也就能夠確定所使用的事件處理函式的參數型態，對 Ext.Element 而言它的事件處理函式參數格式為：

/* 此的處 element 是一個 HTML Element ，也就是原本的 HTML DOM 物件 */
function eventHandler( event, element, object ) { }

但若是 Ext.Component 的話它的事件處理函式則為：

function eventHandler( component [, value/state ] ) { }

其實寫 ExtJS 應用系統很容易遇到事件處理函式未能如預期反應的情況，這是因為搞錯了事件作用的對象以及事件處理函式的參數匹配不正確所導致，要不是因為此次的系統開發時用到了 Ext.form.Checkbox 這個元素，也許格揆我還沒發現原來 ExtJS 的事件模型有分成兩種情形，而大致搜尋了一下也沒有啥文章特別提到這個明明就在 API 文件中，但工程師顯然不會特別注意到的情形。

但我們該怎麼取得 Ext.Component 或 Ext.Element 物件呢？只要記住除了 Ext.getCmp() 外，其他的 DomQuery 函式都只會傳回 Ext.Element 或 Ext.CompositeElement（可把它當成多個 Ext.Element 物件的集合）物件。

以下的範例可看出 Ext.Component 及 Ext.Element/Ext.CompositeElement 在注冊事件處理函式時的差異：

<html>
    <head>
        <link rel="stylesheet" type="text/css" href="http://www.extjs.com/deploy/dev/resources/css/ext-all.css" />
        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
        <script type="text/javascript" src="http://www.extjs.com/deploy/dev/adapter/jquery/ext-jquery-adapter.js"></script>
        <script type="text/javascript" src="http://www.extjs.com/deploy/dev/ext-all.js"></script>
        <script text="text/javascript">
            function init() {
                var viewport = new Ext.Viewport({
                    layout: 'form'
                    ,defaults: {
                        xtype: 'checkbox'
                        ,labelWidth: 70
                        ,labelAlign: 'right'
                    }
                    ,items: [
                        {
                            fieldLabel: '選項一'
                            ,id: 'chbox1'
                        }
                        ,{
                            fieldLabel: '選項二'
                            ,id: 'chbox2'
                        }
                        ,{
                            fieldLabel: '按鈕一'
                            ,id: 'btn1'
                            ,xtype: 'button'
                            ,text: '按鈕一'
                        }
                    ]
                });
  
                // 對 Ext.Component:chbox1 物件注冊 check 事件處理函式
                Ext.getCmp( 'chbox1' ).on( 'check', function ( chbox, checked ) {
                    alert( chbox.getId() + ' is ' + checked );
                });
  
                // 對所有的 Ext.CompositeElement:Checkbox 物件注冊 click 事件處理函式
                // 實際上有兩個物件被注冊了事件處理函式
                // 如果想在 Ext.Element 物件上綁定 check 事件的話，它是不會生效也不會有錯誤的喔！
                Ext.select( 'input[type=checkbox]' ).on( 'click', function( evt, el ) {
                    Ext.Msg.alert( 'Event Tester', el.id + ' is ' + el.checked );
                });

                // 對 Ext.Component:btn1 物件注冊 click 事件處理函式  
                Ext.getCmp( 'btn1' ).on( 'click', function( button ) {
                    alert( button.getId() + ' clicked' );
                });
  
                // 對所有的 Ext.CompositeElement:button 物件注冊 click 事件處理函式
                // 實際上有一個物件被注冊了事件處理函式
                Ext.select( 'button' ).on( 'click', function( evt, el ) {
                    Ext.Msg.alert( 'Event Tester', el.id );
                });
 
                return viewport;
            }
     
            $( document ).ready( init );
        </script>
    </head>
    <body>
    
    </body>
</html>

參考資訊：

ExtJS入门之二事件

閃擊點行動 - 龍之堀起 ( Operation Flashpoint - Dragon Rising )

2009-10-26T01:12:00.000+08:00

閃擊點行動 - 龍之堀起 ( Operation Flashpoint - Dragon Rising ) 是 CodeMasters 公司前陣子新堆出的遊戲，同時支援 PC / XBox 360 / PS3 三平台。

總括而言，這是一套除了畫面遠勝 2001 年首次推出的閃擊點行動 - 冷戰危機外其他部份都完敗的失敗作，甚至嚴格而言本遊戲也不算是冷戰危機的續作，至少從遊戲命名中是完全看不到 2 這個字眼的。

簡單條列個人覺得這套遊戲和冷戰危機相比失敗的地方：

從班戰鬥縮水成小隊戰鬥：沒錯，這是個精英小隊，但是一次 12 個人可以有更多的戰術配置。沒記錯的話在冷戰危機中有一個關卡還是一整個排去打敵人的設定呢！這項改變大致上可以猜到是因為 PS3 / XBox 360 操控手把所做的限制。
戰術指令缺乏細節設定：記得冷戰危機中可以命令隊友去撿拾槍枝和補充彈藥，也可以把整個班透過撿拾殂擊槍的命令而變成殂擊班。本遊戲中似乎電腦隊員都沒有缺彈危機？把戰術指令大幅刪減的原因大概也是為了配合遊戲機的操控吧！對了，我曾對隊員下達接敵指定對象的命令，但是... 他們都不鳥我... (怒)
可遠觀而不可褻玩焉的載具：在冷戰危機及其資料片中有一大堆的載具（飛機、輪型車輛、民車、以及裝甲車等）可以操作，但到了龍之堀起時真的開過的只剩下悍馬車和最後關卡的直昇機而以。不過看電玩快打介紹的影片中有戰鬥直升機可以操作，但我的軍旅生涯回憶錄中只有被戰鬥直升機追殺的慘烈而以.... (嘆)
過關條件的限縮：冷戰危機最為人所贊頌的是他無特定規則的過關選擇，在冷戰危機中除了從外圍一路殺進敵營外，還可以先溜進敵營偷一台裝甲車或雌鹿攻擊機後再殺出來，這是龍之堀起總是走進去敵營又一路打出來的固定模式難以超越的。
隊員養成：在冷戰危機是可以透過經驗值累積以提昇班兵的能力的，但是龍之堀起中每次帶的隊員都一定不同，隊員陣亡也只需等到檢查點後就會重新復活，當然也就少了經驗值作為隊員養成的依據了。
關卡的變化性不足：在冷戰危機中有防禦、有攻擊、有步行機動、有車輛接送、也有裝甲車專屬關卡，還有直昇機攻擊，而龍之堀起則是突擊後防禦為主。其中雖然有一關是監控解放軍將領 - 韓將軍逛大街的特殊關卡，但最後用 JDAM 轟掉房子的設定其實覺得挺空虛的... (默)
關卡過短，故事性不足：記得冷戰危機約有 20 關... 吧，龍之堀起只有 10 關的樣子，搞的玩家還沒融入故事情節時遊戲就結束了.... -.-

認為龍之堀起不如原本冷戰危機的原因大致如上，如果不是 CodeMasters 和原開發冷戰危機的波西米亞工作室鬧僵的話，也許真正的 Operation Flashpoint 2 早就推出了。