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. 個人的にはわりとうれしい機能なので少し試してみるこ
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
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 の
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
API を使う まずは extension ではなく GitHub の API を使ってリポジトリのキャッシュを管理する場合について。 GitHub API の利用方法はいくつかありますが、今回は簡単に GitHub CLI から利用してみます。 使用量の確認 どれくらい利用しているかの確認です。 $ gh api -H "Accept: application/vnd.github+json" "/repos/{owner}/{repo}/actions/cache/usage" { "full_name": "hankei6km/xquo", "active_caches_size_in_bytes": 10572695430, "active_caches_count": 58 } $ gh api -H "Accept: application/vnd.github+json" "
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
GitHub Actions から Node.js のスクリプトで Google Spread Sheet を更新したくなりました。 そこで、以前から気になっていた Google Actions からのキーなし認証を試してみることにしました。 GitHub Actions からのキーなし認証とは 私のキーなし認証に対する理解は「守衛の人(GCP)に『〇〇さん(GitHub のリポジトリ)は名刺の確認ができたら来客用の入館証を渡しちゃってください』と連絡しておく」みたいな感じ？くらいなので、詳細は以下を参照していただければと。 GCP(Google Spread Sheet) を GitHub Actions から使う場合 大雑把な理解で書くと、GCP で「キーなし認証」利用するときは「サービスアカウントを利用する」ただし「鍵は事前作成せずに OIDC Provider を信頼する設定を使う
ちょっと長い前置きです。 clasp を試しているとき「GitHub 上でリリースを公開したら clasp deploy したい」と思ったので少し調べてみました。 現状では以下の方法が一般的なようです。 認証まわりが気になるところですが、概要としては「SECRET に設定したリフレッシュトークンなどを .clasprc.json へ保存し、トークンの更新はコマンド側にまかせる」という方法のようです。 これまで「できれば SECRET(クレデンシャルなど)を含むファイルの保存は避けたい」と思っていたのですが、そうも言ってられないようなのでその辺を少し試してみました。 SECRET をファイルへ保存するコマンド 普通に考えると $ echo -n "${PASSWORD}" > password.txt とやりたくなりますが、以下によると可能な限り回避しておくべき方法に分類されています[1]。
入力補完 当初は上記ラベル一覧からコピペする予定でしたがやはり面倒になったので補完できるようにしました。 補完候補を作成する関数 ラベル名の一覧が取得できたのでこれを補完候補にする関数を作成します。 本来ならサブコマンドなどで場合分けしてから候補を作成すべきですが、今回はその辺のところはやっつけになっています(重複しているコードが多い)。 (リスト 2-1 一部抜粋したソース) __gh_label_completion_labels_get_repo_from_words() { local REPO="" if [ "${words[2]}" = "-R" ] || [ "${words[2]}" = "--repo" ] ; then local SAVE_IFS="${IFS}" IFS="/" local ELM read -r -a ELM <<< "${words[3]}"
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く