5.1が出ていたので、このブログをアップグレードしてみました。以下のコマンドを実施。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上で開発していると、共有フォルダのファイルの変更が検知できない事があるためです。以下の問題を対応しました。:backをredirect_backで書き換えたくらいです。その他、特に問題ありませんでした。以下、参考情報(と言うより一次情報)です。4.2から5.0に上げたら、production環境だけconfig.autoload_pathsが効かないという現象に遭遇したので、対策をメモっておきます。Guideによると、config.eager_loadとconfig.cache_classesがtrueだとconfig.enable_dependency_loadingがfalseになり、autoloadingが無効化されるようです。development環境ではこの2つをfalseにしている事が多いでしょうし、production環境ではtrueにしていることが多いと思うので、この問題に遭遇する人は多いのではないでしょうか。Applicationshttp://guides.rubyonrails.org/configuring.htmlでは、config.enable_dependency_loadingをtrueに設定すればいいのかというと、実際それで動くようにはなりますが・・・将来的にはこのオプションは削除されるようです。productionhttps://github.com/rails/rails/commit/80b416f5e692ae79f4062f59fed6c7d7648a8af0上記のコミットログにも、const_missingを利用しているアプリケーション向けに付けたオプションと書いてあるので、あくまで特殊なケースと位置づけているのでしょう。Guideを見返すとconfig.eager_load_pathsを見つけたので、これを使うことで解決することができました。log流し読み(2016/06/23)http://y-yagi.hatenablog.com/entry/2016/06/24/063207下記ブログでは、copy-on-writeの恩恵をうけるために本番ではautoloadを使うべきではないと紹介しています。IDEでeslintとjscsを設定してみた仕事でeslintとJSCSを使っているのですが、gulpで回しているだけだとlintエラーに素早く対処しにくいので、IDEでも設定してみることにしました。(私が主に使っているのはRubyMineです。以下のページを参考に設定を行いました。.eslintrcや.jscsrcを見に行くようにしているので、gulpでビルドするときにかかるチェックと同じものがかかります。JetBrainsIDE上では以下のような感じで動いています。JSCSはコンテキストメニューから自動整形も可能です。jscs@2.1.1にて発生)。余談ですが、JSCSとeslintの役割がかぶっている部分があるので、うまい具合にルールを切り分けたいと考えています。以下のコミットを見る限りeslintでもコードスタイルの自動整形が検討されているようなので、将来的にはeslintに一本化できるのかもしれません。当面は二本立てで様子見ですかね。4.2.0がでていたので、このブログをアップグレードしてみました。GemfileのRailsのバージョンを4.2.0にする4.2に限った話ではありませんが、一度新規アプリを生成してGemfileを見比べたほうがいいでしょう。Consoleのような新機能が追加されていますが、この機能を使うにはGemfileに該当するgemを追記する必要があります。以下のコマンドを実施。sでbindingされるIPが0.0.0.0からlocalhostに変わった(※)ので、仮想環境越しのアクセスが失敗するようになっています。(セキュリティ上の理由があるようです。)その場合は、以下のようにするとよいでしょう。1.6での仕様変更を受けてのようです。詳しくは以下のブログにあります。4.2」も参考になる(と言うより一次情報ですね)ので、参照するとよいでしょう。gemをインストールしようとしたら、ライブラリ(もしくはヘッダ)が足りないと怒られてコンパイルに失敗してしまいました。rroongaそこで、以下の記事を参考にライブラリとヘッダをインストールしてから再度インストールを試したところうまく行ったので、備忘録としてメモっておきます。rroonga過去に試した時は事前にパッケージを入れなくてもrroongaをインストールできた気がするので、たまたま何か前提となるパッケージが足りなかったとかそういう感じだと思いますが。Skyrim(TES)に出てくる「膝に矢」のアレtwitterを眺めていたら以下の様なtumblrが流れてきました。スカイリムの「膝に矢を受けてしまってな....」っていうアレ、現実のノルディックの言葉のようで、意味は「結婚した」を意味するらしい。衛兵は、本当に膝に矢を受けたのではなく、所帯を持ったから冒険者をやめて衛兵になったってことになるな。知らんかったわ.....http://reitan.tumblr.com/post/86853243927最初は「へー、北欧のスラングなのか」くらいの感想だったのですが、少し引っかかるものを覚えたのでボチボチとググってみました。以下の英語の記事を読むと、最初の回答にそのようなことが書かれているのですが、「ソースは?」「オレ、ノルドだけどそんなそんな言い回し使ったことないけど」的な反論が出ていて、ソースがあるものではないようです。Communityhttp://www.ask.com/answers/48485721/what-does-the-term-i-took-an-arrow-to-the-knee-mean上記のページでは、すね当ての装備スロットを活用することをアドバイスしているのではないかという説明もありますが、それはそれでちょっと味気ないです。Wind"というファンタジー小説に出てくる一節であるという指摘もされています。この小説の語り手である宿屋の主人Koteは若いころは伝説的な活躍をした魔法使いという設定のようで、なんとなくパロディとしてならおもしろい言い回しになっていると思います。Memehttp://knowyourmeme.com/memes/i-took-an-arrow-in-the-knee以下の記事にその前後の文章も引用されています。skyrimhttp://www.reddit.com/r/skyrim/comments/n4kne/arrow_in_the_knee_is_actually_a_literary_allusion/限界を感じて冒険者を引退した衛兵が、言い訳代わりに伝説の魔法使いの言い回しを真似ているとしたら・・・全くもって微笑ましい話だと思います。[書籍データの取得に失敗しました]・・・そういえば、我らがメタルマックスでは、結婚エンド(あるいはゲームオーバー?)は1992年から続く伝統になっています。3では平凡だが幸せな一生を送ったという趣旨の皮肉に満ちたエンディングに突入します。冒頭で引用した記事の「結婚して冒険者引退」と言うのはオープンRPGでは定番のネタともいうべきものなのかもしれません。4.1.0が出ていたので、このブログをアップグレードしてみました。例によって、作業ログを残しておきます。以下のコマンドを実施。注意点としては、セッションのシリアライズがRubyオブジェクトをMarshalする方式からjsonへのシリアライズに変更された関係か、私の環境では以下の様なエラーが出ました。{I"session_id:ETI"...config/initializers/cookies_serializer.rbのcookies_serializerを:hybridにするとうまい具合にmigrateしてくれます。(デフォルトは:jsonです。旧方式を使うなら:marshalを指定してください。:hybridJSON方式に変更すると、DateTimeなどのようにセッションにRubyオブジェクトを含めていた場合に問題が出るかもしれないので注意する必要がありそうです。4.0.2が出ていたので、セキュリティフィックスが含まれているということもあって、動かしているウェブアプリ(このブログ)を4.0.2にアップグレードしました。その際の作業ログをメモっておきます。以下のコマンドを実施。rails:updateの作業ログです。RailsのCookieStoreの脆弱性についてRailsのCookieStoreの脆弱性についていくつか報告記事が出ていたので、内容を検討してみました。SessionにCookieStore使った時の問題点http://oauth.jp/blog/2013/09/26/rails-session-cookie/読み合わせていくと、以下のような問題があるようです。3/4系でもCookieが盗聴される場合は危険セッションをサーバーサイドで管理していないことに問題がある詳しく見ていきましょう。このためクロスサイトスクリプティング(XSS)などの攻撃を仕掛けられて情報を盗まれた場合、ユーザーのログイン情報が悪用される恐れがあるという。4より前のCookieStoreは署名を使った改ざん防止は入っていますが、Cookieそのものは平文で保存されています。2系にはあったように思います。(昔の話なので自信がありませんが。3系ではHttpOnly属性が有効になっているので、XSS脆弱性だけで抜かれる可能性は低いです。4では暗号化されているので、こういった危険性はさらに低くなります。・・・しかしマクナマラ氏はThreatpostに対し、「バージョン4.0以降にも問題は存在する。攻撃者が暗号化されたcookieをサーバに送信すれば、cookieのコンテンツを解読しなくても被害者になりすましてログインできる」とコメントしている。http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.htmlこのように書かれている通り、Cookieを盗聴されると内容が暗号化されていてもセッションハイジャックされる可能性があります。マクナマラ氏は解決策として、セッション情報がクライアントサイドではなくサーバサイドに保存されるcookie保存のメカニズム使用に切り替えるよう促している。http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.htmlこれは少し言葉足らずに思いました。IDをクライアントに置く以上、同様の問題があるはずで、MemcacheStoreに切り替えたからはい安心という種類の問題ではありません。(いや、おそらく大元ではそういう認識で話していないでしょうが。)本質的な問題点については、以下の記事が詳しいです。ユーザーがログアウトしても、ログイン中のCookieを保持していることによって、ログアウトしたはずのセッションでログイン状態を保持することが可能になってしまうSSLを使うことは盗聴防止には有効でも、Cookieが漏えいしてしまえば同じ問題が発生しうる例えば、MemcacheStoreを使う場合、上記の(b)の問題はMemcachedからセッション情報を削除することで回避できます。(a)の問題は自動的には回避できません。サーバーサイドでセッション管理をするようになれば、回避するように実装することはできるでしょう。CookieStoreだと難しいかもしれません。上記の記事でもふれられていますが、署名や署名の検証にアカウントや有効期限に紐づいた情報を含めることで対処する方法はあるかもしれません。いずれにせよセキュリティとコストはトレードオフだと思うので、問題点を認識した上で運営しているサービスに応じた実装を進めていくのがいいかと思います。不完全とはいえ、Railsのバージョンが進むごとにセキュリティ対策も進んでいくので、極力、最新に近づける努力はした方がいいですね。余談マクナマラ氏はこの問題への対応状況を調べるため、9万サイトについて追跡調査を実施し、その結果を11月20日のブログで報告した。Railsをいまだに使っているサイトが1897件見つかったという。http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html90000サイトを調べて、古いバージョンが1897件というのは少ないように思います。体感的にはもっと危険なサイトがありそうなのですが・・・。母数にはRailsじゃないサイトも含まれているのでしょうか。司令部レベル80程度の中堅提督の雑感です。本日は平凡な提督の独り言としてお送りいたします。イベントクリアした!11/9にイベント「決戦!鉄底海峡を抜けて!」をクリアしました。撃破はハイパーズ次第。金剛Lv80、榛名Lv98、島風Lv68、夕立Lv63、大井Lv95、北上Lv95。出撃回数は26回、ダメコン2回発動、消費資源は燃料・弾薬・鋼材それぞれ10000位、バケツは91個https://twitter.com/akasata/status/398833559860813824出撃の全記録を取ってあるので、紹介したいと思います。画像を見るとわかるかと思いますが、最初の出撃10回以降、撤退率が劇的に下がっています。ある程度は事前に攻略情報を仕入れてはいたのですが、持っている艦娘のレベルや装備などを勘案しつつ、最適な編成を探るために、10回ほど試行錯誤のために出撃をしました。支援艦隊はベールヌイLv74、時雨Lv53、飛鷹Lv66、隼鷹Lv58E5も10回程度試行錯誤で出撃しています。10回目からダメコン搭載開始。エラー撤退で涙をのんだり、ダメコン発動したのに削りきれなくて切なすぎる事態に発展したりしましたが、無事クリアできました。