CLINEに全部賭けろ
Cline を使い始めて2ヶ月ぐらい経った。 自分の直感として、Cline は真のイノベーションの入口であり、そして開けてはいけないパンドラの箱でもあったと思う。 ここでいう Cline は Cline型コーディングエージェントであり、広義には Devin / Cursor や Copilot Agent 等を含む話。だが、後述するように Cline でしか見えない世界がある。 その先の未来に、プログラマとしての自分はフルベットする、という話をする。 私たちが知っているプログラミングの終焉 大事なことは次の記事に全部書いてある。まずこれを読んでほしい。 (Google翻訳) Steve Yegge 氏は、置き換えられるのはジュニアおよび中級レベルのプログラマーではなく、新しいプログラミング ツールやパラダイムを受け入れず過去に固執するプログラマーであると指摘しています。 <略> これはプロ
人間によるコーディング禁止の CLINE 縛りでゲームを作らせてみた感想
現時点の AI コーディングの実力を測るために、自分はプロンプトのみ、直接コードを書くのは禁止で Roo Code による VS Code によるエディタ操作のみでコードを書かせた。その感想 (急いで書いたのでいろいろと雑です) tl;dr 良し悪しはともかく、人類は確実にAIによる自動操縦型のプログラミング体験に依存するという確信を持った。 ただ、その基盤である CLINE(系)自体のツールとしての完成度はいまいち。 CLINE以外の、各モデルのコーディング性能も、現時点では物足りない。 CLINE とは何か(知らない人向け) いろいろと機能はあるが、コア機能としてはヘッドフルな vscode runner で、AI にコードを書かせるために必要な情報を受け渡しするインターフェースを持っている。ファイルの読み書きや、コマンドを実行結果をプロンプトにしてAIに渡す。puppeteer によ
LLM にコードを「差分」で書き換えさせるためのアイデア
既存の LLM コード生成の問題 LLM は行カウントやワードカウントが苦手。 例えば自分は SourceMap を扱うコードのテストを書かせようとしたが、モックデータの line:column がガバガバな位置を指してまともにテストにならない。行カウント/ワードカウントができないのはつまり diff がうまく生成できない。 これらの問題があって、コードを生成するパイプラインを組む場合、 全文出力が主流になっている。 ここで何が問題になるかというと、コードが膨らんで来た時に、(書き変える対象が一部だとしても)生成が顕著に遅くなる。うまく生成できなかった時にリトライを繰り返すと、問題がさらに悪化する。 改善手法の提案: 明示的な Line Number の付与 最近の LLM は入力ウィンドウがある程度大きくても、そこそこの速度で応答する。(お金はかかるが...) 問題は生成速度にある。特に
IDEにChatGPTを統合、「この関数のテストコードはどこ？」「XXXを実装するならどう書けばいい？」など、AIでコードと対話できる「qqbot」登場
IDEにChatGPTを統合、「この関数のテストコードはどこ？」「XXXを実装するならどう書けばいい？」など、AIでコードと対話できる「qqbot」登場 テキストから高度なイラストを生成するAIや、人間と自然な対話を可能にするAIが最近話題になっています。 この人間と自然な会話をするAIチャットの代表的なサービスであるChatGPTの派生サービス（Variant of ChatGPT）をVisual Studio CodeなどのIDEに統合し、開発中のコードについて「この関数のテストコードはどこ？」などと対話できる「qqbot」が登場しました。 開発したのはDan Robinson氏。 Introducing qqbot, a variant of ChatGPT that lives in your IDE. The cool thing about qqbot is that it k
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（後編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（後編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
Go言語でのテストの並列化 〜t.Parallel()メソッドを理解する〜 | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2020 の6日目の記事です。 メルペイでBackendエンジニアをしている柴田（@yoshiki_shibata）です。この記事では、Go言語のtestingパッケージに用意されている並列化の機能について説明します。 Go言語では、テストコードを作成するためのtestingパッケージが用意されています。一般に開発するソフトウェアの規模が大きくなるに従って、作成されるテストコードの量も多くなり、すべてのテストが終了するまでの時間も長くなっていきます。特に、データベースへアクセスするようなテストでは、データベースへの通信時間がテスト時間の多く占めますので、テストコードを逐次実行するよりは並列実行することで、テスト時間を短縮できます（厳密には用語「並行」ですが、t.Parallel()メソッドの説明なので、この記事では用語「並列
プログラマーテストの原則 by Kent Beck
チョコレート対バニラTDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。 詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。 詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか？ これでは埒が明かない。 原則一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。 詳細で論争するよりも、原則で論争したほうが生産
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
レガシーコードの触り方 / Working Effectively with Legacy Code
オープンセミナー2017@岡山
テストコードの期待値はDRYを捨ててベタ書きする ～テストコードの重要な役割とは？～ - Qiita
はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き
Copeが教えてくれた、TDD否定派論文の紹介 - 2013-10-31 - やっとむでぽん
来日中の James O. Coplien と話をする機会があり、いまTDDをクライアントに推薦していると話したら目を剥いて "Are you still doing TDD!?" と詰め寄られ、TDDの問題について大変熱烈に語ってくれました(ディスカッションをした体ではあるんだけど、だいたい10対0くらいで押されてました)。 Cope はその後、丁寧にfacebook上にもTDDの話を書いてくれました。ここで読めます。 さらにメールで、TDDの問題を指摘した論文などをいくつか教えてくれたのでした。そこで紹介してもらった論文を、自分の理解の整理も兼ねて、サマリをしてみようと思います。とりあえず1つだけですけど。 "A Comparative Case Study on the Impact of Test-Driven Development on Program Design and T
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
あれから 10 年。まさーるさん(石井勝さん)を偲ぶ。 - t-wadaのブログ
今日（2015-04-25）は福知山線の脱線事故から 10 年目の 4 月 25 日。つまり、まさーるさんこと石井勝さんが亡くなられてからも 10 年になる。 まさーるさんは、一言でいえば 1990 年代後半から 2000 年代前半の日本におけるオブジェクト指向プログラミング、自動テストとテスト駆動開発、そしてアジャイルソフトウェア開発の啓蒙において大きな役割を果たされた方だ。もしも 10 年前の福知山線に乗っていなければ、いまでも日本を代表するプログラマの一人だったのではないかと思う。 まさーるさんの残した足跡は、様々なところに見いだすことができる。 Java プログラマであれば、 Quick JUnit という Eclipse プラグインを使ったことがある方が多いのではないかと思う。 Quick JUnit はテストコードとテスト対象コードの間をショートカットで行き来できる便利なプラグ
実践テスト駆動開発(GOOS)読んだ - Qiita
実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TypeScriptで 負荷テストを書こう 〜k6のシングルバイナリの秘密〜
開発者向けのテストの本いろいろ
スローテスト刑事 (デカ)
