RailsDM2019の振り返り（１日目）
前書き
業務の一環としてRailsDM2019に参加しました。その際にレポートの提出が必須ということで、忘れる前にメモしておきます。
基本的には自分の知らない分野に参加しました。
聞いたもの
"Ask Me Anything" by DHH
名前は知っていましたが、あまり本人が語っているのを聞いたことがなかったです。
「JavaScriptは塩のようなもの」「マイクロサービスは複雑さをもたらす」という持論を延々と展開していて痛快でした。
現在の仕事がフロントエンドな自分としてはあまり大きい声では言えませんが、SPAが過剰な分野はあると思っていて共感できる部分が大きかったです。
発言ではBasecamp社では……という前置きが多かったです。Basecamp社といえば、先日「NO HARD WORK!」を読んでいたので思い出せました。
あの内容も大体「最低限必要なことをやればいい。過剰にするな」という趣旨だったので、まさにBasecamp社の哲学そのものなんだよなぁと。
Railsへの見方が変わる講演でよかったです。
PR
こういうPRも軽い口調のところが多いのは意外でした。
採用目的が多かったですが、楽しさを強調するのがエンジニアにとっての福利厚生というとらえ方が多いのでしょうか。
行き過ぎ感と愉快さが半々ぐらいです。
OpalでつくるBrowserアプリケーション
OpalはRubyライクな記法で書けて、JavaScriptに変換できる言語らしいです。
詳しいことをあまり話していませんでしたが、Virtual DOM、Isomorphic、Web Socketあたりができるという話でした。
ここらへんに関しては、ClojureScript、Elmあたりも見てきているので、Virtual DOMやっぱりあるんだ、そっかぁぐらいの感覚になってきました。
IsomorphicやSSRについては確かに考えたことがなかったです。前に挙げた言語もできるのかどうか記憶にないので、そこまで調べてなかったですね。
見ていて何度もリロードしていて開発体験がよくなさそだったので、自分としては採用しない気配があります。勉強にはなりました。
Active Record Oracle enhanced adapterのこれまでとこれから
Active Recordの詳しいところは知らないし、聞いてみようかなぐらいのモチベーションでした。
中身はRails、OracleのDBに追従するためにどのような戦略をとっているか、というOSSのバージョニングの話が多かったです。
ライブラリを使う側としては早くパッチを……という気持ちだけがあって、作る側の意見を聞いてみると本当に大変だなぁというところで思うところがありました。
作る側からするとずっとRCの時からずっとリリース計画を見つつ、変更に追従しないといけないと考えるとすぐに出せるほうがすごいだけというのがよくわかりました。
破壊的な変更も仕方ないから入れるというところもあり、OSSの辛さとか作っている人の気持ちがよく伝わってくる発表で内容的にはエモくないはずなのに、とてもエモく感じました。
Power-Nap（ランチセッション）
聞き取りづらかったのと、動画の目的がよくわからず、不完全燃焼でした。
個人的には技術的な発表のほうが好きです。ご飯は健康的でおいしかったです。
What's new in RubyGems 3.0
www.slideshare.net
Gemが更新されているということ自体あまり意識したことがなかったです。なので、バージョンごとに破壊的な変更が入ることがあるということも知りませんでした。
細かいインターフェースの変更もしているということで、わかる人にはどんどん使いやすくなっているということらしいです。
ここもOSS開発の分業の仕方（フルコミッターがいるとか、セキュリティ担当者がいるとか）が印象に残っています。
SQLQL は GraphQL にとってなんなのか
www.slideshare.net
GraphQL を勉強中だったので、今ならよくわかるかもと思って聞きに行ったのですが、GraphQL の話していませんでした。
とはいえ、GraphQL の勉強をした際に、「なぜわざわざクエリ言語の再発明が必要なんだ。。」という気持ちはあり、同じ問題意識はありました。
中身はSQLを代わりのクエリ言語として使うというもので、結構DBの仕組みや扱い方を深く扱っていて面白かったです。
OSSというとがんがんロジックを書くというイメージがありましたが、結構他のライブラリやミドルウェアの仕様と戦うところが多く、見方が少し変わりました。
To make Ruby ready-to-use in the data science field. And the impact that it has on Rails applications.
データ分析領域でRubyを使うためにライブラリを書いているという話でした。
Apatch Arrowsというライブラリがあって、C++で書かれているそうで、それをCに変換してRubyから呼び出すみたいな話があった記憶があります。
実際にそのデータ構造を使うと、Railsが早くなったとか。
去年Ruby Kaigiに行ったときにひたすらCのコードが出てきていたので、そういう系統の話には慣れつつありますが、改めてRubyOSSのコミッターの強さを感じました。
万葉のRails新人研修のコードレビューコメントを分析してみました
最近、レビューに時間をかけているので何かヒントを、と思い見に行きました。
分析の手法や見方は好きだったのですが、分類や答えが何となく科学的というよりは、自分たちにとって都合のいい方法でやっている気がしてあまりうまく共感できなかったです。
それ自体が悪いというよりは、そのまま自分たちに流用できない気配だったので、自分たちの組織でやり直してみるのがよさそうという気持ちです。
"雑" / Almost Microservices
必要な設定は全部DBのテーブルに入れてしまえというのは前の仕事では当たり前だったので、すらすら入ってきました。
逆に今の仕事でこれもこれも、オンコードでいいんだと思うところが多くて、戸惑う気持ちがあります。RubyやJSはそんな文化を特に感じます。
テストの仕方や、ユーザーを絞ってリリースするという発想は面白かったです。難しさはありますが、覚えておきたいところです。
作って学ぶ RDBMS
理解できた気もするし、全く理解できていない気もします。
オープンソースとしてのDBは見たいなぁと思い領域でありつつ、C系統だしなぁとか、数学的なアルゴリズムが全開だとどちらにせよわからないし。。と思いながら放置していました。
聞いているとそういう心配はなく、読めるだけの下知識はもらえました。
小さく真似して書いてみるというアプローチも含め、OSSから学ぶ学習法を聞けて良かったです。
Thrifty Rails - How to run a production app on a budget
メモリやパフォーマンスを計測して、自力で直すとお金で殴るよりはいいよねみたいな話でした。
今日は難しい話ばかり聞いていたのでシンプルで聞きやすかったです。
パフォーマンス計測、メモリ監視、全部Gemで行けるよみたいなところで、驚いたところはあります。
特にN + 1問題について、Gemでチェックできるよと聞いてそこまでできるんだという感想でした。そもそもできると思っていないので、検索することもなかったです。
毎日の開発に役立つRailsプラグインづくりの秘訣
人が多くてびっくりしました。今日は人が少ないところばかりにいたので、このテーマでこんなに人が集まるんだというのが発見でした。
中身はRailsのコンソールでの操作が難しければ、WebをGUIにすればいいじゃないみたいなところでこれは盲点でした。
コンソールのWrapperを書くとしてもRailsは選びませんし、そもそもCUIで頑張るほうを選ぶのでその発想がでてこなかったです。
そういうわがままさと技術的な詰め方というところが何となく自分にない感覚が多かったです。
感想
OSSの開発者が普段なにを考えて、なぜ物を作って、どうやって技術を選定しているのかというところを知れたのがよかったです。
自分で作ってみたいという気持ちもありますし、使う側としても背景を知ることで理解や共感ができるようになったように思います。
周りにOSSを書いている人は少なく、本格的なものになるともっと少ないので、今日でだいぶ身近なものになりました。
今回はフロントエンド関係の話をあまり聞いていませんが、発想は活かせそうなので参加してよかったです（と書いたら同僚は納得してくれないだろうか）。
明日もおそらく参加しますが、がちがちのOSS系統は少なそう？なので、別の視野を広げられそうで楽しみです。
