- Хранилище морально устарело и не вывозит современных требований
- Нужен GIT, хотим Merge Request'ы, Code Review и все такое;
- EDT - слишком прогрессивно и не все до него доросли :-);
- Работаем с GIT не покидая конфигуратора и при чем тут автономный сервер;
- Скрипты упрощающие работу с GIT из Конфигуратора;
- Сборка/разборка обработок и расширений "на лету".

Этот доклад о том, как мы смотрим и оцениваем зрелость команд разработки 1С.
Для всех команд разработки нашего управления, не только 1С-ных, существует единая модель зрелости. Она предполагает оценку по 6 основным направлениям:
- Разработка: стек, код-ревью, работа с тех долгом и т.п;
- Эксплуатация: поддержка, мониторинги, SLA;
- Качество: тестовая стратегия, написание автотестов, работа с багами и т.п;
- Процессы: планирование, ретро, ревью сервиса поставки и т.п;
- People Management: онбординг, Performance Review, развитие сотрудника;
- Вклад в коммьюнити: развитие профессии, проведение интервью, стажировки.
Каждый из этих параметров имеет 3 уровня: Начальный, Стандартный и Экспертный. У каждого уровня – свои параметры (подтверждаемые артефактами).
Принято считать, что 1С-ники «не такие, как все», что у нас всё как-то по-своему. Но мы не отделяем команды 1С от других команд в плане зрелости и развития и предъявляем ко всем идентичные требования.
Два года назад мы ступили на этот путь: провели оценку с помощью экспертов из других, не 1С-ных команд, зафиксировали свой текущий уровень и начали движение наверх…
Каким был наш путь, какие практики мы осваивали, какие процессы развивали – об этом и будет мой доклад.

Как мы плакали, кололись, но продолжали пытаться включить и использовать оптимизированные для памяти метаданные tempdb.

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

Механизм гибких настроек оповещений об ошибках журнала регистрации в Sentry.
Мониторинг производительности базы 1С с помощью Sentry.
Опыт использования Sentry в компании Magnit Tech.
Преимущества использования Sentry перед другими бесплатными аналогами.
Интеграция Sentry с системами мониторинга инфраструктуры и сетями доставки контента.

В профильных чатах или на форумах возникают жаркие споры о тонкостях проектирования REST API. Однако часто упускается вопрос, зачем мы уделяем этому внимание и пытаемся проектировать "правильное REST API".
В ходе доклада обсудим, что такое REST, почему в большинстве случаев оно не нужно, и почему этот стиль такой популярный.

Главному инструменту DevOps в 1С исполнилось 10 лет. Я расскажу о том, что представляет собой экосистема 1Script в 2024 году и почему её важно включить в свой рабочий процесс.

Также поведаю:
• как и почему появился 1Script;
• к чему он пришел за 10 лет;
• обзор главных инструментов для 1С-девопса;
• анонс приключения-сюрприза от автора.

Данные растут по экспоненте, но подходы к их обработке и построению систем остаются неизменными и повторяются на уровне 10-15 лет назад. Мы все надеемся на универсальность и безошибочность платформы. Вместо того, чтобы изменить наши подходы, мы виним пользователей, оборудование, систему и, в конечном счете, платформу 1С - ожидая, что она придумает и реализует все за нас! Давайте возьмем инициативу в свои руки и попробуем использовать другие совсем не сложные методы для работы с большими данными. 
Мы погрузимся в проектирование форм, пользовательские сценарии, построение интерфейсов, поиск и многое другое.

1. Почему в 1С сложилось, что при WEB-сервисах используют XML, при HTTP - JSON.
2. Как можно комбинировать XDTO, XML, JSON, WEB, HTTP?
3. Почему REST API - это HTTP-сервисы + JSON?
4. WSDL - почему это удобно?
5. Безопасность, Надежность передаваемых данных, Нагрузка
8. Что проще реализовать?
9. Объем данных JSON vs XML.
10. Определяем ключевые требования к обмену, его назначение и применение: делаем выводы, что лучше нам подойдет по скорости, безопасности, функциональности.

- Зачем нам Элемент?
- Отличия от Платформы
- Особенности языка
- С чего начать разработку на Элементе?
- Перспектива для нашего Заказчика
- Опыт использования

Каждый кто переделывал или писал кадровые отчеты в ЗУП, ERP или УХ сталкивался с механизмом представлений. Это странный код запроса, где поля представлены пустыми ссылками и в наименовании временной таблицы есть слово "представление". В своем докладе я объясню, что это такое и как этим пользоваться. Больше не нужно думать как корректно и из каких регистров получать те или иные данные, механизм представлений сделает это за вас.

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

Минимум теории, сразу к практике. Будем использовать open source внешнюю компоненту. 
В рамках мастер-класса разберем:
        - Получение сообщений в 1С от не 1С источников
        - Обмен сообщениями между 1С базами 
        - Рассмотрим работу клиентов интеграции c SSL, SASL 
        - Попробуем формат сообщений AVRO, посмотрим на преимущества данного формата
        - Коснемся отладочной информации и как ее использовать при разборе проблемных кейсов интеграции.

Представьте, как иногда вы останавливаетесь и задумываетесь: может быть, стоит попробовать что-то еще? Кем я все-таки хочу стать, когда вырасту? Куда мне дальше развиваться?.
Возможно, вы размышляете, если бы вы были на месте руководителя, смогли бы вы организовать работу иначе, чем сейчас?
Это не пустые раздумья, это отражение нашего внутреннего потенциала.
Мы с вами обсудим:
1. Из каких составляющих сегодня складывается движение по карьерной траектории от разработчика 1С к управленцу
2. Где и каким образом можно прокачать ключевые компетенции для карьерного роста, на что обращает внимание топ-менеджер при выборе руководителей?
3. Эволюция профессиональных навыков – в какой момент придется (и придется ли?) попрощаться с hard skills?
4. Как понять, моё это или нет?

Воплощением ИИ сейчас являются лингвистические модели, тем временем в СУБД давно есть свой ИИ - планировщик запросов.
В докладе мы рассмотрим как из оператора кибераватара превратиться в тренера модели Postgres с помощью aqo и relplan.
Какие эффекты от этого может получить ваша система и стоит ли оно того.

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

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

В инструменте можно не только вносить замечания к коду в ручном режиме, отмечая при этом степень важности замечания, но и проверять измененный код с помощью проверок BSL Language Server. При этом процедуру Code Review можно проводить не только в 1С:Предприятии, но и на специализированном сайте, анализируя изменения из merge request`ов таких облачных веб-платформ, как GitHub и GitLab.

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

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

- Почему 1С:Элемент подошёл нам лучше остальных технологий
- 1С:Элемент как инструмент для создания "строгого" фронтенда
- Что делать если адаптивность интерфейса мешает разработчику?
- Приемы для создания собственных компонентов интерфейса
- 1С:Элемент как инструмент для создания бэкенда
- Фишки, которые кратно ускоряют скорость и удобство разработки
- Элемент — это не только площадка для
прототипирования и экспериментов
- Примеры разработанных решений на технологии, и опыт внедрения

- Можно ли разработать АСУТП систему на 1С? А нужно?
- Первая практика интеграции на автомобильном производстве
- Практика интеграции в пищевой промышленности 
- Комплексный пример на производстве товаров народного потребления – когда сделано все своими руками! 
- Перспективы развития

- Что такое менторинг, и в чем его отличие от обучения
- Роль менти и ментора
- Зачем заниматься менторингом?
- Зачем менторинг компаниям?
- Рекомендации для тех, кто хочет стать ментором

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

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

Много лет наша команда специализируется на задачах переноса данных 1С. Мы допускали за это время множество ошибок. На какие-то грабли наступали не раз, прежде чем смогли структурировать опыт и вывести для себя простые правила. Будем рады поделиться ими с сообществом.

- Критичные ошибки при планировании перехода, из-за которых теряются месяцы труда.
- Анализ и постановка задачи. Нужно провести исследование учета и также принять решения по учету до начала работ по переносу. Почему?
Какие пункты должны быть в анкете-опроснике для заказчика перед началом проекта? Предоставим свою версию такой анкеты
- Все говорят про плавный переход. Но для него нужен стабильный двусторонний обмен. Разберем, какими технологиями его можно организовать быстро и с минимальными затратами.
- Еще до организации онлайн-обмена нужно качественно перенести начальные остатки. Нужны корректные данные в исходной базе - как это проверить на примере перехода с УПП на ERP
- Специфические и отраслевые доработки конфигураций и их перенос.

У распространенных инструментов для обмена есть общая проблема – для их использования у вас в команде должен быть сотрудник с достаточно большим и специфическим объемом знаний и умений. Они требуют выделения достаточно больших ресурсов в том числе для текущий поддержки, администрирования, часто имеют сложности в отладке и развертке тестовой среды. Не много ИТ-команд могут безболезненно себе такое позволить, а у остальных, часто, задачи обмена «съедают» ресурсы в неуправляемом режиме.

В докладе я расскажу об используемых нами механизмах и подходах с примерами из реальных проектов. Технологии, для 1С, максимально простые – http-сервисы, json и собственно конфигуратор 1С. Представлю свободно распространяемый фреймворк собственной разработки, обеспечивающий простоту разработки и поддержки.

Теперь у нас проблемные, для многих, вопросы не вызывают никаких сложностей:
• Перенос остатков с огромной базы.
• Консолидация финансового учета с десятков баз в он-лайн режиме.
• Реализация «бесшовной интеграции».
• Анализ непротиворечивости данных между несколькими базами.
Для решения подобных задач нам теперь не требуется тратить сотни часов, как многим. А объяснение новому разработчику, где нужно настроить обмен по новому справочнику, занимает пару минут.

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

•        Шаг 1 – Аудит: запросы, общие черты и разные кейсы. Результаты аудита.
•        Шаг 2 – Оптимизируем производительность.
•        Шаг 3 – Моделируем нагрузку: сценарии нагрузочного тестирования.
•        Шаг 4 – Мониторинг корпоративных информационных систем на платформе 1С: проводим санацию и формируем приборную панель. SLA для высоконагруженных систем.
•        Аудит, как быстрый результат и первый шаг к глубокой трансформация подхода к работе с высоконагруженными системами на платформе 1С.

• Мы прошли определенный путь в части DevOps: что-то сразу получилось, что-то не получается до сих пор – хотелось бы поделиться опытом.
• DevOps нужен для участников процесса разработки прикладных решений. Возможно, из этого доклада кто-то увидит, что было бы полезно именно вам.
• Расскажем, как все начиналось, какие человеческие и технические ресурсы были выделены, какие задачи решали, какой результат получили.
• Расскажем, как переходили на EDT, что это дало, как повлияло на наши сборочные линии.
• Покажем, как выглядят сейчас наши процессы – то, как именно мы, инженеры DevOps, полезны всем, кто участвует в разработке.
• Расскажем, как мы идем (или уже пришли) в k8s, что нам это даст (или уже дало).
• Основная цель – показать, что можно внедрять практики DevOps на разных масштабах проектов, с разным количеством доступных ресурсов.
• В докладе не планируется заострять внимание на конкретных инструментах и приемах, в конечном итоге у всех разные стеки. Большее внимание хотелось бы уделить тому, какую пользу можно извлечь из практик DevOps.

1. Флагманскому продукту ERP 10 лет.
2. Какие специалисты создают ERP?
3. Как тестировать не один продукт, а сразу семь?
  - Каскад вырезки конфигураций.
  - Перевод метаданных, кода, тестов в "дочерних" конфигурациях
4. Edt, git, CI, Docker, Openstack, автотесты.
5. Автоматизированные тестирование - самое мощное тестирование из всех продуктов 1С.
6. Нагрузочное тестирование 
7. Может ли 500 ванесс спеть хором? Используем тестовое облако Openstack.
8. Все еще тестируем вручную. Но что? 
9. Регрессионное тестирование - есть ли оно?
10. Выпуск и как он зависит от Fresh.
11. Качество продукта.

Задумывались ли вы когда-нибудь, сколько времени разработчики тратят на ерунду?
Например, сколько часов пройдет от выдачи задачи до первой строчки кода по проекту? Разработчику нужно найти основную поставку, развернуть ее на нужной платформе, создать и открыть хранилище, настроить пользователей и подключить гитконвертер. Только после этого он может приступить к работе.

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

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

Хотя при этом программисты стараются думать об удобстве работы пользователя. Но почему-то за своим удобством не следят.

В выступлении погрузимся в мир Developer Experience (DevEx) и рассмотрим препятствия и их преодоление на пути эффективной разработки. Научимся искать ерунду и разбираться с ней.

Технология CoW (Copy-On-Write) уже несколько раз была представлена на Инфостарт, но хочется рассказать и про нашу реализацию. 
Расскажу: 
1. Вкратце о самой технологии, которая позволяет экономить огромное количество дискового пространства, и почему от нее (должен быть) низкий «оверхед». 
2. Какие фс (спойлер – xfs и btrfs) мы рассматривали и какую выбрали. 
3. Как мы из 1С выполняем команды по управлению подтомами на линуксовом сервере. 
4. Какой SQL (спойлер – MS SQL) установили на линукс и почему. 
5. Как сделали доступными эти инструменты (база 1С, какие у нас варианты :) ) для простых разработчиков. 
6. Сколько Тб сэкономили и сколько еще сэкономим. 
7. Как это сказалось на разработке и тестировании и времени, которое разработчики тратят на развертывание баз. 
8. Как встроили это добро в наш CI, и как это помогает расследовать длительные регрессы. 
9. И, конечно же, какие есть планы по развитию этих инструментов.

В рамках мастер-класса мы расскажем и покажем:

• в каких случаях следует проводить нагрузочное тестирование
• как подготовить нагрузочный тест, чтобы он был максимально приближен к боевым условиям и показал возможные проблемы
• запустим нагрузочный тест на 3 тысячи пользователей прямо на мастер-классе
• посмотрим как ведет себя СУБД при таком количестве пользователей, на какие показатели следует обратить внимание
• поясним какое оборудование подойдет для таких нагрузок и как обстоят дела с его масштабированием

Часть 1. Зачем я перенес «Героев меча и магии» на 1С

1. Мои первые шаги в разработке игр на 1С: расскажу о том, как я пробовал делать проекты на 1С в свободное время. Были попытки перенести «Сапер» или «Морской бой» на платформу 1С
2. Мой magnum opus – «Герои меча и магии» на 1С, расскажу, как в моей голове зародилась эта идея, как она выглядела до реализации, покажу геймплей и трейлер игры
3. Как так вышло, что компания не посмотрела на меня с таким проектом, как на дурачка, а поддержала и выделила ресурс

Часть 2. Как я перенес героев меча и магии на 1С

1. Поговорим немного о структуре проекта, какие объекты использовались, почему именно такая структура,
2. Расскажу о трудностях, которые возникли в ходе разработки – как реализовывали механизм поиска маршрута, как разрабатывали искусственный интеллект врагов
3. Немного о дальнейших планах развития этого проекта и о том, какую игру будем переносить на 1С следующей

- Что такое Архитектура как Код
- Общие примеры архитектуры в контексте 1С
- Цель описания требований и процессов
- Проектирование и анализ метаданных и программного кода
- Что дает переход к концепции Архитектура как Код

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

На все, конечно же, не хватает времени и внимания, но в данном докладе все же попробую выделить наиболее интересные события из мира 1С-разрабтки за последние 2-3 года.

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

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

Владельцы 1С-систем сейчас делятся на две категории: тех, кто уже перевел системы на PostgreSQL, и тех, кто решается на этот шаг. Про процесс перехода сказано уже довольно много, но вот есть ли жизнь после миграции? Как следить за новым "зверем", что у него может болеть, как это увидеть и вылечить?

Доклад основан на нашем опыте аудитов и эксплуатации систем на базе PostgreSQL:
• мы расскажем об инструментах
• покажем, как понять, достаточно ли вам буферного кэша или, наоборот, его слишком много (да, это тоже может быть проблемой)
• как мониторить работу чекпойнтера, автовакуума, репликацию и многое другое.
 
А самое главное, расскажем, как интерпретировать результаты.

1. Почему наставники не эффективны: проблематика масштаба компании.
2. Системный подход при индивидуальном обучении 100+ разработчиков
- Матрица компетенций
- Система определения уровня знаний разработчиков
- Треки обучения
- Система закрепления знаний
3. Путь от наставников к экспертам
4. Чтобы система не стала хаосом: наши «грабли»

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

В рамках доклада пройдемся по выпущенным за последнее время версиям и разберем анонсы новой функциональности:
1. Посмотрим на новые возможности в программах для разработки и эксплуатации
2. Разберем примеры реального использования новых возможностей
3. Поговорим о том, какие дополнительные технологии стоит изучить, чтобы не отставать от развития платформы

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

А еще мы знаем, что дампы можно и нужно анализировать даже тогда, когда у вас нет исходников: часто причину аварийного завершения и даже зависания можно понять и обойти, не отвлекая вендора.
В докладе мы покажем:
• какими инструментами пользуемся при анализе дампов в Linux и Windows
• что можно увидеть в трассировке стека и как это использовать

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

В мире 1С импортозамещение используемых программных продуктов в первую очередь касается миграции СУБД с MSSQL на Postgres. 
Одной из основных проблем перехода является более «слабый» оптимизатор запросов Postgres по сравнению с MSSQL, когда запросы на MSSQL выполнялись значительно быстрее, чем на Postgres.
Нами был разработан инструмент, позволяющий без значительных затрат выявить эти «проблемные» запросы. Основная идея нашего подхода: конвертация на Postgres запросов, снятых при использовании MSSQL, и сравнение времени выполнения на MSSQL и на Postgres. 
В докладе я расскажу об этапах работ. 
Опишу проблемы, с которыми столкнулись при решении задачи. 
Покажу результаты использования нашего инструмента на реальных базах. 

1. Упростим и ускорим обмены данными, используя простую технологию. 
2. Зафиксируем изменения, чтобы коллеги с других стеков были нами довольны. 
3. Делаем дешевую реплику и уменьшаем нагрузку с базы данных 1С. 
4. Прокачиваем терабайты в считанные минуты.

2 года назад мы начали работать с технологией 1С:Элемент в рамках веб-сервиса Кабинет сотрудника. На текущий момент в приложении работает более 40 тыс.сотрудников.

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

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

EDT – для тех, кто никуда не спешит
Как мы пришли к выбору EDT в качестве среды разработки
Тернистый путь от монорепозитория к ветвистой структуре репозиториев
Слоистая архитектура нашего продукта
Плюшки EDT и как их правильно использовать
Как мы строим процесс работы в команде

Мастер-класс по настройке встроенного в PostgresPRO отказоустойчивого кластера BiHA
Установим, настроим, посмотрим как система отработает отказ Лидера.
Соединим с кластером BiHA сервер 1С и посмотрим на его реакцию при отказе Лидера.

Расскажу про кейс реализации 2х приложений на 1С: Элемент. Первое - производственное, которое (в паре с планшетом) помогло частично уйти от бумаги и облегчить жизнь операторов станков на производстве. Второе - необходимо для авторизации в "первом"
1. Как и почему мы получили доступ к onprem раньше сентября 2024
2. Как и почему мы не хотели делать очередной кабинет сотрудника
3. На какие грабли наступили при проектировании и разработке решения для производственного контура на Элементе
4. Как проходило погружение в новую "околоодинэсную технологию"
5. Небольшое сравнение похожих фич на V8 и 1С: Элемент (включая сравнение трудозатрат)
6. Немного результатов. Что мы получили и что мы потеряли, решив в сторону Элемента, а не всем знакомой v8. Как 1С: Элемент работает почти на каждом станке предприятия

Зачем уметь оценивать задачи, методы и примеры оценки.
1. Зачем уметь оценивать задачи. Почему это полезно всем?
2. Ограничения, которые нам мешают оценить задачу.
3. Способы оценки задач: групповые и индивидуальные.
4. Всегда ли надо умножать оценку на 3,14? Типы разработчиков, и как с ними работать.
5. Более подробно об индивидуальных способах оценки задач как об основном инструменте разработчика. С примерами.
6. Найдите тип ошибки, которая была допущена при оценке задач. (Интерактивная часть доклада.)
7. Рекомендации по дальнейшей работе над навыком оценки задач.

Не для кого не секрет, что для нашей любимой платформы сообщество энтузиастов создало огромный набор инструментария. Для управления исходниками, тестирования, проверки кода и т.д. Вот только небольшой список: vanessa-runner, VanessaADD, vanessa-automation, BSL LS, yaXunit, onescript и многие другие. Так же к нам все ближе подползают технологии из других IT сфер, SonarQube, allure, git, и что-то я обязательно забыл. Так вот, как же не потеряться во всем этом многообразии? Я подарю вам универсальный инструмент, в котором попытался объединить все достижения сообщества последних лет.

Вы только представьте - современный, отзывчивый и красивый интерфейс, где можно:
- Управлять исходниками конфигурации/расширений/отчетов и обработок;
- Запускать тесты и просматривать результат;
- Проводить анализ с помощью линтера BSL LS (так же как в SonarQube);
- Отслеживать изменения git;
- И много еще чего.

И все это, не уходя со своего рабочего места.

В рамках доклада хотим рассказать о технологии для работы с большими данными https://ytsaurus.tech/ru.
Технология недавно вышла в Open source, но внутри Яндекса применяется давно и очень активно. Хотим рассказать о самой технологии, какие задачи она решает, как ее можно развернуть внутри своей компании. Как эту технологию мы юзаем в связке с 1С, какие есть уже готовые модули для интеграции с ней.
Также рассказать какие подходы применяем к проектированию 1С с учетом наличии данной технологии (ytsaurus). Доклад будет совместный от разработчиков ytsaurus и команды 1С Яндекс.Лавки.

Мы начнем с краткого обзора возможностей системы, а затем создадим приложение на платформе 1С:Элемент для программы Infostart-event.
В завершение оценим получившийся результат и обсудим ключевые моменты процесса.
Не упустите шанс погрузиться в разработку на 1С:Элемент!

Тезисы:
1. Краткий обзор возможностей 1С:Элемент
2. Попробуем создать на 1С:Элементе приложение программы Infostart-event.
3. Наполняем программу мероприятия.
4. Смотрим, что получилось и гордимся собой)

Кто будет более успешен в карьере: сильный разработчик с чистейшим кодом, но сложный в общении, или разраб «средней руки», умеющий выстраивать коммуникации? Кто победит в битве интеллектов: IQ или EQ?

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

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

Тезисы к теме:
• Что такое эмоциональный интеллект? Составляющие EQ
• Почему развитый эмоциональный интеллект ВАЖНЕЕ hard skills IT-шника?
• Экспресс-тест проверки уровня развития EQ
• Эмоции. Добро или зло? Первопричины деструктивных эмоций
• Способы прокачки EQ. Как стать «эмоционально умным».

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

Поделюсь опытом поддержки баз 1С с 6000+ одновременно работающих пользователей и расскажу о преимуществах и недостатках применения разных инструментов для мониторинга корпоративных ИТ-систем.

Ключевые вопросы, на которые я отвечу в своем докладе: 
•        Технологический журнал в Elastic: необходимость или нет? 
•        Почему ClickHouse — идеальный выбор для хранения метрик?
•        Ручной разбор блокировок: почему это долго и что делать?
•        Сбор статистики «про запас». Почему это важно? 

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

Данную задачу великолепно выполняет брокер сообщений Active MQ совместно с самостоятельно разработанным нашей компанией маршрутизатором сообщений. В его преимущества входит:
• понятный графический интерфейс управления маршрутами сообщений;
• шаблоны трансформации;
• поиск и переотправка сообщений в случае ошибки и т.д.

При работе «инхаус», у команды разработки всегда много заказчиков:
• Всем нужно уделить время
• Рассчитать сроки
• Рассказать, когда будет сделана задача, и почему кому-то делают быстрее
И никого не обидеть
Как перестать делать одну работу и освободить время для другой нужной работы?

Мы разработали табло очереди задач, которое помогает нашим тимлидам:
- Аргументированно разговаривать с заказчиками
- Прогнозировать трудоемкость поступающих задач на основе предыдущей статистики
- Прогнозировать сроки реализации задач на основе мощности команды и параметров приоритизации. А какие – расскажем на конференции
- Автоматически рассчитывать стоимость каждой фичи (план и факт)
Что вы получите по результатам доклада:
- Методичку для самостоятельной разработки инструмента на ваших технологиях
- Наши контакты для референса. У нас есть планы по развитию продукта, вероятно, вам будет интересно узнать новости

В докладе:
- Как мы в Magnit Tech переводим базы 1C на PostgreSQL
- Что бы мы порекомендовали сами себе сделать до начала перевода систем на PostgreSQL 3 года назад
- Как мы проводим предварительный анализ 1С-систем с помощью чек-листов и других инструментов
- Как мы автоматизировали тестирование при переходе на PostgreSQL
- Как мы мигрируем базы в несколько терабайт и какие видели при этом проблемы

Расскажу о том, что бизнес поставил мне задачу – написать конфигурацию, которая хранит в себе данные и отвечает на запросы внешних пользователей.
В результате этой работы у меня появилась библиотека с набором универсальных функций, который мне позволили быстро расширять функционал HTTP-сервиса, быстро писать АПИ.
Далее эта библиотека позволила писать обработки выгрузки данных из любых конфигураций в формате JSON, или же делать расширение, которое можно сформировать, было используя эту библиотеку. Быстрый HTTP-сервис без больших затрат.
В результате бизнес получил выгоду, так как с помощью этот библиотеки мы смогли быстро экономить и разрабатывать микросервисы на базе 1С.
В рамках этого доклада я расскажу:
1. О функциях, которые я разработал для АПИ для работы с HTTP
2. Об универсальных функциях выгрузки объектов в формате JSON/
3. О тезисе о том, что если бы такие библиотеки можно было публиковать и делиться, отдать другим разработчикам на внесение изменений, то мы бы имели подобие готовых библиотек как в GO и PHP, это многократно бы экономило наши ресурсы.

Flow, структура разработки, организация процесса разработки – как не назови, это все про одно: доставка кода от IDE разработчика до продуктива. У кого-то IDE – это сразу конфигуратор прода, а чей-то код вынужден совершать долгое и героическое путешествие к точке назначения, пробиваясь через десяток статусов в JIRA, статические анализаторы кода и злобное Code Review коллег, преодолевая несколько этапов ручных и автоматизированных тестов и, наконец, долго ждать часа «Хэ», чтобы наконец выкатиться в Продакшн.

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

Надеюсь, будет полезно и интересно.

Дымовое тестирование внедрили на завод. Как это было. 

0. Вводная. На предприятии несколько хранилищ (дев, препрод). В препрод доработки помещаются руками, возможны ошибки. Тестирование после помещения проходит по части доработки, а все, что отпало «сбоку», будет найдено уже пользователями.
1. Подготовка. Сервера, доступы, программы, сбор требований и возможностей. 
2. Быстрый старт: развернули дымы, развернули сонар, написали скрипты, показали, передали.
3. Польза. Сколько было обращений после апдейта, сколько стало. Сколько стоило и стоило ли того.
4. Что было дальше. Перспективы развития проекта, другие конфигурации, сценарные тесты, долгосрочное сотрудничество

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

В докладе:
1. Исследуем феномен профессиональных синдромов среди разработчиков ПО;
2. Рассмотрим различные типы синдромов:
- Синдром самозванца – ты думаешь, что тебя вот-вот разоблачат, как в шпионском фильме;
- Эффект Даннинга-Крюгера – когда ты уверен, что знаешь всё, но потом падает задача, требующая больше, чем "скопировать и вставить"
- Перфекционизм – ты переписываешь одну строку кода 100 раз и всё равно не доволен;
- Прокрастинация – «завтра» становится твоим любимым днем недели;
- Затунелливание – ты застреваешь в бесконечной петле отладки.
3. Научимся распознавать эти синдромы в себе, и вместо борьбы с ними просто научимся с ними дружить, ведь иногда лучший способ справиться с синдромом – это просто налить себе чашечку кофе и признать: «Да, я тоже человек!»

Что разберем:
Рассмотрим конкретные примеры различных тестов:
- Интеграционные (регистрация, выгрузка, обработки по сверкам с использованием IHL)
- Поведение системы (проведение, запись, регламентные задания)
- Отчеты
- Работа форм

Какая польза этого подхода:
1) Защита от регрессионных ошибок.
2) Прогноз/быстрое исправление ошибок после типового обновления конфигурации от поставщика.
3) Легкий рефакторинг - снижения сложности.
4) Упрощение сопровождения и развития.
5) Легкость написания правил обмена.
6) Тесты в расширении, а не в обработках.
7) Уверенность, что все учел и ничего не забыл.
8) Благодаря тестам и поставляемым данными, всегда есть демо-база для удобной разработки локально.

Когда мы только задумывается об оценке программистов и разработчиков, то в самом начале становится сложным определить компетенции и знания, которые необходимо оценить.
Практический диалог о том, как выбрать компетенции для оценки сотрудников.
Тезисы:
1. Что такое компетенции и зачем их оценивать?
2. Интервью как метод определения компетенции сотрудников для дальнейшей оценки.
3. Критические вопросы и как их правильно задавать? Какую информацию необходимо услышать и зафиксировать?
4. Как собрать итоговый профиль компетенции для оценки? Что главное?
Практические подсказки и вопросные листы для дальнейшей работы.

Разработка через библиотеки:
- области видимости и программный интерфейс
- ролевая модель
- тестовые данные
- как предусмотреть расширение данных
- реализация компонент
- подготовка интерфейса
Создание приложения:
- использование библиотеки
- реализация требований библиотеки
- расширение библиотечных данных

Жизненный цикл развития – от инициации до завершения.
План развития: его актуальность зависит от того, насколько прикладным он будет для каждого конкретного руководителя и специалиста
- Компетенции и операции – как соотнести план развития и текущую операционную деятельность?
- Компетенции и проекты – как синхронизировать план развития и "будущее"
- Компетенции и личные цели м чтобы план работал, он должен быть значимым

Формула внедрения 1-2-3: шаг развития, два практики, три эксперимента
- Наедине с собой – пересмотреть планирование, включить новые инструменты в работу
- Вдвоем с руководителем – как правильно запрашивать обратную связь
- С командой – развиваться можно и нужно вместе

Анализ результата и закрепление
- Система метрик для специалиста и руководителя
- Чего должно стать больше в сотруднике, управлении, процессах, проектах, продуктах?
- Форма влияет на все – какие могут быть формы самообучения и обучения на рабочем месте, продукты выхода каждой из форм

Работа с табличным документом хранящимся на сервере
Динамическое построение дерева и реализация сложного поиска в нем
Правильное и здорово использовать длительные операции (выполнение в фоне)
Несколько примеров проблемных ситуаций, ошибок и варианты их решения

Люблю работать с ИИ и хочу поделиться с вами своими наработками в этой области.

Доклад для тех, кто устал слышать из всех утюгов про «ИИ-менеджеров по продажам», «ИИ-HRов» и т.д. и хочет реально разобраться в том, а как это все работает и работает ли.
1. Рассмотрим, как устроены LLM модели;
2. Сравним работу различных MLLM моделей (на реальных примерах по обработке текста, фотографий, файлов, а также генерации кода в области HR, маркетинга и разработки в реальном 1С-Франчайзи);
3. Рассмотрим сервисы, с помощью которых можно получить доступ к MLLM моделям;
4. Обсудим последние новости и перспективы развития МLLM моделей в России и за рубежом.

"Правильно сформулированный вопрос содержит в себе половину ответа" - эту поговорку не всегда надо понимать буквально :) Это надо понимать как "в правильно сформулированном вопросе задано, что и в какой форме нужно ответить".
Один из главных навыков руководителя - навык слушания. Но он основан на не менее важном навыке - задавать вопросы. Вопросы, на которые хочется ответить, которые не вызывают боли или сопротивления.
- Как задать правильный вопрос?
- Какой вопрос будет "хорошим"?
- А какие вообще бывают вопросы?
Хочется надеяться, что по результатам доклада слушатели построят для себя план развития в искусстве переговоров и активного слушания.

Что вас ожидает на докладе:

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

* История развития YAxUnit: Погрузитесь в историю нашего инструмента, от его первых версий до текущего состояния. Обсудим ключевые этапы его развития и как со временем изменялись подходы и технологии.

* Работа над open source проектом: Расскажу об опыте управления YAxUnit как open source проекта, расскажем о трудностях и успехах, связанных с открытым исходным кодом, и о том, как сообщество поддерживает и развивает инструмент.

* Организация CI на GitHub: Узнайте, как мы настроили процесс непрерывной интеграции (CI) на GitHub для обеспечения высокого качества кода. Мы обсудим подходы к автоматизации тестирования, настройке процессов и тому, как это помогает поддерживать стабильность и надежность инструмента.

1. С чего начиналось тестирование. От выбора первого инструмента до полного набора инструментов на текущий момент (Vanessa-ADD, Vanessa-Automation, YAxUnit, Coverage41C, Docker, Gitlab CI, Allure, SonarQube). 
Что стало решающим при выборе Vanessa-ADD как первого инструмента. 
Запуск нескольких видов тестов (дымовых и сценарных) в CI-контуре на win сервере. 
Какие задачи решаем при помощи YAxUnit. 

2. Запуск анализа покрытия кода тестами при помощи Coverage41C. 
Зачем понадобилось считать? 
Сложности в настройке подсчета на клиент-серверной базе. 

3. Переход в Docker. 
Взяли за основу готовый образ, но в итоге собрали свой 
Переход с Windows и PowerShell на Linux и Bash 

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

- Azure - это не только облако, но и on-premis инструменты Azure DevOps;
- Если у вас есть проекты на C#, то вполне вероятно, что инструменты CI можно использовать и для 1С;
- Типичный конвейер сборки/тестирования на Azure pipelines для конфиурации 1С;
- Чего не хватало, полезные расширения Azure для 1С;
- Прикручиваем OneScript к Azure pipelines;
- Переиспользование существующих инструментов CI в Azure pipelines.

В докладе расскажу:
- Зачем переводить 1С на Linux
- Наш опыт перевода конфигураций 1С на Linux
- Что нужно учесть при переводе конфигурации на Linux
- Инструменты для анализа и рефакторинга при переводе на Linux
- Примеры анализа и рефакторинга конфигурации
- Тесты и чек-лист перед миграцией на СП 1С на Linux
Речь пойдет о серверной части конфигурации 1С.

В рамках доклада мы расскажем о том, что из себя представляет эта платформа https://infostart.ru/public/1153616/, чем отличается разработка на ней и как она помогает 1С решениям стать еще лучше.
Отдельным блоком в выступлении станут примеры того, как используя платформу можно решать задачи, которые сложно, или даже невозможно решить типовыми средствами.
Весь доклад будет сопровождаться практическими примерами из реальных проектов.

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

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

Вы собрали свой первый пайплайн на базе Gitlab CI? - Поздравляю, вы молодец!
Но что делать, когда количество проектов начинает расти?
Увеличение длительности выполнения, дополнительные трудозатраты по поддержке скриптов и прочие неприятные моменты.
В своем докладе я расскажу о:
- Проблемах возникающих при росте количества проектов
- Подготовке образов для запуска заданий в контейнерах
- Оптимальных настройках gitlab runner
- Приемах повышения скорости выполнения заданий при работе с EDT
- Использовании CI/CD components для дедупликации кода пайплайна
- Выпуск артефактов релизов используя Gitlab Package Registry и Releases

Неявные ошибки при написании запросов, которые могут повлечь определенные неприятности в работе БД и при последующей доработке (переиспользовании кода). Доклад построен на примерах, выявленных при проведении код-ревью и призван подсветить аспекты при разработке запросов 1С, которые могут послужить основой для составления собственного чек-листа.

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

- Типы программ стажировки и показатели их эффективности.
- Недостатки типичных стажировок и пути их преодоления.
- Оптимальная тактика проведения стажировки. Есть ли какая-то одна беспроигрышная?
- Фидбеки от менторов: взгляд стажера.
- Оценка прогресса стажера: системы контроля и регулярного фидбека.
- Развитие Soft Skills: подготовка стажеров к реальным рабочим задачам. Какие soft skills необходимы начинающим разработчикам?

Мы в Т-Банке решили, что пора бы уже оставить старый добрый MS SQL и Windows ради новых горизонтов с Postgres и Linux. Казалось бы, что может пойти не так?
1) А готова ли инфраструктура? Как мы планировали убить несколько зайцев сразу.
2) Первые трудности. База не грузится на Postgres, спасает только probackup.
3) Тёмные места в зарплатных механизмах, фактический период действия.
4) Ошибки платформы и миллионы циклов при записи в регистр расчета.
5) Как нам не помог Postgres Pro Enterprise, CFS - не панацея.

Цель игры: решить максимум кейсов за 30 минут в 1С:ERP 2 (на демо-версии).
Правила игры: каждый участник решает 3 кейса по 5 минут.
Суть кейсов:
1. Кейсы аналитика: разработчик портит данные в системе и показывает какой механизм в системе работает неверно. Цель аналитика - найти какие данные испорчены (объекты расчетов, записи регистров и т.д.)
2. Кейсы разработчика: аналитик портит код в системе и показывает какой механизм в системе работает неверно. Цель разработчика - найти какой код испорчен и восстановить верный код.

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

Победителя выбирает жюри из 5ти участников, а также голосованием в чате Инфостарт.

p.s. по заданию Марии Серегиной - участники будут в тематических костюмах.

Расскажу вам о том, как не ухудшить производительность интеграционного решения в процессе разработки и рефакторинга когда новых фич в коробке все больше, а требования по производительности все выше.
На живом примере покажу реализованный подход с использованием различных инструментов, таких как - Docker, Redash, Vanessa Automation.
Доклад в первую очередь будет полезен для тестировщиков.

Все разработчики, доходя до уровня мидла, задаются вопросом: а что мне делать дальше? Подобно герою сказки, мы стоим на перепутье и хотим понять, куда нам двигаться: начать развиваться в сторону аналитика, или стать управленцем и отказаться от программирования, или пойти по пути профессионала своего дела и стать сеньором. Я выбрал третий путь и готов поделиться своим опытом того, как стать сеньором
Тезисы доклада:
1. Кто такие джун, мидл и сеньор, и какие проблемы они решают.
2. Испытания, которые я прошёл на пути к сеньору.
3. Как понять, где ты сейчас и как строить свой вектор развития?
4. Стоит ли идти по пути сеньора?

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

Как проводить нагрузочное тестирование в облаке и при этом не платить за простои?

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

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

В докладе рассмотрим работу кластера 1С с уровнем отказоустойчивости более 0.
Какие сервисы кластера как себя поведут при потере одного из центральных серверов
Как вернуть кластер в начальное состояние
Что будут получать клиенты 1С при выходе сервера из строя
Как там с лицензированием

В докладе приводится наш опыт разработки юнит-тестов для одной из самых нагруженных 1С ОЗОН. Какой опыт мы получили, какие выводы сделали и к каким правилам пришли.

1. Обычные формы не приговор
2.  Как писать тесты в активно-развивающейся конфигурации на обычных формах
    - Особенности использования yaxUnit
    - Какие механизмы тестировать в первую очередь
    - Что делать, если сложно протестировать
3. Разберем примеры тестов
    - Модульное тестирование API (http-сервисов)
    - События объектов (проведение, заполнение)
    - Сложная бизнес логика
4. Полезные советы по разработке тестов в конфигураторе

"Надо было не так", "Надо переделать", "Это же было очевидно"... Этими или похожими фразами к нам может прилетать обратная связь. А иногда мы сами гоняем эти мысли внутри себя. Они могут дать позитивный толчок и направить в нужное русло, если правильно ими воспользоваться. Но всегда ли это выходит?

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

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

Дорога будет длинная, но поедем быстро, так что пристегнитесь!

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

Потом поговорим о нашем отношении к задачам и результатам нашей работы. Разберем, чем опасны крайние варианты:
1. Когда мы воспринимаем критику в адрес нашей работы, как критику в наш адрес и не можем относиться к ней рационально.
2. Когда мы отстраняемся и уходим в режим "мне всё равно, как скажете, так и сделаю" или "делайте сами как хотите".

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

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

В рамках доклада:
- разберем и проиллюстрируем архитектурные особенности основных видов обменов в 1С;
- поделимся реальным проектным опытом в части оптимизации обменов (типовые обмены 1С, прямые запросы, событийные обмены);
- обозначим узкие места в реализации интеграций в разных технологиях;
- расскажем о создании событийных обменов с помощью различных объектов конфигурации.
Наш доклад – для вас, если вы работаете с интеграциями и принимаете решения, влияющие на архитектуру системы, и, если для вас важно понимать границы оптимизации в рамках примененной технологии и достигать максимальной эффективности обменов.

Разберем 15 распространенных и малоизвестных мифов о работе платформы "1С:Предприятие 8" в формате «Тезис -> Тестовый пример -> Подтверждение или опровержение -> Обоснование». Начнем с одного из самых известных: работает ли код, написанный в одну строку, быстрее, чем многострочный и почему так происходит. После этого перейдем к менее распространенным мифам.

В разработке.

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

Облачные технологии и DevOps практики изменили лицо современной разработки. В моём докладе вы найдёте ключи к эффективной интеграции этих инноваций в ваш рабочий процесс. Я поделюсь с вами опытом создания и настройки конвейера CI/CD с использованием GitLab. Мы рассмотрим жизненный цикл автоматизации «1С:Предприятие» от начала и до конца:
• Использование Docker для обеспечения необходимой изолированности и воспроизводимости сред.
• Настройки и запуск заданий в GitLab CI:
    • для автоматической сборки конфигураций;
    • для тестирования с помощью инструментов YAxUnit и Vanessa Automation;
   • для интеграции с системой статического анализа кода SonarQube в целях поддержания высокого качества кода.
• Методы эффективного обновления конфигураций информационных баз.

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

Как разрабатывать интерфейс на react внутри 1С.
Особенности тонкого клиента и веб-клиента.
Зачем это все нужно.
Как разработать свой первый react интерфейс за 5 минут.

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

По мере роста компании, увеличения числа проектов и клиентской базы, мы столкнулись с рядом вызовов, требующих решения:
• Отсутствовало ясное представление о распределении затрат на инфраструктуру в разрезе различных ЦФО/проектов/R&D.
• Периодически обнаруживались «забытые» сервера, выделенные под определенные задачи, но не отключающиеся после завершения работы.
• Долго разворачивались «типовые» сервера, используемые в контуре разработки, из-за необходимости проведения процессов согласования и формирования задач администраторам.
• UI и возможности разных облачных платформ были различными.
• В разрезе каждого проекта потребовался инструмент для гибкого управления затратами как на аренду сторонних облачных ресурсов, так и поддержку собственных.

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

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

• Ускорение менее, чем на порядок – не считается
• Что мы можем без участия ДБА
• Основные шаги, подходы и принципы
• Древнее легаси – возможна ли оптимизация без полного рефакторинга или костылей?
• Наши показательные кейсы – путь и результат

*да, мы начали ее уменьшать

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

Сервисов очередей достаточно много, мы поговорим про общие их идеи и про одну конкретную, облачную реализацию: YandexMQ.
Как в ней эти идеи реализованы, что хорошего могут предложить облака, что - не могут, и как с этим работать из 1С.

Представим библиотеку с открытым исходным кодом для работы с YandexMQ (и любым другим SQS-сервисом) для 1С:Преприятия. 
После доклада поможем попробовать ее в действии любому желающему, в формате парного программирования или мастер-класса.

Кажется, мы посягнули на "святое", пытаясь восстанавливать последовательность проведения документов
в несколько параллельных потоков, но нет! Если разобраться детально, открывается много интересных возможностей.
Я расскажу про наш опыт: как ничего не сломать и при этом не стоять в одной очереди.

Детально на примере рассмотрим части кода, что от чего зависит, что делать нельзя, а что вполне можно и почему.

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

Компилируем план проведения документов, что в какой поток попадёт.
Доказательный подход: Анализируем и убеждаемся в том, результат проведения каких документов не влияет друг на друга,
и запускаем их в параллельные потоки.

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

Неприятные сюрпризы. Стабильность. С чем мы столкнулись и как ловко обошли проблемы.

Итоги:
в нашем случае удалось сократить время закрытия месяца с 24 часов до 7.
это ускорение на 70%, высвободили 17 часов.
Так, бухгалтера смогли снова запускать проведение на ночь и с утра продолжать работу.

На мастер-классе расскажу о том, как логировать в базе 1С изменения важных данных, связанных с администрированием и разработкой. С помощью этого подхода можно логировать: объекты интеграции в настройках шины данных Datareon, правила обмена, список регламентных заданий, внешние обработки и т.д.

Вместе мы напишем и протестируем скрипт, который можно будет подключить к CI/CD контуру, чтобы логировать изменение чего-либо.

В зависимости от уровня подготовки аудитории, на мастер-классе будет дан начальный ликбез по работе c OneScript. Научу пользоваться отладчиком.

Участникам обязательно иметь ноутбук для работы.

В разработке

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

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

RabbitMQ широко используется в корпоративном контуре 1C в МТС. Потребителями данных из 1С являются более 70 продуктов и систем, а количество типов сущностей превышает 100+. Ключевой фактор успеха – это обеспечение качества и стабильности данных. 

В докладе расскажу: 
• Как и каким образом мы пришли к написанию интеграционных и контрактных тестов.
• Как мы адаптировали библиотеку RMQ для 1С, чтобы начать писать интеграционные и контрактные тесты.
• Что представляют из себя сами тесты, и как мы тюнили VanessaADD, чтобы добиться написания тестов в несколько кликов. 
• Запуск тестирования в Jenkins и демонстрация результатов в AllureTestOps.
• С каким проблемами и вызовами мы столкнулись при реализации данного подхода.
• Какие усовершенствования мы планируем еще, и какие результаты достигнуты.

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

Рассмотрим на примере WhatsApp:
- Библиотечный подход разработки.
- Интеграция с популярными мессенджерами.
- Управление диалогами через web-интерфейс.
- Использование ИИ для создания шаблонов ответов.
- Автоответчик на базе ИИ для нерабочего времени.

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

С определенного момента импортозамещение перестало быть лишь красивым лозунгом, превратившись в неотвратимую реальность.

Переход на Linux порождает ряд вопросов для тех, кто планирует миграцию:
• Какие особенности работы конфигураций 1С под управлением ОС Linux следует учитывать?
• Каким образом проанализировать конфигурацию на предмет платформеннозависимого кода?
• Какие инструменты следует использовать для этого?
• Как организовать процесс рефакторинга?
• Как совместить рефакторинг существующего кода с контролем за новыми доработками?
• Как проверить результаты и убедиться в работоспособности системы на новой платформе?

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

В процессе многих лет написания, приемки, аудита нагрузочных тестов накопил довольно разнообразный и релевантный опыт.
Он основан на тестировании крупных проектов с более 1500 одновременно работающих пользователей.
На моём пути воина света тестирования:
•    1С + MSSQL (1600),
•    1С + Postgres (1500),
•    переход с MSSQL на PostgreSQL,
•    переход между версиями PostgreSQL,
•    внедрениями облаков, SaaS и прочем (не только 1С).
В процессе доклада ответим на вопросы:
•    Всегда хочется сделать максимально полный нагрузочный тест за минимальные затраты (денег / часов). Возможно ли это сделать?
•    Чем можно пренебречь при разработке, а о чем забывать не стоит?
•    Что нужно учесть при разработке нагрузочного тестирования?
•    Как убедить руководство в необходимости нагрузочного тестирования?
Соберем чек-лист, который поможет при первой разработке.
Рассмотрим некоторые ошибки, которые можно сделать, только приступая к разработке нагрузочного теста, а также которые делают уже опытные разработчики.
Немного и подушним, но куда без этого ?
Доклад будет полезен как начинающим падаванам, только вступившим на светлый путь нагрузочного тестирования, так и опытным мастерам в виде обмена опытом.

В разработке.

Актуальность темы взаимодействия разработчика и аналитика сравнима с поиском ответов на загадки Шерлока Холмса и его верного спутника Доктора Ватсона. Как найти идеальный баланс между нежеланием перебивать и замучивать коллег частыми звонками и потребностью решить проблему здесь и сейчас? Этот доклад рассмотрит важные вопросы и проблемы взаимодействия между разработчиком и аналитиком, предлагая практические рекомендации для построения эффективного сотрудничества.
тезисы:
1. Проблемы в общении аналитика и разработчика - две стороны одной медали
2. Правила взаимодействия, которые разработали мы в нашей компании
3. Как построить аналогичные правила, удобные для вас

Администраторы следят за оборудованием, а за 1С никто не следит?
Нет времени на построение сложных систем мониторинга?
Хотите вовремя реагировать на возникающие проблемы?
Хотите использовать только стек 1С?
Нет времени разбираться в хитростях ТЖ?
Нет желания покупать и настраивать Корпоративный Инструментальный Пакет?
У вас уже все есть!
В докладе расскажу, как грамотно упаковать RAS (Remote Administration Server) и сделать простую и эффективную MAS (Monitoring and Alerting Systems).
Покажу особенности, лайфхаки и основные паттерны построения таких систем.

С каждым годом импортозамещение растет, количество пользователей растет, внедряется новый функционал в системы. Следовательно, растет количество вопросов к поддержке. Возникают очереди при обработке обращений пользователей. Необходимо облегчить работу сотрудников, автоматизировать обработку приходящих вопросов. К счастью, в наше время появились большие языковые модели, которые могут взять на себя большой пласт работы.
В докладе будут представлены следующие пункты:
- Результаты опроса аналитиков, разработчиков, консультантов 1С о технической поддержке
- Результаты глубинных интервью с сотрудниками технической поддержки
- Затраты и преимущества ИИ в техподдержке
- Тестирование в реальном времени. Можно будет задать вопрос и посмотреть, что скажет ИИ
- Ожидаемые результаты после внедрения ИИ в техподдержку
- Опыт внедрения ИИ в техническую поддержку
- Пути внедрения ИИ в 1С

Ситуация на рынке: в ИТ кадровый голод, специалистов не хватает. Какой выход? Учиться работать с джунами.
- Кому и зачем нужны джуны
- Как правильно выстроить отбор джунов и не потратить на это много времени. Как найти "того самого", среди сотни откликов от выпускников известных онлайн-школ.
- Как мы отбирали 1 из 100 джунов и что из этого вышло.
- Как научить решать реальные задачи в короткий срок и почему просто "отправить на курсы" недостаточно.
- Что должен знать джун, чтобы можно было подключать к проекту. Минимальный набор.