はてなさんの「エンジニア実績システム」をベースにして、2016年の目標をたててみた
もはや4月も終わろうとしていますが、まとまった時間がとれるゴールデンウィークを前に意識が高くなっています。 そんな今だからこそ、業務外での目標をリストアップしてみます。
2016年の目標
10年後も食べていけるエンジニアになる。(こちらの記事を読んで、色々と危機感を感じたので、、、)
注力領域
以下の4つ。
効率的なモバイルプログラミングの手法を学ぶ
- Swift熱も高まってるし
- 自動化できない領域を模索する
- テストの自動化やストーリーボードの分割、ライブラリのアップデートの効率化など、保守運用コストを下げる手法を模索する
フロントエンドへのキャッチアップ
- デプロイとかトラブルシュートを考えると、フロントエンドエンジニアにお任せではすまない
- そもそも分業できるほどエンジニアいないw
機械学習の基礎を学ぶ
- インフラやライブラリも充実してきた
- ちょっとずつ活用イメージが湧き始めている
- 久しぶりに数学も勉強したい
アウトプットを増やす(OSSへの貢献や登壇など)
- トップエンジニアのソースを読む機会を増やしたい
- GitHubを派手にしたい
- 業務だけだと選択肢が狭まりそうだし
- まだ数が少ないので、スピーカーに選ばれる難易度やPull Requestの内容はここでは問わない
TODO
アウトプットをゴールにしないとモチベーションが続かなそうなので、具体的なアウトプットを残しながら勉強することを考えています。はてなさんの実績解除システムを参考にさせて頂きました。
実績を解除してエンジニアスコアを上げろ！はてなのエンジニア実績システムのご紹介 - Hatena Developer Blog
効率的なモバイルプログラミングの手法を学ぶ
- [ ] Ray Wenderlich | Tutorials for iPhone / iOS Developers and Gamersを読んでサンプルプログラムを作る
- [ ] こないだ参加したAKIBA.swift 第１回 - connpassのまとめブログを書く
フロントエンドへのキャッチアップ
毎月Web+DB PRESSのフロントエンド先遣隊を読んで、読後メモを書く
- [ ] vol.92
- [ ] vol.93
機械学習の基礎を学ぶ
入門書を読んで読後メモを書く
- [ ] Amazon.co.jp： 線形代数 ベクトルと固有値 (大学入門ドリル): 丸井洋子: 本
- [ ] 図解・ベイズ統計「超」入門 あいまいなデータから未来を予測する技術 (サイエンス・アイ新書) : 涌井 貞美 : 本 : Amazon
- [ ] マンガでわかる統計学 素朴な疑問からゆる~く解説 (サイエンス・アイ新書) | 大上 丈彦, メダカカレッジ, 森皆 ねじ子 | 本 | Amazon.co.jp
- [ ] ITエンジニアのための機械学習理論入門 : 中井 悦司 : 本 : Amazon
- [ ] 電子工作入門以前
- [ ] 数学ガールの秘密ノート/微分を追いかけて | 結城 浩 | 本 | Amazon.co.jp
ディープラーニング使って何か作る
- [ ] hogehoge
アウトプットを増やす(OSSへの貢献や登壇、Qiita/Stack Overflowでの投稿など)
登壇する
OSSへPull Requestを送る
- [x] fix bug that InfoHub does not show post on iOS9 by tjnet · Pull Request #49 · systers/malaria-app-ios
- [x] Fix warnings on Xcode7.3 by tjnet · Pull Request #205 · HighBay/PageMenu
- [x] add docs for statistics API by tjnet · Pull Request #872 · errbit/errbit
- [x] add basic tests by tjnet · Pull Request #6 · errbit/errbit_github_plugin
自分で何かOSSを作る
- [ ] hogehoge
その他
やせる
- 夕食の炭水化物を制限する(おでんや牛丼ライトで代替する)
お金の管理をしっかりする
- ライフイベントに備えて、貯める
全部できるかな、、、頑張ろう。
"Amazon.co.jp： Amazon Web Services パターン別構築・運用ガイド " Chapter1を読んだ
Amazon.co.jp： Amazon Web Services パターン別構築・運用ガイド: NRIネットコム株式会社, 佐々木 拓郎, 林 晋一郎, 小西 秀和, 佐藤 瞬: 本のChapter1を読んだメモ。
概要
本業以外のプロジェクトでインフラ構築も担当することとなり、本書を購入しました。 図解が豊富で、記述レベルが細かすぎず、要点をつかみやすい気がしました。 日進月歩で変わっていく領域なので、参考リンクが随所にあるのも嬉しい。
疑問
この章で気になったのは、Elastic Beanstalkのとこ。 フルセットでELBとか用意してくれるの、すごいじゃん！ 良さそうに見えるが、あんまり活用している人が周りにいないのは何故だろう。。？
と思ったら、このあたりに詳しく書いてあった。
のp.55辺りに詳しく書いてある。 Beanstalkは、アプリケーションコンテナを選択するだけで、フルセットの環境一式が準備できるが、Cloud formationと比較してフレキシブルではない、とある。
触ってみないとわからないけども、Elastic Beanstalkではミドルウェア導入済みのEC2インスタンスを使用するそうなので、技術選定(APサーバとか)の自由度は低くなるんじゃないかな。。。PaaSライクなものかな?
アプリサーバー対決 パート1：主なRubyアプリケーションサーバーの機能比較 [和訳] - Engine Yard Blog
Cloud formationの利点は、テンプレートが再利用できること。ステージングと本番で同一構成のシステムを複製したり、インフラ構成自体をバージョン管理したりすることも容易になる。
まとめ
導入の容易さ
Elastic Beanstalk > Cloud formation
自由度
Elastic Beanstalk < Cloud formation
多分どこよりも早い ドッツサミット2015 レポート
dots.summit 2015とは?
フリークアウトのおしゃれオフィスでトップエンジニアによる講演を聞きながら、エンジニア同士の交流をはかる素晴らしいイベント。運営はインテリジェンスさんですね。それにしてもバスケットゴールやらビリヤード台やらがあって、遊び心いっぱいのオフィスでした。
『短納期＆少人数でも実現できるCI』
株式会社LiB 米山諒氏
女性向け転職サイト、
キャリア女性のための会員制転職サービス | LiBz CAREER（リブズキャリア）を運営しているLiB 米山さんのお話です。
なんだかんだスピード優先されて、わやくちゃになるこのフェーズでも、CIやコードレビューを導入しているスタートアップのお話。すげーな。米山さん、いつ寝てるんだろう。確かまだ設立1年経ってないはず。。。LiBのエンジニアカルチャーを定義したり、コードレビューを行う文化だったり、エンジニアを大切にする風土が伝わってくるお話でした。
『SPEEDA/NewsPicksを支える技術の選定手法』
株式会社ユーザベース 竹内秀行氏
技術を選定する際に大切にしているポイント、というお話でした。
「ただそれを作りたいから作る」「ただ自分がその言語を使いたいから使う」という公私混同に陥ってはいけない。
「その技術はユーザに価値を届けているのか」、忘れがちな視点ではあるので、改めて肝に銘じたいと思います。
『何故scalaを選んだのか？ 〜 アドテクスタジオの場合 〜』
株式会社サイバーエージェント 神田勝規氏
20150207 何故scalaを選んだのか
スライドは、まだ公開されていないようで、残念。。。
scalaを採用した理由は、こちらにも詳しく書かれていますね。
http://careerlaboratory.jp/archives/742
Tech Talk ～ サイバーエージェントアドテクスタジオがScala言語を選んだ理由 | キャリア・ラボラトリー
Javaだと冗長になりすぎる所をシンプルに記述できたり、並列分散処理に優れていたり、といった点が好まれているようです。
トップダウンで導入した、というよりは社内勉強会を開いたり、新しい技術の習得に熱心な風土は素晴らしいですね。
『変わったUIを持つアプリ”へやくる！”』
株式会社ネクスト 大坪五郎氏
お題のアプリはこちらですね。FacebookのPaperを参考にしたというアプリです。
今度、ネクストさんの勉強会にもお邪魔したい!
大規模並列検索サービスGoogle BigQueryについて』
Google Inc. 佐藤一憲氏
ビジネスサイドからの
・ ディレクターの人でも解析、分析したい
・ブラウザから色々やりたい
といった要求にこたえやすいかもしれません。
Google BigQueryについては、こちらのスライドで丁寧に説明されています。
Google BigQueryを使ってみた！
Treasure Data と OSS
『ビックデータ時代のビジュアライゼーション』
Tableau Japan 株式会社 飯塚桂子氏
『会員数180万人のマッチングサービスpairsの急成長を支える技術基盤』
『次世代のリアルマーケティングプラットフォームに挑戦するラクスルの開発体制について』
『ベストアプリW受賞を支える開発手法』
株式会社VASILY 今村雅幸氏
CTO対談！！
～ CEOが迫る！ヒットサービスを生み出す技術組織の作り方 ～
・モデレーター ランサーズ株式会社 代表取締役社長 秋好陽介氏
・株式会社VASILY 取締役CTO 今村雅幸氏
・株式会社ユーザベース 執行役員 竹内秀行氏
Q.CTOって何してるの？
A.広報とか技術戦略とか採用とか雑用とか。
コード書く時間は、やっぱり減った。
Q.成長するエンジニアとは?
A.ハングリーで、5分に1回くらい、サービスの成長につながる事を考えてるような人(僕は無理ですけどw)。組織に深くコミットして、終電とかになりながらも、でもインプットの時間もきちっと取れているような人。
Q.ダメなエンジニアを雇ってしまったら
A.今、思い返しても、そんな人いない。モチベーションの低い人を雇ってしまうと、全体としてレベルが下がる。入り口(採用)でどこまで慎重になれるか。どこまで本気度高くやれるかが大事です。VASILYではエンジニア10人呼んで、10対1で面接する事もあります。
そろそろ「パーフェクト Ruby on Rails」読んで本気出す ⊂('ω'⊂ )))Σ≡=─༄༅༄༅༄༅༄༅༄༅
購入の経緯
とりあえず、日々の仕事については、ある程度こなせる様になって来ました。
ただ、Raisのベストプラクティスやイケてるスタートアップの開発フローと比較すると、色々と思うところがあり、Railsの世界観を学ぶため、本書を購入するに至りました。
Amazon.co.jp： パーフェクト Ruby on Rails: すがわら まさのり, 前島 真一, 近藤 宇智朗, 橋立 友宏: 本
こんな人にオススメ
- 現職でRailsを使用している
- Railsで簡単なTODOアプリとかなら、大体作れる
- Modelが肥大化してきた時の対処法/設計指針を学びたい
- TDDやってみたい
- おすすめのgemとか教えてほしい
- 環境構築 => 開発 => テスト => 本番環境構築 => デプロイという一連の工程をモダンな環境で行いたい
Rails初心者の方が、1冊めとして手に取る本ではない気がします。
Railsは全く初めて、という方であれば、こちらのチュートリアルを先にこなした方が良さそうです。
Ruby on Rails チュートリアル：実例を使って Rails を学ぼう
この分量、クオリティで無料ってすごい。
サンプルコード
こちらに、公開してくださっています。書籍のサポートページもあるようなので、そちらも併せてご参照下さい。
パーフェクト Ruby on Rails のサンプルアプリケーションを Github 上で公開しました - willnet.in
とりあえず、今の自分に必要そうな所だけ、丁寧に読みました。
第1章 Ruby on Railsの概要
環境構築方法や、Railsの設計思想に関するお話。
ActiveRecordの設計思想や、RESTのお話は、復習しておきたいですね。
第2章 Ruby on RailsとMVC
MVCに関する記述は、意外と薄め。前提としてMVCって何なの?という知識は事前に必要な気がします。
REST、ルーティングについても、ここで復習できます。
StrongParametersについては、Rails4で導入されたものなので、現場の状況によっては知らない人もいるのかな?
variantsによるテンプレートの切り替え、特定のレイアウトを適用する方法は、次のお仕事でも使いそう。
第3章 アセット
必要な時に読み返せば済む領域だと考えているため、スキップしました。
第4章 Railsのロードパスとレイヤーの定義方法
MVCにあてはまらないモジュールをどのように管理するのか、その考え方について述べています。ロードパスとかもここで復習しました。MVCにあてはまらないレイヤーの設計指針については、第9章で更に掘り下げていきます。
第5章 開発を効率化するgem
Better Errorsとpryはさっそく使ってみたい。
第7章 Railsアプリケーションのテスト
駆け足ではありますが、TDD、静的解析、CIまで一連の流れを解説してくれています。使用しているツールやサービスも実務でお目にかかる可能性の高いものだと思います。
本書とは直接、関係はありませんが、Rspec入門としては、こちらの記事がおすすめです。
第8章 Railsのインフラと運用
とてもコンパクトにまとまっています。が、インフラは扱う領域が幅広いので、個別のツールについては、別途掘り下げる時間が必要です。DevOpsやスタートアップに興味のある方は、ここにあるキーワードはおさえておくと良さそう。
第9章 より実践的なモデルの使い方
なぜ、バリデーションとコールバックをクラスに分離するのか、その必要性について納得いく形で答えてくれます。
サービスクラスの使いどころと、使用する際の注意点についても触れています。
業務で悩むのも、まさにこの「より実践的なモデルの使い方」だったりするので、今の自分にはぴったりだと思っています。
それなりに難しく、読み応えのある部分なので、何度も読み返したいです。
まとめ
Railsエンジニアの2冊めとしておすすめ。みんなが勧めるのもよくわかる。
第9章は読み返したい。
Special Thanks!
【本場でも通じるふりかえりテクニック】アンチパターンとその対策
本場ってどこやねん。。。
"改善MTG(ふりかえり)"あるある
プロジェクトの節目に行うふりかえりMTG、改善MTG。
これって、盛り上がらなかったり、自然消滅してしまう事も多いですね。その原因となるアンチパターンや対策について考えてみました。
上からメセニストとしてではなく、自戒を込めて書いています。
ふりかえる必要性を感じているメンバーがいない
本当に、ふりかえる必要性を感じているメンバーがいないのであれば、そのチームは完全無欠で理想的な状態にあるのかもしれません。ただ、そんなチームあるのかな。。。
ふりかえった事がなくてキョドる
いきなり"ふりかえりMTGやりましょう"と言われたら、ほとんどの人がどうしていいかわからない。
ただ、ちゃんと探せば、やり方まとめてくれてる人がいるんですね。勉強しようっと。
下のリンクは、めっちゃわかりやすいです。
ふりかえり会のススメ(進捗会議編)
http://objectclub.jp/download/files/pf/RetrospectiveMeetingScenario.pdf
一度のみ振り返り
こういうものは、一度で効果が出る方がむしろ稀なので、繰り返さないと駄目ですね。そもそも一度だけ振り返っても効果が計測できないですし。
自戒を込めて書きました。
効果がない(改善案が生かされない、実行に移されない)
プロジェクトの最後にふりかえりを行ってしまうと、こうなりがちですね。
この手のMTGは、プロジェクトの途中、まさに問題に直面している過程で定期的に行う方が良さそうです。結果をどう生かすのか、まずメンバー間で共有してからMTGを始めなければいけないのだと、お仕事を通じて学びました。
どうやって進めればいいのかわからない
何となく改善MTGを導入すると、一人一人が反省点を口にして、何となく終わってしまう。未来につながるお話にならない。そこでKPT。「型」を導入する事で、進め方をまず共有する。
批判の応酬、責任のなすり付け合いになってしまった
これ、僕もやってしまった事があります。。。そもそも、うまくいっていないチームだと、こういう場を設けた時に、一気に不満が噴出する事があります。これは解決が難しそうですが。。。
まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。
あとは、"**のせい"という論調になりかけた時に、「自分ならどうする?」「これからはどうする?」と自責で、未来志向で考えられるように声がけを行う事でしょうか。不思議なもので、第三者がこういった声がけを行うだけで、ほとんどの発言者は無意識のうちに自責で考え、未来に向けた思考を行えるようになるものです。僕自身も、何度もこの言葉に救われた気がします。
言葉の持つ力を甘く見てはいけないですね。
また、不満を抱えているメンバーには、MTGが始まる前に個別にお話をして、ガス抜きをする事も重要かもしれません。
Keep飛ばし
いきなり"Problem(問題)"から言及して、みんなどよーんとする。お通夜MTGの幕開け。
対策は、まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。大事な事なので、２度書きました。
ほとんどのメンバーが効果を感じていない or 楽しくない
では、なぜ、メンバーが効果を感じていないのか。効果が目に見えないから、もしくはフィードバックを受け取るまでのサイクルが長過ぎるからではないでしょうか。
効果が計測できて、フィードバックまでのサイクルを短くする事ができれば、やっているうちに楽しくなってくるはず。では、どうすれば可視化できるのか、フィードバックを短くできるのか。
考えられる解決策としては、このあたりでしょうか。
- 可視化できるものを目標にする。
- フィードバックサイクルが長過ぎるものは、短く分割して、短期間にフィードバックを得られるようにする。
なげっぱなし、言いっぱなしのTry
誰が何時、何時までに、何をどうする。などより具体的で明確な内容に落とし込む。場合によっては、実行されたかどうかの確認方法まで盛り込む。
。。。。というより、こういう風に具体的に落とし込めないものは諦めて、本当に出来そうなものだけ、3つだけTryする、というのが良いかも。
短期間で、そんなに5個も10個もTryしながら、改善活動できない気がする。
【参考】
仕事を楽しくする【AWSを使わない】はてぶの記事をサムネイル付きでJSON配信する3ステップ
はじめに
類似するネタは、オンライン上に色々な方が書いて下さっているのですが、"サムネイルはAWS S3に保存しよう!"的なネタが多く、VPS一台で処理を完結したい自分にとっては、そのものズバリの記事がありませんでした。需要があるかどうかわかりませんが、書いてみたいと思います。
おおまかに実装方針を立てると、このようになります。
- はてぶのAPIから記事を収集する(XMLをフェッチしてパース)
- はてぶの記事URLからサムネイルを生成してDBに保存(dragonflyもしくはcarrierwaveを用います。どちらでも可能です)
- 記事とサムネイルをJSON形式で配信する
今回は主要部分を抜粋してご紹介します。ソースコードはこちらに公開しております。
tjnet/geeknews-rails · GitHub
(1)はてぶのAPIから記事を収集する(XMLをフェッチしてパース)
まずはとにかく記事データが必要ということで、railsを用いて記事を収集します。データ収集に利用したのは以下のコードです。
#coding: utf-8
require 'pp'
require 'net/http'
require 'uri'
require 'rexml/document'
module Tasks
class ArticlePicker
# initialize article data
def self.execute
ActiveRecord::Base.connection.execute("TRUNCATE TABLE articles")
feed_list = Feed.all
articles = []
feed_list.each do |feed|
next if feed.url.blank?
articles = fetch_and_parse(feed.url)
save_articles(articles, feed.category_id)
end
end
# save articles
def self.save_articles(articles, category_id)
return if articles.empty?
pp '--'
pp Time.now
articles.each do |article|
#pp sprintf('save %s of %d', article['title'], category_id)
pp sprintf('save %s of %d', article['link'], category_id)
Article.create!(
:category_id => category_id,
:title => article['title'],
:link => article['link'],
:description => article['description'],
)
end
end
# return parsed articles
def self.fetch_and_parse(url)
res = fetch(url)
articles = xml_to_array(res)
pp articles
articles
end
# fetch response from url
def self.fetch(url)
pp URI.escape(url)
uri = URI.parse URI.escape(url)
res = Net::HTTP.get uri
res
end
# return parsed XML
def self.xml_to_array(xml)
items_rx = []
doc = REXML::Document.new xml
doc.elements.each('//item') do |e|
i = Hash.new
i["title"] = e.elements['title'].text
i["link"] = e.elements['link'].text
i["description"] = e.elements['description'].text
items_rx << i
end
return items_rx
end
end
endリトライ処理などは、別のスクリプトに切り出しています。
begin
pp "updating article ..."
Tasks::ArticlePicker.execute
rescue Exception => e
pp "[ERROR] update_article #{e.message}"
retry_count += 1
retry if retry_count <= 5
pp "retried 5 times so exit"
exit
end
pp "updated article"
(2)はてぶの記事URLからサムネイルを生成してDBに保存(dragonflyもしくはcarrierwaveを用います。どちらでも可能です)
URLからサムネイルを作成するためにwkhtmltoimageを実行しています。
DBへの保存はcarrierwaveを用いています。
# Generate and assign an image or set a validation error
begin
tempfile = temp_thumbnail_path
cmd = "wkhtmltoimage --quality 40 --width 50 --height 50 \"#{self.link}\" \"#{tempfile}\""
p "*** grabbing thumbnail: #{cmd}"
system(cmd) # sometimes returns false even if image was saved
self.photo = File.new(tempfile) # will throw if not saved
self.save
rescue => e
p "*** thumbnail error: #{e}"
self.errors.add(:base, "Cannot generate thumbnail. Is your URL valid?")
ensure
endDBへのデータ保存が終われば、wkhtmltoimageで生成した一時ファイルは不要となりますので、modelのコールバックで後始末します。
#Cleanup temp files when we are done
after_save :cleanup_temp_thumbnail
# Cleanup the temporary thumbnail image
def cleanup_temp_thumbnail
File.delete(temp_thumbnail_path) rescue 0
end
(3)記事とサムネイルをJSON形式で配信する
ここまででDBに画像データを保存できました。後は、これをcontrollerからJSONとして配信します。
class Api::V1::ArticleController < ApplicationController # return articles def index render json: Article.list(request) end end
#
#= return articles as array of hash
#
def self.list(request)
res = Array.new
Article.all.each do |article|
res.push({
:category_id => article.category_id,
:title => article.title,
:link => article.link,
:description => article.description,
:image_url =>(article.photo.blank?) ? '' : "#{request.protocol}#{request.host_with_port}#{article.photo.url}",
})
end
res
end記事URLを生成するために、controllerからrequestを受け取っています。
もう少し簡潔に書けそうですが。。。
はまりどころ
うまく動かないときは、このあたりをチェックしてみて下さい。
- サムネイルを一時的に保存するディレクトリのパーミッションなど
- public/以下のディレクトリ構造
- 本番環境だけで動かないときは、デプロイ設定やrackサーバの再起動が正常になされているか
TODO
次は、このあたりに取り組みたいですね。
- cronの設定
- サムネイルのクオリティを向上させる
- 静的ファイルの配信を高速化
【VPSか、AWSか、Herokuか】結局、最後はさくらVPS+Unicorn+Rails+Capistranoに行き着いた【構築スクリプト付き】
お仕事以外にも色々手を出しています。
主に知り合いの方とサービス作ってみて頓挫したり、細々とiPhoneアプリを開発してみたり、、まったり作っていきたいと思います。
サーバを用意する際の選択肢について
自分のサービスやアプリを公開するとなった場合、どうしてもサーバが必要になります(僕の場合、自前のAPIと連携しないアプリって何となくモチベーションが湧かないのです。もちろん、既存のAPIを叩くだけでも、アプリを作成する事は可能ですが、はてなブックマークの記事を取得するだけのアプリでも、後からレコメンド機能を実装したり、記事を独自アルゴリズムで分類したり、、、やってみたいですよね。)
現実的な選択肢
みなさん、どんな観点でプラットフォームを選択されてるんでしょう。
ここでは、3つの観点から考えてみました。
- 学習コスト
- 技術的制約
- ランニングコスト
学習コスト
まずAWSは、AWSそのものの作法を覚えなければならない為、(ベースになるLinuxの知識+AWSの知識)が必要となり、学習コストは最も高そうです。
さくらのVPSに関しては、色んな方が構築方法を公開されていて情報量も多く、ピュアなLinux単体の上に構築していくため、AWSと比較すれば、把握する範囲は比較的小さくなります。一定の水準でセキュリティを保つ設定が出来ていれば、なんとかなりそうですね。流れとしては、いったんは手動でLAMP環境を作ってはサーバを初期化して、、、といった事を繰り返してみるのが勉強になった気がしています。SSHの設定を間違えてログインできなくなり、泣く泣くサーバを初期化したのも、今となっては良い思い出。さすがに今は忙しくなって来たので、Ansibleで構築手順を半自動化しています。
AWSやVPSでサービス開発を行う場合、手間がかかりそうな所といえば、デプロイ環境の構築でしょうか。手元のMacで開発=>本番のさくらVPSにデプロイ、といった構成にしたい場合は、自分でこれを設定しなければなりません。
セキュリティの設定、デプロイツールのセットアップをすっとばしたい、という場合はHerokuでしょうか。
デプロイに関しては、Herokuは圧倒的に簡単です。
手元のMacで開発したプロジェクト配下で"git push heroku master"とかやれば、デプロイ完了です。最も初速の出やすい開発プラットフォームではないでしょうか。
技術的制約
今回は、ニュースアプリの作成を予定しているため、サーバにサムネイルを一時保存したかったのですが、Heroku単体ではそれができない為、色々検証した結果、Herokuは選択肢から外しました。
次にAWS。スタートアップ界隈では実質業界標準になってきている(気がする)AWSには、正直何でも搭載されている感があります。スケールさせやすかったり、Herokuで出来ないファイル保存ができたり、、。ただ、趣味の開発でここまで必要なのか。。と言われると正直必要ない場面も多そうですね。色々有りすぎるために、把握しないといけない範囲が増えて手が止まるのは嫌ですね。
さくらのVPSは、AWSみたいにポチポチインスタンス増やしてスケールさせたりは出来ません。ただ、ピュアなLinuxであり、root権限も付与されているため、1台にNginx+(Unicorn+Rails)+MySQL全部盛り、みたいな構成にするならVPSで十分ですね。
開発環境/本番環境を構築する上での前提
というあたりを意識して作りました。個人開発なら、Ansibleで自動化するのが、おすすめですよ。
開発環境
Ansibleを用いてvagrant上に(CentOS+Unicorn+Rails)の環境を構築します。サーバサイドの開発はVagrant上で完結します。
こちらの記事なども、参考になりそうです^^
【5分で学べる】Vagrant上にRailsをAnsibleでかんたんクッキング(CentOS6, MySQL, Rails4, Unicorn) - 不格好エンジニア (引っ越しました)
サーバ設定などのアップデート
開発環境/本番環境を問わず、すべてAnsibleを通して行っています。実際にCentOS+MySQL+Unicorn+Railsを導入するための構築スクリプトは、こちらに公開しています。
tjnet/vagrant_sakuravps_rails · GitHub
本番へのデプロイ
Railsプロジェクトのリポジトリにデプロイスクリプトを入れています。具体的にはCapistrano3(capistrano3-unicorn)を導入しています。
実際にはAnsibleでもデプロイは出来るのですが、Capistranoの方がRailsとの相性は良さそうです。staginやproductionといった複数環境へのデプロイに対応していたり、bundle、migration、unicornとの連携も考慮されており、使いやすいと思います。
作成中のサービスにCapistranoを導入した事例はこちら(config/deploy.rbのあたりは見よう見まねで、おかしい所が多々あるかもしれません)。
デプロイ設定をGitHubで公開するかどうかは、少し悩みました。ただ、ローカル(vagrant)のHostsファイルに本番環境のIPアドレスを記述するようにすれば、具体的なサーバの情報をGitHubに公開してしまう事もありません。アドバイスを頂けるチャンスもあるかもしれないですし、こんな情報でも誰かの役に立つかもしれないので、積極的にシェアしていきたいと考えています。
かかるコスト
かかるコストですが、シンプルに使ったサーバ台数x使用したVPSの月額料金です。
