IngramChen 積分 0

undefined 直翻 未定義 就好了吧。翻 不存在 反而容易和 null 搞混

haocheng 積分 0

Switch 大概是能夠舒服手持的大小上限了,Steam Deck 更大更重真的不覺得會想要長時間拿著玩…

koji 積分 0

這也太恐怖了XD 但想想確實面試的人如果不是同team,會不會出現這種狀況

haocheng 積分 0

OS 支援是一個問題,但那個不太像是掌機的大小可能是更大的問題…

gugod 積分 0

# SEO To be fair, this would probably be an issue with any search engine, but you’d expect Google to be able to come up with a less gameable algorithm.

這個 "Less gameable algorithm" 多半指的是推薦與排行演算法,但是真的很難做到「夠平衡」:在有爬到新的網頁時,既要讓它們能有一定的曝光度,又不能讓它們取得高排行。

haocheng 積分 1

LINE APP 裡面還是可以用一卡通,是新版的 LINE PAY APP 不支援而已

chchwy 積分 1

有點混亂,所以以後到底還能不能在 LINE 用一卡通Money?

gugod 積分 2 編輯於

直接把 graphql api endpoint 接到公開站的這種做法... 對我而言還真是看不習慣。先假設 ACL 也一併做得夠好的話,對於前後端開發人員來說似乎是能省下在開發階段定義各 API 規格的時間。

不過只要 ACL 沒能弄好,或是讓人找到 root 帳號,就等於是資料外洩了。似乎少了防守的一些手段。

haocheng 積分 1

原來如此,那跟我的認知差不多

我們也遇到類似問題,公司內部的 K8s 本來是建議一版一版升級,但後來發現發布版本的速度太慢了跟不上,所以可能會跳過中間幾版直接升級到新版本,到時候我們應該也要開新的 cluster 來升級...

kaif 積分 3 編輯於

都用 post 應該很大一部分是大公司中應付高司資安單位稽核的 best practice。

為了避免 Fortify 這種靜態分析工具亂叫,報告寫不完。

IngramChen 積分 0

最多跳兩版, 但不建議

這裡所謂的跳版升都是重蓋一個新的, 再將服務搬過去

haocheng 積分 0

原來可以跳版本升喔,我還以為 K8s 只有支援一版一版升上去

IngramChen 積分 2

POST 不能 cache,所以有需要 cache 的需求下,一把梭是錯誤的做法。 所以還是給自己一點彈性吧,沒有絕對正確的 rest api 作法

IngramChen 積分 0

這就是 k8s devops 的日常

這文就是直接從 1.18 跳升 1.22 ,沒有在管中間版本的。但即使是這樣一年就要大升一次很痛苦

haocheng 積分 0

不太確定太肝是指什麼?這一代抓寶不一定要進戰鬥其實是很大的改進,遊戲節奏快很多

phonikas 積分 0

看完預告影片覺得太肝了,不想整個過年都花在上面 默默地把預購給退掉 #期待下次會更好