アプリの一部では使うからjbuildrのgem入れてるけど基本的にscaffoldでjson使いたくない場合。
# config/application.rb:
module Rails
class Application < Rails::Application
config.generators do |g|
g.jbuilder false
end
end
end指定したIPからの接続しか受け付けない（古いタイプの）システムと連携したい場合にHerokuだと困る。
ProximoというAddonは固定IP付きのproxyを提供してくれる。rest-clientとかで接続するときにproximoの提供するproxyを設定してリクエストすればOK
require "rest-client"
RestClient.proxy = ENV["PROXIMO_URL"]
res = RestClient.get("http://api.someservice.com/endpoint")
puts "status code", res.code
puts "headers", res.headersこれで固定IP + https + 証明書が必須なシステムとかとも連携できる。httpsの通信をhttp proxy経由で可能かな？とちょっと心配だったけどproxyは中身知らんぷりでそのまま転送するので大丈夫。
proximoはリクエスト数がPlan毎に決まってるので必要なリクエストでだけproxy経由して節約する。
$ curl -x http://proxy.com:8080 http://example.comport指定しないとデフォルトでは1080番にアクセスしに行く。知らないとハマって死ぬ。
おまけ
SSLの証明書とパスワード付きでアクセスする。cert.pemはprivate keyとclient certをconcatinateしたもの！これを知らない者は死ぬ！
$ curl -x http://proxy.com:8080 -E cert.pem:password http://example.com% brew update
% brew upgrade ruby-build
% CONFIGURE_OPTS="--with-openssl-dir=`brew --prefix openssl` --with-readline-dir=`brew --prefix readline`" rbenv install 2.1.0
% rbenv global 2.1.0
% gem install bundler rbenv-rehash
% rbenv rehashバージョンのパッチレベル表記がシンプルになったのは気持ちいいですね。
サーバー台よりS3+CloudFront代の方が高いという自体になっているので、どーせAppサーバー１台だから怖話の画像ファイルをそのままストレージにおいてみた。
capistranoでおなじみの安心構成なのでS3のファイルをscpするだけで完了。
stop and bootするぐらいでは別のストレージになってるなどはなかったけど、柔軟に構成を変えられるのが売りだとおもうのでそういう場合に「あれ、あの画像どこいった？」とならないように注意が必要。
しかし、EYC外のアプリを1台インスタンスにポコっと持ってきてもとりあえず動くのでそこからS3化考えるってのも入り方としては良さそうに思いました。
元から入ってるrubyが最新版ですがsudoとかで壊すとやっかいなので。
% brew install readline openssl
% CONFIGURE_OPTS="--with-readline-dir=`brew --prefix readline` --with-openssl-dir=`brew --prefix openssl` --with-gcc=clang" rbenv install 2.0.0-p247
% rbenv global 2.0.0-p247
% rbenv rehash
% gem install bundler rbenv-rehash会社（FJORD, LLC）で怖話というサイトを２年やってきました。
僕らは２人の会社なので月に７０万の利益があれば諸々の雑費を含めて運営していけると考えました。そして開始時に今度のサービスは２年はやろう。SEOは我慢だ。と思って２０１３年の９月に単月で７０万の利益があったらプロジェクトは成功。達しなかったら失敗と定義付けてやってきました。
そしてその２０１３年の９月が来て結果は失敗となってしまいました。それについてはFJORDのブログに書きました。
ブログにも書きましたが感想はとにかくお金稼ぐの難しいなぁという感じです。
あとは、これは俺がアホだということもありますが、技術面のWebサービスのマネタイズやプロモーションに及ぼす影響の余りの無さにびっくりしました。
Webサービスで技術が優れているというのは、下記のような影響を与えます。
- バグが少ない
- 新機能登場が競合に比べて早い（競合が存在したとして）
- 長年やった場合にコストが少ない（技術的負債をすくなくできる）
- 表示がちょっと速い
- 大規模アクセスに耐えられる
まだまだ怖話程度の規模では関係無いものばかりです。
僕がエンジニア方面の動きを頑張ってもあまり意味が無いのがしんどいですね。
いろいろな背景の人に教えを請いに出かけてみようかなと思います。
何で俺（やオマエら）はマネタイズやプロモーションが下手なんだろう。
俺が思うに、それはプログラミングの面白さと関係無いからだろう。
人月の神話に確かプログラミングの面白さに下記があった（もっとある）
- パズルの楽しさ
- 知的好奇心
- 子供が父親に変なペン立てを作ってあげる時のように人の役に立ちたい（便利なものを作ってあげたい）
我々は面白くないもの耐性が非常に低いので何とかして新しい快楽回路を構築する必要がある。
Webサービス作りの段階について
Webサービスを作るのは楽しい。しかし、ゴルフではじめはドライバーがボールに当たっただけで嬉しいのに、その内ボールに当たるのは当たり前になり、飛ぶ飛距離が出ないと満足できなくなるように、Webサービスにも上達するにつれて快楽の段階がある。
- Webサービスを作れる。
- 便利なWebサービスを作れる。
- 儲かるWebサービスを作れる。
例えば一度２の段階に進むと便利だと周りに持ってもらえなさそうなWebサービスを作ろうという気が無くなる。３の段階に進むと便利でも儲からないWebサービスに挑む気がしなくなる。（４、５とあるのだろうが、俺は食っていける程のWebサービスを作ったことが無いのでまだわからない）
３のための努力というのはプログラマーが面白い努力とは全く関係無いことが多い。例えば俺が猛勉強して怖話をrailsから複数のnode.jsアプリからなるSOA形式に書き換えて大規模開発に対応できるようにしたとしても儲けは全く変わらないだろう。（むしろ減りそうだ）
営業を１から勉強しようと頑張ってみているが「資質や、やるべきことが真逆なので難しいんじゃないか」との意見をいただいている。勿論両方できる人もいるが俺にはそういう能力は無いらしい。
対策としてはマネタイズ・マーケティングの上手い人と組むというのが一般的なんだろう。
昨日EdTech Hackathonに行って久しぶりに色々なWeb関係の方の空気に触れて思った事。
俺はrails好きで強力だし楽しいなーと思うんだけど、
「GoogleからJSのシングルページでもSEO的にペナルティが全く無くなったらサーバーサイド要らねんじゃね？mBaaSで良くね？」
とか
「ちょっとしたサーバーサイドの処理はPHPで良くね？エンジニア多いし、安いし、技術的負債とかセキュリティ・ホールとか経営者からしたらたいして気にならないし、実際の所よくわからないし、来年どうなってるかわからんし。」
とか
「railsエンジニアとか単価高い割に何やってるのかわからないし。テストを書いてます？もっとこうガーッと派手に動く機能追加してくれねえかなあ？」
とか
「長期的なプラットフォームとかはガッツリ作ってくれて構わないけど、もっと雑でいいから短命のモバイル・アプリ量産してくれねえかな？」
とか、そういう雰囲気がWeb業界にあって（俺の被害妄想）、railsが死ぬとしたらもっと強力なフレームワークが出てくるってのじゃなくて、
「railsスゴイのはわかったけど、そういう方向性のスゴさとか我々要らないし、 あと何か上から目線でrubyエンジニアも扱い辛いです。老害乙。」
みたいな感じで、死んでいくのかな、そうだったら嫌だな、と思いました。
プログラマーが誰もが知ってる、そして殆どのバグが直るデバッグ方法。しかし消費MPが多いのでテンパッてたり、心が折れてるとできない。
デバッグ方法
ある程度複雑なプログラムに何か修正を加えたら動かなくなったとする。
- 修正前の動くバージョンを用意する。
- 動かなくなったバージョンを用意する。
- １行（１文字）づつ両方を近づけていく。
- 動くようになった部分の行（文字）がバグの原因。
デバッグ方法（もうちょっと楽なやり方）
大体、何か自分があまり理解してない機能や構文を追加した時にバグが起こる。
- 修正前の動くバージョンを用意する。
- あまり理解してない機能を他を限界まで全てを取り去って（Hello worldレベルで）動くかどうか確かめる。（ここで動かなかったらそもそもその機能は使えない、もしくはあなたが理解してないので勉強してから出直す）
- シンプルバージョンが動いたら、修正前バージョンに近づけていく。
何故このデバッグ方法ができないのか？
殆どのプログラマーはこの方法を知っている。しかし非常に面倒に思えるので（実際はこれやったほうが早く直る場合が多い）一発で直る魔法の方法を探してしまう。もしくは知ってそうな人に聞く（人に聞くのは別に悪いことじゃない）。こういう時は心が折れているので夜であったらさっさと帰って風呂入って寝ると次の日の朝にはこれをやるMPが回復しているのですぐ直ることが多い。