凝集度と結合度
2025年6月25日概要 ソフトウェア設計において品質を測る基本的な指標として、**凝集度（Cohesion）と結合度（Coupling）**がある。これらは、モジュール化、保守性、再利用性などを考慮する際に重要な概念である。 凝集度（Cohesion）とは 凝集度とは、モジュール内の構成要素（関数や変数など）がどれほど密接に関連しているかを表す指標である。 高凝集（High Cohesion） モジュール内の要素...
概要 ソフトウェア設計において品質を測る基本的な指標として、**凝集度（Cohesion）と結合度（Coupling）**がある。これらは、モジュール化、保守性、再利用性などを考慮する際に重要な概念である。 凝集度（Cohesion）とは 凝集度とは、モジュール内の構成要素（関数や変数など）がどれほど密接に関連しているかを表す指標である。 高凝集（High Cohesion） モジュール内の要素...
概要 Open Policy Agent（OPA）は、ポリシーによるアクセス制御を疎結合な形で実現できる強力な仕組みである。Regoという宣言的言語でルールを記述し、アプリケーション側からはシンプルな形式でポリシー評価を利用できる。 本記事では、OPAを利用したアクセス制御の代表的なパターンを整理し、それぞれの特徴や適した用途、実装負荷などを比較する。 以下に、あなたが挙げた4つのアクセス制御アプ...
概要 Rubyの並行モデルやGVLの役割、Pumaサーバのスレッド・プロセス設計、IO/CPUバウンドの捉え方、計測手法によるボトルネック把握、Rails/Pumaデフォルト設定変更背景などを整理し、適切なチューニング方針を提示する。 Rubyの並行モデルとGlobal VM Lock（GVL） GVLの存在意義 Ruby（MRI/CRuby）にはGlobal VM Lock（GVL）があり、同一...
概要 Go言語は、軽量なgoroutineとランタイム機構により並行処理（concurrency）を強力にサポートし、Go 1.5以降はデフォルトでGOMAXPROCSが利用可能CPUコア数に設定されるため、適切に設定することでマルチコアを活かした並列実行（parallelism）も可能とする。本記事では、goroutineのスケジューリングやCPUバウンド処理でのマルチコア活用の仕組み、OSプロ...
概要 データベースの性能向上や安定運用には適切なメモリ設定が必要である。ディスクアクセスはメモリアクセスに比べ極めて遅く、可能な限りメモリから読み書きすることで応答性能を向上させたい一方、過度なメモリ割り当てはOOM（Out Of Memory、メモリ不足によるプロセス強制終了）リスクを高め、システム全体の停止につながる可能性がある。したがって、安定性を担保しつつ性能を確保するために、Postgr...
OPA の基本と課題背景 OPA（Open Policy Agent）は Rego 言語で記述されたポリシーを用いて、入力（input）や外部データ（data）に基づいて評価を行い、許可／拒否などの判定を行うエンジンである。 実装例については、AWS Prescriptive Guidance のマルチテナント API 認可制御ガイドが参考になる。OPA を活用した SaaS におけるマルチテナン...
概要 システム設計に「間違い」はあっても「正解」は存在しない。あるのは、そのときの状況に応じた“最適な妥協”である。 設計とは、さまざまな制約の中で意思決定を行い、将来に向けて形を与える行為である。 「設計の賞味期限」という観点を通じて、どのように設計の寿命を見積もり、制約と向き合うべきかを考察する。 設計の賞味期限とはなにか？ 「いつまで持てばよい設計なのか？」 この問いを意識することで、設計は...
概要 スケーラビリティの計測方法について調べたのでまとめる。 スケーラビリティの基本理解 スケーラビリティとは、ワークロードの増加に対してシステムがどのように対応できるかに関係する品質特性である。 スケーラビリティは、単なるリソース追加ではなく、**効率性（Efficiency）**に直接的な影響を与える。 重要なのは、CPU・メモリ・ストレージ・ネットワークなどのリソースを増減させたとき、シス...
クラウドネイティブ・アーキテクチャ 可用性と費用対効果を極める次世代設計の原則を読んだ。 クラウドネイティブの基本的な考え方について知ることができる。 本書では、クラウドネイティブ成熟度モデル（Cloud Native Maturity Model: CNMM）を軸にクラウドネイティブアーキテクチャの解説を行っている。 クラウドネイティブ成熟度モデルとは、「クラウドネイティブ・サービス」、「アプリ...
概要 個人の資産形成を考えるためのツールとして、資産推移シミュレーターを開発したので、それについて紹介したい。 asset-trend-simulator 背景 私はMoney Forwardを使って資産管理をしているが、将来の資産推移のシュミレーションにはSpreadsheetを使ったものを利用していた。 Spreadsheetでもそれなりの精度（実際の資産推移のズレが数十万程度に済むような正確...
概要 システム設計においてアーキテクチャドキュメントは重要な役割を果たす。特に設計段階においては、関係者に対して設計の妥当性を説明し、合意を形成するための資料として機能する。このドキュメントは、単なる設計情報の羅列ではなく、読者の理解と納得を導くための戦略的な文書であるべきである。 目的を明確にする ドキュメントを作成するにあたって最初に意識すべきは、その目的である。この文書が誰に向けたものであり...
概要 PostgreSQLにおける論理レプリケーションは、データベース内の特定のテーブルに対するDML操作（INSERT、UPDATE、DELETEなど）を、他のPostgreSQLインスタンスに複製する仕組みである。物理レプリケーションとは異なり、論理レプリケーションはテーブル単位で柔軟に対象を選定できるため、データ統合、分散処理、マイグレーションといった用途に適している。 参考: Postg...
概要 PostgreSQLでは、GRANTベースのアクセス制御（テーブルや列レベル）に加え、ユーザー単位で特定の行の可視性や更新可否を制御する仕組み（行レベルのアクセス制御）としてRow Level Security（RLS）が提供されている。 RLSの基本概念 Row Level Securityは、テーブルに対して「ポリシー」を定義することで機能する。 ポリシーは、どのユーザーがどの行にアクセ...
概要 システムの仕様をドキュメントに書き出したい時にどういった構成であるべきか考えることが偶にある。 自分的システム仕様書の構成を記す。 新しいプロジェクトの設計フェーズはもちろん、既存システムの仕様理解のためにもなる構成になっているはず。 構成 01_overview.md # 全体概要 02_system_architecture.md # システム構成 03_dat...
概要 コンテキストマップで整理されたコンテキストについて、なぜそのような切り分け方をしたのか、切り分ける意味が何かといったことを開発者以外にも伝えたい、という課題があった。 そこで本稿では、「境界づけられたコンテキスト」について、開発者以外にも伝わるような説明を試みる。 コンテキストの違いを意識する 同じ言葉であっても、コンテキストが異なれば言葉の意味が変わることがある。 例えば「注文」という言葉...
Open Policy Agentについて詳しく知りたかったので、公式ドキュメントを参照して調べてみた。 Open Policy Agentとは Open Policy Agent（OPA、「オーパ」と発音。）とは、ポリシー適用のためのOSSの汎用ポリシーエンジン。 宣言型言語（Rego、「レイゴ」と発音。）を用いてポリシーをコードとして記述することができる。 Styraによって開発されており、現...
開発者とアーキテクトのためのコミュニケーションガイド ―パターンで学ぶ情報伝達術を読んだ。 視覚情報やテキスト、言語・非言語、ドキュメンテーションなどコミュニケーションに関することを話題とした本。 タイトルは、ソフトウェアエンジニアのためのドキュメンテーションガイドと読み替えても良さそうな内容であると個人的には感じた。 読みやすい内容であるため数時間程度で読める。 自分としてはあまり目新しい情報は...
マルチテナントSaaSアーキテクチャの構築 ―原則、ベストプラクティス、AWSアーキテクチャパターンを読んだ。 SaaSアーキテクチャの概念や実践的なパターンについて書かれている。 SaaSアーキテクチャの二層構造（コントロールプレーンとアプリケーションプレーン） マルチテナントのデプロイモデル オンボーディング手法 アイデンティティ管理とテナント認証 テナントルーティングパターン データパーテ...
OPAを使用したマイクロサービスのアクセス制御システムの実装 OPAを採用したアクセス制御システムのPOCに取り組んでみたので、その内容についてまとめておく。 POCの設計や実装は以下のリポジトリで公開しているため、そちらも合わせて参照されたい。 bmf-san/poc-opa-access-control-system 1. はじめに 1.1 背景と課題 まず、本記事で扱う重要な概念として「権限...
要件最適アーキテクチャ戦略を読んだ。 ビジネス戦略を理解すること ドメイン駆動開発でアーキテクチャを実装していく 最初からマイクロサービスは厳しい といった内容が印象に残っている。 続編として実装編があるらしいが、現在のところ和訳はまだ出版されていない模様。 ビジネスと戦略のつなぎの話よりもDDDの実践的な内容とアーキテクチャの実装パターンについてもページが割かれているように見える。 ...
実務で役立つ バックアップの教科書 基本の考え方からツール活用・差分管理・世代管理・データ保全・リストア・リカバリー・可用性の確保までを読んだ。 バックアップについての基本的な考え方や知識が書かれている本。 割と知っていることが多かったので、データ保護完全ガイド —あらゆるデータの保全と回復を可能にするも読んでみてもいいかもしれないと思った。 ...
PostgreSQL インストール時の 'configure' エラーに関するトラブルシューティング 1. はじめに PostgreSQL のソースコードをコンパイルする際に、make を実行した際に You need to run the 'configure' program first. というエラーが発生した。 トラブルシューティングをメモしておく。 2. ...
PostgreSQLのCOLLATEとglibcのバージョン差によるソート順の違い 同じCOLLATE設定を指定しているにもかかわらず、環境によってソート順が異なる問題に遭遇したので、その時の調査記録をメモしておく。 事象 Cloud SQLとローカル環境のPostgreSQLコンテナでCOLLATEが同じでもソート結果が違う Cloud SQL for PostgreSQL 17上でテーブルの文...
PostgreSQLにおけるCOLLATE（照合順序）について調べたことをまとめる。 1. COLLATE（照合順序）とは COLLATEとは、文字列の並び順や比較の仕方（大文字・小文字の扱いやアクセント、濁点など）を指定する仕組みである。たとえばORDER BYによる並び順や比較演算子の結果にも影響するため、日本語環境下でのアプリケーション開発においては正しいCOLLATEを設定しておくことが推...
FuelPHPの2023年3月現在の現況という記事を書いた。 最近の近況はどうだろうと思って、ChatGPTのdeep research機能を使って調査してみた。（去年からPHPから離れてしまったので、あまり時間をかけて調査するモチベーションはなかった..） 結論だけいうと、前回の調査からあまり大きな変化がないといえそう。 あと引用が自分の記事ばかりになっている...w 以下はChatGPTの出力...
オープンアドレスハッシュテーブルとスイステーブル go.dev - Faster Go maps with Swiss Tablesを読んでいたら、オープンアドレスハッシュテーブルとスイステーブルについての説明があったので、調べてみた。 1. オープンアドレスハッシュテーブルとは オープンアドレスハッシュテーブル（Open Addressing Hash Table） は、ハッシュ衝突（異なるキー...
データモデルには、時間軸（履歴や有効期間など）をどのように管理するかによって、いくつかのパターンが存在する。 Nontemporal（ノンテンポラル） Unitemporal（ユニテンポラル） Bitemporal（バイテンポラル） それぞれは「時間情報をどの程度細かく、どのような意味で管理するか」という点で異なる。 これらのデータモデルの特徴や設計例、メリット・デメリットについて解説する。 ...
ストーリーポイントの基準を考える方法についてアイデアが浮かんだので、それについて書き残しておく。 もしかして世界初では！？とは思ったが、Demystifying Story Point Estimation Using the Cynefin Frameworkという記事を見つけたのでそうではなさそう。 ストーリーポイントとは何か ストーリーポイント（Story Points）とは、作業の「相対的...
本記事ではソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析の第1章～第4章をベースに、モノリスからのサービス分割を検討するときに役立つポイントを整理する。 すべての組織に当てはまる“銀の弾は存在しないが、「どんなトレードオフを見極めるべきか」を理解することで、より納得感のあるアーキテクチャを設計できるかもしれない。 1. 「ベストプラクティス」は存在しない —...
アーキテクチャ戦略について考える ソフトウェア開発において、必ずしもCTOやアーキテクトといった明確なポジションにいなくても、「アーキテクチャ戦略の必要性」を感じ、考える機会がある。 「現場で技術的な方針をまとめたいが、どこから手をつけたらよいかわからない」 「将来の拡張性や組織の成長を踏まえたアーキテクチャにしたい」 「既に蓄積した技術的負債にどう向き合えばよいか知りたい」 本記事では、こう...
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニックを読んだ。 タイトルからプログラマ脳を彷彿して認知科学的な話が交えられているかなと思ったが、そうではなかった。 この本は脳内メモリに収まるコードを書くための実践的なプラクティスが語られている。 全体的に自分の経験則から共感を得る部分が多かった。著者はコンピューターサイエンスの学部ではない出身でソフトウェアエンジニアのキャ...
GraphQL federationについて調べたことをまとめる。 GraphQL Federationとは GraphQL Federationは、複数のGraphQLサービスを統合するための方法である。 GraphQLのマイクロサービスのようなもので、単一のGraphQLエンドポイントとして複数のGraphQLサービスを利用することができるようにするアーキテクチャパターンである。 GraphQ...
Rubyにおけるシングルトンパターンの実装方法についてまとめる。 シングルトンパターンとは シングルトンパターンは、インスタンスが1つしか存在しないことを保証するデザインパターンである。 Singletonモジュールを作成する方法 RubyにはSingletonモジュールが用意されており、これを使うことでシングルトンパターンを実装することができる。 require 'singleton&...
Rubyのインスタンス変数とクラス変数とクラスインスタンス変数の違いについてまとめる。 インスタンス変数 インスタンスごとに異なる値を保持する変数で、@で始まる変数名を使う。 主にクラス内部で宣言されたオブジェクトごとの状態を管理するために使われる。 class Person def initialize(name) @name = name # インスタンス変数 end d...
絵で見てわかるLinuxカーネルの仕組みを読んだ。 Linuxカーネルの仕組みについて初心者にも分かりやすいように書かれている。理解が及ばないものもあったが・・。 Linixカーネルについて知らないことばかりなので、これを入口にもう少し勉強しておきたい。 ...
ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイスを読んだ。 ソフトウェアに関するメトリクスの観点について複数の著者が語っている。副題の通り各著者ごとのアドバイスであり、それぞれの章ごとで詳細までには深入りされてはいないが、アーキテクチャのメトリクスについて観点を知る取っ掛かりとして良い。 メトリクスの定義をするためのアプローチとしてGQMアプローチを紹介している...
スタッフエンジニアの道 ―優れた技術専門職になるためのガイドを読んだ。 チームやプロジェクト、組織をリードするような能力を発揮する機会にあるソフトウェアエンジニアにとって羅針盤になるような内容であった。 ビジョンや戦略の描き方といった部分にも触れており、アーキテクトやCTOといった立場を目指していく意向のある人にとっても充実した本。 思考の仕方やコミュニケーション、振る舞いなど組織をリードしていく...
アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築を読んだ。 タイトル通りまさに教科書といった内容で、アーキテクトが知るべき領域について網羅されている。 ソフトウェアアーキテクチャに焦点を当てた話が割合として多い。 注釈や良書紹介、参考文献が充実しているので、この本を起点に学びを広げることができる。 ...
メタプログラミングRuby 第2版を読んだ。 メタプログミングを使いこなせたら魔法使いになれると思った。 使い所は分かったような気がするが、使いこなすのが難しいという感想を持った。 kinoppyd/reading-metaprogramming-rubyを後日やろうと思っている。 ...
Tidy First? ―個人で実践する経験主義的ソフトウェア設計を読んだ。 130ページしかないのですぐに読める。 コスト・収益・結合・凝集の観点で、"整頓"をするか？を考えさせてくれる本。 主張が端的でわかりやすいと感じた。 個人的にはコスト・収益の見積もりが難しく、技術者としての手腕が問われるなぁと思った。 特に、貨幣経済のアプローチで考えを示しているいくつかの章が面白か...
2024年の振り返りと来年の抱負 今年も1年を振り返って来年の抱負を記す。振り返りブログを書き始めて今回で7回目になる。 2023年の振り返りと来年の抱負 2022年の振り返りと来年の抱負 2021年の振り返りと来年の抱負 2020年の振り返りと来年の抱負 2019年の振り返りと来年の抱負 2018年の振り返りと2019年の目標 プライベート 今年は念願の住宅購入をした。家計簿やライフプランニ...
ソフトウェアアーキテクトのための意思決定術 リーダーシップ／技術／プロダクトマネジメントの活用を読んだ。 この本は訳文レビューに参加していた本で、献本を頂いてから再度読み直した。 アーキテクトの意思決定という部分にフォーカスを当てているところが画期的であり、アーキテクチャの設計に向かう人にとって学びがある内容になっている。 本書では、アーキテクチャの不確実性に立ち向かうためのツールとなる5つの質問...
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計を読んだ。 組織設計とアーキテクチャのあり方についてチームファーストな考え方を示している本。 組織におけるチーム設計のパターンが示されているが、チームのコミュニケーションやチーム間のインタラクションをどう捉えるかというのが要点だと理解した。 組織によって最適な体制は異なるので、ここで示されているパターンはあくまで一例のように捉えて...
Cloud SQLと比較したAlloyDBの優位性について知りたかったので簡単に調査してみた。 前提 Cloud SQLについてはCloud SQL Enterprise editionを対象とする。 Cloud SQL vs AlloyDB 仕様について単純比較する。 Cloud SQL AlloyDB サービス形態 マネージド型RDBMS PostgreSQLベースの分散型に近い...
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングを読んだ。 組織論というタイトルだったので、経営目線の話が多いかなと思ってしばらく手に取っていなかったのだが、サブタイトルにある"不確実性"が主題の本であった。 チームでメンバーとしてエンジニアリングをする立場であっても、アーキテクトのような立場であっても学びのある本だと思った。というかソフトウェア...
イシューからはじめよ［改訂版］――知的生産の「シンプルな本質」を読んだ。 義務教育では大抵"問い"が与えられるが、仕事では"問い"を自ら立てる必要がある。 どちらも問題を理解することは重要だが、問題が適切か？それは本当に問題であるか？など問題の質を深く考えなければならない点に大きな違いがあると思っている。 ソフトウェアエンジニアであっても、目の前の課題の本質...
freee 技術の本 freeeにおけるマルチプロダクト開発を読んだ。 業務系SaaSだと、共通業務（申請・承認）というドメイン領域で切り出せるのか、なるほど。申請・承認といってもコンテキストが違うとワークフローが違ったり、扱うデータも当然違うと思うので、難しそう。権限や通知と比べると抽象化が難しそうな機能分割っぽさがある。基盤としては申請に関する内容は扱わないようにしているらしい。扱わないよう...
いかにして問題をとくかを読んだ。 だいぶ昔の本ではあるが、数学を題材とした応用の効く問題に対する思考法について書かれている。 最近の本ではないため少々読みづらい。 問題をとくにはまず問題を良く理解すること、問題を様々な角度から捉えて試行錯誤することが大事であることを十分に思い知らされる。 ...
マスタリングAPIアーキテクチャ ―モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法を読んだ。 冒頭の章でC4ダイアグラムやADRの解説が入っているのが良かった。この本で語られるアーキテクチャの話はそれらの手法を使って説明されている。 APIアーキテクチャのパターンやテスト、運用、セキュリティなどについて書かれている。 WebにおいてAPIに触れないということは皆無だ...
概要 信頼性のパターンについてAzure、AWS、GCPの提唱するパターンに基づいてまとめる。 信頼性とは ユーザー（システムやアプリケーション）が期待する機能を提供し続けることができる性質のことである。 信頼性を支える特性 信頼性は次のような特性によって支えられる。 可用性：システムが利用可能であること 耐久性：データが失われないこと 耐障害性：障害が発生してもシステムが機能し続けること 回復...
研鑽Rubyプログラミング 実践的なコードのための原則とトレードオフを読んだ。 仕事でRubyを使い始めて、入門的な書籍も一通り読み漁って、ある程度知識が身についてきた段階でより実践的なことが知りたくて読んでみた。 Rubyの実践的な知識はもちろん、Rubyの魅力についてもこの本から感じ取ることができたような気がする。 プログラミングという観点では、Rubyに依らない考え方も拾うことができた。 ...
分散SQLクエリエンジンTrino徹底ガイドを読んだ。 SQLクエリエンジン ANSI SQLをサポート フェデレーテッドクエリ 同じSQLで異なるシステムからデータベースとスキーマを参照および使用する データベースではない OLTPを処理するために設計されていない OLAP向けなので、あくまで性能目標はOLAP水準なのではなかろうか 分散システムとしてコンピューティングリソースを...
概要 punditのコードリーディングをする。 準備 punditのリポジトリをクローンする git clone git@github.com:varvet/pundit.git コードリーディング 権限を適用するときに使うauthorizeメソッドを見ていく。 authorize varvet/pundit/blob/main/lib/pundit.rb#L75 モジュールのクラス...
Ruby コードレシピ集を読んだ。 Ruby初心者がRubyでできることやよくあるパターンをインプットするのにちょうど良い本。 これからRubyを学ぶのであれば、本書を読んでおいて損がないと思う。 分かりやすく簡潔に書かれているので読みやすい。 ...
概要 relineのコードリーディングをする。 準備 relineをクローンする git@github.com:ruby/reline.git サンプルコードを作成する $LOAD_PATH.unshift(File.expand_path('lib', __dir__)) require "reline" prompt = 'prompt&...
概要 irbのコードリーディングをする。 準備 irbのソースコードをクローンする git clone git@github.com:ruby/irb.git エントリポイントを細工する 元の状態だとRubyインストールディレクトリにあるirbを実行してしまうので、ローカルのirbを実行するようにする。 #!/usr/bin/env ruby # # irb.rb - intera...
概要 RSpecのコードリーディングをする。 準備 RSpecのリポジトリをクローンする。 https://github.com/rspec/rspec-core コードリーディング RSpecの呼び出し rspec/rspec-core/blob/main/exe/rspec#L4 エントリーポイント lib/rspec/core/runner.rb#L43 Runnerクラス...
概要 オフセットページネーションとカーソルページネーションの比較についてまとめる。 オフセットページネーションとは SELECT * FROM table LIMIT 10 OFFSET 20 のように、OFFSET と LIMIT を使ってページネーションを実現する方法。 比較的実装が容易で、任意のページに直接アクセスすることができる。全体のページ数が把握しやすいが、データセットが大きい場合、パ...
概要 Sidekiqのコードをさらっと読んでみる。 準備 sidekiqをクローン https://github.com/sidekiq/sidekiq redisを起動 docker run --name redis-server -p 6379:6379 -d redis デバッグしたいところでbinding.pryを仕込む sidekiqを起動 bundle exec ...
PostgreSQLとPgCatをローカルで実験できる環境を作った。 bmf-san/postgresql-pgcat-example PostgreSQLやPgCatのパラメータをチューニングしてローカルで負荷検証することできるようになっている。 構成は、 Web Rubyで雑APIサーバー PostgreSQL MySQLも同じだが、volumeにデータが存在するとinit.sqlが走ら...
権限管理基盤については開発事例を調べてみた。 developers.freee.co.jp - freee 権限管理基盤を開発するチームの今を語ろう！ 基盤開発チームの体制について developers.freee.co.jp - freee 権限管理基盤を開発するチームのこれまでを語ろう！ 基盤を設計していくうえでの課題を整理するアプローチについて共感するところが多い（自分の経験にも近しい...
概要 Ruby on Railsのコードリーディング作業を記録する。 準備 rails new RailsCodeReadingで新規プロジェクトを作成する。 Gemfileに以下を追加 gem 'pg' gem 'pry-rails' gem 'pry-doc' gem 'pry-byebug' gem ...
概要 Ruby on Railsのコードリーディング作業を記録する。 準備 rails new RailsCodeReadingで新規プロジェクトを作成する。 Gemfileに以下を追加 gem 'pg' gem 'pry-rails' gem 'pry-doc' gem 'pry-byebug' gem ...
概要 Ruby on Railsのコードリーディング作業を記録する。 準備 rails new RailsCodeReadingで新規プロジェクトを作成する。 Gemfileに以下を追加 gem 'pg' gem 'pry-rails' gem 'pry-doc' gem 'pry-byebug' gem ...
最近API設計について学び直そうと思って数冊ピックアップして読書したので、読んだ本をリストアップしておく。 API設計の本リスト おすすめの読書順でリストアップする。 Web API: The Good Parts 一般的なAPIの設計における基本的な考え方を学ぶことができる API設計本におけるリーダブルコードのような教科書的立ち位置の本（だと感じている） Web APIの設計 Web A...
APIデザイン・パターンを読んだ。 APIの設計原則に始まり、豊富なAPIのデザイン・パターンを紹介している。 リソース指向 単一のリソースに対して、標準メソッド（ex, Create/Get/List/Delete/Update）をかけ合わせて処理を決める RPC指向 メソッドを指定して特定の手続きを呼び出して処理を決める API設計を良くするため観点 実行可能であること 表現力があ...
概要 負荷試験を理解し、負荷試験を始めることができるようになるためのガイドとなるような内容をまとめます。 負荷試験とは システムの性能を検証するためのテスト手法である。 「システムが想定しているキャパシティ（性能の許容値）を確保できているか」、「過剰な負荷によりどのようなシステム影響が発生するか」、「性能に関わるボトルネックがどこにあるか」などを明らかにするためのテスト手法となる。 ※ この記事で...
概要 アーキテクチャ図を書くときにいつも粒度に迷っていたが、C4モデルという技法があることを知ったので、調べてみた。 C4モデルとは ソフトウェアアーキテクチャのモデル化技法の一つ。 C4はContext、Containers、Components、Codeの略で、システムをこれらの要素に分解することでソフトウェアアーキテクチャを記述する。 C4モデルは抽象度の高い順に以下の4つのビューを提供する...
概要 SLOの文脈でクリティカルユーザージャーニーについて知りたくなった。 クリティカルユーザージャーニーについて調べたことをまとめる。 クリティカルユーザージャーニーとは サービスのユーザーにとって最も重要な体験や、特定の目的を達成するための主要経路を示すものである。 ユーザーが目標達成する過程で重要なタッチポイントや障害を特定することができる。 ユーザーが達成すべき目標を明確にし、タスクやサブ...
New Relic実践入門 第2版 オブザーバビリティの基礎と実現を読んだ。 New Relicの機能を一通り網羅している。活用方法についても半分近くページが割かれているので、実践方法について知ることができる。 NRQLの仕様とかも書いてあると良いなと思ったが、足りないところはドキュメントで補完したり、実際に触ってみるのが早そう。 テレメトリデータについて次のように定義している メトリクス 定期...
ヘルシープログラマ ―プログラミングを楽しく続けるための健康Hackを読んだ。 全体的にエクササイズの紹介が多めにある。 本書で紹介される研究は科学的なエビデンスに基づいているものが多い。とはいえ10年近く前の書籍であるため、エビデンスにアップデートはありそう。 ただ、10年前から変わっていないなぁと思うことも多く、一見の価値があると思った。特に健康は習慣から育むという考え方はずっとある考えなのだ...
概要 SLOについて理解し、SLOの運用を始めることができるようになるためのガイドとなるような内容をまとめる。 SLOの導入から運用までのステップ 組織やチームにSLOの導入を行い、運用を開始していくためには幾つかの段階を踏む必要がある。 SLOの知識について共有する SLOの導入目的について合意する SLOの運用方針について合意する SLOの設計を行う SLOの運用を開始する SLOを組織に...
概要 契約テストとPactについて調べたことをまとめる。 契約テスト（Contract Testing）とは コンシューマ（サービスを呼び出す側）とプロバイダー（サービスを提供する側）の間の動作をテストするテスト手法のことである。 コンシューマーとプロバイダー間での合意を契約として記述し、その契約に基づいてテストを行う。 コンシューマーが契約を発行し、プロバイダーはその契約に従ってテストを行う形式...
概要 TypeScriptの基本について学び直す。 JavaScriptの復習 変数のスコープ（scope） グローバルスコープ windowオブジェクトのプロパティとして定義されるスコープ。 const a = "Hello"; console.log(window.a); // Hello ローカルスコープ 関数スコープ 関数内で定義された変数はその関数内でのみ有効。 f...
SLO サービスレベル目標 ―SLI、SLO、エラーバジェット導入の実践ガイドを読んだ。 サービスやユーザーの定義について語られている SLOを考える時は特にユーザーについての解像度を高めておく必要があると思った 解像度が低いとサービスの信頼性を過剰に高めようとしたり、無意味な指標になってしまいがちになると感じた サービスが信頼できるか？というのはサービスはユーザーが必要とする動作を実行して...
Jestのスナップショットテストを避けたほうが良いかもしれないデメリットについて雑メモ。 デメリット テストが脆くなってしまう スナップショットテストはUIの変更を簡単に検知することができる反面、テストの関心事ではないような変更（ex. class名のリネームだけで見た目は変わらない変更）であってもテストがFailしてしまう。 アサーションの期待が不明確 スナップショットテストではtoMatchS...
Web APIテスト技法を読んだ。 API設計のテストで5w1hを使って問いを考える話があったが、具体例が分かりやすく、示唆に富んでいた 現場のテスタビリティについて理解するフレームワークとして挙げられていた10個のPモデルが良かった。テスト戦略や計画を考える前提の整理に役立ちそう テスト計画の整備と文書化について書かれているテスト計画のフォーマット例も考えやすいシンプルなもので良かった。戦略と...
自分が健康のために行っている習慣について書き留めておく。半分くらいはポエム。そのうち将来振り返ることがあるかもしれないので、いつかの改善のために。 自分が健康のために行っている習慣について書き留めておく。半分くらいはポエム。そのうち将来振り返ることがあるかもしれないので、いつかの改善のために。 免責 この記事で書いていることの正しさ（≒エビデンスがある）については保証できません。自分が調べたこと、...
大規模データ管理 ―エンタープライズアーキテクチャのベストプラクティスを読んだ。 データ管理そのものというよりもアーキテクチャの話に興味があって手にとってみた。 データ管理を中央集権的に行うとデータ管理のトレンドの変化について行くことが難しくなるので、そのためにスケーラブルなアーキテクチャにしていきましょうという話。 データウェアハウスはサイロ化しがちなので避けたほうが良いというのは学びがあった。...
マイクロサービスアーキテクチャ 第2版 を読んだ。 マイクロサービスに取り組んでいる、マイクロサービスを検討しているなら読んでおきたい一冊。 分散システムに求められるアーキテクチャの特性(非機能要件)についてもよく触れられており、マイクロサービスオンリーな観点に囚われず読んでも良さそう。 マイクロサービスの概念についてサッと確認したい場合には第一章がよくまとまっているので参照したい。 一部モノリス...
以前、GoReleaserを使ってのGoのアプリケーションを配布するというタイトルの記事でGoReleaserを使ったバイナリ配布の方法について書いたが、Dockerhubへのイメージプッシュもやってみたのでまとめておく。 ソースコードの全体像はbmf-san/gondolaを参照。 .goreleaser.yamlを設定 ockers: - image_templates: - ...
モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイドを読んだ。 モノリスからマイクロサービスへの移行アプローチについて書かれている。 最もページが割かれている第４章はマイクロサービス化への1番の砦と思われるデータベースの分割について書かれている。時間がない、振り返りだけしたいならこの章だけは目を通しておきたい。 この本はタイトル通りアプローチに特化している内容であるので、マイクロサ...
概要 Bitemporal Data Modelについて調べたことをまとめる。 Bitemporal Data Modelとは Temporal Data Modelsという分野で扱われるデータモデルの１つで、時間軸を取り扱うデータモデルのうち、2つの時間軸を持つデータモデルのことを指す。 ノンテンポラル（Non-Temporal） 現在の状態のみを保持する 過去の履歴や将来の変更に関する情報は...
セキュアで信頼性のあるシステム構築 ―Google SREが考える安全なシステムの設計、実装、保守を読んだ。 前半部分に興味の中心があったのでメモしておく。 セキュリティと信頼性は創発特性、単純に実装されるものではなく、デプロイや運用における複数の要因(仕組みやテスト、検証状態などから)から創発される特性である。 プロジェクトの初期段階からセキュリティと信頼性について考えておいたほうがよい。プロ...
間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価を読んだ。 2010年に初板が発売された割と古い本ではあるが、今にも通ずるソフトウェア・アーキテクチャの話がかなり砕けた表現で書かれている。 この年代では自分はまだ学生だったので時代背景はわからないが、アーキテクトという存在がこの10年で結構変わったんだろうなぁという印象を持った。 技術書というよりエッセイ本なので、技術的な要素のみ...
概要 権限管理の設計について事例を調べてみたのでメモしておく。 調査メモ 調査した情報を整理してみたが、わかっていないこともあるのでちゃんと整理しきれていない。 権限を構成する要素 権限は次の要素で成り立つものと考えられそう。 誰が（Principal） 何に（Resource） 何を（Action）していいか（ALLOW）、いけないか（DENY） 権限設計の手法 設計手法としては次のようなも...
単体テストの考え方/使い方を読んだ。 質の高いテスト設計の為に必要な考え方やアプローチがまとめられている。テスト手法に留まらないテスト設計の本であり、テスト関連の本の中でもあまり類を見ないものだと思われる。 良いテストは、リグレッションへの保護、リファクタリング耐性、フィードバックの迅速さ、保守性を備えているが、これらを全て満たすのは難しいため費用対効果を考える必要がある。本書はその考え方を示す実...
ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするにはを読んだ。 トレードオフはドキュメントには書かれないことがある。何かを選択した理由は書かれていても、選択していなかった理由を示していないことは結構あるのではないだろうか。 この本では、設計判断のトレードオフを対照的に考えることの重要さと、ソフトウェア設計におけるトレードオフ事例を学び得ることができる。 後半はトレー...
概要 RubyのModuleについてかく。 Moduleとは クラスや他のモジュールに共通のメソッドや定数を提供するための仕組み。 # モジュール定義 module Hi def say_hi puts "Hi!" end end Moduleはクラスと異なり、インスタンス化できない。また継承もできない。 モジュールにはクラスメソッドやインスタンスメソッドを定...
概要 Rubyの特異クラスと特異メソッドについてかく。 特異クラス 特異クラスとは、特定のオブジェクトに対してのみ有効なクラスのことを指す。 class Greet def say_hi puts 'Hi' end end greet = Greet.new # 特異クラス class << greet # シングルトンメソッド def ...
概要 RubyのProcとlamdaについてかく。 Procとは ブロックをオブジェクト化したもの。ブロックはオブジェクトではない。 このオブジェクトは手続きオブジェクトと呼ばれ、Procクラスのインスタンスとして表現される。 Proc.newまたはprocによって手続きオブジェクトを生成できる。 # Proc.new proc_object = Proc.new { |x| puts x } ...