京都で私が好きな場所

こんにちは。関西Ruby会議08オーガナイザー、Kyoto.rb 所属の id:onk です。 健康診断の再検査会場で待ち時間にヒマなのでスマホから書いています。みんなも予選突破したら検査行こうね。私は何年か放置していました。

日本一雅な松屋

このツイートで有名になったヤツ。

ただの松屋ですが、ホテルの1階なので庭が良い。ついったー映え写真にどうぞ。

会場からは徒歩15分ぐらい。烏丸線に乗りたいときとかに移動中に撮るといいんじゃないかな。

tabelog.com

ふる里

普通の居酒屋だけど、生搾りサワーがすごいで有名な店。アルコールの入ったスムージーです。

デイリーポータルZにも取り上げられていたね。僕もこれで知って行きました。

dailyportalz.jp

当日は大宮まで移動することまず無いだろう (会場からは徒歩30-40分) から、前後の日 (今日とか) にどうぞ。

琴ケ瀬茶屋

嵐山の穴場的な飲み屋。川のほとりで酒が飲めます。めっちゃいいので適当に画像検索してみて。

渡月橋を渡ったら人の居ない方に数分歩いて行くとあります。 橋を渡らずにボートで行くのも観光っぽくていいんじゃないかなと思うけど僕はボート未経験。

営業日分かってなくて、Day2 に営業してるかは自信ない。たぶんやってるはず……。

tabelog.com

キッチンゴン

知る人ぞ知る京都名物ピネライス。 チャーハンにトンカツを乗せてカレーをかけてある、小学生の考えた最強料理みたいなヤツです。 量は普通なのでビビんなくて大丈夫。

六角店は行きやすいと思う。徒歩7分ぐらい?

tabelog.com

天下一品 総本店

僕もまだ行ったこと無いので興味ある人いたら一緒に行きましょう

tabelog.com

限定の牛すじラーメンがオススメトノコト

www.tenkaippin.co.jp

餃子の王将 1号店

ただの王将ですが発祥の地の石碑はあります。 大宮駅前。

tabelog.com

オシャレ王将

王将で思い出した。日本に4軒しかないオシャレ王将が京都にあります。

www.ohsho.co.jp

ワイングラスが逆さまになって天井からぶら下がってるレベルのオシャレ度。 湯葉天津飯とか、せいろ蒸しとか、ごま団子とかがオシャレメニューかなぁ。

会場からは 20 分ぐらい。これも烏丸御池駅に行きたいときにどうぞ。

tabelog.com

池田屋 はなの舞

新撰組のあの池田屋騒動跡地が、はなの舞 (大衆居酒屋ですね) になってます。 どの辺が池田屋かと言うと、大階段があって、店員さんがダンダラ羽織着てるぐらい。

会場からは徒歩 3 分ぐらい?

池田屋騒動之址って石碑もある。

tabelog.com

すがり

一番京都感というか一見さんお断り感(?)を感じられるラーメン屋だと思う。

まず店の外観に看板やら暖簾やらのお店要素が無い。知ってなきゃドア開けられない系。 中は京町家の雰囲気を存分に楽しめると思う。 一方通行の構造で、他の人とすれ違わないで出られるようになっているのも「京都」っぽさのポイント高い。(入口と出口が別。)

tabelog.com

すがり近所に2店あって、どっちも京都感あると思うけど、会場に近い六角の方のすがりが僕はオススメです。キャッシュレスオンリーなのに注意。

貴船神社Wi-Fi

貴船神社のフリーWi-Fiが繋ぎたくなるいい名前なので見て行ってくれ。もし行くならぜひ小ネタにどうぞ。

貴船口との間にプログラマーが好きそうな名前のカフェもあります

tabelog.com

NINTENDO KYOTO

ニンテンドーショップです。近いし京都っぽい (任天堂さん、京都の会社ですね) し、いいんじゃないかな。

限定品もあるよ

www.nintendo.com

本能寺跡

街中に石碑があるぐらい。「ああそれも京都だっけ」って思い出して貰おうと思って書きました。

本能寺は本能寺の変のあとに移転しているので、現本能寺と本能寺跡は場所が違うことに注意。二条城との位置関係が全然違う。

羅生門

これもガッカリポイントとして有名。

にしんそば

京都以外で見ないし、京都名物だろう。魚がまるっとそばの上にのってるビジュアル見たことない人はぜひ。

純喫茶

本当にいっぱいあるので好きなところにどうぞ

鴨川

等間隔のカップル見たり、トンビにサンドイッチかっ攫われたりしましょう

割と普段から普通に鴨川ビールしてます。「川」Origin だし、当日夜もやるんじゃないかな。

(余談)デルタの勢力図はとても好き。

今日めっちゃ雨だったので、流れてきたオオサンショウウオ見られるかもしれないですね。

クラフトビール

エントリあるので見てください!

note.com

補足もどうぞ。(長文なので開いて見てね)

いくつかは前夜祭に持っていきます。

ランチ情報

エントリあるので見てください!

note.com

それでは楽しい関西Ruby会議08を~

macOS Sequoia (15.4 以降) で cal や date を打つと出力がおかしい

$ cal
      3月 2025
日 月 火 水 木 金 土
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

5 月なのに 3 月と言われる。

$ date
#午後

date#午後 という文字列が返ってくる。

状況は cal -y するとある程度理解できて、

$ cal -y | grep "[0-9]月"
         PM            %Y年 %B%e日 %A %X %Z            1月
         2月                    3月                    4月
         5月                    6月                    7月
         8月                    9月                   10月

と、本来「1月」「2月」となるべきところに「PM」「%Y年 %B%e日 %A %X %Z」が入り込んでいる。どこかで何らかのズレが生じているのだろう。

どうやら日本語だけの問題っぽく、LANG を変えると正常に出力される。

$ LANG=C cal
      May 2025
Su Mo Tu We Th Fr Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
$ LANG=C date
Thu May 22 02:01:25 JST 2025

これはもう LOCALE の問題であろう。と /usr/share/locale/ 以下を眺めると、ja_JP.UTF-8 を含むいくつかの言語ファイルで行数が違うのが見える。

$ wc -l /usr/share/locale/*.UTF-8/LC_TIME
...
      58 /usr/share/locale/is_IS.UTF-8/LC_TIME
      58 /usr/share/locale/it_CH.UTF-8/LC_TIME
      58 /usr/share/locale/it_IT.UTF-8/LC_TIME
      60 /usr/share/locale/ja_JP.UTF-8/LC_TIME
      58 /usr/share/locale/kk_KZ.UTF-8/LC_TIME
      60 /usr/share/locale/ko_KR.UTF-8/LC_TIME
      58 /usr/share/locale/lt_LT.UTF-8/LC_TIME
      58 /usr/share/locale/lv_LV.UTF-8/LC_TIME
      58 /usr/share/locale/mn_MN.UTF-8/LC_TIME
...

en_US.UTF-8ja_JP.UTF-8 を見比べると、確かにおかしい。

$ cat -n /usr/share/locale/en_US.UTF-8/LC_TIME
...
    38  Saturday
    39  %H:%M:%S
    40  %m/%d/%Y
    41  %a %b %e %X %Y
    42  AM
    43  PM
    44  %a %b %e %X %Z %Y
    45  January
    46  February
    47  March
...
$ cat -n /usr/share/locale/ja_JP.UTF-8/LC_TIME
...
    38  土曜日
    39  %H時%M分%S秒
    40  %Y/%m/%d
    41  %a %b/%e %T %Y
    42  #午前
    43  AM
    44  #午後
    45  PM
    46  %Y年 %B%e日 %A %X %Z
    47  1月
...

先ほど cal -y で出力されていたのもこの 45 行目、46 行目ですね。

じゃあ /usr/share/locale/ja_JP.UTF-8/LC_TIME を書き換えたら直るんじゃないかと思ったら sudo でも編集できない。SIP (System Integrity Protection) によって守られてるんだった。

ここまで見て「面白い〜」と社の Slack で共有したところ、id:KashEight から「man setlocale が参考になりそう?」という反応を貰った。

$ man setlocale
...
FILES
     $PATH_LOCALE/locale/category
     /usr/share/locale/locale/category  locale file for the locale locale and the category category.
     /usr/local/share/locale/locale/category
                                        locale file for the locale locale and the category category.
...

環境変数 $PATH_LOCALE を見ているので、リカバリーモードで無理矢理 /usr/share/locale/ 以下を書き換えなくてもどうにかなりそう。

$HOME/.config/locale/ 以下に ja_JP.UTF-8/ をまるっとコピーして、LC_TIME を弄る。

$ diff -u {/usr/share,$HOME/.config}/locale/ja_JP.UTF-8/LC_TIME
--- /usr/share/locale/ja_JP.UTF-8/LC_TIME       2025-04-12 14:16:09
+++ /Users/onaka/.config/locale/ja_JP.UTF-8/LC_TIME   2025-05-17 13:51:58
@@ -39,10 +39,8 @@
 %H時%M分%S秒
 %Y/%m/%d
 %a %b/%e %T %Y
-#午前
-AM
-#午後
-PM
+午前
+午後
 %Y年 %B%e日 %A %X %Z
 1月
 2月

環境変数を設定して、caldate を打つと……

$ export PATH_LOCALE=$HOME/.config/locale
$ cal
      5月 2025         
日 月 火 水 木 金 土  
             1  2  3  
 4  5  6  7  8  9 10  
11 12 13 14 15 16 17  
18 19 20 21 22 23 24  
25 26 27 28 29 30 31  
$ date
2025年 5月22日 木曜日 02時19分11秒 JST

やったぜ!

以下のディスカッションも見つけました。Sequoia 15.4 以降のバグっぽいのでフィードバックしておきましょう。先日出た 15.5 でも直ってない!

Mac - ターミナルにて2ヶ月前のカレンダーが表示されます - Apple コミュニティ

株式会社はてなに入社しました

株式会社はてなに入社しました

株式会社はてなに入社しました - hitode909の日記

8 年目。コード書かないマネージャーを 2 年やってるので、そろそろ戻る算段付けないとな

irumo のギガを Mackerel で監視する

この記事は Mackerel Advent Calendar 2024 の 9 日目の記事です。

普段使いのモバイル回線は docomo というか irumo なんですが、自宅から離れて生活するとギガを使い切って買い足す日々を送っています。

11 月は 3 GB 買い足した

データ通信量ってなんか上手いことアラート出せないですよね。2GB 使った後に「使ってるよ」って言われても困る。というわけで Mackerel で監視するようにしました。

まずはブラウザから https://irumo.docomo.ne.jp/ を触って Developer Tools の Network タブを眺める。

日ごとの数字が入っていそうな JSON 発見

https://irumo.docomo.ne.jp/api/uw/tra/v1.0/getdatareferenceinf への POST で JSON が返ってきているっぽいのが分かったので、リクエストヘッダをどこまで削っても取れるかを試す。

今回は spsp Cookie だけ渡せば動くっぽかったです。

curl 'https://irumo.docomo.ne.jp/api/uw/tra/v1.0/getdatareferenceinf' \
-H 'User-Agent: DataUsageCheckerBot/1.0 (@onk)' \
-H 'Cookie: spsp=xxxxxxxx' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-raw 'requestpatterncode=0009&getuser_div=3'
{
  ...
  "data": {
    ...
    "daydatainfo": {
      ...
      "dayusedatainfo_list": [
        {
          "targetdate": "20241201",
          "daydatadetailinfo": {
            "databypacket": "973737",
            "databygb": "0.93",
            "speedlimitreleasecount": "0"
          },
          "speedlimitreleasecountinfo": {
            "databypacket": "0",
            "databygb": "0.00"
          },
          "highspeeddatainfo": {
            "databypacket": "973737",
            "databygb": "0.93"
          }
        },
        ...

各日のデータに speedlimitreleasecount として買い足した回数が入ってるのがちょっと面白い。highspeeddatainfospeedlimitreleasecountinfo はそれぞれ通常時と速度制限時で使った通信量ですね。

JSON が取れたらあとは加工して Mackerel に送れば完成しそう!

値を取るのは jq でエイってやります。

... | jq -r '
.data.daydatainfo.dayusedatainfo_list[] |
 select(.targetdate | test("20241201")) |
 .daydatadetailinfo.databypacket'
973737

それっぽい数字が取れたので送信用にちょっと加工。

まずハードコードして試していた test("20241201") の部分は外から --arg today $(date '+%Y%m%d') と渡します。

また、Mackerel 向けに投げるならタブ区切りの文字列にしたいですよね。\(...) で String interpolation できるし、now で現在時刻を錬成できるので、全体はこうなります。

... | jq -r --arg today $(date '+%Y%m%d') '
.data.daydatainfo.dayusedatainfo_list[] |
 select(.targetdate | test($today)) |
 "custom.irumo.data-usage\t\(.daydatadetailinfo.databypacket)\t\(now)"'
custom.irumo.data-usage 908991  1733754915

あとは mkr throw で投げて完成です。

... | mkr throw --service irumo

グラフができました

データが溜まったら線形回帰関数を使ってアラートを投げたりして遊びましょう。身の回りのメトリックっぽいデータはとりあえず Mackerel に投げておくと、そのうち使い道を思いつくものです。

Mackerel Advent Calendar 2024、明日は id:taxintt さんです。

追記

1 日のデータ取り出しても毎日 0 から始まってしまうので、今月のデータを合計する必要がありました。

jq -r --arg month $(date '+%Y%m') '
  (.data.daydatainfo.dayusedatainfo_list |
  map(
    select(.targetdate | startswith($month)) |
    .daydatadetailinfo.databypacket | tonumber
  ) | add) as $total |
  "custom.irumo.data-usage\t\($total)\t\(now)"
'

コミュニティ生活で大切な三つの袋

これは はてなエンジニア Advent Calendar 2024 の 3 日目の記事です。昨日は id:todays_mitsui による 不動点コンビネータで無名再帰を作る流れをおさらい with JavaScript - 無駄と文化 でした。

さて、オフライン回帰している昨今、In-Person でのコミュニティ活動や大規模カンファレンスがだいぶ復活してきました。少なくとも私の周り (京都) では In-Person イベントがデフォルトに戻ったなぁと思っています。そんなコミュニティ生活で、学びや繋がりを深めるためにはちょっとした「コツ」があります。そのコツを、三つの袋に例えてみました。

ノベルティ

最初の袋は「ノベルティ袋」です。これは自分の存在を認知して貰うための袋です。

コミュニティ活動では、たくさんの人と出会いますが、後日「見たことはある気がするんだけど」となりがちですよね。ここで活躍するのが、ステッカー類です。

例えば自分のアイコンのステッカーや、ちょっとユーモアの効いた名刺などを配ると、それが記憶に残って次回も話しかけて貰えたりします。先日もこんな話を見かけました。コミュニティの性質を感じて面白いですね。

あるいは自社のノベルティも効果的です。「あっこれ前貰った!」と覚えてくれる可能性が高まります。

ステッカーを貰って困るという人も多いかもしれませんが、カンファレンスでのノベルティ類はカンファレンスや年ごとにクリアファイルにまとめて取っておくと、数年後に見返したときに時代を感じて面白いですよ。毎回処遇に困っている方はぜひやってみてください。

ノベルティ袋、ぜひみなさんも準備していきましょう。自分の存在感を強める武器になります。

胃袋

次は「胃袋」です。これは特に遠方でのカンファレンスで重要です。

遠方開催の場合、たいていの人が小旅行として泊まりがけで参加します。そういう場だと、懇親会も一次会、二次会、そして三次会まで続くことも珍しくありません。懇親会の最初の方はどうしてもフォーマルな雰囲気が残っていますが、時間が進むにつれてお互いに打ち解け、本音や深い話が出てくるものです。それを味わえるのが三次会などの深夜の時間帯です。

特に「同じ時間を共有する」というのが良いのでしょう。懇親会の後半になってリラックスした時間、本音が漏れてくるような時間帯は、ただの情報共有ではなく心の距離を縮める時間になります。単なる単純接触効果を超えた効果がここにある気がしています。

同じ時間を共有した結果、朝帰りになったことで「戦友」という肩書きが増えていくのも、グッと絆を深めるポイントです。

もちろん全員にすべての会に参加しろというわけではありません。健康第一です。でも、たまには「今日は締めのラーメンまで付き合うぞ」と覚悟を決めてみるのもいいものです。そのようにして生まれた絆や信頼関係はかけがえのないものになるはずです。

命を削って参加してますからね。

胃袋をしっかり鍛えて、楽しみながら会話を重ねて、信頼関係を構築していきましょう。

パッチ袋

最後は「パッチ袋」です。

コミュニティに初めて参加するときに、自分から積極的に自己紹介するのは難しいかもしれません。でもコードを GitHub にアップしておくことで、自然とコミュニティの一員になれます。

先日 Kaigi on Rails 2024 に参加した際、以前 sinatra-activerecord gem に Pull Request を数件出していたことで @cupnoodle (現 sinatra-activerecord のメンテナ) から話しかけて貰えました。この出来事自体は 3 年前の Pull Request に言及してくれるという、ちょっと本当に凄すぎるエピソードなんですが、こういうこともあるんですよ。いや本当にビックリした。

先ほど「胃袋」とお伝えしましたが、飲み会で生まれるのは一時的な親近感だと思います。それも大事なんですが、長期的なコミュニティの存続のためには具体的な成果物が根底にあるべきと考えます。

コーディングは、成果物を共有できる、共同で成長できる、という性質を持っています。「このコミュニティにいると技術的に成長できる」「価値のある貢献ができる」という体験が Social Coding にあります。プログラマとしての我々がコミュニティに提供できる最高のものは、やはり工数。継続的に労働力を提供し続けるのが一番の貢献です。

パッチ袋には、コミュニティの存続を支える力が詰まっています。コードを通じた繋がりもいいものですよ。

むすび

というわけで、「三つの袋」について話してきました。ノベルティ袋で繋がって、胃袋でイベントを楽しみ、パッチ袋で技術を共有する。この三つの袋を持っていれば、コミュニティ生活をより充実したものにできます。ぜひ準備して、今後のコミュニティ生活を思いっきり楽しんでください。

はてなエンジニア Advent Calendar 2024、明日は id:susisu です。

Modular Monolith はどの辺りから考え始めるものなのか

モノリスでは大変なので、マイクロサービスやモジュラーモノリスにして認知負荷を減らしたり、生産性の劣化に抗いたいという考え方がある。

モジュラーモノリスとは

モジュラーモノリスについては、だいたい infoq.com のモノリスシリーズ(?)を読めば良いんじゃないか。

有名なのは Shopify のヤツ

モノリスとマイクロサービスの中間にある、1 アプリケーションなんだけどモノリスでは無い、アプリ内でモジュール分けされているアーキテクチャのこと。app/ の直下に MVC を置くんじゃなくて、COMPONENTS (例えば billing)/app/ の下に MVC を置く、ようなイメージ。

モジュラーに移行するタイミング

僕の感覚だと、数百モデルは全然モノリスで扱えると思っている。少なくとも 300 models 程度でモジュラーにしていく必要はまったく感じない。

世の中で見つけたモデル数だと

の辺りは確かモノリスだったと思う。800 なり 1000 なりを超えても普通にモノリスで扱っているのは割と勇気が貰える数字だよね。

SmartBank さんは B/43のサーバーサイド開発の醍醐味と伸びしろ - inSmartBank の中で

現在はモノリスで開発していますがモジュラーモノリスだったりマイクロサービスのようなアーキテクチャも検討していきたい

と書かれてもいる。

800 は割としんどい数字なのだろう。この辺りが「移行したくなるタイミング」なのは僕の感覚とも合っている。

認知負荷が非常に高まってからでは遅い

じゃあ 800 になってからモジュラーに分割し始めるのかと言うと、痛みが表面化してから分け始めると、完了するまでずっと痛みを抱えていることになるし、既に密に絡まり合いまくっていて、分割するのはとてもコストがかかる作業になる。

その手前、400-500 models 辺りから着手し始めると、ちょうど安定的な生産性を得続けられるんじゃないだろうか。触っていて厳しさを感じずに開発できる環境を維持するチャンスがこのタイミング。ぜひ開発合宿とかでチャレンジしてみて欲しい。

逆に言うと、400-500 models にまだ手が届かない状態でモジュラーに分け始めるのは時期尚早っぽいと僕は思う。普通のリファクタリングがその手前にいっぱいあるんじゃないかな〜。

このタイミングでやるべきだった、という後知恵を集めたい。御社の例を教えてください。

僕はモノリス派なので話半分に聞いてもらうとして、じゃあ 200-250 models を超えたらモジュラーにし始めるタイミングなのかもしれないね。モジュラーでも爆速で走る方法を知っていて、それで困りが無いのであれば、いつ導入してもいいわけだし。

複雑なアプリケーションを運用する功夫クンフー》は無限に積んでおきたいものである。

OpenTelemetry でのメトリック収集の始め方について話してきた

Findy さんのイベント で OpenTelemetry + Metrics の話をしてきた。(10分トーク)

スライドは、

  • Primary Signals (Metrics, Logs, Traces) はそれぞれ特性がある
    • メトリックも役割が存在しているので、(自サービスの状況に合わせて) 収集しよう
  • どうやってメトリックを収集するか

というストーリーです。

speakerdeck.com

イベント中/後に

  • メトリックを OTel で収集したことがまだなかった
  • Receiver は LISTEN するだけだと思っていた
    • Receiver から値を取得しにいくイメージを持っていなかった

といった声も寄せられたので、とっかかりとなる最初の一歩を置いておくのは大事だなと思いました。

実際、監視やダッシュボードよりもオブザーバビリティを高める方にみんなの意識が向いているし、既存の監視ツールで既に網羅されていることが多いので、今 OpenTelemetry + Metrics の話を聞くことは少なめです。SaaS によっては Traces だけ送っておくと勝手に Metrics になるしね。

自サービスにメトリックの収集を導入して、そもそも何が見られるか。何を見ているか。今までと比べて何か変わった実感を得たところは何か。といった例を増やしていければ良いなと思います。

Disclaimer: 私はメトリックを収集する SaaS の開発に関わっています。ぜひ 試してみてください