並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 23 件 / 23件

新着順 人気順

subversionの検索結果1 - 23 件 / 23件

  • ソースコードをリポジトリ丸ごとLLMに読んでもらう方法

    はじめに ソースコードをLLMに読んでもらうとき、単一ファイルだと楽なのですが、GitHubのリポジトリのように複数ファイルから構成されるプロジェクトだと困ってしまいますね。 リポジトリごとLLMに読んでもらえるようにいい感じにテキスト化できると良いですね。そんなソフトがありました。しかも2つ。 両方ともほとんどコンセプトは同じです。特に後者のgenerate-project-summaryは使い方も含めて、自分のやりたいことが、すでに開発者の清水れみおさんが以下の記事にまとめていました。 なので、あんまり書く必要ないのですが、せっかくなのでgpt-repository-loaderの使い方と、出力したファイルの別の活用方法について書いてみたいと思います。 gpt-repository-loaderでリポジトリをテキストに変換 使い方はREADMEに書いてあります。シンプルなソフトなので、

      ソースコードをリポジトリ丸ごとLLMに読んでもらう方法
    • 結局 Git のブランチ戦略ってどうすればいいの? - Qiita

      1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ

        結局 Git のブランチ戦略ってどうすればいいの? - Qiita
      • ソースコード管理の進化:Excel管理からGitHubまで、エンジニアの戦いを振り返る! - Qiita

        ソースコード管理の進化:Excel管理からGitHubまで、エンジニアの戦いを振り返る! プロローグ 先日、弊社のとある案件内での会話です。 熟練エンジニア(以降「熟練」と表記):GitHubのプルリクが来てたからコードレビューしておいたよ。 若手エンジニア(以降「若手」と表記):ありがとうございます。助かります。 熟練:他の人のコードにも指摘した内容がキミのコードにもあったので指摘しておいた。他の人のプルリクは見ていないの? 若手:いや、他の人のプルリクは見てないですね。。 必要ですかね・・? 熟練:必要だよ。昔はそういうのやりたくてもできなかったんだから! 若手:(はじまった、熟練さんの昔語り・・。長いんだよなぁ。。)なるほど!そうなんですね。他の人のコード読んで勉強します! はじめに 皆さん、こんにちは。エンジニア歴約20年目の立脇です。今日は、エンジニアにとって切っても切り離せない

          ソースコード管理の進化:Excel管理からGitHubまで、エンジニアの戦いを振り返る! - Qiita
        • あなたのパフォーマンスを倍にする Frontend Ops の傭兵はいかがですか

          あなたのパフォーマンスを倍にする Frontend Ops はいかがですか.md あなたのプロジェクトに Frontend Ops を。 [経営者の方へ] ウェブサイトが遅くなっていませんか?機能追加が遅くなっていませんか? 私 @mizchi は Node.js とフロントエンドのエキスパートです。もし私を知らなければ、御社のフロントエンド担当に mizchi とは誰か聞いてみてください。それが一番早いと思います。 Frontend Ops の専門家として御社のプロダクトの改善にご協力します。 Frontend Ops は、ウェブサイトのロード時間を改善したり、開発者の基盤に手を入れることで一日に何度機能を追加できるかという指標に貢献するロールです。その結果としてUXを改善し、ビジネスを前進させます。 成果報酬で、費用はざっくり 100万円*達成率 となります。(詳細は後述) 弁護士作成

            あなたのパフォーマンスを倍にする Frontend Ops の傭兵はいかがですか
          • 「Winamp」のソースコードが公開 ~かつて一世を風靡した伝説的メディアプレイヤー/独自ライセンスで「GitHub」に

              「Winamp」のソースコードが公開 ~かつて一世を風靡した伝説的メディアプレイヤー/独自ライセンスで「GitHub」に
            • 【GitHub】個人学習をGitHubでレベルアップさせる話

              はじめに ご覧いただきありがとうございます。Gonです! 巷では、GitやGitHubに関する話が話題ですね。 エンジニアでGitを触ったことない人は本当に「やばい」のか? そんなことは知りません。 Gitでのバージョン管理やGitHubの運用方法については、既に多くの記事で解説されているので、ここでは触れずにいこうと思います。 今回の記事では、普段の学習に『GitHub』を取り入れたことで、日々の学習がより楽しく継続できるようになり、結果としてスキルアップできた実体験についてシェアしていきます。 皆さんのエンジニアライフに、少しでも良いキッカケになれば嬉しいです。 GitHubを活用した方が良い理由 まずは、こちらの動画をご覧ください。 正直、意味は分かりません。 アニメーションが凄すぎて話が入ってきませんでした。 要約すると、こんな感じです。 GitHubは世界最大のソフトウェア開発プ

                【GitHub】個人学習をGitHubでレベルアップさせる話
              • リベラル派は構造主義者なのに自由意志を認めているのはおかしい

                人種差別の問題、経済格差の問題、男女差別の問題 これらをリベラル派は「構造的な要因」に原因を求めている 「構造的な要因」に原因を求めるということは、人間の行動は構造によって決定されるという考え方をとっているわけで、自由意志を否定している にも関わらず、自由意志をリベラル派は尊重しているのである 例えば、アファーマティブアクションとして、理系の大学に女子枠を作る話などもそうである 構造的な要因で、女性が理系の大学に進学できないという説明をするのならば、当然にしてそこに人間の自由意志はない しかし、リベラル派は「女性は構造的な要因で理系の大学に進学できない」「女性の自由意志で大学を選べるようにするべき」という二つを主張しているのである これは明らかにおかしい 自由意志を認めるならば、有名大学に黒人が少ないのも、経済格差があるのも、議員に女性が少ないのも、全て「自由意志の結果」のはずである 自由

                  リベラル派は構造主義者なのに自由意志を認めているのはおかしい
                • Go製アプリケーション/ライブラリにおけるメンテナンス性を重視したGoのバージョン管理戦略 - Diary of a Perpetual Student

                  2024-08-28 GOTOOLCHAIN=auto時にはtoolchainディレクティブに指定したものより新しいGoがインストールされていても戻るわけではないという話を追記しました。 Go言語では半年に1回メジャーリリース(マイナーバージョンの更新)がやってきます。ちょうどこの8月にGo 1.23がリリースされたばかりです。Go言語のメジャーリリースは最新2つ分までサポートされるポリシーであることがhttps://go.dev/doc/devel/releaseに書かれています。現在であればGo 1.23やGo 1.22はサポートされており、Go 1.21はサポートが切れているということです。 また、サポートされているバージョンでは、不定期でマイナーリリース(パッチバージョンの更新)がやってきます。バグ修正や脆弱性対応がメインですね。 Goがリリースされると、Goでアプリケーションを作

                    Go製アプリケーション/ライブラリにおけるメンテナンス性を重視したGoのバージョン管理戦略 - Diary of a Perpetual Student
                  • 実務未経験者の人に読んでほしいGitHubの実務tips - Qiita

                    更新履歴 2024-09-05 masterをmainブランチにし、masterに対する言及をしました。 httpsかsshか、についてはいろんな見方があることを追記 「PRの作成タンを押したら終わりではない」の項目を追加 はじめに 株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。 ※ シンシアにおける働き方の様子はこちら この記事は プログラミングを学び出したばかりの人 エンジニアとして働きだしてGitHubを使い慣れていない人 という人向けに、共通してやってほしいなと思って、いつも言っていることを一般向けに書いたものです。 ぜひ読んで見ていただけると嬉しいです。 ※ Githubとはなにか、具体的なGitの操作に関してはこの記事では割愛させていただきます。 git cloneするとき Githubでは、https, sshによるgi

                      実務未経験者の人に読んでほしいGitHubの実務tips - Qiita
                    • Railsのマイクロサービスアーキテクチャで構成されたアプリをモノレポ構成に移行した話 - Sansan Tech Blog

                      こんにちは。技術本部Sansan Engineering Unit Master Data Groupの古本です。 普段は、営業DXサービス「Sansan」の名刺交換した人や企業に関するニュースを表示し、お知らせする「企業ニュース」や「企業情報」を扱うシステムの開発をしています。 最近、マイクロサービスで作られた企業ニュースのシステムをモノレポ構成に移行しました。 今回はその時に行ったことについて話します。 モノレポ(mono repo)とは 本ブログで類似の記事があったので引用します。 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 今回も複数レポジ

                        Railsのマイクロサービスアーキテクチャで構成されたアプリをモノレポ構成に移行した話 - Sansan Tech Blog
                      • GitHubがうまくいった理由を共同創設者が解説

                        世界最大のソフトウェア開発プラットフォームであるGitHubは2008年にリリースされ、2023年には開発者が1億人を突破するほどの規模に成長しました。そんなGitHubの共同創業者であるスコット・チャコン氏が、「一体なぜGitHubは成功したのか」について自ら解説しています。 Why GitHub Actually Won https://blog.gitbutler.com/why-github-actually-won/ チャコン氏によると、GitHubの共同創業者である4人はそれ以前に別のサービスを立ち上げた経験があり、製品としての品質もセンスも良かったものの、市場の環境やタイミングが合わなかったためそれほど成長できなかったとのこと。それなのにGitHubが成功した理由について、チャコン氏は「適切なタイミングで立ち上げたこと」「センスが良かったこと」の2つに要約できるとしています。

                          GitHubがうまくいった理由を共同創設者が解説
                        • Cursor の無料版を使い続ける場合の設定 - Qiita

                          Cursor の Pro 版でサポートされる AI 機能は非常に強力であり、無料版と比較して多くのメリットがあります。しかし、個人開発者や学生など予算に限りがある人にとっては、Pro 版の利用は難しい場合があります。 本記事では、Cursor の無料版で Gemini や GitHub Copilot を設定することで、Pro の使用感に近付ける方法を紹介します。 Gemini は無料枠があります。 GitHub Copilot は基本的に有料ですが、学生・教職員や OSS 開発者への免除があるため、無料で利用できる場合があります。 概要 単純に VS Code を Cursor の無料版に置き換えた場合、差分としてよく使う機能は以下の通りです。 AI Chat でのメンション:Codebase (RAG)、Git、ファイル指定 RAG を別途構築する手間がないのは便利です。 Git 機能

                            Cursor の無料版を使い続ける場合の設定 - Qiita
                          • ファインディでのGitHub Actions高速化の事例 - Findy Tech Blog

                            ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 弊社では、数年前に社内のCI環境をすべてGitHub Actionsに移行しました。 この記事では、弊社のGitHub Actions活用事例の内、CI高速化についてご紹介します。 なぜCI高速化に力を入れるのか CI高速化 キャッシュの活用 ジョブの並列化 Larger Runners まとめ なぜCI高速化に力を入れるのか 当ブログをはじめ弊社では、たびたびCI高速化の大切さについて言及しています。 Findyの爆速開発を支えるテクニック - Findy Tech Blog RailsのCIのテスト実行時間を 10分から5分に高速化した話 - Findy Tech Blog Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog これはなぜでしょう

                              ファインディでのGitHub Actions高速化の事例 - Findy Tech Blog
                            • OSS 推進観点で Supabase の GitHub 設計が参考になった - ROUTE06 Tech Blog

                              こんにちは。ソフトウェアエンジニアの id:masutaka26 です。最近は社内プロダクトの OSS 化を推進する活動をしています。 先日、GitHub の Issue テンプレートを調査しました。その中で Supabase が参考になったので共有します。 1. New Issue からの導線 コラム: Issue テンプレートはどこにある? 2. Discussions のカテゴリ設計 Categories Most helpful まとめ 1. New Issue からの導線 これが Supabase の Issue テンプレートです。 🔗 https://github.com/supabase/supabase/issues/new/choose New Issue on supabase/supabase ②に興味を惹かれました。いずれも GitHub Organization

                                OSS 推進観点で Supabase の GitHub 設計が参考になった - ROUTE06 Tech Blog
                              • 主要なAIコードアシスト機能の比較。GitHubが先行し、GitLab/Google Cloud/AWSが追いかける。ガートナーがマジッククアドラントを発表

                                主要なAIコードアシスト機能の比較。GitHubが先行し、GitLab/Google Cloud/AWSが追いかける。ガートナーがマジッククアドラントを発表 AIコードアシスト機能を提供している主要各社は、調査会社の米ガートナーが作成したAIコードアシストを比較調査したマジッククアドラントの自社の位置づけをプレスリリースで発表しています(GitHub、AWS、GitLab、Alibaba Cloud)。 マジッククアドラントとは、縦軸に「実行能力」、横軸に「ビジョンの完全性」を持つ平面図上に主要なベンダや製品を位置づけていくというものです。図の右上にあるベンダほど、より高い実行能力とビジョンの完全性を備えた、すぐれたベンダや製品と位置づけられています。 そして図全体を4つの象限に分けて、右上がリーダー、右下が概念先行型、左下が特定市場指向型、左上がチャレンジャーと分類しています。 下記がガ

                                  主要なAIコードアシスト機能の比較。GitHubが先行し、GitLab/Google Cloud/AWSが追いかける。ガートナーがマジッククアドラントを発表
                                • ファインディでのGitHub Actions自動化の事例 - Findy Tech Blog

                                  ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 GitHub Actionsは、CI/CD以外にも様々な業務の効率化に役立ちます。 この記事では、弊社で実施しているGitHub Actionsを使った自動化について紹介します。 自動化 担当者アサイン ラベル設定 リリース QAチェック項目の抽出 定期実行 まとめ 自動化 担当者アサイン 開発フローの中では、Pull requestを作ってからレビューに出すまでにいくつかのタスクを行うことがあります。 弊社では、Pull requestの作成者がAssignee(担当者)となる場合が多いため、↓こちらのActionを用いてアサインの自動化をしています。 github.com - uses: kentaro-m/auto-assign-action@v2.0.0 with: repo-token: $

                                    ファインディでのGitHub Actions自動化の事例 - Findy Tech Blog
                                  • 「nginx」プロジェクトが「GitHub」へ正式に移行 ~HTTP/リバースプロキシサーバー/バージョン管理も「Mercurial」から「Git」へ

                                      「nginx」プロジェクトが「GitHub」へ正式に移行 ~HTTP/リバースプロキシサーバー/バージョン管理も「Mercurial」から「Git」へ
                                    • [アップデート] AWS CloudFormation の Git 同期機能がプルリクエストにスタック変更内容をコメントしてくれるようになりました | DevelopersIO

                                      [アップデート] AWS CloudFormation の Git 同期機能がプルリクエストにスタック変更内容をコメントしてくれるようになりました いわさです。 AWS CloudFormation は Git リポジトリとスタックを同期させて、簡易的な CI/CD 環境を用意することが出来ます。 今朝のアップデートでこちらが強化され、CloudFormation がプルリクエストにスタックへの変更内容をコメントしてくれるようになりました。 Git 同期では CloudFormation が特定のブランチを監視し、変更が発生すると自動でスタックがプロビジョニングされるような動きとなっているのですが、このアップデートではユーザーが作成したプリリクエストのマージ先が監視対象のリポジトリだった場合、マージ前でスタック変更セットの内容をプルリクエスト上でコメントしてくれます。 これによってレビュー

                                        [アップデート] AWS CloudFormation の Git 同期機能がプルリクエストにスタック変更内容をコメントしてくれるようになりました | DevelopersIO
                                      • Gitを触ったことのないエンジニアがヤバいと言われる理由を考えた - Qiita

                                        これは何? TwitterでGitをさわったことのないエンジニアがヤバイという発言が物議を醸していたのでなぜヤバイと言われるのかを考察しました。 考えられる理由 業界標準への理解が低い/業界の大局を追えていないように見える 現代のソフトウェア開発のバージョン管理のデファクトスタンダートがGitです。 基本的には,Gitリポジトリのホスティングサービスである,GitHubやGitLabを使うパターンが多く,こういったサービスを使うことで現代の開発フローは実現されていると思います。 そのため,Gitを使ったことがないと業界のお作法的なものができていないと思われてしまう可能性があると考えられます。 最新技術へのアンテナが低そうに見える 現代のOSSのほとんどがバージョン管理にGitを使用しており,GitHubやGitLabにソースコードを公開しているパターンが多いです。。そのため,OSSのコント

                                          Gitを触ったことのないエンジニアがヤバいと言われる理由を考えた - Qiita
                                        • AWSが予告なしに「CodeCommitによるGitの提供」を取りやめ 他のサービスへの影響は?

                                          AWSが予告なしに「CodeCommitによるGitの提供」を取りやめ 他のサービスへの影響は?:「機能的には既に“放棄”されていた」という意見も TechTargetは、「AWSによるCodeCommitとCloud9の閉鎖通知」に関する記事を公開した。AWSは事前の予告なしに、6つのサービスで新規ユーザーの受け入れを停止した。これを受け、一部の業界関係者はアップデートの頻度が低い他のAWSサービスの将来に疑問を投げかけている。

                                            AWSが予告なしに「CodeCommitによるGitの提供」を取りやめ 他のサービスへの影響は?
                                          • Why GitHub Actually Won

                                            A few days ago, a video produced by @t3dotgg was posted to his very popular YouTube channel where he reviews an article written by the Graphite team titled “How GitHub replaced SourceForge as the dominant code hosting platform”. Theo’s title was a little more succinct, “Why GitHub Won”. Being a cofounder of GitHub, I found Greg’s article and Theo’s subsequent commentary fun, but figured that it mi

                                              Why GitHub Actually Won
                                            • Git|作業ブランチ名を常にターミナルへ表示したい(Mac) - Qiita

                                              はじめに エンジニアのみなさま、日々の学習本当にお疲れ様です! また本記事まで足を運んでいただき本当に感謝です。 約2分程度で読めるので最後まで読んでもらえると幸いです。 ======================================================= 開発中に作業ブランチを確認するとき、毎回『git branch』コマンドを入力して確認してませんか?ちなみに私はずっと入力してました...w 業務効率を上げるために何か良いものはないかと探していたときに 『Oh My Zsh』 に出会いました。 遊び心のあるフレームワークで個人的にとても好きですw 今回はこのフレームワークを活用して作業ブランチ名を常に表示させるための手順をご紹介したいと思います! こんな形で表示されます さっと見たい人向け

                                                Git|作業ブランチ名を常にターミナルへ表示したい(Mac) - Qiita
                                              • なぜGitHubはここまで成功したのか — その歴史を振り返るブログ記事が海外で話題に

                                                9月10日、GitButlerが「なぜGitHubが勝ったのか」と題したブログ記事を公開した。この記事では、GitHubが他のプラットフォームと比較してどのように成功を収めたのか、そしてその背後にある要因について詳しく紹介されており、海外で多くの人々に読まれている。以下に、その内容を紹介する。 GitHubが成功した理由 GitHubの成功は、単に技術的な優位性だけでなく、いくつかの重要な要因が相互に作用した結果である。その要因は、主に以下の2点に集約される。 タイミングの良さ GitHubが登場したのは、分散型バージョン管理システム(DVCS)が徐々に普及し始めた頃であった。2005年にGitが誕生し、これまでの集中型バージョン管理システム(SVNやCVS)が持つ問題点を解決するツールとして注目され始めた時期だった。特にオープンソースプロジェクトの拡大に伴い、集中型のシステムでは対応が難

                                                  なぜGitHubはここまで成功したのか — その歴史を振り返るブログ記事が海外で話題に
                                                1