RubyKaigi 2019で登壇した時のCFPや準備の話
今回は未来の発表者のために発表までの準備や流れについて覚えているうちに書いていこうと思います。
発表内容はこちらを参考にしてください。
RubyKaigi 2019でOpenAPI 3について登壇しました
採択されたCFP
採択されたCFPを公開している例はある123ので、こちらでも公開していこうと思います。
## Title
How to use OpenAPI3 for API developer
## Abstract
I'll talk about how to use OpenAPI 3 and another tools in production.
JSON is widely used in the current Web.
But the request / response format is not in the JSON specification, so we can't guarantee.
In the case of developing API servers for backend server and multiple servers like micro services,
guaranteeing the request / response format is improve for stability and development efficiency.
So the definition of schema is important.
OpenAPI 3 (formerly Swagger) is a specification for describing the interface of RESTful API.
We can define request / response parameters schema for the endpoint using it.
The committee is gem which validates request / response in rack layer.
I'm developing the function to perform validation using OpenAPI 3 in this gem.
And I shifted my application specification to OpenAPI3 from another schema specification called JSON Hyper-Schema.
## Details
1.Introduce OpenAPI 3 and explain why it is necessary
2.The OpenAPI 3 specification
3.About request / response validation
4.A story about how to implement OpenAPI 3 feature to Hyper-Schema based gem
5.Shift to OpenAPI 3 from Hyper-Schema
6.Talk of client library generation
7.(If we have time, difference GraphQL and gRPC )
Since OpenAPI3 was released in 2017/12, it is not yet widely popular yet.
So this talk covers all API developers interested in OpenAPI 3, such as maintaining the API server and newly creating.
## Pitch
The committee is gem which validates request / response in rack layer using JSON Hyper-Schema and OpenAPI 2 (Swagger 2.0) .
I'm maintainer for it and I implement OpenAPI 3 feature.
I development OpenAPI 3 parser for it too.
https://github.com/interagent/committee
https://rubygems.org/gems/openapi_parser
My company use Schema validation based on Hyper-Schema.
I'm working shifting to OpenAPI 3 and create converting script.
So I can talk how to use OpenAPI 3 in production.
https://github.com/ota42y/json_hyperscheme_to_openapi3
実際のスライドを見て頂くとわかりますが、ほぼDetailsに書いた内容通りの発表になっています。 ただし、当初はcommitteeの内部の話はそこまでせず、GraphQLとgRPCの比較を入れる予定だったのですが、RubyKaigiなのでRubyの話の比重を大きくしようと思い、そこの部分の比重を大きくしました。
発表内容作り
RubyKaigiの-285日目からアップをしていましたが、内容作りは別にRubyKaigiを意識していたわけではありません⊂(・8・)⊃
#rubykaigi -285日目(｀･ω･´) pic.twitter.com/tHDaGP5dyr
— おおた@技術書典6でMicroservices本&RubyKaigi登壇 (@ota42y) 2018年7月7日
committeeのOpenAPI 3対応はRubyKaigiとは特に関係なく11月頃から本格的に動いていました。 JSON Hyper-SchemaからOpenAPI 3に変換するスクリプトを書きましたが、その時点ではだいぶ進んでいたので作業自体は10月後半辺りからだと思います。
ゆっくり実装しつつ、途中でDevelopers Boostでの発表等があって途中中断しましたが、最終的に年末年始に一気に仕上げてました。
良い年末年始だった事がわかる⊂(・8・)⊃ pic.twitter.com/hCOSYYZ48P
— おおた@技術書典6でMicroservices本&RubyKaigi登壇 (@ota42y) 2019年1月3日
ちょうど完成が近づいていたところにRubyKaigiの締め切りが近くなり、盛り上がっていたので試しに応募してみました。 ただ、締め切りを間違えていたのでCFP自体は1日で書いた記憶があります
結果は2/9に出ました。例年より時間がかかった印象ですが、元々3並列想定だったみたいな話があったのでその辺の調整に苦労してたのかな〜という感じです… 🙏🙏🙏
というわけで、 How to use OpenAPI3 for API developer という内容でrubykaigiで話します( ﾟ∀ﾟ)o彡゜ pic.twitter.com/SGL4kBJ5MC
— おおた@技術書典6でMicroservices本&RubyKaigi登壇 (@ota42y) 2019年2月9日
発表資料作り
結果が出る前にcommitteeのOpenAPI 3対応は終了しているので、基本的には資料作りや周辺ツールの調査だけで良かったです。
ですが、2月の頭からJAWS DAYSで発表したり、マイクロサービス本を出したり、合同誌に寄稿したり、商業誌向けにFlutter本を直したり、Rails DMで話したり、ネットにまだ公開できない色々な事をしてたので、RubyKaigiの資料は4月に入ってから作成していました。 とはいえ、前述のように大まかな流れは作ってありましたし、技術書典で出した本でもOpenAPI 3の話題を書いたので基本的には資料を作るだけでした。特にOpenAPI 3のRubyやエコシステム寄りの話をRubyKaigiに、スキーマファースト開発やGraphQLやgRPCとの比較といった話は本に書けたので、しっかりと無駄なくアウトプットできたのでとてもいい分担になりました。そのため、資料作り自体はRails DMの方が苦戦しました。 なお、会社名を出すプレゼンは業務として時間を確保させてもらえたためなんとかなりました。渡航費支援もあるのですが、こっちの方がかなり効きました…
発表資料自体は全部で5バージョン作っていて、ver.1だとOpenAPI 3の仕様の話が多かったり、ver.2だとcommitteeの使い方周りの話が多かったりと、プレゼンを2回は作り直しているぐらい変えています。 ver.3以降は内容がほぼ確定していて、練習して説明を細かくしたり省略したりしただけになります。 日程としてはver.1が4/10、4/12にver.2、4/15にver.3、発表に使ったのがver.4で、Q&A解答を加えて公開してるのがver.5です。 スライドの英語に関しては日本語にしてから英語に訳すみたいなことをやっていましたが、ベストマサフミ氏(@okuramasafumi)のお力を借りることができ、色々直して頂けたので滅茶苦茶助かりました🙏🙏🙏🙏🙏🙏
発表練習は社内の有志でやるのを4/10,4/15に行いました、1人で声を出す練習であれば10回以上はやってるはずで、福岡に着いてからでも3，4回は発表練習をしていました。 途中、同じく発表者の@ujmさんのいるquipperさんとオンラインで発表練習をしたりしました。 Rails DMの時もやりましたが、別の会社の人と練習するのはかなり良かったのでオススメです。先に聴けるという特典もありますし。
まとめ
私の発表内容はRubyの言語処理系とは外れた内容なので、CFPを出したタイミングでは通る確信は無かったですね… ただ、過去のRubyKaigiを見るとこういった言語の活用みたいな内容は一定数あるようで、 必ずしもRuby本体の話でなくても大丈夫なんだなーというのが実感です。 なので、そういった内容を持ってる人は気にせずとりあえず投げると良いのかなーという気持ちです。
