eyecatch
Fri, Aug 25, 2017

スタートアップはReactを使うべきではない (BSD + patentsライセンスを考慮して) — もし、いつか大企業に買収されたいと望むなら

このエントリでは、Raúl Kripalaniによる記事、If you’re a startup, you should not use React (reflecting on the BSD + patents license)を紹介する。 (Raúlから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 (adsbygoogle = window.adsbygoogle || []).push({}); 現在オープンソースコミュニティで起こっていることには落胆させられる。 特に、オープンソースのおかげで多くのスタートアップやビジネスが存在することを認識したときは。 独占的なソフトウェアのために法外なライセンス料を払わなければならないとしたら、それらは存続できない。 オープンソースとは、より良いソフトウェアをみんなで構築するためのコミュニティをつくることだ。 それを、— Facebookが意図しているような — 人々の権利を交換するための市場として決して使用すべきではない。 Facebookは「BSD + patents」というライセンスモデルを推進している。 広く人気のあるReactを含む、すべてのプロジェクトで。 基本的に、「BSD + patents」はコードが(誰でも参照し利用できるように)公開されていることを意味するが、しかしそれは常にFacebookの著作物でもある。 そして彼らは、君がFacebookを特許侵害で訴えないで 仲良くやっている限り、君に特許ライセンスを与える。 Facebookを訴えた瞬間、Reactの他、君の使っているあらゆるFacebookの「オープンソース」技術の特許権は自動的に取り消されてしまう。 アディオス、バイバイ、どこかへ行ってしまう。 (https://github.com/facebook/react/blob/b8ba8c83f318b84e42933f6928f231dc0918f864/PATENTS) この問題は、Apache Software Foundationによって衆目にさらされることとなった。 この制限は広大で、残忍だ。 ・・・ その知的財産がReactを使用しているドメインと関連しているかどうかは関係ない。 君がReactを使うなら、Facebookが保持する特許に逆らうことはできない。 いつまでも。 言い換えれば、代償。 Facebook、それが君らの考えるオープンソースなのか? ・・・ Fridgebook Inc. 例として、君の会社「Fridgebook Inc.」はインテリジェントな冷蔵庫を販売しているとしよう。 君の冷蔵庫にはスクリーンが付いていて、独自のアプリケーションを実行していて、そのUIにはReactが使われている。 突然、Facebookは冷蔵庫業界への進出を決め、新製品「FBfridge」をわずか1週間後に世界中でローンチすると発表した。 仮に、Facebookがあなたの特許の一部を「FBfridge」で露骨に侵害していた場合、どうすればいい? そう、君は即座に彼らを訴えることはできない。 君は顧客が使うアプリにReactを使っている、だろ? もし他のもの(vue.jsとか)に移行せずに訴えたら、Reactのために与えられたライセンスを即座に失い、思いがけず君自身が違反している状態になり、ソフトウェア不正使用の訴訟を約5000億ドルの会社から起こされる可能性と戦うことになる。 君だけで。 もちろん、君は顧客サービスを中断したくはない。 だから、もし彼らを訴えたい、もしくは少なくともそれをするための効力を保持したいのであれば、記録的な期間でReactから移行できる解決策を見つける必要がある。 それが君の陥るひどい窮地だ。そうだろ? それはほとんど致命的な状況だ。 回避策?
eyecatch
Mon, Aug 14, 2017

WebdriverIOとChromeのヘッドレスモードで自動ブラウザテストするDockerイメージ: webdriverio-chrome

「2017年夏、ブラウザテストフレームワーク」の続き。 ServiceNowアプリケーションのブラウザテストをしたくて色々調べている。 前回は、フレームワークにWebdriverIOを使うと決めたところまで書いた。 今回、最終的に、WebdriverIO、WDIO、selenium-standalone、Jasmineと、Chromeのヘッドレスモードを使って、Dockerコンテナ(Alpine Linux)上でテストスクリプトを実行して、ServiceNowのログイン画面のスクリーンショットが取れるところまでできた。 そのコンテナイメージのDockerfileはGitHubに置いた。 (adsbygoogle = window.adsbygoogle || []).push({}); とりあえずAlpine Linux テスト環境の作成は自宅でやってるけど、DockerイメージにしてDocker Hubとかに上げておけば、社内でダウンロードしてそのまま再現できる。 ダウンロードに係る社内手続きも、Dockerイメージだけに対してやればいいので、中に何を詰め込んでも、後でライブラリとか追加しても、一回こっきりで済む。 というわけでとりあえず、自PC(Windows 10 Home)に入ってるVMware Workstation Player 12.5.5でCentOS 7 x64のVMを作り、Dockerをインストールして、Alpine Linuxをpullした。 $ docker pull alpine:edge Alpine LinuxはBusyBoxとmusl libcで構成された軽量な Linuxディストリビューション。 2016年2月にすべてのオフィシャルDockerイメージがAlpine Linuxベースになるというアナウンスがあったし、他にそれっぽいものもなかったので、これをベースに環境を作ることにした。 glibcじゃないのがちょっと気になるけど、まあ問題ないか。 現在、Chrome 59のAlpine Linuxパッケージがedgeブランチで作られているので、Alpine Linuxはedge(i.e. 開発中のバージョン)をpullした。 (因みに現時点でAlpine Linuxのlatestは3.6。) で、起動。 $ docker run -it alpine:edge sh Chrome(Chromium)インストール まずはChrome(がAlpine Linuxパッケージにはないので、実際にはChromium)と、ついでにChromeDriverをインストールする。 Alpine Linux独自のパッケージマネージャーであるapkを使う。 / # apk add --update chromium chromium-chromedriver / # chromium-browser -version Chromium 59.0.3071.115 無事インストールできた。 この記事を参考にヘッドレスモードで実行してみる。 ヘッドレスモードにするために--headlessを付けて、一時的な制限事項で--disable-gpuを付ける必要があって、コンテナの権限不足を回避するために--no-sandboxを付ける。 (コンテナの権限不足回避には他に、docker runに--privilegedや--cap-add=SYS_ADMIN付ける方法がある。) / # chromium-browser --headless --no-sandbox --disable-gpu https://example.com/ [0811/145902.894023:WARNING:dns_config_service_posix.cc(326)] Failed to read DnsConfig.
eyecatch
Fri, Aug 4, 2017

2017年夏、ブラウザテストフレームワーク

「2017年夏、Selenium、ヘッドレスブラウザ」の続き。 ServiceNowアプリケーションのブラウザテストをしたくて色々調べている。 前回は、Selenium(WebDriver)とChromeのヘッドレスモードを使うのがよさそうというところまで書いた。 この記事では、ブラウザテストフレームワークを選ぶ。 (adsbygoogle = window.adsbygoogle || []).push({}); ブラウザ操作ツールとかブラウザテストフレームワークとか Seleniumを直接使って、JUnitなんかのテストフレームワークでブラウザテストを書くこともできるけど、それは結構つらい。 Seleniumは低レベルなブラウザ操作APIを提供するので、単純にテスト書き辛いし、動的サイトを扱うときには、かなり気を使ってwait処理を入れていかないとテストが安定しない。 テスト前に、WebDriverの準備をしないといけなかったりするのも面倒。 なので、昨今はもう少し高級なツールやフレームワークを使うのが普通な模様。 あまり知らなかったので色々記事を読んだ。 Seleniumアレルギーのための処方箋 ブラウザテストツール総まとめ・2016年夏版 2017年JavaScriptのテスト概論 結果、ブラウザ操作ツールやブラウザテストフレームワークには以下のようなものがあることが分かった。 (SeleniumやWebDriver系じゃないのも含む。) Nightwatch.js GitHubの★は6835。 JavaScriptでブラウザテストを書けるフレームワーク。 WebDriverプロトコルに対応していて、Seleniumと異なる独自のクライアントAPIを実装。 つまり使えるブラウザの幅が広い。 テストフレームワークは独自のもの。 WebdriverIO GitHubの★は3217。 JavaScriptでブラウザを操作できるツール。 WebDriverプロトコルに対応していて、Seleniumと異なる独自のクライアントAPI(ラッパ?)を実装。 つまり使えるブラウザの幅が広い。 独自のテストランナであるWDIO付きで、テストフレームワークにMocha、Jasmine、Cucumberなど、いろいろ利用できる。 Protractor GitHubの★は6801。 JavaScriptでブラウザテストを書けるフレームワーク。 WebDriverプロトコルに対応していて、selenium-webdriverをラップしたAPIを提供する。 WebDriverなのでブラウザはなんでも。 テストフレームワークは、Jasmine、Mocha、Cucumberのほか、いろいろ選べる模様。 AngularとAngularJS向けだけどそれ以外にも使える。 Google製なので信頼感があるし、ドキュメントもコミュニティもしっかりしてる。 Casper.js GitHubの★は6337。 JavaScriptでブラウザテストを書けるフレームワーク。 使えるブラウザはPhantomJSかSlimerJSだけで、多分WebDriver使ってない。 テストフレームワークは独自のもの。 Nightmare GitHubの★は12964。 JavaScriptでブラウザを操作できるツール。 ブラウザは、昔の1系はPhantomJSを使ってたけど、今の2系はElectron。 WebDriverは使ってないはず。 テストフレームワーク機能は付いてないけど、同じ作者のNiffyというNightmareベースのツールがちょっとそれっぽい。 TestCafe GitHubの★は3029。 JavaScriptでブラウザテストを書けるフレームワーク。 すごい多機能っぽいし、TypeScriptやasync/awaitをサポートしててなんかモダン。 WebDriverは使ってないっぽいけど、Chrome、Firefox、IE、Edge、Safariなど、一通りのブラウザが使える。 なぜかリモートテストもできる。 どうもSelenium 1みたいにJavaScriptコードを挿入してテスト実行するらしいんだけど、よくわからない。 Zombie.js GitHubの★は4608。 JavaScriptでjsdomを操作できるツール。 なぜか妙にアサーション機能に凝っている。 WebDriverは使ってないはず。 Chromy GitHubの★は294。 JavaScriptでChromeを操作できるツール。 chrome-remote-interfaceをラップして、 NightmareっぽいAPIを提供する。 WebDriverは使ってない。 Codeception GitHubの★は2900。 PHPUnitとSeleniumをラップして、ユーザ視点のブラウザテスト(受入テスト)をPHPで書けるフレームワーク。 Capybara GitHubの★は7937。 Seleniumをラップして、ブラウザテスト(受入テスト)をRubyで書けるフレームワーク。 テストフレームワークはRack::Testを始め、いろいろ選べる模様。 Geb GitHubの★は759。 Seleniumをラップして、 JUnitやTestNGと連携して、ブラウザテストをGroovyで書けるフレームワーク。 Selenide GitHubの★は555。 Seleniumをラップして、ブラウザテストをJavaで書けるフレームワーク。 これらよりさらに高級なツールに、CodeceptJSというのがあって、これはJavaScriptでユーザ視点のブラウザテスト(受入テスト)を書けるフレームワーク。 基本的にはMochaとWebdriverIOをラップして、より抽象的なAPIを提供する。 WebdriverIOをProtractorとかNightmareとかAppiumに代えられて、色んな環境のテストが統一的なAPIで書ける。 すごいけどバグを踏んだ時辛そう。 また、ブラウザテストの文脈でよく名前が出るKarmaは、テストフレームワークではなくて、HTTPサーバを起動して、テストを実行するためのHTMLを生成して、ブラウザを起動してそれを読み込んでくれたりするツール(i.e.
eyecatch
Wed, Jul 12, 2017

2017年夏、Selenium、ヘッドレスブラウザ

現在仕事でServiceNow上で動くアプリケーションを開発していて、それのブラウザテストをどうやろうかというのを少し考えたので、書き残しておく。 (adsbygoogle = window.adsbygoogle || []).push({}); ServiceNowとは 本題とほとんど関係ないけど、一応ServiceNowに簡単に触れる。 ServiceNowはITサービス管理のSaaS。 世界的にはITサービス管理のデファクトスタンダードとなっているが、日本ではこれから盛り上がりそうといった感じ。 アプリケーションを開発するプラットフォームとしての側面もあり、JavaScript(ブラウザ側とサーバ側両方)でServiceNowの機能を拡張し、他システムと連携させたり処理を自動化したりできる。 アプリケーションがServiceNowプラットフォームで動くので、テスト方法が悩ましい。 Automated Test Frameworkというテストフレームワークが提供されてはいるが、2017年1月にリリースされたばかりということもあるのか、機能がしょぼく、大したことはできない。 これが自前でブラウザテスト環境を作ろうと思った理由。 アプリケーションがJavaScriptなので、テストもJavaScriptで書きたい。 ブラウザテストとは ここでブラウザテストとは、稼働しているWebアプリケーションに、HTTPクライアントで接続して、レンダリングされたWebページを操作して実行する自動E2Eテストのこととする。 HTTPでWebコンテンツを取得して、HTML・CSSをパースしてレンダリングして、JavaScriptを実行するツール、つまりWebブラウザを何にするかというのと、それを自動で操作するのをどうするかというのと、テストどう書くのかということと、書いたテストをどう実行するかということと、テスト結果をどう集計してレポートするかといった辺りを考える必要がある。 Qiitaの記事「ブラウザテストツール総まとめ・2016年夏版」にブラウザテストのためのツールが色々載っている。 レイヤや目的が異なるツールがちょっとごっちゃになってる気がするけど。 SeleniumとかWebDriverとか ブラウザテストはWebDriver抜きでは語れないので、とりあえずそれについて書く。 それにはまずSeleniumについて語らなければなるまい。 ブラウザテスト創世記にはこうある。 神は「光あれ」と言われた。 するとSeleniumがあった。 神はその光を見て、良しとされた。 神はその光と闇とを分けられた。 神は光をSelenium RC (aka Selenium 1)と名づけ、 闇 をSelenium WebDriver (aka Selenium 2)と名づけられた。 (Seleniumの歴史をもっとちゃんと知りたければこの記事を読むべし。) 要は、今ブラウザテストと言ったらSelenium、Seleniumと言ったらSelenium WebDriverというわけだ。 Selenium WebDriverは、WebDriver APIでブラウザやDOMエレメントを操作するツール。 このAPIを実装したクライアントライブラリが各言語(Java、Ruby、Python、JavaScriptなど)で提供されていて、テストコードから利用できる。 APIの裏ではドライバなるものが暗躍していて、OSやブラウザのネイティブAPIを使ってブラウザを操作している。 このドライバはブラウザごと(Chrome、Firefox、IEなど)に用意されていて、その実装形式がドライバ毎に割と違っている。 例えばFirefox用のやつ(Firefox Driver)はFirefox のアドオンを使うし、Chrome用のやつ(ChromeDriver)は独立したネイティブアプリを介してブラウザを操作する。 ドライバは(基本的に)ブラウザと同じマシンにある必要があり、実行するテストコードとも(基本的に)同居している必要がある。 テストを実行するマシンとは別のマシンのブラウザでテストしたければSelenium Server (aka Selenium Standalone Server)を使う。 Selenium Serverはブラウザとドライバと同じマシンで動き、テストコードから送信されたブラウザ操作コマンドを受信してドライバに伝える、プロキシ的な働きをしてくれる。 Selenium Serverを使えば、クライアントライブラリが対応していないドライバでも利用できるというメリットもある。 Selenium Serverを使うと、オーバーヘッドはあるけどメリットが多いので、とりあえず使うようにしておけば間違いなさそう。 Selenium Serverが受け取るブラウザ操作コマンドは、HTTPでJSONデータとして送信される。 この辺りの通信は、もともとJsonWireProtocol (aka