「Azure Test Drive で OpenShift を体験」に参加してきました

コンテナ

  • コンテナはポータピリティが高い
  • 仮想サーバはOSから複製
  • コンテナはOSとの依存を切り離す
  • インフラもアプリも両方いい
    • どっちかが苦労してどっちかが楽ってわけではない

OpenShift

  • RHELが動く環境ならどこでも動く
  • コンテナ + オーケストレーション
  • PodとServiceは一対一
    • Podは上げ直すとIP変わる
    • サービス名をホスト名のように扱う
  • いろんなものにLabelをつけられる
    • それを使って連携していく
  • HAProxyでルーティング名前解決してる
  • ソースコードをビルドしてイメージを作れる

ハンズオン

OpenShift URL
https://masterdnsjsaeqvrpbhr2y.japaneast.cloudapp.azure.com

コンテンツURL
http://workshopper-workshop.6923.rh-us-east-1.openshiftapps.com/

ARM テンプレートを使った OpenShift on Azure のデプロイ
http://akubicharm.hatenablog.com/entry/2017/12/18/170745
  • 今後のバージョンだとistio使えるからもっと便利
    • OpenShiftの機能使うよりistio使うほうが主流になってくるだろうと
  • prometeousも3.9から入ってくる
  • サービスブローカを使ってAWSとかが提供するDB使うのも良い
  • Kubernetesの管理下にwindowsコンテナおいてwindowsサーバおけるようになる

家で今日やったことみたいなのを試すには

「MobileApp Design #1 【Ionic Japan/JXUG共催】」に参加してきました

IonicとXamarinの概要紹介

Xamarin

  • JXUG 田淵 義人(エクセルソフト)

Xamarinとは

開発手法

  • Xamarinネイティブ
    • UIをストーリボードとかOS固有のもので
    • ロジックはC#で共通化
  • Xamarin.Forms
    • UIをプラットフォーム間で共有できる
    • 共通/ios/android/uwpって感じでディレクトリ分けして書く感じ
  • 使い分け
    • さっと作る時はForms
    • ちゃんと作る時はネイティブ

Ionic

  • Ionic Japan 榊原昌彦

フロントエンドの流れ

  • bower死んだ
  • grantもgulpも死んだ
  • coffeeも出てきたけどもう消えた
  • 今はESもしくはTS
  • CSS使いづらいSCSS使おう
  • Angular/React/Vueの時代
  • ReactNative/Kotlinネイティブ
  • PWA

今後の流れ

  • PWAがあるからWEBもアプリにできる
  • BackgroundSync
    • オフライン時の操作をとっておく
    • 復帰時に再送できる
  • Push通知
  • ホーム画面追加
  • GPS/カメラ等へのアクセス

どうしてWebなのか

  • アプリのインストール率低下のデータが
  • Webサイトの利用時間増加
  • ストアから遷移するまでのめんどくささ

ionicとは

  • Cordovaを使うことでWebアプリをネイティブアプリとしてストアから落とせるようにするようなもの
  • android/ios/browserそれぞれ対応
  • andularが土台
  • PWAデフォルト対応
  • UIライブラリも同梱
    • ios/android自動でUIを変える
    • OSの文化に寄り添った見た目にした方がUXがよい
  • https://github.com/ionic-team/ionic-conference-app

Material DesignFlat Designの比較

Material Design

  • 2014のGoogleIOで発表

Flat Design

  • シンプル
  • ダイナミックなレイアウトや色使い

歴史

メリット/デメリット

  • メリット
    • 柔軟性のあるFW
    • より大きくより合理的なタイポグラフィ
    • レスポンシブデザインとの親和性
  • デメリット
    • ユーザビリティへの悪影響
    • 識別性の欠如
      • 似たようなものになりがち
    • 日本語に合わない
      • 漢字が複雑
      • カタカナとか画数少ないひらがなならなんとかいける

今後

マテリアルデザインとの比較

実践から考える「UIデザインの前にやらないといけないIAとUX設計」

UI設計

  • 情報のグルーピング
  • 情報の取捨選択
  • ページ間の意味の統一
    • 同じ見た目なら同じような情報を置かないと
  • ユーザの観察
    • キーボードで隠れる部分の使いかたとか
    • 機能に気づかれないと使ってもらえない

UIの構成要素

  • グラフィック
  • 機能要件
  • 情報設計

UX

  • アプリを使いたいんじゃなくてアプリを通して何かを実現したいと思って使っている
    • 利用前/利用中/利用後
  • ペルソナ
    • 誰をターゲットにするのか
    • 自分の都合のいい人にしてしまいがち
    • 知り合いを設定するとよい
      • 実際に話し聞いたりとかもできるし
  • コンテキスト
    • どういうシーンで使うのか
      • 砂漠で温かいおしるこを売ってもUXは低い
    • ユーザの持つ問題への理解と共感を深める
    • ユーザが望む本質を探求する
    • http://ykazu.com/ux/context-for-ux-design/

Webとアプリの違い

  • 繰り返し使ってほしいならアプリ
  • 一回でいいならWebでいい

まずはプロダクトを作ろう

  • プロダクトが存在しないと学べない始まらない
  • 作って反応を見る

【Xamarin.Forms】デザインと「よしなに」する方法

これからXamarinやるひと

  • 公式が一部日本語対応

Xamarinとは

  • .NETと互換性あるMonoプロジェクトをモバイルで動かせるようにしたFW

Xamarinのメリット

  • ネイティブに負けない
    • 実行速度
    • ライブラリ数
      • ネイティブ+.NETライブラリ
  • コードの共通化
    • アプリの規模にもよるが4割弱
  • ios/androidどちらも同じコードで書ける
    • 仕様をコードベースで揃えられる

Xamarin.Forms

  • プラットフォーム間でViewを共通化するためのUI Tool Kit
  • android/iosの差異をあまり意識せず作れる
  • .NET(MONO)とFormsの知識あればなんとかなる
  • VS上でプレビューできる
    • xamlというxmlでビューを書くと使える

デモ

  • ビルドはサンプルだからはやい
    • 機能があるともうちょっとかかる
  • xamlで書くのはかなりつらそう
    • 特にJSエンジニアからすると絶対に書きたくない
    • コンポーネント化できないってことなのかな?
    • RNエンジニアからするとすごく古い開発スタイルに見えてしまう

TabとNavigation

  • iosは常時タブを出す
  • androidは最初だけタブを出す
  • TabとNavigationどっちが親で子なのか

リーンアジャイルで開発を加速しよう

  • なかしょ
  • 中島進也さん

Sketchで実装しやすいデザインデータをつくる

105問のエムグラム性格診断の離脱率を激減させてバズらせるUIのお話

  • m-gram Inc. 松村有祐

「初学者向け「Kotlinでジェネリクスを学ぼう」」に参加してきました

Kotlinでジェネリクスを学ぼう

ジェネリクス概要

単純なコンテナを作る例

class Box(val value:Any)
  • Anyはあらゆる型の頂点(Nullableを除く)
  • Anyであることが注目点

  • 値を入れるのは簡単

val box: Box = Box("Hello")
  • だけど取り出しは大変
    • キャスト
    • 実行時に型でエラーの可能性

何をしたいか

  • あらゆる型に対応させたい(固定の方で定義したくない) VS キャストしたくない(Anyを使いたくない)

ジェネリッククラスの定義

  • 型パラメータが宣言されたクラス
    • 仮の型
class Box<T>(val value: T)

ジェネリッククラスのインスタンス生成

  • 値を入れる
val box: Box<String> = Box<String>("Hello")
  • 取り出し時にキャストいらなくなる

不変・共変・反変

  • variance
    • 変位/分散
    • 不変・共変・反変

クラスと型

  • 必ずしも一致しない
  • 1つのクラスに複数の方
    • String
      • String, String?
  • 1つのクラスに無数の型

不変(invariant)

  • サブタイプの関係が成り立たない
  • デフォルトだとこれ
  • Box<Int>Box<Number>を入れられない

共変(covariant)

  • 型パラメータと同じサブタイピング関係が成り立つ
  • outを使う
  • Box<out Number>Box<Int>を入れられる

型プロジェクション

  • 射影(projection)
  • RDBにおいてはカラムの選択
  • 型のある側面だけに注目
    • 逆に言うとある側面を隠す
class MutableBox<T>(var value: T)

val box1: MutableBox<Int> = MutableBox<123>
val box2: MutableBox<out Number> = box1
box2.value = 0.5 // コンパイルエラー
  • setterが削除されているから
  • 型プロジェクションにより隠された

反変(contravariant)

  • 型パラメータと逆のサブタイピング関係が成り立つ
  • inを使う
fn setDefault(box; MutableBox<in Int>) {
  box.value = 0
}
val box: MutableBox<Number> = MutableBox<NaN>
setDefault(box)
println(box.value) // 0
  • 値のセットだけできる

まとめ

  • 不変
    • 入出力
  • 共変
    • 出力のみ
  • 反変
    • 入力のみ

変位指定(宣言場所指定と型プロジェクション)

型プロジェクション

  • 射影(projection)
  • 使用場所変位指定
val box1: Box<Int> = MutableBox<123>
val box2: Box<out Number> = box1
  • setter隠れてるからout不要

宣言場所変位指定

class Box<out T>(val value: T)

ジェネリック制約

  • 型引数として指定できる型に制約をつける
    • 制約とは上限境界のこと
class NumberBox<out T: Number>(val value: T) {
  fn toInt(): NumberBox<Int> = NumberBox(value.toInt())
}

複数の上限境界

型消去とreified型

  • コンパイルすると型が消える
  • 型チェックはスタープロジェクションを使うと回避できる

具象型(reifiled type)パラメータ付き関数

  • reifiledを使う

メモ

「Forefront JavaScript ! 急成長中のサービスの技術達!」に参加してきました

CTO対談

  • 是澤さん(メルカリ)
  • 鈴木さん(スペースマーケット)
  • 辻さん(エアークローゼット)

エアークローゼット

  • 全部jsで統一
  • バックフロント区別せずみんな全部

airClosetのアーキテクチャと今後の展望

かつて

  • rails
    • レガシーなコード
    • セキュリティ脆弱性
  • モダンな設計へ
    • Reactへ
  • 更に汎用的に

ReactでSSR

ReactのCSS

  • CSS Modules
  • styled-components

成功した話

  • 頻繁にnpm-check-updates
    • 一気にアップデートすると死ぬ
    • こまめに上げておくと良い
  • Next.jsいい

失敗した話

  • RefluxJSを入れてしまった
    • Redux - Reducerって感じ
    • メンテされなくなった
  • CSS Spriteを使ったこと
    • 画像をなるべく一枚にする
    • HTTP2だと早くならない
      • 1枚あたりのサイズ小さくした方がいい

SSR用に作ったFW

スペースマーケットを支える技術

スペースマーケットの技術スタック

  • Rails
  • React
  • Swift
  • Kotlin
  • ReactNative
    • ホスト向けだけ
  • GraphQL

ローンチ初期

React × Rails時代

FWを統一

GraphQL

  • graphdoc
    • コマンド一発でAPIドキュメント
  • GraphiQL
    • クエリ実行環境
  • Apollo
    • GraphQLにクライアント

アーキテクチャと反省と改善

技術を統一して学習コスト下げる

  • 全部JSで
  • プラットフォームの違いがあっても共通の処理は共有
  • Lerna
    • monorepo実現のためのツール
    • webとnativeで処理を共通化
    • Storeがとてもきれいになる
  • Flow
    • nullチェックしてないとことか警告してくれる
    • model作ると相性良い

Flow

  • config分かりづらい
    • 慣れで
  • エラー分かりづらい
    • 慣れで
  • VUPですぐエラー出る

Formik

  • formのライブラリ
  • webとnativeでバリデーションを共有できる

アプリエンジニアが感じたReactNative導入の良し悪し

従来

  • iosandroid別のコードベースで作ってると
  • バグ改修もアップデートも2倍

RNを検討

  • 不安なことが多い
  • プロトタイプの作成にはよさそう

fastifyはいいぞ

fastify

  • web framework
  • オーバーヘッドが小さい
  • expressっぽい
  • validationをjsで書ける
    • swaggerっぽいことできる
  • ペイロードが小さいほど速い

これからのReactのスタイリングにはStyled Componentsが最高かもしれない

styled-components

storybook

Nuxt.jsでいい感じにGraphQLを扱いたい話

なぜGraphQL

  • サーバ側のステークホルダー多かった
  • GraphQLなら1つのエンドポイントでやりとりできる

Nuxt.jsでどう使うか

メルカリNOWを2ヶ月半でリリースした話し

webpack4について

v4リリース

  • BigChangeが大量
  • 設定ファイルなくても動くように

jsのnumber

ES2018とかのnumber

  • 整数
  • 少数
  • 8進数
    • 0oからはじめると8進数
  • 2進数
    • obからはじまると2進数
  • BigInt
    • まだStage3
    • 64bit以上
    • BigInt以外との演算できない
  • Separator
    • まだStage3
    • 数字の間に_書けるようになる

「Node学園 29時限目」に参加してきました

Nodeにコントリビュートし始めて一ヶ月でコラボレーターになった

きっかけ

  • OSS contribution guide
  • Node学園祭code and learn
    • コラボレーターとやる
    • できそうなissue集めておいてくれる
    • 世界各国でやってる
  • CoreとかTSCとかCTCとかいろいろある

内容

  • 最初のPR
    • functionをアロー関数に
  • ちょいネタは飽きたContributeみを感じたい
    • PRの数ばっか増えてもしかたない
    • 難しいのもやりたい
  • v8(C++)のコードを直した
  • テストのカバレッジを上げる
  • streamをさわるPRも出した

コラボレータになる

  • コントリビューターの候補をあげるissue
    • 自分も候補にあげてもらった
  • READMEに自分を加えてPRだしてレビューしてmasterに反映

コラボレータになって

  • レビュー英語で大変
  • コード理解してないとこもまだ多い

その後

  • nodeの中身わかってると実案件でも役立ってる − nodeの中読めばいいやって思える

コラボレータになりたい人へ

  • 英語は伝えようとする気持ち
    • 英語できなくてもPR出せる
  • ネタはたくさんある
    • 超簡単からC++まで
  • 1Contributeしたら2,3と続けてみましょう

headless chromeでクローラを作った話

ヘッドレスChrome

  • ヘッドレスChrome
    • Chromeをヘッドレスで起動できる
    • 主な用途はテスト自動化と動的クローラ
    • phantomJSよりはやい
      - 開発終了
      

静的クローラ

動的クローラ

  • ヘッドレスChrome
  • SPAでもクロールできる

問題もまだ山積み

  • API低レベル
  • 仕様不安定
  • セキュリティブロック
  • バグ踏む

GoogleChrime/puppeteer

  • puppeteer
    • 1.0.0リリースされたばかり
    • ヘッドレスchromeをラップしたもの

実用的な記事が少ない

作り方

ミニマムで作る
  • クローリング
    • htmlのリンクを見つける
  • スクレイピング
    • htmlから必要なものを見つける
  • jQueryでいいじゃん
    • jQuery無理やり埋め込んで要素取得
イライラしないクローラ
  • 静的クローラに慣れてると遅く感じる
  • Redisを使う
  • 複数のサーバでRedisを共有

分散環境を簡単に作りたい

  • 10並列くらいはないと実用的でない
  • ServerlessFW

ECMAScriptの使い方

ECMAScriptとは

  • EcmaInternationalという団体によって標準化されている
  • 2015からは毎年リリース
  • 2015以前は全ての合意されてから一括リリース
  • 2016以降は合意の取れたものからリリース

プロポーザルステージ

  • 4までは未完成
  • 4になるにはテストが必要

ECMAScriptを学ぶ

  • 仕様を学ぶ
  • 正しい使い方か調べる

アロー関数

  • thisをバインドするは仕様上正しくない
  • thisを持たないから一個上のスコープのthisを使う

Dynamic import あれこれ

imoprt

  • グローバルスコープでimportしないといけない
  • 実行時に全部imoportが確定していないといけない
  • 動的importの需要がある

DynamicImport

  • ES2017の新機能
  • 関数呼び出しスタイル
  • Promiseを返す
  • 名前付きだけdefaultはない

課題

  • moduleを差し替えたりするとnode再起動時にエラーでるタイミングがある

まとめ

  • クライアント側だと厳しいかも
  • サーバ側なら要件次第でいける

npm prepublish の現状と今後どう変わっていくかを調べてみた

npm script

  • preとかpostとかつけると実行前に動いてくれてリとか

npm republish

  • publishの前に実行するよと
  • prepublishがpublishする前だけに動くはずなのにそうじゃないときも動く
    • localでnpm installするとなぜか動く
  • 直に修正される

rxjs v6 について

  • berlysiaさん

v5からv6への変更点

  • ファイルサイズを小さくしたいという方針に変わった

pipeable operator

  • lodashのflow関数みたいなやつ

構造が変わった

  • deep imoprtできなくなった

まとめ

  • 仕様変わりまくってるから注視しておかないと

introduction to JAMStack

  • sotayamashitaさん(Locki)

JAMStack

  • 2016年くらいから海外ではやってきた?
  • 再利用可能なAPI及び事前にビルドされたマークアップで構成される最新のWeb開発アーキテクチャ
  • JAM
    • JS
    • API
    • Markup
  • git push -> CD -> CDNへデプロイ
  • より速い、高セキュリティ、スケーラブル、低コスト

背景

  • git
  • microservices
  • ES2015

構造

  • ブラウザ <=> クライアント & Micro Services <=> ビルドツール
  • CDN <=> Continuous Delivery <=> Git

事例

なぜ今JAMStack?

  • ネットワーク環境が整ってない国
  • 海外でマイナンバー的なやつのハックが起きているからセキュリティ重要視

まとめ

  • JAMStackとは
    • ブラウザからのリクエストとブラウザへのレスポンスは全てJS で行う
    • DB のクエリを叩くのではなくそれらを抽象化して API を叩くようにする
    • view はサーバのランタイムではなく、デプロイ前にビルドしておいて表示する際はただ表示するだけ
  • JAMStackのベストプラクティス
    • 静的ファイルは CDN にばらまく->ロード時間短縮
    • 動的部分は API で対応。
    • 必要なサービスのドメインで特化しているサービスがあればそこに責任を移譲する->セキュリティー強化

「Mercari Web / Frontend meetup #1」に参加してきました

Modern Webを作ろう / Progressive Web Apps と AMP

ModernWeb

  • Modern Web is now mainstream
    • 去年のGoogleIOで繰り返し言われてた
  • アプリからWebに帰ってきた

ユーザが求めるもの

  • 速いWeb
  • 古いWeb
    • ロード遅い
    • レスポンシブじゃない
    • コンテンツ動き回る

速いとは?

Webサイトを早く表示するためのフレームワーク

AMP

アプリのようにリエンゲージ

  • ModernWebはホームに追加できる
  • アプリのように動く
  • スプラッシュ画面もある
  • manifest.jsonを書くとできるようになる
    • ServiceWorkerは必須
  • beforeinstallprompt
    • ホーム追加のプロンプトが出る直前に発火するイベント
    • プロンプト出したくない場面ではこれを監視しておくといい

オフライン対応

  • オフライン時はフォールバックページを返す
  • ServiceWorkerで実現

プッシュ通知

  • パーミッション求めるプロンプト出すタイミング注意
    • サイトに入ってすぐは悪い例

フォームの入力を自動で

  • CredentialManagementAPI
  • ブラウザに保存したID/PWを使って勝手にログインしておいてくれる

支払いフォーム

ModernWebとは

  • PWAとは
  • 新たなUXの基準
    • プッシュ通知
    • ホーム画面追加
    • パフォーマンス
    • 常にログオン
    • 簡単な支払い

Whats Next

  • ios11.3からServiceWorker使える
    • プッシュ通知はできないっぽい
  • MicrosoftStoreにPWAアプリを出せる

メルカリにおける PWA と AMP について

  • 小嶋 仁司氏(メルカリ)

Mercari Web

  • 流通量1日100万点
    • 商品の詳細画面が1日100万ページ増えるということ
  • アプリファーストから多様化へ

AMP

  • 2016/7詳細ページをAMP化
    • アクセス速度は向上した
    • でもgoogleの検索からアイテム詳細に遷移する導線が少ない
  • 2017/11カテゴリページをAMP化
    • 比較的検索されやすいところから
    • 自然検索流縫う45%増(他の要因もあるが)

PWA

プッシュ通知

  • 2017/8プッシュ通知を実装
    • 基本的にアプリと同一の内容
    • ブラウザ経由でnotificationの許可の難易度の高さ

オフライン対応

今後

  • US Webから着手
    • 通信弱いところから
  • JP Webは体制整い次第
  • mobile safariどうするか

これからのWebにおけるSSR / BFF について

BFF

BFFとは

  • Backends for Frontends
  • フロントエンドのためのバックエンドのこと
  • APIを束ねたりページを作ったり

なぜBFF?

組織的な話
  • これまでのWeb
    • モノリシック
    • Ajaxインタラクティブ
    • テンプレートからJSを呼び出してしまったり
    • JSでDOMの中ゴリゴリロジック書く
    • 暗黒のUIになる
  • Webアプリケーションフレームワークだからといってなんでもやるのはダメ
    • 権限を分離したい
  • データ管理はバックエンド
  • UIはフロントエンド
    • UI
    • BFF
歴史的な話
  • 名前がついただけで新しい話ではない
  • まずはフロントエンドとバックエンドに分ける
  • よりコンテクストを意識してマイクロサービス化を検討

SSR

SSRとは

  • Server Side Rendering
  • ClientSideでHTMLを作るのと同じロジックコンポーネントを使ってサーバ側でもやること

なぜSSR

SEOのため
  • googleのクローラは100%JSを実行してくれる保証はない
First View Performance
  • First View Performanceをより速くする
  • FirstMeaningfulPaintまでの速度を上げたい
    • SPAではFirstMeaningfulPaintとTimeToInteractiveはほとんど一緒
    • ClientSideRenderingだけでは時間が無駄
  • そこでSSR
  • BBF導入するときはSSRまでセットのほうがビジネス的メリットが大きい

実践例

まとめ

  • BFFはなんのため
    • 権限分離と開発しやすさ
  • SSRってSEOいらないならいらないんじゃ
    • FirstMeaningfulPaintを最適化するために必要
  • BFF/SSR難しいんじゃないか
    • 最初は設計難しい
    • Next.jsとかNuxt.jsとか出てきてる

「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人
  • うまく回らないこともでてきた

ビジネス視点

  • 1つのサイトに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以来の変化
    • 1つのページの滞在時間が増えた
    • メモリ管理state管理
      • SPA誕生のきっかけの一つ

オフライン化

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

WebPackaging

  • 仕様策定中
  • webページを1つのバイナリにして配布する技術
  • 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
  • どんなものも作った時は速い
    • それを維持するのは難しい
  • 自分に必要な速度はなんなのか

「Inside Frontend #2」に参加してきました

freeeのアクセシビリティ、いまとこれから

アクセシビリティ

freeeのサービス

  • Webサイト
  • アプリ

Webサイト

アプリ

  • 読み上げない場合あり
    • アイコンにラベルがない
  • 関連づかない場合あり
    • フォーム(for属性)

Webサイトのこれから

AMA

  • A11yから遠いと感じる業種
    • エンターテイメント系
    • ゲーム、映画
  • タッチスクリーンによって指が目の代わりになってきている
  • 新規の時にコストをかけずに入れられるとよい
    • CIでlint入れるとか

参考

現場の ES201x とアーキテクチャの変遷と未来

フレームワークの振り返り

過去

変遷
  • 2003: jQuery
  • 2010: Backbone
    • Flashがなくなり始めて
  • Angular,React
太古
テンプレーティングの時代
  • コンポーネント的のな概念がでてきた
  • htmlの生成がクライアント側へ
    • underscore.template, handlebars
データバインディングの時代
  • 木構造を出力するものへ
  • データを更新すると描画も変わる
    • backbone.stickit,knockout, Angular.js
  • MVVMの導入

現在

  • ClientSideMVCの終焉
    • =Backbone
  • Rails由来のBackboneのMVCモデルは破綻
    • クラサバで必要な抽象は別物だった
  • 単方向データフロー

Flux,Obvervableの時代

  • EventとStateとViewを分離
  • Ex, Elm, Redux
  • FunctionalReactiveProgramming
  • Componentの内側にあるstateは悪
  • ReduxはRxのサブセット

トレンド

  • データをメモリに置くようになる
    • 仮想DOMによるバッファリング
  • ブラウザの機能をより賢く実装する
  • JS
    • 毎年更新
  • 多言語由来系
    • ScalaJSとか
  • WebAssemply系
    • Rust系があつい
  • AltJS
    • ES201xに吸い込まれて消滅
    • 生きてるのは型系
  • なぜ型?
    • テストが書きづらい
    • 静的チェックで済ませたい
    • observableがimmutable前提だと静的チェックないと作れない

未来

WebComponents
何が出来る
  • 泥臭いことしかない
  • 良いコード
    • 静的チェックできる
    • コードを捨てられること
      • QiitaのReact -> hyperappとか
  • lint
    • prettier
    • eslint: prefer-XXX
    • eslint: no-unused-vars
ゴール設定
  • スピードを突き詰めるのか
  • 継続して価値を届けるのか

まとめ

AMA

コンポーネントTDDの実践から見えたもの

コンポーネント単体テスト

リリース前

  • コンポーネント単体テストは書かない
  • ケースが複雑でコストが高い
  • リリース後にE2E/スナップショット入れればいい
    • 入れる時間ない
    • 今の開発フローのどこに入れる?
  • レビューに時間がかかるよういなる
    • 動作確認が..

コンポーネント単体テスト何使うか

  • Reactはenzyme
  • Vueは@vue/test-utils
  • Shadow関数mount関数

何を確認

  • porpの確認
  • DOMが意図したものか確認
  • イベント処理の確認

テストどうやって書くようにするか

  • 新規は必ず作る
  • 不安感
    • すぐ壊れる
    • 実装に対するテストケース
  • TDDやってみよう
    • 仕様に対するテストが書けるはず
    • 実装が変わっても壊れないはず

TDDの進め方

  1. テストを書く
  2. 動かして失敗する
  3. 実装する
  4. リファクタする

TDDのコツ

  • 仕様について考えて仕様に対してテストを書く
  • テストも小さくステップを踏んで書く
  • それでとりあえず通す
  • view的なロジックをテストする
  • react自体のテストにならないように注意する
  • 要素にはカスタムデータ属性をつけること
    • data-testid

TDDやってみて

  • 手が止まる時間が多い
    • 仕様を考える
  • 実装ははやい
    • ゴールが明確なので
  • トータルは変わらない
    • テスト書く前提なら?

テストコードの質

  • テストコードもソースコード
  • テストもちゃんとレビューする文化
  • テストコードもリファクタするべき

動的デザインガイドのつくり方

DesignSystemについて

  • SGDD
    • style guide driven development
  • Living Design Guideline

DesignSystemとは何か

  • 定義したデザインを迅速にプロダクトに反映させるシステム
  • デザイン系
    • 統一されたUX
    • 再利用性
  • 開発
    • 低コスト
    • 再利用性
  • 仕様

動的デザインガイドラインの作成ポイント

  • コードを参照してデザインガイドラインを作ること
    • ReactでいうとStoryBook
  • 他レイヤーの情報を含める
    • デザインの意図
    • 使いかた
    • ビジネス仕様
      • 技術情報しかないUIの羅列だと技術者しか役に立たない
  • UIコンポーネント間のデータ型を明確に定義する
    • UIが受け取る型を定義しておく
    • 同じデータを渡せばいつでも同じものができる状態

DesignSystemの事例

GYAOでの事例

古い構成から移行させる

  • ReactのようなモダンなFW必要?
    • なくてもできる

どうやって既存システムに適用したか

  • コードをロジックとテンプレートにわけること
  • コンポーネント化する
  • 通化出来るものは更に細分化
  • ViewとServer間のデータ定義をJSON-schemaにした

分類

  • Script
    • 動作
  • Style
    • スタイル
  • Template
    • テンプレート
  • README.md
    • 業務仕様も
  • package.json
    • モノレポにする

micro-benchmarking is hard

ベンチマークを作る

Webkit

  • 実行エンジンによっていろいろ最適化している
  • とりあえず10万回回してパフォーマンスとるとかは正確じゃない
  • 有名所のベンチマークでもやらかしてる
  • 検証対象の使われ方によって何をどう測るかも変わってくる
    • たくさん回せばいいなんてことじゃない
  • ポイント
    • returnしたものを使う
    • そうしないと不要だと判断されて消される

日経電子版を速くするためにやっていること

「規約に同意」のUX -ストレスフリーな同意UIとその実現方法-

攻めつづける FRESH! の Web ver.新春

Varyヘッダとキャッシュバリエーションの将来

「Cookpad TechConf 2018」に参加してきました

毎日の料理を楽しみにする挑戦をし続けた20年

クックパッドとは

  • 毎日の料理を楽しみにする会社
  • クックパッドはテックカンパニー

プロジェクトの進め方

クックパッドの “体系的” サービス開発

  • 新井 康平

サービス開発の難しさ

Build

  • 不必要に大きくしてしまうと検証したいことがぶれてしまう

Measure

  • 複数のA/Bテストが衝突して計測がぶれる
  • 正しく計測できているか

Learn

  • 出てきた数字をどう解釈すれば分からない
  • 数字は出たが学びを得られない

失敗しないために

  • 前から順番にループを考えない
  • 逐次的にすすめると手戻りが起きる
    • 最初にサイクル全体を設計するべき
  • サービスに対する理解(施策結果の予想)と現実のギャップ

フレームワーク

クックパッドクリエイティブワークフロー

  • 辻 朝也

開発チーム構成

  • 1サービス140人
  • 2w~1m
  • 利用シーン別に区切ってその中に複数チーム
    • 投稿
    • 検索
    • 記録

事例

  • ミッションオーナー
    • 目標責任
  • デザイナー兼ディレクター
    • ユーザー体験の責任
  • iosエンジニア
    • 技術的責任
  • androidエンジニア
    • 技術的責任

施策・体験

  • 目的と仮設を明確にする

デザインレビュー

  • なぜそういうデザインにしたか
  • チーム内外でレビュー
  • issueに蓄積

施策の指標とレビュー

  • ログについても全員で話す

テスト

リリース後分析

デザインリリースマネージャー

  • バージョン単位でUI変更ある箇所を把握しデザイン周りを一貫して管理

What/How to design test automation for mobile

  • 松尾 和昭
  • appiumのメインコミッター

テストを自動化したい

SPLIT

Scope

  • テストの範囲

Phase

  • 開発中のテストなのか
  • 本番稼働中のテストなのか

Level

  • どこまでテストを進化させるか
  • 何をテスト?
  • どう実装?
  • どう計測?
  • どこまで自動化?

size

Type

  • どのような目的を持ったテストなのか
    • ロジックが正しく動いているかのテスト
    • パフォーマンスのテスト
    • UIのテスト
  • 縦軸
    • BusinessFacing
    • TechnologyFacing
  • 横軸
    • GuideDevelopment
    • CritiqueTheProduct

Rubyの会社でRustを書くということ

  • 小林 秀和

クックパッドで使ってる言語

クックパッドのpush通知

  • 都度配信
  • 一斉配信

クックパッドのアプリ構成

  • railsのモノリシックだったけど小さいアプリはマイクロサービス化してる
  • push通知基盤貧弱だとダメになってきた

新しいpush通知配信基盤

  • 受信設定クエリ
  • ARNクエリ
  • SNSに通信
  • こうすることでユーザIDとメッセージ放り込めば通史が行く
  • 数百万件通知
  • rubyじゃ向いてない
  • そこでrust
    • データ競合の可能性のあるコードをコンパイルで検出
    • 速度安全性並行性

Rustのいいところ

  • マルチスレッドが安全
  • 安心して高速化に取り込める
  • 汎用ライブラリ化しやすい型システム

cookpad storeTV 〜クックパッド初のハードウェア開発〜

  • 今井 晨介

StoreTV

  • スーパーに置いてある小さいテレビみたいな
  • スーパー
    • 無料で商品販売促進
  • 買い物客
  • 食料品メーカー
    • 購買促進

ハードウェア開発

  • ソフトウェアと同じようにサイクルを回す
    • サイクルは長めになる
  • 第1サイクル
    • 最小価値検証
  • 第2サイクル
    • スケール
  • 第3サイクル
    • 収益化

第1サイクル

  • 最小価値検証
  • ストアに電話調査
  • アプリ利用率
  • 売上

第2サイクル

  • 何をやって何をやらないのか
  • 得意なことは自分たちで、不得意なことはひとりでやらない

第3サイクル

  • 広告の追加
  • アプリのバグ対応
    • 長時間可動によるバグ
    • 今までやってる開発と違う観点
    • 負荷検証
  • 顔認識も入れてどれだけの人に見られたか情報を集める

Challenges for Global Service from a Perspective of SRE

  • 渡辺 喬之

クックパッドのグローバル・サービス

  • 海外向けに日本のとは異なるサービスを提供している
  • 22言語68カ国
  • スタッフは世界中に点在

グローバルサービスの成長

  • 対応言語ここ1年で15 -> 22言語に、58カ国->68カ国
  • 料理は地域と密接

グローバルサービスにおけるSREの課題と挑戦

特定の国のユーザ体験が悪い

  • その国に住んでないので同じ環境でテストできない
    • 68カ国あるから直接いくのは大変
  • 定点観測した
    • Catchpointを使った
  • 米国から遠いとレスポンス悪い
    • サーバは米国と日本
  • Fastlyを導入した

イベントがとにかく多い

  • 祝祭日などのイベントが地域によってある
    • そのタイミングでアクセス増
    • 日本だとバレンタインでアクセス急増
  • 展開国数が増えるとイベントも増えて負荷も増
  • 全てのイベントに都度対応は難しい
    • 時差もあるし国もどんどん増えてるし
  • DBはAurora
  • Dockerアプリ開発環境の提供

デプロイのオペレーションコストが高い

  • 日本で可能なことが海外ではできないこともある
    • 長時間停電とか
  • 世界のどこからでもデプロイできるようにしたい
    • Slackからデプロイできるように
    • 誰がやっても同じようにできる

toilが急増する

  • toilにあてはまる業務
    • 手動対応
    • 自動化余地がある
    • 繰り返し発生
    • 発生してからじゃ遅い
  • toilが急増してやりたいことができない
    • アカウント管理周りの依頼が特に多かった
    • 社員数の増加
    • 開発ツールの増加
      • 世界中でVPNが使える環境にあるわけではない
        • basic認証ツール増える度にいれてらんない
  • nginxとomniauthによる社内ツールアクセス制御

動き出したクックパッドのCtoCビジネス

  • 村本 章憲

C to Cの新サービス

  • komerco
    • モノで毎日の料理を楽しくする
    • 食器

komerco

  • EC
    • product
  • media
    • story
  • cookpad
    • recipe

komercoの技術

firebase

  • 高速
    • APIを作らなくていい
  • セキュリティ
  • オートスケール

OSSとして公開

  • OSSとしてライブラリを公開する
    • 外部からのバグ報告
    • 公開することを意識して疎結合化促進
    • 再利用できる

Solve "unsolved" image recognition problems in service applications

クックパッドのR&D

  • いろいろやってる
  • その中で今日は画像分析

画像分析

  • 機会は人間より優秀になっている
    • ただし理想的な状況下であること
  • ポイント
    • 適切なラベルの付与
    • 適切なカテゴリの設計
    • closed set
  • 実サービスで解くべき問題が何なのか
    • 間違ってることがおおい
    • trial&errorで探っていく
  • 画像分析に限った話ではない

事例

料理きろく

  • ユーザの端末から料理の画像だけを引っ張り出す
  • 解きたい問題がなんだと思ってたか
    • 画像が料理なのかどうか
  • やってみると考える事とても多い

モバイルへの移行

  • 今後対応していく

Beyond the Boundaries

  • 成田 一生

料理とインターネット

  • インターネットがないと本を買うとか親から引き継ぐとか
  • インターネットによって広く共有できるようになった

クックパッド2018の技術スタック

  • rails
  • go
  • rust
    • ハイパフォーマンスを安全に
  • swift
  • kotlin
  • ReactNative
    • プロトタイプ向けにつかってる
  • firebase
  • ECS
  • Docker
  • Hako
    • デプロイツール
  • rubyのコントリビューターもいる
    • 自分たちの使ってる技術が廃れないように自分で育ててく

文化

  • Beyond the Boundaries
  • 境界を認識
    • 自身の役割
    • 自身の技術力
  • 人が増えて役割が特化
    • 役割を飛び越えていろいろやたせたい
    • 社内hackarade

テックリード制度

  • 部門内のミニCTO
    • 技術選定
    • コードレビュー
    • メンタリング
    • エンジニア評価

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

Swagger駆動開発と最新のRedux構成

  • andoshin11

API開発の問題点とSwagger

課題

  • 定義書のフォーマットどうする問題
  • 定義書のバージョン管理どうする問題
  • 実装待ちどうする問題
  • これら全部Swaggerでかいけつできる
定義書のフォーマットどうする問題
定義書のバージョン管理どうする問題
  • Git使おう
実装待ちどうする問題
  • スタブサーバ欲しい

Swagger

  • REST APIを作れる
  • json,yamlで定義できる
  • 定義書自動生成される
  • 関連ツールがとにかく多い
SwaggerEditer
  • Swaggerファイルの編集ツール
  • 即時構文チェック
SwaggeCodegen
  • APIスタブ生成ツール
  • SwaggerEditerに組み込まれてる
SwaggerUI
  • ブラウザで動くAPIドキュメント

Swaggerの開発フロー

いけてない運用例

  • SwaggerEditerで定義
  • サーバーをgenerate
  • zip解凍 & yarn install
  • SwaggerUI出力
  • yamlの入出力が手動
    • せっかくgit管理してるのに・・・
  • API更新の度にzipダウンロード解凍起動

もっとスマートに

swagger-editer-live
swagger-codegen

CodePush と Circle CI でリリースを高速に回す

NativeアプリをWebのようにリリースしていこうという話

CodePush

  • OTA(Over the Air)
  • microsoftが作ってる
  • ネットごしにJSコードをアップデートできる
    • nativeのモジュールは更新できない
  • VisualStudioAppCenter

CodePushのセットアップ

  • 公式に書いてある手順で簡単
    • CodePushをアプリに適用
    • CLIインストール
    • AppCenterに登録
    • リリース
  • アップデートのタイミング
    • ポップアップでアップデートするかだしたりとか
  • コマンドでリリースできる
    • RollBackもできる
  • githubと連動して動かせる

ReactNative開発を高速化させる技術

どんなツール使ったかの話

React Nativeで作る色々なジェスチャー

ジェスチャーの作り方

タップ

長押し

ダブルタップ

  • Touchable*系をラップして独自で作る
  • 前回タップとの間隔見て処理する

ドラッグ

  • PanResponder

スワイプ

  • PanResponder
  • 閾値を設定 -閾値を超えたらスワイプ発動

ピンチイン&ピンチアウト

  • PanResponder
  • gesturesStateの中の情報で拾える
  • native開発者視点で

ReactNavigation

  • transitionが違和感
  • 特定のタイミングで処理をはさみたいとかがしづらい

ReactNativeNavigation

  • RNとNativeのハイブリット対応してない

airbnb/native-navigaiton

自前で書いた

  • 自前でもけっこうできちゃう

BLE on React Native

BLEとReactNative

  • BLE
  • ハードウェアと協業
  • 技適取得済みチップを使うこと
  • react-native-ble-manager
    • react-native-bleはメンテされてない
  • セントラル
    • クライアント
  • ペリフェラル
    • サーバ
  • Androidだと処理が遅くてうまくいかないことも
    • 適宜waitすることで対応

メモ

  • pre-commitというnpmモジュール使うとcommitした時にnpm-script動かせる

「Polymer Japan Cafe #1」に参加してきました

Polymer Japanの活動紹介とイベントの概要説明

  • jtakiguchi

WebComponents

  • 再利用可能な独自のHTMLタグを作るための標準技術仕様

背景

  • URLアクセスして表示されるだけ
  • ajaxで非同期リクエス
  • HTML5(HTML+CSS+JavaScript)
    • SPA
  • フロントエンドエンジニア
    • 複雑化
    • コードやデータをどう体系化するか
  • ブラウザベンダー
    • ベンダー間でWebの標準化

仕様

  • Custom Elements
  • ShadowDOM
  • HTML Template
  • HTML Imports
    • 廃止
    • HTML ModulesとかESModules

Polymer

  • 独自のHTMLエレメントの作成をサポート
  • アプリを構築するJSライブラリ

特徴

開発元

  • chromeチームが作ったもの

事例

最近の動向

  • TS対応
  • bower -> npm
  • HTML Imports -> ES Modules

Polymerで始めるWebサイト制作

  • takanorip(スマートドライブ)

Webサイト制作における課題

  • Polymerを使うと
  • 環境構築が面倒
    • ほとんど何もしない
  • グローバルなHTML/CSS
    • scoped
  • HTML/CSSを共有したい
  • Web標準技術で実現できる

環境構築が面倒

グローバルなHTML/CSS

  • shadowDOM
    • dom-moduleタグの中にhtml書くとスコープが絞られる
    • templateタグの中にstyleタグを書くとそのtemplateだけにスコープが絞られる
  • データバインディング
    • 属性で値を渡す
    • <button>[[buttonText]]</button>
  • HTML/CSSを共有したい
    • SASSみたいな書き方ができる

PWA

  • ios11.3でsafariがServiceWorker対応で話題
  • Polymer単体でもPWA使える

PolymerのSEO/SSRの対策と手法

  • aggre

他のJSFWとの違い

  • 静的なHTML取得
    • ファイルを探して返す
  • 動的なHTML取得
    • HTMLになる文字列を生成して返す
  • Polymerだと
    • ShadowDOM
    • ブラウザ側で作られる

「Vue.js入門勉強会@渋谷」に参加してきました

[LT] Vue.js入門

  • 高山氏

Vueの誕生

  • angular開発に関わってた人が作った
  • angularの中の好きだった部分だけ抽出したもの
  • 中国で多く使われてる
    • 作者中国出身
  • バージョンアルファベットの頭文字
    • 日本に関わるの多い

特徴

親しみやすい

  • html,css,jsを知ってれば書ける
  • for文とかangularっぽい
    • v-for

融通がきく

高性能

  • ミニマムで20KB
  • 仮想DOM

[LT] vuexについて

  • 竹末氏

vuex使ってみた話

  • vueにおけるflux実装
    • ステート
    • ゲッター
    • ミューテーション
    • アクション
  • 入力フォームには不向き

store

  • storeに処理がある
    • 通信とかも
    • アクションも定義してある
    • getterもmutationもstoreの中にある

mutation

  • ここでstateを更新

weex

  • react-nativeのvue版

[メインコンテンツ] Nuxt.js入門

Nuxt.js

  • ユニバーサルなVueアプリを構築するFW

メリット

  • SSR
  • webpack設定いらない
  • vuexとかvue-routerを使いやすくする
  • モジュール機能によって機能追加可能
  • minifyとかcode splittingとかhttp2とか対応

デモ

  • ディレクト
    • pages
      • ファイルパスがURL
    • assets
      • SCSSとか画像とか
    • components
    • store
      • vuexのストア
  • ホットリロードもある
  • storeの設定もいろいろ勝手にやってくれる

HelloWorldまで

npm i -g vue-cli
vue init nuxt-community/starter-template nuxtdemo
cd nuxtdemo
npm run dev

「React.js meetup #5」に参加してきました

Opening Talk (10min)

React17

Talk: Static sites with create-react-app and Junctions (20min)

15分でアプリを作る

  • create-react-app
  • junctions
  • create-react-appだとビルドしたあとのhtmlの中はscriptタグだけ
    • SNSとかにはっても何も出ない
    • junctionsつかうと対応できる
  • junctions staticを使うと複数のhtmlを生成できる
  • mdファイル読み込んでcomponent生成できる
  • surge

Panel Discussion about React (40min)

  • @james_k_nelson
  • @yosuke_furukawa
  • @yoshiko_pg
  • @koba04 (moderator)

Reactに足りないもの

  • 業務的にformを作ることが多い
    • 入力項目多いときとか
  • SSRとその後の画面行く時にスムーズにいかない?
  • アニメーションが大変
  • ルーター
  • 裏側でsetStateして準備できてから遷移とか最近できてきてる

サードパーティライブラリ

CSSどうしてる

  • @yoshiko_pg
    • styled-component
    • ひとりで全部作るならいい
    • デザイナーさんとかいるとうまくできない
    • 普通にSCSSでBEMでなんとかなってる
    • CSSの見た目が維持されてる方が好きとか
      • JSオブジェクトではなく
      • CSS生成するツールとかで対応しづらくなるから
  • @james_k_nelson
    • LESSとCSS modules
    • CSS in JSセキュリティ問題ある
      • tooltipでxssできちゃうとか最近出でる
  • @yosuke_furukawa
    • SASSとかSCSS
    • SSRするときコードが多いとスプリットしないで同期ロードしてる
      • SSRのときのほうが早くCSSあたる

React教える時

  • Reduxもまとめて教えちゃう
    • 古川さんはReduxおし
  • Reactだけでも作れる
    • jsxもなくてもいい
    • babelとかもいらなくなる
  • 複雑にしてるのはレイヤーを分けたいから
    • 色んな人が関わって作るからルールを作って強制している効果がある
  • html,css分かる人相手の時と、JS自体は書ける人相手のときとか

ロジックどこにおく

  • 本当にピュアなロジックならUtil
    • componentのutilsとか
    • npm_modulesにしちゃうとかも
  • でもドメインからむことが多い
    • それはReduxの世界へ
  • apiからもらったものをreducerで使う時変換したいとき
    • selectorってのを使う
      • RDBでいうところのビュー
    • プロパティ省いたり変換したり

Reactの読み方(仮) (10min)

Reactのリポジトリ

  • monorepo
    • packageの中にいろいろ

Redux のディレクトリ管理を考える (10min)

Reduxのディレクトリ構成悩む

  • コントリビューターも悩んでる

論点

  • component設計
  • store設計

component設計

  • container
    • reduxと繋ぐ部分
    • viewを書くとこではない
  • presentational
    • viewのみ
    • reactのみ
    • reduxを意識しないもの

store設計

  • rails-style
  • domain-style
  • ducks
rails-style
domain-style
ducks
  • action,reducer同じファイルに入れちゃおうってやつ

まとめ

  • actionとreducerを分けて考えるべきではない

中大規模開発をReactで行う現場から伝えたいこと (10min)

現場での泥臭い話

  • B2B
  • 管理画面作ってる
  • react + redux
  • enzymeでテスト

テスト

  • 書かないとのちのち苦しむ
  • 何ヶ月も前に作ったものを手動でテストはつらい
  • 書くようにするにはどうすればいいか
    • TDD
    • できるだけ並行でテスト書く
    • CIでテスト結果確認できるようにする
    • 新規実装時に同時にspecファイルつくるようにする

共通コンポーネントを可視化

  • 新しい開発者が同じの作っちゃうとか
  • 共通コンポーネントあるか都度聞く聞かれるのも大変
  • storybook必須

ドキュメント

  • 開発環境のバージョン開発環境の立ち上げ手順
  • コーディングガイド
    • JSDoc
    • 変数名
  • テストの書き方
  • PRレビューの指針になるようなドキュメントにする
  • wikiに書いてたけど1つのリポジトリにした
  • 多すぎてそれも見づらくなった
  • 今はgitbook使ってる

バージョン変更

  • 小刻みにあげること
  • 習慣的に行う
  • 2週に一度バージョン更新
  • nodeはLTSのバージョンが更新された時
  • 依存パッケージはlockしておくこと

「html5j Webプラットフォーム部 第20回勉強会」に参加してきました

Responsive Web Design もう一度

Responsive Web Design

  • 2011年にできた
    • Fluid Image
    • Fluid Frid
    • Media Query
      • 使いすぎるとCSSが膨れ上がってしまうから注意

MediaQueryを使いすぎないようにする

vw, vh vmin, vmax

  • vh
    • viewport height
    • 画面の高さを100としたもの
  • vw
    • viewport width
    • 画面の幅を100としたもの
  • vmin
    • 縦横短い方の長さを100としたもの
  • vmax
    • 縦横長い方の長さを100としたもの
  • 最小幅 + xxx という書き方
  • Fluid Type
    • 画面幅に応じてスムーズに文字サイズを変化させる
    • 最小と最大のフォントサイズを決めてその範囲でスムーズに切り替えさせる
    • 最小は16pxにすることが多い
    • 計算式がある
    • line-heightも同じ原理で変化させる

CSS Variables

  • CSSで変数を定義できる
  • logic fold
    • 色とかフォントを最初に定義しておく
  • IEでは使えない?

表の幅はどう決まる

B2Bでのレスポンシブ

  • B2CはモバイルファーストだけどB2BはPCが主流
    • モバイルで完結することは少ない
  • エクセルとか資料と並べて見たりとか
  • 権限で機能制御する
    • 同じ画面でも人によって表示量が違う

B2Cとの違い

  • B2C
    • さまざまな人がそれぞれの端末でアクセス
  • B2B
    • ひとりの人が複数の端末でアクセス
  • 画面幅変えても使用感が変わらないようにしないといけない
    • 画面幅変えても想像しやすい変化をするように設計する
  • 行と列が組み変わるパターン
    • 一覧性を犠牲にしやすい
    • 実装保守も大変になりがち
  • テーブルの表組みは意外と思い通りにならないことが多い
  • 内容が可変になることも多い

幅決定の仕組み

  • 固定の仕様はない
  • HTML4.01に推奨のアルゴリズムはある
  • ブラウザごとの裁量
    • とはいえだいたい一緒
  • table-layout
  • 各セルの内容の変化量に応じて幅は計算される
    • 日本語は最悪一行一文字でも表示できるので変化量がとても大きい

初体験で挑む!ぼっちのRWD対応

PCサイトをレスポンシブ対応した話

  • viewportを定義する
  • MediaQueryを入れた
  • sp/pc独自要素を入れる
  • 地道なパーツ単位の調整

失敗したこと

  • スマホ実機で見ておくべきだった
    • フォントサイズが全然違ったとか
  • デザイナーともっと相談するべきだった
    • 愚直に再現しようとして複雑化した
  • 保守しやすいCSSを考えるのをやめてしまった
    • 見通しの良いコード < 納期

どうすればよかったか

やってよかったこと

  • RWDはqiitaとか調べたらなんとかなった
    • もっと良い設計もあったかも
  • やってみないとわかんないことがたくさん

<デザイナー×エンジニア> RWDでステップアップLOVE

フロントエンドエンジニアとデザイナー両方やった経験から

エンジニア視点

  • 想定デバイスを超えたサイズでどうするか考えるのを忘れがち
    • どうするか認識合わせておかないといけない
  • ブレークポイントの境目のmargin(レスポンシブで見た目が変わる境目)
    • 切り替え寸前の時のレイアウトよく見ておかないといけない
  • フォントサイズはいろんなデバイスで見ておいた方がよかった
    • vwとかcalcを使って対応できるように
    • 文字の見え方は予め決めておくこと
  • 日本語 <-> 英語対応
    • 英語のほうが分量が多い
    • marginとかが微妙に違ってくる
    • 言語ごとにCSSを変えた
    • 2ヶ国語対応する時は工数かかることを事前に伝えておく

デザイナ視点

  • PCとスマホを別々にマークアップしてくる
  • アニメーション
    • 意図を伝えないと実装してもらえない
  • ウィンドウサイズ指定したのにあわせてこない

まとめ

  • デザイナはトレンドや勘所を把握してない
  • エンジニアはインタラクションやレイアウトに対する意識が弱い
  • それぞれがそれぞれの領域に入り込んでいって話せるようにならないと
    • 互いのボーダーを超えられることを恐れてはいけない

「golang.tokyo #12」に参加してきました

Next Currency とGAE/Go

  • sonatard 株式会社ネクストカレンシー

GAE/Go

  • GAE
  • 技術選定
    • シンプルなものを選んだ
  • サービス構成
    • サービス単位で分割できる
    • サービスごとにスケール
    • サービスごとにインスタンス選択できる
    • サービス毎に自動的にドメイン
  • デプロイ
    • コマンドひとつ
    • blue/greenデプロイできる
  • アーキテクチャ
  • フレームワーク/ライブラリ
    • ほしい機能最小限のもの
    • chi
  • APIプロトコル
    • REST? RPC?
  • API開発方針
  • リリースまで変わり続けるもの
  • リリース直前が一番いいものを作れる
  • APIクライアントとドキュメント
    • Postman
  • config
  • 開発環境
    • go
      • goimpoerts
    • GAE
      • コマンド
  • CI
    • CricleCI

GoとGCPkubernetesを使ったMF KESSAIの歴史

  • shinofara MF KESSAI株式会社

MF KESSAI

どんな会社か

  • マネーフォーワードの子会社
  • データの可視化業務効率化

なぜgoか

  • 型を厳格に
  • railsからの移行

goでどのように

  • ライブラリは最小限
  • goらしく書くこと

Dockerの採用

  • 環境の同一化担保
  • カプセル化
  • runtime環境の一貫性
    • CI回した環境を本番へ

REST API

  • goa

新規事業にgoを選んでよかったこと悪かったこと

よかったこと

  • 仕様変更が多かったけどコンパイルがあるお陰でよかった
  • 静的チェックツールを最初から入れていて不要なレビューを削減
  • 言語そのものが活発
  • チーム開発に向いている

悪かったこと

  • 動的型付け言語経験者からするとできたことができなくていや
  • 画面UIこるのには向かない
    • template周りの機能は不足している言語
  • エラーハンドリングとか記述量多くなりがち
    • IDE使いこなせばいけるけど