Dave's Notebook

Awesome Angular2 Architecture Options and Opinions

On the subject of Angular2 Architecture, the perception is that Angular 2 is a highly-opinionated architecture. But even though there is a style guide for Angular 2, there are a lot of decisions that still need to be made when working on any but the most trivial of applications. And even then, since most applications take on a life of their own, one could make the case that you need to make these decisions for any application you are building regardless of the initial size. Applications grow up. But, that’s another blog post

I’ve identified, and have formed opinions about 5 areas that Angular 2 leaves open for decisions. Areas that if you don’t spend time considering the choices and making decisions could cost you in the future

The five areas I’ve identified are:

  1. Handling Forms
  2. Page State Management
  3. Component State Management
  4. Data Flow
  5. Client Side Data
![](/uploads/2016/12/image-2.png "Awesome Angular2 Architecture Options and Opinions") Photo via [africaniscool](//pixabay.com/en/users/africaniscool-216435/) via [Visualhunt.com](//visualhunt.com/photos/business/)

Read More

Dissecting Angular 2 Modules

In the new world of Angular 2, and even in the world of Angular.js, you might feel like the concept of a module is the most difficult to wrap your head around.

This is especially if you’ve only ever written client side JavaScript code. Once you’ve learned why you need a module, the temptation is to use one module for all your code. I am guilty of doing that myself when I first started. But, many times using one module for your entire application is the wrong thing to do because it reduces the ability to reuse your code in other modules. Once you understand why modules exist, you’ll begin to reason about how to use modules appropriately.

![](/uploads/2016/12/image-1.png "Dissecting Angular 2 Modules")
Photo credit: [Sappymoosetree](//www.flickr.com/photos/bahkubean/416801559/) via [Visual hunt](//visualhunt.com) / [CC BY-ND](//creativecommons.org/licenses/by-nd/2.0/)

Read More

Reasons to use RxJS Today

If you’ve started looking at Angular 2, one of the things that you’ll notice is that RxJS has gotten a bit of a toe hold in the framework. This becomes apparent the first time you try to access data. Gone is the $http service that returns a promise. Instead, we now have a service that returns an Observable. Now, writing the code to access the server is arguably easy to learn. But, as you travel down the rabbit hole that is Angular 2, you realize that RxJS shows up in places as disperse as NgRX/Store, handling events, and as we’ve already mentioned, AJAX calls.

Because it shows up in so many places, this new API is set to be the next thing we will need to learn to be effective JavaScript programmers. But, should we?

![](/uploads/2016/12/image.png "Reasons to use RxJS Today")
Photo credit: [Dace Kiršpile](//www.flickr.com/photos/91035846@N05/9374805577/) via [Visualhunt](//visualhunt.com) / [CC BY](//creativecommons.org/licenses/by/2.0/)

Read More

Angular 2 Lazy Loading

Last week when we took a look at Client side Routing, I mentioned that one of the reasons you’d want to implement a component in its own module is so that we could lazy load the component and its dependencies

This week, we want to dig into how to implement lazy loading in your Angular 2 application

![](/uploads/2016/11/image-5.png "Angular 2 Lazy Loading") Photo via [jordan](//pixabay.com/en/users/jordan3600-400129/) via [Visualhunt](//visualhunt.com/)

Read More

Adding Client Side Routing to Angular 2

Over the last several Angular 2 posts, we’ve been building up our application bit by bit and examining the various features of Angular 2 along the way using the Angular CLI where that makes sense and modifying it along the way. So far, routing is an area that the Angular CLI does not yet support and so, when you want to use routing in your Angular 2 application, you’ll need to wire most of it in by hand. Now, the routing engine has changed several times during the development of Angular 2. And I know you’re wondering which version of the router this article is going to be talking about. So, to be clear, this article was written using the Angular CLI version 1.0.0-beta.21 and Router version 3.2.1.

![](/uploads/2016/11/image-4.png "Adding Client Side Routing to Angular 2")
Photo credit: [xomiele](//www.flickr.com/photos/xomiele/6759264721/) via [Visualhunt](//visualhunt.com/photos/snow/) / [CC BY](//creativecommons.org/licenses/by/2.0/)

Read More

Unit Testing an Angular 2 CLI Project

This week we want to continue our series about Angular 2 by looking at the Unit Testing capabilities that Angular 2 provides for us. What we want to cover today is:

  • Tweaking Karma to avoid using the Browser Window
  • Code Coverage
  • Tips to testing components

This article was written using Angular CLI version 1.0.0-beta.20-4 (Tip, if you are upgrading on windows, rm –rf node_modules dist temp just means to delete the three directories. You can do that part manually, or install bash for Windows and run the command in bash.)

![](/uploads/2016/11/image-3.png "Unit Testing an Angular 2 CLI Project")
Photo credit: [jimmiehomeschoolmom](//www.flickr.com/photos/jimmiehomeschoolmom/4427775569/) via [VisualHunt.com](//visualhunt.com) / [CC BY-NC-SA](//creativecommons.org/licenses/by-nc-sa/2.0/)

Read More

What’s the Truth about Running ASP.NET WEBAPI Asynchronously?

When Node.JS started getting popular, one of the major benefits people were proclaiming about it is that the web servers running under Node.JS were all processing the request asynchronously. This is how a single threaded environment was able to handle a significant load without falling over. Cool! So, you might wonder how does ASP.NET process request? It processes code synchronously. So, one might assume that if there were a way of running code asynchronously, we might be able to improve the performance of our applications. But can we? And if we can, is it worth it?

![](/uploads/2016/11/image-2.png "What’s the Truth about Running ASP.NET WEBAPI Asynchronously?") Photo via [VisualHunt](//visualhunt.com/)

Read More

Getting Started with Angular 2

Angular 2 is finally released. But the biggest problem with learning Angular 2 is that it is a “Choose your own adventure” kind of framework. And while React has a similar problem, I think Angular has out done them. This means that you can learn bits and pieces of Angular 2, but it will be a while before you get a cohesive understanding of what choices you need to make, which choices are the right choices, and why all of this matters.

And all of this is even more difficult if you are a relatively new programmer. I’m talking those of you who have less than 5 years of experience and even some of you who have less than 10 years of experience.

So, what I thought I’d do to address this very real problem is to assemble a very opinionated Angular 2 tutorial. Over the next several weeks I plan to show you how to create a simple CRUD application using Angular 2 in a way that will scale up to larger projects. While I may mention some of the other options along the way, what you’ll end up with is the “right way.” OK. To be fair, most of what I consider “right” is opinion. Some very smart people disagree with me. But, some other very smart people agree with me too.

![](/uploads/2016/10/image-2.png "Getting Started with Angular 2")
Photo credit: [mikecogh](//www.flickr.com/photos/mikecogh/11300349426/) via [VisualHunt](//visualhunt.com) / [CC BY-SA](//creativecommons.org/licenses/by-sa/2.0/)

Read More

The Myth of Sloppy Code

  • Tightly coupled code runs faster.
  • Tightly coupled code is easier to write.
  • Test Driven Development increases development time.
  • Test Driven Development negatively impacts code design.
  • Knowing the names of design patterns isn’t important as long as you can use them.
  • All my customer cares about is how soon they can have the product, not how clean the code is.

All of these statements, and others like them, are excuses for not writing code correctly. And you know what an excuse is, right?

The skin of a reason stuffed with a lie.

![](/uploads/2016/10/image-1.png "The Myth of Sloppy Code")
Photo credit: [dynamosquito](//www.flickr.com/photos/dynamosquito/5866244470/) via [Visualhunt.com](//visualhunt.com) / [CC BY-SA](//creativecommons.org/licenses/by-sa/2.0/)

Read More

Revisiting The Technical Interview

I’ve written about the technical interview before. I’ve written both for and against code interviews. And I’ve provided both C# and JavaScript questions to weed out fake programmers. But a little more experience under my belt has me rethinking what makes a good interview.

Now, you may wonder why I think I’m particularly qualified to speak about the interview process. Most people who have opinions about the interview process in particular have it from only one side. The one of being the guy looking for a job. And, most of you only interview when you need a job.

What makes me qualified is that, I help interview people looking for a job and I interview for lots of jobs. In my opinion, you should be interviewing for a job, even if you don’t need one, at least twice a year. I interview more frequently than that. In the last 6 months, I think I’ve interviewed at least 4 times.

So, let me start by telling you what the current interview process looks like, and why it doesn’t work. Then, I’ll move on to the few interviews that I believe captured the information everyone was looking for quickly and how you can move the conversation in this direction regardless of what side of the table you are sitting on.

![](/uploads/2016/10/image.png "Revisiting The Technical Interview")
Photo credit: [Gangplank HQ](//www.flickr.com/photos/gangplankhq/5590138183/) via [Visualhunt](//visualhunt.com) / [CC BY](//creativecommons.org/licenses/by/2.0/)

Read More