bashの脆弱性、怖話でも気になったけどEngine Yard Cloudで簡単に対応できました。
CVE-2014-6271からの一連の脆弱性対策がボタン一個で勝手に対応できて楽ですね。
全部の詳細を抑えておくのは大変ですが、こうやって表記してくれると安心感がありました。
お客さんの案件だったらドヤ顔で「調査して対応しました。」とか言えますな。
いきなり更新は怖いので例によって一回cloneした環境で動くこと確認してからアップデートしました。
定期購読しているWeb+DB Press vol.82 ”切りひらくRuby”を読んで知りました。（俺はタバコ吸わないので仕事の休憩時は適当に置いてある雑誌を読む）
今はbrewで入るみたい。rbenvとruby-buildに依存してるからこれからrbenv入れる時はこっちを入れれば一発で全部入りますな。
$ brew install rbenv-default-gems$ vi ~/.rbenv/default-gems
bundler
rbenv-rehash中身はbash scriptで俺の知らないテクがたくさんあってよくわかんなかった。
ヘッド有りブラウザーで動きみたいときもある。
$ brew install chromedriver# test/test_helper.rb:
Capybara.register_driver :chrome do |app|
Capybara::Selenium::Driver.new(app, :browser => :chrome)
end
Capybara.javascript_driver = :chrometeardownも同じくどっちでも変わらないと思ってた。しかし、前者は上書きだけど後者は親クラスのsetupも呼んでくれるので後者の方が良い。例えば下記みたいにintegrationテストだけは全部js実行できるブラウザでテストしたいけどいちいち書いてられない場合。
# test/test_helper.rb:
class ActionDispatch::IntegrationTest
setup do
Capybara.current_driver = Capybara.javascript_driver
end
end# test/integration/post_comment_test.rb:
class PostCommentTest < ActionDispatch::IntegrationTest
setup do
sign_in('foo@example.com', 'password')
end
test 'post a comment' do
(...)
end
endsuperが要らないのは気持ちいい。
単純にテストの後処理としてのサインアウトだったらcookieを消す方が速い。
page.driver.browser.clear_cookiesサインアウト機能のテストでよくある。visitメソッドだとgetしか飛ばせない。
実際にサインアウトリンクをクリックするのはサインアウトのテストだったらいいけど、他のテストの後処理として使う場合はすごく遅くなりそうで嫌だ
deviseには下記のような設定ができるらしいけど、これテストしてることになんの？って気がするので却下。
config.sign_out_via = Rails.env.test? ? :get : :deleteこれで行けた。
page.driver.submit :delete, '/users/sign_out', {}Engine Yardが９月１日から価格改定したみたい。
従量課金って金額計算が面倒だからこうやって何となくでいいから出してもらえるとわかりやすい。受託開発の時とか、お客さんに見せやすいし。
怖話もこの価格改定で安くなるはずだけど夏終わりでトラフィック落ちてきてるから悲しい・・・。
プロジェクト内で単数形と複数形が混在してて気になった。thoughtbotのprojectを幾つかみたけどみんなfactories.rb１ファイルに全部書いてた。
@komagata 同じことを悩んだことあり。generatorが自動生成する時は複数形な気がするので、そちらに揃えることにしてます。
— Junya Ogu®a (@junya) 2014, 8月 19@yoshuki @junya ありがとうございます。generatorが無理やり複数形にしてくれますね！http://t.co/2ZWnwC7fTU
— Masaki Komagata (@komagata) 2014, 8月 19$ rails g factory_girl:model user
create spec/factories/users.rb複数形で書きましょう。
EngineYardCloudが価格改定したのでそれにともなって怖話ではちょっと古いc1.mediumというEC2のインスタンスを使ってたので@yandoさんおすすめのm3.mediumに変えてみました。
vCPUが減る代わりにメモリはほぼ倍増、起動ディスクはSSDになる上に価格がかなり抑えられるということでこれで賄えれば万々歳ですね。夏でアクセス増えてる怖話の経費削減に大きく影響しそうです。
そもそも新しい種類のインスタンスということで見えないところもだいぶ新しくなってそうですし、期待です。
githubでprivateなorganizationリポジトリ（仕事のとかね）は同リポジトリ内に別ブランチを作って、そこからmasterにPRを送るという運用をしてました。
というかそういうとこが多いと思う。
同一リポジトリのbranchからmasterにpull requestする - komagata
@milkcocoa「privateなorganizationなreposからforkしたやつは無料のままprivateでつかえますよ。」
しばらくは"見"に回ってたんですが、自分のrepos（komagata/kowabanaとか）からPRする方式を試しています。どういうのが普通なのかわからないので自分のやり方を晒します。
forkしてきたkomagata/kowabanaをoriginにし、organizationの大本をupstreamというremote名で登録する。
origin内で修正pushして、これでOKとなったらPRを送る
$ git pull-request -b fjordllc:masterこれのいいところは複数人で使ってるfjordllc/kowabanaといったorganizationリポジトリのブランチにゴミが残らないこと。pushを含めてPR寸前まで自分のreposの中で作業してるのでゴミがorganizationに行かない。
PRをマージした時DELETEボタンで消す癖を付けておけばいいが、なんだかんだで忘れてたり、いなくなった人がやってたbranchが残ってたりして消していいか迷う。
逆に困る点は、CircleCIやHoundCIなどのpushしたら色々やってくれる系のサービスはfjordllc/kowabanaしか対象じゃないので自分のreopsにpushした時点じゃ動かないところ。
かと言って参加メンバー全員のforkまでCI対象に含めるのもダルい。
なんとかならないかなー。みなさんどうやってるのか教えていただけると嬉しいです。