builderscon tokyo 2018でElectronの発表をしてきた

9/6 - 9/8に開催されたbuilderscon tokyo 2018で発表してきました.

スライドはこちら.

speakerdeck.com

自分の発表について

30分枠のつもりで応募してたけど,採用されたら1時間割り当てられてたので,もしかしたら時間持たないかなーとちょっと不安だった. でも多分45分以上は話したんじゃないだろうか.

皆様が質問してくれたおかげで,やたら早く終わる発表とかにはならずに済みました.

質問について

ちょっとうまく答えられないものもあったので.

Q: このOSだけではバグるみたいなのはある?またその場合はどうやって検証している?

A: これはまじである.実際最近あったのだと,Arch Linuxでのみクラッシュするという報告があって,それは完全にElectron側の問題だったので,バージョンが上がって修正された. 検証は,これも結構きつくて,今のところ

  • メインで使っているUbuntu18.04
  • サブで使っているmacOS
  • たまーに起動するWindows10とWindows7

みたいな状態で検証している.ただ,普段遣いは完全にUbuntuと,職場でMacなので,この2つの検証が最も手厚い.Windowsは本当にたまにしかしていない.

Q: XSSの対策ってどうしている?

A: これはあまりうまいこと回答できなかった.まず基本的に仕組みとしてElectronはXSSを完全に防ぐ方法(設定等)はない. なので,開発者が書き方に気をつけていくしかない. 一応今のところXSSで何か問題があったりしたという報告はないのだが,そんなに気を使って書いていない. ただ,そんなに柔軟なipc通信をしていない(ipcでいじる操作を絞っているとか,inputをそのまま渡してないとか)ので,おそらくXSSできる口は今の所ないのではないか?と思っている(要検証).

もし脆弱性を見つけたら是非プルリクエストを…….

Q: バグレポートとかどうしてる?

A: これは発表後に個別に聞かれた.今の所そういう仕組みは入れてないのだが,まじでほしい. たとえば,iOSでいうならFabricのCrashlytcsみたいなものを入れたいとは思う.中身はただのnode.jsとChromiumなので仕組み的には入れることは可能だと思っている. ただ,そういうエラーログ系のサービスにログを転送するためには,大抵の場合tokenが必要で,それをアプリケーションのどこかに埋めないといけないという認識. で,swiftみたいにバイナリにコンパイルして逆アセンブルが一般的に想定できないものであればtokenをコード(もしくは設定等に)埋めてもいいと思うのだが,Electronの場合は見ようと思えばソースを見られてしまうので,tokenを埋めるのには今のところ抵抗がある. というわけでそこまでの仕組みは入れられていない. ただ,エラーログはちゃんと吐き出すようにしていて(アナウンスは全然していないのだけれど)「困ったときにはここのログを送ってほしい」みたいなのはちゃんと用意してある.

反省とか

  • 質問は発表者側もテンパる
  • スライドは発表前にアップロードしてtweetもしていたが,buildersconのトークページに資料が貼れる!ここに貼っておいたら見やすそう
  • メモリの話はまじで計測しておけばよかったと後悔(当時はこんなに流行るとは思ってなかったし発表するとも思ってなかったんだよ

他の発表とか

開発現場で役立たせるための設計原則とパターン

builderscon.io

いつも「なんかこれ気持ち悪くね?」というのが言語化されていて大変良かった. 「設計って結局ケースバイケース」みたいな抽象的な話に,できるだけ引き込まれないように考える方法を提示してくれた.

Sustainable Kubernetes -Observability, Security, and Usability-

speakerdeck.com

2ヶ月ぶりくらいのmumoshu. Kubernetesの話はどれを聞いても楽しい.

JavaCardの世界

speakerdeck.com

「これはJavaCardのコードですか?」の問題が絶妙.だって答えが「なぜならJavaCardにcharはないから」とか. 意外にもいろんなところに浸透しているJavaCard. でもEEPROMに書き込んだ変数の書き換えに上限があるとか,怖い話もいっぱい聞いた.開発するのは大変そうだなー.

lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話

builderscon.io

平然と話されたんだけど,やっぱりどう考えてもすごい. リンカの原理を説明されれば,たしかにそれはそうなんだけど,現実的にこれでコンパイラが吐き出したプログラムを動く状態までしっかり持っていくのは並大抵ではない. 事実,Hello Worldが出るまで相当な時間を要していた. 「ちょっと悪いところを見つけるとすぐに作り変えたくなる.でもそれは良くない」って言ってくる人はみんな開発には関わってくれない人たちばっかりだったというのは,いい話.

ファミコンエミュレータの創り方

speakerdeck.com

ブラウザで動くファミコンを見せてもらいました. ファミコンの仕様にだいぶ詳しくなれた気がする(気がするだけ). あんなにいっぱいメモリマップを見たのは久しぶりだった.それをRustで実現するというのもなかなかにすごかったけど. あとボスの描画をしているのは,実はスプライトではなくて(スプライトだとあの大きさのものを描画できないから)背景に描画してあって,逆に足場等をスプライトで描画しながら,それを動かすことでボスが動いているように見せるという,ファミコンらしい涙ぐましい努力の結晶にはびっくりした.

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ

speakerdeck.com

AWSピタゴラスイッチを作るのは俺も大好きなので,楽しかった. 独自ドメインを使えるようにした上で,それをHTTPS化して証明書を管理するのは大変だよなー. そのへんは,配信,発行,更新といくつかの場合に分けて,各フローがちゃんと動くようにしていた.あとngx_mrubyを本番導入していて,またいいmruby事例が聞けてしまった. 証明書の配信なので,速度的にもかなり速く動作するピタゴラスイッチが求められるし,大変だよなぁ. あと,こういうのを聞いているとやっぱりLet's Encryptがもたらす恩恵はすごいな.

感想

Speakers Dinnerでは,「どの発表も楽しそう」と思ってて,全部見たいんだけどトラックが多くてかぶっているのが多い. これもしかして去年よりトラック数増えたよね?追記: トラック数は去年と同じらしいです)

参加者も増えたのかなぁ. そんなわけなので,ホールではなく教室でやっている発表だと,立ち見が出始めると満員という札を出してしまって,それ以上入れなかったりする. これは結構悲しくて,出遅れると見たい発表の教室に入れなかったりする.

本当は発表が終わったあとも質問全部聞いて,なんなら発表者とちょっと話したかったりするんだけど,こういう事情があると,みんなそそくさと移動をし始めて,次の教室前に並ぶようになってしまっていた. 発表が盛況なのは嬉しいけど,これはちょっと悲しいんだよなーと,発表者としても思っていた.

buildersconの参加は今回で3回目だけど,発表したのは初めてだった. 1時間発表はやっぱり準備とか結構大変だったけどね(本業の話じゃないからっていうのもあるんだけど).

そもそも今の時代にElectronって,みんな興味あるの?って思ってたんだけど,意外にも満員で立ち見が出るほどだった. というか初日の午前なんて誰も来ないだろーって思ってたんだけど…….

発表者としての参加はとても楽しかった.ありがたや.

また来年を楽しみにしています.