新的 Full Line Code Completion1 算是精簡版的 AI Assistant?

居然是蘋果退讓了嗎

macOS Sonoma 14.4.11 已經修好啦

java 8 大家每天都在用了（例如銀行系統），沒必要趕著升級版號

幾乎都是 preview

證實這真的只是 24.0-beta1

真的覺得 java 不需要通膨版號

語言新功能確定的只有「 Unnamed Variables & Patterns - JEP 4561 」，其他都還在 Preview

G1GC 的改進2 不知道差多少 🤔

幸好我還沒升級 XD

囧到爆...

到 preview2 然後全部重來啊

新的 proposal 用起來比較長, 沒有 literal 的感覺

"JEP 467: Markdown Documentation Comments" uses my original method of 2019-02-17, my method offers much more features and visualization, It works with all programming languages and markup languages.!

"Markdown Literate programming that don't break the syntax of any programming language"

https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/markdownliteraryprogramming.md

Live preview in Notepad++

https://github.com/linpengcheng/ClojureBoxNpp

用 /// 來區隔蠻聰明的

不是嗎？gradle 跟著升就上去了呀

The first exciting thing is that if you're on Java 17, upgrading to Java 21 is almost a no-op. It's just super easy

是這樣嗎?

之後會變成類似 MySQL 和 MariaDB 的關係?

ouch

nginx 真的會分家嗎

看到下面說可以輕鬆輸出成 YAML, json, XML 我就笑了

Apple spring boot team 弄的吧

這個要錢…

這個格式是 binary ，只能存 UTF-8 字串跟 NULL，但是很容易讀寫。應該有不少用途。

透過在library外包java.util.concurrent的方式避開synchronized還真不錯

看佔有率 (Share) 那一欄的話，只有前五名是大於 5% 的。這指標會不會有點偏心... （例如：偏向會費心力做 SEO 的社群）

比較大的問題 switch (x)

x 沒有被大{} 包住居然吃掉了 exception

image 名要是 UUID，tag 代表使用期限（最多 24h）。

很奇妙的使用方法，但在 CI Pipeline 內來使用好像十分合理。

Android 開發者替另外一邊的人寫問題也很多:

• 為什麼我這邊工作比較多？
• Android 開發者寫 kotlin 給 iOS，那最終他還是要會 iOS 的東西。會雙修的人就是兩邊都會寫了，不會找這種工具來用。不想雙修的人會去找 flutter ，而不是 KMP

Mono repo

iOS/Android 兩個專案肥的跟什麼一樣，tool chain 也很混亂，放在一起會很痛苦

原本的 code base 要把業務邏輯切得夠乾淨

這基本上要三修的人 (backend/android/ios...etc) 的人來規劃才有機會做的好，然後沒有這種人。就算有，他也不太可能指揮所有部門聽他的

去年稍微摸了一下 Kotlint Multiplatform，總讓我一直想到 LLVM。

當時的需求是有一段業務邏輯，需要在 SpringBoot Server/Android/iOS 三個平台上面做同樣的處理，但不希望寫三份。如果當時採用 KMP 就能用一份源碼生出三個平台都能用的 library。就當下來說滿符合我們的需求，最後沒採用是因為它的版號仍然是 beta，公司覺得有風險。

就我對其他跨平台方案的粗淺理解(實在不太想花時間去理解這類方案了)，多是希望開發者在一個抽象層上實作，藉以避開各個平台的差異。KMP 則是僅提供 Primitive Class，再去生出各個平台的函式庫。

原文認為會有 ego 問題，要求 iOS/JS developer 去寫 Kotlin 會有難度。我覺得可以有另外一個切入點：「如果公司有 Android/iOS dev，那就讓 Android 的人多寫點 code 給 iOS 的用」，在我的角度來看應該難度沒增加。(至少當時我的 iOS dev 同事還滿期待前述的那塊邏輯他不用管 XD)

我反倒覺得 KMP 的難關在於，許諾的事情太少，但是引入的成本頗高。

譬如說，它要 Android 跟 iOS 放在同一個 Parent directory 底下，這在沒有 Mono repo 的公司就很難做到。若是獨立一個 Repo 專門處理業務邏輯，又要考慮如何把生出的 binary 放進 Android/iOS repo，這是對於開發流程的影響。另外，多一個external dependency，偶爾又要擔心版本問題。

最難的是，原本的 code base 要把業務邏輯切得夠乾淨，才能享受到 KMP 的好處，但是大公司的 code base，尤其是 client side，通常都不容易做到這點。