コラム

CTC教育サービス・ホーム　＞　コラム　＞　Ruby ＆ Rails　＞　第33回　あのGemは今その3

Ruby ＆ Rails

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第33回　あのGemは今その3 (松永紘) 2018年3月

　私の所属する株式会社ゼネットでは11/20～22の3日間、プログラミング未経験者向けにRubyプログラミングを開催し、私はその講師を務めました。
　このコラムでも教育や研修のお話は何回か書いていますが、し終えるたびに誰かに何かを教えるのは難しいなと痛感します。今回の研修については弊社の技術ブログ(*1)で書きたいと思いますので、ぜひご覧ください！
　さて今回も引き続き「あのGemは今」というテーマで、過去にご紹介したGemの今を取り上げていきたいと思います。
　なお動作確認は前回同様、Ruby2.4.2、Rails5.1.4で行っています。

第16回Opal（2014年7月）

　バージョン: 0.6.2 -> 0.10.5

　OpalはRubyで書いたコードをJavaScriptに変換してくれるコンパイラです。JavaScriptをRubyで書ける！というのは何とも素敵な響きですが、その当時の感覚では実際に使っていくには課題も多い印象を受けていました。
　そんなOpalですが開発は滞ることなく続けられているようで、多くのマイナーアップデートが繰り返され現在は0.11.0.rc1まで上がっています。
　注目度も上がってきているようで、今年のRubyKaigiでも2つのセッションでOpalが取り上げられていました(*2)(*3)。
　JavaScriptを全てRubyで置き換えられる日が来るのか、これからも注目していきたいですね。

　なお今回の執筆にあたりその当時の内容を動かしてみたのですが、OpalやRailsなどのバージョンアップにより一部そのままでは動作しないところがありました。「Opalの今」の最後にその部分について、訂正も兼ねてご紹介いたします。

・ rails new時の--javascriptオプション

　これはOpalではなくRailsのバージョンアップによるものですが、Rails5.1からrails newコマンドの-j（--javascript）オプションが削除されているようで(*4)、以下のコマンドではOpalの環境を整えることができません。

> rails new OpalSample --javascript=opal

そのためRailsプロジェクトの生成後にGemfileへ以下の記述をし、bundle installを行う必要があります(*5)。

gem 'opal-rails'

・ app/assets/javascripts/application.js

　当時は以下の記述でOpal関連のJavaScriptを読み込んでいました。

//= require opal
//= require opal_ujs
//= require turbolinks
//= require_tree .

　ところがこの書き方ですと、5の階乗を行っている「app/assets/javascripts/sample.js.opal」の処理が実行されません(*6)。そこで公式サイトのチュートリアル(*7)の通りに修正します。
まずは「app/assets/javascripts/application.js」を「app/assets/javascripts/application.js.rb」とリネームします。その上で以下のように内容を変更しましょう。

require 'opal'
require 'opal_ujs'
require 'turbolinks'
require_tree '.'

　こうすることで、先述の処理も動作することが確認できるかと思います。

第17、18回Grape（2014年9、12月）

　バージョン: 0.8.0 -> 1.0.1

　RubyでREST-likeなAPIを実現するためのフレームワークです。こちらもOpal同様絶え間なくバージョンアップが行われており、今年の7月には1.0をリリースしています。JSONやXMLのparserが変わったり、DELETE時のデフォルトのステータスコートが変わったりと互換性に関する変更もありますが、Grapeの場合は親切にもGithubにUPGRADINGというページが用意されています(*8)。変更点を確認したい場合はChangeLogと合わせて参照するといいでしょう。
　Rails5からRails::APIが同梱されるようになってはいますが、規模が大きなものや複雑さが増すようなケースではやはりGrapeが選択肢に入ると思います(*9)。その際、多くのContributorが開発に携わっていたり、互換性に関する変更をまとめていたりという点は一つの安心材料になりますね。

まとめ

　今回振り返ったOpalとGrapeは絶え間なく続いており、頻繁にアップデートされているのが印象的でした。メンテナンスされなくなるリスクもありますが、元の開発者ではないエンジニアがContributorとして参加し開発が継続していくというのもOSSらしさかなと感じますね。
　以上、3回にわたって「あのGemは今」をお送りしました。ただ、お気づきの方もいらっしゃるかもしれませんが、WebSocket関連のGemだけまだ取り上げていません。ですので次回はRails5からのActionCableと合わせて取り上げてみようかなと思います(*10)。

それでは、Enjoy Ruby!

注釈

*1: http://zenet-tech.hatenablog.com/

*2: http://rubykaigi.org/2017/presentations/youchan.html

*3: http://rubykaigi.org/2017/presentations/yhara.html

*4: http://edgeguides.rubyonrails.org/5_1_release_notes.html#railties-removals

*5: 執筆時現在、公式サイトやGithubのReadmeにはまだ-jオプションに記述が残っているようです。

*6:
読み込み順の問題なのか、処理の定義はされているもののその処理自体が発火しないようです。app/assets以下のsample.xxxx.jsに処理の記述があり、開発者ツールのコンソールで「Opal.modules["sample"](Opal)」と実行すれば動作することは確認できます。

*7: http://opalrb.com/#getting-started-rails

*8: https://github.com/ruby-grape/grape/blob/master/UPGRADING.md

*9:
Rails::APIはあくまでもRailsからAPIに不要な機能を取り除いたというものですので、APIに特化したという意味ではGrapeの方が機能は豊富かと思います。勿論、そこまで機能が豊富であるべきかどうかは作るシステムによりますので、Rails::APIを選択した方がいいケースもあるでしょう。

*10: 第29回の後編も書けていませんので、その回収も含めて･･･。