Forem: Product Hackers

Code smell | Side Effects

Jesús Mejías Leiva — Wed, 29 Nov 2023 13:09:25 +0000

Hello, today I am writing again and in this post I am going to introduce you to how we incur in a frequently common code smell called "Side Effects," which occurs when a function modifies an external state beyond its own scope.

Cause

Side effects arise when a function alters variables outside its scope, leading to unexpected behaviors and complicating code comprehension.

Example

let total = 0

function addToTotal(value: number): void {
  total += value
  console.log(`Total is now: ${total}`)
}

addToTotal(5)

Solution

An effective solution is to avoid side effects by using pure functions that do not modify external states. Instead of changing global variables, the function should return a new state.

function addToTotal(currentTotal: number, value: number): number {
  const newTotal = currentTotal + value
  console.log(`Total is now: ${newTotal}`)
  return newTotal
}

let currentTotal = 0
currentTotal = addToTotal(currentTotal, 5)

Benefits

Improves Readability: By eliminating side effects, the code becomes clearer and more understandable, making it easier for developers to grasp the execution flow without unexpected surprises.
Facilitates Maintenance: Side-effect-free functions are easier to maintain as their behavior is confined to their scope, avoiding potential conflicts with other parts of the program.
Reduces Unexpected Errors: By avoiding external modifications, the likelihood of subtle errors arising from unexpected changes in variable states is minimized.
Promotes Predictability: Functions without side effects yield consistent results, promoting code predictability and facilitating unit testing.
Enhances Scalability: Code that avoids side effects is more modular and adaptable, easing scalability as the system grows and evolves.

Thanks for reading me 😊

The importance of prioritizing code optimization for humans rather than machine

Jesús Mejías Leiva — Tue, 05 Sep 2023 12:25:01 +0000

In the world of programming, the search for efficiency is a constant. Developers often face the decision to write highly optimized but less readable and maintainable code, or prioritize clarity and ease of maintenance to the detriment of efficiency. In this article, I will present my arguments to justify why in most software projects it is more important to prioritize the optimization of code for humans instead of doing it for machines, highlighting the benefits of maintainability and readability in software development, and why this practice in most cases exceeds the advantages of efficiency.

Long-term maintainability

One of the main arguments in favor of prioritizing the readability and maintainability of the code is the fact that the useful life of most software projects extends far beyond the initial phase of development. As a program evolves and is updated, development teams change, and new developers join the project, a quick and accurate understanding of existing code becomes a critical factor.

If you opt for an extreme optimization approach that sacrifices clarity, it is likely that unnecessary obstacles will be created for future developers. This can result in an increase in maintenance costs, since troubleshooting, bug fixes and updates become more difficult and error-prone.

Effective collaboration

The readability of the code is essential for effective collaboration in software development. Development teams are usually made up of multiple members who work in different parts of the project. The clarity in the code facilitates communication between developers and allows a better understanding of how the various parts of the system work.

When the code is illegible or lacks adequate feedback, collaboration becomes less efficient. Developers can waste time trying to understand what a colleague did or debug problems that could have been avoided with clearer code.

Time and resources

Although extreme optimization can offer efficiency gains in terms of execution speed, these gains are often negligible compared to the time and resources needed to achieve that optimization. The search for extreme efficiency usually requires more development time, which can delay the delivery of the final product.

In addition, the time invested in extreme optimization could be used more effectively in improving functionality, correcting errors or implementing additional features that provide real value to the end user.

Adaptability and scalability

The prioritization of readability and maintainability also translates into greater adaptability and scalability of the software. A well-structured and easy-to-understand code is easier to modify and expand according to the changing needs of the project. In contrast, an excessively optimized code could require significant rewriting to make changes, resulting in greater rigidity and additional costs.

The lowest cost of hardware versus the salary cost of development

In the constant search for efficiency in software development, it is essential to consider how the lower price of hardware today can influence our decisions about code optimization. The reality is that the cost of human resources, in terms of salaries and benefits, is considerably higher than the cost of the hardware needed to run most modern applications.

The evolution of hardware

The technology industry has witnessed surprising advances in computing power and storage capacity over the years. What used to require expensive servers and high-performance equipment in the past, can now be run effectively on much more affordable hardware. Cloud servers and cost-effective web hosting options have democratized access to state-of-the-art hardware resources.

The cost of software development

On the other hand, the cost of hiring and retaining highly trained software developers has increased significantly. Developers are a valuable resource and competitive salaries, benefits, training and retention are essential investments for companies. In addition, as technology advances, the demand for specialized developers also increases, which can lead to greater competition and even higher costs.

Balance between human resources and hardware

From this perspective, the decision to prioritize the optimization of the code for humans, focusing on readability and maintainability, makes even more sense. Even if additional hardware is required to maintain optimal performance, this cost is usually lower compared to the salaries and expenses associated with software development.

When we optimize the code to be clearer and easier to maintain, we reduce the time that developers must invest in understanding and modifying the existing code. This translates into a more efficient use of human resources and, ultimately, long-term cost savings.

Conclusions

While the efficiency in the execution of the code is still important, the cost-benefit ratio of investing in more powerful hardware instead of additional human resources is increasingly evident. Current technology gives us the ability to run applications efficiently on affordable hardware, while the cost of developers remains a significant factor in the development budget.

Therefore, prioritizing code optimization for humans, by improving readability and maintainability, becomes an intelligent economic strategy that benefits both the company and developers, by ensuring efficient and sustainable software development in the long term.

Thanks for reading me 😊

Code smell | Hardcoded fake data in tests

Jesús Mejías Leiva — Sun, 21 May 2023 17:36:33 +0000

Hello, today I am writing again and in this post I am going to introduce you to how we incur in a frequently common code smell called Hardcoded fake data in tests, this code smell occurs when you see fake data that is needed for tests within the same test file.

Cause

When fake data is observed in the test files making them difficult to read and maintain.

Example

Suppose we have the following type to represent a user:

export type User = {
  id: string
  firstName: string
  lastName: string
  email: string
  phone: string
  active: boolean
}

And some functions inside a utils file to apply different filters to an array of users:

export const filterByActivated = (users: User[]): User[] =>
  users.filter((user) => user.active)

export const filterByValidEmail = (users: User[]): User[] => {
  const VALID_EMAIL_REGEX =
    /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

  return users.filter((user) => VALID_EMAIL_REGEX.test(user.email))
}

Now let's see how the tests of the functions of our utils would look like:

// utils.test.ts
import { User } from './types/User'
import { filterByActivated, filterByValidEmail } from './utils'

describe('utils', () => {
  it('filterByActivated', () => {
    const mockActivatedUser: User = {
      id: '1',
      firstName: 'Jhon',
      lastName: 'deville',
      email: 'test@test.com',
      phone: '000000000',
      active: true
    }

    const mockDeactivatedUser: User = {
      id: '2',
      firstName: 'Marta',
      lastName: 'deville',
      email: 'test@test.com',
      phone: '100000000',
      active: false
    }

    const activatedUsers = filterByActivated([
      mockActivatedUser,
      mockDeactivatedUser
    ])

    expect(activatedUsers).toEqual([mockActivatedUser])
  })

  it('filterByValidEmail', () => {
    const mockUserWithValidEmail = {
      id: '1',
      firstName: 'Jhon',
      lastName: 'deville',
      email: 'test@test.com',
      phone: '000000000',
      active: true
    }

    const mockUserWithInvalidEmail = {
      id: '2',
      firstName: 'Marta',
      lastName: 'deville',
      email: 'test.com',
      phone: '100000000',
      active: true
    }

    const usersWithValidEmails = filterByValidEmail([
      mockUserWithValidEmail,
      mockUserWithInvalidEmail
    ])

    expect(usersWithValidEmails).toEqual([mockUserWithValidEmail])
  })
})

Apparently it seems like a quite innocuous test but it is hiding several problems that we will find when having to make some change in the User type, for example if we were asked to add a new field to it it would cause a forced modification of all the tests that depend on it. of it and have the fake data hardcoded.

This should not happen and the answer is very simple, why should I modify the test suite if I add a field, for example, to store the user's date of birth? What relationship does this field have with my tests? correct, the answer is none, hence it does not make sense to have to modify them, and this is not the worst, if we extend this practice through our code, as you will suppose, each change in the User type will cause cascading changes of all the tests related to it, which doesn't make any sense.

Solution

To solve this smell we will rely on two libraries, in our case when using typescript we will use the compatible versions of:

Fishery, will help us build factories based on types, in our case we will use User, in this way we will centralize the changes of it in a single point.
Faker-js, provides us with a very complete API to generate fake data of different types randomly.

In the event that your language is not compatible with these libraries, it will be necessary to look for alternatives or build your own small factory utility.

If we put both together we can create users based on a data model with fake random data.

Sounds good right? Let's see how this factory would look like:

// UserFactory.ts
import { Factory } from 'fishery'
import { faker } from '@faker-js/faker'

import { User } from '../types/User'

export default Factory.define<User>(({ sequence }) => ({
  id: `${sequence}`,
  firstName: faker.name.firstName(),
  lastName: faker.name.lastName(),
  email: faker.internet.email(),
  phone: faker.phone.number('+34 ### ### ###'),
  active: faker.datatype.boolean()
}))

Now we will use the factory in our tests as follows:

// utils.test.ts
import userFactory from './factories/userFactory'

import { filterByActivated, filterByValidEmail } from './utils'

describe('userFilter', () => {
  it('filterByActivated', () => {
    const mockActivatedUser = userFactory.build({
      active: true
    })

    const mockDeactivatedUser = userFactory.build({
      active: false
    })

    const activatedUsers = filterByActivated([
      mockActivatedUser,
      mockDeactivatedUser
    ])

    expect(activatedUsers).toEqual([mockActivatedUser])
  })

  it('filterByValidEmail', () => {
    const mockUserWithValidEmail = userFactory.build()

    const mockUserWithInvalidEmail = userFactory.build({
      email: 'test.test'
    })

    const usersWithValidEmails = filterByValidEmail([
      mockUserWithValidEmail,
      mockUserWithInvalidEmail
    ])

    expect(usersWithValidEmails).toEqual([mockUserWithValidEmail])
  })
})

As can be seen, in addition to making our tests much cleaner, we gain a lot in flexibility and maintainability, since if we are now asked to add a field to our User type where we are going to store date of birth, we will only have one modification point, the factory of our tests, in this case our tests do not have to worry about said change.

Benefits

Flexibility
maintainability
Readability
Greater robustness by having to support the cases derived from the creation of content randomly
Type inference if we use typescript

Thanks for reading me 😊

Design pattern | Criteria

Jesús Mejías Leiva — Sun, 19 Mar 2023 12:04:25 +0000

We start this new series with the pattern called Criteria,
This pattern allows you to build search queries using a common interface,
which makes the code much more modular and flexible.

Uses cases without Criteria pattern

I have assembled the examples with Typescript but the implementation of said pattern is equally valid for other languages.

Let's see an example where the use of the Criteria pattern can help us.

First of all we are going to create a very simple type to define what is a Client for our domain:

interface Client {
  name: string;
  age: number;
  gender: 'M' | 'F',
  city: string
}

then suppose we have to perform several filters to the following list of clients:

const clients: Client[] = [
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'John', age: 15, gender: 'M', city: 'London' },
  { name: 'Marta', age: 14, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
]

Clients who are over 15 years old:

const clients: Client[] = [
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'John', age: 15, gender: 'M', city: 'London' },
  { name: 'Marta', age: 14, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
]

clients.filter(client => client.age > 15)

/*
[
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
];
*/

Now we are going to complicate the query a bit,
imagine that we are asked to obtain the clients whose age is older than 20 and younger than 30 years old,
who are women and your city is Madrid or Barcelona

const clients: Client[] = [
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'John', age: 15, gender: 'M', city: 'London' },
  { name: 'Marta', age: 14, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
]

clients.filter(client =>
  (client.age > 20 && client.age < 30) &&
  client.gender === "F" &&
  (client.city === 'Madrid' || client.city === 'Barcelona')
)

/*
[
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' }
];
*/

As we can see, things start to get complicated and it starts to be difficult to maintain and read,
In addition, at the semantic level there is a large margin for improvement,
for this, we will see how we can improve these aspects by applying the Criteria pattern.

Same complex use case with Criteria pattern

We start by creating the interface that will define our Criteria, we will use typescript generics for it
to gain flexibility:

interface Criteria<T> {
  meetCriteria(items: T[]): T[]
}

We continue creating a Composite class that implements our Criteria interface, it will also allow us to
maintaining an array of criterias to apply and of course the implementation of the required meetCriteria method
upon implementation, the addCriteria method will allow us to add criteria that will function as AND:

class CompositeCriteria<T> implements Criteria<T> {
  private criteriaList: Criteria<T>[] = []

  addCriteria(criteria: Criteria<T>): void {
    this.criteriaList.push(criteria)
  }

  meetCriteria(items: T[]): T[] {
    let result = items

    for (const criteria of this.criteriaList) {
      result = criteria.meetCriteria(result)
    }

    return result
  }
}

Finally, as I mentioned above, the addCriteria when adding criteria to a list would work implicitly
as an AND therefore we will need to make an implementation to be able to do OR operations:

class OrCriteria<T> implements Criteria<T> {
  constructor(private firstCriteria: Criteria<T>, private secondCriteria: Criteria<T>) {}

  meetCriteria(items: T[]): T[] {
    const firstResult = this.firstCriteria.meetCriteria(items)
    const secondResult = this.secondCriteria.meetCriteria(items)

    return Array.from(new Set([...firstResult, ...secondResult]))
  }
}

How to use this new Criteria API

First of all we will create some queries which will help us in the construction of our filter:

const ageOlderThanTwentyYearsCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.age > 20)
  }
};

const ageYoungerThanThirtyYearsCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.age < 30)
  }
}

const madridCityCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.city === 'Madrid')
  }
}

const barcelonaCityCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.city === 'Barcelona')
  }
}

const femaleCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.gender === 'F')
  }
}

This is where the magic happens since we will be able to mount the filtering to our liking and with much greater semantics,
I am sure that if I give you this code you will know very quickly which filter is being built:

const clients: Client[] = [
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'John', age: 15, gender: 'M', city: 'London' },
  { name: 'Marta', age: 14, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
]

const compositeCriteria = new CompositeCriteria<Client>()

compositeCriteria.addCriteria(ageOlderThanTwentyYearsCriteria)

compositeCriteria.addCriteria(ageYoungerThanThirtyYearsCriteria)

compositeCriteria.addCriteria(
  new OrCriteria(
    madridCityCriteria,
    barcelonaCityCriteria
  )
)

compositeCriteria.addCriteria(femaleCriteria)

compositeCriteria.meetCriteria(clients)

/* Same result
[
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' }
];
*/

Benefits

Better maintainability of code.
Better readability.
Allows you to make complex filters more easily.
Move code to semantics of our domain.

Thanks for reading me 😊

Code Smell | Switch Statements

Jesús Mejías Leiva — Tue, 31 Jan 2023 09:19:02 +0000

Hello, today I am writing again and this post I am going to introduce you to how we incur in a frequently common
code smell called Switch Statements, is caused by the abusive use of the switch statements in our code.

The use of the switch structure is perfectly valid

I do not seek to try to avoid its use in 100% of cases but in a large percentage in which it will harm us.

Cause

The abusive use of the switch statements.

As I mentioned above, it is not always advisable to eliminate the switch, an example of this is the design patterns,
in particular I would highlight the so-called Factory Method or
Abstract Factory, it is very frequent to see its use.

Example

Let's see an example of a switch statement that is not very advisable to use:

type Fruit = 'apple' | 'banana' | 'orange' | 'pineapple' | 'raspberry'

const getFruitEmoji = (fruit: Fruit) => {
  switch (fruit) {
    case 'apple':
      return '🍎'
    case 'banana':
      return '🍌'
    case 'orange':
      return '🍊'
    case 'pineapple':
      return '🍍'
    default:
      return '🍇'
  }
}

Solution

We will replace the switch with a simple object which will allow us to search by key.

type Fruit = 'apple' | 'banana' | 'orange' | 'pineapple' | 'raspberry'

const getFruitEmoji = (fruit: Fruit) => {
  const FRUIT_EMOJI_MAP = {
    apple: '🍎',
    banana: '🍌',
    orange: '🍊',
    pineapple: '🍍',
    raspberry: '🍇'
  }

  return fruitEmojiMap[fruit] 
}

I have created a small example to show one of the most common ways to eliminate this smell,
especially in functional programming, the example could be more complicated if instead of emojis with function calls,
but the way to proceed would be the same.

To correct this smell in object-oriented programming, it is common to use polymorphism if necessary,
we must always analyze our code beforehand.

Benefits

Less code.
Improves legibility.
Improves maintainability, you can export this object and use in a others parts of your application.

Thanks for reading me 😊

Code Smell | Too Many Imports

Jesús Mejías Leiva — Thu, 20 Oct 2022 10:43:34 +0000

Hello, today I am writing again and this time I am going to introduce you to how we incur in a very common code smell called Too Many Import, is caused by the abusive use of imports in components, classes or any other type of module of our project.

Cause

It seems like a very harmless Code Smell but it can indicate that we are breaking very important principles such as:

Coupling
Low cohesion
Violation of the SRP (Single Responsibility Principle)

Example

In the following example we can see how up to 13 imports are carried out, which should lead us to think if our component does not have too many responsibilities:

import one from "...";
import two from "...";
import three from "...";
import four from "...";
import five from "...";
import six from "...";
import seven from "...";
import eight from "...";
import nine from "...";
import ten from "...";
import eleven from "...";
import twelve from "...";
import thirteen from "...";


export default function Example() {
  //... code
}

Solutions

In the first place, it may seem a bit obvious, but we should review the use of these imports and assess if they are all essential for the correct functioning of the component.
As you can imagine, the solution to this involves separating responsibilities and dividing this component into several smaller ones or even extracting logic to hooks, although in this case, in order not to introduce many concepts, we will propose a solution based on dividing it into several smaller components:

FirstComponent

import one from "...";
import two from "...";
import three from "...";
import four from "...";
import five from "...";

export default function FirstComponent() {
  //... code
}

SecondComponent

import six from "...";
import seven from "...";
import eight from "...";
import nine from "...";

export default function SecondComponent() {
  //... code
}

ThirdComponent

import ten from "...";
import eleven from "...";
import twelve from "...";
import thirteen from "...";

export default function ThirdComponent() {
  //... code
}

Finally the ExampleComponent , it would stay like this:

import FirstComponent from "./FirstComponent";
import SecondComponent from "./SecondComponent";
import ThirdComponent from "./ThirdComponent";

export default function Example() {
  //... code
}

We can see that we have reduced the number of import by a large number, but this does not end here, by making this division we are delegating the responsibilities to each component.

Warning!

Therefore, like every Code Smell, this one must be carefully analyzed before applying any solution, since a hasty decision can cause some side effects.

Not all are advantages, below we will see some disadvantages that we must consider when applying these splits:

In some cases we can incur in a premature optimization, especially in small projects that do not need much maintenance.
They can have many components, classes etc if the project has considerable dimensions.

Bonus Track

To help us take more into account the number of imports we can use our linter, for example in the case of using eslint we have a rule inside the eslint-plugin-import plugin called import/max-dependencies
which we can configure to help us with this smell.

Thanks for reading me 😊

Do not reinvent the wheel

Conti — Mon, 22 Aug 2022 09:01:43 +0000

There are times when you feel like a god because you think you can build anything, technically speaking, and sometimes you feel useless because the product owner needs you to find a solution for a specific problem and, instead of using an already mature and developed third-party product, you find yourself in your own development roadmap for a similar tool, built from zero. So your frustration grows because you think you have the skills to build that solution, but delivery timing would be out of question since the value needs to be delivered the following week.

As a developer your lines of code value is null, the real value is in the mental process where you imagine and chain those lines of code to approach and solve that problem.

does the approach need new lines of code in your project? Good, have you estimated the hours needed and the cost of them? also good? Do it or not.

is it possible to integrate a third-party tool to solve? Good, is it too expensive and it's better to develop it in-house? also good? Do it or not.

I just want you to be able to view out of the box and try to avoid thinking in the lines of code you are going to type while the Product Owner is talking about the issue itself.

Need examples? Let's go.

Controlling the DOM

Your product team needs a way to manage (adding/removing) third-party scripts on the site to avoid adding issues to JIRA and going through the whole CI/CD process. Give them Google Tag Manager, train the people who are going to manage it, setup a solid permission scheme, and not also you gave them power and a solution, but you positioned yourself as a reliable problem solver that is able to look above the keyboard.

Growth teams use experimentation as a tool to validate hypothesis to a problem they need to solve, and most of the the experiments needs to be deployed within the apps/site. You would lose almost you whole productivity if every experiment had to go through the whole CI/CD process. You can show them Google Optimize or Optimizely to allow them to experiment without interrupting the development workflow.

Delivering

I can build you a CI/CD Pipeline using AWS Code Deploy and Pipeline, linked to a cluster of machines behind an ELB, with auto rotation for them, highly monitored in Cloudwatch, bla bla bla... I really can do that, but is it necessary to overkill every approach with that?

We already have teams of developers around the world that belong to product teams such as Vercel, which is very curated and mature. Give those colleagues some slack, investigate those kind of products before onboarding into an endeavour you do not know you would come back safe and sound.

Building

Do you have the resources to build a Magento or Prestashop from the ground? Think it twice please, perhaps you should try services such Shopify in the first attempt. I am not saying that M&P are bad solutions, I am saying that you need people behind those platforms to maintain and develop them properly.

Need a landing page for your product that is going to last one month? Try tools such as Webflow. Time and resources to build a very good HTML and CSS are not free,
your front-end expert would be the one reviewing the job done by other person with that tool instead of being the person building the landing page from zero.

Do you want to validate an idea using a mobile app? Right now there are several services to build them without coding, such as Glide. I know, I know, a native app is going to be perfect every time from here to Mars, but I am testing with that MVP if I need to hire, or not, a true expert.

Automations

Tired of build lambdas, api gateway endpoints, webhooks, listeners... to allow users enjoy your automations? Show them and let them play with automations in Zapier, Make and Twilio. Your job here is to apply a reliable security policy when using credentials/oauth to avoid misuse within the automations.

This has been a small batch of posible third parties that could lead to you reach your goal or validate ideas faster, without using nor interrupting your main work force.

Images attributions:
Business graph photo created by jannoon028 - www.freepik.com
Volume button vector created by upklyak - www.freepik.com
Covid delivery photo created by freepik - www.freepik.com
Joiner photo created by jcomp - www.freepik.com
Ai brain photo created by rawpixel.com - www.freepik.com

Code Smell | Magic Numbers

Jesús Mejías Leiva — Tue, 16 Aug 2022 12:30:00 +0000

Hello, today we are back with the code smells refactoring series and in this case we are going to talk about code smell called Magic Numbers, this code smell can be detect when we use a number that lacks the proper semantics.

Cause

Numbers lacking semantics make calculations harder to read.

Example

As we can see in the following example we have 2 magic numbers that are quite easy to detect since it is really complex to know what type of calculation we are performing simply by observing these values: 4.50 and 0.21

function calculateTotal(subtotal) {
  const total = subtotal + 4.50;
  return total + (total * 0.21);
}

Solution

By extracting both numbers to constants and giving them semantics we can see that the code is much more readable.

const SHIPPING_FEE = 4.50;
const SALES_TAX = 0.21;

function calculateTotal(subtotal) {
  const total = subtotal + SHIPPING_FEE;
  return total + (total * SALES_TAX);
}

Benefits

Improvement the readability and maintainability of the code.
You will make the next person who needs to go through that part of the code very happy 😋 jiji

Thanks for reading me 😊

Standardize imports with ESLint

Jesús Mejías Leiva — Fri, 08 Jul 2022 09:18:41 +0000

Adding this configuration will significantly improve the readability of our imports since they will follow a standard which we will define in said rule, let's see some small examples.

Requirements

In this article it will be assumed that ESLint is already configured in the project, if you do not have any configuration you must follow the official documentation that I attach here: ESLint configuring.

We will also need to install the following library with npm or yarn:

Npm:

npm install eslint-plugin-import --save-dev

Yarn:

yarn add -D eslint-plugin-import

Imports without rule 🤨

As can be seen, the ordering and grouping that is followed does not follow any criteria and what is even worse is that in other files they will follow different or even opposite criteria.

import React from 'react'
import AnotherComponent from './AnotherComponent'
import dayjs from 'dayjs';
import styles from './styles.module.scss'
import _ from 'lodash';

ESLint to rescue 🛟

Within our ESLint configuration file we will add the following rule, in this example I will use a configuration of my preference, if you need more information I will leave you here a link to the official documentation.

{
  "import/order": [
    "error",
    {
      "newlines-between": "always",
      "groups": [
        ["builtin"],
        ["external"],
        ["parent", "internal", "sibling", "index", "unknown"]
      ],
      "alphabetize": {
        "order": "asc",
        "caseInsensitive": true
      }
    }
  ]
}

It is important to note that to fix all the "errors" in existing imports that this rule will cause, it is recommended to use the --fix flag to automate the resolution of said "errors".

Imports with rule 🥰

We can see that everything is much more readable since with a simple glance we will be able to identify the imports of external and internal packages that are used in said file and the best thing is that in this way we unify criteria in all the imports of our application.

import dayjs from "dayjs";
import _ from "lodash";
import React from 'react'

import AnotherComponent from './AnotherComponent'
import styles from './styles.module.scss'

You can see more complex examples here.

Conclusions

As we have seen, adding this rule gives us a very good cost vs benefit since with a very basic configuration we obtain the great benefit of being able to have a standard in all the imports of our project, something that is really useful if you work with several people.

Thanks for reading me 😊

Being creative as a developer

Conti — Wed, 25 May 2022 14:37:53 +0000

Assumptions

Many times I have heard the word "creativity" associated to environments where the final output is:
a) A Design
b) An advertisement
c) A mockup
d) ... fill it with anything that comes to your mind regarding your experience with this word.

In spite of the examples I put above, "Creativity" has nothing to do with them, it is a human core attribute that anyone can train and improve. It is true that some environments are better than others to develop the skill itself, but believe me, it lives in you too.

What is is

Being creative is highly related with solving problems in unique and efficient ways, and how luck you are!, as a developer you are constantly solving problems, so let's see whether or not you are being creative:

Refactoring

Whenever you refactor a piece of code and the result is cleaner, more efficient and readability has been improved, that is creativity.

Practical with minimum overhead

When you decide that the same feature can run flawless using an endpoint to an external service, instead of developing an in-house new-edge-super-meta-algorithm, that has been already developed and optimised by other third party, that is creativity.

Make decisiones with libraries

They way you achieve solutions using native features instead of using 2,000 libraries from NPM to reduce your web app from 5MB to 500KB, that is creativity.

Open to learn

Being open to learn other languages and techniques allow you to expand you knowledge limits, and because of that knowledge, you will be able to choose from possible solutions and discard others faster. That is creativity.

Look for inspiration

Creativity is fed by your own experience and knowledge, but can also be triggered from other sources, such as other colleagues/professionals who share their experiences. Being able to filter and pick external content to boost your inspiration is also creativity.

Experimentation

Do not fear a failure, every time something goes wrong it is automatically added to your experiences luggage, which will feed your potential to be more creative.

Out of the box

Being able to take a step aside and view the problem out of the box is also creativity. Multiple times you have been hitting a wall when trying to solve a problem, you leave it as it is for a while, and when you come back and think of it again, suddenly some magic appears and you solve it.

Optimising your tools and environment

Investigate, try and optimise your dev tools, such as your IDE, your browser extension and tab organisation, or buying your swiss army knife of dev tools, that is is also creativity.

Remember to not look in other direction when people around you talk about "creativity", everyone has something to say about it.

Images attribution
Creativity and innovation photo created by freepik - www.freepik.com
Think different photo created by Waewkidja - www.freepik.com
Puzzle shape photo created by jcomp - www.freepik.com
Book photo created by ikaika - www.freepik.com

Code Smell | Data Clumps

Jesús Mejías Leiva — Tue, 24 May 2022 12:04:10 +0000

Hello, today we are back with the code smells refactoring series and in this case we are going to talk about code smell called Data Clumps, this code smell can be detected when we observe that certain groups of data are being used in different parts of our code.

Cause

Set of data elements, whether simple primitives, value types, or even complex types, are constantly passed together through different sections of your code base.

Example

We can see that the MarsRover class receives the value of the X and Y coordinates as a parameter, which at first is not necessarily a bad thing, right?

class MarsRover {
  constructor(private x: number, private y: number, private direction: string){
    //...
  }

  move() {
    //...
  }

  //...
}


// Use of the class
new MarsRover(100, 200, 'Example direction');

Solution

The use of X and Y as a separate set does not have to be harmful, but it can cause us different problems such as lack of cohesion, complexity when validating said data and, above all, duplication of associated logic in different parts of our code, let's see how we can fix this little smell:

class Coordinates {
  constructor(private x: number, private y: number) {
    //...
  }

  getX() {
    return this.x;
  }

  getY() {
    return this.y;
  }
}

class MarsRover {
  constructor(private coordinates: Coordinates, private direction: string){
    //...
  }

  move() {
    //...
  }
}

// Use of the class
new MarsRover(
  new Coordinates(100, 200), 
  'Example direction'
);

At first glance, in this simple example, it does not seem that we gain much from this change, but we are giving a data set its own entity, which provides semantics and long-term maintainability to our code.

Benefits

Improves readability: you can shrink a lot of parameter lists and simplify method calling, in addition to providing semantics.
Improves maintainability: we avoid falling into the code smell of shotgun surgery and in this way we facilitate the management of possible changes.

If we are asked for any change regarding new logic or coordinate validation, we will be very clear about where to add it, within our Coordinates class, in addition to being able to reuse it in different parts of our code that requires coordinate treatment.

Thanks for reading me 😊

Extracting a color palette from an image with javascript

Zygimantas Sniurevicius — Wed, 23 Mar 2022 14:56:06 +0000

Introduction

Today I am bring you something really interesting that I think is worth sharing. Let me begin by showcasing the end result.

If you can’t wait and want to test it yourself, here are the links to the app demo and the repository.

Demo app.
Repository (the entire codebase is commented).

Explanation

We can load any image and extract a color palette and every color is accompanied by its opposed color (complementary).

Example of a similar technique can be found in Spotify, when you navigate to a song/playlist or album you get a custom color gradient on top that represents the dominant color of the picture, this gradient adds a unique feel to each page and it's actually the reason why I am doing this post.

There are several websites that provide this service such as coolors.co or canva.com, if you ever wondered how does it work you are in the correct place, let's find out.

📝 Steps

Now that we know what we are dealing here, let’s start by explaining the process:

Load an image into a canvas.
Extract image information.
Build an array of RGB colors.
Apply Color quantization.

BONUS TRACK

Order colors by luminance.
Create a complementary version of each color.
Build the HTML to display the color palette.

🖼️ Load an image into a canvas

First we create the basic HTML of our page, we need a form input of type file to upload the image and a canvas element because that’s how we gain access to the image’s data.

index.html



<form action="#">
 <input type="file" id="imgfile" />
 <input type="button" id="btnLoad" value="Load" onclick="main();" />
</form>
<canvas id="canvas"></canvas>
<div id="palette"></div>
<div id="complementary"></div>

🚜 Extract image information

We load the image into the canvas using the event handler .onload, this allow us to access the getImageData() method from the canvas API.

index.js



const main = () => {
  const imgFile = document.getElementById("imgfile");
  const image = new Image();
  const file = imgFile.files[0];
  const fileReader = new FileReader();

  fileReader.onload = () => {
    image.onload = () => {
      const canvas = document.getElementById("canvas");
      canvas.width = image.width;
      canvas.height = image.height;
      const ctx = canvas.getContext("2d");
      ctx.drawImage(image, 0, 0);

      const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
    }
  }
}

The information returned from getImageData() represents all the pixels that compose the image, meaning that we have an humongous array of values in the following format:



{
  data: [133,38,51,255,133,38,255,120...],
  colorSpace: "srgb",
  height: 420,
  width: 320
}

Each value inside data represents a channel of a pixel R (red), G (Green), B (Blue) and A (Alpha), Every four elements of the data array form the RGBA color model.

🏗️ Build an array of RGB colors

Immediately after obtaining the image data we have to parse it to something more readable, this will make our live easier in the future.

We loop through the image data every four elements and return an array of color objects in RGB mode instead of RGBA.

index.js



const buildRgb = (imageData) => {
  const rgbValues = [];
  for (let i = 0; i < imageData.length; i += 4) {
    const rgb = {
      r: imageData[i],
      g: imageData[i + 1],
      b: imageData[i + 2],
    };
    rgbValues.push(rgb);
  }
  return rgbValues;
};

🎨 Color quantization

After building the rgb colors array we need to somehow know which colors are the most representative of the image, to obtain this we use color quantization.

Wikipedia describes color quantization as

A process that reduces the number of distinct colors used in an image, usually with the intention that the new image should be as visually similar as possible to the original image.

Median cut algorthm

To achieve color quantization we are gonna use an algorithm called median-cut, the process is the following:

Find the color channel ( red, green or blue) in the image with the biggest range.
Sort pixels by that channel.
Divide the list in half.
Repeat the process for each half until you have the desired number of colors.

It sounds easy but it is a little bit complex, so I am gonna try my best to explain the code below.

Let's begin by creating a function that finds the color channel with the biggest range.

Initialize the min rgb values to the maximum number and the max rgb values to the minimum, this way we can determine what is the lowest and highest accurately.

Then, loop through every pixel and compare it with our current values using Math.min and Math.max.

Subsequently, we check the difference between every channels min and max results and return the letter of the channel with the biggest range.

index.js



const findBiggestColorRange = (rgbValues) => {
  let rMin = Number.MAX_VALUE;
  let gMin = Number.MAX_VALUE;
  let bMin = Number.MAX_VALUE;

  let rMax = Number.MIN_VALUE;
  let gMax = Number.MIN_VALUE;
  let bMax = Number.MIN_VALUE;

  rgbValues.forEach((pixel) => {
    rMin = Math.min(rMin, pixel.r);
    gMin = Math.min(gMin, pixel.g);
    bMin = Math.min(bMin, pixel.b);

    rMax = Math.max(rMax, pixel.r);
    gMax = Math.max(gMax, pixel.g);
    bMax = Math.max(bMax, pixel.b);
  });

  const rRange = rMax - rMin;
  const gRange = gMax - gMin;
  const bRange = bMax - bMin;

  const biggestRange = Math.max(rRange, gRange, bRange);
  if (biggestRange === rRange) {
    return "r";
  } else if (biggestRange === gRange) {
    return "g";
  } else {
    return "b";
  }
};

Recursion time

Now that we have the component with the biggest range of colors in it (R, G or B), sort it and then split it by half, using the two halves we repeat the same process and call the function again, each time adding a value to depth.

index.js



const quantization = (rgbValues, depth) => {
  // base code goes here

const componentToSortBy = findBiggestColorRange(rgbValues);
  rgbValues.sort((p1, p2) => {
    return p1[componentToSortBy] - p2[componentToSortBy];
  });

  const mid = rgbValues.length / 2;
  return [
    ...quantization(rgbValues.slice(0, mid), depth + 1),
    ...quantization(rgbValues.slice(mid + 1), depth + 1),
  ];
}

As for the base case, we enter it when our depth is equal to the MAX_DEPTH, in our case 4, then add up all the values and divide by half to get the average.

Note: Depth in this case means how many colors we want by power of 2.

index.js



const quantization = (rgbValues, depth) => {

 const MAX_DEPTH = 4;
  if (depth === MAX_DEPTH || rgbValues.length === 0) {
    const color = rgbValues.reduce(
      (prev, curr) => {
        prev.r += curr.r;
        prev.g += curr.g;
        prev.b += curr.b;

        return prev;
      },
      {
        r: 0,
        g: 0,
        b: 0,
      }
    );

    color.r = Math.round(color.r / rgbValues.length);
    color.g = Math.round(color.g / rgbValues.length);
    color.b = Math.round(color.b / rgbValues.length);
    return [color];
  }
  // recursion code goes below
}

This is it, we are done with median-cut and the palette extraction.

📑 Extra steps

There are a lot of things that we could do here but i don't want to abuse of your precious time, if you are interested in expanding a little bit the scope of the project, check the repository, it contains all the extra code.

Order colors by luminance. There are different ways of doing this, depending of your needs, here we use the relative luminance.
Create complementary version of each color.
Build the HTML to display the color palette.

🗃️ Resources

If you want to go further into the topic I suggest trying different algorithms to create the color palette, find the dominant dolor, understand how color spaces work or add different color schemes, here are some examples to help you out:

Use K-means algorithm to create the color palette.
Use Octree algorithm to implement the color palette.
Watch this talk about color "RGB to XYZ: The Science and History of Color" by John Austin.
Add different color combinations like Monochromatic or Triadic, check this page for more examples.

👋 Final remarks

Thank you for your time, I hope you enjoyed this article and have learned something along the way, have a nice day :)