「GitHub Actions Meetup Tokyo β」に参加してきました

  • GitHub Actions Meetup Tokyo βに参加してきました。

gaugt.connpass.com

タイトル 発表者
新GitHub Actions のはじめかた @miyajan
GitHub Actionsで WebDriverどこまでやるの? @hiroshitoda
GitHub Actions Parallel Testing @yasuhiroki
GitHub Actionsと(主にreviewdogを使った)Automated Code Review @haya14busa
他のCIサービスと比較してできることできないこと @Kesin
Github Actions でハマった点と解決方法 @kawasin73
自作Github actions入門 @Naturalclar

GitHub Actions のはじめかた

  • @miyajanさん

GitHubActionsをはじめるとき

既存のワークフローを探す時

アクションを作る時

既存のアクションを探す時

予想外の挙動で困った時

GitHub Actionsで WebDriverどこまでやるの?

  • @hiroshitodaさん

GitHubActionsが動く基盤

GitHubActionsで最初から使えるソフトウェア

Appiumの利用とNested Virtualizationの壁

  • Androidエミュレータを動かせるのはmacOSだけ
    • Linux/Windows環境がNestedVirtualizationに対応してないから
  • 公開Dockerイメージを使える
    • AppiumでもDocker使っていい感じにしたい
    • NestedVirtualization問題
    • やるならmacOS
    • budtmo/docker-android
      • 5~6GB
      • 2分くらいでpullできる
    • bitriseio/docker-android
      • 26~27GB
      • キャッシュできない環境では実用に耐えない

GitHub Actions Parallel Testing

  • @yasuhirokiさん

並列テスト

複数のテストを分割して並列に実行したい

  • matrixを使うとできる
    • 自分でコードもちょっと書かないといけない
  • CircleCIは実行時間が均されるように自動で振り分けてくれる
    • knapsackを使うといい感じにできる

テスト結果を集計したい

  • artifactを使う
    • それぞれのノードで見えるディレクトリにファイルをアップロード
    • それらをダウンロードして集計する

Tips

GitHub Actions と (主に reviewdog を使った) Automated Code Review

  • @haya14busaさん

GITHUB_TOKEN

  • secret.GITHUB_TOKENを明示的に指定したときだけ使える
    • forkしたリポジトリからはちゃんと見えないようになってる
  • リポジトリにインストールされたGitHub Appのアクセストーク

Check API

  • コードにコメントをつけられる
  • Review APIより使いやすい
  • reviewdog

他のCIサービスと比較してできることできないこと

  • @Kesinさん

ビルドキャッシュとアーティファクト

マトリックスビルド

  • nodeの複数バージョンでJobを実行といったことができる

マトリックスビルドとconainter

  • マトリックスで指定したイメージ上でテストが実行できる
  • actions/setup-xxxを使わなくてもよくなる

Github Actionsでハマった点と解決方法

  • @kawasin73さん

プライベートリポジトリ

  • プライベートリポのインストールが難しい

3rd Party Action信頼できない

  • 大もとはGitHubリポジトリ
    • 差し替えられても気づけない
  • フォークして使いましょう
    • 中身を確認して使う

git cloneに失敗する

  • サーバ鍵の検証を諦めて無視した
  • GitHubないからGitHubリポジトリにアクセスするので中間者攻撃はないだろう

セマンティクスバージョニングがない

  • v0.1はv0.1.0にならない
  • Actionsのバージョンはタグとの完全一致

自作Github actions入門

  • @Naturalclarさん

actions-toolkit

github.com

  • @actions/core
  • @actions/exec
  • @actions/io
  • @actions/github
  • @actions/tool-cache

「CROSS Party 2019」に参加してきました

  • CROSS Party 2019に参加してきました。

2019.cross-party.com

業務ハック 〜業務効率化にコミットする職人達の世界〜

  • 野秋 拓也さん(DMM.com)
  • 廣氏 宣勇さん(DMM.com)
  • 廣野 美里さん(freee)
  • 髙木 咲希さん(SonicGarden)

業務ハック

  • 業務改善をエンジニアリング行うこと

事例

  • Slackで相手の名前とか入れると参加者の開いてる予定検索して提示してくれる
  • 受託開発で業務ハック
  • slackとかgsuiteと使うようになって業務ハックしやすくなっている
  • 全部自分でゴリゴリに作るとかはそんなない
    • いろんなサービスを組み合わせて解決させる
  • kintone
  • Zpier

[基調講演] 夢を形にする技術 〜 大規模開発におけるサイエンスとエンジニアリングの境界を科学する

はやぶさプロジェクト

  • 無人探査機によるサンプルリターンミッション

ユーザ要求

  • IT
    • 自分たちもユーザ
    • 自分たちが使いたいもの
  • 探査プロジェクト
    • イノベーションは技術が主導して立ち上げるもの
    • 顧客は今しかみてないからそのニーズに答えるだけでは発展しない

技術の継承

  • IT
    • 多くのシステムが負債化している
      • 古い技術が動いているからといって放置されている
      • 開発できるエンジニアを持っていなくて委託しているからノウハウのある人がどこにいるかわからない
      • 人材の流動が激しいと数年でいなくなることを想定して作れる
    • ペアプロ、モブプロ
  • 探査プロジェクト
    • 親方と弟子の関係
    • コーチングして技能は得られるが使えるものは得られない
    • 自ら獲得しないといけない
    • はやぶさはやぶさ2の間は10年以上
    • 若いうちからプロジェクトに参加して見せていきたい

チームビルディング

  • IT
    • 同じ方向を向ける中で多様性を持つことが重要
    • 根本から違う方向向いてしまうのは採用ミス
    • 考え方の違う人を入れてしまうよりも才能をある人を貶してしまう方がましというくらい
    • ローコンテキストを前提にビジョンを共する有
  • 探査プロジェクト
    • 向いているところに向いている人を配置する

緊急企画!漫画村再検証!

漫画村

  • 海賊版サイト
  • 政府がサイトのブロッキングを実施
  • 4つの闇
    • 法解釈の闇
    • 法改正の闇
    • 報道の闇
    • 広告の闇

海賊版サイト対策検討会議はなぜ紛糾したのか

事務局による進行の問題

  • 著作権侵害ブロッキングは世界42過酷で導入されているだから日本もやるべき」
    • 2001年にEUが司令を出してEU各国で法制化
    • 法制化されているが実施したことある国は半分くらいしかない
    • EUで28カ国が法制化17年間実績なしの国が15カ国

被害額3000億円

  • 漫画村の被害額が3000億円という試算は本当か
  • 年間コミック市場は4000億前後
  • 総アクセス数に単価をかけたのが3000億円
    • アクセスが有った分全部売り上げた前提

Coinhive事件/WizardBible事件にみる不正指令電磁的記録に関する罪

法が問題としていること

  • 意図に沿うべき動作をさせず不正な司令を与える電磁的記録

事件

  • Coinhive事件
    • 自分のページにWebブラウザにマイニングさせるJSを貼った
  • WizardBible事件
    • リモートシェルを埋め込み
  • アラートループ
    • アラートを閉じてもアラートが出続ける

この状況が続くと

  • サイバーセキュリティ分野の活動が衰退する懸念
  • 海外に優秀な人材が(今以上に)流出

フロントエンドエンジニアがこの先さらに生き残るには

  • mizchiさん(plaid)
  • lacoさん
  • 奥野賢太郎さん(クレスウェア)

働き方のスタイル

  • フリーランスになった
    • もともとのつながりで仕事を得られた
  • 週1日副業
    • サラリーマン感なくなった
  • フリーランス時代の仕事
    • フロントエンドは管理画面の需要が高い
    • エクセル再実装

フロントエンドエンジニアの尖り方

日本人がOSSにあまり貢献していない

  • 一部貢献している人がいてもスター扱いしてそれで終わってる
  • OSSは大企業が作るものに集約されてきていってる
  • バグバウンティの方がまだある
  • 翻訳のコントリビューションする人はけっこういる
  • GitHubのトレンドに日本人作者のライブラリがのることがほとんどない
    • 最近だとhiroppyさんのfusuma
    • 中国勢が強い

フロントエンドのカバーする領域

  • フロントエンドがサーバーサイドに入り込むようになってきた
    • Next.js, Nuxt.js
    • BFF
    • FaaS
  • フロントエンドの大事なところはフロントエンドであることユーザに最初に触れるところ
    • パフォーマンス
    • デザイン
    • UX
    • その反対側にデータを堅牢にする役割の人も必要
  • SPAを作るのが大変だった時代から当たり前に作れる時代になった
    • 注力できる範囲が広がってきてカバーできる領域が増えてきた

フロントエンドのDeveloperExperience

  • webpackのビルド時間が長すぎて改善の妨げになっていたり

次にくるものは

  • 数年前にReactの仮想DOMに魂が震えた
  • 次はWebWorker
    • off the main thread
    • メインスレッドの奪い合い

Rust

  • 今のWebをRustで書くことは今はなさそう
    • ライフタイムとかフロントエンドとは違った難しさ
    • ゲームとか作るのにはいいかもしれないけどメインでやることはなさそう
  • メインスレッドに登場してくることはなさそう
    • workerで動かす処理を書くとかはありそう
    • Backend in Frontend

フロントエンドの技術選定

  • TypeScriptは大前提
  • フレームワークを使うかどうかから
    • ampを使うとか
  • 複雑にならないからと思っても作り変えるときは絶対来る
  • バックボーンの成り立ちや考え方を気にしてもいいかも

「Meguro.css #7 @ ラクスル」に参加してきました

  • Meguro.css #7 @ ラクスルに参加してきました。

megurocss.connpass.com

  • 初めて知った記法や、普段当たり前に書いている変数名やライブラリへの問題提起など、学びがとても多かったです。
  • 次回もまた参加したいです!
タイトル 発表者
react-nativeにおける、Styleとの向き合いかた Naturalclar
Design Tokensを考える前に俺たちは変数名について考え直すことがあるのではないか yamanoku
詳細度調整擬似クラス ShoEzawa
Chrome 78 Betaで試すCSS Properties and Values API あらや
Stylelintの取扱説明書 moro
Sassに頼らないCSS設計 takanorip

react-nativeにおける、Styleとの向き合いかた

  • Naturalclarさん

React Native

  • Reactライクな書き方でiOS/Androidアプリが作れる

React NativeのStyle

  • WebではないからCSSではないけど同じような感じで書ける
  • CSS in JSで書くことになる

React NativeとWebの差

  • Displayは基本flex
  • flexDirectionのデフォルトがColumn
  • marginなどのショートハンドが使えない
    • marginVerticleなど独自のものもある

Design Tokensを考える前に俺たちは変数名について考え直すことがあるのではないか

  • yamanokuさん

デザインシステム

  • 一貫性が保たれたUIUXを提供できるもの

Design Tokens

  • デザインシステムにおけるスタイル変数集
    • CSS variables
    • SASSの変数とか
    • json読み込んだりとか
  • 色の変数名にwhiteとかつけるのはどうなのか
    • Atlassianのデザインシステムはカラー名が色の名前に準拠してない
  • 変数名が教養があるかどうかになるのも何か違う

詳細度調整擬似クラス

  • ShoEzawaさん

詳細度調整擬似クラスとは

  • :where()
  • 引数として与えたセレクタを詳細度の計算で無視する

使い所

  • !importantと同様詳細度に鑑賞するので乱用は危険そう?
  • ちゃんと使えば便利になりそう
  • 擬似クラスや属性セレクタを使うと詳細度が高くなりがちなので使えそう
  • 用途を限定して使うとよさそう

Chrome 78 Betaで試すCSS Properties and Values API

  • あらやさん

CSS Properties and Values APIとは

  • CSSのCustom Propertiesを構造化するためのAPI
  • CSSのCustom Propertyに初期値とsyntax(型のようなもの)を指定できる
  • Chrome78から使える

API

  • window.CSS.registerProperty
  • syntaxにnumberとかcolorとか設定できる
  • 一度定義すると再registerできない
  • syntaxに一致しない値を設定するとErrorがでる
window.CSS.registerProperty({
  name: '--property-name',  // 対象のcustom propertyの名前
  syntax: '*',              // 値をどうパースするか
  inherits: true,           // 親要素の値を継承するか
  initialValue: '',         // 初期値
});

Stylelintの取扱説明書

  • moroさん

Stylelintとは

  • css潜在的なエラーの事前検知や一貫性を保てる

Stylelintの使い方

  • stylelintをinstall
    • npm i -D stylelint
  • configを作成
  • 公式が提供するlintルール
    • stylelint-config-standard

上手な使い方

  • メッセージをカスタマイズできる
  • huskyとlit-staged
    • commitやpush前にタスクを走らせてそこでlintチェックする
    • 必ずlintがかかるようにできる

Sassに頼らないCSS設計

  • takanoripさん

Sass

  • 便利だけど機能が多すぎる
  • 便利だけど注意が必要な機能もある
  • Sassの機能を使うことが目的になってませんか

上書きをなくす

  • 詳細度で値を上書く
    • 詳細度との戦いが始まるのでよくない
  • 過度な共通化をしてると起こりやすい

Custom properties

  • CSSの変数のようなもの
  • 標準のCSSで使える
:root {
  --primary-color: ##ff0000
}
.hoge {
  color: var(--primary-color)
}
  • 色や大きさなど定義しておくことで統一したstyleにできる
  • 上書くだけではないのでよい

ScopedなCSS

フラットなCSS

  • ネストが深いと検索しづらくて開発効率が落ちる
  • 詳細度との戦い
  • Sassはネスト使えちゃうので使っちゃう

「JSUG勉強会 2019その9 Spring&AWS」に参加してきました

  • JSUG勉強会 2019その9 Spring&AWSに参加してきました。

jsug.doorkeeper.jp

  • Springの勉強会ですが個人的にECSの話をきけたのがとても勉強になって嬉しかったです。
タイトル 発表者
Spring BootをKotlinで作成し Amazon Elastic Container Service (ECS) で稼働させる話 白山 文彦 (Fumihiko Shiroyama)
AWSで作るクラウドネイティブアプリケーションの基本とDevOps 川畑 光平 (APN AWS Top Engineers & Ambassadors)

Spring BootをKotlinで作成し Amazon Elastic Container Service (ECS) で稼働させる話

  • 白山 文彦 (Fumihiko Shiroyama)

Kotlin

  • いわゆるAlt Java
  • 完結で強力な記法
  • Null安全
    • 型の時点でnullが入りうるかわかる
    • 自然な形で具象型にできる
  • JetBrains製

Spring with Kotlin

  • Spring Initializr
  • Docker化
    • 簡単に捨てられる開発環境
    • ステートレスなアーキテクチャの強制
    • 本番運用を見据えられる
  • DBもDocker化
  • AWSにデプロイ

Spring on AWS

Amazon Aurora

  • 自動でスケールする(RDSでは昔はできなかった)
  • マルチリージョン
  • 1つのライターと複数のリーダ
  • 書き込みエンドポイントと読み込みエンドポイントが違う
  • ローカルからでもアクセスできる

Amazon ECS

概要
  • Dockerコンテナを簡単にデプロイ管理するためのサービス
  • コントロールプレーンはECS or EKS
  • データプレーンはEC2 or Fargate
    • Fargateは中を意識しないで簡単に使える
    • EC2は自分で好きなようにできる
  • Fargateを使うとリソースを意識する必要ない
使い方
登場人物
  • タスク
    • Dockerコンテナ
    • タスク定義から作る
  • サービス
    • タスクを複数束ねる
    • APIサーバ」や「HTTPサーバ」のような役割の単位
  • クラスタ
    • 複数のサービスを束ねる

まとめ

  • ローカルから段階的にDocker化することで簡単にECS化できた
  • Fargeteは簡単にコンテナを扱える
  • CI/CDツールと連携するとECSの作成やデプロイを自動化できる

AWSで作るクラウドネイティブアプリケーションの基本とDevOps

  • 川畑 光平 (APN AWS Top Engineers & Ambassadors)

AWSで作るクラウドネイティブアプリケーションの基本

news.mynavi.jp

「Serverless Meetup Tokyo #14」に参加してきました

  • Serverless Meetup Tokyo #14に参加してきました。

serverless.connpass.com

タイトル 発表者
機械学習MVPにServerless Frameworkがオススメな理由 池田 雄太郎(株式会社 KaizenPlatform)
今Serverlessが面白いわけ(v19.09) 川崎 庸市(Microsoft Corporation)
AWSで開発するサーバレスAPIバックエンド 三宅 暁(フリーランス
F-SecureのServerlessなSecurity 河野 真一郎(エフセキュア株式会社)

機械学習MVPにServerless Frameworkがオススメな理由

  • 池田 雄太郎(株式会社 KaizenPlatform)

ML/DLプロダクト開発におけるストレス

コンピューティングリソースの短期的ダイナミクス

  • 学習などで一時的に大量リソースほしい
    • => 柔軟なスケールイン/スケールアウト機構が必要

コンピューティングリソースの長期的ダイナミクス

  • ビジネス的な成長予測ができないのでどれくらい使われるかわからない
    • => インフラに関する高い知識が求められる

Serverless

  • リクエストに応じて必要なだけのリソースをリアルタイムに確保する
    • リソース確保が柔軟
  • ML/DLプロダクト開発と相性がいい

Serverless導入の悩み

  • 設定/デプロイに関するデメリット
    • 使うBaaSが多くなり勝ち
      • AWSとかいろんなサービスがある
    • DevOps環境構築のハードルが高い
      • ロジックの実装はJupyterNotebookが多め
  • そこでServerless Framework

Serverless Framework

  • Serverlessアプリの構成管理ツール
  • CloudFormationの定義したリソースをLambdaを中心に一括で設定できる
  • ステージング環境の分割など簡単にできる

今Serverlessが面白いわけ(v19.09)

世の中の動向

  • 人類の問題
    • アジリティがほしい
    • 高い生産性効率性がほしい
    • 運用コストを下げたい
  • ビジネスの傾向

FaaSを支える技術

  • インフラ技術の進化の賜物
  • 一般的にコンテナ相当の技術が基盤に使われる
    • 使った分だけ課金
    • 高速にスケーリング
  • データストアの進化
    • ステートフル/データ永続化対応
    • スケーラブルなデータストア
    • NoSQL型がフィット
  • プラットフォームの進化の方向性
    • 自動化
    • 抽象化
    • 標準化
  • Serverlessにおけるクラウドベンダーの実情
  • Knative
  • KEDA
  • Virtual Kubelet

AWSで開発するサーバレスAPIバックエンド

ノーコーディングでバックエンドAPIを作る

  • Amplifyは使わない
    • ベンダーロックインしないように
    • Apollo Clientを使う
  • Cognitoは使うがOpenID Providerとして使う
    • react-oidc-contextを使う
  • serverless-appsync-plugine
    • AppSyncの設定を完結に定義してデプロイできるServerlessFrameworkのプラグイン

F-SecureのServerlessなSecurity

Serverlessでセキュリティ

  • インフラは提供者が担保
  • エンドユーザがアップロードしてきたファイルは安全か?
    • アップロード時にF-Secureと連携してセキュリティチェックしてくれる
    • API連携でセキュリティチェックができる

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

  • Meguro.css #6 @ oRoに参加してきました。

megurocss.connpass.com

タイトル 発表者
レガシーフロントエンドで頑張ってCSS設計した話 etawin
CSSイラストレーション deren @study_dedede
段組と印刷の地雷 吉川雅彦@行程さん社長 @masahiko888
すたいるQ Ko.Yelie (エリー) @ko_yelie
Scoped CSS + RSCSS のすすめ すわくん @ztrehagem

レガシーフロントエンドで頑張ってCSS設計した話

  • etawinさん

従来の環境

  • CSSトランスパイラなし
  • JavaScriptUIライブラリなし

改修後

  • stylus
    • なぜSassじゃないか
    • JSっぽく変数書ける
    • CSSプロパティライクにmixinを表現できる
  • BEM

工夫

実装序盤

  • 無理して共通化するよりも愚直に書いた方がいいケースも多い
  • 雛形になるクラス作ってそれプラスαって感じで使うと良かった

実装中盤

  • 意味のある単位であとからまとめていった
    • stylusのmixinが便利

実装終盤

  • 抽象のしかた細かく考えだすと不毛な時間に
  • 何者かでなく何を指し示すかで分類

最終的な構造

  • デザイン規約
  • 雛形クラス
  • CSSクラス

CSSイラストレーション

  • derenさん

CSS/JS学びたい

  • CodePenのぞくと面白いと教えてもらった
  • CSSだけで作品を作れる

私流イラストレーション

  • 1.下絵を書く
  • 2.パーツごとにdiv化
    • BEMでつけるといい
    • クラス名詳細に書いてるのでぱっと見でわかりやすい
    • デメリットはクラス名が長いことくらい
  • 3.パーツの形をひたすら制作
    • before/after使うとタグが無駄に増えないからいい

よく使うプロパティ

overflow

  • はみ出た要素の表示方法を指定
  • overflow: hidden; -はみ出た要素非表示

transform

  • 要素の表示位置の変更
  • transform: translate(10px, 10px); top: 10px;left: 10px;と同じ

transform-origin

  • 中心点の変更

CSSで何か作りたい人

https://codepen.io/challenges/codepen.io

段組と印刷の地雷

  • 吉川雅彦さん

段組みを印刷

  • 段組みをプレビューして印刷するというものを作った
  • すべてのブラウザに対応できない
    • IE,FFは印刷プレビューを出しにくい
    • Chromeだけ対応
  • PuppeteerとヘッドレスChromeでやるとよさそう

難しかったところ

  • 紙の余白を指定したい
    • @pageで指定
  • 文字が途中で切れてしまう
    • display: blockとかdisplay: tableで対応
  • h2/h3のサブタイトルのあとで改行したくない
    • break-inside: avoid使った
  • PDF印刷したら文字が欠ける
    • ウェブフォント適用で解決
  • Androidで絵文字を入れると1MBくらいファイルサイズが増える
    • わからない・・・

まとめ

  • 段組み+印刷大変
  • CSS/JS/デザインなどなどで解決していく
  • 割り切りも大事

すたいるQ

  • Ko.Yelie (エリー)さん

Q1

  • Q
    • margin/paddingを全て%で指定した場合基準になるのはそれぞれ親要素?自身の要素
  • A
    • どの方向で指定しても全て親要素の幅が基準になる

Q2

  • Q
    • flexで横に並べた要素の最後だけ右寄せにしたい
  • A
    • margin-left: autoをつけると右寄せになる

Q3

  • Q
    • transformにいろいろ指定した場合にどうなるか
  • A
    • transformのプロパティは左から順に適用されていく

Scoped CSS + RSCSS のすすめ

  • すわくんさん

ScopedCSS

RSCSS

  • BEMの簡単版みたいなやつ
  • シンプルな規則
    • Components
    • Elements
    • Variants
  • 書きやすい読みやすい捨てやすい

ScopedCSS + RSCSS

  • より安全なScopedCSS
  • より単純なRSCSS

「React.js meetup #8 初心者歓迎 LT会」に参加してきました

  • React.js meetup #8 初心者歓迎 LT会に参加してきました。

reactjs-meetup.connpass.com

タイトル 発表者
Gatsby紹介&Gatsbyのビルドをザックリ理解 kon_shouさん
Storeで扱う状態のライフサイクル @as_masaさん
React Hooks - カスタムフックとカプセル化 @sonatardさん
Reactから始めるリプレイス生活 fff_komatsuさん
connectの要らないreact-redux @natural_clarさん

Gatsby紹介&Gatsbyのビルドをザックリ理解

  • kon_shouさん

Gatsbyとは

  • Reactで書ける静的サイトジェネレーターe
  • viewはReact
  • データやりとりはGraphQL
  • Reactの公式サイトもGatsbyでできてる
  • starterkitが豊富

www.gatsbyjs.org

Storeで扱う状態のライフサイクル

Storeの設計

  • 1Store=1model?1Store=複数model?
  • ローカルステート使う?

アプリ特性によって考える

  • 全部載せ系
    • ページ遷移しない
    • タイムライン系
  • ページ遷移系

全部載せ系

  • アプリ起動から終了までのライフサイクルしかない

ページ遷移系

  • アプリ起動から終了までのライフサイクル
  • ページを表示してから別ページに遷移するまでのライフサイクル
  • ページごとの型を定義できる
    • Topページ型とかUserページ型とか

ローカルステート使うか

  • 同じライフサイクルで管理したいのでStoreで管理したい

React Hooks - カスタムフックとカプセル化

  • @sonatardさん

ReactHooks

  • React16.8で追加された
  • statteなどの機能をclassを使わずに書ける
  • useXxxというものが公式で10個公開されている
  • custom hookとして独自のものも作れる

カスタムフックの例

  • ロジックをカスタムフックに隠蔽することでViewをすっきりさせることができる
  • 可読性向上
  • 再利用性向上

カスタムフック

  • いろいろ公開されているから作る前に検索すると見つかるかも

github.com

github.com

nikgraf.github.io

Reactから始めるリプレイス生活

意図せぬコンポーネントの破壊

  • コンポーネントAを変更したらコンポーネントAに依存するコンポーネントBが知らないうちに壊れてた
    • Storybookを使ってればStoryShotsがお手軽で便利
  • styled-componentsのcreateGlobalStyleで意図せず壊れた
    • divタグにstyle定義してそれで囲うことでスコープを狭めた
    • 既存コードに影響ないようにできた

connectの要らないreact-redux

  • @natural_clarさん

react-redux

  • reactでreduxを使うためのラッパー

従来の使い方

  • mapStateToPropsとかmapDispatchToProps使ってconnectする

react-redux v7.1

  • hooksを使ったSPI
    • useSelector
    • useDispatch
  • これらをつかうとconnectを使わなくてよくなる

useSelector

  • 特定のselectorを使って値をとってくるhooks
  • mapStateToPropsの代わり
  • selectorの結果が変更されたときだけrerenderされる

useDispatch

  • 今までのdispatchと同じ感じ
  • mapDispatchToPropsの代わり

「UIT meetup vol.7 集まれ!(タブン)実務では使わないフロントエンド芸発表会」に参加してきました

  • UIT meetup vol.7 集まれ!(タブン)実務では使わないフロントエンド芸発表会に参加してきました。

uit.connpass.com

タイトル 発表者
@1-div challenge kawasako3
SVGで作るワードアート hashrock
React.js と動くもの、鳴るもの Leonardo
本気でCSS芸やりたい人ためのbox-shadow講座 ダーシノ
CSS PANICを支える技術 GeckoTang

SVGで作るワードアート

  • hashrockさん
  • SVG芸人

何でSVG

  • なくてもフロントエンドは作れる
  • やってて楽しくなる系

ワードアート

  • MS Wordで作れる
  • パワポとかエクセルでもできる

SVGでワードアート

  • SVG
    • <svg>
    • d属性で曲線
  • SVG DOM
    • ReactとかVueで扱える
  • ベジェ曲線
  • SVGの世界は単位がない世界
    • ブラウザのスクリーンの世界はpx
    • クリックされた位置を取得する時にSVGの世界の単位に変換しないといけない
  • SVGフィルタ
    • drop shadowみたいなものも作れる

React.js と動くもの、鳴るもの

  • Leonardoさん(LINE)

React + ReduxでWebGL

  • レンダリングのタイミングが大切
  • Three.jsのレンダリング
    • composer.render()を繰り返し呼ぶ
  • オブジェクトがぐるぐるしてるだけのアプリはあまりない
    • ユーザの操作にあわせて動かしたり
  • requestAnimationFrame()でrender呼ぶ
    • Reactのライフサイクルで呼んでstate管理するとかなり重い

React + ReduxでWebAudioAPI

  • AudioNodeどこで持つか
    • 全部Storeで持つようにした

参考

qiita.com

本気でCSS芸やりたい人ためのbox-shadow講座

  • ダーシノさん

box-shadowの基礎

  • 影のサイズは要素と同じ
  • 影は要素の背面に表示される
  • 影はカンマ区切りで複数指定し表示させることができる

box-shadowでファミコン風UI

nostalgic-css.github.io

  • NES.cssはbox-shadowを使っていろいろやっている
    • inputの枠とかbuttonの外枠とか

box-shadowでドット絵

  • もとの要素のheight/widthを1pxにする
    • 影のサイズは要素と同じだから

box-shadow芸のハマリポイント

  • ギガを消費する
    • 大量のピクセル情報を持っている
    • ドット絵だとピクセル単位でたくさん定義が必要
    • 複数サイズ用意する場合サイズごとにbox-shadowの指定が必要
  • ギガを抑える
    • currentcolorを使う
    • サイズの調整はtransform: scale(x)を使う
  • メンテできない
    • box-shadowの定義が大きすぎてどこを変えたいかわからない
    • Sassをうまく使って頑張る

まとめ

  • box-shadowはアイデア次第でいろんなことができる

「Node学園 34時限目 jsconf.eu 報告会」に参加してきました

  • Node学園 34時限目 jsconf.eu 報告会に参加してきました。

nodejs.connpass.com

2019.jsconf.eu

タイトル 登壇者
JavaScript Package Manager 2019 yosuke_furukawa
Cloudflare Workersの紹介 dorayakikun
Node.jsとWebAPIのこれまで、現在、これから Leko
jsconf.eu 報告会 Performance Empathy 編 tomonari-takahashi
TypeScriptでコマンドラインパーサー Akito0107

JavaScript Package Manager 2019

  • yosuke_furukawaさん

JSのPackageManager

  • npm
    • npm inc
    • npm cli
    • npm reistry
  • yarn

npm

  • npmの仕組み
    1. ローカル依存ファイルを読む(package-lock.jsonとか)
    2. 存在しないpackageのメタデータをfetch
    3. 木構造を計算して実行
    4. packageのtarをダウンロード
    5. インストールスクリプト実行
  • ダウンロードが高負荷
    • fetchしてgunzipしてコピーする
    • Network負荷
    • CPU負荷
    • FileIO負荷

tink

  • 新しいパッケージマネージャー
  • npm cliをもとにして作られてるもの
    • ゆくゆくはnpmに統合
  • npm iの処理を実行時にやればいいのでは
    • node_modulesを仮想上のフォルダにする
    • ランタイムでモジュール解決するからnpm iがいらない
      • コピーしないからFileIO改善
      • cloneして実行するだけでよくなる
  • zero install
  • node main.jsではなくtink sh main.jsとするtinkで実行できる
  • prepareとunwind
    • prepareは事前にmoduleをfetch(本番はこれでやるとよい)
    • unwindは事前にnode_modulesを実体化

loadmap

  • npm v8でtinkがnpmに統合される

yarn

  • yarnのv2でも同じzero installに取り組んでいる

今後

  • npmもyarnもzero installになっていく
  • npmとyarnどちらも有意差はまだない
  • まだexperimentalな段階

JavaScript Registryの今後

  • JavaScript Registryとは
    • Packageをバックで管理するサービス
  • JavaScriptのRegistryをビジネス的に成功させるのは難しい
    • public moduleは無償で提供
    • アクセスコントロールするなら有償
  • npmは100万モジュールある
    • rubyのgemは30万
  • Entropic
    • 中央集権ではなく分散管理していこう
    • npmにつながる新しいregistry
    • みんなで治験を高めて分散管理できる状態を目指す

Cloudflare Workersの紹介

  • dorayakikunさん

wasm

  • ここ1~2年盛り上がってきた
  • JSConf EUでのwasmのセッション3つ

Webの現状

  • JSのbyteサイズが年々上昇している
    • この3年でモバイルは50%増加
  • Time To Interactive
    • TTIの平均値9秒以上

既存の戦略

  • SSR + Cache
    • Time to First Byteが遅い
  • CSR + Cache
    • FCPからTTIまでラグがある
  • どれもトレードオフがある
  • => Edge Side Rendering

Edge Side Rendering

  • エッジサーバでhtmlをrendering
  • SSRCSRのいいとこ取り

Cloudflare Workers

  • エッジサーバ上でserverlessアプリを動かせるサービス
  • 言語はjsかwasm
  • デプロイはwebかwrangler
  • 要素技術
    • V8のIsolate

Edge Side Renderingは有効か

  • グローバルなサービスだと旨味がありそう
  • エッジサーバで何させるかは議論の余地ある

Terrarium

  • Fastlyが提供するEdge Computing Platform
  • wasmのみ

Node.jsとWebAPIのこれまで、現在、これから

  • Lekoさん

NodeとWebAPIのこれまで

  • ブラウザのJSの仕様/NodeのJSの仕様
  • 片方にあったやつをもう片方でも実装されたりとか
    • 同じようなことなのに微妙に違うとか
  • NodeとWebAPIを近づけようとしてる
    • URLSearchParams
    • TextEncoder
    • Wrker Threads
    • Performance Timing API
  • 議論中
    • StreamsAPI
    • FetchAPI
      • 仕様がとても複雑
      • Nodeで全部再現できるのか、再現する必要があるのか

まとめ

  • 多くのWebAPIがNodeに取り入れられている
  • ワークフローを改善してより改善されていく

参考

blog.leko.jp

jsconf.eu 報告会 Performance Empathy 編

  • tomonari-takahashiさん

パフォーマンスに関して大切なこと

  • デフォルト/デファクトツールを使う
    • ブラウザデフォルトでできるようになってることも多い
    • lazy loading
    • virtual-scroller
  • パフォーマンスをマネジメント
    • Performance budget

TypeScriptでコマンドラインパーサー

  • Akito0107さん

コマンドラインパーサーを作る

  • 有名なライブラリがいろいろある
    • minimist
    • commander
  • オプションが複雑だとどれもつらい
    • 型がほしい
    • => 作った

github.com

「PORT Firebase × Flutter」に参加してきました

  • PORT Firebase × Flutterに参加してきました。

stamp.connpass.com

タイトル 発表者
Flutterで使うCloud Firestore Shogo Yamada
Flutter × Firebase Crashlytics 菊池 紘
Firestoreのトランザクション 村本 章憲

Flutterで使うCloud Firestore

FlutterとFirebase

  • FlutterでFirebaseを使うプラグインが豊富
    • 基本的に全部ある
    • Firestoreのincrementも最近対応
  • 使い心地はWeb版Firebaseっぽい
  • Flutterだから使えないみたいな話は基本的になし
  • ネイティブでドキュメント通り実装されたものをFlutterから呼んでるだけ

開発スピード

  • Flitterはホットリロードあるし快適
  • Firebase使えばサーバサイドメンテ必要なし
  • Flutterの知識やFirestoreの知識は必要

今後の動き

  • Firestoreに新機能がでるとFlutter側にissue立ってすぐ対応される
  • Flutter × Firestoreではやってる実績はまだ見ない

Flutter × Firebase Crashlytics

  • 菊池 紘さん(Diverse)

youbrideというアプリ

  • 既存アプリをFlutterに置き換えている
  • ScopedModelアーキテクチャ
  • gRPCでサーバと通信

Flutterをproductionで運用

  • クラッシュレポートどう取得する
    • firebase_clashlyticsという公式のプラグイン(まだ開発段階のもの)
    • 導入面倒だけどマニュアル通りやればよい
  • 端末で発生した例外を記録してサーバに送ってくれる
  • Dartの例外のでかたがまだ微妙
    • 全部非致命的エラーになる
    • 拡張子が.javaになる
    • 例外の種別不明
    • 難読化マップ非対応

競合サービス

  • Fabric Crashlytics
    • Firebase Clashlyticsとほぼ同じ
    • 2020/3/31に終了予定
  • Sentry
    • 有料
    • 難読化マップ非対応?

Firestoreのトランザクション

  • 村本 章憲さん(Stamp)

FireStoreでtransaction

  • 同時に更新しようとしたときに問題が起きる
  • update time
    • 1/sec
    • 一秒に一回しか更新できない
  • runTransaction()
    • read/write/observe/commit/rollback
    • read -> write -> commit
    • observerがwriteを監視してる
    • 他でwriteされてたらrollbackしてretry
    • 5回retryしてだめだとそこで終わる
    • 1秒間に100更新が来たら95は失敗する
  • Distributed counter
    • shardingする
    • 増やせばいいというものでもないのでどれくらいshard数にするかは設計しだい

firebase.google.com

メモ

  • FlutterでCI

www.bitrise.io

codemagic.io

「Ginza.js#2」に参加してきました

  • Ginza.js#2に参加してきました。

ginzajs.connpass.com

タイトル 発表者
Vue初心者はVuetifyで遊んでみよう きり丸
Jestを使ってVueコンポーネントとVuexストアのテストコードを書いてみよう! karamage
vue×firebase製のなんちゃってCMSで、仕様決めから開発まで使い倒してる話@受託 MacotoChitose
TOEIC400点のRubistがセブのオフショアでReactNativeでアプリ開発した話 DYoko0701
Ionic/Vueを紹介してみる 果物リン
Figma Pluginを作ろう! takanorip
/f(ig|usu)ma/の話 Quramy

Vue初心者はVuetifyで遊んでみよう

  • きり丸さん

対象

Vuetify

vuetifyjs.com

Jestを使ってVueコンポーネントとVuexストアのテストコードを書いてみよう!

  • karamageさん

VueアプリでJestのセットアップ

  • jestとvue-test-utilsをインストール
  • Jest
    • JSのテストシェアNo1
    • テスト周り全部入り(他のテストツールだといろいろ組み合わせたりする必要あった)
    • カバレッジも取れる
    • スナップショットテストもできる
  • Nuxtアプリに入れるときはbabel周りでハマることもある
    • バージョンいじったら解消された

vue×firebase製のなんちゃってCMSで、仕様決めから開発まで使い倒してる話@受託

  • MacotoChitoseさん

VueとFirebase

  • 仕様決めの段階からコンポーネントを作って見せていく
    • 早めにフィードバックもらって軌道修正できる
  • Firebaseに仮データ入れて動作確認できる

TOEIC400点のRubistがセブのオフショアでReactNativeでアプリ開発した話

  • DYoko0701さん

ReactNativeでのアプリ開発

  • アプリ
    • ReactNative
  • サーバ

オフショア

  • なぜセブ?
    • 中国とかインドとかは単価上がってきてる
    • 公用語英語
  • ネットワークとても遅い(オフィスでも10M/bps)
  • 新しい技術より枯れたものの方が得意なことが多い
  • 既存の改修だと説明しないといけないので大変

Ionic/Vueを紹介してみる

  • 果物リンさん

Vueでネイティブアプリ

  • Weex
  • VueNative
  • どちらもあまり使われてない

Ionic

  • Web技術でネイティブアプリを作れる
    • Cordovaベース
  • v3まではAngularだった
  • v4からはVueやReactも使える

qiita.com

Making Figma Plugins with TypeScript

  • takanoripさん

Figma

  • Figma Designで検索
  • Web版とアプリ版がある

medium.com

Figma Plugin

  • 今まではPlugin作れなかった
  • 6/11にFigma Plugins betaが発表された
  • API経由で自由に機能にアクセスできる
  • TypeScriptで書ける(公式がおしてる)
  • WebWorker上のSandboxで任意のコードを動かせる

/f(ig|usu)ma/の話

  • Quramyさん

fusuma

hiroppy.github.io

github.com

  • markdown(mdx)でスライドが書ける
  • コードも貼れる(ハイライトついてくれる)

fusumaとfigma

  • .mdをスライドにするツールは過去にもいろいろあった
    • 図を入れるのがめんどくさかった
  • figmaならiframeでembedできる
  • mdxにiframeを入れたらよさそう
  • iframeの読み込みが遅かったのでgulpタスクでimgタグに置き換えた

「#portals_study」に参加してきました

  • portals_studyに参加してきました。

web-study.connpass.com

タイトル 発表者
Hands-on with Portals uskay
はてなにおけるPortals pastak
hitode909

Hands-on with Portals -seamless navigations on the web-

  • uskayさん

web.dev

Webのパフォーマンス

  • Lighthouseは最初のページがでるまでの速さをはかる
  • ページ遷移を快適にしたい
    • SPAにする?
    • SPA覚えてなくても使えるものはないか?
    • => Portals

iframeと似ている

  • portalsはiframeのようなもの
  • portalsは埋め込んだページにそのまま遷移できる

Portals

  • Canaryでflugをたてると使える
  • Portals自体がアニメーションを持つわけではない
    • 遷移するタイミングでアニメーションをあてるいい
    • transitionが終わったタイミングでportsl.activate()
  • activateすると前のページのportalオブジェクトを取得できる
  • portalで表示しているページはユーザのインプットを受け付けない(セキュリティの都合、将来変わるかも)
  • portalで表示しているページとはメッセージでやりとりできる
  • activateするとhistoryが消えてしまう(直してる)
  • portalのネストはできるけどactivateできるのは手前のものだけ
  • ホワイトリストしたページでしか表示できないとかは検討中
  • WICGで仕様が議論されている

wicg.github.io

github.com

はてなにおけるPortals

  • pastakさん
  • hitode909さん

マンガビューワ

  • Webで快適にマンガを読む
    • URLを開くとすぐ読める
    • スマホでもPCでも
  • 画像の先読み
  • 次のエピソードの先読み
  • フルスクリーンで読み続けたい

Portals

  • 使用感
    • 簡単に埋め込める
    • 簡単に遷移させられる
  • portalsとして埋め込んでもらえるようにすることも考えてる
    • 今はiframeで提供している

「ABC 2019 Spring」に参加してきました

  • Android Bazaar and Conference 2019 Springに参加してきました。

abc.android-group.jp

  • 今回はAndroidのハンズオンに参加してみましたが、初心者でもわかりやすく且つHelloWorldの2歩3歩先くらいまでの内容でとても満足度の高いハンズオンでした。

teampansaru.connpass.com

  • ARのハンズオンも気になっていましたが、資料公開されているようなので個人的にやってみたいと思います。

japan-android-group.connpass.com

タイムテーブル

10:10~11:10

会場 タイトル 発表者
大講義室 Google I/O 2019 Recap! 鈴木拓生/Google

11:10~11:55

会場 タイトル 発表者
大講義室 円周率世界記録31.4兆桁への道 岩尾エマはるか/Google

13:00~13:45

会場 タイトル 発表者
大講義室 IBM CloudではじめるNative Android Application開発 萩野たいじ/IBM
4101 Google I/O 2019 Recap MLセッション(入門からアプリ化まで) 足立昌彦/株式会社カブク
4103 Service WorkerではじめるオフラインWebアプリの実装 堀正斉/PWA Beginners
4103 Background Sync APIを使った実装について 平田智子/PWA Beginners
4104 準天頂衛星受信機の動向について 松岡繁/(一財)衛星測位利用推進センター
4105 45分で作れるかCPU 今岡通博/日本Androidの会FPGA
4201 アプリとゲームのセキュリティーを高めよう ロドリゲス オスカル/グーグル合同会社
4202 Google I/O 2019 アプリの裏側 萩倉健支/Google

14:00~14:45

会場 タイトル 発表者
大講義室 プロダクトは歳を重ねるととどうなってしまうの 矢野りん/バイドゥ株式会社
4101 スマホ業界とエンジニアキャリア形成 里山南人/株式会社ビデオマーケット
4103 Nuxt.jsとFirebaseを使ったPWA開発事例 菅家大地/株式会社TAM
4104 産業用組込み機器へAndroid搭載の可能性 片山健久/ルネサスエレクトロニクス(株)
4105 最低限機能・格安・長持ちスマホのためのOS「SUNBLAZE OS」 常盤瑛祐/株式会社アメグミ
4201 〜初心者歓迎〜みんなで 東京公共交通オープンデータチャレンジしよう! イボギョン/GMOペパボ株式会社 ちーむパンサル
4202 Googleアシスタント最新情報と他プラットフォームへの拡張方法 一円真治/ヤフー株式会社
4304 TensorFlowで趣味の画像収集サーバーを作る 2019年5月号 Keiji ARIYAMA/めがねをかけるんだ / C-LIS CO., LTD.

15:00~15:45

会場 タイトル 発表者
大講義室 AI世代のデジタル教育―これからの時代を生きる子どもたちや私たちに必要なチカラ― 五十嵐悠紀/明治大学総合数理学部
4101 いざ就活!〜議事録係がAndroidエンジニアになるまで〜 林田守加/ちーむパンサル
4103 「5分で作れる!Glideappsではじめる超簡単PWA(プログレッシブ・ウェブ・アプリ)」 kinneko/JAG金沢支部
4103 PWA+TWA 進藤龍之介/日本Androidの会 Web Working Group
4104 OSAWGの近況と注目のRISC-VをFPGAで動かそう 鈴木直康/株式会社芳和システムデザイン 日本Androidの会運営委員
4105 電子立国再生への思いと、今挑戦していること 大橋太郎/株式会社電波新聞社 編集本部/出版部
4201 JavaAndroidを始めた人のためのJava -> Kotlinライブコーディング 中川幸哉/ウォーターセル株式会社
4202 Android Qのセキュリティ/プライバシー概要 木村隼人/日本Androidの会学生部
4304 食農を支えるプラットフォーム「みどりクラウド」と今後の展開 持田宏平/株式会社セラク

16:00~16:45

会場 タイトル 発表者
大講義室 クロスするリアルと仮想ー経済の視点 伊藤洋一/三井トラスト基礎研究所
4101 Androidにおけるパフォーマンスチューニング実践II 南里勇気/株式会社FiNC Technologies
4103 ServiceWorkerの実装 宮本将/日本経済新聞社
4104 空飛ぶクルマ「SkyDrive」の開発について 柳村将平/株式会社SkyDrive
4105 つらいと評判のAndroid BLEをまだまだ使い倒す話 原田賢太/JapanTaxi株式会社
4201 古から最新までのAndroidアンチパターン あんざいゆき/株式会社ウフィカ
4202 Flutter Recap from I/O 2019 + α 神原健一/NTTテクノクロス株式会社
4304 2019年春の技術であのARアプリを再現する 高橋憲一/株式会社カブク

Google I/O 2019 Recap!

Google I/O 2019

  • テーマ
    • Building a more helpful for Google everyone
    • privacy

Building more helpful for Google everyone

  • 全ての人々のためにより役立つGoogle
  • Duplex on Web
  • 検索結果をARで表示
  • Google Assistant
    • 30言語80カ国
    • 音声だけでスマホが操作できちゃう
      • OK Google言わなくていい
      • 個別のアプリの操作もできちゃう

機械学習/AI

  • Googleが提供する機械学習/AI
    • ML Kit
      • Firebase
      • モバイル
    • Google Cloud
      • Auto ML
      • スケーラブルに
    • TensorFlow
      • フレキシブルに
      • 自分でモデルを作る

ML Kit

  • TensorFlow Liteと比べて
    • そのままだとapkサイズ大きくなってしまうがML Kitだと解消できる
    • ML Kitなら一部のユーザだけに提供とかできる
  • ML Kit on device translation
    • オフラインで翻訳
    • 全てデバイス上で完結
  • Object Detection & Tracking
  • AutoML Vision Edge
    • モデルを作ること自体もAIにやらせる
    • 写真をたくさんあげたらかってに学習してくれる
    • 一度おとせばオフラインでも

TensorFlow

Android Q

  • プライバシーに関する機能が多い
  • 表面上は変更少ないけどアクセスのしかたなど変わるので改修必要

Kotlin first

  • Googleが作るサンプルなどはまずKotlinで提供
  • Googleのアプリの多くはKotlinだけで書かれている
  • Top 1000の内44%はKotlin
  • 新しい機能はあJavaはBest Effortだったり提供なかったりする
    • JetCompose

CameraX

  • Jetpackライブラリ
  • Camera2 APIを更に進化
  • Android L以降をサポート
  • ML Kitとの連携しやすい

Android Studio

  • Project Marble
  • 新しい機能追加より既存のものの改善重視

Google Play

  • latingの仕組みが変わる(今年の夏から)
  • 今までは全ての期間のLatingを平均していた
    • 直近の数字を使ったものに変わる

Design

  • Dark Theme
    • Android Qから強制的にダークモードにできる
    • アプリ作る人も対応が推奨
    • ダークモードでは彩度下げるとよい
  • バッテリー
  • Accessibility
  • Material Designも対応

Web & Chrome

  • Chrome 10年, Google 20年, Web 30年
  • Lazy Loadingをブラウザ側で
  • Flutter for Web

Privacy

  • Incognito mode
    • シークレットモードをyoutubeやmapでも
  • Live Caption
    • 動画に自動で字幕を付ける機能
    • 全てon device
  • 機械学習
    • on deviceで
    • Federated Learning
    • AIによるバイアスの発生を防ぐ仕組み

円周率世界記録31.4兆桁への道

  • 岩尾エマはるかさん(Google)

円周率と計算機の歴史

  • なぜ円周率を計算するのか
    • 人間の計算に関する進歩は円周率をどれくらい計算できるか
  • 紀元前で3.1まで分かっていた
  • なぜ円周率計算が難しいか
    • 桁数が多くメモリ要件が厳しい
    • 計算性能そのものは重要でない

今回の記録

  • 31兆1592億6535万....桁計算した
  • クラウドを使ったはじめての記録
  • 121日かかった

クラウドを使う利点

  • 数分でクラスタ作成できる
  • ハードウェア障害が少ない
  • スナップショットでバックアップできる

振り返り

  • 既存プログラムを4ヶ月走らせただけでは?
  • 始める前は誰も
    • ネットワークドライブで31兆桁計算できると思ってなかった
    • 単一VMを4ヶ月ヘビーに使えると思ってなかった
  • あとから見れば簡単に見えるのがクラウドのすごいところ

あんざいゆきPresents!理解が深まるビンゴアプリ feat.Nkzn

ハンズオン

セットアップ

  • packageの値は公開するとき一意にしないといけない
  • androidx.*
    • 3rd partyのライブラリ
    • チェック入れないと古いやつが入っちゃう

UI

  • match_constraint
    • maxまで幅をとる
  • wrap_content
    • 必要としてる最小の幅
  • スパナつきText
    • Preview用の値
    • 値を動的に変えたいとき用
  • 文字列は別ファイルで管理
  • dp
    • 解像度によらず同じ大きさ
  • sp
    • ユーザのフォントサイズの影響を受ける

Java

  • Activityという単位でページを作る
  • AppCompatActivity
  • onCreate
    • 初期化できるタイミングで呼ばれる
  • 画面を回転すると表示内容が消えてしまう
    • Activityを破棄して作り直すから
    • Activityを作り直す時でも値を保持しておきたい
      • => ViewModelを使うとActivityとは別で値を管理できるので保持できる
    • ViewModelはライブラリが管理してくれる
      • ViewModelProviders
  • LiveData
    • observeして値が更新されたら通知できる
    • Activityが作り直されるときにonStartというのが呼ばれる
    • そのタイミングでViewModelのデータを反映するようにする
    • Activityの方がViewModelより寿命が短いからobserverしたままにしておくとメモリリークしてしまう
    • Activityが破棄されるときにobserveが消されるようにしておく必要がある

「5分で作れる!Glideappsではじめる超簡単PWA(プログレッシブ・ウェブ・アプリ)」

  • kinnekoさん(JAG金沢支部)

Glide

  • Googleスプレットシートを使って簡単にPWAが作れる
  • Xamarin開発者が作ったもの
  • 何もしなくてもそれなりに綺麗なUIができる
    • UIの変更はGUIでできる
  • ログイン機能も簡単に設定できる
    • メールアドレス入力させてPINを送るとかも
  • Glideを使ってみて
    • 思ったほど複雑なことはできない
    • パフォーマンスイマイチ
      • PWAのメリットが・・・
    • deep linkできない(対応予定らしい)

PWA+TWA

  • 進藤龍之介さん(日本Androidの会Web Working Group)

TWA

  • Trusted Web Activity
  • PWAをPlayストアにあげられるようになった
  • ただしそんなにサクッとできるわけではない
  • ChromeのタブをActivityとして表示できるようにする
  • セッション、ストレージ、キャッシュなどChromeと共有

なぜわざわざアプリ化?

  • まだアプリでしかできないこともある
    • ウィジェット
    • 機種変更時に再インストールできる
    • マネタイズ
    • PWAとネイティブコンテンツの混在化
    • 同一ホストから複数のPWAが作れる

Digital Asset Links

  • アプリとWeb間の信頼の確保
  • intentの紐づけ

Flutter Recap from I/O 2019 + α

  • 神原健一さん(NTTテクノクロス株式会社)

Flutter

  • iOS/Androidのアプリを1ソースで作れる

Google I/O 2019

  • Flutter for Web
  • Flutterのセッション5つ

Material Design

  • MaterialDesignの問題点
    • どれもそっくりで似たようなものができてしまう
    • material theming発表(I/O 2018)
    • 独自のブランドイメージを出す
  • DarkTheme
    • flutterでも簡単に定義できる
  • Widget
    • もともとのwidgetをoverrideしてカスタマイズできる
  • Accessibility
    • semanticsLabelで読み上げ用の文字列を設定できる
    • 読み上げる順序の指定が可能に

For Multi Platform

  • Adaptive Components
    • いろいろなデバイスサイズでの表示に対応する
    • パターンをグルーピングして考える
  • Interactive/Passive
    • 手元で操作しながら画面を見る
    • 遠くにあって見るだけ
    • バイスによって画面までの距離が違うから文字のサイズも変えていかないといけない
    • バイスの画面サイズはとれるのでそれで出し分ける
  • iOS/Androidのデザイン
    • iOSのデザインはCupertinoというのがある
    • iOSだったら分岐して書くのでコードが複雑
    • Flutterの良さは1ソースでかけることなので、、

Beyond Mobile

  • Flutter for Desktop
    • hoverとかキーボードの操作も実装できる
  • Flutter for Web
    • JSに変換できる

Flutter 1.5

  • Material & Cupertino Widgetのアップデート
  • Flutter for Web
  • Dart2.3

「Google I/O 2019 Recap at LINE」に参加してきました

  • Google I/O 2019 Recap at LINEに参加してきました。

line.connpass.com

engineering.linecorp.com

タイトル 発表者
Google I/O 2019 Overview 藤原 聖
Androidの何か① Hidetsugu Tamaki
Androidの何か② 高島 友里
会場の雰囲気 櫛井 優介
Webの何か① 清水 大輔
Webの何か② YiXin Xu
Securityの何か コキチーズ
Flutterの何か Megumi Hattori
Speechless Live / Fireside Chat with Hiroshi Lockheimer Ken Wakasa

Google I/O 2019 Overview

  • 藤原 聖さん

Google I/O 2019

  • 2008年からで12回目
  • 2016: google assistant/google home
  • 2017: mobile/AI
  • 2018: AI
  • 2019: Building more helpful for Google everyone

Keynote

  • googleで検索した結果をARで見られる
  • google lensで読み上げ
  • AI for everyone
  • プライバシーの強化
  • on device
    • Live Caption
  • Android Q
    • Security/Privacyの強化
  • Devices
    • Nest Hub
    • Pixel 3a

レポート

engineering.linecorp.com

Androidの何か①

  • Hidetsugu Tamakiさん

Kotlin

  • I/O 2017で正式言語
  • Kotlin First
  • Java/C++のサポートも続く

Android Q

Dark Theme

  • なぜ重要?
  • Force Dark
    • Androidが自動でDarkに色を計算してくれる
    • 細かいところまでちゃんとやりたいならCustomで
  • Custom
    • -nightをつけて対応する
    • 画像もDark用を用意するとよい

Gesture Navigation

  • バイスのメーカーによって挙動が違ったのを統一
  • 変更点
    • バックボタンが消える
        - 左から右へのスライドに変わる
      
    • ナビゲーションバーの裏まで描画
    • 3ボタンと2ボタンは設定で切り替え可

JetpackCompose

  • Frameworkの同梱されないUIきっと
    • バージョン関係なしに更新できる
  • 宣言的なUI作成キット
  • Reactive Programming + Kotlin
  • 既存コードと互換性あり
  • まだExperimental

Androidの何か②

  • 高島 友里さん

Android Studio

  • Project Marble
  • System Health
  • Feature Polish
    • Apply Changes
    • Layout Inspector

Webの何か①

  • 清水 大輔さん

Google Assistant

  • Deplex on the web
  • Interactive Canvas
    • NestHubにブラウザで表示
    • 音声のインプットに対して処理をして画面を表示
    • Assistant Canvas API

Google Search

Chrome

  • Perception Toolkit
    • カメラを使って情報を取得する
    • バーコード読み取ってその商品を画面に出す
    • Shape Detection API
    • proj-fugu
      • ネイティブとWebのギャップを埋める

Webの何か②

  • YiXin Xuさん

Site Performance

  • Twitterがどう考えるか
    • responsive
    • mobile first
    • one codebase
  • TwitterLiteで30%高速化
  • パフォーマンス改善の工夫
    • code ssplitting
    • component based design
    • lazy load
    • < 3MB

Lighthouseの 新機能

  • Lightwallet
    • PerfBadgetを設定して測定できる
  • LighthouseCI
    • Coming Soon

Securityの何か

  • コキチーズさん

Incognito mode

  • シークレットモードがyoutubeやmapでも

Android

  • Qからハードウェアアクセラレーションがなくても暗号化される
  • TLS1.3デフォルトでon
  • 弱い暗号鍵はGoogleが強くして署名してくれる
  • scoped storage
    • /sdcardへのアクセス制限
    • 他のアプリが作ったファイルへのアクセス制限
  • 位置情報
    • バックグラウンドで位置情報をとるのは別で権限必要に

Web

  • Googleに報告される脆弱性の半分はWeb
  • Content Security Policy(CSP)
    • 読み込み可能なリソースをホワイトリストで設定
    • nonceをつける
      • ランダムな値
    • strict-dynamic
      • nonceで許可されたscriptを動的に読み込むことを許可
  • Trusted Type
    • DOM Based XSSを防ぐAPI
    • innerHTMLなど使うときに信頼できる型にしてから入れる
  • fetch metadata
    • リソース取得時にmetadataを付与する
  • Cross-Origin-Opener-Policy
    • window.openの挙動を制限

Flutterの何か

Flutter

Flutter App

  • Google I/Oに合わせて公開されたアプリ
    • Flutter Developer Quest
    • KENKEN

Flutter for Web

  • DartはもともとWebでJSの代わりに使おうとしてたもの
  • Flutterエンジンをブラウザように切り替えてWebで動かす

Multiplatform

  • バイスサイズにスクリーンとの距離が違う
    • そういった設計の工夫についてのセッション
  • iOSAndroid
    • 細かい挙動の差異はFlutterが吸収してくれる
    • UIのパーツが異なるものは実装で使い分ける
      • パーツは用意されている

Dart

  • 特徴
    • Productive
    • Fast
    • Multiplatform
  • UI開発に向いている言語
  • ホットリロードできる
  • 宣言的に書ける
  • UI as code
    • 親子関係の階層がわかりやすい

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

  • Inside Frontendに参加してきました。

inside-frontend.com

# タイトル 発表者
A-1 TypeScript: Why and how we adopted it at Slack Felix Rieseberg
A-2 Introduction to Lucet Adam Foltzer
A-3 Nuxt.jsで中規模サービスを統合した話 Koichi Sawada
Hajime Sasanuma
B-3 Making less of the web with feature policy Andrew Betts
C-3 デザインエンジニアとフロントエンド Shinichi Kogiso
A-4 formの送信ログから反省する、本当は必要だったvalidationや機能たち Yuta Ide
B-4 Web App Checklist 〜高品質のWebアプリケーションをつくるために〜 Kazunari Hara
Marina Toki
C-4 いちからデザインシステムを作ってみて学んだこと Kengo Haruno
A-5 BFFのDeveloper Experience Yosuke Kurami
B-5 strobo.fm公開収録 Shogo Sensui
Hiroki Tani
C-5 AbemaTVにおけるCSS is too fragile問題に対する解 Shota Kubota
A-6 世界中誰もが使えるサービスを目指して、Web標準で作るガラケーサイト Mariko Kosaka
B-6 Loading Performanceとの向き合い方 Sho Miyamoto
C-6 品質と開発速度を両立させるために捨てたものと守ったもの Tsuyoshi Wada
Soichi Masuda

TypeScript: Why and how we adopted it at Slack

  • Felix Riesebergさん(Slack)

SlackのデスクトップアプリをTSに移行した話

  • Electronを使ってる
  • JSにバグが有るとクラッシュする
  • 構造化されたコードを書かないといけない
  • JSDocでドキュメント化
  • TSのよさ
    • 型がある
    • エディタの補助がきく
  • KOAをつかったけどドキュメントを開くことなく開発できた
    • 型と補完のおかげ
  • ESLintはすばらしいがTSLintはまだそこまでいってないe
    • ESLintがTSサポート始めた
  • JavaScriptしかやったことない人は型を知らない
    • そういう人にとっては型が難しい

Introduction to Lucet

  • Adam Foltzerさん(Fastly)

Lucet

Web Assembly

  • 低レイヤーの言語
  • 高パフォーマンス
  • ブラウザで動く
    • サーバでも動く
  • ブラウザ内でも安全に動く
  • WebAssemblyに変換できる言語
    • Rust, C, C++ TS, go, swift

Terrarium

  • RustやTSでかいたWebAssemblyをアップロードできるWebサイト

Nuxt.jsで中規模サービスを統合した話

  • Koichi Sawadaさん(yahoo)
  • Hajime Sasanumaさん(yahoo)

ebook japan

  • ebook japan + yahooブックストア
  • 開発期間約1年
  • 電子書籍販売サービス

開発体制

  • FE -> yahoo
    • yahooの資産が利用できる
  • API + DB -> ebook
    • ebookの表船機能/データ
  • vue × Nuxt
    • vueはデザイナーが理解しやすい
    • ライブラリアップデートの手間削減
    • 初心者向けに日本語ドキュメント
    • Reactは(当時)ライセンスの問題
  • node + express

風土の違い

AtomicDesignへの挑戦

  • なぜ?
    • 新規回月なので途中導入より入れやすい
    • デザイン変更が多発が予想できたから
    • UIの一貫性を保ちたかったから
  • 苦労したこと
    • エンジニアとデザイナーの成果物が違う
    • スクラムと相性悪かった
      • 通化していく作業の優先度が低く改善が疎かに

実装上の苦労したこと

  • apiから返ってくるデータが大きい
    • 使わない情報もたくさん入って返ってくる
    • 開発機関制約の中で大は小をかねた形
    • mixinsを使ってget処理をまとめた

リリース後の改善

体制

  • 動くものを見せるとこに集中しすぎた
    • エラー処理やシステム面での改善が放置気味
  • 経験豊富なエンジニアがいない
    • フロントエンドのサポートチーム追加
    • PRのレビューや実装の相談をうける

システム(パフォーマンス改善)

  • api呼び出しフローの改善
    • Promise.allできるものはまとめる
    • 描画語でいいものは描画後に取得
  • レスポンスサイズ削減
    • apiから取得したデータを削ってからclientに返す
  • JSファイル改善

いちからデザインシステムを作ってみて学んだこと

  • Kengo Harunoさん(yahoo)

デザインシステムを作るきっかけ

  • 多くのサービス多くの関係者
    • 20サービス関係者1000人(デザイナー/エンジニア/ビジネス/業務委託)
  • デザインがサービスでばらばら
    • 一貫性確保
    • デザイン開発効率化
  • 何を作る?

デザインシステム開発(デザイン編)

デザインガイドラインの策定

  • デザインの定義
  • 抽象的なスタイル定義
  • 具体的なルール

コンポーネントのリストアップ

  • 名前をつけていく(時間かかった)
  • 汎用的過ぎて名前むずい
  • 業務固有すぎてしっくりこない
  • 見た目にとらわれずどんな役割をもっているかを考えて選ぶ
  • 全員が納得するものにした(納得しない=適切でない)

スタイルガイドの制作

  • sketchでデザイン作成
    • あらゆるケースや状態を考慮しないといけないので大変だった
    • 種類×サイズ×状態分作る
  • デザインルールをドキュメント化
    • デザインルールを文字化するの難しい
    • 不明瞭な部分が残らないように
  • レビューは全員(4人)がOK出すまでやる
    • 共通認識を担保

デザインシステム開発(フロントエンド編)

コンポーネントライブラリの提供方法

  • 最初はhtml/css/jsでの提供
  • コーディング設計
    • BEM記法
  • Fractal
    • スタイルガイドジェネレーター
    • markdownで書ける
    • Handlebars + yaml
    • 静的サイトとして出力できる

方向転換

  • Reactを使ったプロジェクトが多い
  • Reactコンポーネントとして提供してほしいという要望
  • html/cssでの提供ではは活用しづらい

Reactでコンポーネントライブラリ

  • Storybookベースのものに変更
  • CSS Modules with Sass
  • TS
    • 有識者はいなかった
    • 性的チェックでエラー気づきやすい
    • エディタ補完便利
    • 型でデザインをより厳格化できる
  • スタイルガイドをGatsbyで静的ページとして作った

振り返って

  • デザインから実装までこなすのはとても大変だった
  • デザインシステムは巨大なプロダクト
  • 使う人とのコミュニケーションが大事

BFFのDeveloper Experience

  • Yosuke Kuramiさん(FOLIO)

BFF

  • Backends for Frontends
  • UX視点
    • パフォーマンス
    • UIに必要十分なAPI
    • 統一したUI
  • マイクロサービス視点
    • ドメインに注力
    • シンプルで再利用性の高いAPPI
    • サービスこどの技術得意製
  • これらをつなぐためにBFF

FOLIOのBFFの役割

  • API Aggregation
    • koa
  • SSR
    • react + redux

BFFのいいところ

  • バックエンドはドメインの開発に注力
  • フロントエンドはUIの要求をAPI
  • SSRで高速化
  • => ただしフロントの仕事は増える

BFFを効率的に開発するために

バックエンドを待たない

  • IDL driven development
  • Interface Definition Language
  • FOLIOではThrift
  • IDLからコードを生成

サービスの仮データ

  • 開発中のAPIはモックに差し替えたい
  • 開発済みならテスト環境につなぎたい
  • BFFのコードはどちらにつないでも変わらないようにしたい
  • Direct Proxy

Developer向けの機能

  • BFFはフロントエンドがいじるので開発者用のAPI作ってUIを作ることもできる
  • stateを変える画面作って画面のバリエーションを試せたり

世界中誰もが使えるサービスを目指して、Web標準で作るガラケーサイト

proxx.app

今の時代のガラケー

  • スマートフィーチャーフォンのこと
  • 機能
    • KaiOS
    • モダンブラウザ搭載
  • アフリカ、インド、インネシアではやってる
    • 安いから
  • 画面小さい、タッチスクリーンない、十字キー
  • キャリアがアプリを握っているからWebで提供するようにした方がいい

ゲームを作ってみる

  • Webの強みはドキュメント
    • その正反対をやってみる
  • ユーザのインプットが多いもの
  • あらゆるデバイスをサボーとするようなもの
  • => マインスイーパー的なもの

どうやって開発したか

  • チームスペック
    • フロントエンドエンジニア3人
    • kaiOS初めて
    • WebGL初めて
  • どこまでやるか
    • 1コードベースで作る
    • a11y対応も
    • パフォーマンス第一
  • コード
    • ゲームロジック
    • Stateサービス
    • UIサービス
    • 描画処理
    • 前者2つはWebWorkerで動かす
  • FW
    • WebWorkerとのやりとりはComlink
    • preact

github

github.com