Как подписываются главы крупнейших ИИ‑компаний. На сайте правительства США опубликовали фотографию с подписями руководителей Google, OpenAI, Meta* (* — признана экстремистской и запрещена в России), xAI, Anthropic, Nvidia. Кстати, в документе есть опечатка — не United, а Unites написано.
Помощь от бана 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.
Релизный вебинар - выход Кибер Бэкапа 19
Представим обновление нашего флагманского продукта — системы резервного копирования Кибер Бэкап 19.
В этой версии мы расширили возможности защиты PostgreSQL и СУБД на ее основе, обеспечили интеграции с новыми отечественными системами виртуализации и корпоративных коммуникаций. Также повышена масштабируемость и расширены возможности защиты уже поддерживавшихся отечественных почтовых сервисов. Реализованы интеграции с распространенной системой централизованного ИТ-мониторинга и решениями, обеспечивающими неизменяемость резервных копий. Разработана новая система уведомлений, включающая возможность их отправки в популярный отечественный мессенджер. Кроме того, мы переработали систему лицензирования и внедрили ряд других изменений.
25.10.2026 в 13:00 МСК проведем онлайн вебинар, на котором обсудим следующие темы:
Расширенная интеграция с PostgreSQL и СУБД на ее основе: развитие многопоточности и новые механизмы защиты
Интеграция с VMmanager и снижение нагрузки на сеть при защите ВМ под управлением VMware
Интеграция с RuPost
Развитие возможностей защиты Mailion и Exchange
Повышенная масштабируемость защиты Почты VK WorkSpace
Интеграция с Zabbix, MAX и новая система уведомлений
Интеграция с решением для неизменяемого хранения резервных копий
Новая система лицензирования
Начало закрытого тестирования Кибер Медиасервера
На дворе 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 гораздо больше работы в виде «похоже на что-то страшное», чем в виде действительно новых атак.
Итак, сегодня «ИИ» помогает защищаться от «ИИ», защищает инфраструктуру для «ИИ» и обнаруживает уязвимости, которые «ИИ» же и может помочь эксплуатировать. Ситуация странна своей однобокостью и безальтернативностью, как будто горизонт технологического видения сузился, как у лошади с шорами на глазах. Посмотрим, как все это повернется в течение, скажем, года.
Заставил локальные модели играть в игру MasterMind
Недавно подключил MCP сервер firefox-dev-tools, запустил браузер в специальном режиме (firefox --marionette --remote-debugging-port) и наблюдал за тем как модели отгадывают заганные цвета.
В целом я почти не сомневался в том, что 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 и игровую стратегию и начинай играть.
Конечно такие мелкие уточнения возникли не просто так, часто бывало что модель открывает игру в той же вкладке в которой открыт чат с моделью, и тогда генерация прекращается моментально. Ну и про досрочную победу тоже - было что одна модель после каждой первой комбинации начинала новую игру. В общем попробуйте, напишите свои результаты, если вам такое интересно.
BIS Summit 2026: главное
29 сентября прошёл BIS Summit 2026 — 19-я ежегодная ИБ-конференция. Организатор — Ассоциация по защите деловой информации (BISA) при поддержке InfoWatch.
Тема — «Искусственный интеллект: где граница между прогрессом и угрозой».
Главный вывод: на ИИ наконец начали обращать должное внимание с точки зрения ИБ.
Говорили о практическом применении ИИ, корпоративных рисках облачных и локальных моделей, методиках защиты, которые только создаются, и культуре безопасности.
Пост-релиз — по ссылке.
Новый релиз django-modern-rest@0.16.0
Репозиторий: https://github.com/wemake-services/django-modern-rest
Документация: https://django-modern-rest.rtfd.io
Описание релиза: https://github.com/wemake-services/django-modern-rest/releases/tag/0.16.0
Статья на хабре про суть django-modern-rest: https://habr.com/ru/articles/1017036
Мы выпустили новый релиз. В нем мы значительно ускорили работу фреймворка, улучшили 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=[...])
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)
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: ...
Поддержка library-skills
Установите наши скиллы одной командой:
uvx library-skills --claude # -> .agents/skills/dmr, .claude/skills/...
Делаем разработку с ИИ-агентами - проще!
Буду рад обратной связи в комментах! Какая фича ваша любимая? Чего вам не хватает для следующих релизов?
Как управлять InfiniBand в дезагрегированном инференсе и балансировать ИИ-кластер изнутри? Узнаете на GoCloud Tech 2026
При запуске больших языковых моделей в продакшен инженеры сталкиваются с неравномерной загрузкой GPU и сложностями управления сетью InfiniBand. Дезагрегированный инференс требует точной балансировки нагрузки между узлами, а стандартные инструменты не всегда дают нужный контроль над инфраструктурой.
На докладе разберем, как мы разработали полноценный контроллер для автоматического управления InfiniBand-партициями. Расскажем, как устроен InfiniBand Subnet Manager и как мы написали собственный контроллер поверх него. Покажем архитектуру решения на реальных примерах балансировки дезагрегированного инференса, операций обучения моделей и перераспределения нагрузки.
Спикер:
Денис Добрынин — старший Go-разработчик, Cloud.ru
Трек: Инфраструктура
📅 Когда: 15 октября в 15:50–16:20 мск.
А пока ждете выступление, можете почитать статью из нашего блога о том, как оптимизировать инференс в 2026 году.
Должен ли тимлид быть лучшим разработчиком в команде?
На этом вебинаре поговорили о том, в чем на самом деле заключается ценность тимлида, можно ли эффективно руководить командой, не являясь техническим экспертом, и как решать проблемы, в которых вы сами не разбираетесь.
Инна Пристягина (руководитель развития персонала в PVS-Studio) рассказала о практиках хорошего тимлида, но плохого тех.эксперта. Разобрала, почему неумение лично выполнять задачи команды — не слабость руководителя, а вполне осознанная и эффективная модель работы.
Александра Бутузова (TeamLead кросс-функциональной команды в F.Doc) разобрала, как решать проблемы как тимлид. Ведь лидеру регулярно приходится сталкиваться с задачами и ситуациями, в которых он не является экспертом. Как действовать в таких случаях и в чем заключается истинная ценность работы руководителя — обсудили на вебинаре.
Посмотреть можно тут:
▫️ YouTube
▫️ VK Video
▫️ Rutube
▫️ Наш сайт
Приятного просмотра! 😉
Ссылка на одного участника в Telegram — ещё не персональный доступ
Представим закрытый канал: бот подтвердил оплату и выдал покупателю ссылку с member_limit=1. Кажется, что схема защищена: один платёж — один участник. Но лимит не проверяет, кто именно вступает.
По документации Telegram, member_limit ограничивает число пользователей, которые могут одновременно состоять в чате, вступив по этой ссылке. Это не привязка к Telegram ID покупателя и не гарантия одного использования за всё время.
Пример: Анна оплатила доступ и переслала приглашение Борису. Борис вступил первым. Лимит соблюдён, но доступ получил другой аккаунт. Даже если ссылка действует пять минут, переслать её можно за несколько секунд.
Здесь речь об обычных приглашениях, когда доступом управляет бот. Нативные платные ссылки Telegram Stars — отдельный механизм.
На мой взгляд, проверять нужно право конкретного пользователя на вход. Приглашение позволяет подать заявку, а решение принимается по актуальным правам аккаунта.
Для обычных chat_join_request без query_id схема такая:
Бот создаёт ссылку с creates_join_request=True, без member_limit: эти параметры нельзя использовать одновременно.
При получении заявки берёт chat.id и from.id, проверяет действующее, не отозванное право пользователя на конкретный чат.
При положительном решении вызывает 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. Дополнительная модель прав становится полезной, когда продукт объединяет несколько чатов и тарифов.
Отсюда вопрос: как вы организуете приглашения, отдельной ссылкой на каждого получателя или общей ссылкой с проверкой каждой заявки? Какие различия заметили в аудите восстановлении доступа?
Представлен открытый проект netboot.xyz — универсальный установщик netboot на Jinja. Проект работает так:
установить программу на флешку.
далее установщик подключит ПК к интернету и предложит установку нужной системы.
на выбор есть Linux, Windows 7/8/10/11, Fedora и другие ОС
дальше проект скачает и установит чистую систему.
Итоги 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 млрд писем. Письмо проходит несколько уровней проверки, и большая часть спама отсеивается на первых из них. Поэтому тяжелые модели запускаются не для каждого письма, и инфраструктуру не приходится наращивать. Компании с закрытым контуром получают обновления через выделенный буфер, и сам контур в интернет не выходит.
Что дальше
Мы планируем глубже встроить агентов в сервисы, добавить сценарии для групповых чатов и выпустить готовых цифровых сотрудников, которых не нужно настраивать.
Скролл без костылей — что уже умеет 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-примеры и разобрать типичные ошибки, читайте полное руководство в блоге Рег.облака.
Забирай наборы скилов, гайды, воркфреймы и другие материалы от гаражистов!
Весь прошлый месяц мы собирали рабочие файлы для разработчиков, дизайнеров, аналитиков, маркетологов и менеджеров.
В ней тебя уже ждут инструменты, которые сделали специалисты Garage Eight для себя и своих команд. Теперь ты тоже можешь бесплатно скачать любой из них и начать применять в работе.
Прикручивал свой diff к git и прошелся по граблям
Я пишу небольшую утилиту datadiff на Rust. Она разбирает два файла JSON, YAML, CSV, TOML или XML и сравнивает получившиеся деревья, поэтому переставленные ключи и переформатирование ее не волнуют. Изменения она печатает путями вроде spec.replicas: 3 → 5. Долго это была отдельная команда, про которую надо было вспомнить, так что я решил встроить ее прямо в git diff. Первой версией была строчка в README: шелл-функция, которая из семи аргументов, передаваемых git внешнему драйверу, брала второй и пятый (там лежат старая и новая версии файла). Работало, пока не попался первый кривой файл.
Оказалось, 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 занимает три строки.
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.
Способность понимать что и зачем ты делаешь становится, наверное, самой важной в эпоху ИИ. Работой специалиста теперь становится сомнение и понимание моментов времени, в которых это сомнение нужно, а где наоборот излишне - системное критическое мышление. Позволю себе немного пространных мыслей ))
Никогда не думал, что навыки целостного анализа музыкальных форм, приобретенные в музыкальном училище и отшлифованные в консерватории настолько будут полезны. В музыке тебя учат видеть произведение на нескольких уровнях одновременно: на уровне такта, мотива или интонации, музыкальной темы, периода (обычно 8+ тактов), раздела музыкальной формы, всей формы в целом, части произведения (разные части сонаты, симфонии или концерта написаны в разной музыкальной форме), и иногда - в рамках "большой формы" - несколько симфоний складываются в общий цикл. Твой взгляд приучается видеть тонкие сети взаимосвязей внутри музыкального организма, восстанавливать причинно-следственные связи: почему тот или иной мотив появился именно здесь? Какая история его развития? Как он менялся? От чего шёл и к чему пришёл? И что интересно - куда идёт?
И, на удивление, то же самое происходит на уровне выстраивания любых инженерных процессов. А именно этим сейчас становится разработка, программирование. Она и раньше было этим выстраиванием. Но со скоростью, которую даёт хороший ИИ - теперь это основная деятельность. То же происходит и в бизнес-процессах в целом. Те, кто почувствовал мощь и вкус ИИ как инструмента принялись за самое сложное: формализацию своей работы. Как ты работаешь? Что ты должен получить здесь и сейчас? Как проверить, что это действительно то, что тебе нужно?
С учётом больших скоростей из-за ИИ важно смотреть вдаль. Как за рулём автомобиля на трассе: чем выше скорость, тем дальше нужно смотреть вперёд.
Как применить одну функцию к нескольким колонкам, не перечисляя их в 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 │ └────────────┴────────────┴────────────┘
Несколько нюансов:
Правила вызова пишутся в круглых скобках. Синтаксис такой: APPLY(имя_функции) без аргументов.
Передаваемая функция в APPLY должна уметь работать со всеми полями выборки и их типами данных. Например, для sum все поля должны быть числовыми.
Если мы хотим применить sum, но в таблице есть нечисловые типы данных, мы можем исключить их через EXCEPT или выбрать только нужные через модификатор COLUMNS, о котором я расскажу в следующем посте.
APPLY можно использовать не только для агрегации, но и для изменения типов данных. Например, APPLY(toString) быстро переведет все выбранные колонки в строковый формат.
Ссылка на доку.
Мои статьи по ClickHouse на Хабре.
P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».
Можно ли получить от агента надёжный результат, не спроектировав для него работу? Судя по тому, как мы с агентами работаем, многие на это рассчитывают.
Мы научились писать агентам промпты и учимся принимать у них результат. А проектировать для них работу так и не начали. Поэтому ошибки повторяются от эксперимента к эксперименту и не исчезают ни с новой моделью, ни с более длинной инструкцией. Ниже — почему так происходит и три принципа, которые можно взять на вооружение, когда проектируете работу для агента.
Когда появились компьютеры, работу для них не стали описывать так же, как для служащих. Машина не понимает замысла, поэтому появились алгоритмы: работу пришлось описывать так, как её способен исполнить новый исполнитель.
Для людей своя дисциплина сложилась задолго до этого: регламенты, квалификация, руководитель, последствия. Она работает, потому что человек понимает смысл правил и меняет поведение после оценки.
Агент — третий тип исполнителя. Он интерпретирует ситуацию, как человек, но без норм, опыта и последствий, которые человек приносит с собой.
Поэтому ни один из подходов проектирования не подходит для агента. Подробнее почему — в статье «Почему AI-агент не цифровой сотрудник».
Посмотрите, как в статьях об агентах разбирают их ошибки. Агент выдал неприемлемый результат, и дальше обсуждается, как такую ошибку поймать и кто за неё отвечает. Вопрос, можно ли было устроить работу так, чтобы этой ошибки не было, почти не возникает.
Хотя с такими ошибками можно разобраться раньше, ещё при проектировании: часть исключить, а остальные ловить там, где это проще. Для этого работу нужно проектировать с учётом того, что агент интерпретирует информацию. Три принципа ниже — об этом.
Проектируйте от работы, а не от агента. Сначала определите, какую ошибку вы не готовы принять и после какого действия её уже не исправить. Только потом решайте, что поручить агенту.
Решите, что агенту не нужно интерпретировать. Всё, что можно установить независимо, передайте ему уже подтверждённым. Интерпретацию оставьте там, где ради неё агент и нужен.
Определите, как примете результат, до запуска и отдельно от агента. Когда критерии приёмки известны заранее, работа для агента проектируется точнее, а результат принимать проще.
Почему, на ваш взгляд, работу для агентов почти не проектируют: не знают как, не видят смысла или ждут, что следующая модель справится сама?
Стратегия голубого океана в сопровождении
Сегодня – история о применении книги «Стратегия голубого океана» в сопровождении клиентов. Тут можно сразу и Стивена Кови с его «Третьей альтернативой» упомянуть – подходы схожие.
Итак, стратегия голубого океана – про то, что искать новые рынки надо не вширь, создавая новые продукты, а вглубь, слушая клиента и его потребности. Там и скрыт голубой океан – никем не занятый рынок.
Помимо чтения книг, я ещё и работаю – руковожу отделом программистов 1С. Занимаемся, в том числе, сопровождением – у клиента есть ПО, которым он пользуется, и периодически нужна помощь, доработки, настройка, устранение ошибок и т.д.
Когда я пришёл в этот бизнес, сопровождение работало так. За клиентом был закреплён менеджер, который умел разговаривать, но ничего не понимал в 1С и учёте. Клиент звонил менеджеру, говорил задачу, менеджер искал программиста. Бывало, находил быстро. Иногда искал пару дней. Случалось, не находил вообще. Программисты менеджеру не подчинялись, связи были только горизонтальные.
Пока менеджер искал программиста, клиент, скажем так, негодовал. Особенно если задача – срочная. Бывало так негодовал, что звонил директору. Некоторые клиенты отваливались – кто со скандалом, кто молча.
Если менеджер находил программиста, то для клиента начинался новый квест – всё объяснить человеку, который ничего не знает о бизнесе и особенностях клиента. В сопровождении 1С, к сожалению, очень важно знание местности, людей, процессов. Но делать нечего, клиент как-то объяснял, задача как-то решалась. Чтобы в следующий раз опять получить незнакомого программиста и пройти путь заново.
Клиенты просили – закрепите за нами программиста, блин. Надоело каждый раз объяснять. Собственно, клиента достаточно было услышать – он принёс голубой океан с собой, на тарелочке. Но кто ж его слушать-то будет – это всего лишь клиент, что бы он там понимал в нашем-то бизнесе.
Всё, что сделал я – услышал клиента. Так вышло, что я несколько лет работал на его стороне, в бизнесе, и приходилось выстраивать внутреннее сопровождение. Там проблемы незнакомого специалиста нет в принципе. Зато есть ответственность – если ты плохо сделал, то тебе же и переделывать.
Я придумал отдельную оплачиваемую роль – продюсер клиента. Что важно – это был именно программист, а не менеджер. Эдакий маленький ИТ-директор на аутсорсинге. Продюсер пропускал через себя все задачи клиента (большинство решал сам), быстро вникал во все его особенности, поэтому знал, как там всё устроено. Часть задач раздавал другим программистам, контролируя исполнение.
Клиент получил то, что просил. Человека, который постоянно с ним. Программиста, а не менеджера – существенная часть вопросов стала решаться сразу, в разговоре, а не «мы вам перезвоним». Постоянную команду специалистов, управляемую продюсером. Ну и ответственность, наконец-то – продюсер отвечает за решение всех задач клиента (за это и деньгу получает).
Просто же, согласитесь? Но это тоже голубой океан.
Это история применения книги из Книжного стека.