DeNAを卒業します
この週末にこの話を書こうと思っていたのですが、筆不精なもので土日を普通に過ごしてしまいました。
さて、表題の通りDeNAを卒業することになりました。
今回は技術的な話ではなく、単純にライフステージの変化の話なので気にならない人は読み飛ばしてください。
DeNAに入社したのは3年半前
yosuke-furukawa.hatenablog.com
だいぶ昔の記事ですね。この時は同年代や年下の若いエンジニア達がメキメキと力をつけていく中で「なんとかしなければ」という焦燥感で常に何かしらをウォッチしつつ、新しい技術があれば飛びついて調べ、アウトプットする、というようなことをやってました。(今でもアンテナは張っているつもりです)
そんな折に DeNA に誘われて入社できたのは非常にラッキーだったと思っています。新しい技術を積極的に採用しつつも、ある程度冷静かつ成熟した判断をしている部分があり、しかも事業としても色んな事を多方面でやっているので面白かった。
yosuke-furukawa.hatenablog.com
初めて入って、 Play Framework x Java で海外の人たちと英語でコミュニケーションしながら一緒に海外向けのゲームを作ったり、 PerlでHTMLもCSSもJSもほぼ全部一人でウェブサイト作ったり、 かと思ったら Node.js でリアルタイムゲームのR&Dをやったり、QuizNowっていうリアルタイムゲームを作ってYAPCで宣伝させてもらったりもしました。つい最近まではNBPFと呼ばれる新しいmobageのプラットフォーム周りの仕事をしてました。有意義なキャリア開発ができました。
DeNAという会社でもともとやりたかった下記のことはだいたい実現できました。
- ウェブアプリの作り方の基礎を身につける
- WebSocket等の新しいプロトコルでゲームを作る
- JavaScript(Node.js)を使って仕事をする
- 英語でコミュニケーションをする
次はどこに行くのか
あんまり隠してないので、言ってしまうとリクルートテクノロジーズっていうところに行きます。 Node.js をサービスでも使っているのと、 Node.js のOSS活動・コミュニティ活動を奨励する、という話だったので、OSS活動、コミュニティ活動も継続しようと思っています。特に Node.js committer/evangelism 活動はやり続けたいと思っています。
ただ誤解のないように言っておくと、 DeNA でもその手の活動は別に禁止されていません。むしろ奨励してくれています。
最近だとkazuho さんの h2oとかが良い例じゃないかなと思います。 他にもsonots さんみたいにRuby committer/Fluentd committerとしても活躍している例もあります。
じゃあなんで転職するのか
これには僕のライフステージが変化したのが大きいと思います。簡単に言ってしまうと、子どもが生まれました。 しばらくは子ども中心の生活になるのと後は自分のキャリアとか条件を鑑みて総合的に判断しました。
子どもが生まれるというのは非常に大きな変化でして、今は子どもにかかりきりです。ソフトウェアを作るのとは全然違った楽しさがあります。この記事も子どもが寝てくれたので隣で寝顔を見ながら書いてます。
しばらくは、OSS committerをしながら Node.js ユーザーグループ代表をしながら、サービスも作りながら、 Fulltime パパ committer をする予定です。
細かい話は飲みとかランチとかに行った時にでも話します。皆さん、よろしくお願いいたします。
謝辞
業務用アプリ作り続けて、ソーシャルゲームとかウェブアプリケーションのことを何も知らないで入ってきた門外漢に対して懇切丁寧に教えていただきありがとうございました。3年半という長いようで短い時間でしたが DeNA の皆さんと過ごした時間はかけがえの無いものでした。狭いIT業界なのでまたお会いすることもあるかと思いますが、その時はどうぞよろしくお願いいたします。
wishlist
一応置いておきます。(何か頂けるのであればベビー用品・生活家電系があると助かります)
今後ともどうぞよろしくお願いいたします。
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 になってしまっているが、昔を知る上では非常に重要だと思う。
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
でのチェックをしておけば大丈夫なはずだ。
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
というメソッドがあるのでそれを使ったほうが綺麗にコードが書けるし、高速である。
ただ 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への公開もそれを使うのも、その差を埋めるための手段
Developers Summit 2016で非同期処理について話してきました
だいぶ間が空いてしまったんですが、デブサミ 2016 で非同期処理について話してきました。
トピックとしてものすごく突出してたので成立するか不安だったのですが、なんとなく結論めいたものはでました。
詳しくは takezoe さんのブログを見て頂けると良いかと思います。
結論みたいなもの
まぁやっぱり同期処理と非同期処理は『意識して使い分けなくても言語なりフレームワークなりで吸収するようになっていくんじゃないか』というのが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 がわかりやすい図を書いてくれているので引用する。
この図は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を!!
2015年のふりかえり
さて、もう一個の記事です。
本当この一年は振り返っておかないともったいない一年だったので振り返っておきます。
もう2016年になっちゃったけどスルーします。僕が認めるまで2015年です。
考えてみると、Node.js日本ユーザーグループ代表になって2年目です。当初あげていた目標である、海外に向けての意見発信であったり、国際カンファレンスでの発表経験だったり、YAPCやCROSSでの講演と本当に色々経験させてもらいました。
1月
◆ CROSS 2015 で講演(OSSという枠でパネルディスカッション)
◆ io.js 出たばかりで issue 追ったり PR 出したりしてました。
当初の目的は io.js と Node.js の混乱を少なくとも国内だけは抑えられるようにしようと思っていました。
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
このために半年くらいかけてたので、みんな楽しんでくれて本当報われました。
◆ enjapanさんで国内外で活躍するエンジニア向けに発表してきました。
12月
◆ GTUGGirls に呼ばれて講師をしてきました。
gtuggirls.connpass.com
electronica を作ったのもこの時でした。
◆ NodeSchool Tokyo in leverages
nodejs.connpass.com
◆ JSおじさんで発表してました。
まとめ
総括すると、本当に色々経験させてもらった一年でした。この一年で得たものは大きかったので次の年は絶対にこれを更に大きな経験にしたいと思
います。特に海外での発表経験はすごく良かったので来年も継続していきたいと思います。そのためには再度発表できるクオリティの物を仕込めるようにしていきたいと思います。
また仕事的にも面白い事がたくさんできるようになってきているので、どんどん発表していきますね。
2016年もよろしくお願い致します!!
electron を学べる workshopper である electronica を作ってみました。
ちょっと最近Fallout4でサンクチュアリを開発するのに忙しすぎてOSS界隈の仕事サボってしまっていたので、31日にして書かないといけない記事が2つほど残っていることに気づきました。
なので、一個をこの場で投下しておきます。
手短に言うと、electronicaというworkshopperを作りました。
$ npm install electronica -g $ electronica
で起動します。最初はHello Electron から始まり、最終的に小さなブラウザを作るくらいまでの事をやります。
残念ながら、verifyは動かないので、終わったたら自己判断で次のexerciseをやらないといけないので、まだNodeSchoolで使えるまでは行かないのですが、暇な冬休みにやってみてください。
僕はこの冬休みにはverifyがちゃんと動くようにします。
では次の記事を書きます。
Node.js へのcontributeの仕方
このエントリは 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
に変える修正だった。
結局この修正は色んな効果があって、みんながeslintに乗り換えてくれたおかげでtemplate string literalsやoctal literalといった新しい文字を持つES2015のコードもある程度は書けるようになっている。しかしやっぱり class
構文や let
といった性能に影響があるものはlib/
の中では書けるものの広くは受け入れられていない。
Promiseを返すコードにしてほしい
というのも性能の問題が理由で受け入れられていない。Node.js のコアのコードは読みやすさや書きやすさよりも互換性と性能を追い求める傾向にある。
また、『これがあると便利じゃない?』みたいな一見便利に見えるようなコードも受け入れられないことが多い。
例えば 上に挙げたような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/
へのコントリビュートなので気を付けたほうが良い。
genderの他には宗教や能力の差、身体的特徴など、とにかく人を不快にさせるような言葉は使ってはいけないとされている。
難しいかとおもうかもしれないが、基本的にはAPI説明だけならそんな内容を書くことは少ないし、割りとチェックもされるので気軽にtypoを見つけてはコミットしたり、ドキュメントの間違いを見つけてはコミットすると良いとおもう。
test/ へのコントリビュート
testへのコントリビュートもまた盛んである。OS によってはコケたり、またタイミングが悪いとコケたりするコードのことを不安定なテスト、 flaky test と呼んでいて、これを撲滅する活動が盛んだからだ。
test フォルダ以下に {フォルダ名}.status という名前のファイルが有り、そこを見るとどれが flaky でどれが flaky じゃないかがわかると思う。
これを直すとかなり感謝されるし、取り込まれる可能性が最も高いコミットだとおもう。
また、 lib/
や src/
を修正したらほぼ確実に test/
を書くことが求められるので、常に test を書くクセが付くはずだ。
ここをコントリビュートの出発点にして欲しいと Node 学園祭に来た Rod Vagg も懇親会の二次会で言っていたので、間違いないだろう。
コントリビュートの細かい作法
Node.js はコミットする時にコミットメッセージに
<修正するラベル>: <修正タイトル> ※ 80 文字以内 修正した内容
を書く必要がある。Reviewed-By や PR-URL というラベルはマージする人がつけるという決まりになっているので、コラボレータになると習うはずだ。
僕の最近やったコミットではこんな感じになる。
また、参考までに僕の拙いメモで良ければこういうマージフローになっている。
コラボレータになると merge 権限もあるし master への push 権限も持つことになる、一番注意しないといけないのはうっかり master に push しちゃうことだ。とりあえず間違っていてもすぐに直るだろうが、 git の使い方が怪しければこれを機に見直す良い機会になる。
コア以外へのコントリビュート
コア以外のコントリビュートも盛んだ。僕のやってる evangelism とか benchmarking とかはコア以外で貢献できるタイミングだと思う。 evangelism は毎週の変更点やニュースをピックアップして website に載せるという活動だ。 benchmarking はまだあまり進んでいないが、 benchmark フォルダを修正したり、わかりやすくグラフにして見える化するという活動も含まれる。
最近は Node 学園祭とか学園祭をやってる間に溜まったタスクの消化で忙しく、あまりコントリビュートできていないので、是非みんなも参加して欲しい。
あと、翻訳も立派なコントリビュートだ。 Node.js の API の翻訳が古いと言われているのでそろそろ本腰を入れて翻訳活動を再開したいがどうしても時間がない。(やりたいという人達が集まってくれるとやりやすいのだが、、、)
最後に
いろんなことを言ったが、コントリビュートのやり方は様々だ。僕はやるようになって LESS IS MORE という考え方や英語力、またコアメンバーとの信頼等々色んな物を得たので是非みんなもやってもらいたい。もちろんこういうのは強制になるとつまらないので、やりたいという人達が有志でやるのが一番だと思う。
僕も大津さんも協力するので是非 Node.js をエンハンスする活動に参加してもらいたい。
東京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代が半数を超えてて若いコミュニティだなというのをつくづく思いますね。発表者も若いし、勢いを感じます。
懇親会で学生さんからも声をかけられたしこういう若い人たちが順調にJavaScriptコミュニティの全体を支えていくように新陳代謝が上がるのは素晴らしいなと思っています。
参加した人の職種
なんとWebフロントエンド開発を生業にしている人のがサーバサイド開発よりも多いという特徴が出ました。Node.jsの利用者のほとんどはフロントエンドだし、サーバサイドのためだけじゃないというのは分かっていたけど、おそらく2011年の頃とは全く客層が変わっていると思うので、ここまで来るのはかなり面白いですね。
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年に向けて考えることは多いですが、来年も絶対にやります。コミュニティ全体が大きくなってきているので来年は複数日開催とかも検討しています。
今年来ていただいた皆さん、ありがとうございました!!