と
のツイ談
@neuecc よく@ufcppにぃにが言うC#の「howからwhatへ」みたいな、実装レベルではない概念論を学ぶ機会が欲しいんです。それが学ぶ同期になる。何せ実際僕にとって、今まではただのDSLという認識だったので。
2010-12-22 12:36:39 - 返信元ツイートを取得する
数か月前に蒲田で見かけたのと同一人物？ RT @ugaya40: RT @atsumispc: 学大駅前でスパイダーマンがティッシュを配ってる。相当おもしろい http://yfrog.com/h5a4cj
2010-12-23 16:55:31 - 返信元ツイートを取得する
@ugaya40 async/awaitは、やっぱWPFとかで使う前提で、同期コンテキストで元スレッドに戻ってきて単一スレッド動作になる方を望んでるみたい。実際、IO待ちの非同期にマルチスレッド要らないし。
2010-12-23 20:22:48 - 返信元ツイートを取得する
@ugaya40 いや、使いまくる。DBサーバーへのアクセスとか秒単位でかかりますし。IsBusy=true;await DBからデータ持ってくる;IsBusy=false;とか最近割と定型句。
2010-12-23 20:31:26 - 返信元ツイートを取得する
@ugaya40 複数データでそれやるときも。IsBusy=true;foreach await なんたら;IsBusy=false; なんたらのとこでUI要素にバインドしたプロパティにデータ入れてく。
2010-12-23 20:39:52 - 返信元ツイートを取得する
@ugaya40 まあ、同期的に書いたときとの差がawaitの文字だけなのと、lockとかDispatcher.Invokeが消えるのくらいですね。そしてそれが非常に大きい。
2010-12-23 20:45:45 - 返信元ツイートを取得する
@ugaya40 TaskEx.WhenAll的な動作するなら同期コンテキストないとマルチスレッド動作しちゃってlock必要になるんだけども、VM側に書くコードじゃないか。どうだろ。モデル自体がTask GetXxxAsync()とかの中でそういうことしてると危ないかも。
2010-12-23 21:35:18 - 返信元ツイートを取得する
@ugaya40 すっごい恣意的だけども、 http://goo.gl/b9atP こういうコード書いた場合、Foo().Wait()はコンソールアプリだとlockないとcount狂う可能性あるけど、WPFだと競合しないこと保証される。
2010-12-23 21:42:54 - 返信元ツイートを取得する
@ugaya40 http://goo.gl/9RU3q WPFなら全部スレッドIDが1（lockなしでも競合しない）、コンソールだとバラバラになる（lock必須）。
2010-12-23 21:54:44 - 返信元ツイートを取得する
@ugaya40 順番保証はないですね。普通にTask終了後にSynchronizationContext.Post(()=>continuation(task));呼んでるだけなので。
2010-12-23 21:59:45 - 返信元ツイートを取得する
@ugaya40 TaskEx.Delay(ms)は、Task.Factory.CreateNew(() => {Thread.Sleep(ms);})と思ってください。
2010-12-23 22:00:51 - 返信元ツイートを取得する
@ugaya40 今みたいなcount程度のものならlock確保と解放は同一スレッドでやれるんで大丈夫かと。とはいえ、まあ、ポイントはそのコードが全部単一スレッドで動くという仕組み。デッドロックが怖いならマルチスレッドやめればいいじゃない！
2010-12-23 22:05:00 - 返信元ツイートを取得する
@ufcpp あるいはModelにDispatcher持たせるとか。DipatcherObjectにしちゃったらVMから呼べないｗから、ModelのプロパティとしてコンストラクタでBeginInvokeで作って持つｗ。VMはそのDispatcher経由でModelを呼ぶとか。
2010-12-23 22:10:24 - 返信元ツイートを取得する
@ufcpp あれ?。冗談のつもりがそれで良い気がしてきた。でもVM内で複数のdispatcher管理するの嫌だなぁ。でもなんかこのアイデア発展する気がしてきましたー。
2010-12-23 22:11:50 - 返信元ツイートを取得する
こういう話もあるので。 RT @ufcpp: @ugaya40 http://goo.gl/9RU3q WPFなら全部スレッドIDが1（lockなしでも競合しない）、コンソールだとバラバラになる（lock必須）。
2010-12-23 22:16:49 - 返信元ツイートを取得する
@ugaya40 async使うなら同期コンテキスト自作して最初にSwitchToするだけでいいのだけども。ただ、知らずに使われた場合が怖く。
2010-12-23 22:22:58 - 返信元ツイートを取得する
@ufcpp それも一つですねw。でもそもそも議論が発生した原因がコミュニティの構造的な問題な気もします。とりあえず態度は変えようかと。荒い方向に。
2010-12-24 20:10:21 - 返信元ツイートを取得する
@ugaya40 ただ、そのやりかたで、どうRaiseCanExecuteChangedを実装すべきかに少々迷ったりも。CanExecuteが必要ない場合の簡易的な解だと思うのもありですが。
2010-12-26 00:32:30 - 返信元ツイートを取得する
@ugaya40 まあ、長年、「大手サイトのエイプリルフールネタを真に受けて大混乱」みたいなの何度も見てきてるんで、ネタはネタだと書くけども。
2010-12-26 16:40:39 - 返信元ツイートを取得する
@ugaya40 うーん、DSLとかコード生成とか見こすならLightSwitchみたいにデータ駆動でDBスキーマとかUIも生成な方にふることもできるし、MVVMでコミュニティ1個作る必要があるかどうか。
2010-12-27 02:42:10 - 返信元ツイートを取得する
@ufcpp むしろこの前からちょっと気になっていたんですが、WCF RIA Service + Silverlight + EntityFrameworkみたいな要件ごとに複数の実装パターンが考えられるものを手分けして探すコミュニティがあってもいいかな、とは思います。
2010-12-27 02:43:30 - 返信元ツイートを取得する
@ufcpp MSさんも手がそこまで回らないみたいですし、それこそコミュニティでできる事だな、と思っていたりもします。実際問題は多々あるでしょうが。
2010-12-27 02:45:07 - 返信元ツイートを取得する
@ugaya40 広い範囲カバーするの大変ですもんね。個々に調べて持ち寄る形式だと、全体のディレクションがなかなかに大変そうですけども。
2010-12-27 02:51:11 - 返信元ツイートを取得する
@ufcpp 実はそこら辺、僕が個人的に会う何人かの方に相談をもちかけていたりもしていて、多分複数回の会合をする形式を取るんだろうな・・とか考えていたり。いろいろ話したいことがですね。。
2010-12-27 02:52:41 - 返信元ツイートを取得する
@ugaya40 そうそう。なので実はあんまり個人のタレントに頼るのは好きじゃなく。漫画なんか、作家個人の我が出る職業の代名詞だったけども最近ではプロダクション制も結構あったり。技術記事もそういう方向にできないかなぁとか思っていたり。
2010-12-27 03:01:38 - 返信元ツイートを取得する
@ufcpp 今回MVVM追ってていろいろ見えましたが、要素技術を追う人は十分にいますけど、その結合の仕方をアウトプットしている人は少ないです。要素技術を追う事は最も大事な基本で、決しておろそかにするべきではないですが、決してそれだけではないだろうと。
2010-12-27 03:07:45 - 返信元ツイートを取得する
にらめったーはご覧のスポンサード リンクの提供でお送りしました
と
のツイ談コメント一覧
と
のツイ談を転送する
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
vs
