引っ越し以来6年以上使っている食洗機なのだが、最近洗い上がりが悪い。この間などは洗浄完了したはずのコップの内側に赤いゴミが付着していた。 このままではいけないので、いちど庫内を真面目に掃除してみる。 メンテナンス方法の記載がほぼない説明書 この製品の「お手入れ」のガイドは大変簡素である。 ゴミフィルターを毎回掃除せよ たまにノズルの汚れを落とせ たまに外側を拭け 説明書に記載のあるメンテナンス項目はたったこれだけ。 外からの見た目はこのように綺麗を保っているし、言われた通りゴミフィルターはちゃんと毎回片付けている。しかし内部は…… ざっくり庫内の説明 作業前の食洗機の庫内はこのようになっている。 新品同様には程遠いが、汚れているとも言えない、くらいの微妙なライン。 底面の左上にあるメッシュっぽいやつがゴミフィルターで、その右にある穴の開いた金属板はヒーターカバー。 ゴミフィルターさん近影。 説明書では「残さいフィルター」と表記されているが、めんどいのでゴミフィルターで通す。洗浄時に落とされた野菜くずなどがここに集まる。 ゴミフィルターを外せば排水溝が顔を出す。さて説明書には「排水溝」の文字列すらなく、メーカーとしては掃除不要の扱いなのだろうが…… にしてはいきなり汚い。 隙間からは何やら赤いゴミが見える。洗い上がったはずのコップに付着していた汚れはこれだと思われる。  排水溝の奥は魔窟（わりと閲覧注意） 説明書に言及がない以上、ここから先の工程は自己責任になる。 このプラスチックの網みたいな部品は取り外しが可能である。やり方については諸説あるが、雑にやるなら精密マイナスドライバーで持ち上げる。 なお後で言及するが、ここでの力のかけかたは慎重に行う必要がある。 最小限度の力で片端を持ち上げたら、隙間に別のマイナスドライバーを差し込む。テコをかけて外せば、 こうして魔窟が顔を出す。うわっーーーーーー☆ 意外にも掃除そのものは簡単 排水溝のビジュアルは最悪そのものなのだが、見た目に反して悪臭はない。運転するたび90℃の熱湯が通過する環境のため、油汚れは残存せず細菌繁殖も抑えられるのだと思われる。 汚れは最初から「浮いた」状態になっているので、シャワーをかけつつ適当にブラシでこすれば綺麗になる。本体側の排水溝は、ペーパーふきんで水気を吸い取りつつブラシで汚れを取る。...

設備保護洗浄を知っているだろうか。男子トイレの便器に貼ってあるこのようなシールである。 クレーム回避目的っぽい文章だが、このように説明されればなるほどと納得する。 しかし新しい機種では「設備保護洗浄」の文言が消えている。それがこれ。 人が居ないときでも水が流れるケースがある その目的は臭いや詰まりの防止である 一般利用者あるいは施設管理者に知っていてほしいのはこの2点だけで、「その動作が設備保護洗浄と名付けられている」は不要な情報であると、答えを見せられれば納得する。 新しい文章の方が余計な情報もなくスッと腹落ちする感覚がある。この文言を削ぎ落とせるぞと気付いた担当者は偉いと思うのだ。 似たようなもので「便器洗浄」というものがある →  便器洗浄脳の恐怖 誰が便器洗浄などしたいものか、という指摘は言われてみれば確かにと思わせる。実際、最近のトイレはみな「流す」という文言に切り替わっている。 情報を整理すること、最小限の文字数で誤解なく伝わること。それと意識させないくらい引っかかりのない情報伝達になっていることが良いUIの条件と思う。

WSLからWindows側のファイルを操作すると遅い。AWS CLIを使った操作でどのくらい差が出るのか実験してみた。 実験内容 シナリオ Windows側にあるフォルダをS3に同期する 実体はNTFSフォーマットされた単一のSATA SSD上にある 同期対象ファイル数は2.3万個、合計ファイルサイズは16GiB ローカルとS3の差分を検出し不足と過剰をレポートさせる 同一条件で何度も比較するため、実際にはアップロードしないドライランモードを使う 一度ドライランが終わったら間を置かず再実行し、結果が変わるかを見る 環境 WSL側 aws-cli/2.15.24 Python/3.11.6 Ubuntu 20.04.6 LTS / WSL 2.2.4.0 Ubuntu 上の bash から /mnt/d/syncdir に対して aws s3 sync する Windows側 aws-cli/2.15.33 Python/3.11.8 Windows 11 Home 24H2 cmd.exe から D:\syncdir に対して aws s3 sync する 初回実行の結果 WSL：5分22秒 Windows：3分04秒 WSLで実行すると単純に所要時間が75%ほど増えることがわかった。わかりやすく遅い。 当然ながらあらゆるワークロードでこの差が出るわけでもない。 予想される傾向としては： 両環境の差は同期対象のファイル数に線形に依存する たとえば少数の巨大ファイルを同期するような用途であれば差はわずかになる 物理のストレージが高速であるほど差が開く 今回であればSATAではなくNVMe SSDで実験すればより差が顕著だったと思われる （WSLはファイル操作1件ごとに固定値のオーバーヘッドが載るという前提に立っている） 2回目の実行結果 面白いことになった。 WSL：5分12秒 Windows：13秒（！） Windows側の高速化のされっぷりがおかしいことになっている。なんと10倍以上。 明らかに真面目に数えておらず、何らかのキャッシュがあるのだと思われるが、WSL側はほとんど高速化できていないことからキャッシュの有無だけが理由ではなさそうだ。 もしかしたらNTFSのディレクトリメタデータみたいなのを読んでラクできる仕組みがあるのかもしれない。 まとめ：WS...

閉じた傘を留めるための紐がダメになった。気に入っていた傘であり、紐だけの問題で捨てるのはどうにも悔しい。 なんとか直せないかと調べたところ、実は案外簡単に修理できそうなのでやってみることにした。 「傘を留める紐」の正式名称わからん問題 名前がわからない。これが修理方法の調べづらさにつながっている。 最初 "傘 紐" とかで調べてたんだけど、これだと折畳み傘の持ち手についてる輪っかを指す場合が多いみたい。 一応傘ベルトと呼ばれているのは観測できた。けどあんまり検索ヒットしないので正式名称かどうかは不明。 で、名前はともかく、ここがダメになるパターンはいくつかある。体験した限りでは マジックテープが劣化してくっつかなくなる 紐が根本から千切れる というのがあって、どちらも濡れた傘が常に開きっぱなしになるのでQoLが下がる。今回はマジックテープ劣化パターンの修理です。 で、とりあえず修理後の完成物がこれです 修理したあとの傘。ちゃんと閉じれてるし、何ならわりと普通に見えるじゃろ？ だけど開くとこうなっており 図解するとこうで 実は接着面の劣化でくっつかなくなったマジックテープの上から、無理やりスナップボタンをつけて直しているのであった。 修理方法 1️⃣準備 まず資材を用意する。 スナップボタン 他の傘についてたボタンのサイズを測ったら直径10mmだったので、同じサイズのを選んだ。 濡れたり力が掛かったり振り回されたりする箇所なので、縫い付け式ではなくカシメて固定するタイプがよい。 取り付け用工具も同梱されてるやつだと安心。 https://www.amazon.co.jp/dp/B017K3ZOG4 スナップパッキン（ワッシャー） ボタンと同サイズのもの。とはいえ不要かもしれない。後述する。 https://www.amazon.co.jp/dp/B01GG0HNY8 商品自体は↑だが、販売形態でボタンとセットのやつがあったのでそれにした。送料がかからない。 皮ポンチ 買ったボタンに合わせて径を選ぶ。今回のだと2mmの穴が要求されているのでそのあたりのサイズ。自分は家に3mmのやつがあったのでそれを使った。 入手先は百均がおすすめ。Amazonとかだと500円くらいして微妙に高い。 錐あたりで雑に穴あけしても良さそう？ ゴム板 皮ポンチで穴を抜くとき...

我が家では「OK Google、電気つけて」でリビングの電気がONになるよう設定している。しかし3日前くらいから動きがおかしくなった。リビングだけでなく家中全部の電気がONにされてしまう。 「はい。」じゃないんだよ。12個のデバイスを一挙にONするとかどんな家だ。サタデーナイトフィーバーやってんのか。 画面だけの問題ではなく実際の家電操作もおかしくなる。リビングの電気をつけようとしただけなのに、なぜか書斎も寝室も家中すべてがONになるという動きをする。 結論、どういった問題なのか？ 問題の根幹はこうである： 「電気つけて」を「アカウントに登録されているあらゆる照明をすべてをONにせよ」と解釈する仕様変更が、Google側でサイレントに実施された。 これは控えめに言っても頭のおかしい挙動だ。 判定基準がデバイス名だけというガバガバさが一番の問題である。単純に当たり判定が広すぎる。これのせいで自宅と職場の電気が一度に点くような人も出てくることだろう。 いろいろ実験してわかった挙動 「電気つけて」の当たり判定がめちゃめちゃ広くなった 名前に〝照明を意味する単語〟が含まれるデバイスは全て当たり判定にかかる 最初のスクショでも「◯◯の電気」と「ダウンライト」がまとめてONにされていることがわかる 試した限りでも「電気」「ライト」「照明」「光」「明かり」はすべて効果範囲だった。まだあるかもしれない 「電気」がダメなら「明かり」を使おう！ が塞がれている感じ 「光」や「明かり」まで対象にされてるのには偏執的なものを感じるけど、実際はたぶんなんも考えずに "light" を訳しただけとかでしょ デバイス名の判定は部分一致でされる 「リビングの 電気 」「寝室の 電気 」という2つのデバイスがあるとき、「 電気 つけて」で2つまとめてONにされる 何のためにデバイス分けてると思ってるの？？？ 寝室に寝ている家族がいるかも？ とか考えないらしい エイリアス名だけに「電気」を含む場合もばっちり対象である 判定をすり抜けるワードもあるにはあるが、実用性がきびしい 「でんき」「らいと」……これらは効果範囲外だが、音声入力できないので使えない 「ピカピカ」……すごく愉快なおうちになってしまう。ごはんのピカピカつけて！ Home Assistant内部のエントリ名は ***_...

乗り物がたいへん好きなので、定期的に一人旅をやりたくなる。 前回の一人旅では土合駅を見てきた が、あれから2年も経ちそろそろ乗り物欲が我慢できなくなってきた折、衝動と勢いに任せてアァアアーーーッと名古屋に行ってきた。 旅の第一目的はリニモというリニアモーターカーに乗ること。時期は2月のことである。 まずN700Sを捕まえる N700Sはそのへんに大量に生息しているので、狙わなくてもすぐ捕まえられる。山手線の電車より捕獲が楽かもしれない。 子連れの家族旅行などと違って、一人旅ならば自由席で十分である。予約とかないのでホームに着いたときちょうど居合わせたのに乗るだけ。 いまさらだけど新幹線って超たのしいよね。東海道はとても景色よいし。 富士山に、 浜名湖に、 ニチバンの工場に、とたいへん風光明媚なお土地柄。 そして名古屋到着。日本一有名な通過都市にあえて停まる。実績解除。 リニモの駅まで地下鉄にのる これは地下通路にあった原子炉格納容器みたいな路線図。かっこいい。 あとめっちゃ古い案内看板を見つけてテンション上がった。100系新幹線のアイコンもすごいけど、サインのフォントがゴナなのがガチですね。 市営地下鉄の車両はだいぶ古い感じのやつで逆に新鮮。 線路側の標識も見慣れぬやつがいくつもあり、とくにこの勾配標のイラストが良かった。過去と未来が同居している。 ガラガラのリニモは静かに滑る リニモの駅につく。なんか知らんがめっちゃ鳩がいた。乗客の数より多かったかもしれない。浮いてる同士で気が合うのかな。 改札階に降りると空間がジブリパークの宣伝に侵食されていた。地上駅舎にはジブリの痕跡を匂わせるものがないので、ここだけが際立って異空間めいている。 さて、リニアモーターカーといえばやたらと速い乗り物のイメージがあるが、このリニモは最高でも100km/hと速さの方はそこそこに留まっている。 そのかわりに際立つのが走行音の静かさだ。地上との接触が一切ない、6mmくらい浮上した状態で走るので電車っぽい音がしない。これが速さとは全く別軸の新体験だった。ぜひ動画でごかくにんください。 加減速時こそヒュイーンと磁歪音みたいなのが出るが、高速時は風切音ばかりが聞こえ、低速での惰走中などは空調の音しか聞こえない。まさに滑るように走る、というか、リニモの場合は浮いているので本当に滑っている。 ...