2016-03-27

JavaScriptの文化とleftpadの話とpadStartについて

無駄にラノベみたいに長いタイトル書いちゃったんですが、まぁやっぱり一言くらいは残しておくかと思ったので書きます。長いのでまとめだけでも見てもらえると良いかもしれません。

leftpadの話はかなり大事になっていて、Node.js界隈を中心としてその他のOSSをやっている全体的に話が波及しています。幾つかの記事を読みました。今回はJSの文化と歴史についてちょっとずつ書いていこうかなと思います。

江添さんの話はすごくよくまとまっていて、ネタも含めた上で一番面白い話になっていました、ここで言われている下記の疑問に答えていこうと思います。

もっと憂うべきパッケージがある。isArrayだ。このパッケージは一日88万回もダウンロードされていて、2016年2月だけの一ヶ月間に1800万回もダウンロードされていて、72個ものNPMパッケージが依存している。
isArrayの中身はこうだ。
var toString = {}.toString;

module.exports = Array.isArray || function (arr) {
  return toString.call(arr) == '[object Array]';
};
結局、このコードは本質的にたった一行のコードである。
その他、is-positive-integerという整数が正の整数かどうか判定するパッケージがあるが、これも本質的には4行のコードである。ところが、このパッケージは昨日まで3個もの依存を持っていた（今は0個になっている）
なぜこんなにも多数のパッケージに依存をするのだ？

さて、これは JavaScript エンジニアじゃなければ当然の疑問だと思う。
つまり、『isArray っていう一行のOSSのコードをロードするっていうのはなぜなのか』『なぜこんなにも多数のパッケージに依存するのか』である。

isArray のこれまで

さて、行数に注目する前にisArrayについて深掘りしてみましょう。

昔々に存在していた JavaScript GoodParts という古典がある、これについては今日の JavaScript ではほとんどが過去の knowhow になってしまっているが、昔を知る上では非常に重要だと思う。

www.oreilly.co.jp

JavaScript GoodParts にはなんと Array かどうかをチェックする『 is_array という処理はこう書け』という指南が付いている。
「6.5 配列かどうか」より抜粋

var is_array = function (value) {
    return value &&
        typeof value === 'object' &&
        typeof value.length === 'number' &&
        typeof value.splice === 'function' &&
        !(value.propertyIsEnumerable('length'));
};

つまり、値が存在し、値がtypeof で 'object' と判定され、 length というフィールドが数字であり、 splice メソッドを持っていて、 length が列挙可能なものであれば、それは配列であるというわけだ。ここまで判定しないとちゃんとした配列なのかどうかは 昔のJavaScriptでは分からなかった。

さて、この方法が編み出されてから少し時間が経過してさらにカジュアルなチェックが存在するようになった。それが上に貼っていた、Object.prototype.toString.callメソッドの内容で判定する方法だ。

var is_array = function (arr) {
  return Object.prototype.toString.call(arr) == '[object Array]';
};
is_array(['foo', 'bar', 'buz']); // true

さて、そもそも配列かどうかを判定するのにここまで必要な理由がわからないという指摘もあると思う。現代のブラウザでは上のようなチェックも既に過去のノウハウとなっている。今ECMAScript 5 が実装されているブラウザが手元にあれば、これだけで良い。

Array.isArray(['foo', 'bar', 'buz']); // true

JavaScript GoodParts が出版された頃のブラウザの世界では初期のようなチェックまでやらないといけなかったのかもしれないが、現代のブラウザではだいたいArray.isArrayでのチェックをしておけば大丈夫なはずだ。

JavaScriptでArrayの判定 - 思ったこと

isArray っていう一行のOSSのコードをロードするっていうのはなぜなのか

さて、話を元に戻そう、過去を振り返った結果として、最初は複数行あったコードが時代とともに洗練されていくのが分かったかと思う。実はここに『isArray っていう一行のOSSのコードをロードするっていうのはなぜなのか』と『なぜこんなにも多数のパッケージに依存するのか』の理由が隠れている。

JavaScriptの出自がWebブラウザで主に実装されている、という特性上、クロスブラウザでの対応が求められることが多い、その場合に Array.isArray だけでチェックしていた場合、古いブラウザでは動作しなくなってしまう。

そこで、 isArray ライブラリの出番になる、Array.isArrayが存在するかどうかを調べて、無かったら内部的に Object.prototype.toString.call() でのチェックをする。こういう『foo機能が存在するかどうかを調べて無かったら内部的に代替手段を用意する』事を polyfillと呼んだりponyfillと言ったりする。polyfill/ponyfillの細かい定義はおそらく誰か別な人が書くと思うのでそちらに任せる。

レガシーブラウザも含めた広い環境で動作することが要求されるアプリケーションであったり、Node.js v0.10でも動くことを求められているライブラリで全て polyfill をわざわざ手書きしていたら生産性が落ちてしまうのは想像しやすいと思う。そこで OSSライブラリに頼ってなんとかするような状況になる。

この polyfill を使う文化 こそがJavaScriptでOSSのコードをロードする文化であり、多数のパッケージに依存する原因である。

『たかだか1行とか11行の〜』という話だが、行数自体は関係なく、 polyfill/ponyfill を使って書いていたほうが全体的に整合が取りやすいことが多いから書いていることが多い。もちろん自分でpolyfillを書いたほうがコスト的に安いことも多いので、その場合はわざわざ OSS に頼ったりはしないが、ある程度成熟したpolyfillは自分で書くよりも実績があるのでそれを使っておく方が安心する事も多い。

また、 polyfill というのは言い換えれば『新しい関数が環境に行き渡ったら不要になる』ものだ。

いらなくなったら該当のpolyfillは削除できる。そうして徐々に新しい関数に適用していく事で今日のウェブは急に壊れることなく使えている。

翻って leftpadの話

leftpadが unpublish された件はコミュニケーションのミスや npm の仕様などの不幸が重なった結果発生した事故で、あんまり頻繁に起きるようなことじゃない、とはいえ、かなり大きなニュースになってしまった。もう npm からは今回の反省点も含めてちゃんと声明を出しているので個人的にはnpmの対応には納得している。

The npm Blog — kik, left-pad, and npm

『急に壊れることなく使えている』という話をしたが、今回は不幸が重なって一部のOSSが壊れてしまった。こういう事態を避けたかったら自前で書くほうが良いと言えるだろう、もっと言えば npm に限った話ではなく github であったり bitbucket であったりが急な不幸に見舞われることだって無いとはいえない、それをどうしても避けたいのであれば、もう自分で管理するしか無い気はする。OSSに依存するっていうのはそういう事だと割りきって使っている。

さて、leftpad も isArray と同じようなたった 11行のコードである、頑張れば1行でも書ける。

leftpad のコードがまずいとかそういう話で色々語られてはいたが、確かに愚直にループを回して足していくより今は String.prototype.repeat というメソッドがあるのでそれを使ったほうが綺麗にコードが書けるし、高速である。

paulownia.hatenablog.com

ただ String.prototype.repeat自体が ES2015から新しく定義された関数であり、leftpadのような幅広い環境で動かすような事を目的としたライブラリでは利用できない。最速な実装とは言えないが、単純に書くなら現状維持でも十分問題ないと思われる。

これも ES2015 が十分に行き渡れば中のコードを String.prototype.repeatで書き換えてしまって問題ないはずだ。

padStart の話

話を未来方向に向けるとpadStart/padEnd と呼ばれる仕様が ECMAScript で提案されている。実際のインタフェースはleftpadとは少し違うが下記のように書くことができる。

'hello'.padStart(10); // '     hello'

さらによいニュースとして、実際に v8 では実装が始まっている、ChromeやelectronやNode.jsではこれが使えるようになる事もそんなに先の話ではない。

https://chromium.googlesource.com/v8/v8/+/1a272ba23ec490f73349201c014537c851f3c964

つまりは leftpad のようなコードも時代とともにこう変わっていくだろう。

現在：

function leftpad (str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}
leftpad('hello', 10);

ちょっと先の未来

function leftpad (str, len, ch) {
  str = String(str);
  if (!ch && ch !== 0) ch = ' ';
  return String(ch).repeat(len - str.length) + str;
}
leftpad('hello', 10);

更に先の未来

'hello'.padStart(10);

さて、 leftpad を padStart の polyfill として見た場合には、 isArray と Array.isArray と同じ状況であることがわかると思う。この手の話はたくさんある。

僕はJavaScript というのは我々言語ユーザーと言語仕様策定者が歩みを寄せながら差を埋めつつ育てていくものだと思っている。polyfillだったり、痒いところに手が届くような小さいモジュールを作ってnpmに公開しておく行為は差を埋める一つの手段である。

そういうライブラリが浸透していくことで言語仕様策定者側はユーザーにとって必要な機能がわかる、ライブラリを元に仕様を決めていくための指針ができる。ライブラリを公開/利用するのは無理矢理言ってしまえば未来のJavaScriptへの貢献にもなっている。

まとめ

isArrayの歴史(Goodparts => Object.toString => Array.isArrayの変遷)
leftpad も実際はisArrayと同様
JavaScriptは言語ユーザーと言語使用者が歩みを寄せて差を埋めつつ育てる言語、polyfillもnpmへの公開もそれを使うのも、その差を埋めるための手段

2016-02-29

Developers Summit 2016で非同期処理について話してきました

だいぶ間が空いてしまったんですが、デブサミ 2016 で非同期処理について話してきました。

event.shoeisha.jp

トピックとしてものすごく突出してたので成立するか不安だったのですが、なんとなく結論めいたものはでました。

詳しくは takezoe さんのブログを見て頂けると良いかと思います。

takezoe.hatenablog.com

結論みたいなもの

まぁやっぱり同期処理と非同期処理は『意識して使い分けなくても言語なりフレームワークなりで吸収するようになっていくんじゃないか』というのが1つの結論のような形になった。ES.Nextの async/await はその1つの形だと思う。"意識しないで"というのは難しいが、ほとんど同期処理と変わらない形で書けるようになる。

Node.js は coreの中でも Promise を採用するように只今構想中だし、ユーザーランドの場合はPromiseからの async/await への移行はそこまで難しくないように思える。

ただし、async/awaitやPromiseは所謂単発モノと言われる、一回呼んだら非同期で返ってくるのが基本の処理だ。これでほとんどの処理はまかなえるかもしれないが、一回呼んだだけでは終わらないものも中にはある、時系列的に連続で発生する系の非同期イベントだ。

この『時系列的に連続で発生する類のもの』をどうやって扱うのかというのの1つの解が Stream のような data を chunk として扱って連続的に read / write するタイプの API だったり、さらにそれを抽象化した Rx と呼ばれるライブラリだったりするんだろうと思う。

Stream については Chrome の開発をしている Jake がわかりやすい図を書いてくれているので引用する。

jakearchibald.com

この図はfetchの処理をする時にいっぺんに取得する時とchunk化して少しずつ取得する時の動きの違いをvisualizationしたものだが、わかりやすい違いが見えてるんじゃないかなと思う。

こういう処理をするような場合には非同期処理はさらに一歩先に進み、同期処理とは一線を画するモノになっていくと思う。単発モノの非同期処理を非同期処理レベル1とすると、こういう連続的なイベントを扱わなくてはいけないような非同期処理は非同期処理レベル2とも言える。

レベル1の非同期処理は同期処理とは変わらない形で書けるようになっていくとは思うが、レベル2の非同期処理はそもそも扱っているものの性質がこれまでの同期処理とは違うので『違いを意識しないで書く』というのは難しい気がする。

ただ幸いなことに現実的に今のサーバーサイドではそこまで連続的なイベントを扱うような事は経験上まだ少ない。僕が経験した所で言うと、 socket.io を使ったゲームだったり、いわゆるリアルタイムなウェブアプリを書くっていうような処理をした時に経験したくらいだ。

『サーバーサイドでは』と言及したが、クライアント側では割と頻繁に起きていると思う。クライアント側は非同期処理が複雑化しやすく、例えば Ctrl-x, Ctrl-s で保存するタイプのmarkdown editor を書きたいと思ったらそこそこ複雑なイベントハンドリングを求められる。ただの click イベントで発火するだけの処理を書いてる状況ではなくなっている。

そういう意味ではサーバー側もクライアント側も今後アプリケーションが複雑化してくる事を見越して非同期処理を意識して書いてみるのも良いのではないだろうか。

会場から来た質問

Q. 非同期処理と例外はどうしたらいいのか
A. JavaScript に関して言えば、今はPromiseにくるんで返すというのが一般的になっている、callback の第一引数に error を返してた時代から Promise の catch 関数でキャッチできるようになる時代はもう今来ている。更に進んで async/await になれば try/catch で例外を処理できる時代が来る、そこまで来ればあまり困らないはず。ただし、連続したイベントを扱うようなケースはまたちょっと趣が異なる。

Q. 非同期処理が廃れて同期処理だけで書ける未来は来ないのか
A. なくならないと思われる、昨今のアプリケーションでは外部APIを叩く場合やDBにアクセスする、S3にアクセスするなどのネットワーク経由で処理する事が多い。そのネットワークを経由する際にレイテンシが発生する。そうするとそのレイテンシを愚直に待つよりも非同期処理にして別タスクを実行するほうが効率が良いし、このレイテンシはどんなに速くなったとしても光の速さを超えられないので、どうしても厳しい。

最後にNode.jsの話を

非同期処理がわかりにくいとかそういう話は色々あると思いますが、一回Node.jsやってみるとわりとわかりやすくて良いんじゃないかなと自分では思っています。ステマとかじゃなくて、非同期処理しかないという環境に入れられると否応なくその書き方に慣れます。callback地獄とか言われてるような処理に陥らないように工夫すると上で書いたような話もわかってくるんじゃないかなと。

なので、非同期処理を学びたければ、ぜひ一度Node.jsを！！

2016-01-01

2015年のふりかえり

さて、もう一個の記事です。

本当この一年は振り返っておかないともったいない一年だったので振り返っておきます。

もう2016年になっちゃったけどスルーします。僕が認めるまで2015年です。

考えてみると、Node.js日本ユーザーグループ代表になって２年目です。当初あげていた目標である、海外に向けての意見発信であったり、国際カンファレンスでの発表経験だったり、YAPCやCROSSでの講演と本当に色々経験させてもらいました。

1月

◆ CROSS 2015 で講演（OSSという枠でパネルディスカッション）

2015.cross-party.com

◆ io.js 出たばかりで issue 追ったり PR 出したりしてました。
当初の目的は io.js と Node.js の混乱を少なくとも国内だけは抑えられるようにしようと思っていました。

2月

◆ 東京Node学園祭で io.js について発表

◆ Node.js v0.12 が出たのでサマリをまとめる。
yosuke-furukawa.hatenablog.com

3月

◆ io.js Evangelism WG に入る。この頃から翻訳活動だけじゃなくて、io.js weekly reportをたくさんするようになる。

4月

◆ Hexi をリリースして、 http2study で発表するなど。

◆ NodeSchool Tokyo を主催する。
yosuke-furukawa.hatenablog.com

◆ TowerOfBabel を作って、400 star 稼ぐ。
yosuke-furukawa.hatenablog.com

◆ React meetup で mithril とか mercuryの話をする

5月

◆ isomorphic meetup を開催。
nodejs.connpass.com

◆ io.js v2.0 をまとめつつ、 io.js Collaborator にもなる。
yosuke-furukawa.hatenablog.com

◆ NodeSchool International Day を主催する。
nodejs.connpass.com

6月

◆ ES2015 が制定。 ES6 meetupを開催。
nodejs.connpass.com

◆ StrongModeについて発表

◆ NodeConf Adventure に参加。
yosuke-furukawa.hatenablog.com
yosuke-furukawa.hatenablog.com

7月

◆ gloopsさんの勉強会で Future of Node について発表、

8月

◆ YAPC ASIA で Node.js と io.js の発表をする。

個人的にはかなり大きいカンファレンスでの発表だったので嬉しかった。これまでYAPCは見る側だったので感慨深いです。

◆ io.js v3.0.0 リリースをまとめて解説
yosuke-furukawa.hatenablog.com

◆ io.js collaborators meetup in San Francisco に参加してました。

わいわい！ pic.twitter.com/CkZWrYOAjt
— Yosuke FURUKAWA (@yosuke_furukawa) August 6, 2015

9月

◆ NodeConfEUで発表してきたり！

yosuke-furukawa.hatenablog.com

◆ ISUCON5 参加　アンド　惨敗
yosuke-furukawa.hatenablog.com

◆ Node.js v4.0 リリースそしてまとめ！
yosuke-furukawa.hatenablog.com

10月

◆ Node.js v4.0 の話を東京 Node 学園 18時限目で発表しました。

11月

◆ 東京Node学園祭2015を開催しました。
yosuke-furukawa.hatenablog.com

nodefest.jp

このために半年くらいかけてたので、みんな楽しんでくれて本当報われました。

◆ enjapanさんで国内外で活躍するエンジニア向けに発表してきました。

12月

◆ GTUGGirls に呼ばれて講師をしてきました。
gtuggirls.connpass.com

electronica を作ったのもこの時でした。

◆ NodeSchool Tokyo in leverages
nodejs.connpass.com

◆ JSおじさんで発表してました。

まとめ

総括すると、本当に色々経験させてもらった一年でした。この一年で得たものは大きかったので次の年は絶対にこれを更に大きな経験にしたいと思
います。特に海外での発表経験はすごく良かったので来年も継続していきたいと思います。そのためには再度発表できるクオリティの物を仕込めるようにしていきたいと思います。

また仕事的にも面白い事がたくさんできるようになってきているので、どんどん発表していきますね。

2016年もよろしくお願い致します！！

2015-12-31

electron を学べる workshopper である electronica を作ってみました。

ちょっと最近Fallout4でサンクチュアリを開発するのに忙しすぎてOSS界隈の仕事サボってしまっていたので、31日にして書かないといけない記事が2つほど残っていることに気づきました。

なので、一個をこの場で投下しておきます。

手短に言うと、electronicaというworkshopperを作りました。

github.com

f:id:yosuke_furukawa:20151231222055p:plain

$ npm install electronica -g
$ electronica

で起動します。最初はHello Electron から始まり、最終的に小さなブラウザを作るくらいまでの事をやります。

f:id:yosuke_furukawa:20151231222649p:plain

残念ながら、verifyは動かないので、終わったたら自己判断で次のexerciseをやらないといけないので、まだNodeSchoolで使えるまでは行かないのですが、暇な冬休みにやってみてください。

僕はこの冬休みにはverifyがちゃんと動くようにします。

では次の記事を書きます。

2015-12-01

Node.js へのcontributeの仕方

qiita.com

このエントリは Node.js Adventcalendar の 1 日目のエントリです。

Node.js への contribute の仕方

Node.js の contribute は敷居が高いと思っている人がいるのかあんまり日本人が contribute をしているのを見ることが少ない。もっとコントリビュートする日本人が多くても良いんじゃないかと思っている。

これまでの Node.js では CLA にサインが必要だったりイマイチさくっとコントリビュートができないという問題があったが、 v4 になってからの Node.js はかなりコントリビュートまでの敷居が下がっている。

にも関わらず、少ないのは日本語の記事が少ないことも一つの要因だと感じているのでこれをきっかけにコントリビュートのやり方を抑えてもらって第一歩になるようにしてもらいたい。

Node.js のリポジトリの中身

Node.jsのリポジトリの中は以下の様な感じになっている。

nodejs/node
├── benchmark/
├── lib/
├── src/
├── deps/
├── test/
└── docs/

contributor が修正するのは主に下記の場所だと思っていて良い。

lib/ JavaScript の API が記述されている箇所、最もコミットが多い(と思われる)
src/ C++ で v8 や libuv への依存を直接呼んでいる所
doc/ API の説明が書かれている documentation のためのページ markdown が使われてる
test/ テストコード、最近 不安定なテストを修正しよう運動 が行われていて、ここもホットにコミットがある

この他にも所謂 README.md だったり、 .eslintrc みたいなファイルを修正することはあるけど、基本的にはこのような感じ。

lib/ へのコントリビュート

lib/ が一番コードの変更が多いと書いたがひとえに API に対して変更したいという要求が多いからだとおもう。APIは開発者が直接触れるところなので、そこへの変更は多くなる。

ただし、気をつけなきゃいけないのは、 lib/ の中のAPI を変えるっていう事は互換性に気をつける必要があるという事だ。経験上、互換性を壊すようなコミットはあんまり受け付けてくれない時が多い。互換性を壊す、ということにも色々あって、バグを修正して正しくエラーになる挙動にした結果、それまで無視して無理矢理動いていたコードが動かなくなったという話もあったりする。そもそも正しく動いていなかったが、ちゃんとエラーという挙動になることで互換性が損なわれてしまうという事だ。

こういうので揉めたりすることも勉強になるのでやってみると良いとおもう。疲弊するけどやりがいはある。

また、最近よくあるのがES5からES2015のコード変更だ。これに関してはコントリビュートしやすいし、やりたがる人は多い。ただし、これも気を付けたほうが良い。まだ V8 の JIT が ES2015 に最適化されておらず、愚直に ES5 で書いている方が速いことが多いからだ。

僕は Node.js を ES2015 のモダンなコードスタイルに変えるべく色々と調整してきたが、一番きつかったのは、既存でやってたgoogle-closure-linterをeslintに変える修正だった。

github.com

結局この修正は色んな効果があって、みんながeslintに乗り換えてくれたおかげでtemplate string literalsやoctal literalといった新しい文字を持つES2015のコードもある程度は書けるようになっている。しかしやっぱり class 構文や letといった性能に影響があるものはlib/の中では書けるものの広くは受け入れられていない。

Promiseを返すコードにしてほしいというのも性能の問題が理由で受け入れられていない。Node.js のコアのコードは読みやすさや書きやすさよりも互換性と性能を追い求める傾向にある。

また、『これがあると便利じゃない？』みたいな一見便利に見えるようなコードも受け入れられないことが多い。

github.com

例えば上に挙げたようなconsole.groupみたいなconsole API の拡張だ。これに関してはnpmで困っていないならnpmを使おうと言うのが Node.js のコアメンバーの意向だ。 Node.js のコアのコードはかなりbasic で必要最小限しか入れていない。

LESS IS MORE という言葉がある。これは「より少ないことがより豊かである」という意味の建築家の言葉だが、シンプルに機能を削ぐことでゴテゴテした機能をたくさん持つよりも結果として豊かになるという発想で、これを体現しているのではないかとおもう。なので、一見便利じゃない？みたいなのはコンセプトに合わず、拒否される事が多い。

コアでしかできないこと、コアには必要なことは何なのかを考えてコミットするとPullRequestが受け入れられやすくなると思う。

src/ へのコントリビュート

所謂 C++ レベルでの変更をする時のコントリビュート。ここはV8とかlibuvとかopensslといったライブラリを呼んでいる箇所であり、所謂 Fedor Indutnyや Trevor Norris や Ben Noordhuis や Shigeki Ohtsu といった重鎮が変更する箇所である。

僕はここにコミットしたことはまだない。ただし、コラボレータをやると分かるが lib/ レイヤの変更でできることよりもsrc/レイヤの変更でできることのほうが圧倒的に多い。特にBuffer周りの改善やnet周りの改善系はダイレクトに性能に響いてくるし、tls レイヤのエンハンスは性能とセキュリティというセンシティブな領域を攻めることができる。

Buffer を変更した場合は Trevor Norris, Ben に、 net/httpを変更した場合は Fedor Indutny, Ben に。 tls 周りは Shigeki Ohtsu, Fedor にレビューワーを選んで見てもらうのが良いだろう。

doc/ へのコントリビュート

一番わかり易いコントリビュートといえるだろう。 Node.js はドキュメントがダメだというのはこの前の Node学園祭での NodeDiscussion でも上がっていたが、 document はエコシステムとして周りが作るものなので、ダメだと思うならコントリビュートして欲しい。

docを修正するのが一番簡単で、敷居も低い。

ただ注意点としては、heとかsheみたいなgenderを表すような言葉は使ってはいけないという流れになっている。これはdocumentationにかぎらずだが、一番うっかり書いちゃうのがdoc/へのコントリビュートなので気を付けたほうが良い。

github.com

genderの他には宗教や能力の差、身体的特徴など、とにかく人を不快にさせるような言葉は使ってはいけないとされている。
難しいかとおもうかもしれないが、基本的にはAPI説明だけならそんな内容を書くことは少ないし、割りとチェックもされるので気軽にtypoを見つけてはコミットしたり、ドキュメントの間違いを見つけてはコミットすると良いとおもう。

test/ へのコントリビュート

testへのコントリビュートもまた盛んである。OS によってはコケたり、またタイミングが悪いとコケたりするコードのことを不安定なテスト、 flaky test と呼んでいて、これを撲滅する活動が盛んだからだ。

test フォルダ以下に {フォルダ名}.status という名前のファイルが有り、そこを見るとどれが flaky でどれが flaky じゃないかがわかると思う。

github.com

これを直すとかなり感謝されるし、取り込まれる可能性が最も高いコミットだとおもう。

また、 lib/ や src/ を修正したらほぼ確実に test/ を書くことが求められるので、常に test を書くクセが付くはずだ。

ここをコントリビュートの出発点にして欲しいと Node 学園祭に来た Rod Vagg も懇親会の二次会で言っていたので、間違いないだろう。

コントリビュートの細かい作法

Node.js はコミットする時にコミットメッセージに

<修正するラベル>: <修正タイトル> ※ 80 文字以内
修正した内容

を書く必要がある。Reviewed-By や PR-URL というラベルはマージする人がつけるという決まりになっているので、コラボレータになると習うはずだ。
僕の最近やったコミットではこんな感じになる。

github.com

また、参考までに僕の拙いメモで良ければこういうマージフローになっている。

www.evernote.com

コラボレータになると merge 権限もあるし master への push 権限も持つことになる、一番注意しないといけないのはうっかり master に push しちゃうことだ。とりあえず間違っていてもすぐに直るだろうが、 git の使い方が怪しければこれを機に見直す良い機会になる。

コア以外へのコントリビュート

コア以外のコントリビュートも盛んだ。僕のやってる evangelism とか benchmarking とかはコア以外で貢献できるタイミングだと思う。 evangelism は毎週の変更点やニュースをピックアップして website に載せるという活動だ。 benchmarking はまだあまり進んでいないが、 benchmark フォルダを修正したり、わかりやすくグラフにして見える化するという活動も含まれる。

最近は Node 学園祭とか学園祭をやってる間に溜まったタスクの消化で忙しく、あまりコントリビュートできていないので、是非みんなも参加して欲しい。

あと、翻訳も立派なコントリビュートだ。 Node.js の API の翻訳が古いと言われているのでそろそろ本腰を入れて翻訳活動を再開したいがどうしても時間がない。（やりたいという人達が集まってくれるとやりやすいのだが、、、）

最後に

いろんなことを言ったが、コントリビュートのやり方は様々だ。僕はやるようになって LESS IS MORE という考え方や英語力、またコアメンバーとの信頼等々色んな物を得たので是非みんなもやってもらいたい。もちろんこういうのは強制になるとつまらないので、やりたいという人達が有志でやるのが一番だと思う。

僕も大津さんも協力するので是非 Node.js をエンハンスする活動に参加してもらいたい。

2015-11-11

東京Node学園祭2015を開催しました。

さてさて、東京Node学園祭2015が開催されました。
すごくすごく楽しかったです。午前中から最後の最後までめちゃくちゃ面白かった。

振り返りながらどういうカンファレンスだったのか語っていこうと思います。

アンケート結果

アンケートに回答していただいた皆様、ありがとうございました。反省するべき点も多いので来年にまた活かします。
さて、アンケートでvoteしてもらった結果、参加者の皆さんが選んだコンテンツのトップ5は以下のようになりました。

1. Electroknit! - Pixel to sweater with Node.js by @kosamari
2. "npm": ">=3" by @maybekatz
2. The State of JavaScript by @domenic
4. NodeDiscussion
5. フロントエンドに秩序を取り戻す方法〜はてなブログ編集画面をリニューアルするためにやったこと〜 by @amagitakayoshi
5. 技術文書をソフトウェア開発する話 by @azu_re

Electroknit というJavaScript を使って編み物をする話が一番盛り上がりましたね！トーク内容もさることながら、終わった後のデモで人がめちゃくちゃ群がってたのが印象的でした。

.@kosamari talks about Brooklyn, knitting and JavaScript! #nodefest pic.twitter.com/Ce5W8ucjAx
— Tomomi ❤ Imura (@girlie_mac) November 7, 2015

.@kosamari on stage #nodefest #nodefestA pic.twitter.com/jlmKo1tOsu
— りぃ (@leader22) November 7, 2015

あとは 『npm v3』の話が2位、基調講演の"The State of JavaScript" の話も同票で2位と人気がありました。マルちゃん（@maybekatz）も、domenicも二人共このために呼んだので盛り上がってくれて良かったです。

Npm support for Windows - the team is trying for better user experiences. #nodefest pic.twitter.com/PrW4IrXJH1
— Tomomi ❤ Imura (@girlie_mac) November 7, 2015

.@domenic on the state of JS - exciting stuff is coming as a part of es2015! e.g. JSX-like template strs #nodefest pic.twitter.com/M1OuV33iPt
— Tomomi ❤ Imura (@girlie_mac) November 7, 2015

4位の NodeDiscussion も盛り上がったみたいですね。個人的には一番やりたかったコンテンツだっただけに良かったです。

Node discussion テーマがかなり上がってて少し延長 #nodefest pic.twitter.com/ICbp5tT2cM
— かみやん (@kamiyam) November 7, 2015

5位もなんと同票で『フロントエンドに秩序を取り戻す方法〜はてなブログ編集画面をリニューアルするためにやったこと〜』と『技術文書をソフトウェア開発する話』が獲得しました。片方はフロントエンドのリファクタリングの話（今書いてるはてなブログのフロントエンドの話）ともう片方はtextlintという技術文書のためのLinterの話でした。azuさんの話は前に聞いた時にすごく面白い話だったので直接お願いしただけに上位に上がって良かったです。 amagitakayoshi さんははてなの新卒という事で若くて勢いのある人が出てきてくれて嬉しかったです。

今から話す “技術文書をソフトウェア開発する話”のスライドです。 https://t.co/ABaehmfzK6 #nodefest #nodefestB
— azu (@azu_re) November 7, 2015

#nodefest #nodefestB pic.twitter.com/jESSXSbvFG
— アオヤマミント (@MintoAoyama) November 7, 2015

参加した人の年齢

なんというか参加者は20代が半数を超えてて若いコミュニティだなというのをつくづく思いますね。発表者も若いし、勢いを感じます。
f:id:yosuke_furukawa:20151110132758p:plain

懇親会で学生さんからも声をかけられたしこういう若い人たちが順調にJavaScriptコミュニティの全体を支えていくように新陳代謝が上がるのは素晴らしいなと思っています。

参加した人の職種

なんとWebフロントエンド開発を生業にしている人のがサーバサイド開発よりも多いという特徴が出ました。Node.jsの利用者のほとんどはフロントエンドだし、サーバサイドのためだけじゃないというのは分かっていたけど、おそらく2011年の頃とは全く客層が変わっていると思うので、ここまで来るのはかなり面白いですね。

f:id:yosuke_furukawa:20151110154307p:plain

公開されてるスライド

公開されているスライドはこちらになります。

nodejs.connpass.com

LTや飛び込みLTも含めてスライドが集約されているので見てみてください。

togetter まとめまとめ

聴講者の反応がわかるtogetterのまとめまとめはこちらです。

togetter.com

是非見てみてください。

NodeDiscussion を実施してみた

前回のブログにも書きましたが、今回のNodeDiscussion は挑戦的なコンテンツでした。実際に使っている人達から作っている人達にフィードバックを行う場として用意しました。
実際にはブレインストーミング形式で、Node.jsの良い所、悪い所、wishlistを用意し、それぞれのまとまりを作ってから質問するというコーナーになりました。

yosuke-furukawa.hatenablog.com

.@yosuke_furukawa kicking off the Node Discussion at #nodefest. (@rvagg being serious.) pic.twitter.com/rCwY2Fv1om
— Dan Shaw (@dshaw) November 7, 2015

node discussionというのが始まるぽい。みんなでnodejsの良いところ、悪いところをポストイットで書き出してます。これはWishList www #nodefest #nodefestB pic.twitter.com/ADjTv3eULf
— yositosi (@yositosi) November 7, 2015

Node discussion テーマがかなり上がってて少し延長 #nodefest pic.twitter.com/ICbp5tT2cM
— かみやん (@kamiyam) November 7, 2015

この NodeDiscussion は面白かったと言ってくれる人が多かったのと、特に RodVagg や dshaw から『面白かった。めちゃくちゃいいフィードバックをもらった』と言われたのと、この内容を mikeal や他の core にも見せたいと言ってくれたので、excel か何かでまとめて公開しようかなと思います。すでに画像では上がっているんですが、見やすくしたいのと、QAの結果を載せたいので頑張ります。

最後に

2016年に向けて考えることは多いですが、来年も絶対にやります。コミュニティ全体が大きくなってきているので来年は複数日開催とかも検討しています。
今年来ていただいた皆さん、ありがとうございました！！

2015-11-05

Node.js v5.0 がリリースされました。

Node.js v5.0 がリリースされました！！

今回はどちらかと言うと機能面というより、 Node.js v5.0 の位置づけを中心に解説したいと思います。

機能面も一応載せますが、学園祭前で時間があまり作れないので、さくっと終わらせます。

機能面での変更

ES2015の文法追加

Spread operator が追加

Spread operator が追加されました。

これまで配列をJavaScriptの関数に引数に展開して渡す場合、以下のように記述する必要がありました。

function f(x, y, z) {
  console.log(x);
  console.log(y);
  console.log(z);
}
var args = [0, 1, 2];
f.apply(null, args);

この書き方はあまり直感的じゃなく、また new 演算子と併用できないという問題があったりします。

Spread operator によって Node.js v5.0 からは以下のように記述することができます。

function f(x, y, z) { 
  console.log(x);
  console.log(y);
  console.log(z);
}
var args = [0, 1, 2];
f(...args);

new.target の追加

new.target というのはメタプロパティの一つです。 new 演算子で呼ばれた場合にnew.targetに実行しているオブジェクトのプロパティがbindされます。
これを使うことで、例えばnew で指定されたクラス名をコンストラクタ内から参照することや new 演算子をうっかり付けずにinvokeされたコンストラクト関数をエラーにすることといった事が可能です。

function Foo() {
  // new を付けて呼ばれなかったらエラーにする
  if (!new.target) throw "Fooを呼び出す際はnew演算子を必ず付けてください";
  console.log(new.target.name);
}

Foo(); //エラー： Fooを呼び出す際はnew演算子を必ず付けてください
new Foo(); // Foo

また class の継承などと併用すると以下のようにnew した対象のクラスがコンストラクタから取得できるようになります。

'use strict';
class A {
  constructor() {
    console.log(new.target.name);
  }
}

class B extends A { constructor() { super(); } }

var a = new A(); // "A"
var b = new B(); // "B"

npm v3

Node.js のパッケージマネージャである npm が v2 からv3 にアップグレードされました。

npm v3 に関しての詳細は @watilde さんの資料が詳しいです。

一応概要を説明しておくと

階層を極力 flat に保つようになった
エラー文言などがより親切に
progress barがちゃんと出るようになった

という幾つかのアップデートがあります。とくにflat階層になったのが大きく、flat化される事によってパスが260文字までしか入らない制約を持つ、Windowsフレンドリーなパッケージマネージャになっています。

ALPN サポート

大津さんが ALPN をサポートしてくれました。ALPNとは、 Application layer protocol negotiation の略で、クライアント・サーバ間でプロトコルを利用する際にどのプロトコルを使えるのかを交渉するための処理のことを指します。

これまでは NPN といって、クライアントがサーバーに使えるものを問い合わせて、サーバーが利用可能なプロトコルの一覧をクライアントに返し、そこからクライアントがプロトコルを選ぶ、というやり方しかNode.jsはサポートしていませんでした。

あすのかぜブログにわかりやすい図があったので引用します。

TLS上でのプロトコルネゴシエーションの仕組み、NPNとALPN - あすのかぜ

NPNの図

ALPNでは、クライアントがサーバーに対して最初の交渉の時点で自分が使えるものを渡すことができるようになります。決定権をサーバーが持つようになるといった部分がこれまでとは異なります。

ALPNがサポートされたことでユーザーランドでhttp2やspdy/3を作っているライブラリがALPNを使ってプロトコルを交渉する事ができるようになりました。
tlsでサーバーを作る時に ALPNProtocols オプションを使って指定します。

var tls = require('tls');
var fs = require('fs');

var options = {
  key: fs.readFileSync('server.pem'),
  cert: fs.readFileSync('server.crt'),
  passphrase: 'test',
  rejectUnauthorized: false,
  // ここで指定可能なALPNプロトコルを指定する
  ALPNProtocols: ['http/2', 'spdy/3.1'] 
};

var server = tls.createServer(options, function(socket) {
  // http/2
  console.log(socket.alpnProtocol);
});
server.listen(8000, function() {
  console.log('server bound');
  var client = tls.connect(8000, 'localhost', {
    // Client側からServer側に交渉
    ALPNProtocols: ['http/2'],
    rejectUnauthorized: false
  }, function(){
    // 交渉が成立するとココで http/2 になる
    // 交渉不成立だと false になる
    console.log(client.alpnProtocol);
  }); 
});

そのほか変更点

console.timeがミリ秒よりも細かい精度に対応

github.com

console.time('100-elements');
for (var i = 0; i < 100; i++) {
  ;
}
console.timeEnd('100-elements');
// 100-elements: 225.438ms
// 今までは225msまでしか出なかった(内部でDate.nowを使っていたため)。

deprecated / removed

これまで長らくdeprecatedだった機能がこのメジャーバージョンアップを機会に消えたり、新たにdeprecatedになった機能が増えたりしています。

github.com
github.com
github.com
github.com

使っていたところでエラーが出るような機能だったり、deprecatedになってもう何年もたつような物が対象なので消えても困るような人は少ないと思いますが、一応注意してください。

バージョンについて

今回 Node.js v5.0 (Stable) というラベルがついています。 Stable というラベルが付いていますが、以前のNode.jsのバージョンは Node.js v4.0 (LTS Argon) という風に LTS ラベルとArgonという名前がついています。

Stable と LTS の違い

さて、ここが今回の話の目玉です。

v0.12までのNode.jsは奇数の開発バージョン(v0.11)、偶数の安定バージョンがあり(v0.12, v0.10)、偶数の安定バージョンを最新を含む2バージョンまでサポートするという形式をとっていました（v0.12とv0.10のみサポート等）。これはセキュリティパッチや明らかなバグがあれば下位バージョンであるv0.10にback portして提供することを意味しています。

逆に言うと、新しい偶数の安定バージョンが出た(v0.14)場合、古い安定バージョン(v0.10)はその時点でサポートされなくなります。これが今までのNode.jsの中で痛みを伴う部分でした。リリーススケジュールが明確じゃないのでNode.jsの新しいバージョンが出るタイミングがわからず、Node.jsのアップグレードする人は常に頭を悩ませるような状態でした。

今回、Long Term Support(LTS)の仕組みができました。これは長期サポートといって、リリースしてから2年半は確実にメンテナンスを行うというサポートポリシーです。これによって、アップグレードは必ず2年半単位で実施する必要ができています。サポートポリシーができたことによって開発者がアップグレード計画を立てやすくなるという効果を狙っています。

このLTSにはバージョンとは違ってLTSであることを表すための識別名が付きます、それがArgonです。識別名は元素名なので、次は Boron とか次の次は Carbon なんじゃないかと推測できます。

ただ全てのバージョンをLTSとして扱うとサポートする側が大変になるのでやりません。基本的に3つまでしかLTSとなるバージョンは存在しません。今で言えば、v0.10, v0.12, v4.x です。

f:id:yosuke_furukawa:20151105173736p:plain

次に出るLTSがv6なのかは実は決まっていません。よく偶数バージョンがLTSで奇数バージョンがStableという書かれ方をしている記事を見ますが、そのルールがこれからもずっと継続するのかは個人的には疑問です。

確実に決まっているのは、2016-10-01 で v0.10 のサポートが切れ、そのタイミングでリリースされるであろうバージョンが次のLTS対象になる、というのが正しい見解だと思っています。なので、上の表でも次のLTSにはバージョン番号の記述はされておらず、 v.Nextとしか書かれていません。

つまり、偶数バージョン = LTSではなく、 Argon, Boron などの LTS 識別名が付いているもの = LTS です。
バージョンはあくまでsemverにしたがって上がります。LTSとバージョン番号に直接の関係はあまりないと思ったほうが後々奇数バージョンでLTSが出た時に戸惑わずに済むんじゃないかと思っています。

Stableラベルであるv5.0は、LTSではないので、次のバージョンが出たらv5.0はメンテされません。今回のv5.0はホットに最新を追いたいようなエンジニアを対象としたバージョンになります。今すぐにアップグレードする必要はありませんが、次のLTSでサポートされるような機能をいち早く試したい場合はアップグレードをおすすめします。

LTSかどうかを識別する方法は？

先ほど Argon, Boron などのLTS識別名が付いているものという事を書きましたが、LTS識別名が付いているのかどうかを識別する方法は多少面倒です。
もしも nodebrew などのバージョンマネージャーを使っている場合はいずれ nodebrew install-binary lts とかで最新のLTSがダウンロードできるようにする予定です。

github.com

リリースされている一覧のJSONファイルが提供されているので、そこのLTSラベルをparseすることでバージョンマネージャは識別可能になると思っています。

目で確認する場合は、公式サイトのトップページに書いてある情報から識別するのが簡単だと思います。

まとめ

Node.js v5.0 が出ました。
Spread operator/new.target等のES2015の新機能が追加
npmがv2からv3に
ALPNが追加
LTS(v4) と Stable(v5) の違い

また、今度学園祭に来るRod Vaggがリリースを管理しているのでそこで聞いてみるのも良いかもしれませんね！（これが書きたかった）