I’ve started this little series of posts about things that I remind myself frequently enough to make into my screensaver.

For each of these items, there’s a story and some thoughts that pop into my head when I see them, and I wanted to share them with you.

Here are the screensavers that I’m flicking through each day.

• Kindness is better
• Complex == Bad. Simple == Good - This post
• What would Jesus do?
• (DO(SOMETHING(SMALL(USEFUL(NOW())))))
• Turn up the good

I’ve been in a slump in my life, which just about knocked me out totally, experiencing a few years with fatigue syndrome and depression. Getting out of that is an ongoing process and I find myself leaning back on old lessons, but trying to make them more real in my life.

One thing that I did was that I added a few sayings that I’ve picked up and that builds me up, as screensavers.

Screensavers, kids, was an old thing that we had running on our computers when we didn’t work at them. Otherwise, the old monitors would etch the text shown into the screen permanently… but they were totally safe sitting in front all day. I’m quite … BZZZT … normal.

I wanted to share them with you and also what I’m thinking about when seeing these sayings or phrases.

Here are the screensavers that I’m flicking through each...

I’ve just started a lot of new things in my life; programming Scala (and Python), data engineering and a new client.

Luckily the things we have built until now is algorithmically pretty simple and … what was that? Calculate the what-now temperature?! The wet-bulb temperature? Wash your mouth with soap, young man! What on earth is that?!

And you want me to write this in Scala?! This is horrible.

In this blog post I’ll walk you through my thinking and application of experience to write one of the most complicated calculations I’ve ever put into a program, in a programming language that I’ve never seen 2 months ago.

It actually took me all of 1 hour to get this to work - and still be confident that it works.

I’m learning a brand new programming language. That should probably say, new for me.Because it’s Python. I haven’t touched it before. Yes yes - I’m slow, old and everything. But I am still learning new things… so I’m not all in all bad.

Ok - Python is for the most part very nice to work with and reading and writing code has been easy so far. Until I saw a backwards for-loop. It just looked… weird.

Turns out it was not a for-loop at all, but rather a list comprehension.

I had the great joy of teaching a course on Next JS 13 this last week. Next has for a long time been a favorite of mine and with version 13 they have really stepped it up a notch. Or three.

But what they still are lacking, and for the life of me I cannot understand why, is a good out-of-the-box testing story.

This caused me and the group I was teaching considerable head-ache - especially when we tried to test the server-side async components that Next.JS is plugging hard.

Therefor I have two goals with this post:

1. Help me (and you?) to easily get started with testing
2. Show a way to test async server components

Let’s do this.

I’m putting together a course where I want students to easily deploy their code. Since the course is on .NET 6 WebAPIs (and Entity Framework (core)) I thought that Azure would make a great choice to deploy to.

And nowadays ARM templates seems to be the way to go (maybe BICEPs but I’m doing ARM for now).

But I ran into problems, and I wanted to share with you those problems and how I overcame it. Just your normal post on this blog in other words.

I just had an aha-experience that shook me; first I found it interesting, and then I was ashamed that I haven’t realized this before.

Here it is:

Plans are theoretical

Let me tell you how I realized this and how I think it is important.

I’m writing a boot camp for .NET core and have started to learn a lot of things that have changed since I last coded C#. One of them was shown to me by my good friend John Magnusson. (I’m downplaying his knowledge and skills a lot here since I was close to tears and he sent me a link that saved by bacon, but hey - I’m telling the story :))

Anyhow - John showed me Microsoft.AspNetCore.Mvc.Testing that really tells a nice story when it comes to testing an API. In this post I wanted to show you how I used it.

Also - I ran into problems, since I had a database seeding that didn’t work when I used the suggested solution. I will show you how I solved that too, and in the process, tell you a little thing I picked up about xUnit. And...

I’m enjoying myself at work right now, writing a course in C# and for the .NET core platform. Man - this was some time ago.

Naturally I learn a lot. That’s why I became a teacher. I wanted to share a little nugget (NuGet?) of gold that I found.

In one of the early labs in the course I used Selenium to write some end-to-end tests. And in doing so I need to create Driver object, that is both pretty heavy to start and, if left after the test run, quickly will eat your memory.

Now, I was using xUnit as my testing framework and xUnit doesn’t have a notion of test suites. This was bad since I wanted to create the Driver object on the first e2e test and not tear it down until the last.

My intial attempt looked like this:

I have a big project ahead here at Salt - I’m going to write an entire boot camp from scratch. This is done as a single-person project and all my other colleagues are working on as normal around me.

I wanted to report my progress to them so that they know what’s happening and also that I can get some leeway of keeping my focus.

In this post, I wanted to share a very simple prognosis tool that I created based on the data that my work create. As always, it’s not perfect but it will give an accurate enough feel for where I am and when it will be done