Token が文字列とは別に定義されているため、実装する言語によっては設計に悩む(JS 実装では Symbol を使っている)。 Parameter Parameter は Item に付与できるメタデータだ。 例えば以下は String の "abc" に対してパラメータを 2 つ付与している。 // "abc";a=1;b=2 { "value": "abc", "params": { "a": 1, "b": 2 } } データ表現には基本的に Key/Value/Metadata の 3 つがあることが望ましい。 例えば XML/HTML のようなフォーマットは Attribute がメタデータを担うが、これを再現可能になる。 <p id="foo" class="bar">hello</p> // p="hello world";id="foo";class="bar" { "p

Perl製アプリケーションからGraphQLを喋ってみたい、ということがあって昨年末に2週間くらいでプロトタイピングしていた。 CPANにGraphQLというライブラリが公開されていて、社内の利用実績もあるので、これをいきなり使ってみても良かったのだけど、自分はGraphQLについては、耳では知っていて、GitHubのAPIを呼び出したことがある、くらいで、実際に実装したことはなかった。 このような状態で突き進むと、問題に遭遇したときに2パターンの怪しさが出てきて、切り分けていくことになる。未知のものが多すぎて、プロジェクトXの、トンネルを掘るだけで難しいのに現地の言葉はわからない、みたいな回をイメージしてください。 GraphQL自体への理解が間違っているパターン スキーマ、クエリの書き方が悪い、概念を勘違いしている、など PerlでのGraphQLライブラリの使い方が間違っているパター

その「ちょうどよさ」ゆえに普及したテクノロジ - アイデアや標準があると思う。 そういうのは、科学や工学でなく匠としてのプログラミングを表している気がして成功が嬉しい。 自分にとって「ちょうどいいテクノロジ」の代表は JSON (2002) と Markdown (2004). どちらも技術的にはさほど大したことはないけれど、どちらも広く使われている。 「ちょうどいいテクノロジ」はこれ以前にも色々あった。UNIX(1969) や HTTP/REST (1991) なんかが思い当たる。 ただ同時代性がないせいか成功が華やかすぎるせいか、まいち親近感がない。 ついでにいうと、自分はもはやこれらに「ちょうどよさ」を感じない。 UNIX の代表 Linux は超巨大ソフトウェアだし、HTTP の最新版 HTTP/3 は随分複雑なプロトコルに見える。 JSON と Markdown は、今のところ当

銀座とかの高い店も行くし、地方の名店も少し行くし、普通の鮨屋も入るし、回転寿司も行くし、自分でも握るし、豊洲にも行ってるし、あと色々背景事情知ってるし、なんなら諸事情で一枚板や内装費含めた全費用を数店舗知ってるので、鮨の解説を書いてみる。 togetter.com 魚貝の美味しさについて まず魚については、概ね3種類に分けられる 1.　鮮度が良いと美味しいもの(食べられないもの) 貝類や青魚、がこれに該当する。貝類は剥き立てが美味しい。青魚は当日～3日目くらいが美味しい(ヒスタミンの問題があるので悩ましいが)。関鯖とか良い物を当日使うと、味が全然出ていないので、これは3日目くらいが美味しい。 はてブにあるように、食感(テクスチャー)を味わいより重視する地域があり、その場合は多くの魚がこのカテゴリに含まれる。 なお、東京の飲食店には最短で釣れた当日のものが届く(多くは翌日のもの)ので、それは