サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
こんにちは。カミナシで「カミナシ 従業員」の開発を行っている nilpoona です。 業務アプリケーションを作っていると、避けて通れないのがCSV インポート機能 です。 最初は「encoding/csv で読んでループ回せば実装できる」と考えて作り始めるのですが、仕様が複雑になるにつれて、以下のような課題に直面することがあります。 バリデーションとパース処理が混在し、エラーの発生箇所が追いづらい。 「文字コードが Shift_JIS だった」など多様なエンコーディングへの対応で、ビジネスロジックが複雑になる。 パースやバリデーションエラーを即座にリターンしてしまうと、ユーザーは一つのエラーを直してもまた次のエラーが出る「モグラ叩き」のような修正サイクルを繰り返すことになる。 データが正しい状態か保証されないまま、後続の処理（DB 保存など）に渡されてしまう。 今回は、こういった CS
※ 凡例: ✓ = 明示的に言及、(言及) = 関連概念として触れられている、- = 言及なし ※ Reflection/Critic の Anthropic 列については、記事内で「自己批評的なループ」として触れられている Evaluator-Optimizer の概念を対応付けたもの。 ※ LangGraph 列については、引用ページ [2:1] だけでなく、ReAct エージェントや Plan-and-Execute チュートリアルなど LangGraph ドキュメント全体を含めて対応付けている。 ※ Evaluator-Optimizer は Reflection の一種とも捉えられるが、Anthropic が重視しているため独立して記載した。両者の違いは以下の通り： Reflection/Critic: 同一の LLM が自らの出力を批評し、定性的に改善する（自己批評） Eval
React /Next.js に慣れてくると、次に悩むのはだいたい「設計レイヤー」まわりですよね。 コンポーネントが太りやすい useEffect が増えてロジックが迷子になる 状態をどこに置くか毎回迷う Hooks をどこまで分割すべきか分からない このあたりのモヤモヤさえ事前に言語化しておくと、 コードの読みやすさ 変更時の“怖さ”の小ささ チーム開発でのストレス がけっこう変わります。 この記事では 2024〜2025 時点のReact 19 /Next.js 15（App Router） の設計思想を踏まえつつ、 実務で迷わないための “判断軸” を、例外や補足も含めて整理してみます。 ※Next.js 15 はReact 19 と組み合わせるのが公式に推奨されていますが、 ここで紹介する考え方はReact 18 ベースの既存プロジェクトにも流用できます。 1. 設計は
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
