Rails Follow-up Osaka に行って質問してきたお話 #Rails

Shinosaka.rb Advent Calendar 2016 の 6日目の記事です。

はじめに

先日、第一回目が開催された、Rails Follow-up Osakaに行ってきた感想などをまとめました。
（Rails Follow-up Osaka #1 - Rails Follow-up Osaka | Doorkeeper）

Rails Follow-up Osaka とは？

Shinosaka.rb のFounder むらじゅん(@murajun1978)さんが主催されている勉強会（姉妹版？）です。
Doorkeeperに記載されている説明はこんな感じ。

RailsでWEBアプリケーションを作成する際に必要な基礎知識や、
開発環境の構築、Rubyの学習など 参加者全員 でフォローします。
自分が知っている事で誰かが困っていたらフォローしてあげてくださいね。

初心者から上級者まで みんなで楽しく 腕前を上げていきましょう。

引用: Rails Follow-up Osaka #1 - Rails Follow-up Osaka | Doorkeeper

いつもわたしがお世話になっている Shinosaka.rb と同じく、むらじゅんさんらしい ゆる～い感じ の説明ですねｗ。

質問したことなど

さてここからが本題です。
せっかくFollow-upに参加するので、普段コード書いているときにこんなのみんなどうしてるのかな〜と思ったタイミングでメモしておいたものを持っていってみました。
ちなみに今回は、社内のエンジニアさんにも何かあれば書いておいて〜と連絡しておいて集まったものを持って行きました。

質問の箇条書き

具体的には以下のような質問を持っていきました。

簡易マスタのようなものはどのように扱っていますか？
アプリケーション全体で共有したいような処理はどこに記載していますか？
少し複雑な集計をしたい場合はどうしていますか？
ActiveAdminなどの簡易管理画面Gemを使用する基準などはありますか？
404のエラー画面を出す処理はどのように実装されていますか？
SQLの実行時間はどのくらい以上だと「遅い」と判断されていますか？

ん〜。複数人が聞きたいと思ったときのメモなので、見事にバラバラですねｗ。

こんな雑多な質問を投げかけさせていただいたのですが。みなさんでわいわい楽しい感じで回答いただけました！

質問と回答

1. 簡易マスタのようなものはどのように扱っていますか？

例えば性別のようなカラムを扱うときに、Rails側ではどうやって管理している？
DBにはどのような値を入れている？

回答

DBには文字を入れる方がよいのでは？
- 0, 1 などを入れるよりも male/female の方が後でデータを確認するときにわかりやすい
- 残念ながらDBに直接ログインして、Selectすることもあるよね。。そのときにいちいち逆引きしないで済むのでは？
Rails側では enum を使用する
- enumを使用して、DBに文字列を入れることもできる

結論

enumを使ってDBに文字列を入れるのがベターかな？

2. アプリケーション全体で共有したいような処理はどこに記載していますか？

どこに書けばいいのか？？？
少し調べた感じだと lib の下にアプリケーション名で module を作成するようなアプリケーションがいくつかあったが、どうなのだろう。。？

回答

まずは、全体共有ではなくMVCのどこかによせるべきではないか検討した方がよいのでは？
app の直下に専用のディレクトリを作ってもよいのでは？
- Decorator のようなイメージ
lib よりも別の場所の方がよいのでは？
- Rake Task を記述したりするのでバッチ感がある
- lib の下は require しないといけなくなる
- lib の下だとテストが辛くなる
今後 Gem として切り出せそうな場合は lib の下に配置してもよいのでは？
- libの下に Gem のフォルダ構成で作成することもある

結論

いろいろな意見をだしていただきました！場面によって選択が異なるのではないかなと思います
今回はまず、全体共有ではなくMVCのどこかによせるべきではないか検討 することから実施していくことにしました

蛇足

ついでに全体で共有する値という意味で、定数を扱う場合は？ と聞いてみたところ、binarylogic/settingslogic のようなGemを使おう。という意見が多数でした。
ちょっとしらべたところ最近は railsconfig/config というのも良さげなようです。

参考: Railsで定数を一元管理する(config) – hello-world.jp.net

ちなみに railsconfig/config に関しては、こちら ↓ にもいい感じの使用例が記載されていますのでぜひ！

5日目: Railsで railsconfig/config とダックタイピングを使って簡易的にDIコンテナ化する - Qiita

3. 少し複雑な集計をしたい場合はどうしていますか？

ざっくり以下のような場面で、どのような実装をしているか？
例: 商品の在庫数、販売数、入荷数を表示したいが３種類の集約を表示しないといけない
1. 在庫数は在庫テーブルの集約を表示
2. 販売数は販売テーブルの集約を表示
3. 入荷数は入荷テーブルの集約を表示
なお自分たちが考えていた回答例
- Active Record で頑張る？
- 素のSQLを実行する？
- ３回SQLを発行して、Rails側で頑張る？
ちなみに、項目は違えどどこの現場でも実際にありそうな感じかな～と思います

回答

取得を複数回に分けるのは、Rails側がつらそうなのであまりやりたくないなと言う意見が多数
開発の初期段階などでまだまだメンテナンスが頻発しそうな場合は、 Active Record で頑張った方が後々助かったと思えるのでは？
逆にある程度成熟していて、メンテナンスがそれほど発生しないと判断できれば、SQL直書きでもよいのでは？
集計用のView、Table、DBを使うという手法でもよいのでは？
- 集計系の場合は特に、即時性が求められることは少ないと思われるので、専用のデータ・セットを用意してあげてもよいかもしれない

結論

こちらもいろいろな意見を聞くことができました。
SQL直書きって禁じ手なイメージがありましたがｗ、なぜ避けるべきかを考えれば必要な場面では使用するのもよいなと考えさせられました
ちなみに、今回はメンテナンスが発生しにくいと判断できたのでSQL直書きで対応しようと思います

4. ActiveAdminなどの簡易管理画面Gemを使用する基準などはありますか？

ActiveAdminは初動は早いがクライアントに合せてカスタマイズすると後々工数がかかってくるイメージ
どのような基準で使用するかを決めておられますか？

回答

ActiveAdminは基本使わないという意見が多数
クライアントの要望を熟慮して、コストがかなり削減ができそうなどのメリットがあれば導入してもよいのでは？
データを見たいだけならば、画面をサクッと作ってしまう方が簡単なのでは？

結論

基本的にActiveAdminのようなGemは使わないという意見が多数派だったのが印象的です
今回は複雑なカスタマイズをすることが想定されないため、ActiveAdminを使用しました
次回以降対応するときは、改めて導入が必要かしっかり検討したいと思いました

5. 404のエラー画面を出す処理はどのように実装されていますか？

参考ページのようなやり方で実装したが、もっといいやり方などがあれば教えて欲しい
- 参考: Railsで404エラーメッセージを出すために - Qiita

回答

参考サイトの内容は基本どおりなのでいい感じだと思う
- 注意: rescue_from は後勝ちなので、記述順に気をつけること！
Gemで対応してもよいと思う
- yuki24/rambulance
- kami-zh/rexception
エラートラッキングとかのサービスもあるよ！

結論

発展して、いろいろなGemやサービスをみなさんから教えていただいて大変勉強になりました
気をつけるポイントが聞けたのも勉強になりました
まずは基本形で、もっといろいろやりたいと思ったときにここでいただいた内容を参考にさせていただきたいと思います

6. SQLの実行時間はどのくらい以上だと「遅い」と判断されていますか？

もちろん、サービスや場面によって様々だと思いますが。。
例えばレスポンス改善を求められた時にどのくらいの時間以上のSQLがあれば改善しようとするか？？という感覚値などがあればお聞きしたい

回答

SQLだけではなく画面のレスポンスでみるかな？
あるサービスでは、本番のRender込みで300ms以内が標準で、500msを超えると誰かが怒り出すｗというお話を聞けました
- このサービスの場合は少なくともSQLで500msというのはありえないということになりますね

結論

当然ですが。レスポンス改善などを求められた場合は、お客さんと話し合いRender込みの適正なレスポンス時間を決めることから始めたいと思います
また少なくとも500ms以上かかっているSQLは注意したいなと思いました

まとめ

初心者、上級者関係なくみんなで楽しくフォローアップしてもらえる会で、すごく楽しかったです。
みなさんがそれぞれ意見をお持ちで、いろいろな意見が聞けて大変参考になりました。
回答されていた方も「勉強になるな〜」と言われていたのが印象的でした。

事前に質問を準備していったのも良かったなと思いました。
せっかくですので、ご参加の際は聞きたいことを事前にメモなどしておいて参加されることをおすすめいたします！

勉強会の話とか

気軽に質問できる雰囲気でしたので、大阪近辺でRailsでお困りの方（Rails以外でもOK）は、ぜひご参加いただければと思います。
ちなみに、第２回目はこちらになります。が。。もう、キャンセル待ちになっているようですね。。

Rails Follow-up Osaka #2 - Rails Follow-up Osaka | Doorkeeper

定期的に開催されると思いますので、今後の開催もぜひチェックしてみてください。
Doorkeeperで「コミュニティに参加」をしておくと通知が届いてよいかもしれません。

ちなみに、神戸方面の方には朗報！こちらも開催されております！
Rails Follow-up Kobe | Doorkeeper

本家？ Shinosaka.rb

ちなみに、本家？（この Advent Calendar のコミュニティ）はこちらになります。
Shinosaka.rb | Doorkeeper

わきあいあいとして、楽しい会ですので初めてや初心者の方でも参加しやすいのではないかなと思います。
（懇親会が本番と呼ばれている飲みか。。いや、勉強会です。）

もちろんこちらの勉強会でも、みなさんでフォローアップしてもらえると思いますのでぜひ。
ちなみに、最近はオンラインでの開催も開始されましたので、遠方のかたもお気軽にご参加いただけるのではないかと思います。

関西の勉強会楽しみましょう〜。

現場からは以上です。