RSpec の feature spec でヘッドレス Chrome を使う

Speee エンジニア組織推進室の服部 (yhatt) です。

みなさん E2E テストされていますでしょうか。弊社の Ruby on Rails プロダクトにおいては、RSpecCapybaraPoltergeist を組み合わせ、 feature spec で E2E テストを行う構成が一般的でした。

そんな中、Chrome 59 に ヘッドレスモード (--headless) が搭載 されたことで、テストや CI 環境において、最新の Chrome 環境による E2E テストを実施できるようになりました。それに合わせて、PhantomJS のコアメンテナーがメンテナーを降りる ことを発表し、PhantomJS のアップデートや、継続的サポートは期待できない状況となっています。

そこで今回、社内プロダクトのRSpec における feature spec の実行環境を Poltergeist から ヘッドレス Chrome に移行しましたので、その手順をご紹介いたします。

PhantomJS (Poltergeist) の利用につきまとう問題

PhantomJS は古い Webkit をベースにしているため、最新の JS/CSS の機能に追随できていません。より厳密に言えば、PhantomJS は Qt のコンポーネントである QtWebKit を使用していますが、Qt ではすでに QtWebEngine に移行しています。

実際にあった例として、『ベンダープレフィックスの無い Flexbox を使ったら feature spec が落ちた』ということがありました。今回適用した社内プロダクトの開発では、対応ブラウザを限定できていた ため、実戦投入可能という判断で、ベンダープレフィックス無し Flexbox の採用に踏み切りました。

しかし、PhantomJS では『ただのブロック要素としてレンダリングされてしまった結果、すぐ下にあったフォームの上に覆い被さった』という現象が発生し、該当フォームのクリックを含む feature テストが落ちてしまいました。

f:id:yuki-hattori:20170615104248p:plain:w500

autoprefixer を入れて対処するという選択肢もありましたが、CI のためだけに対応バージョンを広げるのは本質的ではない解決策のため、ヘッドレス Chrome の採用に舵を切りました 。

安定版の Chrome をテスト環境に採用することで、『よりエンドユーザーの環境に近い状態でテストを回せる』というメリットもあります。

ヘッドレス Chrome への移行

もしすでに Capybara を使って feature spec のテスト環境を導入していれば、ドライバを変更するだけで実行環境を変更できるので、移行自体はそんなに難しくありません。

以下、『Poltergeist による feature spec テスト環境が導入されている』という前提に基づいて説明していきます。

selenium-webdriver gem を導入

まず、Capybara で feature spec を実行するドライバを Poltergeist から Selenium に変更します。

 group :development, :test do
   gem 'rspec-rails'
   gem 'capybara'
-  gem 'poltergeist'
+  gem 'selenium-webdriver'
   ...
 end

Gemfile を編集したのち、bundle install を実行してください。

capybara + selenium-webdriver の構成は、Rails 5.1 から標準構成になりました ので、新規に Rails アプリを作った場合、この 2 つの gem は特に意識せずとも入っているはずです。

Capybara のドライバ設定で ヘッドレス Chrome を使う

続いて、Capybara のドライバを Selenium 経由で ヘッドレス Chrome を使用するように設定します。

Poltergeist の設定を外した上で、spec/support/capybara.rb に以下の内容を記述します。

require 'capybara/rspec'
require 'selenium-webdriver'

Capybara.register_driver :selenium do |app|
  Capybara::Selenium::Driver.new(app,
    browser: :chrome,
    desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome(
      chrome_options: {
        args: %w(headless disable-gpu window-size=1680,1050),
      },
    )
  )
end

Capybara.javascript_driver = :selenium

※ 事前に spec/rails_helper.rb の23行目 にある Dir[Rails.root.join('spec/support/**/*.rb')].each { |f| require f } がコメントインされていないと、正しく動作しません。

chrome_optionsargs 1 に、headless というオプションが含まれているのを確認してください。ヘッドレス Chrome ことはじめ  |  Web  |  Google Developers によると、現在の最新安定版である Chrome 59 では disable-gpu オプションも必要です。

ウィンドウサイズは必須ではありませんが、レスポンシブなコンテンツなどにおいては挙動が変わってしまう可能性もありますので、テスト環境を揃えるために指定しておくことをお勧めします。

テスト実行環境に ChromeDriver を入れる

テストを実行する前に、忘れずに ChromeDriver を入れておきましょう。最新バージョンの 2.30 が Chrome 59 に対応しています。

macOS ユーザーであれば、Homebrew で導入しても構いません。

$ brew install chromedriver

テスト実行

以上で、ヘッドレス Chrome で feature spec を実行する準備ができました。試しに js: true のテストだけ、狙い撃ちで実行してみましょう。

bundle exec rspec --tag js

実行中は Chrome のインスタンスが立ち上がり、macOS 環境の場合、Dock にアイコンが表示されることが確認できます。

f:id:yuki-hattori:20170615095247g:plain

無事テストが通れば万々歳ですが、現実的には、修正が必要な箇所(=Poltergeist では動くが Selenium で動かない箇所)も少なくないと思いますので、そのようなテストは少しづつ潰していきましょう。例えば、以下のようなテストに要注意です。

  • ドライバ固有のメソッドをテスト中に使用している
    • テスト中に driver を直接使っていたら注意!
  • ウィンドウ関連の操作
    • 新規ウィンドウを開く、リサイズするなど
  • モーダル関連
    • window.alert() window.confirm() など
    • 現時点では Capybara を適切に設定にすることで回避可能 1
      • [2017/06/19追記] Capybara 2.14.3 のリリースにより、ほぼ問題は出なくなりました

ヘッドレスモード中にスクリーンショットを撮る

Chrome 59 のヘッドレスモードで、Capybara の #save_screenshot を使用してスクリーンショットを撮影しようとすると、1x1 の何もない画像が撮れてしまいます。

f:id:yuki-hattori:20170615095522p:plain:w500

これは Chrome 側の問題のようで、以下の Issue を見る限り、既に解決している模様です。

この変更がリリースされるまでは、『スクリーンショットを撮るときは ヘッドレスモードを OFF にする』というのが暫定対策となりますが、待てない方は Google Chrome Canary をテストで使用すると良いでしょう。2

Google Chrome Canary をテストに使用する
Capybara.register_driver :selenium do |app|
  Capybara::Selenium::Driver.new(app,
    browser: :chrome,
    desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome(
      chrome_options: {
        args: %w(headless disable-gpu window-size=1680,1050),
        binary: '/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary',
      },
    )
  )
end

binary で、実行する Chrome のパスを指定することができます。上記は macOS 環境での例です。

一応、Canary は 常に更新され続ける(毎日更新される)開発版を使用することになる ので、安定版とは挙動が異なる可能性もあることに注意してください。

ベンチマーク

簡易ですが、rspec --tag js -p コマンドにてベンチマークをとってみました。対象は 12 examples の小規模なプロジェクトで、Chrome は安定版 (59) を使用しています。

環境 rspec コマンド実行時間 examples 実行時間
Poltergeist (PhantomJS) 17.81 sec 11.65 sec
Selenium (Chrome 59) 22.75 sec 15.97 sec

rspec --tag js -p を 5 回試行した平均値
※ examples 実行時間 = Total time - files took seconds to load

Poltergeist + PhnatomJS に比べて、ヘッドレス Chrome は コマンド全体で 約 1.37 倍の時間増 となりました。

ヘッドレス特化ブラウザ → フルブラウザ による時間増は仕方ない部分もありますが、体感では、#visit#click などによる ページ遷移 で速度差を感じることが多かったです。例えば、4 回のページ遷移を含む example では、2.71sec (PhantomJS) → 4.32sec (Chrome) と、約 1.59 倍 にまで遅くなりました。

ユニットテストが中心で、E2Eテストがある程度絞られている 小規模〜中規模のプロジェクトだと 気にならないかもしれませんが、大規模なプロジェクトで E2E テストが多く書かれている場合、この時間増がけっこう響きそうです。

まとめ

RSpec の feature spec をヘッドレス Chrome へ移行する手順について解説しました。

これまでも Xvfb を使うことで、実際のブラウザを使ってヘッドレスに自動テストができましたが、今回のヘッドレスモードの実装で、CI でも開発環境でも、より簡単にヘッドレスなテストが実現できるようになり、ハードルが随分下がった印象を受けました。

また、Firefox にもヘッドレスモードが搭載される予定 のようで、今後の E2E テストは、エンドユーザー向けのブラウザを直接動作させる形に収束していくのでは? と思っています。

それでは良き E2E テストライフを。

参考記事


  1. [2017/06/19修正] 初稿では、 args がハッシュロケット記法になっていました。Capybara 2.14.2 時点では、Capybara の ヘッドレス Chrome 判定が特定の構造の Hash しか受け付けない ようになっており、Symbol キーにしてしまうと accept_confirmdismiss_confirm の挙動に影響が及ぶ(該当 Issue comment…)ためです。この問題は 2.14.3 で修正されています。該当 Commit…

  2. Chrome は ベータ版 や開発版も提供していますが、既存の Chrome 安定版を上書きする上、戻すのも面倒なので、開発環境での導入はあまりお勧めできません。Google Chrome Canary であれば、安定版と共存することが可能です。

roppongi.rb #3 "Rails x Frontend-Tech" まとめ

Speee技術顧問の id:gfx です。 2017/05/31 に Roppongi.rb #3 開催のためSpeee Loungeを提供いたしました。私も「RailsエンジニアがReactを始めてSSRとReduxを導入するまで」と題した発表をしましたが、普段使っているReactベースの環境とはまたったく別のAngualrやRiotなどの話を聞けましたし、大変すばらしい勉強会だったと思います。

セッション

オープニング by toshimaru

オープニングでは、主催者の @toshimaru_e さんからの挨拶に変えてRailsフロントエンド技術の今とこれからについてのエントリの紹介がありました。

Railsフロントエンド技術の今とこれから - Hack Your Design!

Rails x Frontend は今後ますます重要になっていく技術なので、上記エントリはいいまとめですね。

RailsエンジニアがReactを始めてSSRとReduxを導入するまで by gfx

私の発表で、最近のKibelaのフロントエンドで実践していることについて話しました。詳しくは次のエントリをご覧ください。

登壇エントリ: Roppongi.rb #3 で「RailsエンジニアがReactを始めてSSRとReduxを導入するまで」という発表を行いました - Bit Journey’s Tech Blog

社内で初SPAをAngularで完成させるまでとその後 by hatappi

弊社のエンジニアである@hatappiさんによる発表で社内でAngularでSPAを作成した話でした。 詳しくは次のエントリをご覧ください。

『社内で初SPAをAngularで完成させるまでとその後』という話しをRoppongi.rbで話してきた - hatappiのブログ

Universal JavaScript by mizchi

mizuchiさんによる発表でした。Sprocketsの殺し方やこれからのJavaScript bundle技術の行く末などに関するお話でした。nativeのES modulesがブラウザに実装されるとwebpackが廃れてるだろうという予言は私も同意します。

Universal JavaScript // Speaker Deck

片手間JS on Rails by tricknotes

tricknotesさんによる発表でした。フロントエンドのビルドツールは多様過ぎるし進化も早すぎるというのはよくいわれることですが、作るもの次第ではRails標準のSprocketsもそんなに悪くないよという話でした。実際のところ、KibelaでもSprocketsはまだまだCSS周りでも使ってますし、適材適所というのは本当にそのとおりだと思います。

片手間JS on Rails

そのSPA、本当に必要ですか? by nishaya

弊社エンジニアのnishayasさんによる発表でした。nishayaさんもSpeeeのエンジニアです。SpeeeのエンジニアのひとりはSPAを作った話をし、もうひとりは無闇にSPAにすべきでない話をするという結果になりました。攻めてますね。もっとも、「軽い気持ちでSPAに手を出さない」というのは私も同意します。

そのSPA、本当に必要ですか? // Speaker Deck

ReactをやめてRiotに移行した話 by pompopo

pompopoさんによる発表でした。Reactはデザイナとの協業が難しけどRiotだとデザイナに抵抗感少なく触ってもらえるというのが移行の理由ということですが、確かにそのあたりはReactの課題だとは思います。Reactを使い続ける場合でも、React Storybook のような仕組みを整備して抵抗感なく触ってもらえるなどの工夫が必要かもしれないですね。

ReactをやめてRiotに移行した話 // Speaker Deck

【PR】Speee Loungeについて

SpeeeではラウンジをIT技術に関する勉強会や交流会のために貸し出しています。詳しくは次のエントリをご覧ください。

Speee Lounge 会場貸出について - Speee DEVELOPER BLOG

勤怠打刻機をRaspberry Pi 14台で本気で作ってみた

こんにちは、プロジェクト推進室でエンジニアをやっている 山本 (id:bino98) です。

毎日のお勤め、お疲れ様でございます。皆さまが、日々の業務を行われる合間に

  • 有給休暇を取得したり
  • 遅刻の連絡をしたり
  • 出張の申請を行ったり…。

様々な場面で自身の勤怠をその組織のやり方で管理されていると思います。弊社では、今年4月初頭から 社内で開発した新しい勤怠管理システム「 SpeeePORT 」による勤怠管理が始まりました。

弊社の新しい勤怠管理システム(以下、PORT)に関する詳しい記事は、ITproさまがこちらの記事にまとめてくださいましたので、ご覧頂けますと幸いです。

今回、PORTの ウリ の1つの 打刻機 について、まとめました。Raspberry Pi で打刻機を作りたいという、結構ニッチな要求を持つ方のお役にたてれればと思います。

Raspberry Piで打刻機を内製した経緯

こちらの記事にあるように、打刻忘れの問題は以前から発生していました。PORTを利用前の勤怠管理システムでは、出勤・退勤打刻をWebブラウザ上で行う必要がありましたが、その存在は忘れられがちだったのです。

打刻が忘れられないように、ICカードによる打刻の実現が社内で強く求められ、 アップデートされてきた弊社の新しい勤怠制度に適合できる勤怠管理システムを内製で開発することとなりました。

Raspberry Piを利用した理由は、

  • 安価で入手容易である
  • 自分たちの用途に応じてカスタマイズできる
  • PasoriとRaspberry Piを連携された事例がインターネット上に存在する

などの理由で使用することを決めました。

打刻機の利用方法

まず、打刻機の種類の話からですが、PORTでは2種類の打刻機を用意しています。1つは、打刻機。 f:id:bino98ty:20170605101952j:plain

もう一つは、打刻登録機です。 f:id:bino98ty:20170605102119j:plain

打刻機を利用して、勤怠打刻を行うためにはユーザには下記のフローを実施してもらいます。

  1. 個人や会社で利用している 交通系ICカードを用意 してもらう
  2. 打刻登録機 にICカードをタッチしてもらう
  3. 画面にQRコードが表示されるため、手持ちのスマホ等で読み取ってもらう
  4. 読み取ると、カードの登録がされる*1ため、あとは 打刻し放題 になる

打刻登録機はカード登録時に必要ですが、頻度はきっと多くないはず。普段使いの打刻にはディスプレイもキーボードも不要ですね。故に、普段は極力小型で、低コストで量産できるRaspberry Piを用いた打刻機を利用してもらっています。

ピッとすると打刻される仕組み

f:id:bino98ty:20170605110135p:plain

打刻機と打刻登録機は実は使用しているアプリケーションは同じです。まず、Pasori*2を利用するためのライブラリnfcpyをPythonを利用した読み取りプログラムを記述し、そのプログラム上でPORTのAPIに打刻リクエストを送信します。カードが未登録の場合はその旨のレスポンスが返ってくるため、打刻機側でそれを解釈し、同一リクエスト内に含まれるワンタイムURLをQRコードにして、イメージファイルとして保存しておきます。打刻機の場合は、ここまでです。

打刻登録機の場合は、発行されたQRコードを表示するためのプログラムも起動しており、node + expressで動かしてます。nodeでは、QRコードが保存されるディレクトリを常に監視し続け、ファイルに変更があれば(すなわち、QRコードが新たに発行された場合)画面を再描画するような仕組みになっています。

十数台の打刻機があるとたまにサボるやつが居るものだ

Raspberry Piを用いた打刻機ですが、不意に停止してしまうことがあります。例えば、

  • WiFiとのコネクションが切れたまま、復旧せず打刻できなかったり。
  • 一定以上使われないと勝手にプロセスが閉じて打刻できなくなったり。

打刻をするタイミングは朝出社前がほとんどであり、その時間帯に「 打刻機動かんけど、どうなってるの? 」などとお問い合わせを受けると、なかなか辛くてお腹が痛くなると思います。

そこで、PORTの打刻機には監視プログラム、自己診断送信プログラム、再起動プログラムの3つの仕組みを作って対応しています。

監視アプリケーション

監視プログラムでは、読み取りプログラムと表示プログラム、自己診断送信プログラムの3つのプロセスが生きているかを監視し、生きていなかった場合再起動させます。これによって、例えばプログラムに不調が出ても、「Pasoriを一度取り外してもう一度打刻機に接続したらプログラムが正常に動く*3」状態を実現でき、万が一朝に問題が合っても利用者自身で打刻機のプログラムを再起動できるようになっています。

自己診断送信プログラム

自己診断送信プログラムでは、プロセスの状態やインナーIP、GitHubのリビジョンなどを定期的にAPIに送信し続けます。PORTには打刻機監視画面があります。その画面に、このプログラムから送信されてきたデータを基に打刻機が稼働しているか、異常が発生しているかの診断を行い、画面に表示させています。

f:id:bino98ty:20170605112625p:plain

万が一、打刻機が停止している場合は、Slackにその旨のアラートを飛ばし、山本が飛んで直しに行きます。

再起動プログラム

再起動プログラムでは、1時間に1度、読み取りプログラム、自己診断送信プログラム、表示用プログラムの3つを終了します。長時間プロセスを起動し続けると、時たまゾンビプロセス化するプログラムがあるため、定期的に終了しています。しかし、上記の監視プログラムがプロセスを監視しているため、自動で再起動します。

ユーザにどうやって打刻成否を伝えるか

打刻機にはディスプレイがないが、どのように打刻の成否を伝えるか。肝は です。スピーカーはディスプレイよりはるかに安価に調達できますし、打刻機から返されるレスポンスは、ディスプレイほどの情報伝達力を必要としない量のため採用しました。

スピーカーは、100均のモノラルスピーカーを利用するか、 アンプ内蔵のお手製スピーカー を利用します。100均で売られているスピーカーを使うと、Raspberry Piから音を最大音量で出力ししても、ちょっと音が小さいのです。そのため、アンプ内蔵のスピーカーを打刻機を設置する場所によっては採用しています。

アンプ内蔵のスピーカー

安価なアンプ内蔵のスピーカーは、その当時調べた限り、見つけることができませんでした。なので、こちらのパワーアンプキットと、こちらのスピーカーを調達し、自前ではんだ付けし、使っています。現実的な音量になるため、全ての打刻機をこのタイプにしたいのですが、できればはんだ付けしたパーツは使いたくないところ…(打刻機運用の引き継ぎのハードルが途端に上がる)。アンプ内蔵のスピーカーを探しているところです。

f:id:bino98ty:20170605114147j:plain f:id:bino98ty:20170605102237j:plain

音のユーザ体験

また、打刻音にもこだわりが。

当初、打刻音は 打刻成功時に一度「ピッ」となるだけ でした。しかし、打刻成功時だけではレスポンスが帰ってくるまでの1〜2秒を長く体感される方が社内には多く(と思うと、鉄道の改札機ってマジリスペクトするぐらい早く ピッ となってくれますよね)、API側でリクエストの負荷のかかる部分をメッセージキューイングさせ、応答時間そのものを早くしたり、プレ打刻音をならしたりして、ちょっとずつユーザ体験の質の向上を実施してたりします。社内で作っていると、すぐにユーザの反応を受け取れるので、やりやすいです。

無機質な電子工作感を脱したい

また、Raspberry Piをそのまま執務室エリアに置いておくと、いかにも電子パーツ感があるため、インテリアしづらいと思います。その電子工作感をなくすため、また100均でケースを買い込み、スプレーニスと電動ドリルで箱を作ってケースを作ったりしました。

f:id:bino98ty:20170605115817j:plain

チーム内でダサいという意見が頻出したため、このケースは採用されませんでした。 レゴでケースを作ったり、3DCADでモデリングしてたりしますが、まだどうするかは未定です。(Raspberry Piを包み込む人形を作るのはどうかという話もあります)

まとめ

内製で勤怠システムを作ったり、打刻機を制作することで、より弊社のニーズに合うプロダクトを作ることができ、ユーザが近いのですぐにその反応も伺えます。もっと簡単に勤怠管理できる日を目指して、引き続き改良を進めていきます。ご覧いただきありがとうございました。

*1:QRコードはカード登録用のワンタイムURLを発行しています。読み取ると、PORTにログインしているユーザのカードとして登録される仕組み

*2:PORTで利用しているICカードリーダー

*3:Pasoriを外すと例外を吐きプログラムが終了するようになっているため

Speee Lounge 会場貸出について

こんにちは!エンジニア組織推進室の中野です。
今回はSpeee Loungeの会場貸出についてブログを書いてみました! 普段私たちは、自社イベントもくもく会などでLoungeをフル活用しています。また、貸出をして少人数の勉強会から大規模なイベントまで多岐に渡って利用いただいてます。
参加・利用していただいた方より、「居心地がよかった」、「十分なスペース、設備があって使いやすかった」などご好評の声をいただくことが多くなり、せっかくだから積極的に貸出をしていこうと思い、今回ご案内をさせていただいております!
※Loungeでは様々なイベント・勉強会をやっているのですが、ここでは"エンジニア向け"の勉強会やイベント利用に限定して、話をさせてもらいます。

Speee Loungeについて

2015年12月に、社内外の"知"が集まるコミュニケーションスペースを創りました。
目的としては、仕事をしたり、社内外の打ち合わせをしたり、コーヒーを飲んでリフレッシュしたり、書棚にあるたくさんの本を読んだり、様々な用途においてLoungeを活用することで意図しない偶発的なコミュニケーションを増やしたいという思いがあったからです。
また、"知の共有場所"となるよう、社内向け/社外向け問わずイベントを実施したりと、"オープンなコミュニケーション"を通じた知の共有を目指しました。
詳しくは下記記事をご覧ください!

cd.zeroin.co.jp

雰囲気

コーヒーの香り漂うゆったりとした空間となっています。多種多様な書籍が所蔵されており、BGMがかかっているため、カフェにいるような感覚です。

f:id:kana-nakano:20170411133521j:plain

会場キャパ

MAX100人程度でしょうか。前スペースには70~80名程度、ソファが並ぶスペースには20~30名程度入ります。こんな感じです。

f:id:kana-nakano:20170411134345j:plain

使用条件

  • ITや技術がテーマの勉強会、交流会などの目的でご利用下さい。
    • その他のテーマでのご利用希望の場合はお問い合わせ下さい。
  • 原則22:00撤収
    • 22:00を超えるイベントの場合はお問い合わせ時にご相談ください。
  • 会場設営や現状復帰にご協力下さい。

できること

  • 飲食物の持ち込み(アルコールも可)
  • Wi-Fi、電源、プロジェクタ、MAC用コネクタ、マイク、演台の貸出
    • マイクは4本、可動式スライド2台、天吊りディスプレイ6台までご用意出来ます。
  • 自由なレイアウトでの会場設営(ソファは原則動かせません)

過去Lounge利用例(一部)

Q&A

  • 申し込み・問い合わせはどこからすればいいですか?

  • 事前に見学はできますか?

    • はい、事前見学いただけます。上記リンクからお問い合わせ下さい。
  • 本当に無料なんですか?

    • 無料で貸出しております。飲食物等の手配は、運営者様にてお願い致します。

最後に

Speeeは技術が好きで、技術力をもっと伸ばしていきたい、技術で世の中を変えていきたいという意思や野望を持った人を応援しています!そんな方々にSpeee Loungeを活用していただき、会場提供・利用という枠を超えて、交流や情報交換が活発に行われるエンジニアコミュニティが形成される場所のひとつがSpeee Loungeだったらいいなと思っています。
ご連絡・ご相談お待ちしてります!

DataScience.rb ワークショップを開催し、PyCall を用いたデータ解析の実演をしました

開発部 R&D グループの村田 (mrkn) です。

2017年05月19日、Speee Lounge で DataScience.rb ワークショップ 〜ここまでできる Rubyでデータサイエンス〜 を開催しました。 f:id:mogmog2:20170522144449j:plain

このワークショップは当初、私が2016年10月から取り組んでいる PyCall の開発 *1 と、Ruby アソシエーション開発助成の支援の下で実施された西田さん、三軒家さん、芦田さんによるプロジェクトの成果報告のために企画されました。そんな中、クリアコードの須藤さんが2017年2月頃から Apache Arrow の Ruby バインディングを開発する Red Data Tools プロジェクトを開始されました。Apache Arrow は2016年頃から開始されたプロジェクトで、私は当初から Ruby の将来にとって重要な基盤になるはずだと思い注目していたこともあり *2、Red Data Tools プロジェクトの進展には期待をしています。そこで、私から須藤さんにお願いして Apache Arrow と Red Data Tools の話をして頂くことになりました。

ワークショップの全体の流れは次のようになりました。

最初に、このワークショップの位置付けについて説明しました。私は、2016年から2017年初めにかけて、カンファレンスで何度か「Ruby はデータサイエンスでは使えないプログラミング言語である」ことを強い表現で説明してきました。このようなネガティブな話をし続けていても Ruby がデータ解析で使えるプログラミング言語になるわけではないので、私はこのワークショップを起点に、ネガティブな話をせず開発を前に進めていくことに注力したいと考えていました。そこで、オープニングで「今日を Ruby でデータサイエンスをやっていく日々の始まり」にするために、次のことを宣言しました。

  • Ruby をデータサイエンスで使えるプログラミング言語にしていこう
  • ネガティブな話はもうやめよう
  • 過去や現在に囚われず、粛々と開発を進めよう

f:id:mogmog2:20170522144502j:plain

そして、Ruby をデータサイエンスで使えるプログラミング言語にするために3つの道があることを説明しました。

  1. 巨人の肩に乗る
  2. 既存の gem をなんとかする
  3. Ruby のための仕組みを整えていく

ワークショップ当日のコンテンツは、これら3つのそれぞれについての現状報告でした。オープニングの後、次の順にそれぞれ発表とデモを実施しました。スライドや Jupyter notebook ファイル、関連ブログ記事へのリンクを記載したので、当日参加されていて復習したい方も、参加できなかった方も合わせてご覧ください。

  1. 巨人の肩に乗る ⇒ 村田賢太「PyCallを使ってRubyでデータ解析をやってみよう」 [slide] [jupyter notebook]
  2. 既存の gem をなんとかする ⇒ 西田孝三、三軒家佑將
「Ruby Association開発助成で得た知見の共有と今後」 [slide] [jupyter notebook]
  3. Ruby のための仕組みを整えていく ⇒ 須藤功平
「RubyもApache Arrowでデータ処理言語の仲間入り」 [slide] [blog]

DataScience.rb は今後も開発の節目ごとにワークショップを開催していく予定です。私たちの取組に賛同し、開発に協力してくださる方は、SciRuby の Slack や Red Data Tools の gitter に参加してください。利用事例の報告、バグレポートなどお待ちしております。

Ruby をデータサイエンスで使えるプログラミング言語にしていく活動を、今後ともよろしくお願いいたします。

*1:2016年12月〜2017年3月まで、しまねソフト研究開発センターさまに支援していただきました

*2:将来的に daru のバックエンドに採用したいと思ってこのような issue を作ったことがあります