はてなブックマーク

VS Code でコミットするときに GitHub Copilot を使っていると コミットメッセージを生成してくれたりします。 図 1 コミットメッセージを Copilot で生成 英語苦手な自分からすると「マジうれしいんですけど」という感じなのですが、コミットメッセージはできればエディターで記述したいと考えてしまいます。 そこで今回は「コミットメッセージをエディターで編集する利便性」を維持しつつ、「GitHub Copilot による生成機能もできるだけ利用しよう」という内容のメモになります。 VS Code のエディターでコミットメッセージを記述するとは VS Code でコミットメッセージを記述する方法としてはソース管理タブの利用が一般的かと思われます。 図 1-1 ソース管理タブのフィールドから普通に入力 一方で上記とは別に、コミット用のコマンドを実行しエディターの中で記述する方

Gemini API を少し触ってみて、画像関連でいくつか応用できそうに思えました。 そこで、Google Drive でスキャンした画像(PDF)から自動的にスプレッドシートを作成するような GAS 用スクリプトを試作してみました。 どのようなスクリプト？ Google Drive で以下のような画像をアップロード(スキャン)しておくと Gemini API を利用してスプレッドシートを作成します。 図 1-1 紙の表をスキャンしたファイル 図 1-2 紙の表から作成したスプレッドシート また、スキャン元の画像にはグラフも利用できます。ただし、グラフ内に値が表示されていないと多くの場合で正確な値にはなりません。 図 1-3 画面に表示されているグラフをスキャンしたファイル 図 1-4 グラフから作成したスプレッドシート 表として取り込む仕組み(プロンプト) 基本的にはドキュメントに従って

VSCode の更新情報で Preview features に「Images in the terminal」という項目がありました。 There is now experimental support for images in the terminal. Images in a terminal typically work by encoding the image pixel data as text, which is written to the terminal via a special escape sequence. The current protocols that are supported are sixel and the inline images protocol pioneered by iTerm. 個人的にはわりとうれしい機能なので少し試してみるこ

以前に Gist で書いていたメモにコメントを頂いて知識が更新されたので、せっかくなので Zenn にも転載しようかと。 (Mermaid の Gitgraph Diagrams を使ってみたかったというのもあります) そのような感じで、たまに --onto を使おうとすると忘れているのでメモ。 基本(普通に rebase) これを こうするには 以下のように rebase を使う。

VSCode の設定を簡単に切り替える方法はないかなと思っていたところ、2023-01(v1.75.0) の更新で Profiles 機能が追加され、複数 Profile を持てようになったとのこと。 そこで、どんな感じかなと試してみたところ、設定の切り替え以外にも共有などで便利そうだったのでその辺についてなど。 2023-02-10: 通常版の vscode.dev でもプレビューを利用できるようになったので、注意点などを更新しました 2023-02-10: Profile の切り替えについての追記などを行いました Profiles 機能とは？ これまで VSCode の UI ではユーザーの設定を 1 つしか持てませんでした。 今回の更新で導入された Profies 機能を使うとその辺を良い感じにしてくれるとのこと。 Profiles If you have different VS

以前にも同じ内容で記事を書いたのですが、GitHub 上のウェブ UI でキャッシュを管理できるようになったり、GitHub CLI の extension も機能アップしたりと変化がありました。 今回は以前の記事に加えて、下記の点について書いてみたいと思います。 お手軽 - ウェブ UI による一覧表示と削除 自動化 - gh-actions-cache とワークフローによる管理の自動化 キャッシュをブラウザーからお手軽に管理 以前の記事では API と GitHub CLI の extension(gh-actions-cache) を使う方法を書きました。2023 年 1 月現在ではウェブ UI でキャッシュを管理する方法も実装されているので、今回はこちらについて書いてみます。 ブラウザーで GitHub 上のリポジトリから Action をタブを開くと、左側のパネルに Manage

VSCode の更新情報を見ていたら Remote Development の項目に Remote Tunnels についての記述がありました。面白そうなので試してみたところ、vscode.dev(girthub.dev) や Codespaces とはまた違ったリモートな開発環境を簡単に構築できてしまいました。 というわけで今回は Remote Tunnels のインストールや使い方、サーバーの少し突っ込んだ設定方法などについて。 2022-12-19 コンテナで資格情報を再利用できる方法がわかったので該当箇所を編集しました。 VSCode の Remote Tunnels とは 簡単に言うと「普段使っている PC を外部のデバイスから VSCode として利用できる機能」となります。 この機能は以前から VSCode Server + トンネル機能としてプライベートプレビューでテストさ

GitHub Apps の Access Token を取得するGoogle Apps Script 用ライブラリーを作った Google Apps Script から GitHub Actions のワークフローを開始したくなったのですが、開始するには対象リポジトリの許可(permission)が必要になります。 定番としては Personal Access Token の利用になりますが、GitHub では有効期限を短く設定するよう警告も出るので他の方法を探したところ以下の記事がヒットしました。 そこで Google Apps Script で同じようなことが出来ないか試してみました。 GitHub Apps アプリの用意 まずはテスト用のアプリを用意します。 アプリ作成 基本的には冒頭記事の通りです。 GitHub App nameはアプリの名前をつけてあげて下さい。 Homepag

Rust で実行数を制限しながら複数のファイルを同時にダウンロードしたくなりました。 最初は「非同期処理と Channel でどうにかなるかな」と軽く考えていましたが、.await を複数配置することになったりと複雑になりがちです。 そこで試行錯誤してみたところ Stream(のアダプター)を使うとコンパクトにまとめることができたので、今回はその辺についての記事です。 ランタイムと各種ユーティリティー Rust では非同期処理のランタイムや関連するユーティリティーは各種 Crate を組み合わせる必要があります。以下は今回利用している Crate についてです。 ランタイムは表題にあるように Tokio を利用します。また、非同期処理の記述も基本的には Tokio の Task を使うようにしています。 ただし、Stream のアダプター(コンビネーター)は tokio-stream では

Zenn や GitHub の Markdown から利用できる Mermaid には「Git ブランチを表現する」機能があります。 その機能を利用してみたところよい感じだったので、記述方法やカスタマイズについてなどを記事にしてみます。 Git ブランチを表現するとは？ ドキュメントでブランチの説明などを読んでいると下記のような図(グラフ)を見かけるかと思います。 図 1-1 AA によるブランチのグラフ A---B---C---D develop \ E---F---G topicA \ H---I---J topicB Mermaid の Gitgraph Diagrams を利用することにより、このような感じで表示できるようになります。 図 1-2 Mermaid によるブランチのグラフ 基本的な使い方 Mermaid 用コードブロックの先頭で gitGraph を記述し、Git の

GitHub Actions から Google Drive API を使う場合「キーなし認証ができる状況ではサービスアカウントを利用するのが便利かな」と考え試しています。 その過程で少し勘違いしていたところがあったのでメモなど。なお確認は個人用のアカウント(エディション)で行っています。 勘違いしていた挙動 以下のような感じでサービスアカウントから(自分の)マイドライブへファイルをアップロードしようとしていました。 通常のユーザーがウェブ UI などでマイドライブ上にフォルダーを作成しサービスアカウントを編集者として共有する スクリプトなどからサービスアカウントを利用して上記フォルダーへアップロードする ユーザーはアップロードされたファイルを参照し必要なくなったら削除する この場合、図 1-1 のようにユーザーのマイドライブへファイルがアップロードされ、通常のファイルのように参照や削除で

techfeed 経由で下記のスレッドを見かけたのですが、タイトルだけでも既に面白そうです。 また、ちょっと前から Notion のデータベースを各種コンテンツへ変換するツールを作っていまして、これを組み合わせるといろいろ楽できそうな予感がします。 そのようなわけで、スレッドで紹介されていた columnq-cli についての記事です。 columnq-cli とは？ README を読むと「各種データをテーブルとして SELECT できるようにする CLI ツール」で、テーブルソースには JSON などの他に ROAPI でサポートされているものを扱えるとのこと。 (SELECT のみで更新はできない) ここで ROAPI とはなんぞやとなりますが、こちらは「ローカルのファイルシステムや各種サービスのデータを統合的に扱える(SELECT できる)サーバー」を構築できるそうです。 図 1-

Docker Compose の --scale で「実際に何か動かしてみよう」と mvSQLite を利用してみたところ、Time travel などが予想以上に面白かったので記事にしてみました。 mvSQLite とは？ 表題から推測できるように分散する SQLite なのですが、他にも特徴があるので詳細は README の Features を読んでいただくのが良いかと(丸投げ)。 Full feature-set from SQLite: mvsqlite integrates with SQLite using either a custom VFS layer or FUSE at your choice. Since it is a layer "below" SQLite itself, all of SQLite's features are available. Tim

先日、下記のタイトルを見て「どういうことだってばよ？」となったので。 あと、Markdown のコードブロックの言語指定を置き換えるコマンド作ろうかなと考えていたので(何が関係あるんだ？というのは後で出てきます)。 つまり、どういうこと？ ちょっと触ってみた感じだと、README.md の中からコードブロックを抜き出し「説明付きで一覧にしたり」「実行したり」する CLI ツールを作ってみたということのようです。 そう聞くと「それはコードブロックをコピーして実行すればいいんじゃね」となりそうですが、 ドキュメント内でのコマンド実行のサンプルは以下のように行頭に $ が付いていたり。実行結果が併記されていたりすることがあります[1]。 rdme はその辺をなんかいい感じに実行してくれます。 リスト 1-1 サンプルの README.md # テスト ## Installation ```sh

Rust を使ってみたくなり、勉強のために簡単な CLI ツールを作ってみました。 そして無謀にも「どうせなら並列処理も試してみよう」と挑戦してみたのですが、ワーカースレッドを複数にするとガクっと遅くなってしまいました。 図 1 経過時間の比較 # ワーカースレッドが 1 の場合 $ time ./target/x86_64-unknown-linux-musl/release/xquo -w 1 < tmp/tmp_large.txt > /dev/null real 0m25.902s user 0m30.587s sys 0m1.637s # ワーカースレッドが 2 の場合 $ time ./target/x86_64-unknown-linux-musl/release/xquo -w 2 < tmp/tmp_large.txt > /dev/null real 0m45.006s

VSCode の更新情報を見ていたら Dev Container の仕様と、リファレンス実装の CLI ツールについて記載がありました。 Development Container specification Our development container teams across Microsoft and GitHub continue active development on the new Dev Container Specification, and this iteration had several exciting highlights. どういう風にやってきたのか Dev Container(devcontainer) の元は VSCode の Remote - Containers で使われている開発コンテナ(とその設定ファイル)のことです。これを VSCode

Notion から使える OCR 機能が欲しかったので、下記の記事を参考に GAS のライブラリーを作ってみました。 この記事ではライブラリーの設定方法などを記載していきます。 どんなライブラリー？ Google Drive 上に保存されている PDF と画像に OCR を実行し、結果のテキストを Notion へ送信するライブラリーです。 定期実行や変更通知に対応しているので、OCR の結果を自動的に Notion へ送信できます。 ▼ 図 1-1 PDF を所定のフォルダーに保存すると ▼ 図 1-2 テキストとして Notion へ送信される また、少し設定を頑張れば「スマートフォンのカメラで撮影した後、リアルタイムに近い感覚で OCR の実行」も可能です。 ▼ 図 1-3 フォルダーに保存後、10 ～ 20 秒くらいでテキストが登録される(実際の画面にタイムコードは表示されません)

GitHub Actions から Node.js のスクリプトで Google Spread Sheet を更新したくなりました。 そこで、以前から気になっていた Google Actions からのキーなし認証を試してみることにしました。 GitHub Actions からのキーなし認証とは 私のキーなし認証に対する理解は「守衛の人(GCP)に『〇〇さん(GitHub のリポジトリ)は名刺の確認ができたら来客用の入館証を渡しちゃってください』と連絡しておく」みたいな感じ？くらいなので、詳細は以下を参照していただければと。 GCP(Google Spread Sheet) を GitHub Actions から使う場合 大雑把な理解で書くと、GCP で「キーなし認証」利用するときは「サービスアカウントを利用する」ただし「鍵は事前作成せずに OIDC Provider を信頼する設定を使う

インストールは README の Install に従う。 npm でパッケージをグローバルにインストールするとローカルでコマンドが使えるようになる。 Apps Script の設定で API の実行を許可しておく。 とくに迷うところもないかな。

リリースノートに含まれるプルリクエストによってワークフローの処理を制御したいと考えていたので、その一環として GitHub のリリースノートの自動生成機能を試してみました。 普通に使う 新しく作成するリリースのタグとその 1 つ前のタグの間にプルリクエストがあれば以下のように自動生成してくれます。 標準の設定で使うなら追加のファイルなども必要なくお手軽に利用できます。 ▲ 図 1-1 編集画面で赤枠のボタンクリックで生成される ▲ 図 1-2 実際に作成されたリリース 図 1-3 は GitHub CLI で利用している例です。こちらも設定などは必要なかったのですが、メニューなどから利用できるのは v2.4.0 からだと思われます。 release create: add --generate-notes functionality by @Sixeight in #4467 ▼ 図 1-

ちょっと長い前置きです。 clasp を試しているとき「GitHub 上でリリースを公開したら clasp deploy したい」と思ったので少し調べてみました。 現状では以下の方法が一般的なようです。 認証まわりが気になるところですが、概要としては「SECRET に設定したリフレッシュトークンなどを .clasprc.json へ保存し、トークンの更新はコマンド側にまかせる」という方法のようです。 これまで「できれば SECRET(クレデンシャルなど)を含むファイルの保存は避けたい」と思っていたのですが、そうも言ってられないようなのでその辺を少し試してみました。 SECRET をファイルへ保存するコマンド 普通に考えると $ echo -n "${PASSWORD}" > password.txt とやりたくなりますが、以下によると可能な限り回避しておくべき方法に分類されています[1]。

remark-cli を試しているとき「入出力を JSON(AST) で扱える」のを見て「これを利用すれば Markdown を jq などで変形できるのでは」ということで試してみました。 remark-cli の設定 まずは remark-cli を実行できるように設定していきます。 インストール remark のプラグインなどもインストールするので npm のパッケージを作ってその中にインストール(設定)していきます。 $ mkdir test-remark-cli $ cd test-remark-cli/ $ npm init -y $ npm install remark-cli $ npx remark --version remark: 14.0.2, remark-cli: 10.0.1