2024年10月のふりかえり

生活

やったこと

ユニコーンオーバーロード

jokerさんが勧めていたのをどこかで見てアトラスも制作しているということで興味を持って始めたが最後、終われなくなった。夜ふかしの限界ラインを知った。80時間くらいプレイしてまだ表ボスを倒せていない。始めると終われない。完璧主義が悪さをして全員との好感度を上げまくってしまう。先週くらいにようやくやめられるようになって生活が戻ってきた。RubyConfに行くまでに表ボス倒すくらいは進めたい。

いかにして強いコンボを組めるか、強さを押し付けられるかという点を考えてパーティーを組む楽しさがある。

登壇1ヶ月前に新しいゲームを始めないようにしよう...。

Kaigi on Rails 2024に参加した

Kaigi on Rails 2024に参加した - Eggshell

スタッフエンジニアの道を読み始めた

www.oreilly.co.jp

マネージャーの道は舗装されているがスタッフエンジニアの道は舗装されておらず、自然となるもののように扱われているがそうではないだろうというところから始まっていて面白い。説得の話なのかもしれない。道を照らし皆を導き支えるのはあなた自身なのだ。

スタッフエンジニアのような技術力を身につけるための本ではなかった（まえがきにかいてあった）

1日1万歩歩く

先週の木曜日から意識しはじめた。Apple WatchにDuffyというアプリを入れて歩数を常に可視化できるようにしたら達成したくなって捗っている。

今日は歩数が足りなかったけど1万歩を達成したかったので家の中で足踏みしたりダンスして歩数を稼いだ。

テルミン

きみの色に影響されてOpenThereminを買ったけど手持ちのスピーカーとの相性が悪いのかノイズがすごくて全然弾けてない。チューニングもしたし導線買って人間アースはしてみているが...まずはスピーカーを探さないといけないかも。Outer Wildsの某曲を弾きたい

いつも通過する駅で降りて散歩

気の向くままに歩いた。参道を見つけて大きな寺に向かったり、喫茶店を探してコーヒーを飲んだりして楽しかった。

継続したこと

Duolingo 英語コース

Anki, Speak, ELSA はほとんどやらず。

見た映像

Kaigi on Rails 2024に参加した

Ruby on Rails

2024-10-25、2024-10-26の2日間開催された Kaigi on Rails 2024 に現地参加した。

RailsのPull requestsのレビューの時に私が考えていること

Actual Behaviorの話が印象的。It does not work. ではなくて実際に起こっていることを書くのは必要だし自分がIssueをトリアージするときも意識して情報を求めていきたいなぁと思った。IRBやRelineのIssues、PRテンプレートを見直したくなった。より踏み込んだ日々の向き合いの話を聞きたくなった。Grammar in Useやるぞ。

推し活としてのrails new

現実の問題・課題に対して自分のできることで世界をよりよくしていく活動の話が大好きなのでとっても楽しかった。私たちはプログラマだから日常生活のお困りごとをプログラミングでシュッと解決できるんですよ〜とエールをもらった気分になった。t-wadaさんの「ソフトウェア エンジニアとしての 姿勢と心構え」の「身の回りをプログラミング対象にする」と近い話だなと思った。

作って理解する RDBMSのしくみ

RDBMSのしくみの概要がまとまっていて、この話をきっかけにRDBMSのより深い話に踏み込んでいけそうだった。本当にやりたいことはまだあるんじゃないかなと思うので次回作とリポジトリの公開が楽しみ！自分でもRDBMS作ってみたいなぁ。

OmniAuthから学ぶOAuth 2.0

OmniAuthを使うときに設定する短いコードの中でどういったことを行っているのかがわかって、ざっくり地図が手に入った感じでよかった。OmniAuthがない世界だったらどうなる？という眼でみてみるところが面白かった。

Identifying User Identity

moroさんのスライドは発表の空気感をも作っていていいなあと思う。フォント、字間など。

という感想を持った。user.admin? みたいなのは書きたいわけではないなーと思った。意味で分割していったとき、境界線上にあるようなカラムがでてくるとどこにカラム追加すべきかを迷いそうだと思った。その場合はテーブル増やすのかな。欲しいデータはどこにあるんだーみたいな迷いは生まれないんだろうか。

WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと

深く入り込んでくるキーノートだった。聞いてる間、これは自分のために語られた話かもしれない...みたいに没入しちゃってとても良かった。ちょっと咀嚼しきれていないので箇条書きで思ったことやスライドの内容を書く。

  • よい設計とは
    • よく観察すること
      • 観察眼のためにはたくさんのいいパターン、悪いパターンを知る必要がありそう
      • Web技術、データベース技術、計算機システムなど
    • シンプルに作る
      • 言うは易し行うは難し
      • 何が必要十分なのかは自明ではない
        • ヒント
          • 標準の道具、標準の解決策で作る
            • 既存の仕組みが標準に乗っていない場合もあるなぁ
            • 必要なら修復せよという話なのかもしれない
          • 本当に必要になるまで複雑な仕組みを避ける
    • シンプルさを維持する
      • 修復：もとに戻すのではなく、変わった後の全体と再度調和させる
      • システムからのシグナルに気づく
        • 気づきやすい状態を整える
    • 学習ガイド：書籍、コード、コミュニティ

一歩一歩学んで精進しようと思った。本をいろいろ読みたくなった。あと、楽しいの軸を忘れないようにしたい。義務感ドリブンで動きがちなのでそのあたり疎かにしてしまいがちであるが楽しい状態を維持していけば物事は労せずとも進んでいく気がする。

その他

あっとどっと書店

笹田さんが展開していた本屋さん。島田さんが訳しているスタッフエンジニアへの道を買った。ちょっと気になっていたものの買うまでのふんぎりはついていなかったので本屋さんがあったから買うきっかけになって良かった。こういう場所で買った本は、Kaigi on Rails 2024で買ったという思い出が付いてくるのでなんだか特別な色がつくように感じる。

あっとどっと書店は電子レシートに掲載されていた書店名なので購入した人たちだけが知っている店名かもしれない。フフフ

わいわい部屋

美味しいコーヒーが飲めておしゃべりできる空間がありがたかった。並びながら一緒に並んでいる人に話しかけたり、ドリップしているおぎじゅんさんや飛び入りバイトのみなさんに話しかけたり、コーヒーを飲んでいる人に話しかけたりとコーヒーを中心にコミュニケーションが生まれる場になっていた。ぜひ来年もお願いします...!

わいわい部屋ではRubyConfの話をしたり、角谷トーク・フィヨブーフェス2024の様子の話を聞いたり、ルービックキューブの話をしたり、IRBとRelineとrepl_type_completorの話をしたり、インクとガラスペンと万年筆と紙の話をしたりして楽しかった。やんちゃさんやこばじゅんさんがルービックキューブを揃えているのを見てルービックキューブを始めたくなった。以前もらった入門キューブの出番だ。

RubyMusicMixin on Rails 2024

DJ興味あるというとやりなよと複数人に後押しされたのでやる、やるか〜〜〜と思った。教えてもらったDJ練習できる場所の予約システムがSTORES 予約という自分たちが開発しているサービスを使っていて嬉しくなった。

coubic.com

DJ G4きゅーぶ氏のDDR選曲が特に楽しかった。Butterflyまた踏みたいなー。

終わりに

とても楽しいカンファレンスに参加できてよかった！オーガナイザーのみなさん、発表者のみなさん、すべての関係者のみなさんに感謝します。ありがとうございました。

RubyKaigiの2006年から2024年までの登壇者一覧を見れるWebページを作った

rubykaigi-speakers.vercel.app

github.com

RubyKaigiのスピーカーごとに過去に何を話したのか知りたいときがたまにあるのでGitHub - ruby-no-kai/rubykaigi-staticや公式サイトからHTMLを取得してスクレイピングした。HTMLにもその当時の時代が表れており面白かったが取得がだいぶ難しい年もあった。

2021年以降はymlにデータがあるのでそちらを使うようにしたい。

名寄せについては人力で見つけているので、漏れてる人がいたら教えて下さい。

2024年3月のふりかえり

やったこと

退職した

3月末日を持って永和システムマネジメントを退職した。大変お世話になりました。

Relineのレビュー

ぺんさんがやってくれたRelineのline_editorのレンダリングまわりの大規模リファクタリングのレビューをしていた。2〜3週間くらいかかった気がする。

github.com

line_editorの仕組みをほとんどわかっていなかったので、こんな感じでコードリーディングをした

  • debug.gemで文字入力から文字が表示されるところまでどんなメソッドに何がわたってくるのか追いかける
  • わかったところ、わからないところをPRのdiffにコメントしてまとめていく
  • メソッド単位でChatGPTに入力して解説してもらう
  • わからないところを随時ぺんさんに質問する
  • わからないところをピンポイントでデバッグしたりまとめたりする
  • レビューコメントを英語に書き直して、自分用のまとめは別ブランチを切ってそこにまとめていく

まとめた内容

Memo · ima1zumi/reline@30d02c0 · GitHub

完全に理解するところを目指すとレビューが終わらないので、おおまかな動きの把握やコアとなるメソッドの処理内容の理解や概念を目標にした。line_editorの動きを大体把握できたのと、すばらしいリファクタリングをリリースできたのでよかった。

DDR

SP足13をクリアできるようになった。楽しい。

不用品の整理をした

大きめの不用品をフリマアプリに出品した。

新機動戦記ガンダムWを見始めた

キャラクターの言動がいきいきしていて面白い。16話まで見た。

Asakusa.rb Hanamiに参加した

エアロプレスと災害用湯沸かしセットを持ち込んでコーヒーを淹れた。外でコーヒー淹れるのは楽しい。

Hanamiは屋外ならではの開放感があると思う。ワイワイ話をして楽しかった。

RubyKaigiの準備

レビューしていてあまり進まなかった。まずい。

読んだ

WEB+DB PRESS Vol.110 名前付け大全

名前付け大全の特集を読んだ。「良い名前」の定義がされていた。名前から連想するイメージが大きすぎても小さすぎてもいけない。

ドメインに関する英語の記事を読むことで語彙を増やす作戦が良さそうだった。

読んでる

継続したこと

  • Duolingo 日本語話者向け中国語コース
  • Speak
  • ELSA

Ankiはお休みする日が多かった。復習が700枚くらいになってしまった。

買ったもの

開発環境の見直しをしていた。

FlexScan EV3895

8時間仕事をすると目が痛くてしょうがなかったので思い切っていいディスプレイを買うことにした。これに変えてから目が痛くなくて良かった。

重くて設置が大変だった。ディスプレイアームが緩んで傾いてたりしたので、アームが耐えられるかは重要そう。耐荷重クリアしてることは確認したけどがさがさやってる間にずれたりして緩んでしまったっぽい。

M3 MacBook Air

軽い。ゴールドが新鮮

UTF-8 validationとmruby/c

Ruby 文字コード

これは mrubyファミリー Advent Calendar 2023 の2日目の記事です。

こんにちは。ima1zumiです。

私はmruby/cでUTF-8を使えるように実装しています。そのなかでRubyの String#valid_encoding みたいな機能を実装しているのでその背景とコードについて書きます。

mruby/c についての説明は昨日のはすみさんの記事がわかりやすかったので、そちらをご覧ください。

しまもん | はすみきん | mrubyファミリーの歩き方（を装ったビルドシステムの話）

現在のmruby/cの文字コード

現在のmruby/cの文字コードはCRubyでいうASCII-8BITのみ使える状態です。文字をバイナリとして格納しているので、どんな文字でも入れられます。ただし、文字数を取るようなメソッドではバイト単位で判定されます。例えば "あ" のようにUTF-8でマルチバイト文字を作ると "あ".size # => 3 となります。

これはUTF-8での あ は \xE3\x81\x82 で3バイトあるため3文字と判定されています。その他にもString#indexなどが文字単位ではなくバイト単位で動いてしまいます。

UTF-8を使えるようにする

というわけでUTF-8を使えるように実装しているのですが、一つ問題がありました。mruby/cはなるべく軽量に作りたいので、Encodingクラスを作りたくありません。そのためビルドオプションでStringのEncodingをASCII-8BIT相当のものか、UTF-8かを切り替える方針にしようとしています。

しかしUTF-8にはinvalidなバイト列があります。たとえば以下のように、 \xE3\x80\x80 はvalidですが、 \xE3\x80\x7F はinvalidです。

String.new("\xE3\x80\x80", encoding: Encoding::UTF_8).valid_encoding?
# => true
String.new("\xE3\x80\x7F", encoding: Encoding::UTF_8).valid_encoding?
# => false

UTF-8にはこのバイトで始まった場合続くバイトはこれしか取れない、というルールがあります。 \xE3\x80\x7F はそれに違反しているためinvalidな文字列です。

仕様はこちらに書いてあります。

Table 3-7. Well-Formed UTF-8 Byte Sequences

https://www.unicode.org/versions/Unicode15.1.0/ch03.pdf

CRubyでは違反した場合文字列を作成できないか、invalidな文字列だというフラグが立つようになっています。しかしビルドオプションでEncodingを切り替えるmruby/cでは、その設定だとUTF-8を有効にしたときにバイト列をStringで作れなくなってしまい困ります。セキュリティ上invalidな文字列を扱うのはよくないのですが、mruby/cではワンチップマイコン向けの言語ということもあり、

ということで、Stringはどんな文字列でも作成できるが、valid_encoding?でvalidかどうか検査できるようにします。

実装

素朴にTable 3-7を実装しました。ビット演算でできるところはビット演算にして、命令を減らすようにしています。

ちなみにUTF-8 validationはいろいろ高速化の方法が研究されている*1ようで、これはあまり最適ではありません。

static void c_string_valid_encoding(struct VM *vm, mrbc_value v[], int argc)
{
#if MRBC_USE_STRING_UTF8
  unsigned char *str = (unsigned char *)mrbc_string_cstr(&v[0]);
  int len = mrbc_string_size(&v[0]);
  int i = 0;

  if (len == 0) {
    SET_TRUE_RETURN();
    return;
  }

  while (i < len) {
    // 1 byte
    if (str[i] <= 0x7F) {
      i++;
    // 2 bytes
    // First byte: C0..DF
    // Second byte: 80..BF
    } else if ((0xC2 <= str[i]) && (str[i] <= 0xDF) && (str[i+1] & 0xC0) == 0x80) {
      i += 2;
    // 3 bytes
    // First byte:  E0
    // Second byte: A0..BF
    // Third byte:  80..BF
    } else if ((str[i] == 0xE0) && (str[i+1] & 0xE0) == 0xA0 && (str[i+2] & 0xC0) == 0x80) {
      i += 3;
    // First byte:  E1..EC
    // Second byte: 80..BF
    // Third byte:  80..BF
    } else if (0xE1 <= str[i] && str[i] <= 0xEC && (str[i+1] & 0xC0) == 0x80 && (str[i+2] & 0xC0) == 0x80) {
      i += 3;
    // First byte: ED
    // Second byte: 80..9F
    // Third byte: 80..BF
    } else if ((str[i] == 0xED) && ((str[i+1] & 0xE0) == 0x80) && (str[i+2] & 0xC0) == 0x80) {
      i += 3;
    // First byte:  EE..EF
    // Second byte: 80..BF
    // Third byte:  80..BF
    } else if ((str[i] == 0xEE || str[i] == 0xEF) && (str[i+1] & 0xC0) == 0x80 && (str[i+2] & 0xC0) == 0x80) {
      i += 3;
    // 4 bytes
    // First byte:  F0
    // Second byte: 90..BF
    // Third byte:  80..BF
    // Fourth byte: 80..BF
    } else if ((str[i] == 0xF0) && (0x90 <= str[i+1]) && (str[i+1] <= 0xBF) && (str[i+2] & 0xC0) == 0x80 && (str[i+3] & 0xC0) == 0x80) {
      i += 4;
    // First byte:  F1..F3
    // Second byte: 80..BF
    // Third byte:  80..BF
    // Fourth byte: 80..BF
    } else if ((0xF1 <= str[i]) && (str[i] <= 0xF3) && (str[i+1] & 0xC0) == 0x80 && (str[i+2] & 0xC0) == 0x80 && (str[i+3] & 0xC0) == 0x80) {
      i += 4;
    // First byte:  F4
    // Second byte: 80..8F
    // Third byte:  80..BF
    // Fourth byte: 80..BF
    } else if ((str[i] == 0xF4) && (str[i+1] & 0xF0) == 0x80 && (str[i+2] & 0xC0) == 0x80 && (str[i+3] & 0xC0) == 0x80) {
      i += 4;
    } else {
      SET_FALSE_RETURN();
      return;
    }
  }
  SET_TRUE_RETURN();
#else
  SET_TRUE_RETURN();
#endif
}

3日目は執筆者募集中です！

*1:ref: 高速UTF-8バリデーションの世界 #高速化 - Qiita

IRBの型補完を有効にする方法

Ruby

IRB 1.9.0から tompng さんの実装によりIRBでは型補完が使えるようになりました。katakata_irb の機能がIRB本体に入った形です。

今までは正規表現での補完だったため精度があまり良くなかったのですが、型のパワーを得てより速く精度の良い補完になりました。

今のところデフォルトでは正規表現補完を利用するため、型補完を利用するには設定が必要です。

github.com

依存関係

Ruby 3.0.0 以上、RBS、prism が必要です。

prism がない場合メッセージが出て、正規表現補完にフォールバックします。

型補完を有効にする方法

.irbrc で設定

IRB.conf[:COMPLETOR] = :type

環境変数で設定

※IRB 1.9.1 以降で有効

IRB_COMPLETOR=type

Railsでは例えば development.rb でこんな感じで有効にできます。

Rails.application.configure do
  console do
    ENV["IRB_COMPLETOR"] ||= "type"
  end
end

irb bin/console などのオプションとして渡す

irb --type-completor

設定の確認方法

irb_info でどの補完を使っているか分かります。

irb(main):001> irb_info
Ruby version: 3.3.0
IRB version: irb 1.9.1 (2023-11-21)
InputMethod: RelineInputMethod with Reline 0.4.0
Completion: Autocomplete, TypeCompletion::Completor(Prism: 0.17.1, RBS: 3.3.0) # 型補完
.irbrc path: /Users/mi/.irbrc
RUBY_PLATFORM: x86_64-darwin21
East Asian Ambiguous Width: 1
=> nil

Kaigi on Rails 2023に参加した

Ruby on Rails

浅草橋で行われたKaigi on Rails 2023に参加した。

印象に残ったセッション

やさしいActiveRecordのDB接続のしくみ

step by step でDBに接続するまでの過程を追いかけ、どのようなクラスがどんな働きをしているのかの解説だった。重要なポイントに絞ってありすごく理解しやすかった。接続までの過程でどんなクラスが登場するか分かったので今後何か困ったときにこの知識が活きそう。

数十億のレコードを持つ5年目サービスの設計と障害解決

レコード数が少ないときには簡単にできたことが、レコード数が多くなってくることで問題になったり解決が難しくなってくる。id をinteger にしてしまう問題は以前私たちのプロジェクトでもレビューで指摘があり、改めて気をつけようと思った。

A Decade of Rails Bug Fixes

10年前のバグ修正と、10年後のバグ修正の話。byroot のような素晴らしいプログラマがコードの正しさよりもコミュニケーションを大事にしよう、と言うのはすごい説得力がある。私もNiceな態度を心がけようと思った。

:sorena:

後半は byroot 以外にこのバグを直せる人が世界に何人いるだろう？と思いながら聞いていた。「git log を見る時点で（バグの原因探しとしては）絶望的な状況」というのは確かにそうだと思った。再現手順を見つけるとか、先にやることがある。

初めてのパフォーマンス改善 〜君たちはどう計測するか〜

同僚のふーがさんのセッション。byroot のセッションを聞いてから改めて考え直すと、2人は違う切り口で同じことを言っていると思った。問題解決のためには仮説検証サイクルを回すこと、事実を集めて問題を分解するということが重要である、と言っていると思う。

一緒に働く中でふーがさんは問題解決能力が高いと感じており、その思考を言語化してもらって垣間見ることができたなと感じた。また、ふーがさんのセッションもbyrootのセッションも両方聞くことで問題解決とはこういうことだよね、という理解が3つの具体例から抽象化できたような気がした。問題を目の前にすると気が急いてしまいがちなのだけど、焦らずに一つずつ問題に取り組んでいきたいなあと思った。

イベント

STORES CAFE〜Kaigi on Rails 2023出張版〜

ノンアルコールで、お子さんと一緒に参加できるミートアップだった。何組かお子さん連れで参加されている方たちがいて、みんな楽しそうで盛り上がっていた。私もとても楽しんだ。会場の大きさに大して余裕がある人数でちょうど良かった。ノンアルコールでよくある一通りのドリンクと、STORESさんで扱っているクラフトコーラやスパイスが効いたシロップがあった。シロップを炭酸で割って飲むのがとても美味しかった。ノンアルのドリンクはどうしてもいつでも飲めるものが多くてスペシャル感が薄くなりがちなのを、こういったその場ならではのドリンクがあるといい体験したなぁと少し嬉しくなれてありがたい。

後半にogijunさんがネルドリップでコーヒーを淹れてくれる時間があり、猫廼舎ファンなので非常に嬉しかった。お昼にフリースペースで出張猫廼舎のペーパードリップコーヒーをいただいてはいたが、やはりネルドリップは柔らかさが違うなぁと思った。

After Party

立食で数百人規模で交流するのはRubyKaigi以来2回目だった。フルリモートワークであまり運動していない人間の体力のなさを感じた。後半疲れて隅っこのほうに座っていると、だんだん人が集まってきたのが面白かった。

話したことない人に話しかけるのは勇気がいるけど、話しかけないといつもの人たちとしか話さないんだよなぁと思った。しかしとっかかりがないと難しい。知り合いが知らない人と話していたらその輪に飛び込んでみるみたいなエイヤッと勇気が必要そう。

あとスピーカーTシャツは会期中毎日着ていいものだと思った。15分とか30分話を聞いただけでは顔を覚えられないので、話を聞いてみたいと思っても Attendee.all.select... では会場の中で探せない。スピーカーTシャツがあると Attendee.speaker から探せるのでできてとても助かる。

RubyMusicMixin on Rails 2023

DJに興味あるので全員のプレイに興味津々でほぼほぼ最前にいた。とはいえスペースがなくてステップ踏めるほどじゃなかったので揺れてるだけでそんなに疲れなかった。それぞれ30分だったけどあっという間だった。DJは集中力ずっと使って大変そうと思った

ラストのオブさんのプレイが印象的で、魅せ方がうまい〜。あとRubyMusicMixinのときも思ったけど緩急の付け方もうまいんだよなぁ、30分でテンションを上げたり落ち着かせたり、一瞬音を止めたりスクラッチで注目させたり観客側に振ってくれたりと様々な楽しませ方をしてくれる。あと不思議と全然疲れない。そういえば最初の曲で完全に止まっちゃうトラブルがあったけど、何事もなかったかのように再開してて凄かった。

今回のMixinは最前でもよく聞こえないくらい音が小さかったのはすこし残念だった。 盛り上がってくると人の声にDJの音量が負けてた気がした。

KaigiEffect

私にとっての Kaigi on Rails の KaigiEffect*1 は2つあった。

RDBMS が動く仕組みを知りたいと思った

Free Spaceでの雑談でRDBMSの性能で悩んでいることをいろいろな人に相談に乗ってもらい、あわせてRDBMSがどんな仕組みで動いているのか少し教えてもらった。ワクワクしたし、自分はRDBMSについて何も知らないなぁと思った。昔に知ったメインフレームで動くDBの知識が中途半端に残っているので、令和最新版にしたいというのもある。

RDBMSは賢く強く信頼できるソフトウェアだと思っていて、そんな子がどうやって動いているのか知りたいんだよなぁ。仲良くしていきたい。

私の知りたいことに合いそうなおすすめの本を3冊教えてもらったのでまずはこちらから読んでいこうと思う。

ogijunさんからカップ＆ソーサーを購入した

大江戸Ruby会議10でogijunさんが「カップによってコーヒーの味は変わる」と言っていたのを聞いて、飲み口が薄かったり香りの立ち具合が良いコーヒーカップがほしいなと思っていた。うちにはマグカップはたくさんあるけどちゃんとしたコーヒーカップはなかった。

そうしたら、STORES CAFEでogijunさんがお店で使っていたカップの隠居先を探していると聞いて、購入することにした。なにせその場でogijunさんが淹れてくれたコーヒーでカップを試すことができる。手に持った具合や、佇まい、口当たり、何ccくらい入るか、とかとかすべて（しかもogijunさんが淹れたコーヒーで）実践で試して買うことができるのだ。こんなことができる機会が他にあるだろうか。いや、ない。

というわけでこのカップとソーサーにはうちで余生を過ごしてもらうことにした。早速使っているのだが、机の上に素敵なカップとソーサーがあるというのは思った以上に精神によい。特にソーサーがあることがこれほどいいとは思っていなかった。

これからも大事に使っていきたい。

有田焼のコーヒーカップとソーサー

*1:https://x.com/kakutani/status/1452995218857504774?s=20