Are you still downloading .exe files like some kinda chump? Check out Scoop, a package manager for Windows not too dissimilar to Chocolatey which ought to be very familiar to any Linux enthusiast. It’s fast, it’s easy to use, and it’s open source. Yes, Scoop is great but this article is not about extolling the virtues of the package management tool.

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.

This guide is mostly a reference for myself as it’s a workflow that I find myself following whenever I set up a new Linux machine. I’m sharing it here as I’m sure many will find this useful, and it will save me from looking up each distinct step in the future.

I also took the opportunity to add some bonus network configuration tips to get the most out of the setup.

I recently installed Fedora on my personal laptop to replace Manjaro as I found Manjaro to be a just a little too flaky for my liking and I know Fedora to be a solid alternative. During installation I was asked if I wanted to encrypt my drives. Now I’m not harbouring anything particularly sensitive but I thought it was worth doing, security first and all that; after all, we expect every website to support HTTPS these days so why not?

Well there is the matter of that mildly pesky login prompt on every boot…

When I set up my own SD-HDD solution based on the wonderful ACSI2STM project, I found the hard drive was becoming corrupted pretty soon after setting it up. I thought it might have been my dodgy soldering or something funny about the way I had everything set up. Turns out I simply hadn’t heard about Bad DMA. A local Atari enthusiast meetup later and a solution was proposed; swap the 68000 chip for a newer, lower power and subsequently less noisy version.

It worked!

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 never noticed it growing up but I see it now, TOS is profoundly flakey. My ST has a TOS 1.62 ROM built in and it does not play nice with hard drives.

There’s a simple solution to this, use the wonderful open source EmuTOS instead. Now I’m not resourceful enough to go writing EmuTOS to a flash ROM but my ST does have enough RAM that I can easily get away with loading it up from the hard drive.

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.