A Philosophy of Software Design, 2nd Edition (English Edition)英語版 John K. Ousterhout (著) 形式: Kindle版 Amazon.co.jpで詳細を見る 良い設計をするためのコンセプトを解説した本。類書はいろいろとあるが、自分が読んだものの中では一番良かった。ソフトウェアエンジニアリングを行う人には広くおすすめできる。コンパクトですぐに読み切れるのも良い。 複雑さをいかに削減するかという観点と、その対策としての深いモジュールというコンセプトを導入し、この軸ですべての章を論じている。筋が通っていて読みやすいし、納得感も高い これらのコンセプトを通して、従来は良しとされているプラクティスの再検討も行っていて、こちらも面白く納得しながら読めた。例えばできるだけメソッドは小さくするという慣習や、Clean Cod

InnoDB のフラグメンテーションについてドキュメントを読んだメモ。 なおいずれも MySQL8 系のドキュメントを参照している。また Issue Tracker やソースコードまでの深堀りはしていおらず、基本的にドキュメントから分かる範囲だけをまとめている。 フラグメンテーションについて MySQL :: MySQL 8.0 Reference Manual :: 15.11.4 Defragmenting a Table より。 ランダムな INSERT や DELETE をしているうちに、だんだんと page のなかで「確保されているが使用されていない」領域が増えていく フラグメンテーションが大きくなると読み取り性能が劣化する可能性がある 次のような場合に偏っているいると考えられる 「本来あるべきデータサイズ」よりも「実際使われているデータサイズ」が大きい場合 「本来」とは何かが難

Rails を使っているプロジェクトを運用していて、ActiveRecord の Schem Cache まわりでいくつかつまずいた部分があった。コードを置いながら挙動の確認したのと、踏んだ問題それぞれとの関係を整理したので個人的な覚書としてメモ。 ActiveRecord はモデル (= テーブル) の定義を知っていてそれを元に ORM のいろいろな機能を提供している。例えば次のようにテーブルのカラムの情報を取得できる。 [1] pry(main)> User.columns_hash.keys => ["id", "name", ...] [2] pry(main)> User.columns_hash["id"] => #<ActiveRecord::ConnectionAdapters::MySQL::Column:0x000055c1ef6ec420 @collation=nil

とても良い本だった。 MySQL の初級・上級の本は既刊であるが、その間を埋めるものがないので書かれたというもので、難易度を 1 ~ 5 で表すと 4 くらい、難易度 5 は 実践ハイパフォーマンスMySQL とのことだった。 あくまで深堀りしたいアプリケーションエンジニア向けの本で、DBA 向けではないと明記されていた。実際 MySQL (InnoDB) の実装詳細の説明が適度に打ち切られていて、ただし必要十分なトピックはカバーされていて、学習効率が良い。 筆者は Hack MySQL を運営していたり、過去に Percona で数々のツールを作ってきた実績 もあり、信頼が置ける。 1. Query Response Time まず North Star Metrics としてクエリのレスポンスタイムを定義し、その改善に必要な項目を体系立てて説明している。この構成がかなり良くて、明確な指

nginx の ngx_http_limit_req_module で rate limit の設定ができる。がパラメータの理解が難しく、当初は設定値の調整に難儀した。背後にある Leaky Bucket というアルゴリズムとその実装を確認することでパラメータもすんなり理解できた。以下調べたことのログを残しておく。 ngx_http_limit_req_module ngx_http_limit_req_module は指定した key ごとに Rate Limit を設定できるというモジュール。key とは例えばリクエスト元の remote_ip で、それごとに「1r/s まで」といった制限を指定できる。 設定はこんな感じ。 http { limit_req_zone $binary_remote_addr zone=myzone rate=1r/s; ... server { ...

multipass で開発環境を構築したメモ - Please Sleep にて、M1 Mac で Multipass を使って開発環境を作ってみていたところ、うまく動かないコンテナがあった。初見では不可解に感じられるポイントがあったので、理解を整理したメモ。 状況 docker-compose でいくつかのコンテナをまとめた環境がある M1 Mac での直接の実行はできる multipass で起動した ubuntu 20.04 の仮想環境ではうまく動作しなかった 次のようなエラーでうまく実行できなかった。 pull した一部のイメージの実行時にアーキテクチャが違うというエラーが出た arm64 のイメージを pull するようにしてみたが、該当のイメージが無いというエラーが出ることもあれば、別のイメージは pull はできるが実行時エラーということもあった # 実行時エラーの例 sta

ActiveRecord がデータベースとの接続をどう管理しているのかを調べたメモ。主に active_record/connection_adapters 以下の話。現時点での main ブランチの HEAD を参照した。 詰まったときに調べる箇所のあたりを付けられるよう全体観を持ちたいという目的だったので、細かい部分まで把握しきれていはおらず、ご了承ください。 ActiveRecord の使い方のおさらい まず最初にユーザーとして、ActiveRecord でデータベースにクエリを発行する際の流れを簡単におさらいする。 まずデータベースの接続情報を database.yml に記載する。ここではメインとなる primay DB と animals DB の 2 つがあり、またそれぞれに primary (master) と replica があるとする (この例は Active Rec

知らなかったのでメモ。 MySQL の外部キーは相当するカラムのインデックスが必要 必要なインデックスがない場合は外部キー作成時に自動でインデックスも作成される こうして自動で作成されたインデックスは、不要になった際に自動で drop される 不要になった際 = その外部キーをカバーできるような別のインデックスが追加された場合 MySQL :: MySQL 5.7 Reference Manual :: 1.7.3.2 FOREIGN KEY Constraints MySQL requires that foreign key columns be indexed; if you create a table with a foreign key constraint but no index on a given column, an index is created. MySQL :

GCP の CPU usage と CPU utilization 指標についてちょっとハマったので、かんたんに調べたことを整理した。 以下正確ではないが、こういうイメージで理解しているというメモ。また各例は GCE インスタンスの指標をとりあげているが、他も同じだと思う。 CPU usage (xxx/cpu/usage_time) usage_time は 1 秒あたりの cpu が利用中だった秒数。すべての vCPU について、60 秒のウィンドウで計測し集計。単位は s/s で、分子は利用中の秒数、分母は秒だと思う。 例えば 4 vCPU のインスタンスで、ある 60 秒間について、それぞれ 30 秒、0 秒、15 秒、0 秒利用中だった場合、usage_time は 0.75 s/s となる。 (30 + 0 + 15 + 0) / 60 = 0.25 (s/s) 当然数値は 1

デバッグや学習用途でパケットキャプチャする際、https をはじめ SSL/TLS で暗号化されている通信を復号化する方法のメモ。 クライアントが PC 上のブラウザや curl の場合 pre-master-secret (または key log file ?。用語の使い分けは理解怪しい) を使った方法がデファクトっぽく見えた。 pre-master-secret とはざっくり言うと TLS 通信時に使用した鍵情報らしい。これを使ってこんな感じでパケットキャプチャを行う。 クライアントに pre-master-secret のログを出力するよう設定する SSLKEYLOGFILE という環境変数を使うのが標準的な方法 主要ブラウザや curl は対応している Wireshark/tshark などのパケットキャプチャツールで pre-master-secret のログを読み込む この状態

bash のシェルスクリプトを書くときに、いつも脳死で以下をやっている。(同僚が整備してくれたものをコピペしている) エディタなり CI で shellcheck をまわす set -euxo pipefail と冒頭に書く こんな感じ #!/bin/bash set -euxo pipefail いつまでもコピペではさすがにアレなので、意味を調べたメモ。 shellcheck koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts イケてない書き方に警告を出してくれる それぞれの警告にはエラーコード割り振られていてとても便利 エラーコードごとに正誤例、解説が書かれているのでわかりやすい SC1000 の例 CI もそうだし、エディタのプラグインも充実 しているのでとりあえず入れておくと良い set

実用ではなく学習目的で WebSocket の簡単なサーバを書きつつ、その後 RFC で仕様の背景を理解する流れがいい感じだった。 先日読んだ ハイパフォーマンスブラウザネットワーキング で取り上げられていたプロトコルについて深堀りしていこうと思い、一番仕様が薄そうな WebSocket をとっかかりとして選んだ。詳細の理解と、この本の刊行後にあった動きをキャッチアップすること、そして周辺の技術や仕様にも yak shaving 的に枝を広げていきたいなと言う意図。 キリが良いところまで来たので、整理のため一度まとめる。 進め方 WebSocket は 仕様がまとまってからもう 10 年くらい経っている ので、いきなり RFC から入るのではなく MDN でざっと概要と API を知るところから始めた。中でも Writing WebSocket servers - Web APIs | M

ぜんぜん意図していなかったが、なんとなく目に入ったので手にとって読み、やる気が出た。良かった。 「いい仕事」をするエンジニアの行動パターンがひたすら書いてある本。かつ自分はその行動習慣を持っておらず、身につけたいと思っている人の目線で書かれている。一生懸命に (でも計画的に) 頑張って努力して、いい仕事できるようになろうぜ、という汗臭いノリがある。人生を楽しいものだと思っている人と、しんどいものだと思っている人の二種類がいるとして、作者は後者だと思う。自分も後者だと思っていて、この感覚の近さが自分としては良い。 10 年弱前にも読んだことがあったのだけど、当時は初めての転職をする直前だか直後だったと思う。その時はこの本に気持ち的に助けられて、転職後の会社で受けたメディアのインタビューでもこの本の引用をした覚えがある。10 年経った現在、キャリアにどん詰まっている最中で、ある意味当時と近い状

Go の database/sql パッケージ の DB 構造体 は、データベースへのコネクションプールを管理し、かつスレッドセーフ (goroutine セーフと言ったほうが良いのだろうか…?) にそれらの接続を使用できることを保証している。 ドキュメント にも次のように書かれている。 DB is a database handle representing a pool of zero or more underlying connections. It’s safe for concurrent use by multiple goroutines. こちらの基本的な実装内容と、動作を制御するパラメータについて調べてみた。 基礎知識のおさらい database/sql パッケージはデータストアの実装によらない一般的な SQL のインタフェースを提供している。具体的なデータストアへの接

マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その

2011 年の文章だけど、今でもかなり示唆深い。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（前編） Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（中編） Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（後編） 以下は気になったポイントを引用しつつ、行間を読みつつまとめたもの。個人的な解釈も入っているので注意してください。 プロダクトとプラットフォーム まずシステムを “プロダクト” と “プラットフォーム” に分け、それらが根本的に違うと言っている。 特定のセグメントに価値を届けるシステム (垂直統合的)特定のセグメントに機能を素早く提供できる完璧な要件定義をし、それをリリースするのが理想 プロダクト プラットフォーム プロダクトは特定のセグメントに対して価

Docker コンテナ上で Go のプロジェクトを delve でデバッグしたいとき。Docker はデフォルトで ptrace(2) システムコールの呼び出しを制限しているので、これを緩和する必要がある。 具体的には docker run に次のように --cap-add=SYS_PTRACE というオプションを渡してあげるとよい。 docker container run --cap-add=SYS_PTRACE -it your-image:latest bash 背景 Docker コンテナ上で Go のプログラムを delve を使ってデバッグしようとすると次のようなエラーで動かなかった。 root@a135f59c96cb:/go# dlv debug could not launch process: fork/exec /go/debug: operation not pe

make中に、こんなエラーが出ることがあります。 /usr/lib/ld: cannot find -lfoo こんな風にlibfooというライブラリが見つからないと言ってきます。 そこで、ほんとに入っていないのか調べてみます。 $ ldconfig -p | grep libfoo これで、本当にそのライブラリが入っていなかった場合は、インストールしてください。ただ、ライブラリが入っているのに上記のように怒られてしまうことが結構あります。 原因として、シンボリックリンクがきちんと張られていないというパターンが多いです。たとえば、libfoo.soというライブラリが2度バージョンアップして、libfoo.so.6とlibfoo.so.6.2があるとします。ふつうは互換性のため、 libfoo.so -> libfoo.so.6.2 libfoo.so.6 -> libfoo.so.6.2

GoogleのDesign Docについて調べました．Design Docとは，Googleのエンジニアがソフトウエアを開発する際に必ず書くドキュメントです． 一般的にDesign Documentというと，設計仕様書のことをさすようです．設計仕様書はソフトウエアのシステム的な設計がどのように行われているかを記したドキュメントです．一方でGoogleのDesign Docは，あるソフトウエアについて，何を・なぜ・どのように作るかを記したもののようです．両者ともあつかっている対象や，対象としている読者が少しずつ異なっています．このエントリーではGoogleのDesign Docについて扱います． Design Docの内容 Design Docについては，Googleの鵜飼文敏さんによる以下のプレゼンテーションで触れられています． 鵜飼文敏さんの講演「ハッカーのソフトウェアエンジニアリング」

Apigee Web API Design という本を読みました. Web API 設計のベストプラクティスがまとめられている, apigee という API のソリューションを提供している会社がだしているフリーの ebook です. コンパクトに 30 ページほどに読みやすくまとめられています. 以下要点のメモです. 開発者視点 API の目的はアプリケーション開発者 (API 利用者) が可能な限り成功すること. 開発者の視点で設計すること. 本書ではそのような API を実現する tips を紹介する. Pragmatic REST REST 原理主義はよくない. RESTafarian たるべからず アプリ開発者の利便性が一番大事. 実利的な REST 設計が求められる それを本書では Pragramatic REST とよぶ URL 動詞ではなく名詞 リソースを名詞であらわす.

S3 上のオブジェクトはオブジェクトごとに Cache-Control ヘッダの設定ができる。 やり方は簡単で、S3 の Web UI から対象のオブジェクトを選び、Properties の Metadata から Cache-Control のキーを追加すれば良い。 キャッシュさせたくない場合は no-cache, no-store、させたい場合は max-age=86400 などと指定すれば良い。 もちろん API や aws-cli からも設定できる。こちら ではバケットのすべてのオブジェクトの Cache-Control を設定するワンライナーが紹介されていて便利だ。 その他には、[Bucket Explorer]() というサードパーティの S3 クライアントは バケットごとの Metadata のデフォルト値が設定できるよう で、こちらも便利そうだ。 travis-ci の d

ジェイクエリーすぐ忘れる DOM エレメント -> jQuery オブジェクト $() 関数に入れてあげれば OK var sample = document.querySelector('#sample'); var jq_obj = $(sample); jQuery オブジェクト -> DOM エレメント jQuery オブジェクトのインデックス 0 らしい var dom_element = jq_obj[0]; 検証 var body = document.querySelector('body'); var jq_obj = $(body); var dom_elm = jq_obj[0]; body === dom_elm // true

awc-cli の s3 sync で s3 からローカルへファイルを同期する場合、変更前後のファイルサイズが同じだった場合は、変更なしとみなされ、そのファイルは同期されない。--exact-timestamps オプションをつけると、ファイルサイズだけでなくファイルの更新日時をみてファイルの変更判定をしてくれるので、このようなケースでも同期が走る。 sync 挙動の概要 この issue によると、現在の sync の際のファイル変更判定ロジックは、ファイルサイズと最終更新日時で判定しているらしい。s3 からローカルへのファイル同期の場合、ファイルサイズが異なっていれば当然変更があったものとみなされる。もしファイルサイズが同じだった場合、デフォルトでは更新日時を見ずに変更がなかったものと判定されるようだ。 ここでの「最終更新日時」(ListObjects の LastModified)

確か iOS6 の頃からだけど、iPhone の実機に対して Web Inspector (開発者ツール) でデバッグができる。むかしはそういうツールが必要だった気がするけど、もう現代では Safari だけあればよい。また iPhone Safari だけでなくアプリ内の WebView も対応していて便利。 手順も簡単で、 iPhone の Safari の設定で Web Inspector をオンにする Safari -> Advanced -> Web Inspector iPhone と Mac を有線で接続 Mac で Safari を起動し Develop -> 端末名 -> ページ名 を選ぶ たったこれだけで非常に手軽。余計なものを入れなくていいのもうれしい。

fc はコマンドの履歴操作をおこなう汎用的なコマンドで, たとえば history は zsh だと fc -l のエイリアスだったりする. history のように普通に履歴を表示するだけだったら -l オプションをつける. -n でコマンドの通し番号を表示しない -d でコマンドが実行されたタイムスタンプ. -d は時刻だけだが -f なら日付もつく. -E や -i で違う日付フォーマットになる オプションのあとにはどこからどこまでの履歴を対象にするかという 2 つの数字を渡せる. ちょうど python の配列スライスのように開始終了位置を渡せるし, 負の値だと末尾からのカウントになる. 直近 5 つだったらこんな感じ $ fc -ln -5

すこし前だが、Nicholas C. Zakas の記事が話題になっていた。 Node.js and the new web front-end | NCZOnline Node.jsをサーバサイドのUIレイヤに限定するのか？ - ワザノバ | wazanova.jp ワザノバさんの抄訳から引用すると、 JavaScriptエンジニアはフロントエンドのコントロールはできるが、サーバサイドのUIレイヤはバックエンドエンジニアの領域で、それがフロント（JavaScript）エンジニアとバックエンドエンジニア双方のストレスであった。 Node.jsの登場で、サーバサイドのUIレイヤをサーバサイドのビジネスロジックから分離し、フロントエンジニアはブラウザ & サーバのUIレイヤ、バックエンドエンジニアはサーバサイドのビジネスロジックを担当するという切り分けが可能になった。 バックエンドの UI レ