So my newly created WCF ReST service (or webHttp service, as MS more accurately like to call it) runs fine in Visual Studio 2012, using IIS Express. But when I switch to IIS proper (in my case, IIS8 on Windows 8) I get:
HTTP Error 404.17 – Not Found
The requested content appears to be script and will not be served by the static file handler.
Most so-far extant posts on how to fix this, refer to how to fix it for .Net 3 on Windows before Win8: Use
"%WINDIR%\Microsoft.Net\Framework\v3.5\Windows Communication Foundation\ServiceModelReg.exe" to register or to repair registration of WCF components. (The other gotcha being, having the right AppPool settings for .Net version & for 32 vs. 64 bit).
This doesn’t work for Windows 8 / .Net 4.X. Instead you must open the control panel “Turn Windows Features On or Off” and tick the box for Http activation:
Windows Features – Windows 8 – Net45 – WCF – Http Activation
Which should fix the issue after a couple of minutes.
A fine time was had by all …
It’s been decades since software people started to think about how to cope with requirements changing during the course of an engagement, though other areas of endeavour have surely been doing it since the stone age. Literally.
The state of the art for software, and increasingly for other areas of IT, is Agile. Yet the recognition of agile in contractual relationships has lagged behind, which is odd given that a large part of IT is done by contracting someone.
When all is sunshine and daises this doesn’t matter. The time you really really want your written agreements to be right is when things go awry. If you’re doing business even with friends & family, it can help to have something in writing.
But how to write a contract for something when you know it’s going to change?
This problem came up in a linked-in architects’ discussion and I immediately reached for google to find my notes from Susan Atkinson’s presentation on Agile Contracts (I saw her present at a Rational User Group conference a couple of years ago). I reduced it to bullet points in /p1201/susan-atkinson-features-of-an-agile-contract, and she was good enough to drop by to correct & update it. She’s been developing an Evolve Contract Model with Gabrielle Benefield and the website should be up soon. Meanwhile there is a recent presentation on slide-share at Contract Metrics For Agile.
For those not yet convinced that there’s anything wrong with a waterfall-style contract and project, you can read the IEEE 2013 conference paper at http://www.slideshare.net/SusanAtkinson2/ieee-2013-the-flaws-in-the-traditional-contract-for-software-development. nb Open it full-page mode for easy reading.
Apple has at long last published official Windows 8 support – but only for 64 bit Windows and only if you are running OS X 10.8.3. A tad irritating if, as on my machine, Windows 8 installed itself as 32 bit and not 64 bit.
The small print is at Boot Camp 5: Frequently asked questions
Reading I Fear Our Mobile Group Being Forced To Follow Scrum crystallised in my mind what can go wrong when you treat Agile as a methodology. It describes a team successfully using kanban which is to potentially be required to use scrum — because that’s becoming the company standard.
Making a team follow an agile methodology is exactly *not* Agile.
Agile is “Individuals and interactions” being valued more highly than processes. Imposing Scrum looks like valuing the process more than the team.
Agile is “self-organising teams” and letting “the team [reflect] on how to become more effective, then tune and adjust accordingly.” Imposing conformity on a team that has already adjusted is a backwards step; you’re asking a team that has optimised somewhat for the individuals in the team to de-optimise again.
This doesn’t mean that you can’t teach an agile team anything. The manifest starts with “We are uncovering better ways of developing software by doing it and helping others do it.” A team that can’t be corrected, or won’t learn better ways, isn’t agile. For that matter, a team that won’t learn in any walk of life has started the downhill path to decline.
For what it’s worth, I’m sure that a competent lean team that tries Scrum for a while will learn from it, even if they end up optimising back to something more fluid.