As a Staff Mobile Engineer at Mews, I’ve come to realize the title “Staff Engineer” is quite vague, with responsibilities varying from company to company and even between departments. In my role, I don’t belong to any specific team; instead, I assist other engineers and teams with code reviews, architectural decisions, and ad-hoc issues. I also consult for other companies and startups, reviewing their code and mentoring their teams. This exposure to different approaches in app architecture has given me insights into what works and what doesn’t. Today, I’d like to discuss how to make your architecture simpler, more reliable, and more manageable.

This is the text version of my talk at Fluttercon Berlin 2024. You can find the video here.

This is the text version of my presentation at Flutter Czechia Meetup, where we delved into how Dart Code Metrics elevates your development game, making your coding process more efficient.

This article is based on a meetup talk I gave in January 2023.

I'm working as a Staff Mobile Engineer at Mews. What staff engineers usually do differs from company to company and even department to department. In my case, it means that I do not belong to any specific team, but rather, I help other teams on an ad hoc basis with things like code reviewing, mentoring, discussing architecture, and solutioning.

Besides this, I do some external mentoring and consulting, and of course, one of the most popular topics we discuss is app architecture. Since Clean Architecture is one of the most popular for apps in general and mobile and Flutter apps in particular, we discuss a lot of questions like what it is, how to do it better, and how to go about app architecture from the Clean Architecture point of view.

Here, I will be discussing Clean Architecture as well. The word "clean" in the title isn't in quotation marks because I see Clean Architecture as the opposite of pragmatic or vice versa. It's just that I often see many implementations of Clean Architecture in different tutorials and real-life projects that, from my point of view, don't follow its core principles. At the same time, there are some issues with the architecture itself. I believe it's not always a perfect fit for Flutter apps, so let's start with these issues.

Enter our career fair project​

For the latest career fair at MatFyz, we wanted to build something interesting: from one side, it should be more than just "here is our merch, come work with us"; from another side, it should showcase the products we were working on at Mews.

Since one of our products is a kiosk for self-service check-ins at hotels, we decided to emulate a hotel check-in experience with guests entering their details into a registration card, cutting their "key" with an emulated key cutter, and later taking part in a lottery with randomly selecting winning room numbers.

Всем привет! Представляю вам текстовую версию моего доклада на DartUP 2021 (сам доклад на английском можно найти здесь). Посвящен он довольно популярному архитектурному паттерну MVVM (он же Model-View-ViewModel), а конкретно той его части, что про ViewModel.

Паттерн этот весьма распространен в мире нативной Android-разработки – во многом благодаря тому, что является официальной рекомендацией Google. А поскольку многие Flutter-девелоперы попали в мир Flutter'а из нативного Android'а, то и подходы они склонны применять те же самые. Как говорится, работает – не трогай и ничего не меняй.

Но как по мне, в мире Flutter'а этот паттерн не то чтобы полезен, а скорее даже и вреден. И сейчас я буду вас в этом убеждать.

As you probably know, we have an app in Flutter that has been successfully running in production for more than 2 years now.

But we also have another app, a Kiosk application written natively in Kotlin and available for Android only. It was available, actually, as we decided to migrate it to Flutter as well. And here’s a report on why and how.

In code reviews, I often see a construction like this:

enum Some { option1, option2 }

final someCondition = Some.option2;

void main() {
  late final String x;

  switch (someCondition) {
    case Some.option1:
      x = 'a';
      break;
    case Some.option2:
      x = 'b';
      break;
  }

  print(x);
}

This article is all about promoting my Flutter library for showcasing isolated widgets and screens. Something like Storybook in the React world. Actually, it's even named storybook_flutter.

Всем привет! В этой статье я буду бессовестно пиарить рассказывать о своей библиотеке для Flutter'а, которая позволяет создавать истории из изолированных виджетов и/или экранов. Что-то типа Storybook из мира React. Собственно, она так и называется: storybook_flutter.

Это текстовая версия моей презентации на DartUp 2020 (на английском). В ней я делюсь проблемами, с которыми мы столкнулись, обсуждаю наш архитектурный подход, рассказываю о полезных библиотеках, ну и отвечаю на вопрос, удачной ли была эта идея – взять и всё переписать.