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 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!

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!