Контакты в QR
Тимлид и инженер-программист, в первую очередь решающий проблемы, а не пишущий код. Лучший код — ненаписанный. Качество продукта — ответственность всей команды. Практик экстремального программирования и BDD. Спикер, тренер по TDD, член программного комитета конференций DUMP 2023-2026 (секция “Тестирование”) и TechLeadConf с 2025 года, организатор Code Retreat в России, экс-лидер Российского сообщества специалистов Salesforce, экс-коач проекта RAD Women.
А ещё: барабанщик, басист, муж, отец, Мастер Подземелий для семьи и друзей.
Практические тренинги для разработчиков и команд.
Двухдневный корпоративный интенсив для команд разработки.
Проекты, которые я запустил на “общественных началах” — open source, community, etc.
Проекты, в которых я принимал участие, но созданные другими людьми.
Начал разрабатывать интеграцию с Playwright, а так же предложил структуру API, которая теперь используется в Serenity/JS 3.0.
Здесь больше примеров.
Коллекция статей и докладов, которые я делал на различных конференциях и платформах. Темы разные: от разработки плагинов для VSCode до Agile, XP и BDD.
Здесь больше примеров.
Руковожу командой разработки процессов проверок KYC.
Достижения:
Разрабатывал сервисы для проверки клиентов (KYC, ЗСК).
Достижения:
Stack: Golang, Postgres, ClickHouse, Bash, Gitlab, microservice architecture
Возглавлял команду разработки решения для сбора документов поставщиков для принятия в программы торгового финансирования, а также управления программами торгового финансирования. Помогал командам работать по методологиям экстремального программирования и BDD.
Достижения:
Stack: Salesforce (Apex, lwc), Bash, TeamCity, Java (test framework), JavaScript, RHEL 7
В мои обязанности входило управление несколькими командами, а также разработка архитектуры решений на платформе Salesforce.
Достижения:
Помогал команде адаптироваться к Lean и Agile разработке. Также принимал участие в создании MVP в качестве разработчика.
Достижения:
Идеальный тест должен быть понятным и легко читаемым. Кроме того, любой тест так или иначе состоит из трёх частей: подготовка данных, действие над системой и проверка — Arrange, Act и Assert. Посмотрите на любой свой тест — и вы так или иначе обнаружите там эти части.
Я однажды разработал тестовый фреймворк для веб-компонентов, который состоял из 3х частей:
Этого было достаточно, чтобы юнит-тестировать веб-компоненты. Получались супер-декларативные тесты, которые было легко читать и легко писать. К сожалению, сам код фреймворка был утерян где-то в недрах Дойче Банка.
Вы, наверняка, каждый день на работе пулл реквесты заводите. А вы знаете зачем? Задумывались ли вы: может есть другой способ? Почему вообще делают пулл реквесты?
Историческая справка: pull request’ы появились как UX фича Github’а в 2008 году как удобная обвзяка над принятым тогда флоу. В те далёкие времена процедура запроса на стягивание (буквальный перевод pull request, на всякий случай) заключалась в том, что ты пушил код в свой форк и писал мейнтейнеру: “Братан, стяни, плз себе мои изменения”. Ментейнер стягивал, делал код ревью и слал тебя нафиг с твоими правками. Ну или всё-таки пушил в основную репу. Вот и всё. Никакого сложного интерфейса. Никаких кнопок “Approve” и “Merge”. И никаких “LGTM”.
Недавно у нас на работе завезли локальную LLM’ку с китайскими премудростями. Среди прочих возможностей там есть RAG’и. Для тех, кто ещё не преисполнился: RAG — retrieval augmented generation, то есть такая фигня, где LLM’ка не просто гонит шизу, а делает это, используя переданный ей большой кусок контекста. То есть если вы ей скормили, например, wiki по aichat (🌚), то она будет не просто фантазировать, а искать ответы в этом контексте.
Перспективы потрясающие, поэтому я решил тут же скормить электронному болвану документацию из нашего Confluence Data Center. Но меня ждало разочарование: даже через VPN наша конфлюха требует авторизации — нельзя даже читать.
Здесь больше примеров.