Стачка. Разработка

1. Что такое CI / СD ключевые тезисы, почему CI/CD критичен для компании (?)

2. Средства/продукты для организации процесса CI / CD: GitLab, Jenkins, TeamCity, Circle CI, Travis, CodeMagic и тп

3. Выбираем GitLab

4. Этапы CI / CD, акцентируем внимание на этапе сборки flutter приложения под iOS, android, web + нет доступа в Интернет (только доступ в корп сеть VPN)

5. Немного о проблемах, которые возникают в условиях VPN

6. Думаем/выбираем локальное хранилище: JFrog, Nexus Dart, ProGet, CloudSmith и тп

7. Далее рассматриваем на примере Nexus Dart хранилища (тк в компании исторически сложилось и бесплатное решение)

8. ** пару слов о развертывании Nexus локально

9. Варианты сборки: локально на ПК / в контейнере (Docker)

10. Собираем Android: сборка в контейнере (настраиваем окружение), далее смотрим какие есть нюансы сборки, на что следует обратить внимание и учесть, метрики (?)

11. Показываем как автоматизировать сборку в GitLab: pipelines, jobs, workflow, runners и тп

12. Собираем Web: сборка в контейнере, нюансы сборки

13. Собираем iOS: размышляем о возможности сборки в контейнере (легальный/нелегальный способы), сборка на ПК, автоматизация в GitLab. Несколько слов о хранении Pods в Nexus

14. Подводим итоги и намечаем пути к последующему распространению полученного артефакта

Доклад охватывает различные аспекты безопасного и небезопасного использования пакета unsafe в Go, при помощи которого можно ускорять код в десятки раз!

Мы узнаем, как можно создавать срезы без дорогостоящей инициализации, научимся избавляться от Bound Checks и конвертировать строки в срезы и обратно без лишних копирований и аллокаций памяти... Дополнительно мы сравним пакет unsafe в Go с указателями из С/С++ и посмотрим на некоторые паттерны С++, которые можно в некоторых ситуациях применять при программировании на Go.

Черную магию мы оставим под конец доклада, чтобы с ее использованием посмотреть, как можно проезжаться по памяти для анализа сложных структур данных, модифицировать иммутабельные строки в Go и получать доступ к приватным полям структур.

System Design Interview - один из самых творческих этапов при прохождении собеседования. Основная сложность для мобильных разработчиков заключается в том, что многие источники для подготовки ориентированы на Backend-инженеров и это часто сбивает с толку. Текущий рынок труда сильно изменился, кол-во этапов увеличилось. Все больше компаний практикуют System Design. Поэтому в этом докладе я расскажу как пройти System Design именно мобильному разработчику и на какие аспекты отдельно уделить внимание. Успешно проходил System Design в Yandex, Avito, Revolut, Monzo и составил свой план для получения наилучшего результата. Покажу типичные ошибки, а также в конце разберем реальный кейс из Big Tech-компании. Доклад будет интересен как мобильным разработчикам которые готовятся к собеседованиям, так и тимлидам, которые хотят внедрить такой этап в своих компаниях.

- API First: что это такое и почему вокруг него споры.

- Контракт как точка синхронизации — когда он помогает, а когда мешает.

- Что влияет на “глубину” API First: цели проекта, структура команды, зрелость процессов.

- Документация vs контракт — где провести границу?

- Практические кейсы и грабли.

- Разберем базовые принципы индексирования и хранения геоточек и геополигонов в Elasticsearch, обеспечивающие эффективный пространственный поиск.

- На практических примерах рассмотрим геозапросы для поиска пересечений полигонов и вхождения точек в области.

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

- Затронем концепцию обратного поиска - регистрации запросов в percolator и использования percolate запросов.

Перемещение и обработка данных — одна из самых частых задач в Web API. Пока объёмы невелики — всё просто. Но когда входящие файлы или JSON становятся большими (десятки МБ и более), прямые аллокации приводят к LOH, дефрагментации памяти и падению производительности.

Доклад показывает, как одну и ту же задачу можно решить тремя подходами — от Junior до архитектора:

Junior-style: читаем всё в память, получаем LOH и GC-паузы

Middle-style: работаем чанками, применяем буферизацию, ограничиваем аллокации

Senior-style: проектируем API через Span, Memory, IBufferWriter, строим zero-alloc поток

На живом примере — передача большого JSON из PostgreSQL клиенту — сравниваем RPS и latency при:

полном чтении через ReadToEndAsync()

потоковой отдаче через SequentialAccess + GetStream

zero-alloc pipeline

Демонстрируем:

когда ArrayPool и RecyclableMemoryStream дают выигрыш, а когда стоит написать свой буфер

как замерить эффект от оптимизаций через BenchmarkDotNet, dotnet-trace и EventCounters

чеклист: «что проверить, чтобы большие данные не съели всю память»

Два независимых направления тестирования: мобильные приложения и Web — с разными процессами, инструментами и даже внутрикомандной культурой, работающие в одном отделе. Разные подходы, разные ожидания, разные метрики. Возможно ли их объединить? Кажется, что нет. Но нам удалось не просто собрать единую команду, а создать эффективную синергию всего за полгода. В этом выступлении я расскажу, когда действительно нужно объединять QA-направления и как понять, что для этого пришло время, а также с какими главными вызовами мы столкнулись, как сохранили сильные стороны каждого подхода при унификации процессов и что в итоге дало объединение — от сокращения издержек до ускорения релизов. Этот практический кейс будет особенно полезен QA-лидам, тимлидам и руководителям, которые работают в условиях мультиплатформенной разработки и готовы менять процессы для достижения реальных результатов.

- Краткое введение по анализу дампов памяти

- Формат хранения дампов памяти Hprof

- Обход графа объектов памяти

- Реализация индексов для быстрого обхода (на основе работы для JB)

Мы в hh.ru пишем большое количество UI-тестов, которые помогают следить за корректной работой наших фич в мобильных приложениях.

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

Опираясь на многолетний опыт создания и поддержки таких сценариев, мы смогли выделить общие подходы и вынесли все наши наработки в open-source библиотеку Rafinad (https://github.com/hhru/Rafinad), которая существенно упрощает написание и поддержку UI-тестов.

В рамках доклада мы:

- Посмотрим, как обычно пишутся UI-тесты в iOS и разберём пример теста.

- Обсудим, с какими проблемами и неудобствами поддержки тестов можно столкнуться.

- Выделим критерии для поиска решения и оценим существующие библиотеки для написания UI-тестов.

- Познакомимся с библиотекой Rafinad и её основными принципами.

- Перепишем пример теста с использованием Rafinad.

- Создадим более сложные сценарии и посмотрим, как их реализует Rafinad.

- Подведём итог, как Rafinad помогает упростить процесс написания и сопровождения UI-тестов.

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

Первая часть

Aurora SDK. Что нового для разработчика в 2025 году

1. Обзор возможностей и устройство Аврора SDK

1. Устройство Аврора SDK

2. Поставки Аврора SDK. Для программиста и CI/CD

3. Обзор возможностей Аврора SDK

2. Переход эмулятора ОС Аврора на QEMU и встраиваемый эмулятор

1. Qemu vs Virtualbox для Аврора SDK

2. Новые возможности Qemu эмулятора

3. Встраиваемый эмулятор ОС Аврора

4. Aurora Debug Tool

3. Поддержка Apple M series

1. Аврора SDK на Apple M Series

2. Пара слов о Aurora Build Tools

4. Новый QtCreator

Вторая часть

Kotlin Multiplatform

В рамках доклада расскажу вводную по большим языковым моделям, параметрам и отличиям существующих моделей, как выбрать модель подходящую под интересующий тип задач, требованя к on primese развертыванию и то, как мы работаем с нашей LLM моделью QWEN 8B в рамках задач автоматизации процессов тестирования.

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