這個問題做 messager 的大概都會遇到。
如果 id 沒用來排序的話，那就用 type 4 UUID 來解，client/server 都能自由產生 unique id，這樣問題就少很多。
不過很多資料都有時序，而某些資料庫也真的只能用 primary key 來排序 (ex. Cassandra) ，那這時候就很痛苦了。這篇提到的前兩種做法我個人都用過，可以解但真的挺痛苦的。
他最後的方法是全 id 轉換，這… 雖然他們說可行，但我想到要 debug client side 的資料時，全部都要轉成 server id 才能和 server 核對做 debug... 這是另一種層面的痛苦呀
python 在教學和數值運算有不可取代的地位
nodejs 則是永遠都能留住只寫 js / front end 的開發者
scala 則真的快死了, 現在緊抓著 big data 不放. big data 消失了, scala 就bye bye 惹
go 則是剛起來沒多久, 不過他能做的別人都做的到, 就記憶體吃少一點而已. 但是玩記憶體又玩不過 c/c++ . 他找不到不可取代性的話, 風潮過後也不行了吧
“Is there anything Rails can do, that PHP can’t do?”
The answer is no.
Ruby 沒有別人做不到的事情/強項，這語言最後就是回到 Rails 紅透半邊天前的狀態…
明明這指令 +XX:UnlockCommercialFeature 應該要追加一串購買的 license key 才能啟用的，oracle 卻不做，只想做成陷阱，不愧是律師事務所
日本推友摔壞了手機，結果克難的用滑鼠操作。asus japan 回推說你掉的手機是金的 zen phone 嗎？推友認真回說那支金的不是我掉的，我的是 zen phone 5。
asus japan 說你真是誠實的人，然後就送一隻金的 zen phone 3 delux 給推友~~
我以前也是 Hibernate expert 咧 (自稱)
不過用了幾年後就丟棄了… 現在變 JdbcTemplate expert 惹
唉，如果有仔細研究 Hibernate 的 source 就知道他們設計的真是精良，是非常懂物件導向和關聯式資料庫的人設計的，使用 Hibernate 也會讓你感覺到你是在處理物件的生命週期，而不是關聯式資料。
問題大概就是資料本身本來就不適合用物件導向解決吧，尤其是資料可能很巨量。物件導向它是強在 UI 元件…
很扯...
- 支援 SQL select/join/subquery/index ...etc
- 不支援 DML (要用它的 client)，猜測是目前只限於做 primary key 相關的 update
- 開一台 0.9 usd/hour，儲存和傳輸另外算錢
每一 instance 的能力 :
each Cloud Spanner node can provide up to 10,000 queries per second (QPS) of reads or 2000 QPS of writes (writing single rows at 1 KB data per row), and 2 TiB storage.
0.9 usd/hour 相當於 aws m4.4xlarge (16 core/64GB ram)
就新東西看一看玩一玩就好，不用太深入。除非它馬上就能解決你一直撞牆的困難 (例如某些 NoSQL 資料庫)，才有必要正式導入。
如果過了一、二年後還有人繼續投入和成長，那時再引進都不算遲 (隨便一個production 系統都麻要跑五年以上...)
文中建議三種 ansible 本身的安裝方式，不過我只建議大家用 pip 裝。
為什麼？
因為 ansible 的 bug 很多 (他們沒有 test case) ，雖然會修啦，但許多 hot fix 的版本只會放在 pip ，而不會上 apt repository。所以裝來裝去最後都是用 pip 裝了