2010Wave

Search Engines vs. Decision Engines

2010-06-26T18:35:00.000-07:00

Bing seems to have branded itself as something it calls a "decision engine" - whatever the heck that means. I just did a search for "decision engine" (using my search engine) and the entry that came up told me that a decision engine is Bing! So it seems to be a circular reference.

On Bing... I get pretty dismayed by the promotional team who mock up screens in the vain hope that they will lead us to believe that their "decision engine" is something more useful than it really is. They artshop these elaborate landing pages which, on the face of it would lead to the early demise of search engines, wikipedia, and digital news services.

Alas, all it not as it seems. The proof is always in the tasting (as they say), and so here we are, right in the midst of Soccer World Cup mania. Everyone is talking about it. The US are better positioned than they ever have been. So let's do a Google vs. Bing bake-off and see what we get:

Here is Google (search engine):

Here is Bing (decision engine):

Decision made! :-)

ASP.NET MVC Data Validation

2010-06-01T22:28:00.000-07:00

I've started to create a set of guidance for developers to show how to implement common validation concerns in business applications. To that end I have created a sample project and an accompanying Guidance document to demonstrate these practices. You can view a copy of these here:

Sample MVC Project - 317KB
Guidance Documentation (PDF) - 682KB

What I would like next is to gather more complex scenarios and implement them. If you have any requests for scenarios that you would like to see implemented, please leave a comment and I will look at adding it in.

Updates
3rd June - Updated to include a new recipe for validating against values bound to dropdown lists

Change

2010-04-28T20:55:00.000-07:00

Change is the process of moving from a current state to a new, improved state. The business world is full of programs that are designed to manage this transition. An alarmingly high percentage of these programs (some say as high as 80%) are claimed to have failed to have achieved what they were designed to do.

In my experience of actual people using actual technology to carry out actual business processes, this is not really surprising. In fact, I would suggest in reality, we should be aspiring to acheive a 100% failure rate if change is the thing that we really are aiming for. Of course in MBA courses, they could never draw it this way as total failure would not fit into 4 quadrants or a concentric circles diagram.

I contend that, in order to know that you need change, you must know that the place you are currently in is not as good as you would envisage. In fact, I would suggest that for all of the places that I've seen, the current actual state is probably deemed (by those who are bound within in it) to be somewhat closer to a scene from Dante's Inferno - in fact, you might as well have these words engraved on plates above the front doors:

"Lasciate ogne speranza, voi ch'intrate" (Abandon all hope, ye who enter here)

At this point it is generally decided that change is requiredd and so the business will create a vision to explain where we need to head and how everybody will feel when we get there. They then "sell" this new vision to the people and this helps to create the feeling of optimism and hope that are required in order to bring about action to enact the change.

Finally - and this is the important part in my story - a formal program is created within the enterprise which is designed to enact the changes that have been agreed upon. Even better, you might appoint a person to be involved in the change program and annoint them as an "agent of change".

The reason that these agents of change (programs and people) are important at this point is that we now have a physical vehicle to attach blame to for when things are deemed to be bad. And I'm not necessarily saying this in a bad way, but think about the alternative. Let me give an example:

People complain about using network shares to collaborate citing that they cannot find things and the organization of information is poor
A change program is created to improve the situation
A modern technology is acquired and installed and training given to the users on how to use it
People complain about using the new technology to collaborate citing that they cannot find things and the organization of information is poor

I can substitute the example with pretty much major change movement that I've experienced and the results are pretty similar - even though you may initially get some good results, the final result will mostly arrive at the same point to which I have observed in the example above.

So if this was the best that it gets, business would be screwed, there could be no room for optimism and everybody would feel like a failure. But having an agent to point towards or to apportion blame against, provides us with the hope that things will become better. In the example above, you may find people citing that things are worse than they were before because:

The technology was a poor choice
The change agent was a poor deliverer
The benefit that would fix a particular problem or concern was planned for a "phase 2" implementation
The business has not given us sufficient training or direction

Being able to purge these things from our system actually gives impetus to a new round of change and so the circle continues.

So we change, and we change, and we change again. Even failed change is better than stasis as it creates activity which motivates people. And a complete lack of change would lead ultimately to death.

Silverlight and WP7 Learning Resources

2010-03-17T15:48:00.000-07:00

Whilst trying to get my head around Silverlight a bit better (it is one of the 2 programming models for Windows Phone) I came across some useful new learning resources:

And if you want to get started with Windows Phone development, the best resources are:

Free e-book: Programming Windows Phone 7 Series
Developer Tools (includes VS2010 Express for WP7) - WP7 Developer Portal
Install checklist for Silverlight 4 RC, Blend 4 Beta and Windows Phone Developer tools from MIX10

There's also a good video of Mike Harsh going through Developing for Windows Phone 7 with Silverlight and his Slides and demos from his MIX10 Session.

Getting Started with Graffiti CMS

2010-03-03T16:18:00.000-08:00

Getting up and running with Graffiti is very easy and one of the things that I really enjoy about using it. One of the things that I've struggled with when using some of the other larger open source products is just getting them going. For example, having to use SQL Server often means that I need to install it, then create the database (and pray that the scripts work) and then do configuration.

Also, some Open Source products are heavily dependant on other open source software. This makes them brittle and tied to what often becomes other unsupported legacy code. This has the knock on effect of making the product harder to get started with as time goes by.

Graffiti on the other hand is lightweight and relatively free of external bindings. This has meant that getting going with an Access database as the backend has not changed significantly in the 3 years that I've been using the product.

To get started, browse to the Graffiti CMS site on CodePlex and work through the "Getting Started" notes that appear on the home page. These lead you through the following steps:

Download the v1.3 source code
Download "extra" assemblies from http://graffiticms.com/lib/lib.zip
Unzip and add the extra assemblies to the \Branches\v1.3\src\Lib folder
Open the \Branches\v1.3\src\Graffiti.sln solution file with Visual Studio 2008
Update web.config to use the desired database settings
If you are not running IIS7 and ASP.NET 3.5 SP1, you should enable the "Generate Folders..." option in the admin >Site Options > Configuration page

Extra Assemblies

The extra assemblies are:

Telligent.DynamicConfiguration
Telligent.Glow - Web Controls by Telligent
Telligent.Glow.Editor - Web Controls by Telligent

These assemblies provide additional functionality and web controls and I believe that they are packaged separately because they needed to be subject to different licensing from the core Graffiti software.

Database settings
The notes for getting a database up and running for your Graffiti installation can be found . Essentially there are 3 parts to this:

Choose your Provider. This is set via the "DataBuddy::Provider" key in web.config.
Update your connection string in web.config. There are samples provided, so just copy the one that is relevant for your database provider.
Set up your database as per the notes that can be found in the \Branches\v1.3\data\read_me.txt file.

If you are using MS Access for your database then getting up and running is as simple as copying a template .mdb file into your App_Data folder and then running the solution. I like the Access database option as it makes the entire website self contained, making it easy to move around and deploy.

Generate Folders
After you have installed and configured your basic set up, you should read through the Getting Started Guide to gain an understanding of more advanced configuration options that you might need to consider. One of the major things that you need to be aware of is the difference between how the site runs under IIS7 and IIS6.

Running under IIS7, the site uses an inbuilt routing mechanism for serving up virtual paths. When running under IIS6, the inbuilt routing is still used, however for that to work, the folders for paths need to physically exist on disk. To acheive this you need to log in to the Administration section and go to Site Options / Configuration and ensure that the "Generate Folders for Posts/Categories" option is checked.

Running the solution
From within Visual Studio, run the application. You can either click login or browse directly to /graffiti-admin/ and then login as an Administrator to start creating content and managing other aspects of the site. The initial Administrator username is 'Admin' and the password can be found in the Graffiti:User:DefaultPassword key in web.config.

Learning how to use Graffiti CMS

2010-03-03T09:17:00.001-08:00

I've been thinking about CMS for a while and recently decided to get back in to using Graffiti CMS as my CMS tool of choice. I've used Graffiti before and I believe that, for a .NET developer, it is probably one of the best CMS tools around.

Late last week I downloaded it and used it to bang out this simple little hockey club website - http://web9ecf9dd.titan.studiocoast.com.au/. Over the next few days I’m going to add several articles which explain how to get up and running using Graffiti and you will see the topics of these articles from the text in square brackets in the bullet pointed list below.

The things that I like about Graffiti CMS are that:

It is .NET based. I am a .NET developer and I really need my tool of choice to have a .NET flavor to it so that I can feel confident that I have full control over the final product. [Using Macros and Chalk Extensions]
It is lightweight. In fact it's probably the lightest of all CMS engines that I know of relative to the number of features and amount of power that it affords. In fact, from the time you download Graffiti CMS, you can be up and running in under a minute if you choose the MS Access data provider. [Getting Started with Graffiti CMS]
It gives me full control over the rendered HTML - Graffiti CMS layout templates are very powerful. [Understanding Graffiti Layouts and Templates]
It's extensible. I can create custom extensions very easily to do pretty much whatever I want. [Developing your own custom Chalk Extension]
It comes with lots of rich features that make it very easy to quickly build and deploy advanced websites. [Users and Permissions], [Themes]
It's open source and it's free.

Further Reading
My Move to Graffiti - nice comparison of different tools

Version Control - a reaction to Martin Fowler's article

2010-02-28T16:12:00.000-08:00

Recently I've been involved with looking at how our team produces software. This has meant looking across the spectrum of activities, tools, and practices that we undertake to deliver working software to the business. It was with this activity still fresh in my mind that I stumbled upon Martin Fowler's thoughtful article about Version Control on his Bliki earlier today.

As part of my work I actually put forward an argument that we move away from using SVN for source control and to implement TFS. As somebody who has deep personal affection for the simplicity of SVN, the decision to recommend TFS was not made lightly.

In light of my own decision to move away from SVN and onto TFS, I was motivated to respond to Martin's positioning of TFS on his summary diagram which placed TFS outside of the tools that he would recommend for version control.

Whilst he suggests that TFS is not a recommendable product, Martin does not make any real attempt to explain other than to say that people he trusts don't recommend it. In this article I want to put forward some of the reasons that I chose for recommending TFS as our tool of choice.

Integration
I believe that it is unfair to look at version control in isolation because, whilst your version control software sits at the heart of your development system, it lives within a larger ecosystem. This ecosystem is made up of IDE's, Issue Tracking Software, Build Management Software, Continuous Integration Services, Reporting, and perhaps other tools and services too.

In light of all of this software that comprises your development ecosystem, consider the technology soup that you are managing. Patching and keeping these systems soon becomes a science unto itself and unless you're job is as a specialist build master where you are entitled to choose individual best of breed applications, managing this type of environment may not be for you.

Moving to TFS provides us with a single technology roadmap and vastly reduces the complexity involved in configuring and patching our environment when compared with the alternative.

An illusion of simplicity
In light of having uncovered the elements of a development ecosystem, let's reconsider our views on simplicity. First I'll start with a statement from my own observations about developing software - Developing software is a complex business. FULLSTOP! PERIOD!

As shown in my previous discussion about integration, the complexity is there always. You can have a simple version control tool but the cost of this is that you transfer more of the complexity to other parts of the system. In the case of having chosen SVN, this complexity comes in the form of having to run multiple, independant systems using multiple technologies.

With TFS you gain simplicity through technology consolidation but you pay a price for having to learn how to set up and manage it - but is this any more complex than having to learn half a dozen other systems?

The real business world
So far I've focussed my discussion about the development ecosystem on the activities of the developers themselves. However in the real business world, this is still not a fair representation of what is needed to successfully deliver working software.

Even small businesses have stakeholders that the software is being developed for and in mature businesses, there is an instrument which sits between (or straddles) the business and technology domain - this instrument is the PMO.

In light of this discovery, it is no surprise that building successful software is as much about soft skills - such as communication and reporting - as it is about purely technical pursuits such as coding, building, and releasing.

By integrating with common business software such as Excel and MS Project, the TFS work item tracking system makes it easier to align IT projects with projects in the PMO and have those functions be able to communicate using a common language.

Conclusion
In this article I have opposed Martin Fowler's view in relation to the placement of TFS on his summary diagram. I believe that his article is too narrowly focussed to be of real value when considering what tools to choose in creating your own software development ecosystem.

However I do agree with his closing sentiments wholeheartedly and I could not have put it any better then when he wrote:

Remember that although I've jabbered on a lot about tools here, often its the practices and workflows that make a bigger difference. Tools can certainly make it much easier to use a good set of practices, but in the end it's up to the people to use an effective way of working for their environment. I like to see approaches that allow many small changes that are rapidly integrated using Continuous Integration. I'd rather use a poor tool with CI than a good tool without.

Productive Software Development

2010-02-09T19:01:00.000-08:00

Today I read through a thoughtful set of blog posts (about 7 in total) on the topic of software and exerting control over it:

http://blog.scottbellware.com/2010/02/to-control-and-observe-productive.html

At the bottom of each post is a “Next” link which takes you to the next article.

If you have time to read it I would recommend it and if you do, think in terms of how a chunk of software should look in order that you can examine it under controlled conditions. These things lie at the heart of the management of dependency management and testing.

The author (Scott Bellware) leads us to think about how we use efficiency as a lever – and what the consequences of that can be – was also a thoughtful exercise.

The article also spoke to me in other ways. An additional concept that I drew out while reading this text was that of authenticity and the motivation that I have for the things that I'm responsible for.

As mentioned by @kzu, this is a verbose style, but a story well told and one which contains some very useful and valid points.

SharePoint (2007 or 2010) Architecture - Part 2: An MVC Style Implementation

2010-02-08T01:27:00.001-08:00

Recently I started a code refactoring exercise for some SharePoint code and here I will lay out a very simple architecture that I have implemented for creating web part views. I want to start here because this is the beginning. In a future post I will show you how to refactor this code to introduce more and more patterns of encapsulation to show you how we can grow to accommodate new needs.

The cost of impedance mismatches
Remember in the first article that I presented an image to highlight how implementations can differ.

A major reason for this difference is that, in the absence of clear protocols and contracts, information can easily be lost during communication of expectations. And in the face of differing expectations and outcomes, the result can lead to changes that are hard to check for conformance and difficult to estimate for the purposes of cost. Additional costs can include excessive rework.

So the implementation that I will talk through in this article is primarily designed to introduce a degree of conformance and consistency into the development process. Whilst the code artifacts that will result from this article may violate some architectural norms, what we will be left with will form a good base from which to build upon and should lend itself to enough abstraction that it can easily be factored and improved over time without making the overall application unnecessarily unstable.

Separating out the database access code
The first thing that I’ll do is to create a custom Command abstraction to encapsulate the execution of my data access code. The Command will fetch data from a repository somewhere and return me some domain objects to work with further up in my architectural stack.

In my application there will be a base Command abstraction that will form the base of more repository specific classes of Commands. Each of these repository specific classes of Commands would have understand how to connect and communicate with repositories of a specific type, e.g. SQL repositories, SharePoint repositories, File System's etc.

And then those repository specific Commands will get sub-classed into specific, domain-specific commands.

At the bottom of the class hierarchy for commands we have a simple abstraction of a base Command class. This class defines a template with an Execute method and returns strongly typed results via a Result property:

public abstract class Command<T> 
{
    protected T _result = default(T);

    public T Result { get { return this._result ; } }

    public abstract void Execute();
}

Sitting above the base Command class we have specific abstractions for the various different types of repositories that we are accessing. In the case of SQL repositories, I am specifying via constructor constraints that any SQL commands are dependant upon receiving a connection string and a commands.

public abstract class SQLCommand<T> : Command<T>
{
    protected string connectionString = "";
    protected string commandText = "";

    public SQLCommand(string connectionString, string commandText) 
    {
        if (string.IsNullOrEmpty(connectionString)) {

            throw new ArgumentNullException("connectionString");

        if (string.IsNullOrEmpty(commandText)) {

            throw new ArgumentNullException("commandText");

        this.connectionString = connectionString;

        this.commandText = commandText;

}

    public override void Execute() { }
}

And finally, at the top level we have specific commands. Here is an example of a Command which encapsulates the logic for getting information about the daily weather from a SQL repository.

public class GetWeatherCommand : SQLCommand<WeatherInformation> {

    const string _commandText = "spGetDailyWeather";

    public GetWeatherCommand(string connectionString) 
        : base(connectionString, _commandText) { }

    public override void Execute() {

        WeatherInformation weather = null;

        using (var cnn = new SqlConnection(connectionString)) {

cnn.Open();

            var cmd = new SqlCommand(commandText, cnn);

            using (var reader = cmd.ExecuteReader()) {

                if (reader.Read()) {

                    weather = new WeatherInformation()

                        Temperature = int.Parse(reader[0].ToString())

};

        this._result = weather;

Over time we can identify ways to refactor our commands by pulling apart and pushing specific pieces of logic further down our Command stack. For example, it may be that the job of creating and managing the lifetime of connection objects are pushed into the base SQL command or that we further abstract the data reading and handling process so that we don't have messy parsing logic duplicated at this level.

Commands return custom entities
Notice that the Command pattern allows for custom entities to be returned. This ensures not only that we enforce strong-typing throughout our solution but also so that we properly abstract and encapsulate our entities and protect our application from changes that we might make such as changing the underlying behavior or version changes such as newly added properties that our entities might take on.

Modelling view logic
View modelling allows us to simplify UI logic - and by separating responsibilities it also helps to keep our HTML "clean". For example, in our example we may have other information that we can infer from our Temperature entity that will be useful to display to our users. An example might be that we want to display a different CSS color based on what range the temperature falls within. In this case we can model that logic in a view model class that we can later bind directly to a UI layout template:

public class DailyWeatherViewModel

{
    private WeatherInformation weather = null;

    public DailyWeatherViewModel(WeatherInformation weather) {
        this.weather = weather;

}

    public int Temperature {
        get {

            return this.weather.Temperature;

}

    public TemperatureRange TemperatureRange {
        get {

            if (this.Temperature < 0)

                return TemperatureRange.VeryCold;

            else if (this.Temperature < 15)

                return TemperatureRange.Cool;

            else if (this.Temperature < 25)

                return TemperatureRange.Mild;

            else if (this.Temperature < 35)

                return TemperatureRange.Hot;

            else

                return TemperatureRange.VeryHot;

}
}

public enum TemperatureRange : short 
{
    VeryHot,
    Hot,
    Mild,
    Cool,
    VeryCold,
}

Looking at the Core project now we can see that code that was required so far. Here we see that we have our SQL Command class which will return an entity and that we also have a separate abstraction for our view logic.

Separating view layout from code
By using a HTML Template for the layout view we get benefits such as having designers who are able to work on the user interface and also a good separation of concerns between layout and application logic.

In the case of this Weather component, I might initially choose a simple layout as shown in the following code snippet, but it is still a simple exercise to change this over when the designer comes back with a new layout template later.

<div id="BirthdayText">
    The temperature is: <%= this.Model.TemperatureRange %>
    <img src="/_layouts/<%= this.Model.TemperatureRange.ToString() %>"
        alt="<%= this.Model.TemperatureRange.ToString() %>" />

</div>

The code behind for this HTML template might look something like this standard piece of ASP.NET codebehind:

public partial class DailyWeatherControl : UserControl {

    public DailyWeatherControl() { }

    DailyWeatherViewModel model;

    public DailyWeatherViewModel Model {
        get {

            return this.model;

        set {

            this.model = value;

}
}

Web part as the coordinator
Back in part 1, I mentioned that I look at Web Part code to only have up to 120 lines of code. These lines of code will be somewhat dependent on how much event handling your web part has to do, but you can use 120 lines as a baseline for a simple Web Part which simply renders data and handles little or no user input.

In such a case the Web Part is responsible for orchestration and coordination of the flow of control. The Web Part will create instances of commands and view models; it will instantiate layout templates and pass the view models to them. Very simple indeed.

For our Web Part class...

public class DailyWeatherWebPart : System.Web.UI.WebControls.WebParts.WebPart {

    protected override void OnLoad(EventArgs e) {
        base.OnLoad(e);

        this.EnsureChildControls();

}

    protected override void CreateChildControls() {

        base.CreateChildControls();

     var connectionString = ConfigurationManager.ConnectionStrings["AppSqlConn"].ConnectionString;

     var weatherCommand = new GetWeatherCommand(connectionString);

     weatherCommand.Execute();

     DailyWeatherControl weatherControl =

       (DailyWeatherControl)Page.LoadControl("~/_controltemplates/Neimke/WebParts/DailyWeatherControl.ascx");

        this.Controls.Add(weatherControl);

     weatherControl.Model = new DailyWeatherViewModel(weatherCommand.Result);

}
}

From here we might eventually decide to abstract further the complexities of template instantiation and error handling to another base class.

What have we achieved?
I mentioned at the start of this article that the architecture that we created would provide us with a good base from with to establish norms and standards. And that what we create should lend itself to improvement through further refactoring. And you will recall that I sought to provide a solution to having developers who produce expected outcomes.

Given the architecture that I have presented, I could now expect that, when I ask for web part to be developed, I already know what the delivery should look like:

A Command
An Entity
A ViewModel
An HTML Layout Template
A Web Part class

This makes the job of passing or failing code based on conformance much simpler. And by being able to have such disciplines at play within our development team should ultimately lead to higher quality outcomes.

The final layout of our solution looks like this:

Where to from here?…
In the next article I want to take the code refactoring deeper to look at how we might introduce new patterns that will allow us to increase the testability of our code.

SharePoint (2007 or 2010) Architecture - Part 1: Building a case for quality

2010-02-07T11:55:00.001-08:00

In the wild, the development of SharePoint customizations is still a bit like the Wild West when compared to where things are at with other forms of modern software development. I'm not blaming the developers or even the architects for this dilemma because developing and deploying custom software for SharePoint can be difficult - a bit like trying to swim against a strong tide. In this article I would like to explain some simple concepts that might make your overall SharePoint development and maintenance experience more bearable.

Note:
If you are developing solutions for SharePoint then you should also read my other SharePoint development articles and, in particular my article about using your build server to help make the process of deploying your customizations much nicer.

What is architecture?
Architecture refers to things that are designed and made by people. And the design is generally a carefully planned thing. This allows us to logically separate between things that a child might build with Lego, mud or clay and, let's say, the structure of a well-designed chair or a house.
Sometimes the code that gets deployed to SharePoint shares more in appearance with mud pies or messy piles of Lego than with a well-planned and organized room.
To be of a high good quality, it is required that both the architectural underpinnings of your code be strong and firm and also that the organization be consistent and well formed.

Note:
Fowler suggests architecture is the things that the senior developers on the team agree are probably important, and are hard to change. Re: the house, the architecture might be the direction it points, and whether it is one storey or two. The organization of the room is just code that's easily changed.

Why is architecture important?
Let's say that you produce a single web part and that you deploy it into SharePoint. For the next month or so you might get some change requests and you are happy to wear the pain of re-deploying it and everybody is happy. But multiply that pain by 3 or 4 (or more) developers and by 4 or 5 (or more) applications and by 3 or 4 (or more) features... and you are already in living, developer hell. And that's even before the first round of maintenance comes along from your initial deployments.
At this point in time - and I'll ask you to take another look at that scoop of spaghetti in the image - your agility and therefore your ability to change is gone! Before you know it, you are unable to meet the demands of the business and you are spending your nights working out how 4 year old code works.
Identifying good and bad code?
There are some worrying signs to look out for and code smells that you can observe in your SharePoint code repositories if you are hoping to avoid the aforementioned road to hell.

Your web part classes have database access code in them
Your web part classes have intimate knowledge of how to configure things
Your web part classes have more than a couple of methods

They are the commonsense metrics, now let me give you my gut-feel metric:

If you have more than 120 lines of code - in total - in your web part class file then that is a "smell" and needs further investigation. And yes, that includes Namespace declarations and everything!

If we apply good architecture and code organization techniques to our SharePoint coding, then our code will be well factored and easily understood across the whole team. It will be easier to change and manage.
How chaos occurs – a short walk through

A day comes when you need to develop a new Web Part and add it to your solution. You might come up with an idea for this web part and then ask one of your developers to implement it. Let's suggest that our code has an unclear architecture and that the organization of it is untidy. What will the developer deliver?
He may decide to implement a single web part class with lots of code in it. Code which connects to a database, grabs some data, caches it, and then sets out to render the user interface of the web part by reading through whatever object the database returned.
Alternatively your developer may choose to start creating a bunch of classes within your solution to do things. But what are these classes? What are they called? And are we happy with the concepts that are being introduced?
I'm not saying that any of these things is necessarily the wrong thing, but in the absence of specific guidance and existing patterns, you can see how things can get rather messy indeed.
What you want is that, when you ask for the web part, you will know pretty much exactly what will be delivered in terms of a final set of artifacts. So that what is built when creating one web part will be the same as what is built when creating the next one. Building upon common foundations and delivering with consistent organization.
Taking the architectural path
Think of your web part as you would any other architectural artifact and layer your software so that you have a sensible separation of concerns between each of the different functions within your application. But don't start by thinking that you have to build something that is perfect, there is no perfect. Perfect is whatever works best for you and your team. But we still need to work along common patterns and standards, so let's start with the some age old sensibilities and separate things along the lines of:

Models (getting our hands on the data)
Views (showing awesome stuff to our users)
Controllers (orchestrate the processes between data and view to ensure that things run smoothly)

Notice that I didn't mention anything about choosing your favorite IoC container or how to create Mock classes for testing? I'm just skimming across the top - because I am assuming that your team needs time to learn how to get better. The low hanging fruit is what is important when you are trying to improve your coding standards... you don't need to start at the lowest level.
My suggestion is that, when you are starting your improvement journey, be pragmatic, start somewhere around halfway between heaven and hell. Because premature optimization is the root of all evil, and, while you can try to start out by cramming every concept that you’ve ever read about into your architecture right from the beginning, a lot of the time patterns within those architectures are put in place to solve problems that you may never even experience. So while your architecture might feel elegant... you ain't gunna need it!
In the next article I will talk through a specific implementation for a SharePoint Web Part and highlight its benefits.

FUSE Labs and Social Media – Producing great tools for the wrong people?

2010-01-30T03:54:00.001-08:00

I never told many people about this but, last year I got pretty anxious for a while about the informal way that personal data had becoming readily available through social networking sites such as Facebook, LinkedIn and Twitter. This was reinforced to me when rich clients such as TweetDeck and Fishbowl started coming out and I could see the real power of the API’s of these sites in full view. Even more when I decided to go and take a peek at the API’s that Facebook makes available to developers and started to understand that I might be sharing personal information about my relationships or my location without even being fully aware who I was giving it to.

I remember at the time being able to completely visualize what sort of tools the bad guys would be capable of creating if they really put their minds to it. Not to belittle the efforts of the people who wrote TweetDeck and Fishbowl, but it’s really getting easy to build very rich dashboards to represent social graphs and with a little additional logic, I could see that you could pivot around on this data in some really interesting ways.

Fast forward 8 or 9 months and the game just keeps getting a whole lot more interesting with people such as Twitter allowing applications to store the geolocation along with the other bits of the tweeted data. This technical shift opens the door for new innovations to rise up in how we visualize information based on the location when it was being created. The following image shows a picture of Bing’s new Twitter Map tool:

As you can see from this picture, I can see location-based tweets over time (past 7 days) and then I can use filters to isolate certain data (e.g.: view only tweets made by a single user). Couple that with tools like the new Silverlight 4 Client for Facebook and you start to understand how much intelligence you could build around this stuff:

Couple that with the potential reach that you get across a social graph from deploying Facebook applications and you could build a very interesting, location based “listener”. Pictures, events, places, comments, and times.

Using technology for good

OK, so that’s enough paranoia, let’s look at what I think needs to happen to balance the scales a bit. We know that technology can be a terrific aid in helping to uphold safety, just as it can be used for bad stuff. Here is a link to the text from Steve Ballmer’s recent speech at the Worldwide Public Safety Symposium.

In and of itself, Bing Twitter Maps is not massively useful right now. For example a relatively minor number people are producing geo-coded tweets and so what you see when you look at this tool is a demonstration of capability. But think about how useful tools such as this could be in a crisis sometime in the not too distant future. A tool such as this could help somebody who was in distress to get a message out. It could be used to monitor activity near the scene of a crime – such as a burglary – and it could help groups of people who are often in disparate locations to understand when they were located near other members of the group.

For some of these types of scenarios to play out, I believe that we need more metadata so that different classes of information could be visualized in better ways. Consider what could be done if there was a metadata standard for Twitter which was the equivalent of a 911 or emergency message. Metadata such as this would allow individuals to send out distress signals and to perhaps have them acted upon.

Similarly, what if there was the ability for certain agencies to annotate their data with certain information which carried special weight with regards to public interest? Fire departments or local councils could start to create messages which plugged in to the raft of tools that are starting to emerge. Imagine a social network dashboard which was able to interrupt you with an important announcement about an event which was occurring nearby to you.

I think that as more standards start to emerge in the way that these types of information are transmitted, we will start to see some really amazing experiences being built and some which carry tremendous social responsibility messages to us.

Until that day arrives, maybe we will be dazzled by new rich renditions of information, but whether it has great application in our lives might be debatable. With the current tools the way they are, I think that there’s more on offer for petty stalkers than there is for seriously digital communities, groups, and individuals.

Creating and running an Azure package by hand

2010-01-26T02:05:00.001-08:00

Note: there appears to be a bug in this which is currently preventing the web application from "spinning up" on my machine. I'm not sure what the problem is but I will correct this post when I find it.

Recently I was running a limited version of Visual Studio which didn’t allow me to build Azure packages because the VS and Azure bits were out of sync. So I ended up having to build the Azure bits by hand and I thought that in this post I would share how that was done. In this post we will create an ASP.NET MVC application and attach it to an Azure Web Role. After that, we will deploy it to our development fabric and run it.
Create the ASP.NET MVC Application

Open Visual Studio, click New Project and create a new ASP.NET MVC 2 Web Application called HelloCloudService
Manually add a reference to the Azure .NET assemblies (these are located in the ref folder where you installed the SDK – the default path is C:\Program Files\Windows Azure SDK\v1.0)

Change your Index action so that it looks like this:

public ActionResult Index()
{
    if (RoleEnvironment.IsAvailable)
    {
        ViewData["Message"] = "Welcome to the Cloud!";

} else {
        ViewData["Message"] = "Welcome to ASP.NET MVC!";

}

    return View();
}

Press F5 to run your web application and you should see that we are indeed NOT running in the Azure cloud fabric.

Create the Web Role

Next we will create our Service Definition (.csdef) and a Service Configuration which matches it (.cscfg)

Go to the folder which contains your Web Application project folder and create another folder alongside it called WebRole
Open the WebRole project and create a new text file named HelloCloudService.csdef. Open the file using Notepad. You can read about the schema for the Service Definition file here.

Add the following text to your .csdef file and press save:

<ServiceDefinition name="HelloCloudService"

xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="HelloCloudServiceWebRole">
    <InputEndpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
    </InputEndpoints>
  </WebRole>
</ServiceDefinition>

Open the Windows Azure SDK Command Prompt in elevated mode, type the following command, and press enter (you will have to change any paths to suit your file locations):

cspack "D:\Sandboxes\2010Wave\HelloCloudService\WebRole\HelloCloudService.csdef"
```
/role:HelloCloudServiceWebRole;"D:\Sandboxes\2010Wave\HelloCloudService\HelloCloudService" 
/generateConfigurationFile:"D:\Sandboxes\2010Wave\HelloCloudService\HelloCloudServicePackage\HelloCloudService.cscfg" 
/out:"D:\Sandboxes\2010Wave\HelloCloudService\HelloCloudServicePackage" 
/copyOnly
```
Interesting things to take note of here are:
- We are generating a Service Configuration file named HelloCloudService.cscfg and placing it within the deployment package folder. This file is based on the Service Definition that we specified in step #3. So had we declared any configuration items in that .csdef file, there would be stubs for their values in the Service Configuration file.
- By using the /copyOnly flag, all files are copied into a folder hierarchy whereas omitting this flag would produce a .cspkg formatted file that would be used as a deployment package for deploying to Windows Azure. That’s what I showed in a previous post on how to deploy into the cloud as part of your build process.
At this point you should have created a CloudService package folder and you should find it positioned like so:
Looking at the structure of that folder we see an elaborate hierarchy:

Running the CloudService in the Development Fabric

From the same elevated command prompt we can check to see the status of the Dev Fabric to see whether or not it is running:

You can find the reference documentation for CSRun.exe here.
We can see in the above image my Devfabric service is not running… let’s start it by typing the following commands:

csrun /devfabric:start
At this point you should see the Devfabric service icon (it’s the one which looks like a blue Windows flag) appear in your system tray icons
Now we can launch our Service on the devfabric by calling /run and passing in the path to the location of our package and the configuration file that we generated using CSPack
```
csrun /run:"D:\Sandboxes\2010Wave\HelloCloudService\HelloCloudServicePackage";
"D:\Sandboxes\2010Wave\HelloCloudService\HelloCloudServicePackage\HelloCloudService.cscfg" 
/launchbrowser
```
Things to pay attention to here are:
- We are specifying to pass in the Service Configuration file that we created previously as part of our packaging command
After running that command, a browser window should appear with your web site hosted within it but now showing a message of “Welcome to the Cloud!”
If you right click on the Devfabric icon in your system tray and select Show UI you will also so that your service is now indeed being hosted in the Devfabric

How to build an Azure Cloud Service package as part of your build process

2010-01-25T01:32:00.001-08:00

I explained in a previous blog entry how important, and ultimately simple, it is to create a deployment package for SharePoint as a part of your Continuous Integration process and in this post I’d like to show you how to produce deployment packages for Windows Azure. This article is laid out in the following sections:

Deploying to Windows Azure
The CSPack Command Line Tool
Automating the Creation of your deployment package

Deploying to Windows Azure
Those of you who have deployed solutions to Windows Azure in the past will know the routine. That is, you must:

Create an account and then login to the Windows Azure portal (this is done through http://azure.com but for the purposes of this article I am going to use the tech preview site).
Create a cloud service project for your account – in the following image I have 3 cloud services in my PDC08 CTP account:
Then click on a Cloud Service project to access the user interface to upload new deployments and toggle them between staging and production:

The packages that you upload into the Cloud Service project is a Cloud Service Package format and is created by an Azure SDK tool called CSPack.exe. These Cloud Service Packages have a .cspkg file extension and are also built into the Visual Studio tooling so that creation of these packages is all done seamlessly as part of using the Visual Studio tools. As mentioned in this article, this is as simple as right-clicking on a VS project node and choosing the Publish option.

The CSPack Command Line Tool
CSPack.exe is a tool which comes as part of the Windows Azure SDK and, when installed, it can be found at C:\Program Files\Windows Azure SDK\v1.0\bin\cspack.exe

As per the documentation for CSPack, the syntax for using this tool to create a package is:

CSPack <service-definition-file> [options]

And the options that we are interested in are:

Argument	Description
/out: <file \| directory>	This option indicates the output format and location for the role binaries.
/role:<rolename>;<role-binaries-directory>;	This option specifies the directory where the binaries for a role reside and the DLL where the entry point of the role is defined. The command line may include one /role option for each role in the service definition file.

And actual sample usage would look something like this:

cspack \ServiceDefinition.csdef 
/role:AmbientPlacesWebRole;\CloudService.WebRole 
/out:AmbientPlaces.cspkg

In this example you can see that we are passing in the path to the .csdef file which describes the definition of our service, including what configuration items that we are specifying. Next we pass through the directories and names for each role that is specified in our Cloud Service Defnition (.csdef) file. Finally we can optionally be explicit in specifying the name and location of our outputted Cloud Service Package (.cspkg).

Automating the Creation of your deployment package

Building the solution as part of our automated build process is very similar to what we did when we created our SharePoint deployment package my previous article on the topic:

Except that, instead of using WSPBuilder.exe, we would use CSPack.exe in those places.

You can refer to my previous article to see how we did it for SharePoint packages, but for building Cloud Service packages I would refer you instead to the following blog post which does an excellent job of explaining on way to do the same thing from an MS Build script:

http://blogs.msdn.com/domgreen/archive/2009/09/29/deploying-to-the-cloud-as-part-of-your-daily-build.aspx

Another option that is available is to use the Windows Azure PowerShell Cmdlets to customize your deployment process:

http://blogs.msdn.com/chabrook/archive/2009/10/26/azure-powershell-cmdlets-announced.aspx

Reflections on the Microsoft MVP Program

2010-01-21T15:09:00.001-08:00

Back in 2004 I was lucky enough to rewarded for a bunch of community activity that I’d been doing with my first MVP award. At the time this meant a lot of forums activity on ASP Messageboard and the newer ASP.NET forums and I was also developing and managing quite a few open source software projects. I’ve been re-awarded every year since then – up until this year that is. For the last couple of years I’ve focused more and more on my management and hockey coaching skills and this has meant no time for “giving” to the community – unless a couple of thousand tweets per year counts So now I am no longer an MVP for the first time in 6 years.

I’ve reflected on the MVP program many times before but my opinion still has not swayed significantly from what I wrote here back in July 2006 – and yes giving up the MSDN subscription is going to have a pretty hard impact I expect. I also agree strongly with what @davidlem wrote back in his post back in January of that same year.

During my time as an MVP I was lucky enough to work for employers who supported me and this allowed me to travel to Seattle on several occasions to attend MVP Summits. And I have great memories of those! Meeting with real Redmondites and making a personal connection with so many of them has really helped me in my career and made it fun along the way too. Justin Rogers, Doug Seven, Kent Sharkey, Duncan MacKenzie, Jonathon DeHalleux… the list goes on. Meeting and getting to talk with people such as Anders Heilberg, Paul Vick, and Don Box and being able to attend keynotes delivered by both Steve Ballmer and Bill Gates were standout highlights. Of course meeting and making relationships with community leaders (and there are too many for me to start naming them) was also an enriching experience.

So if you are an MVP now, my advice is to use the program as a tool and take the opportunity to attend these conferences because they are truly unique opportunities and you won’t regret it. And while there, go out of your way to say “hi” to people. Get to know some of them. Read their blogs, chat with them, have a beer with them.

There are changes that I think could be made to improve the program but they are largely encapsulated in the previous blog posts that I linked to. Given the chance to make any single change, probably upping the churn factor would be the thing that I’d like to see. To give more people opportunity and to force others to cherish their moments in the program while they have them – to take advantage of that time.

So where to now? Who knows… I’m yet to fully decide how much time to take from business and sporting interests to channel back into technical community activity. I’d love to, but you’ve got to do things that make you happy for the right reasons. But I am grateful for what I’ve had and I’d love to personally thank all those who have supported me over that time.

How to reference the jQuery libraries from within your SharePoint environment

2010-01-20T02:48:00.001-08:00

If you’ve decided that you want to implement a modern client-centric approach to your SharePoint page customizations you may well decide to use jQuery as a major ingredient. If you do then you will need to decide how to reference the jQuery library scripts from within your pages. In this article I will show you how to use the AdditionalPageHead delegate control to implement an elegant approach to solving this puzzle.

SharePoint 2007 provides us with a very elegant way to insert items into the head section of our HTML pages. These insertions might typically be referencing additional CSS or JavaScript resources. The mechanism that is provided by SharePoint is a DelegateControl with an ID of AdditionalPageHead. The cool fact about the AdditionalPageHead delegate control is that it allows multiple controls to be injected into it!
You can read the following articles to see examples of using the AdditionalPageHead delegate control to perform these types of common tasks:

A good scenario for thinking about using this type of approach might be if you are developing a WebPart which makes use of jQuery. In this case you will want to deploy your custom WebPart as a feature and have all of the resources packaged correctly so that everything comes together at runtime. These resources include:

The jQuery library JavaScript files
Your WebPart class
JavaScript behaviours for your WebPart
CSS styles for your WebPart

You would separate out the resources that are specific to your web part from the jQuery library which should form part of the common infrastructure of your page so that other features can reference it. So we would create 2 features and deploy them separately:

CommonPageHeadInfrastructure - A feature that includes a custom web control which writes common JavaScript and CSS references into the page head region and a Feature definition which injects the custom control into the AdditionalPageHead delegate control.
CustomWebPartFeature - A feature which encapsulates the functionality of your custom web part.

The web control that you create to write out your common JS and CSS references is a simple control which inherits from Control and writes out the references from within its Render method like so:

public class PageHeadContentControl : Control
{
    protected override void Render(System.Web.UI.HtmlTextWriter writer)
    {
        writer.Write("<script type="text/javascript" src="/_layouts/1033/jquery-1.2.6.min.js"></script>") ;
    }
}

And you would deploy that control into the delegate control using a technique similar to what is shown in this article.

As for your custom web part, you would create it as you normally would and, when creating your Child Controls, register your scripts in the typical manner with the ScriptManager like so:As for your custom web part, you would create it as you normally would and, when creating your Child Controls, register your scripts in the typical manner with the ScriptManager like so:"

var scriptPath = "/_layouts/1033/YourFeatureName/YourScriptFileName.js";
var scriptKey = "YourFeatureNameScriptIncludeKey" ;

var type = this.GetType() ;
var cs = Page.ClientScript;

if (!cs.IsClientScriptIncludeRegistered(type, scriptKey))
{
    cs.RegisterClientScriptInclude(cstype, scriptKey, scriptPath);
}

Of course this means that you must deploy the YourScriptFileName.js file as part of your feature. You can learn about the structure for doing that by reading this article.

The difference between a great developer and an average one is 6 hours

2010-01-19T20:26:00.000-08:00

I explained in my intro post that I was using this blog to immerse myself in the new wave of technologies. In this article I want to shed some more light on what the primary driver behind this was.

Until a couple of years ago I was very comfortable with the current .NET technologies of the day - ASP.NET 2.0, ASP.NET Ajax, WinForms... and a bunch of tools and libraries that shipped within that ecosystem. I would probably go so far as to put myself out as being an expert (whatever that means) at using them to build stuff. Then one by one, new components shipped and I somehow stopped staying at the leading edge of the curve - .NET 3, .NET 4, Silverlight, WPF, and a bunch of agile practices that came with them. The way we build stuff changed too and so new arts and disciplines came to support that - PowerShell, TDD, DI, MS Build and the list goes on.

Let's just say that, during that period, when given a choice between sleeping and staying ahead of the curve... I chose to sleep.

The most important result of all that was not that I cannot use these new technologies, it's more about the level of comfort that I have with them. Probably the thing that I liked best about what I had before was the ability that I had to create a high quality base application in a very short space of time.

This meant that I could fire up Visual Studio, create a blank solution, and in under 6 hours I could have something which:

Was housed in a source control system
Could successfully build as part of a CI process
Used best practices for cross cutting concerns such as configuration, logging and security
Used high quality third party libraries where they were needed to add value
Had a good consistent approach to naming and design guidelines for things such as namespaces and classes

So in under 6 hours, I had an architecture that I was very comfortable with; I knew that I could extend it, deploy it, customize it, and generally do what I liked with it.

At the time I remember lamenting how long it would take other developers to get to a good, consistent base such as this. You might assign a developer a task and when you came back a week or two later they hardly had anything resembling something which had evolved from anything resembling modern software.

Getting to your high quality base should be the sharpest tool in your toolkit. And until you can get to that point, it should be the main focus for your Coding Katas.

So that's the aim for me this year and that's the journey that I hope that this blog will document. Base app, best practices, 6 hours!

How to build a SharePoint WSP package as part of your Continuous Integration process

2010-01-18T16:54:00.001-08:00

Having a continuous, repeatable, and automated build process is necessary when developing software - and developing custom solutions for SharePoint is no exception. In this article I will describe how to automate the creation of SharePoint WSP Solution files as part of your continuous integration build process. The article is laid out in the following sections:

SharePoint Features and Solutions
WSP Builder
Automating the Creation of your WSP Solution

If you are familiar and comfortable with SharePoint features and solutions, feel free to skip forward past the first two sections.

SharePoint Features and Solutions
The way that you develop for SharePoint is via Features. SharePoint Features are a collection of resources and XML configuration information which describes to SharePoint how a certain feature is structured. To provide a concrete example, take a look at the following link to see what goes into creating a Feature:

Anatomy of a SharePoint WSS v3 Feature Project in Visual Studio 2005

That's a fair bit of stuff! At a minimum you are typically looking at:

A Feature.xml file which defines the Feature and specifies the location of assemblies, files, dependencies, or properties that support the Feature.
A signed assembly to be installed in the GAC.
An Elements.xml configuration file which defines the elements that the Feature depends upon

In that article there is also a lot of fluff that is required to create a SharePoint Solution - which is what you need to create to actually deploy and install your Feature into SharePoint. The items that are created in that article which exist solely to create the SharePoint Solution are:

A Manifest.xml file to describe how to package the Solution
A DDF file which defines the structure and contents of the solution package
A custom MSBuild task which runs makecab to process the DDF file and create the .wsp Solution file.

WSPBuilder
WSPBuilder is an open source piece of software which really helps to simplify the task of creating SharePoint Features and Solutions. WSPBuilder consists of an executable program and a Visual Studio plug-in which aid developers when developing SharePoint Features. Here's a link to a page with a tonne of links to useful articles which explain WSPBuilder:

WSPBuilder documentation

When using WSPBuilder you do not need to know about the second grouping of objects that were created in the article which I referenced earlier. Namely, you will not need to create a Manifest.xml, a DDF file, or the custom MSBuild task to call makecab.exe.

When using the WSPBuilder Visual Studio add-in, developers get "right-click" > "add feature" functionality which really does help to bootstrap the development of Features. Not only that, WSPBuilder also helps by simplifying the following common tasks:

Deploying to the GAC
Creating Features
Generating SharePoint Solutions
Debugging

Each of these features can be accessed from within Visual Studio to help speed up the development process when developing SharePoint Features. The interesting part of this is that these services are actually provided by the underlying WSPBuilder.exe application. And this means that we can use this executable during our build to automatically generate SharePoint .wsp solution files as part of our continuous integration process.

Automating the Creation of your WSP Solution
Having used WSPBuilder, your Visual Studio will have a specific structure that conforms to how SharePoint is laid out in the 12 Root, GAC, and 80 Folder. And using the VS add-ins, your developers will have been able to easily create and deploy WSPs on their local development environments. Here is a view of the layout that I would use for a typical SharePoint development project:

When developing I can simply right click the My.SharePoint.FrontEnd project to get WSPBuilder options for deploying, debugging, or re-deploying assemblies to the GAC. However, in order to maintain order and control over the content of WSP files and have them versioned properly, it is best to generate the WSP files that will get pushed through into production automatically as part of your build process.

Creating a WSP package from your build process simply means that you will invoke WSPBuilder.exe as part of your CI build. Therefore the first thing that you must do is to ensure that you have access to WSPBuilder on your build server.

Once you have WSPBuilder on the build server it is a matter of adding some control flow to your build tasks so that it gets called after the Visual Studio project has been built. The control flow for your continuous build process should look similar to this:Creating a WSP package from your build process simply means that you will invoke WSPBuilder.exe as part of your CI build. Therefore the first thing that you must do is to ensure that you have access to WSPBuilder on your build server. Once you have WSPBuilder on the build server it is a matter of adding some control flow to your build tasks so that it gets called after the Visual Studio project has been built. The control flow for your continuous build process should look similar to this:

In my case I am using MS Build to control the flow of the build process, but you could just as easily use NAnt or whatever build scripts you typically use to build your solutions.

Running through the MS Build script logic we see that, at the head of the MSBuild file, I would usually add some properties to provide runtime pointers to where MS Build can find various locations.Running through the MS Build script logic we see that, at the head of the MSBuild file, I would usually add some properties to provide runtime pointers to where MS Build can find various locations.

<PropertyGroup>
<Root>$(MSBuildStartupDirectory)</Root>
<WSPBuilderPath>c:\Program Files (x86)\WSPTools\WSPBuilderExtensions</WSPBuilderPath>
<WSPSolutionPath>$(Root)\$(build_branch_name)\MySharePointProject\My.SharePoint.FrontEnd</WSPSolutionPath>
</PropertyGroup>

In the above snippet I have a property which points to the path of the WSPBuilder executable and another one (WSPSolutionPath) that points to the root path of the the Visual Studio project which has my features in it (typically I have 2 projects in my solution: 1 which has the code assembly and one which only has the feature definitions).

Notice that the WSPSolutionPath is composed by a variable which is passed into my build - $(build_branch_name) - from my continuous integration process. You can hard code this part of the path if you do not need the branch path to be dynamic.

Next up the I use an MS Build task to compile the solution. This builds the assembly which contains the code for WebParts, Workflows, FeatureReceivers, etc and which will ultimately reside in the GACNotice that the WSPSolutionPath is composed by a variable which is passed into my build - $(build_branch_name) - from my continuous integration process. You can hard code this part of the path if you do not need the branch path to be dynamic. Next up the I use an MSBuild task to compile the solution. This builds the assembly which contains the code for WebParts, Workflows, FeatureReceivers, etc and which will ultimately reside in the GAC.

<ItemGroup>
<ProjectToBuild Include="$(Root)\$(build_branch_name)\MySharePointProject\My.SharePoint.sln" />
</ItemGroup>

<MSBuild
Projects="@(ProjectToBuild)"
Targets="Build">

<Output
TaskParameter="TargetOutputs"
ItemName="AssembliesBuiltByChildProjects"
/>
</MSBuild>

Once the solution has been built, I am able to run WSPBuilder to create a WSP package from the compiled artifacts.

<Exec Command='"$(WSPBuilderPath)\WSPBuilder.exe"
-SolutionPath "$(WSPSolutionPath)"
-12Path "$(WSPSolutionPath)\12"
-GACPath "$(WSPSolutionPath)\GAC"'
ContinueOnError='false' 
/>

Notice that the GACPath argument expects any assmblies to be in a GAC folder of the feature project, I used a post-build script in my Core assembly project to copy the assembly across to this folder in my feature project:

xcopy "$(OutputDir)*.dll" "$(SolutionDir)My.SharePoint.FrontEnd\GAC\" /Y /R

The final thing to do is to publish the WSP package to a release server so that it can be deployed into acceptance and production environments…

<MakeDir Directories="$(deploy_path)\$(build_number)" Condition="!Exists('$(deploy_path)\$(build_number)')" />

<ItemGroup>
<WSPSourceFiles Include="$(MSBuildProjectDirectory)\My.SharePoint.FrontEnd.wsp; $(WSPSolutionPath)\Deploy\*" />
</ItemGroup>

<Copy
SourceFiles="@(WSPSourceFiles)"
DestinationFolder="$(deploy_path)\$(build_number)"
/>

As you can see, this is simply a matter of creating a folder and copying the resultant WSP file across. Importantly you will note that when I create the release folder that I include the build number as part of the path. This practice makes it very easy to keep your versioning aligned between source code, release notes, and deployable artifacts.

Updates
Jeremy Thake has uploaded a great screencast which shows how to do this (and more) using TFS which you can view here.

How to fix a “clip duration” error when using the Expression Encoder SDK

2010-01-18T05:01:00.001-08:00

Tonight I was playing around with the latest Expression Encoder SDK in an attempt to build a small video editing tool. What I wanted to do was to take a video and then extract only the highlights from it into a smaller “highlights video”. This is really useful for my side interest as a hockey coach because it would enable me to extract only certain highlights from a hockey match and then send the reduced video around to the players to watch.
So I wrote the following code to get things started:

MediaItem mediaItem = new MediaItem(@"D:\Videos\CANON\20090202\20090202000204.m2ts");

mediaItem.Sources[0].Clips.Add(new Clip(TimeSpan.FromSeconds(49), TimeSpan.FromSeconds(56)));
mediaItem.Sources[0].Clips.Add(new Clip(TimeSpan.FromSeconds(159), TimeSpan.FromSeconds(167)));
mediaItem.Sources[0].Clips.Add(new Clip(TimeSpan.FromSeconds(290), TimeSpan.FromSeconds(297)));

Job job = new Job();
job.MediaItems.Add(mediaItem);

job.OutputDirectory = @"C:\output";
job.Encode();

When I ran it the following exception was thrown:

EncodeErrorException was unhandled
A clip's duration is smaller then the min clip duration 00:00:00.0170000.

Now if you look at the timings that I entered for each of the Clips in the media’s ClipCollection you will clearly see that they are indeed each greater than the duration shown in the error message, so what gives!?

The fix turned out to be quite simple – and obvious really – but I thought that I’d post the solution because there weren’t any clean hits that came up when I did my own search on the error message. To fix, you simple call Clear() on the ClipCollection before you start adding your own Clip’s to it like so:

MediaItem mediaItem = new MediaItem(@"D:\Videos\CANON\20090202\20090202000204.m2ts");
mediaItem.Sources[0].Clips.Clear();

...

Job job = new Job();
job.MediaItems.Add(mediaItem);

job.OutputDirectory = @"C:\output";
job.Encode();

WaveBot integration with Blog Posts

2010-01-12T13:58:00.000-08:00

I'm using this page to try out the blogbot@appspot.com Wave bot. Using that bot, you can embed your Google Wave's into public web pages. If you have a Wave account, you should see an embedded Wave below.

My initial impressions on embedded Waves is that, whilst they are an interesting idea, currently the limited feature-set of Wave means that you might as well simply direct people to your Wave via its public URL. The reasons for this thinking are that:

Your Waves have to be public to ensure that visitors can see the content - and without the ability to assign roles to participants of a Wave, this means that everybody will have contributor access.
There is no ability to have draft and published versions of content. So if all of the content that you are sharing is "published", what's the benefit of pushing it through to your blog? You might as well use the in-built content publishing features of your blog software.

Positive aspects to using Google Wave as a "multimedia wikichat" content source are:

Google Wave has a kick-ass strength in content versioning, providing users with the ability to replay the evolution of content.
It allows you to embed rich content into your content. This includes the ability to embed Wave Gadgets so that you could include things such as charts or surveys as well as the ability to use Wave Bots that you could include to automate repetitive tasks or to augment content by providing additional services - such as Dictionary and Thesaurus services for example.

Further reading:

Using Drag and Drop in a Silverlight 4 Application

2010-01-06T03:28:00.001-08:00

Today I was working through the excellent Image Browser Lab lab to teach myself some of the newer features in Silverlight 4. If you haven’t tried that lab as yet, you should, it shows you how to build a really cool Image browsing application which supports moving, resizing, and rotating images on a canvas. It also shows you how to enable the scenario where a user can drag pictures from their hard drive and into the Silverlight application. Very cool stuff! Here’s a picture of the page in action:

As you will notice, in this tutorial, it shows you how to add the yellow drag handles that you see on the middle photo so that you can resize and move the images around. And as also mentioned, you can drag images in off of your own hard drive. If you have 5 minutes to spare, here is a link to a video by Jesse Liberty which shows how simple it is to get Drag and Drop working.

What happens if you cannot get Drag and Drop to work in your Silverlight application?

OK, call me a simpleton, but this got me today and so I’m going to put it out there to hopefully save some other poor sucker the hour it took me to work out what was going on. Emboldened after having worked through this exercise, I decided to implement some Drag and Drop goodness in one of my own applications. I added the few lines of mark up and code that are required to get things working, ran it up with F5, and nothing! Zip! Drag and Drop was not working for me.

The long of the short of it is that I had started the instance of Visual Studio in elevated mode. What this meant was that Windows was protecting me by not allowing me to drag files from my Windows Explorer instance (which was not elevated) into my IE process (which was).

So after about an hour of scratching my head, it turned out to be a simple fix. And now I have drag and drop functionality in my own application!

New Year's Resolution #1 - Buy a Kindle

2010-01-05T13:53:00.000-08:00

For the last couple of years I've allowed my interest in technology to take a back seat while I spent more time with Uni studies and gaining knowledge and experience as a hockey coach. This year however I've promised that I will immerse myself in the latest rounds of technology - hence this blog.

A big part of my life with technology has always been the software that I create - and this only gets better with the current wave - but I've not really been much of a gadget guy. This is all changing though and now that we have Kindle in Australia I've decided to invest in one.

This was a big decision for me and I thought long and hard about whether to get a Kindle or to purchase a Netbook. The attraction of having a device of this type was mostly so that I can extend my reading - especially of technical articles - to the 2 hour daily bus commute. And the decision point between a Kindle and a Netbook really came down to the fact that you can do a lot more on a Netbook than you can on a Kindle. For example, if I was reading a PDF tutorial on how to use PowerShell, then using a Netbook I could easily fire up PowerShell and try some of that stuff right there and then.

The thing that swayed me away from buying a Netbook in the end was mostly that the Netbook market is still such a changing landscape and, to get the Netbook that I wanted I would probably have ended up spending around $700 anyways.

So the final decision was: spend $300 on a Kindle and solve my immediate reading need problem, then tackle a small form-factor PC later in the year.

Oh yeah, and with the $AUD doing so well against the $USD... how could I afford not to buy one!

Walkthrough using Autofac as your IoC Container in an ASP.NET MVC application

2010-01-01T18:36:00.001-08:00

Note: The Autofac assemblies that I used to write this sample are part of the latest Beta version – which is a bit of a moving target. I know that the most recent build of that major version has changed since I wrote this stuff, so you might want to keep an eye on Nick’s blog to learn about any changes that are occurring in the codebase. One significant change you will need to know about if you are planning to work through this article is the change that he has made to how ASP.NET MVC Controllers are registered with the Container. You can read about that change here.

If you are building properly structured software where you have correctly implemented separation of concerns (SOC) then wiring up dependencies for classes starts to become quite an exercise. Here's an example from the a great series of articles on the topic of IoC and DI that I recommend you read to learn more about the topic which shows how verbose and complex things can become:

IFileDownloader downloader = new HttpFileDownloader(); 
ITitleScraper scraper = new StringParsingTitleScraper(); 
HtmlTitleRetriever retriever = new HtmlTitleRetriever(downloader, scraper);

Commonly when you use simple dependency injection in this manner you find that some services are reliant upon many other components and their construction becomes very messy. You can imagine what this starts to look like when you have lots of type registration and dependency injection to do right across your application!

In this article I am going to get you up and running using Autofac as the IoC container that will handle all of the lifetime management of your dependencies and do the dependency injection for you. To get the ball rolling, go ahead and create a new solution called SimpleAutofac:

I like to structure my source code so that the main branch of the application lives within a folder named trunk and that my external dependencies are referenced from a folder which lives above that. Create a folder for your Autofac dependencies, grab the latest build of Autofac and add its binaries to the folder you just created.

You should get the following list of assemblies added to your Autofac dependencies folder

Next add a reference from your SimpleAutofac project in Visual Studio to the Autofac.dll, Autofac.Configuration.dll and the Autofac.Integration.Web.dll assemblies. Having done that, we can wire up Autofac into our web application and start registering types. The first thing is to take advantage of the Autofac.Integration.Web.dll which contains the AutofacControllerFactory class that can be used at the ControllerBuilder’s current ControllerFactory.

private static IContainerProvider _containerProvider;

protected void Application_Start()
{
     RegisterRoutes(RouteTable.Routes);

     var containerBuilder = new ContainerBuilder();
     containerBuilder.RegisterModule(new AutofacControllerModule(Assembly.GetExecutingAssembly()));
     _containerProvider = new ContainerProvider(containerBuilder.Build());

     ControllerBuilder.Current.SetControllerFactory(new AutofacControllerFactory(_containerProvider));
}

We need to make a minor alteration to the web.config file to include an Http Module that Autofac will use to dispose

<httpModules>
     <add name="ContainerDisposal" type="Autofac.Integration.Web.ContainerDisposalModule, Autofac.Integration.Web"/>
</httpModules>

The ContainerDisposal module requires us to implement the Autofac IContainerProviderAccessor interface on our Application class, which, in-turn, mandates that we expose the ContainerProvider as a property on the class. Go ahead and add the following lines of code to your Application class:

public IContainerProvider ContainerProvider
{
     get { return _containerProvider; }
}

protected void Application_EndRequest(object sender, EventArgs e)
{
     ContainerProvider.EndRequestLifetime();
}

You can read more about the Autofac MVC integration on the project's Wiki page. That's all there is to it, press F5 and your application should now run.

Note that the Controllers are now being served by our Autofac IoC container and so we can now demonstrate the advantages that we get from this by going and adding some dependencies to our Controller classes and see that they get injected at runtime for us.

Create a new interface called IMessageProvider in the Models folder of the web project. We will use this as a dependency that we’ll then pass to controller classes:

namespace SimpleAutofac.Models
{
     public interface IMessageProvider
     {
          string EchoMessage(string message);
     }
}

And now create a concrete instance of that interface that we will use in our application. For the sake of giving meaning to the demo, let's name our class SqlMessageProvider and imagine that this class is responsible for retrieving messages from a SQL Server database. Our class will look like this:

namespace SimpleAutofac.Models
{
     public class SqlMessageProvider : IMessageProvider
     {
          public string EchoMessage(string message)
          {
               return string.Format("{0} returned from message provider.", message);
          }
     }
}

Next we will wire up our implementation with our container so that it knows what class to return within our web application whenever an IMessageProvider is required. Go back to the Application class in Global.asax.cs and add the following registration instruction to our container builder:

containerBuilder.RegisterType<SqlMessageProvider>().As<IMessageProvider>();

Finally, go to the HomeController class and create a constructor which takes an IMessageProvider instance and then change the code in the Index action handler so that it gets its message from the IMessageProvider service as opposed to being a raw string:

namespace SimpleAutofac.Controllers
{
     public class HomeController : Controller
     {
          private readonly IMessageProvider messageProvider;

          public HomeController(IMessageProvider messageProvider)
          {
               this.messageProvider = messageProvider;
          }

          public ActionResult Index()
          {
               ViewData["Message"] = this.messageProvider.EchoMessage("Welcome to ASP.NET MVC!");
               return View();
          }
          
          public ActionResult About()
          {
               return View();
          }
     }
}

Now press F5 to run the application and you should see that our Autofac container did indeed handle the type registration for us and it successfully injected the correct IMessageProvider instance into our HomeController class.

The last thing that I want to show is how to pass a connection string to our SqlMessageProvider instance whenever it is instantiated.

Go back to our SqlMessageProvider class and add a constructor that takes a connection string as an argument. Change the EchoMessage so that it shows us which connection our message came from:

private string connectionString = "";

public SqlMessageProvider(string connectionString)
{
     this.connectionString = connectionString;
}

public string EchoMessage(string message)
{
     return string.Format("{0} returned from {1} provider.", 
          message, 
          this.connectionString);
}

Now go back to the Application class and change the IMessageProvider registration so that it takes a specific instance that we've already pre-configured with our connection string information

var connectionString = "DarrensSqlServer";

var containerBuilder = new ContainerBuilder();
containerBuilder.Register(c => new SqlMessageProvider(connectionString)).As<IMessageProvider>();
containerBuilder.RegisterModule(new AutofacControllerModule(Assembly.GetExecutingAssembly()));

_containerProvider = new ContainerProvider(containerBuilder.Build());

ControllerBuilder.Current.SetControllerFactory(new AutofacControllerFactory(_containerProvider));

How to create Areas in ASP.NET MVC

2009-12-31T20:15:00.001-08:00

In ASP.NET MVC we can use the concept of Areas to segregate different functional areas of development into separate projects. This segregation can help make our code easier to maintain - especially among a team of developers because it means that a new programmer potentially has less code to wade through when they come to maintain a specific feature.

In this blog post we will look at how to create an ASP.NET MVC Area and wire it up into our application. To get things started, create a new Visual Studio ASP.NET MVC2 project named AreasDemo

When your project opens up you can see the standard, base ASP.NET MVC project template files are included.

Next we are going to add a new area that will provide the functionality for managing and viewing Favorites. To get things started, add a new ASP.NET MVC2 project to the solution and name it FavoritesArea

Remove all of the content from the FavoritesArea project but leave the Controllers and Models folders

The only things that will live in the *Area projects will be code - Controllers, Routing configuration, Models, and ViewModels. Let's go ahead and create a simple C# class called Favorite which will encapsulate a domain object for our Favorites functional area.

namespace FavoritesArea.Models
{
    public class Favorite
    {
        public string Title { get; set; }
        public int Rating { get; set; }
    }
}

For this example, we will be creating a single View for our Favorites functional area called Index; the Index view will be the default view for the Favorites functional area and will simply show a list of favorites. Add a Controller class to the FavoritesArea project which looks like so:

public class FavoritesController : Controller
{
    public ActionResult Index()
    {
        var favorites = GetFavorites();
        return View(favorites);
    }


    List<Favorite> GetFavorites()
    {
        return new List<Favorite> 
        {
            new Favorite { Title = "First Favorite", Rating = 3 },
            new Favorite { Title = "Second Favorite", Rating = 5 },
            new Favorite { Title = "Third Favorite", Rating = 3 },
        };
    }

}

Notice that the Index method of this controller class simply returns a hard-coded list of Favorite domain objects.

Next we will add routing information for the Area so that the ASP.NET MVC runtime knows how to access the controller and view for our Favorites function. From within the FavoritesArea project create a new class named Routes - the name is not important but make sure to inherit from the ASP.NET MVC AreaRegistration base class). When you have your Routes class add the following code to it

public class Routes : AreaRegistration 
{                                           
   public override void RegisterArea(AreaRegistrationContext context)    
   {        
       context.MapRoute(
           "favorites_default", 
           "Favorites/{controller}/{action}/{id}",                             
           new {
               controller = "Favorites", 
               action = "Index", 
               id = ""
           }
           );    
   }
   
   public override string AreaName
   {        
       get { return "Favorites"; }    
   }
}

The 3 things to take notice of here are:

We've derived from AreaRegistration

We've overridden the RegisterArea method to add our own routing configuration

We've overridden the AreaName property to provide the key name for our Area

Add a reference to the FavoritesArea assembly from the AreaDemo project:

In the Application class of the AreasDemo project, add a line of code which invokes Area registration [1]:

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    RegisterRoutes(RouteTable.Routes);
}

In the AreasDemo project, create a strongly-typed view named Index and then select your View data class. In our case, that will be the Favorite domain class that we created earlier. The view should be added to a folder named Favorites which will live underneath the Views folder. Therefore the full path to the view file in your Visual Studio project will be /Views/Favorites/Index.aspx. You cannot see it in the following image (because the Types dropdown is covering it) but you should also select List as the View Content type as this will automatically display our Favorites list for us.

The last thing that we need to do to provide a way for users to navigate to our Favorites Index page. To do this simply open up the Site.master file and include an additional navigation node for our view. Notice that you will need to use a different overload of the ActionLink method which lets us specify an area to use.

<div id="menucontainer">

    <ul id="menu">              
        <li><%= Html.ActionLink("Home", "Index", "Home")%></li>
        <li><%= Html.ActionLink("About", "About", "Home")%></li>
        <li><%= Html.ActionLink("Favorites", "Index", "Favorites", new { area = "Favorites" }, null) %></li>
    </ul>

</div>

With these changes made the only thing that remains is to press F5 to run the application and navigate to the Favorites page:

The last thing that you might like to do – for aesthetics – is to place your Area projects into a Solution Folder names Areas. This again helps maintainability as it makes the structure of the solution much clearer to any potential developers:

There you have it! The code for our Favorites function is now isolated from the main chunk of code which is required to bootstrap the web application. This will make it easier to maintain, review and test because code can be worked on in a more focused manner.

[1] It is important to make the call to AreaRegistration.RegisterAllAreas() prior to calling RegisterRoutes - ASP.NET MVC 2 and why Dynamic Area is not supported.

2010Wave Intro Post

2009-12-31T14:55:00.000-08:00

Prior to 2009 I was a very regular blogger.

My first blog started in January 2002 and was hosted on the original DotNetWeblogs service - which later became http://weblogs.asp.net. After that I moved my blogging activity over to http://MarkItUp.com which was (and still is) hosted on some CMS software that I developed whilst writing my book on ASP.NET 2.0 Web Parts back in 2005. After that I turned my attention towards Windows Live and moved across to a Live Spaces blog.

Last year was the first year that I didn't blog since 2001.

This year I have renewed enthusiasm for blogging because I'm geniunely excited by all of the new technologies that I've been playing with. Those technologies include: ASP.NET MVC, Visual Studio 2010, Windows 7, Windows Azure, Windows Mobile, HTML5, Continuous Integration, Software Patterns, DI Containers, Automated Testing, Automated Build Systems, Managing the Release of Software, SharePoint 2010, PowerShell, MSBuild and a host of others.

During the day I'm currently on a 12 month contract with a local Adelaide-based organization where I work as a SharePoint administrator and developer. During this work I'm lucky enough to be considered as a senior member of the team and have been given quite a free license to help improve the way that we develop software. And that's what I'll be blogging about.

During the year I will be diving further into these technologies and plan to post my learnings to this blog. I'm not sure how often I will be posting but I think that I can aim to post about 3-4 quality posts per week on average.

If you would like to follow me you can expect that my posts will lead you on a path towards having more control over your build and release processes for your own software development. Hopefully this will lead to the development of many recipes for bootstrapping development and automating for both on-premise and cloud-based applications.