「Rakuten EC Tech Meetup(楽天EC開発の裏側を全部お話いたします) Vol.1」に参加してきました

Opening

  • タリアさん(CTO)
  • 黒住昭仁さん(CIO)

事業

  • 9個の部署以下3つずつ
  • 50ヶ国
  • 開発者2000人
  • 各国に開発拠点

英語

  • 2012年から英語
  • たかが英語(三木谷)
  • とりあえず海外行けば話せるようになる
  • 採用時TOEIC800少なくとも600
    • 2年以内に800クリアできればOK
  • 外国人ばっかだから勝手に身につく

Development lifecycle with "R-JET"(楽天市場での共通JavaScript Toolkitについて)

  • Daniel Berlanga(ECMD Dept)

楽天のフロントエンド

  • Speed Speed Speed
    • Quality
    • Maintainability
    • Standardize
  • How
    • JS(ESNext)
    • TypeScript
    • ESLint
    • TSLint
    • Babel
    • Webpack
    • npm
    • react/redux
    • chai/mocha
      • jestもある
    • arma
    • saucelabs
    • intern
    • selenium
    • jenkins

R-JET

  • Rakuten JavaScript Engineer Toolkit
    • 設定にむだな時間をかけないように標準化したもの
  • 書く技術のTrainingもやってる

How we make sure the capability of Rakuten Ichiba Checkout system against Rakuten Super Sale?(お買い物かごの負荷試験について)

  • Takehara Tomohiro(SREチーム)

お買い物かご

  • ECサイトのお買い物かご
    • 商品追加
    • クレカ情報
    • 配送先情報
    • ポイントの利用
    • クーポンの利用

負荷試験

  • 楽天スーパーセールに向けた負荷試験
    • 一年に数回セールイベント

負荷のターゲットを決める

  • ピーク
  • 継続的な高負荷

負荷試験実行

  • Blazemeter
  • 結果の可視化もできる
  • データもクラウド上に保持できる

問題検知

  • jennifer
    • メモリとかCPUとか
  • Gatling
  • 内製のモニタリングツール多数

問題改善

  • アプリ修正ミドルチューニング等々
  • また最初に戻って繰り返す
    • このフローを4回くらい繰り返す

楽天の社内クラウドについて - RWASP

  • Yossy(ECCT Dept)

RWASP

  • PaaSのようなアプリプラットフォーム
  • Mesos
    • リソース管理
  • Marathon
    • ヘルスチェック
  • Docker
  • Service Doscovery and Nginx

その他

  • Kafka
  • Logstash
  • ElasticSerach
  • zipkin
  • chef

データ

  • 2 data center
  • 4 production clister
  • over 300 Mesos
  • ~2400 CPUCore
  • 10TB memory

今後

  • pods
  • scale up/scale down
  • Prometheus
  • Kubernates?
    • 前は流行ってなくてMesos + Marathonにした
    • 置き換えるかも

Speed-up micro services development with RAPID(APIプラットフォームの開発について)

  • Michell

RAPID Introduction

  • マイクロサービス
  • Java8/python/js

New Microservice with RAPID

  • error handling
  • valdation
  • model
  • logic
  • data access
  • web service client
  • event publisher
  • event consumer
  • cache
  • authentication/authorization
  • configuration
  • metrics
  • logging
  • monitoring

more to keep in mind

  • interface design
  • documentation
  • deployment
  • load testing
  • functional testing
  • failure testing

Framework

  • play
  • spring
  • gradle

whi is using

  • the standard new microservice development

楽天市場でのテスト自動化による開発プロセスの迅速化

  • Mayur

Quality Assurance Automation Team

  • 自動化チーム
  • 5人
  • 手動テストを自動化
  • POC

Test Automation Device Farm Lab

Rakuten Analytics Tracker(RATrace)

  • テストツール
  • 内製ツール

Grafana

  • Availability tracker

楽天市場モバイルアプリ開発について

  • Ryo Kimura

楽天のモバイル

Design & feasibility

  • Requirement
    • Backend Developer
    • Mobile Architect Developer
  • API決める
  • モバイルチームはAPIできるまでの待ち時間がある
  • API出てきてから試すと要件満たせなかったりとか起きる
  • 動くソフトウェアを(agile manifest)

アーキテクチャ(API)

  • GraphQL
  • OpenAPI
  • GRPC
  • BFF
  • API Gateway
  • OpenAPI(Swagger)のモックサーバを用いて速いうちから動作させるようにすうる
    • 初期のフェーズで足りないものに気付ける

アーキテクチャ(モバイル)

楽天ECでのBig Data、Data Science活用事例について

  • Taku Ohkoshi

なぜECにData Science

  • 楽天会員ID数
    • 9000万
  • 多種多様な顧客
  • 多種多様な商品
  • マッチングは人の頭脳の限界を超える

Big Data, Data Scienceの流れ

  • データ収集
    • 行動履歴が最重要
    • 内製化
      • 3rd partyは自由度がない
    • 簡単なBIも内製
  • アルゴリズム開発
    • 需要予測
    • 価格最適化
    • 検索最適化
    • レコメンデーション
  • 付帯機能開発
    • 最適化結果を提供するAPI/UI
  • リリース
  • アルゴリズムチューニング
    • 継続的なチューニングが必須
    • ABテスト100回/年
    • リアルタイムでユーザの行動データを分析しながら進める

職種

「HTML5 APP CONFERENCE 2018」に参加してきました

  • HTML5 APP CONFERENCE 2018に参加してきました

html5app-conf.connpass.com

  • html5スマホアプリを作るということをテーマにしたカンファレンス
    • モバイルアプリ、webフロントエンドやPWAをテーマにしたセッションが中心
  • 聴講したセッションのメモと、それ以外でも資料が公開されているものは載せていきます

セッション一覧

カンファレンスルーム 広場 Bar スペース
基調講演「Web App Platform Strategy (Webアプリ・プラットフォーム戦略)」 JavaScriptではじめるMulti UI Application モバイルネイティブアプリに変わる存在!?初めてのPWA
開発・運用・チームビルディングHTML5 アプリのメリット クイズで学ぶウェブ解析とグロースハック Cordova/Monacaを活用したHTML5 アプリ最新事例
Monaca でモバイルアプリ3分クッキング PWA, Cordova, Capacitor, ReactNative Dom の比較からみる、これからのHTML5 アプリ 【超初心者限定!】Web アプリケーションを作ろう!
pixiv chatstory の PWA としての取り組み HTML5 アプリ入門ハンズオン〜Monaca を使った超速構築法〜 Forkwell リニューアルの裏側〜デザイナーとエンジニアの垣根を超えたフロントエンド開発〜
フロントエンドでクラウドをいい感じに使う 座談会「HTML5アプリと周辺技術の最新キーワードを追う」 -
『ぼくのアプリが改善できない!』PWA/iOS/Android 対応のHTML5 アプリを実プロダクトでいかに構築し、育てていくのか。 - HTML5 アプリにおけるパフォーマンスの基礎知識

モバイルネイティブアプリに変わる存在!?初めてのPWA

  • 野本 司さん(株式会社ソニックガーデン)

背景

  • プログラミング初めて1年ちょっと
  • Webアプリなんとなくできるようになった
  • モバイルもいけるだろう
    • プラットフォームによって言語が違った
  • PWAならWebの技術だけで対応できそう!

PWAとは

  • Progressive Web Apps
  • ネイティブアプリっぽいWebアプリ
  • 新しい技術がたくさんというわけではない
  • アプリでできることをWebでも実現可能に

事例

PWAどう作る

  • Googleのチェックリストがある
  • Lighthouseで採点
  • 要素技術
    • ServiceWorker
    • WebAppManifest

サンプル

  • Firebase
  • Vue
  • Vuetify
    • PWAテンプレートがある
  • さっと作ったサンプルでもLighthouseのPWA100点とれる
    • PWA作るの簡単!

クイズで学ぶウェブ解析とグロースハック

  • 窪田 望さん(株式会社クリエイターズネクスト)
  • 資料未公開

ウェブ解析とグロースハック

  • インパクトファースト
  • 基準を知って違和感のある数字を見つけることが大事
    • CVR
      • 1%以上
    • 直帰率
      • 40%以下
    • 営業転換率
      • 10%以上
  • Guess Who
    • 写真の人物像を推理
    • ターゲットでなくペルソナ
      • 「20代後半男性」ではなく具体的に
  • 優先順位の並び替え
    • 20のitemがあると並び替えのパターンは20京以上
    • kobitという製品を使うと寝てる間にやってくれる(宣伝)
  • アプローチのしかた
    • キャッチコピー
      • レモン100個分みたいな
    • 自分ごとだと反応する
  • 熟練度でUIを変える
    • 初心者には説明のあるUI
    • 熟練者には省略されたUI
  • その他いろいろな手法があったので資料が公開されたら確認したい

kobit.in

PWA, Cordova, Capacitor, ReactNative Domの比較からみる、これからのHTML5アプリ

  • 榊原昌彦さん(一般社団法人リレーションデザイン研究所)

ハイブリットアプリ

  • 標準では
  • そんなことやってられない
    • 手間を減らしたい

フレームワーク

  • Xamarin
  • ReactNative
    • Reactでモバイルを作る
    • JavaScriptCoreでNativeに実行できる
    • モバイル用のコンポーネントをWeb用に変換
      • React Native DOM
        • WebComponents使ってる
      • React Native for Web
  • Cordova/PhoneGap
    • ネイティブの機能に直接アクセスするわけではない
    • WebView上でHTMLを動かす
    • 最新のAPIを叩くとかCordovaのプラグイン作りたいとかだと大変
    • ネイティブっぽいUI
      • ionic
      • OnsenUI
    • Monaca
      • オンラインのエディタ
  • Capacitor
    • ionicチームが作ってる
    • 次世代のCordova
    • web/ios/android/electron
    • NativeとWebViewの融合
      • Native UI Shell

capacitor.ionicframework.com

  • PWA
    • push通知ほしいからNativeアプリなんて風にしなくてよくなる
    • アプリはインストールされなくなってきてる
    • Webでコンテンツを用意しておくのは必須

NativeとWebView

  • 処理速度は0/100のはなしではなく99/100
    • それをどこまで気にするか
  • Swift/Kotlinでも実装悪ければ遅いしWebViewでもちゃんとつくればそれなりになる

youtu.be

まとめ

  • 従来はHTMLでモバイルアプリを作るのはネガティブな理由が多かった
  • 今はポジティブな理由で採用できるだけの土台が整っている

pixiv chatstory の PWA としての取り組み

  • 中川雄貴さん @ikasoumen(ピクシブ株式会社)

pixiv chatstory

  • チャット形式で小説を投稿できるサービス
  • ios
    • Swift
  • android/pc
    • PWA

add to home screen

  • ホーム画面に追加
  • インストールバナーが出てくる
  • 別アプリから開くときにホームに追加したアプリから開けるようになる
    • 内部的にもapkを作ってインストールしているからできる
  • pixiv chatstoryでは手動でホームに追加する案内も用意している

LazyLoadとcache

  • ServiceWorkerによるchache
    • cacheAPIを使ってキャッシュ
    • オフライン対応
  • *.chunck.jsを使って必要なファイルだけ読み込み
    • キャッシュと組み合わせてる
  • 初期ロード後リソースをキャッシュしておく

マルチプラットフォーム対応

  • 対応OSは段階的に拡大
  • ターゲットを絞ることで素早く展開できた

アーキテクチャ

  • ionic3
  • Rais on Heroku
  • FirebaseHosting
  • Onesignal

CI

  • PWAはクラッシュせずただただ止まる
  • エラー収集はしてるけどまずは防ぐ
  • heroku Review Apps
    • githubでプルリク作ると自動でherokuにデプロイしてくれる
    • そこでプルリク出されたソースを動作確認できる
  • 毎日アプリを触ることで気づきを得る
    • ios/android両方普段からさわれるように

まとめ

  • PWA
    • インストール/アップデート意識しなくて良い
    • オフライン対応/プッシュ通知
    • ネイティブアプリの機能
  • SPAはスケール自動化しやすい
  • 面倒な作業は機会に任せたりみんなで楽しむ

フロントエンドでクラウドをいい感じに使う

  • 西谷圭介さん(Amazon Web Service)

このセッションでの用語

フロントエンドエンジニアがクラウドを使うときの課題

  • サービス多くてどれ使えばいいか
    • どれが自分たちに関係あるのか
  • どうやってプロビジョニングするのか
    • サーバたてるとかよくわからないし興味ない
  • SDKどう使うのか
    • 認証周りとか
    • サンプル/ドキュメントあまりない
  • AWS Amplifyというのがある

AWS Amplifyとは

  • フロントエンド/モバイル開発者向けのOSSのJSライブラリ
  • よく使うタスクをアプリに簡単に組み込める
  • React/Angular/Vue(soon)/ReactNativeをサポート

AWS Amplifyでできること

  • Auth
    • Amazon Cognito User Poolを使った一般的なサインイン/サインアップ等
    • MFA(他要素認証)
  • Analytics
    • Amazon Pinpointへのデータ送信
    • カスタム属性値やカスタムメトリクス対応
  • API
  • GraphQLクライアント
    • AWS AppSyncを使える(AppSync以外も可)
    • フルマネージドなGraphQLサービス
  • Storage
  • Push通知
    • AWS Pinpointを使ったターゲティング
  • インタラクション
    • Amazon LExを利用した会話式ボット
  • PubSub
    • AWS IoTもしくは一般的なMQTT
  • Caching
    • データストアを用いた一般的なLRU

開発の流れ

  • AWSリソースの設定 -> IAMの設定 -> ClientSDKの設定 -> コーディング
    • 前3つはAWS Mobile Hub/AWS Mobile CLIを使うと簡単

デモ

  • デモ動画(後日公開?)

まとめ

  • AWS Amplify
    • フロントエンドエンジニアのためのライブラリ
    • 各種JSFWをサポート
      • PWAも
  • サーバを構築せずに幅広いサービスを利用できる

HTML5アプリにおけるパフォーマンスの基礎知識

  • 尾上洋介さん(日本大学
    • 情報可視化、数理最適化、意思決定支援の研究

HTML5アプリとは?

  • Webアプリ、PWA
  • モバイルアプリ
  • デスクトップアプリ
  • 今回はhtml/css/jsアプリをターゲットに

なぜパフォーマンスを考えるのか

  • 何も考えないで進めるとパフォーマンスは落ちがち
    • 機能追加は転送量の増加を招く
  • ユーザは優れたUXのサービスを好む
    • パフォーマンスは価値を生み出す時代になっている

PWA

  • PWA Checklist
    • 低速回線対応
    • パフォーマンス
  • PWAを追求するのにパフォーマンスも無視できない

Webアプリのパフォーマンス

  • ページがすぐに表示される
  • ページが快適に動作する
  • RAILモデル
    • Response
      • ユーザ操作に対して100ms以内にで応答
    • Animation
      • 10ms/フレーム(60fps)
    • Idle
      • アイドル時間を活用する
    • Loading
      • 1000ms以内に初期画面表示

developers.google.com

パフォーマンス改善の方法

  • JS処理の高速化(RAL)
  • バックグラウンド処理(R)
  • スタイルの最適化(AL)
  • 必要リソースの削減(L)
  • リソースの先読み(RL)
  • 考え方
    • そのリソースは本当に必要なのか
    • 必要ならより効率的に取得できないか

遅いJS処理の改善

  • アルゴリズムの改善
    • これがもっともシンプル
    • まずはこれを
  • WebWorker
    • 処理の並列化
    • バックグラウンド実行
  • WebAssembly
    • 処理の高速化
    • C資産の利用
    • JS以外の言語の利用
      • Rustとか
  • GPGPU(WebGL/WebGPU)
    • GPUによる処理の高速化
    • tensorflow.jsなんかはこのアプローチ

リソース読み込みの改善

  • 基本
    • 無駄をなくす
    • 不要なスクリプト、スタイル、画像、フォント
  • どうしようもなくなったら
    • 静的サイト生成
    • SSR
    • PRPL
      • Push/Render/Pre-cache/Lazy-load
      • メリット
        • TTIの最小化
        • キャッシュ効率の最大化
        • 開発デプロイの簡素化
        • ES Modulesによる効率的なスクリプト読み込み

PRPL パターン  |  Web  |  Google Developers

  • 不必要なライブラリの削減
    • ライブラリが増えるとLoading時間はのびる
      • 開発者が楽になるライブラリがユーザ体験を下げることになる
    • どうしても必要なら
      • Tree Shakingで最小限だけ読み込み
      • LazyLoad使う

パフォーマンスの測定

  • Lighthouse
  • 採点項目
    • PWA
    • Performance
    • Accessibility
    • Best Practice
    • SEO

これからのWebアプリ設計

  • 後から本格的なPWAにするのは難しい
    • 最初からPWAを意識した設計(PWAファースト)
    • 後からのパフォーマンス改善も難しい
  • PWAの作り方
    • SPAをしっかり作る
    • ServiceWorker/WebAppManifest追加
    • パフォーマンスチューニング頑張る
  • パフォーマンスファーストな設計へ

まとめ

  • モバイルファースト -> PWAファースト -> パフォーマンスファースト

「Frontrend Vol.12 - サービスの誕生と成長」に参加しました

frontrend.connpass.com

  • Frontrendへの参加は今回で2回目。前回は補欠だっため配信で参加でした。
  • 今回もFRESHで配信されてるので今からでも映像を見ることができます

https://freshlive.tv/tech-conference/220141freshlive.tv

フルコンポーネント化へ。進化を続けるアメブロの道

背景

  • 2016/1〜アメブロフロントエンドリニューアル
  • SpringMVC/Freemarker -> React
  • アメブロは常に進化している
    • 進化しないのは死んでいるということ

コンポーネント化のメリット

  • 高凝集、低結合
  • 独立しているので機能の追加削除が容易
  • 再利用性(やりすぎは注意)

コンポーネント化に用いる技術

  • Reactを採用
  • その他採用したライブラリやアーキテクチャ
    • React
    • Redux
    • react-router
    • AtomicDesign
    • CSS Modules
    • Webpack
  • LazyLoad
    • ページが長く全てSSRするのはパフォーマンス気になる
    • スクロールする度に動的に先のコンテンツを表示

CSS分割

  • CSSも必要なものだけ読み込む
  • CSS Modulesを採用
  • 課題
    • 外部cssの扱い
    • SSR対応
  • 最適なライブラリを自分たちで作った?

github.com

  • styleもスクロールする度に必要なものをstyleタグに追加
    • unusedなCSSの割合を減らせた

子供向けプログラミング学習サービスQUREOの開発裏話

  • 株式会社Applibot QUREOプロジェクト 鈴木康弘さん(@yasuiro)

QUREO

  • サービス
    • 子供向けのプログラミング学習サービス
    • コードを書くわけではなくGUIでブロックを組み立てながら開発する感じ
  • コンセプト
    • 簡単で/おもしろく/学べる

qureo.jp

ブロックプログラミング

  • Blockly
    • google
    • ビジュアルプログラミング用のライブラリ
    • ブロックで構築したプログラムをいろいろな言語で出力できる

ブロックで構築したプログラムをブラウザ上で実行させたい

  • js差し込む?
    • 差し込んだjs消すの大変
  • js-interpreter
    • カスタム定義メソッドの実行ハンドリングがしにくい
  • 独自で言語を作る
    • 時間がなく実現せず
  • scratch-blocksとscratch-vm
    • scratch-blocks
      • Blocklyがベースになっている
    • scratch-vm
      • scratch-blocksをブラウザで動かす
    • Blocklyから文字列のjsを吐き出す必要がなくなりセキュリティ面でも安心

github.com github.com

  • 最終的に
    • block
      • scratch-blocks
    • vm
      • scratch-vm
    • renderer
    • audio
      • tone.js

画像同士の衝突判定

  • 要件
    • 透過部分は衝突させたくない
    • ユーザが作った絵を使えるようにする予定
    • 縦横比は維持したい
  • 事前に判定領域のパスを持っておく?
    • ユーザが作った画像で対応できない
  • ピクセル単位で判定
    • 重そう
    • 矩形でぶつかったらそこだけ切り抜いて(ブロードフェーズ)それに対してピクセル判定(ナローフェーズ)
      • それでも重い
  • 前処理&判定エリア簡略化
    • 画像を正方領域に分割
    • 各領域内の透過ピクセルの比率で衝突判定の対象とするか決める
    • 判定領域を正方でなく円にする

AbemaTVはただのSSRじゃねえんだよ

  • 株式会社AbemaTV 久保田翔太さん(@kubosho_)
  • 株式会社AbemaTV 加藤賢一さん(@ktknest)

AbemaTVのSSR

  • 既存のSPAをSSR化した
  • 既存の設計やライブラリをほとんど変えずにSSR化した

なぜSSRした

  • ユーザにとって意味のあるコンテンツを速く表示したかった
  • SEOのため

SSRした効果

  • サービス名や番組名で検索したときに上位に出やすくなった
  • First Meaningful Paint Timeも速くなった

SSR化でハマったところ

  • もともとSSR化を想定せず作っていた
    • windowやlocalstorageを触ってるところでエラー
  • SSRCSRで描画に差異があった
    • SSRできないものはcomponentDidMountで対応

SSR化まとめ

  • SSR効果あった
  • SPA + SSRなら最初からやったほうが効率的
    • 途中からは大変

以前のAbemaTVとCDN

  • GCP使ってる
  • GCPCDNを使ってた
    • CloudCDN

今のAbemaTVとCDN

  • デスクトップとモバイルで異なるHTMLやCSSを返したい
  • Fastlyを採用
    • インスタントパージ
      • キャッシュ即削除
    • Varnishベースで柔軟なカスタマイズ
    • HTTP/2 Server Push

結果

  • キャッシュヒット率平均90%以上

今後

  • より細かい分類によるキャッシュ最適化
    • 課金プランごとに振り分けるとか
  • ブラウザごとの配信JS最適化
  • 切り戻し手段の再考

「Running Rust in Production」に参加してきました

ライブ動画変換でのRust言語活用事例

導入事例

  • pixiv Sketch LIVE
  • Sketchの操作を配信できる?

なぜrust

  • Cのライブラリに依存すると事前に分かっていた
    • ネイティブライブラリの関数を呼び出したい
    • ネイティブライブラリの呼び出し定義コードを自分で書きたくない
    • ネイティブライブラリからデータを直接受け取りたい

C++

  • 社内ですでにメンテつらい

Go

  • Cとのやりとり大変そう

Rust

  • C++のあれがほしいって時大抵ある
  • rubyのあれがほしいって時大抵ある

難しかったとこ

  • 所有権とかライフタイムとか学習コスト高い
  • moveされうる変数のポインタ

Rust本番投入をあきらめるためのガイドライン

本番投入のハードル

  • rust特有の難しさ
    • メモリに直接さわるのに慣れてるか
  • 新しいが故の難しさ
    • 真似でごまかせない

真似でごまかせないならどうする

基礎原理に従ってやる

  • ノウハウのある言語との比較
    • ランタイムなしで動くとはどういうことか
    • 実行時にCPUやOSを隠蔽しない
  • スクリプト言語の経験しかないとハードルになり得る

運用上必要な機能を整理する

  • クックパッドの事例の場合
    • ロギング
    • エラーハンドリングとトレーサビリティ
    • graceful shutdown
    • シグナルのハンドリング

まとめ

つぶやき

  • そういえば Node.js よりはエラーハンドリングしやすくて安全に I/O の多重化ができる言語として俺は選んだな

ポイントで導入するRust

なぜRustを勉強したか

  • 毎年一つの言語を
  • goはこの先使うこともありそうだしrustを

Rust導入のきっかけ

  • ラクマで自動化を進めようとしていた
  • そこで使った

運用後

  • みんなrustわからないから不具合で困った
  • みんなもrust学んでくれた

Rustを使ったデータパイプライン

データパイプライン

  • EVTLツールをrustで作った
    • Extract, Validate, Transform, Load
  • AWS Lambda上で動かしてる

なぜrust

  • 速いから
  • 厳しい型システムで安心
  • メモリのコントロール

つらかったとこ

  • コンパイル遅い
    • Scalaよりは速い(というRust界定番の自虐?)
  • 一部ライブラリは未熟
  • 周りに書ける人がいない

Rustが適した分野

  • 安定性
  • 速さ

そのサーバー、三日前からRustだよ

なぜwantedlyでrust

  • マイクロサービス
  • 画像の処理
    • C++で書かれてた
    • 高負荷時に怪しい動き
    • rustで置き換える

Rustと3種のDSL

DSL

DSLを3つ作った

  • 権限チェック
  • API定義
    • マクロを使う
    • 使いすぎは注意
    • 第一級ではない
  • JSON Schema

「JSUG勉強会 2018年その4 Spring 5 & Spring Boot 2ハンズオン」に参加してきました

初めてでも30分で分かるSpring 5 & Spring Boot 2

Core

  • DI
  • Bean

Data

  • Spring Data JDBC
    • Spring JDBCのラッパー

Web

Security

  • 認証認可の設定
  • PasswordEncoder

Test

  • Spring5でJUnit5

Boot

  • AutoConfigulation
  • Starter
  • 組み込みサーバ入りFatJar

ハンズオン

「Meetup in Tokyo #39 Testing & Engineering」に参加してきました

イマドキのソフトウェアのテストやQAの考え方

労働のスケールアップから知のスケールアウト

  • 昭和の会社は労働で解決しようとする
    • なぜなぜをひたすらやる
      • 無駄
    • 人や金が指数関数的に膨れ上がる
    • 無理ゲーに重課金
  • 今時の会社は脳みそをスケールアウトさせる
  • QAは今時でもよくわかってない
    • 昭和の品質保証のやりかた?
    • テスト?

間違った戦略によるQAは失敗する

  • 個々の取り組みだけ頑張ってもそこしか成功しない、根付かない
  • 知のスケールアウトのための個別のアクティビティ(バズワード)に振り回されてないか?
    • アジャイル開発における品質保証やテストはどうするのか、と考えてるので答えがでない
  • 脳みそがスケールアウトするような品質保証戦略を立てるようにする
  • 正解がないので早く失敗させる必要がある
  • 今時の会社は、何を作ればいいか分かってて、どう作ればいいかわかってる人が、力を発揮できる環境にいるからアジャイルがうまくいく
    • スキルが。。とか違う前提を入れるからだめ
  • QAは議事録ではなく共感/納得をマネジメントする
  • ムリなものはムリ
    • 労働で解決するのは昭和の会社
  • 違和感をアンドン化する
    • おかしいと思ったらそこで進捗をとめて納得できるようにする
      • 実はバグでると思ってなかった?どうして言えない環境だったのか?
  • 成功するにはパラダイムシフトが重要
    • 理解してもらうまで説得して納得してもらう

AQUAフレームワーク

  • コンテキストに合わせたソフトウェアQA戦略を立案する
  • Acceslerating project
  • Qualifying value
  • Unveiling weakness
  • Accumulating knowledge

LINE のUI自動テスト事例

LINE Fukuoka

  • LINEの開発拠点は新宿、福岡、京都
  • 海外にも拠点がある

自動テスト事情

  • E2E UIテストに関する組織が最近できた

LINE Fukuokaのアーキテクチャ

  • Spring
  • maven
  • jenkins
  • seleium
    • selenide
    • appium
  • junit
  • 奇抜なことはやってない地味なことを地道に

LINE Storeの事例

  • Webのスタンプストア
  • 週一リリース
  • Dev,Staging,Releaseの3つの環境
  • 毎日一回全環境でテスト実行

An Agile Way As an SET at LINE

ミッション

  • LINEのSET舞台の立ち上げ
  • テストの自動化推進

遭遇した課題

  • 何すべきかわからない
  • テスト対象システムがわからない
  • 幅広い関係者の協力必要

何をすべきか見つけ出す

トライアル&エラーで高速に学習

  • 自動テストを活用したプロダクトの仕様設計の把握
  • 今動作するものが真実
  • Do Not Harm
  • 自動テスト->心理的安全性
  • SonarQubeで可視化

定期的に進捗と成果を見せる

  • インパクトを与え続ける
  • エンジニアに刺激を与えることでテストに関する意識が変わる

まとめ

  • まずは知ること
  • 協力者を集めること
  • 売上/利益/従業員満足
    • 楽天技術研究所の森さんから伝授
  • アジャイル知識/経験を活用してビジネスに貢献しよう!

「React Native Meetup #8」に参加してきました

ReactNative + Redux + NativeBaseでつくるサンプル実装をのぞく

現状の確認

ReactNativeの2018/6

6/2 FacebookがRNやめる?

  • FacebookがRNやめると噂が立ってるとtwitter
    • Facebookのコントリビュート減ってるんじゃないか
  • 中の人が否定
    • 大掛かりな変更してる

6/13 VueNative

  • VueNative on ReactNative on React

6/14 非同期レンダリング

  • RNの今後の方針発表
    • スレッドモデル変更してる
    • ブリッジの高速化簡素化
    • メジャーリリースの回数減らす
    • アプリ起動のパフォーマンスチューニング等ドキュメント整備する

6/20 AirbnbがRN撤退

TypeScriptでreact-native-i18nを型安全に扱う

RN-i18n-ts

expo縛りで旅アプリ&ハッカソン出場していく

  • @hiroga_cc

Expoで作った

  • 遠隔でも共有できる
  • すぐ動かせる
    • 直前までバグを直せる

デザインガイドラインを作るWebサービスを作っている話

React Promitives

使い所

  • デザイナーがSketchで作る
  • それをWebやNative作る人がimport

やってみて

  • 感想
    • 複雑なViewだと若干見た目に差異ある
    • デザイナーにReact書かせるのは酷
    • 型定義ファイルなくて不安
  • to Cでは不安かな

じゃあどこで使えそうか

  • 業務効率化ツール
  • デザイナーがGUIでできるから敷居が低い

「第69回 HTML5とか勉強会「UIフレームワーク最前線」」に参加してきました

Angular Ivyとその先

Ivy

  • もともとngiv
  • Angularの第三世代のViewエンジン
    • v2
    • v2-v4
    • Ivy

しくみ

  • 今まで
    • template html -> template data -> angular interpreter -> DOM
      • 3つめまでBuildで(AOT)
      • 全部Buildで(JIT)
  • ivyは
    • Template html -> template instruction -> DOM

生成物

  • 人にも読めるものになった
  • サイズも小さくなった

コンセプト

  • Smaller
    • 生成されたコードが小さい
    • 使われてないコードを消せる
  • Faster
    • ビルドが早くなる
  • Simpler
    • 生成されるコードが読みやすい
    • デバッグしやすい

Angular Elements

  • AngularコンポーネントをCustomElementsに変換する
    • AngularCoreも一緒に含まれる
    • AngularCoreが小さくなった恩恵を受けてる

Decorator-less Component

  • IvyでDecoratorなしでかけるようになる
  • Reactみたいに書けてくる
    • jsx to ivyとかできそう

まとめ

  • 次世代のAngularのViewエンジン
  • Small/Faster/Simpler

今後

  • Angular for Designers
    • google内部でコードGUIで生成してしまいたいという動きがある

Vue CLI v3

VueCLI v3

  • そろそろv3リリース

プラグインシステム

  • Vue CLI拡張機能
  • API
    • Service
      • webpack設定カスタマイズ
      • npm scriptに登録
    • Generator
      • テンプレート生成機能
      • 既存テンプレートカスタマイズ
    • Prompt
      • CLIの対話内容のカスタマイズ
  • ライブラリのScaffoldツールとして
  • プロジェクト固有のコード生成として

Vue CLI UI

  • CLIでできることは一通りできる
  • ESLintの設定とかPWAの設定とかもできる
  • プラグイン管理もできる

Suspense

Suspenseとは

  • 2018/2のjsconfで発表
  • 非同期の更新処理をうまく扱う機能
  • ページごとのローディングとか
    • すぐレスポンス来てるのに一瞬出たりとか
    • この辺ちゃんとやると大変

どう動くのか

simple cache provider

  • キャッシュのコンテナみたいなもの

Demo

その他

  • SSRでSuspense動かすとか
  • Apolloと連携できたりとか
  • Reduxとはどう組み合わせるかは今後注目
  • たぶんReact v17からデフォルトで使えるようになる
  • ほかはTimeSlicingとか
  • v17は2018年中予
  • 非同期周りが今開発してるところ

「ng-japan 2018」に参加してきました

Keynote

Momentum

  • Angular開発者1M超えた
  • 790+ worrldwide meetups
  • 530,000+ members

6.0.0

  • stability + innovation
  • cli
    • ng updateで関連のライブラリもアップデート
    • ng addで後からライブラリ追加
      • angular-materialとかng-bootstrapとかNativeScriptとか
    • ng generate
      • ng generate library
  • angular-elements
    • WebComponentsのcustom elements

Futuer

  • ivy
    • Smaller
    • Faster
    • Simpler
  • AngularComponents
    • 例えばReactとかVueの中にも入れられる
  • cdk
    • virtual scroll

AngularでPWAを進める

UXからみたPWA

PWA

  • Reliable Performance
  • OS-integrated experience
  • engage

モバイルとPC

  • 一覧性の欠如
  • ステップ数
  • 端末のheader/footer

キャッシュ

  • キャッシュはユーザに近いほどはやい
    • ネットワークが壁

通知

  • OSとか他のアプリとかと同じように出る

installable device

AngularのPWA

  • SPA + PWAで降るクライアントアプリ
  • @angular/service-worker
    • 実行モジュール
      • UIスレッドとやりとりする機能とかも
      • キャッシュ管理
      • swUpdate
  • @angular/pwa
    • コード生成の補助ツール
      • AppManifest生成
      • angular.jsonやAppModuleへ追加

ng buuildがキャッシュリソース

  • キャッシュの対象や期限をjsonに書く
  • strategy
    • performance
      • cache first
    • freshness
      • network first

今後

  • まずはbetter web app
    • serviceworkerを裏で動かしてるだけでも恩恵がある
  • installableはiPhoneが追いついていない

Angular活用実績から、ハマり事例のご紹介

  • Yutaka Shimizu(NRI)
  • 生産技術本部

NRIのAngular

  • 2015からAngularJSを使い始める
  • 2017頃から大規模プロジェクトでも使われ始める

NRIのアプリの特徴

  • 大規模(数100画面)
  • 中国オフショア開発
  • 品質への期待がある
    • 24/365
    • 画面へのこだわり
    • BtoCとは違った特性
      • SPAを長時間利用し続ける
      • 途中でエラーは許されない
      • 諸会議道の遅さは許容可能

事例1(役割分担失敗)

  • 従来は主力はJava
  • フロントエンド技術者が不足
  • フロントだけ別チームで

事例2(迷子の開発者)

  • 実装方法のバリエーションが多く迷う
  • 処理方式を事前に決めておかないと困る
  • コピペできるサンプルコード集

事例3(オフショア開発)

  • 5~10人くらいなら対面で教育できる
  • 100人を超えるメンバーをどう成長させるか
  • リーダーに研修してその研修をチームにやってもらう

事例4(メモリリーク)

  • SPA一日中使ってるとメモリリークする
  • SPAを分割
    • 途中でリロードさせる
  • リリークしやすい処理は共通部品を使わせる

大規模開発に打ち勝つためのマルチパラダイム

How we are using Angular + Firebase at NHK leading to the Olympics

NHKアーキテクチャ

  • 技術
    • AngularをNHKで使っている
    • Firebaseも使っている
    • CloudFireStoreも
    • CloudFunctionも
    • セキュリティ的に厳しい
  • インフラを中に持てない
  • リアルタイムにやりとりするのが難しかった
  • cloud functuinにjsonをアップロードしてる

Realtime data in VR

  • VR
    • 別の場所に連れて行ってくれるようなもの
    • oculusとか
  • AR
    • 現実を拡張
    • 3Dオブジェクトをデジタルでオーバーレイすることで実現
  • MR
    • VR + AR
    • HoloLens
  • XR
    • これらをまとめ言葉

XRやる上でのチャレンジ

  • Latency
    • 4Gだと40msのレイテンシ
    • XRだと20ms下回るのが理想
    • 5G最近出た2ms

Angular + WebVR

  • Angular6だとAngularとVRを別々に実装できる
  • ActionIndex
    • 360度のストリーミング
    • スポーツでのAR体験
    • リアルタイムデータによって実現

Angularで新サービス作って学んだこととか

Screenshot test in Angular

なぜSnapshotTest

  • viewのassertionしてても要件変わったらすぐ壊れる
  • 画像の比較ならかんたん!?

どうやってsnapshottest

  • 環境作るのとても面倒
  • 1度のPRで画像1000枚とかあげんのかと

コンポーネントをキャプチャしてテスト

  • Storybook
    • AngularCLI使ってる環境でも使えるようになった(Angular6,storybook4)
    • 自分でwebpack書かないから
  • Puppeteer
    • headless Chromium
    • storybook-chrome-screenshot
    • ひたすらキャプチャとってくれるやつ
    • storybookのaddon
  • reg-suit
    • 画像のassert

その他

  • Reactでも同じようなことやってる
  • ReactEuropでやってた

Protractor under the hood

ng e2eの裏側

  • Protractor
  • ながれ
    • HTTPServer立てる
      • AngularCLIが
    • Selenium動かす
      • Protractor
    • jasmine起動してassert
      • Protractor

AngularとPlantUMLを組み合わせ表現力を更に上げる

PlantUML

  • UMLを表現するための言語

内容

  • パワポやエクセルの設計書が多い
  • それをAngularアプリで置き換えたい

AngularアプリケーションにおけるCSS設計手法

CSS設計

  • BEM
  • SMACSS
  • OOCSS

なぜCSS設計必要

Angularでは

  • 従来のCSS設計はいらない
    • Component
    • ScopedCSS

AngularでのCSS設計

ComponentCSS

  • 一つのComponent専用

SharedCSS

  • 複数のComponentで使われる

GlobalCSS

  • 全てのComponentに適用されるCSS

どう使い分けるか

  • 基本はComponentCSS
  • SharedCSS、GlobalCSSはできるだけ使わない
  • 良いCSS設計は良いComponent設計

どう値を共通化するか

  • Sassを使おう
    • 変数
      • 色や数値などの値は変数にして名前をつける
      • 上書きは禁止
    • Mixin
      • まとまった単位のstyleを共通化するときはこっち
  • 名前を使えられることがメンテナブルになる

Creating Components Using Angular CDK

AngularCDK

  • Component Behaviors
  • Common Utilities

「Android Bazaar and Conference 2018 Spring」に参加してきました

知られざる IBM の今、デベロッパーとテクノロジーの交差点

  • 佐々木シモン(IBM)

IBMのやってること

Google I/O 2018 Over view

GoogleIO

  • 7000人
  • 3日間
  • 100セッション

AI

  • Gmail
    • 入力内容の予測
  • Google Photo
    • 画像の加工
  • Google Lens
    • カメラで写したものを検索
  • テキスト抽出
    • 写真でとったものの文字をコピーできる
  • ML Kit for Firebase

Android P

Kotlin

  • 全体の30%くらい
    • 満足度が高い
    • 増えてきてる
  • 去年の6倍

Destribute

  • apkのサイズが大きくなっていてる
    • 6Mあがるごとに1%ダウンロード率が下がる
  • Android App Bundle
    • アップデート時に差分だけダウンロード

Actions

Flutter

  • beta-3が出た

Web

  • chromeOSでLinux対応
  • Lighthouse3.0

Material

  • Materialっぽさ出すぎてしまうのを解消
  • 個性を出しやすいような機能
  • sketchと連携する機能
  • Material Component

VR/AR

  • Mapと連携
  • スマホかざすとどっちに行けばいいか表示される
  • 写ってるものを検索とか
  • 文字起こしとか
  • ARCore
  • CloudAnchors
    • AR空間の共有

Firebase

  • モバイルアプリ向けツール
    • 認証
    • ストレージ
  • ML Kit

PWA 集中勉強会総まとめ!既存サイトの「 PWA 化 」はこれでバッチリ!

PWA

  • ローカルにインストールされたアプリのような挙動
    • インストール
    • オフライン
    • Push通知のようなアプリライク
  • はじめてのプログレッシブアプリ

いいところ

  • アプリとWebのいいとこどり
  • はやい
    • 動作が速い
    • 導入が早い
  • うまい
    • アプリ
      • ホーム画面
      • 通知
      • バックグラウンド
    • Web
      • 検索に載る
      • 更新が容易
      • 多くのプラットフォーム
  • 安い
    • 導入コスト
    • 通信量

あらゆるプラットフォームへ

  • 対応するプラットフォーム
    • ここ数ヶ月で増加
  • safariの対応は日本でインパクト大
  • windows/Edge
    • ストアで配布できる
    • PWA Builder
    • bingがPWA収集して勝手にストアにあげる

デメリットは?

  • 既存サイトを毀損することはない
  • 使えない環境なら従来通り
  • 段階的な導入
    • 全部入れなくても良い
    • SPAでなくてもいい

関連API

  • まずどこでも大丈夫
    • indexedSB
    • cache
  • 要確認
    • background sync
    • push
    • payment
    • web auth

PWAの構成

  • html/css/js
  • manifest
  • ServiceWorker

ServiceWorker

  • イベントリスナー
    • install
    • activate
    • fetch
  • scopeに気をつける

Cache

  • Chacheの運用がPWAの肝
  • 目的
    • 高速化
    • ネットワーク節約
    • オフライン
  • 考慮点
    • 更新
    • 容量
  • 戦略
    • cache first
    • network first
    • no cache
  • API
    • match
    • add
    • put
    • delete
    • keys
  • 同期更新削除は自分で
    • activate時に古いものを削除

フレームワーク

  • PWA Builder
    • microsoft
    • ベースを作るためのもの
  • Workbox
    • google
    • 細かな制御をするためのもの

What is new in Kotlin

googleIOでのデモ

  • サンプルコードが31セッションの内23セッションはKotlin
  • Kotlinが標準
  • 2017
    • オフィシャルにサポート
  • 2018
    • 実質的に標準に

Android開発の標準言語としてのKotlin

  • Playストア上去年の6倍
  • 35%がKotlin
    • 増加傾向
  • AndroidDevelopersのドキュメントもKotlin版提供開始
  • Android KTX
    • Kotlinの拡張関数群
    • googleIOで1.0.0-alpha
  • AndroidKTXの例
  // before
  Uri.parse(url)
  // after
  url.toUri()
  ```

### この一年のアップデート

#### AndroidStudio3.0リリース

- Kotlinプラグインがデフォルトで入った
- Kotlinで開発開始できる
- JavaコードをKotlinに変換する機能

#### AndroidKotlinGuides

- AndroidをKotlinで書く際の指針
    - StyleGuide(Kotlinの書き方)
    - InteropGuide(Kotlin/Java相互運用ルール)

#### Kotlin1.2

- マルチプラットフォームプロジェクト
- コンパイルパフォーマンス25%向上

#### SupportLibraryへのNullable/NonNullアノテーション追加

- Javaのコードに追加していってる
- Kotlinの世界に入ってくるときに役立つ

### Kotlinをどう学ぶ

#### Kotlinの目指すところ

- Javaが使われている環境でより簡潔で生産性高く安全に使えるJavaの代替言語
- 実用主義
    - Javaの考え方
    - 他の言語でうまくいってるものを採用
- 簡潔
    - 読みやすさ重視
    - ボイラープレート削減
- 安全
    - 静的型付け
    - Null安全
- 相互運用性
    - JavaとKotlinの相互互換
    - ライブラリも既存のものを使える

#### 注意点

- 自由度が高い
    - StyleGuide
- 簡潔にしすぎると読みにくくなることも
- 原理な機能が自由度を高める
- まずはNull許容型/Null非許容型の区別に気をつける

#### 学び方

- オフィシャルサイト
    - Kotlin and Android
    - Kotlin Sample
- DroidKaigiアプリ
- Kotlinインアクション
    - Kotlin作った人が書いた本の訳
    - なぜそういう言語思想なのか

### まとめ

- KotlinはAndroid開発の標準言語
- 公式ドキュメントが充実
    - オフィシャルとしての対応が進んでいる
- Kotlinの思想をちゃんと知って始めよう

### サーバサイドKotlin

- FRESHはサーバKotlin
- 事例はたくさんある
- Springもオフィシャルサポート入ったはず

## Web アプリケーションフレームワークにおけるWeb開発の最適化

- 佐川夫美雄(アシラス株式会社)
- https://speakerdeck.com/albatrosary/3da-huremuwaku-angular-react-vue-dot-js-bi-jiao-niyoruentapuraizu-web-apurikesiyonkai-fa-falsezui-shi-hua
- http://albatrosary.hateblo.jp/entry/2018/06/10/204323

### WebApplication

- Webサイトとは違う?
    - 見るだけ
    - インタラクティブに使う
- 必要なもの
    - html/css/js
- SemanticWeb
    - 必要?
- CSS
    - 闇
    - スコープがない
    - ベンダープレフィックス

### プログラムを書きときに気にすること

- 可読性
- テスト
- 再利用性

#### コンポーネント

- Piece
    - Webの場合はコンポーネント
- コンポーネント化して小さくすればいいだけじゃない
    - AtomicDesignのようなものが必要
- デザイナーが作ったAtomicDesignをエンジニアがコンポーネント化

### WebComponents

- CustomElement
    - ピースに名前をつける
- HTMLTemplate
    - ピースの模様
- HTMLImport(ESModules)
    - ピースをパズルにはめる
- **ShadowDOM**
    - ピースであることを主張

#### どんなフレームワークを使うか

- ShadowDOMはまだ実装されてない
    - ScopedCSS
- ほしいのはJSFrameworkじゃないWebApplicationFW
- 大事なのはScopedCSSができるかどうか
    - Agular- ok
    - Vue - ok
    - React - めんどくさいからだけ
        - styled-componentsじゃだめなのか?

### まとめ

- Webアプリケーション開発はコンポーネント指向
- 開発効率をどれだけ上げられるか
- フロントエンドエンジニアこそクラウドサービスをマスターせよ

## デザインツール戦争とMaterial Theme Editor

- 山本麻美(フリーランス)

### 機能で考えるツール選び

- 主なUIデザインツール
    - sketch
    - Adobe XD
    - figma
    - InVisionStudio
- プロトタイピングツール
    - いろいろ
- 状況で判断しよう
    - アイデアを素早く視覚化したい
    - 複数デザイナーで進めたい
    - 開発チームにspecを共有したい
    - 画面遷移図がほしい
- spec
    - UI実装情報
    - レイアウト指示書
- 何でも良いではだめ
    - 課題に合わせて選択

#### 比較

- UIデザイン
    - sketchが抜群に優秀
        - 高度なComponent設計ができる
        - windows版はない
    - InVisionStudioはまだ正式版じゃない
- プロトタイピングツール
    - InVisionだけ進行管理ができる
        - でも多機能すぎて使いづらい
    - XD,Sketchはデザイナー視点だと楽で使いやすい
    - Prottはワイヤーフレーム作ったら画面遷移図もできる
- spec共有ツール
    - Zeplinが一番使いやすい
    - XDだと全部一貫してできるからやりやすい
        - まだbeta

#### ケーススタディ

##### ケース1

- 既存アプリを全面リニューアル
- 構成は決まってる
- 画面遷移図必要
- -> sketch,prott, zeplin

##### ケース2

- 新規プロジェクト
- デザイナーじゃないかも
- -> XDなら経験なくても使いやすい

##### ケース3

- デザイナー確保できない
- エンジニアだけでAndroidアプリ作りたい
- -> Sketch(MaterialThemeEditor)

### MaterialThemeEditorを使ってみた

- sketchはiosテンプレートは充実してる
    - androidは貧弱
    - androidテンプレート??
        - 違った
        - 動かすためにsketchを使ってる
            - それだけ完成度高いものだった
- sketchのポイント
    - Style
        - 要素の色とかサイズを設定する
    - Symbol
        - 要素の集合に対するStylee
    - Resizing
        - デバイスサイズ異なる場合の動き
        - 伸ばすのか固定7日
    - Library
        - 外部CSS的なもの
        - Symbolを複数ファイルで使い回せる

### まとめ

- ツール選びは適切に
- MaterialThemeEditorはsketchのプラグインといより動かすためにsketchを使ってる感じ
- 豊富なだけに探すのは大変
- 自由にカスタマイズするのには向かない気がする

## Flutterアプリ開発入門

- https://www.slideshare.net/kanbara/abc2018springflutter-101476556

「UIT#3 The “Backends for Frontends” sharing」に参加してきました

マイクロサービスの思想から捉える、Backends for Frontendsとその類似パターン

BFFとは

  • サーバ
  • Servers for Frontendのが実態に近い
  • Frontendにもサーバがほしいと
  • Frontend/Backend
  • Client/Server

なぜBFF

  • APIを合成する
  • microservices

マイクロサービス

  • 自律的なサービス
  • 独立したリリースサイクル

  • クライアントとサービス

    • モノリシック
      • n:1
    • マイクロサービス
      • n:m
  • 問題点
    • 様々なホストを知ってないといけなくなる
    • そこでAPIGateway
  • でもAPIGatewayにはロジック書きたくない
    • APIGatewayはバックエンドエンジニアの領域
    • APIGatewayいじったときにバックエンドいじらないといけないとかは嫌だ
  • そこでBFF
    • クライアント単位でBFFを立てる
    • BFFはフロントエンドが管理する

BFFの類似パターン

マイクロフロントエンド

  • UIもビジネス
  • バックエンドもフロントエンドもいる縦に切ったチーム
  • 実現のために
    • iframe?
    • WebComponents!
  • 課題

FOLIOのBFFと秩序の話

FOLIOのBFF

構成

  • バックエンド
    • マイクロサービス
  • BFF
    • PC用/モバイル用
  • フロントエンド
    • PC/モバイル

BFFのやってること

  • APIの集約
  • SSR
  • 認証/セッション管理
    • kong

BFFの良い話

  • BFFは外界に挟まれてる
  • フレームワークの依存の排除と型付け
    • swagger-to-flowtype
    • thrift2flow
  • 責務
    • BFFでできることはやる
    • 日付の計算
    • 数値の計算符号付け単位

BFFの辛い話

ダッシュボードでのSSR

  • ログイン直後の画面
  • コードがでかいし型がない
    • BFFで通信を束ねてでかいJSON返す
    • koaもJSONも型なし
  • 改善
    • 型付け
    • テスト
    • CIで落ちるようにする
    • 画面の側がリソースを取りに行く
      • 巨大なのをもらうわけではなく

まとめ

  • レイヤを分けよう
  • ユースケースを考えよう
  • スキーマと型を使っていこう
  • アグリゲーション対象が増えてからだと大変

merpay Frontend における BFF

メルペイのアーキテクチャ

  • Browser(Vue+Nuxt) - SSR(Node) - API(go)
  • SSRするサーバから見ても使いやすいように
    • goのAPIがBackend for BFF的な

BFF

NodeがAPIサーバを兼ねるかどうか

  • SSRするNodeがAPIへのエンドポイントをどう設計するのか

なぜBFFを導入しなかったのか

会社ページリニューアル

課題

  • 共通パーツをどうするか
  • SSRしたいのは一部のページだけ
  • 既存のページはいじりたくない

もともとやりたかったこと

  • SSR
    • ユーザ体験向上とSEO
  • Aggregate data
    • 既存のRESTfulAPIを使いたかった

どうしたか

  • BFFやめた
  • Hypernova入れた
    • AirbnbSSRするNodeのサーバ
    • データを投げるとHTMLにしてくれる

まとめ

  • SSRしたいだけならBFF必須じゃない
  • 疎結合を意識して少しずつ

LINEとBFFの話

LINEのフロントエンド

LINEのBFF

  • なれてるプロセスを破壊しないか
    • この破壊は改善だと広めないといけない
  • Vue+Nuxt/React+Next

BFFがないと

  • テンプレートがサーバにあるため責任が不明確
    • 問い合わせがサーバ側に
    • サーバ側が修正し始めるとつらくなる
  • フロントエンドの修正だけでもサーバ配信が必要

BFFあると

  • 責務が明確
    • サーバ:データ処理
    • フロントエンド:その他

課題

パフォーマンス

  • 物理的速さ
    • Node
    • DataFetch
      • 内部ネットワークだとRTT1桁くらい
  • 心理的速さ
    • FirstMeaningfulPaint

BFFを入れる

  • いいものを作らないといけない
  • 計測すること
  • 責任を明確にすること

まとめ

  • BFFはいいけどそれだけじゃ進まないことも
  • 責任が偏らないように

BFFアンチパターン

2年間やってみて陥ったアンチパターン

  • BFFはフロントエンドとバックエンドの架け橋
    • 関わる人が多い

スパースコミュニケーション

  • BFFはアーキテクチャどうしが疎になる
    • コミュニケーションまで疎になってしまう
  • select分そのまま見える
    • joinの結果がそのまま見える
  • n+1クエリ
    • リクエスト何度もなげる
  • マイクロサービスだからといってAPIを簡素にしていい訳じゃない
    • バックエンド
    • フロントエンド
      • どういうAPIがほしいか言わないと
    • 関係は対等だからコミュニケーションとらないと
  • リクルートでは

インフラレスポンシビリティ

  • BFF誰が面倒見るの
    • 全員

ビッグバンジョイント

  • 最後の最後にフロントバック結合すると死ぬ
  • APIのリクエスト/レスポンスは想定通りじゃない
  • 確実に想定外の問題は起きる
    • リクエストの型
    • statusコード
  • リクルートでは
    • Agreed+proxy
    • できたAPIから本物をつなぐ
    • フロントが先行して作っていく必要ある

まとめ

  • アーキテクチャは疎にしてもコミュニケーションは疎にしてはいけない
  • インフラを見るのはバックエンドだけではない全員で見る必要がある
  • 最後の最後に結合ではなく徐々に結合
  • DevOpsのようにフロントエンドバックエンド

「ReactとAtomicDesignからみるコンポーネント開発」に参加してきました

コンポーネント開発で変わったフロントエンドとrecompose

  • 石橋啓太
  • DMM.com クリプトマイニング開発部
  • @usagi-f
  • 本書いた人(React開発現場の教科書)

フロントエンドの今昔

  • モノリシック
    • サーバ側にView実装
    • jQuery
    • JSでDOM組み立て
  • マイクロサービス

ターニングポイント

  • レンダリングアルゴリズム
    • UIを宣言的に実装
    • Diff Patch
    • DOMツリーと状態の分離
  • HTMLの組み立てから状態をどう管理するかに変わった
    • 複雑な設計がしやすくなりできることが広がった
    • UNIX哲学の適用
      • 小さいは美しい
    • 宣言的な実装は再現性高い
  • 空中戦から戦略戦へ

React + Atomic Design

React

  • UI構築を抽象化
  • 宣言的関数実装
  • 小さく作って組み合わせる思想
    • 副作用はどうする
    • 責務の分離
  • DOMの書き換えはReactに隠蔽される
    • UIの構築に注力できる

AtomicDesign

  • UIを分類して定義付け
  • UIデザインも含めて設計できる
  • 全てを準拠させるようなものではない
  • デザイナーとエンジニアのコミュニケーションがしやすくなる

higher order component

  • HOC
    • 関数を引数にとって関数を返す関数
// 副作用が逃げる
const withSome = (component) => {
  return {
  }
}
const Button = (props) => <button>{props.label}</burron>
const NewButton = () => withSome(Button)

recompose

  • recompose
    • reactが用意してるもの
  • UIコンポーネントから余計な実装を省きやすい
  • 再利用性が高まる
  • AtomicDesignにも準拠しやすくなる

まとめ

  • コンポーネント開発が普及しそう
    • WebComponents
    • react-native-dom
    • material-ui
    • Polymer
      • lit-html
    • preact
    • alibaba/rax

Alternative Atomic Designをさがして(仮)

AtomicDesignおさらい

  • ページやインターフェイスに含まれる要素を5段階で構成した
  • それを組み合わせることでアプリを作る

5要素

  • Atoms
    • それ以上分解できない
  • Molecules
    • 一つのことをうまくできること
  • Organisms
  • Template
  • Pages

AtomicDesignへの疑問

  • Atomsからほんとに作れるの?
  • MoleculesとOrganismsの違いがわからない

Alternative Atomic Design

  • 作者
    • AtomicDesignは厳格に守るものではない

GE

Futuerlearn

  • MoleculesとOrganismsの違いがわからない
  • 分ける必要あるのか
  • helpers
    • それ単体で意味をなさないもの
  • standalone
    • それ単体で独立したコンテンツ

Lewis ...

  • 用語が混乱を招く

Airbnb DLS

Back...

  • 楽譜からメタファーを持ってきた
    • ハーモニー
    • メロディー
    • リズム

まとめ

  • MoleculesとOrganismsの違いにみんな悩んでる
  • 化学用語馴染みづらい
  • チームに合った構造を試してる

React360でVR

React360とは

  • 3DとVRのUIフレームワーク
  • ReactVRから改名した
    • Web実装とOculus実装を分けた
    • Web版がReact360
  • メリット
    • Reactの考え方でVRのUIを構築可能
  • GetStarted

      yarn add react-360-cli
      react-360 init sample
      cd sample && yarn start
    
  • コンポーネントはRNっぽい

    • ViewとかTextとか
    • AppRegistryとか

アーキテクチャ

  • Main Thread
  • Executer
    • React App
    • RN

トークセッション

  • atomsから作っていくスタイルは合わないことが多い
    • プロジェクトの性質による
    • 諸届はあってると思う
  • デザイナーがいるかどうか
  • UIライブラリを使うかどうか
  • material-uiみたいな公開されたデザインシステムの構成だけ使いたい見た目は自分で作りたい
    • スマホアプリならAndroidはmaterial-designがベースとかなってるから乗っかりやすい
    • Webは自由だから悩みどころ

「Web Working Group 「PWAに備える3ヶ月」 vol.3」に参加してきました

Cache 自由自在

PWAの動作

  • SWがオンラインコンテンツとキャッシュの仲介

キャッシュをどう使うか

  • なぜキャッシュ
    • 高速化
    • ネットワーク節約
    • オフライン対応
  • 考慮点
  • 3パターン
    • cache first
    • network first
    • no cache

CacheAPI

  • API
    • match/matchAll
    • add/addAll
    • put
    • delete
    • keys
  • 有効期限はない
  • 適用例
    • SPA
      • AppShellとそれ以外が分かれてシンプルな設計
    • 従来型SSR
      • 固定コンテンツとそれ以外の制御

キャッシュの削除

  • Activate時に削除する
  • 更新タイミング
    • SWはオンライン時に同期次回起動時に更新されたものが動作
    • Cacheは明示的に更新するかSWのActivate時に削除しないとだめ
  • 対策
    • IndexedDBにタイムスタンプとURL記録
    • Workboxのexpiration.Plugin
      • PWAライブラリで有効期限的なのはこれ以外みない

PWAフレームワーク

PWA Builder

Workbox

  • google
  • オフラインサポートのためのライブラリ
  • ライブラリのjsを読み込むようにする
  • キャッシュするURLを正規表現とかで指定できる
  • プラグインもいろいろ
    • キャッシュの有効期限も指定可

総称

  • 2つを組み合わせると便利
    • PWA builderで原型つくる
    • Workboxで細かいところを

今から開発できる、Progressive Web Apps

PWAとは

  • 2015/11のChrome Dev Summit
    • もともとはGoogleの人のブログ記事
  • クライアントの性能に合わせた機能
    • IEなら従来通りとかってこと
  • これまでWebになかった機能
    • オフライン
    • プッシュ通知
    • バックグラウンド所為r
    • アイコンの追加
  • これらは新しいAPIが追加された
    • SW
    • Web App Manifest
  • Webのメリット
    • SLICE
    • FIRE

PWAのメリット

  • ServiceWorker
    • バックグラウンドで動作するプログラミング可能なネットワークプロキシ
  • 既存のWebページに後付でもいける
    • sw.jsとそれを登録する崇敬
  • 何をキャッシュ
    • AppShell
      • UIが機能するために必要最小限のリソース
      • 要件にあったアセット
      • モバイルの場合ストレージ圧迫してしまうから注意
    • SWの更新
      • キャッシュは消えない
  • 開発中にキャッシュしちゃうと反映されなくて面倒なので注意

PWA for windows

PWA位置づけ

  • Nativeを置き換えるものではない
  • 今までWebViewで十分だったってものならはまるかも

まとめ

  • ServiceWorker
  • Web App Manifest
  • 各種API

PWA化するときのUIとスコープの設計について

PWA対応してみた知見の話

  • 多言語対応
  • 一部分だけ多く使われるサイト
    • 戦略としてSWのスコープを調整した
  • インストールされて使われてる場合は〜とか場合分けすると大変
    • start_urlのクエリを見て〜って感じで頑張る
  • エンゲージメント
    • 初回アクセスのユーザとリピータは使い方が違う
    • それを考えた上でstart_urlを決める
  • SPAでないとページにアクセスしないとキャッシュできない
    • SPAだと一発でまとめて
  • オフラインのときはオフラインであることが分かるような画面を出してあげる
    • キャッシュしておいたコンテンツで誤解を与えたりしてしまわないように
  • OS差の対応
    • ホームアイコン
    • スプラッシュはAndroidだけ
    • ローディングアニメーション
      • スプラッシュのあとにローディング画面出すものとか
      • アプリあがりますよってのを2回出してるみたいになる
    • iOSでのブラウザバック
      • 戻るを置くか遷移できるわかりやすいメニューを用意
    • Basic認証

重要だと思ったこと

  • 誰向けのPWAなのか
    • エンゲージ指数が閾値を超えたユーザへのおもてなし
    • 有益な体験とは何なのか考えて
    • 初回ユーザ向けではないのでは?
      • コンテンツでエンゲージを上げた上での+α

使い所

  • 社用スマホ
    • 事前にホーム画面追加
  • イベントタイムテーブル
  • ポートフォリオ/ギャラリー
  • イベントタイムテーブル

注意点

  • iOSとかトラブル起きがち
    • 公開する前に確認しておくこと

「RLS Meetup#9 リクルートライフスタイルのフロントエンドのいまとこれから」に参加してきました

フロントエンドFW戦争を乗り越え、デザインシステムを導入した話

  • 中村 芳弘
  • Air事業
  • AirREGI

Airシリーズのフロントエンド

  • 2016年にできた
    • Backboneとかもあった
  • 技術スタックを揃えたい
    • reactに
  • エンジニアだけでは決められない
    • ビジネスサイドに説明しないといけない

ビジネスサイドへの説明

  • Why
    • 独自FW人材確保できない
    • Backbone(なぞ設計)
      • 機能追加の工数大影響でかい
  • How
    • jsp -> spa
      • 改修の入った画面から徐々に
    • Backbone
      • 大規模改修で一気に
  • jQueryもちょっと残ってて戦ってる

デザインシステムの導入

  • 再利用可
  • 自動化

プロダクトへの導入

  • UXの統一
  • デザイン向上
  • 生産性向上
  • ライブラリ
    • styled-component
    • storybook

効果

  • これってこれでいいですかね?という確認時間をカット
    • storybookでパーツごとに作ってるから共有しやすい

レガシーと向き合い技術スタックを代謝する(ElasticBeanstalk / Vue.js)

レガシーシステム

  • jQueryでできてる
  • jQuery + lodash.template + morphdom
  • MVVM
  • grunt -> gulp -> webpack
  • ava, sinon, nightmareでUI差分
  • codecov
  • sentry
    • エラー即時検知
    • 障害起点の調査

新規案件での取り組み

新規機能3つ追加

  • 学習コスト(初動)からReactでなくVue
    • Vue + vue-router
    • eslint, prettier
      • フォーマットの無駄な議論削減
  • 仕様を決めながらだけど素早くできた
    • 画面と機能の分離
  • 反省点

インフラの取り組み

  • jsonのモックAPIサーバ構築
  • beanstalk
    • node + express
  • デプロイ戦略

フロントエンドのレガシー

  • 非機能要件での差
    • 競合他社との比較
  • エンジニアとしての評価
    • 社外から見た時の評価
    • 古い技術

Nuxt.jsとExpressでSPA×SSR×API Aggregationを実現した話

じゃらん

  • jsp
  • 何十年前からあるシステム
  • レガシーと新規の連携
  • 負債にならないシステムを

マイクロサービス

  • API Aggregationサーバ
    • BFF的な?
    • nuxtとexpressで
      • SSRする
      • expressでワンクッション
  • nuxtフルスタックで便利
    • 今後のPWA化もすぐできそう
    • 内部でいろいろ使ってるのでデバッグでnuxtの中も見ないと・・・という点も
  • SPA + SSR + API Aggregationを同じサーバにしてしまった
    • 今後でかくなる懸念
    • 別管理した方がいいかも

地に足をつけたフロントエンドの改善

ホットペーパービューティー

  • 売上数百億開発者数百人
  • 10年物の負債
  • 事業は成長し続けている
    • 事業側からの機能要望が多い
    • デリバリー重視で負債がたまる
  • 負債
    • グローバル汚染によるバグ
    • htmlタグ数が多すぎてレスポンス悪化
  • before
    • 静的解析フォーマッタなし
    • jsp
    • !importが1590個
    • minifyすらされてない
  • 改善
    • ビルドフロー整備
      • minifyもする
      • jenkins使う
    • DOM構造のリニューアル
      • 機能毎にモジュール分割
        • 大規模リプレイス中
      • 見た目似てるのにどう共通化するか
        • デプロイサイクル

「We Are JavaScripters! @18th」に参加してきました

Nuxt.jsでSSR

  • @comuttun
  • 都内の某メルマガの会社

レガシーな社内システム

  • 日時のバッチで13万枚のhtml作成
  • vue + Nuxt
    • Reactはjsxが無理な気がした
    • Angularは部分的に適用はつらそう
    • Vueは日本語ドキュメント豊富で周りの人も入りやすい
  • 現状のテンプレートを地道にVue化

ブラウザからカメラを呼び出し手書きのサインを読み取って認証するぞ

ステッカー作ろうとした

  • ステッカーを会員証に
    • 手書きで名前書いてもらう
  • 写真をとることでチェックイン
  • 知り合いがいるか分かったりとか

カメラ呼び出し

  • MediaDevice.getUserMedia
  • カメラ呼び出し
  • ios11から

画像解析

  • OpenCV
  • もとはC#
  • 二階調化
  • 輪郭検出
  • 透視変換
  • 画像認識できてもそれのマッチングが難しい

1日一つ強くなる戦略としての UCDDD (Udemy Course Development Driven Development)

Udemy

  • 説明しながらコードを作るととても身につく

CodeSandbox

メロンのはなし(仮)

melon.js

ゲームを作る

  • ボイラープレートがある

いいところ

  • 環境構築楽
  • デプロイ楽

「LP完成しました!お問い合わせメールの繋ぎ込みだけお願いします!」なんて二度と言いたくないのでhtmlとjsだけでお問い合わせメール送信機能を作った話

問い合わせフォーム

  • そんだけのためにわざわざサーバたてたくない
  • フロントの技術だけでなんとかしたい
  • Google AppScritを使うと簡単
    • GmailApp.sendEmailなんていうメソッドもある

reduxはいらないかもしれないし、context APIもあんまり使わなくていいかもしれない

reduxいらない?

ContextAPIいらない?

  • 作者が言ってる
  • レアケースだから使うシーンあんまない
  • バケツリレーの代わりにそこかしこで使うものではない
    • reduxの代わりになるものではない
  • 多言語対応とか・・・
    • 他思いつかない・・

おまけ

  • バケツリレー大変とredux作者にきいた
    • render porps
    • ContextAPIはアプリケーションコードでは使わないと思う

おまけ2

.mjs

Node.js v10リリース

  • mjsも入ってる
  • privateも使えるようになる

mjs

  • import/exportをbundlerなしで使えるようになる
  • moduleのm
  • moduleとscriptは違う
  • module
    • デフォルトでstrictモード
    • トップレベルスコープ
    • awaitが予約後
  • moduleかscriptか拡張子をみて最初に振り分けられる
    • simpleが速い
  • custom loaderを使えばjsのままでもつかえる
  • mjs人気ない使い方変わるかも