今年の業務も終わり

今日が、今年の最終出勤日となる。2021/12/29 〜 2022/01/05 まで休みだ。

この休みの期間の主な予定は以下の通りである。

正直あまり大した予定はない。引っ越しは大きな予定ではあるが、ただの移動作業みたいなものだし。

引っ越しにあたってあと残っている作業があるとすれば、こんなところだろうか。

リストにまとめると意外にやることまだあった。まあ今すぐにできるものばかりではないから、時期を見計らって徐々に終わらせていくしかない。

引っ越しの荷造りは、休み入ってからすぐにやっても、そのあと引っ越しまでの間に何もできなくなってしまうから。やるなら引っ越しの 1 〜 2 日前くらいかな。それまでの間はまったりとポケモンでもやろうかな。

2ch まとめ動画が面白かった

昨日の夜中、というか日付は今日だが、2ch のスレまとめ動画がおすすめに入っていたので見たら結構面白かった。

どれもかなり長い動画だったが、結局最後まで観てしまった。世の中、こんな人もいるんだなと思った。

最後の「浮気してないのに浮気がバレた件」に関してはふつうに小説として出してもいけそうな感じの物語になっていて、最後はハッピーエンドになってなんか良かった。

これを観ていて寝たのが 5 時とかになってしまった。起きたのは 10 時台だが、特に眠くはない。昨日、たっぷりと昼寝 (夕寝？) をしたからだろう。

Kindle Oasis のスリープ画面を今読んでる本にしてみた

Kindle Oasis のスリープ画面は、デフォルトだと新聞紙やペンやタイプライターなんかのサンプル画像がランダムで表示されるようになっている。

設定で、そのスリープ画面を、今読んでいる本の表紙にすることができる。

前からこの機能があるのは知っていたが使っていなかった。なぜなら何を読んでいるのかを見られるのがあまり良いと感じなかったからだ。

しかし、あらためて思った。見られるって、誰に？ と。ずっと引き篭もっているんだから、見られるも何も、見られる相手がいないじゃないかと。

なら別にこの設定にしても良いよねと思い、気分転換にそうすることにした。

今は NEW GAME! を読んでいるので、NEW GAME! の表紙がスリープ画面に表示されている。使っていないときは机の上に画面が見える状態で置いているので、ずっと可愛い女の子の表紙が表示されている。意外にこれも悪くないなと思った。

ちなみに今は 6 巻を読んでいる。

トラックボール使用感経過報告 🖲

(トラックボールの絵文字なんてあったのか…… 🖲)

トラックボールを使い始めて 1 週間ちょっと経った。

ある程度は操作に慣れてきた。トラックボールは比較的慣れやすいと思う。少なくとも分離型キーボードよりは。

ただ、いくつか細かい不満点が出てきた。

たまに Bluetooth の接続が切れる

これはトラックボールの不満というより MX ERGO の不満点であるが、たまに接続が切れる。接続が切れると、しばらく再接続までに時間がかかる。

頻発するというほどではないが、滅多に起きないというわけでもない。ほどほどに起きる。数日かもうちょっと日数経つくらいに 1 回は起こる。

再接続までにそれなりに時間がかかるのがちょっとストレス。

ホイールを回しすぎると効かなくなる

これはトラックボールのハードウェア的な問題なのか、それともソフトウェア (OS 等) の問題なのかわからないが、Web ページなどをスクロールした際、一番上もしくは一番下まで勢いよくホイールでスクロールすると、その後、ホイールで下または上にスクロールできなくなる。ちょっとマウスカーソルを動かしたりすると復活する。

これも地味に不満がある。ソフトウェアの問題なら何かしらの設定で改善するかもしれないが、今のところ原因不明。

ボールにゴミが溜まると使いづらくなる

ボールの部分にゴミが溜まると、ボールの回転がうまくいかず引っかかることがある。

まだ 1 週間ちょっとしか経ってないのにゴミが溜まるのが驚きなのだが、定期的に手入れをしないと快適に使えないのがちょっとめんどくさいかなと思った。特にめんどくさがりな自分には。マウスとかトラックパッドだったらそこまで手入れしなくても快適さが失われることはあまりないのだが。

直感的なジェスチャーはトラックパッドに劣る

トラックボールにはいくつかのボタンがついていて、それに機能を割り当てることで便利なショートカットとして使えるが、やはり直感的な操作ができるトラックパッドに比べると不便かなと思った。

トラックパッドなら複数の指で上下左右にスワイプすることで様々な操作を行うことができる。これに関してはトラックパッドのほうが便利だと思う。

というわけで、トラックボールも万能ではないなと思った。数ヶ月後にはトラックパッドに変えているかも。でもトラックパッドは macOS には最適化されているけど Windows ではちょっと微妙なので、今後デスクトップ PC を新調するなら共通して使えるという意味でもトラックボールが無難なのかなとは思う。トラックボールは、たしかにマウスよりは腕や肩が疲れない気がするので。

シャンプーとボディソープのキリが悪い件

あと 1 週間で引っ越しになるわけだが、もうすぐボトルに入っているシャンプーとボディソープが切れそうだ。

それぞれ 1 本ずつ詰め替え用のストックはあるのだが、もうすぐ引っ越しなのにこのタイミングで詰め替えをしたくない。

とはいえ、残りの量で 1 週間を乗り切れるかというと、ちょっと足りない気もする。しかしここで詰め替えてしまうと、ボトルに入った分が無駄になってしまう。

うーむ、タイミングが悪いなあ。

引っ越しの時間帯が決まった

引っ越し日は前から決まっていたが、時間帯がまだ決まっていなかった。なぜなら時間指定をしなかったからだ。

時間指定をするだけで 20,000 円ほど上乗せされる。馬鹿げている。ぼったくりなんじゃないかとすら思える。

なので時間指定はしなかったのだが、今日、アート引越センターから連絡が来て、時間帯は 16:00 〜 18:00 の間に決まった。

この時間帯に引っ越し前の荷物の搬出に来るので、引っ越し先での搬入はもっと夜遅くになる。さらに、移動の時間もあるので、終わるのは 20:00 とか 21:00 とかになりそうだ。

別に夜遅くになる分にはこちらは構わないのだが、この時間帯だと真っ暗になるはずなので、洗濯機などの重いものを安全に搬入してもらえるかが少し心配だ。

まあそこはプロだからなんとかやってくれるだろうけど。

やる気が出ない

最近やっぱりやる気が出ない。でもこれは毎年のことだ。冬になるとなぜかやる気が出なくなる。気分も落ち込み、テンションが上がらない。

やっぱり冬は嫌いだ。寒くて外にも出られないし、ウイルスも蔓延しやすいし、肌も乾燥するし。

毎年こうだから、もう冬はいっそのことがんばらなくて良いって決めちゃおうかな。動物も冬眠するし、たぶん人間にとっても冬はエネルギーをチャージする期間なんだろう。うん、きっとそうだ。

今年もまだ冬は続くが、何もする気が出なくても気にしないようにしよう。むしろそれがふつうだと思おう。それから、やる気が出なかったら大人しく休もう。

ウルトラワイドモニターが気になってる

ウルトラワイドモニターが最近ちょっと気になってる。世間では割と認知もされていて、自分も使ったことはないが存在はもちろん前から知っていた。

しかし、あまりメリットを感じられなかった。そもそも世の中は 16:9 を中心に作られているので、ウルトラワイドモニターがあっても、Web ページは左右が大幅に空いて無駄になるだろうし、ゲーム画面などもうまく表示されないだろう。

Web ページの表示に関してはウィンドウを狭めて複数の画面を表示するなどできるが、ゲーム画面などは無理だろう。

と思っていた。まだ調べたわけじゃないので確かなことはわからないが、ウルトラワイドモニターの中には、画面を左右 2 分割できるものがあるらしい？

それを使えば、左はゲーム画面、右は PC の画面とかできるのかな。それができるなら良さそうかなと思った。

なぜそれができるなら良いと思ったかというと、モニターの数、つまりはモノの数を減らせるからだ。モノを減らしたい理由に関しては別の日にも書いたのでここでは割愛。

モノはあまり増やしたくない。かといって、1 枚だと不便。なぜなら、ゲームの配信をしたり、ミーティングで画面共有するときなどに、1 枚をゲーム画面やミーティングの画面にして、もう 1 枚を配信の画面や作業画面にしたい、といったことが多々あるからだ。

ウルトラワイドモニターなら、横幅の広さを利用して複数のウィンドウを開いておくことで、PC だけで完結することならモニター複数台と同等の作業環境が実現できることはわかっていた。

しかし、ゲーム画面のように PC 以外のものを画面に映そうとしたときに、一つの出力しか出せないのは不便だなと思っていた。

でも、それが解決できるウルトラワイドモニターがあるなら、それも良いかなと思った。そうすれば、今 2 台あるモニターを 1 台にまとめられる。

今 2 台あるモニターは、左右に並べられるデュアルモニターアームに接続している。しかし、横一列にきれいに並べられているかというと、残念ながらそういうわけではない。お互いのモニターがピッタリとくっつかないし、お互いの間にスペースも生まれてしまっているので、左モニターの左端から右モニターの右端までを見るのにかなり距離がある。なので、それぞれのモニターを内向きに向けているのだ。

これだと見た目的にもダサいし、リングフィットアドベンチャーや YouTube を観たりする際には内側に寄っていると見づらいのでいちいち正面側に向きを直すのだ。これを毎日やっているのだが、できればモニターの位置は固定させたい。

ちゃんとしたウルトラワイドモニターなら、この辺の問題をズバッと解決してくれるんじゃないかなとかちょっと期待している。

ちょっと前までは将来的にはモニターを 3 枚にしようかとか考えてもいたが、それよりはウルトラワイドモニターのほうがスッキリして満足度が高くなる可能性もある。

なのでとりあえず新しいモニターを追加するという考えはいったん置いておいて、ウルトラワイドモニターを調べてみようと思う。…… 引っ越ししてからね。

GitHub Pages で日記を更新するのは Jekyll が最適なのではという話

GitHub 移行化計画により、ブログも日記も GitHub Pages に移行しつつある。

GitHub Pages は静的サイトしか扱えないので、そうなるとどの静的サイトジェネレーターを使うべきか、という問題が浮上する。

で、ブログや日記に限らず、今まで GitHub Pages では Jekyll しか使ってこなかった。

その理由は、Ruby 製で馴染みやすいとか、GitHub 公式とか、自動デプロイ機能があるとかだが、今あらためて考えると、最後のこの自動デプロイって最強なんじゃないかと思い始めた。

というのも、今まさに、この日記を iPhone の Working Copy というアプリで更新しているが、スマホで更新するということは、コミットやプッシュはできても、ローカルでビルドすることはできない。

つまり、もし Jekyll の自動デプロイ機能が GitHub Pages になかったら、スマホで更新しても、GitHub Pages にはそれが反映されないということだ。

反映するためには、PC を開いて、スマホで更新した分の日記をプルして、ビルドしたものをまたプッシュしなければならない。

せっかく iPhone でお手軽に更新できる方法を見つけたのに、それを GitHub Pages に反映させるために結局 PC を立ち上げなければならないのは本末転倒だ。それでは続かない。

あるいは、そもそもビルドしなくても済むようにする方法もあるが、そうなると毎日の日記をすべて HTML で書かなければならなくなる。もはや論外だ。

そう考えると、GitHub Pages の Jekyll 自動デプロイって、まさにスマホでブログや日記を更新するために存在しているものなのではないかとすら思えてくる。

スマホでできるのはせいぜい文章書いてプッシュするところまでだ。ビルドなんてできるわけないし、ましてや HTML をそのまま書くなんてまっぴらごめんだ。

Jekyll を選ぶのはともかく、今までローカルでビルドしたものではなく GitHub Pages 上の自動デプロイ機能を使ってきたのは、単にトレイリングスラッシュがなくなってすっきりするとか、リポジトリのファイル構成もすっきりするとか、そういう体裁の部分だけが理由だった。

しかし、こうやって iPhone で GitHub の更新をしてから、やはり Jekyll の自動デプロイじゃないとダメなんだな、とあらためて感じた。

GitHub Action を使う？

別のサイトジェネレーターで同様のことを実現する方法がないかも、一応考えてみた。Jekyll ばかりを優遇して考えても思考が偏ると思ったので。

使ったことはないが、GitHub Action を使えば、GitHub リポジトリのプッシュイベントをトリガーにして何かできるのではないかと思った。これを使えば記事が更新されたタイミングで自動的にビルドを走らせることができるかも。

でも、おそらくこれって自前でサーバか何かを用意する必要があるか、あるいは GitHub への課金が必要になると思う。そうなると運用コストが増えてしまうので、Jekyll の自動デプロイ機能が無料で提供されているなか、あえてこの方法を取るメリットがあまり感じられない。

まあ自分が Jekyll 好きだから、という時点ですでに考えが偏ってしまっているのかもしれないが、他のサイトジェネレーターが好きなら、それが使えるというメリットはかなり大きいのかも。たとえば Hugo とか。

正直なところ、他のジェネレーターを使ったことがないので比較ができない。だから、こういう考えに固執してしまっているのかもな、とも思った。

懸念点

Jekyll 自動デプロイも万能というわけではない。使えるプラグインは限られている。何でもかんでもプラグインを実行できてしまったらセキュリティ的に問題があるからだろう。

そうなってくると、旧日記サイトのようなデザインを構築できるのかが不安になってくる。こちらの日記も旧日記と同じデザインにしようと思っているが、全く同じようにはできないかもしれない。

たとえばカレンダー表示って、何日が何曜日かという情報が必要で、それは旧日記システムのほうではプログラム的に取得していた。これが果たしてできるのかどうか。

プラグインに制限があるなら、自動デプロイの、Jekyll ファイル内での Ruby プログラムの実行に制限があってもおかしくない。

これは実際にやってみないとなんとも言えないので、今不安になってもどうしようもないんだけど。

もしできなかったら妥協したデザインにするか、もしくは手元でのビルドにするか、あるいは GitHub Action を使うか、だが、手元でのビルドや GitHub Action の運用だと手間やコストが増えるのであまりやりたくないなあ。気軽に更新できなかったら意味がない。気軽に更新できるということは、それほどブログや日記更新において極めて重要なことなのだ。