ちなみに

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

「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つのことというルールを出来るだけ守ろうと思って暮らしているのでどちらかというと過激派なのですが、プルリク単位くらいではやることを絞って欲しいとは思っています。

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

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

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

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

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

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

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

Gitのおすすめエイリアス5選

motemen.hatenablog.com

触発されて自分も地味だけどよく使っているのを紹介します。

変更を無視してpullする (git st-pull)

st-pull = "!git stash && git pull && git stash pop"

手元に変更があってまだコミット出来ないけど、最新の変更をpullして持ってきたいときに使う。 軽減される労力はめっちゃ小さいけど、積み重なるとそれなりに時間を使っているのでこういう手抜きは重要。

タグやリモートの一覧を表示する (git tags / git remotes)

tags = tag -l
remotes = remote -v

ちょっと一覧したいだけなのに微妙にやり方が違っていつも混乱するので複数形で一覧出来るようにしています。

今見ているブランチをGitHubで表示する (git open)

open = !gh browse -b $(git symbolic-ref --short HEAD)

僕は gh を使っています。

コンフリクトしたファイルの一覧を出す (git ls-conflict)

ls-conflict = !git ls-files -u | cut -f2 | uniq

複数のファイルがコンフリクトしたときにどれがコンフリクトしたかをサクッと一覧に出来る。 最近はVSCodeなんかが優秀なのでそこまで使わないですがたまに便利。

すべての変更を無にする (git bang)

bang = "!git clean -df && git reset --hard"

untracked なファイルも消すし、コミットしていない変更も消す。 適当に試してみてうまくいかなかったら消すということを良くやるので1日に何度も叩くやつ。 ときおり必要な変更を消し去ってしまって泣く。