Доклады

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

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

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

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

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

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

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

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

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

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

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

- Анализ пожеланий клиентов по созданию эффективного аналога зарубежных 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) В ходе доклада будут разобраны следующие пункты:

* проблема;

* решение;

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

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

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

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

В какой-то момент многие компании сталкиваются с тем, что им необходимо внедрять перфоманс ревью.

Я в своем докладе я расскажу:

- для чего мы внедрили перфоманс ревью у себя в компании

- помог ли этот инструмент решить наши проблемы

- всю тяжесть проведения перфоманс ревью на ручнике

- автоматизация процесса - не значит идеальный вариант

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

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

В общем, этот доклад-признание про неудачные эксперименты :)

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

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

- Баланс - это то, что отделяет хорошую игру от скучной на одном полюсе и непроходимой - на другом

- Начало построения баланса: определение целей, определение методов, определение оценки

- Инструментарий: от гипотез к формулам

- Анализ результатов: единственный судья - аналитические метрики

- Заключение и рекомендации для комфортного начала работы балансировщиком

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

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

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. Заключение

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

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

Мы в HeadHunter начали разработку новой дизайн-системы больше года назад. За это время наткнулись на множество подобных нюансов. Опытом их обработки мы и поделимся с сообществом.

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

- Методы выявления фрода в рекламе

- Уровни противодействия: сайт и реклама

- «Предохранители» на запуске - набор настроек для минимизации фрода

- Боремся с ботами без сервисов - использование ИИ Яндекса

- Грамотный выбор стратегий и целевых действий в рекламных кампаниях

- 5 способов вернуть стабильную работу аккаунта при столкновении с фродом