У нас было два Solution-архитектора, семьдесят пять микросервисов, пять разных очередей, половина кода на Bash и бесконечное множество костылей всех сортов и поколений, а также GraphQL, gRPC, REST и немного legacy SOAP. Не то чтобы это всё было необходимо для MVP, но когда начинаешь коллекционировать технологии, остановиться уже невозможно.

Как решая проблему можно поднасрать и себе и окружающим и при этом только усугубить проблему?

На этот вопрос сегодня ответит один вендор API!

Итак... Задача... Надо сделать API для продавцов на маркетплейсе. Ну казалось бы... Вроде как не какая-то рокетсайнс задача. У тебя есть данные в БД, надо уметь их отдавать по API. Ключевые задачи которые надо решить:
1) аутентификация
2) нагрузки

Если с первой задачей в целом как бы справились, с оговорочками, но как бы ок.... терпимо...
То со второй задачей - справились как бы... с гораздо большими вопросиками...

Задача со стороны продавца: получать данные по заказам и финансовые отчеты. Казалось бы... Должно быть 2 ручки в API, ну ок максимум до 4, которые ты дергаешь с нужными тебе фильтрами и получаешь все необходимые тебе данные.

Как реализовывается эта механика на стороне ЭТОГО вендора.... фух... ну панеслась....
1) ты дергаешь ручку одну ручку, которая возвращает тебе список заказов
2) ты дергаешь вторую ручку, которы возвращает тебе еще один список заказов, но чуть другой
3) ты дергаешь третью ручку, которая возвращает тебе еще отдельный набор данных, которых нет в 1 и 2 пунктах
4) ты вложенными циклами перебираешь это всё и склеиваешь в один массив
5) далее ты дергаешь еще 6 ручек, чтобы получить список штрафов по заказам или убедиться, что их нет
6) далее ты дергаешь еще 3 ручки, чтобы получить список "задач на сборку"
7) далее по каждой из ручек из предыдущего пункта ты дергаешь еще несколько раз отдельную ручку для получения статуса для каждой из "задач на сборку", чтобы получить статус заказа

И вот только выполнив ВСЁ это ты получаешь данные, чтобы собрать информацию о заказах воедино...

Если вы думали, что это все препятствия на пути - то вы заблуждаетесь....

1) каждый из методов имеет свои таймлимиты... например не более 1 запроса В МИНУТУ Карл!!! То есть ты не можешь отправить запрос с фильтром и получить данные - ты должен постранично с лимитом и оффсетом итерироваться со слипами в 1 МИНУТУ. Иначе тебе будет приходить ошибка о превышении количества запросов.

2) есть метод у которого этот лимит не 1 минута, а 10 минут............

3) если вы думали, что везде есть лимит и оффсет и нормальные фильтры по датам - обломитесь... есть метод, в который можно передать дату... НО он отдает данные не за эту дату... а за календарную неделю со среды до среды в пределах которой находится переданная дата... например отправив дату 05 и 09 февраля 2026 года - вы получите одни и те же данные за неделю... а вам надо за месяц.... но лимит у этого метода 1 запрос в 10 минут... НО... Есть дополнительная опция... если не передавать дату - то вам отгрузят ВСЕ данные которые вообще есть за несколько лет.......... Л - Логика... Чтобы снизить нагрузку - надо вшатать лимит и сделать максимально нежизнеспособный фильтр... просто логично до усёру...

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

И это далеко не все прикольные приколы...

Я вот сижу... читаю эту наркоманию.... И мне живо представляется картина как шел процесс проектирования этого API...

- Итак, коллеги, мы собрались на мозговой штурм по вопросу нагрузок! Ваши предложения!
- А давайте сделаем API настолько запутанным, чтобы разрабы бросали дело на полпути и не справлялись!
- А давайте сделаем настолько странные фильтры, чтобы интегироваться было бы максимально больно и сложно и тогда только самые настойчивые смогут это сделать!
- Надо внедрить тайм-лимиты!
- Надо абсолютно всю постраничную выгрузку данных во всех местах сделать по-разному! Не должно быть двух одинаковых мест с постраничной выгрузкой!
- А еще надо сделать так, чтобы не было одного единого очевидного сквозного идентификатора или называть его везде по-разному!
- А давайте еще добавим кучу кодов ошибок, но при этом тексты самих ошибок будут максимально размыты и без конкретики!
- А еще мы напишем документацию без примеров запросов!
- ОТЛИЧНО! Приняты ВСЕ предложения единогласно!

Какие тут стоит сделать выводы:
1) продумывай архитектуру заранее
2) если ты уже попал в архитектурный капкан и понял, что составленная архитектура не вывозит - то нужно ее пересоздать, а не продолжать в ней барахтаться

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

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

Мне вот реально очень интересно послушать объяснения лида направления на вопрос "откуда тут взялось столько наркомании откровенной?"

Лучшая картинка про ИИ, которую я видел за сегодня 😂😂😂

клиенты всем нужны - клиенты всегда важны 😂😂😂

Актуальная повесточка 😂😂😂

Нейронки. Мысли по поводу.

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

И да и нет... Но заменят многих...

Объясню как это работает на примере своего опыта. У меня есть корпоратная лицензия на claude code и персональная на max X20 тарифе для своих личных пет-проектов.

Для начала несколько фактов.

1) нейронка лажает! лажает сильно! но не часто! И вот это вот ключевая опасность. Получается так, что ты как бы расслабляешься, доверяешься, у тебя постепенно снижается уровень контроля. А потом в какой-то момент БАЦ - и она тебе делает подставу в виде неправильного знака, пишет вместо плюса - минус. И твоя компания в моменте начинает получать убыток. А ты этот код впервые в глаза видишь, потому что отпустил контроль.
Отсюда рождается правило первое, которое я для себя сформулировал так: ревью кода глазами в 100% случаев вплоть до каждой запятой.

2) когнитивная нагрузка. Если ты наивно полагаешь, что купишь себе тариф пожирнее и будешь курить в потолок пока нейронка работает и это сделает твою работу проще - ты заблуждаешься. Использование нейронки делает работу сложнее. Если ранее ты в расслабленном режиме сидел писал код в своем привычном темпе и за день делал 1-2 задачи в потолке, а иногда и 1 задачу в несколько дней - то сейчас ты начинаешь делать 5-6 задач за день, причем огромных по объему... А тебе еще надо все это валидировать, тестировать и т.д. Твой мозг начинает обрабатывать кратно больше информации. Соответственно к вечеру ты уже не бодрячок, а выжатый лимон.

3) да, много кто из-за этого потеряет работу с большой долей вероятности. В первую очередь это касаться джунов будет, потому что с нынешним уровнем знаний - они попросту не нужны бизнесу. Их заменит с лихвой нейронка за 200 баксов в месяц. Также это 100% зацепит тех, кто работает в направлении стандартизированных решений. Например CMS-ки с большой долей вероятности уйдут в небытие, потому что достаточно просто написать тот же самый функционал за 2 дня и иметь полностью кастомное решение и не зависеть от внешнего вендора. Если раньше CMS предлагали быстрое решение типизированных задач, но с завязками на определенные архитектурные решения и вендоров, и основным преимуществом этого подхода была скорость. То сейчас этого преимущества нет. Берется фреймворк и на нем пишется с нуля все то же самое силами нейронки за неделю максимум. Соответственно в цене будут оставаться опытные разработчики, архитекторы, те кто умеют сводить воедино сложные системы, в состоянии оценивать предлагаемые решения со стороны нейронки, а не в слепую соглашаться со всем что она говорит.

4) не маловажный фактор это "ответственность". Ответственность пока что никто не снимал. А как известно хэдам всегда надо иметь кого-то Ответственного за процесс. Свесить ответственность на нейронку - не получится, она тебе просто скажет "сорян, ты прав, а я ошиблась" + она и сама всегда пишет, что мол "я лишь помощник и меня надо перепроверять". Так что... Либо вы будете принимать ответственность, либо вы будете не нужны.

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

Если есть свои мысли по этому поводу - делитесь ))) u r welcome )))

🔐 Обнаружен новый фишинговый сайт

Компания «Солар» выявила фишинговый сайт «Цифровой щит», маскирующийся под образовательный ресурс по кибербезопасности. Злоумышленники предлагают проверить надёжность паролей, но на самом деле стремятся заполучить действующие пароли доступа пользователей. Это подчёркивает важность регулярного обучения сотрудников основам ИБ и использования менеджеров паролей.

Источник: https://d-russia.ru/obnaruzhen-sayt-dlya-seryoznoy-proverki-ib-gramotnosti.html

Сравнение работы с контекстом в Codex и Claude Code

Статья анализирует механизмы сжатия контекста в AI-инструментах Codex и Claude Code. Автор исследует, как эти системы обрабатывают большие объёмы данных и какие методы используют для оптимизации работы с контекстом.

В статье описывается, что Codex CLI работает в двух режимах сжатия контекста: локально для не-codex моделей и через API-метод compact() для codex моделей. Для последних CLI вызывает метод, который возвращает зашифрованный blob. В Claude Code автор сталкивается с проблемой потери эффективности модели при достижении большого количества токенов в одной сессии.

Anthropic предоставляет публичную бета-версию серверной компакции compact_20260112 для Opus 4.7 / 4.6, Sonnet 4.6 и Mythos Preview. В статье отмечается, что промпты для сжатия контекста в Claude Code и Codex CLI практически идентичны, несмотря на различия в подходах к сжатию.

Автор статьи приходит к выводу, что в Codex сжатие контекста происходит более эффективно и своевременно по сравнению с Claude Code.

Источник

Идентификация владельцев доменов через ЕСИА с 1 сентября 2026 года

Статья на Habr от команды Рег.ру посвящена изменениям, которые вносит Федеральный закон № 569-ФЗ в управление доменами в зонах .ru, .рф и .su.

С 1 сентября 2026 года все ключевые операции с доменом (регистрация, продление, смена администратора, смена регистратора, делегирование и изменение NS) будут возможны только при условии, что администратор подтверждён через «Госуслуги». Закон направлен на борьбу с анонимностью владельцев доменов, которая используется для фишинга и мошеннических схем.

Для работы с доменом после 1 сентября нужна именно подтверждённая учётная запись на «Госуслугах». Не подойдёт ни упрощённая, ни стандартная. Подтвердить учётную запись можно онлайн через банк, в центре обслуживания, через «Почту России» или с помощью электронной подписи.

По итогам 2025 года Координационный центр .RU/.РФ заблокировал 60 788 вредоносных доменов в национальных зонах. Фишинг остаётся ведущей угрозой: его доля в обращениях к регистраторам снизилась с 82,6% в 2024 году до 67,9% в 2025-м, но в абсолютных числах он по-прежнему даёт основной поток жалоб.

Источник

Symfony 8.1: динамические атрибуты контроллеров

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

В Symfony 8.1 представлены изменения, которые делают атрибуты контроллеров более динамичными и удобными для переопределения, использования в слушателях событий и расширения с помощью пользовательских функций на основе атрибутов. Атрибуты теперь хранятся в новом атрибуте запроса _controller_attributes, что позволяет слушателям переопределять их для конкретного запроса. Также упрощено представление атрибутов контроллеров: теперь они могут быть представлены в виде плоского списка в порядке их объявления.

Главные нововведения:
• Атрибуты контроллеров теперь хранятся в новом атрибуте запроса _controller_attributes.
• Слушатели могут переопределять атрибуты для конкретного запроса.
• Метод getAttributes() принимает новый аргумент '*' для возврата плоского списка атрибутов.
• ResponseEvent теперь имеет публичное свойство $controllerArgumentsEvent для чтения атрибутов контроллера.

Источник

Блин... Пенсионеры у нас вообще офигевшие... так хорошо живут и всё жалуются и жалуются... и инженеры и преподаватели... всем прям так круто!... Миллионами переводы переводят мошейникам.... Не каждый it-шник так живет как пенсионер/инженер/учитель....

Видимо что-то не так я делаю... пора на пенсию... вот там разбогатею....

🚀 OtezVikentiy JSON-RPC API Bundle 4.1 — релиз

Symfony-бандл для JSON-RPC 2.0 API получил две крупные итерации.

──────────────────────────────
🔒 4.0 — Security hardening
──────────────────────────────
• ErrorSanitizer: любые неожиданные исключения заменяются на дженерик «Internal error.» (-32603), деталь уходит
в PSR-3 логгер. Внутренние трейсы больше не утекают клиенту.
• DoS-лимиты с безопасными дефолтами:
– max_payload_bytes (1 MiB) — размер сырого тела
– max_json_depth (64) — глубина JSON
– max_batch_size (50) — RPC-вызовов в батче
– max_dto_depth (10) — рекурсия гидрации DTO
– max_array_param_size (1000) — элементов в array-параметре
• expose_internal_errors: false по умолчанию.

📝 Гайд по миграции: docs/upgrade-4.0.md

──────────────────────────────
📋 4.1 — Request/Response Logging
──────────────────────────────
• Опциональное логирование каждого RPC-вызова через стандартный Symfony PSR-3 logger. Выключено по умолчанию —
нулевые накладные расходы.
• Дефолтный формат:
Request: [method] {body} context_id: <uuid>
Response: [method] {body} context_id: <uuid>
• Парность Request/Response по context_id. В батче из N вызовов — N разных context_id.
• Маскировка sensitive-полей по PCRE-регексам на имена ключей JSON (рекурсивно на любой глубине).
• 3 точки расширения через DI: кастомный формат, кастомный masker, кастомный генератор context_id.
• 91% test coverage / 370 PHPUnit-тестов.

📝 Подробности: docs/logging.md

──────────────────────────────
• 3 точки расширения через DI: кастомный формат, кастомный masker, кастомный генератор context_id.
• 91% test coverage / 370 PHPUnit-тестов.

📝 Подробности: docs/logging.md

──────────────────────────────
🐘 PHP 8.2+ / Symfony 6.4+ / 7.x · MIT

GitHub: https://github.com/OtezVikentiy/symfony-jsonrpc-api-bundle
Packagist: composer require otezvikentiy/json-rpc-api