f:id:vasilyjp:20180927112707j:plain

こんにちは、バックエンドエンジニアの田島（@katsuyan121）です。 5/31〜6/2にかけて仙台で開催されたRubyKaigi2018に、スタートトゥデイテクノロジーズから5人が参加しました。

今年のRubyKaigiは3日間で50を超える講演があり、参加者も1000人を超える大変大規模なカンファレンスでした。たくさんの講演の中で、スタートトゥデイテクノロジーズのエンジニアが興味を持ったものを、この記事でいくつか紹介します。また今回スタートトゥデイテクノロジーズはスポンサーブースを出展したので、そこで得られたことを共有します。

セッション

Proverbs(Matz)

Rubyのお父さんであり、弊社スタートトゥデイテクノロジーズの技術顧問でもあるMatzさんの発表です。今回の発表では3つの諺を例にお話を展開されました。

f:id:vasilyjp:20180611155555j:plain

名は体を表す

「名は体を表す」という通り、名前は重要であるというお話でした。特にソフトウェアには実態がないため、名前付けが重要になるとのことでした。

名前には2種類あり、1つは振る舞いに対する名前でもう1つがプロジェクトに対する名前です。
振る舞いに対する名前付けが難しいという場面はよく訪れます。しかし名前付けが難しいということはその概念を十分に理解していないことであるとのことでした。

プロジェクト名という側面では、Rubyのような求心力のある名前が好ましいとの話でした。また、今の時代だとgooglabilityが非常に大切であるとも語られていました。それを解決するのためにTensorFlowのように単語を組み合わせたり、Jupyterのようにスペルをいじるのは良い手段であるとのことでした。

時は金（価値）なり

時は金（価値）なりが示すように、時間を有効活用することが非常に大切であるとの話でした。開発における時間には開発時間と実行時間という2つの側面があります。Rubyでは主に開発時間という部分に重きをおいてきました。開発時間を短くすることで人件費の節約など直接的に費用削減につながるということでした。

また、実行時間についてもRubyにJITを導入するなど改善を常に行っています。実行時間を短縮することでサーバの台数が減るなど直接的に費用を削減できると例をあげて説明していました。

塞翁が馬

塞翁が馬のように、良いこと悪いことに一喜一憂するなというお話でした。例えば、静的型が流行っているからと言ってRubyには絶対に静的型は導入しないとのことでした。長い目で見た時に安易に静的型を導入しないほうが有利になるとMatzさんは考えているそうです。

コスチュームスポンサー

f:id:vasilyjp:20180611155624j:plain

今回のRubyKaigiではMatzさんには事前にZOZOSUITを着ていただき、測定結果を元にMatzさんピッタリサイズのジーンズを履いていただきました。
またkeynoteの最後でコスチュームスポンサーとしてスタートトゥデイテクノロジーズを紹介していただきました！

Improve Ruby coding style rules and Lint(Koichi ITO)

RuboCopのコミッタであるKoichi ITOさんによる、RuboCopのStyleとLintについての発表でした。

Styleはコーディングスタイルのことを表します。コーディングスタイルは様々な文化から形成され、会社やプロジェクトによって異なったルールが存在します。RuboCopのデフォルトのStyleはRuby Style Guideに従って作成されているそうです。Lintは潜在的なバグを指摘するもので、コーディングスタイルとは違い言語仕様的に適切でない箇所を指摘します。

Styleについては、会社やプロジェクトによってコーディングスタイルは違うものなので、積極的にデフォルト設定からカスタマイズしてほしいとのことでした。
また、Koichi ITOさん自身がRuboCopのルールをどのような経緯で新しく追加したかについてもお話されていました。会社のコードレビューを受けて気づいたルールや、RailsのカスタムコップからRuboCopに採用したルールもあるとのことでした。

発表を通して、自分たちが使ってよかったものを他の人にも広めていこうというKoichi ITOさんの意思がとても伝わってきました。

Architecture of hanami applications(Anton Davydov)

Anton Davydovさんによる、hanamiを長期的にメンテナンスしていくうえで採用したアーキテクチャを振り返るという発表でした。

ファットモデルなコードから段階的にビジネスロジックを切り離していく方法としてhanamiに採用されている手法の説明がありました。具体的にはInteractor(Service object), Repositoryや、Event Sourcingなどが紹介されていました。

また、Event SourcingのPoC実装としてhanami-eventsというgemについての紹介もありました。
実際にInteractorやRepositoryを入れた意図やhanamiでの実装例が示されていました。
様々なデザインパターン紹介の最後に『必要かわからないときは使わないでおく』ということを書かれていた事は、エンジニアとしてすごく共感できました。

ビジネスロジックの切り分けはhanamiだけでなく、webアプリケーション開発をしている人全体の問題でもあります。良さそうなパターンは実際に検証して自分たちのプロジェクトに取り入れていこうと思います。

bancor: Token economy made with Ruby(Yuta Kurotaki)

Yuta KurotakiさんによるBancor Protocolというスマートトークンを発行するためのプロトコルをRubyで実装したという発表でした。ちなみにBancorはバンコールと読みます。

ブロックチェーン関連の実装はPythonやGo・JavaScriptで実装されているものが多いですが、Rubyで実装されているものがあまりなく実装してみたということでした。

実際のRailsアプリケーションに組み込んでbancor protocolを利用したデモでは、流動的に価格が決定されているところを見ることができました。 Ruby実装が少ないブロックチェーンを実装するという試みは、新しいものに挑戦していくという部分ですごく共感を得られました。

参考：
bancorのリポジトリ

Hijacking Ruby Syntax in Ruby(joker1007/Satoshi "moris" Tagomori)

Hijacking Ruby Syntax in Ruby from SATOSHI TAGOMORI

joker1007さん・Satoshi "moris" Tagomoriさんによるメタプログラミングを最大限に活用しようという発表でした。メタプログラミングというRubyの黒魔術を最大限に活用して、Rubyの文法が変わったのかと錯覚するレベルの機能が示されていました。

肝になる機能は Binding#local_variable_set と Tracepoint で、これらの機能を利用していたるところにフックを仕込みます。そうすることで、いたるところの変数を書き換え邪悪な機能を実現しているとのことでした。

Javaでおなじみのfinal、override、abstractをRubyでも実現し、なおかつこれらはクラス定義時点でエラーを出せるという点に感動しました。
その他にPythonでおなじみのwithや、Goでおなじみのdeferなどと同等な機能をRubyのメタプロだけで実現している例が示されました。

Rubyはメタプロ文化があるとはいえ、ここまでのことができたのかという驚きがありました。

TTY - Ruby alchemist’s secret potion(Piotr Murach)

Piotr MurachさんによるTTYというCLI作成用のライブラリを作ったという発表でした。
最初に以下のようにwebのアーキテクチャと比較している点が興味深かったです。

cli - router
command - controller
stdin - request
stdout - response
template - view

TTYには複数のプラグインがあり、プラグインを導入することでCLIをリッチにできます。
実際にデモではTTYを利用したCLIが示されており、ギュインギュイン動いていて感動しました。

TTYは簡単にリッチなCLIツールを作るにはすごくいいライブラリだと思います。
またアーキテクチャも上に示した通りwebエンジニアにとってすごくわかりやすい構成となっていて、複雑なCLIツールを作るのにも向いているライブラリであると感じました。

参考：
TTYリポジトリ

Firmware programming with mruby/c(Hitoshi HASUMI)

Hitoshi HASUMIさんによる、mruby/cを使って日本酒を醸す（かもす）というお話でした。

日本酒の製造にあたっては麹（こうじ）や醪（もろみ）の温度管理が必要で、そのために温度センサーのデータを収集するためのファームウェアをmruby/cで作ったそうです。
こういう用途ではラズパイの使用も考えられます。しかし冬でも35度である麹室での運用を考えた時に、低消費電力かつ低発熱なことを重視しARM Cortex-M3が搭載されたPSoc5LPマイコンにしたそうです。
このシステムは2018年1月から実際に稼働しているそうです。

mrubyとmruby/cはどちらとも軽量Rubyですが、mruby/cの方がより少ないメモリでも動くようにできているとのことでした。
大きな違いとしてmrubyはRTOS（RealTimeOS）の上で動くことが前提ですが、mruby/cはRTOSなしでその下に直接ハードウェアがあるという構成になっている点です。
そのためにHAL（ハードウェア抽象化レイヤー）があり、ソースコードの中のその部分を読むと面白いのではとのことでした。

開発中に困ったこととしては、デバッガでのステップ実行ができないのでprintデバッグしかできなかったとのことでした。また、 Array#each が未実装なので while と break で代替しなければならないという点でした。このようなことから、mruby/cはまだまだ成長の余地があって楽しみです。

また発表されていた十旭日は、東京では以下の酒販店で取り扱われているそうです。
生原酒と火入れ：新宿の三伊井上酒店
主に生原酒：笹塚のマルセウ本間商店
主に火入れ：中目黒の出口屋、練馬の大塚屋
定番品種：横浜君嶋屋の銀座店、恵比寿店

十旭日のなかでもmruby/cで醸されたお酒は29BY（平成29酒造年度の醸造）のものだそうです。

https://twitter.com/hasumikin/status/1006899085570334727

Ruby code from the stratosphere - SIAF, Sonic Pi, Petal(Kenichi Kanai)

Kenichi Kanaiさんによる、mrubyを使ったlivecodingの発表でした。ここでいうlivecodingとは、「コンピュータの言語であるプログラムコードを直接操作することで、さまざまな音や映像をリアルタイムに生成する即興演奏の方法」とのことでした。
Petalというプログラミング言語（実際はRubyのDSL）を使うことで、シンプルな記法で多様な音を出すことができるそうです。

気象観測用の気球にラズパイとセンサーを載せて、上空でセンサーから取得したデータをもとにPetalのコードを生成します。そこから音を生成することによって、成層圏からの音楽を地上に届けるということを札幌国際芸術祭でやったそうです。

最初は気球に搭載したラズパイで音を生成してそれを地上に無線で届けるということをしていたそうです。しかしそれだとノイズが多くのってしまったので、2回目からは音の生成を地上でやるという方法で問題解決をしたらしいです。
発表の最後ではこの時に取得したセンサーデータのログから音楽を生成し、会場のみんなで成層圏からの音楽を楽しみました。

参考：
スライド
 スライド Petalリポジトリ

Deep Learning Programming on Ruby(Kenta Murata/Yusaku Hatanaka)

Kenta Murataさん・Yusaku HatanakaさんによるRubyでDeep Learningをできるようにする試みについての発表でした。
このセッションは2つ分かれており、前半では「mxnet.rb」のについての発表。後半は「Red Chainer」の発表となっていました。

1つめのmxnet.rbのお話は、MXnetのRubyバインディングを開発したというお話でした。MXnetはDeepLearning用のライブラリで複数言語のバインディングが存在するが、Rubyには対応していなかったとのことで開発を初めたようです。

MXnet自体はKerasのbackendにも利用されています。TensorFlowでのバックグラウンドと比較して良いパフォーマンスであったことが確認されており、有用なライブラリであるとのことでした。
ONNXにも対応しており、一度MXnetで作ったモデルを他のONNXに対応したDeepLearningライブラリで利用できるそうです。また逆に他のライブラリで作成したモデルをMXnetで利用できるとのことでした。
mxnet.rbは絶賛開発中で、プルリクをお待ちしておりますとのことでした。

2つ目のRed ChainerはChainerをRuby実装として実現するというお話でした。こちらも絶賛開発中とのことで、まだPythonチックなRubyを書かないと行けない部分があったり、CPUにのみしか対応していないとのことでした。しかし、今後はもっとRubyらしく記述できるようにし、後述するCUMOを利用することで近々GPUに対応予定とのことでした。

Red ChainerはRed Data Toolsというコミュニティに属しています。Red Data Toolsは理念が素敵で誰でも気軽に参加できそうなコミュニティだと感じました。

このように、RubyでDeepLearningをするという試みが活発になってきていることが分かりました。Rubyで楽しくDeep Learningできるのはすごく楽しみです。

参考：
Yusaku Hatanakaさん振り返りブログ
 mxnet.rbリポジトリ
 redchainerリポジトリ

Fast Numerical Computing and Deep Learning in Ruby with Cumo(Naotoshi Seo)

Naotoshi Seoさんによる、NumoというRubyの計算用ライブラリをCUDAに対応させようという試みの発表でした。

Numo自体はRubyの計算用ライブラリですが、CPUにのみ対応しています。そこで、Numo互換のCUDA対応ライブラリであるCUMOを作成したそうです。
CPUを前提とした実装をGPUに対応した時、GPUによる並列計算どのように計算させるのかということがわかりやすくまとまっていました。CUDAプログラミングをしたことがない人でも理解できるような内容となっていました。実際にCUMOを利用する場合、ソースコード中のNumoをCumoに全置換するだけでGPUに対応できるのは感動しました。

またこのプロジェクトはRuby Associationに採択されたプロジェクトだそうです。個人的にやるプロジェクトでもなにかしらの締切が設けられることで、それがマイルストーンになるということも語られていました。

参考：
発表者振り返りブログ
 CUMOリジトリ
 NUMOリポジトリ

スポンサーブース

アンケート

1日目

お題

初日のお題は、「ブロック開始の中括弧とブロックパラメーターの間にスペースを開けるか」というものでした。
このお題の理由としては、技術顧問のMatzさんとの月イチのミーティングでRubCopの話になったことが切っ掛けです。RuboCopのデフォルトではスペースを開けるようになっています。しかし、Matzさんはスペースを開けたくないとのことだったのでこのお題を提示しました。

結果

f:id:vasilyjp:20180611155715j:plain

考察

結果はスペースを開ける派が多数となりました。スペースを開けるという理由として多く挙げられたのはやはりRuboCopに指摘されるからというのが多かったです。また、中括弧でなく do end で記述する場合は do とブロックパラメータの間にスペースを開けるから統一するためとの解答もいただきました。

スペースを開けない派の意見としては、ArrayやHashを作るときにはカッコのあとにスペースを開けないからそちらと統一するためなどの意見をいただきました。

「Improve Ruby coding style rules and Lint」で示されていたように、styleは文化によって違います。そのためプロジェクト内で記法が統一されていれば、どちらでも良いと考えました。

2日目

お題

2日目のお題としては、「クラスメソッドの定義をするときに self.クラスメソッド名 と書くか、 class << self で特異クラスをオープンするのか」というものでした。このお題の意図としてはまたもRuboCopでは後者を使うように示されますが、前者のほうがクラスメソッドとしてわかりやすいのではないか？　という意見が社内であったことからこのお題を提示しました。

結果

f:id:vasilyjp:20180611155736j:plain

考察

結果は class << self で特異クラスをオープンするほうが多数となりました。特に多かった意見としては、クラスメソッドが1つの場合は self.クラスメソッド名 、2つ以上の場合は class << self を使うというものでした。

また、 class << self を使う理由としてはprivateクラスメソッドがこっちの書き方でしか書けないから、grepする時に探しやすいからというものがありました。self.クラスメソッド名を使う理由としてはパット見てクラスメソッドかどうかがわかりやすいからという意見が多かったです。

このアンケートは、一日目よりも迷う人が多かった様子でした。このケースはプロジェクトで柔軟に対応していくのがいいと考えます。

3日目

お題

最終日のお題は「文字列の配列を定義するときに、％記法を使うか」というものでした。このお題に関してもRuboCopでは前者が示されます。後者のほうが文字列の配列としてシンプルでわかりやすいという意見があったことからこのお題を提示しました。

結果

f:id:vasilyjp:20180611155751j:plain

考察

結果は％記法を使うという方が多数となりました。％記法を使う理由としては、単純にタイプ数が減る。文字列以外が配列の中に入らないなどが挙げられました。ここでもRuboCopに指摘されるからという意見もありました。

％記法を使わない理由としては、％の次に何を書けばいいか忘れてしまう。Ruby以外の言語から来た人でもわかりやすい。文字列の配列であることが直感的にわかりやすということが挙げられました。

これについても、それぞれの利点をちゃんと知った上であれば好みのスタイルで書けばいいと考えました。

gem

お題

最終日には好きなgemのアンケートを取りました。

結果

f:id:vasilyjp:20180611155803j:plain

考察

今回の好きなgemアンケートでは pry や byebug など手元で動かすgemが多く挙げられました。
実際に自分が助けられたり便利だなって感じたgemを好きだと感じるのかなと思います。
知らないgemも多く挙げられすごく勉強になりました。ぜひアンケート結果から知らないgemを調べてみてください。