「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人気ない使い方変わるかも

「Web Working Group 「PWAに備える3ヶ月」 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使った