VSCode で手動で vue-i18n-ally の設定を書くメモ

Vue.js で i18n の設定をしていると実際の日本語が何かぱっと見でわからないです。

VSCode を使っている場合、プラグインの vue-i18n-ally を入れることで日本語が見れる様になって便利でした。

github.com

手動で設定を書かないとうまく動かせなかったので設定を残しておきます。

.vscode/settings.json

{
    "vue-i18n-ally.readonly": true,
    "vue-i18n-ally.experimental.sfc": true,
    "vue-i18n-ally.localesPaths": [
        "src/locales"
    ],
    "vue-i18n-ally.keystyle": "nested",
    "vue-i18n-ally.sourceLanguage": "ja"
}

Nuxt 2.8 から 2.9 へのマイグレーションメモ

Nuxt TypeScript というページができていました。 Nuxt 2.8 から 2.9 のマイグレーション手順が書いてあるのですがメモを残します。

typescript.nuxtjs.org

元環境

  • Nuxt 2.8
  • TypeScript (nuxt.config.ts)

を使用している環境

きちんと読めば問題無いのですが、移行手順書の 5. TypeScript Runtime (optional) を無視すると nuxt.config.js が見つからないため、デフォルトの設定で動きます。

マイグレーション手順

  • パッケージ更新
npm uninstall @nuxt/typescript
npm i nuxt
npm i -D @nuxt/typescript-build
npm i @nuxt/typescript-runtime
  • npm script修正

nuxtnuxt-ts に変更

  • 型定義の読み込み修正
import { Context } from '@nuxt/vue-app'; // nuxt 2.8
import { Context } from '@nuxt/types';  // nuxt 2.9
import { ErrorParams } from '@nuxt/vue-app';  // nuxt 2.8
import { NuxtError } from '@nuxt/types/app';  / nuxt 2.9
import NuxtConfiguration from '@nuxt/config';  // nuxt 2.8
import { Configuration as NuxtConfiguration } from '@nuxt/types';  // nuxt 2.9
  • tsconfig.js の修正
"types": ["@types/node", "@types/jest", "@nuxt/vue-app"]  // nuxt 2.8
"types": ["@types/node", "@types/jest", "@nuxt/types"]  // nuxt 2.9
  • extract-css-chunks-webpack-plugin の設定修正

css の order ででるWARNINGを消している場合オプションが変更されています。

https://github.com/faceyspacey/extract-css-chunks-webpack-plugin/blob/v4.6.0/src/index.js#L534

options.orderWarning = false;  // nuxt 2.8
options.ignoreOrder = true;  // nuxt 2.9

EmbulkでMySQLからBigQueryへデータを転送するときの注意点

Embulk を使って MySQL から BigQuery へデータを転送するときにはまった部分を忘れないように記録として残しておく

github.com

DBの設定などで一度に大量のデータを取得することが難しい場合などに fetch_rows で1度に処理するデータ量を調整することが必要になることがありそうです。

in:
  type: mysql
  fetch_rows: 1000

改行が含まれるデータを BigQuery へ転送する場合は allow_quoted_newlines: 1 が必要になります。

out:
  type: bigquery
  allow_quoted_newlines: 1

参考

embulkでBigqueryにテキストデータ流し込めなかった話 - 無気力生活 (ノ ´ω`)ノ ~゜

TB越えのMySQL 巨大テーブルを 1日で BigQueryへLOADする - Mercari Engineering Blog

HTMLメールの注意点(Gmail)

システムで Gmail へ HTML メールを送る際の注意点になります。
Yahooなど他のサービスでの動作については確認していません。

例えばですが、PCではフォントサイズ 16px SP ではフォントサイズ 20px みたいな要件のとき

.font {
  font-size: 16px;
}

@media only screen and (max-width:480px) {
  .font {
    font-size: 20px !important;
  }
}

の様に書けば要件を満たせます。

ここで注意しなければいけない部分が2点あります。

1 media query の max-width: の後ろにスペースを入れてはいけない

@media only screen and (max-width: 480px) {

とするだけで、SP 時にフォントサイズが変わらないということが起きます。

2 !important を書かないと上書きされない

font-size: 20px !important;

css は後から書いたスタイルが優先されるはずなのですが、Gmail へ送る HTML メールでは !important を書かなければ上書きされないようでした。

参考

html - Why is Gmail ignoring my media queries? (On iOS) - Stack Overflow

AWS CloudFormation で ECR のライフサイクルを設定する

AWS ECR を使ってコンテナを更新していくと知らないうちにイメージが貯まっていきます。
Lifecycle Policy を設定すれば、古いイメージを自動で削除できます。

CloudFormation で設定する方法を見ると、 LifecyclePolicyTextString で設定すれば、 ECR の Lifecycle Policy を設定できます。

docs.aws.amazon.com

ですが、 Amazon ECR ライフサイクルポリシー を見ると分かるのですが、 JSON で設定するようになっています。

Lifecycle Policy の条件とその JSON は以下の様になります。

  • ルールの優先順位 : 1
  • イメージのステータス : タグ付けなし
  • 一致条件 : 次の数値を超えるイメージ数 10
{
  "rules": [
    {
      "action": {
        "type": "expire"
      },
      "selection": {
        "countType": "imageCountMoreThan",
        "countNumber": 10,
        "tagStatus": "untagged"
      },
      "description": "delete cycle",
      "rulePriority": 1
    }
  ]
}

YAML では > を使うと改行をスペースに置き換えられるのでそのまま JSON を書くことで String として扱うことができます。

        LifecyclePolicyText: >
          {
            "rules": [
              {
                "action": {
                  "type": "expire"
                },
                "selection": {
                  "countType": "imageCountMoreThan",
                  "countNumber": 10,
                  "tagStatus": "untagged"
                },
                "description": "delete cycle",
                "rulePriority": 1
              }
            ]
          }

試してみた CloudFormation のリソースを残しておきます。

Parameters:
  RepositoryName:
    Type: String
  ImageName:
    Type: String

Resources:
  Repository:
    Type: AWS::ECR::Repository
    Properties:
      RepositoryName: !Ref RepositoryName
      RepositoryPolicyText:
        Version: "2012-10-17"
        Statement:
          - Sid: AllowPushPull
            Effect: Allow
            Principal:
              AWS:
                - !Sub arn:aws:iam::${AWS::AccountId}:user/${ImageName}
            Action:
              - "ecr:*"
      LifecyclePolicy:
        LifecyclePolicyText: >
          {
            "rules": [
              {
                "action": {
                  "type": "expire"
                },
                "selection": {
                  "countType": "imageCountMoreThan",
                  "countNumber": 10,
                  "tagStatus": "untagged"
                },
                "description": "delete cycle",
                "rulePriority": 1
              }
            ]
          }
        RegistryId: !Ref AWS::AccountId

参考

AWS Lambda のトリガーで CloudWatch の定数(JSONテキスト)を使った場合の起動方法

AWS Lambda が .Net Core をサポートしたと言うけど実際に書くときに引数ってどうするんだろうって思ったので調べてみた。

Lambda のトリガーには CloudWatch を指定できて、 CloudWatch のイベントからルールを設定することでバッチ処理のようなことをさせることができます。

CloudWatch のイベントルール

f:id:naught00:20180831151541p:plain

ここで気になったのが、入力を 定数 (JSON テキスト) にした場合、ソースコードで引数部分をどう書けばいいのかということでした。

f:id:naught00:20180831151614p:plain

イベントごとの書き方の違い

一致したイベント

一致したイベントの場合は CloudWatchLogsEvent で大丈夫です。

public string FunctionHandler(CloudWatchLogsEvent logEvent) { }

定数 (JSON テキスト)

定数 (JSON テキスト) の場合、 JSON テキストは

{ "mode": "test" }

としたとき、 一致したイベント と同じ書き方ではエラーになります。

Object reference not set to an instance of an object.: NullReferenceException

その場合は自分で型を定義してあげることで無事Lambdaを起動することができます。

public class InputParameter
{
    public string mode { get; set; }
}

public string FunctionHandler(InputParameter params) {
    Console.WriteLine("mode : {0}", params.mode);
}

参考

github.com

CircleCI 2.0 で AWS CodeDeploy を使う

まず、 CircleCI 1.0 で CodeDeploy を使っているという前提で話を進めます。
そのため、デプロイ先のインスタンスへの CodeDeploy エージェントインストールなどについては触れません。

先に示すこれは失敗する例です。
成功する例はこの記事の一番最後に書いてあります。

.circleci/config.yml

version: 2
jobs:
  deploy:
    working_directory: ~/repo
    docker:
      - image: naughtldy/circleci-node-awscli:8
    steps:
      - checkout
      - run:
          name: zip
          command: "zip -r master ../repo"
      - run:
          name: zip upload
          command: aws s3 cp master.zip s3://{バケット名}/{ファイル名} --region ap-northeast-1
      - run:
          name: Deploy Staging
          command: |
            aws deploy create-deployment \
              --application-name bot-ryuzu \
              --deployment-group-name ryuzu-prod \
              --s3-location bucket="{バケット名}",bundleType="zip",eTag=`aws s3api head-object --bucket {バケット名} --key {ファイル名} | jq .ETag`,key="{ファイル名}" \
              --region ap-northeast-1

workflows:
  version: 2
  deploy:
    jobs:
      - deploy:
          filters:
            branches:
              only: master

実行結果は、 appspec.yml が無いという理由でデプロイに失敗します。
CircleCI 1.0 で動いていたので、ファイルが不足するなどの理由はないはずなので CircleCI 1.0 のときと比較してみます。

デプロイしたソースコードは、 CodeDeploy によるデプロイ先インスタンス

/opt/codedeploy-agent/deployment-root/{英数字の羅列}/

ここにデプロイIDごとにディレクトリが分かれて入っています。

以前の成功していた時のものを見てみると、デプロイIDのディレクトリの中身は

bundle.tar
deployment-archive
logs

となっています。

CodeDeploy でデプロイするソースコードなどは deployment-archive の中に入ってます。

失敗する場合は

bundle.tar
deployment-archive
repo

となります。

repo はCircleCIでのソースコード展開先のディレクトリ名です。

そうすると、 CodeDeploy のイベント BeforeInstall で、ディレクトdeployment-archive の中に appspec.yml が無いというエラーで CodeDeploy の実行に失敗します。
確認してみると deployment-archive の中身が空で、ソースコードなどは repo に入っています。

こちらが成功する例です。

.circleci/config.yml

version: 2
jobs:
  deploy:
    working_directory: ~/deployment-archive
    docker:
      - image: naughtldy/circleci-node-awscli:8
    steps:
      - checkout
      - run:
          name: zip
          command: "zip -r master ../deployment-archive"
      - run:
          name: zip upload
          command: aws s3 cp master.zip s3://{バケット名}/{ファイル名} --region ap-northeast-1
      - run:
          name: Deploy Staging
          command: |
            aws deploy create-deployment \
              --application-name bot-ryuzu \
              --deployment-group-name ryuzu-prod \
              --s3-location bucket="{バケット名}",bundleType="zip",eTag=`aws s3api head-object --bucket {バケット名} --key {ファイル名} | jq .ETag`,key="{ファイル名}" \
              --region ap-northeast-1

workflows:
  version: 2
  deploy:
    jobs:
      - deploy:
          filters:
            branches:
              only: master

working_directory: ~/deployment-archive で、 CircleCI のソースコード展開先ディレクトリ名を deployment-archive にしたことで、 デプロイ先インスタンスdeployment-archiveソースコードが入り今まで通りにデプロイできるようになりました。