Herokuで成功させるサービス開発 - ボクココ
ページ版執筆にあたって ども、@kimihom です。 技術書典5で販売した書籍の記事版として公開します。より多くの方へ Heroku でサービス開発を成功させていただきたいという思いから、ボクココの固定ページとして無償公開するに至りました。 なお、本記事は、Heroku 社から認められていない非公式の記事となります。予めご了承ください。 はじめに Happy Coding! 本記事はWebサービス開発を本気で成功させたいと考えているエンジニア向けに、サービス開発とHerokuの運用に関して記しています。サービス開発を成功させるには、限られた時間の中で注力すべき内容を見極め、サービスの差別化を推し進めることが重要です。ユーザーはなぜ他の多くのサービスではなくて、あなたが作ったサービスを使うのか。その問いに自信を持って答えられるようにしなければなりません。その状況の中で、どのテクノロジーを採
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 です。 エンジニアとしてやっていくと決めた時、意識していかなければいけないことはどんなことだろう？技術力はもちろん必要だけど、それを証明できるものを持っていないといけない。あなたがどれだけ技術があるのかを他人に示さなければならないからだ。エンジニアとして生存していくための戦略について考察する。 あなたなりのアウトプットを持とう 一昔前の考え方であれば、「資格」がこれに相当した。相応の資格を持っていれば、そのスキルを持っていると対外的に証明できるから、仕事に困ることはない。今でもそのような資格ベースで仕事の裁量が決まる業界は多いことだろう。 しかし、テクノロジーの世界ではそれは一つの参考程度に過ぎず、"めんどくさいお勉強がちょっとできる"程度にしか思われない傾向がある。特に技術の進歩は早いので、数年前に取った資格が、もはや必要のないものだったり、そもそもその技術が企業
月額課金モデルの Web サービスの設計方法 - ボクココ
ども、@kimihom です。 今回は月額課金モデルの Web サービスを実現したい企業向けに設計の参考になる情報を提供できればと思う。こういう情報は割と自分なりに設計して実装するっていうパターンが多いかと思うが、とても大事なことなので慎重に検討していこう。 決済サービスの選択 まずは決済サービスをどれにするかって話。ここで一番大事なのは、扱うカード提供会社の種類だ。 Visa, Master は当然として、その他のクレジットカード会社が使えるのかどうか。ここは顧客のカード登録の自由度を決めるので、実は決済手数料よりもよっぽど大事な項目になる。要チェックだ。 あとは企業によっては収益が出た後の支払いフローも確認しておいたほうがいいかもしれない。収益の確定はいつで、支払いはいつなのか。黒字倒産するほど急成長することは稀だとは思うが、そのあたりのキャシュフローも事前に把握しておく必要がある。
Web サービスは機能の多さで勝負してはならない - ボクココ
ども、@kimihom です。 近年はいろいろなサービスがあるが、サービス開発者の中で勘違いしやすいのが 「機能は多ければ多いほどいい」「他社サービスがこんなことやってるからウチもやらないと」「お客さんがこんなこと言ってるから実現しないと」 といった考え方だ。自分たちのサービスにその機能は本当に必要なのかを考えず、ただ闇雲に機能を追加していく。その行く先にあるのは「複雑で、誰も使いたがらないシステム」である。理解するのに、慣れるのに何日間もかかるようなシステムを誰が喜んで使いたいだろうか？残念ながら、今の日本のサービスはそんなのばっかりだ。 なぜこのような考え方が生まれるのか 機能を闇雲に追加していくことのメリットは、「自分が何も考えなくてもいい」ということだ。他社のを参考に、ユーザーの意見を参考に言われるがままにパクって作ればいいだけなのだから。多少は自分たちのサービスっぽくカラーを添え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
