ikuma-t.com

template 名	内容
005-early-design-review	初期段階での方向性について考えやガイダンスを提供してほしい場合に使用
010-specification-review	現在取り組んでいる Web 技術の仕様についてレビューしてもらいたいの場合に使用
020-dispute-escalation-review	現在の論争について意見を求める場合に使用

Issue template の起源

https://github.com/w3ctag/design-reviews/commit/68a1436aa797b7b30002a5ec39f4ce1dfa451942🔗

git blame すると、2019年05月23日にこのテンプレートが作成されたことがわかります。ここを確認すると、この時点で「こんにちはTAG!」（現在は「こんにちは TAG-さん!」）という文字列が含まれていることがわかりました。

作成された際のコミットメッセージは次のとおりであり、もともと「specification review」というテンプレートがどこか（メーリングリストとか？）にあったことが伺えます。

Create issue templates in the new format Make issue templates in the new format. Use the existing template as a “specification review” template, and create a somewhat different template for “dispute resolution”.

なお Issue Template をこのリポジトリに作成した人物は Google に勤めるエンジニアの L. David Baron さんです。

https://github.com/dbaron🔗

もっと！Issue template の起源

現在の Issue Template はここまでしか辿れませんが、日付と過去に別のテンプレートがあった、という情報が手に入ったので、リポジトリ全体の History を参照してみました。

すると、2019年05月09日に ISSUE_TEMPLATE.md を変更しているコミットを発見。

https://github.com/w3ctag/design-reviews/commit/426a9a8b3fc6314deb9f44a60ade76d2edaca6fd🔗

このファイルの履歴を辿ってみます。

https://github.com/w3ctag/design-reviews/commits/426a9a8b3fc6314deb9f44a60ade76d2edaca6fd/ISSUE_TEMPLATE.md🔗

まず 2016年11月02日にテンプレートのファイルが作成されていました。

https://github.com/w3ctag/design-reviews/commit/9ed6f17be379a5d0d9397c5311ac9634fcab84d4🔗

コミットメッセージには「F2Fからの Issue template。共同で構築。」と記載があります。

Issue template from F2F. Collaboratively constructed.

この「F2F」について検索してみると、どうも W3C が開催している「Face to Face」 Meeting のことを指しているようです。

TAG Meeting 2016@Tokyo

2016年11月02日あたりに開催された TAG の Meeting を検索してみると、どんぴしゃで2016/10/31 - 2016/11/02 @東京開催のMTGがあることがわかりました。

https://www.w3.org/events/happenings/2016/technical-architecture-group-tag-meeting-2/🔗

Web サイトのリンクがあったので眺めてみる。どうも日経ビルでやっていたそうな。

https://github.com/w3ctag/meetings/tree/gh-pages/2016/11-tokyo🔗

議事録があるようですが、どれも W3C TAG のトップページに飛んでしまい参照できませんでした。最新の MTG の議事録の格納場所に移動されていないかみてみたものの、最近では直接 GitHub に保存しているのでダメそうです。

これ以上は追えないものの、ここを起源にテンプレートが生まれたことがわかりました。

greeting の変遷

https://github.com/w3ctag/design-reviews/commit/6bd78d4e674e5428c32f914bec64739164ba7a54🔗

テンプレートが作成されて以降、初めて挨拶部分が変更されたのがこのコミット。2017年07月にはたしかにロンドンで F2F MTG が開催されており、これに合わせて「Dear Sirs and Madam of TAG!」に変わっている。

テンプレートができた時から、初めて挨拶部分が変更されたときまでに、02-boston、04-tokyo の2回が開催されている。ボストンについてはアメリカなので変更の余地がありませんが、なぜ東京は変えなかったのか…（東京の時に Hello で作ったので、変えようと思わなかったのかも？）？

何はともあれ、2017年07月以降、その回の MTG の会期中に、次回の開催地の挨拶文に変わるという文化が始まったようです。

改めて「こんにちは TAG-さん!」を確認する

https://github.com/w3ctag/design-reviews/commit/d7015be036a57a19e9be170eeb914e425db9b65c🔗

この変更が入ったのは、2023年02月13日。確かに2023年04月には東京で F2F MTG が開催されているものの、それ以降も MTG は開催されており、一方で挨拶文は変わっていない。

よくよくみてみると、必ずしも毎回挨拶文が変わっているわけでもなく、厳格な運用（挨拶文の変更に厳格な運用も何もないが…）はされていないようでした。

おわりに

あまり重要ではない情報の調査に時間を使ってしまったような気がしましたが、調査の過程で W3C TAG に少し詳しくなれたのでよかったです。

「こんにちは TAG-さん!」とは何か

公開日: 2024/5/4

GraphQLの「Serving over HTTP」とは何か

2024/5/3

に公開

サマリ

モダンな Web アプリケーションフレームワークは、HTTPを用いてやり取りを行い、ミドルウェアを利用して認証やリクエストの検証、変換を行うパイプライン型のアーキテクチャを採用している
GraphQL においても、事前に認証・検証が行われた上でリクエストを処理するのがベストプラクティス
そのために、GraphQL のリクエストを REST のような形式でマッピングして処理する

Serving over HTTP

https://graphql.org/learn/serving-over-http🔗

GraphQL サーバは GET と POST の 2 種類の HTTP リクエストをハンドリングできるようにします。

マッピングされるパラメータは次のとおりです。

パラメータ	意味	必須
query	クエリそのもの	必須
variables	クエリの変数	任意
operationName	クエリの名前。複数のオペレーションを同時に実行する場合には必須	任意

GET

GET リクエストでは、GraphQL Query が query というクエリパラメータにマッピングされます。

query HeroQuery($id: ID!) {
  hero(id: $id) {
    name
  }
}

このクエリは、次のようにエンコードされます。

http://myapi.com/graphql?query=query($id: ID!){hero($id: ID!){name}}&operationName=HeroQuery&variables={"id":"avagfads732"}

POST

POST リクエストでは、application/json でリクエストを送信する。次の形式の JSON をボディとして送信されます。

{
  "query": "...",
  "variables": "updateHeroName",
  "operationName": { "id": "avagfads732", "name": "Andrew" }
}

レスポンス

レスポンスは JSON 形式で返される。GraphQL の仕様に則り、dataフィールドかerrorsフィールドが含まれます。

{
  "data": {
    "hero": {
      "name": "Andrew"
    }
  }
}

{
  "errors": [
    {
      "message": "Cannot query field 'hero' on type 'Query'",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ]
    }
  ]
}

[Draft] Transport Specification / GraphQL over HTTP

ここまでの内容が GraphQL 公式で公開されている内容で、ここから先はまだドラフト段階です。

仕様の定義場所

https://graphql.github.io/graphql-over-http/draft/🔗

概要

GraphQL over HTTP は Serving over HTTP の仕様を拡張したもの。
HTTP サーバは 1 つ以上の URL を介して、GraphQL スキーマへのリクエストを受け付ける必要がある。
サーバおよびクライアントは、少なくとも JSON の形式でリクエストをサポートする必要がある。
レスポンスにおける Media Type は application/graphql-response+json が推奨。
サーバは POST リクエストに必ず対応する必要があり、そのほかの GET のようなメソッドも対応する可能性がある。
サーバはリクエストの処理の成功時にはその結果を、失敗時にはエラーを返す必要がある。

GraphQLの「Serving over HTTP」とは何か

公開日: 2024/5/3

skim で移動/コマンド履歴検索をインタラクティブに行う

2024/5/2

に公開

モチベーション

新しく M3 Macbook Air を購入したので、これを機に色々とツールを乗り換えています。

Fuzzy Finder にはこれまで peco を使っていたのですが、全部 Rust 製に統一したいという思いがあり、skim に乗り換えました。

乗り換えたはいいのですが、キーバインドやコマンドの設定を怠っており活用できていなかったので、調べて設定してみた、というのがこの記事の内容です。

zoxide の絞り込みに skim を使う

https://github.com/ajeetdsouza/zoxide🔗

zoxide には標準で zi というエイリアスが設定されており、これを使うことでインタラクティブにディレクトリを選択できます。しかし内部的には fzf が使われており、そのままだと fzf もインストールしなければなりません。

これを skim で使うための設定が以下の Issue で提案されていました。

https://github.com/ajeetdsouza/zoxide/issues/228🔗

function __zoxide_zi() {
    \builtin local result
    result="$( \
        zoxide query -ls -- "$@" \
        | sk \
            --delimiter='[^\t\n ][\t\n ]+' \
            -n2.. \
            --no-sort \
            --keep-right \
            --height='40%' \
            --layout='reverse' \
            --exit-0 \
            --select-1 \
            --bind='ctrl-z:ignore' \
            --preview='\command -p ls -F --color=always {2..}' \
        ;
    )" \
        && __zoxide_cd "${result:7}"
}
zle -N __zoxide_zi
setopt noflowcontrol
bindkey '^z' __zoxide_zi

通常のシェルインテグレーションと同様に、__zoxide_zi 関数を定義し、zoxide query でディレクトリを取得し、sk で選択するようにしています。

https://github.com/ajeetdsouza/zoxide/blob/main/templates/zsh.txt#L69-L73🔗

履歴検索を skim で行う

最適かは分かりませんが、履歴検索を skim で行う設定を以下のようにしました。

function hist() {
    BUFFER=$(history -n -r 1 | sk --query "$LBUFFER" --reverse)
    CURSOR=$#BUFFER
    zle reset-prompt
}
zle -N hist
bindkey '^r' hist

zle、bindkey is 何？

Zsh Line Editor の略で、Zsh のコマンドライン編集機能を提供します。ターミナル上の文字列やカーソル位置をシェルスクリプト上で操作するための機能のようです。

今回出てくる -N オプションは、新しく関数をバインドするためのオプションです。

-N new-keymap [ old-keymap ] Create a new keymap, named new-keymap. If a keymap already has that name, it is deleted. If an old-keymap name is given, the new keymap is initialized to be a duplicate of it, otherwise the new keymap will be empty.

bindkey は、キーバインドを設定するためのコマンドです。指定したキーに対して、指定した関数をバインドします。

https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html🔗

参考

https://speakerdeck.com/naoya/sierunolu-li-toikunrimentarujian-suo-woshi-u🔗

https://k-koh.hatenablog.com/entry/2020/10/24/160323🔗

https://www.rasukarusan.com/entry/2020/04/19/193450🔗

skim で移動/コマンド履歴検索をインタラクティブに行う

公開日: 2024/5/2

ikuma-t

ABOUT

9割笑顔、1割 (´・ω・) なエンジニア