「Meguro.es #17」に参加してきました

  • Meguro.es #17に参加してきました。
  • 初参加でしたが幅広い分野で初めて知ることも多く勉強になりました!
  • さっそく試してみたいと思える話もありとても有意義でした!

meguroes.connpass.com

タイトル 発表者
10分でわかるReact fire kdnk
ゼロから学ぶWeb Authentication API kobayang
React.js の render-props と Function as child の紹介 mori-dev
Caching Data Apollo Client takanori_oki_9
DoczをPJに入れてみた mki_skt
Diagnoses your Node.js app (intro) darai0512
  • 以下メモ書きです

10分でわかるReact

  • firekdnkさん

React Fire

背景

  • ReactDOMの近代化
  • Reactv17に入る???
  • issue#13525

github.com

概要

  • 新機能というよりは既存機能をよりわかりやすくするもの
  • nativeの挙動に合わせることで思わぬバグを減らす

input value

  • inputのvalue属性に反映させるのをやめる
  • propertyとattrは違う
    • propはjs
    • attrはhtml

attach events

  • イベントをdocumentじゃなくてReactのRootにattachするようにする

onChange -> onInput

  • onChangeをやめてonInputに変える
  • 理想的にはevent.targetを使いたくない

イベントシステムをシンプルに

  • 独自のイベントシステムをDOMのイベントに近づける
  • イベント周りで不要なものが入ってるからReactDOMのバンドルサイズが大きい

className -> class

  • classNameがclassに変わる

ゼロから学ぶWeb Authentication API

  • kobayangさん

Motivation

  • chrome70からmacでwebの指紋認証できるようになる
  • Web Authentication APIを使ってるらしい

Web Authentication API

  • Credential Management APIの拡張

Credential Management API

  • ログインフローをシンプルにするAPI

処理の流れ

Registration Phase

  • navigator.credentials.store
    • 引数で渡した認証情報を保存する

Authentication Phase

  • navigator.credentials.get
    • 保存した情報を取得する

Web Authentication APIに仕組み

  • Authnticatorを呼んで暗号鍵認証できる

参考記事

blog.jxck.io

React.js の render-props と Function as child の紹介

  • mori-devさん

きっかけ

  • HOCを使っていた
  • render-propsを使うともっと良いというブログを読んだ

親から子へコンポーネントを渡す

  • jsxタグの属性で渡す
  • 文字列でもオブジェクトでも関数でも渡せる
  • コンポーネントを返す関数も渡せる
  • コンポーネントそのものも渡せる
  • childrenという属性名だ渡す場合は<Child children={xxx} /><Child>{xxx}</Child>が同じ

Caching Data Apollo Client

  • takanori_oki_9さん

Apollo Client

  • GraphQLサーバにアクセスするクライアントサイドライブラリ

Apollo Link

  • Client - Link(URLセット) - Link(Tokenセット) - Server
  • Linkはミドルウェアみたいなもの

apollo-cache-inmemory

  • ApolloClientデフォルトのキャッシュ
    • ReduxのStore的な
    • APIをアグリゲートするところでReduxのStore使わなくて良くなる

InMemoryCache

  • アクセスするときはGraphQLのクエリを投げる
  • ローカルのキャッシュを柔軟にいじれて便利
    • オフライン対応で役立つ

DoczをPJに入れてみた

  • mki_sktさん

Doczとは

www.docz.site

Docz導入

上手くいかなかったこと

  • ゼロコンフィグの条件がある
    • webpackv4であること
    • babelv7であること
  • cssが反映されない
    • css in js使ってないと一手間いる

まとめ

  • コンポーネントガイドだけほしいなら選択肢としてあり
  • ShapshotTestとかしたいならStorybookで

Diagnoses your Node.js app (intro)

  • darai0512さん

Node Summit 2018

www.nodesummit.com

  • サンフランシスコ
  • $660
  • 3日間
  • 1000人くらい(うち日本人6人)
  • nodeのコミッターがたくさん参加してる

Diagnose

  • Monitoring
    • モニタリングして問題を察知
  • Profiling
    • プロファイリングをとる
  • Tracing
    • stack-trace
    • AsyncHooks
    • プラットフォームに非依存なv8トレーシングを目指してる

「2018年9月定例会「ABC直前スペシャル PPP」」に参加してきました

  • 2018年9月定例会「ABC直前スペシャル PPP」に参加してきました

japan-android-group.connpass.com

  • 来月のABCに向けた直前イベントということで参加しました。AndroidエンジニアではありませんがPWAが気になるところです!

ABC 2018 Autumn in Kawasaki

  • 杉山 由朗さん@ABC 2018 Autumn in Kawasaki 実行委員長

ABC 2018 Autumn

abc.android-group.jp

  • 10/13(土)に開催
  • 今回はハンズオン多め
    • PWA, XR, etc
  • 場所は川崎振興会館
    • 川崎駅から雨でも濡れない

1つ目の「P」:Android Pieの新機能紹介 最適化されていくユーザー体験

  • 杉本 哲さん@日本Androidの会 運営委員

Project Treble

  • 早い段階でPieが利用できるようになる
    • ベンダー実装とOSシステム部分を切り離すことで実現
    • 同一のベンダー実装で新しいバージョンに上げられる

AI

  • AIによるサジェスチョン

Adjust Less

  • 様々なシーン(場所・時間・明るさ)で明るさを自動調整

Scroll Less

  • Digital Wellbeing: デジタル幸福
  • アプリの利用状況を分解しダッシュボードで表示
  • アプリの時間制限を設定できる

Charge Less

  • 頻繁に使うアプリを監視し使ってないアプリを抑制
    • バッテリーの持ちがよくなる
    • 通知はちょっと遅くなる

Tap Less

  • Slices
  • App Actions
  • タブ切り替えたりしなくてもすぐに実行できるようになる

New Navigation

  • iosのような感じ
    • 適用するかは設定で切り替えられる

Slices

developer.android.com

  • UIのテンプレートがある程度用意されてる
  • AndroidStudio3.2以降から使えるようになる
  • サンプルは公式から辿れるgithubにいろいろある

2つ目の「P」:Challenge PWA!! Web の舞台はホーム画面へ進撃する !

PWAおさらい

  • ざっくり言うとWebアプリがローカルアプリになる!
  • ServiceWorker + CacheAPI
  • アプリに向いたものとWebに向いたものの中間を埋めるものになるのでは

モバイルにおけるWebの存在

  • 入り口は検索かSNSが多いのでは
  • PWAによってWebの幅が広がるのでは

WordPressをPWAに

  • SPAじゃない
  • サーバサイドで埋め込まれたデータ

悩みどころ

  • 急がないけど更新を反映したい
  • 即時に反映したい
  • どこをどうキャッシュするか

キャッシュの更新タイミング

  • swはオンライン時に動悸し次回起動で更新されたものが動作
  • Cacheは明示的に更新するかActivate時に削除が一般的

キャッシュの目的

  • 高速化
  • ネットワーク節約
  • オフライン

キャッシュ戦略

  • Cache first
  • Network first
  • No Cache
    • オフラインページだけキャッシュ

PWA4WP

wordpress.org

  • いけてるところ
    • キャッシュの有効期限が設定できる
    • キャッシュの除外が柔軟に指定できる
  • 使い方
    • プラグインとして追加
    • アイコンとかmanifestの内容をGUIから指定できる
      • Cache戦略も選べる
      • フルスクリーンにするならiPhoneで戻れなくならないように注意
  • ソース

github.com

まとめ

  • キャッシュの制御がとても大事
  • いきなり完成形は難しいのでProgressive

3つ目の「P」:登壇者の皆様と参加者の皆様でディスカッション

Pixel3

Pixelに期待してること

  • 技適が通ること
  • ロックダウンモード
  • ノッチどうなるの
  • でかい画面もいいかも

「UIT#4 Web in App ネイティブアプリケーションのように振る舞うウェブ」に参加してきました

  • UIT#4に参加してきました。

uit.connpass.com

  • 裏番組(これとかこれ)も気になりましたが、自分的にPWAが最近ホットなのでこちらのイベントに参加してみました。
タイトル 発表者
社内向けサービスを@nuxtjs/pwaでお手軽にdesktop PWA化したら結構よかった話 @kawasako
RNとreactの共有ロジックをmonorepoでつくる @yamatatsu
ページ遷移Animation & Skeleton screenをWebViewアプリに実装した体験談 @shoyo.kyo
デザインと仕様に負けないWeb in Appの作り方 @Jun
  • 以下メモ書きです。

社内向けサービスを@nuxtjs/pwaでお手軽にdesktop PWA化したら結構よかった話

  • @kawasakoさん(LINE)

Desktop PWA

  • Chrome67から使えるようになった
    • chrome://flags/でflagをonにすると使える
  • twitterとかqiitaとかが対応してる
  • 独立したWindowがアドレスバーなしで立ち上がる!

社内アプリ

アーキテクチャ

  • @nuxtjs/pwa
  • workboxも使ってる
    • workboxに渡したswのコードを見るにはnpm run buildしないと反映されない...
      • devではworkboxのswではなく別のを使うようにした
  • web pushも入れてる
    • WebSocket経由で通知をswに渡す

まとめ

  • 一般向けにはまだ厳しそう
    • 社内向けなら試せるからいいかも
  • PWAの定義は曖昧だけど今回作った程度のDesktopPWAならお手軽

RNとreactの共有ロジックをmonorepoでつくる

  • @yamatatsuさん(CureApp)

monorepo

ページ遷移Animation & Skeleton screenをWebViewアプリに実装した体験談

  • @shoyo.kyoさん(LINE)

LINEのフロントエンド

  • WebViewもけっこう使ってる
  • LINEポイント
    • VueでSkelton screenに作り変えた

LINEポイント

  • 生誕5周年
  • WebViewでできてる
  • 積極的にリファクタしてる
  • スパイクアクセスあり
  • 小規模SPAの集合

Skeleton screenを使ったきっかけ

  • SPA化の要望あり
    • +αもほしい
    • LINE漫画でスムーズなページ遷移
      • Skeleton screen + React
      • これをやることに -> 体感速度向上施策

Skeleton screenを入れた効果

実装

  • 美しさ重視で
  • コンテンツが出るエリアをグレーのエリアで最初出す
    • データの内容によっては行数が変わったりしてがたっとなってしまう
    • がたっとなるとこもアニメーションで

課題

  • GPU, CPU使いすぎ
  • ページ切り替えた瞬間に使用率上がる

デザインと仕様に負けないWeb in Appの作り方

  • @Junさん(LINE)

デザインと仕様に負けないエンジニア

  • デザインと仕様に負ける
    • このデザインは作りたくないな
    • この仕様通りに作りたくないな
  • 辛いとは
    • 人ができないことをしなきゃいけない時苦しむ
    • プログラマが頑張っても同しようもない領域
      • ブラウザ/OSの制約

Web in App

  • Webの辛さとAppの辛さ両方味わえる
  • App的なデザインや仕様 + Webの制約

負けない方法

  • 戦わなければ負けない
  • デザインと仕様の段階でWebと合わないと切る
    • 代替は提案できないとだめ

まとめ

  • 開発者が苦しむといいプロダクトはできない
    • チームの皆がハッピーになれないと良いものはできない
  • 快適な開発が快適なUXにつながる

「CTO meet up〜JavaScript(Angular,React,Vue)〜」に参加してきました

  • CTO meet up〜JavaScript(Angular,React,Vue)〜に参加してきました

flexy.connpass.com

flxy.jp

  • 以下パネルディスカッションのメモです

JavaScript(Angular,React,Vue)進化しつづける技術について

どうやって技術選定してる?

林さん

  • 最近はAngularとReact使った
  • Angularは管理画面
    • CRUDが多いから
    • ライブラリ選定する時間もなかったから
  • Reactはvmeets
    • WebRTCとのやりとりやりやすいから
  • 3rdパーティのライブラリの量が一つの指針
    • 以下に早く作るかを重視してるから
  • ReactでもTS使ってる
    • Redux使ってるとTSの恩恵大きい
    • ビルドで気付ける
  • 3rdパーティで型定義ちゃんとしてないやつはanyにしちゃう
    • そのうち切り離したいようなものだから
  • AngularのVUPに合わせてライブラリVUP

古川さん

  • 3年前に技術選定してReactを選択
    • 主流になってきていた
    • Reduxも採用
    • たまたまうまくいったからそのまま継続している
  • ある程度の規模を想定して一度作ってしまう
    • ホットペッパー相当のものを作った
    • 当時はReact一択だったから他は試してない
  • 世の中で使われてるかどうかは見る
  • Flow使ってる
    • 80%くらい嬉しいけど20%くらいつらい
    • 3rdパーティのライブラリで型定義されてないとか
      • 3rdパーティのライブラリの型定義が間違ってると最悪
    • 開発体験としてあんまりうれしくない
    • 3rdパーティこそ型ちゃんとしててほしい信頼ならないから
  • greenkeeper使ってる
  • 改善day設けてそこでライブラリアップデートしてる
    • バージョン追従できてるのとできてないのもある

菅原さん

  • 2年前入社時はBackboneだった
  • 1ヶ月でios/android
    • ReactNativeで高速に
    • mobXを採用(Vuexに似てたから)
  • エディタの対応書き心地の良さ
  • 3rdパーティライブラリで悩まされるの嫌だから自前でやってしまう

今の技術の課題・解決方法

林さん

古川さん

  • エコシステムのライフサイクルが短すぎる(特にReact周り)
    • ついていけないとReactやめていっちゃうんじゃないか
  • 従来の技術でなくSPAを作ってるのはパフォーマンスがモチベーションにあるから
    • だからパフォーマンスが悪いSPAだと本末転倒なんじゃないか

菅原さん

  • チャートとか作ろうとすると仮想DOMが邪魔になってしまうこともある
    • それをガリガリやってくれるエンジニアも貴重
  • コンポーネント単位の差分レンダリングmobXだとできるけど追いかけるのつらい

これからのフロントエンドのトレンド・動向を教えて

林さん

  • WebComponents
    • WebComponentsでCSSのスコープができることがいい
      • 今も実現できてる
      • それを使ってビジネスにプラスになるか?薄い
  • WebRTC
    • 最近使えるレベルになってきた
    • SPAでもリアルタイム通信が当たり前になってくるんじゃないか

古川さん

  • WebComponentsに夢を見る?
    • 見ない
    • パフォーマンス速くなると思えない
    • パフォーマンス悪いと本末転倒
    • チューニングしなくてもそこそこ速いのはできるようになるかも
  • PWAは?
    • オフラインで嬉しいアプリだったりそうでないアプリだったり
    • ホットペッパーは予約できるか見ないと意味ない
    • ServiceWorker使うという意味では必要
  • 投機的先読み
    • guess.js
    • ga使って先読み

菅原さん

今、現場に最もほしいフロントエンドエンジニアとは?

林さん

  • 技術+αで何か持ってる人
    • 技術+技術ではなくビジネス的要素とか
  • フロントエンドエンジニアになりたい人に向けて
    • 作って人に見てもらうことが経験値になる
      • 徹底的に悩むこと
  • デザインとJS両方やらせるか?
    • マネジメント視点では適材適所
    • 1エンジニア視点だと知れるものは吸収した方がいい
    • JSエンジニアでも最低限のデザインは知っておくべき
  • フロントエンドエンジニアのキャリアパス
    • 技術以外も含めて+1が求められる
    • nativeとweb両方できるとコンスタントに生きていける

古川さん

  • フレームワークの奥で何やってるか調べられる人
  • フロントエンドエンジニアになりたい人に向けて
    • 自分の中ではこうしたいのにうまくいかず悩む時間を経験することが重要
  • デザインとJS両方やらせるか?
    • どちらかが得意であってもいいが無関心であってはいけない
    • 垣根がないものとしてできないといけない
  • フロントエンドエンジニアのキャリアパス

菅原さん

  • フレームワークに関係なく能力の高いエンジニア
    • インタラクションを作るエンジニアが希少
  • フロントエンドエンジニアになりたい人に向けて
    • まずデザインからで目線づくり
  • プロトタイプバトル
    • 話し合ってもおさまらないから作ったもので決着をつける
  • デザインとJS両方やらせるか?
    • 本人の志向次第
    • figmaでみんなでデザインの認識合わせ
  • フロントエンドエンジニアのキャリアパス
    • ユーザがすごいと思えるものを提供できてれば勝ちがある

「DevFest 2018 Tokyo」に参加してきました

  • DevFest 2018 Tokyoに参加してきました。

tokyo2018.gdgjapan.org

  • 昨年に続き参加しました。Firebaseは変わらず、加えてFlutterも流行ってるなという印象でした。いろいろな分野の話を聞けてとても勉強になりました。
  • タイムテーブルと公開されてる資料一覧です。
Room A+B(大) Room C+D(大) Room G+H(大) Room I (小) Room J (中) Room K (中)
実践!!Web パフォーマンス改善!
宇都宮 佑亮
Game Development for Firebase Unity SDK
gremito
Quick Start GCP
山内 沙織
Android OSは安全なのか?
タニグチガク
Flutterアニメーションの実装方法
konifar
Kubeflowで何ができて何ができないのか?
上田 隼也
Googleアシスタント最新動向
田中 洋一郎
Flutter Overview
Rui Kowase
PWAのイマ
takanorip
Firestore Database Design
1amageek
Advanced Room
荒木 佑一
GCP Compute 概要と選定
vvakame
AndroidX時代のHello world
深見浩和 / fkm
Google AIY Vision kitで遊ぼう ~麻雀牌のリアルタイム識別~
Rio Kurihara
Firebase Overview for native application
Daiki Matsudate
GCP のデータベース・ストレージ
apstndb
Goでネットワークプログラミングするためのよもやま話
竹澤 友博
FlutterPluginの作り方
kuwapp
Angularの最新情報
laco
DialogflowとCloud Functions で作る Google アシスタント アクション
flatfisher
Cloud Kata
sinmetal
KotlinでFlutterを書けないか色々試してみた
菊池 紘
Flutterとの1年
najeira
Growing your app with Firebase
shihochan
TensorFlow Liteで機械学習Androidアプリを超簡単に作る
古川新
Container
Kuma Arakawa
新しいMaterial Design と MDC
namiki
joi
yanzm
Introduction of Polymer 3.0
kazuyoshi kawakami
Realtime Database for high traffic production application
sota1235
Generative Modeling in the Wild
Rishabh Gupta
Goらしいコードを業務でも書くために
tom
TypeScript導入で得られる「変えていく勇気」
okunokentaro
Transactions APIを使って飲食店の予約が出来るGoogle Assistantアクションが出来るまで
小林 大介
AndroidThings で CO2 を計測し、警告&サーバーに計測値を投げるシステム
小林 慧
GCPでつくるデータ処理パイプライン
永井 洋一
"Fan out" to create twitter like timeline with Cloud Firestore and Cloud Functions
タイラー
Androidパネルディスカッション: AAC実践導入について
magie_pooh
teshi04
shaunkawano
飯島彩輝
松山 純也
Firebase Realtime Database in Production
青野 健利(ブルーノ)
機械学習、どこから手をつける?
上総 虎智
非中央集権ウェブ
aggre
Auto ML Overview
永井 洋一
GtugGirlsがヤバいんです
長尾ユリコ
  • 以下聴講したセッションのメモ書きです。

実践!!Web パフォーマンス改善!

  • 宇都宮 佑亮さん(Google)
  • 資料非公開(要点をツイートして頂いていたのでそれを載せておきます)

パフォーマンスを計測する

  • パフォーマンスの計測はLighthouseを使うと良い
    • ChromeのDevtoolから
    • Chromeの拡張もある
    • npmのモジュールもある
  • Chrome68からv3になった
    • 処理速度上がった
    • 解析結果の内容も変わった

サンプルサイトを最適化

  • なるべく軽く同じものは送らない
    • text compress
    • css minify
  • css/jsのカバレッジ
    • devtoolで確認できる
    • 読み込んでるのに使われてないコードは意外と多い
    • bundleしたファイルの内容をorganizationで確認
    • code splitting
    • dynamic import
  • 画像の扱い
    • いろいろツールはある
    • lazy loadする
    • ルーセルはlazy loadしないと重くなるので注意
    • 初期表示に不要な画像は送らない
  • Webフォント
    • 後から読み込まれると適用前のフォントで最初出てしまう
    • <link rel="preload">を使うと良い
  • スクリプトブロッキング
    • defer
      • 非同期にダウンロードして読み込んだ順に実行
    • async
      • 非同期にダウンロードしてダウンロードした順に実行

参考

Flutter Overview

  • Rui Kowaseさん(メルカリ)

Flutterとは

特徴

開発フロー

setup

  • flutter doctorコマンドで環境が整ってるか確認できる

dev

build/release

CD

  • fastlaneをサポート

Google I/O 2018のセッション

  • Flutter × MaterialDesign
  • Flutter × Firebase
  • Reactive Framework

Flutterの今

  • githubのスター数
    • beta1(2018/3)発表で増えた
    • Google I/O後もまた増えた

Firebase Overview for native application

  • Daiki Matsudateさん(FOLIO)

Firebaseのサービス

  • 20くらいある
  • 3つに分類される
    • build your app
    • improve app quality
    • grow your business

とりあえず入れたいFirebase

Firebase Crashlytics

  • クラッシュ解析ツール
  • クラッシュログ収集解析する

Firebase Paformance

  • パフォーマンスを計測してくれる
  • 滞在時間
  • 描画時間

Google Analytics for Firebase

  • モバイル向けにはFirebase使う

App Index

  • Googleの検索結果にアプリを表示する
  • ダウンロードボタンも出せる

Firebase Prediction

  • GA入れてること前提
  • 7日間のデータから次の行動を予測
    • デフォルトは4つの属性が取れる
      • 離脱しそう
      • 離脱しなさそう
      • 課金しそう
      • 課金しなさそう
  • 離脱しそうなユーザにだけ特定のキャンペーンとか
  • A/B Testingでの対象を離脱しそうな人だけにするとか
  • プッシュ通知を送る対象に指定とか
  • In-App messaging

Firestore

Firebase Realtime Database

  • NoSQL cloud db
    • リレーションは持たせず階層は浅くする
    • クライアント側でjoinしないといけない
  • json
  • offline

Firebase Firestore

  • リレーションがある
    • 参照をセットできる
  • クエリが使える

Firebase Cloud Function

  • Firebaseの更新ややhttpリクエストをトリガーに処理を実行する

Angularの最新情報

  • lacoさん

フロントエンド周り

  • 選定しないと行けないものが多い
  • Angularはこれを解決する

Angularで開発

雛形生成/起動

  • AngularCLIで簡単に雛形作成
  • ng serveで起動
    • ホットリロードも

コンポーネント

テストファイルも作られる

  • ng testで実行できる
    • セットアップ不要

MaterialDesign

  • ng add @angukar/material
    • ライブラリがインストールされる
  • MaterialDesignのコンポーネント用意されてるから使うの簡単

build

  • ng buildでバンドルされる
    • サーバに配置したらデプロイ完了
    • Webpackの設定なんかは不要!

周辺ライブラリ

  • Stackblitz
  • AngularPWA
    • 簡単にPWA対応
  • Ionic
    • WebViewベース
  • NativeScript
    • ネイティブを叩く
  • Angular Universal
    • node上でAngularが動く

今後

  • ivy
    • Smaller/Faster/Simper
  • Angular Console
    • AngularCLIのGUI
  • Angular for Designers
    • コードを書かずにGUIでアプリを作る

Introduction of Polymer 3.0

  • kazuyoshi kawakamiさん

Polymer Project

  • GoogleChromeチーム内のプロジェクト
  • driving the web platform forward
  • Web標準を勧めたりライブラリ開発を行う
  • その成果物の一つがPolymer

WebComponents

  • Google I/O 2012で初めて取り上げられた
  • CustomElements
  • ShadowDOM
  • HTML Imports

現在のWebComponents

  • polyfill入れればすべてのブラウザで使える
  • エコシステム
    • WebComponents版のnpm

webcomponents.org - Discuss & share web components

  • 共存できるFW

custom-elements-everywhere.com

Polymerってきもい

  • Polyfillでしょ?
    • 当初はWebComponentsのPolyfill
    • 2.0からはPolyfillを切り離してWebComponentsを作るためのFW
  • bower
    • 今はnpmでも使える
  • HTML Imports
    • HTML Improtsは中止に

Polymer3.0

  • Google I/O 2018で発表
  • Bower -> npm
  • HTML Imports -> ES Modules
  • 3.0できもかった部分が解決された
  • WebComponentsのメインストリームとしてのPolymerが完成

事例紹介

  • 聴き鳥テスト

kikitoritest.jpn.panasonic.com

  • JSFW使ってない
    • Polymer2.0
    • WebComponents
    • Redux
      • WebComponentsでRedux使えるライブラリがある?
    • Web Audio
    • PWA
      • オフライン対応

作ってみて

  • WebComponentsだけでもアプリ作成可能
  • ルーティング周りで苦労
  • JSFW + WebComponentsはあり

TypeScript導入で得られる「変えていく勇気」

  • okunokentaroさん(クレスウェア)

TS採用する理由

昔のTS知ってる人の誤解

  • 型定義ファイルの管理が面倒
    • 今は違う
    • npmで管理できる
    • npm i -D @types/react
  • 途中から導入できない
    • 混ぜて運用できる
    • ただしjs部分は一番ゆるいany型になる
    • .jsならスルー/.tsなら型チェック
  • unknown型
    • 3.0からの機能
    • anyではなくunknown型で

「変えていく勇気」

機械学習、どこから手をつける?

  • 上総 虎智さん(BrainPad)

機械学習で今何できる

  • 自動運転での活用
  • 目をスキャンして心疾患を予測
  • GoogleGlassでスマートファクトリー
    • 手が空かない作業で役立つ

どこから手をつける

  • 動くものをまず作ること
    • やってみないとわからないがつきまとう
    • プロトタイプの難易度は下がってる
  • 機械学習の学習実装
  • 学習済みモデルのデプロイ先
    • TensorFlow Lite
    • ML Kit for Firebase
    • AIY
    • TensorFlow.js
      • なんでブラウザ上で?
        • No device/ No install
        • Interactive
        • Sensors
        • Data stays on the client

プロダクトに仕上げるために

  • 機械学習モデルは使い続けてこそ価値がある
    • 変化を元に再学習が必要
    • 機械学習システムの継続的デプロイ
  • 機械学習モデルの公平性
    • 差別を生み出してしまわないか注意を払う必要がある
    • 再犯率機械学習で判定

まとめ

  • 機械学習モデルを開発して動かすまでのハードルが下がった
  • 必ずしも難しい手法を使う必要はない
    • シンプルな方法が継続活用しやすい

「NuxtMeetup#4」に参加してきました

  • Nuxt Meetupに参加してきました。

nuxt-meetup.connpass.com

  • 普段はReactエンジニアですが、Vue/Nuxtも興味あるので参加してみました。SSRのつらみ等Nuxtに閉じない話も聞けて勉強になりました。
  • イベント公開から数時間で定員が埋まってしまうところから見てもNuxtは今注目されていることが実感できます。
  • ちなみに次回は10/18だそうです。
タイトル 発表者
LINEとNuxt jun
STUDIOのつくりかた @keimakai1993
で、NuxtのSSRっていつ使うの? @kotamats
Nuxtのプロダクション事例 @AkiraTameto
Nuxtを使うと初心者と上級者の実装差がない @aintek4
リクルートライフスタイルにおけるNuxt.jsの導入事例 @YuG1224

LINEとNuxt

  • junさん

LINEとNuxt

  • LINEでNuxt使ってる
    • WebViewとかもあって意外とある

API/Auth

  • APIや認証サーバは別で作るほうが良い

API

  • host(ドメイン)をどう共有するか
    • /apiパスベースのプロキシ
    • /apiだとAPIサーバ、そうでなければNuxtサーバ
  • SSR
    • axios-module
    • Nuxtサーバ->APIサーバ

Auth

  • LINE Login
  • Authした状態でSSRしたい
    • axios-moduleでできる
  • ログインしてない時に/auth/loginとかにredirect
    • vueのコンポーネントを探しに行ってしまう
    • location.hlefでで認証に飛ばす
    • redirectじゃないので画面が出てしまう
    • login用の空のコンポーネントを用意して対応している

まとめ

  • axios-moduleがいい!

メモ

https://axios.nuxtjs.org/

https://github.com/nuxt-community/axios-module

STUDIOのつくりかた

  • @keimakai1993さん

STUDIO

studio.design

  • デザインだけでWeb制作できるツール
  • GUIベースでデザインが作れる
  • そのままWebに公開できる

STUDIOでNuxtがどう使われているか

  • デザイン編集
    • 内部的にはvue-cli叩いて作ってる
  • ライブプレビュー
    • Nuxt使ってる
    • 変更内容をFirebaseへ
    • それをプレビューに反映してる
  • パブリッシュ
    • Nuxt使ってる
    • GCPにアップ
    • SSRで動作

Nuxt/Vueで良かった点

  • サービスの成長スピードに合わせてプロダクト作れる
  • 出だしの素早さ
  • 軌道に乗ってからの作り込み

Nuxt/Vueで困ってる点

  • SSRしてるのでサーバ負荷が高い
    • Nuxt generate
  • メモリリーク
    • 長時間ページを表示し続けることが多い
    • 4分おきにk8sでNuxtのpodをローリングアップしてる

で、NuxtのSSRっていつ使うの?

  • @kotamatsさん

よくある会話

  • NuxtってSPA,SSR,generateどれ使うのがいいの?
    • generateがいいのかなー
    • SSRは使わなくていいんじゃね
  • generateはめっちゃ楽
    • nuxt generate
    • 初回レンダリング速い
    • 2ページ目以降はSPAモード
    • 動的なページも設定すればgenerateできる

(Nuxtの)SSRは癖がある

  • インフラ面
    • node環境
    • node死活監視
  • コーディング面
    • ブラウザ依存のAPI使えない
      • window``document
      • localStorage``indexedDB
  • フロントエンドエンジニアがあんまり考えたくないところ
    • インフラエンジニアも考えたくない

SSRいつ使うか

  1. CMS系のOGP対応
  2. 認証後のページの表示高速化
  3. Nuxtだけでサーバのセッションを使いたい
    • 認証情報をNuxtサーバで管理とか
  4. generateでできないことをしたい
    • middkeware使いたいとか
    • nuxtServerInit使いたいとか

まとめ

  • 静的サイトの場合はgenerateでどうにかなる
  • 会員制サイトなどはmiddleware使うことが多いのでgenerateだと厳しい
  • SSR固有の要素は代替技術もあるので選定が大事
  • SSR自体はNuxtではとても簡単

Nuxtのプロダクション事例

  • @AkiraTametoさん

どうしてNuxt

  • (Reactより)学習コストが低い
  • (Nextより)Nuxtは快適
  • コミュニティも活発

Nuxtのデメリット

  • 今のところない
  • 情報が少しすくないかなというくらい

事例

おしゃれなさいとがほしい

  • Nuxt + Netlify
  • 状態管理できるのでCSSアニメーション使いやすい

Wordpressのようなブログがほしい

  • Nuxt + Contentful + Netlify
  • Contentfulで簡単にCMS作れる
  • メール送信SendGrid使った

チャット付きのイベントアプリがほしい

  • Nuxt + Firebase + PWA
  • NuxtだとPWA簡単にできた
    • initコマンド的なのでPWA指定できる

Googleスライドのようなツールがほしい

  • Nuxt + Firebase + go + GCP
  • 作成したSVGをFirebaseに保存

快適な求人システムがほしい

  • Nuxt + go + GCP + Apollo
  • GraphQL使ってる

重いサイトをリプレイスしてほしい

まとめ

  • 基本全部Nuxtでいける!

Nuxtを使うと初心者と上級者の実装差がない

  • @aintek4さん

なぜNuxtは初心者と上級者の実装差がないと思うか

  • 実装がシンプル
    • ルーティング
    • 非同期処理
    • 簡単な設定ファイル

ルーティング

非同期処理

  • asyncDataの書き方は3パターン
  • どれを使うかチームで決めておけば分かりやすい
    • Promise
    • async/await
    • callback

簡単な設定ファイル

  • nuxt.config.jsだけ書けばいい
  • そもそもほとんど自分で書かなくていい

Nuxtを使う意義

  • 自分で書く量が少ないからビジネスの本質に時間を費やせる

まとめ

  • Nuxtを使えば初心者でも上級者と同じコードが書ける
  • フレームワーク側で用意してくれてるから実装がシンプルになる

リクルートライフスタイルにおけるNuxt.jsの導入事例

  • @YuG1224さん

Nuxt導入の背景

  • 大規模既存システムの存在
  • じゃらんの新機能追加(既存システムとの連携あり)
    • 既存の技術的負債を広げたくない
    • 負債はAPI Aggregationで吸収させる
    • API Aggregationはexpressで立てた

Nuxtの役割

  • NuxtはSPAとSSR
  • expressはAPI Aggregation

Nuxt採用してよかったこと

  • 既存システムの負債を簡単に吸収できた
  • 今後PWA対応簡単にできそう
  • コード規約が平和的に定まる

Nuxt採用してはまったこと

  • Nuxt内部のデバッグが大変
  • SPA + SSR + API Aggregationの構成が肥大化しそう

まとめ

  • Nuxt + Expressで簡単にSPA + SSR + API Aggregationを実現できた

「Rust LT #2 〜いま使う!Rust〜」に参加してきました

  • Rust LT #2 に参加してきました。

rust.connpass.com

  • Rust書いたことなくて難しかったですがいい刺激になりました。Rustでなにか書いてみようと思いました。
タイトル 発表者
Rustを支えるインタープリター qnighy
Rust の安全性を数学的に証明する 〜最新の研究から学ぶ形式手法と Rust の基礎〜 shiatsumat
lopdfの話 skoji
Rust でクロスコンパイルして Raspberry Pi Zero W で動かす legokichi
インタプリタを作ってまなぶRustらしい書き方 yuki toyoda
Rust 2018とは?〜安定した進化の真の意味〜 Pyry Kontio
この場で使う!Rust 〜アルゴリズムの実装を通して感じる使いやすさ〜 kenkoooo

Rustを支えるインタープリタ

  • qnighyさん

miri

miriを使う1

miriを使う2

Chalk

まとめ

Rust の安全性を数学的に証明する 〜最新の研究から学ぶ形式手法と Rust の基礎〜

  • shiatsumatさん

Rustをどう噛み砕くか

  • Rustを単純化したミニマリスティックな言語を一から作る

rustbelt

RustBelt

lopdfの話

  • skojiさん

lopdf

Rust でクロスコンパイルして Raspberry Pi Zero W で動かす

  • legokichiさん

どこでRust

インタプリタを作ってまなぶRustらしい書き方

インタプリタとは

  • ソースを解析して抽象構文木をつくる
  • 木を解析して実行内容を評価する

Rust 2018とは?〜安定した進化の真の意味〜

  • Pyry Kontioさん

Rustのブログのバズワード

  • Stability as a Deliverable
    • 安定性もRustが提供する機能の一つ
  • Stability without Stagnation
    • 常に進化をする

Rust 2018

  • 2018/12リリースする新しいバージョン
  • Rust2015と交換性100%

この場で使う!Rust 〜アルゴリズムの実装を通して感じる使いやすさ〜

  • kenkooooさん

今使えるRust

  • Rustの良さははやさ
  • Webアプリ作ってもいいけどそれはPythonでもいい
  • Rustを使うべきはアルゴリズムの実行

C - 身体バランス

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

  • Meguro.cssに参加してきました

megurocss.connpass.com

  • CSSの勉強会は珍しいので参加してみました。実践的な内容が多く勉強になりました。
タイトル 発表者
RSCSS体験談 @mhz_univ
flex: 1; @ryutamaki
CSSでクオリティをよりよくする @umiremix
Dart Sassであそぼう @terrierscript
"いい感じ"にするためのイージング @448jp
CSSでボーン @s14garnet

RSCSS体験談

  • @mhz_univさん

docs.google.com

RSCSSとは

RSCSSの構成

  • Component
    • 一意のクラス名
    • グローバル
  • Element
  • Variant
    • 色違いとか
  • Helper
    • 一時的な上書き
  • サンプル
.search-form {
.search-form {
  > .button { /* ... */ }
  > .field { /* ... */ }
  > .label { /* ... */ }

  // variants
  &.-small { /* ... */ }
  &.-wide { /* ... */ }
}

なぜRSCSS

  • CSS強い人いなかったから4分類だけで入りやすそう

大きさを考えて書く

  • 大きい粒度にしすぎるとつらくなる

1対1を考えて書く

  • 多html 対 多CSS
    • bootstrapのような
    • 影響範囲が大きいから変更がつらくなる
  • 1html 対 1CSS
    • 変更が容易
  • 多html 対 1css
  • mixin/extend
    • 隠れ多対1
    • classは違うけどmixinで実は同じもの使ってる
  • 共通な部品を作りたくなったらコンポーネントを新しく作る

flex:1;

  • @ryutamakiさん

flex

flexの基礎知識

flex-basis

  • flex-itemの主軸方向の長さ
  • max-width > flex-basis (> width)

flex-grow/flex-shrink

  • flex-grow
    • flex-containerの余ったスペースを比率で配分し拡大
    • 数値が大きいほど領域は大きくなる
    • 0だったら元の値より広げることはしない
  • flex-shrink
    • flex-containerからはみ出したスペースを比率で配分し縮小
    • 数値が大きいほど領域は小さくなる

用例

  • sidebar-main
    • sidebarは固定値
    • 余った領域をmain
  • header-main-footer
    • contentが少なければheader/footer固定
    • content多ければfooterはスクロールした一番下

CSSでクオリティをよくする

  • @umiremixさん

umiremix.com

CSSでテキストをより美しく

均等配置

  • テキストの右端を揃える
  • text-align: justify
  • 文字量が大くフォントサイズ小さいテキストに使うと良い

フォントサイズのジャンプ率

  • pxではなくvwでfont-sizeを指定するとジャンプ率が保たれる
  • ジャンプ率:本文サイズに対する見出しサイズとの比率
  • font-size: calc(30 / 640 * 100vw);

折返し

  • 自然な開業を作るか改行をさせない指定
.wrap: { display: block; }
.inner: { display: inline-block; }

アニメーション

  • iPhoneはスタイリングではなくインターフェイスデザイン
    • iPhoneを使っているという感覚ではなく直接情報を触っているという感覚を目指している
  • Webでも存在を意識させない自然なアニメーションを
  • CSSのアニメーション
    • CSS Transitions
      • 0.5s以上かかると違和感ある(ケースバイケース)
    • CSS Animations
  • 複雑だとJSでやった方が向いてる(JS/CSSの併用も)

DartSassであそぼう

  • @terrierscriptさん

Sassの最近

  • ruby-sassがdeprecated
  • 今後はdart-sass

Dart

  • 最近flutterで復活?

Dart Sass

  • ruby-sassより高速

Dart Sassをブラウザで動かす

  • 頑張ったら動いた!

いい感じにするためのイメージ

  • @448jpさん

アニメーションの実装における指示例

  • いい感じにして下さいとよく頼まれる
  • いい感じのアニメーション
    • 好さ + 善さ
    • 美しさメンテナンス性
    • ユーザ/ビジネス課題を解決する

いい感じのアニメーション

  • 90%はイージングで決まる
  • アニメーション調整の優先度
    • イージング > 時間 > 対象
  • RobertPennerのイージング関数
  • cubic-bezier関数がいい
  • http://cubic-bezier.com/

CSSでボーン

  • @s14garnetさん

docs.google.com

ボーンって何?

  • flashや3Dソフトではお馴染みのツール
  • 骨/骨格のイメージ
  • 意識するのは関節
  • CSSだけで腕みたいな動きを作れる!

デモ

codepen.io

「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でできるから敷居が低い