Разработка

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

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

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

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

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

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

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

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

* проблема;

* решение;

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

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

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

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

Два подхода к багам. Превентивный и фактический.

Фактический дебаггинг.

- С чего начать как эффективно распределять время и усилия.

- Как работать с неизвестными системами. -

- Изменения кода и инъекции для навигации в логики. Инструменты доступные, и которые надо создавать.

Примеры сложных багов в проектах, над которыми я работал.

Превентивный дебагинг.

- Как построить архитектуру проекта.

- Подход к работе с QA.

- Процесс сборки билдов. Юнит тесты или юзер тесты.

- Какие инструменты создавать, какие вещи настраивать.

Примеры систем и подходов которые были использованы на проектах, над которыми я работал.

1. Немного о нас

2. Краткое введение в GPGPU

3. Немного про ассемблер на видеокартах

a. AMD

b. Nvidia (PTX, SASS)

c. ассемблерный псевдокод

4. Ветвление: if, if-else – CPU vs GPU

a. CPU (godbolt)

b. AMD: Регистр для ветвления (exec)

c. Nvidia: ветвящаяся операция

5. Алгоритм распознавания ветвления

6. Циклы

a. Простой цикл

i. CPU

ii. AMD

iii. Nvidia

b. Распознавание цикла

c. Развёрнутый (unrolled) цикл

d. Алгоритм распознавания развёрнутого цикла (для GPU)

7. Заключение

1. C++ не является надмножеством языка C

2. Почему "мифический" С/С++?

3. Параллельное развитие языков.

4. Ограничение стандартов в докладе С++20(ISO/IEC 14882:2020) и С17(ISO/IEC 9899:2018).

5. Не каждая программа на С - это валидная программа на С++

6. Не каждая программа на С++ - это валидная программа на С

7. Код, валидный в обоих языках, но имеющий разное значение

8. Молчание компиляторов

9. Практики по написанию кода, в котором миксуются С и С++

Service Mesh – технология, которая призвана обеспечить гибкое, стабильное и надежное общение сервисов. Технология, призванная упростить эксплуатацию сетевого взаимодействия. Но сделает ли она систему проще?

За последние пять лет в Авито мы прошли путь от реализации собственного Service Mesh до внедрения Open Source решения Istio. И нам есть чем поделиться:

- Причины выбора собственной реализации и почему в итоге ушли на Istio?

- Организация локальности трафика при деплое в несколько датацентров

- Особенности внедрения безопасного общения (mTLS): откуда ждать сопротивление?

- Процесс внедрения массовых изменений в Service Mesh

- Как Service Mesh помогает ускорить разработку и тестирование за счет изолированных окружений?

- Так ли прост Service Mesh и стоит ли его внедрять?

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

Целевая аудитория:

- DevOps- и SRE-инженеры, поддерживающие сетевую инфраструктуру в компании

- лидеры, оценивающие целесообразность внедрения Service Mesh и платформенного подхода

Из каждого утюга доносится что Uiсистема (UI-kit) это здорово. Все говорят о плюсах но молчат о минусах. Предлагаю разобраться, так ли хороша UI-система.

Аккуратно посмотрим в прошлое, вспомним, как развивались бандлеры для фронтенда. Почему Vite всех победил и при чём тут нативные технологии. Обязательно будет шутка про инвалидацию кэша. Небрежно коснёмся архитектуры Vite. Разберём, как можно расширять Vite плагинами. Посмотрим какие крутые плагины уже есть в экосистеме и как написать свои. И разберёмся зачем это бывает нужно. Сделаем изящный вывод о важности автоматизации процессов в ~~жизни~~ работе фронтенд-разработчиков.

- PLM-среда на основе решений 1С: архитектура и возможности;

- Как наладить эффективное взаимодействие отделов и служб с использованием решения 1С:PLM

- Как внедрить и что учесть при внедрении программного комплекса

- Сквозной процесс: основные этапы жизненного цикла в среде 1С:PLM-1C:ERP-1C:MES на примере конкретного изделия

C++ славится тем что в нем все время стреляют себе в ноги. И как правило это связано с работой с памятью. Но, есть методы которые помогают справиться с этим. Давайте разберем один из методов разбора и сбора пакетов, который был успешно применен как в бекэнде в пользовательском пространстве, так и в ядре macOS для разбора USB пакетов. Метод позволяет работать с пакетами весьма эффективно, при этом обеспечивает полный контроль памяти, и не позволяет случаться таким ошибкам как “выход за границы буфера”.

Этот метод хорошо себя показал в высоконагруженном сервисе передачи видео в реальном времени. А так же драйвере для macOS, где использовался для работы с устройсвами по протоколу поверх USB.

- рассмотрим сам метод.

- как он позволяет структурировать код и доступ к данным.

- какие особенности будут у него в пространстве ядра

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

- какой код генерирует компилятор

- рассмотрим особенности связанные с кроссплатформенностью (неприятные сюрпризы от компилятора)

Расскажу о том, как писать свои библиотеки, совместимые с чем-то из стандартной библиотеки Python:

- Фиксируем протокол и убеждаемся, что под него подпадает "официальная" реализация.

- Пилим свои реализации протокола.

Расскажу про 2 свои библиотеки, которые расширяют то, что уже есть в стандартной библиотеке:

1. https://github.com/pomponchik/locklib - расширение возможностей мьютексов из стандартной библиотеки. Содержит универсальный протокол лока + реализации.

2. https://github.com/pomponchik/emptylog - расширение стандартного логгинга. Содержит универсальный протокол логгера + несколько его реализаций.

Современный мир предъявляет все новые вызовы для создателей информационных систем. Чтобы отвечать на них, индустрии ИТ приходится быстро развиваться. Одним из самых быстро растущих сегментов являются встроенные системы. Развитие происходит настолько быстро, что даже меняет само понятие встраиваемой системы. К примеру, еще несколько лет назад трудно было себе представить встроенную систему, которая имеет 4-ядерный процессор и оперативную память в несколько гигабайт. С другой стороны, как и прежде множество встроенных систем основаны на микроконтроллерах имеющих несколько килобайт памяти.

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

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

Условно ОС для встроенных систем можно отнести к трем большим классам:

ОС на базе Линукс (И других универсальных но конфигурируемых ОС);

ОС для микроконтроллеров (LibOS);

ОС реального времени (ОС РВ).

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

Одной из главных современных тенденций является увлечение функциональных требований к встроенным системам, в следствии чего, более 70 процентов всех встроенных систем основываются на различных вариация ОС Линукс. Более того постоянно делаются попытки улучшить характеристики ОС Линукс, чтобы применять ОС Линукс и в остальных 30 процентах, несмотря на существенных трудности в некоторых случаях.

В качестве примера можно привести марсолёт Ingenuity, который построен на существенно доработанном ядре Линукс. Трудность и доработка связанны с тем, что цикл управления, должен был гарантированно выполняться за 100мс.

Еще одним существенным фактом для применения ОС Линукс в embedded является фактор открытости. Компании, которые производят встроенные системы, не хотят быть зависимыми от производителя ОС, а как минимум иметь возможность влиять на ход разработки и вносить свои изменения в код проекта. В частности, это оказалось очень востребованным на фоне санкций.

Аналогично из-за стремления к независимости от производителя, все большее распространение получает открытая процессорная архитектура RISC-V. В России в последнее время фактически все производители процессоров отказываются от использования ядер ARM и переходят на архитектуру RISC-V.

Возвращаясь к попыткам использования ОС Линукс в embedded и связанных с этим улучшений в ядре, нужно выделить следующие:

KBuild билд систему позволяющую конфигурировать ядро в широких пределах;

DevTree систему спецификации оборудования, которая очень хорошо подходит для разнообразного железа применяемого в embedded;

Yocto Project (OpenEmbedded) & BuildRoot конфигурируемая сборка для корневой файловой системы;

Linux-RT система патчей модифицирующих планировщик и позволяющих получить более стабильное управление потоками в системе;

ucLinux (NOMMU режим) версия ядра позволяющая исполняться на системах без аппаратного MMU (микроконтроллерах).

Стоит отметить, что существуют ряд попыток движения со стороны LibOS в сторону увеличение функциональности и удобства разработки, то есть в сторону ОС Линукс.

NuttX - позволяет использовать POSIX ПО на микроконтроллерах. Сейчас слой POSIX добавляется в ряд LibOS в том числе наиболее популярную FreeRTOS.

ZephyrOS использует DevTree в синтаксисе Linux.

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

Использование данного предположения и позволило добиться в ОСРВ Embox сочетания преимуществ LibOS и ОС Linux. Embox - это открытая конфигурируемая ОС для встроенных систем. Основная идея Embox заключается в использовании прикладного ПО Линукс в более безопасном и детерминированном, менее энергопотребляемом и ресурсоемком окружении, в том числе на микроконтроллерах.

Embox имеет оригинальную систему сборки на основе собственного специализированного языка (DSL) описания модулей (Mybuild). Позволяющего строить граф модулей исходя из требовании к системе и зависимостям. Далее происходит генерация ряда артефактов для сборки, а так же сама сборка конечного образа. Сборка происходит статически и происходит анализ всей системы в целом, включая ядро, различные службы и библиотеки, прикладное ПО и так далее. Это позволяет добиться хороших характеристик оптимизации и создать образ максимально эффективно выполняющий указаные в описании системы требования.

С другой стороны, Embox имеет всю необходимую функциональность для построения современных emdedded систем: кросс-платформенное ядро, сетевой стек, файловую подсистему, графическую подсистему и так далее. Что позволяет создавать системы практически не ограниченные по функциональности. Из за этих свойст мы называем Embox - Linux без Linux.

История Embox начиналась с двух направлений: Студенческий проект по практике архитектуры ОС и ограниченная замена втроенному Линукс на специализированном устройстве. В дальнейшем обнаружились потребительские свойства позволяющие эффективноно создавать специализированные embedded-решения практически любой сложности и запускать из на широком спектре оборудования. В частности на российских процессорах, влкючая Эльбрус.

Портирование на Embox некоторых прикладных проектов привело к выявлению ошибок и исправлению. Например, была улучшена библиотека для создания VoIP телефонии PJSIP.

Кроме того, Embox является единственной платформой, которая позволяет использовать фреймворк для компьютерного зрения OpenCV на микроконтроллерах ARM cortex-m.

Разработка под Embox может вестись под ОС Линукс и является кросс-платформенной. Таким образом, разработанные проекты под микроконтроллеры STM были прозрачно перенесены под российские МК на базе RISC-V K1921DU015.

Встроенные системы имеют очень широкий спектр применения. Чтобы удовлетворить взаимоисключающим требованиям, высокой функциональности с одной стороны и предсказуемости поведения и низким потреблением ресурсов, можно использовать конструктор ОС, позволяющий создавать узкоспециализированные, но полнофункциональные ОС нацеленные на выполнение только заявленного функционала. Этими свойствами обладает ОС Embox.

- Что такое Modbus RTU и какие у него проблемы.

- Зачем нам возиться с RS-485 и Modbus, а просто не перейти на CAN?

- Натягиваем CAN-арбитраж на RS-485.

- Добавляем в Modbus RTU события, сканирование шины и другие полезные фичи.

- Как это работает. Посмотрим на байтики и физику шины.

1. API Gateway на Spring Cloud

2. Распределенная конфигурация и Spring Cloud Config Server

3. Обнаружение сервисов и Spring Cloud Eureka

При разработке каждого продукта есть свои особенности и это нормально.

А что если мы скажем, что сюда добавляются требования к развёртыванию от заказчиков, требования регуляторов, при этом мы хотим сохранять качество нашего продукта, как быть?

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

С++ является языком с богатой историей и мощным функционалом. На нём пишут программы для микроконтроллеров, создают игры, Базы Данных, Highload сервисы и многое другое.

Есть мнение, что старичку пора на пенсию. Ведь в последнее время появилось много специализированных языков, которые заменят С++. А языку 40 лет в обед.

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

Рассмотрим историю языка - рассвет в 90ых, забвение на рубеже веков и ренессанс начиная с принятием эпохального стандарта С++11 в 2011 году.

В рамках доклада мы погрузимся в неизведанные глубины спецификации языка Dart и рассмотрим ряд нереализованных фич, которые могли бы изменить его до неузнаваемости, но были отвергнуты программным комитетом. Узнаем, какие возможности они могли бы принести и почему остались лишь проектами на бумаге. Приготовьтесь к увлекательному путешествию в мир "А что, если?"!

С момента появления JDK для сортировки простых типов использовалась классическая (с одним опорным элементом) быстрая сортировка (Quicksort). В ноябре 2009 года в JDK 7 появился предложенный спикером улучшенный алгоритм быстрой сортировки Dual-Pivot Quicksort, который в 2,5–5,5 раза быстрее предыдущей версии.

За последние 15 лет Dual-Pivot Quicksort неоднократно улучшался по сравнению с первоначальной версией. Какие оптимизации и приемы использовались? Как повышалась производительность? Как правильно тестировать сортировку? Эти и многие другие вопросы затронет спикер.

Доклад заинтересует не только разработчиков, но и математиков, любителей алгоритмов, тестировщиков, а также всех тех, кто стремится к еще более эффективному коду и кто хочет внести свой вклад в развитие JDK.

Использование “больших” современных генеративных моделей поможет быстро собрать MVP или baseline, но текущее состояние технологий не позволяет получить высокое качество результата. Об этом как будто бы не часто говорят, но если хочется решать задачу хорошо, нужно ее дробить и вникать в процессы, которые автоматизируем. И скорее всего – искать более простые, иногда классические, инструменты.

Мы делаем продукт для автоматической ретуши фотографий товаров. Один из шагов ретуши – наложение тени.

Дано:

- большое разрешение фотографий;

- три ракурса съемки товаров;

- высокие требования к реалистичности тени;

- ограниченный объем данных для обучения.

Попробовали:

- тень по контуру;

- image-editing с помощью диффузии;

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

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

Расскажу про общие концепции и уровни логирования, основы логирования в Node.js, популярные библиотеки для логирования, ограничения Node.js. Так же про ротацию логов - что такое ротация логов и почему она важна и почему не надо это делать на Node.js. Пройдемся по жизненному циклу лога от записи до анализа. И чуть чуть про безопасность данных.

Весной 2023 года была поставлена задача запускать Flutter приложения на новой платформе KasperskyOS, а уже осенью было успешно запущено первое полноценное графическое приложение "Заметки" на мобильной версии KasperskyOS...

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

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

Большие языковые модели уже сами по себе неплохо умеют говорить, но пока ещё не способны решать сложные задачи, требующие цепочек рассуждений. Кроме того, возникает проблема, как научить их разговаривать в нужной нам предметной области, например, играть роль инженера тех поддержки. Мы рассмотрим разные стратегии решения такого рода задач - от использования In-Context Learning на основе продвинутых способов Retrieval-Augmented Generation (на основе графов знаний), до многоагентных систем. Поделимся примером кода, который вы сможете посмотреть дома, или же по ходу доклада или мастер-класса.

В рамках мастер-класса на практических примерах рассмотрим:

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

- Динамический анализ - техники выявления уязвимостей в реальных условиях работы приложения;

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

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

Краткое описание:

Область деятельности, связанная с внедрением процессов и технологий разработки безопасного программного обеспечения очень динамична. В 2024 году обновлен базовый ГОСТ 56939. Актуальность внедрения процессов и технологий РБПО многократно возросла с принятием Постановления Правительства № 1912, посвященного разработке доверенных программно-аппаратных комплексов, применяемых в том числе в АСУ и АСУ ТП, которые относятся к критической информационной инфраструктуре. В докладе будет представлен опыт планирования, организации и внедрения практик РБПО в организации разрабатывающей современные системы комплексы для систем индустриальной автоматики.

Начнем с истории эволюции хранилищ данных к состоянию Data Lakehouse.

Объясню, почему мы выбрали Ozone, и с какими трудностями столкнулись при внедрении.

Поделюсь решёнными проблемами и тем, которые ещё предстоит решить.

Завершу тем как мы взаимодействуем с Apache Foundation и прогнозом будущего Ozone после завершения эпохи Hadoop.