I see this architectural pattern being underrated and I think it needs to be used more often. Systems are shifting more and more towards microservices architectures and also at the application level we want to gain modularity and decoupling. Especially for services that are not under our control. Putting a boundary between our business and any other dependencies would ensure better future evolvability.
Recently I am working on the edge microservice of a distributed system, let’s call it
Microservice 1. This is built using Spring Boot and as usually it uses Spring MVC to build it’s internal API defined by Java interfaces and DTOs.
Microservice 2 wants to consume the API provided by
Microservice 1 so we need to bind these 2 microservices together. But what is the ideal way to do this in this case? Since microservices architectures are relying very much on bounded context and loose coupling we need to do this with minimum intersection but also avoiding duplications.
Today I had to face a strange issue regarding inspecting requests over the network. I am working on a new feature where users can upload files to our server trough a mobile application. I am responsible for developing the backend part and exposing the proper API. The frontend parts for this feature are the mobile applications, Android and iOS done by remote developers.
I had the opportunity to work with Blockchain lately (on Ethereum) so I learned quickly how is all working, how can I build my own blockchain. The documentation is a little immature at this time, as expected, it’s new technology. Also issues posted online ware broken because of different versions of the tools I used. Most of them weren’t even version 1 yet. I decided to explain the logic behind blockchains, so I will start by building a raw blockchain without using any specific tools. This will be pure Java.
This is for those times when we start a container and figure that no port or the wrong port was exposed. Docker uses it’s own bridge network, that we can define or change but there is no official documentation about how it manipulates the OS routing rules. And there is no official solution to expose a port on a docker container but there are a few workarounds. Let’s see what can we do.
Today we will discuss about memory leaks, what are these, what is causing them and how to find them using a tool called Java VisualVM.
A thread is just a unit that is doing some processing. A java application runs on multiple threads that can be spawn up any particular time. Each thread has it’s own stack trace bat all the threads in an application share the same heap. Once all threads are stopped, the application will exit. Working with threads can get very complicated and to be able to investigate our applications behavior it is important to be able to read through thread dumps.
In this post I will explain the workflow of doing TDD while solving a coding challenge. While following the TDD workflow we will intentionally head in the wrong direction at some point and we will see how we can easily refactor while having confidence in our tests. To stay original I chose a challenge that I didn’t find anywhere. And that is because the the educational system from Eastern Europe (ex Sovietic Block) was different from other places. It is also a good coding challenge to give developers doing a coding interview.
Lets face it, it happens often that our branches are flooded with commits with a significat number of them not even being directly related to the feature we are implementing, like
fixing typo or
cleanup debugger, comments, etc.
Acceptance tests should be very easy to follow by non tech people like our client could be.
Let’s say we want to let our users upload images and we want to save them to our
.../public/gallery folder using Paperclip. But we want to add them dynamically, based on another field of our model.
This will be a very short one, just to prove a point. ERB templates are usually very verbose while including partials and layouts and can result is a very complex UI architecture.
Time complexity measures the performance evolvability of an algorithm. It describes how an algorithm’s performance will scale based on scaling the inputs (or some external factor) or in other words, how will the processing time of the algorithm grow if we grow the input values or data quantity (like: increasing the integer values that represents some form of quantity, increasing the size of an array / string, etc). Instead of comparing the input and execution time, we can compare the input and the number of operations the algorithm has to execute. This is very useful when comparing algorithms.