Being a software developer is much more than simply knowing everything about mastering programming languages.
You need to know how to deal with people, understand how software is best built from a high-level, best practices and trade-offs between them, etc.
We’ll look at a question I received from someone who is struggling with the fact that he just graduated from university - but has no idea how to apply everything he’s learned to solve real-world problems.
If you go to the official docs for ASP.NET Core you’ll find that Dependency Injection is under the “fundamentals” area.
Is that true - is it really fundamental?
This post is part of the 2018 C# Advent Calendar.
In the spirit of the season, we’ll be discussing how Santa Clause has recently been using .NET Core to build his internal Christmas present processing system.
With all the buzz around .NET Core I figured that I should tackle some of the fundamental issues that make .NET Core a gamechanger.
.NET Core really is the next generation of .NET development and I believe that it’s time for .NET developers everywhere to migrate!
One night, about 4 months ago, I had a couple hours of free-time. I was really enjoying the benefits of building apps with .NET Core. But I felt it was still missing all the “built-in” features that makes Laravel (PHP Framework) such a breeze to work with.
After all, I just want to build awesome apps and not tinker with the same old boilerplate stuff.
What if I just want to schedule my code to run once a week? I don’t want to configure Windows Task Scheduler. Or Cron. I just want to tell my code to schedule itself. Shouldn’t that be easy to do (like with Laravel)?
What’s the deal with async and await in C#? Why should a .NET developer in 2019 need to know what it is and how to use it?
What happens when you don’t close your .NET SqlConnections? Bad stuff. Bad stuff that will inevitably bring your IIS website crumbling down to ashes. Well… something like that. We all know that we should take extra care to always close our DB connections. Right?
But what happens when developers try to get fancy with their DB connections and focus more on being able to re-use open DB connections rather than being safe? Well, the consequences were bestowed upon me a few weeks ago.
Let me explain (briefly) what happened, what could happen to you, and a way to fix it - while maintaining the flexibility of re-using open DB connections and being able to safely use DB transactions from your C# code (using ADO).
During my day job, I had a case where I needed to use some pattern matching to do some type checking. If you don’t know, pattern matching in C# allows you to test the type of an object and perform some additional “magic” at the same time. While having the chance to play around with this feature some questions arose from my usage.
As a software developer it’s important to know what tools are available to you. Tedious and repetitive tasks or large “one-off” time-consuming tasks can often be automated by third-party tooling. And yes - sometimes it’s even worth purchasing some of these tools with your own money. Specifically, when refactoring, we should have some knowledge of what refactoring tools are available to us.
Continuing my “Refactoring Legacy Monoliths” series - I want to go over a few tools that I’ve found super helpful and worth investing in.
To make this blog post more useful than a list of products, I’ll go through some high-level steps that represent a way to tackle a refactoring project.
So your engineering team is convinced that you need to make some drastic changes. The direction of future development needs to improve. Things can’t stay as they are. Management is also convinced that the product needs to move in a new direction. What’s next?
Before doing any actual changes or refactoring to your product, planning a refactor is your next step. In other words, you need a game plan. I’ll also discuss some refactoring tips for you to get started!