Jorge F.

When I joined this company, they had a modular product based on a custom NodeJS fork wich was back-end only, configured with JSONs and Javascript files. The product focuses on gathering and processing of data, specialized on the industrial sector, so users can manage all the data a factory needs between machines, databases, edge nodes, historize, and so on. They needed a web interface to manage their product, so they started the front-end department with me. We created an Angular-like framework where the components were synced via WebSocket, so the different hot-plug modules were able to send their specific components to the front-end. Now I lead the front-end department and co-lead the backend department (about 20% of it, along with the backend leader). Things I created that I like the most: - A drag-and-drop-and-excel-like KPI designer with a custom framework, where you can drag-and-drop different elements and, via a property editor, you can add expressions to link their different properties between other element properties or to the product data that is synced via WebSocket. - A React + Mobx web interface to manage in the cloud all the nodes a company has. The nodes are connected to a MQTT broker (VerneMQ) where the web interface and the databse cluster (MongoDB) are also connected and via this broker all the data is synced. The user can also create a tunnel where a port is open on the server, which is also connected to the MQTT broker, and via this single node connection to the MQTT broker, the TCP tunnel sends and receives the data, so the user can access local TCP ports in the node side from a remote location. - A React + Mobx alike framework specialized on fast redraw of data, without a virtual DOM in between. State management is detected using Javascript Proxies. This was created after the previous project, so the previous project is actual React. Worth noting that when my teammate and me got the back-end lead, have improved the performance by 2x-5x.

Co-founder and main only developer of a live video producer company specialized on athletics and cycling. Our main goal was to allow small events to stream the race to a big LED screen on the finish line, so the people can follow their relatives progress instead of just waiting for them to arrive. After 7 years, we stream to national TV stations some important athletics and cycling events in our country. The most difficult part was to send a fluid video feed from several motorbikes around the race to the production zone, where the images were mixed and sent to the LED screen. We reached a solution were we had a multi-node system where there was a main node and multiple sub-nodes (usually 6). Each sub-node had a 4G connection. The main node was the one creating the video feed, and, instead of sending the video feed using a single connection, it sent small frames to the different sub-nodes, which sent the frames to a server, and the server rearranged the video feed before sending it to the production zone. The protocol was made over UDP and it featured packet loss detection to resend to another sub-node and do not lose a single video frame, bandwidth management to select the less stressed sub-node to send each frame each time, and video bitrate update on-the-fly depending on the total bandwidth of all the sub-nodes, as sometimes the motorbikes go through zones with really low 4G coverage. All this was first made in C++, and later on switched to NodeJS (as I was enjoying Javascript way more) and squeezed with RPis, a bunch of power banks and a couple of 4G routers and modems inside a motorcycle suitcase.