ちなみに

火曜日の空は僕を押しつぶした。

ミルクコーヒー

福岡にある FILTER SUPPLY というお店のコーヒーが見た目も味も好きで買っているのですが、夏なので冷たい牛乳で飲めるやつを買ってみました。

hifiltersupply.stores.jp

牛乳500ccにパックを投入して12-14時間冷蔵庫で放置すると完成する。

ただし、パックが浮かんでくるので1回目に作ったときは対策をしてなくていまいち味が出きっていない感じになってしまって物足りなくなってしまった。 何か棒的な物で押さえて沈めておくと14時間くらいでめちゃくちゃ美味しくなったのでおすすめです。うちは菜箸で押さえておきました。

基本は暖かい珈琲の方が好きで夏でもホットで飲んでいるのですがたまには冷たいのありだなと思った夏でした。

hifiltersupply.stores.jp

玄関周りの改善

別府市に引っ越してから、生活を快適にしようといろいろとガジェットを導入している。 その中でも玄関周りが特に快適になっているので紹介します。

まずはスマートロック。

前々から気になっていた Qrio Lock を導入しみました。

qrio.me

オートロックとハンズフリー解錠が便利で鍵を使うことがまったくなくなりました。 もちろん物理的な機構を使っている限り、トラブルで開かなくなることもありえるので物理鍵を完全に手放せる訳ではないのですが。

オートロックは家側にもセンサーがついていて確実にしまったことを確認してから締めてくれるので、ドアがしまってないのに鍵が回ってしまうことはありません。 ただし、逆に反応しないことが多々あって何度か締め直すことがあるのででここはストレスポイント。もうちょっと精度が上がったほしい。

ハンズフリー解錠は家から一定以上離れてから戻ってくると家の前で立ち止まったタイミングで鍵を開けてくれる。 この一定以上離れてからというのがあるので、出かけている途中で帰ってきたと判定されて開いたりはしないので安心。 また、高さとかも見てくれているらしいので、別の階にいるときに開いたりとかもしないのが助かりです。

ただし、たまに反応してくれなくて家の前で待ちぼうけをくらったり、逆に早すぎて廊下を歩いているときに開いたりしている。 「立ち止まったら」という条件がちょっと怪しい感じがするのでここも改善されたいです。

ちなみに一定以上離れるということは例えばゴミ捨てなんかでちょっと出かけるときとかはハンズフリー解錠が機能しない。 この時はアプリを起動して手動で開ける必要がある。さらにオートロックと組み合わせると閉め出される可能性もあって少し緊張感がある。 そういう場合を想定して一時的にオートロックを解除する方法があるのでゴミ捨てのときなんかは鍵を開けっぱなしで出たりしています。

スマートロック、どこのがいいとかは比べてないので分からないのですが、マジで楽なので今すぐ導入した方がいいと思います。

store.google.com

次にスマートドアベル。最近は Amazon が買収した会社のやつが出ていたりするけれど、見た目がお洒落な Google の Nest シリーズのものを購入した。 問題はお洒落すぎてインターホンだと認識されなくて押してもらえないことがあることです。

これも便利で人間が近づくとボタンを押す前に通知がなって接近を知らせてくれる。インターホンが鳴ったタイミングでは相手の素性がだいたい把握出来ているので落ち着いて対応できる。 ただし、精度がよいので廊下を人が通っただけで反応するのでノイズが多いのと、プライバシー的にちょっと問題がある気がしている。 反応するスペースを設定出来るらしいが、廊下が狭いのであんまり意味ない気がして試していない。やってみたら変わるのかもしれない。

また外出先からも応答が出来るので、家にいる風を装って荷物を玄関に置いておいてもらったり出来る。 不在にならなくて助かる。別府の配達の人は置き配設定していても置き配してくれないので地味に助かっている。

賃貸で工事が出来ないので壁には両面テープで貼り付けていているが、うまく張り付かずに何度か落下してしまっている。 結果、レンズがボロボロになっていて真ん中当たりが白くかすんでしまったので、ちょっと見にくいし対象者判定にも影響が出ている気がする。 こんな悲劇を繰り返さないためにもみなさんはしっかり貼り付けてください。

この2つで玄関が驚くほど快適になるので迷っている人は早く導入しましょう。 細かい話とか直接聞いてもらったら答えられます。

「macOS カーソル強制バインディングのすすめ」の最近の様子

qiita.com

この記事を読んでから実践してきたのですが、今回新しいPCに変わって設定しなおそうとしたら karabiner-elements がアップデートされていてなんかかっこいい感じになっていて UI からは JSON のインポートが出来なさそうな感じになっていました。(本当は出来るのかもしれない)

モダンな方法では Web サイトから探してインポートするようになっているみたい。

ke-complex-modifications.pqrs.org

探してみたら Emulation Modes のカテゴリに Ctrl+p/Ctrl+n to arrow up/downKey Specific のカテゴリに Ctrl+b/Ctrl+f to left/right arrows というのが見付かるので、これらをインポートして有効化してやる。

そうすると無事にカーソル強制バインディングが実現できる。

別府市に引っ越しました

f:id:Sixeight:20220727092958j:image

 

貴方がこのブログを読んでいるということは、私はもう京都にはいないでしょう。

 

去る2022年7月22日、長らく住んだ京都市を離れて、別府市に移住しました。

京都府亀岡市に産まれて、これまでの人生の全てを関西で過ごした僕ですが、初めて関西を出ることになりました。

 

理由は「そこに温泉があったから」です。

 

長らく自宅で仕事をするうちに広い家に引っ越したくなってきて、当初は京都市内で家探しをしていました。

しかし、よく考えると別に同じ土地に住む合理的な理由はないなと考え始めて、生活費が安い地方も候補に入れたというのがきっかけでしたが、その後、プライベートな理由で九州という選択肢が出てきて、その中でもやはり温泉がある別府というロジックで決まりました。

 

町の下見には行ったものの家はその時に決まらなかったので、現地に行かずにいきおいで契約しました。結構ドキドキしていたのですが、問題もあるものの概ね快適で満足しています。やっぱり部屋数が多いのは正義。

 

もちろん引っ越してから毎日温泉に入っていて、お肌すべすべかつ疲れがかなりなくなっています。市営の温泉なんて200円ですよ。入らない理由がない。

 

想定していたよりも移住は成功で、とても愉快に暮らしています。

皆さんも土地にしばられない暮らしをしてみませんか?

 

P.S.

仕事については残念ながらフルリモートが認められなかったので現職を退職することになりました。8月から新しい職場で働きます。月一で東京にも行くことになったので東京の人もよろしくお願いします!

問題の切り分け

同僚が困っていそうだったので無意識にやっている問題の切り分けを言語化してみる。

  1. 「分かっていること」と「分かっていないこと」をリスト化する (頭の中でやっています)
  2. 分かっていないことの中で優先度をつける
    • 簡単に試せて効果が高そうなものの優先度が高い
    • 知識がないものも優先度が高い
  3. 試せそうなものについて仮説を立てる
  4. 仮説を検証する
    • 試せそうなものは片っ端から試して「分かっていること」を増やす
  5. 知識がないことについて調べる
  6. 3に戻る

それでもどうしようもなく分からない場合はあきらめて寝る。 その問題についてのアンテナが出来るのでそのうち解決のきっかけがみつかるはず。

ボーイスカウト・ルール、先に直すか、後から直すか。

まれによく目的の変更にリファクタリングを混ぜたプルリクのレビュー依頼を受けるので、そのたびに変更とリファクタリングは分けてねって話をしている。

レビューするときにもdiffが混ざっていて見にくいし、将来的に変更の経緯を追いかけるときにもノイズになってしまう。 コミットが分かれていたらまだマシなんだけれど、そういう場合はたいてい同じコミットに複数の目的が混ざってしまっている。

www.clear-code.com

僕は1コミットには1つのことというルールを出来るだけ守ろうと思って暮らしているのでどちらかというと過激派なのですが、プルリク単位くらいではやることを絞って欲しいとは思っています。

みんな単一責任原則は大好きな気がするけど、コミットやプルリクにも同じ姿勢で取り組んで欲しい。

話はそれたのですが、ボーイスカウト・ルール。 来たときよりも美しくっていうやつです。 言うは易く行うは難しというやつで、簡単に見えてこれをチーム全員で当たり前のようにやっていくのはなかなか難しい。

最初の話から機能変更と一緒にリファクタリングするのはよくないと思っているのですが、じゃあいつするのかと言うと、変更の前か後になります。

なんとなく期日に対するプレッシャーがあると、先に機能を実装してしまって、あとから余裕があったらリファクタするということになりがちなんじゃないかと考えています。 しかしながら、なんで綺麗にするのかというと、今後のメンテナンス、つまり機能追加や不具合修正なんかをやりやすくするためです。

つまり何が言いたいかというと、先にリファクタリングした方が、機能追加も楽になって、結果的に早く価値を届けられるのではと言うことです。 しかもメンテナンスしやすいコードになったということは、より品質の高い価値となってユーザーに届くのではないでしょうか。

あとからリファクタリングするということは、綺麗に出来るコード、つまり綺麗じゃないコードに対して頑張って機能を追加したのだから、複雑度が増してしまっていて変更にも時間がかかるし、不具合が発生する確率が高まっていると思うのです。 そして多くのは場合は「あとでやる」と決めたことは実行されません。 つまりユーザーに対して価値を提供したつもりが、システムとしては価値の毀損を招いているとも言えるのではないでしょうか。

よって僕は機能を追加する前にボーイスカウト・ルールを発動するべきだと思うのです。