NOTE 2018/08/10: 從 Aug 2018 開始，SAA 已經無法考此版內容，這篇文章算是功成身退囉～

使用 AWS 有一段時間，但是真的認真學習相關知識，然後在實務上應用，大概才一年的時間。過程中，覺得 AWS 整個 Cloud 的技術以及 Solution 相當完整，教育訓練也很有系統，加上工作的需求，於是興起考認證的念頭。

剛開始準備其實有點無頭蒼蠅，讀了好幾篇 Whitepapers 和 Guide，發現東西真的是太多了，後來找了一些心得分享，發現官方有完整的 考試指南，才開始收斂準備的方向。

準備考試之前，先確認以下：

• 考試的範圍：AWS 的東西 非常非常多 ，範圍也是 非常非常大 ，每個 Service 都有一定程度的複雜 (像 EC2, S3, VPC, CloudFront)，同時又會相互關聯、以及適當的 Practices，所以知道考試範圍，才知道接下來怎麼安排準備。
• 實作：考試題目很活，很少記憶性的題目，大多是給予一個情境，然後問用哪些方案，或者做 trouble shooting。盡可能多練習，考試的內容很多是實務上的問題。
• 盡可能地在實作中，想問題，然後從 User Guide / Developer Guide / Whitepapers / AWS Developer Forums 找答案.

以下是我準備時，所閱讀的東西，有些已經把重點整理在 blog。

Updated 2018/02/15: SAA 已經在 2018/02/15 更版，差異請參閱 AWS Certified SAA-01 Update 的說明

S3 全名是 Simple Storage Service，故縮寫 S3，它是 AWS 在 2006 年推出的 第二個 SaaS 服務，有很長的歷史。雖然名字有個 Simple，但其實它不容易。本文整理研讀官方文件、以及工作上遇到的問題，整理以下的筆記：

• 一、基本概念 (Concepts)
• 二、核心功能 (Core Functions)
• 三、存取權限 (Access Control)
• 四、資料保護 (Data Protection)
• 五、服務限制 (Limitation)
• 六、開發 (Development)
• 七、成本 (Cost)
• 八、應用場景 (User Scenarios)
• 九、常見問答 (FAQ)

這件事情 NPM & left-pad: Have We Forgotten How To Program?，似乎在 node.js 圈吵很兇 ….

node.js 現在讓人最困擾的就是: 每個 module 都有小而美的精神，而且都很有個性 (跟 Un*x 很像)。但就是太有個性了，所以讓人覺得隨便的感覺 ….. 特別是很多 source code pull 下來真的是慘不忍睹 … 可讀性差, naming 混亂 ….

一隻 function module 放到 npm, 有可能就會被大的 module 參考. (很多 module 裡只有一行 code 的 ….)

像 left-pad 這種一個 loop 的東西，開發快當然沒問題，但從效能角度來看是有待商榷的，甚至是出局的。

PHP 剛開始的 function 大概就是這樣，超級亂的 function 與 naming / arguments / output … 但是能動 …. 然後 node.js 有些 “慣例性的用法”, 像是 lodash, 熟悉了就還好, 但是可讀性很差. 感覺很像 perl … 寫的人很爽，接手的 XXX 罵不完.

這樣的生態圈發展很快，也非常熱絡，但是對於需要高效能、穩定性、標準化的實務應用來講，還是要多慎選 modules 的使用。特別是效能的評估與架構性。

雖然感覺很亂，語法 (ES6) 在 OO 方面也不夠成熟, 像是沒 interface, TypeScript 才有; 只能宣告成員方法，無法宣告成員屬性; 沒有 private 修飾 …. (可能有，或者有類似的寫法 ….) …. runtime 能否做 profiling, memdump, 分析工具? 重構工具？

但是，天下分久必合，合久必分 …. node.js 還是很棒 + 潮到出水的，值得投資學習 ….

Reference

• NPM & left-pad: Have We Forgotten How To Program?, 中文

AWS Identity and Access Management (IAM) Policy 的整理.

Architecting for the Cloud (AWS Best Practices) (2016/02) 是 AWS 針對設計雲端架構的最佳實踐原則，描述了很多架構設計要知道的原則。

對於要設計 PaaS 或 SaaS 是非常有參考價值的。另外一篇也是很有參考價值的是 AWS Well Architected Framework.

Updated: 2018/01 我在公司內部教育訓練導讀了此篇，整理 Slide 分享 - Study Notes - Architecting for the cloud (AWS Best Practices, Feb 2016)

整理 [Route53] 的學習筆記。

整理 DNS 概念筆記。

整理 Elastic Load Balancer 的學習筆記，包含了：

• Classic Load Balancer (L4 + L7), 上一代的 LB ，已經不建議使用。
• Application Load Balancer (L7)
• Network Load Balancer (L4)

內容整理以下：

• 基本概念
• 功能
• 常見問答

今天在設定新的 SES 的時候遇到設定 SMTP Credentials 和 IAM Policy 權限的問題。

整理學習 VPC 的筆記。包含以下：

• 基本概念、設定 VPC 過程問題與心得
• 相關 AWS 服務
• 常見的應用場景，包含如何規劃適當的網路架構

Tomcat Log 出現 “Too many open files”

Log catalina.err 出現類似以下的 exception, 然後 application 就掛了 …

1
2
3
4
5
6
7
8
9
10
11
12

INFO: Deployment of web application archive /usr/tomcat/webapps/app.war has finished in 378,373 ms
Sep 2, 2014 10:46:54 AM org.apache.tomcat.util.net.JIoEndpoint$Acceptor run
SEVERE: Socket accept failed
java.net.SocketException: Too many open files
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
        at java.net.ServerSocket.implAccept(ServerSocket.java:478)
        at java.net.ServerSocket.accept(ServerSocket.java:446)
        at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60)
        at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:220)
        at java.lang.Thread.run(Thread.java:701)
Sep 2, 2014 10:46:55 AM org.apache.tomcat.util.net.JIoEndpoint$Acceptor run

一直有透過 Cloudtrail 在了解資源的使用狀況 （為了方便監控，把訊息放到 Slack），可是發現每天都有一些奇怪的 event 如下圖：

這些 event 的特性有：

• 都是用 root account 在執行 (OMG)
• 都是刪除 ENI (網卡)
• 大多都是晚上發生的

一直搞不懂為啥會有這動作，也去問了同事，有沒人在做這樣的動作，可是沒有結論，直到最近我在規劃 VPC 網路架構時 ….

Hexo 3.x 有一些新功能，目前我還不知道有啥用，只不過現在用的 2.8.x 在 OS X 執行 codegen 時效能很差，所以想換個版本試看看是否有改善。

更新版本的方式主要是參考 Migrating from 2.x to 3.0

今天同事丟 docker4xcode 過來，第一時間，心裡覺得怪怪的，因為不久前才稍微讀過幾篇介紹 Docker 原理的文章，對於 Docker 為啥能在 linux 上實現，以及有人利用 shell script 一百行的程式實作出 docker，心裡對 Docker 原理大概有個底。那時候也有去了解 Darwin (OS X kernel) 能否支援相關功能，結果是不行的。

實驗 AWS 兩個 VPC 透過 Peering 方式，可以讓不同 VPC Subnet 可以對連。基本架構如下 (From VPC Peering)

應用實例就是建立開發和測試兩個 VPC，各自有獨立的 Internet Gateway 和 Route Table. 同時也利用 Route53 的 private host zone，建立內部的 DNS 服務。

備註：實驗的過程，用新的 AWS 帳號來做實驗，避免影響正式的服務。

因為 這個 需求，我先在自己的機器實驗成功後，到公司 AWS EC2 設定。公司 AWS 架構比較複雜，所有的機器都在 VPC 裡面，如果要能夠讓外面進來，只有兩個選擇：ELB 或者是 加掛 EIP。 要讓 EIP 可以出去，就必須走 Internet Gateway (IGW)，如果 EC2 Instance 放在 VPC 裡，那麼預設都是走 VGW (Virtual Gateway)。要讓這台機器可以同時在 VGW / IGW 兩端游走，後來想到的方法就是加掛另一張網卡 ENI，只是這張網卡的 CIDR 是在 IGW 的 Subnet。他們的關係大概長這樣：

把 Windows Server 的 EC2 做成 AMI 之後，利用此 AMI 重新建立的 Instance，就會變成無法取得 Administrator Password，出現以下訊息：

整理一些在 Linux 常遇到的語言或語系問題。

很多事情，換個角度會有完全不一樣的見解。這篇文章整理我個人對於 SQA 職能的一些想法與經驗談。

20230523 更新: 本文部分收錄在 共同著作《軟體測試實務》 第一冊 第一章之中，歡迎大家彭場。

最近系統遇到相容性的問題，兩個不同的版本並行在線上運作，產生諸多無法預期的問題，像是效能問題、未知的 HTTP 404、503 … 等。問題錯綜複雜，加上歷史包袱的堆疊，加上線上隨時的亂流，形成一種無法控制的風暴。

這讓我思考到幾件事情：

工程師要像趙雲一樣藝高、膽大、心細。

有些公司，只要是碩士畢業，就掛 高級工程師、資深工程師。。。這種感覺就跟 幹訓班 出來，就掛 將軍 一樣軍銜，名不符實。

只要付得起每個月信用卡循環利息最低金額就可以申辦『白金卡』，這信用還真廉價 …

我覺得：

Title 代表的不是表象，而雇主對員工的是信任、期待與責任

那到底怎樣的條件才可以算是 資深軟體工程師？還有其他的 Title？

QA 的工作內容落差很大，要求的條件落差也很大。有的公司 QA 是獨立部門，有的是掛在 R&D 底下，有的則是掛在 PM 底下。

20230523 更新：本文內容部分收錄在 共同著作《軟體測試實務》 第一冊 第一章之中，歡迎大家彭場指導。

幾個 OS X 使用鍵盤的問題：

(在不改動系統設定的前提之下)

跟朋友聊到流程的問題，聊到 這篇文章，整理一下我的想法。

關於 人生視野 的問題， 就像用 Google Map 一樣，要學習從不同角度 (街景, 圖資層級, 個人地圖)，不同層次 (交通、衛星、吃喝) 來看。學習當看到一個問題，他應該放在哪一個層次，更容易解決，或者說從各種層次去分析問題，權衡輕重。

為將者，要有遠見、技能、視才知能、執行力、仁德之心等諸多條件。當然資金也會是條件之一，只是比重而已。把這些能力排列組合，一些常見的老闆種類 ⋯⋯

記錄一些 Unix/Linux 常用的 shell and script 概念.

1. Create git repository in server side
2. Basic HTTP Authentication
3. Migrate SVN to Git repository

Notes: CentOS 6.2, Git Client: SourceTree, Github clinet

延續 上一篇筆記, 這篇繼續整理一些常用的 plugins, 主要都是參考自 “快快樂樂學 vim“ 還有其他 google 找到的, 然後整理我自己覺得不錯的 plugins 和 vim 的設定.

另外因為我在很多台機器工作, 所以我也把這些設定放到 github, 方便轉換使用. 有需要的朋友可以參考看看.

因為經常在 unix/linux 環境工作，vi 一直都是最習慣的 editor。不過用了很多年，其實沒有很認真的把功能都很熟悉過，趁著年假空閒之餘，整理一些個人常用的筆記。

寫 code 或寫文章的過程，其實我不太喜歡在鍵盤跟滑鼠 (or touch pad) 之間跑來跑去，所以看過我寫 code 或者寫文章的人會發現，我習慣記很多 shortcut or hotkey，然後直接在 keyboard 上飛奔，也就是專注在思考做事的內容。套句以前老師說的話，一個 developer 最好把滑鼠剪掉，否則你的工作是沒有效率的。

除了 vi, 另外我還喜歡用 ultraedit, sublime, notepad++. 不過最喜歡的還是 vi 和 ultraedit. 不過自從工作環境換到 OS X 之後, vi 和 sublime 就變成主力了. ultraedit 在 OS X 的 IME (中文輸入法) 有不少問題, 目前我還是觀望中.

會注意到 LLVM 是剛開始在學 XCode 時, 在 build settings 裡出現 Apple LLVM 6.0, 裡面有很多項目, 像是 Code Generation, Language, Modules, Preprocessing, Warning, … etc, 其實不是很了解他的明白. 不過後來在看 台灣軟體產業的失落十年 這本書時, 作者也提到 LLVM, 找了一些資料來讀, 像是 LLVM 總是打開你的心：從電玩模擬器看編譯器應用實例, 我才意會到這東西是了不起的概念.

• LLVM 實作最成功的就是 clang, 它是 Mac OS 上預設的 C/C++/Objective-C compiler.
• FreeBSD 10 預設 compiler 改用 clang

版本控管 (Version Control) 的目的：

1. 知道改動的範圍 (Scope)
2. 內部各單位的溝通界面
3. 問題追蹤的參考索引

以下的說明，是我在 2013 年對內部其他單位溝通時的內容，然後稍作調整，主要描述的是版本控管的目的以及方法。這概念跟 Artifact Management 有很直接的關係。

底下的內容，是 2013 年一部內部訊息，整理出來的，部分內容是停留在當年 (2013) 的狀況.

我試著調整 Hexo 的一些細節，包含了解 Themes 結構、修改 CSS、加入 Facebook 的功能、RSS、了解 Plugin 的概念等等。把這些過程心得，都記錄在這裡。調整部分大概如下：

• 寫文章的小技巧
• Theme 目錄結構、CSS 微調
• 好用的 plugins
• 輔助工具

這份筆記主要是參考 交大開放式課程: 嵌入式系統設計概論與實作 的為主，大部份的內容都是錄影內容的筆記，範圍是 第一週 、第二週 的內容。然後加入一些我個人的筆記、複習一些知識、還有一些新的想法。

摘要

1. 計算機結構摘要
2. 簡介嵌入式系統 (What, Why, How)
3. 嵌入式硬體開發
4. 嵌入式軟體開發
5. 一些好玩的應用

緣由

我一直有寫 blog 的習慣, 包含音樂, 技術, 生活三大類. 音樂類在 blogger 寫了很久了, 也很熟悉 blogger 的功能, 他也滿足我大部分的需求, 包含可以完全自定 HTML/CSS/JS 等. 但是對於資料的完整性, 也就是除了文章, 其他還有圖檔部分, 就不是能夠完整備份, 因為它整合了 Picassa. 但我不是很喜歡這樣的整合, 不好備份. 哪天 google 把 blogger 收起來我就哭了 orz…

Blogger 另外的問題就是 HTML Editor 不好排版, 常常產生 garbag code, 差不多和 word 同樣等級了.

自重開始使用 markdown 寫文章之後, 就一直在找類似的系統, 本來是用 logdown, 不過用了一年, 發現問題都沒有在維護, editor bug 也不少, 功能也無法完全滿足我的需求, 所以就開始想找其他的系統了.

本來是想試 Octopress, 後來同事推薦 Hexo, 抱著好奇心的角度試看看, 發現跟以前我曾經用 PHP 把 BBS 文章轉成 web 的概念有點像, 可以整合 github, 所以就決定先用這套了!