komagataのブログ

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を作りました。

komagata/sexy_li

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じゃない送り先ブランチ名

怖話の英語版（kowabana.net）を作ろうとしていてその実装方法に迷っています。

前提情報

怖い話がメインコンテンツなので例えばアメリカ人に日本語の怖い話を見せても仕方が無い。それどころか、"Recent Scare Story"とかに日本語の怖い話のタイトルが並んでいたら「チャイニーズのサイトに来てしまったぜ」みたいな感じになって二度と来てくれないだろう。

システムやUIは流用できるが、データ（怖い話や多分ユーザーも）は流用できない。

実装の種類

1. 2ソース・2DB方式

   別サイトとして作る。

2. 1ソース・2DB方式

   別サイトとしてデプロイするが、ソースは共通。アプリ自体は言語に特化して起動する。ENV['KOWABANA_LANG']とかいう環境変数を作って、それが'en'だったら英語版、'ja'だったら日本語版を表示する。

3. 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 production

stack 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する。もう何年も使ってるのにこれはショボイ気がする。

Ruby on Rails Guidesを見るとTagged Loggingというのがのっている。logにtagを付けてtail -fをgrepすれば埋もれないのかも。

logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
logger.tagged("BCX") { logger.info "Stuff" }

しかし、いちいちブロックで囲む必要があると面倒でputsしてしまう気がする。

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

以前、Engine Yard Cloudでデプロイした時Lingrに通知するというのをやりましたが、デプロイフック内の変数の書き方がdeprecatedになってた。

WARNING: Use of `app` (via method_missing) is deprecated in favor of `config.app` for improved error messages and compatibility.
in /data/kowabana/releases/20130826040633/deploy/after_restart.rb
               
WARNING: Use of `environment_name` (via method_missing) is deprecated in favor of `config.environment_name` for improved error messages and compatibility.
in /data/kowabana/releases/20130826040633/deploy/after_restart.rb

configをつければ良いらしい。

require 'rubygems'
require 'bundler/setup'
require 'lingman'

Lingman::Updater.update(
  "fjord_assistant",
  "takoroom",
  "ASQYUefG1XLx3Mwut7wU44oJh2m",
  "#{config.app} を #{config.environment_name} にデプロイしました。"
)