街コロの期待値を出す

街コロとは

これ

街コロ

街コロ

ルールなどはここ などを参照して欲しい。

モチベーション

どうやっても序盤は森林を買い、周りが駅を建てるに連れて鉱山/家具工場への流れが最強な気がしているんだが、ここまで売れているゲームなのだから他の戦略もあるのだろう、と思い各カードの期待値を出してみた。

コード

建物の数やプレイヤー数で収入が変動するものは除外
期待値はプレイヤー1週で得られる収入
サイコロの数は全員同じとする

街コロの期待値を出す · GitHub

結果

プレイヤー数(試行回数): 4

麦畑(blue) 目:[1] コスト:1 収入:1
サイコロが1つ 期待値:2/3 元が取れるターン数:2
サイコロが2つ 期待値:0  元が取れるターン数:Infinity

牧場(blue) 目:[2] コスト:1 収入:1
サイコロが1つ 期待値:2/3 元が取れるターン数:2
サイコロが2つ 期待値:1/9  元が取れるターン数:9

パン屋(green) 目:[2, 3] コスト:1 収入:1
サイコロが1つ 期待値:1/3 元が取れるターン数:3
サイコロが2つ 期待値:1/12  元が取れるターン数:12

コンビニ(green) 目:[4] コスト:2 収入:4
サイコロが1つ 期待値:2/3 元が取れるターン数:3
サイコロが2つ 期待値:1/3  元が取れるターン数:6

カフェ(red) 目:[3] コスト:2 収入:3
サイコロが1つ 期待値:3/2 元が取れるターン数:1
サイコロが2つ 期待値:1/2  元が取れるターン数:4

森林(blue) 目:[5] コスト:3 収入:1
サイコロが1つ 期待値:2/3 元が取れるターン数:5
サイコロが2つ 期待値:4/9  元が取れるターン数:7

鉱山(blue) 目:[9] コスト:6 収入:5
サイコロが1つ 期待値:0 元が取れるターン数:Infinity
サイコロが2つ 期待値:20/9  元が取れるターン数:3

ファミレス(red) 目:[9, 10] コスト:3 収入:2
サイコロが1つ 期待値:0 元が取れるターン数:Infinity
サイコロが2つ 期待値:7/6  元が取れるターン数:3

リンゴ園(blue) 目:[10] コスト:3 収入:2
サイコロが1つ 期待値:0 元が取れるターン数:Infinity
サイコロが2つ 期待値:2/3  元が取れるターン数:5

感想

鉱山の期待値が20/9というのはぶっ壊れ性能では…
序盤はカフェが強い。駅が揃い始めたら建てる必要はないだろう。
プレイヤー人数が増えるほど緑(自分のターンでのみ収入が得られる)カードの効果は薄まる。緑の収入全体的に増やした方が良かったのでは…?と思うくらい。

標準ルールでは全ての建物を自由に選択できるので戦略が固定化されがちだが、拡張ルールでは序盤に建てられる建造物が限定化されておりランダム性が増すので、こちらで遊んだ方が楽しそう。

ゼロからReduxを学びボドゲのシミュレーターを作った

モダンなJSの開発環境とReact/Reduxを習得したくて、課題としてちょうどハマってたボドゲのシミュレーターを作った。

デモ

Dungeon of Mandom Simulator

ソース

github.com

ReactとFluxは一時期趣味で触ったことがあるくらいで、記事を遡ったら既に2年前の話だった。

norizabuton.hateblo.jp

技術選定

ビルドツール

babel/Webpackを使用。小規模なJSにbabelを使いたいだけであればbabelifyを通すだけで良さそうだが、今回はきちんと学ぶという名目なのでWebpackをちゃんと整備することにした。後々css-loaderを使ってCSS Modulesを試すこともできたのでこの選択は良かった。

AltJS

型が欲しいと思いTypeScriptかFlowで迷った。TypeScriptは現在ReactやAngularでもサポートされており、息が長そうで学ぶ価値は高そうという印象だが、既にbabel/Webpackでビルド環境を構築しており、ここからts-loaderを導入してTS用の環境を作るのが面倒だった(この時点で既にビルド環境構築に1週間ほど費やしている)ので、今回はbabel/Webpackに比較的乗せやすいFlowを選択した。

テスティングフレームワーク

node.jsでサーバーを立てた時にmochaでテストしていた経験はあったが、今回はReduxも推しているJestにし、assertはpower-assertを使ってみた。Jestはmochaと比較しても記法は対して変わらないので学習コストとしては大したことはなかった。デフォルトでMockになるので単体テストが容易という特徴があるらしいが、依存しているモジュールが少ないせいか今回はあまり恩恵を受けられなかった。

デザイン

同僚からantが綺麗で良いというオススメをもらったがmaterial-uiが使いたかった。使ってから気づいたがmaterial-uiにはBootstrapのGrid Systemは標準では存在してなさそうで、導入したければ恐らくサードパーティのものを使う必要がありそうだった。

エディタ

最近AtomからVS Codeに乗り換えたのでこれで書いている。Flowを入れてから気づいたが、VS Codeで型を定義すると.tsでないと使えないぞと怒られる。*1

f:id:Peranikov:20170318103654p:plain

これを回避するにはVS Codeの設定で "javascript.validate.enable": false とすれば良いのだがあまりに場当たりっぽい。

下記設定を試したところjsのコードハイライトが消えてしまったのですぐ戻した。

"files.associations": {
      "*.js": "flow"
    }

github.com

Issueの方でも正式な解決策は無さそうで今のところは警告を無視するしかなさそうな気がしている。つらい。

デプロイ

静的サイトなのでgh-pagesを使いGithub pagesにデプロイした。1コマンドでデプロイできめっちゃ便利である。

Redux所感

このくらいの規模のアプリケーションであれば正直Vue.jsを使ったほうが速く書けるし設計もさして重要ではなさそうである。各レイヤーの役割を覚えるまではコードが分散するので追っていくのが大変だが、慣れてくればどこを修正すれば良いのかがすぐわかるので後のメンテナビリティは上がりそうな気はした。

Modelレイヤー

Reduxを書き始めてすぐに気になった所は、どうやらロジックがreducerに集中してどんどんFatになっていく気がした。なので、下記記事を参考にimmutable.jsとModelレイヤーを導入した。*2

post.simplie.jp

モデルにロジックが集約していくのでテスタビリティも向上し、ロジックの見通しも良くなったと思われる。

それとは別に、Containerなどでコレクションのフィルタリングをしているのだが、モデルの構造を意識してフィルタリングしたくなく、もっと抽象的に扱うためにファーストクラスコレクションを導入したくなった。が、immutable.jsのコレクションは直接拡張することはどうやら難しそうで、公式でないextendable-immutableを用いれば実現できそうな気がしたが、なんとなく依存を増やしたくなく、PureなJSで色々試していたがあまりうまくいかなかった。良い例があったら知りたい。

Constantsの意味

ReduxではActionとReducerはActionTypeという文字列のキーを使ってロジックを紐付けるのだが、わざわざ定数を介する意味が見えず最初は直接文字列で書いていた。途中で気になって調べたところ、下記記事からメリットが複数あることがわかった。

stackoverflow.com

要約すると、

  • ActionTypeの一覧性が1つのファイルに集約するので、既存のアクションが把握しやすく名前の一貫性を保ちやすくなる
  • IDEを使っていれば補完が効くのでタイプミスを誘発しにくくなる
  • 変数名を介してアクセスするので、minifyの効果が向上する

ということで、ActionTypeのファイルを設けることにした。

デバッグ

イベントが発生後にStoreがどのように変化したかデバッグするために方法を探ったところ、redux-devtoolを見つけた。redux-devtoolはとても高機能で、Storeの状態を確認する以外にもActionのUndoやResetが可能らしいのだが、専用のComponentを導入する必要があったり、コードを多く変更する必要がある印象を受け、敷居の高さを感じ今回は見送った。それとは別にredux-loggerというものを見つけた。こちらはイベントの度にStoreの変更前と変更後をロギングしてくれ、比較的導入も楽で必要十分と感じたのでこちらを使用した。

テスト

公式を参考にaction/component/reducerのテストを書いてみたが、ロジックが大したことないのもあって、あまり必要性を感じなかった。Actionは外部APIを叩いたり非同期な処理が増えてくると有用性も高まるかもしれない。Componentsのテストも試しに書いてみたが、デザイン性に大きく関わる部分なのでどういう観点でテストを書けば良いのかがまだあまり掴めていない。Componentsにロジックが寄るのは恐らく設計としてあまりよろしくなさそうだし、UIについてはE2Eテストを別途設けたほうがむしろ有用ではないかという疑念が残っている。

さいごに

ダンジョンオブマンダムは良ゲーだったので買って遊ぶと良い。

ダンジョンオブマンダム

ダンジョンオブマンダム

*1:いかにもMSが作ったエディタっぽい挙動

*2:どんどんFacebookに染まっていくぞ〜

2016年を振り返る

今年も今日を含めてあと2日で終了するので振り返っておく。

なお去年の振り返り。

norizabuton.hateblo.jp

川崎Ruby会議やった

norizabuton.hateblo.jp

スタッフとスピーカーという立場で参加した。自分の中では今年一番大きなイベントだったと思われる。気になるのは来年もやるのかというところだがまだ何も決まってはいない。Kawasaki.rbは土地柄かWeb屋が少なくRuby以外で仕事してる人のほうが割合として多い*1ので、今年の川崎Ruby会議もそのカラーを前面に出し、コンテンツも特にRubyにこだわらずに実施した。もし次回があるのであれば、このカラーは続けていって欲しいと思うし、そんな内容でも聞いてみたいと思う人は是非参加して欲しい。

なおkawasaki.rb公式ブログは今年からMediumに移行して絶賛継続中である。去年の4月から毎月休まず寄稿しているぞ。

データの民主化SQLハンズオン

今年はやたら「データの民主化」という言葉が耳に入った年だと思う。弊社でもRe:dashが整備され、非エンジニアがデータベースにSQLを投げられる環境は整われた。

ただ、環境は整備されても初めてSQLを投げるのはハードルが高く、当初はその人の席で直接SQLを教えながら手伝っていたのだが、手も回らないし全体的に基礎的な事を先に教えた方が良かろうと思いハンズオンという形式で実施した。

norizabuton.hateblo.jp

なおこの記事の2週間後に第2回を実施している。内容は1回目で苦戦したJOINとGROUP BYを図解込みで解説し、残りの時間で難題かと思われたサブクエリの演習をした。講習でなくハンズオンという形にしたことで、課題を解けたという達成感と実際のデータ取得に応用してみようというモチベーションに繋がったと思う。現に、弊社SlackのSQL質問チャンネルでは既にエンジニアを介さずに質問と解答が繰り広げられていた*2

技術スタック

川崎Ruby会議ではScalaについて話してみたものの、結局あまりScalaには触らず、仕事ではRubyを使うことのほうが断然多かった。今年はモニタリングとパフォーマンスチューニングをすることが多かったからか半インフラ業のような仕事が多く、DockerとGatringで負荷テスト、Passengerのチューニング、AWSのサービス(Lambda, CloudWatch, ElasticBeanstalk...)と仲良くなった。特にLambdaとSlackは監視に使うには本当に便利で、最近ServerlessFrameworkも覚えたしどんどん活用していきたい。

あとCUIツールとか今はRubyで書いちゃうんだけど、配布とか考えるとGo覚えてさくっと書けるようになりたい。

まとめ

気の利いたまとめを書こうと思ったが特に何も思い浮かばなかったのであえて書かない。

皆様良いお年を。

*1:Cで組み込みやってますみたいな人もいる

*2:仕事が減ったぞガハハ

社内向けにSQLハンズオンやった

弊社内でRe:dashが整備され、エンジニア以外でもブラウザから気軽にSQLが叩ける用になった。 ただ気軽になったと言ってもいきなりSQLを使いこなせるわけはないので、社内向けに1時間程度のハンズオンを実施したのでここにまとめておく。

目的とゴール

目的はとりあえずSQL(主にSELECT文)の勘所を掴んでもらい、基本的な質問などは非エンジニア部署のメンバー間で解決できるようにしたかった。

なので今回のハンズオンのゴールは

  • 基本的なSELECT文が叩ける
  • Re:dashの基本的な操作ができる

という点に設定した。SELECTで使用する句の範囲は

  • WHERE
  • ORDER BY
  • LIMIT
  • GROUP BY
  • HAVING
  • サブクエリ

とre:dashの簡単な解説とした。

進行方法

自分が前に登壇してセミナー形式にしても良かったのだが、なんとなく退屈になりそうという点と、自分たちで調べて解決したという達成感があった方が身につきやすいのではという実験的な試みから以下のようにした。

  • いきなり制限時間5分の課題を解いてもらう(ex. あるテーブルの◯◯ごとの件数上位n件を表示せよ)
  • 課題には関連するテーブル名やカラム名、使用するSQLの句をヒントとして付随させる
  • SQLの句の使い方はぐぐって調べてもらう
  • 解けたものは解けてない者の手助けをしてよい
  • 5分経ったら解答例提示、解答の解説、質疑応答
  • これらの繰り返し

互いに教え合うという点は、幸いメンバーの技量が

  • SQLほとんど触ったことない: 3名
  • SQLでデータ取得したことある: 4名

とバランスが良かったのでうまくまわった。

得られた効果

セミナー形式と違って自分たちで問題を解くので、実際にSQLを叩く中でハマりやすいポイントと、細かい疑問(各句は大文字小文字どちらが良いのか、改行する意味はなんなのか、COUNT(*)に指定するカラム名はなんでも良いのかなど)も浮き彫りになり、それらを解消することができた。

また、教え合うことで主催者の手が回らず質問できないという事象を避けることができ、無事にほぼ全員が解答まで導けることができた。なにより楽しかった、またやって欲しいという声もいただけた。

反省点

INNER JOINやGROUP BYなど、少し複雑になるケースの解説はもう少し厚くした方が良かった。テーブルのイメージを把握してもらうために多くの図解を加えるべき。(INNER JOINで結合するカラムはRailsの規則によるところがあるので、さらに多くの解説を要した)

1時間でやってみたところ途中までしか終えられず、さらに解説を多く含めるのであれば何回かにパート分けした方が良さそうである。

川崎Ruby会議 01の実行委員 & 発表しました #kwsk01

2016/8/20に開催された、川崎Ruby会議 #01 の実行委員と発表をやらせていただきました。

regional.rubykaigi.org

事の発端

会の内容はるびまに、開催に至った経緯などは実行委員長のブログに任せるとして、個人的に実行委員になった背景を書きます。
僕は2015年1月からKawasaki.rbに通い続け、その後2015年4月からKawasaki.rb公式ブログの中の人を務めるようになり、その甲斐もあってか本家Ruby会議の帰りにchezouさんに川崎Ruby会議を企画しているので手伝ってもらえないかと声を掛けられ、その後正式に依頼されたので引き受けることにしました。

実行委員としてやったこと

こういった実行委員は初めての体験だったので、気づいたことと落ちているタスクは積極的に拾っていこうと思いながら手伝っていました。大きなものではWebページのロゴとスタッフTシャツ作成と当日のるびま用撮影担当、細かいことではミーティングのスケジュール調整やWikiのメンテ、懇親会会場の確保などをしていました。

発表したこと

実行委員でありながら「Rubyistを誘うScalaの世界 2.0」というタイトルで発表させていただきました。
Ver 1.0は一度Kawasaki.rbで発表したのですが、今度は20分枠ということで、未経験者にもより丁寧にScalaの説明と魅力を伝えられるよう心がけました。
参加者でScalaを触ったことあるか質問してみたところ、半数以上が手を上げた気がしたのでもう少し内容を厚くしても良かったのかもしれませんが、発表後に面白いと言ってくださった方もいたので良かったです。

妻は偉大

当初、Webサイトのロゴは用意しない流れだったのですが、折角なので妻に「kwskバザーで連想できるロゴ描いてみてくれない?」と聞いてみたら何パターンか描いてくれて、メンバーに見せたところ思いのほか好評だったので採用に至りました。その後TMIXさまからTシャツスポンサーの申し出があり、ロゴをそのままTシャツのデザインに使いまわそうとしたところ、妻に「そのまま使えるわけないだろ」とありがたいお言葉をいただき、Tシャツのデザインも新たに描き下ろしてもらいました。本当に頭が上がりません。前回の神奈川Ruby会議や東京Ruby会議11のロゴも実行委員長の妻によって描かれたものらしいので、Regional RubyKaigiは妻によって支えられていると言っても過言ではないでしょう*1

なお発表のスライドの4ページ目の通りなのでこんなものをしれっと用意してあります。何卒...!何卒...!

さいごに

発表・参加いただいた皆様、どうもありがとうございました!また機会がありましたら参加いただけると嬉しいです!

f:id:Peranikov:20160820111038j:plain 写真はスタッフTシャツのままカレーを食べに行くスタッフ達

*1:多分

子供の夏休みの宿題を手伝うお父さんお母さんのためのGemを作った

全国のお父さん、お母さんエンジニアの皆様お待たせしました。

事の始まり

なんか弊社CTOが困っていた

事情はよくわからないが、恐らく子供の宿題を手伝うやなんやかやで、子供が書いたっぽい文章にしたいがために感じ漢字をよろしくしたいのであろう。 我々はエンジニアだ。無いのであれば作ればいいのである(キリッ

というわけで作った

github.com

特定の学年の小学生が習っていない漢字をひらがなに変換するGem、名づけて「Furiganize」。オプションに学年を指定することができる。要YahooAppId。
なお僕に子供はいないのでドッグフーディングはしておらず使い勝手のほどは知らない。

使い方

$ gem install furiganize を実行後、

$ furiganize -a [YOUR_YAHOO_APP_ID] -g 3 '小学三年生が書いたこの文章は魑魅魍魎' # => 小学三年生が書いたこのぶんしょうはちみもうりょう

とするだけで子供が習っていない漢字をひらがなに変換してくれる。学年は -g に指定すべし。
無駄にSTDINからも読めるようにしておいた。

$ echo '小学三年生が書いたこの文章は魑魅魍魎' | furiganize -a [YOUR_YAHOO_APP_ID] -g 3 # => 小学三年生が書いたこのぶんしょうはちみもうりょう

技術解説

解説といってもなんのことはなく、Yahooのルビ振りAPIを叩いているだけである。

developer.yahoo.co.jp

当初は学年ごとに習う漢字の辞書とMeCabなどの形態素解析を組み合わせて作ろうとしたが、調べている内にドンピシャなサービスがあったので楽した。
リンク先のサンプルレスポンスの通り、習っていない漢字には Furigana 、習っている漢字には Surface のみが返ってくるのでそれらを連結しただけである。
レスポンスはXML形式なので nokoigiri を使った。具体的な箇所のみを抜き出せば

doc = Nokogiri::XML(open("http://jlp.yahooapis.jp/FuriganaService/V1/furigana?appid=#{@app_id}&grade=#{@grade}&sentence=#{URI.encode(@sentence)}"))
doc.css("Word").map {|w| w.at_css("Furigana") || w.at_css("Surface") }.map(&:text).join

としているだけ。

「実践SERVERLESS」に参加してきた #cmdevio

2016年8月2日に実施された「実践SERVERLESS」に参加してきました。会場は目黒雅叙園にあるAmazonさんのオフィスでした。周りに珍しいポケモンはいませんでした。

classmethod.connpass.com

雑ですが以下参加メモ。資料は公開されしだい更新します。

Introducing Serverless Computing アマゾンウェブサービスジャパン 西谷 圭介氏

AWS Lambdaのユースケース

Real-time file processing

  • イメージのサムネイル生成
  • ビデオの変換(投稿動画が問題ないか解析したり)
  • ドキュメントのメタデータをインデックス化
  • ログの処理
  • メディアコンテンツのバリデーション

Real-time stream processing

  • クライアントのアクティビティトラッキング
  • クリックストリーム分析
  • メトリクス生成
  • データクレンジング
  • ログフィルタリング
  • インデクシング
  • バイスデータのテレメトリと測定

ストリームデータをKinesisに貯めてLambdaに流すケースが多い

Extract, Transform and Load

  • データバリデーション
  • バックアップ
  • 分析

Serverless web and mobile application

以下の組み合わせが多い

  • 静的コンテンツ S3
  • 動的コンテンツ Lambda
  • HTTPアクセス API Gateway
  • NoSQLデータ・ストレージ DynamoDB

Lambda と API Gateway の管理 クラスメソッド 諏訪 悠紀

サーバレスの役割

  • どこをサーバレスにするか
  • サーバレスは様々なレイヤーで使用できる

フロントエンドレイヤー

バックエンドレイヤー

  • ユーザの目に見えない部分
  • Data Processingなど
  • SNS + Lambda
  • S3 + Lambda
  • Streams系 + Lambda

他にも

  • Cognito User Pools + Lambda
  • CouldFormationのLambda-backend カスタムリソース
  • Slack + API Gateway + LambdaでChatOps

管理方法の選定方法のコツ

  • いっぱいある
  • ツールごとに管理する上での観点が違う

API Gatewayとの併用

  • 対象がAPI GatewayとLambda(もしくはLambdaのみ)
  • フロントエンドを対象としているツール(フレームワーク意識)が多い
  • Lambdaのみを対象としているツールは汎用的で導入しやすい

他のリソース管理

  • 規模による
  • 規模が大きく管理するリソースが多い場合は分割したほうが良い(例えばAPI GatewayとLambda、他は別ツールなど)
  • 小さい場合はまとめたほうが管理しやすい

ロールバック

  • 対応しているツールとしていないツールがある(Lambdaを前のデプロイに戻したい場合)
  • ロールバック非対応の場合は手作業か自分で実装する必要があり手間がかかる

使い回し

  • そのアーキテクチャを他のサービスで使い回すか?
  • 汎用的にする必要があるか?
  • 設定値は実行時パラメータ?
  • 環境変数は必要か?

管理ツール6種使い比べ

AWS CloudFormation

  • AWSのリソース管理できる
  • JSON記述
  • 他のAWSリソースも管理出来る
  • 依存関係定義
  • 実行時パラメータを定義可能
  • Lambda、API Gatewayサポート
  • ソースコードJSON内に記述可能
  • EventSourceMappingをイベントソースに指定可能

Serverless

Apex

  • Lambda特化
  • LambdaファンクションのBuild/Deploy/Manageが可能
  • Terraform連携
  • Lamdaファンクションをテストするコマンドもあり

Gulp

  • Node.js界隈でよく使われる
  • 既にGulp使っているのであれば良さそう

SwaggerHub

  • Swaggerのクラウドサービス
  • Swaggerドキュメント(設定ファイル)をブラウザで記述できる
  • API Gateway & Lambdaへのエクスポートが可能

Chalice(Beta)

  • awslabsで公開
  • API Gateway + Lambda
  • Pythonで動く
  • IAMを自動で生成することもできる

Flourish(Comming Soon?)

  • Serverless Confで発表された
  • AWS支援のOSS
  • SwaggerHubライク

まとめ

  • 何を重視するか
  • 最適な管理方法を選定しよう
  • いろいろなツールに触れよう

質問

  1. API Gatewayサポートと言いつつ、一部APIをサポートしていないケースがあったりするのだがどうしているか
  2. 実際にそのケースはある。Cloud Formationはほぼサポートしているのでおすすめ

実際に使う Cognito UserPools クラスメソッド 丹内 優紀

speakerdeck.com

ServerlessとCognito

  • Serverlessアーキテクチャとは: 非常駐型プロセスをイベントによってトリガーするインフラストラクチャ
  • AWS Lambdaが代表的

serverlessで解決したい問題

  • EC2無しで簡単なプログラム運用(手間、お金)
  • アプリケーションから本質的でないコードを少なくしたい
  • Lambda以外のアプローチもある

Cognitoとは

アプリケーションの認証・認可をサポートするフルマネージドサービス

Cognito Identity

  • 外部で認証されたユーザに対して機能を提供する
  • Federated Identity
  • 外部の認証サービスからの名寄せ
  • 匿名ユーザとして認証可能(地味だけど結構大事)
  • 複数のIdentity ProviderをひとつのIdentityとしてマージ可能

STS

  • AWSへのアクセスキーを安全に発行する
  • AssumeRoleやCondition節などIAMとの連携
  • 短期間だけ有効なIAMを発行可能

Cognito Sync

  • ユーザデータの同期機能を提供
  • Sync Store
  • KVSのように使えるデータストア
  • SDK経由ならローカルストレージとの連携も簡単

Cognito Streams

Kinesis Streamsに送信できる

Cognito Events

Lambda Functionを実行できる

Cognito User Pool

  • AWSが提供するIdentity Provider
  • ユーザの登録・管理、認証
  • パスワードやMFA、確認メール送信など一般的な認証機能を持っている
  • GAになった!東京リージョンにも来た!

User Poolsの機能

  • ユニークなユーザ名を設定
  • パスワード認証、MFA
  • パスワードポリシーが利用可

アトリビュート

  • ユーザごとに属性を設定可能(性別、住所、いろいろ)
  • エイリアスによってログインで使用する属性を指定可能
  • 独自のアトリビュートも可能

メール・SMS確認・MFA

  • 認証コード発行
  • メッセージのテンプレート編集可能
  • MFA可能

バイストラッキング

  • 同一ユーザのログイン上限を設定可能
  • 初回ログイン時に認証とは別にトラッキングのトークンが発行される
  • ラッキングが有効な端末はMFAをスキップ可能
  • 管理者はSDK非公開のREST APIからデバイスリストを取得可能
  • Global Sign-out(同一ユーザの全端末サインアウト)や管理者権限サインアウトも可能

トリガ

  • Lambda Functionと連携可能

Cognito Identity連携

ポリシー変数

  • Cognitoに割り当てられるIDに一致するリソースのみへの権限発行
  • サーバを介さない処理を安全に行える
  • IAMのCOndition節に変数を記載

OIDC Provider

  • GoogleやSalseforceなど
  • SAMLも使えるようになった

大量リクエスト時の制限

Trust Relationship

  • どのTOken発行者に対してAssume Roleを許可するかのポリシー
  • 自分で編集するとハマる

まとめ

  • User Poolsで認証機能をAWS
  • Cognito Identity連携でより多くの機能が使える
  • 自分のビジネスに沿うやり方でサーバレスに

質疑応答

  1. Emailのメッセージに日本語入れて保存できない?
  2. (会場で実際に試して)できないですね。