001 - A conversation with Scott Allen

Jeremy speaks with Microsoft MVP Scott Allen about C# 8.0, .NET Core, Blazor and much more.

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Feel free to send any questions or comments to podcast@pluralsight.com.

Jeremy

Hello and welcome to All Hands on Tech, Pluralsight's Podcast about developing technology skills and embracing innovation. I'm Jeremy Morgan and today I'll be talking with Scott Allen, one of our top C# and .NET authors, an MVP and a Microsoft Regional Director and also a huge fan of Blazor. We're going to talk about C# 8, .NET Core, Blazor, and the coolest new Azure feature you may not have heard of. So let's welcome, Scott Allen. How did you get started in .NET programming?

 

Scott

Really, I was working for an organization, what we would call a Microsoft Shop. So I went out and found a job during the dot-com boom days with a company that was an internet startup in more of the B2B space. But when I arrived there, they were doing C++ with SQL Server and classic Active Server Pages running on IAS. So I learned how to ... I had been doing C and C++ for a while. This was my first foray into Microsoft Technologies and this is around 1998. So that's when I started to learn about COM and DCOM and Active Server Pages and these SQL Server for the first time. In fact, when I started, it might not have even been called SQL Server right at the beginning, I think that was right around the time I started to work with Microsoft Technologies that it was renamed.

 

Jeremy

Nice. What did you think when you were going into C# like coming from that, there was probably from C and C++ a little bit of a shift. I came from the Linux world and jumped into C#, but it had already matured. This is around 2008 or 2009, so it's super mature, but it sounds like during this time it may not have been as mature. What did you think about C# as you had started to dig into it?

 

Scott

It was definitely not mature, and I'll tell you one funny story about C# before I started using it. And that is, I clearly remember the day where I was walking by a colleague's desk at this office, and I saw a copy of MSDN Magazine laying on his desk, and it said something about this new C# language. And I remember looking at Tom and saying, "We don't need a new language, we have C++," and I thought that another C like looking language would just never get off the ground. But because it was new, because it was coming down the pike, I decided to take a look at it. And my initial impressions were I was a little bit impressed. I thought it was very refreshing how clean the language was compared to some of the things that we were doing a lot in C++, and I was very impressed at how fast it was to compile.

Those were the days when you tried to compile a simple C++ program and by the time the pre-compiler and the compiler and everything had chewed through all of your header files and open megabytes of stuff and produced files all over your desk, you were waiting minutes for even the simplest program to compile. And then along comes the C# language, which didn't really include header files, it was kind of magic. You could just reference these other abstractions in classes that were in different namespaces and press compile and five or 10 seconds later it's ready to go. So that was to me very impressive. So I immediately started to look at this as a language that could be very productive.

 

Jeremy

Yeah, absolutely. I think that iteration time with compiling can make a big difference because you take a few more risks knowing that it's only going to be a few seconds before you'll find out the answer if so.

 

Scott

Yeah, absolutely. I find myself these days with web technologies having a very short ... I'm not willing to give up these short iterations. So if I run across a technology where I need to write some code and then save files and then build and then wait and wait and wait for something to get into the browser window, I get really frustrated and I'm not really happy with technology. I really like environments where things are set up where I can just save a file, look at the browser, when there's my update on the screen and it only takes seconds.

 

Jeremy

Yeah, absolutely. So what has kept you in the C# and .NET ecosystem this long, do you think?

 

Scott

I think it's evolved very well. I think it's always been an environment that Microsoft has nurtured to try to be as productive as possible for developers. Even though it's gotten big and enterprisey, it's never gone too far off the rails in slowing you down with a lot of extra infrastructure that you don't need. They've always been adding features to the language that have been very interesting, and have even changed the paradigm of how you program in some sense. So if you look at how we wrote code in C# version 1, it was very different in version 2 when we had generics, and it's became very different when we introduced a lot of the infrastructure to support link with an easy way to create delegates and write lambda expressions and really do functional programming in C#. Then of course they added a sink in a way to ... I think the language keeps getting better. The framework keeps getting better.

There was a period of time around, I guess it was 2008, 2010, when I really wondered if .NET was going to have a future, it just seemed like Microsoft and this new windows release at the time was ... And they're pushing .NET aside and almost trying to get rid of it, but I think it's come back pretty strong. And really with .NET Core, I think there's really been a resurgence of excitement around .NET both inside of Microsoft and inside of the community and the ecosystem that's around .NET. It's a really exciting time to be working with .NET again because of all the improvement and the framework and the performance improvements and the language continues to evolve, it stays interesting.

 

Jeremy

Yeah, definitely. So the .NET Core 3 release just happened and that was pretty big. What are some of the cool things that you saw in this release that you're excited about?

 

Scott

Yeah, there's a lot happening in .NET Core 3. One of the things I always call attention to is the feature they added to the C# language for, I like to call it, non-nullable reference type. Sometimes Microsoft will refer to it as nullable reference types, which I always found confusing because we've always been able to assign null to reference types in C#. But this new feature in C# version 8 is a feature you can opt into that at the end of the day it's going to try to help you avoid null reference exceptions. So when you flip on the compiler switch, it's going to find areas of your program where you have reference types that you haven't initialized, that might be null. It's going to tell you when they're not initialized. It's going to tell you when you might be using something that could be null, because we're not going to get rid of null values anytime soon, I don't think. I would like to, but because I think they just tend to complicate programs.

The way I look at it is if I write a method and someone invokes that method and inside of that method I face a situation where I'm not sure what to do, so the default is I'm just going to return a null reference to you. Then in some ways that method has created more work than it's set out to solve, because now when someone invokes that method and calls that method, they have to check, "Did I get a real value back or did I get a null reference back." So I'm pushing work out to anyone who calls me. And so instead of helping them out, I've created a little additional work for them. But that being said, there's situations where no values make sense, so we're always going to be checking for them.

But these new features in the C#, if you have a reference type, like a string type or any custom class you've built like employee or account or invoice. If you're declaring a variable or a field of that type and you want to let the C# compiler know that null might be assigned as a possible value for this particular field or variable, then you can have a question mark after the type name. So I could say something like, "String? First name," and then tells the C# compiler that first name, can be assigned the value null, it might be null. But then throughout the rest of the program, anytime I interact with a first name, like if I do somewhere inside of a method, firstname.lane, the C# sharp compiler will tell me, "This field might be null and you haven't checked the see if it is null before you just dereferenced it." So you make it a null reference exception.

And none of this happens at runtime. So runtime, yes, you still can get an over of its exception, but at compile time the C# compiler is doing a lot of flow analysis to analyze your code and what if statements do you have and what other methods is it calling to make sure that you're trying to check if things are null or not, when they could be null. So, in other words, if I say if first name equals null, returns zero, else return first name.length, the C# sharp compiler will be happy. It knows I'm avoiding the null reference exception. But otherwise it'll give me a warning that I might be possibly dereferencing a field that can contain a null value.

So the point of all this, the reason I like this feature is because I hope developers embrace this feature and teams embrace this feature and it gives them more opportunities to think about, "Do I really want to use a null value here." Because again, I think null values, in general, are a little bit dangerous. They obviously can call us exceptions, but they tend to add complexity to your software because you have to start adding checks. If this is null, do this, else do that. So there's a lot of cyclomatic complexity just in our software because we're doing null value checks.

The alternative, there are situations where perhaps you can avoid null if you just think of perhaps a sensible default value. In some cases, an empty string might be a sensible default value for a string type. So you might be able to use an empty string instead of a null value so someone can still call .length on your string and get some result back without an exception being thrown.

And then more complicated examples would be to look at something like the null object design pattern and say, "Can I come up with a real object instance, a real instance of this object for whatever type I'm building," whether it be employee or invoice or permissions, collections. Could I come up with an object that isn't ... So I don't have to assign a null value, but anytime someone interacts with this value, this object that's going to provide default values or provide some reasonable safe default so that nothing odd happens in the software, but we can avoid null checks and we can avoid null reference exceptions." So that's the case where I want to push developers to try to think about how to get rid of nulls.

 

Jeremy

So do you think this feature might enforce better programming habits if used properly?

 

Scott

Right, that's exactly what I'm thinking. I had just gone through a period recently where I went through so much code where everything was checking for null here and checking for null there, and I thought, "There's just got to be a better way to do this in some cases." And in many cases, it was easy to look at the code and say, "If you just use the sensible default value, we could avoid 10 or 12 null checks throughout the rest of the call chain here." And this feature, the C# compiler, the non-nullable reference types, I think would encourage people to think that way.

 

Jeremy

Yeah, I've definitely overused the empty string pattern quite a bit for the exact reasons that you've talked about there. You've talked in the past about FMO skills and timeless skills. Can you tell us a little bit about that? The difference between the two and-

 

Scott

Yeah, a lot of developers I think focus on skills that don't have a lot of staying power, and I think, unfortunately, that's just because our industry becomes very obsessed with these types of skills. It's how we recruit, it's how we express our capabilities to other organizations and individuals. When someone asks us, for example, for a resume, what do we say? We say, "Oh, I've been doing C# development for X amount of time and I know Angular 1 and I know Angular 2 and I've worked with Microsoft SQL Server databases for this length of time."

And I think all those skills are good and obviously you have to know something about SQL Server and C# if you're going to work in a Microsoft shop where software is written using C# and the SQL database. But at the same time, developers then, because there's so much emphasis on building your resume and acquiring these types of skills, I think unfortunately some of the more timeless skills are undervalued in our industry. I think some of that's been changing recently, but some of the undervalued skills are very simple and obvious, these days like communication. So the ability to work with other individuals on a team.

Timeless skills to me also would include something like empathy. So having empathy for other team members. For example if I'm a developer, having empathy for the Ops team that has to put my software into production. Are there features that my software is missing or that I could add to my software that makes it easier for the Ops team to operate the software and debug it and figure out what's wrong and deploy it. Also, skills like leadership and just good software design principles, UI design principles are kind of timeless.

All of those skills are skills I think people should look for when they're learning a new technology or a new language. Because even though that language or technology is important in the short term to learn, if you're building a career over five or 10 or 15 or 20 or 25 or 30 years, it's those timeless skills that will pay off in the long run and transfer across these technologies that are going to be short lived and even across career paths. So if you spend 15 years as a developer and after 15 years decide you want to go into banking or real estate or just do something different with your life, skills like communication, the ability to write, the ability to empathize with other individuals, those things will carry over into any profession.

 

Jeremy

That's one of the things when I was in college we took writing class after writing class and I thought to myself, "I'm going to be an engineer, I'm not going to need this stuff." And then of course, in hindsight years later, I'm like writing is probably the most important skill that I have and can work on and build. So it's one of those hindsight things and the people skills, I agree like soft skills. One of the things that I learned the hard way in management, being a lead software developer and a manager, was trying to find the candidates with the most skills and the most bullet points like you talked about, "Who's got all the bullet points? Let's bring that person in."

And over time, I learned that it was a little bit better to find the people who have the soft skills, the communication skills, empathy, are they nice, can we work with them. Those things make all the difference to where I had reached a point in my career where I would pick somebody with a lower set of skills, as far as the technical side, and then a higher set of skills as far as the soft skills guide, because I figure I can teach them technical skills and ramp that up a lot quicker than I can teach them not to offend everybody on the team when they speak. So that's definitely a changing way of looking at things I think for beginning developers.

 

Scott

Right. I really wish there was a way in this industry to be able to evaluate people without looking some of these very specific technical skills that we talk about. Every time I see a job ad put out that says, "Require, five years of C# experience," I just cringe and I say, "I wish there was a better way to express that somehow." I don't necessarily only want candidates that have worked in C#, I prefer someone really bright that has been doing Python for five years. That actually might be the right candidate because they can pick up C# in a couple months and be just as productive as someone else I might hire.

 

Jeremy

What are some things that you wished you knew when you started out that you would have focused on knowing what you know now?

 

Scott

Definitely I wish I would have known just how important communication was right from the start. So like you said, the ability to write and express your thoughts and organize thoughts, that's just so valuable in this day and age. The ability to communicate with other people in a written format or speaking to them and presenting to them. I wish I knew that. And also just wish I had realized at the start that this is a marathon and not necessarily a sprint where you're trying to get as much done in a short amount of time as possible. Really you just want to keep moving forward and making small improvements in your career and in your life and you're going to be at this for years and years and years. And as long as you keep improving steadily over those years, you'll be somewhere, you'll definitely be somewhere.

 

Jeremy

How did you get started with developing courses?

 

Scott

I was always interested in teachers. Like I was one of those students that would sit in a class and listen to my teachers. And at least for some of my teachers, and in the topics I was really interested in, I would wonder about the teacher's approach to a given topic. Like, "Why did they choose to approach it this way? Why did the book structure this information in this way?" So right from the very beginning, I was always interested in the craft of teaching, you could say. And that continued even after I got out of school and out of college and into my first job. One of the first things I wanted to do, even when I was one year out of college is, participate in some lunch and learn or some brown bag where I could either be taught and learn, keep learning new topics from other people, or I was really excited also to present and to teach other people some things.

So it was really interesting. One of my first jobs out of college was with a defense contractor here in the United States. And this defense contractor had a bunch of developers on a project using a product. There's this product that used to be called Clipper, which I guess, you could almost say it was like a combination of a programming language and a database. But it was definitely not ... It was an xBase type of language. So this team I was on was considering moving from Clipper, this programming language called Clipper in this environment into C++, because one of the things they wanted to do is move from a DOS based command line environment into a GUI environment, maybe running under Windows. And the idea was, "If you move to C++, then you could rate a Windows program or Windows GUI," what have you that was one approach.

Anyway, this whole team was trying to learn C++ and I just got out of college where I'd done a bunch of C++ and really was quite ecstatic about the language, I thought it was the best language ever. So I started series of little brown bag lunches where I would talk about the C++ language and how we could take this bit of code from Clipper that I wrote the previous week or something and this is how I would do the same thing in C++. And this is how I might try to put it in a GUI. Although honestly, at the time I found GUI programming and programming Windows to be quite overwhelming. I took a years for me to get comfortable with. But fast forward, a long time and I've always been interested in teaching others have also always been interested in writing.

So also early in my career, I did a lot of writing and I tried to write for back then magazines and actually printed periodicals and contribute to books and so forth. And eventually that led to me being approached by Fortanium of Pluralsight who asked if I might want to come to work for Pluralsight as a contractor and do the occasional instructor led training. Or Pluralsight would fly me off to some company or perhaps some Microsoft office and have a training class for a company or an open training class for whoever signs up and wants to learn about a topic. So this is back before Pluralsight did videos and this is back in the days when Pluralsight did training on the C# language and ASP.NET and XML and WCF and it's exciting time.

This is probably 2006, I want to say. And it was shortly thereafter where Pluralsight and Aaron Skonnard, Pluralsight CEO said, "We want to get into this business of making video courses. So we want you to make a video course." And my first video course that I believe was 2008 and I've done, I think, over 50 courses now for Pluralsight.

 

Jeremy

Was there a big learning curve for you for the learning like video and audio editing?

 

Scott

For me the big adjustment was recording myself. I found that really hard to do. I guess there's a couple of things come to mind. The video and audio editing are actually quite enjoyed right from the beginning. I'd always been a bit of an audio nerd. So I had done a lot of recording over the years. I used to do things with four track recorders years before trying to record music and make little music albums for my family to listen to. I found the ability to work digitally with audio is quite exciting and I understood a lot of the terms and a lot of the vocabulary around this editing process. It made sense to me.

But for me, the real challenge was just recording myself. So it became very difficult for me to sit down and hit the record button and talk in away that was natural and interesting. It's amazing how difficult it was. I don't even know why, but it was like I had a mental block. It took me so long to make that first course for Pluralsight. It was so difficult to get started and do that.

 

Jeremy

One of the cool things that people have been talking about in the Microsoft world lately is Blazor. And that's something, of course, that runs like .NET Code in the browser, somewhat like Silverlight without the browser plugin and things like that and near native performance. Have you played around with that at all?

 

Scott

Yeah, I've definitely been looking at Blazor and I've already written a couple of things about Blazor that were slightly critical and I think some people took it the wrong way. I think some people were thinking that I was complaining about Blazor, that I'm a Blazor hater, but I want to make it clear. I want Blazor to be successful. I would love Blazor to become the default standard for writing anything in a client UI moving forward. And because of that, I went to write things that will help to improve Blazor, so it could ... Anything I say about Blazor that's critical, it's not because I don't want to use it or think it's not going to work. It's because I really do want it to work. I want it to work really bad.

I became so frustrated with clients I'd development a couple of years ago that I just walked away from it and I really haven't touched anything in the Angular, Vue, or React space over the last couple of years. I've been forced to here and there, but I haven't actively done any work or written any courses or done any research in any of those areas because I was just so fed up with it. And I really hope that Blazor can step in and take away a lot of the pain I was experiencing with this different technologies. So yes, Blazor to me is very exciting. There's really two execution models for Blazor, but the whole idea is, I want to create an interactive UI in my customer's web browser and respond really quickly to click events without posting back to the server and re-trawling the whole page.

So one way to do that is to use a lot of JavaScript and write Angular or write something with jQuery or something with React. But another way to do that is to use Blazor and write C# Code. So the user clicks on a button in the browser and I want that to execute C# Code. Right now there's one supported way to do that, and in the future that's going to be another supported way. Right now, with the release of .NET Core 3.0, the one supported way to do that is to write your C# Code in a Razor component and set things up so that when the user clicks on that button, there's actually a signal, or WebSocket communication channel that has been established between your component and your App in the browser and the web server.

And that component is going to send a message back to the web server to say, "Hey, user just clicked on this button," and it's up to the web server to actually execute the C# Code server sign, figure out what happens, what changes, what has to change in the DOM. Re-render that component HTML server side and then send disc back down to the client or the DOM can be updated. That's the server side execution model of Blazor. Which to many people sound strange and it is, in a way, at first glance I'll admit it. It is strange because it's not the way any other clients side library or client side framework works.

But in the future, sometime next year, Microsoft has promised that we can write C# Code to respond to that click event ... And by event I mean any client site event. So there could be a click event or a mouseover event or a DragEvent, anything. In the future, Microsoft wants us to be able to write C# Code and that C# Code is going to be compiled into Wasm, which is WebAssembly, which is now supported by all the browsers that are important and basically it's a byte code for the browser.

So C# Code it's compiled into Wasm instead of an assembly. And that Wasm goes down to the browser and the C# Code then effectively executes in the browser. And I can take other .NET assemblies then and also ship them down to the browser and basically have a .NET CLR running inside of the browser. So yes, that's a lot more like the Silverlight model. And now, when the user clicks the button, I'm executing code in the browser and updating the DOM and I'm not going back to the server over WebSocket or anything crazy like that. So it's very much just like writing an Angular application or View application just instead of using JavaScript and TypeScript, we're writing all of our code inside of C#.

Well, there's so many opportunities here. For one, the JavaScript TypeScript ecosystem to me is amazing and frustrating at the same time. It's so amazing because there is a lot of amazing things that happen inside of that ecosystem, but it's also very frustrating to me because there's a lot of yakchieving if you're familiar with that term, which is the yak is always roaring. It's our code and everyday you have to shave the yak and just do things that are not helping you get your daily chores done or helping you provide any business value. But you just always have to do these things like Webpack configuration files and Webpack wants to update every time you do an npm update. It was updating for me every week and causing these breaking changes, which to me, I would look at some of these breaking changes and I don't mind breaking changes if they're done for a good reason and they move things forward. But to me, a lot of the breaking changes were just nonsense. It's like, "We renamed this property to this other property name, because it sounds better," those things drive me nuts.

 

Jeremy

I think sometimes that's how Microsoft develops their products is sometimes they'll put something out that's innovative and it's completely different from other things, but sometimes I feel like their products are a response to a frustration. So they'll see what other people are doing in the industry where they're getting frustrated and then Microsoft will come out with their answer. And I feel like Blazor might be an answer to some of those frustrations. Would you agree with that?

 

Scott

Yeah, I would definitely agree with that. And I would agree Microsoft often wants to improve what's happening in software development industry and sometimes they do a good job with that. I think MVC, was an example of that? Although I do think MVC was very much something that was copied from the Ruby world. All these Ruby developers are doing Ruby on Rails. How can we make a Ruby on Rails type experience using C# and .NET? And it turned out okay. Again, just like you were saying, it's a good environment, very productive and I think for Microsoft developers, it was a very welcome change from web forums. So I think it was a good move.

But I think Microsoft does even better when they try to advance things. So they don't look at something and say, "Let's try to make a copy of those." They look at a situation like client side development and basically think, "How could we do something completely different?"

 

Jeremy

I think TypeScript was a good example of that. Like how can we make something completely out there that's different and while that took a while, it seemed like it took a while for the industry to catch on to how great TypeScript was. When it first came out, I remember looking at it and building stuff and being like, "This is amazing, everyone's going to love it." And then it seemed like it took a few years before everybody loved it.

 

Scott

Yeah, definitely. Well, I think to be fair, Microsoft had to iterate a bit on TypeScript and I think they had to fit TypeScript to work even better in the JavaScript ecosystem because I remember looking at it also early on and I thought, "This was very exciting and it certainly eliminates a whole class of problems from JavaScript programming." But you always caught into these strange edge situations where it just didn't quite work the way you wanted or that didn't have the benefits that you wanted or there was always something missing or hard to configure. But then when they embraced the JavaScript ecosystem.

So a simple example is, "Look, we're going to use the Node.jS module resolution algorithm to resolve where we look for things for TypeScript." As soon as they did that then put that step in a lot of different pieces started falling in place because all of a sudden I could substitute TypeScript for JavaScript more easily in my projects and not based a lot of friction. And the benefits are enormous. I still talk to people who believed that that Static types, if they're not evil, they're unnecessary. And I wish I could share them or generate some report or show them just how many problems my students have run into in an introduction to Angular course. How many problems I've seen our developers have over the years. And I'm talking hundreds and hundreds of cases where people have gotten so frustrated or they've almost quit in the class because of a simple typo. Having an uppercase C instead of a lowercase c or just missing something in the spelling of a word and how preventable that situation could be.

 

Jeremy

Recently I wrote about Razor Pages for HTML and controllers for API's. So can you talk about that a little bit?

 

Scott

Yeah, with the release of ASP.NET Core 3, speaking of MVC, I really see the MVC framework being de-emphasized. So traditionally, what have we used the MVC framework for? Well, back when there was MVC 5 on the .NET Framework, we use the MVC framework for just about everything. We used it to build APIs by rating controllers, and we used it to build applications that generated HTML on the server side and that was MVC, right? You would use a model and a view and a controller to generate HTML. And then ASP.NET Core came out and it was really just, at first, a continuation of what MVC was on the .NET Framework with a lot of extra benefits and some re-architecturing that was done to ... But we basically had the MVC framework now with middleware and dependency injection and all these nice .NET Core things.

But now .NET Core is maturing and .NET Core has added a feature known as Razor Pages into the mix. Where Razor Pages are really optimized for producing HTML. So I'll talk about that in just a second. But what I'm seeing is that the MVC approach to building applications is really fading into the background. Like in the future, we're not going to be talking about the MVC framework any longer. We're going to be talking about ASP.NET Core and we're going to say that we use either controllers to build APIs just like we did in the past because really all you need is an end point to build an API, right? You don't need a view ... Yes, you need models, but we'll be using controllers to build HTTP based APIs that return Jason or return XML and can be restful.

And then there's this other technology that was new called Razor Pages and that's what we're going to use to generate server-side HTML. Because Razor Pages to me are optimized for that scenario where you went to generate HTML. The syntax is a little bit better, they still function and have a separation of concerns just like the Model-View-Controller design pattern always wanted and just like the MVC framework gave us. But the thing about the MVC design pattern is that it never said your model and your view and your controller had to be physically separate files that were spread all across the file system.

And that's one of the things I always found irritating about the MVC framework in ASP.NET. Is that when I wanted to go work on a feature, like a specific feature in my application, the login page, for example, that to me would be a feature. I would have to go find the controller that contain the login functionality and it might be a controller that has 15 other things inside of it, because we were never sometimes very good at organizing our controllers and keeping them thing, so I had to find the controller that has the login functionality but it probably also has the log out functionality and the reset password and the forgot password and the update my email. It's got all this stuff inside of it.

And then I have to go to a different folder and find the view that presents the login form to the user. And then I have to get into another folder to find the view model for logging in. And then in another project, somewhere there's going to be the unit tasks or the integration tasks for the log in feature. So by the time I've gone to these four or five different locations and open up everything I need to work on the login feature, I'm really quite tired and just want to call it a day.

With Razor Pages, that set up can be a little bit different because the Razor Page, for starters, you can think of it as the controller and the view two different files that are physically located in the same folder, which is perfect. There's still a separation of concern, to the view is still distinct from the controller or the page that sits behind it. But now, when I went to work on that login feature, first of all, I'm going to find a Razor Page that's dedicated to login. No one's going to write and work with Razor Pages in a way that you mix the login feature together with the logout feature together with the reset password feature. Because Razor Pages, they're really just designed to respond to either a get request or post request. So you typically only do one thing with them. And although you can add other methods into it, I suggest for the most part people just stick with it in post.

So it's almost like back to the days of Active Server Pages in a way, which I don't want to say because I don't want people to think Razor Pages are anything like Active Server Pages, but in a way, Active Server Pages were really very simple. Like, "Where's the login page?" "Well, just go out and look on the file system for something called login.ASP that's going to be the login feature."

Razor Pages are the same way. How do I find the login thing? Well, there's going to be a login.CSHTML Razor Page that has the markup for my login page and that's all it's going to contain. Just the login feature, not the log out feature and the reset password. And then the .CSS file that's associated with it will be just the logic to implement what happens when the user issues and HTTP get requests for this page. And if they can also post a form, let's say, it will implement the post logic too. So all of that will be in the Razor Page.

And so generally, what I have found with Razor Pages is that developers tend to build smaller abstractions with the Razor Pages because you implement one page of your application or one feature or your application, and that's all that's in this one little abstraction. Unlike controllers and views where things just became a mass and you can put multiple things inside of a controller and have it return all different views. Now, we're back to the simpler page oriented way of navigating and thinking about our software, which to me is much simpler. And developers also tend to develop a better hierarchy of how they place pages onto the file system. So again, instead of having this thing where controllers are just chock full of 12 or 15 different methods that respond to all different URLs, pages are typically much more hierarchical and map to the system UI in a more sane fashion. And I liked that.

And there's also really basic things too like Razor Pages they're, again, optimized and designed for rendering HTML application. So one of the things they provide by default out of the box without you or me having to do anything is they provide validation tokens to prevent cross-site request forgeries. Whereas with MVC framework, MVC framework doesn't know if you're using a controller to build any PI or you're using our controller to respond to a foreign post. To them, their cross site request forgery stuff is optional and you have to explicitly go in and add attributes or some filter to make sure that you checked for things like that where Razor Pages is just built in.

 

Jeremy

And I imagine it's probably a little easier for designers and more front-end developers as well. I remember working with MVC years ago and I would be working with designers who would be developing all the HTML and CSS and then we would literally have to pair in order to integrate that. And it's not the fun pair programming, it's more like, "okay, I've got this, can you please put it into your visual studio and build it?" And it seemed like it was a clunky process because I would have a designer on a Mac, drawing up these beautiful pages and then we would spend an afternoon integrating those into their ... And it sounds like this might be decoupling that a little bit and possibly making that easier?

 

Scott

Yeah, I think it's again, conceptually easier to understand. And I think it's much easier for a designer to go in and find ... I'll use the login feature as an example, again. It's much easier for them to find the login page and clearly see where the markup is that they need to modify or create. It's going to be easier for them to work with, yes.

 

Jeremy

Azure's Red Hat is something that you're really into. What's the coolest new feature that they've come out with like in the last year or so?

 

Scott

Well, this might not be attractive to everybody, but there was a feature released recently that I found very interesting, it's called Ultra Diff. And I find it interesting because one of the things I've seen a lot of pupils struggle with moving to the cloud is simply the IO is not going to be anything close compared to what you have to being in your own data center or on-prem. So it doesn't matter if you're doing SQL Server or running a virtual machine and saving files to a hard drive. It doesn't matter what you're doing, you're not going to get the same IO throughput that you get locally simply because of the way cloud storage is designed.

So in Azure, if you're working with a virtual machine or even like in an app service if you write a web application and deploy it to an app service and your web application are saving stuff to a file system, that file system is backed by Azure storage, which means all of the file system interactivity really is going through an HTTP layer that goes through a load balancer, and through a proxy server and goes all over through the network and eventually gets to some physical storage inside of Azure somewhere. But that just means there's a lot of overhead compared to the local situation where you have hard draws mannered in a raid configuration instead of a machine and your applications stays from data and it's not going out over the network or anything, it's just rating to a desk right there in the machine, very fast.

It's not going to be as highly available as Azure. It's not going to be replicated as easy as it is in Azure, where you can replicate storage all around the globe, but Azure is going to be a heck of a lot faster. Myself and others who have moved some stuff into the cloud that is very sensitive to IO operation and IO performance, we've seen that moving to the cloud can sometimes kill an application if it's doing a lot of IO and it needs to read and write quickly to the hard drive. This ultra disc feature that they just released recently, I think it was maybe like a month or two ago where it went generally available, basically is trying to allow Azure servers, like your virtual machine, to once again go directly from the kernel to almost directly to some physical storage.

So that it still might cross a network, but it's going to avoid some of the things that go through the regular Azure storage layer like the load balancers and proxy servers and all the other pieces of the network that get in the way. So it's really trying to speed up IO by an order of magnitude, make it that much faster. So the pros are that a few ... If you have an application running on prem and you haven't been able to move it to the cloud because it just runs too slow, ultra disc might be the solution. The downsides are that ultra disc is going to be very expensive. So you'd be amazed how much you have to pay for really fast, good IO in the cloud. And it's also not going to come with some of the features that you might expect from Azure storage.

So features like, I don't believe transparent data encryption is supported, at least not yet, and you don't necessarily get things like geo-redundant storage right out of the box with Ultradesk. It really is just a way of providing really fast IO without a lot of the infrastructure that can easily provide these other features. So you have to make some trade offs and sacrifice some things.

So that might seem like a weird one, but to me it's just an indication that Microsoft is doing whatever it can to try to eliminate hurdles that people have to coming into the cloud. So there's a lot of reasons people have not gone to the cloud over the years. It used to be that people didn't trust the cloud and Microsoft went out and got all these certifications around high tech trust and ISO certifications. And you can look at the list of certifications now it's a mile long and they can demonstratively prove that, "Hey, we're a secure environment." So that argument fades away. But you can still definitely make an argument about performance that you can get better performance using local hardware than you can inside of a cloud like Azure, but I think eventually that's going to be the way too.

 

Jeremy

One of the recent projects I worked on with cloud transition that was one of the exact problems we had is moved into the cloud and they're like, 'What's with the performance? I thought the cloud was going to make everything better."

 

Scott

Yeah, I don't know if you ever heard of a .NET CMS named Orchard. Orchard was this really interesting C# ASP.NET project that wanted to be a content management system and it had a fair amount of success, and I'm pretty sure it's still around today, I just haven't worked on it in a while. It might've even been eight years ago now. We wanted to try out Orchard and we deployed Orchard to a virtual message machine inside of Azure. And the thing to know about Orchard is that was such a dynamic customizable system that you basically deployed Orchard, if I remember, by deploying source code. And at runtime when you hit a website with the browser, they did all dynamic compilation that would compile dozens and dozens of projects and extensions and plugins that were part of the Orchard CMS.

So when you were hitting the system, there was a lot of compilation going on and you would not believe how painfully slow this website was running on a really beefy virtual machine. We couldn't figure it out. And then eventually we figured out, "Oh, it's because it's doing all these disc reads and writes when it's compiling. And that's just taking for ever. This is not a workable solution." Fortunately, there was a way to basically pre-compile Orchard so it wasn't doing all of this at runtime. But we lost some of the flexibility, but that was the solution for that problem.

Locally, you wouldn't notice. Locally, might be a three second delay or five second delay it's not optimal. But honestly in Azure, you would run that thing and it would take minutes to load the home page.

 

Jeremy

So what cool new projects are you working on right now?

 

Scott

Oh, what do I have going on? Well, I have one project that's using Blazor. So it's the first real project where I've done any UI in a couple of years. And somewhat enjoying UI development again, it's not nearly as frustrating as I was a few years ago and I'm digging into Blazor and learning a bit about how to work with Blazor. So that's exciting. I've also been working a lot lately with something called FHIR, F-H-I-R, which is the Fast Healthcare Interoperability Resources specification, very exciting sounding. It's basically a standard to try to get healthcare resources to work together a little bit better. So if I went to go to your hospital or your physician's office and get a list of patients, if you can tell me where your FHIR server is, hopefully I can issue an authenticated get request every HTTPS and start pulling patient resources without doing a ton of integration work.

Like one of the challenges in the healthcare industry these days is, "I want your patient data to analyze," and you have to give me a database connection to your custom schema or you have to export files or this just all messiness in the healthcare data.

 

Jeremy

Yeah, that's amazing, the different scheme and different ways that everybody stores things all the different providers and then you have the different health insurance companies and then you have reporters, firefighters, paramedics, all of this data is all stored in all these different formats.

 

Scott

The entire industry vertical to me is just staggeringly complex, sometimes depressingly so. I haven't been in a lot of different verticals, but I can't think of another vertical that has anywhere near as complex as the healthcare industry, particularly here in the States where you have this combination of facilities like hospitals that provide health care. You have physicians and doctors which are and healthcare professionals, which are a different cast. And then there's the insurance industry itself, which adds a whole additional layer of complexity to everything. And that's just these crazy amounts of complex.

 

Jeremy

Do you have any Pluralsight content in the works or anything that we might want to know about?

 

Scott

The mix course I'm probably working on is going to be a small short Razor course, I believe. So it's going to look at just having Blazor, Interop with JavaScript in the browser. So looking at things like, "How do I call a browser API from my Blazor app? How do I call C# Code from JavaScript Code?" Going to be a short one, probably less than two hours, but hopefully it'll be finished by early next year.

 

Jeremy

Definitely will be looking forward to that and we'll likely take it, take that course. Thank you very much, Scott, for doing this. It's very nice to be in the .NET Renaissance as you put it, when I talked to you at live, we're talking about the .NET Renaissance coming in.

 

Scott

Yeah, I think it's still the early days or I think the exciting times are still ahead and thank you for having me over.