blog.waterlow.work

Ruby, Rails, js, etc...

プロジェクトの立ち上げ時に入れてよかった/入れなくてもよかったgem

f:id:waterlow2013:20181109010853j:plain

はじめに

ここ最近趣味でrailsアプリを複数人で開発しています。
自分以外Railsは初心者 で、rails newしてgemを入れてDB初期設計やってはじめのコントローラ(API)をつくるまで位を自分でやったのですが、その後入れてよかった/入れなくてもよかったと思うgemがあり、多少は他の人や未来の自分にも役立つだろうということで書き留めます。

入れてよかった

onkcop(rubocop)

コーディングスタイルについて揉めたり、議論したりすることがなかった。
自分が設定して満足できた。

bootstrap

本デザインが当たっていないサンプルの状態でも、まあまあいい感じに見せられる。素のHTMLを見ることによるテンションの落ちがない。

gimei

後述するseed-fuでのサンプルデータ作成に役立った。

ridgepole

migrationファイルの記法がほとんど使えるため学習コストが低かった。ちょこちょこスキーマを修正するのにいちいちmigrationを作らなくてよかった。(古いmigrationファイルを直せばいいというのもあるけど、ほんの少し罪悪感がある。)

seed-fu

サンプルデータをはじめに整備しておくことで、いろいろイメージが付きやすかったり、たたき台にできたり。

shrine

本番ではS3を使うのだが、developmentではローカルにファイルを置くとか実装を切り替えれたのが便利。初めてつかったけど carrierwave をちゃんと使ったことがあればある程度は動かせた。 他の人を見ていると学習コストは高めだった。

capistrano-*

よくわからんままとりあえずgit pullでデプロイとかしなくてよかった。快適

入れなくても良かった

active_model_serializers

これを使いこなすためには きれいなAPI設計 がおそらく必要なのだけど、それがネックだった。 APIが汚いとserializerも汚くなる。 controllerでの手動よびだしとかするといまいち。 jbuilderや、素のhashを返すpure rubyのクラスを作って自前でas_jsonをしていくほうが、コスト低くある程度の規約ができてよかったかもしれない。

devise

自分が知っていたので立ち上がりは早かった。ただ、自分が入れてjwtなどの設定もしたので、自分が全部面倒見る感じになってしまった。 管理画面には積極的に使えばいいとおもう。

rspec

実際は「テスト各時間を取れなかった」という感じになる。作るものもよくわからないし、教える時間が満足に取れない状況ではどうしてもテストは後回しになってしまった。

まとめ

すべて学習コストとリターンのバランスかなという感じがしました!