Стрим по применению ИИ в бизнес-приложениях
27 августа в 19:00 проведем стрим с Иваном Молокотиным по применению ИИ в бизнес-приложениях.
Пока большинство использует ИИ как средство написания программного кода: становятся вайб-кодерами, пишут свои агентские тулзы, какие-то собственные пайплайны, в общем, работают в этом направлении, — есть ребята, которые уже сейчас встраивают ИИ непосредственно в бизнес-процессы компаний.
Иван покажет на примере своего решения, как помогает службам безопасности компаний анализировать контрагентов и отвечать на вопрос: стоит или не стоит работать с этим контрагентом, насколько он надежный или ненадежный.
Иван расскажет какую роль играет ИИ, какую модель он использует и, самое важное, прямо покажет свой пайплайн и то, как все это работает.
На стриме окунемся и в инфраструктурную часть вокруг всего этого, посмотрим на промпты, которые он использует, как он их использует, куда их передает.
Если совсем базово, то у Ивана есть фронтенд и бэкенд на 1С:Элемент, дальше — n8n, через который идет работа с LLM-моделью и внешними API и получение нужного ответа. И все это интегрируется с 1С:ДО
При этом Иван большой профессионал в этой теме. Он уже много шишек набил, уже успел попробовать сделать так, как делать не надо, и на стриме об этом расскажет. И вот в этом я вижу один из самых больших плюсов стрима. Иван не просто теоретик, который расскажет нам, как это могло бы работать или как красиво все это звучит в анонсах нейросетевых компаний.
Он расскажет:
«Да, вот это пробовали, но не сработало. Вот это сделали так и оно сработало. Здесь сначала пошли по одному пути, потом отказались от него. А сейчас работаем вот по такой схеме»
В общем, приходите.
А пока позадавайте свои вопросы: что бы вы хотели узнать у Ивана?
Может быть, как раз подберем от вас какие-нибудь важные и умные мысли и тоже осветим их на стриме.
Насколько сложно устроиться в 1С Разработку, не имея опыта?
Привет товарищи пикабушники! Может кто-то с опытом в сфере 1С рассказать, насколько реально устроится 1С разработчиком не имея опыта в этой сфере. Есть документ об прохождение курсов от компании 1С, и сертификат 1С "Профессионал". Или, по большому счету, в нынешних реалиях на рынке труда, это больше трата времени?
Заканчиваю говорить про архитектуру в 1С
Вчера после стрима сидели с женой и обсуждали одну мысль.
У меня сейчас ощущение, как перед последним звонком.
Несколько месяцев я жил темами: DDD, чистой архитектуры и как все это нормально переложить на 1С. Думал, как отделить теорию от того, что стоит использовать в коммерческой разработке.
Стрим прошел и сейчас немного странно осознавать, что этот этап подходит к концу. Дальше я сильнее уйду в Unity и C# и буду заниматься совсем другими вещами. Возможно, через какое-то время вообще перестану говорить про архитектуру в 1С.
А мысль мы такую обсуждали:
А что, если то, что мы сейчас делаем, — это маленькое семечко, которое даст результат сильно позже?
Не в рамках одного курса и даже не через год.
Через 5–7 лет часть людей, которые смотрят стримы, спорят со мной, пробуют эти подходы в своих проектах, станут тимлидами, архитекторами, руководителями разработки и начнут по-другому строить системы.
Постепенно то, что сегодня для 1С мира выглядит непривычно, станет совершенно нормальным способом разработки.
Вот это для меня сейчас самое ценное во всей этой истории.
Не просто провести курс.
Заложить небольшой фундамент того, как 1С-разработка может выглядеть в будущем.
Спасибо всем, кто был вчера на стриме, задавал вопросы, спорил и обсуждал.
Запись вчерашнего стрима готова
Стрим по реализации DDD и чистой архитектуры в 1С
Ребята и девчата, сегодня в 19:00 проведем второй стрим по реализации DDD и чистой архитектуры в 1С
На этом стриме я, наконец-то, отвечу на вопрос, который мне задавали чаще всего после предыдущих стримов по чистой архитектуре:
а как при таком подходе не потерять платформенную оптимизацию при работе с табличными частями на клиенте?
До недавнего времени не знал на него хорошего ответа. Теперь знаю. И покажу.
👉 Стрим будет посвящен API-first подходу в 1С.
Получим удобные бизнесовые сценарии, которые удобно использовать можно и из форм, и из других потребителей. Форма перестает быть центром приложения.
👉 Обсудим, почему явные бизнес-сценарии лучше, чем попытка вписать всю жизнь системы в коллбеки платформы:
ПередЗаписью, ПриЗаписи, обработку проведения и все остальное.
👉 Вы сами увидите эти сценарии в коде. Они читаются очень просто и понятно.
👉 Посмотрим, как в типовых решениях 1С пытаются прийти примерно к той же идее с помощью флагов и ДополнительныеСвойства.
Еще одна важная тема — как выбирать место физического хранения данных.
С точки зрения бизнес-логики то, лежит у нас состояние в документе или в регистре, — это деталь инфраструктуры.
Но это не значит, что выбор не имеет значения.
Платформа очень много умеет и очень много берет на себя. И если мы правильно выбираем модель хранения, то получаем вполне конкретные преимущества.
На нашем примере я покажу, почему выбрал именно такое хранение и что это дает нам с точки зрения:
— оптимистической блокировки;
— нумерации;
— вообще нормального использования возможностей самой платформы.
Стрим будет гораздо больше про конкретику:
👉 Как интегрироваться с legacy-кодом типовой конфигурации.
👉 Как интегрироваться с платформой 1С.
Мы не будем тащить сюда святую корову чистой архитектуры и DDD и говорить: «Нет, платформа плохая, все надо от нее спрятать».
Наоборот.
Мы будем смотреть, как все это встроить в 1С красиво. Чтобы код хорошо читался. Чтобы его было просто менять. Чтобы мы использовали возможности платформы там, где они нам помогают, но при этом не отдавали платформе управление нашей бизнес-логикой.
Тем, кто будет на стриме онлайн, я отдам две вещи
✅ само решение, которое у меня сейчас получилось.
Решение показывает, как применять DDD и чистую архитектуру в 1С, как интегрироваться с legacy, как интегрироваться с платформой. Сейчас мне этот пример прям очень нравится. Он получился максимально чистым и показательным.
✅ свои правила для AI-агентов, заточенные именно под разработку на 1С, по которым я сейчас сам работаю.
Но это все отдам именно тем, кто будет онлайн.
Так что сегодня, 19:00 МСК. Приходите. Всех очень жду.
P.S.
Ребята и девчата из фирмы 1С, на самом деле эти стримы я во многом делаю именно для вас.
Приходите, пожалуйста.
Потратьте немного времени. Попробуйте понять, о чем я говорю. Позадавайте вопросы. Поспорьте со мной.
Мне кажется, вам это 100% должно понравиться.
Потому что именно за вами наблюдают сотни тысяч других 1С-программистов. Именно на ваш код они смотрят. Именно типовые решения во многом формируют то, как потом пишется код во всем 1С-мире.
И я, конечно, могу ошибаться. Но мне кажется, если начать писать типовые решения примерно в такой технике, всем в 1С-мире станет сильно проще жить.
Поэтому, ребятушки, если есть возможность, найдите время, присоединитесь, посмотрите.
Мне кажется, за этим вполне может быть будущее типовых конфигураций.
Зачем архитектору курс?
С утра созвонился со знакомым Архитектором, который купил курс.
Звонил, чтобы задать один вопрос 👇
«Я давно тебя знаю, ты крутой специалист. Зачем тебе вообще идти на курс?»И он ответил:
«Я архитектор на бумаге. А в чем на самом деле заключается моя работа, я не очень хорошо представляю»Человек работает архитектором в крупном интеграторе, получает хорошую зарплату, решает серьезные задачи.
Но у него нет главного — системы, на которую опираться и с которой сверять собственные решения.
Словарь архитектора должен состоять из таких вопросов:
— как правильно определить границы системы
— как декомпозировать систему на модули
— как разделить ответственности между объектами
— как выстроить зависимости в коде
Это язык настоящего архитектора.
Но в мире 1С многие архитекторы не понимают смысла этих вопросов. Не говоря уже о том, чтобы использовать их в работе.
Мой знакомый знает про слои. Понимает общий посыл: систему нужно разделять, бизнес-логику нельзя размазывать по формам и общим модулям, зависимости нужно контролировать.
Но дальше начинаются вопросы.
🟡 Как прийти к этому разделению в реальной задаче?
🟡 На что именно декомпозировать систему?
🟡 Где должна пройти граница?
🟡 Чем Application отличается от Domain?
🟡 Зачем нужны контроллеры, репозитории и дополнительные слои?
С UI более-менее понятно: интерфейс отделяем от остальной логики. Условно есть UI и есть все остальное.
А дальше понимание заканчивается.
Он пишет код, распределяет его по общим модулям, обработкам и объектам 1С. Код работает. Задача решена.
Но остается вопрос:
«Насколько хорошо все это спроектировано? Я действительно правильно разделил ответственности или просто разложил код так, как мне сейчас показалось логичным?»И главное — с чем сверяться?
🟡 Нет понятных критериев
🟡 Нет системы принятия решений
🟡 Нет уверенности, почему одно архитектурное решение лучше другого
Решению этой проблемы посвящен курс. Задача — не изучить набор слоев, паттернов и схем, а научиться проектировать системы:
🟡 от пользовательского сценария — к границам системы
🟡 от границ — к модулям
🟡 от модулей — к ответственности объектов
🟡 от ответственности — к доменной модели и зависимостям
🟡 а затем встроить все это в типовое решение 1С
Чтобы на вопрос: «Почему система спроектирована именно так?» отвечать не:
«Мне показалось, что так логичнее».
А:
«Потому что вот границы. Вот ответственности. Вот зависимости. И я понимаю, почему они устроены именно так»
Мне кажется, именно с этого момента архитектор перестает быть архитектором на бумаге. Что думаете?



