部屋の隅っこで書く技術ブログ

Web系企業勤務のエンジニアリングマネージャのブログです。技術ブログと称しつつ技術にまつわる個人的な話題が多めです。

Rails Developers Meetup 2019で聴いた話を全部3行でまとめた Day2編

勉強会 Ruby Rails RailsDM2019

f:id:expajp:20190329000414j:plain

※写真はフォトスポンサー：LOVEGRAPH*1さんの撮影

RailsDM2019で聴いた話を全部無理やり3行でまとめた記事、Day2編です。

前回の記事はこちらです。

expajp-tech.hatenablog.com

なぜ3行でまとめたかは前回の記事に書いていますのでそちらをご参照ください。

スポンサーセッションと基調講演は対象外ですのであしからずご了承を。

では、Day 2編行きます！

全体がいい感じになるために、私たちRailsをホームにするWeb技術者ができること by @moro

  • Railsが最先端だった時代と違い、今は様々な専門家の持つ価値が交差する場所
  • 一人で何でもするのではなく、様々な専門家とコミュニケーションを取るべき
  • 全体を見渡し、届ける価値を最大化することに興味を持ち、提供しよう

スライド：全体がいい感じになるために、私たちRailsをホームにするWeb技術者ができること/let-our-whole-system-grow - Speaker Deck

フロントエンドがモバイルWebともにすごい勢いで発展したり、メインのロジックが機械学習だったりブロックチェーンになったり、確かに分業が当たり前になりました。

こんな時代、Railsの技術者はちょっとイケてない感じが自分でもしてたんですよね。Railsを蛇蝎のごとく嫌う人（何があったのだろう）にムキになってしまったのもその裏返しかもしれません。

けどサーバサイドってそういう価値の交差点なわけで、全体を眺められる位置にいたい自分の軸足としてはやっぱり合ってるのかなあと。

なんだか、聞いていてほっとしました。

Clean Test Code, Revised by @netwillnet

  • 可読性の高いテストコードは脳に負担をかけない
  • ここにすべてを書いてください
  • 説明し過ぎでちょうどよい

スライド：Clean Test Code Revised - Speaker Deck

「テストコードではDRYを徹底しなくてもよい」と中途半端に認識してしまうと、「どのくらいDRYにすれば良いんだろう……」と迷って出てくるのは読みづらい上にDRYでもないコード、ということが割とあります。

それらをすべて解決する「ここにすべてを書いてください」の一言。いまちょうど仕事で大きめの開発をしていますが、脳に負担をかけないテストがかけそうです。

あと、個人的に意識してることといえばこれでしょうか。RSpecの思想に従い、テスト仕様書を書くことを意識してテストを書いています。

エンジニアリングマネジメントの孤独と向き合う by @koichiroo

  • エンジニアリングに携わる人々の生産性を継続的に最大化するのが役割
  • マネジメントそのものには価値はなく、価値を出すのはあくまでエンジニアリング
  • 自分ではなく他人がどうしたいか、マルチに考えていくのがマネージャの仕事で、基本的には孤独なので情報交換しましょう

スライド：RailsDM2019: On the lonely rail of Engineering Management - Speaker Deck

「まあ目指さないですよね」と言われましたがエンジニアリングマネジメントを志向してた奇特な人間ですどうも。

現在、チームのマネジメントをCTOと分掌しながらやっていて、普通は「船頭多くして船山に登る」状態だと思うのですが割と上手くいっている。

なぜなのかなと思っていたのですが、いろいろ検討した結果、「テックリード的な立場にいるのに、技術力とドメイン知識が足りないのでCTOに補ってもらっている状態」だとわかりました。

発表中に「キャリアを上げていくなかで必要とされる広さ、深さが拡大するときにボトルネックになるのは技術」とありましたが、まさにその状態なのでした。。。

Ruby コミュニティの歩き方 by @koic

  • コミュニティで大事なのは、アウトプットと名前を覚えること
  • どう直せば正しいかはコミッターも知らないので、まずはやっていき
  • 話を聞いて人に会うことで、自分の開発の幅が広がっていく

スライド：Somebody to Ruby - Speaker Deck

「コミッターだって唯一の解を知っているとは限らない」という言葉に何より元気が出ました。

勤務先でまつもとさんと話すことが月に一度あるのですが、まさに同じようなことを思っていたのです。常々、「1言えば10返ってくる」ような方なので。

雲の上のような存在ではありますが、全知全能の神ではない。

自分がコントリビュートしていく意味もあると思いました。

問わず語りの個人事業主 by @yoshuki

  • 自分をプレゼンする手段を確立しておく、そのためのアイテムの数々
  • セルフマネジメントがそのまま仕事のマネジメントになるので、時間・お金・スケジュール・スキルの管理を徹底してリスクヘッジしていく
  • お金は継続的に入ってくるのが大事で、足りない状態を作ってしまうと目の前の仕事すら手につかず悪循環に

いまのところフリーランスになるつもりはありませんが、キャリア形成には特に参考になる話でした。

自分をプレゼンテーションする手段と、生命線の冗長化ですね。

セルフマネジメントは得意な部類とは言え、冗長化をガチガチに行わないと野垂れ死ぬ可能性があると考えると、逆に窮屈に感じそうな気もしました。

Webアプリケーションの開発運用で当たり前に必要とされる画像変換の中身 by @unak

  • アップロード時にサーバサイドで加工したいが、ImageMagickは重厚長大すぎる
  • かといって、しがらみが多すぎて画像変換エンジンを自分で作るのは大変
  • まあSaaSが良いんじゃないですか（宣伝）

スライド：Internal of the image processing required on the developing of web applications - Speaker Deck

このあいだWAVファイルをRubyでいじってたんですが、同じようなことを感じました。

メディアフォーマットは記号化の仕様がいっぱいありすぎて、汎用的なソフトを作ろうとすると工数がとんでもないことになりますね……

Ruby on Railsの正体と向き合い方 by @yasaichi

  • DHHの解決：少人数のスタートアップ開発で速くてキレイを実現する
  • Railsの限界は「柔軟さと疎結合を犠牲にした」トリックの裏返し
  • 解決はコードレベルとアーキテクチャレベルがあり、コードレベルではなかなか解決しないがアーキテクチャレベルだと難易度が高い

スライド：Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it? - Speaker Deck

今回の発表でひとつベストトークを選べと言われたら、自分は間違いなくこれを選びます。衝撃でした。

自分はRailsがWebアプリケーションフレームワーク初体験で、よく言われる「Railsは密結合」というのがわかっていませんでした。

（学生時代のメインはFortranで、前職でClassicASPでHTMLにコードを埋め込むみたいな実装をしてたので、Railsのレベルで十分疎結合に見えてた）

Clean Architectureを採用したHanamiを例に挙げ、Railsの密結合な部分を見事に解き明かし、鮮やかに説明しておられました。

すなわち、Modelがユースケースと密結合しており、ユースケースの組み立てや入力値バリデーションまでここに書くことになってしまっている。

さらに、ビジネスロジックを記述すべきモデルと、ORマッパーたるActiveRecordが不可分のものになっているため、特定テーブルのCRUD操作以外の処理を書くことができない。

fatModelは当然の帰結だったというわけです。

アーキテクチャレベルで回避する手段はそれこそマイクロサービス化なんですけど、逆に言えばリポジトリのレベルで分けないと分割できないので、やっぱり巨大システムにはRailsは向いてないんだなとわかります。

こうなると、別のFWを勉強したくなりますねー。やっぱりHanamiか、それとも別の言語か……

フレームワークはアーキテクチャの思想ありきなので、いっぱい調べてそちらをスクリーニングしてみるのが先かもしれませんね。

ともあれ、一気に視座が高くなる体験をするという神プレゼンでした。

カルパスさんが上げたハードルを軽々と超えてくるもんだからもう……

Evolution of Enumerator by @knu

スライド：Evolution Of Enumerator - Speaker Deck

Emumerableモジュールは神。Project Eulerを100問解く過程で心からそう思いました。

メソッドチェーンでロジックを繋げて答えが一撃で出るのが俺Tueeeできてたまらん。

Rubyの機能は、使わない人にとっては気にしなくて良いだけなので、少しでも需要があればなるべく入れていく方針のようですね。助かります。

懇親会で@knuさんと直接お話したのですが、「まだまだ開発は続けるので欲しい機能があれば言ってください」と言われました。

Project Euler再開したくなりますね。

正規表現エンジンを1.9で入れ替えた理由を聞きたかったのに、酔ってて忘れちゃって聞きそびれた。。。

自分たちを信じられるチームが作りたくて私はこうした by @katsumata-ryo

  • スクラムはフレームワークなので、乗っかっていればタスクの粒度が揃った上で自己組織化し、チーム vs. 課題という構図を作れる
  • その他、取り組みとしてはおやつタイムで質問しやすさと課題発見しやすさを担保したり、モブプロでドメイン知識の共有をしたりしたのが良かった
  • Scrum BOOT CAMP THE BOOK を読もう

スライド：railsdm_katsumata.pdf - Speaker Deck

標準的なスクラムチームのお話ですが、普段から机上論に耽りすぎて「標準的なスクラムチーム」を実現する難易度がとても高いのを忘れている気がします。

スクラムをアレンジして自分たちのチームに適用させていく、足りない部分があれば新しい取り組みをしていく、というのは100%リーダーの行動力とキャパに依存するので、マネできるところからしかマネできないですね。

マネから始めて、リーダーがキャパを上げて行動力を身に着けていくのは非常に良いことなので、否定しないどころかむしろやっていくべきと思いますけどね。

自己修復的なインフラ by @sinsoku

  • IAMユーザは一人ひとつ、ロールは一人複数、という形で設計されている
  • Infrastructure as Codeのメリットの中で出色なのは履歴を残せるところ
  • インフラをいじったあと、テストが失敗したらrevert commitを勝手にするしくみを作れれば、自己修復的なインフラができるのでは？

スライド：自己修復的なインフラ -Self-Healing Infrastructure-

過去はRailsにフォーカスした発表をしてきた神速さんですが、今回はインフラの話でした。

なんだろう、インフラにはあまり明るくないのでコメントができないのですが……

結局どこかでやらなくてはならないことなので、どう立ち向かっていったかが気になりますね。

Day2編のまとめ

Day 2で聴講したのはマネジメント系の話題が多かったような気がします。

Railsに関連した話は少なかったですが、異なる技術の交差する場所としての捉え方や、アーキテクチャレベルでRailsの限界を考察するなど、視座を上げるのに良い話が揃っていました。

バラエティに富んでいた、という意味ではRuby本体の解説の話やインフラの話など、Day 1以上のものだったと思います。

こんな感じで、2日目はお酒の力を借りて強い人（@koicさんと@knuさん）に話しかけられて、しかも疑問をすっきり解決できたのがとても嬉しかったです。

前日まつださんと話せて心理的ハードルが下がっていたのかな。

それから、

しおいさんとは初めまして、けんさんとはお久しぶりですだったのですが、お二人とも過去の登壇資料とか見てくださっていたようで、嬉しい限りです。

特にしおいさんには前回RailsDMに登壇した際の内容を絶賛されて、なんだか恥ずかしかったり。

expajp-tech.hatenablog.com

あと、Tama.rbに誘われちゃいました。次は「メタプログラミングRuby 第2版」を読むということで、二つ返事で参加しますと言ってきました。

7月頭にTamaRuby会議があるそうなので、そちらにもお邪魔することにします！機会をいただけるなら、なにか話したい。

そんなわけで、RailsDM 2019は最高のイベントでした。

本当に主催者のカルパスさん（@yoshi_hirano）には感謝しかありません。

今回でRailsDMは完結ですが、やっぱりこの勉強会は自分にとって特別なんだな、という思いを新たにしました。

RailsKaigiと名前を変えて帰ってくるということで、次はぜひお手伝いしたいですね。

では、また。

*1:出張撮影サービスのLovegraph[ラブグラフ]｜想い出を写真に。