Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component

https://lapras.connpass.com/event/179777 の登壇資料

サンプルコード
https://github.com/tooppoo/sample-for-vue-with-design-patterns
http://localhost:8080/first-class-collection-pattern/on-memory

参考資料
・オブジェクト指向UIデザイン──使いやすいソフトウェアの原理
ソシオメディア株式会社 (著)、上野 学 (著、監修)、 藤井 幸多 (著)
・MVCとはなにか
　・tenjuu99
　・https://speakerdeck.com/tenjuu99/what-mvc-is
　・https://note.com/tenjuu99/n/n0232ccd1089d
　・https://note.com/tenjuu99/n/nbbb4b273676d
・MVC
　・Trygve Reenskaug
　・http://folk.uio.no/trygver/themes/mvc/mvc-index.html
・未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明
　・Michael Hiltzik（著）エ・ビスコム・テック・ラボ（監訳）鴨沢眞夫（訳）

関連する過去発表
・WEBフロントエンドにおけるソフトウェア設計の考察
　・https://speakerdeck.com/tooppoo/consideration-of-software-design-in-web-front-end
・Vue.js + デザインパターンによるコンポーネント実装
　・https://speakerdeck.com/tooppoo/vue-dot-js-dezainpatan-niyorukonponentoshi-zhuang-v2
・複雑なv-ifに負けないために
　・https://speakerdeck.com/tooppoo/fu-za-nav-ifnifu-kenaitameni

Transcript

1. Fat Componentにしないための
   Webフロントエンド設計
   1
   @Philomagi
   2020/07/31@Remove.vue #2
   #remote_vue
   

   View Slide

2. 発表者
   @Philomagi
   ● WEB系プログラマ
   ● 自称フロントエンド寄り
   ○ 最近のマイブームは SelfとSmalltalk
   ○ vanila jsも久しぶりにちょっと触りたい
   ● 設計の話とかが好きです
   ○ DDDとかクリーンアーキテクチャとか
   ○ 最近のSOLID原則の推しはI
   2
   

   View Slide

3. 今回のテーマ
   3
   

   View Slide

4. Fat Componentにしないための
   Webフロントエンド設計
   4
   

   View Slide

5. 注
   以降、特に断りが無い場合は
   「フロントエンド = Webフロントエンド」
   の意味で使います
   5
   

   View Slide

6. 注
   理由
   ● 題材のベースがVue.jsである
   ● 発表者自身、Webフロントエンド以外のフロントエ
   ンド（デスクトップクライアント、iOS、Android）に
   詳しくない
   6
   

   View Slide

7. Fat Component
   7
   

   View Slide

8. 8
   ほんとうにあったVueコンポーネント
   

   View Slide

9. View Slide

10. 10
    ←全体のおよそ1/5
    

    View Slide

11. 11
    約20行<br/>

    View Slide

12. 12
    約20行<br/><template> 約200行<br/>

    View Slide

13. 13
    約20行<br/><template> 約200行<br/><script> 約2200行<br/>

    View Slide

14. 14
    全体で
    

    View Slide

15. 15
    全体で
    約2500行
    

    View Slide

16. どうすれば防げたか
    or
    どうすれば改善できるか
    16
    

    View Slide

17. 主張
    17
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するためのルール・制約・知識は、コンポーネントから
    は独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する
    

    View Slide

18. 主張
    18
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するためのルール・制約・知識は、コンポーネントから
    は独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する
    

    View Slide

19. 主張
    19
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントか
    らは独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する
    

    View Slide

20. 主張
    20
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントか
    らは独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する
    

    View Slide

21. 主張
    21
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントか
    らは独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する
    

    View Slide

22. コンポーネントを
    もっと細かく分割する？
    22
    

    View Slide

23. コンポーネント分割の効果と限界
    ● やの肥大化に対しては効果的<br/>○ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる<br/>○ スコープが限定されることで、実装自体も単純化しやすい<br/>● <script>の肥大化に対しては限界がある<br/>○ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い<br/>■ v-if による表示分けのための計算など<br/>○ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難<br/>■ 振る舞いが子コンポーネントに依存するため<br/>■ 「デザインは変わるが振る舞いは変わらない」が困難になる<br/>23<br/>

    View Slide

24. コンポーネント分割の効果と限界
    ● やの肥大化に対しては効果的<br/>○ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる<br/>○ スコープが限定されることで、実装自体も単純化しやすい<br/>● <script>の肥大化に対しては限界がある<br/>○ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い<br/>■ v-if による表示分けのための計算など<br/>○ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難<br/>■ 振る舞いが子コンポーネントに依存するため<br/>■ 「デザインは変わるが振る舞いは変わらない」が困難になる<br/>24<br/>

    View Slide

25. コンポーネント分割の効果と限界
    ● やの肥大化に対しては効果的<br/>○ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる<br/>○ スコープが限定されることで、実装自体も単純化しやすい<br/>● <script>の肥大化に対しては限界がある<br/>○ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い<br/>■ v-if による表示分けのための計算など<br/>○ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難<br/>■ 振る舞いが子コンポーネントに依存するため<br/>■ 「デザインは変わるが振る舞いは変わらない」が困難になる<br/>25<br/>

    View Slide

26. コンポーネント分割の効果と限界
    ● やの肥大化に対しては効果的<br/>○ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる<br/>○ スコープが限定されることで、実装自体も単純化しやすい<br/>● <script>の肥大化に対しては限界がある<br/>○ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い<br/>■ v-if による表示分けのための計算など<br/>○ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難<br/>■ 振る舞いが子コンポーネントに依存するため<br/>■ 「デザインは変わるが振る舞いは変わらない」が困難になる<br/>肥大化の全ての要因をコンポーネント分割のみで解決するのは困難<br/>26<br/>

    View Slide

27. 実装例
    27
    

    View Slide

28. 28
    実装サンプル
    https://github.com/tooppoo/sample-for-vue-with-design-patterns
    

    View Slide

29. 29
    実装サンプル
    

    View Slide

30. 実装サンプル
    カート内には
    複数の商品が存在する
    30
    

    View Slide

31. 実装サンプル
    31
    ・買う個数を変更
    ・カートから削除
    ・削除せず後で買う
    といった操作が可能
    

    View Slide

32. 実装サンプル
    32
    カート内の
    ・購入する商品数
    ・購入時の合計金額
    を表示
    ただし、後で買う商品は除外
    

    View Slide

33. まずどこに注目するか
    33
    

    View Slide

34. まずどこに注目するか
    34
    ● UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い
    （≠データ）に注目する
    ○ 「何がどのように見えるか」より先に、
    見せるべき知識・情報は何か、それらはどのよう
    な構造・関連を取るか、に注目する
    

    View Slide

35. まずどこに注目するか
    35
    ● UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い
    （≠データ）に注目する
    ○ 「何がどのように見えるか」より先に、
    見せるべき知識・情報は何か、それらはどのよう
    な構造・関連を取るか、に注目する
    ● ユーザーは「カート内商品」の集まりである「カート内商品の一覧」に対して、特
    定のカート内商品を「後で買う」「削除する」という操作を行うことができる
    

    View Slide

36. まずどこに注目するか
    36
    ● UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い
    （≠データ）に注目する
    ○ 「何がどのように見えるか」より先に、
    見せるべき知識・情報は何か、それらはどのよう
    な構造・関連を取るか、に注目する
    ● ユーザーは「カート内商品」の集まりである「カート内商品の一覧」に対して、特
    定のカート内商品を「後で買う」「削除する」という操作を行うことができる
    ● ユーザーは「カート内商品の一覧」に基づいて、合計数や合計金額を知ることが
    できる
    

    View Slide

37. 商品カートの構造
    37
    

    View Slide

38. 商品カートの構造
    ユーザーへ情報・振る舞いを
    提示するためのUIパーツ構造
    38
    

    View Slide

39. 商品カートの構造
    UIを通じてユーザーが得る
    情報・振る舞い
    39
    

    View Slide

40. 商品カートの構造
    40
    

    View Slide

41. 商品カートの構造
    41
    

    View Slide

42. 商品カートの構造
    UIとユーザーの間で発生する
    やり取り・相互作用
    42
    

    View Slide

43. 実際のコード
    43
    

    View Slide

44. 主張（再掲）
    44
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントか
    らは独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する
    

    View Slide

45. 45
    Vueコンポーネント
    

    View Slide

46. 46
    Vueコンポーネント
    

    View Slide

47. 47
    Vueコンポーネント
    

    View Slide

48. 48
    Vueコンポーネント
    

    View Slide

49. 49
    Vueコンポーネント
    コンポーネントのに書く内容は<br/>・htmlとオブジェクトプロパティ<br/>・イベントとオブジェクト操作<br/>のマッピングでほとんど終わる<br/>

    View Slide

50. 50
    Vueコンポーネント
    複雑な処理や計算は
    コンポーネントから切り出した
    個々のオブジェクトに任せる
    

    View Slide

51. 51
    Vueコンポーネント
    Vueコンポーネントは
    如何に知識を構成・表示・表現するか
    に注力する
    

    View Slide

52. 52
    Vueコンポーネント
    UIは詳細な処理・計算よりも
    ユーザーに何を伝え、何を示すか
    に注力する
    

    View Slide

53. コンポーネント以外のコード
    53
    

    View Slide

54. コンポーネント以外のコード
    54
    要するに
    普通のjavascriptのコード
    

    View Slide

55. コンポーネント以外のコード
    55
    普通のjavascriptのコードなので
    テストに必要な準備も最低限
    

    View Slide

56. コンポーネント以外のコード
    56
    普通のjavascriptのコードなので
    オブジェクト指向でも関数型でも
    既存の方法論を活用可能
    

    View Slide

57. 考え方
    57
    

    View Slide

58. ユーザーの関心事に注目する
    58
    ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄
    （＝知識・振る舞い）に注目する
    ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」
    ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする
    ■ FYI 「未来を作った人々」
    ● 注目すべき事柄をオブジェクトとして定義し、可視化する
    ○ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の
    相互作用（= interaction）も、「オブジェクト（目当て、対象）」に含まれる
    ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理してい
    く
    

    View Slide

59. ユーザーの関心事に注目する
    59
    ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄
    （＝知識・振る舞い）に注目する
    ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」
    ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする
    ■ FYI 「未来を作った人々」
    ● 注目すべき事柄をオブジェクトとして定義し、可視化する
    ○ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の
    相互作用（= interaction）も、「オブジェクト = 注目すべき事柄」に含まれる
    ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理してい
    く
    

    View Slide

60. ユーザーの関心事に注目する
    60
    ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄
    （＝知識・振る舞い）に注目する
    ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」
    ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする
    ■ FYI 「未来を作った人々」
    ● 注目すべき事柄をオブジェクトとして定義し、可視化する
    ○ 「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の相互
    作用（= interaction）も、「オブジェクト = 注目すべき事柄」に含まれる
    ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理してい
    く
    

    View Slide

61. ユーザーの関心事に注目する
    61
    ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄
    （＝知識・振る舞い）に注目する
    ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」
    ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする
    ■ FYI 「未来を作った人々」
    ● 注目すべき事柄をオブジェクトとして定義し、可視化する
    ○ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の
    相互作用（= interaction）も、「オブジェクト = 注目すべき事柄」に含まれる
    ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理してい
    く
    

    View Slide

62. FW・ライブラリとどう付き合うか
    62
    ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利
    用する」か？
    ● FW・ライブラリは、自分たちが直面している課題を解決するための道具の一つでは
    あっても、特効薬そのものにはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか？
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    （実際、Vueは知識・振る舞いを構造化する方法は提供しない）
    

    View Slide

63. FW・ライブラリとどう付き合うか
    63
    ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利
    用する」か？
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか？
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    （実際、Vueは知識・振る舞いを構造化する方法は提供しない）
    

    View Slide

64. FW・ライブラリとどう付き合うか
    64
    ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利
    用する」か？
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか？
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    （実際、Vueは知識・振る舞いを構造化する方法は提供しない）
    

    View Slide

65. FW・ライブラリとどう付き合うか
    65
    ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利
    用する」か？
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか？
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    （実際、Vueは知識・振る舞いを構造化する方法は提供しない）
    

    View Slide

66. FW・ライブラリとどう付き合うか
    66
    ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利
    用する」か？
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか？
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    （実際、Vueは知識・振る舞いを構造化する方法は提供しない）
    

    View Slide

67. FW・ライブラリとどう付き合うか
    67
    ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利
    用する」か？
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか？
    ○ 個人的には、Vue（のSFC）の html/css/js がそれぞれ自身の世界観を維持し
    ている形が好き
    ○ Reactのような全てをjsの世界に引き込むのは、シンプルでプログラミングフレン
    ドリーなのだろうけれど、あまり好きではない
    

    View Slide

68. ● 「サーバーの「データ」をプリントするだけなんだから、フロントでやること
    は何も無い」
    ○ 振る舞いはどこにいった？
    ● サーバーで提供・管理できる情報には限界が有る
    ○ 画面側の一時的・揮発的な情報は、サーバーでは管理しようが無い
    ○ 画面内部の動的な状態遷移も、サーバーでは管理・定義のしようが無い
    ■ ex. ユーザー操作に伴うUIパーツ表示のON/OFF
    ● 知識ではなく、データに強く注目・依存する考え方？
    「JSON色付け係」
    68
    

    View Slide

69. ● Smart UI アンチパターンが戒めているのは何もかもが区別無く一箇所に混在し
    た状態で、「画面に何らかのロジックが存在すること」ではない
    ○ 「何もかもが区別無く一箇所に混在」 → 全部入りのVueコンポーネント
    ● 画面の状態や操作に関する「ロジック」を、画面以外の誰が管理するのか
    ○ 動的な表示変更も、一切のユーザー操作も提供しない
    LPなら、「ロジック」は無いと
    言って良いかもしれない
    ○ しかし、LPを基準として語れるほど、現代のフロントエンドソフトウェアは単純ではいら
    れなくなっている
    ● 「ロジック = ビジネスロジック」ではない
    ○ ビジネスロジック ∈ ロジック
    Smart UI アンチパターン
    69
    

    View Slide

70. View Slide

71. 私たちの生活は今、コンピューターテクノロジーに囲まれており、仕事や遊び
    の場はますますソフトウェアの中へと移動しています。私たちはもはや物質や
    距離を意識せずに情報へアクセスし、コミュニケーションができます。私たち
    は1日の多くの時間をソフトウェアの世界で過ごしているのです。私たちがソフ
    トウェアを利用する際に接するユーザーインターフェース（UserInterface：UI）
    は、もはやバーチャルな比喩的存在ではなく、リアルな目当て[オブジェクト]そ
    のものなのです。
    オブジェクト指向UIデザイン──使いやすいソフトウェアの原理　「はじめに」
    ([ ] 内は発表者による)
    71
    

    View Slide

72. 私たちの生活は今、コンピューターテクノロジーに囲まれており、仕事や遊び
    の場はますますソフトウェアの中へと移動しています。私たちはもはや物質や
    距離を意識せずに情報へアクセスし、コミュニケーションができます。私たち
    は1日の多くの時間をソフトウェアの世界で過ごしているのです。私たちがソフ
    トウェアを利用する際に接するユーザーインターフェース（UserInterface：UI）
    は、もはやバーチャルな比喩的存在ではなく、リアルな目当て[オブジェクト]そ
    のものなのです。
    オブジェクト指向UIデザイン──使いやすいソフトウェアの原理　「はじめに」
    ([ ] 内は発表者による)
    72
    

    View Slide

73. まとめ
    ● 「Vueを使っているから」とVueコンポーネントに何でもかんでも詰め込む
    と、程なくFat Componentに到達する
    ● どこまでをVueに頼り、どこからは自分たちの領域として守りたいのかを
    考える
    ● UIパーツだけでなく、その奥に潜む知識・情報・振る舞いにも注目し、構
    造化し、洗練させていく
    ● 知識・情報・振る舞いの精査を通じて、自分たちが実現しようとしている
    ものを深く理解し、ソフトウェアに反映していく
    73
    

    View Slide

74. 雑感
    74
    ● 古典的なMVCへ回帰する可能性
    ○ 実装のための「MVCパターン」というよりは、ソフトウェアの役割を規
    程するものとしてのMVC
    ○ Trygve Reenskaug
    ● OOUIとの接続
    ○ この発表では、デザインよりプログラムに寄った視点から「オブジェ
    クト指向」+「UI」に注目している、とも言えるかも
    ○ 行き着くところは似通いそう
    

    View Slide

75. 参考資料
    75
    ● オブジェクト指向UIデザイン──使いやすいソフトウェアの原理
    ○ ソシオメディア株式会社 (著)、上野 学 (著、監修)、 藤井 幸多 (著)
    ● MVCとはなにか
    ○ tenjuu99
    ○ https://speakerdeck.com/tenjuu99/what-mvc-is
    ○ https://note.com/tenjuu99/n/n0232ccd1089d
    ○ https://note.com/tenjuu99/n/nbbb4b273676d
    ● MVC
    ○ Trygve Reenskaug
    ○ http://folk.uio.no/trygver/themes/mvc/mvc-index.html
    ● 未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明
    ○ Michael Hiltzik（著）エ・ビスコム・テック・ラボ（監訳）鴨沢眞夫（訳）
    

    View Slide

76. ご清聴ありがとうございました
    76
    

    View Slide