銀座Rails#24 に参加

勉強会など

8月28日、オンライン開催された 銀座Rails#24@リンクアンドモチベーション に参加した。ツールはZOOMで、参加者は約80人。

出張Railsウォッチ in 銀座Rails

少し前にブログサービスで投稿者のIPアドレスが見える状態になっていた問題があった。そのとき、Rails でよく使われる認証 Gem である devise を使っているのではないかと話題になった（真偽は不明）。

devise を使うことが危険ということではなく、devise を使って危険な実装をすることができるという話。

devise が敬遠される理由は、デフォルト動作のカスタマイズがしづらかったり、devise wiki の情報が古かったりするところ。テーブル設計や実装がレガシー、User モデルが fat になりすぎるというのもある。

一方、メリットは、Webサービスにほぼ必須の「広義のログイン認証」機能を実装するという複雑で難易度が高いことを、サービス初期のエンジニアリソースが足りない時期に、一気に実現できるところ。

ただ、サービスの拡大フェーズに入って大きなカスタマイズや設計見直しが必要になったとき、辛くなる。

どうすればいいのか？

できるだけ User モデルを fat にさせない。devise の機能をすべて使わないといけないわけではない。（下記参考サイト）

認証に Rails を使わず外部サービスを使う手もある。

自前で全部実装するのはやめる。セキュアなコードを書くのはベテランにも難しい。

joker1007.hatenablog.com

感想

devise は使ったことがあるのでとても勉強になった。

devise の README に以下の文章があったのを思い出した。

If you are building your first Rails application, we recommend you do not use Devise. Devise requires a good understanding of the Rails Framework. In such cases, we advise you to start a simple authentication system from scratch.
GitHub - heartcombo/devise: Flexible authentication solution for Rails with Warden.

本番環境で認証をフル実装するようなことはしない方がいいとのことだったが、勉強のためには一度 devise を使わずに実装してみたいと思った。

Ruby にはたくさんの Gem があって便利だが、きちんと理解して使わないといけないということを再認識した。何か問題が起きても Gem のせいにすることはできない。

「Rails で Distributed Tracing をやっていく苦難について」と「railsでつくるなんちゃってserverless CMS〜コーポレートサイト編〜」は、自分の言葉で整理して書けるほど理解できなかったので割愛。m(__)m

Ruby on CI

なぜ CI をするのか？「働きたくないから」

人は間違えるが機械は間違えない。

何をCI（CD）するか？

  • test（RSpecなど）
  • lint（Rubocopなど）
  • deploy（Capistranoなど、ドキュメントも含む）

gem は、上記の deploy 以外。

CI 導入のタイミング

  • 継続的にメンテする必要性が出てきたとき
    • 基本的にはリポジトリ作成時
    • 使い捨てのコードであれば不要
  • 2〜3回手動でやってルーチン化したとき

CI 実行周期

Push や PR の単位。定期ビルド。

gem の場合、最低週1回は定期ビルドすべき。依存 gem の変更で master はすぐ壊れる。

何を使うべきか？

手作業を自動化することによって、生産性を何倍にもできる。

技術革新によってその時点の最適解がすぐに陳腐化する。

感想

最初に「まとめ」から入るやり方がよかった。その後、アジェンダ（項目）を示しながら進むのもわかりやすかった。

CI（継続的インテグレーション）はまだほぼやったことがないが、今後やることになるので、なんとなくイメージがつかめてよかった。

楽するためになんでも自動化したいタイプなので、早くやってみたい。