拾ったアイテムを容量制限のあるカバン内でやりくりしながら、ダンジョンの奥深くへと進んでいくゲーム『[Backpack Hero](https://store.steampowered.com/app/1970580/Backpack_Hero/)』。2022年8月にSteamでアーリーアクセスを開始したばかりの、比較的新しいインディーゲーム。

何となしに遊び始めてみたものの、大人気ゲーム『Slay the Spire』の後追いとしてここまで面白いものが出てくるとは思っていなかったので、良い意味で裏切られた。探索や戦闘の流れは継承しているものの、カバンのやりくりという戦略が奥深いゲーム性を生んでいる。

カバン内でのパズルを解くという意味で『Baba Is You』に似ている部分もあり、ローグライク要素によりこのパズルが動的に生成される状況が生まれている。容量制限のあるカバン内でテトリスを楽しむという意味では『Escape from Tarkov』にも通ずるものがあるだろう。

現時点で性質の異なる4種類のキャラを選んで遊べるが、それぞれ仕組みが大きく異なり、新鮮な体験ができる。裏を返すと、最初はこの仕組みの理解にそこそこ時間を費やすことになるので、手軽に楽しめるというよりは、学習の側面が大きいようなゲーム体験になる。またアップデートも活発で、10月はハロウィン要素がゲーム内に大きく取り入れられたし、11月中には5種類目となる新キャラが登場するらしい。

一方で悪いところを挙げると、日本語訳が微妙（らしい）。雰囲気をより味わうため、自分は普段この手の作品を英語で遊んでいるので困っていないが、他人に薦めるにあたって気になるところではある。良い作品だと思うので翻訳に貢献したいが、制作側にそういう期待や窓口があるのかどうかはよく分かっていない。また、UI周りでの不具合が幾らか目立つ印象だ。面白い作品なだけに、これはなかなか勿体ない点だ。

* * *

自分は2022年11月から遊び始めて、1日1プレイでとりあえずハードモード (1から5まである) を一通りクリアしてみたところ。せっかくなので、初回のネズミのキャラのクリア時のカバンの様子を紹介したい。

Standard
--------

![](https://lh3.googleusercontent.com/PxcT59Vb01MDEznTI0MdCuJuS16cYqllQN-DWma6OvTEJYsmNygT6r1IugdimwJZBwdnm88qCP4nnuM0u-6uiaaYi-2VqJJjJd5F625Y53Wn6A1eSDxwyM1Osr8eoYjuJcWrYus9Xw6FrHxz_AELbC0nbcpXn4uMS1UIyK4R6Y24SmhF3QF4x2B_fOrpTg)

初プレイ時のカバンの様子がこちら。武器の周りに宝石を配置していくのが良いらしいぞということで、宝石集めに邁進していたところ、道中で宝石の効果を強化するアイテムを拾って大成功。

Hard mode 1
-----------

![](https://lh3.googleusercontent.com/2AIMWeRQDE2sqXfpWB3x4Tbr5d_52OOmrzs1a77HF5WEmthlo7tjBx3oWSwlLcehyr_8T_rnaS8ysQJphrOBx6Vw9xw5cPr7rhUNlxrM8r7TIq6dYE1UljSgSt3Pwm6MJo13NatiDgnAxBlwuH4PWrhNTN6ODtuA6i6RAl52r-H77FdkB7e9S0JUL6LM2w)

宝石で強化するなら全体攻撃できる使用回数の多い武器に盛った方がお得じゃね？ということで、ハルバードを強化して振り回す形に。この武器拾いやすくて、ビルドの過程も線形的で安定するので良いんだよな。魔法の強みもこの周でなんとなく把握。

Hard mode 2
-----------

![](https://lh6.googleusercontent.com/zv2O5d3emrZK0xJcrg-bPvpVL33SfopEmtstCxB_q6JZZ5cpe6uF7TGTK6Y9JdvQ_hgQsN6d_yj9fYd93ONsqo8qezbga2nBvOAh6vPqKaFhNbXjyJVs-gyzTBazP5G3hT4NN2URKFbAppwLuPDhhZD8Br0Af9lVmjBS22jrc0AWEWlRQIMGgiYGs7bXzA)

初めて見たビルドを親だと思ってしまう習性があり、結局この回もハルバードを宝石で強化して振り回すことに。この作品は道中で徐々にカバンを拡張していくのだけど、配置条件が難しい代わりに利益も大きい貴重なアイテムが幾つもあるので、拾得時に対応できるよう受けの広さを意識して拡張していくことを考えるのが面白いところの一つだと思う。

Hard mode 3
-----------

![](https://lh5.googleusercontent.com/2kWVbN89-EB3ne_gXru884SpFf08hOcAbFLtjvJQSoXGSlZnLSRaohklFj-MRnuNg8dYnotW1tCK7_I_XuvlEn2yGIHUSqa424OeoQNJT_xj3WA3mLVvRiu0fSi_PujDR3brQeRVFFFKTL8IbcNDI7FsfoGXRyZyP2nyib5tnXJxknIyW5JLopgp163uZQ)

毎ターン威力が16上がる槍を序盤に手に入れたので、防御を固めていった回。防御系ビルドの主な弱点は、防御を貫通してくる毒や呪いといった攻撃と、立ち上がりの遅さ（1ターン目に敵の数を減らせないことからいきなり大量のダメージを受ける可能性がある）なので、これを解消すべく攻撃時に自動回復する仕組みや、1ターン目だけ多めに動ける仕組みを導入した。

Hard mode 4
-----------

![](https://lh3.googleusercontent.com/7hC0G-YgNjjL6HC6b6VNMfRS1FJgVlAOELyddIWCr5XlSamb248mVXi5EroGf76RIb8owGt2nPyCpGUhBkasmIAZhyjuMZ4hh46Cqsbypa03CrXPWcgNBO3wI2KHBcbRMrSkEj54L7HpBy9DHWQOI9FfylR7wUEIpTahgCjcfVgGBd20PH-ikTlgQd2UkQ)

防具無しビルド。攻撃時にHPを回復できるなど、防具を付けていないときだけ利用可能な強いアイテムが存在するので、試しにこれを採用してみた形。毎ターン全回復できるので、最大HP分ぐらいならダメージを許容できる。とはいえ難易度が高いゲームモードでは最大HPがより減らされることもあり、リスキーな部分はある……ので、ダメージを受けたときに効果を発揮するハロウィンイベントのコンパクトな盾を採用した。

Hard mode 5
-----------

![](https://lh6.googleusercontent.com/5G-xDrZBS66Yh3reJsjsThWcZaLgXalhRcxFPZ1diZUKnFjX_CITiKio2arSKnuYz_ksLUwcRifN0w36qd6xdULxN6xBVpNIax07S14iH5NgK76RuseA1LRN8re4pNkxgRAg_hEFOdZZbgxZw90AdBzxRgirGe46GruIP3wJdTEntSG3HLqh4NACnbEKGQ)

このキャラのハードモード最終回。相変わらずハルバードを強化して振り回している。このキャラは1キャラ目だけにバランス重視のビルドで上手くいきやすく、攻撃・防御・回復・金策と基本的なメカニクスを教えてくれる良いキャラだと思う。


拾ったアイテムを容量制限のあるカバン内でやりくりしながら、ダンジョンの奥深くへと進んでいくゲーム『Backpack Hero』。

2022-11-12-backpack-hero

<p>拾ったアイテムを容量制限のあるカバン内でやりくりしながら、ダンジョンの奥深くへと進んでいくゲーム『<a href="https://store.steampowered.com/app/1970580/Backpack_Hero/">Backpack Hero</a>』。2022年8月にSteamでアーリーアクセスを開始したばかりの、比較的新しいインディーゲーム。</p>
<p>何となしに遊び始めてみたものの、大人気ゲーム『Slay the Spire』の後追いとしてここまで面白いものが出てくるとは思っていなかったので、良い意味で裏切られた。探索や戦闘の流れは継承しているものの、カバンのやりくりという戦略が奥深いゲーム性を生んでいる。</p>
<p>カバン内でのパズルを解くという意味で『Baba Is You』に似ている部分もあり、ローグライク要素によりこのパズルが動的に生成される状況が生まれている。容量制限のあるカバン内でテトリスを楽しむという意味では『Escape from Tarkov』にも通ずるものがあるだろう。</p>
<p>現時点で性質の異なる4種類のキャラを選んで遊べるが、それぞれ仕組みが大きく異なり、新鮮な体験ができる。裏を返すと、最初はこの仕組みの理解にそこそこ時間を費やすことになるので、手軽に楽しめるというよりは、学習の側面が大きいようなゲーム体験になる。またアップデートも活発で、10月はハロウィン要素がゲーム内に大きく取り入れられたし、11月中には5種類目となる新キャラが登場するらしい。</p>
<p>一方で悪いところを挙げると、日本語訳が微妙（らしい）。雰囲気をより味わうため、自分は普段この手の作品を英語で遊んでいるので困っていないが、他人に薦めるにあたって気になるところではある。良い作品だと思うので翻訳に貢献したいが、制作側にそういう期待や窓口があるのかどうかはよく分かっていない。また、UI周りでの不具合が幾らか目立つ印象だ。面白い作品なだけに、これはなかなか勿体ない点だ。</p>
<hr>
<p>自分は2022年11月から遊び始めて、1日1プレイでとりあえずハードモード (1から5まである) を一通りクリアしてみたところ。せっかくなので、初回のネズミのキャラのクリア時のカバンの様子を紹介したい。</p>
<h2>Standard</h2>
<p><img src="https://lh3.googleusercontent.com/PxcT59Vb01MDEznTI0MdCuJuS16cYqllQN-DWma6OvTEJYsmNygT6r1IugdimwJZBwdnm88qCP4nnuM0u-6uiaaYi-2VqJJjJd5F625Y53Wn6A1eSDxwyM1Osr8eoYjuJcWrYus9Xw6FrHxz_AELbC0nbcpXn4uMS1UIyK4R6Y24SmhF3QF4x2B_fOrpTg" alt=""></p>
<p>初プレイ時のカバンの様子がこちら。武器の周りに宝石を配置していくのが良いらしいぞということで、宝石集めに邁進していたところ、道中で宝石の効果を強化するアイテムを拾って大成功。</p>
<h2>Hard mode 1</h2>
<p><img src="https://lh3.googleusercontent.com/2AIMWeRQDE2sqXfpWB3x4Tbr5d_52OOmrzs1a77HF5WEmthlo7tjBx3oWSwlLcehyr_8T_rnaS8ysQJphrOBx6Vw9xw5cPr7rhUNlxrM8r7TIq6dYE1UljSgSt3Pwm6MJo13NatiDgnAxBlwuH4PWrhNTN6ODtuA6i6RAl52r-H77FdkB7e9S0JUL6LM2w" alt=""></p>
<p>宝石で強化するなら全体攻撃できる使用回数の多い武器に盛った方がお得じゃね？ということで、ハルバードを強化して振り回す形に。この武器拾いやすくて、ビルドの過程も線形的で安定するので良いんだよな。魔法の強みもこの周でなんとなく把握。</p>
<h2>Hard mode 2</h2>
<p><img src="https://lh6.googleusercontent.com/zv2O5d3emrZK0xJcrg-bPvpVL33SfopEmtstCxB_q6JZZ5cpe6uF7TGTK6Y9JdvQ_hgQsN6d_yj9fYd93ONsqo8qezbga2nBvOAh6vPqKaFhNbXjyJVs-gyzTBazP5G3hT4NN2URKFbAppwLuPDhhZD8Br0Af9lVmjBS22jrc0AWEWlRQIMGgiYGs7bXzA" alt=""></p>
<p>初めて見たビルドを親だと思ってしまう習性があり、結局この回もハルバードを宝石で強化して振り回すことに。この作品は道中で徐々にカバンを拡張していくのだけど、配置条件が難しい代わりに利益も大きい貴重なアイテムが幾つもあるので、拾得時に対応できるよう受けの広さを意識して拡張していくことを考えるのが面白いところの一つだと思う。</p>
<h2>Hard mode 3</h2>
<p><img src="https://lh5.googleusercontent.com/2kWVbN89-EB3ne_gXru884SpFf08hOcAbFLtjvJQSoXGSlZnLSRaohklFj-MRnuNg8dYnotW1tCK7_I_XuvlEn2yGIHUSqa424OeoQNJT_xj3WA3mLVvRiu0fSi_PujDR3brQeRVFFFKTL8IbcNDI7FsfoGXRyZyP2nyib5tnXJxknIyW5JLopgp163uZQ" alt=""></p>
<p>毎ターン威力が16上がる槍を序盤に手に入れたので、防御を固めていった回。防御系ビルドの主な弱点は、防御を貫通してくる毒や呪いといった攻撃と、立ち上がりの遅さ（1ターン目に敵の数を減らせないことからいきなり大量のダメージを受ける可能性がある）なので、これを解消すべく攻撃時に自動回復する仕組みや、1ターン目だけ多めに動ける仕組みを導入した。</p>
<h2>Hard mode 4</h2>
<p><img src="https://lh3.googleusercontent.com/7hC0G-YgNjjL6HC6b6VNMfRS1FJgVlAOELyddIWCr5XlSamb248mVXi5EroGf76RIb8owGt2nPyCpGUhBkasmIAZhyjuMZ4hh46Cqsbypa03CrXPWcgNBO3wI2KHBcbRMrSkEj54L7HpBy9DHWQOI9FfylR7wUEIpTahgCjcfVgGBd20PH-ikTlgQd2UkQ" alt=""></p>
<p>防具無しビルド。攻撃時にHPを回復できるなど、防具を付けていないときだけ利用可能な強いアイテムが存在するので、試しにこれを採用してみた形。毎ターン全回復できるので、最大HP分ぐらいならダメージを許容できる。とはいえ難易度が高いゲームモードでは最大HPがより減らされることもあり、リスキーな部分はある……ので、ダメージを受けたときに効果を発揮するハロウィンイベントのコンパクトな盾を採用した。</p>
<h2>Hard mode 5</h2>
<p><img src="https://lh6.googleusercontent.com/5G-xDrZBS66Yh3reJsjsThWcZaLgXalhRcxFPZ1diZUKnFjX_CITiKio2arSKnuYz_ksLUwcRifN0w36qd6xdULxN6xBVpNIax07S14iH5NgK76RuseA1LRN8re4pNkxgRAg_hEFOdZZbgxZw90AdBzxRgirGe46GruIP3wJdTEntSG3HLqh4NACnbEKGQ" alt=""></p>
<p>このキャラのハードモード最終回。相変わらずハルバードを強化して振り回している。このキャラは1キャラ目だけにバランス重視のビルドで上手くいきやすく、攻撃・防御・回復・金策と基本的なメカニクスを教えてくれる良いキャラだと思う。</p>


『Backpack Hero』をやった

開発機をMacからWindowsに移行して2年ほど経った時点での振り返り。

年表
--

1.  2009年07月 MacBook Pro 1を購入、プログラミング開始
2.  2014年07月 MacBook Pro 2を購入
3.  2016年12月 Windows機1を入手、PCゲーム開始
4.  2017年07月 MacBook Pro 3を購入
5.  2018年06月 Windows機2を購入
6.  2020年09月 MacからWindowsへ開発機を移行
7.  2021年01月 Windows機3を購入
8.  2022年10月 現在

過去記事
----

開発機を移行してすぐの頃の感想は、次の記事に書いた。

*   [Windowsで開発](https://r7kamura.com/articles/2020-09-28-development-on-windows)
*   [Windowsへの回帰](https://r7kamura.com/articles/2020-10-04-windows-revolution)
*   [自作PC2021](https://r7kamura.com/articles/2021-01-08-pc-build-2021)
*   [デスクトップPCを譲渡](https://r7kamura.com/articles/2021-01-14-windows-transfer)

Macからの移行という観点だと、次の記事も幾らか関連があるかもしれない。

*   [AirPodsをWindowsで使う](https://r7kamura.com/articles/2020-12-24-airpods-windows)
*   [Windows10でMagic Trackpad 3](https://r7kamura.com/articles/2022-07-22-magic-trackpad-3-on-windows-10)

感想
--

この二年で特に後悔することも無く、自分の状況により適した方に移行できて良かったと感じている。自分の移行理由は、趣味嗜好の問題は少なく、環境の変化への対応という側面が大きかった。ここ数年で情勢や働き方が比較的大きく変わってきており、この変化により取りたい選択が変わったとも言える。

移行すべきか他人に聞かれることがあるものの、個々人の置かれている状況を理解する必要があるので、咄嗟に答えるのは難しい。とはいえ、自分もそこまで変わった状況にいる方ではないと思うし、自分と似た状況でかつ選択の自由があるという人は幾らかいるはずで、そういう人達に対しておすすめしていきたい選択肢ではある。

悪かった点
-----

*   開発環境が整備されていないことが多い。Macと比べてWSLだとファイルシステムの遅さの問題を受けにくく、Dockerを使いやすいが、MacBook Proを社用PCとして配る組織の開発環境だと、LinuxやDockerコンテナで開発することはほぼ考慮されておらず、自分で整地していく必要がある。変更自体は簡単だが、Docker環境の管理が所謂インフラと呼ばれるチームに一任されていたりすることが多く、開発環境向けの変更であってもアプリケーション開発者の権限のみでそれを通せなかったり、マイノリティ側からの変更要望なので優先度を低く見積もられがち
*   場合によって何かを諦めないといけない場合がある。Macの利用を前提としている社内環境や開発環境への要求を満たせなかったり、そもそも仕組み的に無理だったり。非開発者はWindowsを使っていることも多いので、これは主に開発環境周りで起こる。顕著な例だと、iOSやMac向けの開発はできないとか、組織内規定がMacを前提としているためにそこでは働けないとか
*   開発環境と非開発環境の部分が競合する場合がある。WSLで動かすLinuxを開発環境専用と割り切っているつもりでも、その基盤となる低レイヤーな部分で問題が起こりやすい。例えば、WSLを利用するためにはHyper-Vを有効化する必要があるが、これが『Escape from Tarkov』のアンチチートシステムに[誤検知される](https://r7kamura.com/articles/2021-03-08-escape-from-tarkov-hyper-v)。良く言えばこの作品でしか誤検知されたことはないのでマシかも
*   MacBook Proと比べると、Windows機は購入額に対する買取額が低い傾向にある。金銭的には、パーツ交換や増設のしやすさと対になっていそう

良かった点
-----

*   金銭効率が良い。同じ計算資源や周辺機器をゲームや動画編集や開発のすべてに充てられるため。大きなPCを隣に据えながら、薄くて小さいノートPCで開発するという非合理さが無い。人間側は基本的にシングルタスクで生活しており、ゲームをしながら開発作業をしたりすることがほぼ無いので、上手くいっている
*   パーツを後から変更しやすい。趣味や用途が変わってくるとどうしても不足する部分が出てくるが、自分の用途で足りない部分だけ簡単に補えるのは嬉しいし、自分で使うものを自分で変更できるというのも単純に楽しい
*   WindowsとMacを併用するのと比べ、コンテキストスイッチによるオーバーヘッドが少ない。人間側の認知負荷もそうだが、入出力デバイスをマシンによって使い分けたり、同じデバイスを共用するための苦労をしなくて済む
*   WSLやその周辺ツールが想定以上によく出来ている。もっと大量の問題を踏み抜くことだろうと思っていたが、そんなことも無かった。想定が誤っていたとも言える。特定のハードウェアに依存する開発から距離を取るなど、問題が起きづらい方向を好んで舵を取ったという側面もあるのかもしれない
*   Macだけを開発に使っているのと比べ、WindowsやLinuxへの理解をより深められる。良い点として、例えば本番環境がLinuxで動いている場合、よりそれに近い環境での知識を持っておくと役に立つことが多い。また利用者としてのWindowsに対する感覚も、ソフトウェア開発の文脈上で持っておくと助かることが多い
*   M1 Macへの移行時によく起こる問題に自分の環境が影響を受けない。とはいえ、自分の開発環境が影響を受けないにせよ、他の開発者の問題も解決できた方が良いので、個人的な深刻度が変わるだけで、結局組織や社会の構成員としてこの問題には取り組むことになる
*   Dockerをまともに利用でき、その辺りの利用や改善が捗る。MacのDockerが採用しているファイルシステムが遅くて現実的に使い物にならないという問題を避けられるため
*   どちらかと言うと世間一般の人とPCについての話が通じやすくなった。自分も含めて周囲のほとんどの人がMacを使っているような環境に身をおいていると、たまにPCやデバイスの話をするときにWindowsの利用者の事情を汲み取れないことがあったが、それらが幾らか軽減された


開発機をMacからWindowsに移行して2年ほど経った時点での振り返り。

2022-10-26-two-years-after-mac-to-windows

<p>開発機をMacからWindowsに移行して2年ほど経った時点での振り返り。</p>
<h2>年表</h2>
<ol>
<li>2009年07月 MacBook Pro 1を購入、プログラミング開始</li>
<li>2014年07月 MacBook Pro 2を購入</li>
<li>2016年12月 Windows機1を入手、PCゲーム開始</li>
<li>2017年07月 MacBook Pro 3を購入</li>
<li>2018年06月 Windows機2を購入</li>
<li>2020年09月 MacからWindowsへ開発機を移行</li>
<li>2021年01月 Windows機3を購入</li>
<li>2022年10月 現在</li>
</ol>
<h2>過去記事</h2>
<p>開発機を移行してすぐの頃の感想は、次の記事に書いた。</p>
<ul>
<li><a href="https://r7kamura.com/articles/2020-09-28-development-on-windows">Windowsで開発</a></li>
<li><a href="https://r7kamura.com/articles/2020-10-04-windows-revolution">Windowsへの回帰</a></li>
<li><a href="https://r7kamura.com/articles/2021-01-08-pc-build-2021">自作PC2021</a></li>
<li><a href="https://r7kamura.com/articles/2021-01-14-windows-transfer">デスクトップPCを譲渡</a></li>
</ul>
<p>Macからの移行という観点だと、次の記事も幾らか関連があるかもしれない。</p>
<ul>
<li><a href="https://r7kamura.com/articles/2020-12-24-airpods-windows">AirPodsをWindowsで使う</a></li>
<li><a href="https://r7kamura.com/articles/2022-07-22-magic-trackpad-3-on-windows-10">Windows10でMagic Trackpad 3</a></li>
</ul>
<h2>感想</h2>
<p>この二年で特に後悔することも無く、自分の状況により適した方に移行できて良かったと感じている。自分の移行理由は、趣味嗜好の問題は少なく、環境の変化への対応という側面が大きかった。ここ数年で情勢や働き方が比較的大きく変わってきており、この変化により取りたい選択が変わったとも言える。</p>
<p>移行すべきか他人に聞かれることがあるものの、個々人の置かれている状況を理解する必要があるので、咄嗟に答えるのは難しい。とはいえ、自分もそこまで変わった状況にいる方ではないと思うし、自分と似た状況でかつ選択の自由があるという人は幾らかいるはずで、そういう人達に対しておすすめしていきたい選択肢ではある。</p>
<h2>悪かった点</h2>
<ul>
<li>開発環境が整備されていないことが多い。Macと比べてWSLだとファイルシステムの遅さの問題を受けにくく、Dockerを使いやすいが、MacBook Proを社用PCとして配る組織の開発環境だと、LinuxやDockerコンテナで開発することはほぼ考慮されておらず、自分で整地していく必要がある。変更自体は簡単だが、Docker環境の管理が所謂インフラと呼ばれるチームに一任されていたりすることが多く、開発環境向けの変更であってもアプリケーション開発者の権限のみでそれを通せなかったり、マイノリティ側からの変更要望なので優先度を低く見積もられがち</li>
<li>場合によって何かを諦めないといけない場合がある。Macの利用を前提としている社内環境や開発環境への要求を満たせなかったり、そもそも仕組み的に無理だったり。非開発者はWindowsを使っていることも多いので、これは主に開発環境周りで起こる。顕著な例だと、iOSやMac向けの開発はできないとか、組織内規定がMacを前提としているためにそこでは働けないとか</li>
<li>開発環境と非開発環境の部分が競合する場合がある。WSLで動かすLinuxを開発環境専用と割り切っているつもりでも、その基盤となる低レイヤーな部分で問題が起こりやすい。例えば、WSLを利用するためにはHyper-Vを有効化する必要があるが、これが『Escape from Tarkov』のアンチチートシステムに<a href="https://r7kamura.com/articles/2021-03-08-escape-from-tarkov-hyper-v">誤検知される</a>。良く言えばこの作品でしか誤検知されたことはないのでマシかも</li>
<li>MacBook Proと比べると、Windows機は購入額に対する買取額が低い傾向にある。金銭的には、パーツ交換や増設のしやすさと対になっていそう</li>
</ul>
<h2>良かった点</h2>
<ul>
<li>金銭効率が良い。同じ計算資源や周辺機器をゲームや動画編集や開発のすべてに充てられるため。大きなPCを隣に据えながら、薄くて小さいノートPCで開発するという非合理さが無い。人間側は基本的にシングルタスクで生活しており、ゲームをしながら開発作業をしたりすることがほぼ無いので、上手くいっている</li>
<li>パーツを後から変更しやすい。趣味や用途が変わってくるとどうしても不足する部分が出てくるが、自分の用途で足りない部分だけ簡単に補えるのは嬉しいし、自分で使うものを自分で変更できるというのも単純に楽しい</li>
<li>WindowsとMacを併用するのと比べ、コンテキストスイッチによるオーバーヘッドが少ない。人間側の認知負荷もそうだが、入出力デバイスをマシンによって使い分けたり、同じデバイスを共用するための苦労をしなくて済む</li>
<li>WSLやその周辺ツールが想定以上によく出来ている。もっと大量の問題を踏み抜くことだろうと思っていたが、そんなことも無かった。想定が誤っていたとも言える。特定のハードウェアに依存する開発から距離を取るなど、問題が起きづらい方向を好んで舵を取ったという側面もあるのかもしれない</li>
<li>Macだけを開発に使っているのと比べ、WindowsやLinuxへの理解をより深められる。良い点として、例えば本番環境がLinuxで動いている場合、よりそれに近い環境での知識を持っておくと役に立つことが多い。また利用者としてのWindowsに対する感覚も、ソフトウェア開発の文脈上で持っておくと助かることが多い</li>
<li>M1 Macへの移行時によく起こる問題に自分の環境が影響を受けない。とはいえ、自分の開発環境が影響を受けないにせよ、他の開発者の問題も解決できた方が良いので、個人的な深刻度が変わるだけで、結局組織や社会の構成員としてこの問題には取り組むことになる</li>
<li>Dockerをまともに利用でき、その辺りの利用や改善が捗る。MacのDockerが採用しているファイルシステムが遅くて現実的に使い物にならないという問題を避けられるため</li>
<li>どちらかと言うと世間一般の人とPCについての話が通じやすくなった。自分も含めて周囲のほとんどの人がMacを使っているような環境に身をおいていると、たまにPCやデバイスの話をするときにWindowsの利用者の事情を汲み取れないことがあったが、それらが幾らか軽減された</li>
</ul>


MacからWindowsへの開発機移行から2年


[rubocop-migration](https://github.com/r7kamura/rubocop-migration)というGemをつくった。

ActiveRecordのmigrationでハマりがちな罠を回避したり、記法に一貫性を持たせるための、RuboCop向けのCopをまとめたライブラリである。例えば、テーブルへの読み書きをブロックしてしまうようなMigrationの書き方を検知し、それがもし別の方法で回避可能なものであれば違反とする、といったCopが含まれている。

背景としては、先週に[strong_migrations](https://github.com/ankane/strong_migrations)の話を見かけ、RuboCopから使える形で提供されていると便利そうだと思い用意した。実際、ほとんどのCopはこのライブラリの内容を参考に実装している。

異なる点として、strong_migrationsだと検知させるためにアプリケーションのコードに変更が必要で、またデータベースへの接続も要求される。一方で、rubocop-migrationはこの辺を要求しないという辺りが異なる。動的に情報を集められない分、対象のMigrationに関連するモデルファイルやdb/schema.rbがあればそれも静的解析して使っている。データベースに繋げないので、使うデータベースの種類は分かってもバージョンまでは分からないという問題があり、これには未だに困っている。例えば、MySQL 8.0以上では問題にならないコードを見つけたときなどに困る。「db/schema.rbにDBのバージョン情報も含めるのはどう？」とRails Discordチャンネルで尋ねてみたものの、特に取り合ってもらっていないので、これについてはまた別途Issueを立てて相談することにする。

rubocop-migration gemという名前について。元々5年前に同名のGemがあったのだけど、既に開発が停止されてリポジトリもアーカイブされていたので、[作者に連絡して名前を譲ってもらった](https://github.com/r7kamura/rubocop-migration/issues/1)。感謝。


rubocop-migrationというGemをつくった。

2022-10-20-rubocop-migration

<p><a href="https://github.com/r7kamura/rubocop-migration">rubocop-migration</a>というGemをつくった。</p>
<p>ActiveRecordのmigrationでハマりがちな罠を回避したり、記法に一貫性を持たせるための、RuboCop向けのCopをまとめたライブラリである。例えば、テーブルへの読み書きをブロックしてしまうようなMigrationの書き方を検知し、それがもし別の方法で回避可能なものであれば違反とする、といったCopが含まれている。</p>
<p>背景としては、先週に<a href="https://github.com/ankane/strong_migrations">strong_migrations</a>の話を見かけ、RuboCopから使える形で提供されていると便利そうだと思い用意した。実際、ほとんどのCopはこのライブラリの内容を参考に実装している。</p>
<p>異なる点として、strong_migrationsだと検知させるためにアプリケーションのコードに変更が必要で、またデータベースへの接続も要求される。一方で、rubocop-migrationはこの辺を要求しないという辺りが異なる。動的に情報を集められない分、対象のMigrationに関連するモデルファイルやdb/schema.rbがあればそれも静的解析して使っている。データベースに繋げないので、使うデータベースの種類は分かってもバージョンまでは分からないという問題があり、これには未だに困っている。例えば、MySQL 8.0以上では問題にならないコードを見つけたときなどに困る。「db/schema.rbにDBのバージョン情報も含めるのはどう？」とRails Discordチャンネルで尋ねてみたものの、特に取り合ってもらっていないので、これについてはまた別途Issueを立てて相談することにする。</p>
<p>rubocop-migration gemという名前について。元々5年前に同名のGemがあったのだけど、既に開発が停止されてリポジトリもアーカイブされていたので、<a href="https://github.com/r7kamura/rubocop-migration/issues/1">作者に連絡して名前を譲ってもらった</a>。感謝。</p>


rubocop-migration


RuboCopのカスタムCopを書いてリファクタリングを行う話として、丁度良い事例があったので紹介します。

## 改善したいコード

仕事先のRailsアプリを眺めてみると、昔から慣習的に次のようなコードが書かれていることが分かりました。

```ruby
module A
  extend ::ActiveSupport::Concern

  included do
    def foo
    end

    def bar
    end
  end
end
```

本来は、特別な理由が無い限り次のように書かれるべきコードです。

```ruby
module A
  def foo
  end

  def bar
  end
end
```

これは後から分かったことですが、このようなコードはファイル数で言うと数百件、メソッド定義数で言うと千件弱あるようでした。

## 用意したカスタムCop

そこで、RuboCopのカスタムCopを書いて、このコードを自動修正することにしました。詳しい書き方についてはここでは深入りしませんが、カスタムCopは、別にGem等にパッケージングしなくとも、適当なファイルを置いて読み込めば使えるし、適当に設定すればテストも書けるので、一般的に想像されるよりも気軽に書けるものです。

完成したものを、後になって雑Cop集である[Sevencop](https://github.com/r7kamura/sevencop)に追加して公開したものがこちらです。

- [sevencop/method_definition_in_included.rb at main · r7kamura/sevencop](https://github.com/r7kamura/sevencop/blob/b331e5f3afb1b27bb5f908f7e394674366e10fa0/lib/rubocop/cop/sevencop/method_definition_in_included.rb)

さて、このCopは冒頭のコードをおおよそ次のような形に変換します。

```ruby
module A
  extend ::ActiveSupport::Concern

  public def foo
  end

  public def bar
  end

  included do
  end
end
```

具体的な実装としては、`included` の中にメソッド定義を見つけるたびに、`included` の直前にそれを移動するようになっています。直前ではなく直後に入れる実装だと、上から処理していった場合、結果的に定義順序が逆順になってしまうので、直前を選んでいます。また、可視性が変わらないような配慮を手短に実現するために、インラインなスタイルで記載することで元々の可視性を維持するようにしました。

このCopによる自動修正だけでは、冒頭に紹介した理想的なコードと異なり、可視性に関する部分が残ってしまいますが、これは `Style/AccessModifierDeclarations` というCopで別途適切に自動修正されるので、最終的にはおおよそ理想的なコードになります。`Style/AccessModifierDeclarations` は最近まで自動修正に対応していませんでしたが、こういう用途等で便利に使えるかと思い、夏頃になんとなく対応しておいたのが功を奏しました。

- [Add autocorrect support to `Style/AccessModifierDeclarations` by r7kamura · Pull Request #10966 · rubocop/rubocop](https://github.com/rubocop/rubocop/pull/10966)

また、元々メソッド定義しか含まれていなかった `included` については、上のように変換後に空っぽのまま残ってしまいます。これは別途、空の `included` を削除するカスタムCopを適当に書いて消し込みました。

## 自動修正してはいけないパターン

さて、これで全てが万事解決したわけではありません。冒頭で説明した二つのコードは、`include` してみると明らかに挙動が異なります。

```ruby
module A
  extend ::ActiveSupport::Concern

  included do
    def foo
    end

    def bar
    end
  end
end

class B
  include A
end
```

上のコードの場合、`B#foo` と `B#bar` が定義されます。

```ruby
module A
  def foo
  end

  def bar
  end
end

class B
  include A
end
```

一方、上のコードの場合、`A#foo` と `A#bar` が定義されます。

そのため、クラス側にメソッドを定義されることを（書いた本人がそれを意図しているかどうかはさておき）利用しているパターンは自動修正せず、利用していないパターンだけを自動修正する必要があります。

この挙動の利用方法には、二つのパターンがあります。

## パターン1: クラスに定義されたメソッドを上書きするもの

```ruby
module A
  extend ::ActiveSupport::Concern

  included do
    def foo
    end
  end
end

class B
  def foo
  end

  include ::A
end
```

上のパターンは、既にクラスに定義されているメソッドを上書きする、という使い方です。クラス側に定義されているメソッドについても何らかの方法で動的に定義されている可能性があるので、これを静的検査で検知するのは難しいです。

## パターン2: 親モジュールのメソッドをOverrideするもの

```ruby
module A
  extend ::ActiveSupport::Concern

  included do
    def foo
    end
  end
end

module B
  def foo
  end
end

class C
  include ::A
  include ::B
end
```

上のパターンは、`C < B < A` という継承関係であるのに反して、先に `include` されているはずの `A` の `#foo` の定義が優先されて使われてしまう、というものです。`include` を内部的に呼び出す宣言的なメソッドや、モジュールの側で更に `include` されている場合など、複雑な実現方法もあるので、これも静的検査で検知するのは難しいです。

## 無視すべきパターンの検知方法

今回は、実際に実行してみて、つまり動的に検査することで、上記のようなパターンに一致するものが無いか調べることにしました。一致するメソッド定義全てに `# rubocop:disable Sevencop/MethodDefinitionInIncluded` というコメントを付けてCopを無効化すれば、安全に自動修正できるようになるはずです。

Railsでは、`Rails.application.eager_load!` を呼び出すと、モデルやコントローラーなどの定義が一通り読み込まれます。これを活用して、上述のパターンに一致するものがあればその箇所を報告してもらうことにしましょう。

## メソッド上書きの検知

1つ目の、既にクラスに定義されているメソッドを上書きするパターンについて。これは、`included` の中でいまからメソッドを定義する際に、自身にそのインスタンスメソッドが既に定義されていないかを調べれば判断できます。Rubyには `Module#method_added` という便利なフックがありますが、これはメソッドが定義**された後**に呼び出されるので、今回は使えません。そこで今回は、前述のカスタムCopを少し編集して、事前にコードを次のような形に変換してみることにしました。

```ruby
module A
  extend ::ActiveSupport::Concern

  included do
    method_will_be_defined_in_included(:foo)
    def foo
    end
  end
end
```

`method_will_be_defined_in_included` を適当に定義して、`Rails.application.eager_load!` を呼び出せば、このパターンに一致するメソッド定義を洗い出せます。

```ruby
class Module
  # @param method_name [Symbol]
  def method_will_be_defined_in_included(method_name)
    if method_defined?(method_name, false) || private_method_define?(method_name, false)
      # ここで報告したりする
      # (今回は `caller` を見て呼び出し元のソースコードにコメントを挿入する自己破壊的なコードにしました)
    end
  end
end

Rails.application.eager_load!
```

## 親モジュールに対するOverrideの検知

次に、`included` によって後に `include` されるモジュールよりも優先されるメソッドが定義されるパターンの検知方法について。これは、後に定義されるメソッドに影響を及ぼしているか検知したいので、そのメソッドが定義されたタイミングではまだ検知できません。そこで、すべての定義が終わった後で、結果的にそういう構造になったメソッド定義を探し出すことにしました。

```ruby
Rails.application.eager_load!

# この慣習で `included` が使われているのはアプリ内のモデルとコントローラーだけなので、
# これらのすべての子孫クラスから探索する
result = [
  ApplicationController,
  ApplicationRecord
].flat_map(&:descendants).flat_map do |klass|

  # 1. そのクラスから、`included` 内の `def` で定義されたメソッドを探索する
  methods_maybe_defined_in_included = klass.instance_methods(false).map do |method_name|
    klass.instance_method(method_name)
  end.select do |method|
    path = method.source_location[0]
    File.read(path).include?('included do')
  end

  # 2. そのクラスの継承ツリーから、モジュール上に定義されたメソッドを探索する
  methods_defined_in_module = klass.ancestors[1..].grep_v(Class).flat_map do |mod|
    mod.instance_methods(false).map do |method_name|
      mod.instance_method(method_name)
    end
  end

  # 1と2から得られた二つの集合を積算すると、ほしいメソッドの集合を得られる
  method_names = methods_maybe_defined_in_included.map(&:name) & methods_defined_in_module.map(&:name).uniq

  method_names.map do |method_name|
    "#{klass}##{method_name}"
  end
end

puts result.sort
```

上記のコードでこのパターンに一致するメソッド定義を洗い出せるので、同様に該当箇所に `# rubocop:disable ...` なコメントを挿入し、Copを無効化します。

## 結果

これでCopを無効化すべき箇所を無効化できたので、改めてRuboCopで自動修正すれば、リファクタリング完了です。実際には `+62,932 −62,469` という差分になりました。

## おわり

以上です。RuboCopのカスタムCopを書いてリファクタリングを行う話として、丁度良い事例があったので紹介しました。


RuboCopのカスタムCopを書いてリファクタリングを行う話として、丁度良い事例があったので紹介します。

2022-10-12-diary

<p>RuboCopのカスタムCopを書いてリファクタリングを行う話として、丁度良い事例があったので紹介します。</p>
<h2>改善したいコード</h2>
<p>仕事先のRailsアプリを眺めてみると、昔から慣習的に次のようなコードが書かれていることが分かりました。</p>
<pre><code>module A
  extend ::ActiveSupport::Concern

  included do
    def foo
    end

    def bar
    end
  end
end
</code></pre>
<p>本来は、特別な理由が無い限り次のように書かれるべきコードです。</p>
<pre><code>module A
  def foo
  end

  def bar
  end
end
</code></pre>
<p>これは後から分かったことですが、このようなコードはファイル数で言うと数百件、メソッド定義数で言うと千件弱あるようでした。</p>
<h2>用意したカスタムCop</h2>
<p>そこで、RuboCopのカスタムCopを書いて、このコードを自動修正することにしました。詳しい書き方についてはここでは深入りしませんが、カスタムCopは、別にGem等にパッケージングしなくとも、適当なファイルを置いて読み込めば使えるし、適当に設定すればテストも書けるので、一般的に想像されるよりも気軽に書けるものです。</p>
<p>完成したものを、後になって雑Cop集である<a href="https://github.com/r7kamura/sevencop">Sevencop</a>に追加して公開したものがこちらです。</p>
<ul>
<li><a href="https://github.com/r7kamura/sevencop/blob/b331e5f3afb1b27bb5f908f7e394674366e10fa0/lib/rubocop/cop/sevencop/method_definition_in_included.rb">sevencop/method_definition_in_included.rb at main · r7kamura/sevencop</a></li>
</ul>
<p>さて、このCopは冒頭のコードをおおよそ次のような形に変換します。</p>
<pre><code>module A
  extend ::ActiveSupport::Concern

  public def foo
  end

  public def bar
  end

  included do
  end
end
</code></pre>
<p>具体的な実装としては、<code>included</code> の中にメソッド定義を見つけるたびに、<code>included</code> の直前にそれを移動するようになっています。直前ではなく直後に入れる実装だと、上から処理していった場合、結果的に定義順序が逆順になってしまうので、直前を選んでいます。また、可視性が変わらないような配慮を手短に実現するために、インラインなスタイルで記載することで元々の可視性を維持するようにしました。</p>
<p>このCopによる自動修正だけでは、冒頭に紹介した理想的なコードと異なり、可視性に関する部分が残ってしまいますが、これは <code>Style/AccessModifierDeclarations</code> というCopで別途適切に自動修正されるので、最終的にはおおよそ理想的なコードになります。<code>Style/AccessModifierDeclarations</code> は最近まで自動修正に対応していませんでしたが、こういう用途等で便利に使えるかと思い、夏頃になんとなく対応しておいたのが功を奏しました。</p>
<ul>
<li><a href="https://github.com/rubocop/rubocop/pull/10966">Add autocorrect support to <code>Style/AccessModifierDeclarations</code> by r7kamura · Pull Request #10966 · rubocop/rubocop</a></li>
</ul>
<p>また、元々メソッド定義しか含まれていなかった <code>included</code> については、上のように変換後に空っぽのまま残ってしまいます。これは別途、空の <code>included</code> を削除するカスタムCopを適当に書いて消し込みました。</p>
<h2>自動修正してはいけないパターン</h2>
<p>さて、これで全てが万事解決したわけではありません。冒頭で説明した二つのコードは、<code>include</code> してみると明らかに挙動が異なります。</p>
<pre><code>module A
  extend ::ActiveSupport::Concern

  included do
    def foo
    end

    def bar
    end
  end
end

class B
  include A
end
</code></pre>
<p>上のコードの場合、<code>B#foo</code> と <code>B#bar</code> が定義されます。</p>
<pre><code>module A
  def foo
  end

  def bar
  end
end

class B
  include A
end
</code></pre>
<p>一方、上のコードの場合、<code>A#foo</code> と <code>A#bar</code> が定義されます。</p>
<p>そのため、クラス側にメソッドを定義されることを（書いた本人がそれを意図しているかどうかはさておき）利用しているパターンは自動修正せず、利用していないパターンだけを自動修正する必要があります。</p>
<p>この挙動の利用方法には、二つのパターンがあります。</p>
<h2>パターン1: クラスに定義されたメソッドを上書きするもの</h2>
<pre><code>module A
  extend ::ActiveSupport::Concern

  included do
    def foo
    end
  end
end

class B
  def foo
  end

  include ::A
end
</code></pre>
<p>上のパターンは、既にクラスに定義されているメソッドを上書きする、という使い方です。クラス側に定義されているメソッドについても何らかの方法で動的に定義されている可能性があるので、これを静的検査で検知するのは難しいです。</p>
<h2>パターン2: 親モジュールのメソッドをOverrideするもの</h2>
<pre><code>module A
  extend ::ActiveSupport::Concern

  included do
    def foo
    end
  end
end

module B
  def foo
  end
end

class C
  include ::A
  include ::B
end
</code></pre>
<p>上のパターンは、<code>C &#x3C; B &#x3C; A</code> という継承関係であるのに反して、先に <code>include</code> されているはずの <code>A</code> の <code>#foo</code> の定義が優先されて使われてしまう、というものです。<code>include</code> を内部的に呼び出す宣言的なメソッドや、モジュールの側で更に <code>include</code> されている場合など、複雑な実現方法もあるので、これも静的検査で検知するのは難しいです。</p>
<h2>無視すべきパターンの検知方法</h2>
<p>今回は、実際に実行してみて、つまり動的に検査することで、上記のようなパターンに一致するものが無いか調べることにしました。一致するメソッド定義全てに <code># rubocop:disable Sevencop/MethodDefinitionInIncluded</code> というコメントを付けてCopを無効化すれば、安全に自動修正できるようになるはずです。</p>
<p>Railsでは、<code>Rails.application.eager_load!</code> を呼び出すと、モデルやコントローラーなどの定義が一通り読み込まれます。これを活用して、上述のパターンに一致するものがあればその箇所を報告してもらうことにしましょう。</p>
<h2>メソッド上書きの検知</h2>
<p>1つ目の、既にクラスに定義されているメソッドを上書きするパターンについて。これは、<code>included</code> の中でいまからメソッドを定義する際に、自身にそのインスタンスメソッドが既に定義されていないかを調べれば判断できます。Rubyには <code>Module#method_added</code> という便利なフックがありますが、これはメソッドが定義<strong>された後</strong>に呼び出されるので、今回は使えません。そこで今回は、前述のカスタムCopを少し編集して、事前にコードを次のような形に変換してみることにしました。</p>
<pre><code>module A
  extend ::ActiveSupport::Concern

  included do
    method_will_be_defined_in_included(:foo)
    def foo
    end
  end
end
</code></pre>
<p><code>method_will_be_defined_in_included</code> を適当に定義して、<code>Rails.application.eager_load!</code> を呼び出せば、このパターンに一致するメソッド定義を洗い出せます。</p>
<pre><code>class Module
  # @param method_name [Symbol]
  def method_will_be_defined_in_included(method_name)
    if method_defined?(method_name, false) || private_method_define?(method_name, false)
      # ここで報告したりする
      # (今回は `caller` を見て呼び出し元のソースコードにコメントを挿入する自己破壊的なコードにしました)
    end
  end
end

Rails.application.eager_load!
</code></pre>
<h2>親モジュールに対するOverrideの検知</h2>
<p>次に、<code>included</code> によって後に <code>include</code> されるモジュールよりも優先されるメソッドが定義されるパターンの検知方法について。これは、後に定義されるメソッドに影響を及ぼしているか検知したいので、そのメソッドが定義されたタイミングではまだ検知できません。そこで、すべての定義が終わった後で、結果的にそういう構造になったメソッド定義を探し出すことにしました。</p>
<pre><code>Rails.application.eager_load!

# この慣習で `included` が使われているのはアプリ内のモデルとコントローラーだけなので、
# これらのすべての子孫クラスから探索する
result = [
  ApplicationController,
  ApplicationRecord
].flat_map(&#x26;:descendants).flat_map do |klass|

  # 1. そのクラスから、`included` 内の `def` で定義されたメソッドを探索する
  methods_maybe_defined_in_included = klass.instance_methods(false).map do |method_name|
    klass.instance_method(method_name)
  end.select do |method|
    path = method.source_location[0]
    File.read(path).include?('included do')
  end

  # 2. そのクラスの継承ツリーから、モジュール上に定義されたメソッドを探索する
  methods_defined_in_module = klass.ancestors[1..].grep_v(Class).flat_map do |mod|
    mod.instance_methods(false).map do |method_name|
      mod.instance_method(method_name)
    end
  end

  # 1と2から得られた二つの集合を積算すると、ほしいメソッドの集合を得られる
  method_names = methods_maybe_defined_in_included.map(&#x26;:name) &#x26; methods_defined_in_module.map(&#x26;:name).uniq

  method_names.map do |method_name|
    "#{klass}##{method_name}"
  end
end

puts result.sort
</code></pre>
<p>上記のコードでこのパターンに一致するメソッド定義を洗い出せるので、同様に該当箇所に <code># rubocop:disable ...</code> なコメントを挿入し、Copを無効化します。</p>
<h2>結果</h2>
<p>これでCopを無効化すべき箇所を無効化できたので、改めてRuboCopで自動修正すれば、リファクタリング完了です。実際には <code>+62,932 −62,469</code> という差分になりました。</p>
<h2>おわり</h2>
<p>以上です。RuboCopのカスタムCopを書いてリファクタリングを行う話として、丁度良い事例があったので紹介しました。</p>


カスタムCopでリファクタリング

毎日狂ったようにメモを書いている人が、メモについて語ってくれる本。人生訓や自己啓発的な語り口の内容が意外と多かった。

この辺の考え方は拾い上げておきたいと感じた。

*   情報の記録それ自体は機械にとって変わられるべき仕事だと考えるが、これとは別の観点として、メモを取れる程度に高い集中力で情報の入力に臨むことは有益だ

*   構造的にメモを取るように意識することで、情報を構造的に捉える必要性が発生するので、結果的に自身をそのような試みに導き、構造化能力や言語化能力を鍛えられる

*   自己分析ができている者は重宝されやすい。メモを取ることで自己分析を大いに進められ、自身の価値を高められると共に、自己実現にも繋がりやすい
*   強い願いを持つ者ほど大きな事を成しやすいが、人は生きていく中で願いを忘れてしまうので、書き留めておくことでそれを防ぎ、また何度も見返すことでそれを強められる
*   協力者が多いほど事を成しやすい。言語化能力が高いほど共感を集めやすく、協力者が集まりやすい
*   記憶に残らなかったものは重要ではなかったものだとする考え方は危うい。重要度の判定が情報を得た時点で済まされてしまうと、状況が変化しやすい社会で失敗しやすいためだ
*   具体的な課題を抱えている状態でないと、情報を得てもそれをどう転用できるかということに思い至れないため、常日頃からその手の課題を抱えておくべきだ

解くべき課題が無いと成長できないという構造は、大きさや形を変えながら、至る所に登場する。メモを書くことで能力が鍛えられるという話は、実益も兼ねた仮想的な課題を用意することで成長を促すような、矯正ギプスやエミュレーターを使った訓練に近いやり方のようにも感じられた。

例を挙げると、マクロな話では「いま困っているこの問題を解決できそうな話がこの勉強会で発表されるらしいぞ」と考えて参加するのか、「何か面白そうな話ないかな」と考えて参加するのかだと、経験的には結果に大いに差があるので、課題を引き出しに入れておくのも重要。ミクロな話では、自分に説明できるように解釈を試みながら話を聴くか、なんとなく聴いて面白かったねで済ますかだと、また違いが出てくるといった具合。

全ての物事に同じようにメモを取る姿勢を見せていくべきかと言われると、些か懐疑的ではある。一方、全ての物事に適用できないから何にも適用しないというのも、これもまた違うだろう。一般的に何が不足しがちかと言う傾きの話だとは思うが、書籍内ではこの辺の塩梅やバランスについては語られず、単純にメモ全推しの話で、その辺りには一種の危うさを感じた。

似た構造の話として、例えば[Learn In Public](https://www.swyx.io/learn-in-public/)に対する[How To Learn In Private](https://www.swyx.io/learn-in-private)という記事の中で、”Learn in Public” とは言ってみたものの、100%をPublicにしろという話ではないし、多くの人は0% Publicがデフォルトなのだから、それを数% Publicにするようなことを言っているだけなのだと語られている。また、目標を決めて取り組むと成果が得られやすいとは言うものの、あらゆる物事に目標を決めて目標駆動で取り組むべきと言っている訳ではないとも言っている。今回のメモの話も、これに近い構造をしていると思う。こういうものに対して、適用すべき条件やパターンを注意深く掘り下げながら読んでいけると、より面白く読める。できれば書籍側で構築してほしい話ではあるが。


毎日狂ったようにメモを書いている人が、メモについて語ってくれる本。

2022-10-11-the-magic-of-memos

<p>毎日狂ったようにメモを書いている人が、メモについて語ってくれる本。人生訓や自己啓発的な語り口の内容が意外と多かった。</p>
<p>この辺の考え方は拾い上げておきたいと感じた。</p>
<ul>
<li>
<p>情報の記録それ自体は機械にとって変わられるべき仕事だと考えるが、これとは別の観点として、メモを取れる程度に高い集中力で情報の入力に臨むことは有益だ</p>
</li>
<li>
<p>構造的にメモを取るように意識することで、情報を構造的に捉える必要性が発生するので、結果的に自身をそのような試みに導き、構造化能力や言語化能力を鍛えられる</p>
</li>
<li>
<p>自己分析ができている者は重宝されやすい。メモを取ることで自己分析を大いに進められ、自身の価値を高められると共に、自己実現にも繋がりやすい</p>
</li>
<li>
<p>強い願いを持つ者ほど大きな事を成しやすいが、人は生きていく中で願いを忘れてしまうので、書き留めておくことでそれを防ぎ、また何度も見返すことでそれを強められる</p>
</li>
<li>
<p>協力者が多いほど事を成しやすい。言語化能力が高いほど共感を集めやすく、協力者が集まりやすい</p>
</li>
<li>
<p>記憶に残らなかったものは重要ではなかったものだとする考え方は危うい。重要度の判定が情報を得た時点で済まされてしまうと、状況が変化しやすい社会で失敗しやすいためだ</p>
</li>
<li>
<p>具体的な課題を抱えている状態でないと、情報を得てもそれをどう転用できるかということに思い至れないため、常日頃からその手の課題を抱えておくべきだ</p>
</li>
</ul>
<p>解くべき課題が無いと成長できないという構造は、大きさや形を変えながら、至る所に登場する。メモを書くことで能力が鍛えられるという話は、実益も兼ねた仮想的な課題を用意することで成長を促すような、矯正ギプスやエミュレーターを使った訓練に近いやり方のようにも感じられた。</p>
<p>例を挙げると、マクロな話では「いま困っているこの問題を解決できそうな話がこの勉強会で発表されるらしいぞ」と考えて参加するのか、「何か面白そうな話ないかな」と考えて参加するのかだと、経験的には結果に大いに差があるので、課題を引き出しに入れておくのも重要。ミクロな話では、自分に説明できるように解釈を試みながら話を聴くか、なんとなく聴いて面白かったねで済ますかだと、また違いが出てくるといった具合。</p>
<p>全ての物事に同じようにメモを取る姿勢を見せていくべきかと言われると、些か懐疑的ではある。一方、全ての物事に適用できないから何にも適用しないというのも、これもまた違うだろう。一般的に何が不足しがちかと言う傾きの話だとは思うが、書籍内ではこの辺の塩梅やバランスについては語られず、単純にメモ全推しの話で、その辺りには一種の危うさを感じた。</p>
<p>似た構造の話として、例えば<a href="https://www.swyx.io/learn-in-public/">Learn In Public</a>に対する<a href="https://www.swyx.io/learn-in-private">How To Learn In Private</a>という記事の中で、”Learn in Public” とは言ってみたものの、100%をPublicにしろという話ではないし、多くの人は0% Publicがデフォルトなのだから、それを数% Publicにするようなことを言っているだけなのだと語られている。また、目標を決めて取り組むと成果が得られやすいとは言うものの、あらゆる物事に目標を決めて目標駆動で取り組むべきと言っている訳ではないとも言っている。今回のメモの話も、これに近い構造をしていると思う。こういうものに対して、適用すべき条件やパターンを注意深く掘り下げながら読んでいけると、より面白く読める。できれば書籍側で構築してほしい話ではあるが。</p>


『メモの魔法』を読んだ

ドメイン駆動設計は関数型言語でも上手くできるよ、という本。

ドメイン駆動設計や関数型言語に馴染みのない人にも理解できる程度に、初歩的なところから説明されている。例として取り上げるシステムも、お客さんから注文を受けたら商品の合計価格を計算して請求書とメールを送る、といった小さな規模のものになっており、大規模な業務システムが登場して気圧されることが無いのも良いところだと感じた。一方で、ドメイン駆動設計も関数型言語もある程度習熟しているから組み合わせ方だけ知りたいよ、という人にとっては読むべきところが少なく、物足りなく感じるかもしれない。

なぜ関数型言語でやるのかについては、次のような主張が感じられた。

1.  ドメインエキスパートが読めるようなプログラムを書くべきだ
2.  そのためには、入出力の形式やエラーの有無など、物事の依存関係がわかりやすく明示されるスタイルでプログラムを書くべきだ
3.  そして関数型プログラミングには、型などを使ってそれらを明示するための技法や考え方が多く備わっているから、この用途に適している

プログラミングパラダイムというのは、単にスタイルの問題だけではなく、何を重視するか・何を軽視するかという考え方の問題でもあるから、入出力や依存関係をより重視する傾向にある関数型プログラミングと相性が良いという主張には、たしかに理があるように感じられた。例えば自然言語の場合でも、日本語で考えるときと英語で考えるときとでは思考過程に大きな違いがあるから、関数型の考え方でモデリングすることでまた違った結果が得られるだろうということは、想像に難くない。

不正な状態を取り得たり、コードで説明できていない暗黙的な挙動を含んだりしないようにプログラムを組み上げることが本当に大事である、という考え方が本の中で徹底されており、これも著者の強く主張したい部分なのだろうと感じられた。この辺りは特定のプログラミングパラダイムに限定される話ではないので、明日から適用できそうな考え方な一方で、「とはいえうちで使ってる言語、Result型とか使う慣習無いんですが……」といった問題はままあり、現実で恩恵にあずかるためには更に考えていくべきことが幾つかあるように感じられた。

[Amazon.co.jp: Domain Modeling Made Functional](https://www.amazon.co.jp/dp/B07B44BPFB)


ドメイン駆動設計は関数型言語でも上手くできるよ、という本。

2022-10-09-domain-modeling-made-functional

<p>ドメイン駆動設計は関数型言語でも上手くできるよ、という本。</p>
<p>ドメイン駆動設計や関数型言語に馴染みのない人にも理解できる程度に、初歩的なところから説明されている。例として取り上げるシステムも、お客さんから注文を受けたら商品の合計価格を計算して請求書とメールを送る、といった小さな規模のものになっており、大規模な業務システムが登場して気圧されることが無いのも良いところだと感じた。一方で、ドメイン駆動設計も関数型言語もある程度習熟しているから組み合わせ方だけ知りたいよ、という人にとっては読むべきところが少なく、物足りなく感じるかもしれない。</p>
<p>なぜ関数型言語でやるのかについては、次のような主張が感じられた。</p>
<ol>
<li>ドメインエキスパートが読めるようなプログラムを書くべきだ</li>
<li>そのためには、入出力の形式やエラーの有無など、物事の依存関係がわかりやすく明示されるスタイルでプログラムを書くべきだ</li>
<li>そして関数型プログラミングには、型などを使ってそれらを明示するための技法や考え方が多く備わっているから、この用途に適している</li>
</ol>
<p>プログラミングパラダイムというのは、単にスタイルの問題だけではなく、何を重視するか・何を軽視するかという考え方の問題でもあるから、入出力や依存関係をより重視する傾向にある関数型プログラミングと相性が良いという主張には、たしかに理があるように感じられた。例えば自然言語の場合でも、日本語で考えるときと英語で考えるときとでは思考過程に大きな違いがあるから、関数型の考え方でモデリングすることでまた違った結果が得られるだろうということは、想像に難くない。</p>
<p>不正な状態を取り得たり、コードで説明できていない暗黙的な挙動を含んだりしないようにプログラムを組み上げることが本当に大事である、という考え方が本の中で徹底されており、これも著者の強く主張したい部分なのだろうと感じられた。この辺りは特定のプログラミングパラダイムに限定される話ではないので、明日から適用できそうな考え方な一方で、「とはいえうちで使ってる言語、Result型とか使う慣習無いんですが……」といった問題はままあり、現実で恩恵にあずかるためには更に考えていくべきことが幾つかあるように感じられた。</p>
<p><a href="https://www.amazon.co.jp/dp/B07B44BPFB?tag=r7kamuracom-22">Amazon.co.jp: Domain Modeling Made Functional</a></p>


『Domain Modeling Made Functional』を読んだ


カスタムCop集であるSevencopの最近の様子を、各Copの紹介という体裁で振り返る。

- <https://github.com/r7kamura/sevencop>

SevencopはOpinionatedなカスタムCopを集めたもので、実験的なCopを置いたり、公式には提案しにくいようなCopを置いたりしている。幾つかのCopについては、ここで公開して運用に耐えることを幾つかのアプリで試験してから、公式にPull Requestを出して取り込んだりもしている。

## Sevencop/AutoloadOrdered

`autoload` を定数名の辞書順に定義させるやつ。

```ruby
# bad
autoload :B, 'b'
autoload :A, 'a'

# good
autoload :A, 'a'
autoload :B, 'b'
```

`Bundler/OrderedGems` のように一応空行でセクションが分割されていた場合には、セクションごとに辞書順になっていればOKということにしているが、Gemfileと比べるとセクションが必要になる機会が乏しいので、この機能は無いほうが良いかもしれない。

このCopの他にも、このGemには辞書順系のCopが幾つか存在する。

## Sevencop/HashElementOrdered

Hashの要素をキーの辞書順に定義させるやつ。キーが単純なやつの場合のみ有効。ちなみにメソッド呼び出し時のキーワード引数もparser gem的にはHashとして扱われるので、これも対象になる。

```ruby
# bad
{
  b: 1,
  a: 1,
  c: 1
}

# good
{
  a: 1,
  b: 1,
  c: 1
}
```

RubyではHashの順序は保存されるし、値の評価順序も変わってくるが、その辺りの挙動に依存したコードを書きたいとは思わないので、自分は有効化することが多い。提案順序が安定するので、Copilotと若干相性が良い。

## Sevencop/MethodDefinitionArgumentsMultiline

メソッド定義時、引数が複数個存在する場合は1行あたり1引数にしようというやつ。

```ruby
# bad
def foo(a, b)
end

# good
def foo(
  a,
  b
)
end
```

エディタやdiff、例外情報の表示など、人間向けの各種ツールが行単位での操作を軸にしていることが多いので、それらとの相性を鑑みて行単位で記載する形式を好みがちである。

## Sevencop/MethodDefinitionKeywordArgumentOrdered

キーワード引数の定義時は辞書順にしようというやつ。

```ruby
# bad
def foo(b:, a:); end

# good
def foo(a:, b:); end
```

## Sevencop/MethodDefinitionOrdered

メソッドの定義時は辞書順にしようというやつ。

```ruby
# bad
def b; end
def a; end

# good
def a; end
def b; end
```

誰が書いても同じコードになるようにしようというか、機械が書いたときに書きやすいようにしようという考え方を優先しがちかもしれない。

## Sevencop/RailsBelongsToOptional

これは他とは違い、一時的に有効化してautocorrectで機械的にコードを変換するためだけに用意したCop。すべての `belongs_to` について未指定の場合に `optional: true` を付けて回る。

```ruby
# bad
belongs_to :group

# good
belongs_to :group, optional: true
```

古くから存在するRailsアプリの多くは、`belongs_to` のデフォルト設定を `optional: true` にしたままだと思うのだけど、これだと開発者が新たに `belongs_to` を追加するたびに手を抜かれてしまう危険性がある。そこで、既存の `belongs_to` のすべてをこのように変換した上でデフォルト設定を `optional: false` に切り替えよう、というのがこのCopの目的。

Rails関係のCopの名前には Rails- というPrefixを付けている。Cop名の辞書順に並ぶことが多いので、似たものが近い場所に配置されるようにしようという意図で、ある程度命名に気を遣っている。

## Sevencop/RailsInferredSpecType

付けなくていいtype metadataは付けないようにするやつ。

```ruby
# bad
# spec/models/user_spec.rb
RSpec.describe User, type: :model

# good
# spec/models/user_spec.rb
RSpec.describe User
```

付けなくていいtype metadataを付けないことで、付けないといけないtype metadataが目立つようにという目的。多分このrspec-railsのInferrenceの機能は将来廃止されそうなのだけど、その際の移行の労力を減らすためにも有用だと考えている。

次のPull Requestでrubocop-rspecに追加しようと提案している。

- <https://github.com/rubocop/rubocop-rspec/pull/1365>

## Sevencop/RailsOrderField

MySQLのfield関数をこういう感じで利用しているアプリにおいて、ActiveRecord 6頃から入ったSQL Injection対策のためにこのようなworkaroundを入れざるを得なくなったので、それを雑に検知・修正するために用意したCop。そんなに精度も良くないのであまり使うべきでもないかも。しかしこれが役に立つ現場は確かに存在していた。

```ruby
# bad
articles.order('field(id, ?)', a)

# good
articles.order(Arel.sql('field(id, ?)'), a)
```

ちなみに、順序を指定したい場合ActiveRecord 7からは `articles.in_order_of(...)` のように書くこともできるはず。

## Sevencop/RailsUniquenessValidatorExplicitCaseSensitivity

これも `Sevencop/RailsBelongsToOptional` と似ていて、一時的に有効化してautocorrectする目的でつくったCop。

```ruby
# bad
validates :name, uniqueness: true

# good
validates :name, uniqueness: { case_sensitive: true }
```

それまでUniquenessValidatorがMySQLのCollationを考慮する場合があったのが、しなくなるので、その挙動変更のために準備するためのもの。

## Sevencop/RailsWhereNot

これもRailsの互換性対策のCop。全体的にRails prefixが付いているやつは解毒剤みたいなやつが多いので、ふつうの人は見る価値が無いかも。

```ruby
# bad
where.not(key1: value1, key2: value2)

# good
where.not(key1: value1).where.not(key2: value2)
```

## Sevencop/RequireOrdered

`require` の順序を辞書順にするやつ。

```ruby
# bad
require 'b'
require 'a'

# good
require 'a'
require 'b'
```

eslint-plugin-importに似てるかもしれない。

同セクション内での並び順だけを確認するようにしている。逆コンウェイの法則じゃないけど、これによって `require` の順序に依存しない実装に変わることと、暗黙的な順序関係が存在する場合にセクションを分割するworkaroundによってそれが明示されるようになることを期待している。

## Sevencop/RSpecExamplesInSameGroup

controller-specとrequest-specは、単なる単体テストと違ってめちゃくちゃ長い時間が掛かるので、その手のテスト種別では効率化のために同一の事前条件を持つテストケースは統合しましょうというやつ。

```ruby
# bad
context 'when user is logged in' do
  it 'returns 200' do
    subject
    expect(response).to have_http_status(200)
  end

  it 'creates Foo' do
    expect { subject }.to change(Foo, :count).by(1)
  end
end

# good
context 'when user is logged in' do
  it 'creates Foo and returns 200' do
    expect { subject }.to change(Foo, :count).by(1)
    expect(response).to have_http_status(200)
  end
end
```


カスタムCop集であるSevencopの最近の様子を、各Copの紹介という体裁で振り返る。

2022-10-05-sevencop

<p>カスタムCop集であるSevencopの最近の様子を、各Copの紹介という体裁で振り返る。</p>
<ul>
<li><a href="https://github.com/r7kamura/sevencop">https://github.com/r7kamura/sevencop</a></li>
</ul>
<p>SevencopはOpinionatedなカスタムCopを集めたもので、実験的なCopを置いたり、公式には提案しにくいようなCopを置いたりしている。幾つかのCopについては、ここで公開して運用に耐えることを幾つかのアプリで試験してから、公式にPull Requestを出して取り込んだりもしている。</p>
<h2>Sevencop/AutoloadOrdered</h2>
<p><code>autoload</code> を定数名の辞書順に定義させるやつ。</p>
<pre><code># bad
autoload :B, 'b'
autoload :A, 'a'

# good
autoload :A, 'a'
autoload :B, 'b'
</code></pre>
<p><code>Bundler/OrderedGems</code> のように一応空行でセクションが分割されていた場合には、セクションごとに辞書順になっていればOKということにしているが、Gemfileと比べるとセクションが必要になる機会が乏しいので、この機能は無いほうが良いかもしれない。</p>
<p>このCopの他にも、このGemには辞書順系のCopが幾つか存在する。</p>
<h2>Sevencop/HashElementOrdered</h2>
<p>Hashの要素をキーの辞書順に定義させるやつ。キーが単純なやつの場合のみ有効。ちなみにメソッド呼び出し時のキーワード引数もparser gem的にはHashとして扱われるので、これも対象になる。</p>
<pre><code># bad
{
  b: 1,
  a: 1,
  c: 1
}

# good
{
  a: 1,
  b: 1,
  c: 1
}
</code></pre>
<p>RubyではHashの順序は保存されるし、値の評価順序も変わってくるが、その辺りの挙動に依存したコードを書きたいとは思わないので、自分は有効化することが多い。提案順序が安定するので、Copilotと若干相性が良い。</p>
<h2>Sevencop/MethodDefinitionArgumentsMultiline</h2>
<p>メソッド定義時、引数が複数個存在する場合は1行あたり1引数にしようというやつ。</p>
<pre><code># bad
def foo(a, b)
end

# good
def foo(
  a,
  b
)
end
</code></pre>
<p>エディタやdiff、例外情報の表示など、人間向けの各種ツールが行単位での操作を軸にしていることが多いので、それらとの相性を鑑みて行単位で記載する形式を好みがちである。</p>
<h2>Sevencop/MethodDefinitionKeywordArgumentOrdered</h2>
<p>キーワード引数の定義時は辞書順にしようというやつ。</p>
<pre><code># bad
def foo(b:, a:); end

# good
def foo(a:, b:); end
</code></pre>
<h2>Sevencop/MethodDefinitionOrdered</h2>
<p>メソッドの定義時は辞書順にしようというやつ。</p>
<pre><code># bad
def b; end
def a; end

# good
def a; end
def b; end
</code></pre>
<p>誰が書いても同じコードになるようにしようというか、機械が書いたときに書きやすいようにしようという考え方を優先しがちかもしれない。</p>
<h2>Sevencop/RailsBelongsToOptional</h2>
<p>これは他とは違い、一時的に有効化してautocorrectで機械的にコードを変換するためだけに用意したCop。すべての <code>belongs_to</code> について未指定の場合に <code>optional: true</code> を付けて回る。</p>
<pre><code># bad
belongs_to :group

# good
belongs_to :group, optional: true
</code></pre>
<p>古くから存在するRailsアプリの多くは、<code>belongs_to</code> のデフォルト設定を <code>optional: true</code> にしたままだと思うのだけど、これだと開発者が新たに <code>belongs_to</code> を追加するたびに手を抜かれてしまう危険性がある。そこで、既存の <code>belongs_to</code> のすべてをこのように変換した上でデフォルト設定を <code>optional: false</code> に切り替えよう、というのがこのCopの目的。</p>
<p>Rails関係のCopの名前には Rails- というPrefixを付けている。Cop名の辞書順に並ぶことが多いので、似たものが近い場所に配置されるようにしようという意図で、ある程度命名に気を遣っている。</p>
<h2>Sevencop/RailsInferredSpecType</h2>
<p>付けなくていいtype metadataは付けないようにするやつ。</p>
<pre><code># bad
# spec/models/user_spec.rb
RSpec.describe User, type: :model

# good
# spec/models/user_spec.rb
RSpec.describe User
</code></pre>
<p>付けなくていいtype metadataを付けないことで、付けないといけないtype metadataが目立つようにという目的。多分このrspec-railsのInferrenceの機能は将来廃止されそうなのだけど、その際の移行の労力を減らすためにも有用だと考えている。</p>
<p>次のPull Requestでrubocop-rspecに追加しようと提案している。</p>
<ul>
<li><a href="https://github.com/rubocop/rubocop-rspec/pull/1365">https://github.com/rubocop/rubocop-rspec/pull/1365</a></li>
</ul>
<h2>Sevencop/RailsOrderField</h2>
<p>MySQLのfield関数をこういう感じで利用しているアプリにおいて、ActiveRecord 6頃から入ったSQL Injection対策のためにこのようなworkaroundを入れざるを得なくなったので、それを雑に検知・修正するために用意したCop。そんなに精度も良くないのであまり使うべきでもないかも。しかしこれが役に立つ現場は確かに存在していた。</p>
<pre><code># bad
articles.order('field(id, ?)', a)

# good
articles.order(Arel.sql('field(id, ?)'), a)
</code></pre>
<p>ちなみに、順序を指定したい場合ActiveRecord 7からは <code>articles.in_order_of(...)</code> のように書くこともできるはず。</p>
<h2>Sevencop/RailsUniquenessValidatorExplicitCaseSensitivity</h2>
<p>これも <code>Sevencop/RailsBelongsToOptional</code> と似ていて、一時的に有効化してautocorrectする目的でつくったCop。</p>
<pre><code># bad
validates :name, uniqueness: true

# good
validates :name, uniqueness: { case_sensitive: true }
</code></pre>
<p>それまでUniquenessValidatorがMySQLのCollationを考慮する場合があったのが、しなくなるので、その挙動変更のために準備するためのもの。</p>
<h2>Sevencop/RailsWhereNot</h2>
<p>これもRailsの互換性対策のCop。全体的にRails prefixが付いているやつは解毒剤みたいなやつが多いので、ふつうの人は見る価値が無いかも。</p>
<pre><code># bad
where.not(key1: value1, key2: value2)

# good
where.not(key1: value1).where.not(key2: value2)
</code></pre>
<h2>Sevencop/RequireOrdered</h2>
<p><code>require</code> の順序を辞書順にするやつ。</p>
<pre><code># bad
require 'b'
require 'a'

# good
require 'a'
require 'b'
</code></pre>
<p>eslint-plugin-importに似てるかもしれない。</p>
<p>同セクション内での並び順だけを確認するようにしている。逆コンウェイの法則じゃないけど、これによって <code>require</code> の順序に依存しない実装に変わることと、暗黙的な順序関係が存在する場合にセクションを分割するworkaroundによってそれが明示されるようになることを期待している。</p>
<h2>Sevencop/RSpecExamplesInSameGroup</h2>
<p>controller-specとrequest-specは、単なる単体テストと違ってめちゃくちゃ長い時間が掛かるので、その手のテスト種別では効率化のために同一の事前条件を持つテストケースは統合しましょうというやつ。</p>
<pre><code># bad
context 'when user is logged in' do
  it 'returns 200' do
    subject
    expect(response).to have_http_status(200)
  end

  it 'creates Foo' do
    expect { subject }.to change(Foo, :count).by(1)
  end
end

# good
context 'when user is logged in' do
  it 'creates Foo and returns 200' do
    expect { subject }.to change(Foo, :count).by(1)
    expect(response).to have_http_status(200)
  end
end
</code></pre>
