てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

RubyKaigi 2017 1日目まとめ

こんにちは!ピクスタ開発部です。

f:id:Yasaichi:20170918183459j:plain

ピクスタ開発部は今年もRubyKaigiのスポンサーとなりました。
今年は、RubyKaigiに参加することができなかった方でもイベントの内容が楽しめるように、実況ツイートをしています。 この記事は開発部のメンバーが選りすぐりのセッションを紹介します。

Development of Data Science Ecosystem for Ruby


Development of Data Science Ecosystem for Ruby

データサイエンスで使用できる言語として、Rubyを紹介する発表でした。主な発表はPyCallを使用したRubyからPythonのライブラリを呼ぶことについての紹介がありました。PyCallを使用することでpandasmatplotlibを使用して、データの整形、可視化、機械学習などを利用することができます。*1
データ分析などをしたくてもPythonが扱えるエンジニアがいなくて苦労する局面も、Railsでデータ分析基盤を作ることで、運用もしやすくなるのではないかと思います。

また、Apache Arrow*2にRubyコミッターが参画されたので、Rubyへの展開が期待できるとのことでした。

API Development in 2017

APIとそれを使う側の両方に携わるものとして、API Development in 2017がとてもよいプレゼンだったので紹介させてください。

フロントエンドが高機能化する昨今、APIを常に良いものに変更したいという要望と、変更への追従が辛い状況とのがんじがらめで、思ったようにスピード感を持った開発ができない、という状況は多いと思います。 APIを作る人は、スマホだったり、別のサービスだったり、他のサービスや他人との関わりが深く、気軽に変更できず、ドキュメントも必要で、テストも用意したい、という厳しい状況にあります。 このプレゼンはそんな僕達の悩みに一石を投じるものでした。

Schema First Development、というAPI設計、開発手法があります。 Schemaによる型定義とドキュメント自動生成により、API設計者、使用者共に並行開発が進められないか、というプレゼンでした。

これまでのREST APIとは異なり、クライアントからクエリを発行するGraphQLの紹介など、API開発の未来を考えさせられるプレゼンでした。

Handling mails on a text editor

RubyコミッターのShugo MaedaさんのRubyで作られたテキストエディタTextbringer、Textbringerのプラグインとして実装されたメッセージユーザエージェントであるMournmailについて、テキストエディタやメール処理の楽しさが伝わる内容でした。

Textbringerという名前は、Elric Sagaという小説の中に出てくるStormbringerという剣の名前から、MournmailはるStormbringerの双子の剣Mournbladeからインスパイアされたものだそうです。
Stormbringerは、秩序と規律を司る法と、多様性と変化とで破壊に向かう混沌との宇宙のバランスが重要なものであり、 Textbringerは、プログラミングと宇宙バランスが重要ということで、スパゲティコードでテストのない破壊的なこともダメだし、ルールの厳しい非情なRubocopの使用によって縛るようなコードでも停滞してしまうので、バランスが重要という設定?も大切なことで納得感もあるけど、それよりも小説を元にした背景設定を持つテキストエディタの開発そのものが楽しそう。

バッファの取り方や、文字の内部エンコーディング、再描画などの話もありましたが、 テキストエディタ、プラグインを作るのは楽しい、なんでもできるのがRubyの良いところ、と話されていたことが印象的な内容でした。

Hanami - New Ruby Web Framework


Hanami - New Ruby Web Framework - RubyKaigi 2017

Hanamiのcore developerであるAnton Davydov氏による、同フレームワークの紹介セッションでした。

今年の4月にバージョン1.0.0がリリースされたばかりの、Ruby製の新しいWebアプリケーションフレームワークであるHanami。筆者は旧名のLotus時代からその存在(とその特徴的なディレクトリ構造)は知っていたのですが、コードをちゃんと見たのはこの日が初めてでした。

発表の中で特に印象に残ったのが、1つのActionに対して1クラスを使って実装する点と、ModelをEntityとRepositoryの2層で表現している(=Repositoryパターン)点です。前者は、リクエストパラメータを引数に取り、Rack Application形式の配列を返す#callメソッドのみを持っているため、コードの見通しがよく、テストが書きやすいという利点があります(参考: 公式ドキュメント)。

全体的にRailsと比較して「これどうやって動いてるんだろ」感が少なく(Anton Davydov氏は発表の中でこれを“No magic”と表現していました)、とても良い印象を受けました。

おわりに

RubyKaigi後にランチ会を企画しています!サービス開発の話はもちろん、ピクスタの開発環境や、開発部の組織体制/チームづくり、キャリアの話、今注目の技術に関する話題など何でも話しましょう!

*1:画像中の物体認識もライブでデモを行なっていました

*2:性能と相互運用性を向上させるために、インメモリでビッグデータをどう扱うかという共通の問題を解決する取り組み