2018年9月22日(土)にJSer.info 400回記念イベントを開催しました。
無事JSer.info 400回記念イベントを行うことができました！

• JSer.info 400回記念イベント - connpass
• 2018年9月22日(土)に JSer.info 400回目記念イベントを開催します - JSer.info
• JSer.info 400回記念イベント - Togetter

今回は「憶測しないで議論しよう」というテーマで開催しました。
このテーマについてはJSer.info 400回記念イベントというスライドでも話をしていますが、参加者全員が何か得られるものがあればいいなというPositive Sumの考え方で設定しました。
参加して何か得られたものがあれば幸いです。

本日はご参加いただきありがとうございました！

Special Thanks

• 会場: @koba04 サイボウズ株式会社
• 受付: @bokken_, @nagisa292
• 議事録: @lequinharay, @448jp, @suzuki
• 質問モデレータ: @takanoripe

以下はイベント当時にリアルタイムで書かれた議事録です。

• イベントページ: https://jser.connpass.com/event/100092/
  
• 発表内容一覧: https://docs.google.com/spreadsheets/d/1-rKE9ft4mawt90R2NUoCZGZbdOBqwjcTzfpVw8lStZE/edit#gid=0
• 質問ボード: sli.do/#jser400 発表に関する質問できます

JSer.info 400回記念イベントについて - azu

スライド: http://azu.github.io/slide/2018/jserinfo/400th.html

14:15-14:30 Data of Web - azu（書記担当：@suzuki）

• 紹介アイテム数、8322
• 年間投稿記事数、年間52〜53回
  • ペースはずっとキープ、いま400回
• 更新方法
  • 以前のワークフローで継続
  • 調べる、検証、説明、共有
• Twitter Bot
  • 進捗報告、PRを出すなど
• 記事ドラフトの自動作成
• データセット
  • タイトル、URL、説明、タグ、関連URL
  • @jser/stat
• 記事から自動生成できる Podcast システム
  • https://github.com/jser/podcast
  • うまくいかなかった
• AMP Story
  • AMP Story に対応している
  • https://jser.info/**ampstory**/2018/…
• 目的
  • 紹介した情報を知ってもらいたい
• 今日のイベント
  • データはある
  • 議論があると効率的に知れる
• 質問受付
  • https://app2.sli.do/event/wjfqikyd/questions
• 「憶測しないで議論しよう」
• 憶測が起きてしまうとき
  • 推測
  • 根拠（理由＋データ）あり
  • 憶測
  • 根拠なし
• 個人の知識には限界がある
  • Webにはデータが溢れている
  • データ = 根拠
• GitHub …?
• Chrome UX Report
• HTTP Archive
  • Web Archive の一部
  • パフォーマンスデータ、ライブラリなど
  • 「一般的なページサイズ」なども調べられる
  • フレームワーク別にも出せる
  • Wappalyzer
• Browser Compatibility Data
  • Can I use っぽいもの
• データは完全ではない
  • 検証が必要
  • 偏っている、主観が入ってしまう
  • データ != 情報
• 「差別」の難しさ
  • 差別語は単語と文脈で変わる、難しい
  • 例: blacklist
• 感情を感情で返す問題
  • 感情で返すと話は進みにくい
  • RustConf 2018
• Zero Sum vs Positive Sum
  • Zero Sum は目指さない
• 議論は勝ち負けではない
  • 最適な解決方法を目指す流れのこと

14:30-15:00 「1⇒100」のために「0⇒1」を考えるフロントエンド - @sakito（書記担当：@448jp）

• 今日はサービスを運用する話
  • https://speakerdeck.com/mukai21/1-100-falsetameni-0-1-wokao-eru-hurontoendo
• 自己紹介
  • Yahooでフロントエンド
  • 普段はReactがメイン
  • B2Bサービスの運用と改善をやっている
  • BONFIRE Frontend
• 前置き
  • 0→1
  • サービスを立ち上げるときのこと
  • 技術やアーキテクチャの選定
  • 1→100
  • サービスを運用して成長させていくこと
  • 新機能の開発やチームの拡大、レビュー
  • 建設現場の例え
• 1→100
  • さまざまなことが起こる
  • チームの拡大
  • 新機能の追加
  • リファクタリング
  • パフォーマンスチューニング
  • パッケージのバージョンアップ
  • UIの変更
  • etc
  • 何ヶ月、何年と積み重ねていかねばならない
  • エンジニア3,000人、新卒300人という規模
• 0→1が重要
  • 1→100のために基礎を作るのが重要
  • チームが拡大しても大丈夫か
  • 曖昧なルールは無いか
  • コンフリクトが起きにくいか
  • レビュー時に指摘する点が多くないか
  • 仕様やUIの変更に耐えられるか？
• コンポーネントガイド
  • 規模がでデカくなると、どんなUIが既にあるか分からない
  • チームメンバに必要なUIがあるのか問われる、コミュニケーションコスト
  • サービス画面から見つけ出す？
  • レビュー時の二度手間
  • StorybookやDoczなど手段は様々ある
  • 更新されないガイドは負債になるので注意
  • 一番大事なのは手間にならないこと
• コンポーネント粒度・PrettierとLint
  • 粒度を感覚で決めるのは危険
  • 人によって感覚はバラバラ
  • レビューで指摘するのも危険
  • いつか属人化する
  • Atomic Designの導入
  • Atoms
  • Molecules
  • Organisms
  • Templates
  • Pages
  • 得られること
  • 粒度にルールができる
  • レビューの指針になる
    • これはAtoms
    • これはOrganims
  • 感覚ベースがなくなる
  • 絶対では無い
  • ルールを作る手間を省く手助けをしてくれている
  • ルールを加えたり、新しく考える
  • Prettier
  • コード整形の手助けをしてくれる
  • 人によってコードの書き方は違う
  • 書き方を統一してストレスを減らす
  • Lint
  • ルールに基づく静的検証
    • varを使わない
    • requireを使わない
  • Lintのルールセットは上書きしない
    • ルールは必要だからエラーが起こるようになっている
    • react/jsx-no-target-blank
    • react/no-array-index-key
    • tslint/orderd-imports
    • ルールを上書きしたいときは、リスクもきちんと調べる
• テストとTypeScript
  • Unitテスト、E2Eテストとともに導入したい
  • 導入しないとリファクタリングが不安
  • 仕様は膨らんで行くもの
  • 結合試験がExcel地獄になる
  • なにか変更する度に手動でExcelでテストしたくない
  • Excelに親を殺されたみたいになる
  • コードベースに近づけるほど保守も楽になる
  • Excelは更新されない
  • テストを書くことで得られること
  • 精神的安静
  • コードに対する自信
  • 手動テストのコスト削減
  • コードの見通しが良くなる
    • テストが書きにくいコードは複数の分岐や処理が入っている
    • テストが書きやすいコードは薄くて簡単になるはず
  • 書かないテスト
  • UIに近い部分は変化が激しい
  • TypeScriptでテストを減らす
  • テストをセットにする
    • コードでPropsやDOMを呼び出せていないとエラーになる
    • テストを書く→回す→エラーが分かる→テストを直す、よりも、消耗しない
  • TypeScriptを書くこと自体が1つのテスト
• パッケージ更新
  • 銀河系のようなパッケージ
  • 更新しないといいざというときに困る
  • 依存パッケージにセキュリティの問題
  • サービスを止めない
  • 1年更新してないと1ヶ月以上更新にかかることも
  • 1～2週間に1回更新するなど、短いスパンで更新ルールを決める
• まとめ
  • 1→100の期間は長い
  • この長い期間苦労しないように0→1をよく考える
  • 刷新は解決策ではない
  • 今までの苦労や時間を0にしてしまう
  • ルールを作ってレビューや開発効率を上げていこう！
  • Q. Storybookはメンテしてますか？
  • A. 途中で入れなくなった。Doczを入れて、簡単でもいいからコンポーネントガイドを作る、という流れ。途中からStorybookを入れようとすると、1コンポーネント1000行とかになって無理！となった。
  • Q. 放置され、壊れたコンポーネントガイドはテストしている？
  • A. 会場内）誰もいない
  • A. sakito）Storybookは死んでしまったのでしていない。Doczは…？
  • Q. アクセシビリティの検証や実装？
  • A. Yahoo!のサービスについては……（以降オフレコ）
  • Q. パッケージ更新にツールは使っている？
  • A. sakito）反省点から書いたが、いまは更新中。見事に2年くらい更新していないサービスを更新している。lintエラー多発、テスト落ちる、コンポーネント表示されない、Excel30～40シート、という地獄。良いツールがあったら知りたい
  • A. @teppeis） https://twitter.com/teppeis/status/1043376528187244544
  • Q. 大規模の話、よくわかる。コードレビューがすごく大変。1人で7～8人のコードをレビューしていると自分のタスクを夕方からやる、という状況になってしまう。15人エンジニアがいると、レビューは何人でやるでやる？
  • A. 2人。来期からランダムで。DangerJS勝手にアサインしてくれる
  • Q. コードレビューする2人の間の共通認識は？
  • A. ルールベースで。チーム、プロジェクトのルールは Gitbook? に書いている。2人間の合意を取る
  • Q. E2Eテストは？
  • A. やろうとして死にそうになっている。画面1つに分岐が数百パターンあるので、無理じゃね？となっている。Puppeteerが使えそうかも？
  • A. kyo_ago）操作を録画してそれをテストに自動で落とし込む機能。 E2E にテストを頼るときつい。つらくてだんだん消されていく。
    • E2Eを拡充しすぎるよりも、ロジックを整理してunit testでなんとかする範囲を広げていくべきでは
  • kyo_ago）CM: ブラウザ上でヘッドレスブラウザのコードが動くやつ作った
  • あとでTwitterに投稿します、とのこと
  • https://twitter.com/kyo_ago/status/1043378954235666432
  • Q. Excelがある理由
  • A. 組織的なアレ

15:00-15:30 tweenによるアニメーション - 竹内佑介（書記担当：@lequinharay）

• 自己紹介
  • プログラマー
  • JS大好き
  • three.jsのゲームを趣味で作成
  • 今日はここ↑で得られた知見の話
  • https://github.com/kaidouji85/tween-animation
• アジェンダ
  • tweenとは
  • キーフレームを設定してアニメーションを表現する
  • アニメーションさせるのは、JavaScriptオブジェクト
  • 現状、ブラウザネイティブ実装は存在しないので、基本ライブラリを使うことになる
  • デモ
    • Canvasを動かしてる
    • https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame
    • 60FPSでclearRect(), drawImage()を回し続けてアニメーションさせる
    • https://github.com/tweenjs/tween.js/
    • 「アニメーションを開始してから○秒後なので、この位置にあるべき」みたいなことをやってる
  • tweenライブラリの例
    • gasp
    • https://greensock.com/gsap
    • ライセンスが厳しい
    • tween.js
    • https://github.com/tweenjs/tween.js/
    • シンプルで取り回ししやすい
    • velocity.js
    • http://velocityjs.org/
  • tween vs ブラウザ標準
  • アニメーションのブラウザ標準
    • css
    • cssトランジション
    • cssアニメーション
    • WebAnimationAPI
    • https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API
    • CSSのアニメーションをjsからでも使えるようにしたもの
    • アニメーションのチェインなど、cssで難しかったことが簡単にできる
    • TC39プロポーザルはstage2
      • https://caniuse.com/#search=web%20animation
    • DOM.animate( {…} )
    • CSS だけではつらいアニメーションが書けるようになる
  • tweenじゃないとダメなこと
    • アニメーション機能比較
    • タイムライン、イベント、チェイン × css、web animation api, tweenという軸だと、cssがチェインに弱いくらいの違いしか無い
    • 使える場所の比較
    • css、web animation api
      • html要素のみ
    • tween
      • html要素に加えてcanvasアニメ、WebGLアニメにも使える
      • なんでそうなるのか？
        • canvas、WebGLは要素内を書き換える技術なので、スタイルの適用範囲外（画像の内容をスタイルで変更できないのと同じ）
  • まとめ
    • canvas、WebGLのアニメーションが出来るのはtweenだけ
    • HTML要素のアニメーションでは、状況に応じて好きなものを使えばいい
  • tweenとFPS(Frames Per Second)
  • tween自体にはFPSの概念がない
  • tweenを呼び出している、画面再描画ループのFPSに依存している
  • requestAnimationFrameのFPSは一定であることが保証されていない
    • 通常は60FPSだが、状況次第で60FPS以下になる
  • tweenを使わずにrequestAnimationFrameだけでアニメーションすることは可能だが、これはアンチパターンだと思う
    • pos + 4 / 1frame する、みたいな処理でやる
    • FPSの変更に弱い
    • 表現力が低い
    • 例: 四角形に移動させる: if, switch, 状態変数だらけになって複雑になる
  • tweenはフレームではなく経過時間で移動量を判断しているので、FPSの変化に影響されない
  • 質疑応答
  • Q. WebAnimationAPI
    • A. 全ブラウザベンダは実装したい。Safari は次入る。Chrome はいまいち。WebAnimationのスペックエディターは日本語ペラペラなので、問題あれば日本語でメール書いても通じると思う
  • Q. 実際何に使ってるの？
    • A. threejsを使ってて、そこでアニメーションするために使っている

15:40-16:00 新卒一年目が大規模WEBアプリのE2Eテストに挑戦した話 - Atsumine Kondo(@haidrant)（書記担当：@suzuki）

• 自己紹介
  • 4月から新卒。都内IT企業。バックエンドからフロントまで
• E2E 実装までの経緯
  • Angular + Scalaの大規模B2Bシステム
  • API endpoint 180
  • コード10万行
  • 現在も増加中
• なぜE2E?
  • 大きめの障害が発生
  • 2ヶ月で3回。
  • バックエンドのテストの必要性が薄かった
  • クリティカルな部分はテスト作成済み
  • フロントに品質担保の仕組みがなかった
  • 目視・手動での確認
  • フロントのテストを書く、という思い
  • E2E が良いのでは？と判断
• 実装の手法
  • Puppeteer + Jest
  • スマホエミュレートも可
  • Jest + GUI
  • 後ろに Google + Facebook も強み
  • 書き始めた場所
  • ログイン画面
    • ここからが良いと自信があった
    • 絶対に失敗してはいけない
    • ほとんど変更が発生しない
    • ユーザーストーリーがわかりやすい
  • テストを書いてみて
  • B2B なのでログインにステップがいくつかある
  • ユーザーストーリとして書いた。56行くらい。
  • 書いてみてどうだったか？
  • 最初はつらみが多かった
  • 実行時の環境でテスト結果が変わる
    • re-run で5回中3回落ちるなど
    • session timeout が起きる
    • ネットワークの質でテストの成否が変わるようだ
    • 会社だと成功、自宅だと失敗、など
    • 並列実行の副作用
    • ボタンクリックが前後する
    • パスワード入力で入力値が前後する
  • テストが壊れやすい
    • HTML 構造・CSS の修正でセレクタが動かなくなる
    • UIの変更予定の話を聞くと、「今日この人、僕のテストを壊すんだ。。。」と思う
  • テスト用データが辛い
    • GET 系のテストををどうどうするどうするか？？
    • あらかじめ予めつくっておく？
      • 削除されない保証は？
  • ツールの使い方がわかればまだ辛くない（たぶん）
  • ツラミへの対処
  • 実行時の環境の問題
    • waitUntil に networkidel2 か networkidle0 を指定
    • ボタンクリック前後に delay を入れる
  • テストが狂いやすい
    • セレクタ系はひとつのファイルに纏めて一元管理
  • 最後に
  • 実装コストが高い
    • コツを掴むまでつらい
    • テストケースが壊れる
    • 安心か？それよりもテストが壊されて不安
  • 最初は他のテストを検討したほうが良いかも
    • ユニットテスト、スナップショットが良いのかも
  • Q. セレクタは data-test-idを使ったりしてない?
  • A. テストを書きやすくするためのコードを書いていっればつらさは軽減
  • Q. Puppetier は生で？
  • A. Yes
  • Q. 他のフレームワーク
  • A. Karma
  • A. protractorをすててpuppetierにしした
  • Q. wait が必要なときは、元の
  • Q. CI が終わらないを調べてみたら、ほとほとんどほとんどが wait だった
  • Q. puppetierでテストを書いていて、select boxの選択に遅延があるり、waitをたくさん入れないといけなくなりません？
  • A. 長くなっている。ぼボタンクリックだけで30秒かかるとか。。うまい書き方があるようなきはしような気はしているが、まだできていない。
  • Q. PageObjectPatternとかE2E のテストでちゃんと設計してコードを書いている人は？
  • A. （会場何人か挙手）テスト時にはこう動くというコードを実コードに入れてしまって良いのでは？？
  • Q. そもそもやろうとしているテストはE2Eテストでやるべきなのか、という議論
  • A. 検討によってはその部分はE2Eしなくていいのでは、はありそう
  • A. 準備が長い上にペイしない
  • A. Selenium でもつらい。テスト用のデータを用意。環境を切り替えるとか。ブラウザで動かす安心感があるのは分かる。
  • Q. バックエンドのでーたデータを作ることフロントが保証するものではない
  • Q. チームの人に壊される話があったが、チーム内ではどういう扱い？
  • A. 個人で書いている。他の人にはまだ展開できていない。
  • Q. チーム化しないと。意識高いひとが疲弊してしまう。チームの文化にするべきでは？ E2E でやるべきか？はちーむチーム内のコンセンサスを取るのが良いのでは？
  • A. やっていきたい。やっていく。
  • Q.テストしている環境はどこ
  • A. テスト環境へ向けている
  • Q. クロスブラウザは？
  • A. まだ
  • Q. やるとしたらやるとしたら？ Selenium or TestCafeくらいしかなさそう
  • Q. クロスブラウザで E2E してるしてるひとは？
  • A. やめた。最初は IE もがんばった Selenium で。実際は Chrome で動かして、IE でもできるよ的な状態。IE の実行おそい遅い。やめた。たまに動かないテストが出てくる。クロスブラウザはそれなりに大変。
  • Q. 本当に大変なのはSafari
    • A. どれくらい需要があるかは疑問だが……

16:00-16:30 Vue+Nuxt+Serverlessの開発で得た知見（主につらみ） - Yuki Terashima @y_temp4)（書記担当：@448jp）

• https://speakerdeck.com/y_temp4/jser-dot-info-400th-memorial-event
• 自己紹介
  • ALIS Co., Ltd.
  • 4月から東京に来た新卒
• About ALIS
  • いいね！にトークンによってインセンティブを与える
• フロントエンド開発における知見
  • Vue / Nuxt / Serverless (AWS Lamda)
  • Atomic Design
  • CSS Grid Layout
  • Vuex
  • Cognito
• ALIS初期開発スケジュール
  • ～2018年1月中旬：設計
  • 2018/4/23：クローズドβ版リリース
  • とにかく時間が無かった
• Nuxtを選定してよかったこと
  • 開発速度が保てた
  • 規約があり、設計で迷いにくい
  • 便利機能が本当に便利
  • SSR
  • ルーティング
• Vueの生産性が高かった
  • 初めてでもか書き始めやすい
  • ドキュメントが充実
• Nuxt on Lambda
  • ALISのNuxtはLambda上に乗っている
  • mya-ake/nuxt-on-lambdaが非常に参考になった
  • 他に必要な設定はserverless.ymlくらい
  • デプロイはyarn buildしてsls deployするだけ
• ALISのサーバーサイド構成図
  • https://alis.to/AB2/articles/KBXeJ1VgwzNB
• Atomic Design
  • よかったこと
  • 記事コンポーネント
    • Vueの単一ファイルコンポーネントによって作成
  • コンポーネントの責務を意識して開発
    • 再利用性があるかどうか、など
  • BEMとか使う必要がない
    • 個人的にあまりBEMを書きたくなかった
    • セレクタの詳細度が平坦に近づくため
  • 参考: https://blog.kubosho.com/entry/using-atomic-design/
  • 良くなかったこと
  • スピードが求められるとなんちゃってAtom Designになる
    • 大きすぎるAtom
    • 切り分けられていないコンポーネント
  • ディレクトリ構成だけ切ってあとでキレイにする、でいい気がする
• CSS Grid Layout
  • https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout
  • 記事一覧ページの例
  • よかったこと
  • 複雑なレイアウトにも比較的簡単に対応
  • grid-areaによる名前付けでレイアウトがイメージしやすい
  • 想定よりも学習コストが低い
  • 学び
  • 無駄にGrid Layoutで実装してしまった部分があった
    • コンポーネントの粒度によってはflexboxのほうが効果的
    • 使い分けが大切
  • 可変の値を駆使した方が良い部分があった
    • px指定をガチガチにやってしまった部分など
    • auto、frなど
• Vuex
  • https://vuex.vuejs.org/
  • よかったこと
  • データの管理がしやすい
    • バケツリレー不要
  • そこまで厳格に書く必要がない
    • 必要に応じてVueの双方向バインディングに対応
  • つらみ
  • 型
    • 実装当初に検討したが、いろいろとつらそうだったのでやめた
    • 人数が増えてきたときに心配、できれば導入したいがベストプラクティスが無い
  • 複雑なAction
    • 1つのActionが大きくなりすぎる
    • 非同期処理＋データの保存でどうしても肥大化しがち
    • ベストプラクティスが無い
  • 巨大なModule
    • 700行over
    • さすがに分割したい
• Cognito
  • https://aws.amazon.com/jp/cognito/
  • つらみ
  • 提供されているnpm packageがやや使いにくい
    • Promiseを返してほしい…！
  • 融通が効かない
    • 最初に気合いを入れて設計する必要がある
• まとめ
  • Nuxtについて
  • （何度も言われているが）ふつうに使った方がいい
  • SSRしなくてもメリットは大きい
  • Serverlessについて
  • 運用負荷が減るのは大きい
  • ただし設計の難易度が高い
  • Atomic Design / CSS Grid Layoutについて
  • Atomic Designはともかく、CSS Grid Layoutは採用例をあまり聞かない
  • 対応ブラウザにもよるが、ふつうに便利
  • Vuex
  • 型との相性の悪さが絶望的
  • Cognito
  • 使うなら覚悟して使った方がよさそう？
• さいごに
  • ALISはオープンソースなので、ぜひ見てみてください！
  • github.com/AlisProject
• Q. Vueで型を使ってる人は？
  • A. TypeScript で書いた。型を無視すると書けるよ。
  • A. テストで担保していくほうが。。。
• Q. BEM が不要との話、scopedに閉じているとはいえ複数人開発での style のぶれはどうしている？
  • A. とくにスタイルルールは作っていない。
  • Q. ルールは作ったほうがよいと考えているがどうか？
  • A. そうかも
  • Q. BEM を使っている人？
  • A. （会場）そこそこ多いひとが挙手
• Q. vue-cli/nuxtの使い分けについて
  • A. ……
• Q. nuxt を使っている人は？
  • A. （会場）10数人
• Q. Vue CLI を使っている人は？
  • A. （会場） 3名（potate4dら）

16:30-17:00 2018年秋のJavaScriptエンジニアの投資状況 - HANATANI Takuma@potato4d（書記担当：@lequinharay）

• https://speakerdeck.com/potato4d/2018nian-qiu-javascriptenziniafalseji-shu-tou-zi-zhuang-kuang-number-jserinfo
• 自己紹介
  • フリーランスエンジニア
  • フロントエンド
    • react, vue&nuxt
  • バックエンド
    • php, node(サーバーレスが多い)
  • インフラ
    • クラウド(AWS)限定でサーバーレス周りも
  • 職務領域
  • 請負、準委任
  • 課外活動
  • vue日本語ドキュメントメンテナ
  • やってること
  • フロントエンド6割、サーバーサイド1割クラウド25%
  • フロントエンド内では
    • vue/nuxtが7割
  • バックエンド
    • 半分以上サーバーレス
  • https://www.amazon.co.jp/dp/4863542569
• 個人的な2018年秋現在の技術投資状況
  • Nuxt.jsについてのリザルト
  • 昨年夏に現場への初投入に成功（まだver1にもなってないころ）
    • 現在20プロジェクトくらいで実運用
  • コアに少しだけ貢献・ドキュメントメンテナ
  • ウェブでの発信
    • Qiita Vue/Nuxtタグ日本一
  • 案件はほぼすべてvue→nuxt
    • 数倍パフォーマンスが出る
  • Nuxt の第一人者として呼ばれたりも
  • Serverless
  • 現場投入は昨年夏から
    • webサービスバックエンド、ソシャゲキャンペーンサイトAPI
  • 技術
    • AWS/ GCP & Firebase functionsを利用
    • 業務委託先のひとつALISではnuxt on lambda & serverless python
  • ↓この辺はよかった
    • nuxt+firebase
    • serverless universal application
  • ベーシックなサーバーレスは参入が遅かった
    • その分新規のつまみ食いは最優先
  • 残り三ヶ月は趣味に
  • 「出来ることが広がらないものはやらない」を基準に進める
  • firebase はfirestore tokyoが来るとweb向けが化けそう
  • dart/flutterも興味で触っている
• BETする技術のちょっと変わった基準
  • なんのために技術にBETするのか
  • 自明な新技術キャッチアップのきっかけ
    • 技術的な興味のみ→やれば良い
    • 今の仕事で必要→やれば良い
  • 「これから来そう、楽しそう」でbet出来ると価値になりやすい
  • 投機的BETの対象は？？
  • 1.5歩先で生活し続けること
  • 「これ来そう」の仕組み
    • 今のまま仕事をしていても相対的に価値は下がる
    • 大胆に舵を切りすぎても時代がついてこない
    • 知見は血肉になるが、博打感つよい
    • 今の仕事ももちろん楽したい
    • 今ある要素（＋その最前線）+近い未来の課題=将来BETしたくなる
    • 最前線: 0.5歩分
    • 近い未来の課題: 1歩分
  • 1.5歩はわかりやすい
    • nuxt
    • vue.js←伸びている
      • vueだけだと秩序のなさがつらみ……
    • スケールする開発←これからありそう
      • 開発効率や秩序をもたらす
  • 1.5歩はプレゼンスを忘れられる
    • 1.5歩に位置していると自動的についてくる
    • 貢献する意志があれば先行者利益はそれなりについてくる
      • ドキュメントかいたりとかしておけば、他の人が進んできた時にメリットを得られる
    • 逆に、貢献する意志がないと旨味がない
      • アウトプットが得意なら、淡々とアウトプットしていくだけ
    • 半歩先からでも有効なアウトプット
    • vuesax
      • 息が長そうでもないが、vueではelementが独占なので試験利用
      • Qiitaにエントリを書いたら、作者からリアクションもらった
    • エンジニアらしいアウトプットを心がける
      • 当たり前のことは煽らない
• 総括
  • 個人的状況
  • nuxt/さーばーサーバーレス
    • 成果はよかった
  • 残り3ヶ月
  • nuxtとサーバーレス様子見
  • 投資基準
  • やるべきこと、純粋にやりたいことはやる
  • それ以外は全体の空気感をみて
  • 1.5歩先
  • 1歩先は追いつかれるが、1.5歩先は結構有効
  • 半歩先でもいいのでアウトプットを適切に行うといい感じ
• 質疑応答
  • Q. 今の時点から1.5歩先で注目しているものは何でしょうか。Flutter?
  • A. 悩んでいる。nuxtが近くなってしまっている。継続注視はサーバーレスの新規プレイヤー。出来るだけ早くキャッチアップしていきたい。フロントエンドは面白そうではあるけど、現状の延長線上っぽいのでそこまででもない
  • Q. サーバーレスってのはlambdaとかだけではなく、firebaseとかも含めていろいろ増えるってこと？
  • A. そうですね。awsは根っこのサービスから統合的なサービスを出してくる。このときにキャッチアップできるようにしておく

17:20-18:30 JavaScript Discussion（書記担当：全員）

• https://app2.sli.do/event/wjfqikyd/questions
• Q. いま一番いけてるテストツールってなんですか(mocha, ava, jest...)
  • 会場アンケート：
  • mocha（10人ちょっと）、
  • ava（5人くらい）
  • jest （20人くらい）
  • グローバルにはmocha>jest>>avaとかかな？
  • Qunit
  • 2,3ヶ月に一度は更新されてる。

Q. wasmが流行るかもしれない未来にjsはどのように使われると予想されるか？

• A. やっている人？ 会場数人
• 速度がシビアに求められる時に必要そう。ゲームとか
• 暗号系のAPIが同期で使える
• 64bit Int の計算が BigInt 使わずにできる
• wasm の次のカスタマーがどこか？
  • 何が実装されていくか？
• WebWorker のなかで wasm を動かすのはどうなの？
  • すじはわるくないのでは？
  • Q. flowtypeって終わりましたか？
• A. 終ったの定義は？ はじまったのか？ 会社で使っているところはある AirBnB とか
• 渋谷の某社はやめようとしている
  • バージョンアップで激しい破壊的変更 がある。更新についていくのが大変
  • TypeScript のほうが BC がゆるやか
  • Facebook が使っているような巨大なスケールのコードに後付で型チェックをつける用途には flowtype はとても良い
  • flowtype が遅くとも Facebook は力技で解決
• flowtypeの方が表現できる型のは範囲は広い
• 型の表現力
  • どちらでもよい
  • いけてないところ
    • サードパーティライブラリの型が圧倒的に少ない（flowtype）
    • TypeScript が圧勝
• React は脱 fbjs
• 「漸進的な型」というコンセプトは他でも使えるようになってきた
• flowtypeは、lintを自前でもってるのが良い
  • TSLintはイケてないのでつらい……
• GitHubがjQueryを止めた話の中でFlowのweakモードを使っている
  • https://githubengineering.com/removing-jquery-from-github-frontend/
  • Q. Web Componentsについてのみなさんの所感を知りたい
• 使って作っている人？
  • addon
  • それぞれのコンポーネントがライブラリ持ったらどうなるの？問題は解決したのか？
    • 問題になるほどに使われていないのでは
    • サードパーティのコンポーネントを使う方法が広まっていないのでは？
• 使っているひとがまだ少ないのでは。
  • Q. PWA対応してますか？
• 範囲は？
• WebPush は？
  • けっこういる
• Push で辛かったことは？
  • 小さくやっている。大量時はどうなるのかはまだ分からない。不安。
• 大量配信をしているひとは？
  • push7
  • けっこう難しい
  • Firebase とかない時代からやっている
  • なにかミスったときにイベントが RFC にはあるが、実装が進んでいない
    • リカバリーできない
  • 膨大な数を送ると漏れができる
  • テストがしにくい
    • 頑張って検証するしかない
• app shell パターン？
  • 知っている人？
    • あまりいない
  • これ？ https://developers.google.com/web/fundamentals/architecture/app-shell?hl=ja
  • Q. Lintツールは何を使ってますか？使っている場合、CIに組み込んでますか？それともpre-commitフックとかで実行してますか？
• CI で Lint を回している人？
  • そこそこいる
• Git Hook を使って Lint を使っている人？
  • そこそこいる
• git hook だと rebase 時などに辛くないか？
  • 開発者体験としてはうーんという気持ち
  • pre-commit hook は全般的につらいという気持ち
  • Q. 10年後のWebフロントエンドはどうなってると思いますか
• 想像するの無理では？
• Web replay？
  • すべて再生される？
  • ブラウザを操作したら記録して戻せる
    • 通信も
  • デバッグ用機能
    • Firefox nightly が Mac でなら動く
  • Safari, Edge もあるらしい
    • Edge: Visual Studio と連携？
  • Q. css-in-jsはなにを使ってる？
• 使っている人は？
  • あまりいない
• 何を使っているか？
  • webpack 標準の。
    • いかにだめなのか？というスライドをを持っている
  • emotion を使っている
  • paypal のやつは？
  • Q. GraphQLの現時点での総括を
• 製品開発してる人！
  • ミューテーションが大変
    • 画像アップロードを分ける必要がある
    • 結局 REST が必要
  • 参照系は比較的ラク
    • 良いのでは？という感想
  • フロントエンドに都合の良い形で持ってくれたのがよかった
• applo? を使ってますか？
  • デファクトですか？
  • d?? はメンテが追いついていない
    • 荒れ気味かも
  • vue なら applo? 一択だと思う
  • Q. UIコンポーネントのスナップショットテストって皆さんやってますか？どの様に？コストと効果のバランスは？
• Jest / ava?
• やっているひとは？
  • 2名ほど
• これで担保できるものは何か？見つかったバグは？
  • あんまない。コスパもそんな良くない
  • やる必要あるのかな？という気持ち
  • メリットはテストと StoryBook がセットになっている
  • コンフリクト解決が面倒くさい
  • 不要な変更を避けられる
    • 修正が入っていないのに変わってしまったことの検知ができたのは良かった
• 画像比較のテスト
  • React render() 内の分岐をテストができたのは良かった
  • SSR でどのような HTML が出力されるのかの比較がやりやすかった
  • JSON の比較もやりやすかった
• UI の見た目でのスナップショットテストは難しい
  • コスパとか
  • Q. SPAが思ったほど流行ってないようですが、どうでしょうか？
  • Q. 楽しみなProposalは何ですか？
• Web replay
• STD library
• Layered APIs
• azu さんが気になっているのは？
  • 特にない
  • Q. npm, yarn どっち使ってる？理由は？
• yarn
  • 半分くらい
• npm
  • 全員つかってるでしょw
• npm の lock が相変わらず壊れていると感じている
• yarn を捨てた理由
  • lock ファイル
    • git ssh の参照にバグがある
    • lock.json を手で直す必要があった
    • issue が放置
• yarn の lock ファイルが diff で比較しやすい
  • 編集もしやすい
  • （手で編集するのはどうかという話はあり）
  • Q. フレームワークなどの技術選定の仕方
• 最近技術選定をしたひとは？
  • 人数が多い、会社のセキュリティ、OSS ライセンスなどいろいろある
  • React を選択
    • Angular / Vue より簡単に書ける
  • TypeScript を使いたい場合
  • GitHub の start 数を見る
  • issueが長期間放置されていないか？
  • 背景に会社がいるか？収益化ししているか？
• どの技術が良いか？もあるか、チーム・会社に合っているか？という視点も必要
  • Q. npmパッケージのセキュリティ、脆弱性対応どうしてるか。GitHubのセキュリティアラートがReDOSばかりでウザすぎる問題
• 社内でセキュリティアラートの CI を回している人は？
  • いない
• npm audit をを CI で？
  • いない
• セキュリティチームが構成管理・脆弱性を扱っている
  • npm はパッケージ数が多い
    • ReDOS
  • 実は build 時に npm/node を使っているだけでしたというパターン
• audit をやったらアラートが出てきた
  • よく調べたら gulp の古いバージョンに依存
  • gulp を消したらアラートも消えた
• yarn upgrade を続けておくと割とアラートに合わなくなる
  • 更新は適切に。
  • Q. SPAが思ったほど流行ってないようですが、どうでしょうか？
• 名乗っていないが実は使っているところは多いのかも？
• サーバサイドで HTML レンダーしているほうが多い印象がある
• アプリの種類によるのでは？
• 企業内システムの管理画面だと SPA が楽という話もある
  • SSR が必要とか言わない
  • 時々リロードしてもらう
• むかしは Angular(1) で最近は Vue が多い印象
  • Q. 型システム(TS,flow)入れると、コンパイル遅い・コード量が増えるなどの欠点も発生するが、利点とのトレードオフをどう考えるか？
• 欠点と思ったことがない
• 結局 JS でも build するし
• 欠点だと思っている人は？（時間かかっている）
  • Angular6 / 17万行 / 初回ビルド10秒 差分ビルド2秒
    • 遅いとは思っていない
    • uglify入れると遅くなる
  • Scalar.js
    • ビルドが遅いという話は聞かない
• 利点
  • IDE で型チェックをしてもらえる
    • ここがでかい
    • 普通のエディタだと、このメリットが見えにくくなり、遅いところだけ浮かんできてしまう
  • リファクタもしやすい
  • 利点が大きければ欠点は小さくなる
  • Q. かつてのBackbone.jsのような全部入りフレームワーク(View,State,Router)が必要とされているのではないか？
• Backbone ではなく Angular では？
• Vue はひととおり持っている
• 機能で選択できるのも良いのでは？
• Ember は全部入り
  • Q. I18nどうやってますか？
• i18n やっているひとは？
  • 違う文脈で同じ単語が出てくるときが辛い
  • コードレベルで切り替えるものは工夫が必要
  • 語順が逆になるパターン（人名、通貨表示の位置、カンマの位置）
• 多言語ファイルを SIer が管理
  • JSON で送られてくる（使いにくい）
  • 多言語用のJSクラスを作成
    • 表示順番などはクラス内に記述
  • テンプレートに他言語用のコード
• フレーズアップ
  • エンジニアも更新
  • 言語ファイルを落としてきて組み込み
  • View と翻訳単位をどう結びつけるかが課題
    • このメッセージはどこから来ているの？が見えにくい
• 言語ファイルとアプリケーションのバンドルは？別？全部？
  • A3. 全部入れてる
    • 容量的な問題で迷っているところもある
  • むかしは分けていた
    • わりとつらい
    • 一緒にしてもそこまで大きくなかった
  • 翻訳ファイルは全画面で1ファイル
  • Q. 新しい動向の情報を、主にどこで収集していますか？
• JSer.info と答えるのがこのミートアップの意義w
  • Q. 利用ライブラリの著作権表示はどこに書いてる方が多いのでしょうか
• Web アプリ・サイトで著作権表示をしているひとは？
  • いない
• アプリケーション画面から著作権表示に遷移しているひとは？
  • いない
• JS のコメントに入れている
• Dropbox Paper は PDF ダウンロードできる
• ライセンス一覧をまとめてサイトに公開するのは現実的？
  • 子ライブラリとか孫ライブラリとかどうするの？
• Facebook が表示しているライセンスは偉い
  • 自社のライブラリしか使っていないから記述が楽なはず
  • Q. monorepoやってる？何使ってる？
• やっているひと？
  • yarn workspace
• なんでもそこに入れると破綻
  • チーム・触る人でまとめるべき
    • 組織論につながる
  • Q. Accessibility対応どうする？（やってる？どう進める？社内の方針は？）
• どうやってすすめるか？
  • エンジニアを大事にするw
    • 難しいという話が先行している
    • 大事にすればやってくれるのでは
  • Q. サイトの速度って測ってますか？
• 自動化（定期実行）している人は？
  • あまりいない
• スピードカーブ
  • 大規模リニューアルのときに効果計測できる
  • 機能リリースをした後で影響が出たことを検知できる
• サイトが変わってなくてもブラウザ側の変更でスピードが変わる場合もある
• 『超速!Webページ速度改善ガイド』? 読んどこう
  • Q. ECMAScriptはどこまで機能が増えるのか、増やすべきかhttps://github.com/tc39/proposals
• 人が望むから増えます
• 増えすぎて困る
  • Q. SEOどうしてますか？
• （質問として難しいのでパス）
  • Q. コンポーネントのUIテストってどうしてます？
• （既に話があったのでスキップ）
  • Q. Dockerの話がちらっと出ましたが皆さん使っていますか（自分は好きではないです）
• 会場は何人か使っている
  • Q. NodeのES Modulesはいつになったら固まるのか https://github.com/nodejs/modules
• 1日で終わらない話題。。。
  • Q. ESLintがドキュメントやプロジェクトのガバナンスが素晴らしいのに対して、TSLintが酷すぎる。TypeScriptではTSLint使うしかない？
• TSLint 以外を使っている？
  • ESLint のTS対応は貧弱だった
• eslint-babel はモンキーパッチが多い
• TSLint のプロジェクトがよく分からない
  • リーダーだれ？とか
  • ESLint ほどプロジェクト化が進んでいない気配
  • Q. Proposalで言うと、proposal-pattern-matchingが来て欲しくないですか？皆さんの所感が気になります
• 来るといいですね
  • Q. Reactって日本ではあまり広まっていなような気がしていますが(エッジな企業が導入したけど) 、どうなんでしょうか？
• 普通に使われているような。
• Chrome extension で React バージョンを見られる
  • 15だと古いと出る
  • Q. Servoって今どんな感じですか？
• 最近追ってない
• WebXR のエンジンとして使っている
  • XR 実装に使っている

懇談会でいくつかほかにもLTがありました。

懇親会でLTしました会場にいたもう一人の方です。その場でつくったとてもライトニングな資料になりますが、上げておきます https://t.co/0nJWluapHY #jserinfo

— clngn (@clngn) September 22, 2018