No day younger than today

RubyとかRailsとか蒙古タンメンとか

RubyKaigi 2022 に参加 & 登壇した

9/8 - 10 に三重県津市で開催された RubyKaigi 2022 に現地参加し、登壇してきました。
記憶の新しいうちにいろいろ思ったことや感じたことなど書こうという感じです。

登壇について

なんとありがたいことにプロポーザルを採択していただき、登壇させてもらいました。
プロポーザルの概要は以下から見れます。

rubykaigi.org

話したこと

ざっくり言うと「Ruby の型を導入しているプロジェクトはまだ少なそうですよね。多分 gem の型定義が少ないというのも導入しづらい要因の1つだと思うので、gem_rbs_collection にコントリビュートしませんか?コントリビュートまでのステップをお話するので!」的な感じです。
発表資料はこちらです。

speakerdeck.com

@_risacan_ さんがグラレコしてくださいました。
めっちゃきれいでみやすい!ありがとうございます!!
他のセッションについてもまとめていらしてとてもわかりやすかったので、ぜひ見てみてください。

また、Wantedly さんが RubyKaigiまとめブログ。初日KeynoteからRuboCop, Mega Driveの話まで | Wantedly Engineer Blog を公開されており、こちらで僕のセッションについての記事も掲載していただいています。
とても詳しく書いてくださってありがとうございます!

www.wantedly.com

感想

月並みですが本っ当に楽しかったです。自分の好きな分野について 30 分も人前で語れる機会なんてそうそうないですし。
圧倒されるくらい多くの方が来てくださったこと自体うれしかったですし、皆さん型への興味をお持ちだということがわかったのもうれしかったです。

また、Steepgem_rbs_collection のメンテナの方々も見てくださっていたようで、あとでチャット欄を見たら僕の話を先読みしていて(ネタバレともいうw)さすがでした(ありがとうございます!)。

うれしいことづくめで本当に登壇できてよかった!
見てくださった皆さん、応援してくださった皆さんありがとうございました。

RubyKaigi に初参加した

オフラインの RubyKaigi は今回がはじめての参加でした。
昨年はオンラインでの視聴だったのですが、オフラインの良さを知ってしまったので来年も間違いなくオフライン参加します。

セッションを間近で見れた

大きなスクリーンと立派な演題で話す話者を前にセッションを見れたのがよかったです。
時には笑いが起こったり、拍手が起こったり、一体感がよかったなあ。

前の方の席で見るの、おすすめです。特に Trick

Ruby Friends がたくさんできた

やはりセッションの合間に Rubyist の皆さんと交流できるのが本当に楽しかった。
オンラインだとどうしてもセッションだけを楽しむ形になってしまいます。オフラインだと少し歩けばフィヨルドブートキャンプの関係者、コミュニティでご一緒した方、憧れのコミッターの方、Matz さんとエンカウントしてお話ししたり写真を撮ったりできます。
この体験が最高すぎて、会期中に退屈することは 1 分たりともなかったです。

ほかにも僕のセッションを聞いてくれた方が話しかけてくれて感想を言ってもらえたり、豪華なお弁当が用意されていたり、たくさんのノベルティをゲットできたりと「これが RubyKaigi か…!」と感じられることがたくさんありました。

今回は様々なご事情で現地参加できなかった方もいらっしゃると思うのですが、来年はぜひ現地でお会いできたらうれしいなと思います。

俺の Kaigi Effect

たくさんの刺激を受けたのですが、強く感じるのは「やっていくぞ!」というモチベーションがめちゃくちゃ上がったことです。
具体的にはまず RBS や Steep の内部構造を知っていきたい。その上で機能追加、改善などをできるようになりたい、という気持ちが大きいです。今の僕には大きすぎる目標かもしれないけれど、今のこの気持ちが "Kaigi Effect" なら大事にしたいですね。

その上でまた来年の RubyKaigi でもプロポーザルは出したい。プロポーザルを出す近道は手を動かしていくことだと思ったので、手を動かしていくぞ!

おわりに

まだ余韻が抜けきっていませんが、たくさん良い刺激を受けてもっと Ruby を楽しんでいきたいと思えた 3 日間でした。
また松本でお会いしましょう〜

伊藤淳一さんプレゼンツ!チェリー本の例題に機能追加してみよう SP in りんどく.rb

こんにちは、ふーが(@fugakkbn)です。

最近ダイエットのためにジョギングと食事制限を始めました。2週間ほどで 1.5kg 体重が減ったので、この調子で目標の 55kg まで続けたいなあ。

さて、僕は「りんどく.rb」という Ruby 関連書籍で輪読会をしよう!というコミュニティを運営しているのですが、そこでおもしろい取り組みをしたので紹介します。

rindokurb.connpass.com

なにをやったのか

伊藤淳一さん著、「プロを目指す人のための Ruby 入門」通称「チェリー本」のサンプルコードに機能追加をしてみました。

www.amazon.co.jp

りんどく.rb ではこのチェリー本の輪読会をしていまして、Chapter.7 はクラスに関する章で例題として「改札機プログラム」を作ります。
ちょうど改札機プログラムを終えたタイミングで伊藤さんがりんどく.rb に来てくださり、「改札機プログラムで Suica を使えるようなプログラムを組んでみたら、クラスの理解が深まっておもしろいんじゃない?」とご提案いただきました。
当時参加してくださっていた皆さんも「ぜひやりたい」という声が多く、みんなでわいわい議論しながら設計〜テスト〜実装をやってみることになりました。

なぜやったのか

僕を含め参加者の皆さんからのお声をまとめると、以下の理由から「やってみたい」と表明してくれた方が多かったです。

  • クラスの理解が深まりそう
  • 議論しながら設計していくのが楽しそう
  • テストのシナリオを自分で考えたことがないのでやってみたい

個人的には議論しながら設計するのがチーム開発っぽくて楽しそうだな、と思いました。
実際この予感は当たっていて、自分にはない観点や考え方を知る良い機会になりました。

機能追加の流れ

では、どういった流れで機能追加していったのかを、具体的な内容も交えて紹介します。

設計

まず最初に設計をするための情報をまとめることから始めました。

Suica ってなんだろう?

ここでは「Suica ってなんだろう?」という哲学的な問いから始めることにしました。

こんな情報が出てきました

どんなモデルを作る?

出た情報をもとに、「どんなモデルを作る?」を議論した結果が以下です。

具体的な話が出てきた

議論の結果、Suica モデルを追加するのがよさそう、という結論になりました。

Suica モデルはどんなふるまいをする?

ではこの Suica モデルはどんなふるまいをするのでしょうか?

これは Suica だ!

あわせて、「ふるまいをメソッドで表現したら?」というのも考えました。

コメントから試行錯誤の痕を感じます

シーケンス図

さらに、ここまでの議論でまとまった設計をシーケンス図に落とし込んでいきました。

参加者の方がうまく表現してくれた。ありがたい!

ストーリー出し

ここまでで Suica モデルの概念やふるまいが固まってきました。
次は「どういう使われ方をするのか」を考えるストーリー出しをしていきます。
以降のテスト・実装はここで出たストーリーをもとに進めていくので、漏れがないよう一生懸命捻り出しました。

最終的なストーリー一覧

テスト・実装

ここまで決まればあとは実装あるのみ!
TDD に慣れるため、まずはストーリーをもとにテストコードを書いてから実装、実装ができたらリファクタリング、という順序で進めていきました。

GitHub に実装用のリポジトリを作って fork してもらい、その日の修正をプルリクエストにしてもらいレビュー、マージ、という OSS 的な進め方ができたのもよかったです。

完成品はこちらです。

github.com

チェリー本の改札機プログラムとの差分はこちら。

github.com

学んだこと

約1ヶ月半取り組んでみて、輪読会とは違った気づきや学びがたくさんありました。
特に印象に残っていることを書きます。

設計の考え方・難しさ

普段のお仕事でも感じていることですが、設計に唯一の正解はない、というのが難しいところだなと改めて思いました。
ベストプラティスやアンチパターンを理解しつつ、実装がしやすく、利用時に扱いやすい設計を考える力が必要だと実感しました。

また、現実世界でのふるまいとプログラムとしてのふるまいのバランスも難しかったです。
基本的に現実のふるまいを踏襲したプログラムの方がいい、という考えがありましたが、あまりに近づけすぎるとプログラムとしての実現が難しくなることもあり、そのバランス感覚は一朝一夕で身に付くものではないですね。

ストーリー出しの観点

モデルやメソッドのふるまいを検証するのに必要十分なストーリーを出すことで実装がスムーズに進むことを肌で感じることができました。
ストーリーがあるおかげで「どんなテストを書けば何を検証できるか」が視覚化されて実装に迷いがなくなったと思います。

また、伊藤さんからは「具体的な数値を使う場合には境界値をテストするようにした方がいい」というアドバイスもいただきました。
これまで適当な値(テストがパスする・しないしか考慮していない値)を使ってしまっていたので、大切な観点を教えていただきました。

TDD の流儀

Red → Green → Refactoring のサイクルを回しながら実装を進めていく、というのを頭では理解していても実践することができていませんでした。
今回はこの流儀に従って進めたおかげで、「こんな感じでやっていくんだ」というのを肌で感じられました。

また、終盤にはシナリオは足りていないが実装は済んでいる、というケースもあり、シナリオをもとにテストを書いたら1発で通ってしまうということがありました。
そこで伊藤さんから「そういう時はわざと Red になるようなテストで1度 Red にして、そのあとに正しいテストで Green になることを確認すると良い。意図しない形で Green になっていないことを確認するのが大事」と教えていただきました。 あわせて「テストが1発で通ることに不安感を覚えるのは良いこと」とも言っていただき、TDD の流れが多少なりとも身についたのかな、と嬉しく思いました。

おわりに

伊藤さんからご提案いただいてノリで始めた特別回でしたが、当初想像していた以上に多くの、そして大きな学びがあり、本当にやってみてよかったです。
設計やストーリー出しなど参加者で議論することも多かったため、今まで以上に参加者の皆さんの考え方などを知れたのもうれしかったです。
機会を作ってまた同様のことをしてみたいと思います。
みんなでわいわい議論したい、設計を学んでみたい(教えてやろうも大歓迎です!)、という方はぜひ一緒にわいわいしましょう!

最後になりますが、1ヶ月半という長期間にわたり朝の貴重な時間にお付き合いいただいた伊藤さんに改めて感謝いたします。
本当にたくさんのことを教えていただき濃密な1ヶ月半でした。伊藤さん、本当にありがとうございました!!

宣伝コーナー

りんどく.rb たのしくやっています

紹介したような感じでりんどく.rb ではゆるくわいわいと楽しんでいます。
Ruby にもっと詳しくなりたい」「チェリー本をもっと深く理解したい」「わからないところを聞く場が欲しい」という方のご参加をお待ちしております。

rindokurb.connpass.com

プロを目指す人のための Ruby 入門 第2版 〜通称:チェリー本

りんどく.rb で輪読している書籍です。

www.amazon.co.jp

【Rails】既存の CSS を cssbundling-rails でバンドルできるようにする手順

こんにちは、ふーが( @fugakkbn ) です。

先日、自作アプリを webpacker から jsbundling-rails に乗り換えました。

github.com

ならば CSS も cssbundling-rails に乗り換えたい!というのは自然な流れですよね。
というわけで乗り換えました。
jsbundling-rails と違ってハマるようなポイントはほぼなかったのですが、手順を書き残しておこうと思います。

github.com

前提

  • JS 周りのビルドは jsbundling-rails + webpack を使用しています。
    • bin/dev コマンドでローカルサーバが起動し JS のビルドも実行される前提です。
  • CSS フレームワークとして Bulma を使用しています。
    • 他のフレームワークでも、記事中に bulma となっている部分を置き換えてもらえれば OK なはず。

環境

Gemfile を更新する

bulma-rails という gem を使っていましたが、必要なくなるので削除します。
Bulma でない場合も、CSS フレームワークRails 使用するための gem は必要なくなると思うので削除して良いと思います。 その上で、 cssbundling-rails を bundle します。

# Gemfile
- gem 'bulma-rails'
+ gem 'cssbundling-rails'

install コマンドを実行する

bundle install が済んだら、以下のコマンドを実行します。
Bulma じゃない場合は必要なフレームワーク名を補ってください。

$ bin/rails css:install:bulma

実行すると、必要な yarn パッケージがインストールされたり、設定ファイルが更新されたりします。
ここで生じる差分を見てみます。

app/assets/stylesheets/application.bulma.scss

これがエントリーポイントとなる scss ファイルです。
ビルド時にはまずこのファイルが読まれることになります。

@charset 'utf-8';

@import 'bulma/bulma';

中身は、node_modules 配下の bulma/bulma を読み込んでいるだけですね。

app/assets/config/manifest.js

app/assets/config/manifest.jscss のエントリーポイントを読み込んでいる場合、その記述が削除されます。
CSS を引き続き Sprockets で管理する必要がある、という場合は注意が必要です。

//= link_directory ../stylesheets .css  ←これが削除される

Procfile.dev

Procfile.devbin/dev コマンドで実行されるファイルですが、こちらに CSS をビルドするコマンドが追加されます。

css: yarn build:css --watch

このコマンドは後ほど自分で package.json に定義する必要があります。

css build 用のコマンドを定義する

package.jsonCSS ビルド用のコマンドを追加します。

"scripts": {
   "build:css": "sass ./app/assets/stylesheets/application.bulma.scss ./app/assets/builds/application.css --no-source-map --load-path=node_modules"
 }

1つ目の PATH はエントリーポイントの PATH で、2つ目の PATH は出力先の PATH です。
これで、以下のコマンドで CSS のビルドを実行することができるようになりました。

$ yarn build:css

まぁ、bin/dev で立ち上げていれば変更を検知してビルドしてくれるので、自分でコマンド叩くことはないですけど。。。

既存の scss ファイルを読み込む

もともとの CSS 関連ファイルの構成は以下のようになっていました。
構成は千差万別だと思うのでここは参考までに。

app/assets
└── stylesheets
    ├── application.scss
    └── styles
        ├── _1-modules.scss
        ├── _button.scss
        ├── _common.scss
        ├── _fixed-footer.scss
        ├── _footer.scss
        ├── _form.scss
        ├── _header.scss
        ├── _index.scss
        ├── _material-icons.scss
        ├── _reset.scss
        ├── _searched_books.scss
        └── _welcome.scss

構成に差があれど、要はこれらを application.bulma.scss から読み込んであげれば良いです。

_1modules.scss は Bulma のうち必要な定義を読み込んでいるファイルなので削除します。
そして、 application.bulma.scss では glob 記法が使えないようで以下の書き方はできませんでした。

@import '../app/assets/stylesheets/styles/*';

仕方ないので1つずつ書きました。
これどうにかならないかな?scss 追加するたびにここにも追加しなきゃいけないので、忘れそう。。。

@import '../app/assets/stylesheets/styles/reset';

@import 'bulma/bulma';

@import '../app/assets/stylesheets/styles/button';
@import '../app/assets/stylesheets/styles/common';
@import '../app/assets/stylesheets/styles/fixed-footer';
@import '../app/assets/stylesheets/styles/footer';
@import '../app/assets/stylesheets/styles/form';
@import '../app/assets/stylesheets/styles/header';
@import '../app/assets/stylesheets/styles/index';
@import '../app/assets/stylesheets/styles/material-icons';
@import '../app/assets/stylesheets/styles/searched_books';
@import '../app/assets/stylesheets/styles/welcome';

ちなみに読み込みの起点は node_modules からになります。
@import ./styles/... のようには書けないので注意が必要。

bin/dev でローカルサーバを立ち上げる

ここまで来たらビルドできるようになっています。 bin/dev でサーバを立ち上げて、エラーなく以下の表示が出れば成功です。

Compiled app/assets/stylesheets/application.bulma.scss to app/assets/builds/application.css.

本番反映

本番でのビルド方法は assets:precompile を使えば OK です。 成功するとビルドされた csspublic/assets 配下に吐かれます。

おわりに

意外とすんなり乗り換えができました。
エントリーファイルで glob 記法が使えないのだけどうにかならないかなあ。
なにか良い書き方をご存じの方、ぜひ教えてください🙏

【Rails】自作アプリで Google ログインができなくなった

こんにちは、 ふーが( @fugakkbn ) です。
ブログを書くのはだいぶお久しぶりになってしまいました。
3月からWEB エンジニアとして働いており、元気に楽しくすごしています。

最近、就職前に公開した自作アプリをよくいじっています。
そんな中で、ちゃんと動いていたはずの「Google ログイン」が動かなくなっていることに気が付きました。

Google ログインボタンをクリックすると Not found. Authentication passthru. と表示されてログインできなくなっていたのです。

ログインしようとするとこんな画面になる

結論

さきに結論を書いてしまうと、「rails-ujs を使わなくなったことで link_to メソッドで post リクエストができなくなったから」です。
Google ログイン用リンクの link_tobutton_to に置き換えることで直りました。

これだけだと味気ないので、原因特定に至るまでに確認したことも書いておきます。

確認したこと

Google oAuth の仕様変更

最初に疑ったのはこれでした。なにかしらの仕様変更があったことでログインできなくなってしまったのかな?と。

しかし調べてみても、それらしき情報は見当たりませんでした。
仕様変更があったら影響を受けるサービスは多いでしょうから、その手の記事や公式のアナウンスがないならこの線はないかな、と思いました。

gem のバージョン影響

Google ログインを実現するのに、いくつか gem を使用しています。

使っている gem のバージョンが古くなってしまったのかな?と思い、それぞれの最新バージョンを確認することにしました。
古くなっていれば、アップグレードすることで解消するかも。

しかし、いずれも最新版を使用していました。
いずれも公開当初から最新版を使っていたことになるので、バージョンによる影響ではなさそうです。

自分のブログを見直す

他の原因を考えましたが、特に思い当たるものもなく。。。「そういえば、実装当時に実装方法に関するブログを書いたな」と思い出し、何かしらのヒントがないか見てみることにしました。

fuga-ch85.hatenablog.com

「過去の自分、一生懸命書いたんやな〜」と謎の悦に浸っていると、こんな記述がありました。

認証リンクへのリクエストメソッドはPOSTである必要があります。 button_toやlink_to ..., method: :postを使わないと動かないので注意してください。

自分で書いておきながらこのことはすっかり忘れていました。
まぁもともと POST メソッドで実装してるなら変わってるわけないだろうと思いつつ、念のためリクエストの内容を確認してみることにしました。

リクエスト内容を確認する

GET になってるやないかい!!!

というわけで、ここが原因っぽいことがわかりました。
Google ログインボタンをクリックしたときのリクエストメソッドが POST になるようにしてあげれば、直りそうです。

なぜ POST リクエストじゃなくなってしまったのか

実装時はブログに書くくらいですし、POST リクエストになるように実装しているはずです。
該当のコードを見たところ、確かに method: :post の記述がありました。

= link_to omniauth_authorize_path(resource_name, provider), method: :post, class: 'button max mt-4'
  img.icon src='/g-logo.png'
    span Googleアカウントでログイン

ではなぜ POST リクエストをするように実装したはずのリンクが、GET リクエストをするようになってしまったのでしょうか。

実は少し前に、Rails 7 にバージョンアップし rails-ujs を使わないようにする Pull Request をマージしていました。
上のコードが動かなくなったのは、まさにこれが原因だったようです。

Rails 7 から標準になった turbo-rails を使って link_to の書き方を Turbo 仕様にすれば動くのですが、Devise を使っている都合上( Devise はまだ Turbo に対応していない)、Turbo を使えません。*1

そういうわけで、 link_to の代わりに button_to を使うように変更して、 method: :post がちゃんと動くようになりました。

= button_to omniauth_authorize_path(resource_name, provider), method: :post, class: 'button max mt-4'
  img.icon src='/g-logo.png'
    span Googleアカウントでログイン

めでたしめでたし。

*1:厳密にいえば使えるのですが、Turbo 対応のために本来修正の必要がない View ファイルやコントローラーをいじるのは本意でないのでやっていません(ただめんどくさいだけw)。

2021年の振り返りと2022の抱負

ふーがです。
明けましておめでとうございます!🎍

年が明けたので去年の振り返りと今年の抱負を書きます。

去年の抱負

「2021年の抱負はなんだったかな?」と思っていろいろ漁ってみたのですが、どこにも残していなかったようです😇こういうのはちゃんと残しておかないとダメですね…

去年やったこと

2021年にやったことで変化のあったことを書きたいと思います。順不同です。

FjordBootCampを卒業した

順不同とは言いつつ、これが間違いなく1番大きな出来事ですねぇ。2021年はほんとフィヨルドブートキャンプ 漬けの毎日でした。
プログラミング学習をたくさんしたし、LT会やミートアップなんかを通じて友だちもたくさんできて最高でした。

フィヨルドブートキャンプと出会えて、人生変わったなぁと思える1年になりました。

Railsガイド輪読会を主催した

元々は「パーフェクト Ruby on Rails 【増補改訂版】」の輪読会に参加させてもらっていて、それが終わるタイミングで「次はRailsガイドを読むんですが運営やりませんか?」とお声がけいただいたのがきっかけです。多分僕は輪読会が好きなんですけど、ここでの経験がりんどく.rbを主催しようというモチベーションになってるのは間違いないです。

運営メンバーの皆さんには就活の相談に乗ってもらったりもして、お世話になりっぱなしです。

LTに挑戦した

年明けてすぐくらいにフィヨルドブートキャンプ内のLT会の募集があり、そこでLTに初挑戦しました。
初めは登壇する気なかったんですけど、Twitterでいろんな方に背中を押していただいたので勢いで登壇を決めました。

背中を押してもらったおかげで、貴重な経験をすることができました。

自作キーボードに入沼した

初めての自作キーボードはこちら。

以来、Keychronを買ってみたりキーキャップもいっぱい書いました。GBも挑戦したけどそちらはまだ届いていません(いつ届くんだろう?)。
ErgoDash気に入ってるのとアルミフレームの良さも感じたので、ErgoDashのアルミフレームを購入しようかと考えている最近です。

仕事でプログラミングをするようになった

fuga-ch85.hatenablog.com

この記事に書いたように仕事でRPA開発に携わることになり、プログラミングに近いことを業務でやるようになりました。フィヨルドブートキャンプで学んだことが直接活かせたのは嬉しかったなぁ。

FF14を始めた

オンラインのFINAL FANTASYなんですが、めちゃくちゃ楽しいです。最近新しいパッチが出たんですがそれもまたストーリーがおもしろすぎて…。
ゲームは1日1時間と決めている(子供かな?)ので積みゲーが溜まって仕方ないのですが、FF14のおかげで学習の良い息抜きができるようになったと思います。

日記をつけ始めた

フィヨルドブートキャンプで学習していた時は毎日日報をつけていたのですが、卒業してから書かなくなり、せっかく日報を書く習慣が付いたので何かしら書きたいと思い、ScrapBoxで日記を書き始めました。

これまでの人生で2日以上日記が続いたことのない僕ですが、なんともう2ヶ月近く継続できています!!

副産物として、その日学んだこともまとめているので、ScrapBoxに自分だけのwiki的なものができつつあります。「あれなんだっけ?」と思ったときにここを探すと、まとめてあったりして大変べんりです。

scrapbox.io

総評

こうやってみるとプログラミングばかりしていた2021年だったことがよくわかります。2022年はもう少し、プログラミング以外にも目を向けていきたいですね。

2022年の抱負

5つほど、目標を立てました。来年の元旦に「全部達成できた!」と言えるようにがんばります。

一人前のWEBエンジニアになる

一人前の定義って難しいですけど、「安心して仕事を任せてもらえる」レベルをまずは目指したいと思います。多分この1年は激動の1年になるのではないかと思うのですが、地に足を付けて、着実に前進していきたいです。

りんどく.rbを継続して開催する

Rubyアドベントカレンダーの記事で、Ruby関連書籍の輪読会をメインとしたRubyコミュニティとして、りんどく.rbを立ち上げると宣言しました。

fuga-ch85.hatenablog.com

まだ開催日程すら決めていませんが、まもなく正式に動き出せる見込みです。どうなるかわかりませんが、年越し蕎麦のように細く長く続けていくことをまずは考えたいです。友だちが増えたらいいなぁ。

OSSに貢献する

ちょっとふわっとしてますが、どんな形でもOSSに貢献しようという姿勢は常に持っていたいと思います。ドキュメントのtypoの修正とかその程度でも気づいたらやる。それをやっておけばいざバグを踏んだときにも自然とそういうムーブで動けるんじゃないかなあ。

バグを踏んだ時にシュッとパッチを送れるような感じでいきたいです。

新しいことを始める

プログラミング以外のことで、新しいことを始めたいなと思っています。ギターかベースをやりたいというのが今の気持ちです。元々ドラムはできるので、ギターとベースを習得して各パートを自分で演奏して動画編集して、1人バンドやりたいな、という気持ちがあります。

つまり永田さんになりたい。

www.youtube.com

海外旅行に行く

これは情勢によるところも大きいかと思いますが、情勢が許せば行きたいですね。もう2年ほど行けてないですし。

まとめ

こんな感じで2022年も楽しく良い感じに過ごしていきたいと思います。
今年もよろしくお願いいたします🙏