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

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

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

f:id:expajp:20190326235451j:plain ※写真はフォトスポンサー:LOVEGRAPH*1さんの撮影

3/22金、23土と開催されたRails Developers Meetup 2019に行ってまいりました!

railsdm.github.io

過去最大規模での開催ということで、登壇者の顔ぶれは超豪華、かつトークの内容も気合の入ったものばかりでした。

RailsDMは月次開催の時代に1回、2017、2018のDay 1, 2, 4, そして今回と参加してきましたが、過去最高に楽しかったです。

トークを3行でまとめた

今回は勤務先がスポンサーということで業務として参加したので、給料泥棒と言われないように効率よく持ち帰る方法はないかなーと思って、さっと思いついたのがこの方法。

聴講したトークを無理やり3行以内でまとめる ことです。

これを意識するだけで、話の構造を捉えつつ、その流れの中で何が言いたいのかを考えながら聴くことができます。

院生時代に准教授の先生に本を読むコツとして教わったものですが、本当に役に立ちました。

本記事では、トークを聞きながらまとめた内容を順に公開しながら、少しずつコメントを書いていきます。

なお、基調講演とスポンサーセッションは対象外です*2のであしからずご了承ください。もっと英語力がほしい。

アプリケーションを作るときに考える25のこと by @onk

  • フレームワークの役割は、「難しくて価値があるもの」を「すぐ作れて価値がある」ものに変えること
  • 狩野モデル:「当たり前品質」を考えてベースにしよう
  • gemの探し方:GitHubを検索してStarしてる人と参照してる人を見よう

スライド:アプリケーションを作るときに考える25のこと

最初のトークはこちらでした。探し求めていたgemの探し方のノウハウがいきなり来たということで、頭が上がりません。

DevOps, Immutable Infrastructure, microservices そして Chaos Engineering by @yoshiori

  • インフラ周りがいかにimmutable化されてきて、その影響で何が育ってきたかの歴史の話
  • インフラがimmutableになった結果、計測可能性が上がって現在はその技術の発展途上
  • 定常状態を定義してカオスエンジニアリングができるようになった

スライド:DevOps, Immutable Infrastructure, Microservices and Chaos Engineering - Speaker Deck

  • 作業の切り戻しがしづらいのでコマンド1つ打つのにもプレッシャーを感じる
  • 脳内での完璧なシミュレートは現実的には無理

ことからインフラ管理はプログラミングと真逆と感じてなるべく避けてきたんですが、インフラ管理はサイエンスなんだから当然だなと認識を改めました。

自然科学の対象として見れば、作業のやり直しが効かなかったり予想できない振舞をすることがあったりするのもまあ、納得できるかな。

サーバーサイドエンジニアも知っておくべきフロントエンドの今 by @itkrt2y

  • フロントエンドとCDN Workerの話
  • エコシステムが成熟し、ライブラリの乱立が落ち着いて開発体験が良い
  • 最近の話題はレンダリングや通信の速さなど、UXに直結するものが多い

スライド:サーバーサイドエンジニアも知っておくべきフロントエンドの今 - Speaker Deck

2016年秋辺りに仕事に不満を感じ始めていて、「とりあえず手近なところから」と最悪のタイミングでJSの情報収集を始めてしまい、疲弊して追いきれねえわと諦めたことがあります。

それ以来「変化速すぎてよくわからん」ものだったJSですが、やっと落ち着いてきたんですね。

Vue.jsがとうとうバージョン3でTypeScript化されるらしいので、これも手を動かしとかなあかんやつやなあ。

Talentio をなんとかしようと頑張ってきた18ヶ月の旅路 by @rust

  • サーバ環境が再現できないLaravelのプロジェクトをコンテナ化してRailsに置き換えて行く話
  • やれることから順番にやっていく
  • 無理をしない

スライド:talentio をなんとかしようと頑張ってきた18ヶ月の旅路 - Speaker Deck

なんだろう、これは一つのお手本というのが良いのでしょうか

冷静に問題をブレイクダウンし、各個撃破していけば、って頭でわかっていても混乱しちゃいますよ普通……

淡々と話をされていましたが、エンジニアとしてリアリストであるには腕前は必須なんだなと思わされるプレゼンでした。

サービスを成長させる「仮説検証文化」のつくり方 by @takatoshi-maeda

  • ユーザストーリーとして仮設を定めると仮説の検証がやりやすくなる
  • ユーザの行動とユーザの体験は別々で、それぞれ点と線で計測できる
  • 細かい仮説検証のイテレーションをチームで回すことで、共通のゴールが見えやすくなる

スライド:railsdm2019 - Speaker Deck

これも、一つのお手本でしょうね

そのぶん話の内容に大きな驚きはないのですが、これを実践するのがどれだけ難しいことか……

ユーザストーリーをプロダクトに即して具体的に定めるところまでやって、はじめて計測のスタートラインに立てるんですね。

万葉のRails新人研修のコードレビューコメントを分析してみました by @nay3

  • 初心者には「動くのは3%」と伝えていかなければならない
  • レビュアーの関心事はプログラマとしての「長生きするソフトウェアを作りたい」という価値観
  • セルフチェックできるリストを用意できれば、自分で気付いてくれるのでは?

スライド:万葉のRails新人研修のコードレビューコメントを分析してみました - Speaker Deck

個人的には、これが一日目では出色でした

技術トークって理論と経験のギャップを語るか、やりたいことに対する実装を語るかのどちらかになりがちなんですが、 これは人文科学系の研究のように、統計をとった上でその背景にある行動原理を分析するという形。

珍しい形態であるとともに、出てきた結論も非常に有益なもので、泥臭い分析の尊さを感じました。

ユビレジのチーム開発 by @katorie

  • ユビレジさんのスクラム開発の話
  • 普通のことを普通にやる
  • みんなのいいところを引き出してチーム全体のパワーに変える

スライド:Team development at Ubiregi Inc. (Rails Developers Meetup 2019) - Speaker Deck

こういう場所でチームの良さを自慢して全く嫌味にならないって地味にすごいことだと思うんですけどどうでしょうか?

ユビレジさんがこれだけ良い環境なのは「良い人が集まっている」からなのは間違いないんですが、それは思考停止ワードでもあるので、そうでない理由を考えてみました。

平常開発だけでなくコミュニケーションや緊急対応まで仕組み化することで、徹底的に不要な判断のコストを減らし、精神的な余裕を保っているから、というのはどうでしょうか?

7年目を迎えたRailsアプリケーションの傾向と対策 by @taogawa

  • レールを超えたその先の話
  • レールを延ばすときのパターンにある共通認識は「なんとなく」なので、落とし穴を公開していくべき
  • あくまで主役はモデルなので、それ以外が太るのは落とし穴

スライド:7年目を迎えたRails アプリケーションの傾向と対策/Rails Developers Meetup 2019 Day1 - Speaker Deck

レールを延ばす話はRailsのイベントでは必ずと言っていいほどあるトークなのですが、だいたいハズレがないですね。

それは目新しい話だからで、世にレールの延ばし方の共有が進んでないことの裏付けだと思うのですがどうでしょう?

やっぱり、各社の取り組みをもっと公開していくべきですね。

Railsアップグレード百景 by @r7kamura

  • とにかくアップグレードに伴う差分を少なくする、ただしバッチは最新まで上げる
  • 組織を挙げての対応が必須
  • テストさえちゃんと書けていれば不具合は必ず検出できる

スライド:Extending Rails for Real World App Development - Speaker Deck

いやーほんと大変ですよねアップグレード。。。

ただ、おっしゃるようにテストコードがあればゴールが可視化されるんですよね。

ゴールの見えないマラソンほどしんどいものはないですからね。

毎日の開発に役立つRailsプラグインづくりの秘訣 by @a_matsuda

  • gemは現場の問題から作る
  • 現場の問題から生まれたものでないと、趣味の開発は続かない
  • 小さく作ってすぐリリース

スライド:Extending Rails for Real World App Development - Speaker Deck

松田さんのすごいところは現場の問題を世間一般の問題という視野で見られるところだと思います。

gemのアイデアいくつか溜まってきてるし、行動に移したいな

Day 1編のまとめ

ご自身の軌跡を語る人、組織文化を語る人、Railsを語る人、JSを語る人、統計をもとに考察する人……

ひとくちにRails開発に関する発表といってもこれだけ多種多様になると、聞いていてまったく飽きませんでした。

この日の懇親会は勤務先で手配したケータリングが届かなくて気が気じゃなかったですが、ギリギリとはいえ無事到着。

ほっとしたおかげかお酒も進み、@a_matsuda さんをはじめ多くの方と話せて光栄でした。

学生さんとも何人か話しました。言い訳して多くの時間を投げ捨てていた昔の自分に説教したい気分になりました。

まあ、時間は返ってこないので今から頑張るしかないんですが。。。

Day2編は近々アップしますね!ではでは。

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

*2:DHHとJeremyの発表は英語力不足でまとめられず、高橋さんの発表はスポンサーとしての仕事で全部は聞けず