jlinks

How to use Java Optional correctly, what to avoid and good practices: https://dzone.com/articles/using-optional-correctly-is-not-optional

@ConditionalOnBean(name = "otherNeededBean") The bean is only created, if the bean "otherNeededBean" already exist. @ConditionalOnMissingBean The bean is only created, if no other bean with the same name already exist. @ConditionalOnMissingBean(type = "alternativeBean") The bean is only created, if bean "alternativeBean" doesn't exist. Conditional based on Environment property Add proprty file to the Configuration class. @PropertySource("classpath:myspecific.properties") public class MySpecificConfiguration {} @ConditionalOnProperty(name = "email.notification", havingValue = "true") @Bean public MailService ... myspecific.properties: email.notification = true | false

"every method should either be a Command that performs an action or a Query that returns data. A Command cannot return data and a Query cannot change the data... it might be desirable to use two different data stores... this allows you to store the data in the read database as denormalised data... it allows you to scale the two different sides of your application separately..." More info:  https://culttt.com/2015/01/14/command-query-responsibility-segregation-cqrs/

https://dzone.com/articles/the-2019-java-developer-roadmap

"Merge creates a new “merge commit” in the target branch that ties together the histories of both branches. Merging is nice because it’s a non-destructive operation. The existing branches are not changed in any way. On the other hand, the target branch will have an extraneous merge commit every time you merge.  Rebase moves the entire source branch to begin on the tip of the target branch, effectively incorporating all of the new commits in target.  But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch. You get a much cleaner project history and it eliminates the unnecessary merge commits. But, there are two trade-offs for this pristine commit history: safety and traceability. The Golden Rule of Rebasing: The golden rule of git rebase is to never use it on public branches. Rebase moves all of the commits in source onto the tip of target. The problem is that this only happened ...

app-1 will provide a copy of his public key to app-2 and signs the communication with its private key. Step 1: app-1 creates private/public key pair in its keystore: $ keytool -genkey -alias "app-1-key" -keystore app-1.jks Verify: $ keytool -v -list -keystore app-1.jks Step 2: app-1 generates a certificate file from its private keystore: $ keytool -export -alias "app-1-key" -file app-1.cer -keystore app-1.jks Step 3: app-2 imports the public key of app-1 into its keystore: $ keytool -import -alias "app-1-publickey" -file app-1.cer -keystore app-2-publickey.store

Faults (or mutations) are automatically seeded into your code, then your tests are run. If your tests fail then the mutation is killed, if your tests pass then the mutation lived. https://pitest.org/ Example Method: isPositive Actual implementation:   if (number >= 0) return true; Following test will pass:   assertEquals(true, xxx.isPositive(10)); But fail for following code mutation:   if (number > 0) return true; To kill the mutation, the unit test should test boundaries:   assertEquals(true, xxx.isPositive(10));   assertEquals(true, xxx.isPositive(0)); See:  https://www.mkyong.com/maven/maven-pitest-mutation-testing-example/