Наш Донер 42 ещё совсем маленький, но в его приложении есть свои фишечки. Вот топ-5 «крышесносных» фич от Арсения Васильева, главного по айти в Донер 42:

🔹 Автосборка комбо — когда клиент заказывает Греческий Макси донер, картошечку, айранчик. Заходит в корзину, а приложение предлагает сконвертировать её содержимое в комбо по более низкой цене. Пусть так мы не зарабатываем случайные деньги, которые могли бы получить, зато повышаем лояльность.

🔹 Синхронизация с приложением «Здоровье» на iOS. Нам хотелось сделать что-нибудь приятное для аудитории, которая следит за своим питанием: теперь при создании заказа калории автоматически запишутся в «Здоровь». 7% пользователей уже включили эту синхронизацию.

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

🔹 Сохранение убираемых ингредиентов. Например, клиент не ест лук. Вместо того, чтобы убирать его из ингредиентов постоянно, гораздо проще один раз сохранить ингредиент в списке убираемых — тогда его перестанут добавлять во все продукты и в последующих заказах.

🔹 Донер-встряска. Для супер-юзеров, которые хотят исследовать приложение, разработчики обычно добавляют пасхалки. Чтобы увидеть нашу, надо потрясти телефон на главном экране. Мы сделали Донер-встряску по аналогии с функцией «Мне повезёт» в поисковиках. Клиент не знает, что сегодня съесть на обед? Достаточно потрясти телефон и мы предложим случайный выбор. Никаких рекомендательных алгоритмов, просто старый добрый рандом.

А какую самую классную фичу вы встречали в приложениях для заказа еды?

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

У нас всё начинается с прожарки идеи для новой фичи. За экспериментальным спринтом мы наблюдали на прошлой неделе — ребята вчера провели ретро и уже совсем скоро поделятся результатами.

А в этой статье наш iOS-разработчик Кирилл Орлов рассказывает, как обычно выглядит полный процесс разработки фичи на примере интеграции чата в приложение. Заглядывайте на Хабр, читайте и задавайте вопросы в комментариях.

Эксперимент «От постановки проблемы до проверки прототипа за 3 дня», ретро и выводы

💙 Начнём с того, что понравилось:
— скорость. Хоть и казалось, что всё на бегу, делать дольше было бы сильно утомительнее;
— полное погружение: не отвлекались на другие задачи;
— удалось и покреативить-порисовать от души, и связь с реальностью сохранить;
— спустились к пользователю с «вижен» облачков;
— получили результат.


⚙️ Что учесть на будущее:
— составить подробное расписание и равномерно распределить нагрузку до старта, чтобы все участники знали заранее, что и когда их ждёт. У нас не получилось, потому что запускали эксперимент спонтанно;
— спринт хорош для проверки одной гипотезы и одного исследования, иначе что-то выпадет из фокуса и будет делаться по остаточному принципу. Так у нас вышло с экстра-продуктами;
— нужны активности в первый день для сближения, если в команде есть незнакомые друг с другом люди. Лексуса надо было приводить в первый день 🙂
— все участники должны верить в идею эксперимента — это важно для успешной работы команды;
— тест с клиентами лучше проводить в отдельный день и закладывать время на опоздания. Мы проводили вечером в последний день эксперимента — были почти без сил;
— заранее подумать о том, кого позвать на тест — в идеале должен быть пул клиентов, состоящий не только из знакомых и из знакомых знакомых, тогда не будет искажений в выборке;
— для прототипа лучше использовать другой инструмент и как можно тщательней прорабатывать основной сценарий.

💡 Выводы
Мы немножко и упоролись, но получили результат за 3 дня. Нас было шестеро — и это оптимальное количество людей, чтобы подойти к проблеме с разных сторон. Пять человек захотели участвовать ещё в таких экспериментах. Сам формат спринта показался хорошим для офлайна, в онлайне так не выйдёт.

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

#продактвогне

Команда архитекторов из Тинькофф организовала книжный клуб Code of Architecture — для всех, кто строит программные системы. Сейчас читают книгу Software Architecture: The Hard Parts и позвали наших ребят из «Читаем вместе» поучаствовать в обсуждении.

Четвёртую и пятую главу разберут вместе с Юрой Пастушенко (Юра руководит командой автоматизации системы контроля качества в Dodo):

— обсудят подходы к архитектурной декомпозиции приложения (component-based decomposition и tactical forking);
— детально поговорят про component-based decomposition: расмотрят пошаговый процесс декомпозиции на основе компонентов.

Трансляция будет на ютуб-канале в четверг, 2 июня, в 18:00 (ссылка будет чуть позже), а пока можно посмотреть разбор первых трёх глав книги.

Всё-таки это было легендарно!

Лёша Берёзка, наш iOS-разработчик, рассказал историю того самого «ретро»: как он готовил мир под сценарий самой встречи, как беспокоился о том, чтобы ребятам было всё понятно, а на самом деле всё получилось… Да отлично получилось, на 10 из 10!

Тут вся правда.

Ура, организаторы DotNext выложили в открытый доступ материалы с прошлогодней конференции! Это значит, что и мы теперь можем поделиться с вами записью доклада Антона Оникийчука и Андрея Парамонова про кеширование данных.

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

О чём рассказывают Антон и Андрей:

— какие пути кеширования данных прошли (внутренние in-memory и распределённые кеши, кеширование ответов на стороне приложения, кеширование на nginx);

— какие проблемы поймали с каждыми из них;

— как сделали так, что самый частый запрос к API сайта работает совсем без кешей;

— что планируем делать дальше.

Если вы пишете сервисы, которыми пользуется неограниченное количество пользователей и нагрузку спланировать тяжело — вам точно нужно посмотреть этот доклад. Кстати, он попал в топ-10 докладов, которые особенно понравились участникам конференции!

13 и 14 июня наши ребята выступают на TechLeadConf.

Доклад Миши Рубанова посвящён TDD в мобильной разработке. Он расскажет, как мы определяем интеграционные тесты. Покажет на примере, как управление через зависимости позволяет изолировать сценарий.

По теме ТDD на конференции будет три выступления, после которых состоится круглый стол с обсуждением вопросов, когда этот подход можно применять.

Доклад Виталия Помозова — про подходы, которые позволяют нам релизить не глядя. Он расскажет про опыт тестирования сервиса учёта, за который отвечает его команда, как мы реализуем CI/CD и реагируем на проблемные релизы. А также рассмотрит риски и причины, по которым это может подойти не всем.

Будем рады видеть вас на наших докладах и пообщаться в перерывах!

Когда мы распиливали платёжный шлюз, нам понадобился RPC-фрейворк. Сначала мы выбрали Thrift, но потом всё-таки перешли на gRPC.

Андрей Парамонов расскажет, почему это произошло, с какими проблемами мы столкнулись и про прикольные штуки в .NET 5, 6 и 7, которые делают gRPC дефолтным выбором для взаимодействия микросервисов. Разберёт особенности работы в K8s. Покажет, как использовать кусочки этой технологии по отдельности.

Если уже купили билеты на DotNext, добавляйте в избранное, чтобы не пропустить.

16 июня, начало в 16:30, онлайн.

Обычно мы ходим на конференции как слушатели и как участники. А несколько ребят из нашей большой IT-команды входят в программные комитеты (ПК) конференций. Нам стало интересно, чем, собственно, они там занимаются? Поговорили с Евгением Иванченко, лидером Web QA в Dodo Engineering, — он состоит в ПК TechLeadConf.

Чем занимаются в ПК IT-конференций?

— У ПК есть несколько основных задач:

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

2. Поиск докладов и докладчиков. Конечно, можно полагаться на то, что докладчики сами к нам придут с нужными темами, но этого недостаточно. Мы ищем людей, которые уже что-то рассказывали про интересующие нас темы или которые могут рассказать что-то интересное нашей аудитории.

3. Работа с докладчиками. Мы утверждаем темы, помогаем поработать над структурой доклада, обсуждаем выводы и как они были получены. Задаём уточняющие вопросы, чтобы понять, что именно будет в докладе. Помогаем улучшить его с точки зрения подачи, взаимодействия с аудиторией и динамики. Помогаем отбросить лишнее. Часто приходят докладчики с огромным массивом информации, который невозможно уложить в один доклад на 40 минут, тогда нужно на чем-то фокусироваться. Определяем, что интересно и докладчику, и аудитории конференции.

4. Небольшая часть работы состоит в том, чтобы проработать идеи мерча, подарков, стикерпака конференции. Поучаствовать в продвижении, написать статью, сходить на подкаст или дать интервью.

Сколько времени ты тратишь на это?

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

Какие есть плюсы и минусы?

— Минусов не вижу, зато плюсы очевидные:

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

Продолжаем поход по офлайн-конференциям! Следующая — Heisenbug в Санкт-Петербурге.

Дмитрий Тучс, Head of QA в Dodo Engineering, считает, что опыт «разработки и поддержки QA-фреймворка» в резюме автоматизатора — скорее недостаток, чем преимущество. Потому что очень часто QA-фреймворки бесполезны для бизнеса, усложняют написание тестов вместо того, чтобы упрощать этот процесс. Зачастую они пишутся QA-инженерами, которые не обладают достаточными навыками, чтобы сделать аккуратный, минималистичный и действительно полезный фреймворк. А в половине случаев то, что называют фреймворком, на самом деле просто «набор полезных методов».

В докладе Дима поделится своим видением, сколько публичных классов должен иметь «идеальный» фреймворк и почему. Рассмотрит практические вопросы по работе с БД (JPA/Hibernate), с REST и gRPС и действительно ли нужен собственный фреймворк, если у вас «чистый» Selenium.

21 июня, 11:30

Если ещё не купили билет, держите промокод на скидку: DmitryTuchs2022JRGpc