Last Update: March 2024

Cloud Academy, Inc.


Programs automate the process of assigning training to your team members. Programs are one of the Skills Readiness Solution Tools and you can use them by themselves or together with job roles to optimize your training automation.

From Cloud Academy Help Center

After trying the experience of using Python for web development, my team and I decided it was time to shift our focus towards more enterprise-level solutions using Kotlin and Spring Boot.

Programs are a replacement for an existing product in the company but with the twist of adding new features. The standout feature is the support for smart rules, which enable company admins to automate the process of enrolling a user in a program based on the rules chosen during setup.

These rules are powered by the event-driven architecture implemented in the project. Each rule, except for the custom one, runs every time a user joins the company, a team, or a job role. This integrates directly with the previous project, “Career Paths”, as admins can create a career matrix and, when a user advances, they are automatically assigned new training.

While Python was the widely used language at Cloud Academy, we decided to use Kotlin and Spring Boot. The reason for this shift is that we were looking for a safer language that would offer static typing and leverage the experience that some of our teammates had with the Spring Boot stack.

Career Paths

My first project at Cloud Academy was to build the system that lets our customers set up career paths for their team. We used FastAPI with Python 3.8 for this project.

I finally got to apply GraphQL and event-driven services in a real-world setting, something I’d only read about or tinkered with in theory before. The project itself was mainly about doing CRUD operations, but the real kicker for me was getting Python to play nice in a big enterprise product. It was less about the complexity of the tasks and more about diving deep into a new stack and making it work in an environment where things have to run smoothly and efficiently.


In 2021, I had the opportunity to work on the digital transformation of, an e-commerce platform that specializes in selling high-quality Italian food and brands throughout the United Kingdom.

This was not a simple creation from scratch, but rather a complex migration from legacy systems based on osCommerce and a rudimentary warehouse management system to a new, integrated, and scalable platform that can handle a high volume of daily orders.

The new system has reduced errors and manual processing times, providing customers with a vertically integrated solution that includes warehouse management, shipping systems, and customer support.

One of the challenges that food e-commerce platforms often face is managing portioned products. This includes answering questions such as:

  • How can I manage the sale of “child” products (e.g., 100g and 200g portions) starting from a “parent” product (e.g., a whole Parmesan cheese or ham)?
  • What are the correct quantities to assign to “child” products to ensure that the total sold does not exceed the available “parent” product?
  • How can I properly divide portions into different selling modes, such as fresh packs and vacuum bags?

The mathematical answer to these questions is the so-called “knapsack problem.”

I implemented and tested an algorithm to solve this problem in the context of Nifeislife’s e-commerce platform. This algorithm optimally solves the issue of portioning products while maximizing sales and minimizing canceled orders due to stock shortages.

Through the use of a specially created platform, Nifeislife can manage portioned products, the stock quantities of the parent product, and decide how to divide it into packages. The platform communicates directly with the APIs of other management systems used by the company, both for managing warehouse stocks and for managing the quantities of products put up for sale on the website. SpA

Ricerca Annunci SpA – (Sep 2020 – May 2021)

I had the chance to yet again work on one of the vital parts of all our products: the results page, both as a map and as a listing.

One of the many features of is seeing the results of your search on a map, allowing you to see where the real estate properties are located. We did not have this feature enabled on our Spanish website because we planned from the beginning to rewrite the entire feature. The end result is pretty neat. See here a before and after.

This project reuses and improves most of my work on the previous project, expanding the API to perform all the types of searches available to the user. I recommend you to first read the project below, “Posizione Media”, to gain a better understanding of what I achieved.

Because I had to expand the capabilities and the search categories, I decided to refactor the entire work to implement the abstract factory pattern, improving maintenance and readability.

You can compare the resulting diagram from the one before.

The main difference is that now the classes that store the parameters do not have any methods defined because each attribute is set by the factory. This means that they do not have any business logic in them and can be reused for something else. Sorry for the variables and class names in Italian, but they reflect precise domain names.

Thanks to this project we now have a robust search API, completely tested both via functional and unit tests, that can be easily improved and expanded.

Below is a before and after of the new search results page, that consumes the API I built.

Posizione Media SpA – (Mar 2020 – May 2020)

When publishing an advert, users can choose to buy a visibility package to get a better position in the results page. Each package improves visibility differently, depending on the price. Just telling the users that they can improve the visibility of their properties by buying these packages is one way of selling. Showing them a projection of the improvement is the better way.

Searching for properties works by querying a Solr powered database and then using the results to perform a query on MySQL with the IDs obtained. This has many benefits, like enabling instant results and allowing complex filters to be applied without having to deal with many indices on the relational table where the properties are stored. We do not have a direct interface with Solr, because we apply a facade pattern to expose a simpler interface to the clients who want to query our search engine. However, this simpler interface does not (and does not need to) have any knowledge about the domain where it is used, so, in the process of decoupling the search APIs from the monolith, we created a new project, the so called “search service”, to deal with domain related logics and expose a public API.

We wanted to aim only for the URLs that are searchable via third party search engines, like Google, because those are accessed more by our users. This decision implied that only a part of the search service had to be written (or, rewritten), because these URLs only have a limited number of filters that can be applied.

I started by studying the way search are performed on the monolith, discovering that each URL has a basic structure: /{category}-{contract}/{location}. This means that each search has a common “entry point” that is a category, each applying its specific domain conditions to the parameters. I could then easily identify each category as a “class of parameters” that had its own domain logic. The implementation was then trivial, because I just had to apply the factory pattern to produce the desired parameters to perform the request to the Solr web services. The end result is shown in this diagram.

An important decision that I want to mention is that the classes that store the parameters have all the attributes set to public. In PHP, when using the json_encode() function, classes that have parameters set with this scope perform better than implementing the JsonSerializable interface.

Socials SpA – (Dec 2019 – Mar 2020)

Socials is a messaging platform aimed at substituting the company’s current way of managing leads.

In the past, every successful lead from an advert made the user continue the conversation using its own email or telephone number.
This has now been substituted with Socials, which handles the messages and hides the email addresses of the users involved in the conversation.
Every user has its own masked email address that can be used to receive incoming messages from the other users.
The conversation can be continued either using the masked email addresses or using the web application. This allows the company to retain all the messages and to train artificial intelligence to recognize frauds and phishing.

This project helped me get even more familiar with Symfony, but most of all it allowed me to put into practice what I learned from university about managing a software project.

Valutazione Immobiliare SpA – (Jul 2019 – Sep 2019)

In 2019 my company acquired a startup called Realitycs that provides data and analysis about real estate trends. We revamped a product called “Valutazione Immobiliare” (i.e. “real estate appraisals”) that allows our users to get an appraisal of a property after completing a questionnaire.

I was responsible for creating a page to show our users the appraisals they have made. I did this by connecting the API exposed by Realitycs and generating a little preview of the property location. This was the last project where I had to make edits to HTML/CSS/Javascript before moving entirely to the back-end.

Mercato Immobiliare SpA – (May 2019 – Jul 2019)

Because we have access to many data regarding the properties our users list, we can plot Italy’s real estate trends to show information about how prices change in time.

We revamped this product by showing more data, including demographics details, and decoupled the back-end from the front-end.

I was responsible of importing the data from our sources and exposing an API to the front-end. The import process runs on its own every month, processing data from CSV and XLSX files. SpA – (Jun 2018 – Apr 2019) is a project focused on delivering the unique corporate technologies of to the Spanish market.

The road to kill the monolith started from here. We began working on a new homepage, exposing endpoints from the monolith.

This project was used as a benchmark for the development of new features later ported to our main market.