「RubyKaigi 2024に向けて泡盛を予習しておきたい」ということになり、今月頭に沖縄に行ってきました。
以下、様子です。
コミックマーケット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カタログで確認することができます。
pixivFANBOXおよびGitHub Sponsorsで支援していただいている方に対しては、連絡をいただければ取り置きをさせていただきます。当日お渡しする際には支援していることの確認となるものを提示していただくかもしれません。準備をお願いします。詳しくは各プラットフォームからの連絡をご参照ください。なお、申し訳ありませんが支援金額を頒布価格から差し引くという対応はしません。まあそんな爆裂に売れていくなんてことはないと思いますが……
最後に、再度コミケWebカタログにおけるキリンセルの詳細ページを貼っておきます。
頒布価格を決定しました。1部¥3,500です。お品書きも更新しています。
なお、すっかり言及を忘れていたんですが、同日東パ03bにて頒布される「桐生あんずファンブック」にて、「Rubyistワカモノ組座談会」で僕が話した内容が本になっています。こちらもよろしくお願いします。
【C103 2日目東パ03b「ひやおろし」】
— 炬燵(kotatsu) (@sakahukamaki) December 28, 2023
桐生あんずという一般女性について、友人同僚先輩同輩教育係に保護者と様々な視点から語った結果10万字を超えた本です。サンプルは引用先をご覧ください。
なお、本人は中身を知りません。
#評論情報系同人誌告知 #C103 #C103新刊 https://t.co/TKFHNldP2Q pic.twitter.com/XEJ5xGNdjY
今年は契約先が変わったのですが、新規契約先を探しているときに、「こういうのがあると非常に助かる」という声を頂いたので今年もやっていきます。
これまではこんな感じでした。
例によって冒頭の画像は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を書いた比率のほうが大きいと思います。
昨年と比較して一番変化のある部分だと思います。これは明らかにRubyアソシエーション開発助成2022によるものです。とにかくPythonのQUIC実装をRubyに移植するという作業をしていました。とはいってもPythonを “書いた” ではなく “読んだ” というほうが正しいですね。DjangoやFlaskでWebアプリが書けるようになったとか、そういうわけではありません。
Python同様、イチから移植することで理解が深まったもののひとつです。昨年はここがQUICという表記でしたが、今年は明確にTLSを追加しました。実装の移植で行き詰まりRFC 8446 (TLS 1.3)を何度も読みました。
この活動がきっかけで1、今年3月からIETFに参加しはじめました。これ今年からなんですね……もう3回参加してるのでもっと前からのような気さえしてきます。
日本国外での開催に現地参加するかどうかは……ちょっと悩んでいます。お金がないというのもありますが、まだまだ英語のリスニングが甘いからというのも大きな理由です。
Kaigi on Rails 2023で皆さんに使っていただいたものです。これのおかげで、今年触った技術としてCloudflare、Stimulus、PWAを追加することができました。その後様々な方からのcontributeで、RBS(特にRailsに導入するもの)についてもちょっとわかるようになってきた、かもしれません。
今年は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は書いていこうと考えています。
コミュニティ活動の筆頭と言えます。これは運営チームのみ見える形で「こんなことがしたい」というのを書いていて、それをやっていきたいですね。Proposalも……出せたらいいですね……
今年は初めてのin-person開催となりましたが、運営側からもそうですし、参加していただいた皆さんからも、成長する余地があることは感じられたかと思います。やっていかねば、いけませんね。
昨年から何もできていないですね。本当に何もできていない。無です。多分来年もあんまりここに割ける時間はないんじゃないかと思いますが、気持ちだけはあります。本当です。
Pythonと同様に書くまではいかなくても、QUICやTLSの実装の参考として読むことは多いのではないかと考えてはいます。
昨年、以下のようなことを書きました。
あと海外カンファレンスにProposalを出せたらいいなとか考えていますが、果たして。
こちらは、出すには出したのですがRejectになってしまいました。
一方で、RubyKaigi 2023での登壇は英語でやることにし、その登壇記も英語で書きました(DeepLにおんぶにだっこではありますが)。
RubyKaigi 2023 participation report
RubyKaigiにおいて英語で話すことの一番のメリットは、同時通訳さんとの打ち合わせのために資料を事前に提出しなくてよくなることです。その代わり、発表練習は日本語で話すとき以上にみっちりやる必要がありますが。ただ、RubyKaigiの僕の発表資料作成は、まず話すことを文章にしたうえでスライドを作っていくというスタイルなので、この点は偶然にもうまくいっています。
そしてIETFに参加するようになり、例年以上に英語に触れる、特にリスニングの時間が増えているのを感じます、が、それに英語力の上達がついていっていない……どうしたものでしょうね。
116が横浜で開催されたという偶然もけっこう大きな要因ではあります ↩
チェコの首都、プラハで開催されたIETF 118にリモートで参加したので、自分なりにまとめます。ただ今回、RubyWorld Conference 2023と日程が被ってしまったため、Meetecho(ライブで会議が行われる場所、Zoomの部屋みたいなイメージ)にはあまり入れずにYouTubeのアーカイブと議事録からのまとめとなります。英語の議論についていけないのでどのみちそうなるのですが……
写真はIETFとは全く関係ない、RubyWorld Conference 2023開催地である島根県は宍道湖の写真です。
例によって正確性の保証は一切いたしません。
https://datatracker.ietf.org/group/quic/about/
STOP_SENDING_AT
はドラフトに含まれなくなりそうhttps://datatracker.ietf.org/group/moq/about/
今回もMedia Over QUICのSessionは2回ありました。議論の内容がメディア転送をやっていないとわからないようなものになってきて、いよいよ追うのに限界を感じています。
https://datatracker.ietf.org/group/tls/about/
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と合わせて見ていかないとだめそうです。
https://datatracker.ietf.org/group/ccwg/about/
Freelance
← かっこいいhttps://datatracker.ietf.org/group/httpapi/about/
application/yaml
を追加するものLink-Template: "/{username}"; rel="https://example.org/rel/user"
みたいなheaderを使うことで、 username
に値を挿入してURIを生成できる
application/problem+json
とかで返す/.well-known/api-catalog
で提供するContent-Range
を使うことに対しての懸念、後方互換性は捨てて新しく設計してもいいのでは?という意見application/openapi+yaml;version=3.1
みたいなのの定義https://datatracker.ietf.org/group/httpbis/about/
-d
(例えば br-d
) っていうのがDictionaryを表しているのかな?match
が match-path
と、optionalな match-search
, match-dest
に分割されたDate
を構造化して送信する場合は SF-Date
で送信するとかapplication/octet-stream
なのか application/offset+octet-stream
なのか他の方法かAccept-Events
headerをクライアントが送信するbraid.org
が見れないむずかしいですね。
Kaigi on Rails 2023に参加していただいたみなさま、ありがとうございました。初のオフライン、オンラインのハイブリッド開催となりましたが、登壇者の皆様、Proposalを出してくださった皆様、協賛してくださった企業の皆様、そして一般参加者の皆様のご協力のおかげで無事に今年のKaigi on Rails 2023を終えることができました。
主役は参加者のみなさまということもあり、運営のひとりである僕からのふりかえりは手短かにしようと思います。
もともと会場でのサイネージの役割としてのなにかを用意したいよね、という構想はあったので運営内でのみ使うWeb appを作るつもりではいたのですが、大倉さんがドーンと rails new
をしたリポジトリが爆誕したのでそこに乗っかることにしました。お披露目クオリティに達したのが本当にギリギリだった1こともあり、イベント開催までの周知が全くできておらず当日にアクセスが集中して軽い障害が発生したのは本当に申し訳ないと思っています。でもこれで来年はもっと多くの人が使ってくれそうで嬉しいです。いくつか追加機能のアイデアも頂いています。
これについては他で話すネタになりそうなこともあり、あまり詳細な言及は控えます。とはいえソースは公開されているので何をやったかは全て見れる状況ですね。ドキュメントが少なすぎるのは追々なんとかします……
https://github.com/kaigionrails/conference-app
今年も昨年に引き続き配信関連の担当をしました。とはいっても今回は会場側に配信をやってくれるプランがあるので、それをお願いしました。なので当日は僕自身がなにか操作するということはありませんでした。
会期中は、配信に登壇されている方の姿や声がちゃんと乗っているかの確認のため、YouTubeを2窓して両方の発表を聞く、ということをしていました。冒頭の画像はそのために用意したディスプレイを置いていた、スタッフルームにおける僕の机の写真です。持っててよかったモバイルディスプレイ。ちなみに、手前にあるダンボール箱2つは、直前に僕が買ってきてもらうように頼んだChromebookです。
急にPC必要になって買いに行ったり、荷物が配送遅延で届いてなくてお買物行ったり、Day0からいらいろありましたがなんとかなった(たぶん)のでよかった。明日の起床がんばらねば。まずは風呂🛀
— ぷぽ (@pupupopo88) October 26, 2023
実際に配信のプロの方と組んでなにかをやる、ということは初めての経験だったのでとても勉強になりましたし、楽しかったです。
今年はオフライン開催ということでそこまでしている時間がなさそうな気配があったため、配信のトランジションについては何もするつもりがありませんでした。しかしアイデアが降ってきた&やってみたら案外時間をかけずに作れたために今年も作ってしまいました。これって会場で流れたんでしょうか?もしかしたら配信限定コンテンツだったかもしれません。
果たしていつまで作り続けられるでしょうね。
クロージングでもアナウンスがありましたが、2024年の開催は決定していますが現時点で会場がまだ決まっていません。やばいですね。
レビューしたいと言っていた大倉さんを途中からは完全に無視してCI pass即mergeを連発していました。よろしくないですね。 ↩
クックパッドという会社は、Rubyのコミュニティに関わっている僕にとっては特別な印象がありました。今でこそShopifyやGitHubにその座を譲っているでしょうが、世界最大級のRailsによるモノリシックなアプリケーションによるサービス提供、フルタイムRubyコミッターの登用、優秀なメンバー、技術ブログの豊富なアウトプット……いつだって「いつかこんな会社で働きたい」という会社のうちのひとつでした。
クックパッドが横浜に移転するタイミングで、多くの人が退職していくのを外から眺めていました。その勢いに、このままではいつか一緒に働きたいと思っていた人達がいなくなってしまうと思い、(以前から手が足りていないのでどうですか、という声はかけていただいていた)あそなすさんに連絡をとり、業務委託の立場で関わることになりました。
色々なことをやりました。事業に関わることはどこまで書いていいのかがわからないのであまり触れませんが、新規サービスの立ち上げ、Ruby及びRailsのアップデート、「さわるだけで開発期間が3倍になる優れモノ」とまで言われた1レシピサービス本体への機能追加などを覚えています。
事業に関わらないことでいえば、社内フェスでのDJ、チキチキ、データ指向アプリケーションデザインの読書会、Rubyに関する社内勉強会、そしてRubyKaigi。事業もそうでない部分も、本当に楽しかったです。
一方でいいニュースばかりではなく、度重なる事業の見直しやそれに伴なう人員整理が行われ、その度に寂しい思いで一緒に仕事をした方を見送ることが続きました。
そしてとうとう自分の番も来た、というだけのことです。まあ業務委託の立場で退職推奨に対して「自分の番」というのもおかしな話ですが、とにかく契約の解除ということになりました。僕は撤退作業の手伝いという形で9月末まで稼動していました。稼動初期に立ち上げから深く関わったサービスのクローズ作業をするのは感慨深かったです。
実は、RubyKaigiが終わった直後から、様々な条件付きで正社員として入る交渉をしていました。この交渉は本当に人員整理の直前までやっていたのですが、しかしまあ、白紙になりましたね。この条件に関しては、業務委託で稼動し続けた実績によって交渉していたものなので、そのまますぐ別の会社にこの条件でどうですか、ということはできません。なので本当に、残念な思いです。
職選びの観点で言うなら、たぶん自分はPythonやGoやJavaScriptの案件でもなんとか生活できるくらいのお金はいただけると思っています。それでもRubyの会社を選び続けるのは、Rubyでサービスを開発・運用し、コミュニティに投資している会社であれば、自分がRubyKaigiやKaigi on Railsのために使う時間のことを考慮してくれる(そのことで急に休みを入れることに理解がある)、そういうことへの理解があるからです。その点で、フルタイムRubyコミッタを抱えていたクックパッドは本当にいい会社でした。
個人的な気持ちの問題はどうあれ、クックパッドのサービスと会社のことは引き続き応援しています。残っているメンバーもまた優秀な人達ばかりなので、心配はしていません。
なお、次の稼動についてのお誘いに関しては不要です。
以上、個人の日記でした。
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 にログインし、ユーザー名を変更した後に「あなたが実在の人物であることを確認する必要があります。」という表示になりました。
そして画像認証を行うのですが……これが何回やっても全然終わらない!!!!
15分くらい格闘して一旦あきらめ、@yu_suke1994アカウントのほうで上記ツイートを行いました。そしたら同様の状態に……
ただ、どちらのアカウントも地道に認証をやっていたら突破できました。よかったですね。
どちらの場合も共通しているのは、「https://kosendj-bu.inのURLをツイートしたこと」です。あとハッシュタグでしょうか。いや、これが本当の原因かどうかはわかりませんが……
何かあったら僕はこのあたりにいます。というか、最近は発言の主軸は自分の立てているMastodonに移しているつもりでいます。
たぶんこれですね。
9/7現在、X(旧Twitter)にて名前/プロフィール変更をするとアカウント認証に飛ばされ認証通過しても「技術的な問題が発生したため」とログイン出来なくなるバグが発生中 - Togetter
8/3のCloudNative Days Fukuoka 2023(以下CNDF2023)と8/23のRubyKaigi 2023 follow upで発表しました。
どちらも、自分が取り組んでいるQUICに関連する話をしてきました。
CNDF2023においては、静的WebサイトとNginxなどのWebサーバーの2つの軸に対し、Public Cloud、特にAWSとGoogle CloudにおいてQUICでの運用が可能かどうかについての発表を行いました。
また、発表内で紹介した構成については、TerraformやWebサイトの構成をGitHubで公開しています。
半月ほどしか運用していませんでしたが、コスト削減を真面目にやっていなかったこともあり、AWS側で$122(¥17,000程度)、Google Cloud側で¥1,100ほどの費用がかかりました。
また、懇親会でのLT大会において、直前に開催されたIETF 117 San Franciscoで自分が聞いていたセッションで触れられていたdraftについて一言で説明していくという発表もさせていただきました。これについては発表資料はありませんが、IETF 117 San Franciscoの参加記でより詳細に記事にしています。
RubyKaigi 2023 follow upでは、自分が取り組んでいるRubyishなQUIC実装についての進捗報告を行いました。
IETFやCNDF2023、Kaigi on Rails 2023の準備もありなかなかめぼしい進捗が出せていませんが、来年のRubyKaigi 2024でもproposalを出せるような成果を出せるようがんばりたいです。
以下の記載において、間違い等あれば訂正したいので気軽に言及してください。
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を回避することで高速な通信を行うことができる、ということになると思います。
多分そういうことになるんじゃないかと考えていますが、間違い等あれば訂正したいので気軽に言及してください。
https://datatracker.ietf.org/meeting/117/proceedings
7/22から7/28まで開催されていたIETF 117 San Franciscoに日本からリモートで参加しました。前回のIETF 116 Yokohamaの開催後、ISOC日本支部によって開催されたIETF116報告会において、参加した感想を発表させていただきました。
その発表内で「参加記を書こう!」と宣言したのもあり、こうして117の参加記を書いています。なるべく今後も参加記は書いていこうと考えています。
以下で言及するWGについては、基本的にはsessionの部屋に入って議論を聞いてはいましたが、ここでまとめ直すにあたっては基本的には議事録を参考にして書いています。英語のリスニングスキルがポンコツなので……
https://datatracker.ietf.org/meeting/117/session/quic/
quic wgにおいては、前回の116 Yokohama以降の大きな出来事といえば RFC 9369 QUIC Version 2 が出たことでしょうか。
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の内容が簡単で理解できるという訳ではありませんが。
https://datatracker.ietf.org/meeting/117/session/tls/
TLS WGにおいて前回からの大きなUpdateといえば、個人的にはdraft-rsalz-tls-tls12-frozen-01がでてきたことでしょか。
https://$ORIGIN/.well-known/origin-svcb
で取得できるようにしようというdrafthttps://datatracker.ietf.org/meeting/117/session/mls/
E2EEなメッセージのやりとりをどうするかについてのWGです。
https://datatracker.ietf.org/meeting/117/session/ccwg/
ccwgは輻輳制御に関するworking groupです。もともとcongressという名前だったのが、ccwgに改名されました1。
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に戻っています。
むずかしいですね。
https://mailarchive.ietf.org/arch/msg/congress/rHNowIkEJt8SZy4PkUYzAt2c0nw/ congressという単語よりccwgのほうがclearだというのは、確かにそうですね。 ↩
私はうなすけといい、Kaigi on Railsのオーガナイザー、つまり運営チームの一員です。Kaigi on Railsにおいては、運営に関わる全員がProposalを評価し、その結果から採択・非採択を決定します。なので僕は皆さんから送られてくるProposalを読み、評価をするメンバーのうちのひとりです。
昨年のKaigi on Rails 2022において、皆さんから多くのProposalを提出していただき、大変ありがたく思っております。2023年も引き続きKaigi on Railsを開催できること、皆さんからの Proposalを受け取れることを喜ばしく思います。
さて、昨年頂いたProposalを見ていて、「このテーマはとても興味があるんだけど、書かれてる内容からは採択できないな」と言えるような、惜しいものがいくつかありました。そこで、皆さんには、運営が(というか私が)送られてきたProposalをどのように見ているのかということについて書いていきます。
おこがましいお願いではありますが、Proposalを書こうとしている皆さんにはこれから書くことについて少し頭に入れておいてもらえればと思っています。
RubyKaigiとは異なり、Kaigi on Railsでは匿名レビュー、つまり 「Proposalの提出者が誰なのかを見ずに評価を行う」 のです。これを忘れないでいただきたいのです。
ただし、厳格ではありません。どういうことかというと、Proposalの内容に明らかに個人が特定できる要素、例えば「私はRailsの作者であり、ルマン24時間耐久レースに出場したことがあります」のようなことが書いてあったり、個人ブログや個人リポジトリへのURLが記載されていても、そのことによってリジェクトすることはありません。あなたが誰であるか、という情報は極力含めないでいただけるとありがたいですが、どうしようもない事情によって徹底することができないことも私達はわかっているつもりです。
abstract(概要)には、実際に公式Webページのタイムテーブルに掲載されるトークの概要を記入していただくこともあり、ここが書かれていなかったProposalはありませんでした。
ですが、悲しいことにdetails(詳細)にほとんどなにも書かれていないことによって、評価のしようがないProposalが2022年には数件ありました。detailsには、あなたが一体どのようなトークをすることができるのか(するつもりなのか)、ということを書いていただきたいのです。ここが書かれていないと、私達運営は、それを採択することによって参加者の皆さんが知見を得られるのかどうかが判断できないのです。あなたは、実際には非常に価値のあることを職場で、もしくはプライベートで成されているのかもしれません。そして当事者にとっては、終わってみれば割と自明なことに思えてしまいますが、第三者にとってはそうではありません。その取り組みの内容を具体的に書いていただかないことには、第三者である運営の我々が知ることは不可能です。是非、detailsを書いてください。
あなたが提出してくれたProposalと、ほとんど同じ内容のものを別の人が提出してきたとします。その場合、もちろんabstract、detailsは評価の対象となりますが、そこで甲乙付け難いと運営が判断したら、pitchによって判断することになります。結果として同じ内容の発表になろうと、そこに至るまでの経験や想いについては、かならずあなたにしかない何かがあるはずです。
この記事では、通過するproposalを書くための作文術(どのように書くか)ではなく、「どんなことを書くか」をいちレビュワーの視点から解説したつもりです。ここまでに書いたことについて少し気にしてほしいという想いはありますが、どうか過剰に気にすることなく、どんどんProposalをお送りいただければと思います。
https://kaigionrails.org/2023/cfp/