George Cosma

Kopplr is a fintech startup that I worked on from the first day. It is a platform that acts as a central hub for merchants, providing all the services they need. The platform connects merchants with a payment gateway and other payment-related value-added services such as insurance and POS terminals.

This project was a microservice (CQRS) architecture. The front-ends (four front-end applications, not including mobile) were built with Vue, and the back-end was built on a combination of TypeScript and Haskell, depending on the service. We used DynamoDB (NoSQL) and Amazon Neptune (RDF Graph) as databases. It was all hosted on AWS.

I was more involved in the back-end and DevOps side of this project. Although I worked on the project for over two years, I contributed to the front-end when needed.

One of the more interesting parts I worked on was a data ingestion pipeline for transactions, for which I was responsible for designing and implementing. The challenging part was that it needed to handle millions of daily transactions (the peak was 3 million transactions in 8 hours), which I achieved using AWS services such as SQS and Lambda functions.

A custom trading algorithm that ran on the Paris stock exchange. The customer had developed his trading strategy over the years and needed to automate it and build and investment fund.

The back end was built using Interactive Brokers Trader Workstation Java SDK and Clojure with a PostgreSQL database. The front end was built using React and ClojureScript on Electron, with most communications between the two happening via WebSocket.

In addition to the actual trading algorithm and a screen for tweaking its settings, the app had user management for the investment fund, where users could invest or divest and see the fund's performance. We also had screens for live updates, both for the companies as a whole and more detailed individual screens, on which you could also view things such as transaction histories, performance reports, P/L, etc.

A challenging part of this project was handling the live updates for the companies. The SDK had a strange way of handling live data, and we hit some limits in React. But we fixed the problem with some magic, doing the updates in-memory on the server side and changing the rendering strategy in React, we fixed the problem. This was a fun engineering riddle to solve.

This application was a storage provider similar to Google Drive or Dropbox. Its differentiating feature was that users could encrypt files with a proprietary encryption algorithm and set permissions as to which other users could decrypt said files.

The application was a Java (Spring Boot) back end with a PostgreSQL database, Vue, and native mobile apps for the front end. The mobile applications were built for each platform individually, using Java for Android and Swift for iOS. The client needed a native mobile application to perform better when encrypting large files (we tested with 15 GB).

I started building the Android application from the ground up, but in around two years that I worked on the project, I also contributed heavily to both the back and front end.

The most interesting part for me was the custom encryption algorithm. In implementing it, I was required to go very deep into the mathematics of cryptography to understand it, and I even found a (minor) bug. It was surely a different challenge than I was used to at that point.

I created a self-hosted customer support chat solution. All the client had to run a binary on their server and include a script in their website (or install an extension if using a more popular CMS).

This was a long-term project (1.5-2 years) on which I worked alone and built every part of the application from the ground up. The back end was a Clojure web server with options to connect to any SQL database the client had, and the web app was initially built with Backbone.js, but we re-wrote it with ClojureScript and React. We also had a desktop app that was a simple Electron app with a web view. We initially used this web view for the mobile applications as well, but when the app was feature complete, I rebuilt them with React Native.

This application didn't have any particular part that was more challenging than any other, it was a well-rounded application that required a solid understanding of all the parts involved in web app development, and having worked on it during my formative years, it helped me see how everything fits together.

An application that allowed users to book hotels (similar to booking.com). It aggregated info from multiple feeds to which the client paid subscriptions. It required displaying multiple offers for the same hotel and allowing users to book what they saw as the best offer.

The application had Clojure as the back end with a PostgreSQL database. However, it did involve very heavy Java inter-op, especially for the code that integrated the feeds since all of them had old SOAP API-s, and the tooling for that was way better in Java. Each feed integration ended up being its own .jar file that we could dynamically include as needed. The front end was a hybrid of server-side-rendered code using Selmer (a Clojure templating language inspired by Django) and React via ClojureScript, where complex filtering logic was required.

One of the more interesting challenges was determining if info coming from multiple feeds was about the same hotel or not, since the same physical location was represented differently in every feed due to naming conventions or other factors. We solved this problem by implementing string similarity algorithms like Levenshtein distance in the database before inserting, and matching to a normalized version of the hotel.

A mobile app that allowed users to take pictures of their receipts and would do OCR on it in order to break down shopping items into categories and provide spending reports.

The mobile app was developed using React Native, while the back end was built with Python. The back end used Flask (Python) with a PostgreSQL database. The OCR was done in two parts. First, we detected text lines using OpenCV, breaking the image into text lines. We then send those lines to Google Cloud Vision, which returns the actual content that we store in the database for reports.

I was involved in the entire project, and we even reached the national phase of innovation labs with the project.

I was part of a full-stack TypeScript application project, utilizing React and Express with an SQLite database. The app's objective was to facilitate the management and disbursement of various social benefits for individuals. These benefits included child allowance, social income for people with disabilities, and unemployment benefits. The app had to manage which users received how much money from potentially multiple of these benefits on a per-month basis and deliver said money via multiple sources, including bank accounts at various banks, postal services, and national treasury. It also had to generate reports that could be sent to other institutions.

I was involved in this project from start to finish, including the architecture. We went for a client/server architecture that we bundled in an executable with Deno because the client wanted a desktop app that would eventually become a web app.

One technical challenge was the sheer amount of non-normalized data we had to parse each month. Simple ingestion of this would result in extremely long query times. We handled this by building an ETL pipeline that normalized the data and by clever database sharding.

Developed a TypeScript application using Node.js, React, and React Native, along with a MongoDB database. The purpose of the application was to display the real-time location of public transport vehicles in Alba Iulia, Romania. These buses provided free WiFi and connected to routers installed on streetlight poles throughout the city. The information from these routers was sent to a centralized system that we built. This system stored the location and identity data of the buses in a database for future traffic analysis. Additionally, we created mobile apps that allowed users to connect and receive live bus locations through Google Maps. This API was also utilized to show waiting times at bus stations.

Although the app itself was relatively straightforward, the challenge lay in managing the substantial amount of data generated by numerous buses operating simultaneously. Moreover, we needed to handle the high throughput of live data that had to be sent to users who required real-time updates, often reaching thousands of users simultaneously during peak times.

To handle this significant load, we employed a MongoDB database for its speed and utilized change streams to transmit live data to connected users.

I was involved in a project from its inception that entailed developing an application using AngularJS, Node.js, and TypeScript. The app's purpose was to provide pedagogy students with a simulation platform for teaching a class. The app featured multiple students, each with randomized attributes such as attentiveness, tiredness, and interest in the subject. These attributes influenced their interactions with one another and triggered random events like conversations, falling asleep, or asking questions.

The user's role was to respond appropriately to these events by engaging with the class by asking questions to the entire group, addressing specific students, or initiating tests. The application also incorporated a back-end system that stored user identity data and tracked game progress.

In this project, I was responsible for coding the entire back-end system and handling the front-end aspects, including designing the UI menu elements and defining the attributes and interactions among the "students."

A Laravel-based web app where companies answer questionnaires and get offered various reports and recommendations to increase their digitalization level.

From the start, I was involved in the project and participated in all aspects, including tech stack selection, design, and architecture.

There was no particular technical challenge in this project. The hard part was the very strict deadline of under two months.