Herokuで成功させるサービス開発 - ボクココ
ページ版執筆にあたって ども、@kimihom です。 技術書典5で販売した書籍の記事版として公開します。より多くの方へ Heroku でサービス開発を成功させていただきたいという思いから、ボクココの固定ページとして無償公開するに至りました。 なお、本記事は、Heroku 社から認められていない非公式の記事となります。予めご了承ください。 はじめに Happy Coding! 本記事はWebサービス開発を本気で成功させたいと考えているエンジニア向けに、サービス開発とHerokuの運用に関して記しています。サービス開発を成功させるには、限られた時間の中で注力すべき内容を見極め、サービスの差別化を推し進めることが重要です。ユーザーはなぜ他の多くのサービスではなくて、あなたが作ったサービスを使うのか。その問いに自信を持って答えられるようにしなければなりません。その状況の中で、どのテクノロジーを採
PostgreSQL の JSONB 型の紹介とメリット - ボクココ
ども、@kimhom です。 今回は必要に駆られて PostgreSQL で新しく登場した JSONB 型について調べるきっかけがあったので、まとめてみる。 予め断っておくと JSONB 型はいわば PostgreSQL のリレーショナルデータベースからの脱却だ。これは一見魅力的に見えるけど、誰もが待ち望んだ機能というわけではない。導入するときは慎重に検討するようにしたいところだ。 なぜ JSONB 型が必要になったか 特に SaaS のアプリケーションを作っている方なら共感してくれると思うのだけど、保存したいデータが顧客によって異なるというケースが否応にしてある。例えば 顧客管理のサービスを扱っているなら、業界ごとに保存しなければならない項目(本記事ではカスタム項目と呼ぶ)は異なってくるし、逆に不要な項目なども出てくることだろう。そんな中、最もやってはいけない妥協が、とりあえず全ての項目
サービスローンチ後から始めるべき布教活動 - ボクココ
ども、@kimihom です。 サービスをローンチしてから最初の有料顧客が来るまでには長くの時間を要する。サービス開発の時間をかけた分だけ、この時間は辛く長く感じることだろう。ローンチから1年以上経ってようやく有料顧客を見つけたというケースも少なくない。 そんなサービス開発における"迷える期間"で、コツコツとやっていくべきだと考えているのが「布教活動」である。今回は私の具体例を交えながら、説明していく。 コアなファンはサービスの Why に共感する 最初の顧客をいかに満足して使ってもらい、そのあと使い続けてくれるか。そして顧客が他人へ紹介してくれるようになるのか。単にサービスを使ってくれる顧客ではなく、ファンになってもらえるようにしなければ、その先のサービスの成長を得ることはできない。 サービスのファンになってもらうには、私たち運営者は Why (なぜそのサービスを作ったのか、存在するのか
Ruby on Rails の魅力と思想 - ボクココ
ども、@kimihom です。 私は Web フレームワークは Ruby on Rails を利用している。かれこれバージョン2.2 の頃から使い続けているので 7年以上になる。そこまでして私が Ruby on Rails を使い続ける魅力について個人的な想いを記していく。 Rails の作者 DHH と彼の環境 Rails の作者として有名な DHH(David Heinemeier Hansson) という名前は、 Ruby on Rails を触ったことがあるなら必ずや聞いたことがあるだろう。しかし、彼のいる会社 Basecamp がどんな想いでどんなことをしているかを知っている人は案外少ない。 Basecamp はプロジェクト管理の SaaS である。今や世界中に顧客を抱える超有名サービスであり、Basecamp は Ruby on Rails の最新版をプロダクトに反映され続けて
アプリの個人開発の終焉と新たな可能性 - ボクココ
ども、@kimihom です。 今回は私が今まで開発して来た個人開発と、そこで学んだ次の可能性について記していく。 個人で開発したアプリで食っていく 今でもちょくちょく個人開発をしている方をよく見かける。安定した仕事に勤めていた頃、私もその個人開発者のうちの一人だった。週末や空き時間があれば、ひたすらスマホアプリを開発し、私が作ったアプリの合計は十数個にのぼる。最初はゴミみたいなアプリを量産してたわけだけど、経験を積むにつれていいアプリを作る感覚を持てるようになって、１つだけ当たったアプリ(個人開発で15万DL 超えのアプリ)を作ることができた。この"当たるアプリを作る感覚"ってのは、アプリのアイディアそのものであったり、開発だけでないデザインやストアに掲載する文言やSEO、シェアされる仕組み、その他運用テクニックなど多様なものだ。 個人開発を可能にした背景に、スマートフォンアプリの流行が
認証を含む API 開発で検討すべきこと - ボクココ
ども、@kimihomです。 API に関する基礎的な話で、なぜ API が重要なのか、APIの実装で注意する点について記述した。 今回はAPI開発において最も頭を悩ます、認証の問題について考えてみたい。 API における認証 よくあるログインが必要なページを考えてみていただきたい。 通常のWebアプリケーションであれば、Cookieという仕組みを使って毎回Webサーバーにアクセスするときにsession idというものを送信し、それとユーザー情報を紐付けたデータを取ってくることで、どんなユーザーからリクエストが来たのかをWebアプリケーション側で判断することができる。これにより、私たちはいつも閲覧しているWebアプリケーションが自分専用の画面として見れるようになっている。 これがAPIになると話は違ってくる。Cookieという仕組みが使えないのである。ということで、なんとかしてAPIにア
Web サービスを自力で作る上で大事な考え方 - ボクココ
ども、@kimihom です。 “最近Webサービスを気軽に作ることができなくなった気がする” 流れがある中で、私はどんどんサービスを作っていけ派な人間なので、一言書いておきたいと思う。 開発するネタが出尽くしたことが一つの要因 ちょっと昔は、基本的に「ユーザーがログインして、データベースに書き込んで、それを見る」みたいなだけのサービスでも、業界やユーザーを絞ることで成功させることができた。最近の勢いに乗ってる企業も、基本的に大した技術は使っていない。それでもちゃんとサービスを運営する体制が整えば、軌道に乗せて成功させることはできた。 これから「ユーザーがログインして、データベースに書き込んで、それを見る」だけの発想でサービスを作ったとしても、既視感たっぷりなサービスが出来上がってしまう。基礎的な技術ベースで作られたサービスってのは、他の誰かがもう考えて作ってしまっている。 こんな状況でも
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 サービスは料金設定をミスって(なのかは定かではないが)、あとで値上げするという手段を取る傾向があるようだ。 値上
コードを美しく保つためのたった一つの方法 - ボクココ
ども、@kimihom です。 とあるイベントでエンジニアの方々と話していて話題になった “クリーンなコード” について書いていくとする。 結論から言うと、コードを書かない のが最も美しく保つための条件だと考える。 サービス設計レベルでの"美しさ" を極めよう いくら優秀なエンジニアがサービスを作ったところで、優秀でないプロダクトマネージャーの元で開発をしてはいいコードを保つことはできない。優秀でないプロダクトマネージャーは、機能の多さで他社と差別化をしたり部下の仕事を作ろうとする。この機能が他社サービスにはあるから、うちにも取り入れよう。そんな自社サービスの思想を全く考えない機能をエンジニアに要求するのだ。 その時点で、どんな優秀なエンジニアでも作ったシステムは確実に複雑になる。例えて言うなら、小説家が１冊の本の中にうまく章立てをしてまとめていたのに、全く別の話題をその本に書けと言われて
Web サービスは機能の多さで勝負してはならない - ボクココ
ども、@kimihom です。 近年はいろいろなサービスがあるが、サービス開発者の中で勘違いしやすいのが 「機能は多ければ多いほどいい」「他社サービスがこんなことやってるからウチもやらないと」「お客さんがこんなこと言ってるから実現しないと」 といった考え方だ。自分たちのサービスにその機能は本当に必要なのかを考えず、ただ闇雲に機能を追加していく。その行く先にあるのは「複雑で、誰も使いたがらないシステム」である。理解するのに、慣れるのに何日間もかかるようなシステムを誰が喜んで使いたいだろうか？残念ながら、今の日本のサービスはそんなのばっかりだ。 なぜこのような考え方が生まれるのか 機能を闇雲に追加していくことのメリットは、「自分が何も考えなくてもいい」ということだ。他社のを参考に、ユーザーの意見を参考に言われるがままにパクって作ればいいだけなのだから。多少は自分たちのサービスっぽくカラーを添え
勉強会・ハッカソン運営者の皆様、参加には料金とるか審査制にしてください - ボクココ
私は勉強会に参加するのが好きだ。色んなその分野を極めた方と情報交換して、考え方や行動に得られるものがある。いろいろ話を聞いて感銘を受け、実際に行動に移したこともある。 しかし、現在の勉強会やハッカソンが誰でも無料で参加できることで、私はそれらの会に行くことが厳しくなっている。誰でも参加できることが生まれる悲劇である。以下、私が遭遇した問題について記す。 別の目的で勉強会に来る人がいる 勉強会ってのは情報交換が目的であるのに、その技術に意欲や興味すらないし、そもそもエンジニアでない人が勉強会に来ることがある。そうした人の目的は、"タダで食べられる懇親会"と、"タダで働いてくれるハッカソン用 労働力の確保"である。 ハッカソンでエンジニアに働かせ、企画とプレゼン以外は何もしない。それでイベントに勝って自分の成果とし、いかに自分がすごいかを周りに伝え、次なるハッカソン用エンジニアの獲得に向け日々
スタートアップは始めてから3年間は投資を受けるべきではないと思う - ボクココ
ども、@kimihomです。 最近のスタートアップと言われると、どんなイメージを持つだろうか？ 大抵の方々はメディアを通じてでしかスタートアップを知らないから、「〜百万の資金調達」とか、「〜コンテストで優勝」だとか、そんなニュースしか聞かないと思う。彼らは大きくスポットライトを浴びている。自分もいつかはああなりたい。そう思っている方もいるかもしれない。 今回はそんなトレンドに一言申したい。 "スタートアップを始めるなら、投資を受ける" みたいな風潮が当たり前になってきたのはいつからなのだろう？ 最近はあらゆる投資部門が立ち上がり、日々次なるスタートアップを探し当てている。そして投資家が審査員のコンテストで、投資関連先の企業を優勝させて知名度アップさせる。スタートアップコミュニティが出来上がり、熱い場を作り上げている。 本当に成功した企業を思い浮かべてほしい。Google, Apple, A
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
