今まで生き残ってきたRDBMSとこの先10年戦えるデータストア戦略 @soudai1025

「今日はHOWの話はしません」と冒頭で明言しRDBの過去と未来とを俯瞰して眺めるセッションだった。

技術選定の審美眼 / Understanding the Spiral of Technologies を強く意識した内容だが話題がRDBというスコープに絞られている点がRDBを主戦場とする自分にとっては大変有り難かった。

しかし発表している当のそーだいさんは既にRDBから次のステージに移られた気がする。PHPカンファレンス沖縄2021のスポンサーセッション AIを始める一手はHaveFunTechから/合同会社HaveFunTech でAIやそれを導入するためのS3やRedshiftの話をされていたのを見て驚いたのだが、今回もS3やDynamoDB, NewSQLが当たり前のように出てきた。

自分が長年ITの世界で飯を食えているのはRDBに精通しているおかげだ。これは自覚がある。そーだいさんは昔よく、「変わるもの変わらないものを見極めてほしい、今後もRDBやSQLはそう変わらないだろう、普遍的な強みとなる知識を身につける意味で是非RDBを学ぼう」と言ったことを仰っていた。

考え自体はおそらく変わっていないと思うが、立て続けにサーバレス技術やNoSQLを語られる姿を見て、セッションでは「データベース」ではなく「データストア」という言葉を使われているのを見て、これはいよいよRDBに胡座をかいていられないと身が引き締まった。そーだいさんありがとう。

PHP で PHP のプロファイラをつくろう @sji_ch

php製phpプロファイラ reli-prof の紹介。phpの話としては自分にはハイレベルすぎた。Linuxの話として興味深く聞くことが出来た。

プロファイリングはパフォーマンスを激しく劣化させるのが自分の中での常識だったのだがそういった影響なく計測が可能、拡張機能も不要。魔法のような話にキョトンとしてしまったのだが、OSを経由して実行中プロセスのメモリを外部からダンプしパースする実装とのことだった。つまりphpの話ではなくOSの話だった。

ハイレベルすぎてphpの分野で自分が真似できそうな箇所は無かったのだが、FFIの現実的(?)なユースケースを知れた意外な収穫、Psalmのジェネリクスでポインタを表現するアイディアに膝を打つなど、アイデア次第で機能の使いみちはいくらでも作り出せることを再確認できた。自分も引き出しを増やしたい。

一点だけ直接の糧になった点がある。可視化の点だ。自分はとにかくユーザーインターフェースに苦手意識があり、どんなツールを作るにもCLIの標準出力でお茶を濁して終わらせてしまうのだが、今回のツールでは主要な可視化ツールのフォーマットに予め対応しカスタマイズも可能としたことでGUIの部分はほぼ他所の技術に乗っかっていた。まあ 普通のやり方 だと思うのだが、本体のツールが極めてローレベルなだけに割り切りの鮮やかさが見事だと感じた。

そういえば PHP Conference Japan 2021でのセッション も自分にとってハイレベルすぎる内容で、似たような感想を書いた、というかろくにかけなかった記憶がある。一方で不思議なのは、全体的に 解った気になれる のだ。解らないなりにもダイジェストに雰囲気を味わえるというか、この辺りは説明の上手さなのだと思う。

コミットメッセージ規約「Conventional Commits」を導入してみよう！ @cocoeyes02

commitメッセージを丁寧に書くことの重要性、フォーマット統一の利点、それを行うツールや導入メリットの話。

Conventional Commitsという規約は初耳だったのだがいわゆる「GitHubでよく見るやつ」だ。元々はAngularの規約らしい。そういえばAngularはログもCHANGELOGもとにかく綺麗だった。

Commitログのルールはチームで導入しようとしつつこれまで何度も失敗している。結局手作業のため強制も出来ないし人によって表記がブレる、何より自分自信がその手のは苦手。そう思いながら見ていたところツールが紹介されてくれ大変ありがたかった。CUI上の対話プロンプトで選択肢から設定、これならブレない。blogを書き終えたら早速、導入検討のために触ってみようと思う。紹介くださってありがとうございます。

なお規約にはcommit内でのBCの有無を識別するフラグも定義されている。そして Conventional Changelog というツールもあり、BCの有無を調べセマンティックバージョンを自動的に付与してくれるとのこと、これは凄い。

是非導入、と思ったのだがそういえば業務中に作成する業務コードでセマンティックバージョニングというのもそう無い、残念。いつかこのツールの便利さを感じられるようなOSS作者になってみたい。（なれるだろうか）

カオナビでのチーム開発の舞台裏

チーム改善の話。最近は仕事の内容が微妙に変化してきたため、プロジェクトやチームの話はできるだけ積極的に聞くようにしているのだが、本セッションは極めて 等身大な 内容と感じた。

• 開発の進捗が悪化してきた話。
• POがそれに対し不信感を抱き始めた話。
• 「問題はありませんという問題」

どちらかというと生々しい類の話だが、どう解きほぐしていったのか淡々と紹介して下さったのが有り難い。難解な問題を優れたマネジメントや華麗なパターンで解決した話ももちろん参考になるが、普段必要とされているのはこういった 等身大な 話だ。コミュニケーションの大切さを再確認した。

ツールの選定も秀逸だ。TrelloのようなカジュアルなUIは「問題はありません問題」をカジュアルに顕在化させるのに最適なツールだと思う。

テクニック面ですぐにでも取り入れたい内容があった。工数見積の不確実性に関する話だ。

経験上、最初の設計を間違えたプロジェクトは高確率で大変な目に遭う。非常に重要なフェーズだがそこにかかる所要時間は予測しづらい。初顔合わせの多いチームでパターンやコンテキストが共有されていない状況では特に。

紹介された方法は次のとおりだった。

• スプリントのプランニングの前段階に設計の時間を取る。
• プランニングと設計は決して同時進行で行わない。

設計有りきでプランニングを行うことで見積もりは決してブレない。プランニングのみに集中する時間を設けることでそのプロジェクトでの暗黙のパターンが自然と共有されていく。なるほど当たり前の話なのだが、こういった小さい工夫でプロジェクトは良くなっていくことを知れたのは心の支えになる。

PHPerでもできる！マイクロサービス

「PHPでもできる」に興味があり拝見した。PHPはなまじ慣れているため、よほどの足かせを自分に嵌めないとマイクロにならないのだ。言語仕様やエコシステムの特性としてマイクロサービスにあまり向かないイメージもある。なお単なる先入観とスキル不足であることは解っている。

コードこそ出てこなかったものの非常に実践的な内容だったと思う。

• マイクロサービスに向く箇所と向かない箇所を見極める
  （向かない箇所は無理しなくていい、ということ？）
• DBアクセスが必要だとしたらそれはむしろマイクロではなく本体
  （本体までマイクロを突き詰める必要はない、ということ？）
• マイクロ＝小規模 は 2週間で書き直せる程度 を目安にする
  （指標が用意されると組み立てがやりやすい）

最後の条件のみ少々厳しい気がするが、このような具体的に指標を提示されると自分でもできそうな気がしてくる。Eコマースサイトの各機能になぞらえてそれぞれ説明して下さったのもわかりやすくて良かった。

後半はphpを半ば前提とした極めて具体的なテクニックの紹介、これも有り難い。

• マイクロであるなら脱フレームワークは必須。
• それでも依存管理はほしい、軽量DIコンテナの検討を。
• HTTP API / キュー / イベント それぞれのメリット・デメリット
• ECS, SNS, SQS, Lambda の利用例

「マイクロサービス」という題材は設計寄りの話題がどうしても多くなりがちだが、かなり実装に寄った話が聞けて大変有意義だった。