東京Node学園祭2014

東京Node学園祭2014 に参加してきたのでその時のメモ

企業JavaScript飯

#企業JavaScript飯というご飯イベントをNode学園祭のお昼に(勝手に)やってました。

@teppeis、@ahomu、@kyosuke、Layzie (敬称略)で企業内でのJavaScript状況ですかという感じの話をしてきました。

img

質問テーマのスライド: https://github.com/azu/slide/raw/gh-pages/nodefest2014/lunch.pdf

という感じのテーマを元に話をしてきました。

参加していただいた皆さん興味深いお話ありがとうございました。

最近企業のJavaScript(er)ってどんな感じになってて、どういうものを求めているのかに興味を持ってるので、面白い話があったらお話きかせて下さい。(to @azu_re にmention)

基調講演

  • Socket.io
  • FTP
    • テキストには圧縮が効くがバイナリには圧縮が効いてない
    • 同じ事ができないのでオーバヘッドができてた(スイッチングコスト)
  • HTTP
    • HTTPは段々良くなってきた modifier
    • ただ、回線では良くなってるけどウェブだとイマイチ
    • 一番大切だと思ってるのでファイルトランスファー
    • 一度途中で止まると、もう一度再開するのは手動
    • また並列にダウンロードとかできない(回線が早くなったのでよかった)
    • ダウンロードでは圧縮が効くけど、アップロードの時は効かない
  • XHR Lv2
    • バイナリサポートをしている
    • Progressのイベントもある
    • File APIを使ってアップロードする前にファイルを書き換えできる
    • Blob#slice をつかう
  • Party
    • アップロードの機能に限定されたフレームワーク
    • BitTorrentに似てる(一つのfile streamじゃなくて)
    • S3に保存することもできる
    • 細かいメタ情報がある
    • 早くてシンプルなものを作りたい
  • http://party.rauchg.com/
    • テスト用のオプションを分けて
    • サーバの機能によってどれを使うかを選べる
    • 早くするためにファイルをパーツに分けている
    • TCPをできるだけ使い切るようにしてる
    • 圧縮は開発中 - ChromeではWebSocketでDeflateをサポートしてる
    • zlibを作ってるので、他のでも早くなるかもしれない
    • party側がやってくれるので細かい事を考えなくてもいい
    • 通信が切れた時の再接続とか
  • ライブラリ Automattic に公開予定

Front-end with Node.js for Beginners - @ahomu

スライド

メモ

  • 属人化から自動化 - Node.js製のツールがでてきた
  • パッケージマネージャー
    • Before
      • 配布サイトからダウンロード
      • コピー
    • After
      • コマンド叩いてインストール
      • アップデートも一発
      • 依存関係も解決してくれる
  • Node / ブラウザ でパッケージ管理
  • npm
    • Nodeの標準パッケージマネージャー
  • Bower
    • npmでインストールしてブラウザ向けのJSを管理
  • 2つのリポジトリと設定ファイルを管理してるプロジェクトが多い
    • 2つのまとめたい => npm にまとめる??
    • まだブラウザ向けの情報がnpmのpackage.jsonには入ってない
    • なのでNodeのエコシステムがそのままブラウザに持ってこれるのかは未定
  • Tips
    • npm i
    • npm rm
    • とか短縮オプションがある
    • npm-shrinkwrap 現在のnode_modules内のバージョンを記録して固定する
  • Bower
    • バージョンの競合が依存解決できないとき
    • resolutionsフィールドでデフォルトでどれを使うとかを指定できる
  • Task Runner
    • Before
      • 手動で実行
    • After
      • まとめて自動で実行できる
  • 多彩なタスクを実行してくれる
  • GulpとGrunt
    • 両方とも多くのタスクがある
    • pluginの数に差はあるけど大体あるので同じ
  • Grunt
    • JSONを書いていくだけの宣言的な設定を書く
    • Gruntはtmpにファイルを吐き出して変換を繰り返す
    • 変換を繰り返すような設定は冗長な感じ
  • Gulp
    • JavaScriptのコードで設定を書く
    • taskでタスクの定義、src,pipeで繋いでdestで出力
  • Tips: Grunt
    • Gruntに思う所がプラグインがされている
  • npm run <command>
    • npm 2.0.0で引数の受け渡しも出来る
    • 原始的なコマンド実行を行える
    • 単純なタスクならnpm runでも十分にできる
  • モジュールシステム
    • レガシーコードをどうにかする仕組み
    • Before
      • 大きなファイルが普通にあった
    • After
      • FluxとかMVとかファイルを分ける = モジュール
      • モジュールを管理する出来る
  • Browserify
    • CommonJSをブラウザで実行出来るようにビルドする
    • 基本的には設定があまりなくてもいい
    • 細かい設定はpackage.jsonにメタフィールドを追加する
  • Require.js
    • AMDと呼ばれる一連の仕組み
    • ランタイムとモジュールの仕組み
    • 設定をちゃんと書かないと解決しにくい
  • webpack
    • CommonJS、AMD両方対応
    • Browserifyはひとつのファイル出力がデフォルト
    • webpackは複数のファイル出力に対応してる
    • 非同期ロード用にchunkデータとして吐き出せる
    • 設定はやや複雑な
  • Duo
  • まとめ
    • Browserify
      • 導入が簡単で入門にはいい
    • RequreJS
      • 非同期がデフォルト。モバイルだと通信が多いので相性微妙?
      • r.jsでまとめられるけど、それならBrowserifyでもいいんじゃないか
    • webpack
      • Browserifyからの移行もできる。小さいプロジェクトだと適応しにくいかも
    • Duo
      • 流行ったら考えよう

すべてのノードトランスパイラーがひどい！ならば、ノードトランスパイラーをいかに改善できるか。 - @leichtgewicht

NodeFest2014 - Transpiler

  • Transpiler
    • コンパイラの種類の一つ
    • Source -> Source のコンパイラ
    • JavaScript、CSS、HTML
  • JavaScriptのContextでは一杯ある
    • BrowserifyとかもひとつのTranspiler
  • Transpilerの問題
  • Transpilerパフォーマンス
    • Static Site Generatorの待つ時間が長い
    • 殆どのTranspilerは同期
      • JavaScript、HTMLは殆ど同期
    • 並列にコンパイルできないのでパフォーマンスが問題になる
      • CSSはAsyncでできるやつがなぜか多い
    • 起動するだけでも時間がかかるやつが多い
      • 200msぐらいかかるものがある…
    • import caching
      • インポートのキャッシュが重要
      • jadeはimport cachingしてる
  • Transpiler設定体系
    • source-map
    • targe-encoding
    • pre/post processing
    • output path
    • input path
      • I/O piping
    • import
    • 設定入力システム
      • 似たような設定なはずなのに、オプションとかバラバラ。
    • 設定の保存
      • jade --out hoge.jade --save save.config みたいな感じで設定ファイルを保存できると便利そう(提案)
  • Transpiler 依存関係
    • Watch : Stage 1
      • そのファイルそのものだけを監視
    • Watch : Stage 2
      • そのファイルが依存してるものも監視
    • Watch : Stage 3
      • インポートパターンの対応
    • Watch : Stage 4
      • 別の言語依存も監視してコンパイル
    • Watch : Stage 5
      • Configファイルが変わったらもう一度コンパイル
    • Watch : Stage 6
      • パイプライン
  • TranspilerのCLIごっちゃごちゃ
    • デフォルトが圧縮するしない?
    • 引数なしの場合の挙動が違う
    • それぞれのCLIで挙動が違うと気持ち悪い
    • エラーコードやformatting
      • Syntax Error
      • Config Error
      • どのようにエラーを出すのかの標準がないから辛い
  • Transpiler 合成
    • 一つのHTMLでインラインに書いてそれぞれTranspileをしたい時
    • 合成システムがTranspilerにはない
  • エコシステム
    • Transpilerがよくなれば、エコシステムがよくなる
    • ドキュメントが簡単になるので初心者に優しい
  • みんなTranspilerを使ってる

FAQ

  • アプローチに上にレイヤーをつくる or それぞれお願いする
    • レイヤーを作る方向で検討してる

テスト用ライブラリ power-assert, その開発で学んだ npm モジュール設計の勘所 - @t_wada

power-assert, mechanism and philosophy

アジェンダ

  • power-assertの紹介
  • 仕組み
  • 設計思想

JavaScriptのつと

  • JavaScriptにはテストのデファクトスタンダートがない
  • アサーションライブラリもメソッド数が多い
  • Nodeのassertモジュールが十分な情報を吐いてくれるなら問題ないのでは

DEMO

  • Chaiのコードをassertに書き方に変える
  • This is power-assert
  • シンプルで十分な情報が出せればいい => power-assert

power-assert

  • 成功してる時は静かに
  • 失敗する時はうるさく伝える
  • assertionメソッドが3つぐらいで十分になる

power-assertの仕組み

  • 実行時にコードを変換して実行するようにしてる
  • その変換時にエラーに必要な情報を埋め込む
  • ASTを変換して、埋め込んでいる

DEMO : ASTを変換して -> コードに戻す(Generator)

  • コードを標準入力で受け取る
  • esprimaでコードをASTにパースする
  • estraverseでASTを変更する
  • escodegenでASTをコードに出力し直す

substack pattern

  • モジュールから外部に公開する関数はひとつだけにする
  • 複数返したくなったらもう一個モジュールを作る

DEMO2: 先ほどのデモのAST変換の部分をモジュール化する

  • AST変換部分のコールバックを関数化
  • 関数を別のファイルに分けてモジュール化
  • substackパターンで関数を公開する
  • requireでモジュールを読み込んで使う

DEMO3: パースして、変換、生成の3つなので、それぞれモジュールを分ける

  • コードを受け取り、ASTを返す
  • 変換はASTを受け取り、変換、ASTを返すとする
  • ASTを受け取りコードを出力

これはpower-assertでやってることと同じ

  • ASTを受け取り、変換、ASTを返す = espower

設計思想

  • Easy is not simple
  • SimpleとEasyは別である
  • それぞれモジュールに分ける
  • それぞれのコンテキストにあわせたEasyを提供する
    • Grunt
    • Gulp
    • Node
    • etc…
  • Simpleが本質的な所
    • どういう処理をするかという話

ギャルでもゎかる node-webkit - @upgrade_ayp

  • ユーザ側の話
  • node-webkitってなに
    • デスクトップGUIアプリが作れる
      • GUI(HTML/JS/CSS)
      • Same originとかも突破出来るので楽
  • プロジェクト1 : 事務仕事で使うnode-webkit製のアプリ
  • Contextの問題
  • node-webkit vs atom-shell
    • node-webkitは両方のcontextを普通に扱える
    • atom-shellのserverから見た時
  • ユニットテスト
  • E2Eテスト
    • Nightwatch.js
    • SeleniumのChromeDriverで動く
    • remote-debugging-portを指定して起動する起動できない問題
  • ソースコードプロテクション
    • node-webkitはビルドするけどソースコードがそのまま見える
    • Developer Tools 開くボタンを失くす
    • Remote Debugger Port
      • メインウィンドウのinspect権を先に奪う
    • ユーザーのローカルTMP_DIR
      • 暗号化で対処
      • ビルド前に暗号化
      • gulpとかでjsを暗号化してnwビルド
      • require時に復元する(読み込むときに拡張子別でhookして複合する
  • プロジェクト2
    • リモートにデータベース置いてmongooseで接続
    • Socket.ioで繋ぐ
    • D3のチューニングが大切
    • 常時起動してるのでメモリリークのチェック必要
  • デスクトップNode.jsの世界
    • JavaScriptで全部書けるのは楽
    • Node、npmライブラリが使えるのが楽
    • node始める時にウェブサービスじゃなくてアプリを作ることから始められる

LT

新しい並行計算ライブラリjs-cspをご紹介 - @niryuu

新しい並行計算ライブラリ js-csp のご紹介

  • node.jsで非同期プログラミングを繋いでいく問題
  • Promise/Generatorベースになってきた
  • 新しい書き方がでてきてるが、ちゃんと動いてるのかの検証が難しい
  • 非同期処理の検証の問題
    • 繋いで行く時に失敗する事がある
  • 非同期に向いた計算モデルが必要 => CSP

##ド初心者が5000QPSの広告配信APIをNode.jsで構築したおはな死 - @zuqqhi2, @Jimisky

  • 改善前の広告が色々やってた
    • 複数のリクエスト
    • CSSやJavaScriptが大量
  • 改善: Node.js
    • 複数のリクエストをNode側にまとめる
    • APIオーケストレーション
  • Tips1 :child_process.exec は使わない
  • Tips2 : ライブラリ
    • CやC++のネイティブ処理を使う
  • Tips3: ローカルオンメモリ
    • ヒット率が8-9が高かったのでメモリキャッシュする
  • Tips4: gwicke/nodegrind
    • 指定した期間内にCPUの状態をダンプする
    • Chrome Dev Toolsで確認出来る
    • Heapダンプ を bnoordhuis/node-heapdump でした

node.js + socket.io + mongoDB で本格風リアルタイムWEBサイトを作ってみた - @ozatty96

  • ファイル数が多いと詰まってしまう
  • SEOの問題
    • Google botはsocket.ioの通信を解釈してくれない
    • 自分でPhantomJSみたいな仕組みを作った
  • これからリアルタイムウェブになるのではないのか

node.jsでビッグデータを処理する - @neo6120

  • ビッグデータのプリプロセス
  • ログ解析
    • 大量のログ解析をする話
    • SQL
  • 解析担当者
    • iPythonでやってるんだけど、多くて上手く行かない
  • 解析のプロプロセス
    • データの分割結合
    • バイナリ化
    • フォーマット変換
  • NodeはシンプルプロセスなのでCPU一つだけの処理だとCPUを使い切れない
  • child_processで分割
    • コアを使い切る
    • キューが溢れてしまう事があった
    • dripped dataがきて更にあふれたことがあった
    • さらにキューが小さく…
  • FAQ: clusterをなぜ使わなかったの?

A Profiling and Monitoring Method for Nodejs Applications - @setogit

その他

メモ: FoldingText