Diego Pacheco Tech blog

It's normal for engineers to think of the best solution possible when we think of solutions. A bad engineer would deliver as fast as possible without even considering whether his work is good enough or right. A "good" engineer would think a lot about how to do it and be very slow. A great engineer does both things. So, how can you be fast and slow at the same time? When we are working on a pretty small problem, or in a green field(a new project where you can do whatever you want), and/or a small company or startup with very little software. We all want to have success, and we want companies to thrive; success means more software, and more software often means more technical debt, and it becomes impossible to change everything all the time.

Software is very interesting, it's amazing how little things make a huge difference, being able to see all the small intricacies and how the pieces fit together is a complex and fascinating task. The more we understand, the more we learn effectively, better we can do it. Software complexity does not reduce, it only grows, working with a relentless mindset of continuous improvement is the only way to go forward. Refactoring is often seen as a "bad word" a big spooky thing because everybody believes is busy, so why are you risking breaking a lot of things if you can move forward and "live" with the problems. XP (Extreme Programming) got this right from the get-go, you need the principles and values. XP has a value called: courage; courage to do refactoring, especially when the conditions are not in your favor, considering monoliths and distributed monoliths the odds are never in your favor. Once you start doing so, slowly put all guardrails in place, would such c...

When we right software we need to worry about so many things. For instance: Performance, Scalability, Security, and many other important concerns. There is also a need to worry about corner cases, error paths, and conde readability from other engineers. Which is not an easy task. So should we return null or not? Should we throw an exception or not? Null is considered to be a Billion of dollars mistake. Languages have some concepts to help us like Haskell has the  Maybe Monad . Scala has  Option . Rust has  Result . Java has  Optional . Since  version 8 , Java improved a lot and there is still a long head ahead but  slowly  getting there. Today I decided to do something different with you guys, let's do a simple refactoring together in order to improve our code and understanding. So there is a video showing from zero to a hero like code step-by-step. This is the first refactoring video I make, hopefully, it will be interesting for you guys. Without f...

No post anterior comentei sobre a importância das práticas da engenharia como refactoring e versionamento aplicados ao Banco de Dados. Neste post vou mostrar como usar o Liquibase na prática com Apache Maven 2. A utilização em conjunto com Maven 2 é muito produtiva por dois fatores, o primeiro é que você pode criar um projeto Java no eclipse e utilizar o seu plugin de SCM sendo do CVS ou Subversion para versionar o projeto. O Segundo motivo é você pode colocar este projeto no seu servidor de build continuo e tendo assim as mudanças do desenvolvimento e banco acontecendo de forma igual e no mesmo momento. A Estrutura básica do Projeto Você poderia estruturar o projeto de várias formas, no site do liquibase existem algumas boas práticas de como estruturas os conjuntos de mudanças. Vamos a estrutura do projeto que criei: src/main/resources/ changelogs src/main/resources/ database-conf src/main/resources/ sql src/main/resources/ start-script pom.xml No arquivo pom.xml que f...

Faz tempo que o banco de dados deixou de ser um mero repositório. Hoje em dia os bancos de dados tem muito mais do que um mero repositório. Muitas aplicações tem diversos pontos em banco de dados, quando a maior parte de aplicação já não esta no banco. Quando olhamos para o desenvolvimento de software nos dias de hoje podemos perceber a utilização de diversas práticas e métodos da engenharia como Integração Continua, Sandboxes, Testes, Versionamento, Refactoring e muito mais. Mas e o banco de dados? Na maioria das vezes não utiliza estas práticas. A não utilização das práticas de desenvolvimento junto ao banco de dados tem motivos, dentre eles saliente a própria questão cultural. Em muitas empresas a equipe é dividia em desenvolvimento e banco de dados, logo que mexe com Java, .NET, Delphi ou qualquer linguagem por exemplo não é do mesmo grupo das pessoas que lidam com o banco. Outro fator é o paradigma, muitas vezes as equipes responsáveis pelo banco de dados estão atreladas a um pa...

Ainda é muito comum discussões sobre refactoring . Mas sinceramente acredito que boa parte delas perderam o ponto a muito tempo. Refactoring como o próprio Fowler disse é uma técnica sistemática para reestruturar código sem mudar o seu comportamento. Sempre que escolhemos uma abordagem de design como por exemplo: DBC , TDD , RDD , DDD, etc.. estamos levando a solução através modelos consolidados. Esses modelos tem prós e contras e dependendo da situação um vai ser melhor do que o outro. Eu partircularmente gosto muito do modelo do RDD . Mas como chegamos a um modelo solido e eficaz? O design não nasce pronto, deve ser feito de forma incremental utilizando refactoring por exemplo, mas o refactoring não deveria mudar a semantica, logo precisamos de algo mais que refactoring, nesse caso estamos falando de design incremental. Como fazer um bom Design? Para fazer um bom design é necessário conhecimento do dominio! Sem conhecimento do dominio é impossível fazer um design robusto e sustentáv...