Até que ponto automatizar tudo no desenvolvimento de software é interessante para o time de desenvolvimento?

Automatização de processo de desenvolvimento de software

Hoje mesmo recebi na newsletter do Medium com o título “Auto-Unsubscribing in Angular Components Like a Pro” e é obvio que eu fui correndo ler, mas depois de ler o artigo, me vieram algumas coisas na cabeça que eu quero compartilhar com vocês.

Dica

Aliás, se você não conhece o Medium eu recomendo que dê uma passadinha por lá. Tem artigo de tudo quanto que é coisa, você tem um limite de leitura e ele te joga uma mensagem dizendo “Você lê bastante Leo, para continuar lendo esse artigo manda uns pila pra cá”, não necessariamente com essas palavras… e também não para todos os artigos. Mas o que conta é que tem muito conteúdo de qualidade por lá e as newsletters fazem o papel. Diariamente recebo bastante emails do site, mas não chega a me incomodar, porque 99% deles tem algo de útil ou do meu interesse.

Feito o jabá gratuito para o Medium, vamos voltar ao assunto…

Até que ponto automatizar tudo no desenvolvimento de software é interessante para o time de desenvolvimento?

“TUDO” é uma palavra muito forte, mas tenho certeza que vocês vão acompanhar o meu raciocínio.

Quando eu iniciei no mundo do desenvolvimento de software e tinha uma aproximação maior da linguagem de desenvolvimento PHP havia uma grande vulnerabilidade que era a configuração de register_globals vir ativada por padrão nas configurações do PHP.

Isso ajudava muito no processo do desenvolvimento porque a gente não precisava ficar associando as variáveis que circundavam o ambiente ($_POST, $_GET, $_SESSION, etc). Se você recebia “bonitamente” o valor do formulário em $_POST['meu_campo'] era só você acessar a variável $meu_campo e seguir em frente.

Tudo certo até aí, né?! Mais ou menos, porque o PHP tem tipagem fraca e a gente pode simplesmente acessar essa mesma variável direto pela URL assim: http://meusiteinseguro.com/carrinho_de_compras.php?meu_campo=codigo_nocivo e dessa forma injetariamos o que quiséssemos na variável.

Depois disso, eu – muito espertalhão – comecei a usar a função extract() para extrair as variáveis dos mesmos arrays comentados anteriormente mas configurava o register_globals como off. Ora-ora espertalhão não mudou NADA… 🙂

O tempo passou, o PHP começou a trazer a register_globals configurada com off por padrão e eu comecei a carregar as minhas classes com o método mágico __autoload(), afinal de contas eram “mágicos”!

O que era uma mão-na-roda, mas talvez eu estivesse ganhando um pouco de tempo na importação das libs, mas perdendo o controle da minha aplicação.

Porque é interessante automatizar?

Não quero, de forma alguma, desmerecer a utilidade dessas opções e muito menos o PHP que eu curto muito, entretanto, quero ressaltar que eu as utilizava de uma forma um tanto quanto ingênua e egoísta (só pensava no meu tempo de desenvolvimento), então, é importante sim a automatização, isso que nem estou falando aqui a parte de DEVOPs que na minha época era só INFRA 🙂

Aproveitando a introdução com PHP, não vejo utilidade para register_globals estar ativada, mas a __autoload, hoje descontinuada, tinha seu valor. Eu a usava de forma adequada para carregar os módulos da minha aplicação quando desenvolvia meus próprios frameworks em MVC para meus projetos (quem faz isso hoje em dia né? Loucura…)

Não sou contra automatizações, mas acredito que a gente sempre tem que avaliar coisas como essa com bons olhos e isso eu vou escrever na próxima seção.

Porque não é interessante automatizar?

Seja pela introdução das minhas experiências passadas com PHP que comentei anteriormente ou pelo conteúdo do artigo do Medium mencionado, que aliás é um bait a artigo e sim, é um baita serviço que o cara desenvolveu por lá.

A questão aqui é que você provavelmente não desenvolve software sozinho e se prefere assim, tente desenvolver com um time, a experiência e o teu crescimento pessoal e profissional é incrível. Mas mesmo que desenvolva sozinho, se você ficar um mês sem ver o código, sem dúvidas quando vê-lo novamente vais ser um completo estranho e ainda se horrorizar com as gambiarras que o “Eu do passado” fez ou se impressionar com o código maravilhoso que esse mesmo cara fez…

As questões que me chamaram a atenção e me motivaram a escrever esse post foram duas:

  1. Automatizar pode te trazer problemas de segurança
  2. Automatizar pode te prejudicar no debug quando tu interfere no fluxo da aplicação

1. Automatizar pode te trazer problemas de segurança

Na minha opinião, ter regras claras e bem definidas com o time todo são melhores do que apenas a automatização da aplicação, DEVOP ou fluxo da aplicação.

É claro que qualquer automatização em qualquer nível vai ajudar muito no processo de desenvolvimento, mas além de normalmente dar um baita trabalho, deixa tudo ali prontinho para alguém, muitas vezes bem intencionado, fazer uma grande besteira em algum momento, mesmo sem querer.

Para complementar eu não preciso citar ainda as minhas peripécias na introdução desse texto, certo?

2. Automatizar pode te prejudicar no debug quando tu interfere no fluxo da aplicação

Essa seção tem total relação com o post do colega. Lá ele mostra como fazer para você automatizar o unsubscribe de um observer. Oberver é um padrão de projeto (design pattern) comportamental onde nós precisamos nos inscrever (subscribe) nele e assim ficar recebendo atualizações quando o objeto observer mudar de estado. Acontece que quando a gente está inscrito em um observer, o fluxo de dados está aberto e consumindo recursos da aplicação, portanto, seja por motivo de segurança ou performance é altamente recomendado que nós fechamos essa inscrição depois de executar o que a gente precisa, caso contrário fica ali aberto. É meio parecido com aquela conexão de banco de dados que eu e você “nunca” deixou aberta eternamente lá no MySQL, saca? 🙂

Mas isso é super interessante, não é? Automatizar esse processo burocrático é algo impressionante e “like a pro” como citado no título do artigo. Sim, pode ser pensado como algo fenomenal, mas não e isso que está em questão. O que me chamou a atenção é na dificuldade de troubleshooting na hora de debugar esse código, já que algo tão importante, como o fluxo da aplicação foi doutrinado pela automatização (forte isso hehehe).

Mas aí você pode me dizer que: “poots, mas é fácil resolver, afinal de contas eu fiz o código para automatizar a parada toda”.
E eu posso te responder que: “Toda a automatização nos leva à ignorar a questão automatizada e com isso esquece-la, além disso, o seu time para ser um time, necessariamente precisa de mais pessoas além de você que possam não ter o conhecimento desse código ninja like a boss que você fez. Mas o pior ainda é interferir no fluxo da aplicação…”

Resumindo

A automatização no desenvolvimento de software é importante quando bem definida, divulgada e estruturada.
Interferir no fluxo da aplicação pode trazer grandes problemas para soluções de problemas.
Acredito fortemente que apesar de nos preocupar com o tempo e conforto no desenvolvimento das nossas aplicações, não devemos priorizar esses fatores em detrimento da segurança, troubleshooting facilitado e do bom fluxo da aplicação.

É isso aí pessoas.
Comentem suas experiências e o que você acha disso… só não vale me xingar pelas peripécias com o PHP, eu estava começando e vocês também já erraram na vida que eu sei… heheheh

Grande abraço!

Como fazer favicon, splash screen e ícones de forma fácil e rápida?

Se você está criando um aplicativo, seja ele nativo ou uma PWA, certamente você já se deparou com a missão de fazer os ícones, tela de inicio e o famigerado favicon da aplicação.

Convenhamos que é uma tarefa um pouco chata de realizar, por que são muitas resoluções e formatos

Mas felizmente, vamos aprender aqui como a gente pode agilizar esse processo de forma indolor 🙂

Pré-requisitos

Antes de tudo você precisa ter a arte do seu ícone e a sua splash screen prontinhos e para que tudo fique certinho precisamos ficar atentos á essas regras:

Ícone

  • Pode ter background transparente
  • Tamanho de 1024 x 1024 px
  • PNG

Splash screen

  • Não pode ter fundo transparente
  • Tamanho de 4096 x 4096 px
  • Centralizar as informações importantes *

    * É importante centralizar porque a ferramenta não é “bala de prata” e não consegue manter as proporções corretas para todos os dispositivos, então ela centraliza o conteúdo e preenche com um background. Para um MVP resolve, mas se você vai usar em produção, eu aconselho a editar as imagens que ficarem “estranhas”.

Gerando os arquivos

Vamos usar a ferramenta Ape Tools através do link https://apetools.webprofusion.com/

No primeiro campo (Step 1) a gente precisa inserir o ícone no formato PNG e grandão mesmo…
e no segundo campo (Step 2) a gente insere a splash screen, também grandona.

Depois de inserir os arquivos, vai aparecer um botão “Kapow!” logo abaixo, clique sem medo. Se você quiser ver a prévia das imagens marque a caixa de seleção “Show previews”.

Agora você pode ainda escolher as plataformas que você quer trabalhar. Caso seja uma PWA, tem ferramentas melhores que geram inclusive o manifest.json e uma index.html com as tags necessárias, mas se precisar só das imagens a Ape Tools vai te ajudar.

Para fazer as imagens conforme as configurações dessas plataformas, basta clicar em “Include in bundle”.

O resultado de tudo isso é um arquivo .zip com todas as imagens necessárias.

Se você está usando em uma PWA, você ainda precisa criar o arquivo manifest.json e colocar algumas tags na sua index.html.

Mas, se o seu app é nativo, basta seguir as instruções que o próprio Ape Tools informa, dependendo da versão que você vai usar.

E aí, essa informação te ajudou?

Compartilha aí com teus amigos pra ver se ajuda eles também. Se não gostou, compartilha com os inimigos hiuahuiahuiah

E comenta aí se tu conheces uma forma melhor.

Grande abraço!

Onde encontrar datasets com dados brasileiros?

Muitos dados entrando em um computador

E aí galera! Tudo certo? Espero que sim!

Recentemente fiquei muito frustrado em não poder atingir um objetivo pessoal e profissional por não ter dados suficientes para treinar um modelo de inteligência artificial.

Esse projeto era muito importante porque estava totalmente e acordo com a minha atual filosofia de vida que é fazer com que as micro e pequenas empresas brasileiras perseverem e não se encerrem junto com os sonhos dos seus idealizadores.

Analisando os relatórios do censo das empresas brasileiras proposto pelo SEBRAE, pude observar que as micro e pequenas empresas tem uma grande representatividade na economia do país e isso é muito importante.

Muita gente sonha em ter um emprego em uma multinacional ou em trabalhar em uma empresa gigante. Ok! Isso é muito válido, mas os dados nos dizem que no final das contas, a maior representatividade na economia brasileira é dos pequenos empresários que lutam dia-a-dia deslealmente com palitos de dentes em punho contra gigantes com tanques de guerra.

E por esse motivo, tenho uma missão de empoderar esses guerreiros com ferramentas de acesso a informação e educação. É por esse motivo que sou sócio da ConnectBe Contabilidade Proativa, um escritório de contabilidade bem diferente e que tem uma proposta bem bacana para esse público.

Mas como empoderar esses empresários?

Você já ouviu falar que os “dados são o novo petróleo”, correto?

Os dados são o novo petróleo

Eu também acredito nisso e é dessa forma que pretendo realizar esse feito. Muitos empresários simplesmente seguem contato com a sorte e simplesmente administrando o seu negócio apenas com o feeling as vezes acreditando no que está fazendo e outras vezes torcendo para dar certo. Isso é muito ruim para a saúde do negócio (e do empreendedor também heheh)

Como a inteligência artificial pode ajudar?

A inteligência artificial não é nenhuma novidade nem algo de outro mundo, na verdade as pesquisas iniciais datam da década de 50 e sendo bem sucinto, trata-se apenas da interpretação matemática de dados através de estatística, gerando informação para solucionar alguma necessidade de negócio.

Mesmo sendo um estudo consideravelmente antigo, em um determinado tempo, além de falta de investimento e assuntos filosóficos, chegou-se a conclusão de que não haveriam dados suficientes para que os modelos propostos fossem treinados adequadamente. Esse período é conhecido como o inverno da inteligência artificial.

Entretanto, já faz um tempo em que vivemos em um mundo cheio de dados, na verdade que mede dados, porque eles sempre existiram, apenas nunca foram mensurados. Hoje, a sua geladeira pode te fornecer dados importantes sobre a sua alimentação, o seu carro sobre o seu consumo e até os brinquedos dos seus filhos podem te trazer alguma informação útil. Esse fenômeno é conhecido como big data, onde temos muitos dados disponíveis para fazermos coisas incríveis.

Beleza e os dados?

Os dados são a alma do negócio e toda essa introdução foi para compartilhar com vocês a necessidade que eles tem para todos nós, especificamente, para mim e nesse projeto, para os micro e pequenos empresários brasileiros.

Agora pare para pensar que se para fazer um bom treinamento de um modelo preditivo a gente precisa de milhões de exemplos e isso muitas vezes não é tão fácil nem para as gigantes do mercado, imagina como que eu vou fazer isso para o dono da padaria do bairro?

Essa foi a minha frustração, de certa forma quem está no “inverno da IA” agora, sou eu! Justamente por que esse mercado não gera dados suficientes para que eu coloque meus modelos em produção de forma confiável.

Tenho certeza que muita gente que trabalha com IA compartilha dos mesmos anseios, mas como encontrar datasets com informações importantes para darmos o primeiro passo?

Como encontrar os datasets?

No post anterior eu compartilhei uma busca de datasets oeferecida pelo Google, mas dando uma olhada no GitHub hoje, vi que meu amigo começou a seguir um repositório interessante e fui ver o que era.
Aí que a mágica aconteceu! Era um repositório do Felipe Deschamps com a iniciativa de criar um repositório com dados sobre o Brasil e tornar uma API aberta. Olha que maravilha!

Inicialmente ele está propondo a elaboração de uma API para CEP, para contornar um “problema” técnico na API atual dos Correios.

Mas a ideia do projeto é maravilinda e pretende abordar outros aspectos.

A comunidade inclusive já está adicionando várias dicas além de contribuir para o projeto, alias, foi dentro de uma das issues que eu encontrei também esses dois links https://brasil.io/home e https://catalogo.conecta.gov.br/store/apis/list fornecidos pela comunidade que dão uma mão na roda para treinarmos nossos modelos e resolver grandes problemas.

Você tem alguma experiência desse tipo para compartilhar com a gente?

Comenta aí em baixo pra gente trocar uma ideia.

Google disponibilizou mais de 25 milhões de datasets gratuitos

Tela de busca de datasets gratuitos do Google

Há muitos anos tivemos o apagão da inteligência artificial pela escassez de dados. Haviam os algoritmos, mas poucos dados para o treinamento dos modelos propostos. O tempo passou, desenvolvemos novos sensores e os incluímos em tudo (com IoT por exemplo), assim passando a gerar muitos dados em qualquer coisa que antes nem sequer pensávamos que poderia nos dar alguma ideia importante, como uma geladeira por exemplo que pode monitorar os produtos dentro dela e fazer as compras de forma automática para você.

De fato, vivemos em uma época maravilhosa de BIG DATA, entretanto, dados qualificados não fazem parte do cotidiano da vida de pequenas e médias empresas. Falo isso com propriedade porque possuo uma startup de contabilidade que atua com inteligência artificial para micro, pequenos e médios empresários e mesmo com um bom movimento em seus empreendimentos ainda não geram dados suficientes para um treinamento de um modelo de inteligência artificial.

Existem diversas outras possibilidades de uso e aplicação, mas de fato, datasets específicos e qualificados são ouro na mão da gente. Se vierem “limpos” melhor ainda.

Mas afinal o que são datasets

Se você chegou até aqui e ainda está meio perdido, datasets são conjuntos de dados, estruturados ou não, sobre assuntos específicos.

Para aplicação e treinamento de modelos de inteligência artificial, é necessária uma massa de dados consideravelmente grande para que você consiga os resultados esperados e quem tem esse dados para você validar seu modelo são os datasets.

Não desdenhe dos datasets, você só sabe o quanto são necessários quando precisar deles hehehe

Talk is cheap, show me the “code”

Não é um “code”, mas a citação é boa heheh

Você pode acessar os datasets através desse link https://datasetsearch.research.google.com/ e pasmem: é como se fosse uma busca do Google.

Explore a vontade! Busque o dataset pelo assunto que tens interesse, avalie as fontes, autor, licença e leia a descrição para saber de fato o que contém e divirta-se!

Muito obrigado por ler esse artigo e diga aí se você testou os datasets e como foi a sua experiência! Vai ser legal compartilharmos conhecimento.

Grande abraço e vamos fazer coisas incríveis!

Fonte

Essa dica foi passada pelo Miguel Neves que foi meu colega no MBA sobre Inteligência Artificial aqui na PUCRS. Valeu Miguel!!!

Link passado pelo Miguel https://towardsdatascience.com/google-just-published-25-million-free-datasets-d83940e24284

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 a Amazon define um novo produto?

Caminho errado volte!

Ei, você que tem uma ideia na gaveta ou trabalha com o desenvolvimento de um novo produto na sua empresa. Como você faz para tirar isso do papel? Que framework você utiliza? Ou simplesmente lança e vê no que dá?

Há quem faça questionários com o cliente, há quem só olhe para os stakeholders do projeto e também há quem apenas acredite que teve uma ótima ideia e isso basta para garantir o sucesso do seu projeto.

Na vida real não deveria ser bem assim. Muitas vezes as empresas empregam muito tempo e dinheiro em projetos que seus clientes não precisam de fato ou que não resolvem um problema e isso não significa que seu produto é ruim ou foi mal feito, e sim que talvez o seu cliente não precisava dele.

Existem diversos frameworks e metodologias que resolvem esse problema com abordagens diferentes, mas hoje eu vou te mostrar uma abordagem bem legal que eu nunca usei, mas pretendo aborda-la em breve aqui na empresa. O nome dessa técnica é Working Backward e essa é a forma que a Amazon desenvolve seus produtos.

Working Backward

Essa forma de desenvolvimento de produto é totalmente integrada ao consumidor final e parte do fim para o princípio. Entenda como funciona.

Press release

O primeiro passo é você escrever um anúncio do produto final e destinado ao público-alvo que vai utilizar o produto, isso mesmo, você escreve um artigo como se o seu produto já existisse e estivesse sendo noticiado pela imprensa. Pense em todos os detalhes e realmente pense como a imprensa noticiaria o seu produto. Escreva em um papel e tire várias cópias, você vai precisar delas na próxima etapa.

Reunião

Com a notícia em mãos junte a sua galera, de preferência que tenham skills e backgrounds bem diversificados, dê à eles o seu papel com a notícia do seu novo produto e prepare-se para as “pedradas.”

Pedradas

Naturalmente as pedradas virão. Esse pode ser um momento frustrante, mas é a parte mais interessante do processo. É aqui que você vai identificar as principais oportunidades e problemas do seu novo produto. Mas não leve nada para o pessoal, esse é o trabalho que a sua galera tem que fazer. Sempre com o foco no cliente.

Resultados

Se você sobreviveu a enxurrada de feedbacks da etapa anterior, agora é a hora de extrair os resultados desse processo. Provavelmente, surgiram diversos aspectos que podem fazer com que o seu produto tenha que ser modificado para potencializar os resultados ou o impacto no cliente, normalmente algo que você não pensou, mas aquele colega que teve um caminho diferente do seu na vida, conseguiu pensar por você.

Durante esse processo, você consegue perceber com mais clareza todas as etapas do processo de desenvolvimento e já pode aproveitar para gerar pequenos pacotes de entregas (baby steps) e depois disso é mão na massa!

Como implementar na sua empresa

Uma boa abordagem é a utilização de templates para a criação dos press releases. Mas vale lembrar que o importante é ser fiel ao lançamento de um produto destinado ao publico-alvo, seja ele interno ou externo.

Começando pelo press release, basicamente, você precisa descrever a sua solução e apresenta-la par o seu público de forma clara e simples, entendível pelo público-alvo. Você pode ver como estruturar um press release nesse link https://rockcontent.com/blog/press-release/

Feito isso, chame o pessoal e deixe eles lerem o conteúdo por 15 minutos, depois é a hora dos feedbacks.

Durante o retorno dos feedbacks, tire dúvidas, ajuste features e remova features desnecessárias.

O que aprendemos com isso?

No processo de criação de um produto muitas vezes a gente acha que teve uma brilhante ideia e que ninguém nunca pensou nisso. Quantas vezes você já pensou “poots, como ninguém fez isso ainda?”. Talvez tenham feito de uma forma errada ou num tempo errado, ou talvez não tenha o fit correto com o público alvo estabelecido, enfim, são “N” fatores.

Acho que o principal aprendizado é que nós desenvolvemos produtos para os clientes não pra nós, portanto, a dica é não se apegar a solução que você criou e sim ao problema que você resolve.

O foco no cliente, além de garantir o sucesso do produto também garante que você erre menos, se frustre menos e no final das contas perca menos dinheiro com esse processo.

E você, como desenvolve os produtos da sua empresa? Em quem você pensa primeiro? Comente aí em baixo como você faz para criar coisas incríveis!

Fonte:

https://www.product-frameworks.com/Amazon-Product-Management.html

https://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management?ref=http://www.product-frameworks.com/

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?

Fallback CSS e JS para jQuery

Tela com os erros de carregamento do site do Materialize

E aí pessoas, tudo certo?

Se você achou esse post pelo Google, dificilmente você não sabe o que é fallback, mas para quem chegou aqui de outra forma, aí vai. Fallback é o termo que usamos para mitigar a falta de algum arquivo. Por exemplo, se você está usando um arquivo em um CDN e por algum motivo esse arquivo não exista mais ou esteja com algum problema de acesso, nós testamos se alguma função desse arquivo funciona, se ela retornar um erro, a gente carrega esse arquivo localmente para que a experiência do usuário não seja afetada, afinal de contas ele não tem nada a ver com isso, certo?

Por que eu faria isso?

Mas aí você pode estar se perguntando: por que diabos eu me preocuparia com isso se eu já uso CDN, que de certa forma garante que tudo funcione sempre para mim? Ora, respondo eu mesmo: eu já fui estou “bloqueado” por CORS pelo jQuery por testar aplicações com o CDN em localhost. Isso faz com que eu não consiga usar os recursos que dependem de jQuery em sites que não tenham fallback. Um exemplo de site é o do Materialize, eu simplesmente não consigo acessar os menus (collapse). Mas felizmente uso IP dinâmico e assim que eu conseguir fazer com que alguém na operadora de internet entenda o que eu estou falando, eu trocarei o IP de borda.

Observe as mensagens de erro no console.

Tela com os erros de carregamento do site do Materialize
Captura de tela com erros de carregamento do Materialize

Failed to load resource: the server responded with a status of 403 (Forbidden)
jquery-3.2.1.min.js:1 Failed to load resource: the server responded with a status of 404 ()
jquery.timeago.min.js:1 Uncaught ReferenceError: jQuery is not defined
at jquery.timeago.min.js:1
at jquery.timeago.min.js:1
search.js:396 Uncaught ReferenceError: jQuery is not defined
at search.js:396
init.js:259 Uncaught ReferenceError: jQuery is not defined
at init.js:259

Fallback para Javascript

Para fazer com o que o seu usuário tenha a mesma experiência, garanta que ele consiga acessar o arquivo do seu próprio servidor, caso o CDN falhe.

Para o javascript fazemos isso testando alguma funcionalidade que só o arquivo js em questão contenha.

Coloque esse código antes da tag </body>.

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.4.1/jquery.min.js"></script>
<script>  window.jQuery || document.write('<script src="/content/js/libs/jquery-1.7.1.min.js"><\/script>')</script>

Observe que na primeira linha tentamos carregar o arquivo normalmente no CDN e na segunda linha testamos se a função window.jQuery existe, caso não exista a gente carrega o arquivo local. Obviamente, você precisa ter o arquivo salvo no seu servidor.

E o CSS?

Geralmente ocorre o mesmo com o CSS, mas como aplicar essa mesma lógica para o CSS, se ele é só uma folha de estilos?

.invisible {
       display: none;
}

Para fazer isso, nós vamos criar uma div invisível e verificar se ela realmente está invisível por exemplo.

Dentro do arquivo CSS que a gente quer testar, a gente deixa a div invisível

Depois, colocamos o elemento que vai nos ajudar a testar a funcionalidade no body da pagina

<div class="invisible"></div>

Por fim a gente usa uma função em Javascript / jQuery para verificar se o CSS definido no arquivo foi aplicado.

<script>
    // CSS Fallback
    $(function () {
        if ($('.invisible:first').is(':visible') === true) {
            $('<link rel="stylesheet" type="text/css" href="/assets/css/jquery.css" />').appendTo('head');
        }
    });
</script>

A lógica é a mesma, se o CSS não foi aplicado talvez o arquivo não foi carregado, então nós mesmos carregamos ele do nosso servidor local.

Conclusão

Basicamente a lógica é a mesma tanto para javascript quanto para CSS, a diferença é como fazer o teste. Fique atento que para testar o CSS você precisa do javascript e não necessariamente do jQuery, mas já que você já o carregou para outra tarefa, não custa usá-lo.

Vale lembrar também que essa lógica pode ser usada para qualquer arquivo, não apenas para o jQuery.

Referências

Mas por que ter esse trabalho se eu posso usar direto do meu sistema de aquivos e garantir a experiência do usuário da mesma forma?

Tem a ver com performance, cache e otimização de recursos do seu servidor. Falarei mais sobre isso em posts de performance, SEO e CDN em breve.

Espero ter ajudado! Grande abraço!