Heroku で本番運用を続けていくために必要なこと - ボクココ
ども、@kimihom です。この記事は Heroku Advent Calendar 2017 の 20日目です。明日以降が豪華メンツで今から楽しみですね。 さて、今回は Heroku で本番運用を続けていくって方のための情報をシェアしたいと思う。自社サービスで Heroku を使い続けている事例ってのがあまり出て来ないので、積極的に開示していきたいと思う。 ※ 本記事は、今年書いた Heroku に関する記事のまとめ的な立ち位置として読んでいただけたら幸いだ。 Heroku で本番運用の実績 私は Heroku で 2年間以上、本番環境でサービスを動かし続けて来た。その間、Heroku 起因でトラブルに遭ったことは1日くらいで、他は安定的に動き続けてくれた。その1日も、いつもよりレスポンスが遅くなっていた程度で、なんとかなったので助かった。 さて、私がなぜ Heroku にこだわり続け
起業はスタートアップだけのものではない - ボクココ
ども、@kimihom です。 インターネット企業としてサービスを作って、自分の作ったサービスで食っていく。ってなったときに、皆さんなら起業してどのようにやっていくか？このとき、特に学生など若い人はピッチをして投資家から資金を得るという方法を最初に知ることだろう。 実際、そのくらいしか方法がないと思い込んでいる方が多いようなので、今回はそれ以外の選択肢があって、それも大変魅力的であるということを伝えるためにこの記事を書いている。その方法こそ、Bootstrap と呼ばれる企業形態だ。 先日、Boostrap に関して以下のようなイベントを開催した。オフィシャルな内容は以下にまとまってるので、こちらを参照いただきたい。 www.selfree.co.jp Bootstrap という起業形態 Bootstrap は、自己資金でサービスを立ち上げて、顧客から得たお金で会社を回すという実にシンプル
少数精鋭チームでサービス開発を続けるためのヒント - ボクココ
ども、@kimihom です。 最近は色々な企業がサービス開発は少人数でやる方がいいことに気付き始めて実践しているように見受けられる。もちろん、最初の 0->1 フェーズでは設計して開発するだけなので誰でも少人数で開発していけるだろう。しかし問題はその後でサービスを公開してユーザーが増えてきたときに人が足りないみたいな状況になってしまってどんどん人を増やしてしまうケースが見受けられる。本記事では少数精鋭チームで開発を続けられるようにするためのヒントを記していく。 問い合わせを減らそう サービス公開してユーザーがどんどん増えてきたときに、問い合わせがそれに比例して増えていくようでは、当然のことだけど運営側も人が必要になってくる。問い合わせ、つまりユーザーが疑問に思ってしまう点をいかに減らしていくかが少数精鋭を続けるために重要な点となる。 そのためには、ユーザーを悩ませないサービスを目指してい
キミは本当の MVP を作れるか - ボクココ
ども、@kimihom です。 新サービス開発においてよく言われる “MVP (Minimum Viable Product)” ってのがあるけど、これを本当に実践できている人はどのくらいいるのだろうか。 今回はよくある勘違いと私の考える正しい MVP の作り方について記していきたい。 とりあえず最小限の機能を作って出す MVP は言葉の通り「最小限の機能を持ったプロダクト」だ。とりあえず最小限の機能を作って出すってところまでは特に誰でも問題なくできるだろう。 しかし大事なのはそこからで、もしMVPの検証でターゲットに確実に刺さっているものでないと分かれば、ゼロから作り直すって判断が必要だ。しかし実際は「この機能修正/追加によって対応しよう」レベルの判断になってしまうことが多いのではないだろうか。もはやそれは MVP ではない。そういった安易な判断をしてしまうと、本当に顧客の望むものをいつ
Node.js Express で非同期処理を next で対応する方法 - ボクココ
ども、@kimihom です。 今回は Node.js の Express を使った場合の非同期処理のスマートな対応方法をご紹介する。 Node.js の非同期処理の重要性 簡単な比較をすると、Ruby では非同期処理をほとんどしない代わりに、それぞれのリクエストの一連の処理がが終わるまでサーバーはそのために仕事をする。例えば、DB の読み書きの処理は ActiveRecord を使うが、そこで DB との接続をして処理が終わるまでサーバーの一つのリソース(プロセス)は占有されることになる。これはこれでシンプルなコーディングができるので良いのだけど、処理効率という観点ではあまりスマートな方法ではないと言われている。 Node.js でプログラムを書いていると、DB処理を含めたあらゆる処理が非同期となる。これによってより多くの処理を1つのサーバーで処理することが可能になる。しかし、JavaS
Heroku Strike のイベントに行ってきたレポ - ボクココ
ども、@kimihom です。 Heroku UG で定期的に開催している Heroku Meetup に行ってきたのでそのレポ。今回はがっつり Heroku を使っている方々の運用事例だったり、Heroku を選択する理由、Heroku の最新機能など盛りだくさんの内容だったのでブログに書くしかないと感じたので早速記事にする。 Heroku Meetup #17 Heroku Strike - Japan Heroku User Group | Doorkeeper Node.js や PHP でもこわくない Heroku まずはお世話になっている 10madoの山岡さんの登壇。ちょっと前までは “Heroku = Ruby” な印象が強かったけど、今では Node.js や PHP でも不自由なく使えるようになっていて、実際に 別言語プラットフォームで運用している事例を紹介していただい
WebRTC における通信不具合の検証 - ボクココ
ども、@kimhom です。 以下のイベントで LT してきたので、今回はスライドとともに補足していく。 atnd.org WebRTC チェックサイト まず利用環境で WebRTC が使えるかどうかというそもそもを確認するには、実際に WebRTC に繋いでみる。弊社で実際に Twilio WebRTC に繋いでみるチェックツールを提供している。 Twilio Client 動作チェック 上記は Twilio Client の WebRTC に最適化されているので、一般的な WebRTC チェックツールは WebRTC 本家が提供しているのを使うのがセオリーになるだろう。 WebRTC Troubleshooter このサイトの注意点として、上記サイトでわかるのは「全く通話できないか、そうでないか」の分類になるということ。音質の不具合などを上記のようなサイトで発見することは難しい。んで、
エンジニアがゼロからサービス立ち上げするメリット - ボクココ
ども、@kimihom です。 Web エンジニアの中で、案外ゼロからサービス立ち上げを経験したことのある人って少ないのかもしれない。大抵は企業に就職して、既にある成功したサービスの運営や新機能、他プラットフォームへの対応などをやることが多いかと思う。 そのような既にあるサービスを拡張する 10->100 のフェーズでは体験できない 0->1 フェーズについてのメリットについて語らせてもらう。 胸を張って自分の作ったサービスだと言える 単なる気持ちの問題だけど割とこれって個人的には大事で、誰かが作ったサービスをメンテしてます程度だとそのサービスに対して100%の情熱を注ぐことは難しい(あくまで私の場合)。100%の情熱が注げないとどうなるかというと、コードの品質に妥協が入ったり、第三者の意見をハイハイ言って実装するだけのイエスマンになりがちだ。 自分の作ったサービスで、思い入れがかなりある
ログベースのメトリクスサービスの魅力 (Heroku ユーザー向け) - ボクココ
ども、@kimihom です。 今回はログベースでの解析に関して調べたことをまとめてみる。Heroku に関連する範囲で調べたので、 Heroku ユーザーには最適かと思う。 ログベースのサービス 例えば、メトリクスサービスで有名な以下のようなサービスは、既にメトリクス内容が決まっている場合にのみ有効に活用できる。 Google Analytics などの JavaScript 埋め込み型ツール NewRelic などのサーバー埋め込み型のモニタリングツール 上記の提供するコードをアプリケーションに埋め込むことで、何もしなくても必要な情報をそれなりに収集してくれるようになる。しかし、メトリクスサービスの提供する範囲までしか収集することができないので、例えば独自の項目(サインアップ回数や金額など)を集計したいって時にはまた他のサービスを探すか、手動でデータベースにアクセスしてエクセルを更新す
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 もちろん他にも使っているのはいろいろあるけど、ベースは上記のように至って標準な作りになっている。これによってインフラ周りでトラブルが起きることを最小限にとどめている。今現在でもインフラ周りで特別に問題になっていることはないので、これからも 上記の構成を使い続けていく予
SaaS のプラン料金設定の勘所 - ボクココ
ども、@kimihom です。 最近は SaaSの料金設定について考えることが多いのでこの辺でまとめてみようと思う。 あらゆる規模に適した料金となっているか 各 SaaSにはそれぞれターゲットがいる訳だけども、それに見合った顧客だったとしても規模が 3人だったり50人だったりすることはよくある。その中で3人でも50人でも公平に課金がされる仕組みがあるといいと考えている。 これに対する一番簡単な解としては、1人~円と料金設定する方法だ。そうすれば明確に規模の増減に応じて公平に課金が行われる。特にこの方法で問題がない場合は、人数分の課金にするのが素直な方法だ。 ただし、そうはいかないケースがあったりする。例えばその SaaS が多くの人が使われてこそ価値を生むようなサービスの場合だ。その場合に都度料金が上がってしまうようなら、多くの人に使ってもらうようにする仕組みを作ることができない。となると
Netflix で英語リスニング訓練 - ボクココ
ども, @kimihom です。 映画やドラマが定額で見放題でおなじみ Netfix 。海外発のサービスてことで当然アメリカの映画やドラマが数多く提供されている。Netflix を使いながら英語学習のために映画視聴をした報告を軽くしようと思う。 正直なところ、リスニング力の向上はまだ見られず 週末にひたすら見ることを始めて3週間ほど経ったが、まだまだネイティブの英語を聞き取るには困難な状況であることには変わりない。英語を"読む"ことから訓練を始めてしまったので、英語を聞くとまずは頭の中で"英文"に書き起こし、それを"文法"的に意味を解釈して、さらに場合によっては日本語に"置き換えて"イメージする手順を踏んでいるため、速い英語の口調で話されると一気に理解できなくなる。英語のテストレベルだったらこれでも何とかなっていたが、ネイティブ英語でこの作戦は不可能だ。 本来は、"英語の音"だけで言ってい
Web サービス開発に必要な技能について - ボクココ
ども、@kimihom です。 先日とある雑誌の記者さんから取材を受けて、自分のスキルについて色々と聞かれた。私自身は何かに特化したスペシャリストというよりも、あらゆることが一人でできるジェネラリストの部類である。前回の記事では web サービスのアイディアについて必要なことを書いたが、今回はそのアイディアを実現するためのジェネラリストとして必要な技能について紹介する。 www.bokukoko.info 俗にいう"有名エンジニア"の方々は何かの技術に特化したスペシャリストである場合が多いので下記の事項には当てはまらない。あくまでこれは1人のエンジニアとしての参考情報にすぎないことに注意していただきたい。 一人でサービスを作りきる能力を磨く 何かに特化したスペシャリストの人が、 CSS でデザインを整えたりすることとサーバーの負荷監視などをすることを同時に行うことは困難だ。だけども、ジェネ
開発手法を学ぶことに意味を感じない件について - ボクココ
ども、@kimihom です。 開発手法について議論されたり、発表するような場があったりする。例えば “弊社ではアジャイル開発手法を用いて最先端の開発を実践しています。” 的な話ね。最近はアジャイルじゃなくて何て言うのかよく知らないけども。 それらの話に関してなぜ私が意味を感じないと思うのかを書いていこうと思う。 事前に一つ注意していただきたいのは、私は開発手法に関する話は1,2冊程度しか読んだことがない。だから開発手法を極めればこんなことができるようになる！みたいなのは是非教えて欲しい。開発手法に関する本を読んで、それが全く見えなかったから興味が沸かなかったので。 それより実際に開発しようぜ 基本的にあまり開発をしない方々が、開発手法に関して話しているような感じがする。開発しない立場でチームの開発をとりまとめる立場であるために、何か良い方法を模索している感が漂ってくる。はて開発手法通りに
コードを美しく保つためのたった一つの方法 - ボクココ
ども、@kimihom です。 とあるイベントでエンジニアの方々と話していて話題になった “クリーンなコード” について書いていくとする。 結論から言うと、コードを書かない のが最も美しく保つための条件だと考える。 サービス設計レベルでの"美しさ" を極めよう いくら優秀なエンジニアがサービスを作ったところで、優秀でないプロダクトマネージャーの元で開発をしてはいいコードを保つことはできない。優秀でないプロダクトマネージャーは、機能の多さで他社と差別化をしたり部下の仕事を作ろうとする。この機能が他社サービスにはあるから、うちにも取り入れよう。そんな自社サービスの思想を全く考えない機能をエンジニアに要求するのだ。 その時点で、どんな優秀なエンジニアでも作ったシステムは確実に複雑になる。例えて言うなら、小説家が１冊の本の中にうまく章立てをしてまとめていたのに、全く別の話題をその本に書けと言われて
WebRTC の Media, Stream, Track について - ボクココ
ども、@kimihom です。 最近の週末は Twilio Video を使ってビデオ通話アプリケーションを作成している。Twilio Video は今どんどん進化していて、単なる2,3 人でのビデオ通話をするにとどまらず、面白いことができるようになっている。特にスクリーンシェアの機能を Chorme 拡張機能を使うことで Twilio Video でもデスクトップ画面共有のアプリケーションが作れてしまう。ちなみにデスクトップ画面共有のドキュメントは1週間前に出たばかりなので、最新情報だ。 さて、この デスクトップ画面共有の概念を理解しようとすると、途端に WebRTC の Media, Stream, Track というそれぞれわかりづらい概念をそれなりに理解しなければならなくなる。今回は自分なりに勉強して理解したことをまとめようと思う。 Media, Stream, Track 最初に
新技術とどう向き合うかについて - ボクココ
ども、@kimihom です。 テクノロジーの進化は速く、追いついていくのは大変だ。全部を完璧に吸収するってのは理想ではあるが、当然のことながら一人では限界がある。私たちはどう新技術と向き合えば良いのだろうか？ 今回は私の思う技術を見極める方法について書いていこう。 ちなみに私はどちらかと言うと新しくサービスを作る側のエンジニアであり、何かに特化するスペシャリスト側のエンジニアではない。その目線からの話である。 その技術は本質的に “新しいか” 私は何か技術が生まれた時に、"その技術は本質的に新しいか" を見極めるようにしている。よくある新技術として、以下のような例があるだろう。 新しい技術分野 新しい仕様 新しいプログラミング言語 新しいフレームワーク 新しいミドルウェア 新しいインフラストラクチャ 新しい設計思想 さて、同じタイミングでガッと色々と出てきた時、何を選ぶだろうか。 もちろ
初めて給料が出た日 - ボクココ
ども、@kimihom です。 私の会社は外部から一切資本を受け入れず、また借り入れも一切しない経営(ブートストラップと呼ぶ)をし続けてきている。さらに受託開発を一切せず、自社のクラウドサービスにフォーカスし、ひたすらサービスの改善とサポートを続けてきた。 そして2017年1月10日の今日、初めて給料が出た。起業してから2年9ヶ月目での出来事である。 顧客が自社サービスを使ってくれて、支払っていただいたお金がそのまま給料として得られるようになったというのは、私にとってかけがえのないことだ。給料が出る状態になったということで、もはや新規顧客獲得を意識する必要はなくなった。サービスを使っていただいている顧客が満足して使い続けていただけるようなサービスを提供し続けることだけにフォーカスすることができる。"第三者" からとやかく言われることなく、自分たちと顧客の幸せだけ に力を注げる状態になった。
Rails の フロントエンド周りの未来予測 - ボクココ
ども、@kimihom です。 Rails の Sprockets や Uglifier などが最新の JavaScript に追従していないという理由で、Rails 標準のやり方から外れて最新のフロントエンドツールを追い求める系の報告が多い。一部では完全に Rails の Asset Pipeline から外れて、Gulp などに移行する話もよく聞く。確かに現行の Rails のフロントエンド環境で開発すると、let や クラス構文をまともに使えない(エラーになる)ため、最新の構文に対応した JavaScript フレームワークはほとんど使えないのは大きな問題として残り続けている。 最新版である Rails 5.1 から、ようやく jQuery からの脱却とフロントエンド周りの最新化、つまり Yarn や Webpack の導入が検討され始めている。これに期待されている方も多いのではない
個人プロダクト開発の成功に必要なこと - ボクココ
ども、@kimihom です。 よくエンジニアと話していると、「~を作ろうと思ってるんだよね」とか「今 ~ を作ってるんだよね」とかそんな話をよく聞く。私はこれらの話を信じないようにしている。なぜなら、そのほとんどが情熱半ばで止まってしまったり、作ったとしても自己満のレベルで止まってしまったりするからである。 一人で作りきることができて、ユーザーに使ってもらえるレベルまで成長させるのは、当然ながら難しい。でも、そこまで行けばちゃんとそのアプリやサービスをメンテナンスしようと思うし、ユーザーからの声を聞くことになる。大変だけどもやりがいのある趣味になるし、収益化を狙うことだってできる。自己満で終わりじゃなく、みんなに使ってもらって満足させられたなら、開発者として幸せなことではないか。そこまでやって初めて、"個人プロダクト開発が成功した"と言えると考えている。 今回は、一人で色々なアプリケーシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
