IngramChen 積分 0

這一次 nexus 主題自然是 VR 了,可以期待

IngramChen 積分 0

ブラスト出來啦!

原來是要搞第二英雄勢力的樣子…

IngramChen 積分 3

先有其他語言背景的人,再去寫 js 通常會吐血…

IngramChen 積分 0

太晚知道了…

不過 cache 的最大問題還是在 distributed eviction 和 versioning…

IngramChen 積分 11 編輯於

十年前 Rod Johnson 說了 J2EE is dead,然後就有了 SpringFramework,當時成為一股風潮。之後 JEE 6 好不容易有跟上的聲勢 (加了一堆 Spring/Hibernate 的概念),一堆 JEE 傳教士紛紛跑出來說不該再用 Spring …

時至今日,cloud 已是佈署的基本款,不管你有沒有用 docker/microservice,你都會想用小 server 裝個小服務 (因 cloud 很適合開一堆小 VM)。什麼都全包的 JEE container 忽然間失去了魅力。然而 Spring 卻在這時推出了 Spring Boot,一整個打中潮流和需求點,於是 JEE 再度被 Spring 打敗一次。這篇文章也點出大廠都不把心力放在 JEE 上了,跑去搞 cloud,JEE8/9 沒有任何下文…

Spring 當初打的名號是 lightweight container,每個元件都是可以隨需求自己加上去,不用硬包在一起,這個起步式在十幾年前是對的,到了現在還是對的。這並不是風水輪流轉的緣故,而是這是軟體界永遠不變的真理。

Spring 中期也是搞錯好幾次方向,像是 Ruby on Rails 剛興起時,Spring 也跟風去搞什麼 Groovy,然後又做 command line 工具 spring root,可以像 Rails 一樣幾個指令就生一個 scaffolding。結果 Rails 潮流結束後這些東西就乏人問津。接下來 Spring 又去搞 OSGi,這也是浪費了無數的資源,去完成一件錯誤的產品 (太難懂、太難用、沒有迫切需求… ),接下來就被 VMWare 給買下了。

話說回來,Spring Boot 這新產品很受大家喜歡,歷經中期一連串的失敗還能再站起來還真是不簡單。Spring Boot 當然是跟上現在的 cloud/microservice 潮流才會起飛,但這產品在十年前出的話,我自己也會想用,所以也不盡然是風潮的關係。我想是因為它真正解決了問題 (簡化設定和佈署),又沒有增加任何難度 (你不用再多學一套工具像是 docker 什麼的,它終究是個 .jar 而已)。

----

老骨頭講古講完了… 說實在的,新生代 web 開發者選擇後端的話,通常是 nodejs > rails > 其他平台 這種順序,Spring 再好也是老骨頭才會去選吧。

IngramChen 積分 0

比較大的問題是拿同個 certificate 給 mail server 用,通常 mail server 都沒有管的很好…

IngramChen 積分 0

oh, stackedit 我也有用,不過是拿來寫長文了,不是 quick note

IngramChen 積分 1

這歌是原創,日本人為了做廣告真的請廣東人來填詞唱歌,真是扯

是說這類型的歌市場上很少的樣子,流行歌都是風花雪月故作愁悵... blah blah

IngramChen 積分 0

Xamarin 的價格是 一年一個工程師一個平台 1000美金… 哈哈

IngramChen 積分 0

dedicated 規格好殺… 可惜沒亞洲的

是說現在都自動化 deploy 了。用 dedicated 還是 cloud 其實沒什麼差 (除非你想要 auto scaling)

IngramChen 積分 0

啊,我猜是未來 scala 不是唯一的主力產品…

martin odersky 不是再玩新語言嗎?搞不好那個語言不是 type safe 的 XDD

IngramChen 積分 0

android app 閃退原因多是 exception,大部份是 NullPointerException。

我不是說 android 有 GC 所以 bug 會比 swift iOS 少,閃退會比較少。我只是說 iOS crash 的原因很多是 dangling pointer,是因為要手動管理記憶體造成的。

這個現象對 server 是不利的。Java 是很多 NPE,但在 server 環境下就只是個 bug 而已,process 還是可以繼續服務。swift 踩到記憶體就是整個 crash,這不利 long running application 啊。(mobile 上到是無所謂)

ARC 也許可以再進化,解決這個問題吧 (例如它找到一個演算法完全解決 circular reference),不然只要讓開發者去寫 unowned 這種東西,就是有機會踩記憶體 crash。(有誰的 app 沒 unowned ??)

IngramChen 積分 0

那閃退的大部份原因是什麼?

IngramChen 積分 0

mysql nginx...etc 什麼的也是用 c 寫的,但我覺得那是集大眾人的智慧的結晶辦到的偉業。

我不覺得一般網頁應用程式開發員達得到他們的水準啦

IngramChen 積分 0

memory leak 和 process crash 怎麼相提並論。有 GC 又不代表不會有 memory leak,這前提還要討論嗎?

問題是沒 GC 你除了處理 memory leak ,還要擔心不小心踩到記憶體,踩到記憶體的懲罰又很嚴重 (尤其不適合要跑好幾個月的 process)

ARC 的確可有效減少踩錯,但跟完全不會踩錯的 GC 比又差了一截,這是很明顯的缺點啊。

IngramChen 積分 0 編輯於

ARC 又不是萬能的,我不相信有個 iOS app 從來沒踩過 dangling pointer。哪個具規模的 app 不會閃退?

IngramChen 積分 0 編輯於

swift ... 這種沒有 GC 的語言,適合跑 server application 嗎?

server 的程式通常都要跑個幾個月,有一點點 memory leak 就會逐漸累積,跟 desktop/mobile app 的使用行為差很多啊。mobile 上就算有點 leak,用戶也是常重開 app,沒什麼差。

除了那種很專精功能的 server 程式,通常寫應用程式型的 server ,需求和功能都很雜亂 (尤其是開發了一兩年後… ) 這種情形下還要開發者自行管理記憶體真是太痛苦。

還有,踩到 dangling pointer 怎麼辦?整個 swift process crash 嗎?一旦 crash 了,process 裡的 state 就通通消失了… (反觀 Java 的 NullPointerException,死也是死個 request 而已)

IngramChen 積分 0

步驟還是太多了

沒有 wildcard 還是很不方便

IngramChen 積分 0

EmojiOne 的圖太平了,縮小後常看不清楚是什麼。emoji 還是要有一些陰影和溝紋會比較好

IngramChen 積分 0

這是要下市嗎?還是拆掉賣?