The Tom Bomb

My name is Thomas Desmond: Full Stack Developer, Speaker, Educator, & Thinkster.io Author.

Managing your RxJS Observable subscriptions in Angular with SubSink

Angular Logo

RxJS and Observables are HOT in Angular now. Many of us have started using them and they are not too difficult to pick up and begin using. But there is probably a small piece you are forgetting…Unsubscribing to your subscriptions.

Way too often I open up an Angular Component and inside the ngOnInit() I see a subscription that is never being unsubscribed from. Something like this:

Above we have our userService, and we are subscribing to the GetAllUsers method in our service. But we never assign our call to any variable. This is an easy way to know we are never unsubscribing from this call.

Now you may have many calls like this in your app and it works fine. You don’t notice any ill effects. But this is bad practice. If we subscribe we need to unsubscribe. We should not leave subscriptions laying around. We don’t want to leave tons of open subscriptions. So what should the above code look like?

Above, we created our sub variable to hold onto the subscription. And in the ngOnDestroy lifecycle hook, we unsubscribe. This looks pretty easy. Just a few extra lines of code. But what if we had lots of subscriptions. Having to add many new component level variables can clutter up our file quickly. And we already have a hard time remembering to unsubscribe, is their an easier way?

This is where the package SubSink developed by Ward Bell comes in. Managing subscriptions should not be difficult and SubSink makes it easy. The same code above using SubSink would look like.

There are two easy ways we can use SubSink shown above. In Method 1 we directly add our subscription. While in Method 2 we are using a setter to add the subscription to the sink. Both end up doing the same thing functionally but we can use either syntax.

In the ngOnDestroy, we have one simple this.subscriptions.unsubscribe() call that does all the unsubscribing to all of our subscriptions for us. SubSink makes it much easier to manage our subscriptions and gives us no excuse to not remember to unsubscribe from them.

SubSink makes our lives easier managing the subscriptions for us. Making our code easier and less cluttered is always a big win!

If you are an Angular developer check out my post on Must-have VS Code Extensions for Angular Developers!

Must Have VS Code Extensions for Angular & Typescript

Let’s take a look at the VS Code extension that I use regularly when developing Angular code. I like my extension to make me a more productive developer. Many of these could be helpful outside of Angular development but these are some that I like.

#1 Angular Snippets

This extension is great because it gives you access to many useful Angular, Typescript, and even HTML. I find myself using the HTTP related snippets often. Snippets are great because you no longer need to memorize complex syntax and can now focus on the development.

#2 Material Theme Icons

Material Theme Icons is great because it changes all the icons used throughout VSCode with beautiful icons. It makes it much easier to discern between the different files in your project. Not only does it have icons for the different file types but also folder types. I highly recommend this extension to make your editor look nice and clean.

#3 Bracket Pair Colorizer 2

Bracket Pair Colorizer is one of the first extensions I install when if I come across a machine that does not have it. It changes the colors of all your brackets, parenthesis, etc. It even creates a line that connects each pair to one another. Just make sure to install version 2 because that is the one being actively developed.

#4 Typescript Importer

This one is helpful when working in our Typescript components. It will auto-import definitions for us. So if we start using a new service or a new model in our component on the first use it will automatically bring in the import. Again, this helps us focus on the development work not having to jump around the file importing new things.

#5 Angular Language Service

Angular Language Service is another great Angular extension. This one is developed by the Angular team itself. It helps make VSCode smarter with its auto completes and giving hints about what to do next in your Angular code. This one is a must-have for Angular development.

#6 Code Spell Checker

This is another extension that is helpful for any development done in VS Code. It checks the spelling of your code even for your camelCase variables. It is great at finding common spelling errors that we make in our code. This can be extremely helpful in finding those nasty spelling error bugs. Definitely add this extension to your VS Code if you have not already.

Two Angular 10 projects, same package.json, one project has 281 vulnerabilities the other has 0

The other day I was messing around with Angular and upgraded a project from Angular 8 to Angular 10. I wanted to see the new hotness! Upon upgrading my fairly simple application I was hit with 281 low vulnerabilities reported when I performed an ‘npm install’.

281?!? How could this be? I had zero before. Granted they are low but come on this is way too many. I scoured the internet and had trouble finding someone else who had the same issue as me. I thought to myself it must be because Angular 10 is so new.

So, I took the debugging into my own hands. I created a brand new ‘ng new’ project. Upgraded it to Angular 10, added all the same packages, and what do you know 0 package vulnerabilities. Two Angular 10 projects, the same set of packages, wildly different set of vulnerabilities.

This created a great deal of confusion for me. So I ended up taking the fight to Reddit. I presented my problem hoping the great ether of Reddit would be able to find a solution for me.

And you know what, they did! After a few failed attempts to fix the problem someone suggested deleting my entire node_modules folder and the package-lock.json file. Simple stuff right, I’ve done this before actually on different projects. How could I have forgotten this simple trick.

After deleting the node_modules and the package-lock.json file. I tried ‘npm install’ again and behold 0, zero, goose egg, vulnerabilities. Apparently npm is not the best at cleaning up after itself or taking the very latest packages.

Deleting node_modules and package-lock.json to have them recreated by an ‘npm install’ will not solve everyones problems. But if you are seeing issues revolving around npm not pulling down the very latest versions of packages, this very well may be a good solution for you.

Speaking at Agile + DevOps West 2020 Conference

I have recently accepted a speaking position at Agile + DevOps West 2020. I will be headed to Las Vegas in June 2020 to speak on “The Life of a Mob Programmer”. I will be sharing my thoughts and experiences as a full-time Mob Programmer at Hunter Industries for the past four years.

I am excited to share our development practices with everyone. How mob programming started. The benefits that I have experienced because of it. And why I enjoy mobbing every day.

I do not need or want to convince people mob programming is what they need to do, but rather I do want to encourage people to innovate. Encourage people to try new things and break from a standard ‘Agile’ development practice.

I encourage you to come to the Agile + DevOps West 2020 conference and you will find me speaking about Mob Programming June 11th!

App Module vs Core Module vs Shared Module vs Feature Modules in Angular

Angular Icon

Angular development best practices indicate we should break our applications into modules. Modules in Angular refer to a place where we group like components, services, directives, pipes, etc for our applications.

The easiest to think about would be Feature Modules we simply break these up by feature or domain. But what about the App Module, Core Module, & Shared Module?

What should we put into each of them? What components should live in each of them? Why do we need all of them? Let’s take a look at each of the types of modules and what they are used for.

App Module

Lets first take a look at the App Module in Angular. The App Module can also be called the root module. Every app must contain at least one module and that is the App Module. We launch our applications by bootstrapping the root module.

We want to keep our App Module pretty compact. There should not be a lot of content in the App Module or App Component. We want to encapsulate our application into domain-specific modules, the Core Module, & the Shared Module, which we will look into now.

Core Module

The Core Module is where we want to put our shared singleton services. So the services that we want only one instance of while having them shared among multiple modules should live here.

The Angular injector creates a new instance of a service for each lazily loaded module that it is provided in. We want to keep our singleton services in the core module so only one instance is ever created. We do not want to spread them out in our feature modules.

Another piece of our application that should live in the Core Modules are app-level components. A good example of an app-level component would be the navigation bar. Only the app needs to know about our navigation component.

We do not want to put components used throughout the application inside of the Core Module. We have the Shared Module for that and we will look at that now.

Shared Module

The Shared Module is where we want everything to live that is shared throughout the application. Components, directives, guards, & pipes can all live in the Shared Module.

An example of something commonly found in the shared module would be a loading spinner. If you have any other components that you want to be distributed throughout your application the shared module is where you want to keep them.

It is also common to import and export Angular built modules inside your Shared Module if you need to access them in multiple locations. Because Shared is imported into many of your Feature Modules it’s common to import/export Common Module or Angular Material modules. Import/Export the modules once in Shared Module and now anyone that imports Shared will have access to them.

Feature Modules

Applications commonly have multiple Feature Modules. Depending on the size of your application you may have A LOT of Feature Modules. Breaking things up into domain-specific areas can help in the long run for development.

One of the main reasons to break your features up into different modules is lazy loading. If you want to learn more about lazy loading check out the Angular documentation on Lazy Loading Feature Modules.

Laptop Code

Now you have a better understanding of how to separate your different modules in Angular. For more on modules check out the Angular Introduction to Modules.

Creating a C# ASP.Net Core API course now available on Thinkster.io

In June of this year, I began working on my first ever online technical course. It just got published! Check out my course published on Thinkster.io: Creating a C# ASP.Net Core API. I put in a ton of hard work to create the course and hope others can learn from it and enjoy it.

Link to Thinkster.io Course Creating a C# ASP.Net Core API

The course covers how to make your own API with C# using ASP.Net Core. It starts with the basics covering the GET, POST, PUT, & DELETE HTTP methods and expands into the more advanced cases. You will also learn about status codes, error handling & C# best practices.

The course provides you with the skeleton code for a space-themed API and contains four different exercises to reinforce and test your learning. By the end of the course, you will have your own fully functioning space-themed API written in C# using ASP.Net Core.

Basic knowledge of C# and the desire to learn is all you need to be successful in the course.

Brooke Avery and Joe Eames deserve a big THANK YOU for the support and help in developing this course. Expect more courses in the future. I think my next one will be on LINQ!

I am a podcaster now!

Over the past two weeks, I have been a guest on two podcasts The Mob Mentality Show and the Dev Ed Podcast. These two recordings have been my first ever experiences on a podcast and I have to say they were both lots of fun! As of right now, the two recordings are not live but expect posts in the upcoming weeks highlighting the recordings.

On The Mob Mentality Show, I got to talk about my recent presentation at the Pacific Northwest Software Quality Conference on Creating Quality with Mob Programming. I also got to talk about my other experiences as a mob programmer for the past 4 years.

For the Dev Ed Podcast, the topic was ASP.Net. I have a course coming out very soon on Thinkster.io teaching how to create a C# ASP.Net Core API so that is why the topic was ASP.Net. I got to speak to ASP.Net but also my experience as a university instructor.

When the two podcasts are live and out in the wild I will be sure to update the post with links! Also, I hope to be a part of many more podcasts in the future.

What are Structural Directives in Angular?

Structural Directives in Angular modify what is displayed in a view. They live directly in the HTML. They modify our HTML by adding, removing, or manipulating elements.

Why are they called structural directives? It is because they modify the structure of the Document Object Model (DOM).

Structural directives are easy to spot. They will begin with an asterisk (*). And the two most common structural directives are *ngIf and *ngFor.

Above is how we use a *ngIf. The if statement will evaluate on TheTomBomb and only if that is true will it include “Thomas is the best” into our DOM and viewable to the user.

If TheTomBomb evaluates to false “Thomas is the best” will not display. And not only that, but it will also not be present in the DOM.

The above *ngFor will print out a list of website url’s. The websites variable is a list of websites and we will loop of that and generate a new <li> for each one in our collection. So a new <li> element will be created in the DOM for each item in websites.

Structural directives are popular and give us added capabilities inside of our HTML. *ngIf is perfect for showing and hiding data. *ngFor is great when we need to generate repeated HTML.

To learn more check out the Angular documentation on Structural Directives.

What is Test-Driven Development (TDD)?

At my organization, we utilize test-driven development (TDD) to develop our software. To get a better understanding of TDD myself, I want to put together a post about what is test-driven development.

What Is a Test?

Before jumping straight into TDD let’s define what a test is. A test is something that verifies that our code works as we expect it to. Typically, this is a procedure or method that executes and asserts that a given valid response is received.

With a test, we verify that our code solves the problem it was intended to solve. That given a particular set of inputs and setup we get back the responses or see the changes that we would expect.

What is Test-Driven Development?

Test Driven Development

TDD can be defined as a programming practice that instructs developers to write new code only if an automated test has failed. Guru99

The above definition is from Guru99. Let’s break it down and I will put TDD into my own words.

The code we develop is driven forward by our test hence, Test-driven development. We write our test first before the implementation has been written. Making sure the test fails and for the right reason. Our test asserts proper functionality. Our test should satisfy the requirements of the software.

We then write the code that makes the test pass. This means our production code is already under test because we wrote the test first.

Red Green Refactor

Red Green Refactor is an important concept in TDD. Above I described how we wrote a failing test this is the red. Then we wrote the actual implementation code to make the test pass this is the green.

We have made it to the refactor step. Now that we have code written that is tested we can feel comfortable to refactor it. Maybe we see code duplication or any number of code smells.

With the tests backing us up, we can feel comfortable modifying the code running our tests and ensuring we are still green.

The simple definition of Test-Driven Development is that we write our tests first. The code is tested from the very beginning. We gain the confidence to refactor and improve our code.

Expect more posts on TDD as I expand my own knowledge of test-driven development!

PNSQC 2019 Talk Complete! Creating Quality with Mob Programming

PNSQC Culture Of Quality 2019 Logo

This week I had the pleasure of attending and speaking at the Pacific Northwest Software Quality Conference (PNSQC). This is my second time attending the conference and my first time presenting at this conference or any conference for that matter.

I wrote a technical paper and gave a presentation on Creating Quality with Mob Programming. Writing the paper was the most difficult part. I had not written a research paper in years. But it all came together and after writing the paper the presentation was easy. In addition, the presentation has boosted my confidence and makes me want to submit talks to more conferences.

Unfortunately, the archived links of the paper and presentation slides are not available yet, but I will update this as soon as they are.

The presentation was well-received. It sparked great conversations with people interested in learning more about Mob Programming. It helped to inspire a renewed passion for Mob Programming and reinforced that we must be doing something right.

Michael Larsen attended my presentation. He was generous enough to write a live blog post on his thoughts on Mob Programming. Check it out here! (https://www.mkltesthead.com/2019/10/creating-quality-with-mob-programming.html)

Without a doubt I want to attend and potentially speak at another PNSQC conference. The people, content, and downtown Portland location are great.

Thanks again PNSQC 2019!

« Older posts

© 2020 The Tom Bomb

Theme by Anders NorenUp ↑