Creating the CQ-Shop application was a great adventure. I used a bunch of new tools – event-driven architecture, Event Storming, Kafka, and many more. In this post, I summarize all the things that I learned and achieved.
From the very beginning, the CQ-Shop project was meant to be a big mix of buzzwords – microservices, event-driven, AI, and many many more. Even though the final application is a bit different than the planned one, it is still pretty impressive. In this post, I describe the architecture, development environment, and tools that I used.
CQ-Shop is an application written in event-driven architecture. In this post, I describe what the communication between microservices looks like. Before digging into that concept, I introduce the publish/subscription messaging. Once you get this idea, the whole concept of architecture should be clear. Moreover, I describe how I used events as a data for anomaly detection.
I’m about to start my final year at university, which will involve many activities related to obtaining my master degree. One of them is writing my master’s thesis, which is one of the biggest and the most time-consuming challenges. It’s a process that consists of writing the thesis and developing a project. I’m going to write a series of posts that will show you how the project is evolving.
This post is the second part of the series dedicated to developing plugins for IntelliJ IDEA. Its main topic is a workflow for developing two interdependent plugins. Everything described here assumes that you have configured the workspace using the intellij-gradle-plugin.
I’ve spent the last few weeks configuring and developing IntelliJ plugins. This post is a quick summary of what I’ve learned so far. Some of the things I discuss in this post are not documented and base on my own investigation and debugging of various IntelliJ IDE mechanisms.
There was a very annoying bug. On each of post pages the Disqus plugin, which is responsible for loading comments section, used to show same comments for all of the posts. It took me a few hours of debugging to find out where the issue was.
This is my last technical post in the Get Noticed 2017 category. The last one will be a quick summary of the last three months. Soo…it was a very long week. I didn’t do too much but there was a big progress in using the neural network in the Aksesi Proxy Application.
The neural network requires to train it before using. We are expected to provide sets od date that will be used for the purpose of learning. It means that we need a generator which will create gestures in a form readable by the NN.
It’s time to start implementing support for recognizing gestures with neural networks. As I mentioned in the previous post, I had seen some potential problems. After two days of work, I can finally write that those problems are solved. In this post, I’ll describe how I solved the problem of different drawing area location. In the second paragraph, I’m going to describe implemented resizing strategy. At the end, in the third part, I’ll write some words about flattering gestures and values normalization.