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
あたまにうじがわいているかたは下記を御覧ください。
1年3ヶ月インターンを続けて来てわかったのが、どんなに素人の状態からでも6ヶ月あれば怖話のrailsコードを修正してgit, githubを使い、Pull Requestが送れるようになるということです。（要領の良い人なら3ヶ月ぐらい）
あとはこの形式のローカルインターン最大の敵は生活費が尽きることです。インターン自体にお金は必要ありませんが、週5で勉強してれば一般的な生活費（生命維持費）が持たなくなり、アルバイトや就職の為にまだ勉強したいのに強制卒業になっちゃうことがままありました。
休学中の大学生とかPHPプログラマーだったけどテストの無い終わりなきデスマプロジェクトに疲れて、次に入る会社はrubyのところが良いと思っている方などおすすめです！
下記応募フォームから是非お願いします。
railsでお決まりのliタグをシンプルに書くsexy_liというgemを作りました。
komagata/sexy_liBefore:
ul
- @posts.each do |post|
li
.id post.id
.title= post.titleAfter:
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_netfjordllc ← organization名
remove_a_space ← 今回作ったブランチ名
kowabana_net ← masterじゃない送り先ブランチ名
怖話の英語版（kowabana.net）を作ろうとしていてその実装方法に迷っています。
前提情報
怖い話がメインコンテンツなので例えばアメリカ人に日本語の怖い話を見せても仕方が無い。それどころか、"Recent Scare Story"とかに日本語の怖い話のタイトルが並んでいたら「チャイニーズのサイトに来てしまったぜ」みたいな感じになって二度と来てくれないだろう。
システムやUIは流用できるが、データ（怖い話や多分ユーザーも）は流用できない。
実装の種類
-
2ソース・2DB方式
別サイトとして作る。
-
1ソース・2DB方式
別サイトとしてデプロイするが、ソースは共通。アプリ自体は言語に特化して起動する。ENV['KOWABANA_LANG']とかいう環境変数を作って、それが'en'だったら英語版、'ja'だったら日本語版を表示する。
-
1ソース・1DB方式
一般的な国際化のようにAcept-Languageとかで切り替える。データはデータ自体に言語情報を持ち（usersやstoriesテーブルにlangカラムを持つ）アクセスしてきている人によって見せるデータを分ける。
どうしよう
正直言ってどの方法を選んでも大変な気がしてならない。以前、2の1ソース・2DB方式をやったことがあるが、やっぱり結構大変だった。CookPadは1の2ソース・2DB方式だよね確か。北米向けのレシピを日本のコンテンツから翻訳してきて載せている。怖話も最初の検証段階はそれをやるのがいいのかなあ？
みなさんだったらどうしますか？
cronでrails実行するのにstack v2ベースで下記みたいなエントリーが多いけど、
0 5 * * * cd /data/app_name/current/; BUNDLE_GEMFILE=/data/app_name/current/Gemfile bundle exec /data/app_name/current/script/rails runner 'App.run!' -e productionstack v4ではbundleコマンドがcronでpathの通ってるところにないから下記のようにフルパスにしないとそのまま移行しても動かない。注意。
0 5 * * * cd /data/app_name/current/; BUNDLE_GEMFILE=/data/app_name/current/Gemfile /usr/local/bin/bundle exec /data/app_name/current/script/rails runner 'App.run!' -e production皆どうやってるんだろう。
僕の場合、debuggerはstep実行が必要で無い限り使わない。（step実行が必要な程難しい問題が滅多に無いので殆ど使ってない）
railsのdebug系の記事は定期的に上がるけど、実際にdebuggerを使ってるところを見たこと無い。
結局、
puts "@posts: #{@posts.inspect}"puts "-----------------------------------"
puts @posts.inspect
puts "-----------------------------------"などと書いてrails sしたconsoleで確認している。loggerを使っても他の出力に埋もれるので結局putsする。もう何年も使ってるのにこれはショボイ気がする。
tail -fをgrepすれば埋もれないのかも。
logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
logger.tagged("BCX") { logger.info "Stuff" }railsのloggerとは別のloggerをAppName.loggerとかに設定してlog/app_name.logに出したりするのがいいのだろうか？
mysqlとかよりroleとか色々うるさいので面倒ですよね。
$ curl `heroku pgbackups:url a001` > foo.dump
$ PGPASSWORD=XXXXX pg_restore --verbose --clean --no-acl --no-owner -U foo -d foo_development foo.dump