【はてなブログ独自ドメイン】Google Adsense審査合格までの道のり

2ヵ月ほど前に当ブログを独自ドメインに変更しました。

それまで、はてなブログのドメインでadsenseの審査は合格していたので、新しいドメインで再度申請することに。

しかし、合格しない…

審査側から送られてくるメッセージは以下。

サイトの停止または利用不可

お客様のサイトが停止しているか、利用できないことが判明いたしました。...

もちろん、URLを打ったらブログは出てきます。

ブログの詳細設定にて、headタグ要素にadsense審査用のコードも張り付けてある。はて…

結論

私のケースの場合は、ブログのテーマが問題でした。

現在使っているテーマは、カスタムテーマの「DUDE」。

DUDE - テーマ ストア

独自ドメインにする前は同じくカスタムテーマの「Brooklyn」を使っており、 そちらに戻して申請をしたところ、合格しました。

Brooklyn - テーマ ストア

その他に試したこと、経緯

• ブログアドレスをapexドメインに設定していたが、www付のドメインでもアクセスできるようURL正規化した　→特に効果なし（不合格）
• adsense申請時のドメインについて、サブドメインにwww付を追加した　→特に効果なし（不合格）
• ブログアドレスをapexドメインからwww付きのドメインに変更した　→特に効果なし（不合格）
• ブログのテーマをDUDEからBrooklynに変更した　→合格

参考になれば幸いです。

独自ドメインでのapex(ネイキッド)ドメインへのアクセスを正規化する【AWS利用】

当方の環境

・はてなブログ

・ドメインはRoute53で取得

ドメイン「tachi-machi.net」を取得し、独自ドメインに設定した。

http://tachi-machi.net

https://tachi-machi.net

これで、上記のURLでアクセスできることは確認できた。

www.tachi-machi.net

続いて、次のURLも同じページに遷移するようにURLを正規化したい。

http://www.tachi-machi.net

https://www.tachi-machi.net

S3の静的Webサイトホスティングでリダイレクト(httpのみの場合)

1. 新規バケットの作成

S3に新しくバケットを作成する。名前は「www.tachi-machi.net」。

バケットは公開設定としておく。

2. 静的Webサイトホスティングを設定

バケットのプロパティの「Static website hosting」を設定。

「リクエストをリダイレクトする」にチェックし、ターゲットバケットまたはドメインに飛ばしたい先「tachi-machi.net」を、プロトコルに「https」を指定

3. Route53のAレコード設定をS3に向ける

Route53のホストゾーンにレコードセットを作成。

www.tachi-machi.netのAレコードを作成し、エイリアスに「はい」を選択、先ほど作成したS3のバケットを指定する。

以上で、「http://www.tachi-machi.net」にアクセスした際に正常にリダイレクトされる。

しかしこれはhttpのみの対応…

この静的Webサイトホスティングはhttpにしか対応していないため、まだ「https://www.tachi-machi.net」にアクセスした際はページが見つからない状態である。

そこで、CloudFrontを経由してhttps対応する方法を取る。

CloudFrontを経由したリダイレクト

1. S3のバケットにindex.htmlを作成

0バイトの空ファイルで良いので、先ほどのS3バケットにindex.htmlを作成する。

アクセス権は公開としておく。

2. Webサイトホスティングの設定を変更

先ほどは「リクエストをリダイレクトする」を選んでいたが、「このバケットを使用してウェブサイトをホスティングする」に変更。

インデックスドキュメントに「index.html」を指定

リダイレクトルールには以下を記述する。

<RoutingRules>
  <RoutingRule>
    <Redirect>
      <HostName>tachi-machi.net</HostName>
      <ReplaceKeyWith/>
    </Redirect>
  </RoutingRule>
</RoutingRules>

また、この画面に書いてあるエンドポイントをコピーしておくこと。

3. SSL証明書の取得

AWS Certificate Managerより、SSL証明書を発行する。

申請時のドメインは「*.tachi-machi.net」とした。

検証についてはDNSのCNAMEを確認する方法で、Route53の場合はボタンを押すだけで勝手にCNAMEのレコードが差し込まれる。

数分も立たずに発行済みとなった。

4. CloudFrontのディストリビューション作成

CloudFrontから新規にWebのディストリビューションを作成する。

Originドメイン名には一覧から選択できるS3バケットではなく、先ほどのS3エンドポイントのURLを入力。（S3バケット指定してしまうと、httpsで来た場合にS3にもhttpsアクセスしようとし、アクセス拒否となる。エンドポイントのURLを入力すると、OriginへのHTTP onlyが設定される）

Viewer Protocol Policyは「Redirect HTTP to HTTPS」を選択

Alternateドメイン名(CNAMEs)に「www.tachi-machi.net」を指定

SSL証明書に先ほど作成したACMの証明書を指定。

Default Root Objectに「index.html」を指定。（これがないとCloudFrontがファイル見つかりませんのエラーを返す）

5. Route53のAレコード設定をCloudFrontに向ける

www.tachi-machi.netのAレコードを編集または作成し、エイリアスに「はい」を選択、先ほど作成したCloudFrontを指定する。

終わり！

以上で、「http://www.tachi-machi.net」および「https://www.tachi-machi.net/」にアクセスした際に正常にリダイレクトされた。

まとめ：仕組みの整理

https apexドメインの場合：Route53 DNSのAレコード設定によりはてなブログのアドレスへ。

http apexドメインの場合：上記に同じ。http→httpsははてなブログがよろしくやってくれている。通常はApache等で内部的に301リダイレクトをかける。

https www付きの場合：Route53 DNSのAレコードでCloudFrontへ → (httpに変換され)S3エンドポイントへ → apexドメインへリダイレクト

http www付きの場合：上記に同じ。

追記：www付きをブログのメインドメインに変更した。

Apexドメイン側にファイルを配置したい関係で、www付きを本ブログのURLとした。

・はてなブログのドメイン名を変更し、www付きを正規とする

・DNS側のwww付きをCNAMEでhatenablog.comへ渡すよう変更（はてなブログ公式手順の通り）

・S3側はapexドメインのバケットを新しく作成

・CloudFrontからは、apexドメインのS3に遷移するようにし、CNAMEもapexドメインに変更する

PostgreSQLで特定のテーブルが応答しない

PostgreSQL9.4にて。

特定のテーブルに対するクエリが返ってこない。countすら返ってこない。

pgAdminでテーブルを参照しようとすると、テーブル名をクリックした時点で固まるという始末。

今回のケースではテーブルロックが関与していた。

1. テーブルのロック状況を調べる

select * from pg_stat_activity;

上記のSQLで、実行中のクエリ状況がわかる。右端のquery列でどんなクエリか判別できる。

「waiting」列が「t」になっているものは、待たされているクエリ。まずそれが存在していないかチェック。

加えて、その応答しないテーブルにアクセスしているクエリがないかチェック。query_startに開始時間も書いてあるので照らし合わせながら、長時間残っているような怪しいクエリを探す。見つけたらpidを控え、次のSQLでロック解除する。

2. ロック解除（クエリをキャンセル）する

select pg_cancel_backend(pid);

以上で、応答しなかったテーブルに無事アクセスできるようになった。

intra-mart AccelPlatformでwar入れ替えせずにモジュール追加する方法

iAPにおいて、何かのモジュールを追加したい、となったとき。

アプリケーションやエクステンションの追加など、大きな変更の場合は正式作業としてwar入れ替えを行えばいいが、軽微な変更の場合にいちいちwarを入れ替えるのは面倒くさい。

例えば認可のExcelインポートエクスポートを追加したいとか、テーマカスタマイズモジュールを追加したいとか、IM-Noticeを追加したいとか…。

warを入れ替えてしまうとログが消えるのと、直接書き換えていた設定ファイルや追加したソースなどが全て元に戻るため、影響調査が大変なのだ。（それも含めてちゃんとjugglingで管理しとくのが筋なのだが…現場はそうではない）

そこで、warを入れ替えずにモジュール追加するにはどうすれば良いか。

結論から言うと、「差分を抽出して適用する」というのが賢いやり方だ。

手順1. 変更前のwarを取得し、解凍する

現行のwarファイルを取得する。

warファイルの拡張子をzipに変更し、解凍しておく。

手順2. 変更後のwarファイルを作成、解凍する

jugglingツールにて、モジュールを追加したwarファイルを作成する。

作成したwarは同じく拡張子をzipに変更し、解凍しておく。

手順3. 比較する

変更前の解凍フォルダと変更後の解凍フォルダをWinMerge等の比較ツールで比較する。

結果、変更された差分が出力される。→これらが適用すれば良い差分となる。

※Webサーバがある場合、静的ファイル(WEB-INFの外)も忘れずにWebサーバに適用すること。

※WEB-INF直下のjuggling.ほにゃららも差分として出るが、必要なので忘れずに適用すること。

手順4. 比較結果を抽出する

この差分をどのように抽出すれば良いか。やり方は様々あると思うが、私が行っているのはWinMergeを使い、以下の通り。

1. WinMergeの結果を比較結果でソート

2. 変更点のある行だけShift+クリック等で選択

3. 右クリック＞コピー＞左を...（または右を...）

4. 任意のフォルダに出力

手順5. 環境に反映する

Resinを停止し、抽出したファイルを反映して、Resinを起動する。

必要に応じてテナント環境セットアップなどを行うこと。

以上。

Windowsでサブディレクトリ配下のファイル名のみ（パスなし）を取得する

Windowsのdirコマンドで、サブディレクトリを含むファイル一覧を取得したい。

ただし、ファイルのフルパスはいらない。こちとらファイル名のみの一覧が欲しいのだ。

しかし、dirコマンドをざっと調べてみたものの、サブディレクトリを含めてファイル名のみを一括で出力するオプションはないようだ。

そこで、以下の手順で生成することとする。

手順1. dirコマンドでファイル一覧出力

dir /s /b /a-d フォルダ名 > filelist.txt

フルパス付きだが一旦これで出力

プチ解説

• /s … サブディレクトリを含む
• /b … ファイル名のみ表示
• /a-d … aは属性指定。dはディレクトリ。手前にハイフンをつけることで除外。つまりディレクトリを除外している。

手順2. 正規表現でパス部分を削除

正規表現が使える任意のテキストエディタでファイルを開き、以下の条件で空文字に置換する。

エディタでの検索文字列

.*\\

プチ解説

• . … 任意の1文字
• * … 直前の文字がないか、1個以上連続する
• \\ … \で終わる。2回続けているのはエスケープのため

なお、Excelでも可能。以下の検索条件で空文字に置換すればよい。

Excelでの検索文字列

*\

以上

Outlookでクイック操作の電子メールを編集した際にCCが消える

定期的な報告など、よく使うテンプレメールについてはOutlookの「クイック操作」機能を利用すると便利です。

このクイック操作で呼び出すメールの本文を編集した際、CCが消えてしまう…ということがあります。

その対処法については、以下の通り。

1. 編集したいクイック操作のメールを右クリックし編集

2. 「オプションの表示」をクリック

3. 「[CC]の追加」をクリック

4. 設定していたCCが表示される

この状態で本文を変更して保存すれば、CCは維持されます。

以上です。

intra-mart AccelPlatformで時間のかかったジョブを調べるSQL

以下はSQLの例。

2020/4/1以降で、30分以上かかったジョブを一覧で抽出する。

※PostgreSQL用。RDBMSに応じて書き換えること

SELECT
    t1.tenant_id AS テナントID,
    t1.id AS モニターID,
    t1.jobnet_id AS ジョブネットID,
    t2.name AS ジョブネット名,
    t3.job_id AS ジョブID,
    t4.name AS ジョブ名,
    t3.status AS ステータス,
    to_timestamp(t3.start_date_time / 1000) AS 開始日時,
    to_timestamp(t3.end_date_time / 1000) AS 終了日時,
    round(((t3.end_date_time - t3.start_date_time) / 1000)) AS 所要時間（分）,
    round(((t3.end_date_time - t3.start_date_time) / 1000 / 60)) AS 所要時間（秒）
FROM
    imjob_monitor t1
JOIN
    imjob_jobnet_localize t2
    ON
    t1.jobnet_id = t2.jobnet_id
    AND
    t2.locale = 'ja'
JOIN
    imjob_monitor_task t3
    ON
    t1.id = t3.monitor_id
JOIN
    imjob_job_localize t4
    ON
    t3.job_id = t4.job_id
    AND
    t4.locale = 'ja'
WHERE
    round(((t3.end_date_time - t3.start_date_time) / 1000 / 60)) >= 30
AND
    to_timestamp(t3.start_date_time / 1000) >= '2020/04/01'