頭の中は異空間

上記事に分かりやすくまとまっています。それぞれどのような特徴があるかを知った上で使い分ければミスしません。

$(this)の中身

関数が入れ子になっていると起こりうる現象。thisの参照先が異なるためにバグの温床になりやすいです。他サイトでも説明されきってる感じですが一応。

// 実際には下記のように書かずに$(".hoge").on('change', ~~~と書きますが分かりやすくするために。
$(".hoge").each(function() {
  // ここの$(this)と
  $(this).find('input').on('change', function() {
    // ここの$(this)は違う
    console.log($(this));
  });
};

id読み込み時の挙動

id属性はuniqueである必要があるので、idが重複していた場合通常は正しくJSが動作しないはず。

昔のIEではJSの挙動がおかしくなっていましたが、ChromeやFireFoxではなんと中で独自に解釈したのか、ID重複後もエラーを吐かずに動作していました。なぜなんだろう。。

最新Ver(現時点で55.0.2883.87 m (64-bit))のChromeで試しにやってみると、・・・

 <body>
<div id="hoge">最初のid</div>
<div id="hoge">2つめのid</div>
<div id="hoge">3つめのid</div>
</body>

に対して

この通り、動くみたいです。最初のidに合致する要素を取ってきています。

しかし異常な挙動であることに代わりはないので、うっかりダブらせてしまったら速攻で削除してやるべし。

true/falseの空判定

!!"false"

これはtrueになります。文字列のfalseもtrueもtrueとして扱われるので、わかりづらいです。文字列でfalseになるのは""のみ。関数や変数の中身で判定する時、文字列が返ってくるとわかっているなら必ず === ""の空判定をするべし。

もう一つ、勘違いしやすい判定として

if []

もしくは

if {}

これはfalseになるかと思えばtrue。if文にundefinedやfalse, nullが入れば当然falseとして扱われますが、[]/{}自体は中身が空にもかかわらず1つの空でないオブジェクトとして扱われるのが原因。配列を判定するとわかっていれば

変数.length > 0

連想配列やjsonであれば

Object.keys(変数).length > 0

とすれば中身が空かどうか判定出来ます。

最後に、曖昧比較(==)と厳密比較(===)。前者は変数の型を半ば無視して判定するので、本来falseなはずがtrueにしちゃう。例えば

100 == "100"

これはCやJavaなどでは明確にfalseになるのですが、JSでは==を使う限りtrue扱いです。StringとNumberで比較して同一とか何の冗談だと。でも企業のコードでこういうの多いです。PHPとかJSみたいな動的型付け言語では変数の型がわかりづらいことで、バグの温床になります。関数に渡す変数の型が違ったせいでエラーを吐いていた場合、この変数の型違いによるものが起こりうるので、余程の理由(ってなんだ？)がない限りは厳密比較を使うべし。

null.~~

例えば要素取得してattributeへアクセスする場合。$("~~")が存在しない場合nullになり、null.attribute名でCannot read propertyとなります。

要素名をtypoによって引き起こすことはテストによって排除出来るので、動的な要素変更があった場合に起こりうるバグです。class名やid属性変更後は特に注意です。

find, closest等による要素取得

viewのツリー構造が予めわかっていればfindだけでなくclosest, next等で要素を狙って取得できますが、ツリー構造に変更があった場合はその取得の仕方も変えないといけません。id属性やclass属性で取得していればclass名、id名を変えない限り影響はないのでまだ安心です(変える時は注意)。

自由度が高いからと言って好き放題やらない

1つのロジックを作るのにも多くの手段がありますが、実際書き方1つ違うだけでシンプルできれいなコードにもクソコードにもなります。

クソコードの例としては

unkode-mania.net

を見れば大体わかりそうなものです。本当にひどい例です（笑）

そうならないためには、言語ごとに役割を明確にもたせておくのが良いかと。

他の酷い例

関数名とreturn内容が合ってなかったり

  // タイトルを返すと書いてあるのにコメントを返している
  function title() {
    ～～(処理)
    return comment;
  };

(残念ながら某所で↑の例を実際に見ました...)

HTMLにif, forなどの複雑な構文を埋め込む(erbとして書きます)

<div class="~~~">
<% if hoge %>
  <% fuga.each do |f| %>
    <span class="~~">xxx</span>
    <% if piyo >
      book = Book.find ~~
      ...
    <% end %>
  <% end %>
<% end %>
</div>

Viewの役割に複雑な構文を突っ込んでいるだけでなく、クエリも走らせています。これでは見づらくて仕方ない。

こういう酷い例を見たら多少リスクを犯してでもついでに直しておいて、次見た時読みやすくしておくのがまともなエンジニアってもんでしょう。リファクタリングで多少のミスが出てもそれが致命的なものでないなら、それは大した傷ではないと思います。寧ろクソコードが新しく生み出され続けることのほうが余程重症なので。

ここではJS、特にjQueryを使った際のバグについて書きましたが、他の言語でも色々ひどい例は見てきたので、また何か酷いのを見つけたら書くと思います（笑）

2017-01-01

SESで受信したメールをLambdaを通して転送&S3に保存 - Lambda(Python)/S3/SES

AWS Python

SES
S3
Lambda(Python)
- function
- code

SESを設定することでメール送受信が可能になります。ここでは受信したメールをS3に保存し、更に中身を転送してみます。

SES

ここではオレゴンのリージョンを選択します。認証済みドメインであればどんなメールアドレスでも使えます。ドメインの認証方法は

などを参照。

認証済みドメインを用いて、SESでメール受信する際にS3へ保存するトリガーを設定します。詳細なやり方は

に倣ってできます。

S3

メールを保存するためのバケットを用意します。LambdaのIAMで参照出来るようにプロパティでバケットポリシーを設定(Principalを"*"とか設定すればOK)。

この時点で、SESで認証済みのドメインにメールを何かしら送信すればS3に内容が保存されます。実際に試してみると、

このようになるはずです。

Lambda(Python)

S3にメールが保存されたというトリガーを設定してその都度Lambdaの処理を走らせるようにfunctionを作成します。

function

上画像の通りに設定。

ここではS3から保存されたメールのオブジェクトを取得→中身を解析→SESで送信の流れで処理を書きます。解析でやることは主にread()したあとにsubject, body(plain text), body(html), fromの中身を取得することです。html形式とplain text形式の両方が含まれます(相手が対応していない場合はhtmlはないかもしれません)。

メール転送はsend_mailだけ、中身は単純です。ここで注意しないといけないのは、replyおよびSourceにはSESで認証済みドメインしか使えないということ。このため、もしfrom情報を含めたければsubjectかbodyのどちらかに仕込むことになります。

コードは下記。

code

from __future__ import print_function

import json
import urllib
import base64
import boto3

s3 = boto3.client('s3')

EMAIL_TO = "送信先アドレス"

def send_mail(from_address, reply, subject, body, html_body):
    client = boto3.client('ses', region_name='us-west-2')
    client.send_email(
        Source="noreplyなど、送信専用アドレス",
        Destination={
            'ToAddresses': [
                EMAIL_TO,
            ]
        },
        Message={
            'Subject': {
                'Data': subject,
            },
            'Body': {
                'Text': {
                    'Data': 'from: ' + from_address + '\n' + 'body: ' + body + '\n' + 'html_body: ' + html_body,
                },
            }
        },
        ReplyToAddresses=[
            reply,
        ],
        ReturnPath="noreplyなど、送信専用アドレス"
    )

def lambda_handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = urllib.unquote_plus(event['Records'][0]['s3']['object']['key'].encode('utf8'))
    try:
        response = s3.get_object(Bucket=bucket, Key=key)
        mail = response['Body'].read().replace('\n','').replace('\r','')

        from_address = mail.split('envelope-from=')[1].split(';')[0]
        subject = mail.split('Subject: ')[1].split('To: ')[0]
        body = base64.b64decode(mail.split('base64')[1].split('--')[0])
        html_body = base64.b64decode(mail.split('base64')[2].split('--')[0])
        reply = "noreplyなど、送信専用アドレス"
        send_mail(from_address, reply, subject, body, html_body)
    except Exception as e:
        print(e)
        print('Error getting object {} from bucket {}. Make sure they exist and your bucket is in the same region as this function.'.format(key, bucket))
        raise e

以上です。細かく解説すると、

bucket = event['Records'][0]['s3']['bucket']['name']

でバケット名を、

key = urllib.unquote_plus(event['Records'][0]['s3']['object']['key'].encode('utf8'))

でファイル名を取得しています。LambdaのトリガーにS3を設定した場合必ずこれで取得できる構造になっています。

肝心の内容は

response = s3.get_object(Bucket=bucket, Key=key)
mail = response['Body'].read().replace('\n','').replace('\r','')

でメールオブジェクトを読み取ったあと、それぞれ

from_address = mail.split('envelope-from=')[1].split(';')[0]
subject = mail.split('Subject: ')[1].split('To: ')[0]
body = base64.b64decode(mail.split('base64')[1].split('--')[0])
html_body = base64.b64decode(mail.split('base64')[2].split('--')[0])

で送信元、タイトル(subject)、本文(body)、本文HTMLの4つを取得しています。元々のメールオブジェクトの中身は改行付きで1つの文字列として扱っておりわかりづらいので、mail = の行で改行を削除しています。そのうえで、ほしい情報を前後の文字列を見てsplit関数でうまいこと取り出しています。ゴリ押しですね...

S3のメールをダウンロードして中身のテキストを確認するとわかりますが、bodyの文字列がbase64 エンコードされています。これをbase64デコードするために

base64.b64decode

を用いています。そのため、頭の

import base64

を忘れないこと！

これ以外の情報がほしければ、同様にsplitを使って文字列を切り出して取得する。

ここではS3にメールを保存しっぱなしにしていますが、メールが溜まってきたら容量は圧迫されるので、転送完了後に削除しちゃっても良いかもしれません。

2016-12-24

俺は資産1兆円の植物人間な人生よりも、資産100万円でも健康な人生を選ぶ。

雑談

タイトルの意味
健康は長期的に見れば得だらけ。
日本はサプリ後進国
老後はロボットがいれば安心か？
健康は金で買う
まとめると

タイトルの意味

別に資産100万円しかなくても満足って言いたいわけではありません（笑）もちろん金は必要ですが、それ以上に健康さが大事ということが言いたいです。健康体ならいくらでも稼げるので。

私は結構な数のサプリを買って食事もなるべく決めたものを食っています。月1~2万円くらいはサプリ代で平均的に消えていきます。サプリとかそんなにたくさん買って高いでしょ？なんて言われるかもしれませんが、今は高く感じても後々になれば気にならなくなります。寧ろ不健康で医者にかかり続けるほうがどれだけ医療費で家計を圧迫することか。

将来的に、というより老後はあきらかに体力が衰えて怪我をしやすく病気になりやすくなるのに、なぜ若いうちに対策してる人が少ないか、理解に苦しみます。

別にサプリ買わなくていいんじゃん？と言う人もいますが、アルギニンやビタミン○○などサプリがないと不足しがちな栄養素もあるのも(おそらく)知らず、しかもそういう人に限って普段の食事がデタラメだったり。笑わせるなと。

健康は長期的に見れば得だらけ。

これを「それは知っている」といえる人はほとんどいないはず。なぜなら大抵はそういう行動をしていないので...身体を見ればそんな人は。面倒だけど、絶対若いうちから対策した方が良い。ずっと怠けてた人が老後から対策する余裕ないと思いますし。

健康でいることに普段は得に思わないかもしれませんが、病気になれば嫌でも気づきます。いや、高熱を出して身動き取れなくなった経験でも同様。辛い。苦しい。社会人なら働けないうちは金が入らない(有給使えば一時しのぎは出来る)。

金が入らないどころか医療費で金は出ていくばかりで、損しかしてない。それがなければ痛い思いも辛い思いもしなくて済むしなにより金が浮くので、健康的でいることによって結果的に得しかしてません。

日本はサプリ後進国

発展途上国と言ってもいいかもしれません。国産どころか海外の(主にアメリカ製)サプリなんて持ってる人はレアでしょう。統計を見たわけではありませんが、おそらく人口の1割未満な気がします。1割と言っても、日本の総人口1億２千万（2016/12現在）、その1/10だから1,200万人。成人は1億人、この1/10なら1,000万。キリの良い数字ですが、なんだかこれでも実感より結構多く感じますね？正しい知識を持ってる人がこんなに多いとはとても思えません...

それと比較してアメリカはサプリ大国ですが、これは文化の違いが大きそうです。

news.livedoor.com

確かに、病気になったら医者に行こう、ではないアメリカ的な考えなら当然かもしれませんね。医療費がシャレになりません。

そして含有量も違います。成分表記があるのは当然として、具体的な量を計算、比較してみれば一目瞭然です。やってみましょう。

国内で売られている某サプリは商品1つ約250円で1回15mg, 計20粒の亜鉛が入っています。これをすべて摂れば、亜鉛は計15mg x 20 + 300摂取できる。

それに対して例えば私が以前買ったCountry LifeのCalcium Magnesium Zincは割引なし(iHerbなら割引されることが多い)で約2400円で1回3個分で50mg, 3計250 Tabletsなので 50mg x 250 / 3 ≒ 4166mg.

個数を合わせて比較すると、250 / 20 = 12.5だから、某サプリのほうは250 x 12.5 = 3700円にもなります！海外製に比べて1000円以上高い。。。

しかも後者の海外製は名前の通りカルシウム、マグネシウムも一緒に入っており、こちらはそれぞれ1回につき1000mg, 500mgも摂れてしまいます。ついでにL-グルタミン酸100mgも。圧倒的に破格だと思いませんか。

というわけで、サプリ先進国なアメリカから仕入れるのはおすすめです。サプリの種類も含有量も間違いなく勝っている。種類が多すぎて、逆に何買ったらいいか分からない、となるかもしれませんが（笑）

毎日摂取するとなるとそれなりに値段も張るし、別にサプリを買ってなくても健康な人はいると思いますが、そういう人は生活習慣が優れているので、そんな人達の食事を一朝一夕で素人が真似できるものではないと思います。仮にその人が毎日野菜を○○g食ってるし筋トレストレッチしてる、酒は週1回限り、睡眠時間は6時間確保していると言われたとして、真似できるでしょうか。

老後はロボットがいれば安心か？

安心ではないんじゃないでしょうか？

ロボットが今後増えてくれば直接動けなくても日常生活くらいはなんとかなるかもしれませんが、それって俺にとっては幸せではないです。

仮に資産が1兆円超えしていようが、病院でずっと何本もの管を刺されて身動きすら取れないまま何年も生きたとしても、それは生物学上は「生きている」ですが私にとっては「死んでいる」です。希望を持てないまま過ごすのなんてそんなもので、価値が無いと思っています。所詮は個人的な意見ですが。だから、自分がそうなったら延命はやらないでくれと家族に言っています。そもそも延命は無料ではないので、やりたくても出来ない可能性も高いのですが。

「ロボットがいてくれたほうが凄く助かる」は良いとしても、「ロボットがいないと何も出来ない」は違う。それだとまさにのび太です。ドラえもんも言ってるでしょう、日本中がのび太だらけになったら国が滅ぶと（笑）

健康は金で買う

タイトルと矛盾しそうですが、つまり金は健康のために使うのがベストと言いたいです。まず健康第一、余裕があればその他に、という優先順位です。カネを使わなくても運動は自力でできますが金をかけたほうが手っ取り早く肉体強化出来るし、知識を仕入れるには本を読む、プロと知り合うなどする必要があるのでただでなんでも出来るとは思いません。生きるのにも金がかかりますね。。。

まとめると

日常的に思っていることをざざっとまとめました。一昨年までは堕落した生活を送ってきたからこそ、心機一転、これからは健やかに生きようと思ってこんな生意気なことを書いています。でも、この考え方は中々理解されないんだろうなあ(；´∀｀)少なくとも、国内でずっと右へ倣えしていたら絶対にこうはなりません（確信）私が偉そうに評価できることではないですが、周りに合わせることに一生懸命な人を遠目で見れるようになったら、なんとなく及第点な気がします。

ところで、タイトルは漫画「沈黙の艦隊」の海江田四郎のセリフ

牢獄の庭を歩く自由より　嵐の海だがどこまでも泳げる自由を
私なら選ぶ！！

をもじりました。元ネタはかつてない名言と思ったので、未だにお気に入りです（笑）この考え方が正しいかどうかはともかく、保守的な人間には一生言えないセリフです。これからリスキーな生き方をしていく自分にとって、何より励みになるし、大事なことだから心に留めておく必要があると思います。

というわけで今年も無事生き抜きます。

2016-12-22

AWSでのサービス制作(申し込みフォーム) - AWS Lambda/API Gateway/S3/DynamoDB/SES/CloudFront/ACM/Route 53

AWS Python HTML JavaScript

概要
IAM Role準備
- ユーザー作成
- グループ作成
IAM Roleでログイン
独自ドメイン取得/SSL準備
API形だけ作成
実データ配置(S3)
- S3へのPOSTアクセス
- キャッシュコントロール
テーブル用意
Lambda関数作成
Configure triggers
Configure function
API作成
- API Key設定
- CORS設定
フォーム作成
メール送信
作ってみてわかったこと

概要

最初に紹介した記事

および、前回作ったテストアプリ

から一転して、本命のアプリを制作します。ここまで得た知識+αを総動員してその集大成を見せるときが来ました。大まかな図はdraw.ioで作りました。

IAM Role準備

ユーザー作成

ここでは開発者ということでdeveloperとでもします。

以下でdevelopersグループを作成してそこにユーザを紐付けて、作成。

作成が終わったら、実際にS3やDynamoDBで操作ができるか、適当に触って確認してみましょう。

グループ作成

ダイアログでグループ名をdevelopersにします。Roleは

IAMFullAccess
AWSCertificateManagerFullAccess
AmazonS3FullAccess
CloudFrontFullAccess
AmazonDynamoDBFullAccess
AWSLambdaFullAccess
AmazonAPIGatewayAdministrator
AWSKeyManagementServicePowerUser
AmazonRoute53FullAccess
AmazonRoute53DomainsFullAccess

にチェックを入れて確認。最大10個までしか作れないので、一度設定して不要になったら権限を一部放棄しても問題ないです。アタッチ、デタッチは何度でも出来ますので。

これでもまだ権限的に相当強いですが、細かく設定するのが単に面倒なだけで。。本来は必要最小限にとどめたほうが良いのは言うまでもないです。

IAM Roleでログイン

上記まではroot相当の権限で操作していたはずですので、一旦ログアウトして、さっき作ったroleでログインし直します。

独自ドメイン取得/SSL準備

やり方は少し長くなるので別記事にまとめました。

API形だけ作成

Lambda関数作成に必要です。先にAPI名だけ用意します。

ここでのAPI名は制作するアプリ名としてちゃんとしたものをつけてあげましょう。

実データ配置(S3)

S3に必要なファイルを配置します。具体的にはLambda関数用のファイル(.py)をZIPで、他HTML/CSS/JavaScript/Image/Text(mail)をそれぞれ配置します。今回はこの方法で行きます。

その他、Lambda関数用ファイル(.py)と依存ライブラリをZIPにして別途LambdaへアップロードしてS3へPUTする方法もあります。

それについては

dev.classmethod.jp

の解説を見れば分かりやすいです。

バケットを作成してLambda関数用ZIPファイルを配備し、プロパティを覗いた例です。

S3へは直接アクセスさせずにCloudFrontを介する構成にしているので、ここでは公開後にプロパティのURLを叩いてもAccess Deniedエラーになります。

S3へのPOSTアクセス

これは禁止されているっぽく、実際にアクセスしてもMethodNotAllowedエラーが出ます。CORS設定してようが拒否られます。

stackoverflow.com

なのでPOSTしたいけどどうしてもS3のオブジェクトが欲しいって時はapi gateway経由で取得すると良い。

キャッシュコントロール

デフォルトでは設定がありませんがキャッシュが効いており、JSなど更新しても反映されるまでに時間がかかりすぎます。invalidationというのを使うらしい...

CloudFrontのDistributionsから該当のdistributionを選び、Invalidationsタブをクリックして、Create Invalidation

ここでパスを設定すればまとめてキャッシュを削除できます。毎回ここで消さないといけないのが面倒っちゃ面倒ですが。。

よく編集するJS, HTML, CSSは頻繁にアップすることになるので、まとめて

  /js/*
  /css/*
  /*.html

などして消せるようにしておくと楽です。

テーブル用意

DynamoDBにテーブルを用意します。データ構造を設計時に考えておくべきです。

セッションの永続化のためのテーブルを用意することも出来ますが、今回は単純な申込みフォームを用意するだけなので手を出しません。

noSQLなので複雑なオブジェクトも保存可能。だからこそあまり自由に作りすぎて後で階層が深すぎて取り出しに苦労する、なんてマヌケなことにならないように注意。

Lambda関数作成

必要なLambda関数を作成してAPIから叩けるようにします。

早速作ります。blueprintはBlank Functionを選択して最低限作ってもいいですが予めS3やDynamoDBを使うとわかっているので、それ用のblueprintを利用して書き換えたほうが楽でしょう。

runtimeをPython2.7に変更し、filterにとdynamodbと入れて出て来るmicroservice-http-endpoint-pythonを選択してNext。

Configure triggers

API name：事前に作成したAPIの名前

Deployment stage：prod(最初のデプロイでは他にステージがないので選択出来ません)

Security：Open with access key(keyは未設定ですが、後でAPIコンソールで編集します)

Configure function

Name：実際に作るアプリに関する分かりやすい、愛のある名前をつけてあげましょう。

Description：どんな機能なのかを書いたらいいと思います。

Runtime：Python2.7

Lambda function code

Code entry type：Upload a file from Amazon S3

S3 link URL：別でS3に配備したLambda関数用ファイル(.py)のパス(https://s3.amazonaws.com/作成したバケット名/ファイル名)

Lambda function handler and role

Handler：APIからLambda関数がコールされたときのエントリポイント。これの名前.pyがLambda関数のファイル名です。デフォルトのままでもいいです。こだわりがなければね。

Role：Create new role from template(s)

Role name：必要なroleは勝手に追加されていくので、ここではfunction名を決めるときの様に愛のある名前を！

HandlerはPythonのコード上ではデフォルトで

def lambda_handler(event, context):

となっている部分のことです。

ほかはデフォルトのままで。

Lambda関数はアップロード後にLambdaコンソール(画面)から修正できます。

Lambda関数作成後にエラーが出たら？

Create Function後は何かエラーが有る場合は下画像のようなwarningが出ます。

Trigger作成に失敗しましたと言っています。Lambda関数作成時にTriggerにAPI Gatewayを指定したうえで、TriggerにまだAPIにリソースを追加していないからですね。メソッドをAPIのリソース直下に作成まで終わったらLambdaコンソール上でTriggerタブ→Add triggerからAPI Gatewayを追加すればOKです。さっきと同じ設定でいきましょう。すると作成したリソース直下に新たにANYメソッドが出来ているはずです。

IAM role違いによるエラー！？

後でAPI Gatewayを編集していくとわかりますが、Lambdaでは独自のIAMロールを用いるので、api gateway経由でPOSTすると

The role defined for the function cannot be assumed by Lambda

とか怒られるので、Lambda側で開発に用いているIAMユーザを許可させてやる必要があります。そこで、

dev.classmethod.jp

の

リソースベースのポリシー

の部分から下に倣うと出来ます。一緒にやってしまおう。

API作成

今回は予約フォームのために必要なAPIを準備します。

API名だけは先に用意してあるので、その中身を埋める作業です。まずルートリソース直下にリソースを作成します。次にそのリソース直下にメソッドを作成します。メソッドはLambda関数のTrigger設定時にANYが作成されているはずです。が、これは使いません。自分で新たにGETなりPOSTなり作成します。

API Key設定

dev.classmethod.jp

の通りの設定で大丈夫です(一部UIが異なりますが)。

ただし

にある通り、一度デプロイした後に出来るので、ここではまだ作らず先にデプロイまで進めたほうがいいですね。先に作成だけして無効にしておいてもいいですが。

CORS設定

後述するformとの連携のため(主にjqueryとAPIの連携)、APIのCORS設定は必須です。

CORS設定は

とかを参考に。

はじめにAPIを作る時にCORS設定を同時に有効にしていなくても、後でリソースを選択してアクション→CORSの有効化、とすれば設定できます。しかもこちらならヘッダ情報も自動でつけてくれて大変便利！

統合リクエストのテンプレートマッピングも忘れずに。ここでどういう形式でLambdaにデータを渡すかを定義します。これがないとせっかくAjaxから渡したデータがlambda_handlerのeventに空で渡ってしまいます。

テンプレートマッピングは公式ドキュメントを参考に。

フォーム作成

S3の実データ配置の一部ではありますが、制作するフォームについて補足します。

フォームの作りは

を参考にしました。API Gatewayへのアクセスは、すべてAjaxで行います。事前にgateway側でCORS設定をしておき、テンプレートマッピングも用意する必要があります。S3の項目で書きましたが、formを作成したとしてもmethodはgetのみです。で、

~~.on('click', function() {
  location.href="次画面のリンク";
}

みたいなことやれば出来ますが、かなりゴリ押し感もしますね。S3がただのストレージなので仕方ないといえば仕方ないのですが。

メール送信

SESの設定をします。それ用にドメインを持つ必要がありますが、

この辺は下記記事に別途まとめました。

ここまでで一通り完成です。とは言え、勿論まだ改善の余地だらけだし、正直これで無料期間終了したら月いくらになるのか計算もしてません。セキュリティ的にここがまずい、とか探せば出そうなのでこれを真似して作るなら注意。

作ってみてわかったこと

とてもweb初心者には無理
言語そのものよりもインフラ、サーバ構築の知識が必要
これ専用の学習コストは相当高い。Lambdaは利用できる言語にも縛られるので、すべてをAWS構築にする必要はないかもしれない。→今ではRubyやC#も利用できるし、今後も追加されていくはずなので自由度は高くなる。
記事を書きながらだと理解が速い→おそらく正確に書くことが求められるから分からないところは調べざるを得なくなるので。

といった具合です。独自の用語を覚えたりどれとどれが組み合わせられるのか、その仕様までまず理解するところから始まります。何もwebを知らない初心者からすればただの迷宮です。

初年度無料は確かに魅力としてはでかいしスペックをほとんど気にせず使えるのはありがたいんですが、多機能なサービスには複雑さが伴うことは避けられないといえます。無理してこれを使うくらいなら、規模が小さいうちはサーバも全部自前で用意してCentOS7(本記事執筆時点での最新Ver)を入れるとか得意な言語によっては無料のサービス(Rubyが出来るならHeroku)があるのでそれをまず試してみるのもあり。

筆者自身この日までAWSド初心者でしたが、これで大凡の仕組みというか制作のキモくらいはわかったつもりです。これで堂々とAWS使えますって言える(；´∀｀)

2016-12-18

AWSでのメール設定/送信 - Lambda/SES (+お名前.com)

AWS インフラ

概要
IAM
SES
設定
サンドボックスからの脱出
SESでテスト送信
Lambdaでテスト送信
S3にメール本文を配備
Lambdaと連携
動的なメッセージを送るには？

概要

Amazon SESを用いたメール送信について書きます。

業務用のメールアドレスなのでgmailよりは自分のドメインを持ったメールアドレスにしておいたほうが良いでしょう。ということで独自ドメインを取得したらメールアドレスもそこで受け取れるようにしておいて、かつ送信も出来るようにします。ここでは送信専用として

noreply@独自ドメイン名

のメールアドレスを準備するとして進めます。
なお、SESはリージョンに東京がありません。今回はオレゴンを選択しています。

IAM

IAMグループに紐付ける権限は

AmazonSESFullAccess

をつけておけばいいでしょう。

SES

メールを自分とユーザの両方に飛ばします。スマホアプリの様にPush通知をするならSNSですが今回はPCも対応したいのと記録のためにメール送信としたいため、SESを用いることにしました。

全体的な流れは

で解説されているとおりです。

設定

操作方法は

に倣います。

SES Home(Domains)にアクセス
Verify a New Domainをクリック
独自ドメインなりメール送信に利用したいドメインを入力して、Generate DKIM Settingsにチェックし、Verify This Domainをクリック

ここまでで下画像の表示がされるので、指示に従って続きを進めます。

f:id:notwo:20161202160146p:plain

やることの概要としては、ドメインの発行元のDNSに、画像の中の設定(TXTレコード, CNAME, MXレコード)を追加しろと書いてあります。例えばお名前.comでドメインを取得したなら、お名前.comのドメインNaviから設定を入れてやればいいわけです。

その代わりにここでRoute 53にRecord Setを追加してやることで、ドメイン取得元に代わってSESでメールを受け取ることが出来るようになります。今回はSESでメールのやり取りをするので、上記画像ダイアログでUse Route 53をクリック。

→→※ただしこの場合はドメイン取得元でメールアドレスを受け取れなくなってしまいます。設定する場合は(英語ですが)説明文を注意深く読んでからやること。

チェックボックス全てにチェックが入っていることを確認して、Create Record Setsをクリック。

するとSESのDomainsにドメインが追加されたはずです。ただし今はまだpendingの状態です。この状態で数分待つとverifiedに変わります。筆者は30分くらい待ってやっと全部verifiedになりました。。

同時に、Route 53のHosted zoneを見ると確かにMXレコード等が追加されていますね。

次ですが受信ルールはRule SetsのCreate a Recipt Ruleから作ります。

ここではドメインを入力して、次にEdit RuleでRule Setを設定するのですが、ここでは送信だけしたいので、特に触れません。

次に送信専用のメールアドレスを設定します。

に従います。

さっき認証が完了したドメインをクリックして出て来るMail From Domainをクリック→Set Mail From Domainをクリック。

Mail From Domain: 認証済みドメインのサブドメインとしての名前をつけます。

Behavior if MX Record not found: Reject messageを選択

Set Mail From Domain

Publish Records Using Route 53をクリックしてMX, TXTレコードをRoute 53へ作成

SPFレコードにはチェックを入れず、他はチェックを入れてCreate Record Sets

これも数分(数十分？)かかるので待ちましょう。

※ドメイン名がバッティングしてるとRoute 53にMXは作成されないので注意！作成時にエラーが出ないので、verifiedになる気配がなかったら、一度Route 53の設定を見てみると良いです。

SPF不要なのは

とかで解説されています。

サンドボックスからの脱出

SESをスタートしたばかりの時点ではサンドボックスの中にいるのでその制限を外してやります。

これ用にIAMは

SupportUser

があると良いでしょう。

テストメール送信も、これが完了してないと成功しないっぽいので、いち早く完了させてやるべきです。

に従います。応答があるまでしばらく時間がかかるので、その間は別の作業をするべし。

自分の場合は夜に申請して翌朝見たらサンドボックスから外しました的なメールが来ていてすぐにメール送信出来るようになりました。

SESでテスト送信

サンドボックスからの脱出が終わったら、Domainsから該当のドメインをチェックしてSend a Test Emailをクリックして、宛先を自分のアドレスにして送信してみましょう。エラーなく届くはずです。

Lambdaでテスト送信

これができればいよいよ好きな内容のメールを送れるようになります。

ただし、下記の通り、Lambda関数作成時に専用のroleを作成していると思います。このroleにはSESのSendEMail実行権限がないので、怒られます。

stackoverflow.com

ということでIAM Roleのポリシーを修正します。Lambdaで使用中のroleをIAMのAWS Console→ロールから探して、ポリシー名をクリック→ポリシードキュメントを編集して、"Action"の配列に"ses:SendEmail", "ses:SendRawEmail"もしくは"ses: *"を追加して保存しましょう。

設定が終わった後Testで送信すればエラーなく送信できるはずです。まずは自分宛てのメールを送信して試してみましょう。

S3にメール本文を配備

メール本文はコード上にあってもいいと思いますが、見やすさと再利用性のため分けたほうがbetterです。というのと上記スライドにある通り、添付ファイルとか容量の問題が出るためです。

というわけで配備しましょう。

配備するメール本文のファイルの形式をCloudFrontのBehaviorに設定するのも忘れずに！

それとメールはアップロードするだけでなく公開してないと読み込めません。

Lambdaと連携

API Gateway → Lambda → SESの連携をうまくやっている例は

raspi.seesaa.net

が分かりやすかったです。

宛先、Subjectなどは入力値や内部で用意した文字列を使って埋めていきます。

自分宛てに送信してみましょう。SESから送った場合、Lambdaに処理を書いて直接送った場合と同様、画面からAPIを叩いて送信出来るところまで確認できればOK。

動的なメッセージを送るには？

本文を動的に書き換える、例えば予約フォームに入れた氏名をメール本文に出したい場合はどうするか？といったものです。これは本文をS3に保存してLambdaで取り出して一部を書き換えて送信すればOK。

書き換えたいパラメータを何かしら分かりやすい変数名など埋め込んで用意し、Lambda内でbodyを読み込んで書き換えます。

Lambda(Python)からS3オブジェクトを取得するサンプルは