Forem: Stephen Walsh

Full Stack Engineers Don't Exist!

Stephen Walsh — Fri, 03 Nov 2023 16:27:32 +0000

There's a problem with those thousands of jobs available for Full Stack Engineers or Developers on LinkedIn, like a unicorn, that person isn't real. Insert spit-take, read it, then tell me what you think.

There I said it, you might think this is a controversial or unpopular opinion but if you hear me out maybe you'll agree with me, maybe not, but that's what makes life worth living. I've believed this for a long time now, but it's time to put a little more thought and time to flesh it out.

As for the term Developer or Engineer, yes technically they have different scopes but they mostly cover the same disciplines and principles, so I'll use them interchangeably from here on out.

Defining a Full Stack Developer

To say something doesn't exist, I should probably first define what people think it is. So Looking across the internet to

A full-stack developer is a developer or engineer who can build both the front end and the back end of a website. The front end (the parts of a website a user sees and interacts with) and the back end (the behind-the-scenes data storage and processing) require different skill sets. Since full-stack developers are involved with all aspects of the development process, they must have expertise in both.
Coursera - What Is a Full-Stack Developer?

A full-stack developer can be defined as a developer or an engineer who works with both the front and back end development of a website, web application or desktop application. This means they can lead platform builds that involve databases, user-facing websites, and working with clients during the planning phase of projects.
Wikipedia - Solution Stack - Full Stack Developer

This sounds reasonable, which has led to the rise of this term to become part of engineering culture. This may have been reasonable but the world isn't run by the LAMP stack anymore, the role of a software engineer isn't as simple as it once was.

Demands on the Modern-Day Software Engineer

Being an engineer isn't as simple as writing code anymore. The definitions above hint at it but the expectations of what an engineer is capable of has grown exponentially over the last few years. Every day is different, and every workplace is different, but the point remains that software engineering is a much larger beast than it once was.

Not even covering all bases, the engineer finds themselves; defining work, estimating work, writing test cases, writing unit or integration or e2e tests, creating or coding build and/or deployment pipelines, defining metrics for monitoring, analyzing application logs, bug fixing, designing solution or system architecture, creating infrastructure as code and commiting, merging and rebasing code. Notice I didn't even mention the actual work of writing the code to deliver features. Now cover those bases across data storage, backend systems, and frontend applications.

Maybe a "developer" doesn't get as full a scope as the "engineer" but it's pretty similar. The point here is the expectations of engineers and developers are wide-ranging and the expectation for one to be an expert or senior across all of those disciplines is unrealistic at best.

Keeping Up is Hard

Taking all these disciplines into account, now think about how on earth you stay current and/or skilled in all of them at the same time. The idea of "Full Stack" is that you ask skilled or highly skilled across the scope of your role.
The overload of information and constant change make this impossible.

From Udemy to YouTube, to documentation, to official training courses and certifications, staying up to date with what you currently know is hard enough. Now add library releases and updates, new technology, and new products into that mix. To stay current, will become a full-time job without doing any delivery work at all.

If you do web development with JavaScript, I could stop here you know the pain. How many different libraries, frameworks, and build tools have you learned over the last few years…I'll wait…it's a long list.

Think Differently About Engineers

Now obviously I'm not saying that people can't have a lot of skills at one time. It's more that the expectation that someone should be equally skilled across an ever-expanding set of disciplines is challenging and unrealistic.
A better expectation is to become/hire/build a team of T-Shaped engineers, but even T-Shaped is a rough definition to hold to.

A T-shaped software engineer is a developer who specializes in one area, but also has a broad range of skills in other areas. The term "T-shaped" is used as a metaphor for an individual's strengths. The vertical line of the T represents expertise in a particular field, while the horizontal line represents cross-discipline competencies.

Building a shallow but broad range of skills is difficult too.

I like to think of Pii Shaped Engineers, learning multiple skills is a must! Becoming an expert/senior at more than one is very beneficial too, but the journey (much like Pii) is never-ending. They might not know everything but they like to learn.

Curious Engineers are the New Black

I interview engineers all the time, The thing I look for is a broader set of knowledge regardless of depth, but the trait underlying is curiosity.

The best engineers love solving problems, but they are curious about the best way to solve them. They continue to learn better techniques, and newer technologies and constantly seek to improve. The top engineers can communicate well enough to explain what they are capable of learning and where they are lacking. Humility helps a lot.

When hiring terms like Full Stack and even T-Shaped can be handcuffs. They get you something but it's not always what you need. As an engineer, it's a nice label but it's impossible to live up to.

Forget a specific set of skills, if you become a curious engineer who can do few things but is always keen to learn, you will figure out the rest.

Given all this, the actual percentage of real Full Stack Engineers has to be continually approaching zero. Don't get me wrong, there are unicorns out there but there aren't many, if any. When I read some job descriptions, I think this hope that an engineer will be able to live up to the full list of wants and needs is a bit misguided.

The world of Applicant Tracking Systems makes it difficult for prospective employees to exist beyond the buzzwords, but maybe those who are hiring should look beyond the list of skills and look for that very useful personality trait, Curiosity.

A bold and possibly unpopular opinion but let me know what you think.

A Cleaner Startup for .NET 6's Minimal Approach

Stephen Walsh — Wed, 29 Jun 2022 07:12:25 +0000

After reading the .NET Migration Documentation in the past week, I have formulated an alternative to the suggested methods from Microsoft. To be honest, I created this approach last year and recently refined it, to make it ready to share with others.

The starting point was finding some posts about using the Startup.cs file in the new .NET 6 minimal hosting model. I know I'm not alone in finding Microsoft's format more annoying than anything. With Microsoft removing the Startup.cs file as the default, this lead me to assume they were proposing that Program.cs would be a heavy and long mess. In reading the posts and Microsoft's documentation I've come to realise that they have a suggested implementation. Problem is I think the implementation is a little messy.

Microsoft's Solution

As I read through their documentation I found that...

Apps migrating to 6.0 don't need to use the new minimal hosting model

This was a surprise because I thought they'd killed the Startup.csfile and it's a problem because I found that this eats away at their minimal model. The approach causes a few extra lines to be inserted into Program.cs to handle all the service and middleware configuration. It creates a new format Startup.cs file, that consists of two methods and an injected set of Configuration, easy enough and does the job.

Combined with the following Startup.cs class

Alternative Solution

The above code works just fine, it's maybe a little clunky looking but it does the job. The alternative approach that I made is just a simple use of extension methods. Nothing world changing but I have found it to be a leaner and cleaner look. The extension methods pass in the WebApplicationBuilder and the WebApplication objects. WebApplication has access to the Environment configuration and both have access to the IConfiguraiton as well. This keeps the spirit of the old Startup.cs just like Microsoft's method but I've found it keeps the Program.cs clean and clear as well.

Combined with the following ProgramExtensions.cs class

This method is not going to change your life but I have found value in it. A little pedantic, yeah probably but I enjoy the simplicity those extension methods offer. If they blow out in size, it's possible to break them into separate files for each method. If any configuration gets even larger and more important, it's possible to make ConfigureApplication and a ConfigureExceptionHandling methods. The possibilities are endless with that pattern.

Support

If you like this, or want to checkout my other work, please connect with me on LinkedIn, Twitter or GitHub, and consider supporting me at [Buy Me a Coffee]

What's your default .editorconfig?

Stephen Walsh — Mon, 27 Jun 2022 03:37:19 +0000

I've been using EditorConfig to bring consistency to the way that I write my code. I also find it's been helpful to standardise the way teams I work on deliver with a similar style. It takes a little while to find settings that work for everyone, but I'm wanting to learn from others what their default configurations are and why you chose them.

If you're wondering what EditorConfig is this is taken straight from their website.

What is EditorConfig?

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.

What I Use

I've been using RehanSaeed's EditorConfig project on GitHub, which is pretty great. I have forked it and made some minor customisations that work for me.

Extensive code style settings for C# and VB.NET have been defined that require the latest C# features to be used. All C# related code styles are consistent with StyleCop's default styles, with the exception of the file header definition, which has been changed to a more modern format. All .NET naming conventions are consistent with the .NET Framework Design Guideline's Naming Guidelines.

Would love to see what others have as a default. Please share your versions or repo links in the comments.

Benchmarking to the Bottom — Iterating Arrays in .NET

Stephen Walsh — Tue, 21 Jun 2022 08:36:22 +0000

Finding the fastest way to iterate arrays while accessing their value in .NET using BenchmarkDotNet validate performance at scale.

I have spent some time recently looking through an older system, wondering how I can make it perform better. There are many avenues to make a system like this faster and more performant, but I wanted to avoid large scale refactoring to keep the risk to a minimum. Specifically I have focused on small items that can add up to make a bigger difference overall. The most obvious is a whole system upgrade but when that’s not an option, these small changes might be all an engineer has to make a difference.

Doing this work has peaked my interest as to which is the best way of doing these every day small tasks in the first place. I’m slowly building out a small series of tasks. It might be consuming different libraries to complete a task vs the native features, or it might straight up comparisons of every day tasks. Either way lessons will be learned and fun will be had.

Iterating and Accessing Arrays

Today I decided to look at many different ways that you can iterate over an Array. It's not complicated in any way but given that software engineers are constantly using both lists and arrays in C#, there is value in addressing them as well.

Key to the outcome is actually assigning the item from the array to a variable. This will ensure that the value is being read, purely iterating without accessing the item could lead to skewed results.

Below are the methods being used and tested via BenchmarkDotNet.

Theory

Given the similarity to the previous test I would imagine that the Span methods are going to be our clear winner here. With no LINQ methods to pick on I'll choose the GetEnumerator method to be the worst performing out of them all. I anticipate that the for loop will be fairly close to the Span and foreach will be a little further back.

Setup

Using BenchmarkDotNet to create a console application makes running this benchmarking test very simple. To ensure older systems are being covered these tests will be run in both .NET Framework 4.8 and .NET 6.0 as these are the current Long Term Support versions of .NET. One for the older world and one for the new world.

The premise is simple. Create a Array of strings 100 and 10,000 deep. Then run the test to iterate through each item and do this on repeat until BenchmarkDotNet is happy to give us a result. This should give us a reasonable assumption of the fastest way to do this going forwards.

Methods

Next up is creating a method for each type of Array iteration that I want to test. Each method does one thing to make it an even benchmark. Each method will iterate through each item in the Array, access the item in the list and assign it to a variable. Once the all the items have been process it will finish and record the time taken to complete the task.

Results

Thankfully for us, BenchmarkDotNet includes a Rank column to make it clear which run of tests is the winner. As you read these results you can use the Mean column to compare the difference in runtime between each test. For some of these there is a clear winner and others the difference is negligible.

.NET Framework 4.8

Rank	Method	N	Mean
1	ForEachLoop	100	305.9 ns
2	ForLoop	100	343.9 ns
3	ArrayForEach	100	451.1 ns
4	GetEnumerator	100	10,561.3 ns
5	ForEachLoop	10000	30,064.2 ns
6	ForLoop	10000	33,541.9 ns
7	ArrayForEach	10000	43,825.3 ns
8	GetEnumerator	10000	1,055,741.5 ns

.NET 6.0

Rank	Method	N	Mean
1	SpanForEach	100	141.9 ns
2	ForLoop	100	173.6 ns
2	ForEachLoop	100	175.2 ns
2	SpanFor	100	175.5 ns
3	ArrayForEach	100	370.7 ns
4	GetEnumerator	100	6,190.5 ns
5	SpanForEach	10000	12,333.7 ns
6	ForLoop	10000	16,181.6 ns
6	SpanFor	10000	16,187.0 ns
6	ForEachLoop	10000	16,251.8 ns
7	ArrayForEach	10000	36,155.1 ns
8	GetEnumerator	10000	611,853.5 ns

Results are formatted for clean and clear display, for the full output you peruse the output of the actions on GitHub.

Thoughts

.NET Framework 4.8

Well quite honestly this is quite the surprise, from the test results foreach is the clear winner. Given it's terrible performance on a List, I really didn't see this coming. It's faster at iterating the larger and smaller array than the for loop. Arrays have a new champion. As expected GetEnumerator is the worst performer by absolute leaps and bounds. The outcome here is clear though, time to refactor your code if you're Array.Foreach in favour of foreach. You could take it or leave it with the for loops as the difference is not massive.

.NET 6.0

It's a familiar story for .NET 6.0 the Span foreach methods taking home the prize. It's closely followed by for, foreach and Span for which would lead me to say that it's not worth a major refactoring effort here. There's only minor gains to be made, but any new code should use a Span combined with a foreach. Array.ForEach is well behind here to and totally worth the refactor. GetEnumerator has been put down enough, it's just not worth your time.

ForEach FTW

While not life changing in some areas the foreach loop is the clear winner and should be implemented as the iterator of choice for .NET 6.0 and .NET Framework 4.8 applications. Just remember with .NET 6.0 to make it a Span as well.

Code

All of this code is open sourced. You can find my benchmarking work on GitHub. The results are the output of a GitHub Action to run the benchmark tests, you should be able to find detailed output on that repository.

Support

If you like this, or want to checkout my other work, please connect with me on LinkedIn, Twitter or GitHub, and consider supporting me at Buy Me a Coffee.

Making Software Engineering Interviews more Creative and Interesting

Stephen Walsh — Thu, 16 Jun 2022 04:21:11 +0000

If you're looking to grow through the ranks in your career as a software engineer, you're only going to take on more responsibility over time. One consistent thing that happens for everyone is that you start to interview other software engineers.

This can be daunting at first, and then easier over time as you gain skills in the area. You might even find yourself in the position where you are helping other new interviewers learn how to interview people.

Over time you will look for tips and tricks on how you can give people a great interview experience. That's why I've put a few tips together and am sharing a challenge that I have been using in my interviews lately.

Interviewer Tips

I've run a fair few interviews now and these are my general interviewer principles.

Don't Be a Dick - Treat people with compassion and kindness, it's hard to put yourself out there.
Listen to the interviewee - Don't judge on buzzwords, hear what they have to say, even if it's not what you're expecting.
Be Ready to Pivot - Following the same interview structure for everyone doesn't work because no two people are the same.

The Challenge

One way I've tried to be creative with the interview process lately is by developing an exercise that I can run with any Software Engineer on any level. It's a simple structure but it's open to creativity and change, it's helped me feel like I understand the person on the other side of the table/camera better than when using just direct questions.

It starts with a simple premise and then I ask a progressive set of questions. At the end of the interview, I will have discussed a different set of technologies and approaches with each person. I ask the same six questions each time but dive in different directions for a few deeper questions based on their answers.

Two notes about this process

I'm not expecting the same thing from a junior as I am from a senior. When I use this approach, I attempt to draw what knowledge the person being interviewed has in each area, but I'm looking to understand what they have learned through their experience.

Let the person being interviewed know that you might take some notes for follow-up questions. It can be off-putting if the interviewer is always looking away and you aren't sure what they're doing.

Getting Started

It starts with a greenfield project. Make it a website, an app, whatever you choose. Make it a store, make it a service, and keep it open to keep the interviews different, but keep it simple and similar to keep your interviews fair. All I say is we want data storage, a backend and a frontend involved. That's where the fun begins.

What's your dream stack for this system?

Start with what technology they know or desire to learn. Let them know that they can choose anything, no wrong answer. Some people choose tech because it solves a specific problem, others because of what they know, and some because they want to learn it. Some people want to talk about infrastructure too, let them. There's more room for that later but no harm bringing it up early. All I'm looking for here is reasoning, why are you choosing that stack? Tells you a lot about how people think.

Now that you have some features, how do you validate that it works?

This question is all about testing. There's a fair amount you can learn about an engineer and team fit in knowing their attitude and approach to testing their code. Automated or manual, and why? What layers of testing might you include, unit, integration and/or E2E? Dig deeper and ask about code coverage, see how they value that metric.

You have more people join your team, how do you all work together on the same codebase?

How does this person work in a team? Do they like Pull Requests? How about Code Reviews? Pair Programming? How are they used to working with others....and source control? You can dig into Agile experience and maturity here too, Stand-ups, Sprint Reviews and more. This is a moment to understand how people value teamwork, and learning from others, and whether they are willing to serve others.

It's time to show your work to project stakeholders and your customers, how do you make your system available?

Now we're onto (insert buzzword here) DevOps and Infrastructure. Experience with and approach to building and releasing software. Do you have build pipelines, when do you run them? What environments make sense to serve all people involved in a project. How do you release the software? What do you host it on or in? AWS, Azure, GCP or something else? These aspects of projects people work on can quite often bring a great deal of frustration. How does this person handle that? How do they express it when telling you about it?

Something is wrong, how can you get more information about what is happening?

Oh boy it's time to problem solve. How does this person approach solving a bug? Who do they talk to? What systems do they use in partnership with their software to help them? Do they use application logging? Where do they store their logs? How do they track their progress on a bug? What proactive steps would they take to stay ahead of future bugs?

There are a lot of questions and avenues to go down here, don't dwell forever but depending on the role, this time could really help you know if you would want to work with this person.

Customer demand is growing, how can you make sure your software is up to the challenge?

Finally, how would this person handle the need to scale their system. How would they approach making sure their system was resilient? Would they rely on cloud native features? Would they configure automated, timed, or manual scaling? Would this consideration change their infrastructure choices? This section is tough because it's hard to do hypothetically. Again, how does this person respond when given a problem?

What I'm listening and looking for?

I use this process to get a better sense of a person, than asking directly about their experience with a specific technology.

What they know and have experienced
How they explain what these to me
The details they include and leave out
When I don't understand, how they teach me

Interviewing can be tough, but I've found this challenge and the tips above have allowed me to get people to open up a little and help me understand them. As a person and as a software engineer. I hope it helps you too.

Support

If you like this, checkout my other examples on GitHub and consider supporting me at Buy Me a Coffee.

Benchmarking to the Bottom - Iterating Lists in .NET

Stephen Walsh — Thu, 10 Mar 2022 12:06:54 +0000

Finding the fastest way to iterate lists while accessing their value in .NET using BenchmarkDotNet validate performance at scale.

Iterating and Accessing Lists

Today I decided to look at many different ways that you can iterate over a list. The application I have been working on has many instances of long lists that are iterated for various reasons. It made me wonder what’s the fastest way to work through all the items in a list.

On my initial run through, I neglected to assign the items being iterated to a variable. Purely iterating the list without accessing the item lead to skewed results. Both sets of results will be listed in the outcomes.

Below are the methods being used and tested via BenchmarkDotNet.

Theory

I have read lately about how the for loop is actually faster than the foreach one. I'm anticipating that what I would find is for that to be slightly more performant on a List. To cover multiple different ways to iterate through a list I have included LINQ and for as other options. I would anticipate LINQ to be slightly slower and I have never used Span before so I have no idea what to expect.

Setup

The premise is simple. Create a List of strings 100 and 10,000 deep. Then run the test to iterate through each item and do this on repeat until BenchmarkDotNet is happy to give us a result. This should give us a reasonable assumption of the fastest way to do this going forwards.

Methods

Next up is creating a method for each type of List iteration that I want to test. Each method does one thing to make it an even benchmark. Each method will iterate through each item in the List, access the item in the list and assign it to a variable. Once the all the items have been process it will finish and record the time taken to complete the task.

Results

.NET Framework 4.8

Rank	Method	N	Mean
1	For	100	344.8 ns
2	ForEachLinq	100	559.9 ns
3	ForEach	100	659.4 ns
3	GetEnumerator	100	659.5 ns
4	For	10000	33,562.8 ns
5	ForEachLinq	10000	53,895.5 ns
6	GetEnumerator	10000	63,317.0 ns
6	ForEach	10000	63,356.6 ns

.NET 6.0

Rank	Method	N	Mean
1	SpanForEach	100	144.3 ns
2	SpanFor	100	176.3 ns
3	ForEach	100	251.0 ns
3	GetEnumerator	100	251.0 ns
3	For	100	251.4 ns
4	ForEachLinq	100	352.1 ns
5	SpanForEach	10000	12,260.4 ns
6	SpanFor	10000	16,088.1 ns
7	ForEach	10000	24,109.4 ns
7	GetEnumerator	10000	24,111.0 ns
7	For	10000	24,113.8 ns
8	ForEachLinq	10000	34,713.9 ns

Results are formatted for clean and clear display, for the full output you peruse the output of the actions on GitHub.

Thoughts

.NET Framework 4.8

After running the benchmark tests, the huge surprise to me here is how bad foreach performs. It’s on par as the worst with GetEnumerator and gets outperformed by LINQ foreach. I will definitely not be using this in any older system any time soon. Would have been nice to have some Span results to compare but that feature is not available for .NET Framework. The clear choice here is to refactor all List iterations into for loops and live a happy life.

.NET 6.0

The .NET results are quite surprising to me. I started running this not knowing much about Span, and now I’m ready to do a bit of research to understand more. When accessing the item, it appears that the Span has an edge over the for and foreach and it looks like it's worth refactoring your entire codebase for that performance gain. The key outcome here is that any iteration of a List should look to convert that list to a Span. Outside of that there is some difference between for and foreach when iterating a Span but I'm not sure that it's worth changing all those over.

STOP USING LINQ FOREACH STATEMENTS

They are a performance killer in both .NET 6.0 and .NET Framework 4.8 and far slower than the alternatives. Refactor those immediately. It's incredibly poor for something that does get used by a lot of people.

Code

Support

If you like this, or want to checkout my other work, please connect with me on LinkedIn, Twitter or GitHub, and consider supporting me at Buy Me a Coffee.

Build Your Personal Brand with a Profile Page using GitHub Pages and Hugo

Stephen Walsh — Sun, 13 Feb 2022 03:14:20 +0000

There are a lot more people are thinking about personal brands and all sorts of extra bits and pieces outside of just plain on being a software engineer these days. Recently I created a simple personal profile site that links to my blog, GitHub, Twitter and LinkedIn and thought that others might find a quick how to useful so here we go.

I have tried many other frameworks and even different themes. I've done this all slowly over a few months but now I'm happy with how simple my setup is, and how easy this is for others to do the same. The following is a list of tools used to get the job done:

Hosting - GitHub Pages
Website Framework - Hugo
Website Theme - Lynx
Publishing - GitHub Action
Publishing Action - Shohei Ueda's Template

1. Create a GitHub Pages Repository

Login to GitHub and create a new repository on the new repository page. You need to use the pattern "{username}.github.io", my username is stphnwlsh so my name was stphnwlsh.github.io. Nothing earth shattering here.

Give it a .gitignore file and choose none for the template (we'll update it later), even throw in a licence if you want to. You choose it's your party. Clone the new repository onto your machine and we're ready to go.

git clone https://github.com/{username}/{username}.github.io

Some side notes, if you manage an organisation, you can use the orgs name too. Also, if you already have one, then well tough luck, each github user can only have one.

You can only create one user or organization site for each account on GitHub. Project sites, whether owned by an organization or a user account, are unlimited.

If you're having any issues at this stage, checkout the default setup instructions.

2. Install Hugo and Create a Site

First things first you have to install Hugo onto your machine. I'm on a Mac so it was easy as using Brew.

brew install hugo

Aaaaaaand we're done!!! For other systems checkout the install page on the Hugo website, that will get you where you need to go.

Next up, use your favourite command line tool and navigate to your recently cloned repository to kickstart your journey with Hugo.

hugo new site .

You'll find yourself with some new files and folders, this is the basic black skeleton from Hugo. No content yet, but we'll get there.

3. Install a Hugo Theme

I have shopped around for a few different themes. Hugo is light and very powerful, and it has themes for everything. You can choose on the Hugo Themes site or a few others, just give it a Google.

I went with Lynx because it was a plain and simple profile site with some nice link buttons and it's easy to customise....that's it.

You can just download the theme and dump it in a themes\lynx folder, or you can use hugo to install the theme. I didn't do that, I went down the submodule route, it's helpful if you ever need to customise the theme and then want to give back via a pull request.

cd themes
git submodule add https://github.com/jpanther/lynx

Copy the contents of the themes\lynx\exampleSite folder to your root repository folder and you have a default starting point ready to go.

4. Customise Your Content & Style

There are four key areas to customise to make the site your own. Hugo settings, custom css, page content and custom images. The first thing is to run your site locally with the following CLI command.

hugo server

Once you run this command the output will have a localhost:port url in there copy and paste that into a browser and update the code. There is a watch on changes so you will see live updates.

The hugo settings are found in config.toml. You can set the site name, the main image and the links on the profile page here. Compare my settings with the example settings to see how easy this is to update.

To change the look and feel navigate to the assets\css\custom.css file and just start playing around. I didn't change much, just spacing and colours. Inspect the code in the browser and go for it.

For the text block on the page look at content\_index.md, update the text block, then update the title, description and images for your meta tags and you are done.

Finally drop your images into the static folder. Use the themes\lynx\static folder to guide you on the naming for your favicons, then set the profile image in the config.toml.

This isn't that descriptive but this is the creative part, you can adjust however you like and turn this:

into this:

5. Push it to GitHub

A couple of final steps before we push this to our repo.

Add a .nojekyll file to the root directory. Adding this file will bypass all the default Jekyll processing that GitHub Pages does by default. It's pretty old now but still works, see GitHub's post on this feature.

Update your .gitignore file to match this one from Hugo examples on GitHub.

Last step is to add a GitHub Action. Lucky for us there is something that Shohei Ueda prepared earlier. Create a new file at .github\workflows\github-pages.yml. This will hold out action that will publish your site to a new branch gh-pages. This new branch will be used to host your site. Copy the following code into your file.

name: GitHub Pages

on:
  push:
    branches:
      - main  # Set a branch to deploy
  pull_request:

jobs:
  deploy:
    runs-on: ubuntu-latest
    concurrency:
      group: ${{ github.workflow }}-${{ github.ref }}
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true  # Fetch Hugo themes (true OR recursive)
          fetch-depth: 0    # Fetch all history for .GitInfo and .Lastmod

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: 'latest'
          # extended: true

      - name: Build
        run: hugo --minify

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        if: ${{ github.ref == 'refs/heads/main' }}
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public

Finally push your code up to GitHub and navigate to your repository on the GitHub site.

6. Configure GitHub to Publish Your Site

Finally head over to the GitHub Pages settings page to finish this up and checkout your new site.

https://github.com/{username}/{username}.github.io/settings/pages

If your action has finished by time you get here, set the published branch to gh-pages and the directory to root. GitHub will likely need a few minutes to process everything but then your new site will be available at {username}.github.io, congrats!!!!

That's all folks! If you need any guidance please have a look at my repository, there are expansive configuration instructions on the Lync GitHub repository as well if you are getting more creative than I did.

Have a peek at my site in the wild if you like. This reads like a long process but it was really simple in the end, just had to fail a fair bit with other sites to get it right. Hope this helps you too.

Support

If you like this, checkout my other examples on GitHub and consider supporting me at Buy Me a Coffee.

Top 5 Things I Actually Like About Top {X} Posts

Stephen Walsh — Mon, 31 Jan 2022 23:56:08 +0000

I've been an engineer for a while now and always been a consumer of engineering blogs and feeds. In the last few months, I've gone on the journey to do a little creating too. It's fun, and a little scary sharing my thoughts with the real world. Unfortunately, I have noticed a trait in me that I don't love. I've added a little extra cynicism to my thought patterns these days and I think not in a healthy way. So, I'm calling myself out.

I have found myself hating the "Top X Things to Know About Y" posts. It's not their content per se more the fact that it's the same thing over and over again. I've noticed them the most with the release of C# 10 and the hundreds and thousands of posts with that type of tile, and same content. I'm even adding to it here (hypocrisy, right?). My attitude towards them has been terribly negative and I want to change that.

To pivot back I'm going to find the positives in these posts to help me be less of a grump about it all and see the value in what they provide. Come on the journey with me for my own personal top five.

1. Knowledge to Be Shared

The best starting point here is that I don't know everything. It's easy for engineers to always think they know a better way to do something, and that different approaches are wrong. These articles are a good reminder that there are plenty of things changing all the time and that there are new things to learn. Understanding different ideas and perspectives make me a better person and a better engineer.

There are also lots of these articles for technologies outside of my skillset. These articles provide a good viewpoint as to what technologies are gaining popularity and what might be worth investing my time into.

2. People Have a Desire to Learn

These articles are meeting a need. There are software engineers of all levels out there looking to improve themselves and learn new things. These articles provide an avenue to help people fulfill that desire to get better, even if it's only the entry point. Iron sharpens iron, as one person learns and improves, we are all driven to follow. Life without learning would be boring and these posts help us all on that journey.

3. Short and Sharp Avenue to Learn a New Thing

Most of these articles would not be accused of being a long and difficult read. They are short and sharp, and well that's kind of the point. All they are meant to give you is more things to investigate, but they do it in a straightforward way that's easy to consume. That's exactly what some people need and what others are looking for. I started out looking for something new to learn and now I have five news things, great!!!

4. Authors Gain Confidence to Contribute

In taking my time to write this I can now call myself an author......maybe. Jury's out but I'll barrel on anyway. My main fear in even starting to write is that I might not actually have something to offer. I might not have anything worth sharing. These posts are excellent starting points for people getting into writing and in need of building some confidence. It was a big leap for me to even start and I have to give credit to those who take the risk too.

5. Provide Implementation Examples

This last point might be a bit of a stretch, as not all posts do this, but engineers can get some simple implementation examples from them as well. Quite often they're just taken from another source, but they still help engineers gain a better understanding via the code. The great versions of these posts have a more real-world example of an implementation and I find that to be helpful. The real winners combine more than one concept together, I've noticed in looking for examples you always end up trying to mash two of them together to make your code do what you need it to do.

Well, if you've hung in there till this point, I have nothing to say but thank you. You stuck it out with me through an exercise in being positive, which is pretty cool. I still may not love these but next time I see one, I'll be able to remember that they do have value. They help people discover new things, who knows, I might even read it and share it with someone else.

Bending DateTime in .NET to Test Your Code Better

Stephen Walsh — Wed, 19 Jan 2022 02:13:16 +0000

Okay I'll dial down the hyperbole, over my too many years (read I'm feeling old) as an engineer I have run into a problem where my code has contained a DateTime.Now or DateTime.UtcNow. When I write a test, I can't validate the actual time because milliseconds have passed from when the code ran and then my test goes to validate. It's not a huge problem but annoying as I like to validate everything to make sure I'm not accidentally manipulating those values somewhere else.

There is an easy solution to this, and before I detail out the solution that I used, I need to call out the inspirations for this. The TL;DR is that you can consume my SimpleDateTimeProvider NuGet Package to help you solve this. The implementation of the code for this lies below.

The Solution

I have created a DateTimeProvider consisting of an interface, and two implementations of the interface. One implementation returns the System values and the other returns Mocked values that are preset by the user.

The Interface

public interface IDateTimeProvider
{
    DateTime Now { get; }
    DateTime Today { get; }
    DateTime UtcNow { get; }
}

The System Implementation

public class SystemDateTimeProvider : IDateTimeProvider
{
    public DateTime Now => DateTime.Now;
    public DateTime Today => DateTime.Today;
    public DateTime UtcNow => DateTime.UtcNow;
}

The Mock Implementation

public class MockDateTimeProvider : IDateTimeProvider
{
    public DateTime Now
    {
        get => this.now.ThrowIfNotSet(DateTimeType.Now);
        set => this.now = value;
    }
    public DateTime Today
    {
        get => this.today.ThrowIfNotSet(DateTimeType.Today);
        set => this.today = value;
    }
    public DateTime UtcNow
    {
        get => this.utcNow.ThrowIfNotSet(DateTimeType.UtcNow);
        set => this.utcNow = value;
    }
}

Bending Date and Time

This is a simple solution and it's easy to get under way using the providers, simply inject the system provider under the IDateTimeProvider interface in your functional code. If you are using another library, you'll know the syntax but follow the same formula.

_ = services.AddSingleton<IDateTimeProvider, SystemDateTimeProvider>();

Next step is to create your class and use that registered SystemDateTimeProvider that we just created via the IDateTimeProvider interface. Then use the provider to set the DateTime values in your class.

public class Service
{
    private readonly IDateTimeProvider dateTimeProvider;

    public Service(IDateTimeProvider dateTimeProvider)
    {
        this.dateTimeProvider = dateTimeProvider;
    }

    public string DateTimeNow()
    {
        return $"DateTime.Now is {this.dateTimeProvider.Now}";
    }
}

The whole purpose of this was to allow for testable code. So now that you have your class above, you can inject the MockDateTimeProvider in its place to control the DateTime values in your tests. The following example shows how to write a test in XUnit, using Shouldly for assertion.

[Fact]
public void Today_ShouldReturn_MockedToday()
{
    // Arrange
    var provider = new MockDateTimeProvider();
    var service = new Service(provider);
    var today = DateTime.Today;

    provider.Today = today;

    // Act
    var result = service.DateTimeToday();

    // Assert
    _ = result.ShouldBeOfType<string>();
    result.ShouldBe($"DateTime.Today is {today}");
}

Where Can I Find This?

All of this open sourced. You can find my work on GitHub
at SimpleDateTimeProvider Repository and the published package at SimpleDateTimeProvider NuGet.

Support

If you like this, checkout my other examples on GitHub and consider supporting me at Buy Me a Coffee.

Respectful Naming Conventions

Stephen Walsh — Mon, 06 Dec 2021 22:39:22 +0000

Originally written on the 16th of June in 2020. I'm moving this post from Medium to here as I'm going to write things here instead of there now. This is a light touch on a heavy topic, but I'm genuinely interested how other engineers are approaching this topic more than a year later. Would love to hear other suggestions or how your codebases have changed or not changed.

This is my first post. I’m not usually a blogger, I’m not after attention and I’m not trying to jump to a new job or career. I’m a regular old software developer, who’s been at it for over 15 years, and I still love what I do every day.

The reason I’m writing this now is that I’m thinking through and processing all the events following the killing of George Floyd in Minneapolis. I’m just a software engineer in Australia who is far removed from the whole situation, but I figured there are things I can do in my life to break down barriers no matter how small. After reading about GitHub moving away from naming the main branch in a repository “master” and being a Jenkins user seeing the terms master and slave every day, I figured I could do something along those lines too.

I have a starting point of these 3 things but am looking to crowd source other naming conventions people are using out there

Renaming “master” branches to “main”.
Renaming whitelist/blacklist to allowlist/denylist.
Renaming master/slave in Jenkins to organiser/worker.

I’d like to know what other naming conventions people are using to remove less respectful naming in their systems.

As a footnote, this is the article I read about GitHub changing their naming.

Using GitHub Actions to Update .NET Dependencies Automatically

Stephen Walsh — Sat, 27 Nov 2021 20:45:31 +0000

It’s a tale as old as time, as a software engineer, you write some code, you’re happy with it and then you deliver it. End of story, right? No more work to be done! As usual there’s many more layers to deal with and one of those many layers is maintenance……boooooo!!!!!

I know this isn’t the most amazing topic to write about, but it solves a real-world problem for me and I’m hoping for some of you too.

I’m a backend engineer and write a lot of C#, which means I end up with solutions relying on NuGet packages. These do need to be updated all the time because there are other engineers out there doing amazing work keeping their packages up to date and I like to keep my dependencies up to date. This is where I find myself, with the problem of having to create a branch, update the packages, commit it, then seek PR approval, just to get some minor updates through. It’s annoying and I want to solve this.

Before we get underway, are these instructions for me?

You have a solution written in .NET…these instructions only work for code in .NET.
The code already is, or you are about to host this solution in Github….so you can use Actions.
You want to update your NuGet packages, engineers have valid reasons for doing or not doing things, no pressure here. I like to keep my packages up to date or at the very least alert me to when I need to make changes because of dependency updates.

If you are in, it’s time to work with me here, Actions can be used to trigger many workflows. The most common being build and release pipelines for you project. The answer to our problem also lives in an Action. The time has come to create a new one.

Navigate to your GitHub Repository of choice
Select the Actions tab
Click that New Workflow button
Ignore all the templates and select “Set up a Workflow Yourself”
Delete all the sample code and we are good to go

Step 1: Create a schedule action

This is the easiest part, this action will run once a week. You can change the schedule to anything you want. GitHub Action don’t run perfectly on time, but the do run. For more on scheduled jobs and setting the schedules, read the GitHub Documentation and checkout the examples at Crontab Guru.

name: Automated Dependency Updates
on:
    schedule:
        - cron:  '0 0 * * 0'

Step 2: Setup the Job

Next up we set up the job. This is where we define what steps we want to run. We’re running this job on the latest version of Ubuntu. Next, we setup the default actions/checkout step as well as actions/setup-dotnet to install the version of the .NET SDK we need for our solution. I need .NET 6 for this job. You must that notice the changed token for the checkout AUTOMATED_DEPENDENCY_UPDATES_TOKEN, this comes in handy in Step 5, I’ll explain what’s up down there.

    dependencies: 
        name: Update Dependencies
        runs-on: ubuntu-latest
steps:
    - name: Checkout
      id: checkout
      uses: actions/checkout@v2
      with:
          token: ${{ secrets.AUTOMATED_DEPENDENCY_UPDATES_TOKEN }}
    - name: Setup
      uses: actions/setup-dotnet@v1
      with:
          dotnet-version: 6.0.x

Step 3: Update those Dependencies

These are the base steps of updating our NuGet packages. First, we need to install the dotnet-outdated tool and then validate if we need to take any further action. If we run dotnet outdated and there are not packages to update we should cancel the rest of the steps in this job.
This is done but setting an output variable on the validate step that can be used by every other step in the job to determine if it should run or not. If there are no updates to be made, then we set the output variable to false.
If we have updates to make them, we run dotnet outdated -u to force the NuGet updates. If this is successful, then we set the output variable to true to allow the following steps to run.

- name: Tools
  id: tools      
  run: dotnet tool install --global dotnet-outdated-tool     
- name: Update      
  id: update      
  run: |        
      OUTPUT=$(dotnet outdated)        
      if [[ $OUTPUT =~ "No outdated dependencies" ]]; then
          echo "::set-output name=updated::false"        
      else            
          dotnet outdated -u                    
          echo "::set-output name=updated::true"        
      fi      
  shell: bash

Step 4: Run your Tests

After you’ve updated the NuGet packages you need to validate that the changes haven’t broken your code. The best way to do that is to build and test your solution. It’s a simple dotnet test command to run all the tests on the solution. You can update this statement to suit your needs, the default should be to run all your tests.

- name: Test
  id: test
  if: ${{ steps.update.outputs.updated == 'true' }}
  run: dotnet test -c Release -v minimal

Step 5: Commit and Push

The final step is to commit and then push the NuGet package updates, if the tests pass then this step runs and your automated package update is complete. When we used the AUTOMATED_DEPENDENCY_UPDATES_TOKEN in the checkout step, that was to step around the fact that the inbuilt GITHUB_TOKEN will not trigger a follow-on workflow. If you generate a specific Personal Access Token to use when checking the code out then after the code is pushed, if you have another automated workflow, it will trigger.
Finally, we set the commit message and author. This will register the commit to the GitHub Action user and not the user who setup the job.

- name: Push
  id: push
  if: ${{ steps.update.outputs.updated == 'true' }}
  uses: stefanzweifel/git-auto-commit-action@v4
  with:
      commit_author: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      commit_user_name: github-actions[bot]
      commit_user_email: 41898282+github-actions[bot]@users.noreply.github.com
      commit_message: Automated Dependency Updates

We’re Done!

Now let’s put all the steps together in one easy Gist to use in any other repository. Hope this helps you automate that boring task too. This can work for any other CI/CD tool that allows for scheduled jobs. The concepts are the same just follow the Checkout, Update, Test and Push process.

Support

If you like this, checkout my other examples on GitHub and consider supporting me at Buy Me a Coffee.

Dotnet Outdated - Install and Update

Stephen Walsh — Sat, 27 Nov 2021 13:20:55 +0000

My Workflow

stphnwlsh / dotnet-outdated-action

Dotnet Outdated Action

This action installs the dotnet outdated dotnet tool and then attempts to update any NuGet packages that are available.

Inputs

`location`

The location of the solution or project that needs to be checked for dependency updates. Default "".

For more information review the Specifying the Path documentation on the dotnet outdated GitHub

`includes`

A comma separated list of inputs to use to limit packages being analysed to ones including those values. Default "".

DO NOT INCLUDE SPACES - this will break the step and cause your pipeline to fail.

The following example will only include packages with the word 'microsoft' in their name, regardless of casing.

with
  includes: microsoft

This example will only include packages with the words 'microsoft' and 'automapper' in their name.

with:
  includes: microsoft,automapper

For more information review the Includes and Excludes documentation on the dotnet outdated GitHub

…

View on GitHub

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

https://github.com/stphnwlsh/CleanGraphQLApi/blob/main/.github/workflows/dependency-updates.yml

stphnwlsh / CleanGraphQLApi

A template for an API using Clean Architecture and GraphQL.net.

Clean GraphQL API

This is a template API using Clean Architecture alongside a .net implementation of GraphQL.

Prerequisites

This solution in built on the .net 6 SDK, you need to install that before it will work for you. If you want to build the Dockerfile you will need to install Docker as well.

Installation

This is a template and you can install it using the dotnet new cli. To install the lastest version of the template run the following command.

dotnet new --install CleanGraphQLApi.Template

To create a new solution using this template run the following command

dotnet new cleangraphqlapi --name {YOUR_SOLUTION_NAMESPACE} --au "{YOU_AUTHORS_NAME}"

Docker

There's a dockerfile included in the build folder and serves the purpose of restoring, building, testing, publishing and then creating a runtime image of the API. Works on my machine.....you can add a version prefix and suffix to version the service…

View on GitHub

Additional Resources / Info

https://github.com/stphnwlsh/CleanGraphQLApi
https://github.com/stphnwlsh/CleanMinimalApi
https://github.com/stphnwlsh/SimpleDateTimeProvider

Forem: Stephen Walsh

Full Stack Engineers Don't Exist!

Defining a Full Stack Developer

Demands on the Modern-Day Software Engineer

Keeping Up is Hard

Think Differently About Engineers

Curious Engineers are the New Black

A Cleaner Startup for .NET 6's Minimal Approach

Microsoft's Solution

Alternative Solution

Support

What's your default .editorconfig?

What is EditorConfig?

What I Use

Further Reading

Benchmarking to the Bottom — Iterating Arrays in .NET

Iterating and Accessing Arrays

Theory

Setup

Methods

Results

.NET Framework 4.8

.NET 6.0

Thoughts

.NET Framework 4.8

.NET 6.0

ForEach FTW

Code

Support

Making Software Engineering Interviews more Creative and Interesting

Interviewer Tips

The Challenge

Getting Started

What's your dream stack for this system?

Now that you have some features, how do you validate that it works?

You have more people join your team, how do you all work together on the same codebase?

It's time to show your work to project stakeholders and your customers, how do you make your system available?

Something is wrong, how can you get more information about what is happening?

Customer demand is growing, how can you make sure your software is up to the challenge?

More Questions

What I'm listening and looking for?

Support

Benchmarking to the Bottom - Iterating Lists in .NET

Iterating and Accessing Lists

Theory

Setup

Methods

Results

.NET Framework 4.8

.NET 6.0

Thoughts

.NET Framework 4.8

.NET 6.0

STOP USING LINQ FOREACH STATEMENTS

Code

Support

Build Your Personal Brand with a Profile Page using GitHub Pages and Hugo

1. Create a GitHub Pages Repository

2. Install Hugo and Create a Site

3. Install a Hugo Theme

4. Customise Your Content & Style

5. Push it to GitHub

6. Configure GitHub to Publish Your Site

Support

Top 5 Things I Actually Like About Top {X} Posts

1. Knowledge to Be Shared

2. People Have a Desire to Learn

3. Short and Sharp Avenue to Learn a New Thing

4. Authors Gain Confidence to Contribute

5. Provide Implementation Examples

Bending DateTime in .NET to Test Your Code Better

The Solution

The Interface

The System Implementation

The Mock Implementation

Bending Date and Time

Where Can I Find This?

Support

Respectful Naming Conventions

Using GitHub Actions to Update .NET Dependencies Automatically