Jonathan Eckman

Bring DevOps to your O365 Development Team

Fri, 20 Dec 2019 07:03:47 GMT

In my latest blog post I describe how you can enable successful DevOps practices by taking advantage of advancements made in the SharePoint Framework and O365. Manage your O365 configuration as code, add test automation to your SharePoint Framework solution, and deploy it all to test, staging, and production environments with a Continuous Integration and Delivery (CI/CD) pipeline. Check it out on the Applied Information Science’s website.

Failed to decode %PUBLIC_PATH%

Tue, 06 Feb 2018 07:03:47 GMT

Problem

I’ve been dabbling in React and recently discovered the amazing create-react-app tool. Here’s a unique problem I ran into when using it, and my solution.

In Visual Studio Team Services (VSTS), I created a new project called “My Project”. The space is important.
VSTS will create a default git repository using the same name as the project.
I pushed the React app to source control.
The repo URL is https://myaccount.visualstudio.com/_git/My%20App (notice the encoded space), so cloning it will put it into a My%20App directory.
Run npm start
In terminal, you’ll see the error: "Failed to decode param '/%PUBLIC_URL%/favicon.ico' and 400 bad request errors in the developer console.

Solution

The solution is simple, but not immediatley obvious. The % in the file path was breaking the build task searching for the %PUBLIC_URL% tokens in index.html.

My fix was to rename the project folder. I also renamed the repo to spare the rest of the devs on my team.

Handling .NET Core Web API Exceptions with an Aurelia Interceptor

Sun, 14 Jan 2018 07:03:47 GMT

Problem: Failed to Fetch

In my teams Aurelia app, I wanted an easy way to handle all HTTP response errors coming from our .NET Core Web API. This is easily done with the requestError method on Aurelia’s Interceptor interface. This method acts as a Promise reject handler so when working properly, I’d expect to recieve the failed Response as an argument. Instead, a TypeError was thrown with the message “Failed to fetch”.

Aurelia Interceptor

The problem was not with Aurelia nor the underlying fetch library. Both were doing their jobs given the configuration I provided. The final responseError code simply receives the failed response, does something with the payload, then rejects the promise. The ServerError interface shown in the example below provides typings for our custom error payload. You will see where this object is created in a moment.

responseError(response: any): Promise<Response> {
    if (response instanceof Response) {
        return response.json().then((serverError: ServerError) => {
        
            // Do something with the error here.
            
            return Promise.reject<Response>(serverError.error);
        }); 
    }
}

.NET Core Exception Handling Middleware

I already knew something was failing in our API code. On the client, I was receiving a 500 error with a message indicating a CORS problem.

No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ’https://localhost:44303’ is therefore not allowed access. The response had HTTP status code 500. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

There was a problem, but the CORS error is misleading. Checking the server logs, I found that the real problem was an unhandled SQL exception. In Startup.cs, my API was configured to handle errors with the UseDeveloperExceptionPage middleware:

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}
else
{
    app.UseExceptionHandler("/Home/Error");
}

I suspected the root cause had to do with this middleware. Searching around, I found a discussion on GitHub that proved it. This middleware strips everything it can from the response headers which causes the CORS and “Failed to fetch” errors.

My solution was to add my own error handling middleware to the API called ErrorHandlingMiddleware.

public class ErrorHandlingMiddleware
{
    private readonly RequestDelegate next;

    public ErrorHandlingMiddleware(RequestDelegate next)
    {
        this.next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        try
        {
            await next(context);
        }
        catch (Exception ex)
        {
            await HandleExceptionAsync(context, ex);
        }
    }

    private static Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        var code = HttpStatusCode.InternalServerError;

        var result = JsonConvert.SerializeObject(new { 
             error = "An internal server error has occurred." 
        });
        context.Response.ContentType = "application/json";
        context.Response.StatusCode = (int)code;
        return context.Response.WriteAsync(result);
    }
}

I then registered that middleware in the Configure method of Startup.cs.

app.UseMiddleware<ErrorHandlingMiddleware>();
app.UseStaticFiles();
app.UseMvc();

After this change, responseError received the response with everything I needed to know how to handle it, such as a status code and error message.

Your First Open Source Contribution

Sun, 07 Jan 2018 07:03:47 GMT

I recently had the opportunity to contribute to the Aurelia framework. Aside from a handful of small changes made using GitHub’s in-browser code editor, this was my first experience contributing to an open source project. I’m hoping that documenting what I’ve learned will help those who have wanted to contribute to an open source project but aren’t sure where to start or how the pieces fit together.

Planning

Before doing anything, look through the active issues to see if your idea is already being tracked. If not, create a new issue describing the bug you’d like to fix or the feature you wish to add. Discuss the proposed changes with someone on the projects core team. In my case, I seeked to start the conversation on the GitHub issue, in Aurelia’s Gitter, or in Aurleia’s Discourse. I found that the core team members were listed in GitHub but most are already easy to spot by the Aurelia logo in their profile picture, such as in Rob Eisenberg’s picture shown below.

Read the contribution guidelines. Aurelia’s contribution guidelines state that small changes can be crafted and submitted, but large changes should be coordinated with the team. I chose to create an issue even though my change was small. In my experience, lack of coordination often leads to wasted time so I wanted the team to be aware of my idea before I started working on it. I’ve also gotten into the habit of associating my changes with a work item. By creating an issue now, I’ll have it ready to reference when I submit a pull request.

Project Setup

Create an isolated copy of the repository by forking it. This is as simple as clicking the fork button in the top right corner of the repository you wish to contribute to.

Clone the forked repository to your local workstation and open it in your IDE or text editor of choice. I use Visual Studio Code. It’s good practice to work in topic branches instead of directly in master. Create and checkout a topic branch with:

git checkout -b my-new-feature

From here, each project will be different. In my case, all of Aurelia projects contain a readme.md file that describe how to set up the project. Usually this includes downloading dependencies, running a build script, and executing tests. Complete all steps to ensure the project builds and is working as expected.

Develop and Test

Instead of blindly modifying an API and hoping for the best, I need to see my changes in the wild. To do this, I needed a front end application to test with. I chose to generate a new one using the Aurelia CLI but you may use an existing app if you have one handy. Using the CLI is as simple as running the following from your destination directory:

npm install aurelia-cli -g
au new --here

Next I created a link between the cloned Aurelia source code and my front end app. Think of this as referencing a package on your workstation instead of the one downloaded to node_modules. Navigate to the root of the Aurelia project and run:

npm link

Navigate to the root of the front end app and run the command below. In my case, I was testing a change to aurelia-binding. Change this to whatever module you’re working with.

npm link aurelia-binding

Make your changes to the Aurelia library, build the project, then jump over to your front end app to test the change. Repeat until perfect.

To ensure you didn’t introduce a regression bug, run the same test script you did during project setup. This usually looks something like karma start or jest.

Submit

As you commit changes, make sure to follow the projects commit message guidelines. As an example, you can find Aurelia’s guidelines here. For examples on how to craft the perfect commit message, refer to the commit history of your projects repository. Push your changes to the server then create a pull request by clicking the big green “new pull request” button on the destination repository.

Include the id of the issue you are working from to associate it with your pull request. Provide a helpful description so the code reviewer understands your changes then click submit.

Cleanup

Optionally, you may want to remove the symlink we created with npm link so that your front end references the library it downloaded from the npm registry instead of the local copy. To do this, simply run the following from the root of your front end app.

npm unlink aurelia-binding

And from the root of the Aurelia project:

npm unlink