Merge pull request #1421 from future-architect/feature

parser combinator

Author: ma91n

source/_posts/20241028a_秋のブログ週間2024.md

@@ -50,7 +50,7 @@ TIG真野です。
 | 10/31 木  | 西野理加子   | [フルリモートでも強いチームを作る！ふりかえり方法の工夫](/articles/20241031a/)              |
 | **2週目**   | 🍄     |                                        |
 | 11/7 木   | 真野隼記   | [書評: データモデリングでドメインを駆動する](/articles/20241107a/)               |
-| 11/8 金   | 澁川喜規   | パーサコンビネータ作ってみた                       |
+| 11/8 金   | 澁川喜規   | [パーサコンビネータを自作してみる](/articles/20241108a/)                       |
 | **3週目**   | 🍂     |                                        |
 | 11/12 火 | 曽田弘規   | （仮）仕事における言語化に大切なこと                   |
 | 11/13 水   | 武田大輝   | 書評: アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築 |

source/_posts/20241107a_書評：_データモデリングでドメインを駆動する.md

@@ -25,7 +25,7 @@ TIG真野です。秋のブログ週間のサブ企画である、アーキテ
 
 ## どんな本か
 
-以下、個人意見です。宅配クリーニングや物販などいくつか具体例を上げて、業務のデータモデリング（≒帳**簿**設計）を重視した「いぶし銀」な書籍です。データモデルは各DB実装に依存しない、帳簿（※帳票とは異なる！）のような概念であると本書では定義しています。このデータモデルについてフォーカスを当てた、最近出版された本として貴重な存在かと思います。なお、サロゲートキー／ナチュラルキー、テーブル分割、論理削除、適用開始終了日などは論理DB設計とし、インデックスなどDBに閉じる部分は物理DB設計と定義していました。
+以下、個人意見です。宅配クリーニングや物販などいくつか具体例を上げて、業務のデータモデリング（≒帳**簿**設計）を重視した「いぶし銀」な書籍です。データモデルは各DB実装に依存しない、帳簿（※帳票とは異なる！）のような概念であると本書では説明しています。このデータモデルについてフォーカスを当てた、最近出版された本として貴重な存在かと思います。なお、サロゲートキー／ナチュラルキー、テーブル分割、論理削除、適用開始終了日などは論理DB設計とし、インデックスなどDBに閉じる部分は物理DB設計と定義していました。
 
 論理／物理DB設計は設計、実装テクニックの話が多いと思います。この書籍でも12章で触れられていますが、テクニック自体を語るというよりは、これらの課題が「偶有的複雑性」として発生しているといったような、俯瞰的な考えを伝えることを重視していて、明日から開発で使える実践的な実装テクニックを学べる書籍ではないと思います。
 

source/_posts/20241108a_パーサコンビネータを自作してみる.md

@@ -0,0 +1,3 @@
+[ZoneTransfer]
+ZoneId=3
+HostUrl=https://app.diagrams.net/