LightSwitch... Or Not.

As Microsoft often does, it took a great tool in LightSwitch, which had gained a pretty hard-core following of power users, citizen developers, business analysts, and even some seasoned developers, and completely threw it into the ditch, without any further, substantive explanation, just like it did for Silverlight.

How do we know this change is permanent?

1) They made no (I repeat, NO!) improvements to LightSwitch in the Visual Studio 2015 release candidate. It's a small wonder they included it at all.

2) Andy Kung left Microsoft.

3) Beth Massi (or whatever her married name is now) is also no longer doing LightSwitch content.

4) Jay Schmelzer so eloquently danced around the topic better than any Democrat politician could ever do when it was brought up during a podcast. Pertinent comments start around the 5:00 mark in the podcast.

So... what's next? I wrote previously that learning skills like JavaScript, JQuery, and CSS would be vital for survival in the SharePoint world. This assertion still resounds true today.  Another stack that I have just recently started learning is asp.net MVC, used in conjunction with Entity Framework. This development toolset, like LightSwitch (though in a much different way than LightSwitch), handles much of the data source connectivity for you and it JUST... WORKS. You can still work with fully relational datasets, created either by code-first or by scaffolding via Entity Framework. Code can be generated for you while still customizing the business logic, but you will still need to know HTML. HTML helpers and RAZOR syntax help shorten the code required to render the output.

Microsoft Virtual Academy has some great resources on MVC and Entity Framework featuring Christopher Harrison. Just search for MVC and Entity Framework.

The biggest disadvantage is the difficulty of implementing file / database relationships, which was very easy in LightSwitch, though "Mike" shows how to do both database and file system storage and relationships here. Interaction with SharePoint lists and libraries is exclusively through javascript and is still tedious enough that I wouldn't recommend it in good conscience to non-developers.

Takeaway for today - LightSwitch isn't dead, but it's future looks grim at best and appears to be marked for deletion. I suspect the same will occur with Access 2013 Web Apps. If you're trying to do anything with some Microsoft tool that isn't part of the .net core stack, don't count on it being there in two years.

Today's Worst Mis-Titled Job Description Award Goes To...

The Pew Charitable Trusts!

https://www.linkedin.com/jobs2/view/17632795?trk=job_view_similar_jobs

From their "SharePoint Administrator" job post...

"Position Overview:
The SharePoint Administrator will be responsible maintaining the organization’s SharePoint platform and several custom applications developed on the platform. In addition the Administrator will manage changes and enhancements to a handful of other custom .Net applications. "

"Design, implement, test and deploy  Share Point custom features  and packages, 2007/2010/2013 solutions programmed in ASP.NET/C# with particular attention to user interface design."

"Demonstrated experience  in Microsoft .NET development technologies, including Visual Studio 2012, C#, ASP.NET,  HTML, CSS, JavaScript,  LINQ, WCF, Silverlight, AJAX,CAML,XML,  XSLT, REST, and DOM "

DEVELOPER!  Not Administrator.

Sorry, but this is unacceptable for the recruiter or the hiring manager who labeled this as a SharePoint Administrator position when it is clearly a SharePoint Developer position.

Don't let this happen to you.
 

You Don't Have to Be a Weatherman To Know Which Way the Wind Blows.

Which direction is the wind blowing in terms of SharePoint?

Answer: JavaScript/JQuery (read "function") and CSS (Cascading Style Sheets, read "look and feel"), if you want to do anything above and beyond out-of-the-box with SharePoint 2010 and 2013.

With every new release of SharePoint, Microsoft is allowing SharePoint to be more flexible, but at the cost of becoming less user-friendly for non-developers. The newest release of SharePoint, SharePoint 2013, makes heavier use of "apps" that can be customized through script.

SharePoint Designer 2013 has taken away its Design view, and thrown the form customizations over the fence to InfoPath 2013.  InfoPath 2013 has some limitations, and so the most effective way to change the function of your SharePoint sites is to use JavaScript and JQuery. This means that even a Site Collection Administrator would be well-served to have knowledge of JavaScript, JQuery, and CSS.

Fortunately, there are many good books available on both subjects, and even books focused on using JavaScript, JQuery, and CSS within the context of SharePoint 2013. I would highly recommend also getting a book on the use of InfoPath 2013 and even Office 365, Microsoft's cloud-hosted SharePoint solution.

For an all-in-one book, I recommend "Pro SharePoint 2013 Branding and Responsive Web Development". "JavaScript and JQuery: The Missing Manual" is also a good read if you're starting anew with any type of development/programming and has good cross-references within.

Best of luck, and happy coding!

Definitions #2: SharePoint Administrator

The SharePoint Administrator position, the role I currently fill, is quite possibly the most vague of them all, and this fact alone becomes even more true (or distorted, however you want to look at it) with the newer versions of SharePoint (2010, 2013) and cloud-hosted, multi-tenant SharePoint instances. However, the most common definition of this position is responsibility for any infrastructure components that make up a SharePoint farm (however, this usually excludes responsibility for the overall network/LAN/domain it is attached to). This includes standing up a new SharePoint farm, supporting existing farms, and migrating data from an old farm to a new one.

Farms can be hosted entirely on a single server (they all start out as a single server, or with the only component separated being the SQL back-end), or they can be expanded to include the following: 1-to-many SharePoint Web Front End (WFE) servers, typically an application server (which can include a search function), an indexing server for search, and the SQL Server back-end.

The SharePoint admin is also responsible for databases that store configuration, content, and access lists/user profiles, though the databases typically reside on a larger, shared database server that is under the control and responsibility of a SQL Server database administrator, who usually administers backups of the SharePoint-dependent databases.

The SharePoint admin sees to it that the servers and databases are backed up on a frequent basis, and will be responsible for disaster recovery (DR) should the SharePoint farm crash.

The admin is also responsible for configuring URL's through SharePoint Web Apps and through alternate access mappings, if necessary. Each Web App can be configured for consuming different services, such as search, Excel services, etc. and ensures that those who need access to these services have them.

The admin is responsible for configuring and monitoring search crawls, a key component of SharePoint that users rely upon heavily.

Another admin responsibility is creating new site collections. The newly-created site collections are usually handed over to site collection administrators, who are who are often mis-recruited for SharePoint administrator positions. However, it should be noted that in some cases, the SharePoint admin will also serve as a SharePoint Site Collection Administrator as I do in my current position. But please, please do not confuse these two roles, as they are often separate within the enterprise. If a position you are recruiting for is not a farm admin and is at the Site Collection level only (no server responsibility), please make sure your position is appropriately titled as a Site Collection Administrator and not as a SharePoint Administrator or Developer.  Many candidates will use this in their search criteria when seeking new positions. I will more clearly define the Site Collection Administrator role in a different article.

Another dimension to add is the fact that cloud tenant hosting providers are now coming to the forefront. This adds another middleware layer to the picture. The SharePoint Administrator could be the infrastructure person at the cloud hosting provider, or they could be the tenant company's person who runs the Web Apps. The person will oversee user licenses, Site Collections, storage quotas and usage, as well as resource quotas and usage. This person could be generically (and appropriately) titled as a SharePoint Administrator, though a hiring manager needs to be VERY SPECIFIC about the nature of the environment and which layer(s) the hired candidate will be responsible for when brought on-board.

What the candidate needs to have:

1. Ideally, the candidate should have a solid background (read "degree") in computer sciences, and be Microsoft Certified (MCTS or higher) in the technology he or she is being hired for if they do not have much on-the-job experience prior to the position you are hiring them for. Certifications aren't 100% necessary, but they do demonstrate at least a good portion of the working knowledge necessary for the position.

2. The candidate should be knowledgable on Windows Server operating systems and experience examining server logs for troubleshooting purposes.

3. The candidate needs some working knowledge of SQL server and associated roles. This is necessary for properly securing the SharePoint farm.

4. The candidate should have a solid, working understanding of SharePoint architecture, service architecture, and network concepts.

And, pay close attention to this one...

5. The candidate should have some knowledge of how SharePoint is utilized by the end users. Here is where a unique opportunity may present itself to you in the form of an experienced Site Collection Administrator. An experienced Site Collection Administrator can be up-trained to become a SharePoint farm admin, and you, as the recruiter can use the person's lack of farm admin experience as a bargaining chip to discount their salary in exchange for giving the person valuable experience as a farm admin. That said, the salary will still need to be greater than what they were making as a Site Collection Admin, and the person will need to be sent to a week of training for SharePoint Administration and possibly Windows Server Administration.

6. Experience in programming isn't necessary and is only minimally helpful for a pure SharePoint Admin position... that is why you have developers, though, a developer can be of assistance in administration tasks at times.

7. While not necessary at first, a solid understanding of command-line tools STSADM (for SharePoint 2007) and PowerShell 2.0 (for SharePoint 2010 and beyond) should be learned and maintained.

Your Recruiting Take-Away: Even though SharePoint Administators and SharePoint Developers may have overlapping skills, please make sure that a) the two roles are NOT CONFUSED with each other, b) the job descriptions are accurate about what the position actually entails, and c) that the resumes are actually read prior to matching the resumes to the positions.

Recommended Resume Search Criteria: "SharePoint Administrator" + farm + WFE + "SQL Server" (optional) + "MCTS: SharePoint" (optional) + stsadm + PowerShell