#builderscon 参加記 2日目

builderscon 二日目

二日目から本格的にカンファレンスがスタートし，いろんなトラックで発表者がたくさんの面白いことを発表していきます． とりあえず僕が聞いた話の書いたメモと感想を少しずつ載せていきます．

Electronによるアプリケーション開発事情2018

speakerdeck.com

h3potetoさん

普段はTeraformをいじっている

Mastodonクライアントを作っている

Electron

  • Chromium + Node.js
  • Webフロントの技術が利用できる
  • vue-cliにelectronのテンプレートがあるらしい
  • main, rendererプロセスが存在していて，mainがバックグラウンドでごにょごにょ値が変更されたらviewに反映
  • React, Vueの差分レンダリングはよさみが深く，開発者はデータをどう反映させるかだけを重視すればよい
  • Chromiumは更新されており，それに伴ってElectronもアップデートされて行くよさがある．

リリースの話

electron-builder

  • アプリケーションのパッケージングを行うやつ
  • electron-packagerより機能が増えている

アイコン

  • linuxだけmain.js内に書かないといけない
  • それ以外はpackage.jsonに書いたら動いてくれる

効果音

  • 圧縮されてしまうと読み込めないので，圧縮せずにpackageに含めるように設定する

証明書

  • electron-packagerだと勝手にやってくれる
  • MAS(Mac App Store)だけcodesignコマンドなどを利用する必要がある

Mastodonクライアントの話

  • Slackっぽいクライアント
  • 海外の反応「良い！だけどElectronか」
  • Electronは，メモリをたくさん食ってしまう

メモリと戦う

  • Streamingを切るとメモリが増えない
  • Streamingを増やしてもあまり変わらない
  • 流速が早いと結構変わる
  • 取得したトゥートを片っ端からレンダリングしていた
  • iOSだと画面に表示されている部分のみをレンダリングされている(UITableViewController)

  • 表示部分を含めたセルの高さを算出するやつがいて，そいつが良い感じにレンダリングを調整するらしい

  • 解決策：最新40件のみを保持していて，そしてそれ以降のトゥートを読み込まれた時にレンダリングする

vue.js

api周り

  • mastodon-api，POSTパラメータをbodyではなくurlパラメータに埋めて送信するらしい
  • Bodyに埋め込みたいので，ないので作った

障害周り

  • インスタンスを立てないとわからない問題もある
  • Gemによる障害を解決するために，revertしたプルリクを送ったらしい
  • 今は最新のGemが入っているらしい

感想

リリースなどしたことがなく，そこからのパフォーマンス面の改善の話などそこまで話題に上がらないが重要なトピックが聞けて非常に満足です． vue.js + Electron，良さそうだなと思いました．

Algorithms in React

speakerdeck.com

koba04さん サイボウズ

仮装DOMの話より内部の話

Reactの内部

  • いろいろパッケージに別れている
  • Component -> Reconciler -> Renderer -> Hostという流れ
  • ReconcilerはCとかでも実装するつもりなので基本的に依存が少ない

Stack Reconciler

  • traverseして差分があれば，即反映
  • 同期的に更新するように実装されている

ReactElement

  • DOMと対応している
  • 毎回生成し直して描画

二つのInstance

  • Public Instance
    • 状態を持つ
  • Internal Instance
    • ReactのAPIをいろいろつかうやつ
    • Public Instanceに触らせたくないやつを持っている

ReactInstanceMap

  • Public InstanceとInternal Instanceを紐付け

Stackの実装の問題点

  • 同期的に処理をしないといけない
  • traverseするのに時間がかかってしまったりする

Fiber Reconciler

  • render, commitフェーズの二つのフェーズ
  • renderは途中で止めれたりできる

Fiber

  • ReactElementと1:1で作られる
  • ReactElementをLinkedListで持つ
  • ダブルフバッファリングのような構造を持っている
  • 軽量のスレッド

Linked List

  • InsertとDeleteが早いので利用，要素は順にトラバースしていくので特に問題はない
  • parent, childの関係があり，二つ目からのchildは一つ目のchildからsiblingという関係を持ちparentに関係を持つ．
  • parent -> child -> sibling -> parentという流れで探索

Double Buffer

  • CurrentとWork in progressの二つを持っており，commitするとバッファを切り替える

render, commitフェーズ

  • renderはasyncで動いて，全ての処理が終わったらcommitしてcurrentに反映
  • ComponentWillMountは非推奨らしい

複数のアップデート

  • update queue
  • こうより：this.setState({count: this.state.count+1})
  • こう書いた方がいい：this.setState({state => ({count: state.count + 1})})

expiration time

  • いつ更新されるかを定める，優先度のようなもの
  • Eventごとに優先度が異なっている．
  • ユーザの入力を受け取るものは優先度が高い

Demo

  • 入力した文字をカウントの数だけ文字をレンダリングする
  • 何もいじってないとテキストの入力時に，レンダリングの負荷がかかりブラウザが入力を受け付けなくなる
  • テキストフォームの優先度をあげることにより，入力を先に行い遅れて文字が表示されるようにできる

bit演算

  • reactはbit演算が多用されている
  • bit演算により，状態を抽出する
  • 今がどのモードかどうかをbit演算で判定
  • Context APIでもbit演算で分岐が可能

suspence

  • Demoがあり，lodingという文字を何秒後とかに出したりできる

感想

普段Reactを触ってますが，裏ではそう動いているのかと知らない世界が見れて嬉しかったです． これからのReactを頑張って追っかけていこうと思います．

事前知識なしで理解する、静的検査のいろは

speakerdeck.com

DeNA Kuniwakさん

CSの知識なしでの静的解析

静的検査

  • 実行しないまま検査をする
  • なぜ静的に検査したいのか
  • 動的検査だと実行時に通ってないコードを検査できない
  • 静的検査だと網羅的に検査できるが，正確さは低い（実行していないから）

抽象構文木

  • コードを木構造で表している
  • メジャーな言語の抽象構文木は気軽に見れる

構文解析

  • 再起下降法の単純な実装を紹介
  • 文法規則をいろいろ掘って行き，構文規則に当てはまる文字列を探す

解析プログラム

  • 引数は文と始める位置
  • 戻り値は，Nodeと終わりのインデックス

感想

静的解析を行う方法をすごく手軽に説明しており，非常にわかりやすかったです． Go言語でつくるインタプリタでも少し出てた内容だったりもでていて，再確認にもなりました．

ボクが考える i18n の未来

speakerdeck.com

kazuponさん Vue.js core team

Abount i18n

  • i18n -> 国の文化に依存しない
  • l10n -> 国の文化に適応させる
  • Numeronym 単語の文字数を名称にする -> i18nなどはそういう書き方
  • i18nしていないと色々いちいち変更しないといけない
  • デフォルトでi18nが入っているものも多い

content of i18n

i18nの問題

  • 一つの国に複数の言語
  • 税金だったりGDPR
  • 文章の対応
    • LTR -> 左から右の文字列
    • RTL -> 右から左への文字列

未来のi18n

  • Saas
  • i18n framework
    • Progressive Frameworkという考えの導入
    • 複数のレイヤーに道具を分け，組み合わせて利用する

感想

i18n考えることがすごく多そうで，その大変さを知れたのがすごく大きかったと思います． 勉強します．

Javacardの世界

speakerdeck.com

moznionさん java card applet

java card

smart card

  • intelligent smart card
  • memory card

APDU

UICC

  • カードの方

JCRE

  • Java Card上で動くランタイム
  • GCがあるかどうかはカードによって変わる

Java card memory

  • インスタンス変数はメモリに未来永劫残り続ける
  • インスタンス変数にデータを書き込みまくるとカードが壊れる
  • RAMは非常に小さいので，狭いスコープの一時的な変数のみを格納する

Java Cardの開発

書き込みのお話

  • 認証機関から出ている鍵がないと書き込むことができない
  • つまり個人では書き込みは不可能

感想

発表がすごくJava Cardの話で爆笑していました． でも本当に知らない世界を知れてよかったなと思ってます．

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

Rui Ueyamaさん lldリンカ

lld

  • LLVMのサブプロジェクト
  • FreeBSDは時期バージョンではlldを利用していたり
  • 現在chrome, firefoxで使われてたり
  • コンパイラが中間ファイルのリロケーションを使ってリンクするのがリンカの仕事

開発のきっかけ

  • webフロントを触って来たけど飽きて来てしまった
  • 趣味でコンパイラを作成していた

  • 仕事でコンパイラとリンカ，どっちが作りたい？と聞かれてリンカを作成したらしい

  • アセンブラ書いてバイナリ吐いて，それを読んでそのバイナリを吐けるプログラムを作成して行く

  • Hello world作成まで数ヶ月

作成したリンカ

  • 遅い
  • 作り直したら，10倍くらい早くなった
  • 自然と早くなるものを書くことが大事
  • データ構造を工夫して一回のアクセスでたどり着けるようにする
  • 異なるOSでのリンクのためにしたことは，別々のファイルとして書き特に抽象化なども行わないようにした

感想

自分が良いと思ったパターンによる実装を行うというすごいことを学びました． 普段はすごく抽象化してコードの少しの差異を埋めようとするのですが，最初からそれらを別のコードに落とし込むことを聞いて非常に目から鱗でした．

懇親会

クッキーが割られていたり，飯がうまかったりで最高でした． ある程度いろんな人と話せた感覚があるので，良い懇親会だったと思います．