Development Experience(s)

(This is part 2 of my notes from the ADSD-SOA course. You'll find part 1 here .) Due to the fallacies we have already discussed, whenever possible, favor in-process execution over remote procedure calls. An in-process call, takes about 10 microseconds to execute. A Remote Procedure Call over the Local Area Network, takes somewhere between 500 microseconds to 1 millisecond, i.e. 50 - 100 times slower than the in-process one. When we step out into a Wide Area Network, we end up with call times of about 50 milliseconds. That is another 50 times slower. Now, imagine that we have a remote object on which we read or write a couple of properties. Not scared yet? What if we put the calls in a loop. But we don't write code like this, right? Enter Inversion of Control and Dependency Injection. IoC is great, don't get me wrong. However, a caveat of this technology, is that you do not know whether or not your service is local or remote. In fact, that's one of its value proposit

A couple of weeks ago now, I had the opportunity to partake in Udi Dahan's excellent ADSDS course in London. For my own sake (to better absorb the course through repetition), as well as for you (to, perhaps, learn something new) and, at the same time, toss some credits Udi's way, what follows is a collection of notes that I took during the course. No, I won't share the slides. If you find the notes interesting, book the course through Skills Matter , or through Particular Software . It's well worth your time ;-) Meta Udi comes across as a very calm, collected and professional in the way he teaches his class. With intermixed breaks, he keeps his students attentive throughout all five days of his course. I was very impressed by his teaching skill alone. Systems are not Applications Historically, we haven't had to deal with the term  connectivity , really. This is not something that is baked into the mainstream programming languages. Similarly, pattern books

Know your tools. Today, I learned that to successfully run NServiceBus tests through NCrunch - and this is really related to the IoC aspects of NServiceBus why it's not product specific - you need to do a little more with regards to your test setup than just doing Test.Initialize(); I ran into the following output in the NCrunch error window: System.ArgumentException: Could not find a concrete type mapped to IfInsurance....IPolicyActivatedMessage    at NServiceBus.MessageInterfaces.MessageMapper.Reflection.MessageMapper.CreateInstance(Type t)    at NServiceBus.MessageInterfaces.MessageMapper.Reflection.MessageMapper.CreateInstance[T]()    at NServiceBus.MessageInterfaces.MessageMapper.Reflection.MessageMapper.CreateInstance[T](Action`1 action)    at NServiceBus.Testing.StubBus.CreateInstance[T](Action`1 action) in c:\BuildAgent\work\d4de8921a0aabf04\src\testing\StubBus.cs:line 242    at NServiceBus.Testing.Handler`1.OnMessage[TMessage](String messageId, Action`1 initializeM