昨今の流行りをもうこれでもかというぐらい盛り込んでいてタイトルだけでお腹いっぱい。読めるのはマイクロソフトテクノロジーの使い方的なドキュメントに留まっていた印象があるのですが、良い時代になりました。あとは機械翻訳さえ洗練されれば言うことなしですね。示されたものだった気がします。年間の積み重ねのなかで、どこかで生まれたものなのではないかと想像しています。Event?私の理解では「依存関係を逆転させるため」です。拡大解釈しすぎかもしれませんが、私は本質的に似通っているように感じています。いうところで登壇した時の自分の資料にちょうどいい図があったので埋め込みます。実行されるべきだと知っています。依存している状態です。実行されるべきだという知識を持たなくて良くなります。知らせることだけになります。依存はなくなりました。抽象度が十分に高ければ問題ないことが多いです。管理者ユーザーへのメール送信処理、とかですね。より依存関係を逆転させます。何ぞや、という話をし始めるとキリがないのでまた別の機会に。諸事情により今回の記事のネタになった実例を挙げづらいので無理やり別のところから例を持ってきます。企業の名刺データを一括管理できます。構築以外にも機能があります。上にリードや取引先責任者をつくる機能があったりします。書き込み処理の起動処理があるのは、名刺のテキストデータ化文脈から見ると不純物であり、不適切な依存であるというわけです。属するケースの典型例ですね。いった不適切な依存関係の解消に役立ちます。Event?息切れしてきたので駆け足で。Pub/Subモデルですから、まさにおあつらえ向きというわけです。トリガーされる、というのが容易に実現できます。転送における転送先用です。等から設定することになります。設定できないそうです。できる感じでしょうか、調べてませんが。メッセージを読み出すところを実装するのみです。メッセージを放り込むところ。新規作成しただけのコードに、放り込むコードを足しただけのものです。足したのは日本語でコメントした箇所です。シリアライズして放り込んだりすれば良いのでないでしょうか。}}そして受け取る側のコードはこんな感じ。バインドしているところがポイントです。転送を設定しているので、ちゃんとメッセージがやってきます。転送を設定するかです。的なものが実装されていないことです。呼び出しを含むとします。系のレスポンスコードを返してきたとします。エラーを表しますから、少し間を置いて同じリクエストを再度送ると、その時には成功する可能性があります。自身が備えているメッセージの再実行機構に乗っかることができます。つのメッセージの処理は長くなりすぎないようにした方が良いとされていますが、ループ的にリトライ処理をするとこれに反してしまうので、今回はメッセージの再実行機構に乗っかってリトライすることにします。他のメッセージが溜まっていない場合そうなります)。呼び出し先の外部サービスはエラーを返したのだから、さすがに少し間を置いてあげた方が良いと思われます。回目の実行の間隔は、長くした方が良いでしょう。放り込むようなコードを書くことになります。使っていると不都合が生じます。処理ですから、これは不適切です。転送することで取り回しが楽になりそうです。出た場合なんかにも、同じことが言えそうです。まとめ書いてるうちにとても長くなりましたが、この記事はこんなところで。発展途上感があります。今後の進化に期待ですね。2017で登壇しました。2016のようにレポートサイトが公開されるそうです。レポートサイトになったらURLが安定しそうですね。(2018-11-19追記)。大きな会場で多くの聴衆の前での登壇となり、内心おっかなびっくりだったのですが、ピンマイクを装着させてもらったことでちょっと楽しくなってしまい、壇上をウロチョロしながらオーバーアクションで喋ったら面白いかもしれない、等と思いつつウロチョロしておりました。思い切ったアクションというのは難しいもので、やはりこういうのは場数だな、等と思いながら楽しい時間を終えました。いった機会はありがたいものです。2017で登壇しましたTweet広告を非表示にするもっと読むコメントを書く2015-08-31『C#エンジニア養成読本』の一部を執筆しましたありがたいことに機会をいただき、『C#エンジニア要請読本』という書籍の一部を執筆しました。今回が初めての執筆です。初心者および初級者という感じ。どんなもんよ?」とパラ見するのにちょうど良さそうです。書けるとしたらこの辺ですかね~」となったからです。力はごくごく平均的なため、テーマが「C#」ではやっぱり厳しかったかも。自分の名前を検索したら出てくるってのは感動モノです。機会を下さった方々に感謝です。書いた仕事で使うためにやっつけで書いていたのですが、やってるうちに勢い余って割と作り込むあるあるを踏み抜き、せっかくなので公開することにしました。github.com何ができるかっていうと大したことはできません。片手間でできるものなんてそんなものですね。メール送信のスループット確認はい、それだけです。なんていうお洒落なものはありません。ソースコードダイジェストできるだけ素早くメール送信したいって時にはいろいろと常套手段があるようでして、私も全然専門じゃないもので詳しいことは分からないのですが、ある程度調べて分かったことは詰め込んでおります。万個スレッドを立ち上げるようなことはしません。スレッドプールのスレッドを申し訳なさそうに拝借して処理を始めてみて、どうやらもっとスレッドを増やした方が効率的みたいだぞ?といったことに自動的に気が付いて徐々に使うスレッド数を増やしていきます。分以上はかかった気がします。その間に送られたメールは数千通的な。いう話があるのでスループット確認には不向きですねってことで次のようにして初速を上げてます。コネクションを張ってドバドバっとメールを送るなんてことができません。本までは張れますが、残りはコネクションを張ることができず待たされます。コネクションと同じ感じですね。これだとスループット確認のために十分な負荷をかけられないので、こいつを増やします。中で以下のように書いてます。なんていうプロパティもあるそうで、これでも同じようなことができるようです。こいつの場合はエンドポイント別の指定ができませんが、ほとんどの場合こいつで十分そうですよね。