IngramChen 積分 0

這表太好用了,每次設 head 都要到處找老半天…

IngramChen 積分 0

連 hacker news 都沒出現這則

scala 已經...

IngramChen 積分 3

scroll 到了 40% 了,還在 setup 環境… 有沒有搞錯啊

這麼長的 setup,這麼多的環結… 每個子項都是一種 dependency 啊,這以後會付出代價的 (technicl debt)

IngramChen 積分 1

四大類用法講解的很詳細

不過像我們公司不到 10 人所以用法是混在一起的 (沒有 pull request,但是有 release branch...)

IngramChen 積分 0

如果有 32GB ram 以上的話會比較想換了,現在的 15" 2kg 也太重。

舊款的二手價不知如何

IngramChen 積分 0

正在升 2.0 , 不會太難改

2.1 都 windows, 感覺他們搞錯方向了

IngramChen 積分 4

啊,這樣就很好懂了。來分析一下 Java 領域的 Spring:

  • Spring is Simple
  • Spring Boot is Easy
  • Spring AOP is Easy

原始的 Spring core 是很單純簡單的,所以你才會看到這麼多 xml (因為每個設定都 explicit 寫出來)。Spring 的每一行都很簡單,但是卻需要 很多行 才能完成功能。

Spring Boot 卻很容易 (Eazy),它的一行設定可以達成很多事,很多 magical 的事發生在後面,就像 Rails 一樣。雖然寫的行數變少了,但它的每一行都很難 (Not Simple) ,你實際去 trace 就知道有多難懂和複雜。

Spring AOP (Aspect oriented programming) 是很容易的,寫幾個 annotation 就能辦到很多事,不過背後裡,它替你的程式加了許多工,等到真的去 trace 時就知道有多複雜。AOP 歸類為不簡單 (Not Simple)

基本上 Simple 優於 Easy,從長程來看的話。Simple 的程式行數多,但每一行都很好懂,所以維護的成本低。反之,如果專案的生命越短,開發人數少,Easy 就比 Simple 更有利。

如果要比較 Spring Boot 和 AOP 維護的難易度 (不是比功能,這兩個功能完全不一樣)。Spring Boot 比 AOP 好。因為 Boot 只是處理 configuration 而已,而 AOP 則是會涉入 domain logic。

configuration 基本上搞懂之後,不會影響你接手處理用戶的需求的。但 AOP 在 domain logic 玩魔術,會讓接手處理需求時很痛苦,每次改功能都要追後面有多少奇妙的 side effect 偷偷在發生。

從 Easy vs Simple 的論點來分析 Spring,我的結論是 -- Spring core 可以大膽的用,Spring Boot 也是,但 Spring AOP 則要謹慎,不要用過頭了。

當然,我說的可以大膽的用,不是代表可以惡用。早期在 Spring 盛行時,很多人把 domain logic 混入了純 Spring 寫 (後果是 xml 爆增)。而新一點的 Dependency Injection Library - Dagger2 ,我也聽說過有人用它處理 Observable (RxJava),讓 domain logic 侵入了 D.I. 。這都是惡例,小心不要踩到了。

IngramChen 積分 0

blue print mode 在連 constraint 時的動畫很好玩

IngramChen 積分 0

gradle 總算會自己下載 android sdk 了… 以前都要自己 mirror 一份

IngramChen 積分 5

如果有寫過 messaging 之類的 web app,那架構上多半會摻了類似的概念。

不過這種全靠 persist socket 的做法有很多缺點:

  • 你要處理訊息接受次數可能是 0, 1, 和多次。本來 http 的傳統架構是 request-response,只有失敗和成功兩種結果。如果是 message queue 的話,就有可能因為斷線重連而變空炮彈 (server 有回你但你沒收到),光是要解決這問題就很煩了。然後這問題接下來衍生更難的困境

  • 即然 client (browser) 會掉訊息,那麼 server 的行為就需要變成 "最少送成功一次"。這意味有很多情況是同個 message 會重覆發 (在斷線頻發時),client side 的程式要能處理這種狀況。想也知道要花多少精力維護這種狀況 (every operation must be idempotent)

  • 這問題在 mobile web 上更是嚴重,persist socket 一天斷個十幾次 (3G/4G 隨便斷線的)。在桌機 browser 沒看到的問題通通跑出來了,寫到最後你會想放棄的。

  • 這篇作者提的架構是適合 Single Page App (SAP)。但在 mobile web 上這架構不是很討好,client side js render 在手機上其實很慢,最後都要回歸 server 來 render,而且也不是所有服務都適合 SAP。

  • 最後用 websocket 的省頻寬,省連線數什麼的,這問題在 http2 下已經解決,所以這優點已經消失。

IngramChen 積分 1

flutter 就是用 reactjs 的概念去寫 cross mobile platform app。語言是 Dart,執行期是 native ,不過 UI widget 是他們自己刻的 (skia/mojo)

IngramChen 積分 0

現在美國小孩是跟著 chrome book 長大喔

IngramChen 積分 5 編輯於

流量很低,每秒 1K Byte 流量吧。

資料庫不到 100MB。

medium size two core 的雲端主機,CPU usage 不到 10%,這台 google 的每月要付 70 美金吧。這台當然是過剩了,也許半價以下的主機也跑得動

.io 的 domain 比一般 .com 貴三倍 (不過 domain 沒有人在算成本吧)

IngramChen 積分 0

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