We chase productivity without asking a deeper question: Are my actions actually moving me toward who I want to become? Being busy feels good. It's a quick hit of dopamine every time we check something off our to-do list – even if that list has nothing to do with our actual goals.

In my own pursuit of reaching my goals, I began developing a simple framework to help me align my daily actions with the person I wanted to be. This isn't a radically new concept here. It is more like a refined mental model that’s built from things you've probably heard and read before. But it’s designed to fit together in a clear, usable way.

The goal is to help bridge the gap between big-picture intentions and everyday behavior. I call it PATH.

It stands for:

• Purpose – your why

• Aspirations – the vision of who you want to become

• Targets – clear, measurable goals

• Habits – the consistent actions that support those goals

This is the framework I use to stay oriented. Not just to be productive, but to be intentional. I still get off track, but I find my way back a bit quicker.

In this article, you’ll learn how to apply the PATH framework to clarify your direction, set meaningful goals, and build habits that stick.

Table of Contents

1. Busy Doesn't Mean Effective

2. The Power of Frameworks

3. A Framework For Reaching Your Goals

4. Complexity and Difficulty Are Not Synonyms

5. Summary

Busy Doesn't Mean Effective

Being busy can feel like progress. Sometimes it is – you're moving toward your goals, checking boxes, staying active. But other times, it's just noise. A way to avoid sitting still. A way to avoid asking the harder question: Is this making a meaningful difference?

Sometimes, we chase productivity not because we're clear, but because, in fact, we're uncertain. And doing something – anything – feels better than acknowledging we might be lost.

On the other hand, you can have clear goals and develop effective habits. But if someone asked you why you picked those goals, would you have an answer? Why do you want to lose ten pounds? Why do you want to start that company? What are you really aiming for?

Here's a thought experiment: Imagine your funeral. You get to pick one person to give your eulogy – and they can only say one sentence about you. What do you hope they'll say?

This is a personal question. And I know my answer very clearly. Do you know yours?

The Power of Frameworks

You do not rise to the level of your goals. You fall to the level of your systems.

— James Clear

In programming, a framework is predefined code that helps developers build software more efficiently and effectively. It abstracts away the implementation details of common problems – things you could handle yourself, but probably don't need to. The tradeoff? You give up some flexibility in exchange for speed. In other words, frameworks help you solve your problem faster by deciding a few things for you.

Developers lean on frameworks like React or .NET because they help us focus on solving meaningful problems, rather than wrestling with boilerplate code. PATH works the same way: it abstracts the structure so you can spend more time executing on what matters.

When it comes to setting goals, it's no different. It's easy to get lost in these implementation details and end up overcomplicating the process. We want the perfect strategy or the ideal plan. But in reality, progress almost always beats perfection. Initially, we don't need the most elegant system – we need one that we can follow.

That's where frameworks shine. They reduce friction and help you stop tinkering with the how and start taking action on the what. They free up mental energy, allowing you to focus on actually solving the problem.

This isn't new. Every great tool – whether it's a budgeting app, a productivity system, or a JavaScript library – obscures just enough complexity to help you move towards a solution faster.

A Framework For Reaching Your Goals

PATH is a framework I've used for years to align my actions with my desired future self. Most goal-setting systems start with habits or outcomes, but PATH begins a bit further back: your purpose.

P is for Purpose

Purpose is the core of who you are and what matters most. It is your mission statement, no more than a sentence or two. It should be you. A strong purpose will help you get back on track when you veer off course.

A is for Aspirations

Once you've decided on your purpose, the next step is to dream a little. This is the fun part.

Where do you want to be in the next 5 to 10 years? Try to picture a typical day of your ideal future – not necessarily what you own, but what you experience and do.

• Where do you live?

• What time do you wake up?

• What do you do during the day?

• Who are you with?

Here is an example:

I live by a beautiful lake in the mountains. I get up around 7 am, go for a long run, and then eat a healthy breakfast. I spend my day writing. Evenings are slow, spent laughing on the porch with friends and family.

Now, let's break that down into aspirations – broad themes that define the kind of life you're building. From that vision, here are three I see:

• Be in good shape

• Be a writer

• Spend quality time with friends and family

These are your aspirations – the "A" in PATH. And they're not meant to be specific or time-bound. Think of them as a compass, not a destination. Their job is to give you something to aim at over and over again.

T is for Targets

Targets are the specific goals we aim to achieve.

Each aspiration should have one or more targets – clear, time-bound goals that move you in the direction of your aspiration.

These targets should follow the SMART framework:

• Specific

• Measurable

• Attainable

• Realistic

• Time-bound

For example, if you aspire to become a software developer, a target might be:

Contribute one fix or update to an open-source project by the end of the month.

If aspirations are our compass, targets are the destination. They let you measure progress and know when you've arrived.

H is for Habits

Habits are where the rubber meets the road.

Every target should have one or more supporting habits – things you do consistently that move you towards your goal. While they will generally be daily or weekly routines, one-off tasks are also acceptable. The idea is these are things that move the needle.

For example, if your target is to run a 5k event, a habit might be:

Run 3 miles every other day.

Or, if you're just starting, you may want to create a one-off task such as:

Map out a running route.

Again, these habits (or tasks) are needle-movers. Following them – actually following them – should almost guarantee that you reach your targets.

When it comes to building a habit, the key is to start small, sometimes really small. In the beginning, the goal isn’t performance, it’s momentum. And while momentum can be hard to start, once it’s moving, it’s even harder to stop.

If you’re trying to build a writing habit, begin with two sentences. If you want to exercise more, start by putting on your workout clothes. Or just drive to the gym. The point is to make starting frictionless.

Consistency also depends on cues. Every habit needs a reliable trigger – something that prompts you to take action. It might be a specific time of day, walking in the door after work, or finishing your morning coffee. Over time, that cue becomes automatic, and so does the habit.

Complexity and Difficulty Are Not Synonyms

There's a moment in the boxing film Bleed for This where the main character is asked, "What's the biggest lie you've ever been told?" He answers:

"It's not that simple."

The interviewer tries to clarify – as if she believes the main character doesn't understand the question – but he cuts her off and essentially says:

"No, that's the lie. It is that simple."

That line stuck with me, because we often treat life like it requires a perfect plan before we can begin. However, sometimes the hardest part is simply deciding.

Don't confuse something hard with something that's complex. In my experience, the most meaningful things in life are often simple yet challenging.

Knowing what to do isn't the challenge. It's doing it – over and over again, especially when it's boring, inconvenient, or the outcome is uncertain. That's why clarity matters, and frameworks can help.

There's the person who spends their entire life looking for an elevator. And then there's the person who starts climbing the stairs.

Figure out who you want to be, and filter your goals and actions through that lens.

I'd bet almost anyone reading this could name a few things that would take less than an hour a day that would completely change their life over time. The difference – the only difference – is that the person who gets clear on what they want and then actually does those things every day...gets there.

At the end of the day, the goal isn't to be productive. It's to be intentional. To align your daily actions with your goals and ensure those goals are pushing you toward the person you want to become. That's the idea behind PATH – a framework for being intentional.

Summary

If you remember nothing else, here’s the heart of PATH:

• Purpose – Define your why. A short, personal mission statement that keeps you grounded.

• Aspirations – Paint a picture of who you want to become. Think 5–10 years out, focused on experience, not possessions.

• Targets – Turn aspirations into SMART goals with clear deadlines. These give your vision structure.

• Habits – Identify consistent, meaningful actions that drive progress toward your targets – daily, weekly, or even one-off tasks.

I’ve created a free Notion template to help you get started with the PATH framework.
→ PATH Goal Tracker Essentials

There’s also an upgraded version available for those who want habit tracking, progress calculations, and more.
→ PATH Goal Tracker Plus

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

Whether you are onboarding 50 new hires or rolling out access to a new app, managing roles by hand can be tedious and error-prone.

In this article, you will learn about three scalable ways to assign security roles across multiple users or teams, with low-code and pro-code options.

Table of Contents

1. Aside: Teams

2. Canvas Apps Relate / Unrelate Functions

3. Power Automate with the Relate Rows in Dataverse Action

4. C# Console App: Using the Dataverse SDK

5. Final Thoughts

Aside: Teams

Teams are the simplest way to assign roles to multiple users.

Dataverse admins and team owners can add users to one or more teams. Rather than assigning roles to individual users, the security role is assigned to the team.

But there are caveats: record ownership and team management can introduce their own complexity. In environments with many teams, updating security roles can become just as tedious as assigning them individually.

This article focuses on programmatic individual assignments, but keep in mind that all three methods described below can be adapted to work with teams as well.

Canvas Apps Relate / Unrelate Functions

Canvas app developers can use Power FX to assign security roles across users or teams. Minimal code is required, and the result can serve as a lightweight security role management portal.

While not ideal for massive batches, this approach is suitable for assigning roles to a few hundred users.

ForAll(
    colSelectedUsers As User,
    Relate(
        User.'Security Roles (systemuserroles_association)',
        cbx_securityRoles.Selected
    )
)

Here:

• colSelectedUsers is a collection of users.

• cbx_securityRoles is a Combobox control holding the security role to assign.

The Relate function connects each user with the selected security role. The first parameter is the many-to-many relationship (systemuserroles_association) between systemuser and role.

To find relationship names, open the User table > Relationships. Then, look for many-to-many connections to the role table.

The security role/user relationship is a many-to-many relationship.

Power Automate with the Relate Rows in Dataverse Action

The Relate Rows in Dataverse action allows you to assign roles dynamically in cloud flows.

How it works:

• Trigger a flow (for example, manually or via Dataverse trigger).

• Fetch a list of users based on a condition.

• Loop through each user with Apply to Each.

• Assign a static or dynamic security role.

C# Console App: Using the Dataverse SDK

This method offers maximum control and supports complex, high-scale role assignments – but it requires pro-code skills.

Example:

This console app:

1. Connects to the environment via client credentials.

2. Retrieves all users with the title "Salesperson"

3. Builds a batch of associate requests.

4. Executes the batch transactionally – if one fails, all fail.

using Microsoft.PowerPlatform.Dataverse.Client;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Messages;
using Microsoft.Xrm.Sdk.Query;

class Program
{
    static void Main(string[] args)
    {
        string dataverseUrl = "https://your-org.crm.dynamics.com";
        string clientId     = "client-id-here";
        string clientSecret = "client-secret-here";
        string tenantId     = "tenant-id-here";

        string connectionString = $@"
            AuthType=ClientSecret;
            Url={dataverseUrl};
            ClientId={clientId};
            ClientSecret={clientSecret};
            TenantId={tenantId};
        ";
        // Connect to our environment
        using var serviceClient = new ServiceClient(connectionString);

        if (!serviceClient.IsReady)
        {
            Console.WriteLine("Failed to connect.");
            return;
        }

        // Fetch a list of users that we intend to associate a role with
        var query = new QueryExpression("systemuser")
        {
            ColumnSet = new ColumnSet("systemuserid"),
            Criteria = new FilterExpression
            {
                Conditions =
                {
                     new ConditionExpression(
                        "title",
                        ConditionOperator.Equal,
                        "Salesperson"
                     ),
                }
            }
        };

        var users = serviceClient.RetrieveMultiple(query);

        // Role to assign (pretend guid for demo purposes)
        var securityRoleId = new Guid(
            "00000000-0000-0000-0000-000000000ABC"
        );

        // Prepare our transaction
        var transaction = new ExecuteTransactionRequest
        {
            ReturnResponses = true,
            Requests = new OrganizationRequestCollection()
        };

        // For each user we fetched above, we add an associate request 
        // to the transaction
        foreach (var user in users.Entities)
        {
            var userId = (Guid)user["systemuserid"];

            var relationship = new Relationship(
                "systemuserroles_association"
            );

            var relatedReferences = new EntityReferenceCollection
            {
                new EntityReference(
                    "role",
                    securityRoleId
                )
            };
            // build the associate request
            var request = new AssociateRequest
            {
                Target = new EntityReference(
                    "systemuser",
                    userId
                ),
                RelatedEntities = relatedReferences,
                Relationship = relationship
            };
            // add the request to the transaction
            transaction.Requests.Add(request);
        }

        // Finally, execute the batch as a transaction
        serviceClient.Execute(transaction);
    }
}

You can even utilize this logic within a Custom API, allowing Power Automate or Canvas Apps to call it, blending low-code and pro-code capabilities.

Final Thoughts

If your teams are already well-structured and manageable in number, teams remain the easiest way to assign roles at scale.

But when teams aren't feasible – or when assigning directly to users is required – each method we discussed here offers a viable alternative:

• Use Canvas Apps for lightweight, user-facing management portals

• Use Power Automate when complexity is low and there is a need to trigger it in a variety of ways.

• Use C# and the Dataverse SDK for full control and batch efficiency.

Ready to automate your role assignments? Start small – build a simple Power App or Flow – and scale your approach from there.

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

It might be easier to understand if we compare it to financial debt.

Howard G. Cunningham – the creator of the first wiki – described technical debt this way:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable.

The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

In this article, you'll learn why technical debt is just as much a concern in low-code projects as in traditional development – and why, in some ways, it can be even more prominent. We'll walk through eight common contributors to technical debt in Power Platform projects that, if left unchecked, can lead to future headaches.

Table of Contents

1. Why Technical Debt Is Also a Low-Code Problem

2. Eight Examples of Technical Debt in a Low-Code Project

   • Hard-Coded or Static Values in Your Code

   • Duplicated Code

   • Poor Naming of Controls and Variables

   • Overloaded Screens and Applications

   • No Version Notes

   • Invisible Logic

   • Denormalized Data Models

   • Leading with Layout Before Logic

3. Wrapping Up

Why Technical Debt Is Also a Low-Code Problem

Technical debt builds when short-term decisions ignore long-term consequences. While it exists in any development, low-code platforms increase the risk for a simple reason: they remove much of the traditional friction that forces teams to slow down.

With fewer barriers to entry, it's easier for citizen developers – and even professional developers new to the platform – to start building without considering maintainability, scalability, and security.

Low-code platforms enable speed – but if you aren't intentional, the speed can create an environment that fosters the growth of technical debt.

Eight Examples of Technical Debt in a Low-Code Project

Hard-Coded or Static Values in Your Code

We've all seen code like this:

Office365Outlook.SendEmailV2(
  gblAuthenticatedUser.Email, 
  "Sign-Up Request Received!", 
  "A team member will reach out shortly with more information."
)

At first glance, this appears to be fine. But what happens if the subject or body of the email needs to change?

Hard-coded values are fragile. A better approach is to store your email templates in a data source, even if it only contains one record.

With({
  wthEmailTemplate: LookUp(EmailTemplates, TemplateType="new_signup")},
  Office365Outlook.SendEmailV2(
    gblAuthenticatedUser, 
    wthEmailTemplate.Subject, 
    wthEmailTemplate.Message
  )
)

Now, if the email needs to be changed, you update the data source, not the application logic.

Duplicated Code

While it can be trickier to avoid than in traditional code, duplicate logic is a future maintenance headache.

Imagine two different ways to create comments in an application:

//Main dialog in a stream of comments
With(
    {
        wthNewlyCreatedComment: Patch(
            Comments,
            Defaults(Comments),
            {Comment: txt_hs_comment.Value}
        )
    },
    Collect(
        colComments,
        wthNewlyCreatedComment
    );
    Set(
        gblCommentCount,
        CountRows(colComments)
    )
)

//A different dialog when replying to another's comment
With(
    {
        wthNewlyCreatedComment: Patch(
            Comments,
            Defaults(Comments),
            {Comment: txt_hs_dialogComment.Value}
        )
    },
    Collect(
        colComments,
        wthNewlyCreatedComment
    );
    Set(
        gblCommentCount,
        CountRows(colComments)
    )
)

These two blocks do the same thing. If the logic ever changes, you must remember to update it in both places.

A cleaner approach is to use a user-defined function (UDF) to encapsulate logic that gets reused across your app.

// App.Formulas
UpdateComments(comment: Text):Void = 
{
	With(
        {
            wthNewlyCreatedComment: Patch(
                Comments,
                Defaults(Comments),
                {Comment: comment}
            )
        },
        Collect(
            colComments,
            wthNewlyCreatedComment
        );
        Set(
            gblCommentCount,
            CountRows(colComments)
        )
    )
};

And then in each of the locations that need this formula:

//Main dialog in a stream of comments
UpdateComments(txt_hs_comment.Value)

//A different dialog when replying to another's comment
UpdateComments(txt_hs_dialogComment.Value)

As of this writing, user-defined functions in Canvas apps support side effects (such as modifying collections or setting variables), but the overall feature is still in preview.

If UDFs aren't an option for your current use case, a common workaround is to use a hidden button that encapsulates the logic and call it with Select(ButtonName). Just keep in mind: the control must be on the same screen where it's being invoked.

Poor Naming of Controls and Variables

Home Screen
  ButtonCanvas4
  TextCanvas2
  ButtonCanvas1

What's wrong with the scenario above? It is impossible to know what each control is responsible for.

Good naming isn't just a nice-to-have – it's one of the best ways to reduce confusion and improve maintainability, especially in collaborative environments.

Here is an improved version that allows any developer to understand what these controls do:

Home Screen
  txt_hs_userName
  btn_hs_submitForm
  btn_hs_cancelSubmission

In this example, we follow the pattern of:

[control_type]_[screen]_[control responsibility]

This helps make it easy to search for items quickly as well as identify what they do.

Another aspect that naturally lends itself to naming conventions is the use of variables. Canvas apps have various methods for storing data locally. They include:

1. Collections (ClearCollect/Collect)

2. Global Variables (Set)

3. Local Variables (UpdateContext)

4. Contextual Variables (With functions)

Each type of variable has a different scoping associated with it. Collections are tables and available throughout your entire application. Global variables are also available throughout the entire application. Variables set using UpdateContext are scoped to the screen on which they are declared. And variables contained within a With function are available only within that function.

It is a good idea to ensure that the variable name accurately reflects the type of variable it represents. For example:

// prefixed with "wth" for a with-function scoped variable
With({wthNewlyCreatedUser: Patch(AppUsers,...)},...)

// prefixed with "ctx" for a screen-scoped contextual variable
UpdateContext({ctxCurrentPostVotes: LookUp(colPostVotes, ....)})

// prefixed with "gbl" for global
Set(gblAuthenticatedUser, LookUp(AppUsers,....))

// prefixed with "col" for a collection
ClearCollect(colUserRoles, LookUp(AppRoles, ...))

Each data storage type is designated by a prefix that indicates its kind, which makes debugging an application easier.

Overloaded Screens and Applications

It can be tempting to keep everything on one screen for simple applications. But canvas apps can quickly become non-performant if too many controls or too much logic is on a single screen. The recommended limit is no more than 500 controls per app and 300 controls per screen. Using and editing the application can slow down significantly if these limits are exceeded.

One way to prevent this issue is to think more modularly. For example, you may have both administrative and non-administrative tasks within a single application. Instead, you can make two applications, one for admin users and the other for general users.

Another way to avoid these issues in the same application is to build using components. The controls that make up a component don't count individually towards the screen limits and are also a natural way to reduce duplication within and across your applications. Components can be created within an application or as a component library (if your component needs to be used in multiple applications – for example, loaders/spinners and confirmation dialogs).

For more information on components, refer to this article I wrote about building reusable components.

No Version Notes

As the Power Platform ecosystem grows, advanced versioning techniques are being introduced, including the integration of solutions with Git. But even if you don't have that git integration, there is something simple you can do.

When you save an application after any non-trivial change, use the built-in version notes.

This simple habit will make two things much easier:

1. If you ever need to roll back changes, it becomes much easier to identify the correct version to roll back to.

2. When using multiple environments (for example, Dev, Test, and Prod), this can help you identify which version is currently in each environment, as the built-in version numbers may not necessarily match.

To view version notes for a canvas app, select 'View Details' for the app and then select the versions tab.

Invisible Logic

Invisible logic is logic that supports a product, but it is not immediately recognizable. For example, custom APIs and cloud flows can quickly become forgotten if there is no documentation reminding developers that these critical components exist – and what they actually do.

One of the best ways to document a project is by using solutions. Solutions will typically include the majority of a project's assets – often more than 90% – but there are notable exceptions, such as SharePoint lists, Power BI reports, and certain external integrations.

Some things a solution often won't or can't include are assets that belong to core or base solutions – for example, generic cloud flows that serve multiple projects or products. Depending on your solution strategy, you may not want to add these to each solution, and they will only exist in a core or base solution.

Other things that fall under the umbrella of invisible logic include Power BI assets and Dataflows, along with their respective automation architectures (for example, how and when a Dataflow gets triggered).

As a best practice, utilize the self-documenting nature of solutions to provide references to all assets, logic, and dependencies that a project uses. Also, consider adopting a feature-based documentation practice, where each feature or user story implemented includes basic documentation, including high-level implementation details and any underlying logic. This could be a wiki-like document that allows developers, who may be troubleshooting or extending a feature, a simple way to get oriented before diving into an unfamiliar project.

Denormalized Data Models

Data normalization is a topic of its own, but you don't need to be an expert to get started building robust and scalable data models. In simple terms, data normalization involves grouping similar data elements and eliminating duplication.

Take a look at the following example of the employee table.

Employees Table (Denormalized)

| Employee ID | Name   | Department Name | Department Location |
|-------------|--------|------------------|----------------------|
| 1           | Alice  | HR               | Building A           |
| 2           | Bob    | IT               | Building B           |
| 3           | Carol  | HR               | Building A           |
| 4           | Dan    | IT               | Building B           |
| 5           | Eve    | Finance          | Building C           |

In the above table, we can see the EMPLOYEE table records contain information about the department. Conceptually, this is fine, but the main issue is that the attributes of each record not only describe the employee but also provide details about the department.

This type of data is referred to as denormalized data. Denormalized data makes the data model harder to scale and maintain. For example, if the Department Name changes, we must locate every record with that department name and update it accordingly.

Instead, let's examine a more normalized data model that consists of two tables now.

Employees Table (Normalized)

| Employee ID | Name   | Department ID |
|-------------|--------|----------------|
| 1           | Alice  | 1              |
| 2           | Bob    | 2              |
| 3           | Carol  | 1              |
| 4           | Dan    | 2              |
| 5           | Eve    | 3              |


Departments Table

| Department ID | Department Name | Department Location |
|---------------|------------------|----------------------|
| 1             | HR               | Building A           |
| 2             | IT               | Building B           |
| 3             | Finance          | Building C           |

This data model eliminates duplication and simplifies attribute updates for the department, requiring only a single record update to be made. And because each attribute of the EMPLOYEES and DEPARTMENTS tables only describes the primary key of the respective table, this is a normalized data model.

One common misconception among new developers is that more tables are a bad thing. Many believe that fewer data sources are easier to maintain, but that’s not always true.

In development, what makes things easier to maintain isn't less of something, but rather how atomic, modular, and dependent-free it is. For example, a few small, pure functions that do just one thing will be easier to maintain than a single side-effect-producing function that does many things.

Don't shy away from normalized data just because it creates more tables. Shy away from data models that won't scale.

One final note: Denormalized data has its place, too, and it's not a bad thing. For example, reporting data is often denormalized and is much more preferred as it makes reporting logic much easier.

Leading with Layout Before Logic

Low code makes it easy to jump in and start building, which is a significant benefit. But this model can also make it very easy to skip important aspects of development, such as requirement gathering, user interface design, and data modeling.

It's perfectly fine to prototype ideas. This is great for quickly determining if something may or may not be feasible. But you must have the discipline to stop before getting too far along, and take time to plan properly.

For example, consider employing a business logic-first approach. This means that the requirements and core business logic are decided on (and often implemented) before you even start building the user interface.

The core principle of this type of development is that, regardless of the interface a user chooses to interact with our data – and remember, a web application is nothing more than an interface to your data – the core business logic should function properly. In this light, a Canvas app becomes just an aesthetic wrapper that complements what is hopefully well-designed business logic.

Wrapping Up

Technical debt exists in both traditional and low-code development. Recognizing this debt early, before it begins to accumulate, is critical. Some tips that can reduce and keep technical debt at manageable levels are:

1. Avoid hard-coded or static data in your app logic

2. Eliminate duplicated logic with user-defined functions (UDFs)

3. Use consistent naming conventions for controls and variables

4. Break overloaded apps into multiple screens or multiple apps

5. Add version notes to track meaningful changes

6. Document invisible logic such as flows and APIs

7. Normalize your data to reduce duplication

8. Start with business logic—not layout or visuals

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

Without much thought, I wrote something similar to:

const sorted = data.sort((a, b) => {
  return new Date(a.date) - new Date(b.date);
})

This worked fine on small datasets. But the array I was sorting had nearly 30,000 objects. On a fast development machine, the performance hit was around 100–150ms – already noticeable when combined with other UI work. When I tested with 4× CPU throttling in the browser, the delay increased to nearly 400ms, which more accurately simulates a lower-end device. That's a reasonable approach to ensure your app still performs well for users on slower machines.

Results in browser:

sort_with_date_conversion: 397.955078125 ms

Output with performance throttled by 4x slowdown

In this article, you will learn how to sort dates efficiently in JavaScript. We'll walk through what makes the method above inefficient, as well as a better pattern–especially when dealing with large amounts of data.

Table of Contents

1. Why 400ms Feels Slow

2. Setting Up Our Experiment

3. The Cost of Date Conversion

4. The Lexicographical Superpower of ISO 8601

5. What If Your Dates Aren't ISO Format?

6. Key Takeaways

Why 400ms Feels Slow

According to Jakob Nielsen's classic "Usability Engineering" (1993), delays under 100 milliseconds are perceived as instantaneous. Between 100ms and 1,000ms, users start to notice lag – even if it doesn't require UI feedback. In my case, 400ms felt choppy, especially since the PCF component was already handling other tasks. It wasn't going to cut it.

Setting Up Our Experiment

Let's simulate this with a simple experiment that stress tests our sorting. We'll create an array of 100,000 ISO-formatted dates, and we will simulate a 4x performance slowdown in the browser for all scenarios:

// Create an array of 100,000 ISO-format dates
const isoArray = [];
let currentDate = new Date(2023, 9, 1); // October 1, 2023

for (let i = 0; i < 100000; i++) {
  const year = currentDate.getFullYear();
  const month = String(currentDate.getMonth() + 1).padStart(2, '0');
  const day = String(currentDate.getDate()).padStart(2, '0');

  isoArray.push({ date: `\({year}-\){month}-${day}`, value: i });
  currentDate.setDate(currentDate.getDate() + 1); // advance by one day
}

// Shuffle the array to simulate unsorted input
function shuffle(array) {
  for (let i = array.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [array[i], array[j]] = [array[j], array[i]];
  }
}

shuffle(isoArray);

The Cost of Date Conversion

Now, let's sort using the new Date() method, where each new date is instantiated directly inside the sort method.

console.time('sort_with_date_conversion');

// Sorting by converting each string to a Date object on every comparison
const sortedByDate = isoArray.sort((a, b) => {
  return new Date(a.date) - new Date(b.date);
});

console.timeEnd('sort_with_date_conversion');

Result in browser:

sort_with_date_conversion: 1629.466796875 ms

Sorting 100,000 dates took almost 2 seconds.

Almost 2 seconds. Ouch.

The Lexicographical Superpower of ISO 8601

Here’s the critical realization: ISO 8601 date strings are already lexicographically sortable. That means we can skip the Date object entirely:

console.time('sort_by_iso_string');

// Compare strings directly — thanks to ISO 8601 format
const sorted = isoArray.sort((a, b) => 
  a.date > b.date ? 1 : -1
);

console.timeEnd('sort_by_iso_string');
console.log(sorted.slice(0, 10));

Output in the console:

sort_by_iso_string: 10.549072265625 ms
[
  { date: '2023-10-01', value: 0 },
  { date: '2023-10-02', value: 1 },
  { date: '2023-10-03', value: 2 },
  { date: '2023-10-04', value: 3 },
  { date: '2023-10-05', value: 4 },
  { date: '2023-10-06', value: 5 },
  { date: '2023-10-07', value: 6 },
  { date: '2023-10-08', value: 7 },
  { date: '2023-10-09', value: 8 },
  { date: '2023-10-10', value: 9 }
]

From 1600ms down to ~10ms. That's a 160x speedup.

Why is this faster? Because using new Date() inside .sort() results in creating two new Date objects per comparison. With 100,000 items and how sort works internally, that's millions of object instantiations. On the other hand, when we sort lexicographically, we are simply sorting strings, which is far less expensive.

What If Your Dates Aren't ISO Format?

Let's say your dates are in MM/DD/YYYY format. Those strings aren't lexicographically sortable, so you'll need to transform them first.

Transform then Sort

console.time('sort_with_iso_conversion_first');

const sortedByISO = mdyArray
  .map((item) => { // First convert to ISO format
    const [month, day, year] = item.date.split('/');
    return { date: `\({year}-\){month}-${day}`, value: item.value };
  })
  .sort((a, b) => (a.date > b.date ? 1 : -1)); // then sort

console.timeEnd('sort_with_iso_conversion_first');

Output:

sort_with_iso_conversion_first: 58.8779296875 ms

Still perceived as instantaneous.

Retaining Original Objects

If you want to keep your original objects (with non-ISO dates), you can use tuples:

console.time('sort_and_preserve_original');

// Create tuples: [sortableDate, originalObject]
const sortedWithOriginal = mdyArray
  .map((item) => {
    const [month, day, year] = item.date.split('/');
    return [`\({year}-\){month}-${day}`, item]; // return the tuple items
  })
  .sort((a, b) => a[0] > b[0] ? 1 : -1) // sort based on the first item
  .map(([, item]) => item); // Return the original object

console.timeEnd('sort_and_preserve_original');

Output:

sort_and_preserve_original: 73.733154296875 ms

Still within the boundaries of being perceived as instantaneous.

The original data is preserved and the performance falls well within what is perceived as instantaneous.

Key Takeaways

• Avoid object creation inside .sort(), especially for large arrays.

• ISO 8601 strings are lexicographically sortable. Use string comparison when you can.

• If your date strings aren't sortable, map them to a sortable form first, sort, and optionally map them back.

• Minor tweaks in sorting can yield massive performance gains – especially in UI components or real-time visualizations.

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

When creating a new PCF project, you can choose from two types of controls: standard controls and React virtual controls. For non-trivial components, React is often a good choice because it abstracts away much of the heavy DOM manipulation. But, when you’re using React with PCF, you’re currently limited to React 16 in Canvas apps and React 17 in Model-Driven apps.

That doesn’t mean you can’t use a newer version – but doing so means opting out of virtualization support. For many PCF components, that trade-off is usually acceptable.

In this article, I’ll show you how to integrate the latest version of React (v19) with your PCF component. We’ll install the necessary dependencies and configure the component to take full advantage of the latest version of React.

This article assumes that you:

• Understand how to use the PAC CLI to create PCF projects.

• Are comfortable using the command line and a code editor (for example, VS Code)

• Know the basics of React

• Have some experience with PCF development

Note: You don’t need access to a Power Platform environment unless you want to deploy the component. The built-in test harness will be sufficient to follow along with this article.

In this tutorial, you will:

• Create a PCF Project

• Install the React Dependencies

• Create a Non-React Button

• Create a React Button

• Add the React Button to the PCF Component

• Render the React Button When the PCF Component Updates

Create a PCF Project

To create a PCF project, you’ll use the PAC CLI. If you haven’t installed it yet, follow the instructions here.

From the directory of your choice, create a new folder for this project, and then open your terminal and run:

pac pcf init -ns SampleNameSpace -n SampleComponent --template field

Once it finishes, run:

npm install

This installs the default project dependencies.

So why didn’t we use the --framework flag to specify React during project creation? Because that flag sets up a React virtual control, which only supports React 16/17. Instead, we’re creating a standard control and installing React ourselves.

Install the React Dependencies

To use React 19, you’ll need four dependencies:

• react

• react-dom

• @types/react

• @types/react-dom

These last two provide TypeScript typings for React. Install the above dependencies with:

npm install -D react react-dom @types/react @types/react-dom

You can verify the installation by looking at the package.json file in the project.

While not necessary for what we will be doing, in order to use some newer React features, you may need to tweak the compilerOptions in the tsconfig.json file to include the line below:

"jsx": "react-jsx"

Here is what the tsconfig.json file should look like with the added jsx line:

Create a Non-React Button

Let’s verify that everything works before we introduce React.

From the command line, run:

npm run start:watch

This may take a moment. It will open a browser showing your PCF test harness. You’ll likely see an empty screen. That’s expected – we haven’t rendered anything yet.

Open index.ts in the SampleComponent folder. This file contains a class that implements the PCF standard control interface. Let’s create a basic non-React button.

Update the init method in the index.ts file like this:

public init(
    context: ComponentFramework.Context<IInputs>,
    notifyOutputChanged: () => void,
    state: ComponentFramework.Dictionary,
    container: HTMLDivElement
): void {
    // A basic button with vanilla JS and the DOM
    const btn = document.createElement('button');
    btn.textContent = 'Click me!';
    container.appendChild(btn);

    // A simple event lister for button clicks
    btn.addEventListener('click', () => {
        alert('Button clicked!');
    });
}

Now, head back to your test harness. You should see a button. Clicking it should display an alert.

Create a React Button

Next, let’s replace our plain DOM code with React.

Delete the button code from init(), leaving the init method empty.

Then, create a new file: Button.tsx. Inside Button.tsx, add the code below. This component will accept a label prop and emit an onClick event. Make sure to export the function.

export default function Button(props: { label: string; onClick: () => void }) {
    return <button onClick={props.onClick}>{props.label}</button>;
}

Add the React Button to the PCF Component

In index.ts, update the file to:

1. Import createRoot from react-dom/client

2. Import the Button component

3. Render the Button component

Here is the minimal example:

import { createRoot } from 'react-dom/client'; // import the createRoot method
import Button from './Button'; //import the button.tsx component we just created

export class SampleComponent
    implements ComponentFramework.StandardControl<IInputs, IOutputs>
{
    constructor() {
        // Empty
    }
    public init(
        context: ComponentFramework.Context<IInputs>,
        notifyOutputChanged: () => void,
        state: ComponentFramework.Dictionary,
        container: HTMLDivElement
    ): void {
        // Add the code below to create a React root that allows us to render our button component.
        const root = createRoot(container);
        root.render(
            Button({ label: 'React Button', onClick: () => alert('React Button Clicked!') })
        );
    }
    // Other methods here...
}

You should now see “React Button” in the browser. Clicking it will trigger the alert.

Render the React Button When the PCF Component Updates

Many PCF components receive dynamic input values. If the inputs change, we want the React component to re-render. This is where updateView() comes in. updateView() is triggered when the PCF property bag changes.

Let’s move the rendering logic from init() to updateView().

First, import Root from react-dom/client, and initialize root as a property of the class.

import { createRoot, Root } from 'react-dom/client'; //add Root as an import

export class SampleComponent implements ComponentFramework.StandardControl<IInputs, IOutputs> {
    root: Root; // initialize the root property on the SampleComponent class
    constructor() {
        // Empty
    }
    // other methods here...
}

Then, modify init() to set this.root to the root created by React’s createRoot method. Move the rendering logic from the init method to updateView(), replacing root with this.root.

public init(
    context: ComponentFramework.Context<IInputs>,
    notifyOutputChanged: () => void,
    state: ComponentFramework.Dictionary,
    container: HTMLDivElement
    ): void {
        this.root = createRoot(container); // assign the root React creates to this.root
    }

public updateView(context: ComponentFramework.Context<IInputs>): void {
    // render the React button component, by referencing this.root
    this.root.render(
        Button({ label: 'React Button', onClick: () => alert('Button Clicked!') })
    );
}

With the above setup, React will now re-render your button when the property bag of a PCF component changes.

Wrapping Up

You’ve now created a PCF component that uses the latest version of React! By installing and configuring React manually, you avoid the version limitations of Microsoft’s built-in React controls – unlocking the power of modern React features.

While this setup doesn’t support virtualization, for many components that’s a fair trade-off for modern tooling and maintainability.

If you’re building PCF components beyond simple DOM manipulation, React can be a powerful way to improve your development workflow and UI flexibility.

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

One of the most fundamental tasks when building an application is breaking it down into its core parts, or components. Websites are constructed from smaller building blocks. Just how small? Well, that’s up to you, the developer.

In the example below, we can spot some obvious elements: a header, a search box, perhaps a sidebar for navigation, and a main content area. Applications emerge from many smaller parts coming together.

Components allow us to isolate responsibility and manage complexity for specific parts of an application. In both traditional and low-code development, they play a vital role in creating maintainable, reusable, and testable products.

In this article, you’ll learn what a component is. Then we’ll build a custom text field component inside a Canvas app.

Prerequisites

This tutorial assumes a basic understanding of Microsoft Power Apps. While not required to understand the article, to actively follow along, you’ll need access to a Power Platform environment with the App Maker security role.

Table of Contents

• The Concept of a Component

• How to Build Your Own Component

• Wrapping Up

The Concept of a Component

The idea of components isn’t new – and it’s not exclusive to software.

Let’s think about a car for a moment. A car is made up of many smaller parts: wheels, an engine, seats, a steering wheel, and so on. But it’s the concept of the car – and specifically its ability to transport us – that provides value. That concept emerges from the way the individual parts work together.

Now imagine you get a flat tire. Not a good day. But thanks to how cars are designed, you don’t need a whole new car – maybe not even a new tire. You fix the issue and you’re back on the road within a few hours. Breaking things into smaller parts helps make the whole system more resilient. Applying this same principle to application development is a smart, future-proof approach.

Two Broad Types of Components

Within an application, components can vary in complexity and responsibility. Some are simple, like a text label. Others are more complex, like a pop-up dialog. Regardless of their complexity (again, your design choice), components typically fall into one of two categories:

• Presentational ("Dumb") Components

• Container ("Smart") Components

The difference comes down to purpose. A container component may interact with external sources and usually mutates state. A presentational component, on the other hand, is generally only responsible for how things look and light communication with the application.

Container components are often more complex and harder to test. Presentational components are typically simpler and more predictable.

This isn’t to say you should avoid container components. That’s not realistic. At some point, your app will need to talk to the outside world.

Aside: Pure Functions

The concept of pure functions is useful here.

A function is considered pure if it always returns the same output for the same input and doesn’t interact with any external state.

// Example 1 (pure)
function add(x, y) {
  return x + y;
}

console.log(add(2, 3)); // Always 5

// Example 2 (not pure)
function subtract(x) {
  const y = Math.floor(Math.random() * 100) + 1; // Random number between 1 - 100
  console.log(y);
  return x + y;
}

console.log(subtract(5)); // Unpredictable

Just like add() is pure and subtract() is not, a presentational component behaves like a pure function: same input, same output. The output might be how the UI appears or an event with associated data.

More About Inputs and Outputs

If you’ve built a Canvas App before, you’ve already used components – even if you didn’t realize it. Most controls in a Canvas App are presentational components.

Take the Label control. It receives an input (Text) and renders output (the text on screen).

Events are another kind of output. For example, the Button control emits an event when clicked – handled through the OnSelect property. That property allows the app to respond to the click and perform some logic.

💡 When a component sends a message back to the application the component is said to have emitted an event.

Now let’s look at the Text Input control.

Like the others, it has inputs (like Placeholder). But it also emits a Change event via OnChange. Even better, it passes data back to the application through its Value property. As the user types, the value updates. That value is how we access what they typed.

How to Build Your Own Component

Let’s build a simple, customized input component. It will include:

• A label above the input

• Optional “required” validation

• Change detection and data output

Here is what it will look like:

Part 1: Create the Component

1. Navigate to the Components section of your Canvas App.

2. Add a new component and name it cmp_baseInput.

3. Resize it to 340 (w) x 100 (h).

Part 2: Add Controls

1. Add a Text Input control, centered.

2. Add two Labels—one above, one below the input.

3. Rename them:

   • lbl_label

   • lbl_hint

   • txt_textField

Part 3: Add Custom Properties

Add four properties to the component. We're primarily concerned with the Property Type, Property Definition, and Data Type properties.

• IsRequired (Data, Input, Boolean)

• Label (Data, Input, Text)

• Value (Data, Output, Text)

• OnChange (Event)

Part 4: Connect the Properties

Set the control's properties as follows.

lbl_label.Text = cmp_baseInput.Label

lbl_hint.Text = "This field is required."
lbl_hint.Visible = cmp_baseInput.IsRequired And Len(txt_textField.Value) < 1

txt_textField.OnChange = cmp_baseInput.OnChange()

cmp_baseInput.Value = txt_textField.Value
cmp_baseInput.Label = "Placeholder Label"

Part 5: Style It

lbl_label.Size = 12
lbl_label.Height = 24
lbl_label.FontColor = RGBA(122, 138, 143, 1)

lbl_hint.Size = 10
lbl_hint.Height = 24
lbl_hint.FontColor = RGBA(215, 58, 60, 1)
lbl_hint.FontWeight = 'TextCanvas.Weight'.Semibold

Part 6: Add It to the App

1. Go back to the application screen.

2. Insert the component and name it cmp_userName.

3. Add a label nearby and set its text to:
   "The user name is: " & cmp_userName.Value

Part 7: Test It

• Type in the component and click outside of it → label near the component updates and the hint disappears.

• Clear the text → hint reappears

• Set IsRequired to false → hint disappears

• Set OnChange to Notify("A change occurred!") and type in the input→ a toast message appears with you notification.

Wrapping Up

You’ve just created a functional, presentational component. It handles labels, validation, value output, and even events – all in one package.

This is the real power of components: abstraction, clarity, and reusability. Whether you're in a traditional or low-code environment, thinking in components helps you break complexity into manageable parts.

As your apps grow, this mindset will pay off. You'll spend less time rewriting logic and more time building value – one well-defined part at a time.

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

Stay curious and keep building.

But as this happens, questions arise, such as who supports these applications? And who will make the updates if there is a feature request or bug?

Many low-code applications are often created by a single developer, inherently leading to a single point of failure.

And don't let the advertised simplicity of low-code trick you into thinking anyone can edit the app, fix any issues, and add new features. Low code can still contain complexity, and complex solutions can quickly become a problem for organizations and teams that leverage dozens, if not hundreds, of other low- or non-low-code dependencies.

This doesn't mean that organizations should strictly restrict who can create these applications. Doing so would contradict the very purpose of low code. It's a model that empowers stakeholders themselves to rapidly prototype ideas and develop low-cost solutions to problems that, in traditional development, might cost millions of dollars.

In this low-code world, both organizations and developers need a plan. Developers, specifically, should have a plan to transfer knowledge of their products, whether working in a team or independently.

How to Simplify Complexity

Our relatively small team has created numerous low-code solutions, primarily leveraging Microsoft's suite of products. Some of these solutions are simple low-code canvas apps, while others contain hundreds of dependencies that are anything but low-code.

We've learned, sometimes the hard way, the importance of ensuring maintainability in our development. This means supporting the applications we build and enabling existing and new team members to support them in the future.

Initially, we found ourselves drawn to the premise of being able to create products that solve problems quickly. Before we knew it, we had our own problem: how do we support the array of these products, ensuring that not just us but new team members could do so as well?

Slow Down to Speed Up

This might sound contrary to the low-code paradigm, but taking frequent pauses to consider the long-term impacts of your decisions is critical to ensuring the tools you build today can be supported tomorrow.

This does not mean reverting back to the speeds of traditional software development, but you should not consider building low-code products as a race to the finish line.

Pair Programming

Incorporating traditional software development practices can significantly benefit the low-code movement. Even if your applications involve little to no conventional code, concepts like pair programming can be effectively applied when building low-code products.

Take, for example, the process of building a Power App. Traditionally, only one person could edit an app at a time. Although that limitation has changed—multiple people can now edit an app simultaneously—defining a collaborative process remains crucial.

Our team often employs a primary "driver" approach, where one member leads the development while another observes, providing real-time feedback and suggestions.

This method keeps everyone engaged and helps mitigate the effects of tunnel vision on the product. And this collaborative approach is especially valuable for more complex aspects of the application.

For more straightforward tasks, we often work in parallel but stay closely connected via Teams or Zoom, ready to coordinate and ensure each different component is part of a cohesive whole.

Application/Code Reviews

Low code doesn't mean no code. It is challenging to create robust applications with drag-and-drop alone. Even something like Power Apps has its own language called Power FX.

Schedule time each week to walk through or review others' applications to become familiar with their creations. Look for places where things can be improved, and be ready to accept feedback on your creations, too.

If you're using traditional code in your project, some of this can be accomplished with PRs. For purely low-code implementations, keep a document of changes and have a sign-off process to ensure other team members can access new changes.

For example, imagine adding a new screen to a Canvas app, allowing users to update personal settings. That change should be documented as unreviewed until at least one other team member has reviewed and signed off on this new feature.

Get Other Team Members Involved

If you're on a team, each product should involve at least two people to avoid single points of failure. Ensure each product has a primary and secondary developer or product owner. For larger teams, allow that secondary role to rotate, ensuring each member is more intimately involved with the team's products.

One way to get others involved and up to speed is to have other team members add new features or fix bugs in existing products under the guidance of the primary or lead developer. This knowledge transfer will help cultivate ownership in the various products your team supports, leading to higher engagement and motivation.

Additionally, as the workload is distributed more evenly across the team, bottlenecks are reduced, allowing for more expeditious handling of fixing bugs and enhancing products.

When a Hands-On-Approach isn't Possible...

Much of what I describe above is an attempt to get others involved with projects. The more we touch these things, the better we will understand them.

Inevitably, however, when this hands-on experience isn't possible, it is essential to have practices that can mitigate the effects of isolated development—that is, a development done by one or just a few people.

The two most important things we can do are create and maintain comprehensive documentation about our products and use standard practices as much as possible. We'll talk about documentation first.

Document, Document, Document

As you've probably experienced, the low-code movement allows applications to be created quickly. The more applications exist, the fewer touchpoints we have with older ones. While those touchpoints are critical to the knowledge transfer process, relying on them alone isn't enough.

Whether you're on a team or a solo developer, creating documentation that describes each aspect of your products is critical. For small projects, this may be a simple text document. For larger projects, you could utilize a SharePoint site. Of course, as products become even more complex, the various dependencies will likely have their own documentation (for example, Git repositories).

Here is an example of how you might document a product you are building:

Let's say you have an application that allows users to reserve a conference room for meetings. That application consists of a user interface (such as a Canvas app) and custom code that creates a follow-up reminder for the person who reserved the meeting a day before. This reminder could send an email to remind the user about the meeting, and if the meeting is no longer occurring, encourage them to cancel the reservation. Finally, this product could also have a reporting element, where administrators can see conference room utilization over time to better understand demand.

Here is how you might document this project:

1. Establish a single source of truth about this project, such as a SharePoint page.

2. This page briefly describes the project, the product owners, and the lead developers.

3. The page would also briefly describe this project's components (Canvas app, custom code, and reporting dashboard).

4. Finally, you would include documentation on any easy-to-overlook aspects or non-standard project implementations (more on standardization later).

The SharePoint page handles the high-level overview of the project and gets you pointed in the right direction. Regarding the individual components, the Canvas app will include comments and notes in the version history, and your custom code will leverage Git and often include a detailed readme.

Documentation can be challenging, but it is critical. While documentation should be comprehensive, it should complement the hands-on knowledge transfer techniques described above.

Standardize as Much as Possible

Whether it is low-code or traditional development, it is important to have standard practices. This is even more important when talking about low code because of the speed at which things can be developed and potentially get out of control.

From project planning, design, development, and testing to cross training team members, make time to create standard practices for each phase.

Standardization shouldn't be considered a way to eliminate the need for cross-training and documentation but rather a way to complement those stages and reduce the time needed in those areas.

If you can approach a problem the same way every time, you can spend time discussing those non-standard and easy-to-forget parts of what you're building.

Here are some questions to get you started:

1. What big-picture steps will each application require? Who will be involved in those steps?

2. What tools will you use? (for example, Power Apps, Appian, Pega)

3. Can you support traditional development? If so, how will that look?

4. What is your philosophical approach to development? For example, should you design the user interface or business logic first? What database will you use? (for example, SharePoint or Dataverse)

5. What conventions will you use in your code? (for example, naming conventions for screens and variables)

6. What does this knowledge transfer or cross-training process look like? Do you have dedicated times each week to review each other's work?

Of course, this list goes on. The more you learn, the more you'll realize what needs to be discussed. Get started by creating a Standard Operating Procedure (SOP), and be prepared to edit it early and often.

What if I am a Solo Developer?

If you're a solo developer, it may be easy to think that the recommendations above don't apply. But this couldn't be further from the truth. Creating and maintaining a knowledge-transfer framework is even more critical as a solo developer. While co-developing and pair programming are not directly applicable, the concepts still apply.

For example, take time to meet other developers and ask for feedback. At a minimum, it will be an excellent way to meet other people doing the same thing. And, of course, with AI taking a front row in programming, you can always leverage AI to help you learn new techniques and optimize the things you are building.

Finally, documentation and standard practices are just as necessary for the individual developer. First, if you ever work with others, you'll have a reference for your work. Second, these things will act as an external reminder of how you intend to solve development-related problems in the future.

Conclusion

While low-code platforms offer incredible speed and flexibility, they can also introduce challenges when it comes to maintenance. Rapid development, if not managed carefully, can lead to issues that undermine the long-term success of your applications.

But by intentionally slowing down and establishing a clear plan for knowledge transfer, you can safeguard the future of your critical products. This approach ensures that applications remain supported and sustainable, both now and for years to come.

Stay curious.

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

To define NodeJS, we will take a step back and look at how JavaScript works and discuss three components that play a significant role in JavaScript:

1. The language itself

2. The JavaScript engine

3. The JavaScript runtime

The JavaScript Language Itself

JavaScript is a programming language based on ECMAScript. You may also hear it referred to as a dialect or implementation of the ECMAScript language standard.

A language standard contains a set of rules for how a language should behave. Dialects, on the other hand, are implementations of a language standard. Much like there are regional dialects of the English language, JavaScript is a dialect—the most popular dialect—of ECMAScript.

Before 2008, developers only used JavaScript to manipulate web pages. But the inability to use JavaScript outside the browser was not a limitation of JavaScript, the language, but a constraint of where this JavaScript code was being executed.

What is the JavaScript Engine?

Before we touch on where JavaScript is executed, we will briefly touch on how.

There are compiled languages and interpreted languages. A compiled language is like a prepared meal. All the ingredients have been mixed, organized, and arranged into something that only needs to be cooked. They've been checked beforehand to ensure they meet the standard for that meal.

An interpreted language, on the other hand, is like a hibachi chef performing their artistry on the grill as you watch. They prepare your meal in real-time, make adjustments on the fly, and incorporate their unique skills and techniques to create the final dish.

In the realm of JavaScript interpretation, a JavaScript engine takes on the role of the hibachi chef, executing the code and bringing it to life on the digital grill.

As much as it may seem like an improvisational act, the JavaScript engine still implements specific rules, ensuring consistency when executing your code. (Recall many of these rules come from the ECMAScript language standard).

But it may surprise you that much of what is written by a web developer will be found nowhere in the ECMAScript standard.

You see, the DOM, for example, is part of an "outside world." And ECMAScript has no specifications about how JavaScript should interact with this outside world. These rules come from somewhere else—the JavaScript runtime.

What is a JavaScript Runtime?

A runtime is a place or environment where your code executes. It is not the thing running the code itself (this is the engine) but rather an environment that provides access to certain parts of the outside world.

Imagine your code is a person inside of a house. Different rooms will have different windows which allow this person to see different parts of what is outside. The outside doesn't change, but the room that the person is in will determine what they can see. This is the essence of what a JavaScript runtime is. It is like a room that you can place your code within. And just like the person inside of the house, the room your code is in will determine which parts of the outside world it has access to.

The most common JavaScript runtime is the browser. And for the browser, the parts of the outside world it allows you to see (interact with) with are the Window object and, subsequently, the document object, or DOM.

These objects are critical for web developers because they provide the necessary APIs that allow your JavaScript to interact with web pages. Adding a

, updating some inner HTML text, or listening to window-based events are all thanks to the Web API provided by the browser runtime.

So What is NodeJS?

By now, you may have an idea of what NodeJS is. Node is a JavaScript runtime. It's not a language or a framework. It's simply an environment that allows you to write JavaScript that interacts with different parts of the outside world other than the browser.

Instead of providing things like the Web API, it provides APIs to interact with components such as the file system, HTTP, and the operating system.

How Node Works

Let's look at an example of what Node can do. You may need to install Node first. The easiest way to install it is to visit NodeJS.org and download the LTS (Long-Term Support) version.

Node JS org home screen displaying download options

We can check to ensure that it is installed correctly by opening a command line or terminal prompt and typing node -v.

node -v
> v18.16.0

Let's run our first command in Node. In a terminal window, start the Node REPL by typing in node and pressing enter.

Once the REPL has started, we can run our first JavaScript commands within the Node runtime. Let's type console.log(1 + 1):

console.log(1+1)
> 2

Running commands in the REPL is great for demo purposes, but Node wouldn't be beneficial if that were the only place you could interact with the Node runtime. Fortunately, we can also create JavaScript files and run them with Node.

Let's create a JavaScript file named main.js. Add a console.log statement and display a message of your choice. Here is what I've created:4

onst msg = 'Hello, World! Here is a message from main.js'

console.log(msg

From your terminal (within the same directory where you saved the file), type node main.js and press enter. You should see something similar to the following:

node main.js
> Hello, World! Here is a message from main.js!

Let's do one more thing with Node and build something more complex.

In this last example, we will leverage some built-in Node modules to create an HTML file and then serve that file all with JavaScript (within the Node runtime, of course!).

First, we will import three modules: FS, OS, and HTTP. These are core modules provided by Node JS.

const fs = require('fs');
const http = require('http);
const os = require('os');

Next, we will create the content that we will add to the index.html file we will create. We will get the operating system type of our machine and eventually populate our HTML file with that information.

// Get the OS type of our machine
osType = os.type();

// Create a string of HTML content for a file we will create
htmlContent = '<html><h3>Hello, World! Your OS type is ${osType}</h3></html>

Now that we have the content prepared for our HTML file, it's time to create the file. Most of what we do with Node JS will be writing asynchronous code. So for our example, we will use callback functions to run any code we want to ensure runs after our asynchronous code.

The next code to write will create the HTML file. We use the fs module and the writeFile method to do this. This function accepts a callback. We will use this callback to ensure the file has been created before we read the file and eventually create the server.

// Create an index.html file with the htmlContent variable as the content.
// Since this is async, we will provide a callback as a third argument
// that will run after the file has been created. It is in this callback that
// we will read the file. For code clarity, we won't handle errors.

fs.writeFile('./index.html', htmlContent, (err) => {
    const server = http.createServer((req, res) => {
        fs.readFile('.index.html', (err, content) => {
            res.setHeader('Content-Type', 'text/html');
            res.end(content);
        });
    });
}

We've created the file and prepared the server up to this point. But to serve the file, we need to start the server. We use the listen method on createServer to start the server. This function accepts several arguments. We will pass in a port number of 3000. So putting it all together:

const fs = require('fs');
const http = require('http);
const os = require('os');

// Get the OS type of our machine
osType = os.type();

// Create a string of HTML content for a file we will create
htmlContent = '<html><h3>Hello, World! Your OS type is ${osType}</h3></html>

// Create an index.html file with the htmlContent variable as the content.
// Since this is async, we will provide a callback as a third argument
// that will run after the file has been created. It is in this callback that
// we will read the file. For code clarity, we won't handle errors.

fs.writeFile('./index.html', htmlContent, (err) => {
    const server = http.createServer((req, res) => {
        fs.readFile('.index.html', (err, content) => {
            res.setHeader('Content-Type', 'text/html');
            res.end(content);
        });
    });
    server.listen(3000);
}

Now remember, this is just a JavaScript file. The file has the code to do everything we want to do, but we need to execute the script. Let's run the script and see what happens:

node main.js
>

It may appear that the script is stuck or broken. Remember, however, that we've started a server. Until we cancel the script, the script is running, and it may appear that is the script has timed out.

Let's cancel the server (press ctrl + c twice), and then add a console.log to our listen method to help provide some feedback when the server is running. listen can accept a callback as the second argument. We will pass in a callback function to log some output.

server.listen(3000, () => {
    console.log('Listening on port 3000!');
});

Now, when we run the script we should see:

To run this file, change to the directory where the file is and run the following command:

node main.js
> Listening on port 3000!

The server is running. But where is our webpage?

Open a browser, enter localhost:3000 for the URL, and hit enter. You should see something similar to this:

The content of the index.html file we have created and served with Node!

You've done it! You've created a straightforward web application and served it with NodeJS.

Wrapping Up

JavaScript, the language, is written syntax executed by a JavaScript engine, which adheres to the rules set by the ECMAScript standard.

In addition to the language standard, the engine incorporates additional features for interacting with the outside world. The JavaScript runtime provides these features. The most common runtimes are the browser and Node, but there are others like Deno (similar to Node but offering additional features like native TypeScript support).

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

And, if you look hard enough for these lessons, you will find them. Whether they are a manifestation of your mind or can be held in your hand, once you see them, they remain yours forever.

Programming offers significant parallels to life. We are tasked with creating something–something whose sum feels more significant than the parts. Like life, it is a test of bounded creativity. There are rules we must follow, some we should follow, and others we are free to ignore. Programming offers us a glimpse, however ephemeral it may be, into some fundamental truths about the world in which we reside.

The Four Parallels Between Programming and Life

Iteration is progress.

Did you know, if you started the month with a single penny and it doubled every day, you would have \(163 on the 15th of the month? Surely, you think, there must be a better way to make \)163 in 15 days. But, if you wait another 15 days, you would have more than 5 million dollars.

Go ahead, I’ll wait while you do the math.

In programming, we use the term iterate to indicate repeating something. In a more formal definition, it is repeatedly applying a procedure to the previous result of that procedure. For example, adding the numbers 1 and 1 to get 2, then adding 1 and 2 to get 3, and so forth.

When we iterate, we look for feedback. We wait for some condition to be met so we can either stop iterating or adjust how we are iterating. If we fail to listen for that feedback, we can get stuck in an infinite loop.

Life is no different. We often expect we can jump from point A to point B without ever defining what point A or point B is. And, even when we identify those points, we expect an immediate move from start to finish. Instead, what is often the truth, is we must incrementally make our way from beginning to end. We must listen for feedback that tells us where we are so we can make adjustments.

When we have goals, progress can often feel–for the first few days, weeks, or even months–non-existent. We’re often enticed to start over or start fresh. But in doing so, we fail to realize, while we might not have reached our destination, we are somewhere far past where we started. A complete restart isn’t necessary, we just need to make some minor adjustments.

Stop starting over. Let iteration be the force the creates progress.

Most complex problems are collections of smaller problems that have already been solved.

Even the most fascinating apps are a series of mostly mundane solutions to mundane problems. In fact, most of the solutions implemented within a program are nothing unique. It is the combination of those ordinary solutions that creates an extraordinary product.

In programming, there are different ways to use these quite-ordinary solutions. One way is through a term called abstraction. To abstract something is to move something away from something else.

In computer programming, when we abstract something, we are often building higher-level technology on top of lower-level technology. This makes it easier to work with lower-level technologies.

For example, most programming languages are abstractions of the enigmatic binary language (0s and 1s). They put a layer between us and some more fundamental, but cumbersome, level of interaction with the computer. These higher-level languages allow us to focus on higher-level problems.

Another way we can more efficiently solve problems is by using someone else’s solutions. You may have also heard the term library. And, while I am not speaking of a poorly lit, dusty, and quiet location where books live, it isn’t far off.

A library, in programming terms, is code that someone else wrote that solves routine problems. It also abstracts away those things which aren’t absolutely fundamental to solving whatever problem you have.

For example, if you are writing a program that requires someone to log in to use your application, you could write the code to encrypt and decrypt passwords yourself, or, you could use code written by someone else to do that for you. With the latter option, we free up time to focus on more significant problems our application is trying to solve.

All of us use abstractions and libraries in some shape or form. For example, the grocery store is an abstraction of producing our own food. A car is an abstraction of traveling on foot. An oven is an abstraction of building a fire. These are layers we place in front of us that allows us to allocate time to higher-level problems.

Reinvent the wheel only to learn how to make a wheel, not to drive to the store.

How you define a problem is how you will solve it.

Recall the story of a truck that drove under a bridge and got stuck. Engineers spent hours trying to figure out how to move the bridge. A small child came up, face to face with the tires of the truck, and said, “what if you let the air out of the tires?”

From the child’s vantage point, the problem wasn’t the bridge was too short, but rather the truck was too tall.

Most people can solve any problem. In fact, most problems state the solution. For example, if the bridge is causing the issue, the answer is to do something with the bridge. If, however, the problem is that the truck is too tall, then the solution–almost glaringly obvious–is to make the truck shorter.

The arrangement of parts is much more important than the parts themselves.

What does the Google Maps codebase, the Declaration of Independence, Martin Luther King Jr.’s I have a dream speech, Steve Jobs’s 2005 commencement address, and my first app, Hello, World have in common?

The access to the same 26 letters of the English alphabet.

There is very little that is more fascinating to me than the written word. The written word is one of the most powerful technologies that emerged from humans.

Yes, I use the term technology because–even carved into the wall of a cave–it fundamentally changed how we persist information. No longer was data constrained within the boundaries of our minds.

While the purpose of the written word was initially linked to record-keeping, it quickly became a way to spread ideas. Some of these ideas would anger, and others inspire.

Every language (including computer language) has subtleties when transmitting information through writing or speech. The words and their constituent parts may be slightly different. Still, however, a language is a set of symbols that can be arranged into what seems to be an infinite number of ideas.

For example, in the English language, there are roughly 29 symbols that I can use to represent nearly my entire universe. I’ve mentioned the 26 letters, but it is also helpful to have access to periods, commas, and question marks.

Those 29 characters are available to you, me, and were available to Steve Jobs. Yet, each of us, throughout our lives, will follow different trajectories based on the combination of letters we chose to believe and speak into existence.

Interestingly, while we often add words to the dictionary, we don’t usually add letters. This means, at the most fundamental level, that all the ideas that can exist, already do, with their constituent parts quietly waiting for us to shuffle them into existence.

Les Brown sums it up well with this thought experiment:

Imagine if you will, being on your death bed. And standing around your bed–the ghosts of the ideas, the dreams, the abilities, the talents given to you by life.

And that you, for whatever reason, never acted on those ideas. You never pursued that dream. You never used those talents. We never saw your leadership. You never used your voice. You never wrote that book.

And there they are, standing around your bed, looking at you with large angry eyes saying: “We came to you. And only you could have given us life! Now we must die with you forever.”

The question is — if you die today–what ideas, what dreams, what abilities, what talents, what gifts, would die with you?

Thank you for reading!

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

How do we define the term “constant”?

In programming, a constant it something that doesn’t change.

It is a value that cannot be altered by the program during normal execution.

So, does JavaScript gives us a way to declare a value that can’t be changed? Before we answer this, let’s look at the roots of this convention.

The capitalization convention has roots in C

C is a compiled language. This means that another program converts all of your code into machine code before it runs.

JavaScript, on the other hand, is an interpreted language. An interpreter reads your code, line-by-line, as it runs.

The difference between compilation and interpretation plays a role in how we declare constant values in C.

In C, I can declare a variable like this:

int hoursInDay = 24;

Or, a constant like this:

#define hoursInDay 24

The second example is called a symbolic constant. Symbolic constants can be a sequence of characters, a numeric constant, or a string. These are also called primitive values. The primitive values in JavaScript are strings, numbers, booleans, null, undefined, symbol (not to be confused with symbolic constants) and big int.

Now, let’s revisit compilation.

Before compilation, there is a pre-compilation phase. Here, the pre-compiler replaces all instances of symbolic constants with the respective value. The compiler never knows that the programmer wrote hoursInDay. It only sees the number 24.

Capitalization helps the programmer see these truly constant values.

#define HOURS_IN_DAY 24

JavaScript constants are different than symbolic constants

Before ES6, we stored most values in variables, even those values that you wanted to remain constant.

Capitalization helped us see values we wanted to remain constant.

var HOURS_IN_DAY = 24;
var hoursRemaining = currentHour - HOURS_IN_DAY;
var MY_NAME = 'Brandon';
MY_NAME = ... // oops don't want to do this.

ES6 introduced the declaration const which isn’t a “constant” in the purest sense.

ES6 added the terms const and let as ways to create variables with different intentions.

With those two terms, you may think that we either:

1. don’t need to capitalize anything since we can clearly see which variables are intended to remain the same, or

2. we should capitalize everything that we declare with const.

By definition, const creates a constant that is a read-only reference to a value. This does not mean the value it holds is immutable. It only says that the variable identifier cannot be reassigned.

In other words, some const references can change.

const firstPerson = {
  favoriteNumber: 10,
};
const secondPerson = firstPerson;
console.log(secondPerson.favoriteNumber); //10
firstPerson.favoriteNumber +=1;
console.log(secondPerson.favoriteNumber); //11

The above example shows that the declaration const doesn’t ensure that the variable is immutable.

const only prevents us from trying to reassign the variable name. It doesn’t stop the object property from changing. Remember: objects are pass-by-reference.

// "TypeError: Assignment to constant variable."secondPerson = 'something else';
const secondPerson = 'Me'
secondPerson = 'something else';

So, for JavaScript, we have to go beyond merely looking for a const declaration. We need to ask two questions to determine if a variable is a constant:

1. Is the value of the variable primitive?

2. Do we intend to keep the variable name pointing at the same value throughout our program?

If the answer is yes to both, we should declare the variable with const and may capitalize the name.

Notice I said “may.” The spirit of this convention comes from different languages that had actual constants. JavaScript doesn’t. At least in the purest sense. This may be why you see this convention less often than you might expect. Airbnb has a great section in their style guide with their take here.

The key takeaway is to recognize defining a constant in JavaScript has to include the programmer's intentions.

In addition, not every convention from one language makes sense in a different language. Finally, I can only imagine many conventions were used long before IDEs had the capabilities they have today. I’m convinced my IDE takes pleasure in telling me I’m wrong. It happens a lot.

Thanks for reading!

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

Notes

• You may wonder why I didn’t use PI in any of these examples. Acronyms– especially two-letter acronyms–tend to be either always capitalized or always lowercase by convention.

Most programming languages seem to have very strict standards — certain terms have to be used in certain places. But one area where there is an enormous amount of freedom is how we name those terms.

Take this simple program which creates a sentence from an array of words, adds a punctuation mark, and logs it to the console:

Nothing too special, right? But what you may not have considered is how many terms you were responsible to name.

There are 23 words (not including hard-coded values) in the above program. We controlled the names of 14 of those words. That is more than 60% of what was typed, was our responsibility to name!

You are responsible for the majority of the names in your program

Whether you are building an enterprise application or a simple Hello, World, you want your program to read like a Times Bestseller, not a Mad Libs workbook.

This is not a manifesto on how to structure an entire JavaScript application, but rather a chapter on how to choose names for those things in which you have the freedom to do so. I’ve included the various references at the bottom if you want to learn more. One last thing, the key takeaway of all of our conventions and standards is this:

Most of these conventions are not for you today, but instead, for you and the people reading your code tomorrow.

References and continued learning

1. “Clean Code” by Robert C. Martin — A great read for all languages. It goes beyond naming conventions and proposes the entire structure of your program. The examples are in Java, but the principles apply to JavaScript.

2. “Clean Code JavaScript” by Ryan Mcdermott — The above book, but remade for JavaScript. It is available online and is free.

3. Airbnb JavaScript Style Guide — Possibly the most comprehensive style guide for JavaScript. It contains not only the what, but also the why. (If you’re on a small device, you may need to click on “view all readme” to see the entire document).

4. W3 JavaScript Style Guide — A s_hort and concise guide._

5. Google’s ES6 Style Guide — Google’s style guide for JavaScript.

Thanks for reading!

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

A JavaScript promise is an object that represents the completion or failure of an asynchronous task and its resulting value.¹

The end.

I’m kidding of course. So, what does that definition even mean?

First of all, many things in JavaScript are objects. You can create an object a few different ways. The most common way is with object literal syntax:

const myCar = {
   color: 'blue',
   type: 'sedan',
   doors: '4',
};

You could also create a class and instantiate it with the new keyword.

class Car {
   constructor(color, type, doors) {
      this.color = color;
      this.type = type;
      this.doors = doors
   }
}

const myCar = new Car('blue', 'sedan', '4');

console.log(myCar);

A promise is simply an object that we create like the later example. We instantiate it with the new keyword. Instead of the three parameters we passed in to make our car (color, type, and doors), we pass in a function that takes two arguments: resolve and reject.

Ultimately, promises tell us something about the completion of the asynchronous function we returned it from–if it worked or didn’t. We say the function was successful by saying the promise resolved, and unsuccessful by saying the promise rejected.

const myPromise = new Promise(function(resolve, reject) {});

console.log(myPromise);

Notice the promise is “pending.”

const myPromise = new Promise(function(resolve, reject) {
   resolve(10);
});

Notice we resolved the promise with the value 10.

See, not too scary–just an object we created. And, if we expand it a bit:

Notice we have some methods we have access to namely “then” and “catch”

In addition, we can pass anything we’d like to into resolve and reject. For example, we could pass an object instead of a string:

return new Promise((resolve, reject) => {
   if(somethingSuccesfulHappened) {
      const successObject = {
         msg: 'Success',
         data,//...some data we got back
      }
      resolve(successObject); 
   } else {
      const errorObject = {
         msg: 'An error occured',
         error, //...some error we got back
      }
      reject(errorObject);
   }
});

Or, as we saw earlier, we don’t have to pass anything:

return new Promise((resolve, reject) => {
   if(somethingSuccesfulHappend) {
      resolve()
   } else {
      reject();
   }
});

What about the “asynchronous” part of the definition?

JavaScript is single threaded. This means it can only run one thing at a time. If you can imagine a road, you can think of JavaScript as a single lane highway. Certain code (asynchronous code) can slide over to the shoulder to allow other code to pass it. When that asynchronous code is done, it returns to the roadway.

As a side note, we can return a promise from any function. It doesn’t have to be asynchronous. That being said, promises are normally returned in cases where the function they return from is asynchronous. For example, an API that has methods for saving data to a server would be a great candidate to return a promise!

The takeaway:

Promises give us a way to wait for our asynchronous code to complete, capture some values from it, and pass those values on to other parts of our program.

I have an article here that dives deeper into these concepts: Thrown For a Loop: Understanding Loops and Timeouts in JavaScript.

How do we use a promise?

Using a promise is also called consuming a promise. In our example above, our function returns a promise object. This allows us to use method chaining with our function.

Here is an example of method chaining I bet you’ve seen:

const a = 'Some awesome string';
const b = a.toUpperCase().replace('ST', '').toLowerCase();

console.log(b); // some awesome ring

Now, recall our (pretend) promise:

const somethingWasSuccesful = true;

function someAsynFunction() {
   return new Promise((resolve, reject){
      if (somethingWasSuccesful) {
         resolve();     
      } else {
         reject()
      }
   });
}

And, consuming our promise by using method chaining:

someAsyncFunction
   .then(runAFunctionIfItResolved(withTheResolvedValue))
   .catch(orARunAfunctionIfItRejected(withTheRejectedValue));

A (more) real example.

Imagine you have a function that gets users from a database. I’ve written an example function on Codepen that simulates an API you might use. It provides two options for accessing the results. One, you can provide a callback function where you can access the user or any error. Or two, the function returns a promise as a way to access the user or error.

Traditionally, we would access the results of asynchronous code through the use of callbacks.

rr someDatabaseThing(maybeAnID, function(err, result)) {
   //...Once we get back the thing from the database...
   if(err) {
      doSomethingWithTheError(error)
   }   else {
      doSomethingWithResults(results);
   }
}

The use of callbacks is ok until they become overly nested. In other words, you have to run more asynchronous code with each new result. This pattern of callbacks within callbacks can lead to something known as “callback hell.”

The beginnings of callback hell

Promises offer us a more elegant and readable way to see the flow of our program.

doSomething()
   .then(doSomethingElse) // and if you wouldn't mind
   .catch(anyErrorsPlease);

Writing our own promise: Goldilocks, the Three Bears, and a Supercomputer

Imagine you found a bowl of soup. You’d like to know the temperature of that soup before you eat it. You're out of thermometers, but luckily, you have access to a supercomputer that tells you the temperature of the bowl of soup. Unfortunately, this supercomputer can take up to 10 seconds to get the results.

Here are a couple of things to notice.

1. We initiate a global variable called result.

2. We simulate the duration of the network delay with Math.random() and setTimeout().

3. We simulate a temperature with Math.random().

4. We keep the delay and temperature values confined within a range by adding some extra “math”. The range for temp is 1 to 300; the range for delay is 1000ms to 10000ms (1s to 10 seconds).

5. We log the delay and temperature so we have an idea of how long this function will take and the results we expect to see when it’s done.

Run the function and log the results.

getTemperature(); 
console.log(results); // undefined

The temperature is undefined. What happened?

The function will take a certain amount of time to run. The variable is not set until the delay is over. So while we run the function, setTimeout is asynchronous. The part of the code in setTimeout moves out of the main thread into a waiting area.

I have an article here that dives deeper into this process: Thrown For a Loop: Understanding Loops and Timeouts in JavaScript.

Since the part of our function that sets the variable result moves into a holding area until it is done, our parser is free to move onto the next line. In our case, it’s our console.log(). At this point, result is still undefined since our setTimeout is not over.

So what else could we try? We could run getTemperature() and then wait 11 seconds (since our max delay is ten seconds) and then console.log the results.

getTemperature();
   setTimeout(() => {
      console.log(result); 
   }, 11000);
   
// Too Hot | Delay: 3323 | Temperature: 209 deg

This works, but the problem with this technique is, although in our example we know the maximum network delay, in a real-life example it might occasionally take longer than ten seconds. And, even if we could guarantee a maximum delay of ten seconds, if the result is ready sooner, we are wasting time.

Promises to the Rescue

We are going to refactor our getTemperature() function to return a promise. And instead of setting the result, we will reject the promise unless the result is “Just Right,” in which case we will resolve the promise. In either case, we will pass in some values to both resolve and reject.

We can now use the results of our promise we are returning (also know as consuming the promise).

getTemperature()
   .then(result => console.log(result))
   .catch(error => console.log(error));
   
// Reject: Too Cold | Delay: 7880 | Temperature: 43 deg

.then will get called when our promise resolves and will return whatever information we pass into resolve.

.catch will get called when our promise rejects and will return whatever information we pass into reject.

Most likely, you’ll consume promises more than you will create them. In either case, they help make our code more elegant, readable, and efficient.

Summary

1. Promises are objects that contain information about the completion of some asynchronous code and any resulting values we want to pass in.

2. To return a promise we use return new Promise((resolve, reject)=> {})

3. To consume a promise we use .then to get the information from a promise that has resolved, and .catch to get the information from a promise that has rejected.

4. You’ll probably use (consume) promises more than you’ll write.

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

References

1.) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

What is Testing?

Testing is the process of ensuring a program receives the correct input and generates the correct output and intended side-effects. We define these correct inputs, outputs, and side-effects with specifications. You may have seen testing files with the naming convention filename.spec.js. The spec stands for specification. It is the file where we specify or assert what our code should do and then test it to verify it does it.

You have two choices when it comes to testing: manual testing and automated testing.

Manual Testing

Manual testing is the process of checking your application or code from the user’s perspective. Opening up the browser or program and navigating around in an attempt to test functionality and find bugs.

Automated Testing

Automated testing, on the other hand, is writing code that checks to see if other code works. Contrary to manual testing, the specifications remain constant from test to test. The biggest advantage is being able to test many things much faster.

It’s the combination of these two testing techniques that will flush out as many bugs and unintended side-effects as possible, and ensure your program does what you say it will. The focus of this article is on automated testing, and in particular, unit testing.

There are two main types of automated tests: Unit and End-to-End (E2E). E2E tests test an application as a whole. Unit tests test the smallest pieces of code, or units. What is a unit? Well, we define what a unit is, but in general, it’s a relatively small piece of application functionality.

Recap:

1. Testing is verifying our application does what it should.

2. There are two types of tests: manual and automated

3. Tests assert that your program will behave a certain way. Then the test itself proves or disproves that assertion.

Test-Driven Development

Test-driven development is the act of first deciding what you want your program to do (the specifications), formulating a failing test, then writing the code to make that test pass. It is most often associated with automated testing. Although you could apply the principals to manual testing as well.

Let’s look at a simple example: Building a wooden table. Traditionally, we would make a table, then once the table is made, test it to make sure it does, well, what a table should do. TDD, on the other hand, would have us first define what the table should do. Then when it isn’t doing those things, add the minimum amount of “table” to make each unit work.

Here an example of TDD for building a wooden table:

I expect the table to be four feet in diameter.

The test fails because I have no table.

I cut a circular piece of wood four feet in diameter.

The test passes.

__________

I expect the table to be three feet high.

The test fails because it is sitting on the ground.

I add one leg in the middle of the table.

The test passes.

__________

I expect the table to hold a 20-pound object.

The test fails because when I place the object on the edge, it makes the table fall over since there is only one leg in the middle.

I move the one leg to the outer edge of the table and add two more legs to create a tripod structure.

The test passes.

This would continue on and on until the table is complete.

Recap

1. With TDD, test logic precedes application logic.

A Practical Example

Imagine we have a program that manages users and their blog posts. We need a way to keep track of the posts a user writes in our database with more precision. Right now, the user is an object with a name and email property:

user = { 
   name: 'John Smith', 
   email: 'js@somePretendEmail.com' 
}

We will track the posts a user creates in the same user object.

user = { 
   name: 'John Smith', 
   email: 'js@someFakeEmailServer.com'
   posts: [Array Of Posts] // <-----
}

Each post has a title and content. Instead of storing the entire post with each user, we’d like to store something unique that could be used to reference the post. We first thought we would store the title. But, if the user ever changes the title, or if–although somewhat unlikely–two titles are exactly the same, we’d have some issues referencing that blog post. Instead, we will create a unique ID for each blog post that we will store in the userObject.

user = { 
   name: 'John Smith', 
   email: 'js@someFakeEmailServer.com'
   posts: [Array Of Post IDs]
}

Set up our testing environment

For this example, we will be using Jest. Jest is a testing suite. Often, you’ll need a testing library and a separate assertion library, but Jest is an all-in-one solution.

An assertion library allows us to make assertions about our code. So in our wooden table example, our assertion is: “I expect the table to hold a 20-pound object.” In other words, I am asserting something about what the table should do.

Project setup

1. Create an NPM project: npm init.

2. Create id.js and add it to the project’s root.

3. Install Jest: npm install jest --D

4. Update the package.json test script

// package.json

{
   ...other package.json stuff
   "scripts": {   
     "test": "jest" // this will run jest with "npm run test"
   }
}

That’s it for the project setup! We aren’t going to have any HTML or any styling. We are approaching this purely from a unit-testing standpoint. And, believe it or not, we have enough to run Jest right now.

In the command line, run our test script: npm run test.

You should have received an error:

No tests found
In /****/
  3 files checked.
  testMatch: **/__tests__/**/*.js?(x),**/?(*.)+(spec|test).js?(x) - 0 matches
  testPathIgnorePatterns: /node_modules/ - 3 matches

Jest is looking for a file name with some specific characteristics such as a .spec or .test contained within the file name.

Let’s update id.js to be id.spec.js.

Run the test again

You should receive another error:

FAIL  ./id.spec.js
  ● Test suite failed to run
  
Your test suite must contain at least one test.

A little bit better, it found the file, but not a test. That makes sense; it’s an empty file.

How Do We Write a Test?

Tests are just functions that receive a couple of arguments. We can call our test with either it() or test().

it()is an alias of test().

Let’s write a very basic test just to make sure Jest is working.

// id.spec.js

test('Jest is working', () => {
   expect(1).toBe(1);
});

Run the test again.

PASS  ./id.spec.js
  ✓ Jest is working (3ms)
  
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.254s
Ran all test suites.

We passed our first test! Let’s analyze the test and results output.

We pass a title or description as the first argument.

test('Jest is Working')

The second argument we pass is a function where we actually assert something about our code. Although, in this case, we aren’t asserting something about our code, but rather something truthy in general that will pass, a sort of sanity check.

...() => { expect(1).toBe(1) });

This assertion is mathematically true, so it’s a simple test to ensure we’ve wired up Jest correctly.

The results tell us whether the test passes or fails. It also tells us the number of tests and test suites.

A side note about organizing our tests

There is another way we could organize our code. We could wrap each test in a describe function.

describe('First group of tests', () => {
   test('Jest is working', () => {
      expect(1).toBe(1);
   });
});

describe('Another group of tests', () => {
   // ...more tests here
});

describe() allows us to divide up our tests into sections:

PASS  ./id.spec.js
  First group of tests
    ✓ Jest is working(4ms)
    ✓ Some other test (1ms)
  Another group of tests
    ✓ And another test
    ✓ One more test (12ms)
    ✓ And yes, one more test

We won’t use describe, but it is more common than not to see a describe function that wraps tests. Or even a couple of describes–maybe one for each file we are testing. For our purposes, we will just focus on test and keep the files fairly simple.

Testing Based on Specifications

As tempting as it is to just sit down and start typing application logic, a well-formulated plan will make development easier. We need to define what our program will do. We define these goals with specifications.

Our high-level specification for this project is to create a unique ID, although we should break that down into smaller units that we will test. For our small project we will use the following specifications:

1. Create a random number

2. The number is an integer.

3. The number created is within a specified range.

4. The number is unique.

Recap

1. Jest is a testing suite and has a built-in assertion library.

2. A test is just a function whose arguments define the test.

3. Specifications define what our code should do and are ultimately what we test.

Specification 1: Create a Random Number

JavaScript has a built-in function to create random numbers–Math.random(). Our first unit test will look to see that a random number was created and returned. What we want to do is use math.random() to create a number and then ensure that is the number that gets returned.

So you might think we would do something like the following:

expect(our-functions-output).toBe(some-expected-value). The problem with our return value being random, is we have no way to know what to expect. We need to re-assign the Math.random() function to some constant value. This way, when our function runs, Jest replaces Math.random()with something constant. This process is called mocking. So, what we are really testing for is that Math.random()gets called and returns some expected value that we can plan for.

Now, Jest also provides a way to prove a function is called. However, in our example, that assertion alone only assures us Math.random()was called somewhere in our code. It won’t tell us that the result of Math.random()was also the return value.

Why would you want to mock a function? Isn’t the point to test the real code? Yes and no. Many functions contain things we cannot control, for example an HTTP request. We aren’t trying to test this code. We assume those dependencies will do what they are supposed or make pretend functions that simulate their behavior. And, in the event those are dependencies we’ve written, we will likely write separate tests for them.

Add the following test to id.spec.js

test('returns a random number', () => {
   const mockMath = Object.create(global.Math);
   mockMath.random = jest.fn(() => 0.75);
   global.Math = mockMath;
   const id = getNewId();
   expect(id).toBe(0.75);
});

Breaking the above test down

First, we copy the global Math object. Then we change the random method to return a constant value, something we can expect. Finally, we replace the global Math object with our mocked Math object.

We should get an ID back from a function (that we haven't created yet–remember this TDD). Then, we expect that ID to equal 0.75–our mocked return value.

Notice I’ve chosen to use a built-in method that Jest provides for mocking functions: jest.fn(). We could have also passed in a anonymous function instead. However, I wanted to show you this method, since there will be times that a Jest-mocked function will be required for other functionality in our tests to work .

Run the test: npm run test

FAIL  ./id.spec.js
✕ returns a random number (4ms)
● returns a random number
   ReferenceError: getNewId is not defined

Notice we get a reference error just like we should. Our test can’t find our getNewId().

Add the following code above the test.

function getNewId() {
   Math.random()
}

I am keeping the code and testing in the same file for simplicity. Normally, the test would be written in a separate file, with any dependencies imported as they are needed.

FAIL  ./id.spec.js
   ✕ returns a random number (4ms)
   ● returns a random number
   
   expect(received).toBe(expected) // Object.is equality
   Expected: 0.75
   Received: undefined

We failed again with what is called an assertion error. Our first error was a reference error. This second error tells us it received undefined. But we called Math.random()so what happened? Remember, functions that don’t explicitly return something will implicitly return undefined. This error is a good hint that something wasn’t defined such as a variable, or, like in our case, our function isn’t returning anything.

Update the code to the following:

function getNewId() {
   return Math.random()
}

Run the test

PASS  ./id.spec.js
✓ returns a random number (1ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total

Congratulations! We passed our first test.

Ideally, we want to get to our assertion errors as quickly as possible. Assertion errors–specifically value assertion errors like this one, although we will touch on boolean assertions errors in a bit–give us hints to what is wrong.

Specification 2: The number we return is an integer.

Math.random() generates a number between 0 and 1 (not inclusive). The code we have will never generate such an integer. That’s ok though, this is TDD. We will check for an integer and then write the logic to transform our number to an integer.

So, how do we check if a number is an integer? We have a few options. Recall, we mocked Math.random() above, and we are returning a constant value. In fact, we are creating a real value as well since we are returning a number between 0 and 1 (not inclusive). If we were returning a string, for example, we couldn’t get this test to pass. Or if on the other hand, we were returning an integer for our mocked value, the test would always (falsely) pass.

So a key takeaway is if you going to use mocked return values, they should be realistic so our tests return meaningful information with those values.

Another option would be to use the Number.isInteger(), passing our ID as the argument and seeing if that returns true.

Finally, without using the mocked values, we could compare the ID we get back with its integer version.

Let’s look at option 2 and 3.

Option 2: Using Number.isInteger()

test('returns an integer', () => {
   const id = getRandomId();
   expect(Number.isInteger(id)).toBe(true);
});

The test fails as it should.

FAIL  ./id.spec.js
✓ returns a random number (1ms)
✕ returns an integer (3ms)

● returns an integer
expect(received).toBe(expected) // Object.is equality

Expected: true
Received: false

The test fails with a boolean assertion error. Recall, there are multiple ways a test might fail. We want them to fail with assertion errors. In other words, our assertion isn’t what we say it is. But even more so, we want our test to fail with value assertion errors.

Boolean assertion errors (true/false errors) don’t give us very much information, but a value assertion error does.

Let’s return to our wooden table example. Now bear with me, the following two statements might seem awkward and difficult to read, but they’re here to highlight a point:

First, you might assert that the table is blue [to be] true. In another assertion, you might assert the table color [to be] blue. I know, these are awkward to say and might even look like identical assertions but they're not. Take a look at this:

expect(table.isBlue).toBe(true)

vs

expect(table.color).toBe(blue)

Assuming the table isn’t blue, the first examples error will tell us it expected true but received false. You have no idea what color the table is. We very well may have forgotten to paint it altogether. The second examples error, however, might tell us it expected blue but received red. The second example is much more informative. It points to the root of the problem much quicker.

Let’s rewrite the test, using option 2, to receive a value assertion error instead.

test('returns an integer', () => {
   const id = getRandomId();
   expect(id).toBe(Math.floor(id));
});

We are saying we expect the ID we get from our function to be equal to the floor of that ID. In other words, if we are getting an integer back, then the floor of that integer is equal to the integer itself.

FAIL  ./id.spec.js
✓ returns a random number (1ms)
✕ returns an integer (4ms)
● returns an integer
expect(received).toBe(expected) // Object.is equality

Expected: 0
Received: 0.75

Wow, what are the chances this function just happened to return the mocked value! Well, they are 100% actually. Even though our mocked value seems to be scoped to only the first test, we are actually reassigning the global value. So no matter how nested that re-assignment takes place, we are changing the global Math object.

If we want to change something before each test, there is a better place to put it. Jest offers us a beforeEach() method. We pass in a function that runs any code we want to run before each of our tests. For example:

beforeEach(() => {
   someVariable = someNewValue;
});

test(...)

For our purposes, we won’t use this. But let's change our code a bit so that we reset the global Math object back to the default. Go back into the first test and update the code as follows:

test('returns a random number', () => {
   const originalMath = Object.create(global.Math);
   const mockMath = Object.create(global.Math);
   mockMath.random = () => 0.75;
   global.Math = mockMath;
   const id = getNewId();
   expect(id).toBe(0.75);
   global.Math = originalMath;
});

What we do here is save the default Math object before we overwrite any of it, then reassign it after our test is complete.

Let’s run our tests again, specifically focusing back on our second test.

✓ returns a random number (1ms)
✕ returns an integer (3ms)
● returns an integer
expect(received).toBe(expected) // Object.is equality

Expected: 0
Received: 0.9080890805713182

Since we’ve updated our first test to go back to the default Math object, we are truly getting a random number now. And just like the test before, we are expecting to receive an integer, or in other words, the floor of the number generated.

Update our application logic.

function getRandomId() {
   return Math.floor(Math.random()); // convert to integer
}

FAIL  ./id.spec.js
✕ returns a random number (5ms)
✓ returns an integer
● returns a random number
expect(received).toBe(expected) // Object.is equality
Expected: 0.75
Received: 0

Uh oh, our first test failed. So what happened?

Well, because we are mocking our return value. Our first test returns 0.75, no matter what. We expect, however, to get 0 (the floor of 0.75). Maybe it would be better to check if Math.random() gets called. Although, that is somewhat meaningless, because we could call Math.random()anywhere in our code, never use it, and the test still passes. Maybe, we should test whether our function returns a number. After all, our ID must be a number. Yet again, we are already testing if we are receiving an integer. And all integers are numbers; that test would be redundant. But there is one more test we could try.

When it is all said and done, we expect to get an integer back. We know we will use Math.floor() to do so. So maybe we can check if Math.floor() gets called with Math.random() as an argument.

test('returns a random number', () => {
   jest.spyOn(Math, 'floor'); // <--------------------changed
   const mockMath = Object.create(global.Math); 
   const globalMath = Object.create(global.Math);
   mockMath.random = () => 0.75;
   global.Math = mockMath;
   const id = getNewId();
   getNewId(); //<------------------------------------changed
   expect(Math.floor).toHaveBeenCalledWith(0.75); //<-changed
   global.Math = globalMath;
});

I’ve commented the lines we changed. First, move your attention towards the end of the snippet. We are asserting that a function was called. Now, go back to the first change: jest.spyOn(). In order to watch if a function has been called, jest requires us to either mock that function, or spy on it. We’ve already seen how to mock a function, so here we spy on Math.floor(). Finally, the other change we’ve made was to simply call getNewId() without assigning its return value to a variable. We are not using the ID, we are simply asserting it calls some function with some argument.

Run our tests

PASS  ./id.spec.js
✓ returns a random number (1ms)
✓ returns an integer

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total

Congratulations on a second successful test.

Specification 3: The number is within a specified range.

We know Math.random() returns a random number between 0 and 1 (not inclusive). If the developer wants to return a number between 3 and 10, what could she do?

Here is the answer:

Math.floor(Math.random() * (max — min + 1))) + min;

The above code will produce a random number in a range. Let’s look at two examples to show how it works. I’ll simulate two random numbers being created and then apply the remainder of the formula.

Example: A number between 3 and 10. Our random numbers will be .001 and .999. I’ve chosen the extreme values as the random numbers so you could see the final result stays within the range.

0.001 * (10-3+1) + 3 = 3.008 the floor of that is 3

0.999 * (10-3+1) + 3 = 10.992 the floor of that is 10

Let’s write a test

test('generates a number within a specified range', () => {
   const id = getRandomId(10, 100);
   expect(id).toBeLessThanOrEqual(100);
   expect(id).toBeGreaterThanOrEqual(10);
});

FAIL  ./id.spec.js
✓ returns a random number (1ms)
✓ returns an integer (1ms)
✕ generates a number within a specified range (19ms)

● generates a number within a specified range
expect(received).toBeGreaterThanOrEqual(expected)

Expected: 10
Received: 0

The floor of Math.random() will always be 0 until we update our code. Update the code.

function getRandomId(min, max) {
   return Math.floor(Math.random() * (max - min + 1) + min);
}

FAIL  ./id.spec.js
✕ returns a random number (5ms)
✓ returns an integer (1ms)
✓ generates a number within a specified range (1ms)

● returns a random number

expect(jest.fn()).toHaveBeenCalledWith(expected)

Expected mock function to have been called with:

0.75 as argument 1, but it was called with NaN.

Oh no, our first test failed again! What happened?

Simple, our test is asserting that we are calling Math.floor() with 0.75. However, we actually call it with 0.75 plus and minus a max and min value that isn’t yet defined. Here we will re-write the first test to include some of our new knowledge.

test('returns a random number', () => {
   jest.spyOn(Math, 'floor');
   const mockMath = Object.create(global.Math);
   const originalMath = Object.create(global.Math);
   mockMath.random = () => 0.75;
   global.Math = mockMath;
   const id = getNewId(10, 100);
   expect(id).toBe(78);
   global.Math = originalMath;
});

PASS  ./id.spec.js
✓ returns a random number (1ms)
✓ returns an integer
✓ generates a number within a specified range (1ms)

Test Suites: 1 passed, 1 total
Tests:       3 passed, 3 total

We’ve made some pretty big changes. We’ve passed some sample numbers into our function (10, and 100 as minimum and maximum values), and we’ve changed our assertion once again to check for a certain return value. We can do this because we know if Math.random() gets called, the value is set to 0.75. And, when we apply our min and max calculations to 0.75 we will get the same number each time, which in our case is 78.

Now we have to start wondering if this is even a good test. We’ve had to go back in and mold our test to fit our code. That goes against the spirit of TDD a bit. TDD says to change your code to make the test pass, not to change the test to make the test pass. If you find yourself trying to fix tests so they pass, that may be a sign of a bad test. Yet, I’d like to leave the test in here, as there are a couple of good concepts. However, I urge you to consider the efficacy of a test such as this, as well as a better way to write it, or if it’s even critical to include at all.

Let’s return to our third test which was generating a number within a range.

We see it has passed, but we have a problem. Can you think of it?

The question I am wondering is whether we just get lucky? We only generated a single random number. What are the chances that number just happened to be in the range and pass the test?

Fortunately here, we can mathematically prove our code works. However, for fun (if you can call it fun), we will wrap our code in a for loop that runs 100 times.

test('generates a number within a defined range', () => {
   for (let i = 0; i < 100; i ++) {
      const id = getRandomId(10, 100);    
   
      expect(id).toBeLessThanOrEqual(100);
      expect(id).toBeGreaterThanOrEqual(10);
      expect(id).not.toBeLessThan(10);
      expect(id).not.toBeGreaterThan(100);
   }
});

I added a few new assertions. I use the .not only to demonstrate other Jest API’s available.

PASS  ./id.spec.js
  ✓ is working (2ms)
  ✓ Math.random() is called within the function (3ms)
  ✓ receives an integer from our function (1ms)
  ✓ generates a number within a defined range (24ms)
  
Test Suites: 1 passed, 1 total
Tests:       4 passed, 4 total
Snapshots:   0 total
Time:        1.806s

With 100 iterations, we can feel fairly confident our code keeps our ID within the specified range. You could also purposely try to fail the test for added confirmation. For example, you could change one of the assertions to not expect a value greater than 50 but still pass in 100 as the maximum argument.

Is it ok to use multiple assertions in one test?

Yes. That isn’t to say you shouldn’t attempt to reduce those multiple assertions to a single assertion that is more robust. For example, we could rewrite our test to be more robust and reduce our assertions to just one.

test('generates a number within a defined range', () => {
   const min = 10;
   const max = 100;
   const range = [];
   for (let i = min; i < max+1; i ++) {
     range.push(i);
   }
   for (let i = 0; i < 100; i ++) {
      const id = getRandomId(min, max);
      expect(range).toContain(id);
   }
});

Here, we created an array that contains all the numbers in our range. We then check to see if the ID is in the array.

Specification 4: The number is unique

How can we check if a number is unique? First, we need to define what unique to us means. Most likely, somewhere in our application, we would have access to all ID’s being used already. Our test should assert that the number that is generated is not in the list of current IDs. There are a few different ways to solve this. We could use the .not.toContain() we saw earlier, or we could use something with index.

indexOf()

test('generates a unique number', () => {
   const id = getRandomId();
   const index = currentIds.indexOf(id);
   expect(index).toBe(-1);
});

array.indexOf() returns the position in the array of the element you pass in. It returns -1 if the array doesn’t contain the element.

FAIL  ./id.spec.js
✓ returns a random number (1ms)
✓ returns an integer
✓ generates a number within a defined range (25ms)
✕ generates a unique number (10ms)

● generates a unique number

ReferenceError: currentIds is not defined

The test fails with a reference error. currentIds is not defined. Let's add an array to simulate some ID’s that might already exist.

const currentIds = [1, 3, 2, 4];

Re-run the test.

PASS  ./id.spec.js
✓ returns a random number (1ms)
✓ returns an integer
✓ generates a number within a defined range (27ms)
✓ generates a unique number

Test Suites: 1 passed, 1 total

Tests:       4 passed, 4 total

While the test passes, this should once again raise a red flag. We have absolutely nothing that ensures the number is unique. So, what happened?

Again, we are getting lucky. In fact, your test may have failed. Although if you ran it over and over, you’d likely get a mix of both with far more passes than failures due to the size of currentIds.

One thing we could try is to wrap this in a for loop. A large enough for loop would likely cause us to fail, although it would be possible they all pass. What we could do is check to see that our getNewId() function could somehow be self-aware when a number is or is not unique.

For example. we could set currentIds = [1, 2, 3, 4, 5]. Then call getRandomId(1, 5) . Our function should realize there is no value it can generate due to the constraints and pass back some sort of error message. We could test for that error message.

test('generates a unique number', () => {
   mockIds = [1, 2, 3, 4, 5];
   let id = getRandomId(1, 5, mockIds);
   expect(id).toBe('failed');
    
   id = getRandomId(1, 6, mockIds);
   expect(id).toBe(6);
});

There are a few things to notice. There are two assertions. In the first assertion, we expect our function to fail since we constrain it in a way that it shouldn’t return any number. In the second example, we constrain it in a way where it should only be able to return 6.

FAIL  ./id.spec.js
✓ returns a random number (1ms)
✓ returns an integer (1ms)
✓ generates a number within a defined range (24ms)
✕ generates a unique number (6ms)

● generates a unique number

expect(received).toBe(expected) // Object.is equality

Expected: "failed"
Received: 1

Our test fails. Since our code isn’t checking for anything or returning failed, this is expected. Although, it is possible your code received a 2 through 6.

How can we check if our function can’t find a unique number?

First, we need to do some sort of loop that will continue creating numbers until it finds one that’s valid. At some point though, if there are no valid numbers, we need to exit the loop so we avoid an infinite loop situation.

What we will do is keep track of each number we’ve created, and when we’ve created every number we can, and none of those numbers pass our unique check, we will break out of the loop and provide some feedback.

function getNewId(min = 0, max = 100, ids =[]) {
   let id;
   do {
      id = Math.floor(Math.random() * (max - min + 1)) + min;
   } while (ids.indexOf(id) > -1);
   return id;
}

First, we refactored getNewId() to include a parameter that is a list of current ID’s. In addition, we updated our parameters to provide default values in the event they aren’t specified.

Second, we use a do-while loop since we don’t know how many times it will take to create a random number that is unique. For example, we could specify a number from 1 to 1000 with the only number unavailable being 7. In other words, our current ID’s only has a single 7 in it. Although our function has 999 other numbers to choose from, it could theoretically produce the number 7 over and over again. While this is very unlikely, we use a do-while loop since we are not sure how many times it will run.

Additionally, notice we break out of the loop when our ID is unique. We determine this with indexOf().

We still have a problem, with the code currently how it is, if there are no numbers available, the loop will continue to run and we will be in an infinite loop. We need to keep track of all the numbers we create, so we know when we’ve run out of numbers.

function getRandomId(min = 0, max = 0, ids =[]) {
   let id;
   let a = [];
   do {
      id = Math.floor(Math.random() * (max - min + 1)) + min;
      if (a.indexOf(id) === -1) {
         a.push(id);
      }
      if (a.length === max - min + 1) {
         if (ids.indexOf(id) > -1) {
            return 'failed';
         }
      }
   } while (ids.indexOf(id) > -1);
   return id;
}

Here is what we did. We solve this problem by creating an array. And every time we create a number, add it to the array (unless it already in there). We know we’ve tried every number at least once when the length of that array is equal to the range we’ve chosen plus one. If we get to that point, we’ve created the last number. However, we still want to make sure the last number we created doesn’t pass the unique test. Because if it does, although we want the loop to be over, we still want to return that number. If not, we return “failed”.

PASS  ./id.spec.js
✓ returns a random number (1ms)
✓ returns an integer (1ms)
✓ generates a number within a defined range (24ms)
✓ generates a unique number (1ms)

Test Suites: 1 passed, 1 total

Tests:       4 passed, 4 total

Congratulations, we can ship our ID generator and make our millions!

Conclusion

Some of what we did was for demonstration purposes. Testing whether our number was within a specified range is fun, but that formula can be mathematically proven. So a better test might be to make sure the formula is called.

Also, you could get more creative with the random ID generator. For example, if it can’t find a unique number, the function could automatically increase the range by one.

One other thing we saw was how our tests and even specifications might crystalize a bit as we test and refactor. In other words, it would be silly to think nothing will change throughout the process.

Ultimately, test-driven development provides us with a framework to think about our code at a more granular level. It is up to you, the developer, to determine how granular you should define your tests and assertions. Keep in mind, the more tests you have, and the more narrowly focused your tests are, the more tightly coupled they become with your code. This might cause a reluctance to refactor because now you must also update your tests. There is certainly a balance in the number and granularity of your tests. The balance is up to you, the developer, to figure out.

Thanks for reading!

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

Both frameworks and libraries are code written by someone else that is used to help solve common problems.

For example, let’s say you have a program where you plan on working with strings. You decide to keep your code DRY (don’t repeat yourself) and write some reusable functions like these:

function getWords(str) {
   const words = str.split(' ');
   return words;
}
function createSentence(words) {
   const sentence = words.join(' ');
   return sentence;
}

Congratulations. You’ve created a library.

There isn’t anything magic about frameworks or library. Both libraries and frameworks are reusable code written by someone else. Their purpose is to help you solve common problems in easier ways.

I often use a house as a metaphor for web development concepts.

A library is like going to Ikea. You already have a home, but you need a bit of help with furniture. You don’t feel like making your own table from scratch. Ikea allows you to pick and choose different things to go in your home. You are in control.

A framework, on the other hand, is like building a model home. You have a set of blueprints and a few limited choices when it comes to architecture and design. Ultimately, the contractor and blueprint are in control. And they will let you know when and where you can provide your input.

The Technical Difference

The technical difference between a framework and library lies in a term called inversion of control.

When you use a library, you are in charge of the flow of the application. You are choosing when and where to call the library. When you use a framework, the framework is in charge of the flow. It provides some places for you to plug in your code, but it calls the code you plugged in as needed.

Let’s look at an example using jQuery (a library) and Vue.js (a framework).

Imagine we want to display an error message when an error is present. In our example, we will click a button, and pretend an error occurs.

With jQuery:

// index.html
<html>
   <head>
      <script src="https://code.jquery.com/jquery-3.3.1.min.js"
      </script>
      <script src="./app.js"></script>
   </head>
   <body>
      <div id="app">
         <button id="myButton">Submit</button>
       </div>
   </body>
</html>
// app.js
// A bunch of our own code, 
// followed by calling the jQuery library
let error = false;
const errorMessage = 'An Error Occurred';
$('#myButton').on('click', () => {
  error = true; // pretend some error occurs and set error = true
  if (error) {
    $('#app')
       .append(`<p id="error">${errorMessage}</p>`);
  } else {
    $('#error').remove();
  }
});

Notice how we use jQuery. We tell our program where we want to call it. This is much like going to a physical library and pulling certain books off the shelf as we want them.

That’s not to say jQuery functions don’t require certain inputs once we call them, but jQuery itself is a library of those functions. We are in charge.

With Vue.js

//index.html
<html>
   <head>
      <script src="https://cdn.jsdelivr.net/npm/vue"></script>
      <script src="./app.js"></script>
   </head>
   <body>
      <div id="app"></div>
   </body>
</html>
const vm = new Vue({
  template: `<div id="vue-example">
               <button @click="checkForErrors">Submit</button>
               <p v-if="error">{{ errorMessage }}</p>
             </div>`,
  el: '#vue-example',
  data: {
    error: null,
    errorMessage: 'An Error Occurred',
  },
  methods: {
    checkForErrors()  {
      this.error = !this.error;
    },
  },
});

With Vue, we have to fill in the blanks. The Vue constructor is an object with certain properties. It tells us what it needs, and then behind the scenes, Vue decides when it needs it. Vue inverts the control of the program. We plug our code into Vue. Vue is in charge.

The difference whether it is a library or framework is whether or not there is an inversion of control.

A note on being “opinionated”

You’ll often hear frameworks and libraries described as “opinionated” or “un-opinionated.” These terms are subjective. They attempt to define the level of freedom a developer has when structuring their code.

Frameworks are more opinionated than not since — by definition — the inversion of control requires a concession of application-design freedom.

Again, the degree to which something is opinionated is subjective. For example, I personally would consider Angular a highly opinionated framework, and Vue.js a less-opinionated framework.

In summary

• Frameworks and libraries are both code written by someone else that helps you perform some common tasks in a less verbose way.

• A framework inverts the control of the program. It tells the developer what they need. A library doesn’t. The programmer calls the library where and when they need it.

• The degree of freedom a library or framework gives the developer will dictate how “opinionated” it is.

Thanks for reading!

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

The Problem

Imagine having an array and needing to change each element in the array. Maybe, for example, taking an array of heights in inches and needing to convert them to centimeters. Or possibly converting an array of temperatures in Celcius to Fahrenheit. If you are new to programming, your mind might immediately go to some form of a loop. And, guess what? I’m sure you could make it work.

However, I am here to give you one more tool — something to get you just a little closer to elegant: Array.prototype.map().

The map method allows us to transform each element of an array, without affecting the original array. It’s considered a higher-order function and a functional-programming technique because it takes a function as an argument and we are performing computation without mutating the state of our application.

Map is a property that is inherited from the array prototype. Prototypes provide built-in-methods that objects come with (arrays are special types of objects in the eyes of JavaScript). While map may be a little more foreign, this prototype is no different than, for example, the Array.length prototype. These are simply methods that are baked into JavaScript. Array prototypes can be added and mutated by: Array.prototype.<someMethodHere> = ...

By the end of this lesson, we will discover how map works and write our own array prototype method.

So what does .map() do?

Let’s say you have an array of temperatures in Celsius that you want to convert to Fahrenheit.

There are a number of ways to solve this problem. One way may be to write a for loop to create an array of Fahrenheit temperatures from the given Celsius temperatures.

With the for loop we might write:

const celciusTemps = [22, 36, 71, 54];
const getFahrenheitTemps = (function(temp) {
   const fahrenheitTemps = [];
   for (let i = 0; i < celciusTemps.length; i += 1) {
      temp = celciusTemps[i] * (9/5) + 32
      fahrenheitTemps.push(temp);
   }
   console.log(fahrenheitTemps); [71.6, 96.8, 159.8, 129.2
})();

A couple things to note:

1. It works.

2. We use an Immediately Invoked Function Expression (IIFE) to avoid also having to call the function.

3. It’s a bit verbose and not very elegant.

Map allows us to take the above code and refactor it to the following:

const fahrenheitTemps = celciusTemps.map(e => e * (9/5) + 32);
console.log(fahrenheitTemps); // [71.6, 96.8, 159.8, 129.2]

So how does map work?

Map takes a function and applies that function to each element in the array. We could write map a bit more verbose with ES5 to see this a bit more clearly.

const fahrenheitTemps = celciusTemps
   
   .map(function(elementOfArray) {
      return elementOfArray * (9/5) + 32;
   });
console.log(fahrenheitTemps); // [71.6, 96.8, 159.8, 129.2]

If our map function could say what it is doing, it would say:

“For every element in the array, I multiply it by (9/5), then add 32. When that is done, I return the result as an element in a new array called fahrenheitTemps.”

Let’s look at a more common use case. Let’s assume we have an array of people objects. Each object has a name and age key-value-pair. We want to create a variable that is just the names of everyone in the array. With our for loop method we might write:

const people = [
   {name: Steve, age: 32},
   {name: Mary, age: 28},
   {name: Bill, age: 41},
];
const getNames = (function(person) {
   const names = [];
   for (let i = 0; i < people.length; i += 1) {
      name = people[i].name;
      names.push(name);
   }
   console.log(names); // [Steve, Mary, Bill];
})();

With map:

const names = people.map(e => e.name);
console.log(names) // [Steve, Mary, Bill];

Notice here we don’t transform anything, we simply return the key-value-pair name.

Again, the for loops works. But, it is verbose, and we have to create a new custom function every time we want to do a different transformation. A principal part of programming is writing DRY code (Don’t Repeat Yourself). These higher-order functions such as map, allows us to do more complex programming in fewer lines of code than we could without them.

Reinventing the wheel:

To better understand what is happening under the hood, we will make our own map function that we will attach to the array prototype.

First, to attach a prototype method to an Array, we will write:

Array.prototype.<yourMethodHere>

so for us:

Array.prototype.myMap = <our code>

But, what will our code be?

We already have the logic we need from the for loops above. All we need to do is refactor it a bit. Let’s refactor the last function we wrote getNames().

Remember, this function took a person (in other words an element of our array), did a custom transformation to that element (with the for loop and some logic), and returned an array of names (or a new array).

const getNames = (function(person) {
   const names = [];
   for (let i = 0; i < people.length; i += 1) {
      name = people[i].name;
      names.push(name);
   }
   console.log(names); // [Steve, Mary, Bill];
})();

First, let’s change the name of our function. After all, this new method doesn’t assume to know what kind of array it will be acting upon:

const myMap = (function(person) { //Changed name
   const names = [];
   for (let i = 0; i < people.length; i += 1) {
      name = people[i].name;
      names.push(name);
   }
   console.log(names); // [Steve, Mary, Bill];
})();

Second, we are creating our own version of .map(). We know this will take a function that the user provides. Let’s change the parameter our function takes:

// It is a bit verbose, but a very clear parameter name
const myMap = (function(userProvidedFunction) { 
   const names = [];
   for (let i = 0; i < people.length; i += 1) {
      name = people[i].name;
      names.push(name);
   }
   console.log(names); // [Steve, Mary, Bill];
})();

Finally, we have no idea what array this method will act on. So, we can’t refer to people.length but we can refer to this.length. this, will return the array the method is acting on. Also, let's clean up some of the other variable names:

const myMap = (function(userProvidedFunction) { 
   // change variable name
   const newArr = [];
   // use "this.length"   
   for (let i = 0; i < this.length; i += 1) { 
   
      // use "this[i]", and change variable name      
      const newElement = this[i];
  
      // update the array we push into
      newArr.push(newElement); 
   }
   // Return the newly created array
   return newArr; 
})();

We’re almost there, but there is one thing we are forgetting. We haven’t transformed the array! All we’ve done above is return the old array. We have to apply the user-provided function to each element of the array:

const myMap = (function(userProvidedFunction) { 
   const newArr = [];
   for (let i = 0; i < this.length; i += 1) {
      
      /* Transform the element by passing it into the 
       * user-provided function
       */
      const newElement = userProvidedFunction(this[i]); 
      
      newArr.push(newElement); 
   }
   return newArr;
})();

Finally, we can attach our new function toArray.prototype.

Array.prototype.myMap = myMap;

A final sanity check:

const myArray = [1, 2, 3];
// Multiply each element x 2
const myMappedArray = myArray.myMap(e => e * 2)
console.log(myMappedArray) // [2, 4, 6];

Summary

Map is a prototype method offered by arrays. Behind the scenes, it iterates through the array, applying a user-provided function to each element. Ultimately, it returns a new array with the transformed values. It does this without mutating the original array. Because the parameter it takes is a function, it is considered a higher-order function. In addition, its use falls into the functional programming paradigm.

Thanks for reading!

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.