JSConf2019
記念すべき第一回の*1のJSConf Japanで『Migration from React Native to PWA』というタイトルの発表をしてきた。
登壇に関して
資料
発表では触れなかった余談は泣く泣く削ったトピックなので参照されると嬉しい。
今回は発表資料を作ったり練習する中で気をつけたことがあり、それは「負債や失敗といった否定的で強い言葉を使わない」ということだった。資料中でも発表でもReact Native単体での技術の良し悪しは述べていないし、2年前のReact Nativeを選んだという技術選定自体にも肯定的な態度をとっている。
当時の技術選定に携わりReact Nativeアプリの土台を作ってくれた開発者がいなければ今のビジネスも存在しない。彼/彼女らへの感謝の念は尽きないということ、運用中途での状況の変化によってチームに合わなくなったのでmigrationに至ったということを改めて強調しておきたい。
Proposal
やっていった #jsconfjp pic.twitter.com/ZLBl71ASy7
— ohbarye (@ohbarye) 2019年8月29日
プロポーザルのメモ書きは以下で、これは @mopp さんの VimConf 2019 Proposal - mopp を大いに参考にした。
ここまで長いプロポーザルは今までに書いたことなかったが、おかげで応募以前に思考が整理されることになった。
また、プロポーザルは社内で数名にレビューされ、応募以前にとても良い指摘がもらえて大変良かったです。特に @mopp さんや @ujihisa さんといったカンファレンスのCFP選考側の視点ももらえたのは本当に福利厚生。
- Proposalがしっかり書いてあると運営側としてはめちゃくちゃ嬉しい by @mopp
- アウトライン部分にそれぞれ何分くらい、と追記すると運営側も目印になるし、更に、時間の見積もりをしている、つまり、発表にすでに取り組んでいる、となって信頼度が激増する by @mopp
- 本気のCFPのときはスライド下書きとかCFPに図とか入れまくる by @ujihisa
- 「審査員の中で僕を推してくれそうな人が、他の審査員を説得するために必要そうな客観的材料」とかもいい感じにまとめて出す by @ujihisa
- 一番情報量のでかい要点を一つ述べる by @ujihisa
発表練習
社内で同僚向けに一度だけ発表練習をした。スライドがざっくり出来、まだ一度も通し練習をしていないタイミング。
あまり仕上がっていないものを見せるのはどうか?とも思ったがこのタイミングで見てもらったのが正解だった。話の流れをこうしたほうが現実に即していないか、強調したい結論は結局どれか、などの本質的なツッコミをもらえた。
一度しか出来なかったがもう一回ぐらいやっても良かった。特に社外の人に見てもらう機会を作らなかったのは良くなかったかもしれない。
社内向けの練習では、事実と詳細を知っている人からの良い指摘がもらえる。「誇張・婉曲などの事実誤認がないか」「詳細レベルで技術的な誤りがないか」「伝え方は正しいか」「誤解を招かないか」。内容の正確性に関するレビューが貰えることが多い。
一方、社外(もしくは遠いチーム)からは「社内では通用する前提知識を抜きで理解できる内容か」「抽象的な話と具体例の行き来が適切か」「説明の粒度が適切か」「興味を持てる内容か」など、理解の容易さや面白さについての意見をもらいやすい。
今回は片手落ちだったが、これらを相互補完できると良い発表になると思う。
動機
JS Confにかける熱い思いじゃなくて恐縮だが、大きめのカンファレンスに久々にプロポーザルを出したのには私的な動機があったのでそのことも書いておきたい。
新メンバーが多い大型プロジェクトでの不確実性との戦い方 - Quipper Product Team Blogという記事を書いたことから察する(?)通り、ohbaryeは去年2018年の暮れ頃からしばらくEngineering Management寄りの仕事に注力していた。とはいっても 半年間、自分を騙しながらアウトプットに積極的になってみた - valid,invalidに書いたように2018年の登壇はちょっと自分にとってはハイペースすぎたのであえてブレーキをかけて充電するつもりだった。
が、知り合いや同僚たちが色んな成果を出したりカンファレンスに登壇しつづけるのを横目に見ていた初夏、強い焦燥感が湧いてきて、今年の自分は技術面でのなにがしかに一本注力したり成果をあげたりということがあまりできていないと気づいた。
充電とはいうものの技術面でのインプットを怠りすぎじゃないか…?2018年は登壇駆動でいろいろやっていきたが、締め切りを設けないと学びを得たりまとめたりといったことができない人間なのでは…?*2
しかし久々になにか登壇しようと思っても普段から"やっていっている"人間じゃないとネタがないんだよな…というのを痛感し、そこで今回紹介したプロジェクトを自発的にやっていったという背景がある。
イベントについて
JSを軸に置きつつも、もっと広いテーマや未来を感じさせ、「Web面白いじゃん」「ブラウザ上でもっとやれるじゃん」と改めて思わされる発表がいくつかあって刺激を受けた。
Venue
会場は趣味で何回か行ったことのあるアーツ千代田3331。(つい最近行ったのは小畑健展だった)
屋上まじで寒い
— ohbarye (@ohbarye) 2019年11月30日
が、ノスタルジックで好き#jsconfjp pic.twitter.com/jyw1WnWYfe
元小学校を改装したアートギャラリーというおもしろ空間なので個人的にはここでテックカンファレンスをやるというのは面白いし、自宅から近いのも嬉しい。
#jsconfjp #jsconf is the best conference ever that even a cat visits pic.twitter.com/GvzOBvK4kY
— ohbarye (@ohbarye) 2019年11月30日
印象に残った発表など
JavaScript AST プログラミング: 入門とその1歩先へ
Rubyでは触ったことあるけどJavaScriptのASTは全然だなぁ、と思ったので参加した。
Babelなどの挙動がAST変換によって行われていることは知識で知っていたが使われているparserライブラリなどを気にしてもなかったのでその辺の知識が得られてよかった。
このままだと知識で止まってしまうので、他言語でAST操作して実現している処理をJavaScriptでも再現するようなことをやってみたいと思った。
Building and Deploying for the Modern Web with JAMstack
ギレルモ・デル・トロの影響でGuillermo Rauchもギレルモと読んでいたが、グィァーモみたいな発音が正しかった…。
Guillermo Rauch初めて生で見るが、プレゼンに"迫力"がある…!!#jsconfjp #jsconfjp_a
— ohbarye (@ohbarye) 2019年11月30日
様々なシステムのバックエンドはSaaSに支えられている
— ohbarye (@ohbarye) 2019年11月30日
PaymentやSearchといった機能単位でサービスを提供するSaaSも多く、それらを組み合わせてプロダクトを作っていく#jsconfjp #jsconfjp_a
これは本当にそう
- JavaScript => Static => Serverless
— ohbarye (@ohbarye) 2019年11月30日
- API => λ => Serverless
- Markup => Static => Serverless#jsconfjp #jsconfjp_a
SSRの欠点や課題が整理されていてNext\.jsやNow\.shがserverless志向ぽくなっていった背景がわかりやすい#jsconfjp #jsconfjp_a
— ohbarye (@ohbarye) 2019年11月30日
error ratesに応じて自動的にrevertするような仕組みが近々出来てくる#jsconfjp #jsconfjp_a
— ohbarye (@ohbarye) 2019年11月30日
Deno - A new way to JavaScript
発表から1.5年ほど経過したDenoについて。
正直まったく追いかけてなかったのでDenoがそもそも何なのか?というところからのイントロがあって助かった。
TypeScriptでGoのようにシステムプログラミングができるようになると面白いな。
Make it Declarative with React
Custom Rendererの話、面白かった。(特定のinterfaceを備えるように)HostConfigを自前で実装すればいろんな環境で色んなことができるらしい#jsconfjp #jsconfjp_b
— ohbarye (@ohbarye) 2019年11月30日
Reactという抽象表現の応用の幅を理解できる素晴らしい発表だった。
自前で書いていくのは結構大変そう、というか作りたいもののイメージも特にないけど、React DOMやReact NativeなどのHostConfigを読んでみるのは面白そう。
Node.jsでつくるNode.js - WASM/WASIミニコンパイラ
がねこさんの発表は去年も見て面白かったので今年も期待して見に行ったらやっぱり面白かった。
去年よりも濃そうな内容を10分でやっていてすごい…
正直自分の知識不足で多々ついていけなかったのが悔しいのでもうちょっと学んでから再読する
Browser APIs: the unknown Super Heroes
おもしろAPI集…と見せかけて実用性高いものも多かった。デモ多めで発表うまいな〜と思わされつつ、Bluetooth APIを使ったデモが特に面白かった!
おおーBatteryManagerなんていたのか#jsconfjp #jsconfjp_a pic.twitter.com/6dVnNvZB0T
— ohbarye (@ohbarye) 2019年12月1日
navigator\.connectionにonchange仕込めるな
— ohbarye (@ohbarye) 2019年12月1日
オンライン/オフライン判定はPWAでよくあるやつだ#jsconfjp #jsconfjp_a pic.twitter.com/byiOn6cssZ
MediaRecorder API、語学学習とかで使っていそう
— ohbarye (@ohbarye) 2019年12月1日
発音した音声ファイルをアップロードしたりhttps://t.co/scw7gH6vsz#jsconfjp #jsconfjp_a
ブラウザ使えば高音域の音を発してネズミ避けができるなhttps://t.co/E4ejE3giYN
— ohbarye (@ohbarye) 2019年12月1日
(たまに人間でも聞こえて辛い人がいるので注意)#jsconfjp #jsconfjp_a
Anatomy of Click
E2Eテストフレームワークの作り手が解説する、各E2Eテストツールでブラウザのクリックの裏側で何が起きているか。
Rowdy氏は「フロントエンジニアはこんなこと知らなくても大丈夫」と言っていたが、ちゃんと知ることでE2Eツール選定にも関わってくるような内容だった。
browserに限らず多くのUIシステムが capture phase => event bubbling phase のモデルを採用している#jsconfjp #jsconfjp_a
— ohbarye (@ohbarye) 2019年12月1日
https://t.co/JOpOO2cUSk
— ohbarye (@ohbarye) 2019年12月1日
& Chromium wiki are quite useful to dive into inside Chrome!#jsconfjp #jsconfjp_a
JSONとWebSocketを理解していればDevTools Protocolを使いこなせるhttps://t.co/sf4KxNXjbZ#jsconfjp #jsconfjp_a
— ohbarye (@ohbarye) 2019年12月1日
Who uses DevTools Protocol? E2E testing tools like Selenium, Puppeteer etc.#jsconfjp #jsconfjp_a
— ohbarye (@ohbarye) 2019年12月1日
How Selenium works
— ohbarye (@ohbarye) 2019年12月1日
ChromeDriver is an HTTP Server
Language bindings => (HTTP) => ChromeDriver => (WebSocket) => Chrome Debugger#jsconfjp #jsconfjp_a
Cypress and Selenium 1はChrome debuggerを使っておらず、Eventを直接Dispatchしている
— ohbarye (@ohbarye) 2019年12月1日
これはflakyでSeleniumは壊れ安いという評判につながった#jsconfjp #jsconfjp_a
E2Eテストには2つのアプローチがある
— ohbarye (@ohbarye) 2019年12月1日
1. Simulating native events (Selenium, Puppeteer, Testim)
2. Dispatching events (Selenium1, Cypress)
問題はどちらも常に動くとは限らずflaky
これが「85%の会社がE2Eテストをやっていない」理由の一つ#jsconfjp #jsconfjp_a
Pika: Reimagining the Registory
ブラウザで動く90%のコードが3rd party製のもの。みんな同じものを使うのだから単一のレジストリやCDNから配信し、それをキャッシュすればWebsitesはもっと早くなる。なるほど。
import { foo } from 'https://example.com/awesome-library.js'
のようにURL指定のimportはDenoでも実現しようとしていたことで、この辺協力しあって仕様策定などしていくのかな
Web開発の未来
— ohbarye (@ohbarye) 2019年12月1日
1. 80%の開発用のツールが不要になり
2. 開発が10倍速く
3. Web sitesも10倍速くなる
全員が10 times programmersだ!!#jsconfjp #jsconfjp_a
これからの数年で、書いたコードがそのままブラウザで動くようになるだろう#jsconfjp #jsconfjp_a
— ohbarye (@ohbarye) 2019年12月1日
Websitesで動く90%のコードは3rd partyのもの。React使ってるサイトにアクセスするたびに全く同じReactをダウンロードしてる。完全に同一なら単一のCDNから配信されるやつをみんなが使えば良いのでは?というのがhttps://t.co/PkNAxB3Dtr#jsconfjp #jsconfjp_a
— ohbarye (@ohbarye) 2019年12月1日
カンファレンスへのフィードバック
刺激ももらえたし自身の発表機会をもらえたのはとても良かったし、オーガナイザーとスタッフには本当に感謝している一方、イベント運営周りで改善できそうな点がいくつかあったのでそのことについても書いてみます。
タイムマネジメント
いくつかのセッションが持ち時間をオーバーしてしまったけど、巻きに入らなかったのが気になった。2連続のときに休憩がないこともあいまって、セッション間移動するとけっこう厳しい感じになってしまった。
登壇者に発表のスケジュール・時間を守ってもらったり、休憩時間を余裕もたせるなどができればよいのかもと思った。登壇する側としては自分の出番がずれると緊張する時間が伸びて辛い…!
タイムスケジュール組むのはめっちゃ大変だったり、海外からわざわざ来てもらったスピーカーには存分に話してもらいたいなど、裏側の苦労は察しつつ…
双方向のやりとりを活性化させる
登壇者側としても、わりとさらっと発表して終わってしまって双方向のやりとりが生まれなかったのがちょっと残念。(これは自分の発表とか動き方のせいも多分にありそうだけど)
他イベントで良かったのはAsk the speakerとか、発表は25分でQ&A 5分を設けるといったもので、こういう仕組みがあるとより交流が活性化しそう。
Ask the speakerも徹底させるのとか難しいですけどね…
その他
寒いとか、部屋の人数のバランスが悪いとか、いくつかは会場都合で避けようのない課題もあったけどこれは開催時期や会場が変わればなんとかなりそうなのであまり気にしていない。
最後にちょっとネガティブなことを書いたけど刺激ももらえたし、年内に大きい発表が一つできて良かった。
この機会をくれたJSConf Japan 2019のオーガナイザーとスタッフとスポンサーには改めて感謝いたします。