いま開催中のAppleの開発者向けイベント(WWDC)で、新しくリリースされるiOS15版Safariに関する話が出ている。なんでも、アドレス欄やボタンなどを配するツールバーが、画面下部でウェブページに重なるように表示されるようになるとか。どういう状況でこのような表示になるのかハッキリしないが、「画面下部にボタンを固定する」デザインを採用したウェブページはかなり扱いにくくなりそうだ。Appleのプレスリリースには動画で動作が説明されていた。リンク先ページのほぼ中央付近にある「再設計されたSafariのブラウズ体験」の部分に短い動画がある。これを見ると、下方向にスクロールしている間は最小化されて出てこないようだが、上方向にスクロールする際には出てくる。これだと、やはり画面下部に固定ボタンを並べて配置するようなデザインのウェブサイトだと、ボタンが使いにくくなるだろう。元々、物理ホームボタンのない端末では画面下部がソフトウェアホームボタンの領域になっているので「ウェブ上で画面下部にボタンを固定するデザイン」は既に使いにくくなっていたとも言えるわけだが。それがより強固な指針になるということか。Appleによるとこの変更は「片手だけで操作しやすくする」ためのようだ。確かに下端にすべてのボタンがあれば、親指だけで操作できそうな気はする。発狂するウェブデザイナーも多々出てきそうな気もするが。(笑) いや、笑いごとではないかも知れない。ちなみに私のサイト(の一部)では、スクロールするとメニューバーが画面端に固定されるようになっているが(PCでもモバイルでも)、固定位置は画面上端である。なので影響はなさそうだ。個人的には、画面下端に何かを固定表示するデザインを使ってこなかったのは、画面の下は「読み進める先」なので、そういう「視線の先」になる場所に何かを固定したりしなかったりする表示はあまり望ましいとは思っていなかったという点もある。もっとも、最大の理由はPCだとボタンを下端に固定すると使いにくくなるから、だが。PCとモバイルとのデザインの差を大きくすると作るのが面倒なので、PC側に合わせたのだ。元々PCだけのことを考えたサイトデザインだったのを、後からモバイル対応にした場合には、このような考え方になりやすいだろう。

下記のような条件があるとき、ⒶとⒷの関係や、ⒶとⒸの関係を、計算式1つで表す方法はないものか。
Ⓐが  970 のとき、Ⓑは -45 で、Ⓒは 10 になる。
Ⓐが 1070 のとき、Ⓑは -50 で、Ⓒは 12.5 になる。
Ⓐが 1170 のとき、Ⓑは -55 で、Ⓒは 15 になる。
Ⓐが 1270 のとき、Ⓑは -60 で、Ⓒは 17.5 になる。
Ⓐが 1370 のとき、Ⓑは -65 で、Ⓒは 20 になる。
何か思いつきそうな気がしないでもないのだが、私の乏しい数学的センスでは思いつけなかった。
なお、単純に割り算しただけだと以下のようになる。

なんかⒷとⒸをちょっとどうにかして(笑)下駄を履かせるか脱がせるかすると、いい感じに一定の割合になってくれないかなと思うのだけど。

(追記)
思いついた。Ⓑ÷(Ⓐ-70)、Ⓒ÷(Ⓐ-570) だと、割合が一定になる。

これで、CSSがそれぞれ1行で済むようになった。めでたし、めでたし。

Excelでこの5行のテーブルを範囲選択してから(選択範囲の)右下端を上へドラッグすることで、この5件の間に存在する法則を保ったままⒶがもっと小さい値のときのⒷとⒸの値を出して（下図の赤色部分）、それらが0になったとき（下図の灰色部分）のⒶの値を引き算してから割合を計算することにしたことで分かったのだけど。こういうのを最初から何か計算で求める方法があると思うのだが、どう考えれば良いのか思いつく脳がない。orz

まあ、Excelパワーで判明したので良かったのだが。

なお、先の電話は私宛ではない。家の固定電話の留守電に何かが録音される機会自体がせいぜい半年に1度あるかないか程度の頻度だが、企業からの連絡電話以外となると2～3年に1回あるかないか程度の頻度しかない。しかも、「長年連絡を取っていなかった知人からの留守電」みたいなのだと10年に1回あるかないか程度の頻度ではないか（私の知人ではない）。私の個人的な古い知人から家の固定電話に電話が掛かってくることはない。そもそも大半の知人は電話番号を知らないだろうし、連絡はメールを使えば充分だからだ。メールアドレスをアドレス帳に登録していなかったとしても、私のウェブサイトを検索して見れば連絡先メールアドレスは明らかなので迷うことはないだろう。私がウェブサイトを持っていることを知らない知人は居ない。ウェブサイトのURLを覚えていなくても名前で検索すればすぐに分かる。高校以前の同級生で大学以後に付き合いがない人々は私がウェブサイトを持っていることは知らない可能性が高いだろうが、そういうのは個人的には「知人」の範疇に含めていない。

家の固定電話の留守電に「この携帯の番号に返事くれ」的なメッセージが残っていたのだが、肝心の電話番号は喋ってくれない。固定電話はナンバーディスプレイを別途契約していない限り発信者の電話番号は分からないのだ。電話と言えば携帯電話を指すことが多い昨今、その事実に気付かない人々も多くなっているのかも知れない。いや、電話がかかってきた直後であれば、136をダイヤルすることで直前の発信者番号を知ることはできる（1回30円）のだが「直近1回の電話」しか分からない仕様なので、留守電が録音された後に別の人から電話が掛かってきていた場合にはその後の人の番号しか得られないから役に立たない。固定電話には自動音声アンケートみたいな電話がよくかかってくるのでその可能性はそこそこある。留守電に録音された後に別の人から電話が掛かってきたかどうかを知る方法はないので、136にダイヤルして得られる電話番号が留守電に入れてくれた人の電話番号である保証はないから、136で番号を知る方法は使えない。したがって、固定電話の留守電に「返事くれ」と入れる場合には自分の電話番号も口頭で述べない限り無理である。

毎日新聞に、住居が小学校に近い高齢女性ほど鬱リスクが低いという記事が出ていた。こういう相関関係は、因果関係とは限らないので注意が必要だ。相関関係が因果関係とは限らない例を分かりやすく示したページにSpurious Correlationsがある。下図は、このページで紹介されている「米国メイン州での離婚件数(赤線)とマーガリンの消費量(黒線)」の相関関係図である。

グラフからはずいぶんと高い相関があることが分かるが、マーガリンを消費すればするほど離婚が増える（または、離婚すればするほどマーガリンがたくさん消費される）わけがないだろう。他にも「プールでの溺死件数とニコラスケイジの映画出演件数」にも高い相関があると先のページで紹介されている。「○○な人ほど○○である」のような相関関係を見かけたら、まず「本当に因果関係にあるだろうか？」と疑った方が良い。

駅にATMがあるのでついでに記帳しようかと思ったのだが人が並んでいたのでやめておいた。残高はオンラインバンキングで分かるので特に記帳を急ぐ必要はない。紙の通帳に記帳するのは、確定申告のための帳簿に記載する伝票番号を通帳にも書いておくためだ。そうしなければならない規則はないのだが、帳簿の根拠を明確にしておく方が無用なトラブルを防ぐために望ましいと考えている。オンラインバンキングの画面を印刷するなりPDFにするなりする方法だと、通帳のように整頓された情報にならないので（見やすくないと意味がないので）使えない。もちろん1年分の履歴を一括して表示させれば（通帳と同じように）整頓された情報にはなるのだが、帳簿は1年分をまとめてつけるわけではなく毎月少しずつつけるので、画面を保存する方法では使いにくい。1ヶ月分の履歴ずつ印刷すれば計12枚で1年分にはなるのだが、そこまで取引件数が多いわけではないので無駄に煩雑になる。だからやはり今のところは紙の通帳を使うのが最も見やすく扱いやすいのだ。この点がオンラインでも解決されれば、通帳はオンラインだけで良くなるだろう。銀行がペーパーレスを推し進めたいなら（通帳には毎年200円の税金が掛かるらしいので銀行はできるだけ通帳を発行したくないハズだ）、オンラインバンキングの機能をもっと高めて頂きたい。今でもわりと便利ではあるのだが、「紙の通帳なら自由にメモが付加できる」という点をオンラインの取引履歴でも実現されるともっと便利になる。

インクジェットプリンタの印刷結果を見ると黒色の一部がズレていたので、ノズルのヘッドクリーニングをした。クリーニング結果を確認するためにノズルチェック(吹き出し口1つずつからの印刷テスト)をするのだが、このときA4用紙1枚を消費してしまうのがちょっともったいない。トレイからの自動給紙ではなく手差し給紙をさせてくれる仕様だったら余っている紙片を使って印刷できるのだが、問答無用で自動給紙されてしまう。プリンタのユーティリティに給紙選択を加えるだけで良いのだから実装は簡単だと思うので、実現してくれないものか。

それはともかく、印刷のズレは解消できて、綺麗に印字できるようになった。

Windows Media Player用の視覚エフェクトアドオン「FRUITY(フルーティ)」が楽しい。

Windows7までのPCで使っていたのだが、Windows10でも問題なく動作した。DLLの関係で32bitでしか動作しないので、てっきり64bit版Windows10ではダメなのかと思っていたのだが、64bit版のWindows10でも、Windows Media Playerは32bitで動作していたので問題なかった。

風呂場の蛇口から水漏れがしている。蛇口というと語弊がありそうだが、蛇口そのものではなく、温度調節をするプラスチックレバーの下からポタポタ毎秒2滴くらいのペースで落ちてくる。バケツを置いておくと、一晩で2杯分くらいになる。毎秒2滴だと、1分120滴で、1時間7,200滴。水1滴はずいぶん微量に思えるが、4～5時間で3万滴くらいあるとバケツ一杯に溜まるのか。

一度知ってしまったら二度と「知らなかった状態」には戻れない。おもしろい映画は何度見ても楽しめると思うのだが、中には1度目に観たときの記憶があると、絶対に「1度目のときと同じ感覚」で2度目を観ることはできない話というのもある。レオナルド・ディカプリオ主演の「シャッターアイランド」という映画が2010年に公開されて映画館で観たのだが、この脚本もまさにそうだ。Amazon VideoでPrime特典に入っていたのを発見したのでお勧めしておきたい。最後まで観てすべてを知ってしまったら、絶対に同じ感覚で2度目を観ることはできないストーリーだ。単に「結末を知っているから」とかそういう問題ではない。そういう映画は他に何があるかな……と思ってふと考えてみると、ブルース・ウィリス主演の「シックスセンス」もそうだ。（シャッターアイランドとシックスセンスにオチの共通点はない。）

要素の中身をごそっと入れ替えたいときの記述は、JavaScriptのinnerHTMLではプロパティなので「代入」だが、jQueryのhtmlではメソッドなので「引数」に指定しないといけない。うっかり $('.hoge').html = '書き換え内容'; などと書いてしまうと、文法的にはエラーにならないのに、意図通りには動作しない結果になって、首を捻ることになる。$('.hoge').html('書き換え内容'); が正解だ。

私のメインサイトで使っているドメインは nishishi.com だが、CGIの動作実験用に使っているサイトのドメインは nishishi.org だ。記録を見ると2011年に取得していた（nishishi.comの取得は2000年）。この .org 側サイト（にしし らぼらとりー）のトップページ等は長らく適当なまま放置していたのだが、さすがにそれもどうかと思ったので一念発起して見た目を整備してみた。昨日から今日にかけて、こればっかり作業していた。これまで自分しか読めない場所で書いていた「CGI開発に関係するつぶやき」もどうせならコンテンツの1つにしてしまおうかと、開発放言として公開してある。自分用に書き留めていたメモばかりなので、他者が読んで意味が分かるものばかりではないとは思うのだが。コンテンツが少なすぎるのもどうかと思ったので、賑やかしのようなものだ。

まだ新メインPCは設置していないのだが（開梱すらしていない）、昨夜は電源タップの配線を作り替えてから、キーボードとマウスを2台のPCで共用できるケーブルを出してきて接続した。いま使っている5代目メインPCとその前の4代目メインPCを共用していた頃に使っていて、その後は押し入れに仕舞っていたケーブルだ。ちゃんと正常に動作している（いや、PC側はまだ1台しかないので、切り替えが正しくいくかどうかは未確認だが）。2台のPCへのUSBケーブルと、キーボードとマウスのUSBケーブルが集中する切り替え本体の背面は磁石になっているので机の背面に貼り付くから便利である。机の背面には他に、電源タップが2個とスイッチングHUBが磁石でひっついている。磁石で机の背面に取り付けられると、床にケーブルが散乱せずに済むので掃除が楽だ。もしこれからPCデスクを調達しようとしている人が居たら、机の側面や背面が金属でできている製品を強くお勧めしたい。PC関連機器は(オフィス用途を考慮しているのだろうが)裏面が磁石になっている製品も多々あるので、そういうのを選ぶと床がスッキリする。ケーブルにはどうしてもホコリが溜まりがちなので、床からは離しておきたい。

「abandonedly」って英語の辞書に載っていなかったのだが英語ではないのだろうか？ と思ったが「abandoned」という単語はあるのか。「fly abandonedly into the sun」をGoogle翻訳にかけると「放棄されて太陽に飛ぶ」という和訳になったが、DeepL翻訳にかけると「日向ぼっこをする」という訳語になった。ええ!? ずいぶん違うな。前者はいかにも直訳で、後者はいかにも意訳のように感じられるけど、文脈からするとどちらも違うような気もしているのだが。(笑) DeepLの場合は特に前後の文も含めて訳せばまた違った和訳になりそうだが、文章ではなくて歌詞だから元々ぶつ切りなのだ。……と思ったが物は試しに、と思って「Spread your wings and prepare to fly. For you have become a butterfly. Fly abandonedly into the sun.」の3文をDeepLで翻訳してみると「翼を広げ、飛ぶ準備をしなさい。あなたは蝶になったのだから。太陽に向かって放心して飛べ。」となった。なるほど、それっぽい。ちなみにこれをGoogle翻訳で和訳すると「翼を広げて飛ぶ準備をしてください。あなたは蝶になっているからです。放棄されて太陽に飛ぶ。」で、懸案の文(＝3文目)の訳は同じだった。まあ普通の翻訳ソフトならそうだろう。そういう意味ではやはりDeepLの訳し方がすごいのだな。しかし、最初の「日向ぼっこをする」はどこから出てきたのか。いや、意訳として分からなくはないのだけど（ここでの意味は違うと思うが）。むしろ、最初にその訳を引っ張り出してきたことの方がすごい気もしてきた。ちなみに、マライア・キャリーのButterflyという曲の歌詞である。

kohprpと入力して漢字変換すると一旦は「個hprp」になるのだが、ちゃんと修復変換候補として「時頃」を出してくれるATOK。すごいと思うのは、全部のキーが1つずつ右にずれているというわけではないのに、ちゃんと「時頃」を出してくれる点だ。本当ならjigoroと入力しなければならないのだから、もし右隣に1個ずつずれたキーを押したならkohptpになる。しかし、rだけは正しく入力できていたので、打ったキーはkohprpだ。それでも「時頃」が修復変換として出てくる。よくできているものだと感心した。この機能ができてからは、多少の打ち間違い(たいていは同じキーを押しすぎる間違い)に気付いてもそのまま強引に変換キーを押すようになった。だいたい7割くらいは、意図したとおりの良い感じに修復して変換結果を出してくれる気がしている。とても便利だ。