Обновить

Все потоки

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

Microsoft представила WSL 3.0 с поддержкой запуска Linux-контейнеров в Windows

Microsoft представила подсистему Windows для Linux (Windows Subsystem for Linux - WSL) 3.0, позволяющую запускать Linux‑приложения в Windows. Новая ветка примечательна реализацией возможности для запуска Linux‑контейнеров в Windows и переходом на ядро Linux 6.18. Исходный код применяемых в WSL утилит командной строки, фоновых процессов для Linux‑окружений, графического стека wslg, сервисов для запуска контейнеров и виртуальной машины опубликован на GitHub под лицензией MIT. Версия WSL 2.0 вышла в сентябре 2023 года.

Microsoft представила WSL 3.0 с поддержкой запуска Linux-контейнеров в Windows

Ручная проверка — лучшая автоматизация. Хе-хе.

В общем, оставил ручную проверку при подтверждении публикаций на чужих сайтах. И уже не уверен, что это косяк.

А что делать, если признаки противоречат друг другу? Сделаю проверку жёстче — начну отбрасывать нормальные публикации после редактуры. Ослаблю — появятся ложные совпадения.

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

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

Думаю, однозначные случаи стоит закрывать автоматически, спорные отдавать человеку, а исторический факт и текущее состояние хранить отдельно.

Как считаете, ручная проверка редких спорных случаев — нормальная часть автоматизации или признак её отсутствия?

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

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

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

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

Магазины Apple известны своей полустерильной эстетикой, омрачать которую своим присутствием даже как-то неловко. В окружении всегда минимум визуального шума, максимум стекла, бетона и металла, а всякая инженерная начинка по возможности растворена в интерьере. К примеру, в магазине Apple на Пятой авеню в Нью-Йорке после крупного ремонта 2019 года систему вентиляции спрятали в каменном полу.

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

В России такое возможно вряд ли. Но не из-за низкой культуры производства, а из-за противопожарных требований, с которыми Apple обошлась смело даже для США.

Беглый поиск обнаруживает старые правила СП 9.13130.2009, которые утратили силу 1 марта 2025 года. Сейчас действует ГОСТ Р 59641-2021, который входит в перечень стандартов, добровольное применение которых обеспечивает соблюдение требований технического регламента о пожарной безопасности. В этом стандарте указано, что огнетушители должны быть хорошо видны и легкодоступы, а над огнетушителем на высоте 1,7 м должен располагаться соответствующий знак. Также стандарт требует, чтобы основные надписи и пиктограммы на само́м огнетушителе были хорошо видны. И вообще, никуда не делись обязательные правила противопожарного режима, где пункт 409 прямо требует располагать огнетушители на видных местах вблизи выходов из помещений.

Вряд ли российские ГОСТы допустят огнетушитель за потайной дверцей, ничем не выделяющейся на фоне окружающего пространства. Если судить по обнаруженному в нормах США, то и там такая дизайнерская находка под вопросом. Раздел 906.5 документа Fire Code города Нью-Йорк предписывает размещать переносные огнетушители на заметных местах, где они будут легко и немедленно доступны. Следующий за ним пункт ещё более однозначен: огнетушители не должны быть загорожены или скрыты из виду, а если визуального препятствия избежать нельзя, их местонахождение необходимо обозначить знаками или иной маркировкой. Наконец, отдельный пункт про шкафы для огнетушителей говорит, что такой шкаф должен быть легко распознаваемым. Есть оговорки, например для огнетушителей, которым угрожают кража, порча или неправильное использование — их разрешается размещать в другом одобренном пожарным ведомством месте. Но требование к идентифицируемости самого шкафа от этого не исчезает.

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

Забавно, что эмодзи огнетушителя (🧯) Apple поддерживает ещё с октября 2018 года. Значок вошёл в Unicode 11.0, которым iOS обзавелась с версии 12.1. Но в физическом Apple Store на Пятой авеню компания, похоже, предпочла оставить огнетушитель в режиме пасхалки.

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

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

Есть правило трёх: если в n проверенных образцах не нашлось ни одного дефекта, верхняя граница доли дефектов с 95% уверенностью — примерно 3/n.

10 документов без ошибок — доля ошибок может быть до ~26%. 30 документов — до ~9,5%. 100 документов — до ~3%. 300 документов — около 1%.

То есть, чтобы с 95% уверенностью сказать «ошибок не больше 1%», нужно около 300 документов подряд без единой ошибки.

Но и 300 не спасут, если выборка однородная. Ошибки LLM не случайны, как брак на конвейере, — они кучкуются: таблицы, мелкий шрифт, сканы. Поэтому выборку делят на группы по этим признакам и считают отдельно для каждой. Иначе 300 чистых текстовых PDF ничего не скажут о таблицах.

Ещё две вещи, которых нет у партии товара: — невоспроизводимость: прогоните один и тот же документ несколько раз — ответ может отличаться; — дрейф: новая версия модели или промпта обнуляет приёмку, проверку нужно повторить.

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

А на скольких документах вы проверяли модель, прежде чем пустить её в работу?

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

Гайд, как получать понятные и полезные ответы от ИИ:

  • Для сложных текстовых объяснений просим отвечать в формате ASD-STE100 — это упрощенный технический английский для авиации с жесткими правилами ясности. Без воды, все по делу. Для удобочитаемости иногда можно ставить 80% стандарта.

  • Вместо текста иногда лучше просить картинку или диаграмму. Так сложные вещи будут восприниматься быстрее и лучше.

  • Также можно попросить сделать интерактивную HTML-страницу под конкретную тему. С визуализацией и анимациями.

  • самый удобный и перспективный формат — персональные видео-гайды. Например, пишем «Сделай мне ролик в стиле 3Blue1Brown про [X]». Затем сразу добавляем озвучку в ElevenLabs.

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

🔥 Уходим на выходные с важной новостью!

Уже третий год подряд ГК «КОРУС Консалтинг» участвует в рейтинге лучших работодателей России от HeadHunter. Стартовал этап голосования внешних соискателей – тех, кто еще не работает в КОРУСе. И прямо сейчас ты сможешь поддержать компанию и помочь нам стать еще лучше!

 Как это сделать:

1️⃣ Перейди по ссылке и нажми «голосовать» 

2️⃣ Выбери в поиске «КОРУС Консалтинг» 

3️⃣ Поставь лайк рядом с названием компании ❤️

➡️ Проголосовать можно до 31 октября. Заходи и голосуй! 

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

Импортозамещение по частям: бэкап один, а Linux у всех разный

Увидел новость о том, что «Киберпротект» выпустил «Кибер Бэкап Старт» – бэкап Windows и Windows Server для физлиц и малого бизнеса.

Бэкап уже российский, а операционная система всё ещё Microsoft

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

А что происходит, когда инфраструктура становится больше и в ней появляется Linux?

Windows перестаёт быть единственной платформой

Российский Linux сегодня – скорее лоскутное одеяло, чем одна платформа.

В рейтинге российских ОС CNews 2026 перечислены Astra Linux, Альт, РЕД ОС, РОСА Хром, ОСнова, UBLinux, АльтерОС, Platform V SberLinux OS Server, ОС «Атлант» и EcoRouterOS.

Поэтому совместимость СРК приходится проверять точнее, чем «Linux – да/нет». «Кибер Бэкап» 18.6, к примеру, поддерживает не все российские ОС. Заявлены Astra Linux, Альт, РЕД ОС, РОСА «КОБАЛЬТ» и «ХРОМ», AlterOS и ОСнова, а также ряд зарубежных дистрибутивов. При этом UBLinux, SberLinux, ОС «Атлант» и EcoRouterOS в этой матрице не указаны.

Это не значит «не работает». Наличие слова Linux в описании продукта ничего не гарантирует для конкретного контура. Матрицу совместимости проверяют руками под свою ОС, версию и сценарий.

А что со службой каталога?

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

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

Классическая СРК восстанавливает машину, сервер, виртуальную среду или каталог после аварии. Но если из 10 000 пользователей неправильные данные получили 500, полный откат каталога – слишком грубо.

Поддержка каталога ≠ умение вернуть одного пользователя, группу или атрибут. Здесь нужны уже специализированные средства гранулярного восстановления, которые работают по другой логике: сравнить каталог с бэкапом и вернуть только нужные объекты и атрибуты.

С ростом инфраструктуры меняется задача защиты

Для одного компьютера достаточно вернуть Windows и файлы.
Для корпоративного Linux нужно проверить совместимость СРК с конкретным дистрибутивом, и техническими ограничениями. А для службы каталога – заранее понимать, что именно восстановится, если каталог жив, а данные уже сломаны.

Классическая СРК и гранулярное восстановление – не конкуренты, а два уровня защиты одной инфраструктуры. Они решают задачи разного масштаба и могут быть двумя уровнями защиты одной инфраструктуры.

Источники

  1. CNews, 30.09.2026 – запуск «Кибер Бэкап Старт», назначение продукта и поддержка Windows. «Киберпротект» запускает «Кибер Бэкап Старт»

  2. Документация «Кибер Бэкап» 18.6 – поддерживаемые ОС для агента Linux, версии ядра и glibc. Кибер Бэкап 18.6: поддерживаемые агенты и ОС

  3. CNews – рейтинг российских операционных систем 2026. Российские операционные системы 2026


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

Я живу без дисциплины, расписания, графика и режима дня. У меня нет списка задач на завтра и на следующую неделю. Сегодня делаю один проект, завтра переключаюсь на другой. Могу месяц спать днём, а следующий месяц ночью. Я не привязан к дням недели и времени суток. Для меня вторник не отличается от субботы, день не отличается от ночи, а месяц не отличается от другого месяца. При этом я работаю каждый день по 10 часов.

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

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

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

Не так давно NVIDIA опубликовала весьма обнадёживающие результаты опроса State of AI 2026.

Так, 88% респондентов заявили, что ИИ помог увеличить годовую выручку в отдельных подразделениях или в компании в целом.

А 87% сообщили, что ИИ помог снизить годовые затраты, причём 25% отметили сокращение более чем на 10%.

Что именно изменил ИИ, чтобы выручка выросла, а затраты снизились, в отчёте не уточняется.

Но даже если ИИ помог увеличить продажи, например за счёт большего числа запущенных маркетинговых кампаний, или сократить расходы на ПО и облачные сервисы, это всё равно ничего не говорит о самом главном — о том, как изменилась прибыль.

А построить модель вклада ИИ в прибыль и подтвердить её эмпирическими данными пока непросто.

Например, в исследовании 115 алжирских корпораций за 2016–2023 годы внедрение ИИ лишь незначительно повысило эффективность управления ликвидностью (отношение денежных средств к активам, Cash-to-Assets).

В другой работе изучали, как ИИ влияет на финансовые показатели и стоимость компаний из индекса S&P 500. Оказалось, что влияние ИИ-инноваций на рентабельность активов (ROA) невелико, данные неоднозначны, а сильнее всего эффект проявляется у компаний с большими расходами на НИОКР.

Получается, что отраслевые опросы заметно оптимистичнее академических оценок.

Подробнее про эффективность, производительности и ИИ здесь.

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

zVirt Backup: что нам известно о новом решении для резервного копирования ВМ

Если вы работаете с zVirt, то наверняка уже видели новости о zVirt Backup. Это совместное решение Orion soft и «Береста РК» для резервного копирования виртуальных машин в среде zVirt. Нам еще только предстоит протестировать решение, поэтому мы пока еще не делаем выводов о его работе. Но уже посмотрели, что заявляют разработчики.


Что внутри

Архитектура zVirt Backup строится вокруг нескольких компонентов.

Мастер-сервер отвечает за управление системой. Хранит актуальную конфигурацию, политики и задания, координирует остальные компоненты и предоставляет веб-консоль и REST API.

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

Есть и агенты, которые используются для работы с данными внутри гостевой ОС. Понадобятся, если одного бэкапа виртуальной машины недостаточно и нужно работать на уровне файловой системы, приложения или СУБД.

При этом zVirt и zVirt Backup останутся отдельными административными контурами. Управление виртуализацией и резервным копированием не объединяется в одну консоль.

Что умеет

Основной сценарий — резервное копирование ВМ в zVirt. Среди заявленных возможностей:

·        интеграция через Backup API — решение использует программный интерфейс zVirt для взаимодействия с платформой виртуализации;

·        поддержка работающих и остановленных ВМ;

·        работа с дисками в режиме RAW — прямой доступ к данным виртуальных дисков позволяет использовать их для резервного копирования и последующей работы с копиями;

·        Change Block Tracking (CBT) — при инкрементальном резервировании после создания полной копии система работает с изменившимися блоками, не передавая каждый раз весь объем данных;

·        параллельная обработка — несколько дисков ВМ могут обрабатываться одновременно, а отдельный диск — несколькими потоками;

·        масштабирование за счет нескольких силовых серверов;

·        кластеризация компонентов системы.

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

Планы на развитие продукта

Orion soft уже обозначил несколько направлений: расширенный мониторинг резервного копирования, сохранение структуры папок виртуальных машин и резервирование параметров SDN.

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

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

Мы пока воспринимаем zVirt Backup именно как решение, которое предстоит проверить руками. Для СРК это, пожалуй, самый честный тест: не то, сколько функций указано в списке, а то, получится ли восстановить данные тогда, когда они действительно понадобятся.

Подписывайтесь на наши каналы в Telegram и МAX и следите за новостями, чтобы следить за обзорами вендорских новинок.

 

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

🆕 В Managed Containers появился аддон HAMi. С его помощью одну GPU можно разделить между несколькими нагрузками и для каждой задать долю видеопамяти и вычислительных ресурсов.

HAMi помогает:

🔵 запускать несколько нагрузок на одной GPU
🔵 распределять между ними видеопамять и вычислительные ресурсы
🔵 повышать загрузку GPU
🔵 не устанавливать и не сопровождать middleware для GPU sharing самостоятельно.

Подробнее — в документации

📬 Мы в MAX

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

Выпустили с командой  учебное пособие по моделированию систем транспортных средств - "REPEAT VISION для электромобильности".

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

Одно из первых учебных пособий по REPEAT: подойдёт тем, кто осваивает мультифизическое моделирование и цифровые двойники.

Книга доступна бесплатно https://www.litres.ru/book/ivanov-nikita-34087492/repeat-dlia-elektromobil-nosti-74545417/.

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

Еще 6 причин быть на GoCloud Tech 2026: приходите с ноутбуком и забирайте готовые решения

Доклады дают теорию, воркшопы — рабочий прототип. На GoCloud Tech 2026 мы организовали шесть практических сессий, где вы сами настроите инфраструктуру, запустите приложение и развернете защиту прямо в своем личном кабинете под руководством команды Cloud.ru.

11:50–12:50 | Spark Connect: интерактивная работа с данными
Федор Фаизов, ведущий аналитик, Cloud.ru
Покажем три сценария работы с Evolution Managed Spark:

  • разработчики подключаются к Spark из локальной IDE;

  • аналитики работают с данными и визуализациями в Jupyter Notebooks;

  • системные аналитики DWH строят ETL-процессы в dbt на чистом SQL.

13:10–14:10 | Запускаем приложения через ИИ-агента
Антон Щеколдин, менеджер продукта, Cloud.ru
Воркшоп для тех, кто хочет сокращать путь от идеи до прода. Научим работать с ИИ-агентом: вы формулируете задачу на естественном языке — агент генерирует код, собирает образ и деплоит приложение. За 60 минут пройдете весь цикл и заберете работающее приложение на выделенном домене с доступом к интерфейсу управления и инструкцией по использованию для ваших задач.

14:30–15:00 | Синтетический мониторинг своими руками
Андрей Жирунов, менеджер продуктов, Cloud.ru
Разберемся, как проверять реальный пользовательский путь с помощью flow-тестов: за 30 минут соберете сценарий проверки на подготовленном стенде, создадите flow-тест, запустите его через готовых агентов и посмотрите результаты выполнения, включая диагностику ошибок. После воркшопа сможете внедрить постоянную проверку пользовательского сценария и использовать ее для мониторинга сервисов — заберете инструкцию по настройке и готовые шаблоны тестов для вашей инфраструктуры.

15:20–16:20 | Data Lakehouse с использованием ADB и PXF
Максим Еремин, менеджер продукта, Cloud.ru
Научитесь строить Data Lakehouse-хранилища на платформе данных Cloud.ru Evolution. Разберем, что такое DLH и зачем он нужен, причем тут Greenplum и PXF, как реализовать архитектуру с облачными сервисами.

16:35–17:15 | Guardrails Filter для защиты LLM-приложений
Никита Стешов, менеджер продукта, Cloud.ru
Воркшоп для тех, кто хочет защитить свои LLM-приложения от утечек чувствительных данных и нежелательного контента. Разберемся, как настроить Guardrails-фильтр под ваши сценарии: пройдете путь от готового решения «из коробки» до гибкой настройки open source-решения с собственными правилами фильтрации. За 40 минут получите пошаговый опыт настройки — от базового интерфейса до кастомизации под специфические требования безопасности. 

17:30–18:00 | VPN до другого облака
Алексей Болотин, менеджер продукта, Cloud.ru
В деталях разберем создание VPN-туннеля:

  • создадим отказоустойчивый VPN-шлюз;

  • построим IPsec до удаленной локации;

  • настроим персональный профиль безопасности с кастомными параметрами шифрования;

  • научимся использовать сертификаты из Certificate Manager для авторизации;

  • настроим мониторинг и события по этому VPN-туннелю.

📅 Когда: 15 октября, воркшопы с 11:50 до 18:00 мск.
📍 Где: Москва, ул. Волочаевская, 48, стр. 1 (м. Площадь Ильича), Loft #8 (ДК «Серп и молот»).

👉 Зарегистрироваться и выбрать воркшопы

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

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

Нужно ли выбирать между Data Mesh и Data Fabric?

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

Отсюда возникают две разные, но связанные задачи: распределить ответственность за данные и организовать единый доступ к ним. Именно для этого используют Data Mesh и Data Fabric.

🔹 Data Mesh — это подход, при котором ответственность за информацию распределяется между бизнес-доменами, а не концентрируется в одной дата-команде. Например, маркетинг сам следит за качеством своих данных: описывает, обновляет и передает другим командам как data-продукт.

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

Поэтому выбирать необязательно: Data Mesh и Data Fabric решают разные задачи и могут работать вместе.

➡️ В новой статье VK Cloud подробнее разбираем оба подхода и их место в архитектуре данных.

👉 Больше полезных постов читайте в канале Данные на стероидах. Подписывайтесь в Telegram и МАХ

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

Как подписываются главы крупнейших ИИ‑компаний. На сайте правительства США опубликовали фотографию с подписями руководителей Google, OpenAI, Meta* (* — признана экстремистской и запрещена в России), xAI, Anthropic, Nvidia. Кстати, в документе есть опечатка — не United, а Unites написано.

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

Помощь от бана Claude со стороны Anthropic, которая блокирует пользователей из разных стран, где сервис недоступен. Это не 100% способ, который сохранит от блокировки со стороны Anthropic, но может увеличить шансы не потерять проекты. Вот, какие файлы в мета‑данных могут выдавать пользователей из разных стран:

CLI (~/.claude.json):

  • machineID — создаётся один раз и персистит в конфиге. При этом он не привязан к аккаунту, значит ID един для всех учёток на машине.

  • userID — это device_id из телеметрии.

  • anonymousId claudeco… — анонимный ID телеметрии

  • Вложенный ~/.claude/.claude.json используется cowork‑VM/другой установкой — вторая пара machineID / userID. Это сгенерированный per‑конфиг‑ID.

Десктопное приложение (/Library/Application Support/Claude/):

  • ant‑did — device ID приложения.

  • ant‑device‑registry.json — он привязывает машину к каждому аккаунту. То есть в рамках одного устройства для всех учёток он един. Подписывается также ключом устройства.

  • remote‑control‑state.json — также телеметрия.

  • config.json — общие настройки и состояние приложения (последний аккаунт, дата первого запуска, флаги телеметрии, кэш токенов авторизации).

  • chromeExtension.pairedDeviceId — ID устройства, привязанного к расширению Claude для Chrome. • claude‑code‑sessions/ — локальные записи сессий Claude Code, по одной на аккаунт, под которыми когда‑либо заходили на машине.

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

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

Релизный вебинар - выход Кибер Бэкапа 19

Представим обновление нашего флагманского продукта — системы резервного копирования Кибер Бэкап 19.

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

25.10.2026 в 13:00 МСК проведем онлайн вебинар, на котором обсудим следующие темы:

  • Расширенная интеграция с PostgreSQL и СУБД на ее основе: развитие многопоточности и новые механизмы защиты

  • Интеграция с VMmanager и снижение нагрузки на сеть при защите ВМ под управлением VMware

  • Интеграция с RuPost

  • Развитие возможностей защиты Mailion и Exchange

  • Повышенная масштабируемость защиты Почты VK WorkSpace

  • Интеграция с Zabbix, MAX и новая система уведомлений

  • Интеграция с решением для неизменяемого хранения резервных копий

  • Новая система лицензирования

  • Начало закрытого тестирования Кибер Медиасервера

Регистрация

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

На дворе 2026 год, и про «ИИ» в ИБ говорят все. А что он реально делает? Не в маркетинговых фантазиях, а вот прямо сейчас, по факту, на самом деле? Давайте посмотрим свежие исследования и опросы экспертов участников рынка (ссылка 1, ссылка 2, ссылка 3). 

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

При этом 24% сказали, что автоматизация мешает им развивать профессиональные навыки, а 47% опасаются, что из-за «ИИ» вход в профессию станет гораздо сложнее, если вообще возможным. Уже в недалеком будущем (если не настоящем) «ИИ» приходит, чтобы помогать аналитикам учиться на рутине, а потом эту самую рутину забирает. Машина разгружает младшего специалиста от работы и одновременно начинает лишать его той работы, на которой он должен был получить опыт и стать старшим специалистом.

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

Исследование Google Threat Intelligence Group показывает, что среди уязвимостей, которые GTIG считает вероятно найденными с помощью «ИИ», целых 50% позволяли удаленное выполнение кода, тогда как среди остальных CVE таких было 26%. При этом число раскрытых уязвимостей вообще выросло с 5045 в январе до 10 477 в июле и 10 740 в августе 2026 года, а среднее число эксплуатируемых уязвимостей поднялось с 10,5 в месяц в 2025 году до 18 в месяц в 2026-м. 

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

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

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

Меж тем, вспомним недавнюю статистику по корпоративным SOC: связанные с «ИИ» срабатывания составляют всего 0,43% общего потока алертов. Более того, внутри даже этой цифры подавляющее большинство приходится не на реальные атаки, а на шум и потенциальные риски. Иными словами, пока «ИИ» создает для SOC гораздо больше работы в виде «похоже на что-то страшное», чем в виде действительно новых атак.

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

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

Заставил локальные модели играть в игру MasterMind

Недавно подключил MCP сервер firefox-dev-tools, запустил браузер в специальном режиме (firefox --marionette --remote-debugging-port) и наблюдал за тем как модели отгадывают заганные цвета.

Пример отгаданной комбинации за 5 ходов, локальный Qwen3.6 (36к токенов)
Пример отгаданной комбинации за 5 ходов, локальный Qwen3.6 (36к токенов)

В целом я почти не сомневался в том, что Qwen 3.6-35b справится, но интересно было проверить более мелкие модели, и они чаще всего провалились, иногда вызывали инструменты невпопад, часто они просто по нескольку раз подря проверяют одни и те же цвета и даже одни и те же комбинации по 2-5 раз (думаю могут и больше, но я не выдерживал такую глупость).

Позже я понял, что надо сделать версию для моделей - потому что в этой версии (что на скриншоте выше) инструмент snapshot не возвращал нормально результат и историю попыток, часто бывало модели видели 4 разных черных точки в разных попытках и считали что уже победили. После создания новой игры для ИИ, я прогнал еще несколько раз тестов для нескольких моделей. Я подключал MCP сервер напрямую в llamacpp, и просил сыграть в игру со страницы (https://boolkin.gitverse.site/html/Vibe/MasterMind/mastermind-ai.html).

Следующие тесты для Qwen35b оказались уже не такими впечатлительными, доходило и до 15 попыток, раз на раз не приходится, как говорится. Это же подтверждает и то, что один раз до победы дошла и Qwen3.4-9b, но остальные разы она чаще просто тупила, делая однотипные попытки раз за разом. Понравилось как решила Gemma4-26b - она запустила скрипт для проверки вариантов и довольно быстро решила задачу. В этом отношении впечатлился еще одной моделью на базе Квена (occamy) - она также сделала скрипт, но пошла дальше - скрипт который в автомате решает за минимальное число попыток, запустила его и отчиталась о проделанной работе (если что диалог сохранен). Я ее попросил сделать букмарклет, она и его сделала. Теперь есть и игра, и решатель.

Удивила маленькая модель MiniCPM5-2B-Q8_0 (2.7 Гб) - очень ловко орудует инструментами, но не хватает логики для решения именно игры - также множественные проверки повторяющихся цветов.

Большие умные модели из OpenCode (бесплатные BigPickle и Long Cat) тоже справились, естественно, и тоже с помощью скриптов, но BigPickle использовал не js в браузере, а Python.

В общем если вам тоже интересно попробовать свои модели, то подключайте MCP сервер к llama.cpp (создать файл mcp.json и запустить llama.cpp с флагом –mcp-servers-config /путь/к файлу/mcp.json). В файле прописать команду (у меня файрфокса)

{
  "mcpServers": {
    "firefox": {
      "command": "npx",
      "args": ["-y", "@mozilla/firefox-devtools-mcp", "--connect-existing", "--marionette-port", "2828"]
    }
  }
}

Если у вас другой браузер, то прописать для него MCP сервер, можно поискать в базе серверов (какой-нибудь mcpdb) нужный MCP, где иногда даже напишут настройки для json конфигураций.

Задавал я такой пропт:

Сыграй в готовую игру mastermind со страницы https://boolkin.gitverse.site/html/Vibe/MasterMind/mastermind-ai.html Угадай расположение 4 загаданных цветов. Важно! открывай игру в новом окне, и не начинай новую игру каждый раз (новая игра каждый раз загадывает другую последовательность из 4 цветов), доведи одну игру до победы, угадай комбинацию. Вспомни правила Mastermind и игровую стратегию и начинай играть.

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

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

BIS Summit 2026: главное

29 сентября прошёл BIS Summit 2026 — 19-я ежегодная ИБ-конференция. Организатор — Ассоциация по защите деловой информации (BISA) при поддержке InfoWatch.

Тема — «Искусственный интеллект: где граница между прогрессом и угрозой».

Главный вывод: на ИИ наконец начали обращать должное внимание с точки зрения ИБ.

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

Пост-релиз — по ссылке.

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

Новый релиз django-modern-rest@0.16.0

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

Скорость

  • PydanticFastSerializer.deserialize в x2.2 быстрее

  • PydanticFastSerializer.serialize в x1.33 быстрее

  • Новый BodyMsgspec компонент в x1.6 быстрее чем Body

  • Новый способ сериализации объектов через MsgspecSerializer и msgspec.Struct, gc=False в x2 раза быстрее

  • Content negotiation в x1.2 быстрее для точных заголовков

  • Content negotiation в x65 быстрее для сложных Accept заголовков

Дефолтные значения для компонентов

Теперь можно указывать дефолты для всех компонентов. Мы корректно отобразим их в OpenAPI спецификации:

class ProductController(Controller[MsgspecSerializer]):
    def post(
        self,
        parsed_body: Body[ProductFilters | None] = None,
        parsed_query: Query[Pagination] = DEFAULT_PAGINATION,
    ) -> dict[str, str | int]: ...

Значения по-умолчанию

Готовые вьюхи для аутентификации

Например, чтобы получить Opaque Token по логину и паролю, достаточно всего лишь:

from dmr.security.token import concrete_views

path(
    'auth/',
    concrete_views.ObtainTokenSyncController.as_view(
        serializer=PydanticFastSerializer,
    ),
)

Пагинация через курсор

Теперь мы поддерживаем два типа пагинации: LIMIT + OFFSET и cursor:

paginator = CursorPaginator(
    Entry.objects.order_by('rank', 'name'),
    per_page=parsed_query.limit,
)
page = paginator.page(parsed_query.cursor)  # or: await paginator.apage(...)
return CursorPaginated(next_cursor=page.next_cursor, per_page=..., page=[...])

Cursor pagination

Extras

Создавайте свои контроллеры со своими настройками, мы добавили типизированное поле extras в @modify и @validate:

modify: Final = ModifyEndpoint(SmartResponse)

class APIController(Controller[PydanticFastSerializer]):
    extras = SmartResponse()

    @modify(extras=SmartResponse(response_text='from endpoint'))
    def post(self) -> str:
        return SmartResponse.of(self)

Extras

OpenAPI теперь умеет добавлять любые x- значения

Поддерживаем любые кастомные значения:

class UserController(Controller[MsgspecSerializer]):
    x_extensions: ClassVar = {'x-owner': 'users-team'}  # on the path item

    @modify(x_extensions={'x-rate-limit': 100})  # on the operation
    def post(self, parsed_body: Body[UserModel]) -> UserModel: ...

OpenAPI

Поддержка library-skills

Установите наши скиллы одной командой:

uvx library-skills --claude   # -> .agents/skills/dmr, .claude/skills/...

Делаем разработку с ИИ-агентами - проще!

Буду рад обратной связи в комментах! Какая фича ваша любимая? Чего вам не хватает для следующих релизов?

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

Как управлять InfiniBand в дезагрегированном инференсе и балансировать ИИ-кластер изнутри? Узнаете на GoCloud Tech 2026

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

На докладе разберем, как мы разработали полноценный контроллер для автоматического управления InfiniBand-партициями. Расскажем, как устроен InfiniBand Subnet Manager и как мы написали собственный контроллер поверх него. Покажем архитектуру решения на реальных примерах балансировки дезагрегированного инференса, операций обучения моделей и перераспределения нагрузки.

Спикер:
Денис Добрынин — старший Go-разработчик, Cloud.ru

Трек: Инфраструктура

📅 Когда: 15 октября в 15:50–16:20 мск.

👉 Зарегистрироваться

А пока ждете выступление, можете почитать статью из нашего блога о том, как оптимизировать инференс в 2026 году.

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

Должен ли тимлид быть лучшим разработчиком в команде?

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

Инна Пристягина (руководитель развития персонала в PVS-Studio) рассказала о практиках хорошего тимлида, но плохого тех.эксперта. Разобрала, почему неумение лично выполнять задачи команды — не слабость руководителя, а вполне осознанная и эффективная модель работы.

Александра Бутузова (TeamLead кросс-функциональной команды в F.Doc) разобрала, как решать проблемы как тимлид. Ведь лидеру регулярно приходится сталкиваться с задачами и ситуациями, в которых он не является экспертом. Как действовать в таких случаях и в чем заключается истинная ценность работы руководителя — обсудили на вебинаре.

Посмотреть можно тут:
▫️ YouTube

▫️ VK Video

▫️ Rutube

▫️ Наш сайт

Приятного просмотра! 😉

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


Ссылка на одного участника в Telegram — ещё не персональный доступ

Представим закрытый канал: бот подтвердил оплату и выдал покупателю ссылку с member_limit=1. Кажется, что схема защищена: один платёж — один участник. Но лимит не проверяет, кто именно вступает.
По документации Telegram, member_limit ограничивает число пользователей, которые могут одновременно состоять в чате, вступив по этой ссылке. Это не привязка к Telegram ID покупателя и не гарантия одного использования за всё время.

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

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

Для обычных chat_join_request без query_id схема такая:

  1. Бот создаёт ссылку с creates_join_request=True, без member_limit: эти параметры нельзя использовать одновременно.

  2. При получении заявки берёт chat.id и from.id, проверяет действующее, не отозванное право пользователя на конкретный чат.

  3. При положительном решении вызывает approveChatJoinRequest. Боту нужны права администратора с can_invite_users.

Допустим, доступ оформлен для user_id=101 в канал A. Приходит заявка от user_id=202, у которого такого права нет. Само наличие приглашения не становится основанием для одобрения. И наоборот: оплата канала A не должна автоматически открывать канал B.
Если разрешены подарки, получателя доступа нужно определить заранее. С заявкой сравнивается его Telegram ID, который может отличаться от ID плательщика.

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

Условная последовательность для общей ссылки:

— 12:00:00 — пользователь оплачивает подписку;
— 12:00:02 — приходит заявка, но обработчик платежа ещё не создал право доступа;
— 12:00:05 — подтверждение оплаты обработано, право записано.

Заявку для повторной проверки с ограниченным временем ожидания я бы сохранял. После обработки платежа можно заново проверить актуальный доступ и попробовать одобрить заявку. Скриншота платежа для этого недостаточно. Если БД недоступна, автоматическое одобрение тоже следует отложить.
Это относится к обычным заявкам. Для событий с query_id действует другой протокол: в течение 10 секунд нужно вызвать answerChatJoinRequestQuery или sendChatJoinRequestWebApp. Переносить туда ту же логику ожидания без изменений нельзя.

Срок приглашения и срок подписки тоже нужно разделять. Например, ссылка действует пять минут, а доступ оплачен на месяц. Истечение expire_date не удаляет уже вступившего участника. За окончание доступа отвечает отдельная логика.
Проверка заявки защищает только этот способ вступления. Другие ссылки без одобрения и действия администраторов тоже нужно учитывать. Копирование самого контента она не предотвращает.

Собственная система нужна не всегда: для ежемесячного доступа в один канал у Telegram есть платные пригласительные ссылки с оплатой Stars. Дополнительная модель прав становится полезной, когда продукт объединяет несколько чатов и тарифов.

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

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

Представлен открытый проект netboot.xyz — универсальный установщик netboot на Jinja. Проект работает так:

  • установить программу на флешку.

  • далее установщик подключит ПК к интернету и предложит установку нужной системы.

  • на выбор есть Linux, Windows 7/8/10/11, Fedora и другие ОС

  • дальше проект скачает и установит чистую систему.

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

Итоги VK WorkSpace Conf 2026

23 сентября мы провели в Москве вторую конференцию VK WorkSpace Conf. Главной темой стали ИИ-агенты, которые работают в почте, мессенджере и календаре с правами конкретного сотрудника. Под катом рассказываем, как устроены MCP-сервер и платформа VK AI Space, как работает федерация с внешними компаниями и как защищены данные на устройствах и в почте.

Три уровня ИИ в VK WorkSpace

Мы встраиваем ИИ в платформу на трех уровнях:

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

  • Ассистент. Отвечает на вопросы, собирает данные из нескольких сервисов и показывает, откуда их взял.

  • Агенты. Сами планируют решение задачи, собирают данные и выполняют действия за пользователя через MCP-сервер.

41 инструмент через MCP — и ни одного лишнего доступа

Через MCP-сервер агент получает инструменты в Мессенджере, Почте, Календаре, Оргструктуре и на Диске. Он читает чаты и письма, отправляет сообщения, назначает встречи и работает с файлами, но видит только те данные, к которым есть доступ у самого сотрудника.

Например, так агент готовит отчет к встрече. Сотрудник просит в Мессенджере подготовить отчет по проекту. Агент собирает данные с Диска, из Мессенджера и Почты, а при необходимости из CRM, ERP и других систем с поддержкой MCP. А после формирует отчет, рассылает участникам и публикует на Диске.

Подключить агента можно тремя способами:

  • взять готового Ассистента в Супераппе, который работает на моделях внутри компании;

  • собрать агента на платформе VK AI Space;

  • подключить своего через любой MCP-клиент.

В облачной версии доступ к MCP-серверу входит в тариф «Расширенный».

Агент, который знает регламенты и не выходит из песочницы

На платформе VK AI Space компании создают, запускают и контролируют агентов. Для этого в ней есть три механизма:

  • Навыки. Компания упаковывает правила и регламенты в навык, который агент применяет в работе.

  • Память. Агент помнит решения из прошлых задач, поэтому повторно решаемых задач становится до 40% меньше.

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

С агентами обработка обращения в поддержку обходится в 5,5 раза дешевле, а поиск информации в мессенджере занимает на 60% меньше времени.

Федерация и внешние участники

В коробочной версии федерация в Мессенджере объединяет в одном чате неограниченное число компаний, в облачной она появится в первом квартале 2027 года. 

Служба ИБ видит полный контекст передачи файла, а данные уходят в DLP и SIEM. Внешним участникам открыты и другие сервисы:

  • Календарь показывает занятость;

  • Диск дает доступ к папкам и файлам с разными правами, паролем и сроком действия ссылки;

  • Доска и Проекты дают гостевой доступ подрядчикам и партнерам.

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

Зашифрованный контейнер в приложениях

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

  • вход по пин-коду;

  • запрет скриншотов и записи экрана;

  • запрет выноса файлов за пределы приложения;

  • уведомление о включенном VPN.

Антиспам без роста инфраструктуры

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

Что дальше

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

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

Скролл без костылей — что уже умеет CSS

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

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

  • Overflow — основа скроллинга. Если у контейнера ограничена высота, overflow: auto добавит прокрутку только тогда, когда контент перестанет помещаться. Через overflow-x и overflow-y можно отдельно управлять каждой осью. 

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

  • Плавные переходы по якорям делаются одной строкой: scroll-behavior: smooth. Но есть нюанс с доступностью: если пользователь включил prefers-reduced-motion, плавную анимацию лучше отключить. 

  • Scroll Snap может заменить простой JS-слайдер. scroll-snap-type и scroll-snap-align позволяют фиксировать карточку или секцию после прокрутки, а scroll-snap-stop: always — не перескакивать через элементы при быстром свайпе. 

  • Фиксированный header не должен перекрывать якорь. Вместо дополнительных скриптов можно задать scroll-padding-top для страницы или scroll-margin-top для отдельных секций. 

  • Вложенный скролл тоже можно контролировать. Если внутри страницы есть модальное окно или боковая панель, overscroll-behavior: contain не даст прокрутке после конца блока автоматически перейти на родительскую страницу. 

Есть и менее очевидные детали. Например, scrollbar-gutter: stable помогает избавиться от горизонтального «прыжка» страницы при появлении полосы прокрутки, а кастомный scrollbar лучше не делать слишком узким или малоконтрастным — это уже влияет на доступность интерфейса.

JavaScript понадобится уже там, где скроллинг запускает дополнительную логику: Infinite Scroll с подгрузкой данных, синхронизацию нескольких областей, аналитику или сложные интерактивные сценарии. А вертикальный и горизонтальный скролл, Scroll Snap, плавные якоря и управление вложенной прокруткой вполне можно оставить браузеру. 

Если хотите посмотреть готовые HTML/CSS-примеры и разобрать типичные ошибки, читайте полное руководство в блоге Рег.облака.

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

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

И собрали целую ПАПКУ 🗂️

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

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

Прикручивал свой diff к git и прошелся по граблям

Я пишу небольшую утилиту datadiff на Rust. Она разбирает два файла JSON, YAML, CSV, TOML или XML и сравнивает получившиеся деревья, поэтому переставленные ключи и переформатирование ее не волнуют. Изменения она печатает путями вроде spec.replicas: 3 → 5. Долго это была отдельная команда, про которую надо было вспомнить, так что я решил встроить ее прямо в git diff. Первой версией была строчка в README: шелл-функция, которая из семи аргументов, передаваемых git внешнему драйверу, брала второй и пятый (там лежат старая и новая версии файла). Работало, пока не попался первый кривой файл.

git diff до и после datadiff
git diff до и после datadiff

Оказалось, git считает любой ненулевой код выхода падением драйвера. Пишет fatal: external diff died и дальше ничего не показывает, все файлы после сломавшегося просто пропадают из вывода. А datadiff как нормальный CLI возвращал 1, если нашел различия, и 2 на невалидном файле. Хуже всего, что невалидный конфиг это обычное состояние: открыл YAML, начал править, запустил git diff глянуть что наделал, и получил fatal. Теперь в режиме драйвера datadiff всегда выходит с нулем, а про файл, который не смог разобрать, печатает короткую заметку и подсказку про git diff --no-ext-diff.

Внешний драйвер git вызывает только для самого git diff. git log -p, git show и git blame его игнорируют, туда можно попасть только через textconv, это фильтр, который превращает файл в текст перед обычным построчным сравнением. Я сделал для него режим normalize, он печатает файл в каноническом виде с отсортированными ключами. Если файл не разбирается, normalize отдает его как есть, и тут я накосячил: читал его через read_to_string(...).unwrap_or_default(). Файл не в UTF-8 превращался в пустую строку с обеих сторон, git видел две одинаковые пустоты и молча выкидывал файл из git log -p. Сейчас там чтение байтов и тест на это.

Самые обидные грабли нашлись не в git, а в CSV. В статье на Хабре про самодельный формат конфигов автор объяснял, зачем ему маркер «бери как есть»: чтобы 00544 не превратилось в 544. Я пошел проверять datadiff, и он делал ровно это. CSV типов не хранит, поэтому каждая ячейка, которая разбиралась как число, становилась числом, и замена 00544 на 544 считалась отсутствием изменений. Пока чинил, вылезло еще два случая. Слова, которые f64 честно принимает за число, вроде Nan и inf: человек по имени Nan превращался в NaN, а NaN не равен сам себе, так что неизменившаяся ячейка показывалась как измененная. И целые длиннее i64: они уходили во float и теряли цифры, так что два 20-значных номера счета, отличавшиеся последней цифрой, сравнивались как равные. Правило в итоге такое: ячейка становится числом, только если при этом ничего не теряется. Ведущий ноль перед цифрой, слова вроде nan и inf и слишком длинные целые оставляют ее строкой, а 100 и 100.0 по-прежнему равны. Это вошло в релиз 0.4.1.

Еще запомнился CI. После одного коммита на Windows падал actions/checkout, даже до сборки не доходило. Виноват был файл Icon\r, в нем macOS хранит кастомную иконку папки, в конце имени у него возврат каретки, и он случайно уехал в репозиторий. Windows создать такое имя не может вообще. Тесты при этом падали через раз на всех трех ОС, потому что дочерний процесс успевал завершиться раньше, чем тест дописывал ему stdin, и unwrap ловил EPIPE. Сам проект тут: https://github.com/dimanovikov/datadiff настройка для git в README занимает три строки.

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

Claude научили делать моды на любую игру — с помощью набора скиллов universal-modder ИИ сам пересобирает движок, декомпилирует код, генерит спрайты, 3D-графику, аудио и проводит тесты. Этот плагин уже позволил создать:

• Minecraft в Skyrim, GTA 5, Cyberpunk 2077 и Elden Ring;
• Роботакси в Age of Empires 2;
• Скейтбординг в Call of Duty: Modern Warfare 2;
• Атомные бомбардировки в Terraria;
• Смесь Escape from Tarkov со Skyrim.

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

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

Никогда не думал, что навыки целостного анализа музыкальных форм, приобретенные в музыкальном училище и отшлифованные в консерватории настолько будут полезны. В музыке тебя учат видеть произведение на нескольких уровнях одновременно: на уровне такта, мотива или интонации, музыкальной темы, периода (обычно 8+ тактов), раздела музыкальной формы, всей формы в целом, части произведения (разные части сонаты, симфонии или концерта написаны в разной музыкальной форме), и иногда - в рамках "большой формы" - несколько симфоний складываются в общий цикл. Твой взгляд приучается видеть тонкие сети взаимосвязей внутри музыкального организма, восстанавливать причинно-следственные связи: почему тот или иной мотив появился именно здесь? Какая история его развития? Как он менялся? От чего шёл и к чему пришёл? И что интересно - куда идёт?

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

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

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

Как применить одну функцию к нескольким колонкам, не перечисляя их в SELECT

В прошлом посте я рассказывал про модификатор REPLACE, с помощью которого можно менять значения «на лету», не перечисляя все колонки в SELECT. Сегодня расскажу про еще один полезный модификатор — APPLY.

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

В классических транзакционных базах, таких как PostgreSQL, мы бы вручную перечисляли в SELECT абсолютно все поля, которые хотим просуммировать.

В ClickHouse это делается проще.

Чтобы не писать десятки колонок руками, можно использовать модификатор APPLY. Он работает в связке со звездочкой * и автоматически применяет указанную функцию ко всем колонкам в выборке.

В качестве примера рассмотрим таблицу metrics, в которой хранится количество кликов, просмотров и затрат:

┌─clicks─┬─views─┬─spend─┐
│     10 │   100 │    50 │
│     15 │   150 │    70 │
└────────┴───────┴───────┘

Чтобы посчитать сумму по каждому полю обычно мы привыкли писать так:

SELECT
  sum(clicks),
  sum(views),
  sum(spend)
FROM metrics

┌─sum(clicks)┬─sum(views)─┬─sum(spend)─┐
│         25 │        250 │        120 │
└────────────┴────────────┴────────────┘

С использованием APPLY можно написать короче:

SELECT * APPLY(sum) 
FROM metrics

┌─sum(clicks)┬─sum(views)─┬─sum(spend)─┐
│         25 │        250 │        120 │
└────────────┴────────────┴────────────┘

Несколько нюансов:

  1. Правила вызова пишутся в круглых скобках. Синтаксис такой: APPLY(имя_функции) без аргументов.

  2. Передаваемая функция в APPLY должна уметь работать со всеми полями выборки и их типами данных. Например, для sum все поля должны быть числовыми.

  3. Если мы хотим применить sum, но в таблице есть нечисловые типы данных, мы можем исключить их через EXCEPT или выбрать только нужные через модификатор COLUMNS, о котором я расскажу в следующем посте.

  4. APPLY можно использовать не только для агрегации, но и для изменения типов данных. Например, APPLY(toString) быстро переведет все выбранные колонки в строковый формат.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

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

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

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

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

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

Агент — третий тип исполнителя. Он интерпретирует ситуацию, как человек, но без норм, опыта и последствий, которые человек приносит с собой.

Поэтому ни один из подходов проектирования не подходит для агента. Подробнее почему — в статье «Почему AI-агент не цифровой сотрудник».

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

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

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

  • Решите, что агенту не нужно интерпретировать. Всё, что можно установить независимо, передайте ему уже подтверждённым. Интерпретацию оставьте там, где ради неё агент и нужен.

  • Определите, как примете результат, до запуска и отдельно от агента. Когда критерии приёмки известны заранее, работа для агента проектируется точнее, а результат принимать проще.

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

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

Стратегия голубого океана в сопровождении

Сегодня – история о применении книги «Стратегия голубого океана» в сопровождении клиентов. Тут можно сразу и Стивена Кови с его «Третьей альтернативой» упомянуть – подходы схожие.

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

Помимо чтения книг, я ещё и работаю – руковожу отделом программистов 1С. Занимаемся, в том числе, сопровождением – у клиента есть ПО, которым он пользуется, и периодически нужна помощь, доработки, настройка, устранение ошибок и т.д.

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

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

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

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

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

Я придумал отдельную оплачиваемую роль – продюсер клиента. Что важно – это был именно программист, а не менеджер. Эдакий маленький ИТ-директор на аутсорсинге. Продюсер пропускал через себя все задачи клиента (большинство решал сам), быстро вникал во все его особенности, поэтому знал, как там всё устроено. Часть задач раздавал другим программистам, контролируя исполнение.

Клиент получил то, что просил. Человека, который постоянно с ним. Программиста, а не менеджера – существенная часть вопросов стала решаться сразу, в разговоре, а не «мы вам перезвоним». Постоянную команду специалистов, управляемую продюсером. Ну и ответственность, наконец-то – продюсер отвечает за решение всех задач клиента (за это и деньгу получает).

Просто же, согласитесь? Но это тоже голубой океан.

Это история применения книги из Книжного стека.

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

redb 4.2.0: единый контракт трассировки, коннектор AS4 и семь шаблонов проектов

Вышла 4.2.0 сразу по четырём продуктам экосистемы: хранилище redb, интеграционный фреймворк redb.Route, рантайм redb.Tsak и OpenID-сервер redb.Identity.

Коротко о главном.

Безопасность. В Identity выход из сессии теперь действует на сессию самого браузера: userId в запросе больше не выбирает, кого разлогинить. Полный выход отзывает не только сессии, но и гранты. Отозванный ключ подписи больше не предлагается никому по построению, а не по порядку регистрации. В Tsak модуль с http-входом, у которого никто не проверял учётные данные, теперь просто не стартует. В Route ssl=true у RabbitMQ honoured на всех путях подключения, включая именованные фабрики, где TLS не включался вовсе.

Ломающее. Трассировка стала единым контрактом в ядре, и ему следуют все транспорты: спаны приёма стали корневыми, сообщение без контекста открывает свой корень, имена спанов несут назначение. Форма трасс меняется на полутора десятках коннекторов, от Kafka и RabbitMQ до gRPC, SOAP, AS2 и AS4. Очереди seda: и vm: ограничены по умолчанию тысячей, как в Camel. Типизированное чтение заголовка или тела падает на непарсящемся значении вместо тихого значения по умолчанию.

Новое. Коннектор AS4 (eDelivery AS4 1.16 поверх ebMS 3.0) рядом с AS2.

Коллекция из семи шаблонов проектов redb.Templates. Входная аутентификация Basic и Bearer на http:-потребителях и Rest(...).

тут страничка с чего начать

RedbQuery умеет вернуть один объект, количество или да/нет, фильтровать и сортировать по базовым полям.

Полный текст выпуска со всеми ломающими изменениями и ссылками на релизы: redb 4.2.0.

Если было полезно, ⭐ на GitHub поможет другим это найти.

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

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

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

Один рассказывает, что взял на бирже проект компьютерного клуба, нужно на их сайте сделать лидерборд для чемпионата. Сказал, что сделал за несколько вечеров, сейчас не может со своего сервера перенести на их сервер. Говорит, на моем запускается, копирую всю папку, на их не работает. Сейчас с ботом разбираются, в чем проблема. Токены, говорит, уходят влёт! Каждый вечер аккаунты меняет. Другой советует, ты им отдай вместе с сервером, себе новый возьмёшь, первый говорит, у меня там ещё 2 проекта. Думаю, огонь — облачные технологии, кубернетис с неймспейсами!


Дочь, к сожалению, качели недолюбливает, трусиха, быстро расхотела качаться, пожелала лазить по забору, тут уж я трусиха, пришлось идти подстраховывать, а эти кореша продолжили свой бэкенд толкс, аж завидно, я б послушал!!!


Сильно сомнительно, что на этом они много зарабатывают — я б лидерборд без всяких ботов за пару вечеров вкрутил лет 20 назад (когда с качельками проблем не было — у меня в то время вечер заканчивался утром) — и это стоило копейки. Важнее то, что это тоже навык, тоже прокачивается, и при известной доле настойчивости и везения, они быстро научатся зашибать лёгкую деньгу. Тем более у них есть такой хороший инструмент, который туупыые америкосы нахаляву раздают! И никаких тестировщиков, никаких аналитиков, архитекторов, менеджеров — навайбкодил и в продакшон! ))


Мм, лепота!

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

Тестирую недавно вышедшую SOM (system one model) Laya для наделения CanvasDesk сверхсилами по автодополнению.

Как пользователь, я хочу чтобы проектирование в CanvasDesk было с молниеносным флоу. Я решил тестово прикрутить под это Laya - свежий open-source аналог нашумевшего облачного движка Jev от TypeSafe AI.

Почему не обычная LLM? Большие языковые модели для подсказок в реальном времени не годятся их генерация съедает от секунды до трёх. Я бы не стал ждать автогенерацию так долго. Jev и Laya - из класса System One Models: модели "быстрых интуитивных реакций". Они не разворачивают текст токен за токеном, а за один проход решают типизированные задачи: классифицируют, ранжируют варианты и выдают калиброванную вероятность.

Jev сидит в закрытом облаке по API. Laya вышла под Apache 2.0 и полностью совместима с ним по протоколу, но разворачивается локально. Размер ~421 миллионов параметров. Задержка около 33 мс на GPU и 200–450 мс на обычном офисном CPU. Не требует гонять контекст схемы через внешнюю сеть - для CanvasDesk в b2b исполнении это принципиально.

Что это даёт на практике:
1/ автодополнение формул и переменных: набираешь расчёт нагрузки, система цепляет переменные из апстрим-узлов и предлагает формулу, проверенную локальным парсером,
2/ next-node подсказки: поставил шаблон балансировщика - движок предлагает связать его с очередью и пулом воркеров,
3/ адаптация под роль: архитектору - параметры теории очередей, продакту - связки конверсий и когортного LTV.

Задача Laya - работать умным стрелочником: отбирать лучшие паттерны из каталога за доли секунды и отдавать их только при высокой уверенности. Если эксперимент взлетит, сборка схем перестанет быть укладкой асфальта вручную.

Пока заворачиваю Laya в локальный sidecar на базе python. Результаты теста и замеров скорости выкачу отдельным постом.

А пока можно самостоятельно потестить WASM версию CanvasDesk и написать в комментарий про свой опыт

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

Чуваки, я не знаю как вы, но я задолбался от этого бессмысленного бега в колесе.

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

Поэтому я пилю MyTinyIDP — Internal Developer Platform на основе CNCF-подхода, Kubernetes и GitOps.

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

Сервис собирается без ручного написания Dockerfile: Cloud Native Buildpacks определяют стек, собирают OCI-образ и публикуют его в registry, после чего Argo CD доставляет приложение в Kubernetes.

Под капотом — Backstage, Argo CD, Argo Workflows, Argo Events, Crossplane. Открытые компоненты, декларативная модель и минимум привязки к конкретному облаку.

Рабочий прототип уже есть.

Ну, «рабочий» — ну так :) Пока вопросов там больше, чем ответов. Но оно уже живёт, что-то создаёт, что-то деплоит...

Так что если в этом чатике есть люди, которым близки Platform Engineering, CNCF, GitOps и нормальный Developer Experience, и которые тоже считают, что пора перестать в каждой компании заново изобретать собственный DevOps — давайте пилить вместе.

Что будет с монетизацией — пока не знаю.

Зато свой golden path устроим. То есть вдруг есть энтузиасты, пишите, расшарю репо и тд. :)

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

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

Напишем сами. С ИИ за год

После ухода SAP и Oracle компании надеялись, что западные вендоры вернутся. По наблюдению Алексея Телкова, генерального директора «Галактики», сегодня ждать перестали точно все и некоторые перешли на модель «сами напишем». На вайб-коде и за год. Касается это любого корпоративного ПО, которое не хочется менять на продукт российского вендора. 

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

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

Как правильно считать TCO своей разработки и что будет с рынком интеграторов, в пятом выпуске подкаста «IT-фронтир». 

Смотреть на VK Video, Rutube и YouTube.

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

Open-Spec вместо Open-Source

Пытаюсь тут написать сервис полностью по SDD (описываешь спеку и агент генерит по ней код) и такая мысль пришла. Раньше, когда ты хотел показать, что в твоем коде нет закладок или его можно переиспользовать — то выкладывал исходники. А сейчас, по идее, можешь выложить очень подробную спеку и твой сервис по ней пересоберут.

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

Отсюда другая мысль: мы теперь системные аналитики или технические писатели? Ведь по сути анализ (до какой-то границы) можно так же скинуть на агента

Теги:
+3
Комментарии1
1
23 ...