komagataのブログ

何で俺（やオマエら）はマネタイズやプロモーションが下手なんだろう。

俺が思うに、それはプログラミングの面白さと関係無いからだろう。

人月の神話に確かプログラミングの面白さに下記があった（もっとある）

• パズルの楽しさ
• 知的好奇心
• 子供が父親に変なペン立てを作ってあげる時のように人の役に立ちたい（便利なものを作ってあげたい）

我々は面白くないもの耐性が非常に低いので何とかして新しい快楽回路を構築する必要がある。

Webサービス作りの段階について

Webサービスを作るのは楽しい。しかし、ゴルフではじめはドライバーがボールに当たっただけで嬉しいのに、その内ボールに当たるのは当たり前になり、飛ぶ飛距離が出ないと満足できなくなるように、Webサービスにも上達するにつれて快楽の段階がある。

1. Webサービスを作れる。
2. 便利なWebサービスを作れる。
3. 儲かるWebサービスを作れる。

例えば一度２の段階に進むと便利だと周りに持ってもらえなさそうなWebサービスを作ろうという気が無くなる。３の段階に進むと便利でも儲からないWebサービスに挑む気がしなくなる。（４、５とあるのだろうが、俺は食っていける程のWebサービスを作ったことが無いのでまだわからない）

３のための努力というのはプログラマーが面白い努力とは全く関係無いことが多い。例えば俺が猛勉強して怖話をrailsから複数のnode.jsアプリからなるSOA形式に書き換えて大規模開発に対応できるようにしたとしても儲けは全く変わらないだろう。（むしろ減りそうだ）

営業を１から勉強しようと頑張ってみているが「資質や、やるべきことが真逆なので難しいんじゃないか」との意見をいただいている。勿論両方できる人もいるが俺にはそういう能力は無いらしい。

対策としてはマネタイズ・マーケティングの上手い人と組むというのが一般的なんだろう。

昨日EdTech Hackathonに行って久しぶりに色々なWeb関係の方の空気に触れて思った事。

俺はrails好きで強力だし楽しいなーと思うんだけど、

「GoogleからJSのシングルページでもSEO的にペナルティが全く無くなったらサーバーサイド要らねんじゃね？mBaaSで良くね？」

とか

「ちょっとしたサーバーサイドの処理はPHPで良くね？エンジニア多いし、安いし、技術的負債とかセキュリティ・ホールとか経営者からしたらたいして気にならないし、実際の所よくわからないし、来年どうなってるかわからんし。」

とか

「railsエンジニアとか単価高い割に何やってるのかわからないし。テストを書いてます？もっとこうガーッと派手に動く機能追加してくれねえかなあ？」

とか

「長期的なプラットフォームとかはガッツリ作ってくれて構わないけど、もっと雑でいいから短命のモバイル・アプリ量産してくれねえかな？」

とか、そういう雰囲気がWeb業界にあって（俺の被害妄想）、railsが死ぬとしたらもっと強力なフレームワークが出てくるってのじゃなくて、

「railsスゴイのはわかったけど、そういう方向性のスゴさとか我々要らないし、 あと何か上から目線でrubyエンジニアも扱い辛いです。老害乙。」

みたいな感じで、死んでいくのかな、そうだったら嫌だな、と思いました。

プログラマーが誰もが知ってる、そして殆どのバグが直るデバッグ方法。しかし消費MPが多いのでテンパッてたり、心が折れてるとできない。

デバッグ方法

ある程度複雑なプログラムに何か修正を加えたら動かなくなったとする。

1. 修正前の動くバージョンを用意する。
2. 動かなくなったバージョンを用意する。
3. １行（１文字）づつ両方を近づけていく。
4. 動くようになった部分の行（文字）がバグの原因。

デバッグ方法（もうちょっと楽なやり方）

大体、何か自分があまり理解してない機能や構文を追加した時にバグが起こる。

1. 修正前の動くバージョンを用意する。
2. あまり理解してない機能を他を限界まで全てを取り去って（Hello worldレベルで）動くかどうか確かめる。（ここで動かなかったらそもそもその機能は使えない、もしくはあなたが理解してないので勉強してから出直す）
3. シンプルバージョンが動いたら、修正前バージョンに近づけていく。

何故このデバッグ方法ができないのか？

殆どのプログラマーはこの方法を知っている。しかし非常に面倒に思えるので（実際はこれやったほうが早く直る場合が多い）一発で直る魔法の方法を探してしまう。もしくは知ってそうな人に聞く（人に聞くのは別に悪いことじゃない）。こういう時は心が折れているので夜であったらさっさと帰って風呂入って寝ると次の日の朝にはこれをやるMPが回復しているのですぐ直ることが多い。

acts_as_listはitemに対するcategoryだとか、並び替えをグループ化する対象(scope)を指定できる。scopeをcategoryにすると同一category_idの中で並べ替えるといった具合。

シンプルにはそういうの要らなくて普通にitemを並べ替えたいだけだとおもうんだけどREADMEにのってる例がいきなりそういう応用編なので分かりづらいと思う。

configuration = { column: "position", scope: "1 = 1", top_of_list: 1, add_new_at: :bottom}

acts_as_list/lib/acts_as_list/active_record/acts/list.rb at a736eca3b0918c39759f94d71193c12508344e9c · swanandp/acts_as_list

scopeに何も渡さなかった場合は"1 = 1"という文字列がSQLに渡されるので常にtrueだからそのシンプルな例が適応される。

heroku_sanでstagingでrakeタスク実行したいとき、

% rake staging heroku:rake\[intern:reset_position\]

zshだとカッコエスケープしないと駄目。（bashはok）

active_decoratorは他の類似gemより気持ち良く書けて好きなんですが、時々

「decoratorのmethodが呼べないなあ？」

みたいな時があるのにもかかわらずなんとなく使ってて反省したのでコードを読んでみた。

要はview_assignsというその名の通りのrailsのmethodを使ってview_contextのinstance変数を列挙してActiveRecord系のものだったらdecorateすると。

なるほどなぁ〜。この辺が他の明示的にdecorateする系とは違うピリッと効いてるところなのかな。

それでやっとわかった。

= current_user.foo

とか

= @post.user.foo

とかいうようなassignしてない部分で「あれ、効かないな」となってたわけだ。

俺が使い方をわかってなかっただけなんですが、特に後者は結構でてくると思うけどみんなどうやってるんだろう？

追記：

と思ったらこのPRが正にそれっぽい。

Decorate associations of a decorated object by ronen · Pull Request #8 · amatsuda/active_decorator

association全部decorateするのはやり過ぎ感とかあるのかな？

ユーザーが自分のアイコンをアップできるよくあるサービスの場合、

Amazon CloudFrontの使用上の注意とTipsまとめ｜Media Technology Labs (MTL) : メディアテクノロジーラボ

よって、更新にしろ、削除にしろ、２４時間くらいずれても、いいコンテンツでないとCloudFront には向かないことになります。

写真共有サイトでつかう場合だと、写真の加工とかがあった場合は、必ずファイル名を変更するような対応が必要です。

アップしたアイコンがなかなか反映されずに困る。そりゃそうだ。「誰かがなんとかしてくれてるはず」みたいないい加減な思いでCloudFrontつかっちゃってた。反省。

papaerclipを使ってる場合の良い方法は無いかな？

追記：

Using Amazon’s CloudFront with Rails & Paperclip – Tristan Media Blog

このブログに書いてあるようにpaperclipのinterpolatesを使ってtimestampをファイル名に埋め込むのがいいのかも。でもこれだとファイルがどんどん増えちゃうからexpiresを長くするとお金がかかってしまう。

CloudFrontのファイルを即時削除する方法が見つからなかった。それがあったとしてアップする前に削除するっていう処理を書くのも大変だなあ。みんなどうやってるんでしょう？

追記２：

paperclipだけS3のみにすることで対応した。（assetsはcloudfront）

あの好物のフォカッチャを食べ逃し、/bin/bashを削除し、あたまにうじがわきかけていたko8（こーや）がこのたびめでたくrailsをやっている会社様にアルバイト・インターンが決定し、卒業していきました。

本当におめでとうございます。

現在、本人の事情により名前を開かせないローカルインターンが1名いますが、座席が結構あいてるのでローカルインターン募集です。

ローカルインターンって何？という件については下記を。

• リモートインターンシップ制度案 - komagata
• インターン募集・アプリ公開 - komagata

オフィスの雰囲気については下記を御覧ください。

超豪華商品が当たる！ローカルインターン募集 - komagata

あたまにうじがわいているかたは下記を御覧ください。

あたま うじお - komagata

1年3ヶ月インターンを続けて来てわかったのが、どんなに素人の状態からでも6ヶ月あれば怖話のrailsコードを修正してgit, githubを使い、Pull Requestが送れるようになるということです。（要領の良い人なら3ヶ月ぐらい）

あとはこの形式のローカルインターン最大の敵は生活費が尽きることです。インターン自体にお金は必要ありませんが、週5で勉強してれば一般的な生活費（生命維持費）が持たなくなり、アルバイトや就職の為にまだ勉強したいのに強制卒業になっちゃうことがままありました。

休学中の大学生とかPHPプログラマーだったけどテストの無い終わりなきデスマプロジェクトに疲れて、次に入る会社はrubyのところが良いと思っている方などおすすめです！

下記応募フォームから是非お願いします。

合同会社フィヨルド インターン応募フォーム

railsでお決まりのliタグをシンプルに書くsexy_liというgemを作りました。

Before:

ul
  - @posts.each do |post|
    li
      .id post.id
      .title= post.title

After:

ul= render_li_for @posts

_post.html.slim:

.id= post.id
.title= post.title

という感じです。liに付くclassやid、partial名やlocal変数を決め打ちにしちゃおうというだけです。

-bで送り先のブランチ指定できる。

% git pull-request -h fjordllc:remove_a_space -b fjordllc:kowabana_net

fjordllc　←　organization名

remove_a_space　←　今回作ったブランチ名

kowabana_net　←　masterじゃない送り先ブランチ名