ども、@kimihom です。 ついにこの記事を書ける日が来たことに喜びを感じる。今回は運営する SaaSを Heroku Enterprise へ移設したので、その道のりと移すことで得られた結果について記す。 Heroku Enterprise 移設のきっかけ まず、Heroku Enterprise 導入にあたって一番ハードルにあるであろう、「お金面のクリア」が必要なことは正直に記しておこう。今回の場合、移設前と比べて3倍近く金額がかかっている。私自身、長年 Heroku を使い続けてきたコアユーザーではあるが、やはりこの金額面から Heroku Enterpise は最初から "ないな" と思ってしまい、詳しく調査すらしてこなかった。 しかし時は流れ、お陰様で私の運営する SaaS は多くのお客様に利用いただけるようになり、費用をかけてでも更に高性能で信頼性のあるサーバーにしたいとい

ども、@kimihom です。 この記事は Heroku Advent Calendar 2018 の 24日目の記事です。 heroku Advent Calendar 2018 - Qiita SWTT 2018 の資料 Salesforce World Tour Tokyo 2018 で Heroku について熱く語らせていただいたので、今回はそのことについて記す。Heroku を知っていて少しくらいは使ったことがあるという方を想定した資料である。 speakerdeck.com 誰もが PaaS で開発できる時代へ。 このセッションで一番いいたかったことは、「Heroku は一部の個人開発者やスタートアップのみで使われている印象が強かったが、今ではどの規模の企業でも利用できるプラットフォームになっている」という点だ。 数年前に Heroku を触ったっきりの方は、ここ数年の Her

ども、@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 です。 SaaS(Software as a Service) 界隈でよく言われるカスタマイズの是非について。 顧客ごとに最適なアプリケーションを用意(カスタマイズ)してしまうと、そのための改修や運用コストなどで今後のサービス改善に支障をきたすなどの理由でカスタマイズは悪とされている。本記事ではこのカスタマイズに関する持論を記そうと思う。 カスタマイズのジレンマ 「カスタマイズは一切しないで小規模向けのみでサービスをずっと運用し続ける」って意見なら、カスタマイズは一切しないという方針で良いと思う。しかし、ほとんどの SaaS スタートアップの場合、実際に資金調達を受けて顧客を大規模事業向けにまで増やしていかなければならない。顧客の組織が大きくなればなるほど、このカスタマイズが必要なケースはどんどん増えていく。そこでカスタマイズを一切受けなかったスタートアップは、大規

ども、@kimihom です。 今回は Heroku Meetup#18 で LT してきたので、その内容と発表後記的な感じでまとめてみる。前に書いた記事を基にしているので、被る部分もいくつかある。 LT 登壇資料 まずは以下の資料をざっと見て欲しい。言っていることは至ってシンプルな内容である。 顧客がブランド名を聞いて思い浮かべるのは極わずか パッと有名なブランド「ディズニー」 や 「Starbucks」 などを聞いて皆さんは何を思い浮かべるだろうか？きっと1つもしくは2つのことだけをイメージしただろう。各ブランドは当然、その他にも色々なビジネスをやっているだろうし商品を販売している。だけども、ブランド名を聞いて、それが良いか悪いかは象徴的な数個の特徴だけをベースに判断されるのである。 当然、私たちがこれから作る新しいサービスも同じ運命にある。どんなに色々な機能を作っても、顧客がそのサー

ども、@kimihom です。 “最近Webサービスを気軽に作ることができなくなった気がする” 流れがある中で、私はどんどんサービスを作っていけ派な人間なので、一言書いておきたいと思う。 開発するネタが出尽くしたことが一つの要因 ちょっと昔は、基本的に「ユーザーがログインして、データベースに書き込んで、それを見る」みたいなだけのサービスでも、業界やユーザーを絞ることで成功させることができた。最近の勢いに乗ってる企業も、基本的に大した技術は使っていない。それでもちゃんとサービスを運営する体制が整えば、軌道に乗せて成功させることはできた。 これから「ユーザーがログインして、データベースに書き込んで、それを見る」だけの発想でサービスを作ったとしても、既視感たっぷりなサービスが出来上がってしまう。基礎的な技術ベースで作られたサービスってのは、他の誰かがもう考えて作ってしまっている。 こんな状況でも

ども、@kimihom です。 テクノロジーの進化は速く、追いついていくのは大変だ。全部を完璧に吸収するってのは理想ではあるが、当然のことながら一人では限界がある。私たちはどう新技術と向き合えば良いのだろうか？ 今回は私の思う技術を見極める方法について書いていこう。 ちなみに私はどちらかと言うと新しくサービスを作る側のエンジニアであり、何かに特化するスペシャリスト側のエンジニアではない。その目線からの話である。 その技術は本質的に “新しいか” 私は何か技術が生まれた時に、"その技術は本質的に新しいか" を見極めるようにしている。よくある新技術として、以下のような例があるだろう。 新しい技術分野 新しい仕様 新しいプログラミング言語 新しいフレームワーク 新しいミドルウェア 新しいインフラストラクチャ 新しい設計思想 さて、同じタイミングでガッと色々と出てきた時、何を選ぶだろうか。 もちろ

ども、@kimihom です。 スタートアップをうまく成功させるには、 スタートアップはスケールしないことをしよう ということはとても大事だと思う。スケールしたいんだけどあえてスケールしない努力をすることで、今後のスケールを実現することができるのである。そのことについて理解を深めたい場合は以下のスライドがとても参考になる。 マーケティングを捨てよ、サポートへ出よう　事例から見るスタートアップ初期におけるユーザー獲得 from Takaaki Umada www.slideshare.net 端的に言うと「スタートアップにマーケティング担当者は害。いない方がマシ」っていうことだ。となるとエンジニアとかデザイナーみたいな直接プロダクトを改善していくような立場じゃない人は、人々の話を聞きに行ったりすることになる。 ではエンジニアはどうすべきか？ 今回はスタートアップエンジニアにおいて、"やるべき

ども、@kimihom です。 Rails5.0 の正式版がついにリリースされた。 Riding Rails: Rails 5.0: Action Cable, API mode, and so much more Rails 5といえば、 ActionCable での WebSocket によるサーバープッシュのリアルタイム処理が注目されがちだが、個人的には今後のシステムの開発指針を Rails が示した重要なリリースになっていると感じている。その原動力となっているのが、 あの "Turbolinks" だ。 マルチプラットフォーム開発に対する提案 ではどんな話かっていうと、まず Rails としては JavaScript で複雑なロジックをたくさん書いたり状態を管理するような処理を書かないことを選んでいる。以下の動画は今後の Rails において非常に重要な意味を持っている。 Rail

ども、@kimihom です。 今回はライフスタイルについて書いてみる。 ウチの会社は 3人という必要最低限のメンバーで CallConnect を運営している。3人が意思決定においてもっとも早く決められるし、情報共有も一瞬で全員に伝わる。全員が当事者意識を持つことのできる最高の人数は3人だと今でも思う。そんな中で 3人のうち1人がリモートワークをしてしまうと他のメンバーに影響が出るのではないかって指摘があるけど、そこの課題をどうやってクリアしているのかをシェアする。 フェーズに応じたリモートワークとオフィスワーク "フェーズに応じた"とは開発におけるフェーズの話だ。例えばじっくりと話し合いが必要な設計やテストなど、対面で会って話した方がいい時は必ず3人で話し合うようにしている。その方が早いし付箋などを使って考えをまとめることができる。さらに特殊なテスト項目とかを実施する際には隣同士でやっ

ども、@kimihomです。 皆さんは新しい技術が出てきた時に、どうやってそれを学ぶだろうか？ 大きく分けて2つあるあだろう。まず一つは「体系的に学んでから始める方法」、そしてもう一つは「いきなり使って作り始めてみる」だ。今回はこのことについて思うことを書いてみる。 その技術をなぜ学ぶのか、しっかり検討しよう まずその前に、なぜそれを学ぶ必要があるのか、について。エンジニアは技術を学び続ける必要があるとはよく言われるが、それでも技術なんてとてもじゃないけど全部マスターするのは不可能だ。そんな中で自分が何を学ぶべきか、取捨選択する必要がある。 今後の自分のキャリアを見越して選択するのか、目の前の仕事で使ってるから学ぶのか、それとも自分の実現したい未来のために選択するのか。それらを加味した上で検証しないといけない。 "廃れていたのを頑張って勉強しちゃって損した" とは実際そういう経験をするとそ

本ブログで度々紹介している AWS Lambda。改めてもう一度解説すると、コード(Node.js or Java)を実行する環境をAWS側で用意してくれる。"実行したいときに用意したコードを実行できる"ため、必要な料金を最低限に抑えられる。私が最も気に入っているAWSサービスの一つだ。 さて、具体的な使い方に関しては AWS Lambdaの公式ドキュメントを始め、Qiitaなどでもやってみた系でたくさんあるので、本エントリーではそれを利用する上で知っておいたほうがよりよいことを挙げる。というより私が実際に利用してみて詰まったところや感動したことなどを挙げてみる。 コード失敗時にリトライをデフォルトで3回行う 公式ドキュメントにもこのことは書いてあるのだが、見落として不可解な気持ちになるので、これは必ず知っておいたほうがよい。Node.js の場合、Lambdaのコード実行完了時にcont

気にはなってたAmazon Lambda をようやく使えたのでシェア。 Heroku はご存知の通り、Web とは別のWorker プロセスを立ち上げようとすると、その分プランに応じて倍増する。バックグラウンドジョブがそこまでないシーンで、常にWorkerプロセスを立ち上げっぱなしにするのは非効率。必要な時に必要な時だけバックグラウンドジョブを実行できる環境がないのか、考えていた。そこで登場するのが Amazon Lambdaだった、って訳だ。Amazon Lambda　の魅力は何と言っても便利なだけでなく、1 か月あたり 100 万の要求と最大 3.2M 秒のコンピューティング時間が無料である、という点にある。素晴らしい。 今回やりたいこと CSVなどのデータをアップロードして、それらを一括でHeroku Postgres の DBにデータを入れたい。それらの処理は時間がかかるので、バッ

無料でそれなりなメモリとコネクション数を確保できる Heroku Redis。最近できたばかりのアドオンで情報がなかなか出回ってないが、ここに落とし穴があるので利用する場合は注意。 注意点は以下の２点だ。 アイドル状態のコネクションをデフォルトではKillしない Heroku Redis は アイドル状態のコネクションをデフォルトではKillしない。これはどういうことかというと、つなぎっぱなしになって、最終的に限界である20コネクションに達し、アプリケーション全体が落ちる、ということが起きる。 しかもこの復旧はなかなか大変で、コマンド経由でRedisを再起動ということができないのでびっくりすることになる。対応するなら、一度Redisアドオンを削除し、再度追加する、といったところか。もちろん Redisに保存していたデータは全て消える。 そんなことにならないようにHeroku Redisを入

Herokuの欠点は、Tokyoリージョンがないため、ネットワークによる遅延が気になる と言われている。どの程度による遅延が気になっているのかは人によると思うが、Herokuを最大限に高速化させるために私がやっていることをまとめてみた。 これを実施すれば、Herokuが遅いとはあまり思わなくなると考えている。 Asset Sync を利用する [追記（重要）]　Asset Syncを利用するのは公式で止めるよう勧告が出ている。CloudFrontを利用する方法が推奨されている。以下の内容は古いのでご注意を。 ーーーーーーーーーーーー Asset Syncは、Amazon S3に画像やCSS/JavaScriptを置き、各アセットのパスの向き先をそちらにかえてくれるgemだ。これを利用しないと、HTMLとかに置いた静的コンテンツが全てHerokuにアクセスしてしまうため、Herokuサーバー

ネットでRails x AngularJSで調べると、AssetsにAngularJSを追加してやるのが普通的なことをよく見る。でも、この方法だとYeomanや、Grunt.jsが使えず、Rails x AngularJSでKarmaでテストを書いたりといったことができないし、AngularJSの作法にのっとった開発ができないのがとてもモヤモヤしていた。 てことで、もうこれはAsset Pipelineを使わない方向で行くのがベストなんじゃないのか、という方向で色々探し回っていたら、同じようなことを考えていた方がいたようで,これを参考にしてもっとベーシックな枠組みを作ってみた。 Asset Pipeline の機能が使えなくなる？ご心配なく。Grunt.jsがJSコードの圧縮、SCSS, CoffeeScriptのコンパイル、さらにLiveloadの恩恵, 画像の圧縮、テストの自動実行もで