![\"Paging](\"/static/paging_demo-a325402259bf9864dced311c9eafa7c8.gif\")
In Go 1.23, a new Pattern property in net/http.Request was added.\nIt contains the route pattern used to handle the request. This improvement may have gone unnoticed by many, but it can\nsimplify request processing and improve performance in cases where we need to obtain the matched routing pattern\nfor the current request. Let’s see how we can use this feature.
At AUTO1, we have more than 200 microservices, some of which are written in Go and include an HTTP server.\nIt is critically important for us to collect metrics from these services in order to quickly respond to incidents,\nmake data-driven decisions, and optimize system performance.\nFor example, we collect http_requests_total metric:
requestsTotal = promauto.NewCounterVec(prometheus.CounterOpts{\n\t\tName: \"http_requests_total\",\n\t\tHelp: \"total request count\",\n\t}, []string{\"path\", \"method\", \"code\"})Obviously, for the path label, we should store the path template, not the specific value, for example, /test/{id} instead of /test/123.\nOtherwise, we risk a cardinality explosion, which can significantly increase the amount of stored data. You can read how to choose labels properly in \"Prometheus best practices\".
Previously, to extract the route pattern, we had to pass the multiplexer to a middleware function:
\nfunc metricsMiddleware(next http.Handler, mux *http.ServeMux) http.Handler {\n\treturn http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\t_, pattern := mux.Handler(r)\n\t\t\n\t\t...\n\t\trequestsTotal.WithLabelValues(pattern, method, statusCode).Inc()\n\t}\n}In this approach, we matched the request to the route a second time, and that negatively affected performance.
\nStarting with Go 1.23, we can get the route pattern directly from the request, without passing the multiplexer to the middleware:
\nfunc middleware(f http.Handler) http.Handler {\n\treturn http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\tpattern := r.Pattern\n\t\t\n\t\t...\n\t\trequestsTotal.WithLabelValues(pattern, method, statusCode).Inc()\n\t})\n}This significantly simplifies the middleware, making the code cleaner and more readable. We are no longer dependent on ServeMux and no longer need to re-match the request.
It is important to remember that Request.Pattern is only available after the request has been matched to a route. For example:
func main() {\n\tmux := http.NewServeMux()\n\tmux.Handle(\"/test/{id}\", routeMiddleware(handler()))\n\n\tsrv := http.Server{\n\t\tAddr: \":8080\",\n\t\tHandler: globalMiddleware(mux),\n\t}\n\n\tif err := srv.ListenAndServe(); !errors.Is(err, http.ErrServerClosed) {\n\t\tlog.Fatalf(\"server error: %s\", err)\n\t}\n}\n\nfunc routeMiddleware(h http.Handler) http.Handler {\n\treturn http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\tlog.Printf(\"ROUTE pattern: %s\", r.Pattern)\n\t\th.ServeHTTP(w, r)\n\t})\n}\n\nfunc globalMiddleware(h http.Handler) http.Handler {\n\treturn http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\tlog.Printf(\"GLOBAL pattern: %s\", r.Pattern)\n\t\th.ServeHTTP(w, r)\n\t\tlog.Printf(\"GLOBAL pattern after: %s\", r.Pattern)\n\t})\n}If we send a request GET http://localhost:8080/test/123, in logs we will see:
2024/11/10 13:20:37 GLOBAL pattern: \n2024/11/10 13:20:37 ROUTE pattern: /test/{id}\n2024/11/10 13:20:37 GLOBAL pattern after: /test/{id}This is the expected behavior. The multiplexer implements the http.Handler interface, and inside the ServeHTTP method, it searches for the handler that matches the request. Starting from Go 1.23, it fills the Pattern property of the request with the matching route pattern:
// net/http/server.go\nfunc (mux *ServeMux) ServeHTTP(w ResponseWriter, r *Request) {\n\t...\n\tvar h Handler\n\tif use121 {\n\t\th, _ = mux.mux121.findHandler(r)\n\t} else {\n\t\th, r.Pattern, r.pat, r.matches = mux.findHandler(r)\n\t}\n\th.ServeHTTP(w, r)\n}Thus, the r.Pattern is filled only after the ServeHTTP method of the multiplexer has been called, and the logs confirm this behavior.
In the last two Go releases, the net/http package has received significant improvements that reduced the gap with third-party packages, like gorilla/mux. Now, net/http.ServeMux supports HTTP methods and wildcards in routing patterns, bringing its functionality closer to what third-party packages previously provided.
Additionally, the introduction of the net/http.Request.Pattern property in Go 1.23 has simplified middleware development by allowing us to access the route pattern without needing to re-match the request, improving performance and reducing code complexity.
With each of these improvements, there are fewer reasons to choose third-party routers. While the choice between the standard package and third-party routers used to be more obvious, today I would recommend starting with the standard net/http package.
Paginated APIs, often encountered when dealing with servers and databases, break down large datasets into manageable chunks or pages. This methodology not only optimizes resource usage but also enhances the overall user experience by delivering content progressively. However, integrating and managing paginated data in a mobile app can be a challenge, from maintaining loading states to ensuring a seamless transition between pages and supporting content filtering.
\nIn this guide I will show you how to work with paginated APIs in Android with Jetpack Compose and Paging 3 libraries.
\n
\n![\"Paging](\"https://developer.android.com/static/topic/libraries/architecture/images/paging3-library-architecture.svg\")
The key components of the Paging 3 architecture include
\nWe start with the data layer and define a Retrofit API for fetching movies from network service.
\ninterface MoviesApi {\n @GET(\"/3/discover/movie?language=en-US&sort_by=popularity.desc\")\n suspend fun discover(\n @Query(\"api_key\") api_key: String,\n @Query(\"page\") page: Int,\n @Query(\"with_genres\") genres: String,\n ): Response<MoviesNetworkResponse>\n}Next, we will leverage the Room library, which is compatible with Paging 3, to create a local paging source.
\n@Dao\ninterface MoviesDao {\n @Query(\"SELECT * FROM movies ORDER BY id ASC\")\n fun getMovies(): DataSource.Factory<Int, MovieDbEntity>\n}It's important to highlight that we utilize DataSource.Factory as the return type instead of PagingSource. This choice is made specifically because DataSource.Factory offers the map() method, enabling us to map MovieDbEntity instances into domain layer models.
Now we need to put together local and remote data sources in Remote mediator.
\ngetRemoteKey().nextPage) is stored in the database after each successful network request.val page = when (loadType) {\n LoadType.REFRESH -> 1\n LoadType.PREPEND -> null\n LoadType.APPEND -> repository.getRemoteKey()?.nextPage\n } ?: return Success(endOfPaginationReached = true)For bidirectional pagination support, provide the preceding page number for the PREPEND load type. The REFRESH load type is employed when content is refreshed, initiating loading from the initial page.
\nCall our network data source method to fetch a page of data from the server.
\nval movies = moviesDataSource.discover(page)The RemoteMediator code will appear as follows:
\nclass MoviesRemoteMediator(\n private val repository: MoviesRepository,\n private val moviesDataSource: NetworkMoviesDataSource,\n) : RemoteMediator<Int, Movie>() {\n\n override suspend fun load(loadType: LoadType, state: PagingState<Int, Movie>): MediatorResult {\n\n return try {\n\n val page = when (loadType) {\n LoadType.REFRESH -> 1\n LoadType.PREPEND -> null\n LoadType.APPEND -> repository.getRemoteKey()?.nextPage\n } ?: return Success(endOfPaginationReached = true)\n\n val movies = moviesDataSource.getMovies(page)\n\n val nextPage = if (movies.isNotEmpty()) page + 1 else null\n\n repository.insertMovies(movies, nextPage, loadType == LoadType.REFRESH)\n\n Success(endOfPaginationReached = movies.isEmpty())\n\n } catch (e: Exception) {\n MediatorResult.Error(e)\n }\n }\n}RemoteMediator uses the repository to store movies list and next page number in the database.\nRepository also takes care of clearing the database table when data is refreshed:
\nclass MoviesRepositoryImpl(\n private val database: MoviesDatabase\n): MoviesRepository {\n\n override fun getMovies() = database.movies().getMovies().map { it.toDomain() }\n\n override suspend fun insertMovies(movies: List<Movie>, nextPage: Int?, clear: Boolean){\n\n database.withTransaction {\n if (clear) {\n database.movies().clear()\n }\n\n database.movies().putMovies(movies.map { it.toDbEntity() })\n\n if (nextPage != null) {\n database.remoteKey().insertKey(RemoteKey(MoviesDatabase.MOVIES_REMOTE_KEY, nextPage))\n }\n }\n }\n}The Pager object serves as a bridge between remote and local data sources. It is managing the page loading, prefetching, and handling the transitions between various data sources to provide a seamless and responsive flow of paginated content within your application. You can configure the page loading behavior with the following parameters:
\nclass MoviesScreenViewModel(\n moviesSource: MoviesRemoteMediator,\n repository: MoviesRepository,\n private val movieDetails: MovieDetailsApi,\n) : ViewModel() {\n val moviesFlow = Pager(\n config = PagingConfig(\n pageSize = PAGE_SIZE,\n prefetchDistance = PREFETCH_DISTANCE,\n initialLoadSize = INITIAL_LOAD,\n ),\n remoteMediator = moviesSource,\n pagingSourceFactory = repository.getMovies().asPagingSourceFactory()\n ).flow.cachedIn(viewModelScope)\n}Now, let's explore how to consume the paginated data in your Compose UI.
\nUse the collectAsLazyPagingItems extension function to collect the PagingData and observe changes.
val movies = viewModel.moviesFlow.collectAsLazyPagingItems()Use the LazyColumn or LazyVerticalGrid to efficiently display paginated data in your Compose UI.
LazyVerticalGrid(\n modifier = Modifier\n .fillMaxSize()\n .padding(16.dp),\n columns = GridCells.Fixed(3),\n horizontalArrangement = Arrangement.spacedBy(16.dp),\n verticalArrangement = Arrangement.spacedBy(16.dp),\n ) {\n\n items(\n count = movies.itemCount,\n key = movies.itemKey { it.id },\n ) { index ->\n\n movies[index]?.let { movie ->\n MovieCardSmall(\n movie = movie,\n onClick = { onClick(movie.id) },\n )\n }\n }\n }\n\nNote the usage of the key property for items. The key property uniquely identifies each item, allowing Compose to efficiently update and recycle composables as data changes.
\n
LazyPagingItems offers insights into the ongoing data loading process, allowing you to effectively manage errors during pagination. By examining the loadState.append property, you can determine the loading state when appending new items and present a user-friendly indication of the current status.
\nFor instance, the following code snippet demonstrates how to react to different loading states during item appending:
\nwhen (movies.loadState.append) {\n is LoadState.Loading -> { ProgressFooter() }\n is LoadState.Error -> { ErrorFooter(onRetryClick = { movies.retry() } }\n}Similarly, you can assess the loading status when the list data is refreshed by checking the loadState.refresh property. Extension functions isError() and isLoading() provide convenient checks for error and loading states, respectively.
\nfun LazyPagingItems<Movie>.isError(): Boolean = \n loadState.refresh is LoadState.Error && itemSnapshotList.isEmpty()\n\nfun LazyPagingItems<Movie>.isLoading(): Boolean = \n loadState.refresh is LoadState.Loading && itemSnapshotList.isEmpty()Incorporate these checks into your UI logic to display appropriate screens based on the loading or error states. The following code snippet demonstrates how to handle loading and error states along with providing a retry option:
\nwhen {\n movies.isLoading() -> LoadingScreen()\n movies.isError() -> ErrorScreen { movies.retry() }\n else -> MoviesGrid(movies = movies, onClick = viewModel::onMovieClick)\n}Additionally, LazyPagingItems offers a convenient retry() method, allowing you to retry the last failed data loading attempt with ease.
Now lets add filters to our movie list to see paginated list of movies filtered by genre.
\n![\"Filters](\"/static/paging_demo_filters-ff80a7606fb30961e2bda56bd6ed9985.gif\")
We start with requesting genres from the server and saving them in our database. We will keep genre data and selection in the database so that we can observe it from our domain and UI layers.
\ninterface MoviesApi {\n @GET(\"/3/genre/movie/list?language=en-US\")\n suspend fun genres(@Query(\"api_key\") api_key: String): Response<GenresNetworkResponse>\n}\n\n@Dao\ninterface GenresDao {\n\n @Insert(onConflict = OnConflictStrategy.REPLACE)\n suspend fun putGenres(genres: List<GenreDbEntity>)\n\n @Upsert(entity = GenreDbEntity::class)\n suspend fun updateGenres(genres: List<GenreDbUpdateEntity>)\n\n @Query(\"SELECT * FROM genres\")\n suspend fun getGenres(): List<GenreDbEntity>\n\n @Query(\"SELECT * FROM genres\")\n fun observeGenres(): Flow<List<GenreDbEntity>>\n}Now we can add with_genres parameter to our network request:
@GET(\"/3/discover/movie?language=en-US&sort_by=popularity.desc\")\n suspend fun discover(\n @Query(\"page\") page: Int,\n @Query(\"with_genres\") genres: String,\n @Query(\"api_key\") api_key: String,\n ): Response<MoviesNetworkResponse>Remote mediator will get selected genres from the repository
\n ...\n val genres = repository.getGenreSelection()\n val movies = moviesDataSource.getMovies(page, genres)\n ...Every time user selects a new filter we stave it in the database and restart pagination by clearing movies in the database and resetting the page to 1.
\nclass MoviesScreenViewModel {\n\n fun onGenreClick(genreItem: GenreItem) = viewModelScope.launch {\n genresProvider.setSelection(genreItem.id, !genreItem.isSelected)\n repository.clearMovies()\n }\n \n}class MoviesRepositoryImpl {\n\n override suspend fun clearMovies() = withContext(Dispatchers.IO) {\n database.withTransaction {\n database.movies().clear()\n database.remoteKey().insertKey(RemoteKey(MoviesDatabase.MOVIES_REMOTE_KEY, 1))\n }\n }\n\n}
Source code: https://github.com/auto1-oss/android-compose-paging\n
Official documentation: https://developer.android.com/topic/libraries/architecture/paging/v3-overview
Sense of Security
\nTreat the injured first
\nTrust your tools
\nCommunication via Radio
\nWhat I present today is how to use police techniques and their mindset to detect and solve bugs in software, so that you can be the best software developer that society can provide.
\nFor some years, I worked as a police officer in Brazil and I can say that it is a challenging career. The first step was to pass a national test, where knowledge of various laws was required. Criminal laws, traffic laws, and even the laws of physics.
\nThe second step was to pass a battery of medical exams. Almost perfect health was necessary to be able to practice the profession, in addition to having most of the parts of the human body.
\nThe third step was the psychological examination. It was necessary to have a clear mind and not have impulses different from those expected from a person who must protect other people.
\nAs a fourth part, there was also the fitness test, a test in which career candidates had to prove they had sufficient strength and speed to carry out daily police tasks. Running, pull-ups, sit-ups and long jump are examples of what was required.
\nThe last stage was the Police Academy, where for three months those from now on known as students would learn and prove the learning of several new skills: first aid, use of firearms (pistols, carbines, submachine guns, etc.), non-lethal weapons, martial arts, public policy, and many other disciplines.
\nAll this so that society receives the best police officer that its people can provide. So, what about using some of the following principles and techniques to become the best software developer that society can provide?
\nWithout needing to be a security expert, you already know that it is impossible to have a completely safe city. Even if we reached the point of having perfect police officers, which in itself is impossible, we would not have a police officer for every citizen. In general, the recommendation is 300 police officers for every 100 thousand inhabitants.
\nAware of this limitation, that it is not possible to guarantee complete security for all citizens, police agencies work with the concept of a sense of security. Through strategic actions to combat crime, citizens' feeling that they are safe is increased. This mental condition gives them peace of mind when working, studying, and carrying out their daily tasks.
\nThis sense of security also affects criminals. The common visibility of police officers carrying out their duties in strategic places, as well as effective actions to combat crime, make criminals stay away from that place.
\nNotice that ending 100% of crime is impossible, what we do well is limit its actions. From here we can extract our first lesson when dealing with software: perfect code, totally bug-free, is impossible.
\nDespite this conclusion, the fact that it is impossible does not mean that we should simply ignore the problem. On the contrary, we can, like the police, create strategic actions to combat Bugs. To the point that Bugs themselves will run away from our code.
\nTest Driven Development - TDD is a strategic action that provides a feeling of security in your code. Before the crime occurs, you position police officers in a specific region. Before the Bug occurs, you position the test in a specific place in your code.
\nRobert C. Martin, in his book \"Clean Code: A HandBook of Agile Software Craftsmanship\", teaches us that writing unit tests before writing production code is just the tip of the iceberg in defining TDD. There must be a continuous cycle of improvement, in which there is always a test covering the code you are developing and this security that the code is protected allows you to play with it, and work with it. After all, whatever problem may happen, there is a police-test there to protect you.
\nOne of the functions of Highway Police Officers is to provide first aid in the event of traffic accidents. There are often serious injuries that must be treated as urgently as possible, as even 1 minute can make the difference between life and death.
\nThe first step when arriving at a traffic accident site is to mark the location appropriately to prevent other accidents. We must use lighting devices and other appliances to make it clear to other vehicles that there is a danger there.
\nThe police officer must then check the condition of all the injured to prioritize them according to the severity of each situation.
\nOnce the treatment of each injured person has been completed and, if necessary, they have been taken to the hospital, it is time to survey the accident site. At this stage, the police officer begins to collect all the information relating to the accident to have sufficient information so that a decision can be made on the cause of the accident and, when applicable, any culprits.
\nThis is the mental model that you and I must adopt when we are faced with a Bug. Although several procedures have been adopted to prevent it from occurring, it is a fatality that can happen. It's like when the highway was well designed, the vehicles were up to date with maintenance, but even so, due to carelessness or misunderstanding on the part of the driver, an accident happens.
\nAs in the case of traffic accidents, the first step to take is to secure the environment so that the Bug does not cause other problems. If possible, we can revert the application version to one in which the Bug did not appear. We can use a feature flag to temporarily disable a feature. Regardless of the method used to stop the bleeding, the important thing is that we must focus on treating the injured first rather than looking for culprits.
\nWe have to agree with David Thomas and Andrew Hunt, in their work \"The Pragmatic Programmer: your journey to mastery\" that facing Bugs is a sensitive subject for most developers. Instead of treating the issue as a problem to be solved, some approach it with denial, pointing fingers, lame excuses, or simply apathy. It's exactly the opposite of what is expected!
\nInstead of looking for the culprit in a traffic accident, we must first assist the victims and stop the bleeding. In software, instead of finding out who inserted the Bug, we must solve it.
\nWhen treating an injured person in an emergency, one approach is to use the Glasgow Scale to determine the patient's consciousness. On this scale, one of the components is the verbal response.
\nThe injured person is asked simple questions, and by analyzing the responses, we can assess the level of consciousness and consequently the level of urgency of their care.
\nYou and I must carefully read every error message that is displayed during the Bug, it may contain vital information so that we can resolve the problem.
\nYou may be thinking, but what if there is no error message? If we are just faced with an incorrect result? Well, this also happens in traffic accidents, it is not uncommon for there to be an unconscious victim who cannot answer questions.
\nWhen we discussed the sense of security, we talked about the importance of tests in our application. Go and build a test that can reproduce that Bug, so you can extract the information you need to solve it.
\nThink of these tests like the motor tests that highway patrol officers perform on unconscious victims to check their level of consciousness: do the eyes open in response to pain? Is there a pupillary response to light stimulation? Mentally translate this into software language: Does the Bug repeat itself when I enter this and that parameter? And if I insert this new argument, does it happen too?
\nTo decide on a Bug, data is needed. If you don't receive this data, you must extract it.
\nPolice work is very complex and your day-to-day job involves the fight for life and protection of the most important assets for society. There would be no point in having a modern and efficient selection and training process for the development of police officers if they were not given the appropriate tools for their work.
\nAnd when I say appropriate, I don't mean they are minimally capable of performing the task, as the result delivered is directly related to the quality and safety of the tools. For an excellent result, not only the police officers but their tools must also be excellent.
\nIn the police agency I worked for, one of the work tools used was an Austrian pistol known worldwide for its safety and efficiency. The Glock 17 pistol was developed to meet the strict criteria of the Austrian army who wanted to replace the model used during the Second World War.
\nIn addition to requirements on durability, efficiency, and reliability, safety against accidental firing was one of the pivots of the new model.
\nBut how did a knife factory manage to deliver the pistol model that would prove to be the safest? Well, it can be said that, in addition to intense testing, the secret to reliability was simplicity and maintainability. The person responsible for the project designed the equipment with as few parts as possible, minimizing complexity. Today the Glock pistol is made with an average of 35 parts, which is a much smaller quantity than other pistols on the market.
\nWith a simpler design, so-called first-level maintenance is much easier. Equipment users can easily perform maintenance procedures, making the equipment's efficiency last for decades.
\nOf course, you must already remember the principle with the acronym KISS, which stands for Keep it Simple (omitting the last word because I don't want to offend the reader). The secret of that renowned pistol model was not in the used materials, but in being simple. The secret of maintaining your software in good shape is to keep it simple, having a specific component for each task. When a problem arises, you will know exactly which component to look for, as each component has a responsibility, this is the principle of Single Responsibility.
\nBecause of all this, when you are at a shooting range practicing your aim, the police officer knows that if he is not hitting the target, most likely, the error is in his procedure and not in the equipment.
\nAllan Kelly, in one of his contributions to the Book \"97 Things Every Programmer Should Know\", corroborates this idea that we should trust our tools when dealing with Bugs. Considering our tools are widely used, mature, and in use by multiple companies, we have little reason to doubt their quality.
\nOf course, a prototype, version 0.1, is much more fragile than a library that has been on the market for several years. We are also not saying that it is impossible to have bugs in compilers.
\nBut considering how rare compiler bugs are, what we are saying is that in the search for a Bug solution, we should trust our tools and look at our piece of code first.
\nImagine it as an efficient distribution of efforts. The library or compiler code has already been reviewed and tested for many years by countless people. As for that little piece of code of yours, only God knows who besides you has looked at it on your team.
\nOn one of those days, I managed to solve an unpleasant bug that occurred in one of our services. It was a non-deterministic error in our test suite, that is, the Bug only pushed out its head when no one was looking.
\nThis type of non-deterministic error generally involves three types of origin: multithread, time sensitivity, and dissynchrony between construction and cleaning of test data.
\nAnalyzing the body of the failed test, after several hours, of course, I began to strongly distrust the way we created timestamps with a native Java library. After all, the test seemed perfect to me, if there was an error it must have been somewhere else.
\nBut, aware of this lesson that we should trust our tools, especially since the component in question had been in Java for 9 years, I ignored this distrust. This saved me a lot of time and embarrassment, as I'm going to share that the error was elsewhere.
\nOur test suite ran all tests in a single thread, so it wouldn't be a concurrency issue. But it also ran each test in a deterministic but unpredictable order. Therefore, the source of the intermittent problem must be in some specific order in which the tests were performed.
\nAfter several hours of analyzing the logs, I was able to identify two tests that failed when run in sequence. It turned out that, although our tests performed a test data cleaning routine after each execution, a simple typo had silently overwritten the cleaning method in one of the tests, which generated data inconsistency if such tests were executed in a specific order.
\nI remember that one of the first systems I developed when I worked in the police was one to replace the sending of statistics through radio communication. Many years ago, each police station was supposed to send daily work statistics via radio. Data such as number of people and vehicles inspected, car accidents, etc.
\nThis took a lot of time as the audio quality of radio communications was not always ideal. The interlocutors spent a lot of time transmitting and confirming each piece of information. All this using Q-Code
\nThe Q-Code is a standardized collection of three-letter codes used in radio communication. The use of Q-code even in voice transmissions makes communication safer and more efficient. Each set of three letters, always starting with the letter Q, has a specific meaning that is known to the interlocutors.
\nI could see that two of those codes were widely used among police officers in radio communication: QAP and QSL.
\nQAP was used when you wanted to transmit a message. Let's say someone wanted to talk to me, so he said on the radio: \"Bruno, QAP?\". This could be translated as \"Bruno, are you ready to hear a message?\"
\nMy answer could be QAP or for example QRM. If I responded with QAP, I was signaling that yes, I was ready to receive the message. If you responded with QRM, I would be informing you that at that moment the communication is being interfered with.
\nDuring communication, the second most used Q-Code appears, QSL. At the end of each message, the sender ends it with the QSL. This means that he is asking the receiver to confirm whether they received the message. It would be something like: \"There is a suspicious vehicle heading towards your team, QSL?\" If I had understood the entire message, I should respond with a simple \"QSL\". In the absence of a response, the sender repeats the message until receiving confirmation from the receiver.
\nEach message is concluded with a QSL, and its reception is confirmed with a QSL. Does this remind you of any transmission control protocol out here, used on the internet?
\nThe main thing here is that a large amount of knowledge is condensed into three letters, in a language that provides interlocutors with efficiency and security. Eric Evans, the author of \"Domain-Driven Design: Tackling Complexity in the Heart of Software\", would agree with me that there is a principle here that should also be adopted in software development.
\nA language specific to the domain, which considers possible interference from the environment, a ubiquitous language that is known by all interlocutors, can be the difference between life and death, between success and damnation of a project.
\nWhen a project does not have its own language for that domain, this creates the need for numerous translations between interlocutors. Developers have to translate for domain experts. These, in turn, have to translate their demands to developers. Even among developers, there may be a need for translations.
\nAll these translations make concepts confusing and the consequences of a lack of mutual understanding can be disastrous.
\nThe importance of this in trying to arrest a Bug goes much further than compilation errors or exceptions. It goes through the swampy characteristic that the software may be logically working almost perfectly, but it is not delivering what was expected by the stakeholder.
\nLet's look at the following pieces of code:
\nif (order.status != completed) {\n // (...)\n}if (order.isFullyRefunded()) {\n // (...)\n}Here we have a small example of two ways of expressing the same situation. In the second piece of code, a common language between developers and domain experts was used. Here, possible logical errors can be easily noticed, without the need to keep in mind what the possible states of the Order are and what the expected state is for that case.
\nSee the following code:
\nPayment newPayment = payment.add(10);What do you expect from this code? Does it add ten dollars to the payment? Ten transactions, inbound or outbound? Will the method create a new payment object or will it just change the value of the payment variable and create a new reference called newPayment?
\nA lesson also taken from the book \"Clean Code: A HandBook of Agile Software Craftsmanship\" shows that clear communication must also take place between software developers. Functions must communicate exactly what they are doing.
\nIf you have to look at the function's implementation to know what it's actually doing, that's a big sign that you need to rename it.
\nI'm very grateful that you've made it this far, you've certainly learned a lot about police activity and how some of its principles can be applied to combat and remove Bugs from your software.
\nBy applying this knowledge you will be able to work more confidently in your code, giving you peace in your daily life and also allowing you to experiment and discover new things.
\nYour aim will be improved and you will get straight to the point, avoiding damage instead of first looking for the culprits. You become bolder and go further because you know you can trust your tools. This leaves you more time to refine your code and seek excellence.
\nFinally, not only will your code be safe and efficient, but its result will also be in line with what your customers expect because through effective communication you can accurately deliver what was demanded from you.
\nThe result of all this is that Bug is in jail, lives are no longer in danger, and you can go home at the end of your shift to enjoy the rest of the day with your family which is looking forward to welcoming their hero back.
","fields":{"slug":"/bug-police-officer/","tags":["debugging","testing","TDD","DDD"]}}},{"node":{"id":"d53c49b4-fba1-5071-b078-79bbf0f23344","frontmatter":{"category":"Engineering","title":"A wild Thread appeared! Multithreaded Testing and Thread-safety","date":"2023-02-24","summary":"Today we'll talk a little about how threads work on computers and how to extract more value from concurrent tasks. For this, I will present techniques on how to develop and especially how to test code that uses multiple threads, avoiding the main pitfalls that involve this theme. Of course, along the way, you'll also learn more about Java's Concurrent package, non-blocking algorithms, immutability, and more. However, we need to start by talking a little bit about butter.","thumbnail":null,"authorName":"Bruno Morais","authorDescription":"Bruno is a Senior Software Engineer at AUTO1 Group.","authorAvatar":{"relativePath":"pages/a-wild-thread-appeared-multithreaded-testing-and-thread-safety/avatar.jpeg","childImageSharp":{"resolutions":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAUABQDASIAAhEBAxEB/8QAGAABAQEBAQAAAAAAAAAAAAAAAAQDAQX/xAAXAQEBAQEAAAAAAAAAAAAAAAABAwIE/9oADAMBAAIQAxAAAAGmbSadPSZMPIBLBy1//8QAHBAAAwABBQAAAAAAAAAAAAAAAQIDIQAQERIj/9oACAEBAAEFAqOVEql2047LLDc7A+i5H//EABcRAQEBAQAAAAAAAAAAAAAAAAEAEBL/2gAIAQMBAT8BC5jP/8QAGREAAwADAAAAAAAAAAAAAAAAAAECEBET/9oACAECAQE/AW9HSSsf/8QAGhAAAQUBAAAAAAAAAAAAAAAAAQACEBEhQf/aAAgBAQAGPwLBZRa4VFYt5Jj/xAAcEAADAAIDAQAAAAAAAAAAAAAAAREhURAxYXH/2gAIAQEAAT8ho6G+i0ElVBP0c6AzfMaH3OHLLoTIz//aAAwDAQACAAMAAAAQcC98/8QAGREAAwADAAAAAAAAAAAAAAAAABExEFGB/9oACAEDAQE/EGQbRPcf/8QAGxEAAgIDAQAAAAAAAAAAAAAAAAERMVFhscH/2gAIAQIBAT8QuM2dElucejs//8QAGxABAQEBAAMBAAAAAAAAAAAAAREAITFBYXH/2gAIAQEAAT8QEiRCoPrgpVComQJxnQidLfOE1gCkvzQ9j4TPv80LcHh6dw+UV3//2Q==","width":50,"height":50,"src":"/static/8d7223890dda036e0121799406a35506/d2d31/avatar.jpeg","srcSet":"/static/8d7223890dda036e0121799406a35506/d2d31/avatar.jpeg 1x,\n/static/8d7223890dda036e0121799406a35506/0b804/avatar.jpeg 1.5x,\n/static/8d7223890dda036e0121799406a35506/753c3/avatar.jpeg 2x,\n/static/8d7223890dda036e0121799406a35506/31ca8/avatar.jpeg 3x"}}},"headerImage":null},"html":"Today we'll talk a little about how threads work on computers and how to extract more value from concurrent tasks. For this, I will present techniques on how to develop and especially how to test code that uses multiple threads, avoiding the main pitfalls that involve this theme.
\nOf course, along the way, you'll also learn more about Java's Concurrent package, non-blocking algorithms, immutability, and more. However, we need to start by talking a little bit about butter.
\nButter is a product that is part of everyday life for many people. Present in cookies, cakes, bread, sweets, and snacks, as well as other culinary items that make our mouths water just imagining.
\nButter is not recent; we have historical records of its manufacturing process over 2500 BC. Most often made with cow's milk but it can also be produced with the milk of other mammals such as sheep, goats, and buffalo.
\nSalt has been added to butter since ancient times as a method of preservation, but over time salt has lost this importance as the supply chain has become generally refrigerated. Today, so to speak, salt is added only for taste.
\nSometimes food colorings are added to butter, in Brazil, for example, it is common to use Annatto seeds.
\nAnd one thing I really like to eat is bread and butter. In fact, a delicious slice of bread just out of the oven with a little butter on top, which starts to melt on the hot bread. Oh, how delicious!
\nSadly, my wife happens to like hazelnut cream on top of her bread. And this created a problem with our breakfast, now we have to get two knives dirty to apply the toppings that we like. A knife for the butter, and another knife for the hazelnut cream.
\nHowever, our concern for the environment and its natural resources, which are not unlimited, made us rethink this process.
\nLet's turn this problem into a software. After all, Moore's law has given us processors with more and more cores, and as nowadays virtually all computers have multiple execution cores, a computer must be able to simulate my kitchen.
\nFirst, we need a straightforward Bread that takes 50 milliseconds to be ready (what a blazing fast oven, huh!?)
\npublic class Bread {\n private String name = \"bread\";\n\n public Bread() {\n try {\n TimeUnit.MILLISECONDS.sleep(50);\n } catch (InterruptedException e) {\n Thread.currentThread().interrupt();\n }\n }\n\n public void setTopping(String toppingName) {\n this.name += \" with \" + toppingName;\n }\n\n @Override\n public String toString() {\n return this.name;\n }\n}Now we need a naive knife that can apply the topping to our bread.
\npublic class Knife {\n private String topping;\n\n public Knife setTopping(String topping) {\n this.topping = topping;\n return this;\n\n }\n\n public Knife applyToppingTo(Bread bread) {\n if (topping != null) {\n bread.setTopping(topping);\n topping = null;\n }\n return this;\n }\n}We can verify that everything is working using a test. I'm using the AssertJ library, a java assertion library which I do recommend that you have a look on at, as it could enhance your tests and improve readability.
\n@Test\nvoid givenKnifeWhenApplyToppingToThenChangeBreadName() {\n var knife = new Knife();\n var bread = new Bread();\n\n knife.setTopping(\"butter\").applyToppingTo(bread);\n\n assertThat(bread).hasToString(\"bread with butter\");\n}It seems good, lets's see what happens when we are hungry and want 10 pieces of bread made at the same time! For that, we will need a basket where we will put all the cooked bread.
\n@Test\nvoid givenHungryThenCook10BreadsAtTheSameTime() {\n var basket = new ArrayList<Bread>();\n var knife = new Knife();\n for (int i = 0; i < 10; i++) {\n var bread = new Bread();\n knife.setTopping(\"butter\")\n .applyToppingTo(bread);\n basket.add(bread);\n }\n assertThat(basket)\n .isNotEmpty()\n .allSatisfy(bread -> assertThat(bread).hasToString(\"bread with butter\"));\n}Oops!, it worked, but it took too much time. Each bread takes 50 milliseconds to be ready, so now the whole process is taking 500 milliseconds. If we consider the real-world cook time for bread, it could take hours to cook all those pieces of bread like this.
\nI know what to do, we just need more workforce! I will call my wife to help me. As I said, the majority of current computer machines have more than one core, which allows us to work in parallel. Joshua Bloch, in his book Effective Java, warns that we should prefer executors, tasks, and streams to threads, but for simplicity let me demonstrate this problem using threads by hand.
\n@Test\nvoid givenHungryThenCook10BreadsWithMyWife() {\n var basket = new ArrayList<Bread>();\n var knife = new Knife();\n Runnable preparation = () -> {\n var bread = new Bread();\n knife.setTopping(\"butter\")\n .applyToppingTo(bread);\n basket.add(bread);\n };\n for (int i = 0; i < 5; i++) {\n var me = new Thread(preparation);\n var myWife = new Thread(preparation);\n me.start();\n myWife.start();\n }\n assertThat(basket)\n .isNotEmpty()\n .allSatisfy(bread -> assertThat(bread).hasToString(\"bread with butter\"));\n}But wait, the test is failing, what is going wrong?
\njava.lang.AssertionError: \nExpecting actual not to be emptyIt is like the basket is empty, but we didn't change the process at all despite adding the new threads. Yes, it is a common problem that every software engineer faces when starting to work with multiple threads (or multi-thread apps).
\nIn fact, there is a thread that is responsible for running the test suite which executes each step on our test in sequential order. But when we delegate part of the process to other threads, it follows its flow without waiting for them to finish their job. When it reaches the assertion, the previously created threads have not finished creating their bread. That is why our basket is empty.
\nPlease, don't listen to this evil inner thought suggesting that it is just a matter of creating a Thread.sleep() or something like that, so that the assertion waits for the other threads. It will give you a slow and fragile test. On one hand, if you give it a big delay time, it will slow down your tests. On the other hand, with a small delay, the result could vary depending on the processing power of the machine where the tests are being executed.
\nThe answer for cases like those is to use some tools from java's concurrent package. We have to ensure that both workers start to do their job at the same time. As a second requirement, we need that the test thread verifies the assertion only after the job is done by the other threads. For this, we can use a CountDownLatch like those below. CountDownLatch is a synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes. It does it by holding the thread until the count reaches 0.
\n@Test\nvoid givenHungryThenCook10BreadsWithMyWife() throws InterruptedException {\n var basket = new ArrayList<Bread>();\n var knife = new Knife();\n var startGate = new CountDownLatch(1);\n var endGate = new CountDownLatch(10);\n Runnable preparation = () -> {\n try {\n startGate.await();\n } catch (InterruptedException e) {\n throw new RuntimeException();\n }\n var bread = new Bread();\n knife.setTopping(\"butter\")\n .applyToppingTo(bread);\n basket.add(bread);\n endGate.countDown();\n };\n for (int i = 0; i < 5; i++) {\n var me = new Thread(preparation);\n var myWife = new Thread(preparation);\n me.start();\n myWife.start();\n }\n\n startGate.countDown();\n endGate.await();\n assertThat(basket)\n .hasSize(10)\n .allSatisfy(bread -> assertThat(bread).hasToString(\"bread with butter\"));\n}The startGate will hold all threads so that they start virtually at the same time when the test execution reaches the startGate.countDown(). After that, the assertion will not be verified before the endGate reaches zero, which will only happen when all threads have finished their tasks.
\nThe bad news is that we have a problem with this current implementation. If you are unlucky enough (or simply repeat this test a few times), you will face the following error:
\njava.lang.AssertionError: \nExpected size:<10> but was:<6> in:\n<[bread with butter,\n bread with butter,\n bread with butter,\n bread with butter,\n bread with butter,\n bread with butter]>It happened because we are using as our basket an ArrayList, which states in its documentation:
\n\"Note that this implementation is not synchronized. If multiple threads access an ArrayList instance concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally.\"
\nIn other words, this implementation of the List interface is not thread-safe. Once more, to face this issue, we have at our disposal other collection implementations on the concurrent package. Instead of ArrayList, we could use CopyOnWriteArrayList or a ConcurrentLinkedQueue.
\nAs the first one is more efficient in use cases where mutations are less frequent than other operations, let's stick with ConcurrentLinkedQueue.
\nvar basket = new ConcurrentLinkedQueue<>();But as soon as you execute the test repeatedly, you will see errors like those:
\njava.lang.AssertionError: \nExpecting all elements of:\n <[bread with butter,\n bread with butter,\n bread with butter,\n bread with butter,\n bread with null,\n bread with null,\n bread with butter,\n bread with butter,\n bread with butter,\n bread with butter]>\nto satisfy given requirements, but these elements did not:\n\n <bread with null> \nExpecting actual's toString() to return:\n <"bread with butter">\nbut was:\n <bread with null>We should have a problem in another part of the code, could you imagine where it is?
\nThings get worse when my wife starts to make her bread with hazelnut cream:
\n@Test\nvoid givenHungryThenCook10BreadsWithMyWife() throws InterruptedException {\n var basket = new ConcurrentLinkedQueue<>();\n var knife = new Knife();\n var startGate = new CountDownLatch(1);\n var endGate = new CountDownLatch(10);\n\n Function<String, Runnable> preparation = topping -> () -> {\n try {\n startGate.await();\n } catch (InterruptedException e) {\n throw new RuntimeException(e);\n }\n var bread = new Bread();\n knife.setTopping(topping).applyToppingTo(bread);\n basket.add(bread);\n endGate.countDown();\n };\n\n for (int i = 0; i < 5; i++) {\n var me = new Thread(preparation.apply(\"butter\"));\n me.start();\n var myWife = new Thread(preparation.apply(\"hazelnut cream\"));\n myWife.start();\n }\n\n startGate.countDown();\n endGate.await();\n assertThat(basket)\n .hasSize(10)\n .haveExactly(5, new Condition<>(bread -> bread.toString().contains(\"butter\"), \"butter bread\"))\n .haveExactly(5, new Condition<>(bread -> bread.toString().contains(\"hazelnut\"), \"hazelnutcream bread\"));\n}First, notice the use of a new helper method from AssertJ, we specified that the collection should have exactly 5 items that satisfy a condition.
\nThe Condition entity from the AssertJ library helps us to create a whole new set of assertions. If you are interested, please take a look at a delicious example in the appendix of this article.
\nBut let's come back to our bread story. After executing the test now with hazelnut cream, sometimes we face errors that are even strange:
\njava.lang.AssertionError: \nExpecting elements:\n<[bread with hazelnut cream,\n bread with hazelnut cream,\n bread with hazelnut cream,\n bread with hazelnut cream,\n bread with butter,\n bread with hazelnut cream,\n bread with butter,\n bread with butter,\n bread with hazelnut cream,\n bread with hazelnut cream]>\n to have exactly 5 times <butter bread>Why do we have only 3 bread with butter, but 7 bread with hazelnut cream?
\nBefore advancing, let's recap what we have seen until now:
\nMost today's computers have multiple cores, allowing us to get even more value from concurrent tasks;
\nWorking with multiple threads creates some difficulties when we depend on timing to verify our tests' assertions, nothing that couldn't be handled using tools from java's Concurrent package, like CountDownLatch;
\nAssertJ is a java assertion library that helps us to improve our tests also on their readability.
\nWe should keep in mind that not all classes are thread-safe, like ArrayList for example. When many threads will share access to a common collection, we should use one of the thread-safe Collection implementations from the Concurrent package;
\nOk, with all that knowledge in mind let's figure out what is the reason for the weird errors that we are facing.
\nFirst of all, this is a typical symptom of a Race Condition, or more specifically, a Data Race. Quoting Brian Goetz, in the book Java Concurrency in Practice
\n\"A race condition occurs when the correctness of a computation depends on the relative timing or interleaving of multiple threads by the runtime; in other words, when getting the right answer relies on lucky timing.\"
\nOn our baking issue, we have multiple threads fighting to access the same shared property. My wife and I are fighting for toppings at the same knife.
\nIn the real world, one could think of it like this:
\nI get my knife and put butter on that;
\nJust when I leave the knife to take the bread, my wife gets that knife and puts hazelnut cream on it;
\nI take back the knife and, with tears in my eyes, realize that I'm topping my bread with some strange brown cream;
\nNow my wife with her bread in hand stares at an empty knife, trying to figure out who is sabotaging her.
\nNow the fix of our code is just a matter of adding a synchronized block using the knife as the lock. With this, only one thread at a time can take the knife and execute the code inside it. \"Oh! This is the solution for everything, we should synchronize everything!\" Think twice. Synchronization isn't for free; it creates a performance problem, as now all other threads are blocked waiting for the availability of the lock, which in our case is the knife. In our kitchen, we could say that when my wife touches the knife I become blocked, waiting for her. If the phone rings, she should say: \"darling, please answer the phone\". But I will be blocked, I'll not be able to do anything except wait for her to leave the knife. A blocked thread goes to the TIMED_WAITING state, and during this time it can not be used. It is really advisable to keep track of how many threads our applications are using because threads are a scarce resource. But there is light at the end of the tunnel, at least in this concern you should know that Java 19 is coming up with the concept of Virtual threads, in its Project Loom. This new feature will cut the one-to-one relationship between Java threads and OS threads, which means that more than one Java virtual thread will be able to use the same OS thread. With that, when some virtual thread gets blocked by an I/O operation, for example, another virtual thread can perform calculations on that same OS thread. But, as we said, until there we should use our threads with wisdom. \"But, what to do?\", you could ask. Well, if you need better performance you can use Nonblocking Synchronization. Nonblocking algorithms are widely used by JVMs implementations, Operational Systems, and in Java itself to implement locks and other concurrent data structures. Those Nonblocking algorithms are way more complicated to design and implement, but they provide better performance by avoiding the thread block itself and give us other benefits like being immune to Deadlock. To provide a simple example of Deadlock, imagine that my wife and I are in the living room. The remote controller of the TV and the sofa are Locks. To watch TV, a person needs to sit on the sofa and press the button on the remote controller. A Deadlock would occur if I get the remote controller and my wife sits on the sofa. She will be blocked waiting for the remote controller, and I'll be blocked waiting for the sofa. And we will be like that \"until death does us part.\" Let's go back to the Nonblocking algorithm. First of all, we need a way to ensure atomicity to our tasks. And it is possible because modern computer processors have special instructions for managing access to shared data. A common approach is the implementation of the compare-and-swap (CAS) instruction. It guarantees us that the access to the value and its update will occur as a single task. Java's Concurrent package provides us with some so-called atomic classes. Let's take AtomicInteger as an example, its documentation states that it is \"An int value that may be updated atomically\". The following code shows us the same algorithm, but only the last one achieves thread-safe by delegating its thread-safety to an AtomicInteger: And how does AtomicInteger ensure atomicity? Using the CAS algorithm! Its incrementAndGet method executes a code that could be simplified like this: To start, it gets the current value and stores it in a local variable. Then using the compareAndSetInt method it first checks if, at that precise moment, the current value is the same that was earlier fetched. If it is so, it proceeds with the update and then returns True. If the current value was changed by another thread, the compareAndSetInt method returns False and restarts the process. It is worth saying that the compareAndSetInt method is a native method, which uses the most efficient instructions provided by the underlying hardware. With this new knowledge, what about trying it on our bread? Let's remove the blocking synchronization and create the faster bread with butter that a computer could have (and some with hazelnut cream too, for the sake of my wife's happiness). We can do this using an AtomicReference. Of course, we did that after removing the synchronized block from our test. Good, fast, and easy, and without thread blocking! But, please pay close attention to this piece of code. We have some problems there as it is some kind of adaptation of the canonical CAS algorithm. The hard part of building nonblocking algorithms is to isolate the shared memory into an atomic single change. But in our baker issue, we have a two-step action: first, we set the topping to the knife, and then we add the topping to the bread. So we have two states to keep track of: the knife and the bread. As we said, this code works and does not block the thread, but doesn't give us all the advantages of the CAS algorithm, because we still can have a Livelock issue. A Livelock issue can occur even when the thread is not blocked, if it is waiting for an operation that will never succeed. In our code, we used the topping value as a kind of lock. The first thread that moves it from null to another value, it will put all other threads waiting for that value to become null again. It works, but if any thread fails to add the topping to the bread, which moves the topping value back to null, all the other threads will be waiting forever. The control mechanism, when more than one thread fights for the knife topping, is done by retrying again immediately, like in the CAS. But the canonical CAS will not fail indefinitely if any other thread fails. It will just finish its job as soon as no other thread touches the shared memory when it is still working. \"So, what to do!? I'm reading this to find answers, not questions!\" Ok, I'll let you know. The other side of the coin, in the context of thread safety, is Immutability. If we use an immutable object, virtually all problems with atomicity are gone. That's because all problems that we are facing here are based on threads fighting to access the same shared memory. If the memory that they want to access cannot be modified, those risks are gone and thread safety is achieved. We can summarise that an Immutable object is one that can't be changed after its creation. Java introduced the Record, which is a simple way to create immutable objects. We just need to provide the type and name of the fields. The public constructor, equals, hashCode, and toString methods, along with the private, final fields, are all given for free to us, by the compiler. Take a look at the following code: Some could argue that immutable objects are a waste of resources, but it isn't true in the majority of cases. Dealing with immutable objects offers us performance advantages when it frees us from using synchronization or creating defensive copies, it even reduces the impact on generational garbage collection. But talking about defensive copies, is the record really immutable? Look at this test: This task will fail with the following log: We have to keep in mind that in the way that we created the Parent record we have kept a reference to its internals. A record is still unmodifiable, but to achieve immutability you have to avoid exposing its inner state. In our example, we can avoid that by overriding the constructor and coping the list of children's names: Now the test is successful, but we are still publishing the internal state of the record. The getter method for the property childrenNames is publishing the reference to the record's inner state, allowing it to be modified: This code will fail as well: To avoid that you have at least two options: override the getter and return a copy of our list, or the one that I prefer: save our internal state as an unmodifiable list: Like this, every time someone tries to update our inner state, they will get a UnsupportedOperationException, which I believe is what we should expect from trying to modify something supposed to be immutable. What we have seen so far? We learned more about Race Conditions, in real life and in the software, and the main solution tool from Java: the monitor pattern, using the synchronized keyword; After understanding the downside of locking, we were introduced to the compare-and-swap (CAS) nonblocking algorithm, which despite being hard to develop can lead us to better performance and protect us from Deadlock For the cases when we are unable to isolate our shared memory, or even in other scenarios where we just need more protection, we talked about immutability and how immutable objects can grant us thread safety. We then revisited the java Record, which is a fairly easy way to create an immutable object, but that is not immune to bad programming technic. To really achieve immutability in our objects we saw how we should avoid publishing its inner state. Oh, it was an amazing journey, we started with a brief introduction about threads, how to properly test them, and we met some new friends from Java's Concurrency package. With new algorithms and tools under our belt, we are ready to travel to the multithreaded world riding our thread-safe software. I'll now eat my bread with butter, see you soon! Baking delicious cakes with AssertJ's Condition entity: In this blog post I want to emphasize how important the process of exceptional software delivery is. I’m going through all the steps used by AUTO1 to achieve the best possible implementation in software development. All in all, there are 5 steps that require a clean and effective implementation: The Aggregator Pattern is usually a standalone microservice. It offers a uniform API that a client can use to access data from different microservices. This composite service is utilized when we need to prepare the result data produced from the outputs of several microservices. The aggregator pattern is designed to combine data from several endpoints and provide it as a single endpoint to the client. If necessary, it can also cache that data according to predetermined criteria or rules. You can read more about this pattern here: https://www.edureka.co/blog/microservices-design-patterns So to sum up, we can simply execute two or more api requests to separate services and accumulate the data we need to show the results in the list. This sounds good, except for one drawback: Performance! It is at the expense of performance. One more way to enhance this behavior is by using asynchronous api requests, which basically execute these multiple api requests in parallel. However, it does not provide the best performance (depending on the use-case, it was not an option for us). Since the data like VIN, stock number, etc. will not change in the future, importing fixed data to the service database sounds very suitable. So the key message here is: don't rely on sending synchronous queries to obtain data that was previously controlled by another microservice if your primary microservice requires it. Instead, use consistency to duplicate or propagate that data (just the properties you require) into the other service's database. The only data that changes over the course of a refurbishment is the state. For syncing the refurbishment state, we used asynchronous messaging. Every time the initial state of a refurbishment is changed, a message will be produced to SQS (Simple Queue Service). From there, we can easily consume that message and change the state in the new microservice. To provide a fast search, we added an index only to the state field, since too many composite indexes can have degradation on insertion, deletion, and updating performance. The Data Manipulation Language statement has to modify the table data and the indexed data too, which might decrease the performance depending on the amount of data. We have slow query alerts in place, so we get notified when it might be time for an investigation to improve the performance. Event sourcing is a way for an event-driven microservice to respond to events in order to carry out its tasks. A higher-level operation is performed by a number of these services interacting with one another in an event-driven architecture based on messaging. The interaction usually consists of a series of messages taken by the various services to handle, for e.g. state changes. Messaging at AUTO1 works in the following way. Every service that publishes messages must specify the SNS topic to which it intends to deliver those messages. Topics are bound by message type, so if the message type is So to keep the state changes updated, we created a Message Listener that listens to state changes and updates the state. A message producer for the state changes was already in place since several other services needed to consume this message as well and make their own updates. Feature flags can be helpful in a variety of situations. It's essential to understand that feature flags can be used to configure a wide range of application components. Some feature flags are used to run specific parts of the application, and some feature flags intentionally prevent that. Additionally, feature flags may be applied to the frontend and/or backend. Enabling or disabling features for individual parts of an application is a common use case. The strategy we usually apply is to enable features for specific car repair workshops using a feature flag. That way, we can steadily monitor for errors and let the feature evolve so it is ready to be rolled out to all the other car repair workshops as well. For some features, it might be needed to backfill data to pre-existing entities to support the feature in earlier refurbishments. Quality assurance is an essential part of software development and therefore should ideally take place not only at the end, but throughout the development process. If you want to create good software, you should include software tests in the development process from the very beginning. Here are three reasons for the need of good-quality testing: A high-quality user experience is guaranteed by quality assurance Quality assurance saves time and money More security is provided by quality assurance To improve the quality of an application, you need monitoring. Application monitoring helps developers to locate bugs easier and speeds up the development time. If application monitoring is ignored, it could lead to unexpected crashes or poor performance that would cause significant harm to the company. It can enable engineers to gain insights into how their systems will behave. This information enables them to identify issues or flaws while they are still small enough to be handled with relative ease. At AUTO1 every new service has its own Grafana monitoring dashboard to provide several key metrics like: With over 400 locations across Europe, managing our network devices has become a big endeavor. In order to be more efficient on this challenge the Corporate IT Network Team recently implemented Unimus. Unimus does network automation, configuration backups, change management, updates and enables automation for all the processes. This also benefits the engineers not to work late hours or on weekends. To provide an example, here is a quick overview of how we upgrade our MikroTik routers using Unimus, which are located at our Autohero workshops all over Europe: When a software-based company grows, it creates lots of new code, which means multiple engineers may be facing the same problems across the whole platform. They will usually come up with various solutions to fix it. Some of them might be generic and reusable, while others will be tailored to one’s needs. As it usually happens, the solutions will then be bundled together to create libraries. This is very good, up to a certain point, since over the years, engineers will create them by the dozens and this, in turn, will bring about other hurdles such as: This was quite a big pain point for AUTO1 software developers as we have 60+ common libraries that need to work perfectly in 600+ production services across multiple business units and products. One simple mistake, for example, a wrong configuration change leftover after a debug session can end up in disaster. Enabling protection against direct commits for main branches will address the first hurdle - only pull requests with double approvals and tested by CI can be merged. The next 2 issues are more about ease of usability for the developers, as they might be reluctant to upgrade their service if the process is troublesome. So, in the best-case scenario, our end-user should periodically update only a single property. In addition, our common library developers need to be able to easily publish their changes. The solution to it was the release trains, usually known as BOMs or for AUTO1 developers, service-commons-dependencies. After successful implementation, you will just need to trigger CI build to get the newly released version, which in turn can be pasted into a pom/gradle file. So, right now everything looks good, but can we be 100% sure that our changes are going to work? Perhaps there is a very small bug in a messaging lib or we will lose tracing for incidents. That’s unacceptable. So let’s ensure that will never happen by introducing automatic real use case testing. In our approach, we thought most of the problems could be revealed by running extensive integration testing. The test harness probably catches all bugs in our codebase and simply fails when needed preventing the release of a buggy version. But no matter what you do or how extensive your tests are, you are never going to be able to perfectly mock the production environment. Enter the End to End testing of newly released To get it done, we need CI pipelines that will automatically test our new versions of release trains that are triggered either manually or automatically every week. All tests need to be as close to the real-world scenarios as possible. A practical solution is to create a new service that will include all of the most popular use cases of the aforementioned libs. Then we need to deploy it to all of our environments - as previously mentioned there is always something different between local, QA, and production environments, so we need to cover them all. The tests must be the same for all environments. But the trigger may differ - for example, we are using our test environments to prepare new releases for production. The following diagram illustrates the basic principle of how it should work: In our implementation, we chose to use Jenkins with JobDSL pipelines and Groovy for scripting. The first stage of the E2E process is checking whether a new version of service-commons-dependencies exists by using the maven versions plugin: To check for any changes: If nothing new was found let’s just abort the pipeline and wait for another CRON or manual trigger.\nIn case a new release was found, we need to build it, deploy it, and run E2E tests.\nIf there are no failures the pipeline will create a new core-test-service release.\nFor those cases, we are using parameterized jobs, for example, to trigger the E2E tests we can use the following commands: The new release will be picked up by the production pipeline by checking the latest tag creation time in our repository: If the release of core-test-service was created within the last 2 hours we will deploy it by triggering another pipeline. As the last step, it will run E2E tests. As mentioned above, both testing environments will use a shared codebase for acceptance testing. It can be done by setting up one extra job that will fetch an external repository using this block: We chose Cucumber as our main test framework since it will give us unparalleled leverage compared to other choices. Tests are written using natural language in a way that allows for troubleshooting to be done basically at a glance. For example here is the scenario that tests the libraries responsible for sending messages in our platform exposed via HTTP endpoint: The above, combined with this generated report, is a joy to work with.\n Furthermore, we decided to create a dedicated slack channel to notify us about the new releases and test results. So after getting this message We can finally get our much-needed stress-free beauty sleep, not that it will help us much, right? Hopefully, this small article will get you in the mood for some nice automation work in your company. Have fun and enjoy your peaceful nights. Let's talk about harmony! If you have a look at an English dictionary, you'll see that even though almost everyone has some knowledge of the meaning of the word harmony, it's not so simple to properly define it. There are many contexts that it may apply, such as people relationships, business, law, and so on. But, at the end of the day, this concept imported from the music means that something happens in a way or frequency that makes it pleasant and less error-prone. So I want you to focus on the idea that the proper frequency is a way to achieve harmony. There are some cases where you would like to limit the frequency that something happens to it work properly. Imagine that you have a coffee machine, it's obvious that you would like it to dispense coffee at a frequency that you can replace the cups and be able to serve all your guests. It happens everywhere, even on software. At least while we have limited resources, we have to orchestrate them to work in harmony. One strategy is to use Rate Limiters, a maneuver to control the frequency in which some action is handled. A common pattern to achieve the Rate Limiter strategy is to use the Token Bucket algorithm. In a nutshell, the Token Bucket mimics a real bucket where Theme Park tickets are stored. To enter to play around at the Theme Park, you need to take a ticket. But if the bucket is empty, you have to wait until some new tickets are put in there. Doing like that, you become able to control the flow of people to the Theme Park by controlling the number of tickets that are put into the bucket and the time interval in which the refill occurs. If we put 10 tickets per minute on that bucket, it'll assure that at most 10 people will enter the Theme Park in each 1-minute interval. Libraries like Google Guava, Resilience4j, and Bucket4j are examples of how we can achieve rate-limiting in our Java software. Despite being a beta version by the time of this writing, using the Google Guava RateLimiter library is pretty straightforward. You create a RateLimiter object defining the number of permits per second and, for each task, you specify that it should \"acquire\" the token that allows it to proceed. For Resilience4J you need to create some configuration before and decorate your task: In the same path, now using Bucket4j, you need to specify the refill interval and the limit: But if you want that the employees from the theme park's main entrance do other tasks while the customers are in the queue and still not allowed to enter, I mean if you want that your thread is used for other tasks, at least these 3 libraries have a pattern that may be a problem to you: they block the thread. Now we are in the second part of this article, and as we are talking about Threads, it's good to know some basics about them. The first step is to know that they allow us to work concurrently, two tasks running virtually at the same time. But Threads are notoriously complex and error-prone, inaugurating a new sorts of problems like Deadlock, Race Condition, and so on. As we said at the start of this article, considering that we have limited resources, we have to use Threads with wisdom and be as clever as possible. If I and my wife are in the kitchen and we have just one knife available, it is appropriate that once one of us stop using the knife we leave it available to the other over the table, so that the other could start working with this piece of cutlery. When one forgets about this rule, the other one is kept waiting for the tool, and important work is not held, preventing the flow of a harmonious cuisine. The computer environment works like this kitchen, we have a limited number of Threads. And when something blocks one thread with a Thread.sleep() or LockSupport.parkNanos(), this Thread goes to the TIMED_WAITING state and during this time it can not be used. It is like the unused knife in the cooker's hand of an unharmonious kitchen. In practical terms, consider the following code: It will output as follow: What we wanted was that our 4 tasks were completed in a frequency of at most 2 for each second, but the Rate Limiter also has blocked the other tasks. You may ask, what to do? Perhaps, we should schedule instead of blocking! Imagine when you need to go to the doctor. Unless there is an emergency, you will likely have to make an appointment. The schedules are spread in a timeline, considering the doctor's ability to do the entire checkup: anamnesis, some additional exams, and so on. So to say, if the doctor takes an average of 30 minutes to attend to a patient appointment, those appointments should be guaranteed in intervals of 30 minutes. With this in mind, we could refactor our previous code. If we need that our tasks are executed at a rate of 2 per second, it means that we should schedule our tasks for every 500 milliseconds, which is one second (1000 milliseconds) divided by 2. Now that we know our interval, we have to find a way to keep track of our \"appointments\", to avoid scheduling more than one task to the same interval. Let's use an AtomicInteger class for that. Let's scratch some code: It will output as follows: Oh, it worked, but seems like we are cheating, because we just added a new thread to the game. How can we know for sure if that new thread is not being blocked? Well, we can test it like this: And voilà: The downside of this approach is that the ScheduledExecutorService, that we receive from the newSingleThreadScheduledExecutor() method of the Executors class, uses an unbounded queue. This means that no task will ever be rejected (by the meaning of the unbounded word, it is like an unlimited queue), and because of that, we have the risk of consuming too much memory if we receive tasks more quickly than we can handle them. Of course, we can avoid that in many ways. One approach could be to track the number of scheduled tasks and reject new tasks if we hit the specified threshold. First of all, let's refactor our code so that we use a queue of tasks as the source to be used by the scheduler. Our log: Now in this version, we are using the scheduleAtFixedRate() method, which frees us from keeping track of the already used intervals. It now checks for new tasks for every expected interval. But what would happen if we have more tasks coming than we are able to handle? The following code creates a new task for each 250ms but handles new tasks just in an interval of 500ms. Our output would be something like this: The size of the queue will not stop raising, leading us to an out-of-memory error. Oh, but don't be so afraid my friend, as we said we can limit the schedule based on that queue. Like if you call the doctor to make an appointment and they answer you: \"sorry, for the next 10 years all our schedules are already taken, please call in another day (or year).\" Our output: Here we have to talk about backpressure. Remember that this problem about memory only occurs if always the input of tasks is faster than the output. If the input of tasks was faster in just a point of time, this surplus of tasks will be kept on the queue and properly handled in the following time. So with this approach, our application could control the rate of events so that fast producers (sending new tasks) does not overwhelm our consumer. In a blocking approach, the producer will be forced to wait. In the scheduling approach, the new tasks will be handled in time, and only if it overloads that some of them will be queued. You could say, but how long should be my queue? Well, I may say that it depends on your use case. A doctor could have a schedule book for all the current year. And if it shows to be not enough, the doctor can buy a new schedule book for the next year. As in your application service, if you can afford more memory, your queues can be as long as you want. But in the case of a traveling circus, if it will be in the town for just 3 weeks it doesn't make sense to accept schedules for the next month. The same as your application, if its capacity of handling tasks isn't fast enough at a point that the handling of an older schedule task starts to become unmeaningful, you should shrink your queue. We can conclude that scheduling is a good approach for rate-limiting without the downside of blocking the thread. It gives us the opportunity of controlling the flow of incoming tasks, queueing peaks, and always handle the tasks in harmony with all other components. If you are already familiar with MDC (Mapped Diagnostic Context) you can go to the next section of this article. If not, please take a look at this first to get a better understanding of what MDC is. In one of our services we had an endpoint responsible for invoking process related to car auction with a lot of logs for debugging purposes. We already had a request-id to trace it in Kibana, but we wanted to filter logs in a more convenient way, by value that we know even before invoking this endpoint which was the stock number of the car. So we decided to use MDC as it allows us to add diagnostic key-value pairs to every log in given Thread. Although MDC is a great tool, it forces programmers to write clunky code due to the fact that every key-value pair that was set should be cleared, otherwise in some edge cases it could be used by another thread. Clearing can be done by invoking MDC.clear() or by MDC.remove(key). First one clears all MDC keys so we could accidentally remove keys that were set higher in stack. Second one is better then but it has to be invoked for every key. And also in both cases it should be done in finally block to be sure that no matter what happened, context was cleared. MDC also has To stand against MDC drawbacks, we came up with this functional style solution: At first glance we can see that there is no Try Catch block anymore and we are only setting key-value pairs and not clearing them, however everything works exactly the same. So how is it done? Solution is pretty simple. It is based on a container class for storing MDC context keys mixed with Step Builder Pattern. Let's take a look at implementation. LogContextSteps is a wrapping class for two step interfaces: ContextStep which contains method for adding new log key-value pair ExecuteStep which also extends ContextStep and serves execute method responsible for invoking action that we want to wrap with MDC. implements interfaces from stores MDC keys in executes action that we want to wrap with MDC context For testing purposes there are some package protected classes and methods like So, how does this flow work? We begin with the static factory method MDC key is stored in Finally we can invoke Assuming that we have an ELK stack for monitoring and proper log configuration we can go to Kibana to find interesting logs via our MDC key-value pairs. Depending on the log configuration, key can be directly accessible or under the flat field (which was in our case) For key-value pair: stock-number - SN12356 Kibana filter may look like this: Hello everyone, my name is Ihor Sila and I'm a Senior Software Engineer in AUTO1, with over 6 years of developing experience. When I joined AUTO1, I received my laptop and I found out that it's a new MacBook Pro with M1 processor and I believe that's really great, because I've read a lot of articles about this chip's performance and comparisons with Intel i-core series. However when I've tried to build microservices that my team presented to me, I found some unusual situations with tests, which are working with embedded libraries such as redis and postgres. When I've run first time integration-tests that using embedded-postgres library, I've got next exception in stack trace: With the postgres problem, the solution was pretty simple and after I found it in our Slack channel I applied it and it solved the problem. So, when you are setting up your Mac, please check the environment variables and switch locale to en_US.UTF-8 from default one, because the embedded postgres library tries to start its library with a different locale and has problems with the process id. Another solution is to increase the size of a single shared memory segment a Linux process can allocate. So the commands in terminal will be the next And that you should restart your MacBook to apply all settings. After that the problem should gone. Moving on to redis, the problem was that it was newly added to AUTO1. So, from a code perspective everything is fine, but when you try to run the integration tests that are using embedded redis, they just won't be executed, because redis doesn't want to start. There is some exception log that you receive but that's about it, nothing special. When I've tried to debug the library code, it also appeared fine from a first look, but when I've debugged the stack trace of the startup, I've realized that this old version of redis doesn't know anything about the new M1 architecture and that macOS can be built on something different other than an Intel chip. Basically, old redis library only knows that macOS can be either x86 or x86_64. After a thorough investigation, I realized that there is no solution yet and repositories that provide embedded redis solutions haven't updated their libraries so far. The solution to this problem consists of two parts: To solve the first problem, I thought that I could just download the latest redis-server, then get the application file from the library folder and replace the old app file with the new one. Soon after the first try I've realized that my solution will work only for M1 chips, therefore no compatibility with the Intel chipped Macs. I've dived deeper into the redis library to understand how it knows which architecture (x86 or x86_64) it needs to use. The solution was pretty simple, it just executes the command to get system flags and then analyzes these flags to see which version to use. When I executed the same command on my local machine, I realized that on M1 architecture some new flags were added, which represents that the current architecture is written with a new chip. In embedded redis you can tell redis to use another embedded redis application, but not the solution from the library. If you execute next command at the terminal, you will found extra flags for AMD architecture: But if you will execute the same command on Intel-based architecture, you will see another flags, that are specific for Intel architecture: After realizing that, we created a class so that we can tell the library the fact that if the OS is macOS, then it needs to analyze the system flags. If it will find M1-specific flags (which are not present on Intel architecture), then use the latest redis application file which can be executed on macOS with M1(AMD) architecture, otherwise use the existing solution, because it's working on macOS with Intel processor. We also should store this application file in our resource folder, so in that case new developers can just download the source code and the redis application file will be already there. We've tested this approach on our microservices and it's stable. As for now, our core-team already replaced dependency from old embedded-redis to new one and it's working for both Intel and AMD architecture without additional changes. Thanks for reading! Hello fellow concerned developers, or, if you are not yet concerned, while it is not the crux of today’s entry, I hope\nthat by the end of it, you might get interested in becoming one and/or find out how you could do that on your own and\nwhat it actually means for us. Still, the focal point of this post is to fill you in on the architecture of Application\nCockpit (or “App Cockpit”, as we call it in private), the newest tool AUTO1 has brought in for its concerned developers. The “why” However, before dwelling on the “how” too much, let us pay homage to propriety and start with the ‘why’ of the whole\nmatter. The main reason for the emergence of the Cockpit stems from the plethora of tools AUTO1 has adopted to help us\ntrace, measure and monitor our services, not to mention alerting us when things go south. This opulence often means that\nif you are looking for a specific bit of information, whatever the reason, chances are the data is there somewhere, but\nyou need to make a significant effort finding out where to look for it first. To achieve all that, the Cockpit needs to pull data from multiple sources, aggregate it and present it in a comfortable\nand meaningful manner to the users, not to mention being fast and efficient about it, which leads us to the heart of the\nmatter - the architecture of App Cockpit. Finally, the “how”…. When designing App Cockpit, we were striving for what probably every software engineer worth his hide can recite even\nwhen woken up at 4 am in the morning - we wanted the architecture to be “open and easily extensible, yet simple and\nrobust at the same time\", preferably allowing polyglot extensions to let every team in the company contribute and share\nwith others if they came up with a cool feature. In order to achieve this, we have split the Cockpit into 5 logical\ncomponents distributed in 3 different layers, as depicted below, with the descriptions to follow. Data Collector - the component responsible for fetching data from multiple external sources, parsing, aggregating,\ntransforming and sending it on its way to the data sink with a tiny stretch it might be called the ETL of App Cockpit Data Sink - a simplistic component with a one-track mind, whose only job is to receive data in a well-defined\nformat from the Collector, occasionally perform some simple and generic operations on it (like basic validation and\nparent id resolution) and persisting it in the data storage Data Storage - a simple storage that holds the current snapshot of App Cockpit data Data Provider (aka Backend For Frontend) - exposes an interface to serve everything our UI needs, both serving the\ndata “as-is” from the storage as well as applying some additional logic to further aggregate and transform it for\nspecial purposes UI - yer plain old Front-end - by design contains no logic, it only displays the data as provided Sweet, but how about a model? The specifics of the model run outside of our scope, however, getting it wrong could severely hobble the architecture,\nso it is a story in and of itself, which will have to wait its turn to be told in another blog entry. For our purposes,\nwe will only briefly touch upon it, mainly to establish the domain. Truth be told, App Cockpit is pretty much a simpleton, since its world consists of only two kinds of things: Readings\nand Resources and everything it does revolves around the pair. Data Collector - it is the only component for which the logical diagram differs from the physical one, albeit by\ndesign. This stems from the fact that the Collector has been meant as the main extension point that other teams,\npossibly using disparate stacks, can easily plug into when adding new features. By all means, a Collector, as previously\nstated, is any component that fetches data from an arbitrary source, transforms it into Resources and/or Readings and\npushes it to the Data Sink SNS topic. In consequence, when you want to start collecting a new type of data or start collecting it from a different source, you\nhave two options - either add your implementation in one of already existing collector services, or write your own new\none, and the only requirement we superimpose on you is that when you publish to the Data Sink, you follow the format we\nhave specified. At the time this post is being written, we have 3 distinct Data Collector implementations: Main Collector - a general-purpose collector, written in Java and providing data for cross-platform features,\ne.g.: service ownership incidents Docker images used and their vulnerabilities service health and deployments currently running instances code insights (quality, PRs, contributors etc) Java Collector - yet another service written in Java, as the name suggests it collects data strictly related to\nservices written in Java, e.g.: runtime information like JVM and GC being used selective list of JVM parameters passed to the instances egress dependencies for Java services (in this context, the upstream services) PHP/Golang collector - the first contribution coming from outside the original App Cockpit team, written in\nGolang, it is going to provision data for PHP and Golang services, e.g.: egress dependencies vulnerabilities possibly many more to come With a picture being worth a thousand words, let’s have a look at a diagram that gathers all of this in one place: Obviously, the actual process of data collection, as it is currently implemented, is a whole story in and of itself,\ndeserving yet another dedicated blog post, especially since we have elected to make all the collectors stateless, which\nhad its numerous consequences and challenges so keep your eye out for the next entry which is bound to come shortly. Closing words and … we will be back Having said, or rather written all the above, we sincerely hope that we have managed to pique your interest. Not only in\nour solution but also in actually getting “concerned” about your ecosystem, because it does not necessarily have to be\nboring, especially when you have the right tools to make your life easier. On top of that, you can have your fun\nbuilding the actual tools, deftly combining business with pleasure for a change of the usual pace. As hinted numerous times, this is only the preliminary article, meant to lay the groundwork for future additions\nexploring individual pieces in more depth… We are already looking forward to writing those, so keep your eye out! The AUTO1 microservice landscape is growing in size day by day, with new services from a spectrum of languages being erected and usually communicating with each other by using REST contracts. In a fast paced environment, such as AUTO1, often the service providing the REST API and the service consuming this REST API are developed in parallel, by independent teams. On top of that the business requirements over the lifetime of a project evolve, thus impacting the stability of the API. Having these moving parts in picture can make the development process quite challenging, especially when aiming for high productivity, zero downtime and independent development of the client and server parts. Hence, having a clearly documented and language agnostic API is vital for the success of the whole process. After extensive research, we found a great candidate seemingly accommodating all the aforementioned requirements - OpenAPI. In short the OpenAPI specification defines a language agnostic standard allowing to describe REST APIs in a human readable form, imposing a unified structure, clearly and comprehensively aligning expectations between the consumer and provider sides. Below is an example of such an API described using the OpenAPI 3.0 standard: In general, we distinguish two approaches when developing APIs. The code first approach, which is basically about developing the source code fulfilling the business requirements and afterwards, optionally, generating the API specification from it, which for OpenAPI can be done using the swagger annotations. The second approach known as design first, is all about describing the API in a human readable language first, by using for example the OpenAPI specification, and then optionally, based on this artifact generating the source code for server and/or client. Naturally, both approaches come with pros and cons. As previously mentioned, in AUTO1 it often happens that changes that are being introduced in the API on the server side need to be implemented at more or less the same time on the client side. In such a situation, if the code first approach would be practiced, the consumers would need to wait for the server side implementation to be delivered before starting their part, that would be simply inefficient. Here, for the rescue comes the design first approach, where from the moment when the API specification is agreed upon, both server and consumer side can kick-off their side of the implementation, independently. Additionally, this allows to spot misalignments already at a very early stage, and rectify them before the actual implementation from either of the sides is started, hence less expensive to fix. The OpenAPI comes with a rich ecosystem, from UI tools such as Swagger UI allowing to visualize and test ad-hoc the specifications to AWS integration providing a fast lane to expose the specification via AWS API Gateway. Another very helpful set of tools are the code generators, that can generate client side libraries and server side stubs from the OpenAPI definitions. These extendible generators support a variety of languages and frameworks, which lets one move faster, especially in a polyglot microservice environment. For our Spring Java applications we have decided to go for a generator that is very well configurable and easily customizable. It can be executed in various ways such as via cli, maven/gradle plugin, etc. Since our Java projects use maven for the build automation process, the maven openapi generator plugin was the natural choice for us. Despite the vast configuration possibilities offered by the OpenAPI code generators, in order to integrate OpenAPI into our AUTO1 development world seamlessly and make the generated API and models classes adhere to our coding standards we needed to extend the default Spring generator that we’ve decided to go with in first place, to include some AUTO1 specific code structures. To be more productive, concise and spare some boilerplate code we use in AUTO1 the Lombok library, a lot, hence we couldn’t afford not having the Lombok annotations included in the generated classes as well. To follow the OpenAPI generator practices, we have added a configuration property to control enabling and disabling the usage of Lombok annotations: The above setting would result in generating the following annotations in the output classes: Sometimes the need arises to define custom annotations but only on some specific classes, for that purpose we have introduced a new attribute to our OpenAPI specifications called x-extra-annotation, that hints the generator to add additional annotations to the generated code. For example: The above attribute would result in generating the following annotations in the output classes: Generics is a very powerful feature that is available and widely used in the Java language for almost two decades now. Unfortunately, as of the time of writing of the article the OpenAPI does not support out of the box inheritance together with generics. To make it available to our developers we have introduced yet another attribute in the API specification named x-make-parent-generic specifying the genericType sub-attribute that indicates a generic type of the parent class (in this case PageDTO): The above attribute would result in generating the following generic parent in the output classes: As mentioned at the beginning of this article, our Java services are using the Spring Cloud stack with declarative Feign REST clients, originally the Spring Cloud Netflix Feign module was used for that purpose, however, with recent upgrades to newer Spring versions it was replaced by the Spring Cloud OpenFeign module that resulted in changes in the imported packages (import org.springframework.cloud.netflix.feign.* was replaced with import org.springframework.cloud.openfeign.*). So we ended up in a situation where services use either the old Feign clients (located in their respective packages) or the new ones, yet share the same OpenAPI specification. To support both cases we made it configurable for consumers to go with either one: Another shortcoming of the default OpenAPI Spring MVC generator was the lack of support for making the generated classes implement specific interfaces (using the “implements” keyword), as of version 4.3.1 only the “extends” keyword was supported. We have overcome this limitation by introducing a custom attribute x-codegen-implements allowing us to specify a number of interfaces the generated class should implement. The generated output for the above configuration can be found below: Teams often run into the situation where they have to use multiple OpenAPI specifications to generate the necessary contracts to communicate with the upstream services. Unfortunately, the org.openapitools:openapi-generator-maven-plugin requires a separate configuration for each specification, which was a bit too verbose and too cumbersome for us. In order to circumvent this issue we have created our own maven plugin The main aim of it was to reduce the boilerplate configuration, yet keep the flexibility of the original plugin: When dealing with a large number of microservices a common case is that they share common features, hence common models, within a single bounded context. In a typical Code First approach operating in the Java ecosystem this problem would be solved by sharing a common jar which would be then included by the interested parties. We were interested in achieving similar functionality but from the OpenAPI perspective. We achieved this by simply extracting part of the common functionality into separate specification files and referencing them from the individual OpenAPI specifications that would like to reuse these definitions. The challenge in having OpenAPI specifications referencing other OpenAPI specifications was the dependency management and versioning part. It was especially hard from the consumer perspective, since consumers would need to include both specifications in their respective versions (the referencing one and the referenced one) in order for the code generator to succeed. The solution for this was building API bundling, by adding to the specification a meta attribute called x-bundle-apis we could make all referenced definitions to be included in a single final artifact that was then uploaded in the CI pipeline to artifactory. This meant, from the consumer perspective, that they just needed to include a single dependency now, making their life significantly easier. By default, when bundling the API we’ve always included the latest referenced specification. Since we have had cases where we wanted to give more control to the API owners to specify which concrete version of a “common API” they would like to reference, we’ve included another attribute x-bundle-imports which could be used as following: Despite the vast number of improvements we have already made in order to retrofit OpenAPI and its tooling into our existing AUTO1 ecosystem and practices, there is still room for improvements. Just to name a few. Although OpenAPI specification itself is language agnostic, we have language specific generators which in some cases need to be instructed on how to generate the output code, and unfortunately these generator hints often make sense only in context of a specific language. As an example, instructing the generator to make the generated Java classes implement some specific java interface. Since the OpenAPI specifications are enriched directly with these hints, it results in obscuring and cluttering the contract definition. Yet another challenge would be to generate more complex classes resembling the structure as seen when written manually in the times from before the OpenAPI approach was adopted. As presented in the article, OpenAPI is a very powerful tool that enabled our AUTO1 organization to move forward faster in a more structured and unified way in terms of defining and evolving the REST APIs. It’s not a silver bullet, as the design first approach and the OpenAPI specification come with a number of challenges by themselves. However, with the talented engineering force we have we were able to resolve most of them in an efficient manner, yet every organization planning to adopt this tool needs to weigh in the benefits and the shortcomings and make the call for themselves. BACKGROUND This post is in addition to the previous article about plugin development but with a focus on UI based plugin implementations. Sometimes it can be really useful to have an UI and make it possible to interact with it by doing some checkboxes selections or maybe to have some input areas for text. Let's investigate how to develop a simple plugin with input text area as input entry point and some new generated classes, based on input text as a result. As a source code example we will have a look at source code based on my pet project that also was used as a development tool in AUTO1 to generate non GraphQl based POJO classes. USER STORY As an Android developer I need to interact with backend data. It can be usually presented as JSON data or if we can speak about new and modern practices it also can be presented as a GraphQl scheme. GraphQl is a really powerful framework with its own classes generation framework. But let's go back one step and imagine that we have to do some data presentation classes updated for the project without GraphQl support. To do it, we need to find the target class, compare its fields with new JSON fields and update it. It can be easy if we have only one field changed, but for multiple inner fields and classes with its own inner fields it can be too complicated. We can find some online services to convert JSON to POJO and copy/paste output files, but let's try to integrate this technology to our IDE! And our job will be only to copy/paste new JSON to some window input field! Like this one: To make it possible, let's think about our problem and try to do small decomposition into logical steps. Lets formulate our goals by imaging simple user stories: As a user I want to input JSON text into the input field. As a user I want to transform JSON text into POJO files. As a user I want to see the result notification. We will skip JSON to POJO transformation for this article, but we will learn how to develop a plugin with required user interface. Let's think about option number two as about some library that we already have and can use as a part of our small project. TECHNOLOGY STACK Before we will start let's have a look on basis plugin implementation. There are 2 base options to develop new plugin: We will speak about gradle implementation. Gradle is a really powerful framework and it can be really helpful if we want to simplify our building, releasing and testing. The project structure is a common structure for gradle based projects: Most important topic for us will be the plugin.xml file. We already discussed some details in the previous article and we can be focused on some UI related topics. During the plugin development we can use Java/Kotlin and all utility tools that we want like jUnit testing and dependency injection frameworks. In our current example Koin and JUnit can be found. So, now we have and know about project structure, some utility tools, language to write the code and now we are ready to think how it can be possible to create a user interface and connect it with our IDE. Let's remember about our major goals: GOAL 1 - As a user I want to input JSON text into the input field.\n and see how we can implement it. GOAL 1 First of all, let's learn how to connect our plugin with the IDE user interface. As we can see the IDE has a lot of action groups to do something (create new files for example). According to our idea to have some logic that can help us to convert JSON to POJO it would be great to have a new item in the new file list. It will be something like an action “Create new POJO file”. To connect our logic with the IDE by following this path we have to remember about the plugin.xml file that was discussed early. We can use this configuration file to describe our plugin and how it can be used. Let's find the actions section and define new action to show our input field dialog view. As we can see we can use some properties to describe how users will be available to interact with our plugin. We can define a custom icon for our action, define the position inside of the items list (“NewGroup” anchor “last”) and we can define the class to execute when action will be invoked by the user. Custom action class should extend the abstract AnAction class with the implementation of actionPerformed() method. Inside of actionPerformed() method implementation we can add the logic to show a dialog window with the input field for JSON text. To show dialog view we can easily use DialogBuilder from plugin development SDK and Java swing to create a user interface. More information about actions can be found on the official documentation page. GOAL 2 Let's imagine now that we already implemented logic to show the input text dialog with some selectable options to transform this text. We also added some logic of transformation - that can be some library to work with it or maybe our own implementation. And as the result of that transformation some new POJO files were generated added into our project (We can interact directly with the project or we can use project representation, provided by the plugin development SDK). But what about the next steps? We also need to notify the user about the result: it can be a success result notification, or maybe some error case notification. To implement it we can use default tools, provided by plugin development SDK. We can show some information to the user by using popup, notifications or messages. Let's imagine the following case: we have a text input field and we have some logic to convert/transform the text from this input field. If we can speak about JSON to POJO transformation, we have to understand that any random text cannot be converted to POJO correctly. Target text should satisfy some conditions and also should have the correct JSON structure and it means that we have to not only show some notification if text structure is not valid, but we have to block UI and break our transformation flow. Messages can really help us with it! According to the official documentation: The Messages class provides a way to show simple message boxes, input dialogs (modal dialogs with a text field), and chooser dialogs (modal dialogs with a combo box). The function of different methods of the class should be clear from their names. When running on macOS, the message boxes shown by the Messages class use the native UI. Lets see the following code: As we can see we can use the show dialog method, provided by SDK. We can define some dialog parameters, like title, message, button and of course we can define our custom plugin icon. If the image is not defined, standart Java icon or IDE icon would be shown. More information about images support can be found here. Also as it was already discussed here we can add support for internationalization instead of hardcoding only english string values. And as the result we can see this amazing small UI blocking window with our message text: It looks now that we found a solution to cover the error cases. Now we can prevent users from wrong input and show notification about it. Let's think about the success use case. Let's imagine that the input text was correct and we processed our JSON to POJO transformation as expected. Maybe some new files were generated, maybe it was only one new file. It will be a really good user experience if we can find a possibility to inform our users about it. Maybe one of the possible ways can be to show notification messages. It can be a small popup view with some text, like this one: and maybe we also can print some information to the event log: It looks now that we are ready to totally satisfy our user story requirements! Let's do the final steps and implement the following code: As we can see we can use the create notification method, provided by SDK. Unlike dialog related logic, we also have to define the project that we want to use to show the notification. As an example let's get only the first project (most popular use case), but we have to understand that users can open not only one project in the IDE and we have to take care about it too. So, as we can see it is also possible to define message text. Also we can define the message type (it can be INFORMATION, WARNING or ERROR) and we have to take care about the notification group that was defined inside of our plugin.xml file: FEW WORDS AT THE END As we can see it was not really a big deal to develop some small and hopefully useful tools for daily use or to help your teammates. The major idea is just to understand that integration with IDE can be really simple and when we will finish with it, we can be focused on the functionality of our tool. Perhaps in the future when we will have a stable version with some really cool features we can share our tool not only with teammates that we are working with directly, but maybe it also can be helpful for some developers from some random parts of the world. And maybe together we can simplify our daily job! Devoxx, formerly known as JavaPolis, is an international community conference which first took place in 2001 in Belgium. Since then it has developed into one of the largest Java events in Europe, with chapters in Belgium, France, UK, Poland and Ukraine, as well as an established conference in Morocco. Among the speakers at DevoxxUA (Devoxx Ukraine) 2019 I’d like to mention Josh Long, the Spring Developer Advocate at Pivotal and Cay Horstmann (yes, that’s him, the author of “Core Java”, “Big Java” and other great books). I got a chance to participate as a speaker on the second day of the conference, delivering a presentation on one of our latest solutions for implementing GraphQL with authorization in a microservice architecture. Was very excited to see that the talk got the highest amount of participants for that time slot and the room was packed, including people standing on their feet for the entire duration of my presentation! All in all, it was a great experience of sharing what & how we’ve built while getting valuable feedback and interesting questions. Have to say it felt incredible to stand on stage next to all the stars of the engineering world, during the closing ceremony of the conference! Here's my entire talk:\n\n \n@Test\nvoid givenHungryThenCook10BreadsWithMyWife() throws InterruptedException {\n var basket = new ConcurrentLinkedQueue<>();\n var knife = new Knife();\n var startGate = new CountDownLatch(1);\n var endGate = new CountDownLatch(10);\n\n Function<String, Runnable> preparation = topping -> () -> {\n try {\n startGate.await();\n } catch (InterruptedException e) {\n throw new RuntimeException(e);\n }\n synchronized (knife) {\n var bread = new Bread();\n knife.setTopping(topping).applyToppingTo(bread);\n basket.add(bread);\n endGate.countDown();\n }\n };\n\n // (...) omitted for brevity\n}Thread blocking
\nNonblocking Algorithms
\n\nclass Counter {\n private Integer count = 0;\n\n public void incrementCount() {\n this.count = count + 1;\n }\n\n public int getCount() {\n return count;\n }\n}\n\nclass ThreadSafeCounter {\n private AtomicInteger count = new AtomicInteger();\n\n public void incrementCount() {\n this.count.incrementAndGet();\n }\n\n public int getCount() {\n return count.get();\n }\n}\nprivate int value;\n\npublic final int incrementAndGet(int expectedValue) {\n int oldValue;\n do {\n oldValue = value;\n } while (!compareAndSetInt(oldValue, oldValue + 1));\n return oldValue;\n}\npublic class Knife {\n private final AtomicReference<String> topping = new AtomicReference<>();\n\n public Knife setTopping(String topping) {\n while (!this.topping.compareAndSet(null, topping)) {}\n return this;\n }\n\n public Knife applyToppingTo(Bread bread) {\n String currentTopping;\n if ((currentTopping = topping.getAndUpdate(s -> null)) != null)\n bread.setTopping(currentTopping);\n return this;\n }\n}Immutability
\n\npublic record Knife (String topping) {\n\n public Knife setTopping(String topping) {\n return new Knife(topping);\n }\n public Knife applyToppingTo(Bread bread) {\n if (topping != null)\n bread.setTopping(topping);\n return new Knife(null);\n }\n}\n@Test\nvoid givenReferenceToRecordThenItShouldBeImmutable() {\n record Parent(String name, List<String> childrenNames){};\n var childrenNames = new ArrayList<>(List.of(\"Haru\"));\n var parent = new Parent(\"Bruno\", childrenNames);\n\n var parentBeforeNewChild = parent.toString();\n childrenNames.add(\"Ayumi\");\n\n assertThat(parent).hasToString(parentBeforeNewChild);\n}\njava.lang.AssertionError: \nExpecting actual's toString() to return:\n <"Parent[name=Bruno, childrenNames=[Haru]]">\nbut was:\n <Parent[name=Bruno, childrenNames=[Haru, Ayumi]]>\nrecord Parent(String name, List<String> childrenNames){\n public Parent(String name, List<String> childrenNames) {\n this.name = name;\n this.childrenNames = new ArrayList<>(childrenNames);\n }\n};\n@Test\nvoid givenReferenceToRecordThenItShouldBeImmutable() {\n record Parent(String name, List<String> childrenNames){\n public Parent(String name, List<String> childrenNames) {\n this.name = name;\n this.childrenNames = new ArrayList<>(childrenNames);\n }\n }\n var childrenNames = new ArrayList<>(List.of(\"Haru\"));\n var parent = new Parent(\"Bruno\", childrenNames);\n\n var parentBeforeNewChild = parent.toString();\n parent.childrenNames().add(\"Ayumi\");\n\n assertThat(parent).hasToString(parentBeforeNewChild);\n}\njava.lang.AssertionError: \nExpecting actual's toString() to return:\n <"Parent[name=Bruno, childrenNames=[Haru]]">\nbut was:\n <Parent[name=Bruno, childrenNames=[Haru, Ayumi]]>\nrecord Parent(String name, List<String> childrenNames){\n public Parent(String name, List<String> childrenNames) {\n this.name = name;\n this.childrenNames = List.copyOf(childrenNames);\n }\n}Summary so far
\n\n
\nConclusion
\nAppendix
\n","fields":{"slug":"/a-wild-thread-appeared-multithreaded-testing-and-thread-safety/","tags":["Thread-safety","testing","nonblocking_algorithms","immutability"]}}},{"node":{"id":"62f571b3-f36e-549e-bb49-e2f60369d524","frontmatter":{"category":"Engineering","title":"How We Implement Feature Requests at AUTO1","date":"2022-11-30","summary":"In this blog post I want to emphasize how important the process of exceptional software delivery is.","thumbnail":null,"authorName":"Karim Baydon","authorDescription":"Senior Software Engineer in the AUTO1 Production Domain Team based in our Berlin Office","authorAvatar":{"relativePath":"pages/how-we-implement-feature-requests-at-auto1/karim-baydon-avatar.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAATCAYAAACQjC21AAAACXBIWXMAABYlAAAWJQFJUiTwAAAFIklEQVQ4yx2U21PUZRzGfzeZOaXNVM6UJpoYoiGDkiIHB5DDLuyRPbHnA/uDBXZZ9ySwgItyEJaD7gqSmmbgZFAwKCDqKDlmTjU1XWQ5ZTdNTV020z/w6ZcX33kv3pnPPO/zfJ9X0Bwrx3i8ElNMiTGkwdKhQ9kqR9FSTUNCh/ekFrFPTWTMTnDQQ+xkiOYWEY/NhlmlJeAP4HY3IatUEA+FEerDVVg6K7B3GiWAGW1bFUdsRVR6i9GFpLt2GWK3hmC7n1AggEOrpyA3n7w9+8jYksG+3TmUllRSU61CdHoRrMdleHoVuKSxx2vx9atoG9TjCGlpioiE2tvwtzbSGwqhq1Gy5Y3XeWn9i6xb9wIbXtrAq5teZcOGl9n82mays95D6J3y4O2rxRGvwhVV0NIuPc0vEmgVaW504QtaaW520d3Swu53drJx/ToO7s4kL3MHmW+9Sc72DA5l7WLzxlfY+MomhPAJO6ZGJc5ALd6AhuaAmcaIAV+nDndAhdNfi6fFglGtZe+ODGaGT/LsziLfz05zOz3KamqIh5cnOB9rI+vttxFE0YHDZcTtU+Nw6rBZtHhjGlp7DZJaIw6/5E3QTFlpIR0Ndv75/kt+f3CH31Zv8Gx5nl+leXJjjp8Wr+PXaRAsBp0E1OJwyzHo5NQbVbidGsxGSW2rE4/biKWxilJZCee6wvzxYIW/H6/x16M1fr9/mz/Wbj8/f1mZJx1uQXDb9disCiwGjbQKJlw2CV6vx+t0YFApMTtlqOqLKK+o4OpQDz8uzXHv0hRfTKV5dPEcKyMDpKNhrg328clgAkGrqsZpMeGx6rGYlJjqNdhsRnxuF4l4J8dPNuO2m9Cp1HyePs1UyEdpdjaq97L4pOsYYtH75G3ZSlCrZm504H+FVtwWM6LDgdNlwqDXoq1VkBob5evHP3B5ahp5lZxD+QeZPTvIo6uTxE119NuNPF2aZzoeJWHScTM1yv2PLiC0h8MEmn10nUjgsFoxqDWkzqRZvXWPuU/nsVrq2Jezm6Kiw1yWEv7z4R2eLlznyWcz/PvdN/y8MMu301ckD5dYTI8hzC4skpq6gNGoxyV5N3EmxcrSXZZv3iMU9GF11GFx19E30M/50WG+nLnAN9MXuT85zsyJONcSXTy8dJ6vJOhUPIbQNT6O3mHDolVw/uxZbt1a4+7tR7THQhgN1RwLRegfSDL98XVSI8NMdrQwebyVTk0t9txcxOJieiTPRwIiQYsFwRTw0+CxkxoeZmF+ldXlBwz2D6BUlOIwGxjp6yWdHGJibISuxDg2tY5jejmXAo2Ma3VMOp3PgbL8XCorbQjeRjfJ00MsLKyyvLTGRPoDZNWFdEaC9HW0M5U8zfS5MfpOpdA5hqRfxULB3iyG2pqY7g5xtSeKvPAwZfkHqK12IowODDA3t8yNxTvMXJ1FrarEbq/nbHKUi5IFZ04nCUeTmDxJKpQRZDIRzZES3t22HfmhgxTn5JDx1lYi0rZkvVuC8OHlWT668pmU6DIup00CVhHv7KHBF0VlCOMJSB4/h0U5WtPGnv16FKU1iIqj5O3cyYHMTKJWqW0KLZu3FiIMJT9gYnKGSCSGQlFJIBgl3JHA7O2hQh1DYx9EYz2FwtTD4TKRnP117NhVht+gp1vqfbtJzZi/gZzsErL2SV2+IikcHjrD0aOFOKW0xaYAzdE+golrNMU+pM45TLkyRo2+m4KyBvbmKtmVLWdbRgGG0nK6TQpqCorJyCwnN9/Af3EcVq8wGWCGAAAAAElFTkSuQmCC","width":50,"height":50,"src":"/static/29be57150f6568025a4db433fa0deedc/45876/karim-baydon-avatar.png","srcSet":"/static/29be57150f6568025a4db433fa0deedc/45876/karim-baydon-avatar.png 1x,\n/static/29be57150f6568025a4db433fa0deedc/eb85b/karim-baydon-avatar.png 1.5x,\n/static/29be57150f6568025a4db433fa0deedc/4f71c/karim-baydon-avatar.png 2x"}}},"headerImage":null},"html":"@Test\nvoid testTheCake() {\n record Cake(String name, boolean hasFruit, int weightInKg){};\n\n var chocolateCake = new Cake(\"Chocolate\", false, 5);\n var strawberryCake = new Cake(\"Strawberry\", true, 3);\n\n var bakery = List.of(chocolateCake, strawberryCake);\n\n var heavyCakes = new Condition<Cake>(cake -> cake.weightInKg >= 3, \"heavy cake\");\n var bigChocolate = new Condition<Cake>(cake ->\n cake.name.contains(\"Chocolate\") &&\n cake.weightInKg >= 5\n , \"big chocolate\");\n\n assertThat(bakery)\n .haveExactly(2, heavyCakes)\n .haveExactly(1, bigChocolate);\n}How We Implement Feature Requests at AUTO1
\n\n
\nMethod 1 - The Aggregator Pattern
\nMethod 2 - Importing the data into the microservice
\nTech Decision 2: Event Sourcing the State Changes
\nRefurbishment.State then the topic is named Refurbishment_State. Messages are then routed to the subscribed SQS queues using topics that have been specified. These messages can be consumed by multiple consumers.Tech Decision 3: Implementing Feature Flags
\n4. Quality Assurance (QA)
\n\n
\n
\nSoftware quality issues have an impact on functionality and as a result the user experience. When it comes to developing good software, the user always comes first. Only this ensures that the product is of high quality.
\nThose who recognize quality assurance as an essential component of software development from the start save time and money. The later errors are discovered, the longer the development time and the higher the costs.
\nContinuous quality assurance throughout the development process ensures that security vulnerabilities are detected and addressed early on.5. Monitoring
\n\n
\n\n\n
","fields":{"slug":"/how-we-manage-network-devices-at-auto1/","tags":["auto1","IT","Network","Automation "]}}},{"node":{"id":"c228c662-0cfd-54f0-ad54-4e1ef0c854d8","frontmatter":{"category":"Engineering","title":"Enter the End to End Testing of Internal Libraries ","date":"2022-07-18","summary":"End2End testing could help us tackle problems of increasing new code across the whole platform","thumbnail":null,"authorName":"Mikołaj Kłosowski","authorDescription":"Mikołaj is an Senior Software Engineer based in our Szczecin office","authorAvatar":{"relativePath":"pages/e2e-testing-internal-libraries/avatar_Kłosowski.jpg","childImageSharp":{"resolutions":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAPABQDASIAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAAAAMEAgX/xAAXAQADAQAAAAAAAAAAAAAAAAAAAQID/9oADAMBAAIQAxAAAAHPSiqzp4sF/8QAHBAAAgICAwAAAAAAAAAAAAAAAQIAAwQTESIj/9oACAEBAAEFAsYlcVG5r7CKRrrPnsn/xAAWEQEBAQAAAAAAAAAAAAAAAAAAEUH/2gAIAQMBAT8BxH//xAAVEQEBAAAAAAAAAAAAAAAAAAAAEf/aAAgBAgEBPwFH/8QAGhAAAgIDAAAAAAAAAAAAAAAAATEAEBIhYf/aAAgBAQAGPwIntKYncSr/xAAaEAEBAQADAQAAAAAAAAAAAAABEQAhMUGB/9oACAEBAAE/IQode8wvC2YhG/uoApOa9YSQYzv/2gAMAwEAAgADAAAAEI8v/8QAFhEBAQEAAAAAAAAAAAAAAAAAABEx/9oACAEDAQE/EJhT/8QAGBEAAwEBAAAAAAAAAAAAAAAAAAERQVH/2gAIAQIBAT8Qira0rp//xAAbEAEAAgMBAQAAAAAAAAAAAAABACERQVFxgf/aAAgBAQABPxDAIpp0LiTEIqARnq9gI/maHxA+0omb7FWMPxn/2Q==","width":50,"height":50,"src":"/static/08ff7d0f10dc02e43f61b30c3bf69631/d2d31/avatar_K%C5%82osowski.jpg","srcSet":"/static/08ff7d0f10dc02e43f61b30c3bf69631/d2d31/avatar_K%C5%82osowski.jpg 1x,\n/static/08ff7d0f10dc02e43f61b30c3bf69631/0b804/avatar_K%C5%82osowski.jpg 1.5x,\n/static/08ff7d0f10dc02e43f61b30c3bf69631/753c3/avatar_K%C5%82osowski.jpg 2x,\n/static/08ff7d0f10dc02e43f61b30c3bf69631/31ca8/avatar_K%C5%82osowski.jpg 3x"}}},"headerImage":null},"html":"\n \n\n\n1. On the Unimus platform we add each device with the devices IP and Credentials. \n\n \n \n \n \n2. From “Schedules” we configure the time and date for the desired upgrade. \n\n \n \n \n \n3. After adding all devices of the same model to Unimus, we go to the “Mass Configuration Push” menu. Templates and configurations for the upgrade need to be prepared. \n
4. From here we also add a Mikrotik Script to download the latest update, add the schedule for this push and select the target devices.\n \n \n \n \n\n5. Lastly we add a second command to issue the upgrade and reboot the device. \n
6. All that’s left to be done is to add a corresponding downtime in our monitoring tool (CheckMK) and wait for the magic to happen.\n \n \n \n
\nservice-commons-dependencies, more commonly known in AUTO1 from here on out, “E2E testing”.\nmvn -U versions:update-property -Dproperty='service-commons-dependencies.version'\ndef hasChanges = sh(returnStatus: true, script: \"git diff --exit-code\")\nbuild(job: 'java/core-svc/core_test_end_to_end_test', parameters: [booleanParam(name: 'SEND_SLACK_NOTIFICATION', value: \"true\"), string(name: 'RELEASE_TRAIN_VERSION', value: service_commons_dependencies_version)])\nString latestTagDateString = sh(returnStdout: true, script: \"git rev-list -1 \\$(git describe --abbrev=0 --tags) --pretty=oneline --format=%ci | awk 'NR%2==0'\")\n\ndef proceedWithE2ETesting = wasTagReleasedRecently(latestTagDateString)\n\n@NonCPS\n\n def wasTagReleasedRecently(String lastTagDateString) {\n\n def formatter = DateTimeFormatter.ofPattern(\"yyyy-MM-dd HH:mm:ss Z\")\n\n def lastTagDateTime = OffsetDateTime.parse(lastTagDateString.trim(), formatter)\n\n def currentTimeMinus2hours = OffsetDateTime.now().minus(2, ChronoUnit.HOURS)\n\n return lastTagDateTime.isAfter(currentTimeMinus2hours)\n\n}\ndefinition {\n cpsScm {\n scm {\n git {\n remote {\n github(\"core-e2e-tests\", 'ssh')\n credentials(\"token\")\n branch(\"master\")\n }\n extensions {\n wipeOutWorkspace()\n }\n }\n }\n\n scriptPath(\"jenkins/core_e2e_tests.gvy\")\n }\n}\nScenario: Should have a working API endpoint for creating a message\n\nGiven an object with generated id and message: This is a test\nWhen making a POST call on messaging endpoint with the body containing the given object in JSON representation\nThen should result in a 201 response status code\nAnd should receive an empty body\nSanity checks for new release train X.Y.Z on env:\n\n * REST API simple entity integration ✅\n * REST API dated entity integration ✅\n * REST API auditable entity integration\n * Messaging integration ✅\n * Messaging FIFO integration ✅\n * Storage integration ✅\n * Health integration ✅\n * Metrics integration ✅\n * Logging integration ✅Rate Limiters
\n\nfinal RateLimiter rateLimiter = RateLimiter.create(2.0); // rate is \"2 permits per second\"\n void submitTasks(List<Runnable> tasks, Executor executor) {\n for (Runnable task : tasks) {\n rateLimiter.acquire(); // may wait\n executor.execute(task);\n }\n}\n // Create a custom RateLimiter configuration\nRateLimiterConfig config = RateLimiterConfig.custom()\n .timeoutDuration(Duration.ofMillis(100))\n .limitRefreshPeriod(Duration.ofSeconds(1))\n .limitForPeriod(2)\n .build();\n// Create a RateLimiter\nRateLimiter rateLimiter = RateLimiter.of(**\"backendName\"**, config);\n\n// Decorate your call to BackendService.doSomething()\nSupplier<String> restrictedSupplier = RateLimiter\n .decorateSupplier(rateLimiter, backendService::doSomething);\n\n// First call is successful\nTry<String> firstTry = Try.ofSupplier(restrictedSupplier);\nassertThat(firstTry.isSuccess()).isTrue();\nRefill refill = Refill.intervally(2, Duration.ofSeconds(1));\nBandwidth limit = Bandwidth.classic(2, refill);\nBucket bucket = Bucket4j.builder()\n .addLimit(limit)\n .build();\n\nif (bucket.tryConsume(1)) {\n executor.execute(task);\n}Thread Blocking
\n\nprivate void guavaRateLimiter() {\nRateLimiter rateLimiter = RateLimiter.create(2);\nlogWithThreadTimeStamped(\"Starting\");\n\nIntStream.rangeClosed(1, 4).forEach(i -> {\n rateLimiter.acquire();\n logWithThreadTimeStamped(\"Task n. \" + i);\n});\n\nlogWithThreadTimeStamped(\"I'm blocked =(\");\nlogWithThreadTimeStamped(\"Finishing\");\n\n}\n[12:01:31.972073] Starting Thread: main\n[12:01:31.978520] Task n. 1 Thread: main\n[12:01:32.471752] Task n. 2 Thread: main\n[12:01:32.967231] Task n. 3 Thread: main\n[12:01:33.470331] Task n. 4 Thread: main\n[12:01:33.470662] I'm blocked =( Thread: main\n[12:01:33.470845] Finishing Thread: mainScheduling
\n\nprivate void taskScheduling() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar intervalDiary = new AtomicInteger();\nvar expectedInterval = 500;\nlogWithThread(\"Starting\");\n\nIntStream.rangeClosed(1, 4).forEach(i -> {\n scheduleExecutor.schedule(\n () -> logWithThread(\"Task n. \" + i),\n intervalDiary.getAndAdd(expectedInterval), TimeUnit.MILLISECONDS\n );\n});\n\nlogWithThread(\"I'm NOT blocked =D\");\nlogWithThread(\"Finishing\");\n}\n\nprivate void logWithThread(String message) {\n System.out.println(message + \" Thread: \" + Thread.currentThread().getName());\n}\nStarting - Thread: main\nI'm NOT blocked =D Thread: main\nFinishing - Thread: main\nTask n. 1 - Thread: pool-1-thread-1\nTask n. 2 - Thread: pool-1-thread-1\nTask n. 3 - Thread: pool-1-thread-1\nTask n. 4 - Thread: pool-1-thread-1\nprivate void taskSchedulingV2() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar intervalDiary = new AtomicInteger();\nvar expectedInterval = 500;\nscheduleExecutor.execute(() -> logWithThread(\"Starting\"));\n\nIntStream.rangeClosed(1, 4).forEach(i -> {\n scheduleExecutor.schedule(\n () -> logWithThread(\"Task n. \" + i),\n intervalDiary.getAndAdd(expectedInterval), TimeUnit.MILLISECONDS\n );\n});\n\nscheduleExecutor.execute(() -> logWithThread(\"I'm NOT blocked =D\"));\nscheduleExecutor.execute(() -> logWithThread(\"Finishing\"));\n}\nStarting Thread: pool-1-thread-1\nTask n. 1 Thread: pool-1-thread-1\nI'm NOT blocked =D Thread: pool-1-thread-1\nFinishing Thread: pool-1-thread-1\nTask n. 2 Thread: pool-1-thread-1\nTask n. 3 Thread: pool-1-thread-1\nTask n. 4 Thread: pool-1-thread-1\nprivate void taskSchedulingV3() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar myTasks = new ConcurrentLinkedQueue<Runnable>();\nvar EXPECTED_INTERVAL = 500;\nscheduleExecutor.execute(() -> logWithThread(\"Starting\"));\n\nscheduleExecutor.scheduleAtFixedRate(() ->\n ofNullable(myTasks.poll()).ifPresent(Runnable::run),\n 0, EXPECTED_INTERVAL, TimeUnit.MILLISECONDS\n);\n\nIntStream.rangeClosed(1, 4).forEach(i ->\n myTasks.add(() -> logWithThread(\"Task n.\" + i))\n);\n\nscheduleExecutor.execute(() -> logWithThread(\"I'm NOT blocked =D\"));\nscheduleExecutor.execute(() -> logWithThread(\"Finishing\"));\n}\nStarting Thread: pool-1-thread-1\nTask n.1 Thread: pool-1-thread-1\nI'm NOT blocked =D Thread: pool-1-thread-1\nFinishing Thread: pool-1-thread-1\nTask n.2 Thread: pool-1-thread-1\nTask n.3 Thread: pool-1-thread-1\nTask n.4 Thread: pool-1-thread-1\nprivate void taskSchedulingOverload() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar myTasks = new ConcurrentLinkedQueue<Runnable>();\nvar EXPECTED_INTERVAL = 500;\nvar SMALLER_INTERVAL = 250;\nscheduleExecutor.execute(() -> logWithThread(\"Starting\"));\n\nscheduleExecutor.scheduleAtFixedRate(() ->\n ofNullable(myTasks.poll()).ifPresent(Runnable::run),\n 0, EXPECTED_INTERVAL, TimeUnit.MILLISECONDS\n);\n\n\nscheduleExecutor.scheduleAtFixedRate(() ->\n myTasks.add(() -> logWithThread(\"Fast Task! Task lasting: \" + myTasks.size())),\n 0, SMALLER_INTERVAL, TimeUnit.MILLISECONDS\n);\n\n\nscheduleExecutor.execute(() -> logWithThread(\"I'm NOT blocked =D\"));\nscheduleExecutor.execute(() -> logWithThread(\"Finishing\"));\n}\nStarting Thread: pool-1-thread-1\nI'm NOT blocked =D Thread: pool-1-thread-1\nFinishing Thread: pool-1-thread-1\nFast Task! Task lasting: 1 Thread: pool-1-thread-1\nFast Task! Task lasting: 2 Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1\nFast Task! Task lasting: 4 Thread: pool-1-thread-1\nFast Task! Task lasting: 5 Thread: pool-1-thread-1\nFast Task! Task lasting: 6 Thread: pool-1-thread-1\nFast Task! Task lasting: 7 Thread: pool-1-thread-1\nFast Task! Task lasting: 8 Thread: pool-1-thread-1\nFast Task! Task lasting: 9 Thread: pool-1-thread-1\n\n(...)\nprivate void taskSchedulingLimitingByQueueSize() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar myTasks = new ConcurrentLinkedQueue<Runnable>();\nvar EXPECTED_INTERVAL = 500;\nvar SMALLER_INTERVAL = 250;\nvar QUEUE_LIMIT = 4;\nscheduleExecutor.execute(() -> logWithThread(\"Starting\"));\n\nscheduleExecutor.scheduleAtFixedRate(() ->\n ofNullable(myTasks.poll()).ifPresent(Runnable::run),\n 0, EXPECTED_INTERVAL, TimeUnit.MILLISECONDS\n);\n\n\nscheduleExecutor.scheduleAtFixedRate(() -> {\n if (myTasks.size() < QUEUE_LIMIT)\n myTasks.add(() -> logWithThread(\"Fast Task! Task lasting: \" + myTasks.size()));\n else\n logWithThread(\"I was rejected =(\");\n },\n 0, SMALLER_INTERVAL, TimeUnit.MILLISECONDS\n);\n\nscheduleExecutor.execute(() -> logWithThread(\"I'm NOT blocked =D\"));\nscheduleExecutor.execute(() -> logWithThread(\"Finishing\"));\n}\nStarting Thread: pool-1-thread-1\nI'm NOT blocked =D Thread: pool-1-thread-1\nFinishing Thread: pool-1-thread-1\nFast Task! Task lasting: 1 Thread: pool-1-thread-1\nFast Task! Task lasting: 2 Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1\nI was rejected =( Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1\nI was rejected =( Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1\nI was rejected =( Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1Conclusion
\nLogging with MDC in functional style
\nIntroduction
\nUse case
\nMDC code drawbacks
\n\ntry {\n MDC.put(\"key1\", \"value1\");\n MDC.put(\"key1\", \"value2\");\n //some process\n log.info(\"very important log\");\n}finally {\n MDC.remove(\"key1\");\n MDC.remove(\"key2\");\n}method putCloseable(key, value) which returns AutoClosable object but it allows only one key-value pair and has to be assigned to a variable, which may look better for a single key but it is not perfect. IDE will complain about never used variable\ntry (MDC.MDCCloseable closeable = MDC.putCloseable(\"key\", \"value\")) {\n //some process\n log.info(\"very important log\");\n}Solution
\n\nLogContext.withLogKey(\"key1\", \"value1\")\n .andKey(\"key2\", \"value2\")\n .andKey(\"key3\", \"value3\")\n .execute(() -> {\n // some process\n log.info(\"very important log\");\n });LogContextSteps
\n\n@NoArgsConstructor(access = AccessLevel.PRIVATE)\npublic final class LogContextSteps {\n\n public interface ContextStep {\n ExecuteStep andKey(final String key, final Object value);\n }\n\n public interface ExecuteStep extends ContextStep {\n\n <T> T execute(final Supplier<T> action);\n\n default void execute(final Runnable action) {\n if (action == null) {\n throw new IllegalArgumentException(\"Action for execution cannot be null.\");\n }\n\n execute(() -> {\n action.run();\n return null;\n });\n }\n }\n}\n
\nLogContext
\n\npublic class LogContext implements ContextStep, ExecuteStep {\n private static final MDCLogContextSetter MDC_LOG_CONTEXT_SETTER = new MDCLogContextSetter();\n\n private final LogContextSetter contextSetter;\n private final Set<String> contextKeys = new HashSet<>();\n\n private LogContext(final LogContextSetter contextSetter) {\n this.contextSetter = contextSetter;\n }\n\n public static ExecuteStep withLogKey(String key, Object value) {\n return withContextSetter(MDC_LOG_CONTEXT_SETTER).andKey(key,value);\n }\n\n static ExecuteStep withContextSetter(LogContextSetter contextSetter){\n return new LogContext(contextSetter);\n }\n\n @Override\n public ExecuteStep andKey(String key, Object value) {\n contextSetter.put(key, value);\n contextKeys.add(key);\n return this;\n }\n\n @Override\n public <T> T execute(final Supplier<T> action) {\n if (action == null) {\n throw new IllegalArgumentException(\"Action for execution cannot be null.\");\n }\n\n try {\n return action.get();\n } finally {\n contextKeys.forEach(contextSetter::remove);\n }\n }\n\n interface LogContextSetter {\n\n void remove(final String key);\n\n void put(final String key, final Object value);\n }\n\n private static class MDCLogContextSetter implements LogContextSetter {\n\n @Override\n public void remove(String key) {\n MDC.remove(key);\n }\n\n @Override\n public void put(String key, Object value) {\n MDC.put(key, Objects.toString(value));\n }\n }\n}LogContext is our main class here. It:\n
\nLogContextStepsSetLogContextSetter interface and its implementation MDCLogContextSetter, as it would be hard to test static methods of MDC class.LogContext.withLogKey(\"key1\", \"value1\") which sets up our MDCLogContextSetter and invokes the andKey(\"key2\", \"value2\") method for the first time. Then we can chain next invocations of andKey where every invocation causes two things:\n
\nSet<String> contextKeys as only keys are needed to clear contextLogContextSetter::put method is invoked where implementation is: MDC.put(key, Objects.toString(value)) and at that moment key-value is stored in MDCexecute(() -> action()) which is classic try-finally block where try invokes our action and finally clears MDC iterating every through contextKeys and invoking LogContextSetter::remove where implementation id MDC.remove(key)Practical usage (filtering in Kibana)
\nMacBook with ARM chip and embedded-libraries problems
\nEmbedded-postgres problems
\nProblem
\n\n Factory method 'postgres' threw exception; nested exception is\n java.lang.IllegalStateException: Process\n [/var/folders/61/ls8bv20x4w3fsn3wpm8dlpfm0000gp/T/embedded-pg/\n PG-0c0585587b40695247cf72650cd42f92/bin/initdbSolution
\n\nsudo sysctl kern.sysv.shmmax=104857600\nsudo sysctl kern.sysv.shmall=25600\nsudo sysctl kern.sysv.shmmin=1\nsudo sysctl kern.sysv.shmmni=10240\nsudo sysctl kern.sysv.shmseg=4096\n\nexport LC_NUMERIC=en_US.UTF-8\nexport LC_MONETARY=en_US.UTF-8\nexport LC_TIME=en_US.UTF-8\nexport LC_ALL=en_US.UTF-8\nexport LC_COLLATE=en_US.UTF-8\nexport LC_MESSAGES=en_US.UTF-8\nexport LC_CTYPE=en_US.UTF-8\nexport LANG=en_US.UTF-8Embedded-redis problems
\nProblem
\n\njava.lang.RuntimeException: Can't start redis server. Check\nlogs for details.\n\nat\nredis.embedded.AbstractRedisInstance.awaitRedisServerReady\n(AbstractRedisInstance.java:61)\nat\nredis.embedded.AbstractRedisInstance.start\n(AbstractRedisInstance.java:39)\nat redis.embedded.RedisServer.start(RedisServer.java:9)\nat\nwkda.common.distributed.cache.redis.EmbeddedSingleRedisServer\n.before(EmbeddedSingleRedisServer.java:48)\nat org.springframework.test.context.junit4.SpringJUnit4ClassRunner\n.run(SpringJUnit4ClassRunner.java:190)Deep diving into problem
\n\n=== REDIS BUG REPORT START: Cut & paste starting from here ===\n30203:M 15 Feb 14:01:14.039 # Redis 3.2.4 crashed by signal: 10\n30203:M 15 Feb 14:01:14.040 # Crashed running the instuction\nat: 0x7fff20406440\n30203:M 15 Feb 14:01:14.040 # Accessing address: 0x305685000\n30203:M 15 Feb 14:01:14.040 # Failed assertion: <no\nassertion failed> (<no file>:0)\n\n------ STACK TRACE ------\nEIP:\n0 libsystem_platform.dylib 0x00007fff20406440\n_platform_memset$VARIANT$Rosetta + 108\n\nBacktrace:\n0 redis-server.app 0x0000000100a70a7e logStackTrace + 110\n1 redis-server.app 0x0000000100a70e4d sigsegvHandler + 253\n2 libsystem_platform.dylib 0x00007fff20403d7d _sigtramp + 29\n3 ??? 0x00000001091c1200 0x0 + 4447801856\n4 ??? 0x31207070612e7265 0x0 + 3539952935082291813Solution
\n\n
\n\nsysctl -a | grep hw.optional\n\n------- Result -------\n\nhw.optional.amx_version: 2\nhw.optional.arm64: 1\nhw.optional.armv8_1_atomics: 1\nhw.optional.armv8_2_fhm: 1\nhw.optional.armv8_2_sha3: 1\nhw.optional.armv8_2_sha512: 1\nhw.optional.armv8_crc32: 1\nhw.optional.breakpoint: 6\nhw.optional.floatingpoint: 1\nhw.optional.neon: 1\nhw.optional.neon_fp16: 1\nhw.optional.neon_hpfp: 1\nhw.optional.ucnormal_mem: 1\nhw.optional.watchpoint: 4\nsysctl -a | grep hw.optional\nhw.optional.floatingpoint: 1\nhw.optional.mmx: 1\nhw.optional.sse: 1\nhw.optional.sse2: 1\nhw.optional.sse3: 1\nhw.optional.supplementalsse3: 1\nhw.optional.sse4_1: 1\nhw.optional.sse4_2: 1\nhw.optional.x86_64: 1\nhw.optional.aes: 1\nhw.optional.avx1_0: 1\nhw.optional.rdrand: 1\nhw.optional.f16c: 1\nhw.optional.enfstrg: 1\nhw.optional.fma: 1\nhw.optional.avx2_0: 1\nhw.optional.bmi1: 1\nhw.optional.bmi2: 1\nhw.optional.rtm: 0\nhw.optional.hle: 0\nhw.optional.adx: 1\nhw.optional.mpx: 0\nhw.optional.sgx: 0\nhw.optional.avx512f: 0\nhw.optional.avx512cd: 0\nhw.optional.avx512dq: 0\nhw.optional.avx512bw: 0\nhw.optional.avx512vl: 0\nhw.optional.avx512ifma: 0\nhw.optional.avx512vbmi: 0\nprotected void before() {\nRedisExecProvider provider = RedisExecProvider.defaultProvider()\n.override(OS.UNIX, \"redis-server/redis-server\")\n.override(OS.WINDOWS, Architecture.x86,\n\"redis-server/redis-server.exe\")\n.override(OS.WINDOWS, Architecture.x86_64,\n\"redis-server/redis-server.exe\")\n.override(OS.MAC_OS_X, Architecture.x86,\n\"redis-server/redis-server.app\")\n.override(OS.MAC_OS_X, Architecture.x86_64,\ngetRedisServerForAppleArchitecture());\n\n\nthis.redisServer = RedisServer.builder()\n.redisExecProvider(provider)\n.port(redisPort)\n.setting(\"bind \" + this.redisHost)\n.build();\n\nthis.redisServer.start();\nlog.info(\"Started Redis server at [{}:{}]\",\nthis.redisHost, this.redisPort);\n}\n\n\nprivate String getRedisServerForAppleArchitecture()\nthrows Exception {\nProcess process = Runtime.getRuntime().exec(\"sysctl hw\");\ntry (BufferedReader input = new BufferedReader(new\nInputStreamReader(process.getInputStream()))) {\nString line;\nwhile((line = input.readLine()) != null) {\nif (line.contains(\"hw.optional.arm64\") &&\nline.trim().endsWith(\"1\")) {\nreturn \"redis-server/amd64/redis-server.app\";\n}\n}\n} catch (IOException e) {\nlog.error(\"Error during parsing system process\");\nthrow new RuntimeException(e);\n}\nreturn \"redis-server/redis-server.app\";\n}\n
\n\n
\n\n
\n\n
\n\n
\n\n
\nThe OpenAPI journey
\nThe situation
\nThe light at the end of the tunnel
\nDesign first, code later
\nThe ecosystem
\nRetrofitting OpenAPI
\nChallenges ahead
\nThe verdict
\n\n
\n\nmy_gradle_plugin\n\n├── build.gradle\n\n├── gradle\n\n│ └── wrapper\n\n│ ├── gradle-wrapper.jar\n\n│ └── gradle-wrapper.properties\n\n├── gradlew\n\n├── gradlew.bat\n\n├── settings.gradle\n\n└── src\n\n├── main\n\n│ ├── java\n\n│ └── resources\n\n│ └── META-INF\n\n│ └── plugin.xml\n\n└── test\n\n├── java\n\n└── resources\n\n
\nGOAL 2 - As a user I want to see the result notification.\n\n<actions>\n\n<action id=\"GeneratePOJOAction\" class=\"GeneratePOJOAction\"\n\nicon=\"/icons/pojo.png\"\n\ntext=\"Generate POJO from JSON\"\n\ndescription=\"GeneratePOJOAction\">\n\n<add-to-group group-id=\"NewGroup\" anchor=\"last\"/>\n\n</action>\n\n</actions>\nimport com.intellij.openapi.actionSystem.AnAction\n\nimport com.intellij.openapi.actionSystem.AnActionEvent\n\nclass GeneratePOJOAction : AnAction() {\n\noverride fun actionPerformed(e: AnActionEvent) { \n\n//TODO: Add your UI implementation here \n\n} \n}\ncompanion object {\n\nprivate const val BUTTON_TITLE = \"OK\"\n\nprivate const val DEFAULT_OPTION_INDEX = -1\n\nprivate val DEFAULT_ICON = null\n\n}\n\nfun onPluginExceptionHandled(exception: RoboPluginException) {\n\nMessages.showDialog(\n\nexception.message, exception.title,\n\narrayOf(BUTTON_TITLE),\n\nDEFAULT_OPTION_INDEX,\n\nDEFAULT_ICON\n\n)\n\n}\n12:00 Response.java was updated.\n \n12:00 POJO generation: Success\ncompanion object{\n\nprivate const val MESSAGE_SUCCESS = \"POJO generation: Success\"\n\nprivate const val GROUP_ID = \"RoboPOJO Generator\"\n\n}\n\nfun showSuccessMessage() {\n\nshowMessage(\n\nproject = ProjectManager.getInstance().openProjects.first(),\n\nmessage = MESSAGE_SUCCESS,\n\ntype = NotificationType.INFORMATION,\n\n)\n\n}\n\nprivate fun showMessage(\n\nmessage: String, type: NotificationType, project: Project\n\n) = NotificationGroupManager.getInstance()\n\n.getNotificationGroup(GROUP_ID)\n\n.createNotification(message, type)\n\n.notify(project)\n\n \n<extensions defaultExtensionNs=\"com.intellij\">\n\n<notificationGroup id=\"RoboPOJO Generator\"\n\ndisplayType=\"BALLOON\"\n\nkey=\"com.robohorse.robopojogenerator\"/>\n\n</extensions>
![](\"https://lh4.googleusercontent.com/8EZA89AIL5p8v723-rdyslTwOTbCIAqreXMF9_sd-fP6L7EEfbSN9h1yCvd6n7Ljc62P5GXAdj0KvtGqLhU2BKUdVd9dQEh8QP3rCRMhCZ2Q2yo_Rq9vrAj8grXr06wyWqhMYIAhtlgoG3uzqZGzCw8hcwhZHWXtvUgA7wamde5V5ZNnhkmwXMis0Q\")
![](\"https://lh3.googleusercontent.com/lxogAJ5Uq3wfk3-co_sG3dt_nnSph-bOuOOHItnd_-IKRcvOAzJ50PJgJnyRwKeHdwHk5pFWroeEbRuOcOcm-DiFCTKOKlCqsduwyxQK1nUknzKJpXPPv8z405le3v3C2oMqr2qYp1oq5Mj_XPP4cAhQDjYMUUPcSq-WP-W304PIw2ak2b5qnCNi0Q\")
![](\"https://lh6.googleusercontent.com/2pAyEXvc4hlAGNcMYNalJJDwM91YihSX4NdVRO-Hwzp52Zxldz_P0PH6OSlPSjp4DgGv5TSRTbjzxTQs3I0Li5h1_57g4tR9TB__80NL-petgqahPdZeOcgRYJt9G6h12xrLQfjmm9ijjJbTzXLqJPps3Ana2TZ5yTNJ_VXap4Hd6C7OZahMiHQY1g\")
![](\"https://lh3.googleusercontent.com/2xOP2Pq7LztBRRr-B2VJ5_roCubvYa4xJ_SlVeTz8LWzRTYqXflYowAAaNDsDh7y77M2vDDB8l1r_BpOvQsKQfHGssADO7FnbzGEmjtXKfFKfV5mES8whAQdYfUTJHwEdv9OGJ2A2GvkxS5XglrDG29p7zNZrtFNXvAMjThrQloKfFmSuqs7Nmd-xw\")
![](\"https://lh6.googleusercontent.com/-K5rLPtggaNeQpml856NbA9UyUU6_scnBUgUE_W-RA7MVORz_dYAzrQ_jg7a9vBfQJHqmdosoCH7Evd0dbTF8-kzH0dlygQPeoqQu47__E5Pky0GmeyhlcJ1UWNuQrC7j5s3MZvQhj_EoSgwBA\")
![](\"https://lh5.googleusercontent.com/qyj0MbKLCEPO9M3Q8kalZoXkgfgcxddnmxk6lYUu0DrbBHhT747lCyy1SFhZDHKZXOGwUqcnsDFDPM2_rWAhnWC5l5m58RVcpsWWrBmwHIZgd3tKxSmhC6aqZHsB016Z7MXAhT0EX7mnT_N3_w\")
![](\"https://lh6.googleusercontent.com/F4M8xRSQWe86JzTN8G5uPIc62Y_uNhPB-_YDLlhHtTpy0PseDIX7fb8_jh37YbpVQEIJiy4gE76vP0eqkU5jjHKOeac5h3tprc52Iz2oQvv0Ros5AHC00DqsW_YZ6H_hXWdJ0yPe6evaU3Ir7Q\")