Tag: programming

Java 17 (JDK 17)，新的 Java LTS 版本 (然後來看 GC)

Java 17 (JDK 17) 釋出，這是 Oracle 本家新的 LTS 版本，引用的是 jdk-dev 的 mailing list：「Java 17 / JDK 17: General Availability」。另外在 Hacker News 上的討論可以翻一下：「Java 17 / JDK 17: General Availability (java.net)」。

上一個 LTS 版本是 Java 11，所以很自然的也會有從 Java 11 之後的新功能說明：「JEPs in JDK 17 integrated since JDK 11」。

對於只是拿來用，而不是拿來開發的人來說，我的重點都放在 JVM 的 GC 效能以及特性。

從 Java 11 預設的 G1GC 來看，可以看到一些改善，從「JEP 345: NUMA-Aware Memory Allocation for G1」(Java 14) 這個看起來會改善 G1GC 在多實體 CPU 的情況下效能，不過看起來有 -XX:+UseNUMA 這個參數要加。

再來是「JEP 346: Promptly Return Unused Committed Memory from G1」(Java 12) 可以在閒閒的時候跑個 GC 把記憶體給 OS。

接下來是兩個新的 GC (相較於 11 版)，一個是 ZGC，另外一個是 Shenandoah，都沒有取代 G1GC，但兩個都有對應使用的場景。

ZGC 有列兩個 JEP：「JEP 376: ZGC: Concurrent Thread-Stack Processing」、「JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)」，目標是讓 GC pause time 盡可能的低，另外在 wiki 上面的說明則是有提到目標在 1ms 以下：

The ZGC garbage collector (GC) aims to make GC pauses and scalability issues in HotSpot a thing of the past.

Sub-millisecond max pause times

Shenandoah 列出了「JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)」，不過先前的「JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)」講的比較詳細，目標是希望 GC 不影響目前正在執行的程式：

Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.

可以看出來兩個新的 GC 都是希望降低 pause time，對於 latency 敏感的應用應該都可以測試看看，可以預期整體的 throughput 會低一些。

回頭來看 G1GC，有人跑了 benchmark 測試了 Java 11 與 Java 17 的 G1GC 差異：「How much faster is Java 17?」。

可以看到 G1GC 的改善 (藍色的部份) 看起來還是不少，不過有些情況下是會變慢的。文章裡面還有提到 Parallel GC，這邊就不提了，可以自己看...

等各家 build 出來後來測看看 Cassandra 的效能影響如何...

Simon Willison 提出來的 PAGNIs

Simon Willison 提出來「PAGNIs: Probably Are Gonna Need Its」，整理一下裡面提到的功能。

第一個是 kill switch，在 API 設計上一開始納入強制升級的傳回值，文章裡面有提到一些情境。

第二與第三剛好就是 Test + CI + CD，常常是 best practice，除了文章裡面提到的東西，在其他人的文章裡面應該也都有類似的討論。

第四是 API 的分頁，這個部份只講了要分頁，沒講到分頁時資料庫的效率問題，這部份可以參考「API pagination best practices」這邊的討論，key-based 的 pagination 效能會比較好，也可以避免對資料庫的 DoS 攻擊。

第五是 API 的 log，作者的建議是一開始什麼都存起來，等量大的時候再拔掉，會對於初期開發與除錯很有幫助。我是會掛 Sentry 這類的東西，有錯誤的時候會記錄起來。

第六看不懂他想要幹什麼，先跳過去。第七是在講要盡早實做這些 practice，等專案都推出去後再回過來實做都很花時間。

有些可以練手一下...

GitHub 與 OpenAI 合作推出的 GitHub Copilot

在 Hacker News 首頁上的第一名看到 GitHub 與 OpenAI 合作推出了 GitHub Copilot，對應的討論可以在「GitHub Copilot: your AI pair programmer (copilot.github.com)」這邊看到。

GitHub Copilot 會猜測你接下來會想要寫的「完整片段」，像是這樣：

不過 Hacker News 上面的討論有參與 alpha 測試的人的評價，大概 1/10 機率會猜對，即使如此，他還是給了很多有用的資訊 (像是函式與變數的名稱)：

fzaninotto

I've been using the alpha for the past 2 weeks, and I'm blown away. Copilot guesses the exact code I want to write about one in ten times, and the rest of the time it suggests something rather good, or completely off. But when it guesses right, it feels like it's reading my mind.

It's really like pair programming, even though I'm coding alone. I have a better understanding of my own code, and I tend to give better names and descriptions to my methods. I write better code, documentation, and tests.

Copilot has made me a better programmer. No kidding. This is a huge achievement. Kudos to the GitHub Copilot team!

然後也有人笑稱總算找到理由寫 comment 了：

pfraze

They finally did it. They finally found a way to make me write comments

反過來的另外一個大問題就是 copyright，這點在目前的問答集沒看到... 在 Hacker News 裡面的討論有提到這點，但目前沒有完整的定論。

目前只支援 VSCode，以後也許會有機會透過 LSP 支援其他的編輯器？

另外我想到 Kite 這個 machine learning 的 auto complete 工具，沒有那麼強大但也還不錯？

用 Semgrep 掃一些安全性的問題

在 Hacker News Daily 上看到「Semgrep」這個軟體，看名字本來還以為是 semantic grep，結果是個靜態分析工具：

Static analysis at ludicrous speed
Find bugs and enforce code standards

專案是用 Python 寫的，可以直接用 pip install semgrep 裝起來，然後直接下指令掃，像是在自己的專案裡面執行，這邊用的 ruleset 是 r2c-ci：

semgrep --config=p/ci .

官方網站上的截圖看起來也整的不錯：

可以自己跑或是掛進 CI 裡面跑...

一個有趣的面試問題

在 Hacker News Daily 上看到「Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust」這個有趣的面試問題，在 Hacker News 上的討論也可以看看：「Performance comparison: counting words in Python, Go, C++, C, Awk, Forth, Rust (benhoyt.com)」。

問題是這樣：

Write a program to count the frequencies of unique words from standard input, then print them out with their frequencies, ordered most frequent first. For example, given this input:

The foo the foo the
defenestration the

The program should print the following:

the 4
foo 2
defenestration 1

在面試時，重點不在於用哪個程式語言，而是在面試時一路往下問，像是 profiling 的部份，內部資料結構的部份，可以問得很深。

撇開面試，這個問題其實是個經典問題，當年 Donald Knuth 與 Doug McIlroy 兩位大師都有玩過：

Incidentally, this problem set the scene for a wizard duel between two computer scientists several decades ago. In 1986, Jon Bentley asked Donald Knuth to show off “literate programming” with a solution to this problem, and he came up with an exquisite, ten-page Knuthian masterpiece. Then Doug McIlroy (the inventor of Unix pipelines) replied with a one-liner Unix shell version using tr, sort, and uniq.

不過當年玩的問題有點變形：

Given a text file and an integer k, print the k most common words in the file (and the number of their occurrences) in decreasing frequency.

他們當時其實一個是在示範 Literate programming，而另外一個在展現 pipe 的威力，都是借題發揮而已，跟上面的那些東西倒是沒什麼太大關係。

Martin Fowler 在 2015 年寫的 MonolithFirst，以及 Microservice 的問題

在 Hacker News Daily 上看到「MonolithFirst」這篇，是 Martin Fowler 在 2015 年寫的文章，對應在 Hacker News 上的討論「Monolith First (2015) (martinfowler.com)」也頗有趣的，可以一起翻。

tl;dr：他的文章就是在講新專案用 monolith，不要去碰 microservice。

文章開頭提到了就他觀察到的情況：第一點是，幾乎所有成功的 microservice 案例都是從 monolith 起頭，再轉到 microservice 環境；第二點是，幾乎所有一開始用 microservice 的案例，在後來都遇到嚴重的問題：

As I hear stories about teams using a microservices architecture, I've noticed a common pattern.

  1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up
  2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .

文章接著有兩個猜測，試著去解釋為什麼。

第一點可能的原因是 Yagni (You Aren't Gonna Need It)，在試驗市場時 PoC 或是 MVP 的商業邏輯反而不會那麼複雜，快速用 monolith 開發驗證比起擁抱 microservice 來的重要太多，而且可以快速修改。

第二點分成兩個現象：第一個現象是，即使是對產品的商業領域很有經驗的資深架構師，也很難一開始就切出正確的 BoundedContext；第二個現象是，在 microservice 裡，改架構的難度比起 monolith 高非常多 (i.e. 跨 boundary 的 refactoring)。這兩個現象加在一起就會造成一開始導入 microservice 的專案失敗。

文章接著想要提出一些建議，在一開始使用 monolith 可以注意的方向，這些注意的事項可能可以讓之後轉成 microservice 變得比較輕鬆。

第一種方式是在 monolith 架構下注意 API boundary 與 data 的儲存方式，當想要切換到 microservice 的時候就有機會比較簡單。

第二種是更常見的方式，一開始先是 monolith 架構，然後把 boundary 好切割的拆成 microservice，所以在過度期會是一組不那麼大的 sub-monolith 架構，然後週邊圍繞著很多 microservice。這個做久了就有機會轉成全部都是 microservice。

第三種方式就是砍掉重練。

第四種方式是一開始的時候不用 monolith，而是幾個很大包的 service (所以一開始不太能叫 microservice)，當商業模式成熟穩定後，切出更細緻的 boundary 的時候再拆成 microservice。

把這篇文章拿去搜尋 Hacker News 上的討論，可以看到除了 2021 年的這次討論外，在 2017 年的時候就有一批討論也蠻有趣的，可以看到有些不同的風向：「Monolith First (2015) (martinfowler.com)」。

當然也未必要信 Martin Fowler 的看法，軟體工程這塊還是有很多不同的流派...

Bash Script 的好習慣

這篇給了一份 bash script 用的 tempalte，但更重要的反而是裡面提到的 best practice：「Minimal safe Bash script template」。

首先是不要寫 /bin/bash 這件事情，因為有些系統是沒有 /bin/bash 的，像是 FreeBSD。

如果程式是可以用 POSIX sh 語法的話，應該優先考慮 /bin/sh，如果用到非 POSIX 標準的語法的話，用 env 帶出來會少一些問題：

#!/usr/bin/env bash

再來是 fail 時就趕快停止，不要再往下執行，這點算是老生常談了，文章作者也有給一個範例說明：

set -Eeuo pipefail

再來另外一個還蠻有用的事情是攔下常見的 signal 處理「後事」：

trap cleanup SIGINT SIGTERM ERR EXIT

cleanup() {
  trap - SIGINT SIGTERM ERR EXIT
  # script cleanup here
}

其他的可以看一看，但未必要全盤收下...

在瀏覽器內跑 Python

看到「A Python 3 implementation for client-side web programming」這個專案，在瀏覽器裡把 Python 程式碼用 <script type="text/plain"></script> 包起來，然後掛個 js 進去，就可以在瀏覽器裡面跑 Python 操作 DOM：

Brython is designed to replace Javascript as the scripting language for the Web. As such, it is a Python 3 implementation (you can take it for a test drive through a web console), adapted to the HTML5 environment, that is to say with an interface to the DOM objects and events.

另外在 Brython 3.8.9 performance compared to CPython 3.8.0 這頁也有跟 CPython 的比較 (看起來是用 Firefox 測的)，其實速度看起來不慢？我猜是 JS 這邊的軍備競賽把整個引擎弄的超快 XDDD

Python 2.7.18，官方提供的最後一個 2.7 的版本

本來 Python 2 官方的計畫是支援到 2020/01/01，但最後一個版本 Python 2.7.18 一直到剛剛 2020/04/20 才出。對照前一個版本 2.7.17，是 2019/10/19 的時候出的，這應該算是一個「經典」的落幕：「Python 2.7.18, the last release of Python 2」。

對於得用 Python 2 才能跑的專案 (目前手上應該就是 Trac)，如果 Python 3 的版本再不出，再過個一年應該只能用 pyenv 撐場了...

SQL Antipatterns: Avoiding the Pitfalls of Database Programming

標題裡是說這本書：「SQL Antipatterns: Avoiding the Pitfalls of Database Programming」，在 2010 年出版的書。

我是在 Hacker News Daily 上看到「Ask HN: What are some examples of good database schema designs?」這篇，裡面提到了這本書，看了一下章節看到只有 USD$25 就馬上先買起來丟到 Kindle 裡面...

這不是給資料庫初學者看的書，主要的讀者是對於「標準」夠熟 (學校教的那些理論基礎，像是各種 index 的底層結構，正規化的方法，以及正規化的原因)，然後也有一些實務經驗後的開發者。

因為裡面把常遇到的問題，與可能的解決方式 (通常都違反當初在學校學的理論基礎) 整理成這本書，在底子還沒打穩前跑來看這本書並不是個好主意...

另外裡面雖然不一定有提到，但有蠻多技巧其實是用在「為了效能而不則手段」的情境下，所以這些內容對於想要調校比較大的網站應該也是很有幫助。