「Claude Codeで効率的に開発するための知見管理」をコマンド1発で自分のプロジェクトに反映する方法
はじめに 開発プロジェクトにおいて、コードの知識管理やドキュメント整備は重要ですが、手間がかかる作業でもあります。しかし、LLM の力を借りることで、先駆者が構築した知見を瞬時に自分のプロジェクトに適用できる時代が到来しました。 背景：話題になった記事 こちらの記事が開発者コミュニティで話題になっています。 この記事では、Claude を使った効果的なコード知識管理システムの構築方法が紹介されています。 課題 上の記事を読むと普通のかたは「自分のリポジトリにも適用して試したい！」と思います。 しかしながら、実際に自分のリポジトリに取り込むとなると以下の手順が必要そうだなぁと考えると思います。 記事を読んで内容を理解し、大まかな手順を理解する。 細かい設定やドキュメントを新規作成していく。 自分のプロジェクトに合わせてカスタマイズ そうすると、めんどくさくなって放置してしまいます。 LLM時
Clineを利用した開発が超快適なので、使っている.clinerulesを解説します
こんにちは、株式会社Berryの浅沼です。 この記事を書いている数週間前くらいから話題のClineを会社で導入し、開発に利用しています。最初はコードの自動生成から試していたのですが、.clinerulesを使ってプロジェクトごとのカスタム設定ができることを知り、どんどん活用の幅を広げていきました。 特に大きかったのが、プロジェクト内のコード構造・コーディングルールの設定に加えて、コミットメッセージやプルリクエストのタイトル・サマリーを生成するルールを追加したことです。これによって、「コードを書く→コミットメッセージを考える→プルリクを書く」という一連の作業がスムーズになり、全体の開発効率が格段に上がりました。 この記事では、実際の.clinerulesの内容も含めて、どのようにルールを作り、育て、活用しているのかを紹介します。特に、コードの自動生成以外の使い方にも触れますので、すでにCli
イネーブリングチームの考え方と実践例 — 組織の価値提供能力をいかに高めるか
はじめに 弊社マイベストでは、エンドツーエンドの機能開発チームとは別で、組織の価値提供能力を高めることを目的としたイネーブリングチームがあります。（と言ってもまだ他チームとの兼任メンバーがほとんどですが） イネーブリングチームは、バックエンドやフロントエンドなど、領域ごとに技術課題を解決すべく活動していて、自分はフロントエンド領域を担当しています。 これまで様々な活動を行ってきたので、その考え方を整理しつつ、フロントエンドイネーブリングの実践例をご紹介したいと思います。 参考：マイベストのチーム構成イメージ（記載は一部のみ・名称は仮です） 「イネーブリングチーム」とは イネーブリングは『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』、通称チートポから持ってきた名称なので、まずはチートポをベースにその役割を説明します。 https://amazon.co.jp/dp/
タスクに「〜対応」という名前をつけるのを避けたい理由
先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが
プラグインマネージャーの歴史と新世代のプラグインマネージャー dpp.vim
始めに ddc.vim, ddu.vim の開発が一通り終了し、次に作成するプラグインについて考えていました。 バイナリ編集プラグイン ddx.vim の開発を進めることも考えていたのですが、dein.vim の開発から長い時間がたっており新たなプラグインマネージャーも出てきているので、そろそろ作り直すべきではないかと考えました。 プラグインマネージャーの機能がどんどん複雑化する昨今、プラグインマネージャーに必要な機能とは何か考えたときに、「拡張可能なプラグインマネージャーが求められている」と思ったのです。 そして今回作成したプラグインマネージャーは dpp.vim です。 dpp.vim は作成したばかりで完成度はまだ低く、dein.vim ユーザーが乗り換える機能のレベルや安定性にはなっていません。 しかし、その設計思想とインタフェースは十分固まったといえるので今回記事を書くことにしま
「なんちゃってスクラム」に気づくためのコツ
こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、開発手法として、スクラム開発に取り組んでいます。 今回は、「なんちゃってスクラム」に気づくためのコツ、というトピックで話していきたいと思います。 自分自身数年にわたり、他社の方から「スクラム開発やってる？」と聞かれたときに、「なんちゃってスクラムですかねぇ」と言い続けてきました。長らく「なんちゃって」状態だったのですが、最近個人的にそれを脱するタイミングを味わったので、その話をさせてください。 ※ そもそもスクラム開発をよく知らないという方にもわかるように、適宜スクラム開発自体の説明もしていきます。 この記事の対象読者 現在進行形で、スクラム開発をやっているが、なんか違いそうと感じている方 (前職などで)1度スクラム開発をやった経験はあるが、いまいち
Prompt Engineering Guide – Nextra
Prompt Engineering Guide プロンプトエンジニアリングは、言語モデル（LMs）を効率的に使用するためのプロンプトを開発および最適化する比較的新しい学問分野です。プロンプトエンジニアリングのスキルを身につけることで、大規模言語モデル（LLMs）の能力と限界をより理解することができます。 研究者は、プロンプトエンジニアリングを使用して、質問応答や算術推論などの一般的なおよび複雑なタスクのLLMsの能力を向上させます。開発者は、LLMsやその他のツールとのインタフェースとなる強固で効果的なプロンプテクニックを設計するためにプロンプトエンジニアリングを使用します。 プロンプトエンジニアリングは、プロンプトの設計と開発に限らず、LLMsとのインタラクションおよび開発に役立つ幅広いスキルと技術を含みます。これは、LLMsとインタフェースすること、ビルドすること、能力を理解すること
チームのベロシティを上げる vs. 安定させる - yigarashiのブログ
タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
記憶に残らないものをメモするためにMemory Noteという仕組みを書いた
Memory NoteというプログラマブルなTodoアプリのミドルウェアを書きました。 ややこしいですが、大雑把に言えばReminder的なTodoリストを扱うREST APIをCloudflare Workersで動かす仕組みです。 Headless Todo Appという単語がしっくりくるのかもしれません。 単体だと何ができるのかよくわからないものですが、Todoサービスを自分用に作れる仕組みです。 対象ユーザーは主に自分ですが、Memory NoteのREADMEにセットアップ方法や関連するクライアントの実装も公開しています。 自分の場合は、iOSのショートカットから音声入力で、メモをGitHub Projectのボードにカードして記録しています。 この記録したメモを、iOSのWidgetsとしてホーム画面に出したり、AlfredのHotKeyでワンタッチで表示したり、部屋に電子ペー
突撃！ 在宅の開発環境 2021年夏 - Mobile Factory Tech Blog
はじめに こんにちは。ブロックチェーンチームのエンジニア、 @nanamachi です。 tech.mobilefactory.jp 前回の記事ではたくさんの方に閲覧&コメントいただきありがとうございました。この記事から1年。モバイルファクトリーは日本のどこからでも働けるようになり、書籍購入、資格取得、セミナー参加、懇親会の支援制度などフルリモートに適応できるよう多くの変化をしてきました ( https://recruit.mobilefactory.jp/work-style/ )。その中で社員の環境もさまざま変わったことでしょう。 この変化を記事にすれば、閲覧数を稼げる 弊社の魅力を発信できるに違いない!という目論見で、初めてバズった記事にすがるエンジニア組織開発責任者の@kfly8から次のようなチャットが送られてきました。 kfly8: インターネット識者*1の @nanamachi
JetBrains 開発者サーベイから見る日本のソフトウェア開発（2020年版） | Post Blog
こんにちは。JetBrains 堀岡です。 JetBrains では、近年世界中の開発者をターゲットとした「The State of Developer Ecosystem（開発者エコシステムの現状）」と呼ばれる年次サーベイを行っています。 2020年版の調査結果は以下のサイトで公開されています。 この調査結果において、「世界とのトレンドは分かったが、日本のトレンドはどうなんだろう？」と興味を持たれた方もいるのではないでしょうか。 このブログポストでは、JetBrains のリサーチチーム の協力を得て、日本の開発者からの回答と、（日本以外の）世界の開発者から回答の比較を行います。加えて、考察（というよりは個人的な感想かもしれません）、 JetBrains 関連のトピックについても紹介します。 開発者の属性 今回の比較に用いられたサーベイの回答数は以下の通りです。 日本からの回答数:623
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
開発者向けの基盤をつくる
ハッカーズチャンプルー2019（ http://hackers-champloo.org/2019 ）の発表資料です
Node.js command-line tools for front-end development | Adobe Developer Connection
Experience working with the command line is required. Some knowledge of Node.js will help you make the most of this article. Required products Node.js You may already know that Node.js enables you to create server-side applications using JavaScript. While this is a powerful and compelling capability, perhaps you aren’t a server-side developer or you aren’t yet ready to commit to server-side develo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
