Tech系サービスやガジェットの使い心地、自分の作業環境、資産運用について気が向いたときに記録を残しています。

記事内のAmazonアソシエイト適格販売及び、Google Adsenseでお小遣いを得ています。

Custom Vision Service(Object Detection)で東方キャラを検出してみた

Custom Visionとは?

Custom Vision Service とは https://docs.microsoft.com/ja-jp/azure/cognitive-services/custom-vision-service/home

Custom Vision Service は、カスタム画像分類子の構築を支援する Microsoft Cognitive Services です。 画像の分類子を簡単に素早く構築、デプロイし、その性能を向上させることができます。 Custom Vision Service には、画像をアップロードして分類子をトレーニングするための REST API や Web インターフェイスが用意されています。

ざっくりいうと、画像認識のためのロジックは全部Microsoftがやってくれるので、ユーザーは学習データの投入・タグ付けをやるだけでAPI経由で推論結果を得られるというサービスです。 サービスイン当初は分類器のみでしたが、5/7のアップデートで物体検出(特定部分の座標取得)ができるようになりました。仕事で軽くプロトタイプを作ってみたところ、そこそこ使えそうな精度になったのでプライベート向けの題材で学習して公開してみることにしました。

東方Projectのキャラ判定機を作ろう

物体検出の題材として、学習データの分量を用意できることが必須かつ「分類することの意味」にもこだわってみたかったので東方キャラを題材に選んでみました。学習材料は自宅にある薄い本+公式書籍+αとなっております。 作業を簡略化するため、下記の条件に当てはまる箇所を撮影して学習データを用意します。

  • 表紙
  • 裏表紙
  • フルカラー

コードサンプルはこちら

GitHub : gensobunya/try-customvision

1.学習データを準備

  1. ログイン後、規約に同意してプロジェクト作成を選択すると、下のような画像アップロード画面に移動します。 f:id:gensobunya:20180630130525j:plain

  2. 学習データ(薄い本)を用意して1枚づつ裏表紙を撮影していきます。 f:id:gensobunya:20180630131414j:plain

  3. アップロードします f:id:gensobunya:20180630141126j:plain

  4. ドラッグ&ドロップでエリア選択をして、タグ付けします f:id:gensobunya:20180630141218j:plain

基本的にすべてマニュアル作業となりますが、編集画面で物体検出を自動でやってくれたりして結構スマートです。点線は自動検出部分。

f:id:gensobunya:20180630141424j:plain

2.学習させる

右上の「Train」ボタンを押すだけ…なのですが1タグあたり15枚以上の画像が必須となっているので、微妙に足りないキャラの学習データをフルカラーイラスト集から追加したり、全く足りないキャラのタグを削除したりします。
そもそも50タグが無料版の限界なので、東方キャラ全員の検知は不可能ですね…

f:id:gensobunya:20180630144324j:plain

初期状態で残ったキャラは以下の通りです。

学習が完了すると、試験結果も表示してくれます。特に何もしていないのでバランスが悪いですね… 学習結果と学習内容はIteration単位で保存されていますので、バージョン管理に活用できます。

検出の確信度閾値は左上のスライダーで調整できます。 よほど閾値を下げない限り、Precision>>>Recallとなっているので、そもそもキャラを拾い出すことに苦労している感じですね。

f:id:gensobunya:20180716144039j:plain

APIで結果を得ることもできるのですが、まずは画面上のQuick Testを使って、学習に使っていない電撃Playstationの表紙を判定させてみます。

f:id:gensobunya:20200312182427p:plain

霊夢は正しく検出できました!魔理沙は…がんばりましょう。

3.学習内容を改善する

まだまだ使いものにならないのでもうちょっとマシな学習内容を目指します。 閾値を0にして確認すると、霊夢は12%の確率で魔理沙ですが魔理沙は1.9%の確率でしか魔理沙と思われていません。

f:id:gensobunya:20200312182439p:plain

学習ロジックはいじれないので、学習データを下記の通りいじって再度Trainingします。だいたい5分から10分くらいでモデルが出来上がるので爆速と言って過言ではないでしょう。

  • データの少ないキャラタグを削除
  • 衣装変更(コート着・社会派ルポライターあや・他)を削除
  • 学習データ追加

結果、下記のキャラ(数字はデータ枚数)が残りました。主人公sと書籍キャラが多く残りましたね…

f:id:gensobunya:20200312182454p:plain

もう1度、電撃Playstationの表紙でテストします。

f:id:gensobunya:20200312182505p:plain 未だ魔理沙発見できず。0%時の候補からも消えてしまいました。 他の画像でも霊夢が射命丸になったりするので、あまりいいモデルとは言えません。

仕事で作ったときのように、全タグの学習枚数を揃えると精度があがるかもしれませんが、時間がかかるので今回はここまでにします。

4.WEBアプリ化する

APIを用いてWEBアプリ化します。PredictionURLをクリックして、必要な情報を確認できます。

f:id:gensobunya:20200312182520p:plain

Vue.jsとAxiosを使って適当に実装します。公開するときはAPIキーを隠すべきですがとりあえずローカルで動かしたいだけなので気にせず直接書きます。 APIJSON形式で検出したエリアを返してくるので、確信度でフィルタした後に画像にオーバーレイしてループしてボックス表示します。

  <template>
    <div id="app">

        <h2>SanteMedical Detector(Proto)</h2>
        <div>
            <input type="file" name="file" @change="onFileChange" class="waves-effect waves-light btn">
        </div>
        <div class="buttonwrapper" v-if="image">
          <button @click="removeImage" class="waves-effect waves-light btn">Remove image</button>
          <button @click="submitImage" class="waves-effect waves-light btn">Submit image
            <i class="material-icons right">send</i>
          </button>
        </div>
      <div v-if="image">
        <div class="imagewrapper">
          <img :src="image" />
          <div v-if="predictionData" v-for="prediction in predictionData" :key="prediction.tagID" class="detectionBox" :style="{width:prediction.boundingBox.width*100+'%',height:prediction.boundingBox.height*100+'%',left:prediction.boundingBox.left*100+'%',top:prediction.boundingBox.top*100+'%'}"></div>
        </div>
      </div>
      <div v-if="predictionData" class="tagwrapper">
        <ul class="collection">
          <li class="collection-header">
            <h4>Detected Tags</h4>
          </li>
          <li v-for="prediction in predictionData" :key="prediction.tagID" class="collection-item">
            <b>{{prediction.tagName}}</b>:{{prediction.probability}}
          </li>
        </ul>
      </div>
    </div>
</template>

<script>
import loadImage from 'blueimp-load-image'
import axios from 'axios'

const projectId = "YOUR PROJECT ID";
const predictionKey = "YOUR PREDICTION KEY";
const postURL = "https://southcentralus.api.cognitive.microsoft.com/customvision/v2.0/Prediction/"+projectId+"/image";
const probabilityLine = 0.15; //確信度閾値


export default {
  name: 'app',
  data: function() {
    return {
      image: '',
      imgName: '',
      imgHeight: '',
      imgWidth:'',
      uploadFile: '',
      predictionData:''
    }
  },
  methods: {
      onFileChange: function(e){
        let files = e.target.files || e.dataTransfer.files;
        if (!files.length) {
            return;
        }
        if (!files[0].type.match('image.*')) {
            return;
        }

        this.createImage(files[0]);
        this.uploadFile = files[0];
        this.predictionData = '';
        this.occupancyRate ='';
        console.log(postURL);
      },
      createImage: function(file) {
        let reader = new FileReader();

        reader.onload = (e) => {
          //ローテーション
          loadImage.parseMetaData(file, (data) => {
            const options = {
              canvas: true
            };
            if (data.exif) {
              options.orientation = data.exif.get('Orientation');
            }
            loadImage(e.target.result, (canvas) => {
              const dataUri = canvas.toDataURL('image/jpeg');
              this.image = dataUri;
              this.imgHeight = canvas.height;
              this.imgWidth = canvas.width;
            }, options);
          });
          //ローテーションここまで
        }
        reader.readAsDataURL(file);
        this.imgName = file.name;
      },
      removeImage: function() {
        this.image = '';
        this.imgName = '';
        this.predictionData = '';
        this.occupancyRate ='';
      },
      submitImage:function() {
        let formData = new FormData();
        formData.append('shelfImage', this.uploadFile);
        let config = {
            method : 'post',
            headers: {
                'content-type': "multipart/form-data",
                'Prediction-Key': predictionKey
                }
        };

        axios.post(postURL, formData, config)
            .then(response => {
                //response 処理
                //確信度フィルタリング
                this.predictionData = response.data.predictions.filter( (items) => Number(items.probability) > probabilityLine);
              })
            .catch(error => {
                  // error 処理
                  this.predictionData = error;
            })
      }
  }
};
</script>

<style>
#app {
    text-align: center;
  }
img {
    width: 100%;
    margin: auto;
    display: block;
    margin-bottom: 10px;
  }
button{
  margin: 10px;
}
.imagewrapper{
  display: inline-block;
  width: 30%;
  position: relative;
  margin: 0px;
  padding: 0px;
  align-self: center;
}
.buttonwrapper{
  padding: 1em;
}
.detectionBox{
  position: absolute;
  border-width: 2px;
  border-style: solid;
  border-color: red;
}
</style>

Materializeを使って適当に装飾して、このように表示されます。 f:id:gensobunya:20200312182530p:plain

QiiTopSetというChrome拡張を作った

f:id:gensobunya:20191108220420j:plain
code

タグフィードを最初に見たいんだ!

Qiitaのデザイン変更に伴って、qiita.comへアクセスした際にqiita.com/trendへリダイレクトされる仕様が追加されて幾星霜。 最初は面白かったのですが、やはり興味のある分野に関する記事を探す頻度のほうが高いわけでしてアクセス即タグフィードクリック生活をしていましした。

時間の無駄なのでブックマークをタグフィードのURLに変更しようかと思いましたが、それでは面白くないのでChrome拡張で実装してみました。 普段仕事でコードを書いているわけではないので、記法の古さや使い回しにくさ、そもそもの可読性に難がある可能性大です。

オプション画面からリダイレクト先をタグフィードとタイムラインで切り替え可能です。

インストールはこちらから! Chrome web store - QiiTopSet ※仕様変更により動作しなくなったので、公開を終了しました

Code

Github - QiiTopSet

本体

Chrome ExtensionのAPIが全て非同期処理でコールバックを呼ぶ前提になっているので、中々苦戦しました。 chrome.storage.local.get のコールバック関数内にすべての処理を書くことで、設定取得→リダイレクト処理の順番で処理させることに成功しています。

//Qiitaのトップをタグフィードにリダイレクトする
'use strict';

const qiitaBaseUrl = "https://qiita.com/";

chrome.storage.local.get({"redirectPage": "tag-feed" }, (items)=>{

    let redirectFullUrl = qiitaBaseUrl + items.redirectPage;

    chrome.webRequest.onBeforeRequest.addListener( (detail) =>{
        return {redirectUrl : redirectFullUrl};
    },
        {urls: ["*://qiita.com/trend"]}, //リクエスト先がtrendになった場合発火
        ["blocking"]
    )
    console.log("redirect to "+ qiitaBaseUrl + items.redirectPage);

    //設定変更を監視
    chrome.storage.onChanged.addListener((newItems)=>{
        redirectFullUrl = qiitaBaseUrl + newItems.redirectPage.newValue;
        console.log("change redirect url to" + redirectFullUrl);
        })
    }
)

ただし、この方法だとChrome起動時に設定が変更された場合、リダイレクト処理に反映されないのでchrome.storage.onChangedを使って変更検知のロジックを入れています。 オプション画面で設定しないと設定用のオブジェクトそのものがundefinedになってしまいますが、chrome.storage.local.get({"redirectPage": "tag-feed" }...と記述することでnullの場合の初期値を設定できます。

chrome.storage.localではなくchrome.storage.syncを使っていれば同一Googleアカウントで設定を同期できますが、テストが面倒なので実施していません。

オプション用のページ

あまり面白みはありません。公式サンプルをちょいちょいと改造しただけです。

追記

下記のコードに加えて、「全ての投稿」も選択できるようにアップデートしました。

<!DOCTYPE html>
<html>
<head><title></title></head>
<body>

リダイレクト先:
<select id="redirectTo">
 <option value="tag-feed">タグフィード</option>
 <option value="timeline">タイムライン</option>
</select>

<div id="status"></div>
<button id="save">Save</button>

<script src="options.js"></script>
</body>
</html>

Chrome.storageAPIを使ってローカルストレージにオプションをオブジェクトとして保存しています。

'use strict';

const storage = chrome.storage.local;

// options.htmlからリダイレクト先を取得してobjectに格納
function save_options() {
    const page = {
        redirectPage : document.getElementById('redirectTo').value
    };

// オブジェクトをchrome.storage.localに保存
    storage.set(page,function() {
            let status = document.getElementById('status');
            status.textContent = 'Saved!'; //ボタン押したらフィードバック
            console.log('option saved as ' + page.redirectPage);

            setTimeout(function() {
                status.textContent = '';
                }, 750); //フィードバックを消す
          }
    );
}

// 初期表示は保存されている内容を表示する
function restore_options() {
    storage.get({
        redirectPage: "timeline" //getデータが無い時のための初期値
    },function(items) {
        document.getElementById('redirectTo').value = items.redirectPage;
    });
}
document.addEventListener('DOMContentLoaded', restore_options);
document.getElementById('save').addEventListener('click',save_options);

WP+GCEからHugo+Netlifyへの移行

f:id:gensobunya:20191108215555p:plain
hugo logo

静的サイトジェネレーターへの移行

性能・HTTPS対応などなどについて無料IaaSとWordPressを越えるものを探していたところ、静的サイトジェネレーターという存在を発見。

編集こそ、Markdownの作成で開発者向けではあるものの、HTML直打ちに比べるとテーマの適用やレイアウトのテンプレート化・ページングやタグページの生成などなど、圧倒的なメリットを得られる…

最終的に公開されるものは静的ファイルだけなので当然性能も良いしサーバの性能もそこまで必要ない。有名なツールはいくつかあったが、生成スピードとGolangに興味があったこともあってHugoを選択。特徴は以下の通り。

  • 超速ビルド(1記事1msec程度)
  • ローカルサーバ機能(hugo serve)コマンド打てばローカルですぐに検証できる
  • ドキュメントが割としっかりしている
  • テーマそこそこいっぱい

ホスティングはNetlify

静的ファイル配信にIaaS使うのはあまりにもアホらしいのでホスティングを探す。\ 定番はS3やCloudStrageの静的WEBサイト配信機能を使うことだが、CDNが有料だったりリダイレクトを維持できなかったりと少し課題あり。

そんな中Netlifyというすごいサービスがあることを知る。

HTTPSの静的コンテンツをホストするならs3よりNetlifyが俺の求めていたものだった https://qiita.com/shogomuranushi/items/6ab5bc29923b3f82c9ed

  • 1クリックでSSL(Let's encryptの証明書を自動取得・更新)
  • HTTP/2対応
  • CDN標準装備
  • Gitから更新検知して自動ビルド(!)
  • リダイレクト設定可能(独自記法)
  • 独自ドメイン利用可能(SSLもOK)
  • ここまで全部無料

要件全部満たしていたので即決! 以下は備忘録なので細かい手順は省いて設定とやったことのみダラダラと記載していく。

WordPressのデータをHugo用にエクスポートする

WordPress to Hugo ExporterというWordPressプラグインを利用。WPのプラグインディレクトリに置いて、管理画面にログインして有効化する。あとは1クリックで画像と記事の.mdファイルをZIPでダウンロードできる。以上!

Markdownの仕様上、広告などのインデントが深いとコード記述扱いされてしまうのでVSCodeの置換を使ってシコシコ修正する。

タグやカテゴリ、パーマリンクなどはHugo用のヘッダー部分が作成されており、そこに格納されている。サンプルは以下の通り。

---
title: 格安サイコンbryton Rider310を使ってみた
author: gen
type: post
date: 2017-09-27T11:26:26+00:00
thumbnail: DSC_7899.jpg
categories:
  - 未分類
tags:
  - インプレ
  - ガジェット

サムネイルは能動的に設定しないと作ってくれなかったので、自分で全記事に対して作成した…\ urlは所謂パーマリンク設定がそのまま反映される。hugoでは基本的に記事が/post/記事名/になってしまうが、この項目に設定をしておけば過去のURLを維持できる。

Hugoインストール、動作

Chocolatey経由でGoとHugoをインストールする。 作業したいディレクトリ上でhugo new siteを打てばよろしくディレクトリ構造を作ってくれる。

WPからダウンロードしたMarkdownファイルを/post/へ、画像ファイルは/static/へそれぞれ移動。 作業ディレクトリにconfig.tomlにWEBサイトの情報を投入して準備完了。(エクスポート時に作られたyamlファイルでも可)

自分の場合はこんな感じ。

#website setting
title = "幻想サイクル"
baseURL = "http://blog.gensobunya.net/"
languageCode = "ja-jp"
canonifyURLs = false
relativeURLs = true
theme = "mainroad"
googleAnalytics = "UA-xxxxxxx-x"

#system
contentDir = "content"
layoutDir = "layouts"
publishDir = "public"
buildDrafts = false
hasCJKLanguage = true
defaultLayout = "post"

検証はhugo serveコマンドを打てばlocalhost:1313上にサイトが展開される。 リンクも実際のURLではなくlocalhostによろしく変換されてくれるので便利。

hugoコマンドで/static/に実際のHTMLが生成されるが、Netlifyの場合はこの作業をGitにアップロードした後勝手にやってくれるので、ローカルで実施する必要はない。gitignoreにぶち込んでおく。

テーマは/themes/ディレクトリに移動して公式からテーマファイルをCloneしてくるスタイル。Cloneしたらテーマのフォルダ名をconfig.tomlに記載すればビルドの際に記載したテーマが適用される。\ 普段と違うテーマを試したい時はビルド時に引数で渡してやれば引数のテーマでビルドされる。

Netlify用設定

リポジトリのルートディレクトリにnetlify.tomlを作成してHugoのバージョンを記載する(しないと古いバージョンをビルドに使うためエラーになる)

自分の場合v0.27.1を使っていたので下記の通り記載。

[context.production.environment]
  HUGO_VERSION = "0.27.1"

ここまで書いたら、Github, Gitlab, bitbucketのどれかにリポジトリを作ってプッシュしておく。

Netlifyの会員登録をして、作ったリポジトリと連携すれば自動的にサイトのビルドが実施されてデプロイまで行われる。先程ローカルにあったサイトが生成されていることを確認して終わりだ。

リダイレクト

公式ドキュメントによるとWEBサイトのルートに_redirectを作ってそこに記述する。

Hugoの場合、サイトビルド時に変換してほしくないファイルは/static/以下に置くことになっているので、画像ファイルなどと一緒にここに配置すればOK。

Bloggerの頃のパラメータと、パーマリンクを維持するために以下の設定を記入。

# START paramater 301 redirect
/*param1=:value1   /:splat  301!
# END paramater 301 redirect

# START page 301 redirect
/:year/:month/:date/:slug /:year/:month/:slug 301!
# END page 301 redirect

:yearなどのいかにもYYYYを検知してくれそうなプレースホルダーが用意されているが、スラッシュの間ならなんでも認識してしまう罠があった。問い合わせてみたところ仕様らしい。

コンテンツと設定の移行作業はこれで全て完了。 あとは独自ドメインの設定をしてDNSを切り替えればNetlifyのサーバーからサイトが配信される。

Cloudflareを辞める場合、一旦ネームサーバーをGoogleに返す必要があるのでNSレコードを変更して1日待つ必要がある。\ 24h後にあらためてGoogle DomainsでNetlifyのサーバーにCNAMEを向けて移行の全作業が終了。

Cloudflare上で予めNetlifyにアクセスを向けておけば移行時間を減らせるかもしれないが、Cloudflare経由でNetlifyから配信することは推奨されていないようなのでやめておいた。

BloggerやめてWordpressに移行しようとした② - CDN,HTTPS編

f:id:gensobunya:20191108215739p:plain
cloudshell

※この記事は前回の続きです

システム環境

1クリックデプロイでGCEにWordpessをインストールした時のインストール先は下記の通り。OSはDebian

Wordpressは/var/www/html

f:id:gensobunya:20191108215801p:plain
ディレクトリ1

Apache2.4は/etc/apache2

f:id:gensobunya:20191108215819p:plain
Apachedir

余談だが、WEBターミナルからログインする際に自動作成されたユーザーは当然のようにsudo権限が割り振られている、便利すぎる。

CDN有効化

最初はLet's Encryptの証明書を使おうと思っていたのだが、どうやらCloudflareを使う場合はSSLもCloudflareで用意してくれるそうなので一本化することに。

まずはCloudflareに登録してアカウント作成する。 ウィザード画面に従って進んでいくと、どうやらドメインのネームサーバーをCloudflareのものに切り替える必要があるらしい。\ せっかくお名前からGoogle Domainsに切り替えて信頼性が上がったと喜んでいたところなのだが…ここで代替サービスを探すのも面倒なので言われるがままに設定。

レジストラに登録されていた内容を自動的に反映してくれるあたりは非常に便利。\ DNSが切り替わった時点でCDN経由になっているため、CDN利用はこれで完了。非常にお手軽だ。

HTTPS有効化

CloudflareのHTTPS利用は「Flexible」「FULL」「FULL(Strict)」の三種類がある。\ Flexibleはクライアント-CDNサーバのみ、FULLはクライアント-CDN-オリジン全てHTTPSで通信するがオリジンの証明書の正当性は検査されない(オレオレ証明書でも良い)。FULL(strict)はオリジンも正式な証明書である必要がある。

とりあえずFlexibleで設定し、後からFULL(Strict)に切り替える方針で作業をする。\ 管理画面でHTTPS設定を切り替えるとまずはフロントのWEBサイトがHTTPSで通信可能になる。\ HTTPSサイトはリダイレクトさせたいので.htaccessの出番。以下の記述を追加。

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

巷ではWordPress管理画面がリダイレクトループを起こす不具合が定番になっているらしいが、起きなかったので無視。

次は、CDNからオリジンサーバへの通信をHTTPSにする。\ Cloudflareの管理画面から証明書のCSR秘密鍵を手に入れることができるので、それをコピーしてApacheの適当なフォルダ内に突っ込む。

/etc/apache2/sites-availableにあるSSL用のデフォルト設定ファイルを見ると下記のディレクトリがお作法っぽいので同じ場所に入れる。

SSLCertificateFile      /etc/ssl/certs/gensobunya-net.crt
SSLCertificateKeyFile   /etc/ssl/private/gensobunya-net-private.key

Apacheの設定に追加して再起動。

a2ensite default-ssl.conf
service apache restart

CloudflareのHTTPS設定をFULLに切り替えてアクセス。\ この時点でうまく動かない。サーバーにはつながっているがファイルにアクセスできていないようだ…ということでWordPress用の設定を443に入れていないことに気がつく。

WordPress用confに記載されていた下記の内容をコピペ。

 <Directory />
    Options FollowSymLinks
    AllowOverride None
  </Directory>
  <Directory /var/www/html/>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    allow from all
  </Directory>
  ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
  <Directory "/usr/lib/cgi-bin">
    AllowOverride None
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all
  </Directory>

動いた。Cloudflareの設定をFULL(Strict)に切り替えて再度アクセス。\ 証明書の警告が出る。疑問に思って見てみると、Cloudflareが提供してくれるSSL証明書はLet's encryptなどの証明書ではなく、Cloudflare発行のオレオレ証明書だった、そりゃ警告されるわ。

改めて証明書を取るのは面倒なのでHTTPS設定はFULLで完了とすることに。

とりあえずWP環境完成

以上をもって、ブログ記事を安定して投稿できる設定は終わり。\ ただ、1週間くらい経ったあたりで下記の問題が頭に引っかかってくる。

  • GoogleDomainsでドメイン管理できていないのが気持ち悪い
  • Bloggerと同等のSEOアドセンス・エディタ・画像圧縮などを出来るようにプラグインをインストールしたら管理画面が重い
  • 上記プラグインのセキュリティアップデートが面倒
  • プレビューが重い
  • 検証環境欲しい
  • 並行作業をしすぎるとメモリ不足でMySQLが落ちる(要サーバ再起動)

最後の問題が致命的で、ブログごときに監視自動化なんぞ入れたくないという決意のもとに別サービスの検討をしたところ、静的サイトジェネレーターのHugoを見つけた。

次回、Hugo+Netlify編。

BloggerやめてWordpressに移行しようとした①

f:id:gensobunya:20191108215555p:plain
HUGO

まずはBloggerをやめたかった

かなり長い間Bloggerで自転車ブログを書いてきたのですが、2017年頃に不満が目立つようになってきました。主な点は下記の2点。

特に前者はうっかりすると改行を全て<div>タグで出力するというおぞましい仕様。

HTTPS化は当のGoogleが検索順位を落としたりしているにも関わらずBloggerが対応してくれないため。世の中常時HTTPSの流れに乗りたいという意図。サービスの対応を待っているのも嫌になったので、サービスを乗り換えることにしました。

とりあえずWordpress

まずは手頃で慣れているサービスとしてWordPressを検討。要件は無料で独自ドメインSSLできること、性能がそこまで落ちないこと。

GCPにも興味があって並行して調べていたところ、下記の通りGCE(EC2みたいなもの)でほぼ無料でWordpressが運用できることを知りました。

GCEでWordPressがほぼ無料運用できるようになったので改めてまとめる\ https://yukari-n.info/posts/gce-wordpress/

自分でサーバー運用するので、当然SSLも可能。 興味のあったGCPサービスということもあってまずはこれで移行することに。

ブログ移行が主な目的なので、勉強はそこそこにしてWordpress1クリックデプロイを利用してf1-microインスタンスに設置。無料枠を使うためにUSリージョンにするのを忘れない。

インスタンスの性能がショボいので、最終的にはCDNを使ってほぼ全てのページをキャッシュして通信量・インスタンスの不具合を減らす方向に持っていきます。

GCPすごい

まずはGCPの機能に感動。SSHするのにブラウザから1クリックで証明書を自動作成してインスタンスに登録してSSHできる…

さすがにWEBアプリなのでちょっと遅いが、大抵の作業は事足りる上にAndroidのConsoleアプリからも同じことができる。 環境構築いらないじゃん…という気持でしたが色々WordPressのファイルをいじらなければならないところがあるので、ローカル用にGCP SDKをインストールしてGitリポジトリをこれまたGCP上の「Google cloud repository」に作成。

リポジトリの認証もGoogleアカウントで完結。なんて楽なんだすごいぞGCP

データの移行

データの移行には「Blogger importer extended」を使いました。 使い方は下記の記事を参考に。自動で画像・タグ・記事内容・パーマリンクを取り込んでくれます。※

blogger から WordPress への移行リダイレクトまで\ https://web-memo.fragmentnews.com/blogger-wordpress-279.html

ただし、パーマリンクで取り込んでくれるのは一番最後のファイル名のみなので予めWordPress側のパーマリンクを"/yyyy/mm/ファイル名.html"に変更しておく必要があります。 絶対リンクもWordPress設定のサイトURLに置き換えられるので、移行中にIPアドレスが設定されている場合、あとでまとめて置き換えることになります。Search Regexを使えば一発で全記事のソースを置換できます。

パーマリンク不備

あとから気がついたのですが、WordPressは同じファイル名になるポストのファイル名を勝手に書き換えます。 Bloggerは全角文字のみのタイトル記事は全て「blog-post.html」になるため、自分のようにパーマリンクに気を使っていないと同じファイル名が大量に生成され、blog-post-3.htmlやblog-pos4.htmlという不完全な記事が生まれます。

importer extendedのバグなのでしょうが、普通の記事も末尾の1文字が消えていたりすることがあるので、全部見直すハメになりました。つらい。

さらにさらに、Bloggerはたまに/yyyy/mm/dd/postname.htmlというディレクトリ構成の記事もあることが発覚。 こちらはどうしようもないので.htaccessに書いて対処することに。

# START page 301 redirect
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} !(^/wp.*/.*$)
RewriteRule ^([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*\.html)$ /$1/$2/$4 [R=301,L]
</IfModule>
# END page 301 redirect

念のため管理画面やリソースは除外しています。 ひとまずこれでコンテンツは移行完了。

この時点でDNSを新しいインスタンスのIPに向けて外部向けにも新サイトにアクセスを振り向ける。

CDN・SSL編へ