2025.11.10 覚書 / 2025.11.10 memo's
自分が参考になったブログの紹介します。 / Here are some blogs that I found helpful.
Angular
- Angular v21 のリリース“アドベンチャー”が 2025年11月20日 を予定していることを案内しています。
- 「モダンな AI ツール、パフォーマンス更新など、エンタープライズにもスケーラブルなアプリ構築に最適な時期」だとしています。
- v21 ではフォーム関係に「Signal Forms（シグナルを用いたフォーム）」「ARIAパッケージ強化」などが紹介されています。
- 開発者体験（DX）と開発ワークフローを改善するための「コード生成」などツール面の改善にも言及されています。
ChangeDetectionStrategy.OnPushの活用（デフォルトの変更検知ではなく、入力変化のみチェック）- Signals を使ったリアクティブ更新（Angular 20以降）
- 可能な限り “遅延読み込み（Lazy Load）” を活用してモジュール／機能を分割する
- テンプレート内で関数呼び出しを避ける（変化検知時に無駄な再実行を防ぐ）
*ngForでtrackByを使い、リストの再描画を最適化する- 重いライブラリやモジュールを動的にインポートして、初期バンドルを軽くするコード分割の活用
- ビルド時の AOT、ツリーシェーキング、ミニファイ、ソースマップ解析などを意識する
- サービスワーカーやキャッシュ活用、オフライン対応も UX 改善に寄与する点
- 結論として「複雑なハックではなく、フレームワークの基本機能を賢く使うことで大きな差が出る」と述べています。
- 主なポイント：
- Signals（シグナル）が“今や無視できない”レベルで強化されており、手動サブスクリプションや
ngOnChangesに頼る必要が少なくなった。 - レガシーな Angular アプリを改修した際に、「zone.js による過剰な変更検知サイクル」から解放された経験が紹介されています。
- Signals（シグナル）が“今や無視できない”レベルで強化されており、手動サブスクリプションや
- つまり、Angular 20 は「リアクティブな記述」「パフォーマンス改善」「開発体験の向上」においてひとつのマイルストーンであるという主張です。
- 従来、Angular では HTTP Client＋RxJS の Observable を使って非同期データ取得を行ってきたが、Signals を用いたリアクティブな状態管理を進める中で、「この構文をもっとシンプルにする」ために Resource API が設計された。
httpResource()という API を例示。HttpClientを用いながら、シグナルベースでデータを取得・監視できる形。- この API はまだ 実験的（執筆時点 Angular 20.3）という注意。
- 記事は、この API により「Observable と Signals の橋渡し」「コードの簡潔化」「リアクティブなデータ取得の新しいパターン」が可能になるという点を強調しています。
- Angular 開発においてコードの質（可読性／保守性）を上げるために、導入すべき ESLint ルールを7個挙げています。
- 例として、「シグナル（Signals）を呼び出す際に
()を忘れないようにするカスタムルール」の紹介があります。 > “How many times … have you forgotten to add()when accessing an Angular Signal?” ([JavaScript in Plain English][6]) - また、既存コードベースへのルール導入を阻む「フリクション（摩擦）」を最小限にするための手順（まず警告として、段階的にエラーに移行）なども触れられています。
- 意図として、ルールを“単なるチェック”ではなく、チーム全体の品質文化として定着させるべき、という点が訴えられています。
- 開発環境をゼロから構築する手順を詳細に説明：Node.js／npm のインストールから。
- @angular/cli のグローバルインストール方法と、バージョン互換性についての注意点。
- 新規プロジェクト作成、その後の
ng serveなどの開発サーバ起動手順。ポート指定やホットリロードなど開発時の実践的なコマンドも紹介。 - 環境ファイル (
environment.ts等) を使ったマルチ環境設定（開発／テスト／本番）とangular.jsonによるビルド設定。 - よくあるトラブルとその対処例：ポート競合、グローバルインストール時の権限問題。
- 全体として「初心者でも迷わず始められる Angular プロジェクトの構築手順」が整理されている。
- Angular におけるコンポーネントの基本概念を解説：テンプレート、クラス、スタイル、メタデータ（デコレータ）という構成要素。
- コンポーネントの役割と利点：「再利用性」「保守性」「カプセル化」「構成性」など。
- 開発効率の向上を目的に、VS Code用プラグイン（Angular Generator）を使ったコンポーネント自動生成の手順を紹介。
- 具体的な “user-profile” コンポーネントを例に、生成されるファイル構成（
.ts、.html、.less、.spec.ts）やコード例を提示。 - 親コンポーネント内での子コンポーネントの使い方（インポート／
imports配列／セレクター利用）について。 - ベストプラクティスとして、セレクターの命名規則（例：
app-プレフィックス）、ファイル名・クラス名規則（小文字＋ハイフン、パスカルケース）などを示しています。 - まとめとして、コンポーネントベース開発の思想 (“複雑な UI を部品化・組み合わせる”) を強調。
- JavaScript（ECMAScript）において “ES2025” 世代に向けた提案・新機能が登場しており、フロントエンド開発者として知っておくべき変化だと紹介されています。
- 記事では、パイプ演算子、パターンマッチング、タプル／レコード構文など “言語レベルでの再思考” が進んでいるという主張があります。
- ただし、HN（Hacker News） の議論では「この記事の多くが実際には提案段階／暫定仕様で、誇張されている」という指摘も出ています。 ([Hacker News][8])
NgRx
- 長年 NgRx を「状態管理の正道」と考えてきた筆者が、Angular Signals を使ったモジュール改修で “信仰” を揺るがされた体験を語っています。
- ダッシュボードモジュールを Signals ベースに書き換えた結果、レンダリング回数が70%削減され、バンドルサイズも約42 KB減ったという具体的な数値が提示されています。
- 従来の NgRx ストア構成 (“アクション → リデューサ →エフェクト” の3点セット) が複雑になりすぎており、新人エンジニアの立ち上がりに時間がかかったという反省も。
- Signals による “シンプルにリアクティブ” な実装が、コード行数削減、メンテナンス性向上、パフォーマンス改善につながったという主張。
- 一方で、NgRx を全否定するわけではなく、「ツールと設計思想を見直す機会になった」というニュアンスを含んでいます。
Rust
- Rust を使ってビルド時間を大幅に短縮した事例紹介。
- “Rust vs C – パフォーマンス、安全性、そしてシステムプログラミングの未来を巡るバランス” という論考記事。
- C 言語と Rust を比較して、どちらが「より良い選択か」を性能・安全性・今後のシステム開発観点から分析しています。
- Rust が所有権／借用といった言語機能を持ち、安全性・メモリ管理の面で優位にある点が述べられています。
- 一方で、C が長年蓄積されたエコシステムと成熟度を持つため、用途や既存資産次第では依然選択肢として残るというバランス観もあります.
- 競技プログラミング（AtCoder など）で「速いコードを書く」ためのメモ的記事。
- まず注目するのは「アルゴリズムを変えること」が最も効果的であり、小手先の高速化よりも効率良い手法／構成に切り替えるべきという記述。
- プロファイリングの重要性：ボトルネックでない箇所を高速化してもあまり意味がないこと、
valgrind / callgrind / cachegrind等を利用して解析することが推奨されています。 - アセンブリを読むことで「なぜ思った通り実行速度が出ないか」を理解する手段として紹介。
--emit asmやobjdumpの活用例あり。 - 入出力の高速化：標準
println!等よりも塊で書き込めるバッファ利用やStdoutLock等を用いた実践的な改善案。 - 型選びの重要性：配列アクセス時に
usize／i64を乱用せず、データ量に応じて適切な型（例：u8）を使ってキャッシュ効率・メモリ効率を改善。 - Rust 標準の
HashMap/HashSetが競プロでは遅くなるケースがある、rustc_hash::FxHashMap等の代替を検討すべきという提案。 unsafeを使いすぎることへの警鐘：「速くなると期待して乱用しても効果が薄いことが多い」と記載。- その他、
sort_unstableの活用、SIMD・ターゲット機能 (#[target_feature(...)]) の話など、少し高度な高速化テクニックも紹介。
RxJS
- RxJS（リアクティブ拡張ライブラリ）について、「なぜ JavaScript コミュニティで大規模に採用されなかったか」をテーマに考察しています。
- 記事では、RxJS が解決しようとする「プログラミング課題」が、実際の JavaScript 開発にとって必ずしも“明確な痛み”ではなかった、という視点が示されています。
- つまり「技術的には強力だが、普遍的に ‘必要なもの’ ではなかった」という立ち位置が論じられています。
- RxJS 自体の価値を否定するものではなく、使用／非使用の判断軸を再検討する材料として興味深い記事です。
