#アーキテクチャ

@kemuniku / 8日前

PyPyのListStrategyまとめ

• PyPyではリストの内部構造を戦略に応じて変更して最適化している
• ObjectListStrategy、IntegerListStrategy、FloatListStrategy、AsciiListStrategy、BytesListStrategy、EmptyListStrategy、SizeListStrategyの7種類の戦略が存在する
• リストの要素の種類や操作によって戦略が変化し、特に整数や浮動小数点数の範囲によって戦略が切り替わる

@mylifewithviolin / 8日前

日本語プログラミング言語あおい（Aoi）最小セットの検証フェーズ（ステップ５）～線形探索法、二分探索法のC#コード生成～

• 日本語プログラミング言語あおい（Aoi）で線形探索法と二分探索法のC#コード生成が完了した
• Lexerの演算子対応、Parserの式構文対応、SemanticResolverの名前解決、CSharpCodeGeneratorの制御構造出力が実装された
• C#コンパイラでビルド確認を行い、コンソール出力の型変換エラーが1件残るが構文は正しい

@miruky / 8日前

AI駆動系の◯◯エンジニアリングが多いので、ここらで一旦整理しましょう。プロンプト、コンテキスト、ハーネス、ループ、グラフエンジニアリングについて。

• プロンプト、コンテキスト、ハーネス、ループ、グラフエンジニアリングの違いが説明されている
• プロンプトエンジニアリングは指示文の工夫、コンテキストエンジニアリングは情報の選別、ハーネスエンジニアリングは作業環境の整備、ループエンジニアリングは作業の再実行、グラフエンジニアリングはワークフローの設計
• コンテキストエンジニアリングでは無関係な資料を避け、必要な情報のみを渡すことが重要で、ハーネスエンジニアリングでは作業環境と制限を設定する

@blinkgroup_jp / 9日前

Flaky Test（不安定なテスト）の主な原因と実務で使える具体的な改善手順・チェックリスト

• Flaky Testの主な原因と改善手順が解説されている
• 非同期処理の同期ズレ、テストデータの競合、時間依存処理、環境依存が原因。オートウェイティングやテストデータの独立性確保が対応策
• テストのリトライ機能を過度に頼らず、テストデータの独立性を確保する運用ルールを設けることが重要

@Relu / 9日前

React Router の新しい useRouterState で Pending UI を考える

• React Router v7.15.1でuseRouterStateが追加され、pendingでparams、matches、typeが取得可能になった
• pending.paramsは遷移先のパラメータ、pending.matchesは遷移先のルート階層、pending.typeは履歴操作の種類を取得できる
• pending.paramsでスケルトン表示のUIを遷移前に解決し、pending.matchesでスケルトンの範囲を絞り込み、pending.typeでアニメーションの出し分けが可能になる

@Watanabe Jin / 10日前

ドメインの変換はHandlerとUseCaseのどちらでやるべきか

• ドメインオブジェクトの生成はUseCaseで行うのが一般的
• Handlerで生成するとドメインが外のロジックに影響され、UseCaseで生成すると業務ロジックとドメインルールの境界が明確になる
• HandlerはUseCaseの入力パラメータまでを知るだけで、ドメイン生成ロジックはUseCaseに集約する

@jota9613 / 10日前

わからなかった単語をまとめてみた

• 要件定義、モノレポ、モジュールの定義と違いを解説した
• 機能要件と非機能要件の2種類、モノレポは1つのリポジトリに複数プロジェクトをまとめる、モジュールは関連コードを部品化する
• 要件定義では機能と品質の両方を明確にすることが重要で、コード構成ではモジュール化で管理性を高める

@Sicut_study / 10日前

エンジニア不要論の真実！AIの進化と具体抽象から完全解説

• AIの進化によりエンジニアの仕事は具体と抽象の分かれ道に
• 具体のタスクはAIに代替され、抽象的な問題解決が重要になる。SIerの下請け構造では上流工程が元請け、下流が下請けで、AIが具体を代替する
• 抽象的な設計力がなければAIに仕事を奪われる。ドメインモデリングが問題解決の鍵で、言語化できないとAIに渡せない

@mizchi / 11日前

jev-lint: コード中の命名やコメントが嘘になってないかを高速に確認

• jev-lint が公開され、コードの命名やコメントの整合性を確認するツールとなった
• ast-grep でコードを抽出し、自然言語ルールでスコアを評価する。関数名と実装の一致、テスト名と内容の一致、コメントの整合性を確認できる
• スコアリングの再現性に制限があり、LLMの性能に依存するため、閾値を調整して再採点する必要がある

@Jospin / 13日前

決済の例で理解するDIP（依存性逆転の原則）

• DIPを適用することでOrderServiceがStripePaymentに依存するのではなく、抽象インターフェースに依存する
• OrderServiceはPaymentInterfaceに依存し、StripePaymentはそのインターフェースを実装する、依存関係の向きを逆転させる
• 具体的な実装を変更する際、高レベルモジュールを変更する必要がなくなるため保守性が向上する

@yu_asa / 13日前

FlywayでDDLを管理する ― VとRの使い分けと、ビュー・トリガーの扱い

• FlywayでDDLを管理する際、Vは1回だけ実行されるマイグレーション、Rは中身が変わるたびに再実行されるマイグレーションとして使い分けられる
• Vはテーブル作成などの積み上げ変更に、Rはビュー作成やトリガー定義などの作り直し可能なオブジェクトに使用する。ビューはCREATE OR REPLACE VIEWでRに記述する
• Vファイルは適用後は変更不可で、Rファイルは中身の変更に応じて自動再実行されるため、ビューとトリガーはRで管理する

@hacchi_no_donburi / 13日前

AWS AI-DLC Unicorn Gymに参加して感じた、AI時代に開発者の仕事はどう変わるのか

• AWS AI-DLCではAIが判断点を提示し、人が意思決定と検証を行う
• AI-DLC Workflows v2は決定論的なエンジンで進行を管理し、AIが実行を担当する
• 開発者は判断の背景やリスクを次の工程に引き継ぐ必要がある

@haruki_nakayama / 13日前

AI 駆動開発に変更管理を組み込んだ話

• AI駆動開発に3ファイルによる変更台帳を導入した
• impact.mdで影響マップを、decisions.mdで判断記録を、closure.mdでクローズ前チェックを実施
• 変更の経緯がチケット単位でリポジトリに残り、後から確認できる仕組みになっている

@AIフクロウ｜夜な夜なClaude Code / 14日前

自作ツールに散らばった print デバッグ48行を、Claude Codeに7分20秒で4レベル固定(ERROR/WARN/INFO/DEBUG)のログ方針表20行＋共通フォーマット5項目にしてもらった夜

• 自作ツールのprint出力をClaude Codeで4レベルのログ方針に整理した
• ログレベルはERROR/WARN/INFO/DEBUGの4つ、共通フォーマットは時刻/レベル/イベント名/文脈キー/メッセージの5項目
• 48行のprint出力を20行の方針表にまとめ、消すを4行含む

@a.kobayashi / 14日前

1年半かけて育ててきたAI開発フロー

• AIが自走する開発フローを構築し、人間の判断を仕様決定と最終確認の2回に絞った
• サブエージェントによる工程分離と、メインエージェントによる判断ルールの設定、仕様ドキュメントの活用
• 人間の判断をルール化してAIに渡すことで、開発フローを自動化できるが、ルールの明確さが重要

@Kou / 14日前

「【PHP】in_arrayはもう古い？配列探索を10倍高速化する「isset」の衝撃」～【php】人気記事TOP5（2026/09/13）

• PHPの配列探索を10倍高速化する方法が紹介されている
• ハッシュテーブルの特性を活かしたisset使用とarray<int, true>のデータ構造
• in_arrayより10倍速い探索が可能で、実務で即座に導入できる

@Jagmeet Singh / 14日前

元インフォシスCEOのAIスタートアップが5300万ドルを追加調達

• 元インフォシスCEOが設立したAIスタートアップが5300万ドルを追加調達
• Xoraがリードするシードラウンドで合計8500万ドルに、Hobieという社内フレームワークを活用
• 企業向けにAI戦略のアドバイスとソフトウェア構築を提供し、従来のシステム統合企業と競合

@tomokusaba / 14日前

「AI があればプログラマーはいらない」という風潮が危険な理由

• AIがコードを書けるようになっても、プログラマーの役割は変わらない
• AIは局所的な問題解決に強み、プロダクト設計や運用の判断は人間が行う
• AIに任せたコードが要件に適合しているかを人間が評価する必要がある

@jnishime / 15日前

プロダクトエンジニアに必要な「いい感じ」に作る能力

• プロダクトエンジニアはプロダクト・顧客・組織の状況を見て「どこまで作るか」を決める
• 過去のコード構造や顧客の利用タイミング、他チームの意向を考慮し、検索機能を実装しない選択をした
• 実装中に得た情報をもとに、関係者に早めに相談することで、無駄な作業を減らせる

@ksonoda / 15日前

[入門]グラフエンジニアリングのクイックスタート

• グラフエンジニアリングは複数エージェントの処理フローをグラフ形式で定義する手法
• ノードとエッジで構成されるグラフデータモデル、条件付きエッジによるループ処理
• 処理完了の判定をLLMではなく決定論的なコードで行うことでハルシネーションを防ぐ