Доклады

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. Подводим итоги и намечаем пути к последующему распространению полученного артефакта

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

2. Классификация 1С-системы в рамках системного анализа.

3. Проекция принципов системного анализа (12 принципов) на пример анализа производительности системы 1С.

4. Расшифровка этапов системного анализа (9 основных этапов и 3 дополнительных) для случая работ по нагрузочному тестированию 1С.

5. Модели и моделирование в системном анализе. Классификация нагрузочного тестирования 1С как метода моделирования.

6. Системный анализ направлен на подготовку и

обоснование решений, а не только на моделирование. Что для нашего примера из этого следует.

Данная тема подойдет для более опытных специалистов, которые хотят углубиться в контекстную рекламу. Основные темы:

- ремаркетинг,

- таргетинг по намерениям,

- автоматизация правил

- анализ данных

- демонстрация на реальных кейсах

1. SEO + Яндекс Директ: 5 стратегий одновременного использования

2. Медийка — перспективные траты или слив бюджета

3. Фишечки по снижению стоимости лида до 10 раз

Как можно бесплатно получать внешние ссылки на свой сайт. Универсальные типы площадок и методы добычи ссылок. Бесплатные способы ускорения индексации страниц с внешними ссылками. Красные флаги линкбилдинга. Что не так с показателем DR и его аналогами. Мои списки площадок для размещения.

1. Как проверять товарные фиды? Частые ошибки и их решение

2. Дополнительные возможности по улучшению фидов. Обновления директа и сторонние сервисы

3. Неочевидные способы использования фида. (Фид не только для Ecommerce)

— Как справляются с семантикой новые модели

— ИИ в семантическом ядре для крупных проектов и маркетплейсов

— Работа с многослойными запросами

— Где ИИ на текущий момент бесполезен

— Примеры крупных семантик

— ИИ помощник в поиске ключевых слов

Хэнбук как метафора корпоративной философии: свод правил, принципов и инструментов для эффективного взаимодействия.

Ключевые слайды становятся "мантрой" для ежедневной работы с командой и драйвером роста

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

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

Современная реальность требует трансформации бизнес-подходов — старые шаблоны и модели уже не работают.

Сегодня руководителю важно уметь сочетать фокус на эффективности с вниманием к людям — и при этом сохранять себя.

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

Ключевые тезисы:

- Что такое человекоцентричность в управлении и почему эта тема стала актуальной сейчас

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

- Почему добрые, «человечные» лидеры выгорают быстрее

- Раздвоение ролей: лидер как «психолог», «друг», «стратег» и «координатор»

- Что на самом деле заряжает команду — ясность и эмоциональная стабильность лидера

- Кейсы: внутренний конфликт между «мягким» и «жёстким» управлением, как находить баланс и есть ли он

Для кого

Руководители команд, project и product-менеджеры, HR, тимлиды, HiPo- специалисты — все, кто управляет людьми и ищет живые, устойчивые способы быть лидером в профессиональной и личной жизни.

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

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

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

Основная канва доклада - рассказ о серии оптимизаций Duit (BDUI-фреймворка), целью которых было избавиться от лишних аллокаций объектов при обновлениях/анимациях и максимально сократить время парсинга данных.

1. Что такое АB-тесты вкратце для профессионалов

2. Почему вообще за это взялись SEO-специалисты

2.1 SEO — одна из немногих дисциплин в digital, где результат отсрочен и требует постоянной валидации гипотез на длинной дистанции.

2.2 В отсутствии штатной системы экспериментов SEO-специалистам пришлось строить свои мини-системы внутри хаоса, чтобы проверять эффективность изменений.

2.3 Опыт работы с неявными метриками (как органический трафик, crawl rate, индексируемость) делает SEOшников чувствительными к качеству данных и необходимости строгих контролей.

3. SEO как драйвер кросс-командного взаимодействия

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

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

4. Что именно сделали: кратко о системе

4.1 Организация процесса тестов в корпорации

4.2 Технический стек АБ-тестирвоания

4.3. Валидация гипотез и реестр АБ-тестов с ICE приоретизацией

4.4. Настроены вспомогательные прокси-метрики (например, crawl budget, CTR из выдачи, позиции)

5. Чем подход SEO отличается от классического product-AB

5.1 SEOшники умеют работать с шумными, неидеальными и внешними данными, в отличие от чисто фронтовых АB-тестов.

5.2 Применение кластерных АB-тестов вместо классических user-based: поисковики не делят пользователей случайным образом, значит и методология должна адаптироваться.

5.3 Гибридные метрики — сочетание поведенческих и технических показателей, не видимых напрямую в бизнес-аналитике.

6. Примеры успешных кейсов, где конверсия выросла на 300%

7. Ошибки и уроки

8. Выводы

8.1. SEO-специалисты — естественные строители АБ-систем, потому что они:

- Думают в категориях гипотез и проверки последствий.

- Работают с длинными циклами и малым контролем над внешней средой.

- Привыкли защищать изменения с данными «на руках».

8.2. В корпорациях, где продуктовая аналитика часто занята фронтом и монетизацией, SEO может стать катализатором системного подхода к экспериментам.

— Как устроен приём апдейтов через webhook
— Очереди как буфер: помогают разгрузить webhook и обрабатывать всё асинхронно.
— Идемпотентность: защита от повторных апдейтов и дублей callback-запросов.
— Целостность и порядок: как обрабатываем события строго по очереди и избегаем гонок.
— Надёжная доставка: повторные попытки, логирование отправок, реакция на ошибки Telegram API.
— Модульная архитектура: бот как изолированный модуль в PHP-приложении, не захламляет основное ядро.
— Filament как административный интерфейс: справочники, рассылки, настройки
— Управление состоянием пользователя: как строим цепочки взаимодействий, многошаговые сценарии
— Обновление на лету: кнопки, тексты, логика рассылок
— меняем из админки.
— Rate limiting: как не упереться в лимиты Telegram при массовых отправках, используем троттлинг и очереди.
— Callback-кнопки без хаоса: архитектура обработки команд и колбэков, чтобы масштабировать без боли

- Какую задачу мы решаем с помощью платформы обработки и хранения данных

- Какие вехи в разработке архитектуры мы прошли и что поняли на каждом шаге

- Как функционирует многоуровневая архитектура платформы данных - как в одном продукте уживается cloud.ru, apache spark, apache airflow, apache iceberg и parquet, и почему мы все пишем на python

- Как мы используем имеющиеся инструменты

- Какие строим планы на будущее

⁃ Расскажу про историю внедрения проектного подхода на примере конкретного проекта моей HR команды

⁃ Поделюсь пошаговой схемой внедрения: от сбора рабочей группы до демо и завершения проекта

⁃ Покажу, как привычные для ИТ команд ритуалы (грумминг, синки, ретро) можно адаптировать и применить в HR

⁃ Объясню, почему проектный подход в HR — это не революция, а эволюция и как он может усилить, ускорить и вдохновить команду

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

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

— Разбор шаблона таблицы

История о том, как однажды захотелось упростить себе жизнь: Успехи и неудачи :)

* Первые шаги и первая эйфория

* Первые (и не последние) встреченные ограничения

* Как отревьюить монолит в 5 миллионов строк.

* Дообучение модели на коде компании. Сколько займет, сколько будет стоить, и нужно ли?

* Компромиссы.

* Рекомендации по сценариям использования.

* Итоги (tldr - скорее таки да, чем нет).

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