スタートアップが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の記事投稿でした。