VOYAGE GROUP　エンジニアブログ

voyagegroup_techのブログ
VOYAGE GROUPエンジニアブログです。

JavaScript

2015年02月05日16:34
カテゴリ

今、クライアントサイドのJavaScriptを書く前に知っておきたいこと ~ 2014年トレンド総まとめ

皆さんこんにちは。adingoにてFluctという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。

今回は、先日、社内のエンジニア向けに開催した「2014年のJavaScriptのトレンド総まとめ」というコンセプトの勉強会の内容について紹介します。

それでは、スライドに書ききれなかった前提事項について、何点か補足と解説をします。

補足と解説

前提: なぜ「2014年」なのか

JavaScriptを用いた開発、特にWebフロントエンドとも呼称されるクライアントサイドJSのトレンドは、非常に速いサイクルでの進化を見せています。その一方、Webサービスを提供するに際して、我々は好む好まないに関わらず、デファクトスタンダードであるJavaScriptに触れる必要が存在しています。そうしたことから、JS以外の言語を専門とする（同僚の）エンジニアから、「三ヶ月も経つと新しいライブラリの話がされているので、今現在のベストプラクティスないしは全体的なトレンドを追うのが非常に難しい」という話を耳にします。

本スライド（を用いた勉強会）では、「全体的な潮流、および2014年末日現在であれば、このような方法を用いるのが十分に実用的な水準に達しているものを振り返り、トレンドを理解する」というコンセプトで、現時点でのJavaScriptのトレンドを押さえるのに必要な単語と流れを紹介する事にしました

タイトルに「2015年」と冠していないのは、年が明けて一ヶ月しか経っておらず、2015年のベストプラクティスとも呼べる物は未だに登場していないと判断した為です。

内容選定の基準に付いては以下の通りです:

  • 最先端ではなく「トレンドの少し後ろ」を主軸にする
    • 少なくともアーリーアダプターの間では一定の評価を得ていると判断できる物を中心に選択しています
  • 過去にJSに触った事のある（JS以外がメインの）エンジニア向きの内容
    • 特に、Webアプリケーションエンジニアが主な聴衆となる前提での話が多いです
  • 2013年までに出てきたものを踏まえて、14年に出てきたものを拾う
    • 過去の経緯（コンテクスト）を理解しなければ、全体の流れの理解にはつながらないからです

  • クライアントサイドの話を中心にする

    • Node.js（io.js）では既に解決されている問題が多いため
    • 変化が極端に激しいのはクライアントサイドのため
    • 現時点において、サーバーサイドに関しては必ずしもJavaScriptを採用する必要性が無いため
      • Isomorphicなどの文脈はありますが、業界における決定的潮流には至って居ないため、このような判断をしています
  • パフォーマンスについては、以下の理由から言及していません
    • 話し始めるとキリが無い
    • 万能の解決策は無い

「現代のJavaScriptはビルドする物である」

CSSにおいて、Sass/LESS, Autoprefixerのようなプリプロセッサが普及しているのと同様に、JavaScriptも、Lintやminifyに限らない、デプロイ前にビルド工程を挟む前提でのツールが一般化しつつあります。CoffeeScriptを始めとした「任意の構文で記述したソースコードから、JavaScriptを最終的に生成する」AltJSの大量発生が典型的な事例ではありますが、他にもソースコードをパースし、抽象構文木（AST）を生成する事で、より複雑な変換・解析をカジュアルに行うためのツール群（esprimaが有名）も広く利用されています。

開発環境や目的によっては、これらのビルド工程を挟むツールの利用が困難なケースもありますが、制約の中でもこうしたツール群の恩恵をいかに受けていくかが鍵になるのは間違いありません。

終わりに

上記のスライドで挙げた内容について、本格的に普及が始まるのは今年以降であると予測していますが、情勢を知った上で選択するのと、知らないで選択するのとでは雲泥の差が存在します。上記のスライドおよび本記事が、まさに今、次のアプローチを検討している皆様の一助となれば幸いです。

会社のブログですので

お約束となりますが、弊社には AJITO という社内バーがあり、毎夜のようにエンジニアが現れ、酒を嗜み、軽食をつまみつつ、エンジニアリング談義を行っています（ #ajitingで既にご存知の方も多いと思います）。「私も一緒にエンジニアリング談義をしたい！」という方がいらっしゃいましたら、是非とも弊社エンジニア or @tech_voyageに、お声掛けいただければと思います。

また、adingoを含むVOYAGE GROUPアドテクユニットでは、一緒に働いてくださる仲間を募集しております。VOYAGE GROUPや広告配信に興味を持たれましたら、お気軽にご連絡ください。

タグ ：
JavaScript
勉強会
2012年06月21日15:08
カテゴリ
tool
programming

Introducing our new team member: Ms. zombie.js

初めまして、VOYAGE GROUPの李一（@pank7）と申します。

昨年9月末に中国から参りまして、今子会社adingoでエンジニアをしています。すみませんが、日本語はまだ勉強中なので、これから英語でうちのチームの新しいメンバーを紹介させていただきたいです。

Have you and your team ever encounter the situation, or let's say, difficulty of deciding who will be responsible for scenario testing or browser testing before every release day? Seems like our team -- fluct, have been suffering from that once every 2 weeks for quite a long period of time, long enough for us to start to hate that kind of testings, which requires been done by clicking and typing according to certain movement lists -- scenarios, with only hands and without any automation.

What? Why do we hate that? For God's sake, clicking and typing according according to some instructions is not something an engineer should spend his/her precious time on, not even for 20 minutes! Not to mention that people make mistakes all the time. Well, seriously speaking, the most important reasons why we need some one who can do browser testings for us are that we wish to:
  1. release faster and more frequently,
  2. release with more automations,
  3. release flawlessly,
  4. the last but not the least, be able to release on Fridays.

Thus, we never stopped looking for some one we can count on. However, making browser testings work in the way we want is not as easy as it looks. Some of the obstacles are:
  1. Javascript's are difficult to test
  2. We need to emulate movements, such as clicking and typing, not just HTTP GET's and POST's
  3. There may be too many prerequisites or dependencies for even short testings
  4. Instruction list changes frequently
  5. Confirming the HTML elements on every page can be too boring, and people make mistakes easily

Of course we did have some progresses, however not until recently did we find a best one and think this is some one who can satisfy all our requests. Now, ladies and gentlemen, please allow me to introduce you an insanely fast, headless and so reliable member on our team: Ms. zombie.js. Don't be scared, she dose not bite your brains. Let's find out how she does her works.

Overview

Specifically speaking, we have already prepared a movements/confirmations list called scenario, that is something like the following:
  1. Open URL: http://www.example.com/login, confirm the page has a title called "Example";
  2. Input something into "user_id" and "user_password" boxes, if the page has two, then click the button called "Login", if the page has one, confirm that the page is redirected to URL: http://www.example.com/top, and that page has a title tag called "Top Page";
  3. Click a link called "TEST" if the page has one, confirm that the page goes to URL: http://www.example.com/test, and that page has a title tag called "test";
  4. Click a button called "Click me" if the page has one, confirm that javascript insert an a tag into the page, had text 'TEST', and links to URL: http://test.example.com/
  5. ...

Before Ms. zombie.js came, we test by doing exactly what's in that instruction list, only now that we have Ms. zombie.js doing the job for us. As Ms. zombie.js does not talk much, never actually, I'm afraid you can not talk to her, if you want know what she can do, you can refer to her homepage.

Ok I forgot to tell you Ms. zombie.js is actually a Web browser emulation robot library built with node.js. But to put it simply, Ms. zombie.js emulates a browser, and emulates it so really that it:
  1. has history records,
  2. keeps cookies,
  3. supports HTML5, XHR,
  4. and runs javascript's.
"All of that, just like a real browser, happens asynchronously", said her father. Ms. zombie.js has a group of API's which imitates human motions and easy to use. Ms. zombie.js speaks javascripts, CSS selectors and DOM. Thus, we believe Ms. zombie.js is competent in doing browser testings, in fact she did a good job.

So now if we want to test according the sample scenario above, we write the following code (of course we are using some other libraries like vows and assert, at the same time. You don't have to use them if you don't like them). See, things became easier than before, now we can test by only one command:

$ vows test.'s --spec

Pros

We have to admit that Ms. zombie.js is the best browser emulation robot ever, it
  1. helped us making automatic browser testing become possible;
  2. helped making testings easier because we can now reuse codes, if you organize your code in an elegant way;
  3. increased testing accuracy because it makes no misses, theoretically;
  4. shortened the time spent on testing because of its high speed;
  5. and gives us more confidence to release on Fridays.

All in all, it overcomes the main obstacles which was mentioned above.

and Cons

Although Ms. zombie.js simulates browsers in a really resemble way, that does not make it a real browser. There can be differences, thus you have to carefully organize you output and fit both Ms. zombie.js and real browsers in your development.

The second thing is that Ms. zombie.js is young and evolving, your testing code may get outdated fast, making it difficult to upgrade your zombie.js library.

And by the reason that Ms. zombie.js is a young lady, she can be buggy sometimes. This link demonstrates an example of a bug we found in zombie. We then report it to its github repository homepage, and it was resolved now.


The End

In conclusion, if you are now suffering from doing browser testings by hands, we'd like to strongly recommend you to hand over that work to Ms. zombie.js. She tests automatically, insanely fast, emulate almost everything that a browser has. Even thought she's not perfect in all ways, she is able to help a lot with your testings and releases, enjoy her!

タグ ：
zombie.js
node.js
JavaScript
browser
test
記事検索
最新記事
Blog移行のお知らせ
MySQL InnoDBのinsertとlockの話
様々な角度からデータ分析ができるTableau
Redshiftの操作権限の設定とその方法
BigQueryで使えるクエリをまとめてみた
今、クライアントサイドのJavaScriptを書く前に知っておきたいこと ~ 2014年トレンド総まとめ
知らなきゃ損するVOYAGE GROUPエンジニアが薦めるブログ、ウェブサイト
M1・THE MANZAIの結果で学ぶawk入門
2014年 個人的ハイライト
海外ニュースサイトで振り返る2014年
タグクラウド
QRコード
QRコード