@ledsun blog

Ｈのキーがhellで、Ｓのキーがslaveだ、と彼は思った。そしてＹのキーがyouだ。

#railsdm Rails Developers Meetup 2018 Day 4 Nouvelle Vague で発表しました

Ruby 勉強会 技

Rails Developers Meetup 2018 Day 4 Nouvelle Vague で発表してきました。 趣旨は「ActiveRecordやActiveJobなどのRailsの用意した抽象インタフェースを使うと、アプリケーションのミドルウェア構成、ひいてはアーキテクチャの決定を遅らせる事ができる。その分開発に集中できる」です。

speakerdeck.com

Rails中・上級者向けの話をして良いとのことだったので、Rails開発のレアのシチュエーションの話をしました。 そもそも対象のアプリケーション要件が特殊なので、その説明に20分中5〜6分使いました。

内容が少しマニアックすぎたので、伝わる相手は多くはなかったようです。 その中でも良いリアクションを頂けたので、発表した身としては大変満足でした。

反応

私の前にRail Wayはなく、私の後ろにRail Wayはある*1

補足

Webフロントエンド

Web用フロントエンドとブラウザの間はWebSocketでつないで、サーバから非同期に結果を送っています。 今回はWeb用フロントエンドに関わる話はしないので、端折りました。

Web用フロントエンドでの、WebSocket（とスレッド）に関わる、技術的落とし穴の話は下でしました。 speakerdeck.com アプリケーションの構成は説明していません。

Sucker Punch

qiita.com

発表時に詳細を端折った、Sucker Punchに当てるモンキーパッチの説明をQiitaに書きました。

同じく端折ったDockerの話もどっかーに書きたいです。

ActiveRecord

発表後に聞いた話では、該アプリケーションはSQLiteからPostgreSQLへ、ソースコード修正無しで、乗り換えできたそうです。 ActiveRecordの抽象化の完成度、すごいですね。

その他

動画もあるみたいです。恥ずかしいので自分では、見ていません。

twitter.com

*1:実際は先人が作った巨大なRail Wayの端っこを、ちょっと開拓しただけです。

builderscon tokyo 2018 で得たもの #builderscon

技 勉強会

一ヶ月前の話ですが、やはり印象深かったので書きます。

植山類さんのセッション

大変良かったです。 僕は類マニアなので、以上に高いテンションになっている可能性があります。 その辺は差っ引いて読んでください。 新しい知見が得られたというか、目の前で人間が喋っているのが聞けたのが良かったです。

主な内容は以前のブログ記事と大体同じです。 note.mu

動画も公開されているようです。 builderscon.io

ハートが撃ち抜かれた

特に印象的だったのは「カーゴ・カルト・プログラミングを徹底的に避ける」話です。 勝手な想像ですが、カーゴ・カルト・プログラミングを避けた結果、ソースコードを理解していない部分がなくなり、アドバイスをくれる誰よりも自分がソースコードを理解している自信になり、定石破りが（自分のシチュエーションでは定石が有効でないことを喝破）できたのではないかと思います。

それでlldの性能と開発効率が上がって、多くのOSSプロダクトに採用されるようになった実績を、目の前の人間が喋っていることがすごいです。 ハートが撃ち抜かれた。

Turing Complete FMで何度も聞いている声ですが、実際に喋っているのをみると、最初から天才プログラマだったわけじゃなく、本人の努力で今があるのがわかって良いです。ブログ記事には上手く行った話を書くことが多いので、ブログだけ読んでいると「超天才か！」と思うのですが、「人間、天才みたいな属性だけで雑に説明できるわけねえよ」が実感できて良いです。

カーゴ・カルト・プログラミングを避ける

それで、感銘を受けて、「遅い処理を非同期化する」タスクに取り組んでいる時に、

  1. 「遅いのはわかるけど、どこが遅いか計測すべき」と計測し、データ作成でなく、データ送信に時間が時間がかかっていることを確認
  2. データ送信の振る舞いをみるとデータの送信量に依存せずに遅くなることがあるので、厳密にはデータ送信ではなく、コネクション確立に時間がかかっている
  3. ソースコードにコネクションを使い回す修正を入れて計測してみる
  4. 既存のソースコードには修正を邪魔する、不要な抽象が挟まっている。自分で書いたし、書いたときは良かれと思って書いています。まずは、この抽象をはずす

それから「コネクションを使い回す実装をいれ、それで再度計測して効果があるか確認する必要があるな」と、のたうち回っているところです。

当初は「非同期化するだけなら、スレッドかActiveJobを使えばいいだけ」と軽く見ていたタスクでした。それでも、「カーゴ・カルト・プログラミングを避ける」気持ちで見ると、既存の実装の良くない点（コネクションを使い捨てている）と、設計の良くない点（不要な抽象がある）が、見つかり新たな知見が得られます。

まだ調査中なので、本当にこの方針で実装するのが正しいのかはわかりません。例えば、送信先に依存しているかもしれない。そうならば送信先を制限した方がいいかもしれません。それでも、この調査で得られた知見はより正しい判断につながるでしょう。すくなくとも、不要な抽象（本当に何の役にもたってなさそう）が見つかったのは、この先ソースコードに技術的負債を抱えて進んでいくより良いでしょう。この辺は、時間的プレッシャーに負けそうな自分に言い聞かせている理由付けです。

そういうお気持ちでプログラミングを進めていきたい。