IntelliJ IDEAを使っている人は全員Junieを導入しよう！
はじめに こんにちは、株式会社スマートラウンドでチーフテックリードをしているtsukakei1012です。 ついに、JetBrains製のAIコーディングエージェントであるJunieがGenerally Availableになりました🎉 弊社では、EAP（Early Access Program）の頃から開発チーム全体で導入・活用していることもあり、既にいくつかの知見が蓄積されています。 この記事では、新たにJunieを導入しよう・してみたいと考えている方に向けた参考資料になればいいと思い、書きましたのでぜひご参考にしてみてください！ （ちなみに料金体系などの違いは下の記事によくまとまっています！） ちょっとした宣伝 弊社は創業期からKtorを活用したサーバーサイドKotlinでプロダクト開発を行っており、Server-Side Kotlin Meetup（以下、SSKMと呼びます。）の
生成AIの時代にレイヤードアーキテクチャは古いかなと思った
概要 導入 生成AIの進化に伴いシステム開発においても生成AIにとっても管理しやすいコードベースを作ることが重要になってきてるかなと思います。 そこで重要な点は生成AIに一度に読み書きさせる文章量や概念の広さ(コンテキストウィンドウ)が広い程に品質が下がるので判断材料は多いほど良いのですが効率的に関連情報のみにフィルタリングして渡す情報を節約するのが重要なのでなはいかと(お値段的にも)。 そこで今回お話ししたいのは、昨今流行っているレイヤードアーキテクチャのレイヤー構造が生成AIのコンテキストウィンドウと相性が悪いのではないかと気付き新しいアーキテクチャのコンセプトを描きたくなったので記事を書きました。 コード生成処理の流れ 1.コード生成対象ディレクトリの特定(pwd) 2. 関連パス（親ディレクトリ含む）を列挙 3. module.yaml（と親のmodule.yaml）から設計情報を
アプリケーションアーキテクチャをいい感じに検証し続けたい話 - CADDi Tech Blog
こんにちは、Drawer Growthグループ ソフトウェアエンジニアの内田(id:usadamasa, @usadamasa)です。弊社ではApache Icebergの活用*1とともに、一部のアプリケーションにJavaを導入しています。今回は、システムアーキテクチャから一段レイヤを下げてアプリケーションレベルのお話しをしたいと思います。 アプリケーションアーキテクチャの設計と運用課題 アプリケーション開発において、私たちエンジニアは通常、パッケージ構成やレイヤの依存関係、ロギングなどの観点からアーキテクチャを設計します。 しかし、実装との不整合やチーム内での共通認識が不十分なまま進むと、品質課題として潜在化し、やがて本番障害や開発者の疲弊といった形で問題に発展します。また、DevinやClineなどのAIエージェントに適切に実装してもらうにはプロンプトやドキュメントで設計を伝える必要が
2024年末にデザインパターンについて考える - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Futureアドベントカレンダーの3日目のエントリーです。昨日は@yamat2667さんのFlutterの記事でした。 デザインパターンというと、普段のプログラミングから一歩踏み込んで設計力を上げたい人が履修すべきコンテンツのように思われているようなツイートなりを見かけます。オブジェクト指向言語全般に使える知識だ、とか、開発者同士のコミュニケーションに使えるぞ、とか、コードの質が上がるぞ、とか。 一方で、パターンを詰め込もうとすると逆にコード量が増えて、パターン由来の変なクラス名が増えたりして、設計が歪むぞ、というのも当初から言われてき
なぜ MCP なのか
なぜ自分が MCP を追いかけているのかを雑にだらだらと書いて行こうと思います。 乱文です。 オープンなプロトコル追いかけている理由は Model Context Protocol がオープンなプロトコルにしたことです。これが ChatGPT Plugins とかのクローズドなプロトコルであれば全く追いかけていなかったと思います。 MCP は Anthoropic 以外でも MCP クライアントを実装しさえしていれば、多くの MCP サーバーと接続する事が出来ます。実際 MCP を公開した Anthropic が提供している Claude Desktop や Claude Code だけでなく Cline や Cursor などが MCP クライアントを実装したことにより、MCP サーバーさえ実装してしまえば、様々な環境で利用できる仕組みになっています。 そして VS Code も MCP
不要な処理が実行速度を速くする謎を追う - Money Forward Developers Blog
こんにちは。 id:Pocke です。マネーフォワードでは Rails を用いた Web アプリケーションの開発と、RBS という Ruby の静的型システムの開発を行っています。 最近 RBS の開発をする中で、「不要な処理を削除すると実行速度が遅くなる」という不思議な現象に遭遇しました。この記事ではその現象を解説しようと思います。 なおこの記事は Ruby の知識を前提としないように執筆されており、Ruby の知識が必要となるところには注釈を加えて補足しています。 普段 Ruby を書かない方にも読んでいただければ幸いです。 問題を引き起こした変更 今回の問題は、RBS のメモリ使用量の削減を行っている中で遭遇しました。まずはどんな変更を行おうとしていたかを解説します。 変更の動機 最近私は RBS のメモリ使用量の削減に取り組んでいます。1 その取り組みの中で、RBS のパーサーが作
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
ProtocolBuffers/gRPCを安全に書き進めるためのエトセトラ
OWASP Fukuoka Meeting #6 https://owasp-kyushu.connpass.com/event/244388/ #owaspfukuoka
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
大規模システムにおけるディレクトリ構成をRDBのカーディナリティを参考に考える - ぷらすのブログ
モノリシックなプロジェクトにおいて、トップレベルのディレクトリ構成が異なる 2 つのディレクトリ構成を考え、それらの違いは何で、どちらが優れているか？という問いについて考えた。そして、「複雑な概念をトップレベルのディレクトリ構成にした方が良いのでは？」という結論に落ち着いた話をする。 はじまり ちょっとしたシナリオを想像してみよう。 プロジェクト立ち上げ期 「最近のトレンドはレイヤードアーキテクチャだ！」 そう言って、プロジェクトはスタートした。 . ├── application │ ├── xxx_usecase.go │ ├── xxx_repository.go │ ├── yyy_usecase.go │ └── yyy_repository.go ├── domain │ ├── xxx.go │ └── yyy.go ├── infrastructure │ └── xxx_
アプリケーション動作ログ、
ERRORで出すか? WARNで出すか? #cmdevio2019
20190406 Developers.IO 2019 岡山城 アプリケーションのログ、出してますか？ 欲しい情報が出てますか？ 要らない情報いっぱい出てませんか？ 出すか出さないかの判断は、何に基づいて決めていますか？ そもそも何のためにログ出してますか？ そこでログが出るのは正しいですか？ ここでログが出ないのは正しいですか？ そのログは INFO で出すべきものですか？ それとも DEBUG ですか？ 異常発生なので ERROR でログを出しますか？ では異常とはなんですか？ 404は異常ですか？ 直感に任せて雑にやってますか？ 雑にやってうまくいっていますか？ ガイドラインほしくないですか？ 忙しいですか？ 救ってもらっていいですか？Read less
CLI ツール開発を支える技術 2019春 / Techniques that support building CLI tools, 2019 Spring
talked on https://golangtokyo.connpass.com/event/129067/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Coding Guidelines for Your AI Agents | The IntelliJ IDEA Blog
MCPに入門する/ Introduction to MCP
https://blogs.oracle.com/otnjp/post/unit-test-your-architecture-with-archunit-ja
Unit of Workパターンで永続化とトランザクションを制御する
サバンナ便り〜自動テストに関する連載で得られた知見のまとめ（2023年5月版）〜 / Automated Test Knowledge from Savanna 202305 edition
フルスタック開発者のためのBallerina: バックエンドAPI開発ガイド
