2017-07-03

Angular4(2+)でカスタムValidationを作る

JavaScript Angular

Angular4(2+)で独自のValidationを作ってフォームに適用したい時のやり方を調べましたので、備忘録として残しておきます。

1. Validationディレクティブを作成する。

まず、ディレクティブとして、カスタムValidationを実装したクラスを作ります。以下は単純な例で、フォームへの入力値が「abc」だったらNG、それ以外はOKとしてます。

import { Directive } from '@angular/core';
import { AbstractControl, FormControl, ValidationErrors } from '@angular/forms';

@Directive({
    selector: '[validateCustom][ngModel],[validatorCustom][formControl]'
})

export class CustomValidator {
    check(control: AbstractControl): ValidationErrors|null {
        return control.value === 'abc' ? {‘custom': true} : null;
    }
}

入力をNGとしたい時に「{‘項目名’: true}」をreturnします。

参考：angular.coreのソース
https://github.com/angular/angular/blob/71f5b73296708014b740fb5dd0145c0599de7a19/packages/forms/src/validators.ts

2. 作ったカスタムValidationを使う。

使いたいコンポーネントの中で以下のように書くことで使用できます。

import ‘CustomValidator’ from ‘../directives/custom-validator';

：
onNgInit() {
  const cv = new CustomValidator();
  this.control = new FormControl('', cv.check);
}

2017-06-04

AWS SESでスパム認定されない独自のメールアドレスドメインを登録する

AWS メールドメイン

1. ドメインの取得
2. メールドメインの登録＆DKIMの設定
3. SPFの設定
4. 設定できていることの確認

独自ドメインでメールを送信する時、受信側にスパムメールやフィッシングメールと認定されないように注意しなければなりません。そのために、SPFやDKIMといった認証技術を使って、ドメインを認証する必要があります。

SPF/DKIMの普及が迷惑メール対策に効果、Googleが調査結果を公表 -INTERNET Watch Watch

今回はAWS SESを使って、独自ドメインにSPFとDKIMの認証をしてみます。

1. ドメインの取得

まずはドメインが必要です。
Route53などで取得しましょう。

2. メールドメインの登録＆DKIMの設定

AWSコンソールでSESを選択東京リージョンには残念ながら存在しないので、オレゴンリージョンあたりを選択します。
「Verify a New Domain」をクリックする。
ドメイン名を入れ、「Generate DKIM Settings」にチェックを入れ、「Vefiry This Domain」をクリックする。
Use Route53をクリックする。
画面が切り替わった後、そのまま「Create Record Set」をクリックする。
pending vefiricationの状態になるので、verifyになるまで数10分待つ。

3. SPFの設定

「Domains」の中から、追加したドメインをクリックする。
一番下の「MAIL FROM Domain」を開き、「Set MAIL FROM Domain」のボタンをクリックする。
ダイアログ中の「MAIL FROM Domain」に任意のサブドメインを入力して「Set MAIL FROM Domain」をクリックする。
「Publish Records Using Route53」をクリック
Warningの画面になるので、MXとSPFの両方にチェックを入れてボタンをクリック
verifyになるまで待つ。

4. 設定できていることの確認

Gmailで確認してみます。

「Domains」から登録したドメインを選び、「Send a Test Email」でテストメールを送信する。
受信したメールの詳細を表示する。
「dkim=pass」と「spf=pass」の所に、設定したドメインが記載されていればOK。

以上でドメインの認証が完了です。

2017-05-25

AWS LambdaをNode.jsで簡単に作れるサーバレスアーキテクチャのフレームワークClaudia.jsを実戦で使ってみた

AWS JavaScript サーバレスアーキテクチャ Lambda

f:id:matsnow:20170525010920p:plain:w200

はじめに
Claudia.jsとは
Claudia.jsの導入
実際に使ってみる
まとめ

はじめに

今のプロジェクトでAWS Lambdaによるサーバレスアーキテクチャのシステムを開発していますが、フレームワークとしてClaudia.jsというものを選択してみました。

Claudia.jsとは

AWS Lambdaのようなサーバレスアーキテクチャ用のフレームワークとしてはServerless Frameworkが有名ですが、
それ以外にClaudia.jsというフレームワークがあります。 claudiajs.com

以下のような点がServerlessとの大きな違いです。

Claudia.jsはAWS Lambda、かつNode.js (JavaScript、TypeScript)に特化している。特化している分、非常に少ない手間でデプロイまでできる。
api-builderやbot-builderなどの追加パッケージを使うことで、簡単にAPIやBotを作れる。

なお、サーバレスアーキテクチャということもあり、フレームワークといっても、
フルスタックやMVCなどではなく、むしろビルド・デプロイツールといった色合いが強いです。

Claudia.jsの導入

Claudiaの導入は以下のブログが分かりやすいです。 qiita.com

dev.classmethod.jp

あとは公式のサンプル集を見れば、たいていのものは作れると思います。(手抜き) github.com

実際に使ってみる

Claudia.jsはLambdaやAPIをNode.jsを書いていく上では非常に便利ですが、実戦投入するに当たって、いくつか考慮する点があります。

1. package.jsonは関数ごとに用意する

公式のサンプルなどでは、ディレクトリは1階層だけで、そこにpackage.jsonが置いていますが、実開発ではディレクトリは複数階層になることが多いと思います。
例えば、以下のようなディレクトリ構成にする場合、api/hello、function/foo、function/hogeの各ディレクトリにpackage.jsonが必要です。

sample  
├── api  
│   └── hello  
│       └── index.ts  
└── function  
    ├── foo  
    │   └── index.ts   
    └── hoge  
        └── index.ts

その時のpackage.jsonの内容は、例えば「function/foo/package.json」であれば、以下のようになります。
nameがLambda関数の名前、descriptionは説明文、mainはエントリポイントのJSファイルです。

{
  "name": "foo",
  "description": "Lambda関数のサンプル",
  "main": "index.js"
}

なお、node_modulesのディレクトリは下位階層には不要です。通常のプロジェクトと同じくトップにあればOKです。

2. ロールはあらかじめ作成しておく

Claudia.jsのコマンドでは、とりあえず以下を指定すればLambda関数を作成できます。 sh $ claudia create --region ap-northeast-1 --handler index.handler ただし、この場合、Claudia.jsによってIAMロールが毎回新しく作られてしまいます。そのため、あらかじめLambda用のIAMロールを作成し、「–role sample-role」のように指定するようにした方が良いです。

3. claudia create –handlerの指定は相対パス

単純なことですが、–handlerで指定するハンドラ関数はディレクトリ構成が影響します。例えば、src/ の下にindex.jsを入れており、「export handler」としている場合、「–handler src/index.handler」と指定する必要があります。

4. api-builderの中でpromiseを扱うときはpromiseをreturnする

ハマりどころの1つとして、API作成時にPromiseを使う場合、それをreturnしないと、 CloudWatchLogsなどにも何も出力されないまま、APIが終了します。

api.post('/user', function (request) {
    return dynamoDb.put({
        TableName: request.env.tableName,
        Item: {  userid: request.body.userId }
    }).promise();
});

公式ドキュメントの「4. Return a Promise out of the API handler」に記載されていますが、かなりハマりやすい点なので注意が必要です。 https://claudiajs.com/tutorials/external-services.html

まとめ

最初に慣れるまでは若干手間取るかもしれませんが、一度使い方を覚えれば非常に楽に開発が進められる、良いフレームワークだと思います。
とりあえず、今のプロジェクトでは、このままClaudia.jsを使い続けるつもりです。

Engineer's Way

主にソフトウェア関連について色々書くブログです。