「Railsでモデルのステータスを扱うベタープラクティス」というLTしてきました

こちらでLTしてきました。資料は↓こちら↓

LTに至る経緯など書いていきたいと思います。

LTに至る経緯

非常に単純な理由です。ステータス管理で何度も困ってきたからです！

また、ブログで取り上げていたものがLTにちょうど良さそうだったためでもあります。

gemの紹介が大きく、その部分はコードベースで説明できるのでストレートにしました。結論から書いたのは伝わりやすさのためでもありますが、スライドの構成しやすさのためでもありました。

コードベースの具体例について、ステータス名を違和感ない英語でちゃんと書こうとし、ああでもないこうでもないと悩んだため時間がかかりました。LTの大筋には影響しなかったので、あんまり力を入れなくてもよかったかもしれません。

オリジナリティ0で、完全にAzusaですという見た目の資料になってしまいました。*1

また、具体的な問題点はサンプルコード部分がシンタックスハイライトされていないので見にくかったことです。Keynoteにシンタックスハイライトされたコードを貼る方法を探しておきたいです。

ステータスとか気軽に増やして、後で後悔と絶望するやつですね #omotesandorb
— 神速 (@sinsoku_listy) 2019年2月7日

みんなが踏み抜く地雷ですよね、私ももちろん踏みました(白目)

aasm昔の辛い記憶（詳細は忘れた）によって最近はstateful_enumしか触ってない #omotesandorb
— HolyGrail / 蜘蛛糸まな🕸️@新人VTuber (@HolyGrail) 2019年2月7日

aasmを入れて誰も分からなくなった話でもします？ #omotesandorb
— Toshio Maki (@Kirika_K2) 2019年2月7日

先人のようなので具体的に話を伺いたかったです。気付くのに遅れたのが残念です。

状態遷移図から起こしていれば、ここに安易に状態を足すのはやめようという話になるはずですねー…。
— Toshio Maki (@Kirika_K2) 2019年2月7日

可視化することで「複雑すぎるからどうにかしようぜ」というリファクタリング推進に役立つのはその通りですね。非エンジニア(例えばCS)にとってもステータスの多さはオペレーションの負担になりますし。

ゴリ押してるところあるなー。nullableなhoge_atたくさんあるのきつい。#omotesandorb
— 保立馨（Kaoru Hotate） (@purunkaoru) 2019年2月7日

全く正規化しなかったゴリ押しクラス図(クラス1つ)に対してのリアクションですね。仕様がシンプルなうちはさほど辛く無いし、納期に追われるととりあえずやってしまいますよね。

aasm gem 便利だな、transactions methodでaction条件の構築ができる #omotesandorb
— タピオカ 🥤 (@xga) 2019年2月7日

参考情報を補足してもらえたのも嬉しいですし、役に立てたようでとても嬉しい反響です。

LTしたところ懇親会でアドバイスいただけて、非常に学びが多くよかったです！
Sansanさん会場提供、飲食物、運営ありがとうございましたm(_ _)m#omotesandorb
— ﾅｶﾞﾓﾄ@Glideエンジニア (@ngmt83) 2019年2月7日

Sansanさんには感謝しかありません。

また、表参道.rbは本当にいいイベントだと再認識しました。つよつよエンジニアが何人もいるのに優しく暖かいリアクションとアドバイスをいただけるのは最高です。 ~~表参道というおしゃれの塊みたいな街は私には合いませんが~~

Railsでステータス管理したいなら https://t.co/uP5W7eFsU4 がシンプルで、コードも読める量でおすすめです #omotesandorb
— 神速 (@sinsoku_listy) 2019年2月7日

懇親会でさらに具体的なアドバイスをいただけましたので、このgemは早速試したいと思います。 github.com