Like git, but on the App Store Review Guidelines.

圖1

我不信我那台 NAS 可以行 gitlab 啦，但支援 docker 比原有本只限安裝不明內容的 package 透明多了。

不知十數年後回望今天科技會是怎樣？

解放 Facebook 黑洞這種事太好了！

要試過才知 auto layout 是否較慢了。

AsyncDisplayKit, Components, React Native。他們不同的團隊做不同但有部份相似的東西。

Components 和 React native 都是用 react 的概念。而三者都有 background render 。。。(所以説 FB 現在的 iOS 團隊真是很厲害

感謝感謝感謝!

Components 可說是將 React 的概念帶到 iOS 上的專案，在之前他們的演講聽到他們內部已用了一段時間。Facebook's iOS Architecture1 有詳細講它解決的問題。

相信會在月底 F8 會開放吧。

wat, for C programming language

也好，現在還放在 Google Code 的大多是已死的東西吧

現在不斷在各區 refresh 中 :)

「新消息」

能夠有數字泡泡就好好了。

有 News Feed 就是有可以訂閱的討論區吧？！

但我很喜歡這樣！！ 認真喜歡這種平台因為可以推到原文，不用把所有東西放在 Facebook 黑洞裡啊

明明是 hackernews???

自動計算高度只是基本啊，還有更多更頭痛的。

有人問「為什麼不用 nib ?」nib 對於固定的介面來說是最好的，簡單易作 (假設你學懂了怎樣用)，要說缺點的話 只是不好維護、沒有重用性而已，但因為很易做，那也沒大問題。

但是當問題比較複雜的時候，就非要用手動方法做不可了。

比如說我想做 Facebook Feed ，我有很多種不同的 Feed：

• 基本 post
• 有圖片的 post
• 有影片的 post
• 有 quote 的post
• 某人 like 了某個 post
• 某人分享了某個 post

如果這些不同的條件下的 layout 可以稍為不同 (比如說 margin 或 font size)，用 nib 作就會很煩了。 有些時候可以用一個 layout 一個nib 蒙混過去，但如果以上變化可以組合呢，需要動畫化呢？這時手寫就是唯一解決方案。

習慣了的話用 code 比 nib 更簡單更快，也可以很好讀。所以不要怕用code layout 。Masonry 是個很漂亮很好用的 API ，考慮到很多常用的情況 (如更新 constant 不用存 constraint 的 reference) 。

要是說最需要注意的地方只有一個：把複雜的 View 分拆，組合不同的較少的元件。例如 post 可以分作 header ，body 和 footer。header 有頭像有名字、footer 有 Like / Share / Comment 等等。如果在一個 View 裡做的話，layout code 很快就會暴漲，有很多 branch，有錯誤時 (在 Auto layout 時很容易發生) 也很難找到原因。現在回想這很明顯，但這是浪費了無數光陰才明白的。