My Rants and Raves about technology, programming, everything else...
As I expect most of you already know, I'm making a documentary film about software developers called "Hello World: The Film". I've started a crowd funding campaign to help me finish the film.
If you're a software developer or just know one, you might be interested in helping me make this film a reality. The film delves into the mind of software developers and the history of the business.
You can contribute here:
Thanks to everyone who came to my webcast today! As many of you know, Bower is depreciated so I've been looking at the different ways to move to other solutions.
In the webcast (which will be streamable soon), I discuss using NPM, Yarn, LibMan (an upcoming tool for Visual Studio), and Gulp to get and package your client-side assets.
You can get the code I showed on Github:
As I've been teaching ASP.NET Core for a while now, some things I've been saying I've taken on faith. One of these was that building a Configuration Source (a provider that can read configuration and feed it into the configuration system) is fairly easy.
With a break in building my Vue course, I was curious so I decided to build a configuration source that I hope no one uses. It is a configuration source that reads the AppSettings in a web.config file. This is a thought exercise, not a recommendation.
In order to be a Configuration Source, you must derive from the IConfigurationSource interface. You could implement this interface directly, or if your configuration is file based (like the one I built), you can simply derive from FileConfigurationSource. This class deals with most of the problem of opening and reading a file. Since my Configuration Source is to read the web.config, that's perfect.
In my Pluralsight courses1 on ASP.NET Core, I show how to use JWT Tokens to secure your API. In building a new example for my upcoming Vue.js course, I decided to only use JWT (not cookies and JWT like many of my examples are).
But I kept getting redirects on failure to call an API made me realize that I wasn't sure how to make JWT the only provider. After some fiddling I figured it out. This blog post is mostly to remind me of how to do it.
After help from @khellang - I found the real culprit. See new section at the bottom.
Ok, please tell me how stupid this is. It's apt to be pretty stupid but I have a point to it. I'm trying to separate the ideas of prototyping quickly from preparing for production.
I've been using Bower to do examples of client-side dependencies. Bower is depreciated so for new dev, I don't want to recommend it (and VS2017 has removed it too). Bower is clean as you don't have to introduce a bunch of ideas like gulp or npm scripts to get someone with a working example quickly (Bower's .rc file let's you tell it where to put the dependencies). I want to do the same thing with NPM.
Here is the idea. Instead of writing a script or using gulp to move the files, I'm thinking of using UseStaticFiles to just allow node_modules directory to be available to client-side development. My expectation is that this is a development-only idea and will allow you to get up to speed quickly. But when you're ready to deploy, you'll need to do the harder work of writing a NPM script to copy only the files you really need.
Orlando during Spring Break probably wasn't the best idea, but luckily I got to go to the Orlando Code camp instead of fighting people at Disney.
I had a good time talking with people about Vue.js. Great catching up with the other speakers and so many friendly faces among the attendees.
As promised, here is the code and slides:
I've been digging into Vue.js a lot lately. I'm working on a new course on it that will be released on May 1st.
Coming from Angular and Angular.js, I was surprised to see that remote views were not supported out of the box. Now I'm not using it with Webpack or Browserfy, so I am probably using it outside the norm. But I still think remote views (or in the case of hosting in ASP.NET, generated views) are a powerful idea.
I kept looking for a plugin that would support it. I was ready to ditch the whole idea when I saw in the docs they explained in there (almost).
I'm getting around to this a little late, but late last month I had a great time presenting in Charlotte's Enterprise Developer's Guild. I showed them how ASP.NET Core 2 works.
They had a full house and I got to talk about how ASP.NET Core 2 and .NET Core itself works. Great questions about why bother with ASP.NET Core and how it's related to the new "Core" moniker that Microsoft seems to be putting on everything (answer is, probably no relation, just a marketing group that is latching on to the name).
Here are the materials from the talk:
When I created my Bootstrap 3 course back in 2013, I never thought it would take five years to get to the new version of Bootstrap 4. Back in 2016, I outlined and got ready to create a new course about Bootstrap 4. But it never came out. Until now.
I had always planned to do this course for Pluralsight, but they are changing some of the ways they want to publish content. So this is giving me the chance to promote some one-off courses that they don't have room for in my own course library. Bootstrap 4 is the first of these full-length courses.
You may have seen that I recently published a free course on Font Awesome 5 (if you haven't, go watch it for free here: https://courses.wilderminds.com/courses/font-awesome-5). This course is a good example of what I'm trying to do with these one-off courses. They differ from what I can do with Pluralsight in that I have a quiz at the end of each module and a lab for students (who want to) to go through instead of just following along with the video. My courses will be still focused on being pragmatic and showing you all the code, but some people just do better with written out labs so I'm making them both available.
I feel like the job of software developer in the last 20 years has been to decouple. Whether it's dependency injection or building modular systems, or even the new trend of micro-services; coupling has been the killer of everything good in software development (maybe).
In many small ways, I find that trying to fit in small disconnected sets of functionality into the ASP.NET MVC Controller to View mechanism can be overwhelming. In some cases I'll need something that is completely separate from the logic of the controller. Luckily ASP.NET Core comes to the rescue.
The ServiceContainer in ASP.NET Core is great, but we tend to worry about constructor injection in most cases. But once I realized I could inject directly into Razor, I realized I had a good solution for my needs.