The Blog of Chris Weldon

Wood Badge, Scouting, and Leadership

2021-09-13T00:17:00+00:00

In August 2021, I had the privilege of travelling to Philmont Scout Ranch in Cimarron, NM to attend Wood Badge 133. The Wood Badge experience was nothing short of exemplary. I’ve been a scout leader for 5 years and leader and manager of software teams for over 13 years, and I’ve never been to anything quite as comprehensive and well-thought as this leadership training. What was the price for this 5 day training? It’s a steal at under $700!

The purpose of this blog post is to talk a little about leadership, a little about Scouting, and a lot about Wood Badge.

What is leadership?

If you ask this question to 5 different people, you’ll likely get 7 different answers. What leadership means is very subjective, but leadership is not just being a manager or a CEO. Everyone is able to lead, regardless of the position they hold in their company (or in scouting).

To me, leadership is situational. You can be a leader by helping to rally a group of people around a vision, a mission, or a task and see it to completion. You can be a leader by providing coaching or mentoring to people whom need guidance. You can be a leader by helping to bring about change, whether it’s to your team, your office, your company, your school, your community, your nation, or your world. You can be a leader for something small that is very quick, or you can be a leader for initatives that take years. There are so many situations where you can be a leader.

Most times, chosing to lead is intentional. But sometimes, it’s unintentional. People whom step up to take charge because something must get done can do so without intentionally thinking they are being a “leader”. Are you a volunteer? Guess what - you’re helping to be a leader. You chose to do something without being told. That’s definitely one of the fundamental ways of finding good leaders - finding people with natural drive to want to help and let them soar!

What is good leadership?

Now, just because you step up and take charge of a project doesn’t make you a good or successful leader. It takes a lot to be a really great leader. Great leadership involves:

Defining and measuring success.
Understanding the situation and how to navigate the waters.
Finding appropriate team members to help you succeed.
Communicating effectively with your team and with others (this includes listening).
Coaching and mentoring your team to help them succeed.
Planning for how to achieve success.
Planning for contengencies in case of hypothetical impediments.
Driving you and your team to success.

There’s much more to leadership than this above list. Ask another leader and they’ll find probably another half a dozen things to add to my list.

Being competent in any of these takes time and experience. You won’t always succeed in everything you set out to do. As backwards as this may sound, failure is one of the greatest tools to help a good leader become great. It’s just important not to fail when there are dire consequences!

The other essential tool to help learn these leadership talents is training. I cannot overstate the importance of leadership training. It helps to provide frameworks, tools, and techniques to help you with various situations. It also provides a safe environment to practice and fail using new tools so you can become comfortable before using them in real life.

This is why I’m so excited about what Wood Badge leadership training provides to the community.

What is Wood Badge?

On paper, Wood Badge is the ultimate adult leadership training to help scouting leaders to understand the scouting model and ensure the youth in the program get everything out of the scouting program. At it’s core, Wood Badge is a leaderhip training course. They teach concepts such as:

Defining Vision, Mission, and Values
How to Understand Yourself to Lead Others
Effective Communication and Listening
Including and Optimizing Diverse Talent
Situational Leadership
DiSC Personality Profiles and how to use them with your team
Project Planning with a Bias for Action
Coaching and Mentoring
Building a Leadership Culture

In total, there are 14 leadership competencies in the Wood Badge curicculum. As you can imagine, there’s not enough time in 5 days to really dive deep into each of these competencies. They give you enough of what you need to know in order to investigate further. However, they do not disappoint in what they are able to present. It is enough for an inexperienced leader to come home with new skills to try and be effective. If they wish to take it further (like with Situational Leadership), additional training exists to help dive deep on any of those topics.

The Wood Badge training ties these leadership competencies to scouting by using the Patrol Method. Your patrol is your cohort for the whole of Wood Badge, and you end up forming a good bond with this team.

Why Wood Badge for Leadership Training?

Part of the reason I loved this training so much was how it told the story of the competencies and how they fit together. Most leadership training I’ve ever been thru has been isolated to one or two competencies. Nothing has ever connected training concepts with one another to help maximize potential. I’ve had to learn how to use each of the concepts and figure out my own path for stitching it together. Wood Badge put us thru grueling, time-limited situations to help us as a patrol see how to effectively use those concepts we just learned to be successful.

As a leader (scout leader, company leader, or otherwise), you owe it to yourself to get the best training you can that gives you plenty of opportunity to exercise that training in an environment where failure is acceptable and low-risk. Depending on your environment or situation, you don’t often get those opportunities to try to fail (or at least the consequences for failing may be too high).

If you don’t believe me how inspiring and valuable a training opportunity Wood Badge is, go ask other scouters in your community whom have attended. I have yet to meet a scouter who hasn’t had the same feeling on the importance Wood Badge has been on their life and their relationship to scouting.

Lots of Job Opportunities at Wolters Kluwer

2021-04-02T00:18:00+00:00

Updated September 14, 2021

At the start of 2021, I was asked to lead up a new team within Wolters Kluwer Tax & Accounting. This new team is dubbed the “Always On” engineering team. 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.

We have positions open in North America:

North America
- Manager, Product Software Engineering - We are seeking 1 highly technical software engineering manager to help lead our North America team to success.
- Senior Product Software Engineer - We are seeking one additional senior engineer who has significant experience in either WCF, WPF, Web API, SQL, or any combination of the above.

We also have a ScrumMaster, Product Owner, and Senior or Lead Software Engineer positions still open in India.

If you’re interested, feel free to hit me up via e-mail at chris@chrisweldon.net or ping me on social media. I would love to explain the role and the company and help put your resume into our pipeline!

SharePoint REST API Authentication from Java

2016-03-31T14:20:59+00:00

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#):

var handler = new System.Net.Http.HttpClientHandler() { UseDefaultCredentials = true };
using (var client = new System.Net.Http.HttpClient(handler)) 
{
    // Make some remote API call
}

It is literally one property to set on most networking libraries. Even when you do not want to use default credentials, there are a rich set of libraries, particularly the System.Net.NetworkCredential class that enables better authentication. Now here is the question: which authentication scheme are you using with this? NTLM, or Kerberos?

For Java developers, however, the problem was much more complex. I had many Java developers reaching out to me to understand how to properly authenticate to SharePoint. They assumed they had to use NTLM to authenticate to SharePoint. And indeed, the default way web applications are setup for SharePoint is with NTLM. However, many enterprises whom have hybrid Linux and Windows environments need to use Kerberos as their primary authentication system, as Kerberos works far better on Linux than NTLM.

The purpose of this article is to share how to authenticate Java applications with SharePoint using Kerberos in order to consume SharePoint REST APIs. I did not have extensive experience writing software in Java, much less Java for the enterprise - so these notes may simplify some concepts that are well-known to Java developers. However, if this problem were so easy to solve, why did I have so many Java developers reaching out to me to help them figure out how to solve it?

Note: This article assumes the SharePoint environment you are connecting is properly setup for Kerberos authentication. This includes ensuring that the web application is configured for Kerberos authentication, and all SPNs are properly registered.

Additional Note: For brevity, the code snippets here are greatly simplified and intentionally void of error handling.

Jumping to Code

I first attempted to understand this problem by writing some code that was meant to just connect to a SharePoint REST service and get data. This is my most basic implementation, which you can see is void of really any authentication details. Keep it simple stupid, right?

public class BasicSharePointRestClient {
    private static final ObjectMapper mapper = new ObjectMapper();
    protected final String BaseUrl;

    public BasicSharePointRestClient(String baseUrl) { BaseUrl = baseUrl; }

    public String get(String targetApi) throws Exception {
        Response response = Request.Get(BaseUrl + targetApi)
                                   .addHeader("Accept", "application/json;odata=verbose")
                                   .execute()

        // The request would been unauthorized. httpResponse.getStatusLine().getStatusCode == 401
        HttpResponse httpResponse = response.returnResponse();
        String results = EntityUtils.toString(httpResponse.getEntity());
        return results;
    }
}

Needless to say, the above code did not work. At the point where the request was executed, the HTTP response status code would be HTTP 401 UNAUTHORIZED, indicating that authentication credentials were not sent in the originating request.

Iteration 2

After further research, I stumbled upon some samples that were posted online. I tinkered with those samples and resulted in the following class. This was my first attempt which really worked:

public class HttpClientForSharePoint extends BasicSharePointRestClient {
    public HttpClientForSharePoint(String baseUrl) { super(baseUrl); }

    @Override
    public String get(String targetApi) throws Exception {
        DefaultHttpClient httpClient = new DefaultHttpClient();
        httpClient.getAuthSchemes().register(AuthPolicy.SPNEGO, new SPNegoSchemeFactory());

        Credentials useJaasCredentials = new Credentials() {
            public String getPassword() { return null; }
            public String getUserPrincipal() { return null; }
        };

        httpClient.getCredentialsProvider().setCredentials(
            new AuthScope(null, -1, null),
            useJaasCredentials
        );

        HttpUriRequest request = new HttpGet(BaseUrl + targetApi);
        request.addHeader("Accept", "application/json;odata=verbose");

        HttpResponse response = httpClient.execute(request);
        HttpEntity entity = response.getEntity();
        String results = EntityUtils.toString(entity);
        return results;
    }
}

I ended up with a proper JSON response (returned as a string) from this. However, there were several things I did not like about this implementation:

The method get() had too many responsibilities. It was responsible for configuring authentication as well as executing a REST call.
The authentication was limited to only SPNEGO, which is a negotiated authentication mechanism of Kerberos first, falling back to NTLM. What happens if I want to use only Kerberos? Or multiple types of authentication?

Iteration Three

I continued doing more research and resulted in finding the following, slightly more complex and alternative way to do this. It was derived from the works of the Spring Security Kerberos Client:

public class BuilderSharePointRestClient extends BasicSharePointRestClient {
    public BuilderSharePointRestClient(String baseUrl) { super(baseUrl); }

    @Override
    public String get(final String targetApi) throws Exception {
        LoginContext lc = new LoginContext("SharePoint", new TextCallbackHandler());
        lc.login();
        Subject serviceSubject = lc.getSubject();
        return Subject.doAs(serviceSubject, new PrivilegedAction<String>() {
            @Override
            public String run() {
                HttpClient httpClient = getHttpClient();
                try {
                    HttpUriRequest request = new HttpGet(BaseUrl + targetApi);
                    request.addHeader("Accept", "application/json;odata=verbose");
                    HttpResponse response = httpClient.execute(request);
                    HttpEntity entity = response.getEntity();
                    String results = EntityUtils.toString(entity);
                    EntityUtils.consume(entity);
                    return results;
                } catch (Exception e) {
                    return "";
                }
            }
        });
    }

    private HttpClient getHttpClient() {
        HttpClientBuilder builder = HttpClientBuilder.create();
        Lookup<AuthSchemeProvider> authSchemeRegistry = RegistryBuilder.<AuthSchemeProvider>create()
                .register(AuthSchemes.KERBEROS, new KerberosSchemeFactory())
                .register(AuthSchemes.NTLM, new NTLMSchemeFactory())
                .register(AuthSchemes.SPNEGO, new SPNegoSchemeFactory())
                .build();
        builder.setDefaultAuthSchemeRegistry(authSchemeRegistry);

        Credentials useJaasCredentials = new Credentials() {
            public String getPassword() { return null; }
            public Principal getUserPrincipal() { return null; }
        };
        BasicCredentialsProvider credentialsProvider = new BasicCredentialsProvider();
        credentialsProvider.setCredentials(new AuthScope(null, -1, null), useJaasCredentials);
        builder.setDefaultCredentialsProvider(credentialsProvider);
        return builder.build();
    }
}

The above class worked like a charm, and provided the best of single responsibility (although the private method should be moved to a different class), but nevertheless simplified the responsibilities of each method.

Configuring Java How to Authenticate Using Kerberos

Authentication in Java is performed by the Java Authentication and Authorization Service (JAAS). JAAS has a number of “defaults” that it uses when attempting to perform authentication, including Kerberos. We need to get an understanding of how Java authenticates using Kerberos within your corporate environment. This is dictated by two files, the login.conf and the krb5.conf file.

First, let us look at the login.conf file. From what I can tell, this file has no default “global” configuration, so you will need to create it from scratch. It has the following format:

<packagename.entryclass> {
    <loginmodule> <flags> <loginmodule options>;
}

The following is my login.conf for the classes above (and classes I depend upon). It may be overkill, but it works:

com.sun.security.jgss.login {
    com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};
com.sun.security.jgss.initiate {
    com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};
com.sun.security.jgss.accept {
    com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};
net.chrisweldon.SharePoint.BasicSharePointRestClient {
    com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};
net.chrisweldon.SharePoint.HttpClientForSharePoint {
    com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};
net.chrisweldon.SharePoint.BuilderSharePointRestClient {
    com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};

The second file is the krb5.conf file. This file is the kerberos configuration file, which tells what domains and realms are supported for authentication via Kerberos. The documentation (and purpose) of this file can get fairly complex given the corporate environment. However, if yours is setup correctly, you may not need to make any changes.

The default krb5.conf file is located at %JAVA_HOME%\lib\security\krb5.conf. If you open it up, it may look like the following:

[libdefaults]
    default_realm = CORP.CHRISWELDON.NET

[domain_realm]
    .corp.chrisweldon.net = CORP.CHRISWELDON.NET
    .othercorp.chrisweldon.net = OTHER.CHRISWELDON.NET

[realms]
    CORP.CHRISWELDON.NET = {
        dns_lookup_realm = true
        dns_lookup_kdc = true
        kdc = KDC.CHRISWELDON.NET
    }

    OTHER.CHRISWELDON.NET = {
        dns_lookup_realm = true
        dns_lookup_kdc = true
        kdc = OTHERKDC.CHRISWELDON.NET
    }

What this means is if I try to authenticate to a host that has a domain suffix of either .corp.chrisweldon.net (e.g sharepoint.corp.chrisweldon.net) or .othercorp.chrisweldon.net (e.g. exchange.othercorp.chrisweldon.net), Kerberos libraries will know what KDC servers to perform the authentication against.

Now, suppose you have a machine that is in your enterprise, but has an alias for a different domain, such as sharepoint.chrisweldon.com. Even if that server is connected to the CORP.CHRISWELDON.NET domain in Active Directory, the fact that you have an alias not listed in your krb5.conf file will cause you issues. So, copy the default krb5.conf file to your project directory and edit it to look like the following:

[libdefaults]
    default_realm = CORP.CHRISWELDON.NET

[domain_realm]
    .corp.chrisweldon.net = CORP.CHRISWELDON.NET
    .othercorp.chrisweldon.net = OTHER.CHRISWELDON.NET
    .chrisweldon.com = CORP.CHRISWELDON.NET # this is the addition

[realms]
    CORP.CHRISWELDON.NET = {
        dns_lookup_realm = true
        dns_lookup_kdc = true
        kdc = KDC.CHRISWELDON.NET
    }

    OTHER.CHRISWELDON.NET = {
        dns_lookup_realm = true
        dns_lookup_kdc = true
        kdc = OTHERKDC.CHRISWELDON.NET
    }

You are ready to execute your Java application! Simply specify the following arguments to ensure your app is looking at your custom configuration files and it will be authenticating to SharePoint!

-Djava.security.krb5.conf=C:/path/to/custom/krb5.conf -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.auth.login.config=C:/path/to/custom/login.conf

Finding When a User First Got Access to a SharePoint Site via REST

2016-02-03T14:20:59+00:00

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.

While working on permissions management within SharePoint, I needed to identify when a user first obtained access to their SharePoint 2013 site. I typically look at the SiteUsers table for information relating to users against a Site Collection. The SiteUsers collection can be accessed via the SharePoint REST API by going to /_api/web/SiteUsers. However, the properties on each SiteUser look like the following (obtained from the Users, groups, and roles REST API Reference):

{"d":{
  "results":[
    {
      "__metadata":{
        "id":"https://chrisweldon.sharepoint.com/_api/Web/GetUserById(16)",
        "uri":"https://chrisweldon.sharepoint.com/_api/Web/GetUserById(16)",
        "type":"SP.User"
      },
      "Groups":{"__deferred":{"uri":"https://chrisweldon.sharepoint.com/_api/Web/GetUserById(16)/Groups"}},
      "Id":16,
      "IsHiddenInUI":false,
      "LoginName":"i:0#.w|domain\\user1",
      "Title":" User1 Display Name ",
      "PrincipalType":1,
      "Email":"user1@company.com",
      "IsSiteAdmin":false,{
      "__metadata":{
        "type":"SP.UserIdInfo"},
        "NameId":"s-0-0-00-000000-0000000000-0000000000-000000",
        "NameIdIssuer":"issuer id"
      }
    }
  ]
}}

There are no dates in this. When I thought about it, I remembered the User Information List. This list contains a wealth of additional details beyond what the SiteUsers collection provides. The reason: it is nothing more than a list - just one with lots of columns of rich data. More importantly, it is available to query via the REST API! Checking the structure of the User Information List was as simple as executing the following REST query:

GET /_api/web/lists/getbytitle('User Information List')/Fields?$select=InternalName&$filter=InternalName%20eq%20'Created'%20or%20InternalName%20eq%20'UserName'
Accept: application/json;odata=verbose

Note: a short way is via /_api/web/SiteUserInfoList. The results are as follows:

{
    "d": {
        "results": [
            {
                "__metadata": {
                    "id": "https://chrisweldon.sharepoint.com/_api/Web/SiteUserInfoList/Fields(guid'453160d6-6a28-42ba-ba45-9f9d2c70407d')",
                    "uri": "https://chrisweldon.sharepoint.com/_api/Web/SiteUserInfoList/Fields(guid'453160d6-6a28-42ba-ba45-9f9d2c70407d')",
                    "type": "SP.FieldText"
                },
                "InternalName": "UserName"
            },
            {
                "__metadata": {
                    "id": "https://chrisweldon.sharepoint.com/_api/Web/SiteUserInfoList/Fields(guid'8c06beca-0777-48f7-91c7-6da68bc07b69')",
                    "uri": "https://chrisweldon.sharepoint.com/_api/Web/SiteUserInfoList/Fields(guid'8c06beca-0777-48f7-91c7-6da68bc07b69')",
                    "type": "SP.FieldDateTime"
                },
                "InternalName": "Created"
            }
        ]
    }
}

Awesome! It exists! Now all I have to do is query for the specific user that I want. When I have a specific UserName to find, all I have to execute is the following query:

GET /_api/web/SiteUserInfoList/Items?$select=UserName,Created&$filter=UserName%20eq%20'neraath@chrisweldon.onmicrosoft.com'
Accept: application/json;odata=verbose

And I get exactly what I want:

{
    "d": {
        "results": [
            {
                "__metadata": {
                    "id": "7df6fc9b-0755-421e-934d-617ca89d5d9f",
                    "uri": "https://chrisweldon.sharepoint.com/_api/Web/SiteUserInfoList/Items(12)",
                    "etag": "\"19\"",
                    "type": "SP.Data.UserInfoItem"
                },
                "UserName": "neraath@chrisweldon.onmicrosoft.com",
                "Created": "2013-04-12T15:38:12Z"
            }
        ]
    }
}

In summary, when you are looking to find information about users whom have access to your SharePoint sites, remember the User Information List, and also remember it is queryable via the REST API!

On Helpers and the use of static

2014-03-03T05:08:21+00:00

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.

So, why are statics bad?

I’m a huge fan of automated testing. I started with unit tests, but have recently moved into the realm of behavior tests. Yet, for any automated testing, you have to have good architecture in your code to ensure that you can test in any environment.

Let me give the most basic example: the use of a logging facility. Take for example the following loggger that I see all too often:

public static class LoggingHelper
{
    public static void LogMessage(string message, string area)
    {
        var logPath = Constants.LogPath;
        using (StreamWriter writer = System.IO.File.AppendText(logPath))
        {
            writer.WriteLine("INFO\t[" + area + "]" + message);
        }
    }

    public static void LogError(string message, string area)
    {
        var logPath = Constants.LogPath;
        using (StreamWriter writer = System.IO.File.AppendText(logPath))
        {
            writer.WriteLine("ERROR\t[" + area + "]" + message);
        }
    }

    public static void LogException(string message, string area, Exception exception)
    {
        var logPath = Constants.LogPath;
        using (StreamWriter writer = System.IO.File.AppendText(logPath))
        {
            writer.WriteLine("EXCEPTION\t[" + area + "]" + message + " - " + exception.Message);
            writer.WriteLine("Stack Trace" + exception.StackTrace);
        }
    }
}

Here are a few areas the above code block can improve:

There’s no exception handling. At all.
There’s no mutexes/resource locking. Thus, it’s possible for multiple threads to attempt to open the file at the same time. The first one in will succeed. All others will throw exceptions.
It’s insanely duplicative. In fact, I was able to copy every line of LogMessage to LogError and only have to change 2 lines of code. The same goes for LogException, where I also added an additional line.
What happens when I have another type of message I need to log? That means I must add another method - 6 of those lines likely the same as LogMessage.
What happens when I need to change the location of the log file?
What happens when I need to change the underlying facility for logging? Say, from files to databases?

The last two are key here. For the first, I can change from Constants.LogPath to something like ConfigurationManager.AppSettings["LogPath"], But what happens when the file is a network file system? Not accessible via standard UNC paths? You’re up a creek and this entire class needs to change. That’s pretty much the case of the second question.

You should assume that your underlying logging destination can and will change at any time. If you think that the simple solution to this is to simply change the LoggingHelper class, think again. Let’s take this further. You should assume that your destination will be different for multiple scenarios. In enterprise development, this is frequently the case. In a pre-integration environment, you may only want to log to the filesystem because it may be a single server. However, in integration and production you might choose to log to a database since you’re deploying to a farm of servers and writing to the filesystem makes diagnosing problems a true headache.

Back to the problem of automated testing, you don’t really want any logging. Why? What happens when your test runner doesn’t have access to the logging path? What happens when your test environment doesn’t have the path at all? What happens when you forget you have your test environment dumping massive amounts of logs to the filesystem only to go on a goose chase figuring out why your builds randomly started to fail due to the disk being full? In the case of unit testing, /dev/null should be your destination.

Let’s consider one last secenario: what happens if you want to log to multiple facilities at once?

In any of those cases, using a static class with static methods does not afford you any flexibility. If you want to expand to multiple logging facilities, you would be forced to create another static class. That class is now called in addition to this one. Yuck.

Here’s where I come back to the SOLID principles. Let’s look at how Static classes (and static methods) violate these principles.

Open/Closed Principle - Classes should be open for extension, but closed for modification.
- With statics, you cannot extend and override the behavior. You throw out the idea of polymorphism. This makes it ~~very difficult~~ impossible for me to inject different behaviors for whatever need I may have.
Dependency Inversion Principle - Depend upon Abstractions. Do not depend upon concretions.
- With statics, every class that leverages its facilities are now dependent upon a concretion. There is no way to pass around an abstraction of a static class or regular class with static methods. Your only way of doing this is with reflection and that’s a definite code smell.

In summary, because I cannot leverage the power of inheritance, polymorphism, or really any aspect of object oriented analysis and design with statics, it feels a lot like procedural programming. I suggest leaving this practice behind.

So, why are helpers bad?

My discussion with my colleagues yielded an interesting observation: everyone’s opinion of a helper was slightly different. One thought of it as a single data access layer. Another thought of it as a way of providing consistent authentication for data access. But others think of helpers as the giant “I don’t know where to stick this method” bucket. So, you end up with something like this (methods only, since that should convey what I’m getting at):

public static class Utils
{
    public static string CleanInput(string input);

    public static void FlushCacheIndex();

    public static bool CheckIfSystemIsHealthy();

    public static int GetCountOfActiveUsers();

    public static MyModel CreateModelFromInput(string name, string email, int age, DateTime birthday);
}

These types of helpers are a maintainability nightmare. For starters, if you haven’t read my section above on why statics are bad, step back and read it. Both SOLID principles are still violated. Yet, there are also a couple of others that are violated.

Single Responsibility Principle - A class should have only one reason to change.
- It’s clear in the case above that there are multiple reasons this class exists. However, there are other helper classes (such as StringUtils which are not as clear. However, I’m still a firm believer that the Open/Closed Principle dictates whether to add yet another method to an existing class, or create a separate class. I’m a huge fan of small classes as their much easier to test and maintain.
Interface Segregation Principle - Many client-specific interfaces are better than one general-purpose interface.
- Okay, so this isn’t an interface. ISP is definitely meant for solving another problem. However, the basics behind this principle apply here. This is a general-purpose class. Why should I have my code strongly-coupled to this class if all I need is one method within it?

Now, to tackle some of the other arguments in favor of helper classes, let’s look at another example I’ve seen in the past:

public class DatabaseHelper
{
    private static DataAccessObject daoInstance;

    public static DataAccessObject CreateDataAccessObject(User invokingUser)
    {
        if (daoInstance == null)
        {
            var dao = new DataAccessObject();
            dao.AuthenticationMode = AuthenticationModes.Shared;
            dao.Credentials = new DataAccessCredentials(invokingUser.Kerberos, invokingUser.Token);
            return dao;
        }
        return daoInstance;
    }
}

Ah, rather than a helper, you meant a factory. Okay, I can dig that…sorta. We’re still using static here, which makes it impossible for me to factorize the creation of my DAO without strongly coupling my business logic to this specific class. Now, a factory is meant to abstract away the details of creating an object of a specific type. There’s some generally common expected inputs, and you get a generic implementation at the output. But, how should you go about doing that?

If you’re using a proper dependency injection/Inversion of Control container, you’ll be able to configure your application instance to inject a provider which implements the following interface:

public interface DataAccessFactory
{
    DataAccessObject CreateDataAccessObject(User invokingUser);
}

Furthermore, if you’re in a spot where you need a singleton instance of the DataAccessObject, then you can make sure that you implement the appropriate logic in your Factory instance and setup your IoC container to maintain a singleton instance of the object.

When discussing the use of “helper” classes, it’s more difficult to outright say they aren’t useful, because each person’s definition of helper classes are different. Nevertheless, if you venture down the path of bucket “utility” classes, stop. There are better approaches you can take.

Well, I still don’t agree with you…

That’s fine. You’re entitled to your opinion. Just don’t expect for me to pass your code reviews.

Are there circumstances where the use of a static method might be worth it? Quite possibly. But I rarely encounter those cases. If one of those reasons is “it’s faster to do it with a static than via good architecture” then you’re just being lazy. Yes, software development is about delivering value. However, what debt you introduce to the system must later be addressed save you be unable to deliver any value once you’ve built a castle with no doors around you.

I’m not alone in this. Check out just a few other blogs which carry several really good arguments against the use of statics or helpers:

Where did you shape your thoughts on best practices?

In my previous role at Improving Enterprises, there were a number of really talented technologists, passionate about best practices. They were staunch supporters of user groups and community as well. Thus, my opinions on best practices have been shaped not only through previous co-workers and colleagues, but also by community.

Community has a lot of benefits, and has a lot of diversity of thought. The software community provides an atmosphere for technologists to actively try many of the best practices they preach through katas, discussions, pull requests, and many other channels. These best practices are most commonly focused around the use of patterns. Why reinvent the wheel when patterns exist to help solve the same or similar problems? However, these patterns often have justifiable use: they leverage the facets of object oriented languages in the manner they were expected to be used.

This is where I started to learn about best practices. My source of community was extremely diverse. It included my colleagues at work, my close developer friends, and those technologists in the community who were extremely passionate about their work. Some of these technologists I engaged only through user groups, some through their blogs, and some through discussion boards. I am a high achiever, and in order for me to achieve, I must learn - so I am always on a continuous search for new information - even if it contradicts previous thoughts or practices I held imporant to me.

Finally, the only other way to really learn and solidify the importance of a best practice is to, well, practice it. With enough practice, you’ll invariably run into other practices which box you into a corner or make your life very difficult. The more times you encounter these situations, the greater a believer in best practices which leverage the power of object oriented design and development.

Diversity of thought is a great practice and should be encouraged. It leads to more out-of-the-box thinking, approaches to problems, and ensures that all risks are vocalized. However, one of the most important things I’ve had to learn is that no matter what, diversity of thought should always be supported with sound reason and justification. Simply citing a preference to a mode of practice, idea, or solution without good justification to a practice is hard to accept in a professional setting.

[2] http://www.improvingenterprises.com/ [3] http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

Communication Brevity

2013-11-26T18:50:00+00:00

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 Problem

For those examples I listed above, how important is it to your team to find that information now or three years from now? Let’s face it - most teams undergo turnover at some point and with some degree of variability. Those whom are left find themselves struggling to find the context - the why - beind a particular decision. This becomes more evident the longer time passes since a decision was made.

We have this problem now. I am considering simplifying a system we have currently. Yet, I can’t find any context to understand why the system is currently so complex. Everyone agrees there should be a reason, but nobody knows why that reason is. The how of the system was perfectly documented, but the why was not. If current (and former) history are any sign, it’s likely the conversation of why has been lost somewhere along the way.

The Solution

As previously indicated, expressing yourself via e-mail in 140 characters or less is hard. You want to know what isn’t hard to express under that constraint? A URL.

The solution to this problem is easy. If you shift your conversation online, its longevity or persistance is no longer tied to the life of someone’s inbox. We have what we call a “posting” culture at the firm - a process to keep as many people who are directly involved or may be involved informed about the progress of our work. However, doing so via e-mail is laborious, especially if you leave out a stakeholder. However, if the conversation is non-private, having that conversation on an online social platform enables those stakeholders to opt-in to your updates. They can sit on the sidelines watching the activity, or if they see something that requires their intervention, they can take charge and engage in the conversation.

But what about private conversations? Most social platforms have the capability for engaging in private conversation. Whether this be through closed collaboration/team rooms or direct messages between you and another user. However, once decisions have been made, it becomes easy to promote the relevant pieces of those conversations from private to public - it’s already online.

Additional Benefits

The problems of traditional e-mail go beyond simply lack of context. Many corporate e-mail platforms still don’t provide metadata tagging. Searching for e-mail means you search conversations only you were directly involved. Being able to keep track of the conversation thread is dismal with our tools - only a few e-mail clients (and only very recently) are able to present conversations in threaded views. Most people still don’t know those features exist! Finally, collboration on documents still happens by shipping them via e-mail. Which is the authoritative final version? Finally, what was the final decision of that chain of e-mails about how to proceed on our design?

Moving the conversation online to social platforms opens up many other benefits. Tagging (primarily #tags, pronounced as hashtags) are in most platforms. For those not familiar, tagging content with certain keywords enables easier discoverability. When you search for relevant conversations using those keywords, the search engine considers tagged posts more relevant than posts having those words somewhere in the document. A human made the decision that keyword pertains to this conversation, rather than that word being used in a conversation about something completely different. Search is also enhanced as you’re now searching all open and public conversations, broadening your search potential.

Being able to follow conversations is much easier. Threaded views enable clear visibility and understanding of the flow of conversations. Furthermore, most social platforms (especially in the Q&A space) have options for marking something as a “correct” or “most helpful” answer. Leveraging these same features, even for team discussions accomplishes two things:

You know exactly which decision was made, even when the content indicating that a decision had been made was unclear.
You have all of the conversation surrounding why that decision was made.

Finally, when it comes to sharing and collaborating on content, like Word/Excel/PowerPoint documents, moving that online and providing a single authoritative source for the document reduces confusion on which is the final version and the final copy.

Give it a Try

Don’t wait. Force yourself into this model. It will be hard - you’ll want to revert back to your old ways of typing lengthy e-mails and using distribution lists. When you find yourself writing even just two sentences in an e-mail: stop. Immediately move to your online space and continue. Don’t be tempted to reply in e-mail to someone sending you the link to the topic thread they started online - keep the conversation where it originated! But move it online if it started in e-mail!

While your team starts adopting this pattern of communication, you’ll see some short-term gains (like discoverability, transparency, clarity of decisions, inclusion, etc.). However, this is all about the long-term gains your team will have. The more content you push online, the better it will be for your team when it comes to retaining critical information. It will be worth it!

SharePoint 2013 My Site Timer Jobs Missing

2013-08-02T15:07:00+00:00

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:

My Site Instantiation Interactive Request Queue
My Site Instantiation Non-Interactive Request Queue
My Site Second Instantiation Interactive Request Queue

The problem is, those timer jobs were missing from my server! I checked for the timer jobs first through Central Administration, and then subsequently thru PowerShell. The following are the results I found:

Get-SPTimerJob | sort Name | ft Name

I decided to check for the My Site timer jobs on a know working SharePoint 2013 farm. Sure enough, they were there:

I wanted to look for a way to re-register timer jobs. There should be no reason for me to do something drastic like uninstall/reinstall the User Profile Service just to get the timer job re-registered. This timer job, as expected, was in the Microsoft.Office.Server.UserProfiles assembly:

So, I cracked open dotPeek and decided to hunt for that timer job definition and find who was using it. It turns out, there’s a web application-level feature (MySiteInstantiationQueuesFeatureReceiver) which registers these timer jobs:

There is a public static method inside that feature receiver used for registering the timer jobs.

So, I had one of two options: invoke the static method directly, or simply toggle the feature. I opted to toggle the feature:

$feat = Get-SPFeature 65B53AAF-4754-46D7-BB5B-7ED4CF5564E1
Disable-SPFeature $feat -Url http://webapp
Enable-SPFeature $feat -Url http://webapp

Finally, I double checked and verified the timer jobs were now present!

I then went to the My Site host URL and got into the queue for provisioning. Within 5 minutes, my personal my site was provisioned!

Getting the confusing SharePoint 2013 SocialDataStoreException

2013-05-06T11:34:00+00:00

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:

The target of the operation was not found. Internal type name: Microsoft.Office.Server.UserProfiles.SocialDataStoreException. Internal error code: 0.

The problem seemed fairly straight-forward. The targeted site I wanted to follow couldn’t be found. However, it didn’t make sense. The instance URL I was targeting (https://chrisweldon.sharepoint.com) did in fact exist. Furthermore, I was not already following that site. So, why was this failing?

Let’s take a look at some code:

SP.SOD.executeOrDelayUntilScriptLoaded(userProfilesLoaded, 'SP.UserProfiles.js');

function userProfilesLoaded() {
    SP.SOD.executeFunc('userprofile', 'SP.Social.SocialFollowingManager', followSites);
}

function followSites() {
    var context = SP.ClientContext.get_current();
    var socialManager = new SP.Social.SocialFollowingManager(context);
    var socialSite = new SP.Social.SocialActorInfo();
    socialSite.set_contentUri("https://chrisweldon.sharepoint.com");
    socialSite.set_actorType(SP.Social.SocialActorType.site);
    socialManager.follow(socialSite);

    context.executeQueryAsync(
        function() { alert('Sites followed!'); }, 
        function(sender, args) { alert('Error: ' + args.get_message()); });
}

This is fairly straight-forward. I simply setup a social actor to follow and call out to the SocialFollowingManager to attempt to follow that site. This is when I thought, perhaps this is a permissions problem? I’m trying to have the JavaScript object model write a request to the Social datastore. Perhaps it wasn’t authorized.

I changed the permissions in my AppManifest.xml from Read to Write:

Scope	Permission
User Profiles (Social)	Write

Sadly, I received the same error message. However, if you read the MSDN Documentation on Developing Social Features in SharePoint 2013, there is a section in there talking about user profiles:

User Profiles (http://sharepoint/social/tenant) The permission request scope used to access all user profiles. Only the profile picture can be changed; all other user profile properties are read-only for apps for SharePoint. Apps that request rights for the User Profiles scope must be installed by a tenant administrator.

In a nutshell, I have to grant Tenant permissions to my app to be able to have my user follow a new site. Therefore, my new permissions look like the following:

Scope	Permission
User Profiles (Social)	Read
Tenant	Write

As indicated by the paragraph above, the app now needs to be installed by a tenant administrator. However, in doing so, the app now follows sites (and other content) with ease. Why the obscure error message? That I don’t know, and I hope the SharePoint team might look to address this with a more correct error message in the near future.

MigrateUsersToClaims - Operation is not valid due to the current state of the object

2013-04-30T11:50:00+00:00

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.

The recommended path to upgrade from 2010 to 2013 is a content and service-application database migration. This works great for us since we have to do this piecemeal. However, many of the general approaches for converting to claims-based authentication is to do so at the web-application level, rather than the content-database level (source: TechNet).

In SharePoint 2013, there’s actually an SPWebApplication method dubbed MigrateUsersToClaims that takes 3 arguments:

NTAccount
removePermissionsAfter
SPWebApplication.SPMigrateUserParameters

There was no guidance on the NTAccount, other than the user “performing” the operation. I opted to use the farm account to ensure it had the appropriate level of permissions. The true power of the content database migration comes in with the third parameter. We can add individual content databases to migrate with this parameter rather than worrying about the entire web application.

Props go to Steve Peschka who originally pointed this out. However, in his post, the PowerShell to do this upgrade was the following:

-- SNIP -- 
$wa.MigrateUsersToClaims($acc, $true, $arguments)

For me, that throws the error Exception calling "MigrateUsersToClaims" with "3" argument(s): "Operation is not valid due to the current state of the object." This was strange, and I couldn’t figure it out. So, I cracked open the Microsoft.SharePoint.Administration dll and took a look at the MigrateUsersToClaims method:

public bool MigrateUsersToClaims(NTAccount account, bool removePermissionsAfter, SPWebApplication.SPMigrateUserParameters parameters)
{
    if ((NTAccount) null == account)
        throw new ArgumentNullException("account");
    if (removePermissionsAfter && parameters != null && (parameters.HasDatabaseToMigrate || parameters.OnlyMigratePolicyUsers))
        throw new InvalidOperationException();
    // The rest
}

That second one was the one that I questioned. I know the conditions matched for the first two checks. The question was how my parameters looked. Sure enough:

PS > $arguments

DatabasesToMigrate      HasDatabaseToMigrate        OnlyMigratePolicyUsers
------------------      --------------------        ----------------------
{WSS_MigrationTest_...}                 True                         False

With that, if I changed the middle parameter from $true to $false, the migration finally ran (and completed) succesfully.

Why did this happen? This was because my $acc user is my farm account. I’m also running my PowerShell session as my farm account. This is to ensure that I have full, unfettered access to the SharePoint Object Model and the Content Database. The middle parameter states (from MSDN):

The account will be given the correct permissions to perform the operation. Should this permission be removed when the operation is complete.

We definitely don’t want this for the farm account. So, my updated code, for reference:

$wa = Get-SPWebApplication http://my-app-url
$acc = "domain\farm-account"
$arguments = New-Object Microsoft.SharePoint.Administration.SPWebApplication+SPMigrateUserParameters

$contentDb = $wa.ContentDatabase["Content Database Name"]
$arguments.AddDatabaseToMigrate($contentDb)
$wa.MigrateUsersToClaims($acc, $false, $arguments)

Cheers. Once again, thanks go to Steve Peschka for figuring this out.

Sorry, only tenant administrators can add or give access to this app

2013-04-30T10:41:00+00:00

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.

The application required Tenant Read permissions as I’m accessing the User Profile through the JavaScript object model. The purpose of using the User Profile JSOM is to get the suggestions of sites and people to follow that SharePoint presents.

Now, the concept of a “Tenant” makes sense for Office 365 or SharePoint Online. As a hosting provider, there are multiple tenants you want to support in a single environment. However, for an on-premise deployment, this error message didn’t make much sense. I started poking around and came across spinning up a tenant administration site, being able to set multiple app tenants through the App Management Service cmdlets, but none of those really seemed like the right solution for my on-premise deployment. I found an MDSN Forum Question which seemed closer to the solution. That post recommends splitting the service accounts used to host the App Management and Site Settings services from the farm account. This was critical as the Farm Account is not allowed to add apps under its identity whatsoever. You will get an error message when trying to provision, and the ULS logs will indicate that an assertion failed checking that the current account was not the system account.

What did it turn out to be? I just needed to make sure my user account was directly added as a member of the Farm Administrators group. We have traditionally deployed farm administrators via an Active Directory and local (Administrators) group. However, it appears that the App Management service dislikes this approach and wants users explicitly permissioned to the Farm Administrators group. Additionally, after granting your user direct permissions, you need to issue an iisreset so those changes take effect. Then, you can provision your app successfully.