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
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
したら行けました。
ko8(こーや)が何で
o)加速度センサー x)加速センサー
o)アシェルタ・イタリアン x)アシェルタン
のように名詞を雑に覚えてるのか気になってた。ちょっとした違いかもしれないけど、プログラマーがJavaを絶対にJAVAと書かないように、絶対ありえないタイプの間違えだと思う。
それが最近、すごくしっくり来る理由を思いついた。
たぶんko8は名詞を音の響きで覚えてる。
普通の成人は意味で覚えてる。“加速度”の“センサー”だなとか、“アシェルタ”という“イタリアン”なんだなという風に覚えてる。加速度とセンサーは個別にすでに知っているのでそれの組み合わせだと理解するわけだ。
しかしko8は音の響きで覚えてるのでまっさらな新しい単語として覚える。そして1音違うぐらいはたいした間違えではない。
子供のころは音で覚えてるものが沢山あったとおもう。言語を覚える時というのは最初はそういうものなんだと思う。俺も実家の近くにあった多摩御陵を「たまごりょう」という音で覚えてた。「たまご」はわかるけど「りょう」ってなんだろう?などとは思わなかった。
大人になって初めて多摩の御陵という意味で、陵というのは天皇の墓を示すというのを知った。意味で覚えていれば、“多摩陵”というような間違えはあるかもしれないが、“たまごろう”とかそいういう間違えはありえない。
音で覚えていると新しい名詞に出会った時に理解が遅い。何度も繰り返し耳にしないと覚えないから。音で覚えていると応用が効かない。
多摩御陵を意味で覚えているなら、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化がまずは完了しないと何も進められないのでがんばろう。
@yandoさんから下記を教えてもらったのでやってみた。
@komagata timezoneクックブックでJapanに合わせると幸せになれますよ。UTCだと朝10時にバックアップが走ってマズーかも
— Yusuke Ando (@yando) August 2, 2013
本家に日本語の記事があります。
Chef レシピによる環境のカスタマイズ : Engine Yard Developer Center
最初全体像がつかめなかったんですが、要は環境毎にrecipeを保存してるサーバーがどこかにあって、アプリのコードとは別に、カスタマイズしたrecipesをey recipes
コマンドでそこにアップできるそうです。
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 25 May 17 19:13 /etc/localtime -> ../usr/share/zoneinfo/UTC
$ date
Sun Aug 4 02:54:45 UTC 2013
timezoneのrecipeはengineyardが用意してるrecipeに元々あるので、それを読み込んで変数を変更してやればいい。(recipeはforkして使う)
% git clone git@github.com:fjordllc/ey-cloud-recipes.git
% cd ey-cloud-recipes
% git diff -U0
diff --git a/cookbooks/main/recipes/default.rb b/cookbooks/main/recipes/default.rb
index 5bbd736..f9d39b0 100644
--- a/cookbooks/main/recipes/default.rb
+++ b/cookbooks/main/recipes/default.rb
@@ -148,0 +149,2 @@
+
+include_recipe "timezone"
diff --git a/cookbooks/timezone/recipes/default.rb b/cookbooks/timezone/recipes/default.rb
index e62ec33..b0de8de 100644
--- a/cookbooks/timezone/recipes/default.rb
+++ b/cookbooks/timezone/recipes/default.rb
@@ -4 +4 @@
-timezone = "UTC"
+timezone = "Asia/Tokyo"
僕はsunzi派ですがchefも触っておいて良かった。
ey recipes
でupload, applyする。
% ey recipes upload -e jp_production
Loading application data from Engine Yard Cloud...
Recipes in cookbooks/ uploaded successfully for jp_production
% ey recipes apply -e jp_production
Loading application data from Engine Yard Cloud...
Uploaded recipes started for jp_production
ちゃんとtimezoneが変わってるかどうか確かめる。
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 Aug 4 12:06 /etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo
$ date
Sun Aug 4 12:08:20 JST 2013
うん。変わってる。DBサーバーの方もちゃんと変わってました。appサーバーだけ変更する場合にはroleを指定するとか何かあるんでしょう。多分。
これってTokyoリージョン使う場合は必須の作業ですね。
% CONFIGURE_OPTS="--with-openssl-dir=`brew --prefix openssl` --with-readline-dir=`brew --prefix readline`" rbenv install 2.0.0-p247
% rbenv global 2.0.0-p247
% ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]
% gem install bundler rbenv-rehash
Engine Yard Cloudに限りませんがちょっとハマったので。
UTCで動いてるサーバーで、例えば日本からのアクセスが大半で一番空いてる時間が朝5時(よくある)の場合、JST 5時はUTC 20時(前日の)なので集計バッチなどは上記の用な感じにしておく。
herokuのbamboo stackからcedar stackへのアップグレードは無理なので新規に作ってDBを移行後ドメインを切り替えた。
tapsを使ったdb:pull/db:pushはruby1.9.2とruby.19.3の間のmarshal互換性の断絶で無理なので(このbamboo stackはruby1.9.2で動いてる)pgbackups(pg_dump)を使う。
pgbackupsを使ってpg_dumpを取得したあと、postgres.heroku.comの下記の右側にある矢印アイコンのメニューの中のpg_restoreを選ぶとrestoreコマンドが親切に出るのでそれでさっきのdumpを読み込んで完了。
Lokkaももうちょっとドラスティックに変えていこうかなと思っています。仕事外の時間でちまちまと進めます。