Software engineering is full of patterns and principles to help you get the job done. Sometimes those patterns and principles are defined very abstract and difficult to understand. Let’s talk about SOLID design principles in a 5 part series. Today we’re discussing the Single Responsibility Principle.
Recently I was faced with some difficult decisions regarding employment. I had been experiencing some internal strife and as a result was “open to new opportunities.” While I hadn’t been actively pursuing options I figured that if something came along I’d at least consider it. Eventually some opportunities interesting enough to pique my interest did hit so I began the process. Nearing the end of my “openness” some external events occurred that set up an interesting situation. Ultimately I was faced with a decision that required me to understand myself and work at finding my motivations.
Breathing new life into a “legacy” ASP.NET website is a way you can help slowly transition the site towards ASP.NET Core. One way you might accomplish that is by referencing .NET Standard libraries. Everything seems fine and dandy until you attempt a publish operation. Generally you might not notice these until running msbuild from command-line–such as in a CI environment, batch deploy script, or otherwise. Let’s talk about one major msbuild error you’ll encounter while publishing your ASP.NET MVC application that references a .NET standard library. We’ll also talk about some other errors that might arise in the process.
When deploying an application to the web performance can be (and usually is) an important factor. Running it on your dev machine isn’t really a good indicator of how well your application will run, however. Finding out how well your application performs before you deploy is a good idea. One way we can accomplish that is by stress testing your web application using a tool called K6.
I’m a gamer. Video games are what initially interested me about computers. DOS prompts,
config.sys, and a batch loader to reconfigure the system depending on which game I wanted to play was where I first learned how to configure things. Growing older, however, I find that I don’t have the time for my hobby and I fall increasingly behind on my gaming backlog. Exploring the internet I’ve compiled a way that works for clearing my gaming backlog.
Recently I was going through the motions upgrading an ASP.NET Core 2.0 website to 2.2. Overall the process was fairly straightforward, minus some gotchas. We were attempting to switch the website from targeting the full framework (
net47) to target
netcoreapp2.2 but that caused a cascade of problems. One such problem was WCF. Today we’ll discuss using WCF with .NET Core and some of the gotchas you may run into.
User experience (UX) is a fine art and many developers fail at it. Years ago I watched a basic UX course on PluralSight by Billy Hollis. Since that time I have tried to focus on UX. One thing I’ve learned over the years is how awful modal confirmations are for delete operations. Today we’ll look at another way to approach delete actions by introducing a delayed cancelable action button in React.
Last month we talked about Cookie management in DotNetCore web applications and introduced a generic cookie service. Today we’re going to look at an alternative option for storing user data. Session state is a server store of information linked to a browsing session. Today let’s look at a technique for generic session management in dotnetcore web applications.
You’ve just finished up your fancy new React component and got it into the workflow. You now perform an action on the page. As a result your component renders but it is under the fold and isn’t visible. You want it to be visible immediately. What can you do? Today let’s talk about automatically scrolling React components into view upon render.
Last year I worked on a team migrating a large application to ASP.NET Core from ASP.NET MVC 5. Among our goals we wanted to make the site use responsive layout, become “future-proofed” on a technology stack, and clean-up a bunch of legacy cruft. Our initial launch did not go smoothly and we reverted to the previous site to make changes. In the process we learned some “gotchas”. Today I’m going to discuss one of those and how we addressed it. We’ll learn about throttling requests in .NET Core web applications.