DEV Community: Luciano Graziani

CSS MediaQuery for making a board game responsive

Luciano Graziani — Wed, 29 Jul 2020 23:41:32 +0000

Cover from https://cdn0.tnwcdn.com/wp-content/blogs.dir/1/files/2015/04/colortheory.jpg

Today I was working in a little board game I started with a friend and tried to solve something I was avoiding for some time now: how to make the board responsive.

I used CSS Grid for making a 9x9 board with as much space as possible, given the height/width of the window. I also tried using the vw unit, but when the window's height was less than the width, the page size would overflow vertically. The same did happened with vh but with a horizontal overflow.

Solution

So, how is it possible to adapt a fixed css grid with 9x9 (or whatever) squares? With Media Queries! (or at least is what I found.) Using the orientation condition we can change the unit we're using. This specific snippet is what I used for the board:

.board {
  display: grid;
  grid-template-columns: repeat(9, 10vh);
  grid-template-rows: repeat(9, 10vh);
  gap: 0.2em;
}

@media screen and (orientation: portrait) {
  .board {
    /* no more overflow with this! yay! */
    grid-template-columns: repeat(9, 10vw);
    grid-template-rows: repeat(9, 10vw);
  }
}

Demo

If you know something better than this approach, feel free to respond! Thank you 😄!

How to make TS more intelligent?

Luciano Graziani — Mon, 09 Dec 2019 14:40:21 +0000

I have a monorepo like this:

root/packages
  |-lib1
  |-lib2
  |-lib3

lib3 depends of both lib1 and lib2. I'm using TS v3.7.2 with composite (true), baseUrl, paths and references props to be able to work with the new ts project references.

Everything is ok except for one thing: I'm using VSCode, I'm writing something for lib3 and using an enum from lib1, but the enum is still not imported. When I ask VSCode to show me the possible imports for the enum, it doesn't show anything, but if I write the import by hand, it recognize it.

E.g:

file in lib3 where VSCode doesn't know where to import from

export function bla(key: EnumFromLib1) {
  // do something
}

file in lib3 where VSCode know

import {} from 'lib1/some/path/to/file';

export function bla(key: EnumFromLib1) {
  // do something
}

In the second example, if I press the keyboard shorcut for importing EnumFromLib1 it will list the possibility from the lib1/some/path/to/file file.

So, the question is: How can I configure TS to help him know beforehand that I have more elements in those files?

Thank you!

Using Jest with coverage and BenchmarkJS helped me identify optimization opportunities for my recursive lib

Luciano Graziani — Sat, 26 Oct 2019 17:14:55 +0000

Cover image from picwalls.

The problem I tried to solve

By default, GraphQL adds a __typeName attribute to every element for each query. This attribute helps you determine what type represents each object.

GraphQL services provide a few meta fields, the rest of which are used to expose the Introspection system.

Source: https://graphql.org/learn/queries/#meta-fields

But when you have to invoke a mutation, you cannot pass everything. GraphQL will complain if you have unknown attributes for a given input or type. Hence, you need to remove, at least, the __typeName attribute.

In addition, we can have multiple structures: a simple object, an array of simple objects, an object with nested object, an array of objects with nest... Ok, yes, a lot of possibilities.

So, how could you remove each of those attributes without knowing that much about the structure of the data?

The first solution

Github repo: https://github.com/lgraziani2712/deep-delete

The key point to solve the problem is recursivity. Since you don't know how many objects and array you have, the function must access and process those structures and then return each time the data is not an array nor an object (the base case).

A recursive function definition has one or more base cases, meaning input(s) for which the function produces a result trivially (without recurring), and one or more recursive cases, meaning input(s) for which the program recurs (calls itself).

Source: https://en.wikipedia.org/wiki/Recursion_(computer_science)#Recursive_functions_and_algorithms

First commit solution:

function deepDelete(keyToSearch, data) {
  if (Array.isArray(data)) {
    // Recursive case
    return data.map(element => deepDelete(keyToSearch, element));
  }
  if (!data || typeof data !== 'object') {
    // Base case (anything different than array or data)
    return data;
  }

  return Object.keys(data).reduce((partial, key) => {
    if (key === keyToSearch) {
      // Base case (the key to be deleted)
      return partial;
    }
    // Recursive case
    partial[key] = deepDelete(keyToSearch, data[key]);

    return partial;
  }, {});
}

Limitations of this solution

What would happen if I want to remove more than one key? I need to process my data multiple time just for that? (It's insane, yeah).

This is solved in v1.1.0. You can pass an array of strings as a first param.
Is it really works as expected?
- I'm not 100% sure. It doesn't have tests.
Are since v2.1.0.
How many times (hence, resource consumtion) is the function called?
- I don't know. I don't have metrics nor code coverage.
Are since v2.1.0.
What really are the types that must accept the data parameter? Can be anything, or just one or two?

Since v2.1.0 it only accepts Object | Array<Object>
Can take advantage of things like V8 TurboFan optimizing compiler?
- I don't really know.

Latests benchmark results

Before I talk about how I found optimization opportunities, I want to show you the latests benchmark results:

As you can see (or hear), the version v2.1.0 is the fastest.

Test Coverage really helped me find optimization opportunities

When I was writting tests, I configured Jest to generate the test coverage, to help me know if I was testing everything. What I didn't know was that the coverage it also tells you how many times a line is executed, as you can see in the following image:

Let's analyse the result:

Line 10 was executed 10/24 times. The data parameter had an array 10 times.
Line 13 was executed 8/24 times. The data parameter had an empty value or something different than an object.
Line 17 was executed 6/24 times, so there were 6 objects.
Line 19 was executed 4/8 times, which means that there were deleted four keys.
Line 21 was executed 4/8 times. This means that the object had other 4 keys that were needed to be processed by calling deepDelete again just to returns itself.

Viewing this made me think that there were a lot of function calls, more than the necessary. At that point, deepDelete was being called for every type of value. Every. Type. Of. Value. There are two lines in where was possible to improve this. Those lines are 10 and 21. Instead of just invoking the function, it could check if the element is an array or an object, and if not, not calling it.

This improvement was made for version 2.0.1:

With this changes and a few minor fixes & improvements, I was able to reach v2.1.0 and get the results of the benchmark mentioned before.

Conclusion

Code coverages not also let you know which paths of your application you're testing but it also can help determine optimization points. Using it in conjunction with BenchmarkJS you'll be able to have more metrics about your code!

Stop copying your process.env.NODE_ENV to local variables! 🤯

Luciano Graziani — Fri, 12 Apr 2019 15:45:05 +0000

Cover image from
https://www.nationalgeographic.com/photography/proof/2017/06/bird-gallery/

TL;DR

Instead of this:

Example nº 1:

const localAndLessCode = process.env.NODE_ENV;

if (localAndLessCode !== 'production') {
  // do dev-only things

  console.warn('[dev-only] Warnings to help devs!');
}

export function anotherFunc(num) {
  if (localAndLessCode !== 'production' && typeof num !== 'number') {
    console.warn('[dev-only] Warnings to help devs!');
  }

  // Do something
}

Do the following:

Example nº 2:

if (process.env.NODE_ENV !== 'production') {
  // do dev-only things

  console.warn('[dev-only] Warnings to help devs!');
}

export function anotherFunc(num) {
  if (process.env.NODE_ENV !== 'production' && typeof num !== 'number') {
    console.warn('[dev-only] Warnings to help devs!');
  }

  // Do something
}

Why?

Tools like babel will replace every process.env.NODE_ENV (and any other proces.env variable) with its value. Then, the examples above would be transformed like this:

Example nº 1 transformed:

const localAndLessCode = 'production';

if (localAndLessCode !== 'production') {
  // do dev-only things

  console.warn('[dev-only] Warnings to help devs!');
}

export function anotherFunc(num) {
  if (localAndLessCode !== 'production' && typeof num !== 'number') {
    console.warn('[dev-only] Warnings to help devs!');
  }

  // Do something
}

Example nº 2 transformed:

if ('production' !== 'production') {
  // do dev-only things

  console.warn('[dev-only] Warnings to help devs!');
}

export function anotherFunc(num) {
  if ('production' !== 'production' && typeof num !== 'number') {
    console.warn('[dev-only] Warnings to help devs!');
  }

  // Do something
}

As you can see, in the second example, both comparisons are static. This is something that uglifiers like the webpack's TerserPlugin or babel-minify will take as advantage to literally remove those ifs (and their content!).

It's free!

This is really cool because you don't have to configure anything to reduce your bundle size, it's something you can fix in your code! And it will help you reduce a lot of code you don't want to have in production builds!

Add file extensions to your dynamic imports to reduce size

Luciano Graziani — Fri, 12 Apr 2019 00:43:06 +0000

UPDATE: Here's a codesandbox with this situation: https://codesandbox.io/s/webpack-dynamic-import-duplication-array-gv0gq

TL;DR

Instead of writing dynamic imports like this

import(`./my-path/${fileName}`)

Write them like this

import(`./my-path/${fileName}.ext`);

It will reduce the bundle size!

Long explanation

Yesterday I was reading the generated code by webpack and found something interesting:

var map = {
  "./en/_extras": [
    3,
    0
  ],
  "./en/_extras.js": [
    3,
    0
  ],
  "./en/color": [
    8,
    5
  ],
  "./en/color.js": [
    8,
    5
  ],
  // The rest of the files
};

That map object represent every possible chunk for an specific dynamic import, and it was twice the size I expected.

Then it hit me: I didn't wrote the file extension in my dynamic imports. When I did it, each of those objects reduced its sizes to match the numbers of files!

It's not like it will massively reduce your bundle size, but it's something you could get for free!

I wrote my first babel plugin! (And it wasn't that hard!)

Luciano Graziani — Tue, 05 Mar 2019 22:35:58 +0000

Cover image from https://www.grimms.eu/en/products/building-amp-rainbow-worlds/organic-shapes/1240/colored-waldorf-blocks

Today I wrote a tiny babel plugin for reducing the size of a vue proyect by transforming the props attribute in their minimal expression (and at the same time, removing vue-types as a dependency).

Steps I did to learn how to write a babel plugin

To understand (at least something, lol) how babel's plugin system works, I did the following:

Set up vscode to be able to debug the plugin.
Read the plugin section of the babel-handbook: https://github.com/jamiebuilds/babel-handbook. I didn't read it all, though. And the first time didn't understood anything.
Read other plugins' code.
Install @types/babel__core. The autocomplete (even in JS) in vscode is lit. Really helpful!
Debug a lot. In conjunction with the handbook, it made me understand a little how to understand how the code is interpreted and how to modify it.
Add jsdoc everytime you can. You help vscode to help you ;)

The following snipet is the vscode launch's configuration for debugging a babel plugin:

{
  "type": "node",
  "request": "launch",
  "name": "Debug babel",
  "console": "integratedTerminal",
  "autoAttachChildProcesses": true,
  "program": "${workspaceFolder}/node_modules/@babel/cli/bin/babel.js",
  "args": [
    "--config-file=${workspaceFolder}/babel.config.js",
    "${workspaceFolder}/path/to/file.js"
  ]
}

The string "${workspaceFolder}/path/to/file.js" is the file to be compiled.

Babel plugin basic structure

const { declare } = require('@babel/helper-plugin-utils');
const { types: t } = require('@babel/core');

module.exports = declare(api => {
  // If the plugin requires babel 7++
  api.assertVersion(7);

  return {
    // For what I learned, although the name is not required,
    // if you add one, remember to NOT add the "babel-plugin"
    // prefix. E.g., if the package's name is
    // "babel-plugin-transform-vue-props", the name would be
    // the following:
    name: 'transform-vue-props',
    visitor: {
      /**
       * @param {babel.types.ImportDeclaration} path Import's node
       * @return {void}
       */
      ImportDeclaration(path) {
        if (path.node.source.value === 'vue-types') {
          path.remove();
        }
      },
    },
  };
});

The visitors prop its where everything happens.

When we talk about "going" to a node, we actually mean we are visiting them.

Handbook: Visitors

Each node has a type, and everyone of them can be visited. In the example above we are visiting each import declaration and remove them if they are importing the vue-types library.

How to transform code

By the way, if you want to transform, e.g. an object, into an array of strings (the keys), you would have to do the following:

Consider this code:

const obj = {
  name: 'Luciano',
  age: 28,
};

If you want to transform it to this:

const obj = ['name', 'age'];

You would have to do the following:

const { declare } = require('@babel/helper-plugin-utils');
const { types: t } = require('@babel/core');

module.exports = declare(() => {
  return {
    name: 'transform-obj-to-array',
    visitor: {
      /**
       * @param {babel.types.VariableDeclarator} path Declaration
       * @return {void}
       */
      VariableDeclarator(path) {
        const node = path.node;

        if (!t.isObjectExpression(node.init)) {
          return;
        }
        node.init = t.arrayExpression(
          node.init.properties.map(prop => t.stringLiteral(prop.key.name)),
        );
      },
    },
  };
});

By the way, I had to debug it until I could find the correct visitor (wasn't VariableDeclaration nor AssignmentExpression). JSDoc + @types/babel__core + VSCode FTW.

As you can see, isn't as simple as to replace it like a string. The types (aka t) prop from @babel/core it's very helpful for validating what structure is something and for building new ones.

babel-plugin-transform-vue-props

The lib can be found here https://github.com/lgraziani2712/babel-plugin-transform-vue-props
It really helps to remove vue-types as dependency (since it does nothing in production), which can be weight between 25kb~ to 3.5kb~ gzipped and if webpack (or any bundler) is configured to use the production file (https://github.com/dwightjack/vue-types#production-build). This size doesn't counts the use of vue-types in every component.

Motivation

I reaaaally love to resolve optimization problems, and I wanted to remove vue-types from the production bundle. I searched everywhere but didn't find anything confortable to use. I also rediscovered this doc https://vuejs.org/v2/guide/components-props.html#Prop-Types and remember what is the most simple definition of the props attribute of a component.

EDIT: I just found https://astexplorer.net/. Is really dope!

I hope this post will motivate anyone who wants to explore the world of babel plugins but don't know where or how to start! Cheers!

The value of unit or integration testing

Luciano Graziani — Mon, 17 Dec 2018 17:08:01 +0000

Comic by CommitStrip: http://www.commitstrip.com/en/2017/02/08/where-are-the-tests/

TL;DR: Try to write unit/integration tests, at least, for you core processes. Your future self will thank you.

A few days ago I had to refactor two processes in a stock system: sales and purchases. Both have, at least, one step in common: they query a list of products filtering by a list of IDs. Both use the same data except that sales uses the sale_price (aliased as unit_price) and purchases uses the unit_price. Both manage a "unit price", one as the unit price for sale, and another for purhcase.

The sales process was written by me and the purchases process was written by a teammate, so, even when they have that step in common, both processes did in different ways. It's OK and normal. We didn't knew what they'll have in common until we wrote the code.

Those processes are extremely important and sensitive because they are the core of the system AND manage money. Because of that, we decided to add unit and integration tests for each constraint they have.

Because of that decision, even when my teammate, who isn't used to write tests, didn't wanted to "waste" time written them, today I could refactor both processes and prevented a dangerous bug to emerge:

While refactoring that common step in one method, I decided to query every attribute required by the sales and purchases processes, which means that now both will have accessible the sale_price and unit_price props. But I didn't remembered that inside the sales process, the total attribute was being calculated using the old sale_price alias: unit_price. With the change, everything still worked fine, but the total, instead of multipliying the sale_price for the amount of products, was using the real unit_price.

Only because the snapshot tests warned me about a diff, I could catch the error. Only because we decided to add tests to our processes, instead of letting the user catch us for us, with everything that means.

I hope this experience will motivate you to write tests!

Thank you for reading!

I want to store my benchmarks.js results

Luciano Graziani — Sun, 11 Nov 2018 20:19:05 +0000

Cover image by Teresa Alba

This past week I've been searching for a library that generates a JSON for benchmark.js' results. Since I didn't find anything, I've written one myself.

By default, it stores everything in a file. But it has a callback function so you can do whatever you want, like storing it in a database.

It also uses systeminformation to store static data about the machine is running the benchmarks.

I think this lib is cool since it makes it possible to run your benchmarks in the CI pipeline and store the results in a database for future analysis.

So, how can I start using it today?

First, you need to install the dependencies:

yarn add benchmark benchmark-json-reporter

npm install --save benchmark benchmark-json-reporter

Last, you have to create a file that will run your benchmarks:

const Benchmark = require('benchmark');
const jsonReporter = require('benchmark-json-reporter');

const suite = new Benchmark.Suite('my-bench-suite');

// Just this
jsonReporter(suite);

suite
  .add('bench-name-1', () => {
    // Faster heavy process
  })
  // ...
  .add('bench-name-n', () => {
    // Slower heavy process
  })
  // run async
  .run({ async: true });

This basic example will store the results in the following file: <rootFolder>/benchmarks/my-bench-suite-({md5-hash}.log). The md5-hash is used to identify a machine univocally.

By the way, you can also store your benchmarks in a database like this:

const Benchmark = require('benchmark');
const jsonReporter = require('benchmark-json-reporter');

const suite = new Benchmark.Suite('my-bench-suite');

// Just this
jsonReporter(suite, {
  callback(result, hashId, name, folder) {
    // 1. Connect to a database
    const connection = new SomeEndPoint();
    // 2. Store the sysinfo with the hashId as a main ID
    connection
      .getById(hashId)
      .update({ sysinfo: result.sysinfo })
      .then(() => 
        // 3. Store the benchmarks
        Promise.all(
          benchs.map(bench =>
            // For each benchmark, push the result into the collection
            connection
              .getById(hashId)
              .getProp('benchmarks')
              .getCollection(bench.timestamp).push(bench),
          )
        )
      ).then(() => {
        // 4. Close the database connection
        connection.close();
      });
    // 5. Profit.
  },
});

suite
  .add('bench-name-1', () => {
    // Faster heavy process
  })
  // ...
  .add('bench-name-n', () => {
    // Slower heavy process
  })
  // run async
  .run({ async: true });

Thank you for reading! And if you have any question, don't hesitate to ask!

How a conference can be so rewarding

Luciano Graziani — Sat, 27 Oct 2018 18:36:33 +0000

TL;DR. If you have to travel to go to conferences, try it! At least one time. Save money, if you can, and try it! I think you won't be disappointed. And it's OK to go alone (maybe better: it's easier to talk to strangers.)

Last weekend I went to my first big conferece: NodeConfArg at Buenos Aires. I'm from a city from the north Patagonia where are no meetups and no one is organizing anything, which makes it difficult to find people with the same technical profile.

I went alone. My actual work allowed me to take those days off, but it didn't help me economically in any way. This made imposible to some of my teammates to go, since they have more responsabilities than me, like their house or family. This experience costed me half of my monthly salary.

Please, please, if you have a job like this, update your CV and send it to other places, even if you don't think your expertise/experience is sufficient. I'm doing this right now because I don't want to spend my time in a place that doesn't care about the improvement of their human resources.

Ok, enough ranting. At the NodeConfArg, I could talk to people from other countries like Bolivia, Perú or USA. I could also meet and exchange some words with some speakers (by the way, everyone was super cool). I could also meet an online friend of mine and their teammates from the other extreme of my country. I felt multiple emotions at the same time.

The first day had workshops. I register to two: the first one was about the dat project, a p2p protocol for the web. It was really really amazing. Both teachers had good charisma and passion about what they were teaching. By the way, here's the repo: https://github.com/geut/dat-workshop

The second and third day had talks only (and an amazing panel). Every talk was fabulous. In total where 20 incredible talks which blown my mind. Mostly everything was new to me. Since I'm not working at scale, and since most of the talks were about optimization, I could learn a lot. By the way, it's OK to not know about the topics (and maybe even better).

There were talks about iot, communication through sounds (using https://chirp.io/), the use of monorepos, ia and art, inclussion, standards, optimization (a looot), native extensions, tracing and metrics, serverless, p2p and about the state of node+js as a community. A lot of topics.

I'm conscient that I'll implement near nothing about everything I learned right now. But! I can say that now I have curiosity about those topics (so I will start reading about them).

Thank you for reading this!

See you next time!

How scoop made my dev experience in Windows so great

Luciano Graziani — Wed, 17 Oct 2018 18:07:15 +0000

Since I started programming, I used Windows for the most part. I always had problems while configuring everything I needed every time I formatted the PC or changed it. At the beggining I tried to use xamp or wamp, but I was uncomfortable with those tools, things were difficult to update, change and share configuration between teammates.

The windows' cmd is extremely uncomfortable for me too. Since I learned to use the CLI with Linux (vi 4ever, lol). I felt in love at first sight when I started using Cmder.

I've been working with a 4-person team mainly using nodejs or php7.2 in the backend and vue in the frontend. Early this year, when we started a new project, I truly wanted to share how I configured my dev environment with them since everyone uses Windows.

I started searching some package manager but for Windows. I found chocolatey first, and I tried it but I didn't like it (I don't remember why). So I continued searching until I found scoop.

Scoop

Scoop is a command-line installer for Windows.

Github repository: https://github.com/lukesampson/scoop

This tool made my dev environment configuration a breeze. I could even create a git repository and store every configuration for every tool. This allowed me and my teammates to install, keep updated and configure everything from php (with x-debug), apache, nodejs, yarn, mariadb, composer, cmder, and other general tools like gimp, screentogif (another excellent oss tool) or filezilla in less than an hour.

Today I had to install everything from scratch in another laptop and I only had to install scoop, clone the configuration repo and start installing everything else.

So how I can start using scoop with a git repo?

First of all, you have to install scoop (extracted from the official page):

Requirements

Windows 7 SP1+ / Windows Server 2008+
PowerShell 3 (or later) and .NET Framework 4.5+
PowerShell must be enabled for your user account e.g.

set-executionpolicy remotesigned -s currentuser

Installation

Run this command from your PowerShell to install scoop to it's default location (C:\Users<user>\scoop):

iex (new-object net.webclient).downloadstring('https://get.scoop.sh')

Create your configuration repository

Considering you installed scoop at the default location (C:\Users<user>\scoop), you have to access the C:\Users\<user>\scoop\persist folder. Every scoop app will store their configuration in this folder which isn't affected by uninstalls. Then you could run git init and start persisting you configuration.

By the way, before you start committing and pushing everything, take into account that there are some special files that we don't want to push. To prevent files like those binaries from mariadb, or nodejs caches, we have to create a .gitignore file at the root of the repository, in other words, inside the persist folder. It's OK to add custom files to it.

My .gitignore has the following values:

vendor
cache
data
plugins
composer
nodejs
yarn
log.*
user-ConEmu.xml
.history
*.dmp

I also written a README.md file with everything everyone needs to know to configure each app by hand, like mariadb, or adding apache and mariadb as a windows services.

Things like configuring php with xdebug, which for me was always cumbersome, for the first time was as easy as install it. By default, when you install php-xdebug, scoop creates a xdebug.ini file inside C:\Users\<user>\scoop\persist\php\conf.d\ folder with the following content:

zend_extension=C:\Users\<user>\scoop\apps\php-xdebug\current\php_xdebug

But the thing is, if I want to have a generic configuration which can be used by everyone, I cannot have absolute paths. The following configuration is what I have:

zend_extension=../../../../apps/php-xdebug/current/php_xdebug

[XDebug]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1

The new [XDebug] configuration allows IDE's like VSCode to debug php code.

Share the configuration between teammates

Once you started pushing your configuration into your repository, you can now share it. Since the persist folder will contain data right after the installation, git will complain if you try to clone something inside. To resolve this problem, you have to do the following:

git init 

git remote add origin PATH/TO/REPO 

git fetch 

git checkout -t origin/master -f

Source: https://stackoverflow.com/a/43287779/2862917

I hope this help to simplify the configuration process to anyone using Windows! Feel free to ask me anything!