Zenn
Open14

気になった記事一言まとめ: 2024年5月

Go
frontend
負荷試験
k6
slog
かずかず

01

https://zenn.dev/raru_ex/articles/eb3aa038b38771

  • 最近のJs周りについて軽くまとめられている
  • JavaScriptのRuntimeは、実行時の環境・構成・処理を管理するシステム群をパッケージングしたシステム
    • セキュリティ機能・パッケージマネジメント機能・TSを実行可能にするトランスパイラ・etc
    • Node・Deno・Bun
      • Node: 安定稼働向け、デファクトスタンダード
      • Deno: Nodeの失敗点を踏まえてNodeの開発者が開発した・セキュリティ強化・etc
      • Bun: 速いらしい・Nodeとの完全互換を目指している
  • JavaScriptのEngineとして、V8・JavaScriptCoreが存在する
    • Engineはインタプリタやコンパイラにあたるもの
    • V8: Chrome・Node・Denoが採用
    • JavaScriptCore: Safari・Bunが採用
  • トランスパイラ
    • ある言語で書かれたコード => 他の言語のコードに変換する
    • 新しい言語仕様 => 古い言語仕様のコードに変換する
    • Babel・SWC・esbuildが存在する
      • Babel: もともと、新しいECMAScript仕様 => 古いECMAScript仕様で、古いブラウザでも動作するようにするツール。plugin的な形でts -> jsへの変換も可能に
      • SWC: Babelより早く動作する
      • esbuild: Module Bundlerだが、ts -> jsへのトランスパイルも可能。型チェックは行わないらしい
  • Module Bundler
    • プログラムの依存解決を良しなに解決して、一つのファイルにまとめるもの
    • webpack・vite・esbuild
    • webpack: 古くからある、色々な機能を盛り込んでいる
    • vite: webpackより設定が簡易であったり、パフォーマンスが高そう。内部的にesbuildを利用sしている
    • esbuild: Go製のバンドルツール
  • Linter・Formatter
    • Formatter: prettier
    • Linter: ESLint
    • Biome: romeの開発者が作ったツール
  • Hono: Web Framewaork。Cloudfrare workers向けに作成された。めちゃ軽量らしい
  • Prisma: ORM
  • 感想
    • Jsがインタプリタな理由: 引数などに型定義がなく実行時まで型が確定しないので、事前に機械語や中間言語にも変換できない。これは動的型付け言語は基本的にインタプリタ形式である理由なのか?

TODO

  • Engineの語源を調べる
  • Module Bundlerについて自分でも調査する
  • 動的型付け言語とインタプリタの関係を調べる
かずかず

11

https://zenn.dev/morinokami/articles/npm-uninstall

  • Nodeのバージョンとして22がリリースされました。
  • リリース時に追加された新機能より、不要になりえるサードパーティ製のパッケージがあるらしい
    • dotenv
    • node-fetch
      • ブラウザのFetch APIを利用するための機能
    • chalk
      • ターミナル上の文字をスタイリングする機能
    • mocha
      • テストフレームワーク
    • Nodemon
      • ディレクトリ内のファイル変更検知して、アプリの再起動を実行する機能
    • glob・fast-glob
      • ワイルドカードを使用したファイルパス指定を行うための機能
    • Commander.js、Yargs
      • CLIコマンドの実装に必要な機能を提供している
      • util.parseArgsが代替の機能

https://prtimes.jp/main/html/rd/p/000000024.000081310.html
https://dxcriteria.cto-a.org/frontend

  • 日本CTO協会の人が、企業でのWebフロントエンド開発周りについてのガイドライン資料を作成した
  • 個々の資料は自分がリーダー的な立場になった時の参考資料として、定期的に見直すのがよさそう

https://medium.com/@danielmalagurti/enhancing-web-api-security-essential-open-source-tools-for-tech-leads-part-3-owasp-zap-96cbfb91cc16

  • OWASP ZAP(Zed Attck Proxy)という無料の脆弱性診断ツールが存在する
  • 自動スキャン・手動テスト・REST APIの提供・Webサイトの新しいリソースの検出・有害データを送らず脆弱性を検出し、模擬攻撃で検出する

ref: https://qiita.com/tamura__246/items/9c70ddc1c03cf623cf8d

かずかず

12

https://zenn.dev/canary_techblog/articles/0cd332e5ae0112

上記の記事から抜粋

  • 利用している技術スタック
    • EASという(Expo Application Services)、Expoフレームワークを利用して開発されたコードのビルド・デプロイ・スケーリングを簡単に行うクラウドサービス
    • MagicPod: ノーコード・クラウド上でアプリのE2Eテストができるサービス
    • Twillio: APIを通じてSMS、音声・ビデオ通話機能を行えるサービス
    • Redux Toolkit(RTK): 状態管理・データフェッチ周りの便利機能が提供されている
      • RTK Query: データフェッチにかかわる状態管理を行う
    • react-native-reanimated: react nativeのコンポーネント要素などをアニメーションするために利用している
    • Lottie: JSONベースのファイルを元にアニメーションを行う機能
    • react-native-maps: React Nativeアプリケーションで地図を表示・操作するための機能を提供している
    • Storybook: フロントエンドのコンポーネントを開発・ドキュメント化・テストするためのツール
  • UIコンポーネントとして、Atomic Designをベースにしている
かずかず

13

https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md

今回は概要まとめ

  • slogのdesgin doc
  • 標準ライブラリに、レベルを持った構造化ロギングを追加することの提案
    • 構造化ログは、人間が読めるメッセージに加えて、機械が読める構造であり、キーと値のペアを持つログを出力する。構造化されたログは、人が読むためだけのログより、早く・確実に解析・検索・フィルターなどを行うことができる。
    • ロギングのバックエンドの一般化: これは要調査
      • 既存のlogパッケージ、ログを書き込むio.Wrtiterに対してのみ制御できる
      • 新しいlogパッケージは、ログを出力を行うloggerに関して、様々なログイベントに対して処理を行うハンドラを持つ
    • 伝統的な内容や、logrの冗長性の両方に対応した、レベルに関する内容を組み込んでいる
  • ゴール
    • 使いやすさ, key-valueの形式で表現
    • 高いパフォーマンス
    • ランタイムトレーシングとの統合: これは要チェック
      • プログラムの動作と、ランタイムの動作を関連付けできるようになる
かずかず

14

https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md

上記の続き

  • What dos success look like?
    • 既存のサードパーティからの書き換えではなく共存を期待している
    • ユーザーが、依存関係を避ける以外の目的でも、新しいコードを書く際に既存パッケージよりこのAPIを好めるような快適なAPIを提供することを試した(ランタイムトレーシングとの統合など)
    • この提案で重要なのは、バックエンドの共通化の約束である(ログのレコードを取り扱うもの)
      • 実際のアプリケーションでは、様々なログパッケージが利用されるが、それぞれがこのAPIで提案するハンドラインタフェースをサポートすることで、アプリケーションは単一のハンドラを作成し、それらを各ロギングライブラリに一度だけ設定することで、それらすべてで共通したロギングを得ることができる
      • この設定はアプリケーションのメイン関数で行えば済むので、最小限のコードの変更で済む
      • この提案のハンドラとは、すべての一般的なネットワークプロトコルやログフォーマットに対して実装され、各ロギングのフレームワークが自身のバックエンドからハンドラへの調整を提供することを期待している。
      • そうすことで、Goのロギングのコミュニティはみんなが共有できる高品質なバックエンドを構築するために協力できる

以下良さげな記事

かずかず

15

https://medium.com/@gregmus/dependency-injection-in-golang-simplifying-microservice-development-258571429c8d?source=rss------golang-5

  • goにおける依存性の注入のライブラリとして、digやfxが存在する
  • fxでは、依存性注入のために様々な機能が提供されている
    • 同じインタフェースで異なる設定を適用したものを作るときに利用するModuleという機能
    • 作成した構造体を調整するDecoratorsという機能
    • コンテナ内で同じインタフェースを使いまわすときにwireだと別名の型を作成しなければならないものを、Annotationsという注釈をつけることで同じインタフェースでもそれぞれ別々認識するための機能がある
  • digやfxはその柔軟性を実現するためにReflectionを利用しているので、問題のある設定をした場合にランタイムエラーでしか検知できない

https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md

Overviewを読んだ

  • slog主要なコンポーネントは3つ

  • 1: Logger: フロントエンドで、ログの生成を行う

  • 2: Record: Loggerで生成されたログデータ

  • 3: Handler: Recordの出力

  • Handlerのインタフェース

    • Enabled
      • 出力する際の最低レベルの設定
    • Handle
      • ログの出力を行う
    • WithAttrs
      • 追加の属性をもつHandlerを生成する
    • WithGroup:
      • 指定したグループ名を追加したHandlerを生成する

  • Slogは、textとjson用のHandlerを用意している

  • Record

    • レコードに対して属性の追加・レコードの属性ごとに関数を実行する機能など色々ある
    • Copyする機能もある
    • Attr(上記で属性といったもの): key-valueの情報
      • valueでは、Value型を提供しており、メモリ割り当てが発生しないようになっている
      • LogValuerインタフェースも提供しており、LogValue() Valueを取り扱うが、それを利用するとレコード生成時に、これが実行されてログに渡すようの値を作れそう

  • Levelは間隔をあけた値で設定されており、あとで任意のレベルを追加できるようになっている

const (
	LevelDebug Level = -4
	LevelInfo  Level = 0
	LevelWarn  Level = 4
	LevelError Level = 8
)

- 作成者は、デフォルトのレベルをInfoにしたかった(Levelはint型なので、初期値が0)
- レベルの代わりに詳細度を扱いやすくしたかった
- レベルの間に余裕を持たせたかった
  • HandlerOptionsが存在しており、Handlerの設定をいじれる
    • AddSourceでログの出力元のソースコードの位置を表示できる
    • Levelで、ログに出力する最小レコードを設定できる
    • ReplaceAttrで、groupとAttrを受け取って、別のAttrに変換できる
      • パスワードなどのサニタイズに利用できる
かずかず

17

https://medium.com/@nikhi.unni/understanding-plugin-architecture-in-node-js-e3b97fc39abb

  • プラグインアーキテクチャについてNode.jsを例に説明

    • アプリケーションを実行する構造体を定義し、そいつにプラグイン一覧を持たせて、追加なども簡単にできるようにしている
    • アプリケーションの処理とプラグイン機能をバインドさせられるようにする: 記事では既存のEventパッケージを利用していた
    • プラグインのInterfaceを定義
    • プラグインの実装

  • プラグインアーキテクチャのメリット

    • 物事を小さく分割できる
    • 変更と追加が簡単

  • プラグインアーキテクチャのデメリット

    • プラグインを管理するための複雑性が存在する
    • セキュリティ的なリスクがある
      • システムにアクセスできる場所の制限をちゃんとしていないと、リスクあり
      • プラグインの吟味が不十分だったり
    • プラグインのロード・管理のオーバーヘッドがある
    • システムとプラグインの互換性がいつでも担保されるわけではない

https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md#interoperating-with-other-log-packages

  • ほかのパッケージとの相互運用について
    • このパッケージはほかのLogパッケージとの相互運用を期待して作られている
  • 1つ目の方法として、ほかのパッケージに、slog.Recordsを、slog.Handlerに送信すること
  • 2つ目の方法として、ほかのパッケージのバックエンド(ログの出力を取り扱うやつ)を、slog.Handlerとしてラップする

https://grafana.com/blog/2020/03/03/open-source-load-testing-tool-review/#about-the-review

  • 負荷試験に置けるツールの紹介とメリット・デメリットや、各ツール間のパフォーマンス比較などを行っている記事
  • 見てる感じは、k6sは悪くない選択肢ではありそう

https://k6.io/docs/using-k6/scenarios/concepts/open-vs-closed/

  • 負荷試験における仮想ユーザ(VU)の増やし方について、以下の2つが存在する
  • Closed Model
    • ほかのVUの完了を待って、新規のVUが立ち上がる
    • メリット: 指定した数のVU起動を維持できるので、リクエストの流れを制御しやすい
      • 最大想定人数での負荷を維持するなど
    • デメリット: 対象システムの応答時間で、スループットに影響が出る
      • 負荷試験のゴールが、一般的なスループットを評価することが目的の場合は向いていない
  • Opend Model
    • VUの起動を、ほかのVUの完了とは切り離す

ChatGPT-4oによる差分比較

モデル 説明 メリット デメリット ユースケース
Closed Model ユーザーが特定の間隔でリクエストを送信し、応答を待ってから次のリクエストを送信するモデル 現実に近いシナリオを再現可能、リクエストの流れを制御しやすい 高い並行性のシミュレーションが難しい、レスポンスタイムの影響を受けやすい ユーザーの動作を忠実に再現する必要がある場合
Open Model ユーザーが一定のレートでリクエストを送信し続けるモデル 高い並行性のシミュレーションが可能、システムの限界をテストしやすい リクエストの流れを制御しにくい、現実のシナリオとは異なる場合がある 高負荷のシミュレーションやシステムの限界テスト

https://k6.io/docs/get-started/resources/

  • k6を拡張するためのxk6sとかあるらしい
  • k6で、ブラウザの操作を記録して、シナリオを作成するツールがありそう
かずかず

18

https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md#testing-package

  • Testing Package
    • Handlerをテストするために、testing/slogtestパッケージを提案している
    • それは一つの関数のみを公開している
      • TestHandler(h slog.Handler, results func() []map[string]any) error
    • slog.Handlerを内部的に、loggerに組み込んでloggerの各メソッドを実行して、resultsの結果が一致するかをチェックする
  • このProposalの作成にあたって、作成・改善などに役立った・助けられたことについて記載している
かずかず

19

https://github.com/gofr-dev/gofr

  • Gofrという、意見が強いマイクロサービス開発向けのフレームワークが存在する

    • マイクロサービス開発の簡易化が目的
    • Kubernetesでの開発にフォーカスをあて、可観測性の提供を目指している

  • 機能の特徴として、以下があげられている: ほかにも色々ある: PubSubとか

    • シンプルなAPI構文
    • デフォルトでのREST標準
    • 設定管理
    • 内臓ミドルウェア
    • gRPCのサポート
    • ヘルスチェックとサーキットブレーカーをサポートするHTTPサービス

  • ドキュメントがしっかりとしてそう

  • CNCF Native Landscapeにもリストされている

  • これは分散トレーシングを実現するために、内部的にOpenTelemetoryを使っている

  • ドキュメント読んでる感じ、ほかにも内部的に色々用意されていそう

    • redis client・mysql sql client(マイグレーションも行える感じ)・tracing・Pub /Sub

  • Pub/Subとしては、Kafka・Google Pub/Subをサポートしている

  • DBドライバーを注入できるようになっている

  • Swaggerドキュメントを自動的にレンダリングする機能がある

かずかず

20

https://zenn.dev/cybozu_frontend/articles/react-aria-component-design

  • React Aria ComponentsというAdobeが提供しているheadless UIのコンポーネントライブラリがあるらしい
    • headless UIとは、UI要素やインタラクション時のロジックなどのAPIのみを提供するライブラリやユーティリティ
      • デフォルトのスタイルを持たないので自由にスタイルを設定できる
  • コンポジションを中心に設計されている
  • Contextなるものを利用して、親のContextからpropsとrefを取得 & マージしてそれを提供している?
    • これを利用することで、コンポーネントの内部状態を、独自でいじることが可能になる
かずかず

21

https://qiita.com/Sicut_study/items/64902c228c0438f748d2?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

  • react * voice vox * gpt-4oで音声チャットアプリを作成
  • reactで音声入力のためのライブラリとして、react-speech-recognitionというライブラリが存在する
  • AI側の音声として、非公式のVoiceVoxAPIが存在する
    • これじゃなくて、ローカルで利用するように工夫すれば会話の応答性も結構上がりそう
  • 応答の内容の作成については、gpt-4oを利用する
    個人的には、LangChainのMemoryとかを活用すると、結構いい感じのが出来上がる可能性もある?
かずかず

22

https://zenn.dev/bmth/articles/react-confirm-dialog

  • render hooksパターンなるものがあるらしい
  • useRef・useImperativeHandle・forwardRefとかの機能がreactにはあるらしい
  • 記事の内容的には上記を使って、確認ダイアログの状態管理を隠蔽し、Render Hooksパターンの問題も解消する実装について説明している
    • この記事の手段を利用することで、確認ダイアログの状態管理から解放されて、見た目や挙動の実装に集中できる
かずかず

28

https://zenn.dev/cybozu_frontend/articles/next-react-compiler

  • react compilerによって、内部的にMemo化が勝手に行われるようになり、再レンダリングの最適化がされる

https://speakerdeck.com/satoshi256kbyte/dbdiao-cha-wosiyasukusuru-ahurikesiyonnorokuchu-li?slide=2

  • DBのログ
    • 更新 & 削除件数・トランザクションはDEBUG or INFOで出力する
    • SQLはDEBUGかつ、バインド変数ではなく完成系で出力する
      • 完成系だと、EXPLAIN関数でクエリの実行内容について解析できるため
    • ログフォーマットの中に、時間・ログインID・セッションID・リクエストIDなどを含める
  • AWSのRDSにおけるPerfomance Insightsはサポートへの問い合わせに有用らしい