Предложите надежные альтернативы Контур.Толку, пожалуйста.

Уже второй вебинар фейлится, проблемы не решаются.

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

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

Это критические для меня проблемы.

Я уже прям расстроился, никак не могу найти российский надежный аналог зума, а в условиях, когда много удаленки - это суперважно.

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

Заодно дополню контентом.

Давно в блоге не писал ничего, по следам реальных кейсов.

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

http://agilemindset.ru/независимое-развертывание-в-междуна/

ArchiMate переходит на NEXT: что важно знать

В новой версии спецификации ArchiMate происходит значимый сдвиг в сторону унификации и упрощения метамодели.

Главное — переход от традиционного разделения на “слои” (Business, Application, Technology) к доменам, включая Strategy, Motivation и Implementation and Migration.

Новая модульная структура обеспечивает гибкость, сохраняя ключевые аспекты (Behavior, Active Structure, Passive Structure, Motivation) и позволяет использовать элементы кросс-доменно, без строгой иерархии.

Ранее различавшиеся поведенческие элементы — такие как Business Process, Application Function и Technology Process — теперь объединены в четыре универсальные категории Common Domain: process, function, service и event. Это устраняет избыточность и упрощает моделирование.

Из языка исключены элементы, дублирующие базовые сущности: contract, constraint, gap, representation, implementation event, а также все виды interaction. Их заменяют специализированные формы, такие как requirement, business object, assessment, data object, artifact, material, event.

В целом ArchiMate NEXT делает язык компактнее, чище и лучше приспособленным к автоматизации.

Еще один обзор изменений Archimate Next:
https://habr.com/ru/posts/932602/

Кому интересен Even Storming, я тут снова начал активно писать, уже два поста из серии вышло.

Решил попробовать формат серий постов, чтобы тематики были не такими разрозненными, привнести больше целенаправленности.
Первая серия, которую хочу сделать – «Темные стороны Event Storming»

Дело в том, что иногда складывается ощущение, что про event storming уже все написано и все ошибки давно разобраны, на самом же деле настоящая практика всегда чуть сложнее и чуть глубже, чем кажется из описаний сессий. Я немного порефлексировал и собрал самые сложные и неочевидные истории, встречающиеся регулярно. Некоторым из участников этого канала я их уже рассказывал лично, а кто-то, может быть, узнает свою сессию.

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

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

Сегодня выйдет первый пост на тему «Ложное согласование понятий»

Прекрасный тред
«Lead Architect wants to break our monolith into 47 microservices in 6 months, is this insane?»
https://www.reddit.com/r/softwarearchitecture/comments/1o6re10/lead_architect_wants_to_break_our_monolith_into/

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

http://agilemindset.ru/item-estimation/

А Саше спасибо за ревью статьи 🙂

Всем привет!

Немного о том, как развивалась конференция, – уже можно отследить некоторые тренды на основе всех поданных на конференцию выступлений за все годы 🧐

▪️2019 – год, когда инженеры снова поверили в архитектуру. Тогда всем хотелось строить красиво – микросервисы, доменные модели, API как кирпичики конструктора. В воздухе витала энергия ремесла: делаем хорошо, честно, не потому что «тренд», а потому что так правильно. Было ощущение, что архитектура – это не про власть, а про ответственность за форму (микросервисы же 🙂 ).

▪️2020 стал моментом взросления. Устав от энтузиазма, люди начали понимать, что дисциплина важнее подхода. Говорили про платформы, про то, как разные команды могут работать синхронно, когда система одна, а люди разные. Возникла боль роста – не техническая, а организационная. Архитектура начала становиться зеркалом того, как устроена компания.

▪️В 2021-м на сцене прозвучала новая тема – осознанность архитектора. Все меньше вдохновляющих слайдов про паттерны, все больше разговоров про то, как строить архитектуру не только систем, но и отношений. Люди стали говорить про культуру, доверие, совместное мышление. Про то, что архитектор теперь не «над», но и «рядом».

▪️2022-й принес ощущение, что мир стал облачным, а риски – земными. Архитектура вернулась к инженерии, но уже зрелой. Разговоры про DevSecOps, автоматизацию, платформы звучали не ради моды, а ради устойчивости. Архитекторы начали учиться говорить с безопасностью и бизнесом на одном языке. И это был заметный сдвиг – от контроля к сотрудничеству.

▪️2023-й – время данных и осмысленности. Архитектура перестала быть абстракцией. Мы начали видеть, что у каждого решения есть вес, который отражается в цифрах. Data Mesh, Capability Maps, все это было не про технологии, а про прозрачность. Про умение смотреть на компанию как на живую систему, где архитектура – это нервная система, а не скелет.

▪️2024-й стал годом зрелых архитекторов. Люди вышли за рамки IT. Мир корпоративной архитектуры показал, что можно управлять изменениями не через власть, а через осознанные горизонтальные и вертикальные связи. Появились школы архитекторов, сообщества, события про людей, а не про фреймворки. Архитектура стала более человечной.

▪️И вот 2025-й. Искусственный интеллект не разрушил архитектуру – он ее расширил. Теперь речь идет не только о проектировании систем, а о том, как они учатся вместе с нами. Архитектура стала способом мышления, где AI помогает видеть связи, которые раньше были скрыты. Это уже не каркас и не схема, это среда для развития – и людей, и бизнеса, и идей. При этом идеи корпоративной архитектуры и технические навыки никуда не делись, однако они все больше переплетаются со смежными областями.

Предвосхищаю много кулуарных, противоречивых разговоров о применении AI в проектировании. А там есть что обсудить.

С Уважением,
Сергей Баранов

Интересная статья какая, про влияние вирусного контента на мозги LLM.

https://www.arxiv.org/pdf/2510.13928

Сегодня меня прям убеждали, что ИИ у всех отнимет работу и что сейчас во всем мире сокращают сотни тысяч людей из-за оптимизации через ИИ. Не, в новостях именно так и пишут. И может когда-то так и будет. Но может перед выполнением таких вот KPI имеет смысл приоткрыть занавеску хайпа?) Небольшая подборка косяков ИИ, которые вот прямо сейчас есть. Это не значит, что ИИ - зло, я всеми руками за использование и прогресс, но кажется технология еще не настолько зрелая, чтобы кого-то массово заменить.
————

В рамках исследования в США разрабатывалась нейросеть для оценки риска смертности у больных пневмонией. Целью было определить, каких пациентов можно безопасно лечить амбулаторно, а кого нужно госпитализировать. При обучении модель показала высокую точность на тестовых данных, однако выявилась ошибочная закономерность: алгоритм «решил», что пациенты с бронхиальной астмой имеют пониженный риск смерти при пневмонии.
Ссылка
Ссылка 2

В чем причина? Исторически пациенты с астмой, поступающие с пневмонией, почти всегда направлялись в отделение интенсивной терапии и получали агрессивное лечение и постоянный мониторинг, что резко снижало летальность в их группе. Таким образом, нейронка «увидела» в статистике лишь корреляцию — низкую смертность — и сделала ложный вывод, что сама астма улучшает прогноз, хотя на деле все было наоборот: эти пациенты выживали из‑за своевременной помощи, а не потому, что их состояние было легче.

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

Главная сложность использования искусственного интеллекта в медицине — ошибки и смещения (bias) могут возникать где угодно и зачастую заранее непредсказуемы.

Еще примеры:

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

Компания Workday в США столкнулась с коллективным судебным иском (дело Mobley v. Workday, Inc., 2025 г.) из‑за того, что её ИИ‑система отбора кадров систематически отклоняла пожилых соискателей и людей с инвалидностью. ИИ обучался на исторических данных, где работодатели чаще нанимали более молодых работников, и перенял эту дискриминацию. Суд признал такие алгоритмы потенциальным нарушением Закона о защите от возрастной дискриминации.

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

На крупнейшую медицинскую страховую компанию США UnitedHealthcare подан коллективный иск после расследования Stat News. Алгоритм nH Predict, использовавшийся для принятия решений о выплатах Medicare, систематически завершал реабилитацию пациентов слишком рано и отказывал в продлении покрытия. По данным иска, частота ошибок, приводящих к отказам, достигала 90 %, что лишало людей медицинской помощи и вынуждало оплачивать расходы из личных средств.

Владельцы Apple Card, выпускаемой Goldman Sachs, заметили, что женщины получают значительно меньший кредитный лимит, чем мужчины с аналогичным доходом. Алгоритм скоринга был «слеп» к полу пользователей, но использовал косвенные переменные, коррелирующие с гендером — например, историю покупок и финансовое поведение по совместным счетам. Департамент финансовых услуг Нью‑Йорка начал расследование по факту возможной дискриминации.

В 2025 году в США судью Генри Уингейта обвинили в использовании ИИ‑системы для составления части судебного решения без уведомления сторон процесса.

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

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

Технологии автоматического распознавания лиц, применяемые полицией и судами, также привели к громким нарушениям. В США Роберт Уильямс был ошибочно арестован в Детройте после того, как алгоритм совмещённого поиска воспринял его лицо как совпадающее с фото преступника. Он провёл сутки под арестом, хотя не имел отношения к делу. В России в 2023 году гидролог Александр Цветков провёл 10 месяцев в СИЗО по обвинению в убийствах из‑за совпадения с фотороботом, созданным ИИ‑системой

В Китае и США тестируются системы алгоритмических «рекомендаций наказания». Они анализируют сотни тысяч приговоров и предлагают судьям стандартный диапазон санкций. Однако исследования показывают, что такие модели склонны усиливать уже существующие диспропорции — например, назначать более строгие наказания молодым мужчинам или выходцам из меньшинств, поскольку обучены на исторических данных тех же судов.

И самое вкусное:

По данным Uplevel (2025 г.), количество багов в проектном коде с участием ИИ выросло на 41 % по сравнению с ручной разработкой. Нейросеть может оптимизировать структуру, но не «понимает» бизнес‑логику, что особенно критично в финтех‑ и медтех‑проектах.

Согласно исследованиям MIT и RAND (2025 г.), около 95 % генеративных ИИ‑пилотов в IT‑отрасли не достигают стадии коммерческого внедрения. Причины — нестыковка между задачами бизнеса и техническими возможностями, завышенные ожидания и плохое качество данных.

Согласно исследованию, опубликованному в январе 2025 г. , от 22 % до 48 % примеров кода, созданных популярными моделями (ChatGPT, Copilot, Gemini, JetBrains AI Assistant), содержали реальные уязвимости — от SQL‑инъекций до ошибок обработки строк. Особенно часто ИИ придумывал пакеты и импортировал несуществующие зависимости, создавая атаки через supply‑chain, если эти пакеты подменялись злоумышленниками.

Анализ компании Anaconda выявил, что 60 % ИТ‑директоров оценивают влияние ошибок ИИ‑кодогенерации как «очень серьёзное». В одном случае генеративная модель Terraform от внутреннего ИИ‑бота предложила настройки, удаляющие часть инфраструктуры AWS без резервирования. В результате временно перестали работать клиентские API‑сервисы, а ущерб составил около 200 000 долларов.

Исследование AI‑Generated Code Riss (2024–2025) подтвердило, что мелкие синтаксические дефекты и неверные конфигурации ИИ‑кода часто вызывают каскадные инциденты безопасности. Примеры включают ошибочную обработку ошибок сетевых запросов, что приводило к падению Docker‑контейнеров, и внедрение шаблонов уязвимых API в коммерческие приложения через LLM‑рекомендации.

В 2025 году предприниматель создал веб‑приложение с помощью ChatGPT. Оно работало исправно до тех пор, пока пользователи не стали вводить некорректные данные. Модель не предусмотрела валидацию ввода — в результате возникла ошибка деления на ноль, а позже обнаружили SQL‑инъекцию, позволившую хакеру получить доступ к базе клиентов. Через два месяца компания потеряла базу данных и 80 % пользователей.

Компания Veracode протестировала более 100 моделей (ChatGPT, Gemini, Anthropic Claude и др.) и выявила, что 45 % примеров кода содержали критические уязвимости из OWASP Top‑10. Наиболее часто встречались XSS‑атаки и SQL‑инъекции. Самый высокий уровень небезопасности оказался у Java‑кода — 72 % программ не проходили проверку на безопасность.

В августе 2025 года разработчики отметили, что новая версия ChatGPT‑5 систематически создавала ошибки в HTML‑формах и API‑запросах — в 45 % случаев параметры не совпадали по именам между клиентом и сервером.

Это вызывало неправильную передачу данных и падения фронта. Ошибка получила широкое обсуждение как пример «массового переобучения без понимания контекста».

Аналитика DevOps‑платформы DORA показала, что массовое внедрение GitHub Copilot вызвало падение стабильности релизов на 7,2 %: ИИ часто генерировал «рабочий» код без оптимизации. Пример — автоматическая реализация быстрой сортировки, предложенная Copilot вместо стандартной функции .sort(), вызывала зависания при обработке больших массивов. Для исправления брешей аналогичные фрагменты приходилось переписывать вручную.

Исследование Security Degradation in Iterative AI Code Generation (2025 г.) зафиксировало парадокс: при каждой новой итерации «улучшения кода» через LLM количество уязвимостей возрастало на 37 %. Алгоритм ChatGPT при внесении косметических правок добавлял новые риски, такие как несанкционированное использование пользовательских данных или утечки через логирование ошибок. Эксперимент показал, что «оптимизация» через самообучение без участия человека ухудшает безопасность, а не повышает.

А на десерт на тему архитектуры.

Построение фасадов… стоп, не оттуда. Или оттуда?)

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

В чем проблема?

А в том, что большая часть терминов в IT архитектуре хоть и имеет свое значенине, но сами слова заимствованы…. вроде отвечает про IT архитеткру и по ходу примешивает BIM, CAD…

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

Или вот еще мой пример:

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

Похоже на правду?
Конечно, только оно мне еще ссылку не источник приложило:
https://www.ube.ac.uk/whats-happening/articles/generative-design/

К слову, даже читая источник не сразу догадаешься, что речь не про IT-архитектуру.

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

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

И как вы могли заметить, все примеры тоже сгенерированы ИИ, Perplexity. Они все уверенно складные и не вызывают ни капли сомнений :) Но кто знает сколько там правды.

Нейронки отлично разбираются в том, в чем я не разбираюсь, но ничего не понимают в том, в чем я хорошо понимаю…

Вот прямо сейчас спросил перплексити. И ведь кто-то пойдет задавать вопросы, развивая этот этот ответ, вплоть до реализации. А хорош ли этот ответ?

Какой архитектурные стиль подойдет для реализации небольшого локального интернет-магазина?

Ответ:

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

Почему микросервисы подходят локальному магазину
1. Гибкость и независимость сервисов. Каждый компонент — каталог, корзина, заказы, платежи — работает отдельно. Это позволяет добавлять новые функции без переписывания всего сайта и гарантирует устойчивость при сбоях.
2. Простое масштабирование. Даже если магазин локальный, отдельные сервисы (например, каталог или оплата) можно масштабировать при росте покупателей или расширении ассортимента.
3. Лёгкость поддержки и обновлений. Маленькая команда может обновлять конкретный модуль без остановки магазина. Это особенно удобно, если магазин развивается постепенно.
4. Техническая независимость. При необходимости можно разворачивать микросервисы на недорогих локальных серверах или облачных решениях — Yandex Cloud, Timeweb Cloud и пр..
5.Будущее‑ориентированность. Если магазин вырастет, микросервисная система безболезненно адаптируется к региональному или даже национальному уровню бизнеса.