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?

Read More

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

Read More

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.

Read More

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.)

Read More

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?

Read More

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.

Read More

• 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.

Read More

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.

Read More

I was asked this past week what my thoughts were on Angular 2. I wrote early on about my impressions of Angular 2 when it was barely done enough to review. But now that I’ve been working with it for a while and know a bit more, what I want to discuss is more along the line of what it means to the average developer and, more importantly, organizations that are planning to use it.

Options

While like Angular 1, Angular 2 provides us with most of what we need to build an application. Angular 2 also provides us, out of the box, with very Angular 1 ish ways of putting together an application, complete with modules. What Angular 2 provides that isn’t quite so obvious going into your development is options.

In angular 1, we had options at the GUI level. And while this is still true for Angular 2, this is not the only place where you will see options.

In general, you can split your options into, 1) do you want to do things the Angular 1 way, or 2) would you like to use an approach that looks more like React.JS? No place is this more obvious than with how you deal with forms. You can create forms with a declarative syntax, like you’ve done with Angular 1, using Template Syntax. But, in my opinion, a much better way to create forms is with a more reactive approach using the FormControls and FormGroups classes. If all you are doing is just displaying data, you’ll probably find that using the template syntax is all you need. But once you start working with complex forms that accepts data input and implements validation, you’ll probably want to move toward a more reactive approach. The added benefit is that more of you code will be testable.

The next option you are going to have is figuring out how to move data around your system. Most of the literature is going to suggest you use a data flow that looks a lot like what you were doing in Angular 1. But there is nothing stopping you from using Flux, Redux, or even RxJS instead. And here again, my recommendation would be that you learn these because I think you’ll find that your system will end up being much easier to reason about than the old MVVM stuff you may be used to.

Lazy Loading

There are several places where we had to make choices in Angular 2 where the feature has been built into the framework. One of these places is lazy loading. Why load all of your JavaScript up front? Load what you need when you need it. Angular 2 makes this easy with Lazy Loading and the choice between using WebPack (the default) or System.JS.

I’ll warn you though, as of this writing, Lazy Loading only really works when using System.JS unless you want to spend a lot of time tweaking your webpack config file.

Angular 2 CLI

Command Line Interfaces seem to be the cool new kid on the block. You aren’t a real framework unless you have one. While the Angular CLI is not quite baked yet, I can see how this is going to make writing Angular 2 apps much easier. There are a lot of moving parts involved in getting even the most basic of applications up and running. The Angular CLI makes starting your first application REALLY easy. It even hides all of the WebPack internals while allowing you to add your own config file if you need to. Once they have the routing bit re-implemented, it should make using Lazy Loading with WebPack much easier.

The other thing using the CLI will do for you is that you will automatically start following the coding standards that the Angular team have developed.

Angular 2 Components

Right now, there aren’t a lot of options available for Angular 2 for custom components. While Kendo UI has been the defacto standard for Angular components in the past, Telerik is in the middle of rewriting Kendo UI for Angular 2 (and React.JS). I haven’t seen any movement in the Angular UI camp to support Angular 2. Angular 2 Material has a few components that seem ready, but they are all relatively simple. The only vendors that seems to have a complete Angular 2 package is Wijmo and Prime Faces. I haven’t tried them and I’m not endorsing them. I’m just reporting what I’ve found. There are a few standalone components here and there, but if you are looking for a set of components you can just use from one source, I’m afraid you’ll have to wait. This isn’t necessarily a bad thing. It gives you time to properly learn Angular 2.

But what about the Angular 1 to Angular 2 bridge? In my mind this is way more trouble than it is worth. We’ve waited two years for Angular 2, I think we can wait just a bit longer for a set of components that we can use with it.

What Angular 2 Means for You

The main difference between Angular 1 and Angular 2 is that just about any Script Kiddie could pick up Angular 1 and get something done. Angular 1 was developed during a period of JavaScript history when JavaScript had not quite reach the level of “serious programming language.” But now, JavaScript has not just reached that level, but several very serious frameworks have been developed.

What I notice as I review the JavaScript landscape is that we’ve moved from just getting stuff done with little to no planning, to treating JavaScript as a first class programming language that requires, and even demands that we adhere to a set of programming best practices that we would use for any other language. These include things like naming conventions and design patterns. For you to write code well in this new universe, you will need to understand what these design patterns are, why they exist and how to implement them well. If you continue on your merry script kiddie way, you will soon find yourself out of work.

Further, if you think you know Angular 2 just because you know Angular 1, or you think Angular 2 will be easy to pick up because you know Angular 1, you are in for a very big surprise. Many of the concepts are the same. But since Angular 2 has so many options, you should learn the options well so that you can make an educated decision about which option to use.

What Angular 2 Means for Organizations

Similarly, if you are an organization that is planning to move to Angular 2, don’t expect your programmers to just pick up and move to Angular 2 overnight. Give them time to learn it. My recommendation is that you make learning it part of their job while they continue to use Angular 1 for the product you are trying to complete. We all have time pressure, so you need to factor learning into the schedule.

But Angular 2 may also mean you need to find additional programmers who already have the skills and can transfer the knowledge to your team.

This past week I got into a small discussion about the importance of loosely coupled code.  Specifically, I was looking at event handler code that did nothing more than change the size of another element on the screen.  But the event handler code was in the controller which in the particular implementation we are using was the event handler portion of our Model in a MVVM architecture.  The question becomes does this code belong in the view, or does it belong in the controller? The question of where code belongs leads eventually to arguments for loosely coupled code.  If I put code in my controller that is manipulating the view, then I either need to mock out my view in order to test my controller or I have to have an instance of my view available to test my controller.  Having coded enough systems to know that both of those choices are problematic, I opt for placing the view specific code in the view.  Another place where you might place this code would be in a View Specific event handler class.  But that would only be for the purposes of clean separation.  Something we might consider doing if the View were plain HTML.  But in our particular case, the view is generated from code, so placing the handlers in that same code seems to be the most appropriate location for it.

But all of this leads to a larger question.  Why should your code be loosely coupled at all?

Read More