Speaking of web design, it is impossible not to mention CSS. The sites we use daily work just on the HTML + CSS bundle. Moreover, CSS allows you to format a web document, making it more attractive and interesting for the user.
Using CSS made it easier to work with web documents and made life easier for many modern developers. And all this would be impossible without one person - Haakon Wium Lee, the creator of the SCC and an amazing person with incredible hobbies.
We managed to talk to him about his career at CERN, about unique facts in his biography and even asked for an opinion on ChatGPT. The most interesting answers, as always, are waiting for you on slides 👆🏻
Using CSS made it easier to work with web documents and made life easier for many modern developers. And all this would be impossible without one person - Haakon Wium Lee, the creator of the SCC and an amazing person with incredible hobbies.
We managed to talk to him about his career at CERN, about unique facts in his biography and even asked for an opinion on ChatGPT. The most interesting answers, as always, are waiting for you on slides 👆🏻
👍7
How often do you visit IT events? We try not to miss a single one. Each event is a chance to find out what our colleagues and friends have prepared, as well as the opportunity to meet amazing people.
We managed to talk to one of these people in Morocco, on the ninth "MirageOS Retreat." Meet Hannes Menert, co-author of MirageOS and an enthusiast who regularly gathers a community of developers around him. For those who are a little in the tank, we decrypt: MirageOS is a library operating system that is used in the development of unikernels. In turn, Unicernel is an application development framework that will run in a virtualization environment and can work autonomously without using operating systems.
We managed to discuss with Hannes his contribution to the development of such a mysterious MirageOS, as well as the benefits of OCaml. You can find all the details on the slides 👉🏻
We managed to talk to one of these people in Morocco, on the ninth "MirageOS Retreat." Meet Hannes Menert, co-author of MirageOS and an enthusiast who regularly gathers a community of developers around him. For those who are a little in the tank, we decrypt: MirageOS is a library operating system that is used in the development of unikernels. In turn, Unicernel is an application development framework that will run in a virtualization environment and can work autonomously without using operating systems.
We managed to discuss with Hannes his contribution to the development of such a mysterious MirageOS, as well as the benefits of OCaml. You can find all the details on the slides 👉🏻
👍9❤4🔥4
Today, we begin an exciting series of posts dedicated to one of the cornerstone features of the Ruby on Rails framework — routing. In this first part, we will delve into the depths of the architectural principle that underpins it — REST (Representational State Transfer).
Routing in Rails doesn't just allow your application to respond to HTTP requests; it does so by adhering to strict yet flexible REST rules, ensuring clarity and understanding of your application's architecture. This not only simplifies development and maintenance but also makes your application more intuitive for other developers.
In this post, we will touch on the key aspects of routing and REST principles, setting the stage for deeper exploration in subsequent parts of our series.
Join us on this journey through Ruby on Rails, and together we will learn how to use routing most effectively to create reliable and scalable web applications 😉
Routing in Rails doesn't just allow your application to respond to HTTP requests; it does so by adhering to strict yet flexible REST rules, ensuring clarity and understanding of your application's architecture. This not only simplifies development and maintenance but also makes your application more intuitive for other developers.
In this post, we will touch on the key aspects of routing and REST principles, setting the stage for deeper exploration in subsequent parts of our series.
Join us on this journey through Ruby on Rails, and together we will learn how to use routing most effectively to create reliable and scalable web applications 😉
👍10🔥8👏3
This media is not supported in your browser
VIEW IN TELEGRAM
BeRealFan: Where Architecture Creates Capability, Not the Other Way Around
We didn't assemble the platform from ready-made modules – we built it from scratch. Our team took on the full cycle: from UX design to infrastructure development, streaming, billing, and analytics. This allowed us to make architectural decisions at the system level, not just patch over someone else's bottlenecks.
Why? To create not just a "paywall" for content, but a full-fledged social network where monetization is a natural part of the environment, not an add-on.
Technical Foundation
We chose a stack that guarantees stability under load and handles complex logic elegantly:
✅ Backend: Ruby on Rails – for fault-tolerant handling of subscriptions and payments.
✅ Frontend: React –for a dynamic and responsive interface.
✅ Database: PostgreSQL – for transaction consistency.
✅ Infrastructure: AWS – for global scalability.
✅ Streaming: Our own multiplexer, integrated into the access control system.
What This Offers Content Creators:
1) A social network, not a storefront. It's a feed, comments, stories, and private messages – everything needed to build a community, not just to sell.
2) Tiered subscriptions. Creators can set up multiple pricing plans, unlocking different combinations of content, chats, and streams. The system checks access rights in real-time, without lag.
3) Live streams as a monetization tool. Private broadcasts, donations, and pay-per-view access are built into the viewing experience. Payments process instantly without interrupting the stream.
4) Chats that sell. Audience segmentation, bulk messaging to online users, response timers – chat becomes a practical tool for growth.
5) Analytics that lead to action. Dashboards show not raw numbers, but revenue per tier and content effectiveness, helping inform strategic decisions.
The result is a ready-made ecosystem where the creator focuses on content and audience, while technology ensures stable growth. The platform doesn't limit the business – it amplifies it.
We didn't assemble the platform from ready-made modules – we built it from scratch. Our team took on the full cycle: from UX design to infrastructure development, streaming, billing, and analytics. This allowed us to make architectural decisions at the system level, not just patch over someone else's bottlenecks.
Why? To create not just a "paywall" for content, but a full-fledged social network where monetization is a natural part of the environment, not an add-on.
Technical Foundation
We chose a stack that guarantees stability under load and handles complex logic elegantly:
What This Offers Content Creators:
1) A social network, not a storefront. It's a feed, comments, stories, and private messages – everything needed to build a community, not just to sell.
2) Tiered subscriptions. Creators can set up multiple pricing plans, unlocking different combinations of content, chats, and streams. The system checks access rights in real-time, without lag.
3) Live streams as a monetization tool. Private broadcasts, donations, and pay-per-view access are built into the viewing experience. Payments process instantly without interrupting the stream.
4) Chats that sell. Audience segmentation, bulk messaging to online users, response timers – chat becomes a practical tool for growth.
5) Analytics that lead to action. Dashboards show not raw numbers, but revenue per tier and content effectiveness, helping inform strategic decisions.
The result is a ready-made ecosystem where the creator focuses on content and audience, while technology ensures stable growth. The platform doesn't limit the business – it amplifies it.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥7👍3👏2
We solved a classic GPU underutilization problem for a European research lab. Their high-performance hardware was largely sitting idle. The root cause? Their system reserved an entire graphics card for every single task, large or small. Most workloads ended up using only 10-20% of the available power. Multiple teams then competed for these underutilized cards through a slow, manual management process. The result was zero visibility and zero efficiency.
Our approach? We didn't guess. We tested. On their actual, heterogeneous GPU fleet, we implemented and evaluated two strategies: partitioning the resources of a single GPU and intelligent time-scheduling. The data from these real-world tests gave us the correct configuration.
In eight weeks, we delivered. We built them a custom MLOps platform on Kubernetes, utilizing open-source tools like Ansible, Grafana, and Ray. This transformed their static hardware into a dynamic, shared resource pool. Now, tasks run in parallel, utilization is high, and they have complete control. There is no vendor lock-in. They own the platform outright.
The lesson is straightforward: often, you don't need more hardware. You just need to use properly what you already have.
Our approach? We didn't guess. We tested. On their actual, heterogeneous GPU fleet, we implemented and evaluated two strategies: partitioning the resources of a single GPU and intelligent time-scheduling. The data from these real-world tests gave us the correct configuration.
In eight weeks, we delivered. We built them a custom MLOps platform on Kubernetes, utilizing open-source tools like Ansible, Grafana, and Ray. This transformed their static hardware into a dynamic, shared resource pool. Now, tasks run in parallel, utilization is high, and they have complete control. There is no vendor lock-in. They own the platform outright.
The lesson is straightforward: often, you don't need more hardware. You just need to use properly what you already have.
🔥7❤3😁3👍2