my_back_pages

プログラミング学習の記録 Ruby / Rails / FjordBootCamp

【Ruby Silver】試験をどこから申し込んでいいかわからず迷子になった話

結論

※2024/1/2現在の情報です。

団体ではなく、個人で Ruby Silber / Gold を受験するときの申し込みは、まず下のページに行って、

Ruby技術者認定試験制度|試験一覧・検索|受験者の方|CBT/IBT 世界水準の試験運営|プロメトリック

  • 予約に必要なプロメトリックIDの作成
  • 試験予約(日程・会場の選択、支払い)

をここ↓から行えばOK。

なんでこんな記事を?

↑の個人としての申し込み口の上よりも先に、いかにも申し込みチケットが買えそうな「支払方法 -> 受験チケットの購入はこちら」というボタン↓があり、迷子になってしまったから。

こちらは団体で申し込む際の窓口みたいです。よく読めばしっかりと説明が書いているので、迷子になった私が100%悪いのですが、「受験するぞ!!」と意気込む私のようなせっかちさんの助けになれればと思い、シェアさせていただきました。

2024/2 に Ruby Silver を受けます。

2024年の最初のチャレンジとして、Ruby Silverの受験をしようと思い、元日に申し込みました。

16,500円という大金を先に支払ったので、もうやるしかありません。毎日の学習の初めに、1hほど受験対策をしていこうと思っています。

勉強内容や結果等、またシェアできればと思っています。

2023年のふりかえり

2023年のプログラミング学習をふりかえる記事です。

学習状況

6月にフィヨルドブートキャンプ(以下FBC)に入会し、約200日が経ちました。

2023/12/31時点での学習状況

FBCに記録した学習時間を表す草の記録

学習時間は1100時間くらいで、草の濃淡こそありますが、入会後は1日も休まずに学習を継続することができました。

学習したこと

これらについての基礎を学びました。

現在は、これらの知識を活かして、FBC内で実際に使用されているEラーニングWebアプリ「bootcamp」の開発スクラムに参加する「チーム開発」というプラクティスに取り組んでいます。

やってみて思うこと

私は現在キャリアブレイク中です。

その期間を使って新しいキャリアに挑戦したいと考えたときに、いくつか思い浮かんだやりたいことのひとつだったのがプログラミングでした。

FBCは卒業する難易度が高いスクールで、ここまで来るのにもくじけそうになったことも何度かあります。ですが、同じように未経験から学習している生徒さんとの交流やメンターさんの支えのおかげで、ここまではなんとか挫折せずに走ることができたと思っています。関わってくださっている皆様に、本当に感謝です。

感慨深いプラクティス

FBCではJavaScriptの最後のプラクティスとして、「自作npm」というオリジナルのnpmを制作するプラクティスがあります。

プログラミングに関わらず、どちらかというと問題点を無くしたり、すでにあるものを改善するようなタスクの方が得意だと思っている自分にとって、ゼロイチ的な思考も求められるこの課題は正直しんどかったです。ここでそこそこ足踏みをすることになりました。

最終的には、「認知の歪み」に気づくための認知行動療法のワークである「トリプルカラム法」をターミナルで実践できるCLIアプリを制作しました。

www.npmjs.com

プログラミング学習で成長を実感できずネガティブな気持ちに襲われたときに、そのネガティブな気持ちの原因となる「認知の歪み」を自覚することで気持ちを少しだけ楽にするためのアプリ、という感じです。

正直、技術的に難しいことは全くしていません。他の生徒さんの素晴らしい自作npmと比較してしまい、凹んでしまう気持ちもあります(こういうときこそトリプルカラム法の出番です!)。

ですが、ありがたいことに数名の生徒さんから「使いました!」的なフィードバックをいただけまして、これが学習のモチベーションをめちゃくちゃ上げてくれました。

ある意味で、このnpmは自分のプログラマとしての処女作だよな、という思いも最近は持てるようになり、自作npmはいろいろな意味で感慨深いプラクティスになりました。

プログラミング自体に対して思うこと

プログラミング自体に対する気持ちですが、「うまくいっているときはめちゃくちゃ楽しく、ハマっているときはとても辛い」という感じです。

自分ができることの範囲が着実に広がっていく感覚(これが自己効力感につながっているのかも?)が面白く、学習すること自体はとても楽しいです(もともと勉強自体は好きというのもあると思いますが)。

一方の「ハマっているときはとても辛い」というのは、プログラマというキャリアを歩む以上はずっと向き合うことになるネガティブ感情だと思っています。このあたりともっと上手に付き合っていくための気づきや経験を、残りのプラクティス(チーム開発・自作サービス)で積んでいけたらなという思いです。

この「何がわからないのかもわからない」というやつ。これはすごくツラいですが、プログラマーにとっては非常によくある状態です。

全然気に病むことはないです。

「ドンマイ、ドンマイ、締まっていこうー!」

ぐらいの感じです。

日々新しい技術を覚える必要があるプログラマーには頻繁におきます。 プログラマーとして働いている人はこの状態のプロです。

むしろ「これが飯の種になる」と考えている節があります。

この状態からの抜け出し方を知っていることが新しいことを自己学習し続けていけるコツなのかもしれません。

わからないときの心持ちについて - komagataのブログ

この感じに近づくための経験をしていきたいです。

おわりに

2024年が私にとってプログラマとしてのキャリアをスタートさせた一年になるよう、とにかく頑張っていきたいと思います。

また、地域Rubyや各種イベントにも積極的に参加していきたいと思っています。

引き続き、どうぞよろしくお願いいたします。

【プログラミング初心者の気持ち】retvalって何?

結論

Return Value(戻り値)の略として使われることがある言葉。

なんでこんな記事を?

この記事を書いている時点からみて、翌週からFBC内で『リーダブルコード』の輪読会を始めることになりました。

www.oreilly.co.jp

下読みをしていたところ、「tmpretvalなどの汎用的な名前を避ける」というパートでこの言葉と出会いました。

経験者から見ると「そんなの略語の意味、知ってて当たり前でしょ」みたいな話なのかもしれませんが、プログラミング初心者の私はこの言葉の意味や、「戻り値」の意味になるとしてもなぜ「retval」に?というところで引っかかってしまい、ここで読む手が止まったので、シェアしようと思った次第です。

GitHubでライブラリのコードをのぞいたときに、略語の部分がスッとわからず理解に時間がかかった、みたいなことはよくある気がします。

ゆえに、この世界でよく使われる略語の知識は初心者にとっても結構重要なのでは?と改めて感じた次第です(かつ、それらを使うときは注意せよ、というのがリーダブルなコードを書くときの心構えということですね)。

scrapbox.io

あと、自分がこんなことにつまづいたのは、もしかしたらRubyからプログラミング学習に入ったからなのかな?(明示的にreturnしなくとも値を返せるから)みたいなことを含め、実は掘り下げ甲斐があるテーマなのかしらと思ったり?いやないか。

アウトプットのハードルをこれくらい下げたいと思いもあり、小さいシェアですが投稿させていただきました。

【Rails】Capybaraのwindows.lastで得られるウィンドウは、必ずしも最後に開いたものにならない可能性がある

Railsシステムテストで、別タブでページを開くボタンを押して、その先で何かを確認するテストを書きたいと思った時のメモです。

もしかしたら、思った挙動にならないかもしれないテスト

click_on '別タブでページを開くボタン'

# 最後に開いたタブの中でテキストをチェックしたい
within_window(windows.last) do
  assert_text 'あるか確認したいテキスト`
end

テスト中のブラウザの動きを見ていると、これでうまく動いているように見えることもあるのですが、それはたまたまかも?という感じらしいです。

Get all opened windows. The order of windows in returned array is not defined. The driver may sort windows by their creation time but it's not required.

www.rubydoc.info

返り値のオブジェクト(開いたページ)の配列の順が、開いた順になることを完全に保証するものではないらしい。

ウィンドウを指定してそのページの中で何かを確認するコード

window = Capybara.window_opened_by do
  click_on '別タブでページを開くボタン'
end

within_window(window) do
  assert_text 'あるか確認したいテキスト`
end

Capybara.window_opened_byメソッドは、ブロック内の行為の処理によって開かれたウィンドウを返してくれるので、その返り値を使えば、確実に自分のテストしたいウィンドウにいける。

www.rubydoc.info

Get the window that has been opened by the passed block. It will wait for it to be opened (in the same way as other Capybara methods wait). It's better to use this method than windows.last as order of windows isn't defined in some drivers.

公式リファレンスにも、windows.lastよりこちらの方がいいよ、という添え書きがありますね。

switch_to_window(window)とか、開いたタブのページに行く方法はいろいろありますが、とにかく確実にテストしたいタブがある場合はまずCapybara.window_opened_byで指定しておこう、というイメージで理解しました。

フィヨルドブートキャンプに入る前に予習した内容 / 使ったサービス / それらを振り返って思うこと

はじめに

この記事は フィヨルドブートキャンプ Advent Calendar 2023 Part1 の記事です(Part2もあります)。

フィヨルドブートキャンプ Part 1 Advent Calendar 2023 - Adventar

フィヨルドブートキャンプ Part 2 Advent Calendar 2023 - Adventar

Part1の前日はmotohiro-mmさんの 2度の挫折を乗り越えて学習時間1000時間超えた話 [フィヨルドブートキャンプ] - もとひろ blog でした。

Part2の前日はYumiyaさんの Railsのフォームヘルパーを深掘りしたら得るものが多かった - yumiya's blog でした。

サマリ

  • 【重要】FBCに入るにあたり予習はマストでは全くないけれど、不安な人/予習したい人もいると思うので、私の予習体験をシェアするのがこの記事の目的
  • FBCに入る前の予習として、使ってよかったと思うサービス -> Progate、ドットインストール、Udemy(個人の感想です)
  • HTML / CSS / Ruby は予習できてよかったかもしれない(個人の感想です)
  • Railsに触れるのはフィヨルドのプラクティスに到達してからでもよかったかもしれない(個人の感想です)
  • Railsよりはターミナルの操作方法や、Gitの基本の基本とかがわかっているとよかったかもしれない(個人の感想です)

私について

私は現在フィヨルドブートキャンプ(以下FBC)でプログラミングを学習しています。

今年の6月に入会し、本記事執筆の数日前にチーム開発(他の生徒さんやメンターさんで構成される開発チームに入って、FBCの中で実際に使われている学習アプリを開発する)のプラクティスに突入しました。

約半年で、FBCで記録している学習時間は980時間

この記事について / 入会前の予習はマストではない

(本文をつらつらと書いてしまったら「誰のための何の記事なのか」があやふやになってしまったので、このセクションはその言い訳です🙇‍♂️)

私はFBCに入る前に、下で述べるサービスでプログラミング学習の予習(?)をやっていました。

FBCというスクールの評判の良さを聞いて入ることは決めたものの、

  • カリキュラムがなんだかすごいらしい
  • 中には途中で退会する生徒さんもいらっしゃるらしい

という評判も結構目にしたからです。

ここで、FBCの卒業生の方のブログ記事で、カリキュラムの特性と予習について触れられた文章を引用させてください(切り抜きで印象が変わってしまうことを避けたいため、長いですが1セクションをそのまま引用します)。

フィヨルドブートキャンプの悪いところ

正直ほとんどないのですが、公平性のために悪いところもあげておきます。

「基礎を手取り足取り教えてもらえない」、というところは人によっては辛いかもです。

たぶんこれは「現場力が鍛えられる」の裏返しです。現場力を鍛えるためには、未知の問題に出会った時に自分で解決する能力を鍛えていく必要があります。そのためフィヨルドブートキャンプの課題は、自分で調査して考えることを要求する、答えのない課題が多いです。なのでWebを調べたり、他の生徒さんの日報を調べたりしながら、自分の頭で考えて解決していきます。この調査・思考自体が大事な訓練なのですが、未経験者の場合は手取り足取り教えて欲しいという方もいると思います。そういう方にはあんまり向いていないかもーと思います。

かなりハードなカリキュラムになりますし、実際フィヨルドブートキャンプを卒業できる人は少ないです。(だからこそ卒業生は皆さん優秀だし、有名な会社さんに就職できるのですが。)

個人的には基礎は独学で済ませて、プログラミングスクールでは現場力を鍛えるべきだと思うので、このやり方は正しいと思います。プログラマとしての適正を早めに判断できるという利点もあります。とはいえ早めに脱落してしまう人が結構多いので、未経験者にはもうちょっとサポートがあってもいいのかなーとも思います。

これは悪いところというより思想の問題かもしれないです。

プログラミング未経験でフィヨルドブートキャンプに参加される方は、Progateやドットインストール等で先に基礎を勉強しておくか、並行して勉強していくのをおすすめします。ただカリキュラム的には未経験でも進められるように必要なプラクティスを網羅しているので、やる気がある方ならフィヨルドブートキャンプだけでも問題ないです。

プログラミングスクールの理想と現実。あとフィヨルドブートキャンプについて - 猫Rails

こちらの卒業生の方がおっしゃるように、FBCのカリキュラムは(予習含め)プログラミング自体が完全にはじめてでも大丈夫なように作られていると感じます。どんな質問をしても、プロのメンターさん達が100%返事をしてくれます(ただし答えそのものを教えてもらえるとは限らない)。

※個人的には、FBCが「基礎を手取り足取り教えてもらえない」場所だと思うかどうかは、人それぞれなのではないかな〜と思うことを追記しておきます。ただ、「手取り足取り」でイメージすることが、「自分がわからなくなったら、教える側が『率先して(手を取り足を取り)』答えを教えてくれたりする」ということであれば、FBCは確かに手取り足取り教えてもらえない場所と言えると思います。プログラミングの世界では現場力が求められる、調査・思考の力が大事など、この引用箇所の主意については120%同意ではあるのですが、念のため。

FBCのページで公開されているカリキュラムや評判を読んで、「うお〜なんか高そうな壁っぽいけどやってやるぜ〜」と燃える人や「サポートが充実してそうだし大丈夫かな」と思う人もいれば、「興味はあるし評判はいいけれど、ついていけるかな〜」と不安に思う人もいると思います。

私は後者だったので、上のブログを入会前に実際に読んだあと、(自分なりに思う)基礎だけ予習を済ませてから入会することを決めました。

この記事は、そんな私が実際に使ったサービスや学習したこと、逆に「これは予習しなくても良かったかも」と思うことなどのシェアです。

私のようなタイプで、FBCへの入会を悩んでいる人や、どこまで何を予習をするか悩んでいる人の参考になればいいかな〜というイメージです。

※私はFBCが好きなのでFBC推しですが、他のスクール/サービス/その他あらゆるプログラミング学習の前段階にやることの参考に(万が一にでも)なればこれ幸い、という気持ちです。

※以下、具体的な経験をシェアするために、特定のサービスや動画コースのリンクを張ってはいますが、アフィリエイトとかでは全く×100ありません(貼っているリンクも普通のリンクです)。

よかったサービス

Progate / ドットインストール

プログラミング入門の定番サービスですね。 「プログラミングを勉強しようかな」と思ったあとに、まずProgateとドットインストールでHTML / CSS のコースを一周して、FBCへの入会を決めたあとにProgateのRubyのコースを一周しました。

HTML / CSS を両方のサービスでやった理由は、単純にそのときは学習のロードマップがわからず、でも立ち止まるのが怖いのでとにかく有名なサービスをやろうと思っただけで、今考えたらどちらか一つだけでも全然良かったと思います。

FBCでは最初にHTML / CSSをやるので、この予習によって、そこで思いっきりつまづいたり、初めてのことばかりでパニックなる、的なことが防がれた、みたいなことが私にはあったかもしれません。

Rubyの予習は純粋にとても面白かった記憶があります。後述のとおり、その前にJavaScriptを予習したのですがちんぷんかんぷんだったのに対し、Ruby(のすごく基礎的なところ)はスッと入ってきた印象でした。

あと、Rubyのクラスなどの難しいテーマについては予習段階では全然理解できていませんでした。Progateのスライドを何度読んでもちんぷんかんぷんで目が滑りまくる、みたいな感じ。おなじくHTML / CSSFBCに入会したころには細かいことは忘れていました。

これは今になって思うことですが、本格的に学ぶ前の予習ということであれば、言語に対する深い知識とかを得ようとする必要なんて全くないと思うので、まずはプログラミングの流れみたいなものに触れられればそれでいいのかな〜と思っています(なので私がクラスがちんぷんかんぷんなまま次のステップに突入したことは悪くなかったはず)。

込み入った内容に出会ったら、なんとなく頭の中にインデックスして次に行けばいいと思います。例えば「なんかHTMLの要素の並びには親と子の関係みたいなものがあって、親のパワーが子に影響しちゃうんだね〜」くらいのことを、ざっくり頭の中にふせんで貼っておいて次に行く、みたいなイメージです。それはあとでもう一度出会った時に必ず役に立ちます。

qiita.com

また、Progateを1週したと書きましたが、この時点でプログラミングがなんだか面白い!と思ったら、そのときにやっている教材が途中でもFBCに入る or その他のサービスを使って本格的に学習を始める、とかで全然いいと思います(もちろんProgateの内容を極めてもいいし、そのままずっと独学でもいい)。

あと、プログラミングは環境構築(自分のPCでプログラミングができる準備を整えること)でつまづくことがあるので、それを考えなくてもいいようにしてくれているProgateは、学習のとっかかりにはとても良いサービスだな〜と今でも思っています。

Udemy

動画でスキルを学べるサービスです。FBCを知る前に、評判の良かったこのコースを途中までやっていました。

www.udemy.com

(奇しくもこのコースの名前もBootcamp……。)

FBCRuby / Rails を主にしたカリキュラムですが、こちらは JavaScript / Express を主にしたカリキュラムです。

これを独学でやっていて、JavaScriptのDOMやクラス・非同期処理、Expressのあたりで「なんだこれ、なにもかもがぜんぜんわからん」となっていたころにFBCの存在を知り、上述のようにRubyをふわっと予習してFBCに入会しました。

上のコースの内容は骨太なので、FBCに入る前に知っておくこととして全然マストとかではないと思うんですが、動画で講師が説明するのを聞きながら学べるという点で、Udemyはとても良いサービスだと思っています。

FBCに入ってからも、Reactの学習でUdemyの講座を購入して参考にしたりしていました。定価で買うと高いので、月に一回くらいあるセールを狙って買っています(90%オフとかになる)。

Railsの予習について

FBCRailsという言語?(←言語ではない)を勉強するみたいだから予習しとこうかな」という感じで、ProgateでRailsのコースも一応やってみたのですが、これは(FBCの前の予習という観点では)マストではなかったかなと思っています。

  • プログラミングの基礎があやふやな状態でRailsを触っても、何が起きているのか / 自分が何をしているのかさっぱりわからない
  • チュートリアル通りにやれば動くは動いてProgateが「修了!」と言ってはくれるけれど、↑の状態なので何かが身についた感覚がなく、モヤモヤする
  • FBCではRailsに到達するまでに結構な量のカリキュラムがあり、Railsを触るころには予習したことを忘れている

もちろん、入会前でもRailsに興味があれば触れてみるのは全然いいと思います。ただ、「挫折しないために入会前にある程度Railsを理解するぞ!」的なテンションでプログラミング初心者がRailsに挑むと、余計つらくなる可能性もあるかな〜と思ったので(よくない完璧主義の傾向がある私がそれでした)、一応シェアできればな〜と思った次第です。

ちなみに、Raisを触り始めて「何が起きているのか / 自分が何をしているのかさっぱりわからない」となることを防ぐために、FBCではSinatraというフレームワークを使ってWebアプリを作るプラクティスがRailsの前に置かれています。大変なプラクティスでしたが、終わったあとにRailsを触った後は感動しましたし、あとからこのプラクティスの並びの意味に気づいた時にさらに感動しました。

ターミナルの操作 / Git について

FBCではRubyのプラクティスに入る前に、ターミナル(映画のハッカーがカタカタやっている黒い画面)やGit(バージョン管理ツール)の使い方を学びます。

今考えれば、Railsの予習に割く時間と元気があれば、個人的にはこれらのことについてもサラッと触れておくのもよかったんじゃないかな〜と想像したりします(サラッとがポイント、FBCに入ったらイヤでも深くやるので、なんとなく雰囲気を知る感じで)。

どちらもProgateに対象のコースがあるので、それらを使ってもいいかもしれません。

おわりに

FBCの生徒のみなさまには、もしかしたらあまり興味がわかない記事になったかもしれず、申しわけないと思っています……🙇‍♂️ あと、外部の人には私がFBCの回しものみたいに見えるかもですが、そんなこともありません。純粋に、自分のプログラミング学習の始めの頃の体験のシェアとして、万が一にでも誰かのお役に立てたらいいな〜くらいのテンションです。

それはそれとして、FBCは素敵なコミュニティだなといつも思っています。 いつも真剣に向き合ってくれるメンターさん、日報のコメント / Discordやイベントなどで優しく接してくれる生徒のみなさまに感謝です。

これからが大変なパート(チーム開発・自作サービス)に突入しますが、挫折せずに頑張って卒業できたらな〜と思います。

【Rails】Capybaraでvisitしたページのオブジェクトと、pageメソッドについて【Capybara】

  test "ほげほげさんの記事に行ける" do
    article = articles(:article1)
    visit_with_auth "/articles/#{article.id}", 'hogehoge_san'
    assert_equal "#{article.title} | みんなの日記サイト", title
  end

この最後のtitleの意味がわからなくて時間を溶かしたんですが、Capybaraの提供するメソッドだった模様。

Class: Capybara::Node::Document — Documentation for teamcapybara/capybara (master)rubydoc.info

いきなりtitleと書くだけで使えるのがよくわからなかったんですが、こういう理由だったらしいです。

visitでページアクセスすると、page変数に格納されるCapybara::Sessionオブジェクトが更新される。 後述のAction, Matcher, Finderなどは 暗黙的に このページオブジェクトに対して操作を実行する。

(中略)

Capybaraは要素を検索し、操作したり内容を検証したりできる。 各メソッドは要素オブジェクト(Capybara::Node)に対するインスタンスメソッドとして動作するが、 省略した場合(Capybaraのクラスメソッドとして記述した場合)はvisitで取得したページpageに対して適用される。

qiita.com

自分でもCapybaraのソースコードを眺めてみました。

require 'capybara'

module Capybara
  module DSL

# 中略

    ##
    #
    # Shortcut to accessing the current session.
    #
    #     class MyClass
    #       include Capybara::DSL
    #
    #       def has_header?
    #         page.has_css?('h1')
    #       end
    #     end
    #
    # @return [Capybara::Session] The current session object
    #
    def page
      Capybara.current_session
    end

https://github.com/teamcapybara/capybara/blob/6267ff65a294a7dcbe9d7281c30cc2d91b08b093/lib/capybara/dsl.rb#L45

このpageメソッドは、current_sessionメソッドをたどっていった先にある、モジュールのインスタンス変数の中のオブジェクトを参照しているみたいでした(めちゃくちゃ詳しくは読めてません)。

assert_equaltitleは、このオブジェクトに対して働いてたんですね。全然わかっていなかった……というメモです。

【Rails】(メモ)React + Rails(API)でよく考えずに skip_before_action :verify_authenticity_token するのは危なそう

React + Rails(API)構成でのアプリ開発について学習している中で、下のようなコードと出会いました。

# app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  include DeviseTokenAuth::Concerns::SetUserByToken

  skip_before_action :verify_authenticity_token
end

RailsCSRF攻撃対策

  • Railsは、CSRF攻撃対策のためのトークンを生成し、セッションで_csrf_tokenというキーでユーザーに保持させる。
  • デフォルトでは、rails newで自動生成されるビューであるapplication.html.erb上のメタタグ<%= csrf_meta_tags %>によって、_csrf_tokenの中のトークンは生成される。
  • form_withによる値の送信の際に、上のトークンを暗号化したauthenticity_tokenが生成され、他の値と一緒に送られる。
  • verify_authenticity_tokenは、上の2つが一致しているかを検証するメソッド。違っていたら不正なリクエストと判断される。

ビューを用いたスタンダードなRailsアプリ開発では、これらの仕組みのおかげで特に意識することなくCSRF攻撃対策ができている模様です。

そのために、verify_authenticity_tokenというメソッドはとても大事だというわけですね。 (実際は、これのラッパーのprotect_from_forgeryが使われているみたい。)

railsguides.jp

一方、ビューを使わないAPIモードの場合、

そもそも検証すべきトークンが生成されない → POSTリクエストが送られてもverify_authenticity_tokenによる検証が失敗する → Can't verify CSRF token authenticityというエラーが起きる

という現象が起きてしまうようです。

それを回避するために、トークン検証自体をやらないようにしよう!というのが、冒頭のskip_before_action :verify_authenticity_tokenの意味だったみたいです。

(デモ用のコードだからということだとは思いますが、単純なエラー解消手段としてこれを紹介する記事もあったりするみたいなので、セキュリティ関係のことは念を入れて気をつけておかねばと思った次第です。)

どうすべきなのか

トークンを自動生成するビューがないのであれば、「トークンを生成してクライアント側に渡す -> 受け取ったクライアントは以後そのトークンをリクエストにのっける」という仕組みを自前で作る必要があるということみたいです。

実際に必要になったら、下の記事などをもとに対応したいと思っていますが、現時点での上記の仕組みと注意点の備忘録的な記事でした。

参考にさせていただきました🙏

RailsにおけるCSRF対策をできるだけ分かりやすく説明する

【Rails API】CSRF 対策をあきらめないでちゃんとやる | みどりみちのブログ

React + Rails(API)で tokenを用いたCSRF対策の基礎(のメモ) - jonamon’s diary