はてなの金次郎

とあるエンジニアの技術系ブログ

Alexa Salon #1 に参加してきました

Alexa 勉強会

感想

dev.classmethod.jp

Alexa Salonに参加してきました。スキル開発をするにあたって色々勉強させていただきました。じゃんけん大会負けてしまいましたが、本も読んでみたいです。

はじめてのAlexaスキル開発 [音声認識アプリ開発の基礎知識を身に付ける! ]

はじめてのAlexaスキル開発 [音声認識アプリ開発の基礎知識を身に付ける! ]

SINさんのブログとてもわかりやすかったのでおすすめです。

dev.classmethod.jp

基礎から学ぶVUIの勘所

自己紹介

VUIとは

会話における法則

  • Voice Communication
  • メラビアンの法則（視覚情報：58%、聴覚情報：38%、言語情報：7%）
    • 言語情報は10%未満
    • Echoは20~30%で戦う必要がある

VUI設計で気をつけること

  • NUDGE
    • 行動経済学用語
    • ユーザーが相手の自然かつ無意識に意図通りの行動を起こすように環境を整え促すこと

留意点

  • 選択肢を例示する
  • はい/いいえで答えられるように促す
  • 一息で言い切れる長さ
    • ユーザーが鬱陶しいと思わないように
    • 書き言葉をそのまま使っては行けない
    • 録音して長いと思ったところは切る
  • 「〜ですか？」：は等価、「〜ですね？」は強調
    • はいと言ってほしい時など

GRAPH BASE UI vs FRAME BASE UI

  • VUIではFRAME UIが良い

MULTI-TERN

  • ユーザーがたくさん話しすぎるのはだめ
  • ピンポンの会話にする

VUI設計の作り方

  • 目的を決める 　- なにをしたいか 　- そのためにUX的に音声でどう体験してほしいか。 　- どこまでVUIにするか。 　- VUI以外との連携は。 　- ユースケースを想像する。毎日使うのか、必要な時に使うのか。
  • キャラクター設定
    • ペルソナを作り、発話に一貫性を持たせる
    • ユーザーとの距離感
    • Alexaの立ち位置
  • ハッピーパス
    • ストレートな対話を作り、これを軸に
  • INTENT/SLOTの設計
    • State-Intent-Slotのスコープを決める
    • Intentはなるべくシンプルにまとめる
  • UI図
    • ハッピーパスを肉付けする
    • 重要なSlotと必須ではないSlotを区別しておく
    • Slotの最中に別Intentに飛ぶケースを想像しておく
    • 結構修正するので具体的な発話を書かない
  • UTTERANCE表の作成
    • 規模によっては以外と重要
    • 被ってないか確認
  • シノニム/バリエーション
    • ひたすら想像力
    • 5種類をランダムに
    • 頻度によってメッセージを帰る
  • エラーハンドリング
    • キャラクラー設定を元に判断する
    • 謝りすぎない
    • 疑問形で終わる
    • エラー回数によって選択肢を明示する
    • ストップへの誘導

まとめ

  • VUIはAlexa開発のキモ
  • 図を書くまえの準備がクオリティを上げる

Alexa-SDKについて

www.slideshare.net

自己紹介

  • 平内真一さん
  • アプリケーションエンジニア
  • ブログを業務時間に書いていい

Alexa SDK

  • 煩わしい作業をSDKに押し付けて、開発者はロジックに集中できてウハウハ
  • リクエスト・レスポンスJSONの抽象化
  • データの保存
  • 処理のルーティング（ハンドラ登録）
  • ステート（状態）

バージョン1と2

  • 4/18以前
  • はじめてのAlexaスキル開発
  • Lambdaのテンプレート

バージョン2

  • ハンドラの実装法穂が変わった
  • データ永続化の記述が明確になった
  • コア機能のみの利用可能
  • Node8対応(async/await)
  • DynamoDB以外も利用可能
  • AlexaサービスAPIのラッパー提供
  • Java + Node.js

https://dev.classmethod.jp/cloud/alexa-sdk

変更点

  • tell, askの廃止 --> ResponseBuilder
  • ステートの廃止
  • ハンドラのインターフェース canHandle
  • データ永続化の要領
  • 例外時の処理

最後に

  • Ver1の方が簡単に描ける
  • Ver1に未来はあるのか・・・？
  • これから取り掛かるならVer2でいいかも
  • 個人的には、Ver2押し
    • データ永続化が明確
    • canHandleも慣れると悪くない
    • Alexa APIへのアクセスが超簡単
    • async / await 最高
    • TypeScriptで書ける

大質問大会

Q.対話モデル・対話フロー設計時のオススメの方法があれば教えてください。

Q.開発方法、事例、活用ポイントについて

  • Cloud9
  • alexa-conversation テスト

Q.ニーズが高いスキルはどのようなスキルか

  • Amazon的には子供向けスキル
  • USでもキッズ向けが人気
  • キャラクターの声がなんかしてくれる

Q.広告ポリシー

  • 子供向けは広告だめ

Q.勝手に喋り出す機能はないのか？

  • プッシュ通知機能はある

Q.バックエンドに機械学習を絡めることはできるか

  • あったら面白そう

DBテーブル設計入門に参加してきました

勉強会

感想

supporterzcolab.com

サポーターズCoLabの「DBテーブル設計入門」に参加してきました。

DB設計ムズイ。

データの種類によってテーブルを分割したり、ミドルウェアを変更したりと考慮するべき点が多いなと改めて感じました。 アンチパターンは存在するが、正解があってないような世界だと思うので、勉強し続けることと良質な経験を重ねることが大事なのかなという所感です。

ゲームアプリのDBテーブル設計を実例にどのような設計にするべきなのかということを学べました。

スライド

共有はありませんでした。

メモ書き

自己紹介

  • 梶川 琢馬さん
  • サーバーサイドエンジニア3年目

DBテーブル設計の重要性

  • データの蓄積や検索を楽にする
  • データはシステムより長く残り続ける
  • 後から変更しづらい
    • 影響範囲が広いため
    • メンテナンスがしづらいため

DBテーブル設計の流れ

  • 論理（概念）設計：人間のための設計
    • ビジネス要件をデータモデルとして表現する
    • エンティティやリレーションの定義
    • 正規化
  • 物理設計：システムのための設計
    • セキュリティやパフォーマンスを考慮
    • 水平/垂直分割、Master/Slave構成
    • 正規化を崩す
    • ミドルウェアを変更する

オンラインゲーム

  • ユーザ数が多い
  • リリース後に継続して改修

データの分類

  • マスタ
    • 一度登録すると頻繁に更新されないデータ
  • トランザクション
    • 頻繁に更新されるデータ
  • サマリ
    • 集計結果を保存する。主に分析用。
  • キャッシュ
    • 頻繁に参照されるデータの置き場所。
  • ログ

テクニック

  • 1対1テーブル
  • クラス継承
    • 単一デーブル継承（STI）
    • テーブル構造を変更しやすい
    • SQL原則から外れる
    • クラステーブル継承（CTI）
    • 後からテーブル構造を変更しにくい
    • SQL原則にのっとった方法
    • 具象クラス継承（CCI）
    • 全体から検索しにくい

qiita.com

  • ビジネス要件を把握する
  • チームメンバーと議論する
    • 既存のテーブル設計について
    • コードレビューよりも早めにテーブル設計レビューを依頼する

データ特性に応じたミドルウェア選択

おすすめ書籍

SQLアンチパターン

SQLアンチパターン

  • 現場で役立つシステム設計の原則

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

SRE がよく利用するソフトウェアの理解と分類講座に参加しました

SRE 勉強会

感想

supporterzcolab.com

サポータズCoLabの「SRE がよく利用するソフトウェアの理解と分類講座」に参加しました。

SREエンジニアとして働くためには並大抵ならぬ努力がいることを感じざるを得ませんでした。

一方で、SREエンジニアとしての働き方にかなり興味を持ったのも確かです。

「自動化」 ・「制御してやったという達成感」

SREエンジニアとしてのモチベーションを尋ねたときの回答です。

それを聞いたとき、はじめて自分が書いたCIのymlが期待通りの挙動をしてくれたときに幸福感を感じたことを思い出しました。

コードをゴリゴリ書くことが1番の楽しみでしたが、なるほどそういう働き方もあるなという気づきをいただきました。

「一番困っていることから手をつけるのが良い」

オススメの勉強方法です。まずは課題を見つけるところから少しずついらいろな技術に精通していけたらと思います。

裏の勉強会がかなり盛り上がっていたようですがこちらの勉強会に参加してよかったです。

帰宅後、それぞれのサービスをググって概要だけでも眺めてみましたがかなり全体像がつかめた気がします。

今回紹介していただいたサービスだけでも

な、なな、なんと

43個

ありました。（驚）

全てに精通する必要はないですが、どういったツールなのか、どういう違いがあるのかくらいは理解しておきたいですね。

speakerdeck.com

以下、メモ書きです。

メモ書き

自己紹介

  • 北野勝久さん
  • スタディストSREチームリーダー

困っていたこと

  • コード管理されておらずブラックボックス化したインフラ
  • 障害が発生してもモニタリング・管理が貧弱で状況がすぐに掴めない
  • 何からやったらいいかわからないし周辺技術もたくさんある

ひらすら勉強

  • 効率最悪
  • 時間の無駄

これを知ってれば

  • SREの全体像をみれていれば...
  • 闇雲に走る必要はなかった

SRE?

  • Google発
  • システム管理者, DevOpsとは何が違うのか
  • ソフトウェアエンジニアが、システム運用をしたらどうなるか？という観点で再定義されたシステム管理者の役割
  • class SRE inplements DevOps
    • それ以外の役割も担う
    • それ以外の役割は各社で異なり厳密な定義はない

youtu.be

話す範囲

  • 話さないこと
    • ベーススキルセット
  • 話すこと
    • SREの責務範囲の枠組み
    • ツール（AWSメイン）

Infrastructure as Code

Monitoring

Log

  • ログの転送ツール（フィルタリングや加工も可能）

ChatOps

  • Slackなどのチャットツールからコマンドなどを入力することで何かしらの作業を行う

CI/CD

Development Environment

Infrastructure Automation

  • イベント駆動アーキテクチャでインフラ操作自動化することを意図して記載
  • 「○○が起きたら、XXXが起動し、△△する」というXXXの部分

Security

Data

Incident Management

まとめ

  • 全体像を把握し、それぞれのツールの役割を理解するのが良い

QA

  • オススメの勉強方法や書籍
    • SRE book for FREE in English
      • Googleと自分たちの違いを理解する
      • 分散処理が世界で最も強い会社
      • 自分の会社とGoogleとの差分だけ認識して学習する
      • 書いてあることを全て実現するのは無理だし意味がない

www.publickey1.jp