Представлен открытый ИБ-проект bumblebee от команды Perplexity для защиты ПК на Linux и macOS:
проверяет файлы, установочные сборки, библиотеки, фреймворки
сканирует пакетные менеджеры, плагины для IDE, браузерные расширения, конфиги Claude, Cursor, Coder и других ИИ‑инструментов.
сканирует метаданные.
Решение конфликта «пешеход vs самокат» на тротуаре без стройки и денег.
Проблема: Пешеход идёт медленно, смотрит в телефон, может резко повернуть. Самокат едет быстро и бесшумно → появляется сзади → пугает → авария.
· Пешеходы → правостороннее движение. · Самокаты → левостороннее движение.
Что даёт: Пешеход видит самокат спереди, а не со спины. Даже если тупит в телефоне то боковым зрением замечает. Время среагировать есть.
Почему это почти рабочее правило:
· Не нужны миллиарды, разметка, камеры. · Всего два простых пункта:
Держись своей стороны.
Самокат едет навстречу пешеходу, а не догоняет сзади.
Главное ограничение (честно): Самокат всё равно быстрее. Но теперь хотя бы ты его видишь. Пешеходу понятно, самокатчику тоже (он знает, что его ждут спереди).
Итог: Правило не идеальное, но лучше, чем сейчас. Внедрить можно хоть завтра через памятки и привычку. Главное: не ездить рядом с бордюром.
llm-nano-vm v0.8.0 — выход в PyPI, валидация вывода и per-step таймауты
В прошлом посте мы описывали концепцию nano-vm — детерминированного ядра исполнения на базе конечных автоматов (FSM) для LLM-воркфлоу, где модель не является оркестратором, а лишь предлагает действия внутри жесткого графа \delta(S, E) \to S'.
За это время проект перерос стадию концепта. Мы опубликовали рантайм на PyPI и выпустили релиз v0.8.0. Ниже — сухой отчет о том, что конкретно было сделано, измененено и протестировано.
Что нового в v0.8.0
1. Выход на PyPI и релиз пакетов
Рантайм и сопутствующие компоненты полностью изолированы и доступны для установки:
pip install llm-nano-vm==0.8.0 pip install llm-nano-vm[litellm]==0.8.0 # поддержка провайдеров через LiteLLM pip install nano-vm-mcp # MCP-шлюз
2. allowed_outputs — LLM enum guard
Добавлена жесткая валидация сырого вывода модели по белому списку до того, как значение попадет дальше в пайплайн.
{ "id": "classify", "type": "llm", "prompt": "Classify. Reply ONLY with: refund / query / other", "allowed_outputs": ["refund", "query", "other"], "on_error": "skip", # → подставит "refund" (первый элемент) на mismatch }
Реализовано три политики обработки ошибок: fail (trace \to FAILED), skip (подстановка allowed_outputs[0]) и retry (перезапрос модели до max_retries).
3. timeout_seconds + on_timeout — таймауты на уровне шага
Решена проблема «зависания» внешних LLM API. Любой llm-шаг теперь можно ограничить по времени выполнения с политиками fail или fallback (подстановка дефолтного значения без падения автомата).
4. Стабилизация ASTEngine
Мы окончательно избавились от eval() для условий (condition). Написан кастомный песочный интерпретатор JSON AST. Любые системные вызовы и скрытые вызовы методов (вроде .lower()) теперь вызывают ASTEvalError на этапе компиляции графа.
Результаты бенчмарков (v0.8.0 · WSL2 · Python 3.12)
Тесты производительности на синтетическом адаптере (3 провайдера \times 5 сценариев \times 10k итераций) показали 1,096,500 операций и 0 нарушений контракта графа.
СценарийСредний TPSp95Refund pipeline2,200/s123 msDouble-execution guard2,800/s69 msBudget enforcement2,400/s97 msParallel throughput1,000/s196 msGovernanceEnvelope (аудит-лог)2,100/s108 ms
Crash consistency (BM-INT-07): При crash_rate=100% повторное воспроизведение (replay) пайплайна после симулированного падения рантайма выдает идентичный хэш трейса в 100% случаев.
Memory leak test (BM-INT-10): Пиковый RSS — 76.5 MB, аллокация — 3.62 MB для программ на 1000 шагов. Утечек памяти нет.
Валидация на реальных платежных API
Концепт успешно проверен на двух интеграционных сценариях (9/9 тестов пройдены):
MoMo Payment API v4: 3-way ветвление, HMAC-SHA256 IPN верификация, цикл пуллинга статуса с ретраями.
Stripe Payment API v1: Обработка 3DS-флоу (REQUIRES_ACTION), refund-пайплайн и верификация вебхуков.
В процессе интеграции со Stripe пофиксили важный баг: коллизию доменного статуса "PENDING" от API Stripe с внутренним сентинелом рантайма, который триггерил заморозку (SUSPEND) автомата.
Текущий фокус и краткосрочный роадмап
Phase 0: Разработка ProgramValidator для статического анализа графов до их выполнения (поиск циклов, недостижимых шагов и битых таргетов). Актуально, когда сами программы генерируются «на лету» внешними моделями.
Phase 1: Консистентность шлюза. Перенос StateContext между вызовами MCP в SQLite WAL (execution_contexts + UPSERT на каждый шаг). Это полностью уберет риск повторного списания (Double-Spend) при перезапуске процесса шлюза.
Phase 2: Интеграция OpenTelemetry для распределенного трассирования шагов.
Репозитории проекта:
Core runtime: github.com/Ale007XD/nano_vm
MCP layer: github.com/Ale007XD/nano-vm-mcp
Дилемма:
1. Раньше, когда кто-то патчил уязвимость в ПО с открытым исходным кодом, разработчик мог попытаться вполне успешно скрыть факт устранения уязвимости. А сегодня агент может посмотреть pr и нет-нет да и сообразить, насколько уязвимы машины, не установившие последний патч(все машины)
2. Но ведь существует и другая проблема - активно разрабатываемый(особенно новейший) софт всегда добавляет всякие уязвимости из-за вайбкодеров сегодня. Не только из-за вайбкодеров, проблема существовала и раньше, стойкое недоверие к самому последнему патчу постепенно развивается у некоторых людей. Лучше всего тренируется на arch linux* или любом другом rolling release distro. Nvim, если все патчи подгружать, как только они появляются, тоже помогает с этим. Взаимодействие с результатами бесплатной децентрализованной разработки с самыми разными мотивациями, квалификациями и интересами - это вот самый топ обучения, наверняка те, у кого это приводит к supply chain attack особенно квалифицировались.
Выход: ограничить использование нового софта без достаточной контейнеризации, при этом не торопиться за самым последним обновлением всего и вся. Пользоваться в основном, а лучше исключительно только проверенным боями ПО.
Возможно это неочевидно многим, потому что индустрия ушла от понимания к запоминанию, от мастерства к экспертности, от любопытства к курсам.
Не знаю, чему там "этично" сегодня учат на инфобез курсах, но есть много вещей, о которых как бы нельзя говорить, и это скорее всего будет закреплено на законодательном уровне, потому что политиков пугает возможность роста количества подозреваемых.
*Это не в огород арха. Arch linux у джуна всегда был зелёным флагом - человеку интересно, и отговорить можно. А вот если это миддл, то надо сначала выяснить, каким образом он его гоняет. Без раскрытия деталей, по умолчанию страшно с таким человеком работать
Что не так с DeFi и почему там до сих пор происходят взломы
Со стороны DeFi выглядит как будущее финансов: кошелёк вместо банка, смарт-контракт вместо посредника, а код вместо правил “по договорённости”.
Но в реальности DeFi это не одно приложение, а связка протоколов, смарт-контрактов, пулов ликвидности, оракулов, мостов, токенов управления и внешних интерфейсов. Пользователь видит кнопку Swap или Deposit, но под капотом может запускаться целая цепочка вызовов между контрактами. И чем больше таких зависимостей, тем больше поверхность атаки.
Одна из главных проблем - composability. В DeFi протоколы часто строятся друг поверх друга: lending-протокол использует один токен, DEX даёт ликвидность, оракул поставляет цену, мост переносит актив между сетями, а поверх всего этого работает ещё один интерфейс. Это удобно для разработки, но опасно для безопасности. Ошибка в одном элементе может стать проблемой для всей цепочки.
Отдельный риск - смарт-контракты. В традиционной системе подозрительную операцию можно остановить, откатить или вручную проверить. В DeFi логика другая: если транзакция валидна и контракт позволяет выполнить действие, сеть его выполнит. Поэтому баг в коде, ошибка в проверке прав, неправильная работа с балансами или уязвимость в математике протокола могут стоить не “небольшого сбоя”, а сразу миллионов долларов.
При этом атаки давно не сводятся к классическому “взлому”. Часто злоумышленник не ломает сервер, а использует экономическую механику протокола. Например, через flash loan можно взять огромный объём ликвидности в рамках одной транзакции, временно исказить цену в пуле, повлиять на расчёт залога или ликвидации, а затем вернуть заём до завершения блока. Формально всё может пройти по правилам контракта, но результат будет разрушительным.
Большая зона риска - оракулы. DeFi-протоколам нужно откуда-то получать цены активов. Если протокол берёт цену из слабого источника, например из тонкого пула с низкой ликвидностью, этой ценой можно манипулировать. Дальше начинается цепочка: неверная цена → неправильная оценка залога → ошибочная ликвидация или вывод средств.
Ещё одна больная точка - кроссчейн-мосты. Мосты соединяют разные сети и часто хранят или контролируют большие объёмы ликвидности. Это делает их идеальной целью. Проблема в том, что мост должен одновременно доверять событиям в одной сети и корректно выпускать или разблокировать активы в другой. Любая ошибка в валидации сообщений, подписях, мультисиге или логике relayer-ов может привести к катастрофе.
Есть и governance-риск. Многие DeFi-протоколы управляются через DAO и governance-токены. На практике это означает, что изменение параметров протокола, обновление контрактов или управление казной может зависеть от голосований, делегатов и концентрации токенов. Если управление плохо защищено, атакующий может повлиять не на код напрямую, а на правила игры.
Парадокс DeFi в том, что он создавался как trustless-система, где не нужно доверять посредникам. Но на практике пользователь всё равно доверяет: аудитам, разработчикам, оракулам, мостам, мультисигам, фронтенду, governance-механике и экономической модели протокола.
То есть доверие не исчезло. Оно просто переехало из банка в инфраструктуру.
Именно поэтому DeFi до сих пор остаётся одновременно самой интересной и самой уязвимой частью крипторынка. Чем больше открытости, автоматизации и связности между протоколами, тем сложнее сделать систему безопасной не только на уровне кода, но и на уровне экономики, ликвидности и пользовательского сценария.
Как ИИ помогает разобраться в незнакомом проекте
Наверное, почти у каждого была ситуация, когда нужно срочно погрузиться в новую тему или проект. Десяток ссылок, документы, репозиторий, записи встреч — по отдельности информации вроде немного, но между ней постоянно приходится переключаться и самостоятельно собирать общий контекст.
В итоге время уходит не на саму задачу, а на попытки понять, что вообще происходит и с чего лучше начать. Один из способов упростить погружение в новую тему — использовать ИИ.
Можно дать ИИ репозиторий, документ или ссылку и попросить:
объяснить, о чем проект;
рассказать, какие технологии используются;
подсказать, с чего лучше начать изучение.
Например: «Я junior-разработчик. Объясни, что делает этот репозиторий и какие технологии здесь используются».
Если сразу указать свой уровень подготовки и задавать уточняющие вопросы по ходу диалога, за 15–20 минут можно получить гораздо больше понимания темы.
Передача параметров ssh с помощью суффиксов имени хоста
В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).
Host tproxy Hostname srv-10-79.dmz.company.com User srv_user Port 36602 DynamicForward 127.10.0.79:1080 LocalForward 127.10.0.79:4445 127.0.0.1:445 LocalForward 127.10.0.79:8080 127.0.0.1:8080
У этой рекомендации есть один существенный недостаток — она не обеспечивает модульность конфигурации и вынуждает дублировать информацию. В случае, если требуется обеспечить подключение к тому же серверу из интернета через NAT или через SSH-прокси, или без SOCKS5-прокси и переадресации портов, причём во всех возможных комбинациях:
изнутри с переадресацией портов,
изнутри без переадресации портов,
снаружи с перадресацией портов,
снаружи без переадресации портов,
для данного сервера придётся добавить ещё три секции Host, часть сведений в которых будет дублироваться. Если же компания подключилась к двум провайдерам и сэкономила на маршрутизации BGP, понадобятся уже шесть частично дублирующих друг друга секций Host. Дублирования сведений, как известно, желательно избегать, и для этого следует каким-либо образом доработать исходную рекомендацию.
Сущность предлагаемой доработки
Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.
В случае, если суффикс должен добавлять параметры, специфичные для определённого хоста, например, его реальное имя DNS, или параметры переадресации портов, в которых фигурирует адрес локального сокета, индивидуальный для каждого из хостов, команда Match должна будет содержать два аргумента originalhost: один — с шаблоном имени хоста, и второй — с шаблоном суффикса. Пример:
Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*" # Подключение через РостелеТелеком (NAT) Hostname srv-10-79.rtk.company.com Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*" # Подключение через Yota ProxyJump gate-10-1+yota Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*" DynamicForward 127.10.0.79:1080 LocalForward 127.10.0.79:4445 127.0.0.1:445 LocalForward 127.10.0.79:8080 127.0.0.1:8080
За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:
Match originalhost "tproxy,tproxy+*" Hostname srv-10-79.dmz.company.com User srv_user Port 36602
В случае, если добавляемые суффиксом параметры не содержат специфических для хостов аргументов, в команде Match достаточно указать один аргумент originalhost с шаблоном суффикса. Такие секции следует располагать в самом конце файла настроек ssh.
Match originalhost "*+rsa,*+rsa+*" HostKeyAlgorithms +ssh-rsa PubkeyAcceptedKeyTypes +ssh-rsa
В мире ещё пару лет назад жило 1.2 миллиарда людей (теперь их больше) с психическими расстройствами, согласно исследованию, опубликованному в журнале Lancet. В принципе, я всегда что-то подобное подозревал.
https://www.eurekalert.org/news-releases/1128514
https://edition.cnn.com/2026/05/21/health/mental-disorder-rate-worldwide-study-wellness
Это число удвоилось за 36 лет. А вот число людей вообще — выросло всего в полтора раза. «Тен-ден-ци-я, однако!»
С 13 по 22 мая на Инфостарт Бирже заказов появились новые задачи для 1С-специалистов: доработки типовых конфигураций, внешние печатные формы, автоматизация скидок, работа с документами и проекты с использованием ИИ.
Собрали часть актуальных заказов, которые можно взять в работу.
Новые задачи недели
Шаблоны претензий и писем-уведомлений в 1С Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.195.40);
Доработка «Счет на оплату покупателю с QR кодом для Управление торговлей, редакция 11 (11.5.17.201);
Доработка «Стоимость материалов и работ по ресурсной спецификации»;
Заказы, которые еще доступны
Заказ по статье «Векторный поиск в 1С без облаков: локальный AI-сервис для прайсов поставщиков»;
Апгрейд 1С УТ 11.5 до 1С: Управление торговлей и взаимоотношениями с клиентами (блок CRM)»;
Инфостарт Биржа заказов — площадка для поиска исполнителей под задачи по 1С: от небольших доработок до проектной разработки и внедрений.
Для заказчиков доступны прямой обмен контактами, работа без комиссии, рейтинги исполнителей и безопасная сделка по желанию.
Как мы превратили приложение в SaaS-платформу с IoT-доступом и увеличили выручку клиента в 7 раз
Рынок self-storage в США и России растет: все больше частных клиентов и компаний используют складские ячейки для хранения личных вещей и товаров. Вместе со спросом на услугу растет и запрос на цифровые инструменты для управления арендой.
Именно с такой задачей к разработчикам Doubletapp пришел американский клиент — владелец сети складов. Ему нужно было мобильное приложение, в котором клиенты могли проверять, какие ячейки за ними числятся и оплачивать аренду.
В процессе совместной работы мы увидели, что запрос клиента шире, чем создание только мобильного приложения, и в результате проект вырос в вертикальную SaaS-платформу с собственной IoT-инфраструктурой, которая стала новым источником дохода для бизнеса.
Расскажем поэтапно, как развивали проект.
Бизнес-задача
На старте у клиента были типичные ограничения рынка:
низкая конверсия в аренду
высокая нагрузка на персонал
отсутствие единой цифровой системы
зависимость от legacy-бэкенда.
Фактически задача — поднять выручку и снизить операционные затраты.
Быстрый запуск и проверка гипотез
Мы начали с MVP, чтобы не инвестировать в сложную архитектуру без подтверждения спроса. Запустили базовый пользовательский сценарий управления арендой:
продление доступа, прием платежей
уведомления о статусе оплаты
история операций.
Использовали WebView для платежей, чтобы не тормозить запуск из-за legacy-ограничений.
Результат — подтвердили спрос и получили первые пользовательские данные.
Полный цифровой цикл аренды
Следующий шаг — увеличить конверсию и сократить путь пользователя. Мы перенесли весь процесс аренды в приложение:
выбор локации и юнита
бронирование
подписание договора
оплата.
И на этом этапе переработали клиент-серверное взаимодействие, чтобы уйти от WebView и внедрить нативные платежи.
Переход к платформенной модели
На этом этапе продукт начал масштабироваться за пределы одного клиента — заказчик предложил другим операторам рынка подключиться к нему формате white-label. Мы спроектировали платформу, которая позволяет подключать разные storage-компании.
Внутри платформы каждый участник использует индивидуальный брендинг, UI, контент и настройки, а данные сохраняются и обрабатываются изолированно.
По сути мы превратили приложение в SaaS-продукт, и это стало новым каналом роста бизнеса для клиента.
IoT-инфраструктура и NFC-доступ
Самый технологически сложный блок — интеграция с физическими замками для ячеек. Клиент приобрел готовые платы и поставил команде задачу — обеспечить безопасный и контролируемый доступ к оплаченным ячейкам через приложение.
Т.к. приложения у нас были кроссплатформенные, а SDK для Flutter не существовало, к работе подключились iOS и Android-разработчики. Мы создали собственную Flutter-библиотеку, а взаимодействие с железом реализовали на нативной стороне.
Подробнее о разработке читайте в кейсе.
В итоге у пользователей отпала необходимость в физических ключах, а бизнес получил непрерывный автоматизированный контроль доступа к складским ресурсам.
Приложение для операционных команд
После внедрения электронных замков у менеджеров, управляющих доступами к ячейкам, появились новые задачи и новые инструменты. Все их мы вынесли в отдельное приложение.
Функционал:
настраивать замки
отслеживать оплату
управлять объектами в реальном времени.
Приложение снизило операционную нагрузку и ускорило выполнение рутинных задач за счет автоматизации.
Что в итоге получилось
Мы подключились для разработки приложения, а в итоге решили более глобальную задачу — превратили операционный бизнес в технологическую платформу с масштабируемой моделью роста.
Цифровизировали офлайн-процессы
создали платформу вместо продукта
интегрировали software + hardware
обеспечили рост через SaaS-модель.
Если у вашего бизнеса есть:
физическая инфраструктура (склады, парковки, недвижимость)
повторяющиеся операции
потенциал масштабирования через платформу — давайте обсудим вашу задачу.
Приглашаем вас на бесплатный экспресс‑курс для технических специалистов «ИИ в корпоративной автоматизации».
Курс посвящен практическому применению современных ИИ‑технологий в корпоративной автоматизации: LLM, ИИ‑агентам, MCP, интеллектуальной обработке документов (IDP) и гибридным сценариям совместно с RPA.
За 3 академических часа участники получат системное представление о том:
— где достаточно классического RPA, а где необходимы LLM и агенты;
— как проектировать гибридные сценарии автоматизации;
— как работают MCP и современные ИИ‑агенты;
— как строить надежные промпты для корпоративных задач;
— чем отличаются OCR, VLM и IDP‑подходы;
— как выбирать технологию под конкретный бизнес‑процесс.
Курс сочетает теорию с практическими демонстрациями и ориентирован на реальные корпоративные кейсы.
Для кого: бизнес‑ и системные аналитики, RPA‑разработчики, архитекторы решений, специалисты по цифровой трансформации и внедрению корпоративных систем. Также курс подойдет тем, кто сталкивается с задачами интеграции LLM, интеллектуальной обработки документов, ИИ‑агентов и гибридных сценариев автоматизации, но хочет получить системное понимание технологий и практических подходов к их применению.
Требования к слушателям: базовые технические навыки, приветствуется опыт работы с корпоративными системами автоматизации, понимание API и HTTP‑запросов.
04 июня, 11:00–14:00, онлайн, бесплатно, требуется регистрация.
Битва за Интернет переходит в реальный мир
Виртуальные бои с взаимной блокировкой сайтов и сервисов перешли в реальный мир. Евросоюз изучает возможность проложить оптические магистрали в Азию через Арктику. Почему не хватило текущей надёжности Интернета, который разрабатывался как сеть, способная сохранить работоспособность после ядерной войны?
Азия и Ближний восток: риски и возможности
Вместо локальной системы связи для одной страны Интернет стал глобальной сетью. При этом магистральные каналы прокладывались не равномерно, а там, где удобно. В результате оказалось, что большая часть магистральных каналов между Европейским союзом и Китаем, Индией и другими важными партнёрами из Юго-Восточной Азии проложена через Россию или Ближний Восток.
В 2024 году в Красном море Йемен повредил четыре подводных кабеля в Красном море. А уже в этом году Иран угрожал блокировать не только Ормузский пролив, но и интернет-каналы, проходящие у его берегов. Так как долговременное примирение геополитических противников никто не гарантирует, ЕС задумался над прокладкой кабелей через арктический регион.
Трафик через полюс
У Европы два варианта прокладки интернет-кабелей — через Северо-Западный проход. Аналог Северного морского пути в обход Канады и Аляски по Северному Ледовитому океану. Однако придётся решать вопросы работы в сложных ледовых условиях. Есть опыт многомесячных перерывов в ремонте интернет-магистралей, находящихся в подобных условиях. Альтернатива — не проще: проложить кабели непосредственно через Северный полюс.
Кажется, что в таких условиях получат новые возможности спутниковые сервисы связи. Однако в текущей ситуации захочет ли Европа зависеть от американских компаний? А OneWeb вряд ли потянет полноценную связь регионов. Часть коммерческой нагрузки может взять на себя сервис спутниковой связи IRIS, основное назначение которого — связь для европейских госструктур и силовиков.
В любом случае реализация обхода через Арктику намечена к 2030 году. За 5 лет может ещё всё измениться.
ИТ-компаниям приходится учитывать не только требования локальных регуляторов, но и геополитику, чтобы готовиться к сложностям с доступностью электронных компонентов и каналов связи. К сожалению, на это уходят ресурсы, и приходится прикладывать дополнительные усилия, чтобы это не сказывалось на пользователях.
Как прокачаться во frontend-разработке на React?
Во фронтенд-разработке мало просто сделать красиво. Важно, чтобы всё работало без багов, а интерфейс вел себя предсказуемо, чтобы человек не тратил время на изучение, что и как нажимать. Для этого нужны навыки работы с кодом и понимание того, как устроен интерфейс и как собрать его в одну систему.
Постепенно появились инструменты, которые упростили эту работу. И один из главных — React. Его используют в самых разных проектах, от небольших сервисов до крупных продуктов. К тому же, во многих командах он стал базовым инструментом.
Кстати, разработчикам, которые умеют работать с React, обычно проще искать работу и получать повышения, а у нас на Хабр Карьере как раз собраны курсы, которые помогают освоить этот востребованный на рынке стек.
Вот технологии и навыки, которые вы освоите на курсах:
— React. Создаем интерактивные пользовательские интерфейсы.
— TypeScript. Расширяем возможности работы с JavaScript.
— Playwright. Автоматизируем тестирование веб-приложений.
— Redux Toolkit. Делаем разработку более лаконичной и удобной.
— Рефакторинг. Улучшаем структуру и архитектуру кода.
Привет! На связи QA-сообщество 2ГИС. Пробуем ввести новую рубрику — регулярные новости из мира разработки и тестирования. И вот первый дайджест свежих релизов.
PEP 831 — “Build CPython with Frame Pointers by Default”
Новый PEP предлагает включить frame pointers по умолчанию во всех сборках CPython. Это обеспечит корректные стеки вызовов для профайлеров, дебаггеров и eBPF‑трейсинга без необходимости пересобирать Python вручную.
→ https://peps.python.org/pep-0831/
Playwright 1.60
HAR‑запись теперь доступна напрямую через tracing.startHar() / stopHar(), появился locator.drop() для эмуляции drag‑and‑drop, а также новый метод test.abort() для мгновенного прерывания теста.
→ https://playwright.dev/docs/release-notes#version-160
TestRail 10.3.1
Вернулся тёмный режим, добавлен AI Evaluation Template с дашбордом Quality Insights — теперь можно оценивать качество LLM‑функций не только «проходит/падает», но и по показателям эффективности, безопасности и любым другим метрикам, которые нельзя привести к бинарному результату.
→ https://support.testrail.com/hc/en-us/articles/48316772215956-TestRail-10-3-1-Default-1009
Chrome DevTools 148
Теперь по умолчанию отобржается полное дерево доступности (Full accessibility tree), добавился новый раздел Crash report в Application, в Network появилась новая колока Request order (показывает порядок запросов).
→ https://developer.chrome.com/blog/new-in-devtools-148?hl=en
tox 4.54.0
В релизе добавлен экстра tox[testing] для легкой установки зависимостей плагина tox.pytest, плюс исправлены погрешности в TOML‑схеме для таблиц replace.
→ https://tox.wiki/en/latest/changelog.html#v4-54-0-2026-05-12
Добавляйте свои новости в комментарии. И заглядывайте в наш канал, чтобы быть в курсе других активностей и мероприятий для тестировщиков.
Если вы сидите на MacOS / iOS и у вас VPN на VLESS+XTLS‑Reality, то при очередном обновлении системы/VPN-клиента с высокой вероятностью всё сломается или уже сломалось. Это не баг Shadowrocket и не баг xray-core. Apple ввела квантово-безопасное шифрование TLS 1.3 по умолчанию в iOS 26 / macOS 26, которое увеличивает размер TLS ClientHello на ~1216 байт. REALITY-сервер xray-core не может корректно прочитать такое большое сообщение — отсюда firstLen = 0 и отсутствие соединения. Windows это не затронуто. Простого/универсального решения нет, т.к. откат на предыдущую версию в экосистеме Apple — тот ещё квест. Если ваше клиентское приложение VPN позволяет настроить TLS → Fingerprint, тогда там необходимо выбрать firefox или Crome110 — для которых ещё не было поддержки X25519MLKEM768. В этом случае всё легко чинится.
Представлен открытый проект waylandcraft - это полнофункциональный композитор Wayland полностью интегрирован в мод Fabric для Minecraft Java 26.1.2.
«Запускайте приложения и открывайте окна прямо в вашем мире Minecraft. Перетаскивайте данные из одного окна в другое. Закрепите видеоплеер на вашем HUD. Выбор за вами. Важно: этот мод работает только под Linux! MacOS и Windows не поддерживаются», — пояснил автор проекта.
Представлена космическая онлайн-карта из произведения «Проект „Аве Мария“». Там показаны основные локации и можно посмотреть Линию Петровой.
Google продемонстрировала, насколько громадным стал спрос на искусственный интеллект. Ежемесячное количество токенов, обрабатываемых в Google:
май 2024 года – 9,7 трлн;
май 2025 года ~480 трлн;
май 2026 года – 3,2+ квадриллиона.
Это семикратный рост по сравнению с прошлым годом.
На днях узнал, что hh.ru тихонько обфусцировал опцию готовности к переезду, и как-то так получается я не был готов к переезду возможно уже около года.
Самое раннее упоминание об этом, которое мне попалось, датируется 1 октября 2025.
Выход предлагается увлекательный, оказывается теперь необходимо установить мобильное приложение, и покопаться там. Ничего такого вроде "все регионы" больше нет, то есть человеку готовому переехать куда угодно, нужно указывать длинный список на пол страницы, который будет выглядеть отчаянно.
Держу в курсе своей слоупочности.
Что общего между компьютерными играми и фридайвингом?
Вроде бы ничего, но РКН все-таки нашел. Из почти 30 компаний оштрафованных с начала года за невыполнение требований о "локализации", 8 производителей игр и 6 организаций, работающих в сфере дайвинга/фридайвинга (обучение, сертификация, оборудование).
С играми все более-менее понятно, но чем дайверы сумели привлечь к себе внимание, почему именно они? Нет ответа
Если кому-то интересно, игры: Electronic Arts Inc, Battlestate Games Limited, Digital Extremes Ltd, Epic Games Inc, NetEase Interactive Entertainment Pte, Take-Two Interactive Software Inc, TOO Dynamic Technologies, Embracer Group AB; дайверы: SNSI International Training Agency, NAUI Worldwide, SSI International GmbH, AIDA International, PADI Americas Inc, Molchanovs Pte Ltd.