memo

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

あらまし

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

• JVMのチューニング - ITエンジニアとして生きる
• ガベージコレクタの仕組みを理解する (2/2)：チューニングのためのJava VM講座（後編） - ＠IT

移動先は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状態が長いです。
チューニングの問題なのか、ラズパイのスペックが足りてないのか、問題の切り分けができていないので調査して改善できそうならどうにかしたいです。

コンタクトフォームからのスパムメールが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&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には行かないと思います。

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

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

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

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

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