haocheng 積分 0

喔喔,這一版有支援 JDK 11 了

haocheng 積分 0

Grails 作者新開發的 microservice framework

haocheng 積分 1

OpenJDK 8 至少會支援到 2023 年

At Red Hat, we intend to provide support for OpenJDK 8 to our customers until 2023, and our policy of always “upstream first” implies that OpenJDK 8 will continue to be updated for critical bugs and security fixes until then.

koji 積分 0

看來才剛開始,只有1-n。在這種情境下要寫n-m 感覺有點麻煩。

IngramChen 積分 0 編輯於

AuthorRef 這個想法有趣。不過大多數的 relation 都不是 aggregates ,這不是變成 8 成以上的 relation 都要多加一個 *Ref class 嗎?

haocheng 積分 0

這麼說也是,不過台灣金融業都要 IBM,所以應該就直接跟 IBM 買支援了?

koji 積分 1

如果這樣賺翻的話表示會顧更多專職開發者? 應該會是好事?(然後其實是更多律師跟業務XD

IngramChen 積分 0 編輯於

金融業才不管什麼划不划算的咧…

haocheng 積分 0

會嗎?以現在 Oracle 的計費方式,我猜很多公司會考慮 Azul 這種有上限的比較划算,或者本來有買 RedHat Linux 的公司就用 RedHat 上的 Java 了 XD

IngramChen 積分 0

這個模式再 run 個三年就知道了。

結果… 是 Oracle 賺翻了

natsu 積分 0

另外架 DB 去改 OS 參數是很常見的事,裝過 Oracle DB 就會知道。

寫程式十多年都沒有聽 DBA 提起過有這回事 ...

可能是我和 DBA 比較不熟吧 XD

P.S. 一般開發時用的 DB (測試區) 都是用預設值 ...

IngramChen 積分 1

一般而言都不用動到,postgresql 舊版的預設參數都很保守,現在好多了。

另外架 DB 去改 OS 參數是很常見的事,裝過 Oracle DB 就會知道。

natsu 積分 0

沒想到架個 DB 也需要改到 Kernel Parameters ...

不過應該是 PostgreSQL 有丟出相關錯誤訊息時才需要改吧?

haocheng 積分 1

結論:

But if you just want the "standard", currently my best advice is to use the OpenJDK builds by Oracle, AdoptOpenJDK builds or the one in your Operating System (Linux).

linus 積分 0

大部分的內部 AP 系統開發, 如果已經走 microservice 架構, 應該比較少機會用那麼多的 RAM吧.

IngramChen 積分 1

自從外包給 RDS 後現在都沒機會動到這些設定了

kaif 積分 0

之前elasticsearch有建議heap不要開太大 有這個應該就不一樣了

natsu 積分 0 編輯於

ZGC restricts itself to 4Tb heaps which require 42-bits, leaving 22-bits of possible state of which it currently uses 4-bits: finalizable, remap, mark0 and mark1.

喔喔,4TB 耶!

不過可能也沒機會用到這麼多 ram ...

haocheng 積分 0

沒錯,除非你有付錢買 support,不然還是轉 OpenJDK 吧…

IngramChen 積分 1

總之要有一個觀念,Oracle JDK LTS 有跟沒有一樣,都是只到半年。

natsu 積分 0

純 rest 要用名詞, 所以要改寫成 /user/{id}/approval。

我是有看到用動詞的例子:

要講究純 rest 到最後變得像是在考文法一樣, 咬文嚼字, 我個人是不太喜歡浪費時間在這種地方啦。

說的也是 ...

而且用 PATCH 就對了嗎?approve user 這個動作有可能改到三個 Table 以上,不一定是只改 user.approved 這個 boolean flag 而已啊。

我只是覺得 approve 這個動作應該只是在 update 資料,所以用 PATCH 比較合適 ...

不過改三個 Table 有可能代表了同時修改三個資源,這部份 REST 目前也沒有規範到 ...

就像您說的那樣,最後會是 REST 和 RPC 混用吧

IngramChen 積分 0 編輯於

純 rest 要用名詞, 所以要改寫成 /user/{id}/approval

要講究純 rest 到最後變得像是在考文法一樣, 咬文嚼字, 我個人是不太喜歡浪費時間在這種地方啦。

而且用 PATCH 就對了嗎?approve user 這個動作有可能改到三個 Table 以上,不一定是只改 user.approved 這個 boolean flag 而已啊。