3月7日にOmotesando.rb#95に参加しました！
【オフライン開催】Omotesando.rb #95 - connpass
参加しての感想・自分で気になって調べたことを記録しています。
間違い等ありましたらコメントいただけたら幸いです。
会場提供：タイミー様 ShintaniTeppeiさん
Timee：スキマバイトサービス、リリースから約5年、ワーカー700万人
企業・サービスの説明のあとにRailsの話がありました。
「has many throughの落とし穴」
Rails の has many through 経由でモデルを削除すると destroy callback が呼び出されない - カレーの恩返し
Shintaniさんのブログに詳細がありました。
そしてFBC卒業生で今回参加されていたSakiさんの記事がわかりやすいです。
has_many: through で dependent: :destroy を付けないとafter_destroyが走らない - Saki
Shintaniさんからご連絡をいただき、User.find(1).books = [ ]をするとBookingをDelete ALLするとのことでした。
たしかにDeleteALLされ、設定していたafter_destroyコールバックは実行されませんでした。
Userモデルのhas_many :books, through: :bookingsにdependent: :destroyを追加します。
User.find(1).books = [ ]を実行するとDELETEがそれぞれ実行されafter_destroyコールバックもそれぞれ実行されました。
dependent: :destroyの有無で挙動が変わることが知れて良かったです。
最初うまく再現できずShintaniさんからもご連絡いただいたのですが、再現できていなかった原因は自分がモデルを書き間違っていたことが原因でした。大変失礼致しました。
助言してくださってありがとうございました！
hamachanさん
「LispしてたらRubyが楽しくなったので共有します BUPG編」
ボトムアッププログラミング：BUPG
先日知った言葉だったので、知っている単語というだけでテンション上がりました！
プログラムの下流から組み立てて、全体の設計を煮詰める前に書き始められることが特徴。
小さい関数を書いたらちょっと大きい関数を書く、と言った具合進めていくそうで、
「小さい成功を積み重ねられる開発は楽しい」とおっしゃっていました。
また、エラーを見つけるのも簡単で、理由は最後に作った関数が原因だから、とのこと。
そこまで順調だったわけだから、確かになと思いました。
またLTではSlimuxというものを使っていて初めてみたのでとても面白かったです。
「技術書典と私 [2018~]」
前回のLTにも技術書典のお話があってそこで初めて技術書典の概要を知ったのですが、私は技術書典に行ったことがないので興味深く聞かせていただきました！
売れなくても良い、書きたい、という思いから本を書いているそうです！
LT内ではお金の話等も含めてかなり詳細を話してくださっていて、技術書典に興味がわくLTでした！
過去のkaibaさんの本はこちらで買えるそうです↓
kaiba - BOOTH
表紙が独特で目をひきます！👀
ぱRailsで苦戦したElasticsearch気になる…🐟
今年も新刊を出されるそうです！
funaki0415さん(@funakimasano)
「STI導入で開発スピードアップ！一元管理で外部連携をスムーズに」
STIがわからなかったので調べました。
STI：単一テーブル継承（SingleTableInheritance）
Active Record の関連付け - Railsガイド
【Rails】単一テーブル継承(STI)について #Rails - Qiita
同じ設計のテーブルを異なるモデルで共有するもの、のようです。
STI自体も初めて知ったので、X上がざわついているのか分からなかったのですが、
以下の記事のアンケートへの返答やコメント欄をみるとなかなか意見が分かれているというか、安易に使うと痛い目をみることもあるものなのかなぁと思ったりしました。
みんなRailsのSTIを誤解してないか!? #Rails - Qiita
今回
STIを導入した理由は、多数の外部サービスとの連携が必要になり、チームごとに効率よく実装する必要があったこと、そして複雑な処理などが不要だったことだそうです。
メリットとして、新しい外部連携をするときにフォーマットがあると楽、とおっしゃっていました。
そして、
STIはあくまで手段で、設計レビューを通じて
STIが適切な手段かを常に評価している、とのことでした。
業務に関するお話は自分がまだ触れたことのない部分なので、聞いていて興味深かったです！
naoさん(@philosophy_note)
「壁を乗り越えるためにGemを作成したら無知を知った話」
競馬予想が好きからの競馬予想AIアプリ開発からのエンジニア転職はパンチがきいてました🐎
業務の中で取得できない文字がある、という悩みから文字を変換するgem「mojicon」を作られたそうです。
インストールして実際に色々やってみましたが面白かったです！
そのあと出てきた「
Railsエンジン」を知らなかったので調べました。
Rails エンジン入門 - Railsガイド
エンジン (engine) は、ホストとなるRailsアプリケーションに機能を提供するミニチュア版Railsアプリケーションとみなせます。
Railsはエンジンを一種の「完全なプラグイン」とみなしている点です。
Gem、Railtieプラグイン、Engine（full/mountable）の違いとそれぞれの基礎情報 #Ruby - Qiita
よりRailsアプリケーションの中身に踏み込みたい時、つまり、既存アプリのControllerやModel、Routing等を拡張したい時に利用。
Railsエンジンをgemとして配布できる、とあったので、ほぼ同じようなものと考えてよいのか…？
gemはOSSでエンジンはOSSでなくても良いということ？
なかなか難しく理解が浅いですが、Railsエンジンというものがあることが知れて勉強になりました！
いけむらさん(@fd0)
「Ruby on cygwin (2024/3月号)」
Cygwinの
Rubyのバージョンを2.6から3.2まであげたというお話でした。
公式のメンテナになるところからのスタートとのことで、まずそこのやりとりから大変だったとおっしゃっていました。
Cygwinは
Windows上で動作する
UNIX互換層となるソフトウェアとのことで、WSLが一般化してからそっちを使う人が増えてそうとのこと。
ちなみにご本人は
Macの中の
Windowsに
Cygwinを入れているとおっしゃっていました！すごい…
メンテナになるにあたり
メーリングリストでやりとりをした、というお話で参加者の方々が「MLは大変だ…」と口々におっしゃってたのが個人的には印象的でした。
(自分はMLを使ったことがないので大変さが分かっていません…)
Fohte(ふぉーて)さん (@fohte)
「rubocop-daemon 裏話 OSSの苦悩」
前日のGotanta.rbでのLTの資料
普段私はgemを利用していて、正直OSSオーナーの苦労を考えたこともありませんでした。
LT内でお話されていた苦悩は、英語に関する共感できるものからシェルスクリプトのコマンドがOSで挙動が異なるといったがっつり技術的なものまで様々でした。
(ぜひスライドみていただきたい…👀)
OSSはとても便利で実装も見れる(今は見ても分からないことがほとんどですが…)し、ユーザーとしてはとても良いのですが、
当たり前ですがそれを作った人がいて人が管理しているものだということを忘れてはいけないなとLTを聞いていて反省しました。
「OSSオーナーへのリスペクトを」と最後におっしゃっていて、本当にその通りだなと思いました！
雑談
FBC生＆卒業生の方々とプラクティスの苦悩や就活の話などできて楽しかったし励まされました！
また、RailsGirlsTokyoでコーチをされていた方が私のことを覚えていてくださったのもとても嬉しかったです！
帰る時にも参加者の方と一緒に駅まで歩いたのですが、
いろんな地域.rbがあるなかでOmotesando.rbはとても和やかだから初心者も参加しやすい会だとおっしゃっていて、そんな会に出会えて私はラッキーだな🙌と思いながら帰りました！
まとめ
今回もLTは難しかったですが、面白かったしとても勉強になりました！
そして少しずつですが他のエンジニアの方々とお話できるようになってきてとても嬉しいしありがたいです！
今後も参加したいと思います！
ありがとうございました〜！
