webアプリのプラットフォーム作った。
app2
http://www.app2.io
2、3か月前から作っていたwebサービスが完成した。
app2という名前でwebサービスの管理ができるサービス。
簡単にこのwebサービスの説明する。(また詳しい記事を出す予定)
app2でできること
- webアプリの管理
- 検索
- お気に入り(ホーム画面に追加)
- ユーザー通知(現在はRSSのみ)
- レビュー
iosでいうapp storeを作りたかった。コンテンツベースのwebサイトなら検索流入からアクセスが期待できるが、webサービスとなるとなかなかアクセスを集めることが難しい。なのでストアのようなものがあればアクセスも増えるのではないかと思って作った。
そしてユーザーにリピートしてアクセスしてもらうためにユーザーがwebアプリを管理できるようにし(具体的にはホーム画面にwebアプリを配置することができる)、そのwebアプリからの通知も受け取れるようにした。
例えばあるブログをホーム画面に加えるとそのブログから更新の通知が届くようになる。最終的には各ユーザーに向けて個別にメッセージを送ることができるようにし、FacebookやTwitterの通知やブログの更新を一気にチェックできるようにしていきたい。
もちろん無料なので、webアプリ開発者の方は是非登録してみて欲しい。
[追記]
サーバー落ちた
Railsのテスト関連。インストール方法まとめ 便利なgemあり
[!注意!]最新版はこちらに書いています。
はじめ
RailsでテストをしようとするとRSpec系を使うのが主流だと思うので、そのインストール方法をまとめます。
基本的には、RSpec+Capybara+factory_girlを使います。
最後の方に便利なgemを書いてます。
使う
まずはgemfileに追加。
group :development, :test do #test gem 'rspec-rails', '~> 3.0' gem 'capybara' gem 'factory_girl_rails' gem 'database_cleaner' gem 'guard-rspec' #以下便利gem。使う場合はコメント外す。 #gem 'guard-livereload' #gem 'launchy' #save_and_open_page methodが使える。 #gem 'growl' #テスト通知。growlをインストールしてあれば使える。 end
追加してbundle install。
rspec-rails
$ bin/rails generate rspec:install
でspecフォルダと中身を作ります。
これでrspecは使えるようになります。
テストを作る時、ファイル名を*_spec.rbとすることを忘れないようにします。
capybara
spec/rails_helper.rbに以下を追加。
require 'capybara/rails'
作成するテストファイルは上同様ファイル名を*_spec.rbにし、先頭に以下を付け加える。
require 'rails_helper'
factory_girl_rails
factory_girlはテストで使用する生成するデータを簡単に管理できます。
spec/rails_helper.rbに以下を追加します。
RSpec.configure do |config| config.include FactoryGirl::Syntax::Methods end
作成するデータをspec/factories/*.rbに配置すれば自動的に読み込んでくれるのでfactoriesフォルダを作りその中に配置したほうがいいでしょう。
詳しい使い方は以下を見てください。
File: GETTING_STARTED — Documentation for factory_girl (4.5.0)
database_cleaner
database_cleanerはテスト後に作成されたデータを削除するためdatabase_cleanerをインストールします。
spec/rails_helper.rbに以下を追加します。
#db_cleaner config.before(:suite) do DatabaseCleaner.strategy = :transaction DatabaseCleaner.clean_with(:truncation) end config.before(:each) do DatabaseCleaner.start end config.after(:each) do DatabaseCleaner.clean end
これで自動的に、データベースがクリーンに維持されるようになります。
guard-rspec
guardを使えば、ファイルが変更されたのを感知して自動でテスト実行できます。
$ guard init rspec
で使えるようになります。
使い方は、
$ bin/bundle exec guard
で使えます。
その他便利なgem
guard-livereload
github.com
viewを変更すると、自動的にブラウザを更新できる。すごく便利。
$ guard init livereload
でインストール完了。
ブラウザ側には
How do I install and use the browser extensions?
から拡張機能をインストールしてきて、localhost:3000のページ上で拡張してブラウザに追加されたボタンを押せばシンクロされる。
まとめ
guard-livereloadなんかは最近知って、すごく便利だなと思いました。
ブラウザとシンクロさせるやり方は他にもたくさんありいろいろ試してみましたが、この方法が1番シンプルで使いやすいと思います。
速度対決!AWS、heroku、puma、webrick、 usリージョン、euリージョン
AWSを触っていたら、今まで気にかけていなかったwebサーバーの問題にぶち当たりpumaやwebrickなど意味不明な単語が出現し、今までいろいろ調べていた。herokuの公式ページを見ると、rails標準のwebサーバーwebrickの使用を避けpumaの使用を奨めていた。今までそんなことを気に掛けていなかったため普通に本番環境でもwebrickを使用していたが、調べてみるとそのような使い方は論外らしい。なので、webrickからpumaにしたらどれだけ速度が向上するのか適当に計測していることにする。
そしてherokuはUSリージョンとeuリージョンでしか使用できないため、それ相応の遅延が発生する。はたしてその遅延はどれほどなのかAWSの東京リージョンと比較してみる。
heroku × webrick
ローカルでRailsアプリを作り、そのままHerokuにアップロードするとこの環境になる。Railsアプリは静的なページと、scaffoldで作成したページの簡単なデザイン。
以下が作成したwebアプリ。
Heroku and weblick
これでも結構速い。
トップページのリロードでだいたい2.2秒くらい。
ターボリンクで移動するとブラウザで計測できなかったので数字は不明だが、体感的も結構速い。
ただし、アクセスが同時に来たときにwebrickは大変なことになるらしいのでpumaもしくはuniconを使うべき。
heroku × puma
Herokuの公式ドキュメントにやり方が載っていたのでそれを見ながらpumaに変更。
Deploying Rails Applications with the Puma Web Server | Heroku Dev Center
以下が作成したアプリ。
Heroku and puma
測定してみるとwebrickの場合と同じくトップページのリロードでだいたい2.2秒くらいで、速度の差はほとんどなかった。
ただ、頑張って設定したせいか、それとも本当に速くなっているのか気持ちターボリンクが速くなっている気がする。
ちなみにherokuはforkというアプリをまるまるコピーできる機能があるみたいで、今回はそれを使用した。詳しくは以下のurl参照
Forking Applications | Heroku Dev Center
heroku × euリージョン
herokuはeuリージョンも用意しているようで、デフォルトのUSリージョンから変更することができる。
以下が作成したアプリ。
Heroku and puma
まあ、そんなに変わらないですね。
普通にUSリージョン使おうと思います。
AWS × 東京リージョン
AWSのElasticBeanstalkというHeroku的なサービスを使用し、デプロイしたのが以下のアプリ。(設定はデフォルト)
Heroku and puma
書籍
負荷すくねぇ、ブロックねぇ、node.jsは何者だ
最近railsを学習しており、ふと流行りの言語とフレームワークが気になったので調べた所以下の記事を発見しました。tutorialzine.com
抜粋すると
学習すべき言語・プラットフォームでnode.jsが1位でrubyは6位。
学習すべきフレームワークの1位がAngular.jsで2位がRuby on Rails。
読んでみると2015年はJSでしょ!みたいな感じでJSが全面に出てきており、Ruby on Railsを使っていた自分としては、これでいいのか?と不安になりいろいろ調べてみました。
node.jsは何者だ
Node.jsとは何か?従来のJavaScriptとの違いは? | monopocket blog
上のブログから引用させてもらうと
————– 引用開始 ————–
バックエンドでJavaScriptが動作するには、インタープリターで変換され、 そして実行されなければなりません。これをNode.jsが行います。 内部ではGoogleのV8 VMが利用されています。 V8 VMはGoogle Chromeが使用しているJavaScriptの実行環境そのものと同じです。
それに加えて、Node.jsにはたくさんの便利なモジュールが同梱されています。 全てを1から作る必要はないのです。例えばコンソールに文字列を出力するモジュールなどがあります。
つまりNode.jsは、実行環境とライブラリの2つから成っているのです。
————– 引用終了 ————–
となっているので、node.jsは言語ではなくプラットフォームみたいです。言語はJavaScriptですね。サーバーでJSを動かす機能+モジュール(rubyで言うgemみたいな)機能 = node.js 的な感じっぽいです。
っとまあnode.jsのことを調べまくったので、Railsと比較してみたいと思います。
node.jsを使うメリット(railsと比較)
webアプリ開発という前提で、調べた所node.jsを使うメリットは
・スケーラビリティが容易
・リアルタイムに反映したりするアプリが得意(chatみたいな)
が2大メリットだと思います。
他にもメリットはあるとは思いますが、調べた感じこの2つが大きそうです。
aws難しすぎ!
クローラで拾ってきた情報を保存するために、awsを使おうとしたのですがむっちゃ難しいです。
とりあえず登録とかして、amazon RDSっていうやつでデータベース立ち上げたんですがどうやって外部接続したらいいかわからないし、マニュアルは英語だしなかなか思うように進んでないです。
て、書いているうちに適当にいじってたら解決しました。解決したのは自分のパソコンから、RDSで作ったdbにアクセス出来ねーってやつです。
https://forums.aws.amazon.com/thread.jspa?threadID=49600
を参考にしてipアドレスに/32をつけて、VPC -> Security Groups -> 該当するvpc -> Inbound Rules -> edit -> typeをAllTrafficに、Sourceを先ほどのip+/32にして保存したら出来ました。
いや~でも難すぎでしょこれ。ド素人が、軽い気持ちでいじるもんじゃないなって思いました。っていうかherokuとawsを組み合わせようとしているのがダメなのかな。
ついにクローラー完成!
amazonのランキングからデータをとってくるクローラーを作り、保存するデータベースを作り、clockworkと言うgemで定期的にクローラーを動かすようにし、ミヤネ屋で矢口の復帰を見届け、herokuでも使えるようにごちゃごちゃ設定したことによって、やっとこさクローラーが完成しました。
いやーでも、クローラーを作れることによってだいぶできることの幅が広がった感というか、能力強化された感があります。この感覚はRails以来です。
いやーうれしいです。ウレシすぎて記念にスクショ撮ったので載っけておきます。
おっと間違えました。
でも、自分の知らない間に動いてくれるっていうのはなかなかいいもんですねー。
データベースは、herokuのプラグインであるcleardbていうやつを使いました。無料枠が5MBだったので大丈夫かよと思っていたのですが、思っていた以上に大丈夫じゃなかったです。
とりあえず3,4時間動かしてみたのですが、そのときの使用容量はこんな感じでした。
ええ、致命傷です。
とりあえず、1時間動かしてみた時の使用容量はどんな感じになるのか調べてみたかったので1時間後にもう一回調べたらこんな感じで、
だいたい、1回起動するごとに0.1MB増えてました。。
インデックスをつけまくったのでこんな多くなったのか、もともとこんなのなのかよくわかりませんが、これでは1週間も持たないのでとりあえず違う方法を考えてます。
一応awsのAmazon RDSっていうやつが良さそうなので、それにしようかなと思ってます。1年間無料分があって、容量が20GB使えると書いてあるので、金を1銭も払いたくない僕にとってはよさげです。
20GBなら、20 000MB / (0.1MB×24時間) = 8333日
大丈夫そうですね。
Amazon RDSの他にもおすすめのストレージがあったら、もしよかったら教えてください。