Having gathered initial feedback from the v0.99 release, v0.99b is now available, with the following minor improvements:
v0.99 is now no longer available for download. However, v0.99b is available from, or directly by clicking here.
To perform an upgrade from v0.99, first uninstall the existing version (this will NOT remove your existing database), then run the v0.99b MSI installer and select the database upgrade version.
Attitudes towards risk are something that I've been meaning to write about for some time now. To me, there're basically two types of risk - active and passive (I'm no risk expert in the "risk analyst"/academic sense, so ignore all of this if it's obvious)....
Whilst I've not had time to do all the documentation I was planning to over Christmas, I have got round to bundling up the installer and updating.
So, available for download now (from the aforementioned URL), is v0.99 of XP StoryStudio - the freely distributable XP planning tool created by myself and Dave Fellows, with the help and support of several other kind souls at Egg.
From the documentation enclosed within the installer:
This is a functionally complete, pre-release version of XP StoryStudio intended for limited distribution to test installation and integration issues prior to the public release. As such, should issues be found, please forward them to: support {at} xpstorystudio.com.
This is a functionally complete, pre-release version of XP StoryStudio intended for limited distribution to test installation and integration issues prior to the public release. As such, should issues be found, please forward them to: support {at} xpstorystudio.com.
I've been debating whether to post another entry on this for the last couple of weeks due to another bad smell I've spotted around Agile practices. However, it's my blog, and I think it's worth saying. But first, the bad smell... will be applied correctly and appropriately. People can, and will, get things wrong - especially when lacking experience.
So, TDD Gone Bad #2... Mock oriented development. Mocks are a good thing where you really want to extract a dependency and ensure you're testing the right thing. But there are a couple of issues that can arise:
Whenever mocking is used, the value that the mock gives versus the cost it will introduce over the lifetime of the system should be measured (or at least estimated/considered)
So, #1.1 was all about the "business" - people defining requirements, and how these can cause issues. #1.2 is just a short entry about the underlying statement I was trying to make in the original post:
Anti-pattern:.
It's all too easy to work with a group of savvy technical people that get TDD, and not be able to see how it could go wrong. If you try and scale this across an enterprise where some people just don't get it, and the support isn't there to keep things moving in the right direction, things can, and do go wrong.:
The reason that V isn't always greater than C can arise from several situations from a "story" (business) perspective:
[In part #1.2, I'll discuss the second part of:
Although Test Driven Development (TDD) is one of the greatest steps forwards in software engineering, especially when combined with modern languages and testing frameworks (i.e. xUnit), there's a definite anti-pattern lurking in there - Test Oriented Development.:
That's the good news - a paradigm for developing enterprise websites that theoretically has few drawbacks. Moving on to the implementation is where the bad news begins...:
Web control implementation: <h1>Hello World</h1> <asp:TextBox id=txt runat=server />
Custom control implementation: Literal literal = new Literal(); literal.Text = "<h1>Hello World</h1>"; Page.Controls.Add(literal); TextBox txt = new TextBox(); txt.Id = "txt"; Page.Controls.Add(txt);
Although possible, developing a graphically compelling site using the second method is torturous, so I've discounted it as an option. I also don't want control teams to deliver an editable ASCX control to the site team - it would be prone to editing, etc. and not as much of a "boxed product". There is an alternative, however. Whenever .NET renders a web page that makes use of a user control, it converts the first code example into the second internally. In Visual Studio .NET 2002 and Visual Studio .NET 2003, this process is largely invisible, and only happens when the page is requested. Visual Studio .NET 2005 ("Whidbey") changes this, though, allowing for pre-compilation of websites into Assemblies (DLLs).
So, my long-term plan was to have each team develop a control in a separate VS.NET 2005 project, pre-compile the output when they're ready to release, and then just hand the Assembly over to the "site" team to use just like any other class library. Having spent many, many hours over the last week poking and prodding the aspnet_compiler.exe tool, rewriting it from scratch, attempting reflection on the System.Web.Compilation namespace, and even disassembling most of the System.Web assembly, I'm getting close to giving up. Rather than creating one sensibly named assembly for the whole project, the compiler creates multiple randomly named assemblies - usually one for each control/page (although it sometimes puts several together). After recreating the aspnet_compiler tool from scratch, and extending it to sift through these files, pull out just the assemblies, give them new file names based on the controls they contain, etc. I thought I was getting somewhere. Now the problem is that if one of these controls uses another from the same project, it will be given a reference to the random 8-letter assembly name (and matching internal module name). I've yet to see if any internal assembly hacking can rectify this.
None of this would be necessary if Microsoft hadn't specifically made the majority of the System.Web.Compilation namespace private/internal, presumably in an attempt to make it difficult for other people to develop competing tools, etc. The most infuriating part of this is that, in theory, you can access all of the System.* functionality through reflection, whether its supposedly private or publicly visible. Additionally, tools like Salamander and Reflector make it possible to decompile vast swathes of the system classes back into C#. So Microsoft aren't really "protecting" anything, they're just making it painful to come up with enterprise class solutions.
The point to this post?.