DEV Community: Fernando Doglio

Getting Started with the Django Stack: Create a Full Project

Fernando Doglio — Tue, 15 Oct 2024 10:23:40 +0000

If you're new to the Python world, and you're wondering what the heck Django is, here's an article that might help as a practical introduction.

Django is like that toolkit you wish you always had. It makes building powerful, scalable web applications not only possible but genuinely fun. And guess what? You don’t need to be an expert to get started.

In this guide, we're going to take a hands-on approach to create a complete Django project from scratch. By the end, you'll have your own fully functioning web app that you can tweak and improve. Let's dive right in!

For a detailed overview of the Django stack, you can visit this page on Code Clash.

Prerequisites

Before you get started, you'll need a few things installed on your computer:

Python 3.x: Django requires Python 3.x to work properly.
pip: This is Python's package manager, and you'll use it to install Django and other packages.
Virtualenv (optional but highly recommended): It helps you create isolated environments so you can keep the dependencies of different projects separate.

If you don’t have Python yet, you can download it from python.org.

Step 1: Set Up Your Environment

First things first—we need to set up a virtual environment for our Django project. This will keep all our project dependencies in one place and ensure they don't interfere with other projects on your system.

To create a virtual environment, run the following command:

# Create a virtual environment
python -m venv myenv

# Activate the virtual environment
# On Windows
myenv\Scripts\activate

# On macOS/Linux
source myenv/bin/activate

Once your virtual environment is activated, go ahead and install Django:

pip install django

And just like that, you’re ready to start building!

Step 2: Create a New Django Project

Let’s kick off by creating a new Django project. Run the following command to create the project:

django-admin startproject myproject

This command will generate a new directory called myproject, and it will contain the following structure:

myproject/
    manage.py
    myproject/
        __init__.py
        settings.py
        urls.py
        asgi.py
        wsgi.py

manage.py: A script that helps you manage the project (e.g., starting the server, migrating databases).
settings.py: Contains all the configuration settings for your Django project, like database info and installed apps.
urls.py: Where you map URLs to their corresponding views.

Step 3: Run the Development Server

Okay, time to see if everything is working. Navigate into your project folder and start the development server:

cd myproject
python manage.py runserver

Now, open your browser and go to http://127.0.0.1:8000/. You should see the default Django welcome page, complete with a rocketship. This means your project is up and running—awesome!

Step 4: Create a Django App

Django projects are like big boxes, and inside those boxes, we have smaller boxes called "apps." Apps are modular components of your project, like a blog, a user authentication system, or an e-commerce module.

Let’s create an app called blog by running this command:

python manage.py startapp blog

This will create a new folder named blog containing files like views.py, models.py, and others to help you organize your code.

To let Django know about your new app, add 'blog' to the INSTALLED_APPS list in myproject/settings.py:

INSTALLED_APPS = [
    ...
    'blog',
]

Step 5: Define Models

A model in Django is simply a Python class that defines how your data is structured. Open blog/models.py and define a simple model for a blog post:

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()
    date_created = models.DateTimeField(auto_now_add=True)

title: A short text field for the post title.
content: A longer text field for the post content.
date_created: Automatically stores the date when the post is created.

Now, we need to apply these changes to our database by running the following commands:

python manage.py makemigrations
python manage.py migrate

These commands will create the necessary database tables for the Post model.

Step 6: Create Views and Templates

A view is where the logic happens. It takes a request and returns a response, often rendering an HTML page. Let’s create a view to display all blog posts. Open blog/views.py and add:

from django.shortcuts import render
from .models import Post

def home(request):
    posts = Post.objects.all()
    return render(request, 'blog/home.html', {'posts': posts})

This home view retrieves all the posts from the database and sends them to a template called home.html.

Next, let’s create the template. Inside the blog/ directory, create a folder called templates/blog/ and add a file named home.html:

<!DOCTYPE html>
<html>
<head>
    <title>Blog Home</title>
</head>
<body>
    <h1>Blog Posts</h1>
    {% for post in posts %}
        <div>
            <h2>{{ post.title }}</h2>
            <p>{{ post.content }}</p>
            <small>Published on: {{ post.date_created }}</small>
        </div>
    {% endfor %}
</body>
</html>

This HTML code will display all the posts with their title, content, and creation date.

Step 7: Set Up URL Routing

Now, we need to set up URL routing to connect the views to the right URLs. In the blog/ directory, create a file named urls.py (if it doesn't exist) and add:

from django.urls import path
from . import views

urlpatterns = [
    path('', views.home, name='blog-home'),
]

Then, include the blog URLs in the main project’s urls.py file:

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('blog.urls')),
]

This way, when someone visits the root URL, Django will serve the home view from the blog app.

Step 8: Test Your Application

You’re almost there! Let’s run the server again and see if our blog works:

python manage.py runserver

Go back to http://127.0.0.1:8000/ in your browser, and you should see a list of all your blog posts—congratulations, you’ve built your first Django app!

Additional Resources

Django Documentation - The official documentation is a treasure trove of information and examples.
Python-Anaconda Stack - Learn how Python can be used with Anaconda for data science.
Best Frameworks for Web Development - Explore the best web development frameworks, including Django.

Conclusion

In this guide, we walked through setting up a Django environment, creating a new project, and building a simple blogging app. Django has a lot of built-in features that make web development faster and easier, so you can focus on building what matters most. If you’re ready for more, check out Code Clash’s Django Stack page to dive deeper into the world of Django.

Happy coding, and welcome to the Django community!

Is the MERN Stack Still Valid?

Fernando Doglio — Wed, 09 Oct 2024 11:47:25 +0000

Remember when the MERN stack was the Beyoncé of web development stacks? It was everywhere, and if you weren’t using it, you were probably missing out on some secret sauce.

But here we are in 2024, and it’s time to ask the question that’s been on the minds of developers everywhere: Is the MERN stack still relevant, or has it become the MySpace of web development?

What is the MERN Stack?

The MERN stack is a full-stack development bundle that combines four powerful technologies, all revolving around JavaScript. It allows developers to build robust, dynamic web applications using a single programming language from the front end to the back end, simplifying the development process and improving efficiency.

Let’s break down each component:

MongoDB:
Serving as the database layer, MongoDB is a NoSQL database known for its flexibility and scalability. Unlike traditional SQL databases that use tables and rows, MongoDB stores data in a JSON-like format called BSON (Binary JSON). This makes it particularly adept at handling large amounts of unstructured data and allows developers to store complex data structures without needing to define a schema upfront. This flexibility is one of the reasons MongoDB became the go-to choice for many developers looking for a more adaptable database solution.
Express.js:
This is the web application framework sitting on top of Node.js, providing a set of robust features for building web and mobile applications. Express makes it simpler to write server-side code, offering a lightweight and minimalistic structure that doesn’t impose too many restrictions on how you organize your app. It provides essential functionality like routing, middleware support, and templating engines, allowing developers to create APIs and handle HTTP requests and responses efficiently.
React:
React is the “R” in MERN and arguably the star of the stack when it comes to front-end development. Created and maintained by Facebook, React has revolutionized how we build user interfaces with its component-based architecture. It allows developers to build reusable UI components that manage their own state, resulting in a more organized and efficient way to develop complex, interactive user interfaces. React’s virtual DOM and one-way data flow contribute to its high performance, making it a popular choice for building dynamic, high-performing web apps.
Node.js:
The “N” in MERN stands for Node.js, a runtime environment that allows you to run JavaScript on the server side. Before Node.js, JavaScript was confined to the browser, but with the introduction of Node, developers could now use JavaScript to write server-side code. Node.js is built on the V8 JavaScript engine (the same engine used in Chrome) and is known for its non-blocking, event-driven architecture, making it ideal for building scalable network applications. Its ability to handle multiple connections concurrently without blocking makes it perfect for real-time applications like chat apps and online gaming.
The beauty of the MERN stack lies in its unified language across the stack. This means developers can use JavaScript everywhere, from querying the database with MongoDB to managing the server with Express and Node.js, to building interactive user interfaces with React. This homogeneity reduces the need for context switching between languages, leading to a more streamlined and efficient development process. It’s no wonder the MERN stack has been a favorite among startups and small teams looking to build full-featured web applications quickly and efficiently.

But as the web development landscape evolves, it’s important to question whether sticking to this tried-and-true stack is the best choice moving forward.

The Current State of the MERN Stack

So, how does the MERN stack fare in today’s rapidly changing development landscape?

Pros:

Unified Language:
JavaScript rules both the client and server sides, reducing context switching and making development more streamlined.
Vast Ecosystem:
The community around the MERN stack is massive, providing countless libraries, tools, and resources.
Active Support: From numerous tutorials to extensive documentation, getting help with MERN-related issues is relatively easy.

Cons:

Performance Bottlenecks: While great for many applications, the MERN stack can run into performance issues, especially with complex, data-heavy apps. Scaling Challenges: As applications grow, scaling can become a headache, often requiring additional tools and infrastructure. Rise of New Technologies: With new stacks and frameworks emerging, MERN is no longer the shiny new toy in the playground.

Alternatives and Modern Trends

In the world of web development, alternatives are plenty. Let’s briefly look at some of the contenders:

MEVN Stack: A slight twist on MERN, replacing React with Vue.js. For those who prefer Vue’s simplicity and ease of integration, this is an attractive option. Learn more about MEVN MEAN Stack: Another popular variant, using Angular instead of React. It’s known for its robustness and extensive tooling. Check out MEAN
JAMstack:
A modern approach emphasizing performance and scalability by decoupling the front-end from the back-end. Perfect for static sites and dynamic apps, JAMstack is all about speed and security. Dive into JAMstack
Other trends are also changing how we build web applications, including:
Next.js:
Offering server-side rendering and static site generation for React apps, making it a powerful tool for building fast, SEO-friendly applications.
Serverless Architectures:
Reducing the need to manage servers, allowing developers to focus more on code and less on infrastructure.
Microservices:
Breaking applications into smaller, independent services for better scalability and maintainability.

When to Use the MERN Stack

While the MERN stack may not be the shiny new tech on the block anymore, it still has its place in the developer toolkit. It’s not about whether the MERN stack is the “best” option, but whether it’s the right fit for the specific needs of your project. Here are some scenarios where the MERN stack shines and is worth considering:

Rapid Prototyping and Development:

Startups and MVPs: If you’re building a Minimum Viable Product (MVP) or a prototype to test an idea quickly, MERN is a solid choice. The stack allows for rapid development due to its simplicity and the fact that developers can use JavaScript across the entire stack. This unified language approach speeds up the development process, making it easier to get your product to market quickly.
Iterative Development: MERN is great for projects that require frequent updates and iterations. With React’s reusable components and MongoDB’s flexible schema, you can easily modify your application as new requirements arise or user feedback is gathered.
Single Page Applications (SPAs):
Dynamic and Interactive UIs: If your project involves building a highly interactive Single Page Application (SPA) where user experience and responsiveness are paramount, React within the MERN stack is an excellent choice. React’s virtual DOM and efficient rendering make it well-suited for applications that require real-time updates without refreshing the page.
Complex Front-End Logic: For apps that need to handle complex front-end logic, React offers a structured way to manage state and components. This makes it easier to develop and maintain intricate user interfaces, like dashboards or data visualization tools.

JavaScript-Centric Projects:

Unified Language Across the Stack: If your development team is well-versed in JavaScript and prefers to stick to a single language across the entire application, MERN is ideal. This minimizes context switching between different programming languages and can streamline the development process. It’s also beneficial for smaller teams or individual developers who want to manage both the front-end and back-end without learning additional languages.
Full-Stack JavaScript: Projects that aim to leverage the power of JavaScript on both the client and server sides will benefit from the MERN stack’s capabilities. This can lead to a more consistent and cohesive codebase, easier debugging, and faster development.

Flexible Data Structure Needs:

Dynamic and Evolving Data Models: If your application deals with data that doesn’t fit neatly into a traditional SQL schema or is subject to change frequently, MongoDB’s document-oriented database is a strong choice. Its flexible schema allows you to store complex data types without the need for predefined structures, making it ideal for projects where the data model is expected to evolve over time.
High Data Variety: Applications that need to store diverse types of data, such as user profiles, content management systems, or IoT data, can benefit from MongoDB’s ability to handle various data formats and types with ease.

Small to Medium-Sized Projects:

Scalability at a Modest Scale: MERN is well-suited for small to medium-sized applications where scalability is required but not to an extreme level. It can handle a fair amount of traffic and data if set up correctly, making it suitable for applications like blogs, e-commerce platforms, and social networking sites with a moderate user base.
Resource-Conscious Development: For teams or organizations with limited resources, the MERN stack offers an efficient way to build a complete web application without the need for a large team or extensive infrastructure. Its open-source nature and large community support also mean you can find plenty of free resources and libraries to enhance your project.

Projects Requiring Reusable Components:

Modular Development: React’s component-based architecture allows you to build reusable UI components, which can save development time and effort. If your project can benefit from modular design, where elements like buttons, forms, and navigation can be reused across different parts of the application, the MERN stack’s React component system is a major advantage.
Consistent User Interfaces: For applications that need a consistent look and feel across various sections or features, React makes it easier to maintain uniformity by reusing components and ensuring consistent styling and behavior.

When to Look Elsewhere

However, the MERN stack isn’t a one-size-fits-all solution. There are situations where you might want to consider other options:

High-Performance Requirements: If your application demands the utmost performance, such as in high-frequency trading platforms or real-time analytics, other stacks or technologies might offer better optimization and speed.
Heavy Data Processing: For applications that need to handle complex data processing or transactions, a relational database like PostgreSQL or a stack specifically tailored for heavy data manipulation might be more suitable.
Scalability Concerns: If you’re building an application that expects to scale massively, such as a large-scale social media platform or a cloud-based service with millions of users, you might encounter challenges with MERN’s scalability. In such cases, microservices architecture or a more robust backend solution might be preferable.
In other words, the MERN stack is still a valid choice for many scenarios, especially when you need to move quickly and efficiently with a JavaScript-centric approach. But like any tool, it’s essential to evaluate it against your project’s unique needs and constraints before diving in.

Is the MERN Stack Here to Stay?

That’s the question, isn’t it?

The MERN stack has shown a remarkable ability to adapt and remain relevant. With a huge community and a wealth of resources, it’s still a great way for new developers to learn full-stack development using JavaScript.

Plus, it’s not like MongoDB, Express, React, or Node.js are going away anytime soon; they’re all still evolving and improving.

So give it a try! (maybe?)

Conclusion

So, is the MERN stack still valid? Absolutely, but with caveats. While it’s no longer the only player in town, it remains a solid choice for certain projects and use cases. It’s particularly great for developers looking to leverage their JavaScript knowledge across the full stack.

But as with any technology decision, it’s crucial to assess the specific needs of your project. If you’re curious to see how other stacks compare or want to join in on the debate, check out Code-clash.net for more insights on stack wars and modern development trends.

Whether you’re team MERN, JAMstack, or something else entirely, the key is finding the right tool for the job.

Code for People, Not for Machines - A Glimps into my Newest Book

Fernando Doglio — Wed, 19 Jan 2022 06:59:18 +0000

I know this advice can sound counterintuitive, but when you write code you can’t think about the interpreter or the compiler or how it’ll translate into machine code. This isn’t your concern, instead, you should focus on who is going to read it tomorrow.

Even if you think no one else will read your code but you, the focus must still be the same. Coding sometimes requires us to come up with intricate solutions and trust me, they won’t always make sense the next day, even if you’re the one who wrote them.

Let’s pretend your new feature PoC works well and you and your team are now faced with the task of implementing its full version.

You’ll do two months of coding, and not only you, but three of your teammates will work on it, which means four developers writing code for the same feature. This causes people to interact with each other, and to write on each other’s files; this is completely normal and expected. Two days after starting to work on it, you find you and your team having daily meetings to review each other’s work to understand how your logic works.

As a result, you all spend a lot of time understanding code instead of writing it, and your Tech Lead asks all of you for an alternate solutions to your meetings. Something that you all can do that solves this problem now and for the rest of the project’s duration.

What would be your suggestion?

Self-documenting code doesn’t exist

One terrible solution some developers suggest to this problem is to write code that avoids complex logic solutions, using mnemotechnic variable and function names (i.e. instead of using foo and bar, they’ll use monthly_revenew and current_index). They say the code will be clean and easy to read, they say that the code itself can be the documentation. Mind you, this is indeed a good practice and something you should aim for, but by itself it’s not enough.

I’m afraid to say it but this is like asking Santa for a unicorn. It’s just not realistic, no matter how you look at it.

You’ll probably last a few days and then when deadlines hit or the weekend is close and you want to go home, user_with_too_many_logins becomes foo, and like that the whole self-documenting plan goes away.

Whatever solution you come up with needs to scale with code density and it needs to stay working over long periods of time. Saying you’ll document it eventually is not going to work because documenting two months’ worth of code is a massive task. A solution that takes more time than writing the code won’t work either. You must find a balance between the two.

Let me show you a few options and you pick the one that works best for you and your context. Whichever you choose to use, consider the following: it’s all about reducing the cognitive load of the person reading your code.

To put it another way, you need to remember that code is meant to be parsed into machine code and it has a particular structure, but people don’t parse and think the same as a machine parses code. We’re slower, and our memory is faulty, and when reading large chunks of code, we tend to get lost in the logic, and forget about where a piece of data is coming from. Whatever solution you choose to implement should help in that regard.

Commenting your code

This is the most obvious one, 99.99% of all programming languages support comments (I’m not going 100% because I’m sure there are a few esoteric languages out there that don’t bother with comments).

You can’t be satisfied with writing them, they need to make sense, be useful and stay updated.

Take a look at the Listing 1 and the great line of comment I left for you.

Listing 1: Sample log-in function for our fictional log-in form

    //log-in function
    async function performLogin(username, password, database) {
        let user = await database.query("select * from users where usr_name ='" + username + "' and password = '" + password + "'")
        if(!user) {
            return null
        }
        user.last_login = new Date()
        await user.save()
        return user
    }

This could be a piece of logic for the new feature you’re working on. Granted, it’s not clean and it’s quite a simplistic approach but look at that useful comment at the top. Would you say that by reading it, you’re able to understand how to use the function? Or what it’s meant to do?
That line of comment literally serves no purpose, and the sad thing is I’ve seen comments like that countless times (heck, I’ve even written comments like that back in the day too).
For a comment to be useful and provide real help diminishing the cognitive load I mentioned before, it needs to:

Add value to the reader. What is value? Anything the reader can’t know by looking at the function’s signature, or by looking at the line of code that the comment is meant to explain. If we’re dealing with a comment for a block of code, explain the internal logic and mention the steps involved in the process. Why not even add extra information you couldn’t possibly have otherwise, like types for your variables in JavaScript code? Are you commenting on a function or a method that returns something? Make sure you mention the returned value, what is it? What type is it? Anything and everything someone else trying to use your code might need must be explained, otherwise, it’s back to asking people or making mistakes.
Be up-to-date. Reading an outdated comment and hoping it’ll help you figure out the code is as realistic as looking at the night sky and thinking the stars you’re seeing look like that right now. Any of them could’ve gone supernova already and you won’t find out in thousands of years. The same goes for the comments, if they’re not updated when the code is, then you’re reading an explanation for an older version which only helps to add confusion and bugs to the mix. If you’re updating code make sure you update the associated comments, and future you can thank you for it.

Some formatting standards can be used when writing comments that can be picked up by other tools, such as your IDE or documentation generation tools. These tools take the code and its comments, and mix them to better understand the code.

Look at figure 1 for a second.

Figure 1: Comparing the effects properly formatted comments have on your IDE

Notice how the tooltips generated by the same code differ when a properly formatted comment is added into the mix. This is JavaScript code and the comments are following JSDocs standards. These standards tell you how to format your comments with a structure that a machine can then parse and get useful information out of. You clearly identify things such as variable types and names, return types, descriptions, and more, and then, in our case, the IDE parses it and show an informative tooltip.

You have the equivalent for other languages too, this isn’t only for JavaScript. Make sure to look for these standards for whatever language you use on your journey and apply them to your commenting practices. They won’t solve all your problems, but they’ll definitely help quite a lot.

You may not be right now, but eventually you’ll be part of a team of developers all working towards the same goal. The thing is, unless you’re all forced to, not everyone’s code will follow the same standards.

The language itself sets a syntax you need to follow and maybe the framework you use forces you to use one particular set of patterns in your code, but you still have a lot of wiggle room to add your own coding style. This isn’t a problem if everyone on the team has a similar style, but many aspects can change from developer to developer and unless someone sets a universal standard to follow, it can get messy.

A programming paradigm used by some frameworks (made popular by Ruby on Rails back in the day) is called “Convention over configuration” and it means you should expect to have “sensible default” behavior and only care about creating specific code for a section of your logic if that expected default is not met. For example, having a class representing a database table on your code, if that class is called “Notes” then you’d expect the table to have the same name and your class to have one property for each field on the table (again, aptly named and typed). Only if for some reason that expectation isn’t met, you’ll have to jump in and write the required code to map the values or whatever you need to make the class work between both worlds (this is your internal logic and the database structure).

Why am I suddenly talking about convention over configuration? Because you should expect your team and your coding standards to work the same way. Reading someone else’s code should feel like you’re reading your own. This helps alleviate some of the cognitive load associated with parsing code mentally to understand what it’s trying to do.

For example, having a set of standards that tell you:
● How to name your variables (for instance: always using English words and a camel-case notation or using specific prefixes to identify their type without having to look-up their definition). This by itself isn’t enough to document your code, but it’s a good starting point.
● How to perform specific minor tasks (such as comparing two values always with === instead of using == sometimes).
● The maximum length of a line of code (normally they force it to be eighty characters, which corresponds to the eighty characters terminals normally allow for).
● How to name your files or where to save them (such as having a specific folder where all common code should live).

I could go on, but you get the point. These standards are there to keep you from thinking about the meager tasks and worry about the important job of solving your problem. Mind you, these standards can be opinionated, after all, they’re likely coming from a single person (your tech lead). This is fine because you don’t have to worry about agreeing with them, but you must use them, like if you’re joining the team after it’s been working together for a while.

The good news is that there are tools known as “linters” that can help you check for these standards in your code. They’re normally included on your IDE or can be configured to run on pre-deployment or pre-merge events, making sure you’re not sending code which isn’t following the right conventions.

Coding standards are a great way to writing code which is easier to read by someone on your team, even if that someone comes years after you and you’re no longer working for the company. Granted, standards alone won’t make your code readable, but they are the equivalent of finding three different notes written in English, one from the year 1300, one from 1920, and one from last year. They’re all written in English but with slightly different styles; by translating them to the modern version of the language (i.e. forcing the same standard on all three of them), you (and everyone else from today) will have an easier time reading them.

A case for Literate Programming

Remember when I said earlier that there’s no such thing as self-documenting code? Well, hold my beer, because I’m about to go against my own words, kind of.

Literate programming is a programming paradigm that allows you to write code and documentation at the same time.

You see, what normally happens is that you first write your code and then write the documentation based on it. You could, potentially, go the other way around and with the documentation written use it as the development blueprints to create the code.

With Literate programming you write both at the same time. You create an explanation around your logic and show snippets of your code. This resulting documentation is processed and the working code is created and saved to one location, and at the same time a dynamic version of this documentation (i.e. normally an HTML version) is saved somewhere else.

To give you a quick example, pretend you’re building a JavaScript library meant to provide you with two functions: mult and div (multiplication and division). Following literate programming, you can write a document like shown in Listing 2.

Listing 2: The markup version of our documentation/source code

    ..    include:: <isoamsa.txt>                            
    ..    include:: <isopub.txt>

    Introduction
    -------------
    This is a sample documentation for a very simple JavaScript function

    MULT function
    --------------
    The MULT function requires two different parameters `a` and `b`, both numbers ideally.

    @o my-math-lib.js
    @{
    function mult(a, b) {
       return a * b
    }
    @}

    DIV function
    -------------
    The DIV function takes care of dividing `a` with `b` whenever possible.

    @o my-math-lib.js
    @{
    function subtract(a, b) {
        @<validate parameters@>
        return a / b
    }
    @}

    Value validation for the division
    ------------------------------
    Because one can't correctly divide a number by 0 (or a non-numeric or undefined value for that matter) using JavaScript, the following
    code takes care of checking for the value of `b`:

    @d validate...
    @{if(typeof b == "undefined" || isNaN(b) || b == 0) {
        return 0
    }@}

As you can appreciate, there’s no one place where our code resides all together and organized; I’m splitting the code into three different chunks. Two of them are marked to be outputted to the same file (my-math-lib.js) and the third one is marked as a code snippet to include inside other sections.

The main benefit around this way of working is that you need to make a mental switch from only writing code (or only writing documentation) and need to think about both at the same time. The end result, when done properly, is a much richer documentation filled with examples, and the code is less prone to error because you’ve already thoroughly explained what it’s meant to do.

Originally introduced by Donald Knuth around 1984, this programming paradigm is great for small coding projects. Normally you’d want to create detailed documentation filled with examples for things like libraries and tools for other developers to use. These projects normally tend to be smaller than say, creating the internal intranet for the whole company.

The way it works is:

You write everything together using a markup language (depending on the implementation, it can be Markdown, LeX, or something similar).
You need specific custom tags to use across the text to signal elements such as code snippets, import statements (to split your writing into multiple files), and other elements that allow you to reuse blocks of text in different places.
You’ll weave all the snippets together into the final source code.
And finally, you’ll tangle the snippets and written documentation into an HTML file that acts as the user-facing documentation.

Don’t worry too much about the weaving and tangling phases (the last two steps), because they’ll be taken care of by pyWeb, the tool we’ll use to parse the code from Listing 2.

As a result of using it, we get two files: my-math-lib.js which as you can see in Listing 3, it’s full-on JavaScript without any extra documentation, and my-math-lib.html which is the dynamic documentation.

Listing 3: Final version of our code, without any extra documentation

    function mult(a, b) {
        return a * b
    }

    function subtract(a, b) {
        if(typeof b == "undefined" || isNaN(b) || b == 0) {
          return 0
        }
        return a / b
    }

Figure 2 shows the tangled version of the same file, this time rendered as interactive HTML.

Figure 2: The tangled version of the documentation, mixing code and comments

The HTML is pre-formatted by default, but you can edit it and its stylesheet to make it look any way you like. The point here is that the hardest part, which is writing the HTML to publish somewhere is already done for you. Changing styles to make it look better is a minor hustle in comparison.

Is this the answer to all our documentation problems? Does this programming paradigm change the way we work and write our code? I don’t think it does because larger projects still require a focus on the code and folder structure that Literate programming can’t provide. Smaller ones though, such as libraries and small frameworks, can take advantage of it without seeing their coding workflow changed that much. It’s definitely an interesting alternative compatible with all programming languages, and a great option if you’re looking to save some time writing documentation.

Readable code >> one-liners

Although documentation in all its forms is crucial to helping people understand how code works, there’s something to be said about the way you write your code. Sometimes a single line of code might require several paragraphs of documentation because it’s too optimized and minified that mentally parsing it takes too long. This is plain unacceptable in most situations.

Unless you’re writing embedded code for resource-constrained devices, saving characters and writing doesn’t yield huge benefits. Consider, instead, writing the same solution for human beings and machines alike (i.e. code that works, but which is a lot easier to read). Check out Listing 4 for an example of what I mean by that.

Listing 4: Readable vs optimized code

    salaries = {
      "You": 100000,
      "Sarah Connor": 90000,
      "John Doe": 100000,
      "Laura Micheals": 60000,
      "Mike Tyson": 35000
    }

    def who_makes_the_most():                                                            # A
      dict_sal = salaries.copy()
      high_sal = 0
      for name in dict_sal:
        dict_sal[name] = dict_sal[name]
        if dict_sal[name] > high_sal:
          high_sal = dict_sal[name]

      high_paid_emp = []
      for name in dict_sal:
        if dict_sal[name] == high_sal:
          high_paid_emp.append(name)

      return high_paid_emp


    def who_makes_the_most_v2():                                                         # B
      return [emp for emp in salaries if salaries[emp] == max([sal for sal in salaries.values()])]

    print who_makes_the_most()
    print who_makes_the_most_v2()

    #A - Version 1, calculate who makes the most money at the company. Verbose and understandable version.
    #B - Version 2, calculate who makes the most money with a reduced and harder-to-read function.

Both versions of the same function in Listing 4 yield the same result, but one requires a single line of code yet the other eleven. Is V2 better than the original? This is a subjective question to answer. A team of expert Python developers with many years of experience doesn’t need a lot of time to read the one-liner function, but the moment someone new comes in with the intention of editing or expanding on it, that person will face some issues. This isn’t only because the function is a lot harder to understand, but the fact that it’s been reduced to a single line with the same amount of functionality means the complexity has been packed into specific constructs.

In the case of this example, there are two list-comprehension expressions nested and a call to the max function. If we want to keep adding logic into our code, for example, upper casing the names and removing the first names from the returned values, we need to expand our one-liner function, making it harder to read and adding an in-line check for scenarios with no last names. Listing 5 shows how the new functions grow based on this added complexity:

Listing 5: Example from Listing 4 expanded with added logic

    def who_makes_the_most():                     # A 
      dict_sal = salaries.copy()
      high_sal = 0
      for name in dict_sal:
        dict_sal[name] = dict_sal[name]
        if dict_sal[name] > high_sal:
          high_sal = dict_sal[name]

      high_paid_emp = []
      for name in dict_sal:
        if dict_sal[name] == high_sal:
          name_parts = name.upper().split(' ')
          if len(name_parts) == 2:
            high_paid_emp.append(name_parts[1])
          else:
            high_paid_emp.append(name_parts[0])

      return high_paid_emp


    def who_makes_the_most_v2():   # B
      return [emp.split(' ')[-1].upper() for emp in salaries if salaries[emp] == max([sal for sal in salaries.values()])]

    #A - Version 1 with extra logic added into it
    #B -  Version 2 of the same function turned into a longer line

You can see how the code from the original function remains a lot easier to mentally parse. You’ve a clear place where you can check whether there are last names to use and what to do if there aren’t. With the one-liner, we resorted to using index -1, which if you don’t know what it means, it references the first element starting from the end of the list (the last one). This works, but using negative indexes on arrays is something not everyone is comfortable with and requires you to understand how Python specifically deals with them.

Again, both functions do the same, but with this basic example, you can see how we still manually translate the packed logic instead of letting you read it.

Granted the longer function could also be simplified and still maintain a better readability than V2, but the point here’s to show you both extremes. You shouldn’t aim for either, you should aim for something in-between, something like Listing 6 below.

Listing 6: A new version, capturing the best of both worlds

    def who_makes_the_most_v3():
      dict_sal = salaries.copy()
      high_sal = max(dict_sal.values())

      high_paid_emp = []
      for name in dict_sal:
        if dict_sal[name] == high_sal:
          name_parts = name.upper().split(' ')
          if len(name_parts) == 2:
            high_paid_emp.append(name_parts[1])
          else:
            high_paid_emp.append(name_parts[0])

      return high_paid_emp

We get rid of the first for loop, because there’s already a function that does this for us: max. We’ve kept the “complex” section of our logic intact and expanded because it’s a lot easier to read that way.

With all of this being said, you need to remember one thing: readable code doesn’t substitute documentation, they complement each other. You still need to document your algorithm and explain why you’re doing what you’re doing. Writing readable code can help you avoid documenting some sections in detail, which saves you a bit of time.

Understandable code is no excuse to overcomplicate a solution. Consider this as you try to make your code easy to read--you can also fall for a common trap: overengineering.

That’s all for this article. If you want to learn more about the book, check it out on Manning’s liveBook platform here.

From Skills of a Successful Software Engineer by me
When writing code, you need to write it with people (rather than machines) in mind. Without good notes and documentation, others who read your code might have to spend a lot of time trying to understand it before they can begin to work with it.

Take 35% off Skills of a Successful Software Engineer by entering fccdoglio into the discount code box at checkout at manning.com.

Starting a New Side Project in 2022? Look Beyond Coding

Fernando Doglio — Fri, 07 Jan 2022 12:00:47 +0000

For some reason, developers are starting to wear the number of unfinished side projects as a badge of honor: the more the better. They get the idea, buy the domain name, throw down some lines of code, and a few weeks later, they get excited about a new idea and leave the other one to rot.

Why do you think that is? I know why I used to do it: I used to think with my code, instead of properly planning my projects.

Whenever I had a new idea, I would start turning my thoughts into code without hesitation. But that’s not the right way to do it, is it? By the time a new shiny idea arrived, I was elbow deep in code, dealing with my business logic.

And so I had to decide: New project from scratch vs. continue dealing with a problem I don’t know how to solve? The decision was easy, and the outcome the expected: I was incapable of finishing a single side project.

So, let’s take a look at what it means to tackle a side project correctly and what else needs to happen besides actually coding the damn thing.

Control the Urge the Start Coding and Make a Plan Instead

Whenever a new idea hits, you have to keep yourself from coding. Not for long, but there are a few tasks you need to take care of before you get to that part.

Coding is the “fun” part, I know, but coding without a plan is the worst thing you can do for your project.

To create a plan:

Decide on what you’re building.
Make a list of features. It doesn’t have to be detailed, but at least a bullet list of points you want to cover.
Out of that list, decide on the bare minimum that needs to be implemented and which ones would be “nice to have,” so you have an MVP (Minimum Viable Product) scope.
Think about the architecture of the product. Will this live in the cloud? Will it be a mobile app? Will it be able to function once you release it into production this way?

These are all questions you have to ask yourself. There is no coding involved, so don’t get confused. I’m not asking you to do anything other than to open a text document or a Trello board, or whatever you want to do and start asking yourself these questions.

By answering them, you’re already miles ahead of the rest who’re already writing code. Trust me on that one, you’re making a plan.

A plan will give you a finished scope, a pre-defined list of things you have to work on. This is major because it’ll tell you when you’re done. If instead, you started coding without thinking about what you’re implementing, you’d start adding features on the go and, potentially, you’d never see the end of it. That is known as “scope creep,” when you start adding extra scope before you’re done with your current one, and it’s one of the main reasons why software projects die.

So, make a plan. Heck, make several plans: one for the MVP, one for version one, one for version two, and so on. But whatever you plan, try to stick to it as much as possible. Only once you’re done with your current plan, start thinking about the next one.

Think About the Stability of Your Code

We’re all tempted to start throwing code around that “just works” because we want to move forward.

That’s not entirely bad, as long as you remember that this code needs to be reviewed and tested shortly after.

My go-to advice here would be to code thinking about stability from the get-go. But if speed is a problem and you need to get the first working version of your product ready, then, by all means, avoid all quality standards for the time being. But don’t forget about the forever, just enough for you to get that first version out (usually a pre-MVP version known as a Proof of Concept).

You should later come back to the code and properly go through it with a more detailed eye. Looking for things such as:

Stability problems. Did you take into account every edge case for your logic when building this PoC version? Are you sure your code is stable enough to keep on adding more features?
Code smells such as code duplication and lack of proper coding standards could hurt your progress in the future.

The point of this step is to make sure you have a solid base for the future. Adding patches on top of patches without a proper foundation is like building an office building without a blueprint on top of moving sand. That building is not going to be finished. And neither is your project.

Eventually, you’ll find problems that are too big to patch and that would require you to refactor a big chunk of your code. And that will be when that new project that you’ve been thinking about starts looking like a great idea.

Spend some time and stabilize your foundation, add unit tests, integration tests if you have multiple systems. Try to automate as much as possible from the build process. This will all contribute to you focusing on what really matters: getting the project done.

Scaling Should Not Be a Future Problem

How many users do you expect to have? How much data do you want to work with?

Answer these questions (or similar ones) at the start of a new project, and if you don’t have enough experience with previous ones, it is not only hard but near impossible.

At least it is if you want to answer them accurately. But that’s not what I’m saying here. The point of asking yourself these questions at this stage is not to properly estimate the traffic or the workload your product will have, but to plan for your ideal scenario.

There is a big difference between building a product that only works on your machine and building something that can be used by a few hundred people. And don’t get me started if you’re aiming to reach a lot more clients. If you build something that works for ten users because you never stopped to think about this point, the minute 100 users find your product, they won’t be able to test it. The thing will be slow; it’ll be unresponsive; it’ll crash on them. You’ll lose the users you were trying to gain simply because you didn’t stop for a second to think about your architecture before writing your code.

The project was doomed from the get-go, and you didn’t even know it.

Coming up with the architecture of your project is not easy, especially so if you don’t have prior experience. But again, the point here is not to come up with the ultimate architecture, one that will be able to work for every situation. Instead, my point is that you should review the ideal scenario where your product is successful and ask yourself: will they be able to use it if I build it like this?

Maybe you’re building a web app, and you’re going with a monolithic approach. Chances are that you’ll have to switch to a microservices-based architecture, eventually. The jump from monolith to microservice will require a huge refactor. Instead, you could’ve foreseen this and created just a few microservices, enough to get the gist of the workflow going so if tomorrow you need to disaggregate some of them, the basic architecture is already set up. The refactor should be less painful that way.

Or perhaps you’re having to process a lot of information daily. One approach would be to just iterate over it and serially process it. After all, having 10 or 20 users means you only take ten minutes. That’s not a big problem. But what happens when your users start to scale up? 100? 1,000? Now you’re jumping from 10 to 100 minutes, or maybe even more. Is your processing script still able to cope with that amount of data? Instead, you could’ve foreseen this and thought about doing some parallel processing. It would’ve been harder to implement from the start, but the process would’ve scaled up a lot better now.

The point I’m trying to make is that there is a big difference between getting your first version up and running to make sure it works vs. having a product that you can call “production-ready.” The first one is the PoC, and we’re allowed to do whatever the heck we want inside it, but the second one, which we can call MVP or version 1, needs to be built with certain considerations because it’ll be the one our real users will interact with. And we want them to be happy, don’t we?

Scale is a problem from the start — not a big one, mind you, but it should be in the back of your mind — and you should drive all your design decisions based on it (along with your other business needs).

Just Because You Build It, They Won’t Come

“If you build it, they will come.”

That phrase doesn’t work in this situation. Building a great product is not enough if you want to succeed. You also have to find a way to reach your audience.

And there are many ways to do it too; it’s all about marketing in one way or the other. But the gist of it is that you have to have an online presence.

If you’re not findable online, your chances of your product being a success are greatly diminished.

What does it mean to be findable? That’s the key isn’t it, there is no one single way because it depends on the type of users you’re targetting. Are those users normally finding what they need through Google? Are they using Reddit? Perhaps they’re searching on Pinterest because they’re looking for visual products?

There are infinite ways for them to find what you’re offering, the point is that you should understand them before deciding on your marketing strategy.

Once you do, provide them with as much information as you can:

Creating content around your product might help. Blog posts, videos, Instagram stories, you name it. The point is to create fresh content around your project that others might find. This helps transmit the message that you’re actively working on it and that you care about interacting with your users. This is not a project built ten years ago and then forgotten.
Create evergreen content as well. Tutorials and user guides answering common questions about how to use your product are great ways to get users to love you. You then have to find the places where they’re asking about it and try to link the content there. If they’re going on Facebook groups to ask, make sure you’re there to answer. If they’re asking on Stack Overflow, set up an alert and reply to those questions. Be there for your users.
Finally, building online is a trend that’s proving to work quite well too. By sharing your building process you gain an audience while at the same time developing your product. That way, by the time you have your project’s first version ready, you have a set of clients already interested and eager to try it. This is not an easy process, and it requires you to share both your highs and lows to prove you’re honest about it. However, if done right, the results can be great.

Whatever you decide to do, remember that building the product and having the code working is not enough to call it “done.” Reaching your clients is just as important and should be part of your plan from day one as well.

Is it easy? Heck no! And you might want to ask for help if you’ve never done it before. But neglecting it and having no marketing strategy whatsoever means you’ll have a much harder time ramping up the user count once you release. Keep that in mind!

Next time you have an idea for another side project that you really want to finish, remember to:

Push through the idea of starting to code it right away and make a plan for it.
Allow for stability in your code once you do code it.
Think about scale and design around that idea.
Start building an audience as soon as possible.

This should help you increase your chances of getting to a point where your project can actually be deployed and used by others.

What do you think? Have I left a step out?

How Can You Get Noticed Without a Github Account?

Fernando Doglio — Sat, 18 Dec 2021 11:47:14 +0000

I’ve had conversations with many developers trying to understand how to get their first job without any experience. And my go-to solution is: create a Github account and start uploading code projects you’ve worked on. Either that, or create new ones and publish them there.

Sadly, not everyone has access to Github, given how the platform is part of Microsoft and given the latter is a US company, it needs to comply with the US export law. Thus developers from countries such as Iran, Syria, Crimea and others are blocked by the platform.

This puts a harsh roadblock in their chances of getting their first job, especially if they’re applying for a remote position or a freelance gig. Either way, the main code repository for developers is out of their reach, so how can they find ways to show what they know how to do?

Let’s take a look at some options.

Build a WordPress site

Granted, this is not a code repository, but we’re going barebone here.

Other public code repositories like Bitbucket are also blocked in many countries, so we’re looking for alternatives.

Wordress.com allows you to set up a blog for free, where you can add whatever content you want. So let’s take a look at this and consider the opportunity it represents:

You’re free to show our code however we want.
You’re able to provide samples of code through direct download links, or through directly showing what it looks like.
You can also write content around that code. Are you showing a project you built? Create a series of articles around that project and link it to the code.

You can also take advantage of WordPress plugins such as code-prettify which lets you highlight code on your posts. That way you generate a similar look and feel users would get by reading code directly on Github.

If you have access to hosting and a domain name (ideally something like your name .com) you can even download the free version of WordPress from Wordpress.org and install it yourself. This would give you a lot more control over how your site works.

LaunchPad

If you’re looking for something similar to Github but that it’s not blocked, you might want to give LaunchPad a try.

It’s similar to Github in the sense that you can publish your project’s code, track bugs and issues, perform code reviews and more. And while the tutorials are written following the use of Bazaar instead of Git, they claim that the latter is also an option.

Projects such as Inkscape, the Photoshop open-source alternative or Ubuntu MATE, the Linux distro, are hosted there and you can see the type of information that you could potentially show to others.

Granted, the visual aspect is not the highlight of LaunchPad, considering they don’t allow you to show a lot, in fact, there seems to not be a place for a Readme file. However, you can definitely add a link to an external website, so that way you can provide extra information about the project if you want, and focus on giving access to your code through this platform.

Writing!

Writing is an alternative to showing projects done. It’s definitely not the same, however, as part of technical articles you can definitely show some aspects of your coding skills.

And that is what we’re after here, isn’t it? Trying to show potential employees that you know what you’re talking about and that the list of skills on your resume is definitely true.

Writing in a lot of places is free and public, so you don’t need to spend any money if you don’t want to. And if you’re doing this for a resume, I would strongly suggest you write about the subjects you claim to know. Maybe not about all of them, but the most relevant at least.

If you’re lucky and some of those articles get some traction, they can even be picked up by newsletters such as JavaScriptWeekly. That’s a nice greeting card, especially if your interviewer is already a subscriber.

But even if you’re just getting started, spend some time honing your writing skills, their return of investment is huge considering how much they can affect your communication skills.

Go to meet-ups / conferences and speak

Granted, this one might be a little bit extreme, but what better way to get in front of everyone you want to be hired by than assisting the same social events they do.

Some of the biggest (and sometimes not so big) software companies normally either sponsor some meet-ups or the big conferences, and they tend to send some of their employees as well. It’s a great opportunity for you to be there, speak about something relevant to your experience and network!

I understand that it’s not easy for everyone. Especially conferences require travel and not all of them are willing to pay for your plane ticket and hotel room. But at least do the research, there is a ton of information online about the different conferences you could be speaking at and they normally tell you if they have some travel budget or not.

Think about it, it might sound like a lot, but you’re also putting your name out there. The video of your talk will surely be on YouTube a little bit after, and anybody interested in you will only have to google your name. This is definitely a powerful, yet scary, opportunity.

Do not discard it until you’ve done the research.

Getting noticed is not all about code, but it definitely helps. The thing is that when I say “code”, you usually go straight into “side-project”, and from there you go right into Github, and that is where the plan collapses. No Github access, no side-project, no new job. Done.

But that’s not the case, find alternative ways of showing what you know how to do, either by finding less popular (or user-friendly) alternatives, or by doing other things around your projects (like writing or speaking about it).

What else would you suggest to a new dev looking for their first job as an alternative to having a portfolio on Github?

If you liked what you read, consider joining my Free newsletter to get insight into the software development career! https://fernandodoglio.substack.com

Practical Big O Notation for JavaScript Developers

Fernando Doglio — Fri, 17 Dec 2021 11:25:25 +0000

Big O notation is one of those things we usually learn about when we go through some kind of formal education (i.e college), otherwise the practical aspects of our day-to-day tend to overrun it and leave it as a completely secondary term that we can live without — and many of you do!

With that being said, I still believe there are benefits to understanding this notation at a high level. Quickly understanding the performance implications of an algorithm is not only useful but very practical.

So let’s take a quick look at what Big O notation is and what exactly should you be looking out for.

What is Big O notation?

The Big O notation is nothing more than a mathematical way of describing the complexity and performance of an algorithm.

I refuse to go in-depth into how to calculate the exact expression because honestly, you will likely never need it. Instead, you’ll only be needed the abbreviated version of it, something that will give you an idea of how fast the complexity of an algorithm will grow once the amount of values it needs to work with grows.

Let’s me put it like this: Big O notation is a way to graphically represent how fast the complexity of an algorithm grows while the number of data points it requires approaches infinity. Or it’s also a way to compare two algorithms within the same domain, the one with the lower BigO notation is usually better, at least performance-wise.

I know, it doesn’t sound a lot easier, but let me show you what I mean:

Look at the above image and consider the Y-axis as complexity, while the X-axis is the number of elements your algorithm will deal with (here “elements” can be anything from the number of variables to potential different values, or perhaps even number of instructions it needs to execute, we’ll be seeing some examples).

I won’t go into every single option here, because again, if you haven’t been using BigO until now, you can already benefit by understanding what O(n!), O(nlogn), O(n), O(logn) and O(1) mean. The rest of them are in-between and after reading this article you should be able to determine whether they’re good for you or not.

O(n!)

Let’s start at the worst-case scenario, the O(n!) case, that’s the black line in the above chart.

Sometimes you can’t avoid it, but if you can you should try to keep away from these types of algorithms as they are the ones that scale for the worst.

Note: If you see yourself not being able to solve the problem following a linear approach in less than n! time, then consider alternatives such as parallel processing, distributed computing or other, more complex solutions that might yield better results.

But personal note aside, some algorithms such as finding all permutations of a list of values, or even calculating the factorial number of a value have very common O(n!) solutions.

Also, another very common problem to solve, such as calculating the Fibonacci sequence. If you do it recursively — which unless you’re using a programming language that has “tail call optimization” (and JS doesn’t) you’ll run into problems for very small numbers— you would get an O(n!) algorithm.

O(nlogn)

I think it’s important to understand this particular order of magnitude because many common algorithms fall inside it.

In particular, sorting algorithms such as Merge Sort, Heap Sort and Quick Sort will have this performance. This means that if you’re trying to sort enough elements with them, the execution times will not scale gracefully. In fact, they’ll keep going up and up very quickly.

Many developers claim that JavaScript’s Array.sort method has a Big O complexity of O(nlogn), but in reality, it depends on the implementation the runtime has used. For instance, Firefox uses Merge Sort, so yes, O(nlogn) is correct as a usual execution complexity. However, the V8 runtime for instance (and thus Chrome, Node.js and even Deno), uses Timsort a mixture of Merge Sort and Insert sort that has a best-case scenario of O(n) which if you go back to the chart from above, it’s considerably better.

O(n)

The green line on the chart can be read as: your algorithm will have to go through every data point to perform the task at hand. The more data points to process, the more time it’ll take to do it.

These are not necessarily bad algorithms, but if the value of n (i.e the number of data points) is meant to grow quite high, then you have to consider the implications and maybe even, some kind of optimization.

A classical O(n) algorithm would be one that needs to traverse all the elements of a list to perform an action, for instance, imagine having to count the number of odd values in your array:

function countOdds(list) {

  let totalOdds = 0;
  list.forEach( n => {
    if( n % 2 == 0) totalOdds++;
  });

  return totalOdds;
}

If we’re dealing with 10 elements on the array, it’ll go through all of them but it’ll do it quickly. However, if your array suddenly contains 1.000.000 elements, it’ll take a while because its complexity is growing accordingly.

O(logn)

The blue line (log2 n) tells you that while the complexity will grow, it’ll grow slowly, and even better, the growth rate is capped. It will not go past a certain point, no matter how many more data points you add. This is a very good algorithm and it can scale quite high.

A classical example of an O(logn) algorithm is the binary search, which is constantly dividing the problem universe in half.

In case you’re not familiar with the algorithm, here is a quick run down, always assuming you’re looking for a value inside a sorted list of elements.

You identify the element in the middle of your list.
You compare your target value with the middle value. If it matches, you’re done. Otherwise, continue to 3.
If the target is lower than the middle value, drop the right-hand list and repeat from step 1 on the left-hand list.
If the target is higher than the middle value, drop the left-hand list and repeat from step 1 on the right-hand side.
Repeat the process until you find the target or run out of values to compare.

Now the magic of this algorithm is that if you grow the number of elements in the list, thanks to the fact that you’re constantly dropping half of it, you’ll still be able to finish very fast.

For instance, in a worst-case scenario, if you have 1.000.000 elements, you’ll have to compare values 20 times. That’s right, 20 times (which is quite close to 13.8, which is the value of logn(1000000)).

If you think about it, you’re going from 1.000.000 to 20 with a change from O(n) to O(logn).

O(1)

Or constant time as others call it.

This is the ideal notation and it means that you’ll always be able to perform the action you’re looking for without caring for the number of elements you’re having to deal with.

If you’re able to write an algorithm that achieves constant time then it’s definitely worth the time and effort put into it.

An example of this would be using an object literal vs having multiple IF statements to decide what to do with your logic. Let me explain with an example, imagine having this code:

function myFunction(myValue) {

  if(myValue == 1) {
    return doOneThing();
  }

  if(myValue == 3) {
    return doAnotherThing();
  }

  if(myValue == 4) {
    return doYetAnotherThing();
  }

  //default behavior
  return doTheDefaultThing(); 
}

Worst-case scenario, that code is checking every IF statement and then returned the default behavior. Granted, depending on your outside logic that decides the value of myValue you could argue that your best case scenario is a lot better, and 8 out of 10 times myValue will have the value of 1. However, we’re planning for the worst and hoping for the best here. And since we have an algorithm that is checking “n” times the value of myValue we can say that right now its Big O notation is O(n) — mind you, for a very small number of “n”, but nevertheless if you call this function often it could potentially be a performance hit.

Can we improve on it? I’d say yes, we can, let’s take a look:

let logicBehavior = {
  1: doOneThing,
  3: doAnotherThing,
  4: doYetAnotherThing
}

function myFunction(myValue, logic) {
  try {
    logic[myValue]();
  } catch(e) {
    doTheDefaultThing();
  }
}

Now you may or may not fully like this solution, but it’s no longer checking every value. In fact, it is directly accessing the function it should be calling. And since we’re planning for the worst, in our “worst-case scenario” it’s first checking for the index’s existence in logic and then calling doTheDefaultThing, that would be a Big O notation of O(2), which again, it’s a constant number for potentially millions of calls, so we can safely disregard that 2 and call it an O(1).

If you go back to the chart from the start, this would be the pink line. Of course not every single algorithm can be O(1).

Big O notation is nothing more than a tool. It helps us compare algorithms within the same space and understand at a glance, how performant they’ll be without having to read a lot of documentation or benchmarks about them.

Many libraries or even other software products will make use of this notation as well, a classic example of it is Redis. Redis’ documentation states the Big O notation for all of its commands, which helps you understand if you should or shouldn’t be using them considering the number of records they’ll be interacting with.

Keep in mind that this is also a “worst-case scenario” type of measurement and given the right circumstances you could still make do with a O(n^2) algorithm.

Leave a comment if you didn’t know what Big O meant or if you have any further questions, I’d love to help you understand this concept!

If you liked what you read, consider joining my Free newsletter to get insight into the software development career! https://fernandodoglio.substack.com

Designing Error Messages and a Logging Strategy in Node.js

Fernando Doglio — Tue, 30 Nov 2021 12:13:11 +0000

Error handling is one section of our job that we tend to neglect, especially when working on something new, interesting, or something we just need to get working. We'll handle errors later, we say — and that's often a big lie.

But that's not even the worst part. The problem comes when we decide to 'quickly' add some code to handle our errors and completely forget about the importance and relevance of a properly constructed error message.

Who cares about the other side as long as my app doesn't burn while crashing, right? Wrong. And don't even get me started on the lack of proper logging for those errors — who's interested in the person troubleshooting those midnight crashes?

These are prevalent situations that we need to learn to avoid. We can't code assuming our applications won't have issues (they will), and we can't think that no one will try to troubleshoot those issues. There is a lot of information that we can provide if we do it properly.

So let's see what a proper logging strategy looks like and how we can structure our error messages to be helpful.

The Importance of a Good Error Message

"There's been an error, try again later."

How many times have we read or written that error message (bad developer!). Who are we helping? And honestly, do you really think "try again later" solves anything? Is the problem going to fix itself magically? For the sake of our sanity, let's assume that it won't, shall we?

Error messages aren't there to get you out of crashing your app. They should help whatever or whoever is on the other side of the request to understand why they're not getting what they asked.

Notice how I said "whatever or whoever." That's because we live in a world where people can use our systems through a piece of software, or an automated software can read errors directly.

Both need very different types of error messages.

We need to have an explanation of:

what went wrong
why it went wrong
what we can do to fix it, if possible

On the other hand, automated systems won't benefit from such an approach since we all know getting machines to understand our language can be very hard. Instead, other systems might just need a single alphanumerical code representing the error code. They'll have an internal mapping to understand how to respond to problems.

From the perspective of returning a particular error message in Node.js, I like to take the JSON approach and return everything I need to return inside a single JSON object. For example, in the following code snippet, we return an error for a fictional sign-up form. In this scenario, the user attempts to register on our site with an already existing username:

{
    "error": {
        "error_code": "44CDA",
        "error_msg": "There was a problem with your username, it looks like it's already been taken, please try with a different one"
    }
}

The above error response does a few things:

It lets the other end know there is information about the error by encapsulating everything inside a single error key.
It returns a single error code for any potential system to automatically react to, without the need to parse and understand our error message.
It also returns a detailed explanation of the error for a human user to understand.

You could even expand on #3 and provide some suggested usernames that are currently available. But the example above is more than enough.

Another great practice for returning error messages is to consider the HTTP response code. This is, of course, only useful if you're working under HTTP (but let's assume you are).

As part of the standard (and this is why it's so useful — because it's a standard), we have the following groupings:

1XX (Informational responses) — These are informational statuses meant to let you know the server has received your request and is still working on it.
2XX (Successful responses) — OK return codes, meaning that whatever you tried to do, it worked.
3XX (Redirects) — Redirect messages usually mean that the resource you're trying to reach is no longer there.
4XX (Client errors) — These indicate that the problem is on the request, meaning it's incorrectly formatted, trying to access something that's not allowed, or some variation of that. In other words: it's your fault.
5XX (Server errors) — These indicate that something went terribly wrong on the server-side. Your code crashed, and it couldn't recover, thus the 500 error.

Read all about the different status codes.

With this in mind, we know that we could potentially group our custom error codes into two categories:

Errors generated by the user
Errors generated by our code

Why would we do this? Why isn't the custom error code enough? It actually is in some situations. However, if you're dealing with client code that you know follows HTTP standards, such as a web browser, then you're providing them with information that they can automatically use to improve the way they handle the error.

So, for instance, back to our 'invalid username' error example: we would return it with an HTTP Status Code of 400 — 'bad request.' The request initiated by the user is incorrect, as they wanted to sign-up with an already taken username.

How to Log Errors in Node.js

Consider the necessity of understanding why errors happen. Why does your application constantly return the same error message stating that a username is already taken?

Meanwhile, this is causing users to complain that they can't sign-up to your app, so you'd better figure out what's happening fast.

This is where logging comes into play — because returning a good error message to the user is only half the battle.

What happens when the user is getting the wrong error message? You, my friend, have a problem. But you now need to understand it and figure out how to solve it. Doing this without proper logging will be a pain, especially if you're troubleshooting a production application.

How Does a Good Logger Look?

What is a "good logger" after all?

Well, it's not console.log("This is my log message"), that's for sure.

A good logger is a piece of code that can do multiple things, ideally all at once:

Help you log a message (duh!).
Handle any type of variable (including objects) being logged. That means correct serialization of attributes.
Add metadata to the message, such as its importance (or level, as it is commonly known), a timestamp, or the message's origin (the module, for instance, or the function name).
Persist that message somewhere.
Format the message for easier human interaction (e.g., add colors, bold words, etc.).

At a high level, this is exactly what you want to look for in any logger you either build or import into your code. Just make sure that you use one that's accessible throughout your code. This is crucial because another problem with an unsupervised logging strategy is that multiple developers often try to solve the same problem differently. You and your colleagues will inevitably each build your unique version of the ideal logger, tailored to your particular needs.

That is a problem right there, not only because you're repeating logic, but also because you're potentially handling some related issues in different ways. For instance:

Message formatting
Extra metadata
Message persistence

Instead, ensure that you're all using the same logger, following the same standards, and doing the same thing with the output.

What to Do with Logged Data

A vital topic to cover when it comes to logging is what to do with logged data. Every time you log a message, you're generating data that needs to go somewhere.

That 'somewhere' can simply be the console — a volatile place where everything that's not actively watched or captured somehow gets lost. So if you're not looking at the log output, then you'll miss it. This means that storage-wise, you have it very simple; however, by losing the data, there is no chance for you to correctly troubleshoot your application when something goes wrong.

You have to think about your logs as pictures of the state of your system at any given time. The more pictures you have, the better your ability to re-live it.

That means we need to save our logs. But where? Saving into a local file can be dangerous because if you're not manually truncating those files, your hard drive might run out of disk space. The very solution you've used then ends up causing a big problem.

Ironic, isn't it?

Instead, consider using an external utility such as Logrotate — a Linux utility that allows you to manage your log files automatically. For instance, you can zip and rename your log files automatically by setting thresholds on files' age and sizes. When these triggers get fired, Logrotate will create a new, empty log file and "rotate" the old one so that it is archived. You can control how many archive files are created. When a set number is reached, the oldest one is deleted, and a new one added.

An alternative is to send the log messages to other platforms such as Loggly or Logz.io, which receive, index, and provide you with search functionality over your logs.

This, in turn, makes it very easy to traverse the full set of logs, especially when you're logging on multiple servers (for example, when you have copies of the same service).

Logs are a wonderful tool to use when things go wrong, but they require you to pay attention to something other than your code. Storage is one of the main aspects of logging that many people ignore — and they end up crashing their servers due to a lack of disk space. Make sure you have a storage strategy to go alongside your logging strategy, and you'll have no issues.

Logging Libraries for Node.js

Like with anything in JavaScript, there are way too many logging library options out there.

I got 6,219 results on NPM's site when searching 'logging'. The endless options can be intimidating.

That being said, only a few of these results are worth using, as they're actively maintained and used by millions of users. So let's focus on those options, and you can go from there.

Winston

Winston is, by far, my personal favorite. It's a very versatile library that integrates with major platforms when it
comes to storage.

Essentially, Winston is a logging library that allows you to:

Create your own loggers
Customize the output format and logging level
Control how you'll store those logs
Decide different storage options for different levels

For example, you could decide that error-level logs — those you want to keep an eye out for — are sent to DataDog. At the same time, you can determine that any info-level logs will go to a local file that gets rotated when it reaches 100Mb of size and display debug-level logs on the terminal.

Winston's plugin-based architecture means it stays relevant even after new logging products are released because developers create integrations with the plugins and publish them on NPM.

Creating a logger with Winston is as simple as doing the following:

const winston = require('winston');

const logger = winston.createLogger({
  level: 'info', //Sets the default level
  format: winston.format.json(), //Sets the default format
  defaultMeta: { service: 'user-service' }, //Adds extra meta-data
  transports: [ //Configures the transports, or essentially where do log messages go...
    //
    // - Write all logs with level `error` and below to `error.log`
    // - Write all logs with level `info` and below to `combined.log`
    //
    new winston.transports.File({ filename: 'error.log', level: 'error' }), //Error log files for error-level logs
    new winston.transports.File({ filename: 'combined.log' }), //Simple file for everything together
  ],
});

//
// If we're not in production then log to the `console` with the format:
// `${info.level}: ${info.message} JSON.stringify({ ...rest }) `
//
if (process.env.NODE_ENV !== 'production') {
  logger.add(new winston.transports.Console({
    format: winston.format.simple(),
  }));
}

Notice how, through the use of the createLogger method, we're creating a new instance of a Winston logger. And through the configuration object we pass to the method, we make sure this particular instance behaves as expected:

The default level is going to be info.
The format that every message will have is JSON.
It'll also add one extra field to every logged message: service with the value "user-service".
Error-type logs are saved into a specific file called error.log.
And all logs, in general, will go to a file called combined.log.

That entire configuration will make your particular instance unique, and you can build as many as you want (although you'd normally build one).

Finally, an extra transport is added in case we're not in a production environment (we check this through the value of the environment variable NODE_ENV): the console. This means that if we're dealing with a non-production deployment, we'll send every log into the terminal, and the format for all messages will be plain text with no JSON-like structure. This is especially useful for debugging purposes.

Finally, simply use:

logger.info("This is an info message!");
logger.error("Something terrible happened, look out!");

As you can see, the magic methods appear. You don't have to worry about whether you're logging in a production environment, or if you want one of these messages to be saved into a file. It's all transparent to you now.

Check out this complete list of Winston integrations with external systems.

Logging

Logging is a basic yet functional logging library. It only works for your terminal, so you can't control where or how logs are stored through code.

That being said, nothing stops you from capturing the terminal's output and redirecting it to a file, to get rotated using logrotate.

Using this library is super easy. All you have to worry about is creating a logger around a particular feature, and then you'll have custom methods for each log level, just like with Winston.

import createLogger from 'logging';

const logger = createLogger('MyFeature');

logger.info('Interesting information you need to know');
logger.warn('Hmmm..., this data is not correct', { details });
logger.error('Not good.', 'Not good at all.', { err }, { context }, { etc });

/**
This would output:

[ MyFeature ] Interesting information you need to know
[ WARNING MyFeature ] Hmmm..., this data is not correct { details object }
[ ERROR MyFeature ] Not good. Not good at all. { err } { context } ...
*/

In the above code, we also have the same createLogger method we had with Winston. However, this time around, it's a bit simpler.

We only care about naming the feature we're logging (the parameter that the method receives), and that's it. The rest of the magic methods come back, but they all do pretty much the same thing — they log those messages to the terminal.

As I mentioned, this is a very basic library that doesn't do a lot — but what it does do, it does very well. External libraries can do the rest.

Log4js

If you're familiar with Java, you probably know about log4j. Log4js is an attempt to port that functionality into Node.js.

The creator's README does not recommend assuming that this library works like its Java counterpart — however, it's safe to assume certain similarities.

Much like Winston, Log4js is packed with possibilities and configuration options. You can decide how to format your logs and where to store them.

Its list of integrations is not as big — there are only 11 options available.

Don't get me wrong though, these are 11 more than Logging, and you probably only need one per project. You'll hardly ever need to consider sending your logs to different places, even if you had the chance to do so.

From the library's documentation:

const log4js = require("log4js");
log4js.configure({
  appenders: { cheese: { type: "file", filename: "cheese.log" } },
  categories: { default: { appenders: ["cheese"], level: "error" } }
});

const logger = log4js.getLogger("cheese");
logger.trace("Entering cheese testing");
logger.debug("Got cheese.");
logger.info("Cheese is Comté.");
logger.warn("Cheese is quite smelly.");
logger.error("Cheese is too ripe!");
logger.fatal("Cheese was breeding ground for listeria.");

Here, we have a mixture of Winston and Logging because, as you can see, we're configuring a specific instance of the logger.

We're setting up one particular file to contain all of our logs — cheese.log — and we're also adding a default error level (much like we did for Winston). However, we then create one particular logger instance around the "cheese" category (like we did with Logging).

This code will output the following to your terminal:

[2010-01-17 11:43:37.987] [ERROR] cheese - Cheese is too ripe!
[2010-01-17 11:43:37.990] [FATAL] cheese - Cheese was a breeding ground for listeria.

Why only two lines? Because, as you can see, the default level for the 'cheese' category is "error", everything below
that level only gets saved to the cheese.log file.

If you ask me, unless you're an ex-Java developer who's familiar with log4j, I would skip this one and go straight to Winston.

Are there more options? Absolutely: Bunyan, Pino, and others. It depends on what your particular logging needs are.

What to Log in Your Node.js Projects

Let's leave the actual libraries aside for now. It's important to understand that there is an unspoken standard between them all. You may have noticed mentions of "log-levels" and methods such as debug, error, info, and others from the small code snippets above.

You see, not every log message is created equal — they don't all have the same importance or relevance at any given point in time.

You'll want to see some messages every time your application runs because they'll let you know everything is working correctly. There are other messages that you'll only care about if things start to go wrong.

The basic log levels that most libraries tend to adopt are:

Info — Meant for messages that display useful yet concise information. You want to use info-level messages to show that a process got called, but not what parameters it received or how long it ran.
Error — This one's easy enough. When things don't work out, and you catch an error, you'll use an error level message to save as much detail about the error as you can. Remember, error messages need to be useful. See this post on long error messages to read more about how you can make error messages useful.
Debug — This is the 'verbose' level. As you'll use this when you're debugging your application, you need a lot of details about what's happening. Here, you'd include things like full-stack trace dumps or list the full content of an array. Things that it doesn't make sense to see constantly, but you need to make sure that everything goes where it's supposed to go.

There might be other log levels depending on the library, such as warn — to indicate messages that live between an info state and an error state. In other words, warn flags something that needs attention — for example, a missing config file.

While you can still use default values, you could instead write something like this:

[Warn] Missing configuration file on ./config, using default values

This could be written as an info message as well, but an extra level of logging allows you to filter and organize the information a lot better.

You might also see a fatal level, which is worse than an error — for instance, a crash on your server (i.e., something you can't recover from) would be a perfect use case for fatal.

Finally, a level that goes beyond debug is trace. This level contains all the super detailed messages that you only want to see when something is wrong, and you need to understand what's happening inside your application.

An example is an Extract, Transform and Load (ETL) process, where you extract information from a source, transform it somehow and finally load it into a storage system (this could be a database, the file system, or anything in between).

If you start seeing that your data is corrupted at the end of this process, you need to understand when the corruption happened. You'll have to know exactly what happens to the data at each step, and that is where a trace level of logging can come in handy.

Once you're done checking your logs, you can revert to a less verbose default logging level. Let's look at that now.

Default Logging Level

We can't always log everything. This is another important concept to understand when defining our logging strategy.

Even if we split different log levels into different destinations, we can't always spend computational resources logging every detail of our business logic.

Logging hurts performance the more you do it, so keep that in mind as well.

So what do we do instead? The log levels mentioned above are sorted by priority, for example:

trace
debug
info
warn
error
fatal

If we want to use the less verbose levels, we could set the default level to info. Then, even if we had direct calls to the debug and trace methods, they would be ignored because the library would only pay attention to our default level and anything with higher priority.

In the same vein, if we only care about error messages for some reason, we can set the default level to error and get error and fatal logs, but nothing else. So we toggle certain levels based on a single value. The perfect use case for this is to enable different levels depending on our deployment environment.

Let's pretend we have three environments:

Dev — where we test new features ourselves
QA — where we let others test our features
Prod — the final environment where we deploy our code once it's ready

We could have different default logging levels in each environment.

For example, trace could be a default for our Dev environment to get the most details about how our code executes. Only we care about that level, so it makes sense that it's only the default here.

For the QA environment, we could have the info level as our default, in case something goes wrong or we want to monitor what's happening during tests. We're assuming things work here, so we don't need the details provided by
debug or trace.

Finally, we'll only want to use the error level as default for our Prod environment because we only care about things going wrong. If nobody complains, we're good. This also provides the lowest possible performance loss since we're only logging when something bad happens.

You can control the default value with an environment variable, like this:

const winston = require('winston');

const logger = winston.createLogger({
  level: process.env.NODE_LOG_LEVEL || "info", //using the default log level or info if none provided
  //... rest of the implementation
});

The example above shows that you can grab any environment variable through the process.env global object. By default, if we can't find the variable, we use the "info" value.

You can set that directly on the execution of the script:

$ NODE_LOG_LEVEL=error node server.js

Or through a bash script where you export the variable directly:

$ export NODE_LOG_LEVEL=info

Wrap-up: Choose the Right Node.js Logger and Useful Error Messages

Any application you're developing requires a logging strategy. Luckily for us, Node.js has a bunch of very interesting and useful loggers. As long as you understand your use case and your strategy, you can then pick the right one for you.

As for your strategy, remember the two most important things to decide are:

What are you going to do with error messages?
How are you going to structure them?

Once you've answered those two questions, it just comes down to picking the right library and adding logging lines.

Check out this article for more tips on logging in your Node.js apps.

Happy coding!

P.S. If you liked this post, subscribe to our JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

P.P.S. If you need an APM for your Node.js app, go and check out the AppSignal APM for Node.js.

Fernando Doglio is an engineering manager, blogger, book author, and maker of software things. He loves writing, especially about software. Get in touch with him on his blog or Twitter.

Starting Your Journey in Coding: The Skills That You Actually Want To have

Fernando Doglio — Sat, 23 Oct 2021 05:51:04 +0000

When looking to get started in your software development journey, one of the first things you’ll ask yourself is “Where do I start?”.

And while there are plenty of places that will happily list the same set of technicall skills, I strongly believe that the main areas in which you should focus are not technical.

These are some skills which are never listed in your typical job offers. They definitely help you either get your first job or to be considered a great dev, but because they’re not technical skills they can add to their resume, many new developers tend to skip them.

These are passive skills. You won’t actively have to use them, but rather, they’ll be there in the back of your mind helping you in your daily routine. The most frustrating part about them: there are no online courses or bootcamps that help you train them. These are soft skills that you need to be aware of in order to develop (if you don’t already have them).

I know this is probably not what you wanted to hear, but these are the cornerstone of growing as a developer, and you’ll need them in order to successfully train everything else. As you’re about to see, any technical skill can be learned over time by reading a manual or watching a video, but the following skills will help you through the learning process.

Yes, you’ll become a developer by learning how to code, but if you skip these five skills, it’ll be like learning to run before knowing how to walk.

Patience

Nothing says “I’m a Software Developer” like spending three hours debugging a piece of code, and figure out the problem was a missing “,” somewhere in the middle.

You’ll go through this a lot, and it’s not a sign of “Juniority” or a lack of experience, trust me; I go through that same process every now and then today, after almost twenty years.

Understanding someone else’s code requires time and effort, researching how to solve a problem requires time and effort, writing code and getting it to work requires time and effort. Patience isn’t only a virtue for a developer, it’s a must-have. Copy and pasting code from the internet only gets you half-way, the rest needs to come from you and there’s a lot of trial and error involved.

Determination

In-line with patience, you need to also understand this isn’t an easy profession. I’m not saying this to scare you off and throw this article away. On the contrary, setting the right expectations is key to avoid getting discouraged when bad things happen during your journey.

The fact is, your chosen profession will be filled with roadblocks, with problems that once fixed become ten. Bugs can take months to solve and each and every one of these situations becomes a reason for you to quit.

Trust me, I’ve wanted to quit programming multiple times during my career. The idea of moving to the middle of nowhere, away from technology, and growing tomatoes in the desert is appealing to many devs inside our industry.

Is that the sign of a problem in software development? I don’t think it is, but it is proof that ours can be a frustrating profession at times.

This is why determination is a must-have skill for developers. Mind you, you can build it over time. It’s hard to know if you’re determined enough until you’re faced with a situation that challenges you, but if you’re already a determined person, someone who is known to not give up on the first try, then you’ll do fine as a developer.

An eternal student mindset

The underlying topic of this article is professional growth and growth can’t happen without learning.

One hard requirement I put on every new software developer is to always be learning. Or at least, be open to the idea of learning.

Although it’s true that you don’t have to like a fast-paced environment to work on, our industry is always moving. Sometimes it moves forward and sometimes backward by making a twenty plus year old pattern new again (I’m looking at you React) and if you don’t keep tabs on these changes, you’ll be left behind.

I’m not saying you need to go out and learn “all the things”. That couldn’t be further from the message. What I’m saying is that you should be open to the idea that the tools you’re using right now and the things you know right now won’t always be the norm. If you don’t accept that, you’ll find yourself unable to move forward with your career within two years.

Technology pushes technology forward, it’s that simple. The tools you use today won’t be the same ones you’ll use tomorrow. New technology developments might open new areas of research, new ways of processing data, new ways of interacting with users, and when that happens the tools for the developers need to adapt. If you don’t adapt with them, you’ll be left behind.

An open mind to receive criticism and learn from it

Programming isn’t a solo profession, even if you’re considering going freelance, you’ll have to interact with other developers one way or another. Part of that interaction happens through feedback.

Code review, for example, is a common practice in software development which helps ensure code quality by having a group of devs review the code written by someone else.

If you’ve never been through it, it might sound strange, but it’s a growing experience for both parties involved if they perform it correctly:

On the reviewing end, the group of developers reading the code need to understand that their job is to improve the code by finding logic issues, missing standards, or even some bugs.
On the receiving end, you’ll need to understand that the feedback they’re giving you isn’t personal. Showing your code like this can feel like that nightmare where you realize too late that you’re in class naked in front of everyone. They’re putting their years of experience at your disposal; you should accept their feedback, make sure you understand why it’s given, and you’ll come out learning a lot.

Feedback comes into play in other instances as well. Sometimes it’s expected, like with performance reviews, and other times it isn’t, like getting an issue reported on your open-source project. Either way, receiving negative feedback is always a possibility, and being open to it’s a must.

Surviving negative feedback, like when it’s unexpected, can be hard if you’re not open to learning from it.

I think it’s important to make a distinction between feedback that shows a negative quality of our work (e.g. a bug), versus non-constructive (negative) feedback that only shows how our work has affected others to the point where they need to hurt or disqualify us with their words.

A negative piece of feedback has to be received as advice you didn’t ask for. It always has a nugget of wisdom inside it, and you must ignore the negative coating around it, cut through to the core message and the lesson to be taken out of it. You should consider the rest as noise.

As a technical lead, I’ve received hundreds of performance reviews in my career, and they’ve not always been positive. Whenever that happens, I try to focus on getting to the core of the problem, on trying to understand what caused that negative review to avoid that behavior in the future.

If you only see feedback as a bad thing, then you’ll start second-guessing your decisions and the whole point of that feedback (which was to help you improve) is lost.

Know how to communicate

This is a tough one because a common problem amongst developers, even experienced ones, is that they don’t know how to communicate with people.

From the outside, it might seem weird, but sometimes we focus too much on learning how to write logic code that a machine can understand, that our soft skills, no matter how small and undeveloped they are, tend to wither away.

Machines don’t need us to write eloquent sentences, they don’t really care for synonyms or the use of metaphors and figured speech. They need clear, unquestionable logic. As a developer, you also need to work with humans, who, unlike machines favor all those things.

When you need to interact with a colleague to ask for help by explaining the problem you’re having, or even when you have to solve someone else’s question, you need to switch from your “machine understandable syntax” to your “human understandable” settings.

This is why having these skills even before applying to your first job is a major advantage over everyone else in your same situation. The moment your interviewer notices you can communicate effectively, the battle is half won.

How can you develop this skill? One way to do it’s through writing.

Back when I started, both my written and spoken communication skills were terrible. I remember spending thirty minutes writing “important” emails because I had to go through them multiple times, adding words and explanations, asking colleagues to review them to see if they made sense.

It was only when I started making the conscious effort to write online (articles for my own blog) that I started learning how to write more eloquently, you can say I started finding “human friendly” ways of explaining concepts. This, in turn, helped my spoken communication skills as well (something “clicked” in my brain).

And through that and other working experiences, I was able to learn how to effectively talk to others (which helped me in my path to leading teams as well).

Yes, knowing how to communicate with others is a major skill to have, the great news is that you can start practicing it right now, for free, and figure out what your internal voice sounds like.

And what about after you get your first job?

The trick to the career path of the software developer is to remember that you’re not done when you get your job. It only means you’re getting started.

It’s like getting to the max level on your favorite MMORPG and thinking you beat the game. This isn’t right, you only unlocked a whole new level of content specifically designed for you.

And it’s the same thing with your career. Getting the job doesn’t mean you’ve mastered the trade, it means you were able to stand on the first step of a huge ladder. The skills I listed above need to be developed and maintained throughout the course of your life, and the more you work on them, the better you’ll do.

Keep honing your communication skills, they’ll always be useful, but the higher on the ladder you climb, the more important they’ll become.
Understanding how to grow from negative feedback keeps you from getting stuck in your career.
Working on your patience and determination ensures you never meet a problem you can’t solve. These two skills have taught me that there’s nothing impossible in our profession, as long as you have enough time and people to work on it. This is something I like to say to clients asking if their idea is possible. The answer is always yes, no matter how crazy or difficult the request is, as long as you have the patience and determination to do it.
Staying relevant in our industry is a must for anyone who is interested in advancing their career. This means looking outside your own box to find out about what others are doing. Raise your head every once in a while, if nothing else, to make sure you’re not the only one around.

That’s all for this article. If you want to learn more about the book, check it out on Manning’s liveBook platform here.

From Skills of a Software Developer by Fernando Doglio

Take 35% off Skills of a Software Developer by entering fccdoglio into the discount code box at checkout at manning.com.

If you haven’t already, go check out the various articles about the journey of a software developer covering things like myths about the requirements or perhaps the best practices to follow as a Jr . developer.

Starting Your Journey in Coding: Myths about What You Need to Get started

Fernando Doglio — Sat, 23 Oct 2021 05:43:26 +0000

From the outside, the software industry looks compelling if you think about it: many countries have no unemployment in the field, salaries are fair, there’s always room to grow, travel is involved in many cases, the option to work from your couch for a Silicon Valley company is there; why isn’t everyone working in software development?

The truth is that although it might seem interesting, getting in isn’t that simple.

Finding your first job as a software developer can be challenging at best; most companies looking for entry-level engineers require them to either have experience with some of the latest frameworks and technologies or to understand a lot of advanced concepts such as design patterns, software development best practices, and version control. Then, they’ll go into vague requirements, such as having great “interpersonal skills”, or knowledge about other IT-related areas… what’s that about?

The following job listing was created from multiple samples taken from internet, looking for Jr. developers:

Bachelor’s degree in related areas and a minimum of one year of experience in similar roles.
Knowledge of secure software development.
Intermediate skills associated with design, development, modifications, and deployment of software, including object-oriented programming.
Knowledge of other IT-related areas.
Demonstrated software repository skills.
Demonstrated effective communication and interpersonal skills.
Self-motivated and works independently.
Demonstrated problem-solving skills.
Intermediate skills in C#, ASP.NET MVC, SQL Server, TypeScript and React.js.
Experience using Git and Github.

Looking at that list, how can anyone trying to get into the industry not feel intimidated and scared of applying? Anyone looking at that job posting will assume they need two more years, at least, of experience before being taken seriously.

Having been through the same experience eighteen years ago, I still remember the type of questions I had:

Do I even bother applying for the job? I only have three out of ten of the required skills.
Do I need to stop studying X and switch to Y now? Because this week everyone is asking for Y developers.
How can I get experience if I’m looking for my first job?

They’re probably the same questions that any new developer looking to start their career has, but here’s the kicker: they’re normal. You’re not figuring out that you’re not cut out to be a developer; you’re only living through the Jr. Dev experience.

This is what this article is all about. I’ve been through the same struggles that any new developer experiences, I had my first underpaid job because I had no experience. I’ve met some great people that taught me quite a lot about working in a team and I’ve also met some terrible ones who, through their behavior taught me a considerable amount of things to avoid.

Throughout this article, I’ll be sharing the bits and pieces of my own journey. My hope is to show you that you’re only getting started in yours and that the issues you’re facing and the doubts you’re having are completely normal and part of the developer experience package you bought when you decided to live off of your coding skills.

For this article, I wanted to start by covering the basics: what exactly do you need to work as a developer? The internet has a lot of noise and asking this question to Google can bring up a lot of different articles. Everyone has their opinion, and most people tend to focus on functional skills, things you need to learn before thinking of applying for a job.

In my experience they’re not the most relevant nor the most important ones you’ll pick those up through experience if you have to. The truly important qualities of a good developer (even one who has never worked a single day in their life) aren’t technical.

Let’s look at both lists now: the common misconceptions of what is needed to be a developer and the truly useful skills you’ll need.

What you don’t need to become a successful software developer

If you’re looking around internet trying to figure out how to profile your learning before applying for the first job, or if you’re thinking about planning your next five years before you start working, let me cover some of the biggest misconceptions around the requirements to get into the software industry.

Mind you, none of the following topics will hurt your chances, but they’re not hard requirements needed to start the job. Don’t think of it as a to-do list, but rather, a nice-to-eventually-have list.

Bachelor’s degree in computer science or related degree

Four+ years of formal education. Look, I went through it, I did my best to finish it, and I failed on my first try. I tried to be a Software Engineer, a five-year career in my home country, but by the time I was in the second year I got my first job, and my formal education went down the drain.

Do I regret it? I did, which is why a few years later I completed a technical degree (two years and a final project) to formalize a lot of my practical experience.

Did I need the first two years of university? I did, yes, but mainly because they formalized a lot of the basic programming concepts that I had somewhat figured out on my own, learning how to code for fun. Back then there were no bootcamps, my internet access was limited by my 2400 bauds modem, and the learning resources were mainly hacker e-magazines (which were TXT files with some ASCII art thrown in).

The situation now is completely different, and anyone looking to start learning how to code has the world’s knowledge at their disposal. This is no exaggeration, there are free online resources such as YouTube or freeCodeCamp.org which have everything you need to go from zero to workable. Although it’s true that not everyone can learn by absorbing knowledge, you also have other options: paid courses in places like Udemy or Skillshare, which cost a lot less than a university degree and gives you access to classrooms, Q&A sessions with teachers and contacts of other students going through the same problems as you.

These resources provide the practical knowledge required to start coding, and although it’s true that many people value the mention of a college degree as part of your resume, a lot of companies are starting to pay less attention to that single bullet point. Granted, that affirmation might be less true in some countries than others, but it’s also true that ours is an international profession in the sense that we can work for companies anywhere in the world, and when that starts happening, the college degree are diminishing in importance.

I’ve personally performed hundreds of interviews with new developers, and I’ve come to learn that a college degree shouldn’t be an entry requirement.

Don’t get me wrong, I personally believe there’s value in formal education, and I’ll go into more detail about that later on, but it’s probably not your best choice if you’re looking to get your first developer job. If you’re in a hurry, a four plus year investment (money AND time) is too much and when compared to the six to twelve months of a practical bootcamp, the choice should be obvious.

Do you need more? Yes, a bootcamp, or online education doesn’t cover everything you need to know, but this isn’t what we’re after here. We’re focusing on the practical aspect of the profession, and you can start learning by doing.

Knowledge of the software development life-cycle

A typical software project has to go through a development life-cycle:

You first need to do a requirement analysis to understand exactly what you need to do.
Then move on to planning your project to understand when to do those things and how much time you’ll need.
Designing its architecture comes third. Once you know the “what” and the “when”, you have to start thinking about the “how”, and the architecture gives you the blueprints for that.
Only then, you can start writing code. This is the section where most developers tend to focus on, but as you can see, it’s not the first thing you’d normally do.
Testing your code and your product comes next, understanding if the previous step produced the right output is a must-do before moving on to the next one.
Deploying your product. Giving it to users to allow them to start testing it and giving you feedback.

Because it’s a cycle, you’d take that feedback and normally start all over again, but you get the idea.

Now, if you’ve never worked on a software project before then you’ve never had to apply most of these concepts, and this is perfectly fine. You don’t need to understand any of that to get your first job.

Yes, these will be part of your tasks, and you’ll apply this knowledge every day, but turning it into an entry-level requirement for the role of Jr. dev is like asking an acting surgeon to lead their first surgery. Eventually, they’ll be able to do it and they’ve probably read about it, but you don’t want them doing it on day one.

It’s the same for you as a developer; you shouldn’t be expected to understand what all these steps mean on day one. You won’t be in charge of doing it all anyway. You’ll learn about it because you’ll be part of the process.

A math, physics, or similar degree is needed for understanding programming

I’m guilty of believing this one myself back when I started, but then again, I blame college; they taught me calculus and algebra at the same time I learned to code. Was that a mistake? In the long run, no, it wasn’t, but it did nothing to help me get my first job as a developer.

Math, physics, or any similar sciences aren’t going to help you understand programming. Some of them require you to understand abstract concepts (such as infinity, or the number PI), which can act as practice when you need to create mental models of an algorithm you’re trying to write.

This is where I think the misconception comes from — they require you to flex your abstract thinking muscles.

You won’t be solving hard math problems or implementing difficult physics simulations on your first job, and even if you happen to find yourself in such a conundrum, there’s a big chance you’ll use someone else’s library.

Should you need to get a math degree before making the jump to computer science or a Jr. dev role? No, not at all.

The Role of Data Scientist isn’t an exception

Although the role of a Jr. Data Scientist might require you to, in fact, have one of those degrees, the requirement isn’t for understanding how to code but rather, how to model the problems you’re trying to solve.

Eventually, you might find shared concepts between programming and these other sciences (such as sets in many programming languages), or you might find yourself implementing concepts from other realms into your code (such as implementing the concept of gravity on a platformer game), but none of this is something that requires a full degree before even starting to code.

Certifications

Certifications are tempting because they have that “not-as-long-as-formal-education-but-still-useful” kind of vibe, and they have merit, but they’re not a hard requirement to get a developer job.

Listing certifications on your Jr. dev resume shows you care about your learning and that you care about improving your skills. This is a good thing.

But it’s not a requirement. You won’t find job listings asking for particular certifications from a Jr. developer, instead, they’ll be looking for knowledge about a group of technology. This is easier to achieve by following online courses or bootcamps.

What I’m saying is, if you must choose between investing in a certification or an online course, go for the latter and get a broader education before you start narrowing down on a particular subject.

The desire to work in a fast-paced environment

I personally love this requirement. You can find it on many job listings as well as basic software development skillsets. Truth is, this one is generic enough that it can really mean anything.

What does “fast-paced” even mean here? That term can mean anything honestly, but I’m assuming (because it’s what anyone reading in our context would do), it means you have to be interested in working inside an industry that changes a lot, and by that, I mean changes in technology, working methodologies, project focus, or even projects themselves.

This probably sounds scary, particularly for someone who is not even working yet, but I can confirm that you can be a software developer and still hate “fast-paced” environments. Not everyone likes changing technologies, nor even projects. You don’t have to either.

Granted, startups normally work that way, because they have to. They normally need to grow fast and adapt to changes.

Contractors work like that too. Some companies out there hire you to be part of someone else’s team for the duration of a project, and when it’s done, you move on to the next client.

Both scenarios are great, and if you find that interesting, please go ahead and apply, chances are you’ll enjoy your work.

Some other companies have been working for years on their product(s) and they tend to have a more stable environment. In fact, the perfect example of this is banks (and I should know, I’ve worked for some of them in the past as an external contractor); they have a lot of data from numerous clients, and making changes to their tech stack is quite hard, and honestly, scary for them.

No one choice right because most of the time you don’t get to pick your first company; the fact that they accept your lack of experience is the deciding factor. Keep in mind that because a section of our industry is “fast-paced” doesn’t mean you need to like it or to be looking for that.

Experience

Asking for experience from a Jr dev isn’t only counterintuitive, it’s silly. I’ve been there and I know how it feels when you read a job listing asking for Jr devs with experience in different technologies. You’re sitting there, reading the listing trying to find a job to get the experience. It’s like the egg and chicken problem.

My advice here is to ignore that part of the listing because it makes no sense. Apply if you feel comfortable with some of the other requirements or if you feel like you can pick them up quickly.

The kicker is this: if you apply for the job and are worried about the experience part, you can showcase other types of experience:

If you’ve done some kind of online course, you can list it here.
If you’ve one or more personal projects published somewhere (i.e. on Github, or somewhere else), you definitely want to publish it here.
If you’ve worked as a volunteer on something remotely related to IT, list it here.

Careful though, I’m not saying this is a must-do, requiring experience for an entry-level position makes no sense, and it should not be a prerequisite. If you want to address that point on your application, listing some of the above items is definitely better than saying “none”.

If you’re wondering exactly what you should be focusing on when starting your software development journey, check out this other article!

That’s all for this article. If you want to learn more about the book, check it out on Manning’s liveBook platform here.

From Skills of a Software Developer by Fernando Doglio

Take 35% off Skills of a Software Developer by entering fccdoglio into the discount code box at checkout at manning.com.

I'm Writing a Book for New Developers and I Need Your Feedback!

Fernando Doglio — Thu, 24 Jun 2021 06:12:36 +0000

Hi everyone!
I'm Fernando, long-time user of dev.to, and while I haven't been able to post recently, that's just because I've been crazy busy trying to work on one particular project I'm very excited about.

For the past 6 months or so, I've been working with the folks at @manningbooks to create a book that could act as a bible for any new developer joining our ranks.
What do I mean by "bible"? Essentially I wanted newcomers to understand what it meant to be a developer, how to deal with the usual hurdles of our profession and what to expect from the experience of working as a developer.

You see, I've met people joining our ranks simply because they know the "pay is good", but really have no idea what to expect from our industry.
I've met others coming with completely unrelated backgrounds hoping to turn their lives around and make a living for themselves through coding.

But just like with everything in life, if your expectations aren't set correctly, you're only going to be disappointed, so I want this book to be that for them (amongst other things).

But I need your help, the book's not ready, and while it's already halfway there, there is still time for me to go back and edit any of the chapters, and add any information you think it could help others, so I'm essentially asking for feedback here.

Right now, the book is out on Manning's Early Access Program (MEAP), which means that if you get it, you'll right now get the first 3 chapters, and once the new ones start getting published, you'll be getting them as well. Through their site, you can provide feedback and leave your comments (this is what I need to make the best book possible).

What's in the book?

Now, I'm sure you're wondering what's inside, what kind of information have I deemed worthy of "the bible for new developers", so let me share the ToC for the book, hopefully that'll give you a better idea.

The topics covered are:

What you need to be a developer. There is a lot of misconception around what is needed to become a developer. I personally don't think it's about going to college or having 50 side projects before you get your first job. In fact (spoiler alert), I don't think any tech knowledge is required to be a good developer, that will come with the trade on its own.
Learning how to code (tips&tricks). The book doesn't cover basic programming knowledge, instead, it'll cover recommendations on best practices around commenting code, usual traps such as overengineering, early optimization and the like.
Unit testing. This is such as basic and cross-tech topic that I had to include it. Since I'm not focusing on one particular language, this section covers the generic approach at Unit testing and best practices around it.
Refactoring. Same with refactoring, it's not about doing it with one programming language, but rather, about understanding what it is, when you should do it, and the best practices around it.
Work-life balance. We all know that coding can become your life, however, that can also be a bad thing, it can lead to burnout and thus bad performance at the workplace. This section covers some topics around understanding how to avoid burnout.
Getting past the interview. This section is almost done and I had a lot of fun writing it. It covers everything you need to understand the tech job interview. Especially some tips around what you shouldn't be saying and what to listen for to understand if the job you're being offered is actually good or just a bunch of lies.
Being a good team member. As part of our experience as developers, we can't really expect to be working alone, even as freelancers. This section will explain what it means to be a team player and how to code taking your colleagues (future and current) into consideration.
Leading the team. Finally, because most of the time the usual "next step" for any developer is to start leading some teams, I'll end the book explaining what it means to be a team lead. Recommendations around it such as understanding that you can't be expected to be the guru inside your team, and covering the exact responsibilities of the team lead.

Interested yet? You can check out the book here

Now, a very important aspect to understand, is that this is not generic advice taken from internet.
I've been working inside the IT industry for the past 18 years and I've seen some sh*t.

I've written my share of terrible code, and I've been corrected multiple times. I've seen many horrible managers trying to micro-manage everyone and I've also seen great ones showing me how to grow without holding my hand.
The book covers my own experience around the above topics, my personal preferences when it comes to best practices and essentially everything I've seen that works.

What gives me the right to write this?

Great question, in fact, that's one that you should always ask when reading something someone else wrote. Internet is filled with people trying to teach others without actually knowing what they're talking about.

So here is a summary of me and my career so you get to know me a little bit and understand where this book is coming from.
As I said before, I've been working as part of the industry for 18 years, I started when I was 19, and I'm 37 right now.
I've done Web development working with PHP, RoR, Python, Javascript (vanilla most of it), HTML, CSS and Node.js. And then I made the jump into BigData and started marrying my previous experience with the ability to create scalable and highly available platforms. I've worked with Hadoop, Hive, Kafka and a plethora of other technologies that would be too boring to list here.
During that path, I eventually started leading technical teams, growing my soft skills and while I was doing that I also started to write, both tech articles as well as technical books.
I've written over 150 articles reaching more than 1million people in Medium (not my numbers, check out the image with the actual stat). And I've published 8 books so far (link to my Amazon profile because it's the only place where I have them all listed), most of them around Node.js and JavaScript, this would be the first one that covers more generic aspects of our profession.

I'm currently a Data Engineering Manager working for a big consulting firm, so while I don't have to code every day, I'm still very much in contact with developers trying to mentor them and help them grow in their career.

Am I alone in this?

I'm trying to help those getting started to understand what it means to be a developer and to give them the tools to succeed at this career. But I'm not the only one trying to do it.
There are plenty of other folks doing the same around here, such as @florinpop17 , @wesbos , @dthompsondev and others.
They're all doing work to help others, each one with their own skillset and I can't but look up to them and try to do the same, so this is my own grain of salt.

I would just love to complete this book with your help, making sure that the content I put inside makes sense to you if you're just getting started or if you've been through that process recently.

So to help with that idea, and because let's be honest, I also need the book to be sold to show the folks at Manning that the principle behind it is indeed useful for the community, here is a discount code you can use (I think it'll be valid until the 29th of June) for a 50% off price: mldoglio
Use that during check out and you'll get the discount.

That's it

That's it, that's the announcement, I'm writing a book for everyone that's either thinking about getting started and working as a dev, or those that have just joined our community and are trying to figure out how to fit it.

Get the book here and make sure you leave your thoughts either directly on their page, here in the comments, or reach out to me at fernando.doglio@gmail.com.

React’s onClick Event Handler Explained

Fernando Doglio — Tue, 19 Jan 2021 05:58:34 +0000

Original author: Felix Gerschau

TLDR

The onClick handler allows you to pass a function to a component, which will be executed when it’s clicked.
Call e.preventDefault() to prevent native default behavior, like submitting a form.

const App = () => {
  const sendMessage = (e) => {
    e.preventDefault();
    alert('hi');
  }

  return (
    <button onClick={sendMessage}>
      Send message
    </button>
  )
}

Handling onClick events in functional components

Event handlers are functions that get executed when a given event happens. For example, you can use them to send a message after the user clicks on a button.

You might already know event handlers from plain HTML and JavaScript. Event handlers in React are very similar.

HTML provides us with event handlers like onclick, onchange, onfocus, and many more. We can use them by adding them to the HTML element as an attribute.

<button onclick=”sendMessage();”>
  Send
</button>

We can do the same in React as well. Most of the time, React’s event handlers have the same name as in HTML, but they are written in camelCase. The handlers above would translate to onClick, onChange, and onFocus in React.

<button onClick={sendMessage}>
  Send
</button>

As you can see, it’s not exactly like in the HTML example. First, curly braces ({}) replace the double quotes (”) used in HTML.

Curly braces are using in JSX syntax to separate the markup from JavaScript.

Everything that’s inside the braces is evaluated as JavaScript. Everything outside of them is the markup that will be rendered.

For a more complete picture, let’s see how the complete component may look like.

const App = () => {
  const sendMessage = () => {
    alert('hi');
  }

  return (
    <button onClick={sendMessage}>
      Send message
    </button>
  );
}

Play around with the code of this example on codepen.

Here we see why we needed to put sendMessage in curly braces. We define the sendMessage function as a variable at the beginning of the component.

A common mistake here is to call the function right away (like in the HTML example).

<button onClick={sendMessage()}>

Instead of calling the function when the button is clicked, it will be called every time the component renders.

We only need to pass down the function itself without calling it.

<button onClick={sendMessage}>

Alternatively, you can also inline the function itself.

<button onClick={() => sendMessage()}>

Note how we call sendMessage in the inlined function. We do this because it’s part of the inlined function, which we don’t call right away.

React’s synthetic events

As you may have already heard, React has a virtual DOM, which is an abstraction layer that React uses to optimize renders and some browser-specific features.

This means that even though the code we write in React looks similar to HTML, it’s not quite the same.

I wrote an article on how this works exactly. You can check it out here.

Just like React adds an abstraction on top of the DOM, it also adds an abstraction layer to events. React’s events are called synthetic events.

Synthetic events are a wrapper around events that improve performance and normalize the events so that they look the same across all browsers.

Such events are passed to the event handlers, like onClick. We can use it to access the value attribute of the button element.

const App = () => {
  const sendMessage = (e) => {
    console.log('value', e.target.value); // output: “value somevalue”
    alert('hi');
  }

  return (
    <button value="somevalue" onClick={sendMessage}>
      Send message
    </button>
  )
}

React preventDefault()

Accessing the value attribute is usually done when dealing with text inputs and not in combination with onClick.

What you’ll rather encounter in React applications is the following:

const sendMessage = (e) => {
  e.preventDefault();
  alert('hi');
}

We call the preventDefault function in the event handler, which the synthetic event provides. The name already gives away what it does: It prevents the event from executing the default behavior.

To understand this a little better, we need to know the default behavior of different HTML elements.

If the button element is located inside a form element, the default behavior is to submit the form.

This was fine when HTML forms only had one button anyway, but what if you only want to run the code of the onClick function without submitting the form?

In React, we usually solve this by putting e.preventDefault() at the beginning of the event handler.

Alternatively, you could also solve this natively by changing the type attribute of the button:

<button type=”button”>Click me!</button>

Form elements have an even worse default behavior: They refresh the entire page after the onSubmit event—not something you want to happen in a Single Page Application.

Handling onClick events in class components

In the previous section, I only focused on functional components. While this is the easiest way of writing components in React, you'll still encounter components written as JavaScript classes from time to time.

So let's have a look at the previous example as a React class:

class App extends React.Component {
  sendMessage = (e) => {
    e.preventDefault();
    console.log('value', e.target.value); // output: “value somevalue”
    alert('hi');
  };

  render() {
    return (
      <button value="somevalue" onClick={this.sendMessage}>
        Send message
      </button>
    );
  }
}

As you can see, the way we handle onClick events in React classes is the same as in functional components. The function sendMessage is now part of the App class, which is why we access it via this.

In case you were wondering why I defined sendMessage as a variable and not as a method of the class: This is to preserve the scope of the class inside the function, which practically means that I will be able to call this.setState inside the function.

Observability for Production React Apps

Debugging React apps in production may be challenging and time consuming. Asayer is a frontend monitoring tool that replays everything your users do and shows how your app behaves and renders for every issue. It’s like having your browser’s inspector open while looking over your user’s shoulder.

Asayer helps to quickly get to the root cause by reproducing issues as if they happened in your own browser. It also monitors your frontend performance by capturing key metrics such as page load time, memory consumption and slow network requests as well as Redux actions/state.

Happy debugging, for modern frontend teams - Start monitoring your web app for free.

Original author: Felix Gerschau

7 Ways of Achieving Conditional Rendering in React

Fernando Doglio — Sat, 09 Jan 2021 05:15:18 +0000

Choosing when to show a piece of your UI should be as easy as writing an IF statement:

if(condition_is_met) {
  renderSectionOfUI();
}

However, given the component-based nature of React, and the mixture of HTML and JavaScript known as JSX, that IF gets a little bit more complicated depending on where exactly we want to add it. Should we add it as part of our component’s code? Can we add an IF right in our HTML? Are there other options?
In this article, I’m going to be covering the 7 most common ways of achieving what is known as “conditional rendering” in React. This should give you an idea of what is possible to do and why.

Implementing conditional rendering

Although choosing to conditionally render a component should be easy, to make it easy we need to understand the behavior of the framework we’re using. Simply put, we can’t just add an IF right inside our JSX code, because JSX is nothing more than syntactic sugar, designed for our benefit but lacking any magic that we might want to attribute to it.
Put simply, the following JSX code:

ReactDOM.render(<div id="error-box">This is my error message!</div>, mountNode);

Is translated into:

ReactDOM.render(React.createElement("div", {id:"error-box"}, "This is my error message!"), mountNode);

And adding an IF inside our code like this:

ReactDOM.render(<div id={if (condition) { 'error-box' }}>This is my error message!</div>, mountNode)

Would translate to the following, invalid JS (you can’t add an IF as the value of a JSON key):

ReactDOM.render(React.createElement("div", {id: if (condition) { 'error-box' }}, "This is my error message!"), mountNode);

But don’t worry, there are more options available to achieve exactly this (and even more complex behavior) than you might ever need, and we’ll take a look at them right now.

Using IF/Else inside your components

This is the most straightforward and easy to understand, since it directly covers JS and how JS works. You don’t need to worry about JSX here or anything.
This technique requires you to extract the IF statement I showed before and add it before the call the render. All you have to remember is to set the correct value for the id attribute inside a variable and then you can use it in JSX normally:

render() { 
 //your component's render method....
  let idAttr = ''
  if(condition) {
    idAttr = 'error-box'
  }
  //... more logic here...
  return  (<div id={idAttr}>This is my error message!</div>)
}

You can do the same with a functional component as well as the following variation:

const myMsgBox = () => {
  let idAttr = ''
  if(condition) {
    return (<div id="error-box">This is my error message!</div>)
  }
  return (<div id="msg">Normal message, no error here!</div>)
}

Either case, they would work and you would have your conditional rendering logic ready.

JSX syntax: taking advantage of JavaScript’s `&&`

But of course, there are other ways of doing the same thing, because this is programming after all.
As I already mentioned, you can’t add an IF statement inside your JSX, because it doesn’t translate well into proper JS. However, you can use a boolean expression instead.
Have you ever seen code like this?

function fnName(optionalAttr) {
  let myVar = optionalAttr && "default value";
  //...more logic here
}

In JS the above code would assign the string "default value" to the variable myVar if optionalAttr wasn’t present. Of course, it would also assign the default value if optionalAttr was an empty string or the numeric value 0. This is because we’re using a boolean expression that, by default in JS, always evaluates until it finds a falsy value.
For us, this means we can add our condition for render before the call to the component that needs to be rendered. This in turn, would cause our component to only be shown if the condition is true.
Something like this:

function MyComp(props) {
  const errorCondition = props.errorCondition;
  return (
    <div>
      <h1>Hello!</h1>
      {errorCondition && 
         <errorMessage>This is an error</errorMessage>
      }    
    </div>
  );
}

We’re conditionally rendering our errorMessage component only if the errorCondition variable has a truthy value, otherwise JS will stop evaluating our code in that variable and it would never reach the errorMessage portion of our logic.

The ternary operator

Given the fact that we can do that with the && operator, we can also do something very similar with the ternary operator. Otherwise known as inline IF, which allows us not only to conditionally render a component (or part of it) but also to add an “else” behavior.
Check it out:

function MyComp(props) {
  const errorCondition = props.errorCondition;
  return (
    <div>
      <h1>Hello!</h1>
      {errorCondition  
         ? <ErrorMessage>This is an error</ErrorMessage>
         : <InfoMessage>Hey there bud! Nothing wrong here, carry on!</InfoMessage>
      }    
    </div>
  );
}

Notice how we’re even able to structure it in a way that it looks like an IF statement somehow. I mean, IT IS an IF statement, in essence, but written as an expression, which is valid for JS. This will either, render the ErrorMessage component if errorCondition evaluates to TRUE or otherwise it will render InfoMessage.
Note that this is a value expression, because just like in the previous example, you could potentially assign the result to a variable (since it returns the result of evaluating either one of the sub-expressions inside it):

function fnName(optionalAttr) {
  let myVar = (optionalAttr != null) ? "default value" : optionalAttr;
  //...more logic here
}

The above code will assign "default value" to myVar only when optionalAttr is null, otherwise it will always assign its value.

Using `null` to avoid rendering

This is yet another way of choosing to avoid rendering a component, but this time it has nothing to do with how JS uses conditions and more to do with how React behaves.
As you may or may not know, React will not render a thing in place of your component, if its render method (or itself if it’s a functional component) returns null.
So if we want to move the conditional rendering logic to inside our affected component (as opposed to having it outside, as part of another component), we can do so by making it return null when it needs to hide.
Given the following consuming component:

class Page extends React.Component {
  constructor(props) {
    super(props);
    this.state = {showError: true};
  }
  //more methods here...
  render() {
    return (
      <div>
        <ErrorMessage show={this.state.showError} />        
      </div>
    );
  }
}

We can write our ErrorMessage component like this:

function ErrorMessage(props) {
  if (!props.show) { return null; }
  return (
    <div className="error">
      Error!
    </div>
  );
}

I like this solution better because it keeps JSX code (i.e presentation code) clean, while hiding the logic behind whether or not a component should be rendered inside pure JS and I’m all about separation of concerns.
This way we keep our view code focused on presentation and structure, while our JS code takes care of any logic we need.

Understanding IF components:

Following on that same note, we can go even one step further, and hide the entire IF statement logic inside a component. This in turn would create a hybrid of a component, one that instead of representing a visual component, would represent a logic component, but still keeping the view code clean by only writing HTML-like tags.
I’m of course, referring to the IF component.
In JS we write our IF statements following always the same pattern:

if(condition) {
   truthyBehavior()
}

And our IF component is no different, we can do something like this by taking advantage of child components:

<IF condition={condition}>
   <TruthyBehavior>
</IF>

And as long as condition is a value boolean expression, we can write our IF component like this:

function IF(props) {
  if(props.condition) {
    return props.children
  }
  return null;
}

Notice how we’re also using the null default behavior here.
By creating this generic component, we can use it across our projects, adding logic to our view code with minimum impact.
The problem with this implementation, is that the child components will be evaluated regardless of the condition and only shown if we need to. This can potentially be a problem if you link the children with the condition.
For example:

<IF condition={user != null}>
  <Greeter username={user.name} />
</IF>

In this case, we would see an error message from the browser, stating that user is null, even though we intended that code to only be executed if user was defined. This is a problem because even though our code might resemble a normal IF statement, it is not and we’re tricked to mentally follow the expected behavior.
This means we’re either forced to keep this behavior in mind or change our component into something that uses functions to encapsulate logic we want:

function IF(props) {
  if(props.condition) {
    return props.onTrue()
  }
  return null;
}

And then we can use it like this:

<IF condition={user != null} onTrue={() => {
   <Greeter username={user.name} />  
  }
 }/>

The resulting code is not as clean, but it gets the job done. Now since we’re only executing our code when the anonymous function gets called, we’re safe to use the user.name property.
Writing a proper and safe IF component is not easy, so keep reading to find out other ways of conditionally rendering a component.

Frontend Monitoring

Debugging a web application in production may be challenging and time consuming. Asayer is a frontend monitoring tool that replays everything your users do and shows how your app behaves for every issue. It’s like having your browser’s inspector open while looking over your user’s shoulder.

Asayer lets you reproduce issues, aggregate JS errors and monitor your app’s performance. Asayer offers plugins for capturing the state of your Redux or VueX store and for inspecting Fetch requests and GraphQL queries.

Happy debugging, for modern frontend teams - Start monitoring your web app for free.

Using HOCs to achieve conditional rendering

HOCs or Higher-Order Components are functions that accept components as parameters and return new ones as a result of their execution.
They help create wrapper components if you will, that can help us add logic (more specifically, rendering logic) to a plain component. Or that can also help us, extract logic into a generic component, letting us clean up our main component’s code.
For example, let’s take another look at our running example component:

function ErrorMessage(props) {
  if (!props.show) { return null; }
  return (
    <div className="error">
      Error!
    </div>
  );
}

We could create a HOC that removes the first IF statement from the component, like this:\

function showOnlyWhenNeeded(conditionalFn, component) {
 return function(props) {
  if(conditionalFn(props)) {
    return component(...props)
  }
  return null
 }
}

We can then, proceed to use this HOC like this:

//...your code
function ErrorMessage(props) {
  //no more IF statement here
  return (
    <div className="error">
      Error!
    </div>
  );
}

let betterErrorMessage = showOnlyWhenNeeded(props => props.show, ErrorMessage)

//... more code here
<betterErrorMessage show={condition} />

This approach has two immediate benefits:

The code for your component gets cleaned up, because it no longer requires adding the conditional rendering logic inside it. That part is abstracted into an external function,
The conditional rendering logic can be extended simply by adding more function composition to the mix.

Look at the following example:

let betterErrorMessage = showOnlyWhenNeeded(props => props.show, ErrorMessage)
let myBetterErrorMessage = showOnlyWhenNeeded(props => props.username == "fernando", betterErrorMessage)
let myBetterErrorMessageForHomepage = showOnlyWhenNeeded(props => props.currentpage == 'home', myBetterErrorMessage)
//... more code here
<myBetterErrorMessageForHomepage show={condition} username={currentUser} currentPage={page} />

Granted, the example might be a little basic, but you get the point. I added three different rendering conditions to my component without having to modify its code. That’s a win in my book.

Using fragments to achieve conditional rendering

Fragments allow you to return a set of elements or components without a wrapping HTML tag.
For example, a classic example would be to create a component that needs to render several table cells inside a row, like this:

function tableRow() {
  ///your logic here
  return (<tr>
          {tableCells()}
          </tr>)`
}

A normal tableCells component would need to return several td elements. However, we would have to wrap them inside another tag, like a div, which in turn would break everything. For this scenario, React added the concept of Fragments. By using them, we can return a set of elements inside a generic, non-descript tag only used by React itself, like this:

function tableCells() {
  return (<>
          <td>Val1</td><td>Val2</td>
         </>)
}

And we can use this concept to also add conditional rendering to fragments. In fact, we can just use any of the methods listed so far, they all work with fragments.
The following component shows how to return a list of fragments, out of which, only some of them get rendered:

function Lines() {
    let children = ['Some text.',
                    <h2>A heading</h2>,
                    'More text.',
                    <h2>Another heading</h2>,
                    'Even more text.']
    return (
      <>
      {children.map( (child, idx) => {
         if(idx % 2 == 0) return child;
         return null;
       })
       }</>
     );
  }

As you can appreciate, the rendering logic is added inside the component on the return statement, by returning null for the children that won’t need to be rendered.

Conditional rendering with Hooks

Functional components and hooks simplified the way we think about components and the way we write them. However, when you’re working with conditionally rendered components, sometimes this new way of writing them might get in the way.
One thing that not everyone takes into account, is that React relies on the fact that functional components need to always call the same hooks in the same order. This is crucial for everything to work.
If you have a component looking like this:

function myComp(props) {
  let state, setState = useState({name: 'Fernando'})

  if(state.name == 'Mary') {
    useEffect(function persistForm() {
      localStorage.setItem('formData', state.name);
    });
  }

  //more code here
}

The useEffect hook will not always be called, and this is not gonna work with React. T is why if we attempt to use some of the techniques shown so far inside our functional components and affect the way hooks are called, our conditionally rendered component is going to make our app go “boom”.
In other words, this will not work:

function myComp(props) {
  if(!props.show) return null;

  let state, setState = useState({name: 'Fernando'})

  useEffect(function persistForm() {
    localStorage.setItem('formData', state.name);
  });

  //more code here
}

Just add that first line at the bottom, and deal with any if -based condition for your other hooks inside them. Like the useEffect hook, if you need to only have that logic working when the component is being rendered, add that if inside its callback:

function myComp(props) {
  let state, setState = useState({name: 'Fernando'})

  useEffect(function persistForm() {
    if(props.show){
      localStorage.setItem('formData', state.name);
    }
  });
  if(!props.show) return null;
  //more code here
}

Either that, or just rely on any of the other techniques that don’t affect the order of execution of the hooks.

Performance considerations

Conditional rendering in React is great and allows for very dynamic behavior, however, it does not come free. Depending on how you decide to implement it, the performance costs can be considerable.
Of course, there are many optimizations you can implement regarding your own code and logic associated with your rendering logic, however, there is one big topic to understand about React before you decide to call it a day: React cares about the order in which you render your components.

Essentially, if your rendering logic will keep moving components out of order, then all associated components will have to be unmounted and remounted again, even the ones you’re not trying to hide or show.
Let me explain:

The most common example, happens if you follow the first technique described here (mind you, this will only become a problem if you’re overusing it, otherwise the performance penalty is barely visible).
With our first example, we were doing something like this:

const myMsgBox = () => {
  let idAttr = ''
  if(condition) {
    return (<div id="error-box">This is my error message!</div>)
  }
  return (<div id="msg">Normal message, no error here!</div>)
}

Visually, we’re getting our results, because we’re either rendering an error box or an info box. But internally, React is having to unmount both components every time the rendering condition changes. And this problem is even more apparent when we do something like this:

const myMsgBox = () => {
  let idAttr = ''
  if(condition) {
    return (<div>
              <ErrorBox id="error-box">This is my error message!</ErrorBox>
              <InfoBox>This text is always visible</InfoBox>
            </div>)
  }
  return (<div>
            <InfoBox>This text is always visible</InfoBox>
          </div>)
}

We’re not using 2 different components inside our myMsgBox one. We’re telling React that if there is an error, we need to show the ErrorBox as well as the InfoBox with a permanent message. However, as logic would dictate, if there is nothing wrong, we don’t need to render the ErrorBox. The problem here? That on our first render, with let’s say, no error condition, React rendered the InfoBox on position #1, but on the second render, with an error condition, the component rendered in position #1 will be the ErrorBox while also having the InfoBox rendered on position #2.

Abusing this behavior will cause React to keep mounting and unmounting our components, even though some of them need to be present all the time (i.e the InfoBox). The way to solve this, is to go for a technique, such as the null-based one. Because if a component is replaced by null, the “slot” it occupies will not be replaced by the next component in line, instead, it will be help there, empty sort of speak, by the null value.
For example, something like this:

const MyMsgBox = () => {
  let [condition, setCondition] = React.useState(false)
  return (<div>
          {condition && 
                  <ErrorBox id="error-box">This is my error message!</ErrorBox>}
            <InfoBox>This text is always visible</InfoBox>
            <button onClick={() => setCondition(!condition)}>Toggle</button>
          </div>)
}

Every time we click the button, it will change the component’s state, and the condition will be updated. Because we’re using this circuit-break syntax, when the condition value is false, it will leave a false value instead of the ErrorBox component (which means the same as a null value), and when it’s true, it will render mount and render the ErrorBox correctly. The InfoBox component is never touched nor affected.

Closing thoughts

Conditional rendering with React is a relatively easy thing to do, the hard part is doing it in a way that solves your problem correctly.
There are performance considerations to account for, of course, such as the ones mentioned above, but you also need to consider the effect your logic will have on your code. The moment you start adding behavior to your presentation, you have to remember to keep best practices present as well. Keep your view code clean, or at least as clean as possible. Remember, JSX is not HTML nor JavaScript, it’s a mixture, but it doesn’t mean you have to forget about separation of concerns!

Leave a comment if I forgot to add your favorite conditional rendering technique or if you have a favorite from the 7 listed here!