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.

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!

Make it work, Make it right, Make it fast

I support the software development strategy of make it work, make it right, make it fast. This is a quote from Kent Beck, common in the software industry. I interpret this quote as, let us make sure our most basic solution solves the problem at hand before investing any more time than necessary.

Make it work

Not all solutions to a problem are pretty. This may mean little to no tests, poor performance, janky code, etc. Sometimes we just need a solution to a problem that shows that the problem can be solved. We want to make sure the problem is solvable albeit with a less than desirable solution.

An example where I implement a ‘make it work’ solution in code, is often in the area of user input or user navigation in my applications. Instead of relying on the user, I will hard-code the exact data I want. I want to encourage the happy path solution and test my application under only the best case scenario. This will tell me if under the most ideal conditions whether or not my solution even works. If my code does not work for this, the solution will have no hope in the edge cases and no reason to continue on with the work. I would then focus my ‘make it work’ code on implementing a different solution until I get it right.

Pushing code to production in the ‘make it work’ phase is a scary thought and something we should all strive to avoid. If you have a continuous integration (CI machine running all your tests pushing this ‘Make it work’ code is an option (preferably in a separate branch). However, it is important to see how it holds up to a full suite of tests.

Make it right

If we can show the problem can be solved with a ‘make it work’ solution we can move onto steps to make it right. This includes tests, proper syntax, good naming conventions, extensibility, and the like.

We want to remove any hard-coded data, we want to start thinking about the edge cases, and we definitely need to have tests around the code. For testing make sure to comment out code or remove code to see a failing test. Never trust a test during this stage unless you see it failing first for the right reason.

Our code should be bulletproof at the end of the ‘make it right’ stage. We should not feel any hesitations about presenting this code to a user from the standpoint of introducing a bug. A ‘make it right’ solution should be production ready.

Make it fast

Now for the hard part, ‘make it fast’. This is an area of software development that we often do not get the time and resources to experiment with. We just released a solution to production that works from the ‘make it right’ stage. It adds value to the users but we have ideas of making it even better. Often, the next bug or feature takes priority.

But let us assume we have the time. Let us assume we have the resources. We should always be thinking of ways to refactor our code and continuously improve the solutions we have.

Make it fast sounds like a performance or timing centric idea. People think “how can I get this code to run faster”. But it is more than that. We should be thinking how can I make it more testable, how can I make it more extensible, how can I make this code more valuable to the user. Performance is important but these other areas are just as important as well.

Having time for the ‘make it fast’ stage is a privilege and we should always try to take advantage of it. Improving existing code is just as important as writing new code.

In the end, we want to provide software solutions to our users that provide the most value. The make it work, make it right, make it fast idea of software development can help us get there. It allows us to choose the happy path of problem-solving before even considering the often much more difficult edge cases. Make it work, make it right, make it fast provides a solid foundation for building great code.

Make it work, make it fast, make it right -Kent Beck

For more on happy path coding, check out my previous post Programming Better and Easier With The Happy Path.

Microsoft Cognitive Services Emotion API First Impressions

I am always interested and looking for new libraries to put to use in Xamarin.Forms. I recently stumbled upon Microsoft Cognitive Services Emotion API and wanted to see what it was all about. After a quick look at some sample code, I knew I needed to sign up and try this library out for myself.

The sample code I had been looking at can be found here Xamarin.Forms Emotion API sample code. The sample has some other services built into it but what really interested me the most was the Emotion API.

According to comments in the code, which I am always skeptical of, the API can detect happiness, sadness, anger, fear, contempt, disgust, and neutral. It is amazing that it can determine these emotions and with great accuracy. What is even more amazing is that it basically is one line of code.

This one simple line gets the first (highest percentile) emotion recognized from a picture. Using the sample code you can easily take a beautiful selfie, send it with the single API call, and within seconds get an emotion back. I am not sure yet what factors cause it to take longer but sometimes I get results back in under a second.

From my dozen or so attempts at taking a picture of myself, it gave quite accurate results. I have yet to fake fear in a picture but will see if I can one to happen.  I am very impressed with the Emotion API’s ability to analyze and image and produce an emotion result. Looking forward to Microsoft adding even more emotions.

The free tier for using the API is quite impressive in terms of the number of calls available. I hope to be writing a post soon showing off an app I have made in Xamarin.Forms incorporating the emotion API.

Xamarin.Forms Microsoft Emotion Api

Programming Better and Easier With The Happy Path

When I start down a new solution or looking at how to solve a problem one of the first things to jump into my head are all the crazy edge cases that may or may not ever occur. I see it as a blessing in disguise because, in the long run, it helps out tons to be able to think about the crazy things a user may do. But when just trying to get a proof of concept together it can make the work that much more daunting.

When putting together a proof of concept stick with the happy path. Hard code values, expect perfect reproducible input, and for the proof of concept even lower the security levels a bit. Make sure if using lowered security settings you are in some sort of development environment. Do not go lowering your security on production.

But the key is to make it as easy on yourself as possible. What if you took the happy path and find out your solution did not even work anyway? You do not want to have wasted your time making your ability to accept input the most robust known the man if your strategy to submit the code is

A more real world time when the happy path saved me much time and effort was when the team and I at work were attempting to setup up a cloud solution using AWS. We had a couple different strategies in our minds as to how to build out our cloud solution. It involved security, databases, IoT, Lambda functions. It was going to be an extensive cloud system.

First thing we did was throw security out the door. We knew it needed to be done but would only complicate things. We did not set up a database because again takes time and we had a lot of database knowledge on our team so that did not pose too much of a risk. We just hard coded the data we would receive back when we did end up making the database.

Now we could take a look at the happy path for our proof of concept. Perfect user input, interaction, no confusing security. We found that our first model would not scale well so we threw it out the door. Our second model was not easily supported due to library limitations imposed on us. Our third solution found a happy medium of ability to scale, performance, and ease of implementation. This all did not happen overnight it actually took a few weeks. But imagine if we had added the extra complexity of security or the database. It would have taken months.

Taking the happy path saved us time and frustration. The process of making application development as easy for you as possible. Ignore the edge cases, ignore security, hard code values. Made us more productive and let us explore multiple solution strategies in a shorter amount of time.