DartWay Ru | Flutter & Fullstack Dart

Dart — язык будущего?

О Dart обычно говорят только в контексте Flutter. А зря.
Это один из немногих языков, который с первого дня проектировался под производительный компилятор — и это видно в каждой детали.

Компилятор, который умеет всё
Dart изначально проектировался под производительный JIT/AOT компилятор — это не случайность, а архитектурное решение с первого дня.
Результат:
— работает как скриптовый язык (как Python)
— компилируется в нативный код (как Swift)
— компилируется в JS (как TypeScript)
— компилируется в WASM (в отличие от TypeScript)
— поддерживает stateful hot reload (больше так не умеет никто — разве что Erlang)

Один язык — четыре режима исполнения. Это инженерное решение, а не маркетинг.

Sound null safety — полноценный, на уровне компилятора. Не «добавили как в TypeScript». Гарантия: null там, где ты не ожидаешь, физически невозможен. Любая null-ошибка превращается из runtime-краша в compile-time ошибку. В продакшне это означает целый класс проблем, которых просто нет.

Sealed classes + pattern matching — компилятор знает все возможные подтипы sealed-класса на этапе компиляции. Switch по нему обязан покрыть все случаи — иначе ошибка сборки. Идеально для состояний: Loading / Success / Error. Забытый случай не доживёт до прода.
Records — возврат нескольких значений без создания отдельного класса. Выглядит как мелочь — на практике убирает кучу бойлерплейта.

— — —

Какие перспективы?
Dart проектировался для web, выстрелил во Flutter, сейчас идёт на бэкенд.
В эпоху AI-агентов строгая типизация end-to-end перестаёт быть академической строгостью. Когда агент генерирует или рефакторит код — он опирается на типы. Sound null safety и sealed classes дают ему точную модель того, что возможно в системе: меньше ошибок, надёжнее результат.
Я думаю, Dart — это язык будущего, и Flutter будет только одной из многих сфер его активного применения.

— — —

Вы уже используете Dart за пределами Flutter? Бэкенд, скрипты, что-то ещё — напишите в комментариях, интересно посмотреть на реальный опыт.

72% из вас уже что-то строят — и это круто.

Хочу познакомить вас друг с другом.

Напишите в комментариях о своём проекте — одной строкой: что это, на каком стеке, на какой стадии.

Если есть вопросы или застряли на чём-то — пишите тоже. Разберём вместе.

Интересно посмотреть что у людей в столе 🙈

Больше никаких редизайнов!

Хочу поделиться факапом. Самое обидное — повторяется уже третий раз.

Клиент приносит макеты. Говорит: редизайн, оцените. Смотрим — визуально похоже на то что есть. Говорим: 20–30 часов.

В итоге выходит под 80.

Почему так происходит? Редизайн выглядит как косметика — поменяли цвета, шрифты, отступы. Но внутри это совсем другая история. В новых макетах появляются поля, которых нет в API. Состояния, которых раньше не существовало. Логика, которую надо переписывать с нуля. Всё это не видно при беглом просмотре — но вылезает в процессе работы.

Разработчик уже зажат в цифру и дедлайн. У него нет времени и возможности обсуждать детали реализации — приходится на ходу придумывать, как натянуть новый дизайн на имеющуюся кодовую базу. Получается обычно не очень.

Последний случай: нужно показывать длительность видео в списке уроков. Казалось бы — мелочь. Разработчик решил читать длительность прямо с плеера на фронте. Плюс отдельный плеер под каждое превью.

3 видео в уроке = 7 инициализированных плееров одновременно. Краш эмулятора. OOM.

Правильное решение существует — хранить длительность на бэкенде, превью делать статичными кадрами. Но это решение нужно провести через процесс: обсудить, согласовать, переоценить. Разработчик, закрывающий задачу в последний вечер, не может себе этого позволить — он действует здесь и сейчас.

— — —

Я понял одну вещь.

Редизайн — это не «обновить цвета». Это новая задача. И оценивать её надо точно так же, как любую новую фичу: разбить на части, прописать спецификацию по каждой, оценить отдельно изменения в данных, в логике, в UI.

Беглый взгляд на макеты — это не оценка. Это обещание, данное вслепую. А последствия могут быть очень болезненными.

Больше так не работаем.

Пет-проект — это не игрушка-погремушка.

Большинство делают его для резюме или чтобы поиграть с технологией. Но это не то.

Настоящий пет-проект — это продукт. Цель одна: создать что-то рабочее, что дойдёт до реальных пользователей.
Не «лежит в репозитории». Не «доделаю когда-нибудь». А до живых людей, которые это используют.

—

Поэтому выбор идеи важен. Три вопроса перед стартом:
— Реалистично довести до пользователей?
— Тебе самому интересно настолько, чтобы не бросить?
— Решает реальную проблему, а не придуманную?

И стоит хотя бы немного следовать принципам стартапа: сначала проверить идею, потом строить. Сделать MVP быстро, показать живым людям, собрать фидбек. Иначе — в стол.

—

Несколько примеров, которые мне нравятся:
📌 Nomad List — начался как Google-таблица «куда ехать фрилансеру». Pieter Levels завернул в сайт за несколько дней, случайно запустил, попал на первое место Product Hunt и HN одновременно. Сейчас бизнес на миллионы, который он ведёт один.
📌 RemoteOK — следующий его проект. Одна PHP-страница, агрегирует вакансии для удалёнщиков. Без фреймворков. Генерирует десятки тысяч долларов в месяц.
📌 Cashew — Flutter-приложение для учёта бюджета. Один разработчик, 4.9 ⭐️, 100k+ скачиваний. Начиналось как личный трекер расходов.
Что общее: простая идея, реальная проблема, доведено до пользователей.

—

Пет-проект — это не про технологию.
Это про то, чтобы пройти весь путь: от идеи до человека, который это использует. Этот опыт не заменит никакая рабочая задача.

Всё больше использую нейросети в работе, но не в плане сделай вместо меня

Наибольший эффект я вижу в режиме - давай сделаем вместе гораздо лучше, чем я или ты могли бы сделать по отдельности

На скрине простой пример - я делаю скрипт для удаленной настройки сервера
- я даю вводные, что и как должно работать, указываю ключевые ограничения и принимаю решения
- AI всё аккуратно сверяет и оформляет

Я бы никогда в жизни не сделал всё так аккуратно и подробно

Первичный тест прошел удачно, так что выкладываю в публичный доступ

Немного поясню - о чём речь.

Я сделал бот для тренировки прохождения интервью - он попросит у вас резюме и задаст несколько вопросов - всё по логике обычного интервью.

В конце бот даст развернутую обратную связь
- % вероятность пройти собеседование
- что было классно
- чего не хватило

Это просто бот, просто AI, не стоит быть слишком строгим к нему.
Но если вы подойдете ответственно и будете отвечать на вопросы серьезно, то рекомендации точно будут для вас полезны.

Переходите в бота, пробуйте.
@dartway_interview_bot

Если что-то не работает, пишите, буду чинить

Как я за 2 дня собрал AI-тренажёр для собеседований

Недавно писал про инструменты продвижения с помощью AI. Одна из идей — создать бесплатный цифровой продукт для привлечения целевой аудитории.

Эта идея мне особенно понравилась. Во-первых, это реальная ценность для людей, а не просто реклама. Во-вторых — я получаю живой опыт разработки AI-продуктов, который потом превращается в экспертизу. Убиваю двух зайцев.

Выбрал нишу которую знаю хорошо — Flutter-разработка. Сделал тренажёр для подготовки к собеседованиям.

Как это работает

Отправляешь PDF резюме → бот анализирует его через Claude API → проводит интервью в два блока: сначала про реальный опыт и проекты, потом технические задачи → в конце даёт развёрнутый фидбек с вердиктом, сильными сторонами и зонами роста.

Никаких шаблонных вопросов — AI выбирает что спрашивать исходя из твоего резюме и уровня.

Для меня непривычно было вообще не трогать код. Я внимательно смотрел и направлял все технические решения, но не написал ни одной строчки - что-то новенькое для меня.

Большую часть времени я не писал код — я думал. Архитектура диалога, логика блоков, что проверять у junior vs senior, как формулировать фидбек чтобы он был честным но не демотивирующим.

Claude Code справлялся с реализацией быстро. Моя работа — быть продуктовым думателем, а не кодером.

Это и есть AI native подход — не "AI вместо меня", а "я думаю, AI делает".

В ближайшие дни провожу закрытый тест, после чего выложу инструмент в открытый доступ. Следите за обновлениями 👀

😂 Не знаю, о чём это говорит, но мне очень нравится программировать и эти выходные я как раз посвятил созданию интересного инструмента для вас

Собрал телеграмм бота для тренировки собеседований - для начала хочу протестировать в закрытом режиме с небольшим количеством пользователей

Напишите в комментариях, кому интересно попробовать - я дам ссылку

Зачем разработчику разбираться в продукте

Сегодня стартует первая группа обучения. Как вводное задание я попросил ребят описать свои проекты по четырём пунктам — ЦА, боль, решение, челлендж. Получил резонный вопрос: «А нам это вообще зачем?»

Думаю, ответ будет полезен многим — особенно сейчас, когда AI всё активнее заходит в работу разработчика.

Есть две ветки, и в обеих продуктовое мышление работает.

Ветка первая — свой продукт или стартап
Здесь всё очевидно: ты сам принимаешь решения, что делать и как. Без понимания продукта тут далеко не уедешь.

Но даже если ты не собираешься уходить из найма, свой пет-проект — это сильная штука. Прокачка навыков, плюс кейс в портфолио. А чтобы кейс действительно играл на тебя на собеседовании, в нём должно быть видно не только «я написал», но и «я понимал, для кого и зачем». Без продуктового мышления получается просто демка — таких много.

Ветка вторая — найм
Тут две причины, и вторая важнее, чем кажется.

Первая — ты ценнее в команде. Разработчик, который понимает, что нужно бизнесу и почему фича делается именно так, ведёт себя в проекте иначе. Он задаёт правильные вопросы на старте задачи, замечает противоречия в требованиях до того, как написал код, и предлагает решения, до которых не додумался продакт. Это не «инициативность» как абстрактная черта — это конкретный навык, и он напрямую конвертируется в грейд и доход.

Вторая — ты выбираешь работодателя осознанно. Один из самых интересных карьерных треков — это работа в стартапах: там быстрый рост, опционы, реальное влияние на продукт. Но это работает только если ты умеешь отличить стартап с шансом от красиво упакованного пузыря. Без продуктового мышления ты в этой оценке слепой — смотришь на офис, зарплату и презентацию основателей, а не на ЦА, боль и unit-экономику. И ставишь годы своей жизни на проект, который изначально не имел шансов.

И про AI

Та часть работы разработчика, которая «получил тикет — написал код», сжимается быстрее всего. Cursor и Claude уже делают её достаточно хорошо, а будут делать ещё лучше. То, что AI пока не делает за тебя — это понимать, какую задачу вообще стоит решать и почему именно так. Продуктовое мышление — это ровно тот навык, который остаётся за человеком и которым ты отличаешься от исполнителя, легко заменяемого инструментом.

Поэтому я и включил продуктовое задание в первый день обучения. Не потому что мы будем делать стартапы — а потому что без этой оптики все остальные технические навыки имеют меньшую цену, чем могли бы.

🔥 dartway_router 1.1.0

Обновление под go_router 17.2.3 — плюс новые возможности и важный фикс.
—
⚠️ Breaking change
Все route-enum'ы, реализующие DwNavigationRoute, должны добавить геттер:

@override
DwStatefulShellRouteBuilder? get statefulShellRouteBuilder => null;

Компилятор укажет, где именно.
—
Что добавилось
statefulShellRouteBuilder — правильный способ строить bottom nav bar с независимыми ветками навигации. Scroll-позиция, дочерние экраны и состояние виджетов сохраняются при переключении вкладок. Рекомендую переходить на него вместо shellRouteBuilder для любого layout с табами.
onEnter — хук, срабатывающий до redirect и zoneGuards. Удобно для аналитики или любой логики перед матчингом маршрута.
caseSensitive (default true) — чтобы /Profile и /profile резолвились в один маршрут.
shellNotifyRootObserver (default true) — контролирует, получает ли root observer события из ShellRoute-зон.
Fix: DwPageBuilder.slide — параметр from теперь описывает направление входа. AxisDirection.right — страница въезжает справа. Раньше offset был инвертирован.
—

dart pub add dartway_router

github.com/dartway/dartway_router
Готово к копипасту. Подчёркивания в именах экранированы, блоки кода в обратных кавычках — Телеграм их отобразит моноширинным шрифтом с кнопкой копирования.

Git — одна из тех тем, где споров и документации бесконечно много, а рабочая методология умещается в несколько правил.

И эта методология подойдёт большинству проектов и команд.

Две специальных ветки
master — продакшн, то что видят пользователи. develop — стейджинг, то что проходит тесты перед релизом.
Под каждую задачу — отдельная ветка

feat/user_avatar_upload-APP-42
fix/login_crash_on_ios-APP-43

Формат: (feat|fix)/snake_case_описание-ЗАДАЧА-НОМЕР. Только английский, только lowercase. Привязка к задаче обязательна — через полгода будет понятно, зачем вообще это менялось.

PR и code review
Фичи и фиксы вливаем в develop через PR. PR проходит code review и вливается в режиме squash and merge — все коммиты ветки схлопываются в один.
Почему squash: история develop остаётся чистой. Один PR — один коммит. Не нужно читать «wip», «fix», «fix2», «наконец работает».

Из develop в master
Когда develop протестирован — вливаем в master прямым merge, без squash. Нужно сохранить все коммиты из develop в истории master, чтобы истории веток не расходились.

Актуализация ветки перед PR — rebase
Пока пишете фичу, в develop вливаются другие PR. Перед созданием PR актуализируйте свою ветку:
bash

git fetch origin
git rebase origin/develop

Rebase переносит ваши коммиты поверх актуального develop по одному. В отличие от merge — не добавляет лишний merge-коммит, история остаётся линейной. Но если ветки сильно разошлись, конфликты будут на каждом коммите — это больно.

Главное правило: актуализируйте ветку часто. Синхронизируетесь раз в день — rebase пройдёт незаметно. Ждёте неделю — готовьтесь к боли.

После rebase нужен force push:

git push --force-with-lease

Именно --force-with-lease, не --force — защитит если кто-то успел запушить в ту же ветку.
Если конфликты — решаете, затем:

git add .
git rebase --continue

Если что-то пошло не так:

git rebase --abort

Именование коммитов

feat: user avatar upload #APP-42    ✓
fix: login crash on ios #APP-43     ✓
added new feature                   ✗
fix2                                ✗

Формат: (feat|fix): краткое описание #ЗАДАЧА-НОМЕР. Заголовок PR становится сообщением squash-коммита — он должен быть понятным.
Это не весь git и не единственно верный подход. Это база, которая работает в команде и не создаёт боли при поддержке проекта.

ПС - в любой непонятной ситуации

git status

Если полистать каналы про Flutter — почти везде одно и то же.
Как настроить GoRouter. Как подключить Firebase. Как сделать анимацию. Пост, скриншот, ссылка на доку.

Это всё здорово и полезно, но писать ещё один такой канал я точно не хочу.
И вот почему.

Есть два типа знаний.

Инструментальные — это "как сделать X". Все те же how to.
Их в интернете полно, любая тема — десятки статей и видео.

Системные — это "как думать про X". Почему в одних обстоятельствах решение хорошее, а в других — катастрофа. Какие силы действуют в задаче и что они требуют.

Инструментальных знаний полно, но у них две проблемы, из-за которых разработчик годами топчется на месте.

Первая: повторение по гайду работает в границах гайда.
Шаг в сторону — и всё сыпется. Потому что нет понимания, зачем вообще это нужно.

Вторая: изучать всё подряд "вдруг пригодится" — долго, утомительно и зачастую бесполезно.
К моменту, когда тема понадобится, ты половину забыл, а другая половина устарела.

Системные знания решают обе проблемы.

Вы не помните конкретный how to, но вы понимаете, как это работает в целом и что важно учесть. Дальше how to гуглится за 5 минут или решение делается через нейросеть — а дальше адаптируется под ваш случай.

Поэтому канал — про почему, а не про как.
"How to" вы и без меня найдёте.

ПС. интересный момент, что системные знания можно приобретать из контента практически по любой теме - хоть из компьютерных игр, хоть из кулинарных рецептов, но это уже более широкая и глубокая насмотренность, которая формируется только с годами опыта

Три мини-пакета, которыми я пользуюсь в каждом проекте.

1. gap
Делает то, что должен был делать сам Flutter — добавляет пустое пространство между виджетами в Row и Column.

Без него: SizedBox(height: 16) или SizedBox(width: 16) — и каждый раз думаешь, height или width в зависимости от направления.

С ним: Gap(16) — и работает в любом направлении автоматически.

Мелочь? Да. Но когда таких "мелочей" в проекте сотни — экономия времени и чистоты кода ощутимая.

2. conditional_parent_widget
Решает проблему, с которой каждый Flutter-разработчик сталкивался: нужно обернуть виджет в другой виджет только при определённом условии.

Без него — городишь if/else с дублированием child-а внутри обеих веток.
С ним: указываете условие, родителя и child — и получаете чистый код без дублирования.

Особенно удобно, когда оборачивающих условий несколько (например, на разных платформах разные обёртки).

3. device_frame
Я любой проект публикую и на web — это бесплатно и очень удобно для оперативных демо и тестов

Но web открывается на широких экранах, а приложение спроектировано под мобильный размер. Без обёртки получается странно: контент болтается посередине пустого экрана.

device_frame даёт ту самую рамку телефона, в которую можно завернуть приложение на web — и оно сразу выглядит так, как должно.

Сохраняйте — пригодятся.

На группу осталось 2 места, заполняйте анкету, чтобы успеть в первый поток - на самых выгодных условиях

Хотел написать обзор про архитектуру. Плюнул.
Хотел сделать обзорный пост про подходы к структуре проекта и организации разработки. Clean Architecture, feature-first, DDD, TDD — всё как положено: суть, плюсы, минусы, что почитать.

Набросал драфт. Почитал. Плюнул.

Куча мутных слов и абстракций — и очень мало толку для реальной жизни. И пока пытался свести это в нормальный текст, понял, почему мне самому это не заходит.

Сформулирую.

Проблема первая. Эти концепции выросли не из нашего мира.
Clean Architecture, DDD — это мир больших, долгоживущих серверных систем. Сложный бизнес-домен, команды в десятки человек, горизонт жизни проекта — годы. Там эти подходы решают реальную боль.

Flutter-приложение — чаще всего другое. Тоньше домен, меньше команда, короче цикл. И когда концепция из одного мира переносится в другой, она переносится с трением: формально слои есть, а боль, ради которой они придумывались, — отсутствует. Остаётся ритуал без причины.

Проблема вторая. Все они продаются как ультимативное решение какой-то глобальной проблемы.
А в реальности глобальной проблемы нет. Есть совокупность требований и кодовая база, в которой важно не запутаться. Всё.

И главная цель архитектуры — не «соответствовать подходу». Цель — чтобы разработчику было удобно. Чтобы новые фичи делались быстро и легко, а старые при этом не ломались. Прагматичная, приземлённая задача — без пафоса про «чистоту» и «правильность».

В этом контексте большинство концепций превращаются в монструозный оверхед, который отъедает время. А дальше — то, что я видел не раз. В условиях ограниченных ресурсов строгое соблюдение неизбежно сыпется. Начинаются компромиссы, исключения, «здесь по-быстрому». И проект, который задумывался как образцовый Clean, превращается в кашу — только теперь это каша со слоями, и разобраться в ней сложнее, чем в честном простом коде.

Тут важно не уйти в другую крайность. Я не говорю «архитектура не нужна» — без неё проект тоже превращается в кашу, просто быстрее. Я говорю про другое: знание названий подходов и умение выстроить удобную кодовую базу — это разные навыки. Первое часто выдают за второе.

И теперь — то, ради чего я вообще сел это писать.
Все эти концепции создавались до эры AI. В мире, где написание кода стоило человеко-часов. Где каждый класс, каждый слой, каждый интерфейс — это время живого разработчика. В таком мире структура, экономящая усилия на больших дистанциях, оправдывала свою цену.

Сейчас код пишется условно мгновенно и условно бесплатно. И вся экономика, на которой стояли эти подходы, поехала.

Главным ограничителем разработки становится не скорость написания кода. Им становится проработка требований и проектирование фич. Понять, что именно надо построить. Разложить это на части. Продумать поведение, граничные случаи, связи. Вот где теперь узкое место.

И вот в этих задачах Clean, DDD, TDD не помогают примерно никак. Они про то, как разложить код — а не про то, как понять, какой код вообще нужен.
Поэтому драфт обзорного поста отправился в корзину. Думаю, дальше интереснее говорить не про то, как нарезать папки, а про то, как в новых условиях проектировать фичи. Этим и займусь.

Поговорим немного о карьерных перспективах

Кажется, эпоха «просто хорошего разработчика» заканчивается.
Раньше крепкий миддл = хорошая зарплата и светлые перспективы, сейчас это уже не так.

AI меняет рынок, количество задач, где нужен просто аккуратный исполнитель стремительно сокращается.

Поэтому предлагаю обсудить, к чему стоит стремиться, чтобы не остаться за бортом.

1. Senior / Architect
Это, наоборот, становится еще ценнее.

Топовый инженер:
- глубоко знает свою технологию,
- умеет использовать AI как усилитель,
- понимает архитектуру,
- разбирается в продукте и бизнесе.
И самое важное — умеет брать ответственность за результат.

Тут вижу два основных сценария - корпорации и стартапы. У них немного разные приоритеты и портрет идеального кандидата, желательно заранее решить, в каком направлении хочется развиваться.

2. Фрилансер-универсал
Очень сильный сценарий ближайших лет.
Соло-разработчик, который:
- умеет делать frontend + backend + инфраструктуру,
- использует AI на всех этапах,
- умеет работать с клиентом и требованиями.

Благодаря AI появляется новый тип специалиста:
не «исполнитель задачи», а маленькая продуктовая команда из одного человека.
И мне кажется, спрос на таких людей будет только расти.

3. Фаундер
Никогда раньше запуск продукта не был настолько доступным.
Но эта легкость приносит с собой колоссальную конкуренцию, так что этот путь стоит выбирать только тем, кто хорошо подготовился и уверен в собственных силах.

На этом пути есть 2 основных направления
- стартап - прогрессивная идея, которая может либо загнуться, либо сделать создателей богатыми и знаменитыми
- коммерческий продукт - что-то понятное, сделанное хорошо и приносящее несколько тысяч долларов в месяц на подписках

Если коротко — ценность смещается:
от написания кода → к созданию результата,
от узкой специализации → к универсальности,
от количества людей → к скорости и эффективности,
от исполнения → к ответственности и продуктному мышлению.

🚀 Запускаю учебную группу для Flutter-разработчиков

За последнее время пообщался с несколькими разработчиками из сообщества и заметил, что у многих повторяются одни и те же проблемы:

— код работает, но проект со временем начинает разваливаться
— непонятно, как строить архитектуру и развивать её дальше
— сложно принимать инженерные решения
— AI уже используется в разработке, но мало кто понимает, как делать это грамотно

Поэтому на следующей неделе запускаю первую учебную группу.

Это не курс в формате:
“повторяем код за преподавателем”.

Хочу сделать практическую группу про реальную разработку приложений:
— архитектуру
— инженерное мышление
— UX
— code review
— рефакторинг и развитие проекта
— и использование AI в ежедневной разработке

Формат:
— 4 онлайн-вебинара
— теория + разбор реальных примеров
— практические задания в вашем проекте
— разборы кода и инженерных решений участников

Также будет расширенный формат участия с персональным разбором вашего проекта.

Группа будет небольшой, чтобы можно было нормально разбирать вопросы и код участников.

Детальную программу и условия участия отправлю после заполнения анкеты 👇
https://forms.gle/BnokfcKSbtkT1gK46