"メディアアーティスト"の話を聞いてきました
話の流れを押さえているというか自分が気になった部分をメモったものです。
メモを書いて考えたりしてたせいで結構聞いてない話とかありました（）
コンテンポラリーアートとメディアアート
既存技術の様式を批判する（という意味で技術の上に存在する、技術ありき）コンテンポラリアート
技術と人間の横並びを目指したメディアアート
既存の分野の"隣"にはあるものの直接には属さない、間（media）に存在する
e.g. ASMRは既存の枠組にには入れるのは難しい
Art&Science と Art&Technology の違い
個から世界をみるのがArt
世界から個をみるのはScience
人が産んだものがArt
科学が産んだものがTechnology
技術との協調について
脇田さんの話と資本社会
物質社会・消費社会の象徴としてのインスタへの批判。副作用を顕現させる、議論する。
- 衆からの理解
- お金？
- 資本社会は単純消費をどれだけ推し進められるかを追求している。世界の深さ面白さを捨てて。
- 議論自体の難しさ、飽食、考える事選ぶことを辞めた人たち
- 世界のすばらしさの片鱗を知っているからこそ議論をしようと思える
- そういう世界にしたい
ミック本読みました
いわゆるミック本を読みました。
達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ
- 作者: ミック
- 出版社/メーカー: 翔泳社
- 発売日: 2012/03/16
- メディア: 単行本（ソフトカバー）
- 購入: 21人 クリック: 316回
- この商品を含むブログ (24件) を見る
アーキテクチャパターンについて調べてみた
今日のスタートになった記事
Controllerは薄く書けとのことをひたすら読んだので実践したところ、ModelがFatになったり持っている機能の範囲が広くなりすぎたりするのが不満だったのと、２つ以上のModelにまたがった機能を実装するときその機能はどのModelの責任になるのかみたいな疑問に対してどんぴしゃでした。
これ読む前に自分でもアプリのユーザー体験に基づいた機能（ドメインロジックって呼ぶんでしょうか）を切り出して別クラスを作って、ModelをDBアクセスのためだけに使おうとかしてたんですが、なかなかうまく作れなかった。
その中で紹介されていた記事
実際に自分が陥っている問題の具体化だとか、対策としてどういうものがあるかなどがはっきり書いてあったのでよかった(SQLアンチパターン読まなきゃな)。あと自分が作ろうとしていたものがサービス層というものだということ（全ッ然違うけど）が分かっていろいろ調べられるようになったし、DDDって聞いたことあったけどそういうことだったのね、とか。DDDの本やばそうですね。DCIってなんぞ。。。レイヤーアーキテクチャっての面白そうだな。
やっていこうとは思うけど、ここに書いてあることをやってそれが本質的な問題解決につながるようになるには経験もスキルも足りなさすぎるなぁという感じ。
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
上の記事のスライドの中で出てきた「ドメインモデル貧血症」の話。
ビジネスロジックはあくまでドメインに記述すべきもので、アプリケーション層なんかはそこにタスクを投げるだけにするという意味でControllerは薄く書くものだという意味だったんだなと理解。
railsとかのどうでもよいメモ: DCI (data context interaction)
DCIってなんぞってわけで読んだ。
DCIとは全く関係ないんですが
そういう意味で、例えばデザインパターンのような技術者だけの道具が設計の初期に出てくるのはおかしい。技術者はえてしてそういう技術話が好きなものだが、ラムダとかデザインパターンとかmix-inとか、ビジネスロジックの出てこない道具は「syntax上」の道具でしかなく、これはつまり局所最適化にしかなりえない。それを全体レベルの最適化に使ってもうまくいくはずがない。こういう道具は局所戦でしか使ってはいけない。
ってところ、その通りだと思います。肝に命じておきます。
でDCIについてはここにはあまり書いてなかったので
を読みました。軽めの内容で読みやすかったです。
実際にこれ実践できると、Roleなどに応じてコードをどんどん分割できて綺麗に管理できそうですね。でもDCIってのは僕の求めている類の対策というよりは開発手法なのかな。今から急に採用してってことはできなさそうです。もし今度もっと使うのであれば勉強しないといけないですけど、今はDDDの方に興味があります。
サービスを作るときの責任の持たせ方の参考になりました（OOが分かってない顔）。
上の記事と合わせて責任の分け目ってこういうところに作るんだなって。
アプリケーションのレイヤー化についてよく分かってなかったので自分で読みやすいものを探してきた。
ドメイン層だけじゃなくてアプリケーション層なども合わせて読んで理解が深まりました。依存関係のところとかしっかり守ってカプセル化とかうまくやっていきたいです。
でもこれこのJavaのフレームワークの思想はこうですよっていう内容だしDDD原本はまだ怖いので
https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html
の内容なんかを時間があるとき読もうと思います。
あんまりかいつまんだ勉強をしてもなんだか正しい理解なのか不安になりますね。。とりあえず自分で実践していくときは読んだ内容はあくまで参考としていくということにします。
アプリケーションっていうのは問題解決のためのものであり、コードはその解決のある部分を担うという意図を持って書かれている。コードはアプリの機能のロジックを実現するものであったり、他のコードからツールとしてだけ使われるものだったりする。そのような性質によってコードの置かれるべき階層などに分けて、コードの再利用やコード同士の疎結合を実現しようとしている。
ということだけ頭においておきます。
こんな理解であってるんでしょうか。
