この記事は、『研鑽Rubyプログラミング ― 実践的なコードのための原則とトレードオフ』 の感想記事です。レビューアーとして参加し、本書が広く読まれて欲しいので宣伝のために書きました。本記事は、"研鑽Rubyプログラミング β版 final"をもとに実施してます。なお、私自身はレビュアー参加のお礼として一冊本書をいただくことになっています。
私は2019年のRubyKaigiで、著者のJeremy EvansのKeynoteのレポート Jeremy Evansさん「たのしいRubyの先に、はやいRubyがある。Work, Correct, Fun! Fast」 〜RubyKaigi 2019 3日目 基調講演 を書いたことや、ある程度Ruby on Railsやデータベースに関するバックグラウンドがあったことから、その後翻訳者の角谷さんのレビューアー募集に応募して選ばれたというのがきっかけです。
下記、特に印象深い章について感想を書いています。なお、後半は反論になっていますがそれは本書の価値を損なうものではなく、議論を起こす価値のある本であるからであることを了承ください。
この章はライブラリ関連のgemメンテナーとして最も参考になる章でした。 私自身はActive Record Oracle enhanced adapterという3rd partyのデータベースアダプタのメンテナーなのですが、3rd party adapterの難しさの解決に役立ちそうな気がします。
この章ではPostgreSQLとSequelが推奨のデータベースとフレームワークになっており、それと対比するMySQLとActive Recordの弱点が記述されています。対比されているMySQLやActive Recordの若干以前の状態に基づいた比較をしているのではないかと感じる部分がいくつかありましたので、それらに対する意見表明です。なお、私自身はRuby on Railsのコミッターであるというbiasがあります。
- p317
MySQL でもうまくやっていくことは可能ですが、いつの間にかデータが消 失することがないように、細心の注意を払って MySQL を設定する必要があります。
この辺は以前のsql_modeの設定の話かと思いますが、MySQL 5.7以降のデフォルトのsql_modeを利用することで、これらの問題は回避されています。
- p320
考えなしに created_ at や updated_at といったカラムをすべてのテーブルに定義してはいけません。
Active Recordはデフォルトでは、これらのカラムを"考えなしに"全てのテーブルに定義します。私はこのやり方は好きです。
- p325
Active Record では、モデルのカラムごとに手動でバリデーションを定義して、データベース制約は使わないことが推奨されています。
Active Recordにもデータベース制約(Rails 7.0だとcheck制約、foreign key制約)はMigrationを通じて作成できますので、「使わないことが推奨」とまではいえないかと思います。これらのデータベース制約はsave!でデータベース側でエラーが出ればActive Recordの例外として補足も可能です。ただし、valid?ではこれらの例外は事前に検知できません。
β2以降からだけではありますが、レビューアーとして参加し、翻訳書がどのように作られているのかを見たり、いくつかの変更に自らが携わることができたのは貴重な経験でした。現著者の意図を損なうことなく、日本語版の読者向けに丁寧な翻訳がされていると思います。また、RubyKaigi 2023にはJeremyも角谷さんも参加されるようなので、読んだ感想などフィードバックされるといいのではないでしょうか。