Webフロントエンドハイパフォーマンスチューニングを読んで

はじめに

2020/09/24に買ったが少しずつ読んでやっと読み終わったので感想を書いておこうかと思います。
ただ書籍第2版発売が2018/04/20で発売から2年ほど時が経っており、またWebフロントエンドの進化スピードは速いため、情報が古いものもあるかもしれません。

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

ブラウザのレンダリングの仕組みが分かってよかった

まずこれを読んで良かったと思ったのはWebページが表示されるまでにブラウザで何が行われているのかが書かれていた点です。
第二章がまさにブラウザのレンダリングの仕組みを解説しており、この章を読むだけでも買ってよかったと思いました。
この書籍ではWebページを表示するまでのフェーズを大まかにLoading→Scripting→Rendering→Paintingの4つで紹介しています。
このフェーズの流れと各フェーズで行われることを掴んでおくだけでも今後フロントエンド開発をする上でも役立つと思いました。

ちなみに各フェーズで何をするかさらっと書くと以下の通りです。

  • Loading: HTML, CSS等のリソース読み込み、パースしてDOMツリー、CSSOMツリーの構築
  • Scripting: JSの実行
  • Rendering: スタイルの計算（CSSOMツリーからDOMツリーを総当りして適用）、レイアウト（DOM要素の具体的な座標位置、大きさなどの算出）
  • Painting: レイアウトで算出したものを実際に描画する

各フェーズでのチューニングテクニックが解説されててよかった

上記それぞれのフェーズでどうしたらパフォーマンスが改善できるか、そのテクニックが解説されていたのもよかったです。
特にLoadingでのチューニングテクニックはHTMLやCSS, JS以外のネットワークが絡む部分で割とフロントエンドエンジニアが意識から外れやすい部分かなと思いますが、ここもしっかり解説されていてよかったです。
例えばLoadingのチューニングの一例としてブラウザキャッシュを解説していましたが、これはWebサーバ側の設定を見直す良い機会になりました。
普段NginxをWebサーバとして使うことが多いのですが、これを読んだ後に調べたところNginxはETagキャッシュをデフォルト有効にしているということを知りました。

一つ思ったのはScriptingのチューニングテクニックで紹介されていたコードがaddEventListenerを使ったJSで書かれているものが多かったですが、僕は普段AngularのようなWebフレームワークを用いて開発を行うためフレームワークに用意されたイベントバインディングを使って書くことが主です。
その点は今回紹介されたチューニングテクニックの適用が難しいものもあるのかなと感じました。

Chrome DevToolsによる計測・解析を紹介しているのがよかった

パフォーマンスチューニングするにもまずは計測が大事です。この書籍ではその点パフォーマンス計測・解析についても紹介していたのはよかったです。（発売が2年ほど前のためもしかするとChromeのアップデートにより情報が古くなっている可能性はあります。）
そして割と色々なメトリクスが取れることを知れました。この辺は実際にWebページを読みながら実勢したいと思います。

最後に

まとめると買ってよかったでした。

「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んで

はじめに

約1年ほど前に書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を買ってずっと読んでいなかったのですが、最近アーキテクチャや設計周りの関心が強くなってきてようやく読む気になったので読みました。 所々読むのに飽きてきて読んでない章があったりしますが、感想を記しておこうと思います。

Amazon CAPTCHA

感想

本書ではソースコードレベルでの設計原則、コンポーネントレベルでの設計原則を解説してその後それらの設計原則をもとにアーキテクチャレベルの設計原則やプラクティスが語られていました。

その中で自分が感じたことは結局ソースコードレベルでもコンポーネントレベルでもアーキテクチャレベルでも高凝集と疎結合が大事ということです。ほとんどの設計話は結局この２つの要素にたどり着くのではないかと思います。

例えばSOLID。分解すると

  • SRP: 単一責任の原則
    • モジュールを変更する理由を一つにするように高凝集にする
  • OCP: オープン・クローズドの原則
    • 拡張については開くように疎結合にし、修正については閉じるように高凝集にする
  • LSP: リスコフの置換原則
    • 交換可能となるよう実装には依存しないように疎結合にする
  • ISP: インターフェース分離の原則
    • 使用しない処理に依存しないようにインターフェースを分離し高凝集、疎結合にする
  • DIP: 依存関係逆転の原則
    • 方針が実装詳細に依存しないように疎結合にする

というように凝集度、結合度の話に行き着くと思います。

他にもコンポーネントレベルでの設計原則として以下の6つの設計原則の紹介がありましたが、これも高凝集、疎結合の話に行き着くと思います。というかこの書籍ではそれぞれの原則を凝集度・結合度にカテゴライズして紹介していました。

  • 凝集度に関する原則

    • REP: 再利用・リリース等価の原則
      • 再利用の単位とリリースの単位が等価になるように高凝集にする
    • CCP: 閉鎖性共通の原則
      • 変更の理由がコンポーネントごとに同じになるように高凝集にする（SRPに近い）
    • CRP: 全再利用の原則
      • 実際に使わないものに依存しないようにするために、一緒に用いられるものはまとめて高凝集にする（ISPに近い）

  • 結合度に関する原則

    • ADP: 非循環依存関係の原則
    • SDP: 安定依存の原則
      • 安定度の高い方に依存させ、変更しやすいモジュールが依存されないように疎結合にする
    • SAP: 安定度・抽象度等価の原則
      • 安定度の高いコンポーネントは抽象度も高くする。すなわちSDPと組み合わせると抽象度の高い方に依存させて疎結合にする（DIPに近い）

このように設計の根本には高凝集・疎結合が存在していて、これらの要素を満たすように設計することが大事だなと思いました。

また、この書籍を読んでいく中で心に残った考え方として「優れたアーキテクトは方針に関係なく詳細を決める」というものがありました。この考え方は非常にDIPに近いと感じました。DIPに近いということは結合度の話に帰着させることができると思います。プログラマであろうとアーキテクトであろうと根本にある考え方は一緒なんだと思います。

さいごに

ということでこの書籍の感想を書きました。個人的にはソースコードレベル、コンポーネントレベルの設計原則を知れただけでもこの本を買って良かったなと思います。

次はこの書籍を読んで2年ほど前に購入して読んでいなかったIDDD本も読みたくなってきたので読もうと思います。

Twitterでまとめてた感想・あらすじ

Spring Fest 2019参加レポート

はじめに

2019/12/18に行われたSpring Fest 2019に参加してきました。
自分は今年で2回目の参加となります。
少し時間が経ってしまいましたが、自分が聞いた講演内容や感想、気になったことなどをまとめました。

イベント内容

こちらのイベントになります。今年は御茶ノ水ソラシティという会場で行われました。
Home | Spring Fest ’19

聴講したセッション

  • 基調講演
  • Spring Boot アプリの運用が楽になる？ Pivotal と Microsoft が共同開発した専用 PaaS「AzureSpring Cloud」のご紹介 !!
  • ローコード開発プラットフォームと、ドメイン駆動設計と、Springの関係
  • 徹底解剖Spring MVCアーキテクチャー -DispatcherServletの中身を覗いてきました
  • システム間連携を担うSpring Integrationのエンタープライズ開発での活用
  • Spring と GraalVM Native Image - 2019/12
  • RSocket徹底入門 ~Spring 5.2の目玉機能であるRSocket対応とは~
  • Spring Social でソーシャルログインを実装する

基調講演

www.slideshare.net

Stephaneさんと槙さんによる発表でした。
Stephaneさんからは主にSpring Boot 2.2や2.3で入る新機能や改善された機能のお話でした。

  • Spring Boot 2.2
    • RSocketサポート
    • Health Indicator Group
      • Spring Boot ActuatorのHealth Indicatorをグループ化できる
    • Immutable Configuration Properties
      • @ConfigurationPropertiesをfinal(イミュータブル)なフィールドにインジェクションできる
    • JUnit5がデフォルトに
    • Performanceの改善
      • 起動時間の短縮、遅延初期化など
  • Spring Boot 2.3
    • JDK17準備
    • GraalVM Native Image対応
    • RSocket, Coroutine改善
    • リリース周期変更

地味にありがたい改善や新機能が入ってきたという印象でした。
個人的には@ConfigurationPropertiesがイミュータブルにできるのはKotlinなどで活きてくるので良いなと感じました。

槙さんからは以下のお話がありました。

  • SpringのGraalVM Native Imageのサポート
    • Spring 5.3からout of the boxでNative Imageをサポートする
  • Spring Cloud系ライブラリのアップデート
    • Spring Cloud Netflixがメンテナンスモードになる
  • Cloud Native Buildpack
    • PivotalとHerokuが共同開発するプロジェクト
    • ソースコードからOCIイメージを生成する(Dockerfileを書かなくていい)

GraalVMは最近本当によく聞きますね。ずっと触ってみたいと思っているのですが触れていない。。SpringでもNative Image化できるようになると色々な場面でSpringを選択する機会がより増えてくるのではないでしょうか。
Cloud Native BuildpackによってDockerfileを書かなくていい分、気にするレイヤーがよりPaaSに近づいている印象です。

Spring Boot アプリの運用が楽になる？ Pivotal と Microsoft が共同開発した専用

yoshio3.com

PaaS「Azure Spring Cloud」のご紹介 !! マイクロソフト寺田さんによるお話。この辺のお話をされていました。

  • AzureにおけるSpringのサポート
  • Azure DevOpsのマネージドサービスの紹介
  • Azure Spring Cloudの紹介
  • Azure Spring Cloudを使ったデモ
    • Github Actionsを用いてCI/CDをデモ動画で紹介

中でも主に紹介していたのは発表タイトルにもあるAzure Spring Cloudについてです。

Azure Spring Cloud

  • Azure上でSpringを簡単にデプロイ・稼働させることのできるPaaSインフラ
  • 現在はPreview版
  • 基盤はKubernetesで動いている
  • Blue Green Deploymentに対応している

本セッションではデモ動画も紹介していましたが、見た感想としてはコマンド一発で簡単にSpringアプリをデプロイできるので使い勝手はいいなと思いました。上記資料にもデモ動画が添付されています。また、コンテナでアプリを動かす時代においてBlue Green Deploymentがすぐ利用できるのはいいですね。
ただ自分は業務でCloud Foundryを利用していますが、Cloud Foundryと比較したときに違いや嬉しい点はあるのか、Azure Spring Cloudという名前だけあってSpringに特化している点はあるのかなど気になりました。

ローコード開発プラットフォームと、ドメイン駆動設計と、Springの関係

yoshinorinie.hatenablog.com

贄さんによるお話。Wagbyという製品を中心にお話されていましたが、それ以外のDDDや設計に関するお話もたくさんされていました。
お話された内容

  • DDDの特徴
  • DDDにおける難しい点
    • トランザクション処理やRDB, UIとの連携の難しさ
    • 結局のところDDDだけでは全ての実装をカバーできない
    • 開発者が業務も理解する必要があるが、その獲得は難しい
  • ここでDDDとは違うアプローチのローコード開発とは
    • 少ないコードで実装を進める開発
    • 業務設計者がツールの使い方を学び、それを使ってほぼノンプログラミングで実装を手掛けていく
  • それを実現するのがWagbyです
  • WagbyでExcel設計書を廃止し、設計情報とソースコードを同期させたい。業務フローに変更があった場合にすぐにコードのどの部分に影響するか知れる世界にしたい

という感じでした。
発表を聞いた感想としてはとにかく贄さんが熱かったです。業務とコードを一致させるという視点においてローコード開発もDDDも目的は似たようなものだ、というのが印象に残りました。アプローチが違うだけで結局目指す先は一緒なんだろうなと。あ、ちなみにお弁当は美味しかったです。

徹底解剖Spring MVCアーキテクチャー -DispatcherServletの中身を覗いてきました

www.slideshare.net

カサレアル菊池さんによるお話。
Spring MVCのアーキテクチャを詳しく見ていき紹介していくお話でした。この発表では

  • URLとコントローラーメソッドはどう関係しているか
  • コントローラーメソッドの引数はどう解決されるか
  • コントローラーメソッドの戻り値はどう処理されるか

の3つをソースコードレベルで紐解いて解説していました。
かなり情報量が多くてまとめきれないので詳しくは資料をご覧ください。
正直情報量多くて途中で頭がパンクしました・・。このレベルでスラスラ解説できるのは本当に素晴らしく、相当ソースコードを読み込んでいるなあという印象でした。Springはブラックボックスで何やっているかわからないなあと思うことが割とあるので、この辺知っておくと問題が起きたときに強いなと思いました。

システム間連携を担うSpring Integrationのエンタープライズ開発での活用

www.slideshare.net

NTT DATA 太田さんのお話。
Spring Integrationを使ったエンタープライズシステム間の連携手法のお話でした。Enterprise Integration Pattern(EIP)では4つの連携パターンが紹介されていますが、その中でも本発表では非同期メッセージングという連携パターンに焦点を当てていました。非同期メッセージング手法は送信側は待機しなくてよく、受信側の状態に依存しないため、疎結合な連携を実現できるメリットがあります。ここではそんな非同期メッセージングをSpring Integrationでどう実装するかのお話していました。
Spring Integrationはエンタープライズなシステム連携を実現するための実装を提供するプロジェクトです。
Spring Integrationで登場する概念として以下があります。

  • Message
    • システム間でやり取りされるデータ
  • Endpoint
    • アプリケーション連携部の始点・終点に位置し、Messageを生成・出力する
    • メッセージフローの内部に位置し、Messageの加工・ルーティングを行う
  • Channel

これらをBeanとして定義したり、実際の加工処理等を実装することでシステム連携を実現できます。
聞いた感想としては、まずは実際に手を動かしてみないと分からないなあとは思いつつ色々なパターンのシステム連携を同じフレームワークで実現できるのでSpring Integrationがわかっていれば実装が読みやすくなるのかも？と思いました。

その他に、Spring Integrationを使った事例と実際に利用してみての課題もお話されていました。 決済システムと金融機関を繋ぐ中継システムで利用したようですが、出てきた課題を4つ紹介していました。その中で

  • 連携システム数増加に応じてコンポーネント(Endpoint, 業務処理など)が増える
  • 自由度が高い反面実装が無秩序になる

の2つの課題はなるほどと思いました。システム連携元、連携先のペアにつきEndpoint, Message, Channelの実装が増えていくのはつらい。。さらに中身の実装が似たようなものだとすると再利用性も低く読みづらくなってしまいそう。。
また、実装が無秩序になるのもフレームワークとしてそこまで厳格に決まっていない分出てくる問題なのだと思いました。
これらの課題に対し、以下のような策で解決を図ったそうです。

  • 連携システム間のコンポーネントを分解し、データの入出力から業務処理までを1セットとしてパーツ化した => 再利用できるようにしたため、連携元・先につき1つで済むようになり、必要なコンポーネント数を減らせた
  • 処理の標準化を行いそれに沿うような設計・実装にした => 無秩序になるのを防いだ

正直深くは理解できていないので、機会があればSpring Integrationを使ってみたいです。 1つ疑問に思ったこととしては非同期メッセージングというとMessage Queue（Kafkaなど）による連携がぱっと思いついたのですが、MQのpub-sub実装だとSpring Cloud Streamによる実装もあるかと思います。こういう場合はどちらを選択すべきなんでしょう。

Spring と GraalVM Native Image - 2019/12

www.slideshare.net

NTTソフトウェアイノベーションセンタ岩塚さんによるお話。
最近何かと聞くGraalVM Native Imageのお話でした。
そもそもNative Imageとは何かから、コンパイルプロセスでどうNative Image化されるか、最後にSpringにおけるNative Image対応についてお話しされていました。
Native Image化するということはコンパイル方式がAOTコンパイルになるため、JITコンパイルで行えていたリフレクションやダイナミックプロキシは設定を施さないと利用できません。 Springでは内部動作にリフレクションやダイナミックプロキシなど多用しているため、SpringをNative Image化しようと思うと設定が必要になります。
そのサポートを行うプロジェクトとしてSpring Feature(Experimental)が提供されています。
そもそもFeatureというインターフェースがあり、Native Image化の色々なタイミングで任意の処理を挟むことができます。これをSpringに適用させたものがSpring Featureです。Spring FeatureはNative Image化するためにFeatureを使って内部でリフレクションなどの設定を行います。主に以下のコンポーネントが設定をします。

  • Reflection Handler
    • Spring内部で利用するリフレクション設定を行う
  • Dynamic Proxy Handler
  • Springが利用するダイナミックプロキシ設定を行う
  • Initialization Handler
    • Spring内部で利用するクラスの初期化タイミングの設定を行う
  • Resource Handler
    • Springが内部で利用するリソースの設定を行う

Spring FeatureによってNative Image化ができれば利用者自身がたくさんの設定を書くことなく利用できるのでこれは今後に期待ですね。あとはNative Imageの話を聞いているとJVMやOS低レイヤーの知識が足りないなと感じました。この辺の知識不足は定期的に突きつけられる。。

RSocket徹底入門 ~Spring 5.2の目玉機能であるRSocket対応とは~

docs.google.com

Pivotal槙さんによるRSocketとその実装方法のお話。
まず、RSocketについて。

  • 双方向で多重なバイナリプロトコル
  • トランスポートレイヤーには非依存でTCP, WebSocket, HTTP/2など利用できる
  • Reactive Foundationで開発

RSocketの特徴としては以下があります。

  • Duplex(双方向通信)
    • ServerがRequesterにもなれる
  • Reactive Streams
    • SubscriberがPublisherにn件のデータがほしいというように調整可能（Back Pressure）
  • Session Resumption
    • Streamの途中で通信断しても再接続してStreamを再開できる
  • Leasing
    • ResponderがRequesterにリクエストを制限できる
    • RequesterがResponderを圧倒しないようにできる
  • 多言語対応

実装例についてはスライドを参照してください。
また、この発表ではデモを行っていましたが、そのときにrscという槙さん自作のRSocketの通信をcurlのように扱えるCLIツールを使って行っていました。簡単に試したいときには便利ですね。
全体的に聞いた感想としては、技術としては面白いなと思いつつ、本番利用はもう少し事例が増えないと手が出しづらいなあという印象でした。利用場面としてはgRPCのようにマイクロサービス間の通信など外に提供しない場面で使えそうかなと感じました。

Spring Social でソーシャルログインを実装する

www.slideshare.net

楽天田中さんによる発表。
この発表ではまず最初にこうおっしゃっていました。

「Spring SocialはEOLを迎えてしまったプロジェクトです」

えーーー！！タイトルで釣っといて！！と思いましたが、結果的には代替ライブラリとなるSpring Security OAuth2の紹介をしていました。ここではOAuth2.0やOpenID Connectとは何か、それらをSpring Security OAuth2で実装する方法をお話されていました。シーケンス図を用いて認証の流れなどを説明していたので詳細は資料を参照してください。
自分もOAuth2やOpenID Connectを勉強したときは認証の流れが複雑でよく分からないと感じていたのですが、実際に実装してみると流れが頭に入ってすんなりと理解できるようになったので、難しいと思った方は一度実装してみるのが良いかと思います。クライアント側であれば簡単に実装できると思うのでおすすめです。Spring Security OAuth2に出てくるクラスなどは一度聞いただけではさすがに覚えきれないので実装する機会があれば参考にしたいと思います。
最後にライブラリのEOL・サポート状況には気をつけましょうというまとめがあって、Springは特にプロジェクトが多いので自分も気をつけねばと思った次第です。

最後に

二度目のSpring Fest参加でしたが、まだまだSpringの進化に目が離せません。去年と比較してもGraalVMやRSocketなど、新しい技術が入ってきているなあ感じました。実際の業務利用はまだ難しい点はあるかと思いますが、選択肢の1つとして用意できるよう学んでいきたいと思います。

その他気になった発表

聞けなかった発表ですが、資料だけ添付しておきます。

t.co

t.co

t.co

t.co

t.co

t.co

こちらのQiita記事にもまとめられているのでよかったら。

qiita.com

終わり