komagataのブログ

-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} にデプロイしました。"
)

# config/routes.rb:
devise_for :users,
  controllers: {
    registrations: :registrations,
    omniauth_callbacks: 'users/identities'
  } do
    delete 'users/disconnect/:provider' => 'users/identities#disconnect_omniauth_provider', as: 'disconnect_omniauth_provider'
end

$ rake spec
(...)
DEPRECATION WARNING: Passing a block to devise_for is deprecated. Please remove the block from devise_for (only the block, the call to devise_for must still exist) and call devise_scope :user do ... end with the block instead. (called fr)

上記のようにdevise_forにblockを渡すスタイルはDEPRECATEDになった。

# config/routes.rb:
devise_for :users, controllers: {
  registrations:      :registrations,
  omniauth_callbacks: 'users/identities'
}

devise_scope :user do
  delete 'users/disconnect/:provider' => 'users/identities#disconnect_omniauth_provider',
    as: 'disconnect_omniauth_provider'
end

こんな感じでblockに渡してた部分はdevise_scopeを使うといいらしい。

sqlite3でhistoryや補完が聞かなくてウザい。

% which sqlite3
/Users/komagata/android-sdks/tools/sqlite3
% brew link sqlite3 --force
Linking /usr/local/Cellar/sqlite/3.7.17... 9 symlinks created
% which sqlite3
/usr/local/bin/sqlite3

Android SDKに入ってるのが使われてた。brew linkしたら行けました。

参照：あたま うじお - komagata

ko8（こーや）が何で

o）加速度センサー　x）加速センサー

o）アシェルタ・イタリアン　x）アシェルタン

のように名詞を雑に覚えてるのか気になってた。ちょっとした違いかもしれないけど、プログラマーがJavaを絶対にＪＡＶＡと書かないように、絶対ありえないタイプの間違えだと思う。

それが最近、すごくしっくり来る理由を思いついた。

たぶんko8は名詞を音の響きで覚えてる。

普通の成人は意味で覚えてる。“加速度”の“センサー”だなとか、“アシェルタ”という“イタリアン”なんだなという風に覚えてる。加速度とセンサーは個別にすでに知っているのでそれの組み合わせだと理解するわけだ。

しかしko8は音の響きで覚えてるのでまっさらな新しい単語として覚える。そして１音違うぐらいはたいした間違えではない。

子供のころは音で覚えてるものが沢山あったとおもう。言語を覚える時というのは最初はそういうものなんだと思う。俺も実家の近くにあった多摩御陵を「たまごりょう」という音で覚えてた。「たまご」はわかるけど「りょう」ってなんだろう？などとは思わなかった。

大人になって初めて多摩の御陵という意味で、陵というのは天皇の墓を示すというのを知った。意味で覚えていれば、“多摩陵”というような間違えはあるかもしれないが、“たまごろう”とかそいういう間違えはありえない。

音で覚えていると新しい名詞に出会った時に理解が遅い。何度も繰り返し耳にしないと覚えないから。音で覚えていると応用が効かない。

多摩御陵を意味で覚えているなら、XX御陵という他の墓が存在するだろうとか、天皇の墓というのであれば多摩御陵は何天皇の墓なんだろうとかもうすこし立体的に理解できる。

しかしko8は今日が誕生日だそうで（おめでとうございます）、今日ゼロ歳で生まれ変わったと言っていたので大丈夫だと思う。コーヤリボーン！

このブログのLokkaのテーマをslimにしてみた。

docs-komagata-org/public/theme/komagata/layout.slim at master · komagata/docs-komagata-org

以前はバグが多かった印象だけど最近rails案件で使って特に問題なかったので。

従軍記のLokka移行をやっていますが、それを実験台としてさっさとactive-recordブランチをmasterにしたい。あとちょっとなんですけどねー。datamapperからactive-recordへの移行になるからexport/import機能が必要になる。フォーマットはxmlかymlか？とにかくactiverecord化がまずは完了しないと何も進められないのでがんばろう。