The SPC 2010 event seems to have been taking place ages ago, in actual fact it was only last Monday and Tuesday. Anyway I was too busy to report on this straight away, trying to finish two stressful projects at the same time this week.In short, it was a good one. Not ground breaking, but useful because it filled some essential gaps in my knowledge and it was good to take a timeout to focus on SharePoint 2010. The running theme of every session was, “the real product has yet come out, don’t come crying back if it turned out to be different”. My guess is, looking at the SharePoint 2010 Beta, that there shouldn’t be that many surprises.
As a developer, I tried not to focus too much on the developer aspects, thinking that this will come to pass anyway. I went to an intro session and session on unit testing Sharepoint by Peli de Halleux. Here at Aviva Solutions all internal projects use TDD where possible and useful. Peli showed how he is able to make SharePoint development unit testable by using Pex and Moles. Moles allows making test stubs of any .NET code and that way might even make the file system testable. As a showcase Peli and his team made a comple Mole-d SharePoint. Recommended!
Development with Visual Studio 2010 will be fundamentally different, no more manifest.xml, feature.xml and copy/paste of GUIDS. The question is now if this is a good thing in all respects, because a session by Serge van den Oever and Mirjam van Olst showed that VS 2010 flattens out all components of your solution into separate features. Large solutions, like complete site definitions, end up completely unstructured. New opportunities for WSPbuilder!
However, the major surprise for me was the shift of focus for development to SharePoint Designer. SharePoint designer now allows you to save changes as reusable solutions, WSPs. When imported into VS2010, these could be good starting points for your development. Do not expect too much yet, the WSP import in VS 2010 seems to be messy and broken for now. Microsoft has made Designer more powerful to cater for Power Users. In absence of Power Users I think developers should not be shy and use Designer to quickly get from A to B. If the WSP import works that is. Designer failed in sessions on more than one occasion during the event.
When trying to sum up the remaining goodies of this event, Claims based Authentication is worth mentioning. Or this is at least something that caught my attention. How to finally get rid of the annoying logon popup when opening Office documents. Also a new way to cross process boundaries without having to elevate to administrator rights. Spencer Harbar pointed out the highlights, but could not really show it hands on unfortunately. Otherwise the way SharePoint 2010 will be more scalable and less restrictive in implementations showed up throughout all sessions.
On Saturday February 27th, the Dutch DotNED user group, Aviva Solutions and Oosterkamp Training & Consultancy will be hosting a full day session on software quality. The session will be mostly held by myself, but I will be accompanied by my colleagues Jonne Kats and Peter Hesseling.
Unfortunately, due to popular demand, the session was fully booked within 24 hours. But now, we are seriously considering repeating the session in the beginning of April. So if you’re still interested, go to the DotNED registration page and click the link at the bottom of the page to send us an email.
Storyotypes are stereotypes for user stories that can help to define the right scope for your user stories. You can read more about these in the article Using Storyotypes to Split Bloated XP Stories and these slides. Team Foundation Server 2010 includes a new VSTS for Agile process template closely following the Scrum practices and supporting a user story WIT. However, Storyotypes are not supported, so I decided to change the standard work item template to add that field.
You can download the modified WIT template from here. You can install them into an existing project using the witadmin.exe tool (available if you open a Visual Studio 2010 Command Prompt), but it’s much easier to use the TFS Power Tools.
As part of my many assignments, I’m compiling a bunch of best practices into a set of development guidelines for bootstrapping our internal projects using TFS. I’ve decided to share these with the community so that others may benefit from it as well. Beware that these practices are not new nor in any way invented by myself. I'm merely trying to get some good resources together in a nice compact format.
So what are my goals?
- To provide insight into the benefits of applying well known best practices on software development projects.
- To provide examples of applying those practices on new and ongoing projects and explain how to gain the most of out them.
- To help you jumpstart a new project or professionalize running projects.
And what do you gain?
The goal of these posts is to end up with a set of development practices that provide the following benefits:
- Allows you to more quickly and accurately assess the impact of new requirements.
- Promotes building well designed software that allows changing functionality with lesser risks (even during a running project).
- Promotes a consistent code-base that solves similar problems using similar solutions, everywhere.
- Strives for a functionally consistent software system. For instance, ensuring that date fields look the same all over the application).
- Attempts to prevent code duplication so that you never have to make changes at multiple locations if you change a particular piece of behavior or logic.
- Eases the effort for deploying a new release by removing as many human actions as possible.
- Provides traceability on where a particular piece of functionality has been realized technically.
- Improves the developer experience when working on an existing or shared code-base (e.g. readability, purpose and goal of a block of code).
- Provides a safety net that reduces and possible prevents the chance of running into regression problems.
- Attempts to prevent common mistakes or misinterpretations by introducing common rules and recommendations.
- Strives to a situation where each and every member of the team is aware of the project’s affairs.
- Promotes any endeavors that improve the self-education and self-organization of teams.