Official
見つけよう、Dockerと開発・運用のいい関係
- Dockerとコンテナ技術は別物
- アプリケーションをイメージ化してポータビリティを実現したかった
- バックエンドの1技術としてコンテナーを利用した
- コンテナー技術は10年前からある技術
- Linuxコンテナーはプロセスグループごとに独立したOSは環境を見せる技術
- 普通のサーバーだと共有されてしまうので、アプリごとにわけることは出来ないのか
- カーネルをちょっとトリックを細工して実装している。既によくあるもの(chrootとか)
- コンテナーの技術を管理する技術がなかったから流行ってなかったが、Dockerがイメージで管理出来るような仕組みを作った事によって、爆発的に流行るようになった。
- Docker.incへの期待として、戦略が不思議な感じで見えてこないので、パートナー戦略、エコシステム、サポート体制を早急に作って欲しい。
- 個人を超えたDockerの利用パターンとして、Dockerイメージを用いて、多数の開発者に同一の開発環境を提供。そのまま本番環境でも動作するDevOps。この全体像を見失わず、開発と運用をひとまとめにする、全体を網羅する、様な形をイメージしておくと吉。
- Dockerを使用するとチームを作らずとも、1人で運用出来てしまう未来もある。
クライアントサイド開発をWebとNativeから考える
好き嫌い
- webの好きな所
- 50年後もあると思う
- 技術の潰しが効く
- PDCA＆デプロイが早い
- webの嫌いな所
- UIとして動きが遅い
- パーツが足りない
- もっと制約があった方がやりやすい
- nativeの好きな所
- UIが作りやすい
- パーツが充実
- 強いプラットフォーマーがいる
- nativeの嫌いな所
- プラットフォームに縛られている
webの非同期周り
- 非同期処理が前提
- js自体がfunction渡しの言語仕様ではない
- コールバック処理が辛くなる -> Promiseの登場、仕様化することにより、可読化が容易になった。webのフロントエンドはPromiseが必須・流儀。だが、エラーハンドリングが重要。
- webの場合、UIThreadのみ。WebWorkerがカジュアルに来る時代が来るかどうか？
- ネイティブの場合、自分でスレッドプールを作って管理していたが、ライブラリに任せて。
- Androidの場合、Promise使うならRxjava使うようになってきた。
- iOSの場合、ライブラリが乱立。プログラマ次第。
- streamは、Rx.jsから派生して標準化しようとする動きがあるがまだわからない。
状態管理
- webの場合、jQueryのちょっとしたものからちゃんと作りましょうっていう流れになって、Backbone.jsがMVC的な流れになり、Angular.jsが出てきて、データバインディングの流れになり、React.jsが出てきて、今に至る。今まで、1つのライブラリが席巻してきたが、最近はAngular2、React、Reduxなど乱立している。
- ネイティブの場合、プラットフォームが提供するフレームワークがあるが、はみ出る設計を補う為に、規約で縛ったり、ライブラリを利用している。フレームワークはOSのものを使用する。iOSの場合、言語から変わるので、ランタイムから依存するのは良くないという流れがあるんじゃないか？iOSSDKの更新頻度が多いので、ライブラリのメンテが大変なので、それを使用するのはどうか？という思いがあるのではあるのではないか？
MVCについて
- ルーティングに発火するイベントは古い。サーバー側とクライアント側の実装がかぶる。
- iOSのMVCとRailsのMVCは違う。MVCの定義は違う。
- webの場合MVC2。オリジナルのMVCとFluxの場合は似ている。
- webの場合、クライアントのMVCは辛かったのか？
- Backbone、underscoreの作者がRailsエンジニアなので、そこから技術をもってくる傾向があったので辛くなったかも。
- Fluxは変更の局所点だけ管理すれば表現出来るようになったのが良い点。
- ReSwiftはアプリの内部状態を管理したいので、状態遷移を表現出来るのが気に入っている。
- webはフロー。SPA・ネイティブはスタック。
- Fluxの問題はStoreが非同期を取れない。
リアクティブプログラミング
- 【翻訳】あなたが求めていたリアクティブプログラミング入門
- データバインディングがしたかった。ReactiveCore。
- Rx系はAndroidで使われているがPromiseでも良かったかも。
- Rxは難しすぎる。習得に時間がかかる。
- RxJavaはAndroidではデファクト。
- RxはPromiseの代替でも出来るし、全部フォロー出来る。ユーティリティとしてどの程度まで使用するか。
- webの場合、Rxの問題はjsでは型がないのでIDEでの補間が出来ず、いまいち流行らないかも。
- Rx系のライブラリを使用するとxcode死ぬ。
クライアント開発に向いている言語は？
- jsには型がないし、仕様ではないので、要求が満たせなかったりしている。
- 型は冗長化しなければあった方が良い。
- 型があって辛い事はなかった。
- webの場合、すべてに型が必要ではない。jsは貧弱ではある。
- KotlinはGoogleがサポートするかどうか。言語仕様的にはSwiftに近い。Java7で書くのは辛い。
- Immutableなデータ構造は欲しくなる。そのへんSwiftは扱いやすい言語。クライアント開発には欲しい。
- WebAssembly
今後
- jsの型が欲しい
- 正しくステートを分類出来るアーキテクチャが欲しい
- 昨今、ネイティブはwebから技術が降りてきている。
- ネイティブは多様化していく。
- WebAssemblyは、LLVMバックエンドの言語を触っていると恩恵があると思う。