blogs.conchango.com

Linq to SQL: testing, the long way around

Anthony.Steele — Thu, 24 Jul 2008 11:54:00 GMT

Linq to SQL is great. You can open up your Db schema, drag some tables in, and in no time you have a data context class with loads of functionality, and data classes for all of the entities. No more recordsets to unpack into objects, no more fields to pack into SQL params, just lists of strongly typed ojects. Even better, the classes are partial so that you can extend them.

It seems natural to extend the data context by adding methods like
var orders= MyDataContext.GetOrdersForCustomer(myCustomer.Id);

Methods like these are trivial to implement with Linq:

from o in orders where o.CustomerId = customerId select o;

And Linq makes persistence simple too.

Now the problem comes in when you think about layering and mocking. You'd like to have a interface e.g. "IDataStore", with an implementation of it that is backed by the database, and another mock implementation for testing. You'd like to have the data classes to be defined where they depend on neither of these implementations, but both implementations can reference them.

But Linq to SQL's code isn't laid out like this if you drag and drop. The DataContext doesn't implement any interfaces. The data classes are defined in the same namespace as the DataContext. You can test the data classes by just creating and populating them, but you can't test anything that depends on data retrieval without using the datacontext and behind it, the database.

It's taken me a while to get there, but this seems to be the problem that Ian Cooper is solving in Architecting LINQ To SQL Applications, part 5

Hence the"long way around" to seeing why Ian was on about that. Linq to SQL can be used in other ways besides drag and drop, and some of these ways will give you what you want.

On Standards...

marcus.alexander — Thu, 24 Jul 2008 11:34:00 GMT

So I was having a conversation the other day about whether or not IE8 will pass the "Acid 3 test" and meet the HTML/CSS/scripting standards properly. It’s all well and good meeting the standards, except...

There are a whole bunch of new standards coming out, XHTML 2, HTML 5, CSS-whatever, etc, etc. These are/will be as clearly defined (i.e. Not) as the current standards, so it’s always a game of catch-up whichever way you look at it. Many people like to believe the standards are created, and perfect, and anyone who misses the target is plain wrong. Except it's not really like that. The way it really works is something like this:

Browser X implements feature A and it becomes popular.
Browsers Y and Z rush to implement feature A too, so they don’t lose out;

Meanwhile W3C look at take-up of feature A and try to incorporate it into up-and-coming standards set P.
Browsers X, Y and Z realise that their next-generation models will have to incorporate (still not finalised) standards set P, so attemp to implement an incomplete and non-finalised set of standards, while at the same time... Inventing features B and C to keep ahead of the market.

Meanwhile all the geeks in the world bewail the fact that browser Y doesn’t support feature A even though it is in standards P, forgetting the entire history of it and also forgetting that the W3C is nothing more than a loose consortium of geeks from competing browser vendors and other bodies, who agree with things about as often as the UN members do (ie never) and are themselves creating standards which compete with their own standards (eg XHTML vs HTML, etc, etc).

It’s a mess. Yep. For sure. But that’s how we end up with cool things like, well, pretty much everything we have now.

Jack and Jill went up the hill to get an en-suite bathroom

peter.hanlon — Thu, 24 Jul 2008 08:46:39 GMT

If you've read one of my previous posts about Fuzzy Logic, then you'll know that I was thinking about moving house earlier this year. Without boring you too much about my personal life, we're not going down that route anymore, instead we've been talking to architects and looking at doing a home extension. We live in a Victorian house full of original features (I sound like an estate agent !) and as a result we have a downstairs bathroom. One of our requirements is to achieve an upstairs bathroom. According to the beenster, an en-suite bathroom is one of the top 5 requirements requested by home buyers. Our architect, in trying to maximise re-sale value, is suggesting that we create a bathroom with two doors, one opening onto the landing and one opening into the master bedroom. This is called a Jack and Jill arrangement. Technically this means we'll have an en-suite, a tick in the box when selling a house.

Now I know the architect is trying to do us a favour, but I can't help but feel that whilst this technically meets the description of an en-suite, it doesn't meet the 'spirit' of an en-suite. (ie it's not an en-suite)

I can draw parallels with my job in IT. We often have critical success factors on projects that are hard to articulate. In my experience sometimes these can go unspoken, but everyone understands what they are. 'Look like this', 'behave like this', 'be better than that', 'delight me'. These are just a couple of examples in my head at the time of writing this. We often try to capture these and call them non functional requirements. Sometimes we capture them well, other times less so and sometimes we don't capture them at all (I like to call this flexibility). Even when we capture them, we can fail to deliver on them, and when we don't, we can try and justify ourselves by claiming we've met the 'letter' of the requirement, when we know we haven't delivered in the 'spirit' of the requirement.

'If people don't use the system it's there own issue, it does everything they asked for....'

I've had a recent experience of this in a project where time was the most critical factor, ahead of cost and quality/scope. We had the ability to flex the scope in order to meet the date, but this soon got to the point where we knew we'd compromised the 'spirit' of the requirements, but we were trying to kid ourselves that we'd met the 'letter' of the requirements, so it was alright.

When I was a younger, less experienced project manager / business analyst, I would have carried on regardless, feeling like being unable to deliver the 'spirit' of the requirements was a personal failure and something to be covered up and ignored. Having been burnt several times by this approach ( I got away with it a couple of times too), I now know that raising these issues early always leads to a better outcome in the long run. It can of course mean some short term pain from management and stakeholders as they realise they're expectations aren't going to be met fully, but the benefit of raising this early is two fold

Stakeholders get a chance to be involved in a resolution plan, so you get good stakeholder involvement and buy-in to the resolution. (When issues are raised late, your usually very limited on the resolution.)
Stakeholders expectations get managed gradually, so each incremental change is less painful than a big realisation at the end of a project

So with the issue over requirements raised, I'm probably in for a period of short term pain. I've learnt it's better this way though than to carry on regardless...

Windows Home Server Power Pack 1 and WHS+USB 1.0 == Misery!

James.Saull — Wed, 23 Jul 2008 20:39:11 GMT

I pushed too much data on to the Windows Home Server (WHS) and I started to get health warnings indicating which files it could no longer duplicate. My data was stored OK, just at risk. Given that the WHS experience was going well I ordered up a Lacie 500GB external USB 2 drive. To tide me over, I plugged in a little 100GB host powered USB drive and added it to the pool. Slowly the data balanced out across the three drives with enough space for all content to be duplicated. I then continued to copy more data on to the server. Transfer rates were abysmal! 500k/s. Oh dear. All my content finally copied over and eventually my critical health warning went away as it finally migrated enough data off the smallest system drive.

The Lacie 500GB drive arrives and I plug it in. A couple of clicks later it is added to the storage pool. It starts to balance the content whilst I right click the little 100GB host powered drive and remove it from the storage pool. WHS can see that there is enough storage and drives to successfully duplicate content across the remaining drives and so it starts to migrate content off... how slow?! it can only have about 30GB on it. Max! Anyway, time for bed.

By the next morning all the content has migrated off the drive. I go to the WHS to remove the drive... Ah... I'd forgotten that this old machine still had USB 1.0 ports. In the darkness under the desk it would appear that I had rediscovered them when I had plugged in the 100GB drive! Copying files and balancing storage with the 500GB drive plugged into USB 2.0 is now going up to 8MB/s (given I have a 10/100 switch in the way it won't get much higher than that). When MS say they don't recommend USB 1.0 they weren't kidding. Copying large AVCHD files onto the WHS is nice and fast and I can happily watch the HiDef videos directly off the WHS.

Applied WHS Power Pack 1 last night. All straight forward. Go get it here: http://download.microsoft.com/download/8/b/d/8bd7fe82-34cc-4026-b8e5-e9e10902312c/WHS-KB944289-v1-x86-ENU.exe

and read about it here: http://blogs.technet.com/homeserver/archive/2008/07/21/power-pack-1-come-and-get-it.aspx

Change – There’s a lot of it about!

Steve.Bailey — Wed, 23 Jul 2008 14:45:00 GMT

Being new to Conchango (& new to consulting for that matter), I am a little out of my comfort zone right now. I’ve never written a blog before either & was struggling with what I could contribute.

I thought maybe I should follow the writer’s maxim that it’s easiest to write about something that you have direct & current experience of.

Right now, my most pressing concern is how I am going to manage all of this change positively. So... change it is!

I know that I can play a part in the continuing success of Conchango & that the feelings of anxiety I have right now will pass. I am also sure that I will soon be looking back & wondering what I was worried about.

I know this, like you do, because it has all happened before. I have changed jobs before, (though not for a long time) & I have also had change happen in many other areas of my life. We all come to recognise the pattern of feelings that change causes in us, but that does not necessarily make living through them any easier. For some people, the feeling of discomfort that change brings is enough to stop them ever considering change, let alone accepting it. That may not be you, (I’m sure Conchango is full to the brim of change junkies), but it could easily be the clients you are working for.

One thing that helped me to understand & deal with change more productively, was that someone once explained the change cycle to me. It is fair to say that this was one of the more memorable sessions in all the various training courses that I have attended. To this day I remember the metaphorical “light bulb moment” when I realised that not only was I normal (well at least in my responses to change) but also that, despite their outwardly calm & in control appearance, most other people have similar feelings at times. I guess we are all human, even if some people try very hard to hide this fact. At the very least, I learnt that I am not alone; which is comforting in itself.

As change is at the heart of what we do at Conchango, I thought that others may benefit from understanding the change cycle. Not only will it help you to deal with your own personal change management, but it may shed some light on why clients behave the way they do. If you are evangelical about change, it might be hard to understand why some people seem less than enthusiastic. You need to separate any genuine concerns about the effectiveness of the change from the emotional reaction that is being expressed.

I expect that many of you are experts in managing change & will put this in the egg-sucking category. If, however, you have an opinion to share, or a contribution to make, feel free.

The disclaimer

Firstly, I am not a qualified psychologist & I do not claim to be an expert. I have compiled the following from various sources, (there are plenty of online resources that will allow you to explore this subject further) & have found it useful to provide insight, but I will leave you to gain what you can from it. It is just my view, which I hope will help.

Also, what follows is my own view and doesn’t necessarily represent Conchango’s positions, strategies or opinions

What’s it all about then?

None of what follows says that change itself is necessarily good, or even productive. In fact, I am certain that this is not the case. Although you may be in a position to shape or veto a particular change, or influence those that can, in most cases the driver of change will be outside of your control. Clearly, you should voice your concerns if you have them, however I am assuming that the decision to implement has been taken & that you need to find a way to get the most personal benefit that you can from it.

Change is inevitable in some form or another. Without it, nothing much would happen. You can’t really fight this basic fact - well, not for long anyway, so you may as well learn to live with it.

Many of the changes that we deal with are hardly noticed. You have to look back a long way to realise how all of the small steps have accumulated to get you where you are now. Even some large changes may have no appreciable impact on us. So what is it that makes some changes hard to deal with?

I think that the impact any change has on you, is proportionate to the emotional investment you have in the status quo. The key issue with this is that not everyone has the same level of emotional investment in something. Understanding the level of emotional involvement of all the parties concerned is the first step to understanding how change can be managed.

I think that the level of emotional investment we have in something generally increases over time. We become comfortable with what we are most familiar with & start to feel defensive about any criticism of it. I think this sometimes stems from a feeling that we are being judged for having accepted the status quo & that is what we are reacting to, rather than the idea behind the change.

Maybe that’s just me, but I have seen similar reactions in others often enough to believe that I am not alone. If you want to drive change, an appreciation of this may help you to put the change to those affected in a way that makes it more likely to be accepted.

We also tend to be more emotionally invested in something which we have created ourselves, even if we know it is not perfect. Demonstrating an understanding of why things are the way they are currently, (perhaps because things were originally pulled together in a hurry & on a limited budget), whilst showing that there are good reasons why change is now needed, is likely to be more productive than the more challenging way, (e.g. the “what we have now is rubbish!” approach) often seen when communicating the need for change.

Being emotionally invested in the status quo may also be driven by the perceived personal impact of the change, or more likely, the uncertainty of what the change will mean to you. In this case, it is not holding on to the current situation that drives the anxiety, but the avoidance of what is coming. This may even lead to people suddenly becoming keen to hold onto something that they themselves have criticised in the past.

If you are the driver of change, the emotional impact that the change has on you will generally be less, however this is not necessarily so. Although you may have identified that change is desirable & be fully committed to the process, the jump into the unknown can still be very stressful & lead to many of the same issues as externally driven change.

Avoidance of change, due to the uncertainty of what it will bring, is perfectly natural. It is normal to have a degree of risk aversion. I don’t think that we would be a very successful species if the natural curiosity which has driven us to explore & develop the planet were not tempered with a healthy (but not total) aversion to taking risks. Risk in itself is neither good nor bad, but needs to be balanced with the reward it might generate & the likelihood that this reward will be realised.

Clearly, the amount of risk you are prepared to take is generally proportionate to what you stand to lose. Therefore, if you stand to lose something you perceive as particularly valuable (your income, house or family life for example), then you are likely to be more resistant, unless the "buzz" that this generates is what is driving you to seek risk in the first place. Again, if you understand what others stand to lose & how important that is to them, then you can address their resistance better.

In summary, if you are not too emotionally invested in how things were, you are clear about how you will be affected & you believe that it is for the better, you are unlikely to be bothered by the change. Otherwise, you will, to some degree or other, go through the stages of the change cycle. The attitude with which you enter the cycle is generally dictated by your perception of the risk involved. Just remember that this is true of all those potentially affected by any change that you are proposing as well.

The Kübler-Ross model

The original model, upon which most of the existing change models are based, was put forward by Elisabeth Kübler-Ross, in her 1969 book "On Death and Dying”, extracts of which have been published online by those nice people at Google: (http://books.google.co.uk/books?id=9yfJQBo_9GQC&dq=kubler+ross+death+dying&pg=PP1&ots=r6tiJni1U_&sig=hIta6kxsHMuQB2-HF7U4OPtzahY&hl=en&sa=X&oi=book_result&resnum=1&ct=result#PPP1,M1)

The book deals with the way that people handle grief & tragedy. Clearly this is an area where people have a large emotional investment & therefore it is to be expected that people in these situations will feel the impact quite strongly. If you are facing terminal illness, your perception of risk is also going to be pretty high!

Kübler-Ross identified 5 key stages of grief in some detail. In summary, these are (expressed from the perspective of someone who knows that they are dying):

1. Denial:

Example - "I feel fine."; "This can't be happening."

2. Anger:

Example - "Why me? It's not fair!" "NO! NO! How can you accept this!"

3. Bargaining:

Example - "Just let me live to see my children graduate."; "I'll do anything, can't you stretch it out? A few more years."

4. Depression:

Example - "I'm so sad, why bother with anything?"; "I'm going to die . . . What's the point?"

5. Acceptance:

Example - "It's going to be OK."; "I can't fight it, I may as well prepare for it."

Kübler-Ross also noted that these stages may apply to other areas of catastrophic loss & cited the loss of a job, relationship or freedom in particular as eliciting similar responses.

I think that there are business situations where people could feel strongly enough to grieve for what they have lost (routine, friends, established desk etc), but this is the most extreme situation.

One important element in this model is that not everyone will experience all of the stages as strongly as others, if at all; however everyone will experience at least 2.

The order that these stages occur in is not always that listed above either. Whilst this is the most common order, some people may, for example, be become depressed before they become angry. On the whole though, it is the most typical order in which people go through the process.

There is additional info on this model here: http://changingminds.org/disciplines/change_management/kubler_ross/kubler_ross.htm

The Changing Minds.org site is a mine of “interesting” stuff

Other Models

In order to cover less traumatic situations, a number of other models have been developed, based on this general premise.

The following models have been developed & the links are attached to avoid any copyright issues that might exist if I copied them to this Blog:

The positive change cycle

http://www.changingminds.org/disciplines/change_management/psychology_change/positive_change.htm

Also from Changing Minds.org

The Change Cycle.com

http://www.changecycle.com/changecycle.htm

This is a Commercial organisation, with a particularly useful visual representation

A Final thought

The common factor in these models is that a stage is reached where you have to make a conscious decision whether to accept the change, or not. Which way to jump is a matter of personal choice, but once that choice is made, the consequences must also be accepted, even if they are negative.

Silverlight Tweening Adventures with Baby Smash!

Richard.Griffin — Wed, 23 Jul 2008 14:32:00 GMT

Before starting out on my tweening adventures I have to admit too being complete tweening newbie. On previous WPF and Silverlight projects animations were rolled from scratch to provide the desired responses to changes in the applications state. With regards to Designer and Developer workflow this stage of the process is usually where the 2 worlds collide. The developer adding animations in code behind hand cranking; Storyboards and animations; and dealing with event handlers. The designer is using Blend to create Timeline animations declared in Xaml. The other point to note is that Developers can't do animations, we may be able to code the equations and provide the necessary hooks for when event that happen when an animation finishes, but essentially the designer will have the last say in the matter with regards to the aesthetics of the animation created. My own experience is that we start with good intentions by putting all the animations in Xaml but this can become a little tricky when you have to deal with different states and trigger different animations. So this is when I fall back to putting all my animations together in a Resource Dictionary; and handling the state changes in code which fire the animations that the designer has created. The other problem that i have come across is when you have dynamic data data bound to an Items Control and you need to animate the different items based on their position in the Control, this simply can't all be done in Xaml and is a combination of Storyboards declared in Xaml and code behind to trigger the animations. In general animations can cause problems and I was also frustrated that these animations having to be hand rolled from scratch, this was evident when Felix asked if I would write some Silverlight animation code for him recently and while I was doing this all the memories of working with WPF and animations came flooding to mind at which point I thought that there must be a better way. I vaguely remembered reading an article on Silverlight Cream from Koen over at first floor solutions and further back a post from Adam Kinney. If like me you are new to Tweening this is a great place to start and is where my journey really begins. After reading the blog posts and looking over the other Tweening libraries from Cristian all of which are based on Robert Penner equations I was feeling confident that I could use this code and start to tackle my first problem. Animating Baby Smash! shapes.

After helping Scott with some other parts of Baby Smash! we started talking about how to animate the different shapes that Felix had created. We discussed the above and based on the outcome I decided to use tweening rather than hand cranking the animations from scratch, but I wanted to do something that would not only work in Silverlight but also in WPF, this is where Koens' Library solved my problem. I download his simple Silverlight application which shows off some of the basic features available in the Tweening Library and put in some additional tweaks to the UI allowing for more control over the different Transfroms which we can use in Xaml. We have a bunch of different transforms available in Silverlight, which include; RenderTransform; ScaleTransform; RotateTransform; and SkewTransform. Not only did I want to be able to play with tweens for each Transform type I also wanted to allow users to change the values for their selected transform, for example the Scale Transform supports Scaling on the X and Y axis so there are sliders which can be used to change the values from and to which the tween will use to animate the Scale tween selected.

Scott is building Baby Smash! mainly using code behind, and I can understand the attraction of heading for the code behind as this is what we feel comfortable cranking. From personal experience when building WPF applications burying goo in the code behind is not always that best thing especially when you are building interactions for the user. These interactions will have an impact on the designer and if they are not in the Xaml then they can't help that easily, but also they are more willing to change Xaml than code behind. Keon solution fits well, it allows me to add the animations in Xaml and event handlers in the code behind, allowing the designer to tweak the animations to produce the desired effect.

So now we have away to play around with the different tweens and how they effect the various Transforms, we can also hit the Xaml button and get the Xaml required to recreate the Storyboard. The next job is to get everything working in WPF. I created a new WPF assembly and stuck Keons' library in. Next up add a reference from Baby Smash! project to the tweener project. Find the User Control shape that I want to change and add this code into the Resources collection of the Grid we also need to add the RenderTransformOrigin and set the value. Finally I needed to add the Render, Rotate, Scale and Skew transform to the Transform group collection of the grid. Hit F5 and i get to see my shape and the tween animation that I created in the Silverlight app.

There are a couple of problems with my approach; first is that we are duplicating the tweening code in all the User Controls; and second problem is randomness, if I want to keep the equation applied to the shape but randomly change the from and to values this is currently not possible. I style may help here as Styles support animations, however I am referencing UI Elements that are in the Grid and this could cause some issues with regards to Scoping. My other choice is to add the animations into another Xaml file and use a Resource Dictionary. Keons' Library is best used inside a Control Template, however the Baby Smash! shapes are User Controls which contain a layout grid that hosts other UI Elements unfortunately these controls do not inherit from Control and thus I am unable to use the Control Template. As I could not make a decision I thought that I would attempt both the Style route and the Resource dictionary. I created an empty style for the layout root grid and moved the tweening Xaml into here, and that is about as far as it went, I got an exception at runtime complaining that it could not find the target. This is the scoping issue that mentioned earlier as the UI Element that we want to target is out of scope. So next up is the Resource Dictionary. I created the Resource Dictionary in Blend and moved the tweening Storyboard into the Resource Dictionary, final part in Xaml is to just add in a reference from within the User Controls Resources collection to the new Resource Dictionary. Using this mechanism means that I have to trigger the tween for each shape from code behind, but its only a couple of lines. In Baby Smash! the figure generator is where most of the action takes place so in there I added some code to kick off the animation for shape. I have now replaced the duplicate code with a single Storyboard that we have in the Resource Dictionary, cool, but what about Random changing of the tweening easing functions and input values ? To implement this part I iterate over all the Children which in this case are DoubleAnimationUsingKeyFrames and call on of the Utility methods in Baby Smash! to get two random numbers generated. To change the other values we can simply add the other static method calls to change the inputs on the tween. So I guess the next question really is "What would it have taken to do it all in code behind ?? " You can see that if we go with all the animation tweening in code behind then it looks like this, yeah that's all it takes to get the animation working. By creating the Storyboards in code behind we loose the Verbose qualities of Xaml but we also loose the designer. My current thoughts are that if you have a number of UI Elements that you want to animate and these animations are pre baked by the Designer, go for the Xaml route. However, if you are looking for a solution to either dynamic items in an Items Control or you are looking to do something which is similar to Baby Smash! go with the code behind.

While I was building this code Dev Dave and Scorbs put together the FlickrViewr using the Animating Wrap Panel and Robbie updated his site and also posted a great post on animating panels. So the next job is to take Dev Daves' AWP and change his interpolations with Penners' Equations. I have got pretty far with this but I have a performance tweak that I would like to make before posting the source. What I am hoping to build is a versatile AWP where you can easily say in Xaml what tweening easing equation you want to use along with the inputs. You can download all the source from my SkyDrive or you can load up the URL and have a play with the app here.

The Design of Womenomics

Paul.Dawson — Wed, 23 Jul 2008 09:25:54 GMT

Dan Sumner at Microsoft seemed quite intrigued by a presentation I made the other day on a couple of trends that came through our friends at the Future Laboratory.

The Slash/Slash Generation was one. More on this another day, but the one that captured his imagination was "The Design of Womenomics".

What The Future Laboratory were saying is that what was a trend on the rise (womenomics) has finally settled into the mainstream of design.

The power of women in the economy is essentially what 'womenomics' is, and it's a trend that has obviously been growing since suffragette-ism and feminism, and demonstrates that although equality and parity between men and women still has a long way to go, it is now a major influence on commerce.

Womenomics is about the fact that women are involved in about 80% of purchasing decisions in the retail universe. They're also looking for different things; but make no mistake, this is not about pink and fluffy. It's instead about simplicity, clean lines, efficiency and what the psychologists call 'whole brain thinking'.

"The Design of Womenomics" is about how the trend of womenomics is now concretely influencing product design, retail design and other commercial areas.

What is interesting about "The Design of Womenomics" is that it's a trend that is completing the loop. We use trends analysis a lot to help us plan and set strategies for customers like Virgin Atlantic and Tesco - and often the feedback on seeing a trend on the rise is initially "very nice, but how do I use that to my advantage". So what we do with those, is stretch them forward and map them on to our clients' businesses. This is a lot more practical approach and helps those companies see the potential impact of a trend, and how they go about planning to take advantage of it.

What you see in "The Design of Womenomics" is how companies like Electrolux, Halfords and HiQ have shifted their attitude to design in order to better cater to an ecommerce and retail marketplace that is increasingly dominated by the power of a trend that was only previously "on the rise" as they say in "trend-y" circles.

In other words, it was good planning. Something we at Conchango do under the "Experience Planning" umbrella, with a philosophy of "Total Experience Design", which is about consideration of all channels and touchpoints regardless of whether or not Conchango has the ability to execute in them, and with a focus on the emotional state of the customer before, during and after their interaction with the brand we are working with.

I posted a few of the things I used to illustrate "The Design of Womenomics" this on a Flickr set here.

Thanks again to our partners at The Future Laboratory for being out there to pick this stuff up for us so we can translate it into actionable strategies for our clients.

Why BDD works for Agile

james.broome — Tue, 22 Jul 2008 22:34:00 GMT

As I mentioned in my first post (and will probably continue to do so for the unforeseeable future), I recently attended JP Boodhoo's Nothin' But Dot Net training 'boot camp' which has motivated me to start to write about some of the stuff that I learnt and am still trying to make sense of...

The main focus of the course was using Behaviour Driven Design to drive out an application, tests first, from the top down. I was very familiar with the concept of automated unit testing, having used NUnit in the past and using the MSTest tools on my current project. However, I don't think I could truly say that I'd been working 'test first' or that the design of our application was driven out by the test cases. Also, if I were to give a summary report of our automated tests to one of our Business Analysts, I guarantee that it would be met with a blank expression. This makes it tricky to prove that the tests are correct - do they match the requirement and, if this changes, what tests need to change to reflect this?

The whole idea behind BDD is to write tests in plain English, describing the behaviours of the thing that you are testing. When the things that you are testing are written in the common language of the domain, the tests are then describing the behaviour of that domain. The main advantage of this is that the tests reflect the user stories, the business requirements of the application. Careful choice of naming conventions and syntax mean that a unit test report can read like a functional specification. Therefore, it can be read by a non-technical person e.g. the project sponsor, a domain expert, a business analyst and the tests can be validated against the requirements. If a new developer joins the team, they may not know the domain of the application however looking at the tests will immediately give them a very clear idea of the intent of the code.

Let's take the following hypothetical user story for a staff telephone directory application:

"As a user I should be able to view an alphabetical list of the employees so that I can quickly find the person I wish to contact."

We may start with writing a test class something like this...

using System;

using System.Collections.Generic;

using Observation = MbUnit.Framework.TestAttribute;
using Context = MbUnit.Framework.TestFixtureAttribute;

[Concerning(typeof(DirectoryTasks))]
public class when_the_directory_tasks_is_told_to_get_all_the_employees_beginning_with_the_letter_A : SpecificationContext
{
    private IEnumerable<Employee> results;
    private IDirectoryTasks sut; //sut = System Under Test    

    protected override void establish_context()
    {
        //Test set up here e.g. mock objects etc...        
        this.sut = new DirectoryTasks();
    }

    protected override void because()
    {
        this.results = this.sut.GetEmployeesBeginningWith("A");
    }

    [Observation]
    public void should_ask_the_telephone_directory_for_all_the_employees_that_begin_with_A()
    {
        //Interaction based test checking that we are talking to the TelephoneDirectory domain object    
    }

    [Observation]
    public void should_return_the_list_of_employees_in_alphabetical_order()
    {
        //State based test  
    }
}

Note the name of the test class describes the context of the tests. The test methods (observations) are describing the expected behaviour of the thing that we are testing. Note too the Arrange, Act, Assert style of the test. We establish the context for the test, perform the action that we want to test and then assert the correct behaviours of the system under test.

Writing the specification first drives out the need for the following supporting domain classes:

public class DirectoryTasks : IDirectoryTasks
{
    public IEnumerable<Employee> GetEmployeesBeginningWith(string first_letter)
    {
        throw new NotImplementedException();
    }
}

public interface IDirectoryTasks
{
    IEnumerable<Employee> GetEmployeesBeginningWith(string first_letter);
}

public class Employee {}

And the test class uses the following utility classes:

/// <summary>
/// Base class for all test contexts - enforces the Arrange, Act, Assert style testing
/// </summary>
[Context]
public abstract class SpecificationContext
{
    [SetUp]
    public void Setup()
    {
        this.establish_context();
        this.because();
    }

    protected abstract void because();
    protected abstract void establish_context();
}

/// <summary>
/// Attribute used in grouping observations
/// when generating test report
/// </summary>
[AttributeUsage(AttributeTargets.Class)]
public class ConcerningAttribute : Attribute
{
    private readonly Type concern;

    public ConcerningAttribute(Type concern)
    {
        this.concern = concern;
    }

    public Type Concern
    {
        get { return this.concern; }
    }
}

Each test class relates to a specific context for a set of tests, which translate as the specification for the system under test. So, you may have more than one test class for each thing that you are testing if there are different test contexts e.g.

when_the_directory_tasks_is_told_to_get_all_the_employees_in_a_department

when_the_directory_tasks_is_told_to_get_all_the_employees_with_a_specific_last_name

And each test context may have multiple tests, or observations, each with different assertions. The assertions themselves can also follow the same BDD coding styles so instead of the typical

Assert.IsTrue();

Assert.AreEqual();

We can use

results.should_only_contain();

result.is_equal_to();

dependency.was_told_to();

Of course, the fluent syntax of the code in the above examples is made possible by the goodness of C# extension methods and some creative thinking about the design and naming of classes. But taking the mantra Red, Green, Refactor, the only thing preventing you from writing truly expressive code is your own creativity. Write the code how you want to use it from the tests, get the code compiling, get the test passing, then refactor the code.

Writing the tests first drives out the code from the top down, whilst writing them in a BDD style syntax gives a meaning to why the tests are there and why that piece of 'real' code should then be written. As I'm already working in an agile environment, collaborating with business analysts and working from user stories, developing features in this way just seems to totally fit. Its only a small step to produce a report of all the tests, parsing the class and method names to give you something like this:

Directory Tasks

When the directory tasks is told to get all the employees beginning with the letter A

should ask the telephone directory for all the employees that begin with A

should return the list of employees in alphabetical order

should return the list of employees in groups of 10

When the directory tasks is told to get all the employees in a department

should etc...

Look familiar? The tests start to become a direct specification for the system that can be read, understood and validated by any member of the team. They are written in the language of the domain and describe the behaviour of the domain. If the specification changes, or new requirements are added (or missing) it is easy to see which tests and therefore what code needs to change. The code itself becomes the living breathing documentation of the application and this really supports an agile iterative cycle of development, adding new features one at a time.

Please note: The example above will compile, but the tests won't yet pass due to the GetEmployeesBeginningWith() method throwing a NotImplementedException. In future posts I will build on this example to flesh out the tests and the associated code.

The test framework used here is MBUnit, so a reference is needed to MBUnit.Framework. Alternatively, the test framework can be replaced by changing the aliases in the using statements at the top of the file.

For more info, see http://behaviour-driven.org/

BTS 06 R2 and .Net 3.0

Prasanna.Krishnan — Tue, 22 Jul 2008 15:03:00 GMT

BizTalk 2006 R2

This article is intended to provide an overview of BTS 06 R2 new set of adapter and integration with WCF and WF. (Some of the contents are referred from the Microsoft web site)

Firstly BTS 06 R2 is released more or less at the same time of VS 2008 has no supporting templates for BTS. So if you planning to migrate to new visual studio environment you may have to wait for another major release (I guess that’s BTS 06 R3).

Since BTS 06 R2 is built on top of .Net 2.0 framework you cannot take advantage of the all the new features of .Net 3.0 and above. The major integration point is of with WCF.

.Net 3.5

None of the feature other than REST based communications for BTS 06 R2. Linq2XML will be better suited for BTS but unfortunately it is not supported with the current release

WF Adapter

This is purely my assumption; there is no straight forward way to integrate WF. I thought R2 might have new orchestration shape to invoke WF J

The only way I heard or seen others doing it is by exposing WF as service and consume the same in BTS like any other service and vice-versa

There is an undocumented BizTalk Server 2006 R2 Extensions For Windows Workflow Foundation SDK V1 is available, and honestly don’t know how many of them have used or using it - http://www.microsoft.com/Downloads/details.aspx?FamilyID=b701c00f-cdc1-4edb-a975-b9412263ec6e&displaylang=en

WCF Adapters

Overview

The BizTalk WCF (Windows Communication Foundation) Adapters align BizTalk with Microsoft’s Web Services strategy by exposing WCF channels to BizTalk processes.

Features

The BizTalk R2 contains the following WCF Adapters

WsHttp Adapter – provides the WS-* standards support over HTTP transport. WCF-WsHttp adapter provides a transport/protocol stack implementation compatible with other next generation Web Services (platforms that also implement the same Web Services Architecture standards). It provides full access to SOAP security, reliability, and transaction features. This adapter uses the HTTP or HTTPS transport, and messages have a text or Message Transmission Optimization Mechanism (MTOM) encoding

NetTcp Adapter – provides the WS-* standards support over TCP transport. WCF-NetTcp adapter provides efficient communication in a .NET to-.NET environment. It provides full access to SOAP security, reliability and transactions features. This adapter uses the TCP transport and messages have binary encoding.

WCF-NetMsmq Adapter – provides queued messaging using MSMQ transport. WCF-NetMsmq adapter provides queued communication in a .NET-to-.NET environment. It uses MSMQ transport, and messages have a binary encoding

WCF-BasicHttp – compatible with first generation web services. WCF-BasicHttp adapter provides a transport/protocol stack implementation compatible with first-generation Web Services. This adapter uses the HTTP or HTTPS transport, and messages have a text encoding.

WCF-NetNamedPipe – provides cross process messaging using NamedPipes transport. WCF-NetNamedPipe adapter provides efficient cross-process communication in a .NET-to-.NET environment. This adapter provides full access to SOAP reliability and transaction features. The adapter uses the named pipe transport and messages have a binary encoding. This adapter cannot be used in cross-machine communication.

WCF-Custom – provides customization for using WCF components (bindings, behaviors and binding elements). WCF-Custom adapter is used to enable usage of WCF extensibility components in BizTalk Server. The adapter enables complete flexibility of the WCF framework. It allows users to select and configure a WCF binding for the receive location/send port. It allows users to set the endpoint behaviors and security settings.

WCF-CustomIsolated – provides customizations for using WCF components (bindings, behaviors and binding elements) and using the HTTP transport. WCF-CustomIsolated adapter is used to enable usage of WCF extensibility components in BizTalk Server, but out of proc in IIS. The adapter enables complete flexibility of the WCF framework. It allows users to select and configure a WCF binding for the receive location/send port. It allows users to set the endpoint behaviors and security settings. This adapter should only be used by transports than can be hosted in IIS.

Supported Use Cases

The BizTalk R2 WCF Adapters supports the following Use Cases:

· Exposing BizTalk orchestration as a WCF web service

· Exposing BizTalk Content Based Routing application as a WCF web service

· Consuming a WCF service from BizTalk orchestration

· Consuming a WCF service from Content Based Routing application

· Transactional message receive

· Transactional message send

· Using WS-* headers for routing and message processing

· Using custom headers for routing and message processing

· Using custom binding elements

· Using custom bindings

· Using BizTalk dynamic send ports

· Using BizTalk as SOAP intermediary

· Consuming a WCF Service originating from WCF-LOB Adapter (SAP, Siebel, Oracle DB, and Tibco RV)

Consuming a WCF Service originating from the WCF-Adapter Framework (Custom Adapters)

Supported Transports

· HTTP / HTTPS

· SOAP

· MTOM

· TCP

· MSMQ

· Named Pipe

WinFX Adapter Framework

Overview

The framework provides a common basis for building integration adapters that can be consumed by a variety of client applications (BizTalk, Office, .Net, etc) and usage scenarios via WinFX (Microsoft’s next generation messaging framework). The .Net 3.0 Adapter Framework aligns the adapters strategy with Microsoft’s Web Services strategy by exposing integration adapters as WCF (Windows Communication Foundation) channels.

Features

The Adapter Framework consists of the following components:

Adapter Framework Runtime

The run-time consists of services that expose the adapter logic as WCF channels. This layer hides most of the complexity of the channel architecture and lets the adapter developer focus on Line of Business (Siebel, SAP, etc) specifics. These services auto generate much of the channel-level code based on declarative attributes used by the adapter developer. The framework also extends the channel architecture with Metadata components. The framework provides for metadata cache mgmt, connection mgmt etc that adapter developers can leverage to simplify the development process.

Adapter Development Tools

The development tools include Visual Studio extensions and project wizards that automate much of the tedious and busy work required to wire up adapters including the adapter deployment projects.

Adapter Development SDK

The SDK includes project samples, walkthroughs and an Adapter Development Cook Book that goes thru in detail the various aspects of adapter development

WinFX Line of Business (LOB) Adapters

An adapter is fundamentally a module that bridges a client program and an external system, exposing well-defined and standardized interfaces over various programming models to the client program while internally mapping them to proprietary interfaces and protocols supported by the external system.

Application adapters provide an interface to Line-of-Business (LOB) systems like SAP, Siebel, Oracle Financials, PeopleSoft and JD Edwards. Database adapters provide an interface to database systems like Oracle, SQL Server, Sybase and DB2. Transport adapters provide an interface to transport protocols like HTTP and FTP and message-oriented middleware (MOM) like Tibco, Websphere MQ and MSMQ.

The WinFX Adapters deliver application, database and transport adapters by implementing a common Adapter Framework, which in turn is built on top of the Windows Communication Framework (WCF). Technically the WinFX adapters are exposed as WCF transport channels to clients, enabling connectivity, metadata exchange and business data exchange with external systems.

The WinFX adapters make line-of-business applications, databases and messaging platforms visible and interoperable with standard business processes, workflows and .NET applications They promote reusability and “plug ‘n play” across disparate applications. Different programming models can be built on top of the WCF adapter framework giving client programs the choice of programming models based on business needs. ADO.NET, WCF proxy programming and WCF channel (message-level) programming are a few programming models. The adapter framework eases adapter development in terms of providing simplified abstractions that handle common infrastructure and plumbing aspects of adapter building besides providing common runtime services. This enables adapter writers to focus on business logic required to interface with and surface external system functionality. It also empowers partners to develop custom adapters. The choice of WCF is essentially inline with Microsoft’s next generation communication framework optimized for the web services enabled world. It automatically web service enables external systems that are being adapted using WinFX adapters

Migrating BizTalk 2004 (VS 2003) Solution to BizTalk 2006 R2 (VS 2005)

While the BizTalk Server product team has done a great job of being able to migrate an already deployed BizTalk 2004 solution to BizTalk 2006 in-situ, there is definitely some effort required in upgrading the Visual Studio solution itself such that subsequent deploys actually work.

The situation is complicated by two things: the change in project definitions between VS 2003 and VS 2005, and of course the migration from .NET 1.1 to .NET 2.0 (there should be no complication by .NET 3.0 / 3.5 with BizTalk 2006 R2 as .NET 3.0 / 3.5 is an extension to 2.0).

Depending on the solution, some of the items may not apply, and there may be some other issues to be taken care during the migration process (for example handling deprecated classes, method overloads etc).

Export the port bindings and configurations to XML before making any changes.

When you open the VS 2003 SLN file in VS 2005, VS will prompt you to migrate the solution, just follow the migration wizard. Once the wizard completes porting from VS 2003 to VS 2005 it will generate a report of the items you may need to fix (e.g. deprecated classes) .
Migrate all the WebService Projects which are referenced by BizTalk
Migrating the BTS Projects

Re-build all the web reference in the project.

Remove all the web reference and re-add them with the same name
If you use Dynamic web references, ensure that property is selected
Add a reference to System.Configuration if it is not there already (to avoid compilation error)

Open the project's properties

Assign a default BizTalk Configuration Database
Assign an Application Name

For each schema in your solution that uses promoted properties

Open the 'Show Promotions' dialog. to rebuild the xsd's code-behind (.cs)

For each orchestration with a web-port

Delete the configured web port (since you regenerated the web reference)
Re-add the web port with the same name, ensuring it is a Dynamic web port if necessary
Re-assign message types for messages defined in Orchestration Explorer
Re-connect send/receive shapes if necessary

6. If your using dynamic maps then verify the fully qualified name of the assemblies are correct

7. If you have custom functoid then treat them as new functiod and place them in GAC and BizTalk reference directory. And re-add them to your map

8. If time permits then migrate your existing web service to WCF – Preferred going forward

Once you build the solution you might end up with tons of warnings. Some of the warnings have been added to assist in improving the performance/stability of your BizTalk solution. The one most notable to my solution was the following:

Performance Warning: marking service 'OrchestrationName' as a long running transaction is not necessary and incurs the performance penalty of an extra commit

For orchestrations where long-running was not necessary (ie do not contain send/receive pattern or other long-running transactions), I have since changed them to use Transaction Type of None. Hopefully we will see a reduction of database chatter for these orchestrations when we benchmark the changes.

UCD 101

Paul.Dawson — Tue, 22 Jul 2008 08:33:04 GMT

Ok, I've been meaning to post this for a while, so sorry it's late... but I talk a lot about 'experience' and user-centred design, and occasionally, I stumble across someone who doesn't come from my universe and isn't as keenly aware of what some of this means. So here begins, hopefully, a small series of blogs on the basic principles of User-Centred Design (UCD) and user experience generally. The aim is to do each in 500 words or less. Something I'm not very good at, so bear with me. Herewith, UCD 101:

User-centred design (UCD) is an industry-standard term for an approach to the design of a solution that takes a detailed look at the needs of the end users of a solution, and then specifically sets about creating things that satisfies those needs.

Done well and in an organisation that truly 'gets it', this approach will drive not simply how something works, but the overall 'product' the company has to offer. UCD is a very effective innovation framework, as it looks at un-met needs in its customer base and potential customer base. This basic approach has been the key driver of invention since forever, so UCD is a perfect framework to drive everything from product innovation to interaction design.

In order to be effective, UCD can't purely be 'user' design. i.e. it cannot simply be 'what users want'. Take a look at Homer's ideal car below to see how bad this approach can be. UCD is about understanding users' wants and needs, coupling that with an understanding of what will drive the commercial business and what the technology is capable of, and then design an appropriate, beautiful and enjoyable experience or product.

It's something often summed up as balancing desire, feasibility and viability. Unless you get all three right, the thing will fail.

Lose 'desire' and nobody will come to use it. Thereby collapsing any business case you had built on it.
Lose 'feasiblity' and you may not even be able to build it in the first place.
Lose 'viability' and it will be too expensive, or hard to maintain and the business needs won't be met.

The best products balance all three very effectively. So a UCD process is actually one that also is business-centred and technology-centred. That's a lot of centres... but the secret is mutual gain.

Usually, unless we create something that somebody wants to do ('Desire') it's going to fail. So usually, the reason we call this user-centred is that unless we have users, nothing else works; but as we said in reality the game is mutual gain. We can give users lots of things they want to do, but where is the business value? When we find overlap between user-benefit and business-benefit, those are the magic moments that will make a system or business successful.

Sometimes a business just has to do something. It might be a regulatory requirement for example. But even this requires attention to the 'desire' element. In this case, the base system comes first. "We need a system to get customers to sign our new terms and conditions". Viability is ticked as it's a 'must do', but now we have to address 'desire'. How do we make people do this? It's best if they want to do it as it will happen faster and they will be happier - but what motivates them?

Finally - UCD should have a success metric of user happiness. User happiness is a user benefit that overlaps with business benefits, but is often left unconsidered. In internal systems it leads to staff loyalty and lowered support costs, in customer-facing systems it generates increased trade and loyalty. But more than that, because loyalty can be generated simply by having the right product at the right price and not letting people down on delivery. That's all good, but you can go further. When you get customers emotionally invested in something, you move from simple loyalty, to advocacy, which is a far more valuable attribute for business. It's 'experience' that generates this emotional attachment...

Words: 576 - Doh!

Thanks to / people to read: Alan Cooper - The Inmates are Running the Asylum; Lou Carbone - Clued In.