I wrote in the past how WCF defaults limit scalability but this thing (which had cost me two days of head scratching) is even worse.
Consider the following scenario:

 You have a WCF service/resource. when you get a message/request your codes needs to send another message to another service.

Sounds common enough now doesn't it? and it is - unless you happen to use a service with   WebHttpBinding (e.g. if you try to develop a RESTful WCF service or want to use POX services).  When you use WebHttpBinding and try to make a call within a call you are likely to find yourself starring at a ProtocolException with a 405 error - Method not allowed. Turns out WCF finds itself confused by the Operation Context (OperationalContextScope) of the incoming request so if you want things to work properly you need to create a new one for the request

var webBinding = new WebHttpBinding();
var channel = new ChannelFactory(webBinding, controlUri);
channel.Endpoint.Behaviors.Add(new WebHttpBehavior());
var proxy = channel.CreateChannel();
using( new OperationContextScope((IContextChannel) proxy))
{
     proxy.Dostuff()
}

I already spent the time figuring this bugger out- I hope this post will save you the trouble

 

Back in may Andrew Binstock wondered "is the popularity of unit tests waning?" Andrew lists 5 indications he observed to support his conclusion:

1. Commercial tools are waning
2. Few OSS products
3. Unit testing is not taught by major Java instructors
4. Few books get published on unit testing
5. xUnit alternatives are completely invisible.

I am not sure I agree with all these observations, nevertheless,in a followup article in Java World Andrew continued to ask "Is unit testing doomed?".
Andrew says that two issues with unit testing are that they seem to offer little value and that the evangelism of unit testing in general and TDD in particular also causes antagonism (I can say from personal experience with introducing unit testing to long time C and C++ developers that, indeed, the initial responses are rather cold)

Andrew also quotes former CEO of Agitar (Jerry Rudisin) saying that "unit testing hasn't taken off as mainstream practice". A survey ran by Scott Ambler for Dr. Dobb's also found that "The more difficult practices, such as TDD and executable specifications, have lower adoption rates than easier practices such as daily scrum meetings." (although another survey by VisionOne found that within companies where agile practices are used 77% use unit testing and about 49% use TDD)

I recently read another interesting post on the subject, this time by Dan North about the "end of endotesting" explaining why the record-reply idium of most mocking framework is not intuitive and more easy to use mocking frameworks like mockito (his example) or Moq and Mocha (my examples) are better.

Now, yesterday I read Roy Osherov's post "Goodbye mocks, Farewall stubs". Roy makes similar observation on the adoption (or lack therof ) of unit testing practices. Roy believes the number one reason holding back unit testing is the learning curve associated with it and suggests we simplify the tools and terminology (and gives a example similar to Dan's mentioned above)

What we see is that both in the Java and the .NET worlds unit tests adoption hit a few snags. The way I see it there are event  additional barriers to wide adoption of unit test and TDD but I'll talk about that in part II where I'll also try to talk a little about what can/should  be done

Powered by ScribeFire.

 

(This part III of a series -see Part I, Part II)

We need to face it, there are no absolute truths when it comes to software architecture( I guess that's part of the reason the term always looks so fuzzy. ) Should we use REST? it depends. Should we use OR/M or direct database access? it depends. Sometimes even a big ball of mud can be a good option. The good news is that we can always answer "It depends" to any architectural question and always be correct. The bad news is that it is our role to figure out what does it depend on and come up with a viable trade off.

The fact everything is a tradeoff doesn't mean that there aren't any cases where the trade-off is simple. E.g. if you just have to build a couple of data entry screens and a simple database you probably shouldn't spend a couple of months evaluating your options, just write the damn thing in your spare time. Nevertheless, just hacking it can mean it wouldn't be extensible, it that's what you needed then cool. if not, maybe you should have considered that.

This is one of the reasons I don't like the term "best practices" - it sends out a "you don't have to think anymore" message which is oh-so-incorrect. Patterns on the other hand, don't send  out this message, as they also include discussion on where to use them as well as their limitations and pointers to other patterns. Unless of course, patterns are seen as an end-goal rather than a means, in which case, they look pretty close to "best practices"

To sum this post - everything is a tradeoff. The most important bit here is to keep that in mind, even when the choices seems obvious. Awareness  is the key to better decisions.

Powered by ScribeFire.

 

I've written a lot on the efforts in converging web and desktop applications (Adobe Air, Mozila Prism, Silverlight, JavaFX, Google Gears etc.). Now Google ups the ante with the introduction of its new webkit based browser - dubbed Chrome (You can see a comics explanation of its main concepts/features).

Let's do a quick recap before taking more about Chrome. Basically we see all the major players trying to blur the lines between desktop applications and web applications (a.k.a. Rich Internet Applications) some players are on the offensive (Adobe, Google) and some on the defensive (Microsoft, Sun) but the direction is identical. The web oriented companies understood that RIAs are becoming more real application and not "just" web pages. They also understand they need presence on the desktop for easier accessibility and better acceptance by users as a "serious" applications. Furthermore, the fact the applications become more serious and more mission critical, along with the fact that they can (and are) be used on-the-go where disconnects occur, the need for occasionally connecteness becomes more apparent. This is where smart-clients have a lead and technologies like Gears are trying to catch-up.

Now,in my opinion, Google makes a bold move to change the rules and re-define the playground - if webapss need to run on the desktop, let's make the browser the new desktop.
What makes me say that? because it is focused on application (see the comics),because the browser runs each tab in its own process, because it has a process monitor, because it is a link on the google home page...


From the chrome "OS" point of view we can look at javascript,HTML etc. as the IL (bytecode in java speak) on which the application run. This makes cross-compilers like GWT and the good side of MS Volta (vs. the bad side) the next abstraction layer. I expect these will be more significant in the future

Anyway, you can see for yourself if you download it now from www.google.com/chrome