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

勉強会メモ

KotlinJSでServiceWorkerを使ってみた

kotlinJS in ServiceWorker

  • 良かった点
    • コード再利用できた
      • すでにあるkotlinコードを

ServiceWorkerのおさらい

  • プロキシ
    • 通信検知して書き換え
  • ページのJSとは別スレッドで動く
  • ブラウザの任意のタイミングでServiceWorkerは終了する
    • 永続化はindexedDBとか

kotlinJS

なぜkotlinJSとServiceWorker

  • 状態管理とか発生した時にkotlinいいんじゃないか-
  • state machine
    • swift,kotlin,tsで書いてたのをServiceWorkerへ移植

大変だったこと

  • 意図しないタイミングでリリースされる
  • indexedDBの型ファイル自作

使い方

  • kotlinからServiceWorker見えるように定義しないといけない
  • external
    • kotlinからJSの関数を呼ぶ
      • DOMアクセス系とか
  • 入れ子のPromiseの型の扱い
    • asDynamic

ツールを利用した対応と企業サイドの懸念点

Mobify

  • PCサイトをモバイル向けにするツール

課題

  • モバイルからのコンバージョン率
  • 顧客ロイヤルティ
  • サービス力で差をつける

事例

  • LANCOME
    • リッチなコンテンツ
    • ページ増加
    • スピード課題
  • アプリは?
    • 毎日使うようなものでもない
    • PWAで
  • 恩恵
    • アプリライク
    • プッシュ通知
      • 買い物かごに入れたまま落ちた人に通知
  • AMP + PWA
    • 入り口はAMP
    • そのあとはreact

導入企業の声

  • ネイティブライクに
    • アプリと全く同じになると勘違い
    • 見た目がwebと同じじゃんとなる
  • ios対応していないことはネガティブ要因
    • iosプッシュ通知使えないし・・
  • 新規事業と相性良い
  • ホームアイコンのみでも

メリット

  • ネイティブアプリより工数少ない
    • SSRタイプの画面ベースのページをSPAへ

お手軽PWA開発環境と近い将来の課題

お手軽PWA開発

  • create-react-app
  • ionic cli
    • start templateが豊富
    • とにかく簡単
  • PWA Builder

ユーザから見た不安

  • 見つけにくい？
    • ストアで探しても見つけることができない
    • ググればいいと言うけれど
  • そのままではPWAと思わないのでホームに追加しようと思わない
    • そもそも知らないし
    • iosは自分でホームに追加しないといけない
    • インストールしますかとか出してもそういうのはたいてい拒否される
  • ネイティブと比べて
    • 動作遅い？
    • 機能低い？

開発者から見た不安

一般的な課題

  • マルウェア対策
  • サニティチェック
  • メモリ/ストレージ使用量の把握/警告
  • ユニバーサル性/レスポンシブ性

フリートーク

  • iosだとスタンドアロンだと戻るがない
  • UI周り大変なんじゃないか
  • モバイルのスタンドアロンの場合と普通のWebアプリとして使う場合両方対応しないと
  • デザイナーが知ってないとはまりそう

「PWA Beginners 勉強会 #3」に参加してきました

勉強会メモ

WebでアプリなPWA、実際に本気でプロダクトを作ってみて見つけた悩み処

  • ShoheiKoyama

PWAの特徴

  • 審査通す必要ない！

実際に作る時に考えないといけない視点

  • ユーザにどうやってPWA化してもらうか(->ホーム画面に追加してもらうかということ?)
    • ホーム画面への追加の手順を載せる
      • イケてない
    • 何も言わななくてもいいものなら追加してもらえるんじゃないか？
  • ホーム画面に追加した後のアップデートどうするか
  • Web -> PWAとNative -> PWA
    • WebとNativeでUXが違う
  • 結局何を目的にするか、普遍的な価値は何か
    • Nativeでいいんじゃね？とか普通のWebページでいいんじゃねってなってしまわないように

PWAを簡単に使える方法！！

  • daisu_yamazaki
  • ジーズアカデミー主席講師

PWA

  • WebAppManifest
  • ServiceWorker

PWA化

  • 最初っからPWA化することを意識しないと苦労する
    • 既存サイトでも簡単にPWA化できますってよくきくけどそんなことない？？

WebAppManifest

  • ChromeのDevツール->Applicationで内容確認できる
    • ここに出てこなかったらちゃんと読み込めてないということ

ServiceWorker

  • ServiceWorkerはブラウザとは別のメモリで動く
  • キャッシュするファイルは読み込み失敗するとそこで落ちる
    • 絶対キャッシュしたいものとおちるかもしれないものを分けておくといいかもしれない
  • https://github.com/craigbuckler/pwa-retrofit

HNPWAの紹介

HNPWA

  • https://hnpwa.com/
  • HackerNewsリーダーをPWAで作ったもの
  • Reactとかいろんな実装がある
  • TodoMVCの後継者

HNPWAの仕様

  • リーダーとして使い物になるように条件がある
    • 各ページにURLがふられてるとか
    • lighthouseで一定以上のスコア出すとか
    • AppShellを使うこと
    • レスポンシブであること
  • オプション条件
    • オフライン
    • SSR

注意事項

  • FWの性能比較に使ってはいけない
  • 仕様がルーズ
  • サーバは実装者自前
  • 自分の使ってるFWでどうPWAを作れるかの参考にすると良い

ServiceWorker on Rails

  • ykyk1218

ServiceWorker + Rails

Webpackとrails

  • rails5からJSはWebpackで管理するようになった

DOM操作とServiceworker

  • postMessageでServiceworkerにメッセージを送れる

PWAで嫁に怒られなくなった話

ゴミの種類を教えるアプリ

  • firebase
    • lambdaでもよかったけどhttpフックできなかった
  • vue
  • cron.org
  • ServiceWorkerからLocalStorageを参照できない
    • indexedDB使った

「Firebase Japan User Group / meetup / 3」に参加してきました

勉強会メモ

FirebaseとUnity

Unityとは

  • ゲームを作るFW
  • VR/AR

FirebaseとUnityエンジニア

  • Firebaseを使うことでサーバ側だいたい同じ構造でいける

SDK連携を用いたAdMob活用法

AdMobとは

  • バナー広告
  • ネイティブ広告
    • まだbeta
  • インタースティシャル広告
    • バツですぐ閉じれるやつ
  • 動画リワード広告

AdMobのよさ

  • 導入が楽
    • FirebaseとアカウントさえあればOK
  • Firebaseダッシュボード上でも確認できる

AdMobMediation

  • 他の広告事業者と連携
  • ドキュメントに事業者一覧が載ってる

Flutterとfirebaseを使ってモバイルアプリに挑戦してみる

Flutter

FlutterとFirebase

firebase auth

  • 認証簡単にできる
  • JSのライブラリと使用感似てる

cloud firestore

  • JSのライブラリと使用感似てる

Firebase Realtime Databaseをフロントエンドで使って得た知見

AIメッセンジャー

  • RealtimeDatabase使ってる
  • 自前でWebSocket用意しなくていい
  • メッセージの受信は全部Firebase
    • ブラウザはreadのみ
    • APIにPOSTしてwrite

課題

  • 初回のデータ取得とか新規データ取得の概念がない
  • React使ってるからループでDOM作りたい
    • RxJS使った
  • 書き込みがタイムアウトしないから失敗検知できない
  • 大量データをにsort書けるとReadが100%になって止まってしまう
    • BigTableにもdoublewriteした
    • Firebaseはリアルタイムのreadのみ
  • 遅延や障害が多い
  • 冗長化が難しい
    • Firebaseは1プロジェクト1こ

Firebase Cloud Messaging (FCM) を利用した Web Push 通知の実装

FirebaseCloudMessaging

FirebaseでSPAするときのSEO/OGP対応これでどうでしょう

Firebase使ったサービス

  • SPAでSEOが悪い
  • SNSでOGP反映されない

どう対応するか

metaタグ差し替え

  • 特定のコンテンツのときだけfunctions呼ぶ
    • functionsのレスポンスはCDNにキャッシュできる

functionsでRSSフィード

スプレッドシートでsitemap

「春の機械学習祭り 〜Data Engineering & Data Analysis WS#4〜」に参加してきました

勉強会メモ

推薦アルゴリズムの今までとこれから

  • 内藤 遥(CA)

推薦アルゴリズム

  • 協調フィルタリング
    • これを買った人はこれも多く買ってます的な
    • 評価データがたまらないと推薦できない
  • コンテンツベース
    • アイテムの特徴で推薦を決める
    • ドメイン知識必要だけどデータなくても行ける

Amebaの推薦アルゴリズム

  • Fresh!とかで使ってる
  • 今はバッチで推薦を作ってる
  • リアルタイム化したい

マルチメディア機械学習への取り組み

  • 藤坂 祐介(CA)

CAが扱うデータ

  • テキスト、画像、動画...
  • Ameba、AbemaTV、Fresh!

アメブロの画像カテゴライズ

  • ブログのジャンルのカテゴライズを自動化したい

画像カテゴライズ

  • 画像300K枚手動でラベル付け
  • kerasで分析

スパム画像検知

  • Content moderation(コンテンツ健全化)

アメブロ

  • スパム画像は全体の0.1%
  • 人手でやってたから自動化したい
  • 有人監視のデータを溜めてモデル作った
    • スコア出してオペレータの判断を補助
    • でもうまくいってない
    • 画像の種類が多すぎた

マッチングアプリ

  • プロフィール画像の使い回し
    • 業者のユーザ
  • 類似画像フィルタ(dhash)
    • xxビット一致したら検知、みたいな感じでやった
  • 大量に検知できた

楽曲の盛り上がり検知

  • サビを検知する
  • AWA
    • 無料プランは30秒だけ
    • それをサビにしたい
    • サビ部分を自動検知したい
  • 音楽データにタグ付け
    • ここがイントロとか
  • デコードして解析
  • 結果は51%

大規模分散深層学習と ChainerMN の進歩と課題

  • 秋葉 拓哉(PreferredNetworks)

何やってる会社か

  • chainer作ってる

深層学習

大規模分散学習野何が難しいか

分散深層学習の基礎

ニューラルネットワークのイテレーション

  • Forward
  • Backward
  • optimize
  • これを何万回も繰り返す

同期型 vs 非同期型

  • 全ワーカー同期して処理するか非同期でやるか
  • 非同期のほうが速そう
  • Googleのbrainが非同期がいいと論文出してる
    • 2012年に発表されたもの
    • 古すぎる
  • 速くても意味がない重要なのは精度
    • 同期のほうが精度が上
    • Googleのbrainも動機がいいと論文出した
  • 分散深層学習
    • Forward
    • Backward
    • All-Reduce
      • ここで全部同期させる
    • optimize
  • ChainerMN
    • MN -> Multi Node
    • 分散深層学習できる
  • なんで同期のほうが精度いいのか
    • Gradient Staleness
    • 非同期でやってる間にモデルが更新されてる
    • 処理が終わってマージしようとした時は、元にしたモデルは古い
    • だから精度上がらないし壊してしまうことも

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

勉強会メモ

Progressive Web Apps: WebのInstallabilityのおさらい

従来のWebのユーザエクスペリエンス

  • 電車の中で
    • ブラウザのロードバーが
    • ぐるぐるがでてきて
    • 画像の領域がでてきて
    • ようやく映ったら広告がでて
  • 多様なデバイス × あらゆる環境
  • 足りなかったもの
    • プッシュ通知
    • ホームに追加
    • 簡単な支払い
    • 信頼おけるパフォーマンス
    • 常にログイン
  • Webのよさとアプリのよさを兼ね備えたい

PWA(主にAndroidの観点から)

  • PWAはホームに追加できる
    • アイコンちゃんとある
    • 全画面表示

ホームに追加

  • ホーム画面登録の条件
    • manifestファイルが存在する
      • short_name - ホーム画面で仕様
      • name - アプリ名
      • icon - アイコンのパス
      • scope - PWA化させる範囲
        • スコープ外れるとchromeタブが開く
    • プロンプトを出したいページにlinkタグで設置
    • ServiceWorkerが登録されてること
      • 空のServiceWorkerだとだめ(昔はできた)
      • fetchをlistenしてないとだめ
    • HTTPSで配信されてること
  • 2回以上のアクセスがあり間隔が5分以上であることがプロンプト出る条件
  • ユーザがどの程度エンゲージしてるかchromeが持ってる(1~100)
    • 2以上だと出る
  • chromeが自動的に出してしまう
    • タイミング悪いこともある
    • beforeinstallprompt
      • プロンプトでる直前のイベント
      • ストップしてどっかで任意のとこで呼び出すとかできる

ホームに追加したアプリ

オフライン対応

  • chromeの恐竜じゃなくて側だけでも作ったページ返すだけで印象全然違う

パフォーマンス

  • Lighthouseで計測する
    • chromeチームが使ってる
    • chrome開発者ツールで使える
      • Auditsタブ

プッシュ通知

それ以外

  • Offline
    • Background Sync
    • Periodic Sync
    • 急にネット切れても裏で持っておいて後から通信
  • Social Share
    • Web Share API
    • Web Share Target API
    • Webページの「共有」的なアイコンで他アプリが候補で出てくる
  • Photo
    • New image upload UI
    • Image capture API
    • デフォルトでギャラリーみたいなのがでる
  • Trusted Web Activity

今後

  • iOS11.3
    • 一部まだ使えない
  • Microsoft Store
    • PWA対応してるサイトがストアに載る
    • デスクトップアプリとして使える
  • Workbox
  • Credential Management API
    • 裏でオートログイン
    • JSでブラウザに保存したCredentioalにアクセスできる
  • Payment Request API
    • 支払いフォームをブラウザで提供
    • みんな同じことしてるのにそれぞれで作っていた

まとめ

  • Webの新たなUX
    • -> PWA
  • 信頼のおけるパフォーマンス
    • 必須
  • ホーム画面追加
    • お手軽

Service Worker とは何者か

前回の振り返り

  • ServiceWorkerが動くブラウザが増えてきている
    • Safariの対応
    • 日本では80%超
    • モバイルに絞れば99%
    • 使えるAPIには注意
  • コンテンツマイニングのいい機会

PWA化してみた話

ServiceWorkerの動き

  • install
    • インストール時のアクション
    • インストール終わったら必須な所をキャッシュ
      • アイコン、スタートページ、オフライン北ぞ
      • cache.addAll(fileToCache)
  • activate
    • ServiceWorkerが有効化された時
  • fetch
    • リクエストが来た時に発生
    • e.requestの内容見てハンドリング
    • online/offlineも見える
      • navigator.onLine
  • cacheを捨てるタイミング難しい
  • ServiceWorkerとは何者か
    • cacheを制御するもの
  • 未対応の環境にはなにも影響ないのも良い
  • どうさしてるServiceWorkerを見る
    • chrome://serviceworker-internals/

PWAってどんな使い方ができるのかしら？

PWA対応してみた

  • https対応面倒
  • ServiceWorker
    • ホーム追加だけなら簡単
  • アイコン作るの面倒

PWA入れた狙い

  • 新規よりリピータを増やしたい

PWAに向き不向き

  • 全てがPWAが良いわけではない
    • 全てがモバイルアプリがいいわけではない
  • yahooとかWebの方が使いやすい

PWA開発の視点

  • PWAであることはWebアプリであること
  • Webで使われる場合もアイコンから使われる場合も考えないといけない

まとめ

  • ちゃんとした設計思想のもと作らないとゴミアプリになる可能性ある
  • サービスのステータスを見てネイティブ/PWAの選択を賢く
  • PWAの登場でUXデザインがより一層重要
  • 技術の選択肢が増えたんだからしっかり理解して判断するべき
    • だから今PWAをキャッチアプする価値はある

「MANABIYA」に参加してきました

勉強会メモ

MANABIYA

The Angular World

Angularの紹介

  • フロントエンドのフレームワーク
  • 統合された開発プラットフォーム
  • 開発者のエコシステム

フロントエンドのフレームワーク

  • CoreとFeaturesに分かれてる
  • npmパッケージは細かくわかれてる
  • 実行環境はブラウザでもnode上でも
フルスタックのよさ
  • 同じ知識の共有
  • 公式で全てテストしてくれる
  • VUP遅れることもない

統合された開発プラットフォーム

  • 開発者を支援する仕組みも含めて
開発者ツール
  • Angular Language Service
    • tsのLanguage Serviceを活用
    • 入力補完が強力になる
  • Angular CLI
    • プロジェクト生成
    • テスト/ビルド/起動
    • webpackなんかを隠蔽してくれている
      • パフォーマンスチューニングしてくれてる
  • codelyzer
    • tslintの拡張
    • Angularならではの部分もチェックしてくれる
  • Stackblitz
    • Angular公式が協力して作ってる
    • コードの実行環境
    • ブラウザで開発できる
Angular for Mobile
  • PWA
    • Angular CLIで対応済みプロジェクト作れる
  • Ionic
    • ネイティブ用のコンポーネントが提供されている
    • ネイティブのUIに近い見た目を作れる
  • NativeScript
その他
  • Angular Material
  • Component Dev Kit
  • Angular Elements

開発者のエコシステム

  • 世界中でAngularは使われてる
  • バージョン
    • メジャーバージョンは半年ごと
    • マイナーバージョンは毎月
    • パッチバージョンは毎週
  • リリース前にかならずGoogle社内で使ってる
  • LTS(1年間)
    • V4, V6
  • AngularとAngularJS
    • Angularの方が多数はになってる
    • AngularJSは2018/7からLTS2021/6で終了
  • Google社内のAngularJSアプリは25%Angularにマイグレーション
  • who-use-angular-in-japan
    • 24社掲載

Angular Roadmap

  • Angular Labs
    • 実験的機能が入ってる

Angular Elements

  • WebComponents対応
  • 実装がAngularで出力はWebComponents
  • 小さいAngularアプリって感じ
    • 例えばdatepickerとか

ngivy

  • 目指す所
    • Faster
    • Smaller
    • Simpler
  • HelloWorldが3kbでできる
  • V6ではオプショナル

Angular Buildtools Convergence

  • ビルド時のツールチェーンをGoogle社内のものと同じようにしようというもの

Angular Real World

2018年のWeb標準

2018年のWeb標準

  • ServiceWorker
  • WebComponents
  • WebPayments

ServiceWorker

  • キャッシュがあってもオフラインでは取得できなかった
  • ServiceWorkerがインストールされてればバイパスできる
  • オンラインへの復旧を検知できる
  • プッシュデータの受信

まとめ

  • 機能が強力
    • しかも現状に後から追加できる
  • ブラウザサポートも大きく好転

WebComponents

機能が強力

  • CustomElemetns
    • 自分で作ったClassがHTMLタグとして使えるようになる
  • ShadowDOM
    • DOM要素の下にShadowDOMというスコープの閉じた要素を作り出す機能
  • ES Modules
    • ESのimport/export

JSFWとの比較

  • ビルドフェーズの単純化
  • 仮想DOMはないからそこは劣る
    • lit-htmlで仮想DOM的な差分描画できる

まとめ

WebPayments

  • PaymentRequestAPI
    • 共通的なブラウザUIを提供
  • クレジットカードの脆弱性
    • リスクが大きい
  • PCI DSS
    • クレジットカード情報を扱う場合に守らないといけない基準
  • カード情報を扱わないために
    • 決済部分だけ代行業者のページへ

WebPaymentsのコンセプト

  • カード情報をやりとりしなければいいのでは
  • PaymentRequestAPI
    • PaymentAppを使いやすくするもの
  • chromeとedgeすでに使える

まとめ

  • 決済機能あるなら使うべき
  • UIも統一される
  • クレカ番号毎回入れるのもうやめる

Vue.jsの今後と次世代のWeb開発に向けて

2017年のVue

  • github star フロントエンド部門1位(2年連続)
  • VueConf2017開催(ポーランド)
  • storybookのVue対応
  • Nuxtv1.0リリース
  • NativeScriptのVueサポート

コアチーム体制による開発状況

Style Guide

  • 公式にスタイルガイドがある
    • betaリリース済
    • 日本語も

Cookbook

  • よくある落とし穴の対処
    • 最近betaリリース
    • 日本語はまだ
  • レシピが順次追加されてる

eslint-plugin-vue

  • 公式のeslintプラグイン
  • v4.0リリース済
  • スタイルガイドの対応中

Vue Test Utils

  • 公式のunitテストライブラリ
  • 1.0にむけて最終作業中

vue compoonent compiler

Vue CLI

  • v3.6

Core

  • 今v2.5
  • 2.6に向けてと3.0に向けてにブランチ分かれてく
  • 3.0はes2015動くブラウザのみが対応になる
    • IEはおとされる
  • クラスベースのAPI
    • ES側の対応が進んだら(class fieldとか)

次世代の開発に向けて

  • Vue CLIによってすぐに雛形ができる
  • 課題
    • 機能が雛形作るのみ
    • 質問事項多すぎ
  • 3.0でスクラッチで作り直し
    • .vuercに質問事項保存
    • webpack/babel/eslintの設定を隠蔽してくれるようになる
    • vue.config.jsで設定カスタマイズ
    • WebComponentsのビルドサポート
    • GUI版も開発中
  • Vue Dev Tool
    • ブラウザ拡張だけではなくelectron版も作ってる

Vueの思想

  • Simple Made Easy

Web Application 2018 From Performance Perspective

歴史

  • 200x年
    • good old web
  • 201x年
    • SPA
  • 2017

200x年

  • High Performance Web Sites
    • ユーザはフロントエンドで80~90%待機している
  • ページ遷移での処理がメイン
    • 毎回ページを描画しつつブラウザの機能を多用

パフォーマンス

  • リクエストしてからレスポンス返ってくるまで

パフォーマンスのためにやること

  • リクエスト回数改善
    • そもそもリクエストしない
    • CSS sprite
    • Cache Controle
    • CSSのインライン展開
  • レスポンス時間の改善
  • レスポンスするバイト数の改善
    • 画像のサイズ
    • minify/gzip化

2010~2016年

  • High Performance Browser Networking
    • サーバ中心からブラウザへ移る
    • レイテンシを良くしろ
  • ネットワークレイヤでの最適化
    • HTTP2
    • Ajax/SPA
    • Partial Rendering
  • SPAを基本としてGUIアプリとしての側面が強くなった

パフォーマンス

  • Lighthouse
    • ベストプラクティスに則ってるか点数化してくれる
  • Real User Monitoring
    • 実際のユーザ体験を数値化
  • よりリアルなユーザを対象に
  • アプリ全体の時間を考慮するようになった

パフォーマンスのためにやること

  • 初回アクセスだけでなくその後の操作も最適化
  • レイテンシ削る
    • 1つのHTTP接続を無駄にしない
      • 毎回接続はコスト高い
  • HTTP2
    • 多重化されたリクエストを送る
    • 帯域幅が増えてもレイテンシが上がらないと高速化しない
  • HTTP1.1では
    • 同時接続6本まで
    • 7本目は待たされる
    • Head of Line Blocking
  • https://github.com/yosuke-furukawa/early-hints-demo

2016年~2018年

  • 超速本
  • 7 principles of Rich Web Applications
  • よりGUIアプリケーションとしてユーザ体験を向上させる進化
  • JSのサイズがでかくなってきてる
    • 80kbくらいだったのが450kb

パフォーマンスのためにやること

  • SSR
    • JS全部ダウンロードしないと画面が見えない
      • だからサーバ側でもページを作る
    • クライアントとサーバで同じロジックが動く
    • 初期表示時間を改善しつつSPAのよさ活かす
  • CSRだと
    • First Contentful Paintが長い(Loadingの時間)
    • First Meaningful Paintまでの待ちが長い
    • SSRするとこのまちをなくせる

2018年~

  • ユーザアクションが起きる前に動きを予測して投機的実行
    • レイテンシの壁を超える
    • オンマウスでprefetch
    • スクロールの動きをもとにprefetch
    • 機械学習
  • CDNをもっとアクティブに
    • Cloudinary
      • 画像の配信に特化したCDN兼画像変換
    • Fastly/netlify
      • Instant CacePurge
      • キャッシュの更新とかが簡単に
      • 動的なhtmlをキャッシュさせる
      • 経路の最適化

まとめ

  • パフォーマンスは文化である
    • パフォーマンス警察を育てよう
  • Webの動きを予想
    • Webの仕様を追う

Web Cross Session

Full SPA vs Partial SPA

  • 部分的なSPAをVueで
  • Vue + NuxtでSSR + SPA

SPA作ってて困ったこと

  • ServiceWorkerのキャッシュのパージ
    • ServiceWorker更新されたことのイベントは来る
    • ブラウザで画面リロード促してほしい
  • ブラウザデフォルトで動いてくれてることがSPAで変な動きしてしまうとよくない
    • 戻るでのスクロール位置とか
    • 状態の保持とか
  • Angularはでかいものをどんと作るにはいい
  • 小さいものはWebComponentsで作ってる

フロントエンドに疲弊してるか

今後のWeb標準で期待したいこと

  • WebAssembly
    • ポータビリティが上がってほしい
    • Web以外でネイティブでも動いてくれたりとか
  • template-instantiation
  • DOM changelist
    • DOM変更のリストをバッチにして渡せる
    • 仮想DOMのdiff patchの出力
  • ブラウザにもっと頑張って欲しい
  • 仮想DOMがやってることをWeb標準でやってほしい
  • async-dom

今後

  • Angular
    • SPAとしては完成している
    • いかに小さくはやく
    • SPAじゃない文脈でユースケースを増やす
  • Vue
    • Webの複雑なものを簡単に作れるようにする仕組み
  • Web標準
    • ServiceWorker
    • WebComponents
    • WebPayments

「エンタープライズ開発におけるフロントエンドのいま-HTML5、JavaScript、TypeScript、Angular-」に参加してきました

勉強会メモ

HTML5が創り出す新たな世界

HTML5が常識になる

マルチプラットフォーム

  • Cordovaとか

AppleがHTMLを使う理由

IT + Creative

  • 結果をいかに見せるかが差別化優位性に直結
  • IT + Creativeできる企業は少ない

HTML5/Angularによる業務系システム開発 -プロジェクト成功へのノウハウと大規模事例紹介-

業務システムの歴史

  • 1990年代 -> html
  • 2005年くらい -> Flash/Flex

Flex

HTML5/Angularへの移行

  • 既存のままで困ってないけどFlash終わるから仕方なくれプレイス
  • Flexはグリッドが高機能
  • UIの変更の合意をまず最初にやること
  • Bootstrapテンプレート + UIライブラリ

UIライブラリ

  • WijimoUI(有償)
  • KendoUI(有償)
  • PrimeNG for Angular
  • OnsenUI
  • 有償でも10万いかないくらい
    • いろいろ考えなくてよくなるのでただみたいなもん

モックを作る

  • エクセルとかじゃなく動くもので
  • UIだけでなく操作性まで合意をとる
  • 出来る人が画面部品をパターン化しhtmlの雛形作る
    • フロントエンドエンジニア出ない人がそれをもとにモックを作る
    • SI界隈はフロントエンドエンジニアが少ないのでこのやり方

QA

  • フロント周りVUPしてますか？Angularは半年ごとにメジャーVUPしてますし
    • 開発中は極力上げている
    • 完成後はお客さんからお金もらえないことも多いのでそれ次第
    • 開発者のモチベーションにも関わるのであげたい

サーバーサイドエンジニア向けTypeScriptのすゝめ -もう、「知らない」では逃げられないフロントエンド開発-

  • 越智理夫(株式会社カサレアルチーフエンジニア)

JavaScriptを学ぶ

昔のJavaScript

  • ブラウザ互換性
  • セキュリティ脆弱性

少し最近のJavaScript

  • ツール代替言語多すぎ
  • 言語として不安
    • 型ない
    • コンパイルない
    • クラスないのを様々なテクニックでカバー

TypeScript

  • おすすめの理由1
  • おすすめの理由2
    • 入力補完
  • JSライブラリの活用
    • 型定義は有志で作ってる
    • 苦労することも
      • どんくらい苦労するもんなのか
  • JSのプラクティスに則った形式でトランスパイルされる
    • ここ客観的な根拠がほしい

QA

  • 型定義どんくらい苦労するもんか
    • ライブラリの最新版に追いついてこないことが多い
      • anyで逃げるのも一つの手
      • 型定義は自分で書くという気概がないと
    • TSの最新版に追いついて来ないことが多い
  • JSのプラクティスに則った形式でトランスパイルされることの根拠は何かないか
    • C#を作ってる優秀なエンジニアとかが作ってる
  • Angular使うならTS一択だけど、それ以外だと決め手に欠ける、ESNext + Flowで挙げられたメリットはカバーできる
    • ライブラリのコード補完が効く所が良い
      • 型定義苦労してるんでは・・・

「R.kt #3」に参加してきました

勉強会メモ

変態文法とKotlin Puzzlers

  • 長澤 太郎さん(エムスリー)

変態文法

  • Nothing型がおおもとの型

Kotlin Puzzlers

  • ラムダの中でreturnはインライン関数でしか使えない

Kotlinミニアンチパターン

Destructing Declaration

  • 変数の宣言準ルール決めないと事故の元

Nullable Boolean

// 警告出る
if (condition ?: false) { }
  • true/false/nullの3つの場合分けするとややこしい

SAM変換

  • Javaのメソッドをラムダで呼べる

sealed class

  • どうファイルのみで子クラス宣言できる

Data Binding

  • findViewById

もくもくKontribute

  • 磯貝 佳典さん(ASICS)

Providing Sample Codes

  • サンプルコードを提供するissue

ホットペッパービューティー / Kotlin採用時の懸念と実際

ホットペッパービューティーをKotlin化

  • 2016/6〜2017/12でリプレイス
  • 84画面
  • 最大11人
  • must案件以外完全ストップ

なぜKotlin

  • Android界隈での高まり
  • 一度Javaのままリプレイスしたらもう変えられないだろう
  • エンジニアのモチベーション

採用の懸念

  • Kotlin化したらKotlinエンジニア探し続けないといけなくなる
    • 学習コスト低い
    • 採用リスク無視できるだろうと
    • Java経験者なら1週間
      • Kotlinらしさを無視すれば
    • Javaの資産使えるのがいい
  • 未熟なエコシステム
    • 最悪Javaで書こうとしてたが必要なかった
    • Javaの静的解析ツールが無駄になった
      • kotlinようのツールある
  • 言語としての発展性
    • Googleが採用してくれた

ktlint

  • 仙波 拓さん(AbemaTV)

Kotlinのlint

  • AbemaTVで最近ktlintいれた
  • kotlinの静的解析ツール&フォーマッター
  • json/xmlで出力できる
  • gradkeのタスク追加するだけ

ktlintのルール

  • 公式のスタイルガイドにそっているルール
  • ルールを変更することは公式ではできない
    • 頑張ればできる
  • 特定の行で無効化とかはできる
  • ルールの追加はできる

ktlintの仕組み

  • ASTの構文木に分解して解析してる

CI

  • CI連携できる
  • PRにコメント出したり

「2018年3月定例会「クロスプラットフォーム開発最前線2018」」に参加してきました

勉強会メモ

Monaca/Cordova 開発最前線2018〜 国内初の飲みニケーションロボットから、AIとロボットを活用した人気ラーメン店での顔パスサービスまで 〜

Monava

世の中のながれ

monacaで苦労したこと

  • タップイベントの反応が悪い
    • タッチイベントに変更したり
  • スクロール(慣性)中にタッチイベントうまく制御できない
    • 慣性中にタッチさせないようにした
  • 処理速度が遅い
    • 無駄なアニメーションなくした
    • APIのリファクタ
    • 画像サムネイルにした
  • 縦横斜めのハンドリング
    • スクロール
    • タブスワイプ
    • プルフック

プラグイン

まとめ

「Xamarinで始めるクロスプラットフォーム開発」

  • 石崎充良様 (JXUG / イメージ情報システム株式会社 )

Xamarinとは

開発方法

  • Xamarin Native
  • Xamarin Forms
    • UIも共通化
    • UIは各プラットフォームの最大公約数の機能

C

  • 今も言語はアップデートされている
  • 拡張メソッド
  • XamarinはC#の最新機能をすぐに使える

ネイティブのAPI

  • ネイティブAPIの薄いラッパー
  • Javaで書くのとほぼ同じコード
  • iosAPIは次の日/AndroidAPIは数ヶ月

AndroidアプリをXamarinに置き換える

  • Androidのres -> XamarinのResources
    • そのままコピペでいける
  • Javaのコードをそのままコピペから手直しでけっこういける

Xamarin Forms

ゼロから始めるUnity生活　〜Unity 101〜

Unity

  • 2004年にできた
  • ゲームを作るUnityという会社でゲーム作るために作ったFW
  • コンテンツを作るためのツール
    • エンジニアのためのものだけじゃない

事例

周辺ツール

  • エディタ
  • ゲームとプレイヤーの解析
  • アプリ内課金/広告

最近

PWAがたぶんくる

PWAとは

  • Web Application
    • ブラウザで動く
  • Progressive Web Apps
    • よりアプリっぽく
    • ServiceWorker

What is a PWA

  • Responsive
  • Connectivity
    • オフライン
  • App-like
    • アプリのように
  • Fresh
    • ServiceWorkerが裏でデータとってくる
  • Safe
  • Discoverble
  • Re-engageable
    • プッシュ通知によるもの
  • Installable
    • ホーム画面にアイコンおける
  • Linkable
    • URLでシェアできる

クロスプラットフォームアプリとの違い

  • クロスプラットフォーム
    • 開発資源を共通化しつつ各プラットフォーム向けにコンパイル
    • アプリストアで配布
  • PWA
    • Webアプリをインストールしてオフライン実行
    • Webサイトにアップロードして配布
  • ストアを経由しないことはメリット/デメリット？

PWAのメリット

  • Webのいいとこ
    • 検索でひっかかる
    • 更新容易
    • 低コスト
    • 既存のWeb資産活用
  • アプリのいいとこ
    • 高速な動作
    • オフライン
    • Push通知
    • ホーム画面にアイコン

PWAの構成

  • 既存サイトを対応させるならほんの一手間

インストール発生条件

  • httpsが大前提
  • 5分以上開けて2回目以降のアクセスで出てくる
  • Manifestファイル、ServiceWorkerが存在してること
  • インストールすると端末からはアプリとして認識される

オフライン制御の仕組み

  • ServiceWorkerがキャッシュとオンラインのハンドリング

コンテンツ/アセット

  • ResponsiveならそのままでOK
  • 何をキャッシュするか考える
  • アイコン設定忘れずに

事例

対応状況

  • 現状対応してるブラウザのシェアは45%くらい
  • SafariとEdge足すと75%くらい!
  • ただしOSによって全部の機能が使えるわけじゃない
  • グローバルだと75& -> 90%

まとめ

  • httpsならManifestとServiceWorkerとちょっとしたコード追加でPWA化できる

「フロントエンド未来会議」に参加してきました

勉強会メモ

バックエンドエンジニアチームでVue.JS + TypeScript

  • Chifung Cheung(Geniee)

アプリエンジニア->ReactNative系

ReactNativeWeb

  • WebアプリをReactNativeWebで作った
  • Nativeは別で作ってる
  • ReactNativeのコードでWebを書きたかった

フロントエンドの未来予想

フロントエンド->バックエンドエンジニア

  • Xingyue Sun(Geniee)

「JAWS DAYS 2018」に参加してきました

勉強会メモ

A story of cloud journey with Community

Enterprise Serverlessを実現するための信頼性エンジニアリング

Serverlessとは

Serverlessの信頼性

FaaSの課題

  • テストどうやるか
  • functionの粒度
  • 他のfunctionやbackendとの連携
  • エラーハンドリング
  • トレーサビリティ/ログ

BaaSの課題

  • どのサービスをえらべばいいか
  • 監視

FaaSの実態

  • コンテナ内で非同期に呼び出される関数

BaaSの実態

信頼性の担保

  • 結局は今までの技術と同じだから信頼性担保はできる
  • 信頼性は自分で作る
    • アプリの層にいろいろ移ってきている
  • シンプルを保つ
    • functionの数はは多くても良い

Serverlessの設計

イベントは一方向に流す

  • 結果が必要なら同期で返さず取りに行かせる
  • 自然と非同期になる
    • 同期だとエラーハンドリングとか考えないと
    • 結果整合性/冪等性
    • リトライすればいい

サービス間のエンドポイントを集約する

  • マイクロサービス
    • ドメインでサービスを分ける
    • サービスごとに唯一のエンドポイントというわけではない
    • 特定のサービスの特定のオペレーションは１つのエンドポイントに

トレース

  • 一連の処理には同じIDを付与
  • ログ収集しましょう

データモデリング

  • RDBと相性悪い
    • 急激なコネクション
  • DynamoDB使おう

Serverlessの実装

  • ユニットテストを書く
    • ただの関数なので書ける
    • 依存サービスはモック化
  • DBとかつなげてやりたい場合
    • ServerlessFWとかSAMとか使う
  • E2Eテストも継続的に
    • traceableIDつけておく

監視

  • エラー通知をしっかり作ること
    • どんなエラーが出たか分かって追えるようにしておく
  • メトリクス取れるサービスはとる
    • データ制限あるサービスとかは確認
      • 何秒間に何回しか呼べないとか

まとめ

  • Serverlessは特別なものじゃない

ランチセッション

「AWS Technical Evangelists Special talk session -スペシャルトークセッション AWSとユーザーコミュニティが生み出すNo borderな未来-」

  • Jeff Barr
  • Randall Hunt
  • Julio Faerman
  • Channy Yun
  • 亀田 治伸

Alexa for Businessとワークスタイルの未来

働き方改革

  • 超長寿社会
  • 今までの働き方だとだめ
  • 柔軟な働き方

業務シーン

  • 情報を社外に出せない
    • 帰社しないと作業できない
  • 子育てとの両立

ソリューション案とベネフィット

AWSの提供するサービス

  • WorkSpaces
  • AppStream
  • Alexa

alexa for business

  • 色んな所における
    • 倉庫、会議室、受付
  • 生産性向上
    • 電話、会議スケジュール
  • 集中管理
    • デバイス、ユーザ管理
      • SharedDevice
  • PersonalDevice
    • スキル管理
      • パブリックスキル
      • プライベートスキル

まとめ

  • AWSのサービスを活用することで
    • いつでも働ける
    • どこでも働ける
    • 誰とでも働ける
  • その中の１つとしてalexa for business

コンテナを守る技術 2018

Dockerイメージの安全性

  • DockerHubのイメージにもたくさんの脆弱性
    • オフィシャルのものでも
  • コンテナの機能を活かせば他への影響なしにセキュアなサービスを提供できる

AWSで構成するなら

  • ECSを使う
    • awsvpcモード
  • コンテナ(アプリ)毎にセキュリティグループを設定できる
  • Fargate
    • ホストを管理したくない場合

アプリ開発

  • CI
  • 実行時スキャン
    • アプリ実行時にポリシー違反がないかモニタリング

ホストとコンテナ

  • 守りやすい環境を整える
    • セグメントを分ける
    • クラスタを分割
    • ネットワークを分割
  • スケールアップよりスケールアウト
  • role.SGの解放は最小限に

ホストとコンテナ

Dockerコンテナ

  • リソースの分離はVMほど厳密じゃない
    • ホストのカーネルで走る
    • ホストのリソースをほぼ直接利用
  • リソース制約
    • ulimits
    • memory指定し超えたらコンテナ落とす
  • read only
    • いろいろオプションある
    • マウントしたフォルダ以外書き込み禁止
    • マウントしたフォルダの書き込み禁止
  • ルートユーザ使わない
  • 実行ファイルの管理
    • 不必要なファイルは削除/無効化
    • できれば静的リンクに
  • 通信を制限
    • 通信先/解放ポートも最小限に
  • システムコールを制限する

CI

  • Static Application Security Testingツール
  • Dockerイメージのポリシーを定義&チェック

deploy

  • aqua
    • AWSの各サービスとも統合された商用ツール
    • ECRのイメージ解析
    • 設定不備検知
    • 実行時防御
  • NeuVector

秘密情報

  • 2016年はS3に置いてIAM適切に
  • 環境変数だといろんなとこから見えちゃう

実践Serverless x Microservices

「Frontrend Vol.11 - 2017年度フロントエンド大反省会」に参加してきました

勉強会メモ

新R25本創刊までの1年

CSS管理

  • 変数を使う
  • css var

AtomicDesign

  • 粒度の定義難しい
  • ルールをしっかり決めた
    • 必ずatomsから作る
    • atomsが含まれていたらmolecules
    • moleculesが含まれていたらorganisms
    • 使い回すことがなくてもコンポーネント化する
      • 表示の分岐があったりすると分けた方が扱いやすい
      • containerが汚れるのを防ぐ

SSR + SPA

  • SSRでhtmlサイズが大きすぎてしまう
    • SSRでどこまで表示するか
    • SEOやSNSシェアで影響でないように
  • 画面遷移時のスクロール位置
    • window.scrollTopとかする？
    • ブラウザの「進む」「戻る」
    • history.stateにページの情報を入れておく

レスポンシブデザイン

  • window.matchMedia

R25の今後

  • AMP使おうとしている

Nuxt.jsでB2Cサービスを作った話

FW選定プロセス

  • サービスの要件
  • ビジネスの要求
  • 開発側の要求

Vue/Nuxt

  • NuxtはVue公式で推している
  • 日本語ドキュメント
  • SSRも対応している
  • バックボーンが企業じゃない

Vue + Nuxtで良かったこと

  • ディレクトリ構成がそのままURLになる
  • Exporess上でNuxtをミドルウェアとして扱える
  • パフォーマンスが良い
    • FWが要因なのか？？？

Vue + Nuxtで困ったこと

  • VueとNuxtのライフサイクルを意識しないといけない所
  • 新陳代謝が激しい
    • VUPでワーニング
    • こまめにアップデートしないと大変

まとめ

  • SSR + SPAを低コストで実現できた
  • コスト/パフォーマンスどちらも満足

歴史ある巨大システム アメブロに配属された新卒トーク

AbemaTV #ホンネテレビ の本音

AbemaTVの構成

  • GCP上に構築
  • BFF
    • Nginx -> Node
  • SPA

Webサーバを死なせない

  • ダウン時に問題のあった箇所の見直し
  • CDN化
    • html含めた静的ファイルは全てGoogleCloudCDN経由に
    • UserAgentによる配信物の振り分けができない
    • Fastly移行検討中

API/配信サーバを死なせない

  • CDN化
  • リクエスト数削減
    • 視聴までに必要なAPI刷新
    • マイクロサービスの分け方を見直した
  • 解像度のコントロール

エラー発生時の適切な対応

  • エラーハンドリングの見直し
    • エラー時にエラー用のレスポンスを返す
  • メンテナンス画面の表示
    • エラー時に何も表示されないが起きないように

Unit testを書かなくて反省した話

2017年度の Vue + TypeScript

WebComponents

「UIT#2 怠けるために努力を惜しまない プロのフロントエンドエンジニアたち」に参加してきました

勉強会メモ

Reactのコンポーネント作成を効率化しよう

コンポーネントを作る

npmとmakeでプロジェクトをコントロールする

タスクランナー

  • gulp,Grunt
    • 属人化しやすい
    • 宣言的でないので読みにくい
  • npm scriptsが主流
    • npm run ~
    • shellが叩けるだけなのでシンプル
    • node_modulesで補う

便利モジュール

  • rimraf
    • rm -rf
  • ejs-cli
    • ejs変換
  • cpx
    • コピー
    • watch
    • transform
  • npm-run-all
    • コマンドを並列実行できる

Lintとフォーマット

  • ルール違反をコミットさせたくない
  • git pre-commit hook
  • pre-commit
    • node_modules

make

  • npm scriptsのラッパーとして使ってる
  • macなら最初っから入ってるから手っ取り早い

Docker

  • Dockerfileのnpm scripts叩く処理書いてる
  • makeからdocker呼んでる

【codegen は難しくない】SwaggerからJavaScript(TypeScript)コードを自動生成してコーディングを効率化しよう

ボイラープレートをなくそう

  • ボイラープレート多いよね

Swagger

SwaggerCodegen

  • SwaggerSpexで書かれたドキュメントからクライアント/サーバのコードを生成する
  • Java(maven)で動作する
  • groovyでも動く
  • Java書くの嫌だし自分で作る

ウェブクリエイターに贈る自動化Tips

  • @takanorip

画像圧縮

SFTPデプロイ

便利bot

  • npm outdated
    • 最新じゃないライブラリを教えてくれるコマンド

WebAssembly text format で画像処理を書くぞ

画像加工

  • PhotoShopなしで背景付き画像を透過したい
  • 画像データｈ配列で表せる
    • [255, 255, 255, 255, 0, 0, 0, 0]みたいな
    • 4要素で1pxずつ
  • Flood-fill

「JSUG勉強会 2018年その2 SpringとAPI時代の動く仕様への取り組み」に参加してきました

勉強会メモ

SpringとAPI時代の動く仕様への取り組み

テスト編

  • given-when-then
    • given
      • 事前条件状態
    • when
      • 対象に対する操作をした時
    • then
      • どう動くか
  • spockとかcucumberとか

API編

  • Swagger
  • Spring Fox
  • Spring REST Docs

「SRE-SET Automation Night #2」に参加してきました

勉強会メモ

Ansible 2.5 におけるネットワークモジュールのトピック

Ansibleとは

  • 構成管理ツール
    • Simple
    • Powerful
    • Agentless

Ansibleのネットワーク対応

Ansible2.5

  • 2018/3リリース予定
  • 変更点色々
  • ネットワークモジュールにフォーカス

ネットワークモジュール

  • フォルダ構成のベストプラクティス公開
  • group_varsの利用

AWS Lambdaで作る GitHub bot

GitHub bot

  • PRにコメントで何かしてくれる
  • issueに自動的にラベリング
  • PRの内容チェック
  • GitHubAPIは多機能

PRのコメントに反応

  • SNS Eventで通知(github -> SNS)
  • SNS通知来たらLambda起動
  • GitHubAPIでコメント投稿

ライブラリ

デモ

Lambda -> GitHub

  • GitHubの設定でkeyを登録
  • AWSで暗号化したkeyを作る(Create KMS key for Encrypt)

SNS -> Lambda

  • SNS Topicsの登録
    • Lambdaを起動するというやつ
    • Lambdaにjsonが流れるようになる

GitHub -> SNS

  • GitHubの設定
    • Settings -> Integrations & Service
    • SNSを選べる

まとめ

  • システム関連携が大変
  • GitHubAPIのドキュメント重要

運用の負担を減らすログ送信システムの設計

ログ送信機構

  • 従来
    • flientdとかでBigQuerynに投げる
  • 見直し後
    • GCP活用
    • Cloud Storage
      • バックアップ用
    • Cloud Pub/Sub
      • ログ投げる側と受ける側の責務分けられた

要件

  • 欠損なく重複なく送信したい
  • 簡単な加工もしたい
    • BQのpartitionやテーブル振り分け
    • Pub/Subの重複排除
  • 人の作業を減らしたい

アーキテクチャ

  • Extractor -> Transformer -> Loader

どこまで自動化するか

  • 手動対応しないといけないケース
  • 例外の種別を明確にすることが大切

例外設計

  • warn
    • 想定されている
    • 自動対応化
  • error
    • 想定されている
    • 手動対応要
  • fatal
    • 想定されていない

各プロセス

  • 疎結合でべき等
    • 気軽に再実行
  • fatalが起きても他プロセスに影響しない

まとめ

  • 作業者の負担をできるだけ減らす
    • 例外種別をしっかり分ける
    • 冪等性の担保

退屈なブラウザ作業をpuppeteerにやらせたいお話

ブラウザ作業の自動化

やりたいこと

世界のカンファレンスから～SeleniumCamp 2018～

  • @mkwrd

メルカリの自動化への取り組み

メルカリの自動化

node-core-utils

Nodeそのものの自動化

  • jenkinsでCI
    • いろんな環境で動かないといけない
  • Bot
    • issueにラベル付け
  • node-core-utils

node-core-utils

  • git-node
    • コミットのルールのチェック
  • ncu-team

コミットのルール

  • masterに直接pushする
    • mergeボタン押すわけではない
  • ルール
    • 24時間待つこと
      • 世界各地にいるから
    • レビューは2人以上
    • タイトルの長さとか
      <ecosystem>: <title>

  <description>

  PR-URL: <pr id>
  REFS: <ref id>
  ISSUES: <issue id>
  Reviewed-By: <name>:<email address>
  Reviewed-By: <name>:<email address>

自動回帰テストフローとGitHub Apps

GitHubApps

  • GitHubAPI
    • API実行によるレポジトリ操作
  • Webhook
    • レポジトリに起きたイベントに反応

OAuth Apps

  • OAuthApps
    • GitHubアカウントに紐付く
  • GithubApps
    • レポジトリに紐付く
  • チームでやるならGitHubApps

求めていたもの

  • スナップショットの差分を見てテスト

スナップショットの更新要件

  • 差分があったか
  • その差分は意図したものか
  • 意図してればマージ

OSS作った

デモ

まとめ

  • GithubAPI
    • CIの結果をPRへコメント
  • Webhook
    • レビュー結果に応じてコメントを更新