Nginx Helper 2.0.1でコメント時にパージが動かない。

Nginx Helperで個別記事のキャッシュをパージできない。 – return $lock;
これとは別の問題です。2.0.1の段階でコメントがついた時に個別記事のパージが動かなくなりました。前回とは異なり、個別記事のURLは正しいようです。

バージョンアップの度に動かなくなることが多いプラグインのため、以下から適当に1.9系のバージョンを持ってきたところ動作しました。やはり2.0.x系に問題がありそうです。修正されるまでバージョンアップはなしで運用かなと思います。
Releases · rtCamp/nginx-helper · GitHub

調べてみると同じ問題に当たっている方がいて、やはり1.9系に戻してるようです。
Nginx-Helper で上手いことキャッシュのパージが行われない問題 | ぶっちろぐ

稼働中のmetabaseを他のサーバに移行する。

本当はAlexa Skillの記事を書きたかったのですが、スクショとか取るのめんどくさくなってしまった。

あらまし

このブログと同じサーバでmetabase(0.31.2)を動かしていたのですが、-Xmxで指定してるヒープ領域を食いつぶす+Full GCが発生しまくる+他のサービスに影響が出そうなので引っ越すことにしました。(チューニング用のパラメータは以下を参考にしています。)

移動先はRaspberry Pi 3 Model Bしかなかったのでそこにしました。動くのか。

移行方法

metabase.db.mv.dbのSETTINGのurlを移行先のものにしたあと、metabase.db.mv.dbとmetabase.db.trace.dbをmetabase.jarと同じ場所において起動したところ、問題なく動作しました。ダッシュボードや管理者の設定も正しく生きています。
urlは移行先のものにしなくても起動できそうな気がします。多分。
Dockerの場合は試していませんが、おそらくdbファイルをホストからマウントすればいけるんじゃないでしょうか。

問題点(未解決)

起動がめちゃくちゃ遅いです。移行前はおよそ3分で起動していたのですが、移行後は7分程度かかるようになりました。ダッシュボードにあるグラフの描画も、移行前と比べて明らかにLoading状態が長いです。
チューニングの問題なのか、ラズパイのスペックが足りてないのか、問題の切り分けができていないので調査して改善できそうならどうにかしたいです。

コンタクトフォームにreCAPTCHA v3を導入した。

コンタクトフォームからのスパムメールが2日に10通くらいのペースで来ていて、困るほどの数でもないけどどうにかしたいレベルにはなってきたので、reCAPTCHA v3を導入してみました。

「私はロボットではありません」選ぶ必要なし 新「reCAPTCHA」Googleが公開、ユーザーは何もしなくてOK – ITmedia NEWS
reCAPTCHA v3 | reCAPTCHA | Google Developers

Akismetでもよかったのですが、今までコメントフォームに使ってみて誤検知が結構多い印象だったのと、公開されたばかりなので試してみたいこともあり、こっちにしてみました。
判定の流れとしては以下のとおりです。

  1. クライアントサイドでtokenを取得
  2. 取得したtokenを元にサーバサイドでverify用のAPIを呼び出す
  3. APIから返ってきた結果をもとに、ページにアクセスしてきたのが人間かロボットかを判定する

クライアントサイドの導入方法

  1. 管理ページでAPI実行用のキーを発行する。
  2. 管理ページにjsロード用のscriptタグのスニペットが表示されるので、reCAPTCHAしたいページのhead内に埋め込む。
  3. 管理ページにreCAPTCHAのexecute用のscriptタグのスニペットが表示されるので、reCAPTCHAしたいページのどこかしらに埋め込む
<script>
  grecaptcha.ready(function() {
    grecaptcha.execute('Site key', {action: 'action_name'}) // action_nameはサーバサイドの処理で使用する
      .then(function(token) {
        // Verify the token on the server.
    });
  });
</script>

サーバサイドの導入方法

  1. クライアントからtokenを受け取る。
  2. Secret keyとtokenを使用してスコアの問い合わせを行う。APIからのレスポンスの形式はドキュメントを参照
curl https://www.google.com/recaptcha/api/siteverify  -X POST -d "secret=secret&amp;response=token"
{
    "success": true,
    "score": 0.9,
    "action": "contact_form", // クライアントサイドで決めたaction_name
    ...
}

しきい値を決めて、それを下回るならエラーを返す等の処理をサーバサイドに書きます。

コンタクトフォームはContact Form 7を使用しているのですが、そのうちプラグイン側がv3に対応しそうなのと、自分で改造するのが面倒なので、reCAPTCHA用のエンドポイントを設置して、「エンドポイントからのレスポンスが200以外だったら、送信ボタンのDOMをremoveした上でsubmitイベントを無効化する」とかいう意味があるんだかないんだかわからない処理を入れておきました。
DOMの処理終わる前に送信されたら意味ないし、そもそもスパムの送信元がJS無効化してたら詰むんだけどまぁものは試しなので…。
reCAPTCHA用のjsも本当は全ページに読み込ませないといけないのですが、スパムの送信元はどうせコンタクトフォームに直接アクセスしてきてるので、コンタクトフォームのページにだけ読み込ませています。

設置してから4日くらい経ちますが、スパムが3通くらいしか届いていないのである程度効果はあるのかなと思っています。

追記 2018/12/15

Contact Form 7がv3に対応したので用済みになりました。

だから私はQiitaに投稿しない。

最近のQiitaの記事の質が下がってきている事への考察 – Qiita
これ読んでいろいろ思うことがあったのでポエム。

メールで問い合わせ受けたときに何回か「この記事Qiitaに投稿してほしかった(Qiitaに投稿してくれたらもっと早く見つけられた)」と言われたことがあるんですが、私は多分Qiitaには行かないと思います。

ポエムとかJAVAの人の記事は論外として、何かしら記事書いても「質の高い記事を投稿しろ」って言われてしまうなら、じゃあQiitaには投稿しないわ、ってなっちゃう。
今までQiitaに投稿された色々な記事に助けられてきたけど、私の書く記事がそうなれるかって言ったらなれないんですよね。多分。

Qiitaって技術ブログのInstagramみたいだとずっと感じてて、見る分にはほんとに楽しいしすごいなぁって思うんですが、私は投稿するのきついです。
意識高い人やいけてる人がめっちゃキラキラした写真を投稿するように、いけてるベンチャーの人やバリバリのフリーランスの人やレベルの高いエンジニアがレベルの高い記事を投稿するのがQiitaで、Qiitaには質の高いものばっかりなきゃいけない、みたいな感じになってる気がします。(でもそれってほんとにQiitaと、Qiitaを見に来る人にとっていいことなんですかね?)
「質の高い記事だけ探して読むわ」って人が集まるんじゃなくて「質の高い記事だけ投稿しろ」っていう人が集まってるところに記事投稿しても自分が悲しくなるだけだなぁって。

ポエムも書きたいし自分の好きな言語だけで好きなものだけ作りたいので、私はこのブログでいいです。

Gutenberg 4.1.1が有効の状態でSyntaxHighlighter Evolvedを使うとbr /が混ざる。

「新しいものは良いもの」という信条があるのでOSアップデートでもなんでも即試すんですが、ただしGutenberg、テメーはだめだ。
Gutenberg | WordPress.org
レビューにdisasterってコメントがあるのは笑ってしまった。

もう絶対原因こいつだろと決めてかかって無効化したらSyntaxHighlighter Evolvedで出力してる箇所にbr /は混ざらなくなりました。これ標準エディタ化されるとマジで詰みますね。どうしよう。
原因まで調べてる時間がなかったので、具体的にどのコードがSyntaxHighlighter Evolvedにちょっかいをかけているのかはわかっていないです。とりあえずメモとして記事を残しておきます。