#teppeis_sushiというイベントで、Faao - ドメイン駆動設計で作るGitHub Issue Client -という話をしました。

image

Electronやブラウザなどで動くfaaoというGitHubクライアントを書いていてそれの技術的な話です。 クライアントサイドでDDDを取り入れた設計になっていて、その設計や規約の作り方やそれを守る方法についての話をしました。

Living Documentation by design, with Domain-Driven Design by Cyrille Martraire [PDF/iPad/Kindle]という無料から買える書籍では、ドキュメントとコードを同じ速度で成長させていくためにはドキュメントに対しても自動化が必要であるなど(コミュニケーションの話なども)が書かれています。

それらを参考にして、レイヤーの違反を自動的に見つけたり、Faao - UseCase architectureのようにコードからユースケースの図を自動生成したりなど、モデリングへのフィードバックループができるようにしているという話です。

Vue.jsでSSR

最近Electronでローカルプロキシを作っていてこまったこと - kyo_ago

  • クライアントとサーバで両方データがある感じ
  • クライアントのデータはサーバのキャッシュにすぎないので嘘のデータに見える
  • サーバへ送信するまでの一時的なデータであるならばそれは無理してモデル化するべきなのか
  • クライアントのデータはキャッシュでしかないならば、サーバに比べてDDDの魅力がオチている
  • ドメインの共有はIsomorphicで辞めたほうがいいかも
  • ドメインはクライアントとサーバで異なる
  • サーバから見たドメインは所有という概念がなかったりする
  • クライアントとサーバのドメインはアクターが異なるのでドメインモデルも異なる。 なので、クライアントとサーバで同じドメインモデルを共有することはできないのでは
  • サーバは「自分が持っている」という概念はないので

大規模フロントエンドのDDD - 83

  • 8人でやってるフロントエンドのチーム
  • スキルレベルがバラバラ感
  • Angular1だったものを2にする設計を始めた
  • 設計を担当して質問を受け付けるようになった
  • 些細な質問なども殺到して個人が開発する時間がなくなった
  • 質問ルームをslackチャットに作ってそこでやってもらったら質問が分散した
  • サーバのAPIを作ってる人とクライアントサイドを作って流人は別。
  • コンテキストがそもそも違う。 そこで腐敗防止層としてのDDDを取り入れる
  • サーバから渡ってきたものをリマップしてクライアント側に主導権を持てるように
  • AngularはViewは決まってるけど、設計は別に決まってない。
  • 無理難題が振ってくることがあるので、ngrxじゃなくて普通にrxをベースにして開発した
  • モデリングをちゃんとやることでコピペコードは減る
  • 1画面を作るのに7 APIを叩く

Faao - ドメイン駆動設計で作るGitHub Issue Client - - azu

  • クライアントサイドでTypeScript + Almin + DDDでの開発
  • Living Documentationについて

本の読み方 - t_wada

  • 本は未来方向には書けなくて、過去方向にしか書けない
  • 技術書を読むときは発刊された年数をちゃんと見る
  • 特に翻訳本はやたらと古い場合がある
  • DDD本はRailsが出る前に書かれたけど、翻訳はRailsのずっと後
  • 絶版ショック

Rx6の話 - laco

  • バグ修正によるBreaking Change
  • Rxを拡張してるユーザーには影響がある

api.aiの話 - vvkame

聞けてなかった

2017年のフォームの話 - 会長

スライド: 2017年のformの話 // Speaker Deck

  • Reactでのformの値の管理 unctrolledとcontrolled
  • FBとしてはcontrolledで管理して
  • ちょっと複雑なフォームをやるとバリデーションが複雑化する => controlled推奨
  • React/Redux/永続化されたState
  • どこで何を管理する?
  • Twitterはハイブリット的な構造
    • 入力中はコンポーネント、適宜Reduxへ
  • ユーザー入力中に外からpropsで値がすり替わるとIMEなどで問題が起きるため
  • 処理速度的にコンポーネントに閉じたほうが良いこともある

ES class fieldの話 - teppeis

スライド: ES Class Fieldsのプライベートフィールドがハッシュな変態記法なのは何でなんだぜ？

  • hard protectionは言語としてできることを目指すべき
  • Reflectとかで闇雲見られるようにはしない

flutterの話

Web Packaging - jxck

  • dispatchというWGで議論されて、どこで議論するべきなのかを決める
  • WGができたら結構すごいことになるかも
  • Service Workerの横つながりみたいな話がでてくるかも
  • 次回のプラハ会議に注目

その他

  • Nodeの進捗がよくわからない
  • CSPとバグとお金

おわり

おめでとうございます