無職です。はたらいてます。 旧ブログ: 1 Entry per Day

全日本ラジオボタンのラベルにクリック判定を付けろ協会

f:id:mstssk:20200507202238p:plain

全日本ラジオボタンのラベルにクリック判定を付けろ協会 会長の id:mstssk です。

皆さんはチェックボックスラジオボタンのラベル(キャプション)をクリックしても選択したことにならず憤慨したことはありませんか?
私はあります。

(追記)タイトルはラジオボタンなのに記事はチェックボックス主体で書いているのはただのミスです😇

よくないチェックボックス

Webサイトでこういうチェックボックスによる選択肢をよく見かけます。

選択肢1
選択肢2
<input type="checkbox"> 選択肢1
<input type="checkbox"> 選択肢2

そして大抵の場合、視覚的にチェックボックスと一体になっている「選択肢x」というラベルをクリックしても何も起きないということがよくあります。

こういう実装はアクセシビリティの問題があります。
まず、単純にチェックボックスを選択しづらいということ。
そして、チェックボックスとそのラベルの一体というセマンティクスをHTML上表現していないため、視覚障害者などの読み上げツールから適切に認識されません。

よいチェックボックス

チェックボックスとラベルのセットを表現するには<label>要素を使います。 HTMLだけで実現できます。 JavaScriptCSSもいりません。

developer.mozilla.org

<input>要素を<label>要素でくくるだけでOKです。

<label><input type="checkbox"> ラベルをクリックしてもチェックできる</label>

<input>要素のclickイベントで何かしら処理を走らせている場合でも問題ありません。ラベル部分をクリックしても<input>要素のclickイベントは発火します。

デザインなどの都合により<label>要素でくくれない場合、for属性とid属性を使います。

<input type="checkbox" id="checkbox01">
<label for="checkbox01">ラベルをクリックしてもチェックできる</label>

チェックボックスだけでなくラジオボタンでも同じことができます。 いくつかのパターンを書いたサンプルページを用意しました。

Macでfn+7をF7にする方法

仕事で使っているMacBook Proのバタフライキーボードのチャタリングが酷すぎる。 Unshakyを使ってみたりいているんですが、緩和策でしかないのでやっぱり誤入力が度々起こってしまい、どうしようもない。

HHKBあたりを衝動的に買ってしまおうかと思ったのですが、fn+数字キーによるFunctionキー入力が少々ネックだと感じて、Amazonの購入確定ボタンをまだ押していません。 *1

普段日本語を入力する際にF7キーでカタカナ変換したりなどFunctionキーをよく使っているので、個人的にけっこう大きな課題です。 fn+7の入力に慣れたとしても、今度はデスクを離れてバタフライキーボードを使わざるを得ない状況で戸惑いそうだな、とか買う前から無駄に悩んでいます。

Karabinerでなんとかする

いっそバタフライキーボード使っている時を含めて普段からfn+数字キーで入力する状況に自分を矯正してしまえばいいのでは?と考えました。

KarabinerというMacのキー入力を自由にカスタマイズできるツールで対応できます。 *2

karabiner-elements.pqrs.org

インストールガイドに従い、インストールとMacのシステムの入力監視への操作権限を付与したら、使えるようになります。

  1. Karabinerのサイトでfn+数字キーの置換ルールを検索
  2. Map fn + number keys to function keys (rev 2) というルールセットをImport
  3. インポート後のKarabinerの設定画面が開くので、 Map fn + number keys to their corresponding function keys (rev 1) をEnable

fn+数字キーをFunctionキーに置き換える設定を選択している画面キャプチャ

輝度設定やメディア再生コントロールが動作しちゃう場合

Macのキーボード設定で「F1、F2などを標準のファンクションキーとして使用」を有効にしていると、 Map fn + number keys to function keys (rev 2) ルールではFunctionキー入力になってくれません。

替わりに Map fn + number keys to their corresponding media control keys (rev 2) をEnableにすればちゃんとfn+数字キーがFunctionキー入力になってくれます。

「F1、F2などを標準のファンクションキーとして使用」を有効にしている画面キャプチャ

設定のJSONファイルの中身を見ると理由がわかります。 このルールが実際に行っているのは次のとおりです。

  • Map fn + number keys to their corresponding function keys (rev 1):
    • fn+1 → F1+fn
  • Map fn + number keys to their corresponding media control keys (rev 2):
    • fn+1 → F1

つまり、「F1、F2などを標準のファンクションキーとして使用」が有効になっていない状態のキーマップを想定した置換ルールだからでした。

追記: 別のショートカットキー

ctrl+i に体を矯正したほうがよさそう。

*1:後から改めて考えたら、自分はHHKBが欲しいのではなくMacで使えるまともなキーボードが欲しいだけなので、Magic Keyboardでもええんちゃうかと考えています。

*2:ありがとう、ようてんさん

video要素のcontrols属性のブラウザごとの動作

2020/03/22現在はほぼ全てのブラウザでvideo要素のcontrols属性をサポートしている。

でもどうせブラウザによって動作が違うんでしょ、と思って調べました。

https://caniuse.com/#feat=mdn-html_elements_video_controls

f:id:mstssk:20200322231108p:plain
video要素のcontrols属性のブラウザ対応表

サンプルコード

動作確認のため作ったページ: Example:`controls` attr of video element.

動画は🍏の最近のSplatoon 2のプレイ映像。

github.com

スクリーンショット

左上からZ字の順でSafari, Firefox, Chrome, Edge。

初期表示 再生して1秒後の表示
f:id:mstssk:20200322231245p:plain f:id:mstssk:20200322231240p:plain

各ブラウザのコントロール表示

ブラウザ別の機能差分表

環境: macOS Catalina 10.15.3

  Chrome 80.0.3987.149 Firefox 74.0 Safari 13.0.5
再生/一時停止ボタン あり あり あり
音量コントロール あり あり あり
全画面表示ボタン あり あり あり
再生時間表示 現在/総再生時間 現在/総再生時間 現在/再生時間
Picture in Picture あり(ハンバーガーメニューから
Android ChromeではN/A)
あり(コンテキストメニューから) あり
15秒進む/戻るボタン N/A N/A あり
Chromecast等へのキャスト あり(コンテキストメニューから
Android Chromeではハンバーガーメニューから)
N/A N/A
ダウンロード
※"名前を付けて保存"といったメニューではなくあくまで「ダウンロード」メニューの有無
あり(ハンバーガーメニューから) N/A あり(コンテキストメニューから)
再生速度変更 N/A あり(コンテキストメニューから) N/A
コントロールの表示/非表示切り替え あり(コンテキストメニューから) あり(コンテキストメニューから) あり(コンテキストメニューから)
video要素クリック 再生/一時停止トグル 再生/一時停止トグル 再生/一時停止トグル
video要素フォーカス時スペースキー押下 再生/一時停止トグル 再生/一時停止トグル N/A
video要素フォーカス時左右カーソルキー押下 押している間、早回し/早戻し 押すと15秒進む/戻る N/A
  • Microsoft EdgeChromeと同じ動作だったので対応表では割愛。
  • ※video要素へのクリック・キーボード操作はいずれのブラウザもコントロール表示中のみ有効。
  • Firefoxはマウスホバー時のみコントロールを表示する動作だった。
  • Android ChromeAndroid 10のPixel 3上での同バージョン。

真似しちゃいけないdeployステップの使い方

これはCircleCI Advent Calendar 2019の8日目の記事です。

qiita.com


こんにちは、CircleCI大プッシュしてたらCircleCIの回し者だと思われた@mstsskです。

今回はdeployステップの変な使い方を思いついたので紹介します。

ただし、真似しちゃいけません。

deployステップについて

CircleCIでは、CIジョブで実行するコマンドのステップをrunというキーワードで記述します。 そして実はdeployというキーワードでもコマンドを記述できるようになっています。

deployステップの書き方はrunと同じですが、文字通りデプロイのためのステップであり、動作が異なります。

parallelism を使ったジョブの場合、deploy ステップは他のすべてのノードが成功した場合にのみ、ノード番号 0 として実行されます。 ノード番号 0 以外はステップを実行しません。

引用元: https://circleci.com/docs/ja/2.0/configuration-reference/#deploy

deployステップを使ったconfig.ymlは次のような感じになります。

# .circleci/config.yml
version: 2.1
jobs:
  build:
    docker:
      - image: circleci/ruby
    parallelism: 4 # 4並列で実行
    steps:
      - checkout
      - run: bundle install
      - run: # circleciコマンドを使ってテストを4分割して実行
          name: Parallel Testing
          command: bundle exec rspec $(circleci tests glob spec/**/*.rb | circleci tests split)
      - deploy: # テストが通ったらデプロイ。このステップは4つのノードのうち0番目でだけ実行される
          name: Deploying to dev env
          command: bundle exec cap dev deploy

つまり、deployステップを使うとCircleCIのジョブの中で並列処理の待ち合わせができるんです!

待ち合わせ処理を書いてみる

並列実行している処理の待ち合わせが書けるなら、あとはデータの受け渡しができれば、もう並列処理のプログラム書けるようなもんだよね? 例えば、大きな処理の分割実行とその結果の統合が1つのジョブの中で済ませられるのでは?と考えてやってみました。

deployステップで並列実行の待ち合わせをして、各ノードの結果をCircleCIのキャッシュ経由で受け渡しするサンプルは次のとおりです。

# .circleci/config.yml
version: 2.1
jobs:
  build:
    docker:
      - image: circleci/node:12
    parallelism: 4
    steps:
      - checkout

      # 成果物を result-{ノード番号}.txt に保存する、ビルドとかテスト実行など並列実行したい遅い処理
      - run:
          name: Building Some Results
          command: |
            mkdir results/ &&
            ./dummy_slow.sh > results/result-$CIRCLE_NODE_INDEX.txt

      # 成果物をキャッシュに保存
      - save_cache:
          key: results-{{ .BuildNum }}-{{ .Environment.CIRCLE_NODE_INDEX }}
          paths:
            - results/

      # 各ノードのビルド実行・キャッシュ保存を待つ
      - deploy:
          name: Waiting Results
          command: ":"

      # 各ノードの成果物をキャッシュから取り出す
      - restore_cache: { keys: ["results-{{ .BuildNum }}-1"] }
      - restore_cache: { keys: ["results-{{ .BuildNum }}-2"] }
      - restore_cache: { keys: ["results-{{ .BuildNum }}-3"] }

      # 0番目のノードで他ノードの成果物を組み合わせる
      - deploy:
          name: Merging Results
          command: |
            ls results/
            echo
            cat results/result-*.txt

restore_cache のところがどうしても冗長な書き方になりますが、これで1つのジョブの中で並列実行した結果を統合できます。

もうちょっとconfig.ymlを整理したサンプルは↓。

https://circleci.com/gh/mstssk/circleci-deploy-step-play github.com

何に使うの?

もともとは、並列テストのカバレッジデータをサクッと統合したいと思ってなんとかジョブの中でミニマムに解決できないかと考えて思いついたものです。

実際にジョブの中でデータ集めができることを確認したあたりで正気に帰りました。 本来の使い方とは違うやり方だけど試行錯誤してなんとかなったぜやったぁ状態になる瞬間ってたまにありますよね。

よっぽど1つのジョブの中で完結させたい理由がもしあったなら使えるテクニックかもしれませんが、本当に必要かどうか3回考えてから諦めましょう。 普通に別ジョブにしてpersist_to_workspaceでデータ受け渡してやりましょう。

カバレッジデータの統合をしたい場合は、各カバレッジツールがCircleCIの場合の使い方サンプルを公開してたりしますし、Coverallsは結果をよしなにマージしてくれる機能があるらしいです1

width属性の詳細度は要素セレクタよりも低い

img要素などいくつかのHTML要素では widthheight を属性で書いてもよい。

<img width="100px" src="foobar">

しかし、このwidth属性に対してCSSでもwidth指定をしていたら、どちらが優先されるのか。 <img width="100px"><img style="width:100px;"> は挙動が違うというのはわかって入るが、具体的にどうなんだろうと思って調べてみた。

ざっくり調べた結論としては、属性でwidthを指定するのは何よりも優先度(詳細度)が低いというつもりでいればいいだろう、という感じ。

width属性はCSSじゃないので詳細度という言い方が適切かはわからない。

あと、スタイルと一緒くたにしてしまったが、本来はスタイルの指定に使うものではない。 HTML5.2のspecを一部読んだ感じでは、width属性とheight属性両方とも同時に指定するのが本来の仕様であり、ユーザーエージェント(ブラウザ)はその値を描画のヒントとすることを期待するものとのこと。

実際のブラウザの挙動を確認するのはstackblitzで適当にサンプルコード書いた。 Safari, Chrome, Firefoxあたりで確認して、同じだった。

https://stackblitz.com/edit/attribute-style-specificity

参考

CircleCIの実行時間を3分の2くらいにした、というLTをした


CircleCIのLT会で、会社のCIをどうやって早くしたのかというLTをしてきました。 一人で全部やったわけじゃありませんが、なかなか早くなって満足している一方、もう少し余地がありそうだなとか思ってます。

増枠: CircleCI ユーザーコミュニティミートアップ 【LT会】 - connpass https://circleci.connpass.com/event/140666/

社内のKibelaには、これにどういう意味があって、エンジニアにはこういう良い影響があるんだ、というポエムを書いたんですが、そっちで満足したので自分のblogはあっさりにしておきます。

FACTFULNESSを読んだ雑感想

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

とても良かった。

知識がある人ほど先入観で物事を判断してしまう、何故人は思い込みをしてしまうのか、思い込みを解消するにはどうしたら良いか、という解説を丁寧にしてくれる本。 著者の実体験を口語調で書いているので、読みやすい。

エンジニアにもオススメ。

データを読むとき、何も考えず平均値みるんじゃなく中央値とか最頻値とかが大事だぞ、という話とか地味に大事だと思ったり。 病気の感染拡大を防ぐために道路封鎖したら物流が止まり食糧難になり別の犠牲者を出してしまったというエピソードは、規模は比べるべくもないが、動いているシステムに手を入れることがおおいエンジニアに身につまされるものがあった。