"Javing" is the present continuous form of "to program in Java".
Here you will find: code snippets, examples, tips, tricks, tutorials, best practices, miscellaneous and much more.
Enjoy your Javing!
Did you know that IntelliJ ultimate has an embedded http client that you can use to sent requests to your app? There's no need for external tools like curl or postman, you can just use IntelliJ's endpoints tab. Also this requests can be saved as http files and be used on tests.
In the context of Kafka, what does back pressure mean?
It means that a slow consumer should be capable of handling throughput coming from a fast producer.
Do you know any solution(other than increasing partitions) to deal with consumers back pressure?
- Increasing partitions - The consumer signals to the producers that they are sending the data to fast(reactive streams can do this) - Buffering Name one advantage and one disadvantage of Kafka?
advantage: using Kafka can reduce the amount of integrations needed in a large ecosystem of applications. This reduction of integrations often results operational cost savings for the company.
disadvantages
disadvantage: order in which events arrived in a multiple partitions scenario is not guaranteed. Using timestamps can help consumers understand the order. If the cluster is being distributed across different time-zones, the event may also need to carry some sort of unique identifier so that alongside the timestamp, the consumer can understand the order.
Can race conditions happen in Kafka and how can we prevent them?
Race conditions with Kafka consumers can happen and one of the main reasons is that in multi partition scenarios, the order of the events is not guaranteed. In order to guarantee ordering timestamps and/or unique identifiers is needed.
Today I did a code challenge that a recruiter gave me. Is for a vacancy at a London company. I thought to record a demo explaining the code that i implemented and some of my thoughts, just to have here for future reference. I uploaded the code to this repo: https://github.com/SFRJ/offers
In the requirements it says to publish in github, so if I am allowed to publish in github, maybe I am allowed to also publish on the blog and on youtube :)
Here the demo:
bonus using vavr(formerly javaslang) The exercise said that I could choose any tool I like, I was thinking in doing vavr but since is not so well known maybe the reviewers don't like it. But just for myself I decided to modify the code to use vavr and upload it in a separate repository on github(https://github.com/SFRJ/offersvavr). This a very short video with some of the changes i did to introduce vavr:
Update(morning after)
When I was uploading the video in youtube i was just previewing and I noticed there was a little bug. I added tests for it and fixed it. Interesting, this situation made me thing about the importance of QA(Quality Assurance). I did not write automated acceptance tests but AAT are basically programmatic quality assurance. Maybe with AAT I woulda catch that but earlier. Doing the technique used to bring QA before code implementation is called ATDD(Acceptance Test Driven Development). Link to article written in this blog some time back on the topic:
I uploaded this other video with the explanation of the bug:
I just noticed that in the video I didn't explain that I refactored that overridden cancel method I was talking about at the end, since that method extraction was not really needed if I call again the repository in both get and cancel methods.
I was practising a Kata I haven't done in a while because I wanted to add a recording to the new Page I created dedicated to TDD Katas. The Kata in question was the Roman Numerals Kata (From Roman to Arabic).
After doing the Kata I ended up with this implementation:
This is fine, the solution worked but I just didn't like that those two nested loops seemed a bit of a lot of complexity. Probably not the best solution from the point of view of performance. I wanted to try something else. So I deleted that code and without deleting the tests I wrote this:
To me this seemed a bit better and probably faster. Optimisations are something that we should always postpone. Remember the saying?
Make it run, then make it nice, then make it fast.
Early optimisations can lead to unwanted over-engineering and some other problems. TDD teaches us that we need to grow our code gradually. But then how can we just refactor to something completely different than what we just got?
Once we have written all our tests and we are happy with our refactoring, the tests will act as our documentation, so even if we were to delete all the code and just leave the tests, we could recreate the code. So that is what I did initially to create that second implementation.
After observing the new implementation and compare it to the previous one, I decided to TDD to see if I could get to the code in the second implementation. I discovered that at the point where I was doing the refactoring after making the test for number 6 pass, here was the place where I could make a design decision and choose not to extract an enum and instead try something else.
This time the Kata has once more proven that TDD is not just capable of making safer code but also drive the design even when we are looking for a faster solution than the one we have.
Recently my company which has the same name as this blog launched it's website under the domain: https://www.javing.uk/
In the following weeks I will be re-organising a bit the content of the blog and also it's look and feel so that it is more aligned with the company colours and font. I will continue to blog as I often do with the only difference that this blog will now be the official blog of www.javing.uk
I am planning to re-organise some of the content of the blog. From now own TDD Katas will no longer be posted as blog posts, instead they will be added to the page "TDD Katas" on this blog under the following url: http://javing.blogspot.com/p/tdd_9.html