O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
社内ツールを作って得た気づき
AngularとElixirの 新しい関係 @isyumi_net 谷出陸
お前誰よ 名古屋でプログラマーしてます。 自宅 -> Dart 会社 -> Go/TypeScript
問題提起 最近のフロントエンドまじ面倒くさい
確かに便利になった Angular or React 手続きではなく変数でViewを管理できるようになった
型安全な言語 Dart TypeScript
状態の管理は依然、面倒くさい
解決策１ Redux 安全になったのはいい コード量が増えたのが辛い
解決策２ Rx的なものを使う 全てをイベントストリームとして捉える そこそこいい選択肢 頭使う
辛い
わかってくれる人？
僕らが触れている 状態とは どのようなものか
状態のスコープ サーバーサイドからのデータ 例）チャットのメッセージ一覧 ユーザーの入力 例）チャットのインプットフォーム
なぜ辛いのか Webアプリのライフサイクル 1. サーバーからデータを取ってくる 2. Modelにキャッシュする 3. 表示する 4. ユーザーの操作でModelを書き換える 5. サーバーに書き込む
つまり 真実が サーバー クライアント 二つある
フレームワーク対決！Angular VS React仮想パネルディスカッ ション https://html5experts.jp/yoshikawa_t/14459/
MVC二階建ての部分の引用 （4/1 編集 特に許諾とかとってないので消しました）
1階建てにしよう
お題 社内で使うリアルタイムチャット 同じオフィス(=ローカルネットワーク)にいる
提案
具体的に クライアントをAngularで書く WebSocketでPhoenixに接続 Phoenixでは全てのStateをメモリ(Agent)で保持 ユーザーのイベントは全てWebSocketで送信 Phoenixで全員に最新のViewの状態...
1階建てになった！
良かったこと 開発時間の短縮につながった パターンマッチがあるためActionの解釈がしやすかった おそらくHot Code-Swappingが効いてくる
デメリット vimの設定が大変だった 遅い vagrant上で1000ms EC2 東京リージョンにサーバーを置くと 1100ms Redux的なものをElixirで手書きしなければいけなかった ズバリそのものというライブラリがなかった
結論 時期尚早だった 未来は感じた 社内のちょっとしたツールならOKという時代も来るのでは
ありがとうございました Make Dartlang Great Again
AngulaとElixirの新しい関係
AngulaとElixirの新しい関係
Próximos SlideShares
Carregando em…5
×

AngulaとElixirの新しい関係

2.176 visualizações

Publicada em

こんにちは。
よろしくお願いします。

弩.netといいます。
AngularとElixirの新しい関係について提案します。

私は、名古屋でプログラマーをしています。
家ではDartを、会社ではGoとTypeScriptを書いています。

今日切実に訴えたいのは最近のフロントエンドがまじで面倒くさいので
Elixirで何とかしたいということです。

たしかに、部分的には便利になりました。
AnguarやReactを使えば手続きではなく変数でViewを管理できるようになりました。
例えば、bool値でメニューバーが開いているかtrue/falseで宣言すれば、
間違いなく画面でメニューバーが閉じたり開いたりします。

** 1分 **

また、DartやTypeScriptなど型安全な言語で開発できるようにもなりました。
僕は名古屋出身だで、型安全な言語で開発しりんよとおばあちゃんに言われて育ちました。
東京都民の皆様も安心と安全を区別するのが得意なフレンズと聞いていますので、
ぜひ生JSを書くのはもうやめてDartやTypeScriptに移行していただきたいなと思います。

しかし、状態の管理という面ではまだまだ課題もあります。

一つの解決策としてReduxがあります。
しかし、安全性は高まりましたがコード量が増えたのでやはりまだ辛いです。

また、Rx的なものを使うという選択肢もあります。
全てをイベントストリームとして考えるというは良いアプローチだと思います。
しかし、知能に限界がある人にはなかなか使いこなせないです。

結局まだまだ辛いんです。

わかってくれる人

そこで僕は、状態とは何かについて考えました。
僕らが触れている状態には二種類あると思います。

サーバーから来たデータとユーザーが入力したデータです。
チャットのメッセージ一覧をサーバーから取得します。
そして、それに対して返信を書き込みます。
この時、「ありがとうございます」とインプットボックスに書き込む途中の
ありがとうご　という変数、これも状態です。

** 2分 **


フロントエンドのライフサイクルで考えると辛さのポイントが分かってきます。
まず、サーバーからデータを取ってきます。
それをローカルのモデルにキャッシュして
それを表示します。
ユーザーが何か操作したら、モデルを書き換えます。
送信ボタンが押されたらサーバーに送信して
その結果が取得できたらまた１〜５を繰り返します

つまり、サーバーとクライアントに二つのモデルがあるんです

これは少し前にバズってたAngularとReactについての対談です。
ここに

問題の核心をつくフレーズがあります。
MVCが二階建てになってるじゃないかと。

じゃあ、1階建てにしよう

僕が取り組んだのは社内リアルタイムチャットです。
チャットワークやスラックを使えばいいと思いますが、
特殊な社内システムと連携したり社内用語を入力補完して欲しかったりすることありますよね。そういうチャットです。
また、チャットメンバーは同一ネットワークにいるものとします。

** 3分 **

こういう設計はどうでしょうか。
これはよくあるFluxの図です。

このViewの部分だけをブラウザで実装し、残りは全部Elixirでかけないか。

そこでPhoenixです。

具体的には、
まず、Viewは全てAngularで書きます。
WebSocketでPhoenixに接続します。
Phoenixでは全員のState、つまり、メッセージ一覧やあるユーザーのメニューバーが開いているかいないか、何番目のタブを開いているかをAgentで管理します。
ユーザーが何かをクリックしたり送信したりしたら、全てWebSocketでイベントを送信します。
PhoenixでStateを書き換えて最新のViewをWebSocketで配信します。
そして、そのデータをそのままAngularにわたします。

** 4分 **

1階建てになりました。

挑戦してみて良かったこととして、
開発時間はすごく減りました。
特にパターンマッチがあるためActionの解釈が楽でした。
まだやったことはないのですが、ホットコードスワッピングがあるためWebSocketを使ったアプリでもデプロイが簡単だと思います。

しかし、デメリットもありました
まず、Elixirを書くのにVimの設定が大変でした。
また、まだ理由はわかっていないのですが、vagrant上で実行しても、つまりネットワークレイテンシがほぼゼロでもリクエストからレスポンスまで1秒近く待たされます。
ここは引き続き調査します。
Reduxそのものというライブラリがなかったので自分で書かなければいけないものも多かったです。

結論としては
まだ時期尚早だと思いました。
でも未来は感じました。
ちょっとした社内ツールならOKという時代はきそうです。

ありがとうございました。

** 5分 **

Publicada em: Tecnologia
no profile picture user

  • Entre para ver os comentários

AngulaとElixirの新しい関係

  1. 1. 社内ツールを作って得た気づき
  2. 2. AngularとElixirの 新しい関係 @isyumi_net 谷出陸
  3. 3. お前誰よ 名古屋でプログラマーしてます。 自宅 -> Dart 会社 -> Go/TypeScript
  4. 4. 問題提起 最近のフロントエンドまじ面倒くさい
  5. 5. 確かに便利になった Angular or React 手続きではなく変数でViewを管理できるようになった
  6. 6. 型安全な言語 Dart TypeScript
  7. 7. 状態の管理は依然、面倒くさい
  8. 8. 解決策１ Redux 安全になったのはいい コード量が増えたのが辛い
  9. 9. 解決策２ Rx的なものを使う 全てをイベントストリームとして捉える そこそこいい選択肢 頭使う
  10. 10. 辛い
  11. 11. わかってくれる人？
  12. 12. 僕らが触れている 状態とは どのようなものか
  13. 13. 状態のスコープ サーバーサイドからのデータ 例）チャットのメッセージ一覧 ユーザーの入力 例）チャットのインプットフォーム
  14. 14. なぜ辛いのか Webアプリのライフサイクル 1. サーバーからデータを取ってくる 2. Modelにキャッシュする 3. 表示する 4. ユーザーの操作でModelを書き換える 5. サーバーに書き込む
  15. 15. つまり 真実が サーバー クライアント 二つある
  16. 16. フレームワーク対決！Angular VS React仮想パネルディスカッ ション https://html5experts.jp/yoshikawa_t/14459/
  17. 17. MVC二階建ての部分の引用 （4/1 編集 特に許諾とかとってないので消しました）
  18. 18. 1階建てにしよう
  19. 19. お題 社内で使うリアルタイムチャット 同じオフィス(=ローカルネットワーク)にいる
  20. 20. 提案
  21. 21. 具体的に クライアントをAngularで書く WebSocketでPhoenixに接続 Phoenixでは全てのStateをメモリ(Agent)で保持 ユーザーのイベントは全てWebSocketで送信 Phoenixで全員に最新のViewの状態を配信 WebSocketからやってきたデータをAnguarにそのまま渡す
  22. 22. 1階建てになった！
  23. 23. 良かったこと 開発時間の短縮につながった パターンマッチがあるためActionの解釈がしやすかった おそらくHot Code-Swappingが効いてくる
  24. 24. デメリット vimの設定が大変だった 遅い vagrant上で1000ms EC2 東京リージョンにサーバーを置くと 1100ms Redux的なものをElixirで手書きしなければいけなかった ズバリそのものというライブラリがなかった
  25. 25. 結論 時期尚早だった 未来は感じた 社内のちょっとしたツールならOKという時代も来るのでは
  26. 26. ありがとうございました Make Dartlang Great Again

×