Aqui na Resultados Digitais nós temos alguns scripts que os clientes colocam em suas páginas para enviar alguma informação ao RD Station. Nós atualizamos esses scripts frequentemente, e para manter nosso fluxo de desenvolvimento ágil, automatizamos o processo de deploy desses scripts. Já existe, aqui no Ship It!, um post dedicado a explicar o funcionamento desse deploy automatizado de scripts. Em suma, utilizamos o Grunt para executar as tarefas abaixo com apenas um comando.
Aqui na Resultados Digitais damos muita atenção à qualidade do produto. Essa atenção se reflete, por exemplo, no uso de testes automatizados. Além dos testes de unidade e integração, os testes de aceitação merecem cuidado para evitar problemas de evolução e manutenção da suíte de testes.
Este artigo levanta alguns pontos sobre a arquitetura e boas práticas desse nível de testes.
Continuando com os nossos problemas enfrentados com o ElasticSearch, neste post irei mostrar como um mapeamento não planejado corretamente pode dar uma grande dor de cabeça. Caso você não tenha lido o primeiro post desta série leia aqui.
O cliente entra no site, se depara com uma lista de produtos, olha para os destaques com 4 produtos lado a lado, fica 10 segundos na página e então fecha a janela e parte para o concorrente. Nestes meros 10 segundos, o cérebro desse cliente processou diversas sensações relacionadas ao que ele realmente queria e como as informações dos produtos foram apresentadas.
Como é grande a variedade de opções para se comprar on-line, expor preços e produtos não é uma tarefa simples, na verdade é bem complexa e desafiadora. Pequenos detalhes na interface e um pouco de psicologia melhoram a experiência de compra e instigam o interessado a, efetivamente, tornar-se cliente.
Estudos na área apresentam pontos a serem considerados na hora de mostrar preços e produtos. A seguir, mostrarei aqueles que mais chamaram a minha atenção. Além disso, relacionarei como essas técnicas estão ligadas ao nosso dia a dia de trabalho com o RD Station.
No mês de setembro estivemos na RubyConf Brasil 2015, e um dos assuntos que atraiu a atenção de quem passou pela trilha de Workshops 3 foi o nosso processo de desenvolvimento e entrega de software: o deploy via chat.
Na Resultados Digitais usamos o (Slack) para diversas atividades: coordenar os diversos times; sincronizar e auxiliar o trabalho do time de Suporte, Customer Success e Vendas; discutir novas funcionalidades e auxiliar os membros que estão trabalhando remotamente a terem o mesmo fluxo de comunicação que o pessoal do escritório.
Através do chat também conseguimos controlar diversas funcionalidades de operação, como receber alertas de serviços, realizar deploys em staging e produção alinhados com integração contínua. Isso permite que todos os interessados saibam o que está acontecendo de forma transparente e efetiva.
Durante a vida longa de uma suite de testes, alguns problemas comuns podem começar a surgir e atrapalhar o processo de desenvolvimento do software. Por exemplo, testes que levam uma eternidade para serem executados e o surgimento de diversos falsos positivos (exemplos de testes que falham, porém a funcionalidade testada está funcionando corretamente). Boa parte desses problemas é decorrente do uso excessivo de testes integrados, onde toda a stack da aplicação é executada para testar uma parte pequena do sistema. Essa stack poderia muito bem ser simulada utilizando mocks/stubs.
Estudando sobre tipos de testes e as fronteiras de comunicação entre objetos, me deparei com os testes de contrato e de colaboração. A princípio, eles podem parecer muito simples, porém podem proporcionar um maior conforto ao trabalhar com mocks/stubs em seus exemplos de teste.