Обновить
256K+

Управление разработкой *

Планирование, отслеживание и контроль

559,27
Рейтинг
Сначала показывать
Порог рейтинга

ProtoTech Community: ищу 1-2 сеньоров, готовых бесплатно повести команду джунов. Джуниоры - пока в лист ожидания

TLDR: Собираю некоммерческую “виртуальную IT-компанию” - джуниоры получают реальный Git Flow, код-ревью и командный опыт вместо очередного пет-проекта. Ради чего это сеньору - вопрос открытый: я сам не сеньор и с сеньорами идею вживую не обсуждал, ниже мои гипотезы, а не обещания. Если звучит мимо - пишите в комментах, это тоже ценный результат. Джуниоры, оставляйте контакты, наберу команду, когда будет вокруг кого её строить.

Почему это существует

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

Сеньорская сторона - косвенные сигналы, не мой опыт: тысячи опытных разработчиков бесплатно менторят на ADPList и в OSS, значит готовность тратить время безвозмездно реальна. Но это разовые 30-минутные созвоны, а не ведение команды неделями - и это уже непроверенная часть идеи.

Что могло бы быть интересно Ментору (гипотезы)

По убыванию уверенности:

  • Technology Playground. На основной работе не дают Rust/Bun/HTMX? Здесь риска для бизнеса нет.

  • Talent pipeline. Месяцы смотришь людей в реальной работе - кто тащит, кто сливается. Лучших зовёшь к себе (это не HH).

  • Management Practice. Полигон для тимлидских навыков - хотя многие сильные IC осознанно не хотят в менеджмент, так что мотив для меньшинства.

  • Личный бренд. Кейс “я обучил команду и мы сделали X” для блога/резюме.

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

Как это устроено

  • Ритм: асинхронный недельный спринт - пн планирование, ср текстовый чек-ин, сб/вс необязательный часовой войс-синк.

  • Не обсуждается: Git Flow, тикет-трекер (“нет тикета - нет работы”), обязательное код-ревью перед мерджем.

  • Стек и архитектура - целиком на менторе.

  • Деньги внутри не ходят. Ни взносов, ни платного менторства - см. правило #0. Разрешены донаты на инфраструктуру и найм участников друг другом (это успех, а не заработок).

  • Код по умолчанию MIT/Apache 2.0, права - у авторов коммитов.

Текущий статус

Продакшена нет. Есть название, черновик правил и роадмап, нет ни одного ментора. Первый шаг - 1-2 ментора, которые вместе со мной выберут стек и соберут команду под первый проект (Telegram-бот для нужд сообщества, обсуждаемо).

Джуниорам

Пока рано - без ментора нет проекта, без проекта нет тикетов. Но если формат откликается (реальный Git Flow, код-ревью, честная командная разработка вместо курса с сертификатом) - пишите, оставлю в листе ожидания.

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

Как откликнуться

Пишите в личку Хабра.

  • Сеньоры/тимлиды - go.

  • Джуниоры - в лист ожидания.

Готов ответить на вопросы в комментариях.

Теги:
-7
Комментарии7

C-level в кулуарах: о миссии, ошибках и AI — семь топов говорят честно

Что происходит, когда IT-руководители высшего звена собираются не на сцене, а в кулуарах? Правильно — начинается настоящий разговор.

Этот выпуск «Свободного слота» записали прямо на конференции SouthHub в Красной Поляне. Саша Афёнов и Саша Прокшина поговорили с семью топами из крупнейших IT-компаний: Алексеем Молчановым (Cloud.ru), Татьяной Фоминой (HeadHunter), Александром Швецом (Авито), Иваном Самсоновым (MWS), Дмитрием Молочниковым (Альфа-Банк), Сергеем Паращенко (Product Vision) и Кириллом Евсеенко (Звук).

Что обсудили

Зачем CTO и CPO вообще ездят на конференции, если они и так всё знают. Кто такой настоящий C-level — и почему «уникальная снежинка» на высокой должности это проблема. Как превратить личную мечту в рабочую миссию и не спутать её с синдромом отложенной жизни. Как бизнесу не сливать бюджеты на LLM — и почему разговор об AI всё равно случился, хотя никто не планировал.


Слушайте и смотрите новый выпуск на площадках:

📺 YouTube
🔵 ВК Видео
📌 RuTube
🎧 Яндекс Музыка
Ⓜ️ Mave

Ещё больше новостей — в нашем телеграм-канале

«Свободный слот» — терапевтичный контент для тимлидов и тех, кто хочет ими стать

Теги:
+2
Комментарии0

Представлен открытый проект Ghostprovider — терминальный инструмент для быстрого запуска GitHub‑проектов у себя на localhost.

Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет Dockerfile, docker‑compose, package.json, requirements.txt, Go/Rust/Python/Node‑признаки, определяет тип приложения и пытается развернуть его в Docker. После запуска показывает локальный URL, контейнеры, логи и дает управлять сервисами прямо из TUI: старт, стоп, рестарт, удаление. По сути это автоматизированная оболочка над git clone, docker build, docker run и docker compose up, только с автоанализом проекта и удобным интерфейсом в терминале.

Важно: инструмент реально запускает код из чужих репозиториев, поэтому случайные проекты лучше гонять в VM/песочнице и внимательно смотреть Dockerfile/docker‑compose перед запуском. Сам Ghostprovider выглядит прозрачным, но риск всегда в том, что именно вы через него запускаете.

Теги:
+3
Комментарии0

Автоматизировать, нельзя делать вручную

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

Константин, специалист по ИИ в Naumen, рассказал, какие задачи стоит автоматизировать в первую очередь и по каким признакам понять, что процесс действительно подходит для ИИ.

Проверьте процесс по трем критериям

Перед тем как автоматизировать любую задачу, ответьте на три вопроса.

  1. Боль. Насколько процесс раздражает, отнимает время или приводит к ошибкам?

  2. Частота. Как часто вы его выполняете: каждый день, каждую неделю или раз в месяц?

  3. Стоимость автоматизации. Есть ли понятные правила, по которым выполняется задача, или каждый делает ее по-своему?

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

В первую очередь автоматизируйте работу с информацией

Практически любая задача, связанная с обработкой информации, — хороший кандидат для автоматизации.

Например:

  • Парсинг сайтов конкурентов, изучение технической документации, сбор данных из отчетов — в 90% случаев это можно доверить ИИ. Человек подключается только для валидации результата: проверить, не упущено ли что‑то важное, адекватен ли вывод.

  • Изучение документации — нет смысла читать 50 страниц документации вручную, когда ассистент справляется за минуту и выдает выжимку.

  • Любая работа с форматированием данных — привести таблицу к единому виду, объединить информацию из нескольких документов, удалить дубли или преобразовать данные в нужный формат.

Следующий шаг — база знаний команды

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

Если собрать материалы по конкретным рабочим сценариям в единую базу знаний, можно создать ассистента, который:

  • отвечает на вопросы;

  • находит нужные фрагменты;

  • помогает новым сотрудникам быстрее разобраться в теме;

  • снижает количество однотипных вопросов внутри команды.

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

Например, вместо поиска по нескольким чатам можно просто спросить ассистента: «Как у нас проходит релиз продукта?» или «Какие требования сейчас действуют для этой интеграции?».

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

Например, менеджер по продажам может попросить: «Объясни простыми словами, как работает эта функция, чтобы я мог рассказать о ней заказчику без технических терминов».

Создать такого ассистента сегодня можно несколькими способами

  • Для команды

Мы, например, создали платформу на базе Open WebUI. Любой сотрудник может создать ассистента, загрузить в него документы и открыть доступ коллегам. Ассистент помогает быстро находить информацию по вебинарам и рабочим материалам.

  • Для общей базы знаний

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

  • Для личной работы

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

Главное — не пытаться автоматизировать все сразу. Найдите процесс, который часто повторяется, действительно мешает работать и выполняется по понятным правилам. Именно он обычно дает самый заметный результат.

Теги:
+3
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №29 из 30 — Системы с конструктивной информационной безопасностью (ГОСТ Р 72118—2025)

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Системы с конструктивной информационной безопасностью". На YouTube. Слайды.

С помощью приглашённого эксперта Екатерины Рудиной, аналитиком департамента перспективных технологий "Лаборатории Касперского", мы разобрались, в чём сходство и различие таких систем с безопасным ПО, как соотносятся создание систем с КИБ и разработка безопасного ПО, чем полезен в работе специалистов по ИБ новый ГОСТ Р 72118—2025 "Защита информации. Системы с конструктивной информационной безопасностью. Методология разработки".

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Теги:
+4
Комментарии0
Свежие задачи на Бирже заказов Инфостарта для 1С-специалистов
Свежие задачи на Бирже заказов Инфостарта для 1С-специалистов

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

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

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

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

На площадке доступны:

  • 0% комиссии — расчеты напрямую с подрядчиком;

  • исполнители разного масштаба — от одного разработчика до ИТ-команды;

  • прямой обмен контактами;

  • безопасная сделка по желанию;

  • рейтинги, кейсы и прозрачность откликов.

Теги:
+9
Комментарии0

Два Claude Desktop на одном Mac в одну кнопку

Sergey Gordeychik

Обычно я пишу всякое сложное — про кибербез, кризис воспроизводства профессий и прочий АйАй-ужас. Сегодня коротко и практично: как удобно работать с двумя Claude на одном macOS — под разными аккаунтами, одновременно, чтобы личное и рабочее не смешивалось.

Проблема

Claude Desktop хранит сессию в одном фиксированном профиле (~/Library/Application Support/Claude). Второе окно — тот же аккаунт. Даже open -n не помогает: профиль общий. А держать личный и рабочий аккаунт хочется рядом, не разлогиниваясь по десять раз в день.

Идея

Оказывается, приложение умеет запускаться с другим профилем — но не через флаг командной строки, а через переменную окружения. В коде main-процесса (Electron) буквально:

if (process.env.CLAUDE_USER_DATA_DIR) {
  app.setPath("userData", process.env.CLAUDE_USER_DATA_DIR)
}

Значит, можно обернуть тот же самый подписанный бинарник в маленький .app-лаунчер, который выставляет CLAUDE_USER_DATA_DIR в отдельную папку. Никакой второй закачки и копии на 400 МБ — просто другой профиль. Блокировка «один экземпляр» у Claude привязана к профилю, поэтому два разных профиля — это два полноценных инстанса рядом.

Две засады

1. Ловушка Rosetta. Бинарник универсальный (x86_64 + arm64). При «наивном» запуске второй экземпляр стартовал под Rosetta как транслируемый x86_64 — и Chromium начинал жечь ядро под 100%, всё дико тормозило.

sample "Claude Work" 1 | grep 'Code Type'
# Code Type: X86-64 (translated)   ← вот она, беда

Лечится форсом arm64 в лаунчере (exec /usr/bin/arch -arm64 …) плюс LSArchitecturePriority/LSRequiresNativeExecution в Info.plist. После этого — Code Type: ARM64, CPU в норме.

2. Сессии Claude Code. Транскрипты лежат глобально в ~/.claude/projects и общие для всех. Но десктоп ведёт свой индекс сессий по каждому профилю и аккаунту (claude-code-sessions/<account>/<org>/…). Новый профиль этот индекс не видит — список пустой, хотя транскрипты на месте. Достаточно скопировать папку нужного аккаунта — и сессии возвращаются.

Как поставить

Я собрал это в маленький репозиторий claude-clone с деплоем в одну команду:

git clone https://github.com/<you>/claude-clone && cd claude-clone
chmod +x install.sh sync-sessions.sh
./install.sh -n "Claude Work" -b W --copy-settings --copy-sessions

Скрипт создаёт .app-обёртку, изолированный профиль и отдельную иконку (перекрашенный фон + буква-бейдж в углу), чтобы два Claude не путались в Доке. Флаг --copy-sessions подтянет существующие сессии Claude Code (а если их нет — просто начнёт с чистого листа). Дальше — запускаешь «Claude Work», логинишься вторым аккаунтом, и всё.

Что осознанно не копируется: токены логина, куки, локальное хранилище — весь смысл в другом аккаунте. Системный прокси, если он у вас есть, оба инстанса подхватывают сами (Chromium читает системные настройки).

Итог

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

Репозиторий со скриптами: https://github.com/scadastrangelove/claude-clone

P.S. Это неофициальный трюк на основе поведения приложения (переменная окружения CLAUDE_USER_DATA_DIR) — в будущих версиях может измениться. На момент написания работает на Apple Silicon, Claude Desktop 1.17.x.

Теги:
+6
Комментарии2

🤖 🤖 🤖 К счастью или сожалению, ИИ-инструменты стали нормой в сфере разработки софта. И если раньше ещё был некоторый скепсис, что «стрельнет» эта штука или нет, то теперь очевидно — либо вы освоите ИИ-инструменты, либо вы пойдёте на мороз.

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

И тут у нас есть три пути:

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

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

 3) Идеологом третьего подхода является Мэтт Покок (Matt Pocock), который предлагает технику разработки, основанную на скилах, которые сначала опрашивают тебя обо всех нюансах проекта, потом готовят документ, содержащий доменное знание. После этого разбивает задачу на маленькие таски и выполняет их, основываясь на доменное знание. Т.е. что-то из мира TDD, DDD и прочих техник.

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

Cобственно, на этой неделе разбирал, как он предполагает работать, знакомился с его репозиторием скилов и дальше буду пробовать — https://github.com/mattpocock/skills

Теги:
+1
Комментарии0

Claude и Codex научились проходить модерацию App Store вместо разработчиков — инструмент greenlight сам находит причины будущего отказа и тут же их исправляет. Htitybt проверяет приложение по требованиям Apple, автоматически устраняет найденные ошибки и повторяет проверки до тех пор, пока шанс получить отказ не станет минимальным.

Теги:
+3
Комментарии0

Представлен открытый проект OmniRoute — The Free AI Gateway. Это провайдер OmniRoute, который обеспечивает 160+ бесплатными нейросетями:

  • выдаёт токены, подключает один эндпоинт для всех API и самостоятельно отправляет нужные запросы: агрегация бесплатных токенов, что позволяет получить до 1,6 млрд бесплатных токенов в месяц (а в первый месяц с учётом бонусов — до 2,1 млрд). Для старта не требуется банковская карта, а 11 нейросетей (например, Kiro, Qoder, Pollinations, LongCat) остаются бесплатными навсегда;

  • объединяет API от разных ИИ в один;

  • переключает модели сам, когда кончились токены;

  • сам сжимает контекст до 95%, чтобы сэкономить;

  • платформа поддерживает популярные модели, такие как GLM, Grok, Mistral, DeepSeek, Qwen и другие. Также доступны скиллы и MCP (Multi-Channel Protocol), а всего реализовано 17 стратегий маршрутизации (от приоритетной и взвешенной до оптимизированной по стоимости и контексту);

  • поддерживает скиллы и MCP.

Теги:
+4
Комментарии2

Представлен открытый проект Council of High Intelligence. Это локальный совет ИИ‑мудрецов, который поможет принять любое решение и найти идеальный исход событий:

  • в проекте заявлены 18 ИИ‑мудрецов: Марк Аврелий, Аристотель, Сократ, Сунь‑Цзы, Лао‑Цзы, Ричард Фейнман и Линус Торвальдс и другие;

  • ИИ-мудрецы максимально продумывают каждый шаг, спорят друг с другом в парах и выдают идеальное решение вопроса;

  • одни мудрецы находят риски, вторые — давят на практичность, третьи — высказывают сомнения;

  • устанавливается и запускается одной командой в Claude Code или Codex.

Теги:
+4
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №28 из 30 — Безопасность frontend-приложений: особенности, угрозы и анализаторы класса FAST

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Безопасность frontend-приложений: особенности, угрозы и анализаторы класса FAST (Frontend Application Security Testing)". На YouTube. Слайды.

Frontend-приложения (личные кабинеты, онлайн-банки, маркетплейсы, сайты, лендинги и т. д.) выполняются в браузере пользователя — традиционной "слепой" зоне для безопасности. В вебинаре рассмотрены актуальные угрозы, крупнейшие инциденты, построение модели угроз и то, как применение анализатора класса FAST (Frontend Application Security Testing) снижает риски и делает frontend-приложения безопасными. Объясняется, почему классические анализаторы имеют низкую достоверность для frontend-приложений, и как использовать FAST-анализатор в процессах РБПО по ГОСТ Р 56939—2024.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Теги:
+2
Комментарии0

Почти 10 лет в Авито — это не просто стаж. Это возможность наблюдать, как компания меняется изнутри, и самому влиять на эти изменения.

В этом выпуске «AviTalk» ведущий Виктор Раев, руководитель разработки юнита Services Base, поговорил с Александром Лукьянченко — техническим руководителем кластера Architecture. Саша прошёл путь от разработчика до менеджера высшего звена и видел Авито ещё в 2016-м — когда всё было устроено совсем иначе.

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

Смотреть выпуск:

🔵 VK Видео
📺 YouTube

AviTalk — шоу толковых людей. Гости — сотрудники Авито из разных дирекций и команд, которые делятся своей экспертизой и профессиональным путём.

Теги:
+13
Комментарии0

Ближайшие события

Про персональных агентов и что он умеет у меня

Дальше разговор пойдет про OpenClaw/Hermes подобные системы. Т.е это переход от агентных систем по типу Claude Code/Codex к проактивным персональным агентам

В моей классификации это переход с уровня 8 на уровень 9

Коротко о том, в чем разница уровня 8 и уровня 9

Уровень 8 — например Claude Code / Codex / Cursor и тому подобные.
За качество отвечают — Моделька + Harness + еще по мелочи

Уровень 9 — например Hermes / OpenClaw.
За качество отвечают — Все то же самое, что и на уровне 8 + слой личной памяти + мессенджер + коннекторы в ваши сервисы + персональные skills

У меня у самого подобный агент уже был 3 месяца и крутился на OpenClaw. Но для написания статьи решил еще и Hermes попробовать

Кстати спойлер — разницы между Hermes и OpenClaw практически нет. Просто Hermes лишен кучи функций, что можно счесть как за плюс, так и за минус. Но зато у него есть Self Healing механизм, которого нет у OpenClaw

------------------

Ниже про наполнение моего агента и что он умеет
А именно на это и уходит основное время при создании персонального агента

Личные системы
- finances — ведёт мои финансы в Notion: расходы, доходы и отчёты
- ticktick — управление моим тасктрекером TickTick: списки на день, создание задач и подзадач, ну и все такое
- google-calendar — полный контроль гугл календаря, где я ставлю совместные события и расписания с учениками
- weekly-summary — собирает недельный обзор из задач, календаря, финансов, почты, аналитики и SEO по сайту + истории сессий, чтобы я посмотрел на прошедшую неделю целиком

Мое обучение
- google-forms — читает анкеты и ответы участников
- notion — ведет базу по моим ученикам
- ga4 — аналитика моих сайтов в гугл аналитике
- seo-monitor — SEO/GEO мониторинг сайта ilia-pro-ai.com.
- youtube — навык по работе с YouTube, упаковка каждого нового видоса и сбор данных


Работа с документами
- google-sheets — работает с таблицами: ученики, оплаты, анкеты, аудиты.
- google-docx — создает классные контракты/договора


Соцсети
- linkedin — читает мой LinkedIn-профиль, посты и engagement.
- threads — работает с черновиками / публикациями /метриками в Threads
- threads-writer — пишет драфты постов для Threads из идей, ссылок, статей.


Жизневое
- concert-monitor — мониторит концерты в Bangkok/Thailand по моим артистам.
- local-entertainment-research — еженедельный мониторинг кино, события и евентов на неделю
- shopping-product-research — экспериментальный набор скиллов по работе агента с маркетплейсами, пока в процессе
- online-ordering-automation — экспериментальный набор скиллов по заказу еды/продуктов
- outreach-deeplinks — делает кликабельные ссылки для WhatsApp/LINE/tel с готовым текстом

B2B / ресёрч
- b2b-outreach-research — ищет компании, ЛПР, каналы связи и углы для outreach в LinkenIn
- apify — навык работы с Apify для скрейпинга любого сайта


Сегодня еще наконец-таки подрубил Telegram к нему и запустил его туда как пользователя — теперь мой агент может еще и так

1. Смотреть список всех моих диалогов

2. Читать историю конкретного чата. Например:

Расскажи, что за последние 2 дня ученики написали в чатике AI Advanced Alumni

3. Искать по Telegram-истории. Например:

Поищи я там где то мес назад скидывал контракт для Hochland, но не могу чатик найти

5. Смотреть каналы как пользователь и делать по ним дейли саммари

6. Скачать любые медиа из чатов
Файлы, голосовые, фото, видео — если нужно обработать/распознать/суммаризировать

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


———————

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

Теги:
+5
Комментарии5

Как перестать вручную поддерживать экран настроек

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

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

Илья, iOS‑разработчик в Naumen, рассказывает, как пришел к подходу, при котором разработчику достаточно описать новое свойство, а интерфейс собирается автоматически.

Почему задача оказалась сложнее?

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

Но довольно быстро возник другой вопрос: как проверять изменения без постоянной пересборки приложения?

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

Почему обычный экран настроек не решил проблему?

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

Чтобы добавить новую настройку, нужно было каждый раз:

  • добавлять свойство;

  • добавлять соответствующий UI‑компонент;

  • настраивать обработку;

  • связывать с хранилищем данных.

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

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

Как сделать так, чтобы экран собирался автоматически?

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

Дальше система анализирует структуру объекта, определяет типы данных и автоматически подбирает нужные UI‑компоненты:

  • для булевых значений — переключатели;

  • для текста — поля ввода;

  • для чисел — поля с ограничением на числовой ввод.

Что изменилось после внедрения такого подхода?

Теперь для добавления новой настройки достаточно описать новое свойство и добавить необходимые метаданные. После этого настройка автоматически появляется в интерфейсе.

По моей оценке, трудозатраты на работу с настройками сократились примерно на 80–90%. Кроме того, уменьшилось количество дублирующего кода, а интерфейс стал более единообразным и предсказуемым для пользователей.

→ Подробнее своим опытом Илья поделился в статье.

Теги:
+5
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №27 из 30 — PVS-Studio Atlas — новая платформа контроля качества кода

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "PVS-Studio Atlas — новая платформа контроля качества кода". На YouTube. Слайды.

В ходе бонусного вебинара команда PVS-Studio представила новый продукт — PVS-Studio Atlas, предназначенный для работы с результатами анализа кода: просмотра, аналитики, разметки и формирования отчётов для сертификационных лабораторий и ФСТЭК.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

PVS-Studio — статический анализатор кода для поиска критических и типовых ошибок

Также приглашаю всех познакомиться с нашим статическим анализатором PVS-Studio, который может закрыть не только 10-й процесс ГОСТ Р 56939, но и будет полезен по другим направлениям:

  1. Обучение сотрудников (п.5.2). Формирование у программистов понимание антипаттернов и уязвимых конструкций, что улучшает их техническую экспертизу;

  2. Моделирование угроз и разработка описания поверхности атаки (п.5.7). Дополняет процесс, выявляя потенциальные уязвимости, которые формируют поверхность атаки;

  3. Экспертиза исходного кода (п.5.9). Позволяет усилить проверку стороннего кода, который команда включает в проект. Например, его можно использовать для выбора сторонних библиотек, оценивая качество их кода;

  4. Поиск уязвимостей в программном обеспечении при эксплуатации (п.5.24). Можно просматривать ранее отключённые предупреждения PVS-Studio с целью дополнительного выявления дефектов в коде.

Скачать PVS-Studio.

Основные характеристики:

Теги:
+11
Комментарии0

Биржа работает: новые заказы недели с 17 по 24 июня

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

Посмотрите список - возможно, среди этих заказов есть проект под ваш опыт:

Биржа заказов: найдется исполнитель под любую задачу

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

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

Теги:
+8
Комментарии0

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

Теги:
+6
Комментарии0

Новая лабораторная уже в субботу 27 июня! 👩‍🔬 Учимся проектировать API 🛠

Подробнее: https://debugskills.ru/content?article=labs/openapi-rest

Получить доступ: https://boosty.to/polnyistek

Теги:
+3
Комментарии0

ГОСТ Р 56939-2024 на практике: что мы сделали, чтобы получить сертификат РБПО

🔎 Контекст
У Cloud.ru есть платформа, созданная специально для заказчиков, которые обязаны соблюдать особые требования к хранению данных и разработке ПО. Вся инфраструктура, которую они используют, должна быть аттестована на соответствие стандартам безопасности, а платформенные сервисы должны пройти жесткую проверку у регуляторов. Ранее платформа уже получала сертификат ФСТЭК России №4979, но при внесении определенной массы изменений в продукт, процесс требуется пройти заново, а сделать это невозможно без привлечения сторонней лаборатории и многомесячных ожиданий. Чтобы иметь возможность развивать продукт более оперативно, требовалось сертифицировать не только платформу для создания частного, гибридного или распределенного облака Cloud.ru Evolution Stack, но и все процессы вокруг нее, т.е. подтвердить соответствие ГОСТу Р 56939-2024.

🚀 Задача
Стандарт требует выстроить 25 взаимосвязанных регламентов и поддерживать более 200 артефактов в актуальном состоянии постоянно. Но этого мало: ведь стандарт есть, но конкретной методологии его реализации не существует, нужно было приземлить элементы процесса на орг.структуру нашей компании. Осложнялось всё тем, что в любой крупной ИТ-компании команды непрерывно перетасовываются, ответственные меняются, а любое кадровое изменение должно быть тут же отражено во всей документации сразу.

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

☁️ Что мы сделали
Применили существующую в компании BPM-систему как единый источник правды: описали в ней ключевые процессы РБПО, зафиксировали роли, связали их с командами через орг.структуру, разместили все артефакты, точки контроля и указали их взаимосвязи. Следующим этапом автоматизировали конвертацию и публикацию свежих документов: по расписанию из BPM-модели экспортируется HTML, который автоматически конвертируется в Markdown и публикуется во внутреннюю Wiki. Изменился владелец роли — один раз вносишь правки в BPM, все документы актуализируются и тут же становятся доступны всем и каждому. Чтобы новички не впадали в ступор от количества регламентов, поверх Wiki добавили ассистента с RAG под капотом. Можно написать в корпоративный чат любой вопрос и получить структурированную информацию о том, кто за что отвечает и как действовать в любой ситуации, причем сразу со ссылками на конкретный документ в базе знаний. 

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

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

🧠 Рефлексия
Можем смело рекомендовать аналогичный пайплайн командам, которые: 

  • сами готовятся к сертификации процессов РБПО;

  • хотят упростить адаптацию сотрудников на новых ролях; 

  • хотят убрать «слепые зоны» из разработки;

  • ищут способ более предметно демонстрировать работу руководству или инвесторам. 

Теги:
+5
Комментарии1

Что с хабром ?
Написал пост о том что выложил в opensource простенький ssh клиент и получил кучу дизлайков.

За что ? Я ничего не продаю, это ssh клиент которым я сам пользуюсь, пользуются еще несколько людей, через него удобно работать с туннелями и смотреть какой из сервисов отвалился

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

Как тогда делиться своими наработками, проектами, получать по ним обратную связь, если вокруг сколько негатива!
Если интересен проект, вот он на Github вот еще одно opensource приложение для транскрибации которое я развиваю

Я хочу обратную связь от сообщества, в правильном ли я направлении иду
Всем ПИС!

Теги:
+12
Комментарии5

РБПО по ГОСТ Р 56939—2024: вебинар №25 из 30 — Обеспечение безопасности при выводе программного обеспечения из эксплуатации

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.25. – "Обеспечение безопасности при выводе программного обеспечения из эксплуатации". На YouTube. Слайды. Это последний вебинар про процессы стандарта. Следующие пять будут бонусными.

Цели 25-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Теги:
+3
Комментарии0

Где заканчивается vibe и начинается инженерия

ИИ уже в ежедневной разработке. Cursor, Claude Code, Copilot и другие инструменты помогают писать код, собирать прототипы, проверять гипотезы и быстрее двигаться от идеи к работающему решению. Правда, для этого нужно перенастроить инженерный процесс и ответить на важные вопросы.

❓ Кто отвечает за качество сгенерированного кода?
🧪 Как проверять, который написал не только человек?
🚀 Как ускорение разработки меняет внутренние процессы?

Что делать с безопасностью, если, по данным Veracode, 45% проверенных образцов AI-generated code не прошли security-тесты и получили уязвимости из OWASP Top 10?

25 июня в Сфере X5 в Парке Горького проведём первый митап серии AI & ML Talks. Он будет посвящён теме «Vibe Coding: новая разработка или новый техдолг?»

Со спикерами из Альфа-Банка, X5 Tech и X5 Digital обсудим, что уже происходит в командах: где заканчивается «vibe» и начинается инженерия, какие ИИ-инструменты реально помогают разработчикам, а что пока остаётся демкой. Отдельно поговорим о качестве, безопасности, ревью и о том, насколько большие компании готовы пускать ИИ-код в продакшен.

🎤 В программе три доклада, Hot Battle на спорный тезис с голосованием зала и нетворкинг под открытым небом.

👥 Митап будет полезен разработчикам любого стека, тимлидам, AI-early adopters и всем, кто уже использует ИИ-инструменты в работе или только разбирается, как встроить их в свой процесс.

🗓 Встречаемся 25 июня в 18:30 на площадке «Сфера X5» в Парке Горького.

🔗 Регистрация

Первый митап серии AI & ML Talks посвящённый теме «Vibe Coding: новая разработка или новый техдолг?»
Первый митап серии AI & ML Talks посвящённый теме «Vibe Coding: новая разработка или новый техдолг?»
Теги:
+4
Комментарии0

Подборка вебинаров на июнь 

В июне вас ждут еще три онлайн-встречи с экспертами Cloud.ru — о Spark, облачных расходах и Redis. Регистрируйтесь заранее, чтобы ничего не пропустить.

🎥Spark Connect для ИТ-команд: упрощаем разработку и работу с данными

Покажем, как сделать использование Apache Spark удобным для всей команды с помощью Spark Connect и Evolution Managed Spark. Затронем вопросы разработки в IDE, анализа данных в Jupyter и построения ETL на чистом SQL в dbt. Не бойтесь споткнуться о порог входа — здесь он минимальный. 

🧑‍💻 Для кого: дата-инженеры, аналитики, руководители дата-отделов.

📅 Когда? 23 июня 11:00 мск.

📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

🎥Как управлять расходами в облаке и не удивляться счетам

Разберем, как сделать облачные расходы прозрачными с помощью FinOps-инструментов. Вы узнаете, почему важно назначать владельцев ресурсов, как правильно выбирать тариф, выставлять автоматические квоты и настраивать алерты, чтобы сократить затраты на 20–30%. Всё — с живым демо в личном кабинете.

🧑‍💻 Для кого: ИТ-менеджеры, DevOps, финансовые директора.

📅 Когда? 25 июня 11:00 мск.

📍 Где?  Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

🎥Эволюция приложения в облаке: как настроить кеш с Redis и ничего не сломать

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

🧑‍💻 Для кого: бэкенд-разработчики, DevOps-инженеры, архитекторы.

📅 Когда? 30 июня 11:00 мск.

📍 Где?  Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.


Теги:
+4
Комментарии0
Биржа работает: новые заказы недели
Биржа работает: новые заказы недели

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

На этой неделе заказчикам нужны 1С-разработчики для работы со старыми и новыми конфигурациями: интеграций с онлайн-кассами по ФЗ-54, интернет-магазинами, Telegram-ботами и ФГИС «Зерно», переноса данных из 1С 7.7 в 1С 8, настройки обменов, выгрузок в XML, доработки УТ 11.5, УНФ 3.0 и нестандартного производственного учета.

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

На Бирже доступны:

  • прямой обмен контактами между заказчиком и исполнителем;

  • работа без комиссии площадки;

  • возможность безопасной сделки;

  • рейтинги, кейсы и история откликов;

  • исполнители разного масштаба — от частных специалистов до ИТ-команд.

Посмотреть свежие задачи и откликнуться можно на Бирже заказов Инфостарта.

Теги:
+6
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №24 из 30 — Поиск уязвимостей в программном обеспечении при эксплуатации

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.24. – "Поиск уязвимостей в программном обеспечении при эксплуатации". На YouTube. Слайды.

Цели 24-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Теги:
+3
Комментарии0

1С в 2026 году: разработка, архитектура и работа с требованиями

Современному специалисту по 1С уже недостаточно знать язык запросов, СКД и механизмы платформы. В проектах приходится разбираться в архитектуре информационных систем, моделировать бизнес-процессы, общаться с заказчиками и подключать ИИ к разработке и документации.

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

Разработка и инструменты 1С

  • 18 июня, 20:00. «Эффективная 1С-разработка с ИИ в 2026: от SDD к MCP-инфраструктуре». Записаться
    Поговорим о применении ИИ на разных этапах разработки: от подготовки спецификаций до создания инфраструктуры для AI-инструментов.

Анализ требований и бизнес-процессов

  • 17 июня, 20:00. «Заказчик vs Стейкхолдер: как вовлечь бизнес в проект». Записаться
    Объясним, как выявлять интересы участников проекта, согласовывать требования и вовлекать представителей бизнеса в разработку решения.

  • 24 июня, 20:00. «Внедрение новой функции системным аналитиком на примере услуги на Госуслугах». Записаться
    Покажем путь от бизнес-задачи и сбора требований до проектирования новой функциональности.

  • 8 июля, 20:00. «Как писать PRD, ТЗ и user stories с помощью ИИ — быстро, структурно и без мусора». Записаться
    Расскажем, как использовать ИИ при подготовке требований и проектной документации.

Архитектура 1С-решений

  • 17 июня, 20:00. «Архитектура информационных систем. Монолиты, SOA и микросервисы». Записаться
    Поговорим об основных архитектурных подходах и месте отдельных приложений в корпоративном ИТ-ландшафте. Это поможет лучше понимать интеграцию 1С с другими системами.

  • 29 июня, 20:00. «Использование ИИ архитектором 1С: как ускорить анализ требований и подготовку документации». Записаться
    Покажем, как применять ИИ при анализе требований, проектировании решений и оформлении документации.

  • 8 июля, 20:00. «Новшества языка ArchiMate 4.0». Записаться
    Расскажем, как описывать взаимосвязи между бизнес-процессами, приложениями, данными и элементами корпоративной архитектуры.

Данные и автоматизация бизнес-функций

  • 17 июня, 20:00. «Как убрать “человеческий фактор” из финансовых моделей: от расчёта NPV до сложных систем оплаты труда». Записаться
    Объясним, как автоматизировать расчёты и снизить количество ошибок в финансовых и управленческих моделях.

  • 9 июля, 20:00. «HR на языке цифр: от кадров к стратегии». Записаться
    Поговорим о кадровой аналитике и работе с HR-данными.

Что почитать по теме:

Больше бесплатных уроков в IT смотрите в дайджесте.

Теги:
+1
Комментарии0

Я* говорил вам, что ИИ — это инструмент, а не стратегия, а вы переименовывали стартапы в "Что-то-там AI". Теперь у нас сотни питчдеков тысячи мудбордов и ни одного бизнес‑плана, не выплюнутого из той же LLM, вокруг которой типа «строится бизнес».

Я говорил вам, что нужно делать полезный продукт, а вы прикручивали к нему чаты. Теперь у нас вместо полезного продукта — никому не нужная хрень, но с чат‑ботом.

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

Я говорил вам, что код нужно понимать, а вы продолжали копипастить ответы LLM. Теперь всё вроде работает, но никто не знает как это проверить.

Я говорил вам, что инженеров нужно учить архитектуре, а вы учили их писать промпты. Теперь все умеют правильно попросить нейронку написать микросервис, но никто не знает, нахрена он нужен.

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

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

Я говорил вам, что удалёнка требует специальную рабочую культуру, а вы ставили трекеры активности и считали клики. Теперь у нас всё в графиках продуктивности и ноль доверия.

Я говорил вам, что не нужно заменять джунов чатами, а вы заменяли их агентами. Теперь для джунов нет работы. Джуны прикидываются мидлами, мидлы сениорами, а где взять сениора — х** его знает... Он скорее всего теперь RAG прикручивает.

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

Я говорил вам, что нужно разворачивать свои LLM, а вы оформляли подписку на Claude. Теперь токены стоят больше, чем джун. Джуна у нас нет — он прикидывается миддлом, миддл прикидывается сениором, а сениор занят — он RAG прикручивает.

Я говорил вам, что не нужно отсеивать кандидатов по списку ключевых слов, а вы продолжали искать Senior Kubernetes AI Cloud DevOps Platform Engineer. Теперь вакансии висят по году, а кандидатов «на рынке нет». Откликов тьма, но все "нерелевантные".

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

Я говорил вам, что нельзя делать автоматизацию найма, а вы кликали по кнопке «сгенерировать вакансию». А с обратной стороны «сгенерировать резюме». Теперь у нас миллионы вакансий с миллионами откликов и резюме, но как на собеседовании отличить джуна от сениора - непонятно. У нас ведь сениора нет! Он п****ц как занят — RAG прикручивает.


*Я — собирательный образ

Теги:
+55
Комментарии11

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

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

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

1️⃣ Как ИИ может помочь сформулировать задачу?

У нас в команде есть ассистент Dev Describer. Он помогает формулировать бизнес-требования к задачам разработки.

Например, можно описать задачу своими словами: «Нужно добавить уведомление о просроченной заявке в личный кабинет». 

Ассистент поможет уточнить детали:

  • когда именно показывать уведомление; 

  • для каких пользователей оно должно работать; 

  • какой текст нужен;

  • что считается ожидаемым результатом.

Если нужны дополнительные материалы — схемы, ссылки, скриншоты — мы сразу фиксируем их в задаче вместе с текстом.

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

2️⃣ А как проверить постановку перед передачей в работу?

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

Например: «Ты — исполнитель этой задачи. Тебе важно найти пробелы, которые мешают приступить к работе».

После этого ассистент помогает заметить:

  • где не хватает контекста;

  • что можно понять неоднозначно;

  • каких вводных не хватает;

  • какие вопросы, скорее всего, появятся у команды.

3️⃣ Что это дает в работе?

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

4️⃣ Где такой подход особенно полезен?

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

Теги:
+4
Комментарии0

AviTalk: как инженер становится техническим руководителем юнита

AviTalk — шоу, в котором сотрудники Авито рассказывают о своём профессиональном пути. В этом выпуске — Марк Чайников, Technical Unit Leader в Авито. Ведущий — Виктор Раев, руководитель разработки юнита Services Base.

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

Отдельно затронули не самые очевидные, но важные вещи: как логи и заметки помогают в работе руководителя, почему ops-review — это не формальность, а инструмент управления, и что делать с конфликтами и выгоранием внутри команды.

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

Смотреть выпуск:

🔵 VK Видео
📺 YouTube
📌 Rutube

AviTalk — шоу толковых людей. Гости — сотрудники Авито из разных дирекций и команд, которые делятся своей экспертизой и профессиональным путём.

    Теги:
    +21
    Комментарии0

    РБПО по ГОСТ Р 56939—2024: вебинар №23 из 30 — Реагирование на информацию об уязвимостях

    Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.23. — «Реагирование на информацию об уязвимостях». На YouTube. Слайды.

    Цели 23-го процесса по ГОСТ Р 56939—2024:

    Обеспечение выявления и устранения уязвимостей при эксплуатации ПО.

    Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

    Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

    Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939–2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая «Методика ВУ и НДВ в ПО». См. заметку «Методика выявления уязвимостей и недекларированных возможностей — 2026».

    НЕкурс про РБПО

    Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

    Теги:
    +3
    Комментарии0

    Написал бесплатное приложение для транскрибации — ⚡️ Talkis. Делал для себя как open‑source альтернативу платным сервисам по подписке.

    Что оно умеет:

    • Расшифровывает созвоны (Zoom, Discord, Telegram и др.) в реальном времени прямо на лету.

    • Вытаскивает текст из любых готовых аудио‑ и видеофайлов.

    • Умная диктовка: наговариваете мысли голосом, а приложение причесывает и форматирует текст под нужный стиль.

    Как это работает: модели можно крутить либо полностью локально на вашем железе (вообще бесплатно), либо подключить свои API‑ключи и платить копейки за токены без наценок сервисов.

    Проект открытый. Буду очень благодарен за обратную связь, баг‑репорты и звездочку на GitHub — для развития проекта это сейчас самое важное.

    🤩 GitHub  📥 Скачать

    Теги:
    +11
    Комментарии2

    📕📖🧠 Недавно на глазапопалась новая книга на O'Relly с интригующим названием «Follow the money» (Следуй за деньгами) от Ена Милли. В ней автор раскрывает несколько тем работы IT-компании:

    1. Спонсоры технологий (кто платит деньги за неё) и Юзеры технологии (которые требуют новые фичи и поддержку) — разные люди. И как итог, если ты работаешь только с юзерами, но не своими спонсорами, то технологию ждет провал.

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

    3. Приводится пример, когда отдел продаж получающий деньги от ключевых клиентов, начинает фактически управлять структурой IT‑компании и формировать технические команды под свои нужны (Команды по работе с ключевыми клиентами и команда по работе с малышами — где вторая формируется из менее сильных разработчиков).

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

    — Хазин, Щеглов: «Лестница в небо»

    — Патрик Ленсиони: «Пять пороков команды»

    Так вот, я решил посмотреть, какие же до этого книги писал автор, чтобы понять, именно эта книга такая странная, или он так всегда пишет. И обнаружил, что он до этого писал книги по devops, и он был одним из популярных авторов O'Relly

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

    Теги:
    +6
    Комментарии2

    Руководитель, который не ошибается — и другие мифические существа

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

    В новом выпуске «Свободного слота» — Андрей Колесников, SRE DevOps Lead в Авито и соведущий подкаста «В SREду на кухне». Разбираем топ управленческих косяков — и честно признаёмся в своих.

    Что обсудили

    Можно ли вообще научиться на чужих ошибках — или только на своих? Где грань между взвешенным решением и банальным затягиванием. Как говорить «нет» так, чтобы не прослыть неудобным руководителем. И как признавать ошибки до того, как с ними уже пришли к тебе — а не после.

    Слушайте и смотрите новый выпуск на площадках:

    📺 YouTube
    🔵 ВК Видео
    📌 RuTube
    🎧 Яндекс Музыка
    Ⓜ️ Mave

    Ещё больше новостей — в нашем телеграм-канале

    «Свободный слот» — терапевтичный контент для тимлидов и тех, кто хочет ими стать

    Теги:
    +20
    Комментарии0

    РБПО по ГОСТ Р 56939—2024: вебинар №22 из 30 — Обеспечение поддержки программного обеспечения при эксплуатации пользователями

    Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.22. – "Обеспечение поддержки программного обеспечения при эксплуатации пользователями". На YouTube. Слайды.

    Цели 22-го процесса по ГОСТ Р 56939—2024:

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

    Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

    Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

    Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

    P.S. Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились. 

    Теги:
    +5
    Комментарии0

    В стране копирующих продуктов.

    Как сейчас помню. Прилетает баг. Пользователь-кассир видит закупочную цену. Исправил. Прилетает баг. Пользователь-управляющий видит не закупочную цену, а цену продажи. Фиксить нельзя рефакторить.

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

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

    Ладно, не вышел. Был свидетелем. Как от спринта к спринту задачи не были связаны друг с другом. Сегодня мы делаем турникет, завтра апельсин, потом кузнечика, потому что срочно нужна наковальня, а у нас итерационный продукт! Если останется время, то переведём бабушку с ангуляра на рякт, если нет — дедушку, но закончить до сентября! Что будет через два месяца? Верно, бабка с дедом посреди дороги висят на турнике в шубах на рыбьем меху. А? Поняли? Поняли? Рыбий мех — кузнечный мех! Это аджайл, мамкина норка! Нет времени уточнять, тебе ещё апельсин чистить.

    И вроде бы фантастика, ложь, абсурд! Но одна недоделанная фича сменяет другую и мы из созвона в созвон гоняем запятую по «фиксить нельзя рефакторить», ведём разговоры о техническом долге. Только долг оказывается концептуальным.

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

    Вы помните этого персонажа из Книги Джунглей. Не шибко опасен, не шибко умен, но он повсюду со своими мантрами. Если концепцию продукта можно представить в виде компаса, по которому можно сверяться и потому свободно перемещаться по пути к большой цели, то табаки-менеджмент не имеет такого компаса, он ориентируется на слухи: куда подул ветер, туда и развернут продукт. Это бизнес! Бизнес зовут! Подобное мельтешение ведёт к джунглям из спагетти-кода, что при первом приближении кажется техническим долгом.

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

    Теги:
    +5
    Комментарии0

    Собрали новую подборку заказов с Биржи Инфостарта. В этот раз в списке — задачи, которые появились с 4 по 9 июня: отчеты, обновления, интеграции, синхронизация, аналитика и проектная работа по 1С.

    Есть как небольшие разовые задачи, так и заказы, где нужно глубже погрузиться в проект. На этой неделе заказчики ищут аналитиков, разработчиков и консультантов 1С. Встречаются задачи по ERP, БП, УНФ, УТ, «Управлению холдингом», MDM/Data Quality, обменам и внешним интеграциям.

    Среди новых заказов:

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

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

    Для работы через Биржу доступны:

    • 0% комиссии площадки;

    • прямой обмен контактами;

    • исполнители разного масштаба — от частных специалистов до ИТ-команд;

    • безопасная сделка по желанию;

    • рейтинги, кейсы и история откликов.

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

    Теги:
    +6
    Комментарии0

    РБПО по ГОСТ Р 56939—2024: вебинар №21 из 30 — Безопасная поставка программного обеспечения пользователям

    Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.21. – "Безопасная поставка программного обеспечения пользователям". На YouTube. Слайды.

    Цели 21-го процесса по ГОСТ Р 56939—2024:

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

    Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

    Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

    P.S.

    Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.

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

    Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

    Теги:
    +3
    Комментарии0

    Собрались как то Росатом, Камаз, Северсталь и РЖД, чтобы разработать отечественный стандарт Бережливого производства - ГОСТ Р 56020.

    Сделали сначала первую версию от 2014 года.

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

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

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

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

    Вот исходный тойотовский список из 7ми:

    • перепроизводство

    • избыток запасов

    • лишнее перемещение объектов (логистика)

    • задержки и простои

    • лишняя обработка

    • лишние движения человека

    • дефекты и брак

    Вот, на мой взгляд, более адекватный для работы вариант:

    • использование неактуальной технологии

    • избыточность (операции, ресурсы, страховка)

    • ошибки и нарушения

    • упущенные возможности и простои

    Чем меньше в списке позиций - тем проще его запомнить и применять на практике.

    Чем лучше систематизация, тем более целостная получается модель.

    Теги:
    +3
    Комментарии7

    РБПО по ГОСТ Р 56939—2024: вебинар №20 из 30 — Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения

    Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.20. – "Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения". На YouTube. Слайды.

    Цели 20-го процесса по ГОСТ Р 56939—2024:

    Организация приёмки ПО с целью недопущения недостатков кода ПО перед его предоставлением пользователям.

    Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

    Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

    P.S.

    Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.

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

    Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

    P.P.S. Знакомство с ГОСТ Р 56939-2024 – всё более актуальная задача

    Информационное сообщение ФСТЭК России от 28 мая 2026 г. N 240/24/3693.

    Разработчикам программного обеспечения средств защиты информации рекомендуется использовать положения настоящей Методики для организации внутренних процессов жизненного цикла программного обеспечения в соответствии с ГОСТ Р 56939-2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования". 

    Теги:
    Всего голосов 3: ↑3 и ↓0+5
    Комментарии0
    1
    23 ...