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

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

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

У Додо Пиццы уже больше 890 точек в 17 странах, везде используется платформа Dodo IS. В большинстве случаев нужно передавать данные о каждом чеке в налоговую с первого дня работы, чтобы сразу же не закрыться от штрафов. Поэтому задача интеграции нашего ПО с местным налоговым ПО для нас одна из самых важных при запуске новой страны.

Меня зовут Дима Карпов, я продакт‑оунер в команде, которая занимается кассами, чеками и всем, что связано с оплатами в ресторанах. В статье расскажу, как мы решаем описанную выше задачу так, чтобы ни один бизнес и разработчик не пострадал.

С первой частью рассказа о микрофронтендах в Dodo можно ознакомиться тут

Мы спокойно сидели и пилили новый проект на нашем устоявшемся стеке (React + TypeScript + Webpack + SingleSPA + SystemJS + Jest). Пока одним прекрасным утром не пришел наш техлид и такой: «Чуваки, а давайте затащим Vitest!».

Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.

Как получается, что код становится мало понятным даже для его авторов? Почему нейминг так важен? Как придумывать названия, не применяя целые теории нейминга? Как лёгким процессом организовать работу с неймингом в команде? На все эти вопросы мы ответим в статье.

«Микрофронтенды в компании, которая доставляет пиццу? Серьёзно? Зачем? Да и куда? У вас же всего лишь приложенька с каталогом и заказом товара. Какие ещё микрофронтенды?»

Одно из самых распространённых заблуждений о том, что в Dodo до микрофронтендов не доросли. Но сегодня я постараюсь его развеять и рассказать, как мы докатились до такой жизни и какой путь при этом был пройден. Усаживайтесь поудобнее, мы начинаем наш рассказ.

Вечером пятницы 23 сентября, в самое «горячее» время для Додо Пиццы, развалилась платформа Dodo IS. Приём заказов превратился в тыкву, клиенты и пиццерии 4 часа испытывали проблемы. Это было наше самое крупное падение с 2018-го года как в техническом плане, так и по недополученной выручке.

Особенная боль — то, что мы упали в прайм-тайм. Наш бизнес устроен циклично и зависит от сезона: осенью заказов больше, чем летом, а по вечерам пятницы больше в несколько раз, чем в утром вторника. Обычно пик заказов приходится на вечер пятницы (с 16 до 20 по Москве). Это время — самое напряженное для системы и самое ценное для бизнеса.

У Dodo IS произошёл каскадный сбой и мы долго не могли реанимировать систему. В этой статье делимся постмортемом инцидента: разберём причины, опишем действия по устранению и расскажем о действиях, которые позволят избежать таких падений в будущем.

Одно из направлений разработки в Dodo — интернет-платежи. Для компании это скорее утилити-функция, чем основной бизнес, но всё же нам приходится делать кучу всего, чтобы дать клиентам лучший UX и у нас накопился опыт, которым хочется поделиться.

Меня зовут Дмитрий Кочнев, я разработчик в команде интернет-платежей и в этой статье расскажу о том, какой путь проделала компания в этом направлении, какое положение дел сейчас и какие планы. Статья написана в формате мини-историй, каждая из которых может стать отдельной статьёй с большим количеством подробностей, если к ней возникнет интерес с вашей стороны.

В 2019 году я устроился в Додо Пиццу. В первую же неделю я спросил у ребят, как они логируют происходящее в iOS-приложении у клиентов и узнал, что никак.

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

Итого: клиентских логов нет, а неопределённость и интерес остались. Значит надо сделать систему логов самому. Ну я и сделал. А это — история появления и развития логов в iOS-приложении Додо Пиццы.

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

Мы в Dodo стараемся сделать приложения в первую очередь качественными, но и не забываем добавлять интересных фич для наших любимых клиентов. Так, например, мы создали анимацию «Летающая Пицца», а в канун Нового года решили сделать праздничную зимнюю анимацию под названием «Изморозь».

В статье поделюсь этим опытом и расскажу, как за несколько шагов сделать стираемую с экрана анимацию и в вашем приложении.

Вчера чат-бот с искусственным интеллектом ChatGPT написал за меня Android-приложение! Это очень примитивное приложение, но оно компилируется, запускается и работает. Но как он это сделал? С первой попытки или пришлось долго сидеть и мучить его?

Сейчас расскажу!

Вам приходилось ходить на встречи, на которых 10 или более человек никак не могли договориться? Такое может быть и с архитектурными, и дизайн-решениями, и  процессами. Нам в Dodo приходилось. Это может быть мучительно больно и выматывающе, поэтому хочу поднять тему решительности или «куража», как это называется в экстремальном программировании.

Почему я? Когда-то давно, когда я ещё не была техлидом, я заметила, что у нас есть проблема с глобальными процессами. От этого страдали все, и я в том числе. В конце концов страдать мне надоело, поэтому я решилась изменить что-то хотя бы в собственной команде. И мне это удалось. Хочу поделиться опытом и рассказать о одном принципе, который помог мне тогда и помогает по сей день.

У меня есть правило: «решает тот, кто делает». В принципе, статью на этом можно было бы заканчивать.  Но я расскажу о паре тонкостей этого правила и приведу примеры.

Одна из санкций, которая досталась России, — запрет на выдачу и продление SSL-сертификатов. Это приводит к тому, что у некоторых компаний сертификат может протухнуть и сайты перестанут открываться.

Основных решений два:

Использовать российский Яндекс.Браузер или Атом.

Поставить на компьютер сертификат или профиль от минцифры.

Для мобильных приложений это превращается в особую проблему — могут перестать проходить платежи разных эквайрингов.

Например, 15 февраля 2023 года у Сбера истечёт действие сертификата и надо переходить на самоподписанный. Если этого не сделать, то эквайринг через Сбер может перестать работать. SberPay будет работать как и раньше.

В статье покажу, что делать разработчикам приложений, чтобы экраны c 3-D Secure открывались и эквайринг продолжал работу.

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

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

В этой статье расскажу, что при росте приложения Додо Пиццы стало для нас отправной точкой и заставило внедрить Release Train. В конце поделюсь результатами, помогло ли это.

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

3 года назад я загорелся тем, что хочу эргономичную клавиатуру. Готовых вариантов было немного, Keyboard Model 1 оказалась одной из них, но была слишком дорогой. И тут её переиздают на кикстартере, где собирают почти миллион долларов. Страдаю, жду полтора года производства и вот она у меня.

Три года назад я стала продактом. Это приучило меня мыслить в таких понятиях как ЦА и пользовательские сегменты, JTBD, считать метрики и оценивать профит от всего. А ещё легализовало мои мысли о дизайне UX и о том, как можно выпрямлять пользовательские пути в разных сферах жизни человека.

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

В сентябре Антон Скобин, коммерческий директор Слёрма, записал два выпуска подкаста «Манул Слёрма» с Олегом Блохиным, лидером инфраструктурной команды Dodo Engineering. Поговорили о том, как выстраивается работа SRE-команд, какие функции они выполняют и в чём профит от SRE для бизнеса. В этой статье поделимся главными мыслями этой беседы.

В 2011 году 2 разработчика начали создавать свою информационную систему, чтобы через неё принимать заказы в Додо Пицце. 2 года назад мы рассказывали про раннюю архитектуру Dodo IS здесь и здесь. За это время монолит нашей системы пережил немало изменений, самое значительное произошло в этом году — мы перевели его весь на .NET 6 и переехали в Kubernetes. Переход оказался непростой задачей и длился в общей сложности год.

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

Android-разработчиков часто спрашивают на технических собеседованиях, как запускать фрагменты, как передавать туда данные, почему нельзя класть много в аргументы, а много — это сколько, а что может пойти не так и т.д. Мы в Dodo тоже иногда такие вопросы задаём. Я думал, что понимал всё это, но оказалось, что довольно поверхностно. Всё изменилось, когда я столкнулся с частыми крашами TransactionTooLargeException в приложении Дринкит.

TransactionTooLargeException — это исключение из области IPC-вызовов (interprocess communication) и Android Binder. Но его можно получить в безобидной ситуации, когда, казалось бы, мы ничего такого не делали, и не пользовались IPC.

В этой статье предлагаю разобраться с этим крашем и поговорить про IPC-вызовы и Binder.

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

Сегодня расскажу, как Apple предлагает решать эту проблему с помощью логов.

Представьте, что вы садитесь делать новый проект для iOS/iPadOS/macOS/tvOS/watchOS. Совсем скоро сталкиваетесь с первым багом и, чтобы его понять и исправить, добавляете логи — вызываете print() тут и там. Баг исправили и часть логов убрали, а часть оставили на будущее — полезные, ещё пригодятся.

Спустя пару месяцев работы над проектом консоль в Xcode превращается в водопад из логов. В них сложно разобраться и в них невозможно ориентироваться. Вы принимаете это как данность и в новые логи для удобства добавляете какие-то маркеты по типу "----->" или ещё что-нибудь в этом духе — так их можно будет различить в бесконечном потоке.

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

В этой статье расскажу, как Apple предлагает решать такую проблему.