#アーキテクチャ
@iketani45664566 /
- 3層アーキテクチャのプレゼンテーション層・アプリケーション層・データ層の役割と構成が説明されている
- プレゼンテーション層はWebサーバー、アプリケーション層はAPサーバー、データ層はDBサーバーで構成される。ステートレスなアプリケーション層の設計が重要
- アプリケーション層に状態を保持しないことでスケールアウトが可能になる。データ層はネットワークで隔離する
@Hiruge /
- Go Conference 2026でOSS活動や標準ライブラリの設計、range over funcの導入が紹介された
- OSS活動の継続理由や標準パッケージの採用基準、range over funcの仕組みとその歴史が語られた
- Goの標準ライブラリの内部仕様を調査する重要性や、range over funcの実用例が実際の技術選定に影響を与える可能性がある
@nagi-0106 /
- ReactコンポーネントとCMSモジュールは再利用目的は同じだが設計思想が異なる
- コンポーネントは機能分割で粒度が細かく、モジュールはテンプレート断片で粒度が粗い。データ受け渡しはpropsと変数の違いがある
- CMSモジュールはテンプレート内変数で暗黙的にデータを受け取るが、Reactはpropsで明示的に渡す必要がある
@【PRONI】テックブログ /
- AI駆動開発でSDDを活用する際、DiscoveryとDeliveryでは先に定義すべきものが異なる
- Deliveryでは受入基準を先に定義し、Discoveryでは学習条件を先に定義する
- 価値仮説と実装要件を区別しないとエージェントが誤った実装を進める可能性がある
@Ohmiya-Mizuki /
- 個人開発でクリーンアーキテクチャを採用する価値はプロジェクトの性質に応じて変わる
- 外部依存の数と変更の独立性、テストのしやすさ、開発の継続性の3つの基準を満たすプロジェクトに価値がある
- 外部サービスへの依存が2つ以上あり独立して変更される可能性があるプロジェクトでは採用を検討すべき
@天野 学 /
- AIがコードを書く時代に設計の役割が重要になる
- 業務ドメインで区画し、依存の向きや公開範囲で境界を縛る。ArchUnitでガードレールを設ける
- 共有ファイルへの衝突を減らすため、DDLや画面の所有権を明確に設定する
@mizzsugar /
- 共同編集機能を実装する際、リアルタイム性を諦めてバージョン管理と軽量な工夫で対応した
- バージョン管理は保存＝バージョンの単純モデル、ポーリングによる通知と編集中ユーザーのアイコン表示、バックアップ機能を組み合わせた
- リアルタイム性を諦めることでインフラ変更や工数を最小限に抑え、社内アプリの小規模な同時編集に適した実装が可能になった
@ito_kohhh /
- セキュリティを機能として捉えるのではなく設計によって安全性を高める考え方を紹介
- セキュリティを設計段階で考慮し、ドメインモデルと多層セキュリティを重視
- セキュリティ対策を設計段階で行い、状態の完全性を保つことが重要
@wfukatsu /
- 2ヶ月半の空白期間中に151件の型エラーが発覚し、リリース可能性が遅れていることが判明
- 型定義ドリフトによるエラーとCI導入前のビルド不具合、151件の型エラーの原因は3つの未追随
- リリース準備のためのCI導入は102日目に行われ、型検査で151件のエラーが確認された
@kaiinaba /
- Power Automateでループ処理を避けて計算で処理速度を改善する方法を紹介
- Do untilによるループ処理と、Nを2で割って切り上げる計算式の比較、変数更新回数の削減
- 処理件数が増えるとループ処理は時間がかかるため、計算式で置き換えると大幅に改善する
@GENDA 公式アカウント /
- クロスボーダーM&Aの価値向上を支えるプロダクト開発の実践が紹介された
- 時差や法規制、デザインの非対称性といった課題と、日英ペアの設計ドキュメント作成、直接のコミュニケーションの重要性が挙げられた
- プロダクトエンジニアが日米チームをつなぐハブになるための仕組みづくりと、直接のコミュニケーションの両輪が重要だと示された
@suneo46 /
- 1年目のバッチ実装で3ヶ月かかった経験を振り返り、分からないことを整理しなかったことが原因だった
- 分からないことを書き出すことと、必要な部分だけ理解すること、調べる際の整理が重要だった
- 分からないことを言語化してから調べることで、解決への道が開ける
@いまいまい /
- コードの設計やコメントの書き方、知識の更新方法を個人的に重視している
- 拡張性を標準とし、知識の鮮度を確認するためのWebSearch、コメントは直下のコードだけを説明する
- 古い知識は有害なのでWebSearchで確認し、コメントはコードの理解を助けるために名前や構造を変更する
@suzukielecs /
- Pythonに標準で用意されたbreakpoint()でコードを一時停止できる
- breakpoint()はpdbを起動し、p/n/s/c/qの5つのコマンドで変数確認や実行制御が可能、PYTHONBREAKPOINT環境変数で無効化やデバッガ変更が可能
- 本番コードに残すとCIで固まるリスクがあるため、実行後に削除するかPYTHONBREAKPOINT=0で無効化すること
@wfukatsu /
- コードレビューの在庫を280枚のMarkdownファイルで管理し、状態と優先度を明記することで課題の可視化と優先順位付けを実現
- 1ファイル1指摘のフォーマットで選択肢A/B/Cを提示し、人間が採否を判断、複数のレビュアーが異なる観点から指摘
- 連番で束ねてPRにまとめることでコンフリクトを減らし、解決した課題はdocs/solutionsに具体例とともに記録
@nolanlover0527 /
- 配列の添字は0から始まる理由がメモリ効率と数学的簡潔さから説明されている
- メモリアドレス計算で0始まりが効率的で、ダイクストラの論文で数学的区間表現がシンプルになる
- C言語のポインタ演算が0始まりを広めたことが明記されており、言語設計の選択肢としての背景がわかる
@日下部 聡久 /
- QA活動はテスト実行以外にも要件レビュー、設計レビュー、リスク評価、メトリクス活用などがある
- 要件レビューで曖昧な仕様を防ぐ、変更リスク評価で重点テスト箇所を特定、メトリクスで品質傾向を可視化
- バグ分析から傾向蓄積までを回すことで同じ失敗を繰り返さない仕組みを構築できる
@dach /
- AIレビューとCIの結果をもとに人間レビューの深さを3段階で判断するフローを紹介
- Level1はPR内で判断が閉じる、Level2は後続確認を残す、Level3はPR外の根拠を調べる
- AIレビューの条件やCIの結果が揃っていればLevel1で終わる、後続確認が必要ならLevel2、PR外の根拠が必要ならLevel3に分ける
@まっさん | TOKIUM /
- Claude Codeの品質改善にevalを活用し、ログを元に失敗を観測して改善するプロセスを紹介
- ログを自動収集して失敗を分類・数えることでevalを作成し、発動率を52%から78%に向上
- evalは正解データを用意せず、実際の失敗を観測して作成するべきで、発動すべきでないケースも評価に含める
@songchong /
- MCPとAPIの違いを調査し、APIが依然として重要であることを示した
- MCPはAIエージェント向けに設計され、APIは人間向けに設計される。MCPは動的自己紹介機能を持ち、APIは静的仕様書に依存する
- MCPは既存のAPI基盤に依存し、APIが存在しない場合はまずAPIを作成すべきである
