Luke Warren Dev
Software Development Tips and Stories When I feel Like It

CI and CD Pipeline for Rework

My first YouTube Video

CI and CD Pipeline for Rework

Short post here.

Just wanted to notify my loyal reader base of a YouTube video that I have put up showing how the continuous integration and continuous delivery pipeline works for Rework. The video was filmed via live stream on my LiveCoding.tv channel but I also uploaded it to YouTube

So, without further adieu:



Click here to comment

Introducing the Model Builder - You Don't Need Automapper

This post is quite simple. You don't need Automapper, all you need is a model builder.

Introducing the Model Builder - You Don't Need Automapper

Now I am a big fan of "don't reinvent the wheel" but at times we as developers need to learn where to draw the line. In this article I will show you a very simple pattern that gives you more control and avoids needing to bring in yet another dependency - AutoMapper.

Disclaimer: I like and use Automapper in many of my projects and will continue to. It is a great library but sometimes you just don't need it.

Example ModelBuilder

All our model builder class does is either create a Model class from its entity/domain class equivalent OR parse a Model class back to a entity/domain class.

public class ModelBuilder
{
    public ProvinceModel Create(Province province)
    {
        Require.NotNull(province);
        Require.NotNullOrEmptyOrWhitespace(province.Name);

        return new ProvinceModel
        {
            Id = province.Id,
            Name = province.Name
        };
    }

    public Province Parse(ProvinceModel model)
    {
        Require.NotNull(model);
        Require.NotNullOrEmptyOrWhitespace(model.Name);

        return new Province
        {
            Id = model.Id,
            Name = model.Name
        };
    }
}

Wondering what that Require stuff is? Those are just some handy methods contained in the Rework Nuget Package (yes, this is a shameless plug).

ModelBuilder In Action:

I usually either inject my model builder in the constructor for the class that needs to use it, or just instantiate it right there in the constructor. The later does make it a concrete dependency rather than an abstraction but sometimes this makes sense IMO.

You could, either create a model builder for each entity-domain relationship you have or just put them all in one. You are reading this blog so I will assume that you are smart and can figure out what you prefer ;).

For completeness, here is how you actually use the thing:

    public ProvinceController(IProvinceService service)
    {
        // Init my service and create my model builder
        _service = service;
        _builder = new ModelBuilder();
    }

   public object Post(ProvinceModel model)
    {
        Province province = _builder.Parse(model);
        _provinceService.Create(province); // My "service" is creating the province in the DB
        return _builder.Create(province);
    }

Click here to comment

New Version of Rework Available

My helper is slowly becoming something useful

New Version of Rework Available

Happy to make a quick announcement that Rework is slowly getting useful!

A new version is out and features some more handy string functions for truncating strings. The library is still very light but does help eradicate some silly boilerplate code

Check it out on Nuget and Github or simple install it with the Nuget Package Manager command Install-Package Rework


Click here to comment

My First Nuget Package: Rework

I am so tired of rewriting the same code over and over and over again

My First Nuget Package: Rework

So I have been wanting to do this for a while but finally got around to creating a reusable C# library.  

The library contains all the sort of helper functions that you tend to re-write, redo or "Rework". It is currently quite light but is fully unit tested and highly reliable. I am using AppVeyor for Continuous Integration and Deployment to Nuget.

I am hoping to do a video at some point on just how easy it is to setup a project in AppVeyor. For more info on the project, it's features and how to use it. Simple head over to Github.

If you like the library and want to add to it, feel free to contact me or put in a pull request.


Click here to comment

How to configure the Hangfire Dashboard in an ASP.NET App

Hangfire is an awesome little library to aid in the scheduling of recurring or deferred "jobs".

How to configure the Hangfire Dashboard in an ASP.NET App

Hangfire is an awesome little library to aid in the scheduling of recurring or deferred "jobs".

It comes with a handy dashboard that, when configured, allows you to easily monitor and take actions on your jobs.

The problem I have come across on StackOverflow and other sites is that many people battle to get the dashboard setup, so I thought that I would document here how it is done.

First we need to create an authorization filter

This will be used later to make sure that only authenticated and authorised users can access the dashboard.

This means making sure that users are both logged in and in the admin role before they can view the Hangfire dashboard.

using MyApp.Common;
using Hangfire.Dashboard;
using Microsoft.Owin;
using System.Collections.Generic;

namespace MyApp.Dashboard.Schedules
{
   public class HangfireAuthorizationFilter : IAuthorizationFilter
   {
          public HangfireAuthorizationFilter()
          {
          }

          public bool Authorize(IDictionary<string, object> owinEnvironment)
          {
             // Only admin users can access the dashboard
             var user = new OwinContext(owinEnvironment).Authentication.User;
             return user.Identity.IsAuthenticated &amp;&amp; user.IsInRole(RoleKeys.Admin);
          }
      }
}

All you need to do really is implement the IAuthorizationFilter interface and you are away.

Next, we need to configure our app to use the Hangfire dashboard

I usually just create a static method that sets up the dashboard and adds whatever jobs I need run.

We are using the authorization filter created previously.

public static class ScheduleConfig
{
    public static void ConfigureSchedules(IAppBuilder app)
    {
        // Configure Dashboard
        GlobalConfiguration.Configuration.UseSqlServerStorage("DefaultConnection");
        // I like to use "/jobs" as my endpoint
        // but your could change that to whatever you like
        app.UseHangfireDashboard("/jobs", new DashboardOptions
        {
            AuthorizationFilters = new[] { new HangfireAuthorizationFilter() }
        });
        app.UseHangfireServer();

        // Add jobs
        //...
    }
}

All we need to do now is call our method from within Startup.cs

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        // Other startup config
        //...

        // Call our method to configure hangfire.
        ScheduleConfig.ConfigureSchedules(app);
    }
}

Now (once logged in as admin) you will be able to navigate to the dashboard via http://yourappdomain.com/jobs


Click here to comment

How to get all Content by Document Type in Umbraco

This is probably going to be my shortest post yet. After having messed around with Umbraco for the last few weeks I thought that I would share some code!

How to get all Content by Document Type in Umbraco

OK, straight to it

Please note that on large sites you probably want to cache the results of the method to avoid a performance hit.

public static IEnumerable<IPublishedContent> GetAllNodesByType(IPublishedContent home, string docTypeAlias)
    {
        var foundNodes = new List<IPublishedContent>();
        foreach (var content in home.Children)
        {
            if (content.DocumentTypeAlias == docTypeAlias)
                foundNodes.Add(content);

            // Check recursive
            if (content.Children.Count() > 0)
                foundNodes.AddRange(GetAllNodesByType(content, docTypeAlias));
        }
        return foundNodes;
    }

Click here to comment

Scheduled Job Runner in an ASP.NET MVC App

simple apps do not need the feature bloat

Scheduled Job Runner in an ASP.NET MVC App

I have finally had the chance to build a few apps in vanilla ASP.NET MVC recently. While we still prefer DNN for many use cases, simple apps do not need the feature bloat you get when building on top of DNN. Sometimes in this vanilla context you find yourself missing things that you get for free in DNN.

Scheduled jobs

DNN provides an extremely easy and configurable way to run a task or "job" on a schedule. I needed something similar in an MVC app.

Turns out that it is not as hard as it seems when you break it down.

Find a job runner

First we needed something to actually handle running our recurring jobs. While you could write something yourself, that would be a waste of time considering it is a solved problem. I found a few nifty little libraries and decided that the best one to use would be Hangfire.

Hangfire allows you to easily run code on a schedule as well as monitor them via a dashboard (Hangfire has many many more features).

Discover our jobs

Now you could just use hangfire to run whatever code you want on a schedule off the bat but I wanted my implementation to require no code changes when a new job is needed to be run. You should just be able to write you code and have it run itself.

If I want to create a new job, it would just need to adhere to a contract that I defined. This simply meant creating a interface to act as my "contract"

My Interface:

```

public interface IScheduledJob {

string Frequency { get; }

void DoWork(); }

```

Now that I had a contract, I needed a way to discover all the classes that inherited  from my interface - ie all the "jobs" to register on app startup.

The following method is called in the Startup.Configure method and essentially just finds all the jobs and adds them to a recurring job schedule:

```

private void ConfigureSchedules(IAppBuilder app) { // Configure Dashboard GlobalConfiguration.Configuration.UseSqlServerStorage("DefaultConnection"); app.UseHangfireDashboard("/jobs", new DashboardOptions { AuthorizationFilters = new[] { new HangfireAuthorizationFilter() } }); app.UseHangfireServer();

// Get all types that implement the scheduler interface var jobs = AppDomain.CurrentDomain.GetAssemblies() .SelectMany(s => s.GetTypes()) .Where(p => typeof(IScheduledJob).IsAssignableFrom(p) && !p.IsInterface); foreach (var jobType in jobs) { // Create instance of job IScheduledJob job = (IScheduledJob)Activator.CreateInstance(jobType); // Add job to schedule RecurringJob.AddOrUpdate(() => job.DoWork(), job.Frequency); } }

```

*Note, for more information on the dashboard see the Hangfire docs *

Create a job

OK, now we are cooking on gas. We just need to create a class that inherits from our interface and it will automatically be added to the schedule

An example job:

```

public class TestSchedule : IScheduledJob
{
    public string Frequency
    {
        get
        {
            return Cron.Minutely();
        }
    }

    public void DoWork()
    {
        Debug.WriteLine($"Test Job Ran: {DateTime.Now}");
    }
}

```

Note that we use Hangfire's built in Cron class to define the frequency of our job. These methods simple return a string.

Happy scheduled-jobbing!


Click here to comment