jlinks

"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 in y

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/

A puts an envelope in a box, locks the box with his key and sends it to B. The box can't be opened on the way, since it is locked. B receives the box, and accepts to view it. But can't open the box neither, since it is locked. B lockes the box again, this time with his own lock and sends it back to A. The box is now locked with 2 locks, one from A, and one from B. A receives the box and realizes, that B has accepted the communication by locking the box with his lock.  A can now remove his lock and send the box back to B.  The box still can't be opened by anyone other than B. B receives the box with his lock and can now open the box with his own key and open the envelope sent by A originally. For A and B to trust each others locks (certificates), a Certificate Authority (CA) must approve both certificates. See also: https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

"Kafka Connect provides scalable and resilient integration between Kafka and other systems. The Confluent JDBC Connector for Kafka Connect enables you to stream data to and from Kafka and any RDBMS that supports JDBC. ... CDC basically enables you to stream every single event from a database into Kafka. Broadly put, relational databases use a transaction log ( redo log depending on DB flavour), to which every event in the database is written. Update a row, insert a row, delete a row – it all goes to the database’s transaction log..." Read more:  https://www.confluent.io/blog/no-more-silos-how-to-integrate-your-databases-with-apache-kafka-and-cdc See also  https://www.oracle.com/middleware/data-integration/goldengate/big-data/

"The difference between a forward and reverse proxy is subtle but important. A simplified way to sum it up would be to say that a forward proxy sits in front of a client and ensures that no origin server ever communicates directly with that specific client. On the other hand, a reverse proxy sits in front of an origin server and ensures that no client ever communicates directly with that origin server..." Read more here:  https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/