Alterando mensagens de commits anteriores do Git com os comandos amend e rebase

O versionamento distribuído e o estimulo a criação de branches locais independentes são propriedades que tornam o sistema Git uma das ferramentas mais promissoras para a realização de controle e versionamento de linhas de desenvolvimento. Assim, a partir do uso dessa ferramenta, a criação, o merge e a remoção de linhas de código acabam se tornando uma atividade mais rápida e menos onerosa do que seria com outras ferramentas com características opostas pois lançamos mão de recursos como commits locais. Neste artigo, quero introduzir dois comandos do Git que tornam possível a edição de uma mensagem de commit anterior o ammend e o rebase.

Escolhendo entre injeção de dependências por construtores e injeção de dependências por setters

O artigo é um guia de boas práticas que faz uma discussão sobre as técnicas mais aplicadas de injeção de dependências. Nele são enumeradas as vantagens e desvantagens da aplicação da técnica de injeção por método construtor em contraste a injeção através uso de setters e o porque de uma ser tão mais usada e conhecida do que a outra.

Desmistificando o conceito de inversão de controle e sua relação com a injeção de dependência

Um dos grandes temas que geram confusão no meio do desenvolvimento de software diz respeito ao relacionamento entre dois conceitos: a inversão de controle e a injeção de dependência. Neste artigo mostro de forma objetiva, fazendo uso de exemplos cotidianos, o que é a técnica de inversão de controle, como ela auxilia a resolver problemas que ferem o “principio aberto fechado” e como podemos alcança-la a partir da aplicação de uma injeção de dependência.

Separando testes unitários de testes integrados usando diretórios distintos com Maven

Não é mais uma novidade que a aplicação de testes já a partir das fases iniciais do processo do desenvolvimento de software é um dos diferencias que garante uma melhor qualidade ao sistema. Nesse contexto, essa elaboração de testes quando feita por parte dos desenvolvedores demanda algum tipo de organização uma vez que tanto testes unitários quanto testes de integração podem ser automatizados, mas não misturados. Neste artigo tratamos uma abordagem para separação e organização dessas fases do ciclo de testes durante o desenvolvimento de software a partir da configuração avançada do Maven.

Boas práticas de programação com a aplicação do princípio da responsabilidade única

No que diz respeito ao desenvolvimento de software, vivemos em um universo no qual transformações em sistemas são cada vez mais frequentes. Cada nova funcionalidade, até mesmo cada simples variação dela que se adapta melhor ao usuário final gera valor e soma dinheiro. Assim, cada sinergia de sucesso eleva o grau de diferenciação perante concorrentes e garante melhor vantagem competitiva. Nesse contexto, a velocidade com que um produto consegue se adaptar a uma determinada necessidade é um fator crucial de sucesso. Quanto mais rápido uma necessidade é desenvolvida, melhor é para todos os envolvidos. Assim, um dos fatores que devem ser considerados para um sistema amplamente adaptável é a sua capacidade de manutenibilidade que pode ser alcançada com a aplicação do principio da responsabilidade única.

Entendendo os padrões de projeto a partir da análise de frameworks populares de mercado: Padrões comportamentais

As abstrações enumeradas por Gamma et al. e que possuem como principal caracteristica a preocupação com a forma pela qual objetos satisfazem a comunicação entre dois ou mais são classificadas como padrões comportamentais. Em geral classes que pertencem a esse grupo tendem a descrever padrões comuns de comunicação entre entidades enaltecendo maneiras flexíveis de carregar essa propriedade e por isso nos auxiliam, mais uma vez, a desenvolver sistemas de baixo acoplamento. Neste artigo veremos aplicações dos onze modelos mais conhecidos desse grupo: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor.

Entendendo os padrões de projeto a partir da análise de frameworks populares de mercado: Padrões estruturais

Enquanto no artigo anterior observamos algumas aplicações populares de padrões de projeto criacionais e como que eles definem melhores maneiras de se instanciar objetos agregando a inteligência de como dependências e propriedades se interrelacionam de forma a originar novos objetos, nesta sequencia demonstrarei como que os sete padrões de projeto estruturais: adapter pattern, bridge pattern, composite pattern, decorator pattern, façade pattern, flyweight pattern e, por fim, proxy pattern estão intimamente correlacionaos em frameworks reconhecidos de mercado.

Entendendo os padrões de projeto a partir da análise de frameworks populares de mercado: Padrões criacionais

Amplamente aceitos como exemplos de arquiteturas a serem seguidas, os modelos conhecidos como padrões de projeto (ou design patterns como preferir…) ainda são pouco utilizados na construção de novos sistemas ou, quando utilizados, passam despercebidos. Apesar disso, paradoxalmente, é muito incomum encontrar softwares de ampla magnitude com a ausência de todos os padrões estudados pela “gangue dos quatro” de Erich Gamma e seus parceiros. Isso decorre do fato de que padrões de projeto nada mais são do que análises profundas sobre os tipos de soluções mais aplicadas sobre situações frequentes e pontuais mas, o mais importante, é que se tratam de alternativas que deram certo. Assim, quanto maior o grau de conhecimento dos envolvidos com a elaboração de um determinado programa, maiores são as chances de que este atinja seu objetivo de modo mais eficiente e com menor esforço individual.

A ascensão dos webservices: as arquiteturas SOA e REST e a definição do contrato WSDL

Com o passar dos anos, as grandes organizações vem convergindo cada vez mais para a adoção de medidas que as permitam aumentar o grau de sinergia para que, dessa maneira, possam elaborar sistemas mais robustos e eficientes, construídos com maior agilidade e menor custo. Esse comportamento é evidente, afinal, a reimplementação de artefatos já produzidos é onerosa e exige esforços desnecessários: um novo entendimento sobre um determinado negócio, uma nova implementação, novos testes, manutenção em geral… Nesse contexto, torna-se vantajoso tanto reaproveitar serviços como expô-los publicamente pois, desse modo, as corporações passam a concentrar seus esforços naquilo que é a raiz do próprio negócio agregando assim maior valor no que produzem e, por fim, tornam-se mais competitivas.

GIT: Configurando Meld como ferramenta de Diff externa no Linux

O artigo aborda a configuração do Meld com ferramenta de Diff para o Git instalado em um ambiente Linux.