Vagif Abilov
Singing programmer
Oslo, Norway
Actions
Vagif works for Norwegian Broadcasting Corporation (NRK). He has about three decades of programming experience, currently focusing on building systems in F# and C#. Vagif is a frequent speaker at software conferences and contributor to some open source projects. In his free time he plays keyboards in The Linebreakers, teaches his pets programming and rides bikes.
Surviving Long Event History
Any system built on event sourcing principles needs to deal with event versioning soon after it goes into production. Systems that handle long lasting processes or contain long living entities may face additional challenges: how to optimize building states from large number of events? Should event streams be kept short? And what is the best approach to the design of systems where entities live for years, outliving technologies and development teams?
Come to my talk, and I will share the experience and views of our team where we are developing and maintaining applications for a large media company. Our choices are opinionated, but we have spent years on the design and implementation of our services, and we are modelling entities that live for decades.
Stay with C# or switch to F#? Let's fight! Let's vote!
We are two developers with a long experience in OOP, and in the .NET world it means C#. Both of us later discovered functional programming, and in the .NET world it means F#. One of us was convinced to make a switch to F# with its immutable data and terse syntax and never looked back. The other one was convinced that the evolution of C# and adoption of FP elements make it a solid language to take advantages of both paradigms. Perhaps both of us are right in our choices but what would YOU do?
Come to our session, and you will become our judge. You will be presented a series of small tasks with solutions in both languages, and you will vote for a winner in each category. Perhaps yo can make a choice for your own future?
Reliable messaging in the world of actors
Actor model frameworks use at-most-once delivery as a default rule for their message transport, and they do it for good reasons. Efficient reliable messaging requires business-level acknowledgement, and this it not something that the actor model framework is built for.
So how do we build a reliable actor based system? I will share the lessons from our journey through the world of actors where we revised an approach to a message delivery guarantee mutiple times. Our system is written in F# and uses Akka.NET, but this talk is language and platform agnostic, discussing common patterns and possible obstacles when choosing between various methods to achieve reliable messaging in a system run by actors.
reF#ACTORing using F# and Actor Model
Want to simplify state management, improve scalability and reduce the code base? Rewrite your system in F# and use the actor model (Akka.NET). The functional language discourages use of mutable state and actors contribute to efficient communication, routing and scalability. And what about the code base? The code metrics speak for themselves.
This is a talk about a concrete project at the Norwegian Broadcasting Corporation (NRK) where we summarize our experience writing a robust and performant message based system for distributing media files to the cloud.
Real time event visualization in F# and Fable
First time I saw Fable in action I was convinced: this is the tool for us, backend developers. At last we can write nice UI directly in F#. And we did. We went us far as writing a dashboard to monitor our system activities using Web sockets. The source code is written entirely in F# and compiled into JavaScript using Fable magic. In this talk we will build a similar dashboard, using pre-recorded stream of real time events. So if you are still in doubt that F# is a versatile language suitable for frontend development, come to my talk and I will try to change your mind.
Life after business objects. Confessions of an OOP veteran.
It finally happened: tired of mutable data structures and thread synchronisation, we decided to use functional programming and F# for the next generation of our system. Gigabytes of data are going through our applications every hour with high demand for performance, scalability and failure recovery. The fact that our project has for a long time been in production can identify it as success, but has the choice of FP become an essential part of this success? Could we achieve similar development speed and operational stability if we settled for OOP (and C# on .NET platform)? We believe that functional programming provides a set of defaults that can give significant advantages for development with short deadlines and continuous deployment, and we are going to share our experience and lessons learned in this talk.
Instrument your .NET services with OpenTelemetry tracing
In this 2 hours workshop we will learn how to instrument several .NET applications with OpenTelemetry tracing, so we can trace cross-service activites and visualize them using popular tools and dashboards. We are going to cover:
- Quick overview of OpenTelemetry standard
- Bootstrapping .NET applications with OpenTelemetry tracing
- Setting up Docker containers for additional services
- Tracing HTTP, database and message queues
- Exporting traces to Jaeger, Elastic APM and Honeycomb
- Running sample applications and inspecting generated traces
Prerequisites for the workshop:
- A computer with .NET/C# IDE (e.g. Visual Studio or Rider)
- Docker
- (optional) If you want to display traces in Elastic APM or Honeycomb you will need to set up and account there, otherwise you can use Jaeger
Frontend in F#? Hold my beer!
I am a backend developer, like many of you. So what should I do when I need to show some data? Write a console app (sigh)? Or maybe learn CSS and JavaScript (deeper sigh)? I am using F# and functional programming for my daily tasks, so when I heard about MVU pattern and functional approach to UI development offered by Elm language and brought to F# by Fable and its Elmish extension, I became eager to try it in our projects. Did it deliver? Was I really able to write a decent Web site all in F#? Come to my talk and you can judge for yourself!
Event journal in Azure (no Cosmos inside)
We no longer wanted to keep in-house terabytes of event journals from various applications. We have already been using Azure services, so moving our data from rusty MongoDB collections to Azure storage was a natural step. But should we keep using MongoDB API offered by CosmosDB? Or go over to its SQL API? Or maybe Table/Blob storage would be sufficient for our needs? In this talk we will share our decision factors, what choice we made, how much it cost and how it performs. You will also see the implementation details in C#.
Akka.NET from Zero to Hero
During this full day workshop we will practice implementing a scalable file distribution engine in C# or F# using actor model and Akka.NET.
You are not required to have prior knowledge of actor model or Akka framework, just bring a laptop with Windows or Mac and use your favorite .NET programming language with either Visual Studio or JetBrains Rider.
Workshop plan:
1. Introduction to actor model
2. Warming up
3. Writing actors
4. Actor supervision
5. Routing and scaling actors
6. Testing actors
7. Discussing results
Prerequisites:
1. Computer with either Visual Studio (2015/2017/2019) or JetBrains Rider installed.
2. Access to GitHub.
3. Knowledge of C# or F#.
4. If you want to become familiar with Akka.NET in advance, you can review tasks from Petabridge Akka Bootcamp (https://github.com/petabridge/akka-bootcamp), it has both C# and F# versions. There's no overlap between that bootcamp and our workshop, our tasks are all different.
5. While we will be building a file distribution engine, access to FTP server is not needed. We will use a mock that will simulate FTP operations on a local machine.
Akka Streams for Mere Mortals
How can we just in a few lines of code display a live stream of Twitter messages, extending them with weather forecast in the locations of tweet authors? And how can we limit the number of requests to the weather service, so they won't blacklist us? All of this you can see in the demo that will conclude the presentation. And prior to that we will cover the basics of Akka Streams - a technology that makes processing live streams of data as simple as writing LINQ expressions, without hand-written implementation of individual actors or Reactive Streams interfaces.
Actors in clusters: why, when and how
You have successfully applied the actor model to your software architecture. You have a robust and performant system, you are no longer busy synchronizing threads or writing try/catch/finally exception handlers. More of your time is now dedicated to better understand and model your domain, and actors are taking care of less creative tasks.
But your system is still running on a single server. Not only it will soon reach its hardware capacity, it is at constant availability risk. One of the reasons to choose the actor model was location transparency: frameworks like Akka let you seamlessly distribute the load between multiple cluster nodes. Is this what you need? When is it right time to support clustering? What does it take? And when can you manage without it?
We had to answer all these questions in our project at Norwegian Broadcasting Corporation (NRK) expanding our system to use Akka.NET cluster. Come to our talk and we share with you our experience and some of our secrets.
NDC London 2025 Sessionize Event Upcoming
Build Stuff 2024 Lithuania Sessionize Event
KanDDDinsky 2024 Sessionize Event
NDC London 2024 Sessionize Event
Build Stuff 2023 Lithuania Sessionize Event
NDC London 2023 Sessionize Event
Build Stuff 2022 Lithuania Sessionize Event
KanDDDinsky 2022 Sessionize Event
Re:factor 2022 Sessionize Event
Build Stuff 2021 Lithuania Sessionize Event
Build Stuff 2020 Lithuania Sessionize Event
.NET DeveloperDays 2020 Sessionize Event
NDC London 2020 Sessionize Event
KCDC 2019 Sessionize Event
NDC Oslo 2018 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top