Разработка

1. Предпосылки создания системы аналитики - как и почему мы к этому пришли

2. Требования, выдвигаемые к архитектуре решения, и как им соответствовать.

Поделюсь описанием функциональных и нефункциональных требований к системе.

3. Общая архитектура работы системы. Включает в себя рассказ о том, как устроена архитектура со стороны бэкенда (kafka + clickhouse) + архитектура Android приложения

4. Алгоритм доставки событий. Расскажу об отправке данных, как данные хранятся, как отправляются, что происходит в случае ошибки

5. Как быть с ошибкой. Расскажу о приемах, как досылать данные в случае потери сессии / отсутствии интернета. Расскажу о том, как не положить сервер от "распухших" данных

6. Как мы валидировали что SDK работает корретно ? Расскажу о метриках контроля качества, сколько мы теряем событий, ошибках при работе с беком, логировании работы SDK

7. Планы на будущее. Расскажу, куда хотим дальше развивать инструмент, что добавлять

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

Обзор и сравнение существующих архитектур дебаггеров в PHP, обзор возможностей Yii Debug и при чем тут панелька?

А так-же: рассмотрим наиболее частые ошибки и подумаем, как их избежать.

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

Сколько стоит создать цифрового помощника для РФТ сегодня

Поиск и выбор фрейма для инфраструктуры AI в РФТ

Библиотека - Ollama

Применимость AI для РФТ по Рексу Блэку

Сравним полученные результаты с результатами от Старшего Инженера по тестированию

Сделаем выводы

1. Выбор архитектуры и построение кластера

Определение требований к масштабируемости и отказоустойчивости.

Выбор между кластеризацией в активном и пассивном режиме.

Разработка стратегии распределения данных и узлов.

2. Выбор между бесплатной и коммерческой версией СУБД

Оценка функциональных возможностей и ограничений бесплатной версии.

Сравнение уровня поддержки и документации.

Учет общих затрат на лицензии и поддержку.

3. Миграция данных

Планирование миграции для минимизации простоев.

Выбор инструментов для миграции и их настройка.

Проведение тестов миграции на небольших объемах данных.

4. Тестирование производительности

Определение ключевых метрик производительности для тестирования.

Использование инструментов для профилирования и мониторинга.

Проведение стресс-тестов и анализа узких мест.

На докладе рассмотрим два основных алгоритма работы с локальной аутентификацией, а также инструменты, которые помогут сделать это как в нативных приложениях, так и в кросс-платформенных.

1. Введение

1.1. Обзор архитектуры RISC-V

1.2. Обзор инфраструктуры LLVM

2. llvm-exegesis как инструмент бенчмаркинга

2.1. Работа в режиме JIT

2.2. Запуски для baremetal

3. Интересные решения в llvm-exegesis бэкенде для RISC-V

- Dart: не только для фронта. Является ли он кольцом всевластья?

- Flutter: не только для UI. Какие задачи стало можно решить ныне.

- Цена кроссплатформы и почему Flutter for Web может стрелять в вас.

- "Хочу полный контроль"(С) или как рисовать то, что не было заложено изначально.

- "Повелитель пламени Анора"(С) или как укрощать flame.

- Три-в-ряд или серьёзные проекты?

- Резюме

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

Рецензирование требований - поможет сделать качество требований лучше, но всегда ли это нужно?

В рамках доклада я рассмотрю практики рецензирования требований и отвечу на следующие вопросы:

1. Когда рецензирование требований надо?

2. Когда оно вам точно не надо?

3. На что обращать внимание при рецензировании - на форму или на содержание?

4. Как организовать процесс рецензирования в зависимости от размера команды и процесса разработки.

Доклад будет полезен:

1. Тем, которые еще не сталкивались с процессом рецензирования требований;

2. Тем, кто пострадал от рецензирования требований и теперь не хочет про это слышать;

3. Тем, кто попробовал внедрить эту практику и она не взлетела.

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

- Краткий обзор факторов и сценариев, определяющих конечный продукт

- Мировой опыт в разработке модульных конструкций

- Собственный опыт в разработке модульных конструкций

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

Разберём разные алгоритмы поведения в таких ситуациях.

Когда речь заходит про multi-master режим работы СУБД, у многих разработчиков и архитекторов она часто вызывает эмоции от неприятия до практически презрения. Кто-то не уверен в стабильности такого решения, кто-то в его производительности. Если к этому добавляется необходимость разместить серверы в разных географических локациях, градус сомнения сразу умножается на 10. Между тем существуют сервисы, использующие СУБД именно в этом режиме. Мы в компании Базис-Центр создаём именно такие сервисы и я готов поделиться своим опытом сборки и эксплуатации MySQL кластера в multi-master режиме, рассказать каким инструментарием мы для этого пользуемся.

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

В докладе разберёмся какие бывают ЦОДы, что за сертификация у них такая, когда в облаке дешевле и удобней, почему могут отказать в размещении и что за мощность на стойку, о которой вас обязательно спросят. А может вам вообще ничего этого не надо и проще стойку в подсобке поставить.

C# — один из самых громоздких языков. Причина: плохие "гены" и архитектурные карго-культы.

Можно ли на C# писать простой код? С оговорками — да.

Поговорим про объекты-значения, интерфейсы, оборотную сторону принципа единственной ответственности, Entity Framework, Mediator, minimal API и top level statements.

Аннотация:

Расскажу и покажу как мы собирали диалоги и катсцены в Перелеске. Как интегрировали FlowCanvas в архитектуру Unity-проекта и как работали с кастомными таймлайнами. Как у нас получилось дать удобный инструмент геймдизайнерам и не сломать код.

Подробнее:
1. Роли в геймдев команде: зачем программисты пишут код, и кто такие геймдизайнеры. Dev2Dev: инструменты и код, которыми пользуются другие.

2. Из чего собирается игра и как собрать ее в сжатые сроки.

3. Сервисная архитектура проекта. Зависимости в коде и связи с контентом игры. Разделяем инфраструктурный и геймплейный код.

4. Сценарий, логика уровня и связи сцены. Собираем отдельный уровень.

5. Диалоговая система. Сервис для кода и визуальный редактор для геймдизайнеров

6. Катсцены. Timeline и Cinemachine в Unity

7. Реализация с FlowCanvas и пара слов о xNode

8. Вот теперь точно собираем один из уровней – диалоги

9. Сборка катсцен. Как попасть в тайминги озвучки.

10. Демо – первый уровень не анонсированной игры студии perelesoq

С бурным развитием CSS, все чаще мы слышим призывы к отказу от препроцессоров, в пользу первого. В докладе разберемся: нужны ли нам сегодня CSS-препроцессоры, и если да, то для чего?

Посмотрим на современные возможности CSS, которые реализуют часть функционала препроцессоров. Проверим, являются ли эти возможности заменой на самом деле. Далее рассмотрим продвинутые функции препроцессоров, про которые мало кто знает и которые вряд ли появятся в CSS. Разберемся, для каких задач может понадобится этот функционал, и посмотрим конкретные кейсы

Доклад будет полезен всем, кто занимается версткой, и особенно - CSS-энтузиастам

Многие знают, что существует стек 1С, и представляют его себе как платформу для "тётечек из бухгалтерии", но это далеко не так.

Посмотрим, какие решения сейчас реализуются на стеке, разберем роль системного аналитика в разработке на 1С, а также чем он отличается (и отличается ли?) от системного аналитика в других стеках. Посмотрим различия в работе в зависимости от модели работы организации: интегратор, заказная или внутренняя разработка.

Узнаем и обсудим:

- Какие инструменты есть у системного аналитика 1С?

- Особенности проектирования решения, на сколько легче или сложнее проектировать, когда платформа диктует свои правила?

- Правда ли, что им не обязательно знать английский язык, и так ли страшно смотреть на код на русском языке?

- Можно ли найти с ним общий язык и взять в НЕ 1С команду?

- Сложно ли будет стороннему системному аналитику, который попал в 1С среду?

А также разберемся с мнением, что системных аналитиков 1С не существует.

В текущих реалиях мы все чаще видим прецеденты атак на цепочки поставок, одной из наиболее нашумевших в последнее время стала заражение XZ Utils и только случайность позволила избежать массового заражения и инцидентов безопасности. Также многие считают, что безопасность цепочек поставок заканчивается на внедрении OSA/SCA решений.

В докладе расскажу о примерах атак, какие угрозы несет в себе использование Open Source и как работать с ними, что при разработке необходимо выстраивать "здоровый" цикл доставки доставки OSS и что атаки на цепочку могут быть не только в процессе использования OSS, но и при сборке ПО или его передаче.

«Посетитель» (visitor) — один из самых сложных паттернов Банды Четырех.

На языке C# для него можно создать множество реализаций, однако все они так или иначе имеют ограничения из-за возникающего динамического приведения типов.

В рамках доклада вы погрузитесь в проблематику мультиметодов и увидите новую реализацию паттерна, лишённую озвученных недостатко и открывающую возможность к написанию по-настоящему гибкого и типобезопасного кода!

- Анализ пожеланий клиентов по созданию эффективного аналога зарубежных BI-инструментов: Microsoft PowerBI и Google Looker Studio.

- Проектирование прототипа решения на базе opensource-технологий: Apache Superset (python) и своего плагина на java к Trino.

- Создание работающего BI-решения за 2 недели с активным использованием технологий контейнеризации Docker и Docker Compose.

- Масштабирование BI-решения с использованием Kubernetes.

- Работа BI-решения под нагрузкой в 25 000 компаний-клиентов - подводные камни и секреты.

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

- Организация процесса использования контейнеризации в разработке и эксплуатации для устойчивого дальнейшего развития "BI-конструктора".

1) Использование селекторов в чистой архитектуре (DDD)

2) Доклад об использовании паттерна "Селекторы", направленного на

* увеличение степени переиспользования частей orm запросов;

* увеличение читаемости orm запросов;

* изоляцию логики получения данных;

* увеличение гибкости программного кода.

3) Доклад представляет собой сторителлинг, в ходе которого простым языком изложен принцип паттерна селектор.

4) В ходе доклада будут разобраны следующие пункты:

* проблема;

* решение;

* теоретическое обоснование;

* практическое применение;

* преимущества подхода;

* недостатки подхода.