diff --git a/lib/evan361425/figcaption.py b/lib/evan361425/figcaption.py index fa72694b..fa0192a0 100644 --- a/lib/evan361425/figcaption.py +++ b/lib/evan361425/figcaption.py @@ -7,7 +7,6 @@ from .util import info - # ------------------------ # Constants and utilities # ------------------------ diff --git a/lib/evan361425/util.py b/lib/evan361425/util.py index f8c428e0..83122d83 100644 --- a/lib/evan361425/util.py +++ b/lib/evan361425/util.py @@ -1,13 +1,9 @@ import logging -from mkdocs.utils import warning_filter - - # ------------------- # Logging # ------------------- log = logging.getLogger("mkdocs.plugins." + __name__) -log.addFilter(warning_filter) LABEL = "Custom -" # plugin's signature label diff --git a/mkdocs.yaml b/mkdocs.yaml index 79d0c1f3..3c7011fd 100644 --- a/mkdocs.yaml +++ b/mkdocs.yaml @@ -194,17 +194,21 @@ plugins: - search - figcaption - tablecaption -# - serve_simple: -# dest: site -# targets: -# - index.md -# - latest-works.md -# - javascripts/ -# - feedback/index.md -# - essay/index.md +- serve_simple: + dest: site + targets: + - index.md + - javascripts/ + - stylesheets/ + - feedback/index.md + - feedback/site-reliability-workbook/index.md + - feedback/site-reliability-workbook/nalsd.md + - essay/index.md - mermaid2: arguments: - securityLevel: 'antiscript' + securityLevel: loose + theme: | + ^(JSON.parse(__md_get("__palette").index == 1)) ? 'dark' : 'light' # 用來注入最新的修改 - blogging: # https://github.com/liang2kl/mkdocs-blogging-plugin diff --git a/src/essay/gpl-check.md b/src/essay/gpl-check.md index 8b536f33..ad71aaf2 100644 --- a/src/essay/gpl-check.md +++ b/src/essay/gpl-check.md @@ -14,7 +14,7 @@ GPL 和 AGPL 不管是啥版本都要求**直接引用**該程式庫的專案要 下表是不同許可間的比較。 -![image alt](https://raw.githubusercontent.com/HansHammel/license-compatibility-checker/f243eb4523ebc7d019a5928103e5b82b59b3b803/licenses.svg) +![Licenses](https://i.imgur.com/nLE7KrX.png) > [The easiest way to check all your npm dependency](https://medium.com/@fokusman/the-easiest-way-to-check-all-your-npm-dependency-licenses-753075ef1d9d) diff --git a/src/essay/web-security/cross-origin-resources-sharing.md b/src/essay/web-security/cross-origin-resources-sharing.md index db2c18a8..75ffc100 100644 --- a/src/essay/web-security/cross-origin-resources-sharing.md +++ b/src/essay/web-security/cross-origin-resources-sharing.md @@ -22,8 +22,11 @@ ## 細節 -1. 若 HTTP request [夾雜了些東西](SimpleRequest)，HTTP response 就會[需要更多標頭來表達意願](https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS#Access-Control-Expose-Headers)。 -2. 若 HTTP request [夾雜了些東西](SimpleRequest)，瀏覽器可能還需要做[預先檢查](https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS#預檢請求)，若檢查失敗，不會做進一步的要求。 +1. 若 HTTP request [夾雜了些東西][simplerequest]， + HTTP response 就會[需要更多標頭來表達意願](https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS#Access-Control-Expose-Headers)。 +2. 若 HTTP request [夾雜了些東西][simplerequest]， + 瀏覽器可能還需要做[預先檢查](https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS#預檢請求)， + 若檢查失敗，不會做進一步的要求。 > 夾雜的東西常常就是使用者的隱私。 @@ -48,4 +51,4 @@ - `Cross-Origin-Embedder-Policy` - `require-corp` -[simplerequest]: (https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS#簡單請求) +[simplerequest]: https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS#簡單請求 diff --git a/src/essay/web-security/owasp-api-top10.md b/src/essay/web-security/owasp-api-top10.md index c31f70b6..6d3b66af 100644 --- a/src/essay/web-security/owasp-api-top10.md +++ b/src/essay/web-security/owasp-api-top10.md @@ -130,7 +130,7 @@ LIMIT 1 ## Improper Assets Management -`v2` 把 [Lack of Resources & Rate Limiting](#lack-of-resources-rate-limiting) 的問題修好了 +`v2` 把 [Lack of Resources & Rate Limiting](#lack-of-resources--rate-limiting) 的問題修好了 ```text GET /api/v2/users?page=1&size=100 HTTP/1.1 diff --git a/src/essay/web/http.md b/src/essay/web/http.md index d6926083..5749fedc 100644 --- a/src/essay/web/http.md +++ b/src/essay/web/http.md @@ -20,7 +20,7 @@ HTTP 建立在 [TCP](./tcp.md) 之上，雖然 TCP 可以確保連線的穩定 從上面也可以得知，HTTP 其實就是一種針對應用程式邏輯的協定， 所謂的超文本（Hypertext）就是不再像底層協定那樣， -透過位元（bit）去做一些參數設定，例如 [TCP 選項](tcp.md#tcp_2)， +透過位元（bit）去做一些參數設定，例如 [TCP 選項](./tcp.md#tcp-選項)， 而是透過純文字來控制參數， 例如 HTTP 用 [HSTS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) 去協調請求方（通常是瀏覽器）應該用哪個版本的協定。 @@ -126,7 +126,7 @@ set the cookie #### Connection 如果請求有這個 Header，服務方在回應後，就會主動關閉連線。 -關閉連線的那方是要負擔較大的 TCP 開銷，並貯存 [TCP `TIME_WAIT`](tcp.md#四次揮手) 的連線。 +關閉連線的那方是要負擔較大的 TCP 開銷，並貯存 [TCP `TIME_WAIT`](./tcp.md#關閉連線的信號) 的連線。 #### ETag diff --git a/src/feedback/designing-data-intensive-applications/derived-batch.md b/src/feedback/designing-data-intensive-applications/derived-batch.md index ddaf2533..2632936c 100644 --- a/src/feedback/designing-data-intensive-applications/derived-batch.md +++ b/src/feedback/designing-data-intensive-applications/derived-batch.md @@ -296,9 +296,9 @@ HDFS 是開源軟體，他有很多其他相似的產品，但大致上的邏輯 在介紹 MapReduce 之前我們先看看應用 -![以 Lucene/Solr 解釋 MapReduce 的運作](https://i.imgur.com/sQWXHL7.png) +![以 Lucene、Solr 解釋 MapReduce 的運作](https://i.imgur.com/sQWXHL7.png) -例如 [Lucene/Solr](https://docs.cloudera.com/documentation/enterprise/5-15-x/topics/search.html) +例如 [Lucene、Solr](https://docs.cloudera.com/documentation/enterprise/5-15-x/topics/search.html) 就是透過 MapReduce 在分散式資料系統中產生索引（Index）。 全文索引的建立方式是透過以名詞和文章編號做 key-value pair。 diff --git a/src/feedback/designing-data-intensive-applications/foundation-encode.md b/src/feedback/designing-data-intensive-applications/foundation-encode.md index 2b36bec4..4a30c818 100644 --- a/src/feedback/designing-data-intensive-applications/foundation-encode.md +++ b/src/feedback/designing-data-intensive-applications/foundation-encode.md @@ -54,7 +54,7 @@ JSON、XML、CSV，這些格式都很常見，不需要綱目就能解碼。然 ### 二進位編碼 -二進位編碼並不是新東西，早在 1984 年就有協定 [ASN.1](https://www.oss.com/asn1/resources/books-whitepapers-pubs/larmouth-asn1-book.pdf) 闡述如何進行二進位編碼，他和 [Thrift](#thrift)、[Protocol Buffer](#protocol-buffer) 一樣都使用 tag ID。且其應用（DER）如今仍被大量使用於 X.509。 +二進位編碼並不是新東西，早在 1984 年就有協定 [ASN.1](https://www.oss.com/asn1/resources/books-whitepapers-pubs/larmouth-asn1-book.pdf) 闡述如何進行二進位編碼，他和 [Thrift](#apache-thrift)、[Protocol Buffer](#protocol-buffer) 一樣都使用 tag ID。且其應用（DER）如今仍被大量使用於 X.509。 但是他卻過於複雜且其文件也設計得很複雜，由此發展出以下幾個較新的方式。 diff --git a/src/feedback/designing-data-intensive-applications/foundation-model.md b/src/feedback/designing-data-intensive-applications/foundation-model.md index 31a55bbc..0331566f 100644 --- a/src/feedback/designing-data-intensive-applications/foundation-model.md +++ b/src/feedback/designing-data-intensive-applications/foundation-model.md @@ -14,7 +14,7 @@ - 圖像式模型（Graph-like model） 一開始資料儲存僅以 Hierarchical Tree 的形式儲存資料， -但是當需要考慮到[多對多（many-to-many）](#多對一（多）)的關係時，就開始出現困境。 +但是當需要考慮到[多對多（many-to-many）](#多對一多)的關係時，就開始出現困境。 而後，當關聯式模型不再滿足需求，例如：資料格式不想要多做一層轉換、無法快速做 scaling 等等時，便相繼發展出其他模型。 @@ -99,7 +99,7 @@ SQL 是關聯式模型在做搜尋語言時的一種協定。SQL 在推出時有 但是，因為他在處理一對多的關係時非常單純，不會像關聯式一樣有各種 join 和 group，讓他在分散式的資料庫下非常好做，這會在我們後面做複製（replication）和分區（partition）時和考慮競賽狀況時更能體會到。 -除此之外，還有[綱目](#schema)也不太一樣。 +除此之外，還有[綱目](#綱目schema)也不太一樣。 ### 綱目（schema） diff --git a/src/feedback/distributed-systems-with-node.js/container.md b/src/feedback/distributed-systems-with-node.js/container.md index 6c91cbd9..00d6b20e 100644 --- a/src/feedback/distributed-systems-with-node.js/container.md +++ b/src/feedback/distributed-systems-with-node.js/container.md @@ -216,7 +216,18 @@ docker-compose 便是用來解決這一問題的方案。 以上一份 Tracing 中的 Zipkin 為例： -![應用程式架構圖](https//www.plantuml.com/plantuml/png/HSz13e8m40NG_PnYBj0Bk310EG29EucB2WDEBDEcr11ZlBi3Hjpz__gRfiMSNSgFoSDyPuakkGcxCCKW9FcKdvumKPUTZ9wWjPwLB-XcB65tB9i6Nu3OBdGrBl8sg5RG3KVQpS8RsZD7VMhhDPHe4e-tR8vweVeN2nQDf-5xeBaFYsYkyO0iGu3gHxiK9FtwaGy0) +```mermaid +--- +title: 應用程式架構圖 +--- +flowchart TD + subgraph app[APP] + w[web-api] <--> r[recipe-api] + end + c[Client] --> w + w-- info -->z[Zipkin] + r-- info -->z[Zipkin] +``` 就可以依此建立 docker-compose.yaml： diff --git a/src/feedback/index.md b/src/feedback/index.md index b1eac2e3..70c0e5e5 100644 --- a/src/feedback/index.md +++ b/src/feedback/index.md @@ -55,12 +55,12 @@ exclude_from_blog: true - [Adaptive Concurrency] - [Release It!] -[distributed systems with node.js]: distributed-systems-with-node.js/ -[designing data-intensive applications]: designing-data-intensive-applications/ -[adaptive concurrency]: adaptive-concurrency/ -[future of fusion energy]: future-of-fusion-energy/ +[distributed systems with node.js]: distributed-systems-with-node.js/index.md +[designing data-intensive applications]: designing-data-intensive-applications/index.md +[adaptive concurrency]: adaptive-concurrency.md +[future of fusion energy]: future-of-fusion-energy/index.md [release it!]: release-it.md -[the site reliability workbook]: site-reliability-workbook +[the site reliability workbook]: site-reliability-workbook/index.md [讀完]: #讀完 [寫作]: #寫作 [完成]: #完成 diff --git a/src/feedback/physics/astronomy.md b/src/feedback/physics/astronomy.md index 81d154aa..674c8ea5 100644 --- a/src/feedback/physics/astronomy.md +++ b/src/feedback/physics/astronomy.md @@ -460,7 +460,7 @@ CCD 有兩種主流方式來計算收集到的電子數量， 理解 CCD 這類感光設備後，我們就可以開始討論，要怎麼「拍攝」可見光之外的光源，例如紅外線。 任何東西只要有溫度就會發射紅外線，例如冰塊、被微塵包裹的物體、宇宙邊緣的物體。 -然而紅外線因為太低頻，所以其攜帶的能量不足以讓矽進入[導帶](#他怎麼運作的？)， +然而紅外線因為太低頻，所以其攜帶的能量不足以讓矽進入[導帶](#他怎麼運作的)， 也因此我們需要利用其他物質來製作感光設備，例如 [CMT](https://en.wikipedia.org/wiki/Mercury_cadmium_telluride)。 @@ -533,7 +533,7 @@ CCD 有兩種主流方式來計算收集到的電子數量， #### 儲存能力 CCD 中每個位元（MOS）可以儲存 2 bytes（16 bits）的資訊， -如果以一排有 [4000 個位元](#要怎麼收集電子？)來計算， +如果以一排有 [4000 個位元](#要怎麼收集電子)來計算， 每張 CCD 出來的影像就會有 32 MB 的大小。 我們再以一個望遠鏡有多個 CCD 來考慮，所以一張天文照片約需要數 GB 來儲存。 diff --git a/src/feedback/release-it.md b/src/feedback/release-it.md index 706c4194..3dfd64e2 100644 --- a/src/feedback/release-it.md +++ b/src/feedback/release-it.md @@ -529,7 +529,7 @@ GSLB 可以做到檢查下游的健康狀況、彈性分配流量到不同節點 流量增長可能會耗盡系統的資源，以網路為例，有幾點要注意： - Socket 會被耗盡，並需要等待舊的被關閉 - （關閉前會需要進入 [`TIME_WAIT`](../essay/web/tcp.md#四次揮手) 狀態）。 + （關閉前會需要進入 [`TIME_WAIT`](../essay/web/tcp.md#關閉連線的信號) 狀態）。 - 一部分封包等待著其他封包進來，這時記憶體就會被這些不完整的封包佔用， 稱這種現象為[隊頭阻塞](https://zh.wikipedia.org/zh-tw/%E9%98%9F%E5%A4%B4%E9%98%BB%E5%A1%9E)。 - 以 TCP 為例，建立連線前會進入 `listen` socket 的佇列， diff --git a/src/feedback/site-reliability-workbook/nalsd.md b/src/feedback/site-reliability-workbook/nalsd.md index cc56199e..06f9fd8f 100644 --- a/src/feedback/site-reliability-workbook/nalsd.md +++ b/src/feedback/site-reliability-workbook/nalsd.md @@ -5,12 +5,12 @@ tags: SRE-workbook # 非抽象大型系統設計 非抽象大型系統設計（Non Abstract Large System Design, NALSD）的目的在於讓開發者設計系統架構時， -有個依據建立穩健而又高擴充的系統。 +能夠有個依據來建立穩健而又高擴充的系統。 本文先透過定義問題，收集需求並反覆審視、循序改善架構的設計，最終得到一個可靠的系統設計解方。 目標是讓開發者能設計出一個在初期便擁有高穩健性且同時擁有未來調整的環境， -而這個過程，就是把抽象的需求，降成實際可被估量的實踐。 -這些實踐包括： +而這個過程，就是把抽象的需求，落地成實際可被分析的數字。 +這些分析包括： - 容量（capacity）預估 - 功能獨立性（類似艙壁原則，bulkheads），避免單一功能的損壞影響全部的服務。 @@ -27,7 +27,7 @@ tags: SRE-workbook !!! success "練習的目的" 所有的系統最終都要實際跑在真實的資料中心和真實的設備上， - 我們需要反覆練習將白板上的架構圖，轉化成實際要使用的設備數量等等。 + 我們需要反覆練習將白板上的架構圖，轉化成實際要使用的設備數量、網路通量等等。 聽起來很瑣碎，但是不去練習和規劃，當我們實際上線時，可能會付出更慘痛的代價。 練習中的假設和推估會比最終實際結果重要。 @@ -105,7 +105,7 @@ AdWords 是 Google 一項產品，用來在使用者透過 Google 搜尋時， 假設： - 服務每秒會有 500k 的搜尋（Google search）和 10k 的廣告點擊； -- 搜尋每筆日誌大小為 2KB，這是高估，但是為了避免非預期大流量，高估是可被接受的； +- 搜尋每筆日誌大小為 2KB，這是高估，但是為了避免非預期大流量，高估是可被接受的。 ### 設計可行架構 @@ -142,7 +142,7 @@ WHERE a.search_term = b.search_term 問題：*這方法可以在有限的設備數量、時間和金錢內達成嗎？* 為了放進這些資料，我們需要多大的資料庫？ -根據前面估計的量，計算一下 1 天的搜尋日誌大小約為 86.4TB： +根據前面估計的量，1 天的搜尋日誌大小約為 86.4TB： \begin{flalign} \left( 5 \times 10^5 \mathrm{\ queries/second} \right) @@ -187,7 +187,7 @@ WHERE a.search_term = b.search_term 把搜尋日誌和點擊日誌的 `ad_id` *剖析*（map）出來，之後 *合併*（reduce）進每個 `search_term` 的點擊次數。 雖然 MapReduce 可以輕易做到分散式的計算，當需要更多設備時也可以輕易補上，但是我們還要考量我們的 SLO。 -99.9% 的 CTR 資訊都要顯示 5 分鐘內的資料。 +SLO：*99.9% 的 CTR 資訊都要顯示 5 分鐘內的資料*。 為了滿足即時資料的需求，我們必須要把批次處理的級距變得很小，例如，每分鐘批次計算一次。 但是在進行合併計算時，如果相同搜尋和點擊的日誌並沒有放在同一個批次裡 @@ -212,11 +212,11 @@ WHERE a.search_term = b.search_term title: LogJoiner 架構 --- flowchart TD - ql[Query Logs] --All query
log records-->qm[(QueryMap
key: ad_id,
search_term
value: query_ids)] - ql --All query
log records-->qs[(QueryStore
key: query_id
value: Query
Log record)] - cl[Click Logs]--All click log
records-->lj([LogJoiner]) - lj<--Look up
query_id-->qs - lj --> cm[(CLickMap
key: ad_id,
search_term
value: query_ids)] + ql[Query Logs] --All query
log records-->qm[(QueryMap
key: ad_id,
search_term
value: query_ids)] + ql --All query
log records-->qs[(QueryStore
key: query_id
value: Query
Log record)] + cl[Click Logs]--All click log
records-->lj([LogJoiner]) + lj<--Look up
query_id-->qs + lj --> cm[(CLickMap
key: ad_id,
search_term
value: query_ids)] ``` 透過 ClickMap 和 QueryMap 存放我們需要的 `ad_id` 和 `search_term` 對應的點擊數和搜尋數。 @@ -301,8 +301,8 @@ QueryStore 只需要以 `query_id` 作為鍵，然後存放該筆搜尋的資料 title: 分區的 LogJoiner 架構 --- flowchart TD - ql[Query Logs] --> qls[Query Log Sharder
hash:ad_id % N] --> qm2 & qm1 - cl[Click Logs] --> cls[Click Log Sharder
hash:query_id % M] --> lj2 & lj1 + ql[Query Logs] --> qls[Query Log Sharder
hash:ad_id % N] --> qm2 & qm1 + cl[Click Logs] --> cls[Click Log Sharder
hash:query_id % M] --> lj2 & lj1 subgraph qms [QueryMap Shards] qm1[(QueryMap Shard 1)] qm2[(QueryMap Shard N)] diff --git a/src/feedback/site-reliability-workbook/postmortem-culture.md b/src/feedback/site-reliability-workbook/postmortem-culture.md index 707adc8e..afbd7987 100644 --- a/src/feedback/site-reliability-workbook/postmortem-culture.md +++ b/src/feedback/site-reliability-workbook/postmortem-culture.md @@ -550,7 +550,7 @@ IRC 的日誌 - [可以強化的做法](#可以強化的做法) - [壞味道](#壞味道) -- [工具](#工具) +- [工具和平台](#工具和平台) ### 可以強化的做法 diff --git a/src/review/2022-ai.md b/src/review/2022-ai.md index 68114ed4..8f81bfff 100644 --- a/src/review/2022-ai.md +++ b/src/review/2022-ai.md @@ -7,7 +7,7 @@ description: 2022 年針對 AI 的回顧文，包含自然語言、繪圖、醫 今天（12/17）回顧 2022 年，發現有很多 AI 的突破，讓我備受感動！ 以下就來盤點一下幾個我覺得很厲害的產品。 -- [（全能）自然語言處理模型 — ChatGPT](#ChatGPT) +- [（全能）自然語言處理模型 — ChatGPT](#chatgpt) - [AI 繪圖 — Stable Diffusion](#stable-diffusion) - [蛋白質模型預測 — AlphaFold2](#alphafold-2) - [核融合的溫度維持](#fusion)