渋谷かと思ってたら東京だった回！
「npm v4/v5/next」 by @othiym23
これは事前に共有してもらえたスクリプトです。
ほぼこれの通りに話されてたので、ざっくりメモ。
自己紹介
- npmのCLIチームのリーダーです
- チームにはKatとRebeccaがいるよ
- ありがとう @watilde さん!
npmのいままで
- 今やmillions of users, over 350,000 packagesな大プロジェクト
- なので機能追加は慎重にやっていく
- SemVerはある種の契約
- npm@2からnpm@3
- まさにメジャーアップデートだった
- でもいまだにnpm@2を使ってる人もいる
- npm@2のほうがインストールが早いケースもある
npm@4
- メジャーアップデートではあるがそんなに変わらないかも
- depricatedになるものがいろいろ
- 変更点は↑のGistをどうぞ
- npm searchがStreamになるのでちょっぱやに
- 今までは10MBくらいあるjsonを取りに行ってた
npm shrinkwrap
- 使ってる人ー？ 会場「ぱらぱら・・」
パッケージマネージャについて
- RubyならBundler
- RustならCargo
- インストール結果を保証したい
- インストールするタイミングで結果が変わる
- そうならないために、lock fileを作ることがおおい
- Bundlerは
- Gemfile / Gemfile.lock
- lockはflat only
- Cargoは
- Cargo.toml / Cargo.lock
- lockはネストできる
- yarnは
- package.json / yarn.lock
- ライブラリ向けにネストもできるし、クライアント向けにflatにもできる
shrinkwrap
- 後方互換性のために
- metadataをもてるように
- もう少しhackしやすい仕組みにしたい
パフォーマンス改善
- content-addressable cacheなる仕組み
- ローカルにあるものはサーバーに取りに行かない
npm@5
- NodeのLTSとnpmのLTS
- 2017/04には出したい
- Nodeのv8に入る？ > まだわからない
「GraphQLの話」 by @KOBA789
自己紹介
- GraphQL知ってる人ー？ > 会場「結構いる」
- 書いたことある人ー？ > 会場「ぱらぱら・・」
- SQLの親戚みたいに思ってた人ー？ > 会場「ぱらぱら・・」 ですよねー
- 質問もってきた人ー？ > 会場「ぱらぱら・・」 ヒッ
- 中学2年からNodeの本を書いてた！
RESTful APIとは
- SQLをそのままパラメータにするみたいなことではない
- 直感的に設計できない
- Swaggerでドキュメント・・？
フロントエンドのつらみ
- もはやフロントエンドはただのViewではなく、サービスを構成するMicroServiceの1つ・・！
- 他のMicroServiceたち（サーバーサイド）に比べると遠い（1RTTが重い
- から1リクエストでなんとかしたい
- UIなので非合理的な要求が多い
- コメントは3件だけとか
- でもでも細かい指定はしたい
- やっぱ10件にしてとか言われるから
- オーケストレーション層を置けばいいのでは！（2層式や！
- 全て解決できるわけではない
- そこでGraphQL
GraphQL
- ほしいのはテーブルではなくグラフ
- デモ
- https://github.com/graphql/graphiql というツールが
- 型付きなので補完が出るよ、いわんやドキュメントに
- まぁFalcorとかと一緒でサーバーサイドで受けるクエリと返すものの定義は必要
- JOINの多いサービスに向いてるかも
- ただしN+1問題は普通に起きる
- GitHub - calebmer/postgraphql: A GraphQL API created by reflection over a PostgreSQL schema.より良い感じのつくってるよ
まとめ
- RESTful以外にもAPI設計のやり方はあるよ
- GraphQLが全てでもない
- これからの分野なので、もっと語っていきたい
「Webのネイティブ広告の話（仮）」 by @saneyuki_s
Client-side JS for infeed layout native ad at fluct SSP // Speaker Deck
Node学園祭のCFP落ちたのでお焚きあげだそうな。
はじめに
- 話さないこと
- AdblockとかWebの未来とか
- 俺が考えた最強のxxとか
- 広告枠の枠についての話をします
- SSP(Supply Side Platform)という業種だそうな
- DSPとの違いは、オークションしないか
- そんなDSPやAd networkから広告をもらって、それを配信する
- 広告の配信方法
- SDKを配るスタイル
- タグを配るスタイル （こっち
デファクト
- いちおうルールがある
- OpenRTBプロトコル
- ザルな仕様・・
- 誤字だらけのドキュメント・・
- DSPは任意のjsを埋め込めるようになってる
- ＼document.write()／
- 使いたくないけど儲かるDSPなので使わざるを得なかったりと・・
広告が表示されるまで
- ページ読み込み
- SSPのサーバーへ`script`からリクエスト
- オークションして広告を決めて返す
- うまくいったらそのまま出す
- ダメなら各自で広告を取りに
- いったんadServerでjsを解析しないといけない
- 愚直に評価するとXSSされちゃう
- なのでいったんjsonにする
昨今のWeb広告
- パフォーマンスを求められる時代
- 同じタグを何個もはられたりする（非同期）ので判別したい
- `document.currentScript`は古いAndroidで動かない
- 4.xでLegacyとか言われるんか・・
- リクエストにidをふる
- `document.currentScript`は古いAndroidで動かない
- リトライ用にキューを作って、優先度をみる
- DOMを安全に構築するには？
- 単純な文字列連結はダメ
- DOMのAPIを使ったほうがいいが、そんなライブラリはない・・
- サーバーでやらず、クライアントでやる
クライアントでは
- サーバーとやりとりするRuntime
- 各Ad networkとやりとりするDriver
- 基本的に非同期でいろいろやる
- でもモダンなライブラリは容量を食うので使えない
- 1kbでもトラフィック量から見ると重い
- promiseのsimすら使えないので自作
- TypeScript target=ES3, modules=AMD
その他地雷まとめ
- `navigator.sendBeacon()`はクリティカルパスのロード中には使えない
- LegacyなAndroidはテストを一気に実行すると落ちる
- 独自のキュー機構を作ったのでDOMと食合せが悪い
これから
- どんな環境で走ってるのかレポートする仕組みを作り中
- 例のキュー機構をリファクタしたい
- OSSに・・？
- コード自体を公開してもデメリットにはならない