Go to Qiita Advent Calendar 2024 Top
LoginSignup
186
179

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

JavaScriptAdvent Calendar 2015

Day 8
@azu(azu)

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

Last updated at Posted at 2015-12-15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tonic on npm

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

tonic

RequireBinも類似サービスで、
Browserify + JSFiddle的な感じでnpmモジュールをそのままブラウザで動かせます。

開発者ツール

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

開発ツールバーの inject コマンドで、
inject <URL>とすることで見ているページにJavaScriptファイルをロード出来ます。

inject

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

ブラウザ拡張機能やJS Envyを使えば同様の事が出来ます。

js envy

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

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

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

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

|壁|

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

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

@azuのケース

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

# 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などスクリプトは以下に置いてあります。

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

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

例) Jasmineのランダムテスト

これは2015-12-07のJS: Jasmine 2.4.0、Redux入門、Firefox Platform Status - JSer.infoでJasmine 2.4.0について紹介するときにやったことについてです。

Jasmine 2.4.0ではランダムな順番でテストを実行する変更が入りました。
しかし、リリースノートにはそういう変更があったということだけが書いてあり、
それがデフォルトになったのか設定方法については書かれていませんでした。

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

どういう意味?

実際に動かしてみる

$ 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というランダムで実行されたら落ちるテストを追加しました。

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

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

Add support for returning run details for reporting randomness

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

動かした後の認識

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

Add support for returning run details for reporting randomness

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

動かすことで得たもの

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

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

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

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

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

mizchi素振り

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

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

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

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

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

Issueを出す

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

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

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

Issueのサンプル : deku

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

まとめ

JSer.infoで紹介するときの確認方法や素振りについて紹介しました。

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

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

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

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
186
179

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?