サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
please-sleep.cou929.nu
Web配信の技術―HTTPキャッシュ・リバースプロキシ・CDNを活用する田中 祥平 (著) Amazon.co.jpで詳細を見る Cache-Control ヘッダから始まり、クライアント (ブラウザ) のローカルのキャッシュから CDN まで、Web システムの「配信」の最適化技術を網羅的に解説してくれている本。 業務の必要に応じて、CDN など個別のソリューション (の必要な一部の機能) は使ったことがあったり、Cache-Control の一部のディレクティブは都度調べて指定したことはあった。こうした「配信」に関する知識は各論の寄せ集めになっていて、体系的に理解できていないなという実感が以前からあった。また例えば HTTP のヘッダの仕様は歴史的経緯もあり複雑で、RFC から追おうと思っても必要な文章が複数あったり、実際の世の中の実装にばらつきがあったりと、キャッチアップコストが高い
Databases in 2023: A Year in Review | OtterTune Andy Pavlo (CMU, OtterTune) による毎年恒例の DB 業界動向年間レビュー LLMs による Vector Databases の隆盛 (専用の DB ではなく、既存 DBMS の機能としての提供も追いついてきそう) 新標準 SQL:2023、目玉はグラフ構造へのクエリと、多次元配列のサポート。いずれも実装はまだほぼ無し MariaDB (会社側) のごたごた NOTAM というシステムの障害でアメリカ国内線が不通に。80年代に作られたままの、RDBMS を使っていない、おそらく CSV か何かを編集するような自家製 DBMS らしい などなど。相変わらず技術面からファイナンス含めた企業の隆盛までカバーしており面白い Big Data and Beyond: My Pr
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 上に開発環境を構築したメモ。 背景 もともと Vagrant + VirtualBox (クライアントは MacOS) で開発環境を構築していた M1 チップの Mac に乗り換えたところ、VirtualBox が未対応だったので、EC2 (ubuntu) 上に環境を移した 今回 multipass がなかなか良さそうなので環境の移植を試した multipass とは canonical が開発している ubuntu の仮想環境がさくっと立ち上げられるもの cli のみだったり、コマンドもシンプルだったり、cloud-init に対応していたり、なかなか developer friendly というかセンスが良い第一印象 やってみた感想の雑多なメモ M1 Mac 上ではアーキテクチャが aarc64 の ubuntu のイメージしかなさげだった 自分の場合これまで x8
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
記事 We analyzed 30 SRE job postings to find top SRE responsibilities.. 30 社の JD を集計して SRE という役割の仕事をまとめたもの インフラの構築運用、SLOSLIの定義と管理、モニタリングとアラートの設定、オンコール対応、自動化 10 questions teams should be asking for faster incident response | PagerDuty pagerduty の統計では 2019-2020 比でインシデント数は増えているが MTTA, MTTR は改善していてるらしい。より効率的に障害に対処できるようになってきている 障害対応を Detect, Prevent customer impact, Diagnose, Resolve, Learn のステップに分けてそれぞれ
知らなかったのでメモ。 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 のログを読み込む この状態
VPC DNS スロットリングが、Amazon が提供している DNS サーバーへのDNS クエリの失敗の原因となっているかどうかを判断する を読んでいて、tcpdump でキャプチャしたパケットをファイルに落とし、それを読み込んで DNS のクエリ数を分間で集計する例が記載されていた。 このページの本論も興味深いが、苦手な tcpdump の使い方は地道に身に着けて行こうと思い調べた内容をメモ。と言っても man を読んだだけだが、-w オプションに加えて便利なファイルのローテーションを行う機能などは知らなかったので勉強になった。 ネットワークインタフェースの一覧を確認する ifconfig… とついやってしまいそうになるが、ip コマンドを使ったほうが良い。手元の Ubuntu 20.04 (Vagrant) には ifconfig はデフォルトでは入ってなさそうだった。 If you
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 年経った現在、キャリアにどん詰まっている最中で、ある意味当時と近い状
複数のデータストアに分かれているユーザーの認証情報を、マージしてひとつに統合したいという要件があり、認証 Saas 大手の Auth0 に Automatic Migrations というそれっぽい機能があったので調査した。特に複数のユーザーデータの名寄せをどうやっているのかが知りたかった。 結論としては、名寄せは当然自動でできるはずもなく、ユーザーからのアクションや自前での実装が必要という当たり前の結果となった。とはいえ全体のフローは参考になった。 Auth0 とは Auth0: Identity is Complex. Deal with it. 認証・認可機能を提供する Saas AWS の Cognito や GCP の Firebase Authentication が恐らく競合 認証・認可はドメイン特有の知識が求められるが、多くのサービスにとって差別化できる部分ではないので、S
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 としています その
IETF には rough consensus and running code というモットーがあるらしい。 rough consensus and running code IETF | Running Code We reject: kings, presidents and voting. We believe in: rough consensus and running code. https://www.ietf.org/proceedings/24.pdf きっかけは、仕事で技術的な判断のファシリテーションがうまくいかず困っていて、標準策定をする組織のベストプラクティスが参考になるかもと思ったこと。彼らは構造上トップダウンで方針決定をできないはずだし、加入時の選考がないのでメンバーの多様性もより大きいはず。そんな環境での合意形成は普通の企業よりも難しそうなので、参考になるの
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
前回の続きです。 機会があり、オープンソースのライセンスについて調べました。その結果について、簡単にまとめてあります。 調査を通じて、僕にはこういう法律系の細かな作業が、向いていないなあと痛感しました。ややっこしくて、文章を読んでいて疲れてきます。 概要 オープンソースの著作物(ソフトウェア以外のものも含む)は、商用・非商用問わず、第三者に再配布できる(ただしクリエイティブ・コモンズの非商用オプションは除く)。その際の条件はライセンスに拠り、著作者のクレジットを表記するだけでよいものから、すべてのソースコードを公開しなければならないものまで幅がある。 オープンソースのソフトウェアを用いたWebサービスについては、ソースコード配布の義務はないという見識が一般的である。 オープンソースの条件 次の要件を満たすものを、オープンソースと呼ぶ。 自由な再頒布ができること ソースコードを入手できること
前回(Makefileの書き方スピード再入門 - フリーフォーム フリークアウト)の内容について、twitterで@makingさんに、pyopyopyoさんの素晴らしい記事について教えていただきました。 Twitter / making: .@cou929 make -pみてみるといいです。 ... Makefile は簡潔に書きましょう - ぴょぴょぴょ? - Linuxとかプログラミングの覚え書き - 内容は、最大限にmakeビルトインのルールを活用して、極力シンプルなMakefileを書こうというものです。 デフォルトのルールの確認 Makefileがあるディレクトリで、make -p します。出力は結構大きいです。 簡潔な書き方の例 例えば、foo.cppをコンパイルして、fooというバイナリを作るときは、 all: foo これだけで全てやってくれます。これはすごい。ソースコー
Makeとは ソースコードをコンパイルするルールを記述できる より一般的には、階層的な依存関係のある、コマンド郡を記述できる。 階層的な依存関係とは、例えば、処理Aが終わらないと処理Bができない場合、BはAに依存している。 基本 target: source file(s) commmnd targetを作るには、source file(s)が必要(targetはsoure filesに依存している)で、commandを実行することでtargetが作られる。例えば、 foo.o: foo.c cc -c foo.c また、command行の先頭は必ずtabでないといけない。 このようなルールの集合からmakefileは成り立っている。また、これをより簡潔に記述するために、以下の機能が提供されている。 phonyターゲット clean: rm -f *~ 例えばこのように記述すると、コマンド
東京Node学園祭2012 アドベントカレンダー の 20 日目の記事ですが, あんまり Node は登場しません... Node.js がでたての頃は C10K 問題とからめて説明されることが多かったかとおもいます. C10K 問題といえば次の有名な記事がありますが, TheC10kProblem - 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと はじめて読んだ時は内容をさっぱり理解できませんでした. 特にノンブロッキング, 多重化, 非同期といった IO まわりがわからずついていけなかったので, 当時しらべたり試したことを紹介したいと思います. はじめに おもに詳解 UNIX プログラミングを参考にしているため, 内容が古いところがあるかもしれません. またサンプルコードや図も最
一つ前のエントリで JavaScript のトピックスについて紹介しました. 避けなければいけない JavaScript の失敗 - Please Sleep この中でエレメントノードのテキスト部分を取り出す innerText プロパティについて説明していましたが, これは非標準で Firefox ではサポートされていません. 標準になっているものとして textContent というプロパティがあります. 一応エントリ下部のコメント欄紹介ページでこのことについて触れているんですが, もっときちんと取り上げないとフェアじゃない気がしたので, 改めてこの2つのプロパティについて取り急ぎエントリにしました. 仕様とブラウザサポート textContent も innerText もある要素の text 部分にアクセスするためのプロパティです. 例えばこのような html に <div id=
次のページ
このページを最初にブックマークしてみませんか?
『Please Sleep』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く