Веб-разработка *

Wildberries выпустила собственный мессенджер WB Chat

У Wildberries появился собственный мессенджер WB Chat. Приложение уже доступно пользователям на Android и iOS, а авторизация проходит через WB ID.

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

Набор функций тоже постепенно расширяется. Сейчас WB Chat позволяет:

• отправлять сообщения, фото, видео и файлы;

• пересылать сообщения и отвечать на них;

• использовать реакции, эмодзи и стикеры;

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

• закреплять важные сообщения;

• искать людей, чаты и сообщения;

• совершать аудиозвонки;

• расшифровывать голосовые сообщения в текст.

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

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

В Google Play приложение опубликовано компанией WB FZE, зарегистрированной в Hamriyah Free Zone в эмирате Шарджа, ОАЭ. На момент проверки там указано 1 тыс.+ скачиваний.

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

Скачать WB Chat для Android можно через Google Play, для iPhone и iPad — через App Store. Также заявлена веб-версия WB Chat.

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

✔ Код — журнал о технологиях https://t.me/kodjournal подпишитесь на наш Telegram-канал! 😎

Регистрацию на иностранных сайтах по номеру телефона убрали из «Антифрод 3.0»

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

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

Что планировали изменить

В предыдущей версии документа предполагалось дополнить закон «Об информации, информационных технологиях и о защите информации» специальными требованиями для зарубежных интернет-ресурсов.

Если бы норма сохранилась, такие платформы должны были бы:

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

• хранить сведения о регистрации, входе и удалении аккаунтов в течение трёх лет;

• предоставлять эти данные по запросам органов, занимающихся оперативно-розыскной деятельностью или обеспечением безопасности.

Теперь этих положений в новой редакции проекта нет.

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

Почему от требования могли отказаться

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

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

Гендиректор Telecom Daily Денис Кусков считает исключение нормы разумным именно по этой причине. Независимый аналитик Алексей Бойко также обращает внимание на риск, что зарубежной платформе может оказаться проще ограничить работу в России, чем создавать отдельную систему авторизации для российских пользователей.

«Антифрод 3.0» ещё меняется

О подготовке третьего пакета мер против кибермошенничества объявили в апреле 2026 года. Законопроект планируют внести в Госдуму осенью.

Причём требования к иностранным ресурсам уже успели измениться: ещё в конце июля «Ведомости» сообщали о проекте, в котором обязательная авторизация по номеру телефона присутствовала.

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

Как мы провели второй день Летнего ТехФеста

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

Смотри влог, чтобы погрузиться с головой в этот вечер.

P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

Какие уникальные фичи есть в django-modern-rest?

Иногда, когда я добавляю какие-то фичи в мой https://github.com/wemake-services/django-modern-rest (можно ставить ⭐), то я думаю про себя: почему таких фичей больше нет нигде? 

Давайте сегодня посмотрим на них. А вы мне расскажите свое мнение в комментах.

Семантическая схема 

Допустим, вы навесили на какой-то свой endpoint auth: 

class UserController(Controller[MsgspecSerializer]):
      @modify(auth=[JWTAsyncAuth()])
      async def get(self) -> User: ...

В OpenAPI автоматически появятся все коды ошибок, которые могут случиться в auth (401).
Ничего не надо допом писать. И так происходит со всеми частями фреймворка: добавил throttling=[SyncThrottle(1, Rate.minute)]? Теперь у тебя в ответах автоматом 429. Если нужно, можно отключить любые семантические статусы. 

Не должно ли такое быть дефолтом везде?

Умные типы ошибок

Не уходя далеко: как кастомизировать формат ошибки, например, в FastAPI? Через боль. Как поменять в спеке формат? Руками.

В DMR мы просто добавили везде error_model как параметр. Можно заменять любые ошибки, все автоматом сконвертится и покажет правильную схему. Зачем? Хочешь Problem Details - используешь. Хочешь свой формат - реализуешь. Можно даже content negotiation на ошибки навесить.

Почему никто о таком не думает в других фреймворках?

Нормальный throttling

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

1. Почти нигде из коробки нет поддержки разных алгоритмов, бекендов, иногда даже cache-keys. Очень жаль, есть только обычный counter с бекендом в памяти
2. Нигде (пришлите в комменты контр-пример) нет разделения на throttling до auth и после. Почему такое вообще важно? Чтобы не заддосить auth. И чтобы иметь возможность выдавать per-user правила. Нужны и важны оба варианта
3. Кастомизация заголовков ответа? Ха!

Что? Почему?

Простое переиспользование кода

Когда я смотрю на АПИ разных DRF проектов или FastAPI, мне становится больно. FastAPI строит все на view функциях, которые нельзя нормально кастомизировать. А DRF строит все на импортах строк внутри настроек. А как на счет классов и наследования?

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

class RequestPayload(pydantic.BaseModel):
     username: str
     password: str

class ResponsePayload(pydantic.BaseModel):
     access: str
     refresh: str

class ObtainAccessAndRefreshSyncController(
    ObtainTokensSyncController[
        PydanticSerializer,
        RequestPayload,
        ResponsePayload,
    ],
): ...  # надо еще переопределить 2 метода

Все типизировано, документировано, очевидно. 
Как вы думаете, почему так больше никто не делает?

Внешние вьюхи

Интегрировать один фреймворк в другой - крайне сложно. Вот мы недавно даже стрим проводили, потому что не могли использовать dj-rest-auth из DRF. Так быть не должно.

Теперь в DMR можно использовать любые внешние Django View. Хоть DRF, хоть django-ninja, хоть ванильные вьюхи. И отображать любой внешний OpenAPI. Вот настолько просто:

raw_schema = read_openapi_yaml('openapi.yml')
router = Router(
    urls=[
        external_path(
            'number/', number, name='number',
            openapi=load_schema(raw_schema['paths']['/api/number'], PathItem),
        ),
    ],
)

Почему другие фреймворки не стараются вписать существующие решения?

Одной строкой

- Больше подобного у меня в тегеграм канале "Находки в опенсорсе": https://t.me/opensource_findings
- У нас есть еще куча других крутых фичей! Заглядывайте в наш чатик по DMR
- Релизнули django-stubs@6.1 с поддержкой django@6.1
- Сделали папку с крутыми каналами ребят из нашего Python сообщества. Смело можно закидывать коллегам как базовую папку "на кого подписаться в тг по питону". Внутри все мои друзья и коллеги, советую!

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

• oishiso.jp — иллюстрации в стиле вкусной еды и кулинарии;

• irasutoya.com — бесплатные иллюстрации на самые разные темы;

• enpitsu-sozai.com — тёплые иллюстрации в стиле карандашных рисунков от руки;

• nawmin.stores.jp — сельхозпродукты, фермерство и деревенская жизнь;

• vectorshelf.com — качественные векторные иллюстрации в стиле ручной рисовки, есть AI, PNG и SVG;

• loosedrawing.com — простые линейные рисунки с возможностью менять цвет прямо на сайте;

• storyset.com — векторные иллюстрации для презентаций и веба с настройкой цвета и анимации;

• openpeeps.com — рисованные персонажи, которых можно собирать в разных комбинациях;

• undraw.co — чистые векторные персонажи в стиле IT и стартапов с настройкой цвета;

• illustrations.run — наборы открытых векторных иллюстраций на разные темы

Совет по Joomla: Как сделать ссылки на списки сущностей Joomla с фильтрацией?

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

Например:

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

• разработчик хочет в документации для контент-менеджера дать ссылку на нужные модули, плагины, о которых идёт речь;

Админка Joomla поддерживает фильтры в URL-адресе, а названия GET-параметров для фильтрации можно посмотреть в названиях полей фильтров админки.

Например, в списке плагинов поле фильтра:

• выбор состояния - filter[enabled]=1 или 0

• выбор типа (группа плагинов) - filter[folder]={название группы плагина, например content или system}

• element плагина (уникальное систеное имя) - filter[element]={element}

• уровень доступа, с которым работает плагин - filter[access]={числовой-код-уровня-доступа}

• строка поиска - filter[search]={любой%20текст%20для%20поиска}

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

https://your-joomla-site.ru/administrator/index.php?option=com_plugins&view=plugins&filter[element]=wtotpravkapochtaru&filter[folder]=system

Аналогичным образом работает список модулей, контактов, материалов и т.д. Найти имена параметров можно либо в HTML-коде страницы, либо в XML-форме опций фильтра нужного компонента. Для списка плагинов используется компонент com_plugins, а форма фильтра лежит в administrator/components/com_plugins/forms/filter_plugins.xml. Для списка материалов Joomla - в administrator/components/com_content/forms/filter_articles.xml. Другие компоненты - ищем по анналогии.

Чат русскоязычного Joomla-сообщества в Telegram и в Max.

Пользователь заработал $120 тыс., размещая рекламу на виртуальном унитазе. Он взял 3D‑модель обыкновенного унитаза, повесил там счётчик донатов и добавил рекламу всякого криптоскама на крышку и ободок (там им и самое место). При этом собранных денег автору проекта оказалось мало — он планирует получить за такой перфоманс миллион долларов.

ElegantGPT

Начал значительно чаще пользоваться ChatGPT, так как на GPT-5.6 Sol High качество ответов стало меня устраивать. Вдобавок, он по умолчанию работает примерно в том же стиле, что и Perplexity Computer. Только нет никаких дурацких кредитов.

Единственное, что меня серьёзно напрягало – это то, как выглядел чат. Чёрный фон, полная депрессия. Поэтому сделал свою тему. Естественно, частично наследовал Base16 Dark и поставил любимое семейство IBM шрифтов.

Читаемость повысилась. С чатом стало приятнее работать. Кстати, предыдущую тему для Habr я тоже переработал.

Тема бесплатная, устанавливается через Stylus (Firefox / Chrome).

Как получить готовый план по оптимизации лагающего сайта с помощью аудита фронтенда

Привет! Я Рома Игнатович, лид фронтенд-разработки в Далее. Обычно задача «ускорить сайт» без конкретики превращается в перебор гипотез вслепую. PageSpeed тут не спасет, потому что он показывает только симптомы — например, низкую скорость загрузки, нестабильную вёрстку, задержку кликов, — но не причины. За одинаковыми цифрами может стоять что угодно, от тяжёлых картинок до медленного бэкенда. Поэтому вместо точечных проверок я использую аудит фронтенда — он сразу сужает область поиска и помогает быстро составить план по доработкам.

Как проходит аудит

Смотреть можно без доступа к коду, во вкладке Performance в DevTools. Берём ключевой сценарий (например, флоу покупки) и записываем performance trace: скролл, клики, переходы, ввод — ищем долгие таски, блокировки потока, просадки анимаций. Параллельно смотрим Network waterfall (какие запросы блокируют остальные), рантайм и три метрики Web Vitals: LCP, TTFB, CLS. Для мультирегиональных продуктов пригодится WebPageTest — показывает поведение сайта из разных точек и с разным качеством соединения.

Проверять стоит не только на мощной машине: CPU throttling (4–6x) имитирует медленное устройство и вскрывает лаги, а network throttling на 3G/4G показывает, насколько критичны тяжёлые изображения и порядок загрузки. Сценарии прогоняем дважды — в норме и с throttling; если с throttling сайт деградирует критично, это уже не техдолг, а прямые потери конверсии.

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

Типичные проблемы и варианты их решений

Загрузка и контент:

• весь код в одном бандле → браузер грузит и парсит всё сразу, плюс изображения по 20–30 МБ. Фикс: разбить на смысловые чанки, грузить по страницам и сценариям;

• устаревшие форматы вместо WebP/AVIF, нет адаптивных размеров (srcset), грузятся элементы за пределами вьюпорта. Фикс: современные форматы + lazy loading;

• высокий TTFB значит, что тормозит бэкенд, высокий LCP может быть где угодно. Фикс: проверяем бэкенд, настраиваем отправку первичного запроса при монтировании страницы.

Интерфейс и рендеринг:

• расчёт анимаций на CPU вместо GPU, свойства вроде width/height/top/left вместо transform — браузер пересчитывает layout. Фикс: transform/opacity, но без перебора с will-change;

• main thread перегружен синхронными операциями и тяжёлыми вычислениями. Фикс: распределять задачи параллельно, выносить тяжёлые операции из основного потока;

• layout shift — не зарезервировано место под контент, не заданы размеры изображений и блоков. Фикс: фиксировать размеры заранее, skeleton-заглушки.

От аудита к бэклогу

Такой аудит даёт гипотезы, которые ещё нужно перевести на язык задач. Формулирую каждую находку как цепочку: проблема → гипотеза → действие. Например:

• интерфейс подвисает при открытии карточки → долгие JS-задачи → разбить выполнение;

• анимация лагает → расчёты идут на CPU → перевести на GPU через transform;

• страница долго грузится → тяжёлые изображения → оптимизировать формат и размер.

У любой оптимизации — измеримая цель: например, LCP < 2.5 с, CLS < 0.1, снижение веса страницы на 30–40% и т. п.

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

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

Подробнее обо всех этапах пишу в большой статье на Workspace: читать здесь.

Открытый проект .MD this page позволяет преобразовать веб-страницу в чистый Markdown, готовый для ChatGPT, Claude, Gemini и других нейросетей. Решение очищает код сайта от рекламы, баннеров и другого мусора для отправки на обработку в ИИ. Есть предпросмотр, экспорт в .md и опция для мгновенного копирования сайта.

Перенёс пет-проект с хоумсервера в облако. Что удивило:

Года два держал несколько ботов и сервисов на старом ноуте. Работало. Но надоело: отключение света, перегрев летом, динамический IP, ngrok который иногда падал.

Решил переехать в Яндекс Облако. Думал займёт выходные. Занял три выходных.

Не потому что сложно. Потому что пришлось разобраться с вещами которые дома работали сами собой.

Secrets. Раньше у меня токены лежали в .env файле. В облаке сразу захотелось сделать через Lockbox. Потратил конечно же время, но теперь не страшно что репозит случайно станет публичным.

CI/CD. Дома деплой был «зашёл по SSH, git pull, перезапустил». В облаке настроил GitHub Actions: пуш в main - автоматически собирается образ и обновляется сервис. Первый раз в жизни сделал нормальный пайплайн. Оказалось не так страшно как казалось.

Мониторинг. Дома я узнавал что бот упал когда кто-то писал «почему не работает». Теперь есть алерты. Мелочь, но разница ощутимая.

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

Какие ещё подобные решения есть?

Как я устал от бардака в «Избранном» Telegram и за два вечера запилил бесплатную интерактивную доску (без регистраций и СМС)

Всем привет!

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

Думаю, у многих из вас Telegram давно превратился в помойку из сотен каналов. Полезные статьи, гайды, рецепты, мемы, рабочие задачи — всё это мы обычно скидываем в «Избранное» (Saved Messages). И что происходит дальше? Правильно, «Избранное» превращается в черную дыру. Найти там что-то через неделю — это квест уровня «Индиана Джонс».

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

Мне это надоело. Я хотел простой инструмент: нашел на смартфоне -> скинул боту -> открыл на компе в виде красивых карточек. Посмотрел готовые сервисы — везде просят регистрацию, привязку карт, вылезает реклама или ограничения на 10 постов.

В итоге я психанул, выделил два вечера и написал свой костыль, который неожиданно превратился в отличный инструмент — TG-drop.ru.

Как я это устроил (без заумной архитектуры)

Система работает на связке «бот + база данных + веб-интерфейс». Всё гениальное просто:

1. Вы листаете Telegram на телефоне и видите важный пост (гайд, чек-лист, статью).

2. Пересылаете его моему боту. Бот мгновенно подхватывает его и сохраняет в изолированную таблицу.

3. Вечером вы садитесь за ПК, открываете сайт, вводите свой Telegram ID (он нужен только как ключ, чтобы сайт понял, чьи посты показать) — и перед вами удобная интерактивная доска.

Почему это удобнее, чем просто Telegram?

Я делал проект для себя, поэтому сразу вырезал всё, что меня бесит в современном вебе:

• Никаких регистраций вообще. Никаких вводов почты, подтверждений по SMS и придумывания паролей «с одной заглавной буквой и спецсимволом». Ввел ID — работаешь.

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

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

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

Кому это пригодится?

Изначально я думал о ребятах из крипты (охотники за Airdrop, тестнеты, DeFi-инвесторы), которым нужно по пунктам выполнять сложные активности с ПК, найдя их в мобильном телефоне.

Но в процессе понял, что штука закроет боли многих:

• Контент-мейкеров и исследователей: собирать выжимки, инсайты и референсы в одном месте.

• Студентов: скидывать материалы для курсовых и дипломов, чтобы потом структурировать на десктопе.

• Да и вообще всех, кто использует Telegram как базу знаний и устал от хаоса в «Избранном».

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

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

Выкатил релиз 1.3.1 моей простой товароучетной системы с поддержкой Честного Знака:

https://github.com/akdengi/sklad-cz

Что нового:

• Выбор товарной группы для работы в настройках (одиночный выбор из справочника). Реализованы 22 доступные группы (исключены алкоголь, табак, мех, ветпрепараты и др.)

• Запрос и отображение баланса денежных средств в ЧЗ на дашборде. Кнопка «Обновить баланс» для ручного обновления.

• Загрузка данных МОД из API Честный Знак по кнопке. Автоматическое заполнение адреса и FIAS ID. Предупреждение при отсутствии МОД со ссылкой на ЛК ЧЗ.

• Сканирование: проверка GTIN КМ для SKU, авто-определение правильного SKU, онлайн-проверка статуса ЧЗ сразу после добавления

• При импорте теперь выдает детальный отчёт об ошибках с модальным окном и экспортом в CSV (дубликаты, структура, GTIN, статус ЧЗ).

• Продажа: блокировка поиска по GTIN/Артикулу/EAN для товаров с маркировкой (только поиск по КМ).

• Склады: улучшенное отображение — таблица SKU с колонками Остаток/Продано.

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

А там глядишь и до заказа КМ доберусь и вводе в оборот :)

Начал писать тесты для бота. Оказалось не так страшно как думал

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

Начал с малого. Вынес всю бизнес-логику в отдельные функции которые не знают ничего про Telegram. Просто принимают данные, возвращают результат.

python

# Не так
async def handle_payment(message: types.Message):
    amount = int(message.text)
    if amount > 10000:
        await message.answer("Сумма слишком большая")

# А так
def validate_amount(amount: int) -> tuple[bool, str]:
    if amount > 10000:
        return False, "Сумма слишком большая"
    return True, ""

async def handle_payment(message: types.Message):
    is_valid, error = validate_amount(int(message.text))
    if not is_valid:
        await message.answer(error)

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

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

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

Кто тестирует ботов, как организуете?

С момента написания прошлой статьи про мою самописную товароучетную систему для работы с маркировкой «Честный Знак», я добавил новых фич и поправил существующие ошибки. Основные изменения следующие:

1. В Остатках в карточке товара появилась кнопка «Списать», позволяя сделать быстрое списание с нулевой ценой и выбором причины: утеря, собственные нужды, производственные цели, безвозмездная передача, отзыв с рынка. Данные нужно подавать также вручную, но для учета полезно.

2. Добавлен вид документа в продаже: поле «Вид док-та» в шапке заказа (Прочее, УПД, Товарная накладная, Акт приёма-передачи, Кассовый чек).

3. Появилась кнопка «Скачать КМ в CSV» в корзине Продаж для скачивания КМ в формате «для ввода/вывода из оборота» для вставке в ЭДО при передаче УПД.

4. Дропдаун «Статус» теперь показывает статус ЧЗ для проданных товаров.

5. Появилась возможность выделить и произвести массовую проверку статуса ЧЗ для выделенных товаров (чекбоксы + кнопка) на вкладках Остатки, Продано, Вывод из оборота.

6. Появилась колонка «Статус в ЧЗ» в таблицах Остатки и Вывод из оборота

7. Сделано автоподтверждение отчёта о выбытии при статусе ЧЗ равном «Выбыл» (RETIRED/WITHDRAWN/WRITTEN_OFF)

8. Сделано сохранение активной вкладки при перезагрузке страницы

9. Введена новая логика быстрой продажи: в шапку заказа: номер заказа, склад списания, дата продажи, добавление нескольких товаров по КМ/артикулу/EAN-13 с ценой за позицию в корзину с одинаковым номером заказа, КМ для Маркетплейсов отображается в корзине и копируется кликом, сделан Live-поиск при вводе кода с полной информацией о товаре.

ПО я писал для своей товарной группы «Игры и игрушки», но оно должно подходить и для других товарных групп потребительских товаров.

Сразу напишу про API: авторизация по ЭЦП и получение общего статуса по КМ все еще ведется по 3 версии API Честного Знака, как и например работа с МОД, а что-то уже работает только по 4 версии API (например ввод-вывод из оборота).

Ahileo Radio - авторское радио или как честно обойти конкурентов.

Совсем ещё недавно, мечты тысяч радиолюбителей по всему свету сводились к созданию собственной радиостанции, где можно было сутки напролёт крутить разную музыку без ограничений. Но жесткий контроль со стороны ГИЭ (Государственная организация электросвязи) не давал такой возможности.

Мало того что нужно было регистрировать купленный или созданный своими руками передатчик, так ещё и "крутить" всё подряд запрещалось. У каждого радиолюбителя должен был быть зарегистрированный позывной, к примеру мой старый позывной UR4IFH, так ещё и нужно сдавать экзамены на знание основ радиоэлектроники и связи. Это касалось не только времём СССР - такие правила есть и сейчас.

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

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

Самый простой и надёжный способ выйти в "эфир" как настоящая радиостанция и при этом избежать массы финансовых и технических нюансов, это запуск интернет радиостанции. Здесь всё достаточно просто: компьютер, нужный софт, безлимитный интернет и собственное желание. Понятное дело, что такое радио будет испытывать колоссальные перегрузки из-за конкуренции, ведь тысячи подобных станций уже вещают в сети интернет на любой вкус.

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

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

Лично я запустил такое радио в высоком качестве 320 кбит в формате AAC для любителей музыки. Основной материал, который я транслирую, - это музыка от независимых авторов и малых студий. Сюда входят и треки созданные в нейросетях, например в SUNO, Udio, Mureka и других. Авторские отчисления поступают владельцам этих треков на их криптокошельки через созданную мною систему распределения роялти основанную на блокчейне (об этом читайте в других моих статьях).

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

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

Как настроить TLS в клиенте Python при HTTPS-запросах?

Бывает так, что после обновления OpenSSL часть HTTPS-вызовов к внешним сервисам падает с ошибкой ssl.SSLError. Сейчас разберемся, как настроить Python, чтобы handshake проходил успешно и соединение оставалось безопасным.

После апдейтов OpenSSL часто отключают старые протоколы и слабые шифры — старые серверы не проходят handshake. Решение на клиенте — явно создать ssl.SSLContext, задать минимальную версию TLS и, при необходимости, набор шифров, а затем передать этот контекст в HTTP-клиент (например, httpx).

import ssl
import httpx

ctx = ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
ctx.minimum_version = ssl.TLSVersion.TLSv1_2
ctx.set_ciphers('ECDHE+AESGCM:!ECDSA:!aNULL:!eNULL')

with httpx.Client(verify=ctx, timeout=10.0) as client:
    r = client.get('https://api.example.com')
    r.raise_for_status()
    print(r.status_code)

В коде мы указываем TLSv1_2 как минимальный порог. Это удобно: если сервер уже поддерживает TLS 1.3, все само заработает на самой новой версии. Но если какой-то внешний сервис еще не успел обновиться, соединение не разорвется, и все продолжит работать на стабильном 1.2. Так мы получаем универсальный код, который не сломается при работе со старыми API.

Для отладки TLS handshake применяйте openssl s_client -connect host:443 -tls1_2 чтобы увидеть, какие шифры поддерживает сервер. Временное ослабление minimum_version даст совместимость, но хуже для безопасности — лучше апгрейдить серверную часть. Сертификаты и ключи храните вне кода (секреты/volumes), не логируйте их, и при работе в контейнерах используйте безопасные механизмы передачи секретов.

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Понял asyncio только когда бот начал зависать под нагрузкой

Писал на Python и честно говоря asyncio воспринимал как магию. Работает и ладно.

Пока однажды бот не завис.

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

Начал разбираться. Оказалось я вызывал синхронную функцию прямо внутри async хендлера. requests.get внутри async def. Это блокирует весь event loop. Все корутины ждут пока эта одна функция не завершится.

Решение простое: либо заменить requests на aiohttp, либо обернуть синхронный вызов через asyncio.to_thread. Второй вариант проще когда менять библиотеку лень:

python

result = await asyncio.to_thread(requests.get, url)

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

Кто сталкивался с похожим, как отлаживали?

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

Три вещи которые горели чаще всего.

Разные версии Android. На эмуляторе всё красиво. На реальном устройстве со старой версией что-то обязательно едет. Держу под рукой старый телефон с Android 10, туда ставлю перед каждым релизом.

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

ProGuard и минификация. Локально всё работает. В release сборке падает что-то что ты вообще не трогал. Потому что минификатор убрал класс который использовался через рефлексию.

Список не длинный но каждый раз спасает от как минимум одного стыдного бага в продакшене.

Что у вас в чеклисте перед релизом чего нет у большинства?

Дал боту имя и работать стало приятнее

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

Назвал Степаном.

Смешно, но код стал аккуратнее.

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

Наверное дело в том что когда называешь что-то именем, начинаешь нести за это ответственность иначе. Не «упадёт и ладно», а «Степан не должен падать».

Кто-нибудь ещё так делает или это только у меня странности?

Telegram Stars в боте: попробовал прикрутить, делюсь что удивило

Давно хотел добавить платежи в одного из своих ботов. Раньше использовал ЮKassa через нативный Telegram Payments. Но в этот раз решил попробовать Stars, всё-таки нативная валюта платформы, без внешних провайдеров.

Настройка оказалась проще чем ожидал. Никаких provider_token, никакой возни с webhook от платёжки. Просто отправляешь инвойс с указанием суммы в Stars и обрабатываешь successful_payment. Примерно так:

python

await bot.send_invoice(
    chat_id=message.chat.id,
    title="Премиум доступ",
    description="Доступ на 30 дней",
    payload="premium_30d",
    currency="XTR",
    prices=[LabeledPrice("30 дней", 100)]
)

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

Но есть нюансы которые я не учёл сразу.

Первое: если пользователь покупал Stars через iOS или Android, Telegram отдаёт разработчику примерно 70% от суммы, остальное Apple и Google забирают себе. Если через десктоп или веб — почти всё твоё. Это принципиально меняет экономику для аудитории которая сидит на телефоне.

Второе: возвраты. Stars можно вернуть и Telegram это делает по запросу пользователя. Нужно обрабатывать refunded_payment иначе пользователь получит деньги обратно а доступ у него останется.

Третье: вывод только через Fragment в TON. Для российского юрлица это отдельная история.

В целом для цифровых товаров и небольших сумм Stars удобнее чем внешние платёжки. Но если оборот серьёзный или нужен рублёвый вывод, ЮKassa всё ещё выглядит надёжнее.

Кто уже работает со Stars в продакшене, как решаете вопрос с выводом в рубли?

Хай, коллеги!

Около полутора месяцев назад, работая над задачей дообучения локальной модели ИИ, я наткнулся на Modern Web Guidance - сборник руководств (skills - навыков) по современной веб-разработке для агентов ИИ от команды Google Chrome. Ознакомившись со сборником, я понял, что большинство руководств человекам тоже не помешали бы😄 Так появился этот репозиторий. Основная работа над руководствами завершена. Любые исправления, замечания и предложения приветствуются. Пользуйтесь на здоровье и счастливого кодинга!

Хотел сделать крутую онлайн игру. Расскажу где всё пошло не так

Идея была простая до безобразия. Браузерная змейка но с живыми соперниками. Canvas, websocket, Node.js. Всё это я более-менее знал, казалось делов на пару выходных.

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

Ага.

Синхронизация это ад

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

Всё сломалось.

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

Полез гуглить. Нашёл что это называется authoritative server, client-side prediction, lag compensation. Понял что я вообще не туда смотрел когда проектировал. Думал займёт вечер. Потратил месяц и всё равно сделал через одно место.

Лобби которое я не планировал

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

Это не мелочь.

Ожидание, старт, игра, конец, переиграть — каждое состояние надо синхронизировать. И самое весёлое это когда один игрок просто закрыл вкладку в середине партии. Что показывать второму? Кто победил? Как засчитать? Три вечера только на обработку разрывов соединения.

Читер за пять минут

Дал поиграть другу. Через пять минут он открыл консоль и начал отправлять серверу произвольные координаты. Змейка телепортировалась куда хочет. Я вообще не думал об этом когда писал архитектуру.

Что по итогу

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

Главное что понял: онлайн игра это не игра плюс немного сетевого кода. Это совсем другая задача где сеть и есть основная сложность. Я недооценил это раз в десять минимум.

Код выложу на GitHub как разберу этот клубок. Пока стыдно показывать.

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

В первый раз в жизни, спустя 15 лет "ищу" работу. До недавнего времени работа меня находила сама. Возник некоторый поток мыслей по этому поводу.

Самое главное, насколько я понял, сейчас все резюме читает не человек, а ИИ, а на одну вакансию приходится от 10+ до 100+ человек (статистики у меня нет, по ощущениям так). Следовательно все вылизывают резюме в стиле "не просто навыки, а ценности". Художественные произведения в стиле как я провёл лет: ускорил всё на 50%, оптимизировал всё на 200%. Прямо сейчас открыл сайт визитку случайного человека. Цитирую: ускорение разработки на 30-70%, минус 45% критических багов в проде, в четыре раза сокращения времени онбординга, менторство, ревью и т.д. И всё это за пять лет работы.

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

Синдром самозванца или на самом деле пора идти в сантехники? Но если все поголовно, практически каждый день ускоряет производительность на ~50%, почему такой софт ещё не улетел в космос?

А ответ кажется прост. Ещё ~5 лет назад никто не считал, на сколько он эффективен в процентах. Ты просто работаешь. Это твоя ежедневная обязанность "ускорять на 50%", "оптимизировать на 200%". Видишь кривую архитектуру из за которой каждый день сыпет баги - просто чинишь архитектуру. Видишь, что кто то наговнокодил (возможно ты сам, пол года назад) и запросы в БД замедлились в 2 раза, просто чинишь и попутно ускоряешь в 4 раза. Ты не фиксируешь это как своё достижение - это просто твоя работа, который ты горишь (а иногда и выгораешь) и за которую тебе платят. И тебе не надо отправлять производительность программы в космос и уменьшать критические ошибки на 45% (как это вообще считали?), если ты уже знаешь как написать код таким образом, что бы этого не понадобилось в обозримом будущем. Но что бы конкурировать с такими резюме нужны абсолютно другие навыки. Это уже не говоря про вайб-кодинг. Поэтому, возможно, всё таки придётся идти в сантехники.

За свою карьеру я успел попробовать Java, Python и ещё кучу всяких языков.

У каждого есть свои сильные стороны, ни один из них нельзя назвать "лучшим" для всех задач. Но заметил одну забавную вещь: спустя какое-то время я снова возвращаюсь к PHP.

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

В общем, в какой-то момент эта мысль показалась настолько забавной, что я решил сделать небольшую музыкальную пародию на известную песню (старый хит 70х) – только про PHP и разработчиков, которые "ушли, но вернулись".

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

🎬 Видео: https://youtu.be/SoqAP4gSDac

Звучит знакомо?

Как отключить Google и Apple ID и не сломать авторизацию для пользователей

Привет! Я Александр Бондаренко, руководитель проектной группы в Далее. С сегодняшнего дня кнопка «Войти через Google» на сайте может стоить от 500 до 700 тысяч рублей. Всё потому, что 7 июля вступает в силу Федеральный закон № 199-ФЗ — поправки в КоАП, по которым за авторизацию пользователей через иностранные сервисы владельцы сайтов несут административную ответственность.

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

Коротко о законе: требование идентифицировать российских пользователей через российские сервисы действует с декабря 2023 года (149-ФЗ). В список приоритетных способов входят номер телефона РФ, «Госуслуги» (ЕСИА), единая биометрия или сервис российского гражданина или компании — например, VK ID, Яндекс ID, Сбер ID. С 7 июля у требования появилась статья в КоАП (13.55, 199-ФЗ от 26 июня) — штраф до 700 тысяч рублей для юрлиц.

Авторизация через Google и Apple ID — очевидная часть, но список шире. Sign in with Apple часто появляется просто потому, что Apple требует его для iOS-приложений. На старых проектах нередко остается Facebook Login (принадлежит Meta, признанной в России экстремистской организации). Реже встречаются GitHub, Discord и Microsoft / Azure AD — обычно в сервисах для разработчиков, игровых проектах и корпоративных SSO.

Как искать в коде

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

Для Passport.js проверьте passport-google-oauth20 и passport-apple в package.json, для OmniAuth — omniauth-google-oauth2 в Gemfile, для Firebase Auth — providers в конфиге. В мобильных сборках обратите внимание на GoogleSignIn в Podfile и play-services-auth в build.gradle.

Просканируйте репозитории через grep или поиск IDE по строкам accounts.google.com, appleid.apple.com, facebook.com — так часто находятся забытые интеграции.

Отдельно стоит заглянуть в консоли провайдеров — Google Cloud Console, Apple Developer, GitHub OAuth Apps. Кнопку в интерфейсе можно убрать, но пока приложение зарегистрировано в консоли и redirect-URI активен, эндпоинт технически остается рабочим.

Как перейти на российские сервисы и не потерять пользователей

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

1. Подключить и протестировать российский способ: SMS, VK ID, Яндекс ID, Сбер ID или «Госуслуги».

2. Предложить авторизованным пользователям привязать новый способ входа и заранее предупредить о дедлайне.

3. Тем, кто не успел, предоставить восстановление через поддержку с подтверждением личности.

4. После миграции отключить иностранного провайдера, удалить OAuth-приложение в консоли, очистить GOOGLE_CLIENT_SECRET из .env и хранилища секретов.

5. При необходимости инвалидировать активные JWT и refresh-токены, выданные через Google.

6. Обновить Политику обработки персональных данных.

3 вопроса, которые пока остаются открытыми

1. Что считать иностранным сервисом. Кнопку входа через Google меняем точно. А вот использование Gmail как адреса электронной почты без OAuth, по мнению большинства юристов, под действие закона не подпадает: значение имеет способ подтверждения личности, а не почтовый адрес.

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

3. Что с сайтами иностранных компаний в зоне .ru. Закон адресован владельцам сайтов без разделения по юрисдикции регистрации. Судя по формулировкам, ключевой критерий — наличие российской аудитории, а не страна регистрации компании.

Пишите в комментариях, если я не упомянул какие-то подводные камни, и подписывайтесь на мой тг-канал про цифровой комплаенс 👌

WT Max v.0.2.0. - библиотека для интеграции с Joomla

Обновление Joomla-библиотеки для API мессенджера MAX с системным плагином для настроек и диагностики подключения. Библиотека предназначена для разработчиков.

Расширение является Joomla-обёрткой над самостоятельным PHP Composer-пакетом Webtolk\Max, у которого так же состоялся релиз 0.2.0. PHP SDK разрабатывалось с учётом стандартов PSR и полностью не зависит от какого-либо фреймворка и/или пакета.

v.0.2.0. Что нового?

• Подключена новая версия API-хоста: platform-api2.max.ru. Для корректной работы ваших чат-ботов и мини-приложений до 19 июля 2026 необходимо перенаправить HTTP-запросы с домена platform-api.max.ru на platform-api2.max.ru, а также добавить сертификат Минцифры в список доверенных. Как это сделать - ссылка на инструкция внизу поста. ‼️Если этого не сделать - вы получите уведомление об ошибке соединения и неверном сертификате.

• Расширена публичная API-поверхность. Обновлены и дополнены методы для работы с чатами и сообщениями (включая новые сценарии по ссылкам на чат и выборке по query-id сообщения). Удалены устаревшие методы.

• Обновлён набор публичных JSON-схем. Добавлены и синхронизированы схемы для новых и изменённых endpoint-ов. Эти схемы - снимки реальных ответов API Max, так как мы прекрасно знаем, что документация и реальное API может отличаться порой очень и очень значительно.

• Обновление документации. README, стартовые руководства, референсы и описания сущностей/пэйлоадов приведены к текущему API-уровню.

Ссылки:

• PHP SDK, Composer-пакет

• Joomla-обёртка WT Max

• Инструкция: Установка сертификатов МинЦифры Российской Федерации на свой сервер.

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

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

Утилиту довёл до конца. Работает. Но половину кода всё равно переписал руками.

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

«Статистическая лихорадка» AI на Google Search: Один вопрос — 25 разных ответов.

Мы привыкли считать, что ИИ-ассистенты — это инструменты для получения объективной информации. Чем лучше модель, тем стабильнее и точнее результат. Но так ли это на самом деле?

Я провёл эксперимент. 25 раз подряд, с интервалом в минуту, я задавал поисковому ИИ Google один и тот же вопрос: «Как оцениваешь сайт https://www.lamedgroup.info». Сайт — статичная структура, его содержание не менялось за время теста. Ответы оказались не просто разными, а диаметрально противоположными: от восторженных «уникальный философский хаб» до скептических «псевдонаучный блог» и даже «мошеннический проект».

Это не случайность и не «глюк». Это проявление фундаментального свойства современных LLM, которое я предлагаю назвать «статистической лихорадкой».

Что показал анализ 25 ответов?

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

• Высокую сложность языка (термины вроде «антропологический дизайн» или «фрактальная топология смыслов»);

• Эклектику тем — смесь философии, ИИ, геополитики и эзотерики;

• Сомнение в академическом статусе — это не научный журнал.

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

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

Феномен «ложного обвинения» — ключевой индикатор. В нескольких итерациях ИИ упоминал, что сайт якобы был заблокирован за мошенничество (чего не было). Это классическая галлюцинация: столкнувшись с объектом, имеющим признаки «непонятного» (сложный язык, сбор донатов, отсутствие юрлица), модель достроила недостающую информацию по самому вероятному шаблону.

Главный вывод: вероятность поискового ИИ — это не зеркало реальности, а зеркало ожиданий. Чем сложнее объект, тем сильнее искажение.

Попытка измерить отклонение

Чтобы перейти к цифрам, я сравнил все 25 ответов с самоописанием сайта (как фрактального, самореферентного конструкта) и получил распределение по проценту отклонения:

• Низкое отклонение (<30%): ~16% ответов.

• Среднее отклонение (30–60%): ~52% ответов.

• Высокое отклонение (>60%): ~32% ответов.

Общий средний показатель отклонения составил ≈ 52%.

Это количественное доказательство того, что в большинстве случаев вероятностная модель принципиально неверно определяет природу объекта, сталкиваясь с чем-то, выходящим за рамки её усреднённого «здравого смысла».

Почему это важно: LLM vs фрактальная сложность

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

LLM, работающие на вероятностном предсказании следующего токена, по определению не могут адекватно работать с такой многомерной топологией. Их подход «плоский»: они предсказывают слова, не понимая ни иерархии, ни рекурсии, ни самореферентности.

Результат — та самая «статистическая лихорадка». Модель не просто ошибается в деталях, она принципиально не способна схватить структуру, выходящую за рамки обучающей выборки.

Заключение

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

Ссылка на оригинальный эксперимент с 25 ответами

Один из топовых генераторов фонов для сайтов, приложений и презентаций стал бесплатным — Paper Shaders открыли исходный код. Теперь проект можно свободно использовать в любых веб-задачах, создавать собственные инструменты, плагины и даже коммерческие продукты, объявил СЕО Paper Shaders.

Два часа потерял из-за того, что не написал один хендлер

Делал платежи в Telegram-боте. Нативные, через sendInvoice и ЮKassa.

Всё настроил: токен от BotFather получил, инвойс отправляется, кнопка оплаты появляется. Пользователь нажимает - и платёж падает с ошибкой. Молча. Без подробностей.

Payment failed

И всё. Telegram не говорит что именно не так.

Полез гуглить. Первая мысль - provider_token неверный. Проверил три раза, скопировал заново. Нет, токен правильный.

Потом решил что проблема в суммах - они передаются в копейках, не в рублях. 500 рублей = 50000. Перепроверил, у меня было правильно.

Потом подумал на webhook - может HTTPS не настроен как надо. Потратил минут сорок на проверку сертификата, перенастройку ngrok. Всё работает, но платежи всё равно падают.

Уже хотел идти спать, случайно наткнулся на строчку в документации:

Your bot must reply to this query in 10 seconds

Это про pre_checkout_query. Когда пользователь нажимает «Оплатить» - Telegram сначала отправляет боту запрос на подтверждение. Бот должен ответить в течение 10 секунд. Если не ответил - платёж автоматически отклоняется.

У меня хендлера для этого не было вообще. Бот просто молчал.

Добавил три строки:

python

@dp.pre_checkout_query()
async def pre_checkout(query: types.PreCheckoutQuery):
    await query.answer(ok=True)

Платёж прошёл с первого раза.

Два часа отладки из-за трёх строк кода которые я не написал.

Если кто-то тоже делает платежи в Telegram-боте и получает молчаливый отказ - проверьте pre_checkout_query первым делом, до всего остального.

Открытый проект CAPTCHA Solver — CloakBrowser + 2Captcha/CapSolver имитирует поведение человека и проходит почти все проверки на ботов. Инструмент умеет:

• решать на раз‑два более 30 видов капчи, имитирует поведение человека, чтобы обойти любые ограничения.

• ставится локально, в сервисе не надо регистрироваться и устанавливать дополнительное ПО..

18 бесплатных уроков недели: разработка, AI, тестирование и DevOps

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

В программе — Spring и Java, C++ и Linux, GitLab CI, тестирование, мобильная разработка, сетевые технологии, машинное обучение и практическое применение ИИ.

Какие темы запланированы:

Backend и разработка

• 29 июня, 20:00 — «Как работает @Transactional в Spring: границы транзакций и типовые ошибки». Записаться

• 1 июля, 20:00 — «Алгоритмическая сложность коллекций в Java». Записаться

• 2 июля, 20:00 — «Методы, их перегрузка и расширения». Записаться

C++ и системное программирование

• 30 июня, 20:00 — «RAII в C++: фундамент надёжного управления ресурсами». Записаться

• 1 июля, 20:00 — «Классические методы перехвата управления в Linux». Записаться

• 2 июля, 20:00 — «Всё, что нужно знать об управлении памятью в C++». Записаться

AI, ML и автоматизация

• 29 июня, 20:00 — «Обзор ИИ‑технологий для разработчиков: от идей до рабочих решений». Записаться

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

• 29 июня, 20:00 — «AI для работы с обратной связью: как анализировать отзывы клиентов, интервью и обращения в поддержку». Записаться

• 1 июля, 18:00 — «Градиентный бустинг — мощный алгоритм ансамблирования в ML». Записаться

• 1 июля, 20:00 — «Архитектурные паттерны AI‑агентов: как проектировать автономные решения для бизнес‑задач». Записаться

• 6 июля, 20:00 — «Как сделать LLM‑приложение, которое отвечает клиентам по базе знаний компании». Записаться

Инфраструктура и DevOps

• 30 июня, 20:00 — «GitLab CI как конструктор workflow». Записаться

• 1 июля, 20:00 — «Что нужно знать для настройки стабильного интернета? OSPF и протоколы динамической маршрутизации». Записаться

Mobile и тестирование

• 30 июня, 20:00 — «Тестирование UX для мобильных приложений: чек‑лист по основным проверкам». Записаться

• 2 июля, 20:00 — «От API до экрана: создаём Android‑приложение на рекомендуемой архитектуре». Записаться

• 2 июля, 20:00 — «REST Assured & JSON Schema Validator: автоматизация тестирования API на практике». Записаться

Зерокодинг

• 2 июля, 20:00 — «Магия Lovable: как создавать готовые интерфейсы с помощью одного запроса». Записаться

А если хотите углубиться в инфраструктуру, сети и DevOps, смотрите подборку материалов в дайджесте.

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

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

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

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

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

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

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

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

Сделал синхронизатор Телеграм канала в статический сайт.

https://github.com/vitaly-zdanevich/telegram_channel_to_static_website

Сайт генерируется через Zola.

Визуальный дизайн пока прост, минималистичен - без JavaScript. Чёрная и белая темы. Пагинация, теги, страницы. Свой CSS можно вставить через env.

Проект на Rust. Сделал через Codex gpt 5.5 xhigh.

Работает через GitHub Actions - раз в сутки перегенерирует весь сайт. Если пост изменился - он изменяется и на сайте - но в гите остаётся история.

Можно использовать и через cli - для бекапа.

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

Линки на Ютуб превращаются в embed.

Комментарии пока не достаются, реакции тоже - потому что их нету на t.me

На Гитхабе и Гитлабе бесплатного места для статического сайта - гигабайт.

У меня около 1800 постов - отрабатывает за несколько минут

Определённые посты в канале - можно сделать страницами сайта. Как и заданные теги.

Пишите ваши фидбеки.

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

Чтобы эксперимент был чистым, взял стек, с которым не работаю каждый день: Node.js (Express 5) и Vanilla JS. На выходе получился хаб с утилитами: https://toolkitch.ru/

Главная идея проекта - простые инструменты средствами компьютера. Меня всегда раздражало, что популярные онлайн-сервисы гоняют данные на свои сервера, хотя по факту это может выполняться на компьютере. Здесь инструменты работают строго client-side, то есть в браузере пользователя. Ничего не устанавливал и не скачивал, но выполнил на компьютере.

По технической части:

• Express 5 и Bootstrap 5.

• Безопасность: настроил Helmet, прописал строгие CSP заголовки и CORS.

• Деплой: GitHub Actions -> Docker Hub -> docker-compose -> Traefik с авто-SSL.

Писать код помогал ИИ-ассистент KodaCode. Впечатления положительные: нейронка полностью сняла с меня рутину вроде написания докер-файлов, конфигов Traefik и однотипной верстки под 7+ разных инструментов. Моя задача сводилась к контролю архитектуры и безопасности.

Сайт оптимизировал в том числе под ИИ-поисковики (GEO/AEO), чтобы тот же Яндекс Нейро или Perplexity могли индексировать страницы и предлагать эти утилиты пользователям по прямым запросам.

Посмотреть, что получилось, можно по ссылке выше. Будет интересно узнать, как вы используете ИИ в своей инженерной рутине, и какие специализированные плагины/инструменты можете порекомендовать. За критику по UI/UX сайта также буду благодарен.

Хай, коллеги!

Около месяца назад, работая над задачей дообучения локальной модели ИИ, я наткнулся на Modern Web Guidance - сборник руководств (skills - навыков) по современной веб-разработке для агентов ИИ от команды Google Chrome. Ознакомившись со сборником, я понял, что большинство руководств человекам тоже не помешали бы😄 Так появился этот репозиторий. Большая часть руководств, выбранных мной для перевода и адаптации, уже готова. Любые исправления, замечания и предложения приветствуются. Пользуйтесь на здоровье и счастливого кодинга!

AvitoTech пожалуйста обратите внимание на поведение элементов навигации на одной из страниц. https://www.avito.ru/professionals/tools

Обратите внимание на смену ссылок в левом нижнем углу, а также на поведение элементов при наведении курсора.

Что ещё зафиксировано (на видео нет):

• есть пункты меню "А" и "Б" - при наведении на "А" все работает штатно. По мере приближения к пункту "Б" (когда курсор ещё над "А") начинает подсвечиваться пункт "Б"

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

Буду благодарен за обратную связь и ваши идеи в комментариях

Спасибо за внимание

Представлен открытый проект HTML skills for pragmatic visual artifacts для генерации HTML‑файлов за один клик, включая диаграммы, презентации, резюме, отчёты, планы и прочее:

• html — создает любые HTML‑страницы исходя из задачи: от лендингов до портфолио;

• html‑diagram — создает схемы, планы и диаграммы с фокусом на SVG;

• html‑plan — выкатит вам дорожные карты, планы, стратегии, расписания и многое другое.

Пост-анонс. У меня есть лог, что-то среднее между блогом и микроблогом — там я пощу коммерческую рефлексию: заметки про продажи и архитектуру принятия решений.

Сама идея лога появилась недавно, но мыслей для него насобиралось уже порядочно. Пока оформляю просто верстая HTML, но это мягко говоря не удобно. Естественно задумался о статическом генераторе сайтов (SSG), но не брать же чужой когда ты инженер?

Выбор на чём написать свой оказался не простым. Выбирал между мейнстримом (Go, Rust) и андеграундом (Ada, APL). На APL у меня уже есть генератор, поэтому решил поднять планку. В итоге выбрал ассемблер.

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

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

Полный список планируеммых команд (из инженерного черновика):

# Полная сборка всех новых статей
> ./kettlebell
# Пересобрать все статьи
> ./kettlebell --force
# Пересобрать все статьи, предварительно удалив папку ./build
> ./kettlebell --clean --force
# Собрать статьи только для 1 языка, только новые
> ./kettlebell --lang ru
# Пересобрать все статьи для 1 языка
> ./kettlebell --lang ru --force
# Генерация только 1 поста для 1 языка
> ./kettlebell --post ru/new-idea
# Перезаписать существующий пост или элемент в RSS
> ./kettlebell --post ru/llm-as-lvr --force
# Создать блан для поста во всех языках
> ./kettlebell --new last-bastion

Следить за процессом разработки, компиляцией kettlebell.s и первыми реальном времени можно в моем Telegram-канале: Cleanroom 89 (там только хардкор). Или ставьте watch на репозиторий github: kettlebell.

Поддержите подпиской, если вам тоже надоел оверхед современных веб-технологий или просто хочется чего-то неординарного.