A common dilemma within the field of software development is traversing too deep within documentation to discover the solution to a bug. This struggle can be represented and reflected in many aspects of life, however as developers we encounter this dilemma more often than not. This post is about how I fell into this dilemma and got bamboozled by Apple’s integrated development environment, Xcode.

It’s ten o’clock in the morning and I’ve just configured and bumped the dependencies for my client’s android application which they hadn’t touched for over two years. Everything looked decent and worked properly. I was now ready to further develop their iOS application which also hadn’t been developed on since early 2020. While trying to compile the application, an error message prompted from a custom script saying:

Every software developer should keep a diary.

Personally I’ve kept one for about a year now, and I’m very content. During some periods I haven’t bothered, and that’s OK. I can always write a new entry tomorrow, or next week.

The diary can cover a lot of different aspects from your daily work. Below are some examples.

• Things you’ve learned
• Accomplishments that you’re proud of
• Thoughts on dynamics within your team
• Sketches of ideas
• Reasoning behind technical decisions
• Solutions to problems that you’ve struggled with

I think the greatest benefit of writing a diary is that you give yourself time to reflect on your daily work. You will think about things that works less well and identify improvements for both yourself and your team. Sometimes we feel that we’re just standing still, not developing as individuals. By reflecting on accomplishments and things you’ve learned you can more clearly see that you’re actually growing as an individual, every day. You might reflect a lot already without writing anything about it. That’s great, but your brain might not be the most suitable storage solution in the long-term. Additionally, when writing thoughts or solutions related to different problems, you’ll get a personal knowledge base. If you encounter the same issue again, you can always re-visit your old diary entries.

tl;dr

TypeScript is already a great upgrade from JavaScript if you like types and want to ensure type-safety in your code base. Zod aids that goal by making sure that incoming data satisfies the purpose it is about to fulfill, among other features of course.

Zod is a TypeScript-first schema declaration and validation library with lots of features that I have yet to use. However, the basics are very handy and simple to get started with! For the purpose of introducing Zod, we’ll assume that we have a Node.js backend with an endpoint for adding a user to our system.

There are a few different approaches to testing in the spectrum between simple unit tests and complete E2E tests. If I had to choose one approach to prioritize I would pick integration tests.

The key reasons are:

• Tests a flow of multiple functions, in contrast with unit tests where only a single function is tested
• Self contained i.e. the test has no external dependencies on a deployed environment etc.
• Makes logical sense to test a complete function in a REST api, a single Lambda in AWS or an Azure function

The problem

In my case the goal was to setup a test suite for a .NET web api. I quickly realized that the naive way to explicitly instantiate every controller plus all dependencies would lead to lots of repeated boilerplate code in order to setup a test case. I also wanted to make use of the existing DI configuration.
So how to create a generic setup where new test cases is a breeze to create? 🤔

One of the projects we work with at Devies is related to the dental domain. In that project we use the dental notation (ISO 3950) to refer to teeth. Every tooth have an unique identifier that consist of two characters. The first character represent a quadrant (one of four areas in the mouth). The second character is an identifier that refers to one of the eight teeth in that area.

Early on in the project we represented the tooth identifier using a string, for example "42" (4 is the quadrant, 2 is the identifier). As the project grew we stared to use this tooth identifier in many different places in the project. Since we use a raw string, we had to make sure the tooth identifier was properly validated at every place where it was used. Additionally, it was unclear what the tooth identifier (string) represented, and it affected the readability of our code.

Documentation, while in many cases important, might not be the first thing you as a developer want to spend time on doing. Something you might do like as a developer is to spend a lot of time automating simple but tedious tasks in order to never have to do it manually again! With documentation being a particularly important part in our project we were extra keen on finding as many ways of automating documentation as possible. In this post I will go through how we utilized Conventional Commits, an Azure Devops extension called Commitizen and an npm package called Standard version to automatically generate changelogs in our Azure Devops CI environment.

A few weeks ago, we upgraded one of our projects from .NET 5 to .NET 6, since .NET 5 was nearing end of support. In this process, we ran into a few hurdles. This post will go through a few of them that were a bit unexpected, and why we ran into them.

AccessTokenValidation deprecated

This isn’t completely related to .NET 6 in itself, but we ran into the issue during the upgrade. While upgrading our Nuget dependencies, we had some trouble with mismatching version numbers on transient dependencies. While we tried to upgrade the IdentityModel package to a newer version, AccessTokenValidation had a dependency to an older version. It turned out that AccessTokenValidation had been deprecated since we added it. This was solved by removing the dependency by simply substituting a call to AddIdentityServerAuthentication with a call to AddJwtBearer. We don’t use Introspection to validate tokens in our solution, but it is possible to combine JwtBearer and Introspection using the ForwardDefaultSelection option.

Last week, while writing end-to-end tests for our Kubernetes application, we discovered a useful Kubernetes command. Namely, the kubectl wait command. We managed to stabilize our test using this command, and we will explain how we did it in this post.

We have written our end-to-end tests in bash, and they deploy and manage different Kubernetes resources. Bash scripts execute commands sequentially, waiting for the first to finish before executing the next one. Consider the following script, where we first deploy an Nginx instance and then read its logs.

TLDR: If you need to “trick” a local web server that you’re making requests to a certain domain, but do not want (or have permissions) to modify /etc/hosts - Set the intended domain in the Host request header instead.

We are currently working on a project where we have an nginx instance that is redirecting traffic for many different domains. In our case, the nginx is an ingress controller in a kubernetes cluster, but you might use a similar approach if you’re hosting multiple websites on the same webserver.

For the past couple of weeks, we’ve been working on a React app from scratch. Additionally, we’ve added pipelines in Azure as an attempt to achieve MAXIMUM EFFICIENCY when it comes to deployment and integration. So there we are. It’s a lovely morning. The sun is shining, the coffee is warm, and we’re ready to drop some lines of code! 😎

Last week we built and deployed a version of our React app that had a slightly faulty CSS attribute that made the header of the app take up the whole screen. Thus our first and foremost task was to fix it so that it only takes up a small area at the top of the screen. We used the Inspection feature in Firefox Developer Edition to pinpoint the faulty CSS and determine the issue, which we managed to do. The next step was to apply that fix in our code to see what would happen. The fix worked locally by running the React app using yarn start as well as deploying a Docker image. Great, the fix is ready to be deployed using our Azure pipelines!