うなすけとあれこれ

2024年06月23日

高専DJ部は2024年5月で10周年を迎えました

#40の看板

高専DJ部とは

https://kosendj-bu.in

なりたち そもそも高専DJ部は高専カンファレンスという高専生を中心としたコミュニテからのスピンオフになります。もともとは音楽が好きな人達が「高専DJ部」という名前でFacebookにグループをつくっていて、それが2013年の4月5日とのことです (中略) というわけで初イベントは2014年5月31日でした。Facebookにグループをつくってから1年と少しでイベントをやるまでになりました。 高専DJ部について - 良いあそなすちゃん

これが高専DJ部のなりたちです。このときから、rooqさんを部長、asonasさんを顧問として、およそ2ヶ月おきに早稲田の茶箱で高専DJ部は開催されてきました。

僕が高専DJ部を知ったのは高専生の頃、たしかTwitterで流れてきのがきっかけで、東京で就職できたら行ってみたい、できればDJとして出てみたいなあと思ったものでした。

Ust待機 #kosendj

— うなすけ (高専DJ部#40 6/1) (@yu_suke1994) May 31, 2014

当時はUstreamで配信していたんですね。

そして僕は東京の会社に就職し、高専DJ部に現地参加できるようになりました。僕の初DJは高専DJ部第8回のことでした。

https://github.com/kosendj/kosendj-bu.in/blob/master/archive/08.yml

引き継ぎ

そして高専DJ部第8回からDJを始め、よほどのことがなければ毎回DJとして立候補を続けていました。

そんな折、asonasさんが多忙になるということでゆるやかに運営業の引き継ぎをはじめ、第19回以降は僕がオーガナイザーとしての取りまとめを行うようななりました。

その後、開催頻度が3ヶ月毎になったり、配信がTwitchになったりと細かな変更はありましたが、とうとう2024年6月1日の回で第40回かつ10周年を迎えることができました。

第40回では、僕がクラブミュージックを知る切っ掛けとなったKONAMIのBEMANIシリーズから、10年前の稼動シリーズであるbeatmania IIDX 22 PENDUALから中心に曲をチョイスしました。音ゲー君すぎましたね。

高専カンファレンス界隈に向けて

高専DJ部は、前述のように高専カンファレンスからスピンオフとして始まったクラブイベントです。そして10周年を迎えるわけですが、ひとつ課題があります。それは最近新入部員がめっきり減っていることです。そもそも認知すらされていないかもしれません。

ここ最近、コロナ禍で途絶えてた高専カンファレンスの開催がどんどん勢いを取り戻している様子を観測しています。

https://kosenconf.jp

そこで再度現役生や、卒業したばかりの元高専生に高専DJ部の存在を(再度)知ってもらおうと、僕が行ける範囲で参加して高専DJ部についての話ができればいいなと最近は考えています。

首都圏に在住していない方々には、無理に来てほしいとは思っていませんが、とりあえず知っていただけたら、よければ開催しているときにはTwitchでの配信を観ていただければと思います。もし興味があれば、Discordサーバーもあるので覗きに来てください。x.com/kosendj や x.com/yu_suke1994 に話しかけてもらうのでも大丈夫です。

そんなわけで、これからの高専DJ部もよろしくお願いします。

https://kosendj-bu.in

2024年06月23日
2024年05月30日

RubyKaigi 2024 参加記

はじめに

昨年は英語で書いたんですが、今年は発表できなかったので日本語で書きます。

登壇したかったニャンね

いや〜〜〜〜〜〜〜〜〜〜〜〜……はい。

特にしおいさん、いまいずみさんと僕はRubyKaigi Takeout 2021での初登壇以来、RubyKaigi 2023まで連続してacceptされていたので、勝手に同期みたいな仲間意識を感じていたのですが、今年は僕がnot acceptedとなり、ぐぅぅぅ……という感じです1。まあnot acceptedとなることに対しての納得はあるので、精進が必要、といったところですね。

トーク

まともに聞けているのがあまりない……以下箇条書きで感想を書いていきます。

コミュニケーション

やはり普段会えない人と会えるというのはとても貴重な機会でした。STORES CAFEでJeremyを独り占めしてOpenBSDのことを教えてもらったり2、いまいずみさんと英語トークの(自分なりの)準備のしかたについて話したり、RubyKaraokeで転岩を2回リクエストされたり、RubyMusicMixinでありたそと限界になったり……

#rubykaigi @yu_suke1994 pic.twitter.com/PRrRq86Lmj

— ima1zumi (@ima1zumi) May 17, 2024

RubyMusicMixin terfno撮影

#RubyKaigiNOC

昨年までは得に何も考えずにスケジュールを決めた結果、NOC完全撤収の前に帰ってしまうという(自分的)失態をしたので、今年はちゃんと最後の集荷のスケジュールに合わせて帰ることにしました。ので自分史上最も長くRubyKaigiの会場付近にいたことになります。これは来年も継続していきたいことのひとつです。

NOCの仕事としては、ネットワーク構築、発注したケーブルの巻き直し、当日のケーブル敷設、AP設置、会期中の運用、クソクイズ出題、そして撤収などなどなどがあります。このうち、僕が関われるケーブル巻き直し、敷設、設置、撤収については、特に今年はKMCからの若者が多数参加してくれたおかげで、会場作業については例年の比ではない速度で完了させることができました。本当に助かりました。

Today’s #rubykaigiNOC quiz deployed! #rubykaigi pic.twitter.com/nNG47iIDbZ

— osyoyu (@osyoyu) May 17, 2024

ところで皆さんはDay 0の準備中や、Day 4の撤収作業をDiscordで配信していたことにお気付きでしたか？

RubyKaigi Discordサーバのnetops VCでやってます（きてね）。 #rubykaigi #rubykaigiNOC https://t.co/aKfbTF6OSo https://t.co/A2gUzTlHLQ

— 花月かすみΛ__Λ (@k_hanazuki) May 18, 2024

Day 4は何人か聞きにきてくれたのを観測しています。来年どうなるかはわかりませんが、おもしろコンテンツとして聞きにきてくれたらいいかなと思います。

レジャー

完全撤収日まで滞在すると数日何も作業予定のない日が発生します。このタイミングで沖縄を満喫しました。

#rubyistsonwaves

おしょうゆという人がいます。僕は彼に「沖縄行くんだったら船舶免許取ったほうがいいよ」と背中を押され、取りました。

そして土曜日、海へ……

風も強くて波も高いけど最高！！！！！ #rubykaigi #rubyistsonwaves pic.twitter.com/eTayA3Z7J0

— なっちゃん (@pndcat) May 18, 2024

海に出たあとは戻ってバーベキューをしたりして、これは完全に “陽” だな……と改めて思います。

#rubyistsonwaves @yu_suke1994 pic.twitter.com/gLNOKnQgtb

— ねっけつ (@nekketsuuu) May 18, 2024

この日は海から帰った後、なはーとで少しNOCの撤収作業があったのでそりゃ夜にはこうなりますわな、という写真です。

pic.twitter.com/jiJtOt74sT

— そらは (@sora_h) May 18, 2024

ドライブ

果報バンタ(カフウバンタ)

それでもまだ数日の空きがあり、その日はKMCのメンバーで沖縄ドライブをしました。民泊でバーベキュー、美ら海水族館、植物園、辺戸岬、ダム見学、タコライス、24時間営業のmelonbooks……沖縄でやるレジャーっぽいことをそこそこやれて良かったです。

#rubykaigi pic.twitter.com/cnRTTBNbJi

— そらは (@sora_h) May 19, 2024

やっていくぞ

RubyKaigiが終わったら、Kaigi on Railsがやってくるわけです。Kaigi on Railsがんばりモードに切り替えて、やっていきます。

また、ふと思い付いた取り組みがあり、関係者には企みを話して「やろう」ということになったので、やっていきます。こういう話が顔を合わせてやれるのもRubyKaigiのいいところですね。

コミットしよ

  1. この気持ちはおふたりにぶつけ済 ↩

  2. Jeremyと話したかった人がいたらマジごめんという感じ ↩

2024年05月30日
2024年05月25日

技術書典16に出展します

3行で

本について

TLS 1.3のRFCを読んでいく本：キリンセル

詳しくは以前の記事、「C103の2日目(12/31)にTLS 1.3についての同人誌を頒布します」を参照していただきたいのですが、要はRFC 8446の日本語訳にちょっとした解説などが付いた本となっています。

物理在庫について

以前の記事でも書いたように、物理の在庫を売り切るまでは物理本の通販はしません。また、よっぽどのことがない限り物理本を再度印刷することもしません。物理は売り切ったらそこまでのつもりです。

また、後日公開予定1の電子版については、本当に本の内容のみ公開予定で、つまりナナメさんのイラストについては当日会場、または電子版を購入していただいた方のみの限定コンテンツとなります。(おまけポストカードはそれなりの数を用意したので、会場で売り切れとなった場合に余っていればお渡しします)

電子版について

本来、この本はPDFやEPUBなどの形式による頒布をするつもりはありませんでした。ですが技術書典ということで、電子版を用意しました。こちらの電子版にはナナメさんによる表紙絵とイラストが含まれています。(電子を用意するつもりがなかったのは、まずは物理の在庫をなくしてしまいたいので……本がぶ厚いんですよ！8mmあります！)

この電子版についても、可能であれば技術書典16終了後に頒布を停止する予定です。

取り置き制度(C103同様)

pixivFANBOXおよびGitHub Sponsorsで支援していただいている方に対しては、連絡をいただければ取り置きをさせていただきます。当日お渡しする際には支援していることの確認となるものを提示していただくかもしれません。準備をお願いします。詳しくは各プラットフォームからの連絡をご参照ください。なお、申し訳ありませんが支援金額を頒布価格から差し引くという対応はしません。まあそんな爆裂に売れていくなんてことはないと思いますが……

さいごに

TLS 1.3のRFCを読んでいく本：キリンセル

手ぶらで帰りたい！！！皆さんよろしくお願いします！！！！！「か 01」でお待ちしています。

  1. 本当は技術書典終了し次第公開したかったのですが、色々間に合わず……すみません ↩

2024年05月25日
2024年04月28日

ギターを買い、バンドを組み、ライブをしました。

撮影 HoliGrail

まさかこんなことになるとは

以前のブログ記事でも書いたように、バンドを組み、オリジナル曲「タワーマンの孤独」を含む3曲を演奏しました。まさかこんなことになるとは。

経緯

経緯についてはなぜか動画が公開されているので、そちらを見ていただくのでもいいです。なぜあるんだ？

というわけで、あそなすさんという方にめちゃくちゃ「バンドやろうぜ」という勧誘を受けていて、根負けしました。

勧誘の様子

ただ押し切られて嫌々始めたわけでもなく、昔から家族や友達など周囲に楽器を演奏できる人がおり、興味がなくはなかったことと、「How To Become A Hacker」に

なにか楽器を上手に演奏したり、歌が歌えるようになること。

とあることから、楽器を演奏できるようになることには憧れがありました。問題は初期費用とか、練習する時間が確保できるのかとか、そもそも練習しても全然弾けるようにならなかったらとかいう不安もありましたが……

というわけで背中を押され、ギターを買いました。

ギター購入時ログその1

ギター購入時ログその2

#今日のうなすけ pic.twitter.com/JajEw4JhvU

— 蜘蛛糸まな🕸️ / HolyGrail (@HolyGrail) October 8, 2023

ハネモノ

まず簡単な曲が弾けるようになろうということで、スピッツの「ハネモノ」を課題曲として課されました。

ハネモノ練習時の感想

これがそのままライブで披露する1曲目になりました。ハネモノを家で練習しながら、月に1回くらいのペースでスタジオに集まって練習をしていました。

転がる岩、君に朝が降る

その後、流れで次の曲はASIAN KUNG-FU GENERATIONの「転がる岩、君に朝が降る」にしようということに決まりました。これは確かスタジオ練習で決まったことなのでテキストのログがありません1。

オリジナル曲「タワーマンの孤独」

そして2曲目を決めたのと同じタイミングで、新曲をお願いして作ってもらおうということになりました。というのも、仲間内のDiscordでもともとChatGPTやSuno.aiを使った謎の曲がchiastoliteさんの手によって生み出されており、これをちゃんと編曲してもらったらいいんじゃないか、ということになったのです。

編曲は樫野創音さん (@kashino_tsukune)にお願いしました。

依頼したときのログ

快く引き受けてくださり、また素晴らしい曲に編曲していただき本当に感謝しています。この場を借りてお礼させていただきます。

編曲していただいたものをみんなで聞いたとき、本当に良い曲になっていて感動すると同時に、「これ、自分に演奏できるのか……？」と不安にもなりました。これが3月上旬のことです。

その後練習を重ね、なんとか弾けるようになり、ライブ本番を迎えます。

ライブ

最高 #ukfes pic.twitter.com/J81QChlMSF

— 蜘蛛糸まな🕸️ / HolyGrail (@HolyGrail) April 27, 2024

楽しかったです！！！！！！！

来ていただいた皆さん本当にありがとうございました。

そもそもライブで初お披露目となる曲でみんながノッてくれるのか、という不安がありましたが、冒頭の「Road to 1st LIVE うなばん！」を作成したjigsawさんにより歌詞のカラオケ表示があったおかげで、大盛況だった……と聞いています(演奏してるとそこまであまり気にする余裕がない)。本当にありがとうございました。

また、初ライブ&誕生日(誕生日ではありません)祝いということでなっちゃん(@pndcat)にケーキを頂きました。ありがとうございました。美味しかったです。

#ukfes pic.twitter.com/gTxpxkvRVI

— 蜘蛛糸まな🕸️ / HolyGrail (@HolyGrail) April 27, 2024

こうしてみると、バンドメンバーはもちろんそうですが、それ以外にもたくさんの方々が関わってくれていることがわかります。とても大きな感謝の気持ちと、ちょっぴりの「あなたたちのせいですからね」という両方の気持ちがあります。これからもよろしくお願いします。

初ライブめちゃくちゃ楽しかったです！！！！！！！ #ukfes

— うなすけ (@yu_suke1994) April 27, 2024

ただ反省点は多くて、まずは主体性を獲得したいと思います #ukfes

— うなすけ (@yu_suke1994) April 27, 2024

あと、ぼざろ観ます #ukfes

— うなすけ (@yu_suke1994) April 27, 2024

次回

ukfesはまた開催されるということもあり、2度目のライブに向けてまた演奏できる曲を増やしたりなんだりやっていくつもりです。がんばります。

  1. 関係者向け おそらく2023年12月23日の練習録画 52:30からの会話 ↩

2024年04月28日
2024年04月02日

バンドを組んでフェスに出ることになったので大岡山に来てください

要約

来てくれ！！！！！！！！！！！！！！！！！

バンド結成しました

#今日のうなすけ pic.twitter.com/JajEw4JhvU

— 蜘蛛糸まな🕸️ / HolyGrail (@HolyGrail) October 8, 2023

めちゃくちゃ勧誘されたので、ギターを買ってバンドを組むことにしました。メンバーは以下です。

バンド名は「うなばん！」です。ホントに？いい名前が思い浮かんだら変わるかもしれません。

「新曲」？

初ライブでオリジナルの新曲があるの正気か？と思うんですが、あるのでしょうがないです。この新曲についてはライブが終わったあとに書こうと思っているふりかえりで色々書くつもりでいます。曲はめちゃくちゃカッコイイので気になってる人はぜひukfesに来てください！！！！！！！！！！！

2024年04月02日
2024年03月31日

IETF 119 Brisbaneにリモート参加しました

IETF 119 Brisbane

IETF Meeting参加シリーズも4回目、リモート参加シリーズだと3回目になりますね。2024年3月のIETF Meeting 119はオーストラリアのブリスベンで開催されました。TZはUTC+10なので日本からリモート参加しやすかったです。

オーストラリアといえばカンガルーということで、参加者向けメーリングリストでは「カンガルーに遭遇した場合はどうすればいい？Internet Draftの共著者にならないか誘うべき？」などの会話が行われていました1。

参加したセッション

前述したとおりブリスベンのTZはUTC+10なので、各種ミーティングがUTC+9の時間で生活している自分にとっては人道的な時間に開催されるのは助かりました。ただ、それはつまり日々の仕事などの日常生活とバッティングするということでもあり、どのみちフルで参加することはできませんでした。

あとやっぱりリスニングは壊滅的でした。本当にわからない。

それでは以下、常体です。

Media Over QUIC (moq)

Agenda

https://datatracker.ietf.org/meeting/119/session/moq

Readout from Hackathon

MoQの6つある(？)実装のうち、5つはversion 3(draft-ietf-moq-transport-03)に対応したとのこと。具体的にどの実装が、みたいな情報が見あたらないけど……

Subscribe and Fetch (draft-ietf-moq-transport)

SUBSCRIBE が送信されるとき、実際には何が送信されるのか、subscriptionの重複が存在する場合にオブジェクトが何度送信されるかが不定、などなどの不明瞭および不正な点がissueとして挙げられていて、それを解消するために FETCH という仕組みを提案するもの。

Fetch is a “StateFul” request, finds out about “non-available objects” in that range.

と述べられている。

そんなわけで今はここで議論が進められているのかな？

Split SUBSCRIBE into SUBSCRIBE and FETCH by ianswett · Pull Request #421 · moq-wg/moq-transport

draft-ietf-moq-transport

で、それとは別にdraft-ietf-moq-transport-03でのupdateの報告。いくつかのメッセージがmerge、追加されたり、曖昧な部分の明確化が行われた。今後の課題としては前述のSubscribeの問題の他に、Transmission、Object Model Details、Handshakeがあるとのこと。

draft-mzanaty-moq-loc-03

CMAFに代わるメディアフォーマットであるLOC(Low Overhead Container)を標準化するもの。WebCodecベースで、CMAFよりもオーバーヘッドが小さい。

03でなんとMLSの仕組みを利用したE2EEへの参照が追加されたり、Audio/Video共に様々なパラメータや拡張が追加された。

“Separate packaging container format from MOQ Streaming Format?” に関して意見が分かれていたようだ。

draft-wilaw-moq-catalogformat

catalogのupdateにJSON Patchを使うようになったり、トラック名が相対的に、名前空間を継承するようになったりする変更がmergeされている。今openなものとしてIANAにcatalog fieldsを登録したり、trackに共通するfiledsを持てるroot objectを追加したりなどがある。

Call for Adoptionということは近いうちにWG draftになるのかな。

WARP draft Update (draft-law-moq-warpstreamingformat)

https://datatracker.ietf.org/doc/draft-law-moq-warpstreamingformat/

話されてた？議事録にも特に詳細がないので新しいtopicはなかったのかも。

Transport Issues (draft-ietf-moq-transport)

そしてMoQ Transportのissueについての議論。このへんちょっと議題の認識がごっちゃになってるかもしれない。GroupおよびTrackが終了するのはいつか、優先順位はどうするか、みたいな議論がもりあがっていた。次のIETF Meetingまでにinterim meetingをやろうという意見が投票多数。

Lessons from implementation

https://datatracker.ietf.org/meeting/119/materials/slides-119-moq-simulcast-video-delivery-learnings-01

サイマルキャスト、優先度、輻輳制御について。回線状況が不安定な場合の挙動について色々課題が出てきていて、FECについての研究やmoq WG以外のWGと連携することも提案されている？(BBRv3の改善とか)。

Bandwidth measurement in MOQ

https://datatracker.ietf.org/meeting/119/materials/slides-119-moq-bandwidth-measurement-for-quic-00 (pptxです)

様々な映像ソースを使って帯域測定をした結果とのこと。Özyeğin University(なんて読むんだ、トルコのオジェギン大学？)の方からの発表。

帯域幅測定はクライアント側で行うことが可能。共有だけで特に議論とかはなかった……のかな？(録画を見てるけどたぶんない)

MoQ Secure Objects

MoQでE2EEをやるための仕組みの提案。CMAFのほうにはCommon Encryption(cenc)というのがあるんだけど、それの代替というわけではなく、Low overhead containerのほうでcenc的なことを実現するためのもの(そのまま使うことができないので)。

新しい暗号を導入するのではなく既存のHKDFとAEADを使う。MLSやLOCとのeasy integraionを目指している。"Why focus on low bandwidth" に “Lyria is a 3kbps audio codec. Newer ML codecs are use even less bandwidth.”(原文ママ) とあって、Lyra、あったな～～～となった。

Lyra V2 - a better, faster, and more versatile speech codec | Google Open Source Blog

質問でCGM-SSTなるものに言及があったけど、これだろうか。

https://datatracker.ietf.org/doc/draft-mattsson-cfrg-aes-gcm-sst/

そして内容がよく聞きとれなかったけど、議事録には “Maybe use GCM-SST? (Sure)” とあるのでこれを使うということ？

WebTransport (webtrans)

もともとQUICに興味を持ち始めたきっかけがWebTransportだったのに、このWGを追うのを忘れていたな～、と。

Agenda

W3C WebTransport Update

WebTransportに関わる標準化はIETFとW3Cの両方で進められていて、W3CのほうはWeb browser APIとかを担当している(という理解をしている)。

W3CのほうでのWebTransportは、6月にAPIを安定させ、8月には複数の実装が存在している状態を予定しているっぽい？

めちゃくちゃ長い名前のオプションが追加されてる。

現時点でSafariのみが未実装。 https://caniuse.com/mdn-api_webtransport

draft-ietf-webtrans-http2

118から 08が出て、CLOSE_WEBTRANSPORT_SESSIONとDRAIN_WEBTRANSPORT_SESSIONがHTTP/3のほうから追加されたり、いくかのcapsuleがrenameされて短くなった。

draft-ietf-webtrans-http3

https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/

https://datatracker.ietf.org/doc/draft-ietf-quic-reliable-stream-reset/ への参照が追加されたり。Flow controlについてどうするかの議論がさかんだったかな？ただinterimは予定されなかった。

QUIC (quic)

masque wgも追いかけたほうがいいのかなという気持ちもありつつ、もういっぱいいっぱいなので……

Agenda

FECについては発表だけ、Accurate ECNは時間切れになりました。

QLOG (draft-ietf-quic-qlog-h3-events)

Dune: Part Two観てないんですけど、観たほうがいいですかね。

118以降、QPACK関連のイベントが削除されたり、イベント名がちょっと変わったり、Multipathのサポートが入ったりした。今年末にはWGLCしたい、という雰囲気？

もっとMoQ wgと連携していこう(あとでメールしてほしい)、という話が出た。

Multipath QUIC (draft-ietf-quic-multipath)

Path IDをどうするか、interopの結果がどうだったかなど。Path IDについては292で提案されているExplicitなものと現在の06とのPros/Consがそれぞれ挙げられている。MPTCPというのがあるのか。

retire CID on all pathsについては賛否が分かれたのかな？

Ack Frequency (draft-ietf-quic-ack-frequency)

いくつかの文章と変更と明確化、特に対応せずcloseしたものなど、前回からの変更についての報告。

2度目のWGLCを119が終わったあとにしたい。

QUIC security considerations

https://datatracker.ietf.org/meeting/119/materials/slides-119-quic-honeybadger-and-his-friend-the-mongoose-00

QUICに対するリソース枯渇攻撃についての共有。HTTP/2 Rapid Reset Attachに似ている？QUICサーバー側のactiveconnectionidlimitを越えてNEWCONNECTION_IDをはちゃめちゃに送りつけるという攻撃、なのだろうか。

https://seemann.io/posts/2024-03-19-exploiting-quics-connection-id-management/

この記事に詳しく記載されている。

QUIC on Streams (draft-kazuho-quic-quic-on-streams)

新キャラ。TCPとUDPでの二面待ちをしたり、新しい概念が導入されたときにTCPとUDPの両方に対応する必要があったりするので、TCP上でQUICを話せるようにしようというもの。QUIC on Streamsはあくまでもfallbackであって、TCPで発生し、QUICが解決したHOLBの問題はこっちでも頑張って解消しようとはしていない。……で、あってるのかなあ。

スケジュールだと5分という話だったけどまあ5分で終わるはずがなく。どっちかというとQUICを推し進めていくほうがいいのでは？という反対意見のほうが多かった……のか？

BDP frame (draft-kuhn-quic-bdpframe-extension)

BDPは"Bandwidth Delay Product"の略。輻輳制御に関するパラメータを両者間でやりとりして、Careful Resumeを実現するもの。もしかしたらCCWGでやることになるかも？QUIC WGがこれを進めていくかについては賛否が分かれた。

Transport Layer Security (tls)

Agenda

8446bis/8447bis

Chairのところで止まっていて、報告されているエラッタを処理しなければいけない。なんかエラッタを草案のコメントとして使ってる人がいて？全部closeになるかも、という話をしていたかも。

ECH Update (draft-ietf-tls-esni)

Encryptred Client Helloになってからも、Encrypted Server Name Indication時代の名残で draft-ietf-tls-esni なの、混乱しますよね。

これも今月いっぱいはIn WGLCという報告。

Registry Update

https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-tls-registry-updates-00

IANAの人からの報告。rejectされたrequestはなし。Extensionがいくつか増える(スライドにあるのは4つ)。ALPNも作業中のものがCoAPの表記について？

TLS Hybrid Key Exchange (draft-ietf-tls-hybrid-design)

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

大幅には変わっていないが、Hybrid Groupsの数が2つに削減された( X25519Kyber768Draft00 と SecP256r1Kyber768Draft00 )。FIPSの認証と、共有鍵と合体させる(？)方法についてが残っている問題。

“Chrome announced today they are going to release an experimental version.” って言ってて、どれだよ……となっている。

一番「それっぽい」のはDev channel 2023-03-16の 124.0.6356.6のリリース(上の2つめのリンク)で、"Enable PostQuantumKyber by default on desktop" っていうcommitが入ってる。でもこれAndroid……？3つめのリンクはそのcommitに関連付けられているChromiumのissue trackerにおけるチケット。diffの中身も「っぽい」んだよな。Firefoxのほうは “Firefox is shipping in nightly currently.” とのことで。https://bugzilla.mozilla.org/show_bug.cgi?id=1871629 から辿れそうだけど具体的なcommitまではわからなかった。

TLS Obsolete Key Exchange (draft-ietf-tls-deprecate-obsolete-kex)

これ、 In WG Last CallになってるけどExpiredっていうStatusはアリなのか？(chairの作業で止まってる、とスライドにはある)

FFDHEについて、TLS 1.2では Discouragedに、TLS 1.3ではNot recommended(議事録ではOKとしか書いてないけど、でもrecommendedではないでしょう)となることになりそう。

Static DH Client Certificatesについても非推奨とされる流れ？

TLS Formal Analysis

https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-formal-analysis-triage-panel-00

個人的には今回のTLS WGのミーティングで最も盛り上がった議題だと思う。8773bisがlast callするにあたり、いくつかのWGのメンバーから「その変更に対するformal analysis(形式的分析)が行なわれていない」という意見があったらしい。

つまりTriage panelを置き、TLS 1.3の標準に変更が入る際にはtriage panelに連絡し、そこで正式にformal analysisを行うかどうか判断するようにしようという提案っぽい。

“Not just Tamarin” というのは標準化界隈でよく使われる(らしい)セキュリテイプロトコルの検証ツールとのこと。

https://tamarin-prover.com/

で、not justなのでTamarinに限らず様々なツール、手法で検証をしようじゃないか、という。

賛成の声が多い感じ。学生を巻き込みたいという意見もあった。

Super Jumbo Record Limit (draft-mattsson-tls-super-jumbo-record-limit)

SUPER JUMBO

TLSのrecord size limitを RFC 8449にて定められている2^14 バイトから 2^16 バイトまで拡張できるようにするもの。データセンターで有益という意見。性能指標についてどうなるのか、という疑問点が挙げられ、今後識者と協力してやっていく、ということに。

mTLS FLag (draft-jhoyla-req-mtls-flag)

クローラー、Botが「自分は真正なクライアントですよ、ほら証明書がありますよ」をサーバーに知らせるためにmTLS readlyであることを送る仕組み。

実はもうここ https://tls-flags.research.cloudflare.com/ で動いている。CとGoでの実装もあるみたいだけど資料には記載がない。でもGoは多分これ https://github.com/cloudflare/go/pull/151

“I would like to see enthusiasm.” ということは、もっと協力なニーズがないと厳しいのか？

Extended Key Update (draft-tschofenig-tls-extended-key-update)

長生きなTLS connectionにおいての鍵更新をなんとかしたいという話。TLS 1.2での再ネゴシエーションが脆弱であるということでTLS 1.3では削除されている仕組み。(ラムダノートさんの「プロフェッショナルTLS＆PKI改題第2版」では「8.1 安全でない再ネゴシエーション」として記載があります)

これが、通信インフラやIoT機器などのコネクションが長生きする場面において通信内容をよりセキュアにするために有用であるという提案。仕組みではpost-quantumでも使われるKEMを使う？RFC 9180を参照するとのこと。

設計が複雑になるのでは？という議論になった感じだろうか。

ML-KEM for TLS 1.3 (draft-connolly-tls-mlkem-key-agreement)

耐量子での鍵確立をやるってことですね。Named Groupに mlkem768(0x0768) と mlkem1024(0x1024) を足す。ていうか、耐量子暗号って7年前には既に提案されていたんですね(早すぎるのでは？というFAQ)。

hybridでやるべきでは？という意見、RFCではなくコードポイントの定義だけでいいという意見、強く支持するという意見、これはひどいアイデアだという意見などなどなどがあり、一体どうなっちゃうの～～？

まとめ

むずかしいですね。mls、httpbis、httpapi、ccwgについてもまとめたかったんですが、ギブです。

  1. https://mailarchive.ietf.org/arch/msg/119attendees/JFhD7Oqm4dRjB4YwzxzXJDMbYUU/ ↩

2024年03月31日
2024年02月25日

楽々静的HTTPサーバーことpocke/wwwのv3.0.0をリリースしました

楽々静的HTTPサーバーことpocke/wwwとは

これらをご覧ください。ちょこちょこpull reqを投げていたらコミット権をもらえた1ので気付いたときに触っています。

タイトルでは「v3.0.0をリリースしました」と言っていますが、その前段階で v2.0.3 をリリースしているので、ついでにそれにも触れていきます。

v2.0.3

この変更で行なったのは以下の2つです。

Windows版buildの配布を追加

僕はたまにWindows環境でwwwを使いたいことがあったのですが、リポジトリのreleaseにはLinuxとDarwin(macos)向けのビルド済みバイナリしか存在しませんでした。GoなのでWindows版バイナリを用意するのは簡単ですが、用意されているほうがありがたいですよね。

wwwはリリース作業にGoReleaserを使用しているので、.goreleaser.yaml を用意してWindowsをtargetにしてやるだけで対応完了です。

ちなみにpull requestは1年以上放置していました。よくない。

deprecatedとなったioutil.ReadFile の削除

エディタでmain.goを開いたときに気付いたのですが、内部で使用しているioutil.ReadFileがdeprecaredとなり警告が発生していました。

これは単純に os.ReadFile に置き換えるだけで対応完了です。

v2.1.0

HTTPSへの対応を追加しました。

HTTPS対応

これについては、himanoaさんのこの発言を見たのが対応のきっかけです。

そんなわけで、 --cert と --key に証明書のpathをそれぞれ指定することでhttpsによるリクエストを送ることができるようになりました。このoptionは、両方を指定しないとエラーになるようにしています。

まとめ

CHANGELOG.mdとかあったほうがいいのかな、という気もしてきましたが……そこまででもないかな？とにかく、pocke/wwwは便利なのでよろしくお願いします。

  1. 結構昔のことなので経緯はうろ覚えです。勝手にリリースしちゃったけどいいのかな…… ↩

2024年02月25日
2024年01月28日

RubyKaigi 2024の予習をしに沖縄に行ってきた

予習

「RubyKaigi 2024に向けて泡盛を予習しておきたい」ということになり、今月頭に沖縄に行ってきました。

写真

以下、様子です。

でっっかいシーサー。焼き物らしくて、どうやって焼いたのかとても気になる。

ソーキそば……ではなく沖縄そば。美味しかった。

RUBY TUESDAY

RubyKaigi 2024の会場でもあるなはーと。公共施設なので中にも入れたけど、この日はイベントをやっていて自由に見回ることはできず。というかこの1週間後？にRubyKaigiチームの下見会があって、タイミングが絶妙だった。

いわゆるスパムおにぎりことポーク玉子おむすび。玉子感があまりなくて、ツナのほうを食べてみたかったが旅行中に2度目の機会がなく、5月までおあずけ。

特徴的な外観で有名な那覇市役所 本庁舎。さすがに中には入らなかった。

全然「軽食」が出てこない「軽食の店 ルビー」。晩ご飯をここで食べました。

今回の旅のメイン目的でもある泡盛の予習。人々が高速に酩酊していく。ここ外だったんだけど、寒すぎてヤバかった。運ばれてきた料理も高速に冷めていく。

海です

世界文化遺産である斎場御嶽(せーふぁうたき)。とってもおごそか。

海2です

北谷にある「エメラルド オーシャンサイド」のステーキ。これがとっても美味しかった。

まーじで美味しかった……

美ら海水族の年表に登場するリン子どん。リン子どん、美ら海水族のあらゆる場所に出てきてかわいいけど知名度がないっぽくて悲しい……pixivでも全然描かれていなかった。誰も知らない！

美ら海水族の一番でかい水槽、で泳ぐジンベエザメのジンタ

海3です。これは瀬底島。全然人がいなくて、シーズン外なんだな～というのを実感できた。

知見

2024年01月28日
2023年12月24日

C103の2日目(12/31)にTLS 1.3についての同人誌を頒布します

お品書き

3行で

本について

コミックマーケット103 2日目(12/31) 東ヘ17a 「キリンセル」ブースにおいて、「TLS 1.3のRFCを読んでいく本」を頒布します。この本は、Rubyアソシエーション開発助成2022において、aiortc/aioquicをRubyに移植する際の経験をもとに書くことにしたものです。

aioquicには、TLSの実装が含まれています。そのTLSのPython実装をRubyに移植する際になかなかうまくいかず、RFCや実装とにらめっこをするなどの苦労をしたので、TLSのRFCを日本語で解説してくれる資料がないだろうかと思い、書くことにしました。

もちろん既に日本語訳を公開されていらっしゃる方もおられますが1、やはり自分でイチから写経しないといかんなということで本にしてまとめようと思った次第です。

とはいえあまりに文書量が多く、わかりやすくまとめなおすというのは時間的に無理で、ほとんど日本語訳の形になってしました。それでもRFCには記載のない参考資料へのリンクを追加したり、言い回しをやさしくしたり語句の簡単な解説を足したりと、単なる翻訳ではないような本になるようにしたつもりではあります。

この本については、いずれインターネット上で誰でも読めるような形式で公開するつもりです。その際はMITライセンスやCCライセンスなどの、何らかの自由に利用可能なライセンスを適用します。なので、本当に今すぐ読みたい、何らかの理由でお金を払って読みたいという方でない限り、当日お越しいただく必要はないかもしれません。

そうなってしまうと結局RFC 8446を日本語にしただけじゃないか、ということになるので、ナナメさんにお願いして表紙絵とイラスト数点をお願いしました。これは後々公開予定の文書には含まれず、物理本を購入していただいた方限定のお楽しみコンテンツとなる予定です。当日お買いあげいただいた方には、表紙絵のみを印刷したものもおまけとしてお渡しします。

頒布数についてですが、50部を印刷しました。ただし全部を今回のコミケで頒布するつもりはなく2、次回の技術書典でも(もしかしたらその前にRubyKaigi 2024でも)頒布したいと考えており、それぞれで半々ずつくらいで頒布することを考えています。また次回の技術書典で在庫が余るまでは通販もしません。単純に在庫を抱えたくない&発送作業をしたくないという怠惰のアレです。

で、現在「¥?,???」となっている頒布価格についてですが、まだ印刷所からの連絡がなく3決めきれないでいます(決まったら記事およびお品書きを更新します)。ただ、¥3,000～¥4,000くらいにはなるんじゃないかなと見ています。利益を出そうとは思っていませんが、そもそもページ数が多いので印刷費がかさみそうです。

見本

見本はコミケWebカタログで確認することができます。

キリンセル | Comike Web Catalog

取り置き制度

pixivFANBOXおよびGitHub Sponsorsで支援していただいている方に対しては、連絡をいただければ取り置きをさせていただきます。当日お渡しする際には支援していることの確認となるものを提示していただくかもしれません。準備をお願いします。詳しくは各プラットフォームからの連絡をご参照ください。なお、申し訳ありませんが支援金額を頒布価格から差し引くという対応はしません。まあそんな爆裂に売れていくなんてことはないと思いますが……

最後に、再度コミケWebカタログにおけるキリンセルの詳細ページを貼っておきます。

キリンセル | Comike Web Catalog

追記 2023-12-29

頒布価格を決定しました。1部¥3,500です。お品書きも更新しています。

なお、すっかり言及を忘れていたんですが、同日東パ03bにて頒布される「桐生あんずファンブック」にて、「Rubyistワカモノ組座談会」で僕が話した内容が本になっています。こちらもよろしくお願いします。

【C103 2日目東パ03b「ひやおろし」】
桐生あんずという一般女性について、友人同僚先輩同輩教育係に保護者と様々な視点から語った結果10万字を超えた本です。サンプルは引用先をご覧ください。

なお、本人は中身を知りません。
#評論情報系同人誌告知 #C103 #C103新刊 https://t.co/TKFHNldP2Q pic.twitter.com/XEJ5xGNdjY

— 炬燵（kotatsu） (@sakahukamaki) December 28, 2023

  1. https://tex2e.github.io/rfc-translater/html/rfc8446.html ↩

  2. そもそも見本誌提出とかお世話になった方に配るとかもありますし。 ↩

  3. 入稿データのOKは頂いており、なので印刷はされるはずです…… ↩

2023年12月24日
2023年12月18日

サーバーサイドエンジニアとして2023年に使った技術と来年の目標

使用したプログラミング言語統計

4年目

今年は契約先が変わったのですが、新規契約先を探しているときに、「こういうのがあると非常に助かる」という声を頂いたので今年もやっていきます。

これまではこんな感じでした。

例によって冒頭の画像はwakatimeによる2023年1月1日から12月18日までのプログラミング言語使用率です。2位のOtherですが、内訳を見てみるとRBSやqlogやHamlやJsonnetでした。ReasonとなってるのはReasonでなく、Re:VIEWの .re がそう判定されているようです。(この統計には仕事で触れた言語は含まれていません)

立場(毎年同様)

フリーランスで、主にRailsやAWSを使用しているサービスの運用、開発に関わっています。いくつもの会社を見てきた訳ではなく、数社に深く関わっている都合上、視野が狭いかもしれません。

今年も仕事の成果として公表できるものはありませんでした。仕事ではありませんが、Kaigi on Rails 2023で使っていただいたconference-appはその大部分を書きました。

https://github.com/kaigionrails/conference-app

利用した技術一覧

昨年からのDiffとしては、Goは触った記憶がないので削除しました。TypeScriptとJavaScriptを併記していますが、conference-appのためにStimulusを書いた都合上、TypeScriptよりもJavaScriptを書いた比率のほうが大きいと思います。

Python

昨年と比較して一番変化のある部分だと思います。これは明らかにRubyアソシエーション開発助成2022によるものです。とにかくPythonのQUIC実装をRubyに移植するという作業をしていました。とはいってもPythonを “書いた” ではなく “読んだ” というほうが正しいですね。DjangoやFlaskでWebアプリが書けるようになったとか、そういうわけではありません。

QUIC/TLS

Python同様、イチから移植することで理解が深まったもののひとつです。昨年はここがQUICという表記でしたが、今年は明確にTLSを追加しました。実装の移植で行き詰まりRFC 8446 (TLS 1.3)を何度も読みました。

この活動がきっかけで1、今年3月からIETFに参加しはじめました。これ今年からなんですね……もう3回参加してるのでもっと前からのような気さえしてきます。

日本国外での開催に現地参加するかどうかは……ちょっと悩んでいます。お金がないというのもありますが、まだまだ英語のリスニングが甘いからというのも大きな理由です。

conference-app

Kaigi on Rails 2023で皆さんに使っていただいたものです。これのおかげで、今年触った技術としてCloudflare、Stimulus、PWAを追加することができました。その後様々な方からのcontributeで、RBS(特にRailsに導入するもの)についてもちょっとわかるようになってきた、かもしれません。

来年頑張りたいこと

Ruby/QUIC/TLS

今年はGrantでの移植以降、TLS 1.3をちゃんと学び直さないといけないと思い RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 をアタマから読み直したり、日本語にしたりしていました。

RFCは、仕様として書かれているのでそういうものかもしれませんが、特にRFC 8446は読みづらかったです。後の章で解説される概念が冒頭で出てくることが何度もあるので、そのままの順序で読むと理解に苦労します。ということで、実装する立場でもうすこしわかりやすいものがあれば、と思いそれらしいものを書いている途中です。

そもそものQUIC実装にしても、RubyKaigi Takeout 2021からもう2年も経ってるのに……という状態であり、来年こそは何らかの成果を出したいところではあります。が、どうなることでしょうね。どうしても趣味でやっていることなので取れる時間が少ないのと、コミュニティ活動もあるのでなかなか進みが遅いですが、頑張りたいです。

QUIC実装、特にaioquicの移植としてそれなりの規模のコードを書いた感想としては、RBSはやっぱりあると便利ですね。なのでOtherが2位に上がってきたのだと思います。個人でgemを書くことがあれば、積極的にRBSは書いていこうと考えています。

Kaigi on Rails

コミュニティ活動の筆頭と言えます。これは運営チームのみ見える形で「こんなことがしたい」というのを書いていて、それをやっていきたいですね。Proposalも……出せたらいいですね……

今年は初めてのin-person開催となりましたが、運営側からもそうですし、参加していただいた皆さんからも、成長する余地があることは感じられたかと思います。やっていかねば、いけませんね。

C/Rust/Zig

昨年から何もできていないですね。本当に何もできていない。無です。多分来年もあんまりここに割ける時間はないんじゃないかと思いますが、気持ちだけはあります。本当です。

Pythonと同様に書くまではいかなくても、QUICやTLSの実装の参考として読むことは多いのではないかと考えてはいます。

English

昨年、以下のようなことを書きました。

あと海外カンファレンスにProposalを出せたらいいなとか考えていますが、果たして。

こちらは、出すには出したのですがRejectになってしまいました。

一方で、RubyKaigi 2023での登壇は英語でやることにし、その登壇記も英語で書きました(DeepLにおんぶにだっこではありますが)。

RubyKaigi 2023 participation report

RubyKaigiにおいて英語で話すことの一番のメリットは、同時通訳さんとの打ち合わせのために資料を事前に提出しなくてよくなることです。その代わり、発表練習は日本語で話すとき以上にみっちりやる必要がありますが。ただ、RubyKaigiの僕の発表資料作成は、まず話すことを文章にしたうえでスライドを作っていくというスタイルなので、この点は偶然にもうまくいっています。

そしてIETFに参加するようになり、例年以上に英語に触れる、特にリスニングの時間が増えているのを感じます、が、それに英語力の上達がついていっていない……どうしたものでしょうね。

  1. 116が横浜で開催されたという偶然もけっこう大きな要因ではあります ↩

2023年12月18日
古い投稿