I’ve moved on to Hexo which is essentially a static site generator catered for blogging.
The process was manually moving assets and articles over, but due to the ability of re-creating articles using Markdown, this was a breeze, and much quicker than any WYSIWYG.
Wordpress for my scenario was completely unnecessary:
- -Platform & plugins notification updates, pushing various subscription/paid models
- -Constrained to a smaller viewport when writing, hinders the process
- -Tedious formatting code
- -Backend slow on mediocre hosting (relative to hosting static sites)
- -Not a nice place to spent large amounts of time
Overall I feel that many blogs jump into the online db driven CMS model, but most of the time it’s taking a sledgehammer to crack a nut.
Wordpress locks you out from the most important thing about sharing content, editorial review.
I would encourage anyone reading to have a look at the many SSGs out there:
In this post, we’ll go over image manipulation via creating a pipeline, the goal of this post will be to create avatar, consisting of a user/character, then surrounding this picture with a frame as an overlay.
Rather than using
System.Drawing we’ll instead using ImageSharp which is the most popular image processing library written using .NET Core, it’s very fast and highly optimized, despite being in beta I have used in production for a year without problems.
Using this library, we’ll create our own pipeline of image operations to perform using
IImageProcessingContext, and take advantage of some of heavy lifting ImageSharp provides.
For assets, we’ll be using two images, a base picture and an overlay to surround:
Base picture (me.png)
- Create a .NET Core Console App
- Add the following Package Reference to your .csproj file
<PackageReference Include="SixLabors.ImageSharp.Drawing" Version="1.0.0-beta0007" />If you install through nuget, ensure that
.Drawingis included, else you won’t be able to access the
- Add the assets to your project, make sure you select
Copy if newerin the Properties panel > Copy to Output Directory
The first part of this process is to alter the shape of our user image to something the resembles a diamond.
Below is the code for this, with heavy use of comments elaborating on the process since this is much easier than blog annotations:
The above code results in the following image:
We can achieve our approximate diamond shape via increasing the
cornerRadius float value, however this will result in less of the canvas showing, below is 200:
Side note, if you wanted a circle, all that would be required is to set the
cornerRadius to 50% of the image size.
Currently we’re filling in the areas we’ve clipped with a solid green. Great for testing, but not for our desired result. You will want to comment out the following line which will automatically remove our colour fill.
AlphaCompositionMode = PixelAlphaCompositionMode.DestOut
Next, we’ll add our overlay, this is simpler than the previous code. We’ll embed another
using statement since we still want the original outputs, this makes viewing each stage of the process and making changes much easier whilst we build the pipeline.
Add the following within the
destRound using, after
using (var overlay = Image.Load("frame.png"))
GenerateOverlay is part our pipeline for this project, add the following:
private static IImageProcessingContext GenerateOverlay(this IImageProcessingContext processingContext, Image me)
The above method will draw the image together with the previous image, once that has completed this will be saved to the disk.
It should be noted that the code above is simply a proof in concept, for instance the
Clone methods add overhead and shouldn’t appear in production code.
This is a quick post on an error I encountered whilst opting into the Ivy compiler (which should be here Nov 2019).
Once you get through the initial errors, you may see the below in your console log:
core.js:6014 ERROR Error: Uncaught (in promise): Error: Cannot find module 'src/app/modules/module/your-module.module' Error: Cannot find module 'src/app/modules/module/your-module.module' at $_lazy_route_resource lazy namespace object:5 at ZoneDelegate.invoke (zone-evergreen.js:365) at Object.onInvoke (core.js:39707) at ZoneDelegate.invoke (zone-evergreen.js:364) at Zone.run (zone-evergreen.js:124) at zone-evergreen.js:851 at ZoneDelegate.invokeTask (zone-evergreen.js:400) at Object.onInvokeTask (core.js:39688) at ZoneDelegate.invokeTask (zone-evergreen.js:399) at Zone.runTask (zone-evergreen.js:168) at resolvePromise (zone-evergreen.js:793) at resolvePromise (zone-evergreen.js:752) at zone-evergreen.js:854 at ZoneDelegate.invokeTask (zone-evergreen.js:400) at Object.onInvokeTask (core.js:39688) at ZoneDelegate.invokeTask (zone-evergreen.js:399) at Zone.runTask (zone-evergreen.js:168) at drainMicroTaskQueue (zone-evergreen.js:570) at ZoneTask.invokeTask [as invoke] (zone-evergreen.js:485) at invokeTask (zone-evergreen.js:1596)
You’re getting this error due to Angular 8 introduced a new recommended module loading method, previously the default method of lazy loading modules was to specify a string path to a module:
I couldn’t find an answer for this, so figured a quick post may help someone out on this issue since people are experiencing this.
Initially despite best practice, explicitly setting a version for the Microsoft.AspNetCore.Net package resolved a pipeline library confliction issue, where it could not determine the correct package to restore on the Pipeline side.
Then came the following host of errors:
Error : NETSDK1061: The project was restored using Microsoft.NETCore.App version 1.0.0, but with current settings, version 2.2.0 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore. For more information, see https://aka.ms/dotnet-runtime-patch-selection.
Some people resolved this issue, by specifying their projects to target the latest runtime, however in my scenario, apparently the pipeline still wanted to restore using 1.0.0