Homebrew Caskの作り方メモ

HomebrewはmacOSの向けのパッケージマネージャで、インストール可能なパッケージの管理もコミュニティによって保守されている。

Homebrewで利用可能なパッケージはFormulaと呼ばれ、homebrew-coreで管理されているが、ここはその名の通り自家醸造（homebrew）可能な＝ソースコードからビルド可能なパッケージしか取り込まれない。一方でバイナリ配布のみのアプリケーションやGUIアプリケーションを取り扱いたい場合はhomebrew-caskで管理することになる。

Formulaの作成や更新は何度かやっていたけれど、CaskはFormulaとは若干作り方のフローが異なっていたので備忘録として残しておく。なお、Caskは樽を意味して、Formulaは製法を意味する英単語。Caskは既に作られたものを溜めておくので面白い命名である。

Caskの作り方

Caskの作り方はCONTRIBUTING.mdを読む。

既にhomebrew-caskを手元に導入済みの前提で、forkした自分のリポジトリをcaskディレクトリ直下でremoteリポジトリとして登録する。リポジトリパスは各環境に応じたものにしておく。

$ cd "$(brew --repository)"/Library/Taps/homebrew/homebrew-cask
$ git remote add me "https://github.com/castor4bit/homebrew-cask"

今回はSlack CLIを新規登録するためのCaskを作ってみる。まずは作業用branchの作成。

$ git checkout -b add-slack-cli master
$ vi Casks/slack-cli.rb

ここからの作業は Adding Software To Homebrew — Homebrew Documentation を参考に進める。Caskの雛形は brew create コマンドにURLを渡すと自動的に作成してくれる。

$ brew create --cask https://downloads.slack-edge.com/slack-cli/slack_cli_1.14.0_macOS_64-bit.tar.gz --set-name slack-cli

Examplesを参考に各項目を埋めていく。

cask "slack-cli" do
  version "1.14.0"
  sha256 "290b60a3798c13bfc11d815807d2115b8dca62532e9509eef8bfc2e8e1863b4a"

  url "https://downloads.slack-edge.com/slack-cli/slack_cli_#{version}_macOS_64-bit.tar.gz",
    verified: "downloads.slack-edge.com"
  name "Slack CLI"
  desc "CLI to create, run, and deploy Slack apps"
  homepage "https://api.slack.com/future/tools/cli"

  livecheck do
    url "https://api.slack.com/future/tools/cli"
    regex(/href=.*?slack_cli_(\d+\.\d+\.\d+)_macOS_64-bit.tar.gz/)
  end

  depends_on formula: "deno"

  binary "bin/slack"
end

Caskのドキュメントは全般的な説明とCask定義の詳細説明でそれぞれ独立しているので、どちらにも目を通すとよい。

• Adding Software To Homebrew — Homebrew Documentation
• Cask Cookbook — Homebrew Documentation

GUIアプリケーションを対象とする場合は app "Slack.app" のように app を利用するが、バイナリ配布のアプリケーションでは binary を利用する。インストール時に自動的に $(brew --prefix)/bin folder（通常は /usr/local/bin）にリンクされる。

depends_on の記法がFormulaとは異なり、caskとformulaのどちらに依存するのかなどを記述する。Formulaのように:recommendや:optionalの指定はできない。

今回はアンインストール時の作業用ディレクトリなどないので zap は削除する。

テストする

インストールのテスト

$ brew install slack-cli

アンインストールのテスト

$ brew uninstall slack-cli

定義ファイルのチェック

Caskの記述誤りやルールに沿っているかなどをチェックする。

$ brew audit --new-cask slack-cli

audit for slack-cli: failed
 - The URL's domain downloads.slack-edge.com does not match the homepage domain api.slack.com, a 'verified' parameter has to be added to the 'url' stanza. See https://docs.brew.sh/Cask-Cookbook#when-url-and-homepage-domains-differ-add-verified
 - Version '1.14.0' differs from '' retrieved by livecheck.
 - Version '1.14.0' differs from '' retrieved by livecheck.
Error: 2 problems in 1 cask detected

最初の実装では url と homepage のドメインが不一致なため verified を付加するように指示された。ドメインが異なることは理解した上で指定していることを明示する目的みたい。

さらに、livecheckで取得したバージョンと不一致であると言われていた。livecheckでどのようなチェックが行われているかは brew livecheck --debug で確認できる。以下は livecheck ブロックを何も記述していない状態での出力でバージョン取得に失敗していることが分かる。

$ brew livecheck --debug slack-cli

Cask:             slack-cli
Livecheckable?:   No

URL:              https://downloads.slack-edge.com/slack-cli/slack_cli_1.14.0_macOS_64-bit.tar.gz
Strategy:         None

URL:              https://api.slack.com/future/tools/cli
Strategy:         None
Error: slack-cli: Unable to get versions

修正してバージョン取得に成功することを確認する。

$ brew livecheck --debug slack-cli

Cask:             slack-cli
Livecheckable?:   Yes

URL:              https://api.slack.com/future/tools/cli
Strategy:         PageMatch
Regex:            /href=.*?slack_cli_(\d+\.\d+\.\d+)_macOS_64-bit.tar.gz/

Matched Versions:
1.14.0

slack-cli: 1.14.0 ==> 1.14.0

• 参考リンク
  • When URL and Homepage Domains Differ, Add verified:
  • brew livecheck — Homebrew Documentation

スタイルチェック

コードフォーマッタで整形する。

$ brew style --fix slack-cli

Pull Requestを送る

$ git add Casks/slack-cli.rb
$ git commit -m "Add Slack CLI v1.14.0
$ git push -u me add-slack-cli 

Pull Requestテンプレートに記載されているいくつかの確認事項を全てチェックして Create pull request を押す。必須の確認事項は以下の3点。

• 安定版であること（ベータ版のみが配布されていない場合は例外としてOK）
• brew audit --cask --online <cask> でエラーのないこと
• brew style --fix <cask> で違反警告のないこと

$ brew audit --cask --online slack-cli
==> Downloading https://downloads.slack-edge.com/slack-cli/slack_cli_1.14.0_macOS_64-bit.tar.gz
Already downloaded: /Users/castor/Library/Caches/Homebrew/downloads/a30cc23554ef08339fed1136f5b83c7fc2593f16b20f32bd21ab6ae66deb42f4--slack_cli_1.14.0_macOS_64-bit.tar.gz
audit for slack-cli: passed

$ brew style --fix slack-cli

1 file inspected, no offenses detected

新規のCaskである場合には更に以下の項目も確認する。

• Token referenceに準拠した命名であること
• 過去に却下されていないこと
• 対象リポジトリが正しいこと
  • 開発版やNightly Buildなどは homebrew-cask-versions に、フォント系は homebrew-cask-fonts、ドライバ系は homebrew-cask-drivers などがある
  • 非公式ビルドなどは取り込まれない
• brew audit --new-cask <cask> が通ること
• brew install --cask <cask> が通ること
• brew uninstall --cask <cask> が通ること

こうして作られたのが以下のPull Request。めでたいですね。

github.com

独自HTTPヘッダのX-接頭辞が非推奨になっていた話など

RFC6648

developer.mozilla.org

Custom proprietary headers have historically been used with an X- prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in RFC 6648; others are listed in an IANA registry, whose original content was defined in RFC 4229. IANA also maintains a registry of proposed new HTTP headers.

RFC6648でX-プリフィクスの仕様廃止となっている。廃止についてのRFCというものもあるのだなあ。

datatracker.ietf.org

標準化する際に旧パラメータを半永久的にサポートする必要があるなど移行コストがかかるということが主な理由らしい。しかし、標準化と非標準化で分離される意味がないという主張であるならばX-があっても問題がないはずでどうも論拠が弱い気がしてならない。

標準化の際にセキュリティ上の理由などで仕様が変更されても追従されないような話はまた別の問題なのでプリフィクスの有無の問題ではないだろう。実際のところ「なくてもよいだろう」という話はその通りとも言えるけれど、「つけるべきではない」という話とは別問題で少しネットを見ていても似たように納得していない人はそれなりにいそうだった。

さておき、こういう流れであれば自分が設計する仕様ではプリフィクスはないように命名する気がするけれど、ベンダ?固有の仕様であることを明示できるようになんらかの接頭辞は付加するのだろうなあ。

well-known URI

RFC6648について調べていた最中に、Real World HTTPなどの著者である渋川よしき氏の記事 HTTPヘッダーのX-は非推奨と言うけれど・・・ でwell-known URIへの言及をみつけた。

/.well-known はスマートフォンアプリ向けの対応で apple-app-site-association や assetlinks.json を配置するようなことはあっても詳しく理解しているわけではいなかったが、各サーバで同じパスを参照すればいいように標準化されている話で古くからの仕組みだと robots.txt や crossdomain.xml などの延長として策定されたように思われる。

RFCでは8615が該当するようだ。

datatracker.ietf.org

ヘッダ名どうするの流れからなので、ここでも命名（パス）をどの程度衝突に強くするかといった問題が出てきそうだが、IANAに登録済みの命名もすでにだいぶカオスな印象なので結構やりたい放題のインターネットを感じる。

ヘルスチェックなんかをこういうパス配下に置くのはよさそうに思ったけれど、あまりそういう話が出ている雰囲気ではないのか。ヘルスチェックなんかはある程度標準化してほしいような仕組みであるけれど、細かいニーズが必要なケースとそうでないケースがあるので最小公倍数だと仕様は膨れがちになりそう。

共通フォーマットを策定しようという動きはあって、これは仕様の標準化とは異なるのだけれど応答情報の命名や構造で参考にしている。

datatracker.ietf.org

Appleが提唱して、SafariやChromeでは既に利用可能な /.well-known/change-password は実用的で良い仕組みだなあとは思った。すべての会員制サービスで /.well-known/cancel-membership 用意してほしい。

Google re:Work 学習と能力開発

マネージャから退いてしばらく経って、組織や人事について再度考え直したいと思ったのでGoogle re:Workを再読している。理解よりも実践が難しいと感じたものだけれど、マネジメントに行き詰まって即効性を求めた時期とは違った読み方ができるのではないかと思った。

直近の課題として、技術的な取り残されを解決したいという最近の動きから最初に「学習と能力開発」から読み始めた。

従業員間での学習プログラムを導入する

はじめに

学習の文化がビジネスの成功に繋がる話。単純な話としての技術力向上というよりは、求められるものが変化しても柔軟に対応できることで競合優位性を得られるということ。

実際に他社の学習の様子から学ぶことは多いし、十数年前に従業員の多い環境を求めて転職したのも学習文化のある環境を求めてのことだった。あれから仕事に追われて成長が止まってしまったのを取り戻したいのが今。ちょうどタイミングや条件が揃ってきたというのはある。

社員同士のトレーニングで伸びていくというGoogleの事例は理想だと思うけれど、能力バランスや向上心の差などをどうツールで埋めていくのかを読み解いていきたい。

学習目標を決める

組織として何を得たいかという命題は難しい。全体最適を考えるほど一般的な研修などに落ち着いてしまって従業員のモチベーションに繋がらないことが多かった。

従業員が学びたいと思っているということ、従業員同士で教え合うことができる内容であること、を洗い出すことがまず難易度高いのであるなあ。会社全体の責任として行うべきと書かれているが、まずは開発組織など小さなところから始めるのはアリなのだろうか。

1対1のメンタリングはペアプログラミングに近い形か。オフィスアワーは回答者のモチベーションが維持できれば望ましい解決とも言える気はした。雑談会のような形の中で知りたいことが聞けるような流れはよさそうというのが最近の周囲の雰囲気としてあるが、参加者の意識がまばらなのはまだ解決されていない。

目指すべきものはまずは適切な学習の機会を適切な従業員に提供することであり、そこに全員が参加することを強制する必要はないのか。しかしタイミングもある気がするのだよなあ。自分も少し前までならばモチベーションが底をついていたので学習意欲が湧かなかったのであった。

さておき、何を得たいかというと情報や技術が不足していることによって発生する機会損失をなくしたいという感じに近いかなあ。うまい言語化が難しい。

「学び」を組織文化の一部にする

機会とフィードバック。

何をもって学びとするかという話は若干あるものの、ルーチンワークを毎日こなすのでもなければ日々の業務の中で常に学びは発生しているとはいえ、既存の技術をなぞって知識不足を補うことを学びと感じられない気持ちはある。

業務においてはレガシーシステムの保守よりも新規案件で新しい技術の導入などに携わったほうが学びの機会は当然多く実のあるものになるが、全ての従業員に公平にその機会を与えられるかというと難しい問題はあり、学びに対するモチベーションの差に繋がっているような気がしている。

学びのためのコストを組織として別途計上するかというのが20%ルールのような制度に繋がってくると思ってしまうが、ここでの話はそういうことでもないのだよな。。

「自分で学ぶよりも同僚に教わるほうが効率よく学べる」というのは同意できる。組織のコアバリューとの関連付けは理想的な形に思えるけれど、この辺りはいくつか実践しないと具体的なイメージに繋がらないのでもう少し考える。早期の導入は入社からのタイミングとなるとそれまでに組織作りが成功している必要があるか。

勉強会なり読書会なり雑談会なり機会をつくることはできても意義に賛同できる人が増えないと継続が難しい。初期は誰かの犠牲の上に成り立つのかそうでない手法があるのか。これまでの成功事例を考えると全員に知識がないケースよりも明確なロールモデルが身近に存在しているほうが成立しやすさがあるけれど。

ファシリテーターの募集

前項で考えていたことを裏付けるような感じがしたけれど、やはり熱意と専門知識を持ったファシリテーターは必要。不在の場合は次の育成という話になってくるのか。

参考資料は具体的なアプローチこそ提示されていないものの、ファシリテーターとして意識するべきことがまとまっている。

ファシリテーターのスキル開発

ワークショップは実際に体験したわけではないが資料からイメージを感じとる。

成人学習者

恥ずかしながら「成人学習者」という単語を知らなかったのだが、子供に対する教育と成人に対する教育は区別するべきだという考えがあり成人学習者は子供とは異なる性質を持つのだという。

成人学習者をイメージしてみると、「すでに一定の知識がある一方で固定観念に囚われそうである」「自分にとって有用かどうかを軽率に判断してしまいそう」「プライドが高く素直に学習できないのではないか」というような若干ネガティブな印象がいくつか思いついた。

少し調べてみると、「学習者自身が主体的に学ぶ」「過去の経験を生かして学ぶことができる」「何を学ぶべきかを理解した上で課題解決に取り組むことができる」などの特徴が挙げられておりなるほどであった。

プレゼンテーションの三原則

「トーン」「テンポ」「間のとり方」。

あまり話すのは得意ではないのでトーンやテンポは比較的苦手というか自然にはできない。内容の区切りなどで間を取るのは比較的意識的に行っていると思っている。

ファシリテーションの定義

プレゼンテーションの主体が本人であることに対してファシリテーションの主体は他の参加者であり、ファシリテーターは参加者は議論が進行し目的を達成するための手助けをするものだと理解している。結論に誘導するような発言をしたり、誰が発言するのかをコントロールしたりするのは誤った手段であるように感じる。

プレゼンテーションとファシリテーションに優劣があるわけではないだろうが、プレゼンテーションは知識を一方的に与える形になるので、どちらかといえば成人学習者ではなく子供などに対する手法に適しているのではないだろうか。

このセクションには特に正解などは示されていないのではたしてどうなのだろう。

知識の呪い

これはよく分かる。

前提知識の少ない相手にどのように伝えるか、どのような情報が不足しているのか、何が知りたいのかは資料をよく書いていると意識しがちではある。自分の場合は逆に情報過多になってしまいかえって読みづらいというパターンが多いと思っている。内容の優先度をうまくつける必要がある。

厄介な学習者

「冗舌な学習者」「皮肉屋の学習者」「無口な学習者」「やる気のない学習者」。

効果的な対処が示されており勉強になる。人数が少ないほうが安心する人がいる、2名1組だと積極的に関わらざるを得ないというのはなるほどである。

まとめ

なんんとなくファシリテーションのテクニックというよりは講師の心構えに近いものを感じたが、参加者のマインドをうまく誘導するという意味では通じるものがあるのかもしれない。ファシリテーションで難しいと感じる脱線や議論の発散を防ぐようなテクニックをもっと身につけたい。

効果的なフィードバックの提供

ここでもトレーニングやコーチングについて言及されている。講師っぽい。

功績の評価と表彰

ファシリテーターのモチベーションを維持させることも重要。ファシリテーター同士のコミュニティというのは内側からの刺激があって有用に思われる。

見落としがちな注意点

先にファシリテーターの育成を行うよりも参加障壁を下げて徐々に改善していくほうが望ましいという話。

上層部からは許可だけではなくサポートを受けるというのは、学習環境を整備するための購入支援とかカンファレンス参加費の補助なんかを指すのだろうか。学習文化の成果について定期的にフィードバックするのも、参加者がやっていてよいのだという気持ちをしっかり持てるのではないかと思った。マネージャー的な立ち位置からもそういった活動をちゃんと把握しておく必要があったよなあ。と。

ガイドを読み終えて

組織の話なので当然ではあるが、個人としてどうしていくかよりも学習文化をどのように根付かせるかという点にフォーカスされていた。どちらにしても学習目標を立てて、学習環境を整えてすすめることが大事である。

直近では、積ん読や内容忘れている技術書を再読してあらためて知識の下支えをしていきたい。

2021年に買ってよかったもの

生活が変わって色々と買い揃えた気がするけれど、意外と地味なものばかりが便利だった。思い出したら追記していく。

野菜フレッシュキーパー

100円均一で購入したもの。多分キャンドゥだったけれど、ダイソーやセリアでも同様の商品があると思う。

一人暮らし時代は小さめサイズを買って一気に使い切るか大半を捨ててしまっていたものだった。ちゃんとサラダとか作るようになって一度の消費量が減ってくると鮮度が気になるので買ってみた。

正直半信半疑であったけれど、数日経過してもほとんど変色しないので驚いた。爪楊枝なんかでも代用できるとは言うものの、それなりに硬さもあるし再利用もできるので買ってよかった。一週間くらいで一つ紛失したけれど二個セットなので安心。

持ちやすい汁椀

www.nitori-net.jp

お椀の下部が平たくなっているだけではあるのに信じられないくらい持ちやすくて、熱さも感じにくいのが個人的には嬉しい。外食するときに出されたお椀がこれじゃないと違和感を感じて持ちにくいと思ってしまうほど気に入っている。

ムヒソフトGX

www.ikedamohando.co.jp

アレルギーなのか妻の背中が荒れてしまいがちなのをなんとかしたくて購入した。

かゆみ止めでは肌荒れや掻き傷が治らないし、軟膏ではかゆみが止まらないけれど、この商品ではかゆみ止めと肌の治療、保湿まですべてを賄ってくれるので、これだけで欲しい物が一通り揃ってくれる。

塗るとしばらくは落ち着いて改善するので定期的に使って少し平和が訪れている。

Serverless、イミュータブルデータモデル、PolyForm、ホラクラシー。

読んだ記事

今Serverlessが面白いわけ v19.09 from Yoichi Kawasaki

www.slideshare.net

Serverless周りはしばらく追っていなかったので、最近の情報を知りたいと思って読んでいた。とはいえ2年前の記事であり更に事情は変わっている可能性はあるが、それでも自分の把握している状況よりは新しくよく整理されている資料で大変有り難い。

Firebaseがエコシステムを強化してFaaSもLambda一強から多少情勢が動いている印象ではあったけれど、標準化の動きがあるのは非常に望ましいと思う。ベンダロックインしない世界が早くきてほしい。とはいえ2021年現在でもまだ状況が大きく変わっていないところを見るになかなか難しい感じもあるのだろうなあ。

インフラ周りは整備が進んでいるものの、全体としては停滞気味というか Why the Serverless Revolution Has Stalled などという記事も出ていたりしてなんとも。

個人的に調べたかったのはServerless全体の動向というよりはフレームワークのトレンドではあったのだけれど、すぐに代替ソリューションに取って代わられると思っていたServerless Frameworkが未だにというか逆に主流になっているような雰囲気でもあり、安心して使ってよいのかよく分からないまま再入門するのであった。

scrapbox.io

設計周りの考え方を最近アップデートしていなかったけれど、そう大きな（自分の中での）パラダイムシフトなど起こらない想定でいて衝撃を受けた。

どちらかというと、これまで迷いながら間違ってきた部分が明確に正しい理屈でもって否定してもらえたという気持ちで、ここまで綺麗に文章化されたデータモデリング手法は初めて見たので感動があった。しかし全体把握が容易なレベルでの小〜中規模アプリケーションでどこまで厳密にモデリングするかという悩みは未だに残ってしまうところで、結局地獄を見ているのは小規模から始まったシステムが経年で肥大化した結果なのだよなあ。

リソースの世代管理でバージョンタグ付けの例があったが、類似の状況としてイベントトリガではなくあらかじめ指定された期間によって適用されるバージョンが差し替わるような仕様で、うまくバージョンを付け替えていくにはどうすればよいのか迷っていてこれについては読んでも解決がみえていない。Materialized Viewがあれば対応できるというのはまあありそうだがMySQLでやりたいのであるが…。

tech.bitbank.cc

一般的なOSSライセンスやAWSとOSS企業との問題くらいまでは把握していたが（これをStrip-miningを呼ぶのは知らなかった）、OSSから外れた新しいライセンスや独自ライセンスの誕生など状況は混沌としていそう。

記事ではPolyFormと呼ばれるCreative Commonsライクなライセンスが紹介されておりなるほど感はあるけれど、そもそもとしてオープンソースの定義に対する課題を解決するものではないので軸が違いすぎるとは思った。個人としては、ソフトウェア配布などはNYSLなどを採用していたし最低限の著作権だけは主張しつつ利用側が分かりやすければ後はどうでもというスタンスではあったので、その辺りに近しい汎用ライセンスとして共通のものが生まれるのは便利ではあるのかもしれない。

blog.h13i32maru.jp

これまで考えてきた組織の作り方と全く異なる概念で理解するのに苦労している。

ホラクラシーというものを知らなかったので、そこから勉強しなおしている。人からロールへ、暗黙のルールではなく明文化された憲法とガバナンスというところはなんとなくイメージできるものの、それでどのように組織を運用できるのかの具体的な形に結びついていない。

最後まで読んでもどのようにこの運用が成立するのか分からなかったので、もう少し学びを積んでから再読したいなあ。

マネージャ時代は組織論についていろいろと考え試しては失敗して現在は管理職から退いているが、様々な文献を漁っても今のところ自分の中では良い組織を作るにはまず良い人材で集めることだという身も蓋もない結論になっており、組織を育てるという観点では絶望感が否めない。

しかし、Ubieの人事評価についての記事「人事評価は不毛？〜評価なしで100名の壁を超えたUbieの事例〜｜sonopy@Ubie Discovery｜note」を読んでも、この人事制度でも成立する人材のみで組織されているから問題がないという流れになっており、結局のところ途中で組織を立て直すことなどできないのだろうか。迷走はまだ続きそう。

鶏むね肉とぶなしめじのマヨホイル焼き

今日の料理

www.kewpie.co.jp

作りたいメニューに対してレシピサイトが複数みつかるときは、白ごはん.comか調味料メーカーさんのレシピを選んでしまう。今日はキューピー。

トマトとアボカドはなかったので代わりにエリンギを入れた。

ホイル焼きは過去にもやったけれどアルミホイルが全然足りずに包めないことが多いので、自分のイメージよりも大きめに用意することは大事という教訓がある。今回も1枚無駄にしてしまった。

味付け薄めになるのではと不安だったけれど、味噌がしっかり仕事をして実に美味しくなってくれた。

食材は重ねるのではなく並べるようにしないと味が染みずに淡白なものが上の方に残ってしまう。今回はマヨネーズをかけたので若干誤魔化せたけれど、次回は汁気が全体に行き渡るように工夫したい。敷いた玉ねぎが少し焦げてしまったのは火が強すぎたのだろうか。

データベースエンジニア養成読本

gihyo.jp

部屋の掃除をしていて発掘されたので捨てる前に再読しておく。8年前であるし内容はだいたい忘れている。

巻頭企画

第1章 データベースエンジニアの心得

• データベースの特徴的な機能としてのトランザクションとACID特性
  • Atomicity（原子性）
  • Consistency（一貫性）
  • Isolation（独立性）
  • Durability（永続性）
• 非機能要件の評価指標RASIS
  • Reliability（信頼性）
  • Availability（可用性）
  • Serviceability（保守性）
  • Integrity（保全性）
  • Security（安全性）

ACIDはともかくRASISは単語として普段あまり使わないので忘れがち。無意識に考慮しているものだけれど、共通言語があると第三者への説得力が増すので有り難いのである。

保守性の記述がデータ正規化などになっているのはアプリケーションレイヤの文脈で若干本題から逸れている気がした。システムとしての保守性はステータスの把握だったりオペレーションの容易さなどが含まれるのではないか。

このあたりの評価指標は、最近は定性的なものではなくMTBFやMTTRなどで定量的に評価されていそう。

第2章 大規模サイトを支えるデータベースエンジニアの仕事

GREEでのデータベース大規模活用の事例。

LAMPにLVSというインターネット拡大期の構成が今では若干懐かしさを覚える。Flareとかあったなあ。

インフラチームにデータベーススペシャリストが存在する組織は何度も試そうと思うけれど、どうしてもサービスについての知識が深くないと踏み込んだ設計やアドバイスができないので悩ましい結果になってしまうが、GREEではうまく回っていたのかが気になる。実際のところ、データベースについての諸知識もアプリケーションエンジニアに求められる領分であると思いたい。

「トランザクション/JOIN/サブクエリを避ける」は大規模サービスでスケールさせるために採用することもあるテクニック。複雑な処理をスケールしやすいアプリケーション側に寄せるのも結構やりがち。

活用事例はちょっと特殊なので一般的な参考になるか微妙かもだけれど、データベースエンジニアの業務として列挙されたものはよいまとめだと思う。

特集1

第1章 RDBMS、NoSQL - DBを適材適所で使いこなすための基礎知識

RDBMSとNoSQLが競合するものではなく相互補完する形で共存していくような予見は正しくて、2021年現在でもそれぞれの特性を活かして生き残っている。KVSはRedis一強の様相で、TokyoTyrantやRiakは最近では聞かなくなってしまった。カラム志向の分散DBが存在感を増している。

コラムのCAP定理について、提案者であるEric Brewer氏が現在は「3つのうち2つ」はミスリーディングであると訂正しているのは知らなかった。実際のシステムでは状況に応じて優先されるものが変化したり、優先度合いも0/1ではないという主張に変わっているようでなるほどである。

参考: CAP Twelve Years Later: How the "Rules" Have Changed （日本語訳）

第2章 MySQLを使い切るための基礎と最新知識

MySQLのEdition別機能比較や構成解説、当時の最新版5.6の新機能紹介などをさらりと解説。さすがに現在は古い情報で参考にはならないかとは思ったけれど基礎知識としてはまだ使えるようにも思える。

第3章 PostgreSQLを使い切るための基礎と最新知識

PostgreSQLは6.x時代に使っていたきりなので最新情報を斜め読みするには便利だった（とはいえ8年前である…）。

高機能で運用が複雑なPostgreSQLと、軽量シンプルなMySQLという初期の対比は今ではなくなってしまったし、使い慣れているという理由だけで自分はMySQL中心に使っているけれど、PostgreSQLの採用もちゃんと視野に入れておくほうがよいのだろうなあ。記事時点で最新版は9.3だったが、2021年8月現在ではなんと13.3であった。

当時の時点でJavaScriptでのストアドプロシージャとか書いてあって鼻血出る。

第4章 MongoDBを使い切るための基礎と最新知識

基礎知識シリーズ。

この辺の解説を読んでも初学者だとピンとこないだろうし、具体的な活用事例や導入に適したパターンなどがあったほうが嬉しいのではという気もするけれど、用途を変に限定させるよりは自分で学んでいってくれということだろうなあ。

ドキュメントDBといってもスキーマレスで無法に使うと秒で破綻するので、実際にはそれなりにスキーマ設計はされる。投票とかアンケートサイトのような単一機能でちょっと複雑な構造もありうるようなものを作るには非常に強力でRDBMSに対するアドバンテージがあると思っている。大規模サービスで長期的に導入するかというと迷う。

第5章 Redisを使い切るための基礎と最新知識

具体的な利用事例が載っていてこれはとてもよい。

KVSとしても充分に利用可能だし、やはりリアルタイムランキングは圧倒的に強力。キューやPub/Subも便利なのである。

memcachedと比較しても充分に高速というのは若干厳しいのではと思ってしまうけれど、KVSとして充分に高速なのはまあ事実。memcachedは高速すぎるので比較するのは可哀想…。

Redisは2021年現在でも積極的に進化を続けていて活用事例は今後も増えていくのは確実だし、本誌で紹介されている中では動向を追っておくべきソフトウェアの筆頭な気がする。

第6章 Riakを使い切るための基礎と最新知識

分散KVSとして高い可用性と性能を誇るRiakであるけれど、KVSというよりはS3互換ストレージのRiak CSとしての利用が一般的だったような気もする。

最近動向を聞かないと思っていたけれど、2017年に開発元のbashoが事業継続不可能になって買収されていた。開発自体はまだ継続しているようで、何かのタイミングでまた復興してくる可能性もあるかもしれない。

特集2

第1章 データベース設計とは何か

ちょっと内容のない（よく分からない）章であった…。

第2章 ドキュメント型NoSQLにおけるデータベース設計の考え方

前章でもそうだったけれど若干大雑把な記事を書かれる執筆者さんのようであるという印象があるが…ドキュメント単位で設計することを書類と引き出しのたとえにするのは妥当感はあるように思える。

RDBMSでの正規化脳からうまく切り替えられるかは慣れが必要な気がしている。冗長なデータに不安感が出てしまうのはまあ分かる。ドキュメント型NoSQLの設計で迷ったときは、AWSのDynamoDBの設計ガイドを参考にするとよいのではと思っている。

参考: NoSQL Design for DynamoDB - Amazon DynamoDB

全体の感想

さすがに8年前の本なので情報が古く今から読むには適さないけれど、データベースを取り巻く概観を察するにはよい無いようなので5年間隔などで刷新されてほしいシリーズという気はする。

終盤にはデータモデルや関係代数、SQL入門、正規化など基礎知識がまとまっていて、本誌の中では技術寄りの比重が高いので初学者には難しいかもしれないけれど、本当に大事な基礎がコンパクトに詰め込まれていてこれは何年経っても劣化しない有用な情報だと思った。

全体として知っている情報が中心ではあったけれど、Redisの新機能だったり最近追えていない動向を再認識する良い機会になったので最後の最後にまた役立ってもらった。