コード日進月歩

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

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で『無用な認知負荷を減らしてお手入れしやすいコードを書こう』という内容で登壇してきました

登壇 Rails

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

発表したスライド

speakerdeck.com

伝えたかったこと

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

補遺編

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

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

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

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

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

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

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

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

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

登壇後記

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

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

プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ

プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ

Amazon

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

Amazon

『Kaigi on Rails 2023』の二日目に行ってきたよメモ

行ってきたメモ Rails

『Kaigi on Rails 2023』の2日目に参加してきたので見たセッションメモ ちなみに1日目はこちら

各発表の感想

※資料スライドは見つけたら貼ります。

Railsの型ファイル自動生成における課題と解決

speakerdeck.com

感想

  • Railsアプリケーションに段階的にRBSを導入していくアプローチに関しての紹介。 怪しいセミナーではない。
  • orthoses (読み：オーサーシーズ) とその関連gemで解決していくアプローチ
  • もともとRailsの備えているものに関しては自動でカバーできる範囲が多いが、自前のアプリケーションに関してのアプローチも考えらえており、RBSの基礎を叩き込んだあとにいざ導入！というときに見直したい資料でした。
  • rubocop-yard はチーム内のYARD矯正ギブスとしても使えそうだし、明日から導入したいgemだった。

関連リンク

Fat Modelを解消するためのCQRSアーキテクチャ

感想

  • ReadとWriteの分離をするCQRSの考え方ををRailsアプリケーションに持ち込んだ話。
    • CQRSというとイベントソーシングも合わせて語られることが多いが今回はイベントソーシングではない事例だった
  • Commandが出来上がってもCommandを叩くControllerがFatになりがちだが、そこをUseCase層を持ち込むことで、純粋なRDBの処理部分を逃がせたのはなるほどなと思った。
  • APIなら割とやりやすい方向性だが、通常のWebページのactionの場合はどうするのかなというのは気になった。
  • ルールに沿わないコードを検知し辛いので、チームへの浸透とワンセットの考え方と感じたが、その点どうやて活動しているのかも合わせて気になった

関連リンク

32個のPRでリリースした依存度の高いコアなモデルの安全な弄り方

感想

  • 無停止でいかにカラムの変更を行うかの話
  • かなり雰囲気でMySQLを使っているフシがあるので、こうやって事前調査を入念にやるということは大事だなと改めて感じる。事前にオンラインDDLになるかどうかのチェックができるノウハウは良い知見だった。
  • RailsReleaseにおける db:migrate と Railsソースの更新タイミングの問題はどこでもつきまとう問題だなと聞いていた。
  • 今回の事例はinsertオンリーのテーブルの事例だったので愚直にやれば課題感がなかったけれど、updateを伴うカラムのほうはもっと大変だろうなと感じる

関連リンク

テーブル分割で実現するdeviseの責務の分離と柔軟な削除機構

speakerdeck.com

感想

  • Deviceをうまく扱うためのテーブルの分割方法のお話
  • 削除の考えかたに関してもActiveなものを表現するテーブルとして作るという考え方
  • Userというドメインをちゃんと分解して取り扱わないとしくじるので、そーだいさんの事例を思い出すなどしました。

関連リンク

管理機能アーキテクチャパターンの考察と実践

感想

  • 管理機能をどう構築すべきかという引いた目線での話
  • 過去経験上刺さる部分が多く、かなり共感できる部分も多かったので、何かアーキテクチャの検討に入ったときにはスッと出したくなる資料
  • エンドユーザ向けが現状どうあるかと対比して選ぶパターンを紹介していたのもよかったです。
  • この資料のすごいところは発表内容もさることながら、参考資料のデータが非常にバラエティに富んでいたのでよかったです

関連リンク

自分の道具を自作してつくる喜びを体感しよう、Railsで。 〜4年続いたPodcastを実例に〜

感想

  • Podcastを通じて自分の道具になるツールをつくっていく話
  • ステップアップの過程がよかったのと、単発サービスと継続できるものの差が勝たれていてよかった
  • サイドプロジェクトを使って好循環を生み出すのは本当にいいなと思った

関連リンク

ペアプロしようぜ 〜3人で登壇!? 楽しくて速いペアプロ/モブプロ開発〜

感想

  • ソロプロにおける課題感と、それをペアプロで解消する方法やペアプロ時の問題に対しての解決アプローチの話。
  • ペアプロのやり方はよく聞くが、実践した場合の難しさの知見があったのがよかった
    • ドライバーをタイピストと言い換えるのは単純ながら効果はありそうだった
  • ライブコーディングを見ながら、良いなと思ったポイントは以下
    • issue着手前にissue内容の点検をタイピストが司会進行となって、疑問点がないかを確認する
    • issueからすぐにコードの変更に取り掛かるのではなく、タスクリスト的に作業順番を明文化して実施する
    • ナビゲーターが沈黙モードに入ったらタイピストが声掛けをする
    • 全体的に相槌と確認をこまめに挟みながら進める
  • 前半のissueの確認に関してはプロダクトバックログからスプリントバックログに起こす過程に似ているなと思いながら見ていました。

関連リンク

ActiveSupport::CurrentAttributes: すっごく便利なのに嫌われ者？！

スライドは見つけたら貼ります

感想

  • ActiveSupport::CurrentAttributesの紹介と使い方の話
  • なんで必要となったんだっけ？という背景も含めて説明があったのでタメになった。
  • 要するにグローバル変数なので、グローバル変数に関する所々の問題がはらんでいるし、Rails特有の問題もあるので使うときはその点気にしながら利用しましょう。

関連リンク

コードカバレッジ計測ツールを導入したらテストを書くのが楽しくなった話

感想

  • コードカバレッジの話とそれをどうやって改善に組み込んだかという話
  • 条件網羅について語られることがないので、ここで語られたのはよかった
  • 前回の登壇で実はこのあたりまで喋りたかったので、こういう話どっかでできればなーとは思っています

関連リンク

A Decade of Rails Bug Fixes

感想

  • ふたつのBugfixのエピソードからどうやってデバッグをしていったという話。
  • ひとつめはRailsのカウンターキャッシュの話
    • 社内で問題になっているところを起点に、調査を進めて、手元で再現するものを見つけ出してPRを出していったエピソード
    • ここではバグの修正PRだけではなく、バグの対しての再現方法やそのバグがなぜ困るかのコンテキストを含めてちゃんと伝えることの大切さに触れられるエピソードだった。
  • もうひとつはMastodonの修正の話
    • Mastodonのバグに関しての話を目にし、最初は安易なバグだろうと思って取り掛かっていったら根が深いことだったという話
    • こちらは自分自身がバグで困っている当事者ではないケースだったので、バグ報告には意義があるということや仮説が立てにくいなかどうやってバグ修正を進めていくかということに触れたエピソードだった。
  • どちらの話もRubyやRailsというOSSを使っている際に少しの報告が誰かの一助になるんだろうなということを考えさせられるエピソードだった

関連リンク

2日間を通しての感想

  • 会場としては大きなホールと、小さな会議室、加えて十分な量の休憩スペースなどもあり過ごしやすい空間になっていてよかったです。
  • Railsを使った仕事の話、Railsにまつわる技術の話、Railsを使ってよかったことの話、さまざまなRailsの話があり去年以上にバラエティに富んでいたと思いました。
  • 複数トラックあったので聞きたかったなというトラックもあったんですが、アーカイブを即日見れるのはすごい助かりました。
  • 懇親会でも色々話させて頂いて楽しかったです、来年はスピーカーとして出れるように精進します。。
    • ちなみにどの日本酒もめっちゃ美味しかったです。 （下記は別の方のツイート）

『Kaigi on Rails 2023』の一日目に行ってきたよメモ

Rails 行ってきたメモ

『Kaigi on Rails 2023』の1日目に参加してきたので発表見たよメモ

見た各発表の感想

※資料スライドは見つけたら貼ります。

スケーラブルActive Jobs with Sidekiq Enterprise

感想

  • スケールインをするときに非同期処理をうまく扱うためへのAWSの話とsidekiqの話
  • Sidekiq Enterprise、名前は聞いたことあるがどういう利点があるかを知らなかったので実例を交えて聞けてよかった

関連リンク

基調講演

動画はこちら

感想

  • zzakさんの「Railsへ貢献してくれる人のためにやっている取り組み」を紹介
    • Rails Guide照らし合わせたAPIドキュメントとの差異の修正の話
    • This Week in Railsの更新についての話
    • RailsそのもののCIを整備している話
  • Railsへの貢献、というと実コードへの貢献を考えがちだが、こういうRailsを使いやすくする・修正しやすくするという取り組みでも貢献できるのだなと改めて感じた
  • 自分自身OSS活動などはできていないタイプの人間なので、こういう土台を支える作業をやるのもアリなのかなと思いました。

関連リンク

Rails アプリの 5,000 件の N+1 問題と戦っている話

感想

  • N+1をうまく倒すにはという話
  • トーク内容がバラエティに富んでいました。
    • N+1がおきる原理とそもそもの対応法
    • Bulletの警告を基軸にincludesに置き換えていくgem
    • includesとeager_load/preloadの対応の切り分け方と考え方
    • 現実ではどうやって立ち向かっていくか
  • gemを作った話のすごさもさることながら、N+1問題の知識のおさらいとして共有したくなるスライドでした。

関連リンク

生きた Rails アプリケーションへの delegated types の導入

handon.club

感想

  • あとから追加された仕様に引きづられてテーブル構成をかえないといけなくなったときにDelegated Typesを採用した話
  • ユースケースがわかりやすく、また移行プロセスも地に足ついた話でなるほどーと思いながら聞いていた。
  • ポリモーフィック関連に関しては取り扱ったことがあったがDelegetedTypesは知らなかったので、もしマッチするときはスッと使いたいなと思いました。

関連リンク

Exceptional Rails

感想

  • 例外をどう取り扱うべきかという話。
  • 普段ちゃんと例外を取り扱うべきか、というところはなんとなくでやってしまっている部分も多いのでためになった
  • Rails.error.handle の存在、Rails7.1から ActionDispatch::ExceptionWrapper.rescue_responses の挙動が変更されたことなどは知らなかったので勉強になった

関連リンク

Update Billion Records

感想

  • たくさんのデータを移行するためのプロセスに関しての事例
  • ユースケースに左右されるので難しいが、適切なデータ分割を見極めるのはドメイン理解がないと難しそうだなと感じました
  • 前例踏襲だとしんどい部分をsidekiqなどを使って分解した苦労が垣間見えました

関連リンク

Simplicity on Rails - RDB, REST and Ruby

感想

  • RDB、REST、Rubyのパートに分けていい感じにシンプルなものをつくるという話
  • RESTとCRUDが明確に紐づくわけではない、というを明言しながら話している内容はあまりないので他の人に共有する面でもいい話だった
  • モノとコトに分ける話はSoRとSoEの話につながる部分があるのかなと思いながら聞いてました。

関連リンク

技術的負債の借り換え on Ruby and Rails update

speakerdeck.com

感想

  • 増え続ける技術負債を完全に解消するのではなく、より軽い負債に乗り換えていくためにはどうするかという話
  • 選択肢としてwrapperをつくるというのが経験がなく、実例もみたことがなかったのでいままで脳内から排除していたが選択肢として持つのはよさそうと感じた

関連リンク

seeds.rbを書かずに開発環境データを整備する

感想

  • seed.rbを愚直にかかないでカバーする方法の実践例
  • 本番データをdumpして加工してやる、よりも健全な方法だった。
  • 一回目に実行するときにリトライ処理をして正常な順番を見出すというアプローチはなるほど、という感じだった

関連リンク

Active Record クエリクイズ

speakerdeck.com

Kaigi on Rails 2023 で、Active Record Query Quiz というタイトルで発表しました - pockestrap

感想

  • ActiveRecordの exists? や each で回しているときにどっちを実行すると効率よく取れるかをクイズ形式で紹介
  • キャッシュが効く、みたいな話は聞いたことあるがわかりやすい例で紹介されたので理解しやすかった。

関連リンク

一日目を通しての感想

  • 久しぶりの物理開催の大きめカンファレンス参加、色々聞けて良かった
  • 本日は大きいホールであるRoomAにずっといたが、明日はフレキシブルに動こうかなーというところ。
  • 各ブースも回りたかったが、休憩長めのときには混雑するのであまり回れず。明日は回りたい。

rbenvでのバージョンを決めるのは環境変数RBENV_VERSIONが最優先、次点が.ruby-version

Ruby

表題の通り。ドキュメントにわかりやすく記載がないので、各記述をよりあつめた話をドキュメントをもとにまとめる。

調査したバージョン

$ rbenv -v
rbenv 1.2.0-59-g0704e65

rbenvが利用するRubyのバージョンを決めるのはどの情報をもって決めるのか

まずはrbenvのバージョンを決定づける要素は以下

対応方法 説明 設定データのありどころ
rbenv global * rbenvが利用するデフォルトとして設定する (ドキュメント) ~/.rbenv/version (anyenvなど使うと場所が変わります
rbenv local * コマンドを実行したディレクトリ配下を指定舌バージョンで動くようにする(ドキュメント) ./.ruby-version
環境変数 の RBENV_VERSION RBENV_VERSION=* の環境変数として設定する。なおrbenv shell *で設定したときはこの環境変数の機構を利用している。 各種環境変数

優先順位はどれか

順番に関しての記述はrbenvのドキュメントに記載があり

Sets the global version of Ruby to be used in all shells by writing the version name to the ~/.rbenv/version file. This version can be overridden by an application-specific .ruby-version file, or by setting the RBENV_VERSION environment variable.

とあり、globalで設定舌内容は .ruby-version か RBENV_VERSION で上書き可能ということが書かれている。

また、下記のようにも書かれている。

Sets a shell-specific Ruby version by setting the RBENV_VERSION environment variable in your shell. This version overrides application-specific versions and the global version.

「RBENV_VERSION で指定したものはアプリケーション固有のバージョンや、globalのバージョンを上書きする」という旨の記述が書かれている。

これらのことをまとめると

  1. 環境変数RBENV_VERSION
  2. .ruby-version
  3. ~/.rbenv/version（ rbenv global * で設定した値）

という優先順位で動作するということになる。

関連リンク

オンボーディングするとき/されるときにに毎度見返していきたい資料『サポートを明らかにすることを通して、助け合い上手なチームに爆速でなるぞ』

スライド・記事回顧録

資料スライド

speakerdeck.com

みどころ

「助ける」ということと「助けてもらう」ということについてサポートというフレーズでよりよいサポートを行うためにはどうしたらいいかという話の資料。

何事においても助ける/助けてもらうということは行われるが、どういう振る舞いをすると助ける/助けてもらうということがスムーズになるかが説明されている。スライドがかなり細分化されているので読み進めていくと内容を理解できる。

人の「助け方」などに焦点を当てた資料は多いが、「助けてもらう側の心構え」に言及したものはなかなかないので、新しい環境でオンボーディングを受ける場合にも見直すと効果がありそうな資料となっている。

関連リンク