読者です 読者をやめる 読者になる 読者になる

fnwiyaBlog

EmacsとかLispとか可視化とか

node学園祭2016行ってきた

大きなConference系は久しぶり。
node界隈というかJS界隈は幅が広くて動きが活発でとても聴き応えがあった。
一番印象的だったので@t_wada氏のpower-assertへの依存をなくした話。
ロックインをなくしてtool化していく姿勢は本当に尊敬します。
サイボウズのKAIZENNはちょうど悩んでいたろころでぴったりだし、
気になっていたサーバサイドレンダリング、web-assemby周りも知れた、
何より最前線を走っている方々の熱量を感じられたのが良かったです。(after partyも豪華だった)

発表者・運営の方々に感謝です。
来年はLT立ちたいな。

以下メモ

Building Interactive npm Command Line Modules

@Irina Shestak

  • CLIのコマンドのオプションの意味わからなくないですか?という問題提起
  • CLIAppとは? プログラムと対話する
  • optionいっぱいよりinteractiveにするとUser friendly
  • https://github.com/yargs/yargs/ が引数の処理におすすめ
  • ↑default設定、ロングオプション、ショートオプション等の設定が楽
  • .help()でdescriptionがでる
  • catコマンド(猫の飼える数の表示)実装してみたよ(15分ぐらいでできたらしい)

Debugging Node.js Performance Issues in Production

@Thomas Watson

  • パフォーマンスモニタリング
  • 本番のパフォーマンス測定は難しい。影響を与えたくない。
  • premature optimization = 早すぎる最適化はよくない。
  • console.time('hoge'); hoge(); console.timeEnd('hone');で測定できる。
  • 遅くなる(Stop The World)原因:
    • single thread
    • CPU intensive code
    • Slow I/O
    • Event Loop saturation
    • Running out of memory
    • Garbage Collection
  • CPU Intensive Code
    • Sync I/O fs.*Sync
    • JSON parse
    • RegExp
    • Crypto
    • Templates

サイボウズの開発を支えるKAIZEN文化

@Teppei Sato http://www.slideshare.net/teppeis/kaizen-68803503

  • VP of Engineering
  • 技術的負債との戦い
    • あとで時間のあるときにやろう!=>そんな時こない
    • KAIZENN DAY(丸一日KAIZENNする日)。呼び方も変える
    • 1日で終わらない。非エンジニアの共感。割り込み業務 => 改善合宿(関係者に発表)
    • チーム横断なもの => 改善会議(スーパリセットしちゃお) http://pepabo-ceo.jugem.jp/?eid=40
  • 新規技術
  • リモートワーク
    • 採用戦略
    • QoL => ウルトラワーク(総労働時間の10%は好きなところで働いてよい制度)
    • 最初はつらさもあった(つながらない問題) => 全員がリモートワーカー。全員練習する CiscoのSystem
    • 質問責任と説明責任
    • すべての情報はオンラインに
    • 分報(ピープル)
  • 理想の共有/共感

The Seif Project

@Douglas Crockford

  • Upgrade Web => seif project
  • https://github.com/paypal/seifnode
  • https://github.com/paypal/seif-protocol
  • Full duplexなプロトコル
  • Seif resource management
  • Seif Apps
    • HTML-free Javascript-based application delivery build on NodeJS and Qt
    • Logic: Node, Display: Qtをjson-channnelでつなぐ。
  • Trust Management
  • Seif Helper App
  • Transion Plan
    • 一つのブラウザに組み込むよう説得する(Mozilla?MS?)
    • secureなサイトにユーザーにそのブラウザを使うようにしてもらう
    • penguinの原理でほかもついてくるようになる
    • 他のブラウザも対応するようになる
    • 既存のものと並行するとは思うが、新しいものはseifで作られるようになる

Why to Standardize your READMEs

@Richard Littauer

  • READMEはドキュメントより先に見る
  • npmには35万のパッケージがある

Vue.js 2.0 サーバサイドレンダリング

@Kazuya Kawaguchi https://speakerdeck.com/kazupon/vue-dot-js-2-dot-0-server-side-rendering

  • プログレッシブフレームワーク
  • コンパイル template => AST
  • VirtualDOM
    • diff算出コストがかかる => 二段階処理 = 静的なノードの検出 + 静的なノードツリーの検出
    • snabbdomベース
  • サーバーサイドレンダリング
    • レンダラ
      • renderToStream
    • ハイドレーション(水分補給)=>状態補給
    • コンテキスト
    • バンドリング
  • 参照透過性をたもったレンダリングを実装しましょう

React + Reduxを使った大規模商用サービスの開発

@Naohiro Yoshida

  • SSRしたあとはSPAとして動作pushStateをもちいたpjaxなアプリ
  • redux middleware: サーバーとクライアントの差分を吸収する
  • 失敗しないように注意するポイント
    • transition
      • onEnterではreplaceStateを使う。pushStateだめ
      • mountしてから分析ログを飛ばす
      • data fetchしてからRouterContexrのrenderをする
      • iPhone画面スワイプ問題(safariは回避策あり。chromeは無理)
    • webpack
      • 変更箇所意外のhashを変えずにブラウザキャッシュを最大限活用
      • めったに行かない画面のjsはgetComponentで動的に
    • partial renderingでもGoogle botに認識される。Fetch as Google

Introducing Now and Next.js

@nkzawa

The Evolution of Electron

@Cheng Zhao

  • Atomを作ったのがきっかけ
  • node-webkittは複数ウィンドウに対応していなかったのでforkしてatom-shellとして書き直し
  • node-webkitがまともに動かないとAtomが作れない」「じゃあ作者を雇おう」=> チェン=サンがgithubに雇われる
  • コントリビューターを惹き付けるために
    • issues, PRにはすぐに反応することが重要 -開発へのハードルを下げる

JavaScript による並列処理:共有メモリとロック

@Noritada Shimizu https://speakerdeck.com/chikoski/20161113-nodefest

  • Mozillaエヴァンジェリスト
  • メインスレッドという一つの時間軸の上で動いている
  • workerを使うとマルチスレッドが実現できる
  • メッセージ間のデータのやりとりではobjがコピーされる
  • ArrayBufferならポインタを移すだけなので効率的 => SharedArrayBifferならさらに共有可能
  • 食事する哲学者問題 => Atomics.wait
  • unityはHTMLを吐ける。
  • 1.5倍ぐらい早くなる?

WebAssemblyに欠けている大事なもの

@Yoshiki Shibukawa

  • C/C++: 言語自体はとても良くなっている
  • pkgマネージャーがない...rustはいいぞ
  • CMakeがデファクト
  • webassemblyはUIに絞っただけのほうがいいかもしれない

From Library to Tool - power-assert as a General Purpose Assertion Enhancement Tool

@Takuto Wada

  • Testing framework should evoleve slowly.
  • testコードはtestできない。書き直しは綱渡り
  • easy to write VS. easy to learn to write
  • No API is the best API
  • require('power-assert')ではなくrequire('assert')で動くようにした。power-assertに依存しない。From Library to Tool
  • assertはtestだけのためのものではない。契約プログラミングなど。unassertでproductionでもいける

How Do We Get Along With Static Types

@FUJI Goro https://speakerdeck.com/gfx/how-do-we-get-along-with-static-types

  • JSの資産を使うのが難しい
  • 型定義ファイルが無いとダメ
  • .d.tsを書けばできる。けどそれで生産性は上がってる?

RuntimeJS Playground

@Jacob Groundwater

http://runtimejs.org/ - OS等はすっ飛ばして直接ハードウェアを操作する。