株式会社FLINTERSでフロント&バックエンドエンジニアをやっている者です! いい加減、git worktreeを身近においておこうと思い書き留めました。✏️🗒️本記事はFLINTERSBLOG Advent Calendar 2025の13日目の記事となります。 はじめに 開発者の皆さんなら、一度は「コンテキストスイッチ地獄」を経験したことがあるのではないでしょうか。新しい機能開発に没頭しているまさにその時、Slackに飛び込んでくる 「緊急バグ修正お願いします!」 の通知。 ここから始まる従来の手順は、思い出すだけでも気が滅入ります。 まず、中途半端な作業を git stash で退避。次に gitswitch でバグのあるブランチに移動し、修正作業に頭を切り替えます。 修正が終わったら、また元のブランチに戻り、git stash pop を実行。 しかし、複数の stash

この記事はHTアドベントカレンダー5日目の記事です。 はじめに 博報堂テクノロジーズでデータサイエンティストをしている髙橋です。データとテクノロジーを駆使してメディア・コンテンツを革新していくデータサイエンティスト集団であるAaaSTech Lab に所属しています。 私のチームでは、テレビの視聴ログや広告の出稿データ、生体データなど、メディア・コンテンツ領域の多様なデータを扱っています。業務内容は分析や予測にとどまらず、観光プロモーションやAIラップ生成といった企画立案から、バックエンド・フロントエンドの実装まで多岐にわたります。 チームメンバーは全員データサイエンティストですが、単に機能を作るだけでなく、UI/UXまで意識して作り込むスタイルをとっています。例えば、AIエージェントとの対話を通じてメディアプランニングができるソリューションなどもその一例です。 前回のアドベントカレンダ
この記事は、LayerXTech Advent Calendar 2025 の 2日目の記事です。 初日は @frkake さんの「OCR技術の変遷と日本語対応モデルの性能検証」と、@izumin5210 さんの「思考を減らしコードに集中するための tmux,Neovim 設定」の豪華二本立てでした。 こんにちは、@su8/denchuです。 クラナドは人生。電柱が好きです。現在、マサイ族の驚異的な視力を瞳に宿せると噂の「とあるブルーベリーのサプリメント」(諸説あり)が空前絶後の流行りをみせているバクラク勤怠チームで、ソフトウェアエンジニアをしています。 平均視力は3.0~8.0と推測され、中には12.0の数値を出すマサイ族もいるらしい。12...?本記事では、大量のドキュメントレビューで目の疲れを感じやすい仕様駆動開発(SDD)に対して、いわば「仕様駆動開発におけるブルーベリー」と

React /Next.js に慣れてくると、次に悩むのはだいたい「設計レイヤー」まわりですよね。 コンポーネントが太りやすい useEffect が増えてロジックが迷子になる 状態をどこに置くか毎回迷う Hooks をどこまで分割すべきか分からない このあたりのモヤモヤさえ事前に言語化しておくと、 コードの読みやすさ 変更時の“怖さ”の小ささ チーム開発でのストレス がけっこう変わります。 この記事では 2024〜2025 時点のReact 19 /Next.js 15(App Router) の設計思想を踏まえつつ、 実務で迷わないための “判断軸” を、例外や補足も含めて整理してみます。 ※Next.js 15 はReact 19 と組み合わせるのが公式に推奨されていますが、 ここで紹介する考え方はReact 18 ベースの既存プロジェクトにも流用できます。 1. 設計は

はじめに こちらの記事は先日開催されたAI駆動開発についてのイベントの登壇内容をベースに記事にしたものです。 発表後の反応が良く、特に「他社のAI駆動開発の実態を知ることができてよかった」という声をいただいたため、改めて記事化することにしました。 Claude CodeやCodex等を使用して開発している方は増えていると思いますが、実際に行っている開発フローを共有されることはあまり多くないため、私たちが実施しているAI駆動のフローを共有し、みなさんのAI駆動開発に参考になればと思います。 先に全体像共有 最初に全体像をお見せします。AI駆動開発のフローは大きく4つのステップで構成されています。 要件定義 設計(バックエンド・フロントエンド) 実装(バックエンド・フロントエンド) PR 基本的に仕様駆動開発(Spec Driven Development)を採用しています。 SDDとは簡単

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 前回の記事ではWingetの基本的な使い方についてまとめました。本記事では、最近追加された「winget configuration」について紹介します。 この機能を活用すれば、開発環境のセットアップを効率化できます。 みなさんこんにちは。新しいPCをセットアップする際や、チームメンバーの開発環境を統一する時に、面倒な作業の連続で時間を無駄にした経験はないでしょうか。 この記事では、単なるアプリインストールツールとしてのwingetの使い方を超えて、開発環境の完全自動化を実現する方法を解説します。DevContainerのよう
対策AGENTS.md useEffect Policy useEffect must be used only for synchronizing with the external world — for example:API calls, WebSocket connections, browserAPIs, external store subscriptions, or timers. In all other cases,it must not be used. Anti-patterns • Copying props or derived values into local state • Runninglogic in response to flag changes • Handling user actions inside effects instead
はじめに こんにちは。ZOZOTOWN開発本部フロントエンドの菊地(@hiro0218)です。 2021年、ZOZOTOWNはフロントエンドリプレイスを開始しました。現在、ホームページや商品一覧ページなど主要なページのNext.js化が完了し、運用フェーズに入っています。詳細は以下の記事を参照してください。techblog.zozo.com 開始当初、他社事例を参考にしながら、よくある課題を未然に防ぐディレクトリ構成を設計しました。本記事では、約4年にわたる運用で改善を重ねてきたディレクトリの分割戦略について紹介します。 ※本記事は2025年8月にちょっと株式会社との合同勉強会で発表した内容を基にしています。speakerdeck.com 背景 現在、私が携わっている領域におけるフロントエンド開発は4チーム、合計30名強で運用しています。この規模で効率的に開発を進めるため、ディレクトリ

あの日見たパターンの名前を僕たちはまだ知らない. よくある一覧 + 詳細画面を作りたい 例えば TODO アプリで, /todo にアクセスしたらタスクの一覧を, /todo/42 にアクセスしたら一覧は表示したまま ID = 42 のタスクの詳細を表示する, というよくあるパターンの画面を作りたい. 世の中の実例としては Asana や, URL の形は異なりますがGitHub の Projects なんかがこういう感じですね. /todo で一覧, /todo/42 で一覧 + 詳細技術的には要するに SPA なのでやればできるはずなんですが, これをNext.js (App Router) 上で作るにはどうしたら良いかという話をします. 素朴な実装は微妙Next.js はファイルシステムベースのルーティングを行います. ということで最も素朴には以下のようにファイルを配置すれば


2025年10月20日の僕が考えるAIコーディング(バイブコーディング)プロセスです。 個人的な結論としては、1ミリでも気に食わないコードを生成してきたら、そのタスクは最終的には破棄すべきというものです。「このコード気に食わない」「この設計気に食わない」の直感がAIコーディングで品質を維持する生命線です。 バイブコーディング時代ではコードレビューのお局ビリティが鍵です。 レビューに全時間を割こう。レビューに時間がかかりすぎるというより、レビューに時間をもっとかけるくらい 1ミリでも知らないことをなくそう 断片的なAIコーディングでいえば1年弱、本格的なコーディングエージェントを使い始めて半年以上の僕がたどり着いた結論です。 よろしければ、皆さんのTipsや感想も知りたいです。アップデートしていきたいところです。 前提 僕は実装だけじゃなくて、設計もさせることが多いです Codex使いましょ

現実のアプリケーションで発生するすべてのエラー・例外をResult型に変換するのは非現実的 エラーハンドリングが不要なものはUnexpectedErrorとしてまとめてしまう という現実的な落とし所を提案する記事です。TypeScriptにResult型を導入したくなる理由TypeScriptのエラーハンドリングは、try…catch文を使うのが基本です。tryブロック内でthrowされた例外はcatchブロックで捕捉されます。 try…catchによるエラーハンドリングには、以下の問題があります。 例外がthrowされる可能性がある関数かどうかが型シグネチャに表れないため、呼び出し時にtry…catchが必要かどうかわからない exceptionVarの型がunknown(設定によってはany)のため、エラーの種類に応じたハンドリングができない try…catchを細かく切って個別に

本記事では、筆者の dotfiles リポジトリ shunk031/dotfiles を題材に、テスト可能性を重視した dotfiles 管理のアプローチについて解説します。 はじめに dotfiles と dotfiles リポジトリ dotfiles とは、.bashrc、.vimrc、.gitconfig などの「.」で始まる設定ファイル群のことです。近年、これらを Git リポジトリで管理する dotfiles リポジトリ が開発者の間で広く普及しています。 dotfiles リポジトリは単なる設定ファイルの管理ではなく、設定ファイル、インストールやセットアップ用のスクリプトを含む開発環境構築の自動化ツールとして機能することが多いです。これにより、新しいマシンや環境でのセットアップが迅速かつ一貫して行えるようになります。 テストされないスクリプトの問題 ほとんどの dotfiles

はじめまして。チームみらい 永田町エンジニアチームの伊藤と申します!エンジニアチームではエディと呼ばれています。 どーやって作ったの?先日チームみらいでは、政治資金の流れを透明性を持って公開するプラットフォーム「みらい まる見え政治資金」をリリース、ソースコードも OSS として公開し、サービス開始から約2日で20万PVと、大きな反響をいただきました。 アプリケーションの設計や技術的な詳細については、上記の記事にまとめているので、ぜひ読んでみてください! ところで、こちらのアプリ、実は95%以上のコードをLLM(コーディングエージェント)が実装しているんです。 自分でコーディングの手を動かさない開発手法を確立できたことで、15,000行程度の中規模アプリケーションを、開発開始から約45日でリリースすることが可能になったと思っています。(なお私は別件でフルタイムの本業があり、パートタイムとし

はじめまして。チームみらい 永田町エンジニアチームの伊藤と申します!エンジニアチームではエディと呼ばれています。 先日チームみらいでは、政治資金の流れを透明性を持って公開するプラットフォーム「みらい まる見え政治資金」をリリース、ソースコードも OSS として公開し、サービス開始から約2日で20万PVと、大きな反響をいただきました。 2日で20万アクセス!ありがとうございました!このサービスがどういったものなのか、なぜ公開するのかについてはこちらの記事に譲るとして、この記事では、ソフトウェアエンジニア向けに振り切った記事として、サービス構成と工夫した部分を紹介しようと思います。 また、関連記事として、「どのようにして95%以上のコードをLLMに書かせることができたのか」についても記事にしているので、よければ合わせてお読みください。 国政政党の提供するサービスとして意識したポイント公共性のあ

はじめに 最近、Claude Code を使って「設計 → 実装 → テスト → PR」という流れを丸ごと自動化できないかと考え、検証用のプラットフォームを作っていました。 このプラットフォームはYAML ファイルでサブエージェントを制御し、ワークフローを実行する仕組みです。 ただ実際にやってみると、サブエージェントを順番に実行していくことは意外と面倒 だと気づきました。 そこで「もっとシンプルにワークフローを定義できる仕組みが欲しい」と思い、「CC-Flow」 を作りました。この記事では、その仕組みと使い方を紹介します。 なぜ作ろうと思ったか Claude Code でワークフローを組む際、当初はサブエージェントを順に呼び出すことで実現できると考えていました。 しかし実際に使ってみると、次のような課題がありました。YAML ファイルが膨大になり、管理が大変 呼び出し順を変えるだけでも

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く