GitHub、Copilotでより高い精度のコードを生成させる方法を指南。関連ファイルを開く、トップレベルのコメントを書くなど
GitHub、Copilotでより高い精度のコードを生成させる方法を指南。関連ファイルを開く、トップレベルのコメントを書くなど 記事の中で、プログラマが意図したコードを高い精度で生成AIに生成させるためのテクニックがいくつも紹介されています。これらのテクニックはCopilotに限らず、生成AIを用いてコードを生成させる際の参考になると思われます。 この記事では、紹介されているテクニックのポイントをまとめてみました。 GitHub Copilotでよりよいコードを生成するためのポイント 生成AI活用の基本として説明されたのは、大規模言語モデルを用いた生成AIでは、コンテキスト（文脈）に基づいて予測を行うように設計されているため、生成AIに対する入力やプロンプトがコンテキストに富んでいるほど良い出力が得られる、という原則です。 それゆえ、GitHub CopilotおよびGitHub Copi
GitHub Organizationの安全な運用とモニタリングに関するスライド（全44ページ）を無償公開しました - Flatt Security Blog
はじめに こんにちは、株式会社Flatt Securityプロダクトマネージャーの小島です。Shisho Cloud というソフトウェアサプライチェーンに関するセキュリティ上の問題の発見から修正までを包括的にサポートする開発者向けセキュリティツールを開発しています。 shisho.dev 本日はこのサービスに関連して、GitHub Organizationを安全に運用していくためのベストプラクティス、そしてそのベストプラクティスがきちんと開発組織の中で運用されているかをモニタリングする方法についてまとめたスライドを公開しました。 スライドは下記のSpeakerdeckのURLより無料/登録不要で閲覧/ダウンロードいただけます。 https://speakerdeck.com/flatt_security/2022-github-org-best-practices この記事では、そのスライ
Jasper v1.0.0をリリースしました🚀（GitHub用のissueリーダー） - maru source
以前から開発しているJasper(GitHub用のissueリーダー)のv1.0.0をついに今日リース！やったー！前バージョンから作り直しレベルでコードを書き換えたので、かなり大変だったなぁ。でもそのおかげですごく良いものにできた！ jasperapp.io というわけで、こんにちは丸山@h13i32maruです。今日はJasper v1.0.0のリリース記事なのですが、GitHubを普段使ってる人にはJasperも是非使ってみてほしいので、少ししっかりめに書いてみました。よろしくおねがいします🙋 🕵️ Jasperとは（初見の方向け） JasperはGitHubのissueを柔軟に見ることができるツールです。例えば「nodejs/nodeのbugラベルがついたissue」「自分が作成したpull request」などの条件でissueを見たり通知を受け取れます。この条件はJasper
GitHubを使った開発であると便利なツール - Carpe Diem
概要 GitHubを使った開発で使ってるツールを紹介していきます。 どれもあると無いとでは開発スピードが大きく変わります。 Fork GUIのGitクライアントです。 git-fork.com 以前はSourcetreeを使っていましたが管理するファイルが増えると非常に重くなったのでリプレースしました。 メリット とにかく軽い タブ型なので複数リポジトリ見ても散乱しない 対話型のリベース・コンフリクト修正機能がある リポジトリの追加しやすい 無料 複数ブランチ扱ってる時に、取り込んでないコミットが非アクティブだから見やすい デメリット まだ開発途上でバグがいくつかある（コンフリクト解決したら別の変更ファイルが消えたり、など） ghq + fzf リポジトリ管理ツールのghqと github.com インクリメンタルサーチを可能にするfzfです。 github.com 以前はpecoを使って
GitHubが作った謎のAPI？BOT？ / Meet the Noopsで面白くてくだらない機能を作ってみよう！ - omuriceman's blog
なんだこの謎のサイトは・・・！GitHubが先日謎のサイトとリポジトリを作成していたのをご存知でしょうか？ noopschallenge.com 最初は全貌がよくわかっていなかったのですが、どうやらお題やAPIが用意されていてそれを使って面白い機能を作って公開するというプログラミングチャレンジが行われているようです。 紹介されているブログはこちら。 github.blog お題は毎週ごとに5問ずつ追加されるようで、現在はLevel2までのAPIを用意しています。 どんなAPIやお題があるの？ ドラムパターンを出力するAPI ベクトルを出力するAPI 上下左右の方向とスピードを出力するAPI 迷路を出力するAPI noops-challenge.github.io ポリゴンを出力するAPI 他にもあるので見てみると面白いですよ！ 自分も作ってみた ブログで紹介する以上、私も何か面白いものを作
GitHub-readyな社労士 @Takashi_U に就業規則の改定を依頼した - terurouメモ
デンキヤギという会社では、就業規則をGitHubで公開・管理しています。 github.com 就業規則というものは一回作れば終わりというものではなく、法改正や、運用後に気が付いた改善・考慮漏れに対応して、都度改定していく必要があります。ただし、改定するにも労働関連法やガイドライン等を逸脱しないようにする必要があるため、社労士のチェックが必要不可欠となります。 就業規則の初版を作成した際の流れは GitHubに会社の就業規則を公開した - terurouメモ でも書いていますが、名古屋市の中小企業向けの専門家派遣（同様の仕組みで中小企業庁 ミラサポにも専門家派遣がある）を使って作成しました。この時は、 私が全部markdownで執筆して、 印刷して、 社労士に紙でレビューしてもらって、 フィードバック事項をmarkdownに反映する 2-4を繰り返し、レビューOKになったら完了 というフロ
Kubernetes at GitHub
An overview of the on-premesis Kubernetes deployments that power 20% of GitHub's production services, and a review of the challenges GitHub faced and overcame during their Kubernetes journey. Presented at KubeCon in Austin. Slides with presenter notes are available here: https://schd.ws/hosted_files/kccncna17/44/kubernetes-at-github.pdf
GitHubだけで超高機能なスライド資料が作れる「GitPitch」の使い方を徹底解説！ - paiza times
どうも、まさとらん（@0310lan）です！ 今回は、ブラウザ上のGitHubでMarkdown（マークダウン）ファイルを作成し、そのまま超高機能なスライド資料に変換してくれるサービスのご紹介です！ もちろん、自分でMarkdownファイルを用意してpushするだけでもOKなのですが、今回はコンソール画面などは使わずにすべてブラウザだけで完結できる方法をご紹介致します。 【 GitPitch 】 ■「GitPitch」の基本的な使い方！ それでは、実際に簡単なスライド資料を作ってみましょう！ まず最初に、自分のGitHubアカウントでログインし、新規のリポジトリを作成しましょう！ 「① リポジトリ名」は好きな名前を付けてください。 画面下にある「② チェックボックス」をONにしてから「③ Create repository」ボタンをクリックしましょう。 すると、自動的に「README.md
【GitHub】1年以内に作成された人気リポジトリ20個をまとめました | HRナビ by リクルート
コードレビューや情報収集など、エンジニアの開発シーンに欠かせないGitHub。 技術者の興味関心や開発トレンドが詰まったサービスなので注目が集まることも多々。今年に入ってからはFreeCoodCampの総スター数が、長年トップだったbootstrapを上回ったことが話題になっています。 今回は、2015年9月30日〜2016年9月30日に作成されたリポジトリのなかでスター数が多いリポジトリ上位20個を集めました。 本稿のスター数、フォーク数は2016年9月30日9時現在の数値、メイン言語にはリポジトリ内の上位2言語を表示しています。 スター数が多い上位20リポジトリ 第1位：swift 2015年12月にオープンソース化したSwiftがスター数トップに。2016年9月13日にはSwift3.0がリリースされている。
GitHubのmasterブランチをWebページとして公開する手順（GitHub Pages） - Qiita
GitHubでは、サーバーを自前で準備しなくてもWebページを公開できる「GitHub Pages」という機能があります。これまでは、gh-pagesという別ブランチを作成して、そこにソースコードをプッシュする必要がありました。しかし、本日(2016/08/18)実装された新機能により、masterブランチのみでWebページを公開できるようになりました。 本エントリーでは、具体的な設定手順を紹介します。 手順 masterブランチにて、「docs」フォルダーを作成します。このフォルダーに公開したいWebページのソースコードを入れます。 masterブランチをプッシュします。 GitHubのリポジトリページ上で、[Setting]→[Pages]に移動します。 [Source]の箇所から、「Branch: main」、「/docs」フォルダーを指定します。 [Save]を押すと、下図の赤枠部
イケてる感じにソースコードをブログに載せよう！ - Milkのメモ帳
2016 - 06 - 29 イケてる感じにソースコードをブログに載せよう！ 日記 IT関連 GitHub イケてる感じに載せてる方がいる！ Gistを利用する Gistにファイルを作成する はてなブログに貼り付ける プログラムソースの貼り付け結果 はてなブログ以外の場合 普段、私はこのブログの編集方法は「 はてな記法 」を使っています。 慣れればそっちの方が早いし、それはいいんですけど・・・ 私気づいてしまったんです。 プログラムソースが見にくい！！ イケてる感じに載せてる方がいる！ www.ksakae1216.com コウタロウさんのブログを読んでいて、「イケてる感じにソースを載せてるじゃん！！いいなぁ〜」と思っていました。 そして、よくよく見てみると・・・気づいてしまった！ 「hosted with ❤ by GitHub 」 なぬ？！ github だと？！ そうです。以前書い
GitHub に *.github.io という URL の Web サイトを作る - ablog
今更だけど、GitHubを使って3分でHPを公開する。 - Qiita を参考に GitHub に Web サイトを作ってみた。 ブラウザで GitHub にログインする。 [New repository] をクリックし、"Create a new repository" というページに移動する。 [Repository name] に "GitHubアカウント名.github.io(例: yoheia.github.io)" と入力し、"Create repository" をクリックする。 作成したリポジトリの [Settings] をクリックする。 [GitHub Pages]-[Launch automatic page generator] をクリックし、"New user site" ページに移動する。 [Continue layouts] をクリックし、"Choose a t
GitHubのトレーニングに役立つリンク集 - ikeike443のブログ
※最初に断っておきますが、この記事はもちろん、このブログ全体もそうですが、私の個人ブログであって、会社の公式見解とは一切関係ありません 自分のチームや会社でGitHubを使いたいんだけど、チームメンバーにGitHubを使ったことのある人が自分以外いないよ、みたいなケースがあるかと思います。 そんな時に役立つリンク集を紹介しておきます。 英語のリソース GitHub Guides Mastering Markdown Mastering Issues Understanding GitHub Flow GitHub Training YouTube channel GitHub Services curriculum "Kit" GitHub for Developers GitHub for Everyone Pro Git 2 eBook GitHub Git Cheat Sheet P
XcodeからgitとGitHubを使う方法・基本編 - 開発メモ
Xcodeで開発を行うときに、gitやGitHubとあわせて使う方法について調べてみたのですが、いまいち、しっくりくるサイトが見つからなかったので自分でまとめてみました。 ここでは、以下のような情報についてまとめてあります。 プロジェクトと同時にリポジトリを作成 とにかくコミットが大事 GitHubのリポジトリを登録 GitHubにプッシュ あくまで基本編と言う事で、あまり難しい話はしません。 （SSH鍵を登録する話やgitignoreの話は無し） 応用編はこちら。 XcodeからgitとGitHubを使う方法・応用編 - 開発メモ http://seeku.hateblo.jp/entry/2016/03/02/232151 動作を確認した環境 環境 情報 Xcode 7.2.1 (7C1002) iOS 9.2 Swift 2.1.1 Date 2016/2/25 基礎知識編 gitと
GithubでTILというリポジトリが流行りつつあるのかもしれない - 生涯未熟
Githubで海外のエンジニアさんをフォローしているのですが、あるエンジニアさんがtilというリポジトリをstarしていました。 github.com 「なんか新しいツールか何かかな？」と思ったのですが、覗いてみたらdescriptionに"Today I learned"の文字が。 どうもtilというリポジトリを作成してそこに"今日覚えたこと"を書いていくのがプチ流行している様子。 ・ 色んなTILが 今までだと同じような感じでベストプラクティス等をまとめた"◯◯-awesome"が流行ってましたが、 自分が何を学んでいっているのか自分も他人にも知ってもらうためにこういうリポジトリを作って書いていくのも面白そうですね。 関連したWebサービスとかが作成されたらそれはそれでまた面白いのかも。
GitHubのPull Requestを簡単にチェックアウトするたった1つの方法 - アジャイルSEの憂鬱
みんな知ってるものだと思ったけど、あまり周りで知ってる人がいなかったのでブログに書いた。 こういう釣りタイトルっぽいブログ、一度書いてみたかった。 参考 Checking out pull requests locally - User Documentation 参考というか、そのままだけど。 方法 Pull Requestの ID を BRANCHNAME にfetchします。 *1 $ git fetch origin pull/ID/head:BRANCHNAME ブランチをcheckoutします。 git checkout BRANCHNAME これだけです。forkした人のリポジトリを remote add する必要はないです。 おまけ マージ後のsha1 ちなみに、Pull Requestのマージ前だと、 pull/ID/merge を使うこともできます。 $ git fet
Circle CIでbundle updateのPull Request作成を自動化する手順 - ppworks.jp
日々、bundle updateしてますか！ circleci-bundle-updateとcircleci-bundle-update-prを使って、bundle updateの Pull Requestを自動化する手順をまとめてみます。作者の記事を読めばいいっちゃいいんですが、地味に抜けていた手順と各ステップは何のために必要かを整理してみました。 このgemは、Pull Requestに各gemの差分リンクを貼ってくれるのが便利だな！って思って採用してます。素敵なgemをありがとうございます。 github.com github.com ステップは CircleCI経由でbotからgithubにpush出来るようにしておく CircleCI経由でbotからgithubにPR作れるようにしておく 外部からCircleCIへbuild指示できるようにする 外部からcronでCircleCI
Pelletkachels.nl
Pelletkachels waren ooit eenvoudige apparaten voor verwarming, maar ze hebben een opmerkelijke evolutie doorgemaakt sinds hun bescheiden begin in de jaren ’80 van de vorige eeuw. In dit artikel duiken we diep in de geschiedenis van pelletkachel, bespreken we de belangrijkste mijlpalen en ontwikkelingen op het gebied van subsidiemogelijkheden en werpen we een blik op de transformatie tot moderne en
複数のエンジニアと開発を円滑に進めるためのissueの立て方 - クックパッド開発者ブログ
こんにちは。クックパッド特売情報ディレクターの田中です。 前回ヘルスケア事業部の濱田くんのエントリーでエンジニア以外のGitHubの利用について紹介されていましたが、今回は私がチーム開発で実践しているissueの立て方についてご紹介したいと思います。 チームが大きくなってきてヒズミが生じてきた 本来、ディレクターが開発を伴わない価値検証を十分に行った上で仕様を考え、デザイナー・エンジニアに引き継ぐのが理想的だと思います。 私自身も当初はその開発の進め方を採用していましたが、チームが大きくなり、ディレクター１人で関わるエンジニアが増えてくると、状況は変わってきました。 マルチタスク的に仕様を考えていたために詰めが甘い部分が多く、手戻りが発生してしまったり、仕様の準備が追いつかず、エンジニアの手が空いてしまうことが増えてしまったのです。 当初は自分自身の頑張りが足りないからだと、徒に気合いと根
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自称日本一GitHub Projectsを使っているので魅力を伝えたい！ / i call myself the best github projects user in japan so ill show you how i use it
