O paradigma de Orientação a Objetos é um dos mais populares dentro do desenvolvimento de software. Dentre os conceitos aplicados existem alguns que são considerados os pilares do paradigma, sendo eles: Abstração, Encapsulamento, Herança e Polimorfismo. Porém além dos pilares um outro conceito importante é o do reuso de código, onde determinado trecho de código pode ser reaproveitado por várias classes afim de evitar codificação duplicada dentro do software. E quando se fala de reuso, a Herança pode ser a primeira técnica que vem a cabeça, porém nem sempre ela é a mais indicada e ao invés de solucionar um problema pode acabar gerando inúmeros outros a medida que o software cresce.

Este é o segundo post da série que irá falar sobre JavaScript. No post anterior eu apresentei um contexto histórico do surgimento da linguagem e como ela evoluiu até agora.

Nesse post abordaremos a versão 6 da ECMAScript dando alguns exemplos do que mudou e o que chegou de novo. Se você está em dúvida sobre o histórico da versão 6, não deixe de ler o post anterior da série.

O desenvolvimento de software sempre modificou-se dinamicamente ao decorrer do tempo. Novos paradigmas de programação foram criados, novos tipos de linguagem, metodologias e processos. A arquitetura dos sistemas também não poderia ficar fora, começando com uma arquitetura monolítica, passando para uma arquitetura orientada a serviços (SOA), até a arquitetura com maior destaque no momento: microservices.

O aumento da utilização das arquiteturas baseadas em services e microservices fez com que um grave problema entrasse em foco: a quebra de contrato entre o provedor do serviço e o cliente.

Neste terceiro e último post da série de dicas de Design Orientado a Objetos com Ruby, fecharei a série com algumas dicas relacionadas a como melhorar a comunicação entre suas classes deixando mais claras suas interfaces públicas.

Se você ainda não leu na parte 1 expliquei como tornar as classes mais coesas e na parte 2 como torná-las menos acopladas.

Se existe uma coisa que não falta hoje em dia é aplicativo de gestão de tarefas. Existem apps para todos os gostos e adaptados para todos os tipos de metodologias de trabalho e produtividade. Em minha saga por achar um bom app para gestão das tarefas pessoais, eu testei muitos, como Wunderlist, Remember the Milk, Todoist, Asana, Trello, Reminders da Apple e até papel e caneta.

Quando escrevi meu post de estréia aqui no Ship It!, no longíquo Agosto de 2015, eu disse que se pudésse dar só uma dica sobre o futuro, seria essa: “Use TDD”. De lá pra cá, entre o preço do Dólar e o futuro político do país muitas coisas mudaram, mas não mudou a minha certeza de que essa é a dica de ouro no mundo do desenvolvimento de software. E quando digo TDD estou me referindo, é claro, a Test Driven Development (Desenvolvimento Guiado por Testes), prática redescoberta e evangelizada por Kent Beck que você certamente já ouviu falar. Neste post, porém, eu quero falar sobre uma outra técnica que pode ajudar bastante a nos tornarmos desenvolvedores mais completos. Eu chamei esta técnica de Testes Depois do Deploy cuja sigla também é TDD.

Desenvolvedor que usa TDD saboreando um saboroso café