document.querySelectorAll の結果を map や reduce したい

document.querySelectorAll の結果は NodeList で、forEach はできるが mapreduce はできない。

例えば、いくつかのテキストボックスに入力された数字を合計したい場合、document.querySelectorAll の結果をスプレッド構文で配列にするとよさそう。

const sum = [...document.querySelectorAll('.foo')]
        .map(e => e.value)
        .reduce((acc, e) => acc + parseInt(e), 0)

(追記) ドキュメントに書いてあった...。

NodeList - Web API | MDN

メモ: NodeListArray とは異なりますが、forEach() メソッドで処理を反復適用することは可能です。Array.from() を使うことで Array に変換することができます。

任意の文字列の登場回数をカウントしたい

備忘録。任意の文字列の登場回数をカウントしたい。grep-r を付けてディレクトリ配下を再帰的に検索する。

-o は条件に合致する行を出力する。これを wc でカウントする。

$ grep -or "hogehoge" . | wc -l

-o の代わりに -c を使うとカウントした結果をファイルごとに出力できる。

$ grep -cr "hogehoge" .
./path/to/foo.txt:3
./path/to/bar.txt:7

名前に任意の文字列を含むファイルを検索したい + ファイル数をカウントしたい

備忘録。名前に任意の文字列を含むファイルを検索したい。

OR 検索する場合は \| のようにバックスラッシュを入れる。

$ find . -type f | grep -e "foo*\|bar*"

ファイル数をカウントしたい。

$ find . -type f | grep -e "foo*\|bar*" | wc -l

モジュラモノリス徹底解剖 〜実践者から学ぶ Lunch LT〜 に行ってきた #モジュラモノリス_findy

モジュラモノリス徹底解剖 〜実践者から学ぶ Lunch LT〜 に参加しました。オンライン参加。簡単に所感をまとめます。

findy.connpass.com

所感

モジュラーモノリス検討中ですっていうひとが思ってたより多かった気がする。Go の Workspace mode はモジュラーモノリスを実現しやすい仕組みなんだろうか。言語レベルでそういうのサポートしているのよさそう。

モジュールの依存関係はコンテキストマップを踏襲する。あと、DB を分割しておくとマイクロサービスにも移行しやすい。なるほど。

マイクロサービスが負債になるっていうのは心に留めておきたい😇

以下、メモから抜粋。

非モジュラーモノリスからモジュラーモノリスへのステップ

  • チーム分割しても生産性を維持したい
  • 分散トランザクション
  • モジュラーモノリス構成
    • モジュールごとにディレクトリ切る
    • モジュール API 公開
    • 少しずつモジュール化する
  • BFF
  • モジュール間は循環依存しないように
  • モジュール間の RDB 分離
    • 外部キー張ってたりするので難しい
  • モジュール間のトランザクション
    • 基本的にはないように
    • 仕様見直し
  • モジュール粒度
    • 最初はなるべく小さく
    • 小さいモジュールをまとめてモジュール化

RDRAとDDDでGoのモジュラーモノリスアプリを設計してみた話

  • RDRA
  • 戦略的DDD
  • コンテキストマップごとの設計資料
  • Workspace mode (Go)
    • モジュール間の依存解決
  • コンテキストマップと同じ粒度で Go Module を作成する
  • マイクロサービス
  • 新規なのでDB分割はやりやすかった

TypeScript・モジュラーモノリスによる型安全なWebサービス開発

  • 複雑なサービスをシンプルなモジュールを組み合わせて作り上げる
  • 垂直分割=ドメインごとに分割
  • 水平分割=レイヤごとに分割
  • コアロジックを外に抽出
    • 凝集度が高い
    • FE/BEにロジックが分散しないように
  • Turborepo
  • 関数を export する
    • モジュール間は関数呼び出し
  • ドメインロジックを書くべきところに書く
  • ビルド, Lint はパフォーマンスわるい
  • 初期構築の難易度が高い
  • モノリポと相性いい

マイクロサービスではなくモジュラモノリスを採用した理由

  • 既存システムの技術負債
    • 新機能を別システムで作る
    • 既存システムを少しずつ移行
  • マイクロサービス
    • 整合性担保が難しい
    • マイクロサービスが負債になる
  • モノリス
    • 内部品質を保つには設計スキルが必要
    • 将来的にマイクロサービスに移行しづらい
  • モジュラーモノリス
  • モジュール境界はサービス境界に比べて戻しやすい
    • サービス境界を探る

モノリスとマイクロサービスを経てモジュラモノリスを導入した実践事例

tech.asoview.co.jp

eh-career.com

  • マイクロサービス
    • 認知負荷/コミュニケーションコスト軽減
    • 自立自走
  • モノリス
    • プロダクト全体にわたる変更
  • モジュール境界
    • RDRA
    • DDD (境界づけられたコンテキスト)
    • リソース/可用性などの非機能面の観点
    • 組織構造を意識しすぎると組織変更についていけなくなる
    • 組織構造が変わっても大丈夫なように
  • DB分割
  • トランザクション分割
  • ランタイムは同一
  • 可用性
    • 単一障害点
    • シングルバイナリ/マルチモード
  • アプリケーションレベルのリファクタリングが可

Argo Workflows ドキュメントリンク集

Argo Workflows を使うときによく参考にするドキュメント。備忘録。

やや古い資料ですが、全体的に分かりやすく解説されておりいつも参考にしています。

speakerdeck.com

細かい内容は公式ドキュメントの Field Reference とか。(あまり見やすくはない)

argoproj.github.io

その他、GitHub の examples とか。

github.com

JSUG勉強会2023その2 クレディセゾンでのSpring・AWS活用事例に行ってきた #jsug

JSUG勉強会2023その2 クレディセゾンでのSpring・AWS活用事例 に参加しました。オンライン参加。簡単に所感をまとめます。

jsug.doorkeeper.jp

所感

こういう移行プロジェクトっていろんな前提や制約があってなかなか思ったようには進まないもので、トレードオフだったり現場のアイデアが詰まってるはず。今回そういう話が聴けてよかったです。昔、Seasar2 から Spring に移行したときのことを思い出した。

単純なインフラ/フレームワークの移行だけじゃなくて、メトリクス取れるようにしたりサーキットブレーカー導入したりしててすごい。

移行と関係ないけど、サービス間の接続に Git のコミットハッシュ使うのよさそう。あと、Karate は初めて聞いた。

以下、メモから抜粋。

Springを武器に闘うレガシーアーキテクチャ 〜オンプレ/EJB2からのEKS/Spring Bootへの移行奮闘記〜

  • オープンGW
  • AWS, EKS, Aurora PostgreSQL
  • G.M.ワインバーグ
  • コアとなる業務ロジックは変更しない
  • 開発/運用しやすくしてから改善する
  • フレームワーク
  • Spring 管理下にする
    • Spring の機能が利用できるように
  • テスト
    • 対象を絞る
    • E2Eによる外部仕様の原新比較
      • 既存システムの通信ログからテスト作成
      • Karate
        • 自由度が少ないので記述がブレにくい
  • 保守/運用
  • EKS
    • プラットフォーム
    • k8s はシンプルな設計に保つ
    • k8s で足りない部分は Spring の機能を活用する
    • デプロイ容易性
    • IaC
      • CDK (Java)
        • 環境ごとに yaml に外部定義
        • Java で読み込んで CDK で構築
      • eksctl + config ファイル
    • blue/green
  • クライアントサイドロードバランシング
  • オブザーバビリティ
    • fluent-bit
    • firehose > S3
    • メトリクス
      • Prometheus > cloudwatch agent > cloudwatch logs
  • 無停止ローリングアップデート
    • Liveness Probe, Readiness Probe
    • CommandLineRunner ウォームアップ
      • ピーク時にロールアウトリスタートしても性能問題ないように
      • ロードされてないクラスをロードしたり (servlet リクエストしたり)
      • キャッシュ生成
  • Git のコミットハッシュを利用してイメージタグを付与
  • AWS VPC Lattice
  • ドキュメントを絞る
  • バージョンアップ
    • 自動テストがあると安心