こんにちは、hachi8833です。BPS社内勉強会でmorimorihogeさんが発表した「月刊Railsウォッチサマリー」の2018/12版を元にお送りします。
反応がよければ月刊として定着させたいと思いますので、皆さまからのフィードバックやご要望を@morimorihogeまたは@hachi8833までぜひお寄せください🙇。
- スライド発表、コメント: morimorihoge
- 構成、本文文責: hachi8833
⚓週刊Railsウォッチ（20181203）
週刊Railsウォッチ（20181203）Railsのglobalidとは、AWS LambdaがRubyに対応、JSはPromiseを最初に学べほか
この回は「公開つっつき会」の日でした。
⚓主な話題
- Rails本体
- その他
⚓ES2015とJavaScriptの今後
勉強会では、上述のCoffeeScript -> ES2015リライトに関連して、morimorihogeさんによるES2015やJavaScriptの今後の見通しについて以下が示されました。少なくとも「将来CoffeeScriptやSprocketに戻ることはないだろう」という見解です。
- CoffeeScript
- 今後新規案件で新しく書くことはないと思う方がよさそう
- jQuery
- 「とりあえずjQueryを入れる」はやめる方がよさそう
・急ぎの案件や、技術的負債を見越した案件、ライブラリの関係でjQueryを使わざるを得ない場合はこの限りではない - TypeScript
- 現時点ではES2015を生で書くことの方が多いように思える
- Webpacker
- 今が移行の苦しい時期
・もう少しこなれてくれば使えるようになるかも
・Webpacker本家のバージョンに完全追従していないなどはかなりつらい
・Webpackerがつらいなら生Webpackにする手も
非Railsメインな方も読んでいるかもしれないので念のため補足しておくと、WebpackerはRailsでwebpackを簡単に扱えるライブラリです。
ぼちぼちリリースの迫るRails 6からはWebpackerが
rails new時のアセット管理のデフォルトツールになる予定なので、世のRailsエンジニアは追いかけておく必要があります。
一方、Webpackerにはかなりハマりどころも多く、本家webpack側のバージョンアップに追随するのが少し遅かったり、ちゃんと使おうとすると結局ある程度しっかりとしたwebpackの知識も必要になってくるということから、webpackを簡単に使うためにWebpackerを導入したのに結局勉強するものが増えてしまったという悲しい気持ちになることもあります。
また、昨今ではフロントエンドエンジニアとバックエンドエンジニアが分業するスタイルが一般化してきましたが、フロントエンジニアにとってはWebpackをいつも通り使いたいだけなのに、なんでWebpacker使わないといけないんや！Rubyわからん！！というhateを生み出す要因になってしまうところもあると思います。
というわけで、フロントとバックエンドを開発するメンバーなりチームが明確に分かれていて、かつフロントエンジニアがRailsにそれほど慣れていない場合には素のwebpackの方がチーム間は仲良くできるのではないかなあ、と思っていたりします。お互い適切な距離感が大事。
＃今気づきましたがwebpackは全部小文字、Webpackerは頭大文字なんですね
webpackは全部小文字、Webpackerは頭大文字
気が付きませんでした💦。
⚓週刊Railsウォッチ（20181210）
週刊Railsウォッチ（20181210）update_columnは要注意、DBカラムコメントは書こう、個人情報扱いの注意点、Capistranoはやっぱりいいほか
⚓主な話題
- Ruby 2.6リリース直前の話題
- Rails
⚓ActiveRecordの更新系メソッド
ActiveRecordの更新系メソッドには注意を要するものがあるという話題になりました。ここでいう更新系メソッドは、#saveや#updateや#update_attributesなどです。
- ActiveRecordの更新系メソッドの中には、コールバックを呼ばない（validationをスキップする）ものがある
#update_column#update_all#update- etc.
- validationがスキップされると、DBの論理整合性がたちまち失われてしまう
- RDBMS側でCONSTRAINTによる制約をかける方法もあるが、ビジネスロジックに関連する制約や複雑な制約はどうしてもアプリケーションのコードに置かれるので、すべてをCONSTRAINTでまかなうのは難しい
- validationを誤ってスキップしないよう、すべてのRailsエンジニアは更新系のメソッドを適切に選ぶ必要がある
生SQLを書いていた時代からWebアプリケーション開発をしていた人たちはこのあたりそれほど問題にならないと思います（というかそこまでORM（Object-Relational Mapper。RailsだとActiveRecordに相当）を信頼してない）が、ORMを使ってしか開発したことがないような人が踏みがちなやつです。
RDBMSから見ると整合性があるけど、アプリケーションから見ると不整合なデータというのはRailsだと割と作りがちで、かつ発生してしまった場合の障害も割合危険なものになることが多い（アプリケーションエラーになってしまうケースが多い）ため、コードレビューの際には注意してチェックしたいところです。
⚓DBテーブルのカラムコメント
データベーステーブルのカラムを作成するときには、適切なカラムコメントを日本語で追加しておくと自分やチームを助けるという話題です。morimorihogeさんによる勉強会での説明の要点を以下にまとめました。
中規模〜大規模なシステムでテーブル数やカラム数が増えてくると、英語のカラム名を見ただけでは日本語名をすぐに想像できなくなることがよくあります。XXX_atやXXX_keyのような類似の英語カラム名が増えてくると、確認の手間も増えてしまいます。
また、Excel形式のスキーマ仕様書も納品する場合、データベースのスキーマ更新のたびに仕様書を手動で更新するのはまったく非効率です。
幸い、一般的なRDBMSではスキーマ定義時にカラムにコメントを追加する機能があります。これを活用すれば、開発中にカラムの日本語説明を簡単に参照できて開発の効率が向上しますし、A5:SQL Mk-2などの整形ツールを援用してスキーマ仕様書を自動生成することもできます。
現在のRailsでは、スキーマにカラムコメントを書いておけばデータベースに反映されるようになっています（Rails 4以前ではgemが必要でした）。
SIerアレルギーの過激な人なんかは「Excel仕様書なんていらない。schema.rbのソース見ろ」みたいなことをいう人もたまにいるのですが、アプリケーションコードが何の言語で書かれていようが気にしないけどDBの中身がどうなっているかは外部連携やビジネスロジックの検討上知りたいというケースは多々あります。
また、初期はRailsアプリのコードが読める身内メンバーだけで開発していたが、システムの運用拡大に伴い「DB仕様書見せて」というケースは比較的多いので、いざという時にチョロく生成できるための先行投資としては悪くないと思います。
⚓Railsでのセキュアデータの扱い
- ウォッチ: Railsでデリケートな情報を扱うには
ウォッチで紹介した記事「Securing Sensitive Data in Rails」はRailsを中心に、Webアプリでセキュアなデータを扱うときの注意点を運用も含めてひととおり紹介しています。以下はこのトピックに関するmorimorihogeさんの説明のまとめです。
- Railsに限らず、セキュアなデータの扱いについて求められる水準は上がっている
- 特に開発経験の浅い人は、こうした記事に一度は目を通しておいて欲しい
- データがRailsやライブラリの機能レベルで漏洩する可能性もあるため、重要なデータの扱いについて仕様書に記載があるかどうかにかかわらず、Railsのどの機能でどういう漏洩が発生しうるかを実装サイドで理解しておく必要がある
- 重要なデータがサーバーログに含まれていた、など
⚓Capistranoの話題
- ウォッチ: Capistranoは今も優れもの
BPS社内の標準デプロイツールであるCapistranoは今も便利なツールであるという話題でした。Capistranoは既に空気のように当たり前に使われているので、その分最近Capistranoに関する新しい話題を見かけなくなっているという指摘になるほどと思いました。
勉強会では、その他にCapistranoによるデプロイをインフラエンジニアとアプリエンジニアのどちらが設定すべきかという話題にも触れました。以下はmorimorihogeさんの説明のまとめです。
- Capistranoのデプロイ設定は、どちらかというとアプリエンジニアの仕事だと考える
- アプリケーションの細かい設定は、インフラエンジニアだけではできないものであり、インフラエンジニアの作業範囲を超えると考える
- インフラエンジニアは文字通りインフラを準備することが業務
- スムーズな連携作業のためにも、アプリエンジニアはCapistranoのデプロイ設定を書けるようになって欲しい
インフラエンジニアとアプリエンジニアの責任分界点は割と会社やプロジェクトチームによっても異なるケースを見かけますので、この辺りは唯一の正解があるわけではないと思います。
弊社ではインフラエンジニアよりもアプリエンジニアの方が数が多いこともあり、なるべくアプリエンジニア側でできることはやってもらう運用にしています。
⚓週刊Railsウォッチ（20181217）
週刊Railsウォッチ（20181217）Railsのafter_*系フックは要注意、早すぎるDRYとYAGNI、mruby 2.0リリースほか
⚓主な話題
⚓Rails Developers Meetup 2018 Day 4
- ウォッチ: Railsdm 2018 DAY 4にて
「Rails Developers Meetup」（Railsdm）というカンファレンスの特徴などについてmorimorihogeさんが解説しました。
- Railsを中心に据えていて、業務に直接役立つ発表が多い
- RubyKaigiほどマニアックではない
- Railsのベテラン開発者、経験の浅い開発者のどちらにもおすすめできる
- 発表内容がバラエティに富んでいて、技術寄りでない発表もあり
私（hachi8833）も、RailsdmはRailsの開発者にとって参加する価値が高いと思いました。実際、今年の3/22に予定されている最初のRailsdm 2019は発売したその日にチケットが完売していました。
⚓週刊Railsウォッチ（20181225）
週刊Railsウォッチ（20181225）Rails 6新機能第2弾「Action Mailbox」、url_forは慣れが要る、Ruby製サーバーレスフレームワークJetsほか
⚓主な話題
⚓URLHelperによるurl_for名前解決
- ウォッチ:
url_forは慣れが要る
Railsつっつき会と本勉強会の両方で、しきりに「#url_forは闇が深い」という話が出ました。以下はつっつきと勉強会でのmorimorihogeさんの説明をまとめたものです。
- RailsのURLHelperのメソッドである
#url_forはルーティング形式の引数をURLに変換するためのもので、*_pathや*_url、link_to、form_forなどのビューヘルパーの内部で多用されている#url_forは単に奥が深いというより、後方互換性などによって闇が深くなっている面がある
#url_forは実に多種多様なパターンで引数を受け取れる#url_forの挙動を理解しようとしても、少々実装を追いかけたぐらいでは理解できない#url_forを使いこなせるようになると引数を簡潔に書けるようになる
勉強会では、#url_forの多種多様な引数の渡し方とどう取り組むかについてmorimorihogeさんから次のような話もありました。
- 引数の渡し方は、参加するRailsプロジェクトによって異なることが多い
- （新しく実装するなら1つの書き方だけ覚えていれば済む）
- さまざまなプロジェクトに参加するには、引数の渡し方のパターンをある程度網羅的に知っておく必要がある
- そのためにも、さまざまな引数の渡し方を少しずつでも学んで慣れておくとよい
url_forの書き方は少なくとも同一プロジェクトの中ではある程度統一した方が良いと思います。書き方がばらばらだと単に読みにくいというのもありますが、ソースコード検索でも見落としが出やすくなってしまうため、Routingの見直し時に更新漏れが発生してエラー原因になったりする危険性もあります。
この辺りは既に走っているプロジェクトであれば、既存ソースを見ながら郷に従うのが正義だと思います。
Railsウォッチを毎週やっている中では、時によっては半分以上がマニアックな話題に終始してしまうことがあり、普段のWeb開発業務に直接役立つ知識を追いかけている人にとってはノイズに思えてしまう部分も多いと思います（ノイズの中にも面白いネタが転がっているので意図的にやってるのですが）。
「面白さ」を追求する週刊Railsウォッチに対して「実用性」を追求した月刊サマリーとでもご理解下さい😉。
※なお、ピックアップしているトピックや内容の重要度については多分に僕個人の価値観が含まれるため、業務でのご利用の際は皆様一次ソースをご確認の上自己責任でご利用下さい。