うなすけとあれこれ

2023年11月19日

IETF 118 Pragueにリモート参加しました

IETF 118 Prague

チェコの首都、プラハで開催されたIETF 118にリモートで参加したので、自分なりにまとめます。ただ今回、RubyWorld Conference 2023と日程が被ってしまったため、Meetecho(ライブで会議が行われる場所、Zoomの部屋みたいなイメージ)にはあまり入れずにYouTubeのアーカイブと議事録からのまとめとなります。英語の議論についていけないのでどのみちそうなるのですが……

写真はIETFとは全く関係ない、RubyWorld Conference 2023開催地である島根県は宍道湖の写真です。

例によって正確性の保証は一切いたしません。

参加したセッション

QUIC

https://datatracker.ietf.org/group/quic/about/

Media Over QUIC (moq)

https://datatracker.ietf.org/group/moq/about/

今回もMedia Over QUICのSessionは2回ありました。議論の内容がメディア転送をやっていないとわからないようなものになってきて、いよいよ追うのに限界を感じています。

Transport Layer Security (tls)

https://datatracker.ietf.org/group/tls/about/

Messaging Layer Security (mls)

https://datatracker.ietf.org/group/mls/about/

RFC 9420: The Messaging Layer Security (MLS) Protocol が7月にRFCになったばかりですが、draft-ietf-mls-architecture-11がRFCになってくれたら、というかdraft-ietf-mls-extensions-03も結構重要な要素なので、要するにまだこれからという雰囲気を勝手に感じています。

そしてどちらかというとリソースがmimi(More Instant Messaging Interoperability)のほうに割かれてるのではないかということらしいです。しかしmimiのほうは追えておらず……

なんというか、mimiと合わせて見ていかないとだめそうです。

Congestion Control Working Group (ccwg)

https://datatracker.ietf.org/group/ccwg/about/

Building Blocks for HTTP APIs (httpapi)

https://datatracker.ietf.org/group/httpapi/about/

HTTP (httpbis)

https://datatracker.ietf.org/group/httpbis/about/

まとめ

むずかしいですね。

2023年11月19日
2023年11月03日

Kaigi on Rails 2023 運営記

感謝

Kaigi on Rails 2023に参加していただいたみなさま、ありがとうございました。初のオフライン、オンラインのハイブリッド開催となりましたが、登壇者の皆様、Proposalを出してくださった皆様、協賛してくださった企業の皆様、そして一般参加者の皆様のご協力のおかげで無事に今年のKaigi on Rails 2023を終えることができました。

主役は参加者のみなさまということもあり、運営のひとりである僕からのふりかえりは手短かにしようと思います。

conference-app

もともと会場でのサイネージの役割としてのなにかを用意したいよね、という構想はあったので運営内でのみ使うWeb appを作るつもりではいたのですが、大倉さんがドーンと rails new をしたリポジトリが爆誕したのでそこに乗っかることにしました。お披露目クオリティに達したのが本当にギリギリだった1こともあり、イベント開催までの周知が全くできておらず当日にアクセスが集中して軽い障害が発生したのは本当に申し訳ないと思っています。でもこれで来年はもっと多くの人が使ってくれそうで嬉しいです。いくつか追加機能のアイデアも頂いています。

これについては他で話すネタになりそうなこともあり、あまり詳細な言及は控えます。とはいえソースは公開されているので何をやったかは全て見れる状況ですね。ドキュメントが少なすぎるのは追々なんとかします……

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

配信

今年も昨年に引き続き配信関連の担当をしました。とはいっても今回は会場側に配信をやってくれるプランがあるので、それをお願いしました。なので当日は僕自身がなにか操作するということはありませんでした。

会期中は、配信に登壇されている方の姿や声がちゃんと乗っているかの確認のため、YouTubeを2窓して両方の発表を聞く、ということをしていました。冒頭の画像はそのために用意したディスプレイを置いていた、スタッフルームにおける僕の机の写真です。持っててよかったモバイルディスプレイ。ちなみに、手前にあるダンボール箱2つは、直前に僕が買ってきてもらうように頼んだChromebookです。

急にPC必要になって買いに行ったり、荷物が配送遅延で届いてなくてお買物行ったり、Day0からいらいろありましたがなんとかなった（たぶん）のでよかった。明日の起床がんばらねば。まずは風呂🛀

— ぷぽ (@pupupopo88) October 26, 2023

実際に配信のプロの方と組んでなにかをやる、ということは初めての経験だったのでとても勉強になりましたし、楽しかったです。

趣味 スティンガートランジション再び

今年はオフライン開催ということでそこまでしている時間がなさそうな気配があったため、配信のトランジションについては何もするつもりがありませんでした。しかしアイデアが降ってきた&やってみたら案外時間をかけずに作れたために今年も作ってしまいました。これって会場で流れたんでしょうか？もしかしたら配信限定コンテンツだったかもしれません。

果たしていつまで作り続けられるでしょうね。

Next

クロージングでもアナウンスがありましたが、2024年の開催は決定していますが現時点で会場がまだ決まっていません。やばいですね。

  1. レビューしたいと言っていた大倉さんを途中からは完全に無視してCI pass即mergeを連発していました。よろしくないですね。 ↩

2023年11月03日
2023年10月01日

おもいで

クックパッドという会社は、Rubyのコミュニティに関わっている僕にとっては特別な印象がありました。今でこそShopifyやGitHubにその座を譲っているでしょうが、世界最大級のRailsによるモノリシックなアプリケーションによるサービス提供、フルタイムRubyコミッターの登用、優秀なメンバー、技術ブログの豊富なアウトプット……いつだって「いつかこんな会社で働きたい」という会社のうちのひとつでした。

クックパッドが横浜に移転するタイミングで、多くの人が退職していくのを外から眺めていました。その勢いに、このままではいつか一緒に働きたいと思っていた人達がいなくなってしまうと思い、(以前から手が足りていないのでどうですか、という声はかけていただいていた)あそなすさんに連絡をとり、業務委託の立場で関わることになりました。

色々なことをやりました。事業に関わることはどこまで書いていいのかがわからないのであまり触れませんが、新規サービスの立ち上げ、Ruby及びRailsのアップデート、「さわるだけで開発期間が3倍になる優れモノ」とまで言われた1レシピサービス本体への機能追加などを覚えています。

事業に関わらないことでいえば、社内フェスでのDJ、チキチキ、データ指向アプリケーションデザインの読書会、Rubyに関する社内勉強会、そしてRubyKaigi。事業もそうでない部分も、本当に楽しかったです。

一方でいいニュースばかりではなく、度重なる事業の見直しやそれに伴なう人員整理が行われ、その度に寂しい思いで一緒に仕事をした方を見送ることが続きました。

そしてとうとう自分の番も来た、というだけのことです。まあ業務委託の立場で退職推奨に対して「自分の番」というのもおかしな話ですが、とにかく契約の解除ということになりました。僕は撤退作業の手伝いという形で9月末まで稼動していました。稼動初期に立ち上げから深く関わったサービスのクローズ作業をするのは感慨深かったです。

実は、RubyKaigiが終わった直後から、様々な条件付きで正社員として入る交渉をしていました。この交渉は本当に人員整理の直前までやっていたのですが、しかしまあ、白紙になりましたね。この条件に関しては、業務委託で稼動し続けた実績によって交渉していたものなので、そのまますぐ別の会社にこの条件でどうですか、ということはできません。なので本当に、残念な思いです。

職選びの観点で言うなら、たぶん自分はPythonやGoやJavaScriptの案件でもなんとか生活できるくらいのお金はいただけると思っています。それでもRubyの会社を選び続けるのは、Rubyでサービスを開発・運用し、コミュニティに投資している会社であれば、自分がRubyKaigiやKaigi on Railsのために使う時間のことを考慮してくれる(そのことで急に休みを入れることに理解がある)、そういうことへの理解があるからです。その点で、フルタイムRubyコミッタを抱えていたクックパッドは本当にいい会社でした。

個人的な気持ちの問題はどうあれ、クックパッドのサービスと会社のことは引き続き応援しています。残っているメンバーもまた優秀な人達ばかりなので、心配はしていません。

なお、次の稼動についてのお誘いに関しては不要です。

以上、個人の日記でした。

  1. モダンBFFを活用した既存APIサーバーの再構築 - クックパッド開発者ブログ ↩

2023年10月01日
2023年09月08日

一時的にTwitterアカウントにログインできなくなっていた

TL;DL

9/30 14時から開催の高専DJ部 #38 に来てください！！！

高専DJ部 #38、 9/30にやります！！！14時から茶箱です！！！！TwiPla登録お願いします！！！！僕は翌日から仕事がありません！！！！ #kosendj https://t.co/cwtjZhtnoR pic.twitter.com/4WOwcXkXMp

— うなすけ(9/30は高専DJ部だぞ) (@yu_suke1994) September 7, 2023

ことの経緯

上記、高専DJ部の告知を行うために @kosendj にログインし、ユーザー名を変更した後に「あなたが実在の人物であることを確認する必要があります。」という表示になりました。

image.png (29.6 kB)

そして画像認証を行うのですが……これが何回やっても全然終わらない！！！！

延々と認証させれている様子

15分くらい格闘して一旦あきらめ、@yu_suke1994アカウントのほうで上記ツイートを行いました。そしたら同様の状態に……

ただ、どちらのアカウントも地道に認証をやっていたら突破できました。よかったですね。

あやしいと思っている点

どちらの場合も共通しているのは、「https://kosendj-bu.inのURLをツイートしたこと」です。あとハッシュタグでしょうか。いや、これが本当の原因かどうかはわかりませんが……

というわけで

何かあったら僕はこのあたりにいます。というか、最近は発言の主軸は自分の立てているMastodonに移しているつもりでいます。

コレクション

追記 (2023-09-08 08:50)

たぶんこれですね。

9/7現在、X(旧Twitter)にて名前／プロフィール変更をするとアカウント認証に飛ばされ認証通過しても「技術的な問題が発生したため」とログイン出来なくなるバグが発生中 - Togetter

2023年09月08日
2023年08月27日

CloudNative Days Fukuoka 2023とRubyKaigi 2023 follow upのこと

CloudNative Days Fukuoka 2023とRubyKaigi 2023 follow up

8/3のCloudNative Days Fukuoka 2023(以下CNDF2023)と8/23のRubyKaigi 2023 follow upで発表しました。

どちらも、自分が取り組んでいるQUICに関連する話をしてきました。

「パブリッククラウドにおけるQUIC現状確認2023年8月編」

CNDF2023においては、静的WebサイトとNginxなどのWebサーバーの2つの軸に対し、Public Cloud、特にAWSとGoogle CloudにおいてQUICでの運用が可能かどうかについての発表を行いました。

CNDF2023

また、発表内で紹介した構成については、TerraformやWebサイトの構成をGitHubで公開しています。

半月ほどしか運用していませんでしたが、コスト削減を真面目にやっていなかったこともあり、AWS側で$122(¥17,000程度)、Google Cloud側で¥1,100ほどの費用がかかりました。

AWSのコスト

Google Cloudのコスト

また、懇親会でのLT大会において、直前に開催されたIETF 117 San Franciscoで自分が聞いていたセッションで触れられていたdraftについて一言で説明していくという発表もさせていただきました。これについては発表資料はありませんが、IETF 117 San Franciscoの参加記でより詳細に記事にしています。

「RubyishなQUIC実装の進捗について」

RubyKaigi 2023 follow upでは、自分が取り組んでいるRubyishなQUIC実装についての進捗報告を行いました。

RubyKaigi 2023 followup

IETFやCNDF2023、Kaigi on Rails 2023の準備もありなかなかめぼしい進捗が出せていませんが、来年のRubyKaigi 2024でもproposalを出せるような成果を出せるようがんばりたいです。

余談 WebTransportについて

以下の記載において、間違い等あれば訂正したいので気軽に言及してください。

RubyKaigi 2023 follow upの会場で、「WebTransportはTCPの上にもQUIC(HTTP/3)の上にも展開されるのに、そこでリアルタイム性の求められる通信を行うのは、TCP及びQUICの欠損制御が邪魔になるのではないか？」という質問を頂いたのですが、その場で回答できなかったので調べました。

そもそもTCPと比較した際のQUICの優位点として、複数のstreamを使用することによるHead-of-line blocking(HOLB)の回避が挙げられます。WebTransport over HTTP/2ではこのstreamの独立をサポートしていません。また、続く “Partial Reliability” では、"HTTP/2 retransmits any lost data.“ とあるように、欠損したデータは全て再送されます(バッファリングできない分はdropすることが許可されます)。

Stream Independence: WebTransport over HTTP/2 does not support stream independence, as HTTP/2 inherently has head-of-line blocking.

Partial Reliability: WebTransport over HTTP/2 does not support partial reliability, as HTTP/2 retransmits any lost data. This means that any datagrams sent via WebTransport over HTTP/2 will be retransmitted regardless of the preference of the application. The receiver is permitted to drop them, however, if it is unable to buffer them. https://www.ietf.org/archive/id/draft-ietf-webtrans-http2-06.html#name-transport-properties

そして、WebTransport over HTTP/3 (https://www.ietf.org/archive/id/draft-ietf-webtrans-http3-07.html) では、このような欠損については特に言及されていません。

そもそも、draft-ietf-webtrans-overview-05 (The WebTransport Protocol Framework)にもhttps://www.w3.org/TR/webtransport/にも、WebTransportが"low-latency"を目的として生まれた技術であるとは書かれていません。(正確には、Head-of-line blockingによって生じるlatencyを避ける必要がある、という記述はありますし、またWebSocketはlatency-sensitive applicationsには向いていないという記載もあります1)

では真にlow-latency性を求める通信はどのように行うべきかというと、今まで通りに素のUDPやWebRTCを使ったり、RTP over QUIC (RoQ)2の登場を待つ、ということになるのかなあ……ちょっとわかりません。ただ言えることとしては、RFC 9002 QUIC Loss Detection and Congestion Controlにおいて、QUICがその欠損制御を無効化するような仕組みは定義されていないということです。

なので結論としては、QUICの欠損制御がWebTransportの通信において邪魔になるのかどうかという点については、QUICが複数のStreamによる通信によってHOLBを回避することで高速な通信を行うことができる、ということになると思います。

多分そういうことになるんじゃないかと考えていますが、間違い等あれば訂正したいので気軽に言及してください。

  1. https://www.ietf.org/archive/id/draft-ietf-webtrans-overview-05.html#name-background ↩

  2. https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over-quic/ ↩

2023年08月27日
2023年08月27日

IETF 117 San Franciscoにリモート参加しました

IETF 117 San Francisco

https://datatracker.ietf.org/meeting/117/proceedings

7/22から7/28まで開催されていたIETF 117 San Franciscoに日本からリモートで参加しました。前回のIETF 116 Yokohamaの開催後、ISOC日本支部によって開催されたIETF116報告会において、参加した感想を発表させていただきました。

isocjp-ietf-116-report

その発表内で「参加記を書こう！」と宣言したのもあり、こうして117の参加記を書いています。なるべく今後も参加記は書いていこうと考えています。

参加したセッション

以下で言及するWGについては、基本的にはsessionの部屋に入って議論を聞いてはいましたが、ここでまとめ直すにあたっては基本的には議事録を参考にして書いています。英語のリスニングスキルがポンコツなので……

QUIC

https://datatracker.ietf.org/meeting/117/session/quic/

quic wgにおいては、前回の116 Yokohama以降の大きな出来事といえば RFC 9369 QUIC Version 2 が出たことでしょうか。

Media over QUIC (moq)

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

moqはQUICを用いたメディア転送に関するプロトコル、Media over QUICを策定するためのworking groupです。今議論されているのはMedia over QUICそのものの仕様をどうするか、という点ですね。まだmoq wgからRFCは出ていません。116もそうでしたが、moqはセッションが2回ありました。なぜなんでしょうか。

draftを読んだりミーティングを聞いたりして感じたことは、やはりメディア転送についての知識が必要になるなということです。本当に難しい。別に他のWGの内容が簡単で理解できるという訳ではありませんが。

Transport Layer Security (tls)

https://datatracker.ietf.org/meeting/117/session/tls/

TLS WGにおいて前回からの大きなUpdateといえば、個人的にはdraft-rsalz-tls-tls12-frozen-01がでてきたことでしょか。

Messaging Layer Security (mls)

https://datatracker.ietf.org/meeting/117/session/mls/

E2EEなメッセージのやりとりをどうするかについてのWGです。

Congestion Control Working Group (ccwg)

https://datatracker.ietf.org/meeting/117/session/ccwg/

ccwgは輻輳制御に関するworking groupです。もともとcongressという名前だったのが、ccwgに改名されました1。

Building Blocks for HTTP APIs (httpapi)

https://datatracker.ietf.org/wg/httpapi/documents/

普段はこのWGの動向は追っていないのですが、 Kaigi on Rails 2021でohbaryeさんが発表してくださった「Safe Retry with Idempotency-Key Header」で紹介されている draft-ietf-httpapi-idempotency-key-header がagendaにあったので参加しました。これは一度expiredになってしまったのですが、つい最近03が公開されて再度activeに戻っています。

まとめ

むずかしいですね。

  1. https://mailarchive.ietf.org/arch/msg/congress/rHNowIkEJt8SZy4PkUYzAt2c0nw/ congressという単語よりccwgのほうがclearだというのは、確かにそうですね。 ↩

2023年08月27日
2023年07月03日

Kaigi on RailsにProposalを送ろうと思っている皆さんへ

これを書いているのは誰か

私はうなすけといい、Kaigi on Railsのオーガナイザー、つまり運営チームの一員です。Kaigi on Railsにおいては、運営に関わる全員がProposalを評価し、その結果から採択・非採択を決定します。なので僕は皆さんから送られてくるProposalを読み、評価をするメンバーのうちのひとりです。

この記事の目的は何か

昨年のKaigi on Rails 2022において、皆さんから多くのProposalを提出していただき、大変ありがたく思っております。2023年も引き続きKaigi on Railsを開催できること、皆さんからの Proposalを受け取れることを喜ばしく思います。

さて、昨年頂いたProposalを見ていて、「このテーマはとても興味があるんだけど、書かれてる内容からは採択できないな」と言えるような、惜しいものがいくつかありました。そこで、皆さんには、運営が(というか私が)送られてきたProposalをどのように見ているのかということについて書いていきます。

おこがましいお願いではありますが、Proposalを書こうとしている皆さんにはこれから書くことについて少し頭に入れておいてもらえればと思っています。

前提として、Kaigi on Railsは匿名レビュー

RubyKaigiとは異なり、Kaigi on Railsでは匿名レビュー、つまり 「Proposalの提出者が誰なのかを見ずに評価を行う」 のです。これを忘れないでいただきたいのです。

ただし、厳格ではありません。どういうことかというと、Proposalの内容に明らかに個人が特定できる要素、例えば「私はRailsの作者であり、ルマン24時間耐久レースに出場したことがあります」のようなことが書いてあったり、個人ブログや個人リポジトリへのURLが記載されていても、そのことによってリジェクトすることはありません。あなたが誰であるか、という情報は極力含めないでいただけるとありがたいですが、どうしようもない事情によって徹底することができないことも私達はわかっているつもりです。

abstract(概要)もそうだけど、details(詳細)を書いてほしい

abstract(概要)には、実際に公式Webページのタイムテーブルに掲載されるトークの概要を記入していただくこともあり、ここが書かれていなかったProposalはありませんでした。

ですが、悲しいことにdetails(詳細)にほとんどなにも書かれていないことによって、評価のしようがないProposalが2022年には数件ありました。detailsには、あなたが一体どのようなトークをすることができるのか(するつもりなのか)、ということを書いていただきたいのです。ここが書かれていないと、私達運営は、それを採択することによって参加者の皆さんが知見を得られるのかどうかが判断できないのです。あなたは、実際には非常に価値のあることを職場で、もしくはプライベートで成されているのかもしれません。そして当事者にとっては、終わってみれば割と自明なことに思えてしまいますが、第三者にとってはそうではありません。その取り組みの内容を具体的に書いていただかないことには、第三者である運営の我々が知ることは不可能です。是非、detailsを書いてください。

pitch(ピッチ)は最後のひと押しとなる

あなたが提出してくれたProposalと、ほとんど同じ内容のものを別の人が提出してきたとします。その場合、もちろんabstract、detailsは評価の対象となりますが、そこで甲乙付け難いと運営が判断したら、pitchによって判断することになります。結果として同じ内容の発表になろうと、そこに至るまでの経験や想いについては、かならずあなたにしかない何かがあるはずです。

まとめ

この記事では、通過するproposalを書くための作文術(どのように書くか)ではなく、「どんなことを書くか」をいちレビュワーの視点から解説したつもりです。ここまでに書いたことについて少し気にしてほしいという想いはありますが、どうか過剰に気にすることなく、どんどんProposalをお送りいただければと思います。

https://kaigionrails.org/2023/cfp/

追記

2023年07月03日
2023年06月29日

最近はpixivFANBOXにInternet-Draftを読んだ感想を書いています

流れてきたfeedの様子

TL;DR

https://unasuke.fanbox.cc/tags/IETF

いきさつ

IETF Meetingに参加してから、QUIC WGやTLS WGの動向を追っておきたいなという気持ちになりました。

やりかたとスタンス

どうやって追っているかというと、RSS feedを購読しています。具体的には以下のfeedを、MonitoRSSを使ってDiscordに流しています。

そして更新が流れてきたタイミングで、内容を読んで思ったことを1〜2文程度で書き、pixivFANBOXに支援者限定で公開します。

このとき書く内容については単純に思ったことを書くのみで、技術的に正確だったり、なにかの学びになったりする内容にしようとはしていません。理由はそれが負担になって続けられなくなるのを避けるためです。これはRails及びMastodonにおいても同様です。

毎月末に、その月の投稿を1つにまとめて全体公開で再度投稿します。例えば5月は次のようになりました。

https://unasuke.fanbox.cc/posts/6073778

(5月まではDNS関連のdnsopとdpriveも追っていましたが、流量が多く負担が大きいのでやめました)

2023年06月29日
2023年05月17日

RubyKaigi 2023 participation report

https://slide.rabbit-shocker.org/authors/unasuke/rubykaigi-2023/

As the Ruby Association Grant 2022 final report

As I wrote in last year’s participation (JA), I applied for the Ruby Association Grant 2022. As a result, it was accepted and I was able to complete the port of aioquic to some extent.

I think this presentation was a little early final report. I am a little concerned about whether or not I will apply for the Grant again this year, but I will think about it again when the time comes. This is because, after all, time constraints are unmanageable. It is true that it makes a deadline, and I can certainly make progress with the help of my mentor, but I have no choice but to devote my personal time to writing the code. I felt that if I cannot generate the time to do this as a job, I will not be able to continue. However, I wondered if any company would invest in the QUIC implementation of Pure Ruby, which is not suitable for production use. I have not been able to approach companies because I am worried about this, or rather, I have not been able to come up with an answer to this question.

As a member of #RubyKaigiNOC

unasuke dropped fiber

“unasuke dropped”

I have been helping with the RubyKaigi network for the past few years. This year again, as a member of #RubyKaigiNOC, I mainly helped with L1.

#rubykaigi #rubykaigiNOC 台数チェックをするうなすけの様子です pic.twitter.com/WqZpi1bEoV

— そらは (@sora_h) May 15, 2023

Sorah, who is the organizer of the RubyKaigi and NOC boss, is a very busy person. Therefore, this year I decided to take some of her tasks away from her. But as a result, other NOC members including her, helped me. However, thanks to that, I was able to gain knowledge about fluentd. I had never written a fluentd configuration before. The book “fluentd実践入門” written by tagomoris was very helpful in doing this task, and I got him to sign the book for me on #authorsrb.

It’s time to collect stamps at the venue of #rubykaigi2023 ! - Rubyist Book Authors Stamp Rally #authorsrb｜やきとりい

I’m very pleased to provide the Internet to all RubyKaigi attendees. I hope to provide the same experience in Kaigi on Rails which is the conference about Ruby on Rails in Japan as one of an organizer of that either. But it’s a very hard thing in this year I thought.

As a DJ of RubyMusicMixin2023

Continuing from last year, I had the opportunity to DJ at a RubyMusicMixin2023 organized by pixiv. After a great Kaigi, it is a great time to dance to the music also.

#RubyMusicMixin #RubyMusicMixin2023

NICEDJでオタクの語彙が「懐かしい」と「ヤバイ」になり、NICE VJで人は踊る pic.twitter.com/AOxrgr2T7C

— 炬燵は首輪を買い足した (@sakahukamaki) May 14, 2023

Challenges

2、そして3。https://t.co/0XDpjsJgQi pic.twitter.com/EIz0X4Zsa5

— うなすけ (@yu_suke1994) March 5, 2023

1. Write Codes, 2. Receiving and sending in English (as a lingua franca), 3. Show Your Presence at International Conferences – by kakutani

The most difficult part of this year’s RubyKaigi was speaking in English. I think I did a little bit about “1. Write Codes” in “Developing the Ruby Ecosystem,” as Kakutani-san mentioned. On the other hand, I did nothing about 2 and 3.

However, DeepL and ChatGPT have recently allowed us to empower English language skills. I may still be powerless in face-to-face conversations, but in one-way speaking situations where I have to prepare a script in advance or writing, they help me a lot. (Also, I wrote this blog in English and Japanese too!) In fact, for my presentation, I first wrote a script in Japanese, had it translated into English by DeepL, and then adjusted the English text to suit my English skill. (I spoke a little Japanese. I apologize.)

About the future

As I mentioned in my talk, I’m trying to create my own QUIC implementation based on my porting knowledge. In doing so, I’m reading RFC 8446 and draft-ietf-tls-rfc8446bis, although this is a bit of a detour. Because, during the porting process, I was trying to rewrite the existing Python implementation in Ruby in its original form, and not much thought was given to the TLS 1.3 specification itself.

See you at the next RubyKaigi, Okinawa.

Ruby Association Grant 2022 の最終成果報告として

昨年の参加記で書いたように、Rubyアソシエーション開発助成金 2022に応募しました。結果として採択していただき、aioquicの移植をある程度まで完成させることができました。

Rubyアソシエーション開発助成2022を終えて

今回の発表は、結果として少し早めの最終成果報告という形になったんじゃないかと思います。今年度も応募するかどうかは少し悩んでいますが、時期が来たらまた考えようかと思っています。

#RubyKaigiNOC のメンバーとして

ここ数年は #RubyKaigiNOC の一員としてネットワークの手伝いをしています。今年も、主にL1(ケーブル、APの敷設、撤収)の手伝いをしました。

RubyKaigiのオーガナイザーでもあり、NOCのボスでもあるsorahが大量のタスクを抱えているので、今年はsorahのタスクを奪うことを密かな目標にしていました。結果としてsorahやhanazukiさんにおんぶにだっこでしたが…… ただ、奪ったタスクにより、fluentdについての知見を得ることができました。そして、奪ったタスクはfluentdに関するもので、とはいえこれまでfluentdの設定を書いたことがなかったのですが、tagomorisさんの「fluentd実践入門」 がすごく助けになりました。#authorsrb のおかげで、tagomorisさんから直接本を書い、サインを頂くことができました。同じ本を何度も買おう！

最近本を出したRubyistに話しかけようスタンプラリー #rubykaigi2023 会場 をやります #authorsrb｜やきとりい

RubyKaigi参加者の皆さんにインターネットを提供することは嬉しいことです。同じ体験をKaigi on Rails 2023でも提供できると嬉しいのですが、今年はどうなるでしょうね……

As a DJ of RubyMusicMixin2023

昨年に引き続き、今年もpixivさんの主催するアフターパーティーであるRubyMusicMixin2023でDJをさせていただきました。Kaigiの後に良い音楽を浴びるの、最高の体験ですね……！

最後に告知をしましたが、高専DJ部というイベントを早稲田にある「茶箱」で定期的に開催しています。次回は7月の後半になる予定です。RubyMusicMixin2023のような、オールジャンルなクラブイベントとなっています。是非来てください。

https://kosendj-bu.in

挑戦

今回のRubyKaigiにおいての一番の挑戦は、英語で発表するということでした。角谷さんがおっしゃっていた「Rubyエコシステムの発展」にある事項(上記)のうち、1はそれなりにできていたんじゃないかと思っています。反面、2と3については僕は特に何もできていませんでした。

しかし、最近はDeepLやChatGPTなどによって英語力に下駄を履かせることができるようになりました。対面での会話に対してはまだ無力かもしれませんが、事前に原稿を練って一方的に話す場面や、文章を書く場面においては非常に力になってくれます(現にこの参加記も)。実際、僕の今回の発表は、まず日本語の台本を書き、それを一旦DeepLによって英語にしてもらったあと、その英文を自分の英語力に合わせて調整するという形式で作成しました。

今後

今回の発表でも話しましたが、移植の知見を基にした独自のQUIC実装を作ろうとしています。それにあたり、少し遠回りではありますが、RFC 8446並びにdraft-ietf-tls-rfc8446bisを読んでいます。移植中は、既にある実装をそのままの形式でRubyに書き換えるという作業をしており、TLS 1.3そのものの仕様についてはあまり考えられていなかったためです。

それでは次のRubyKaigi、沖縄で……の前に、Kaigi on Railsで会いましょう。

2023年05月17日
2023年04月02日

IETF 116 Yokohamaに参加してきました(IETF Meetingに参加しよう)

IETF 116の受付あたりの写真

IETF、IETF Meetingとは

※ IETF 116などの定期的に開催されるin-personな会合をこのブログでは “IETF Meeting” と呼びますが、正式名称ではない可能性があります。正式名称があったら教えてください。ちょっと探したけど総称っぽいものが見付かりませんでした。

IETFは、"Internet Engineering Task Force" の略で、インターネットの標準を決める団体です。ざっくばらんに言えば、RFCを出しているところです。

IETFが何なのかについては、既に良い説明があるのでそちらを参考にするのがいいでしょう。以下にリンクを貼っておきます。

さて、そんなIETFの116回目のMeetingが横浜で行われるとのことなので参加してきました。ただ、僕は都合上Hackathon(日曜)と木曜日のみの参加でした。

前準備

まずはIETFがどのような構造を持つ組織で、どのように議論が進んでいくのかを頭に入れておくと、議論が現在どういう状態にあるのかを把握でき、理解の助けになります。以下のリンクを読み、そのあたりの勉強をしました。

次に、自分の興味がある分野のdraftなど、Agendaに記載されている資料について読んでおきます。IETFの会議は、既にMailing listである程度議論されているdraftの内容について実際に対面で意見を交わすという場なので、draftは読んでおくべきでしょう。

参加したセッション

以下、メモは常体です。正確性の保証はありません。

Hackathon

https://wiki.ietf.org/en/meeting/116/hackathon

Hackathonは特定のprojectには参加せず、自分がやっているcurlのHTTP/3版ビルドをメンテナンスしたり、QUIC実装のデバッグをしたりしていました。

QUIC

https://datatracker.ietf.org/meeting/116/session/quic/

Media Over QUIC (moq)

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

むずかしい！

メディア転送、既にあるWebTransportではなくMoQ(MoQTransport)を定義したいモチベーションとしては、WebTransportはHTTP/3の上にあるプロトコルなので、映像配信をするのにサーバーがHTTP/3を解釈する必要があり、そうじゃなくQUICの上で直にメディア転送ができると嬉しいということらしい(会場で又聞きした)

Automated Certificate Management Environment (acme)

https://datatracker.ietf.org/meeting/116/session/acme/

IETF Meetingに行こう

IETF、インターネットの標準化について「興味はあるし、楽しそうだけど敷居が高くて、自分はまだそのレベルじゃないな」と尻込みしている人が多いのではないかと思います。確かに、議論の内容はインターネットの最先端についてなので予習しておかないとついてはいけませんし、しかし予習したからといってついていけるわけでもないですし、何より英語でのやりとりを理解する必要があります。ただ文字起こしがあるので、あとからゆっくり読み返すことはできます。

しかし、IETFそのものが初心者を歓迎しているイベントです(そう感じました)。理由は、参加回数が5回未満であれば名札に “NEW ATTENDEE” というリボンを付けることができます。初参加者向けの “New Participants’ Social Hour” というイベントもあります。つまりそのようなNewbieに対するサポートを行うという意識が参加者の間にはあるということです。実際、わからないことを聞いても突き放されることなく、丁寧に教えていただけました。

IETF116の参加記念？Tシャツと名札。NEW ATTENDEEのリボンをつけている

ただやっぱり、趣味で行くにはEarly Birdであっても$700というのは厳しいものがあります。これについては、(レポートなりを書くことで)業務扱いとして参加費を出してくれる企業が増えてくれることを願うばかりです。特に「若い人達が流入してくれないか」というのを懇親会ではよく耳にしましたし、そのためには若者の手を引いてくれる先輩の存在が、そしていずれそのような先輩となってくれるような、標準化の分野に興味のある人が参加しやすいような土壌をつくることが重要です。インターネットは、欧米の大企業が作っているものを享受する、というものではなく、人類全体で作っていくものです。インターネット上でサービスを提供している企業であれば、インターネットをより良くしていくための活動に対しては支援を惜しむべきではありません。それこそ、社内で採用されているプログラミング言語やフレームワークのカンファレンスに対する参加支援と同じような流れで、IETF Meetingの参加費を支援する企業が増えてくれると嬉しいですね。毎回とはいかないまでも、せめて国内開催の場合は旅費交通費を含めた支援がされるのが望ましいのかもしれません。

そして、お金を払って参加するのであれば、何か目標を自分に課すといいかもしれません。議論の様子や発表される資料は全て公開されています。それでも現地に参加するのは、実際に「インターネット」に関わっている人達に会えるからです。実際僕も、今回のIETF Meetingで「QUIC working groupのchairに話してQUIC開発者が集まっているSlackに招待してもらう」ことを目標として参加し、達成しました1。現地参加するのであれば、現地参加だから意味のある目標をひとつ決めて参加するのがいいと思います。

それと、チケットはWeek Pass(全日)を買っておくほうが絶対に良いです。僕は日和ってAgendaが確定した後にOne-Day Passを購入しましたが、自分の興味のある分野のMeetingが1日に集中することは本当にまれですし、一旦Agendaが確定した後に突然Meetingが生えたりすることもあります。

(ついでに言うと、1日しか参加しないにしても、Agendaの決定を待たずに購入するべきでした。参加当日、正確には受付時に判明したのですが、One-Day Passを購入する段階ではどの日に参加するかを選ぶものではなく、受付のタイミングでどの日に参加するか伝えるというものでした。上の写真の名札にある “THURSDAY” はその場でスタンプされたものです。つまりどういうことかというと、Early価格で買えたのにAgendaを待ってたからLate価格になってしまった……という話です。このシステムが116特有のものか、ずっとこのシステムなのかはわかりませんが。)

僕もこの界隈に足を踏み入れたばかりなので右往左往していますが、それでも参加して楽しかったし、今になっては全日程参加しておけばよかったと思っています。QUICというプロトコルに関しての活動をしているタイミングで、国内でIETF Meetingが開催されるというのは本当に幸運だったと思います。

次回、117はサンフランシスコで開催されるようです。時差が厳しい問題ではありますが、まずはRemote参加をしてみるというのは検討してみてもいいのではないでしょうか。僕も参加するとしたらリモートになるでしょうし。

https://www.ietf.org/how/meetings/117/

  1. もちろんmailing list経由で招待してもらうこともできると思います。しかしこんな良いタイミングでIETFがあるなら直接、と考えました。 ↩

2023年04月02日
新しい投稿
古い投稿