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 initial 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

I’m rediscovering my first programming love; .NET. I’m having a blast and .NET core keeps giving.

This post is one of those - I can’t believe that I couldn’t find this post on the net somewhere. Or I didn’t look hard enough.

But I wanted to setup Selenium testing, but only use .NET Core and Visual Studio Code on my Mac. Every example I saw was using older versions of .NET core (I’m writing this on .NET core 5) and/or Visual Studio, which I don’t have.

I rarely get paid to write code these days… or that is people rarely ask me to write code. But since I’m a programmer at heart it is one of the tools in my tool belt, regardless of what kind of tasks I’m given.

Today I got asked:

Could you please list all Open Source Licenses we are using, and all the dependencies all our code is using.

Considering we have 130+ repositories I was what the scientist refer to as a boring task.

Let’s make it more fun with code.

I like to automate repetitive and boring things I do in my daily work. This lead to that me write bash scripts from time to time, but the problem is that I’m a newbie script:er. I’m learning as I go.

And the other day I did a cardinal sin in scripting. Not only that - I decided to show the world. Now that is a point to feel ashamed or to learn. I did both.

In this post, I will tell you about how I made my curl-script a little better and a lot safer, but using an old way that’s been in curl for ages.

The background

I was waiting for the summer part of Salt to start and had an hour over. The weather was amazing and I found a nice tree to sit under. Of course, I flipped up the computer...

I’ve been increasingly annoyed with the fact there’s no easy way to add scripts to a package.json file programmatically. It always messes up my lovely scripts for tutorial setups and other use cases. Very frustrating.

Well … until not that is.

I give you ScrAdd - the script adder.

Let’s say that you are writing a tutorial on how to test next apps. You want the readers just to get to the place where you can start to talk about code. My friend - just scradd in that command and take the rest of the day off!

npx create-next-app demo cd demo npx scradd . test "mocha . -R dot -w" npm i -D mocha 

I don’t expect this tool to be widely used and spread but I was pretty fun to write it -...

I indirectly got a question that I thought would make a good blog post. The question came from the brilliant Emer on this LinkedIn post. That post in itself is a great read on the US Air Force’s thoughts on agile in general - great stuff in there.

Anyhow - Emer asked me:

Yes! I have read many posts by Allen Holub and our friend Woody Zuill on this. I do struggle though to find a way to practice “true” agility at a large scale. Do you have any good resources on this?

and I started to write a response but realized that I needed some more space. This blog post is that response.

Oh, man! I’m so happy that I’m still sane. This error was about to drive me crazy.

Here’s the back story - we have about 120 repositories with a lot of exercises and tests. This is nigh on impossible to maintain by hand, so we have written scripts to verify the integrity of each repository. Each script is verifying that installation, linting, and testing works as expected.

The whole thing is built-in bash scripts and for the most part, works just fine. It’s quite rewarding to have it checked automatically, read about it here

But the repositories that have been created with create-react-app have caused problems from day one. They work just fine when we use them normally, but in the script, it’s flaky at best and just hangs at worst.

But. Now. I’ve. Found. A. Solution.