Tag: programming

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

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

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

Python 3.7+ 保證 dict 內容的順序

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

Changed in version 3.7: Dictionary order is guaranteed to be insertion order. This behavior was an implementation detail of CPython from 3.6.

作者裡面的兩張圖清楚表示出來以前的版本怎麼實做，與 3.7+ 的版本怎麼實做：

這樣就很好理解了。

不過考慮到還是有些系統用 Python 3.5 (像是 Ubuntu 16.04 內建的 python3) 與 Python 3.6 (Ubuntu 18.04 內建的 python3，雖然沒問題，但當時還沒有寫出來)，也許還是先不要依賴這個行為會比較好。

不過以插入的順序列出好像不是很常用到...

第二堂：「Shell Tools and Scripting」

這個系列是從『MIT 的「The Missing Semester of Your CS Education」』這邊延伸出來的，這篇文章講第二堂課「Shell Tools and Scripting」。

這堂有點像是第一堂的延伸，在講更多 shell 的操作與工具，然後說明 shell script 怎麼寫。

開頭就先說明有 function，然後講了不少 magic variable，像是 $0、$1 到 $9，而 $@ 與 $# 也提到了 (但居然沒提到 $*)，然後再來是 $$、!! 與 $_。

然後提到 true 與 false，接著就講條件 || 與 && 了。後面就開始講 shell 裡面的 for 與 if，基本上到這邊已經能寫不少東西了？

後面就介紹更多工具...

四個機率問題

在「Some Useful Probability Facts for Systems Programming」這邊看到的四個機率問題，而且都有接近解：

  • 每一次有 \frac{1}{N} 成功的機率，跑 N 次後最少成功一次的機率。
  • N 個球隨機丟到 N 個籃子後有空籃子的機率。
  • N 個數字在隨機排序後有數字不改變位置的機率。
  • N 種 coupon 平均隨機出現，要抽中一套 N 種都有的 coupon 需要抽幾次的期望值。

會想要寫這篇是因為發現最後一題就是「大人買」抽卡問題的簡化版本 (這邊簡化成機率相同，一般的情境下應該是不同的)。

可以看到歐拉常數 e 與自然對數 \ln{} (i.e. 以 e 為底的對數) 滿天飛 XDDD

eBay 提供的 TSV 工具組

在 Hacker News Daily 上看到的，eBay 提供了操作 TSV 的工具組：「eBay/tsv-utils」。

看到了兩個比較少見的東西，第一個是軟體授權是 permissive license (Boost Software License)，第二個是使用的程式語言是 D...

TSV 的確是比 CSV 好用不少，只是會用的單位好像有限...

資料裡還蠻常見出現 , 的情況 (得用 double quote 包起來，但是再遇到 double quote 的時候就用 double double quote...)，但比較少遇到會有 tab 出現...

Perl 6 的名字被拿出來談...

在「Is Perl 6 Being Renamed?」這邊看到提到 Perl 6 名字的問題，主要是因為 Perl 6 跟現有 Perl 5 已經是不同的東西 (有點類似於當初 Python 2 到 Python 3 的計畫，但是差異比 Python 那邊多很多)，而導致被提出來討論是否還要繼續使用 Perl 這個名字了：「"Perl" in the name "Perl 6" is confusing and irritating」。

When Perl 6 was announced, it was seen the way that Perl 2, Perl 3, Perl 4, and Perl 5 were seen: replacements for "$VERSION - 1". Over time, it became clear that though Perl 6 was in the same family as Perl 5, a straightforward migration path was unlikely. One only needs to look at the problems with Python 2 and Python 3 and the upgrade obstacles with their minor syntactic differences to understand that an upgrade from Perl 5 to Perl 6 isn't trivial.

如果把 Perl 5 與 Perl 6 當作不同的程式語言來看，這個問題就變成非技術性的問題了 (甚至是政治問題)。

接下來應該會是一連串混亂的討論，但解決問題的第一步永遠是先面對問題，至少這個問題被拿到檯面上「討論」了...