ISUCON 12 の予選に参加して、7位で本選進出を決めました
こんにちは、@p1ass です。 先日行われた ISUCON 12 の予選に @km_conner と @atrn0 と参加しました。
結果は 35642 点・7 位で、本選に行くことができました。わいわい 🙌
この記事では、事前準備や本番中に入れた改善について紹介します。 なお、今回はコミットごとのベンチのスコアをほとんどメモしておらず、途中のスコアは概算となる点にご注意ください。
GitHubはこちらです。 masterがバグることが何回かあり、コミットやPR単位で実装を見てもFAILするコードになっている場合があるので注意してください。 (主に僕の実装)
protocの代わりにBuf CLIを使ってスキーマ駆動開発の体験を向上させる
こんにちは、@p1assです。
この記事では、Protocol Buffers に関連した様々なコマンドを実行できる Buf CLI を紹介します。 Buf CLI は、protoc とは異なり、Formatter や Linter、Breaking Change Detector、依存パッケージ管理など、Protocol Buffers を使う上で便利なコマンドが用意されています。 Protocol Buffers を使いたいけど CI のセットアップ等が面倒な人におすすめです。
Buf のロゴ(公式サイトより引用)
- 公式ドキュメント: https://docs.buf.build/introduction
- GitHub: https://github.com/bufbuild/buf
- 執筆時のバージョン: 1.6.0
SPA で役立ちそうな OAuth 2.0 for Browser-Based Apps を読んだ
こんにちは、@p1assです。
GW 中に SPA で OAuth を使うときのプラクティスについて調べていたところ、OAuth2.0 for Browser-Based Apps という RFC の Internet-Draft を見つけました。
一通り読んでみたところ、現時点でのベストプラクティスが良い感じにまとまっていたので、興味深かったところを抜粋して紹介します。
Twitter API v2のOAuth 2.0 Authorization Code Flow with PKCEを試した
こんにちは、 @p1ass です。
Twitter API の v2 が正式リリースされてから数ヶ月経ちました。
Twitter API v2 では様々な API が追加されていますが、中でも注目すべきは OAuth 2.0 対応だと思います。
今までは OAuth 1.0a しか対応しておらず、他の OAuth 2.0 対応の認可サーバーと比較して使いづらいと感じていました。 今回の対応によって、OAuth 2.0 の Authorization Code Flow ( RFC6749 Section4.1)を利用した認可に対応し、より便利に認可をシステムに組み込めるようになりました。
また、スコープを細かく制御できるようになったため、今までのように不用意に多くの権限を要求する必要がなくなりました！ 現在対応しているスコープは以下の通りで、非常に細かくスコープを制御できることが分かります。
- tweet.read
- tweet.write
- tweet.moderate.write
- users.read
- follows.read
- follows.write
- offline.access
- space.read
- mute.read
- mute.write
- like.read
- like.write
- list.read
- list.write
- block.read
- block.write
というわけで、せっかく OAuth 2.0 に対応したことなので、実際に Authorization Code Flow を試してみようと思います。
『ソフトウェアアーキテクチャの基礎』を読んだ
こんにちは、 @p1ass です。 タイトルの通り、『ソフトウェアアーキテクチャの基礎 エンジニアリングに基づく体系的アプローチ』を読みました。
本書はソフトウェアアーキテクチャに関する内容を網羅的にまとめたもので、アーキテクトのようなポジションを目指す人にとっての教科書的な存在です。 自分の今の興味関心にドンピシャの内容で、書籍の発売後にすぐ読み切ってしまいました。
この記事では、本書の感想を書こうと思います。 現在購入を検討している方の参考になれば幸いです。
大規模システムにおけるディレクトリ構成をRDBのカーディナリティを参考に考える
モノリシックなプロジェクトにおいて、トップレベルのディレクトリ構成が異なる 2 つのディレクトリ構成を考え、それらの違いは何で、どちらが優れているか？という問いについて考えた。そして、「複雑な概念をトップレベルのディレクトリ構成にした方が良いのでは？」という結論に落ち着いた話をする。
Gradle にしっかり入門する
1 章 はじめに
こんにちは、 @p1ass です。
最近、Gradle を使ったプロジェクトを 1 から構築することがありました。 以前から Gradle を使ったことはあったのですが、ほとんど雰囲気で触っていたため、いざ諸々をセットアップしようとすると戸惑ってしまうことが多々ありました。そのため、改めて Gradle について学んだほうが良かろうということになりました。
この記事では、改めて Gradle を学んだ際に自分のためにまとめたドキュメントを再編集して公開します。
2021年にブックマークした記事まとめ
こんにちは、@p1assです。
普段利用しているブックマークサービスである Pocket の API を使って、今年ブックマークした記事の一覧をまとめてみました。 大体 280 記事くらいあるので、目次をみつつ漁ってみてください。 バックエンドからインフラ、設計、フロントエンド、マネジメントまで幅広くあります。
なお、記事の一覧は下記のスクリプトを使って生成しました。 急いで作ったので拡張性はないです。 使いたい方は適当に手直しして使ってください。
2021年の振り返り
二項演算子のASTを参考にした動的なフィルターのデータ構造
この記事はDeNA 21新卒×22新卒内定者 Advent Calendar 2021の 1 日目の記事です。
こんにちは、@p1assです。
いよいよDeNA 21新卒×22新卒内定者 Advent Calendar 2021が始まります 🙌
今年は新卒と内定者によるこの Advent Calendar と DeNA のエンジニアが担当するDeNA Advent Calendar 2021の 2 種類があるので、どちらもぜひチェックしてください！
（執筆時点では新卒 Advent Calendar はまだ埋めてないですがこれから埋まっていくはず…!）
さて、ここからは本題に入っていきます。
世の中には何らかのコレクションから条件に一致するものをフィルターする処理がよくあります。 例えば、「ユーザ一覧の中から年齢が一定以上の人のみを表示する」などです。(こういった条件をこれ以降「フィルター条件」と呼びます。)
このようなフィルター条件は 1 つであれば簡単ですが、複数の条件が組み合わさると少しずつ複雑になっていきます。 また、これらの条件がプログラムの中に静的に埋め込まれるのではなく、エンドユーザーのリクエストによって動的に変化すると、より面倒になってきます。
今回はいくつかのフィルター条件を自由自在に組み合わせて新たな合成フィルター条件を作り出すためのデータ構造を紹介します。 デザインパターンを知っている人にとっては既知の構造ですが自由度を保ちつつ複雑なフィルター条件を実装できるので、参考になれば幸いです。