Tagged with Web Development
Writing web apps has become complicated. Transpilation has made some thing really awesome, but it also has complicated the field. Webpack, Browserify, Babel and even TypeScript have all make our lives easier and awful at the same time.
I loved this tweet about our current situation:
When I built this blog, I wanted to get comfortable with Angular 2. I shoehorned Angular 2 into the contact page as an excuse to use it. Never a good decision.
My goal with replacing Angular 2 was to remove a lot of the complexity. Getting Angular 2 up and running requires a lot of moving parts. By removing Angular 2 I was able to eliminate a lot of pieces of the build. These pieces were making my builds on Azure App Services brittle so it had to go.
So I’ve been on a mission of sorts…I’m looking for the right size framework for some of my web development. I know what you’re saying, “Aren’t you suggesting Angular2 for everything”? No, no I’m not.
I just made a bunch of you excited. You React, Aurelia, and Ember enthusiasts and now probably foaming at the lips ready to tell me to use one of your frameworks! Hold off for now. Let’s talk about it.
The problem for me is fairly simple, I don’t want to build a Single Page Application (e.g. SPA). Yeah, I know.
I know this was a “click-bait” post name, but so be it. I’ve been doing some small Angular2 in a recent project (rebuilding the new Atlanta Code Camp website) and I’ve been frustrated with the amount of ceremony. But I may be misunderstanding Angular2 so bear with me.
The problem for me is in the idea of SPA in general. SPA seems to imply monolithic apps but written in client-side web code. For a single, large scale application, Angular2 seems like it is just right…but that’s not what I do.
I want client-side frameworks to fill in the holes for when a website needs rich user interaction. Making every part of a page some sub-element in a huge SPA makes as little sense as the old monolithic Visual Basic 3.0 apps that used to be the norm.
As you can see, I recently updated this blog. I wrote the new blog using ASP.NET Core RC1 (as related technologies) so when time came to deploy it, I had some issues.
At the time I thought it was Azure, but after testing with an empty project that worked, I figured it was probably something I did. In this post, I’ll talk about what I did to get it to work in Azure Websites.
There a couple of ways to do this. I preferred the publish from source approach. You can use the Visual Studio publish options too:
When I created my blog in ASP.NET Core, I forgot about one feature that I used to help out some other Pluralsight authors by creating a quick top 100 list of courses. Because Pluralsight doesn’t really expose that data as an API, I didn’t want to hammer their service, so I had been using a memory cache to do it.
But when I moved the code over, I realized that the old, reliable Cache object was missing. Luckily I found it and like much of ASP.NET Core, adding it was simple and consistent. Let me show you.
First thing was to see how caching was being handled. Instead of having different caches, ASP.NET Core has an abstraction around caching and then you can support different types of caches. For me, it was a simple memory cache I wanted so I needed two Nuget packages:
I had the opportunity to do three talks and two of them went well (if you were at my Bootstrap talk, you know what I’m talking about). In any case, I wanted to share the slide and code with the attendees so here it is:
I had planned on finishing these a long time ago, but working on my Pluralsight course about ASP.NET 5 distracted me. Sorry about that.
If you’ve been doing web development in .NET, you probably have at least a passing experience with ASP.NET’s MVC framework. At it’s core, it’s a common way to build and architect web applications. The new stack is built on the same metaphors from the older versions. If you’ve been using MVC before, you won’t be lost and some of the additions are welcome.
I’ll explain what I’m doing in a series of blog posts and link them all here as I write them. The plan is to write posts about:
Part 4: ASP.NET MVC 6 (This Post)
Part 6: Web Tooling with VS2015 (coming soon)
NOTE: This post has been updated for changes in Beta 7 and later.
Every web project needs some sort of data framework and ASP.NET 5 is no exception. Like it’s forbearers, ASP.NET 5 uses Entity Framework, but this version of the Entity Framework is different. It’s being re-engineered from the ground up just like the ASP.NET 5 stack.
In this, the third part of my ASP.NET 5 series, I’ll be talking about Entity Framework 7. While you can use older versions of EF or other storage mechanisms (NoSQL, Postgres, etc.), I think it’s an interesting exercise to see what the EF team is thinking in this evolving version of the framework.
I’m on the World Tour and this stop is in Delhi, India! While here I had the fun opportunity to give a talk on AngularJS to a great group at Sapient in Delhi, India.
Via Pluralsight and the great Pinal Dave helped organize this event. If I go long enough without giving a talk, I start to get the shakes. The group had great questions which I always like.
As promised, here is the code and slides:
In this second post in my six-part series on ASP.NET 5, we’ll take a look at how your ASP.NET 5 applications will be configured upon startup. The startup in this new version of ASP.NET 5 is very different, but hopefully is clearer and easier to debug. At least that’s my impression so far.
If you haven’t read the prior topics, it would probably be helpful to start with the earlier articles. You can see a list of the links to the articles below:
Over the past few weeks I’ve been playing with the new ASP.NET 5 (also known as ASP.NET vNext) bits using Visual Studio 2015. I’m trying to make sense of the new changes and how they will affect how I build websites. I’d like to share some of what I’ve learned about the new stack.
I’m going to do this by talking through an example website I wrote using the new bits. Do know that we’re still pretty early and Visual Studio 2015 (CTP6 as of this writing) and ASP.NET 5 Beta 3 are both in a state of flux. This is definitely about what’s coming, not what is here so far.
I’ll explain what I’m doing in a series of blog posts and link them all here as I write them. The plan is to write posts about:
I’ve been working on a new web site wholly using the ASP.NET 5 (e.g. vNext, MVC6, etc.) for the past couple of weeks. This means using Visual Studio 2015 Preview and the new project types in ASP.NET 5.
The idea around the site is to be an example of an ASP.NET 5 site using MVC6, EF7, and Visual Studio 2015. It’s not perfect and ASP.NET 5 isn’t ready yet so I expect to continue to fix and remove hacks for quite a while, but it’s been fun to dig into a whole new stack while it’s still getting the kinks worked out. Here are some of my first impressions.
You can see the code as it progresses, I’m I’m not done yet, but I’m sharing the code I’m working on via GitHub here:
I might be. In many of the projects I help with we have to handle back-end and front-end coding for web projects. This means I need the best in breed in tools no matter where I’m writing code.
In many cases this is Visual Studio. I love this tool and have for years. While it’s not without it’s own foibles, it does most things really well. But not everything.
The new course is all about using WebStorm 9 to build web applications. The course was built using the WebStorm 9 EAP so I was able to cover new features as well as the basics.
So AngularJS team finally is talking more publically about what they’re trying to do. At the ngEurope conference last week, they talked very opening about their new strategy for AngularJS 2.0 and it has a lot of people freaked out. Sounds a lot like some reaction to Silverlight in fact.
I’m seeing a flood of hate on the AngularJS team at the moment. I am not sure it is justified. Here’s why:
While there are a lot of details about what they’re thinking being shown and shared, the reality is that AngularJS 2.0 comes out in 13 months. A huge amount of time in web development. I am sure they are hearing all the concern and fear and are taking it into account. I suspect it will be fine.
I know that the title of this post may be a bit of link bait, sorry about that. But having been in this business quite a while now, I am noticing a trend. A trend that worries me.
The Single Page Application (or SPA) moniker is one I’ve always disliked (as you’d know if you follow me on Twitter). But it’s not the technology I have a problem with, it’s the moniker and the implications of the moniker.
I started doing web development in the ‘90s on ASP (no, not ASP.NET). This was a treasure trove of open database connections, imported headers, and clunky HTML. I never thought we’d get to where the web was a mature platform to develop upon. In the past few years, technologies like Knockout, AngularJS, BackboneJS and the like have all contributed to a richer client-side experience. No longer were we dependent on post-backs or page requests to get the job done. Things are good. They are really good.
I am getting married and that means I get a bunch of development tasks to do for the wedding planning. I guess it’s my own fault, I did propose with an app.
One of the tasks I had to do was create a new page on my wedding site for the day of the wedding to include things like directions and parking. Pretty simple HTML stuff, but one thing I wanted to be sure of was to only show the page on the day of the wedding. This should be easy, but the time zone of the server has kicked my ass before.
The problem is that if I check for the date, the date might get shifted if the time is after midnight where the server is. Luckily the TimeZoneInfo class makes this pretty easy in C#. The trick is to first get the time zone you care about:
I am a developer first. I’ve become my family’s IT department but not by choice. This is the fate of most developers I know.
For the past year or so I’ve been experimenting with Azure Websites as a solution for quick, one-off sites and even for class examples. I’m a big fan. Let me tell you why.
Azure is a diverse landscape with lots of services. It be a little daunting. I’ve some of these services, but certainly not all. Azure Websites is particularly interesting to me in that fulfills my desire to not be an IT guy. Why?
I recently had the pleasure of talking to the “A Bunch of Devs” user group in Atlanta about Web API. I had never spoken at this group and I had a great time.
They had really great questions all around. If you have a chance to visit the user group, it is really worth your time. Of course, free pizza is never a bad thing.
Here are the slides and the code from that presentation:
As some of you know, I’ve been delving into Node.js for a new Pluralsight course that is coming out soon. One of the interesting aspects to me is the idea of server-side view engines. As an ASP.NET (and ASP before that) guy, I’ve been using server-side view engines for a long time…not that we always called them that.
Jade (NPM Package Name: jade) is interesting to some because it’s very terse and (in theory is quicker to write). It’s also similar to the default view engine (AFAIK) for Ruby on Rails so that is going to make it pretty popular. Here is the syntax:
Depending on your environment, you’re probably already using some package manager for your server-side code. Gems for Ruby, Nuget for .NET, NPM for Node…whatever. In any of these cases you’re used to being able to get the piece of code you need and the other requirements. For the web this is more difficult…or used to be.
For web projects, we’ve needed a way to get these client-side scripts. Sure Nuget or other package manager *can* do this but it’s been a round peg in a square hole. That’s where Bower comes in.
Bower is a simple package manager for the web. Bower depends on node and npm so you need them installed first. And if you do, then installing Bower is as simple as using NPM:
I’ve been getting good feedback on my Web API course on Pluralsight but some of the comments have concerned me. Lots of the students (from my small sample size) seem to be trying to infer how to *design* an API, not just implement one. That course is specifically about how to implement an API.
What’s important as far as I am concerned is to well design the API (regardless of which way you implement the API). So if you’re starting to use Web API and you need an API for your app, for your customers, or for others to consume (e.g. 3rd party developers) – stop figuring out how to implement the API and go back and design the API.
This is especially important if you are new to the notions of REST. Essentially, you need to understand the ‘Why’ instead of focusing so much on ‘How’.
Are you starting to work with Bootstrap 3? If so, maybe I can help. I’ve recently released a Bootstrap 3 course on Pluralsight that covers many of the new features including how to migrate from Bootstrap 2 to 3.
Here is an excerpt from the course where I explain how the new grid system works in Bootstrap 3:
If you’re interesting learning how the new Web API 2 works, you’ll be happy to hear that my popular Pluralsight course “Implementing an API using ASP.NET Web API” now has a new module that shows you how to use the new features in Web API 2!
The Web API 2 features that I cover include: