雖然 feature complete ，不過離 GA 還有三百多天...

S3 只是一個付費的服務，沒有開放原始碼也沒有 spec，算不上是標準吧

JP 還沒開放之前我在 CF 就有用了，不知道有什麼差

應該是 extend string 的 method

好緊張喔！不會用 kotlin 怎麼辦~~~

CDMI? 那個好像沒人理她...de facto standard就是S3吧

def 我難過(String s) {
    println s
}

"我難過"("的是放棄你放棄愛")

"testCompile"("junit:junit:4.12") !?!?

Object Storage 其實當初有個規範喔~所以大家可以做...XDD

現在object storage也太多家了...搞的好像門檻很低一樣xd 差別在哪也分不出來了

好像沒啥特別的，就 Java 9 本月 feature complete !?

最近寫/改scala特別有感啊XD

我也都先寫 return result;

這根本就是自嗨業配文嘛

不用 static import 啊。

static import 那些小工具 method， IDE 是會幫忙，但其實寫起來不順手 (太多個了)

我現在 fixture 已經開始這樣用 mix-in 的寫法了

對非測試的 library 做 mix-in interface還理解，但對測試的 library 做好像感覺不出什麼好處。

inline 太扯有時也會很難過就是，到最後都是一種“感覺”....

對打得每個字斤斤計較，要讓程式每個字都有意義。

我個人覺得OTV的問題是讓code變多行，要多花力氣讀吧。實務上效能的問題是因為OTV的case應該很罕見吧..

你的 link 裡面的寫法，類似 TDD 開發流程了 (先從一個無用的結果開始，然後漸漸長大… etc)

OTV 的話，有時候是為了 debug 方便，有中間變數 breakpoint 比較好設。

OTV 多起來命名也是有點討厭就是，本文的範例裡，它說宣告和使用位置相近的話，可以縮到剩一個字：

 List<Host> hs = s.fetchHostsWithPackage(obsoleteVersions);
 Workflow w = startUpdateWorkflow(hs);

雖然作者這樣說，但我個人的經驗還是不會去寫 hs, w，最少還是會寫個單字

 List<Host> hosts = s.fetchHostsWithPackage(obsoleteVersions);
 Workflow flow = startUpdateWorkflow(hosts);

沒差幾個字，卻比較好懂，在 IDE 裡通常也是打個字頭就 auto complete 了，沒有必要省成這樣…

大概從 5 年前，我開始大量使用 OTV，從當時寫的一篇文章開始 Link1 。在大量使用 OTV，並取適當變數名之後，即使註解寫的不多，也不會造成閱讀的困難。當然，是否容易閱讀可能取決於個人。但後來我想清一件事，我好像沒義務寫到每個人都讀的懂，但至少自己在半年之後還能讀的懂，這樣就夠了。

OTV 的問題在於有很多人誤以為這樣會降低執行效率。對某些語言也許會，例如 Python，這類語言因為是在 runtime 編譯，因此無法做太多 optimization。但對於 C/C++/Java 這類語言，如果會降低效能，那就是 compiler 的問題了。不如等到實際 profiling 之後，再針對 bottleneck 做局部改善。(前幾天 ptt 好像有人在抱怨主管時，也討論到類以問題)

顯然, 除了 Java 和 Ruby 之外，他沒寫過任何其它高階語言 XD

後面提到的如果變數定義跟使用位置很近的話就可以簡潔寫還不錯...

沒寫好 (thrift socket 跟 REST) 都切到 http2 之上...之前的 socket implementation 有點遜(? 不是 multiplex ...

看他們找到的 nginx 缺點好煩啊… 讓 operator 不安