So What!?

カテゴリ

記事

連絡先

何か間違っている情報などがあればTwitterにてメッセージください。

ご注意

このBlogはアクセスデータをGoogle Analyticsおよび、Cloudflare Analyticsに送信しています。また研究開発用にSentryにパフォーマンスデータを送信しています。それ以外のデータは収集していません。

次世代Webカンファレンス

2019年1月13日

SRE(#nwc_sre)

プロアクティブなタスク（チーム本来のタスク）と、リアクティブなタスク（サポート的なタスク）が50%になるように（タスクはGitのイシューで管理）まずはラベルをつける

という話は、サービス開発と他部署サポートなタスクの話とかぶるところがある。

ロードマップを作る時に過去2年分のインシデントを振り返って、多発してるやつとかはロードマップに組み込む

クォータのはじめにロードマップを決める。 とにかくサービスをつくるというよりも、SLI、SLOを上げていく目標をたてたほうがいいかもしれない。

SLO 100%に向かうといろんなタスクが発生する -> こっちのタスクはできなくなる -> 開発速度は遅くなる

上層部に承認を得ることで、プロダクトオーナーに認知させる。

アラートの設定内容をレビューしてもらう -> 承認 === 夜中に起こされてもOK

狼アラートを減らすため。アラートを見てみたら、実際には全然大丈夫じゃんってパターンを減らす。

マイクロサービス化をするには共通化する点を減らした方がいい（ボトルネックを減らす）

QAに通じる。デプロイ前にいろんな部署から、受けるところがボトルネックになりやすい。

プロダクトを出したので、モニタリングなどSREとしての仕事はしなくて良いのか

用語

  • SLI（Service Level Indicator）: 何を目標の指標とするか（リクエスト数など）
  • SLO（Service Level Objective）: 内部的に持つ目標となる数値（99.99%など）
  • SLA（Service Level Agreement）: エンドユーザーに対して、この可用性で提供してますという契約。罰則規定がある場合もある。
  • エラーバジェット: 許容可能なエラー率（時間、範囲、レベル） のこと。SLAとは逆の視点でみて、0.01%は不具合が生じても構わないという指標。
  • オンコール: 緊急時の対応をすること、人
  • ポストモーテム: ポストモーテムとはプロジェクトの終了後、プロジェクトを振り返って行う「事後検証」のこと。反省会とは違って、次に繋げるアクションが必ずある。
  • モノリス: マイクロサービスでない従来型のアーキテクチャ。大きな一つの機能により、一つの処理を実現するアーキテクチャ。
  • スピネーカー: SpinnakerによるContinuous Delivery

A11y(#nwc_sre)

WCAG 2.1について

今日的にa11yに関わるだろうといえることに関する基準ができたことはいい点。 今の基準で考えてしまうと、2,3年後になると、また勧告が遅れる可能性。

WCAGはブラウザでみることを想定している項目が多い。 サービスの一部分を別のモダリティとして提供することで、IoTやスマートスピーカーなど個々に選択する。 コンテンツ側の対応と、デバイスで対応の両輪となる？

人 vs API 使えない人を減らすためにa11y対応をする派と、PCが使えるようにしておくため、 スクレイピングしやすくするために対応しておく派

フロントエンドでアクセシビリティ対応しようと同じレベルで、 データをオープンにすることも重要な点となってくる。

コンテンツ側でよく使うことで、ベンダー側で実装しやすいかもしれしない。 ブラウザベンダーが実装しても、サイト側のユースケースがないとそれ以上進めていくことができない。

ビジネスとa11yの関係は社会が変わらないと、今後も変わらない

障がい者は生産性がないと思っている奴がいる

所詮他人なので、個人でレベルで気をきかせる必要はないと思っているが、会社としては意識していくべきだと思う。

不要な属性を消してしまう可能性がある = レビューで止める = 運用でもレビューは必要である。 画像を更新した時にAltを更新することを忘れることとかってないのか？ 相手が可視化されない状態で意図（Altやキャプションなど）をつけるのはけっこう考えにくい つまり、相手によって意図（コンテンツ）が変わってしまうこともある。

知らないうちに使えるものは知らないうちに使えなくなる可能性がある。

インスタのストーリについて

  • テキストでない
  • ユーザーによって作られるコンテンツ
  • 時間で消える

Youtubeでサイトの読み上げだけをしている動画 -> Webの入口がブラウザじゃない人向けのコンテンツ。

にたいしてどう対応すればよいのか。

Design(#nwc_design)

デザインシステムがなぜ流行っているのか。 Reactが使われることで、デザインと実装のギャップが埋めやすくなった。（ドキュメンテーションとコードが両立している）

課題

デザインは統合型で、パーツを先に作って組み合わせることは基本できない。実装は逆にコンポーネント型。 2~3年後にデザインシステムをどうしたいのかを考えた上で、次の四半期でできることをやりましょう。 そうしないと、デザインシステムを作って終わりになってしまう。 デザイナーがいない組織にデザインシステムを導入する場合、詳細度が低いものをつくるのは危険。 外注するときは、外の人も使い方を理解しないといけない。 100%デザインシステム通りにつくることはできない（余白とか）ので、一部システムから外れたデザインをするが、それを明文化することは難しい。 やれてないことが多い。デザインシステムどころじゃない。 Webデザイン、Appデザインの文脈ではなく、デザインとして考えると、開発とかのスピード感についていけない感がある。

デザインシステムが導入されるまえにやっておくべきこと

  • デザインガイドライン、スタイルガイドを作っておく。
  • ゼロからやる必要はない。Bootstrapはドキュメンテーションがしっかりしている。あのレベルを作れるなら0から作ってもいい

文化の違い

ドイツはノーコンテキストな言語なので、スタイルガイドの詳細度はかなり高い。 日本語は意図を汲み取ってやってしまうことが多い。ただ、そこを取っ払ってしまうと成立しない、時間がかかることもある。 海外は人種や宗教も多様だから、一つのカラーにも色々な解釈ができる。だからこそ明文化が必要になる。

WSは合意形成の場と捉える

結論がでると思ってやるのは危険。みんなが作った感がでるのもよい。

マテリアルデザインについて

自社のシステムがないからマテリアルデザインにたよることになる。 プラットフォームが変わると拠り所がなくなってしまう。

疑問

  • 一貫性を持たせるため、効率化するためのデザインシステムは作って終わりではだめなのか

music(#nwc_design)

Web Musicというのは、Web AudioとWeb MIDIをひとくくりにしたもの。 MIDI自体は40年くらいの歴史ある。

Web Audioについて

そもそもはWebゲームにオーディオをつける必要性があり、実装されたのが起源。

v2は高レイヤー、低レイヤーのどっちか

高レイヤの機能: すでに音ありきの機能 低レイヤの機能: 低いレイテンシを提供する必要があるなど、プロシューマー向けの機能。Unityのランタイムなどから扱いやすく。

APIはWebIDLにもとづいて作られているだけで、JSから呼び出される想定で作っているわけではないが、Cなどのバイナリから呼び出されるものではない。 W3Cの仕様にJS以外のリファレンスが乗る可能性はある。

N Synth Super;

グローバルにAPI生えすぎ問題

昔はコンテキストに生やしていたが、W3C内に全体のAPIを整備する人が、そういう方針をとった時期があった。

議論する場がすくない

事業会社にも議論してもらわないといけないので、Audio Community Groupをつくって、より高レイヤーの話をする

Web MIDI

楽器の中でも使用されている経緯もあり、歴史が深い。

System Exclusive

各社の独自拡張ができる

WebでMIDIがつかえること

外部のMIDI機器とやりとりするプロトコルの仕様。楽器だけではない。 シーケンスに落としこみやすいコンテンツはMIDIに向いている 音楽と同期したアニメーションとかはMIDI制御がいいのかも？ 万人が使うものではないが、既存の延長としてクロスプラットフォームとして音色管理ツールとかが使える。

ファームウェアをWeb MIDI経由で送信して実機のアップデートを行う。

Web Musicの未来

Web Musicが身近になることで音楽と向き合い方が変わる。 コラボレーションやポータビリティには変化ができる。 クラウド側で音をレンダリングすれば、低スペックのPCでも出力できる仕組みとか。ストリーミングダウン。

定石がある

定石部分をAIがつくって人がブラッシュアップする（個性を出す）時代。

同時多発ライブ

音楽の流れはライブ -> レコード -> CD -> ストリーミングになってきているが、ライブに戻る？ 演奏データを配信して自宅の楽器を鳴らす。エルトンジョンのライブを同時に多地域で聞くことができる。

フォーマットは変わらないけど、作り方や使い方は変わってきている。

次世代のサウンドフォーマット

ミックスダウン前の生データをストリーミングで配信して編集しつつ、ダウンロードもできるWebサービスができる 1曲の価格があがりそう。絵文字レベルの気軽さがある音楽（ジングルとか）が使える。

完成系ではなくそのまえの段階を販売するようになるかも。

Frontend(#nwc_front)

方法論的にがはあらかたでそろった感じではあるが、どういう風に作るか（DX的な視点）は結構違う。

フレームワーク的にはコアの機能を外して薄くしていく流れ。 バージョンアップも破壊的な変更はなく、マイグレーションの仕方とか

ブラウザの進化速度が高い APIによっては生で書いていくのは敷居が高いかもしれない。

状態管理に関しては、Redux、Fluxが定番化してきている。

Extensible Web

TypeScriptについて

TSLintについて

TSCのコンパイル設定を厳しくしておけば問題ない気がする

テストについて

そこは変わらない。スナップショット、状態管理のユニットテスト。 高レイヤー（スクリーンショット依存）のテストが増えてきた。

コンポーネント設計

これまではAtomicデザインしか拠り所がなかったが、Lazyloadのようにどこでコンポーネントを切るかの決め方、基準が今後増えていくかもしれない。

Lazy-loading components in React 16.6

デザイナーの切り方、エンジニアの切り方が違うので決め方がむずい。

storybookの影響

コンポーネントにアプケーションロジックを含めないようにしたりとか、

Web components

コンポーネントを作るものであって、アプリケーションを作るものではない。 jQuery Pluginレベルの手軽さで、リッチなコンテンツが作れるようになると便利 Web componentsを各フレームワークがどうラップしていくかの違い。

Material Components for the web

Polymerでアプリケーションを作っていくのは辛い。が、 コンポーネント内でCSS、JSを隠蔽されて裏側でフレームワークが使われているなんてことは起こりそう。

iframeを使うSNSウィジェットを置き換えてくれると嬉しい。

スレッド

  • Reducerをworkerに逃がして、Viewだけメインスレッドで
  • Webフォントのサブセット
  • worker DOM

マイクロフロントエンド layered API