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 つであれば簡単ですが、複数の条件が組み合わさると少しずつ複雑になっていきます。 また、これらの条件がプログラムの中に静的に埋め込まれるのではなく、エンドユーザーのリクエストによって動的に変化すると、より面倒になってきます。
今回はいくつかのフィルター条件を自由自在に組み合わせて新たな合成フィルター条件を作り出すためのデータ構造を紹介します。 デザインパターンを知っている人にとっては既知の構造ですが自由度を保ちつつ複雑なフィルター条件を実装できるので、参考になれば幸いです。
ドキュメントの運用を考えてみたが正解が分からない
ドキュメント運用について考える機会があったので、そのとき考えてたことをダンプしてみる。 実際に運用しているわけではないので机上の空論だが、文字に起こしてみることで何か得られないかと思いやってみる。
EnumやUnionの列挙子が増えたときに起こりうる人為的なバグを撲滅したい
こんにちは、@p1ass です。
Enum や Union 型は、取りうる値を列挙する上で非常に便利な構文です。 曜日のようなものを全列挙したり、エラーコードのように本来 string 型として無限の集合だったものを有限の列挙としてアプリケーション側で扱ったりと、様々な用途で使われます。
これらの型は if や switch などの条件分岐やパターンマッチングと共に使われることが多いです。 しかし、これらの処理は列挙子を増えたときに意図しないバグを埋め込んでしまうことも多いです。 そこでこの記事では、Enum と switch を組み合わせたときに人為的に起こしうるバグを紹介しつつ、できるだけ静的にバグを発見するための方法を考えていきます。
先に話をまとめると、この記事に書いてあることは、
defaultはできるだけ使わないようにするswitch式やmatch式があるプログラミング言語は羨ましい- 上記の構文がない言語では静的解析に頼ろう
になります。
サンプルコードは TypeScript と Rust で書いていますが、これらの言語特有の話をしたいのではなく、一例として挙げています。