「Android Dev Summit 2019 Extended Tokyo #gdgtokyo」に参加してきました

  • Android Dev Summit 2019 Extended Tokyo #gdgtokyoに参加してきました。

gdg-tokyo.connpass.com

  • 普段Anrdoidの開発をしているわけではありませんが、新しい機能を知ることができて便利な機能がたくさん登場してきていることを実感できました。
タイトル 発表者
【Session1】Conference Overview & Keynote Session mhidaka
【Session2】Android Studio 4.0 最新アップデート Daichi Furiya / Wasabeef
【Session3】かんたんべんりなMotionEditorの使い方講座 mochico
【Session4】What's new in CameraX Takasy
【Session5】Jetpack Composeの解説です! Yuki Anzai
【Session6】Jetpack Roomの最新情報が届きます! Yuichi Araki

【Session1】Conference Overview & Keynote Session

  • mhidakaさん

概要

  • 10/23-24
  • 700人
  • 60セッション

キーワード

  • Modern Development
    • 素早く簡単に
  • Modern distribution channel
    • PlayStoreの強化
  • Modern OS
    • OSのリリース戦略

Keynote

  • Androidはユーザと開発者をつなぐプラットフォーム

Modern Development

  • Innovation
    • 利用シーンの拡大
  • Updatability
    • 柔軟な機能アップデート
    • Android10からAPKだけでなくAPEXに対応
    • APKだとなかなかアップデートしてくれない
    • APEXだと動的に自動でアップデート(ユーザの同意が必要)
  • Secirity & Privacy
    • Popup Block
  • Developer Experience
    • PlayStoreのTop1000のうち60%がKotlin
    • 開発者の53%がKotlinを使用(母数は何?)

Modern OS

  • Android11からα,βといった提供になる
    • 今まではstable1,2,finalみたいな感じだった
  • targetSDKは1つ前までしか認めなくなる
    • どんどん上げていかないといけなくなる

【Session2】Android Studio 4.0 最新アップデート

  • Daichi Furiyaさん

Desugaring in D8 & R8

  • 新たにいろいろなパッケージ、クラスがサポートされた

Multi Preview

  • さまざまな解像度のデバイスでプレビューできる
  • 各国の言語設定でもプレビューできる

Build Speed

  • ビルドのどこにどれくらい時間かかってるか可視化できるようになった

Google Maps Emulator Integration

  • Google Mapsのナビゲーションをシミュレートできるようになたt

Proguard Editing

  • コード補完の精度向上
    • クラス名とかきかなかったけど補完されるようになった

Live Layout Inspector

  • エミュレータで動作しているものを3Dで要素の階層とか見られる
    • 要素をクリックするとプロパティが表示されたり
  • Experimentalなので設定をonにしないと使えない

Emulator embedded inside the IDE

【Session3】かんたんべんりなMotionEditorの使い方講座

  • mochicoさん

Motion Editor

  • Motion Layoutを使ってアニメーション
  • Motion Layout
    • ConstraintLaayoutのサブクラス
    • motionをXMLで定義できる

Modern Editorの使い方

  • 要件
    • Android Studio4.0+
    • ConstraintLaayout2.0.0beta3+
  • エディター上でアニメーションのstartとendを設定できる
    • 動かすとアニメーションしてくれる
  • keyframesでもっといろいろ設定できる

【Session4】What's new in CameraX

  • Takasyさん

Camera2 API

  • 高度な機能の実装ができる
  • でも細かなことができるせいで使いづらい
  • 様々なデバイスで動くものを作るのが大変

CameraX 3

  • Camera2をラップしたもの
  • 新機能を追加するときデバイス固有のものを使わないようにしてる
  • 2億台のactiveなデバイスでテストしてるから様々な機種で動く

CameraXのユースケース

  • プレビュー
  • 画像解析
  • 画像キャプチャ
  • CameraViewが簡単に使えて便利

新しいAPI

  • Tap to focus
  • Pinch to zoom
  • Zoom Slider

【Session5】Jetpack Composeの解説です!

Jetpack Compose

  • AndroidのUIを作るためのモダンなツールキット
  • 既存のコードと混ぜて使える(予定)

Jetpack Composeはやりたいこと

  • シンプルにしたい
    • UIを作るのにたくさんコード書かないといけない場面がある
    • フレームワークからはさわれるけど3rdパーティからはさわれないとかいう場面がある
    • Material + AnimationなUIを作りたい
  • Single Source of Truethにしたい
    • CheckBoxの状態とModekの状態どっちが正しいの?ってなっている
  • ReactiveなUIにしたい
    • Modelで状態を管理し変更されたら再描画
  • UIパーツの再利用性高めたい
    • 従来はカスタムViewあるけど作るの大変
    • 小さなcomponentを組み合わせてUIを作っていく

Jetpack Composeの今後

  • まだ開発中
    • 本番で使うな危険
  • 来年betaが出る(来年のいつだかは不明)

【Session6】Jetpack Roomの最新情報が届きます!

  • Yuichi Arakiさん

Jetpack Room

  • N対Nにも対応するようになった
  • デフォルト値設定できるようになった
  • Incremental Build
    • Buildがはやくなる
  • Expand Projection
    • select文の結果で一部のカラムしか必要ない時に対応できるようになった
    • 空気を呼んで全カラム返さなくなる

「LINE API × Tech API Vol. 1 Powered by AWS」に参加してきました

  • LINE API × Tech API Vol. 1 Powered by AWSに参加してきました。

linedev.connpass.com

後半のハンズオンではLINE botを作成してバックエンドにAWSを使いました。 コピペ部分も多かったですが、初めてCloud9を使ったりLINE botを作ったりいい経験になりました。

タイトル 発表者
What and Why AWS Serverless Satoshi Suzuki
サーバーレスだからこそフロント実装もカジュアルに!LINE APIでAWS上でアプリを作ろう! 比企 宏之
LINE APIとAWSを使ったハンズオン Satoshi Suzuki

What and Why AWS Serverless

  • Satoshi Suzukiさん(AWS)

トレンドのワード

  • microservices/serverless
  • それぞれ2014年くらいから伸びている

サーバーレスとは

現場のニーズ

  • Business Personの気持ち
    • 早くリリースしたい
    • 新機能ほしい
    • スタートアップ時にインフラコスト抑えたい
  • Developerの気持ち
    • インフラ管理したくない
    • ビジネススケールしたときにサービススケールさせるの大変
  • ビジネスロジックに集中したい
    • => サーバーレス

サーバーレスの特徴

  • インフラのプロビジョニング管理が不要
    • マシンの事前調達不要
  • 自動でスケール
  • 価値に対する支払い
    • 実行した分だけ払う課金体系
  • 高可用かつ安全
    • メンテナンスや定期的なダウンタイムはない

AWSのサービス

  • 処理
    • Lambda
  • 外部I/F
  • 認証
    • Cognito
  • ストリーム
  • データ保持管理
    • DynamoDB
    • RDS
    • Aurora
    • SQS
    • S3

Amazon API Gateway

  • インターフェースの抽象化
  • HTTPのエンドポイントを作れる
  • リクエストを受け付けてどこにパスするか設定できる
  • 作成可能なAPIの種類
    • REST
    • WebSocket
  • メトリクスも確認できる

AWS Lambda

  • リソース管理
  • リトライ
  • ログ出力
    • Cloud Watch Logsに書き出してチェックできる
  • いろんなイベントをトリガーに実行できる
    • API呼び出し
    • データの変更
    • ファイルの配置
  • 処理対象
    • 自由に処理を書ける
    • DBアクセス
    • ファイル出力
  • 負荷に応じて柔軟にスケール

Amazon Simple Que Service

  • メッセージングキューをハンドリングするサービス
  • 標準キュー
    • 少なくとも1回は配信
  • FIFOキュー
    • 順序保証と1回限りの配信

Amazon Simple Storage Service

  • オブジェクトストレージ
  • 安価なストレージサービス

サーバーレスだからこそフロント実装もカジュアルに!LINE APIAWS上でアプリを作ろう!

  • 比企 宏之さん(LINE)

ITシステムの運用コスト

  • 運用と保守で75%

LINEのフレームワーク

  • LIFF(LINE Frontend Framework)
    • LINE内で動くWebアプリのプラットフォーム
    • HTML/JSで書ける
    • バックエンドAWSつないだりとかも自由にできる
    • LINEは8200万人のユーザがすでにインストールしてくれている

LINE Things

  • IoTアプリ

「FRONTEND CONFERENCE 2019」に参加してきました

  • FRONTEND CONFERENCE 2019に参加してきました。

2019.kfug.jp

タイムテーブル

11:00〜

タイトル 発表者
モダンJavaScript再入門 尾上 洋介
デザイン・設計の体幹とスキル 山下 一樹
PWAとCache API 田口 航

11:45〜

タイトル 発表者
ディレクトリ構成ベストプラクティス 〜 Angularアプリを作り続けてわかったこと okunokentaro
事例からみるアプリデザインの成長戦略とWeb Native Platform 榊原 昌彦
JavaScript も jQuery も未経験の新人エンジニアが 1 年間 Vue.js を学習して感じた話 川又由雅

13:00〜

タイトル 発表者
Adobe XDで作るマイクロインタラクション 松下 絵梨
UIデザイナが実装できる良さ コンチ
レガシーなフロントエンドをリプレイスする 小島大基

13:45〜

タイトル 発表者
2019年のUIパフォーマンス キリル ワシルツォフ
Nuxt.js + Firebaseでの開発と高速化に挑んだ話 カンボ@沖縄(鈴木孝之)

14:30〜

タイトル 発表者
AWSを活用したフロントエンド開発 前田 圭介
高齢者でも使えるプロダクトUIの挑戦 神保嘉秀

15:15〜

タイトル 発表者
私たちはなぜ SPA で開発するのか 花谷拓磨(@potato4d)
プロダクト開発とFigmaのより良い関係を求めて 大木尊紀
React Hooksで<video>を乗りこなす 浜田 真成

16:00〜

タイトル 発表者
フロントエンドエンジニアのためのセキュリティ対策 平野 昌士
Flutter For Webを用いて居酒屋で使えそうなゲームを作ってみた備忘録 大西 優司
Web 制作現場のディレクションを支える GitHub 後藤知宏

モダンJavaScript再入門

  • 尾上 洋介さん

なぜJS

  • 本格的なSPAが作れる
  • モダンなツールやフレームワークを学ぶのにJSの知識が必要なものが多い
  • ツールが移り変わっても通用する技術

基本的なオブジェクト

  • 数値/文字列/配列/オブジェクト

変数の宣言

  • const/let
    • 基本はconst
    • 再代入必要な時だけlet
    • varは使わない

アロー関数

  • 関数は第一級オブジェクト
    • 変数に入れたり関数へ渡したりできる

非同期処理

  • asyncをつけた関数内ではawaitが使える
  • awaitつけるとPromiseが解決されるまで待ってくれる

レガシーなフロントエンドをリプレイスする

  • 小島大基さん

レガシーとは

  • 古い
  • 代替すべき新しいシステムがある
  • フロントエンドにおいて
    • 新しい技術がすぐに入ってくる

アーキテクチャ

  • UIとロジックのディレクトリ(ファイル)を分ける
    • UIライブラリが変わっても使い回せる状態に
  • コンポーネントはなるべくステートレスに

テスト

苦労したところ

  • ライブラリのバージョン上げたらテストが通らなくなった
    • BootstrapVue 1.5 -> 2
  • class style apiが非推奨になってしまった

Nuxt.js + Firebaseでの開発と高速化に挑んだ話

  • カンボ@沖縄(鈴木孝之)さん

なぜFirebase

  • RDSも使ってる
    • FirebaseはChatの部分だけ
  • 使っているサービス
    • Firebase Authentication
    • Cloud Firestore
    • CloudFunction

チャット機能をFirebaseで

  • 候補
    • WebSocket
    • ロングポーリング
    • Firebase
      • Firebaseに決定
      • 導入コスト低くてメンテコストも低い
      • 採用のウリになりそう
  • 導入前の懸念
    • DBの無料枠1GB
    • 検索条件に制限

Firebase導入してどうだったか

  • Firestoreの構成
    • usersコレクション
    • roomsコレクション
    • usersのサブコレクションにrooms
      • 深い層への検索がやりづらそうだったから
  • CloudFunctionの初期起動遅い
    • 一定時間アクセスがないとスリープモードになる

ビルド高速化

  • Webpack Bundle Analyzer
    • webpackの処理で遅いloaderやpluginが分かる
    • bundleしたファイルがどのライブラリがどれくらい占めてるか分かる
  • バンドルサイズ
    • Chart.jsが重い
    • memoment.jsが重い
      • 不要なlocaleも入ってて重い
    • lodashが重い
      • ほとんど使ってないから消そうとした
      • 関数単位でimportするやり方があったからそれにした

AWSを活用したフロントエンド開発

  • 前田 圭介さん

AWS

  • 使ってるサービス
    • S3
      • ストレージ
    • Cognito
      • 認証サービス
  • 今後よさそう
    • AppSync
      • GraphQLでやりとりする
      • リアルタイムデータアクセス
      • オフラインのデータ同期

導入編

  • AWS Amplify
  • amplify initで雛形生成できる
    • Auth.signin()でCognito Signin
    • GraphQLのqueryを生成したりもできる
  • amplify pushでデプロイできる

まとめ

  • Amplifyで簡単に認証からAPI作成・実行Storage利用ができる

私たちはなぜ SPA で開発するのか

  • 花谷拓磨(@potato4d)さん

なぜSPAを選定するのか

  • User Experiences(UX)
    • 要件を満たすための選ぶ場面
  • Developer Experiences(DX)
    • 開発効率を上げて生産性を上げる
    • エンジニアを確保するために新しい技術を使う

UX要件の強い事例

  • InstagramがPWA/SPAで提供している
    • 新興国での利用など考慮してWebで提供
    • twitterも同じようなことしてる
  • ページ遷移にアニメーションをつけたりリッチにしたいけど各ページでURLは持ちたい

DX要件の強い事例

  • コーポレートサイトをSPAで作成
    • コンテンツのアップデートを簡単にやりたいからSPAを選択

SPAの技術をどこまで使うか

  • SPAに付随してくる技術はすべて必要?
    • たとえばReduxとか
  • 要件ごとに検討していく必要がある
    • 常にバランスが大事

間違った技術選定

フロントエンドエンジニアのためのセキュリティ対策

  • 平野 昌士さん

Webのセキュリティ動向

  • IPAが出している脆弱性届出受付数
    • Webがソフトウェアの倍以上
    • XSSが半分を占めている
  • 脆弱性の多くはWebサイトでXSSが多い

脆弱性(XSS)の仕組みと対策

XSS

被害例
XSSの種類
主な対策
  • 特殊文字エスケープ
    • & -> &amp;とか
  • 危険な文字列の削除
    • javascript:alert()とか入ってたら消すとか
    • 自前でやれなくもないけど大変
      • OSSなどを活用しましょう
      • 例えばReactはデフォルトでいろいろやってくれる
      • DOMPurify
  • ブラウザの機能を使う
    • Content Security Policy
      • HTTPレスポンスヘッダーに入れる
      • <meta>でも指定できる
    • Content-Security-Policy-Report-Only
      • レポートをとれるから本番適用前に確認すると良い
    • nonce
      • metaタグで設定したnonce値と同じ値が設定されたscriptタグしか実行できないようにする
      • nonceはリクエストの都度変える必要があり推測困難なランダムな値にする
    • Trusted Types
      • URLの文字列を安全な型に検証して扱う
      • まだexperimentalな機能
        • chromeはflag立てれば動く
        • Polyfillもある

セキュリティへの意識

  • 脆弱性とは悪用できるバグ by 徳丸先生
  • セキュリティに関しても
    • 要件定義でfixする
    • セキュリティテストする
  • どうやってチェックする?

「#webauthn_study」に参加してきました

  • webauthn_studyに参加してきました。

web-study.connpass.com

タイトル 発表者
WebAuthN を入れるには何を考えるべきか @ritou (mixi)
WebAuthN を実際に入れてみてどうだったか @kasecato (nulab)

WebAuthN を入れるには何を考えるべきか

  • @ritouさん(mixi)

リカバリーの話

  • 無効化/再設定
    • パスワード
    • TOTP
    • リカバリーコード
    • Auhtenticator
  • 別の認証方式or複数登録

パスワード認証におけるリカバリ

  • 忘れた
    • 別の認証方式 + 再設定

SMS通知におけるリカバリ

  • 番号/アドレスが変わった
    • 別の認証方式 + 無効化/再設定

FIDOにおけるリカバリ

  • 紛失盗難
    • 別の認証方式 or 複数登録可能にして無効化/再設定
  • FIDOだからといってそんなに問題ではない

導入事例

  • Google, GitHub
    • パスワード認証との組み合わせ
    • 2段階認証

2段階認証としての導入

導入時にどこに手を入れるか

  • アカウント設定
    • 追加認証を有効にする
    • リカバリー設定
      • 別の認証方式を登録
  • 認証
    • パスワード認証 + 追加認証を要求するように
    • 複数ある場合はどの方式か切り替えられるように
  • 再認証
    • GitHubではパスワード確認の場面でWebAuthnが利用可能に

検討事項

  • リカバリーの認証方式でカスタマーサポートの負担が決まる
  • 利用可能な環境の制限
    • user-agentによる判別
    • platform
    • Attestation
  • 追加認証要求のタイミング
    • パスワード認証に成功したら
    • パスワード認証の結果に関わらず
    • パスワード認証前に

パスワードレス認証としての導入

  • パスワードレスとは?
    • パスワードを使わない
      • 所持 or 生体 or 記憶
    • FIDO UV相当
      • 所持 + (記憶 or 生体)
  • 新規登録
    • リカバリーを考慮して効率的に2種類の認証方式を設定するには?

WebAuthN を実際に入れてみてどうだったか

  • @kasecatoさん(nulab)

WebAuthN導入前の話

WebAuthN導入のモチベーション

  • セキュリティキーや顔認証でログインしたい
  • 社内ハッカソンで作ってみた
  • しかし当時は仕様変更が続いていて不安
  • 今では2019/3にW3C仕様勧告

WebAuthN導入中

認証フローの設計

  • 2要素認証
    • 利便性の改善にはつながらない
  • 単要素パスワードレス認証
    • 多要素を強制したいフローで困る
  • 多要素パスワードレス認証 - 採用
    • 利便性と安全性を両立
  • ユーザネームレス認証
    • windows10以外で普及したと思えなかった
  • Email First Sign-in Flowを参考に実装

アカウントリカバリの設計

  • 盗難紛失
    • 従来のパスワード認証でログインし認証器の無効化
  • パスワードを削除したユーザ
    • リセットのEメールを送信

実装が困難だった点

  • macのtouchID複数登録の後勝ち問題
  • アカウント新規作成でパスワードレス

WebAuthN導入後

サポートへの問い合わせ

  • 指紋が変わって生体認証使えなくなったらどうすればいいか
    • PINで認証器解除して再登録をしてもらう

パスワード削除でモバイルから使えない

  • パスワード削除したらパスワードでログインしてるものを全部サインアウト
  • モバイルはFIDO対応してないからパスワード再発行しないといけない

Touch IDが使えなくなった

  • 公開鍵クレデンシャル登録時のChromeのProfileに紐づく

使用可能な認証器がわからない

  • いろんな認証器がある
  • これ使えますか?と問い合わせがくる

「ServerlessDays Tokyo 2019」に参加してきました

  • ServerlessDays Tokyo 2019に参加してきました。

tokyo.serverlessdays.io

  • 事例紹介のセッションではかなり踏み込んだ設計の話をしてくれることが多く参考になることが多かったです!
タイトル 発表者
10x Serverless Product Development for a Startup with Microsoft Azure Yutaka Tachibana(EBILAB)
Keynote Keisuke Nishitani (AWS)
Keynote: Infinite Scaling, Finite Failures: Serverless Resiliency Patterns and Lessons Learned Katy Shimizu (Microsoft)
グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例 Yuya Urayama (TOYOTA), Takanori Suzuki (Acroquest Technology) and Eiichiro Uchiumi (AWS)
All You Need Is JavaScript Jensen Hussey / Cloudflare
Zero Scale Abstraction in Knative Serving Tsubasa Nagasawa (CyberAgent)
空調設備向けIoTシステムにおけるクラウドランニングコスト 野原 健太 / ダイキン工業株式会社
ISPがサーバレスに手を出した 伊藤良哉 & 松田丈司 (NTTコミュニケーションズ)
AWS Lake Formation で実現、マイクロサービスのサーバーレスな分散トレーシング 藤武司 & 岩井良和 (Sony Corporation)
Don’t think Serverless Security, think Application Security Ido Neeman (Nuweba)
Azure でサーバーレス、 Infrastructure as Code どうしてますか? Kazumi Ohira
The hidden cost and technical debt of running huge Serverless service on production James Nguyen / MaaS Global

10x Serverless Product Development for a Startup with Microsoft Azure

  • Yutaka Tachibana(EBILAB)

スタートアップ × Microsoft Azure

EBILAB

開発しているもの

  • BIツール
    • どれくらいの人が来客するか予測
  • 画像解析
    • 入店客の人数や属性をカウント
    • 通行人数もカウント

Microsoft Azureのサーバーレスコンポーネント

  • Functionse
    • DBにデータを入れるところまで
    • LogicApp
  • PwoerBI
    • エクセルのデータをもとに表示することもできる
    • DBとかAPIから取得したJSON
  • WebApp
    • Nuxt
    • Laravelで認証
    • PwoerBIで作ったレポートをiframeで呼び出し

サーバーレスで作ったメリット

  • 開発運用コストが従来のモノリシックより少ない
  • 責務分離が自然と行われる
  • 将来的にスケールしても問題ないと楽観視できる
  • 不要になったパーツを捨てやすい
  • 分業協業しやすい

Keynote

  • Keisuke Nishitani (AWS)

Event Driven

  • LambdaはサーバーレスよりもEvent Drivenをキーワードにしたサービスだった
  • 状態の変化をイベントとして捉えて処理を実行する
  • Event Driven出ない場合処理が増えると呼び出し元にも手を入れないといけない
  • Event Drivenならサブスクライブを追加するだけ

Lambda

  • 2014年に発表
  • 当初はEvent Drivenや関数実行がキーワードだった
  • 2015年にAPI Gatewayが出てきてサーバーレスという言われ方をし始めた

Lambdaのネットワーキング

  • Lambdaの実行環境ははサービスチームのVPCで動いている
  • ユーザのVPCにElastic network interfaceを通じて接続できる
  • スケールするとサブネット内のIPアドレスを使っていく
  • ENIの作成に10~30秒時間がかかる

AWS Hyperplane

  • internal network load balancing service
  • 内部的に動いてるサービス
  • ユーザは使えない

VPC環境の改善

  • AWS HyperplaneをベースにしたVPC to VPC NATを使う
    • コールドスタートレイテンシの改善
    • ネットワークインターフェースの共有
    • スケーリング
  • LambdaからRDSへの接続
    • VPCのコールドスタート問題が解決する

モダンアプリケーション

  • 特徴
  • アプリケーション実行環境
    • EC2
    • ECS/EKS/Fargate
    • Lambda
  • マイクロサービス
    • サービスごとにデータを永続化するので疎結合
  • APIはマイクロサービスの玄関
  • メッセージングを活用してコードからステートを取り除く
  • クラウドネイティブなアーキテクチャ

Keynote: Infinite Scaling, Finite Failures: Serverless Resiliency Patterns and Lessons Learned

サーバーレス

  • サーバの抽象化
  • イベント駆動型
  • 従量制課金

すべての依存は障害になりうる

  • レースコンディション
  • ネットワーク障害
  • レート制限
  • ハードウェア障害
  • => 再試行のデザインパターン

グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例

  • Yuya Urayama (TOYOTA)
  • Takanori Suzuki (Acroquest Technology)
  • Eiichiro Uchiumi (AWS)

はじめての大規模アジャイル

トヨタのコネクティッドサービス

  • 車載デバイスがネットワークに繋がる
  • 車のヘルスチェックがスマホでわかる
  • 盗難の検知追跡エンジンの再始動停止

サーバーレス

  • 日中と夜でアクセス数の差が顕著
    • 通勤や業務で車に乗る人が多い
    • サーバーレスなら不必要にリソースを確保しなくていい
  • ライフサイクルが長い
    • 買い換えるまで7〜8年
  • コネクティッドカー国ごとにまだ法規制が違う
    • 国ごとにプラットフォームを確保
    • サーバーレスならシェアの大きい地域と小さい地域に合わたサイズにできる
  • データは蓄積せずにリアルタイムで流している

アーキテクチャ

指針

  • 十分にシンプルな粒度
  • ライフサイクルが異なるコンポーネントを自立
  • プロセスをステートレスに

アーキテクチャスタイル

  • Nティアー
    • 役割に応じていくつかの層に分割
    • Gateway
    • Logic
    • Data
  • ウェブキュー/イベントドリブン
  • マイクロサービス
    • ライフサイクルを共有できる単位のまとまり
  • 車載デバイスと地域サービスをつなぐプラットフォーム

AWSのサービス

開発の課題

クラウドで動かさないといけないのでテストしづらい

  • CI/CDでテスト実行環境整備
  • サービス単体テスト
    • LocalStack
    • プロキシで向き先無理やり変えてテストしてる
  • サービス間連携テスト
    • Karate

全体のトレーシングが難しい

  • ログはCloudWatchに
  • 想定以上にコストが高くなるから注意
  • X-Rayで分散トレーシング

自動スケール便利だが問題になるケースも

  • Lambda失敗して再試行するようにしてた
    • 再処理のLambdaが数千実行されてしまった
    • 同時実行数の上限はアカウント単位
    • 他のLambdaの起動を妨げる危険性
    • 変に上限までいかないように関数ごとに設定する

All You Need Is JavaScript

  • Jensen Hussey / Cloudflare

Cloudflare

  • 世界中にデータセンターがある
  • ユーザに近いデータセンターでJavaScriptを実行することができる

なぜJavaScript

  • 一番使われている言語だから
  • サーバーサイド
    • Node
  • モバイル
    • ReactNative
  • ネイティブ
    • Electron
  • サーバーレス
    • Cloudflare Workers

Cloudflare Workers

  • ServiceWorkerをベースに考えられたもの
  • v8で実行される
  • WebAssemblyにも対応している

Zero Scale Abstraction in Knative Serving

Knative

  • Build
    • 卒業してなくなった
    • Tektonになった
  • Serving
  • Eventing

Knative Serving

  • HTTPリクエスト駆動でスケールする
  • 素のk8sを使うとyamlをたくさん書かないといけない
    • Knative使うと簡単になる
  • Kanative Serviceを書いていく

事例

  • なぜKnative?
    • k8sを抽象化できるから
      • ネットワークのレイヤーも含めて抽象化
    • yaml地獄から脱却
    • ゼロスケールできること
      • パフォーマンス < 可用性 のサービス
    • Dual Stack
      • knativeとk8sのリソース併用
    • Portability
  • イベントを受けて処理をするところだけzero scalingを使う
  • Eventingはまだ未成熟だから採用見送り

空調設備向けIoTシステムにおけるクラウドランニングコスト

ダイキン工業とIoT

システム規模

  • 各機器から毎分データ発生
    • 膨大なアクセス
    • 高い処理性能とスケーラビリティ
    • 無限に発生するデータを扱えるストレージ
  • スモールスタート
    • 徐々に接続する機器を増やしていく
  • => サーバーレスでNoSQLで

サーバーレス開発

  • サーバーレス開発はクラウドランニングコストとの戦い
    • 目標のランニングコスト以内で動くシステムを作れるかどうか
    • IoTのように負荷が高いシステムだと従量課金でもコストは嵩む
    • サービスごとの課金体系を把握し設計する

システム構成

空調機 -> AWS

  • 変化のあった項目を毎分送るようにした

アプリ -> AWS

  • 一度のコールで同時に複数機器のデータを取得
  • 毎分データを取り出す

ランニングコスト

  • コストのかかる部分
    • Dynamoへの書き込みでのWCUコスト
    • データ取得時のLambdaの処理時間
  • DynamoDBのデータ構造が肝になる

DynamoDBのデータ構造

  • 数十kmの項目があると一部だけ更新する場合もWCUを消費してしまう
  • 運転データごとにアイテムをわける
    • 1機器Nアイテムとしてデータを持つ
  • Lambdaからアクセス時に機器数×N個分アクセスしないといけない
    • Partition Keyを建物IDとして建物ごとにまとめて取得できるようにした

まとめ

  • 今回の要件は書き込みは少しずつ、読み込みはまとめて
  • 要件にあった構成にすることでコストを削減できる
  • DynamoDBは書き込みのほうが読み込みより10倍課金額が高い

ISPがサーバレスに手を出した

ISP

  • Internet Service Privider
  • 家 - 回線 - ISP - インターネット

サーバーレスどこで使ってるか

  • 通信する前にルールを取得する必要がある
    • そのAPIをサーバーレスで作ってる

サーバーレス以外の選択肢

  • 選択肢
    • 物理サーバ
    • 自社IaaSサービス
    • 他社IaaSサービス
  • 納期3ヶ月
    • サーバーレスじゃなきゃ無理

社内基準と通信事業としての基準

  • 社内クラウドを使わない理由
    • IPv6対応してなかった
  • 信頼性の担保
  • 100万ユーザついているサービスが1時間止まると総務省に報告しないといけない

IPv6の受難

リリース後

テストの自動化

  • 全般
    • ローカルで軽量に行えること
    • デプロイして行うテストは最小限に

ローカルでテスト

  • Serverless Frameworkとプロアグ員を駆使
    • serverless-offline
    • serverless-dynamodb-local

負荷試験/長時間試験

  • Gatlingで叩いてる
    • レポートが見やすい
  • テストをやって・・・
    • DynamoDBのaute-scaling忘れに気がつくことができた

CIパイプライン

  • GitLab CI/CD
    • ローカルでしか動かないということがないように
    • dockerコンテナで実行することで環境が汚れない
    • commitとテスト結果をバインドすることで証跡を残せる
  • serverless-offlineのテストとかをCIで動かしてる

Infra as Code

  • Serverless Frameworkとにかく便利
    • ローカルでのテスト
    • 本番へのデプロイ
  • Azureは対応してるのが多くない
  • AWSもすべてをコード化できるわけではない
    • sls deployのあとにaws-cli使ってるところもある
  • 構成変更
    • 移行後の構成をsls deploy
    • 切り替えて古い方をsls remove

AWS Lake Formation で実現、マイクロサービスのサーバーレスな分散トレーシング

背景

  • aiboやMultifunctional Lightなどのバックエンドをサーバーレスで作ってる
  • マイクロサービス構成
  • 呼び出しチェーンが長い
  • 非同期も多い
  • クロスアカウントやオンプレとの連携も
  • 1ヶ月立ってから問い合わせや障害のトレースをすることがある

分散トレーシング

  • 分散アーキテクチャの処理の可視化や追跡性を向上させるための仕組み
    • どのサービスをどういう経路でたどったか
    • どこにどれくらい時間がかかったか
  • 共通のIDを受け渡していって経路を特定できるようにする

Lake Formation

  • 複数のAWSアカウントにまたがったログを集約分析できる
  • サーバーレスで実現できる
  • リアルタイムな分析はDataDogで長期的に残しておくのはLakeFormation

トレーシング基盤の構成

  • Step Functionsでログの出力
  • Lake Formationで各アカウントからログを集約

トレーシングIDの取得と伝播

  • X-Rayだけでは非同期イベントのトレースが困難
  • それぞれ工夫して対応した

Don’t think Serverless Security, think Application Security

  • Ido Neeman (Nuweba)

サーバーレスは新しい攻撃の窓口になりうる

  • イベント駆動アーキテクチャはサーバーレスに限った話ではない
  • むしろサーバーレスの方がセキュアな場面もある

サーバーレスはマネージしにくい

  • 小さい単位の関数にすることで管理しやすくなる

サーバーレスで過剰なアクセスがきたらどうするか

  • スケールするのが仇となって大量の課金につながる
  • 関数ごとに制限を設定しておく

サーバーレスの実行権限が広くなりすぎないか

  • IAMの権限を最小限にしぼっておくこと

Azure でサーバーレス、 Infrastructure as Code どうしてますか?

  • Kazumi Ohira

Infrastructure as Code

  • インフラのリソース構成/管理をコードで行うこと
  • メリット
    • 自動化できる
    • ミスが減る
    • レビューしやすい
    • バージョン管理できる

クラウドにおけるリソース管理

  • IaaS
    • Terraform
    • AWS Cloud formation
  • Container
  • Serverless

AzureでIaC

  • ARM templateを使う
    • 冪等性を管理してくれる
    • エラーハンドリングしてくれる
    • 差分デプロイ並列デプロイできる

The hidden cost and technical debt of running huge Serverless service on production

  • James Nguyen / MaaS Global

クラウドサービスを使うこと

  • クラウドベンダーに預けてるデータが壊れたら?
    • 最近もAWSの大規模障害があった
  • 技術的制約
    • Lambdaで最新のNodeが使えるようになるまで3ヶ月くらいかかる
    • 最新の情報を入手してアップデートし続けないといけない
      • 知らないところでAPIが廃止されてしまわないように
    • よりよいサービスに置き換わっていくこともある
      • 状況に合わせて移行していく必要がある
  • ベンダーロックイン
    • マルチベンダーは簡単ではない
    • Serverless Frameworkで抽象化はできる

「GitHub Actions Meetup Tokyo β」に参加してきました

  • GitHub Actions Meetup Tokyo βに参加してきました。

gaugt.connpass.com

タイトル 発表者
新GitHub Actions のはじめかた @miyajan
GitHub Actionsで WebDriverどこまでやるの? @hiroshitoda
GitHub Actions Parallel Testing @yasuhiroki
GitHub Actionsと(主にreviewdogを使った)Automated Code Review @haya14busa
他のCIサービスと比較してできることできないこと @Kesin
Github Actions でハマった点と解決方法 @kawasin73
自作Github actions入門 @Naturalclar

GitHub Actions のはじめかた

  • @miyajanさん

GitHubActionsをはじめるとき

既存のワークフローを探す時

アクションを作る時

既存のアクションを探す時

予想外の挙動で困った時

GitHub Actionsで WebDriverどこまでやるの?

  • @hiroshitodaさん

GitHubActionsが動く基盤

GitHubActionsで最初から使えるソフトウェア

Appiumの利用とNested Virtualizationの壁

  • Androidエミュレータを動かせるのはmacOSだけ
    • Linux/Windows環境がNestedVirtualizationに対応してないから
  • 公開Dockerイメージを使える
    • AppiumでもDocker使っていい感じにしたい
    • NestedVirtualization問題
    • やるならmacOS
    • budtmo/docker-android
      • 5~6GB
      • 2分くらいでpullできる
    • bitriseio/docker-android
      • 26~27GB
      • キャッシュできない環境では実用に耐えない

GitHub Actions Parallel Testing

  • @yasuhirokiさん

並列テスト

複数のテストを分割して並列に実行したい

  • matrixを使うとできる
    • 自分でコードもちょっと書かないといけない
  • CircleCIは実行時間が均されるように自動で振り分けてくれる
    • knapsackを使うといい感じにできる

テスト結果を集計したい

  • artifactを使う
    • それぞれのノードで見えるディレクトリにファイルをアップロード
    • それらをダウンロードして集計する

Tips

GitHub Actions と (主に reviewdog を使った) Automated Code Review

  • @haya14busaさん

GITHUB_TOKEN

  • secret.GITHUB_TOKENを明示的に指定したときだけ使える
    • forkしたリポジトリからはちゃんと見えないようになってる
  • リポジトリにインストールされたGitHub Appのアクセストーク

Check API

  • コードにコメントをつけられる
  • Review APIより使いやすい
  • reviewdog

他のCIサービスと比較してできることできないこと

  • @Kesinさん

ビルドキャッシュとアーティファクト

マトリックスビルド

  • nodeの複数バージョンでJobを実行といったことができる

マトリックスビルドとconainter

  • マトリックスで指定したイメージ上でテストが実行できる
  • actions/setup-xxxを使わなくてもよくなる

Github Actionsでハマった点と解決方法

  • @kawasin73さん

プライベートリポジトリ

  • プライベートリポのインストールが難しい

3rd Party Action信頼できない

  • 大もとはGitHubリポジトリ
    • 差し替えられても気づけない
  • フォークして使いましょう
    • 中身を確認して使う

git cloneに失敗する

  • サーバ鍵の検証を諦めて無視した
  • GitHubないからGitHubリポジトリにアクセスするので中間者攻撃はないだろう

セマンティクスバージョニングがない

  • v0.1はv0.1.0にならない
  • Actionsのバージョンはタグとの完全一致

自作Github actions入門

  • @Naturalclarさん

actions-toolkit

github.com

  • @actions/core
  • @actions/exec
  • @actions/io
  • @actions/github
  • @actions/tool-cache

「CROSS Party 2019」に参加してきました

  • CROSS Party 2019に参加してきました。

2019.cross-party.com

業務ハック 〜業務効率化にコミットする職人達の世界〜

  • 野秋 拓也さん(DMM.com)
  • 廣氏 宣勇さん(DMM.com)
  • 廣野 美里さん(freee)
  • 髙木 咲希さん(SonicGarden)

業務ハック

  • 業務改善をエンジニアリング行うこと

事例

  • Slackで相手の名前とか入れると参加者の開いてる予定検索して提示してくれる
  • 受託開発で業務ハック
  • slackとかgsuiteと使うようになって業務ハックしやすくなっている
  • 全部自分でゴリゴリに作るとかはそんなない
    • いろんなサービスを組み合わせて解決させる
  • kintone
  • Zpier

[基調講演] 夢を形にする技術 〜 大規模開発におけるサイエンスとエンジニアリングの境界を科学する

はやぶさプロジェクト

  • 無人探査機によるサンプルリターンミッション

ユーザ要求

  • IT
    • 自分たちもユーザ
    • 自分たちが使いたいもの
  • 探査プロジェクト
    • イノベーションは技術が主導して立ち上げるもの
    • 顧客は今しかみてないからそのニーズに答えるだけでは発展しない

技術の継承

  • IT
    • 多くのシステムが負債化している
      • 古い技術が動いているからといって放置されている
      • 開発できるエンジニアを持っていなくて委託しているからノウハウのある人がどこにいるかわからない
      • 人材の流動が激しいと数年でいなくなることを想定して作れる
    • ペアプロ、モブプロ
  • 探査プロジェクト
    • 親方と弟子の関係
    • コーチングして技能は得られるが使えるものは得られない
    • 自ら獲得しないといけない
    • はやぶさはやぶさ2の間は10年以上
    • 若いうちからプロジェクトに参加して見せていきたい

チームビルディング

  • IT
    • 同じ方向を向ける中で多様性を持つことが重要
    • 根本から違う方向向いてしまうのは採用ミス
    • 考え方の違う人を入れてしまうよりも才能をある人を貶してしまう方がましというくらい
    • ローコンテキストを前提にビジョンを共する有
  • 探査プロジェクト
    • 向いているところに向いている人を配置する

緊急企画!漫画村再検証!

漫画村

  • 海賊版サイト
  • 政府がサイトのブロッキングを実施
  • 4つの闇
    • 法解釈の闇
    • 法改正の闇
    • 報道の闇
    • 広告の闇

海賊版サイト対策検討会議はなぜ紛糾したのか

事務局による進行の問題

  • 著作権侵害ブロッキングは世界42過酷で導入されているだから日本もやるべき」
    • 2001年にEUが司令を出してEU各国で法制化
    • 法制化されているが実施したことある国は半分くらいしかない
    • EUで28カ国が法制化17年間実績なしの国が15カ国

被害額3000億円

  • 漫画村の被害額が3000億円という試算は本当か
  • 年間コミック市場は4000億前後
  • 総アクセス数に単価をかけたのが3000億円
    • アクセスが有った分全部売り上げた前提

Coinhive事件/WizardBible事件にみる不正指令電磁的記録に関する罪

法が問題としていること

  • 意図に沿うべき動作をさせず不正な司令を与える電磁的記録

事件

  • Coinhive事件
    • 自分のページにWebブラウザにマイニングさせるJSを貼った
  • WizardBible事件
    • リモートシェルを埋め込み
  • アラートループ
    • アラートを閉じてもアラートが出続ける

この状況が続くと

  • サイバーセキュリティ分野の活動が衰退する懸念
  • 海外に優秀な人材が(今以上に)流出

フロントエンドエンジニアがこの先さらに生き残るには

  • mizchiさん(plaid)
  • lacoさん
  • 奥野賢太郎さん(クレスウェア)

働き方のスタイル

  • フリーランスになった
    • もともとのつながりで仕事を得られた
  • 週1日副業
    • サラリーマン感なくなった
  • フリーランス時代の仕事
    • フロントエンドは管理画面の需要が高い
    • エクセル再実装

フロントエンドエンジニアの尖り方

日本人がOSSにあまり貢献していない

  • 一部貢献している人がいてもスター扱いしてそれで終わってる
  • OSSは大企業が作るものに集約されてきていってる
  • バグバウンティの方がまだある
  • 翻訳のコントリビューションする人はけっこういる
  • GitHubのトレンドに日本人作者のライブラリがのることがほとんどない
    • 最近だとhiroppyさんのfusuma
    • 中国勢が強い

フロントエンドのカバーする領域

  • フロントエンドがサーバーサイドに入り込むようになってきた
    • Next.js, Nuxt.js
    • BFF
    • FaaS
  • フロントエンドの大事なところはフロントエンドであることユーザに最初に触れるところ
    • パフォーマンス
    • デザイン
    • UX
    • その反対側にデータを堅牢にする役割の人も必要
  • SPAを作るのが大変だった時代から当たり前に作れる時代になった
    • 注力できる範囲が広がってきてカバーできる領域が増えてきた

フロントエンドのDeveloperExperience

  • webpackのビルド時間が長すぎて改善の妨げになっていたり

次にくるものは

  • 数年前にReactの仮想DOMに魂が震えた
  • 次はWebWorker
    • off the main thread
    • メインスレッドの奪い合い

Rust

  • 今のWebをRustで書くことは今はなさそう
    • ライフタイムとかフロントエンドとは違った難しさ
    • ゲームとか作るのにはいいかもしれないけどメインでやることはなさそう
  • メインスレッドに登場してくることはなさそう
    • workerで動かす処理を書くとかはありそう
    • Backend in Frontend

フロントエンドの技術選定

  • TypeScriptは大前提
  • フレームワークを使うかどうかから
    • ampを使うとか
  • 複雑にならないからと思っても作り変えるときは絶対来る
  • バックボーンの成り立ちや考え方を気にしてもいいかも

「Meguro.css #7 @ ラクスル」に参加してきました

  • Meguro.css #7 @ ラクスルに参加してきました。

megurocss.connpass.com

  • 初めて知った記法や、普段当たり前に書いている変数名やライブラリへの問題提起など、学びがとても多かったです。
  • 次回もまた参加したいです!
タイトル 発表者
react-nativeにおける、Styleとの向き合いかた Naturalclar
Design Tokensを考える前に俺たちは変数名について考え直すことがあるのではないか yamanoku
詳細度調整擬似クラス ShoEzawa
Chrome 78 Betaで試すCSS Properties and Values API あらや
Stylelintの取扱説明書 moro
Sassに頼らないCSS設計 takanorip

react-nativeにおける、Styleとの向き合いかた

  • Naturalclarさん

React Native

  • Reactライクな書き方でiOS/Androidアプリが作れる

React NativeのStyle

  • WebではないからCSSではないけど同じような感じで書ける
  • CSS in JSで書くことになる

React NativeとWebの差

  • Displayは基本flex
  • flexDirectionのデフォルトがColumn
  • marginなどのショートハンドが使えない
    • marginVerticleなど独自のものもある

Design Tokensを考える前に俺たちは変数名について考え直すことがあるのではないか

  • yamanokuさん

デザインシステム

  • 一貫性が保たれたUIUXを提供できるもの

Design Tokens

  • デザインシステムにおけるスタイル変数集
    • CSS variables
    • SASSの変数とか
    • json読み込んだりとか
  • 色の変数名にwhiteとかつけるのはどうなのか
    • Atlassianのデザインシステムはカラー名が色の名前に準拠してない
  • 変数名が教養があるかどうかになるのも何か違う

詳細度調整擬似クラス

  • ShoEzawaさん

詳細度調整擬似クラスとは

  • :where()
  • 引数として与えたセレクタを詳細度の計算で無視する

使い所

  • !importantと同様詳細度に鑑賞するので乱用は危険そう?
  • ちゃんと使えば便利になりそう
  • 擬似クラスや属性セレクタを使うと詳細度が高くなりがちなので使えそう
  • 用途を限定して使うとよさそう

Chrome 78 Betaで試すCSS Properties and Values API

  • あらやさん

CSS Properties and Values APIとは

  • CSSのCustom Propertiesを構造化するためのAPI
  • CSSのCustom Propertyに初期値とsyntax(型のようなもの)を指定できる
  • Chrome78から使える

API

  • window.CSS.registerProperty
  • syntaxにnumberとかcolorとか設定できる
  • 一度定義すると再registerできない
  • syntaxに一致しない値を設定するとErrorがでる
window.CSS.registerProperty({
  name: '--property-name',  // 対象のcustom propertyの名前
  syntax: '*',              // 値をどうパースするか
  inherits: true,           // 親要素の値を継承するか
  initialValue: '',         // 初期値
});

Stylelintの取扱説明書

  • moroさん

Stylelintとは

  • css潜在的なエラーの事前検知や一貫性を保てる

Stylelintの使い方

  • stylelintをinstall
    • npm i -D stylelint
  • configを作成
  • 公式が提供するlintルール
    • stylelint-config-standard

上手な使い方

  • メッセージをカスタマイズできる
  • huskyとlit-staged
    • commitやpush前にタスクを走らせてそこでlintチェックする
    • 必ずlintがかかるようにできる

Sassに頼らないCSS設計

  • takanoripさん

Sass

  • 便利だけど機能が多すぎる
  • 便利だけど注意が必要な機能もある
  • Sassの機能を使うことが目的になってませんか

上書きをなくす

  • 詳細度で値を上書く
    • 詳細度との戦いが始まるのでよくない
  • 過度な共通化をしてると起こりやすい

Custom properties

  • CSSの変数のようなもの
  • 標準のCSSで使える
:root {
  --primary-color: ##ff0000
}
.hoge {
  color: var(--primary-color)
}
  • 色や大きさなど定義しておくことで統一したstyleにできる
  • 上書くだけではないのでよい

ScopedなCSS

フラットなCSS

  • ネストが深いと検索しづらくて開発効率が落ちる
  • 詳細度との戦い
  • Sassはネスト使えちゃうので使っちゃう

「JSUG勉強会 2019その9 Spring&AWS」に参加してきました

  • JSUG勉強会 2019その9 Spring&AWSに参加してきました。

jsug.doorkeeper.jp

  • Springの勉強会ですが個人的にECSの話をきけたのがとても勉強になって嬉しかったです。
タイトル 発表者
Spring BootをKotlinで作成し Amazon Elastic Container Service (ECS) で稼働させる話 白山 文彦 (Fumihiko Shiroyama)
AWSで作るクラウドネイティブアプリケーションの基本とDevOps 川畑 光平 (APN AWS Top Engineers & Ambassadors)

Spring BootをKotlinで作成し Amazon Elastic Container Service (ECS) で稼働させる話

  • 白山 文彦 (Fumihiko Shiroyama)

Kotlin

  • いわゆるAlt Java
  • 完結で強力な記法
  • Null安全
    • 型の時点でnullが入りうるかわかる
    • 自然な形で具象型にできる
  • JetBrains製

Spring with Kotlin

  • Spring Initializr
  • Docker化
    • 簡単に捨てられる開発環境
    • ステートレスなアーキテクチャの強制
    • 本番運用を見据えられる
  • DBもDocker化
  • AWSにデプロイ

Spring on AWS

Amazon Aurora

  • 自動でスケールする(RDSでは昔はできなかった)
  • マルチリージョン
  • 1つのライターと複数のリーダ
  • 書き込みエンドポイントと読み込みエンドポイントが違う
  • ローカルからでもアクセスできる

Amazon ECS

概要
  • Dockerコンテナを簡単にデプロイ管理するためのサービス
  • コントロールプレーンはECS or EKS
  • データプレーンはEC2 or Fargate
    • Fargateは中を意識しないで簡単に使える
    • EC2は自分で好きなようにできる
  • Fargateを使うとリソースを意識する必要ない
使い方
登場人物
  • タスク
    • Dockerコンテナ
    • タスク定義から作る
  • サービス
    • タスクを複数束ねる
    • APIサーバ」や「HTTPサーバ」のような役割の単位
  • クラスタ
    • 複数のサービスを束ねる

まとめ

  • ローカルから段階的にDocker化することで簡単にECS化できた
  • Fargeteは簡単にコンテナを扱える
  • CI/CDツールと連携するとECSの作成やデプロイを自動化できる

AWSで作るクラウドネイティブアプリケーションの基本とDevOps

  • 川畑 光平 (APN AWS Top Engineers & Ambassadors)

AWSで作るクラウドネイティブアプリケーションの基本

news.mynavi.jp

「Serverless Meetup Tokyo #14」に参加してきました

  • Serverless Meetup Tokyo #14に参加してきました。

serverless.connpass.com

タイトル 発表者
機械学習MVPにServerless Frameworkがオススメな理由 池田 雄太郎(株式会社 KaizenPlatform)
今Serverlessが面白いわけ(v19.09) 川崎 庸市(Microsoft Corporation)
AWSで開発するサーバレスAPIバックエンド 三宅 暁(フリーランス
F-SecureのServerlessなSecurity 河野 真一郎(エフセキュア株式会社)

機械学習MVPにServerless Frameworkがオススメな理由

  • 池田 雄太郎(株式会社 KaizenPlatform)

ML/DLプロダクト開発におけるストレス

コンピューティングリソースの短期的ダイナミクス

  • 学習などで一時的に大量リソースほしい
    • => 柔軟なスケールイン/スケールアウト機構が必要

コンピューティングリソースの長期的ダイナミクス

  • ビジネス的な成長予測ができないのでどれくらい使われるかわからない
    • => インフラに関する高い知識が求められる

Serverless

  • リクエストに応じて必要なだけのリソースをリアルタイムに確保する
    • リソース確保が柔軟
  • ML/DLプロダクト開発と相性がいい

Serverless導入の悩み

  • 設定/デプロイに関するデメリット
    • 使うBaaSが多くなり勝ち
      • AWSとかいろんなサービスがある
    • DevOps環境構築のハードルが高い
      • ロジックの実装はJupyterNotebookが多め
  • そこでServerless Framework

Serverless Framework

  • Serverlessアプリの構成管理ツール
  • CloudFormationの定義したリソースをLambdaを中心に一括で設定できる
  • ステージング環境の分割など簡単にできる

今Serverlessが面白いわけ(v19.09)

世の中の動向

  • 人類の問題
    • アジリティがほしい
    • 高い生産性効率性がほしい
    • 運用コストを下げたい
  • ビジネスの傾向

FaaSを支える技術

  • インフラ技術の進化の賜物
  • 一般的にコンテナ相当の技術が基盤に使われる
    • 使った分だけ課金
    • 高速にスケーリング
  • データストアの進化
    • ステートフル/データ永続化対応
    • スケーラブルなデータストア
    • NoSQL型がフィット
  • プラットフォームの進化の方向性
    • 自動化
    • 抽象化
    • 標準化
  • Serverlessにおけるクラウドベンダーの実情
  • Knative
  • KEDA
  • Virtual Kubelet

AWSで開発するサーバレスAPIバックエンド

ノーコーディングでバックエンドAPIを作る

  • Amplifyは使わない
    • ベンダーロックインしないように
    • Apollo Clientを使う
  • Cognitoは使うがOpenID Providerとして使う
    • react-oidc-contextを使う
  • serverless-appsync-plugine
    • AppSyncの設定を完結に定義してデプロイできるServerlessFrameworkのプラグイン

F-SecureのServerlessなSecurity

Serverlessでセキュリティ

  • インフラは提供者が担保
  • エンドユーザがアップロードしてきたファイルは安全か?
    • アップロード時にF-Secureと連携してセキュリティチェックしてくれる
    • API連携でセキュリティチェックができる

「Meguro.css #6 @ oRo」に参加してきました

  • Meguro.css #6 @ oRoに参加してきました。

megurocss.connpass.com

タイトル 発表者
レガシーフロントエンドで頑張ってCSS設計した話 etawin
CSSイラストレーション deren @study_dedede
段組と印刷の地雷 吉川雅彦@行程さん社長 @masahiko888
すたいるQ Ko.Yelie (エリー) @ko_yelie
Scoped CSS + RSCSS のすすめ すわくん @ztrehagem

レガシーフロントエンドで頑張ってCSS設計した話

  • etawinさん

従来の環境

  • CSSトランスパイラなし
  • JavaScriptUIライブラリなし

改修後

  • stylus
    • なぜSassじゃないか
    • JSっぽく変数書ける
    • CSSプロパティライクにmixinを表現できる
  • BEM

工夫

実装序盤

  • 無理して共通化するよりも愚直に書いた方がいいケースも多い
  • 雛形になるクラス作ってそれプラスαって感じで使うと良かった

実装中盤

  • 意味のある単位であとからまとめていった
    • stylusのmixinが便利

実装終盤

  • 抽象のしかた細かく考えだすと不毛な時間に
  • 何者かでなく何を指し示すかで分類

最終的な構造

  • デザイン規約
  • 雛形クラス
  • CSSクラス

CSSイラストレーション

  • derenさん

CSS/JS学びたい

  • CodePenのぞくと面白いと教えてもらった
  • CSSだけで作品を作れる

私流イラストレーション

  • 1.下絵を書く
  • 2.パーツごとにdiv化
    • BEMでつけるといい
    • クラス名詳細に書いてるのでぱっと見でわかりやすい
    • デメリットはクラス名が長いことくらい
  • 3.パーツの形をひたすら制作
    • before/after使うとタグが無駄に増えないからいい

よく使うプロパティ

overflow

  • はみ出た要素の表示方法を指定
  • overflow: hidden; -はみ出た要素非表示

transform

  • 要素の表示位置の変更
  • transform: translate(10px, 10px); top: 10px;left: 10px;と同じ

transform-origin

  • 中心点の変更

CSSで何か作りたい人

https://codepen.io/challenges/codepen.io

段組と印刷の地雷

  • 吉川雅彦さん

段組みを印刷

  • 段組みをプレビューして印刷するというものを作った
  • すべてのブラウザに対応できない
    • IE,FFは印刷プレビューを出しにくい
    • Chromeだけ対応
  • PuppeteerとヘッドレスChromeでやるとよさそう

難しかったところ

  • 紙の余白を指定したい
    • @pageで指定
  • 文字が途中で切れてしまう
    • display: blockとかdisplay: tableで対応
  • h2/h3のサブタイトルのあとで改行したくない
    • break-inside: avoid使った
  • PDF印刷したら文字が欠ける
    • ウェブフォント適用で解決
  • Androidで絵文字を入れると1MBくらいファイルサイズが増える
    • わからない・・・

まとめ

  • 段組み+印刷大変
  • CSS/JS/デザインなどなどで解決していく
  • 割り切りも大事

すたいるQ

  • Ko.Yelie (エリー)さん

Q1

  • Q
    • margin/paddingを全て%で指定した場合基準になるのはそれぞれ親要素?自身の要素
  • A
    • どの方向で指定しても全て親要素の幅が基準になる

Q2

  • Q
    • flexで横に並べた要素の最後だけ右寄せにしたい
  • A
    • margin-left: autoをつけると右寄せになる

Q3

  • Q
    • transformにいろいろ指定した場合にどうなるか
  • A
    • transformのプロパティは左から順に適用されていく

Scoped CSS + RSCSS のすすめ

  • すわくんさん

ScopedCSS

RSCSS

  • BEMの簡単版みたいなやつ
  • シンプルな規則
    • Components
    • Elements
    • Variants
  • 書きやすい読みやすい捨てやすい

ScopedCSS + RSCSS

  • より安全なScopedCSS
  • より単純なRSCSS

「React.js meetup #8 初心者歓迎 LT会」に参加してきました

  • React.js meetup #8 初心者歓迎 LT会に参加してきました。

reactjs-meetup.connpass.com

タイトル 発表者
Gatsby紹介&Gatsbyのビルドをザックリ理解 kon_shouさん
Storeで扱う状態のライフサイクル @as_masaさん
React Hooks - カスタムフックとカプセル化 @sonatardさん
Reactから始めるリプレイス生活 fff_komatsuさん
connectの要らないreact-redux @natural_clarさん

Gatsby紹介&Gatsbyのビルドをザックリ理解

  • kon_shouさん

Gatsbyとは

  • Reactで書ける静的サイトジェネレーターe
  • viewはReact
  • データやりとりはGraphQL
  • Reactの公式サイトもGatsbyでできてる
  • starterkitが豊富

www.gatsbyjs.org

Storeで扱う状態のライフサイクル

Storeの設計

  • 1Store=1model?1Store=複数model?
  • ローカルステート使う?

アプリ特性によって考える

  • 全部載せ系
    • ページ遷移しない
    • タイムライン系
  • ページ遷移系

全部載せ系

  • アプリ起動から終了までのライフサイクルしかない

ページ遷移系

  • アプリ起動から終了までのライフサイクル
  • ページを表示してから別ページに遷移するまでのライフサイクル
  • ページごとの型を定義できる
    • Topページ型とかUserページ型とか

ローカルステート使うか

  • 同じライフサイクルで管理したいのでStoreで管理したい

React Hooks - カスタムフックとカプセル化

  • @sonatardさん

ReactHooks

  • React16.8で追加された
  • statteなどの機能をclassを使わずに書ける
  • useXxxというものが公式で10個公開されている
  • custom hookとして独自のものも作れる

カスタムフックの例

  • ロジックをカスタムフックに隠蔽することでViewをすっきりさせることができる
  • 可読性向上
  • 再利用性向上

カスタムフック

  • いろいろ公開されているから作る前に検索すると見つかるかも

github.com

github.com

nikgraf.github.io

Reactから始めるリプレイス生活

意図せぬコンポーネントの破壊

  • コンポーネントAを変更したらコンポーネントAに依存するコンポーネントBが知らないうちに壊れてた
    • Storybookを使ってればStoryShotsがお手軽で便利
  • styled-componentsのcreateGlobalStyleで意図せず壊れた
    • divタグにstyle定義してそれで囲うことでスコープを狭めた
    • 既存コードに影響ないようにできた

connectの要らないreact-redux

  • @natural_clarさん

react-redux

  • reactでreduxを使うためのラッパー

従来の使い方

  • mapStateToPropsとかmapDispatchToProps使ってconnectする

react-redux v7.1

  • hooksを使ったSPI
    • useSelector
    • useDispatch
  • これらをつかうとconnectを使わなくてよくなる

useSelector

  • 特定のselectorを使って値をとってくるhooks
  • mapStateToPropsの代わり
  • selectorの結果が変更されたときだけrerenderされる

useDispatch

  • 今までのdispatchと同じ感じ
  • mapDispatchToPropsの代わり

「UIT meetup vol.7 集まれ!(タブン)実務では使わないフロントエンド芸発表会」に参加してきました

  • UIT meetup vol.7 集まれ!(タブン)実務では使わないフロントエンド芸発表会に参加してきました。

uit.connpass.com

タイトル 発表者
@1-div challenge kawasako3
SVGで作るワードアート hashrock
React.js と動くもの、鳴るもの Leonardo
本気でCSS芸やりたい人ためのbox-shadow講座 ダーシノ
CSS PANICを支える技術 GeckoTang

SVGで作るワードアート

  • hashrockさん
  • SVG芸人

何でSVG

  • なくてもフロントエンドは作れる
  • やってて楽しくなる系

ワードアート

  • MS Wordで作れる
  • パワポとかエクセルでもできる

SVGでワードアート

  • SVG
    • <svg>
    • d属性で曲線
  • SVG DOM
    • ReactとかVueで扱える
  • ベジェ曲線
  • SVGの世界は単位がない世界
    • ブラウザのスクリーンの世界はpx
    • クリックされた位置を取得する時にSVGの世界の単位に変換しないといけない
  • SVGフィルタ
    • drop shadowみたいなものも作れる

React.js と動くもの、鳴るもの

  • Leonardoさん(LINE)

React + ReduxでWebGL

  • レンダリングのタイミングが大切
  • Three.jsのレンダリング
    • composer.render()を繰り返し呼ぶ
  • オブジェクトがぐるぐるしてるだけのアプリはあまりない
    • ユーザの操作にあわせて動かしたり
  • requestAnimationFrame()でrender呼ぶ
    • Reactのライフサイクルで呼んでstate管理するとかなり重い

React + ReduxでWebAudioAPI

  • AudioNodeどこで持つか
    • 全部Storeで持つようにした

参考

qiita.com

本気でCSS芸やりたい人ためのbox-shadow講座

  • ダーシノさん

box-shadowの基礎

  • 影のサイズは要素と同じ
  • 影は要素の背面に表示される
  • 影はカンマ区切りで複数指定し表示させることができる

box-shadowでファミコン風UI

nostalgic-css.github.io

  • NES.cssはbox-shadowを使っていろいろやっている
    • inputの枠とかbuttonの外枠とか

box-shadowでドット絵

  • もとの要素のheight/widthを1pxにする
    • 影のサイズは要素と同じだから

box-shadow芸のハマリポイント

  • ギガを消費する
    • 大量のピクセル情報を持っている
    • ドット絵だとピクセル単位でたくさん定義が必要
    • 複数サイズ用意する場合サイズごとにbox-shadowの指定が必要
  • ギガを抑える
    • currentcolorを使う
    • サイズの調整はtransform: scale(x)を使う
  • メンテできない
    • box-shadowの定義が大きすぎてどこを変えたいかわからない
    • Sassをうまく使って頑張る

まとめ

  • box-shadowはアイデア次第でいろんなことができる

「Node学園 34時限目 jsconf.eu 報告会」に参加してきました

  • Node学園 34時限目 jsconf.eu 報告会に参加してきました。

nodejs.connpass.com

2019.jsconf.eu

タイトル 登壇者
JavaScript Package Manager 2019 yosuke_furukawa
Cloudflare Workersの紹介 dorayakikun
Node.jsとWebAPIのこれまで、現在、これから Leko
jsconf.eu 報告会 Performance Empathy 編 tomonari-takahashi
TypeScriptでコマンドラインパーサー Akito0107

JavaScript Package Manager 2019

  • yosuke_furukawaさん

JSのPackageManager

  • npm
    • npm inc
    • npm cli
    • npm reistry
  • yarn

npm

  • npmの仕組み
    1. ローカル依存ファイルを読む(package-lock.jsonとか)
    2. 存在しないpackageのメタデータをfetch
    3. 木構造を計算して実行
    4. packageのtarをダウンロード
    5. インストールスクリプト実行
  • ダウンロードが高負荷
    • fetchしてgunzipしてコピーする
    • Network負荷
    • CPU負荷
    • FileIO負荷

tink

  • 新しいパッケージマネージャー
  • npm cliをもとにして作られてるもの
    • ゆくゆくはnpmに統合
  • npm iの処理を実行時にやればいいのでは
    • node_modulesを仮想上のフォルダにする
    • ランタイムでモジュール解決するからnpm iがいらない
      • コピーしないからFileIO改善
      • cloneして実行するだけでよくなる
  • zero install
  • node main.jsではなくtink sh main.jsとするtinkで実行できる
  • prepareとunwind
    • prepareは事前にmoduleをfetch(本番はこれでやるとよい)
    • unwindは事前にnode_modulesを実体化

loadmap

  • npm v8でtinkがnpmに統合される

yarn

  • yarnのv2でも同じzero installに取り組んでいる

今後

  • npmもyarnもzero installになっていく
  • npmとyarnどちらも有意差はまだない
  • まだexperimentalな段階

JavaScript Registryの今後

  • JavaScript Registryとは
    • Packageをバックで管理するサービス
  • JavaScriptのRegistryをビジネス的に成功させるのは難しい
    • public moduleは無償で提供
    • アクセスコントロールするなら有償
  • npmは100万モジュールある
    • rubyのgemは30万
  • Entropic
    • 中央集権ではなく分散管理していこう
    • npmにつながる新しいregistry
    • みんなで治験を高めて分散管理できる状態を目指す

Cloudflare Workersの紹介

  • dorayakikunさん

wasm

  • ここ1~2年盛り上がってきた
  • JSConf EUでのwasmのセッション3つ

Webの現状

  • JSのbyteサイズが年々上昇している
    • この3年でモバイルは50%増加
  • Time To Interactive
    • TTIの平均値9秒以上

既存の戦略

  • SSR + Cache
    • Time to First Byteが遅い
  • CSR + Cache
    • FCPからTTIまでラグがある
  • どれもトレードオフがある
  • => Edge Side Rendering

Edge Side Rendering

  • エッジサーバでhtmlをrendering
  • SSRCSRのいいとこ取り

Cloudflare Workers

  • エッジサーバ上でserverlessアプリを動かせるサービス
  • 言語はjsかwasm
  • デプロイはwebかwrangler
  • 要素技術
    • V8のIsolate

Edge Side Renderingは有効か

  • グローバルなサービスだと旨味がありそう
  • エッジサーバで何させるかは議論の余地ある

Terrarium

  • Fastlyが提供するEdge Computing Platform
  • wasmのみ

Node.jsとWebAPIのこれまで、現在、これから

  • Lekoさん

NodeとWebAPIのこれまで

  • ブラウザのJSの仕様/NodeのJSの仕様
  • 片方にあったやつをもう片方でも実装されたりとか
    • 同じようなことなのに微妙に違うとか
  • NodeとWebAPIを近づけようとしてる
    • URLSearchParams
    • TextEncoder
    • Wrker Threads
    • Performance Timing API
  • 議論中
    • StreamsAPI
    • FetchAPI
      • 仕様がとても複雑
      • Nodeで全部再現できるのか、再現する必要があるのか

まとめ

  • 多くのWebAPIがNodeに取り入れられている
  • ワークフローを改善してより改善されていく

参考

blog.leko.jp

jsconf.eu 報告会 Performance Empathy 編

  • tomonari-takahashiさん

パフォーマンスに関して大切なこと

  • デフォルト/デファクトツールを使う
    • ブラウザデフォルトでできるようになってることも多い
    • lazy loading
    • virtual-scroller
  • パフォーマンスをマネジメント
    • Performance budget

TypeScriptでコマンドラインパーサー

  • Akito0107さん

コマンドラインパーサーを作る

  • 有名なライブラリがいろいろある
    • minimist
    • commander
  • オプションが複雑だとどれもつらい
    • 型がほしい
    • => 作った

github.com

「PORT Firebase × Flutter」に参加してきました

  • PORT Firebase × Flutterに参加してきました。

stamp.connpass.com

タイトル 発表者
Flutterで使うCloud Firestore Shogo Yamada
Flutter × Firebase Crashlytics 菊池 紘
Firestoreのトランザクション 村本 章憲

Flutterで使うCloud Firestore

FlutterとFirebase

  • FlutterでFirebaseを使うプラグインが豊富
    • 基本的に全部ある
    • Firestoreのincrementも最近対応
  • 使い心地はWeb版Firebaseっぽい
  • Flutterだから使えないみたいな話は基本的になし
  • ネイティブでドキュメント通り実装されたものをFlutterから呼んでるだけ

開発スピード

  • Flitterはホットリロードあるし快適
  • Firebase使えばサーバサイドメンテ必要なし
  • Flutterの知識やFirestoreの知識は必要

今後の動き

  • Firestoreに新機能がでるとFlutter側にissue立ってすぐ対応される
  • Flutter × Firestoreではやってる実績はまだ見ない

Flutter × Firebase Crashlytics

  • 菊池 紘さん(Diverse)

youbrideというアプリ

  • 既存アプリをFlutterに置き換えている
  • ScopedModelアーキテクチャ
  • gRPCでサーバと通信

Flutterをproductionで運用

  • クラッシュレポートどう取得する
    • firebase_clashlyticsという公式のプラグイン(まだ開発段階のもの)
    • 導入面倒だけどマニュアル通りやればよい
  • 端末で発生した例外を記録してサーバに送ってくれる
  • Dartの例外のでかたがまだ微妙
    • 全部非致命的エラーになる
    • 拡張子が.javaになる
    • 例外の種別不明
    • 難読化マップ非対応

競合サービス

  • Fabric Crashlytics
    • Firebase Clashlyticsとほぼ同じ
    • 2020/3/31に終了予定
  • Sentry
    • 有料
    • 難読化マップ非対応?

Firestoreのトランザクション

  • 村本 章憲さん(Stamp)

FireStoreでtransaction

  • 同時に更新しようとしたときに問題が起きる
  • update time
    • 1/sec
    • 一秒に一回しか更新できない
  • runTransaction()
    • read/write/observe/commit/rollback
    • read -> write -> commit
    • observerがwriteを監視してる
    • 他でwriteされてたらrollbackしてretry
    • 5回retryしてだめだとそこで終わる
    • 1秒間に100更新が来たら95は失敗する
  • Distributed counter
    • shardingする
    • 増やせばいいというものでもないのでどれくらいshard数にするかは設計しだい

firebase.google.com

メモ

  • FlutterでCI

www.bitrise.io

codemagic.io