I have been renewed as SharePoint MVP!

Got good news today – I just have been re-awarded as SharePoint MVP again! Hurray!!!

It”s my 6th year of holding this status (4 years as .NET/C# and 2 yeas as SharePoint MVP). I’m really happy that my passion about technology and influence to others is still recognized by community. Promising to keep this pace for the next years as well.

And additional announcement, recently I became un-official Tech Reviewer of PacktPub Publisher (http://www.packtpub.com/) reviewing the forthcoming SharePoint books.

Comments

Presenting on Australia SharePoint Conference, June 16-17, Sydney

This year is quite tough for me, in terms of presentations. It’s the 5th event which I attend as the speaker, and now it’s the the Australian SharePoint Event of the year – about 60 speakers and 1000 delegates. This will ROCK!

“After a very successful New Zealand SharePoint conference in 2009, this year sees the conference extended to include Australia! This will be THE Australian SharePoint Conference to learn about both SharePoint 2007 and SharePoint 2010. Expert local and international speakers will present on topics that will help you understand and succeed with your SharePoint implementations, and add real world value to your organisation and businesses.”

I have two sessions:

  • “Real World Business problems with PerformancePoint Services in SharePoint 2010” about Balance Scorecards
  • Vendor’s session about the SharePoint 2010 success stories

image

Comments

SharePoint 2010 and Silverlight – lessons learned

In these days, I’m working on the several SharePoint projects where we utilize Silverlight for the better user experience. The decision was driven by the specific requirements and not by “taste to try something new” . In one project, we are using Silverlight to build Dashboard, in another, we are using SharePoint Foundation 2010 (SPF) for public internet site, and we need to provide customers the forms to input request tickets. That second project became quite challenging for us in terms of providing custom forms in short period of time.

The problems with SPF 2010 with forms design is that SPF 2010 doesn’t support InfoPath – the simplest and fast way to provide the custom user-input form in SharePoint. We researched different alternatives, as hosting InfoPath in ASPX pages, developing XSLT forms, or ASPX layout pages,  but all of them were either too complex or didn’t meet the requirements to integrate with external Web Services and Database easily. The only one solution which could provide quick and nice UI + simplified integration with Web Services is Silverlight. So, that’s where our story begins :,,)

Despite of native Silverlight support in SharePoint 2010 there are a lot of hidden issues how to develop, debug and test SL. In this post I will share the challenges I experienced with Silverlight in SharePoint 2010 and solutions to help others to cut the corners.

1) Development

With SharePoint 2010 you can use Silverlight 3.5 or Silverlight 4.0. We had no dependency on .NET Framework version so picked the decent 4.0 version. You need to install Silverlight 4.0 Tools, SDL, WCF

When you create a new Silverlight project you will be asked if you want to host it in the external Web Application. In all articles I read they recommend not to host in external webApp and build and deploy directly to SharePoint via Features . It’s up to you if you choose that way, but for me deploying to SharePoint and testing form there is very annoying and time consuming process (it builds WSP, deploys WSP, resets IIS, SharePoint page recompiles), so I prefer to develop and deploy to the simple aspx page (TypeMock rocks in this case) and then deploy to SharePoint when necessary. The development is much faster in this case.

2) Web Services

To communicate with external systems you need to make calls ether directly from Silverlight or using Web Services. Take into account that Silverlight is the client technology and all calls will be made from the client”s browser (similar to making call to external system via javascript – JSON and REST models is what you need). It’s ok to make calls to SharePoint Object Model (Lists, Sites and etc) directly from Silverlight, but working with Database will be quire expensive in terms of loading your server with requests. In this case you need to consider creating the Web Service and call database from there.

Silverlight has limited support of SOAP services, so, consider using WCF Services, due to better support of serialized types.

3) Debugging

SharePoint Silverlight debugging in Visual Studio is not supported by default, due to Script debugging settings turned on. It means that you can’t set breakpoints and step into your code in VS if you are not deploying Silverlight controls via feature. Such functionality is supported when you host your SL project in external Web Project (another reason not to host in SharePoint during development)

To provide the SharePoint SL debugging capabilities you need to package your .XAP file in SharePoint Project (in VS) and deploy as a Feature. Such approach allows to enable “Siverlight Debugging” instead of client one, and step into your .cs code from Visual Studio 2010. This options is set from the VS IDE. Navigate to the SharePoint project properties –> SharePoint Tab –> click “Enable Silverlight Debugging”. That checkbox will activate the Remote Debugger and you will be able to debug SL hosted in SharePoint using Visual Studio 2010 (but you need to configure the Remote Debugger first, opening the firewall ports. On the 64bit windows you need to configure the x86 version of msvsmon.exe because the Visual Studio is x86)

I found really strange behaviour that debugging doesn’t work if you don’t have another instance of the the SL page opened in browser. Seems there is a bug resolving assemblies, because when you start debugging your solution might be re-builded , IIS restarts, thus remote debugger can’t attach to the right assemblies. To fix it just open another tab in browser, navigate to page with SL control you are debugging and only after that start debugging which will open the second instance of that page.

4) Deployment

You can deploy your Silverlight controls (XAP files) either externally or in SharePoint. Refer to this step-by-step instruction. Take into account that if you host Web Service outside Silverlight you need to supply ClientAccessPolicy.xml and crossdomain.xml for the cross-domain calls. Create and put these files into the root folder of SharePoint (inetpubwwwrootwssVirtualDirectories<your app port>) or into the root of the external hosing(depending the way you host SL and services)

To deploy the XAP files to SharePoint they recommend to use the following locations: SharePoint Library, “_catalogs/masterpage/”, “_layouts” or custom locations. I found that the standard SharePoint 2010 controls are stored into the “_layouts/clientbin/” folder. This folder is designed to be a standard place for hosting assemblies that are used in Silverlight. Take into account that all files deployed to SharePoint are ghostable (even you don’t specify the type), and you won’t see them on physical drive – use the SharePoint Designer to check the the file presence in the folder you deployed it.

Few words about storing the XAP in Lists. It’s might be appropriate in some scenarios, but I found that the default deployment doesn’t render the deployed file in the list 🙂 Yep it’s true, your list will be empty, nothing there, but if you type the complete URL to the file in the browser you will be prompted to download it. It looks like that the file has been actually deployed, but not exposed via the List (albeit list is created and rendered)

Web Services deployment is very easy, because Visual Studio can create the deployment package for you (right mouse click on the WCF project and select “Package”). VS will archive the solution and create the CMD script to deploy the solution to IIS. I would recommend to make additional step further and to use Web Deploy for this

————————-

That’s all for what I found to be tricky in developing Silverlight controls for the SharePoint 2010. Will update this post with further findings. If you have something to add or to share on this topic please add comments below.

Comments (7)

Protected: The cost of daily paperwork routine

This content is password protected. To view it please enter your password below:

Enter your password to view comments.

Save the tree – use eForms (statistics)

Reading the “8 Factors to Consider in Creating an Information Management Strategy eBook and Presentations” found a few interesting data points to consider:

  • If the U.S. cut its office paper use by roughly 10 percent or 540,000 tons, greenhouse gas emissions
    would fall by 1.6 million tons — equivalent to taking 280,000 cars off the road for a year.
  • There are over 4 trillion paper documents in the U.S., growing at a rate of 22% per year.
  • For 56% of organizations, the volume of paper records is increasing.
  • The average office worker uses 10,000 sheets of copy paper each year and wastes about 1,410 of these pages.
  • With the average cost of each wasted page being  about six cents, a company with 500 employees
    could be spending $42,000 per year on wasted prints.

That can be a good justification of moving to eForms

Comments

How to patent the algorithms

In my career I have a few years of experience in Finance and Trading industry and recently I decided to look back at that industry again and define the new goals in my career :,,). In these days, in spare time, I’m working on the trading “pet project” and came out with one interesting conception of finance modelling and prediction (an algorithm actually) that I’m seriously considering to patent.

The patenting was quite new for me, especially what relates to patenting of the algorithms :), and after a few weeks of investigation I’ve found out the following stuff that I reckon will be interesting for everybody.

1) Definition

An algorithm must possess five essential features – definition, finiteness, input/ output, effectiveness and order

  • The feature of definition relates to the certainty of description of an algorithm’s steps
  • The feature of finiteness relates to the need for an algorithm to specify a route to a final step in all possible cases to be handled by it
  • The need for an algorithm to have input and output follows from the fact that it is designed to be useful.
  • An algorithm is said to be effective when if each of the steps are simple enough to be performed manually, even if such performance would be tedious and inefficient
  • An algorithm would be less than serviceable if its steps were described in no particular order, even if an experienced operator could work out the correct sequence for him or herself.

http://www.austlii.edu.au/au/journals/SydLRev/1998/23.html

2) Process of Patenting – WHAT

Before patenting you need to find if the similar patent already exists. There is a patent database that allows to search across all existing patents http://www.uspto.gov/patents/process/search/index.jsp. The goal of this step is to find if your patent already exists, and if not –what’s the most related one

3) Process of Patenting – HOW

 

I hope that I will have enough time to finish my algorithm this year (after I learn this bloody MatLab) and apply for the provisional patent.

Comments

Protected: Search – recall, precision and ranking

This content is password protected. To view it please enter your password below:

Enter your password to view comments.

SharePoint Farm Design checklist

Recently found a checklist for the SharePoint Farm design template I described previously , which I reckon quite good to be used across my projects

  • An infrastructure design to support your solution
  • A detailed document that describes how you will implement the solution
  • A plan for testing and validating the solution
  • A site and solution architecture
  • An understanding of the monitoring and sustained engineering requirements to support the solution
  • A record of how the solution will be governed
  • An understanding of how the solution will be messaged to the consumer to drive adoption of the solution

Comments (3)

How to select the right Key Performance Indicators

In these days I’m working on how Information Architecture is designed for the Dashboard/Scorecards solutions – what information artefacts are used and how they are organized. While skimmed different resources on this topic I found one interesting statement by David Parmenter, in his book “Key Performance Indicators:Developing,Implementing,and Using Winning KPIs” that I reckon is worth to share

David uses 12 steps for identifying the artefacts that are used as Key Performance Indicators (KPI) for Scorecard/Dashboard. Process covers major success BUSINESS DRIVEN factors, such as stakeholder buy-in, organic growth, and iteration instead of “get it right the first time.”

1. Senior management team commitment
2. Establishing a “winning KPI” project team
3. Establishing a “just do it” culture and process
4. Setting up a holistic KPI development strategy
5. Marketing a KPI system to all employees
6. Identifying organization-wide critical success factors
7. Recording performance measures in a database
8. Selecting team-level performance measures
9. Selecting organizational winning KPIs
10. Developing the reporting frameworks at all levels
11. Facilitating the use of winning KPIs
12. Refining KPIs to maintain their relevance

The most common mistake when people select the irrelevant KPIs that don’t following the strategy maps. Strategy maps are designed to link a company’s high-level goals to the KPIs that measure how the company is performing on the measures that drive the business. In case of KPI not matching the business you are tracking the irrelevant stuff

Comments

“SharePoint Solution Design” document template

I published several posts regarding document templates for the SharePoint projects previously, but they were related to the specific sections of the projects.

Recently I had discussion with colleagues about the structure of “Solution Design” document and logical inconsistency we have seen all time.

Almost each project you are starting should be based on the “Solution Design” that describes and justifies what is going to be implemented. I”ve seen tons of documents for C++, and .NET projects in the Financing, Marketing, Industrial and others areas, that were organized quite good logically. By “quite good” I mean that you structure the document from the broad and general terms, introducing what do we have, moving toward the specialization and physical artefacts. In two words it should be “out-in” approach.

SharePoint brings a lot of new conceptions and artefacts that either don’t exist or are not taken into account for the Solution Design that came from other areas.  For example, “content types”, “capacity planning”, “farm architecture”. Reviewing several “Solution Design” documents for SharePoint projects last 6 months I saw a lot of inconsistency of how information is addressed and structured – people mess up the physical artefacts with logical ones, structure flows without any logic and smooth transitions. For example,in section of “Solution architecture” they put together logical design and network infrastructure. It’s ok for a Web application where all servers have almost the same role,but in SharePoint the logical and physical design are two different things and they don’t match each other 1-to-1. Logical designs is based on metadata and taxonomies, when physical design is dictated by “usage patterns” and data volumes. You will have absolutely two different physical designs creating system for enterprise to manage documents online and for the digital agency with the terabytes of media files – conceptually you have the same metadata but physical organization will be different due to usage approach.

I have some thought for a while about creating the “SharePoint Solution Design” template that is properly aligned – starting from the broad terms, which describe what the system is about, specializing the taxonomies and content prior to the physical organization.  Such document should aim to targets:

  • Lead the reader logically to the physical design, describing what artefacts the system manipulates and how they are used. So, when we come to the physical organization the reader will have their own vision of system in mind.
  • No hops between unrelated sections (like logical and physical architecture), because physical design should be justified previously.

After more that hour of analysis, brainstorming a discussion we came out with the following structure that I want to publish here and hear your feedbacks.

Update 1 (Feb 12, 2009): added the section about “Information Artefacts”. This is important to understand what are the information that system uses, ignoring the technology aspect. Is it about managind the word documents and having multilevel approval, or is it the financial company who creates the dashboard for the stock marker. This is important to be described earlier to have understanding about usage patterns, because it will affect the Information Architecture.

  1. OVERVIEW
    1. Background
    2. Document Purpose
  2. INFORMATION ARTEFACTS
    1. Artefacts overview (the list of information pieces the system operates)
    2. Data Flow (how data is moving across the system0
    3. Usage cases (different scenarios of using information artefacts)
    4. Artefacts Managing (describing how different products – sharepoint, drupal and others) can manage artefactts)
  3. INFORMATION ARCHITECTURE
    1. Site Structure
      1. Site Maps
    2. User Interface and Branding
      1. Wireframes
      2. Navigation
      3. Branding
    3. Content Types, Columns and Lists
      1. Content Types
      2. Columns
      3. List
  4. LOGICAL ARCHITECTURE
    1. Feature Mapping (which features of the SharePoint  are gonna be used and for which purposes)
    2. Farm Logical Architecture
    3. Web Applications
      1. Zones
      2. Managed Paths
    4. Site Collections and Content Databases
    5. Shared Services
    6. User Profile and Properties
    7. Search
    8. Audiences
    9. Service Accounts
  5. CAPACITY PLANNING
  6. PHYSICAL ARCHITECTURE
    1. Server Topology
    2. Network Infrastructure
    3. Storage Requirements
      1. Web Front-End Servers
      2. Application Server
      3. SQL Server

Comments (16)

« Previous Page« Previous entries Next entries »Next Page »