第1回を生視聴した増井さんのこれの第2回、第3回に関するメモです。
@masuidriveさんのスクーの授業が面白かったのでメモるよ - ぴよログ
先週配信された第2回は生視聴できませんでした。これも増井さん絡みでちょっときもい感じなんですが、IKEA家具でオフィスを作るって記事にインスパイアされてはるばる横浜のIKEAに買い物に行ったせいでへとへとで寝ていました。
そんで昨日が第3回目の放送でした。
- スクーの授業 ”増井雄一郎の「wri.pe」を事例に学ぶ、自作サービスの作り方〜開発編”
- スクーの授業 ”増井雄一郎の「wri.pe」を事例に学ぶ、自作サービスの広め方〜リリース編”
- リビングにIKEAで作る2畳の快適仕事環境 | @masuidrive blog
- 初心者が初めてIKEAに行ってきたけど難易度高かった - ぴよログ
- IKEA家具で作る格安コーナーデスク - ぴよログ
第2回 開発編
第2回は主にコーディングの話で、サーバーサイドとクライアントサイド両方の話でした。
サーバーサイド
rake stats
知らなかった!
RailsではAPIのみを提供
サーバーサイドではAPIのみを提供するというやり方にはちょうど興味を持っているところでした。これができると、クライアントとサーバーを完全にわけることができるし、ネイティブのモバイルアプリで同じAPIを使えばよくなるので色々便利そうだなと思っています。
認証にはDeviseを使わない
これは結構意外でしたね。大抵の連携はOmniauth
+Devise
でいけたりするので。。。
とはいえ対応が必要になったときに素早いのは自前ですね。簡単だということなのでちゃんと見ておこう。。。
Railsでログインとは別に複数のサービスとの連携を行う方法 - ぴよログ
クライアントサイド
Backbone.js
Backbone.jsの一部を使ってCoffeeScriptでViewを書いたそう。Backboneも前から気になっていた技術でストライクな内容です。前に作っていたRSSリーダーではCoffeeScriptでグローバルに書いていたのでかなりスパゲッティでした\(^o^)/
APIとViewがうまく切り分けられれば自然と綺麗になりそうなので、JSの構造化フレームワークは使ってみたいです。
HTML5
- Local Storage
- Session Storage
- Application Cache
このあたり知らなかった…!
開発編まとめ
open-wripe読もう。
第3回 リリース編
デプロイ編といったほうがいいのかもしれません。主にPaaSの話、自動テストの話でした。
Heroku
個人的にはHerokuにかかっている費用の内訳が興味深いです。スクーのスライドと増井さんのブログに載っています。
4/1のスクー 「wri.peの作り方」で拾いきれなかった質問 | @masuidrive blog
- Heroku Dyno x 2 = $34.50
- Heroku Worker x 1 = $36.00
- Heroku Postgres Olive = $50.00
- Adept Scale Skiff = $18.00
- Heroku SSL = $20.00
- Websolr Cobalt = $20.00
- Total = $178.50
Herokuは無料分しか使ったことがありませんでしたが、きちんとしたサービスを作るならそれなりにかかるなあという印象。Workerが結構高いですね。そもそも無料分じゃレスポンス的にも実用性は低いのですが。
全文検索のsolrも使えるみたいだしオートスケールも魅力。Herokuの運用しても余裕なプロダクトをやってみたいもんです。
Herokuのメリットの1つがMatzがいることらしいww
New Relic
これは僕も使ったことがあります。どの料金プランでどの機能が使えるのか忘れてしまいましたが、こんなことができるのでRailsアプリケーションならほぼ必須といってもいいのかもしれません。
(※1年前はAWSでホストするサービスはちょっといいプランが無料になった気がします)
- ページロードの内訳
- レスポンスタイムの内訳
- DBのレスポンス
- コントローラのレスポンスの内訳
などなど。
内訳っていうのがすごくて、メソッドごとの所要時間がわかったり、ブラウザのリクエストからレスポンスが戻ってきてDOM構築からレンダリングまでの内訳がわかったりします。遅いクエリを特定してくれたりもするのでパフォーマンスのボトルネックがすぐわかるようになっていますし、iPhoneアプリに通知を出してくれたりもします。
そして結構儲かっているらしい。
自動テスト
RSpec+Capybara+Selenium driverの自動テストをしているそう。
個人で作ったもののほうがテストが重要というのはなんとなく同意。仕事の場合はテストを書くことよりもお金になることのほうが優先度が高くなるはずだし、個人のサービスの場合は不具合のリスクや修正のコストをかけないためにテストが重要になるのかなと思いました。
質疑応答
せっかくなのでたくさん(3つ)質問したら時間内に全部答えてもらえました。
Q.アクセス負荷の話が少しありましたが、レスポンスタイムの計測などはしましたか?
A.New Relicでおk
今の10倍程度のアクセスならさばけるだろうという予測をしておられたのでその辺をどうやって見積もったのかを聞いてみたかったのですが、質問の仕方が難しかったです。
僕がやってたときはJMeterを使ってがっつり負荷をかけたときのスループットなんかを見ていましたが、そういったベンチマーク的なことはどうだったんでしょう?色々なプラクティス、ケースに興味があります。
あ、そうそう、Railsのデバッグ環境でプロファイルするならmini-profilerが結構いいです。NewRelicがやってくれるようなことを手元の環境で計測できます。
Q.テストではOSやブラウザ毎のテストも全て走るようにしているんでしょうか?
A.基本Mac、たまにWindows。モダンIE便利。
まあテストのたびにたくさんのOSや環境でテストするのはきついですよね〜。
Q.poltergeistなどサイレントなWebドライバーもありますが、そのあたりのものは実用性はどうでしょうか?
A.ちょっとテストするときはサイレント、デプロイ前は必ずSeleniumでブラウザを起動して動かす
PhantomJSと言ったほうが良かったのかも。
で、これは確かになぁと思いました。ブラウザ毎のちょっとした挙動も検証するならSeleinumを使ったほうが良さそうです。そもそもテストがきちんと動くかどうかを確認するようなときもあるので、そういうちょっとした場合はPhantomJSとかを使うんでしょう。
さっきの質問にも関連してるけど、デプロイ前にはがっちりテスト、普段はカジュアルにテストということなんですね。
リリース編まとめ
テストも含めてソース読もう。
第2回・第3回まとめ
ソース(ry