programming

用 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.

Almost all the successful microservice stories have started with a monolith that got too big and was broken up

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 的底層結構，正規化的方法，以及正規化的原因)，然後也有一些實務經驗後的開發者。

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

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

Python 3.7+ 保證 dict 內容的順序

在「Dicts are now ordered, get used to it」這邊看到的，因為 Python 官方 (也就是 CPython) 實做 dict 的方式改變，然後決定把這個特性當作是 social contract，而不是當作 side effect 的特性 (也就是不保證之後版本會有相同特性)。