Showing posts with label code. Show all posts
Showing posts with label code. Show all posts

Tuesday, September 29, 2020

Iterator

Trade-offs are super interesting and excellent exercises you can do to have better design and better coding. Let's say we want to do some simple algorithms that return vols from a String. So how many different implementations can we have? So easily we can think about some sort of Utils or generic function that can do the work for us. What if we cant to be Lazy or Early loading or be able to abstract the process? Well and Iterator is an interesting pattern that we can use to help us to abstract state and have more functionality around the data structure. So because there is the Pattern Iterator you might think that there is just one possible implementation right? Actually, there are several different implementations we can do and we can play with different trade-offs. So today I made 2 java videos to co trought this pattern and show some practicality in code. I hope you guys like it, let's get started. 

The Videos

The Code

https://github.com/diegopacheco/java-pocs/tree/master/pocs/simple-iterator 

Cheers,

Diego Pacheco

Saturday, September 19, 2020

Dependency Management Best Practices

Every single technology project uses dependencies. No matter the language you use, you always will use dependencies. Monoliths and Monorepos make dependency management more manageable by having it all in the same place. Services and Microservices make them a bit more challenging because now they are spread across each server, updating libs is a challenge that requires automation to be fixed. Besides automation, some best practices are also needed. Several times engineering teams take dependency management for granted. After all, we are just adding some strings and numbers to a file, right? So how complicated can that get? Often dependency management issues only appear after time and scale. Dependency Management is a super important and relevant discipline. Today I want to share some best practices to make your life better and make sure you scale your codebase with speed and solid practices rather than piles of tech debt and pain. So In case your not geek enough, the post icon image is a famous Death Star for Star Wars, which also becomes popular by the Death Star diagram from microservice organizations like Amazon, Netflix, Twitter, and other companies. 

Dependency Management Best Practices

Often Best practices are depending on contexts. Once you have complexity several times, best practices do not necessarily translate from one company to another; however, there are cases where they apply and make sense, not always, but for Dependency management IMHO, these are Golden Rules and excellent practices to be followed. Here are some Dependency Management best practices: 

  • 1. Use a Dependency management tool (ant, maven, gradle). Do Explicit Dependency management.
  • 2. Use Artifact Management Solution (Nexus, Archiva, Artifactory) - Management but Mainly: Cache.
  • 3. Remove dependencies you dont use.
  • 4. Use Consistency Versioning (MAJOR, MINOR, SEC/PATCH).
  • 5. Do not use multi-project EXTERNAL POMS.
  • 6. Keep Dependencies up to Date (But does not update at deploy time - Immutable Infrastructure)
  • 7. Use Dependencies Carefully (Shared-Libs) avoid coupling as much as you can.

Dependency management is not only about using some specific or better tools. It's about a process and culture which requires attention and automation as well.  Let's do a deep dive into each of these practices and understand why they are important. 

Use the Dependency management tool (ant, maven, gradle). Do Explicit Dependency management.

It might sound obvious but it's not uncommon to see infrastructure projects downloading binaries manually and not using explicit dependency management via tools like Ant/ivy, Maven, and Gradle. No Matter the language you use, no matter if is an engineering or DevOps code, you should do explicit dependency management. Because is easier to maintain and we can relly on common process and tools for improvements and housekeeping. 

Explicit dependency management means, explicit defining dependencies on a file that is used by the dependency management tool. You should avoid having embedded dependency and scripts who download dependencies outside of your main tool. 

Use Artifact Management Solution (Nexus, Archiva, Artifactory) - Management but Mainly: Cache

Software tends to grow with your business. As you grew build times can get very slow. A cache is a must-have feature. Because there are multiple engineers downloading artifacts from the web and you often have multiple cloud environments like DEV, STAGING, STREE, PROD, etc... Dependency management solutions like Nexus, Archiva, Artifactory, also can help with better dependency management but one of the main benefits is to have a central cache and central repository management/location. 

Remove dependencies you dont use.

This might sound silly. But un-used dependencies are bad as Dead Code because they make upgrade efforts harder and they end up creating technical debt. It's not uncommon that dependencies have 3rd party dependencies too and you might be dependency from a 3rd party dep instead from a direct dep and have that scenario for a dep you dont use is bad. It's unclear, confusing, raise false positives, and makes reasoning about refactoring efforts much much harder. 

Use Consistency Versioning (MAJOR, MINOR, SEC/PATCH).

Versioning is something old as the snakes in the jungle(like we use to say in Brazil). However people still dont get it right. Why? People know when to use MAJOR(Major API Breaking change), Minor(Minor change no breaking backward compatibility), and Security/Patch release (minor bug fixe or security patch, not impact). But people do not do it. Why? Most of the time is a combination of lack of discipline and lack of ownership and pain of upgrading people dependencies. Central teams can be great in sense of reducing some costs but certainly, they hide some of the pains that if people would face them directly the would definitely deal with the problem differently.  Having consistent versioning is super important, for Design, for Testing, and for health engineering practice I would argue. This part requires discipline and every single binary should embrace this principle. 

Do not use multi-project EXTERNAL POMS.

Don't be fooled by the word POM. This principle works for any dependency management tool. You should not share multi-project external configs for dependency management. Either you have a monolith or monorepo where you have all code in one place or if you do have multiple github repositories you should not share these files(poms). Because? Well because they are EVIL. They create coupling they make upgrades harder and they kill microservices. 

If you will have shared libraries they should be:

 * Small

 * Independent 

 * Isolated (dont have poms, not share configs)

Otherwise, you will build a distributed monolith and binary coupling will prevent you from upgrade when you need it. Never trade coupling for convenience or developer experience.  However, if you have a monolith or a monorepo is perfectly fine to share poms. 

Keep Dependencies up to Date (But does not update at deploy time - Immutable Infrastructure)

Another super important practice is to keep your dependencies updates. Thats important for several reasons such as:

  * Prevent Bugs

  * Fix Security Bugs

  * Reduce Tech Debt

Update Dependencies often works with the same principles as Branches in Configuration Management. If you gonna have a long-lived branch(which you should avoid at all costs) you need to do merges every day so it reduces the complexity and issues on an old fashion bing bang boom merge. Libraries updates work in the same way. For minor, security patches, even minors should be able to upgrade it easily. 

DevOps has a principle called - Immutable Infrastructure, you do not want to upgrade libs before doing a deploys or when a service restart. Because that breaks the principle of immutable infrastructure. However, at the same time, you want to AUTOMATE your dependency management and update libs frequently. Often engineers do not have the mindset to keep updating libs, which can be fixed with proper plugins and automation. 

Use Dependencies Carefully (Shared-Libs) avoid coupling as much as you can.

When we ship internal shared libraries we need to be very careful. Shared Libs should be treated by applying the same principles we apply for Services. It's super important to pay extra attention to 3rd party deps in shared libs in order to avoid binary coupling. It's fine to use shared-libs, sometimes thats the right solution, however, there is a huge abuse of internal shared libs on the technology industry. 

Better Dependency management helps Design and Testing. It makes CI/CD more effective and in the long-run increases the speed and ability to ship better and more frequent software. Currently, we live in an era where every company is trying to do proper CI/CD, Observability, Services, DevOps, SRE, and many other important matters however we often forget dependency management is an important sub-part of Building that end ups charging a high price at scale. 

Cheers,

Diego Pacheco

Wednesday, September 16, 2020

JDK 15


Java is finally getting interesting again since JDK 8 thats the first time I wish to be using a new JDK in production. I'm really looking forward to JDK 16 and to the future. JDK 15 has lots of interesting things such as Records, Pattern Matching for instanceof, EdDSA algo, Text Blocks, Local classes and interfaces, Sealed classes and interfaces, ZGC, FMA, and much more.  So Let's get started and take a look at a quick video I made to show Java 15 working with Maven and Idea. 



The Video

The Code

https://github.com/diegopacheco/java-pocs/tree/master/pocs/java-15-fun

Cheers,

Diego Pacheco

Tuesday, August 25, 2020

BFF Dilemma

The software industry is always becoming more specialized. We have backend engineers, frontend engineers, edge engineers, cloud/DevOps engineers and I'm sure we will have more specialization in the future. With specialization and growth on systems, we end up having more layers or places that we can put software. Microservices often end up making a huge proliferation of services at the backend(check out Uber case for that).  There are so many places that you can "put" your software but one particular place that is growing a lot is the BFF(Backend for Frontend) place. Often we have different stacks for backend and frontend. Frontend often is on JavaScript or TypeScript. Backend is often in Java, .NET or Go. So the first dilemma is, is BFF a frontend thing or a backend thing? IMHO it's a frontend thing where frontend means consumer. So how different BFF is from a driver or client? Well if you look into drivers and clients they often dont have network logic like routing, discoverability, circuit breaking where BFFs often dont. There is nothing preventing you put that logic on the BFF which really raises the question of how different BFF is from drivers/clients. Definitely, there is an overlap with Drivers/Clients/BFFs and even Services. 

BFFs the Benefits

Let's say you have a big app or multiple apps with multiple platforms like IoS and Android. Let's say you also have multiple sites or web application, it will be common to have a design system where you company want to have a standard view of the brand experience(colors, fonts, tons, etc...). It's important to leverage components, if you are working with React thats even easier and natural. However, another dilemma that often happens is, should I make a design system component, or thats something just for the app? Well, that is a couple of factors that could help you to figure it out. 

* How many apps/sites will have that feature/component? 

* How often that behavior it's likely to change? 

* How complex is to make the component? 

Even if you decide to go one route vs another route you can always refactor. So refactorings are cheap others are not, so as you grow you need to keep asking these questions. But regardless of what kind of component you end up doing or not doing you have benefits on the BFFs like:

* Caching 

* Sever Side Rendering - Which also can be done in a generic way. 

* Centralize and Re-use UI Logic (not business logic)

However, sometimes the UI Logic can easily be seen as business logic, in some sense microservices are making this much worst them it is.

Microservices are making BFFs Fat

I remember first waves of SOA where the default was to write code on the service, the services end up being FAT and with stuff that supposes not to be there. However, I also remember we having Aggregation Services, which were services that call other services and that was like the Gateway Uber is talking about on the re-discover of DDD post on DOMA. 

Right now we have a different default, meaning, do not put stuff on the service, they need to be micro. The consequence is that complexity is pulled upwards. Complexity needs to live somewhere and microservices right now tend to be super simple and small however all the orchestration/choreography is being done by the BFFs which are getting more fat and complex. 

It's a Governance Problem

IMHO we need Services, not Microservices. Services should be a bit more FAT. It's fine if the BFF is also FAT as long as it makes sense. So we are talking about a governance problem, that we need to answer some of the following questions:

 * Where we put our code? (BFF, Aggregator Service / Gateway, Service)? 

 * Are the decisions we made on the past still make sense? 

 * Are we running joint Event-Storming exercises to figure out boundaries? 

 * How do we version APIs? Do we provide forward and backward compatibility? for how long?

 * How we expose APIs? HTTP/2, gRPC? 

 *How own what component? 

 *How we test things properly? Are we having WASTE on our tests? 

 *How we coordinate cross-team efforts? 

 *Do we create a lib instead? Sidecar? 

It's also a management problem

There are lots of options to manage this kind of cross-coordination. Do we have a big team as just have a big kanban to handle it? Do we have a chapters/guild(Spotify) to take care of that? Do we have a small pizza team(amazon) to execute the changes? Amazon's way relies on autonomy as a business construct and lean way it kind of makes a lot of sense because of the dependencies and lack of business autonomy you might end up here. When I say business autonomy I dont mean if you company has a cool culture and people are allowed to experiment and do stuff. I mean autonomy is a business construct, so you need to be able to generate results by ourself otherwise you always will have dependencies and you might be better served by the lean model. 

Guidelines and Reflection Over Rules

Rules should be avoided because like any Design and Architecture matter we need to apply judgment. There is no one size fits all, so thats why rules are complicated. Judgment might be right or wrong or it might be right for a period of time and them things change and it's not valid anymore. For all those reasons we need continuous reflection, via big long retrospectives and working groups. Dilemmas are not bad, they are good actually it forces us to think which is our job. If we are not thinking a lot we might be following things we dont understand and creating debt and problems for the future :-) 

Guidelines are awesome because they are not hard rules, you should have very few hard rules in a sense of design and architecture. Guidelines are educative and teach people how to approach problems. One thing I use a lot with Guidelines is Principles, I love principles they are great and I few the industry needs to use them more. 

Cheers,

Diego Pacheco


Wednesday, August 5, 2020

Github: PR Template + CODEOWNERS

Github is an amazing platform. Today I want to show in a video 2 super killer features which is: Pull Request Template and also Branch protection with CODEOWNERS. This feature makes the PR Reviewer life much better and improves documentation, learning, save time, and just push the team to a much better direction. Sometimes people might create too much bureaucracy, however, the other extreme to have no comments in chaos and not good. So we need to look for some sweet middle ground. So Let's get started. 

Video


Code


Cheers,
Diego Pacheco

Monday, August 3, 2020

Terraform Functions

Terraform is a great DevOps tool. Terraform has support for functions which is a killer function. Functions allow you to take much more advantage of Terraform and avoid the right custom code in bash or other languages.  Today I made a video showing some functions in terraform like how we can work with external JSON files and use functions. So Let's get started.


Video


Code


Cheers,
Diego Pacheco

Sunday, August 2, 2020

Java Object Creation Patterns

Java is an old language. 25 years now. Java has several limitations and issues however java is the robust and pretty well-stablished solution for backend, databases, Caches, Search Engineers,  IoT, and much more. Today I want to share some patterns about object creation. I highly recommend you read Effective Java book, which was a huge inspiration for this blog post. So I want to show you guys some useful patterns like Static Factories, Builder, Singletons and Immutable Objects.  So I made a quick video with code, let's get started. 



Video


Code


Cheers,
Diego Pacheco

Monday, July 27, 2020

Quarkus with Panache

Quarkus is a super interesting project.  IMHO Quarkus is JEE done right. It's super-fast, relies on Netty, uses GraalVM. Today I want to share a video I made about Quarkus with Panache using the Postgres database running on Docker. So Let's get started. 






Video


Code


Cheers,
Diego Pacheco

Spring-Boot-2 with Kotlin

Kotlin is a Jetbrains language that has lots of inspiration from Scala. Spring-boot-2 is a popular solution for microservices like Quarkus and Micronaut. Today I want to share a simple video I made so you can get started with Maven, Spring-Boot-2, and Kotlin. If you are new to Kotlin I also recommend seeing my previous post about the language. Okay, let's get started. 





Video


Code


Cheers,
Diego Pacheco

Kotlin 101

Kotlin is a JVM language created by JetBrains in 2011. Google declared the official preferred language for Android in 2019. Kotkin is heavily inspired in Scala. Kotlin claims to have the good parts of scala without having the bad parts. It's also possible to see some Python and Groovy influence as well. Kotlin makes java much less verbose and has awesome support in sense of IDE thanks to IntelliJ. I'm a Scala guy and prefer scala, however, kotling is an interesting choice especially if you are making android native apps. So today I want to share a video I made with a good walkthrough through several features of the language in a Maven project. So Let's get started!

Video


Code


Cheers,
Diego Pacheco

Friday, July 24, 2020

Property Based Testing with Jqwik

Property-Based Testing in a really nice functional programing way todo testing. Originally created at Haskell with QuickCheck. Today there are frameworks for pretty much all languages. Jqwik is a property-based testing framework for java.  Property-based Testing is cool because you focus on a predicate / boolean expression and forget about inputs. When I say forget about, thats happen because the property based testing takes care to generate all possible inputs for you and you can save lots of typing, creating uses cases. You still need to work in your property/assertions however you end up writing much less code and cover a much wider range of possible inputs.  Today I want to share a video I made about it, so let's get started.


Video


Code


Cheers,
Diego Pacheco

Immutables Builders

Fluent Interfaces(Internal DSL) are a nice and sweet way to code. However, make a builder in Java all the time can be a bit verbose and time-consuming. Immutables Builders is a very interesting library that can help us with the heavy lifting.  Immutables can generate builders which are Type-safe, null-safe, and thread-safe. They are super easy to use and serialization ready. Immutables make your code clean and fun. So today I want to share a java video made about Immutables Fluent DSL in Action. So Let's get started. 






Video


Code


Cheers,
Diego Pacheco

Swagger + Spring Boot 2

Swagger is a great API documentation tool. Today I will show how we can generate Swagger Documentation based on a Spring-Boot-2 Application. We will be using SpringFox. Swagger is interesting because you have a very useful contract for services/microservices. It's possible to generate code from that spec and also invoke the services. Spring-Boot is a popular java framework for services/microservices the integration between to solution is more than ideal and SpringFox does that for us effortless. So Let's get started!








Video


Code


Cheers,
Diego Pacheco

Hashing in Java

Hashing is an interesting technique we need to use in standard java solutions such as services and microservices. SHA-256 is a secure hash algorithm for data you want to hash. Often this technique can be used for Passwords or high entropy PII Data.  For this blog post, I want to share with you guys how we can create secure hashes in java using SALTS. We will be experimenting with 4 flavors of Hashing(SHA-256) being: Standard Java API, Guava, Apache Commons Codec, and Bouncy Castle. Today we will see a Java video I recorded going through the API. So Let's get started.





Video


Code


Cheers,
Diego Pacheco

Tuesday, July 21, 2020

Micronaut

Micronaut is a JVM(Java, Groovy and Kotlin) framework similar to Spring Boot or Quarkus. Micronaut is modular and blazing fast. It has a minimal memory footprint and is a bit cleaner API compared with Spring Boot for instance. Micronaut does Reflection based IOC(with Cache). Micronaut also has GraalVM support. Micronaut is a non-blocking IO and has a Reactive API based on Netty and Rectivex projects. Today I made a quick video going trought the Micronaut API DEMO I made. 


Video


Code


Cheers,
Diego Pacheco



Monday, July 6, 2020

Code Forensics

Troubleshooting it's a very interesting skill-set. Often engineering teams dont expose this issue. People are always fixing bugs but very little we are talking about bugs(investigations).  Being able to run investigations(Fix bugs) is a must-have skill in a cloud / distributed systems world that we live. I believe troubleshooting is someting much more strong in SRE/DevOps than it is on engineering. I deeply believe we can and we should improve our debugability tools, tricks, and techniques not only because we want to build better user experiences in digital products but also because we want to spot major trends and fix and improve our overall engineering process and products.  Today I have a slidecast for you guys, so let's get started. 

Video


Slides


Cheers,
Diego Pacheco

JUnit 5 Tricks

JUnit 5 is much better than previous versions. Testing is something every engineer should be obsessed about it. Junit 5 improved a lot the assertion API being much more clean, easy to use, and concise. Today I want to share a video I made about Some cool JUnit 5 tricks. I should make this post a long time ago, however is better late than never :-)  Let's get started.




Video


Code


Cheers,
Diego Pacheco

Thursday, July 2, 2020

Spring Boot 2 running with Netty

Spring Boot 2 - It's the default Java way to implement REST endpoints and microservices nowadays. I really miss old days of spring where we used XML and there was no coupling and spring was really lightweight. IMHO Spring is great if you use it under a service, If you use a shared library of the big framework, you can easily get Binary Coupling which will be bad for you in the long run.  Today I want to show how easy is to use Netty. Using netty directly is not that hard and really anyone can use without spring. Netty comes as default dependency if you use webflux instead of the web. So Let's get started.



Video


Code


Cheers,
Diego Pacheco


Serde Benchmark

Serialization is always an important aspect of any Microservice or solution. Often people associate Benchmarks as potential flame-war enablers, thats not my goal here. Benchmarks are sensible things, they really vary from config, hardware, use case, payload. I'm trying to convince you guys of anything. I'm Just sharing some simple comparison exercise I did so you guys have any idea about performance to Serialize and Deserialize and the resulting size. I highly recommend you do this benchmark for you use case. However, my pet project here might give you some ideas on how to get started. The benchmark I will show is coed in Java but you can take this ideas and do them in any language. I will use Junit as way to run the benchmarks. So let's get started. 

Friday, June 26, 2020

Debug Tricks

Debugging is an important tool. When it's possible to debug you have more chances to figure out the problem faster. Unfortunately not all issues are created equally and sometimes you cant debug. When you need to debug something is important to have your debug game sharp. Several engineers might consider the topic basic but as a consultant, I saw multiple times overtime people dont dominate the tools. Dominate and master your tools is important not only for productivity but also to improve your developer experience and make your life easier as an engineer.  I used Eclipse for a long time. For the last 3 months I decided to give IntelliJ a chance. A month ago I made a video about some killer stream debug trick and also how to do some configs. Today for this post I want to show some other IntelliJ Debug tricks which will make your life easier and will make debug much better and productive.


5 Java Debug Tricks Video


I hope you guys like it. 

Cheers,
Diego Pacheco 

Chuyên mục văn hoá giải trí của VnExpress

.

© 2017 www.blogthuthuatwin10.com

Tầng 5, Tòa nhà FPT Cầu Giấy, phố Duy Tân, Phường Dịch Vọng Hậu, Quận Cầu Giấy, Hà Nội
Email: nguyenanhtuan2401@gmail.com
Điện thoại: 0908 562 750 ext 4548; Liên hệ quảng cáo: 4567.