Collabshow.com

Five important things to learn from the announcement this morning around the SharePoint branding and positioning.

1. SharePoint Server’s new name will be SharePoint Server 2010.  The word Office will be dropped, but the integration story only gets better.

2. MOSS as an acronym will no longer reflect the naming as Office will no longer be in the acronym and we shouldn’t use MSS as an acronym because of Microsoft Search Server.

3. WSS is still around, no new announcement around it’s naming.  Don’t make any inferences around it as a result of the naming with SharePoint Server 2010.

4. Office as a brand will no longer refer to server applications, but more clearly refer to client applications including the Office (the client), Office Web Applications and the mobile version of Office.

5. Exchange 2010 will ship this year outside of the Office launch and a beta is currently available.

More details on the SharePoint Team blog from Tom Rizzo

More details on the Chris Caposella Exchange 2010 announcement, and Office which will now refer to client applications link from the SharePoint Team blog.

While these days I would suffice to tweet a simple URL and say hey new details about Office System/MOSS SP2 announcement and leave a good link to the source in a tiny URL like http://tinyurl.com/apr28sp2 and call it good, but unfortunately I’m still not seeing enough penetration to leave good content like this to not be explained in better detail in a post.  I’d even skip it and leave it to a tweet if the message was on the SharePoint Team blog, the place where we’ve all grown accustomed to seeing these type of announcements.

Now I’m seeing what looks like really good details on Microsoft Update blog with details on the OSE blog.

Microsoft Update Blog: http://blogs.technet.com/mu

Office Sustained Engineering Blog: http://blogs.technet.com/office_sustained_engineering

"Last October, we announced the upcoming release of the 2^nd service pack for the 2007 Microsoft Office System and the 2007 Microsoft Office. Today, we’re happy to provide both a formal release date, and more details on what you should expect to see in SP2."

This section in the post relate particularly to the SharePoint Products and Technologies:

"Changes that impact the server products

Windows SharePoint Services 3.0 SP2 and Microsoft Office SharePoint Server SP2 include fixes and enhancements designed to improve performance, availability, and stability in your server farms. SP2 provides the groundwork for future major releases of SharePoint Products and Technologies.

· An STSADM command line that scans your server farm to establish whether it is ready for upgrade to the next version of SharePoint and provides feedback and best practice recommendations on your current environment.

· SP2 offers support for standards-based documents formats and compatibility with a broader range of Web browsers.

· Substantial improvements to Forms-based authentication.

Windows Server 2008 SP2 and Windows Server R2 will be supported on their release."

I do like the language while vague in that it addresses availability and stability issues as well since it has some info on upgrade readiness, I see that it will be required for upgrade.  So it will be best to include it in your planning.  As always you need to test it first.

I do fully expect to see more details around the SP2 release and more official information from the SharePoint team around it’s release, but do find some valuable information around the documentation which is quite relevant to how we can expect to see details from this team on KBs and service packs.  Pay particular attention to the fact that they have *heard* your feedback and are making significant changes… (I quote from the MU blog)

1. Gone are the days of the long-winded or too sparse knowledge base articles that do little to describe what’s included in the actual service pack

2. More user-friendly and informative KB’s

3. Technical information still exists, but it has been pulled from the main KB articles and now will live on TechNet

4. Spreadsheet listing individual bugs that were fixed across all of our products

(close quote)

More details later when we see links to the documentation, KB, and the actual bits.  They say the Apr 28th.  Interesting to see a date.  We’ll see.

First stop Paris. The press interviews and meeting up with Erol and the other MVPs was cool.  Exploring the city was great.  Unfortunately my free day, Monday the catacombs was closed.  Next time. I wanted to speak to the France MOSS Club, but didn’t work out.  Next time.

Cologne Germany– the “Joel Oleson Interview by Michael Greth” podcast was fun.  He’s got some great high tech gadgets.  If it’s not good, you can blame lack of sleep.

The User Group in Cologne was the first meeting for that group.  We had a great turnout of about 40.  You can download the presentation here: 10 Steps to Successful Deployment Presentation.

In Amsterdam the SharePoint Experts Day with Mike Watson, Robin Meure, Daniel McPherson, and myself plus Waldek and Matthias was loads of fun.  Plus that night we had a SharePint. The live twitter feed of #sp020 projected on the wall was a great effect.

Decks:

• 10 Steps to Successful Deployment – Joel
• Daniel McPherson’s SharePoint and Social Media – All demos (I think some of what he showed is on zevenseas.com blogs)
• SharePoint Fundamentals back to basics (Information Architecture and Physical Toplogies) – Joel and Robin
• SharePoint Backup Demystified (to be posted) – Mike Watson

In London, the Keynote kick off included the Monty Python and the Holy Grail sketch about the killer rabbit.  I likened the deployment approach of many companies to those that run into it because it looks so simple and essentially get their heads taken off.  Sure a bit drastic, but I think you get the point.

As well the "Stocks" were used in the analogy around the IT challenge of working with the business with your hands and head not free.

Also new to this particular session was a deeper approach to staged deployment and brief discussion around policies with SharePoint Designer being free.

The main points of the slides can be taken from 10 Steps to Successful Deployment Presentation, but the localized version with Mark of zevenseas in the stocks and Mike Watson and Robin Meure looking the wrong way in the cross walk also known as zebra crossing.  This deck will be added when I get a reliable connection. 🙂

It was a great event, and as I’ve said on Twitter.  Steve Smith pulled off an incredible event.  Maybe the best SharePoint conference ever in Europe (including the MS one) and definitely in the top handful world wide.  Very well organized and excellent speakers. Not to play down the San Diego one which was superb. (Ben you did great.)

I love the dynamics of twitter and how it plays into conferences these days.  Mark Miller’s live twitter feed on endusersharepoint.com of the event is sure to be something that will stick.  Was funny to see a row of SharePoint speakers all twittering during and between sessions.

Thursday nights user group session here in Cairo (125 registered!!!) for the Egypt SharePoint User Group in the MS office will include some local flavors as well, but the gist of the discussion will be around the 10 Steps to Successful deployment which I haven’t yet delivered in Egypt :).

This morning I was in a meeting with a bunch of developers and they asked me… “What is the best tool for Unit Testing SharePoint?” I talked to them about patterns and practices SharePoint  (Thanks Francis Cheung, your User Group session at Puget Sound SPUG paid off.)

I then went to http://www.SharePointDevWiki.com right in the meeting to look at the list of tools and resources and found a post on SharePoint Development with Unit Testing.  They were asking alternatives to WSPBuilder and I knew the spdevwiki had a comparison of solution package development tools including a killer side by side chart of WSPBuilder with STSDev and VSeWSS.  The resources were extensive and the name brand resources were great!  The people in the meeting had heard of the tools, but were looking for more.  Next I went to SharePointReviews.com to see if any third parties had any dev/testing tools, but I didn’t see a development category.  The deployment category didn’t fit.  Twitter was running through my brain.  It prompted me to say let me ask my twitter buddies… (even though my friends in the states were asleep.)

I posted this question to Twitter in the middle of my customer meeting and had 80% of theses responses by the end of the meeting.  The customer was super impressed by the quick quality responses.

JoelOleson – @jthake what is the best unit testing tool for SharePoint?

@AndrewWoody @harbars What do you use for Unit Testing SharePoint?

andrewwoody – @joeloleson @harbars either MSTest (built in to VS) or NUnit as framework with Typemock Isolator to mock out SharePoint

mahoekst – @joeloleson Check out: http://www.codeplex.com/spg they have used unit testing in version 2 of the solution (including mocks) very nice.

rmaclean – @joeloleson TFS – white paper on it: http://tinyurl.com/tfssharepoint

zimmergren – @joeloleson @AndrewWoody I use NUnit myself, and the Resharper has some cool testing utilities to help out.

JoelOleson – @AndrewWoody Awesome. It’s nice to see TDD coming to SharePoint, but we need more. Experience with Typemock, Isolator?

andrewwoody – @joeloleson yes lots of experience with Typemock Isolator see Unit Testing posts here http://www.21apps.com/agile/

JoelOleson – @zimmergren @AndrewWoody cool. Thanks for sharing. I’m filling in a customers here in Germany with this rich info.

harbars – @joeloleson @AndrewWoody NUnit is my preferred option. DevPartner also good …, MSTest is good also, lifestyle choice!

What an incredibly rich interactive world wide discussion in the course of an hour… and who knows… it may not be over!

What did I learn:

• Microsoft has a tool built into Visual Studio called MSTest as well as SharePoint TDD Patterns and Practices guidance and best practices at MSDN as well as v2 in development on http://www.codeplex.com/spg
• There’s a whitepaper for TFS on Visual Studio Team Tester  for creating automated builds
• Popular TDD Tools of .NET Developers use tools such as Resharper (by Jetbrains) – a Visual Studio add in, including a beta 4.5 that’s currently available for download. And NUnit an open source C# project for Unit Testing.  (Andrew Connell has written his own SharePoint baseclass for NUnit, and Spence wants to see more SPDev teams using NUnit.
• TypeMock Isolator is the new tool of choice for Andrew Woodward who has done a series of blogs on TDD and Unit testing and SharePoint.
• Compuware has a full suite called DevPartner Studio which compliments Visual Studio.

We also discussed some things I’d learned from twitter from a search on “#MIX09 and SharePoint.”

@katriendg VS2010 will have full debugging and development experience for SharePoint, yeah some people will be happy! #mix09

Blog Resources

Snippet from SPDevwiki on SharePoint Development with Unit Testing (from Top posts) please Contribute! Thanks Jeremy Thake, @spdevwiki the Wiki Rocks!

Microsoft – SharePoint Guidance – Unit Testing
Microsoft has published an article on Unit Testing in SharePoint as part of the SharePoint Guidance

Andrew Woodward – 21Apps
Andrew has a great set of articles on Unit Testing in SharePoint Development including 2 excellent White Papers.

Francis K. Cheung – Unit Testing SharePoint 2007 Applications
Francis discusses the approaches and also the reasons why SharePoint Unit Testing is so difficult.

SPTDD: SharePoint and Test Driven Development, Part One by Eric Shupps

Spencer Harbar – "Test Driven" SharePoint Development

I just finished reading a write up of a SharePoint Designer Good Bad Ugly as “SharePoint Designer a definite Maybe” by Mark Rackley.  I think he makes some good points early in the document, but many of the conclusions which come across biased to structured deployments I don’t agree with as they relate to composite commodity and collaboration environments.  Some of the statements especially his conclusions are just too wide sweeping and come across as scare tactics.  Don’t let this come across as higher ground… I make the same mistake some times in my attempts to keep people from deploying custom site definitions due to their impact at upgrade, but that’s a different discussion.  Often it takes a good post to get the community stirred up to flush out the details…  I applaud Mark on making a stand.  Let me break down where I disagree with Mark’s conclusions. (Mark’s Conclusion Arguments as originally written are outlined in quotes below)

Argument 1: “Keep SharePoint Designer FAR away from your Production Servers”

SharePoint Designer can really be used in two what I’ll call “editing modes” 1) remote with portability (which supports dev, test, prod) and 2) In Place

1) Design your masterpage and your web parts to work with portability.  Design your themes, skins (ask Heather Waterman what a skin is), layouts, styles, CSS, Masterpages, and other CMS assets and then export and upload to the master page gallery and various galleries (MOSS only).  You might consider starting with the minimal masterpage.  With WSS 3.0 the only way to apply a master page without custom solution is with SharePoint Designer.  Hence if you want style applied in a quick way beyond the out of the box themes, you’ll turn to SharePoint designer.

For web parts you would simply design your web part and it’s connections for example using the dataview or dataform web part which essentially are not accessible in IE.  Complexity goes way up to try to do the same thing with Visual Studio.  You can connect to databases, web services, XML, RSS, and on and on.  The filtering, conditional formatting, and rich forms, otherwise extremely complicated to write yourself are extremely intuitive.  Once you like the way it looks you simply use the web UI to export the .DWP file which is a self contained web part file. 

2) In place editing and design has a place.  Let’s start with MOST SharePoint Deployments are collaboration environments.  These commodity applications run primarily out of the box and the business requr Consider the composite applications designed by the power users in the business.  Without designer, the development team becomes the bottleneck.  I’m not suggesting that SharePoint designer be installed on every desktop by any means, but it is important to understand the positive impact that Designer can have on building rapid applications.  While I wouldn’t encourage people to have free reign, I do see a place for designer in most deployments.

Understanding the out of the box webparts is extremely important to understand how the tools fit.

Content Editor web part – drop in essentially any client side code including javascript and flash includes to make magic happen.  Looking at Jquery you’d think there was nothing you couldn’t do with the content editor web part.

Content Query Web part – amazing when you see how powerful this webpart can be in pulling in list data from across the site collection all right through the browser!

Dataview/form webpart – The Swiss army knife of webparts which are NOT accessible via the browser alone.  With Designer this webpart can pull in data from various datasources and make your site become an application.  Not only integrate with your lists and integrate workflows, but much much more.  Take the Dustin Miller 3 hour tour, or listen and watch any of his building composite applications or dataview sessions.  In an hour he’ll blow your mind.  He does make Designer sing.  Not just Dustin, but Asif, WoodyW, and a ton of other people and who in your company can you turn into a SharePoint Designer super star?  It’s not just what you can do, it’s how much time you can save building applications in a commodity environment without having to add server assemblies, that’s the real key to winning over the server admins.

Given the tradeoff of server assemblies or someone using designer to create a dataview or create a workflow, almost all would choose the educated trusted power user with SharePoint Designer.

The argument about the impact of Unghosting is legacy and performance impact is unvalidated

Forget about the page being unghosted.  The page isn’t unghosted unless you actually edit the page itself.  In WSS 2.0 this wasn’t the case, but now only the particular items that are edited are customized or unghosted.  It’s important to understand when you edit an object whether a web part, a layout, or CSS.  It does store that in the content database.  If you avoid editing the page itself, you’ll find that the editing concepts work best when applied with a masterpage and no page unghosting is necessary at all.  The DWP file or webparts would get added into the content database no matter what tool you use to create them.

I challenge someone to actually do the performance test.  In my tests even in WSS 2.0 I found that unghosted pages were FASTER, than their ghosted untouched counterparts.  Why?  If you look at the query it was checking the database first then hitting the page on disk.  So comparing the two the unghosted one was a few milliseconds faster on a GET.  Upgrade in my mind is the reason not to touch the pages, so don’t touch the pages.  Use Masterpages, and use designer to work with workflows and webparts and we don’t even have to talk about ughosted pages.  The reset to site definition feature was introduced during the upgrade and remains available.  Let me reiterate, I recommend keeping the pages inheriting from the site definition.

Argument 2: “Don’t give your end users access to SharePoint Designer ESPECIALLY if you have multiple Web Front Ends”

SharePoint stores the files in a common content database.  This statement is unfounded.  There’s really no difference between 5 WFEs and 1 WFE as far as editing is concerned.  I do recommend sticky sessions, but despite the number of web front ends, the data is still stored in one content database, and any webparts, workflows, etc.. are only ran and processed from a single box at a time.

Argument 3: “Unless you truly understand SharePoint Designer and what it’s doing under the covers, DON’T TOUCH IT.”

This type of scare tactic may be efficient to an end user that hasn’t had the necessary training, but Designer has a legacy bad rap that has carried over.  Much of which today is unfounded and for which training and workarounds address most of the issues.  It is a powerful tool, I do highly recommend training and sandbox usage.  Touch it as much as you can in a non production sandbox site, that may actually even be sitting on the production environment, just not your production portal.  Collaboration and Project sites are the ideal place to train your power users and designers on the effective use of SharePoint Designer. 

Argument 4: “If you are aware of it’s limitations and keep them in mind, it is a wonderful tool.”

Too little too late.  You already lost your audience.  Some good points in the article, but it comes across as scare tactics rather than stating some workarounds and facts.

Conclusion:

1. Don’t deploy SharePoint on every desktop.  You should still work with a group of designers, and power users which create masterpages, CSS, dataviews/dataforms, and limited simple workflows.

2. Most of the assets around design can be created remotely to allow staged deployment.  Don’t worry about the impact of unghosting to performance when using Designer to create workflows, webparts, masterpages, etc….  even pages don’t create a measurable impact to performance, but I recommend  NOT editing the pages themselves with Designer (in most environments where you’d be concerned).  That design for the WCM site can still be designed with Designer and achieve portability!  It isn’t only an inplace tool.

3. Education/Training plus policies is the key.  You can decide who can do what.  Create a sandbox and help your power users get educated.  Not every user needs or has to know.  It is handy even for your trusted site administrators to learn how to use designer.  It’s the ONLY way to add a master page to WSS without deploying code, and the ONLY way to create dataviews and dataforms without code. While I hate to say Governance will solve this (alone it won’t)  problem for you, essentially setting out policies and roles and responsibilities along with enforcement, you’ll be much better off than using scare tactics.  People need to understand what is ok, and what’s not ok.

4. It is faster to create an RAD application with SharePoint Designer than it is with Visual Studio.  It’s not always the right answer to jump from the browser based solutions to visual studio.  Maybe that is the right answer with your WCM or .COM environment, but those one off little apps that with a tweak here or there…. Designer goes a long way to help biz dev scale. 

5. Create a Sandbox (demo/test UAT for trusted power users) for collaboration environments – if you don’t want people to do anything until they know what they’re doing, you need a sandbox.  You need an environment where people can learn, and they can see what happens if… What’s the worst that could happen?  Well, lets run that in the demo environment and see.

Totally ok with blocking access to SharePoint Designer (from SPD team blog) until you figure out your composite application plan around this… Few moving parts in the beginning is essential to understand what’s in the box.  SharePoint is a lights on experience!  Don’t forget you have backup/restore.  Do you have a quick way to restore a site or site collection?  Figure that out before turning on SPD or even Site Collection Admin access to ANYONE. 

<update!>

SharePoint Designer is now Free check it out in a Sandbox!

Q&A on License Change

</update>

@ferringer just produced a custom site def on codeplex.com that blocks SPD.  I don’t know what I think.  Not too excited about this being a site def.  Would much prefer a solution, but at least there’s now an effort underway to simplify a farm wide change to manage access by SPD.  I imagine in the future a solution or a web app policy that would allow you to manage the group that has access to the various SPD features at a more granular layer across the web app, then opts in at the site layer.