Prism, MVVM and Silverlight – Gripping it by the short and curlies – introduction.

Today, and for a few hours yesterday, I found myself “on the bench” for the first time in 4 years – that means I’ve got a little bit of time to brush up on some concepts, write some spikes and equip myself with some new tools before I start another engagement. I figured I’d use this time productively to brush up on the latest incarnations of Silverlight (4) and Prism (4) by trying to build out a sample application.

The question is, what to build? I only have a day or so which means I need it to be simple-ish, but interesting. Well, recently, I’ve been playing with an iPad application called Popplet (links: Website, get it on iTunes) – which is a pretty neat little app that lets you essentially drop post it notes (text or image) onto a canvas, drag them around into some layout that makes sense to you and connect the various boxes. I’ve used it for brainstorming ideas, thinking about application components and how they relate and a bunch of other things.

Inspiration? Check! – this kind of application covers a bunch of things that I’d like to cover off with this exercise;

• Expressing a reasonably complex model.
• Visualising that model
• Data templates or components for the notes.
• Best way to do the connections between things
• Decorating the notes with resize handles and (for our version) rotation.

So here goes – our back of a napkin specification;

• As a user I want to see a canvas of notes.
• As a user I want to be able to add a new note box to my canvas.
• As a user I want to be able to rotate or resize any of my note boxes on my canvas
• As a user I want to be able to connect note boxes
• As a user I want to be able to delete note boxes
• As a user I want to be able to zoom in and out
• As a user I want to be able to drag my canvas around
• As a user I want to be able to click a button to zoom out to the extents of my canvas so far.

At this point, I’m not going to bother with persistence – that’s a problem that’s well and truly solved, I just want to concentrate on the Silverlight side of life and I’ll stub out the service that would get the data for the user from the database.

So that’s the idea – I’ve spent around 8 hours on this so far and I’m quite impressed with how far I’ve been able to get – the screenshot below might look like crap, but it’s proving out some of the technical issues I’m interested in; If you’re interested, the top and bottom diagrams mirror each other and have two separate data templates – you can add new notes, move notes around, pan the canvas as much as you like and zoom in and out…. quite good for 1 working day!

In coming days I’ll post the full diary, along with all of the source code - I’m keeping a detailed log of the issues I faced and how and why I made the decisions I made in building the application – once I’ve got it all together and the app finished, I’ll post it here. Watch this space!

Software development lifecycle – Part I – Introduction

Software development lifecycle – the process of how we build software, the steps we go through to design software, build it, test it, deploy it – it means a lot of different things to a lot of different people, but yet we find that many organisations aren’t really paying close enough attention to their processes and management of software development which leaves them reacting to problems, not knowing when they are going to deliver, delivering features that are irrelevant or lower priority than missing features and with no deep insight into what they are supposed to be delivering in the first place.

I’ve heard a number of teams say “oh, we’re agile"" – and what they mean is they have no specifications, no plans, no timescales and at the end of it, no jobs because the company employing the team went bust waiting for the team to deliver something.

So, in this series of blog posts I want to take a look through some of the things to think about when implementing structure around your development activity – on the one hand you don’t want to just have a team banging away at code with no formal structure, as the example above, but similarly you don’t want to get too binding with this otherwise you’ll end up with Carl (lets call him Carl in this situation) rocking in the corner, muttering about how he’s “too confined and boxed in maaaan” – development is a creative, problem solving process, let them be creative but within some structured boundaries.

I’m going to keep this series open ended an just chew the fat on a different topic each week and see where we come out. Whilst not a list of topics that I’m going to write on individually, below is a list of some of the things I'm going to explore in this series;

• Typical phases of a project
• How to understand the problems and get a holistic view.
• Involve the business or customer early and keep them engaged!
• Defining the product
• Why bother
• What format
• Who owns the product?
• Understanding and addressing risk.
• Prove it – show me the code.
• The point of spikes.
• Housekeeping!
• Keeping track of risks, issues and key decisions.
• Backlog pruning.
• Keeping the customer engaged.
• Other project artefacts.
• Making a plan – estimation is not about marketing!
• Iterating and aggressive construction.
• Transitioning to live/launch.
• Supporting the product.
• Managing the team
• The role of team lead
• 8 hours does not a day make
• Motivating technical people.
• Doesn’t involve putting the dev team in an open plan office next to the sales department hotlines!
• Continual harassment != productivity.
• Monitoring progress
• Dealing with hold ups and blocking issues.
• Why it’s possible to keep the reigns of management loose and still be impossible to get away with being a slacker.
• Capability leads and subject (domain) experts.
• Recruiting technical staff
• Show me the code!
• Solve this problem!
• Welcome on board – induction or abduction?
• Training and/or free time to experiment.
• Managing the code, the build and quality
• Code reviews – still as important today! But let’s not get hung up on the traditional formality.
• Daily and continuous builds
• The build wall
• Unit testing
• Bugs – squish em soon and squish em often.
• It works on my machine!
• Source control.
• Framework, framework, framework.
• Strategy
• Have one!

Quick explanation of generating dynamic WCF client proxies with Unity;

I’ve been using castle windsor for years now and it’s been my favourite IOC and DI container for a long time. On one of my current projects, I’ve been forced to look at Unity a bit more closely and the first thing that came up for me was how to create WCF client proxies automatically from the shared service contracts. This is how I did it;

I configure the container with code at the moment – I don’t know about you but the usefulness of IOC isn’t the fact that you can replace components at runtime, it’s the clean separation and testability that following a loose coupled pattern gives you. So, I configure my container in code – if I needed the ability to replace bits later, I’d devolve just that part of the configuration out to XML or such like, but I wouldn’t start at XML – it’s too easy to introduce a typo and it doesn’t support refactoring easily.

Anyway, so the complexity of registering a WCF client proxy is it doesn’t have a concrete implementation – I have an interface assembly that contains the service contracts and data contracts and I want to tell WCF to wrap the interface with a channel factory and create the resultant channel.

Unity provides a way of doing just that;

_host.RegisterType<TService>(new InjectionFactory(c => new ChannelFactory<TService>(endpointConfigurationName).CreateChannel()));

TService is our interface and endpointConfigurationName is the name of our endpoint configuration in app.config. What this does is when something wants to resolve an instance of TService, it calls the lambda contained within the injection factory and this in turn creates a channel around the interface.

As such, you can then just go ahead and call your interface members and it will wire everything up for you. No need for service references etc, it just works :)

A modicum of security would be appreciated!

My web hosting package was due for renewal today and I received this email (yeah, I’ve redacted some information to protect me and the people in question); I was quite shocked with the content of the URL that was in the body of the email;

Yes, you read that right, they sent me an (insecure) email that contains in clear text everything you would need to access my account with that provider. Why bother with that https:// at the beginning of the url if you’re going to stick my username and password in the text of the email body too! You don’t need to try and bypass SSL and watch what is being sent to the site, all you need to do is get hold of the email being bounced (insecurely) around SMTP servers and you can have full unadulterated access to my hosting package! (and possibly more – read on!)

I don’t mean to pick on these guys, they aren’t an isolated case, and other people have articulated why this kind of thing is REALLY bad better than I can so I refer you to Jeff Atwood’s articles on “The dirty truth about web passwords” and his post about “The internet drivers license”.

Update: Forgot to add this link in; Smart enough not to build this website