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

中の人は20代後半Web系エンジニアです。テーマは闇鍋ですが、マネジメント、Ruby/Rails、ブロックチェーンの話題が多めです。

【TamaRuby会議01】Rubyのパターンマッチングについて喋りました #tamarubykaigi01

f:id:expajp:20190715232641p:plain

先週、「TamaRuby会議01」というイベントで、「brainf*ck処理系で理解するパターンマッチングをつかった疎結合な実装」というタイトルで喋ってきました。

tama-rb.github.io

Rubyistとしての成長」をテーマにした地域Ruby会議です。多摩といいつつ、場所は渋谷だったわけですが。

イベント自体の様子は漏れなくtogetterにまとめられていて、

togetter.com

ブログを書いている方も、基調講演の伊藤さんをはじめ、すでに何人もいらっしゃる

blog.jnito.com

phayacell.hatenablog.com

yazawa-tech.hatenablog.com

ので、イベント全体について語るのは縮小再生産かな、と思います。

というわけで、このエントリでは個人的に考えたことや思ったことを書いていきます。

(追記)参加した方向けにアンケートが行われているようです。

自分のトークについて

スライドはこちらです。

speakerdeck.com

大雑把にまとめると、

  • パターンマッチングは密結合コードの温床なのでは?と思った
  • 昔書いたbrainf*ck処理系をパターンマッチングで書き換えようと思ったが、無理だった
  • 「無理だった」ことで「使いどころの違い」と「パターンマッチングはインタフェースを揃えられない入力に有効であること」を理解した

という内容でした。

スライドの中でも言ってますがタイトル詐欺ですよね。

なんでタイトル詐欺になったか

もともと計画していた内容は、「パターンマッチングでbrainf*ck処理系を書き換えて、実際のコードを検討しながら、両者の違いについて検討していく」というものでした。

1ヶ月ほど前から準備を始めて何度も何度も何度も何度もコードとにらめっこを繰り返したのですが、どう頑張ってもcase ~ when文で書かれている箇所を書き換える程度にしかならないことに本番3日ほど前に気付きました。

書き換えたコードをもとに一気にスライドを作り切る計画をしていたので慌てて軌道修正を図ったのですが、根本的な軌道修正は終業後のわずかな時間の積み重ねでは到底叶わず、結局本番前日に会社を早退してシナリオを書き直したのでした。。。

スライドは事前にテンプレだけ作っていたので、徹夜で無理やりカタチにしました。

こういうわけでタイトル詐欺になりましたが、結果的にギリギリまとまりのあるものを出せました。また、「成長」というテーマに合致するものにもなって結果オーライでした。

このテーマを選んだ理由

パターンマッチングは密結合コードの温床になるのでは?」という疑問はRubyKaigi当時からずっと抱いていました。

この疑問はRubyKaigi 2019 After Partyで何人かの方にぶつけてみて回答も得られたのですが、自分の中ではイマイチ腹落ちせず。

その後、Twittermohikanzでも同様の疑問を投下してみたところ、

あるベテランエンジニアから

「どんな方法でデータを渡されても解釈できる」的使い方ができるようになる気がする。これはむしろ疎になる方向に働かないか?

大学の後輩から

前提が違うかもしれませんが、この辺の話です?

oop - How does Pattern Matching in Scala overcome duplication that switch case causes? - Stack Overflow

というコメントを得て、理解できそうな気になりました。

あとは自分で手を動かすだけ」だと。

Rubyistとしての成長」というテーマを見たときには、正直エモ話が多くなると思ったので「様々なコミュニティに属していてよかった、手を動かすのはよい」みたいな話にしようと思ってCFPを書いたのでした。

フタを開けてみたら技術的なトークテーマが多かったので、10分という制約もあいまって結局テーマにたどり着くまでの話はバッサリカットすることになりました。

代わりと言ってはなんですが、ここで供養しておきます。

基調講演・他の方のトークについて

上記の通り、自分の発表はイマイチな手応えだったのですが、基調講演や他の方のトークは素晴らしいものばかり。徹夜明けの眠い脳みそで聞いててもひと時も眠くなりませんでした。

いくつか抜粋して短く感想を書きます。

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

伊藤淳一(@jnchito)さんの基調講演です。スライドはこちら。

なぜテストを書くの?(または書かないの?) 〜テストコードの7つの役割〜 / #tamarubykaigi01 - Speaker Deck

仕事でテストコードを書くときは境界値分析や同値分割に則って設計をしていても、「境界の数が多すぎる」だとか「想定される入力値が多すぎて同値分割するにも多すぎる」という現実に押し流されて妥協点を探ることになりがちです。

ここで提示されたテストを書く目的が、現実的な工数にテストケースを減らす妥協点を探るためのひとつの指標になると思いました。

発表も、スライドの構成が明確な上によどみなく話をされていて、さすがというかなんというか。

伊藤さんはリアルで初めてお会いしたのですが、気さくな関西人というイメージの方で、Web上の紳士的なイメージとは良い意味でギャップがあって驚きました😅

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

主催者の一人、fuqda(@fuqda90)さんのトークです。スライドはこちら。

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

OSS貢献って実はやったことがない(自分で作ったことはある)んですが、自分にはない知見を得るという意味では最高かもしれないですね。

オープンソースコミュニティは自己組織化されることで遠隔でも回る仕組みなので、飛び込むことで見えることもあるかも。

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

こちらも主催者の一人、しおい(@_coe401)さんのトークです。スライドはこちら。

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

トークの主題がコードリーディングであるにもかかわらず、わかりやすい……

コードリーディングのプレゼンはどこかで置いていかれると残りが全くわからなくなり、つらいことが多いです。でも、しおいさんの発表は(早口だったにもかかわらず)スライドも内容も丁寧につくられていて、見る側のことがしっかり考慮されたものになっていました。

しかし、しおいさん遠くに行ってしまったなあ🤔 自分も頑張らなくては……

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

サポーターとしてイベントの記録係📸をされていたKatsumata Ryo(@katsumata_ryo)さんのトークです。スライドはこちら。

成長に期待しない目的志向実践のススメ - Speaker Deck

「成長」という言葉への違和感は自分も抱いていました。

実際、ポジティブな言葉のはずなのにやりがい搾取に使われているイメージが強すぎて、どうもこの言葉は好きではなかったのです。

かつまたさんの言う通り、「やりたいこと、やらなきゃならないことを見つける」という目的なくして、成長は成立し得ないですよね。

やりがい搾取に使われる「成長」は、「明確な目的はないけどなんとなく成功を手に入れたい世間知らずな人」に自分の都合の良い目的を与えて盲目的にさせる、一種の洗脳のようなものです。

余談ですが、最近プログラミングスクール出身者を相手にしたキナ臭い商売がポコポコ生まれてるのも同じでしょうね。

自分も以前どのように成長するかの発表をしたことがありますが、これはさらにその前段階のHowを説いた発表でした。

白魔術師への道

こちらは五十嵐邦明(@igaiga555)さんの基調講演です。

Road to white mages - Speaker Deck

「魔術をproductionコードに入れない形で使ってみてはどうか」という着想がまず素晴らしい。これなら仕事ですぐに使える!というテクニックが揃っていて、メタプログラミングの入門とRubyKaigiで話されるようなレベルの黒魔術との間をどう埋めるかという、ありそうでないアプローチの発表でした。

と、何やら偉そうなことを言っておきながらメタプログラミングRubyは未読というのがコンプレックスなので、いま読んでるパーフェクトRailsさっさと終わらせて読みます。。。

懇親会について

懇親会では@neko314_さんと初めましてしたり、@konchan_xと闇の深い話をしたり、@popmac1451さんからRailsDMのときの感想を聞けたりしました。

初めましての人が多くてよかったのですが、もっといろんな人と話したかったなあ。一度話が始まっちゃうと、別のところには混ざりづらいですよね。

今後どうしたいか

OSSについての発表が多かったので、そちらの欲を刺激されました。

いま作りたいけど作り方がわからないgemがあって、kaminariが参考になりそうだなと思うので読んでみようと思います。

github.com

まあ、「やろう」というのは自由だし時間も作れるんですが、JS触ってたり設計の本読んでたりマネジメントの本読んでたり英語の勉強してたり仕事はしなきゃいけないときはしてたり趣味の合唱の練習やら運営事務やらしてたりするので、なんというか分散して時間が細切れになっているのが良くないなと思っています。

かといって、これらを「やらない」のも不安になって嫌なんですよね。どうしたものか。

よかったら誰か良いアドバイスください。

まとめ

  • 「様々なコミュニティに属していてよかった、手を動かすのはよい」みたいな話をしようとしてCFPを出したら、紆余曲折あってタイトル詐欺になった
  • 徹夜明けだったのに良い話ばかりで全く眠くならず、OSS読みたくなった
  • 時間が細切れにならない方法だれか教えて

昨年から高い頻度で登壇してたんですが、次の登壇予定はしばらくナシです。

そろそろふりかえりの時期なのかもしれませんね。

ではでは。