Diego Pacheco Tech blog

Configuration management is an important aspect of any service. However, configuration management is way bigger than just using a source control system like Git. CM(Configuration Management) is about Branching Strategies, or avoiding branches might be the best strategy in the line of Trunk Based Development. Besides branches and configuration management versioning systems like git we also need to be able to version applications in a proper way. It's pretty default to use semantical versioning. i.e: $major.$minor.$sec-patch however sometimes is important to know what version the app from inside the de application.  Java has a way for us to version packages(which can be used as modules) and we can know what versions we are getting, thats interesting for building modular monoliths and also for troubleshooting reasons, imagine you deploy to service and want to be sure you are running a specific version no matter the name of the jar is. Java JAR can have a build number or whatever versi...

Properties are around since java.  Properties are a persistent form of K/V pair which is mainly used for configuration. Configuration can be extrapolated all the way down to Feature Flags, Feature Toggles, and Canary. Java properties are cool because they are a simple API that allows you to do simple and yet powerful programing around them. There are 2 interesting projects enhancing properties such as Apache Commons Configuration and Netflix Archaius . These projects are pretty cool and give you killer functionally however the Java Stand SDK can also be pretty powerful if you have enough creativity and know-how to use it. So today I want to share a video exploring the Java Properties API in Depth showing how we can do some pretty powerful and simple configuration management for Dynamic Configurations, Feature Flags, Toggles, and more. So Let's get started!

BOM(Bill of Materials) is an interesting technique to simplify dependency management. Dependency management is often a lost discipline nowadays and often developers dont care about dependencies. BOM is a way to make dependency management easier, however like anything in this world it can be abused. So be careful to not create a massive monolithic BOM with all your dependencies because that would be another microservices killer . 

Git is a very powerful tool for source code version control. Often we do POCs and no one whats to waste time while you are doing a POC so often people dont pay much attention to their commit messages(including myself). However the POC grows and you reach the point to productionize the solution, all great but what you do with your poor commit messages? Good messages are critical for good configuration management, release management, and code hygiene. So what can we do? Well git rebase can rescue us. Git rebase is also useful in other use cases where you need to have a specific format of messages because your CI/CD tool does some validations or you are hunting a bug down and you want to drop a bad commit or you are cherry-picking commits to doing a chirurgical release. So I made a short video showing rebase commands in action. We also will use squash which is an interesting way to combine your commits in one for better trackability. So Let's get started.

So this is a hot and problematic subject: Monorepos. IMHO there are good use cases for mono repo when your project is really one thing such as angular. However, there are good use cases for microservices. IMHO we should avoid extremes and just have one big monorepo for the whole company and at the same time avoid having microservices for everything. There is a need to strike some balance between maintenance, isolation, and organization. This is the first post about the monorepos, today I will cover the solution from Google called Bazel . In the next post, I will cover the solution from Facebook called Buck. All posts will have practical videos building mono repo with Java.  IMHO the IDE integration is not ideal for both Bazel and buck. There is some support for VSCode and IDEA but is far from being ok. So Let's take a look at the video.

NetflixOSS Archius 2 is a great Dynamic Configuration solution for microservices. Archaius is based on Apache Commons Configurations project . Using Archaius we can load configurations from several sources such as OS env vars or any Database like Oracle or even from Zookeeper. If there is a missing configuration source you can add it pretty easy and load your configs.  Archaius can be used in any java project no matter if is a microservice or not.  Archaius also support dynamic configuration refresh via callbacks -- In short, this means you can reload your configs without re-deploy or downtime in your microservice -- which is really great. Archaius has many nice features. Archaius also is very modular and easy to extend there are some nice community extensions available as well. 

Gradle Dynamic Resolution strategy a.k.a use a + on the dependency is a usable feature.  This is handy because you can do something like spring:spring-core:4.0.+ and gradle will always get the latest snapshop for you -  but them to make this work fine you need people have discipline to do proper major/minor versioning. 

Ainda me lembro do inferno das DLLs quando trabalhava mais ativamente com produtos da Microsfot. Naquela epoca sofriamos com problemas de dependêcias. Quando comecei a trabalhar com Java sofri o mesmo problema de uma forma um pouco diferente mas na essência era a mesma coisa. Em java o problema tem o nome de inferno dos jars . É incrével ainda ver empresas que em 2010 ainda passam por este tipo de problema em Java. Isto por que existem duas soluções que resolvem este tipo de problema. Estou falando do Apache Maven 2 e do Apache Ivy . As suas soluções da apache provem a funcionalidade de gestão de dependências. É comum ver uma pasta chamada *lib* no classpath das aplicações java com mais de 100 jars, sendo que 70% ou mais não serve pra nada, nunca foi usada, nunca se quer foi tocado pelo classloader e dificilmente ira ser todado, mas por que as pessoas ainda fazem isso ? Por dois motivos:   Problemas de Depedências : Todo mundo ja deve ter visto o famoso ClassNotFoundExce...

O Maven é uma excelente solução de gerência de configuração para Java, mas você não deve utiliza-lo sozinho, para tirar mais proveito do maven você irá precisar de uma solução de: hospedagem de dependências e proxy. Essa solução é o Archiva , neste post vou mostrar como instalar a solução e bem como a forma mais adequada de utiliza-lo. Em um post anterior eu já tinha mostrado como instalar o Archiva, juntamente com um servidor de Build Continuo e Maven 2. Então se você quiser ver como instalar o Archiva sugiro que de uma olhada neste post . Agora vamos ver a forma mais adequada de lidar com os repositórios e como que o Archiva e o Maven faz isso, vamos discutir a estrutura interna de repositórios do maven e bem como resolver pequenos problemas que você pode passar. Resolução de Dependências com Maven O maven resolve as dependências da seguinte forma. Primeiro ele procura no seu repositório local que fica no $USER_HOME/.m2 caso ele não ache a dependência ali ele iria para web ...

Em um post anterior escrevi sobre a possibilidade de customizar o comportamento do sistema de controle de versão open source chamado Subversion ou popularmente chamado de SVN. Neste post vou mostrar através de um Script Python como é possível modificar o comportamento do Subversion de forma que não deixe o usuário realizar um commit sem um comentário. A Importância dos Comentários nos Commits Além de uma ótima prática de gerencia de configurações, utilizar comentários no commit do svn nos ajuda na hora de realizar merges, na hora de acompanhar mudanças e também quando você está procurando um versão antiga de um artefato. Você irá precisar de um Binding A API do Subversion é para alguma linguagem como Java, Python, PHP, etc é chamada de Binding. Então precisamos de um binding para Python. Vamos utilizar o binding do próprio site do subversion chamado de pysvn . Você precisa instalar o Python e o Subversion e bem como o pysvn. Uma vez tudo isso instalando vamos ao script, ...

Já avaliei diversas ferramentas em vários projetos que participei. E sei bem como pode ser uma novela avaliar, escolher, comparar e instalar uma ferramenta. A ferramenta pode ser desde uma ferramenta de modelagem como EA ou uma ferramenta de Requisitos. Mas a ferramenta em questão também pode ser uma solução de arquitetura como um servidor de aplicação ou até mesmo um ESB. Avaliar tem um custo Ninguém compra ferramenta só pela lista de features, para comprar uma ferramenta você tem que avaliar diversos aspectos da mesma que podem vir do mais trivial ao mais avançado. Antes de mais nada você tem que pensar para que você precisa da ferramenta e qual as necessidades que a ferramenta deve sanar. Isso pode ser tratado como requisitos, já utilizei essa abordagem algumas vezes com sucesso, uma simples lista com os requisitos da ferramenta podem bastar em alguns cenários. Veja que você terá um trabalho para fazer isso e isso demanda tempo de recursos e gera custos. O que fazer? Podemos dividi...

Não sou muito de fazer lista, mas creio que seja justo compartilhar algumas das boas soluções open source que utilizo em projetos. Já utilizei essas soluções em diversos projetos, não utilizo apenas soluções open source, este também não é um post anti-proprietário. A idéia é compartilhar algumas boas soluções para o desenvolvimento com Java. Ferramentas não substitui o bom profissional, uma boa ferramenta na mão de um tolo pode ser uma bomba relógio, mas a culpa não é da ferramenta e sim de quem o contratou. Um boa ferramenta na não de um bom profissional pode além de facilitar a sua vida e evitar o trabalho repetitivo, aumentar a produtividade e até mesmo ajudar a mitigar riscos. Então vamos a lista de algumas soluções open source que uso, essas soluções são para propósito geral, existem outras ferramentas que utilizo mas ai já estaríamos entrando em domínios mais específicos e esse não é meu objetivo neste post. Firefox : Excelente browser e ótima escolha para desenvolver suas aplic...

Qual desenvolvedor Java que já não fez um script ant ? Ant é uma poderosa solução escrita em Java para automação de build. Eu já usei muito Ant, não tenho nada contra a solução, mas em um projeto você precisa muitos mais do que build. Os scripts ant tem o seu valor, na verdade todo bom script seja ele em ant, bash, groovy ou no que for tem seu lugar ao sol. Não acho perda de tempo escrever esses scripts, mas acho absurdo ter que reescrever a mesma coisa várias vezes. Na prática é isso que acontecia. Quando se inicia um projeto Java se tem um setup muito pesado e que as vezes demora bastante. Por que tem que se criar toda uma infra-estrutura de diretórios, tem que se configurar o framework A,B,C e D para funcionar com o X,Y e Z, bom quem já fez isso sabe a novela que é. Um desenvolvedor novo? Caos No mínimo 2 dias configurando e instalando coisas na máquina do desenvolvedor. Para variar você esquece de algo e começa a dar problemas de ambiente, assim a brincadeira vai até que as cosias ...

Relembrando o post sobre o Banquinho . Que por sinal ainda acho que é uma visão a se ter sobre uma solução completa extremamente viável e simples. Hoje eu adicionaria outros pilares ao banquinho, seria como se fossem as cores secundarias, todas derivadas do bom e velho RGB , por isso não vou fazer mudança no banquinho. Mas vou falar de um pé sub-colateral, falando da rosa dos ventos agora.O ponto em comum entre ferramentas e processos, que estou chamado aqui de políticas. Acredito que esse seja o melhor nome, até por que esse termo é comum em gerência de configurações. Políticas? Hummmm.... Não. Não é esse tipo de política que você deve estar pensando. Falo de políticas de uso quanto a ferramentas, aqui ferramentas e processos se misturam, não falo apenas de workflow de trabalho, mas em formas de uso. Uso de Ferramentas Ferramentas servem diversos propósitos, os que considero mais importantes são: Diminuir o peso do processo Facilitar o trabalho das pessoas Automatizar tarefas repet...

O Subversion é um dos mais conhecidos sistemas de controle de versão do mercado. É uma solução open source que pode ser utilizada de forma viável no ambiente corporativo. O Maior problema do subversion é quanto a adminsitração por que as ferramentas boas de administração são pagas, não usando essas ferramentas você tem que administra-lo via linha de comando. Mas isso não é o fim do mundo. Eu sinto fala de processamento da working copy do SVN, o Clear Case de Rational/IBM já tem essa feature de maneira bem inteligente e eficiente, quem sabe nas próximas versões eles colocam. Existem diversos clientes visuais para o Subversion, o melhor deles que é o Tortoise não existe para linux, somente para Windos. O que é uma pena pois esse é o melhor client e no Linux não existe nenhum que seja bom perto do Tortoise. O Tortoise é o nosso primeiro ponto de customização você pode adicionar scripts customizados que realizam determinados processamentos no Tortoise mas isso não é aconselhado p...

A assunto não é novo. Sempre que vejo na hypermidea e no mercado comentários sobre essa prática vejo sempre o foco em build, abstraindo o máximo possível e fazendo um esforço alguns até enfatizam com foco em gerencia de configurações. Não há dúvidas que Gerencia de Configuração é uma disciplina esquecida aqui no brasil, fora do país até vejo movimentações sobre o assunto mas lá também existe uma grande deficientes de profissionais nessa área. Você conhece alguém que é ou quer ser gerente de configurações? São raros talvez achar um gnomo laranja venha a ser uma tarefa mais fácil do que achar um GC. Isso acaba afetando muito um projeto de software, bom que conhece Casos de uso e utiliza estimativas através do Use Case Point sabe a disciplina de ambiente podem diminuir até 38% da complexidade do projeto. Esse é um número muito alto. Isso se divide em: Planejamento de Release : As trocas de versão são complicadas e se perde muito tempo para colocar uma versão no ar, se acontece algum prob...