※執筆時点の情報なので、内容が古くなっている可能性があります。最新の情報は公式ドキュメントをご確認ください。 はじめに GitHub CopilotのAPIを自分で呼び出せて、カスタムできたらなーとなんとなく思っていた時代もあった私。 そんな私がVS CodeのAPIに Chat extensions というものが追加されたと知ってしまい、「これはもしや内部でGitHub CopilotのAPIを呼び出せるやつでは！？でもドキュメント見てもよくわからん…誰も記事書いてない…」となったので、実際にいじって確認した内容をまとめます。 ついでに出てくる言語モデルAPIについてもまとめています。 VS Codeの拡張機能開発も初めて、TypeScriptも不慣れなので間違いがあればご指摘ください。 VS Code拡張機能開発方法については取り上げませんので、こちらをご確認ください。 結論 時間がな

TL;DR Add a terraform plan -light flag such that only resources modified in code are targeted for planning. This would reduce the scope of the pre-plan refresh down to the set of resources we know changed, which reduces overall plan times without the consistency risk of -refresh=false. For Terraform to know what resources were modified in code, it would store the hash of the serialized sorted attr

Buf Technologies, Inc Connect webを作っている会社。 Protocol BuffersのlinterやCLIツールを開発している。 Protocol Buffersに特化している理由はよくわからない。(儲かるのか？) Protocol Buffers Protocol Buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data. Googleが開発したデータシリアライズのためのプラットフォーム中立的なオープンソース形式のこと。 JSONのようなデータフォーマットで様々なプログラミング言語で使える。 ProtobufはProtocol Buffersの略。 proto2やproto3 Protobufのバージョンを意味

Connect RPC, Buf’s family of fully protocol-conformant and battle-tested alternatives to Google’s gRPC project, has joined the Cloud Native Computing Foundation. We joined the CNCF to demonstrate our deep commitment to sustainably and responsibly growing Connect as a well-governed and community-led open source project. Today, Connect integrates seamlessly with gRPC systems in production at compani

はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って

こんにちは、ファインディのEND（@aiandrox）です！ 2024年4月30日より、ファインディは新オフィスに移転しました。 findy.co.jp 新オフィスのここがすごい！ 大崎駅から直結徒歩5分！雨に濡れずに出社できる！ 前オフィスの2.3倍の広さ！ オフラインイベントが開催できるイベントスペースが増えました！ この記事では、そんな新オフィスについて、エンジニア目線で紹介します（2024年5月時点）。 執務室について ソファ席・ハイテーブル パントリー イベントスペースについて 社内イベントの様子 オフラインイベントの様子 おわりに 執務室について 執務室は前オフィスと同じようにシンプルな作りです。1フロアで、大体徒歩5分あれば1周できるくらいの広さです。 最大500席入る広さですが、現在は出社メンバーが200人程度なので空席が多いです。毎月ガンガン新しい方にジョインしていただい

｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣Git 画像略 TL;DR(Too Long; Didn't Read) ~nは単純なコミットの親をたどる(ブランチの分岐がある場合は現在のブランチのみで辿れるコミット) ^nはマージコミット向けで^2は｢そのコミットの2番目の親(取り込んだブランチの前回のコミット)｣ だからHEAD^n(n > 2)は存在しない 2024/06/04追記：　OctopusなMergeだと３つ以上のブランチからマージできるので^nも存在する......があまり見かけることはない HEAD^^は｢HEAD^の親｣､HEAD^2は｢HEADのもう一人の親｣みたいな......｡タラちゃんがHEADだと波平がHEAD^^でマスオがHEAD^2です(