題外話，我們公司的 front-end (nodejs ecosystem) 全部是交給 gradle build，從此開發者不用再自行安裝 nodejs，也不用管設定 PATH 或是 virtual env. 版本互衝那些啊哩不搭的鳥事。
Day 2 Note1 還沒有在這個 collection 裡，但點 Day 1、3 可以找到。
EDIT: 三天的筆記都進來囉
我們公司的系統都有寫 unit test，所以在追加功能和維護上都相對簡單 (就成本低一點，大家也比較敢改東西)。我自己寫了快十年的 unit test，這件事簡單說就是倒吃甘庶：一開始很累，因為要建一些基礎設施。到了中期稍微好了一點，但你還是會覺得有負擔。到了後期這負擔還是在的，但這個階段沒 test 還真的不曉得怎麼寫怎麼改了。(沒 test 通常就是照前輩流傳的 沒壞的東西不要去動 的準則去做了，想當然爾什麼功能都加不太上去)
沒 test 的 legacy code 這種債務我們很低，不過系統久了，其他地方還是會有債務的。我們去年花了一點時間還了一筆技術債，就是升級 Cassandra，從 thrift 到 CQL。大概花了一、二週寫了一些橋接的程式讓兩種 drivers 能共存。這筆債還了之後我們後來加功能就變得輕鬆很多，直覺好寫又不容易出錯，效能又變好。(大部份的人都對 Cassandra 不熟，我打個比方好了，改版的進步大約是一開始是純 js 的亂七八糟碼，然後後來導入 jQuery 那樣，巨大的改進)
這篇投影片的內容建議：你應當先清償債務利息最高的部份。說得真是好啊，把最大的路障移走後面自然快速通暢了。我上面的例子對我們單位來說就是清掉擋路的大石塊，爽得咧！當然這是一次成功的清償我才會拿出來臭屁啊，其實也有多次的清償都失敗的 (例如 refactor 後也沒什麼顯注改善之類...)
果然我的習慣跟大家不同...
嘛，寫 domain 的話，我覺得有兩個地方不便。
一是當機器掛掉時，你想馬上補一台，在這緊要當口，換 route53 緩不濟及，因為 dns 要一段時間才會生效 (再快也要幾分鐘) ，而且 dns 常常是在這切換的十幾分鐘內，一下指向舊的 IP ，一下指向新的 IP。這完全不能精準復機啊。
二是要移機時，移機的過渡期會有新舊共存的時段 (看服務性質) ，你會先 provision 一台新的，再慢慢引導流量過去。新舊主機共存，自然只能先用 IP provision，等全部好了才會切換 dns。
咦？在 inventory 裡我一直都會替每個 host 做別名，而不是直接用 domain，即使是不用 azure。像是 kaif 就是：
kaif ansible_ssh_host=104.155.193.153
然後 ansible_ssh_host 我也是傾向直接寫 IP，不用 domain。
遇到這個問題是在用 Azure Cloud Service 遇到的。因為 Cloud Service 是透過 1 個 FQDN 去溝通的，它看起來會像是：
yourdomain.cloudapp.net
當你有多台 vm 在裡面的時候，就會把 ssh port 對應到不同的 port，例如：
vm1:22 => yourdomain.cloudapp.net:2021
vm2:22 => yourdomain.cloudapp.net:2022
vm3:22 => yourdomain.cloudapp.net:2023
vm4:22 => yourdomain.cloudapp.net:2024
那麼寫 ansible inventory 時就要寫成這樣子(原來的 host 就隨意取個代號就行了)：
[service4azurecloud]
vm1 ansible_ssh_port=2021 ansible_ssh_host=yourdomain.cloudapp.net ...
vm2 ansible_ssh_port=2022 ansible_ssh_host=yourdomain.cloudapp.net ...
vm3 ansible_ssh_port=2023 ansible_ssh_host=yourdomain.cloudapp.net ...
vm4 ansible_ssh_port=2024 ansible_ssh_host=yourdomain.cloudapp.net ...