情報更新

last update 05/24 11:26

ツイート検索

 

@kyo_ago
サイトメニュー
Twilogユーザー検索

Twilog

 

@kyo_ago

Local Proxy@kyo_ago

Stats Twitter歴
4,010日(2007/06/02より)
ツイート数
45,477(11.3件/日)

ツイートの並び順 :

表示するツイート :

2018年05月23日(水)1 tweetsource

2018年05月22日(火)5 tweetssource

5月22日

@kyo_ago

Local Proxy@kyo_ago

typescript、string literal typeをinterfaceのkeyに展開するのは無理か。。。
(interfaceのkeyをstring literal typeにするのはできる)

posted at 15:32:52

5月22日

@kyo_ago

Local Proxy@kyo_ago

pac file proxy、第1引数のurlにurl渡してもらえないことに気づいた。。。
まあ、たしかにそうだけど。。。

posted at 10:18:51

2018年05月18日(金)7 tweetssource

5月18日

@kyo_ago

Local Proxy@kyo_ago

ただ、クライアントサイドだと、基本的に「DBのロック」は考えなくていい(考えられない)ので、そのへんも含めると結構集約単位がでかくなりやすい印象。
(サーバサイドで改めてトランザクションに合わせた集約に切り直してコミットする)

posted at 16:23:41

5月18日

@kyo_ago

Local Proxy@kyo_ago

クライアントサイドDDDやってると集約の単位があんまり自由にならんなーという印象。
(APIの単位に引きづられる)

posted at 16:07:03

2018年05月17日(木)2 tweetssource

2018年05月16日(水)5 tweetssource

5月16日

@kyo_ago

Local Proxy@kyo_ago

ノベルティ、個人的にはあんまり欲しい感じないけどあったほうがいいのかな?
(わりと匿名での報告も多いからそういうのいいのかと思ってた)

posted at 11:13:49

2018年05月15日(火)6 tweetssource

5月15日

@kyo_ago

Local Proxy@kyo_ago

なんか普段は「表と裏」くらいでしか意識してないなー
あとは随時必要になったらつくるくらいで

posted at 12:20:36

2018年05月14日(月)12 tweetssource

5月14日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem 適当に予約してもらって大丈夫ですー
食べられないものはないですー
(実際通勤経路なので「予約無しで適当にそのへんの店に入る」でも大丈夫ですよ。空いてなければ喫茶店とかでもいいし)

posted at 12:37:09

5月14日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem AServiceを複数箇所から参照する(少なくとも設計概念上AServiceは複数のinstanceを持たない)ので、もし、先に上げてもらった例を使うのであればAService内でSingletonの仕組みをもつ必要があると思います。

posted at 11:13:41

5月14日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem new Container({
defaultScope: "Singleton",
autoBindInjectable: true,
skipBaseClassChecks: true,
});
で、初期化してるので、Singletonにしたいんです。。。
(その方法だとすべて別のinstanceになる)

posted at 11:07:01

5月14日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem できないと思っています。
デフォルト引数にする場合、先に各classを広域変数としてinstance化しておく必要がありますが、その場合でも初期化順は開発者が考える必要があるので、「初期化順を考えるのが面倒」という部分は解決されないと思っています。

posted at 11:02:53

5月14日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem ところで、どっかで飯でも行って話すほうが早い気がしますがどうでしょうか?
(あまりお互いに内容が正しく伝わっていない気がしています)

posted at 11:00:43

5月14日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem (1)、それは含みません(headでも同じ構成になっています)
(2)、各class側で「injectableか否か」を定義すればServiceContext内で行っていた「どの順番で初期化するか?」を検討する必要がなくなりました。
((2)は質問の意図が余り理解できていない可能性が高いです)

posted at 10:58:53

2018年05月11日(金)19 tweetssource

5月11日

@kyo_ago

Local Proxy@kyo_ago

一応「コードを書く」とのことなので、それを見たいと思ってはいるけど、現状の認識では「一定以上の単位はmonorepoで割って、それ以下の単位ではDIで楽したい」と思っている派。。。

posted at 12:52:38

5月11日

@orga_chem

Kuniwak@バニラDI/Mockをやる者@orga_chem

@kyo_ago わかります。これの解決策をふわっとした言葉にすると「抽象層を通過するごとにオブジェクトをラップしていき、この過程で具体的パラメータを埋めていく」です。

ただ、具体的なコードがないと何もわからん、となると思うので後でコードを用意しますね。

Retweeted by Local Proxy

retweeted at 12:50:33

5月11日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem 「初期化順考えるのが面倒」というのは単純に「Aの初期化前に依存しているBを初期化しないといけない」みたいなのを考えるのが面倒というレベルなので、そもそも「面倒」のレベルが違うのではという気もしています。
(そもそもそうしないと動かないので間違えられないレベルの話)

posted at 11:33:50

5月11日

@kyo_ago

Local Proxy@kyo_ago

「そもそも上がってるサンプルは依存性の解決だけで、テストとかはDIのうまみが全く生きていないのでは」というのも「はい」とは思う。
(テストの粒度がでかいのでrequireレベルでのmockでやってる)

posted at 11:08:01

5月11日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem あ、「つらい」部分はテストコードではなく本体コード部分でした。
(そもそもテストではrequireレベルでmockしてたので、テストではDIあんまり使ってなかった。。。)

posted at 11:05:01

5月11日

@kyo_ago

Local Proxy@kyo_ago

「そもそも依存関係がそんなに頻繁に変わるのおかしくない?」って言われたら「はい」としか言えないんだけど、DIはそのへん楽でよかった。
classベースのDIならIDEのサポートも得られるし

posted at 11:02:56

5月11日

@kyo_ago

Local Proxy@kyo_ago

DIするなら依存関係を薄くして初期化の面倒くささをDIに担保させたほうがいいと思うし、Constructor Injectionなら多少依存関係深くして初期化を簡素化させたほうがメンテしやすくていいと思う。
自分は依存関係変える毎に初期化ファイルをメンテするのに疲れた。。。

posted at 11:01:26

5月11日

@kyo_ago

Local Proxy@kyo_ago

まあ、結局どこに複雑さを突っ込むかって気もするな。
DIで全体にバラすのか、Constructor Injectionで初期化ファイルに突っ込むのかの差というか

posted at 11:00:23

5月11日

@kyo_ago

Local Proxy@kyo_ago

初期化順考えるの面倒なの、「加齢では」って思ったけど、文字数制限的に書けなかったのでセーフ

posted at 10:57:12

5月11日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem ブログでは「一つのclassに多数の依存関係」の場合だったと思うんですが、「多数のclassに少ない依存関係」でも「依存関係のツリーを自分で構築して管理する」のは結構手間に感じてました。
このサンプルならまだいいほうですが、importだけで50個超えると手動で初期化順考えるのが面倒に。。。

posted at 10:56:27

5月11日

@kyo_ago

Local Proxy@kyo_ago

実際には「テストに向かない設計のままMockライブラリ使わず無理やりテストする」結果になることも多いと思うので、「高機能なMockライブラリに罪はないのでは」と思ったりはする。 // SWETの新メンバーから見て驚いたこと、そこから生まれたDIライブラリ不使用宣言 - DeNA swet.dena.com/entry/2018/05/

posted at 10:46:41

5月11日

@kyo_ago

Local Proxy@kyo_ago

もとは「テストに向かない設計のまま高機能なMockライブラリ使って無理やりテストしても価値が低い」ってところから来てるとは思うんだけど、
// SWETの新メンバーから見て驚いたこと、そこから生まれたDIライブラリ不使用宣言 - DeNA Testing Blog swet.dena.com/entry/2018/05/

posted at 10:46:29

5月11日

@kyo_ago

Local Proxy@kyo_ago

バニラMockに関しては自分がSinonJSになれてるからDIほど訴求を感じないかなー
ただ、Mock系は概念が独自で、なれてないとメリットが生かせないとは思う。
// SWETの新メンバーから見て驚いたこと、そこから生まれたDIライブラリ不使用宣言 - DeNA Testing Blog swet.dena.com/entry/2018/05/

posted at 10:43:44

5月11日

@kyo_ago

Local Proxy@kyo_ago

@orga_chem こういう感じで依存関係を手動で解決するのに疲れました。。。
もちろん面倒なだけでミスる可能性は低いですが、いい加減面倒になってDIに移行してます。
(ただ、DIだと循環参照に気づけなくて詰まったりするのでそこは良し悪しだと思ってます)
// github.com/kyo-ago/lifter
github.com/kyo-ago/lifter

posted at 10:23:08

このページの先頭へ