アプリの個人開発の終焉と新たな可能性 - ボクココ
ども、@kimihom です。 今回は私が今まで開発して来た個人開発と、そこで学んだ次の可能性について記していく。 個人で開発したアプリで食っていく 今でもちょくちょく個人開発をしている方をよく見かける。安定した仕事に勤めていた頃、私もその個人開発者のうちの一人だった。週末や空き時間があれば、ひたすらスマホアプリを開発し、私が作ったアプリの合計は十数個にのぼる。最初はゴミみたいなアプリを量産してたわけだけど、経験を積むにつれていいアプリを作る感覚を持てるようになって、１つだけ当たったアプリ(個人開発で15万DL 超えのアプリ)を作ることができた。この"当たるアプリを作る感覚"ってのは、アプリのアイディアそのものであったり、開発だけでないデザインやストアに掲載する文言やSEO、シェアされる仕組み、その他運用テクニックなど多様なものだ。 個人開発を可能にした背景に、スマートフォンアプリの流行が
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 もちろん他にも使っているのはいろいろあるけど、ベースは上記のように至って標準な作りになっている。これによってインフラ周りでトラブルが起きることを最小限にとどめている。今現在でもインフラ周りで特別に問題になっていることはないので、これからも 上記の構成を使い続けていく予
まだ WebPay から移設をしていない方へ - ボクココ
ども、 @kimihom です。 WebPay がサービス終了宣言を出してからおよそ半年が経とうとしている。いよいよ2017年04月30日までというデッドラインが近づいてきている。 「WebPay からどこかへ移った系のエントリーが出てくるのを待つか」 と思って後回しにしている読者の方に一言、伝えておかなければならないことがある。 今すぐ申請を始めるべき！！ 私も甘くみていた側面があるのだが、WebPay の審査が通ったからといって、他の決済サービスの審査期間が短くなるということではない。つまり、そもそも次なる決済サービスを本番サービスに反映しようにもその審査時間であるおよそ 20 営業日を待たないといけないのだ。Visa/Master の2ブランドだけでいいなら、1週間以内に本番反映できるようになるが、それ以外のカードをサポートするには1ヶ月の余裕を持った方がいいだろう。 1ヶ月・・。そ
スタートアップのサービス開発における「スケールしないこと」とは - ボクココ
ども、@kimihom です。 スタートアップをうまく成功させるには、 スタートアップはスケールしないことをしよう ということはとても大事だと思う。スケールしたいんだけどあえてスケールしない努力をすることで、今後のスケールを実現することができるのである。そのことについて理解を深めたい場合は以下のスライドがとても参考になる。 マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得 from Takaaki Umada www.slideshare.net 端的に言うと「スタートアップにマーケティング担当者は害。いない方がマシ」っていうことだ。となるとエンジニアとかデザイナーみたいな直接プロダクトを改善していくような立場じゃない人は、人々の話を聞きに行ったりすることになる。 ではエンジニアはどうすべきか？ 今回はスタートアップエンジニアにおいて、"やるべき
リモートワークを 2年やってみて感じた素質について - ボクココ
ども、@kimihom です。 今回はライフスタイルについて書いてみる。 ウチの会社は 3人という必要最低限のメンバーで CallConnect を運営している。3人が意思決定においてもっとも早く決められるし、情報共有も一瞬で全員に伝わる。全員が当事者意識を持つことのできる最高の人数は3人だと今でも思う。そんな中で 3人のうち1人がリモートワークをしてしまうと他のメンバーに影響が出るのではないかって指摘があるけど、そこの課題をどうやってクリアしているのかをシェアする。 フェーズに応じたリモートワークとオフィスワーク "フェーズに応じた"とは開発におけるフェーズの話だ。例えばじっくりと話し合いが必要な設計やテストなど、対面で会って話した方がいい時は必ず3人で話し合うようにしている。その方が早いし付箋などを使って考えをまとめることができる。さらに特殊なテスト項目とかを実施する際には隣同士でやっ
クラウド時代こそ PaaS を選択すべき理由 - ボクココ
ども、 @kimihomです。 さて、最近は AWS をはじめとしたクラウドサービスが盛り上がっている。そんな中で私はもっとサービスオリエンテッドなネット企業はもっと PaaS を活用すべきだと思ったので書いてみるとする。 貴社のインフラエンジニアは本当に必要か？ いや、この話は大企業とかお金たくさんあるような会社は別にいいんです。だがお金を節約したいのに、わざわざインフラをEC2のようなまんまのサーバーを立てる必要があるのか私には疑問だ。 サーバーに Apache や Nginx を入れて https にしていざ公開となるわけだが、そこから先の監視ツールの導入やミドルウェアのバージョンアップ、デプロイの自動化まで、まんまのサーバーを選択してしまったあなたはずっとそういった課題に対応しなければならない。それがたとえインフラエンジニアが一流で経験のある人でなくても、だ。 PaaS にすればそ
認証を含む API 開発で検討すべきこと - ボクココ
ども、@kimihomです。 API に関する基礎的な話で、なぜ API が重要なのか、APIの実装で注意する点について記述した。 今回はAPI開発において最も頭を悩ます、認証の問題について考えてみたい。 API における認証 よくあるログインが必要なページを考えてみていただきたい。 通常のWebアプリケーションであれば、Cookieという仕組みを使って毎回Webサーバーにアクセスするときにsession idというものを送信し、それとユーザー情報を紐付けたデータを取ってくることで、どんなユーザーからリクエストが来たのかをWebアプリケーション側で判断することができる。これにより、私たちはいつも閲覧しているWebアプリケーションが自分専用の画面として見れるようになっている。 これがAPIになると話は違ってくる。Cookieという仕組みが使えないのである。ということで、なんとかしてAPIにア
API 開発において認証以外で気をつけるべきこと - ボクココ
ども、@kimihomです。 前回の 認証を含む API 開発で検討すべきこと は多くの方にお読みいただき、API の関心の高さを伺えた。 さて、今回は認証以外でAPI開発において考慮すべきこととして以下の課題について考えてみる。 アクセス制御(認可) 不正アクセスの制御 バージョン管理の課題 ドキュメント作成の課題 アクセス制御(認可) まずは認可について。トークンによってユーザーは識別できたけども、そのユーザーができること・できないことができるようになったわけではない。基本的に認可の話はプログラム側でユーザーと役割を定義してできることできないことをゴリゴリ書いていくだけだが、より一般的な方法がある。 それは前回の認証コードを発行する"アプリケーション" ごとに権限を付与する方法である。ここでアプリケーション(アプリ)という概念が出てきたので少し解説しよう。 API の世界で出てくる"ア
API に関する基礎的な話 - ボクココ
ども、@kimihomです。 今回から何回かに分けて、APIについて語っていきたいと思う。 API とは。そのメリット Application Programming Interface の略。サービス同士がAPIを通じて連携するための仕組みだ。通常は、HTTPSを通じて、JSONのフォーマットでやり取りされることが多い。特に最近は、RESTful な APIにであることが求められている。これは、以前の記事を参照していただきたい。 REST な API とは何か APIにより、サービス同士の"連携"が可能になる。例えば自社サービスにGoogle や Facebookの機能を埋め込みんだり、情報を取ってきたりできるのも、各社が提供するAPIがあるおかげだ。また最近はWebだけでなくスマホやタブレット、その他デバイスの普及により、一つのサービスがWebの中に留まることはなくなっている。他デバイ
AWS Lambda を利用する上で知っておいたほうがよいこと - ボクココ
本ブログで度々紹介している AWS Lambda。改めてもう一度解説すると、コード(Node.js or Java)を実行する環境をAWS側で用意してくれる。"実行したいときに用意したコードを実行できる"ため、必要な料金を最低限に抑えられる。私が最も気に入っているAWSサービスの一つだ。 さて、具体的な使い方に関しては AWS Lambdaの公式ドキュメントを始め、Qiitaなどでもやってみた系でたくさんあるので、本エントリーではそれを利用する上で知っておいたほうがよりよいことを挙げる。というより私が実際に利用してみて詰まったところや感動したことなどを挙げてみる。 コード失敗時にリトライをデフォルトで3回行う 公式ドキュメントにもこのことは書いてあるのだが、見落として不可解な気持ちになるので、これは必ず知っておいたほうがよい。Node.js の場合、Lambdaのコード実行完了時にcont
Heroku と Amazon Lambdaを連携して、バックグラウンドジョブを実現した - ボクココ
気にはなってたAmazon Lambda をようやく使えたのでシェア。 Heroku はご存知の通り、Web とは別のWorker プロセスを立ち上げようとすると、その分プランに応じて倍増する。バックグラウンドジョブがそこまでないシーンで、常にWorkerプロセスを立ち上げっぱなしにするのは非効率。必要な時に必要な時だけバックグラウンドジョブを実行できる環境がないのか、考えていた。そこで登場するのが Amazon Lambdaだった、って訳だ。Amazon Lambda の魅力は何と言っても便利なだけでなく、1 か月あたり 100 万の要求と最大 3.2M 秒のコンピューティング時間が無料である、という点にある。素晴らしい。 今回やりたいこと CSVなどのデータをアップロードして、それらを一括でHeroku Postgres の DBにデータを入れたい。それらの処理は時間がかかるので、バッ
Heroku Redis は初期設定で利用してはならない - ボクココ
無料でそれなりなメモリとコネクション数を確保できる Heroku Redis。最近できたばかりのアドオンで情報がなかなか出回ってないが、ここに落とし穴があるので利用する場合は注意。 注意点は以下の２点だ。 アイドル状態のコネクションをデフォルトではKillしない Heroku Redis は アイドル状態のコネクションをデフォルトではKillしない。これはどういうことかというと、つなぎっぱなしになって、最終的に限界である20コネクションに達し、アプリケーション全体が落ちる、ということが起きる。 しかもこの復旧はなかなか大変で、コマンド経由でRedisを再起動ということができないのでびっくりすることになる。対応するなら、一度Redisアドオンを削除し、再度追加する、といったところか。もちろん Redisに保存していたデータは全て消える。 そんなことにならないようにHeroku Redisを入
なんだかんだで SPA から jQuery に戻った話 - ボクココ
最近は SPA とか React といった話題が尽きないが、自分は結局 フロントエンド JavaScript は jQuery が最もいいと感じている。それはそれら SPA の JavaScript をいじった経験を踏まえての感想。 理由としては、「 やりたいことができにくい 」これに尽きる。 最新を追うということ 自分が最初にSPAを触ったのは AngularJS だった。なるほど、この ng-repeat や $route, $scope などを使えば、今までサーバサイドでやってたようなレンダリングが表側で制御できるようになる！と感動したものだった。この気持ち良さはきっとサーバーサイドでごにょごにょやっていた経験のある人ならなおさら感動するものだ。 さて、じゃあといって「次作るのは SPA のサービスにしよう！」と意気込んで初めて見たとする。それで作っただけで話題になるし、エンジニアと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
