DEV Community: Thiago Moraes

Como publicar seu primeiro package Typescript e automatizar com Github Actions

Thiago Moraes — Tue, 15 Jun 2021 01:30:25 +0000

Introdução

Nesse artigo vou abordar a criação e publicação de um package escrito em Typescript para o NPM. A minha principal motivação é escrever algo que seja simples mas não deixe de levar em consideração fatores importantes, como versionamento, atualização, testes e automatização. O que será abordado:

Criar um package em TS
Boas práticas de teste pre release
Publicar um package público no npm
Gerenciar atualizações
Noções de versionamento
Automatizar a publicação com github actions

Pré-requisitos

Criar uma conta no Github
Criar uma conta no NPM

Configurando o ambiente para o package

Criando o repositório

Nosso package vai se chamar math-ops e será responsável por fazer operações matemáticas básicas. Sendo assim, vamos criar um novo repositório com o nome escolhido:

Inicializando o repositório

Vamos criar um novo diretório e acessá-lo:

mkdir math-ops && cd math-ops

Em seguida vamos configurar o repostório git e enviar o primeiro commit.

echo "# math-ops" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:thiagomr/math-ops.git
git push -u origin main

Configurando o package

Inicializando as configurações do NPM

npm init

Como resultado deste comando teremos a seguinte saída:

//package.json

{
  "name": "@thiagomr/math-ops",
  "version": "0.1.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/thiagomr/math-ops.git"
  },
  "author": "Thiago Moraes",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/thiagomr/math-ops/issues"
  },
  "homepage": "https://github.com/thiagomr/math-ops#readme"
}

Nessa etapa é importante notar que definimos o nome do package (você deve mudar de acordo com o seu nome de usuário ou nome do package que você desejar), que será utilizado para instalar o mesmo. Também foi definida a versão 0.1.0, seguindo os padrões de Semantic Version. Este é um padrão que nos permite incrementar a versão de acordo com o tipo da atualização. Você pode se aprofundar sobre o assunto aqui. Vamos considerar que estamos criando uma release não oficial, ou seja, anterior à versão 1.0.0. É interessante também perceber que como ja temos o git configurado nesse diretório, o npm automaticamente sugere o preenchimento das configurações de url e homepage do mesmo.

Instalando as dependências

Em seguida vamos instalar as dependências que utilizaremos no projeto, que são basicamente o Typescript e o Jest (ferramenta que utilizaremos para escrever testes para nossas funcionalidades):

npm install typescript jest @types/jest ts-jest --save -D

Vamos adicionar o arquivo tsconfig.json com as configurações que usaremos para compilar o projeto:

//tsconfig.json

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "sourceMap": true,
    "outDir": "./lib",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "declaration": true
  },
  "include": [
    "src"
  ],
  "exclude": [
    "**/*.spec.ts"
  ]
}

Em seguida, iremos adicionar alguns scripts para fazer o build do projeto e uma configuração bem simples para o Jest. Nosso arquivo com as alterações ficará da seguinte forma:

//package.json

{
  "name": "@thiagomr/math-ops",
  "version": "0.1.0",
  "description": "A package to make basic math operations",
  "main": "lib/index.js",
  "types": "lib/index.d.ts",
  "scripts": {
    "clean": "rimraf lib",
    "build": "npm run clean && tsc",
    "test": "jest",
    "prepublish": "npm run test && npm run build"
  },
  "author": "Thiago Moraes",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/thiagomr/math-ops.git"
  },
  "bugs": {
    "url": "https://github.com/thiagomr/math-ops/issues"
  },
  "homepage": "https://github.com/thiagomr/math-ops#readme",
  "jest": {
    "preset": "ts-jest",
    "testEnvironment": "node",
    "coveragePathIgnorePatterns": [
      "/node_modules/",
      "lib"
    ]
  },
  "files": [
    "lib/**/*"
  ],
  "devDependencies": {
    "@types/jest": "^26.0.23",
    "jest": "^27.0.4",
    "ts-jest": "^27.0.3",
    "typescript": "^4.3.2"
  }
}

Algumas explicações mais detalhadas:

"main": "lib/index.js", Será o arquivo que vai expor a API pública do nosso pacote.
"types": "lib/index.d.ts", Indica a declaração de tipos do TS, gerado automáticamente de acordo com as nossas configurações de compilação feitas anteriormente.
"jest": {...} Configuração para que o Jest funcione usando TS e indicação de arquivos a serem ignorados.
"files": {...} Arquivos que desejamos incluir no nosso pacote.
"prepublish" Executa um script antes de publicar o package. Neste caso vamos rodar os testes unitários.
"build" Faz a compilação do projeto. De maneira bem resumida, seria o processo de typechecking e transpilação do código TS para JS.

Para finalizar essa etapa, vamos criar um arquivo .gitignore:

//.gitignore

node_modules
lib

E então vamos enviar toda a configuração para o repositório:

git add .
git commit -m "add dependecies"
git push

Criando a primeira funcionalidade

Agora vamos adicionar o arquivo com a primeira funcionalidade, que irá retornar a soma entre dois números:

// src/sum.ts

const sum = (firstNumber: number, secondNumber: number): number => {
    return firstNumber + secondNumber;
}

export {
    sum
}

Vamos criar também um arquivo de entrada para exportar a API pública do nosso package:

// src/index.ts

export * from './sum';

Testando o package

Vamos escrever nosso primeiro teste untário para a funcionalidade de sum:

// src/sum.spec.ts

import { sum } from './sum';

test('should return a sum of two numbers', () => {
    const result = sum(3, 2);
    expect(result).toEqual(5);
});

Rodando os testes:

npm test

Agora que já temos nosso primeiro teste unitário, vamos testar o uso real do package. Nós vamos utilizar o comando npm link. Isso fará com que o npm crie uma referência local para esse projeto, podendo ser utilizado de forma direta em outros projetos. É uma forma de testar seu package no ambiente de desenvolvimento sem precisar publicá-lo várias vezes.

O primeiro comando será executado no diretório do package e o segundo em um novo diretório para testes:

# math-ops
npm link

# testdir
npm link @thiagomr/math-ops

No diretório de testes, vamos criar um arquivo que importa e utiliza a funcionalidade sum:

// testdir/index.ts

const { sum } = require('@thiagomr/math-ops');
const result = sum(2, 3);

// sum is 5
console.log(`sum is ${result}`);

Para finalizar, vamos atualizar nosso repositório com as novas mudanças:

git add .
git commit -m "add sum feature"
git push

Publicando no NPM registry

Agora que já temos nosso pacote funcional e testado localmente, vamos para a fase de publicação. Vamos adicionar um arquivo .npmignore que vai excluir os arquivos desnecessários, enviando apenas o essencial e diminuindo o tamanho do package:

//.npmignore

src
node_modules

Iremos fazer o login no npm com a conta desejada:

npm login

Por padrão o versionamento do NPM utiliza o sistema de tags do GIT para indicar a publicação de novas versões. É importante manter o versionamento do NPM e GIT sincronizados, mas vale ressaltar que não há nenhuma regra que faça uma ligação entre as duas coisas. Existem alguns packages que facilitam o gerenciamento de ambos, mas como a intenção aqui é mostrar a funcionalidade básica e o mais pura possível, não utilizaremos nenhuma ferramenta adicional.

Vamos atualizar o repositório com a tag de versão incial e em seguida publicar no npm:

git tag v0.1.0
git push --tags
npm publish --access=public

Agora já temos nosso pacote publicado e disponível para instalação (O meu está em uma versão um pouco a frente pois fiz alguns testes para o artigo):

Adicionando novas funcionalidades

Nessa etapa vamos adicionar uma nova feature. Isso vai reforçar os conceitos aplicados, trazendo familiaridade com o processo. Vamos adicionar uma funcionalidade que retorna o resultado da multiplicação entre dois números index.ts:

// src/times.ts

const times = (firstNumber: number, secondNumber: number): number => {
    return firstNumber * secondNumber;
}

export {
    times
}

//src/index.ts

export * from './sum'
export * from './times'

Seguindo o processo anterior, vamos escrever um teste unitário para a nova funcionalidade:

//src/times.spec.ts

import { times } from './times';

test('should return the multiplication of two numbers', () => {
    const result = times(3, 3);
    expect(result).toEqual(9);
});

Vamos atualizar o repositório e publicar a nova versão:

git add .
git commit -m "add times feature"
npm version minor
git push --tags
npm publish --access=public

Agora você poderá o ver o package atualizado no NPM registry.

Automatizando a publicação com Github Actions

Agora que já vimos como fazer todo o processo manualmente, vamos automatizar a publicação utilizando Github Actions.
Vamos criar um token no NPM aqui, para que seja possível fazer a publicação através do Github. Vamos inserir nosso token como uma variável de ambiente com o nome NPM_TOKEN, acessando o repostório e em seguida selecionado as opçoes Settings > Secrets > New Repository Secret.:

Em seguida vamos criar o arquivo de configuração do pipeline para que seja executado sempre que ouver uma alteração na branch main e no arquivo package.json:

# .github/workflows/publish.yml
on:
  push:
    branches: [ main ]
    paths:
      - 'package.json'

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 14
      - run: npm install
      - uses: JS-DevTools/npm-publish@v1
        with:
          token: ${{ secrets.NPM_TOKEN }}

Para testar o pipeline, nós criaremos a última funcionalidade ao nosso package, capaz de subtrair dois números:

const subtract = (firstNumber: number, secondNumber: number): number => {
    return firstNumber - secondNumber;
}

export {
    subtract
}

Vamos novamente atualizar a entrada do package:

//src/index.ts

export * from './sum'
export * from './times'
export * from './subtract'

Assim como nos passos anteriores, vamos criar um teste unitário para o mesmo:

// src/subtract.spec.ts

import { subtract } from './subtract';

test('should return the subtraction of two numbers', () => {
    const result = subtract(4, 4);
    expect(result).toEqual(0);
});

Agora vamos enviar nossas alterações para o repositório e atualizar a versão do nosso package:

git add .
git commit -m "add subtract feature"
npm version minor
git push --tags

Se a nossa configuração estiver correta e tudo ocorrer bem, podemos verificar o pipeline no Github executado com sucesso e a nova versão publicada no NPM:

Agora vamos adicionar um exemplo de uso do package que também estará no README.md do repositório:

// Install
npm install @thiagomr/math-ops

import { sum } from '@thiagomr/math-ops';

//6
console.log(sum(4, 2));

Conclusão

Isso é tudo pessoal. Aqui está o link do repistório com todo o código utilizado. Espero que tenha ficado claro e que de alguma forma possa ajudar vocês a publicarem seus próprios packages. Gostaria de ouvir feedbacks, opiniões, sugestões e o que mais desejarem. Me sigam no Twitter para mais novidades. Grande abraço e até a próxima!

Class VS Function - Qual o jeito correto de escrever Javascript no mundo moderno?

Thiago Moraes — Sun, 04 Oct 2020 15:37:30 +0000

Introdução

O lançamento do ES6 (EcmaScript 2015) foi realmente um divisor de águas no Javascript, trazendo inúmeras novidades, dentre elas, a inclusão da declaração de classes (class Foo {...}). Mesmo após cinco anos, vejo que ainda há muita polêmica sobre o uso da mesma. Nesse artigo vou trazer minha visão sobre o assunto e também alguns exemplos práticos de como eu utilizo esse recurso.

O que acontece por baixo dos panos

A primeira coisa é entender o que de fato acontece quando nós utilizamos a keyword class. Em resumo, é simplesmente um syntax sugar para o padrão de prototypes do javascript. Anteriormente a existência de classes, a forma mais comum para se criar "instâncias" era utilizando factory functions (toda função em javascript é capaz de gerar objetos). Existem pequenas diferenças entre os dois modelos e a que considero mais relevante é que o uso de classes torna obrigatório o uso da keyword new para criar novos objetos. Segue exemplo:

//using Factory Functions
const Hero = function (name) {
    this.name = name;

    this.getName = function() {
        return this.name;
    }
}

const hero = new Hero('spiderman');
//it works
const hero = Hero('spiderman');
//it works

//using Class
class Hero {
    constructor(name) {
        this.name = name;
    }
    getName() {
        return this.name;
    }
}

const hero = new Hero('spiderman');
//it works
const hero = Hero('spiderman');
//TypeError: Class constructor Hero cannot be invoked without 'new'

Performance

Eu já ouvi algumas pessoas me questionando sobre perder performance devido ao uso de um syntax sugar como esse. Na minha opinião isso é completamente irrelevante. Provavelmente você nunca chegará em uma situação que esse tipo de coisa faça alguma diferença significante. Outro ponto importante é que muitas vezes você pode trocar alguns milisegundos de "execução" por "estética", o que pode vir a economizar horas de desenvolvimento.

Edit1: Caso você, assim como eu, goste de escovar alguns bytes, lembre-se que há outros syntax sugar bastante utilizados atualmente ("async / await", por exemplo). E há ferramentas (como o Babel, por exemplo) que permitem transpilar seu código de diferentes maneiras (explorando diferentes possiblidades de performance).

Edit2: Fui questionado por um amigo da comunidade sobre as evidências para esta afirmação (que eram baseadas na minha experiência trabalhando com Node). Achei interessante e fiz um rápido benchmark em cima de alguns exemplos utilizados. Caso queiram conferir, segue o github. Fiquem a vontade para testar e contribuir também.

Orientação a Objetos

Eu entendo que muito da decepção que algumas pessoas tiveram ao tentar utilizar essa feature, foi devido a uma expectativa errada de que isso faria com que a linguagem tivesse um suporte total a orientação a objetos. Com certeza apenas a declaração de classes e o suporte a heranças não é suficiente para esse propósito. Mas para isso nós temos o nosso querido Typescript <3.

Expressividade

Com certeza esse é o ponto mais relevante sobre toda essa questão. Javascript é uma das linguagens mais populares no mundo e muito disso se deve ao fato de ter uma baixa curva de aprendizado, ser multi paradigma e altamente flexível. Ao mesmo tempo que a flexibilidade é uma das coisas mais legais, também pode ser uma das mais prejudiciais, uma vez que faz com que a mesma tenha padrões pouco rígidos e isso pode se tornar um problema em projetos grandes, times inexperientes, etc. O fato de termos classes em Javascript faz com que a mesma se torne mais amigável para desenvolvedores que venham de outras linguagens (uma vez que o conceito de classes é um dos mais utilizados há um bom tempo em programação), além de trazer maior clareza para o código em diversas situações. Um outro fator é que eu, assim como grande parte da comunidade, venho programando bastante em Typescript (onde as classes fazem mais sentido ainda, devido a orientação a objetos por exemplo), isso torna o uso desse recurso bastante natural para mim. Inclusive, grandes frameworks JS como React e Angular, utilizam bastante esse padrão. A seguir, vou mostrar alguns exemplos que eu utilizo com classes.

PS: não vou colocar os exemplos equivalentes com Prototype, pois a ideia é muito mais enfatizar o recurso class do que fazer um comparativo entre ambas (além de considerar este um recurso ultrapassado).

Para padronizar e tratar erros HTTP (ao herdar o tipo Error, nós temos acesso a tudo que essa classe nos oferece, como a call stack do erro, por exemplo):

class BadRequestError extends Error {
    constructor(parameter) {
        super();

        this.status = 400;
        this.title = 'BadRequestError';
        this.message = `missing param [${parameter}]`
    }
}

class UnauthorizedError extends Error {
    constructor() {
        super();

        this.status = 401;
        this.title = 'UnauthorizedError';
        this.message = 'invalid token';
    }
}


class ServerError extends Error {
    constructor() {
        super();

        this.status = 500;
        this.title = 'ServerError';
        this.message = `unespected server error, please contact support`
    }
}

function httpError(error, response) {
    console.log(error);

    //some custom error logic

    if (!error.status) {
        error = new ServerError();        
    }

    return response.status(error.status).send({
        title: error.title,
        message: error.message
    });
}


function httpHandler(request, response) {
    try {
        //do something
        // throw new BadRequestError('parameterName')
        // throw new UnauthorizedError()
        // throw new Error('Random Error')
    } catch (error) {
        return httpError(error, response);
    }
}

Para herdar componentes nativos da linguagem, como o EventEmitter (aqui é possível criar várias chamadas, cada uma independente e tendo acesso a seus métodos):

const EventEmitter = require('events');

class Call extends EventEmitter {
    constructor() {
        super();
        this.startAt = null;
        this.endAt = null;
    }

    save() {
        //save call on database
    }
}


const call = new Call();

call.on('start', () => {
    console.log('starting call');
    this.startAt = new Date();
});

call.on('finish', () => {
    console.log('finishing call');
    this.endAt = new Date();
    this.save();

    console.log('call duration', this.endAt - this.startAt);
});

setTimeout(() => {
    call.emit('start');
}, 1000);

setTimeout(() => {
    call.emit('finish');
}, 4000);

Para injetar dependencias (Aqui o metódo construtor nos dá maior clareza em relação a inicialização das instâncias):

class LoggerService {
    info(...args) {
        console.log('[info]', ...args);
    }

    error(...args) {
        console.error('[error]', ...args);
    }
}

//broker service
class BrokerService {
    constructor({ logger }) {
        this.logger = logger;
    }

    ack(message) {
        this.logger.info('[ack message]', message);
    }
}

class HistoryService {
    constructor({ logger }) {
        this.logger = logger;
    }

    save(msg) {
        this.logger.info('[save message]', msg);
    }
}

class Subscriber {
    constructor({ broker, logger, history }) {
        this.broker = broker;
        this.logger = logger;
        this.history = history;
    }

    handle(msg) {
        //do something

        this.history.save(msg);
        this.broker.ack(msg);
        this.logger.info('done');
    }
}

//service factories
const logger = new LoggerService();
const broker = new BrokerService({ logger });
const history = new HistoryService({ logger });

//subscriber
const subscriber = new Subscriber({ broker, logger, history });

subscriber.handle({ queue: 'test', content: 'I am a message' });

Apesar de usar bastante o recurso de classes, em alguns casos eu gosto de utilizar functions. Seguem alguns exemplos.

Para criar helpers, onde as funções tem um mesmo contexto mas não uma ligação tão forte entre si:

//helpers.js
function validateEmail(email) {
    //validate email
}

function validatePhoneNumber(number) {
    //validate number
}

module.exports = {
    validateEmail,
    validatePhoneNumber
};

//index.js
const { validateEmail, validatePhoneNumber } = require('./helpers');

Para criar middlewares:

//auth.js
module.exports = (request, response, next) {
    auth();
    next();
}

Afinal, devo usar class ou function?

Alguns casos eu considero óbvios. Se você precisa criar instâncias de uma classe ou utilizar herança, claramente eu escolheria class. Se você vai trabalhar com programação funcional, como o próprio nome sugere, utilizaria funções. Porém, nem tudo é apenas preto e branco. É preciso manter a mente aberta para aceitar que há diversas formas boas de se chegar em um resultado. Desenvolver um software é como cuidar de uma biblioteca, você precisa organizar os livros com uma certa lógica para que os mesmos façam sentido onde estão, sejam facilmente encontrados e possam ser adicionados novos de forma intuitiva e simples. Sendo assim, mais importante que escolher um ou outro, é conhecer os recursos disponíveis para ter mais opções na hora construir softwares consistentes.

Conclusão

Nós escrevemos código para desenvolvedores. Por esse motivo, além de desenvolver um software de qualidade (que atenda os requisitos para qual foi designado e possua uma boa performance), é também importante escrever códigos legíveis, entendíveis e que possuam uma interface amigável e intuitiva para novos devs. O fato é que o uso de classes nos proporciona ferramentas muito interessantes para este objetivo. Então se você ainda não usa ou tem algum tipo de preconceito, recomendo fortemente abrir um pouco a mente e experimentar tudo que de melhor o Javascript pode te oferecer!

E vocês, o que acham sobre o assunto? Fiquem a vontade para colaborar com opiniões, experiências e feedbacks.

Desvendando o mundo mágico dos acrônimos: SOLID, KISS, YAGNI, DRY, DDD, TDD

Thiago Moraes — Thu, 03 Sep 2020 13:13:53 +0000

Introdução

No artigo de hoje vou esclarecer um pouco sobre essas siglas que ainda deixam muita gente confusa. De maneira geral, eu diria que a intenção é proporcionar o desenvolvimento de software de maior qualidade. Vamos começar então abordando o que seria um software de qualidade e qual a importância do mesmo.

O que é um software de qualidade?

Definir a qualidade de um software pode ser algo extremamente complexo, então vou resumir dois principais pontos dentro do assunto que iremos abordar.
Um software é um programa que visa resolver determinado problema. No mundo empresarial, diríamos que é uma solução que gera um determinado valor e satisfaz um cliente. Então esse é nosso primeiro conceito: a qualidade de um software pode ser definida pela sua capacidade em satisfazer as necessidades de um determinado usuário. E aí entram questões como usabilidade, aplicação correta de regras de negócio, performance, etc.
O segundo conceito é em relação ao processo de desenvolvimento, onde podemos levar em consideração a clareza do código, consistência, manutenibilidade, capacidade de expansão, dentre outros. No fim das contas, tudo está interligado, pois um software com boas práticas de design, claro e consistente, geralmente vai estar mais próximo de atender as necessidades para a qual foi especificado.

Por que precisamos de software de qualidade?

O primeiro ponto a destacar é que nós desenvolvemos software para pessoas. Mais especificamente para necessidades de pessoas. E as necessidades, inevitavelmente, mudam. Se as necessidades mudam, os softwares também deveriam ter a capacidade de mudar. Mas não basta apenas mudar, tem que ser fácil, rápido e livre de riscos.
O segundo ponto é que nós trabalhamos em times. E esses times possuem pessoas diferentes, com habilidades diferentes e eles também mudam. Todas essas mudanças, de softwares e de pessoas, geram uma série de problemas que todo desenvolvedor já passou (ou ainda vai passar), como demorar dias lendo um código completamente sem sentido ou desistir de implementar uma feature por medo de quebrar algo que funcionava anteriormente.
Então o importante aqui é que nós escrevemos código para pessoas, mas principalmente, para desenvolvedores. E ter um código limpo e claro, ou seja, documentado, testável, com padrões consistentes e boas práticas, vai trazer maior agilidade e segurança no desenvolvimento de novas funcionalidades. É sobre isso que se tratam os acrônimos citados no título, trazer maior qualidade para o código escrito. Alguns são conceitos, outros metodologias, mas todos com o mesmo propósito. Então, vamos aos conceitos.

Nota: Vale lembrar que a ideia aqui é dar uma visão geral sobre cada um dos conceitos. Alguns dos assuntos são extremamente profundos e merecem um (ou mais) artigos dedicados.

SOLID

O famoso S.O.L.I.D. é um conjunto dos 5 princípios essenciais para o Desenvolvimento Orientado a Objetos, visando construir código mais compreensível, flexível e sustentável. Alguns dos conceitos são mais fáceis de entender analisando exemplos, portanto, este será o único tópico em que vou colocar alguns códigos:

[S]ingle Responsibility Principle (Princípio da Responsabilidade Única)

A class should have one, and only one, reason to change.

Simples assim. Uma classe deve ter uma e somente uma responsabilidade. Apesar de parecer um dos princípios mais simples, é também um dos mais importantes, já que é essencial para o funcionamento dos outros. O Seguem dois exemplos:

//without solid
class EmailService {
    validateEmailAndSend(string emailAddress, string subject, string content): boolean;
}

//with solid
class EmailService {
    sendMail(emailAddress: string, subject: string, content: string): void {
        //
    };
}

class Validator {
    validateEmail(email: string): boolean {
        //
    };
}

[O]pen/Closed Principle (Princípio do Aberto/Fechado)

You should be able to extend a classes behavior, without modifying it.

Este princípio diz que você deve ser capaz de expandir seu código, ou seja, criar novas funcionalidades, sem modificar o código existente. O grande problema ao mudar um código existente é a chance de criar um possível bug. O exemplo a seguir é interessante pois ao mesmo tempo que reflete esse princípio, também está bastante atrelado com o anterior, uma vez que o cálculo do custo de cada tipo de fornecedor pode ter uma lógica diferente (e consequentemente são responsabilidades diferentes). Para cada novo tipo de fornecedor, o código seria alterado em uma parte crítica.

//without solid
class Provider {
    calculateCost(): number {
        if (this.type == 'email') {
        //
        } else if (this.type == 'internet') {
        //
        } else {
        //
        }
    }
}

//with solid
interface Provider {
    calculateCost(): number;
}

class EmailProvider implements Provider {
    calculateCost(): number {

    }
}

class InternetProvider implements Provider {
    calculateCost(): number {

    }
}

[L]iskov Substitution Principle (Princípio da Substituição de Liskov)

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.

Olhando pela primeira vez, esse princípio assusta, mas o conceito é simples. Significa que classes derivadas de uma mesma classe devem poder ser substituídas entre si. No exemplo a seguir, as classes não são intercambiáveis pois não têm a capacidade de implementar os mesmo métodos:

//without solid
class Bird {
    walk(): void {
        //
    }

    fly(): void {
        //
    }

}

class Duck extends Bird {}

class Owl extends Bird {}

//with solid
class Bird {
     walk(): void {
        //
     }
}

class FlyingBird extends Bird {
    fly(): void {
        //
    }
}

class AquaticBird extends Bird {
    swim(): void {
        //
    }
}

class Duck extends AquaticBird {}

class Owl extends FlyingBird {}

[I]nterface Segregation Principle (Princípio da Segregação de Interfaces)

Make fine grained interfaces that are client specific.

Este princípio defende que uma classe deve depender de interfaces que contenham apenas o essencial para seu uso, sendo assim, priorizando interfaces específicas ao invés de genéricas. Segue exemplo:

//without solid
interface Stream {
    read(): void;
    write(): void;
}

class Reader implements Stream {}
class Writer implements Stream {}

//with solid
interface ReadableStream {
    read(): void;
}
interface WritableStream {
    write(): void;
}

class Reader implements ReadableStream {}
class Writer implements WritebleStream {}
class DuplexStream implements ReadableStream, WritableStream {}

[D]ependency Inversion Principle (Princípio da Inversão de Dependências)

Depend on abstractions, not on concretions.

Abstrações nunca deveriam depender de classes concretas. Entende-se por classes concretas, as que realmente têm a implementação completa de algo. O conceito da inversão de dependência tem como objetivo tornar as classes mais desacopladas, fazendo com que se tornem mais sustentáveis e testáveis. No exemplo a seguir, a classe está completamente dependente de um outro serviço. Com as alterações, ela vai depender apenas de uma interface, sendo possivel trocar facilmente a dependencia (para escrever um teste ou alterar ou utilizar um outro serviço de comunicação, por exemplo):

//without solid
class CloudNotificationService {
    sendMessage(): void {
        //
    }
}

class Transaction {
    private notificationService: CloudNotificationService;

    constructor(notificationService: CloudNotificationService) {
        this.notificationService = notificationService;
    }

    save(): void {
    //...
        this.notificationService.sendMessage();
    }
}

//with solid
interface NotificationService {
    sendMessage(): void;
}

class CloudNotificationService implements NotificationService {
    sendMessage(): void {
        //
    }
}

class Transaction {
    private notificationService: NotificationService;

    constructor(notificationService: NotificationService) {
        this.notificationService = notificationService;
    }

    save(): void {
        //...
        this.notificationService.sendMessage();
    }
}

KISS

Keep it simple, stupid

Esse é certamente o meu preferido. É sobre manter as coisas o mais simples possível e pode ser aplicado em tudo. Manter algo simples na prática significa dar bons nomes para metódos e variáveis, aplicar o conceito da responsabilidade única, organização do código e tudo que seja benéfico nesse sentido. Eu recomendo que você aplique esse conceito na sua vida como um todo, não só no desenvolvimento de software.

YAGNI

You Aren't Gonna Need It

Esse é um princípio da metodologia ágil XP (Extreme Programming) que sugere que você não deve adicionar coisas que não vai utilizar no seu código. No dia-a-dia isso vejo isso muito relacionado à Over Engineering, ou seja, criar uma solução muito mais complexa do que o necessário pensando em uma situação futura que pode chegar a nunca existir.

DRY

Don't repeat yourself

DRY é sobre não repetir código desnecessariamente. Você deve reutilizar código sempre que possível, de uma maneira inteligente, fazendo assim reuso de código sempre que possível e tornando alterações mais fáceis.

DDD

A sigla significa Domain Driven Development (Desenvolvimento Orientado a Domínio). O domínio de um software é a área de conhecimento a qual o mesmo pertence. Esse é um conceito um pouco mais abrangente que os anteriores, pois se trata de um modelo estrutural de software que propõe a organização em camadas separadas por subdomínios, visando isolar responsabilidades, desacoplamento e um criar softwares que refletem de forma clara o domínio para o qual foram criados. Mais do que um modelo de arquitetura, esse método tem alguns conceitos muito interessantes como o de manter uma linguagem única entre todos os envolvidos em um projeto.

TDD

Test Driven Development (Desenvolvimento Orientado a Testes) é uma metodologia que propõe iniciar o desenvolvimento criando testes para as funcionalidades propostas e somente depois partir para as implementações. O método consiste em escrever testes bastante específicos, refatorando o código até chegar na melhor versão possível. Esse tópico gera muita polêmica, pois muitos desenvolvedores acham que isso acarreta em mais código a ser desenvolvido e maior tempo de manutenção além de duvidarem da prática. Sim, de fato, os testes são código, e como qualquer outro código, precisam de manutenção, refatoração, etc. Porém, se aplicado da forma correta, com disciplina, pode trazer excelentes ganhos a médio / longo prazo.

Conclusão

A ideia por trás de todos os conceitos é a mesma: produzir um código de qualidade. Isso não significa que você precisa usar tudo isso ao mesmo tempo para produzir um bom software, mas sim que você precisa conhecer as ferramentas para que seja possível escolher as melhores opções de acordo com a situação em que você se encontra. Muitos dos conceitos tem um aspecto comportamental e podem trazer benefícios para sua vida além do trabalho como desenvolvedor.
Isso é tudo pessoal. Espero que tenham curtido e sintam-se a vontade para enviar dúvidas, sugestões, feedbacks e o que mais desejarem.

Referências:

https://khalilstemmler.com/articles/solid-principles/solid-typescript/

https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

https://khalilstemmler.com/wiki

Automatizando a criação de um ambiente de desenvolvimento com Docker + Bash Script + Portainer

Thiago Moraes — Sat, 29 Aug 2020 15:10:22 +0000

Introdução

Facilidade, automatização e velocidade são coisas que nós, desenvolvedores, amamos. Eu trabalho em muitos projetos, com diversas ferramentas, como MongoDb, MySQL, RabbitMQ, Redis, dentre outras e muitas vezes fica difícil gerenciar tudo isso (ao migrar de máquina, por exemplo). A ideia hoje é mostrar uma forma simples e eficiente de ter todas suas ferramentas centralizadas e organizadas utilizando Docker e Bash Script (quem me conhece sabe que eu amo Bash Script <3) e também o gerenciamento das mesmas através do Portainer, uma interface gráfica para o Docker. Lembrando que deixarei todos os exemplos no github ao final do artigo. E como a ideia é ser ágil, esse tutorial vai passar na velocidade da luz. Então vamos nessa!

Pré-requisitos

Docker
Docker Compose

Criando nossos serviços

Primeiramente, criaremos um arquivo do Docker Compose, que irá conter a descrição de todos os nossos serviços. Aqui utilizarei os serviços citados no inicio (Mysql, MongoDb, RabbitMQ e Redis), além do Portainer, que vai nos dar uma visão e gerenciamento de todos os serviços. Você também pode adicionar os serviços da sua preferência.

Esse será nosso arquivo de configuração:

#docker-compose.yml
version: '3.4'
x-logging:
    &default-logging
    options:
    max-size: '10m'
    max-file: '1'
    driver: json-file
services:
    portainer:
        image: portainer/portainer
        container_name: portainer
        restart: on-failure
        ports:
            - "9000:9000"
        volumes:
        - /var/run/docker.sock:/var/run/docker.sock
        - ${VOLUMES_DIR}/portainer:/data
        logging: *default-logging          
    mysql:
    image: mysql:5.7
    command: mysqld --sql_mode='NO_ENGINE_SUBSTITUTION'
    restart: on-failure
    environment:
        - MYSQL_ROOT_PASSWORD=toor
        - DEFAULT_TIME_ZONE=America/Sao_Paulo
        - TZ=America/Sao_Paulo           
    volumes:
        - ${VOLUMES_DIR}/mysql:/var/lib/mysql
    container_name: mysql
    ports:
        - 3306:3306
    logging: *default-logging
    redis:
        image: redis:latest
        container_name: redis
        ports:
        - "6379:6379"
        logging: *default-logging      
    mongo:
        image: mongo:latest
        volumes:
            - ${VOLUMES_DIR}/mongodb:/data/db
        container_name: mongo
        ports:
            - 27017:27017
        logging: *default-logging
    rabbitmq:
        image: rabbitmq:3-management
        container_name: rabbitmq
        ports:
            - "15672:15672"
            - "5672:5672"
        volumes:
            - ${VOLUMES_DIR}/rabbitmq:/var/lib/rabbitmq
        environment:
            - RABBITMQ_ERLANG_COOKIE=cookie
            - RABBITMQ_DEFAULT_USER=root
            - RABBITMQ_DEFAULT_PASS=toor
        logging: *default-logging

Aqui vale destacar dois pontos importantes. O primeiro é que mapeamos os volumes dos serviços utilizando uma variável que vai definir onde os dados persistentes dos containers serão armazenados na máquina host. Essa configuração só é necessária se você desejar persistir a informação, caso contrário, cada vez que você refizer o build ou remover a imagem, você perderá todos os dados contidos nelas.

O segundo é a utilização de uma política para definir o tamanho máximo do armazenamento de logs em cada container. É importante caso ocorra alguma situação inesperada, como um erro de algum container que fica acumulando logs, podendo levar você até mesmo a ficar sem storage na máquina.

Rodando os serviços

Agora que já temos o nosso arquivo de configuração dos serviços, vamos automatizar as ações que iremos utilizar com Bash Script, fazendo uma pequena abstração de alguns comandos. Nosso script ficará dessa forma:

#script.sh
export VOLUMES_DIR=/var/volumes/docker

up() {
    docker-compose up --build -d $1
}

logs() {
    docker-compose logs -f $1
}

down() {
    docker-compose down
}

stop() {
    docker-compose stop $1
}

rmi() {
    docker rmi $(docker images -f dangling=true -q) --force
}

$*

Rodando todos os serviços:

bash script.sh up

Rodando um serviços específico

bash script.sh up <service name>

Parando todos os serviços:

bash script.sh down

Parando um serviço específico:

bash script.sh stop <service name>

Acessando os logs de todos os serviços:

bash script.sh logs

Acessando os logs de um serviço específico:

bash script.sh logs <service name>

Adicionei um comando extra muito útil também que remove todas as imagens não utilizadas (se você usa Docker no dia-a-dia e nunca fez uma limpeza, ficará surpreso com o quanto de storage será liberado ao rodar esse comando):

bash script.sh rmi

Gerenciando os serviços

Bom, levando em consideração que subimos todos os serviços rodando o primeiro comando, vamos explorar um pouco o Portainer como um meio de gerenciar nossos serviços. O Portainer é uma interface gráfica para o Docker que permite ver containers, volumes, rodar imagens e muito mais. De acordo com nosso arquivo de instalação, ele deve estar disponível na porta 9000. Acessando 'http://localhost:9000' teremos acesso a interface do mesmo. No primeiro acesso, você deve criar uma senha para administrador.

Em seguida escolha a opção Local e clique em connect, para que o portainer possa se conectar aos seus containers locais.

Acessando o nosso endpoint criado, no menu Containers, temos acesso aos nossos serviços (os que estão rodando e os que estão parados também).

Clicando em um Container, teremos um menu com algumas opções, como logs, stats (que mostra dados sobre uso de cpu, memória, etc) e até mesmo acesso ao terminal dentro do container. É possível acessar algumas dessas opções através do menu rápido na propria tela que lista os containers.

Outra opção interessante é a App Templates, onde você tem uma variedade enorme de serviços e é possível fazer deploy com apenas um clique.

Como prometi que seria um artigo rápido, vamos ficar por aqui, mas vale muito a pena explorar outras opções, a interface é muito rica e intuitiva (merecia um artigo só pra ele). Todos os exemplos citados acima estão no github:

https://github.com/thiagomr/docker-utils

Conclusão

Hoje vimos como é simples e rápido ter um ambiente de desenvolvimento rodando apenas um comando e também uma forma visual de gerenciar o mesmo. Se você curtiu essa dica, dá um like, star no github e me segue no twitter para novidades e deixe aqui seu comentário. Feedbacks são mais que bem-vindos.

Grande abraço e até a próxima!

Frameworks JS: Love or Leave them

Thiago Moraes — Sun, 23 Aug 2020 16:07:47 +0000

Hey folks, how are you doing? Good, I hope.

Today I’m going to talk about a polemic subject on JS community:

Frameworks… to use or not to use, that’s the question.

Introduction

If you’re not familiar with the term, in a nutshell, it can be said that a framework is a solution written to solve a generic problem. It’s also commonly related with libraries, since a framework can also be a library or a set of them.

In the Javascript universe there are a lot of these generic features, mostly of open source code, created by the community itself. And there is also a lot of discussion about whether or not to use these third party codes. This article is splitted in two parts, in the first I'll address some pros and cons on the subject and in the second I’ll bring a practical example on some points mentioned.

What is the right choice?

The first thing I would like to say is that there is not “right or wrong” about this subject, it’s a much more matter of “necessity and choose”. Therefore, it’s extremely necessary to know what kind of problem we’re trying to solve and in what context, to be able to choose the most appropriate solution. I’ll list some of the points that I consider the most important in both approaches.

Note: It’s worth mentioning that nothing written here it’s an absolute rule, but rather a set of opinions built according to my experiences and that may vary according to experiences of each one. It’s also necessary to understand that in most cases we’re talking about frameworks with a certain relevance, with good practices, organization, tests and good quality standards.

Strengths of using frameworks:

It’s a solution used by a vast community, therefore, there are several people working to find resolutions of the same problem, which brings a collective view and different points of view.
It’s a simpler abstraction to something that may not be important in the desired context. For example, it’s not necessary to know how all the gears in a car work to learn how to drive and get around more easily.
Agility in development. It’s not a rule, but it’s usually is a gain, since abstractions decrease the complexity level of some solutions.

Weaknesses of using frameworks:

Customization. As it’s a solution that aims to solve a specific type of problem, it may be that at some point you have a case that does not fit into it.
Bugs. It may be that an update to the framework or a version change generates an unwanted bug in your code and you have no control over it to fix it.
Dependency. Something very common is the development of a code be completely tied to a framework, creating a total dependency relationship. That is, if at any point the framework is discontinued or no longer maintained, this could became a big problem.

Strengths of not using frameworks:

Greater control of the code. Since you’re going to develop everything using native technology, you have complete control over everything that has been built.
Highly customizable solutions.
Less overload. The fewer third-party modules you application has to load, it will be lighter and build more efficiently.
Greater mastery of native technology.

Weaknesses of not using frameworks:

Complexity. Sometimes, it may be complex and even unnecessary to create a solution from scratch for the whole problem.
Standardization. When you work in a big team, depending on their experience and the size of the project, it may be hard to manage and maintain over time.
Time. You’ll probably require more time developing some things that are already "done".

Conclusion

I, in particular, think that thousands of frameworks are one of the coolest things in the javascript universe. It gives me the feeling of working all the time with people around the world, in addition to having access to great solutions that I probably wouldn’t have the time and ability to develop on my own or in a lifetime. Still, now and then I'm in a situation where the best option is not to use it. For example, when there is really no framework that fully meets your needs or when for security reasons you choose not to carry sensitive information through third-party libs, or still because you cannot risk depend on an external lib, among others.

Taking into account all pros and cons raised for both hypotheses, it’s clear that it’s not a simple matter of “good or bad” or “like or dislike”, but of making the right choices within a given context. Therefore, it’s to take stock of the situation you’re in and the pros and cons of each approach to get the best possible solution.

Next steps

Although I think using frameworks are really positive in productivity terms, standardizing, reuse, among other advantages, there is something that I see on a daily basis that I consider a negative point. Some developers are totally oriented towards the use of frameworks, to the point of not knowing how some basic things of the technology work. Something I always defend is the good old "do the basics", to know well the concepts and main nuances of the language or technology with which you work. So, as i mentioned at the beginning, in part two of this article I’ll bring a very cool practical example on this topic, addressing one of the most used solutions in Node JS.

That’s it for now. And you, what do you think about the use of frameworks? Leave your opinions, experiences and feedbacks on comments.

May the force be with you, see you next time.

Como funciona o Express JS? Criando um HTTP Server "express like" do zero, sem frameworks

Thiago Moraes — Sat, 22 Aug 2020 19:59:50 +0000

Introdução

Na primeira parte deste artigo, fiz uma abordagem com prós e contras sobre o uso (ou não uso) de frameworks. Apesar de ter grandes vantagens, tem um ponto negativo que me chama bastante atenção no dia-a-dia: muitos desenvolvedores estão completamente dependentes de frameworks, ao ponto de não conhecer alguns dos fundamentos básicos da tecnologia com a qual trabalham. Como já citei anteriormente, eu defendo bastante o “do the basics”, ter o conhecimento da base faz com que você tenha uma visão mais ampla e consequentemente, implementações melhores para suas soluções.

Hoje eu vou trazer a implementação de um HTTP Server inspirado no Express, feito completamente do zero, sem uso de frameworks. Ao longo do caminho vou mostrar alguns exemplos bem comuns no universo Node JS, como high order functions, chaining functions e events. Em paralelo, vou trazer a implementação com o próprio Express também para fazermos um comparativo. No final do artigo, vou deixar o link com todos os exemplos no Github. Então, vamos nessa!

Nota: De forma alguma a intenção deste artigo é refazer o express ou criar um framework que substitua o mesmo. Os exemplos são totalmente didáticos, visando o entendimento de alguns conceitos, não tendo a intenção de rodar em produção ou ser um robusto framework de servidor http.

Primeiramente nós precisamos de um nome legal, então para fazer uma alusão ao express, vamos chamar nosso módulo de Rockspress.

Conhecendo o módulo HTTP

Antes de iniciarmos o desenvolvimento do módulo em si, vou demonstrar como criar um simples http server em NodeJS (acreditem, muitos desenvolvedores nunca tiveram a necessidade de criar um). No fim das contas, todos os frameworks que fazem abstração de servidor HTTP utilizam o módulo nativo http (ou https). Segue exemplo:

//http.js
const http = require('http');

http.createServer((req, res) => {
    res.write('done!');
    res.write('\n');
    res.end();
}).listen(8000, () => console.log('server listen at 8000'));

Primeiramente chamamos a função createServer, que retorna um callback com um objeto para o request (que contém todas as informações do que é recebido a cada requisição ao servidor, como url, body, headers, etc) e outro para o response (que contém toda a estrutura para retornar ao cliente uma resposta no padrão http, como status code, body, headers, etc). Em seguida utilizamos a função listen para deixar o servidor disponível na porta 8000. No nosso exemplo estamos apenas escrevendo uma mensagem no corpo do response e finalizando o mesmo. Agora, vamos de fato ao nosso módulo.

Iniciando o módulo Rockspress

A primeira coisa que faremos é criar uma classe e no método construtor, criaremos uma propriedade que vai receber nosso server nativo, conforme o exemplo anterior:

//rockspress.js
const http = require(‘http’);

class Rockspress {
    constructor() {
        this.server = http.createServer();
    }
}

Criando uma estrutura de dados

Em seguida, criaremos uma estrutura de dados, que vai ser responsável por receber e armazenar nossas funções de acordo com o roteamento. Escolhi utilizar uma estrutura de chave / valor:

class Rockspress {
    constructor() {
        this.server = http.createServer();

        this.router = {
            GET: {},
            POST: {},
            PUT: {},
            DEL: {}
        };
    }
}

Criamos um objeto chamado router, que vai conter uma propriedade para cada método http que iremos implementar. Por sua vez, cada uma das dessas propriedades também é um objeto.

Registrando novas rotas

Agora que já temos umas estrutura para armazenar os dados, vamos criar uma função para registrar novas rotas de acordo com o método http escolhido. Vamos utilizar uma high order function (para quem não conhece o termo, é uma estratégia bem comum em programação funcional, se tratando uma função que opera outra função, recebendo como argumento ou retornando como saída). Não vou entrar muito a fundo nos detalhes, pois isso renderia um artigo inteiro. No nosso caso a intenção é fazer uma abstração de um método que recebe um parâmetro predefinido e parâmetros inseridos por quem chama a função.

registerRoute(method) {
    return function (route, callback) {
        this.router[method][route] = callback;
    }
}

A abstração recebe o método http, a rota escolhida e qual função será executada e salva essas informações de acordo com nossa estrutura de dados.

Fazendo o handle dos requests

Agora nós precisamos redirecionar os requests recebidos de acordo com a rota e método escolhidos. O módulo http nativo do Node, é todo baseado em eventos. Sempre que recebemos uma nova requisição no nosso servidor, é emitido um evento chamado request. Vamos criar uma função que vai fazer o gerenciamento desse evento, utilizando as propriedades req.method e req.url para acessar nossa estrutura de dados, enviando como argumentos os objetos de request e response.

class Rockspress {
    constructor() {
        //...

        this.server.on('request', this.handleRequest.bind(this));
    }

    async handleRequest(req, res) {
        if (!this.router[req.method][req.url]) {
            res.statusCode = 404;
            res.write('not found');
            return res.end();
        }

        this.router[req.method][req.url](req, res);
    }
}

Adicionamos mais uma abstração que vai verificar se o método e rota solicitados existem. Caso negativo, será retornada uma resposta padrão com o statusCode 404 (not found).

Agora que já estamos fazendo o roteamento das requisições recebidas para seus devidos métodos, precisamos alterar os objetos de request e response, colocando algumas abstrações adicionais para tornar o uso mais amigável.

Alterando o objeto Response

Vamos começar com o response. Criaremos uma função que recebe o response original e adicionar dois métodos no mesmo. O primeiro, seta o statusCode e o segundo escreve no responseBody um argumento recebido. Os dois retornam a própria response, permitindo assim o uso de um padrão bastante comum em javascript chamado chaining functions, que consiste em chamar múltiplas funções consecutivas a partir mesmo objeto.

setupResponse(response) {
    response.status = (statusCode) => {
        response.statusCode = statusCode;
        return response;
    }

    response.send = (responseBody) => {
        response.write(responseBody);
        response.end();
    }

    return response;
}

Exemplo de chamada com chaining function:

res.status(200).send('ok');

Nesse momento, já somos capazes de receber requisições, rotear para seus devidos metódos e retornar uma resposta. Mas antes de testar tudo funcionando, iremos implementar uma abstração para o objeto do request, permitindo pegar o que foi enviado como body da requisição.

Alterando o objeto Request

O recebimento do corpo da requisição, também é feito via evento, o mesmo é um stream que vem em partes. O que faremos é juntar as partes dessa stream, colocando tudo em uma propriedade do request em forma de json, para um acesso mais fácil (simulando algo semelhante ao que o middleware body-parser faz).

setupRequest(request) {
    request.body = '';

    request.on('data', chunk => {
        request.body += chunk.toString();
    });

    return new Promise(resolve => request.on('end', () => {
        request.body = request.body ? JSON.parse(request.body) : '';
        resolve(request);
    }));
}

Assim que o request recebe todas as partes, fazemos o parse para JSON e retornamos o request já alterado.
Vamos adicionar nossos métodos de setup de request e response no nosso handler de requests. Esse setup também poderia ser feito por eventos, porém, escolhi utilizar promises para facilitar o entendimento (É necessário colocar a keyword async no mesmo, pois estamos chamando uma promessa utilizando a keyword await).

async handleRequest(req, res) {
    req = await this.setupRequest(req);
    res = this.setupResponse(res);

    if (!this.router[req.method][req.url]) {
        res.statusCode = 404;
        res.write('not found');
        return res.end();
    }

    this.router[req.method][req.url](req, res);
}

Expondo o servidor em uma porta

É necessário também expor uma porta onde o server vai escutar as requisições enviadas. Para isso, faremos uma simples abstração do método listen do módulo http, apenas passando pra frente os mesmos argumentos recebidos:

listen() {
    const args = Array.prototype.slice.call(arguments);
    return this.server.listen.apply(this.server, args);
}

Refatorando

Para finalizar, vamos refatorar o código, dando mais clareza na leitura, criando funções que abstraem a criação da estrutura de dados e configuração dos métodos. Também iremos exportar uma instância do mesmo. Com isso, nosso módulo completo ficará da seguinte forma:

//rockspress.js
const http = require('http');

class Rockspress {
    constructor() {
        this.server = http.createServer();
        this.setupRoutes();
        this.setupMethods();
        this.server.on('request', this.handleRequest.bind(this));
    }

    setupRoutes() {
        this.router = {
            GET: {},
            POST: {},
            PUT: {},
            DEL: {}
        };
    }

    setupMethods() {
        this.get = this.registerRoute('GET');
        this.post = this.registerRoute('POST');
        this.put = this.registerRoute('PUT');
        this.del = this.registerRoute('DEL');
    }

    async handleRequest(req, res) {
        req = await this.setupRequest(req);
        res = this.setupResponse(res);

        if (!this.router[req.method][req.url]) {
            res.statusCode = 404;
            res.write('not found');
            return res.end();
        }

        this.router[req.method][req.url](req, res);
    }

    setupRequest(request) {
        request.body = '';

        request.on('data', chunk => {
            request.body += chunk.toString();
        });

        return new Promise(resolve => request.on('end', () => {
            request.body = request.body ? JSON.parse(request.body) : '';
            resolve(request);
        }));
    }

    setupResponse(response) {
        response.status = (statusCode) => {
            response.statusCode = statusCode;
            return response;
        }

        response.send = (responseBody) => {
            response.write(responseBody);
            response.end();
        }

        return response;
    }

    registerRoute(method) {
        return function (route, callback) {
            this.router[method][route] = callback;
        }
    }

    listen() {
        const args = Array.prototype.slice.call(arguments);
        return this.server.listen.apply(this.server, args);
    }
}

module.exports = new Rockspress();

Implementando o HTTP Server

E agora vamos criar a implementação do mesmo, com rotas GET e POST:

//index.js
const rockspress = require('./rockspress');

rockspress.get('/', (req, res) => {
    return res.status(200).send('main');
});

rockspress.get('/ping', (req, res) => {
    return res.status(200).send('pong');
});

rockspress.post('/send', (req, res) => {
    console.log('request body', req.body);

    return res.status(200).send('sent');
});

rockspress.get('/error', (req, res) => {
    return res.status(500).send('error');
});

rockspress.listen(8000, () => console.log('listen at 8000'));

Testando as rotas implementadas

Para testar, vamos utilizar o comando curl (pode-se utilizar qualquer client http desejado). Primeiro vamos inicializar app:

node index.js
#listen at 8000

Rota GET:

curl http://localhost:8000/ping
#pong

Rota POST:

curl -X POST http://localhost:8000/send -H 'Content-Type: application/json' --data '{"foo":"bar"}'
##request body {"foo":"bar"}
##sent

E para finalizar, a implementação lado a lado com express e com nosso rockspress:

//both.js

/**
 * ------------------------------------------------------------------------------
 *  Server with express framework
 */

const express = require('express');
const app = express();

app.use(express.json());

app.get('/', (req, res) => {
    return res.status(200).send('main');
});

app.get('/ping', (req, res) => {
    return res.status(200).send('pong');
});

app.post('/send', (req, res) => {
    console.log('request body', req.body);

    return res.status(200).send('sent');
});

app.get('/error', (req, res) => {
    return res.status(500).send('error');
});

app.listen(8000, () => console.log('listen at 8000'));


/**
 * ------------------------------------------------------------------------------
 *  Server with custom framework
 */


const rockspress = require('./rockspress');

rockspress.get('/', (req, res) => {
    return res.status(200).send('main');
});

rockspress.get('/ping', (req, res) => {
    return res.status(200).send('pong');
});

rockspress.post('/send', (req, res) => {
    console.log('request body', req.body);

    return res.status(200).send('sent');
});

rockspress.get('/error', (req, res) => {
    return res.status(500).send('error');
});

rockspress.listen(8001, () => console.log('listen at 8001'));

Segue o link do github com todos os exemplos: https://github.com/thiagomr/rockspress

Conclusão

E assim vamos chegando ao fim. Além de aprender diversos conceitos da linguagem, é possível também perceber o quanto é trabalhoso implementar o mínimo de funcionalidades (mesmo que para fins didáticos, sem se preocupar com performance, dentre outros aspectos importantes) de um framework como o express. Eu recomendo que vocês façam esse tipo de engenharia reversa, pra mim funciona como uma ótima fonte de aprendizado e para os novatos pode ser realmente esclarecedor, afinal, quem nunca se perguntou "mas de onde vem esse req, res"?

Então é isso, espero que tenham gostado. Me sigam no twitter para ficarem ligados nos proximos artigos e compartilhem com os amigos para que eu possa continuar gerando conteúdo. Feedbacks, comentários e sugestões sempre são bem-vindos.

Um grande abraço e até a próxima!

The power of abstraction

Thiago Moraes — Mon, 17 Aug 2020 19:13:48 +0000

Hey folks, how are you doing?

Today I’m going to talk about a subject that is very present in our day-to-day lives and which is somewhat of paradox, because while having one of its main characteristics to simplify something, it is also extremely complex. Let’s talk about abstraction!

Note: This is my first article in English and I’m learning how to improve my writing. So, sorry about mistakes and help me to grow up!

What is abstraction?

I would say that sometimes it's hard to even start to explain in an easy way what this term means, since the concept is (ironically) something abstract. Let’s start by bringing the meaning of the word in two different approaches.

In philosophy:

Abstraction is an intellectual operation that consists of isolating, for example in a concept, an element to the exclusion of others, from which abstraction is then made. For example, abstracting a leather football ball, by a football ball, we have only the lean information about properties and behaviors of a football ball (Wikipedia).

In computer science:

Abstraction is the ability to concentrate on essential aspects in a context, ignoring characteristics of less importance or accidentals. In object-oriented modeling, a class is an abstraction of existent entities on a software system domain (Wikipedia).

In a very simplified way, I would say that abstraction is a way of bringing something that has a certain depth or / and complexity to a simpler layer and easily layer, that is, what really matters within a given context.

When you’re accessing a website, you’re only concerned about typing something in the address bar of your browser and that the requested page appears so that you can access the content. It’s not important at this moment the whole path that your request takes, the translation of address for something logical, packaging and unpacking TCP packets, routers, DNS services, external servers, data processing, etc. This can tell us that the browser can be seen as an abstraction of your access to the web.

Why it is important and how to use

In my day-to-day life as a Software Engineer, I'm constantly talking, studying and dealing with extremely technical issues, related to software development. However, I always try to link common things among the different things that I do, that way I never learn just isolated things, I gain generic skills that I can reuse in different situations and this is a way of abstracting something.

For example, music and programming aren’t directly linked sciences, but music is extremely linked to math, as well as programming. It means that at some point I can use the same skill to benefit from both specialties. And this is also a way to abstract something!

Abstraction is also an extremely powerful skill when we talk about communication. For example, when it’s necessary to translate something of a specific domain to people who are not aware of it, make a clear solution in a team with different skills levels or express themselves better in any situation.

Improving the ability to abstract

Nothing like practice to improve the knowledge on something, so I’ll suggest that you ask some questions to exercise your ability of abstract something in a positive way:

Can you explain something specific to your area of expertise to someone else in a simple way, without dealing with unnecessary details?
Could this explanation be understood by people with different levels of knowledge and skills?
In software development, are you able to understand how a business rule works and see different possibilities for turning it into a program, without delving into implementation details?

You can ask yourself the questions on a daily basis and get the results according to how easy it is to perform these tasks. Over time you’ll notice that this skill is really amazing and it will become something more and more natural.

So we come to the end. Today I tried to bring a little of my vision on how it can be interesting to report skills of different areas of knowledge with programming and vice versa.

So, what did you think? Send me comments about your experiences with this subject, feedbacks and suggestions!

See you next time!

Frameworks JS: Ame-os ou deixe-os

Thiago Moraes — Mon, 17 Aug 2020 13:54:13 +0000

Salve pessoal, como estão todos vocês? Bem, eu espero.

Hoje vou tratar de um assunto que gera bastante polêmica na comunidade JS:

Frameworks... usar ou não usar, eis a questão.

Introdução

Pra quem não sabe do que se trata o termo, em poucas palavras, pode-se dizer que um framework é uma solução escrita para resolver um problema genérico. É comumente também relacionado à libraries (bibliotecas), uma vez que um framework pode ser também uma library ou um conjunto delas.

No universo Javascript, há uma infinidade dessas funcionalidades genéricas (há rumores que nascem mais frameworks JS por dia do que bebês na China), em sua maior parte de código open source, criadas pela própria comunidade. E há também muita discussão sobre usar ou não esses códigos de terceiros. Esse artigo será divido em duas partes, na primeira vou abordar alguns prós e contras sobre o assunto e na segunda vou trazer um exemplo prático sobre alguns pontos citados.

Qual a escolha certa?

A primeira coisa que gostaria de falar é que não existe "certo ou errado" quando se trata desse assunto, é muito mais uma questão de "necessidade e escolha". Sendo assim, é extremamente necessário saber qual problema estamos tentando resolver e em que situação para que seja possível escolher a solução mais adequada. Vou tentar listar alguns dos pontos que considero mais importantes nas duas abordagens.

Nota: Vale ressaltar que nada aqui escrito é uma regra absoluta, mas sim opiniões construídas de acordo com a minhas vivências e experiências e que podem variar de acordo com as experiências de cada um. Também é necessário entender que na maioria dos casos estamos falando sobre frameworks com uma certa relevância, com boas práticas, organização, testes e com bons padrões de qualidade.

Pontos fortes de utilizar frameworks:

É uma solução utilizada por uma vasta comunidade, consequentemente, há várias pessoas trabalhando em busca da resolução de um mesmo problema, o que traz uma visão coletiva e com diferentes pontos de vista.
É uma abstração mais simples para algo que pode não ser importante no contexto desejado. Por exemplo, não é necessário saber como funciona todas as engrenagens de um carro para aprender a dirigir e se locomover com mais facilidade.
Agilidade no desenvolvimento. Não é uma regra, mas geralmente é um ganho, uma vez que as abstrações diminuem o nível de complexidade de algumas soluções.

Pontos fracos de utilizar frameworks:

Customização. Como se trata de uma solução que visa resolver um tipo de problema específico, pode ser que em algum momento você tenha um caso que não se encaixe na mesma.
Bugs. Pode ser que uma atualização no framework ou uma mudança de versão gere um bug indesejado no seu código e você não tem controle do mesmo para corrigir.
Dependência. Algo muito comum é o desenvolvimento de um código estar completamente atrelado a um framework, criando uma relação de dependência total. Ou seja, se em algum momento o framework for descontinuado ou não tiver mais manutenção, isso pode ser gerar um grande problema.

Pontos fortes de não utilizar frameworks:

Maior controle sobre o código. Uma vez que você vai desenvolver tudo utilizando a tecnologia nativa, você tem total controle sobre tudo que foi construído.
Criação de soluções altamente customizáveis
Menos overload. Quanto menos módulos de terceiros sua aplicação tiver que carregar, ela será mais leve e terá um build mais eficiente.
Domínio maior da tecnologia nativa.

Pontos fracos de não utilizar frameworks:

Complexidade. Algumas vezes, pode ser complexo e até mesmo desnecessário criar uma solução do zero para todo o problema.
Padronização. Quando você trabalha em um time grande, dependendo da experiência do mesmo e do tamanho do projeto, pode ser difícil gerenciar o mesmo ao longo do tempo.
Tempo. Provavelmente você demandará mais tempo desenvolvendo algumas coisas que já estão "prontas".

Conclusão

Eu, particularmente, acho que os milhares de frameworks JS são uma das coisas mais legais do universo javascript! Me dá a sensação de estar trabalhando o tempo todo com gente do mundo inteiro, além de ter acesso a ótimas soluções que provavelmente eu não teria tempo e capacidade de desenvolver sozinho nem em uma vida inteira. Ainda assim, vez ou outra estou em alguma situação em que a melhor opção é não utilizar. Por exemplo, quando realmente não há um framework que atende totalmente a sua necessidade ou quando por questões de segurança, você opta por não transitar algumas informações sensíveis por libs de terceiros, ou ainda por não poder correr o risco de depender de uma lib externa, dentre outros.

Levando em consideração todos os prós e contras levantados para ambas as situações, percebe-se que não é uma simples questão de "bom ou ruim" ou "gostar ou não gostar", mas de fazer escolhas certas dentro de um determinado contexto. Sendo assim, a dica é fazer um balanço da situação que você se encontra e dos prós e contras de cada abordagem para chegar na melhor solução possível.

Próximos passos

Apesar de achar o uso dos frameworks super positivo em termos de produtividade, padronização, reuso, dentre outras vantagens, tem algo que vejo no dia-a-dia que considero um ponto negativo. Alguns desenvolvedores estão completamente orientados ao uso de frameworks, ao ponto de não saber como algumas coisas básicas da tecnologia funcionam. Algo que sempre defendo é o bom e velho "do the basics", conhecer bem os conceitos e principais nuances da linguagem ou tecnologia com a qual você trabalha. Então, como citei no início, na parte 2 desse artigo vou trazer um exemplo prático bem legal sobre esse tema, abordando uma das soluções mais usadas em Node JS.

Por enquanto, é isso. E vocês, o que acham sobre o uso dos frameworks? Deixem suas opiniões, comentários e feedbacks nos comentários.

Um grande abraço, que a força esteja com todos vocês!

Open Source, Helm e Javascript

Thiago Moraes — Thu, 09 Jul 2020 11:49:58 +0000

Salve terraqueos, tudo em ordem?

Atrasei um pouco o artigo dessa semana, mas foi por uma boa causa. Além de estar trabalhando bastante, ando passando por um momento de grandes revoluções pessoais e vou falar um pouco sobre isso também hoje. O artigo será divido em duas partes, a primeira onde vou falar um pouco sobre alguns acontecimentos e mudanças de atitude e a segunda com um exemplo prático bem legal!

Open-Source

Eu sempre fui declaradamente apaixonado por Open Source. Pra quem não é familiarizado com o termo, este é um modelo colaborativo de desenvolvimento, que permite a livre consulta, modificação e distribuição do código-fonte de um software sem a necessidade de pagar por uma licença comercial. Eu acho incrível o poder que uma comunidade com um interesse comum possui de construir coisas realmente grandiosas. E assim como eu sempre me beneficiei de tudo que é oferecido gratuitamente, também sempre tive uma grande vontade contribuir para que outras pessoas sintam o mesmo. E aí entra uma questão bastante comum: Como eu posso contribuir com a comunidade? Vou tentar abordar um pouco sobre o assunto em cima de algumas experiências recentes.

Eu sempre fui muito perfeccionista (no sentido ruim mesmo), onde eu acho que nada nunca tá perfeito e se não tiver perfeito não serve. E esse "perfeito" muitas vezes nunca chega. Eu também sempre gostei de fazer muita coisa ao mesmo tempo e essas duas características em conjunto, fizeram com que eu tivesse um certo bloqueio durante algum tempo. Eu estava sempre fazendo muitas coisas e nenhuma delas estava perfeita o suficiente, logo, não serviam.

Iniciando a revolução

A primeira coisa que fiz foi mudar meu mindset em relação a essas questões. Eu entendi que a perfeição que eu buscava era algo impossível e que eu precisava direcionar meu foco para terminar projetos de forma mais simples. Então eu comecei a planejar meu tempo de uma forma inteligente, colocando data e horário pra tudo que eu desejava fazer com antecedência. E a primeira coisa que eu decidi fazer na prática, foi começar a escrever aqui no dev.to, que também é uma forma de contribuir com a comunidade compartilhando conhecimento. Vale lembrar que existem diversas formas de contribuição, como escrever artigos, participar de talks, eventos, ajudar membros da comunidade e claro, escrevendo muito código! E assim, iniciei a fase dois do meu plano para dominar o mundo.

Hands-on

Bom, então vamos de hands-on! Eu sempre usei bastante nosso querido Github (a maior comunidade de código open-source do mundo), porém de uma forma muito pessoal, guardando projetos, templates, compartilhando com pessoas mais próximas e esse tipo de coisa. Então, o segundo passo após começar a escrever aqui, foi começar a contribuir também com projetos que possam ser relevantes para a comunidade. E como a primeira vez tem que ser especial (e dizem que a gente nunca essquece), decidi começar compartilhando algo relacionado a duas das minhas tecnologias favoritas: Javascript e Kubernetes <3.

O Kubernetes é uma ferramenta para orquestração e gerenciamento de containers extremamente poderosa. Quem trabalha com essa tecnologia provavelmente conhece o Helm, uma ferramenta para facilitar o gerenciamento de aplicações em Kubernetes. Em um projeto que ando trabalhando recentemente, surgiu a uma necessidade de utilizar o Helm, que é uma ferramenta CLI, através do NodeJS e foi assim que surgiu meu primeiro pacote publicado no NPM (O gerenciador de pacotes do NodeJS). E claro, o código é totalmente open-source e está disponível no Github!

Helm Wrapper

Eu criei um wrapper para o Helm, permitindo utilizar as funcionalidades da mesmo via Node JS. Criei as funcionalidades mais utilizadas (install, upgrade, uninstall, list, history, rollback), com possibilidade de passar todas as flags suportadas. E caso seja necessário utilizar alguma função não implementada, também criei uma função que permite receber um comando custom, sendo possível executar outros comandos (sem o mesmo padrão nas respostas dos métodos). Vou demonstrar de forma breve como utilizar (para mais detalhes, basta acessar o repositório):

Instalando o pacote:

const helm = require('./index');

Utilizando algumas funcionalidades:

/**
 * install a release
 */
helm.install('nginx', 'bitnami/nginx');

/**
 * install a release with flags
 */
helm.install('nginx', 'bitnami/nginx', ['-n stage']);

/**
 * upgrade a release
 */
helm.upgrade('nginx', 'bitnami/nginx');

/**
 * rollback a release
 */
helm.rollback('nginx', 1);

/**
 * list releases
 */
helm.list();

/**
 * list release history
 */
helm.history('nginx');

/**
 * uninstall release
 */
helm.uninstall('nginx');

/**
 * custom command
 */
helm.custom('help');

Inicialmente minha ideia era criar uma interface HTTP para o Helm. Porém, decidi criar um wrapper um pouco mais genérico, permitindo que qualquer um pudesse fazer sua própria implementação de API, ou qualquer outra desejada. Ainda preciso fazer uma documentação mais rica e escrever testes, mas como citei anteriormente, isso será um trabalho contínuo e conto com a ajuda de vocês pra isso também!

Seguindo a ideia inicial, também fiz minha própria implementação de API utilizando o wrapper, que acompanha também uma imagem Docker, permitindo rodar todo o ambiente necessário sem nenhuma dependência local! Mas esse é assunto que ficará para o próximo post!

Conclusão

Então por hoje é isso. Estou muito feliz pelo início dessa nova jornada e no próximo artigo vou abordar a minha implementação de API utilizando o wrapper e também falar um pouco sobre alguns tópicos importantes para quem também deseja embarcar no fantástico mundo do open-source. Sendo assim, me contem o que acharam, suas experiências e contribuições com código open-source, principais dúvidas, sugestões e o que mais quiserem.

Espero que todos estejam bem, até a próxima e grande abraço!

O poder da Abstração

Thiago Moraes — Mon, 29 Jun 2020 10:39:42 +0000

Primeiramente gostaria de agradecer a todos que leram e me mandaram feedbacks e sugestões no meu post de boas vindas, isso é muito importante para que eu possa seguir em frente!

Hoje vou falar sobre um assunto muito presente no nosso dia-a-dia e que é de certa forma um paradoxo, pois ao mesmo tempo que tem como uma de suas principais características simplificar algo, é também algo extremamente complexo. Vamos falar sobre abstração.

O que é abstração?

Eu diria que as vezes é difícil até começar a tentar explicar de uma forma fácil o que significa esse termo, uma vez que o conceito também é (ironicamente) algo abstrato. Vamos começar trazendo o significado da palavra em duas diferentes abordagens:

Em filosofia:

Abstração é uma operação intelectual que consiste em isolar, por exemplo num conceito, um elemento à exclusão de outros, dos quais então se faz abstração. Por exemplo, abstraindo uma bola de futebol de couro, por uma bola de futebol, retemos apenas a informação enxuta das propriedades e comportamentos de uma bola de futebol. (Wikipedia)

Em ciência da computação:

Abstração é a habilidade de concentrar nos aspectos essenciais de um contexto qualquer, ignorando características menos importantes ou acidentais. Em modelagem orientada a objetos, uma classe é uma abstração de entidades existentes no domínio do sistema de software. (Wikipedia)

De maneira bem simplificada, eu diria que a abstração é uma forma de trazer algo que tem uma certa profundidade e/ou complexidade para uma camada mais simples e de fácil acesso, ou seja, o que realmente importa dentro de um determinado contexto.

Quando você está acessando um website, você está preocupado somente em digitar algo na barra de endereços do seu navegador e que a página solicitada apareça para que você possa acessar o conteúdo,não é algo importante nesse momento o caminho que sua requisição faz, a tradução desse endereço para algo lógico, empacotar e desempacotar pacotes TCP, roteadores, serviços de DNS, servidores externos, processamento de dados, etc. Isso pode nos dizer que o browser pode ser encarado como uma abstração do seu acesso a web.

Por que é importante e como utilizar

No meu dia-a-dia como Software Engineer, estou o tempo todo falando, estudando e tratando sobre assuntos extremamente técnicos, relacionados a desenvolvimento de software. Porém, eu sempre tento linkar pontos em comum dentre as diferentes coisas que eu faço, dessa forma eu nunca aprendo apenas algo isolado, ganho habilidades genéricas que posso reaproveitar em diferentes situações e isso é uma forma de abstrair algo.
Por exemplo, música e programação não são ciências diretamente ligadas (não estou falando que não possam se relacionar ou sobre softwares que utilizam música como foco, etc), mas música é extremamente ligada à matemática, assim como programação. Isso significa que em algum momento eu posso utilizar uma mesma habilidade para me beneficiar em ambas as especialidades. E isso também é uma forma de abstrair algo!

A abstração também é uma habilidade extremamente poderosa no que diz respeito à comunicação. Por exemplo, quando é necessário traduzir algo de um domínio específico para uma pessoa que não tem conhecimento sobre o mesmo, tornar uma solução clara em um time com diferentes níveis de habilidades ou se expressar melhor em qualquer situação.

Aprimorando a capacidade abstrair

Nada como a prática para aprimorar o conhecimento em algo, vou sugerir então que você faça alguns questionamentos para exercitar sua capacidade de abstrair algo de forma positiva:

Você consegue explicar algo de conhecimento específico da sua área de atuação para outra pessoa de forma simples, sem tratar sobre detalhes desnecessários?
Essa explicação poderia ser entendida por pessoas com diferentes níveis de conhecimentos e habilidades?
Em desenvolvimento de software, você é capaz de entender o funcionamento de uma regra de negócio e enxergar diferentes possibilidades para transformá-la em um programa, sem se aprofundar em detalhes de implementação?

Você pode fazer essas perguntas diariamente a si mesmo e colher os resultados de acordo com a facilidade que você tem em realizar essas tarefas. Com o tempo você vai notar que essa habilidade é realmente incrível e vai se tornar algo cada vez mais natural!

E assim chegamos ao fim. Tentei trazer hoje um pouco da minha visão sobre como pode ser interessante relacionar habilidades de diferentes áreas de conhecimento com a programação e vice versa.

Então, o que vocês acharam? Coloquem aqui nos comentários suas experiências com o assunto, além de feedbacks e sugestões!

Grande abraço e até a próxima.

Hello World!

Thiago Moraes — Mon, 22 Jun 2020 10:52:50 +0000

Olá pessoal, tudo bem?

No post de hoje não vou falar sobre um tema específico, mas sim fazer uma breve introdução sobre quem sou eu e quais meus objetivos escrevendo aqui na comunidade.

Meu nome é Thiago, atualmente sou Software Engineer e Tech Lead na Pontaltech, uma empresa que trabalha com comunicação digital e está entre os maiores brokers de SMS do Brasil, além de oferecer diversas outras soluções como Whatsapp, Bots, Ura, etc. Estamos em crescimento constante e contratando também!

Há muito tempo tenho vontade de começar a escrever sobre tecnologia para compartilhar o conhecimento que acumulei durante meus anos de desenvolvimento e também para aprender, pois acredito que contribuir e ensinar é uma excelente forma de fazer isso (inclusive, aprender a escrever esse tipo de conteúdo). Porém, com as rotinas frenéticas, com trabalho, estudos diários, compromissos, lazer e milhares de outras coisas, comumente ouvimos e falamos: “falta tempo”. Na maioria das vezes essa expressão é falha, pois geralmente o que falta é “organizar as prioridades”. E foi assim que tomei a iniciativa de iniciar essa série de conteúdos, organizando minhas prioridades.

Existem duas ramificações principais de habilidades em desenvolvimento: as hard skills (conhecimento técnico, sobre linguagens, tecnologias, etc) e as soft skills (aspectos comportamentais, como comunicação, liderança, gestão, etc). Vou falar brevemente sobre duas soft skills para explicar sobre como fiz pra começar a escrever e como pretendo construir o conteúdo.

Estamos no meio de uma pandemia terrível que está afetando o mundo inteiro, mudando a forma como nos comunicamos, trabalhamos e trazendo também um momento de grande reflexão. Em meio a tudo isso, eu tive mais tempo para organizar minhas ideias, traçar objetivos e colocar tudo isso em prática. E isso está relacionado com a primeira habilidade que queria apresentar, que é sobre olhar para o lado positivo das coisas e tentar extrair o que há de melhor mesmo nos piores momentos. Isso pode ser útil não só para manter uma mente saudável e positiva, mas também para manter o foco e encontrar soluções para situações difíceis.

A segunda habilidade também tento aplicar em tudo que faço, principalmente para coisas que são novas: seja simples. Acredito que simplificar as coisas é uma arte (extremamente difícil) e nos dá a capacidade de fazer coisas cada vez mais complexas com clareza (vou me aprofundar nesse assunto em tópicos futuros). O que pretendo fazer a princípio é exatamente isso, criar um conteúdo simples, breve, de fácil leitura e em um intervalo semanal, tempo que considero razoável para conseguir me organizar.

Bom, o artigo já está ficando um pouco longo para uma introdução, então vou encerrar por aqui. Eu espero contar com a participação dos leitores para sugestão de tópicos, temas e também fiquem a vontade para mandar seus feedbacks, para que eu possa melhorar cada vez mais o conteúdo. Também tenho a ideia de fazer alguns vídeos tutoriais, live coding e coisas relacionadas, mas isso é assunto para posts futuros.

Sendo assim, me enviem comentários falando sobre o que vocês acharam, sugestões de temas, interesses, feedbacks e o que mais desejarem!

Então é isso, espero que estejam todos bem, fiquem seguros e até a próxima!