VOYAGE GROUP エンジニアブログ

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

2012年06月

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!

新卒エンジニア研修2012のふりかえり

先々週末に12新卒エンジニアが全員部署へ配属されたので今年のエンジニア研修をふりかえってみたいと思います。
何事もふりかえり重要ですよね。


▼期間は5週間
総合職との合同研修が終わった4/23(月)から5/31(木)まで約5週間行いました。
5週間と日数だけ聞くと結構時間あるなと感じるのですが、学んで欲しいことをリストアップしていくと時間が足りないと気づきます。


▼テーマは「チーム開発」
  • 今年は全員最低限のスキルを持っているのでプログラミング言語の基礎はやらない。
  • チームで開発する際に必要な作法やツールを学ぶ。
  • グループワークを多めにし、常にアウトプットを意識させる。


▼学習計画
内容講師
Webサービス運営ECナビ 価格比較本部 本部長
インターネット広告の仕組みadingo メディアソリューション本部 本部長
User Experiencegenesix Chief UX Designer
プロジェクトマネジメントアジャイル戦略室 室長
VMシステム本部 エンジニア
CIシステム本部 エンジニア
デプロイシステム本部 エンジニア
バージョン管理adingo エンジニア
セキュリティ情報セキュリティ委員会 委員長
システムの構成と運用システム本部 インフラエンジニア
DBDBA
テストシステム本部 エンジニア
JavaScript Libraryシステム本部 エンジニア
プログラミング作法CTO
Web Application Frameworkシステム本部 エンジニア
グループワークたくさんのエンジニア


▼よかったこと
  • 事前スキルチェックを行い、それを元に微調整した。
  • グループワークを多用することで理解度が深まった。
  • すきま時間用課題は割とチャレンジしてた。
  • 毎日開催の先輩クルーからのありがたいお話はためになったようだ。
  • ペアプロを行うことで何が分からないか分かった。

▼来年挑戦したいこと
  • 全ての資料を研修前に用意しておく。
  • スキルチェックの要綱を事前に開示する。
  • 頻繁に席替えする。
  • 座学を極力減らす。
  • 英語版も作る。


▼まとめ
全体を通して実践的な内容のため、1人でそれなりのアプリケーションを開発できるスキルはあるが本格的にチームで開発した経験がない人には効果的な内容だったと思います。
今後はこれをベースに海外拠点向け研修や学生向けインターンに広げていく予定です。


※宣伝
VOYAGE GROUPは今年の夏もエンジニア向けインターン「Treasure」を開催します。
このインターンで初めて会った仲間とサービスを考え、「チーム開発」しませんか?
興味を持った学生の方はぜひ登録してみてください。

超便利!Makefileを作ってmakeするのは想像よりもずっと簡単だった

VOYAGE GROUP の初級シェルスクリプター @katzchang です。おはこんばんちわ。

最近、 makeMakefile をゴリゴリ使い出しているところなので、それについて今日はちょっと書いてみることにします。

さて、プロフェッショナルな技術者たる皆さんであれば、一生に何度かは「ディレクトリをカレントに入れてメイク、ディレクトリをカレントに入れてメイク…」というご経験があろうことかと思います。 make のイメージといえば:

  • C言語で書かれたアレをコンパイルする、よくある手順
  • もしかしてC++かもしれないけど大勢に無影響
  • たまに失敗するけどあれマジなんなの困る
というアンケート結果がでています(2012 俺調べ)。

そんな make 環境ですが、意外にも普通に使えるのです。普通というと、ベターシェルスクリプトとして。ここで「それ、普通じゃないすか」と思った方、いらっしゃいますか?その通り、大したことが書いてないです。お疲れ様でした。以下は、まだ疲れていない方のための記事です。大丈夫、難しいことは書けないので。

Hello Make World

makeの本当の姿、それはターゲット駆動スクリプト言語です。 Makefile に書かれたターゲットを make コマンドで発火させます。訳の分からないことを言うのはここまでにしておいて、とりあえず Hello World から始めましょう。適当なディレクトリを作って、 Makefile ファイルを作って、 make コマンドで実行してみます。

$ mkdir hello_make; cd hello_make
$ vim Makefile

Makefileファイルの内容は:

all: hello_make

hello_make:
	echo Hello Make World!!

"echo" の手前は tab です。 tab だけが許されています。ここに論争はありません。そして、makeコマンドで実行:

$ make
echo Hello Make World!!
Hello Make World!!

普通に echo しているだけです、簡単ですね。 "all" や "hello_make" はターゲットってやつで、 "make" コマンドだけであれば all ターゲットが実行されます。 "all: hello_make" としていることで、 all は hello_make ターゲットに依存している(つまり、事前に実行する)ことになります。 make コマンドにターゲットを続けることで、狙いのものを実行させることもできます。

$ make hello_make
echo Hello Make World!!
Hello Make World!!

「 make コマンドが実行できない!!」等の場合は、osx make command not foundcentos make command not foundなどでおググり頂ければ幸いです。

エラーで止まる

何かの手順をシェルスクリプトにする場合、途中でコケたら嫌ですよね。でも、ステータスコードを途中で拾ってifってexitるとか、いちいち書きたくないですよね?…ですよね?

でも大丈夫、我々には make があります

たとえば、 curl と grep を組み合わせて、サイトをテストしてみましょう。 grep は、与えた文字列が見つかれば 0 、見つからなければ 1 を、ステータスコードとして返します。では、先程の Makefile に check_hito ターゲットを足してみます。

all: check_hito hello_make

hello_make:
	echo Hello Make World!!

check_hito:
	curl --silent voyagegroup.com | grep "人月を軸にした事業開発会社"

で、make。

$ make
curl --silent voyagegroup.com | grep "人月を軸にした事業開発会社"
make: *** [check_voyagegroup] Error 1

あぁ、間違いました。「人を軸にした事業開発会社」でしたね。でもこれで、エラーが起こると、その先の "hello_world" ターゲットが実行されていないことがわかりました。

修正し、

check_hito:
	curl --silent voyagegroup.com | grep "人を軸にした事業開発会社"

make 。

$ make
curl --silent voyagegroup.com | grep "人を軸にした事業開発会社"
<title>株式会社VOYAGE GROUP | 人を軸にした事業開発会社</title>
<meta property="og:title" content="株式会社VOYAGE GROUP | 人を軸にした事業開発会社" />
echo Hello Make World!!
Hello Make World!!

hello_world まで、エラーなく実行されたようです。

パラメータが便利

「僕が叩きたいのは voyagegroup.com じゃないんだ、テスト環境は別なんだよ」というあなたに、更に朗報です!対象をパラメータ化してみましょう。

TARGET = voyagegroup.com

all: check_hitowo hello_make

hello_make:
        echo Hello Make World!!

check_hitowo:
        curl --silent $(TARGET) | grep "人を軸にした事業開発会社"

上部に TARGET 変数を定義し、 voyagegroup.com としておきます。 curl のパラメータを "$(TARGET)" とすれば、お察しの通り、埋め込まれることになります。make 。

$ make
curl --silent voyagegroup.com | grep "人を軸にした事業開発会社"
<title>株式会社VOYAGE GROUP | 人を軸にした事業開発会社</title>
<meta property="og:title" content="株式会社VOYAGE GROUP | 人を軸にした事業開発会社" />
echo Hello Make World!!
Hello Make World!!

さて、 TARGET を変えてみましょう。 make 実行時に、引数として指定します:

$ make TARGET=ecnavi.jp
curl --silent ecnavi.jp | grep "人を軸にした事業開発会社"
make: *** [check_hito] Error 1

切り替わってますね!正常にエラーになりました。シェルスクリプトと違ってデフォルト値や定義名を与えることができるので、可読性は良さそうな気がしませんか?

次のステップ(やること・やらないこと)

  • ビルド用スクリプト
  • デプロイ用スクリプト
  • テスト用スクリプト

みたいな部分が、私としては今後使いたいようなところです。 make はコマンドとステータスコードで頑張ってくれるので、 phpunit や ant、 git、ssh など、他のコマンドを組み合わせて使うことも簡単にできたりします。

他方、込み入った Makefile はできるだけ避けるべきかもしれません。高度な Makefile を使いこなすほど我々は賢くないという可能性も考えておくべきです。複雑な処理は従来のシェルスクリプトを書けばいいんじゃないでしょうか。というかむしろお好みの、普通のプログラミング言語を使ったほうがよさそうな気がします。ただ、make厨二病にはまだ感染していないので、もしかしてこれから色々ありそうな予感もしますが、そのあたりは追々で。

補足:補完とzsh

zsh が便利なのは言うまでもないですが、 make コマンドでターゲットを補完してくれたり(たぶん初期設定状態で)するのでおすすめです。 Ubuntu の bash も、初期設定状態でも補完できるようになってたりするので、いろいろ便利です。お試しください。

記事検索
QRコード
QRコード