elly blossom

INSIDE FRONTEND#2 レポート

Tag : ,

INSIDE FRONTEND#2

写真：INSIDE FRONTENDというイベントでもらったシール

INSIDE FRONTEND#2が、2018年2月11日大手町の日経カンファレンスルームで開催されました。

Web高速化で話題となっている日経新聞社での開催、そしてスポンサーにCDNのFastlyが付いていて、高速化チューニングをするエンジニアには、注目のイベントです。アクセシビリティの分野でも注目のYahoo!や、CyberAgentも協賛していました。

このイベントは、30分のセッションが同時並行で2本x5回、AMAブースでは、事前にgithubから受け付けていた質問、またはその場で登壇者への質疑応答ができる形式で進んでいきます。

最初のセッションは、伊原氏の「freeeのアクセシビリティ、いまとこれから」を選択しました。
伊原氏の講演は、昨年のWeb Accecibility Conference 2017や、html5jの勉強会でも聞いていたのですが、自分の相方が重度の視覚障害ということもあり、アクセシビリティが今後どのようにWebで発展していくのか興味を持ちました。

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

伊原氏は主に、アクセシビリティの考えを自社に根付かせる方法を語りました。
Yahoo!やCAなどのアクセシビリティを施行している各社のモデルをまとめたり、社内勉強会や、Qiitaチーム、社内ブログ、インクルーシブHTMLの輪読会などをされたそうです。インクルーシブHTML読んでみましたが、最初っからhandlebars.jsを使ったサンプルが出てくるなど、理論だけでなく実務にも向いた内容で面白かったです。

私もコーディングの際は、高速化やSEOに考慮するのと同じようにアクセシビリティも考慮して書くものだと思っています。
インクルーシブHTMLにもありましたが、少し考慮するだけで、アクセスできるユーザーが増える。
「ユーザーのできないをできるようにする」のは、ものづくりの上で大切なことかなと。
例えば子供用のサイトなら、難しい漢字が出てきたらrubyタグでルビをふるとか、そんな感じのホスピタリティを持って作っていくこともアクセシビリティに通じるかなと思いました。UXは、デザインとコードと少しの愛情でできています。なんてね。

伊原氏の話を聞いて今後取り入れて行きたいと思ったのは、以下のアクセシビリティのテストです。

  • iPhoneのvoice overを使って、作成したWebページを読み上げる（気軽にできる）
  • W3CのEasy Checksでサイトを評価する（じっくり取り組めたらいいな）

それにしても、少しショックだった内容は、やはりWebアプリよりもネイティブアプリの方が、全盲の方には使いやすいという事実でした。
ネイティブアプリは機能が絞られていて、タップできないことはないということ。
スマートデバイスは、やはりネイティブアプリにシフトして行きそうだな。と頑張らねばという思いです。

最後に伊原氏は、コーダーがつまづくマークアップはだいたい同じであること。
例えばタブはaタグを ボタンはbuttonを。
あほむさんのよくあるヤツと対応方針をやるとだいたい改善案書いてあるとのことなのでEasy Checkかける前にやっときます。

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

ここまで書いて、だいぶ力尽きましたが、ブログ書くマン枠で参加したので続けます。
次は、react.jsのすごい人と認識しているmizchi氏の「現場の ES201x とアーキテクチャの変遷と未来」に参加しました。ES6は書き始めたばかりではあるものの、確実に主流になるので選択しました。

mizchi氏　最初の一言「フロントエンドのみなさん！　消耗してますか？」
みんなの心「消耗してまーす！！！！！」　エ、モ、いーーー。

mizchi氏は、これまでのフレームワークを振り返り、
今後、何を選択し変化に強い設計をしていくかに付いて語りました。
振り返り。。。Senchaあったなぁ jQMあったなぁ knockoutさわったなぁ　今はAngular、vue、reactだよねと。

設計的には、
太古、手で木を書き換えていた時代
（うちらはappendChildで木（node）を書いていた。）
↓
テンプレーティングの時代
（テンプレートでnode作ればいいじゃん。コンポーネントの概念ができてきた。handlebarsとかでやってたよね）
↓
データバインディングの時代
（テンプレートで書くのは一緒だけど、コンポーネントを作って、書き換えたりね。knockoutとかAngular(MVVM)とか。文字列を展開するものから木構造を出力するものに変わりました。いつの間にかブログが文語調が口語体になってる。。登壇者に影響されてる。）
↓
現代：
Flux/Observableの時代
（現代 Client side MVCは亡くなった（backboneモデル） event state viewの時代。
elmとかrxとか、今後はReduxの時代 む、、むずい。。
eventのストリームからstateのスナップショットを生成。obserbableのスナップショットがbindされる。
viewはstateのスナップショットを表示している）

すみません。ここからメモの貼り付けになります。。。m(–)m
今後のトレンドはテンプレートでちゃんとした設計。あとはマイクロチューニングで理想に近づけていく。
最近盛り上がってる言語は型推論があるということ。GUIはテストが書きづらいから型が重要視されている。
昔：手動テストでぽちぽち UT, Linter。
未来：webcomponentがきたらフレームワークしぬの？
viewの末端はカスタムエレメントになるだろう。
マテリアルデザインのｘｘ実装とかなくなる デザイントレンドすぐ変わるから、そこと蜜になりたくない。
われわれに道はあるのか。。。

今後やっていくこと

  • lint書く
  • 型書く
  • グローバル変数消す -> ES Modules
  • テスト書く

コードは捨てられることが大事
モジュールの境界が明らかでないコードはやばい
viewとstateの分離(Flux)

とりあえずやっとけ prettier eslint
守れば壊せる

FEとはなにか なにやってもいい。
スピードのためにフロントエンドをやる。継続して、コードを改善していく。
いまのフロントエンドは技術のごった煮。自分に必要なものを見定めいていこう。

mizchi氏の講演で、印象に残ったのは「コードは捨てられることが大事」ということ。
今までの消耗からの学びでもありますが、日頃からモジュールに何でもかんでも詰め込みすぎない、
捨てやすいコードを書くことを念頭に書いております。捨てられなかったらフレキシブルに改善できないですし、
改善の最初の一歩は、捨てやすいコードを書くことかなと。

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

JSネタが続きますが、次にYahoo!の黒帯エンジニア穴井氏の「コンポーネントTDDの実践から見えたもの」を選択しました。

TDD全然やってませんが、これからテストも改善して行きたいので頑張って参加しました。
どこでテストを組み込むか、それが問題だ。
テストといえばリリース前にガッとやるイメージですが、コンポーネントの単体テストを書くメリットとその内容を伺いました。

コンポーネントの単体テストでは、Reactならenzyme、@vue/test-utilsで使うそうです。
テストの内容は、端的にいえばセレクタで探して、コンポーネントで探して、イベントが再現できるかを書くというもの。

実際に業務でどのように運用しているか。

  • 新規コンポーネントは必ず単体テスト先に書く
  • 週に1回改善タイムを作り、地道に書いていく

すげー！

コンポーネントはすぐに変わっていく・・・
ではTDDでやろう（テストを先に書く）
メリット：仕様に対するテストケースを自然とかけるようになる（素晴らしい）
すみません。ここからメモの貼り付けになります。。。m(–)m。
JSのコアな話になると概要理解でいっぱいになるのであった。。勉強しよ。。

TDDの流れ

  1. テストを書く　(細かくステップを作るのが大事)
  2. アサーション追加
  3. フォームの別パターンの追加
  4. テストを動かして失敗することを確認
  5. 実装する
  6. テストが通るようなとりあえず実装　実装　実装
  7. リファクタする

繰り返し。。

テストのコツ

  • View的なロジックをテストする。(v-ifの出しわけができてるかなど)
  • セレクタや要素でfindしないでdata-testidみたいなのをつけて、テストする。(詳細度を高める)
  • vue/test-utilsはfindできないケースを知る(shallow関数でmountedが呼ばれる。slotの中身はfindできない。はまるからmountedするしかない)

TDDのメリット

テストを書くのに仕様を考えるから時間かかるけど実装の時間が短くなる。
ゴールが明確なので実装に迷いがない。
TDD前は、描画まで完成図の実感がなかった。
TDD後、想定どおり動いている状態を常にキープできる。
無駄なテストケースを書かなくてよくなった。ただテストケースがふえる。
メソッドやpropsのテストからふるまいのテストにかわるようになった。

TDDの悩み

布教に困っている。。。時間かかる、 テストコードのレビューもちゃんとやる文化ほしい。

感想

布教か。。。はるか昔、なぜかJavaのテスト書く勉強をしたことがあったなぁ。
師匠もブログでよく布教していたっけ。
時間かかってすみません。。が、少しずつテスト改善して行きたいなと思っております。

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

ようやく高速化ネタとなります。
宍戸氏の「日経電子版を速くするためにやっていること」。
昨今、日経電子版の表示スピードやばい！って高速化界隈を賑わせているあの日経新聞社の施策を聴けるとは！。楽しみにしていたトピックでした。

AMAで気づいたのですが、css radarさんもいるし、そりゃめっちゃ技術力高いじゃないですか！うちにも来てくれないかなぁ。。。
さて、日経電子版、コンテンツもユーザーもすごいサイトです。

  • 一日900本記事
  • 月3億PV

日経では、サイトの速度が1秒落ちると、ユーザーエンゲージメントは5%下がるという。
（ここでいうエンゲージメントは、日経が独自に定義しているもの）
最重要KPIをサイトの速度にした結果、表示が2倍速くなったそう。

施行前に現状確認に使ったページスピード測定ツールは下記です。

  • Speed Curve(継続的に計測)
  • webpagetest

技術的な施策としては

CDN（fastly）

  • 常時SSL
  • IPv6対応
  • HTTP2
  • リソース圧縮
  • webp(Saasのimgixを使用)

feature flagsというfastlyの機能がABテストで便利。
FlagAPIで、クッキーを監視して、描画を出しわけ
ページごとのキャッシュコントロール(Varyヘッダでクライアントの種別をキャッシュできる。)
ただし開発かなり大変とのこと。

フロントエンド

  • 外部ファイルの非同期ロード（うちもやったことあるけど、jQuery依存のdeferつけるの大変な感じ。。）
  • Above the fold部分のcssインライン化（きついやね。）
  • セクション単位の遅延ロード
  • スケルトンスクリーン（intersection Observerで2回読む む、むずい）
  • 次のページのprefetch
  • レスポンシブ
  • PWA化
  • Prerender:カーソルがアイコンに乗った瞬間にprerenderしてる（すげー。でも今のChrome一時的に動いてない）
  • dns-prefetch
  • Service Workerによる事前キャッシュ（2,30msで返せるようになる。。すごい。）
  • Nikkei UIというコンポーネントを作成（開発効率もアクセシビリティにも対応。見たい！）

高速化の基本としては
まずはLighthouseやWebpagetestで分析しよう
速くすることより遅くなる要素を減らしていこうとのこと。

日経電子版、最重要KPIがページスピードとは本当にすごい。インフラとフロントが協力して、ガチでページスピードのボトルネックを排除して、webpなどにもチャレンジしているの、すごい組織だと思いました。

デザインシステムとコードを密結合するワークフロー

最後のセッションは、デザインネタを選択しました。
登壇した菅原氏は、北海道の帯広とかに支社があるファームノートという農業の会社で、
基本的にリモートワークでフルスタックな感じで仕事をされているそうです。

ファームノートは、牛を管理するアプリを作っていて、具体的には
牛の首にセンサーをつけて、牛の状態を監視して、牛が発情したよーなどと、スマホに状態をとばしたりするアプリだそうです。

で、菅原氏いはく
「牛のプロパティは400個くらいある。。。開発すげー大変」
さらに
「リモートやっているから、議論の空中戦で、仕様が決まらない。。。」
↓
問題はコミュニケーションコスト
企画　＞　デザイン　＞　コーダ　＞　開発　＞　テスト
（ここで企画がはじめて見て違うと言ってくる）
伝言ゲーム はしょりたい

デザインシステム：
デザインツールのシンボルと、コーダーのコンポーネントを1対1にする！！！
（しびれますな。理想的な世界観だ）

獣医さんも営業も、企画もデザイナーもコーダーも全員でUIデザインやろう

救世主ツール　Figma
（GoogleDrive * sketchのような、みんな同時に編集できるソフト）

パワポつかえればFigmaも大丈夫だよと エンジニアも、獣医さんも、企画者も
デザインで話し合いを始めた
絵に描いてないものは絶対に実装しないルール！

とりあえず最初はデザイナーが一人で3画面くらい作る（アトミックデザインの粒度でシンボル化する）
それをみんなでならべるだけ プロトタイピングもできる　xdみたい。

シンボルの依存関係をvueで書き起こしていく

最近のフルスタックなリモートワークすごいな。と。
リモートじゃなくても、リリース直前に仕様変わることたくさんあるもんなぁ。。
同じフロアでも企画の見える世界観とエンジニアの見える世界観の差を感じる会社は多いのでは？
Figma　取り入れていきたすぎるツールだと思いました。