Rails で作ったサービスを Heroku から Sqale に乗り換えた話

先日公開した FeedlyGraphホスティングを移行した。


乗り換えた経緯

Heroku の無料枠を超えたことがきっかけ。


アプリケーションは問題なかったが、問題は DB。
Postgress は 10k rows までが無料枠だった。
(よく確認してなかった。容量制限だろうと油断した)


サービスの性質上、Feedly購読者数のレコードが毎日ガンガン増えるため、1ヶ月足らずで突破していた。


Heroku の DB を有料で使うとすると、$9 / 10k rows か、$50 / month が候補。
流行ってないプライベートプロジェクトでそれほどのコストをかけるのはつらい。


少し気になっていた Sqale を調べてみると、月額940円で DBは2GBついてくる。
ということで Sqale に移行することに。


移行でやったこと

アプリケーションを修正

Gemfile を修正。


移行前(Heroku)

group :production, :staging do
  gem 'pg', '0.15.1'
  gem 'rails_12factor', '0.0.2'
end

移行後(Sqale)

group :production, :staging do
  gem 'mysql2'
end


database.yml を修正。


移行前(Heroku)
Rails 初期状態なのでカット。


移行後(Sqale)

production:
  adapter: mysql2
  encoding: utf8
  username: { username }
  password: { password }
  database: { database_host }
  host: mysql001.sqale.jp


DB の移行

Heroku 上の Postgres をエクスポート

pgAdmin3 を使って接続し、ローカルにエクスポートした。
pgAdmin: PostgreSQL administration and management tools


Sqale 上の mysql にインポート

Qiita の記事を参考にデータを加工。
PostgreSQLのデータをMySQLに移行する - Qiita

あとは ssh で Sqale 上のマシンに接続。
mysql で直接 SQLを読み込ませてインポート。


Cron

Heroku の Scheduler でやっていたタスクを Cron に移行した。
Sqale - Sqale の特長


NewRelic

特に変更なし。
Heroku 上でアドオン削除すると何か起きそうで不安だったけど、問題なし。


ドメイン

ドメインの割り当てを Heroku のサーバから Sqale のサーバに変更。
自宅からは 5分くらいで変わっていた。
2日くらいしたら Heroku を削除しても大丈夫なはず。


最後に

極力無料の範囲内でやるつもりだったけど、少しコストをかけてでもサービスを続けたほうが問題が起きて勉強になる気がするので続けてみる。
元は取れないだろうけど、お世話になることだし、Sqale の広告でも入れてみようか。


ペパボの教科書 インターネットサービスではじめる、あたらしい自分

ペパボの教科書 インターネットサービスではじめる、あたらしい自分


複数のプログラミング言語を学ぶメリット

プログラミング言語

10 Programming Languages You Should Learn in 2014より


僕が最近触るプログラミング言語をあげておく。
仕事は C#JavaScript
プライベートで先々週が Ruby、昨日は PHP だ。


メリット

ググる対象が広がる

ググる言語が増えれば正解にたどり着く可能性も高まる。
昨日公開した PHP のYammer API ライブラリ の話。


実は Yammer API をいじる試みは前にやっていたんだけど、認証周りがうまくいっていなかった。
少し前に Ruby を始めたことで Ruby の公式 Gem を読めるようになった。
読んでみると数分で問題は解決した。
原因は、AccessToken を HTTP Header に入れればいいだけというショボい話。


こんな感じで「既にある別の実装」という手がかりが手に入るのは大きい。
知らない言語を読むのは拒否反応が出るけど、ちょっと読めるレベルになるのは簡単。
Ruby なら Railsチュートリアルの第4章を読めばいい。


飽きにくく、面白い

僕は飽きっぽくて、一個のことをひたすらやるのがニガテだ。
マルチタスクは好きじゃないけど、煮詰まったときにひたすら考えるのはもっと好きじゃない。
煮詰まったときに何かを閃くのは、僕の場合はシャワーを浴びてるときが多い。
どうやら頭の違う部分を使うといいらしい。


これが違う言語をいじっているときも同じで、ふとしたきっかけで新しいひらめきにつながったりする。
Rails をいじっていると「CakePHP ではどうなってたっけ?」とか、言語(やフレームワーク)をまたいで疑問が湧いてくるので、知識を深堀りしようとするきっかけになる。
知識欲が刺激される状況に身を置くのはなかなかいい。


技術の幅が広がる

月並みだけど、要求を実現するのに一番早い方法を選択できるようになる。


小さいWebアプリを好きな場所に手軽に公開するには PHP は向いてるし、
多くの公開されたライブラリを活用することで要求に集中するには Ruby が向いてる。

こんな感じで自分なりの選択フローを見つけていくのがいい。


リスクヘッジ

プログラマーとしての寿命に対してのリスクヘッジ
言語の流行り廃りにはイチ個人、イチ企業レベルでは抗えない。


最後に

今回あげたメリットは、個人視点での話。
会社視点では、言語を絞ったほうが人を確保しやすいし、教育コストも下がる。


少なくとも個人視点ではメリットが大きいので、普段触らないものにもチャレンジしてみるといいと思う。


7つの言語 7つの世界

7つの言語 7つの世界


PHP で Yammer の REST API を叩くためのライブラリを公開した

Yammer の REST API を使いたかった。
既存の Apache で手軽に動かすために PHP を使いたいが、公式では SDK がない。

Yammer SDK


なければ作ればいいじゃない。
ってことで、作って公開した。

kheiakiyama/php_yam · GitHub


公式の Ruby SDK にインターフェースを近づけてみた。
いわば写経、というか翻訳か。


自分が使うもの以外をテストする気がないので GETメソッド の一部しか対応してない。
他の API を生やすのは簡単そうなので真似ればできるはず。
世の中の誰かのためになれば。


いきなりはじめるPHP~ワクワク・ドキドキの入門教室~

いきなりはじめるPHP~ワクワク・ドキドキの入門教室~


プログラミング学習のモチベーションを維持する方法

と心の中で思ったならッ!その時スデに行動は終わっているんだッ!

photo credit: SweetOnVeg via photopin cc


まえがき

プログラミングを学習するうえで最も大事なモチベーション。
僕がどうやってモチベーションを維持しているかをまとめてみる。


やる気が出る環境

短期的なモチベーションアップのための環境づくり。


場所

僕は休日に家にいると Twitterはてブを眺めていてなかなかやる気にならない。
そのため MacBookAir を持ち歩いて、ドヤリング駆動開発(DDD)する。


主にカフェや図書館。
(このエントリも図書館で書いている)


カフェではそれほど長居せず、食事込みで1時間半くらい。
作業のとっかかりさえ手をつけてしまえば、その後は帰宅してもやる気が継続する。


僕の場合は(実際に見られているかは別にして)他人の視線がある環境にいたほうが集中するみたいだ。


BGM

無音は寂しいので BGM 必要。


気分が盛り上がるけど興味がいきすぎない曲がいい。
最近は BUMP OF CHICKEN の RAY をよく聞いてる。



こっちは気分をとにかく上げるときに。


半年くらい前は作業音が流行ってて、 Coffitivity をよく使ってたけど飽きた。


フィードバックを得る

こちらは中・長期的なモチベーション維持のため。
一歩を踏み出した後にフィードバックを得られるようにする。


人に話す

単なる知識を経験として蓄積するための活動。


たとえば職場の同僚に話すことにしている。
読んだ本で気になったことを話したり、現場に適用してみたり。


先日はリーダブルコードを読んで以降、コードレビューで名前について議論するようになった。
「コイツ急に語るなあ」と思われようが関係ない。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)


身につけた知識は使わないと意味がないし、使ってから知ることもある。
なので荒削りな知識を積極的に使って、磨きをかけるプロセスを意識的に行っている。


ブログを書く

こちらは知識を体系的に整理するための活動。


自身が学んだことを振り返るきっかけになる。
また、要点にまとめることで瑣末な情報はフィルタリングして大事なところだけに集中できる。


たまに Twitter やコメントがもらえるけど、うまく伝わらないことによるノイズもある。
どちらかというと反応があったこと自体によって承認欲求が満たされることが大きい。


最後に

ここまでいろいろ書いたうえでちゃぶ台返すけど、やる気がなくてもエディタを開いて書き始めればだんだんやる気が出てくるもの。
これだけ準備したからやんないと!って自分を追い込みたいときと、精神論でやればやる気になるさ!ってときを使い分けられるといいかなと思う。


やる気のスイッチ! (Sanctuary books)

やる気のスイッチ! (Sanctuary books)

やる気のスイッチ!

やる気のスイッチ!


Feedly の購読者数をサイドバーに表示した

今回も Feedly ネタ。
前に書いたブログパーツの話。


前置き

Feedly 購読ボタンの設置は Feedly公式ページ を見ればやり方分かるはず。
これだけでは購読者数が見えないので、面白くない。


WordPress だと PHP のコード置けるので、このへんのエントリ参考にすればできる。
僕は WordPress 使ってプロブロガーになるつもりはないけど、少しばかり見た目をいじりたいので困っていた。


やり方

サイドバーに以下のような HTML を設置する。

<object width="120" height="28"  data="http://www.feedlygraph.info/blog_parts?feedid={フィードID}">
</object>

「フィードID」は、Feedly のフィードIDをURLエンコードした文字を指定する。
このブログの場合は、「feed%2Fhttp%3A%2F%2Fkheiakiyama.hateblo.jp%2Frss」となる。


調べ方が分からない人は FeedlyGraph で自分のブログを検索して、URLをコピーするのがラク。

FeedlyGraph でフィードIDを調べる


説明

上で HTML を書いたので気付いた人もいるかもしれないけど、昔でいう IFrame を使っている。
FeedlyGraphブログパーツ用ページをページ内に表示しているということ。


設置を簡単にする代わりに、マークアップをいじれない形式にしてあるので、
それでもいいという希少な人は利用してみてください。


購読者数には「FeedlyGraph で確認する」リンクが設置してある。

FeedlyGraph で確認


最後に

初めてブログパーツを作ったけど、対応の仕方がいろいろあって悩んだ。
購読者数を取得する API を用意してクロスドメインで JS で使うパターンも考えたけど、

  • Feedly が公式でそれをやっていない以上やるべきではない
  • セキュリティ上で不安
  • FeedlyGraph にとって何もメリットがない

ということから今回はやめた。
最近更新されてない?TopHatenar っぽいものも考えたけど、ブログ読む人は履歴に興味ないだろうし。


これ使いたいけど少し見た目をいじりたいって方はご意見ください。
(ボタン変更したいよ、とか。)
僕も FeedlyGraph 使う人が増えると嬉しいので、前向きに対応するつもりです。


必ず結果が出るブログ運営テクニック100 プロ・ブロガーが教える“俺メディア

必ず結果が出るブログ運営テクニック100 プロ・ブロガーが教える“俺メディア"の極意


僕がWebサービスを公開した後の1週間

先日 FeedlyGraph を公開した。
今回は公開後の1週間でどんなことをやったかの日記。


↓ 関連記事


アクセス監視

NewRelic や GoogleAnalytics をチェックし、異常があったら調査。
NewRelic は超便利。


エラーログ

FeedlyGraph Error - NewRelic


エラーログをもとにローカルで現象を再現してバグ修正。
それにしても公開当初はヒドすぎた。


この後ちゃんと直した。


パフォーマンス

アクセスのレスポンス時間が分かるのも便利。
フィードの最新データの蓄積でフィードの数だけ取得しているので、その間のアクセスが重い。

FeedlyGraph ResponseTime - NewRelic


feedly Cloud API で同期処理してたりとひどかったので、非同期処理に変更。
600〜700件のフィード取得が、おおよそ 210s → 10s に改善した。
(劇的に改善したというより、単純に最初の実装がヒドかっただけなんだけど・・・)


参考


エゴサーチ

Twitter のキーワード検索でエゴサーチした。
はてブホッテントリ効果もあってか、サイトに取り上げていただいた。


男子ハックではちょっと誤解を招く表現になっていたので著者にツイート。

その後、修正していただいた。


やりとりが Web 上で完結するのは今っぽい。


最後に

今回 2日で出来るものを7日かけて公開したけど、公開は完成じゃない。
Web サービスは公開してからが本番だと聞くけど、体感できたのは大きい。


そして幸運なことに、はてブコメントを含め、ありがたいフィードバックに恵まれた。
承認欲求が満たされてモチベーションに繋がる。
自分のためのプロダクトでも公開してみるものだ。


見ていただいた方々、
コメントいただいた方々、
拡散いただいた方々、
ありがとうございました。


ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス

続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス


次の staticおじさんは僕やあなたかもしれない


とある福井のstaticおじさん - Togetterまとめ

このまとめ読んだ。


ヒドい職場だよなー
オブジェクト指向使えないとかありえないよなー
ソースコード管理しないって意味分かんないよー
って感想がほとんどだと思う。


でも、職場に何かを導入したという人はそれほど多くないのではないか、と思う。
たまたま staticおじさんの職場環境よりも進んだ職場に入ったというだけ。
それって staticおじさんと何が違うんだろう?


新しい技術に、抵抗するか or 黙って受け入れるかの違いだけじゃないか。
(往々にして、黙っていた人たちは導入後に文句を言う)
抵抗する人も黙っている人も、新しいものに対して無学という点では同じ。
そんな受け身の人に教えるコストは高い。


こういう人が多いと何かを変えるなんてことは労力がかかって誰もやりたがらない。
みんなが新しいものごとに無関心になるから、職場全体の時代は止まる。


結果、数年後に Subversionおじさんが生まれるのではないだろうか。


いや自分は Subversionおじさんにはならない!
もっといいものがあるなら知りたい!
って人は、下を読んでいってください。



↓気になる本


GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)