Herokuで成功させるサービス開発 - ボクココ
ページ版執筆にあたって ども、@kimihom です。 技術書典5で販売した書籍の記事版として公開します。より多くの方へ Heroku でサービス開発を成功させていただきたいという思いから、ボクココの固定ページとして無償公開するに至りました。 なお、本記事は、Heroku 社から認められていない非公式の記事となります。予めご了承ください。 はじめに Happy Coding! 本記事はWebサービス開発を本気で成功させたいと考えているエンジニア向けに、サービス開発とHerokuの運用に関して記しています。サービス開発を成功させるには、限られた時間の中で注力すべき内容を見極め、サービスの差別化を推し進めることが重要です。ユーザーはなぜ他の多くのサービスではなくて、あなたが作ったサービスを使うのか。その問いに自信を持って答えられるようにしなければなりません。その状況の中で、どのテクノロジーを採
アプリの個人開発の終焉と新たな可能性 - ボクココ
ども、@kimihom です。 今回は私が今まで開発して来た個人開発と、そこで学んだ次の可能性について記していく。 個人で開発したアプリで食っていく 今でもちょくちょく個人開発をしている方をよく見かける。安定した仕事に勤めていた頃、私もその個人開発者のうちの一人だった。週末や空き時間があれば、ひたすらスマホアプリを開発し、私が作ったアプリの合計は十数個にのぼる。最初はゴミみたいなアプリを量産してたわけだけど、経験を積むにつれていいアプリを作る感覚を持てるようになって、１つだけ当たったアプリ(個人開発で15万DL 超えのアプリ)を作ることができた。この"当たるアプリを作る感覚"ってのは、アプリのアイディアそのものであったり、開発だけでないデザインやストアに掲載する文言やSEO、シェアされる仕組み、その他運用テクニックなど多様なものだ。 個人開発を可能にした背景に、スマートフォンアプリの流行が
Heroku で本番運用を続けていくために必要なこと - ボクココ
ども、@kimihom です。この記事は Heroku Advent Calendar 2017 の 20日目です。明日以降が豪華メンツで今から楽しみですね。 さて、今回は Heroku で本番運用を続けていくって方のための情報をシェアしたいと思う。自社サービスで Heroku を使い続けている事例ってのがあまり出て来ないので、積極的に開示していきたいと思う。 ※ 本記事は、今年書いた Heroku に関する記事のまとめ的な立ち位置として読んでいただけたら幸いだ。 Heroku で本番運用の実績 私は Heroku で 2年間以上、本番環境でサービスを動かし続けて来た。その間、Heroku 起因でトラブルに遭ったことは1日くらいで、他は安定的に動き続けてくれた。その1日も、いつもよりレスポンスが遅くなっていた程度で、なんとかなったので助かった。 さて、私がなぜ Heroku にこだわり続け
Heroku x Rails のサービスを本番運用する際に確認したいこと - ボクココ
ども、@kimihom です。 私は Heroku に Rails サーバーを立ててサービスを運用している。これまでの経験を元に、定期的にチェックしておきたい指標とか項目をまとめてみる。今後のサービス開発などで参考になれば幸いだ。 サービス構成 現在の構成はというと、以下のような感じである。 Ruby 2.4.1 (執筆時点で最新) Ruby on Rails 4.2.8 Heroku Standard 1X Dyno * 4 Heroku Postgres Standard 0 Heroku Redis Premium 0 もちろん他にも使っているのはいろいろあるけど、ベースは上記のように至って標準な作りになっている。これによってインフラ周りでトラブルが起きることを最小限にとどめている。今現在でもインフラ周りで特別に問題になっていることはないので、これからも 上記の構成を使い続けていく予
月額課金サービスをボクはこう設計した - ボクココ
ども、@kimihom です。 Stripe Meetup というのが渋谷の Tokyo Otaku Mode さんのオフィスで開催された。そこのイベントでサブスクリプション型サービスの設計について話をした。 speakerdeck.com こちらの内容は、以下の記事の続編的な感じとしてご紹介した次第である。 www.bokukoko.info 以下は補足 プランのプライシングは慎重に SaaS サービスをいくらで販売するか？ 実際に事業を始める上で重要だけど決めることは難しい。見込み顧客に「いくらなら買いますか？」と聞いてみたところ思っていたよりも安めの金額を言われたり、今後のスケールを考えれば安くてもなんとかなると思って、金額を安めに設定しがちだ。だけども、多くの SaaS サービスは料金設定をミスって(なのかは定かではないが)、あとで値上げするという手段を取る傾向があるようだ。 値上
月額課金モデルの Web サービスの設計方法 - ボクココ
ども、@kimihom です。 今回は月額課金モデルの Web サービスを実現したい企業向けに設計の参考になる情報を提供できればと思う。こういう情報は割と自分なりに設計して実装するっていうパターンが多いかと思うが、とても大事なことなので慎重に検討していこう。 決済サービスの選択 まずは決済サービスをどれにするかって話。ここで一番大事なのは、扱うカード提供会社の種類だ。 Visa, Master は当然として、その他のクレジットカード会社が使えるのかどうか。ここは顧客のカード登録の自由度を決めるので、実は決済手数料よりもよっぽど大事な項目になる。要チェックだ。 あとは企業によっては収益が出た後の支払いフローも確認しておいたほうがいいかもしれない。収益の確定はいつで、支払いはいつなのか。黒字倒産するほど急成長することは稀だとは思うが、そのあたりのキャシュフローも事前に把握しておく必要がある。
個人プロダクト開発の成功に必要なこと - ボクココ
ども、@kimihom です。 よくエンジニアと話していると、「~を作ろうと思ってるんだよね」とか「今 ~ を作ってるんだよね」とかそんな話をよく聞く。私はこれらの話を信じないようにしている。なぜなら、そのほとんどが情熱半ばで止まってしまったり、作ったとしても自己満のレベルで止まってしまったりするからである。 一人で作りきることができて、ユーザーに使ってもらえるレベルまで成長させるのは、当然ながら難しい。でも、そこまで行けばちゃんとそのアプリやサービスをメンテナンスしようと思うし、ユーザーからの声を聞くことになる。大変だけどもやりがいのある趣味になるし、収益化を狙うことだってできる。自己満で終わりじゃなく、みんなに使ってもらって満足させられたなら、開発者として幸せなことではないか。そこまでやって初めて、"個人プロダクト開発が成功した"と言えると考えている。 今回は、一人で色々なアプリケーシ
Amazon API Gateway Importer を使って Rails x Grape から API を生成する - ボクココ
ども、@kimihom です。割とマニアックな記事。 以前書いた Grape Swagger で Amazon API Gateway 連携 の記事では、 grape-swagger から Amazon API Gateway に乗せるまでの手順を書いた。 しかし、このままだと 結局 Amazon API Gateway 側で Integration Request, Integration Response を1つずつ定義しなければならず、開発中にAPIが変わるたびにデプロイするのが大変だった。そこで、今回は Amazon API Gateway Importer の中にある機能をフル活用して、API Gateway 側でほとんど設定することなしにデプロイできる環境を作ろうと思う。 前準備 さて、API Gateway 側の Integaration~ 系の設定方法のサンプルはaws-a
認証を含む API 開発で検討すべきこと - ボクココ
ども、@kimihomです。 API に関する基礎的な話で、なぜ API が重要なのか、APIの実装で注意する点について記述した。 今回はAPI開発において最も頭を悩ます、認証の問題について考えてみたい。 API における認証 よくあるログインが必要なページを考えてみていただきたい。 通常のWebアプリケーションであれば、Cookieという仕組みを使って毎回Webサーバーにアクセスするときにsession idというものを送信し、それとユーザー情報を紐付けたデータを取ってくることで、どんなユーザーからリクエストが来たのかをWebアプリケーション側で判断することができる。これにより、私たちはいつも閲覧しているWebアプリケーションが自分専用の画面として見れるようになっている。 これがAPIになると話は違ってくる。Cookieという仕組みが使えないのである。ということで、なんとかしてAPIにア
Amazon API Gateway で気になった機能をまとめてみる - ボクココ
今回の話題は つい先日出た Amazon API Gateway について。 あくまで自分が注目したところを読んでのできる範囲であるため、それ以外にもできることがあるだろう。詳細は、API Gatewayのドキュメントを読んでいただきたい。現在は英語のみのようだ。 AWS Lambda の呼び出しとレスポンスの受け取り AWS Lambdaを使えば、プログラミングしたコードをサーバーを立てずに動かすことができる。しかも料金は実行回数と実行時間に応じた課金のため、従来のずっと課金しっぱなしだった EC2などのサーバーを立てるやり方よりよっぽどコストを抑えられる。それでもって、できることは多い。普通のサーバーにNode.jsが入った感じで、外部ライブラリを取り込んだソースコードをAmazon Lambdaに配置することもできる。 設定はシンプルだった。呼び出し先に Lambdaを指定するだけで
私が実施する Heroku x Rails の高速化をまとめてみた - ボクココ
Herokuの欠点は、Tokyoリージョンがないため、ネットワークによる遅延が気になる と言われている。どの程度による遅延が気になっているのかは人によると思うが、Herokuを最大限に高速化させるために私がやっていることをまとめてみた。 これを実施すれば、Herokuが遅いとはあまり思わなくなると考えている。 Asset Sync を利用する [追記（重要）] Asset Syncを利用するのは公式で止めるよう勧告が出ている。CloudFrontを利用する方法が推奨されている。以下の内容は古いのでご注意を。 ーーーーーーーーーーーー Asset Syncは、Amazon S3に画像やCSS/JavaScriptを置き、各アセットのパスの向き先をそちらにかえてくれるgemだ。これを利用しないと、HTMLとかに置いた静的コンテンツが全てHerokuにアクセスしてしまうため、Herokuサーバー
rails-api は デフォルトの middleware に要注意 - ボクココ
いや〜ハマったハマった。 rails-api っていうフルスタックのRailsからAPIに特化した構成に削ぎ落としてくれるGemがあるんだけど、これで「何が削られているのか」をちゃんと把握してないとハマる。 基本的なRailsアプリとrails-api の Middleware 比較 rake タスクを実行すれば見れる。 フルスタック $ bundle exec rake middleware use ActionDispatch::Static use Rack::Lock use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x007fe29f9cc6e0> use Rack::Runtime use Rack::MethodOverride use ActionDispatch::RequestId use Rai
Railsのテスト,デプロイ,ドキュメント生成をBitbucket, Jenkins で行う - ボクココ
今回はJenkinsとBitbucket の連携をします。 Bitbucket はプライベートリポジトリを何個でも作れて、5人までなら無料で使えるという優れもの。少人数開発ならこれを使わない手はないです。 Github Enterprise だとお金かかる部分が浮きます。 さらに！ Wiki 機能もあり、今回はここに自動生成したドキュメントを反映できるようにします。 またJenkinsはどっかのリモートに置くとそれだけでお金がかかるし、無料のJenkins ホスティングサービスは柔軟性が無いので使いません。その代わりにしばらくはMacのローカルでJenkinsサーバを立てて運用していきます。 ローカルでJenkinsを立てると、Bitbucketへのフックができなくなるので、git push した瞬間にJenkinsを走らせる、みたいなことはできないのでご注意を。 やりたいこと Git p
ユーザ登録・API 認証の仕組みを Rails で実現する - ボクココ
スマホアプリから会員の新規登録、ログインが両方できるようにAPIを作成中。ようやく自前でアクセストークンを作ってOAuth認証が出来たのでまとめておく。 まず何がしたいか？ スマホアプリでAPI認証ができるように、OAuthを自前で作成したい。 -> スマホアプリ側ではユーザ名とパスワードを入力すればトークンが取って来れて、そのトークンで各APIにアクセスすればユーザ固有の情報が取って来れるようになる仕組みを作る。 スマホアプリ側でユーザ作成も出来るようにしたい。 -> APIでユーザが作れるようにする。もちろんhttps前提。 環境 gemfile ruby '2.0.0' gem 'rails', '4.0.0' gem 'rails-api' gem 'active_model_serializers' gem 'mongoid', '4.0.0.alpha1' gem "moped
理想的な Rails, AngularJS 環境の構築 - ボクココ
ネットでRails x AngularJSで調べると、AssetsにAngularJSを追加してやるのが普通的なことをよく見る。でも、この方法だとYeomanや、Grunt.jsが使えず、Rails x AngularJSでKarmaでテストを書いたりといったことができないし、AngularJSの作法にのっとった開発ができないのがとてもモヤモヤしていた。 てことで、もうこれはAsset Pipelineを使わない方向で行くのがベストなんじゃないのか、という方向で色々探し回っていたら、同じようなことを考えていた方がいたようで,これを参考にしてもっとベーシックな枠組みを作ってみた。 Asset Pipeline の機能が使えなくなる？ご心配なく。Grunt.jsがJSコードの圧縮、SCSS, CoffeeScriptのコンパイル、さらにLiveloadの恩恵, 画像の圧縮、テストの自動実行もで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
