JavaScriptのトレンドを素振りして確認する方法

JavaScriptは流れが早いと言われますが、その流れをどう捉えるかの一つの要素として使える素振りの話です。

流行り廃れが早いのはちゃんと循環してるということなので問題ないですが、
トレンドと言われるものの半分ぐらいは誰かの主張にすぎない事があります。

そのため、主張だけを見て判断しないで中身を見て確認する必要があります。

自分は[JSer.info](http://jser.info/ "JSer.info")というJavaScriptの情報サイトを2^8週間ほど継続してやっています。([5周年記念イベント](http://jser.info/2015/12/14/jser-info-announce-5-years/ "JSer.info 5周年記念イベントを1/16(土)に開催します - JSer.info")を1/16(土)にやります)
JSer.infoで紹介するものは何かしらの方法でその主張がおかしくないかの確認をとります。

売り文句は素晴らしいが中身を見た時におかしな部分や問題がありそうなら、そこで引き返して追わないという判断もします。

仮にそこで引き返した事が間違えであっても、それが素晴らしいものなら別の誰かがそういう主張を書いてくれるはずなので、そちらに任せるという考え方です。

以下の話も少し関連するかもしれません。

- [技術トレンドを追わないという勇気 - to-R](http://blog.webcreativepark.net/2015/11/20-091733.html "技術トレンドを追わないという勇気 - to-R")
- [エンジニアミーティング vol.46 技術トレンドを追わないという勇気 by engineer meeting podcast | Free Listening on SoundCloud](https://soundcloud.com/engineer-meeting/vol46 "エンジニアミーティング vol.46 技術トレンドを追わないという勇気 by engineer meeting podcast | Free Listening on SoundCloud")

この"確認"というのは色々ありますが、一番単純なのは動かしてみることになると思います。
JavaScriptだとブラウザ自体が実行環境になるので、他の言語に比べて気軽に実行できるのは良い点です。

この記事では動作確認をする際に使えるツールや確認方法などについて書いています。

同じような話を以前やったのでスライド版もあります(簡略)

<div class="kwout" style="text-align: center;"><a href="http://azu.github.io/slide/2015/year-end/javascript-swing.html"><img src="http://kwout.com/cutout/9/hn/n7/gyj_bor.jpg" alt="http://azu.github.io/slide/2015/year-end/javascript-swing.html" title="JavaScriptの素振りする技術" width="600" height="309" style="border: none;" /></a><p style="margin-top: 10px; text-align: center;"><a href="http://azu.github.io/slide/2015/year-end/javascript-swing.html">JavaScriptの素振りする技術</a></p></div>

## ライブラリをちょっと試す

READMEなどドキュメントが十分であればわざわざ実行しなくても問題ありませんが、それらでは不十分な時があります。

JavaScriptのライブラリの場合はGitHub Pagesでそのまま動くデモが公開されているケースも多いです。
しかし、デモが無かったり、Node.jsの向けのライブラリなどの場合はわざわざ`npm install`して試すのは大変です。

そんなときには、以下のようなウェブサービスやツールを利用するとブラウザだけで試すことが出来ます。

### npmモジュールをブラウザ動かす

- [Tonic: a better REPL for node.js](https://tonicdev.com/ "Tonic: a better REPL for node.js")

![Tonic on npm](https://monosnap.com/file/xKGVwkjuxArDwEj7OslITBRPef5Yxe.png)

npmのサイトから直接リンクが貼られているので知ってる人も多いですが、Tonicを使うとnpmで公開されてるモジュールを試せます。
Browserify + REPLのようなサービスなので、その場でモジュールを`require`して試すことが出来ます。

[![tonic](https://monosnap.com/file/DPbfvXUGDajbYUV0iJQ0BDEByN1EE3.png)](https://tonicdev.com/npm/lodash)

[RequireBin](http://requirebin.com/ "RequireBin")も類似サービスで、
Browserify + JSFiddle的な感じでnpmモジュールをそのままブラウザで動かせます。

### 開発者ツール

Firefoxの開発者ツールではサイトに特定のライブラリを読みこませる機能が入っています。

[開発ツールバー](https://developer.mozilla.org/ja/docs/Tools/GCLI "開発ツールバー")の `inject` コマンドで、
`inject <URL>`とすることで見ているページにJavaScriptファイルをロード出来ます。

![inject](https://monosnap.com/file/UFPOCEP2WnTykJTKfJBM6oZNmuthjV.png)

ブラウザ向けのライブラリならそのままファイルを読み込ませてコンソールで試すことが出来ます。

ブラウザ拡張機能や[JS Envy](http://jsenvy.com/ "JS Envy")を使えば同様の事が出来ます。

[![js envy](https://monosnap.com/file/5xnaU8dqIJgcOPjwTk9mWDZIQlxq4D.png)](http://jsenvy.com/)

-----

## ライブラリの新しい機能を試す

ライブラリの新しいバージョンで機能が追加された時にどうやって確認するかというパターンです。

リリースノートにちゃんと書いてあれば何も問題ありませんが、稀によくリリースノートだけでは良くわからない場合があります。
Issueやコミットだけでは分からない場合に、最終手段としてローカルで実行してみる必要があります。

更新履歴の追い方については以前書いています。

- [良いChangeLog、良くないChangeLog | Web Scratch](http://efcl.info/2015/06/18/good-changelog/ "良いChangeLog、良くないChangeLog | Web Scratch")
- [われわれは、いかにして変更点を追うか](http://azu.github.io/slide/cto/changelog.html "われわれは、いかにして変更点を追うか")


## |壁|

ブラウザで完結するならまだいいのですが、やはりローカルで実行するにはある種の壁があります。
(そのためできるだけブラウザで完結しておきたい)

ここで自分なり手順をテンプレ化しておき、それを使うのがいいと思います。
`npm install` -> write code -> `git push` というのがおおまかな流れになると思います。
(後述しますが、適当に書いたものでもGitHubにあげておくといいです)

### @azuのケース

普段ローカルで何か試すときは、大体以下のようなパターンをとっています。

```sh
# ghqディレクトリにhogeを作ってhogeへ移動
mkdev hoge
# git, npm, license init
init-node.sh
# 確かめたいライブラリをインストール
npm install foo
### Development... ###
# Githubリポジトリを作成
hub create -d "description"
# git push -uのスクリプト
git pushup
```

`mkdev`や`init-node.sh`、`git pushup`などスクリプトは以下に置いてあります。

- [https://gist.github.com/azu/09dd6f27f52e2e8d9978](https://gist.github.com/azu/09dd6f27f52e2e8d9978 "node-init.sh")

`init-node.sh`に該当するものを色々作っておき、pecoで色々なパターンを選択し使う感じです。

実際にどんな感じでやってるかを見ていきます。

### 例) Jasmineのランダムテスト

これは[2015-12-07のJS: Jasmine 2.4.0、Redux入門、Firefox Platform Status - JSer.info](http://jser.info/2015/12/07/jasmine2.4-redux-firefox/ "2015-12-07のJS: Jasmine 2.4.0、Redux入門、Firefox Platform Status - JSer.info")でJasmine 2.4.0について紹介するときにやったことについてです。

[Jasmine 2.4.0](https://github.com/jasmine/jasmine/blob/master/release_notes/2.4.0.md "Release Notes")ではランダムな順番でテストを実行する変更が入りました。
しかし、リリースノートにはそういう変更があったということだけが書いてあり、
それがデフォルトになったのか設定方法については書かれていませんでした。

	Changes

		Run jasmine's specs in random order
		Add support for returning run details for reporting randomness
		Use className instead of class when creating DOM elements


#### 動かす前の認識

> Run jasmine's specs in random order

デフォルトでランダム実行になったの?

> Add support for returning run details for reporting randomness

どういう意味?

#### 実際に動かしてみる

```sh
$ mkdev jasmine-random-example
$ init-node.sh
$ npm install -g jasmine
$ jasmine init
$ jasmine examples
$ jasmine # run
```

`jasmine init`で出力された`jasmine.json`を見ると`"random": false`というのが増えていたのがわかりました。
また、デフォルトでは`"random": false`となっていました。

ここでランダムに実行される事を確かめたくて[randomeSpec.js](https://github.com/azu/jasmine-random-example/blob/master/spec/randomeSpec.js "randomeSpec.js")というランダムで実行されたら落ちるテストを追加しました。

```js
var count = 0;
describe("random 1", function () {
    it("should be 1?", function () {
        count++;
        expect(count).toBe(1);
    });
});
describe("random 2", function () {
    it("should be 2?", function () {
        count++;
        expect(count).toBe(2);
    });
});
```

なぜか`jasmine`コマンドで実行してもランダムになる様子がなかったので、
jasmineならHTMLで実行される方が多いと思ったのでHTMLで動かすようにしました。

HTMLで動かしたら設定があり、実際にランダムで実行されてテストが落ちるようになりました。

![right](https://monosnap.com/file/irp2XkqW8cuWDcQGxyotfqhvghviGE.png)

またテストが落ちると、`seed`値のパーマリンクが出るようになっていました

> Add support for returning run details for reporting randomness

というのはこれのことを言ってるんだなというのがここで分かった感じです。

#### 動かした後の認識

- デフォルトではランダム順序の実行ではなかった

> Add support for returning run details for reporting randomness

これは`seed`値が失敗した時にでるという意味だと分かった


#### 動かすことで得たもの

- 10分ぐらいで適当に動かせて認識を正すことができた
- そのままGitHubにpushして動くサンプルを作れた
- [https://github.com/azu/jasmine-random-example/](https://github.com/azu/jasmine-random-example/)
- [http://azu.github.io/jasmine-random-example/?random=true](http://azu.github.io/jasmine-random-example/?random=true)

-----

## ライブラリの使い勝手を試す

多分ここが一番コスト高く、試すライブラリ自体も大きめなものとなっていることが多いです。

例えば、Redux、Riot.js、jspmなどは、話を聞いただけだと評価が難しいタイプのものです。
この手のものの使い勝手を把握するのは実際に何かを書かないと分かりにくいという問題があります。

使い勝手を確かめるには素振りをするのが手っ取り早いと思います。

そして違和感を感じたら、その時点で引き返す選択肢を積極的に取るべき所です。

[![mizchi素振り](https://monosnap.com/file/9iqROc63qzR27m92owMJSPs1CD8veh.png)](https://twitter.com/mizchi/status/532914332518989824)

小さな規模またはサンプルをなぞってみるだけでも十分で、とりあえずそのライブラリを使ってみると色々な事がわかります。

書くものがないならElectronやNW.jsで小さな便利アプリを作ってみるのがいいかもしれません。
環境が固定されてると新しい機能が使いやすいやすいので、考えることが少なくなります。

自分が何かを作るときは大体以下のような事をしています。

- 作ってGitHubにあげる
- 完成しなくてもGitHubにあげる
	- トークンなど秘密のものがなくなったら`git push`します
- そのままローカルのゴミ箱に捨てるよりはGitHubに捨てる
	- ゴミ箱に捨ててしまうと記憶からも無くなってしまう

実際に自分が適当に作ったものを並べてみます。

- [JSer.info Pull Request Form](http://jser.info/contributing/ "JSer.info Pull Request Form")
	- Angularを試したくなり作った
	- [JSer.infoに紹介してもらいたい記事のPull Requestが出来るようになりました - JSer.info](http://jser.info/post/75446735069/jser-info-pull-request/ "JSer.infoに紹介してもらいたい記事のPull Requestが出来るようになりました - JSer.info")
- [JSer.info contributing item preview](http://jser.info/contributing-preview/ "JSer.info contributing item preview")
	- Vue.js 1.0を試したくなり作った
- [azu/github-ribbon-generator](https://github.com/azu/github-ribbon-generator "azu/github-ribbon-generator")
  - Vue.js 1.0と`.vue`を触りたかった
  - Vue.jsでUnidirectional Data Flowがちゃんと可能なのかを調べたかった
- [azu/hatebu-mydata-search](https://github.com/azu/hatebu-mydata-search "azu/hatebu-mydata-search")
	- Flux Utilsを試したくなり作った
	- [はてなブックマーク検索を作りながらFlux Utilsについて学ぶ | Web Scratch](http://efcl.info/2015/08/24/flux-utils/ "はてなブックマーク検索を作りながらFlux Utilsについて学ぶ | Web Scratch")
- [azu/bookmarkletter](https://github.com/azu/bookmarkletter "azu/bookmarkletter")
	- [benjamn/ast-types](https://github.com/benjamn/ast-types "benjamn/ast-types")を使いたくて作った
	- [ブックマークレットを作るコマンドラインツール | Web Scratch](http://efcl.info/2014/09/08/bookmarklets-env/ "ブックマークレットを作るコマンドラインツール | Web Scratch")
- [azu/video-prefetcher](https://github.com/azu/video-prefetcher)
- [azu/video-shortcut-controller](https://github.com/azu/video-shortcut-controller)
- [azu/video-transcript-note](https://github.com/azu/video-transcript-note)
- [azu/video-transcript-tracker](https://github.com/azu/video-transcript-tracker)
	- `<video>`と`<track>`に触りたくて作った
	- [動画とルビ翻訳された字幕をみながらMarkdownメモできるアプリを書いた | Web Scratch](http://efcl.info/2015/07/27/video-transcript-note/ "動画とルビ翻訳された字幕をみながらMarkdownメモできるアプリを書いた | Web Scratch")
- [jser/stat-js](https://github.com/jser/stat-js "jser/stat-js")
	- [natural](https://www.npmjs.com/package/natural "natural")を使った自然言語解析がやりたくなった
- [azu/audio-node-flow](https://github.com/azu/audio-node-flow "azu/audio-node-flow")
	- Web Audio APIに触りたくて書いた
	- => Web Audio APIの標準に同様のものが追加されてた [Web Audio Method Chaining Sample](https://googlechrome.github.io/samples/webaudio-method-chaining/index.html "Web Audio Method Chaining Sample")
	- [JavaScriptとWeb Audio事始め](http://azu.github.io/slide/webaudioapi/web-audio.html "JavaScriptとWeb Audio事始め")

------

## Issueを出す

ライブラリなどで問題を見つけた時に、一番いいのは再現可能なサンプルと共に報告することです。
普段からリポジトリを作った上げる練習をしてないとこういったサンプルを作るのも億劫になりがちです。

これまで出てきたサービスや素振りで慣れておけば、再現手順の報告もしやすくなるはずです。

JSFiddleみたいなパーマリンクだけ済むならそれを出せば良いし、素振りで慣れておけばリポジトリで作るのも5分かからないと思います。

### Issueのサンプル : deku

- [Reduce build file size by azu · Pull Request #297 · dekujs/deku](https://github.com/dekujs/deku/pull/297 "Reduce build file size by azu · Pull Request #297 · dekujs/deku")
- [Add "browser" field for browserify by azu](https://github.com/component/type/pull/23 "Add &#34;browser&#34; field for browserify by azu · Pull Request #23 · component/type")

BrowserifyやWebPackでビルドするとファイルサイズが50KB増える問題を見つけました。
この時は実際にビルドしただけで50KB増えてるリポジトリを作り報告しています。

- [azu/component-type-with-browserify-issue](https://github.com/azu/component-type-with-browserify-issue "azu/component-type-with-browserify-issue")

-----

# まとめ

[JSer.info](http://jser.info/ "JSer.info")で紹介するときの確認方法や素振りについて紹介しました。

実際にはドキュメントやGitHub上でソースを眺めるだけでも十分なことが殆どです。

- [JavaScriptライブラリの気になる実装をどうやって見ていくか | Web Scratch](http://efcl.info/2014/0209/res3658/ "JavaScriptライブラリの気になる実装をどうやって見ていくか | Web Scratch")

ただ、`git clone`/`npm install`してローカルで試したほうが簡単にたどり着けることもあります。
その壁をできるだけ低くするために普段から素振りしておくといいのではという話でした。

全然まとまりのない記事ですが、まとめ。

- 実際にローカル環境を作らなくてもJavaScriptは動かせる
- ローカル環境でもパターン化してスグ動かせるように素振りしよう
- バグ報告には再現可能なサンプルを一緒に出そう
- ゴミはゴミ箱ではなくGitHubへ
- ライブラリ書く側はドキュメントを分かりやすく書こう、デモを作ろう