「Developers Summit 2018」に参加してきました

勉強会メモ

技術選定の審美眼

世の中の動向

  • フロントエンド疲れ
  • キャッチアップするべき変化とそうでない変化の見極め
  • 差分とそれを可能にした技術が重要

技術の変化

  • 振り子にみえるけど螺旋
  • 同じところには戻っていない
  • 差分がある

変わらないもの

なぜ変わらないか

  • インターフェイスが狭く限定的
  • 振る舞いの種類が少ない
  • 実装に依存しない
  • Unix
    • 全てはファイルとフィルタ
  • REST/Web
    • 全てはリソース
  • RDBMS/SQL
    • 全ては集合

変わるもの

集中と分散

アプリとWeb

  • 変遷

  • 差分

    • 主戦場はモバイルへ

OSSと組織

決定的な違いをもたらした技術

  • Rails
  • Cloud
  • Docker
  • React
  • 上3つは今までできてたことの生産性を圧倒的にあげた
  • Reactは仮想DOMによって考えることを減らしたe
    • 手数は増えたが心配は減った
  • これらが何をもたらしたか理解しないといけない

取捨選択の軸

  • Simple
    • 客観的
  • Easy
    • 主観的相対的

属人化したフロントエンドのJavaScriptを、‘新規機能開発を止めずに’改善するために行った取り組みについて。及びその経過報告。

古いコードをリファクタした話

  • before/afterのafterがわりと常識的な内容だった

サイボウズのリモート開発 変わったもの×変わらなかったもの

新しいことを取り入れる時

  • 制度
  • ツール
  • 風土

サービス・メッシュ Istio を利用した Kubernetes でのマイクロサービス開発

Kubernetes

  • 開発/インフラ両方の知識を持って使わないと使いこなせない
  • そのまま使うのは大変

Kubernetesを使うと

  • Akkaとかでサーキットブレーカーとかをアプリに入れなくてよくなる

Istio

  • 共通的な関心事を引き受けてくれる
    • マイクロサービスのアプリがいろんな言語でも大丈夫になる
  • 分散トレーシングの機能もある
    • jeager(Zipkin的な)
    • 特定のヘッダーをリクエスト毎に伝搬
  • 新旧バージョンのアプリへの振り分け方をymlに定義するだけで設定できる
  • カナリアデプロイも設定書くだけ
  • タイムアウトの設定もできる
  • サーキットブレーカーもできる

多様なビジネスドメイン、サービスフェーズが混在する中での組織戦略と技術戦略

リクルート

  • リボン図モデル
    • ユーザとクライアント(企業)をつなぐモデル

リクルートテクノロジーズのこれまで

  • 組織が拡大していっている
  • 150 -> 700人
  • うまく回らないこともでてきた

ビジネス視点

  • １つのサイトにSoRとSoEが混在している
  • どの事業も同じくらいの利益/成長度合い(どれも100億くらい)
    • 優先度つけづらくリソースを集中させにくい
  • 新規プロダクトも立ち上がってる

アーキテクチャ視点

  • 型化
    • インフラ/FW
    • 例外的なのは別チームに依頼で効率悪い
  • 急速な成長で技術的負債

どう改善したか

  • チーム/開発の単位を適切に
  • 開発チームのリーダーが調整ごとに奔走
  • 学び
    • 苦手なことを何とかするために頑張ってしまう
      • 本来の強みが消える
    • 適材適所で

事例

  • WF＋agile
  • BFF入れた
  • Consumer Driven Contract
    • フロント側がAPI仕様を決める
  • Agreed
    • JSONでリクエスト/レスポンスを定義
    • フロントからはモックデータ
    • バックからはテストデータ
  • React/Redux,swift,kotlin
  • SRE
    • インフラをサイト別に切った

今後

  • SoEとSoR混ざってるのは厳しい
  • マイクロサービスも大変そう
  • 無理をせずに層を分けることを意識するくらいにしてる

最新技術に挑戦し続けるLIFULL HOME'Sアプリの開発について

LIFULL

  • LIFULL HOMESのアプリを作ってる

新技術を導入するための課題

  • アイデア提案
  • 導入時の困難に立ち向かう
  • 技術的負債の返済

アイデア提案

  • 長期目線で評価してもらわないとつらい
  • それが通じないなら風土を変えていかないと
  • モックで提案するとよい

導入時の困難に立ち向かう

  • 調査学習が難しい
  • 予期せぬ事態が起きる

AndroidInstantApps

  • インストールしなくても使えるようにする技術

  • Googleストアに「今すぐ試す」ボタンが出て来る

  • 苦労したこと

    • 大規模な依存関係の見直しをした
    • ライブラリが追従してくれてない

Tango

  • googleのAR技術
  • 空間を認識する
  • カーテンのイメージをARで見れる
  • 苦労したこと
    • サポートが2018/3/1で終わってしまう

ARKit

  • 部屋の間取りを計測できる
  • 苦労したこと
    • 3Dの開発技術持ってる人いなかった

AppleTV

  • 家族で家を考えるだろうから対応した
  • 苦労したこと
    • 対応していないライブラリばっかり
    • AWS接続を自力で
    • GoogleAnalyticsも自力で

技術的負債の返済

  • メンバー入れ替わってブラックボックス化
  • 機能追加のコスト
  • 新技術を導入しやすい設計
    • 抽象化
    • 統一化

抽象化

統一化

  • 型名は主に扱うデータ名＋レイヤ名
    • PropertiesPresenter
    • PropertiesUseCase
    • とか
  • UI実装の統一
    • ローディング
    • エラー

次の挑戦へ

  • 実績ができたことで次へつながった
  • 各自の強みを発揮
    • 多面的に改善

おまけ

  • Firebaseを使った検索
    • 検索の項目が多すぎる
    • 検索条件のレコメンド
  • RemoteConfig + RealtimeDatabase

さらばダミーデータ！～超高速開発を実現するテストデータ活用～

  • 16:20～17:05【15-E-6】
  • 岸和田 隆 [アシスト]
  • 拝島 渚 [アシスト]
  • 製品の宣伝だった

世の中の流れ

  • いろいろ変化してるのにテストデータは変わらない
  • ダミーデータを作ってテストしてる

テストデータ

  • できるなら本番データをテストデータとして利用するのがいい
    • マスク化
    • 容量

Delphix

  • 任意のデータを好きな時に高速に提供する
  • 本番環境と開発環境の間に配置
  • 変更履歴を蓄えていく

もはや定番！？Kotlinの概要再確認と2018年の使い方！

Kotlinとは

  • Javaっていいよねがまずある
    • 歴史長い人口多い
    • 後方互換性
    • 高性能高信頼性のJavaVM
  • でもJava大変だよね
    • 定型文の嵐
    • nullポインタ
    • 後方互換ありすぎて古い文法が残りすぎる
  • そこでKotlin

Kotlinの特徴

  • 簡単
    • コードの見た目が分かりやすい
  • Interop
    • Kotlin<->Javaの相互呼び出しできる
  • Android
  • 安全
    • 型安全null安全

Kotlin1.0

  • ;不要
  • 型推論による型省略
  • テンプレートリテラル
  • if-elseが指揮
  • 関数式ラムダ式
    • TypeScriptっぽい
  • データクラス
    • 簡単な宣言だけであとは内部で勝手に
    • Scalaっぽい
  • 拡張関数
    • Android KTX
    • 既存の型にメソッドを後から追加するようなイメージ
  • null安全
    • nullを入れる時は変数名に?をつける
    • ?があるとnullの可能性があるということ
    • ?がないとそもそもnull入れるとコンパイルエラー
    • var i: Int? = null
    • i?.toString()
      • iがnullだとメソッド呼ばずにnull返す
  • スコープ関数
    • 使い分け難しい
    • it使ったほうが分かりやすいかも
    • thisの方が混乱してしまいがち
  • プラットフォーム型
    • KotlinからJavaを呼び出した時のnullの扱い
    • NotNullでもNullableでもなくプラットフォーム型が返る
    • プラットフォーム型はNullable型に代入しておくのが安全

Kotlin1.1

  • コルーチン
    • 関数を途中で止めたり続きから始めたりできる
    • async/await
    • experimentalだけど本番導入してもいいとお墨付き
    • JSのasync/awaitの方が分かりやすいやってることは同じっぽい

Kotlin1.2

AndroidやWebでの活用

Android

  • Parcelable
    • Parcelにデータを書くために実装スべき形式/ルール
    • staticの代わりにcompanionオブジェクトに@JvmFieldをつけたものを使う
    • @Parcelizeつけるとかってに対応してくれる
  • Kotlin用のDI
    • KODEINとKOIN
    • Daggerというのもあるけどいろいろはまりやすい

Web

  • Kotlin × Spring
  • SpringBoot2からKotlin使いやすくなった
  • WebFlux
    • Kotlinと相性いい

ヤフーを支える社内システム

情シスとは

  • コミュニケーションの効果を最大化する仕事
  • なぜわざわざ内製
    • 自分たちに最適なものは自分たちで作るべき

開発

  • クリエイター = エンジニア + デザイナー
    • 6000人中3000人くらい
    • 社内システムのクリエイターは企画/開発/運用/改善など全行程

インフラの変化

  • 2005
    • 自分たちで調達
  • 2010
  • 2013
    • OpenStack
    • データセンターへ

技術の変化

社内システム

  • システム
    • 稼働中1200以上
    • 累計3500以上
  • アカウント
    • 12000以上
    • 累計32000以上
  • 社内システムはほぼ全てSSO
    • APIから全てのシステム参照可
  • 社内yahoo的なポータル
    • 100000PV/日
    • 検索10000回/日

PC管理

  • 社員全員にPCとiPhone
  • windows7000台mac10000台

文化

  • 全部自分たちで作れば何かあっても自分たちで対応できる
    • 必要なものは自分たちで作ってしまう文化
  • いきすぎた自動化も
  • 拠点作るとかも全部自分たちでやった

変わるもの/変わらないもの

  • 変わらないも
    • 自分たちで作る
  • 変わるもの
    • OSSを使う
    • 自分たちで自分たちのために作ったものを共有する

なぜ内製なのか

  • ビジネス/制度の変化に即座に対応できる

  • ユーザとコミュニケーションをとって開発する経験を積ませることができる

  • 情シスでは

    • 新しい技術を最速で多くの人に届けられる
    • 全てやるので一通りの知識がつく

大規模ログ集約実現のためのアーキテクチャ～誰でも美少女になれるVRシステム「VR Live Studio」からお届け

  • 12:10～12:40 【16-E-L】
  • 清水 佑吾 [gumi]

ゲームのログ

  • ゲームはほとんど更新
    • 一般的なWeb参照多めとは違う
    • ユーザの行動ログ
  • ログの使いみち
    • カスタマーサポート
    • チュートリアルどこまで見てるかとか
    • ゲーム難しすぎて途中で離脱してないかとか

ログ収集の課題

  • 利用者が使えるようになるまではログ収集
  • fluentdで収集してる
    • aggrigatoeサーバに集める
    • その後S3とかへ
  • よくあるトラブル
    • ログの欠損
    • 遅延
      • すぐに見えることに価値がある
  • 原因
    • ネットワーク
    • 過負荷
  • 障害が連鎖する
    • 集約サーバで加工もしてた
    • 集約サーバの仕事が多すぎた

ログ収集のトラブルの解決策

障害時の保管

  • kinesis
    • 高頻度のwrite/read対応
    • スケール
    • 24h保存しておける
  • AppサーバとかBatchサーバから直接kinesisへ

加工

  • Lambda
  • kinesisにデータ入ることをきっかけに起動

まとめ

  • 保管と加工を疎結合にできた
  • 役割が多いと障害に弱い
  • 変化に強い仕組みを

加速するフロントエンドとPWA

経歴

  • 大学時代websocketでMMORPG
  • 2012~ ゲーム
  • 2013~ quipper
  • 2014~ qiita

PWA使ってる事例

  • dev.toが速いという記事をかいた
    • 異常に速い
    • 「今」の常識でまっとうにつくるとこれだけ速い
  • 日本だと日経

PWA

競技

  • モダンブラウザユーザにはより良い体験をという方向性
  • モダン?レガシー?
    • ServiceWorler
    • レガシーはIE/safari

ServiceWorker

  • バックグラウンドで動くローカルプロキシ
  • あらゆるレスポンスを書き換え可能
  • 生存時間は15~30秒
  • メモリ使用量も制限

従来のWebライフサイクル

  • タブに対して一個のUIスレッド

ServiceWorkerのライフサイクル

  • UIスレッドとサーバの間にプロキシが入る
  • タブが閉じてもServiceWorkerは生きてる
    • push通知
    • オフラインキャッシュ
    • バックグラウンド処理

webの転換

  • サーバ直通 -> レスポンスは動的に変わるもの
  • history.pushState以来の変化
    • １つのページの滞在時間が増えた
    • メモリ管理state管理
      • SPA誕生のきっかけの一つ

オフライン化

  • サーバに到達する前に書き換えられる
    • キャッシュしとけばオフラインでもページを返せる
  • サーバとつながってるときにレスポンスをキャッシュしておく
    • index.htmlもキャッシュしておく
    • 画像も何でも全部
  • サーバがなくても起動できる
    • サーバに依存しない形態
    • アプリとして登録できる
    • androidならホームスクリーンに
      • androidはもうアプリいらないかも?
    • windowsはストアに登録できる

WebPackaging

  • 仕様策定中
  • webページを１つのバイナリにして配布する技術
  • AMPもWebPackaging対応で再構築される方向性のよう

アプリ化で競合する技術

  • Electron
    • Chrome GatewayAdd to homescreenに対応予定
  • ReactNative
    • web技術でモバイルを開発する環境という点で競合

なぜオフライン化大事か

  • googleはインターネット貧弱な環境が多いからという
  • 光が遅い
    • UXを突き詰めるために光速を超える

dev.to

  • サーバはheroku
  • fastly CDNがユーザのアクセスを受付
    • 初回リクエストをCDNでキャッシュ
    • リンクにオンマウスで遷移先をfetch&cache
    • レスポンスはServiceWorkerがcacheを消す
  • ブラウザはCDNとオフラインキャッシュしか相手しない

PWAまとめ

  • ServiceWorker
    • 透過的な高速仮想
    • 本格化はIE死んでから
  • PWA
    • ServiceWorkerを使って速度を追求

現実を見る

  • 本当にPWA時代来るのか
  • IE問題
    • IE11:2025/10/14
  • PushNotification問題
    • pushとpush notificationは依存するけど違うもの
    • safariは対応してない

パフォーマンス・チューニング

  • 指標のとり方
    • devtool
    • lighthouse
    • pupperteer
  • どんなものも作った時は速い
    • それを維持するのは難しい
  • 自分に必要な速度はなんなのか