口遊(くちずさみ) 去年八月二条河原落書云々 元年歟
此比(このころ)都ニハヤル物
夜討強盗謀綸旨(にせりんじ)
召人(めしうど)早馬虚騒動(そらさわぎ)
生頸(なまくび)還俗(げんぞく)自由出家
https://www2.city.kyoto.lg.jp/somu/rekishi/fm/nenpyou/htmlsheet/bunka08.html
これ見るとだいたい脳内に↓が流れ始める。 Google で検索するとそういう人が結構いそう 二条河原落書 ジッタリン・ジン - Google 検索
Perlで戻り値として呼び出した子サブルーチンのコンテキストは親と同じ
Perl Advent Calendar 2022 の 12日目です。
qiita.com
こういうときのことです。
sub func2 { # ここのコンテキスト } sub func1 { func2; }
サブルーチンのコンテキストは wantarray - Perldoc Browser を使うと調べられそうです。 wantarray は、 list/scalar/void コンテキストでそれぞれ true/false/undef (値としては 1''undef ) を返します。
Returns true if the context of the currently executing subroutine or eval is looking for a list value. Returns false if the context is looking for a scalar. Returns the undefined value if the context is looking for no value (void context).
https://perldoc.perl.org/functions/wantarray
こういう感じで、呼び出し方を変えながら wantarray を見るコードを実行すると:
use feature qw(say); sub print_wantarray { my $wa_str = defined wantarray ? (wantarray ? 'true' : 'false') : 'undef'; say " wantarray: $wa_str\n"; } sub func1 { print_wantarray; } say 'my $val1 = [print_wantarray];'; my $val1 = [print_wantarray]; say 'my $val2 = print_wantarray;'; my $val2 = print_wantarray; say 'print_wantarray;'; print_wantarray; say 'my $val3 = [func1];'; my $val3 = [func1]; say 'my $val4 = func1;'; my $val4 = func1; say 'func1;'; func1;
こうなります。前半は print_wantarray を直接呼んだものですが、後半の func1 を介した呼び出しでも同じコンテキストになっています。同僚と、そういえばこれどうなるんだろう、という会話になり試しましたが、子の戻り値が結局親の戻り値になるので、コンテキストが同じになるのはたしかにそういうものか、という感じで納得でした。
$ perl a.pl my $val1 = [print_wantarray]; wantarray: true my $val2 = print_wantarray; wantarray: false print_wantarray; wantarray: undef my $val3 = [func1]; wantarray: true my $val4 = func1; wantarray: false func1; wantarray: undef
ちなみに return - Perldoc Browser を省略して書いていますが、明示的に書いても同じです。 return によってコンテキストが変わったりしないのかな、と思ったら、むしろ return がコンテキストに合わせる立場でした (コンテキストによって返す値が変わりますと書かれている)。
Evaluation of EXPR may be in list, scalar, or void context, depending on how the return value will be used, and the context may vary from one execution to the next (see wantarray).
https://perldoc.perl.org/functions/return
Get Back見た
去年の 12月あたりに公開された、ビートルズのルーフトップ・コンサートあたりのドキュメンタリー映画。 Disney+ の独占配信で、これのために入った。腰が重くて見ずにいたけど、この 10月あたりにようやく見た。仲良くやってた。マジで良くて、何回も見直している……。
ディズニー公式のトレイラーがあるけど、個人的には不必要に映画感を出していておかしいのでおすすめしないし、ここにも貼りません。一部分を切り取った公式動画を貼るので、こっちを見て雰囲気を感じてほしい。
www.youtube.com
www.youtube.com
www.youtube.com
話としては、色々あってライブをやらなくなったけど、久々に観客ありテレビショーやったら面白かったし改めてやろうぜとなって、テレビショー & その準備のドキュメンタリー映画を撮ることになり、しかし映画もテレビショーもあんまりな……という意見が出たりして、曲を練習・録音しながら議論しまくり、最終的にはよく使ったスタジオの屋上でライブすっか、でライブするという流れ。なので曲を演奏しまくったりここからどうするか話しまくったりする様子が順番に見られる。各々大人になり各自の意見があるのでそれなりに紛糾していて大変だけど、演奏してるときは楽しそうにしているし、最後にはアルバムができてるので信じて最後まで見てください。
『ザ・ビートルズ：Get Back』が映し出す温かい雰囲気や強い仲間意識、そして天才的な創作風景は、アイコンたる4人のレガシーが確固たるものになる様をとらえている。1969年1月に撮影された60時間超の未発表映像（マイケル・リンゼイ＝ホッグ撮影）や、150時間を超える未発表音源、この貴重なプライベート映像に50年もの時を経て初めてアクセスを許されたピーター・ジャクソン監督が美しく復元・編集し、映画を構成。これはジョン・レノン、ポール・マッカートニー、ジョージ・ハリスン、リンゴ・スターの物語。当時、彼らは2年ぶりのライブを計画し、曲を書き、14曲の新曲をリハーサルしていた。元はライブ・アルバムとしてリリースする予定だったからだ。映画にはバンド最後のパフォーマンスとなった、ロンドンのサヴィル・ロウで行われた忘れ難きルーフトップ・コンサート＜初の完全版＞も含まれる。加えて、バンド最後の2枚のアルバム『Abbey Road』と『Let It Be』で発表された楽曲の数々も本作を彩る。
https://www.disneyplus.com/series/the-beatles-get-back/7DcWEeWVqrkE
それまで全員で集まらずにスタジオ録音で重ね撮りとかしてたけど、今回は集まって編集なしで曲を撮ろうみたいな取り組みをしていて、 1ヶ月間スタジオに通い詰めている。最後の屋上でのライブの音源も含めた全部の録音の中から、 Abbey Road と Let It Be というアルバムに曲が収録されていて、つまり事前にアルバムを聞いている人は映像を見ながらこの音源じゃん!!! となるわけで、良い。
あと、こういう曲つくったよとか、これやりたいとか、そういうのを普通に話してるのが見られるのは最高で、活動こういう感じだったのだな〜と思って、そういう素朴さにテンションが上がる。
↑のところは Something つくってるところで、歌詞決まんないんだけどどういうのがいいかね、思い浮かんだのでいいでしょ、みたいな会話をしながら、みんなで演奏しつつ考えている。これいいところで終わっちゃうけど、この後 Love Me Do の激ゆっくりバージョンを弾き始めてアツい。
他では例えばリンゴが Octopus' Garden つくってきたときの映像がかわいい (チャプター3の最初)。「タコの曲聞かせたっけ」「まだ」って会話から弾き始めて、「Aマイナー覚えたね」って言うジョージ(ハリスン)と、イントロとAメロまでしかない曲の続きをこういう感じとかって話しながらつくっていっている。その後人がだんだん来てすっと参加していく感じとか、これに限らず急に色んな曲を始めるときもすぐ合わせて楽器を弾いていたりして、めちゃくちゃ楽しそう。
個人的にはチャプター3が一番楽しそうなので好き。ピアノ弾く役として呼んだビリー・プレストンがすごく楽しそうなのも最高で、(みんなそうだけど)音楽好きなんだな〜〜みたいになる。チャプター3の Can You Dig It? やばくて、ポールの娘がオノ・ヨーコの真似してア〜って歌うのも入ってるしジョンが Twist and Shout の歌詞歌い出してすぐコーラスもあわせて入れる(多分ジョージ)し弾き続けまくって、それが(一部だけど)アルバムにも入っていてすごい。この一連の演奏全部アルバムに入れてくれたらいいのに……。そのすぐ後にも(かつて聞きまくったり一緒に演奏したりしたのであろう、当時からすると十数年前の)1950年代の曲を急に(冗談で)始めて全員すぐ参加みたいな、そういうことが起きまくっていて、この波長の合った人々はすごいな……となる映像ばっかりでやばい。
屋上で急に演奏を始めたときのインタビューを聞いていると賛否両論あったみたいだけど、終わったあとの会話ではめちゃくちゃ楽しかったって感じになってて、マジで良い。実際屋上で演奏してるの超楽しそうでかわいくて、この演奏だけの (インタビューとかなしの) 映像を通しで見たすぎる。 Don't Let Me Down で歌詞がわけわかんなくなる(実際ミスってごり押してる)ジョンとそれ聞いて笑っちゃうみんなみたいな。その後の活動がどうかはそんなに詳しくないし誰と誰が仲が悪いとか色々言われているけど、しっかり仲が良い瞬間があるのは見てわかるし、それで十分だな〜と思った。楽しく撮った映像が残っていることと、アルバムになっていることに感謝しながら、 Get Back を何回も見/聞きまくっている。
追記: 見逃してたけど、このルーフトップ・コンサートの録音が各種音楽ストリーミングで配信されている The Beatles - Get Back (Rooftop Performance)。 YouTube Music でめちゃくちゃ聞いていて最高の状態。
ちなみにビートルズのアルバムは何回かリマスターされていて、最近の技術でまたリマスターされたやつが出ている。後期の作で録音方法的に音の再処理がしやすい Let It Be や Abbey Road から始まって、この間 Revolver もリマスターされた。有名な「ビートルズの曲は音のパンが左右に楽器ごと分かれている」みたいな話があるけど、最近のリマスターでそれを現代的に分け直しているので、聞いてみてほしいです。個人的には楽器ごと分かれているのも普通に聞いていて楽しいけど……。あとリマスター版では書き下ろし的な感じで色んなボツテイクも一緒に収録されているので、 Get Back 見たあとに聞くとああこれはあの映像ねとなれて楽しい。
Album - Let It Be (Super Deluxe) のプレイリスト
www.youtube.com
Album - Revolver (Deluxe) のプレイリスト
www.youtube.com
z-indexバトル観戦
こんにちは、 
id:hogashi です。 whywaita Advent Calendar 2022 - Adventar 3日目です。
z-index バトル
id:whywaita さんの好きなアルファベットは流石に Y ということでした。ありがとうございます。
やはり僕も id:whywaita さんの id を眺めていて、 w とか y とかから z-index を想起しまして、世の中の z-index バトルがどのように繰り広げられているのか見たいと思い、 GitHub で language が css と scss のコードを検索しました。 API でバリバリ検索したら 1000件しか検索できないということだったので、運良く 1000件にひっかかったコードの中から z-index のみなさまを雑に集計してみました。
ちなみに z-index とはスタイルシートのプロパティで、 z 方向つまり画面に垂直な方向の高さを示すようなものです。値が大きいほど手前に見え、値が小さいものが隠れる、といった具合。 z-index - CSS: Cascading Style Sheets | MDN
z-index が 100 より小さいもの
まず z-index が 100 より小さいものを見てみるとこう。 z-index 、負の数使えるんですね。 MDN にも "Negative values to lower the priority" って書いてある。バトルでいくと、 0 〜 5 では熾烈な戦いがありますね。人類は十進法を採用しました*1ので、なんとなく 10 ごとに山があるようにも見えます。
z-index が正の値のもの
1 〜 100 は上と被りますが、まとめて全部見ます。読者のみなさまのご想像通り、でかい値はでかいです。
対数グラフだと分かりづらいけど、 css での一位は 9999999 (10^7 - 1) 、 scss の一位は 999999 (10^6 - 1) ということで、桁がひとつ違う。まあ冒頭でも書いた通り雑に 1000件検索してるだけなので、まだ見ぬ巨大な z-index はあるかもしれないですね。値を眺めていくと、大体は十進数でキリの良い値だけど、変な値がちょこちょこあっておもしろい (666 とか)。いや〜バトルですね、これが見たかった。
実際の数字を見る
cssz-index の値 数 9999999 1 5000000 5 500000 2 100000 3 99999 2 65536 2 10100 1 10000 18 9999 233 9998 4 5000 2 3214 1 2020 1 2000 2 1900 1 1100 1 1009 1 1001 3 1000 23 999 236 997 1 996 1 895 1 643 1 600 3 500 18 416 1 301 1 300 5 250 2 240 5 233 1 214 1 200 6 199 2 197 3 190 1 150 2 145 2 139 2 110 1 102 2 101 5 100 29 99 2 98 1 86 1 80 2 74 3 57 2 52 2 51 2 50 3 45 2 42 1 40 2 37 2 33 1 32 4 31 2 30 6 25 4 23 1 20 15 19 2 15 3 14 3 13 3 12 5 11 1 10 27 9 16 8 10 7 8 6 41 5 282 4 41 3 293 2 327 1 403 0 289 -1 22 -2 4 -5 1 -9 1 -60 34scss
z-index の値 数 999999 7 100001 42 100000 1 99999 12 50000 2 9999 95 9998 2 5000 9 2010 1 2000 1 1500 1 1400 1 1300 1 1020 2 1000 4 999 102 998 8 700 1 666 1 500 6 400 4 300 2 250 1 200 1 110 1 100 26 99 5 98 8 90 1 70 1 69 1 60 1 50 2 49 1 40 4 39 1 30 7 28 1 27 1 22 2 21 1 20 6 15 1 10 32 9 13 8 3 7 3 6 4 5 111 4 16 3 128 2 181 1 335 0 134 -1 27 -6 1 -19 1 -20 1
統計
雑な統計をとるとこうなるっぽいです。スプレッドシートにすべてを任せているので分散がめちゃくちゃになっているの本当か？という気持ちになるけど、多分本当です。 (追記 2022/12/05: 計算するデータを間違えてたので直しました。引き続き分散はすごい)
| css | scss | |
|---|---|---|
| 合計 | 39506402 | 13753297 |
| 平均 | 15727.07086 | 10053.57968 |
| 中央値 | 3 | 3 |
| 分散 | 89591078363 | 5432903256 |
z-index バトルの頂点はどこか
stackoverflow で「ブラウザは 32bit 使ってるだろうし −2147483648 〜 2147483647 だと思う」って言ってる人はいます (html - Minimum and maximum value of z-index? - Stack Overflow) が、 MDN からたどって CSS の integer の定義を見に行くと、特に最大値などは書かれていないようでした https://w3c.github.io/csswg-drafts/css-values/#integers 。これからも z-index は高みを目指して切磋琢磨していくことでしょう *2。
あそびかた
こういう感じで雑に検索/集計しました。 GitHub の API は 1分おきに 30件取れて、 1000件取れるので、 34 回やると十分そうでした。 awk で TSV にして、スプレッドシートに貼り付けてグラフにしています。
ちなみにこれを書いている 2022/11/29 時点では、 GraphQL API にはコードの検索が実装されていませんでした。無念。
for page in {1..40}; do sleep 65 gh api -H "Accept: application/vnd.github.text-match+json" "/search/code?q=z-index+in:file+language:css&page=${page}" | tee ${page}.json done
cat *.json | jq .items[].text_matches[].fragment | perl -pe 's|z-index|\nz-index|g' | perl -pe 's|^.*?(z-index\s*:\s*[\-0-9]+)\s*;.*$|$1|g' | awk '{print $2}' | grep -vE '[^-0-9]' | sort -nr | uniq -c | awk '$2 ~ /-?[0-9]+/{ print $2 "\t" $1 }'
*1:まどろみ消去 MISSING UNDER THE MISTLETOE (講談社文庫) | 森博嗣 | 日本の小説・文芸 | Kindleストア | Amazon
*2:多分そんなことはなくて、バンドラなどが普及した現代では、変数などを使ったりしてちゃんと管理することで、 z-index のインフレを防ぐ工夫などが生まれていると思います
Renovateでつくられるpull requestのgithub .comへのリンクはドメインがtogithub .comに置き換えられている
Mend Renovate: Automated Dependency Updates を使うと、リポジトリに勝手に pull request を作ってくれるけど、その description に書かれる github.com 以下のリンクは、ドメインが ( github.com ではなく) togithub.com になっている。
これはバックリンクが作られてしまうことを防ぐためのものらしい。確かに、 GitHub 内で他の issue などのリンクを貼ると貼られた側にバックリンクが誕生して便利だけど、 Renovate のような機械的に大量に p-r を作るタイプのものだと困りそう。
ちなみに togithub.com は誰が運用しているのか、と思って whois したら Redacted for Privacy になっていた。が、 Renovate のコードには「renovatebot redirector」と書かれているのを教えてもらった *1。 Renovate の持ち物っぽい。
renovate/index.ts at bef5030e11b227a62866c15cda1036b35273c9d2 · renovatebot/renovate · GitHub
// to be safe, replace all github.com links with renovatebot redirector
https://github.com/renovatebot/renovate/blob/bef5030e11b227a62866c15cda1036b35273c9d2/lib/modules/platform/github/index.ts#L1660
あと #123 とかはデフォルトではそのリポジトリの issue/p-r のリンクになってしまうので ​ が入っていたりするのもテクい……。
*1:
id:polamjag ++
ワンタイムパスワード(OTP)のベストプラクティスじゃない入力フォームに出会う
こんにちは、 id:hogashi です。 masawada Advent Calendar 2022 - Adventar の 2日目です。
OTP 入力フォーム
なぜか 
id:masawada さんとたまにワンタイムパスワード (OTP) の話をする印象があります。偶然生成された「ホホンドホド」という文字列*1が TOTP で出そうな見た目じゃん、とか。
最近もまた微妙に使いづらい入力フォームに出会いました。そこで、世に存在するベストプラクティスとそれに沿わないフォームを見て、ベストたる所以をなんとなく感じてみる回をお送りします。結果的に GitHub がなんかむずい感じになっているという記事になりましたが、もちろん各サービスそれぞれ良いと思ってやっているはずなのであくまで個人の感想です。
まずベストプラクティスを見る
web.dev では、 input タグを:
type="text"inputmode="numeric"autocomplete="one-time-code"
にして使うのがよいと書かれています (フォーム以外に、 SMS の内容の書き方や WebOTP API についても書かれているので、一度見てみてください)。
あと前提として、値を 1つの input だけに入力する想定です。今回の記事ではどちらかというとそっちが重要。
それでは本題です
<input autofocus="" type="text" name="user-code-0" id="user-code-0" class="form-control js-user-code-field h1" maxlength="1" style="height: 2em; max-width: 1.5em; text-transform: uppercase" aria-label="User code 0" data-next="user-code-1"> <input type="text" name="user-code-1" id="user-code-1" class="form-control js-user-code-field h1" maxlength="1" style="height: 2em; max-width: 1.5em; text-transform: uppercase" aria-label="User code 1" data-next="user-code-2" data-previous="user-code-0"> <input type="text" name="user-code-2" id="user-code-2" class="form-control js-user-code-field h1" maxlength="1" style="height: 2em; max-width: 1.5em; text-transform: uppercase" aria-label="User code 2" data-next="user-code-3" data-previous="user-code-1"> <input type="text" name="user-code-3" id="user-code-3" class="form-control js-user-code-field h1" maxlength="1" style="height: 2em; max-width: 1.5em; text-transform: uppercase" aria-label="User code 3" data-next="user-code-5" data-previous="user-code-2"> <span class="h1">-</span> <input type="text" name="user-code-4" id="user-code-4" class="d-none" aria-label="User code 4" value="-" readonly=""> <input type="text" name="user-code-5" id="user-code-5" class="form-control js-user-code-field h1" maxlength="1" style="height: 2em; max-width: 1.5em; text-transform: uppercase" aria-label="User code 5" data-next="user-code-6" data-previous="user-code-3"> <input type="text" name="user-code-6" id="user-code-6" class="form-control js-user-code-field h1" maxlength="1" style="height: 2em; max-width: 1.5em; text-transform: uppercase" aria-label="User code 6" data-next="user-code-7" data-previous="user-code-5"> <input type="text" name="user-code-7" id="user-code-7" class="form-control js-user-code-field h1" maxlength="1" style="height: 2em; max-width: 1.5em; text-transform: uppercase" aria-label="User code 7" data-next="user-code-8" data-previous="user-code-6"> <input type="text" name="user-code-8" id="user-code-8" class="form-control js-user-code-field h1" maxlength="1" style="height: 2em; max-width: 1.5em; text-transform: uppercase" aria-label="User code 8" data-previous="user-code-7">
最近遭遇したのがこれ。 GitHub CLI でログイン (gh auth login) するときに、 Login with a web browser を選ぶと、ブラウザが開いてこの画面になります。 1文字打つと JavaScript でカーソルが右の input に進むタイプなのですが、入力中に input が空のままカーソルが右の input に進んでしまう、ということが起きました。厳しい。
よく観察すると、 keydown で文字を入力し、 keyup で次の input に進む、という挙動になっています。例えば "AB" と入力するとき、 A キーを押したまま B キーを押す (そしてどっちも離す) と:
| # | イベント | input とカーソル |
|---|---|---|
| 1 | 最初 | | _ _ _ - _ _ _ _ |
| 2 | A (keydown) | A _ _ _ - _ _ _ _ |
| 3 | B (keydown) | A _ _ _ - _ _ _ _ |
| 4 | A (keyup) | A | _ _ - _ _ _ _ |
| 5 | B (keyup) | A _ | _ - _ _ _ _ |
……という感じになって、 2つ目の input に B が打てないままカーソルが 3つ目に行ってしまうのでした。ちなみに手順 3 でも A しか入っていないのは maxlength="1" だからですね (1つ目の input に 2文字入ろうとして無視される)。
あとせっかくコンソールにテキストでワンタイムパスワードが出るのに、コピペで入力できないのもつらい。いつもの input と同じ入力体験になってくれるか、あるいは素朴に全体で 1つの input を使ってくれると嬉しいな〜と思っています。
ちなみに
<input type="text" maxlength="1" autocomplete="none" value=""> <input type="text" maxlength="1" autocomplete="none" value=""> <input type="text" maxlength="1" autocomplete="none" value=""> <input type="text" maxlength="1" autocomplete="none" value=""> <input type="text" maxlength="1" autocomplete="none" value="">
Steam も↑の GitHub CLI の OTP の入力フォームとかなり近い形 (1桁ごとに input がある) になっているんですが、うまく作ってあるのか、↑のような困ったことは起きず、しかもメールに書かれたワンタイムパスワードをコピペで入力することもできる(！)ので、特に不便を感じたことがないです。とはいえアクセシビリティとかはどうなのか気になる。
ちなみに2
<input type="text" name="sudo_otp" id="totp" value="" autocomplete="off" autofocus="autofocus" class="form-control input-block js-verification-code-input-auto-submit mb-2" inputmode="numeric" pattern="([0-9]{6})|([0-9a-fA-F]{5}-?[0-9a-fA-F]{5})" placeholder="XXXXXX">
GitHub (Web ブラウザで使ってるとき) のフォームは、 HTML 的には大体ベストプラクティスに沿っているのですが、 6桁入力すると (Enter を押す前に) 即座に submit されるようになっています。 Enter の手間はないものの、最後の桁をミスったときは 6桁の入力が最初からになるのがちょっとつらいポイントですね。 submit はユーザのタイミングでやらせてほしい……。
むすび
僕が個人的に素朴なものを好きなのでバイアスがかかっているかもしれませんが、やはりユーザの体験は損なわないようにしたい、そしてベストプラクティスとされているものは説得力がありそう、という感じでした。あとここまで書いてなんですが、今後は WebAuthn や Passkeys などの OTP の入力が不要な認証方法に移り変わっていくものと思うので、そもそも入力の体験に気を払う必要はなくなっていくかもしれない…… (楽になるのはもちろん歓迎)。それでは良いお年を🎍
*1:string_random で[ヘッドホン]{5,6}から "ヘッドンホホ" を出そうとして遊んでた
