I like that Godot has its own, simple scripting language in GDScript, but I’m a .NET tragic so it’s C# for me. Interoperability between the two is possible, but not always obvious. Case in point, how do you await an async GDScript method? Well, it depends…

As part of an upcoming piece of work, it was suggested to me that I spend some time getting familiar with Tailwind CSS. I’d heard good things from colleagues, one comment in particular suggesting it doesn’t hold you back like other CSS frameworks. So I was quite keen to dig in and see what was so special about it.

Go big or go home! I’ve been working on and off this project for nearly ten years. Originally developed in Unity, I’ve moved to Godot because I’m an Open Source shill.

There’s not much here yet I’m afraid, but I hope to write more about this soon.

I took some time to investigate developing a MAUI mobile app that shares business logic with a Blazor web app by way of ViewModels and the like. What I discovered was that MAUI and XAML is a pretty cumbersome framework. My colleague Kael gave me some insight on the possibility of building a Blazor app and running that as a MAUI app. After looking into it in more detail I came to the conclusion that having a single application with multiple deployment targets is a more practical approach to cross-platform development. This article serves as a guide to developing a single application that can be deployed as both a website and an Android app. Of course there are a few platform specific things to look out for but they’re easily handled as I will demonstrate in this post.

Fluxor is a Flux implementation for Blazor in the vein of Redux. It is a state management system designed for larger software systems that encourages immutability of state, pure functions and clean separation of code. Given my fairly basic understanding of the Flux pattern I thought it would be valuable to document what it is at a high level and what’s required when using Fluxor to implement the various concepts.

MVVM is a development pattern that has been around for a while now. It was designed to facilitate the development of WPF applications for Windows and is still used for the likes of Maui apps. I reckon it has a place in Blazor apps as a neat way to separate view from logic, and as a sort of volatile state management for when you don’t want state to persist between pages.

A published Blazor WebAssembly instance is just a collection of files that can be loaded into a browser. If these files are hosted on the API, running the API means the UI is running as well, probably from the same address. In this case it’s a little different to debug compared to launching it standalone, but not any more complicated.

I couldn’t find a single-page cheat sheet that summarised SOLID software development principles, so I made one. For each of the letters in SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) there are a couple of bullet points explaining the benefits of adopting them and the smells that betray their violation.

Today I spent a bit of time fighting with certificates in an ASP.NET application I’m working on. The scenario is we have Blazor Server communicating with a Minimal API. Debugging locally I was struggling to get the two to communicate, with errors like:

The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot

I’ll talk more about why I think the Godot game engine is a good alternative to Unity as part of my alternatives series of posts, but for now I want to share for posterity’s sake how to use SQLite.NET in Godot. Skip to the end to add the one package necessary to get SQLite.NET working in Godot. For the uninitiated, SQLite.NET is an ORM for SQLite, similar to Entity Framework. SQLite is a good fit for games and I’m fond of using an ORM where possible.