あきろぐ

いろいろめもするよ🐈🐈🐈

zsh-abbrを導入する

Linux zsh

シェルは長年zshを使っているが、abbr機能は使ったことがないため試してみた。

zsh-abbrとは

abbrはaliasと近しい機能であるが、aliasと違って登録した略語を自動的に展開した上でhistoryに記録してくれるもの。 zsh-abbr.olets.dev

導入はbrewでインストールし、いくつかの設定をzshrcに追記すればOK。

# install
brew install olets/tap/zsh-abbr

# activate abbreviations
# add the following at the end of your .zshrc
source /opt/homebrew/share/zsh-abbr/zsh-abbr.zsh

abbrに登録したコマンドの補完を有効にするには以下もzshrcに追加する。

# .zshrc
  if type brew &>/dev/null; then
    FPATH=$(brew --prefix)/share/zsh-abbr:$FPATH

    autoload -Uz compinit
    compinit
  fi

zshrcを再読み込みしてabbrコマンドが有効になっていればOK。

❯ abbr --version
zsh-abbr version 6.5.2

試してみる

abbrコマンドを使って登録してみる。

❯ abbr hw="echo hello world"
Added the regular user abbreviation `hw`

一覧を確認すると、登録されているのが分かる。 登録した略語コマンドは即時そのセッションで使用可能となる。

❯ abbr list
"hw"="echo hello world"

以下のように自動展開されていることが分かると思う。

削除するときは、abbr eraseを使う。

❯ abbr erase hw
Erased regular user abbreviation `hw`

zshのaliasを自動的にabbrにインポートする機能も兼ね備えている。abbr import-aliasesコマンドを使えば一発で登録できるようになっている。

まずは、dry-runを実行して意図した挙動になっているか確認してからインポートする。

❯ abbr import-aliases --dry-run
Would add the regular user abbreviation `df`
Would add the regular user abbreviation `du`
Would add the regular user abbreviation `g`
Would add the regular user abbreviation `g-ph`
Would add the regular user abbreviation `hs`
Would add the regular user abbreviation `la`
Would add the regular user abbreviation `ll`
Would add the regular user abbreviation `lt`
Would add the regular user abbreviation `mybr`
Would add the regular user abbreviation `run-help`
Would add the regular user abbreviation `vim`
Would add the regular user abbreviation `which-command`
Dry run. Changes not saved.

問題なさそうだったので、インポートして確認してみると意図通りに登録されている。

❯ abbr list
"df"="df -h"
"du"="du -h"
"g-ph"="git push origin `mybr`"
"g"="git"
"hs"="history"
"la"="ls -a"
"ll"="ls -l"
"lt"="ls -lt"
"mybr"="git rev-parse --abbrev-ref @"
"run-help"="man"
"vim"="nvim"
"which-command"="whence"

1つ注意点としては、インポート対象にはzshrcに登録したaliasだけではなくzshデフォルトのaliasもインポート対象になる。 zshのデフォルトのaliasを確認するにはこちらのコマンドを実行すると確認できる。

❯ zsh -fc alias
run-help=man
which-command=whence

つまり、run-helpとwhich-commandはzshデフォルトのaliasであることが分かる。

参考：

https://www.reddit.com/r/zsh/comments/on53sy/i_cant_find_where_the_aliases_get_stored/

設定しておくと良いもの

zsh-autosuggestionsと連携させる

zsh-autosuggestionsを使っているなら、zsh-autosuggestions-abbreviations-strategyを入れておくとzsh-abbrに登録した略語もサジェストしてくれる。

github.com

リマインダーを設定する

zsh-abbrに登録してもその略語を忘れてしまいがち問題に対しては、以下の環境変数を設定しておくと略語に登録したコマンドを実行したときにリマインドしてくれる。

# zsh-abbr reminders
ABBR_GET_AVAILABLE_ABBREVIATION=1
ABBR_LOG_AVAILABLE_ABBREVIATION=1
ABBR_LOG_AVAILABLE_ABBREVIATION_AFTER=1

例えば、ls -lコマンドを実行したとき

❯ ls -l
total 37120
### 省略 ###
abbr: `ll` is your regular user abbreviation for `ls -l` # リマインド

abbrをバージョン管理する

zsh-abbrにコマンドを追加すると環境変数ABBR_USER_ABBREVIATIONS_FILEに設定されているconfigファイルに書き込まれる仕様となっている。zsh-abbrで管理するコマンドはzshrcではなく別ファイルとして切り出した方がよさそう。 自分の環境だと~/.config/zsh-abbr/user-abbreviationsというファイルに書き込まれていたので、このファイルをdotfilesレポジトリで管理し、シンボリックリンクを貼る運用にするつもり。

Storage and manual editing :: zsh-abbr

2025年の振り返り

普段は1年の振り返りは書かないのですが、今年は自分の中で印象的かつ節目の年でもあったので備忘録的に残しておこうかなと思います。

ライブ3本やった

今年は例年より多くライブをやりました。1月に2本、11月に1本と偏りはありますが、ベースを弾く機会をたくさんもらえてとても楽しかったです。今年はベースの難易度が高い曲が多くコピーするのが大変でしたが、そのおかげもあり、少しベースが上達した気がしてます。

まず今年1本目は、1月11日にukfes#4に出演させてもらいました。私は「五反田ノット」というバンドで結束バンドのコピーをやりました。結束バンドのベースは本当に鬼畜でしたね。ベーシストとしての力不足を痛感しました。

ukstudio.jp

セットリストはこちら：

  1. ギターと孤独と蒼い惑星
  2. 忘れてやらない
  3. Re:Re:
  4. 青春コンプレックス

特に、青春コンプレックスのベースラインが難しいだけでなく、1番と2番でフレーズが結構変わるし2回転調するので、暗譜するのが大変でした。

2本目は、1月18日にTechRockFestivalのスタジオ配信ライブに出演しました。TechRockFestivalは第1回から出演させてもらっていて、1回目の時に一緒にバンドをやった「水曜日のコンパイラ」のメンバーで出ました。

trf.connpass.com

セットリストはこちら：

  1. To Be With You / Mr. Big
  2. Under the Bridge / Red Hot Chili Peppers
  3. Whatever / OASIS
  4. Numb / Linkin Park

いつもと違って、新宿NOAHのスタジオを1日借りて自分たちで配信ライブをし、みんなでお酒を飲みながらわいわいするのが楽しかったです。自分はPA周りは全然詳しくなく、全くセッティングの戦力になりませんでしたが、かるぱさん中心に配信ライブの音質を支えてくれたのでとても心強かったです。

3本目は、11月22日にTechRockFestivalのDAY3に出演しました。今回は、「Heavy Longe」というバンドでメタル中心のコピーをやりました。また、バンド名にちなんで10年ぶりくらいに髪を伸ばしました。意外とロン毛が今の自分にしっくりきたので、しばらく維持しようかなと思ってます。

trf-taupe.vercel.app

セットリストはこちら：

  1. Dance, Dance / Fall Out Boy
  2. Thnks fr th Mmrs / Fall Out Boy
  3. Fuel / METALLICA
  4. Enter Sandman / METALLICA
  5. Master Of Puppets / METALLICA

何回か曲変した結果、Fall Out BoyとMETALLICAに振り切ったセットリストになりました。自分としては、初めてメタルバンドのコピーをしたのですが、結構難しくて苦戦しました。ハンマリングとプリング地獄でちょっと辛かったかも。特にMaster Of Puppetsは変調で曲構成が複雑で覚えるのも大変なのに、長いし速い！！！ロバート・トゥルヒーヨはあれを指で弾いてるのは超人すぎるなと痛感しました。あれは無理。ちょっと楽して弾いているところはあるんですが、なんとかやりきれてよかったです。ライブ後の打ち上げは、疲労と達成感でテンションがちょっとおかしかった気がします。笑

エフェクターデビューした

私は元々エフェクターを頑なに使わないアン直人間だったのですが、ついに今年エフェクターデビューしました。大きなきっかけがあった訳ではないのですが、周りの人たちから機材の話を聞いていると、ベースの音作りにもっとこだわってみたい、向き合ってみたいという気持ちが徐々に湧いてきたので、思い切って購入してみました。

初エフェクター何を購入するのか散々悩んだんですが、今年のベーマガ2月号に紹介されていたのをきっかけに知ったSansAmpのXB Driverを購入しました。これを選んだ理由は、このエフェクターを通した時に出せる音に惚れたからのが一番大きい気がします。クリーンとドライブのチャンネルでそれぞれ独立した音作りができて、なおかつそれらをMIXすることもできるので、かなりバリエーションのある音作りがこの1台でできそうだなと思い購入に至りました。SansAmpの集大成のような複合エフェクターなので結構なお値段しますし、初手でこんな高価なエフェクター買うのはどうなんだと思いましたが、結果買ってよかったなと思ってます。

www.kikutani.co.jp

3回目のライブの時に初めて使ったのですが、音作りは以下の感じでやりました。

  • Fall Out Boy: クリーンチャンネルだけを使い、ローを持ち上げてミドルは抑えめにし、あとはコンプで補正。
  • メタリカ: クリーンとドライブチャンネルをMIXし、ドライブチャンネルの方はローを切ってミドル強めにし、若干歪ませる感じに。ドライブのつまみをあげすぎるとジャリジャリしすぎてちょっと安っぽくなる感じがあったので、ちょっと歪ませるくらいがちょうど良さそうだった。あとはBITEスイッチで高音域をブーストさせた。

でも、まだまだエフェクター初心者で使いこなせてはないと思うので、色々と学びたいなと思ってます。（教えてほしい・・・）

初めて公募枠で登壇した

エンジニア関連でいくと、今年は初めて公募枠で登壇しました。去年、Kaigi on RailsでスポンサーLTとして登壇デビューしたのですが、せっかくなら自分が話したいテーマで登壇してみたいなとぼんやり考えていました。そんな時に、3月にTokyoWomen.rbが開催されることを知ったので、思い切って応募したところ無事採択されました。話した内容は、特に目新しい内容ではないのですが、元SREとしてRailsアプリケーションを運用していくために取り組んでいることとして、デッドコードの削除とパフォーマンス改善の取り組みの話をしてきました。

speakerdeck.com

当日は冷や汗をかくくらい緊張したのですが、無事やりきれてよかったです。

初めてのRailsGirlsのコーチ

今年初めてRailsGirlsのコーチをやりました。RailsGirlsの存在は以前から知っていたのですが、Rubyistの友人であるnekoさんがコーチしているのを見ていて、どこかで自分もやってみたいなと思っていました。ちょうど開発者になって3年が経ちRailsにもだいぶ慣れてきたところだったので、チャレンジしてみることにしました。

自分はちゃんとGirls達に分かりやすく教えられるだろうかと不安はありましたが、私たちのチームは無事デプロイするところまでいったのでよかったです。私が担当したGirlsは、ブートキャンプに通ってプログラミングを勉強している方で、私がそこまでサポートしなくても自力で解決していっていたので、とても頼もしかったです。

6年勤めた会社を退職した

今年の一番大きなイベントとしては、6年間勤めた会社を退職したことです。それなりの規模感のあるtoCサービスの開発・運用に携わらせてもらい、エンジニアとしてたくさん経験を積ませてもらいました。

もともとSES系の企業でインフラエンジニアとして働いており、そこから転職してきたのですが、まだ経験が浅い状態だったのにも関わらず、ポテンシャル枠でSREとして採用してもらいました。入社してからは大小さまざまなプロジェクトに携わらせてもらったおかげで、1人前のSREとしてワークするレベルに引き上げてもらったと思います。本当にハードな局面が何度かあり、涙を流したこともありましたが、同僚の励ましのおかげで頑張れました。

そして、その後プログラミングスクールに通い勉強していたことを評価してもらえたのもあり、SREから開発者として社内で転向させてもらいました。開発者に転向してからは、CGMプラットフォームに移行するための新機能開発や検索機能の改善、WebのSEO改善のためにLLMを使ってレシピ判定処理やプレーンテキストから構造化データを生成する仕組み作りなどをやってきました。この取り組みは、AWS Summit 2025のセッションの中で事例として取り上げてもらいとても嬉しかったです。*1

また、それ以外にもチームにアジャイル開発体制を導入したり、開発環境のリプレースやインフラコストの削減など技術負債の解消にも注力しました。SREと開発の両方を経験できたことで、自分ができることの幅が広がり、後半はロール関係なく必要なことをやっていくスタイルで動いていたと思います。

本当に濃い6年間でした。最初はあまりなじめてないなと思っていたのですが、飲みに行ったり、キャンプしたり、バレーしたりと仲良くしてくれる同僚ができて仕事以外でも楽しかったです。最終出社日にもらった色紙やプレゼントもとても嬉しかったな〜！BIG感謝！

転職するよ

次は来年1月から製造業のSaaSを作っている会社にSREとして入社予定です。まだ開発者として頑張りたい気持ちもあったのですが、悩んだ末またSREに戻ることにしました。縁あってお世話になった元上司とまた一緒に働くことになりそうです。

グローバル展開が進んでいて、英語話者も多く在籍しているとのことなので、最近は英会話スクールに通ってます。もともとグローバルでも通用するプロダクトに携わりたいと思っていたので、とても楽しみです。

まとめ

私は毎年テーマを決めているのですが、今年は「自分らしくいる、自分と向き合う」ことがテーマでした。振り返ると、結構その通りの一年になったのかなと思います。

来年は環境が新しく変わるので、どんな一年にしていこうか考え中です。 引き続きベースをたくさん弾きたいですし、2本目のベースの購入を検討中です。

では良いお年を！

*1:https://pages.awscloud.com/rs/112-TZM-766/images/AWS-19_AI_AWS-Summit-JP-2025.pdf

S3のマルチパートアップロードとaws s3 cpコマンドの挙動を学んだ

aws

マルチパートアップロードとは

  • aws s3のマルチパートアップロードとは、1つのオブジェクトを複数のパートに分けてS3バケットにアップロードできる機能
  • マルチパートアップロードは、5MB~5TBのサイズまで対応可能
  • オブジェクトのパートが全てアップロード完了したら、パートには番号が付与されているので、それを元に組み立てて1つのオブジェクトを作成する
  • AWSでは、100MBを超えるオブジェクトはマルチパートアップロードを使うことを推奨している
    • メリットとして挙げられているのは以下の通り：
      • パートを並列にアップロードできるので、スループットが向上する（帯域幅を最大限活用できる）
      • ネットワークエラーによって再開する時のリスクを最小限にできる

マルチパートアップロードの挙動

  • 例えば、100GBのファイルをマルチパーとアップロードすると、合計1002回のAPIコールが実行される
  • マルチパートアップロードが正常に完了しなかったら（ CompleteMultipartUploadAPIがコールされなかったら）、S3はパートを組み立ててオブジェクトを作成しないまま、そのまま残り続ける
  • オブジェクトとして組み立てられなかったパートに対しても課金が発生するので注意

    aws s3コマンドの挙動

  • AWS CLIには、aws s3コマンドとaws s3apiコマンドが存在する
  • これらの違いは、s3apiコマンドの方が高レベルのs3コマンドでは公開されていないAPIレベルの操作ができる点
    • つまり、s3 cpコマンドはいくつかのAPIコールがラップされているということ
  • 注意点として挙げられているのは、大容量オブジェクトをアップロードする場合、AWS CLIは自動的にマルチパートアップロードを実行すること。aws s3コマンドを使っている場合は、コマンドの実行に失敗したり、システム障害により正常にコマンドが実行完了しなかった場合は、オブジェクトとして生成されなかったパートが残り続けるため注意しなければならない。
  • AWSのベストプラクティスとしては、意図せず不完全なマルチパートアップロードによって発生したパートを削除するために、ライフサイクルを設定することを推奨している

    オブジェクト数をカウントする時に気をつけたいこと

  • CloudwatchやS3 Storage Lensで確認できるNumberOfObjectsは、すべてのストレージクラスのバケットに保存された保存数（最新、最新ではないオブジェクト数の合計+削除マーカーがついたオブジェクト数+不完全なマルチパートアップロードの合計パート数）なので、注意
  • aws s3 ls <s3_path> --recursive | wc -lコマンドなどでカウントした数は、実存するオブジェクトのみカウントしている
  • これを知らなくて、NumberOfObjectsと差分があり戸惑った

参考文献

RubyKaigi2025@愛媛に参加しました

RubyKaigi

RubyKaigi2025@愛媛に参加してきました！RubyKaigiは自分がRubyistになった翌年から参加しており、今回で3回目です。少しずつ分かることや知り合いも増えてきて、RubyKaigiでの再開を約束していたりするので、年々楽しみ度が高まっている気がします。

また、松山市は私が3歳になる頃まで住んでいた、ゆかりのある場所だったので、久しぶりに訪れることができるのも楽しみでした。

印象に残ったセッション

他にもたくさんセッションを聞いてどれも興味深かったのですが、ブログ書き終わらなさそうなので割愛します;;

Day1. Ruby Taught Me About Encoding Under the Hood

speakerdeck.com

ima1zumiさんのkeynoteから始まったRubyKaigi。Day1の朝イチの飛行機で会場に向かったので、ギリギリでしたが間に合いました。ima1zumiさんが文字コードに興味を持ったのは、igaigaさんが家族の絵文字（🧑‍🧑‍🧒）がIRBクラッシュすること教えてくれたことがきっかけだそうです。きっかけは些細なことだけど、ここから文字コードに興味を持ち、自分自身でクラッシュをfixし、そしてRubyコミッターになられているなんて...！とてもかっこいいなと思いました。

keynoteでは文字コードの歴史から遡り、Unicodeによって全世界的に統一された文字コードが発明されたことから話されていて、文字コード1つとっても長い歴史の中で変遷があったのだなととても興味深く話を聞いていました。 そして、家族の絵文字（🧑‍🧑‍🧒）は、ユーザーからすると1文字だけど、7つのコードポイントで構成されており、バックスペースを2回実行すると、途中に挟まっているZWJ（Zero Width Joiner）との兼ね合いでカーソル位置がズレてしまうことでクラッシュしているとのことでした。 この発表で、Unicodeには書記素クラスタという概念があることを初めて知りました。RubyのStringクラスにも書記素クラスタを扱うメソッドがあるんですね。

docs.ruby-lang.org

また、Rubyが持つUnicodeのデータベースを更新するお話をされてました。Unicode15.1.0では、インド系文字の処理に関わる新たなプロパティ「Indic_Conjunct_Break」が追加され、複雑な子音の組み合わせ（子音クラスター）も正確に扱えるようになったそうです。*1 このプロパティ追加の影響で、既存のパース処理が失敗し、テストが落ちるようになったため、パースロジックの修正も行われたとのことでした。

Unicodeは年に1度の頻度で更新されており、Rubyでも内部のデータベースを継続的にアップデートしているそうです。こうした地道なアップデートによって、私たちが日々Rubyを使って多様な言語や文字を扱えるのだなと感じました。

Day2. Speeding up Class#new

speakerdeck.com

@tenderloveさんの発表は今回のRubyKaigiで楽しみにしていたセッションの1つでした。Class#newがCで実装されていることに興味を持ち、内部実装を調べてみたことがきっかけで、RubyだけでClass#newを実装し高速化することを試みたそうです。Class#newはRubyとC言語を行き来していることで、そのタイミングに時間がかかっているとのことでした。どのタイミングで話されていたか忘れてしまったのですが、親クラスが増えるほどメソッド探索に時間がかかるので、インラインキャッシュでメソッド探索を効率化させているというお話もされていました。

最適化を実施した結果、Ruby3.4とRuby3.5で比較すると1.8倍早くなり、キーワード引数を使う場合でも3.2倍速くなったとのことでした（3つのキーワード引数の場合）。速くなった分、消費メモリが増えたとのことで、そこはトレードオフだよなと思いました。 発表の中で、キーワード引数を持つメソッドは内部的に並び替えが発生するから遅いという話もされており、キーワード引数の挙動も知れて面白かったです。

Day2. Making TCPSocket.new "Happy"!

speakerdeck.com そして、しおいさんの発表！しおいさんの話はいつも面白くて、聞き入ってしまいます。 しおいさんは、ネットワークの接続効率を上げるために、IPv6とIPv4の名前解決を同時実行することが可能なHappy Eyeballs Version 2（HEv2）アルゴリズムをRubyのSocketライブラリに対応させる取り組みをされており、昨年はRubyのSocket.tcpメソッドのHEv2対応が完了したので、Ruby3.4でリリースされています。 *2

今回は、RubyのSocket.tcpの問題点を解決するために再実装した話とCで実装されたTCPSocket.newをHEv2対応させた話でした。 Socket.tcpの問題点として挙げられていたのは、IPv6とIPv4の名前解決がほぼ同時に完了した場合、キューから先にIPv4アドレスを取り出したとするとIPv6の名前解決を待つために無駄なIO.selectが呼ばれてしまっていたそうです。そのため、状態管理をやめて1ループの中で行うことができる処理は全て実行するアプローチに変更されたとのことです。

TCPSocket.newをHEv2対応するにあたって、解消しなければならない課題がいくつかあったそうです。例えば、socketライブラリはpipeとselect(2)で待機可能な名前解決関数が存在しないことなどです。 これらを解決するために、既存の関数を拡張するのではなく、HEv2対応した新しい名前解決関数を追加して対応したとのことでした。

200ページを超える発表でしたが、しおいさんの今まで努力とどんな問題に直面しても乗り越えていくかっこよさが詰まっていてとても素敵でした。改めてコミッター就任おめでとうございます！

Day3. On-the-fly Suggestions of Rewriting Method Deprecations

speakerdeck.com

@ohbaryeさんの発表は、非推奨になったメソッドを動的に書き換えることができるDeprewriterというツールを開発したお話でした。 非推奨の警告自体はよく目にしますが、対応はどうしても後回しになりがちで、置き換え作業にもかなりのコストがかかると感じていたので、こうしたツールがあると移行作業がぐっとスムーズになりそうだなと思いました。

github.com

Rubyのエコシステムでは、ドキュメント（READMEなど）、ランタイムでの警告表示、静的・動的解析ツールなどを通じて、ユーザーに非推奨化を通知しています。 発表では、他の言語における非推奨化のアプローチについても紹介されていて、言語によって対応がかなり違うこともとても興味深かったです。

特にPharoという言語では、ランタイムで自動的にコードを書き換える仕組みがあり、そのアプローチに着想を得て、Ruby向けに移植する形でDeprewriterを開発したとのことでした。

Deprewriterは本番環境ではなくローカルやテスト環境での利用を想定しており、用途に応じて使い分けができるように、log・diff・rewriteの3つのモードが提供されているそうです。

Day3. Programming Language for AI age

最後は、Matzさんのkeynoteでしたが、まさか迫り上がって登場してくるとは思わなかったので、衝撃的でした。笑

MatzさんのAI時代において、逆シンドロームに気をつけなければならないという話が印象的でした。AIの進化が速くて日々キャッチアップするのは大変ですが、あくまで人間が主導権を握るべきで、うまく付き合っていく必要があるなと思いました。

また、Ruby4.0のリリースを考えているとおっしゃっており、ZJITやNamespaceが実験的に含まれるとのことだったので楽しみです。

その他

みきゃんになった

わかなさんの発案で手作りカチューシャ作って、愛媛のご当地キャラクターのみきゃんになりました。笑 はじめ、頭に葉っぱつけよ？と言われた時は、ちょっと戸惑いましたが、面白かったです。いい思い出。笑

みかん堪能した

ANDPADさんのブースでは、蛇口からみかんジュース出てきたり、食べチョクさんのブースでは、日替わりで品種の異なるみかんを配布していたり、休憩中もみかんが食べれたり、Kaigi中みかんを堪能できて満足でした。

個人的に、松山城の近くにあるみかんやさんでは３種のみかんを選んでブレンドジュース作れて飲めるのですが、それがめっちゃ美味しかったです。道後温泉近くのみかんジュース飲み比べも行きたかったけど、混んでて断念;;

酸味強めのいよかんを選んだのがミソ

道後温泉近くにあるみかんおにぎりもすごくおいしかったな〜

意外とおいしかった

RubyKaraoke楽しかった

あまりカラオケ得意じゃないので、今まで参加してなかったんですが、幹事のふーがさんや仲の良いRubyistに誘われて初参加しました。

盛り上がりすごかったし楽しかったので、行ってよかったです！途中力尽きて完走はできなかったですが、来年も参加したいなと思いました笑

松山城 && 道後温泉最高だった

Day.4に松山城行きましたが、かなりの堅牢な城で見応えもすごくありました。建設に四半世紀もかかったとのこと。難攻不落と言われるだけあるなと思いました。

念願の道後温泉の本館にも行けてよかったです。個室を取ったのでゆっくりくつろげて、夏目漱石の坊ちゃんの部屋も見学できたしとても満足でした。スタッフのおもてなしもすごく手厚くて感動しました...！

締め

今年もRubyKaigi楽しかったです。運営スタッフ && スポンサーの皆さんありがとうございました！ 久しぶりに会えたRubyistと美味しいご飯とお酒を堪能できて、わいわいできて本当に楽しかったなとしみじみしてます。

来年の函館も楽しみ〜〜！（来年は前乗りしていきたい！）

*1:https://www.unicode.org/versions/Unicode15.1.0/

*2:https://www.ruby-lang.org/ja/news/2024/12/25/ruby-3-4-0-released/