Берёзка

🦤 Приложение Додо Пиццы - первое место в фестивале креативных индустрий G8!

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

Отдельное место в дизайн-раю, кстати, для этих ребят @designdodo

Немного похвастаюсь

Сделали себе публичный дашборд проекта Drinkit

Пока что только для Android. Скоро сделаем и iOS, когда обсудим, что ребята хотят трекать 📊

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

Дашборд построен на движке и идее из iOS пиццы, про которую Леша Березка писал у себя

Ну и пишите, если вам было интересно что-то еще узнать про проект, чего нет на дашборде 👀💭

Кстати, есть еще одна очень срочная и горячая новость

В Додо появились стажировки! И с подачей заявок лучше поторопиться, потому что прием заканчивается сегодня

Открытые направления:
⭕ Разработка & Security
⭕ QA
⭕ Аналитика
⭕ Дизайн
⭕ Менеджмент в ИТ

Стажировка только для студентов ИТМО и СГУ (Сыктывкарский ГУ им. Питирима Сорокина) 3-4 курсов бакалавриата и 1-2 курсов магистратуры

Поторопитесь, потому что прием заявок заканчивается 7 сентября. Если у вас есть кандидаты — скидывайте им этот пост

https://maxpolitov.github.io/dodo-internship-landing/#apply

Ура! У нас в додо наконец то открылись вакансии для Android разработчиков 👩‍💻🍕

Android разработчик в команду оформления заказа
https://dodoteam.ru/vacancy/?vacancyId=15178

Android разработчик в Core команду Додо
https://dodoteam.ru/vacancy/?vacancyId=15176

Знаю, что вы интересовались наличием вакансий к нам. Пришло ваше время 😧

🍎 iOS-разработчики, общий сбор!
Через тридцать минут начинаем наш митап.

Подключайтесь к трансляции, чтобы обсудить iOS-инфраструктуру, CI, аналитику и архитектуру — стартуем в 18:30 🔴

YouTube
VK Видео

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

Уже послезавтра расскажу как мы ускорили CI в Додо Пицце замедлив тачки.

Успевайте зарегаться!

Берёзка pinned «Хочу вам помочь Я в разработке около 15 лет. Последние 7+ лет в Додо делаю так, чтобы приложение стабильно работало на всех рынках. В основном шарю за iOS и мобильную инфру. Ещё могу помочь с доступностью: Dynamic Type, контрастными темами, адаптацией для…»

Bookshelf.dev: новая книга — про автотесты на iOS

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

Выходит, что 4 из 5 пунктов я могу показать: как это выглядит, куда идти и как пользоваться. А вот последний пункт про архитектуру вы должны пройти сами, выбрав что вам нужно, что можно сделать сейчас и насколько вы готовы менять проект. Зато после книги конечная цель будет сильно понятней!

Книга будет выходить постепенно, первые шесть глав уже доступны.
• Как тесты помогают масштабированию приложения.
• Примеры тестов в пирамиде тестирования. Бесплатная глава
• Как тесты и ИИ помогают друг-другу.
• Что приходится изменить в архитектуре.
• Что такое TDD-ката и туториал по ней.
• Что такое DSL

Затем я расскажу про самые разные виды тестов (примеры в бесплатной главе) и к концу вы узнаете как написать стройную систему автотестирования без мок-фреймворка на сценариях использования приложения.

Доступно на русском и английском, $30 вместо 50 пока книга пишется.

https://bookshelf.dev/testing-book

Миша — гуру в тестах. Как бы хорошо вы не писали тесты — прочитайте книгу и научитесь новому.

А если ещё не писали тесты — ну, пора уже, это лучшее вложение в техническое качество проекта, особенно с учетом всего этого ЛЛМ-бума.

Хочу вам помочь

Я в разработке около 15 лет. Последние 7+ лет в Додо делаю так, чтобы приложение стабильно работало на всех рынках.

В основном шарю за iOS и мобильную инфру. Ещё могу помочь с доступностью: Dynamic Type, контрастными темами, адаптацией для дальтоников.

Ну и с процессами в команде. Много че повидал и поменял, знаю, что работает, что не работает и почему.

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

Консультация стоит 10 000 ₽ за час.

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

С вас - проблема и контекст. С меня - разбор, че происходит и что с этим делать.

Пишите в личку.

Долистали до главного релиза августа — iOS-митапа от hh.ru 🛠

Наши эксперты и специалисты Dodo Engineering представят четыре доклада об инфраструктуре, CI, мобильной аналитике и архитектуре. Ждём iOS-разработчиков и техлидов, которые развивают крупные приложения и хотят ускорить рабочие процессы!

🛠 iOS-разработчик hh.ru Виталий Барабанов расскажет, как устроена iOS-инфраструктура hh.ru и какой путь проходит приложение от коммита до релиза.

Обсудим CI/CD, сборочные машины, авторелиз, кодогенерация аналитики и сокращение ручных операций

🛠 iOS-техлид Dodo Engineering Алексей Березка рассмотрит, как находить узкие места в CI и ускорять сборки.

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

🛠 iOS-разработчик hh.ru Андрей Максимкин разберёт перезагрузку мобильной аналитики и объединение подходов iOS и Android.

Проанализируем переход к единому масштабируемому подходу в мобильной аналитике для iOS и Android, а также организацию совместной работы команд, результаты внедрения и применение AI

🛠 iOS-разработчик hh.ru Тимур Шафигуллин поделится какой получилась MVVM на проекте из 17 тысяч Swift-файлов и 164 модулей.

Разберём причины отказа от чистого SwiftUI, объединения бизнес- и UI-состояния и создания собственных опенсорс-библиотек, а также альтернативы и решения возникших проблем.

📆Когда: 20 августа в 18:30, начало в 18:30.
У
✌️Участие: бесплатно, онлайн
Регистрируйся тут

Скоро выступлю и расскажу как сделать вашу инфру быстрой.

Запишитесь, придите и послушайте. ТАКОГО ВЫ ЕЩЁ НЕ СЛЫШАЛИ.

А ещё мы снова ищем iOS-разработчика! На этот раз в команду лояльности — додокоины, персональные скидки и всё такое.

Успевайте откликнуться, пока никто не занял это золотое место — проекты там и правда клёвые.

https://dodoteam.ru/vacancy/?vacancyId=15043

Берёзка pinned a photo

Новый публичный технический дашборд Додо Пиццы

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

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

Короч стало вау, зацените:
💅дашик 💅

LLM-фабрика, часть 6: ишьюс сам пишет себе план

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

Ответили на вопросы — пора планировать. Ишьюс получает planning.

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

И ничего в коде не меняет. Не потому что мы попросили — у него просто нет доступа на запись. Только чтение, поиск и коммент в ишьюсе.

На этом этапе фабрика разбирается:
• каким из способов делать и чем за это платим
• в каком модуле ваще должна жить правка
• что уже есть и можно переиспользовать
• чем это потом проверить
• где можно случайно сломать соседнее

После ресёрча бот кладёт план прямо в комменты ишьюса: контекст, выбранный подход, шаги, конкретные файлы, тесты, риски и крайние случаи. Не «поправить сервис и добавить тесты», а какие именно файлы, че в них менять и какой результат проверять.

Главное: план можно перехватить руками.

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

Спорить с планом в комментах сильно дешевле, чем на ревью гига-ПРа.

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

Если по дороге нашлась развилка, которую из кода не решить — возвращаемся в awaiting-answer из прошлой части. Фабрика задаёт вопрос и ждёт. Сюда же попадает и «делаем одним ПРом или разбиваем на три» — из кода это не выводится, это решает человек.

Если вопросов нет — в конце плана бот ставит маркер: всё исследовано, можно двигаться дальше.

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

И только тогда planning заканчивается. Какой лейбл приходит следующим — в следующей части.

Жмите 👀 если продолжать.

LLM-фабрика, часть 5: бэклог разбирает сам себя

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

Но тупо отдать ЛЛМ первый попавшийся ишьюс тож нельзя. В одном написано «переименовать опечатку» — там всё понятно и работы на десять строк. В другом «переделать авторизацию» — че именно переделать, зачем, какой из пяти вариантов выбрать и кто ваще решает как правильно?

Если оба сразу отправить писать код, первый превратится в нормальный ПР, а второй — в уверенно написанный абсолютно неверно ПР.

Поэтому следующий кирпичик фабрики — LLM Triage.

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

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

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

Он появляется, когда прямо ща нужен выбор человека. Фабрика задаёт вопрос прямо в ишьюсе — не абстрактное «а че вы хотите?», а конкретную развилку, на которую можно ответить одной строкой: переименовать старое API или оставить совместимость, делать через вариант А или вариант Б. Заодно тегает автора ишьюса и тех, на кого оно назначено.

И всё, фабрика встаёт и ждёт. Не начинает писать код наугад, не выбирает сама и не долбит человека одинаковым вопросом каждую ночь. Пока нового ответа нет — молчит.

Когда человек отвечает, фабрика не просыпается мгновенно. Следующей ночью LLM Plan снова приходит в ишьюс, перечитывает весь тред, берёт последний ответ и пересобирает план с учётом него.

Если из ответа вырос ещё один вопрос — оставляет awaiting-answer и спрашивает дальше. Если всё понятно — снимает лейбл, публикует обновлённый план и ставит маркер «вопросов больше нет, можно двигаться дальше».

То есть awaiting-answer — не метка «мы запутались и сдались». Это прям состояние фабрики: вот конкретный вопрос, вот кого ждём, вот с какого места продолжим после ответа.

А что делают остальные лейблы — уже в следующих частях. Про planning там прям отдельный кусок фабрики, а до написания кода ещё доберёмся.

Наваливайте 🤔 если продолжать.

Пандус для Фигмы

Сделал плагин который позволяет легко описать разметку для VoiceOver в Фигме. О таком инструменте меня спрашивали десятки компаний, так что забирайте.

https://www.figma.com/community/plugin/1658465990761157788/voiceover-annotator

Главное: он задает формат описания элементов и показывает ограничения, которые есть у скринридера. Но это цветочки: если подключить API-ключ для нейронки, то с помощью скила можно сгенерировать все описание! А мелочи потом руками доправить.

Главные фичи:
• Повторяет интерфейс приложения VoiceOver Designer. Если пользовались, то будете как дома.
• Умеет подписывать как под фреймом, так и в аннотациях для Dev Mode.
• Можно экпортнуть в формате .vodesign и послушать превью в VoiceOver Designer

Плагин опенсорсный, пишите баги в ишьюс https://github.com/AccessibilityTools/voiceover-annotator-for-figma

С плагином и дизайном мне помог Матвей Мясоедов. Матвей, спасибо!