hogashi.*

日記から何から

RegExp match indicesためした

GoogleChrome

　Chrome 90 で入っていた RegExp match indices (https://www.chromestatus.com/feature/6558676666023936) というのを見てへ〜と思ったのでちょろっとおためしした*1。

f:id:hogashi:20210507151501p:plain
devtools でおためしした様子

　さっと見た感じでは、マッチしたものそれぞれについて、その登場範囲を配列で返してくれるというものらしい。上の 3つ目の例 ('123aaaabbbb'.match(/(aa)+(?<bee>b)/d))だとこういう感じになっていそう ↓

  • (aa)+(?<bee>b) (全体) にマッチするのは
    • aaaab で (最初を 0文字目として) 3〜7文字目
    • なので [3, 8]
  • (aa) にマッチするのは
    • aa (後半の方) で 5〜6文字目
    • なので [5, 7]
      • 繰り返しだと最後にマッチしたものになってこうなっている？
  • (?<bee>b) にマッチするのは
    • b (最初の1文字) で 7文字目
    • なので [7, 8]

　範囲の感じで終わり側の数字が 1つ多いのは、 GitHub の例を見る限り slice とかでそのまま使えて便利になっています、というように見える。

const re1 = /a+(?<Z>z)?/d;

// indices are relative to start of the input string:
const s1 = "xaaaz";
const m1 = re1.exec(s1);
m1.indices[0][0] === 1;
m1.indices[0][1] === 5;
s1.slice(...m1.indices[0]) === "aaaz";
https://github.com/tc39/proposal-regexp-match-indices#examples

　indices つけるの大変なので /d フラグを明に指定しないとやりません、という仕様らしい。まさにこれがほしいぜというときにつけてあげると小粒に便利そう。 (ところで Chrome Devtools を見ていると /d にシンタックスハイライトがまだあたってなさそう……)

As producing this array is expensive, the `.indices` property is only present when the /d flag is passed.

https://www.chromestatus.com/feature/6558676666023936

　GitHub の方には、なんで /d なのかというところに、 d 使っていいのかみたいなことも書かれていた (https://github.com/tc39/proposal-regexp-match-indices#why-use-d-for-the-regexp-flag) 。 indices という単語から取ろうとしたけど、いまある i とかを避けつつ、他の正規表現エンジンも見て d がすでに意味バラバラなので、まあいいかな、みたいな感じになっていそう？

　あとそれに伴って他の正規表現エンジンでの様子をまとめていておもしろい (https://github.com/tc39/proposal-regexp-match-indices/blob/master/flags_comparison.md)。リンクもあるので各エンジンのドキュメントへのリンクまとめみたいになっている……。

www.chromestatus.com

github.com

*1:バージョン: 90.0.4430.93（Official Build） （x86_64）

pt-query-digestのJSON出力の型書いた

TypeScript JavaScript

　型を公開する練習として、 pt-query-digest *1 で --output json したときに出力される JSON の型を書いてみた。 JSON.parse() したものにつける型を想定している。

github.com

　index.d.ts とかを書いて、 package.json に types として指定しておくと完成らしい。 npm に公開しなくても、とりあえず yarn add -D https://github.com/hogashi/types-pt-query-digest-output-json とかやるとインストールできるのでさっと作ってみるには気楽。

www.typescriptlang.org

　値としては数値なはずだけどプロパティによって number だったり string だったりすることがあってちょっと難しい。ちゃんとコード読んでるわけでもないので、意外と null になるじゃんみたいなものもあったりしそう。あと pt-query-digest の v3.0 時点でもまだ開発中ということなので急に変わったりもしそうではある。

json output was introduced in 2.2.1 and is still in development, so the data structure may change in future versions.

https://www.percona.com/doc/percona-toolkit/3.0/pt-query-digest.html#options&:~:text=json%20output%20was%20introduced%20in%202.2.1%20and%20is%20still%20in%20development

*1:https://www.percona.com/doc/percona-toolkit/LATEST/pt-query-digest.html

wgetはHSTSをサポートしている

Linux

　ホームディレクトリを見ていたら .wget-hsts というファイルがあったので見てみるとこういう感じだった。

$ cat .wget-hsts 
# HSTS 1.0 Known Hosts database for GNU Wget.
# Edit at your own risk.
# <hostname>	<port>	<incl. subdomains>	<created>	<max-age>
raw.githubusercontent.com	0	0	1599047229	31536000
gist.githubusercontent.com	0	0	1605963625	31536000
(後略)

　調べると wget は HSTS (HTTP Strict Transport Security) *1 をサポートしていて、このファイルはそのデータベースですとのことだった。なのでこれをちゃんと編集したら好きなホスト名についてとにかく https で接続できそう。素朴。

‘--hsts-file=file’

By default, Wget stores its HSTS database in ~/.wget-hsts. You can use ‘--hsts-file’ to override this. Wget will use the supplied file as the HSTS database.

(中略)

An HSTS entry line consists of several fields separated by one or more whitespace:

<hostname> SP [<port>] SP <include subdomains> SP <created> SP <max-age>

https://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_0029-Options.html#:~:text=hsts-file

www.gnu.org

*1:Strict-Transport-Security - HTTP | MDN

拡張機能「twitter画像原寸ボタン」 v3.1.3 公開

拡張機能 GoogleChrome MSEdge

　拡張機能「twitter画像原寸ボタン」 v3.1.3 公開しました。特に変更はなく依存パッケージのアップデートです。すでにインストールされていれば自動で更新されます。

chrome.google.com

　あと今回から Microsoft Edge アドオンにも公開しています。

twitter画像原寸ボタン - Microsoft Edge Addons

　互換性ある API しか使ってないから Port するだけなのでやってみませんか、みたいなメールを Microsoft Edge アドオンの担当の人？からなぜかもらったのでやったけど、本当に単にそれだけでできました。なるほど感。

docs.microsoft.com

■

日記

toya.hatenablog.com

　競馬のことをほんとうにほとんど知らないのでここ最近は TL を遠くから眺める感じになっているのだけど、なるほど〜と読めた。そして以下は競馬とは全然関係ない話題です。

　特に関わっている人が (見えないところを含めて) とても多くいて、その上で選手？が出場する、というところはやっぱりそうなんだなと思った。これは F1 でも同じなのでとても身近な感覚で、僕が F1 を楽しく見ている理由のひとつでもある *1。

　F1 ではドライバーが一番注目されるわけだけど、乗っているマシンはチームが開発したものだし、優勝したドライバーのチームは表彰式で一緒に表彰される (チームのひとりが表彰台に上がる、ドライバーの国だけでなくチームの国の国歌も流れるなど)。それ以外にも、ドライバーとずっと会話し続けて指示などをするエンジニア、爆速ピット作業のエンジニア、カメラに写らない縁の下でデータ解析しまくって助言する人々など *2 レース最中もすごい数の人が動いていると聞く (放映でしか見たことがないので伝聞)。それを勝手に想像しながら放映を見るのが楽しい。あと実況解説の人がそういうのめっちゃ詳しくて説明してくれたりすると倍楽しい。

　というところまで考えて、僕が E-スポーツ版 F1 にあまり惹かれないのはそういう点もあるのかな〜と思った。今までは、現実のモノ・天候・人の調子などが色々重なって起こる色々なことを見る方がおもしろいと感じるのかなと思っていた (引き続きそれもあるとは思う)。もちろん関わっている人の数は決して少なくはないのだろうけど、どうしても比べてしまうのかもしれない。

　ということは、ものぐさなので何も調べてなかったから知らないだけで、どういう人がいるのか見て色んな人がいることが実感できたらまた印象が変わるかな、とも思える。でも、なぜか同じくらい好きにはならないんだろうな、という直感があるのであった……。

*1:といって詳しいわけではないし F2 とかはほぼ見たことがないのでかなり雑になります

*2:細かく言えばドライバーやエンジニアの詰める場所の食事の用意とかお掃除の人とかもっとめちゃくちゃいると思う

■

日記

　家から出ずに会話をする日々で、通信を介する遅さにじわりじわりと苦しんでいる気がする。仕事も私事もそうだけど、どうしても発話が被るし、間合いを取りかねる。

 

　意外と短い時間で機微を感じ取って会話していたのだなと思いつつ、通信を介する遅さで育つ人が居たらどれくらいその遅さに適応できるんだろうかというのも気になる。光や音の速さが人間の反応速度とかに影響ない範囲だからやっていけているのか、もともと遅かったらそれに合わせて生活できるのか。なんにせよ会って話す場面はまだまだ無くならないので結構先の話になりそう。

 

　昔学研で読んだ、光の速さが秒速 1m とかになる SF のことを思い出した。小学生ながら登場人物の抜けた感じにつっこみをいれていたけど、今になってよく考えると秒速 1m ならダッシュで光を追い越せる。ちょっとやってみたい気もするけど、もしドップラー効果とかがあるとめちゃくちゃ眩しいと思う。