WebmoをNode.jsから使う

昨日の記事でも紹介したWebmoはJavaScriptで簡単に操作できることがウリですが、現状用意されているライブラリはブラウザ上で動作することを前提に設計されており、Node.jsで実行するとエラーが起きます。

エラーを直して本家にpull requestを送ろうと思っていたのですが、そう簡単ではなかったので、Node.js用に移植した新しいnpmパッケージ webmo-client-nodejs を作って公開しました。

依存ライブラリがブラウザ前提に設計されているため、サンプルコードを実行すると
ReferenceError: self is not defined というようなエラーが出ます。

変更点

  • 本家 webmo-client が依存していたqwestやQといったブラウザ用ライブラリを一掃して、websocketのようなNode.jsで足りていないライブラリを読み込むようにしました。
  • 開発言語をJavaScriptからTypeScriptにしました。
  • ビルド時、ブラウザ用にwebpackで固めていたのをtscでコンパイルするだけにしました。

詳しくはGitHubのCommitsを見てみてください。

require(‘webmo-client-nodejs’)

変更点は上の通り表層的な部分だけなので、実際の使い方は本家とほぼ同じです。ブラウザ用に require('webmo-client') と書いていた部分を require('webmo-client-nodejs') とすれば同じJavaScriptコードが動きます。サンプルコードを webmo-example-nodejs に置きましたが、めちゃくちゃ短いのでこちらにも貼っておきます。Webmo便利ですね!

var WebmoWs = require('webmo-client-nodejs').ws
var motor = new WebmoWs("webmo.local")

motor.onopen = () => {
  motor.rotate(90)
  setTimeout(() => { motor.stop(); motor.close(); }, 2000)
}

上の例はWebSocketを使っていますが、HTTPもテスト済みです。

var WebmoHttp = require('webmo-client-nodejs').http
var motor = new WebmoHttp("webmo.local")
process.stdout.write('testing http client ...');

motor.rotate(-90)
.then(() => {
  setTimeout(() => {
    motor.stop()
    .then(() => {
      process.stdout.write(' ok\n');
    });
  }, 2000);
});

というわけで、Happy hacking with Webmo!

Webmoを試す

WebmoはJavaScriptから気軽にサーボモータを操作できるIntel Edisonベースのデバイスです。Webmoを電源に繋ぐだけで、Wi-FiアクセスポイントとWebサーバが立ち上がります。Wi-Fiアクセスポイントに接続すると、JavaScriptのライブラリでサーボモータの状態を取得・設定したり、WebブラウザでWi-Fiアクセスポイントの設定を変えたりできます。

Intel Edison終売の噂があって今後どうなるか分かりませんが、公式サイトの「Webmoの始め方」に載っていない情報をメモ代わりに書き留めておきます。

Windowsで有線(USB)接続

公式サイトの「Webmoの始め方」に沿って進めればWebmoを使い始めるのは簡単だと思います。ただ、Macユーザに最適化されたマニュアルになっていて、Windowsだと有線接続で捜査できないように読めてしまいます。実際には有線接続はMacより簡単です。

Webmoを電源に繋いで起動したあと、PCにUSB Type micro-B⇔Type Aケーブルで繋ぐと、とくに何もドライバを入れなくてもUSB複合デバイスとして認識されます。

デバイスマネージャには「ユニバーサル シリアル バス コントローラー」以下に「USB Composite Device」が、「ディスク ドライブ」以下に「Linux File-CD Gadget USB Device」が、「ネットワーク アダプター」以下に「Intel Edison USB RNDIS Device #(n)」が表示されます。

…と書いたのですが、もしかするとIntel Edison用ドライバを以前インストールしたことがあったからかもしれません。デバイスマネージャに上のような表示が出ない場合は「Intel Edisonのセットアップ」にあるようにインストーラを起動して最初の項目が「USB drivers installed」「Repair Drivers >」という表示になるようにドライバをインストールしてください。ちなみに、Flash Firmware以下のボタンをクリックしてしまうとWebmoのファームウェアがリセットされたり設定が書き換わったりするので、そのあたりの意味を100%理解していない限り絶対にやらないようにしてください。

また、USBケーブルを挿すタイミングによってはデバイス識別子の取得に失敗して、USB複合デバイスとして認識されない場合があります。そのときは、デバイス マネージャー上で認識に失敗しているUSBデバイスを右クリックし、いったん「無効」にしてから再度「有効」にすると認識されます。

microUSBで接続後は、ネットワーク アダプターのIPアドレスを手動で 192.168.2.2 に設定し、ネットマスクを 255.255.255.0 に設定すれば、Webmoが 192.168.2.15 で見えるようになります。

コントロールパネルの「ネットワーク接続」にWebmoを表す「Intel Edison USB RNDIS Device #(n)」が表示されます。

右クリックで出るメニューから「プロパティ」を選んでIPアドレスなどの設定を変えられます。

「インターネット プロトコル バージョン 4 (TCP/IPv4)」の「プロパティ」がこの画面のようになるよう設定すればIntel Edisonに繋げるようになります。

ここまでできたら、ブラウザで http://192.168.2.15 にアクセスしてみてください。Webmoの設定画面が表示されるはずです。(「Webmoの始め方」には http://192.168.42.1/ と書いてありますが、RNDISのときのIPアドレスは自動的に 192.168.2.15 になります。これはIntel Edisonベースのデバイスで共通です。)

WebmoにSSHログイン

Webmoに限らずIntel Edisonベースのデバイスは適切に設定すると root アカウントでSSH接続できるようになります。Webmoの場合は、「Webmoの始め方」に書いてあるように、USB接続したPC上に表示されるUSBドライブ内の「id_rsa」を秘密鍵として使うことでログインできます。例えば次のようなコマンドになるでしょう。

ssh -i ~/.ssh/id_rsa_webmo root@192.168.2.15

WebmoにSSHログインして ls-al したり systemctl でデーモンの状態を確認したりしてみました。

これまでHTTPでホストしていた研究会サイト sigpx.org と個人サイト junkato.jp をHTTPS化しました。前者はCloudflare、後者はLet’s Encryptを使いました。どちらも無料でした。

できればCloudflareで統一したかったのですが、事情があって別々の方法を取りました。また、手順自体はシンプルだったのですが、単純に移行するとはてなブックマークやFacebookのLikeなどが引き継がれないので、その対応が少々面倒くさかったです。

CloudflareでGitHub PagesをSSL化

SIGPXのWebサイトはGitHub Pagesでホストしています。GitHub Pagesは github.io のサブドメインであればSSLでアクセスできます(例: https://sigpx.github.io)が、独自ドメインを使うと直接はSSL化できません。

Cloudflareを使った具体的なSSL化の方法についてはすでに日本語の記事がQiitaなどにあがっているのでそれを参照すると簡単だと思いますが、英語ならCloudflare自身の ブログ記事もあります

仕組みとしては、独自ドメインの名前解決をするときにCloudflareのネームサーバを見に行くようにすることで、HTTPであれHTTPSであれ、アクセス時にGitHub PagesのサーバではなくCloudflareのサーバへアクセスが飛ぶようにしています。

そして、以下のように、CloudflareがリバースプロキシとなってブラウザとGitHub Pagesサーバ間の接続を仲介することで、もともとのGitHub Pagesと同じコンテンツへのアクセスが可能となっています。

設定の途中で、独自ドメイン契約先でネームサーバの設定を変更する作業が必要です。お名前.comの場合は、「ドメイン設定」「ネームサーバーの設定」「ネームサーバーの変更」からネームサーバーをCloudFlareに指定されたものに変更します。

最終的にCloudflare上のDNSに関する設定は次のようになります。

あとはサイト上で参照しているすべてのリソースがHTTPSで統一されていることを確認します。(そうしないとブラウザのアドレスバーに「安全でない通信路」の情報が出続けます。)

GitHub PagesもCloudflareも無料の範疇で転送データ量の制限などがあるようですが、ふつうに使うぶんには全く問題なさそうです。

Let’s Encryptでさくらインターネットの共有サーバ上のサイトをSSL化

さくらインターネットのスタンダードプランでホストしている個人サイト junkato.jp もCloudflareでSSL化できれば簡単だったのですが、そうはいきませんでした。設定後、Cloudflareの「Error 1000」が出るようになったのです。まったく同じ問題で困った人のブログ記事があって助かりました。記事から引用すると、起きている現象は以下のとおりです。

  1. クライアントがさくらのレンタルサーバ(https)に対して要求を送信する
  2. さくらのレンタルサーバ(https)の443番ポートは80番ポートへのプロキシなので名前解決を行う
  3. 名前解決した結果、当然CloudFlareのIPアドレスが返ってくるので、そのアドレスを使用しhttpで接続を試みる
  4. CloudFlare(http)はさくらのレンタルサーバ(http)へ接続を試みてコンテンツを取得する

後で知ったのですが、サイト全体をWordPressで運用している場合はさくらインターネットの公式プラグインがあるようです。自分の場合はそうではなかったので、Cloudflareを諦めてLet’s Encryptで証明書を取ることにしました。

SSL化自体は、Qiitaで「さくらレンタルサーバーに独自SSL「Let’s Encrypt」導入(Windows10編)」という記事を書いている方がいたので手順に従うだけでとても簡単でした。

はてなブックマークとFacebook Likes

WebページのURLが変わる(httpがhttpsになる)ので、これまでのブックマーク数やLikesは引き継げません。ただ、見た目上引き継ぐことはできます。

はてなブックマークの場合はウィジェット表示部の a タグに data-hatena-bookmark-url 要素を設定するとブックマーク対象のURLを変更できます。(ボタン設置用フォームの「保存するURL」欄に対応)

Facebookの場合は同様に data-href 要素を設定します。(Share Button ConfiguratorのURL to shareに対応)

静的なページの場合は個別にこの対応をしていけばよいのですが、問題はWordPressで運用しているブログ(このページ)でした。HTTPS化する前のページはHTTPのURLで、HTTPS化したあとのページはHTTPSのURLでシェアボタンの類を設置したいので、利用しているWP Social Bookmarking Lightのソースコードを編集して対応しました。

変更点は以下のとおり:

https://github.com/arcatdmz/WP-Social-Bookmarking-Light/commit/d48293c05cde3fbe41a4ab8622cac488f6a71549

日付の判定はService.phpの50行目で行っています。

そんなわけで、意外と考えることは多かったですがちゃんとHTTPS化できました。Let’s Encryptの証明書更新も自動化したいのですが、さくらインターネット側がAPIのようなかたちで対応してくれないと難しいかもしれません。(ヘッドレスブラウザでログインから自動化する?)

昨年IPSJ-ONEに登壇した際の記事「情報処理が科学を更新する」では「Science as a Service」というコンセプトを解説し、プログラミング環境技術を伸ばしていった先に、効率的で再現性の担保された科学研究があるという旨を議論しました。

こうした流れについてはもはや止められるものでなく、実際にいろいろな事例を見聞きするようになってきました。ここでいったん、自分から見えている現状をまとめておこうと思います。他にも事例や研究コミュニティをご存知の方がいらっしゃいましたら、ぜひお知らせください。

再現できない!

以前の記事で引いたのは2016年初頭の「生物医科学論文の大半に不備、信頼性に疑問符」と題するAFP通信の記事で、元となった調査は2016年1月4日のPLoS Biologyに掲載されたMeta-Research Articleでした。その後も、2016年5月4日付のNature Newsで1500人の科学者を対象にした再現性に関する調査結果が公開されました。調査対象のうち70%以上が再現実験に失敗したことがあり、過半数が自分の実験ですら再現できなかったことがあるといった内容です。こうした危機感は研究者コミュニティのなかでは相当共有されていると思います。

再現実験の取り組みは以前からあって、例えば2012年にはLJAF Foundationから著名な癌研究を検証するために130万ドルのファンディングがScience Exchangeというスタートアップに提供され、Validation by Scientific Exchangeというプロジェクトになっています。2015年8月には心理学実験の論文100本を再現した研究で、元々の論文のうち97%で統計的な有意差が報告されていたのに対し、再現実験では36%でしか有意差が観察されなかったことが明らかになりました。2016年7月にはオランダの科学予算から再現実験のためだけの300万ユーロのファンディングが立ち上がりました。日本で私と近い研究コミュニティだと、みんなで既存研究の再実装をして知見を共有しようというCG技術の実装と数理という勉強会があります。

論文が大量に刊行され、査読者以外誰にも知られず忘れられていくことが問題の一端にあるとすれば、みんなで論文読み会をしてよく分からない論文を顕在化してしまうのも解決策の一つになるかもしれません。私の研究分野(Human-Computer Interaction)では、毎年600本近く刊行される論文を分担して紹介し合うCHI勉強会が何年も開催され続けています。Computer Vision分野にもcvpaper.challengeという同様の試みがあります。

なぜ再現性のない論文を書いてしまうのか

再現性が取れないような実験論文を書いてしまう原因の一つに、実験をする段階で研究者側に思い込みがあって、それが反映された計画を立ててしまう、あるいは、結果を収集する段階で無意識に結果を選別してしまうといったことが挙げられます。そこで、心理学のジャーナルの一部では、実験計画を立てる段階で、実験を行う前に、ジャーナルに対して「Pre-registration」──すなわち実験内容を報告することになっています。これはユーザスタディを伴う論文をよく執筆する私の研究分野でもすぐ実現できそうで、極めて興味深い取り組みだと思います。

また、もう一つ、より根本的な原因として「CNS (Cell, Nature, Science)」などと呼ばれるトップジャーナルが権威を持ちすぎたことが挙げられます。トップジャーナルに採録されたいがために、歪んだ研究プロセスを採ってしまうことがありうるのです。トップジャーナルが権威を得てきた過程については、最近のGIGAZINEの記事「メディア王ロバート・マクスウェルが『科学』から巨万の富を搾り取る科学出版システムを作った方法とは?」でも紹介されています。少し検索しただけでも、高額な契約料を強いるElsevierに対し大学図書館がボイコットした件についての日本語の論考が出てきました。

こうした批判の一方で、Elsevierは多くの研究を効率化するスタートアップを買収しており、巨人としての責任を果たそうとしているようにも見えます。スタートアップ界隈での科学技術研究を推進する取り組みについては馬田さんの記事が詳しいので、ぜひ読んでみてください。

現時点ですでに研究者の方なら、最近は予算獲得などの過程で研究不正を防ぐための講義が義務付けられていることが多いため、学びの機会が半強制的に得られていると思います。一方、これから研究者になる人が研究の方法を学ぶ機会も増えてきているようです。例えば東京大学では、一年生から科学の技法を学ぶゼミがあるようです。僕が在学中にはなかったので羨ましい!これに関連した書籍「科学の技法」の書評も参考になります。(ちょっとオフトピックですが、同じ人の書評で「科学の経済学」も気になりますね。)

再現性のある研究発表フォーマットとは

そもそも論文という静的な紙面を基本とするフォーマットは、抽象的な考え方や得られた知見、つまり研究の結論をコンパクトに伝えるのには向いているけれども、結論に至った研究のプロセスのように具体的で雑多な情報を伝えるのが難しいという問題もあります。

そこで、記事「情報処理が科学を更新する」中の発表資料では「結果の共有からプロセスの共有へ」という流れを紹介しました。例えば、数学的証明をプログラムで自動化することで複雑な証明を機械検証可能なソースコードとして書けるようにする証明支援システムCoqや、生物学実験のハードウェアとソフトウェアをオープンソース化するDIYbio、複雑なデータの可視化を容易にするCytoscapeなどを事例として挙げています。

ここまで幅を広げなくても、論文フォーマットを改善しようとか、論文に付随するデータやソースコードをもっと重視しようという試みが近年コンピュータ科学を中心に広まっています。私の研究分野では論文にデモ動画をつけて投稿するのが当たり前になっていますし、Autodeskの研究者は動画を論文PDF中に埋め込んで投稿してしまおうと提唱しています。さらに、私から見て分野横断的に一番盛り上がっているのが、これから紹介する「Artifact Evaluation」です。

Artifact Evaluation

コンピュータ科学分野の最大学会であるAssociation for Computing Machinery (ACM)は「Artifact Review and Badging」というタイトルで各分野の予稿集において「論文だけでなく対象となるシステムや取り扱ったデータ(artifact)を公開することを推奨し、一定の基準をクリアした論文にバッジを付与して讃えよう」というポリシーを表明しています。Artifact Evaluationと呼ばれるこうした試みはACMのなかでもソフトウェアに関する国際会議で始まったようです。例えば Artifact Evaluations for Software Conferences とか Artifact Evaluation for Computer Systems’ Research といったWebサイトに情報がまとまっています。この取り組みをサポートする会議では、プログラム委員会の他に、Artifact Evaluation Committeeという委員会が編成されます。似たような試みが最近コンピュータグラフィクスの国際会議であるSIGGRAPHでも始まっており、 Graphics Replicability Stamp Initiative で再現が容易な論文発表の一覧を見ることができます。

これらのArtifact Evaluationでは論文投稿者はGitHubなど誰でもアクセスできるソースコードリポジトリにすべてのソースコードとデータを置くことが一般的となっています。こういった取り組みは、近年のDeep Learning関連の研究でも頻繁に見られます。研究者の方で自身の研究成果をGitHubに置いてみたいと思ったら、日本語だと「あなたの研究を可視化させるGitHubのすすめ」という記事が参考になると思います。

コンピュータ科学に寄った話をしましたが、コンピュータは今やどんな研究分野でも使われています。とくに統計処理やデータの可視化などでコンピュータは大活躍しています。 scientific computing とか data-intensive science といったキーワードで調べると、関連する諸分野がいろいろ出てきます。とくに若い世代の研究者は、GUIのツールを使うだけでなく、統計処理やデータの可視化を自分でプログラムのソースコードを書いて行っています。前出のArtifact Evaluationはコンピュータ科学以外の分野でも行えるはずだし、実際にいろいろな研究コミュニティがそういう方向に進んでいます。

Artifact Evaluationを可能にする技術

だんだん、私の専門であるプログラミング環境の話に近づけていきましょう。ソースコードやデータを配布する取り組みが現実的になってきた背景には、プログラミング言語や仮想化技術の発展があります。かつては、ソフトウェアのソースコードを書いても、それが実行できる環境は限られていました。ソースコードだけを配布しても意味がない研究が多かったのです。そこで私が注目している技術は二つ、DockerとJupyter Notebookです。

Dockerは本質的には軽量な仮想化技術ですが、その周りを取り囲むツールや思想が非常に先進的です。すなわち、ソースコードをコンパイルして実行するための「環境」を記述する専用のフォーマットとしてDockerfileがあり、これを他の人から受け継いでさらに編集したりできるのです。これによって、例えば論文で使われているシステムをすぐ実行できるだけでなく、査読者がソースコードを編集してコンパイルし直して他のパラメタを試したりできます。そういった可能性は例えば2015年のブログ記事「Docker for data-intensive science」で議論されていますし、生物学関連の便利なライブラリや開発環境をDocker化してみんなで共有できるようにした「Bioshadock – Docker for Science」という取り組みがあります。Bioshadockは論文にもなっているようです。

Jupyterはある意味そのさらに上のレイヤーの取り組みで、コンピュータの深いところまで知らない科学者でも容易に使えるWeb上のプログラミング環境の一種です。こう書くとプログラミングできないと使えないように思われるかもしれませんが、Google Docsにプログラミング機能を足したものといったほうがよいかもしれません。日本語だとほぼプログラマ向けの情報しか出てきませんが(私が科学者・研究者向けに情報をまとめたほうがいいのか…?)例えば簡単な説明スライドが見つかりました。生物学者向けにはPLoS Computational Biologyの2017年5月の論文でJupyter and Galaxy: Easing entry barriers into complex data analyses for biomedical researchers」という紹介記事があります。

こうした技術のおかげで、コンピュータ上のソフトウェアレベルでの再現性というのは飛躍的に向上したと言えると思います。あとは、実際の実験室、すなわち物理世界で行われているウェットな実験プロセスをどうやってコンピュータで扱えるようにするか、という問題が残されています。これについてはまだまだ研究が必要だと思っていて、私の研究でいえばインターネットに繋がったデバイスを簡単に設計、出力できるf3.jsなどが深く関連すると考えているのですが、その話はまたいずれ。

Computer Scientists as Toolsmiths

この記事では、長らく問題視されてきた「研究の再現性」について、なぜ再現できないのか、なぜそうした研究をしてしまうのか、再現できる研究発表をするにはどうしたらいいのか、いろいろな事例を引きながら考えてきました。コンピュータ科学者である私としては、科学研究の方法をコンピュータを使って革新していくのが建設的な解決策だと信じています。

そうした考えをもっともよく表していて好きな言葉が「Computer Scientists as Toolsmiths」です。同名の論文から引用します。

If the computer scientist is a toolsmith, and if our delight is to fashion power tools and amplifiers for minds, we must partner with those who will use our tools, those whose intelligences we hope to amplify.

というわけで、こうした研究に興味のある方、情報をお持ちの方はぜひお知らせください。研究者の道具はもっとよくできるはずで、それは、研究の再現性を向上させる以上の価値を生むはずです。

学生向けおすすめ記事は、基本的に自分が学生の頃の体験をもとに書いています。博士課程を一昨年修了したので、新しい記事を書くことはもうないだろうなぁと思っていました。ところが、今年の国際会議ACM UIST 2016でStudent Volunteer Chairを拝命したため、今度は学生に仕事をお願いする立場で学生の役得を実感することになりました。

この記事では、Student Volunteer (SV)の概要、SVになる方法と、なった場合のスケジュールなどについて紹介します。なお、ACM(コンピュータ科学系の国際学会)主催の国際会議を前提に話しているので、別の分野や別の学会ではちょっと勝手が違うかもしれません。

ACM UIST 2016 Student VolunteerとSV Chairの集合写真


Continue Reading…