Чтобы сделать пиццу из половинок мы использовали два UICollectionViewLayout. Рассказываю о том, как мы написали такой лейаут для iOS, с чем столкнулись и от чего отказались.

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

Как часто бывало так, что написав рабочий юнит-тест, ты смотришь на его код, а он… плохой? И ты такой думаешь: «Это же тест, оставлю так…». Нет, %username%, так оставлять не надо. Тесты — это значимая часть системы, которая обеспечивает поддерживаемость кода, и очень важно, чтобы эта часть также была поддерживаемой. К несчастью, у нас не так много способов обеспечить это (не будем же мы писать тесты на тесты), но парочка всё-таки есть.

У нас не очень простое собеседование. Нужно пройти 3 шага:

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

Я три месяца был тем программистом, который оценивает резюме. Мне есть о чём с вами поговорить.

Привет, Хабр! Пару месяцев назад мои коллеги рассказывали про расширение команды в 5 раз: от 50 тогда до 250 разработчиков к концу 2020 года. Как вы могли догадаться, сейчас мы уделяем много внимания найму. При этом, мы не готовы «брать количеством», нанимая всех подряд, мол «потом разберёмся». Нам важно, чтобы человек действительно стал частью нашей команды на годы вперёд. Именно этот мотив привёл нас когда-то к новому формату собеседований – тестовому дню. Про него и пойдёт речь под катом.

Серия статей про собеседования:
1. Наш первый обед вместе: почему и как мы проводим тестовый день.
2. Я прочитал 80 резюме, у меня есть вопросы.
3. Собеседование в Додо Пиццу.
4. Уходя уходи: почему не стоит принимать контроффер.
5. Спасибо за собеседование, мы ответим о нашем решении… сейчас.

/start

Вечер пятницы, конец рабочего дня. Вы находитесь в офисе. Что будете делать?

— Поехать домой поспать
— Пойти в бар с друзьями
— Отправиться на свидание
— Проверить, почему горит свет в переговорке

Меня зовут Андрей Моревский, я архитектор в Додо и тот человек, который выбрал «Проверить, почему горит свет в переговорке». Тогда я ещё не подозревал, чем закончится эта история.

Привет, Хабр. Не буду повторять тысячный раз о том, что как любой из нас всегда мечтал написать игру. Мне 37. Я разработчик. Как раз самое время задуматься. Аркады, симуляторы, RPG, шутеры, веб, десктоп, мобильная. Было непросто. В какой-то момент я понял, что хочу возродить направление текстовых квестов, от которого в детстве бежали мурашки по коже. Хочу поделиться с вами игрой CMAN. Это история про разработчика, который на один день отправился в гембу.

Под катом вы найдёте описание игры, фичи, а также узнаете про призы за топовые места.

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

Привет, Хабр! Сегодня хочу поделиться с вами историей о том, как я сдавал сертификационный экзамен Google Developers Certification: Mobile Web Specialist. Если честно, то каких-то объективных причин я назвать не могу, так как не слышал ещё ни об одном случае, когда наличие сертификата давало кому-то преференции при устройстве на работу или помогало повысить зарплату. Под катом расскажу, почему всё же решил сдать экзамен и подробно опишу, как я его сдавал.

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

Но теперь мы спим лучше. Мы научились распознавать сценарии системного апокалипсиса и обрабатывать их. Ниже расскажу, как мы обеспечиваем стабильность системы.

Прошлой осенью мы объявили о том, что планируем расширить IT-команду с 48 до 250 человек. Сразу посыпались вопросы, которые по сути сводились к одному: зачем сети пиццерий 250 разработчиков? Откуда эта цифра? Поэтому в первом посте в нашем блоге хочу ответить именно на этот вопрос (и, конечно, на любые другие в комментах).

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

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

Разберём на новогоднем примере:

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

У вас большой UIViewController? У многих да. С одной стороны, в нём работа с данными, с другой — с интерфейсом.

Задачи отделения логики от интерфейса описаны в сотнях статей про архитектуру: MVP, MVVM, VIPER. Они решают проблему потока данных, но не отвечают на вопрос как работать с интерфейсом: в одном месте остается создание элементов, лейаут, настройка, обработка ввода и анимации.

Давайте отделим view от controller и посмотрим чем нам поможет loadView().