載ってないところを軽く補足したりしておくと…… #kanrk08
醸造所だと「西陣麦酒」や「Bighand Bros」がウッドミルと同じ西陣エリアにあります。西陣麦酒の柚子無碍は個人的にも好きで、最近は京都駅前伊勢丹などで購入可能。BBは会場からも近い市役所前にタップルームがあります。… https://t.co/WHjm4JPMQA
— マジカルペンネくん🍝 (@pastak) April 30, 2025

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

ランチ情報

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

note.com

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

2025-05-22

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-8 と ja_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月

環境変数を設定して、cal や date を打つと……

$ 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 コミュニティ

2025-04-01

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

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

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

2024-12-09

irumo のギガを Mackerel で監視する

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

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

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

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

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 として買い足した回数が入ってるのがちょっと面白い。highspeeddatainfo と speedlimitreleasecountinfo はそれぞれ通常時と速度制限時で使った通信量ですね。

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

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

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

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

まずハードコードして試していた 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)"
'

2024-12-03

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

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

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

ノベルティ袋

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

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

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

デザイナーが集まるところで活版印刷の名刺を渡すと話が盛り上がって楽しい。作ってよかったな。
— takanorip (@takanoripe) November 29, 2024

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

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

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

胃袋

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

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

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

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

朝帰りするRubyistたち。 pic.twitter.com/BrRjnSqUaR
— 大倉雅史（OKURA Masafumi） (@okuramasafumi) August 23, 2024

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

おーなかさんとかあーさーさんとか、いつ寝てるの？ってくらい元気ですごい
— わいとん (@ytnobody) November 30, 2024

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

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

パッチ袋

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

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

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

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

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

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

むすび

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

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

2024-05-31

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

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

モジュラーモノリスとは

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

有名なのは Shopify のヤツ。

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

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

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

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

クックパッドの例
- 1892 models
- 1282 models
SmartBank の例
- 830 models

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

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

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

と書かれてもいる。

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

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

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

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

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

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

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

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

2024-04-30

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

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

スライドは、

Primary Signals (Metrics, Logs, Traces) はそれぞれ特性がある
- メトリックも役割が存在しているので、(自サービスの状況に合わせて) 収集しよう
どうやってメトリックを収集するか
- OpenTelemetry Collector に色々 Receiver があるのでそれを使うんだよ
- もしくは Span Metrics Connector で Traces から自動生成すると始めやすいよ

というストーリーです。

speakerdeck.com

イベント中/後に

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

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

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

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

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

id:onk のはてなブログ

京都で私が好きな場所

日本一雅な松屋

ふる里

琴ケ瀬茶屋

キッチンゴン

天下一品総本店

餃子の王将 1号店

オシャレ王将

池田屋 はなの舞

すがり

貴船神社の Wi-Fi

NINTENDO KYOTO

本能寺跡

羅生門跡

にしんそば

純喫茶

鴨川

クラフトビール

ランチ情報

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

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

irumo のギガを Mackerel で監視する

追記

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

ノベルティ袋

胃袋

パッチ袋

むすび

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

モジュラーモノリスとは

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

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

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

日本一雅な松屋

ふる里

琴ケ瀬茶屋

キッチンゴン

天下一品 総本店

餃子の王将 1号店

オシャレ王将

すがり

貴船神社の Wi-Fi

NINTENDO KYOTO

本能寺跡

羅生門跡

にしんそば

純喫茶

鴨川

ランチ情報

追記

ノベルティ袋

胃袋

パッチ袋

むすび

モジュラーモノリスとは

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

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

天下一品総本店