【Git】同じコンフリクト解消を繰り返している人に教えたい「git rerere」 - Qiita
はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
[翻訳]LLMで1年間開発して学んだこと〜LLMプロダクト開発を成功に導くための実践的ガイド〜
この記事は "What We’ve Learned From A Year of Building with LLMs" という記事を著者の一人である Eugene Yan さんから許可を得て翻訳したものです。 https://applied-llms.org/ Thank you for giving me a permission to translate this wonderful article! 著者の方々 Eugene Yan Bryan Bischof Charles Frye Hamel Husain Jason Liu Shreya Shankar 原文の公開日 2024/６/8 今は大規模言語モデル（LLM）を使った開発がとってもエキサイティングな時期です。この1年間で、LLMは実世界のアプリケーションに対して「十分に良い」ものになりました。そして、年々良くなり、安く
![[翻訳]LLMで1年間開発して学んだこと〜LLMプロダクト開発を成功に導くための実践的ガイド〜](https://cdn-ak-scissors.b.st-hatena.com/image/square/3636c7c8e7c838018a6e006d55b3f4b8d18f34cc/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--7VM-vHg9--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255B%2525E7%2525BF%2525BB%2525E8%2525A8%2525B3%25255DLLM%2525E3%252581%2525A71%2525E5%2525B9%2525B4%2525E9%252596%252593%2525E9%252596%25258B%2525E7%252599%2525BA%2525E3%252581%252597%2525E3%252581%2525A6%2525E5%2525AD%2525A6%2525E3%252582%252593%2525E3%252581%2525A0%2525E3%252581%252593%2525E3%252581%2525A8%2525E3%252580%25259CLLM%2525E3%252583%252597%2525E3%252583%2525AD%2525E3%252583%252580%2525E3%252582%2525AF%2525E3%252583%252588%2525E9%252596%25258B%2525E7%252599%2525BA%2525E3%252582%252592%2525E6%252588%252590%2525E5%25258A%25259F%2525E3%252581%2525AB%2525E5%2525B0%25258E%2525E3%252581%25258F%2525E3%252581%25259F%2525E3%252582%252581%2525E3%252581%2525AE%2525E5%2525AE%25259F%2525E8%2525B7%2525B5%2525E7%25259A%252584%2525E3%252582%2525AC%2525E3%252582%2525A4%2525E3%252583%252589%2525E3%252580%25259C%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Aseya%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2QzODg4YjM0MzEuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
RAGの実装戦略まとめ - Qiita
それでは以下、簡単なデモを含めながら個別に説明していきます。 1. ハイブリッドサーチ こちらは、性質の異なる複数の検索方式（例えばベクトル検索とキーワード検索）を組み合わせて検索精度を向上させる手法になります。 各検索方式単体の場合に比べ、性質の異なる検索方式を組み合わせ、ある種いいとこ取りをする事で、検索性能の向上が期待できます。 今回はBM25でのキーワードベースの類似度検索と通常のベクトル検索を組み合わせていきます。 BM25について簡単に説明しておくと、文脈や文章構造は完全に無視した上で、文書内の単語を全てバラバラに分割し、文書内の各単語の出現頻度と文書間におけるレア度を加味した特徴量を算出します。 つまり、特定の文書内の各単語の数をカウントしてヒストグラムを作れば、似たような文書には同じような単語がよく出るはずなので(同じようなヒストグラムの形になるので)、類似度が高くなる性質
RAGの実案件に取り組んできた今までの知見をまとめてみた | DevelopersIO
はじめに 新規事業部 生成AIチーム 山本です。 ChatGPT（OpenAI API）をはじめとしたAIの言語モデル（Large Language Model：以下、LLM）を使用して、チャットボットを構築するケースが増えています。通常、LLMが学習したときのデータに含まれている内容以外に関する質問には回答ができません。そのため、例えば社内システムに関するチャットボットを作成しようとしても、素のLLMでは質問に対してわからないという回答や異なる知識に基づいた回答が（当然ながら）得られてしまいます。 この問題を解決する方法として、Retrieval Augmented Generation（以下、RAG）という手法がよく使用されます。RAGでは、ユーザからの質問に回答するために必要そうな内容が書かれた文章を検索し、その文章をLLMへの入力（プロンプト）に付け加えて渡すことで、ユーザが欲しい
子育て終わった！やったーー！！【問い合わせに関する追記】
7/11 なんかツイッターの有名な方に拡散していただいたようでありがとうございます！！！とんでもないことになってしまった… 子育て終わった開放感で書き殴った日記がこんなことになるとは思ってもみませんでした。 取材に関しては、別の媒体で内容を掲載されることで息子に微妙に違ったニュアンスでこの日記の内容が伝わってしまうもしれないリスクがあるので申し訳ありませんがお断りさせてください。 ひぇーーーー！なんかめちゃくちゃ読まれてる！！今更恥ずかしい！！ お祝いのコメントありがとうございます！！！ めちゃくちゃ嬉しいです！！！ 子どもはインスタとかビーリアル(ビリアル？かどっちか)をちょっとしかやってないらしいし、仕事に関する勉強で忙しいらしいからこの日記も読まれないと思ってはいるけど、もし読んじゃったら教えてね！！！ 私が本当は愛せるか分からなかったし子供産むの怖かったって話はちょっと前チラッとし
無邪気なエンジニアリングができなくなってきた
タイトルの通り。好きでやっているエンジニアがだんだん好きではなくなってきたような気がして、改めて何が起きているのか、思考はまとまらないから箇条書きする。 無邪気なエンジニアリングとはコードを読む、書くのIOがとにかくたくさん気になったOSSやサービスはすぐさわる記事や登壇で書く以外のアウトプットもたくさん無邪気なエンジニアリングをして、これになりたかったインターネットで一発当てる著名なOSSのコミッターカンファレンスのプロポーザルをたくさん通す本をたくさん書いているたくさん質の良い記事を書いて凄い PV 数なりたかったのその行く末生活を全てエンジニアリングに捧げようとする無理あらゆる技術イベントに顔をだそうとする私生活や仕事でしばしば予定がつかずキャンセル帰りが遅くなるのが良くないので、家から近いイベント以外いかなくなった（規模の比較的おおきい）コミュニティを主催するスポンサー探しで苦労こ
技術書典16で同人誌「日記駆動仕事術」と「エンジニア採用ガイド」を頒布します
5/25〜6/9に開催される技術書典16に河童書房として出展し、同人誌を頒布します。5/26のオフライン会場には「し22 : 河童書房」として参加します。 今回は3冊頒布、そのうち2冊は新刊ですよ！ 新刊 : 「エンジニアのためのエンジニア採用ガイド」今年になってお手伝いしている企業で「採用どうしよう」というお悩みが発生したので、とりあえず現場向けのドキュメントを書きはじめました。もう5回目ぐらいだから手慣れたもんやで…とパカパカ書いていたのですが、ふと「これもう本にすればいいのでは？」という気持ちになり、過去4回の記憶をサルベージして書籍の形にしたのが本書です。 採用に携わってる方にとっては常識みたいな内容ですが、意外とこういうのを教えてくれる形式知は少ないような気がしています。いきなり「明日から採用担当な」という無茶振りはキャリアの幅を広げてくれるけど、それにしたってもうちょっとなんか
技術書典#16向けに 「The Cloud Run (Google Cloudコンテナ設計本)」を執筆しました - How elegant the tech world is...!
はじめに お久しぶりです。iselegantです。 今日は技術書典#16向けに執筆した「The Cloud Run」本の紹介をさせてください。 今回のテーマは「Google Cloud」です！ 特に、コンテナサービスとして代表的な「Cloud Run」のアーキテクチャ設計をテーマに執筆しました。 techbookfest.org これまで、「クラウドネイティブシリーズ」と称して3冊執筆してきましたが、その第4弾の位置付けになります。 いつもであれば、わりとゆるくかわいい感じの表紙でしたが、今回は「ちょっと本気でCloud Runに向きあって、読者のみなさまに価値を届けようか」とのコンセプトなので、本気度を表現するためにシリアスな表紙を作成いただきました。 今回の書籍のコンセプト 僕たちが今回の書籍を執筆する際、2つのコンセプトを大切にしています。 実務に通用する学びを届ける とにかく楽しく
Ktorm のクラス設計を読み解いて、DSLを拡張する - ドワンゴ教育サービス開発者ブログ
はじめに 先日Server-Side Kotlin MeetupのLT大会で登壇してきましたので、その内容をブログ記事でも公開します。 テーマはKotlin製のORマッパー、Ktormのクラス構造と機能拡張についてです。 Ktormの紹介 ktorm.org Ktormは、いくつかあるJDBCベースのKotlin製ORマッパーのうちの1つです。 それらの中でもっともメジャーと思われるExposedと比較すると、次のような特長があります。 シンプルな実行モデル 遅延実行やキャッシュなどの仕組みを持たないので、コードを読んで理解しやすく、SQLの実行タイミング等も把握しやすいです。 生SQLに近いDSL select() で検索条件を指定し slice() でカラムを指定する形式のExposedのDSL 1 に比べて、生SQLに近い文法を採用しており、SQLに習熟していれば少ない認知コストで読
GitHub Copilot Workspace：GitHub Copilotネイティブの開発環境へようこそ
Author Thomas Dohmke GitHub Copilot Workspaceで開発環境を再定義します – どんな開発者でも自然言語でアイディアからコード、ソフトウェアまで作成できます。登録はこちら。 この2年間で、生成AIは開発環境の中に組み込まれたツールとして、開発者の状況を大きく変えました。2022年、私たちはエディタ内のオートコンプリートAIペアプログラマーとしてGitHub Copilotを発表し、開発者の生産性を最大55%向上させました。GitHub Copilotは現在、最も広く採用されているAI開発者ツールです。2023年、GitHub Copilot Chatをリリース、コーディング、デバッグ、テストにおける自然言語の力を引き出し、開発者がリアルタイムでコードと会話できるようになりました。 昨年GitHub Universeでその一端をお見せした後、本日Git
OpenAIを使った自動コードレビューの導入 - Qiita
1. はじめに 少し前からAIを使ったコードレビューに関する記事を目にするようになりました。その中でも特に有名なのはCodeRabbitがあるかと思います。 無料でも使用することができますが、利用機能や条件が限られており、業務や個人でちゃんと使いたい場合は有料プランに入る必要があります。それなりの額を毎月支払うのはハードルが高いため、もう少し気軽に利用できるサービスがないかを探しました。 いくつかある中で、今回はChatGPT-CodeReviewを紹介します。 2. 対象読者 AIによる自動コードレビューに興味のある方 OpenAIのAPI利用経験者 Github Actionsを使った開発改善に興味のある方 3. 目次 1. はじめに 2. 対象読者 3. 目次 4. ChatGPT-CodeReviewの概要 5. 設定方法 5-1. Githubの設定 5-2. Github Ac
Spring Framework 6.1 から追加された RestClient を試してみる - Qiita
この記事はNTTコムウェア Advent Calendar 2023 13日目の記事です。 はじめに こんにちは、NTTコムウェアの田村です。 普段はMacchinetta Framework、Springプロジェクトに関する社内からの問合せ対応や技術検証を行っています。 今回は Spring Framework 6.1 から新しく登場したRESTクライアントである RestClient について公式ドキュメントを参照しつつ試してみました。 Spring Boot では 3.2 からRestClientをサポートしています。 本記事では Spring Framework 6.1.1 をもとに説明しています。 6.1.1 では RestClient による API 応答結果が no response body の場合、null ではなくエラーが返却されることが報告されています（ 6.1.2
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA（命名的問題）より、グループB（構造的問題）の方が正答率が大きいということ。一方でグループA（命名的問題）よりグループB（構造的問題）の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
Prompt Engineering Guide – Nextra
Prompt Engineering Guide プロンプトエンジニアリングは、言語モデル（LMs）を効率的に使用するためのプロンプトを開発および最適化する比較的新しい学問分野です。プロンプトエンジニアリングのスキルを身につけることで、大規模言語モデル（LLMs）の能力と限界をより理解することができます。 研究者は、プロンプトエンジニアリングを使用して、質問応答や算術推論などの一般的なおよび複雑なタスクのLLMsの能力を向上させます。開発者は、LLMsやその他のツールとのインタフェースとなる強固で効果的なプロンプテクニックを設計するためにプロンプトエンジニアリングを使用します。 プロンプトエンジニアリングは、プロンプトの設計と開発に限らず、LLMsとのインタラクションおよび開発に役立つ幅広いスキルと技術を含みます。これは、LLMsとインタフェースすること、ビルドすること、能力を理解すること
ゼロから考えないで既知の思想や他人、潮流に従ったほうがよい - Lambdaカクテル
常識は疑うほうが良い、みたいな妙な思考が頭の中にあって、何かを考えるときに無駄に根本的な所から考えてしまう。 例: 上の階がやかましいようだ 考える: そもそも夜間に振動を発生させるという行為に対する考え方は歴史的にどのように発展していったのか…… 普通こう考えたほうがいい: 管理会社に言ってみるか まったく無駄である。しかしなんか哲学的に考えたほうがカッコ良いみたいな謎のアレがあり、脳を無駄にしている。そのほうが言葉がポンポン出てきて面白いのだが、別にそういうことは既に世界のめちゃくちゃ賢い人が既に通過済みである。 speakerdeck.com 既に通過済みのパッセージを通ったところで劣化版の思考が、再生産されるだけだ。劣化してるので使えないし、再生産しているので無駄なだけだ。 良い書物はイシューに到達するまでの思考の過程をちゃんと再現してくれる。良い書物は基点となってくれる。良いとさ
レビュワーを"憑依"させて Pull Request をセルフレビューする - Konifar's ZATSU
メンバーと1on1をしていると、「うっかりミスが多くて Pull Request で毎回コメントをもらってから気づくのを何とかしたい」という相談を受けることがある。 まず、そういう認識を持てていることが素晴らしい。課題意識があるのであれば、どう補正していくかを一緒に考えることができる。 自分がオススメしているやり方は、レビューを依頼する前に徹底的にセルフレビューすることである。巷でよくやられている方法ではあるが、どういうやり方かを雑に書いておく。 レビューを依頼する前に レビュワーになりきって 自分の Pull Request を自分でレビューしてみる 頭にレビュワーが思い浮かぶのであれば、その人を "憑依" させるイメージ 「この人はここでこういうコメントしそうだな」と思ったら、 先回りして PR上にコメントしておくか、突っ込まれないようにコードやコードコメントを改善する タイトルや説明
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LLMの現在 - Speaker Deck
Javaの現状2024夏 / Java current status 2024 summer
エンジニアにも知って欲しいChatGPT基本テクニック - Qiita
