ng-conf 2017 Feedback

ng-conf2017-2.md

Sharing is Caring… At Scale!

Sarah Saltrick Meyer

Sarah Saltirick Meyer frontend engineerです。
Buzzfeedで働いてます。
python, js を使ってます。
ときにはコードシェアしたくなるよね
え？なんで？
社外の開発者にコードを渡したい、クライアントサイドアプリをいくつも開発したい、フロントエンドは幾つものアプリに分けられているが統一した体験が必要
フロントエンドのコードを簡単に再利用したい
そういうときには！コンポーネントライブラリーだ！！！！
component library はデザイナーと開発者のチームを纏める機会になる。
BuzzFeedについてですが Website ですね
またはユーザーインタフェースをコンポーネントで作ると作りやすい
ちょっとBuzzFeedの話をしますね。
モノリスなPHPでできたウェブアプリから
CMSはいつも一番遅れています。
マイクロサービスへのへswitch しています。
700行のswitch caseがあるテンプレートとかいじりたくない
フロントエンドをモノリスのアプリから数々のアプリに分割している。
BuzfeedはCSSのスタイルガイドを公開してる
社内CSSスタイルガイドも持っている。フロントエンド同士のコードシェアをするために。
buzzfeed の style guide を公開しています。 Solid https://solid.buzzfeed.com/
使うとすぐに似たようなlook&feelになる
モノリシックから472のマイクロサービスへ
Buzzfeedはmono repo
コンテナ化の良いソリューションもあります。Dockerも良い。単一の環境を開発者に提供できるようになりました。新しいサービスを設定ファイルを書くだけですぐデプロイできるようにした。
これは私がやったプロジェクトではないが、同僚のblogpostを参照してください。
https://tech.buzzfeed.com/deploy-with-haste-the-story-of-rig-ca9a58b5719a
Googleした結果がこちらです
これはコンポーネントでも有り、カードでもある。
異なった要素に共通点が見えると思います。これがコンポーネントで、ここにあるのもコンポーネントで、ここのボタンもコンポーネントですね
コンポーネント間に統一感がありますね。
しかしクリックしたら、違うアプリに飛びました
ページを集めて表示するところは一つのアプリ、それぞれの記事も一つのアプリ
いろんな理由があります。assetの量が違います。インタラクティブなページとそうでないのもあります
しかし違うアプリでも同じコンポーネントがあります
最初は複数のアプリでコードをコピペしていました
一箇所でバグを直しても他のところはバグったままだった
もっと違うのが必要でした
コンポーネントライブラリを作っていました。最初は技術がそのものがなかった。その次には他の開発者の味方がいなかった。
コンポーネントライブラリ3回も作ってる、最後のやつでやっと成功した
Buzzfeedもコンポーネントライブラリを作ろうと長く試みてきました。
ワッフルという。失敗。誰も使わなかった
なんでや
モノリシックだったから
ただインポートすればよかった
教訓は、新しい技術を広めるにはタイミングの問題があるということです
Good code is not enough
BuuzBlocks というソリューション。社内のコードネームはBuzzがよくついてる。
BuzzBlocks を開くとこれらのフォルダが見えます。GitHubのリポを開くとこのフォルダツリーがみえます
components, docs, fonts, img, js. scss, snippets みたいな内容のフォルダが入ってる。
fonts are for fonts to share
js: js utilities, like internal npm
scss: scss
snippets: small html files for polyfill and scripts
スニペットは小さなスクリプトとHTMLのタグだけです。全体のJS環境に不要なものが置かれます。
最初にコンポーネントの定義を説明します
Here’s a YAML file
you know YAML right?
File formats don’t matter much, json is also accepted
これらは情報の例です。コンポーネントを使いたい人はこのファイルを見るとAPIのシグネチャがわかります
コンポーネントはクライアントとサーバ両方で使えるようにする必要がある
こららの引数は表示するためのDOM要素と、テンプレートです
これがAPIで、compactのboolと(…)をとります
気づいてるかもしれないけどフレームワークについてはまだ話していません
buzzfeedはt3という小さなフレームワークを使っている。これは小さいということ以外はあまり取り柄がない（笑
http://t3js.org/docs/

これはテンプレートの例です
ジンジャーのテンプレートです。ここに示すようにHTMLにデータをいれることができます

{%if not compact %}
  <p>Let us know what you think</p>
{%endif %}

Buzzfeedの場合は様々なフロントエンドアプリの間でコンポーネントを共有する必要があります。 BuzzBlocksをつかってコンポーネントライブラリを共有することができる、なんで共有するのかを考えるのはどうやって使ってもらうかを考えるのと同様である
JackとArtyomはフロントエンドインフラストラクチャのチームです。
ギャラリーを作ってくれたのが一番の成功だった
リポにあるすべてのコンポーネントはギャラリーに表示されます。バグがない限り。
ここではyamlファイルの定義がそのままギャラリーに変換されて表示されます
設定の例も合わせて示されます
ページをみてバグってたらすぐに誰かが気づく
こんなコンポーネントがあったんだと気づける
ドキュメンテーションがないとだめ
BuzzBlocks は結構複雑なので、かなりのドキュメントが用意されています。
Documentation is your only hope
今回おみせしたのはほんの一部ですが、実際に使うには結構複雑なことを知る必要があります。
だからドキュメントが必要
BuzzBlocksのドキュメンテーションは readme, contributing, usage, naming, faq にわけられてます。
コントリビューションの仕方とか命名規則とか色々docが用意されている
CSには難しい問題は二つしか無いというジョークがあるといわれていて、キャッシュの無効化と名前付けです。
ツッコミは、off-by-oneとか日付とかもあるやんーというやつです
readme => 説明しなくてもわかりますよね 🙂 説明書です
contributing => 貢献方法
usage => 利用例
naming => 名前付け
faq => frequently asked question
ローカルファイルシステムにあるコードを使いたい時はconfigを設定することで簡単にできる
Buzzfeedのサービスは簡単に始められる
開発者の楽しさは大事
Semverを採用している。
自分たちはそれの専門家じゃないから外にある概念をそのままもってきた
BuzzBlocksはnpmで提供されている
BuzzBlockに関するコミットはどれもテスト成功したら webhook で npm packageになると。
自分でnpm publishをしないといけなかったけど自動化された

信頼貯金という言葉がある、みんなライブラリが壊れたりしたらそういうライブラリは信用が消えてしまってなくなる。
バグがあったら使ってもらえなくなる -> 信用貯金
正直なところ他の人のクソなアプリを壊すことはあるが、常に壊したいわけではない
ソフトウェアってバグばかりでしょ？
壊れるのが普通
unit testを書くしかない
BuzzBlocksはユニットテストが必須
CSSの見た目の退行テストもやっています

機能面：unit test,
マークアップ：snapshot test,
CSS： headless chromeでテスト（登壇者が首なしchromeって翻訳してたｗ

SlackチャンネルでChatするのはとても重要みたいになっていて、どうやってやったらいい？とかのヘルプも聞ける。
開発者は編集したコードがどこで使われているか知りたい -> 今はgrepで探している
開発者が使っているかどうかだけが成功を図る手段
今のところ自動的にコンポーネントがどこで使われているかを調べる方法はないので、自動化したい
component libraryはプロダクトではなくプロセスです
BuzzBlocks はプロセスであり、進化し続ける。BuzzBlocks はフロントエンド開発者のための変わり続け、終わりはない
単なるプロダクトではなく、手順として定期的にお互いを手助けできるようになっていれば進化は止まらない
社内オープンソースライブラリーのコミュニティーマネージャ
99%が人間とかコミュニケーションの問題
OSSライブラリーのメンテナンスは楽しいけれど楽じゃない、 people problemのほうが9割
技術的な問題は特に無かった。 BuzzBlocksをやってて技術的に何が問題だった？と聞いた
ぼーっと考えてた。そんなの頭にもなかったらしい
BuzzBlocks結構良いけど、まだ満足してない。
Emilyはフロントインフラチームでデザイナーをしている。デザインはインフラの一部
統一された見た目があるのはかわいい
BuzzBlocksを開発ソリューションからデザインシステムにしたいと思っている
デザイナがリードをするシステム
デザイナの皆さんはこの考え方に慣れていない
photoshopとかで大きなmockupを作るのが普通
elementから考えるのはnomalではない。だからそれを助けるのが開発者の役目
開発者は人間とcomputerの間にたつ通訳者
BuzzBlocksはデザイナーに、より柔軟な新しいデザインのツールを与えるのが仕事
技術の問題は拡大解釈すればpeople problemになる。
（at scale ってこういうことか）

このセクションはかなり学びが多いので読み返した方がいい

data sketches: A Visualization a Month

Shirley Wu

子供の頃6年ほどつくばに日本ですんでて、日本にこれてうれしいです
データ可視化について話します。特にdata sketchesについて
2015秋くらいからビジュアライゼーションしてます
Data visualization にであったのは2015/10、 OpenVis Conf 2016
Open Vis Conf で Data Sketches プロジェクトに関するコラボレーションで発表し、それからずっとData Visualizationに関する活動を続けている

Q.データが先でアイデアが浮かぶのか、アイデア先でデータをあつめるのか？
A. いつでもアイデアが先です

http://www.datasketch.es/

友達が、「ビデオの顔検出から感情を判別できたらクールだよね」と言ったのがきっかけで、ビデオを集めてた
Youtubeから動画を取ってきて、ffmpegでスクショとって、googleのAPIで感情のデータを取得して……
youtube を収集し、解析したあとでGoogle Cloud Vision APIを使って表情解析にかける

DDR は毎日やってた。
DDR（ゲーム）の曲の可視化
ドットの色が矢印の方向で、曲が進むに従い中央から外にひろがっていく
DDRの曲の難易度、BPM，などのデータが必要
DDRのデータセットを使って解析するのはかなり大変だった
足譜がすでにddr freakに用意されていた
ただ画像だったので、解析しようかと思っていたけど、そのかわりにメールをしたらいいのではと思ってメールした
かなりほめたけど返事くれるか自信がなかった。ところが17分したらzipファイルで一式送ってくれた
それをparseするscriptを書いて解析できるようにした
可視化の一番大事なのは興味のある分野を選ぶこと。モチベーションになる。過程は難しいが、終わらせる熱意になる。
常に好奇心旺盛でいよう、貪欲にデータ集めよう
データを集めるにはいろんな方法がある。サイトオーナーにメールしてもいいし、スクレイパーを書いてもいい。考えられるすべての方法を貯めそう。ただし法律は守る
旅行中に自分で撮影した4万の画像を分析した
代表的な色を表示した
自然が好きで、滝、山、などの青はすごく納得した
赤とかオレンジの写真があるのが不思議だったが、食べ物だった
全部食べ物の写真だった（笑 これはアイスランド2015年の写真で、とてもアイスランドっぽい
滝、自然
このプロジェクトはスムーズには進まなかった
最初アイデアをスケッチしていた。どんなパターンや傾向が自分の写真にあるか昼夜考えていた
徐々にどの特性を使うかなどをまとめていった
その後スケッチからコードに置き換える時は、ほぼ一対一で行えてスムーズだった
時々データセットがとても大きく、手で調べてデータを理解するのが難しいことがある
グーグルNewslabで、2004年までのサーチデータを遡って調べたことがある
旅行に関しての検索で、どの国でどんなことが調べられているのかをみた
逆に日本が調べていること。白馬、ニセコ、フランスのリヨンなど。
一番調べてられている国はどこかと調べたかった
ブラジルだった
どこの国がブラジルを調べているのか、どんな内容について調べているのか、一年の間ではどんなふうか、を調べた
その興味を分類してbinにして表示した
それぞれの分野について大きさや色を変えて表示してみた
例えば近い国同士や遠い国で傾向が変わるかをしらべた
ヒートマップ（成功してない）。あまり興味深い傾向がなく、ストーリーを描けなかった
季節変化については面白い傾向が見えてきた。
そしてスケッチを描いてコーディングして、失敗
年中通して同じことを検索してた
春に休みについての検索が増えていた
なぜかというと合衆国では夏休みがあり、秋に学校が始まるから
何回もいったりきたりして、スケッチしてコードを書いて、何が動いて何がだめかというのを学んでいくのが大事だし、それでいい
これもお気に入りのプロジェクト
夏のブロックバスター映画について
色はジャンルなど
1997バットマンとロビンがとてもお気に入りで、めっちゃ小さい
花をかくのは意外と簡単で、SVGとキュービックベジェ曲線があれば花がだせる
説明します
0,0 から紫のエンドポイントまで線をかき、アンカーポイントを２つとる
それからほしい曲線になるまで引っ張る
そして2本線を追加し、反対側にも線をかき
回転させる
もっかいやる
ありがとう
そして色をつける。それだけ
シンプルで単純
ツールセットを理解しよう、というのが教訓
svgとcanvasをきちんと理解するのが大事だった
特にsvg pathをきちんと理解することによって、とてもユニークな可視化ができた
ミュージカルのハミルトンにとてもはまっていた
ので、ハミルトンの可視化
キャラクター、キャラクター間の会話、その他、についてフィルターできるようにした
2ヶ月前にとても不思議な事がわかった
これは画像ではなくイメージ。それぞれのフレームを描画するのに数秒かかった。性能が劣化した。
コードを9ヶ月触ってなかった
renderするのに数秒かかり、非常にひどいことになってた。
twitterで他の人にブラウザの更新のせいか心当たりがないか聞いたら、理由はcanvasがとても大きかったからということをとても親切にもおしえてくれるひとがいた
ガールフレンドと休み中なのに…
メモリにとても負荷をかけていた
GPUメモリにヘビーな負荷をかけるとChromeはSoftware renderingモードにfallbackするという仕組みになっていた
documentと同じ高さのcanvasを作り、ドットをアニメーションさせて、なぜかというと読み進めるにつれてドットを追従させたかったから
6000pxから3000pxの高さにcanvasを小さくして、視覚効果を維持した
数週間かかったが早くなった
（つまりはGPUメモリをそんなに使わないのであればhardware renderingを使うのでするするスムーズに動くか、そうじゃなくて負荷をかけると自動的にsoftwareでレンダリングされるのでNGになると。)
svg, d3 などはツールセットだと思っているが、これらを理解するのがとても大事。一番大事なツールだと思っている
最初の80%。データを集めて、解析して、アイデアを作って… これは大事。ただし、残りの20%が同じぐらい大事。
例えばこの点はスクロールするに従って動くが、その動きがとても良く、読者にどのようにデータを読めばよいかを教える
このようなディテールを重視している
これまで自分のプロジェクトを紹介したが、他のプロジェクトも紹介する
Royal Constellations
http://www.datasketch.es/october/code/nadieh/
作者は欧州の王家がどのように結婚を繰り返してきたかに興味があった
色がイングランド、デンマークなどの王家。それぞれのスターが王家の中心人物
動けばとてもきれいなんだけど…
誰かにカーソルを合わせると、つながりがばっと広がるはず
6度の広がりがみえる
より良いところは、二人の人を選ぶと、どのように線を繋げば最短でつながるかを表示してくれる

もう一つのプロジェクトはドラゴンボールZ
http://www.datasketch.es/january/code/nadieh/
みたことはないけど nadieh は大好き
戦闘シーンが特に好き
このオレンジがごくう、それぞれの○が戦闘、カーブは一つの戦闘から次の戦闘に飛ぶ様子
いいもんが←、わるものが→
例えばベジータは悪者サイドではじまり、良い物サイドにいく
もしアメリカにいて、日本ではなければ、丸をクリックするとYouTubeの正しいビデオに飛ぶ
とてもかっこいいでしょ
こういう可視化はとても時間がかかる
このトークから持ち帰って欲しいのは、可視化はとても楽しいということ
国際的な友人、ここの会場でトークができること
とてもすばらしい
ぜひ帰ったら可視化に挑戦してみてほしい
ありがとうございました

JSON Schema Centralized Design

https://speakerdeck.com/pika_shi/json-schema-centralized-design

Hikaru TAKEMURA

pros
脆弱性診断の時とかそこだけやればいいリストになる

cons
仕様と実装の乖離が進んでしまう

json schema

• json objectの型定義format
• yamlで記述してjsonに変換することが多い

RAML
REST api定義format

• yamlで記述
• 仕様をバージョン管理できdiffで管理できる
• JSON schemaをincludeできる

JSON Schema Centralized Design

ドキュメントから自動でコードを生成して保守性を高める

APIドキュメントからAPIサーバのテストがかける

このへん多分今日の話に近い記事っぽい
https://qiita.com/pika_shi/items/7b8136d5ee3ad8b6957c

spec ドリブン development
example ドリブン development

Real-world applications of hash functions

Emil Bay

Emil bayです、 githubも emilbayです。
Denmarkで働いてます。
電車は日本だと53秒くらい遅れるけど、デンマークだと7年遅れてる
hash functions
最初のハッシュ関数を見てみましょう
problem: Map data to integer
position in memory
fun: network port
パスワードをストアするのに使われてたりしますよね
最初のhashfunctionは電話番号でした
mathiasという友達がnumber-padというライブラリを作っています
これを使ってhash関数をみてみましょう。
電話番号のところ abc が 1 で def が2 で、、、という風に電話番号の番号をalphabetにマップして表示するライブラリです。
これを使うと httpは4887ですね
もう少しディープなハッシュ関数をやってみます。 djb2 を作ってみましょう
Hello という文字列のハッシュ値をdjb2で出してみます、こんな感じですね。
次は konnichiwa でやります。値が変わりましたね。
bufferでやったのはその方が memory アロケーションがダイレクトですごくcostが安いから。
Buffer.from('Hello') で buffer として演算したほうが効率的。
djb2i16 で 65536の範囲内に収めてみましょう。
これでポート番号の範囲内なので、microservicesのポート番号にも使えますね
ただしハッシュ値はその値によって衝突も起きます。
良いハッシュ関数はこの衝突が起きにくいハッシュ関数です。
2^n の n に使える数によって範囲が変わります。 8 だと 256 16なら 65536と増えていきます。このようにして数の範囲が変わり、ハッシュ関数を使える用途が変わっていきます。
値が大きくなればなるほど衝突が起きる可能性は減っていきます。
１つ例としてファイルアップロードの例をあげます
ファイルをアップロードしたらそのファイルにハッシュ値を付与してfingerprintを取るようにします。
nodeのソースコードを tar.gzしたものをアップロードしてみます。
key に sha256のハッシュ値が帰ってきました。 size も帰ってきてます。
uploadsにはハッシュ値を分解したものがあがっています。こうすることでファイルアップロード時の名前衝突を防ぐことができます。
JavaScript ecosystem は 94% のファイルの重複があったりする。こういうものを見つけるのにもハッシュ値で見つけるのは重要。他にもgitの中ではハッシュ値で値を取ってファイルとしてobjectを保管している。
npm install -g ied とやるとnode_modulesのハッシュ値がわかる(?)
https://github.com/alexanderGugel/ied
ied は npm の代替で、node_modules の中にgitのようにハッシュ値で管理するようにすることでContent-Addressable Storageを作るという方法なのか。
次のトピックは Security
impossible to fin b, so that h(a) = h(b)
ハッシュ値をcryptographyに使うことで、パスワードのそのものを知らなくても一致させることにつかえる。
sodium という暗号化ライブラリを使ってhash値のdigestがあっているかどうかをチェックしてみると、毎回同じものを実行している限りは必ず同じものが変えるようになっている。
webassemblyでやっても速いが、 Cよりは3倍くらい遅かった。
Balke2bを日本のblue trainとすると、SHAKE-128はデンマークの汽車みたいなもの。
https://twitter.com/_tessr/status/766124117565202432
Hashcoin というアイデアもある。 emailでcryptographicな値を送りあって ... (難しかったのでリンク貼ります)
https://www.hashcoin.io/
zeroの数を数える clz/nlzにもhash関数が使える
ハッシュ関数にdifficultyという値でより複雑な値に変換させることもできる。それを使ってbitcoinはminingの難易度を調整させている
JavaScript には 32bit integer のためのoperatorがある、 64bit floatなら二倍の精度で計算できる
webassemblyでもdjb2を書いてみた。すごく長くなったｗ
webassembly のline-by-lineでのやってること紹介
webassembly ってループ用のfor文みたいなのがないのでincrementも最後でやった上でloopという構文の中に囲むことになるのか。
hash functionはローレベルな処理でしかも非常に沢山実行されるからwasmとして定義して実行することで速くなるかもしれない

ng-conf2017.md

Source to Binary - journey of V8 javascript engine

https://speakerdeck.com/brn/source-to-binary-journey-of-v8-javascript-engine

青野健利 a.k.a brn

V8の話

コードを全部パースすると重い
functionの外観だけを先にパースする
実際にfunctionが呼ばれたタイミングで実際にパースする
Lazy Parsing

ASTの話
let, const, spread operator
astは重いのでbinaryにしちゃおう

bytecode interpreter
astをbytecodeに変換して実行する

Hidden Class
obectの構造体から型を推論する
別のオブジェクトであっても同じpropertyを持っていれば同じHiddenClassとして扱う
Mapと呼ぶ
厳密にpropertyの順番をみるので、少しでも違うと違うMapとして扱う
propertyの増減は多いので前のMapを引き継ぎながら新しいMapを作る
Mapによってプロパティアクセスや型のチェックがより高速になる

inline caching
プロパティアクセスの高速化のためにcachingする
hashmapやfixedarrayからプロパティを毎回ロードするのはすごく遅い
特定のmapを記憶しておく
2回目以降のアクセスは早くなる
違う構造をもつものをあまりに大量に配列にいれると、毎回ロードするので遅くなる

Node.js Production Checklist

Gergely Nemeth

99.9%動くサービスを作るには
26s/month しかdowntimeをもてない
SLA
SLOは Best Practice だと思っています。

error handling
you have to lean to throw again
migrate from callbacks to async-await
callbackじゃなくてtry catch使おうね
error handler middleware
error handlingのためのboomというmoduleいいよ
Middlewareを使うとエラーの失敗が少なくなっています。コードも短くなっています。

checklistの2つめはsecurity
npmコマンド自体のセキュリティをまず見直す
X-Frame-Options: clickjacking attak
strict-transport-security: to keep your yours on https
x-xss-protection: to prevent reflected css attacks
x-dns-prefetch-control
セキュリティのベーシックチェックは [helmet] (https://www.npmjs.com/package/helmet) で対応できます
joiでvalidateing user input

logging best practice

timestamp
format
destination
support for log levels

ログインを作る最低限の要素
timestamps　いつおきたか
format人にも機械にも読みやすいもの
destination: 最低限のものをアウトプットする
Loglevel: debug とか infoとか

error
general errors, always reported
whenever
app may try to recover or forcefully terminate

warn

info
indicate major state changes in the application like the startup of the http server
each component shoud log

debug
diagnostical level events

log the original url of the request for errors

CICD

継続的なデリバリーを作るのに、なにをチェックするか

protect the master branch
only approved pull request can be merge

run automated checks on your codebase

with good test coverage
youcan doploy to production on evenry commit
Test Coverageが高い場合はデプロイが早くなります。

monitoring your applications

error rate: as they directly affetct customor satisfaction
latency
throughput
saturation

Response Time は役に立っていません。 (Gergleyの経験です）
you want to have route-level metrics
ユーザが使っている Endpoint は大事です。
endpointごとに見ろ。averageじゃなく
Black Box Monitoring サービスはいくつかがあります。
例えば Pingdom, ping.apex.sh

アラートシステム構築

問題の場合は書いている人が担当者にした方がいいです。
そうすると客と近くなるからコードのクオリティーが増えています。
問題のために Status Page があるのが客も気持ちが安全になります。
24時間のサービスのために少なくとも3人が必要になります。
war room

サマリー

• Async awaitでのエラーハンドリングについて
• 継続的デリバリーについて
• ログの仕方、モニタリングの仕方
• そしてアラートシステム構築

Node.js x Chrome headless で、お手軽WebRTC MCU

がねこまさし

https://www.slideshare.net/mganeko/nodejs-x-headless-chrome-for-wertc-mcu-nodejs-x-chrome-headless-webrtc-mcu/

mcuをNode.js x ヘッドレスブラウザで実現していじり放題

iOSはコーデックが1部しか対応してない

p2p

ブラウザ同士

good

• サーバ不要
• シンプル

bad

• cpu負荷
• ネットワーク負荷

負荷が高い理由
圧縮不可が高い理由
通信相手に合わせて別々に圧縮している（状況に合わせて

sfu

サーバ側で映像/音声を配布
サーバでは圧縮しない
クライアントがサーバに1つ映像を送りつける
結局うけ取るのは個別

MCU

サーバ側で映像/音声を合成

回線に合わせた圧縮率
クライアントに合わせたコーデックが利用可能

OSS

• kuranto
• licode

mcuをブラウザで

ブラウザのrequest animation frameを使っているのでタブを切り替えたりタブが隠れたりすると止まる
自分の声をのぞいた声を合成してあげないといけない

シグナリングの方法が規定されていない
アプリケーション、サービスごとに異なる

メッセージとシグナリングにだけnode.jsを使ってるっぽい

puppeteerとかは使ってない

Node.jsからchildProcessで起動
proc.kill('SIGKILL')で殺す

接続を始めたタイミングでheadless chromeを立ち上げてる。
全員いなくなったらプロセスkill

サーバ側の負荷は非常に高い

No REST for the weary... Introducing GraphQL

https://speakerdeck.com/siakaramalegos/no-rest-for-the-weary-dot-dot-dot-introducing-graphql-nodefest-japan

Sia Karamalegos

GraphQL -> ぐらふきゅーえるかと思ってたらぐらふぃくるって発音してる

before REST theare was SOAP
restはclientとserverを分ける(decouple)ためのものだった

watus the problem

API のコントロールが問題です。この API の例は FrontEnd のかたが変えません。
ブログのトップページを表示するのに、9つのリクエストを必要とする。
フロントエンドが必要ないデータもサーバーが送っています

chatty == slow

too much data

GraphQLは Specのみです。
GraphQLは、データの形を宣言して、必要なプロパティをリクエストするとそのデータだけを返す、という仕様
今日の例で REST のAPI を GraphQLに書き換えます。
現在はRESTで実装されているStar WarsのAPIを使います

https://github.com/graphql/graphiql
https://swapi.co/
ドキュメンテションは Spec で自動にもらえます。
今は swapi を GraphQL を使って試しています。
スターウォーズに登場する惑星のデータをgraphqlで取得します
必要のないデータはサーバーからは返ってきません

使い方
sample code
https://github.com/siakaramalegos/star_wars_graphql

expressでgraphqlを実現するためのライブラリ
https://www.npmjs.com/package/express-graphql
schemeをもとに、express-graphqlを利用しGraphQLのapiの作成
Apolloとかのツールもありますがこれはgraphql標準のスキーマです
GraphQLListを使うことで、外部テーブルをそのまま使うように定義を持ってくることができる

今さら聞けないSPAのCORS対策の話

杉浦颯太

CORS

Origin -> Scheme, Host, Port
サブドメインとかもoriginは変わるよ

Same Origin Policy

ブラウザがsame origin policyにのっとって処理を抑制している

意図的に制御を解除する仕組み -> CORS

Access-Control-Allow-Origin
Access-Control-Allow-Method

この辺理解しておいてね

• cors
• preflight
• ajax with credentials

cross origin

Access-Control-Allow-Origin

Access-Control-Allow-Method

Access-Control-Expose-Headers
-> 明示的に許可したいヘッダを追加

access tokenをlocalstorageとかにもたせる

not best

xss仕込まれる
expireの仕組みとか自分で作らないといけない
-> 現状cookieになるんじゃないかな

Set-Cookie: HttpOnly; Secure

jsからdocument.cookieにアクセスできなくなる

withCredentials

Access-Control-Allow-Credentials: true

Access-Control-Allow-Originは*を指定できない
ちゃんと指定しようね

Optimize performance

preflight request

cross originのときにブラウザが勝手に送るリクエスト
-> 単純に通信コストが2倍になる

preflight request -> 実際のreuqest
put, delete, patch, optionsはpreflight requestが送られる
headerにもいくつか送られるやつがある

何も送らないように制御するのが一番いい

• get,postしか使わないとか
• content-typeを絞るとか

CSRF

origin headerはブラウザでは書き換えられないのでそれでチェック

preflightを最適化する方法はある

ブラウザでcacheできる
Access-Control-Max-Age: 100 -> 100秒間はブラウザにcacheさせる
あまりいけてない設定
ブラウザによって上限値が決まっている
chrome -> 10m
firefox -> 24h

Turbo Boost Next Node.js

Yosuke Furukawa

とりあえず資料だけメモ https://speakerdeck.com/yosuke_furukawa/turbo-boost-next-node-dot-js

Native ES Module - something almost, but not quite entirely unlike CommonJS

Gil Tayar
https://twitter.com/giltayar

https://docs.google.com/presentation/d/1JKnj-HvAwkba9GMEuEqZjMPzAaZTL7j2f1n4JjOWXhs/mobilepresent?slide=id.p

es modulesがついにnode.jsにきたぞ
3年もかかった

--experimental-modules

named exports

kettle.mjs

export const spout = 'the spout'
export const handle = 'the handle'
export const tea = 'hot tea'

main.mjs

import { handle, spout, tea} from './kettle'

console.log(handle)

全てのloadはasynchronousであり、syncで動くcommonjsとは違う
ファイル名には .mjs が必要

ES modulesのルール

1. ESM には .mjs を付ける
2. .js は CJS

mjs は michael jackson script とも呼ばれてる

export default foo is same module.exports = foo and import a from 'a' is same to const a = require('a')

file resolution - index

index ファイルの解決方法は異なる。
ES Modulesでは、 package.json には main: "foo.mjs" と書く必要がある。

// このへんはcommon moduleの仕組みと一緒ぽいな

file resolution - node_modules

• node_modules/kettle.mjsはimport { tea } from './kettle'でimportできる

// node_modules以下が./になる。。。？

file resolution - dynamic

async function main() {
  const { tea } = await import('./kettle.mjs')

  console.log(tea)
}

main()

動的なloadをする場合、CommonJS の require はただの関数なので任意のタイミングで実行できる。 ESMの場合は import() という新しいsyntaxを使う必要がある。
これを await させて使う。

// importがpromiseを返す

import path from 'path'
import fs from 'fs'
import url from 'url'

const __dirname = path.dirname(new url.URL(import.meta.url).pathname)

import.meta.urlは__dirnameとimport.meta.urlはfile://xn--hogehoge-z83gka8m8am4be8w9g2327f、URL parsingは必要です。

Interoperability

ESM と CJS の間には 巨大なバリアがある
Node.js はそのバリアのためにbridgeを用意している

mjs can import js

• but only default import

js can import mjs

• but only dynamic import

js で named export されていると MJS から import するときには named import できない。失敗する
js で default export すれば MJS から default import で呼べる

migrating from cjs

CJSからESMにmigrationするには２つのアプローチがある。

as application developpers

• stop using babel !!
• rename all js to mjs cahnge all require-s to imports if it's cjs, then defualt imports only
• change dynamic require-s to await import() only if they are really dynamic !

全てのjsをmjsに変更しよう。
requireをimportに変更して、もしもCJSから使うならdefault importだけ使うようにしよう。
dynamic require は 全て dynamic import だけにして、実行しよう。

as library developpers

• require('no-extension') ** only '.js'
• import ... from 'no-extension' ** first '.mjs' (as ecma)

Migrationのためのルールとしては .mjs や .js を書かないextension無しでの呼び出しはやめておこう。

dual-mode-libraly
簡単なはなし。mjsとjsの2つのファイルを吐き出せばいい

まずはmjs-styleのファイルを書いてpackage.jsonのmainにそのファイルを書く
babelでmjsをjsファイルにbuildにする
シンプルに2つだけpluginを使えばいい

transform-es2015-modules-commonjs
dynamic-import

その時は.gitignoreにbabel済みのものをignoreするのを忘れずに。

標準化ってなに？ Webプラットフォーム/ESNextを作る方法

Mariko Kosaka

資料だけメモ
https://speakerdeck.com/kosamari/web-platform-dot-dot-dot-what-is-it-webpuratutohuomufalsetukurifang

TLに流れてた

http://teppeis.hatenablog.com/entry/2017/08/es-modules-in-nodejs

memo

https://speakerdeck.com/quramy/introduction-to-visual-regression-testing-jp これスクリーンショットのときに使えそう
requestIdleCallbackでスクリーンショット -> レンダリングのあとにスクリーンショットをとる
CSS animation, transitionをnone importで強制的に潰す