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