Almost two months ago, I was asked to lead up a new team within Wolters Kluwer Tax & Accounting. This new team is dubbed the “Always On” engineering team and will be our first team of Site Reliability Engineers. We are seeking the best and brightest engineers, development managers, and product managers whom are eager for a new opportunity to help dramatically improve the resiliency and performance of our flagship product, CCH Axcess.

Each enterprise has many languages they use to solve their technology problems. C# and Java are the predominate languages used in most enterprises. However, I have noticed a distinct difference between these two types of developers. Enterprises that use Microsoft Active Directory have very little problem with authentication for applications developed using C# (or Visual Basic). NTLM and Kerberos are natively supported for authentication by all .Net applications. Authentication looks like the following (C#):

I have experienced many legacy solutions which closely depend on the SharePoint Server Side Object Model (SSOM). This was the only option for being able to manage your SharePoint 2007 and 2010 farms. You may have read on some of my past blog posts, code written against the SharePoint SSOM is extremely difficult to unit test without Microsoft Fakes or writing a facade. As a result, I have deepened my familiarity with the SharePoint 2013 REST APIs. They are much more strategic, especially when planning for the possibility of moving to SharePoint Online / Office 365.

One of my most recent interactions with several of my colleagues has been over best practices within software development. More specifically, the idea of static classes, static methods, and helper classes. It was a healthy debate with different view points. Some believe that static methods are perfectly fine for development. Others feel that helper classes provide unity to certain practices such as database access. Generally, however, I believe static and helper classes are an anti-pattern and lead to less maintainable code. This post is an expression of why I believe this to be the case. None of the code samples are actual snippets on real projects. They are paraphrased instances of practices I’ve seen on a myriad of past projects.

Let’s talk about something I really don’t like: e-mail. Let me clarify this by saying I loathe e-mails on team projects. Why? Persistence. Conversations via e-mail have this perception they will be “found” at a later time, but the proposed value is rarely so useful. Furthermore, new team members or collaborators rarely ever get that context, because it’s buried in another person’s e-mail. This is my approach to how teams should communicate to ensure longevity of this critically important information. I’m a huge fan of the e-mail brevity challenge. The idea is simple: keep your e-mails short. 140 characters short. What this limits you to do is huge. Do you think you can have technical design discussions with 140 characters? What about researching technical support problems? How about product feature ideas? Clarifying how your team came to the conclusion to disable a feature due to security constraints? You might be able to do this in a bunch of 140 character e-mails, but that’s hardly a good use of time.

The way My Sites are created in SharePoint 2013 is vastly different from SharePoint 2010, but for good reason. I won’t go into the details of how it’s changed, as Wictor Wilen has done an excellent job of this already in his blog post SharePoint 2013: Personal Site Instantiation Queues and Bad Throughput. I encountered problems with a new development workstation not setting up My Sites for users appropriately - blocking us from testing our solution, which was dependent upon a user having a My Site. In looking online (and in Wictor’s blog post), everything was pointing to checking the following three timer jobs:

As I was writing an app using the new SharePoint 2013 app model the other day, I ran into an issue when I was trying to follow a site automatically through JavaScript:

I’m in the process of migrating my customer from SharePoint 2010 to SharePoint 2013. In their SharePoint 2010 environment, they were still using classic-mode authentication, but are switching to claims-based authentication in SharePoint 2013.

I have just completed building my first SharePoint 2013 application. I came across the error message Sorry, only tenant administrators can add or give access to this app. when trying to deploy the application to my site. This happened regardless if I was deploying using a SharePoint development site or after installing the solution in the app catalog.

I’ve recently switched from using Subversion directly to using git svn to allow me to use a git workflow, but interact with a subversion repository. It works great, except when I needed to interactive rebase… When moving this workflow into my customer’s environment, they require I specify a JIRA ticket on each commit to the repo. I had forgot to do that for the first few commits, which looked like this: