Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Road to RubyKaigi Speaker (case sue445) #rubykaigi2023_after

Road to RubyKaigi Speaker (case sue445) #rubykaigi2023_after

After RubyKaigi 2023〜メドピア、ZOZO、Findy〜( https://zozotech-inc.connpass.com/event/281473/ )の発表資料です。

sue445
PRO

May 18, 2023
Tweet

More Decks by sue445

Other Decks in Technology

Transcript

  1. Road to RubyKaigi
    Speaker (case sue445)
    After RubyKaigi 2023〜メドピア、ZOZO、Findy〜 #rubykaigi2023_after
    pixiv Inc.
    sue445
    2023.5.18

    View Slide

  2. 2
    About sue445
    ● Go Sueyoshi (a.k.a. sue445, sue-san)
    ○ https://twitter.com/sue445
    ○ https://github.com/sue445
    ● Speaker at Day 2
    ○ https://rubykaigi.org/2023/presentatio
    ns/sue445.html#day2
    ○ Fix SQL N+1 queries with RuboCop
    sue445

    View Slide

  3. 3
    My Proposals (3/5 accepted)

    View Slide

  4. ● sue445がRubyKaigiに過去2回登壇するためにやったこと
    ○ Proposalネタ出し
    ○ Proposal執筆
    ○ Proposal採択後
    ○ 発表準備
    ● 対象:来年以降RubyKaigiに登壇したい人
    ● 注意点:N=1なので再現性はない
    4
    今日話すこと

    View Slide

  5. ● 2022年9月:RubyKaigi 2022の頃にはProposalの下書きがだいたいできていた
    ● 2022年12月くらい:翌年1月くらいにCFPがオープンするだろうと思って、igaiga
    さんにレビューしてもらっていつでも出せる状態にした
    ● 2022年12月27日: Ruby 3.2のリリースパーティの会場でCFPがオープンになった
    ので、会場から急いでProposalを出した
    ○ おそらく1get
    5
    今年の流れ (Proposalを出すまで)

    View Slide

  6. ● あまりにやることがなさすぎてCFPの締め切りから当落結果が来るまでの平均日数
    を集計してた
    ● 今までの審査期間は4週間前後だったので今年も2月下旬くらいに結果が来ると予
    想してた。(だいたい合ってた)
    6
    今年の流れ (CFP審査期間中)

    View Slide

  7. 7
    3/1 23:48: Proposal採択通知

    View Slide

  8. 8
    あまりに嬉しくて夜中に会社Slackで@hereつける暴挙

    View Slide

  9. ● 3月下旬:発表資料がだいたいできたので大倉(@okuramasafumi)さんに英文のレ
    ビュー依頼
    ● 4月上旬:最速上映と称して社内勉強会で発表練習
    ● 5月12日:本番
    9
    今年の流れ (Proposal採択後)

    View Slide

  10. ● 日常生活から見つける
    ● Proposalの募集が始まってネタ出ししてもネタが出ない人は1年間考え続けるとい
    いと思う
    ○ 日に数度、CFPから頭が離れる状態(刃牙ネタ)
    ● 日々業務でRubyを書いてたら1〜2ヶ月で1本くらいLTネタはできるはず
    ○ 自分はここ4~5年くらい業務でRubyを書いていないので毎回CFPネタをひね
    り出すのに苦労している
    10
    Proposalネタ出し

    View Slide

  11. ● 人によるけど、僕は「LT換算」か「1つのネタを膨らませる」ことが多い
    11
    Proposalネタ出し

    View Slide

  12. ● 持ち時間が30分としたらLT 5〜6本分を合体させて1本のトークとして話せるか考
    える
    ● 2019年の「Best practices in web API client development」がこのパターン
    ○ https://rubykaigi.org/2019/presentations/sue445.html#apr20
    ● メリット:LT慣れしてる人なら作りやすい
    ● デメリット:複数のLTネタを組み合わせて1本のトークとして成立させるための柱
    を作るのが難しい
    12
    LT換算

    View Slide

  13. ● 今年がこのパターン
    ○ https://rubykaigi.org/2023/presentations/sue445.html#day2
    ● メリット:トークの柱を作りやすい
    ● デメリット:30分話せるレベルのネタを探すのが難しい
    13
    1つのネタを膨らませる

    View Slide

  14. ● ISUCONネタだと他にもいくつもネタはあったがrubocop-isuconが一番話を膨らま
    せやすかった
    ○ 他は小粒(LTどまり)
    ● gem作成時点で、ISUCON予選に落ちてもRubyKaigiのCFPネタとして使えるとい
    う打算はあった
    ○ 自分の中でそれなりに確度も高かった
    14
    今年のProposalの裏話

    View Slide

  15. https://speakerdeck.com/sue445/fix-sql-n-plus-one-queries-with-rubocop?slide=20
    15
    e.g. 小粒なネタ一覧

    View Slide

  16. ● [MUST] RubyKaigiに限ったことではないけど、どんなに素晴らしい内容でもカン
    ファレンスの趣旨や方向性と違う場合は落とされる
    ○ RubyKaigiの場合コードが全て
    ○ 例えば、1年かけてGitLabをGCPに移行した話をRubyKaigiのCFPに出しても
    落とされると思う
    ■ c.f. https://inside.pixiv.blog/2022/11/29/110000
    16
    Proposalを書く時に気をつけたこと

    View Slide

  17. ● 意識したこと
    ○ とにかく技術的に頭がおかしいネタ
    ○ 自分以外に話せないこと(自分が第一人者)
    ○ 業務でRubyを書いてない(=業務からはCFPネタを出せない)ので、大江戸
    RubyKaigi(生活発表会)っぽさを意識した
    17
    Proposalを書く時に気をつけたこと

    View Slide

  18. ● [SHOULD] 他の人の採択されたCFPをたくさん見る
    ○ https://sue445.hatenablog.com/entry/2019/02/10/102907
    ○ 僕は割とonkさんの影響を受けてる
    ● 今年採択されたProposal
    ○ https://inside.pixiv.blog/2023/04/11/140000
    18
    Proposalを書く時に気をつけたこと

    View Slide

  19. ● [SHOULD] 他の人にも見てもらう
    ○ 自分で面白いと思っていても他の人がどう思うかは別問題なので
    ○ 可能なら自分よりも圧倒的につよつよな人に見てもらう
    ○ igaigaさんに見てもらったProposalは今の所採択率100%
    ○ 早くProposalを出せばレビュアーからコメントがくることもあるので早く出
    した方がお得
    ■ 2016(不採択)の時は卜部さんからコメントがきた
    19
    Proposalを書く時に気をつけたこと

    View Slide

  20. ● [MAY] 可能ならProposalを複数出す
    ○ 自信があるProposalが1つしか出せなければその1つに全力投球するでも全然
    ok
    ○ ネタがたくさんあっても実際に通せるレベルのトークにできるかどうかは別
    問題
    20
    Proposalを書く時に気をつけたこと

    View Slide

  21. ● スライドが全部英語だと緊張で頭がとんだ時に終わりなのでスピーカーノートは手
    厚く書いた
    ○ 日本語資料の時はスピーカーノートを書いていない
    ● オンサイト登壇だと後ろの方の席からスライドの下の方が見づらいことがあるた
    め、なるべくスライドの下の方に文字を書かないことを気をつけた
    21
    スライドを書く時に気をつけたこと

    View Slide

  22. ● 発表時間が長いので最初にアウトラインを書くとよい
    ○ c.f. https://inside.pixiv.blog/sue445/6946
    ○ 今年に関しては、以前社内勉強会で発表した資料(後述)がベースになってるの
    でアウトラインは書いてない
    22
    スライドを書く時に気をつけたこと

    View Slide

  23. 23
    参考:社内勉強会の資料

    View Slide

  24. 24
    参考:社内勉強会の資料

    View Slide

  25. ● Proposalを出した時にもさっきの資料のリンクを貼った
    25
    社内勉強会資料に関して補足
    https://inside.pixiv.blog/2023/04/11/140000

    View Slide

  26. ● ひたすら練習する
    ○ 声に出しながら時間を測った
    ○ 練習で微妙に30分超えることが分かってたので本番は冒頭からちょい早口に
    してたら、今度は終盤付近で早く終わりすぎることに気づいてむっちゃ焦っ
    たw
    26
    発表前に気をつけたこと

    View Slide

  27. ● 自分のことを必要以上に卑下しない
    ○ 日本人は自分のことを必要以上に謙虚に言いがち
    ○ 「他の人の発表に行った方がいいですよ」とか「自分の発表はあまり面白く
    ないですよ」って言うと、Proposalを落ちた人や自分のProposalを選んでく
    れたレビュアーや自分の発表を見に来てくれた人たちに失礼なので絶対に言
    わない
    27
    発表前に気をつけたこと

    View Slide

  28. ● 全部
    ● 会話する時に自己紹介しなくていいのがむっ
    ちゃ楽
    ○ Speaker名札を見せるだけでいい
    ● 人見知りなので知らない人に話しかけるのが苦
    手なんだけど、Speakerなら相手から話しかけ
    てくれる
    28
    Speakerの何がいいか?

    View Slide

  29. https://speakerdeck.com/midorikawa/kutukupatudogarubykaigini20ming-yi-shang-noshe-yu
    an-decan-jia-suruwake?slide=25
    29
    登壇してもらうのが一番の技術広報

    View Slide

  30. ● A. すごいなんて言ったらそれ以上成長しなくなるのでダメ
    ● 12年前の角谷さんのおかげで今の自分があると思ってる
    30
    Q. それってsueさんがすごいだけでは?

    View Slide

  31. ● 今回話した内容を見た人から、来年以降のRubyKaigiの新しいSpeakerが出てくれ
    ば幸いです
    ● 僕も来年も登壇するぞ!!!!!!
    31
    最後に

    View Slide