It Made My Day

Acutally, my whole life is just one big yak shaving exercise.

業務で役立ったもの厳選！とあるエンジニアのSlackを使った生産性向上事例

生産性向上

これはZOZO Advent Calendar 2023 5日目の記事です。Slack公式が出しているTips記事など以外で、職場で使っている活用方法を厳選して紹介します！ エンジニア向けの内容を含みます。

通知編

脆弱性関連のPRとIssueだけSlackに通知する

GitHubの通知機能をパブリックチャンネルで設定すると、通知が多くなるのでチームのコミュニケーション用チャンネルと分けている、という組織も多いと思います。そこで、私のチームでは、通知するものの種類とラベルを指定することで、脆弱性を検知したIssueやPRが作成されたときだけSlackに通知されるようにしています。vulnerabilityというラベルがついているPRもしくはIssueだけ通知する、という設定をすることで、dependabotなどで自動で付与されるラベルも検知してくれます。

Issueは解決したらその旨もSlackに投稿してくれます。

注意点としては、1つのチャンネルに通知できる条件として、ラベルは1リポジトリにつき1種類しか指定できません。 私のチームでは、脆弱性の通知のみ、PRのマージなどを通知するリリース絡みのチャンネルとは別に、チームの業務連絡用のチャンネルに通知されるようにしています。

祝日を考慮し、指定した曜日にSlackに投稿する輪番担当者お知らせBot

Slackのリマインダーはあまり柔軟性が高くなく、日本の祝日を考慮しないのでいまいち痒いところに手が届かないこともあります。 そこで、スプシのGASを使い、毎週設定した曜日の決められた時間に、チームを1人ずつ順番に指定してSlackにメンション付きのリマインド投稿をしてくれるBotを作成しました。

通知のイメージ。やっぱりBotはアイコンが可愛いのが一番大事ですよね！！！

元々は、朝会のファシリテーターを輪番にしたいという話から作ったBotですが、例えば週に1度のmtgのファシリと議事録担当者を輪番にしたいとか、そういう用途でも使用しています。 管理にはスプレッドシートを使っており、通知の条件をスプシにこんな感じ↓で書き込めば、GASが上から順番に担当者を選んで、指定した曜日の特定の時間に通知してくれるってわけです。

GASが「次回の当番」に記載されている人にメンションする通知を送り、「担当者」の列にある次の担当者を認識して次回の当番を更新してくれる仕組みです。

実際には、投稿チャンネル、アイコン、メッセージなども指定でき、1つのファイルで複数のBotを生成することもできるようにしています。

指定した日にSlackに投稿するBot

上記の輪番とは違い、シンプルに指定した日付に投稿するBotも作りました。 このBotは、日付に加えて月末月初を指定できるようにしています。 曜日指定の輪番通知は定例のmtgでしたが、こちらのBotの主なニーズは、月に一度のイベントや、月末の勤怠締めなどの定例作業のリマインダーです。

管理シートはこのように作っています。

メンションは指定してもしなくてもOK。日付に月末月初を書き込むと、毎月最初のor最終営業日に通知できます。

これがこんな感じで通知されます。

スプシのサンプルかGASのソースコードを公開しようかと思ったのですが、ちょっと準備が間に合わず、もしご興味ある方いらしたらTwitterでDMください。

作業の自動化編

ワークフローで定型的な内容の連絡を効率化

Slackのワークフロー機能は個人的にかなり使いまくっています。公式のチュートリアルはこちら。

所定の情報を記入して手続きをしないといけないなどの場合にワークフローでフォームに記入する、などの用途（公式ページの用例はこちらご参考）で使っている組織も多いんじゃないかなと思います。

そこまでかしこまった手続きの場合でなくても、例えば自分のチームへの依頼をするときは優先度を記入してほしいのでフォームに必須事項として追加しておく、とか、依頼に複数のメンション先が必要なので依頼者にワークフローに記入してもらうことでメンション先を気にしなくてよくなる、など絶妙にSlackコミュニケーションのペインを解消できることがあります。

特定のスタンプを押すと特定のチャンネルに投稿を転送してくれる

Slackリアク字チャンネラーを使うと、任意の投稿にスタンプを押すだけで、設定したチャンネルに対して他チャンネルから投稿を転送できます。 地味に投稿のURLをコピーして貼り付けて...とする手間が省けて 弊社では、「xxx共有」みたいなスタンプがたくさん存在し、結構多くのチームがこの機能を使っていそうです。

ユーザーグループに加入した人が自動的にチームに関連するチャンネルに入るようにする

オンボーディング資料に、「このチャンネルに入っておいてね」と教えるためのチャンネルリストを記載していませんか？ 意外にチャンネルが増減したり名前が変わったりして、メンテが面倒ですよね。

そんな時は、ユーザーグループの編集画面から、デフォルトチャンネルを設定しましょう。 グループメンションに新入メンバーを追加すると、自動で設定したチャンネルに参加させてくれます。

また、併せてそれぞれのチャンネルに説明を書くようにしておくと、突然加入させられても新入メンバーからそのチャンネルの用途が一目でわかるのでおすすめです。

その他

ワークフローで学びをメモして、チームに共有する

みなさん、日々の学びや気づきをどうやってチームに共有していますか？ そういう、ちりつもな何かを集めるツールとして、Slackのワークフローにメモを投稿すると、スプシに集約されるツールを作りました。

ワークフローを発動するとこんな感じでフォームが立ち上がり、これに入力するとスプレッドシートにその内容が蓄積されます。

Slackとスプレッドシートの連携方法の公式ドキュメントはこちら。私は上記のようにカテゴリを指定してもらい、スプシのデータが記入されるシートをマスターとして、スプシのquery関数を使用してカテゴリごとに自動で専用のシートにデータが貯まるようにしています。

チーム内に限らず、何かのイベントの意見を集めるなどの用途にも使えそうだと思っています (このGoogleフォームから感想を投稿してください！みたいなやつをSlackワークフローでやるイメージ)。

普段の情報整理に便利なTips

サイドバーを整理する

サイドバーの上部のアイテムリストをカスタマイズしてしたり、カスタムセクションで複数のチャンネルをまとめています。 設定の仕方は公式サイトをご覧ください。

チャンネルが多くなりがちなので、整理は必須ですね。このセクションの設定まで他人と共有できるようになれば新しく入るメンバーにも提供できて楽なのにな〜と思うことがあります。

予約送信

「送信」ボタンの隣にある「下矢印」ボタンをクリックし、日時を選択して、「送信日時を設定する」をクリック。

チャンネルによく使うURLをブックマーク

よく使うURLをブックマークしておき、個人でブラウザのブックマークを編集したり、探す新しく人が入った時に教える手間を省くことができます。

この画像はサンプル用に作ったのでとてもリンクが少ないですが、実際には結構入っていて、日々いかに色んなサイトを見に行っていたのかと考えると、そういうのを思い出す手間すら省いていきたいなという気持ちになります。

最後までご覧いただきありがとうございました！ みなさま良いお年を〜🎍

読書メモ 2023年6〜10月

読書メモ

大学院やら転職やらで忙しさにかまけてブログをサボっていた。この半年ほどは、転職を機に自分のエンジニアとしてのキャリアや中長期的な目標について考えるようになり、STAFF ENGINEERなど技術書以外にも色々読んでみた。しかし、キャリアや自己啓発系の本は他人におすすめできるかまだわからないので一旦ここでは紹介しないでおく。

Go言語 100Tips ありがちなミスを把握し、実装を最適化する

Goの仕様書やら公式ブログやらコードやらを色々読み漁って勉強してたことが全部書いてあって、本当に最高だったし早く読んでおきたかった...。翻訳も読みやすかったし、説明の仕方もとても理解しやすくて良い本だった。

システム設計の面接試験

有名なアルゴリズムや設計事例の概要を説明しており、私が学位を持っていないのでどの程度有益かはわからないものの、もしかしたら大学などで既にCSを学んだ人にはやや得るものが少ないかもしれない。この本の説明だけで得た知識ではなかなか技術面接を突破するのは難しいかもしれないと感じたが、よく見るテーマを集約して外部記事へのインデックスを貼ってくれているだけでも十分良い本だと思った。個人的には、行間からも学べる文章でよく外資系の面接対策で使用されるウェブのリソースよりも勉強になったし、注釈に貼られているビッグテック企業のテックブログなどのリンクを辿るのも楽しく、知識を定着させるため理解が浅いところや詳細を調べながら読めてとても良かった。

SAML入門

趣味で読んだが、ググったりしてもふわっとした理解しかしていなかったので、体系的に理解できる本があるのはとてもありがたいと思った。SSOログインを使ったことがある人ならイメージしやすいだろう。

最高の脳で働く方法

うまくいくときとそうでない時に自分の脳で何が起こっているのか、それをどうコントロールすれば良いかを、脳の機能をベースに順を追って説明している本。例えば仕事中に散歩に行くと良いアイデアが思い浮かぶとか、職場でのフィードバックにストレスを感じるとか、そういう現象がなぜ起こっているのかを知ることで、人間の社会的活動において脳が発する信号を意図的にコントロールするにはどうしたら良いかを、ケーススタディを解説する形で提案している。多少都市伝説的に聞こえなくもない説明もあるし、脳のこの部位がどうみたいな説明は読んでいると退屈になることもあるかもしれないが、読み進めると他人や自分の思考や感情を手探りで理解しようとしていた時期に考えていたことと近い内容も多く、知っておいて損はない内容だっと思う。特に面白かったのが、自分の脳の活動を客観視するツールとしてマインドフルネスが有効という話と、生存欲求を感じる脳の部位は社会的欲求にも同様に反応するという話だった。後者については、社会における確実性、自律性（自分で決めた、という感覚）、（他者との）つながり、公平性の4つは人間の一次的欲求と同様に強い情動を引き起こすとしており、社会人としてのプライドで片づけるには複雑すぎる人間関係の微妙な軋轢を思い返し納得感があった。

Go：型アサーションでインターフェースへの準拠を確認する

Go

最近久しぶりにこういう↓イディオムを見かけ、色々文脈があるなと感じたのでちゃんと調べてみた。

type A struct {}

var _ SampleType = (*A)(nil)

uber-goのスタイルガイドの「Verify Interface Compliance」よりソースコードを抜粋し、説明をまとめる。

github.com

type Handler struct {
  // ...
}

var _ http.Handler = (*Handler)(nil)  // ←これ

func (h *Handler) ServeHTTP(
  w http.ResponseWriter,
  r *http.Request,
) {
  // ...
}

*Handler が http.Handler インターフェースと一致しなくなると、var _ http.Handler = (*Handler)(nil) はコンパイルに失敗する。

代入の右側 (*Handler)(nil) は、アサートされた型のゼロ値。これは、ポインター型 (*Handler など)、スライス、マップの場合は nil であり、構造体型の場合は空の構造体 (例：var _ http.Handler = LogHandler{})。そのため、メモリはアロケートされない。

この記述を追加することを議論したuber-goのイシューによると、このイディオムは、Javaの implements , Rustの impl ... for に相当する。APIの契約の一部として特定のインターフェースを満たす必要がある公開型がある場合、型が予期されるインターフェイスのセットを実装していることをアサートし、メソッド シグネチャの変更による破損を防ぐ。 Newから始まる名前を持つコンストラクタがインターフェースを返す場合はこの1行は必要ないが、特に外部へインターフェースを公開するパッケージではインターフェースの実装を変更することでユーザーのコードを壊さないために、構造体を返すことが良しとされていることから、インターフェースへの準拠をこの1行で担保する。また、満たすべき条件を明示し、ドキュメントの追加形式として機能させることでコードが読みやすくなるとのこと。

まとめると、この var _ SampleType = (*A)(nil) イディオムは具象型がインターフェースを満たしていることをコンパイル時に保証するためのもの。Goのインターフェースは暗黙に満たされるものであるため、インターフェースを実装する側がインターフェースへの準拠を保証するために使う、ということだと思っている。
アプリケーション開発時のこのコードのニーズについてmattnさんが説明してくれていた。

ヘキサゴナルアーキテクチャとNetflix社での採用事例

アーキテクチャ

ヘキサゴナルアーキテクチャについて理解を深めるために調べたので内容をメモする。

ヘキサゴナルアーキテクチャとは

概要

キサゴナルアーキテクチャの提唱者であるAlistair Cockburn氏の記事（2005年のものと思われる）が和訳されていたので、このセクションでは主にこの和訳記事を要約している。

ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳) | blog.tai2.net

ビジネスロジックがユーザーインターフェイスコードに侵入するのを防ぐためにPorts and Adaptersパターンを採用するアーキテクチャ。MVCやレイヤードアーキテクチャが持つ課題を解決するために生まれ、クリーンアーキテクチャの基礎となった。

DBや外部サービスなどの外部のものからアプリケーションのコアロジックを分離することで、テスト、保守、拡張が容易になるというアイデア。レイヤを増やすだけだとビジネスロジックがレイヤを超えて存在しないという取り決めをしても違反がないことを保証できない。アプリケーションをViewなどの外部と切り離し、提供する機能すべてをAPIにすることで、自動化された回帰テストを用いてビジネスロジックがプレゼンテーションレイヤーから隔離されていることを確認できる。そのAPIを外部デバイスが必要とするインターフェースに変えるのがadapterで、adapterとやりとりしてイベントを内部的に処理するための窓口（インターフェース）がport。

外部とはViewやコマンドなどユーザーが使用するもの、もしくはデータストレージを指すことが多く、入力と出力という一見反対側とも思えるそれらを同じadapter層で扱うのは、ユーザーサイドであれサーバーサイドであれ課題の本質は同じだから。その課題とは、ビジネスロジックと外部エンティティーとのやりとりが絡み合っているという、設計とプログラミングにおける誤り。

要はアプリケーションの内側にあるコアロジックを、外側に漏れないようにしたいというのが最大の関心ごと。

アーキテクチャを構成する概念

ビジネス ロジックを定義する主要な概念は、エンティティ、リポジトリ、およびインタラクターの3つ。コアが作用するものは全てアクターと呼ばれる。

  • エンティティ：ドメイン オブジェクト。データがどこに保存されているかとは関係がない。
  • リポジトリ：エンティティを取得したり、エンティティを作成および変更したりするためのインターフェイス。データソースと通信し、単数または複数のエンティティを返すために使用されるメソッドを保持する（例：UserRepository）。
  • インタラクター：ドメインアクションを調整して実行するクラス。ビジネス ルールと検証ロジックの実装であり、サービス オブジェクトやユース ケース オブジェクトなどが含まれる。

ビジネスロジックの外側には、データソースとトランスポート層がある。両方Adapterだが、データソースはアプリケーションが利用するデータストレージへのアダプター（セカンダリアダプター）で、リポジトリ上で定義されたメソッドを実装し、データのフェッチとプッシュの実装を持つ。トランスポート層はユーザー向け（プライマリアダプター）なので、インタラクターを用いてビジネスロジックを実行する。 プライマリとセカンダリというのは、サービスを駆動する側か呼び出される側かということらしい。

レイヤの依存関係は全て内側を指す。六角形はポートの数を視覚的に表すという意味もあるようだが、分け方に明確な基準はなく、割と直感的で2~4くらいの少なさがいいんじゃないという感じらしい。

ヘキサゴナルアーキテクチャの依存関係グラフ

出所：Netflixのテックブログ

ちなみにNetflixでは、インタラクター、データソース、統合仕様（e2e）をテストしたそう。統合仕様によるテストは、ドメインアクションごとに1つずつ成功、失敗シナリオを行った。リポジトリはインターフェースなのでテストなし、エンティティはオブジェクトなのでメソッドがない場合はテストはしない。以上の内容について、単一プロセスで100秒で3,000の仕様のテストを実行した。依存しているサービスについては、契約テストを行うよう改善の余地があったとのこと。

Netflix社のヘキサゴナルアーキテクチャ採用事例

このセクションは、2020年3月のNetflixのテックブログ記事を著者の解釈に基づいてまとめており、翻訳ではない。

netflixtechblog.com

当時同社は、ビジネスの複数のドメインにまたがる新しいアプリの開発を行う際に、gRPC、JSON API、GraphQL などのさまざまなプロトコルを実装する多くのサービスに必要なデータが分散されており、それらを統合して使用する必要があった。 モノリスで開発を開始したが、時間の経過とともにアプリケーションが専門的になってくると、（パフォーマンスの問題ではなく）ドメインを分解するためにサービスを分解することにした。モノリスのアプリケーションのデータソースを、あるタイミングでマイクロサービスに切り替えるため、モノリスのアプリケーションをヘキサゴナルアーキテクチャで開発した、という状況のよう。

ヘキサゴナルアーキテクチャを採用してマイクロサービス化に備えることで大きなメリットがあった。
データは既に切り替え元と切り替え先両方のDBで同期されている状態にしておき、データソースの切り替えは1行のソースコードを変更するだけでよかった。結果として、データソースの切り替えは2時間以内で終わったそう。
また、外部との契約を先に決め、詳細な実装をカプセル化できることで、契約に基づいて外部サービスの開発の要求を損なうことなく内部実装を後から行うことができた。結果として、データをアプリケーション内に保存するかどうか、どのタイプのデータストアを使用するかなど、アーキテクチャを含む重要な意思決定を遅延させることができたとのこと。

まとめると、ヘキサゴナルアーキテクチャには下記のメリットがあった。

  • ビジネスロジックに影響を与えずにデータソースを交換できる
  • プロトコルに依存せずにビジネスロジックの検証をテストできる
  • 適切な抽象化によりソースコードを大きく変更することなくデータソースを切り替えることが可能。結果としてロールバックが容易など、リリースのリスクが軽減される
  • 内部実装のカプセル化と内部実装に関わる意思決定の遅延化。外部との契約としてのインターフェースを先に決定し、内部実装を後から具体化させることができる

最後の点については、プロジェクトのパラドックスを引き起こす、情報に基づかない意思決定により「アーキテクチャに自分たちを閉じ込めるべきではない」としている。プロジェクトのパラドックスとは、最大の意思決定を情報が最も少ないプロジェクト初期に行うことだそう（下記ツイート参考）。

ディレクトリ構成

プロジェクト構成はいくつかの記事で見かけたが下記のような感じが最も納得感がある気がした。

.
├── bin
├── cmd
│   └── http
├── docs
└── internal
    ├── adapter
    │   ├── cache
    │   │   └── redis
    │   ├── handler
    │   │   └── http
    │   ├── repository
    │   │   └── postgres
    │   │       └── migrations
    │   └── token
    │       └── paseto
    └── core
        ├── domain
        ├── port
        ├── service
        └── util

あとがき：クリーンアーキテクチャでいいのでは？

以上ヘキサゴナルアーキテクチャについて調べてみたが、私はクリーンアーキテクチャのレイヤを少し減らした感じで実装することが多かったので、多分時代的な背景が原因で、別にヘキサゴナルじゃなくてもクリーンアーキテクチャの亜種でいいじゃんという気持ちはやっぱり残った。大規模なモジュラモノリスとかを開発しているとよりメリットがわかるのかも？あまり想像できないが。MVCよりは全然境界分けやすそうというのは思ったし、プラガブルなアプリを使ってドメインを守るという強いコンセプトがあることは理解できた。デベロッパーエバンジェリストの成瀬氏によると、クリーンアーキテクチャはヘキサゴナルアーキテクチャの外側の具体的な実装を推し進めているとのことで、もしかしたらそもそもどちらがどう良いかという議論はそもそも不毛で、クリーンアーキテクチャほど詳細に外側の責務を分けたいわけじゃないなら、ヘキサゴナルくらいが内側と外側を明確に分離できて適任ということなのかもしれない。Netflixのテックブログ記事が2020年とクリーンアーキテクチャがそれなりに浸透した後のものであることを考えると、Netflixがなぜヘキサゴナルアーキテクチャを選択したのかは気になる。
また、DDDの文脈で語られることが多いが、別にドメインモデリングの話も一切出てこなかったし、ドメインロジックを守るという思想以外にヘキサゴナルが特段DDDに向いてそうな要素を持っているようには思えなかった。CodeZineの2018年の記事を読んだ感じ、時代的背景で当時最も合っていたと思われていたということなのかもしれない。開発者に対して「ドメインにフォーカスしよう」という明確なメッセージができることにより、たくさんレイヤを分けるアーキテクチャを採用することと比較し、外側とコアドメインというシンプルで強力なメンタルモデルをチームで共通化できることでコードを綺麗に保ちやすいという効果はあるかもしれない。

Next.jsに入門した＆最近のReact開発について調べたのでメモ

フロントエンド

フロントはかなり経験が薄いが、業務で触るため必要に迫られて勉強した。実務上必要となる理解を優先したため、JavaScriptやReactのAPIの仕様など無視している点もあるかもしれない。 前提として、私が以前にReactを触ったのは4年ほど前で、Hooksも使用していなかったし、Reduxがよく使われていた気がする (うろ覚え)。つまりほぼ素人。

ざっくりNext.js is 何

ReactはインタラクティブなUIを提供するJavaScriptのライブラリ。Next.jsはReactを使ってアプリケーションを開発するためのフレームワーク。Next.jsはReactを使ってUIを構築し、その他のアプリ構築とパフォーマンス最適化をいい感じにできるような機能をビルトインで備えている。例えば、ReactではReact Routerを使ってルーティングをする必要があったが (どうもこれがめんどいとの噂)、Next.jsではディレクトリ構造で自動的に解決してくれたりする。 また、TypeScriptやESLintのインテグレーションとか、DXもいい感じにしてくれる。 どうでもいいけどコンパイラはRustで書かれてるらしい。

以下サバイバルTypeScriptより抜粋

Next.jsはルーティング時のプリフェッチや画像の最適化などのパフォーマンス最適化をフレームワーク内で内包しており、ゼロコンフィグで簡単にパフォーマンスの高いアプリケーションを構築することができます。ページ単位のサーバーサイドレンダリング(SSR)や静的サイト生成(SSG)の機能も提供しており、用途に合わせて柔軟にアーキテクチャを選択できるのも特徴

Reactはページ数が少なく小規模なウェブサイト開発に向いていて、ページ数が多いと読み込み速度が遅くなる。レンダリングするとJavaScriptが全部読み込まれるから。らしい。 一方でNextはReactをベースにしたHTMLテンプレート派のフレームワークで、最初にHTMLがレンダリングされて、必要なところだけをJSが読み込むため読み込み速度が速い。Reactはクライアントレンダリング(CSR, SPA)。Nextはサーバーサイドレンダリング (SSG, SSR) とクライアントレンダリングをコンポーネントごとに選択できる。だからReactでSSRを行いたい人の強い味方として存在しているそうだ。

Next.js入門

現時点では英語しかないけど、やっぱりNext.jsのチュートリアルをやってドキュメントを読むしかなさそう。Udemyにチュートリアルとほぼ同じ内容の日本語の講座があったので、興味がある方はそちらを聞いても良いかもしれない。 チュートリの最初はReactのプリミティブな感じの実装から始まるので、私は興味があるところだけ読んであとは実践のスタイルで行った。細かく最適化しないといけない業務でないのなら、機能だけ攫うだけであれば大して読むのに時間はかからないだろう(いつかちゃんと読まないとな...)。

Nextフレームワークとしての機能

ルーティングをWebページ、API共にいい感じにしてくれたり、ホットリロード機能を搭載(Fast Refresh)したりしている。 ReactではReact routerっていうライブラリ使ってルーティングしたり、webpack dev serverでホットリロードしたりが面倒だった様子。

JSXで使える組み込みコンポーネント

Linkタグを使えばクライアントサイドだけでページ遷移できる。SEO対策を気にする場合はaタグを中にネストできる。 Imageタグは画像の最適化のやり方の設定ができる。使ってみたが、それが逆にややハマった。

参考資料：Next.js API Reference

最近のReactによる開発についてキャッチアップ

Hooks

React16.8で追加された機能。最近はとにかくhooks使いまくってるっぽい。

state などの React の機能を、クラスを書かずに (関数コンポーネントを使って) 使えるようになる。いろんな種類があって、非同期通信の状態 (要はPromiseの結果) とか、コンポーネントのライフサイクルとか、それぞれ指定されたタイミングでトリガーされる。 クラスコンポーネントstateの初期値セットとかstateを更新する関数とかを、こんな感じ↓でシュッと書ける。

//const [状態変数, 状態を変更するための関数] = useState(状態の初期値);
const [count, setCount] = useState(initialState)

↑このコードの解説

  • count => countという名前のstateの現在の値
  • setCount => countを更新する関数
  • initialState => stateの初期値

よく使われるHooks

  • useState
  • useEffect
    • DOMのライフサイクルによって発火してくれるくん。つまりcomponentDidMountとかそういうの書かなくていい
    • 第2引数に取った変数が更新された後に動作する
    • 関数をreturnすると、componentWillMountとcomponentDidUpdateのタイミングで実行してくれる
  • useContext
  • useReducer
    • useContextと組み合わせてReduxパターンのReducerみたいなものを作れるので、Reduxは今後不要と言われているらしい
  • useCallback
    • メモ化でパフォーマンス向上するくん
  • カスタムフック (fetcher指定してフックを自作できる)
  • 他にも色々あるみたい

参考資料：

SWR

SWR は、Next.js を作っているVercel 社が開発しているデータフェッチのための React Hooks ライブラリ。"SWR"と言う名前は、 stale-while-revalidate の頭文字をとって名付けられている。SSR / SSG に対応しており、非同期処理を簡単に扱えるようになる。ただ、これもReact18で追加された新機能のSuspenseを使うと不要になりそうな雰囲気らしい。

こんな感じ↓でカスタムフックを使う。

const { data, error } = useSWR("/api/user", fetcher);

↑のfetcherはfetch APIを使っているが、fetcherはPromiseを返す関数ならなんでも使える。依存フェッチという複数のフェッチを連携させる処理をシュッと書ける。

dataには fetcher が resolve した値(通信結果、Promise.resolve() した値)、もしくはundefined (ロード中の時) が入る。isLoading的なものはない。 個人的な話だが、APIのレスポンスでfalsyな値が返ってきた時にif (!data) とかでハンドルしててずっとロード中の処理になって最初ちょっとハマった。

また、useSWRから mutate 関数を取得し、そのAPIを使用しているコンポーネントに再検証する旨を伝えることもできる。 例えば、モーダルで何かデータを操作する処理をして、処理が終わったらモーダルの裏側にある一覧画面を更新するみたいな場面に使えそう。

参考資料：

MUI(Material UI)

いい感じにスタイルされたReact componentを提供してくれる。コンポーネントにはそれぞれAPIが生えてて、それをタグからいじることでカスタマイズできる。 SVGのアイコンとかもある。 参考資料：MUI: The React component library you always wanted

ぱっと見ややこしいが、LinkタグとかImageタグとか、Next.jsが提供している組み込みコンポーネントを使うこともある。

storybook

Reactコンポーネントをプレビューできるサーバーを建てられる。 2022年現在、フロントエンド開発において必要不可欠らしい。公式ドキュメントは英語のみ。チュートリアル(日本語もあるけど更新はちょっと遅れてそう) やってもいいかもだけど、シュッとサーバーを立ち上げて動かしてみると理解できる。

UIのカタログを作るツールとよく言われるが、ﾅﾆﾓﾜｶﾗﾅｲ状態では一瞬どういうことやねんと思ってしまった。たとえば家の内装とかでも壁紙何種類か比べてみるみたいなシミュレーションをやるイメージで、コンポーネントをGUIでシュッといじって試せる＆コンポーネントの現状を管理できることからそう例えられるようだ。

コンポーネントディレクトリにストーリーと呼ばれる、Reactの状態をもたない関数コンポーネントのようなものを定義する(参考)。このストーリーをGUIで確認できることにより、ビジュアルテストの役割を果たす。

参考資料：

テスト

これからがんばる...。ぱっと見RSpecっぽい書き方してた。

余談

有名な同人誌↓。重い腰を上げてやっと読んだ。 Next.jsを使う場合は直接的に必要ない情報が多いが、実務的な観点で役立つ情報が多く、かつとてもわかりやすくて良かった。Reactがいかに進化してきたかもよくわかる。

oukayuka.booth.pm

最近読んだこの記事も面白かった。

eh-career.com

React界隈で聞いたことある単語を調べてると既に時代遅れになってることも多くて、進化の速さを実感した。 最初のうちは画面上のコンポーネントの状態と表示するデータの状態を同様に扱うことにどうしても抵抗があったが、最近やっとReactの世界観に少し慣れてきた気がする。

"OAuth 2 in Action" Sample Code in Go

Motivation

As I am engaged in developing authorization server recently, I read "OAuth 2 in action" to acquire the prerequisite knowledge. The sample codes were written in JavaScript & Express, but since I've never seen them translated int Go, I rewrote it by myself for my study.

OAuth 2 in Action

OAuth 2 in Action

Amazon

I first read the summary articles in order to understand OAuth without spending much time, but immediately it turned out to be a wrong way. The book "OAuth 2 in Action" takes much more time to read, but I felt it was perfect for the first study because it comprehensively explains from concept to implementation, security issues, and recent trends. OAuth is a mechanism that requires developers to implement complex details, and knowing the superficial flow is not enough to implement authorization servers.

MVP implementation of authorization code flow according to OAuth2.0, in Go

You can find the sample codes in my Github repository.

github.com

The original source code used Express as the framework and libraries like lodash. As I wrote in the README of the Github repository, I also adopted a popular library.

Te current progress is the part of the authorization code flow assuming a Web application only. In other words, up to Chapter 3. However, since it is basically not recommended to adopt patterns other than the authentication code flow, I decided to disclose it now.

The contents I want to implement in the future are as follows:

  • Implementation when using JWT token
    • Token Revocation
  • Dynamic client registration
  • Authentication using OAuth
  • Implementation when using PoP token

Hope my attempt will be helpful to someone.

読書メモ 2022年1~3月

詳しくない技術を触りに行った3ヶ月だった。来期は深める勉強やりたい（できるのか？）。

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

Amazon

業務で認可基盤を開発することになったので読んだ。認証について概要を掴みたくて色々ググった時期もあったが、そんなことをする必要は一切なかったなと思うほどわかりやすいし、基礎となる理論からテクニカルな仕様まで、ソースコードも提示しながら丁寧に説明している。

手前味噌だが、JavaScript以外の言語で書かれたサンプルコードを探してもなかったので、Goで書き直してみた。

「OAuth徹底入門」のサンプルコードをGoで書いてみた - It Made My Day

［Web開発者のための］大規模サービス技術入門 ―データ構造，メモリ，OS，DB，サーバ/インフラ

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)

Amazon

はてなのブログ系サービスがスケールする際に困ったポイントと、その解決策の選択肢や周辺技術の概要を説明した本。同社がインターン生に説明していた内容を書き起こしたものらしく、非常にわかりやすくテンポよく読める。

2010年発行のため、クラウドベンダーのフルマネージドなサービスを使った開発が非常に身近なものとなった現在においては少し古く感じる内容ではある。が、システムデザインの勉強をしていた際 (こういうのとか) には理屈だけで理解していた実務のイメージがより具体的に理解でき、個人的にはとても楽しめた。

[試して理解］Linuxのしくみ ～実験と図解で学ぶOSとハードウェアの基礎知識

［試して理解］Linuxのしくみ ～実験と図解で学ぶOSとハードウェアの基礎知識

［試して理解］Linuxのしくみ ～実験と図解で学ぶOSとハードウェアの基礎知識

Amazon

4月からRuss CoxのMemory Modelsについての記事を読むことになったので、事前準備も兼ねて趣味で読んだ。コンテナの仕組みを理解したいならまずこれ、ともよく聞くやつ。

断片的な知識しかなかったところを実際にプログラムを動かして確認しながら理解を深めることができてとても良い本だった。低レイヤが垣間見える話はやっぱり楽しい。 個人的にはCの書き方にもちょっと慣れることができて良かった。

初めてのGraphQL ――Webサービスを作って学ぶ新世代API

www.oreilly.co.jp

なんとなく触ったことはあった程度だったので、ちゃんと入門してみた。RESTと違う世界観で仕様の変化に強そうと思った (似たようなエンドポイントの量産とか、バージョン管理の煩雑さがかなり軽減できそう) し、ツールも充実してそうだった。ネットワークで重くなりすぎるリスクへの対処とかページングとか、Pub/Subとかキャッシュとかもシュッと実装できて至れり尽くせりみたい。

全く調べてないけど、N＋1とかそういう、クエリ流してみるとあれってなる事象もありそうだし、やっぱりGraphQLのメンテはサーバーサイド側でやるんだろうか。現場で運用するとRESTとは違うハマりポイントがありそう。知らんけど。

この本では他のスタイルとの比較はなかったが、APIのアーキテクチャスタイルの比較にはこういう意見があるようだ。