20250501 てんや『海かぜ天丼』

項目 内容 得点 換算点
睡眠時間 7時間40分 100 13.0/13.0
起床 9:00 50 4.0/8.0
散歩 ノー 0 0.0/5.0
朝食の栄養カバレッジ 3色カバー 100 5.0/5.0
体操 実施 100 5.0/5.0
労働 passion: 80点, discipline: 80点 80 19.2/24.0
ジム 休養日 100 12.0/12.0
勉強会 ノー 0 0.0/12.0
個人開発 実施 100 7.0/7.0
あすけん - 76 6.8/9.0
総合 1日の総合評価 - 72

あすけんアプリのレスポンスの悪さとリクエストの失敗率、金取っていい水準に達してないと思う(有料会員)。

ランチはてんやの『海かぜ天丼』にした。てんやの季節モノメニューにはあまり関心がなくて天丼や野菜天丼ばかり食べていたんだけど、『海かぜ天丼』(海かぜ天丼って何?)はエビもあおさも太刀魚もそれぞれの鮮烈な香りが感じられてかなり良かった。食べる意義があった。あおさが形態上衣が多く油っぽかったのは少し辛かったが…。

思い立ってマネーフォワードを見て出費の確認などしていた。普段はしない。独身男性なので。固定費ではやはり割引が切れたJCOMがキツい。NTTの設備があるのに配管の問題で使えないのはお前らがなんとか旋回!と管理会社に問い合わせているが返事がない。たぶん来ないだろう。水漏れの補償の話も来てないし。なあ大東建託。

…なんか面白い話を書こうとしていたんだが忘れちゃった。GitHub Copilot ProとかOpenRouterとかさくらのVPSとかも削れるっちゃ削れるだろうけど、一応技術で食ってるので一時の節約のために腕磨きを怠るのは本末転倒だよな〜。

20250429 IP fragmentation

項目 内容 得点 換算点
睡眠時間 5時間5分 23 3.0/13.0
起床 9:12 40 3.2/8.0
散歩 ノー 0 0.0/5.0
朝食の栄養カバレッジ 3色カバー 100 5.0/5.0
体操 ノー 0 0.0/5.0
労働 休日 100 24.0/24.0
ジム 有酸素+筋トレ 100 12.0/12.0
勉強会 ノー 0 0.0/12.0
個人開発 実施 100 7.0/7.0
あすけん - 72 6.5/9.0
総合 1日の総合評価 - 61

↑これのせいでOGPのdescriptionが意味ない内容になりがちだったのでちゃんと明示するようにしてみる。

遅く起きて朝食→ジム→ラーメン屋→買い物→帰宅→昼寝→個人開発→今

ジムで顔見知りの人と世間話をした。同じジムでも普段やることが違うといろいろ教わることがあって面白い。

なんとなく普段行かないラーメン屋に行きたくなって行ったら、定休日火曜という表示とともに中で客?と店員が和やかに談笑していて、(今日は休みで店員がまかない食べながら談笑してるのか…?)と思ったけど普通に営業してた。祝日だからかな。メニューが以前来たときから完全に変わっていて驚いた。デフォルトのトッピングがほぼ無な代わりに安いというモジュラー式電源みたいな構成になっていた。

楽しみ

休日と入っても特にやりたいことも行きたいところもないよなあ…と無気力決め込んでいたけどツイッターで友人がめちゃくちゃきれいな島の風景を上げていて俺も何かすればよかったなと少し悲しくなった。人生全部これ。段取り付けて準備してようやく得られる体験というものがあり、それをきちんと遂行できる人間と、最終的な体験は羨ましがるけど行動は起こせないで家で昼寝してる人間がいる。まあ風景が良いからなんだよとも思うが。

よく友人に付き合いが悪いとか遊ぼうとしないと言われる。人と会うのは好きなのだが、事実だ。昔から楽しむということが苦手だ。趣味もなんらかの形で自己研鑽につながるものじゃないとやる気にならない。100%enjoyの娯楽には罪の意識がある。ディズニーランドとか怖い。Dota2は対戦と上達という要素があるから楽しめるが、四川省はある程度は上達の要素もあるが結局配牌次第であり、あまりやる気が出ない。加えて初めてのことをやるのも億劫だ。まあこちらは「人生経験」「これも勉強」みたいな言い方をされれば割と簡単に乗り越えられる。ので僕に違法薬物を勧めないでください。でも誘われるのは嬉しいので何でも可。

ちなみにアニメの聖地巡礼旅行はかなり自由研究的要素があるので好きです。土地とストーリーと制作プロセスが重なって新しい発見が生まれてくるのはかなり楽しい。

最近はジメッとした内省的な話ばかりしていて嫌だね。ずっと睡眠が壊滅していてそのせいで気持ちが落ち込む。まあそれも含めての日記道だから。

IP fragmentation

パケットキャプチャの続きもやった。今日はIPパケットのfragmentationのことを考えていた。昔マスタリングTCP/IPを読んでいたときにはあまり実感していなかったけどIPパケットが下位レイヤのMTUの都合で自らを分割するのってちょっと違和感あるよね。まあこの辺りが教条的ではなく柔軟だったことがIPの広がりにプラスに働いたというのもあろうが。

IPヘッダのfragment offsetは13ビットの領域を割り当てられており、その表現は8ビット単位である。この説明はよく見られるのだが「8ビット単位って何?」という疑問が湧いた。13ビットで表現できる数値は2^13(8192)通りだ。つまりfragment offsetは8の倍数オクテットであって2^16までの数字しか表現できないということになる。そうなの?答えはYesだ。RFC791に明記されているとおり

そもそもIPデータグラムの最大長は65536オクテットなので2^16でちょうど足りる。

This format allows 2**13 = 8192 fragments of 8 octets each for a total of 65,536 octets. Note that this is consistent with the the datagram total length field (of course, the header is counted in the total length and not in the fragments).

そして分割は8オクテット単位でせねばならないと定められている。

The data of the long datagram is divided into two portions on a 8 octet (64 bit) boundary (the second portion might not be an integral multiple of 8 octets, but the first must be).

そう言えばもう一つ、Identificationも他の送信元と被ったら混線しない?と思ったんだけど、これは送信者IP・宛先IP・プロトコルも含めてユニークになるようにassembleせよと定められてたね。

To assemble the fragments of an internet datagram, an internet protocol module (for example at a destination host) combines internet datagrams that all have the same value for the four fields: identification, source, destination, and protocol.

Ethernetの仕様書は7000ページあった一方でIPは随分読みやすい。

20250425 チーズバーガー丼

項目 内容 得点 換算点
睡眠時間 3時間30分 0 0.0/13.0
起床 8:31 74 5.9/8.0
散歩 ノー 0 0.0/5.0
朝食の栄養カバレッジ 0色カバー 0 0.0/5.0
体操 ノー 0 0.0/5.0
労働 passion: 70点, discipline: 70点 70 16.8/24.0
ジム 休養日 100 12.0/12.0
勉強会 ノー 0 0.0/12.0
個人開発 ノー 0 0.0/7.0
あすけん - 45 4.0/9.0
総合 1日の総合評価 - 39

↑結構いろいろ改修した(させた)。今回はGemini2.5Pro。小規模アプリケーションだとめっちゃ賢いよ。ちゃんと.clinerulesに従うしpackage.jsonのコマンドも読める。まあコスト的にはハイエンド側だからね。コメントが過剰気味なのは変わってない。そう言えばYouTubeのある英語話者がジェミナイって読んでたけど、本人(?)に聞いたら発音はジェミニって言ってたな。


(世代がバレる)

夜眠れず、眠れないことにイラついて開き直って5時頃まで起きてた。健康も精神も全てが破滅している。

友人からのタレコミで松屋の新メニューチーズバーガー丼を食べた。美味いかまずいか以前に「普通にパンでバーガーにすれば良いのでは…?」という疑問が湧くほどには単にチーズバーガー。味の評価は米に酸味を合わせることをどう思うか次第。僕は若干懐疑(しかし改めて考えてみると酢飯・ケチャップライス・ケバブ・ドリア等は違和感なく食べてはいるな…)。シンプルに肉がデカいのは満足感がある。

休みが多い期間に入る。と言ってもカレンダー通りだが、憂鬱だ。休みは退屈で、休みを退屈にしてしまう自分の至らなさを思い知るのは辛いからだ。

基本的に僕はポイントカードアンチなのだが、ここに住み始めて結構長く、そろそろ近所のスーパーで使えるカードなら作ってもいいかなという気分になってきた。しかし僕は基本的にデジタル国粋主義者なので、GAFAにピンハネさせないでポイントカードを活用するためにはどういう方法がいいかなと考えている。

20250421 もう一人のボク

項目 内容 得点
睡眠時間 5時間0分 20
起床 6:30 100
散歩 ノー 0
朝食の栄養カバレッジ 3色カバー 100
体操 ノー 0
労働 した・passion: 75点, discipline: 80点 78
ジム 有酸素 100
勉強会 ノー 0
個人開発 実施 100
あすけん - 64
総合 1日の総合評価 59

入眠困難・眠い浅い・悪夢の三重苦。一応早起きした(してしまった)がその後も半覚醒でボーッとしていたのでゴミを捨てそこねた。

昼食は日高屋のW餃子定食。いつもながらあんまり美味しくない。なんならいつもあんまり美味しくなさすぎて思ったより美味しいまである。あすけんに入力するときキムチか唐揚げか選べるようにしてほしい。

神の気温。むしろ適温に近すぎるせいで日に当たると暑いし風が吹くと寒い。フィードバック処理なら平滑化を入れないと高速で服を着たり脱いだりし始めて他の行動ができなくなる。

最近は睡眠の不調を反映してか頭の動きが悪い。とっさに単語が出てこなかったり、複雑な仕組みをイメージするのに時間がかかったりする。元気もあまりない。年齢もあるだろうが、それよりも体調による短期的変動のほうがずっと大きい。

ふと思い立って自分の全ツイートと全日記をNotebookLMに突っ込んでみた。全然面白くなくて、あれこれ質問しても自分がもう知ってることを自分よりも曖昧で不正確な文章で返答してくるだけだった。

20250420 回転寿司/gpt-4.1-miniの印象/prismaでgroupBy

遅めに起きて布団カバーを洗濯した。また冬が終わったので毛布類をコインランドリーで洗った。待つ間にくら寿司で豪遊(1100円)。

回転寿司

回転寿司というのは、極みである。食事の進行中に1品ずつ注文を受けてオンデマンドで調理される自由度の高さ、それを支えるweb注文とコンベヤ輸送という温かみの欠片もない高度な技術によるオペレーション、射幸心を煽るびっくらぽん。揚げ物スイーツラーメンなんでもありの無文化性。そんなに美味しくない寿司、腹に貯まる米による満腹感。誰も触らないせいで回転レーンで干からびていく寿司(そしてそのせいで一層誰も触らなくなる)。

食べる分量が空腹である入店時には決まらないという性質上食べ過ぎにくいというのはなかなか良いところだと思う。

洗いたての毛布を持ち帰って神の昼寝。起きたら友人が麻雀で大負けしていた。

gpt-4.1-miniの印象

またいろんなLLMを試しながら個人開発。これ自分じゃメンドクセぇ〜って思うところはやっぱりLLMにも任せられないね。今日の感触としてはこんな感じ。

  • gemini2.5: やたらと作業ログをコメントで残す。やめろと言ってもやめない。diffツールの使い方が下手で何度もやり直し金ばかりかかる。触るなと言ったところを触る。
  • gpt-4.1-mini: 頭も記憶力も悪いが時間をかけて誘導すれば一応仕事はできる

僕は安くてそこそこ使えるやつに興味があり、その点ではgpt-4.1-miniは良い。claudeはお高くて使いづらいんだけど優秀であるということを痛感。gemini2.5は高いし評判も良かったけど使ってみたらそれほどでもなかった。

prismaでgroupBy

具体的にやった作業はprismaのクエリいじり。アニメの作品(work)とエピソード(episode)が一対多対応であるという前提で、ある条件を満たすようなepisodeを2つ以上持つworkを抽出したい。生SQL(を使えるprisma API)だと

const works = await prisma.$queryRaw`
  SELECT w.*
  FROM work w
  JOIN episode e ON e.work_id = w.id
  WHERE e.some_condition = true
  GROUP BY w.id
  HAVING COUNT(e.id) >= 2
`;

のようにwhere→group by→havingの流れで2回絞り込みを行うことで実現するらしいのだが、これをprismaに持っていくと

const works = await prisma.episode.groupBy({
  by: ['workId'],
  where: {
    some_condition: true,
  },
  _count: {
    workId: true,
  },
  having: {
    workId: {
      _count: {
        gte: 2,
      },
    },
  },
});

となり、返り値の型が { _count: { workId: number }, workId: number } になる。つまり SELECT w.* が再現されずworkIdしか取れない。

既知のissueとしてはこの辺りが近い話に思われるが、いずれも対応される雰囲気がない。
https://github.com/prisma/prisma/issues/24816
https://github.com/prisma/prisma/discussions/6517

まあしないだろうなという感覚もわかる。prismaはそもそも様々なデータベースを隠蔽する抽象化の役割も持っており、各データベースのある程度細かい機能に逐一対応するのは無理だ。TypeScriptとの堅固な統合が持ち味であることを考えれば難易度は一層高い。

ある程度複雑なクエリ、パフォーマンスチューニングが求められるクエリは生SQLのAPIを使ってくださいよということなのだろう。