2018-07-16

自分のブログ（独自ドメインのはてなブログ）をHTTPS配信に切り替えました

Tips一般 Ruby お知らせ

はじめに

このブログ（give IT a try）をHTTPSで配信できるようにしました。
ブラウザのアドレスバーを見ると、鍵マーク🔒が見えているはずです。

f:id:JunichiIto:20180716082031p:plain:w400
f:id:JunichiIto:20180716082023j:plain:w400

2018年6月13日に、はてなブログが独自ドメインのHTTPS配信に対応したので（参考）、「そろそろこのブログもHTTPS化したいな〜」と思っていたのですが、ようやく対応できました。

今回のエントリでは僕がやったHTTPS化の手順をまとめてみます。

大まかな流れ

HTTPS配信するまでの大まかな流れはこんな感じです。

過去のエントリに含まれる混在コンテンツ（mixed content）を洗い出す
タイトルや内容は変えずに、各エントリの「更新」だけを実行する
まだ残っている混在コンテンツを洗い出す
手作業で残った混在コンテンツ問題を解消する
ヘッダやサイドバーなど、本文以外の混在コンテンツをなくす
テスト用のブログを作って、問題なくHTTPS配信できることを確認する
HTTPS配信に切り替える
動作確認と見つかった問題の修正

ちなみに、僕のブログは独自ドメインで運用していますが、hateblo.jpやhatenablog.comなど、はてなのドメインを使っている場合もステップ6以外は同じになるはずです。

各手順についてはそれぞれ以下で詳しく説明していきます。

1. 過去のエントリに含まれる混在コンテンツ（mixed content）を洗い出す

はてなブログをHTTPS配信する手順や注意点は以下のページにまとめられています。

help.hatenablog.com

この手順の中で一番面倒なのが、混在コンテンツの確認と解消です。

混在コンテンツとは簡単にいうと、HTTPS配信してるページ内で、HTTPで読み込もうとしている画像やiframeといったコンテンツのことです。
混在コンテンツが含まれると、ブラウザがそのコンテンツの読み込みを拒否したり、警告を出したりします。
なので、何らかの方法で混在コンテンツをHTTPSで読み込むように過去の記事を修正する必要があります。

・・・と、理屈と解決策はわかるのですが、問題はそれをどうやって見つけ、どうやって修正するか、です。
これまでに書いてきたブログエントリを数えたところ、僕は733件のブログを書いてきました。
これをいちいち手作業と目視で確認＆修正していくのは、あまりにも非現実的です。

とりあえず、修正をどうするかはおいといて、いったい自分のブログにどれくらい混在コンテンツが含まれるのかを把握しようと考えました。

混在コンテンツを洗い出すスクリプトを作った

僕はプログラマなので、手作業でやるよりも何でも自動化する方が好きです。
というわけでまず、世の中に混在コンテンツを洗い出してくれるプログラムがないか調査してみました。

調べてみるといくつかそれっぽいツールは見つけたのですが、どうも自分のニーズと微妙に合致しません。
なので、自分でスクリプトを書くことにしました。

それがこちらです。

github.com

といっても、これはあくまで自分用に作った、使い捨ての雑なRubyスクリプトです。
いちおう使い方はREADMEファイルに書いていますが、問題が起きても責任は取れません。
もし利用する場合は自己責任でお願いします。

混在コンテンツが含まれるエントリは733件中、約400件！

さて、このスクリプトを使って混在コンテンツを洗い出したところ、全733件中、約400件のエントリで混在コンテンツが見つかりました。ひえ〜、半分以上・・・😂

f:id:JunichiIto:20180716054204p:plain

とりあえず、この一覧を見ながら「傾向と対策」を考えました。

2. タイトルや内容は変えずに、各エントリの「更新」だけを実行する

混在コンテンツの一覧を見ていると、大半が以下のようなコンテンツでした。

ブログに貼り付けたオリジナルの画像
Amazonの商品リンクに含まれる画像
下の画像のような埋め込み（embed）タイプの過去記事のリンク（iframeが使われている）

f:id:JunichiIto:20180716054616p:plain:w400

ですが、こうしたコンテンツは最近のエントリでは混在コンテンツになっていません。
どうも2017年6月頃からはてなブログの仕様が変わったらしく、最近投稿したエントリでは全部自動的にHTTPS扱いになるみたいです。

過去記事の混在コンテンツも更新を実行すればHTTPSに切り替わる

この問題については以下のページで解決策が載っています。

編集画面を「はてな記法モード」や「Markdownモード」でご利用で、[f:id:sample:20180308000000j:plain]というような記載で画像を貼り付けている方は、記事を再度「更新する」ことで解消します。
　
【よくある質問】HTTPS配信時の混在コンテンツ（Mixed Content）対応について - はてなブログヘルプ

実際に手元で試したところ、画像だけでなく、Amazonの商品リンクや過去記事のリンクも「更新する」を実行すれば、HTTPSに切り替わることを確認しました。

過去記事に対して無変更で「更新」だけを実行するスクリプトを作った

さて、「更新する」を実行すれば修正可能であることがわかったものの、問題はそれを400件の過去記事にどうやって適用するかです。

400件をプチプチと手作業で更新していく？
いや、無理でしょう！！

というわけで、今回も自分でスクリプトを作ることにしました。
前述のGitHubページの中にあるupdate_allというタスクがそれです。
このタスクは、指定されたページのタイトルや本文を変更することなく、純粋に「記事の更新」だけを実行してくれます。

念のため、過去記事のバックアップを取ってから、このスクリプトを使って混在コンテンツが含まれる400件のエントリを更新していきました。

3. まだ残っている混在コンテンツを洗い出す

さあ、これで大半の混在コンテンツ問題が解消されたはず！！・・・と思ったのですが、前述のスクリプトを使って再度確認したところ、まだ69件のエントリで混在コンテンツが残っていることがわかりました💧

f:id:JunichiIto:20180716070213p:plain

4. 手作業で残った混在コンテンツ問題を解消する

記事の更新だけでは解消されなかった混在コンテンツは、だいたい以下のようなケースです。

HTMLタグを使って埋め込んだSlideShareのスライドやFlickrの画像
はてなダイアリー時代に、はてな記法で埋め込んだYouTubeの動画やTwitterのツイート

これらはどうしようもないので、手作業で修正していきます。
僕の場合は69件のエントリを修正するのに、約2時間かかりました。

もっと大量に残っている人は、これまた専用の自動修正スクリプトを作った方がいいかもしれません。

5. ヘッダやサイドバーなど、本文以外の混在コンテンツをなくす

ここまで修正してきたのは記事本文の混在コンテンツです。
ヘッダやサイドバーなど、ブログのデザインに関連する部分にも混在コンテンツが残っているかもしれないので、それも確認します。

これはサイト共通の設定なので手作業や目視で確認してもそこまで手間ではないと思います。
ですが、せっかくなので僕は本文用に作った確認スクリプトを拡張して、機械的にチェックできるようにしました。

すると、サイドバーで使用している一部のJavaScriptやロゴ画像に混在コンテンツが見つかりました。
見つかった混在コンテンツについては、手作業で修正していきました。

修正が終わったら再度確認スクリプトを流して、全ページにおいて混在コンテンツがなくなったことを確認します。

6. テスト用のブログを作って、問題なくHTTPS配信できることを確認する

さて、これでほぼ準備は整ったのですが、万一予期しない問題（自分のブログに誰もアクセスできなくなる等）が起きると怖いので、テスト用のはてなブログを独自ドメインで立ち上げ、問題なくHTTPS配信できることを確認しました。

テスト用ブログで確認する限り、独自ドメインを使っても特に問題なくHTTPS配信できました。

ちなみに、新しくはてなブログを立ち上げると最初からHTTPS配信になるため、テスト用ブログではHTTPとHTTPSの比較はできません。

7. HTTPS配信に切り替える

さあ、準備が整いました。いよいよHTTPS配信に切り替えます！

HTTPS配信の切り替えは、「設定画面 > 詳細設定 > HTTPS配信」で設定を切り替えるだけです（参考）。

一度HTTPS配信に変更するとHTTPには戻せないため、ちょっとドキドキしながら切り替えを実行しました！！

さあ、どうかな？ちゃんとHTTPSでアクセスできるかな？？

・・・あれ、エラーが出てる（ガーン😱）。

と思ったのですが、実はヘルプページに「切り替え直後には一時的なエラーが起きる場合がある」と書いてあります。

独自ドメインで運用しているブログをHTTPS配信に変更した後、ごく一部のブログで「この接続ではプライバシーが保護されません」といったエラーが表示され、アクセスできないことがあります。

その場合は、設定画面から、HTTPS配信の状況をご確認ください。無効（移行中）と表示されている場合は、数分程度でエラーが解消されます。
　
HTTPSで配信する - はてなブログヘルプ

このヘルプに書いてあるとおり、数十秒待ってから再読み込みすると、無事にHTTPSでアクセスできるようになりました。

ちょっとビックリしましたが、これでいったんめでたしめでたしです。

8. 動作確認と見つかった問題の修正

さて、混在コンテンツ問題が解消し、全く何も問題がない状態になっていれば、Chromeのアドレスバーにグリーンの鍵マークが出ているはずです。
ですが、最初に開いたときはグリーンになっていませんでした（あれあれ？）。

原因を調べてみると、サイドバーで読み込んでいた一部のJavaScriptが内部でHTTPの画像やCSSを読み込むようになっており、混在コンテンツ問題が完全に解決していませんでした。

そこでHTTPではなく、HTTPSで画像やCSSを読み込むようにJavaScriptを修正したところ、混在コンテンツ問題が解消し、めでたくグリーンの鍵マークが表示されました💚

f:id:JunichiIto:20180716051026p:plain:w400

また、ヘルプページにも書いてあるとおり、過去のエントリに付いていた、はてなブックマークやはてなスターもちゃんと移行されていました。
ヘルプには「移行に時間がかかる場合がある」と書いてありましたが、上の混在コンテンツ問題を解決した頃にははてなブックマークやはてなスターの移行は全部完了していました。

これで移行作業は一通り完了です。
最後にTwitterでHTTPSに移行したことを完了しておきました。

勢いでブログをHTTPS化してみました。mixed content問題もたぶん解決してるはず！何かおかしな部分に気づいたら、教えてください〜。https://t.co/irheMGOJiM pic.twitter.com/Uorvu0aruA
— Junichi Ito (伊藤淳一) (@jnchito) 2018年7月15日

トータルの作業時間

移行にかかった作業時間は正確に記録したわけではありませんが、たぶん全部で10時間ぐらいだと思います。
そのうちの半分以上はスクリプトを作っていた時間です。

10時間というとかなりの重労働っぽく見えるかもしれませんが、混在コンテンツの対応はもっと大変なのかと思っていたので、予想よりも早く終わりました。
（でもスクリプトなしで全部手作業でやってたら、本当に大変だったでしょうね・・・）

まとめ

というわけで、このエントリでは自分のブログをHTTPS配信する一連の作業を紹介してみました。

今回は自分でスクリプトを作成しましたが、混在コンテンツの洗い出しや、混在コンテンツ問題を解消するための機械的な更新作業は多くの人が必要とする機能だと思います。
なので、こうした機能はできればはてなブログの公式ツールとして事前に用意してもらえると嬉しいなあと思います。

とはいえ、技術的には独自ドメインのHTTPS配信に対応するだけでも大変だったと思います。
はてなブログの中のみなさんはどうもお疲れ様でした。

まだご自分のはてなブログをHTTPS配信していない人はこのエントリを参考にして、HTTPS配信にチャレンジしてみてください！

謝辞

このツール自体は利用していませんが、「混在コンテンツ洗い出しスクリプト」を作成する際に、「--fix-mixed-contentの動作」の項で説明されている内容を参考にさせてもらいました。
smdn.jp

「無変更で過去記事の更新だけを実行するスクリプト」では、こちらのhatenablog gemを利用させてもらいました。
Rubyから手軽にはてなブログAPIを操作できたので非常に助かりました。
github.com

2018-07-12

西日本豪雨災害義援金に寄付しました + 自宅周辺の当時の状況など

お知らせチェリー本 Everyday Rails

お知らせ

昨日、平成30年7月西日本豪雨災害の義援金として、日本赤十字社を通じて3万円を寄付しました。
被災されたみなさまには心よりお見舞い申し上げます。

f:id:JunichiIto:20180712054154p:plain

先日の豪雨について

僕が住んでいる兵庫県西脇市でも7月5日から8日にかけて、断続的に大雨が降りました。
今までも数年おきに台風等の影響で大雨が降ることはありましたが、これだけの大雨が連日続いたのは初めてだったと思います。

自宅の前を流れる加古川は、数年前に行われた河川工事のおかげで、かなりの雨量に耐えられるようになっていましたが、今回の大雨では「ちょっとヤバくない？」というレベル（5m超）にまで水位が上昇しました。

f:id:JunichiIto:20180712055140j:plain — 2018年7月7日12時頃（撮影: 知人のMさん）

ちなみに普段の水位はこれぐらい（数10cm）です。

f:id:JunichiIto:20180712055604j:plain

自宅の窓から家の外を眺めるとこんな状態でした。

f:id:JunichiIto:20180712055934j:plain

妻の親戚の家に自主避難

川の水位は「今すぐ氾濫する！」というレベルではなかったのですが、警報はたくさん出てるし、「あ、これはマジでヤバいかも」と思ったときに動き始めても遅いです（自分の身に危険が及ぶだけでなく、他の人も一斉に動き出すので道路も渋滞してしまう）。
それに、川が氾濫する前に堤防が決壊する恐れもあります。

自宅の周辺が大丈夫でも周囲の道路が寸断されたりしたら、結局遠くへ移動できなくなります。
天気予報を見てもまだまだ雨は止みそうにないので、事態が悪化することはあっても、好転することはしばらくなさそうです。

このような状況を勘案した結果、「よし、まだ余裕があるうちに、いったんここを離れよう」と決断し、7日の早朝に妻の親戚の家に一家で避難させてもらいました。
今までも何度か「川の水位がかなり上がってきたなあ」と思うことはありましたが、避難まですることは滅多にありませんでした。

「これまでにないぐらい川の水位が上がっている＋このあともまだまだ雨が止みそうにない」という悪条件が重なることはそうそうありません。
「数十年に一度の大雨」と言われる大雨特別警報が発令されただけのことはあります。

自宅の周辺はなんとか持ちこたえたけど

7日の午後からはちょっとずつ雨脚も弱まり、川の水位も少しずつ低下したので、夕方頃に自宅に戻りました。
西脇市内の一部地域や周辺の地区町村では若干の浸水被害もあったようですが、僕の自宅の周辺では幸い大きな被害出ませんでした。

しかし、今回の豪雨については本当に「運が良かっただけ」かもしれません。
各地で報告されている水害や土砂崩れの被害を見ていると、「これって、この周辺で同じ災害が起きても全然おかしくないよなあ」と思ってしまいました。
実際、8日に車で出かけたときは、あちこちで軽い土砂崩れが発生してブルーシートが掛けられている光景を見かけました。

今回、僕が個人的に義援金を寄付したのは、このように「この災害は全然他人事ではない」と感じたためです。
この先いつか、自分が義援金のお世話になる可能性もないとは言い切れないので、Give and Takeの精神で寄付させてもらいました。

義援金を寄付できたのはみなさんに本を買っていただいたおかげです

ちなみに今回の義援金の出所は、今まで書いてきた本の印税の一部です。
おかげさまで「プロを目指す人のためのRuby入門」や「Everyday Rails - RSpecによるRailsテスト入門」の売上が好調なので、印税も思った以上にたくさん入ってきています（と書くと、若干いやらしい話になりますが）。

なので、「プロを目指す人のためのRuby入門」や「Everyday Rails - RSpecによるRailsテスト入門」を購入してくださったみなさんは、今回行った寄付の貢献者の一人です！

一方で、今回被災された方の中には、もしかすると読者の方が含まれているかもしれません。
もし、床上浸水の影響で「プロを目指す人のためのRuby入門」が読めなくなったという人がいたら、電子書籍版を無償提供することもできますので、Twitter等で声をかけてください。

プロを目指す人のためのRuby入門言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

作者: 伊藤淳一
出版社/メーカー: 技術評論社
発売日: 2017/11/25
メディア: 大型本
この商品を含むブログを見る

Everyday Rails - RSpecによるRailsテスト入門 | Leanpub

まとめ

というわけで、今回のエントリでは平成30年7月西日本豪雨災害の義援金を寄付した話と、自宅周辺の当時の状況をあれこれ書いてみました。

それにしても今回の豪雨災害については、「台風が来たわけでもないのに、大雨だけでここまで大きな被害が出るのか」と、自然の恐ろしさを改めて感じさせられました。

あらためて、被害に遭われたみなさまには心からお見舞いを申し上げるとともに、一日も早い復興を願っています。

f:id:JunichiIto:20180712074755j:plain

被災地の支援に関する情報源

僕はこのページから募金先を見つけました。
自分のできる範囲で構わないので、みなさんも何かしらの支援を検討してみてください。

あわせて読みたい

2016年の熊本地震でも本の売上げを寄付させてもらいました。

先月は大阪で大地震に遭遇したので、立て続けに自然の恐ろしさを実感させられています。

2018-07-10

Everyday Railsの小規模なアップデートを実施しました

Everyday Rails お知らせ Ruby

お知らせ

僕が翻訳者の1人として参加している電子書籍「Everyday Rails - RSpecによるRailsテスト入門」の小規模なアップデートを実施しました。

購入者の方にはおそらく通知メールが飛んでいるはずです。
アップデート版をダウンロードする場合はLeanpubにログインして、Libraryページにアクセスしてください。
（または通知メールに記載されたリンクからもダウンロードできます）

アップデート版のダウンロードはもちろん無料です。

Everyday Rails - RSpecによるRailsテスト入門 | Leanpub
f:id:JunichiIto:20180219082935p:plain

具体的なアップデート内容

今回のアップデートでは原著の2018年6月4日版に追従しました。
とはいえ、2018年6月4日版のアップデート内容はそれほど大規模なものではなく、いくつかの小粒なアップデートをまとめてリリースしたような内容になっています。

興味深い変更点をあえて挙げるなら、以下の2点でしょうか。

ChromeDriverのインストールにchromedriver-helper gemを使うようになったところ
Factory GirlがFactory Botに変わったところ

chromedriver-helperは便利なので僕もよく使っています。

また、Rails開発者であればFactoryGirlの名前がFactoryBotに変わったというニュースもすでにご存じなのではないでしょうか。

今回のアップデートにより、Everyday Railsを読む際にgemの名前を毎回頭の中で読み替えずに済みますね。

その他、環境やバージョンによる違いなど

Rails 5.2でも基本的な考え方は同じです

本書はRails 5.1を対象にしていますが、現時点（2018年7月）の最新版であるRails 5.2を使う場合でも基本的な考え方は同じなので、本書の内容はほぼそのまま適用可能です。

ただし、Rails 5.2とrspec-rails 3.7で動かす場合は、サンプルアプリケーションのテストコードで以下の変更が必要になります。

コントローラスペックとリクエストスペック: expect(response).to be_successをexpect(response).to be_successfulに変更する
リクエストスペック: expect(response).to have_http_status(:success)をexpect(response).to be_successfulに変更する

具体的な変更点については、こちらのdiff（差分）も参考にしてください。

https://github.com/everydayrails/everydayrails-rspec-2017/compare/master...JunichiIto:rails-5-2

システムスペックについて

rspec-rails 3.7ではフィーチャスペックの代わりにシステムスペックというタイプのテストを書くことができます（ただし、システムスペックを使う場合はRails 5.1以上が必要）。
システムスペックの説明やフィーチャスペックからシステムスペックに移行する方法を知りたい場合は、以下のブログ記事を参照してください。

サンプルアプリケーションはRuby 2.4、またはDevise 4.4以上で動かしてください

本書のサンプルアプリケーションは以下のリポジトリで公開されています。

ただし、2018年7月時点のmasterブランチのテストコードをRuby 2.5で動かそうとすると、以下のようなエラーが発生します。

Failures:

  1) Sign in user signs in
     Failure/Error: click_link "Sign In"
     
     SyntaxError:
       /Users/jnito/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/devise-4.3.0/app/controllers/devise/sessions_controller.rb:5: syntax error, unexpected '{', expecting keyword_end
       ...ion only: [:create, :destroy] { request.env["devise.skip_tim...
       ...                              ^
       /Users/jnito/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/devise-4.3.0/app/controllers/devise/sessions_controller.rb:5: syntax error, unexpected '}', expecting keyword_end
       ..."devise.skip_timeout"] = true }
       ...                              ^
     # ./spec/features/sign_ins_spec.rb:12:in `block (2 levels) in <top (required)>'
     # -e:1:in `<main>'

Finished in 9.24 seconds (files took 3.78 seconds to load)
70 examples, 1 failure

Failed examples:

rspec ./spec/features/sign_ins_spec.rb:10 # Sign in user signs in

これはサンプルアプリケーションのDeviseのバージョンが古いのが原因です（参考）。

Ruby 2.5ではなく、2.4に落として実行すると、正常に動作します。
rbenvを使っている場合は以下のコマンドでRubyのバージョンを指定してください（以下の例ではRuby 2.4.4を指定していますが、2.4系であれば他のバージョンでも構いません）。