Planning to be a Sharepoint Developer? Rethink, become an Office Developer

Today (or yesterday!)

Sharepoint (in the good ol’ days) used to be about building bulky custom full trust farm based solutions and deploying them to the GAC on the farm servers to achieve even the most basic of customizations. Developers usually would have resumes flooded with C#, VB, ASP.NET, SQL and Oracle expertise. Most of us have even invested many years and had ups and downs along the way which have brought us to our current state of comfort with the complex world that is Sharepoint.

Those days (although still valid in some companies) are soon becoming a thing of the past. 

With Office 365, Sharepoint Online and days of the cloud environment upon us, Developers now should be focused on client side technologies with the new App model and client side development using CSOM, REST API’s. No matter for how long developers maintain their stand to remain with server side technologies, Microsoft (and businesses, eventually) will make the push to Online and client side development.

Next Steps

With the new App model, Microsoft is clearly pointing developers to the way forward for Sharepoint as a whole. Let’s face it, major problem with Sharepoint environments (except for the rare incidents with pesky CU or Service Pack bugs), is because of poorly designed code or customization. 

Microsoft is proud of Sharepoint as a product and is just gearing up the environment to make it more robust for end users by allowing for developers to interact through the app model exclusively.

The good news is that the App model and client side API’s are just growing. The Sharepoint (Office) community as a whole needs to grow with it and (and as with early versions of Sharepoint, I am sure)  will build a strong practice with tools and helpful API’s to make developing and deploying with the App Model a much easier and smoother experience.

Invest time with JavaScript API for Office, the new OAuth support, REST end points, and expanded JavaScript CSOM for SharePoint and learn to adapt with App Model. The technology not only bridges Sharepoint but applies also to Office apps. The App model does not limit you by the technology or platform and allows for you to use your expertise (or lack of) and build apps without having to worry about learning complicated Server side Model.

Office app developer can extend this knowledge beyond Sharepoint and start developing for Office applications and the Office Store.

Check out Office 365 Developer Patterns and Practices on GitHub.

https://github.com/OfficeDev/PnP

Here are ten tips from Jeremy Thake's blog on things to look for when moving to the Sharepoint App Model:

http://www.jeremythake.com/2014/09/top-10-tips-for-preparing-for-the-shift-to-the-sharepoint-app-model/

Should I be changing my blog name to Office Daily? hmm!

Web application creation does not create IIS site

Quick post today based on an experience with newly created web applications not displaying. I had created a new web application/root site collection on a Sharepoint 2010 Farm server (2 WFE, 2 App servers) and noticed that the web application successfully got created but on going to the web app URL nothing was being displayed (404). I checked the IIS and noticed that the IIS website was not created.
Here are the steps I used to troubleshoot:
1.    Checked ULS logs: No issues found or recorded
2.    Checked the Timer service: Timer Service was up and running on all servers, restarted anyway to be on safe side.
3.    When that did not help, restarted IIS on all servers. That also did not help.
4.    Started checking all services in CA --> Manage Services on the server.
Checked and found that “Microsoft Sharepoint Foundation Web Application” service was stopped on the app server.
Restarted the service and VOILA! Web application and IIS website started getting created.

Client Side Scripting: Get Sharepoint User Profile properties using jQuery

In Sharepoint 2010 environment, I recently had a request to fetch the UserProfile object using client side scripting on a Sharepoint page. Immediately, I started looking for any methods exposed within the jQuery library to do so. A jQuery script library called SPServices is available which abstracts SharePoint's Web Services and makes them easier to use.

SPServices: http://spservices.codeplex.com/

Specifically they have examples on how to retrieve UserProfile properties using SPServices library function GetUserProfileByName.

http://spservices.codeplex.com/wikipage?title=GetUserProfileByName

For my own implementation, I modularized the code for fetching the user profile object into a separate javascript file as below:

function returnUserProfile()
{
var user = {};
$().SPServices({
operation: "GetUserProfileByName",
async: false,
AccountName: $().SPServices.SPGetCurrentUser(),
completefunc: function (xData, Status) {
$(xData.responseText).SPFilterNode("PropertyData").each(function() {
              user[$(this).find("Name").text()] = $(this).find("Value").text();
           });        
    }
    });
return user;
}

I can quickly surface the function call in any CEWP/HTML form web part and read the user profile property.

Example: (Redirect based on Users Office location)

var user = {};
var url = document.url + "/sites/region/";
user = returnUserProfile();
window.location.replace(url+user.Office); 

A complete list of all properties available under UserProfile is below:

http://technet.microsoft.com/en-us/library/hh147510%28v=office.15%29.aspx


Hope this helps!

Developers vs. Operations

I recently came across an interesting article (“Revisitingwhat is DevOps” by Carlos Sanchez) on role of DevOps and the constant balance between the developers and operations team within the project to make it successful. Throughout the article I could perfectly relate to what the essence of the article was i.e. the need to have a balance between both teams to achieve the best that the software/platform has to offer.

From my own personal experiences working on multiple projects, I have always felt the need to address as part of any project, setting up channels of communication and constant interaction between the developers/architects and the operations team. On too many occasions, the development team will come up with innovative and challenging approaches to only find out that the limitation to get it implemented is the hesitation/apprehension of the operations in setting up the infrastructure or service required to facilitate the approach. After many discussions and arguments, this would finally boil down to a stalemate with teams not making any ground and having to revert back to existing solution or platform to resolve the problem.

I am not saying that the problem here lies with the Operations. They have their own reservations (and rightly so) when implementing changes which could possibly hamper or disrupt services and make their lives a living hell just so that the development team can rejoice in their two minutes of fame. There are plenty of other constraints as well that the Operations team has to look at like lifecycle management and financial limitations when reviewing the changes.

However, that being said it is ultimately a working relationship between the two which can ultimately make or break a project.

For further reading and looking at Sharepoint Governance, I recommend Steve Goodyear’s books on Practical Sharepoint Governance and Sharepoint Enterprise Content Management.

Microsoft Sharepoint Certification – Benefits for Employer and Employee

Microsoft has always been a proponent of technology certification through its MCP (Microsoft Certified Professional) program and MSDN Learning portals with guidance to plan and prepare for their certifications based on technology of your choice.

However, employers and employees alike are often at crossroads of whether the Microsoft certifications are actually beneficial for either of them. Here are some points in favor of both parties:

For employer’s, the perks lie in achieving certain competencies within the organization (yes, since 2010 Microsoft made key changes to the partner program that Gold or Microsoft Certified Partner labels did not apply to the whole company per say but to specific competencies within the organization) and demonstrating that they are dedicated towards maintain those competencies. The requirements to demonstrate these competencies among others are to show that your workforce meets the requirements for number of certified individuals with those competencies.

                                   

Specific to Sharepoint, Microsoft has consolidated the process of becoming a Microsoft Sharepoint Partner. They are divided into 2 groups namely System Integrators and Independent Software vendors.

System Integrators – Helping customers realize full business value of their Sharepoint investment including social; Enterprise Search and surfacing LOB (line of business) data in Sharepoint.

Independent System Validators – providing solutions leveraging cloud based platform for business intelligence, advanced visualization, project portfolio and business process management.

The new Collaboration and Content competency merges the previous competencies: Portals and Collaboration, Content Management and Search. Further reading on the competencies and how to achieve partner status here.

For employee’s, the perks are in achieving certification and Microsoft accreditation which can help them gain better visibility within the organization as well as the industry. Nowadays, it has relatively harder for companies to screen and assess competencies which are ever changing and rapidly progressing (compare MOSS to 2013). This gives certifications more weightage when assessing talent and required skill set based on requirements.

Below is the certification plan for MCSD (Sharepoint Developer) in 2013:

(Images and content copyright of Microsoft, the views expressed here are mine)