IETFサテライトオフィスに行ってきた。登録人数40人だけど全日程参加しない人もいるため、20人くらいいたかな？もっといたかも。
月曜日。
サテライト会場だと感想が部屋の中で非公式に聞こえるからみんなの感想を聞こえるのが面白かった。
今回再度ミーティングにAIネタが大量にあるらしい。
dispatchはあまりIETFでやる必要がないものが多い。
mnotによってWell-Known URIsの問題提起があったけど、
こっちも途中から聞いてみた。Zooko's triangleの話とか。
むずかしい
wgとしての最初のMTGなのでgithubの使い方どうするかとかそうゆう話から。
PKI, Logs, And Tree Signatures (plants)
draft-ietf-plants-merkle-tree-certs-02 - Merkle Tree Certificates
めも （まじできちんとメモをとっていなかった。）
土日のハッカソンの時間でいろんな人と話してスライドの準備をした。
金曜日の夜の時点でTobias, Tomたちとあえてよかった、
Day0 (day-2かも) pic.twitter.com/ClZAObPfJi
— momoka (桃歌) (@momoka0122y) 2025年11月1日
土曜日にモントリオール名物のプティンを食べた。
Day1 pic.twitter.com/Qwo0adRPv0
— momoka (桃歌) (@momoka0122y) 2025年11月2日
ハッカソンの食事とても良い。
日曜日
Day2
— momoka (桃歌) (@momoka0122y) 2025年11月3日
近くのバー pic.twitter.com/QMT9sPblnI
ホテルの前にでっかいリングがあった。
また一年の振り返り
過去の
JANOG55に参加してました。京都はとても楽しかった。
研究室飲みをして、自分の同期の社会人一年目、M2,M1が参加した。ICTSCで大工大の繋がりすごいと思ったから、後輩とご飯いくだけでもしたいと思った。年末までにもう一回やりたい。
ICTSCの本戦がありました。自分は社会人運営として運営の手伝いをしました。学生と話せたのは楽しかったですね。写真を撮る仕事とtwitterの運営を当日してました。
選手の皆さんお疲れ様でした！
— ICTトラブルシューティングコンテスト (@icttoracon) 2025年3月16日
また来年度の #ICTSC でお会いしましょう！ pic.twitter.com/gIH3vuTCGY
社会人2年目になった。一年あっというまだった。
新しく会社に入社した新卒のことが知りたくてたまに会社で開催してるLT会をやったら新卒の子が3人発表してくれた。同期9人とその他の人合わせて合計16人もLT発表をしてくれて楽しかった。入社して7回もLT会を開催してた。
ICTSC キックオフ合宿 海はいいですね
GWは箱根に旅行に行っていた。
万博に行った。めっちゃ楽しかった。3日間かけて行った。たくさん見れてよかった。
KubeCon行った。めっちゃたくさんの人と話せて楽しかった。
KubeConきてる pic.twitter.com/pUl1zhEI3R
— momoka (桃歌) (@momoka0122y) 2025年6月16日
NotebookLMが出てておもしろーってなって自作ラジオをいくつか作って電車の中とかで聞いてた。
JANOG参加。今回初めてプログラム委員として参加。
やりたいことをさせてもらってとても楽しいJANOGだった。島根、鳥取も初めてだった。
JANOG楽しかったです！
— momoka (桃歌) (@momoka0122y) 2025年8月2日
声をかけていただいた皆さんありがとうございました！
100均でプランターと土とタネを買って二十日大根を栽培始めた
リベンジの2,3号
— momoka (桃歌) (@momoka0122y) 2025年9月18日
1号は新しい種植えたけどまたダメそう(土がダメそう。2,3号と別の土 pic.twitter.com/gw0TbOLUwT
yas-nyan先生の結婚式に参加してとても楽しい会だった。
結婚式後の二次会に新郎新婦がなかなか現れない理由がわかった
— yas-nyan (@yasnyannet) 2025年9月14日
二十日大根を収穫した。
— momoka (桃歌) (@momoka0122y) 2025年10月5日
今年も若手の会に行ってきた。（３年目）
IETFに行ってきました。（ブログを書いていない。。。）
２年ぶりに行って、久しぶりにIETFの知り合いと話せたのはすごいよかった。
先週のカナダ pic.twitter.com/qd193uQkZn
— momoka (桃歌) (@momoka0122y) 2025年11月15日
たくさん美味しいものを食べました。
PechaKuchaという非公式深夜LT会も楽しかった。
ドラフトの発表も無事やってLastCall通過しました。この話は詳しくblogに書きたい。
GSoC(Google Summer of Code)のJapan meetupに行ってきた！GSoCの歴代の参加者がいてたくさん参加者がいたんだなと実感できた。参加者の半数が仕事で日本に移住してきた外国人で、日本に外国人エンジニアの方ってたくさんいるんだなと思い知らされた。
同期が一人退職をした。これからどんどん一緒に仕事している人や、同期たちが退職するのを見るんだろうなというのを実感した。
まだ仕事ですごい関わりある人の退職は経験していないけど、最近会社で退職する人の数がとても多いので遅かれ早かれ別れを経験することになるのだろうなと思っている。
同期の数が多い会社に入社して新卒として結構のびのびいろんな知り合いを作れた気がする。みなさんお昼ご飯でも夜ご飯でも誘って欲しいです！
新卒で働いて２年目が終わりそうなの早いですね。
この前一人振り返り反省した時のメモ↓ 仕事を終わらせるのに時間がかかっていて難しいと感じる時が多いですね。
MTGやSlackで伝えたいことはなにかを考えて出す。
論理的になるように、根拠をもって、どこが推測でどこが事実でどこが自分の意見なのか。
伝えることを意識して文章・資料・図を組み立てる
関連性が薄い話はしない。（AIは余分な情報がなにかを教えてくれないので、読みやすい文章にするためにの削りは自分で考えないといけない。）
他のドキュメントをたくさん見て読んで真似る。文章の書き方は自分で一から考えるのではなく、他を真似る。（コードは既存のやつを真似て書いてるから同じように文章も真似る）
何が目的なのか考える。
どこが無駄で、どこが必要かは、目的が何かがきちんと明確になればわかるはず。
読み手の背景と暗黙知がなにかも考える。
必要なタスクの洗い出し。優先度付け
優先度の低いことに周囲の人の時間を巻き込まない。
読んだ本
全然本を読んでいなかったので毎年年末に行っているけど、積読を消化したい。
ここ一ヶ月は新たな趣味ををこっそり始めているけど、もしかしたらすぐ飽きるかもしれないし、続けるかもしれない。一年後も続けてたらこんなことをしてましたって言いたい。
今年はあまり本を読まなかったので（読み始めたやつはいくつかある）チームの勉強会で２冊だけ。
これが正解です！って言うのではなくビジネスや組織状況やトレードオフを見てどう考えれば良いかについての考え方を教えてくれる本。
各章にストーリーがあるのが特徴的でそれによって、アーキテクチャについて考えることは単純な技術的な話ではなく、他のチームや時間や要件など多くの要素が絡み合う人間的なものだと思わせてくれる。（ストーリの中で登場人物3人くらいが議論しているのを読むのは、アーキテクチャの議論において人によって考え方が違うのがすごいわかりやかった）
チームの勉強会では皆で一緒にこの本を読んで、自分たちでその章のテーマの改修を行おうと思った場合に、それぞれ、どう考えるかなどを話すきっかけになったので、一人で読むよりチームと一緒に読むとチームの年長者の経験を聞けていい本だなと思いました。
ソフトウェアアーキテクチャに絶対的な正解は存在しません。むしろ、さまざまな妥協点の中から選択を強いる難題、すなわち「ハードパーツ」が多く存在します。そのため、ソフトウェアアーキテクトには常にトレードオフを見極め、状況に合った選択をすることが求められます。本書は、読者が自身のアーキテクチャ上の難題に対して効果的なトレードオフ分析を行い、より良い決定ができるようにするための書籍です。
本書では、サービスの粒度やデータの所有権、コードの再利用やワークフローの調整、可用性や信頼性の実現といった現代のソフトウェアアーキテクチャの難題と、それに対するさまざまなアプローチやパターンを紹介します。そして意思決定を難しくするトレードオフについて、モノリスを分解しマイクロサービスアーキテクチャに再構築する例を通して詳しく説明します。
『ソフトウェアアーキテクチャの基礎』の著者らによる現代的なトレードオフ分析とその実践を学べる本書は、現代のソフトウェアアーキテクチャに関わるソフトウェア開発者にとって必携の一冊です。
一番最初に単体テストには古典派とロンドン学派の2つの流派があることの説明がされている。
古典派は1つの振る舞いに対してテストする。
ロンドン学は1つのクラスに対してテストを行う。
著者は古典派が好きな考え方をしている。ロンドン学派だと実装の詳細に対するテストになりやすいことを批判している。実装の詳細ではなく振る舞いをテストするべきと言う考え方。
Mocking戦略の違いとか。
過度に複雑なコードをテスト対象から除外し、単体テストをドメイン・モデルやアルゴリズムに集中させることで、テストスイートの価値が向上し、保守が容易になります。
ハードパーツで読んだ様々な致命的課題を解決するため分散マイクロシステムを行うと、ビジネスロジックが分離されて、お互いの依存が減るとビジネスロジックがシンプルになってテストもしやすくなる。
良いアーキテクチャであればテストもしやすいという "=>"の関係がある。
そういえば、これも読んでた。The Hunger Games のプロローグの２作目。よかったので読んで欲しい。新しい映画は2026に出るのかな？楽しみ。
@utam0k san の話
第58回 情報科学若手の会の招待講演の資料を公開しました。#wakate2025
— Toru Komatsu (@utam0k) 2025年10月11日
オープンソースソフトウェアへの解像度🔬https://t.co/qjgi1cIk8F
---
概要:…
youki (OCI Container Runtime in Rust) の話を題材に。
自作コンテナランタイムとして初めて発展して今。自作〇〇が大きく。
取り組みやすいgood first issueでなるほどと思ったのは、「コンフリクトが起きにくい」issueとか。
OSS貢献の連続性。メンテナが1つのOSSに対する活動で完結することは少ない。依存関係で繋がっている。
他のOSSとの関係ある問題を見る中でメンテナになることも。
「k8sからyoukiを使ったら壊れた」などの問い合わせの中でk8sのコードを見たりと隣のOSSのコードを見て、一から新規コントリビューターになることも。
どの時間帯がメンテナが活発な時間も大事。SIG-Scheduling は日本時間で夕方など。
なぜyoukiはバズったか？個人の勉強としてやったので大きくなるつもりはなかった。ちょうどruncの開発者が長く続いてきたことによる依存などで困っていたところでyoukiが出てきて、作り直すならRustと思われていたからちょうどよかった感じでタイミングがちょうどよかった。
社内の複数あるプロダクト全てに緊急の脆弱性がないかを確認するリクルートRED TEAM のはなし。
脆弱性を正しく理解して、各プロダクト開発者に正しい温度感で対応してもらう。
脆弱性が出た時にそれを正しく理解して、「どのような条件を満たす場合に何をすると何が起きるのか」のようにわかりやすい説明をする。
Dirty Pipe
書き込み権限がないはずのファイルを書き込みできる。/etc/passwd を書き換えることでログイン時のパスワードを不要にできる。
じぶりんさんの説明がとてもわかりやすかったのでもう一度資料を見直したい。
[SpeakerDeckへのリンクをあとで貼る]
ページキャッシュとかの話。
pipe_buffer の更新時に can_mergeの値が初期化されていなかった。
splice()で、ページ内の開始位置やデータ長を自由に指定して参照させられることを利用して、狙った位置からページキャッシュを参照させキャッシュの任意の位置を上書きできる。
社内の脆弱性の専門家として、社内のプロダクト開発者に対してわかりやすく説明することが大切という話を、実際にわかりやすい説明をすることで体感させてくれる発表で面白かった。
今日の情報科学若手の会の発表資料です
— kmuto |『先輩データサイエンティストからの指南書』（技術評論社） (@eycjur) 2025年10月11日
「理論と実務のギャップを超える 〜機械学習(生成AI)導入の実践知〜」#wakate2025 https://t.co/sXrMvzusCT
「成長中のプラットファオームに関わると歴史をなぞって学べて楽しい」
kateinoigakukun.hatenablog.com
Nixとは
一言だと「パッケージマネージャにMakefileがついたようなもの」
ビルドの設定を宣言的に記述できる。
再現性担保：ダウンロードしてきたもののsha256ハッシュ値書いておいて、確認。git commit hashなど確認
インストールされるソフトウェアの設定も（Nixがサポートされていれば）Nixからできる。
dotfile 公開のノリで設定がGitHubに公開されてるらしい。、GitHub で lang:Nix で検索してみればよさそう。いつか眺めてみよう。
https://github.com/search?q=lang%3ANix&type=repositories
An analysis of BGP convergence properties
論文に出てた経路交換が収束しない簡単な例のBAD GADGETを実際に組んでみてみたいと思った。
あれでも、論文の中だとBGPの経路選択を local preference, as-path, lowest nexthop の三つでやっててフルのBGP経路選択アルゴリズムではないか。
build-and-break-linux.keioaic.dev
情報科学若手の会で即席LTした資料
— lemolatoon (@lemolatoon1) 2025年10月13日
『スマホからYoutube Shortsを見られないようにする』https://t.co/b5DGRQdhen #wakate2025
https://dl.acm.org/doi/10.1145/3365199
2日目ハジマタ #wakate2025 pic.twitter.com/U69hHJX1pC
— Masaki Kuge (@kuge_masa) 2025年10月12日
System32 のファイルを消して起動しなくなるまでやる闇のゲーム始まった #wakate2025 pic.twitter.com/SI4yz7ATlM
— Masaki Kuge (@kuge_masa) 2025年10月11日
Windowsを壊していくゲーム、最終的には設定画面やゴミ箱とかも壊れていって面白かった
— kmuto |『先輩データサイエンティストからの指南書』（技術評論社） (@eycjur) 2025年10月11日
#wakate2025 pic.twitter.com/vSYrovk7id
自分のチームはいろいろ消したら、ブルースクリーンは出ないけど、真っ暗の画面のまま起動しない自体に。ブルースルクーンだと何のファイルを消したせいかちょっと書かれていて参考になったのに、ブルースクリーンにすら行かなかったのでなにを消した成果がわからなかった。
3日目の朝はちょっと早起きして周りを散歩した。キノコとか木がいっぱいあった。
軽井沢素敵すぎてカメラロールこれ
— ぽん (@maru65536_domo) 2025年10月13日
#wakate2025 pic.twitter.com/MHMPRrrBMa
キノコがいた
— momoka (桃歌) (@momoka0122y) 2025年10月12日
#wakate2025 pic.twitter.com/SrcwHLlnR8
去年と一昨年
JANOG56でプログラム委員として参加させていただいたのでメモ。
やったこと
JANOG slackのししおさんのコメントを引用
今回のJANOG56は下記に記載のある採点ポイント
https://www.janog.gr.jp/meeting/janog56/program-app/
1. 技術/運用の観点で日本のネットワークオペレータにとって有益か？
2. 議論のポイントが明確であるか？
3. 発表/議論を通して気づきや発見を得ることができるか？
およびその採点結果を元に(基本的に上位のプログラムから）最強のプログラム方式と言われる各プログラム委員がタイムテーブルを作成し、相互の投票により賛同者が多いもののタイムテーブルが採用されます。https://www.janog.gr.jp/meeting/janog37/newsletter/column-03.html
今回の応募プログラムは61件 応募があり、37件までが賛同者の多いタイムテーブルに使用されました。
これに追加で書くと今回はプログラム委員長(PC chair)が 2人とプログラム委員(PC)が14人います。
chair以外の14人がすべての応募プログラムに3つの採点ポイントに5点満点で点数をつけました。つまり一人15点満点で点数をそれぞれの応募プログラムにつけ、14人が採点を行ったので、210点満点で点数がそれぞれのプログラムにつけられました。
その点数でつけられた順位をもとに14人のPCがそれぞれタイムテーブルを作成しました。同じようなテーマは同じ時間にならないようになどの工夫をそれぞれの人が行いプレゼンを行いました。それぞれの発表を聞いた後にもっとも良いと思うタイムテーブルに投票を行って今回のタイムテーブルとプログラムが決定しました。
今回の応募プログラムは61件 応募があり、37件までがタイムテーブルに採用されました。
プログラムを採点していて、まだ新卒2年目でネットワークの知識が少ない自分が採点してて良いのだろうかと思うことはあったのですが、JANOG参加者がプログラム一覧を見て、それぞれのプログラムの概要を読んで見たいを思いそうな応募文はなにか考えながら3つの評価軸それぞれに5点満点で点数を入れていきました。
有益性 / 議論ポイントの明確さ/ 新発見 の三つの軸で応募文を採点し、他のPCの採点の点数をみるのは面白かったです。
同じ合計点を得た応募プログラムでも、有益性は高いけど議論ポイントが低いプログラムに対してその逆の配点をとっていたプログラムや、ほとんどの人が平均的な点数をつけたプログラムに対してPCによって高評価だったり低評価だったりと評価に偏りがあったプログラムなど
プログラムが決定したあとは、プログラム委員それぞれに担当プログラムが割り当てられました。それぞれのプログラム委員の担当したい気持ちを汲み取ってPC Chairが決めました。
自分は3プログラム割り当てられました。
それぞれに連絡をして、zoomでミーティングをしてプログラムの概要文が問題なさそうか？発表のあとどのような議論が起きて欲しいかなどの発表をしました。
事前資料や登壇資料をwebに掲載するなどもしました。
半年に一回開催されるJANOG
過去のプログラムを振り返るLTがあるといいなと思い企画しました。
去年読んだ。とても軽くて読みやすかった。（ほしい物リストで川上さんから頂いた）
綺麗なコードの書き方。一部「リーダブルコードって本ではこう書いてあったらしいけどこう思う」と書いてある箇所もあった。
久々に技術書を読み始めた たくさん本を頂いたからどんどん読んでいきたい
— momoka (@momoka.bsky.social) 2024-02-08T14:11:45.750Z
綺麗なコードの書き方を説明する中でこの説明はすごいわかりやすい文章化だなって思った。
— momoka (桃歌) (@momoka0122y) 2024年2月13日
“module’s functionality should reflect your current needs, but it’s interfaces should not. Instead, the interface should be general enough to support multiple uses.”
本にもっと具体的な例もある pic.twitter.com/x1QZGOUaTd
まとめスライド作ってる方がいた。
チームの勉強会で読んだ。4,5,6,10,13 章を読んだ。
とてもいい勉強になった。数ページでまとまっていて大きなスケールへ拡大する方法について考える機会になってよかった。
Table Of Contents
Chapter 1: Scale From Zero To Millions Of Users
Chapter 2: Back-of-the-envelope Estimation
Chapter 3: A Framework For System Design Interviews
Chapter 4: Design A Rate Limiter
Chapter 5: Design Consistent Hashing
Chapter 6: Design A Key-value Store
Chapter 7: Design A Unique Id Generator In Distributed Systems
Chapter 8: Design A Url Shortener
Chapter 9: Design A Web Crawler
Chapter 10: Design A Notification System
Chapter 11: Design A News Feed System
Chapter 12: Design A Chat System
Chapter 13: Design A Search Autocomplete System
Chapter 14: Design Youtube
Chapter 15: Design Google Drive
Linus Torvaldsさんの自伝。2002年出版。（ほしい物リストでむさしんさんから頂いた）
> As I read and started to understand Unix, I got a big enthusiastic jolt. Frankly, it’s never subsided. (I hope you can say the same about something.) 自伝を読むって自己啓発本みたいな感じだな(自己啓発本を読まないので知らないが) 「君も何かについて同じように言えるといいですね」ってね
— momoka (@momoka.bsky.social) 2025-02-13T00:23:52.058Z
116ページ ネットワークの機能を入れたから結構満足して突然バージョンを0.13から0.95まで飛ばしたら治さないといけないところが大量に出てきてでも1.00までの間の数字は少なくて大量のpatchナンバリングになってしまった話
— momoka (@momoka.bsky.social) 2025-02-25T03:04:10.255Z
123p TAしていた授業で「メールを送る」という課題を出した。1993年なのでメールは今みたいに当たり前ではない。 生徒のほとんどは当たり障りのないことをメールで送ってきたが、彼女は私をデートに誘った。 私は機械を介してアプローチしてくれた最初の女性と結婚した
— momoka (@momoka.bsky.social) 2025-02-25T03:22:13.046Z
Linusさん27歳になる前に第一子が生まれていて人生進むのが早い (自分が今26歳だからどの分野でも追いつけないと思ってしまった(笑)
— momoka (@momoka.bsky.social) 2025-02-28T09:38:36.501Z
Linuxが瞬く間に使われるようになった理由にライセンスは大きな理由だけど、他にその頃の特定用途向けOSがあったのに対して汎用的だったというにがある。 特定用途用に作られたOSよりWindowsの方が汎用性があってどんどんWindowsが使われるようになったのと同じようにLinuxはたくさん使われるようになった。 あと商用サポートする会社も現れたのが大事。IBMが入ってきて、OracleもLinuxで動かせるようになって企業が使わない理由が減っていった
— momoka (@momoka.bsky.social) 2025-03-03T00:58:29.410Z
1999年 Red Hat とそのあと VA LinuxのIPOでお金持ちに 初めは自分の元株分のお金というよりLinux自体の評価が市場からどうかという意味で心配していたが、そのあと値段が決まったらIPOを換金できるまでの半年が待ち遠しかった
— momoka (@momoka.bsky.social) 2025-03-04T00:40:16.090Z
