スタートアップがRailsでこれだけはやっておくべきTips

はじめに

先日、「スタートアップRails勉強会」というものに参加し、
10名弱のRailsエンジニアの方達がLTをされたので、メモとしてまとめときます。

技術的負債を減らしやることに集中すべし

スタートアップはスピード感が大事！！ということで、
負債に時間をかけてられません。そこで、
Railsのアップグレードは頻繁に行うべし！
じゃないと、後から大変なことになるみたいですね・・・
あとは、
- コードは少なく書け！不要なコードはガンガン消す！
- アップグレードすべきものは、その都度slackに流れてくるようにして、アップグレードするべし。
LT参考資料：
http://qiita.com/kmszk/items/ad687e772da454e3f614

Docker-composeを導入せよ

動く環境をコマンド一つで構築、できるとか、なんとか
Dockerは知ってるけどDocker-composeは知らなかった。
IncrementsのQiita Teamの方がLTで推奨していました。

modelのvalidationは最初から入れる

これは、最初にやっておかないと、後で相当やばいことになるらしいです。
私、してたっけ・・・後でチェックします。
特にuniquenessは設定しておくべし、とのこと。

お手軽にエラーを見える化する

Bgusnagを使うべし。
Bugsnagとは、エラーを全部記録してくれて、webで見れるそうです。
確かうちでも、導入していますが、前のエンジニアにしかメールが届かないので教えてもらわないと・・。
簡単にGithubのissueや、slackの通知と連携することができるそうです！
これは可視化もできて、なかなかよさそう。

サーバが落ちたときの復旧に対応できるような体制

まず、「サーバが落ちたときはslackなどに通知がくるようにして、すぐに対応できる体制にしましょう」、とのこと。
サーバが落ちたときの対応も知識として入れておかねば・・(私まだわかりません。ごめんなさい)
また、負荷がかかってサーバが落ちるのを防ぐための準備も必要。
過負荷テストをしたり、オートスケーリングの設定をしておく、など！
AWSだとオートスケーリング設定できるけど、VPSだとどうなんだろう・・
これも後で調べてみよう。

Re-dashなどの計測ツールを使って各種KPIの計測、slackに流す

最近は、KPIを自動で計測・可視化してくれるサービスが多いようですね。
先日は、TechCrunch(だったかな)でRedashが取り上げられていたので、Redashを使って毎日slackに通知させている企業さんが多いのかな。
他にもtableauとか、いろいろあるみたいです。
毎日KPIがグラフになってslackに流れてきたら、モチベも上がるかもしれませんね。
私もためしてみよう。

PRD, RFCを書く

PRD(Product Requirements Document)

PRDとは、「製品への要求が書かれた文書」のこと。
製品の目指すゴール、要求される技術などを詳しく書くもののようです。
(実装方法については書かない。)
具体的になにを書くかは、下のURL(参考資料)から見れます。

RFC(Request for Comments)

RFCとは、「新機能や機能改善のための提案書」のこと。
PRDよりもミクロ。本当に必要なのか？を議論することができる。
軽く書いて、共有するもの。いけそうだったら実装に入る。

参考
http://qiita.com/takashi/items/39adc590ddb48e5765a6)

最後に

私もスタートアップにいるし、このイベントはRailsだけに特化していてとてもよかった。
いろいろ聞けたので、試してみようと思います！
また試したものの中でいいのがあったら、Qiitaにメモしよう。
ということで、初めてのQiitaの記事投稿でした。