Diego Pacheco Tech blog

SOA(Service Oriented Architecture) is all about contracts. Contracts can either be managed explicitly by doing Contract First, Customer-Driven Testing, having POs manage the contract as an important asset as much as a UI is. Contracts can also be unmanaged or managed implicitly just pushing problems to consumers and making the whole org move slowly. So what is a contract anyway? Why should we care?  The contract is all Data, Behavior, and expectation involved in the services capabilities. It's easy to see just the endpoint's input and output data and forget about the rest. The rest is smaller things like data formats, access protocols, serialization formats, and do not forget about expectations. For instance let's say you are returning a list of customers, if the data is in ascending or descending order it might affect your consumer code or tests.  Contracts cab be versioned and we should have specific tests on the Implementation provider side in order to make sure we don...

There were some interesting posts about UML recently. Mainly being  “   Has UML died without anyone noticing? ” and “   Why UML “Really” Died ”. I also made some po s ts about UML in the past — mainly “   UML Hidden Gems ” and “   Architecture 101: Thinking about Design ” and “   Internal System Design: The Forgotten Discipline   “. IMHO success means decline and eventually abuse. That happened to all successful movements, technologies, and methodologies I can remember such as Agile, Architecture, DevOps, Docker, Spring, and many more. Yes UML was abused and used in the context of the heavy and rigid process. UML was often used for all CRUDs which does not make sense and does not add value. But honestly, if we see things with DDD lens even CRUDS don’t make sense especially with UX sense CRUD are not ideal at all. IMHO what happens is we are exposed to fashion and marketing. There is internal and external pressure to do things in one way instead of anot...

Spring Boot is the standard framework for developing java services nowadays. It's more than normal to have multiple deploys into productions during the day if you are not trapped by a release calendar or release train which should be a temporary thing and end up being a permanent thing. Ideally, you will have 3 at least 3 instances of your service, one for each availability zone in AWS. In order to introduce changes, DevOps often apply a pattern called Rolled Updates where often you patch one service and restart the application and then you do that one server at a time. In order to do that you server should be able to handle a clean shutdown and manage restarts smoothly which requires some config or code in your service side and also some consideration in sense of release resources, deny connections and prepare the land for a proper restart to happen. You might be in the middle of an important transaction so maybe you want to finish that first. For services is common to use the Sag...

@Value annotation allows you to inject either values or results of expression into fields or even methods and constructors. Spring has several mechanisms to deal with configuration and dependency inject. IMHO for Services is more them fine to use all these features, however for libraries we need to be extremely careful and I would say you don't want to use any of these capabilities. We also need to be careful about versioning properties inside jars, especially for libraries. It's very easy to get unpredictable behavior. So great powers require great responsibility and thinking beyond anything I made a video showing some of this feature and also some simple POC - so let's get started!

Like we say in Brazil (Todo Carnaval tem seu fim) all carnival has an end. This is the end, my friend. It's the final slidecast on the series. If you did not watch  part 1 and part 2 I highly recommend you do. Part 1and 2 I covered +40 books, 20 each slidecast, and today I will cover +20 more. Total +60 books. Even if you dont agree with all ideas here I recommend you watch them because you will see common patterns and connections between books and might get some insights or reading recommendations. So Let's get started! 

AWS Lambda is an awesome Serverless implementation. Lambdas are a bit tricky because they are ephemeral and short-lived so either they call another lambda or they will mutate some external state. Either an external data store like RDS, Aurora, S3, Kineses, Elasticache or they will call another microservices that does state mutation. In order to properly test Lambdas, we need to design for testability, the easier thing to do is always create more lambdas because you can check the input and output. So lambdas are not pure functions(functional programming) they often need to have side effects. So AWS has this library that makes it easier to test lambdas for Unit Testing / Mocking but also for localized Phased Integration Tests. You can mock source events like S3 ones, and also mock the context, and just test your lambdas with Junit. So I made a simple POC and video I want to share with you guys. So Let's get started!

Mock Server is an interesting and useful testing solution. Mock Server allows HTTP and HTTP Tests and verifications. Mock Server supports Java and NodeJS. Mock Server requires requests to match expectations. It's not that different from a unit test from JUnit. However, Mock Server has the expectations in a central server and you could version those expectations as Json files for instances or use the standard API in order to create the with programmatic code in Java or NodeJS. So today I made a simple POC showing how we can use Mock Server, both with Java and JUNIT in an embedded fashion but also in standalone mode and using the dashboard UI mock server has. So Let's get started!

Lean / Kanban was always about managing work instead of managing people. Often mention as Manage the flow. Organizations are about organizing people, but they should be about organizing work instead. As organizations grow, it's harder to make an impact and easier to get benefits. Safi Bahcall, the Loonshots book, says that as organizations are growing, the perks become much easier to get rather than impact(outcomes). That's why politics and empire-building strike. Leaders need to be explicit about managing flow. Otherwise, organizations tend to focus on local hierarchies and produce local optimization(classical Lean issue).  If we should manage work/flow instead of people(Some coachs also called it to manage the system). Should we have teams? Are teams silos? Are silos always bad and wrong? When should we create a team? When should we decommission a team? Work often happens on teams, people leave and join companies because of teams, but would teams get into the way sometimes? ...

Spring Boot is the most popular java stack nowadays. New languages like Go and Rust are capable of creating a single binary, self-contained with all deps to run the application. This is great for deployment simplicity but also easier to maintain. As time pass we want to have fast bootup times and do more with less. The native solutions are fast since they are statically compiled for a target platform or OS(in the case of UniKernels). Java was designed to be better as time pass(Runtime) and optimizations kick in. However thats not ideal for Serverless applications. GraalVM changes that since allowing us to compile JVM applications(Java, Scala, Kotlin) to native applications. Today I want to share a simple Video + POC using a new project called Spring Boot Native which allows us to create native images to spring boot apps.  Native images have some challenges like Type Erause for C++ and Reflections in Java. 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 . 

Java SPI is a standard java way to have binding between contracts and implementations. SPI used for several use cases such as Currency, Locale, TimeZone, DateFormat, Number, JDBC Driver, JPA, Json, JasonB, and many more. I believe the most classical example is for JDBC/JPA use cases where you have one common spec(contract) and multiple implementations for each database driver such as MySQL, Postgres, etc... SPI is interesting, shower I would not use SPI for common bread a butter SOA / Microservices use cases. Because often you just have one contract and one implementation, for that case using the new keyword or even basic DI/IoC I would say is much more desirable, easier, and much more simple and straightforward. However, if your use case has multiple implementations(beyond versioning) thats definitely something you should consider.

Lo4j is an old logging framework. Sometime ago Logback was faster than lo4j. Now, lo4j2 is the fastest and coolest kid on the block.  Logs are the eldest and primitive form of observability. IMHO observability has many different use cases such as Troubleshooting, Business Discovery, Performance Troubleshooting, Reliability Assurance, and Testing. IMHO you could use logs for all those use cases, however, IMHO logs are best suited for troubleshooting and metrics and better suited for general observability. Logs can destroy application performance and often are the number 1 culprit of slowness. Log4j2 makes logging faster due to async logging and LMAX Disturptor as the secret source. However I would question if you just use logs nor dont use metrics and traces. 

Design is not Subjective! I know we have bad actors out there and several times people do Bad Design and use subjectiveness as a way to control the dialog and shut down conversations. Today I want to explore more why I believe design is not subjective and Design is done by Design. Design is about Goals, Purpose, and Structure. Decisions are driven considering a particular problem Domain and thats an important matter. When we do design without considering a domain we often step into a code problem, not into a design problem. Just looking at the code misses the point and ends up killing the design. Today I want to share a slidecast I made going deeper on these questions and hopefully I will be able to demonstrate to you why Design is not subjective at all or at least why it should not be. Let's get started!