Когда речь идёт о написании своих нагрузочных сценариев «поверх» JMeter, есть десятки способов выстрелить себе в ногу. Самый верный способ это заметить — качественно измерять то, что мы делаем.

На осенней конференции Heisenbug Дима Тучс рассказал о работе с памятью в Java, о многопоточности и тред-пулах и даже о такой банальной теме, как парсинг JSON. А ещё о том, почему и как всё это пришлось переписать, чтобы нагрузить бэкенд Dodo IS втрое выше. 💻

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

P.S. Спасибо организаторам за то, что поделились записью с нашими подписчиками. Кстати, если у вас есть что рассказать на Heisenbug этой осенью — самое время отправить заявку на выступление.

Собираем неравнодушных QA инженеров и не только на ламповые посиделки в арт-коворкинге Санкт-Петербурга.

💻 Ярослава Рощина (Dodo Engineering) расскажет, как в её команде удалось сократить время разработки фич.

🛠 Татьяна Березенцева (СберКорус) проведёт мастер-класс по запуску автоматизации API на проекте.

🗓 19 июля, начало в 19:00

Офлайн, Санкт-Петербург, участие бесплатное.

Регистрируйтесь и приходите, если будете в это время в городе.

До встречи!

💻 Компьютерное зрение на страже стандартов качества пиццы

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

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

И уже экономим 30% времени команды, которое тратится на проверку отчётов клиентов. Круто же!

Как добавить возможности Chat GPT в ваше приложение

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

Когда мы начали создавать эту систему, у нас возникло множество вопросов. И если вы новичок в работе с GPT-моделями, у вам тоже может быть непонятно, как интегрировать помощника AI в приложение, как использовать API Open AI, какие сложности могут возникнуть и как их решать.

💻 Ответами на подобные вопросы делится Константин Полонский в своей статье — заходите на Medium почитать (статья на английском), задавайте вопросы и делитесь своим опытом!

Деврел — не человек, или Всем мы немножко деврел

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

💻 Вероника Ильина, наша Head of Devrel, собрала 14 утверждений про деврел и разобралась, что правда, а что ложь — и сделала это в лучших традициях «Разрушителей Мифов».

Читать 10 минут

🤨 Бонус в конце статьи — чек-лист для тех, кто хочет деврельской движухи в своей компании, но есть вопросик.

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

Этот принцип лежит в основе нашей культуры. Он же применяется и к сервисам.

💻 Наш СТО Павел Притчин сформулировал принципы владения сервисами, которые помогают компании и командам лучше с этим работать.

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

2. Должно быть описание роли владельца, его обязанностей. Например, что человек должен делать как владелец сервиса, на какие алерты и как реагировать.

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

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

5. Нужна автоматизация в тех местах, где это возможно, чтобы снизить нагрузку на людей.

Некоторые пункты из этого списка у нас уже есть (например, карта раскатки фич), некоторые только появляются (реестр сервисов).

Интересно узнать, как вы понимаете «владение», как этот принцип проявляется в вашей работе — поделитесь в комментариях.