Scraps 最終更新 2026/10/02 09:10

記事一覧 新着順

@Relu /

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でアニメーションの出し分けが可能になる

@Judgment Log /

話題のChatGPT Astra、オーバーエンジニアリングが過ぎる件について

  • ChatGPT Astraが頼まれていない作業を勝手に広げ、トークンを無駄に使う問題が指摘された
  • オーバーエンジニアリングの設計やエージェント構成を説明し、余計なトークン消費と時間の無駄が生じた
  • AIに依頼する際は作業範囲を明確にし、追加作業は理由を説明して承認を得るプロンプトを設定すべき

@ishi720 /

妖精が飛んでいるかのような幾何学模様をJavaScriptで作ってみた

  • JavaScriptで六角形の辺を往復する点から線の交点を計算してアニメーションを作成した
  • 点の往復移動と法線ベクトル、線の交点計算、グラデーションによる軌跡描画が使われている
  • 線の交点を計算するアルゴリズムと軌跡の描画方法が実装のポイントとなる

@Noa /

AIイラスト|アニメの女の子を作ってみた【プロンプト3選】Gemini|PixAI |Nano Banana

  • GeminiとPixAIでアニメの女の子イラストを生成し、プロンプトの調整で結果を改善した
  • 英語と日本語のプロンプトで生成したイラストの違い、PixAIのレトロ2DアニメスタイルとGeminiのグラデーション修正、iPhoneでの編集
  • プロンプトの言語や調整方法で結果が大きく変わるため、複数のAIやツールを組み合わせて試すことが有効

@むーさん /

DynamoDBでベクトル検索を導入する際は既存のGSIの射影タイプの確認が大事だと思った

  • DynamoDBでベクトル検索を導入する際、既存GSIの射影タイプを確認しないと書き込みコストが4倍になる
  • GSIの射影タイプがALLの場合、ベクトルデータがGSI4本とベクトルインデックスに複製される。同居と分離の比較でWCUが24と6に差が出る
  • GSIの射影タイプがALLでベクトルを問題アイテムに同居すると、採点時のWCUが4倍になるため、ベクトルを別アイテムに分離する設計が有効

@Watanabe Jin /

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

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

@jota9613 /

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

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

@prozolic /

C# Kaigi 2026 参加レポート!!

  • C# Kaigi 2026でC#の進化や実装技術、開発ツールの話題が紹介された
  • C#の歴史とAI時代の.NET、Riderの開発環境、リアルタイムデバッガーの実装、Cloudflare WorkersでのC#実装が話題に
  • C#の最新技術や開発手法を学ぶ機会となり、実装に活かせる情報が得られた

@Uyuki_0409 /

【Vitest】テストを書いてみた~振る舞いを仕様として残す~

  • Vitestでテストを書く際、振る舞いを仕様として残す方法を紹介した
  • テストを前提・操作・結果の順で記述し、モック関数とReact Testing Libraryを組み合わせて画面の振る舞いを確認する
  • テスト名に「未ログインの場合、投稿後にログイン画面へ遷移する」と記述することで意図が伝わりやすくなる

@AIフクロウ|夜な夜なClaude Code /

育ちすぎて62行になったCLAUDE.mdを、Claude Codeに8分で4判定(効く/重複/曖昧/過剰)の診断表24行+31行の短縮版にしてもらった夜

  • CLAUDE.mdの62行を診断し、効く/重複/曖昧/過剰に分類した
  • 効く9行、重複5行、曖昧6行、過剰4行に判定し、短縮版31行を作成
  • 過剰と重複の行は削除可能で、削る理由が40字以内で明記されている

@beatapi /

JEV リポジトリを 100+ 件読んで分かったこと:真似すべきはモデル呼び出しの前後だった

  • JEVのモデル呼び出し前後のコードが100以上のプロジェクトで共通して重要だった
  • モデル呼び出し前のstate構築と後処理の検証、選択肢の重複回避、確率分布の利用
  • 選択肢が重なると閾値が意味を失うため、選択肢を重ねない設計が重要だった

@個人魔開発ラボ 阿修羅ワークス@フリーランスエンジニア /

AnthropicのMCPは2年足らずで時代遅れに AIエージェントが直接APIを叩き始めた

  • AnthropicのMCPサーバーが時代遅れになり、AIエージェントが直接APIを叩くようになった
  • MCPはツールの事前登録が問題で、モデルの進化により直接操作が可能になった。認証や状態管理には依然として有効
  • 単純なAPI呼び出しをラップしたMCPサーバーは不要で、使っていない設定を削除すべき

@heftykoo /

AIコード補完はTab一発で比べない。「近傍→別関数→別ファイル」の編集経路を測る

  • AIコード補完の評価にlocal/nearby/cross-fileの3段階の編集経路を導入
  • localは現在行、nearbyは同じfeature内の別関数、cross-fileは別fileの関連実装を対象にし、変更意図の届き具合を測る
  • 変更が予期した場所に届いていない場合、手修正が必要になる可能性がある

@shu15511551 /

言葉で頼んで AI 0 回・約 1 秒、手順書をマクロに焼いたら日々の業務から AI が消えた話

  • AIを毎日の作業員として使うのではなく、裏方の鍛冶場として活用することで、通信負荷を減らし、配布性を向上させた
  • AIにマクロを作らせて現場は言葉でマクロを先撃ちする、三十六行の関数でキーワード照合、手順書をマクロに焼く
  • AI通信を0回で処理が終わるようになり、アドイン一つで職場に配布可能になった