平凡なエンジニアの独り言

Rails 4.2.8を5.1.0にアップグレードした

2017-05-02 11:11:36 +0900

Rails 5.1が出ていたので、このブログをアップグレードしてみました。 Rails 5.1: Loving JavaScript, System Tests, Encrypted Secrets, and more | Riding Rails http://weblog.rubyonrails.org/2017/4/27/Rails-5-1-final/ (1) GemfileのRailsのバージョンを5.1.0にする (2) 以下のコマンドを実施。 {{{code bundle update rails app:update }}} Rails 4系からのアップグレードということもあって、sass-railsやcoffee-railsなどのgemのバージョンを変更しないと依存関係の問題でbundle updateが失敗しました。まぁ、こんなに長く放置しているアプリケーションも珍しいと思うので、細かくRailsのバージョンを上げていれば問題はないはず・・・です。 -config/boot.rbは上書き -config/routes.rbはスキップ -config/application.rbは上書き -config/secrets.ymlは上書き -config/environment.rbは上書き -config/environments下のファイルは適宜マージ development環境のconfig.file_watcherはActiveSupport::EventedFileUpdateCheckerは無効にして、ActiveSupport::FileUpdateCheckerを使うようにしました。これは、Vagrant上で開発していると、共有フォルダのファイルの変更が検知できない事があるためです。また、以下の問題を対応しました。 Rails 4.2を5.0に上げたら、production環境でautoload_pathsが効かなくなった http://akasata.com/articles/318 ソースコードの書き換えとしては、redirect_to :backをredirect_backで書き換えたくらいです。その他、特に問題ありませんでした。以下、参考情報（と言うより一次情報）です。 A Guide for Upgrading Ruby on Rails - Ruby on Rails Guides http://guides.rubyonrails.org/upgrading_ruby_on_rails.html

Rails 4.2を5.0に上げたら、production環境でautoload_pathsが効かなくなった

2016-10-11 14:35:02 +0900

趣味コードをRails 4.2から5.0に上げたら、production環境だけconfig.autoload_pathsが効かないという現象に遭遇したので、対策をメモっておきます。 Rails Guideによると、config.eager_loadとconfig.cache_classesがtrueだとconfig.enable_dependency_loadingがfalseになり、autoloadingが無効化されるようです。development環境ではこの2つをfalseにしている事が多いでしょうし、production環境ではtrueにしていることが多いと思うので、この問題に遭遇する人は多いのではないでしょうか。 Configuring Rails Applications http://guides.rubyonrails.org/configuring.html では、config.enable_dependency_loadingをtrueに設定すればいいのかというと、実際それで動くようにはなりますが・・・将来的にはこのオプションは削除されるようです。 Add option to enable dependency loading in production https://github.com/rails/rails/commit/80b416f5e692ae79f4062f59fed6c7d7648a8af0 上記のコミットログにも、const_missingを利用しているアプリケーション向けに付けたオプションと書いてあるので、あくまで特殊なケースと位置づけているのでしょう。再度、Rails Guideを見返すとconfig.eager_load_pathsを見つけたので、これを使うことで解決することができました。 {{{code config.eager_load_paths << "#{Rails.root}/hogehoge" }}} ■ 参考 rails commit log流し読み(2016/06/23) http://y-yagi.hatenablog.com/entry/2016/06/24/063207 下記ブログでは、copy-on-writeの恩恵をうけるために本番ではautoloadを使うべきではないと紹介しています。 Don't forget about eager_load when extending autoload paths http://blog.arkency.com/2014/11/dont-forget-about-eager-load-when-extending-autoload/ ■ 備忘録 Rails 4.1.1を4.2.0にアップグレードした http://akasata.com/articles/316

JetBrains IDEでeslintとjscsを設定してみた

2015-09-15 09:15:02 +0900

仕事でeslintとJSCSを使っているのですが、gulpで回しているだけだとlintエラーに素早く対処しにくいので、IDEでも設定してみることにしました。（私が主に使っているのはRubyMineです。） !!!インストール {{{code // JSCSとeslintのインストール npm install jscs -g npm install eslint -g // babelパーサとreact向けプラグインのインストール npm install babel-eslint -g npm install eslint-plugin-react -g }}} !!!IDEの設定以下のページを参考に設定を行いました。.eslintrcや.jscsrcを見に行くようにしているので、gulpでビルドするときにかかるチェックと同じものがかかります。 -[link https://www.jetbrains.com/webstorm/help/jscs.html JSCS - JetBrains] -[link https://www.jetbrains.com/webstorm/help/eslint.html ESLint - JetBrains] IDE上では以下のような感じで動いています。JSCSはコンテキストメニューから自動整形も可能です。ただ、JSX内のHTML実体参照が変換されてビルドが通らなくなるなどの問題があるので使っていません（2015/9/15 jscs@2.1.1にて発生）。 [gyazo faf9d0cb3d22cfa4487d9d4e4f3d350c] 余談ですが、JSCSとeslintの役割がかぶっている部分があるので、うまい具合にルールを切り分けたいと考えています。ただ、以下のコミットを見る限りeslintでもコードスタイルの自動整形が検討されているようなので、将来的にはeslintに一本化できるのかもしれません。当面は二本立てで様子見ですかね。。。 -https://github.com/eslint/eslint/commit/61056b8a020f8370a57ed9dff022617c81f64f99

Rails 4.1.1を4.2.0にアップグレードした

2014-12-23 17:01:37 +0900

Rails 4.2.0がでていたので、このブログをアップグレードしてみました。 Riding Rails: Rails 4.2: Active Job, Asynchronous Mails, Adequate Record, Web Console, Foreign Keys http://weblog.rubyonrails.org/2014/12/19/Rails-4-2-final/ (1) GemfileのRailsのバージョンを4.2.0にする 4.2に限った話ではありませんが、一度新規アプリを生成してGemfileを見比べたほうがいいでしょう。例えば4.2ではWeb Consoleのような新機能が追加されていますが、この機能を使うにはGemfileに該当するgemを追記する必要があります。 (2) 以下のコマンドを実施。 {{{code bundle update rake rails:update }}} -config/boot.rbは上書き -config/routes.rbはスキップ -config/application.rbは上書き -config/environments下のファイルは適宜マージ Rails 4.2からrails sでbindingされるIPが0.0.0.0からlocalhostに変わった（※）ので、仮想環境越しのアクセスが失敗するようになっています。（セキュリティ上の理由があるようです。）その場合は、以下のようにするとよいでしょう。 {{{code rails s -b 0.0.0.0 }}} ※ 厳密にはRack 1.6での仕様変更を受けてのようです。詳しくは以下のブログにあります。 [link http://www.techscore.com/blog/2014/09/12/rails4-2beta1%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%97%E3%81%A6%E6%9C%80%E5%88%9D%E3%81%AB%E3%81%AF%E3%81%BE%E3%81%A3%E3%81%9F%E3%81%93%E3%81%A8/ Rails4.2beta1をインストールして最初にはまったこと TECHSCORE BLOG] また、以下のページの「2 Upgrading from Rails 4.1 to Rails 4.2」も参考になる（と言うより一次情報ですね）ので、参照するとよいでしょう。 A Guide for Upgrading Ruby on Rails — Ruby on Rails Guides http://guides.rubyonrails.org/upgrading_ruby_on_rails.html

CentOSでrroonga gem（Ruby向けGroongaライブラリ）のインストールに失敗したので対処方法をメモ

2014-08-03 21:25:32 +0900

手元の開発環境でrroonga gemをインストールしようとしたら、ライブラリ（もしくはヘッダ）が足りないと怒られてコンパイルに失敗してしまいました。 {{{code gem install rroonga }}} そこで、以下の記事を参考にライブラリとヘッダをインストールしてから再度インストールを試したところうまく行ったので、備忘録としてメモっておきます。 -[link http://groonga.org/ja/docs/install/centos.html 2.5. CentOS Groonga v4.0.4ドキュメント] {{{code rpm -ivh http://packages.groonga.org/centos/groonga-release-1.1.0-1.noarch.rpm yum makecache yum install groonga-libs groonga-devel gem install rroonga }}} 過去に試した時は事前にパッケージを入れなくてもrroongaをインストールできた気がするので、たまたま何か前提となるパッケージが足りなかったとかそういう感じだと思いますが。。。

Skyrim（TES）に出てくる「膝に矢」のアレ

2014-05-26 17:29:23 +0900

twitterを眺めていたら以下の様なtumblrが流れてきました。 [b http://reitan.tumblr.com/post/86853243927 スカイリムの「膝に矢を受けてしまってな….」っていうアレ、現実のノルディックの言葉のようで、意味は「結婚した」を意味するらしい。だから衛兵は、本当に膝に矢を受けたのではなく、所帯を持ったから冒険者をやめて衛兵になったってことになるな。知らんかったわ…..] 最初は「へー、北欧のスラングなのか」くらいの感想だったのですが、少し引っかかるものを覚えたのでボチボチとググってみました。以下の英語の記事を読むと、最初の回答にそのようなことが書かれているのですが、「ソースは？」「オレ、ノルドだけどそんなそんな言い回し使ったことないけど」的な反論が出ていて、ソースがあるものではないようです。 What does the term "I took an arrow to the knee" mean - Ask Community http://www.ask.com/answers/48485721/what-does-the-term-i-took-an-arrow-to-the-knee-mean 上記のページでは、すね当ての装備スロットを活用することをアドバイスしているのではないかという説明もありますが、それはそれでちょっと味気ないです。以下の記事では、"The Name of the Wind"というファンタジー小説に出てくる一節であるという指摘もされています。この小説の語り手である宿屋の主人Koteは若いころは伝説的な活躍をした魔法使いという設定のようで、なんとなくパロディとしてならおもしろい言い回しになっていると思います。 I Took an Arrow in the Knee | Know Your Meme http://knowyourmeme.com/memes/i-took-an-arrow-in-the-knee 以下の記事にその前後の文章も引用されています。 "arrow in the knee" is actually a literary allusion to The Name of the Wind : skyrim http://www.reddit.com/r/skyrim/comments/n4kne/arrow_in_the_knee_is_actually_a_literary_allusion/ 限界を感じて冒険者を引退した衛兵が、言い訳代わりに伝説の魔法使いの言い回しを真似ているとしたら・・・全くもって微笑ましい話だと思います。 [amazon B006JW4KNG] ・・・そういえば、我らがメタルマックスでは、結婚エンド（あるいはゲームオーバー？）は1992年から続く伝統になっています。3では平凡だが幸せな一生を送ったという趣旨の皮肉に満ちたエンディングに突入します。冒頭で引用した記事の「結婚して冒険者引退」と言うのはオープンRPGでは定番のネタともいうべきものなのかもしれません。

Rails 4.0.4を4.1.0にアップグレードした

2014-04-09 11:15:57 +0900

Rails 4.1.0が出ていたので、このブログをアップグレードしてみました。例によって、作業ログを残しておきます。 Riding Rails: Rails 4.1.0: Spring, Variants, Enums, Mailer previews, secrets.yml http://weblog.rubyonrails.org/2014/4/8/Rails-4-1/ (1) GemfileのRailsのバージョンを4.1.0にする (2) 以下のコマンドを実施。 {{{code bundle update rake rails:update }}} -config/routes.rbはスキップ -config/application.rbは特に変化が無かったのでスキップ --（備忘録：4.0.2から4.0.4にアップグレードした時は少し変化があったので修正した記憶があります） -config/environment.rbは上書き --config/environments下のファイルは適宜マージ -その他細々と上書き --config/initializers/mime_types.rb --config/initializers/session_store.rb -config/secrets.ymlにsecret_token.rbの内容をコピーして、secret_token.rbを削除注意点としては、セッションのシリアライズがRubyオブジェクトをMarshalする方式からjsonへのシリアライズに変更された関係か、私の環境では以下の様なエラーが出ました。 {{{code ActionView::Template::Error (795: unexpected token at {I"session_id:ETI"... }}} config/initializers/cookies_serializer.rbのcookies_serializerを:hybridにするとうまい具合にmigrateしてくれます。（デフォルトは:jsonです。旧方式を使うなら:marshalを指定してください。） {{{code Rails.application.config.action_dispatch.cookies_serializer = :hybrid }}} JSON方式に変更すると、DateTimeなどのようにセッションにRubyオブジェクトを含めていた場合に問題が出るかもしれないので注意する必要がありそうです。

Rails 4.0.0を4.0.2にアップグレードした

2013-12-10 15:11:12 +0900

Rails 4.0.2が出ていたので、セキュリティフィックスが含まれているということもあって、動かしているウェブアプリ（このブログ）を4.0.2にアップグレードしました。その際の作業ログをメモっておきます。 Rails 3.2.16 and 4.0.2 have been released! http://weblog.rubyonrails.org/2013/12/3/Rails_3_2_16_and_4_0_2_have_been_released/ (1) GemfileのRailsのバージョンを4.0.2にする (2) 以下のコマンドを実施。 {{{code bundle update rake rails:update }}} 以下、rake rails:updateの作業ログです。 -routes.rbはスキップ -application.rbは特に変化が無かったのでスキップ -環境ごとのファイルは適宜マージ -initializers/secret_token.rb上書き ■ その他の作業特にありませんでした。

RailsのCookieStoreの脆弱性について

2013-11-28 20:25:50 +0900

RailsのCookieStoreの脆弱性についていくつか報告記事が出ていたので、内容を検討してみました。 Ruby on Railsにcookie保存関連の脆弱性、2000サイトで放置状態 http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html Rails SessionにCookieStore使った時の問題点 http://oauth.jp/blog/2013/09/26/rails-session-cookie/ 読み合わせていくと、以下のような問題があるようです。 -Cookieの情報が抜かれることによって、セッションをハイジャックされる可能性がある --Rails 2系にはXSS脆弱性からCookieの情報が抜かれる可能性がある --Rails 3/4系でもCookieが盗聴される場合は危険 -セッションをサーバーサイドで管理していないことに問題がある詳しく見ていきましょう。 [b http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html このためクロスサイトスクリプティング（XSS）などの攻撃を仕掛けられて情報を盗まれた場合、ユーザーのログイン情報が悪用される恐れがあるという。] Rails 4より前のCookieStoreは署名を使った改ざん防止は入っていますが、Cookieそのものは平文で保存されています。 XSSでCookieの情報が抜かれる脆弱性は、CookieのHttpOnly属性が有効になっていなかったRails 2系にはあったように思います。（昔の話なので自信がありませんが。。。） Rails 3系ではHttpOnly属性が有効になっているので、XSS脆弱性だけで抜かれる可能性は低いです。 Rails 4では暗号化されているので、こういった危険性はさらに低くなります。ただし・・・ [b http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html しかしマクナマラ氏はThreatpostに対し、「バージョン4.0以降にも問題は存在する。攻撃者が暗号化されたcookieをサーバに送信すれば、cookieのコンテンツを解読しなくても被害者になりすましてログインできる」とコメントしている。] このように書かれている通り、Cookieを盗聴されると内容が暗号化されていてもセッションハイジャックされる可能性があります。 [b http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html マクナマラ氏は解決策として、セッション情報がクライアントサイドではなくサーバサイドに保存されるcookie保存のメカニズム使用に切り替えるよう促している。] これは少し言葉足らずに思いました。例えば、MemcacheStoreを使ったとしても、Session IDをクライアントに置く以上、同様の問題があるはずで、MemcacheStoreに切り替えたからはい安心という種類の問題ではありません。（いや、おそらく大元ではそういう認識で話していないでしょうが。）本質的な問題点については、以下の記事が詳しいです。 Rails SessionにCookieStore使った時の問題点 http://oauth.jp/blog/2013/09/26/rails-session-cookie/ -サーバーサイドでセッション管理していないと、セッションがユーザーやセキュリティ上の意図を超えて有効になってしまう恐れがある --(a) 例えば、パスワードが漏れて変更した場合など、そのアカウントに紐づく全てのセッションが削除されるべき（少なくともパスワード入力を要求すべき）状況で対処することができない --(b) ユーザーがログアウトしても、ログイン中のCookieを保持していることによって、ログアウトしたはずのセッションでログイン状態を保持することが可能になってしまう -SSLを使うことは盗聴防止には有効でも、Cookieが漏えいしてしまえば同じ問題が発生しうる例えば、MemcacheStoreを使う場合、上記の(b)の問題はMemcachedからセッション情報を削除することで回避できます。(a)の問題は自動的には回避できません。ただ、サーバーサイドでセッション管理をするようになれば、回避するように実装することはできるでしょう。 CookieStoreだと難しいかもしれません。上記の記事でもふれられていますが、署名や署名の検証にアカウントや有効期限に紐づいた情報を含めることで対処する方法はあるかもしれません。いずれにせよセキュリティとコストはトレードオフだと思うので、問題点を認識した上で運営しているサービスに応じた実装を進めていくのがいいかと思います。不完全とはいえ、Railsのバージョンが進むごとにセキュリティ対策も進んでいくので、極力、最新に近づける努力はした方がいいですね。 ■ 余談 [b http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html マクナマラ氏はこの問題への対応状況を調べるため、9万サイトについて追跡調査を実施し、その結果を11月20日のブログで報告した。それによると、ユーザーの情報が暗号化されない古いバージョンのRuby on Railsをいまだに使っているサイトが1897件見つかったという。] 90000サイトを調べて、古いバージョンが1897件というのは少ないように思います。体感的にはもっと危険なサイトがありそうなのですが・・・。母数にはRailsじゃないサイトも含まれているのでしょうか。。。

艦これのイベントについて雑感

2013-11-20 09:18:56 +0900

司令部レベル80程度の中堅提督の雑感です。つまり、本日は平凡な提督の独り言としてお送りいたします。 !イベントクリアした！ 11/9にイベント「決戦！鉄底海峡を抜けて！」をクリアしました。 {{{b https://twitter.com/akasata/status/398833559860813824 E-5攻略完了。所要時間3時間。撃破はハイパーズ次第。金剛Lv80、榛名Lv98、島風Lv68、夕立Lv63、大井Lv95、北上Lv95。出撃回数は26回、ダメコン2回発動、消費資源は燃料・弾薬・鋼材それぞれ10000位、バケツは91個}}} 出撃の全記録を取ってあるので、紹介したいと思います。 !E4の全ログ -所要時間4時間 -出撃回数23回 -夕立Lv61、島風Lv66、榛名Lv97、金剛Lv78、大和Lv90、陸奥Lv52 -ダメコン1回発動 -費資源は燃料・弾薬・鋼材それぞれ15000位 -バケツ消費88個 [image /img/blog/20131120_e4.png] 画像を見るとわかるかと思いますが、最初の出撃10回以降、撤退率が劇的に下がっています。ある程度は事前に攻略情報を仕入れてはいたのですが、持っている艦娘のレベルや装備などを勘案しつつ、最適な編成を探るために、10回ほど試行錯誤のために出撃をしました。支援艦隊は入れるのを忘れてました（汗；なんか難しいな～とか思いつつ・・・。一言。 [font bold_#FF0000_xx-large 夕立、最強っぽい。] !E5の全ログ -所要時間3時間 -出撃回数26回 -金剛Lv80、榛名Lv98、島風Lv68、夕立Lv63、大井Lv95、北上Lv95 -ダメコン2回発動 -燃料・弾薬・鋼材それぞれ10000位 -バケツ消費91個 -支援艦隊はベールヌイLv74、時雨Lv53、飛鷹Lv66、隼鷹Lv58 [image /img/blog/20131120_e5.png] E5も10回程度試行錯誤で出撃しています。10回目からダメコン搭載開始。エラー撤退で涙をのんだり、ダメコン発動したのに削りきれなくて切なすぎる事態に発展したりしましたが、無事クリアできました。一言。 [font bold_#FF0000_xx-large 北上を信じろ。北上は強い。] !イベントについて雑感 E4クリア時にはガッツポーズが出ました。大変面白いイベントだったと思います。今回のイベントに関しては運ゲーという批判もあります。統計的に考えれば、理不尽なほどに運に左右される人というのもごくわずかに（数%もしくは1%未満）いるのは間違いないでしょう。少なくとも、イベント中の羅針盤の動作は福引券方式（はずれの回数を決めるなど）にすべきかなと思います。しかし、基本的には運以上にこのゲームを左右するのは戦略と戦術です。戦略というのは、資源の備蓄や情報収集（Wikiだけでなく出撃による威力偵察も）であり、戦術は決戦艦隊と支援艦隊の編成と言えるでしょう。無策で突っ込めばレベリングの意味が希薄（とはいえ、夜戦の多い今回のイベントはレベルによる練度は多少は影響してそうが気がしますが）な本ゲームにおいては、どれほど時間と資源を費やしたとしてもクリアできないでしょう。 # ダメコンは積んだ方が精神衛生上良いと思います。出撃回数が倍くらい変わるんじゃないかと。しかし、大変ストレスフルなゲームです。このゲームの最大のストレス要因はUIとレスポンスの遅さなので、それが改善されるだけで長時間プレーも快適になり、心が折れる提督も減ってくるんじゃないかなと思います。 !参考議論の発端となったまとめや、素晴らしい考察など。艦これイベントについての感想 http://togetter.com/li/590386 艦これのイベントについて僕も考えてみた http://tororosoba.hatenablog.com/entry/2013/11/20/001639