NodeConfEU 2015 で発表してきました。

昨年 NodeConfEU 2014 に行った時に来年は発表しようと思って、それから一年。ちゃんと発表することができました！！

発表資料

CFPがあったのは6月頃で、その頃は Hexi についての話をまとめようとしてたのでその話をしました。

Hexi の話は4月頃にしましたが、割りとアグレッシブな技術を使っていて、http2とかAWS Lambdaとかio.jsとかを積極的に使ってたのでそれを広く浅くという形で紹介してきました。

yosuke-furukawa.hatenablog.com

（いくつかギャグも入れてみたんですけど、滑らなかった訳ですよ。僕だって滑らない発表もできる。）

NodeConfEUとは

Node.js のためのカンファレンス in ヨーロッパ版です。なんだかんだNode.js/JavaScriptのすごい人達が集まるし、コミュニケーションしてるだけでも楽しいです。

こういうサーカスみたいな会場で

f:id:yosuke_furukawa:20150929045659j:plain

こんな感じのバンドが居て

鹿が居たり

f:id:yosuke_furukawa:20150929101658j:plain

鷹が居たり

f:id:yosuke_furukawa:20150929101713j:plain

午前から夕方はがっつり発表があって、

夕方からはワークショップが1-2時間ほど、

終わると懇親会という感じの一日を三日間過ごします。

ホント、アイルランド遠いけどめっちゃおすすめします。

NodeConfEU の面白かった発表

Tessel ♥ Rust

発表資料： slides.com

Node.js の IoT 基盤の一つである Tessel が Rust でも動くよっていう話。 JavaScript は開発者が広くいる言語としては有名だけど、IoTでやるには低レイヤな層も触れる必要があって、そのレイヤをちゃんと触りつつ高速に動くのにRustはすごくよかったという話をしてくれました。

f:id:yosuke_furukawa:20150929102612p:plain

Contributing to Node Core

f:id:yosuke_furukawa:20150929103317j:plain

発表資料：なし

TCメンバーの一人であるFishrockの発表。どうやってNode.jsのTCメンバーになったのか、という話ですごく良かった。

簡単に言うと、最初はNode.js のコアコミッターじゃなかったけど、IRCで質問に応えたり、issueを直したり、PRをreviewしている内にその功績が認められてTCになったという、サクセス・ストーリーだった。

Node core は exclusive club じゃなく、誰でもコントリビュートできるように敷居を下げてる、だからコントリビュートして欲しいという話がすごく良かった。

（そこにいる Yosuke も lint tool 直したりしてくれてるんだぜって紹介してくれて嬉しかった）

visulator

発表資料：Introduction | visulator

デモ：visulator

Assemblyの動きをJavaScriptで可視化するツール、ちょうどこの時 Linux カーネル輪読会を社内でやってたから、動きも含めて勉強になった。
レジスタがどう動くのかが JS で emulateされていて、面白かった。

NodeConf EU まとめ

他にも色んな話聞いてきたんですが、その話は今度の10/8に行われる Node学園18時限目で話します！

nodejs.connpass.com

とりあえずまとめると、

  • IoTめっちゃ多い。Webアプリの発表をしてたのは僕とあと２人位で、IoTは5人くらい発表してた。
  • JavaScript でアッセンブリを作っちゃったり、p2pでライブ・ストリーミングしたりする Mad Science の人が多くて面白かった。
  • あとめっちゃenterpriseが多くなった、IBM/Groupon とかの大企業での採用が多くて話もそっち側にシフトしつつある印象だった。

JavaScriptで何かを作るときにWeb アプリは完全にサブセットでしかなくて、IoTだったり、ウェブサーバではない別なサーバを作ったりする人が多くなった。本当に面白い話が多かった。

Node学園祭でも色んな話を聞きたいので、是非みんなの発表お待ちしています！！！！

nodefest.jp


goo.gl

ISUCON5 についての感想

僕がやったのは単純に users とかを Redis に置き換えるっていう処理とユーザーカウントしてるところを改善したりしてました。最後は11600点くらいかな。

bundle install とかも満足に分かっていない状態だったのでほんとチームのみんなにはすいませんとしか言えないですが、SQLをガツッとhokacchaが改善してくれたり、hakobera さんがインフラ周りを面倒見てくれたりしたので、前回よりはなんとなく良かったかなと思ってます。

そんな一朝一夕でポーティングできる規模のアプリじゃないのは参加者全員わかってるはず！！ (>_<)

Node.js v4.0.0 がリリースされました。

NodeConfEUに行ってたりして完全にブログにするのが送れましたが、 Node.js v4.0.0 がリリースされました。
f:id:yosuke_furukawa:20150918025348p:plain


https://nodejs.org/download/release/v4.0.0/

Node v4.0.0 (Stable) | Node.js


個人的には今年ずっとNode.js と io.js をまとめてきたり、時に中の人としてpatchを送ったりしてきたので本当に思い入れの深いリリースです。今までで一番リリースの思い入れが深いですね。

何が変わったのか

何回かこのブログで触れてますが、一番変わったのは開発体制と開発方法です。YAPCの発表でも触れましたが、BDFL (優しい終身の独裁者)モデルではなくなり、技術委員会によってけん引するモデルに変わりました。

体制が整った事で、今までよりかなりちゃんとPRはレビューされるようになりましたし、テストも不安定なテストが見直されたり、追加されたりすることで安定性が向上しました。

今、Node.js には44名のアクティブなコラボレータが存在します。V8の中の動きに詳しい人もいれば、大津さんみたいなcrypto/tls周りのスペシャリストも居ます。彼らがちゃんとPRをレビューしてくれるのでpatchを送るだけでもかなり手厚い体制ができています。

そういう意味ではこの Node.js v4.0.0 は今までで一番安定したバージョンであると言えるのではないでしょうか。

もちろん安定しているとは言ってもバグは存在する可能性はあります。ただバグがあった場合も週次に次のバージョンがリリースされるため、これまでよりも修正されるスピードは速くなります。

機能的な差

おそらく Node.js v0.12 と v4.0 の差が気になるところだと思います。数えきれない程の差分があります。これをまとめる機会はまた別にあるので、そこで記述します。

どうしても気になる方は僕の記事のこれまでまとめたものをざっと眺めて貰えればと思います。

yosuke-furukawa.hatenablog.com

yosuke-furukawa.hatenablog.com

yosuke-furukawa.hatenablog.com


ここでは io.js v3.x から Node.js v4.0.0 までに入った機能について解説します。

ES6

Arrow 関数がデフォルトで利用可能になる

Arrow関数が追加されました。これまでは--harmony-arrow-functions と付ける必要がありましたが、これからは不要です。

'use strict';

// arrow funcs
setTimeout(()=>{
  console.log('foo');
}, 1000);

// Array examples 
const array = [1,2,3,4].map((i) => i*i);
array.forEach((i)=>{
  console.log(i); // 1, 4, 9, 16
});
Object.assign が使えるようになる

オブジェクト間のマージを行うためのメソッド、 Object.assign が使えるようになりました。
これまでは --harmony-object で有効でしたがこれからはフラグ無しで使えます。

js-next.hatenablog.com

var sym = Symbol()

var obj1 = {
 "str": 1,
}

var obj2 = {
 "str": 2,
 [sym]: 2 
}

var obj3 = Object.assign( obj1, obj2 )


console.log( obj1 == obj3 )      // true
console.log( obj1["str"] == 2 )  // true
console.log( obj1[ sym ] == 2 )  // true

// コンストラクタにまとめてアサイン
class Cat {
  constructor( name, age, color ) {
    Object.assign( this, { name, age, color } )
  }
}

var tama = new Cat( 'タマ', 9, '桃' )

console.log( tama.name == 'タマ' )  // true
SharedArrayBuffer が --harmony-sharedarraybuffer オプションで有効になる

SharedArrayBuffer は ArrayBuffer を worker 間で共有して扱うための新しいAPIです。

ただし、Node.jsには今のところ Worker を作るための仕組みが備わっていません。残念ながら Node.js の中では SharedArrayBuffer は単なる ArrayBuffer と変わりません。

なので今はまだNode.jsではテスト位でしか役に立ちませんが、一応Node.jsでもAPIを使うことはできます。

詳細： http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html

基本的に WebWorker に代表される Worker は shared nothing、 つまりメモリを共有せず、値をコピーしてpostMessageなどでWorker間で協調しながら値を共有してきました。

このやり方はシンプルですが、コピーせずWorker 間でメモリを共有できたほうが効率的です（もちろん共有するな協調せよという考え方もあります）。

また　SharedArrayBuffer を扱うためにはWorker間でのリソースの競合を防ぐ必要があります。これを可能にするために入っているのが Atomic API です。こちらは --harmony-atomics で有効になります。

SharedArrayBufferで作った配列に対して Atomic な操作を提供します。配列に対してadd/sub/and/or等の操作をする際に他のWorkerが操作していないか確認しロックを取る仕組みになっています。仕様によれば、futexの仕組みを使ってロックを取ると記述があります。

こんな感じで使います。

// SharedArrayBuffer and Atomics
// use flag --harmony-sharedarraybuffer --harmony-atomics

var sab = new SharedArrayBuffer(4); // SharedArrayBufferを作る
var uint8Array = new Uint8Array(sab); // Integer Shared Typed Array になる
for (i = 0; i < 4; i++) {
  uint8Array[i] = i;
}

uint8Array.forEach((x) => console.log(x)); // 0, 1, 2, 3

Atomics.add(uint8Array, 2, 10); // index 2 に 10 を足す
Atomics.sub(uint8Array, 3, 3); // index 3 から 3 を引く
Atomics.compareExchange(uint8Array, 0, 0, 1); // index 0 が 0 なら 1 にする
uint8Array.forEach((x) => console.log(x)); // 1, 1, 12, 0

console.log(Atomics.load(uint8Array, 2)); // 12 index 2 の値を get する
console.log(Atomics.store(uint8Array, 2, 19)); // 19 index 2 の値を19に書き換えて書き換えた値をgetする
uint8Array.forEach((x) => console.log(x)); // 1, 1, 19, 0

Intl オブジェクトがオプション付き有効になる。 (v3.1.0〜)

build オプションとして '--with-intl' が追加され、それを使ってビルドすると 国際化のためのBuilt-in ObjectであるIntl オブジェクトが有効になります。いわゆる ECMAScript 402 用のオブジェクトが使えるようになります。

$ ./configure --with-intl=full-icu --download=all
$ make
$ make install

Intl オブジェクトを使うと言語ロケールに依存した文字列比較、日付フォーマット、数値フォーマットを行うことが出来るようになります。

ECMAScript Internationalization API Specification – ECMA-402 Edition 1.0

developer.mozilla.org

// 文字列比較系

console.log(new Intl.Collator('ja', {
  sensitivity: 'base'  // 文字の派生系を同値と見なします、カタカナとひらがなの区別もつけません Ex. か == が , ぴ == ヒ, あ != い
}).compare('ハハ', 'パパ'));  // 0 つまり同値

console.log(new Intl.Collator('ja', {
  sensitivity: 'accent'  // 文字で発音が同じものを同値と見なします base の中で派生系は不等という指定です Ex. は == ハ , ぴ != ひ, あ != い
}).compare('ハハ', 'はは'));  // 0 つまり同値

console.log(new Intl.Collator('ja', { 
  sensitivity: 'accent', 
  ignorePunctuation: true // 句読点を無視するかどうか、デフォルトはfalse 
}).compare('わたしは、Lです', 'わたしはLです')); // 0 つまり同値

// 日付フォーマット系

var date = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
console.log(new Intl.DateTimeFormat('en').format(date)); // 12/20/2012
console.log(new Intl.DateTimeFormat('ja').format(date)); // 2012/12/20
console.log(new Intl.DateTimeFormat('ja-JP-u-ca-japanese').format(date)); // 平成24/12/20

// 数値フォーマット系
console.log(new Intl.NumberFormat('en').format(10000000)); // 10,000,000
console.log(new Intl.NumberFormat('ja', {style: 'currency', currency: 'JPY'}).format(10000000)); //￥10,000,000
console.log(new Intl.NumberFormat('en', {style: 'percent', }).format(0.230232)); // 23.023%

--tls-cipher-list というデフォルトの暗号化方式を変更する事ができるオプションが付く (v3.2.0〜)

暗号化方式をデフォルトの一覧から変更することができるオプションが付くようになりました。
例えばこれで使わない暗号強度の弱いものをデフォルトから省くといった事が可能になります。

これ自身は Node.js v0.12 には入っていたものの、 io.js には取り込まれていなかったもので、追加されることになりました。

$ node --tls-cipher-list="ECDHE-RSA-AES128-GCM-SHA256:!RC4"

こうすることで自分でデフォルトの暗号化リストを制限することができます。

--link-module という configure オプションが追加される (v3.3.0〜)

configure のオプションとしてNode.js内部にユーザーモジュールをbuilt-inすることができる、 --link-module オプションが付くようになりました。

背景として、 io.js v3.0や Node.js v4.0 は private モジュールを極力呼べないように外からは隠ぺいするようになりました（言い方を変えると今までは呼べました）。privateモジュールはリファクタリングされる事が多いので、semver上それらが使われてしまう事は好ましくありません。モジュールの安定性を求め、隠蔽されたので、privateモジュールは呼べなくなってしまいました。

そのため、内部モジュールを使って無理矢理ライブラリを作成するような事はできませんが、その代わりビルドオプションの--link-moduleでコアの一部に無理矢理自分のモジュールを入れることはできます。そうすると、コア内に自分のモジュールが組み込まれることになるため、内部メソッドを使う事も可能になります。ただし、通常のユーザーに取ってみればこれを必要とするケースは極わずかだと思います。コアの拡張を一旦試すようなNode.js コントリビュータもしくは Node.js の fork を作ってコアを拡張するような人達、はたまたどうしても内部のメソッドを呼びたい人達が使うオプションです。

# cat test.js 
# console.log('hello world');
$ ./configure --link-module test.js
$ make
$ make install
$ node -e "require('test')" // hello world

Node.js v4.0.0 の性能面

もう一つ性能的な面でも改善されています。Node.js v0.12 と io.js v3.3 、 Node.js v4.0 のそれぞれでベンチマーク比較をしてくれているサイトがあるので紹介します。

https://raygun.io/blog/wp-content/uploads/2015/09/Screenshot-2015-09-09-16.01.51.png

raygun.io


このグラフは Benchmark 厨の Raygun というサイトのものです。 Express のアプリを作ってそれぞれどれくらい性能が上がったかを示したものです。このサイトによれば、 Node.js v0.12 と比較して 8% ほど改善しています。

f:id:yosuke_furukawa:20150918025958p:plain

もう一つ、 Daniel Khan という僕と同じくエヴァンジェリストの一人が計測したデータです、こちらでも高速化されてることがわかります。

apmblog.dynatrace.com


f:id:yosuke_furukawa:20150918030135p:plain

さらに高速化されてるだけじゃなくてメモリ消費量も下がっています。
今回から http_parser がバージョンアップし、性能改善されたため、高速化されたこと、またv8の改善やBuffer API がリファクタリングされたことの影響を受けてメモリ使用量にも影響を受けるようになりました。

Node.js v4.0.0 まとめ

基本的に大きな機能変更は v3.0.0 の時と変わりません。 v3.0.0 + Node.js v0.12 の差分 が v4.0.0 です。

機能的な面をおさらいすると

  • ES6強化 Arrow 関数 / Object.assign / SharedArrayBuffer
  • Intl オブジェクトが使えるようになる
  • 自分のモジュールを内部のコアに組み込めるようになる

性能的には

  • http_parser 改善により、 express などのライブラリを通して 8% 以上の改善
  • v8 のバージョンアップ、Buffer リファクタによるメモリ改善

などが見られます。この他にもたくさん機能はありますが、一旦ここまで。

YAPC::ASIA 2015で「どうしてこうなった？ Node.jsとio.jsの分裂と統合の行方。これからどう進化していくのか？」というタイトルで発表してきた。

YAPC::ASIA 2015 でスピーカーとして参加してきました。

2014年に一度スポンサーセッションでトークしましたが、2015年はCFPを出しつつスピーカーとして参加してきました。自分がNode学園のオーガナイザーになってみてわかりますが、YAPCの規模で毎年カンファレンスを続けるのは本当にすごい。スタッフ含めておもてなしと手際の良さが表れていて、素晴らしかった。

あと発表者としては、今回のYAPCの参加者はかなり積極的に質問してきていて、いつもよりも参加してる人達の"質問してやろう"っていう意向が強くて活発な議論ができたかと思います。すごく良かったです。

発表内容

発表の内容は Node.js の歴史と今のNode.jsの開発体制の話、さらに今後のNode v4.0 の話を中心的に話してきました。

Node.js は Ryan Dahl によるBDFL（優しい終身の独裁者）の開発体制で始まり、 io.js になってTC（技術委員会）による合議制モデルの開発体制にシフトしました。往々にして OSS の開発体制はBDFLによる統治制が多いのですが、Apache を初めとして TC による体制もあります。

本質的で良い質問だなと思ったんですが、うまく回答できなかった質問に

BDFLモデルとTCモデルのどっちがいいんですか？

っていう質問がありました。聞かれた時はうまく答えられなかったので、ここで補足しておきます。


どっちがいいかは正直わかりません。ただ国家の統治制もそうだと思うんですが、独裁体制の方が合議制より効率が良いし、その人の哲学に沿うようになるので、コードとして見た時には「哲学に沿わないようなコードは入らないだろうな」とか、「この機能は入れるけどこの機能は入れない」みたいな機能の決定がすっきりするだろうなと思います。

ただある程度成熟してくると、独裁による決定よりもコミュニティ全体の決定の方が優先するべき時もあります。コミュニティの意見を聞かなくなってしまうとコミュニティが離れてしまい、OSSとして良い方向にならないからです。そういう意味では一人の人が決めるよりも効率を犠牲にした上で色んな意見を聞いて合議制で決める方が良い時もあります。

最終的にどっちがいいのかはよく分かりません。ただNode.jsは既にサーバーサイドのJavaScriptでも無ければビルドツールでもなくて、クライアントアプリケーションだったり、AWS Lambdaにも使われてたり、IoTとしても使われています。さらに言えば企業からも利用されているので蓋を開けてみればものすごくたくさんの人達から使われていて、このコミュニティ、エコシステムこそがNode.jsと言えるものになっています。

その人達が選択したのが今のTCモデルです。io.js発起人のMikeal Rogersは何度も意見を聞いて、何度もコミュニティにどちらがいいかのvoteをお願いしてきました。
僕としてもコミュニティを主軸とした今回のTCモデルには賛成です。

今後のNode.jsでは、コアはシンプルでExtensibleなすっきりしたものになるでしょう。その代わりnpmモジュールを起点としてユーザーランドの自由を増やしています。逆に言えばnpmやコミュニティの支援がないとコアのNode.js単体ではアプリを書くのが難しくなると思います。Node.jsはそういう方向を選びました。

和田さんと話した時

ちょうど僕の発表の後で和田さんがブログに起こしたエントリが素晴らしくて、これもOSSを育てるためにはどうしたらいいかっていう話だと思います。

t-wada.hatenablog.jp


YAPCのあとで和田さんと飲んだ時に「どうやって盛り上がってる感を出しつつ、コアのコードの洗練された形を保つか」っていう議論がありました。

盛り上がっている感を出す方法はいくつもあって、ひとつはプラグインみたいな形でextensibleな余地を残しておくこと、もうひとつは今のNode.jsがやってるみたいにEvangelismやlocalizationも含めて一つのコントリビューションとみなしてそれぞれに役割と責任を与えてあげることかなと思います。(ちょうど僕がEvangelistというラベルを与えられたことで他のカンファレンス (YAPC) でも話すようになったように。)

extensibleな余地があるとコアを直接いじる以外にも参加する人達が増えてきて、結果的にロックスターが出てきたりして、さらに盛り上がるかと思います。(ただまぁ、そういうextensibleな設計が難しいというのは同意です。)

YAPCお疲れ様でした。

スタッフ、参加者、登壇者の皆さん本当にお疲れ様でした。まさに10年間の集大成という感じでした。
参考にできそうな話は山ほどあったし、カンファレンスの運営スタイルも参考にします。

YAPC::Asia 2015 で Node.js のこれからの話をします。 #yapcasia

さてさて、本当にNode.js と io.js の話も大詰めになってきました。

今年は io.js オジサンとしてそれこそサンフランシスコに行ったり、発表や講演も多数行ってきました。
io.jsの中の人になれたり、Evangelistとして認定されたりしました。

io.jsというプロダクトはあと一ヶ月か二ヶ月程で終わりを迎えるでしょう。既にリポジトリはio.jsではなく、Node.jsに変わりました。
これからは io.js が新しいNode.jsとして動いていきます。

www.publickey1.jp

publickeyにも書いてあるとおりです、日付が9月になるかどうかはまだ実は不透明ですが、この位のスケジュール感で今動いています。

f:id:yosuke_furukawa:20150821090759p:plain

この io.js の活動の始まりと終わり、whyを理解してもらいたいと思うし、 OSSのケーススタディとしても面白い話になるかなと思っています。
あと願わくば新しいNode.jsを使ってみてほしいなと思っています。

以下の様な ToC で語る予定です。是非興味がある方は8/22(土) の朝10:00 に Track B まで来てくださいー！！！

Past
  Node.js 成り立ち
  Joyent と Node.js
  BDFL モデルの限界
Present
  Node.jsの開発の停滞
  io.js の台頭と成長
  Node Foundation
  BDFLモデルからTCモデルへ
  Open Governance / SemVer
Future
  Node.js + io.js => The Future of Node
  LTS
  Node.jsの今後とこれから
Free Talk
  TCメンバーである大津さんとトーク
  なんで僕らはNode.jsを選んだのか
  Node.jsの開発スタイル/Node.jsの今後どうなるか予測
  会場からも質問受け付け

io.js v3.0.0 がリリースされました。

io.js v3.0.0. がリリースされました。めでたい！

f:id:yosuke_furukawa:20150807002243p:plain
iojs.org


さらにめでたいことに、次のv4.0.0リリースはとうとうお待ちかねの Node.js との converged されたバージョンになります。

既にコアメンバーは v4.0.0 のリリースに向けて動き出しています。
今回の v3.0.0 は v4.0.0 、つまり converged される Node.js のアルファ版という位置づけです。

v2.0.0 から v3.0.0 がリリースされるまでに作られた機能を振り返っていきましょう。

--trace-sync-io オプションが追加される (v2.1.0)

--trace-sync-io オプションが追加されました。これは、fs.readFileSyncやexistSync といった 同期的に動作するコードを見つけてwarnings を出すオプションです。

Nodeに慣れていない人がうっかり同期のコードを書いてしまった時などに使います。もちろん、Syncのメソッドも使いどころは沢山あるので、慣れている人は今更かもしれませんが、チームで開発していて習熟度に差がある時などは便利です。

単純にwarnings を出すのではなく、tickが回ってから出るような仕組みになっているのでトップレベルで取った時には出ない。非同期実行中に同期を混ぜると出るような作りになっている。

const fs = require('fs');
const data = fs.readFileSync('file.js'); // ここじゃ警告は出ない
console.log(data.toString());
fs.readFile('file.js', function(err, data){
  fs.writeFileSync('file.js', data.toString()); // NG ここでは警告が出る
  console.log(data.toString());
});

WARNING: Detected use of sync API
    at fs.openSync (fs.js:549:18)
    at fs.writeFileSync (fs.js:1155:15)
    at /private/tmp/test/file.js:3:6
WARNING: Detected use of sync API
    at fs.writeSync (fs.js:663:20)
    at fs.writeFileSync (fs.js:1164:24)
    at /private/tmp/test/file.js:3:6
WARNING: Detected use of sync API
    at fs.closeSync (fs.js:518:18)
    at fs.writeFileSync (fs.js:1172:8)
    at /private/tmp/test/file.js:3:6

requireの高速化 (v2.2.0)

requireが内部的にfs.statSyncとfs.readFileSyncを使ってファイル読み込みを頻繁に行っていた箇所を特定し、性能を改善しました。これにより、requireが50倍高速になりました。

fs.statSyncやfs.readFileSyncは中でエラーオブジェクトやStatオブジェクトをメモリ中に持つんですが、メモリ中に持っても requireの時はエラーを無視して別なパスを探索する事が多いので実装上に無駄が多く、またGCフレンドリーでもないという話で内部的にエラーやオブジェクトを保持しないメソッドが作成され、それを使って高速化されました。

https://github.com/nodejs/io.js/pull/1801

os.homedir メソッドの追加 (v2.3.0)

osのホームディレクトリを返すためのメソッドが追加されました。

const os = require('os');
console.log(os.homedir()); // /User/yosuke

Buffer が TypedArray で再実装される (v3.0.0)

Node.js の至るところで使われている Buffer オブジェクトがこれまで独自機構で作成されていたものが TypedArray で再実装されました。これは v8 で使っていたAPIが消えたことの影響を受けて修正されたものです。これに伴い、 Buffer の コンストラクタ関数に TypedArray がそのまま受け付けられるようになりました。

const Buffer = require('buffer').Buffer;
const ab = new ArrayBuffer(16);
var buf = new Buffer(ab); // Buffer constructor accepts ArrayBuffer.

console.log(buf instanceof Uint8Array); // true
console.log(buf instanceof Buffer); // true

buf.writeUInt32BE(0x61626364, 0);

console.log(buf.toString()); //abcd

unicode 文字列 (v3.0.0)

ES2015の unicode escapedな文字列が許可されるようになりました。これでunicode文字を \u{xxxxx} で表現できるようになります。

console.log('\u{1F363}'); // 🍣
console.log('\u{1F4A1}'); // 💡

これでサロゲートペアの表現でわざわざ2文字として扱う必要がなくなります。

console.log('\uD867\uDE3D'); // 𩸽 (ES5で表現)
console.log('\u{29E3D}'); // 𩸽 (ES6から)

他にも色々あるので、今まとめています。

詳しくは以下のリンクを参照のこと。

https://github.com/yosuke-furukawa/iojs-new-features/pulls
https://github.com/nodejs/io.js/blob/master/CHANGELOG.md#2015-08-04-version-300-rvagg
https://github.com/nodejs/io.js/wiki/Breaking-Changes#300-from-2x

余談ですが

今、 io.js collaborators summit のためにSanFranciscoに来ています。 今から行ってきます！

github.com

NodeConf Adventure 2015 に行ってきました。（三日目、四日目に起きたこと）

さて、三日目と四日目に起きたことを書いていくよ！

三日目も同様にアンカンファレンス形式でスタート

f:id:yosuke_furukawa:20150613094556j:plain

ホワイトボード見てもらって分かるかもしれないけど、 Diversity, Documentation, JS Modules, Streams, FrontEnd Packaging, Error Handling などが三日目の議題だった。

JS Modules の話

bower 使ったり jspm 使ったり、 はたまた npm + browserify 使ったりと戦国時代状態のフロントのパッケージモジュールに何使うべきかっていうディスカッション。まだみんないろいろ試してる感じだったけど、 npm + browserify と monolithic な JS library の相性が悪くて、どうするべきかっていう話が一番面白かった。

というわけで、全体のエコシステムは npm + browserify とか npm + jspm に向きつつも、 jQuery ライクな monolithic な ライブラリーはやめて unix philosophy な小さいライブラリを作っていくのが常套手段という感じだった。

ただ誰も WebComponents の話をしてなくて、 ES6 modules とか browserify の話は出てくるけど、 WebComponents で ページのコンポーネントを作るという考え方も本来はあるはず。CSSもそのパッケージモジュールに載せたいっていう話が多かったけど、NodeConfでは誰もWebComponents の話はしてなかったのが気になった。

Error ハンドリング

Node.js のエラーハンドリングという普遍的なテーマについての議論、 domains についての話と zone っていう strongloop 製のライブラリの紹介がメインだった。domains があまり使えないっていう話は mozaic.fm でもしたけど、ここでも同じ議論。

Zoneの話、面白くて色々見てたら Dart にも Angular にも同様の機能があったりして、ちゃんとやってみてもいいかもって思った。

中身の構造を見てみると domain とすごくコンセプトは似ているんだけど、全く違った実装で作られていて、 zone によって限定された範囲をトラップするためにsetImmediate/setTimeout を拡張したり割りと global を拡張してるので、すごい力技で実装されていた（この力技のところが逆に受け入れがたい印象も受けた）。

あと、『そもそも例外が上がった時点で終わりだろ、本当にやばい時以外、例外上げるべきじゃない』っていう議論もあった。

Interview with @bad_at_math

DeNA SF に転籍した bad_at_math さんこと、篠崎さんとエラー/例外の話をした（日本語）。

俺： 「例外が上がった時点で終わりっていうのってどうなんですかね、ちょっとそうも行かない気が」
BAM：「まぁでもある程度わかるかなぁ、本当にやばい時じゃないとそういう時に陥らないように設計してる」
俺：「例えばmysql へのアクセスでたまたま接続不良で例外上がったりしますよね、そういう時どうするんですか」
BAM：「例外の中にも種類があって、絶対復旧不可能な奴とリトライで対処可能な奴でいくつか種類がある。この中でも絶対復旧不可能な奴は本当の例外として扱うべきで、こういう時はアプリケーションのプロセスが生きててもしょうがないからそういう例外が上がった時点で終わりっていうのは分かる。」
BAM：「一方で一時的な接続不良みたいな奴はリトライしたら大丈夫っていうパターンが多いからそういうのはプロセス終わりにしない、ちゃんとMySQL で言うと戻り値のエラーの種類を見分けてどうするのか決めてる。」
※ エラーの種類一覧 http://dev.mysql.com/doc/refman/5.6/en/error-types.html
俺：「なるほど、ミドルウェアのドライバーから上がった例外をちゃんと適切にハンドリングできているの初めて知ったかもしれないです。domainとかは使ってます？」
BAM：「domainかなり助けられるケースが少ないんだよね。ほぼほぼ使ってない」

最後に (Ex含む)DeNA チームでパシャリ
f:id:yosuke_furukawa:20150703021856p:plain

Diversity の話

この話が NodeConf 行ってきた中で一番面白かった Diversity の話。
Diversity っていうのは "多様性" っていう意味で、どうやって多様性を認める文化にするかっていうコミュニティ運営の話だった。

技術的な話というよりは本当に運営の話で、OSSというかインターネットのコミュニケーションは相手の顔が見えないとちょっと語気を強めに言う傾向にあって、そういう事がこのコミュニティの中であってはいけないし、どんな人でも発言できるコントリビュートを表明できる必要があるという話だった。

初心者も何年も関わっている人もフラットで平等に扱われるべきだし、間違っても個人の尊厳を深く傷つけるような行動はあってはならない。一人の意見を尊重しようという話。

詳しくはここにまとめてくれている人がいるので詳細を知りたい人は読んでみて欲しい。

Challenging Diversity at NodeConf | The True Entrepreneur Corps


簡単に説明すると、

1. 全員が共通して持っている弱みを把握しよう

他人を犠牲にしてまで自己を過剰に防衛する事をやめよう、という話。
実行可能な批判は受け入れるべきだし、その批判に対して過剰に反応して防衛したり攻撃するのは避けるべき。
常にインプットをコントリビューションの一部として好意的に捉えて維持するのは難しいんだけども、個人の考えを尊重するべきだし、間違っても人のプライドを傷つけるような事があってはいけない。

2. Collaboration > Competition

競争よりも協力。
必ずしも競争が悪ではない、健全な競争は受け入れた方がいい。でも競争が問題をストップさせる事もある、そういう時は議論の視点を元に戻して考えなおすべきだ、という話だった。

3. 模範によって導く

npm には guys jar っていう制度がある。 "Guys" っていう言葉を男女混合のグループを指す意味で使ったら $1 払って jar に入れるっていう制度だ。
（これは opt-in policy なので強制じゃなくて任意参加らしい）

コミュニティのリーダーは率先してそういう模範を示して欲しいという事だ。 guys jar は単なる罰ゲームじゃなくて、率先してそういう事を表明する事で gender の差をちゃんと自覚してみんなを導くという行為。

こういうのは Node にもあってもいいんじゃないかという話が出ていた。
結果として、ドキュメントのための WG ができて、そこでドキュメントに記述していい言葉が決められることになった。

以下がちょっとした例。
ユーザーを指すときの言葉として使っていいものと使っちゃいけないものの例。

OK: "they", "their", "them", "folks", "people", "developers", "cats"
NOT OK: "his", "hers", "him", "her", "guys", "dudes".

github.com

4. 「Ouch」っていう発言を信頼しよう

コミュニティのメンバーが自分の世界とは違った問題を報告したとする、そういう時に無視するべきではない。

例えば npm ユーザーはたまに Windows マシンで npm を使うことの難しさに不平不満を言う事がある。
Windows の問題はしばしば文化的なジョークとして捉えられる事がある。だからこういう Windows の問題は無視されやすい。でもそういうのは起きるべきじゃない。そういうのがずっと積み重なるといつかコミュニティは廃れていく。

npm ではこういう Windows の問題は出来る限り対応しているし、一般的なルールとして、聞く => 聴く => 反応する の順で発言は対応するべきだという話だった。

こういう話が行われているメタなカンファレンスを僕は知らなかったし、この議論はすごくおもしろかった。
僕はローカルコミュニティのリーダーをやって一年になるわけだけど、こういう目線の話をちゃんと自覚して考えたことがなかった。 Diversity の話はちゃんと記憶にとどめて活動していこうと思った。

Performance Monitor Session

パフォーマンスモニタリングのワークショップで、メモリリークの特定とか、 CPU 100% になったときにどこが悪いのかを見つける方法の話だった。

dkhan の話は具体例も多くて面白かったけど、途中から StrongLoop の人が俺たちのやり方紹介するよって言い出して解説が始まったのがすごく面白かった。


Tessel Hack

tessel のワークショップがあったのでそこに参加して色々やってきた。

Tessel 本当に素晴らしくて、レゴブロックみたいにスロットに何か差しこむだけで色んなものを動かすことができて本当に面白かった。
カメラで撮影するだけだったらサクッとできたし、 @maxogden と話した時に Max は自転車に取り付けてずっと風景を撮影させてるとか言ってて、むちゃくちゃ面白そうだった。

この辺は勉強会でも取り扱ってもいいかもなぁと思った。

f:id:yosuke_furukawa:20150705030921p:plain

Tessel, Performance Monitoring の人達とパシャリ

最後のキャンプ

最後のキャンプで NodeFest の話をしてきた。
『NodeFest は 11/7(土) に実施する予定で、場所は渋谷、もしも NodeConf の人達が来てくれたら寿司をおごるよ』って言ったら
みんなが「ワー！！」って拍手してくれた。


本当に色々キャンプとしても面白かったし、色んな話ができてめっちゃ楽しかった。
来年も行けるといいなぁ。