DEV Community: Gareth Bradley

Episode 5 - JSON API using ASP.NET Core, Docker & MongoDB - Modelling, Controller and Unit Tests Part I - BookStore

Gareth Bradley — Sun, 17 Feb 2019 00:00:00 +0000

Previously on Dcoding

In Episode 4 I set up our docker-compose files to allow us to knit together our application and the services it will be use. Today’s episode is focusing on Modelling, Controller and Unit Tests for the BookStore Object.

Here is a reminder on the sample User Stories / Epics for phase 1.

As a book store_I can _add our store to the database_So_ we can be accessible

As a book store_I can _add our inventory to our database_So_ we can expose our inventory

As a book store_We can _update a books stock level_For_ an accurate stock level

As a API consumer_I can look up a _stores addressSo we know where to buy a book

As a API consumer_I can look up a _bookSo we can get a list of stores who sell a_book_

As book store IT Security_We can add _API Keys to the API_For_ API Consumers to use when querying the API

Dependency on MongoDB

Our application will ultimately be using MongoDB as its back end data store. We need to take a dependency on the MongoDB driver. This will allow us to communicate with and use MongoDB.

Using your shell of choice, change directory to ../src/api directory. To recap, our directory structure is:

.
    ├── src
    | ├── api
    | |
    | ├── BookStoreApp.WebApi.csproj
    | ├── Dockerfile
    ├── tests
    | ├── integration
    | ├── unit
    | ├── BookStore.Tests.csproj
    ├── docker

Note: Something has changed, can you guess what? Yep that’s right, I have renamed the .csproj to BookStoreApp.WebApi.csproj instead of BookStore.WebApi.csproj.

Now run the following command, which will add the latest Nuget package to your api project.

dotnet add package MongoDB.Driver

We will be returning to MongoDB once we have the unit test infrastructure set up in the next episode.

BookStore

Modelling

The first of our models (the M in M VC), will represent our BookStore. A simple Plain old C# (POCO) to represent this:

/// <summary>
    /// BookStore POCO.
    /// </summary>
    public class BookStore
    {
        [BsonId]
        public ObjectId Id {get; set;}
        public string Name {get;set;}
        public string AddressLine1 {get;set;}
        public string AddressLine2 {get;set;}
        public string AddressLine3 {get;set;}
        public string City {get;set;}
        public string PostCode {get;set;}
        public string TelephoneNumber {get;set;}

        /// <summary>
        /// Default constructor
        /// </summary>
        public BookStore()
        {
            this.Id = ObjectId.GenerateNewId();
        }
    }

I added a Model folder to my ../api folder where this was added. MongoDB uses a serialization format standard called BSON. BSON has the idea of types and one of those types is ObjectId which represents a unique id for the record. You decorate the Id property with [BsonId] attribute, to inform the MongoDB driver what field is your BsonId field.

I have also created a default constructor that sets that Id up. Now we have created the Models directory and structure is now the following:

.
    ├── src
    | ├── api
    | ├── Models
    | ├── BookStore.cs
    | ├── BookStoreApp.WebApi.csproj
    | ├── Dockerfile
    ├── tests
    | ├── integration
    | ├── unit
    | ├── BookStore.Tests.csproj

Controller

Now we need to create a BookStore controller. A controller is the C in MV C pattern. The controller will handle the HTTP requests that come in using Actions. The HTTP requests are mapped to Actions via the routing pipeline of MVC. For WebAPIs, they map to specific HTTP methods like GET, POST, PUT etc.

ASP.NET expects you to follow conventions when creating your own Controllers:

The Controller class name always ends with Controller.
The Controller class should reside in a folder called Controllers.
The Controller class should inherit from Microsoft.AspNetCore.Mvc.ControllerBase (WebAPI) / Microsoft.AspNetCore.Mvc.Controller (ASP.NET MVC Apps with Views).

When you do a dotnet new webapi the templates include a standard ValuesController.cs that lives in a Controllers folder. Create a new BookStoreController.cs file in there:

.
    ├── src
    | ├── api
    | ├── Controllers
    | ├── BookStoreController.cs
    | ├── Models
    | ├── BookStore.cs
    | ├── BookStoreApp.WebApi.csproj
    | ├── Dockerfile
    ├── tests
    | ├── integration
    | ├── unit
    | ├── BookStore.Tests.csproj

To this file I have added the following:

[Route("api/[controller]")]
    [ApiController]
    public class BookStoreController : ControllerBase
    {
        // GET api/values
        [HttpGet]
        public async Task<ActionResult> Get()
        {
            var bookStore = new List<BookStore>{
                new BookStore {
                    Name = "Waterstones",
                    AddressLine1 = "The Dolphin & Anchor",
                    AddressLine2 = "West Street",
                    City = "Chichester",
                    PostCode = "PO19 1QD",
                    TelephoneNumber = "01234 773030"
                }
            };
            return await Task.Run(() => new JsonResult(bookStore));
        }
    }

Its a simple GET method that just returns a hard coded BookStore object. For today’s episode we are just concentrating on getting our unit test infrastructure up and running so we can ignore PUT, POST and DELETE until my next episode.

Unit Tests

Before we move forward we need to use the dotnet tooling to add a project reference to our tests project. Change directory to tests\unit and do the following to add a reference:

dotnet add reference ..\..\src\api\BookStoreApp.WebApi.csproj

I have also added two basic test methods to cover our new GET method in oir controller:

public class ControllerTests
    {
        [Fact]
        public async Task BookStoreController_Get_Should_Return_ActionResult()
        {
            //Arrange
            var controller = new BookStoreController();

            //Act
            var result = await controller.Get();

            //Assert
            Assert.IsType<JsonResult>(result);
        }

        [Fact]
        public async Task BookStoreController_Get_Should_Return_Correct_BookStore_Data()
        {
            //Arrange
            var controller = new BookStoreController();

            //Act
            var result = await controller.Get();
            var json = result.ToJson<BookStore>();

            //Assert
            Assert.True(json[0].Name == "Waterstones",$"Assert failed, received {json[0].Name} ");
            Assert.True(json[0].PostCode == "PO19 1QD",$"Assert failed, received {json[0].PostCode} ");
            Assert.True(json[0].TelephoneNumber == "01234773030",$"Assert failed, received {json[0].TelephoneNumber} ");
        }
    }

Before we start integrating with Docker, we can test using (you guessed it), the dotnet tooling. Make sure you are in the tests\unit directory and run:

dotnet restore
dotnet test

The test will set off a dotnet build first then ran our XUnit tests. One test should fail and this will be outputted similar to this:

Total tests: 2. Passed: 1. Failed: 1. Skipped: 0.

Test Run Failed.

Test execution time: 2.6340 Seconds

The error was intentional, there should of been a space in between "01234773030", I fixed this:

Assert.True(json[0].TelephoneNumber == "01234 773030",$"Assert failed, received {json[0].TelephoneNumber} ");

Re-run the tests and everything should now be green:

Total tests: 2. Passed: 2. Failed: 0. Skipped: 0.

Test Run Successful.

Test execution time: 3.1173 Seconds

Now we have a project with some basic logic within a controller, and a very basic model. We have also started creating some tests to cover this code. Now we need to build and run the application. We could at this stage use the normal route for that, but as these episodes include Docker , lets integrate what we know into a docker pipeline.

Docker

Firstly in the root of the project create a new Docker file. Your project structure should look like this now:

.
    ├── src
    ├── tests
    ├── Dockerfile

Here we will create a multi-stage Dockerfile that will restore, build and run our tests. Here is the first stage:

FROM microsoft/dotnet:2.2-sdk AS build-env
WORKDIR /app

COPY src/api/BookStoreApp.WebApi.csproj ./src/api/
RUN dotnet restore ./src/api/BookStoreApp.WebApi.csproj
COPY tests/unit/BookStore.Tests.csproj ./tests/unit/
RUN dotnet restore ./tests/unit/BookStore.Tests.csproj

COPY . .

You should be familiar with this now from previous episodes. This time take note that we are copying the unit test project files in to the build context. Also note we need to keep the same directory structure as before, because we added a dotnet add reference previously into the test project. If the directories didn’t match we would get build errors.

Run the following:

docker build -t test-ep5 .

Now do a docker image and you will see a massive image there:

Docker has a way of managing this, meet .dockerignore.

.dockerignore

This file behaves similarly to a .gitignore. It tells docker which files to not copying in during a build. So how do you know which files to ignore, well I learnt a good trick from Wes Higbee by passing in a ls alR to list out your directories. Run the following:

docker run --rm test-ep5 ls -alR

This will list out your containers file system, and you can easily see what is copied in. So things like .vscode, .git folders and bin directories. None of this stuff is needed during the build stage of this multi stage Dockerfile, so lets exclude it, using similar glob patterns you can use in .gitignore files. Add a .dockerignore file to your root:

.
    ├── src
    ├── tests
    ├── Dockerfile
    ├── .dockerignore

Then add the following, excluding files and artefacts that are not needed for a restore and build. We exclude things like our docker folder and .ps1 scripts we have been using. Plus the README.md and dockerfiles.

**/.vscode/
**/.git/
docker/
**/bin/
**/obj/
**/.dockerignore/
**/Dockerfile*
**/docker-compose*.yml/
run.ps1
clean.ps1
README.md

Re-run:

docker build -t test-ep5 .
 docker run --rm test-ep5 ls -alR

You will see a cleaner build plus about 100MB less space than previously:

Unit Tests in Docker

So now we have pruned our Image, we can add our tests to our Dockerfile. Add the following into your Dockerfile:

RUN dotnet test tests/unit/BookStore.Tests.csproj
RUN dotnet publish src/api/BookStoreApp.WebApi.csproj -o /publish

We run what we ran on the commandline earlier (see no magic). This will run our unit tests, then if they pass, we will publish a new release ready for our 2nd stage to use, by running dotnet publish and outputting to a new /publish directory.

Run again using the following and see your test success!

docker build -t test-ep5 .

If these unit tests fail, we will see the same as we did previously, so you can see how this all ties in. And just ecause we run our tests in docker, dotnet is still behaving the same. No docker magic.

Running your application

In previous episodes we had a multi stage Dockerfile with a 2nd stage that runs the application itself. No different here, our 2nd stage allows us to run our application.

NB: Once we have added this, we cannot use our “ls aLR” trick Wes taught us, as our ENTRYPOINT will be set with dotnet. Also the 1st build stage is thrown away once used so we cannot access the directory fully anyway.

Add the following to your Dockerfile which is our runtime stage:

FROM microsoft/dotnet:2.2-aspnetcore-runtime AS runtime-env
WORKDIR /publish
COPY --from=build-env /publish .
ENTRYPOINT ["dotnet","BookStoreApp.WebApi.dll"]

Rebuild the Image first:

docker build -t test-ep5 .

Then we can run the Image as a container process, overriding some of the ASP.NET Core environment variables using -e. We would override these usually when using docker-compose.

docker run -e "ASPNETCORE_ENVIRONMENT=Development" -e "ASPNETCORE_URLS=http://+:5003" -p 5003:5003 --rm -it test-ep5

You can then use your application of choice (I’m using Postman, more to come on that) to hit http://localhost:5003/api/bookstore. You should receive the following JSON payload:

[
    {
        "id": "5c6947093497a200016c0dee",
        "name": "Waterstones",
        "addressLine1": "The Dolphin & Anchor",
        "addressLine2": "West Street",
        "addressLine3": null,
        "city": "Chichester",
        "postCode": "PO19 1QD",
        "telephoneNumber": "01234 773030"
    }
]

And thats it, we are slowly starting to move our development and unit test pipeline into docker itself.

Next time

That’s it for today. Remember all code is on Github if you want it.

On our next episode we will start integrating MongoDB into the application.

Raspberrypi Cluster Kubernetes

Gareth Bradley — Tue, 12 Feb 2019 00:00:00 +0000

Creating Raspberry Pi Cluster to Learn Kubernetes

In August 2018 I bought some Pi’s tp create a cluster, mainly after reading and watching Alex Ellis and Scott Hanselman’s blogs and videos on the subject, which inspired me to make the purchase. I was running Code Clubs at the time, so I thought this would make a good show and tell as well.

Both Alex and Scott posts were both inspiring and I really wanted to give it ago. Anyway I got the equipment, but work and real-life got in the way and progress was slow. Then in December 2018 I landed a new job, starting in April this year, and they use Kubernetes extensively so I also had another good reason to get it up and running - to learn Kubernetes!

So this month I finally got it working, including a proper master and node setup:

There were some pain points, like make sure you set up your static IP’s for your Pi’s (and set them up correctly on your router), and more importantly, set up a static IP for the router itself. The yellow box is the picture is the rGL-MT300N-V2 router I went for in the end, and the only bit of Hanselmans shopping list from his post, I diverted from.

My Sons love it

My two sons love it, as we are building Raspberry Pi robots as well in parallel to this. They are interested in what this is doing and why. Sparking curiosity in little minds is important, and me just building websites doesn’t get their juices flowing!

Should I do this?

Yes. :)

Whats next?

Well, learning Kubernetes itself and running some .NET Core container sites. I would like to see how quick the .NET SDK is for building on the Pi’s now, as I would like to experiment with an local build server.

Also, Alex is the creator of OpenFaaS, a cloud agnostic Serverless solution. Having worked with Azure Functions recently at my current job, I can definitely see why this is a good idea. A Serverless infrastructure without being tied down to a specific cloud. I want to explore converting a small Web API app to OpenFaaS and experimenting there (I’m actually super excited).

Lastly, when I restart my Code Clubs up, I would like to do a show and tell with something interesting that includes the cluster. I was thinking about running some OpenFaaS functions that “talk” to my Pi robot I’m building and possibly allow you to control it for example.

Lots to do before April arrives!

Episode 4 - JSON API using ASP.NET Core, Docker & MongoDB - Docker Part II Docker Compose

Gareth Bradley — Mon, 31 Dec 2018 00:00:00 +0000

Previously on Dcoding

In Episode 3 I set up our Dockerfiles for creating our Docker Images for our BookStore app. This will allow us to rapidly test our application as we move forward in later Episodes. Today’s episode is Docker Part 2: Docking Compose.

What is Docker Compose?

The official documentation a good explanation:

Compose is a tool for defining and running multi-container Docker applications.

Docker compose allows you to define your services you need to build and run a full scale application. Think about it, it is not just your application you need. Depending on the type of application you may want:

Database of some sort.
Load Balancer.
Web Server.
Other applications / APIs.

You may even want to run your unit/integration testing during your Continuous Integration pipeline (CI). You could do that with Docker and Compose.

BookStore.WebApi Set up

If we take a look at our application for the BookStore.WebApi, we can see the following:

As you can see from my quickly drawn up diagram (used Microsoft Whiteboard), we have two services running in containers, 1 for the application and the other for the database (MongoDB), so we can compose these together using docker-compose.

docker-compose.dev.yml

So in Episode 2 we set up the Project Structure, so change directory to the ./docker directory.

.
    ├── src
    | ├── api
    | |
    | ├── BookStore.WebApi.csproj
    | ├── Dockerfile
    ├── tests
    | ├── integration
    | ├── unit
    | ├── BookStore.Tests.csproj
    ├── docker

Within that directory, you should have two empty YAML files:

docker-compose.dev.yml
docker-compose.yml

We are concentrating on a Development environment first, so add the following to docker-compose.dev.yml. These files help us define the shape of our services and the dependancies they have:

version: "3"
services:
  webapi:
    image: garfbradaz/bookstoreapi:develop
    container_name: webapi_tutorial_debug
    build:
      args:
        buildconfig: Debug
      context: ../src/api
      dockerfile: Dockerfile
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://+:5003
    ports:
      - "5003:5003"
    depends_on:
      - mongodb
  mongodb:
    image: mongo:latest
    container_name: mongodb
    ports:
      - "27017:27017"

And also, just add the following line to docker-compose.yml file so that when we run docker-compose up it doesn’t fail:

version: "3"

As in Episode 3 lets break this YAML file down now and what we are declaring. These files are YAML and following the normal YAML syntax rules around indenting etc.

`version:`

This is really important. The currently released version (as of December 2018) is 3(.7). You only have to include the whole number within the version number field within the YAML file. Each major upgrade (from 1.x, to 2.x, to 3.x) brings about possible breaking changes, including syntax changes to the YAML structure itself.

Also the version of Compose relates to the version of the released Docker Engine so have a good read of the Compatibility Matrix, but usually you pick the latest version.

`services:`

Docker services is where you define each application. So we have two services defined:

webapi: which is our ASP.NET Core BookStore.WebApi application.
mongodb: which is the back-end data store, MongoDB.

`image:`

Each service has an image defined. Mongo’s mongo:latest will be pulled directly from hub.docker.com.

Our own will be built locally for now (until we publish it later) and its simply called garfbradaz/bookstoreapi:develop. Note the tag of develop. We now have denoted our debug image, and we can add things like symbols etc for debugging purposes.

`container_name:`

This is just a nice friendly name for our container. You can see the name when you run docker ps after you have run a container.

Run your applications

Docker compose has a command docker compose up, which allows you to (re)build, (re)create and attach containers for the service. You run the command using the following (make sure you are in the ./docker directory):

docker-compose -f docker-compose.dev.yml up -d --build

This command overrides the file (-f) to docker-compose.dev.yml and runs up. The containers will run in detached mode (-d) and run in the background. We will also (re)build the images (--build). Because we have a build section in our docker-compose.dev.yml file for our code those values will be used. We set the context (../src/api) which is the relative directory to the source code we are building (Relative to the ./docker directory), plus tell docker-compose the Dockerfile name.

We also send in some args into the Dockerfile. Currently we ignore these, but we will be coming back to them later in this post.

Lastly we set some environment variables for our application/ASP.NET Core to use. Specifically around setting up a Development environment and HTTP URLs.

Note: If we dont set these, our application will try and use HTTPS because that is the default now (which is a good thing). Because we haven’t set any self-signed developer certificates up yet this will become a bit of a pain. We will do it, but to get up and running, we are switching off HTTPS for now.

We also pull down a MongoDB image and start a new database, listening on port 27017. This is the standard port mapping for MongoDB.

This command will also create a default network for your applications to live in. Normally named after the directory docker-compose is run with a postfix of default. So mine is docker_default.

Check the containers are running

You can now run a docker ps on your commandline of choice. You should see your webapi_tutorial_debug and mongodb ( Hint: container_name you set in the docker-compose.dev.yml file).

Stop containers

When you have finished you can clear up your containers by running the following, which will stop and remove the containers networks created for this service:

docker-compose -f docker-compose.dev.yml down

Powershell Scripts (Optional)

I have created two powershell scripts that automate this. You just need to run them in the root of the project:

Run containers

.\run.ps1

Close and clean containers

.\clean.ps1

Powershell Core is now cross platform as well so you can install Powershell Core and use these scripts on Mac and Linux boxes if you wish.

Debug Arguments

Previously I mentioned we set a arg called buildconfig to Debug. We haven’t used this so far. But we will now. I use this to build a debug version of our ASP.NET Core BookStore.WebApi app, so we can debug into the container using vsdbg.

Have a read of my article Debug .NET Core in Docker about what this is. For this article, change directory to ./src/api and make sure your Dockerfile looks like this:

FROM microsoft/dotnet:2.2-sdk AS build-env
ARG buildconfig
WORKDIR /app
COPY BookStore.WebApi.csproj .
COPY . .
RUN env
RUN if ["${buildconfig}" = "Debug"]; then \
        dotnet publish -o /publish -c Debug; \
    else \
        dotnet publish -o /publish -c Release; \
    fi 

FROM microsoft/dotnet:2.2-aspnetcore-runtime AS runtime-env
ARG buildconfig
ENV DEBIAN_FRONTEND noninteractive
WORKDIR /publish
COPY --from=build-env /publish .
RUN if ["${buildconfig}" = "Debug"]; then \
        apt-get update && \
        apt-get install -y --no-install-recommends apt-utils && \
        apt-get install curl unzip procps mongodb -y && \
        curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l /publish/vsdbg; \
     else \ 
        echo "*Whistling*"; \
    fi 
ENV DEBIAN_FRONTEND teletype
ENTRYPOINT ["dotnet","BookStore.WebApi.dll"]

Next time

That’s it for today. Remember all code is on Github if you want it.

Now we have our architecture spun up and ready, we can start building some ASP.NET Core code (using C#) to start creating our Models for our BookStore.WebApi. We will also start creating some unit tests and creating the shape of our API.

Episode 3 - JSON API using ASP.NET Core, Docker & MongoDB: Docker Part I, Dockerfiles

Gareth Bradley — Sat, 29 Dec 2018 00:00:00 +0000

Previously on Dcoding

In Episode 2 I set up the project directory structure. Today’s episode is Docker Part 1: DockerFiles.

Lets talk about Docker

Firstly before we get into how to set up Docker, I want to get into bigging the big D up! Apart from Visual Studio Code and WSL, no other technology has transformed how I develop code in 2018. Yes there are pain points, but once you get through those, then your development experience starts (i dare say it) become a little more blissful.

I can now pull down pre-developed images of applications, databases, load balancers, webs servers, SDKs build tools, pixie dust (nic: testing you are still reading!), and use them like lego bricks, to build a system, without installing the binaries on my machine.

Take this tutorial for example, apart from the .NET SDK installed for the IDE, MongoDB, nginx and the dotnet runtime are all installed via images, for which I can build and throw away when finished. No installation needed on my local development (host) machine. Even SQL Server runs on Linux now, and has a Image to pull down.

This Lego Brick approach to building software now means I dont need to worry about installing all the tools on my machine, configure those tools and un-install when finished. I can package it all up in a Dockerfile to use now, later or even on another machine, without polluting my host machine and slowing it down.

What is Docker?

Docker is product that utilises a technology containers, which have been around in Linux for a while. Containers are isolated/sandboxed processes, which only use the bare minimum binaries needed to run the application within the container, including the file system. Unlike Virtual Machine which run a whole operating system, and the bloat around it.

Now as I was writing this post, Dave Swersky, wrote an awesome post on What is Docker, and why is it so popular?. Check that out.

Dockerfile

If this is the first time you have used Docker, or you do not have it installed, check out dockers getting started to start your journey. You will need to sign up to Docker Hub(https://hub.docker.com/) as well. Think as hub as the repository for Container Images you can access. Not just Dockers, but the communities as a whole. You may here the term Container Registry for the Hub as well (You can set up your own private Registries on Azure for example).

So a couple of commands and terminology we need to clear up, which are useful now before moving forward.

Help

So the docker command has a nice help facility, so if you want to see a list of docker commands:

docker --help

Images

A image is the package that includes everything needed to run your application, from the environment, code and configuration. You normally use other companies/communities/developers pre-built images from the hub or base images, but you can create your own just as easily.

If you want to see which images you have on your host machine (your development PC/Mac), then run the following command:

docker images ls

If this is all new, then nothing will be listed currently, but when we start building our Dockerfile, we will come back to the output on what this means.

Containers

The container is your image running in a discrete process. You can have multiple containers running on your host machine. Again there is a command to see what containers are running:

docker container ls

You can also use the short cut (One I personally use a lot):

docker ps

Develop first Dockerfile

What is a Dockerfile then? Here is a good description from Docker themselves:

Docker can build images automatically by reading the instructions from a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Using docker build users can create an automated build that executes several command-line instructions in succession.

To begin with, we will build our first Dockerfile to:

Compile our .NET Core Web API for the BookStore.
Run our .NET Core Web API.

We call Dockerfiles that do more than one thing, multi-stage builds. They allow us to build and run without maintaining separate Dockerfiles (which was the case once upon a time). Because I don’t learn this stuff on my own, let me link to Alex Ellis talking more about this.

Future Post: While I’m chatting about Alex, in the future I will be refactoring this BookStore.App to use OpenFaaS an open source serverless architecture that isn’t coupled to one particular cloud. I’m excited about this, as I have wanted to use this tech for a while now, I even have the Raspberry Pis to cluster…..

So, back to the matter at hand. Firstly we need to change directory to src/api directory we set up in Episode 2. Just to recap we set up the following:

.
    ├── src
    | ├── api
    | |
    | ├── BookStore.WebApi.csproj
    ├── tests
    | ├── integration
    | ├── unit
    | ├── BookStore.Tests.csproj
    ├── docker

Then create a file called Dockerfile in the root of api:

.
    ├── src
    | ├── api
    | |
    | ├── BookStore.WebApi.csproj
    | ├── Dockerfile
    ├── tests
    | ├── integration
    | ├── unit
    | ├── BookStore.Tests.csproj
    ├── docker

Add the following to the file:

FROM microsoft/dotnet:2.2-sdk AS build-env
WORKDIR /app
COPY BookStore.WebApi.csproj .
COPY . .
RUN dotnet publish -c Release -o /publish

FROM microsoft/dotnet:2.2-aspnetcore-runtime AS runtime-env
WORKDIR /publish
EXPOSE 5000
COPY --from=build-env /publish .
ENTRYPOINT ["dotnet","BookStore.WebApi.dll"]

If this is new to you, then let me explain the format on this file and what it means.

FROM

This statement sets the base image created by Microsoft (or any organisation who has created an base image) and creates a new build stage (each FROM creates a new stage). These images will live on a public repository like hub.docker.com. So make sure you have logged in via Docker Desktop otherwise the first build step will fail.

Having multiple FROM denotes a multi-stage Dockerfile.

microsoft/dotnet:2.2-sdk - SDK image. This base image is designed to allow you to build/publish using the dotnet CLI. As you can see I’m using the 2.2 .NET Core Version (denoted the common tag name of :2.2-sdk ).
microsoft/dotnet:2.2-aspnetcore-runtime - Runtime image. This base image is designed to run a ASP.NET Core application using the dotnet runtime. Again it follows the same format with denoting the dotnet version by the common tag of :2.2-aspnetcore-runtime.

WORKDIR

This statement will create a directory for the following statements will work in. If the directory exists, then the directory is just set to the value in WORKDIR. In our case /app is created by the command and /publish is set to (as publish is created in the dotnet publish).

COPY

This statement will copy the files specified into the containers file system (normally into the file system specified in WORKDIR) from the host machine of the directory where the Dockerfile is placed. So in our instance, the ../src/api directory.

Note: We have two COPY commands in the build stage of our Dockerfile context. We do this for the BookStore.WebApi.csproj so that we have a build cache entry for this file, so if it hasn’t changed, we dont copy it on every build (reduces build times). Also COPY . . will copy everything else.

COPY BookStore.WebApi.csproj .
COPY . .

Our 2nd stage actually copies the output from build-env /publish directory into the next stage.

RUN

This statement will run a set of commands that will create another layer in your image and commit the results, which will form part of the container. It allows you to set up your container before running it.

Our example is the dotnet publish will be RUN as part of the docker build instruction set, creating the binaries to use when we dotnet using the published .dll.

ENTRYPOINT

This statement defines what is run when you docker run and start the container. Our ENTRYPOINT runs the dotnet command using our published .dll. You can pass more parameters into the ENTRYPOINT command via docker run.

Our multi-stage Dockerfile builds our source code in the first stage and copies the published output so that it is run using the .NET Core Runetime.

Build the Image

Now we have a Dockerfile, we can build this file into an image which will be stored locally on our host. Make sure you are on the commandline of choice, and change directory to ../src/api and run the following command:

docker build -t garfbradaz/ep3-api .

This command will run a docker build. The “.” signifies you want to use the Dockerfile in the current directory and -t garfbradaz/ep3-api is a parameter that will build an Image with a [-]tag name of garfbradaz/ep3-api. You can replace this string with anything you want.

The first time you run this will take a while, because there will be no cache entries from previous builds for your layers. You can also see all the layers that are built from the Microsoft base images which are made up of layers also:

If you run a docker images again you will now see your image has been built (plus the .NET Core Images):

Run the Image as a Container

So, we have created a Dockerfile that includes the steps to build an image, which includes the resources needed to run the application within a container. This is the magic, as we can run this image on any OS that supports Docker itself (If we are building Linux containers).

So the following will run your container as isolated/sandboxed process:

docker run --env ASPNETCORE_ENVIRONMENT=Development --env ASPNETCORE_URLS=http://+:5000 -p 5000:5000 -t --rm -it garfbradaz/ep3-api

This command will run your Container interactively (-it), and override some environment variables (--env); overriding port mapping to 5000 (-p) and clean up the container with finished (--rm).

I use Powershell to validate the container is running fine, but you can use postman (we explore setting this up in another chapter).

Invoke-RestMethod -Uri http://localhost:5000/api/values -Method 'Get'

This should fail with a 401 status, because we set up the [Authorize] attribute against the ValuesController.cs. But at least this proves we are hitting the Web API running using Kestrel within the Container process.

Next time

We will be exploring docker compose to allow us to run and knit together multiple containers together so we can interact with MongoDB for example.

Release Notes: Update 1

Gareth Bradley — Sat, 29 Dec 2018 00:00:00 +0000

Release Notes - Update 1

Whenever I do an update to this blog itself, I will be providing some Release Notes on changes, including where possible, what I have done, as this may be helpful to someone else.

Version Notes

I was going to use a proper Semantic Version (SemVer) for the site, but decided just to do incremental number releases (like Chrome). Just, well because!. No other reason than ease.

Blog Post Comments

I have now switched on comments using the service Disqus for which you can sign up for free. Because Jekyll doesn’t have a back end data store, this made the most sense to me (& Disqus has good support).

How did I do it? Well this is my site, so you may need to add it different places depending on your site structure, but I followed the standard Jekyll site creation for Github Pages, the structure is what I would call vanilla.

Sign up to Disqus.
Take note of the the shortname you create for your site.
Edit your _config.yml and add the following:

disqus:
    shortname: <replace-with-your-short-name>

Create a comments.html and and save it to your _includes directory with the following snippet. This is the embedded code provided by Disqus:

<div class="comments">
        <div id="disqus_thread"></div>
        <script type="text/javascript">
            var disqus_shortname = 'garfbradaz';
            (function() {
            var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
            dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
            (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); })();    
        </script>
    <noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
    </div>

Add a reference to comments.html to your posts.html. Add the following to the bottom of the posts.html (or whatever your HTMl file is called):

{% include comments.html %}

You need to turn a comment on using the following Front Matter value in each post file:

comments: true

Rebuild your posts:

bundle exec jekyll build

Voila, you will have a nice comment at the bottom of your page:

Episode 2 - JSON API using ASP.NET Core, Docker & MongoDB: Project Structure

Gareth Bradley — Wed, 19 Dec 2018 00:00:00 +0000

Previously on Dcoding

In Episode 1 I set the scene for what this series will contain. Today’s episode is simply on setting your directory structure and creating the relevant projects.

Directory Structure

Firstly, create a directory structure for your Source (src) where our dotnet projects will be saved, tests will hold our Unit and Integration tests and lastly, docker which will hold our docker-compose.

    .
    ├── src
    ├── tests
    ├── docker

Src

Change directory to src and we will run the following dotnet command to new up a Project. Before we move on any further and do that though, lets talk about dotnet new for people who have not used it.

This command will create a dotnet project based off a default project template. You get a bunch of defaults with the SDK (and you can create your own. Run the following:

dotnet new --help

This will give you a list of available templates you can use:

Take note of the short name as this is what we will be using next. So now we know what dotnet new does, lets create the project:

dotnet new webapi --auth Individual -o api -n BookStore.WebApi

This will create a folder with the name api and in it will create a new webapi project using authentication (we will explore this more in a later episode). The project will be called BookStore.WebApi.

Tip: You can do a dotnet new webapi --help and see all the available switches for that short name.

Your directory structure should look like this now:

    .
    ├── src
    | ├── api
    | |
    | ├── BookStore.WebApi
    ├── tests
    ├── docker

Tests

Change directory to the tests folder. Firstly mainly create a integration test folder. These will hold our Postman tests (again for another episode). Secondly, we need to create our Unit Test project. I will be using Xunit, but as you can see, there were a few different projects for testing when you did a dotnet new --help.

dotnet new xunit -o unit -n BookStore.Tests

Again this will create a xunit project type within a folder called unit. The project name will be BookStore.Tests. Within the integration folder just add an empty postman.json file.

    .
    ├── src
    | ├── api
    | |
    | ├── BookStore.WebApi
    ├── tests
    | ├── integration
    | ├── unit
    | ├── BookStore.Tests
    ├── docker

Docker

Change directory to docker folder and for now just create two empty files:

docker-compose.yml

docker-compose.dev.yml

Yes you guessed it, this files will become apparent (and fatter) in a future episode.

Next time

So now we have set up our Project directory structure, we can move on to setting up our Docker environment, using Dockerfiles and docker-compose. Join me next time.

Side note: Episode 1 can be found on my Github Repository

Episode 1 - JSON API using ASP.NET Core, Docker & MongoDB

Gareth Bradley — Tue, 18 Dec 2018 00:00:00 +0000

Inspiration

There is a series on dev.to that I have followed by Nathan Bland who has recorded as series of videos around creating a JSON API, using Node.js, docker and Express.

I liked the idea around this, so I’m going to do the same, but in a blog style, but replacing Node.js and Express with ASP.NET Core WebAPI. I also want to use a MongoDB as a the backend.

Set the Scene

The API itself will be for a Book Shop Chain who want to expose their stores and titles via a public RESTful service for other companies to use. This can be used for stock lookups and to see which stores have stock available to sell.

Here are some example Epics to show the shape of the API needed:

As a book store_I can _add our store to the database_So_ we can be accessible

As a book store_I can _add our inventory to our database_So_ we can expose our inventory

As a book store_We can _update a books stock level_For_ an accurate stock level

As a API consumer_I can look up a _stores addressSo we know where to buy a book

As a API consumer_I can look up a _bookSo we can get a list of stores who sell a_book_

As book store IT Security_We can add _API Keys to the API_For_ API Consumers to use when querying the API

What to expect

My plan is to release weekly blog posts covering in a similar fashion like Nathan’s:

Setting up your .NET Core Project Structure.
Setting up docker environment using docker-compose.
Modelling API JSON back end using Mongo.
Modelling API using Swagger.
Unit Tests with Xunit.
Integration Tests with Postman.
Skeleton Book Store API (Routes etc).
Skeleton Inventory API (Routes etc).
Securing your API.
Data validation.
Pagination for large data queries.
Filter and Search.
Hooking up to Azure Dev Ops for Build and Release Pipeline.
Publisher Swagger Documentation on Github.

I will post any code on Github as well.

Start at Zero

So before starting cracking on with this, make sure your environment is set up. Because this is .NET Core, this is cross platform, so if you own a Mac or Linux box, feel free to join in. I’m going to be building this on a Surface Book, but I will try to be a good Xpat-Citizen and test across environments.

Please make sure the following is installed:

Dotnet Core - I’m currently using 2.2.
Docker - You will need to also create a login for Docker Hub if you do not have one.
Powershell Core - PowerShell Core is cross-platform and runs on Windows, Linux, and MacOS while the old one runs on Windows only(CLI). There are options to install on the OS of choice.

We wont need to install Mongo as we will be running it using Docker.

IDE

I will be using Visual Studio Code for cross platform .NET Core support. I use a bunch of extension which I have put here:

https://gist.github.com/garfbradaz/be010080df076d19892bf4ec71127b53

You can import these using the following Settings Sync extension on the marketplace:

https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync

If you already use VSCode, you may just want to find the C#, Docker GitLens and .NET Core Test Explorer extensions.

Note: My list contains extensions like Jekyll support which you wont need for this.

Next time

We will create the ASP.NET Core WebAPI template, set up the project structure. Join me next time!.

Debug .NET Core In Docker

Gareth Bradley — Thu, 13 Dec 2018 00:00:00 +0000

Debugging ASP.NET Core in a Linux Docker with Visual Studio Code

So, you have started using Docker for your .NET Core applications - awesome news. You are using Linux Containers, and Visual Studio Code, and you then go to Debug your container…..oh. (I’m using Windows).

Its not the most straight forward process I have found, if you are looking at getting this up and running. Firstly I didn’t figure this out on my own, the reason I’m blogging about it is because I meshed together the knowledge I had, plus these very informative posts:

It was the above two posts that glued it together for me. Have a good read of those as well. Before we go any further, just to confirm these instructions are for Visual Studio Code and Linux Containers using Docker Compose, I’m not sure how this is set-up on Visual Studio. I’m presuming you have VSCode, Docker and .NET Core SDK installed. And you are using Linux Containers.

DockerFile

Firstly lets look at my multi-staged (Multiple FROM) Dockerfile for building my project.

1st Stage Build

The first part of the Dockerfile build-env stage, takes an ARG of buildconfig, which controls how the dotnet publish is configured. And yes I know, I have a todo item to refactor the if/else to just pass the buildconfig as a -c value.

2nd Stage Run

So the 1st stage handled the build, the 2nd handles the running of the Web API project. As you can see, there is a Debug switch again, to install some dependencies when running in Debug. Ignore the mongo installs, it is the vsdbg installation We are interested in.

curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l

The debugger platform has been expanded between Visual Studio 2017 15.3 and previous versions of Visual Studio. Visual Studio can now communicate using the debug adapter protocol which is used by Visual Studio, Visual Studio Code and Visual Studio for Mac. This protocol is now used for debugging cross-platform .NET Core applications.

Source

So vsdbg is installed into the container to allow remote debugging from your host machine using Visual Studio Code.

FROM microsoft/dotnet:2.2-sdk AS build-env
ARG buildconfig
WORKDIR /app
COPY ServiceApp.WebApi.csproj .
RUN dotnet restore
COPY . .
RUN if ["${buildconfig}" = "Debug"]; then \
        dotnet publish -o /publish -c Debug; \
    else \
        dotnet publish -o /publish -c Release; \
    fi

FROM microsoft/dotnet:2.2-aspnetcore-runtime
ARG buildconfig
ENV DEBIAN_FRONTEND noninteractive
WORKDIR /publish
COPY --from=build-env /publish .
RUN if ["${buildconfig}" = "Debug"]; then \
        apt-get update && \
        apt-get install -y --no-install-recommends apt-utils && \
        apt-get install curl unzip procps mongodb -y && \
        curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l /publish/vsdbg; \
     else \
        echo "*Whistling*"; \
    fi
ENV DEBIAN_FRONTEND teletype
ENTRYPOINT ["dotnet","ServiceApp.WebApi.dll"]

Launch Task Configuration for Visual Studio Code

So this was the bit I struggled with, to the point I logged a Github Issue and subsequently had a light bulb moment afterwards!

Both Jonathan and Richards work and investigations for their posts, again helped tenfold.

Important bits are the sourceFileMap which map your projects code to the binaries in the Container. The /app in reference in mine, relates to the /app directory declared in the Dockerfile.

The other important snippet is the debuggerPath option. This is the directory where vsdbg has been installed within your Container. You can set different directories within your curl command in the Dockerfile if you so wish.

Lastly, note the Container name of webapi_debug, I set this up in the relevant compose file.

The below will live in a launch.json in your .vscode directory. If configured correctly you should get a nice launch icon:

{
    "name": "Attach to webapi (Docker)",
    "type": "coreclr",
    "request": "attach",
    "sourceFileMap": {
        "/app": "${workspaceFolder}/src/api"
    },
    "processId" : "${command:pickRemoteProcess}",
    "pipeTransport": {
        "debuggerPath": "/publish/vsdbg/vsdbg",
        "pipeProgram": "docker",
        "pipeCwd": "${workspaceFolder}/src/api",
        "quoteArgs": false,
        "pipeArgs": [
            "exec","-i", "webapi_debug"
        ]
    }
}

Composing

Because I’m using separate Docker containers for MongoDB and Identity Server I use docker-compose to knit together my containers.

Note: I’m planning on doing a Identity Server post next on my experiences in getting that set-up.

The below is from my docker-compose.dev.yml file.

So the container with the interesting configurations is webapi which is my ASP.NET Core Web API project. As you can see I set the container name to webapi_debug is set. As I mentioned before, the launch task needs that to remote into that particular container.

You can also see I mount my Source Code directory from my host Windows machine using volumes using a relative path to my source code directory (../api) to :/app, allowing us, when a breakpoint is hit, for the code to be shown. If you configure this bit wrong, you will get the following error when the breakpoint is thrown:

The other interesting config points, are the ASPNETCORE_ * environment variables for Development and the buildconfig argument of Debug, which as we learnt previously, is passed into the Dockerfile and used.

version: "3"
services:
  identity:
    image: garfbradaz/serviceident:develop
    container_name: identity
    build:
      args:
        buildconfig: Debug
      context: ../quickidentity
      dockerfile: Dockerfile
    volumes:
      - ../quickidentity:/app2
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://identity:5002  
      - AuthorityUrl=http://identity:5002
    ports:
      - "5002:5002"
  webapi:
    image: garfbradaz/serviceapp:develop
    container_name: webapi_debug
    build:
      args:
        buildconfig: Debug
      context: ../api
      dockerfile: Dockerfile
    volumes:
      - ../api:/app
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://+:5001
      - AuthorityUrl=http://identity:5002
    ports:
      - "5001:5001"
    depends_on:
      - mongodb
      - identity
  mongodb:
    image: mongo:latest
    container_name: mongodb
    ports:
      - "27017:27017"

Running

So put this all together you can run your containers using the Compose:

docker-compose -f docker-compose.dev.yml up -d --build

Set a breakpoint in your code (Example I set in my Controller), and run your debug task in Visual Studio Code. This will ask you to pick your process for your dotnet code. Then when the breakpoint is hit, you can inspect it as normal.

I find that it can hang and take half a minute sometimes for the debug session to initiate, so bear with it.

Anyway I hope this helps someone, and a massive thank you to Jonathan and Richard.

Setting Up Github Pages Jekyll And Using Windows Subsystem For Linux

Gareth Bradley — Wed, 12 Dec 2018 00:00:00 +0000

Setting up Github Pages, Jekyll and using Windows Subsystem for Linux

The 1st how to for setting up the blog and tools needed to edit it. I’m a Windows fan (I love my Surface devices), but I’m also starting to appreciate Linux, so this is a perfect opportunity to set up my Surface Book to use Windows Subsystem for Linux, which allows you command line access to Linux. I’m assured this is not a virtual machine, but a syscall mapping between Windows and Linux itself, to actual Linux binaries themselves.

I’m going to provide the instructions on how I set up my Surface Book. You may want to tweak these to your needs.

NB: I originally posted this blog post December 2018 so if anything has changed or doesn’t work, let me know.

WSL Set up

Windows Subsystem for linux needs setting up. If you have done this previously, then skip to code instructions

Use Powershell Windows Subsystem for Linux (WSL), make sure you Run as Administrator:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
The prompt will ask you to restart your machine, so make sure you save anything before pressing Y :
Use the Windows Store to install your favourite Linux Distro. I chose Debian. More information here

Visual Studio Code

Again if you have installed this previously, then jump to Jekyll.

I’m a great VSCode advocate, mainly from using .NET Core and C#. But I’m using TypeScript a little and using it more and more. I actually get a little sad face when I realise I need to use Visual Studio Enterprise for anything now (Usually because Razor support isn’t the best in Code, but improving).

I’m going to use Visual Studio Code to allow me to compose and edit markdown. Its the perfect editor because:

The IDE is cross platform, so you can look after your blog within the IDE across any platform.
It has git out of the box.
Various Markdown extensions for extending the experience.
Markdown Preview, so you can view how your post will look. -I will do a separate post on my Visual Code extension set up.

Download and install Code here.

Install Jekyll on WSL

As I mentioned previously, I installed Debian, so the instructions I’m giving are for Debian. More more information see here.

Firstly open a bash Window. I fired up Debian app I just installed.
Install dependencies for Ruby:

sudo apt-get install ruby-full build-essential
Now, I got the following error when I ran this on Debian:

Reading state information… Done
E: Unable to locate package ruby-full
E: Unable to locate package build-essential
Essentially the sources.lst is missing the deb-src links to the repository.
Use sudo nano /etc/apt/sources.list to edit the file and add the missing entries. Here is my file
Run sudo apt update.
Re-run step 2. If this works, move on.
Add the environment variables for gems for when bash is run interactively:

echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc
echo 'export GEM_HOME=$HOME/gems' >> ~/.bashrc
echo 'export PATH=$HOME/gems/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
Install Jekyll and bundler using gem install jekyll bundler.
Confirm you have GCC and Make available:
```
    gcc -v
    g++ -v
    make -v
```

Install Git on WSL

You may already have Git for Windows set up on your Windows instance, but you will need to make sure Git is on WSL as well. Follow these instructions.

Install git:

sudo apt install git
To validate it has worked, run git version.

Set up standard email and username details:

     git config --global user.email "your@email.com"
     git config --global user.name "your username"

As described here, need to set your line endings correctly.

git config --global core.autocrlf input

Create Github Repository

There are different steps that need taking when creating your repository. Firstly the repository names needs to be a specific format:

your-github-username.github.io

You can find your username my navigating (top right) click Your Avatar->Your profile. Example mine is garfbradaz:

![me](https://garfbradaz.github.io/assets/img/posts/me-github.png)

So mine is garfbradaz.github.io.

You can select a Jekyll theme as well also. This is saved to the _config.yml file in your repository. This can be changed at a later date.
Once the site is published, your repository name is your URL for your new site:

my site

Update Github with generated SSH using WSL

Run the following in WSL bash terminal to generate a key, replacing the email with yours that you use for Github:

ssh-keygen -t rsa -b 4096 -C <your@githubemail.com>

Press Enter to accept the default directory, and add a pass phrase.

Add the SSH private key to ssh-agent so that you dont need to write the pass phrase each and every git commit:

ssh-add ~/.ssh/id_rsa

Note: This is using ~ which is fine as we are within a Linux bash terminal.

Run the following to Print tne RSA key to the screen. Then using your mouse, copy to clipboard:

cat ~/.ssh/id_rsa.pub
Navigate to github in your browser of choice.
Click on Your profile.
Click on SSH and GPG keys.
Click on button New SSH Key.
Give the key a meaningful title.
Paste RSA key.
Click on Add RSA key.

Clone the Site to WSL

Firstly run Visual Studio Code.
Open a Terminal within Visual Studio code. One option for doing that is Menu->Terminal->New Terminal.
Then run bash.
Something important to note. After you run bash, you will be greeted with a directory prefixed with /mnt/c. This means the drive is mounted and mapped to C:\. You can prove this by doing a ls. Look at all those familiar Windows files:

Note: cd ~ && pwd isn’t your traditional home directory, so dont place any files in here you want Windows to access. This DOES NOT map to your Windows Home directory. If you edit this Linux Only Windows files, you will corrupt your Linux install.

Basically it is safe to use the /mnt/c.

With that in mind, navigate to the folder you wish to clone your Jekyll repository, here is an example for mine (You do this in the same bash terminal you created in Visual Studio Code):

cd /mnt/c/code/blog

This is the following Windows directory:

> C:\code\blog

Git clone into this directory:

git clone <your-repository-url> .

And because you are within Visual Studio Code, the files will appear straight away:

![files appear in VSCode](https://garfbradaz.github.io/assets/img/posts/git-in-vscode.png)

Now create a file called Gemfile and add the following (root of the directory):

source ‘https://rubygems.org’ gem ‘github-pages’, group: :jekyll_plugins

As you can see VSCode recognises up its a Gemfile and uses a nice Ruby icon.

Now create the dependencies. Within the bash terminal within Visual Studio code run:

bundle install

Note: At this stage for Debian, I found there was an error installing nokogirl-1.8.5 dependencies.

I resolved this by running the following, then re-running bundle install.

`sudo apt-get install libpng-dev`
`sudo apt-get install --reinstall zlibc zlib1g zlib1g-dev`

(Optional) Modify Layout of Theme

If you want to amend the layout; add your own styles or navigation, then you need to check your themes repository for instructions on how to update (each may have different instructions).

The URL scheme for the repositories is:

> https://github.com/pages-themes/<your-selected-theme></your-selected-theme>

So mine is:

https://github.com/pages-themes/minimal

Update _config.yml

Update your title and description for your blog.

> title: Gareth Bradleys Blog

> description: garfbradaz new blog, hosted on github

Release, Release, Release...

After you have proof read it and checked obviously. The beauty of Jekyll is you to publish your blog, you just use the git skills you (may) already have, so run the following in bash while in your repository where your .git folder is:

git add .

git commit -m "Start of life for my awesome blog - Arise!"

git push origin

Next time…

I will talk about How to Add Google analytics and How to publish your first post all in Visual Studio Code.

I haven’t written this blog post without help. I would like to shout out to the following blogs and documentation for assisting me:

Arise New Blog

Gareth Bradley — Sat, 07 Jul 2018 00:00:00 +0000

It’s alive!

I have wanted to move my current off Wordpress for sometime, but time has always been a factor. As a developer I find myself living within Visual Studio Code, so I decided to set up a blog which can:

Use my Visual Studio Code
Use my git skills

I knew github has Github Pages, and it used Jekyll. So I have started a Github page. So this is day one. I chose a minimal theme for the site, and each change to the site I will document as a blog post. Think of them as Release Notes!

As I move on I change the style and layout etc, but for now (and posterity) here is the Home Page from day 1:

Source Post