Como resolver no Angular: ERROR Error: Uncaught (in promise): ReferenceError: Buffer is not defined

Se você está utilizando o Angular e trabalhando com Buffer, certamente você já se deparou com esse erro em seu console.

core.js:6014 ERROR Error: Uncaught (in promise): ReferenceError: Buffer is not defined
ReferenceError: Buffer is not defined

Esse erro significa que o seu Angular não conhece a implementação de Buffer. Mas como resolver isso?

Como resolver: Buffer is not defined?

Para solucionar esse problema, você precisa instalar o pacote do Node.js Buffer via npm ou yarn

npm install --save buffer

Depois disso, vamos configurar “adicionar” a funcionalidade no objeto window para que ele funcione no Angular da mesma forma que funciona no Node.js.

Para isso, vamos alterar o arquivo polyfills.ts:

import * as buffer from 'buffer';

(window as any).Buffer = buffer;

Pronto!

Dica:

Se você não quiser utiliza-lo como se fosse “nativo”, apenas importe normalmente no seu componente, dessa forma:

import { Buffer} from 'buffer';

Dica 2:

Isso não acontece só no Angular. Você pode usar essa dica para trabalhar com scripts em páginas da web ou em algum projeto que usa Typescript, assim como o Angular.

E aí, funcionou para você? Conta aí embaixo quais as outras formas você resolveria essa situação?

Abração e até a próxima!

Como organizar meu aplicativo Angular

Organização

É natural que projetos comecem pequenos e naturalmente se expandam ao longo do tempo e se tornem algo monstruoso, principalmente se você estiver fazendo um monolito ou um espaguetão bem doido. Não te culpo, quem nunca fez isso?

O problema é que dependendo da dimensão que o projeto tomar com o passar do tempo e com o aumento do seu time você pode ter criado um grande problema para todo mundo, pois, na bagunça generalizada que ele vai se tornar, você perde velocidade, agilidade e consequentemente escalabilidade.

Imagine a situação: você tem 3 devs desenvolvendo 3 features diferentes, mas você está em meio a um caos no seu projeto, sem padrão qualquer todo mundo está editando o arquivo app.module.ts. Tranquilo, afinal cada um está trabalhando na sua branch e está tudo certo. Tudo certo até você ter que fazer o merge dessa bagunça e resolver os conflitos que não precisavam existir se o projeto estivesse organizado 🙂

Mas como organizar?

Uma sugestão é dividir as responsabilidades como nesse exemplo:

|-- modules

    |-- module1
        |-- [+] components
        |-- module1.service.ts
        |-- module1.module.ts
        |-- module1.routes.ts

    |-- module2 
        |-- [+] components
        |-- module2.service.ts
        |-- module2.module.ts
        |-- module2.routes.ts

|-- shared
        |-- [+] components
        |-- [+] mocks
        |-- [+] models
        |-- [+] directives
        |-- [+] pipes

|-- core
        |-- [+] authentication
        |-- [+] footer
        |-- [+] guards
        |-- [+] http
        |-- [+] interceptors
        |-- [+] mocks
        |-- [+] services
        |-- [+] header

|-- app.module.ts
|-- app.component.ts

Dessa forma o seu projeto está com cada domínio separado, devidamente modularizado com seus componentes, módulos, rotas, guards, services e etc.

Eu em particular gosto de trocar o diretório “Modules” por “Features” e isso é a prova que não existe uma regra, você faz a sua! Essa é apenas uma sugestão de organização proposta pelo próprio Angular e alguns outros figurões como John Papa por exemplo.

O diretório core contém tudo que for necessário para a sua aplicação funcionar, como os componentes principais do seu template, serviços de autenticação e o que mais for necessário.

Enquanto o diretório shared é responsável por guardar os componentes, pipes, diretivas, etc que serão compartilhados com os outros componentes. A única regra pra entrar nesse diretório é não pertencer a nenhum componente, apenas ser usado por eles 🙂

Mas me diz aí como você estrutura o seu projeto? Tem alguma ideia melhor pra compartilhar conosco?
Já teve que reestruturar um projeto no meio do caminho ou ficou com o custo tão elevado de manutenção que inviabilizou a continuidade de um projeto?

Comenta aí que vai ser legal a gente conversar sobre isso 🙂

Fonte

https://johnpapa.net/angular-app-structuring-guidelines/

https://johnpapa.net/angular-growth-structure/

https://medium.com/@motcowley/angular-folder-structure-d1809be95542

https://itnext.io/choosing-a-highly-scalable-folder-structure-in-angular-d987de65ec7

Como hospedar seu app sem servidor?

Serverless

Como assim sem servidor? No seu dia-a-dia você vai ver que é isso mesmo, mas na real, nada mudou 🙂

Você já ouviu falar sobre serverless ou FaaS? Então é sobre isso que temos que conversar.

Serverless em tradução livre do inglês seria como “sem servidor”, de fato, o conceito é esse mas também não é bem assim. Na verdade a utilização de uma “arquitetura” serveless apenas “abstrai” a camada de infraestrutura de forma que você não precise se preocupar com isso.

Isso significa que podemos desenvolver um código na nossa máquina e simplesmente dar um deploy para algum player do mercado sem sequer configurar um docker, roteamento, alta disponibilidade, camadas de segurança, etc. Apenas desenvolva seu código e digite no terminal “plataforma_que_eu_escolhi deploy” e pronto! Olha que maravilha!

Tá mas e o FaaS? Essa é a sigla que utilizamos para definir Function As A Service, que pode ser considerado sinônimo de serverless. Os puristas por favor não me xinguem.

Beleza, então meu código tá viajando por aí e eu nem sei onde está? Mais ou menos.

Na verdade, o seu código está em um – ou mais – servidor(es) sim! A jogada aqui é que você não precisa se preocupar com isso, essa é a expertise do player que te fornece o serviço, você não precisa mais ficar dimensionando máquina virtual e configurando o ambiente.

Mas então é uma maravilha só! Vou usar para tudo. Calma! Não é bem assim. Veja abaixo as vantagens, desvantagens e quando usar.

Vantagens

  • Deploy muito prático
  • Setup muito rápido (muito mesmo)
  • Economia de tempo e dor de cabeça com infraestrutura
  • Não importa a quantidade de requisições, o seu serviço não vai “estrangular”

Desvantagens

  • O report de consumo geralmente não é muito claro (normalmente o serviço é cobrado por consumo)
  • Se você não tiver um “stop”, você pode gastar muito dinheiro, inclusive com um bug no código por exemplo
  • É bom que o seu código esteja bem otimizado
  • Não é legal usar para toda e qualquer coisa

Quando usar?

Já tentei usar essa solução de várias formas, certas e erradas (mais erradas do que certas hehe) até encontrar o caminho correto. Não tente subir uma API completa no Firebase Functions por exemplo, não é uma boa solução, não é bom para a sua aplicação e menos ainda para o seu bolso.

As functions são ótimos recursos para hospedar códigos que precisam ser chamados sob demanda para resolver um domínio da aplicação, algo que precise ser chamado, faça o que tenha que fazer e depois termine.

Um exemplo bacana seria: ao fazer o upload de um arquivo de imagem, o usuário envia uma imagem gigantesca para a aplicação, então você chama a sua função hospedada em uma arquitetura serverless e executa toda a otimização dessa imagem para depois armazena-la no bucket e com isso economiza, espaço em disco e grana no bolso, além de garantir o seu padrão da imagem, dimensões, tipo de arquivo, filtro, etc.

Outra aplicação legal é com a utilização de microserviços ao invés de um monolito. Mas isso é um papo para outra jarra de café.

Principais players

E aí, já se animou para testar essa infra? Praticamente todos os players que eu citei te fornecem uma conta gratuita onde você pode se divertir e testar suas aplicações. A experiência é maravilhosa, vai lá!

Em breve eu solto outro post pra te ajudar a fazer isso 😉

Clique em Serverless – Subindo meu código sem servidor (se o título ao lado não estiver com um link, significa que eu ainda não escrevi o post 🙂 )

Obrigado por ter me aturado até aqui e um grande abraço à todos!

Não esqueçam: vamos fazer coisas incríveis!

5 fatos que provam que serverless não é tão caro assim

Gráfico que exibe as vantagens de utilizado serverless em relação ao método tradicional

Se o título atraiu você provavelmente você está familiarizado com o termo serverless, mas para introduzir a galera que caiu de paraquedas por aqui, serverless é uma arquitetura na qual nós “não precisamos” de servidores para hospedar nossos códigos. Nós simplesmente escrevemos os nossos códigos, escolhemos um player do mercado e colocamos o código lá. Depois é só chama-lo e tá feito! Você pode entender melhor sobre serverless nesse artigo que eu escrevi aqui no blog: Como hospedar seu app sem servidor?

Feita a introdução, vamos ao objetivo!

Calcular a execução de uma função na arquitetura serverless pode ser uma tarefa extremamente difícil, isso porque os principais players do mercado estruturaram seu modelo de negócios baseado em tempo de execução dessa função, o que é extremamente justo, mas o valor “pode” ser salgado dependendo de várias variantes.

1 – Tempo de execução

Partindo dessa premissa, você como programador, precisa garantir que o código vai perder menos tempo possível, afinal de contas, mais do que nunca o termo “time is money” se aplica nesse caso.

Muitas tecnologias podem ser adotadas por aqui, algumas bem simples como a utilização de um try/catch na chamada de suas funções ou simplesmente usando uma linguagem de programação compilada como o Go, que faria seu código rodar mais rápido, consumir menos recursos e consequentemente gastar menos dinheiro.

Além das técnicas já citadas não podemos esquecer da utilização do paradigma de desenvolvimento funcional para as linguagens que suportam esse tipo de desenvolvimento com certeza é um ponto para observarmos. Em Javascript por exemplo existe um ganho considerável apenas utilizando as abstrações existentes como map, filter e reduce. Além disso, são essas técnicas que propiciam que softwares de análise de big data como o Apache Hadoop funcionem.

2. Infraestrutra

Não só de máquinas e cabos são feitas as estruturas de uma organização, seja essa estrutura on promisses (instalada localmente na sua empresa) ou na nuvem (cloud computing) precisa de um time para orquestrar todos aqueles servidores que você suou para pagar ou para convencer sua diretoria a pagar.

Por mais que ainda vejamos muitos casos em que empresas ainda utilizem infraestrutura de datacenter local, seja por regras governamentais, seja por necessidade de disponibilidade imediata (altíssima latência), softwares não projetados para escalar em nuvem, ou qualquer outro motivo (eu poderia passar horas por aqui hehe), já sabemos que essa prática é tem um peso muito grande a ser carregado. Máquinas depreciam, tem um custo elevado e normalmente tem capacidade ociosa.

Em se tratando de máquinas, imagine que você tem um software hospedado em nuvem pública em uma máquina virtual. Você tem todos as buzz words de tecnologias configuradas no melhor player do mercado com alta performance e redundância configurados num nível nunca visto antes. Você se sente super feliz com isso! Eu também me sentiria. Entretanto, mesmo que podendo adicionar memória, processamento e disco quando lhe der vontade ou quando a máquina precisar, você não pode adicionar apenas hipotéticos 123 Mhz de processamento, você tem uma quantidade pré-definida pelo seu serviço de hospedagem na qual é possível adicionar, sem contar os reboots que seriam necessários, você certamente está perdendo dinheiro com capacidade ociosa, mesmo que pouca, você está perdendo dinheiro.

Com a utilização de serverless, a sua função é chamada, ele faz o que tem que fazer em um tempo X e te devolve o resultado. Pronto! Usou? Pagou pelo que usou.

Tenho uma longa carreira na área de infraestrutura e sempre foi um desafio propor para a direção o aumento da capacidade computacional do datacenter, isso porque normalmente era visto exatamente dessa forma que eu estou colocando aqui: desperdício de recursos financeiros (apesar de ser cobrado quando a coisa parava heheh) e como exemplo posso citar também a capacidade ociosa que existe, principalmente em estruturas on promisses com máquinas físicas, onde você tem uma máquina que suporta 100 usuários, sua empresa cresce e você tem 110 usuário, você não consegue comprar uma máquina que suporte 10 usuários (e também não faria sentido não ter margens de crescimento nesse paradigma), talvez, você precisará comprar outra(s) máquina(s) que suportem 100 usuários e pagar esse spread ocioso de recursos.

3. Pessoas, mais especificamente: DEVOPs

Não é uma caça as bruxas, nem a extinção desse profissional, muito pelo contrário. Esses caras sempre foram extremamente importantes e são ainda mais hoje em dia.

A questão aqui é que mesmo utilizando tudo em nuvem, se você não tem conhecimento suficiente para orquestrar o ambiente onde roda a sua aplicação, você vai ter que contratar alguém para fazer isso por você, justo! Mas porque ter esse custo e ainda ter todos os custos de ociosidade que eu comentei ali em cima se eu posso não ter?

Cabe ressaltar que dependendo do nível e do tamanho da aplicação é extremamente importante que você estruture e a mantenha com um DEVOP, mesmo utilizando serverless.

4. Performance

Imagine você que em um dia extremamente atípico o seu e-commerce, principal canal de vendas do seu negócio, teve, ao invés dos 5 mil acessos diários, 1 milhão de acessos que repercutiu em vendas e visibilidade para o seu negócio. A sua infraestrutura sem serverless, on promisses ou na nuvem, suportaria essa demanda sem quebrar? Sem ficar lenta ou indisponível? Ora, responde eu mesmo: provavelmente não!

Com o serverless, você com certeza vai pagar por essa demanda (e bastante), mas o seu usuário não será impactado por qualquer um desses fatores, já que estamos falando de players como Amazon Lambda, Microsoft Azure Functions e Google Cloud Functions por exemplo. Acho que temos bastante capacidade computacional com esses caras, certo?

5. Planos gratuitos

Pensando como uma startup todo o centavo é muito importante e se conseguimos economizá-los, isso se reverte em café em cima da mesa, café se transforma e código-fonte e por aí vai…

Brincadeiras à parte, a maioria dos players, grandes ou não, oferecem planos gratuitos, claro que com suas limitações, mas certamente atende as suas demandas de teste, MVP e lançamento do seu produto.

Conclusão

Serverless ainda é caro, complexo de ser medido e provisionado (valores monetários), mas assim como vários outros aspectos da sua startup, precisa ser analisado com atenção, principalmente aos fatores indiretos ligados a sua implementação. Também é necessário ficar atento à operação continuada e entender o momento certo de migração, caso necessário. Isso pode ser um fator muito importante dentro da sua organização.

Eu uso serverless como premissa da minha estrutura e você?

Gostou do artigo? Consegui agregar valor para você? Se sim, indique para um amigo para que ele também fique esperto no assunto.

Obrigado por vir até aqui.

Vamos fazer coisas incríveis hoje?

Capitã Marvel causando nostalgia em desenvolvedores

E aí galerinha do café, tudo tranquilo?

O desenvolvimento web que conhecemos hoje tem um passado nebuloso… hehehe

Hoje em dia temos muita gente nova que provavelmente nem ouviu falar em MIcrosoft Frontpage (eca!), já que na época em que ele “resolvia” alguns problemas, a maioria do pessoal estava nascendo…

Na época, mesmo com uma baita ascensão da internet, programadores web eram vistos com desdenho por programadores desktop, que era o que mais havia. A frase mais comum era “PHP não é linguagem, é tecnologia”, “ASP é gambiarra”, “HTML só formata”, “progama em C que nem gente grande”, etc…

Fato é que a gente não dava muita bola (mesmo eu já programando em C também nessa época heheh) e desenvolvíamos coisas “incríveis” para os sites da escola, da turma, do condomínio, da família e para tudo o que mais poderia haver, sempre com muitos códigos copiados e alterados de diversos tutoriais e upados com o velho FTP.

Recentemente,  iria fazer um comparativo de sites que eu fazia na época para os que rola hoje (a diferença é enorme!!!) para uma talk que fiz na trilha Inspire do TDC, mas a Marvel resolveu isso pra mim. Como o filme da Capitã Marvel rola nos anos 90, eles fizeram o site oficial bem do jeitinho – horrível – que a gente fazia na época. Isso deu uma baita nostalgia!

Confere lá: https://www.marvel.com/captainmarvel/

A web melhorou não é? hehehe

Valeu, grande abraço!

Compactação GZIP com Node.js

Introdução

Em tempos de servidores compartilhados onde cada recurso utilizado dói no bolso no final do mês, é muito importante compactar arquivos, seja para servi-los e economizar na transferência, seja para armazenar em disco. Existem algumas alternativas, uma delas é o Brotli, um projeto do Google que eu escrevi aqui, outra que também é suportada pela maioria dos navegadores é o GZIP e para isso existe uma ferramenta muito tranquila de implementar e que também pode ser utilizada no shell.

Solução

A ferramenta em questão é o Gzipme mantida por Caio Ribeiro Pereira sob licença MIT.

Implementação

No diretório do seu projeto, instale o pacote com o npm.

npm install gzipme
import gzipme from 'gzipme'

// Comprime "file.txt" para "file.txt.gz" no mesmo diretório.
gzipme("file.txt");

// Comprime "file.txt" e sobrescreve o arquivo "file.txt" no mesmo diretório
gzipme("file.txt", true);

// Comprime "file.txt" com o nome "compressed.txt" no mesmo diretório
gzipme("file.txt", "compressed.txt");

// Comprime "file.txt" usando o modo de "melhor" compressão (arquivo menor mas a compressão é lenta).
gzipme("file.txt", false, "best");

// Comprime "file.txt" usando o modo "rápido" de compressão (arquivo maior mas compressão rápida)
gzipme("file.txt", false, "fast");

Para usar  no shell do seu sistema operacional, basta instalar em modo global.

npm install -g gzipme

Os comandos são bem semelhantes às funções.

# O mesmo que 'gzipme("file.txt")'.
gzipme file.txt
# O mesmo que 'gzipme("file.txt", true)'.
gzipme -o file.txt
# O mesmo que 'gzipme("file.txt", "compressed.txt")'.
gzipme -O compressed.txt file.txt
# O mesmo que 'gzipme("file.txt", false, "best")'.
gzipme -c best file.txt
# O mesmo que 'gzipme("file.txt", false, "fast")'.
gzipme -c fast file.txt

É isso aí! Tente aplicar esse conhecimento conforme o seu projeto necessita 🙂

 

Grande abraço!

Compactando arquivos para a web com Brotli

Introdução

O assunto compactação normalmente é tratado na hora do deploy da aplicação, seja observando os relatórios de performance, como por exemplo o LigthHouse em caso de PWA ou seja simplesmente acessando o aplicativo e percebendo que ele está muito, as vezes muitooooo lento.

Fato é que esse assunto é o que envolve o maior número de engenheiros em empresas de desenvolvimento maiores e os navegadores já estão aptos à ajudar a resolver o problema e se não tiver, usa o GZIP mesmo.

 

A solução proposta aqui é o Brotli, um projeto Google que faz a compactação para você ter menos dores de cabeça com performance 🙂

Para usa-lo, utilize o gerenciador de pacotes do seu sistema operacional, eu estou usando um Ubuntu 16.04 LTS.

sudo apt-get install brotli

No caso de uma aplicação Angular, crie um arquivo no chamado Makefile no mesmo nível de onde está o seu package.json, copie o código abaixo e altere o que for necessário para adequar ao seu projeto.

build:
    ng build --prod --aot`

compress: 
    find dist -type f -exec sh -c "gzip < {} > {}.gz" \;
    find dist -type f -not -name "*.gz" -exec sh -c "bro --input {} --output {}.br" \;

Agora, executando os comandos make build no terminal, gera os arquivos de produção do Angular e o comando make compress gera os arquivos em GZIP e em BR (Brotli) compactados.

Não se preocupe que o seu servidor (Ngnx, Apache, etc) saberá o que fazer com eles 😀

Esse assunto sempre dá ibope, conte as suas experiências na seção de comentários…

 

Grande abraço!

Live preview no Visual Studio Code

E aí galerinha do café, tranquilasso?

Hoje em dia, existem diversas ferramentas para auxiliar o nosso trabalho, principalmente com o front-end, na verdade acho que é a área mais “frenética” no momento em que escreve esse post (Set/2017). Fato é que além de frameworks, precisamos também de uma boa IDE, porque só maluco vai de VI, VIM ou Notepad 😀

Por muito tempo eu usei o Brackets pura e simplesmente porque ele tem a função de live preview, que é aquela função espetacular em que altera o arquivo no navegador na medida em que tu estás editando e com isso o desenvolvimento fica muitooo³ mais rápido e talvez até com mais qualidade.

Hoje em dia, ando tendo uma relação de paixão pelo Visual Studio Code da Microsoft, que apesar de ser Microsoft, é gratuíto e funciona em Mac e Linux também.

Esse editor tem uma interface bacana, te ajuda com debug e tem um terminal integrado, na verdade ele usa o terminal da sua máquina dentro da IDE, de qualquer forma, é uma mão na roda!

 

Hoje eu estava com o Brackets aberto e o Visual Studio Code também, quando me deparei, pera aí, deve ter alguma extensão de Live preview para esse cara e aí eu uno o útil ao agradável (pra mim, pelo menos).

Eis que então achei a extensão “Live HTML Previewer“, que está disponível aqui.

Para instalar é bem tranquilo. Lógico que tu precisas ter instalado antes o Visual Studio Code e para isso, basta seguir as instruções no site deles.

Depois de instalado o VS, pressione CTRL + P e digite o seguinte comando:

ext install live-html-previewer

Escolha a extensão na lista e clique em install.

Recarregue o Visual Studio Code

Pronto!

Para usar em uma aba no Visual Studio Code, pressione F1 ou CTRL + Q + S e digite:

Show side preview

Para usar em “tela cheia”, CTRL + Q + F ou pressione F1 e digite:

Show full preview

E, por fim, no navegador, CTRL + Q + W,

ou F1 e digite:

Open in browser

ou clique com o botão direito do mouse no editor e selecione

Open in browser

 

Feito!

Espero que tenham gostado.

Grande abraço!

 

Double screen – Comercial do Banco Sicredi

Screenshot de campanha de Natal do Banco Sicredi

E aí gurizada do café! Sussa?

Vocês víram? No Natal do ano passado, 2016, o Banco Sicredi inovou junto com a empresa DZ Estúdio e fizeram uma publicidade em “double screen”, isto é, ao entrar no endereço http://juntospelonatal.com.br/ no desktop e http://natal.am no celular, posicionar o dispositivo à direita do desktop, inserir o código fornecido, confirmar a execussão nos dos devices e curtir um show de inteligência, competência e criatividade.

Na minha experiência não ficou totalmente sincronizado, mas vamos e venhamos, alem do meu celular ser uma “lesma”, isso é bem complicadinho de sincronizar.

No passado empresas como a Samsung, se não me engano já usou essa técnica também com muita inteligência e também foi um sucesso, pelo menos no meu mundo nerd hehe

Confere lá, antes que saia do ar (eu não tiraria nunca…) pq eu estou atrasado e o bom velhinho já passou faz tempo… hehe

Tecniquês

Se você quer usar essa técnica, estude Javascript, HTML e alguma linguagem de servidor (PHP por exemplo). Se houver uma demanda legal, eu faço um tutorial.

Grande abraço!

Esse post foi escrito ao som de Pretinho Básico (Rádio Atlântida) e ao sabor de um bom café orgânico moído na hora e coadinho na xícara (sempre sem açúcar e bem forte 😉 #fikdik)

Como forçar a versão do PHP no .htaccess

E aí galerinha do café, tranquilo?!

Em tempos de mudança da versão do PHP, as vezes precisamos forçar a versão antiga ou garantir que o servidor, nesse caso apenas o Apache, tenha instalado a versão mais nova, tanto faz, o procedimento é o mesmo.

Por isso, hoje trouxe para vocês esse artigo rapidão para mostrar como fazemos para forçar determinada versão do PHP direto no .htaccess.

Primeiramente, verifique na raiz do seu projeto ou no diretório em que você deseja determinar essa configuração, se já existe o arquivo .htaccess, caso contrário, crie-o.

Insira nele as seguintes linhas:

AddHandler Application/x-httpd-php55 .php

Prontinho, basta alterar a versão do php que você precisa em php55.

 

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