GitHubの調査により開発者の92％がAIコーディングツールを愛用している実態が判明
コードも記述できる文章生成AIやコーディング支援ツールの「GitHub Copilot」などの登場により、コーディングを行う開発者の業務は効率化しつつあります。GitHubが調査機関を通じて実施した調べにより、開発者の92％が何らかの形でAIコーディングツールを使用していることが明らかになりました。 Survey reveals AI’s impact on the developer experience | The GitHub Blog https://github.blog/2023-06-13-survey-reveals-ais-impact-on-the-developer-experience/ Surprise! GitHub finds 92% of developers love AI tools • The Register https://www.theregis
GitHub Actions と Release Please を使ったアプリケーションのリリース自動化 - Classi開発者ブログ
GitHub Actions と Release Please を使ったアプリケーションのリリース自動化 こんにちは @lacolaco です。最近は、先日プレスリリースが出された「学習トレーニング」機能を裏で支えているコンテンツ管理システム（以下内部CMS）の開発に携わっています。 corp.classi.jp この記事では、内部CMSのフロントエンド（Angular アプリケーション）のリリースフローを自動化している仕組みを紹介します。現在のリリースフローの全体像は次の図のようになっています。この中にある Release Please というのが、今回特に紹介したいツールです。いくつか日本語でのブログ記事などもあるので特にマイナーというわけではないと思いますが、多くの場合はライブラリのリリースに使われています。一方、アプリケーションのリリースで使っているケースはあまり発信されてないよう
Gitのコミットメッセージは適当に書いてる - Mitsuyuki.Shiiba
「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。 僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。 しっかり書きたいとき 僕が、コミットメッセージをしっかり書きたいときはどういうときだろう？って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと
【AWS CDK】インフラ変更内容をGitHub ActionsでPRに自動コメントする - Qiita
前提 aws cdk v2 typescript やりたいこと aws cdkで構成したインフラ環境の変更点をprで確認したい やりかた github actionsのymlを作成して、起動条件をpull_requestにして 以下の処理を好きなステップに記載 # ~省略~ - name: diff run: npm run cdk diff > diff.txt env: AWS_DEFAULT_REGION: 'ap-northeast-1' AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} - name: Comment PR with CDK Diff uses: actions/github-script@v
GitHubでAWS SESのメールテンプレートを管理するワークフローを構築する - Qiita
困ったこと 業務でAWS SES(Simple Email Service)のemailテンプレートを利用していて、便利なんだけど変更に弱いのがﾋﾞﾐｮｰだった。 テンプレートを変更するためにコマンド打って既存テンプレートを取得して、jsonファイル作って変更してまたテンプレート変更のコマンドを打たなければならない。面倒な上にミスに気付きにくい・管理しにくいと言うデメリットがあった。 んでワークフローに組み込もうと思って調べても記事が少なかったので備忘録にする。 実現したいこと 本番環境を管理するブランチ(prd)にメールテンプレートを管理するjsonファイルの変更(追加・削除)がマージ(もしくは直push)された時、本番環境のSESのテンプレートを変更する処理を走らせるようにする。 書くこと Github Actionsのyaml記載に関して 特定のファイルの差分の取り方について 書かな
「Bluesky Social」アプリのコードベース、「Github」で公開
ベータ版として提供されて人気を集めている新しいソーシャルネットワーク「Bluesky」が、オープンソース化に向けて大きく一歩前進した。2023年5月15日に、「Bluesky Social」アプリのコードベースが、GitHub上でオープンソースとして公開された。これは、同社の計画に沿った動きだ。同SNSを運営する公益目的の合同会社（PBLLC）のBlueSkyは当初から、「オープンで分散型」ソーシャルネットワークの構築を掲げていた。 オープンソース化がまだうまく進んでいないTwitterとは異なり、Blueskyのクライアントコードは、コードの改善に取り組みたい人や、これを独自のソーシャルネットワークの基盤として使用したい人など、あらゆる人を対象に公開されている。 MIT Licenseの下でライセンス供与されるBlueskyのコードは、現在使用可能だ。実際、公開されたばかりにもかかわらず
Stable Diffusion開発元、独自の大規模言語モデル「StableLM」をGitHubで公開し、商用利用も可能。チャットAI「StableChat」は数カ月後 | テクノエッジ TechnoEdge
Stable Diffusionの開発で知られるAI企業Stability AIは、オープンソースの大規模言語モデル（LLM）「StableLM」を発表しました。 現在GitHubで公開中のアルファ版では30億パラメータと70億パラメータのモデルを提供。GitHubリポジトリで公開しています。150億パラメータから650億パラメータのモデルも提供する予定です。ライセンスはCC BY-SA-4.0で、商用または研究目的で利用できます。 GPT-3と比較して小規模なパラメータ数であるにも関わらず、「会話やコーディングのタスクで驚くほど高い性能を発揮する」という性能をうたう背景には、1.5兆トークンのコンテンツを含む、実験用データセットがあると説明しています。 StableLM with human feedback (RLHF) でファインチューニング（微調整）された研究モデル一式も公開。Al
ジョブを細かく分けてGitHub Actionsのテストを効率化する
改善戦略 実行のタイミングやGitHubの状況や依存サーバーのネットワークの状況によって変動はあるものの、早くて7分、だいたい10分〜15分くらいかかっている。早いか遅いかは、他の開発と比べても内容や状況が違うのでなんとも言い難いが、個人的な感想としては「遅い」。というより、一切の工夫をしていなかったので、もっと早くできるはずだと考えた。 ビルドされたファイルを複数の環境で共有する 処理全体の中で時間がかかっている処理は3つ。 依存パッケージのインストール ビルド テスト さらに、課題の一つとして「テスト実行時に開発用依存パッケージ（devDependencies）がインストールされているせいでテストが失敗しない問題がある」というものがあり、これを処理に追加しないといけない。 開発用依存パッケージのインストール ビルド 依存パッケージを一旦すべて削除 本番用依存パッケージのインストール テ
OSSで新機能要望やバグ報告を全てGitHub Discussionsに起票してもらうことにしてみた - knqyf263's blog
今回の案は自分のメンテナンスしているOSSだと回りそうという話で、これが他のプロジェクトにとっても良いと勧めているわけではないです。 ふーんそういう運用をしているところもあるんだと思って読んでもらえればと思います。 要約 背景 質問への回答 バグ報告のノイズ バグと言われることの精神的苦痛 新機能要望 Issuesの横の数字が増えていくことへの嫌悪感 Issues対応への強迫観念 マイルストーン決めるときにタスクの選定が面倒 運用案 利点 タスクの分離 コミュニティ内のコミュニケーション促進 メンテナの精神的負担軽減 懸念 アサインができない 参照しているIssuesが表示できない トリアージが終わっていないバグはissueにならない 再現ができないバグはissueにならない ユーザがバグ起票後にすぐPRを作ることができない 実現方法が思いつかないだけで追加したい新機能がissueにならな
実行時間ベースでテストを分割するGitHub Action
GitHub Actionsでテストファイルを複数ノードに適切に分割するためのカスタムアクション、r7kamura/split-tests-by-timingsを作った。 CircleCIに同様の仕組みがあり、今回はこれのGitHub Actions版が欲しかった。 既存ツールとして、Go製のleonid-shevtsov/split_testsというCLIツールがあり、これを利用するchaosaffe/split-testsというカスタムアクションがある。 このカスタムアクションでも不足は無かったが、幾つかの理由で今回自作するに至った。 しばらく使いそうなので、保守性を上げるためにも、不要な機能を取り除いて必要最低限の機能にしたかった GitHub Actionsは仕様変更が多いため、自分で保守できるようにしたかった 今回、内部実装としてRust製のmtsmfm/split-testとい
3分でお手軽にReactアプリをGithub Pagesにデプロイする方法🍞 - Qiita
Reactアプリを作成できたが、どうやってデプロイ（公開）すればいいのだろう。。。？ 今回は、GitHubが提供するGitHub Pagesというサービスで Reactで作成したアプリをGitHub Pagesにデプロイする手順をご紹介します。 必要なもの（前提条件） Node.jsとnpmがインストールされた開発環境 GitHubアカウント GitHub PagesにデプロイしたいReactアプリ 手順 Githubリモートリポジトリを作成 まず最初に、Reactアプリを保存するためのGitHubリモートリポジトリを作成します。 このリポジトリは公開（Public）リポジトリにして下さい。 gh-pagesをインストール GitHub Pagesと連携するパッケージgh-pagesをインストールする必要があります。 以下のコマンドを実行してインストールしましょう。 package.jso
ミクシィ、新卒向け研修資料を無償公開 「Git」と「テスト・設計」 今後も随時公開
MIXI（旧社名ミクシィ）は5月8日、同社の新入社員向け技術研修で使用した資料を無償公開した。分散型バージョン管理システム「Git」とテスト・設計研修の資料をスライド共有サービス「Speaker Deck」で公開中。動画も後ほど公開するという。 Gitの研修資料は約470ページあり、Gitを使ったチーム開発の進め方やGitの内部構造などを記載している。テスト・設計研修の資料は約40ページ構成で、テスト技法やコードレビューのコツなどを紹介。いずれの資料も同社の社員が作成した。 同社は2021年から新入社員向け研修の資料を一般公開しており、22年はUnityでのゲーム開発やAI、セキュリティ研修など全12種類の資料を自社ブログに掲載していた。同社の公式Twitter（＠mixi_engineers）は「今後も随時資料や動画を公開していく」としている。 関連記事 ミクシィ、技術カンファレンスを初
GitHub ActionsからOIDCでCredential情報を使わずにAWSと連携 - Qiita
はじめに 今更ながら、GitHubとAWSをOIDC（OpenID Connect）で連携して、GitHub ActionsからS3へ連携したので、やり方について記載 OIDC そもそもOIDCってなんだっていう人は、ChatGPTさんに聞いたら以下をおすすめしてくれたので、記載しておきます。 その上で、GitHubの該当ページには、以下のように説明がありました。 No cloud secrets: You won't need to duplicate your cloud credentials as long-lived GitHub secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-l
【GitHub Copilotは序章に過ぎない!?】GitHub Next、次世代の開発エクスペリエンスを実現する圧倒的なプロジェクト群 | DevelopersIO
Flat explores how to make it easy to work with data in git and GitHub. It builds on the “git scraping” approach pioneered by Simon Willison to offer a simple pattern for bringing working datasets into your repositories and versioning them, because developing against local datasets is faster and easier than working with data over the wire. (日本語訳) Flat は、git と GitHub でデータを簡単に操作する方法を探ります。これは、Simon Wi
あなたの会社でオープンソース担当部門を立ち上げて機能させるには？ GitHubがドキュメント群をオープンソースで公開
この記事は新野淳一氏のブログ「Publickey」に掲載された「GitHub、あなたの会社にオープンソース担当部門「Open Source Program Office」を立ち上げて機能させるためのドキュメント群をオープンソースで公開」（2023年4月10日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。 ソフトウェアの開発や運用において、さまざまなオープンソースが重要な役割を果たすようになってきており、現在ではオープンソースを抜きにソフトウェア開発や利用を行うことがほとんど困難な時代になってきました。 オープンソースと適切に関わり、活用や推進をしていくことは、ソフトウェアに関わる企業にとって（それ以外の企業にとっても）戦略的に取り組むべき事項になってきているといえます。 そうした中で「Open Source Program Office」（OSPO）と呼ばれる組織
GitHub、あなたの会社にオープンソース担当部門「Open Source Program Office」を立ち上げて機能させるためのドキュメント群をオープンソースで公開
GitHub、あなたの会社にオープンソース担当部門「Open Source Program Office」を立ち上げて機能させるためのドキュメント群をオープンソースで公開 ソフトウェアの開発や運用において、さまざまなオープンソースが重要な役割を果たすようになってきており、現在ではオープンソースを抜きにソフトウェア開発や利用を行うことがほとんど困難な時代になってきました。 オープンソースと適切に関わり、活用や推進をしていくことは、ソフトウェアに関わる企業にとって（それ以外の企業にとっても）戦略的に取り組むべき事項になってきているといえます。 そうした中で「Open Source Program Office」（OSPO）と呼ばれる組織への注目が少しずつ高まっています。 一般的にOSPOとは、企業のオープンソース戦略の策定と実行といった大きなものから、社内でのオープンソースに関する啓蒙と推進、
GitHub.comにSBOM生成ツールが登場。誰でも無償でSBOMファイル作成、パブリックリポジトリならユーザーでも自由に作成可能
GitHub.comにSBOM生成ツールが登場。誰でも無償でSBOMファイル作成、パブリックリポジトリならユーザーでも自由に作成可能 GitHubは、同社が提供するGitHub.comにSBOM（ソフトウェア部品表）生成ツールが組み込まれたことを発表しました。 リポジトリを参照できる権限があるユーザーであれば誰でもボタンをクリックするだけでSBOMファイルを無償で作成できます。 つまり、誰でも参照できるパブリックリポジトリであれば、誰でもそのリポジトリで公開されているソフトウェアのSBOMファイルが簡単に入手できることになります（実際に試しましたが、確かにパブリックリポジトリのSBOMファイルを簡単に作成できました）。 Introducing self-service SBOMs! With just one click, developers and compliance teams c
現場でよく使う Git コマンド - Qiita
本記事 タイトルの通り、開発環境にてGitを採用している現場で、 個人的な経験則で、重要コマンドを厳選してみました。 前提知識：Gitとは 前提 Gitの理解には、リモートとローカルの言葉を知っていなくてはいけません。 リモートは、サーバー上にあるなどの意味合いとして使われ、 ローカルは、手元にあるなどの意味合いとして使われることが一般です。 そのため Gitに出てくるリモートリポジトリは、 「誰もがアクセスし共有できるサーバー上のソース保管場所」であり、 ローカルリポジトリは、 「自分しか見れない手元のPCにあるソース保管場所」です。 この保管場所を作っているのがGitです。 コマンド git add どのファイルを変更しましたよ〜という情報をGitに教えてあげるコマンド。
WindowsとGitHubのファイル並び順の違いを、ASCII文字の範囲で具体的に確認した - Qiita
そのリポジトリがこちら という感じ。 リポジトリの README は英語っぽい何かで書いたが、せっかくなのでそれと同じことをここ Qiita に日本語っぽい何かで書いておく。 ASCII 文字のファイル並び順調査 Windows と GitHub のファイル名における ASCII 文字の取り扱いを見てみる。 Windows 画像が縦長すぎるので縮小表示している。 クリックすれば別タブで原寸閲覧できるはず。 並び順 数字部分は数値として並び替えられる。 大文字・小文字は区別されない。 制約 頭と尻のスペースは削除される。 一部の記号が使えない。 " * / : < > ? \ | Windows 10 Home 64-bit 22H2 にて確認。 実は他にも色々と制約があるが、ASCII 文字の並び順というテーマからは遠のくのでカットしている。 その辺は公式ドキュメントを見た方がずっと正確だ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoftが開発者向け全部入りアプリ「Dev Home」を発表 ～ReFSベースの「Dev Drive」も／開発デバイスの環境構築から「GitHub」ワークフローの監視・管理までを一元的に
