AWS Summit Tokyo 3日目に参加してきました

こんにちは、たじりん（@ayaka_pespes）です。

AWS Summit Tokyo 2019の3日目に参加してきました。 そのレポートになります。

基調講演

AWSのサービスをテーマごとに紹介していました。
中でも印象に残っているのは機械学習の事例として紹介されていた、SyntheticGestalt社の事例です。
機械学習を用いて人間の代わりにロボットに実験をさせ、創薬に繋げるということをしているそうです。
その機械学習の部分でAWSを用いているとのことでした。
現状、創薬にはコストがかかってしまい、社会保障費を圧迫しているという問題があり、それの解決手段として機械学習を使用されていました。
すごく未来的な話のように感じましたが、根本には課題や問題があり、それの解決手段として機械学習を使っていました。
ついつい、技術にばかり目が行ってしまいますが、技術は手段であることを忘れないでおきたいです。

Amazon DynamoDB Deep Dive

DynamoDBの機能の説明とNoSQLのデータモデリングの話です。

データモデリングについては下記がセッション内で紹介されていました。 aws.amazon.com

【イチから理解するサーバーレスアプリ開発】 サーバーレスアプリケーション向きの DB 設計ベストプラクティス from Amazon Web Services Japan

www.slideshare.net

DynamoDBのテーブルを設計する場合もER図までは作成することが大事だそうです。

Alexaのスキルを作成するときにDynamoDBを使っていましたが、データモデリングを考えずにDynamoDBを触っていたので、今後は紹介されていたスライドを見ながら、より適切にDynamoDBを使っていこうと思います。

サーバーレスアプリケーションのためのセキュリティアーキテクチャ

サーバーレスでセキュアに構築する方法の話でした。
AWS Well-Architected Frameworkに「Serverless Applications Lens」というドキュメントが公開されており、そこにセキュアなアーキテクチャについても載っています。

以下のような質問をあげ、それに回答していく形で、セキュアなアーキテクチャを紹介していました。

1. APIアクセス制限をどのようにしていますか？
2. lambdaファンクションがアクセスできるAWSサービスをどのように保護していますか？
3. ログをどのように分析していますか？
4. 依存関係や脆弱性をどのように監視していますか？
5. lambdaファンクションがアクセスできるVPC内のAWSリソースに対してどのように保護していますか？
6. サーバーレスアプリケーション内の機微な情報をどうしていますか？
7. どのように入力値をチェックしていますか？

それぞれ、以下の方法が紹介されていました。

• 1、2 Cognito、IAM、lambdaAuthorizer
• 3、4 Cloud Watch Logs、X-Ray
• 5 WAF、Security Group
• 6、7 System Manager Parameter Store、Secret Manager

侵入テストでCloudFront、lambdaも申請不要になったというお話もありました。

サーバーレスで作るときもセキュリティを意識して作りたいなと身を引き締めました。 英語ではありますが、サーバーレスなAWSのサービスを使うときは、AWS Well-Architected Frameworkを読みながら使おうと思います。

めざせ！サーバーレスプロフェッショナル

サーバレスで開発をする際の具体的な話でした。

複数環境にデプロイする方法がとても参考になりました。 alexaのスキルを公開していますが、特に開発用環境や評価用環境、本番用環境を分けずに作成してしまっており、今後変更を加えるときにどうしようか考えていました。 SAMで環境変数を用いて複数環境にデプロイできるそうなので、試してみたいと思います。

他にもアーキテクチャのデザインパターンの話をしていましたが、時間がなくなりあまり詳しく聞けなかったです。 後日スライドを公開するとのことなので、公開を楽しみにしておこうと思います。

AWS & Alexa Automotive : worldwide Automotive industry trends

車とalexaのお話でした。 アメリカではすでに車内で使うecho autoが発売されており、車内でalexaを使うということが進んでいます。 車で使うスキルもローンチされており、日本では日産がすでにスキルを公開しているそうです。

またamazon社のとったアンケートから次のようなことがわかったそうです。

• 家の中で使っているVUIエージェントと車の中で使うVUIエージェントは同一の方がいいと思っている人が76%
• 車の中で使いたいのはナビゲーション、MUSIC、Driver Warning

現在、alexaは100以上の機器に搭載され、世界で公開されているスキルは80000以上に登るそうです。 AVSを使ったデバイスが今後も増え、利用シーンが増えそうだと感じました。 今後は利用シーンも考えながらスキルを作ったりすると、便利で快適な体験を増やせるのではないかと思っています。

3日目まとめ

技術的なことを多くインプットした1日でした。 私個人としてはサーバーレスをalexaのスキルを作る際に使用しており、すぐにスキルの開発で使えそうなインプットが多くありました。

AWS Summit Tokyo 2日目に参加してきました

こんにちは、たじりん（@ayaka_pespes）です。

AWS Summit Tokyo 2019の2日目に参加してきました。 そのレポートになります。

Serverless/AppSync によるモバイル開発の今

AppSyncとは何か、どういうメリットがあるか、というような内容でした。 AppSyncはGraghQLのマネージドサービスで、セッションを通してGraghQL便利そうだなと思いました。

事例としてグノシーの方が登壇されていました。 以下のような内容を話されていました。

• グノシースポーツというサービスでAppSyncを使用している
• リアルタイム更新、スキーマファーストになる、複雑かつnestな構造のデータが取得が可能 といった理由から、AppSyncを選択
• リアルタイム更新
  • Dynamoに更新があるたびにリアルタイム通知する
• スキーマファースト
  • GraghQLは先にスキーマを定義し、それに合わせてサーバサイドを実装するため、スキーマファーストとならざるを得ない
• REST APIだとAPI仕様書が必要だが、API仕様書を記載するコストが高い
• REST APIだとUIを変更するたびにAPIも修正する必要があったが、GraghQLではそういったことがない
• バックエンドはUIがデータにアクセスする方法を提供
• Tips
  • GSI(Dynamo)だけでなく、ElasticSearchも使うと良い
  • lambdaをdatasourceにするときは慎重に(ホットスタート/コールドスタートの問題など)
  • 最適な環境をシュッと作れる

私自身RESTで実装していた時に、API仕様書の記述が面倒・ちょっとした画面の変更でもAPIを直さなければならないことは面倒に感じていました。 GraghQLを使うと、そういった問題が解決できそうです。 今後APIを作成するときはGraghQLも候補に入れて行きたいと思いました。

最後にライブでデモをしていました。 いくつかのコマンドを実行し、少しコードを修正して、簡単にwebサイトが動いていました。

CEO ジム・ローズ来日：CI/CDが変革する開発現場・ビジネスとしてのCircleCIの未来

CircleCIは日本に注力をしているそうです。 日本APAC拡大へのHUBにするといった考えもあり、日本での採用を増やしているそうです。

CD(Continuous Deployment)の話をその後話していていました。 結局本番環境にリリースしてみないとわからないという話でした。 切り戻しが容易にできる、修正がすぐにリリースできれば本番環境にリリースし、問題があればすぐに切り戻したり、修正してリリースすることができます。

開発環境と本番環境の差異やリリース後に仕様が違うと言われることはあると思います。 本番にリリースした後、大丈夫かなとよく不安になります。 しかし、修正してすぐにリリースができれば、リリースのハードルが下がります。 CI/CDちゃんとやりたいなと改めて思いました。

Amazon Alexa音声インターフェースへの新しい挑戦。スマートホームを実現するAWS IoT

スマートホームの話です。 しかし、スマートホームの話だけでなく、使われるスキルを作るヒントを得ることができました。

赤外線リモコンを発売されているラトックシステム様が事例として登場されていました。 以下のようなお話をされていました。

• AWS IoTを使った赤外線リモコンを発売している
• スマートホームAPI
  • APIがサポートするデバイスと機能のみ
  • 発話がプリセットされている
  • スキルの呼び出し名不要
  • アカウントリンク必要
• Alexaで赤外線リモコンを操作するとき
  • Echo → skill → lambda → AWS IoT Core → 赤外線リモコン
• スマホリモコンから赤外線リモコンを操作するとき
  • スマホアプリ → AWS IoT Core → 赤外線リモコン
• カスタムスキル
  • 発話を覚えられない
  • 発話が複雑になりがち
  • スキル名を言う必要がある
• スマートホームスキル
  • 発話がシンプル
  • 発話が統一されている

alexaに対応している赤外線リモコンが10万ユーザーに登り、大ヒット商品となったそうです。 また、作成したスキルは作成したdeveloper以外の人にテストしてもらうのが大事だそうです。 シンプルな発話は大事だと言われてはっとしました。 ついつい、なんでもできる方がいいと思いがちですが、使いやすいのはシンプルなものだったりします。 特に音声で操作するときは一度に提示できる情報が多くないので、いかにシンプルにするかは、かなり重要だなと思いました。

2日目まとめ

他にも2日目にはre:MIXというイベントがありました。 AWSウルトラクイズで上位3名はre:Inventにいけるという特典がありました。 クイズは初心者から上級者まで楽しめて、想像以上に楽しかったです。 セッションやイベントなど、内容が濃く新しい知識を得られた1日でした。

サイダス技術部に5月からジョインしました、たじりんです

初めまして、たじりん（@ayaka_pespes）です。 5月からサイダスにジョインしました。 ちょうど1ヶ月が経ったので、入社エントリーを書きます。

入社までの経緯

2019/2/23にJAWS DAYSに参加したことがきっかけでした。 以前にもサイダスの方がイベントで登壇されているのを拝見して興味を持っていました。

JAWS DAYSの二次会で酔っ払って騒いで転職したいという話をしていたところ、CTOの吉田さんから、サイダスを受けてみないかというお話をしていただきました。 それがきっかけになり、wantedlyから応募をして、ジョインさせていただくことになりました。

入社してよかったこと

• 1on1やOKRを積極的に行っている
  定期的にCTOとの1on1があります。 1on1を通して、自身のキャリアや今後の目標を改めて考えることができました。 1on1ではOKRの話もします。目標を設定し、共有します。 やはり目標がある方が具体的なアクションをしやすくなると思いました。

• コミュニティ活動をやりやすい
  サイダスはコミュニティや勉強会などへの参加を推奨しています。 特に登壇は機会があるなら、積極的に登壇することを良しとしています。 私以外にもイベントを開催したり、社外で登壇するような人が多数おり、気持ち的にとても動きやすくなりました。 また、イベントをやる、登壇するという時に応援してもらえるので、前よりも積極的に動けるようになりました。

• モブワークでコミュニケーションを取りやすい
  私は今チームで開発を行っており、常にzoomをつないだ状態で仕事をしています。 雑談も交えながら、すぐに質問ができ、とてもコミュニケーションを取りやすいです。 まだ、入社して1ヶ月ですが、社内でもくもく会したいと言った時にも参加してくれる人がたくさんいました。 よかったら一緒に勉強しましょうと言いやすい雰囲気だったからこそ、もくもく会もできたと思っています。

• 会社がおしゃれ
  沖縄本社はとても綺麗です。カフェみたいです。 今はマンスリーマンションに住んでいるのですが、マンスリーよりも会社が好きで、土日も会社にいることが増えました。

入社後のギャップ

• 日本人以外の方も結構いる
  良いギャップです。 入社前は日本人ばかりかと思っていましたが、日本人以外の人も複数名います。 またこの後も何名か外国の方が増えるようです。 基本は日本語でコミュニケーションをとりますが、私も英語喋れた方がいいと思うようになりました。 基本的にどの国の方でも日本語は厳しいけど、英語はOKという方が多いので、私が英語を喋れることで、コミュニケーションがもっと円滑に取れるのではないかと考えています。

• 技術部以外の方との交流が少ない
  技術部以外の方はフロアが分かれているため、あまり交流がありません。 一ヶ月に一回納会と言う名の飲み会があり、そこでは交流の機会があります。 しかし、人見知りを発揮してしまい、あまり交流ができなかったので、後悔しています。

そんな感じで1ヶ月が過ぎました。 もっとインプットとアウトプットを増やしていきたいと思っています。 本を読む、勉強会に行くと言ったようなインプットを増やし、ブログや登壇等でアウトプットしたいと思っています。
とても居心地よく感じているので、会社に対してもっと貢献できることを増やしたいです。 またこの技術ブログにも今後登場すると思うので、よろしくお願いします！

Introduction to installable feature of PWA

This article will introduce PWA installable feature which makes web app looks like a native app.

What is a Progressive Web Apps

PWAs are web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features

There are some key principles a web app should try to observe to be identified as a PWA. It should be:

• Discoverable: so the contents can be found through search engines.
• Installable: so it's available on the device's home screen
• Linkable: so you can share it by simply sending a URL
• Network independent: so it works offline or with a poor network connection
• Progressive: so it's still usable on a basic level on old browsers, but fully-functional on the latest ones.
• Re-engageable: so it's able to send notifications whenever there's new content available
• Responsive, so it's usable on any device with a screen and a browser -- mobile phones, tablets, laptops, TVs, fridges, etc
• Safe: so the connection between you an the app is secured against any third parties trying to get access to your sensitive data.

In this article, We just focus on the Installable feature.

Install a PWA web app

The demo web app is here: https://tsq-demo-app.github.io/coinmarket . It's a SPA and built with Vue.js.

We will use Chrome on Mac, Windows, Android and use Safari on iPhone.

Installation on Mac

Installation on Windows

Installation on iPhone

Installation on android

How make a website installable

To make the website installable, it needs the following things in place:

• A web manifest, with the correct fields filled in
• The website to be served from a secure(HTTPS) domain
• An icon to represent the app on the device

The key element is a web manifest file, which lists all the information about the website in a JSON.

We can create a file named manifest.json. It should be included in the <head> section of the index.html file via the following line of code:

<link rel="manifest" href="manifest.json">

The content of the file looks like this:

{
  "name": "COINMARKET",
  "short_name": "COINMARKET",
  "description": "An App that displays the mark cap rankings, price, details and more for the top 100 larget crytocurrencies based on overall market cap.",
  "icons": [
    {
      "src": "./img/icons/android-chrome-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "./img/icons/android-chrome-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "start_url": "./index.html",
  "display": "standalone",
  "background_color": "#fff",
  "theme_color": "#00d1b2"
}

let's break down the document and explain them in detail:

• name: The full name of your webapp
• short_name: Short name to be shown on the home screen
• description: A sentence or two explaining what your app does
• icons: A bunch of icon information, source URLs, sizes and types. Be sure to include at least a few, so that one that files best will be chosen for the user's device.
• start_url: The index document to launch when starting the app
• display: How the app is displayed: can be fullscreen, shandalone, minimal-ui, or browser
• background_color: A color for background, used during install and on the splash screen
• theme_color: A primary color for the UI, used by operating system

The bare minimum requirement for a web manifest is name and at least one icon (with src, size and type). The description, short_name and start_url and recommended.

Summary

Installable is a very cool feature which makes your website look like a native app. Even though, it's not supportted by all browsers now, I think it will become more and more popular in the future.

If you want to learn more about PWA, the MDN web docs is a good place.

VuexとAtomic Design

大阪からこんにちは、福山健（@kenfdev）です。

フロントエンドに関わっているエンジニアであればAtomic Designというのを聞いたことがあるかもしれません。

フロントエンドの開発をしていく上で大事なことの一つに、画面の部品をどのようにComponentに分割していくかというものがあります。

きっとたくさんのフロントエンドエンジニアがこの点については毎回悩まれると思います。

そこで、どのように分割していくと良いかという指標の一つとしてAtomic Designという考え方があると僕は解釈しています。

Atomic DesignはBrad Frostさんという方が提唱したもので、英語であれば下記にて公開されていますし、本を注文することもできます。

atomicdesign.bradfrost.com

また、日本では下の書籍がReactを使って具体的にわかりやすく説明されています。（ただし、SPAフレームワークを触ったことが無いとちょっとつらいかも）

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

この記事ではAtomic Designについては詳しく見ないので、そもそもAtomic Designについて知りたい方は上の書籍や、わかりやすいブログ記事も多数あるのでそれらを先に読むことをおすすめします！

ではこの記事で何を述べるかと言うと、Vue.jsのVuexを使ったプロジェクトでAtomic Designを採用した場合に、VuexのStoreとAtomic DesignのComponentがどのようにやり取りすると良いかを紹介します。

あくまでこのやり方は1例に過ぎず、やり方は多数ありますので迷っている方の参考になればと思います！（CYDASでもやり方は日々アップデートしています！）

Atomic DesignとVuexで何に迷うのか

これは「Atomic Designだから」、という問題では無いのですが「誰がVuexを意識するのか？」という課題が常につきまとってきます。

具体的には：

• 誰がVuex StoreからStateを受け取ることができるのか
• 誰がVuex StoreにActionをdispatchしていいのか

という2点がポイントになってきます。ここに一定のルールを設けないと、そこら中からStateを受け取ったり、そこら中からActionをdispatchしたりしてどこで何が起きているのかかなり追いづらくなってしまいます。

イメージとしては下図のような状況です。

フローが追いにくい関係

「Pages, Templates, OrganismsはPropsを受け取ることもあれば、Storeからstateを受け取ることもあり、eventを$emitすることもあればStoreにdispatchすることもある。」のがわかります。

これでは流れが追いにくかったり、実装するときも迷いが生じやすくなります。

Atomic DesignとVuexの良い関係

そこで、僕が今のところ良いと思っているAtomic DesignとVuexの関係は下図のようになります。

追いやすくしたフロー

言語化すると、

• Storeからstateを受け取るのはPagesのみ
• Pages以外はPropsでしか入力を受け付けない
• Storeにdispatchして良いのはPagesとTemplatesのみ
• Pages, Templates以外はdispatchしてはいけない（イベントは$emitするのみ）

というルールになります。

StoreはPagesのみが意識すべきでは？

ここで出てきそうなのが「StoreはPagesのみが意識すべき」という意見です。

ルールとしてはわかりやすいんですけど、実際にやってみるとTemplates→Pagesにeventを$emitして、PagesからStoreにdispatchするのが冗長に思いました。

Templates→Pagesのコピペ感がつらい

Templates→Pagesへの$emitが増えるほどPagesでもイベントハンドラが増えてしまうのです。。。（やり方はいくつかあるにせよ冗長さは避けられないと思います）

そういうわけでCYDASでは「dispatchに関してはTemplatesからやってもいいのでは？」という意見もあってTemplatesまではStoreを意識して良いルールにしています。

Pagesはいつdispatchする？

Templatesがdispatchするなら、むしろPagesはいつdispatchするのか？という疑問も出てくると思います。

基本的にOrganismsより下の層から$emitされたイベントについてはTemplatesからStoreにdispatchします。

なので、Pagesがdispatchするタイミングはmountedなどの、ページ初期化時などのタイミングくらいしか無いのかなと思っています。

TemplatesにPropsは必要なのか？

Templatesからdispatchができるなら、いっそのことstateもStoreから持ってこればいいのでは？という疑問も出てきます。

それをやってしまうともはやPagesが必要なくなると思うのですが、あくまでデータはProps経由でもらうというルールにしています。

というのも、Atomic Design（にこれも限らずですが）とStorybookを組み合わせて使うことも多いかと思います。

storybook.js.org

このStorybook上でTemplatesを表現する際に、Propsで制御できたほうがVuexのセットアップ（gettersだったりstateだったり）が必要なくなります。

標準のVue.jsで、Propsにデータを差し込むだけでいろいろなデータを流し込めるので、変に手間のかかることをせずに済むと思っています。

そういったわけで、TemplatesはPropsでデータを受け取るようにしています。

まとめ

この記事で述べているやり方はあくまで1例にすぎません！大事なのは皆が好き勝手違う書き方をしてしまわないようにルール（コーディング規約）をある程度決めておくことだと思います。

そしてやってみて、フィットしなかったらもっと良いと思う方法に変えていけば良いんだと思います（手戻りは発生してしまうのは覚悟の上で）！

参考

UI 開発をアジャイルに行うための Atomic Design from Yusuke Goto

【開催報告】AliEeates Okinawa Meetup #1

こんにちは。エンジニアのしのっちです。 遅くなってしまいましたが、4/24 に開催しました AliEeates Okinawa Meetup #1 の報告です。

Connpass のページ
alieaters-okinawa.connpass.com

石川さんによる Twitter まとめ
togetter.com

Alibaba Cloud概要と海外最新動向紹介

Alibaba Cloud の強みである BigData 基盤の活用事例を中心に紹介いただきました。FlyZoo Hotel は未来体験が詰まっていて、すぐにでも用事を見つけて出張申請したい雰囲気でした！

AlibabaCloud基本プロダクトと最新プロダクト紹介

売れる EC サイトが自動生成されてしまうとか驚きでした。 新しいサービスがリリースされていく順番 (中国 → International → 日本) など、興味深いお話が聞けました。

真吾吉田のMVPな話

これから盛り上がっていく企業の話とか、そんな中で自分たちが何をやっていかなければいけないかというお話でした。

サイダスエンジニアによる LT 三連発

LT①：Alibaba CloudでServerlessに入門しました

yudy1152.hatenablog.com

「日本語のドキュメントがわかりやすい」というのが印象的でした。

LT②：RAMユーザのパスワード誤入力をSlackに通知させてみた

blog.pirox.dev

実現までに困難が多く、なかなか大変だったようです。

LT③：Alibaba Cloud Container Service で自作キーボードのファームウェアをビルドしてみた

Alibaba Cloud Container Service で自作キーボードのファームウェアをビルドしてみた from semnil

www.slideshare.net

最後は私の LT ですが、完全に趣味全開で自作キーボードを熱く語っただけの内容でした。 当日は時間の都合で泣く泣く割愛した動画もここにこっそり貼っておきます。
Helix キーボードキットを製作している様子 (60 倍速) - YouTube

最後に

Alibaba Cloud は全体的に AWS に似ているところが多いので、経験者なら入門は簡単です。 登録すると無料のクーポンがもらえるので、結構遊べると思います。 今回の LT はサイダスのエンジニア 3 人になってしまいましたが、皆さんの積極的な参加をお待ちしています！

サイダスの技術部にジョインしました、湯です

はじめまして。エンジニアの、湯です！ 以下は社内でシェアしている私のトリセツです。

どんな問題に対するソリューションが得意か

フロントエンドとNodejs関連のこと。

そのソリューションについてどの程度エキスパートか？(経験者上位何％など)

経験者上位何%かは難しいところですが、前々職での実績値は上位 50％頃 です。

上司となる人に期待すること

• 性格がいい。
• 新しいことにチャレンジしていること。

同僚に対してあなたができる(できそうな)こと

私にできそうな事があれば、なんでも気軽にご相談ください。

同僚となる人に期待すること

チームで助け合う気持ちを持っていること。

ワークライフバランスについてどういう考えを持っているか

健康な生活、楽しい仕事。

リモートワークについてどういう考えを持っているか

今までリモートワークをやったことがないけど、やってみたい。

1年後どのような職業人でありたいか

• 日本語が上手になる、同僚とよく交流できる。
• 自分の得意技術は新入社員に教えたい。

3年後どのような職業人でありたいか

プロジェクトのリーダーになりたい。