wataメモ

日々のメモをつらつらと書くだけ

Ruby on Railsでサービスを作ってみたpart5

 今回で5回目の「Ruby on Railsでサービスを作ってみた」記事投稿。いつもの様に過去記事はこちらからどうぞ。(part1part2part3part4)画面や機能周りで終わりではなく、開発環境やらインフラ周りのメモも書いていくので引き続きよろしくお願いしたい。(挨拶)

開発環境について

 今回は開発環境について書いていく。開発環境と言ってもpart1とはスコープが違っていて、開発に使っている、エディタやらコマンドやらツールやらの事だ。

OSについて

 開発はすべてMacBook Proで行っている。とは言っても、OS Xに直接rubyやら何やらを入れているわけではなく、VirtualBoxで仮想環境をローカルに作ってその中で開発することを基本としている。これは色々なバージョンのrubyが入ってしまったりmysqlが一杯立ち上がったり、汚れるのを嫌ってのことだ。仮想環境にしておけば、最悪ハード障害になってもバックアップを取っていれば別のマシンでも同じ環境で開発をすることが出来る。2011年頃からこのスタイルで開発を続けている。仮想環境も使いまわしたりせず、案件ごとに作るようにしている。

エディタについて

 Rubyの開発はRubyMineと言いたいところだが、Atomを使って開発をしている。仮想環境内のファイルアクセスについてはsshfsを使ってOS X上にマウントしてアクセスしている。Windowsで開発していた時はSambaを使ってUNCパス経由でアクセスしていたが、OS Xからだと通信が切れたりと相性が良くないので乗り換えた。

コンソールについて

 他を試していないのだがiTerm2を使ってsshアクセスしている。たまにscreenを貼ったり、tmuxを貼ったりしてrack起動画面とgulp watchとgit操作とlogのtail等を分割してやったりもする。画面分割も便利だが、どちらかと言うと仮想環境に繋ぎ直した後に、何個もssh接続してプロセス立ち上げてというのが面倒だからという理由のほうが強い。
 OS X上でよく使うvagrantコマンドはvにaliasしていて、「v ssh」みたいにしている。

シェルについて

 zshバリバリですよ。というわけではなくbashを普通に使っている。git-completion.bashとかgit-prompt.shは必ず入れてgit操作をしている。やはりよく使うコマンドはaliasを切る。「bundle exec」は「be」とか。
 シェルの話ではないが、タスクランナーであるgulpを今回は使わなかった。やはりgulp等はフロントエンド界隈の技術なのかもしれない。Railsでは結果的に同じことを別の手法で解決していて、それがシームレスな開発に繋がっているのが素晴らしい。前も少し感じたことだが、サーバサイドエンジニアにはwatch文化が少ない気がする。もっとファイルの変更をwatchして、色々なことをしていけばコマンドを打たなくて済んだりして開発に集中出来ると思うのだが・・・。まあ、この辺りは自分が知らないだけの可能性があるので今後も調べてみようと思う。

gitについて

 SourceTree等のGUIツールは使わずコマンドベースで作業している。これはCVS(古い!)時代からSubversion等もコマンドラインで操作をしていた。この辺はあまりマウスは使いたく無く、「キーボードで操作を完結させたい!」という思いがあるからかもしれない。タッチパネルだと指が痛くなるのでマウスはMagic Mouseを使っている。
 GitHubを使ってソース管理をしているので素のgitではなくhubを入れてgitにaliasして使っている。いちいちPull Requestを出すためにブラウザを開くのが面倒だったので重宝している。が、仮想環境での操作のため「git browse」が使えない。なのでPull Requestをマージするためには手でブラウザを開いている・・・。(誰か良い解決案あれば教えて下さい。VirtualBoxの機能を使えば通知は出来そうだが・・・。)
 master Pull Requestの作成はgit-pr-releaseを使わせて頂いている。一人開発なのであまり意味は無いが、Pull Requestコメントに変更点がまとまるのはありがたい。

プロビジョニングについて

 Chefを使っていたが、itamaeを知ってからはitamaeで行っている。そんな複雑なことはいつもやらないので十分ということもある。今回はローカル環境とAWS環境はitamaeによってプロビジョニングを行った。反省点としてはローカルはCentOS6.6で、AWSはAmazonLinuxだったのを意識して無かったことか。awsコマンドとかは不要なのでその辺が分けられるようにしても良かったかと思った。プロビジョニングソースはこちらにあります。

CIツールについて

 前はTravis CIを使っていたが、今回の案件でCircle CIを使ったので引き続き使うことにした。単純にdevelopとmasterブランチを監視してmasterの場合はAWSにCodeDeployでデプロイする形になっている。おしゃれなUIはやっぱり必要だと思う。

デプロイツールについて

 capistranoは使わずCodeDeployを使った。せっかくなのでmamiyaも使ってみようかと思ったが今回は見送った。CodeDeployはec2インスタンス管理的な意味で言うと優れているが、実際のデプロイ周りが少し微妙な気がする・・・。まあLifecycleでhookすれば何でも出来るので問題は無いのだが、もっと痒いところに手が届く感じにしてもらいたいものだ。

次回について

 次回はいよいよインフラ周りの話について書いていく予定。1回で書ききれるのかはわからないが。