Forem: Grant Hair

How delegating handlers bit me in the ass and how I tested them

Grant Hair — Mon, 03 Jul 2023 08:39:05 +0000

My use case was the following:

Add a delegating handler to add a bearer token to an api call that will either pull a JWT from a 3rd party api endpoint or pull it from memory cache. If we get an unauthorized response we want to bust the cache and repopulate the value with a call to an api

My main issue with testing this logic was in the following code




protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,
            CancellationToken cancellationToken)
            => MakeRequest(request, false, cancellationToken);

        private async Task<HttpResponseMessage> MakeRequest(HttpRequestMessage request, bool isRetry,
            CancellationToken cancellationToken)
        {
            try
            {
                await SetAuthHeader(request, isRetry);
                return await base.SendAsync(request, cancellationToken);
            }
            catch (ApiException exception) when (exception.StatusCode == HttpStatusCode.Unauthorized)
            {
                if (!isRetry)
                {
                    // if due to 401 and it wasn't a new token then retry with a new token
                    return await MakeRequest(request, true, cancellationToken);
                }

                _logger.LogError(exception, "ApiException making request to {url}", request.RequestUri);
                throw;
            }
        }

When return await base.SendAsync(request, cancellationToken); was called the base class would then try and send the actual api request which would result in a 404 because my test was setup to send requests to "blah.blah" or something. In my use case it was a 3rd party api to send SMS messages to users not something I wanted to be doing for real life.

My test code looked something kinda like this (Moq-ed Spaghetti) after a couple days and a lot of head banging trying to get stuff mocked out and trying to use Moq Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected().Protected() or something I can't remember it was a bit of a blur haha

Then I came across this stack overflow answer and stuff started to make sense.

https://stackoverflow.com/a/37219176/9057687

By setting the InnerHandler of my custom delegating handler to just a stubbed out response like this I was able to avoid the actual sending of the request and just return an Accepted response.



public class TestHandler : DelegatingHandler
    {
        private readonly SendMessageResponse _sendMessageResponse = new()
        {
            MessageId = new Guid("AF97201F-F324-4CD1-A513-42811FA962B4")
        };

        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            var response = new HttpResponseMessage(HttpStatusCode.Accepted)
            {
                Content = JsonContent.Create(_sendMessageResponse)
            };

            return Task.FromResult(response);
        }
    }

Then my test code could be simplified massively to something like this



public class MyTestHandlerThatIWantToTestShould
    {
        private const string JwtValue =
            "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0ZXN0IjoidGVzdCJ9.elSSvs4awH3XEo1yZGTfZWjgCXcfyy_TBRyCSCT3WbM";

        private readonly Mock<ILogger<MyTestHandlerThatIWantToTest>> _logger = new();
        private readonly IMemoryCache _memoryCache = new MemoryCache(new MemoryCacheOptions());
        private readonly MyTestHandlerThatIWantToTest _handlerThatIWantToTest;
        private readonly IOptions<SmsApiConfiguration> _config;

        private readonly SendMessageResponse _sendMessageResponse = new()
        {
            MessageId = new Guid("AF97201F-F324-4CD1-A513-42811FA962B4")
        };

        public MyTestHandlerThatIWantToTestShould()
        {
            _config = Microsoft.Extensions.Options.Options.Create(new SmsApiConfiguration
            {
                ApiBaseAddress = "https://any-old-value.website.com/api-test-mocked",
                ApiToken = Guid.NewGuid(),
                JwtTokenCacheKey = "CacheKey"
            });

            var mockHttp = new MockHttpMessageHandler();

            mockHttp.When("*")
                .Respond("application/json", "{'jwt' : '" + JwtValue + "'}"); 

            var client = new HttpClient(mockHttp);
            _handlerThatIWantToTest = new MyTestHandlerThatIWantToTest(_logger.Object, _memoryCache, _config, client);
        }

        [Fact]
        public async Task PopulateBearerTokenValue_When_ARequestToSendSmsIsSend()
        {
            var request = new HttpRequestMessage();

// This is the magic line I'd say
            _handlerThatIWantToTest.InnerHandler = new TestHandler();

            var invoker = new HttpMessageInvoker(_handlerThatIWantToTest);

            // act
            var response = await invoker.SendAsync(request, default);

            response.StatusCode.Should().Be(HttpStatusCode.Accepted);
            var json = await response.Content.ReadAsStringAsync();
            var responseObject = JsonConvert.DeserializeObject<SendMessageResponse>(json);
            responseObject.MessageId.Should().Be(_sendMessageResponse.MessageId);

            request.Headers.Authorization?.Parameter.Should().Be(JwtValue);
            _memoryCache.Get(_config.Value.JwtTokenCacheKey).Should().Be(JwtValue);
        }
    }

In my test I can assert that an auth header was added, the value was added to the memory cache and that an accepted response was returned.

Everyone probably already knows this stuff but it kinda stumped me for a bit I think mainly because we are using Refit for our API calls instead of using HttpClient everywhere so stuff was a wee bit different for me and took a bit to get my head around. We had a bit of chicken and egg situation for a while with the api that both sent the request and obtained the JWT as it was technically part of the same Refit interface but we needed to pass the interface to get the jwt before we could make the request so DI became a bit tricky hence the usage of HttpClient for getting the JWT and refit for sending the actual request.

I'm pretty sure there are a few ways to refactor this code or improve it but the tickets in ready to deploy now so that is a tale for another sprint haha.

Shout out to:

https://github.com/richardszalay/mockhttp

https://github.com/moq/moq

https://fluentassertions.com

👋

I used my first ever Expression> today to create reusable LINQ Queries

Grant Hair — Fri, 19 Nov 2021 11:49:22 +0000

Up to this point in my career I have yet to reuse a Select lambda in my LINQ queries, today that changed.

I was messing around with something for a technical session within my team when I noticed I had the exact same code for 2 Select functions.

Basically I wanted to Select my DB entity type to a Domain Transfer Object type. I could've done this through some mapping or whatever but I chose this way to show off the barebones of what I was trying to show and tell at our tech session.

My code looks like this, I have a VERY basic API (that uses probably 0 best practices) that returns various information about Golf courses, scores, handicaps etc etc.

Side note, I love golf, its a great excuse to get outdoors which is probably going against the grain in a Covid fuelled world but anyways I'll keep going.

I managed to take a pretty sick photo of a tree whilst golfing at the weekend.

Where was I... ah yes the codes.


public class CourseDataIntegrationServices : ICourseDataIntegrationServices
    {
        private readonly GolfScoresDbContext _context;

        public CourseDataIntegrationServices(GolfScoresDbContext context)
        {
            _context = context;
        }

        public List<CourseDto> GetAllCourses()
        {
            return _context
                .Courses
                .Include(x => x.Holes)
                .Select(_selectCourseToCourseDto)
                .ToList();
        }

        public CourseDto GetCourseById(Guid id)
        {
            return _context
                .Courses
                .Include(x => x.Holes)
                .Select(_selectCourseToCourseDto)
                .FirstOrDefault(x => x.Id == id);
        }

        private readonly Expression<Func<Course, CourseDto>> _selectCourseToCourseDto = (x) =>
            new CourseDto
            {
                Holes = x.Holes.Select(h => new HolesDto
                {
                    Name = h.Name,
                    HandicapIndex = h.HandicapIndex,
                    Par = h.Par,
                    Id = h.Id,
                    Number = h.Number,
                    Yardage = h.Yardage
                }).OrderBy(h => h.Number).ToList(),
                Id = x.Id,
                Name = x.Name,
                Par = x.Par
            };
    }

The nice thing about this is that I know have a reusable way of mapping my DB entity to my DTO without the need of a 3rd part NuGet package and tbh the code is pretty plain vanilla in terms of added sprinkles.

Expression<Func<Course, CourseDto>> in your head can become
Expression<Func<MyInputType, MyOutputType>>

I can take the above one step further by writing a second Expression> for my Hole selection...don't be nasty.

I think I will leave that for another day.

Anyways I hope this has been of some help to those looking to create reusable select criteria for LINQ queries.

Cypress e2e testing with Google Maps Autocomplete

Grant Hair — Tue, 04 May 2021 08:48:04 +0000

During my working day I encountered a problem.

I needed to be able to drive a Google Maps Autocomplete text input through Cypress Tests.

https://docs.cypress.io

https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete

As you can see above we get some suggestions as you type in the search box.

Now this is extremely easy to test manually, just jab in a place and click on a suggestion.

Cypress testing this not so much.

I scratched my head for hours trying to figure out how I could target that little suggestions list served back from Google Maps.

I went through the following google search results

https://github.com/cypress-io/cypress/issues/14598

https://stackoverflow.com/questions/53039165/cypress-test-google-places-autocomplete-not-functioning

https://github.com/bahmutov/cypress-geolocation-example

https://glebbahmutov.com/blog/cypress-geolocation/

The Solution

The Solution for me was something like the following




completeBranchPage: () => {
      cy.enterText(enterLocationInput, value.dumfries);
      cy.get('.pac-item', { timeout: 10000 }).should('be.visible');
      cy.enterText(enterLocationInput, '{downarrow}');
      cy.enterText(enterLocationInput, '{enter}');
      cy.get(latInput).should('have.value', value.dumfriesLat);
      cy.get(lngInput).should('have.value', value.dumfriesLong);
    }

The magic piece of the puzzle for me was making sure that the gmaps suggestion items were actually there before I tried to choose one of them.

I did this with the following line of code where .pac-item is the class of the Gmaps Autocomplete suggestions



cy.get('.pac-item', { timeout: 10000 }).should('be.visible');

Huge shoutout to this stack overflow answer, https://stackoverflow.com/a/60065672/9057687

I now have a passing test, WOOHOO!!!

Where's the code you jabroni?

https://github.com/GrantHair5/cypress-google-maps-autocomplete

I have created a small example repo.

You will need to add your own Google Maps API Key secret in the fashion of an environment variable or a .NET user secret.

User secret would be like the following



{
  "GmapsApiSecrets": {
    "ApiKey": "MY SUPER DOOPER SECRET KEY"
  }
}

Please feel free to fork or clone down that repo and have a play around with the code.

For anyone who has not used cypress testing in the past I'd whole heartedly recommend it. Massive shout out to our Automation Tester https://github.com/karenpetrie for introducing us to the mysterious ways of automated testing.

It is baller.

Anyways, I'm out, hope this is of help to someone

Bye 👋

Decremental Improvements aka The Longest Blog Post Ever

Grant Hair — Wed, 28 Apr 2021 08:20:37 +0000

Photo by Paweł Czerwiński on Unsplash

tl;dr;

This conference video from HackConf Bulgaria 2019 (I attended yay) was the catalyst for me.

Bozhidar Batsov: The Groundhog Development Method

Intro

This post is entirely opinionated and is based on my experiences, please take it with a pinch of salt.

I apologise it is lengthy.

History

Since the beginning of time (1 January 1970 00:00:00 UT) programmers have been striving to write code.

For sometime we wrote very little code at all

Then we began to write lots of code (obviously not just for Hello World)
https://en.wikipedia.org/wiki/Plankalkül

Then programming began to get a little easier

https://ourcodingclub.github.io/tutorials/fortran-intro/

Fast forward sometime and you find yourself in the land of "high level languages" you know the simple stuff that even your wee old granny could write from her rocking chair...

That is an implementation of hello world in C btw

https://www.quora.com/What-is-the-most-complicated-C-code

Solution

I see where you are going with this...

The issue is the lines of code and the fact that as a native English speaker I can't properly say what I am trying to do with these languages...

We need more packages, we need more abstraction.

So we gave the world packages. We gave the world languages that were pretty much plain English. What did they do with it? They threw it right back in our faces.

"I amn't using a package it could have anything in it." - They say as they proceed to write the exact same code as in the package.

Dogfooding innit.

Then began the process I like to call "meme based programming"

Off topic, c'mon Grant get back here!

Anyways the point I am making is that as programmers... we suck... we write crap that we aren't proud of on a daily basis.

It's ok though because we always have a solution... right.

If someone was to hire me to write code with the processing power of a calculator, without my safety blanket of C# without ReSharper, without Google, without Stack Overflow to send a rocket to the moon I would end up with at least something on fire.

I still don't get it

Anyways enough memes and stuff...

The point is we will write some garbage, sometimes we can't control this. Sometimes that hot steamy garbage was the best thing we could come up with at that point.

But...

How often do you look at that hot steamy garbage and think "What was I thinking?"

Probably quite a lot.

But due to scope and other constraints you never do anything about it because hey "It works" - (TM) every programmer ever at some point.

Some solutions I try to use.

Lets say you have a little bit of "slack time" you managed to get that feature done a few days before expected.

There is a piece of code that you didn't write for this feature but it is in the same class or file that you are working in. It has been there for sometime. It is absolute hot garbage. I am talking this kinda code

https://levelup.gitconnected.com/reviewing-the-worst-piece-of-code-ever-db2df8730c76

https://shitcode.net/worst

"Most" of them are "easily" refactored but you can guarantee that I have written some awful code in my time. The kind that you look back at and think "Did I fall and hit my head that day?"

Take some time, refactor the garbage.

Before you do that find out something extremely important.

Does anyone actually use this garbage.

What I mean by this is...

Lets say your garbage code is on a page that 0.46% of users (<1%) actually visit. Is there much point keeping that garbage code page around?

If that 0.46% of users is the directors of the company then probably. Discover who uses what and why they need it.

This is possible if you:

A: Know the entire code base and your domain inside out.

B: Have excellent analytics and/or have "internal products"

Obviously sometimes the above is impossible due to external factors.

But lets say you can refactor 100 lines of absolute garbage into 50 lines of nicely abstracted method code.

GitHub will show this as a red PR and for me red PR's are the gold standard of PR's

Obviously in the above image I added 37 changes, a new feature, yay that's great, new code woo.

But I also managed to remove 4 lines of code. Doesn't seem like much but those 4 lines of code made that repo a bit less manageable. Scale that up to 400 lines and you have removed a real nice bit of your app.

Less code = less overhead = more time for the "cool" stuff

People talk about strangler pattern rebuilds/refactors where you identify core logic in an application and "strangle" down your application by lifting and shifting unnecessary pieces of logic out into microservices or packages until you are left with this really nice small, concise piece of code that is easy to manage and allows you to move really quickly.

This is just an ideology. Why should it be confined to the constraints of a rebuild.

If you apply that mindset to your working day or even side projects then you start to attack some of the parts of your repo that keep you up at night.

Lets say you know for sure that there is an absolute nightmare piece of code inside an API endpoint. It's sole purpose is to transfer data that isn't all that important to a message bus mechanism which is then picked up by a cron scheduled function to place this data off the bus into a database.

This code keeps you up at night because the cron function keeps erroring out because of network issues between the bus and your cloud provider.

Why can't you just refactor out that technology and handle the writing of this non important data directly in the API. It's not very cool for your CV but sleep is great for humans.

The above is probably the worst example ever, but what I am getting at is sometimes the "correct" choice is the most basic choice.

Because we removed our message bus and our cron function we can also remove our implementation of CQRS in the API. Bye Mediatr, Bye MassTransit.

We now have one very basic Entity Framework call. Our flow for this non vital data has gone from

User submits -> API -> DataSubmittedRequest -> -> HandleDataSubmittedRequest -> MassTransit -> MessageBus -> Emit Event -> Cron Function Picks up message -> HandleDataSubmittedRequest -> Entity Framework -> SQL DB

To
User submits -> API -> Entity Framework -> SQL DB

Ok sure now we have lost some fault tolerance if the DB write fails the data may be lost but that is the trade off to weigh up sometimes.

Sometimes allowances have to be made for simplicity but 99% of the time optimistic success will get you very far and your team will be happier as they don't have this overhanging fear of something complicated breaking on a Saturday night when they are having vino with friends.

I am 1 developer working on an open source project

If you get GitHub issues in on an open source repo (or you can apply this to your company, it is a little more difficult though) you have 3 options:

1: Blindly accept the suggestions and implement because if its important to 1 person it must be important to everyone.

2: Wait for more +1s on this issue and weigh up importance before implementing.

3: Be very firm with your core goals. Reject anything that does not align with these core goals or directly add value to these core goals. I.E my app does 1 thing and it does it excellently, no I won't add "Stories" to my app

Now option 3 probably won't win you many popularity contests but it is the option I would probably choose. If you begin to add features to applications do this with extreme caution.

The family hypothesis

Think about your application like a family:

You have 0 kids, no partner, you rent a really nice apartment in a cool part of town.

You look after yourself and that is it. Life is easy. You have great hair and enjoy reading and learning new languages.

Todo lo que necesito es vino y un gran libro.

Then you find a partner. A new "feature" in your life.

Now you share your time with this new feature. I apologise that sounds horrendous and I apologise to my fiancée, you are more than a feature to me 😂

You no longer learn new languages because the Duolingo owl "annoys your partner" instead you have both decided that you need to buy a house because you both want to add many new features.

You now can't drink expensive Chilean wines because you are in a code freeze to be in a great position to add a really nice big feature to your app.

I hope your still following because I am getting lost 😂

You buy your first home. A really big one you saved all your money to buy it.

Everything is great everyone loves your home. It is the best home they have ever seen.

Then a pipe bursts. You cry a lot. You have to code overtime to fix this issue.

After several days you have fixed the issue but because you have been so focussed on that you haven't spent any time with your partner so now you have an issue there you need to fix.

Many "I'm sorry"s later you have resolved your "partner bug" so you decide to add a new feature to celebrate.

This feature took a lot of time to build. Lets say 9 months or 19.5 sprints.

Now you have no time to maintain the core application, you begin to lose your hair, you now remember none of the Spanish you learned 8 years ago, your knees hurt a lot, the new young dev that we shall call "Node" scares you at work because you don't speak their language and don't have the time to become their friend even though you wish your application was more like theirs.

After a little bit of time you add another feature. This time you get through 2 features at once "twinned features" we shall call them.

You have no idea how you are gonna get through this backlog now.

Everyone tells you that your application is great now. The best app they know, 5 stars.

You feel burned out maintaining this massive monolithic application.

Your "home" feature develops a "hole in roof" bug. This is extremely expensive and has caused the "aaaah theres water everywhere" bug

You decide to run away to Aruba. You just wanted to build an easy application and enjoy life.

If only you had rejected that initial pull request.

The above example is obviously not real life but you see how its very easy to take something simple and low maintenance and turn it into something that seems "daunting and insurmountable"

Now please whatever you do. DO NOT APPLY DECREMENTAL IMPROVEMENTS TO YOUR FAMILY. You will probably end up in jail. "But your honour, I just opened up a red pr like the random blog post told me to"

Wow, thats morbid. I apologise.

Conclusion

I waffled a lot there.

I apologise for that but I was vomiting stuff onto screen.

This post could probably benefit from some decremental improvements.

In a nutshell.

Identify ways you can make your codebases smaller or more easy to maintain.

It will make your life easier.

Please delete cautiously. Don't delete the main app logic.

Somethings cannot be refactored. This is ok you can't win every battle.

Be cautious when blindly adding new "features" will this cause massive headaches months later for not much return.

Sometimes it is ok to push back. Fight your corner for why something shouldn't be added.

If a feature does add real value or it is business critical obviously you can't deny everything, we do still love to write code.

Great analytics help you to chop down huge code bases by seeing what's needed and what's not.

It gets me all warm and fuzzy when I delete huge chunks of code.

Hall of Fame

Comment your best refactors or biggest project deletions in this post.

Mines is:

12,490 lines deleted and 0 new lines added.

I wept that day. TEARS OF JOY

Anyways I hope this EXTREMELY long post has been of help to someone.

Thanks, Bye 👋

Knowing when your writing sucks

Grant Hair — Tue, 13 Apr 2021 09:03:11 +0000

I recently started a series I called the Bullet Point Series.

https://dev.to/granthair5/bullet-point-series-intro-2hpo

This series was awful.

The topics of conversation were too vague.

The bullet point lists were far too long.

Part 1 came before the intro.

The whole thing was a mess.

But I thought I was being really clever. Oh yeah short sharp blog posts is what people want that will really take off I thought.

I could not have been more wrong. My implementation sucked. My writing style was lazy. It felt robotic and un-personal. That makes it very difficult for people to relate.

I gave this series a few weeks, no one read it and it fell into the abyss so at that point I had 2 options:

1: Continue writing in the hope that maybe I'll get lucky and this idea will really take off.

2: Call it quits and know when to back out and try something new.

I chose option 2 due to my programming background. Sometimes instead of following Alice down the rabbit hole the best option is to say "Nah forget that" and walk away to the pub. I usually choose this approach when tackling "impossible" bugs in a technique I like to call "next day programming"

Usually, the next day that "impossible" bug doesn't seem all that impossible but if you continue to bash your head off the wall chances are you won't break down the wall you'll just end up with a headache.

So, to the handful of people that read the bullet point series I thank you but I am more grateful to those of you who chose not to read it because I feel we learn more from the stuff that doesn't work or the mistakes we make than the glory we can easily become accustomed to.

Stay tuned for more non bullet point series posts and I hope you all enjoy what is to come.

Thanks, 👋

Bullet point series - Part 2 - Some pretty sweet Visual Studio Extensions I Use

Grant Hair — Fri, 02 Apr 2021 08:53:07 +0000

Visual Studio

Viasfora, https://viasfora.com, Rainbow braces, keyword highlighting, I feel that this just makes it easier for me to navigate code bases.
Codemaid, https://www.codemaid.net, cleanup on save, cross team formatting practices, this allows me and my team mates to have the same formatting, its just a real sweet timesaver, makes your code pretty too.
Resharper, https://www.jetbrains.com/resharper/, personally for me the holy grail of extensions, I sometimes feel I don't know C# but rather I know Resharper, it will save you soooooooo much time. Most of its functionality is being rolled into Visual Studio now though.

Visual Studio Code

CTRL + SHIFT + P for the win

Docker, https://code.visualstudio.com/docs/containers/overview, add Dockerfile to workspace is my best friend. https://code.visualstudio.com/docs/containers/overview#:~:text=You%20can%20add%20Docker%20files,add%20them%20to%20your%20workspace.
Prettier, https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode , make your code pretty
Live Server, Launch a server for your static sites yes please, no more file path browsing - https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer
GitLens - https://gitlens.amod.io/#features , see who did what, when and why in your IDE and also quickly see any changes you have made

That's probably enough for now

Have a great weekend, hope this was of help to someone 👋

Bullet point series - Intro

Grant Hair — Thu, 25 Mar 2021 11:10:32 +0000

Hello,

Firstly excuse my idiocy, I published part one before the intro.

Damn it Grant, remember the semver training we did.

I will try keep this brief.

I am going to try and write some bullet point series posts on a regular basis. These will be hopefully short and hopefully easily digestible little nuggets of knowledge.

Stay Tuned for more code shenanigans

Bye for now 👋

Bullet point series - Part 1 - My PR Best Practices

Grant Hair — Thu, 25 Mar 2021 11:05:46 +0000

Welcome, to what I hope will be something that I remember to do frequently which is a bullet point series.

This will be quick to read and hopefully useful little nuggets of knowledge that I may or may not be correct on haha.

Lets get to it...

This list is not exhaustive and might differ from your best practices but this is what I tend to try and go with and it seems to have improved our teams PR conversion

Start with great branch names, I like to follow the convention of grant/TICKET-NAME/SHORT-DESCRIPTION e.g grant/JIRA-1234/Add-Centralized-Caching this is useful as you can very quickly know who to go to for further information

Make smaller pull requests, think about it how many of us would read in fine detail a 300 files changed PR

Give yourself an early chance of finding any crap by self reviewing. You will not believe how much stuff I've found doing this. Add PR comments on anything you think might be confusing to someone else or the reasoning behind a decision. Draft PR's are your friend for this.

Use descriptive and declarative commit messages the practice I use is to in my mind prefix all commit messages with "If applied this commit will..." This gives the reviewer a recipe for your PR and they can see how you got to the point you are at now.

If you PR is for a bug fix where applicable add bug trap testing, this is a test around your bug fix. This allows the reviewer to see in terms of code what went wrong, what you did to fix it and also what you have done to test it, It also means that in future if your code is modified in any way the bug trap test may fail and prevent anyone introducing that same bug again.

Use a PR template, knowing exactly where to go in a PR description every single time to get the information that you need will save you so much time long term trying to sift through a paragraph. I usually use something like this https://gist.github.com/GrantHair5/97b5564131376888cc45c4c35d68a3bc

If it is a visual change please add a screenshot or GIF it helps the reviewer so much with understanding your change.

Please spend the time to write a good PR description put yourself in others shoes. If you spend 5 minutes now that saves every reviewer 10 minutes and you have 3 reviewers there's a half hour saving right off the bat. "Fix broke stuff" doesn't cut it anymore haha

Don't treat PR comments as a blocker, treat them as a way to collaboratively better your codebase, you might have missed something, PR's should be a safe space, if something is worth doing and someone else has put the effort into putting a change request in give it the credit it is due and talk it through with someone.

Don't be scared to tell someone in a PR that they've done a great job, go crazy with emojis and GIFs it makes your repo a happier place and might give someone a little boost for the day. Be Kind to people.

Red PR's are the best PR's, I call this decremental improvements and I'll write a little post about this later on but basically delete pointless stuff, we can always recover some comment that was in a code base. SCM LYF ❤️

I'll call time on this there, the bullet points got kinda lengthy but hopefully something in there will be of help to someone.

If you have any best practices you usually follow shoot them in the comments below I am always looking to improve processes.

Bye for now 👋

Any other yerba loving devs out there?

Grant Hair — Thu, 18 Mar 2021 09:19:32 +0000

I got into drinking Yerba a few years ago after a fellow developer introduced me after his travels of South America check him out here https://backpackerdeveloper.com/

I find that Yerba Mate helps me stay focused for longer than coffee and I just generally enjoy the taste more.

It also looks real cool and makes people wonder "what is that dude drinking"

There are also some proven and some unproven health benefits https://www.healthline.com/nutrition/8-benefits-of-yerba-mate

The Yerba subculture is also something that fascinated me and I have learned so much and have passed on some knowledge and tricks to colleagues looking to take up the fantastically social dance that is a ronda de yerba, we even have a Teams channel dedicated to that now.

I am currently enjoying Rosamonte (IT MUST BE ESPECIAL) and Cruz De Malta (my first time trying Cruz)

excuse the messy desk, I like creative chaos

Does anyone have a favourite Yerba they like to drink while coding or anything they could recommend?

For anyone interested I get my Yerba Mate from here https://urushop.co.uk/ it is a great place to get Yerba in the UK

My setup is as follows:

Gourd/Cup - https://urushop.co.uk/shop/yerba-mate-accessories/mates-gourds/thermal-stainless-steel-mate-cup/
Bomba/Bombilla (I like bomba cause the wider mouth gets more flavourtown in my mouth) - https://urushop.co.uk/shop/yerba-mate-accessories/bombillas-straws/stainless-steel-brazilian-bomba/
Mate - https://urushop.co.uk/shop/yerba-mate-from-south-america/1kg/yerba-mate-cruz-de-malta-1kg/ or https://urushop.co.uk/shop/yerba-mate-from-south-america/1kg/yerba-mate-rosamonte-especial-1kg/
Flask aka my love HÄLSA - https://www.ikea.com/gb/en/p/haelsa-steel-vacuum-flask-blue-40450637/

Look forward to any suggestions 👋

🧉

How I decompress as a developer

Grant Hair — Wed, 17 Mar 2021 14:30:52 +0000

tl;dr;

Care less, Buy a dog, Go to the forest and shout at trees

As a developer it is very easy to become swept up in problem solving, imposter syndrome, comparing ourselves to those around us, office drama, overwhelming deadlines, obviously Covid-19 and how that has affected our lives and so much more.

I think for some people that are developers and this is a generalisation that some may not feel, we are viewed as people that have an extremely easy lifestyle and we just play table tennis 95% of the day, watch YouTube 4% of the day and make buttons on screens the remaining 1% of the day then we get to finish early and go grab some sushi with our other dev friends.

This doesn't usually leave us much room to complain about some deadline that we are scared we might not meet or that one runtime bug that you just can't squash or that crushing feeling that you have no clue what you are doing 99% of the time and you feel like you spend all your time copy pasting the code of smarter people from Stack Overflow and when you reach a point where that doesn't work and you have to dust off the cobwebs and flex your own brain it can't seem to get past 1st gear.

I think as we are usually painted as highly intelligent people that can solve complex problems like putting a button on a screen and making it clicky click, people often assume we have all the answers in our big beefy brains and will never have that feeling of inadequacy but throughout my career I can remember vividly all of these times whereas I struggle to remember my "rockstar" moments where I absolutely crushed some issue or made something that saved a colleague a bunch of time.

Then I remember that this is extremely common for most people regardless of their career path.

Do you remember that time you ripped your shorts in High School in front of the whole class, I guarantee you do but I guarantee that hardly anyone else in that class does. This is because as creatures we always store these traumatic events in our mind and other people don't have the space to remember your traumatic events because they have their own crap going on up there.

So the next time you say something that you think is "stupid" in a meeting full of people that you assume are better than you or commit some code that you think is the worst code ever or get asked a question that you don't know the answer to just remember that although it may be painful now after the moment has passed there is a high chance that no one but yourself will look back on that moment. The important thing in that moment is that you use it as an experience to learn something.

Remember when you were a kid and you were learning to walk, remember how many times you fell over (probably not because you were an infant but you get my drift) that traumatic experience is what allowed you to learn to walk, so if the same very basic logic is applied to your professional development and every time you make a mistake, do something outside your comfort zone, take a risk that doesn't pay off or just do something that 5 minutes later you are like "Why did I commit that, oh no people will think I am a moron and I am sure to get caught out as a fraud" (yes I've been there) then please try and ask yourself these questions:

If I did this again, knowing what I know now, what would I do differently?
Did the world end because of what I did?
Did I do what I did because I thought it was the right thing to do at that time?

Did the world end because of what I did?

Is probably the most important question I ask myself whenever I make a mistake.

It is very easy to get yourself all worked up because you committed something like the following

if(thisBoolShouldBeFalse)
{
  DoSomethingThatShouldHappenWhenBoolIsTrue();
}
else
{
  DoSomethingThatShouldHappenWhenBoolIsFalse();
}

Now unless the code above is the main logic behind some kind of nuclear device then the world probably didn't end because you committed that and it made it through PR and then out to users for a day until it was highlighted.

Hey we all make mistakes and sometimes as "Developers", "Engineers", "Evangelists" or even "JavaScript Ninjas" we don't always like to show our flaws because often our imposter syndrome is so crushing that we feel even one tiny mistake will push us off our elitist pedestal that we have placed our self on, the best developers that I have worked with are the ones who will make a mistake and then find it and be like "Haha look at this crap that I wrote here is what I did to fix this..."

If you adopt the above approach then I feel like a lot of weight will be lifted from your shoulders because honestly the majority of us developers even though we may be scary on Stack Overflow are really nice people at heart and we just want to see those around us succeed.

It is ok to feel overwhelmed.

It is ok to feel scared, I feel scared when people talk about stuff at a very technical level because my mind works best at "beep boop I make computer go now" and large architecture diagrams, "lets talk about algorithms", "what design practice did you use for X?", acronyms for acronyms sake and Big O scare me a lot and I used to pretend that I knew all this stuff until I asked one day "What does that mean?" and the dev answered "I don't know either haha"

It is ok to know what you know and also what you don't know but it is also ok to not know what you don't know, our environment as computer wielding ninjas is always changing and it's ok to not be super up to date with stuff that's why the internet exists we live in a time where any information you could ever want is literally available in a TikTok video, as a meme or as a blog post so cramming books into your brain might not work for you, that doesn't make you worse that the other dev that devours O'Reilly like they are California Rolls (circle of life it all begins and ends with sushi)

The main thing to remember is that computers are just rocks that we tricked into thinking and if at the end of the day the world is still spinning your code can't have been as bad as you thought it was.

Find your people that you can talk to, I often use https://devrant.com to rant about code and other stuff that happens that were I to talk to a non developer about they might just not get it, sometimes you just need to shout about stuff and get someone that is like "I know right".

Ok, nice Ted Talk get to the good bits.

As I live in Scotland, a mostly beautiful country, and because I am very much not a city boy (I grew up in mostly farm lands where there are very little computer based jobs, check it out here if you are interested https://goo.gl/maps/m1FQbhnY3KBu4W1e7 & https://en.wikipedia.org/wiki/Dumfries), I like to escape to the country, now that has been difficult given the current restrictions so I have had to do some digging around what is available where I live now, this in itself is a joy and I have a list of places to go to now.

I usually just go to Google Maps, turn on satellite view and try and find anything green or beachy that I can drive to under the current restrictions.

I have been able to find some pretty sweet forests that are usually fairly deserted and as I got a lockdown puppy (a black lab named Luna) I like to take her walks through the quiet wooded areas, up some hills or over large moorland.

This gives me the time that I need away from screens and I can truly feel disconnected for a period of time. After the working day is done I make sure to put the lid of my laptop down and try take at least 30 minutes away from people and screens, this gives me the time I need to become centred again. If you can spin around 360 and not see another person then even better it is time for some soul cleansing shouting.

I feel like that's enough clichés for one blog post but to conclude:

Find your people that you can have open honest discussions with
No matter how small or insignificant you feel your problem is it is always best when shared often philosophical ruminations will only eat away at you and like the avalanche that begun with a snowflake it can very easily overwhelm you
Never apologise for asking what you feel are "dumb" questions, if it is important to you it should be important enough for those around you
Don't let your mistakes eat away at you, 99% of the time you will be part of a team of developers that are there to catch you if you fall, use them and learn from your mistakes because we all make them
Imposter syndrome happens to even the most seasoned developers, there will always be stuff that you don't know, you are not an Encyclopaedia of knowledge, you are an unfinished autobiography.
If it all gets to much shouting at trees can help
Care less about what other people think because they are probably caring too much about what you think of them to even care about what they think about you.
Sometimes the oldest clichés are the most applicable to blog posts. That's why pencils have erasers, a problem shared is a problem halved, sometimes mistakes that you think you've made can be perceived as moments of genius from others viewpoint, fake it till you make it etc

If anyone would like to chat about any of the above or any feelings they have around imposter syndrome etc then either drop a comment below or fire a social media message at me, links should be in my bio because we are all in this together and some of the stuff that you are feeling right now high chance is I will have felt it to or are currently going through it.

The above is anecdotal from my experience as mid level engineer and is in no way targeted so I hope it can be taken in the way it is supposed to be taken, a light-hearted jab at some of my misfortunes and shortcomings to take the edge of an extremely sensitive subject for most and hopefully break down some walls or anxious feelings that some may have to be the catalyst for a discussion point, if we all open ourselves up to the idea of making ourselves look "stupid" then it hopefully breaks the feeling that it is such a bad thing to do.

If you would like to see more random pictures from my adventures I usually post stuff on my Instagram here: http://instagram.com/granthair96

I will also hopefully follow this up with a "Here's the stuff I don't know in 2021" post similar to Dan Abramovs "Things I Don’t Know as of 2018"

https://overreacted.io/things-i-dont-know-as-of-2018/

That article really opened my eyes and made me realise that because I don't know how to convert binary to hex, because I don't fully understand what a strategy pattern is or because I don't understand how routers work and now I'm too scared to ask it doesn't make me less of a developer.

Thanks, I hope this was of help for some 👋

A couple ways I test my .NET APIs

Grant Hair — Fri, 26 Feb 2021 16:16:02 +0000

Recently I have undertaken some work that required either building a whole new API or regression testing another API.

Through that experience I used 3 techniques to help build my confidence that what I was building actually worked, these are:

Unit Tests
In Memory API Tests with WebApplicationFactory<TEntryPoint>
Newman Tests

I will assume that everyone is familiar with unit tests in C# but just a quick note that my favourite framework is XUnit. I really enjoy the simplicity that it brings and allows me to get up and running super quickly.

In Memory API Tests with `WebApplicationFactory<TEntryPoint>`

tl;dr;

Check out this GitHub repo

https://github.com/GrantHair5/DotNetApiInMemoryTests

It has some pretty nice examples at a very basic level I'm taking lets get some fruit from a basket kinda stuff.

How?

The MVP of this test is WebApplicationFactory<TEntryPoint> it allows me to run an in-memory version of my API using TestServer this gives me access to a HttpClient and also my actual API. I can then send HTTP calls to my API as I would do in real life and assert the responses.

This is a great time to plug one of my favourite NuGet packages, FluentAssertions. It gives you the ability to assert test cases using plain English style language and makes complex test assertions a breeze.

Anyways,

To use WebApplicationFactory<TEntryPoint>

You would write something like the following:

public class ApiWebApplicationFactory : WebApplicationFactory<Startup>
    {
        protected override void ConfigureWebHost(IWebHostBuilder builder)
        {
            builder.ConfigureTestServices(services =>
            {
                services.AddTransient<IFruitBasket, StubbedFruitBasket>();
            });
        }
    }

ApiWebApplicationFactory will become your new best friend.

Basically this is allowing us to override the default implementation of IFruitBasket with our new StubbedFruitBasket perfect for testing stuff with.

Then I inherit ApiWebApplicationFactory into my next best friend IntegrationTestBase which I use across each of my integration tests to get access to that sweet sweet in memory API.

 public class IntegrationTestBase : IClassFixture<ApiWebApplicationFactory>
    {
        protected readonly ApiWebApplicationFactory Factory;
        protected readonly HttpClient Client;

        public IntegrationTestBase(ApiWebApplicationFactory fixture)
        {
            Factory = fixture;
            Client = Factory.CreateClient();
        }
    }

Then my tests look something like this:

 public class FruitApiShould : IntegrationTestBase
    {
        public FruitApiShould(ApiWebApplicationFactory fixture) : base(fixture)
        {
        }

        [Fact]
        public async Task Return_Two_Fruits_From_Stubbed_Basket()
        {
            var response = await Client.GetAsync("/api/Fruit/Basket");
            response.StatusCode.Should().Be(HttpStatusCode.OK);

            var basket = JsonConvert.DeserializeObject<IEnumerable<Fruit>>(await response.Content.ReadAsStringAsync());
            basket.Should().HaveCount(2);
        }
}

If I want to override the stubbed implementation of my IFruitBasket I can do this by using my ApiWebApplicationFactory Factory from IntegrationTestBase to call Factory.WithWebHostBuilder() like so:

[Fact]
        public async Task Return_Four_Fruits_From_Real_Basket_Overriden_By_With_Web_Host_Builder()
        {
            // WithWebHostBuilder will allow us to override the base Client with any new services that we require.
            var client = Factory.WithWebHostBuilder(builder =>
            {
                builder.ConfigureServices(services =>
                {
                    services.AddTransient<IFruitBasket, FruitBasket>();
                });
            }).CreateClient();

            var response = await client.GetAsync("/api/Fruit/Basket");
            response.StatusCode.Should().Be(HttpStatusCode.OK);

            var basket = JsonConvert.DeserializeObject<IEnumerable<Fruit>>(await response.Content.ReadAsStringAsync());
            basket.Should().HaveCount(4);
        }

Simple right 👍

Some things to note

1: services.ConfigureTestServices() is called after services.ConfigureServices() in the natural pipeline allowing us to override implementations or configuration or databases etc.

2: The above is obviously not a real life implementation and should be used as a guide, any terrible code is not a reflection of my real life performance 😂

Newman Tests

I have probably already bored you to death so I'll just drop a tl;dr; here

tl;dr;

Newman is an NPM package

It allows you to run many http requests from a postman collection

You can write JavaScripty style tests against your collections, for me these were:

Is my status code 200

Is my JSON response what I expect it to be

It is super cool and helpful.

It saved me so much time as I didn't have to hit over 120 endpoints individually.

Check out this link for more info:

https://learning.postman.com/docs/running-collections/using-newman-cli/command-line-integration-with-newman/

Hope this was of help

See Ya 👋

The only way you should be handling exceptions in C#

Grant Hair — Wed, 24 Feb 2021 12:34:13 +0000

Enjoy ☀️

https://gist.github.com/GrantHair5/88a9f902d287cc5efc40cd4c63c81125

or if you enjoy a fiddle (that sounded weird but were rolling with it)

https://dotnetfiddle.net/E0JdC1

Forem: Grant Hair

How delegating handlers bit me in the ass and how I tested them

I used my first ever Expression> today to create reusable LINQ Queries

Cypress e2e testing with Google Maps Autocomplete

The Solution

Where's the code you jabroni?

Decremental Improvements aka The Longest Blog Post Ever

tl;dr;

Intro

History

Solution

Off topic, c'mon Grant get back here!

I still don't get it

Some solutions I try to use.

I am 1 developer working on an open source project

The family hypothesis

Conclusion

Hall of Fame

Knowing when your writing sucks

Bullet point series - Part 2 - Some pretty sweet Visual Studio Extensions I Use

Visual Studio

Visual Studio Code

CTRL + SHIFT + P for the win

That's probably enough for now

Bullet point series - Intro

Bullet point series - Part 1 - My PR Best Practices

Bye for now 👋

Any other yerba loving devs out there?

🧉

How I decompress as a developer

tl;dr;

Ok, nice Ted Talk get to the good bits.

A couple ways I test my .NET APIs

In Memory API Tests with WebApplicationFactory<TEntryPoint>

How?

Some things to note

Newman Tests

tl;dr;

The only way you should be handling exceptions in C#

Enjoy ☀️

In Memory API Tests with `WebApplicationFactory<TEntryPoint>`