Builderscon1

2018/09/07

BuildersConメモ

Envoy internals deep dive

まず同時通訳がすごかった。ほぼ原文の漏れなくリアルタイムでガンガン通訳する。

Envoyとは

Microservicesの開発を補助するツール。 作成したServiceのProxyとして動作し、便利機能を色々と追加してくれる。（Sidecar Pattern）

Envoyが作られた背景

世の中モノリシックなデザインからMicroservicesに移行したけど、マイクロサービスも問題がある。

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

設計抽象的な話になりがち
責務ってこのxxxなクラスはxxxな責務です！と言われたらまぁそうと言わざるを得ない

設計。複数の分割構造の選択肢から適切な構造を選び出すアクティビティ。デザインパターンは分割カタログ。

SOLIDの説明

設計原則を用いるとセルフチェックができる。

Single Responsibility

責務は仕様変更が発生するまでわからない、 設計対象となる問題をよく観察して、変更理由を知ることが大事。どこがかわりやすいポイントなのかしることが大事。

新しい学びは少なかったが、新人に研修をするときの良いサンプルになった気がする。

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

Slide

JavaCardの世界

JavaCard

あの金色のチップ

SmartCard ISO7816

CardはAPDU(Application Data Unit)というプロトコルで外界と通信する。

UICC
Inteligent Smart Cardの一種　　 ある程度の演算ができる

1M〜5M Hz CPU ROM EPROM(書き換えできる) RAM 普通にCPU

Core O.S(Docker関係ない) ファイルシステムもある。普通にファイルを取り扱える。

JCRE(Java Card Runtime Edition) 機能はかなり制限されており、下記は使えない。 動的クラスローディング ファイナライズ スレッド 大きなプリミティブ型(char, float) etc…

GCはカードの実装次第

基本インスタンス変数はEPROMに書き込まれる。 電源が切れてもインスタンス変数のデータは残る。

RAMはめっちゃ小さい(8byte) 本当に一時的なデータのみ入れる

JVMは一生動き続ける 電源供給がない場合は無限のクロックサイクル。完全に一時停止しているような状況になっている。

Java CardはAppletを同時に実行はできないが、同時に起動させておくことはできる。複数のアプレットを選択して起動さ焦る。

EPROMの寿命は100,000writes

開発サイクル

普通のJavaを書いてConverterかける。

How to write a Java Card applet

Javaカードはどこでかえるのか

Amazon/Aliexple

どんなアプリが動いているのか
アイデンティフィケーションの処理
SIM認証系
通信暗号化

Q JavaCardの未来は？
A クレカ/携帯が死滅しなければ

Q JavaCardのコードを検索したいときは？
A javacard.frameworkはぜったい使われている

Q SmartCardはなぜJavaなのか
A SmartCard登場当初はC, Lisp実装もあったらしいが自然淘汰の結果JavaCardがのこった。セキュリティレベルが高かったから？

Q EPROM破壊を防ぐための独自テクはあるか？
A 洗練されたテクはない。基本耐久テスト。壊れるやつはテストですぐ壊れる。

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

リンカの基本概念

catして全体を作って、 断片化している時には決定できなかったメモリ配列を決定する。他のファイルで定義されている関数。

リロケーション リンカの仕事

Chrome のリロケーション13000000 1μ秒多く費やすと合計で13秒遅くなる

作りはじめた当初 全く動かない

徐々に動かす エラーをはかない実行ファイル 単一ファイル 複数ファイル etc… HelloWorldを動かすまで数ヶ月

ターゲットの実行環境毎に色々異なる。 概念は同じだが

実行環境に依存しない中間コードに直そうとすると無理がでた。

書き直し決意 文句言われたけど、文句言ってる人は書いてるわけじゃないので書き直し開始

書き直したらめっちゃ早くなる

書き直した結果、賛同する新しい仲間が増えてくる

リデザインのポイント

マルチターゲット

中間表現を導入する ダメ

全ターゲットでデザインを共有するが、コードは共有しない。 ターゲット毎に似たようなコードを書かなくてはいけないが、似ているだけで厳密には違う。これを共通化すると大変だった。

早くてシンプルなコードを書くために

慣習に従ったReasonがない実装は積極的に拒否する。そんなパッチが来ても入れない。慣習が間違っていることは多々ある。全てに理由と理屈を求める。