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

日本語の文字単位diffオプションをgit aliasに設定する

まとめ

  • ある正規表現を指定することで、日本語文章のdiffを文字単位で見れるようにできる
  • それをgit aliasに設定したかったけど、正規表現エスケープ周りでうまくいかなかった
  • スクリプトファイル化したものをgit aliasで実行することで解決した

日本語を文字単位でdiffを見るいい感じの方法

gitで日本語の文章を扱っていると、行ではなく文字単位でdiffが見たかったりする。

そういう場合、↓の記事で紹介されているdiffのオプションがとても便利で重宝しています。

skoji.jp

git diff --word-diff=color --word-diff-regex=$'[^\x80-\xbf][\x80-\xbf]*' またはショートハンドで git diff --color-words=$'[^\x80-\xbf][\x80-\xbf]*' と実行すると、空白文字は無視して文字単位での挿入・削除だけが表示できる。

例えば簡単な例で、 id:mstsskJSer.infoさんに出したtypo修正のdiffで試してみると、次のように削除した文字列と追加した文字列だけがインラインで表示できている。

f:id:mstssk:20210819234353p:plain

ただgit aliasに設定するとエラー

これをgit aliasとして .gitconfig に次のように設定し git diffrgit showr <commit> のように簡単に実行したかったが、この書き方では正規表現が問題になるらしく実行時にbad configエラーが発生してしまった。

[alias]
    diffr = diff --color-words=$'[^\x80-\xbf][\x80-\xbf]*'
    showr = show --color-words=$'[^\x80-\xbf][\x80-\xbf]*'

頑張ってエスケープしようとしたが、通るやり方を結局見つけられなかった。 普通のaliasでやる方法もあるが、個人的にはgitのaliasとして設定しておきたい。

同じことで悩んだ方の記事: Git Diff で日本語の文章も綺麗に差分を出す - Neo's World

しばらくは diffr = diff --color-words="[^€-¿][€-¿]*" という正規表現を使わない設定の仕方で回避していたが、これは正規表現から文字の実態に置き換える時に盛大に間違えていて、動作したりしなかったりの駄目な設定だった。

外部のシェルスクリプトとして実行してしまえばいい!

どうにかならんもんかと最近あらためて見直したところ、git aliasなんだから外部化してしまえばええやん、と思い至った。

git aliasは ! を先頭につける書き方をすると任意の外部コマンドやシェルスクリプトを実行できるので、やりたいことをシェルスクリプトにしてそれを呼び出す様にしてしまえばいい。 むかーし自分の過去blogにも書いていたやり方だったのに、すっかり忘れていた。

mstssk.blogspot.com

というわけで、次のような感じに設定してうまくいきました。

~/.gitconfig

[alias]
    diffr = !~/path-to-shell-dir/git-color-words.sh diff
    showr = !~/path-to-shell-dir/git-color-words.sh show

git-color-words.sh

#!/bin/bash

cmd=$1
shift
git $cmd --color-words=$'[^\x80-\xbf][\x80-\xbf]*' $*

前述のファイル内容はサンプルで、実例はdotfilesリポジトリを適当に参照してください。

github.com

天穂のサクナヒメのエンディングがエモすぎて心に空いた穴が塞がらない話

※この記事は天穂のサクナヒメのネタバレを含みます。

www.marv.jp

こちらのnoteを読んで、とても「わかる!わかるぞー!」と思い、俺も書き殴りたくなったので書きました。

note.com


そももそもあんまりゲームは何本も買う方じゃないんですが、Ghost of Tsushimaをトロコンするまでプレイして「今年は良いゲームに巡り会えたな」とか思っていたところに現れた『天穂のサクナヒメ』はとっても良いダークホースでした。

世間で取り沙汰されてるとおり、稲作だとかしっかりとした横スクロールアクションとかももちろん良かったんですが、エンディングがエモすぎて一気に個人的GOTYが塗り替えられてしまいました。

以下、どこが心に刺さったのか簡単に切り分けつつ書き出してみました。

ミルテのかなわない約束

これは🍏の解釈なので実際の設定とは違うかもしれませんが、エンディング近くでミルテと田右衛門が叶わぬ約束をしているシーンがあります。

ヒノエ島で長く過ごすうちにそれが当たり前になってしまい、本来は布教の旅の途中であるはずのミルテが「また来年も…」と言ってしまった自分に驚愕したりの一連の流れです。 そしてある夜、ミルテと田右衛門が二人きりで話すシーン。 「自分は元の世界に戻らなければならない、サクナ達と出会い培ったいろいろなことを故郷に持ち帰り広めなければいけない。いつかそれを終えたら、また…」 といった事をミルテが田右衛門に話しているのをサクナは聞いてしまいます。

でも再会することは多分不可能なんですよね。 食事シーンで語られる、ミルテの国からヤナトにやってくるまでの話を聞くかぎり、とても簡単に往復できる距離ではない。 戦国時代くらいの日本とヨーロッパの距離感です。 そもそも一度麓の世に戻った後に頂の世に戻ってこれる可能性はほとんど無い。 もう田右衛門着いていけよ!とか思っちゃうんですが、そこでしっかり別れを描くというあたりがこの作品の憎いところ。 田右衛門は戦ばかりの麓の世に戻れない一方で、ミルテは宣教師としての役目を果たさなければならない。 この作品はそれぞれの心の傷と決意を蔑ろにして大団円にはしなかった。 しっかり別れを描いた。 それが(いい意味で)しんどい。

しかも、エンディング見た後の喪失感が冷めやらぬまま、ローンチトレーラーを見返してみたらまたヤバい。

冒頭のキャプション:

遥か東方の果て ヤナトの国あり
古来よりこの地では神の世と人の世
すなわち"二つ世"があると信じられてきた
これは我が布教の旅の中 異教の神サクナと出会い 共に暮らした日々の記録である

宣教師ミルテ著 "耶那土見聞記"より

www.youtube.com

トレーラーでもうミルテが帰ってしまうことが思いっきり示唆されてるじゃん!!!!!11

2度も喪失感を味わう羽目になったわけですよ。 ローンチトレーラーで辛い気持ちになるとは思わなかった。

ゲームの当初の設定ではこんなキャラではなかったミルテをここまで心を抉るキャラクターにしたのは凄いと思うわけです。

ゆいのかんざし

エンディングでヒノエ島を去るきんたを見送るゆいの後ろ姿が写ります。 その頭には無骨な風車の形のかんざしが刺さっています。

ゆいがいなくなったイベントできんたが話していた「作ってあげると約束したかんざし」が、エンディングのここぞというタイミングでしれっと映り込んでいるんです。 そしてカメラが切り替わり、笑顔で見送るゆいの姿を写します。 きんたはいつものスンとした顔で振り返っています。 いつもの二人の姿なんですが、その間にも素晴らしい「ヤナト田植唄」と、二人が今生の別れであることを暗示するかのようにその後の二人の行く末を書いたキャプションが表示されています。 こういう演出は他のゲームなんかでもたまに見かけますが、とっても心が抉られて大好きな演出です。

やり込みプレイができない

プレイ後のやりこみがエンディング前の状態のループなのがつらい。

こんなに心を抉るエンディングを見せられた後に、「やり込みプレイはエンディング直前の状態で進行します」とか言われても辛いわけですよ。 あんな別れをした/する仲間たちが、これまでの姿のままいつものように家にいる姿なんか見てられないわけですよ。 どうしてもそれに気が向いてしまって2周目プレイに着手できませんでした。

ボリュームがちょうど良かった

エモい点というわけではないですが、ゲーム全体のボリュームがちょうど良かったと思ってます。 あんまり超大作だとやってる途中でフェードアウトしちゃったりすることもあるんですが、サクナヒメがちょうど物足りないくらいでした。 ストーリー的には伏線回収しきってないけど、クリア後の喪失感がとっても素晴らしかったんですよね。 そして上にあげた諸々の心を抉る点たちの、その衝撃たるや。

ヤナト田植唄の歌詞が良い

仕事中にYouTube Musicのランダム再生をBGMにしているんですが、「〽️植えよ〜 根付けよ〜」と始まる度に手が止まってしまいパフォーマンスが落ちてます。 エピソード記憶としてしっかり残しってしまっているので、歌い出しでもうエンディング直後の感情が思い出されてむしろ辛い。

www.youtube.com

実際の田植え唄を編纂して作ったというのがまた素晴らしくて、作品世界と現実を地続きにしてくれてるような気持ちになります。 エンディングのキャプションでも「作詞:不明」になってるし、YouTube Musicの概要欄の作詞者情報もpublic domainになってます。 歌詞については、冒頭に書いたnoteの記事も必見です: https://note.com/tekken8810/n/n39f146378c70

あとは、前半でしっかり振ったあとにCパートあたりでそれを逆手に取るみたいな歌詞の作りになっているのが単純に好みです。

ちなみに、楽曲や朝倉さやさんについて調べているうちに、朝倉さやさんのプロデューサーががん再発で余命宣告されているという情報を見てしまい余計に心にきたりしました。

感想がしんどいとかつらいとかばっかりだけど、それもまた作品の魅力

大団円ですっきり終わる作品ももちろん良いんですが、すっきりすぎて感情が右から左にスッと抜けてしまったりもするわけです。 良くも悪くも観た人に強い印象を与えて、「ああっ、もうちょっと観たい!」みたいな喪失感を感じさせる作品ってやっぱり凄いと思います。

天穂のサクナヒメの購入した理由自体はゲームさんぽでプロモーションされているのを観て、「稲作なんてニッチなところをゲームに組み込むとか凄いな。こういうゲームを世に出してくれたこと自体が凄いと思うし投げ銭がてら買っておくか」という感じです。

www.youtube.com

正直、厄災の黙示録が発売するまでのつなぎにプレイするかーくらいの気持ちだったんですが、すっかり心にクソデカ感情を刻み込まれてしまい、ぜんぜん厄災の黙示録がプレイできてません。

2020年いろいろありましたが、この作品に出会えたことは素晴らしい出来事だったと思っています。

RICOH GR3をWebカメラ化したメモ

id:mstssk の周囲にも一眼レフ持ちがちょこちょこいて、Webカメラ化をやっているみたいなので羨ましいなーと思っていたら、自分が持っているRICOH GR3でもWebカメラ化ができそうと書いている人を見かけのでやってみたら出来た。という話です。

bbs.kakaku.com

GR3にUSA-PHD01を接続

どうするのか

GRなら無条件で買うので、特にGR3のスペックをそこまで確認していなかったのが悪いんですが、この子はUSB Type-C端子からDisplayport alternate modeで外部映像出力をしてくれます。背面の液晶に表示する内容がそのままDisplayport出力される感じです。

なので、上記の価格.com掲示板にレスを付けている方の言う通り、Displayportの信号をうまい事変換してやればよいわけです。

GR3 → DP-HDMIアダプタ → HDMIキャプチャーボード → MacbookPro

撮影時のインジケータ類の表示も出力されちゃいますが、それはDISPボタン何度か押せばトグルして消せます。

必要なもの

DP-HDMIアダプタ

ミヨシのUSA-PHD01。
USB PDに対応しているのでGR3に給電しながらカメラが使えます。
というか、こいつ自体も給電が無いと動作してくれない様子。 www.mco.co.jp

HDMIキャプチャーボード

HDMIの信号をUVC(USB Video device Class)として扱えるようにしてくれるデバイスが必要です。 PCからは普通のWebカメラのように認識されるようになります。

まともなものを買うと2万円くらいするのですが、とりあえずお試しということでAmazonの2千円台の安いやつを適当に購入。 Amazonの販売者情報ページを見る限り、深センのZasLukeというよくわからんメーカーのです。

注意点として、Macに繋げる場合はちゃんとMac対応を謳っているものを買いましょう。 これを買う前に別の製品を「Winのみサポートって書いてあるけど、Webカメラの規格なんて一緒だし行けるやろ」と思って本当にテキトーに購入したら640x480サイズの映像しか受信できなくてつらい思いをしました。しかも16:9の映像を640x480で入力してくるから完全にアスペクト比おかしいし…

給電

USA-PHD01にUSB PDで給電する必要があります。
もともと持っていたAnker PowerPort Atom PD 2を使いました。 もちろん、USB Type-Cで給電できれば別のものでもよいです。 ただし、給電量には注意(後述)。

www.ankerjapan.com

その他

三脚として卓上に置くので小さめの↓を購入。

しかし、小さすぎて下にマンガを何冊か重ねて高さを稼いだり、ホットシューにアダプタ無理やり付けて伸ばしたりする羽目になりました。 他の人はクリップ型のカメラ雲台で吊り下げるようにしている人が多いみたいですね。

使ってみた結果/使用上の注意

残念なことに、購入から5日でキャプチャーボードが壊れました

ちゃんと使えてはいたので満足はしていたのですが、安物だったのでさもありなんという感じです。
USBに繋いでいる間ずっと妙に発熱していてヤバいなと思い、使っていないときは抜くようにしていたのですが、5日目に忘れて繋ぎっぱなしにしていたときにオシャカになりました。

映像について

カメラの設定次第ではありますが、Webカメラよりやはりかなり画質は良かったです。 使っているところをスクリーンショット撮る前に使えなくなってしまいましたが。

Webカメラは照明の光でどうしても全体が白っぽく写ってしまったりしますが、GR3では当たり前ながらちゃんと露出や絞りを調整して撮影できます。
Webカメラとして使っているときはマニュアルモードにして絞りなどを固定して使うとよかったです。そうしないと写っている自分が多少動いたときにいちいちフォーカスや絞りが変化して大変でした。

給電が足りない

給電には気をつけましょう。

60Wまで出してくれるし大丈夫やろと思ってAnker PowerPortにMacbookPro 13'とUSA-PHD01をそれぞれ繋いで使っていたのですが、これではUSA-PHD01への給電が足りないようで、使っているうちにどんどんGR3の電池がなくなっていくというタイムリミットありのWebカメラになってしまいました。
リモートでミーティングしたり人狼しているときに「電池がなくなりました」というメッセージと共に俺の姿が消えるのを見た人が何人かいます。

アスペクト比はPCのソフトウェア側でなんとかする

安いキャプチャーボード使っていたせいかもしれませんが、受贈する側のソフトウェアが映像のサイズまたはアスペクト比を指定していないと16:9が4:3になってしまって細長い映像になってしまいました。自分でMediaDevices.getUserMediaでやってみたら、サイズのパラメータなしだと4:3にされて細長になり、16:9のサイズを指定すると整った絵になりました。 また、getUserMediaで1280x720より小さいサイズを指定して映像を取得しようとすると、縮小するのではなく真ん中あたりを勝手にクロップした映像になるという罠も(どこまでがデバイスのせいで、どこからがブラウザやOS・ドライバーのせいか切り分けできていない)。

例えば、Zoomは16:9がデフォルト設定なので問題なく使えましたが、Google Meetはデフォルトでは縦長になっちゃってました。 Google Meetも設定をいじればよかったのかもしれませんが、試していません。

Google Meetで縦長になってしまった問題は、Snap Cameraを間に挟むことで解消しました。

snapcamera.snapchat.com

Snap CameraはWebカメラの映像にフィルタをかけた映像を別のWebカメラのデバイスとして扱えるようにするツールです。 Snap Cameraを通して出力する映像はデフォルトでは1280x720(16:9)になっているので、フィルタ無しでSnap Cameraを通すことでアスペクト比がおかしい問題を回避しました。

もっと動画配信やカメラに詳しい人はSnap Camera以外の回避方法を知ってそう。

ちゃんとしたキャプチャーボードを買おうか迷っている

とりあえずで買ったキャプチャーボードが壊れたので今GRはただのカメラに戻っています。

以下は、今度はちゃんとしたキャプチャーボードを買おうかなー、どうしようかなーというメモ。

動画配信やっている人たちのなかでは、キャプチャーボードといったらAVerMediaElgatoらしいので、その2社から自分のニーズに合っているものをピックアップした。

条件は、Mac対応・UVC・比較的最近のモデルであること。

UVC非サポートでもWebカメラとして使えたりするデバイスはあるそうだが、WindowsなのかMacなのかでまた変わってきそうなので、安全側に倒してUVC前提で探してます。 汎用的な規格に沿ってた方がいいでしょ、たぶん。

Elgato Cam Link 4K

名前の通り、カメラの映像を変換してつなげるためのデバイス。 使いたい用途にドンピシャの製品。だいたい2万円。

www.elgato.com

似た製品でもっと安いものはあるけど、安いものを買った結果5日で壊れたから、まともに使えるものを買うにはこのあたりが最低ラインなんだろう。

非4K対応版の旧Cam Linkはもう販売していないみたい。

ちなみに製品ページにはUVC対応かどうか書かれていないが、サポートページの方に書いてある。 help.elgato.com

Elgato Game Capture HD60 S+

同じくElgatoのデバイス。こちらはゲームキャプチャー用で、HDMIパススルーに対応している。

せっかくキャプチャーボード買うならゲームキャプチャーもできるやつにしようかなーと迷ってこちらもピックアップ。

www.elgato.com

UVC対応についてはサポートページ参照。 旧モデルのHD60 SはUVC非サポートという罠。

help.elgato.com

HD60 SとWindows環境でそのままWebカメラとして使えたという方はいる様子。

AVerMedia Live Gamer Ultra GC553

HD60 S+と同じようなスペックのAVerMediaの製品。 価格はAmazonではこちらのほうが1000円くらい安い。

https://www.avermedia.co.jp/jp/product-detail/GC553

HD60 S+に比べるとこちらのほうがパススルーできる最大解像度が高い。

ちょうどHD60 S+とGC553の比較について説明している動画を見かけたのでURLを貼っておく。
https://www.youtube.com/watch?v=OLLYkcgW9Ic

AVerMedia Live Gamer Portable 2 PLUS - AVT-C878 PLUS

あっ、これ見たことある!と思ったけど、見たことあったのは旧モデルの「Live Gamer Portable 2」の方だった。 この旧モデルが2016年発売で、以前からこれを使って https://stat.ink/ を使っている人を見かけていた。

https://www.avermedia.co.jp/jp/product-detail/GC513

AVerMedia ライブゲーマーエクストリーム GC513

AVerMedia ライブゲーマーエクストリーム GC513

  • 発売日: 2019/09/06
  • メディア: Personal Computers

これは2018年発売のマイナーバージョンアップモデル。名前にPLUSと付いている。

UVCサポートはもちろん、ハードウェアエンコードもサポートしていて、こいつ単体で動画キャプチャできるすごいやつ。

 

他にもたくさんあるけど、UVC対応を確認できなかったりしたものは省いているのでこんだけ。

用語メモ

  • ハードウェアエンコード
    • キャプチャデバイス自体に録画機能がついているもの。SDカードにMOVファイルとして保存したりする。
  • ソフトウェアエンコード
    • キャプチャデバイスHDMI信号をPCへの入力に変換するだけで、録画はPC側で何かしらのソフトウェアを使って録画する必要があるもの。
  • パススルー
    • HDMIの入力を出力から(ほぼ)ラグなしで出せること。あくまでHDMI信号の話で、PCへの入力は遅延する。PC側の性能にも寄ったりするらしい。
  • UVC: USB video device class

input[type=range]で範囲指定っぽいUI

f:id:mstssk:20200518231950p:plain

input[type=range]要素を組み合わせると、なんちゃって範囲指定のUIが構築できそうなのでやってみた。

始値を指定するスライダーと、終了値を指定するスライダーが連動して、開始値が終了値より先にいったりしないよう制限もかけている。

developer.mozilla.org

実際に動作するサンプルはStackblitzで作ったページを参照: https://react-ts-keurq5.stackblitz.io

stackblitz.com

大事なのはdatalist要素で範囲を定義しておくこと。 単純にinput[type=range]要素でmax属性とmin属性で最大値・最小値または連動するように互いのvalueを参照し合うよう指定しても、想像した任意の値の範囲を指定するようなUIにはならない。 正確に言えば、開始値が終了値を追い越さないようになっているし開始値と終了値を指定する機能自体は満たしているけど、スライダーの値の範囲がぐちゃぐちゃ可変してしまって使いづらい。

そこで、datalistで値の範囲を定義して、2つのinput[type=range]要素がどちらも同じ値の範囲を持つスライダーになるようにした。 開始値のスライダーが終了値のスライダーより大きい値にならないように仕込むには、max,min属性を使っていけなくて、onChangeイベントで引っ掛ける必要があった。

以下にコードを貼り付けておく。 今回はReactで作ったが、やっていることは単純なので、他のフレームワークや素のJavaScriptでもすぐ書ける。

import React, { Component } from "react";
import { render } from "react-dom";
import "./style.css";

interface AppProps {
  startAt: number;
  endAt: number;
  callback?: (range: AppState) => any;
}
interface AppState {
  startAt: number;
  endAt: number;
}

class App extends Component<AppProps, AppState> {
  constructor(props) {
    super(props);
    this.state = {
      startAt: this.props.startAt,
      endAt: this.props.endAt
    };
  }

  render() {
    const onChangeStart = (event: React.ChangeEvent<HTMLInputElement>) => {
      const startAt = parseInt(event.target.value);
      // 終了値を超えないように
      if (startAt < this.state.endAt) {
        this.setState({ startAt }, () => {
          this.props.callback(this.state);
        });
      }
    };

    const onChangeEnd = (event: React.ChangeEvent<HTMLInputElement>) => {
      const endAt = parseInt(event.target.value);
      // 開始値を下回らないように
      if (endAt > this.state.startAt) {
        this.setState({ endAt }, () => {
          this.props.callback(this.state);
        });
      }
    };

    // option要素で値の範囲を定義しないと、範囲が固定にならない。
    const options = [];
    for (let i = this.props.startAt; i <= this.props.endAt; i++) {
      options.push(<option key={i} value={i} />);
    }

    return (
      <div>
        <h1>input[type=range]で範囲指定っぽいUI</h1>
        <p>スライダーをドラッグして開始と終了をそれぞれ指定する</p>
        <datalist id="datalist">{options}</datalist>
        <p>
          値の範囲: {this.state.startAt}{this.state.endAt}
        </p>
        <div>
          開始:&nbsp;
          <input
            type="range"
            list="datalist"
            min={this.props.startAt}
            max={this.props.endAt}
            value={this.state.startAt}
            onChange={onChangeStart}
          />
          <br />
          終了:&nbsp;
          <input
            type="range"
            list="datalist"
            min={this.props.startAt}
            max={this.props.endAt}
            value={this.state.endAt}
            onChange={onChangeEnd}
          />
        </div>
      </div>
    );
  }
}

const logging = value => {
  console.log(value);
};

render(
  <App startAt={0} endAt={120} callback={logging} />,
  document.getElementById("root")
);

stackblitz上のソースコードhttps://stackblitz.com/edit/react-ts-keurq5?file=index.tsx

ルンバe5を買ってしばらく経ったのでまとめ

f:id:mstssk:20200511233053j:plain

TL;DR

 

  • 明るい色のラグを買え。

 

 

2月くらいにルンバe5を購入しました。基本的に満足しているのですが、いくつか課題もあったのでまとめてみます。

www.irobot-jp.com

 

ラグ・絨毯の色には気をつけろ

ルンバを買ったのと近い時期に暗めの色のラグを買ってしまうという、ルンバビリティを一番下げるミスをしてしまいました。 そして買って早々に落下センサー部をアルミホイルで隠すというハックをする羽目に。

ラグの色はこんな感じです。このくらいの色でもルンバは段差だと認識しちゃうようです。

f:id:mstssk:20200511233050j:plain
暗めのブラウンなラグ

センサーの隠し方は少し試行錯誤のした結果、こういう形に落ち着いています。

  • 幅1cmくらいのアルミホイルで覆うだけ。横からは光が入るようになっていないといけない。
    • センサーを完全に隠してはいけない。真っ暗になり常に段差の上にいる判定になりルンバが動かない。
  • お手入れの際にセンサー部をどのご家庭にもあるエアダスターで掃除する。
    • 覆った分、ホコリ等が挟まって汚れやすくなる。汚れて暗くなり段差と誤検知することもある。わざと残した横の隙間からエアダスターでホコリを吹き飛ばす。

f:id:mstssk:20200511233045j:plain
センサー部を1cm幅のアルミホイルで覆って上から黒いマスキングテープで固定している。手前にわざと隙間を残す。4つ のセンサーそれぞれ同じ様に覆う。

もちろん、段差検知のためのセンサーを隠しているので、段差に落ちるようになります。 うちの場合、玄関の段差に落ちるようになったので、バーチャルウォールで回避しています。

あと、センサーを隠しているせいなのかいまいちわかりませんが、Dirt Detectが動作していない気もします。2ヶ月立ちますが、一度もありません。我が家がそこまで汚くないだけなのかどうか…

 

1,2cmちょっとの段差なら乗り越える

ので、越えてほしくないところに物を置いたりしないように。

カラーボックスの1番下の段にビニール紐を置いていたら、そこにルンバが突っ込んで巻き込んで止まってました。

また、こういうリクライニングチェアの足に乗り上げて止まってしまうのも想定外でした。 今は足に黒い紐を張ってルンバが乗り上げないように回避しています。

 

バーチャルウォールよりそもそも床に物を置かないようにする

バーチャルウォールが充電ベースに向いていなくても、近くにあると干渉することがあるようです。ルンバがいまいちベースに帰ってくれない場合、バーチャルウォールの位置を変えてみるとよいと思います。

ホームベースから2.5 m以内に デュアルバーチャルウォールや他のルンバのホームベースなどが設置されていないことを確認してください。これらの機器の赤外線が干渉する場合があります。 ルンバがホームベースに戻らない。

そもそもバーチャルウォールをできるだけ使わないほうがよいと思っています。 とはいえ棚が足りないとか配線の都合で電源タップや一部機器が床置きになっているので、無印良品のワイヤーバスケットにとりあえず入れることでルンバを回避したりしています。

18ー8ステンレスワイヤーバスケット2 約幅37×奥行26×高さ8cm 通販 | 無印良品

 

家にいる時に動かさないほうがよい

購入後は平日昼間の会社にいる最中にルンバに動いてもらうようスケジュール設定していました。 しかし最近は自宅勤務が続いています。

ルンバが動いている最中も気にせず仕事したりしていたんですが、ラグの上を掃除する時に流石にホコリがそれなりに舞うようで、咳き込むようになりました。

今は買い物やジョギングのため外出する時に動かすようにしています。 Googleアシスタントの外出時ルーティンにカスタムコマンドで「掃除して」と仕込んでいます。

Googleアシスタントのルーティンのカスタムコマンドの設定画面で「掃除して」と入力して保存する

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

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:ありがとう、ようてんさん