If you have an issue with the wrong address in the WSDL of a WCF .NET 3.5 SP1 service that runs behind a load balancer, look at
Hope that saves you the time of writing a custom behavior to change the WSDL :).
Monday, February 27, 2012
Friday, January 27, 2012
Another case for code contracts
I stumbled upon one of the many articles on inversion of control (IoC). Interesting enough, one of the arguments the author used for utilizing interfaces was that it enabled you to safely change the actual implementation of the interface later on. I have to disagree on that point. In fact, in some way I think that depending upon a specific class rather than an interface is more 'honest'. Not saying that you shouldn't use interfaces: interfaces, combined with IoC, are very useful. One issue I have with many interfaces is that they are not defined in terms of pre-conditions, post-conditions and invariants. Without a contract you can still only guess what the interface provides to you. If you rely upon a specific class, you at least recognize that you are dependent upon the implementation details of that class. When you rely upon an interface without a contract, you are basically saying "I rely upon an interface that has no clear specification, but I trust anyone that implements it not to violate my interpretation of the interface." Code contracts are crucial for well defined interfaces.
On a related note: during the "meet the experts" session at the Windows Build conference I talked to some Microsoft employees about model checking. Their first reaction was, with a somewhat surprised look: "Do you develop driver software?" My answer was "Nope", but it was a clear indication that formal methods are still only generally accepted in very small pockets of our industry. Maybe over the next couple of years Microsoft will finally be able to make some of these formal methods readily available to all programmers.
On a related note: during the "meet the experts" session at the Windows Build conference I talked to some Microsoft employees about model checking. Their first reaction was, with a somewhat surprised look: "Do you develop driver software?" My answer was "Nope", but it was a clear indication that formal methods are still only generally accepted in very small pockets of our industry. Maybe over the next couple of years Microsoft will finally be able to make some of these formal methods readily available to all programmers.
Tuesday, January 10, 2012
Back to basics
One of the projects that I work on involves customization and modification of an existing system. The original system was however not architected for change. Beyond the rather long list of architectural and implementation issues that surround the system, one of my colleagues noted that the system was really a world by itself. This brought me back to the thought that larger systems have organic aspects to them.
In the end, simple organisms are favored above complex organisms when disaster strikes. Cockroaches are for example more likely to survive nuclear holocaust than humans. Are simple applications more likely to do well in a changing environment? I have lately been leaning strongly toward limiting custom frameworks and not 'over architecting' applications. The closer you can stay to mainstream constructs that you can expect any programmer to know, the better. As part of the 'less is more' strategy, I have for example ensured that the interaction with Windows Identity Foundation is completely transpartent to the programmer. We have also started to refocus on basic concepts, like encapsulation, contracts and decoupling and making the developer aware of these concepts in an intuitive way through the IDE. I understand why the industry aspires to extreme test driven continuous integrated agile development :), but I also don't want to loose sight of the basics.
In the end, simple organisms are favored above complex organisms when disaster strikes. Cockroaches are for example more likely to survive nuclear holocaust than humans. Are simple applications more likely to do well in a changing environment? I have lately been leaning strongly toward limiting custom frameworks and not 'over architecting' applications. The closer you can stay to mainstream constructs that you can expect any programmer to know, the better. As part of the 'less is more' strategy, I have for example ensured that the interaction with Windows Identity Foundation is completely transpartent to the programmer. We have also started to refocus on basic concepts, like encapsulation, contracts and decoupling and making the developer aware of these concepts in an intuitive way through the IDE. I understand why the industry aspires to extreme test driven continuous integrated agile development :), but I also don't want to loose sight of the basics.
Thursday, October 20, 2011
Code Contracts and more ...
There is so much fun to be had and so little time. A list of some of the areas I have been working on (some professionally, some for my own fun):
- Code Contracts: A Microsoft Research project that brings pre- and post-conditions and invariants to .NET. Although I understand the limitations, I have been very impressed with the capabilities it brings to the table. For example: after adding code contracts to existing code, the suggestion was to add a restriction on the size (at least 20) for an input parameter of type string. Rather odd requirement, which turned out to be the consequence of some substring calls inside the method in question. Obviously it was time to weaken the pre-condition. I can deeply appreciate a tool capable of pointing these issues out.
- PEX: Yet another Microsoft Research project that brings automated whitebox testing with high code coverage to .NET. In combination with code contracts, it rocks. You will never have any excuse for an 'object is null' error again.
- Kinect for Windows 7: Yet another other Microsoft Research project bringing the Kinect to Windows. What else can I say, NUI is finally available for the masses and the way we interact with machines has changed for the better.
- Windows 8 METRO applications: After my visit to the BUILD conference, I have been trying to keep the momentum going and get more familiar with the new Windows 8 METRO applications.
Friday, September 23, 2011
Arduino ...
Been tinkering around with the Arduino boards. It is a blast! They are somewhat of a pain to interface with, but it's been good to learn in detail about bluetooth profiles and wiring :). You can do some wild stuff with these boards, so go and have fun: figure out how to open your garage door from your Android or change tv channels from your laptop.
Thursday, September 15, 2011
My time at 'ask the expert'
Even though you can't really expect answers that actually mean a lot, it is a great way of interacting with some of the presenters/MS developers. So my questions were:
1) With me working for a retail company (blah-blah), can we expect motion (not touch, but for example kinect) to become a first class citizen? Mixed response: one guy said just use a webcam and have the user hold lights in their hands so your software has something to track through the webcam. My answer: really? An other actually found the idea quite fascinating and although it is not there right now, he said that use-case scenario's for kinect outside the xbox are definitely being considered. I liked the answer of the last guy better :). My plea: if you are pushing these slates as gaming devices, support 3D and kinect from win8! And then we can also use standard, affordable, hardware in retail environments :). And please provide standard gestures (culture sensitive? lol, thinking about different finger arrangements meaning different things in different cultures) with the kinect. Just like touch, a set of default movements would be helpful (restart is jumping up and down while having an angry face ? :))
2) SPIN like model checking in VS. To my surprise they are having a talk about this tomorrow! They are using data paths (which is slightly different), but hey, it's at least a form of model checking :). I mentioned the ability to generate test cases out of your model checker, but that didn't seem to resonate.
3) Analysis of large amounts of historical data in the cloud. The answer: unless you can figure out how to use blob data, you will pay a dear price for storage or band-width. That figures :).
4) Suspend mode: while your app is running, save state, so you don't run out of your limited time to save things once you are suspended. The user can choose a certain number of apps to always run, but no guarantee that will be your app! Also: you can schedule tile updates while the app is running or gets notified of suspension. This way you can still provide the user some sort of message after a given amount of time. However: if there is a server task running and your app gets suspended, you will no longer be able to track progress of that server task :)
Windows 8
I am spending this week at the Build conference where Microsoft just released their preview of Windows 8. After the initial message of "everything is okay, you can still use what you know", we had some more in-depth sessions yesterday. And here is, at a high-level, what they have done. They have taken COM and made it a "first class" citizen in .NET. Their new WinRT layer is actually COM. But COM is all about interfaces, and .NET is all about objects. So what they have created is metadata for all the winRT interfaces and mapped those into object oriented equivalents that are exposed in .NET. Thus you no longer need to deal with COM interop when talking to winRT (their framework takes care of it for you).
The other messages is that everything has to be async if it takes more than 50 ms to access.
Here is the rub. Last night I set out to build a new METRO style app to see what it was like. I set my goal low: read some XML in from a file and display it in a grid. Been there, done that, shouldn't be that hard, right? Here are some of the challenges:
The first challenge is getting the right to access a file. I was storing the file in the document library, so I figured there was probably some kind of privilege setting required in the new application manifest to allow access. And there was :). But after changing all that good stuff I still ended up with a blank screen. Huh. They mentioned that if you didn't have the right privileges set, you would get some kind of an error. I am yet to see that, the UI was just blank and no error other than in your debugger. Anyways, after more digging into one of their sample apps, I figured out you also need to specify in the application manifest the specific file extensions that your application will be associated with. If you don't, you will get an 'access denied' error.
Second challenge was actually reading the data. Obviously, since it could be more than 50 milliseconds :), that is an async call. So you go into their new 'Windows' namespaces and find the classes to read a file async. Not that bad. However, here is the rub: all of the winRT functionality is mapped into interfaces. Remember that this is actually COM that is interface oriented? So I like using the classes in the System.Xml.Linq namespace for reading a stream into an xml document. Oooppsss ... you are not getting a stream back from the async file read, you are getting one of the WinRT specific interfaces back. So after some digging I find this new 'Windows' based xml document class that does allow you to process the interface that winRT returns.
Even more fun, winRT doesn't allow you to just inject regular .NET classes, it specificly wants winRT classes in many scenario's.
If this was confusing: sorry, it is also somewhat confusing to me :). Right now it feels like you have to two frameworks awkwardly rolled into one: the .NET framework and the WinRT .NET framework. And they both for example have a way of dealing with Xml documents. So you are choice is to put all these conversions together between winRT and the 'desktop' .NET classes you are familiar with, or you live in a divided house where there is yet another way of working with an XML document. Developers are require to once more split their personality. You already had a WinForms, ASP.NET, WPF and SL personality, now you can start to raise your winRT personality.
The other messages is that everything has to be async if it takes more than 50 ms to access.
Here is the rub. Last night I set out to build a new METRO style app to see what it was like. I set my goal low: read some XML in from a file and display it in a grid. Been there, done that, shouldn't be that hard, right? Here are some of the challenges:
The first challenge is getting the right to access a file. I was storing the file in the document library, so I figured there was probably some kind of privilege setting required in the new application manifest to allow access. And there was :). But after changing all that good stuff I still ended up with a blank screen. Huh. They mentioned that if you didn't have the right privileges set, you would get some kind of an error. I am yet to see that, the UI was just blank and no error other than in your debugger. Anyways, after more digging into one of their sample apps, I figured out you also need to specify in the application manifest the specific file extensions that your application will be associated with. If you don't, you will get an 'access denied' error.
Second challenge was actually reading the data. Obviously, since it could be more than 50 milliseconds :), that is an async call. So you go into their new 'Windows' namespaces and find the classes to read a file async. Not that bad. However, here is the rub: all of the winRT functionality is mapped into interfaces. Remember that this is actually COM that is interface oriented? So I like using the classes in the System.Xml.Linq namespace for reading a stream into an xml document. Oooppsss ... you are not getting a stream back from the async file read, you are getting one of the WinRT specific interfaces back. So after some digging I find this new 'Windows' based xml document class that does allow you to process the interface that winRT returns.
Even more fun, winRT doesn't allow you to just inject regular .NET classes, it specificly wants winRT classes in many scenario's.
If this was confusing: sorry, it is also somewhat confusing to me :). Right now it feels like you have to two frameworks awkwardly rolled into one: the .NET framework and the WinRT .NET framework. And they both for example have a way of dealing with Xml documents. So you are choice is to put all these conversions together between winRT and the 'desktop' .NET classes you are familiar with, or you live in a divided house where there is yet another way of working with an XML document. Developers are require to once more split their personality. You already had a WinForms, ASP.NET, WPF and SL personality, now you can start to raise your winRT personality.
Subscribe to:
Posts (Atom)
