コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

factory bot の trait内に引数のように値を渡したい場合はtransientを使う

N:Nの関連性のレコードをサッとつくるためのtraitを作りたい場合のtips

環境

Gemfile.lockは以下のような環境

factory_bot (6.4.4)
  activesupport (>= 5.0.0)
factory_bot_rails (6.4.2)
  factory_bot (~> 6.4)
  railties (>= 5.0.0)

使い方

factory_botでは一時的な属性情報として transient という機構を用意している。公式ドキュメントとしては以下のように紹介されている。

factory :user do
  transient do
    rockstar { true }
  end

  name { "John Doe#{" - Rockstar" if rockstar}" }
end

create(:user).name
#=> "John Doe - ROCKSTAR"

create(:user, rockstar: false).name
#=> "John Doe"

Transient Attributesより引用

これをtraitと組み合わせることにより、trait側に値を渡す事ができる。

利用例

たとえば以下のようなN:Nを表現するテーブルがあるとする。

booksテーブルとshopsテーブルをつなぐ「本屋さんがおすすめする本」という関連性

この場合にbooksのレコードを作るときにshopsのレコードを指定したい場合、以下のようなtraitを作成する。

# 前提としてshopとbook_recommend_shopのFactoryBotのファイルはあること
FactoryBot.define do
  factory :book do
    title { "BookTitle#{rand(100)}" }
    author
  end
  trait :recommend_shop do
    # 意図したものをセットできるようにする
    transient do
      related_recommend_shop_record { nil }
    end
    after(:create) do |self_object, evaluator|
      shop = evaluator.related_recommend_shop_record.nil? ? create(:shop) : evaluator.related_recommend_shop_record
      create(:book_recommend_shop, book: self_object, shop: shop)
    end
  end
end

このように作成すれば、以下のようにshopを簡潔にしていしてつくることができる。

choice_shop = create(:shop)
create(:book,:recommend_shop,related_recommend_shop_record: choice_shop)

こうすることで間の交差テーブルを意識することなくレコードをつくる仕組みを用意することができる。

参考サイト

リモートワークのMTG・ファシリテーションに悩んだときに読みたい『リモートワークにおけるファシリテーションの方法論』

書き留めたつもりが書き留めてなかったので改めて書き留めます。

資料スライド

speakerdeck.com

https://blog.copilot.jp/entry/remote-facilitation

みどころ

リモートワークでのミーティング・ファシリテーションのやり方に関して、具体的なノウハウに関しても紹介した資料。

過去「良い会議にするためにはゴールを設定する」「アジェンダをちゃんと作る」というところは割と色々なところで語られては来ましたが、それよりも更に踏み込んだHow to が散りばめられており、自身の進め方を問い直すのにとてもよい資料となっています。

また、この資料を読みつつ、関連リンクにあるfukabori.fmのインタビュー回を聞くとよりいろいろな気づきがあると思います。

関連リンク

Rubyで例外のキャッチをワンライナーで書くこともできる

あんまり書く機会がないのでメモ

環境

ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [arm64-darwin22]

構文

公式ドキュメント曰く

{{式1}} rescue {{式2}}

の形式で書くことができ、以下と同義になる

begin
  {{式1}}
resuce
  {{式2}}
end

公式ドキュメントにも言及があるが、ワンライナーの場合はrescueの後に記述するErrorTypeを指定することができない。そのためStandardErrorのサブクラスである全ての例外をすくい上げることにはなる。もし特定のエラーを拾いたい場合にこの記述方法は採用できないので注意。

以下のように書くことでエラーを補足することができる。

def demo
  p "テストです"
  1 / 0 rescue p "なんか例外がおきました"
end

関連リンク

競合があるWebサービスがあるときに振り返りたい資料『なぜレッドオーシャン化する前にサービスを グロースできなかったのか? - フリマアプリ編』

この資料が有用になるシーンは限られるのですが、学びが大変多いので振りかえることができるようにメモとして。

資料スライド

みどころ

先行者メリットを持っていたはずのサービスが何故抜かれてしまったのか?というのをまとめてある資料。サービスをいいところまで持っていくまでの話は目にすることが多いが、軌道にのったあとにどういうアクセルの踏み方をしなければならないかという観点ではあまり語られることがないので大変貴重な回顧録となっている。

個人的にはカジュアルゲーム開発者の方々にも一定学びがあるのではないか、という資料でした。

関連リンク

2023年11月時点でよく聞くPodcastをまとめる

Podcastのトレンドよく変わるので、現時点でランニングしながら聴くPodcastを書き留めておく

fukabori.fm

fukabori.fm

iwashiさんが主催するPodcast、扱うネタは技術的なものから組織の話などバラエティ豊か。

最近100回を迎えて、とにかく主催のiwashiさんの興味のある内容に関してゲストを招いてトークをするので、内容も濃く、また初手で聞く人にやさしいので、広く聞きたい人にはおすすめのPodcast

印象に残った回

mozaic.fm

mozaic.fm

Jxckさんがメイン進行をするPodcastでWebの技術部分やエコシステムの話が中心です。

Web系の動向(ブラウザの動向や、フロントエンドの動向など)を話す番組で、大きく月イチで紹介する「Monthry回」と、特定のトピックに関して有識者トークする「通常回」、1年間の総括をする「Yearly」がある。MonthryやYearlyはその月に起きたイベントをざっくり抑えるのによく、通常回は特定のトピックに関して話をするので知識が薄い状態でも掘り下げて話が進むのでとてもタメになります。

印象に残った回

セキュリティのアレ

podcast - #セキュリティのアレ - ゆるーいセキュリティのポッドキャストですよ。

辻さん、根岸さん、kangoさんの3人によるセキュリティ専門家がセキュリティに関して話をするPodcastです。

2023年に入ってから聞き始めたのですが、3人の語りが軽快でとても聞きやすいPodcastです。他の技術Podcastにはないラジオ感があります。

ALL STAR SAAS PODCAST

ALL STAR SAAS PODCAST

ALL STAR SAAS FUNDのパートナーである楠田さんと神前さんが様々なSaaS企業の方々と話をするPodcast

ビジネス的な話題ももちろん、チームビルディング的なトピックを扱うことも多く、マネジメントを業務としてこなす人には学びが多い回もあるのでよく聞いています。

EM.FM

EM.FM

ひろきさん、ゆのんさん、さとうさんの3人の、エンジニアリングマネージャーによるエンジニアリングマネージャーのためのPodcast

EMのためのラジオと謳っているが、エンジニアを取りまとめるひとや現在のエンジニアを取り巻く話題なども取り扱っているのでEMじゃなくても楽しめるPodcast

Backyard Hatena

Backyard Hatena • Spotify for Podcastersのポッドキャスト

株式会社はてなのCTOのmotemenさんが、はてな社のメンバーをゲストに招き対話形式で繰り広げられるPodcast

メンバーの方々個々人の考えや、はてな社がどういうサービス開発を知れます。

Slack用の「済」emojiアイコンを作った

印鑑スタンプ風にdone!って押すアイコンが欲しくて作りました

実際のemoji用アイコン

大きいバージョンはこちら

This work is marked with CC0 1.0

参考サイト

After Kaigi on Rails LT Nightで『無用な認知負荷を減らしてお手入れしやすいコードを書こう』という内容で登壇してきました

After Kaigi on Rails LT NightでLTしたのでその登壇後記です。

発表したスライド

speakerdeck.com

伝えたかったこと

  • 認知負荷という言葉が独り歩きしがちなので、基礎的な概念を抑えてほしかった
  • その上で自分たちの身の回りの「課題外在性負荷」を探してもらえればと思った

補遺編

今回のテーマ選定について

Kaigi on Railsのプロポーザルも落ちてしまい、イベントが迫るうちに自分も喋りたくなり、関連イベントのLT枠がまだ空いていたので応募しました。

最初は去年の発表で語りそびれた部分の補遺編でもやろうかなぁと思ったんですが、色々なところでハードルをあげられてしまったので、急遽新作を作ることにしました。

何を話すか…と考えたときに、書籍プログラマー脳を読んだときに衝撃を受けたのでどこかで自分の脳内整理も含めて取り組みたいなと思っていたので、登壇ドリブンでまとめよう!と思い認知負荷理論を題材にした話を急遽まとめることにしました。

資料を作成するに当たり参考になった資料

きっかけはプログラマー脳だったのですが、一番参考になったのは下記のZennです

認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介

認知負荷理論の基礎的なことを記載してあったので大変わかりやすく、調べる時間がショートカットできたので大変助かりました。(デジャブを感じてた方は正解です)

また、導入の部分に関してはt_wadaさんがfukabori.fmで話されていた内容を間借りさせていただきました。

登壇後記

  • 認知負荷理論を知ってる人も知らない人も一定反応がもらえたのでよかったです。
  • 「新人教育に使えるのでは?」という話をもらったのですが、もともとは教育向けの理論なのでもしそちらに活用したい場合は関連論文を読むと良さそうです。
  • 「課題外在性負荷なのか、単純に学習がおっついてないから処理できていないのかわからなくないですか」という話もありました。こちらも関連のお話を読んでいくと語られたりしているので、またどこかで喋ってもいいかなと思いました。
  • 前作のテストの話と、認知負荷理論の話は実は絡めやすい部分も多く、混ぜた話をどこかでしたいなぁと思いました。

今回この登壇に役立った書籍