而且，如果有最基本的 unit test，這麼明顯的錯誤，應該很早就挑出來了。

還是以明晰的方式寫程式比較重要。

這通常是講者沒有事先縱覽整個議程，才會導致過度地重複。

從原始數據來看，真正的長青霸主，其實真的就只有兩個：Java & C.

第三名以後，數字都差了一截...

Terraform 有 Execution Plans 及 Resource Graph 機制，類似 RDBMS 的那種 query plan。用起來會比較安心。

我這陣子會好好試驗看看，再到 JCConf 2015 分享（如果投稿有被接受的話⋯⋯）。

這類 ec2 module 的問題，我比較傾向用 HashiCorp 的 Terraform

不同的看法：

Google's participation in OpenStack doesn't solve a major problem1

這是在逼 Google 加速 Go 1.5 的 Android 功能...

ingramchen 及 koji 可以開講一場 研發 Kaif 所用的技術...

這年頭，連 PHP 的會議也徵求 big data 主題了……

很多美商其實還是非常強調解題方法。

至少以我聽過的，FB, MS, Google, Amazon, Square, Foursquare... 都是這樣。

Ansible 總部最近一直在各地招募 meetup...

和 moco1 比起來，哪個好用？

我比較不會無限上綱到每一個 image 都要壓到這麼小，會比較一下 C/P 值。

像以下這堆 Java 的 image，就不太值得：

REPOSITORY                   TAG        VIRTUAL SIZE
 -------------------------   ------     ------------
jeanblanchard/busybox-java   latest     162 MB
jeanblanchard/busybox-java   7          146.5 MB
jeanblanchard/busybox-java   jdk7       147.6 MB
jeanblanchard/busybox-java   jdk8       163.8 MB
errordeveloper/oracle-jdk    latest     303.6 MB
errordeveloper/oracle-jre    latest     159.4 M

目前個人的感覺是，很少 runtime dependency 的小工具（尤其是原本就是用 C/C++ 或 Go 寫的小工具），比較值得做這種處理。如果是 server 程式，反而比較適合留在原本的 debian:jessie 上面，享受比較多的 runtime 支援，也不必小心翼翼處理『拆除 dependency』的環節。

反過來講比較合適：Windows Server 要主動提供 Container 機制，以支援 Docker 功能。

Vector 只是 PCP (Performance CoPilot) 的 dashboard frontend。實務上，並不會部署太多台，影響並不大。

自己沒有真的架在 AWS 上，不過據別人的經驗，weave 和 Open vSwitch 都可以。

簡單一點的方法：SDN。

對侯捷仍守在 C++/STL/Boost/DesignPatterns 這領域進行教育訓練，還一直鑽進去，我抱著尊敬的態度。

就像一直有出版社找我翻譯 C++ 經典級新書一樣（我個人是沒這個時間了啦...），只要有這樣的需求，自然就會有這樣的教育訓練／出版市場。

重點是要問，對那些 TA 來說，是否獲得 C/P 夠高的訓練？

我也很愛用它的 pretty print。偶爾搭配一點點 filter。