In the previous article of this mini-series I talked about the problems inherent in MonoGame (and other Game Engines) that effectively prevent Dependency Injection (DI). During the development of Clean Space I made several attempts to resolve this particular issue, and in this article I want to describe the first (pretty crude) mechanism I put together.

Quite some time ago, following a short and shallow review of the game development industry, I started writing a game; Clean Space. Work on the game is ongoing and I have learned an incredible amount so far. Whilst I’ll happily talk the ears off of anyone in proximity that shows but a hint of interest, I’ve done very poorly at writing down some of the lessons I’ve learned throughout the course of Clean Space’s development. So, in this article, I want to talk about “The Game Loop”, how it fits into major Game Engines, and why I very quickly came to the conclusion that it is wrong.

There has been a lot of movement around kubernetes (k8s) of late. Several big name vendors have assumed k8s as the de facto standard, and all the big name cloud providers now have some level of integration. I work at an Azure house (though we have a good chunk in AWS also) so we had been looking forward to getting involved with the new Azure Container Service. However, the service (still in preview at time of writing) is far from ready. The myriad of bugs we encountered have lead us to deploying our own cluster in Azure to learn more about the procedure and technologies. We anticipate switching back to the managed service when we deem it to be ready, but for now I want to walk you along the journey we’ve taken in case you too would prefer the more hands on approach.

I tweeted a thank you to the guys over at Seq recently because Seq was instrumental in finding and eliminating a very difficult issue we came across. But technology choice alone isn’t enough, so I’ve decided to blog about some of the logging practices we tend to follow as a rule, and some specific practices that we used in a particularly complex application we’ve been developing over the last couple of months.

Whether you’re a game developer, or write software for large corporate enterprises, there is one frustration we all share. The end user always finds a way break our software, or find a way to make it behave strangely. It’s never the user’s fault, our failings in UI/UX design, our missing restraints and misunderstanding of user intent all point to the developer being at fault. Of course, this only makes the situation all the more frustrating.

In this article I’m going to delve into some of the science behind the exploration aspects of Clean Space, and perhaps tackle a couple misconceptions that you and I may share, such as the title of this article. Nothing I’m presenting here is ground-breaking, but I hope you find some of the facts interesting as we recap ourselves on those awful trigonometry lessons or physics classes of your past! Don’t be put off, I literally had no formal education beyond Secondary School in the UK (10th grade - or sophomore I believe it’s called - in the US), so there should be nothing here most layman can’t grasp. I’ll apologise now, because that same education (or lack thereof) will no doubt account for some level of ignorance and subsequent mistakes in this article; if the actual smart people fancy lending me some pointers in the comments section, I’d be very grateful!

I was recently contacted by Ivaylo Kenov asking if I could take the time to review his new fluent testing framework for ASP.NET Core MVC. I hadn’t come across any of Ivaylo’s work before, but tend to enjoy evaluating new technologies and frameworks so decided to share my review.

As it stands in the RC1-Update1 release of ASPNET 5 and DNX, (soon™ to become AspNetCore and the dotnet CLI respectively), you are not limited to only creating Web Applications; you can also create Class Libraries and Console Applications. Having been on the proverbial bandwagon for quite some time now, I have assisted in getting several ASPNET5 web applications into production, and dozens of class libraries. I recently came across the requirement to introduce a command line interface (CLI) to run some background jobs for one of our sites. In this post I’ll explain what I did to not only produce a professional looking CLI, but also to utilise our existing class libraries through dependency injection.

For several weeks now we’ve been using Swashbuckle in our ASP.Net 5 Web API to assist document and even test our API endpoints. This is a brand new API, and we’ve been doing everything we can to follow best practices with regards to Web API’s. Our discussions and decisions regarding best practices are always focused upon the practices themselves, and not necessarily upon the technical implications of an outcome. Thanks to the superb extensibility of ASP.NET 5, this hasn’t been an issue. That is, until today, when we came across an issue that many others also seem to have had problems with.

In my previous post I talked about the reasons for writing a game, but without going into the detail of what the game is actually about. In this article I hope to clarify some of the high level detail, concepts, and goals of (code name) Clean Space, to give an idea of the scale involved and an idea of what this series has to look forward to.

All my life I’ve dreamt of writing a game. Not just any game; one game in particular. The subject of countless hours of daydreaming, theorycrafting, brainstorming, and outright planning. For a long time I put off this endeavour, all too aware that one should never undertake a project of the magnitude I intend for my game, as their first game. I’ve glimpsed at the possibility of game development from afar whilst growing my skill and experience as a Senior Software Developer. At long last, it’s time to act.

Even those that work outside the realms of IT are unlikely to argue against the fact that our field is fast moving, so I assume I’d be hard pressed to find a software developer that wouldn’t attest to our changing times and the difficulties of keeping up with the latest technologies. Far too many technologies, in my opinion, for it to be plausible to keep up with them all. As a Professional Software Developer, I believe it expected of me to know as much as possible about the technologies in use in my day to day work, that I know of and have perhaps tried out technologies in the plausible pipeline of the company’s upcoming work, and of course I’m keeping ontop of any core technologies and frameworks that are perhaps not in use, but are prevalent in the industry.

Increasingly I stumble upon articles that are pushing businesses to increase their investment in open source. I recently fought this battle myself, working against the legacy thought process that all source code of a business should be proprietary as key contributor of unique selling points. I want to ellaborate on my experiences for those of you also working towards such a goal, and provide some advice on how you can go about implementing the process itself.

Unlike my typical rants and rages, I’ve decided to put together a series of articles on some of the more basic coding standards and conventions I follow, as well as the reason(s) I do so. A lot of the battle of conventions is to offer some form of standardisation, making code easier to read and understand by other developers (and your future-self!).

As a Senior .Net Developer, I’ve never found it particularly difficult to find a really good role. Admittedly, the signal-to-noise ratio is astonishingly poor, but the market seems saturated with companies looking for good developers. This was not always the case; as a junior and inexperienced developer it was quite the opposite, having to settle for the best opportunity of the bunch. Clear indication of just how many bad, inexperienced, and junior developers are out there. Having recently revisted the recruitment market, I thought it might be of interest - recruiters, clients, and candidates alike - to share my perspective, and perhaps make some suggestions.

I was reading a blog post by Aidan Fitzpatrick recently, and as is often the case whilst scouring the web for endorsable blog authors, felt some sympathy for the misinterpretations or unfortunate circumstances I assume Aidan to have been through. I don’t believe the experience of trying to improve oneself and their code but failing and thus falling back to old ways, is a particulrly uncommon phenomenon. So it seems appropriate to address some of the points Aidan has raised, in an attempt to help and perhaps even reinspire those suffering silently in simular situations, fallen to the wayside in their endeavour for excellence.

I find it easy to fall into the trap of wondering, how is it so many people can misunderstand testing. Sure, it’s a broad subject and there are far too many (wrong) opinions on the subject. But then, it’s easy to forget how I was also so very wrong not that many years ago. I too, thought of tests as an optional extra, afforded only to the lucky few, not those of us slogging it out in the pits of legacy code, or those of us rushing releases for a new startup.

I see a lot of people get application composition very wrong, very often. The problem isn’t so much that the subject lacks resources, on contrary, dependency injection for example is probably the most talked about and blogged pattern of all time! However, the information presented is all too often incorrect or conflicting, spawned from the enlightened minds of mid level developers keen to share their light bulb moment in which DI and some of its benefits are suddenly realised.

I’ve spent a little over a month checking out game developers on twitch and similar, getting a feel for what goes into making a game. I wanted to know what differences there are between game developers and the rest of us mere mortals. More importantly, I wanted to know why differences exist.

I remember, as a younger man, asking my on-prem guru of the day, “when will I be a senior developer?”. I had no idea what answer I expected in response. Perhaps it would be on “time served”? After 2 years? Maybe 5 years? 10? Perhaps when I had more hair sprouting from my nose and ears than on my head?