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

Всем привет! Два месяца назад я выкладывал пост про нашу тактическую MMO по вселенной Готики, которая работает прямо в браузере как PWA-приложение. Спасибо всем за фидбек в прошлый раз. Сегодня делюсь новым апдейтом: мы реализовали сюжетные квесты с множеством вариантов выбора развилок и концовок.

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

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

«Твой Лагерь может забить сундуки рудой, парень. Но когда ты один спускаешься в заброшенный штрек — клановое знамя тебя не прикроет. В недрах горы решает то, кому ты должен руду и кто готов всадить тебе нож в спину...» — Диего, Глава Призраков Новое правило Барьера Провал — это не конец. Это следующая глава.

Забудь о надписи «Вы погибли». Не прошёл проверку сноровки? Проиграл драку? Сюжет не откатывается назад! Он продолжается по более грязной и опасной ветке: через плен, засады, ранения и потерю хабара.

Архитектура сюжета Один выбор. Несколько судеб.

Это не квесты «сходи-принеси». В начале главы твои решения бесповоротно разделяют сюжет на независимые ветки с уникальными боями и финалами.

Выбирай путь Воровская скрытность, сила клинка или магия тьмы — каждый путь ведёт к своим развязкам. Плати за выбор Помог одним — нажил врагов среди других. Здесь нет «добра» и «зла». Есть только цена твоих решений.

Личная Летопись и Почта Мир продолжает говорить с тобой.

В игре открыт путевой Дневник каторжника от 1-го лица, отражающий твои мысли и решения. А мир вокруг не застывает после диалогов:

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

Тайные силы Колонии Шесть синдикатов. Ни одной безопасной стороны.

В недрах Долины клановое знамя бессильно. Здесь правят тайные союзы и кровная месть.

Бандиты - Налёты и выживание грубой силой. Гильдия Воров - Тайники, отмычки и скупка краденого. Охотники - Лес, шкуры и повадки диких тварей. Шахтёры - Схроны и тайное рабочее братство. Ростовщики - Кабала и безжалостные вышибалы. Кланы Орков - Закон предков и право сильного.

ПРЕМЬЕРА · ДОСТУПНО ОТ 2-ГО УРОВНЯ «Шёпот в Старой Шахте»

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

Тебя ждут: детективное расследование улик с таймером времени, засады в полузатопленных штреках, древние механизмы и выбор между Ворами, Наёмниками Ли, культом Белиара или чистой наживой.

Включиться в игру

BestGothic RPG © 2026 Костры лагерей все еще горят. Мы ждем тебя.

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

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

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

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

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

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

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

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

• Репозиторий: https://github.com/wemake-services/django-modern-rest

• Документация: https://django-modern-rest.rtfd.io

• Описание релиза: https://github.com/wemake-services/django-modern-rest/releases/tag/0.16.0

• Статья на хабре про суть django-modern-rest: https://habr.com/ru/articles/1017036

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

Скорость

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

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

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

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

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

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

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

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

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

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

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

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

from dmr.security.token import concrete_views

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

• Token views

• JWT views

• Session views

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

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

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

Cursor pagination

Extras

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

modify: Final = ModifyEndpoint(SmartResponse)

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

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

Extras

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

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

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

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

OpenAPI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

API Security на практике: что проверить в API перед продом

API может быть закрыт авторизацией, работать по HTTPS и стоять за WAF — и при этом оставаться уязвимым. Например, пользователь успешно вошел в аккаунт и запрашивает /orders/125. Если сервер позволяет заменить 125 на 126 и получить чужой заказ, пароль взламывать вообще не нужно: проблема не в аутентификации, а в том, что API не проверяет права на конкретный объект. 

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

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

• Входные данные и запросы сервера. Параметры, JSON, имена файлов и URL нельзя без проверки передавать дальше в SQL-запросы, команды или внутренние сервисы. Иначе появляются инъекции и SSRF — вплоть до запросов к ресурсам, которые вообще не должны быть доступны извне. 

• Бизнес-логику. Иногда API технически работает правильно, но им легко злоупотребить: бот может перебрать промокоды, занять все слоты бронирования или отправить тысячи SMS-кодов, за каждый из которых платит компания. Обычного общего rate limit здесь бывает недостаточно — ограничения нужно задавать именно на чувствительные операции. 

• Старые и тестовые версии. API меняется, а забытый endpoint может продолжать работать со старой аутентификацией, лишними правами или уязвимыми зависимостями. Поэтому важно вести инвентаризацию методов и версий и отключать то, что больше не используется. 

• Защиту на уровне инфраструктуры. WAF может отфильтровать часть веб-атак, API Gateway — централизовать правила доступа и лимиты, DDoS-защита — отсечь большой поток до сервера. Но эти инструменты не исправят ситуацию, если само API не проверяет, имеет ли пользователь право выполнить конкретное действие. 

В статье собрали основные риски из рейтинга OWASP API Security Top 10, разобрали аутентификацию и авторизацию, SSRF и инъекции, атаки на бизнес-логику, работу с секретами, WAF, API Gateway, rate limiting и мониторинг. В конце — чек-лист, по которому можно пройтись по своему API и понять, где искать основные пробелы в защите. Если хотите пройти проверку целиком, читайте материал в блоге Рег.облака.

pear-crypt: клиентское шифрование

pear-crypt — небольшая TypeScript-библиотека, которая шифрует на клиенте и больше ничего не делает. На входе — пароль, PIN или Recovery Code, на выходе — ciphertext, который можно положить хоть в S3, хоть в Postgres. Пароль в этот blob не зашит.

• Библиотека: github.com/yamakca/pear-crypt

• Демо: github.com/yamakca/pear-crypt-demo

Лицензия MIT. Из зависимостей только hash-wasm: нативного Argon2id в браузере нет. AES-256-GCM и HKDF-SHA256 берутся из Web Crypto, без велосипедостроения.

Почему бы не собирать самому?

Типичный сценарий: сгенерить мастер-ключ, обернуть его паролем, тем же ключом зашифровать файл и отдельно мету. Если каждый раз клеить это из crypto.subtle, через год уже не вспомнить, был ли AAD, какой длины nonce и куда делась salt.

Здесь wire-format зашит в спеке и в тестовых векторах. Поменять раскладку байтов «чуть-чуть» нельзя: старый ciphertext просто перестанет открываться.

Под капотом

Мастер-ключ — 32 случайных байта. В открытом виде наружу не светится: только внутри AES-GCM-обёртки. Ключ обёртки получается из секрета через Argon2id: 32 МиБ памяти, два прохода, без раскладки на несколько ядер. Параметры KDF лежат в JSON рядом с nonce и ciphertext, чтобы было видно, чем именно заворачивали.

Дальше HKDF с пустой солью режет мастер-ключ на домены. В info зашито, для чего ключ: файл или метаданные. Строка вида pear-keep-file:{uid} — это и есть domain separation. Файл и его имя одним ключом не вскрываются: это разные info.

Сам файл — кадр версия | nonce 12 байт | ciphertext и GCM-тег. AAD pear-keep-file:{uid}:{bindAt} привязывает blob к идентификатору и поколению содержимого. Подменили uid или bindAt — тег не сойдётся, расшифровки не будет.

Метаданные — тот же кадр, другой ключ и JSON внутри: подпись, комментарий, время, etc. Recovery Code — 25 символов из алфавита без сомнительных похожих, группами по пять. Им заворачивается тот же мастер-ключ, но отдельно от пароля: пароль забыл — ищи бумажку с кодом.

Как проверяется, что байты не разъехались

В репозитории лежат docs/crypto/SPEC.md и JSON с векторами. Тесты бьют не только в прямую «зашифровал и тут же расшифровал», но и в зафиксированный ciphertext. Покрытие держится выше 90%. Поменяли src/ — пересобрали векторы через npm run export:vectors и закоммитили вместе с кодом. Иначе спецификация и реализация тихо разъедутся.

Чего в комплекте нет

Библиотека не решает, куда класть ciphertext, как устроен логин и когда блокировать сессию. Длину PIN тоже не проверяет. И кофе не варит.

Ошибки — PearKeepCryptoError с машинным кодом: wrongPassword, cannotDecryptMetadata и дальше по списку. Человеческого текста ошибок нет и не будет. Как и i18n.

Итого

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

Drizzle ORM: типобезопасный SQL без магии тяжёлых ORM

Привет, я Сергей Маркизов, бэкенд-разработчик в веб-продакшне Далее. В своих проектах я часто использую Drizzle ORM — инструмент для TypeScript-разработчиков, которым нужны строгие типы, но не хочется прятать SQL за несколькими слоями абстракций.

Классические ORM избавляют от шаблонного кода, однако на сложных проектах их удобство иногда превращается в ограничение. Появляются скрытое поведение, громоздкий API и сложности с нестандартными запросами. А при переходе на QueryBuilder или raw SQL часть преимуществ ORM может потеряться.

Drizzle предлагает компромисс: запросы остаются похожими на SQL, а TypeScript проверяет их на основе схемы базы данных.

Схема — это TypeScript-код

Например, так можно описать таблицу пользователей:

const activeUsers = await db

  .select({

    id: users.id,

    email: users.email,

  })

  .from(users)

  .where(eq(users.isActive, true))

  .orderBy(desc(users.createdAt))

  .limit(10);

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

type NewUser = typeof users.$inferInsert;

const user: NewUser = {

  email: 'user@example.com',

};

Если передать поле неправильного типа или пропустить обязательное значение, TypeScript сообщит об ошибке ещё до запуска приложения.

Запросы остаются похожими на SQL

Для простых операций можно использовать ORM API, а более сложные запросы собирать через типизированный конструктор:

const activeUsers = await db

  .select({

    id: users.id,

    email: users.email,

  })

  .from(users)

  .where(eq(users.isActive, true))

  .orderBy(desc(users.createdAt))

  .limit(10);

Здесь нет отдельного языка запросов, который нужно мысленно переводить в SQL. select, from, where и orderBy остаются на своих местах, при этом поля и результат запроса типизированы.

Если возможностей конструктора недостаточно, можно перейти к SQL-фрагментам:

const result = await db

  .select({

    total: sql<number>`count(*)`.mapWith(Number),

  })

  .from(users) 

Это удобно для агрегатов, CTE, специфичных для конкретной СУБД функций и других случаев, когда бороться с абстракцией сложнее, чем явно описать запрос.

Когда Drizzle особенно полезен

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

• пишут на TypeScript и работают с PostgreSQL, MySQL или SQLite;

• знают SQL и хотят контролировать реальные запросы;

• сталкиваются с ограничениями Prisma или TypeORM;

• не хотят дублировать описание таблиц и TypeScript-типы;

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

Drizzle не привязан к конкретному фреймворку. Его можно использовать с Next.js, NestJS, Remix и другими TypeScript-решениями.

Но «магии» здесь действительно меньше

Это одновременно преимущество и ограничение Drizzle. ORM не скрывает работу с базой и не берёт на себя всю инфраструктуру.

Миграции нужно отдельно встроить в CI/CD, read/write split для реплик — реализовать на уровне приложения. Drizzle работает только с SQL-базами, а его экосистема пока меньше, чем у более зрелых ORM. Проект активно развивается, поэтому документация иногда не успевает за изменениями API.

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

Drizzle — это не ORM для тех, кто хочет забыть об SQL

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

В полной версии статьи я подробнее разобрал описание связей, миграции, CRUD-операции, CTE, транзакции, оператор sql, расширения и ограничения Drizzle ORM.

Буду рад почитать о вашем опыте работы с Drizzle в комментариях. 

Выделенный сервер на Xeon E3: разбираем варианты переезда 

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

В SpaceWeb мы держим линейку на Xeon E3-1270 v3 — процессоре не новом, но зато проверенном годами. Варьируя лишь объем RAM и тип накопителей, можно решить почти любую задачу: от легкого сайта до файлового хранилища на терабайты.

Какую выбрать конфигурацию:

• Сайт или несколько веб-проектов. 16 ГБ RAM и пара SSD — база для Битрикса, WordPress или интернет-магазина. Если проектов больше, тогда берем 32 ГБ.

• Интернет-магазин или портал с контентом. Тот же процессор, но диски побольше: под базы, картинки и логи.

• Бэкапы, архивы, почта. Здесь скорость SSD не нужна, поэтому ставим HDD на терабайты. Дешевле, а задачу решает.

• Сайт и файлы на одном сервере. Гибрид: SSD под приложение, HDD под документы. Удобно для корпоративных порталов и Bitrix24.

Посмотреть полные характеристики и заказать нужную конфигурацию можно на сайте SpaceWeb. А если не нашли подходящий вариант — просто напишите нам на почту dedic@sweb.ru, мы поможем подобрать решение вручную.

Cloudflare представила сервис, который позволяет захостить проект в один клик — Cloudflare Quick Tunnels превращает локальный сервер в публичную ссылку:

• всё работает через утилиту cloudflared, где нужно указать адрес запущенного сайта — получить ссылку с HTTPS;

• настраивать роутер и открывать входящие порты не нужно, шифрование и защиту от DDoS берёт на себя Cloudflare;

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

• ссылка временная: остановили туннель — доступ закрылся;

• работает бесплатно, без регистрации и покупки домена.
  

Акт подписан, но система не работает:  суд вернул 185 млн 

В IT-проектах бытует мнение: если промежуточный акт подписан, деньги за этап не надо возвращать. Арбитражное дело, дошедшее до Верховного суда России, показало обратное.

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

Суть дела

Между Заказчиком и Исполнителем был заключён контракт на создание сложной информационной системы. За первый этап работ Заказчик оплатил Исполнителю 185,9 млн руб. Однако в ходе дальнейшей реализации проекта выяснилось, что система не обеспечивает требуемый функционал и не может использоваться по назначению.

Проблема

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

Решение суда

Апелляционный суд расторг  контракт и взыскал с Исполнителя 185,9 млн руб. неосновательного обогащения и почти 4 млн руб. неустойки. Кассационный суд  и Верховный Суд РФ поддержали этот вывод. Суды указали на отсутствие для Заказчика потребительской ценности результата работ и недоказанность полноценного встречного предоставления на перечисленную сумму.

Что делать, чтобы не повторилась ситуация

Для Заказчика:

· Включайте в контракт условие о потребительской ценности как критерии приёмки: не просто «акт подписан», а «система работает в заданных режимах, согласно ТЗ».

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

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

· Проводите независимую экспертизу до подписания итогового акта.

Для Исполнителя:

· Не полагайтесь на подписанные промежуточные акты как на гарантию оплаты — суд смотрит на итоговый результат.

· Перед сдачей этапа убеждайтесь, что функционал соответствует технической документации и может быть проверен Заказчиком.

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

· Включайте в договор ограничение ответственности по объёму и срокам, если это возможно.

Если проект зашёл в тупик, а Исполнитель ссылается на подписанные акты — это не приговор.

Провожу анализ ситуации на стыке IT, права и финансов.

Пишите @RRSadykov

Сайты wordpress.org и developer.wordpress.org с прошлой недели недоступны из сетей российских интернет-провайдеров.

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

Судя по косвенным признакам IP-адрес 66.6.42.252, на который указывают оба доменных имени попал под блокировку со стороны РКН. По крайней мере запросы по 443 и 80 порту к этому адресу не уходят дальше шлюза провайдера, что указывает на то, что дело именно в блокировке с нашей стороны, хотя сами провайдеры заявляют в один голос, что дело на стороне сайта wordpress.org. Проблема массовая, даже тикет в трекере WordPress открыли: https://meta.trac.wordpress.org/ticket/8432

Ни доменное имя ни IP-адрес 66.6.42.252 в списках заблокированных не значатся. Никакой информации от РКН об этой блокировке также не было. Что же происходит и когда все это кончится? Может огласка проблемы на Хабре поможет ускорить решение этой проблемы?

UPD: Буквально только что (спустя полчаса после публикации этого поста) сайт wordpress.org стал доступен отсовсюду. Неизвестно повлияла ли эта публикация или что-то еще, но чудесным образом проблема исчезла. Всем спасибо!

OpenAI сообщила о доработке сервиса ChatGPT Sites, который позволяет по описанию от пользователя создавать, публиковать сайты и простые веб-приложения. Теперь над ИИ-проектом сайта могут работать несколько пользователей.

Вот несколько способов начать работу с сервисом Sites, если пользователем нужно вдохновение:

• запускайте панели управления для отслеживания и обмена результатами;

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

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

• игры (например, викторины) для дня рождения;

• карты ваших любимых местных мест для гостей из других городов;

• планы поездок, чтобы все были на одной волне.

BITCORD - объявляет конкурс на разработку: Валютный конвертер и Прогноз погоды!

Привет, Хабр! Мы ищем талантливых PHP-разработчиков, готовых создать два полезных, легковесных сервиса для нашей площадки. Главная фишка — ориентация на текстовый интерфейс (режим чата) и полная автономность кода.

Ниже представлены подробные требования к конкурсным работам.

Что нужно разработать?

Предстоит создать два независимых сервиса. Каждый сервис должен быть оформлен в виде одного самостоятельного PHP-файла, который внутри себя обращается к любым популярным сторонним API, но не привязан к жестким собственным эндпоинтам. Сервисы обязательно должны быть мультиязычными и возвращать результаты на том языке (локали), который передан в качестве входного параметра (ru, en, es...).

1. Сервис конвертации валют (converter.php)

• Интерфейс: Строго текстовый, адаптированный под логику чат-бота.

• Функциональность: Возможность выбора исходной и целевой валюты из динамического или предзаданного списка, ввод суммы и моментальное получение результата.

• Интеграция: Использование надежных внешних API для получения актуальных курсов валют.

2. Сервис прогноза погоды (weather.php)

• Интерфейс: Строго текстовый, структурированный для удобного чтения в чате.

• Объем данных: Сервис должен возвращать текстовую сводку погоды на:

  • Текущий день

  • Завтрашний день

  • Ближайшие 10 дней

• Интеграция: Использование популярных погодных API (например, OpenWeatherMap, WeatherAPI и т.д.).

Технические требования

• Язык программирования: PHP 8.x (чистый код, без тяжелых фреймворков вроде Laravel/Symfony на базовом уровне).

• Формат вывода: Только структурированный текст. Никакого HTML-структурирования или тяжелой графики - результат должен идеально смотреться в обычном CLI-терминале или окне мессенджера.

• Архитектура: Код должен быть чистым и легко встраиваемым в существующие чат-платформы.

• Безопасность: В каждом файле должна выполняться аутентификация по токену (Bearer Token) для защиты доступа к сервису.

Призы и сроки

• Победителю: Умная колонка Яндекс станция мини (с Алисой) или контракт на долгосрочное сотрудничество.

• Другие интересные решения: Денежный приз в криптовалюте мессенджера Bitcord (BTCD). Сумма будет зачислена на ваш кошелек в приложении Bitcord.

Сроки

• Дедлайн приема работ: 1 Октября 2026 г.

Как принять участие?

Опубликуйте ваш код на GitHub (публичный репозиторий) и отправьте ссылку в комментарии к этому посту или в мессенджер Bitcord на имя администратора @administrator. В README обязательно приложите пример передачи Bearer-токена в заголовках, краткую инструкцию по запуску и примеры текстовых команд.

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

Энтузиаст представил виртуальный музей старых мобильных устройств. Проект находится в разработке. Пока что для изучения доступны Nokia 3250, 5300, N93i, 5310, Lumia 1020. Каждая модель воссоздана в 3D с поразительной точностью. Мобильное устройство можно выключить, изучить меню, а также воспроизводить медиа файлы

Я вот тут думал, что просто обалденно: когда-то ведь говорили, что нейронка не заменит девопсов. Да, возможно, для каких-то крупных enterprise-решений, где банковская система, возможно, и не заменит (пока что). Но, будем честны, сколько из нас работает с обычным хостингом и сколько в банке? Сколько девопсов реально работает в крупных корпорациях?

Сейчас началась просто гонка искусственного интеллекта. Каждый хочет сделать модель лучше, мощнее, быстрее, скажем так, меряются бенчмарками. Хотя по факту для большинства задач с лихвой хватает текущих моделей. Для 80% людей за глаза хватит и обычного DeepSeek: спросить, как варить пельмени, или просто поныть. Зайдите на YouTube. Сколько человек там реально занимаются исследованиями? Большинство видосов — это приколы всякие с нейросетями. Ну серьёзно, блин. Для планирования с лихвой хватило бы Opus 5, а для обычного кода — Sonnet 5 просто с головой. И я бы пользовался моделью предыдущего поколения типа Opus 4.8, если бы она стоила в 2 раз дешевле.

Тут вышла модель Gemini 3.8 Flash, и я решил её проверить. Если бы не вышла 3.8, я бы запустил Sonnet 5, потому что она постабильнее и даже ее хватило бы. А Gemini 3.7 хоть и быстрая, но сильно галлюцинирует и делает часто то, что не нужно, слишком независимая.

Сегодня днём я как раз переносил на новый хостинг 10 сайтов, с одной ISP-панели на другую. Шесть сайтов перевелись нормально, это обычные вордпрессовские сайты. А вот четыре уже сразу легли. На одном был Laravel, на другом админка со своей базой, ещё на одном кастомные таблицы, где база при импорте вообще не перенеслась. Техподдержка хостинга мне бы это по-любому не сделала: там принципиально разные проекты и нужен был доступ к старому хостингу. Сколько бы заняло времени это через техподдержку?

Я дал доступ — всего лишь логин и пароль к хостингу. Всего лишь. Сделал буквально два промпта. И за 70 минут в одной сессии Gemini просто поднял все сайты: пересобрал данные в Laravel, поменял адреса где нужно, докачал базы, которых не хватало. Причём для этого всего хватило модели Gemini Flash 3.8, не говоря уже о каком-нибудь Opus 5 или более мощных моделях.

Единственное, кого пока не заменит нейросеть, — это 1С-ников. И то не потому, что там суперсложные проекты, огромный легаси-код или суперсложная бизнес-логика. Уже сейчас нейросеть кушает за раз огромные проекты. Единственное, что пока спасает 1С-ников, — это то, что нельзя подключить Claude Code напрямую к написанию кода 1С. И то, в принципе, реально же задавать промпт и руками копировать-вставить. Но как только придумают, как интегрировать искусственный интеллект в 1С, — 1С-ники тоже заметят последсвия ИИ.

Третий день Летнего ТехФеста — в нашем новом влоге

Мы заглянули в офис Okko, чтобы посмотреть, как устроена AI-кухня. Было технично, честно и очень вдохновляюще.

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

Ещё больше о мероприятиях — в нашем TG-канале.

Новый закон об ИИ вступает в силу 1 сентября: что изменится для владельцев сайтов

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

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

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

Сначала напомню, о каком законе идет речь👇

Федеральный закон № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации»

Рамочный закон, который регулирует большие фундаментальные модели вроде ГигаЧата или Алисы. Они имеют от 1 миллиарда параметров и способны выполнять интеллектуальные задачи на уровне человека или выше. Если компания просто использует готовые модели в своих сервисах, закон на нее напрямую не распространяется.

Полный текст

Основная часть закона вступает в силу с 1 сентября 2026 года, отдельные нормы — с 1 марта 2027-го.

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

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

Национальный статус дает два преимущества: можно свободно обучаться на объектах авторского права и получить доступ к государственным данным. 

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

Это классический механизм opt-out: нейросеть по умолчанию может парсить и анализировать контент, если владелец заранее не ограничил это право. Пока непонятно, какой именно технический сигнал признают достаточным ограничителем — это открытый вопрос и в российской, и в европейской практике, где действует похожая логика.

Обязательная маркировка ИИ-контента — просто слух

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

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

Прямого запрета на использование иностранных моделей в законе нет

Правительство сможет регулировать объекты и сферы, где разрешено применять только суверенные модели. Подробностей пока нет, но мы знаем, что будет поблажка. Если система уже работает к 1 марта 2027 года и данные хранятся в России, владельцы смогут использовать иностранный ИИ до сентября 2032 года. 

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

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

1. Какие государственные данные откроют для обучения? 

2. Как будет работать opt-out и каким будет технический механизм отказа правообладателя?

3. Где будут разрешены только суверенные модели и насколько широким будет этот список?

4. Что такое достаточная «техническая возможностью маркировки»?

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

Возможно я не открою Америку. Но для меня это было сюрпризом. Хочу поделиться тут, чтобы для кого-то другого это не стало неприятным сюрпризом.

Купил домен, залил сервис на vps, и обнаружил, что прямое обращение возможно только через зарубежный vpn. Проверил домен через сервис РКН и с удивлением узнал, что на него наложены санкции аж с 2016 года.

Пришлось писать обращение, через форму того же РКН. Теперь ждать ответа максимум 30 дней.

Не будьте как я. Проверяйте будущий домен через сервис чёрного листа РКН.

Много лет висело без откликов у меня на hh.ru резюме на вакансию «Web-реаниматор старых сайтов» и вдруг прилетела «подработка»…

У небольшой организации занимающейся разработкой очень специфичной техники есть в интернете несколько информационных сайтов на Joomla 3 и уже года 4 без каких-либо изменений, и, соответственно без необходимости иметь сотрудника для их поддержки.
И что примечательно, у этих сайтов в среднем около 1 посещения в неделю..

Но месяц назад на двух сайтах вдруг появились вместо заглавных страниц сообщения «Взломан CoupDeGrace» и «Взломан ANTONKILL».
Так у меня появилась хоть какая-то работа за последние 4 года.
Убрать заставки взломщиков оказалось достаточно просто, сложнее перекрыть дальнейшие возможности для подобных хулиганств – не представляю как удалить из работающего сайта модули Helix и Sppagebuilder, через которые происходит основной вход «хулиганов»… частично их «деактивировал».  Но наверняка есть и другие способы, про которые я тогда не знал.
Обновлять Joomla до актуальной версии занятие долгое и непредсказуемое, а потому один сайт остался жить просто почищенным от заставок «Взломан …», а их там оказалось несколько десятков, а другой достаточно быстро перелопачен в статичные html страницы.
Первый этап «реанимации» закончен и очень постепенно начался второй – поиск нового движка для сайтов. Желательно отечественного производства, с активной поддержкой, чётким MVC, а ещё и бесплатным… в общем – проблематичные условия, но несколько кандидатов нашлось, и даже лидер образовался с самым маленьким количеством проблем на входе.

Но опять возникло «НО»!
Тот сайт, что остался крутиться на Joomla был заселён несколькими бэкдорами и это обнаружилось совершенно случайно только потому, что развили очень активную деятельность и буквально подвесили виртуальный сервер с очень скромными ресурсами.

За прошедшие выходные я понял, что мои возможности уже сильно устарели и резюме на вакансию «Web-реаниматор» надо бы убрать…
Мало того, что «искусство обфусцирования» вышло за уровни моего понимания, но как можно перехватывать пересылаемый по ftp на сайт index.php и класть его в корень с уже вписанным «вирусом» - мне уже видимо не осознать.

В прошлом году на секции «Слабое звено ИБ» один выступающий рассказал о своём эксперименте по «взлому» - всего $10 долларов на оплату токенов и ВСЁ!
Про миллион за взлом «белым хакерам» можно забыть – нейросети обесценили труд этих специалистов на несколько порядков.

Любая известная и популярная CMS со средствами «web-администрирования» и самообновления уже имеет в себе «парадные ворота» для взлома и заселения всем чем захочется.

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

А может не всё так грустно?
Может есть уже простые решения, про которые всем кроме меня всё давно известно?

Сделал S3-браузер в один HTML-файл (S3Feather)

TL;DR: один index.html, открываешь в браузере, работаешь с бакетом. Без установки и сервера. AWS, MinIO, Cloudflare R2 и вообще любой S3-совместимый. Потыкать, код.

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

Как устроено Один файл: HTML, JS, CSS, логика подписи запросов. Открываешь локально или хостишь чоб было доступно везде, ну или уже захосченый - линк выше.

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

Что умеет

• Листинг, загрузка, скачивание, удаление

• Несколько файлов сразу в ZIP прямо в браузере

• Presigned-ссылки для шаринга

• Drag and drop

• Адресная строка с s3:// и командная палитра по Ctrl+K

• Flatten-режим: показывает всё рекурсивно плоским списком, когда помнишь имя файла но не помнишь папку

На Android качал файлы пакетами по несколько гигабайт, работает нормально.

Буду рад фидбеку, особенно от тех кто использует нестандартные S3-совместимые хранилища.