Tama Ruby 会議 01 に行ってきた

tama-rb.github.io

こちらのイベントに行ってきました。
転職先の @fuqda さんが Tama.rb Organizor と聞いて、それきっかけでの参加です。

本イベントのハッシュタグは以下。

twitter.com

以下、聴講中のメモを残します。
Twitter で見かけたリンクも貼っておきますね。

登壇内容を全体的に網羅しているものではなく、個人的に感銘を受けたとか、刺さったことをメモに残しているので、詳細はスライドを見たほうが良いかもしれません。

なぜテストを書くの?(または書かないの?) Junichi Ito

speakerdeck.com

テストを書くのが目的になってないか?
目的と役割。
マッチする目的がなければテストを書かなくても良いし、書けないもの。

安全ネットとしての役割

自動テストで追加・修正しても壊れないことを保証する。

なぜ?
大規模なプログラムを毎回手作業で再テストしたくないから。
プログラムが壊れると迷惑がかかるし、長く運用される見込みがあるし。

実装の正しさを確かめる役割

ちゃんと要件を満たしているか確かめるため。
パスしたら自信を持ってリリースできる。ただし、テスト項目に抜け漏れがなく、確実に異常を検知できること。

なぜ?
不具合がないことの担保。
人と違ってヒューマンエラーが起きないから。

コードの品質を向上させる役割

ちゃんとリファクタリングできる!
コードレビューの指摘事項を修正するのに、テストコードがあると直しやすい。

なぜ?
可読性や保守性を高めて、将来の開発工数を減らせるから。
あと精神的ストレス。

省略化ツールとしての役割

手と目で確認するのは大変なので。
テストを書くとトライアンドエラーがやりやすくて工数削減できる。

なぜ?
自動化した方が最終的なコスパが良い。
他の開発者にドロップインで貢献してもらいやすくなったりもする。

バグを叩き潰す役割

不具合を発生したら、先にテストコードから書く。
単発的なレッド→グリーン。

なぜ?
不具合の再発を防止できる。
再発すると顧客からの信頼を失うから。
テストコードを書くと試行錯誤しやすい。

設計を支援する役割

実装する前にテストコードから書くと、設計に役立つ。テストファースト
対話的に実装を進めることができる。
ここも、レッド→グリーン。

なぜ?
設計の良し悪しに気付きやすくなる。

説明書としての役割

テストコードを読めば、プログラムの仕様やデータ構造がわかる。
新機能なども、テストを読めば使い方がわかりやすい。

なぜ?
他のメンバとか将来の自分が理解しやすくなるので。
読むだけでなく、動かして確認することができる。

なぜテストを書くの? vs 書かないの?

先述の「なぜ」を反転してみると、書かなくて良い理由が出てくる。
ただ、仕事でコードを書くなら自動テストが不可欠な状況になりがち。

それでも書けない人への処方箋

優先順位をつけてますか?
ここが壊れると致命的という箇所から書くと良い。コスパも良い。

テストしやすい設計・データ構造になってますか?
Rails のレールに乗るようにしよう。
責務の分割を適切に。

勘と経験だけでテスト項目を決めようとしていませんか?
体系的なテスト技法で学べる。
最少・最善のテスト項目を用意する。

ツールの使い方やテクニックは習得していますか?

原理主義的なルールにとらわれすぎてませんか?
ある程度は雑なテストコードも許容しよう。
大事なのは目的と役割。

ちゃんと試行錯誤してますか?
ツールのくせやよくある落とし穴があるのは覚悟しておこう。
習得には時間がかかるのものなので、たくさんテストコードを書こう!

どの役割で自分がテストコードを書こうとしているのか、よく考えてみよう!
どの役割に当てはまるのかは、排他的ではない。チェックボックス的。
テクニックにだけ注目しすぎず、役割と目的を意識しましょう。

成長には時間がかかるもの。
振り返ると、ちょっと苦しい経験の方が成長につながる。
講演を聞くだけでは苦しくないので、まだ成長できないので、泥臭くやっていきましょう。

プロになるためのレビューのススメ konchan

speakerdeck.com

レビューをされた or したときに成長を実感。

レビューされるメリット

ベテランのチェックでコードの品質をアップして、スキルアップ
見てもらうために読みやすいコードを意識する。

レビューするメリット

おすすめ。

まずプロの技を盗める。
責務分割とか移譲とか、自己代入、依存性注入とかとか。
こんなことやってるんだ〜というテクニックを見ることができる。

コードから始まるコミュニケーション。
アーキテクチャの話とか。
関連する話につながっていって、周辺知識を身につけるきっかけになる。

プロジェクトの状況を把握する力が身につく。
自分ならどう実装するか比較しながらやれるので、教えることもできるし、学ぶこともできる。

レビューサイクルのメリット

適切な単位で PR を作成するようになる。
見る側を体験することで、見られるときにどのくらいのサイズで作るのが良いのかわかってくる。

相手に理解してもらうために資料を用意する。
いろんな図を用意したりする中で、便利なツールも覚えたり。

OSS初心者がつまづきながらOSSマナーを学んでいく話 fuqda

speakerdeck.com

憧れの先輩を真似て始めてみたら、学びが深くなった。

Rails にモンキーパッチをあてて、気づき。
そのまま使えば良いわけじゃない。
複雑な要件に立ち向かうときに必要になる。
で、自力で直せるようになりたい!

パッチを送るためのアプローチ。
気になるリポジトリのコードを読み漁る。
業務で困っていることを洗い出す。

プルリク出す手順は OSS初心者がRailsにプルリクエストを送ってマージされるまでの一部始終 - Qiita にまとめられている。

郷に入っては郷に従え。
公共スペースだから、その場のルールや思想にならってやると良い。

brainf*ck処理系で理解するパターンマッチングをつかった疎結合な実装 Shu OGAWARA

speakerdeck.com

Ruby 2.7 のパマーンマッチング。人気。
気持ちよくハマるパターンが多そう。

だけど Ruby のお約束に反してる?
密結合が加速する?
パターンマッチングが動いてしまうと、呼び出し側の機能が引数に応じた動きをできてしまうので、Ruby に合わないのでは?

パターンマッチングの強み。
一つのメソッドでオーバーライドメソッドに近しい動作をさせることができる。
インターフェイスを揃えられないパターンで嬉しい!
既存のデータ構造上の都合に寄せられる嬉しさ。

勘違いに真摯に向き合って、自分で嬉しさを見つけた成長。

こわくないDSL ken3ypa

speakerdeck.com

万葉の人。
https://everyleaf.com/articles/50

スライドが多くて早くてメモする余裕がない。
でも楽しい発表。

eval 族。
これでやりくりすると main にいろいろあれこれしている。
DSL は怖くなくなる!

ぼくらのリファクタリングは裏切らない💪 ほたて

speakerdeck.com

いわく、エモい話。

リファクタリングが必要になるタイミングにはもう遅いのでは?
もっと前からやっておかないと手遅れに……。

リファクタリングして良かったこと。
コード読みやすくて助かったって言ってもらえたり、ペアプロ・モブプロでやれて学べた。

そしたら社内で整地部が立ち上がる。
PORO。
リファクタリングの方向性も見えてくる。

たのしいOSSコードリーディング: Let's read "cookies"🍪 しおい

speakerdeck.com

詳しいのは たのしいOSSコードリーディング: Let's read "cookies"🍪 - Qiita に。

聞いててめっちゃ楽しかった。
RailsCookie をどう扱ってるのか、早いけど丁寧でわかりやすく説明されていた。

あと 🍪 の絵文字がかわいい。

コードを「見る!書く!見てもらう!」で爆速ステップアップ! s_naga03

speakerdeck.com

コードレビューは自分が至っていないレベルにジャンプできるチャンス。

早期リターンとか、それを使うにしても TPO に合わせるとか。
既存コードは最適解とは限らないとか。

読んで、書いて、見てもらう。
恥を捨てて見てもらって、周りの力を借りて爆速でステップアップしていきましょう。

Dartに浮気したらRubyは最高だと再認識した話 makicamel

speakerdeck.com

Dart はよく死ぬ。
Ruby より死んでるかも。

開発体験は良さげ。
でも、Ruby でできることができない。
日付操作が不便。

OSS 作成の機運。
自分が困ってることは誰かも困っている。それはissueで確認済み。

以下、すごくいい格言。

  • ググるのは俺が最後でいい
  • 現場のいまある課題をきちんとオープンなコードで解決する

というわけで、つくったみたい。
すごい!

暦は面倒で難しい。
Ruby はそれを最高の体験にするために commit を積んできている。
したいように書けるのが Ruby の魅力。

自分の道具の歴史を知ると、身近に感じられてめっちゃ好きになるのでおすすめ。

WebAssemblyをRubyコンパイルする黒魔術コード完全解説 alitaso345

speakerdeck.com

wagyu。 WebAssembly to Ruby の変換。

めっちゃ難しい……。 proc と next の活用法が面白かった。

RubyistのためのElixir入門(以前) tsuka

複数の言語を学ぶと成長できる。
違う言語は、同じ問題に対して別のアプローチで解決策を見出していて、視野を広げるチャンスになる。
また、Ruby の向き不向きもわかる。

Elixir は Ruby の次に学ぶのにピッタリ。
動的型付け言語で、関数型言語

Doctest はめっちゃ良さげ。
ドキュメント兼テストコードになるので、メンテナンスコストが下がりそう。

Erlang の特徴を受け継いでいる。
Erlang 任天堂」で検索すると例が出てくるみたい。

勉強するならプログラミング Elixir がおすすめ。
Elixir school もある。

成長を期待しない目的志向実践のススメ katsumata-ryo

speakerdeck.com

成長ってなんだろう。
成長は過程であって、目的ではない。
努力しようとしてたら動機が足りない。

やりたいことを見つける。
やらなくちゃいけないことを見つける。
ここらへんが大事。

ダニング=クルーガー効果。

がむしゃらにやることが大切。
がむしゃらにアウトプットで成長を実感。

東京地域Rubyコミュニティ大全 okuramasafumi

speakerdeck.com

Ruby とコミュニティ。
コミュニティの話は RubyWorld Conference 2019 で Matz もしてた。
人が Ruby の性質を決めていく。

自由に話すなら Shibuya.rb。
Ruby の話をしない時もあった。

テーマに絞った Omotesando.rb。
Sansan。テーマは7つくらい。
酒も飲む。

ひとつの話題をじっくりと Ginza.rb。
メドピア。
キャンセル待ちも多い。

もくもくするなら、西日暮里.rb。
西日暮里ではあんまりやってない。
少人数でアットホーム。

リモート参加できる Sendagaya.rb。
内容はいろいろ。
毎週開催。

目黒向け Meguro.rb。
毎月末、目黒近辺の会社が持ち回り。

初学者におすすめ Otemachi.rb。
エネチェンジさんが開催。
初学者向けで、懇親会もあり。

ノンテーマ Ebisu.rb。
各月の月末に食べログオフィス。
懇親会もあり。

雑談したりもくもく Asakusa.rb。
毎週火曜日、開催回数500回。
幅広い参加者。

輪読会メイン Tama.rb。
最近は開催頻度が減ってるけど、この会議が終わったら戻るはず。

白魔術師への道 Kuniaki Igarashi

speakerdeck.com

後世の歴史家と最前線の勇者では語る内容が違う。
至るべき場所がわかった上で語るのが後世の歴史家で、どうするべきか試行錯誤するのが最前線の勇者。

TracePoint。
ローカル変数を書き換えるところがあるが、あるルートだけ書き戻し忘れていてやばかったときがある。

デバッグに使う魔術を白魔術。

  • pry.
  • ObjectSpace.
  • methods.
  • method, instance_method.
  • Kernel#caller, caller_locations.

ソースコードの世界とオブジェクトの世界。
僕たちが見ているのはソースコードの世界で、台本。
プログラムが動くのはオブジェクトの世界で、舞台。

世界の隔たりがあるから、デバッグは難しい。
今回は、どうにかしてオブジェクトの世界を見ていくかという話。

グローバル変数trace_var がある。
インスタンス変数にはそういうのはないし、オブジェクトでもない。

TracePoint.trace(:line) と書くと式代入時にブロックを動作させる。

AST も使っている。構文木
ソースコードを読み込んで、AST の node を使って解釈して、条件に加えていた。

ObjectSpace.allocation_sourcefile
オブジェクトの生産地を知る。

signal & trap.
macだと ctrl+t でinfoシグナル送れるので、そこでプログラムを止められる。
すごい。

まとめ

舞台上のオブジェクトたちと対話したり、様子を知ることができる。

プログラミングの多くの時間はデバッグに費やされている。
デバッグを楽にできるようになれば、それは私たちへの癒しになる。

白魔術と黒魔術は表裏一体。
強力な力をどう使うかは、あなた次第。

感想

どの登壇内容もめっちゃ濃くて、面白くて、興味深いものでした。
エモい話はやっぱりモチベーションが上がりますし、技術的な話はためになるものばかりでした。

テーマは「Rubyistとしての成長」とのことで、これからもっと Ruby をやっていくぞ、というフェーズでこの会議に参加できて、もう最高。

Tama.rb 会議、初開催なのにしっかりと運営されていたことも印象的です。
スポンサーがついて、会場・懇親会の食事・ドリンクまで提供があったのはすごい!

おかげさまで、楽しく懇親会に参加できました。
ぼっち参加でも、みなさん優しく絡んでくれて、ほんと Ruby はコミュニティが成熟しているなぁ、という印象が強いです。

次回があれば、また参加したいです。します。