Кофе — продукт, который можно покупать и пить несколько раз в день. Заказ в приложении Дринкит должен быть супер-пупер быстрым. В идеале, чтобы можно было даже не запускать его, а заказывать из виджета на домашнем экране.

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

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

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

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

Entity Framework — это удобный фреймворк для работы .NET-приложения с базой данных. По сути, это такая удобная абстракция над БД, которая сама пишет за разработчика оптимальные (ну, почти) SQL-запросы прямо из высокоуровневых LINQ-конструкций. Одной из киллер-фич фреймворка является возможность относительно легко сменить СУБД приложения на какую-нибудь другую. Предположим, разочаровались вы в MySQL или, наоборот, хотите сменить MSSQL на что-то менее дорогое — пожалуйста, EF как абстракция над СУБД в теории может это предоставить, так сказать, by design.

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

Несколько месяцев назад мне захотелось сдуть пыль со своего аккаунта в Steam и поиграть в старые игры про программирование.

While True Learn в очередной раз показалась слишком скучной, я пару дней позалипал в TIS-100, реализуя свой многопоточный процессор, но в конечном итоге осознал, что интереснее не играть в игры про программирование, а самому писать такие игры.

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

В статье расскажем, что такое Dodo Score и почему у нас появилась потребность в сквозной приоритизации задач. Будем рады, если наш опыт поможет вам прокачать скилл делать только самое ценное или приведёт к мысли, как улучшить тот фреймворк, который вы используете.

Прогнозирование закупок и расхода ингредиентов — часть работы управляющего любым рестораном, которая может занимать несколько часов в неделю. Мы в Dodo Engineering задумались, как можно помочь и автоматизировать рутину, при этом улучшить качество прогноза.

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

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

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

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

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

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

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

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

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

Часто слышу мнение, что unit-тесты не нужны для мобильной разработки: в приложении должно быть минимум логики, основная работа с UI, а его сложно тестировать, да ещё и тесты отнимают время, которое можно было бы потратить на написание фич. 

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

Рассказываю, что поменялось спустя 2 года и 4 тысячи тестов. 

По разным данным в СМИ, за март из России уехало от 50 до 100 тысяч айтишников и ещё столько же планируют переезд в апреле. Многие из них уже работали на зарубежных работодателей, кто-то переезжал вместе с компанией. Но многи и тех, кто продолжает трудиться на российские компании из-за границы.

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

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

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

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

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

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

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

Есть маленькая книга, которая предлагает методологию определения того, стоит ли продолжать некое дело вопреки сложностям или пора всё бросать. Она примерно так и называется — The Dip: A Little Book That Teaches You When to Quit (and When to Stick). Эта книга и её небольшой пересказ в статье призваны помочь найти ответ на тот самый вопрос «а не пора ли соскочить».

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

Пет — отличный способ прокачаться как начинающим разработчикам, так и опытным. Во время разработки пет-проекта можно побывать и программистом, и дизайнером, и менеджером, и маркетологом. 

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

У сервиса онлайн-обучения программированию Хекслет есть собственный Open Source проект Code Basics, на котором выходят бесплатные курсы для начинающих на разных языках. Когда-то их было только два – PHP и JavaScript, сейчас уже более десятка. В компании Dodo Engeneering есть хорошая экспертиза по C#, поэтому мы вместе решили сделать курс с тренажером для тех, кто хочет начать изучение программирования именно с него. Во время написания курса оказалось, что из-за долгого холодного старта и ограничений учебной платформы все решения студентов падают.

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

Представим простую историю. Вы заканчиваете делать рефакторинг, которым занимались последние 2 недели. Вы хорошо над ним поработали, сделали несколько ключевых изменений в проекте. Делаете долгожданный pull request, и ... 12 конфликтов.

Или другой вариант. Вы работали и постоянно подливали себе основную ветку, так чтобы код сильно не расходился. Делаете pull request, он висит несколько дней, после этого вы получаете approve и ... 15 конфликтов. Кто-то слил свой большой pull request раньше.

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

В этой статье поговорим про технику Branch by Abstraction. Как она может помочь не копить большие изменения в нашей ветке, избегать merge hell и прокачать ваш CI.

Я буду описывать примеры из Android-разработки, но они также справедливы для большинства типов проектов и платформ.

Модульный монолит — это подход к проектированию приложений, который позволяет, с одной стороны, отложить во времени операционную сложность использования микросервисов, а с другой — избежать превращения монолитной системы в большой комок грязи. Сама идея модульности не нова и основана на давно известных принципах Separation of Concerns и Information Hiding. Но не так-то просто перейти от абстрактных принципов к пониманию, как их реально использовать на практике.

На Хабре не так много информации о модульных монолитах в целом и практически ничего о конкретных вариантах их реализации. Но об этом есть серия статей у Камиля Гржибека. Сегодня поделюсь переводом первой из них.

История об одном баге, который превратил переход с .NET Core 3.1 на .NET 6 в «приключение на 20 минут», самописной библиотеке Dodo.Primitives.Uuid, которая помогла этот баг починить, и размышления о бренности бытия важности своевременного рефакторинга и его приёмах.

В 2017 году у Додо Пиццы появилось приложение для iOS на русском языке, а в 2019 его понадобилось перевести на румынский, а потом ещё на несколько языков. При этом ни одна строка не была обёрнута в макрос NSLocalizedString(…).

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