JSUG勉強会2020その5 Spring Boot 2.3 徹底解説 に行ってきた #jsug

Spring メモ

JSUG勉強会2020その5 Spring Boot 2.3 徹底解説 に参加しました。今回はオンライン開催。簡単に所感をまとめます。

jsug.doorkeeper.jp

所感

Wavefront は初めて知りましたが、VMware が提供するサービスなんですね。k9s や コンテナ向けの機能がどんどん追加されていきますね。ヒープメモリの割り当ての説明が参考になりました。Memory Calculator は便利そう。

YouTube の URL はこちら。

https://youtu.be/mQC7yPTAE5oyoutu.be

以下、メモから抜粋。

Deep dive into Spring Boot 2.3

docs.google.com

  • Boot 2.3 からは半年に1回リリースに
    • Spring Data のメジャーアップデートに対応するため
    • Gradle バージョンアップ (6.3+) が必要
  • k9s Support
  • /actuator/health エンドポイント
    • HealthIndicator
    • 外部サービス向けのヘルスチェック？
    • k9s コンテナのヘルスチェックには不向き
  • Liveness State
    • プロセス内部の状態のヘルスチェック
    • NGの場合はプロセス再起動する (コンテナ再作成)
    • /actuator/health/liveness
    • 外部サービスのヘルスチェックは含めない☆
      • コンテナを再起動しても外部サービスが復旧するわけではない
  • Readiness State
    • トラフィックを受けられるかどうか
    • NGの場合はトラフィックを遮断する
    • /actuator/health/readiness
    • 外部サービスのヘルスチェックを含める
      • アプリ側で対処できるものは含めない (Circuit Breaker, Fallback, ...)
  • Liveness と Readiness の間に任意の処理を入れられる☆
    • リクエストを受ける前にキャッシュをロードしたり
  • k9s 環境ではデフォルトでエンドポイントは有効
    • k9s 以外では明示的に要設定
  • HTTP エンドポイントの他に、イベントの終了結果に応じてコマンドで状態を変えられる☆
  • Graceful Shutdown
    • レスポンスを返す前にシャットダウンするとエラーになったり
    • 高負荷な状態でシャットダウンすると不整合が起きたり
    • Boot 2.2 までは自前で実装
    • server.shutdown=graceful
    • spring.lifecycle.timeout-per-shutdown-phase
      • シャットダウンまでの猶予時間？(デフォルト30s)
    • 新規リクエストは受け付けない
  • Docker Image Support
    • チュートリアルの Dockerfile では不十分
    • Dockerfile 以外でも Docker Image は作成可能
  • Cloud Native Buildpacks
    • OCI イメージを作成できる Maven/Gradle Plugin
    • Paketo (Buildpack 実装)
    • 使われる JRE は BellSoft Liberica☆
    • ヒープサイズとノンヒープサイズを自動設定☆
  • Buildpack の Docker Image ではロード済みのレイヤー (ミドルウェア) は再利用される？
    • push/pull されない
  • コンテナのメモリサイズと -Xmx の設定値を同じにするのはNG
    • ノンヒープの分を考慮する必要あり
    • Memory Calculator
      • ヒープサイズ = コンテナメモリ - ノンヒープ
      • jar 内のクラスファイル数, MetaSpace, Thread Stack など
    • ノンヒープがコンテナメモリを超える場合はエラー
      • スレッドや Reserved CodeCache の分を減らしたり
    • Memory Calculator のパラメータと Tomcat などのパラメータは合わせる
  • Head Room
    • Java 以外のプロセスが利用するメモリ
  • Memory Calculator は個別に利用可能
  • JVMKill Agent
    • OOME が発生したときにプロセスを kill する
    • k9s のときに適宜コンテナを再作成してクリーンな状態に
  • Layered Jar Format
    • アプリのレイヤーをさらに細分化 (application/dependencies)
    • 依存ライブラリの更新頻度は高くないので push/pull 不要
    • Dockerfile multi-stage builds と組み合わせると Dockerfile でも可
  • デフォルトではレスポンスに例外メッセージを含めなくなった
    • server.error.include-message, server.error.include-binding-errors で変更可
  • spring-boot-starter-validation が含まれなくなった
    • Bean Validation を使う場合は個別に依存を追加
    • メモリフットプリントが大きいから
    • Hibernate Validation 6.1 から自動でロケールを見てメッセージを表示
  • spring-boot-properties-migrator
  • Wavefront
    • SaaS モニタリングサービス
    • Sleuth, Micrometer からメトリクス/トレース送信
    • Spring Boot から Freemium アカウント作成可
    • ワンタイムリンクでダッシュボードにアクセス可
    • 2回目以降はプロパティに設定
  • GraalVM Native
    • Actuator, JPA, Cloud Function, Jafu
    • メモリフットプリントが小さく
    • AWS Lambda 上で動かすためのアダプタ？
    • ネイティブのコンパイル時間は CI のサンプルのビルド結果を参考に

Remote.vue #1 に行ってきた #remote_vue

Vue.js メモ

先日、Remote.vue #1 に参加しました。オンライン開催。簡単に所感をまとめます。

lapras.connpass.com

所感

アーキテクチャから API までいろいろ知見のある内容でした。特に、アーキテクチャではどういう判断基準があってその構成になったのかを聴けるのはとても参考になります。今回、初めて知ることもいろいろ...。Vue.config.errorHandler とか。

あと、SSR もまともにやったことがなくて、恥ずかしながら初めて hydration を知りました。ただ、こういうのをまったく知らずに引き出しもない状態だとハマったときに抜け出せなくなるので、知見として話を聴いておくことができてよかった。

最近、Vue をがっつり使った開発から少し離れてしまっているけど、ちゃんとキャッチアップしておかないと...。とりあえず、このあたりから調べようかと。

  • Vue 3 (Composition API, ...)
  • Nuxt.js
  • TypeScript

YouTube の URL はこちら。

https://youtu.be/rx249I9JmNUyoutu.be

以下、メモから抜粋。

超高速devサーバーvite

  • Native-ESM powered web dev build tool
  • 開発ビルドツール
    • dev: ネイティブ ES モジュールに最適化
    • prod: rollup を使ってビルド
  • vue-loader がサポートしているものはサポートしている
  • VuePress
    • サーバーの起動が遅い
    • ES モジュールの HMR
    • SFC を ES モジュールで動かしたい
    • ES モジュールに最適化されたバンドラがない
  • Snowpack
  • サーバーの起動が速い
  • オンデマンドコンパイル
  • HMR (他のバンドラより速い)
  • 開発モードのときはバンドルしない？
  • esbuild
    • 他のバンドラより速い
  • HTTP リクエストごとにコンパイル
  • HMR は画面単位で動く
  • キャッシュ
    • 変更がないものは304で返す
    • Service Worker
      • サーバー側のキャッシュを破棄するのに Service Worker を使ってたり
  • Koa
    • Express より高速な HTTP サーバー
  • プラグインアーキテクチャ
  • Module Rewrite Server Plugin
    • 相対パスから絶対パスに書き替える
    • import のパスに timestamp が付く
    • import しているモジュールのsグラフを持っている
  • HTML Rewrite Server Plugin
  • Vue Server Plugin
  • HMR Server Plugin
    • サーバー側の変更が WebSocket を経由して通知される
    • dynamic import で変更されたモジュールをダウンロード
    • HMR グラフを解析
    • 木構造を遡って対象を探す
    • HMR 対象のファイルが見つからない場合は index.html をリロード
  • VitePress？React？Preact？

ぼくのかんがえたさいきょうのVueあーきてくちゃ

  • ディレクションの知識
  • コンポーネント150個&API100個以上の規模の事例
  • フロントの責務 > 遷移と参照☆
    • Vue Router
    • 一覧の処理 ⇒ ロジックとして共通化する
    • 詳細 ⇒ 愚直に作り込む (共通化の余地がない？)
  • フロントの責務 > 権限と操作☆
    • 権限は参照/操作における DOM 表示とAPIリクエストに関わる
    • バリデーションも権限のひとつと言える？
  • 見通しのよい構成☆
    • SetupContext (this が持っているコンテキスト？)
      • これに依存する処理は切り出す
  • ディレクトリ構成☆
  • enums
    • 定数が扱えるなら enum でも union でもいい
    • namespace をオーバーライドしてメソッドを生やせる☆
    • 文字列で扱えばデシリアライズしなくても比較できる
  • models (BaseModel)
    • APIクライアント
    • Vuex の store の action に API リクエストを入れない
    • BaseModel は基本的な CRUD のメソッド
    • レスポンスはデシリアライズを通す
    • extend したクラスでは CRUD は書かない
  • modules
  • mixins
    • SetupContext を利用した処理
    • Composition API の SetupContext を切り出したロジック
    • ビジネスロジックに近いけど SetupContext がないと処理しづらいもの
    • emit, $router, $store はここで呼ぶ
    • 一覧系の共通ロジックを入れたり
  • views のコンポーネントは画面と1対1に
  • 汎用的なコンポーネントは components に
  • ドメインやビジネスロジックを持つコンポーネントは templates に
  • Vuex に API クライアントの責務は持たせない
    • 画面共通リソースとの store, およびその永続化に留める☆
    • ログインユーザー情報, 権限, など
  • moment.js のロケールファイルを除去してファイルサイズ縮小
    • day.js がよさそう？
  • v-bind.sync☆
  • 部分型☆

Vue.observable で状態を管理する

  • Nuxt.js + TypeScript
  • ページをまたいでグローバルな状態を管理したい
  • Vuex (モジュールモード)
    • ディレクトリ構成に対応するプロパティが動的に生える
    • TypeScript と相性がわるい
  • Vue.observable☆
    • Vue 2.6+
    • js のオブジェクトをリアクティブにできる
    • Vue の data 関数の仕組みも同様
    • Composition API の reactive 関数とほぼ同じ？
  • Vue.config.errorHandler☆
    • 例外発生時に登録した関数が呼ばれる
  • エラー状態を Vue.observable で定義
  • Vue.config.errorHandler の関数でエラー状態を変更する
  • SSR の場合、Vue.observable だけでは hydration できない？☆
  • Vue.observable は状態を変更する口が少なくなる
    • 見通しがよくなる

NuxtでSSRしている時でもGoogle Optimize(ABテスト)を動かしたい

  • Google Optimize
    • A/Bテスト, GUIでテストの設定ができる
    • GAなどの連携
  • Nuxt で SSR しているサイトで Optimize を使いたい
  • hydration☆
    • 場合によっては DOM を破棄して再構築する
  • hydration が終わってからテストを起動/実行する
    • app.mounted (Vue)
    • window.onNuxtReady (Nuxt) ※ドキュメントに書いてない...
  • vue-server-renderer

終わりゆく Vue 2.x 時代の状態設計の答えと Vue 3 の Provider への期待

  • Inject を軸に構成する
    • Vuex への依存は抑える
    • HTTP 通信など SPA 外部への依存は Inject を通して DI 的に実装する
  • モーダルのフラグ > portal-vue, Teleport (Vue3)
    • 仮想 DOM 上の親子ツリーとは別のところに状態をマウントできる？
  • Vuex を使わないだけライフサイクルフックに乗れる☆
  • ストア使いたいけど Vuex じゃなくてもいい
  • Inject☆
    • Nuxt.js の Plugin に同梱されるオブジェクト注入の機能
    • アプリケーションの this に生える依存を DI できる
    • vue-test-utils でモック化しやすい
    • TypeScript の型定義を追加する余地がある
  • 必要最小限の API と依存で状態が管理できる
  • inject 関数の第2引数に入れているもの以外は外に露出しない
  • Recoil
  • Vuex の型定義 (Vuex.Store<any>)
    • 次期バージョンから改善される
  • vue-test-utils と相性がよい
    • this に依存が生えるので mocks が使える
  • Inject は粒度が小さいものになるので取り回しやすい☆
  • Vuex を HTTP リクエストのキャッシュに使わない
    • HTTP キャッシュ or Inject でオンメモリ
  • Prototype 拡張や provide / inject は Vue 2.x 自体にある
    • provide / inject は Vue 3 でより扱いやすくなる
    • Composition API と合わせて使う
    • React のカスタムフックみたいな
  • Vue.observable + Inject で Composition API に近い書き方になる☆
  • inject の粒度を考えて使わないと $ が煩雑になりそう
  • スコープを狭めることを自分で考える☆
    • Vuex では仕組みとして提供されている部分？
    • state を直接いじらないとか mutation を通すとか...

改めて考えるフロントエンドライブラリ共有LT会に行ってきた #ouchi65

Vue.js メモ

先日、改めて考えるフロントエンドライブラリ Angular, Vue, React, jQuery etc... 〜何を利用してる？共有LT会〜 に参加しました。オンライン開催。簡単に所感をまとめます。

techplay.jp

所感

今回、Angular, Vue, React, jQuery etc... ということでしたが、ほとんど Vue だったような...。ただ、取り組んでいる課題や工夫の話が聴けてとても参考になりました。個人的に TODO<T>: any は興味深かったです。

あと、分類のグラデーションというのも面白かったです。自分はパターン2と3かな。確かに段階的に移行できるのは Vue のメリットかもしれないし、これがいわゆるスモールスタート可能と言われるやつですかね。

途中、アンケートを取るところがいくつかありましたが、自分の環境ではできず...。ブラウザから Zoom に参加しているからだろうか？

YouTube の URL はこちら。

youtu.be

以下、メモから抜粋。

LINEサービスをTypeScriptに置き換えた際のノウハウ&苦労話

  • テストコードがない
  • 環境が古い
    • webpack, Babel, ...
  • ビルド環境が違う
    • Browserify, module.exports/require, import/export
  • TypeScript
    • 型の安心感, コードレビューの負荷軽減
  • テスト
  • ts 運用基盤の構築
    • 中長期的にプロジェクトに適応させる
  • 小さく適用する
  • ts コンパイル
    • 既存 js ファイルのビルド結果は変えない
    • 正しくトランスパイルできているか
    • 小さいファイルから ts 対応, ビルド生成物の差分を確認
    • tsconfig の allowJS オプション有効化 (jsDoc で型チェック)
    • tsconfig の target を es2019 に
      • これまで通り Babel で Polyfill を入れたい
      • ts 側で Polyfill を入れることも可
  • Vue の SFC を ts 対応
    • Vue.extend
    • vue-class-decorator や vue-class-component は変更が大きい
  • ビルド時間短縮
    • fork-ts-checker-webpack-plugin
    • 型チェックのプロセスを分離
  • ビルド環境をシンプルに
    • ts-loader で js/ts をビルドできるように
  • テスト
    • Karma ⇒ Jest
    • window オブジェクトを書き替えるテストがやりやすい
    • jest.resetModules
    • まずはユーティリティ系から
  • 移行中にリファクタリングや修正はしない
    • 問題が起きたときに切り分けしづらい
  • TODO<T>: any
    • とりあえずビルドを通してあとで直せるように
  • computed の返り値の型を明示的に書く
  • target 以外に transpileOnly=true を設定

Frontend負債返済の野望 @ Repro

www.slideshare.net

  • 負債返済によって開発コストを下げる
  • フロントエンドとバックエンドの切り離し
    • BFF
    • フロントエンドのロジックを Rails 依存から切り離す
  • フロントエンドだけで適切なアーキテクチャ設計が必要
    • 関数型言語の影響が入ってきている
    • 過去の js のノウハウは基本的に使わない (混ぜない)
  • Vue.js にはモデルレイヤがない？
    • MVVM が難しい？どうやって状態を持つか？
    • immutable な state を考えると関数型のアプローチがよい
  • Vue 3 を待つ余裕がない ⇒ React に転換？
  • 余談) うさぎのプレゼンツール

ビザスクliteなVue.jsの使い方

様々なプロダクト環境から垣間見るVue.js

  • Rails + Vue
    • helper でカバーできない動的処理を Vue に任せる
    • Vue は jQuery の代わり？
    • SSR にできる
    • SFC の仕組みが生かしにくい
      • Lint, UT
      • テストは E2E 頼み
    • Vue 以外が DOM に触れる
  • Vue + Rails
    • コンポーネントの mount と props に値を渡すのみ
    • Rails と Vue のインタフェースが限定される (props/API)
    • SSR にできない
    • 渡したい値は props に詰め込む
  • Vue
    • Rails と Vue のインタフェースは API のみ
    • バックエンドとフロントエンドが分離される
    • API を mock すれば画面実装可能
    • E2E テストが難しい
  • 完全 Rails から徐々に Vue にシフトしたり
    • Vue の Progressive さがいい感じにマッチしている
    • テンプレートベースだから？テンプレートエンジンに組み込めるから？

TechTrain しくじり先生 - Nuxt.js, Vue.jsにおけるしくじり

  • ページをまたがるグローバルなストア
    • ログイン, ログアウト, Firebase 以外の処理, ...
    • pages に書いてある
    • ⇒ Nuxt.js + ts, Action から状態を触る
  • 他ページ用の store が冗長にロードされる
    • 肥大化した data プロパティ
    • API通信でN+1
    • ⇒ 余計なロードを削る
  • SSR
    • SPA, meta タグなし, リッチカード対応なし
    • ⇒ client タグなど
  • ページ遷移で UI がチラつく
    • API通信でローディング表示なし
    • ⇒ v-cloak, loadingindicator
  • SSR がどのくらい SEO に影響するか
    • Google が SPA に対応しているけど...

Amazon Transcribe + Amazon Translate + α

AWS Python

Amazon Transcribe と Amazon Translate を題材にしたハンズオン。

ハンズオン3の文字起こし + 翻訳パイプラインで、とりあえず、文字起こししたテキストを翻訳して S3 にアップロードするところだけ。

gist.github.com

日本語テキストをそのまま json.dumps すると Unicode エスケープされるようなので、第2引数に ensure_ascii=False を指定する。

参考

AWS Lambda でS3にファイルがアップロードされたら、加工して別フォルダにファイルを作成する（Python） - 株式会社CoLabMix

UNION したクエリで ORDER BY + CASE WHEN する

SQL

備忘録。

UNION したクエリで ORDER BY する。さらに ORDER BY 句で CASE WHEN するパターン。使い道があるかは分かりませんが。

UNION したクエリに AS で別名を付けて、ORDER BY 句ではこの別名を使う。

SELECT * FROM (
  SELECT
    t.id AS t_id, t.name AS t_name, t.order AS t_order
  FROM
    table AS t
  WHERE
    ... (略)
  UNION
  SELECT
    t.id AS t_id, t.name AS t_name, t.order AS t_order
  FROM
    table AS t
  WHERE
    ... (略)
) AS uniontable
ORDER BY
  CASE WHEN uniontable.t_order IS NULL THEN 1 ELSE 0 END ASC, uniontable.t_order ASC,
  uniontable.t_id ASC

現場からは以上です。

JJUG Java生誕25周年記念イベントに行ってきた #jjug

Java メモ

先日、JJUG Java生誕25周年記念イベントに参加しました。今回はオンライン開催。簡単に所感をまとめます。

jjug.doorkeeper.jp

所感

JJUG CCC 2020 Spring が中止になり、代わりに開催されたイベントです。Java 生誕25周年。セッションは総会を含めて5本でしたが、幅広い内容で面白かったです。

しかし、IDEの位置付けについてここまで深く考えられるもんなんですね。納得感のある内容でした。今のプロジェクトで使ってる Eclipse めっちょ古いからバージョンアップしなければ...。まずはバージョンアップできるようにプラグインとか周辺のツールを整理するところから。

Jakarta EE はパッケージ名の変更がインパクト大きそうだけど、YouTube のコメントを見てると意外とマイグレーションツールが提供されるっぽい？

あと、キャッシュの更新検知はプロダクト任せになるのかな。Infinispan は通知してくれるみたいだけど。結局、セッションにはユーザー情報とか更新頻度が低いものを入れるのがよさそう。

YouTube の URL はこちら。

youtu.be

以下、メモから抜粋。

Java 14 新機能を軽くまとめてみた

  • Java 14
    • 16 JEPs
    • non-LTS (パッチは15リリースまで)
  • 言語機能の標準化は3段階
  • Incubator
    • ライブラリ
    • incubator モジュールとして import する必要あり
  • Experimental
    • JVM 機能
    • Standard ではなく Production
      • JVM 機能は Java の標準ではなく実装ごとの機能のため
  • Text Blocks (Preview 2)
    • 15 で Standard になる予定
    • 改行のエスケープ (\)
    • スペース文字 (\s)
  • Switch Expressions (Standard)
    • case 句に複数のラベルが指定可 (ステートメントも同様)
    • アローを使うと break は記述不要
    • 値を返すときは yield を使う
    • yield はキーワードではない (型名には使えない)
  • Records (Preview)
    • データをやり取りするための型, 名前付きタプル
    • Record は特別なクラスなので自分のコードでは継承不可
    • invokedynamic で実行時に処理コードが生成される
      • 新バージョンで実装が最適化された場合、旧バージョンでコンパイルしたコードも新しい実装で動く
    • ほぼ enum と同じ扱い？と考えてよい
  • Sealed Classes (Java 15 で Preview)
    • 継承するクラス/インタフェースを限定できる
    • Switch 式で default が不要になる
      • すべての case を処理したことをコンパイラ側で検知できるため
  • Pattern Matching for instanceof (Preview)
    • スマートキャスト
    • if (obj instanceof String s) {...} って文法として微妙な気がするのは自分だけだろうか...
    • 今のところバイトコードには無駄なところが多い模様
  • Pattern with Switch
    • switch でパターンマッチ
    • 近いうちに入るかも？
  • Deconstruction
    • switch の case で Record を分解する
    • 今のところ入る予定なし
  • JFR Event Streaming
    • ファイルにダンプしたデータはストリーミングで見るには不便
    • Event Streaming ではイベントとして処理できる
    • 監視に使いやすい
    • JFR はそろそろ OpenJDK 8 にパックポートされる模様
  • Foreign Memory Access API (Incubator)
    • ヒープ外のメモリを扱う
    • これまでは Unsafe が使われていた
  • @PreviewFeature
    • これまでは Preview の API には @Deprecated が使われていた
    • @PreviewFeature の API を使う場合は --enable-preview が必要
    • ※資料には --enable-feature と書かれてますが、正しくは --enable-preview です (確認済)
  • Packaging Tool (Incubator)
    • ランタイムを含むアプリケーションパッケージ
      • アプリケーションを使う側は事前に Java をインストールする必要なし
    • パッケージングは jpackage コマンドを使う
    • インストーラ/アンインストーラ
    • ランタイムをコンパクトにする場合は jlink でカスタムランタイムを作成
    • これからはランタイムは開発側が責任をもって提供する
  • https://qiita.com/nowokay/items/ec85d97a7cecaaac8123

IDE起点で2020年代の開発環境を眺めてみる

  • たくさんのツールを使うのは高コスト
  • ツールを組み合わせると取りこぼすものがある
    • これらをシームレスに使えるようにするためにIDEがある
  • いろいろなツールを使うことより開発そのものにリソースを割きたい
  • 開発で使うツールは開発を邪魔するものであってはならない
    • ただし、ツールを蔑ろにしていいわけではない
  • IDEの役割は開発を容易にすること
  • IDEは開発者のためにある
  • 開発対象のアプリケーションがIDEに依存してはいけない
  • IDEはビルドツールの設定を読み込んで使う
    • IDEはビルドツールに依存させる
  • IDEの独立性を高める☆
    • IDEはなんでもいいというところまで持っていく
  • アプリケーションに影響を与えるものはIDEに設定しない
    • JDKのバージョン, ライブラリ管理, フォルダ構成, など
    • IDEの設定を変えたからサービスが停止したということはあってはならない
  • IDEからビルドツールを使うときにIDEバンドルのJDKは使わない
    • アプリケーションに影響を与えるから☆
  • IDEを使うならエラーを出したまま放置しない
    • IDEが出している警告も個人的には残したくない...
  • いざというときにプリミティブなツールが使えると安心
  • IDEの新規プロジェクト作成とかクラスパス設定とかは今はやらない
  • フォーマッタを切り離したい
    • 言語にフォーマッタが付いてるといい
  • IDEのバージョンアップは積極的にするべき☆
    • IDEがバージョンアップできない状況にしない
    • IDEが独立していれば問題なくできるはず

Jakarta EE / MicroProfile を利用したクラウドネイティブアプリの開発

www.slideshare.net

システムのモダナイズ 落ちても良いアプリの作り方

www.slideshare.net

  • スケールアウトしたのに負荷が偏る
  • スケールインで情報を持っていたノードが消えた
  • システムの可能性を高めるには
    • 耐障害性向上
    • スケールアウト
  • クラウドを使っているとそれ以上耐障害性を上げられなかったり
  • ステートレスなアプリケーション ⇒ スケールアウト
  • ステートフルなアプリケーション ⇒ ？
  • ステートの取り扱い
    • DB/インメモリに読み書き
    • 透過的に使う ⇒ HTTPセッション
  • なぜHTTPセッションを使うのか☆
  • HTTPセッションに入れていいもの☆
  • Connection や Thread は Serializable ではない
    • 同一のアプリに接続している場合はたまたま動く
    • 実装の参照がそのまま使えるから？ (シリアライズした情報ではなく参照を使う)
    • アプリをまたぐ場合にシリアライズされる ⇒ NG
  • ステートはどのように保持されるか☆
    • ファイル(共有ストレージなど)/DBに置く場合、複数のアプリでステートを共有できる
  • アプリがステートを持つメリデメ☆
    • ステート数が増加してヒープを逼迫するとGCによる停止時間が増えてレスポンス遅延に
  • ファイル/DBがステートを持つメリデメ☆
  • ステートフルで可能性を担保するために重要なこと☆
    • ステートをどこで持つか
    • リクエストをどう振り分けるか
  • セッション外部化
    • DBにステートを持たせる
    • 全体はステートレスになるもののレスポンスは遅い
    • 外部ストアの性能劣化にはニアキャッシュを使う
  • ニアキャッシュ
    • よく使うセッション情報をアプリ上にキャッシュする
    • ネットワークやディスクアクセスを減らす
  • スティッキーセッション
    • アプリが落ちるとセッションは消える (運用で落とす場合も同様)
      • オートスケールできない？
    • 負荷が偏る可能性あり ⇒ 時間を短くして分散しやすいように
  • DBにゴミデータ残らないか？
    • セッションの有効期限を設定する
  • セッションには変更されない情報を入れるのが現実的？☆
  • キャッシュの更新は？
    • HttpSession の実装による
    • Infinispan では無効になったときに通知してくれる
    • Infinispan は同じ JVM プロセスの中で動く
    • Hazelcast も同様？
    • WebSphere では JSESSIONID の Cookie にキャッシュのバージョンが入っていてニアキャッシュと毎回比較している

チームリーディング フロントエンドコンポーネントの指針に行ってきた #narusemi

Vue.js Atomic Design メモ

チームリーディング フロントエンドコンポーネントの指針に参加しました。今回はオンライン開催。簡単に所感をまとめます。

nrs-seminar.connpass.com

所感

前回のクリーンアーキテクチャに続き、今回はフロントエンド寄り、特に新しい技術を導入するときにどのようにチームをリードしたかという話。自分もかつてプロジェクトで Vue.js を採用した経験があるため、とても興味深い内容でした。メンバーに対してきちんと説明できるように自分の中で明確な基準を持つことが大事なのかなと思います。自分はここまでちゃんとできなかったけど...。Vue.js を採用したときのまとめなどはこちら。

Vue.js + Vuex + axios を使うときに考えたことや反省点など - kntmr-blog

メンバーにコンポーネント指向をどう根付かせるか、デザインからどうやってコンポーネントに落とし込むか、そのあたりの話が参考になりました。フォルダ構成は大事。自分は Vuex の examples あたりを参考にしたっけ。

ところで、JS フレームワークと jQuery の相性はよくないという話はよく聞くけど、個人的には適材適所かなと思っています。jQuery を Web フレームワークのように扱うと破綻するけど、DOM アクセスのユーティリティとして使う、豊富なプラグインを生かすことを考えれば、決して駆逐するほどではないかなって。ただ、「仮想 DOM など SPA の利点がなくなる」という点は確かにという感じ。

あと、Vuex のようにデータを1箇所にまとめることで「コンポーネントがデータ越しに依存する」という話は興味深かったです。イベントで繋がることで疎結合になる、と。なるほど。そうすると確かにコンポーネント間で emit する方が分かりやすいしメンテしやすくなる気がする。でも、Flux アーキテクチャってまさにこのあたりを解決するものではなかったっけ？ちがったっけ？もしくは Action の IF 設計とか、Store とコンポーネントに持たせるデータの種類にもよるか。

React は JSX が好きになれるかどうかなのかー。

以下、メモから抜粋。

https://youtu.be/sZA92l4XQsAyoutu.be

  • ゲーム業界に比べて Web 業界のコンポーネント指向は遅れてる
  • Atomic Design
  • JS フレームワークと jQuery の相性はよくない
    • 仮想 DOM など SPA の利点がなくなる
  • フレームワークを使う理由
    • 無意味に重複したコード
    • 意図が見えづらいコード
    • 解読が難しいコード
  • jQuery のコードは前提とする DOM の状態が実装者以外に見えづらい
  • フレームワーク + コンポーネント指向
    • モジュール性を高める
    • 小さく作って理解の範囲を狭める
  • Atomic Design
    • パーツ同士を組み合わせる
    • コンポーネント指向
    • どういう粒度で作ればいいかイメージできる
  • Atomic Design はデザイナー向けのデザイン手法ではない？
  • CSS フレームワークと Atomic Design の粒度は合わないかも？
  • オブジェクト指向は継承やポリモーフィズムなどのための仕組み
  • コンポーネント指向はパーツの取り外しがしやすいように疎結合にするための仕組み
  • ひとつのページを分析してみせる
    • これ以上分解できない要素はどれか (Atoms)
    • Atom を組み合わせる (Molecules)
    • Atom もしくは Molecules を組み合わせたもの (Organisms)
  • ページを担当分けしてみんなでやってもらう
    • 最初にやってみせることで参考になる
    • みんなでやってあとで集約する
    • みんなにやってもらう間にサンプル実装を作る
    • 構成サンプル☆
      • Atomic Design の要素に合わせて構成する
      • Atom の下でさらにフォルダを切ると見通しがよくなる
  • Templates はページレイアウト？
    • Templates や Pages はない場合もある
    • ステークホルダーと話し合うときに使うためでもある
    • コードに落とし込むかどうかはプロジェクト次第
  • Atomic Design とは別に pages フォルダを用意
  • 位置調整などはコンポーネントにしない
  • ボタンコンポーネントを分けたらボタンじゃなくなる
  • Atom を利用したら Molecules
  • Molecules を利用したら Organisms
  • 意味のある塊は Organisms
  • Organisms を利用した Organisms はあり
  • コンポーネント定義
  • データは親コンポーネントが持つ
  • Vuex のようにデータを1箇所に集めるとどこからデータが変更されるか分かりづらい
  • Playground の場を用意して実践してもらう
  • 共通化しすぎて内部で v-if が増える場合は分離するタイミング？
    • 別のものをあとから共通化するより、共通化したものを分ける方が簡単
  • API アクセスはページが担う
    • 共有されるパーツでは Organisms でも許可
  • Molecules が Organisms になることはある
    • Molecules と Organisms の違いは意味を持たせるかどうか
  • BFF のメリットは複数の API アクセスをまとめられること