この記事は、Global Tokyo RでHenningさんが紹介されていたのを、そのままQiitaへ輸入したものです。 この記事では、blogdownを使ってgithub.io上にブログを掲載することをゴールに設定して ステップバイステップで手順を残していきたいと思います。 詳細なやり方は次のURLに詳細が記載されています。 https://proquestionasker.github.io/blog/Making_Site/ https://github.com/rstudio/blogdown/blob/master/docs/01-introduction.Rmd ここで紹介している手順は基本的にproquestionasker.github.ioで紹介されている方法をベースにしてますが、 実際にやってみてハマったり、こうしたほうがいいかも?な部分が出てきたので自己流に変えている
記事を書いたモチベ R studioなどを使ってコードを実行しているとき、この内容をどこかにいい感じにまとめてほかの人に共有したいなーって思ったことありますよね? Rmdファイルはhtmlやpdfに変換できますがそのファイルたちを共有する方法がなかなか難しいです。 webサイトとして公開できれば見やすい&壊されないのではというところから始めました。 対象 複数の章(Rmdファイル)に分かれるようなナレッジを1つのサイトとして共有したい Rmdでの実行結果(tableやグラフ)もサイトに掲載したい mac/windowsユーザー R studioを使用可能 手法比較 早速ですが、この記事で紹介する3つの手法について下記にまとめます。 個人的にはquartoを使うのがおしゃれ、かつカスタマイズ性が高いです。 方法 利点 欠点
時代はAIじゃ! 私は普段コーディングをするときにGitHub Copilotを多用しています。中にはAIツールをコーディングに導入することに抵抗がある人も多いかもしれませんが、うまく付き合えば彼女よりも強力な存在になること間違いありません 今回はコード補完だけじゃないGitHub Copilotの便利機能を紹介します。 心得 GitHub Copilotを使う時の個人的な心得を書いておきます。 一、部分部分に留めること 一、生成されたコードを理解すること ここで一つ徳川家康の名言を。「及ばざるは過ぎたるより勝れり」 コード補完 導入で言ったことを忘れたかのような章題ですが、一番はやはりコード補完です。 Twitterのバズり例でよくある「〇〇のコードを生成して」ってChatGPTに投げて100行ぐらいばばーっと帰ってくるのをコピペして使うのは、見た目のインパクトはすごいですがあまりやるべ
1. はじめに GitHub Actionsを用いて自動テストの実行と結果の集計を行う方法を説明します。 具体的には、ソースコードがGitHubへpushされたタイミングで、pythonで書かれたテストをpytestを使って実行し、GitHub上に下図のサマリを表示します。 今回、GitHub Actionsを初めて使ったので、学習のためにGitHub Actionsの基本についても触れています。 2. GitHub Actionsとは GitHubのCI/CDツール。 push, pull requestなどのGiHub上のアクティビティやスケジュールした時間、外部イベントをトリガーとして、ワークフローを作成できます。 特徴 Linux, macOS, Windowsすべてのコンテナに対応 Node.js, Python, Java, Rubyなど、様々な言語に対応 複数のジョブを並行し
ぬるぽよりにるぽ、ヘビや宝石やイルカよりホリネズミやカニやアザラシが好きです。クジラに乗っていたらとある船の航海長に出会い意気投合しました。その後、帆船と衝突し大変な目にあいました。ペンギンとは未だにわかりあえません。 はじめまして はじめまして、うちやまです。バックエンドのアプリケーション開発を主にしています。 今回はCI/CDでGitHub Actionsに移行したことについてざっくばらんにお話しようと思います。私を含めチームメンバーはGitHub Actionsを知ってるけどそこまで使ってないし知らない状態です。GitHub Actionsに怒られイライラし、最終的に仲良くなっていった流れを書いていこうと思います。GitHub Actionsの深い技術要素というより、とりあえず移行してみて動くようになったよということを書いていくので、難しい話はしない予定です (というより、できません
GitHub Actions内でPytestを実行して失敗したテストの詳細をPR内で直接表示させよう!DjangopytestGitHubActions 概要 GitHub Actionsを使ってテストを実行する際に失敗したテストはログを見るかと思います テストが少なければいいですがプロジェクトが大きくなるにつれてどんどん探すのが困難になってくるので PR内で書いたテストコードに失敗したテストの実行内容が表示されたら便利かと思います 今回はとあるライブラリを使って実現する方法について解説していきます 前提 フレームワークはDjangoを使用 テストフレームワークはPytestを使用 pytest-github-actions-annotate-failures pytest-github-actions-annotate-failuresを使うと
※この記事の内容にセクションを少し加えたページをサンプルとして公開してある→bookdown_test はじめに とりあえず細かいセッティングは抜きにして手元のRmdファイルをGitHub上に公開したい、という気持ちだったので最低限の手順をまとめた。 bookdownとは R Markdownからドキュメントを作成するパッケージで、通常のR Markdownに対して(というかPandoc Markdownに対して)長編のドキュメントを生成するのに便利な機能が付け加えられている。図表や数式へのナンバリング、相互参照、複数ページのHTML出力などなど。 必ずしも本を書かなくてもいいし、R Markdownじゃなくて普通のMarkdownでも扱えるので、Rのコードを全く含まないポエムを書いたって全く構わない! 事前準備 bookdownパッケージをインストールしていなければインストールしておく。
marketplace.visualstudio.com GitHub Copilot と直接会話できる Copilot Chat 、皆さん使ってますか? 私は最近まともに使い始めました。 Copilot と言えば補完だけだと思っている人、以前ちょっとだけ触れて使えないと思った人(僕です)、いまのバージョンをもう一度触ってみてください、めっちゃ便利になっている。 www.youtube.com この動画が出来ることを追いかけるのに良さそうなので見てください。 ベースモデルがGPT-4に変わったりとかいろいろ変化はありますが、便利なのは Participant や Context の概念が入ったことだと思います。 Participantは @workspace みたいなやつで、Chat-GPTにおける GPTs みたいなやつ。例えば @workspace ならいま開いているプロジェクトについ
Issue作成だけで後の工程は全てお任せ!GitHub Copilot Workspaceのテクニカルプレビューを触ってみた こんにちは。リテールアプリ共創部のきんじょーです。 待ちに待った GitHub Copilot Workspace のテクニカルプレビューへ招待が来たので、早速試してみました。 GitHub Copilot Workspace とは GitHub Copilot Workspaceは、自然言語で記載した Issue を元に、仕様の策定から実装、ビルド、デバッグなど、その後の工程を Copilot が自動的に実行してくれる開発者向けの AI ツールです。 現在はテクニカルプレビューの段階で Waiting List に登録することで順次利用することができます。 ユーザーマニュアルも公開されているため、詳しく知りたい方はこちらをご覧ください。 試してみた 以前、AWS
Github の README でよく見るオシャレなやつを作りたくなったので、 Gopher くんで遊ぶ。 必要な機能 コミット数の取得 <svg>を返す 今回は Python で FastAPI を使って、Heroku にデプロイして作る。 コミット数の取得はこちらのサイトを参考に、Curl Converterでサクッと変換する。 その結果、以下のコードで最も新しい日付のコミット数を取得できる。 リテラルが多いですが... import json import os from dotenv import load_dotenv import requests load_dotenv() TOKEN = os.getenv("TOKEN") username = "ogty" headers = { 'Authorization': f'bearer {TOKEN}', 'Content-
はじめに ちょくちょく Terraform を触る機会が増えた @kt15 です。最近、E2E テストフレームワークを調査する機会がありました。E2E テストフレームワークは Playwright 以外にも Cypress などいくつかありますが、個人的には Playwright が1番しっくりきました。今回は Playwright の導入から GitHub Actions 上で実行するところまでを試したので、やったことを備忘録的に残しておこうと思います。 Playwrightとは E2E テストを自動化するフレームワークです。 個人的にはこの辺りが魅力的だと感じました。 クロスブラウザ(WebKit も含む)をサポートしている モバイルデバイスをエミュレート(ビューポートなど)してテストできる 構築していく! テスト用にサンプルアプリを作る 今回は Vite と React でサンプルア
別にみんなそうするべきとは全く思わないのだけど、僕は最近GitHub Copilotを意図的に無効にすることがあるので、そのへんについて雑に書いておく。 あらかじめ言っておくが、僕はGitHub Copilotを有効にすることもある。この記事もGitHub Copilotおよびそのユーザーを批判する意図は全くない。 GitHub Copilot が便利な場面 僕がGitHub Copilotを使い始めて少なくとも一年以上は経ってる。自分が書こうと思っているコードに近いものが簡単に生成されていくことに最初は感動したし、便利な場面がはたくさんある。 具体的に便利な場面を思い返してみる。 僕は仕事ではNext.jsでフロントエンドを書いたり、NestJSでバックエンドを書いたりしているのだが、その用途では便利だった。僕は自分が関わっているプロジェクトのReactやNode.jsの書き方はある程度
TL; DR 場合による "How to" を教えるライブコーディングの場合は、切ったほうが良い 設計議論を中心に行うライブコーディングの場合は、使うと良いことがある 文脈 最近の仕事の中で、プログラミングを学んでいる人々の前で、オーディエンスのスキルアップを目的としたライブコーディングを実施したり、ライブコーディングセッションのアレンジをしたりファシリテーションをしたりしている。少々性格の異なるライブコーディングを数パターン行うなかで、「ライブコーディングで GitHub Copilot を有効にするべきかどうか」という問いに答えるに当たって一つの指針が見えてきたので書き残しておく。 How to を教えるライブコーディングでは Copilot を切る 自分が担当したライブコーディングは、特定のテスティングフレームワークの使い方やテスト駆動開発の講義だったのだけど、このような「特定のツー
GitHub、「Copilot Workspace」テクニカルプレビューを開始。ほとんど全ての開発工程をAIで自動化 テクニカルプレビューは上記のCopilot Workspaceのページからウェイトリストボタンをクリックして申し込みます。 Copilot Workspaceはほとんど全ての工程を自動化 Copilot Workspaceは、自然言語で書かれたIssue(課題)を基に、Copilotが仕様案と実装計画を示し、コーディングや既存のコードの修正を行い、ビルドをしてエラーがあればデバッグも行うという、プログラミングのほとんど全ての工程をCopilotが自動的に実行してくれる、というものです。 人間は各工程でCopilotから示される内容を必要に応じて修正するか、そのまま見守ることになります。 GitHub CEOのThomas Dohmke(トーマス・ドムケ)氏は、Copilot
はじめに GitHub Copilot Chat で #file, #editorのように # を利用すると、質問と同時に渡したい情報を投げることができる context variables という機能があります。 今回は現在(2024/2/8)までで利用可能な context variables を全て試してみました。 #file : 選択したファイル チャットプロンプトと共にワークスペース内の指定されたファイルをコンテキストとして含めるために#fileを追加しました。入力の提案コントロールから#fileを選択し、表示されるクイックピックからファイルを選択してください。 可能であれば、ファイルの完全な内容が含まれます。コンテキストウィンドウに収まりきらないほど大きい場合は、実装を除いた関数とその説明を含むファイルのアウトラインが含まれます。アウトラインも大きすぎる場合は、ファイルはプロン
「ChatGPT/LangChainによるチャットシステム構築[実践]入門」という本を読んで学んだ知識を使って、自分で簡単なツールを作ってみたのでそれについて紹介しようと思います。作ってみたツールは、git diff の結果を入力として、この差分によって更新が必要になるドキュメントを検知して書き換えるというものです。 動作例 この記事で紹介するツールの実際の動作例を最初に示します。 ❯ dupdate --repo ../dummy_project --model_name gpt-4 --k 2 2023-11-05 15:22:42.471 | INFO | __main__:main:123 - Using mode: gpt-4 2023-11-05 15:22:43.440 | INFO | __main__:main:125 - Created DB 2023-11-05 15
はじめまして。サーバサイドエンジニアの @DQNEO です。 今日はGitのつくりかたをご紹介します。 C言語学習教材としてのGit Gitと同じものをゼロから作って何の意味があるのか?と思いますよね。 私がこの再発明をやり始めた動機は「C言語を書けるようになりたい」でした。 実際に途中までやってみたところ、 C言語がチョットデキるようになった Gitの内部構造に詳しくなった というメリットが得られました。 C言語を勉強する題材は、テトリスとかWebサーバとか他にいくらでもあるのですが、Gitを実装してみるのはかなりおすすめです。理由は下記の通りです。 内部構造が意外と単純 (ローカルで動かす分には)ネットワークの知識が不要 普段使っているツールで外部仕様がわかっているので、やるべきことが明確 余談ですが、本家Gitのソースコードを参考にしようと思って読んでいたら、Linus Tovals
ghput pr-comment ghput issue-comment のデフォルトの挙動について注意点を追記しました 最近はGitHubやGH:Eといったサービスのリポジトリと、そのリポジトリと連携するCI/CD環境がある前提で、様々なパイプラインを作ることが普通になってきています。 git push や Pull Request をトリガーにCI/CD環境で実行されるのもテストの実行だけではなく、master mergeのタイミングでのプロダクションデプロイやプロビジョニング、その前段階としてPull Requestタイミングでのdry-runやplanの実行など。 GitHubは便利ですし、それと連携するCI/CD環境があるとその2つだけで様々なものの自動化ができて便利です*1。 そんなGitHub+CI/CDな環境で使えるであろう ghput というツールを作りました。 gith
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く