Dev Festいってきたのでメモ。
初心者のためのRxJava
Reactive Extensionの略
Reactive Manifest
Reactive Programing流行った
定義は曖昧。むーん。
データフローを定義して変更を伝播していくこと
従来はTransformational
変数に一つ一つ設定していく
Reactive
データフローを決めて、変更を伝播させる
普通にリクエスト投げるだけだとレスポンスを待ってスレッドをブロックしちゃう
コールバックを設定する必要がある
コールバック減る
Androidだと色々書いてるのがツラくなる
非同期処理ツラい
Rxとは？
ReactiveProgrammingにインスパイアされてできた
非同期、イベントベースのプロぐらい民具
Observable Sequences
観測できるもの
Subscriberを取れる
Composing
シングルタップをダブルタップに変換させる
Operator
元々Linqを使いたかった
RxJavaで何ができるか
- 非同期処理
- UIイベント処理
- 非同期＋UIイベント処理
メリット
- イベント・非同期処理が扱いやすい
- 状態変数が少なくて済む
- データフローの見透しガッ良くなる
デメリット
- 直感的とは限らない
- 普通なら読むと大体分かるけど、Operatorの使いこなしが必要なので難しいかも
- 罠がけっこうある
なぜ学習コストが高いか？
オペレータがたくさんある
ややこしい概念が多い
- ドキュメント嫁
- RxJSで貯める
- Javaだとビルドに時間がかかる
- 違いはほとんどない
- 納得いったらJava使うみたいな方法
- 良いのはラムダ式が使えること
- オペレータのカテゴリを覚える
- ライブラリを利用する
- 実はObservable.createでObservable作るのは鬼門
- fromEmitterオススメ
- 楽しむ
- 全てはストリームである
- 頭の使い方が異なる
- android-jp.herokuapp.com
RxJavaのこれから
- RxJava 2.0 RCC2
- 今月末には正式版出る予定
- Reactive Streamsベース
- Java9で標準化される非同期処理のガイドライン
- これから導入するなら2.0にトライしてみて
使う使わないの基準は？
- 単純な非同期処理一本とかならいらない
- 複雑なUIとの組み合わせをしたい場合は適してると思う
- 諦める
ユニットテストは？
- 一番問題になるのはScheduler
- スレッド周り
- フックポイントというのがあるよ
- 全部非同期からどう気にして動くようにできる
- 2.0で改善されてるらしい
- TestSubscriberで結果の検証はできる
これからRxJava始めるなら？
- 勉強してみたいなら2.0
- 実際に開発するなら、2.0に色んなライブラリが対応してない
エンジニアとして知っておくと幸せになれる(かもしれない)機械学習とTensorFlowの事
機械学習、人工知能がブーム
勉強方法
- 機械学習を賢いブラックボックスとして扱う
- よくわからんけど割り切って使う
- 言ってることは分かるがおもしろくない
- 用途別に呼び出す手法を判断できるようになる
- scikit-learnっていうチートシートあるから見ろ
Tensorflow Playgroundがあるのでこれ使うと楽しい
ステップ3に行くには数学がチラチラ見える硬派な本で知識を蓄える必要がある
深層学習は？
Tensor
多次元の行列
定数、変数、プレースホルダーを宣言できる
デバイスに展開して実行する
Web over HTTPS
Googleのセキュアの記事
抜け落ちてる話があるんじゃないの？
安全とは？
記事に書かれてない。
HTTPサイトは本当に全て危険なのか？
今何が起こっているのか
HTTPはテキストベースでシンプル
最初は
- ドキュメント共有のプラットフォーム
- インターネット使えるのも一部の人
- パケットが見えるとか気にする必要がなかった
サイトからシステムになることで、センシティブな情報が流れるようになった
Wi-Fiで簡単にのぞける。
JSの脆弱性とかMan in the Middleがよく前提になってる
HTTPSにしとけば
間で見ても暗号化されてるから見れない
秘情報がなければ暗号化しなくて良いか？
どんな検索してるか、どんなもの使ってるかわかったら色々分かることもあるよね
技術的には層だけどそんなことやるやつはいないよね
そうではない
やらないと思われてたことを実はやってる人がいたのがわかった
これがターニングポイント
日本では通信の秘密が憲法で定められてる
言論の自由のためにはこのサイトはHTTPSじゃなくてもいいよねとか言ってらんねえ
とりあえずHTTPSでいいのか？
暗号化されたデータのまま保存しておく
国だったら
- 法律で殴りまくって秘密鍵の提出要求できる
- 物理で殴りまくって素因数分解で解析する
牧歌的な時代は終わった
前提が変化した
Webはもっと殺伐している
通信は見られている
HTTPSにしないのならば、HTTPSにしない理由を分かるようにする必要がある
PFS
これだけは押さえとけ
広域盗聴されて、鍵さえあれば全部読めるのはまずい
Ephemeralの付く鍵交換を利用
大変なのは…
- 証明書
- 買え
- ビジネスをまともにやるなら買え
- それすらできないビジネスはクソ
- Let’s Encryptって言われると思ったら大間違いだ。なめんな。
- 非営利や個人サイト向けのためのものだ
- URL変更
- リダイレクトする
- 毎回リダイレクトすると遅いから、HSTS
- HTTPS化の指標の一つ
- HTTPS化のゴール
- MixedContents
- 埋め込まれて得るHTTPサブリソース
HTTPSでしかできないこと
最初からHTTPSにしとこう
古いガラケー問題
時間が解決してから動き出すのでは遅い
準備をやっていくしかないですよ
後手に回るほどツラくなる
TLS関連のインシデントが多い
重要度が高まったからそこを狙うメリットが増えた
今後はもっと増えると思う
インシデントには敏感に。
日和見暗号
Opportunistic Encryption
TLS1.3
何とかしよう
ZeroRTT
RFCももうすぐ出そう
HTTPSを前提にした開発ノウハウ
hostsファイルに127.0.0.1を本物のドメイン書いて社内CAからValidな証明書発行して使ってる