This post explains how to create a GitHub workflow, which builds, tests and deploys a Unity project to Azure Static Web Apps (SWA) instance. Due to foundations on which SWA was built upon, it represents a perfect way to develop and test any game built on Unity WebGL platform.
The title might be a bit misleading. If you assumed this post would be yet another Unity tutorial, it is not quite the case. Teaching you complex framework, such as Unity, in just about three weeks, is something I could never promise. It is more of a story of how I rewrote my high school project, written in Turbo Pascal, without having any real experience with Unity. Because, why not. And I have been postponing learning a thing or two about Unity for quite some time.
Configuring service container and setting up request pipeline in ASP.NET Core can eat up a lot of lines of code, especially for more complex projects. A well-established way of doing this is using Startup.cs and its ConfigureServices() and Configure() methods. Although complete application setup can be packed into a single type, we must not forget about Single-responsibility principle. I wanted to show you a way to prevent startup from growing uncontrollably, by keeping different concerns separate from each other.
One disclaimer though. ASP.NET Core 6 has rolled in and removed the need of having Startup.cs altogether. Despite that fact, I am sure the ideas presented in this post will be relevant, even in the new era.
Let me present a pattern we used to solve a problem haunting our enterprise application for ages. It was initially designed to handle long running operations, using RESTful approach, but we soon realized it could be used in many other ways. As it generalizes the system of submitting requests and obtaining responses, it can easily be adapted to different business processes, while keeping unified client interface.
I always wanted to devote an article to Azure App Service, as it is my personal weapon of choice for hosting Web Apps. And what better topic to choose, than the one I always found official documentation severely lacking: describing feature difference between Windows and Linux platforms.
Ever wondered what happens under the hood of Azure Functions? How can your server code magically run without a server? How does it know when to scale and how much? How to adjust your application to run optimally as a function? I’ve got you covered.
New month, new exciting moments from my life as a developer. I hope you will enjoy reading about these flashes of clarity, that come suddenly after solving unfamiliar problems. Or as I like to call them - Ahaaas!
Microsoft Azure Architect Design is the second exam required for obtaining Azure Solutions Architect Expert certification. Backed up by deployment and configuration skills, obtained from preparation for Microsoft Azure Architect Technologies exam, we will tackle design of more complex and robust systems in this part.
In fast paced technology world, developers discover new insights practically on a daily level. Surely you have experienced these moments of almost divine wisdom, ending with “Now I know xyz can do that” or “I have to be aware of xyz” or “Eureka!”. I have recorded my moments of clarity, or Ahaaas as I call them, hoping that some of them will prove useful to you, whether you’d be dealing with .NET development, Azure or Docker.
This post is intended for anyone actively trying to, or considering, obtaining Azure Solutions Architect Expert certification. As I have obtained certificate near the end of 2019, I wanted to share relevant information and findings gathered prior to and after taking exams, in order to help future applicants.
Update your browser to view this website correctly. Update my browser now