Atualizações do site

logo

Olá pessoal, já faz um tempinho que não postamos este tipo de boletim informativo. Mas com todas as coisas que aconteceram nestes últimos 2 anos infelizmente o MundoJS acabou ficando um pouco parado.

Bom, o plano é retomar as atividades aos poucos , demos uma olhada e o que a galera mais tem gostado é de dicas sobre os fundamentos do JS, então vamos começar por lá. Criar tutorais de como fazer as coisas e também focar talvez em vídeos.

Eu costumo a escrever no plural, mas na verdade voltou a ser uma equipe de uma pessoa. O que faz parte… kkkkkk

Como vocês devem ter visto o site ta com outra cara, isso porque, para os próximos meses

foco será:

  • Novos posts com tutorais
  • Focar na velocidade do site
  • Melhorar a performance e segurança do site
  • Aumentar o conteúdo em vídeo
  • Remover as coisas que ninguém, ou quase ninguém, está usando.

O que já fiz nos últimos dias

  1. Novo layout, muito mais leve.
  2. Removido a funcionalidade de push de notificações. Tinha apenas umas 30 pessoas usando ele.
  3. Atualizado o Site, plugins de segurança.
  4. Removido plugins de antigos que a atualização invalidou… Quebrou quase nada.. kkk
  5. Iniciado novas postagens

Por último o plano para o futuro é

  • Continuar postando
  • Criar vídeos
  • Melhorar a área de cursos
  • Criar enquetes e buscar mais gente para contribuir

Extreme Go Horse – Gambiarra é para os fracos

extreme-go-horse

Conheça a metodologia Extreme Go Horse (XGH) onde você não precisa perder tempo com padrões, pensamento, documentação ou qualquer bobagem que vai te fazer produzir código. Aqui você sempre programa 8 mil linhas de código por segundo e se você teve que parar para pensar em fazer uma gambiarra, você lento e não sabe o que ta fazendo… kkkkkk… Bom, chega de enrolar, veja a baixo como funciona

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única
opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você
conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão
resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá
implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um
script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema
vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na
APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework
implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o
que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a
não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será
feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e
sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é
coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a
qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta
de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente,
seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao
caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo
precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8).
Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se
começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da
moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo
sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá
salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo,
mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move
o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você
sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código
compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As
pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre
maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto
de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um
sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe
morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma
8.

Conheça SvelteJS, um framework Frontend JavaScript

O Svelte é um framework com uma nova maneira de desenvolver interfaces de usuário. Frameworks tradicionais como React e Vue fazem a maior parte do trabalho no browser, o Svelte realiza esse trabalha em uma etapa de compilação que acontece quando você constrói a sua aplicação.

Sem utilizar técnicas como virtualização do DOM, o Svelte escreve código que cirurgicamente atualiza o DOM quando o estado do seu app muda. A diferença crucial entre o Svelte e outros frameworks JavaScript é que o Svelte converte o seu app para JavaScript ideal em tempo de construção, ao invés de interpretar seu código em tempo de execução. Isso significa que você não terá que considerar custo de performance das abstrações do framework, e você não terá penalidades quando seu app carregar pela primeira vez.

Você pode escrever o seu aplicativo do zero utilizando o Svelte, ou pode adicioná-lo de forma incremental à uma base de código já existente. Você também pode utilizar componentes como pacotes independentes, que funcionam em qualquer lugar, sem a sobrecarga de dependências de um framework convencional.

Componentes

No Svelte, uma aplicação é composta de um ou mais componentes. Um componente é um bloco de código reutilizável que encapsula HTML, CSS e JavaScript juntos em um arquivo .svelte.

Por exemplo:

<script>
    let nome = "mundo";
</script>

<h1> Olá Mundo!</h1>

E podemos utilizar uma referência à variável nome, criada acima!

<h1>Olá {nome}!</h1>

E isso nos trará o resultado:

Olá mundo!

Também podemos armazenar caminhos de url e pastas de armazenamento em variáveis, e utilizá-las em atributos de nossos elementos HTML, como:

<script>
    let caminhoOrigem = "imagem/foto.png";
</script>

<img src={caminhoOrigem}>

E isso funcionará. Mas o Svelte nos trará uma mensagem:

A11y: <img> element should have an alt attribute

Quando estamos criando web apps, é importante ter certeza que ele será acessível para todos os usuários, e isso inclui pessoas com dificuldades de visão ou movimento, ou até mesmo pessoas com boa conexão à internet e com bom hardware. A acessibilidade é de extrema importância no desenvolvimento e o Svelte auxilia avisando-o se você não escreveu elementos de marcação acessíveis.

Nesse caso, teremos:
<img src={caminhoOrigem} alt="Seu texto acessível aqui.">

Você pode fazer o download do Svelte diretamente no site em um arquivo .zip ou utilizando o npm e npx:

npx degit sveltejs/template my-svelte-project

cd my-svelte-project

npm install

npm run dev

Você pode verificar a documentação em: https://svelte.dev/tutorial/basics

Gostou deste artigo? Comente abaixo!

Referência: https://svelte.dev/

Princípios do SOLID com TypeScript – SRP

Veja nesse artigo uma rápida introdução ao SOLID e um exemplo prático sobre o SRP (Principio da responsabilidade unica) utilizando TypeScript

Introdução

Fala galera tudo bem? Aproveitando que estamos iniciando uma serie de podcasts sobre os princípios do SOLID no nosso canal DEVSHOW.

  • O (OCP) Princípio Aberto-Fechado
  • L (LSP) Princípio da Substituição de Liskov
  • I (ISP) Princípio da Segregação da Interface
  • D (DIP) Princípio da inversão de dependência

Principio da Responsabilidade Única (SRP)

Esse é o primeiro principio e na minha opinião o mais simples e o mais importante, ele diz que uma classe deve ter apenas um motivo para mudar” ou sejadeve ter apenas uma responsabilidade. Caso a sua classe tenha mais de uma razão para mudar, ela está fazendo mais de uma coisa, logo quebrando esse principio.

import * as express from "express";
import * as bodyParser from "body-parser";
import * as nodemailer from "nodemailer";
import config from '../config/configs';


class App {

    public app: express.Application;

    constructor() {
        this.app = express();
        this.app.use(bodyParser.json());
        this.routes();
    }
    routes() {

        this.app.route("/").get((req, res) => {
            res.send({ 'result': 'version 0.0.2' })
        });

        this.app.route("/").post((req, res) => {
            const message = Object.assign({}, req.body);
            let result = this.sendMail(message.to, message.subject, message.message);
            res.status(200).json({ 'result': result })
        });
    }


    sendMail(to?: string, subject?: string, message?: string) {

        let mailOptions = {
            from: "",
            to: to,
            subject: subject,
            html: message
        };

        const transporter = nodemailer.createTransport({
            host: config.host,
            port: config.port,
            secure: false,
            auth: {
                user: config.user,
                pass: config.password
            },
            tls: { rejectUnauthorized: false }
        });

        transporter.sendMail(mailOptions, function (error, info) {
            if (error) {
                return error;
            } else {
                return "E-mail enviado com sucesso!";
            }
        });
    }
}

export default new App();
  • O método de envio de e-mail deveria estar em uma outra classe separada
import * as nodemailer from "nodemailer";
import config from './config/configs';

class Mail {

    sendMail(to?: string, subject?: string, message?: string) {

        let mailOptions = {
            from: "",
            to: to,
            subject: subject,
            html: message
        };

        const transporter = nodemailer.createTransport({
            host: config.host,
            port: config.port,
            secure: false,
            auth: {
                user: config.user,
                pass: config.password
            },
            tls: { rejectUnauthorized: false }
        });

        transporter.sendMail(mailOptions, function (error, info) {
            if (error) {
                return error;
            } else {
                return "E-mail enviado com sucesso!";
            }
        });
    }

}

export default new Mail;
import * as express from "express";

const indexRouter = express.Router();

indexRouter.route("/").get((req, res) => {
    res.send({ 'result': 'version 0.0.3' })
});

export default indexRouter;

emailRouter.ts

import * as express from "express";
import mail from "../mail";

const emailRouter = express.Router();

emailRouter.route("/").post((req, res) => {
    const message = Object.assign({}, req.body);
    let result = mail.sendMail(message.to, message.subject, message.message);
    res.status(200).json({ 're sult': result })
});

export default emailRouter;

E por fim atualizamos o arquivo app.ts com o seguinte trecho de código:

import * as express from "express";
import * as bodyParser from "body-parser";
import indexRouter from "../router/indexRouter";
import emailRouter from "../router/emailRouter";


class App {
    public app: express.Application;

    constructor() {
        this.app = express();
        this.app.use(bodyParser.json());
        this.routes();
    }
    routes() {     
        this.app.use("/", indexRouter);
        this.app.use("/", emailRouter);      
    }
}

export default new App();

Gostou deste artigo? Comente abaixo!

Referência: https://programadriano.medium.com/princ%C3%ADpios-do-solid-com-typescript-1e585c6eeb5e

Princípios do SOLID com TypeScript – OCP

Veja nesse artigo um exemplo prático do principio OCP — Princípio Aberto-Fechado

Introdução

Dando continuidade a minha série de artigos sobre os princípios do SOLID com TypeScript e aproveitando a liberação do episódio 2 do nosso podcast: DevShow #22 SOLID OCP. Hoje irei abordar o segundo principio do SOLID, OCP.

Image for post

enum TipoDeArquivo {
    pdf,
    excel
}


class Arquivos {
    Exportar(arquivo: TipoDeArquivo, data: any) {

        if (arquivo == TipoDeArquivo.excel) {
            // exportar data para excel
        }

        if (arquivo == TipoDeArquivo.pdf) {
            // exportar data para pdf
        }
    }
}
enum TipoDeArquivo {
    pdf,
    excel,
    word
}


class Arquivos {
    Exportar(arquivo: TipoDeArquivo, data: any) {

        if (arquivo == TipoDeArquivo.excel) {
            // exportar data para excel
        }

        if (arquivo == TipoDeArquivo.pdf) {
            // exportar data para pdf
        }

        if (arquivo == TipoDeArquivo.word) {
            // exportar data para word
        }

    }
}
abstract class Arquivos {
    Exportar(data: any) { }
}


class GerarExcel extends Arquivos {
    Exportar(data: any) {

    }
}

class GerarPDF extends Arquivos {
    Exportar(data: any) {

    }
}

class GerarWord extends Arquivos {
    Exportar(data: any) {

    }
}

Gostou deste artigo? Comente abaixo!

Referência: https://programadriano.medium.com/princ%C3%ADpios-do-solid-com-typescript-2c6a4911242d

Upload de arquivos com TypeScript + Node.js + Azure Storage

Veja nesse artigo como criar um projeto para upload de arquivo utilizando Node.js + TypeScript e Azure. A seguir você tem dois links demonstrando um passo a passo do upload para uma pasta até o envio para o Azure Storage e depois alguns vídeos demonstrando a construção de um middler.

Introdução do módulo

Node.js + TypeScript: Criação de um middler

TypeScript + Nodejs: Criação de middler para upload de arquivos

Testando o nosso projeto

Gostou deste artigo? Comente abaixo!

JWT — JSON Web Token / Vídeos

Veja nesse artigo como trabalhar com JWT

Recentemente eu liberei mais um módulo do meu curso: Criando API’s RESTful utilizando TypeScript, Node.js, mongoDB, nesse estou demonstrando como trabalhar com JWT. Caso tenha interesse em ver esse conteudo, segue alguns links abaixo:

Gostou deste artigo? Comente abaixo!

Referência: https://programadriano.medium.com/jwt-json-web-token-2039797ba126

(JWT) JSON Web Token

Conhecendo o (JWT) na teoria e na prática.

Introdução

Quando estamos trabalhando com API’s, nós precisamos pensar na segurança no momento no momento de trafegar os dados e principalmente no nível de permissão que cada usuário deverá ter. Existem muitas formas de se fazer isso, mas uma que vem se destacando a cada dia que se passa é o JWT (JSON Web Token), por ser muito seguro e fácil de se implementar. Nas próximas sessões, será abordado a sua teoria com alguns exemplos e no final iremos criar uma aplicação com Node.js para exemplificarmos melhor o seu funcionamento.

Bom, o JWT (JSON Web Token) é um sistema de transferência de dados que pode ser enviado via POST ou em um cabeçalho HTTP (header) de maneira “segura”, essa informação é assinada digitalmente por um algoritmo HMAC, ou um par de chaves pública/privada usando RSA. Podemos ver na imagem a baixo um cenário onde será requisitado um token através do Verbo HTTP POST, que irá devolver um token validado para que nas próximas requisições que utilizem os Verbos HTTP possam utilizar.

Publicando projeto Docker + Node.js + TypeScript + MongoDB No Azure

Veja nessa artigo alguns links sobre como publicar o seu projeto Node.js, TypeScript e MongoDB com Docker e Docker Compose no Azure

O próximo passo será acessar a sua conta do Azure. Caso ainda não tenha uma, você pode criar através do seguinte link: Crie sua conta Azure Grátis.

Benefícios Visual Studio Dev Essentials

A seguir você tem o exemplo do arquivo Docker Compose que eu irei utilizar para publicar o meu projeto no Azure:

version: "3"
services:
  api:
    image: tadrianonet/api-ts
    ports:
      - "80:3050"
    links:
      - link-db
  link-db:
    image: tutum/mongodb
    ports:
      - "27017:27017"
      - "28017:28017"
    environment:
      - AUTH=no

Deploy no Azure Web Apps for Containers

Testando aplicação na Nuvem

Bom galera, com isso liberamos mais um módulo sobre Docker do Curso “Criando API’s RESTful utilizando TypeScript, Node.js, mongoDB”.

Espero que gostem e até um próximo artigo pessoal 😉

Referências: https://programadriano.medium.com/publicando-projeto-docker-node-js-typescript-mongodb-no-azure-608d8fa54246

 

Trabalhando com Docker + Node.js + TypeScript + MongoDB

Veja nessa artigo alguns links sobre como trabalhar com Docker e o Docker Compose em um projeto desenvolvido com Node.js, TypeScript e MongoDB

Abaixo vocês tem os links do módulo como trabalhar com Docker do meu Curso Criando API’s RESTful utilizando TypeScript, Node.js, mongoDB

Espero que tenham gostado e até um próximo artigo pessoal 🙂

Referência: https://medium.com/typescript/trabalhando-com-docker-node-js-typescript-mongodb-a341d42e1fc0