Внезапно: Почему опытные айтишники учатся лучше новичков?!

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

И какой же контраст с курсами для новичков! Вот что отличает учеников продвинутых курсов:

1️⃣ Им интересно. Они слушают, просят повторить, если что-то не поняли, осмысляют и реально делают ДЗ (хотя и не все).

2️⃣ Они задают вопросы. Много, неожиданные, дотошные. За 6 потоков вопросы ни разу не повторялись!

Отдельно хочу похвалить GetAnalyst: только у них я видела, что из-за вопросов могут добавить новые блоки в обучение или записать доп. уроки и материалы. Хотя сама программа и так продуманная.

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

3️⃣ У опытных специалистов выше процент посещаемости. Для меня это стало открытием. У людей, которые уже хорошо зарабатывают и давно в профессии, время на курс находится. А вот у тех, кто только хочет войти в профессию часто нет. И зачем вы нам такие нужны, а?

4️⃣ Делятся опытом и учатся друг у друга. Увы, не всегда. Но когда такие диалоги завязываются это очень интересно. Для меня это, пожалуй, самое ценное. В общем, продвинутые уровни, это когда учиться у соседа по парте не позор, а привилегия)

Вероятно, с опытом в ИТ люди учатся глубже мыслить и нести ответственность за своё обучение и знания.

С другой стороны, я сама чаще прохожу курсы как новичок. Молчу, прохожу только те уроки что мне интересны, как сталкер читаю переписки в чате, а копать предпочитаю в одиночку. А как вы?

💃Я немного загуляла или срез августа💃

На этих выходных я немного загуляла: В субботу за обедом решила посмотреть «Удивительная миссис Мейзел», дальше на 12 часов все как в тумане: сериал, кошки, я , кровать. Ни о чём не жалею.

Если вы тоже ушли в загул и пропустили что было интересного в блоге, вот лучшая выжимка:

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

📌 Приняла участие в конкурсе блогов #продолжи_мысль_SE Не выиграла, но это был отличный повод поделиться новым для меня термином - харденинг. В свете атак, которые в августе сыпались на российские ИТ-компании, тема особенно актуальна.

📌 Под другим моим конкурсным постом развернулось отличное обсуждение про промты для ИИ Советую не пропустить: там стоящая вашего внимания ментальная карта (теперь без регистрации) от Крутого AI-аналитика. Кстати, именно она в конкурс выиграла!

📌 Разбирала на котиках что Swagger ≠ OpenAPI. В комментариях вышел не менее замечательный диалог, который вернул вопросу неоднозначность, и показал что между понятиями всё же можно ставить знак равенства.

📌Ну и без неудач этот месяц не прошел. Самый большой страх спикера выстрелил!

В общем август вышел насыщенным. Очень рада что уже появляются такие интересные диалоги и обсуждения под постами. Спасибо всем кто откликается. Ну а под этим предлагаю поделиться, какие сериалы и книги вас заставляли уйти в незапланированный загул)

Телу у DELETE: быть или не быть?!

Часть 1️⃣

Конечно, утренний опрос был с подвохом 😬. Давайте разбираться

Как правило, метод DELETE в REST API реализовывается без тела запроса. А над каким объектом совершаем действие указываем в URI.

 DELETE /resource/{id}

❓Что говорят стандарты❓

😮‍💨 В диссертации Роя Филдинга (родоначальника REST API) я нашла главу про REST на HTTP, но отдельные методы он подробно не разбирает.

😮‍💨 В стандарте по семантике HTTP (RFC9110, раздел 9.3.5) указывается, что тело у DELETE может быть. 🤪Но с пометкой, что семантика не регламентирована, поэтому нет гарантий, что оно будет обработано. Более того, некоторые серверы могут такой запрос отклонить из-за рисков атак.

😮‍💨 В OpenAPI 2.0 тело запроса не предусмотрено. Сколько раз на меня ругались линтеры не хочется вспоминать. Но вот уже в 3.0 такая возможность есть. Хотя и с пометкой возможного отклонение сервисами.

😎 Таким образом получается, что тело в DELETE вполне может быть. Вопрос только зачем?! 😎

😊 Множественное удаление 😊

Вполне возможно, что вместо 100 вызовов, типа

DELETE /items/{id} 

вам будет удобнее делать один

DELETE /items
{
  "id": [1, 2, 3, 4]
}

😊 Удаление связей или под-ресурсов 😊
Когда в выбранном объекте нужно удалить, какую то его часть.

У Spotify есть отличный пример: удаление треков из плейлиста. + интересная работа со Snapshot.

DELETE /playlists/{playlist_id}/tracks
{
  "tracks": [
    { "uri": "string" }
  ],
  "snapshot_id": "string"
}

😂Удаление с условиями😂
Когда удаление, должно произойти, только если выполнилось некоторое условие. Я о таком читала только в книге, поэтому если сталкивались на практике поделитесь.

Ну а мне нравится, как ElasticSearch решают эту задачу без использования тела запроса

😂Подпись на удаление😂

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

DELETE /api/v3/userDataStream
{ "signature": "base64(hmac_sha256(secret, payload))" }

 

На практике тоже не встречала, но видела интересное обсуждение на форуме. В реальности, такой пример более «REST-канонично» можно реализовать, например как Binance.

Вероятно, могут быть другие кейсы. Я на практике использовала и встречала только 1 и 2. Поэтому если у вас есть такие из реальной практике поделитесь в комментариях 👀

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

Как раз о рисках я расскажу в следующей части.

#СистемныйАнализ #интеграции #RESTAPI #OPENAPI

Тело у DELETE: риски разработки

Окей, решили, что у DELETE будет тело запроса. С чем мы, как разработчики, можем столкнуться?

1️⃣ Множественное удаление

1️⃣ Ваша ролевая модель должна предусматривать, что «можно удалить всё».

2️⃣ Нагрузка на БД. Нужно осмысленно формировать запросы и проводить нагрузочные тестирования.

3️⃣ Допустим, из 4 объектов удалились первые 2, а на 3-й не хватает прав. Что будете делать? Отдавать частичный успех (207)? Откатывать удаление? Или продолжать удалять дальше?

4️⃣ DELETE должен быть идемпотентным (по стандарту). Для вас критично, если это не так?

2️⃣ Удаление подресурсов

1️⃣ Здесь снова упираемся в права. У вас должны быть права не только на каталог, но и на его объекты и действия с ними. Бывают и такие тонкости: права на работу с объектами и каталогом есть, а на изменение конкретных связей — нет. Это не всегда очевидно до тестирования.

2️⃣ Все те же проблемы, что и при массовом удалении, если оно предусмотрено.

3️⃣ Удаление по условиям
1️⃣Удар по производительности: чем сложнее фильтр, тем тяжелее запрос.
2️⃣Есть простор для инъекций. Нужно реализовать «белый список» условий и операторов, плюс заморочиться с валидацией.

3️⃣Условия могут быть массовыми → добавляем к этому риски массового удаления.

4️⃣ Подпись операции
Здесь я совсем не эксперт, но отмечу из общей практики:

1️⃣ Возможность утечки. В заголовках (Authorization, Cookie/Set-Cookie, X-Api-Key, X-Signature) обычно можно скрыть данные настройками. А вот в теле запроса это уже на вас: или не логируете тело, или делаете белый список полей.

2️⃣ Потребуются настройки прокси, чтобы они понимали, как работать «с таким сюрпризом».

3️⃣ Если вы используете готовые фреймворки для возврата ошибок, убедитесь, что они не вернут всё тело запроса в ответ целиком.

Ну и помним что не все SDK и сервисы работают с телом запроса у DELETE.

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

Ну а теперь у нас есть понимание: у DELETE тело может быть, но перед этим стоит семь раз подумать. Насколько это было полезно и занимательно отметь реакциями.

👍 - Да, больше таких постов
👀 - сложно и не понятно
👎🏼 - это уже давно всем известно\я могу посмотреть это в ИИ
🤡 - я читаю ради развлекательного контента, а не вот это все

У меня особая любовь к мероприятиям из Ульяновска, даже если они проходят в Питере.
#stopworking!
Речь, конечно, про Стачку 2–3 октября 2025

Я буду там лично с докладом. 👀Приготовила кое-что новенькое 👀

Нравится что «Стачка» — это мультиконференция. Можно заглянуть на секцию архитектуры, ИБ, Python, а после вернуться к аналитикам.

Я уже присмотрела для себя несколько докладов:

1️⃣ От REST к MCP: как LLM меняют принципы проектирования API и архитектуры систем
2️⃣ Воркшоп «Ресурсный баттл» от Владимира Бурмистрова
3️⃣ UX в кибербезопасности: от инженерного хаоса к понятным решениям
4️⃣ От простого API к гибкой платформе: BDUI бэкенда в Яндекс Еде
5️⃣ Прожарим риски по полной: техника MEAT в работе аналитика от Анастасии Московкиной(получится познакомиться лично!) и Натальи Леоновой

Программа уже почти полностью опубликована, самое время понять: нужно вам это или нет.
А если нужно напишите мне есть промокод

Агрегаты - бойцовский клуб в мире ИТ

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

Нам, системным аналитикам, это часто даётся нелегко. Целый ад терминологии.

😂Если обратиться к создателю Event Storming и его книге по методу, то там можно найти забавную рекомендацию: «Не говорите, что такое агрегаты".😂

Ха-ха, Брандолини, очень смешно. Когда я продвигала Event Storming и началась сессия с очень занятыми архитекторами (скептически настроенными), провернуть такое у меня не получилось. 😉😉 Коллеги воспринимали эту подачу как «Зачем ты тратишь наше время?».

На следующих встречах я подготовила описания агрегатов. Но и они не зашли моим программистам и архитекторам. Тогда я предложила вместе разобраться, из чего агрегат состоит: мы коснулись Value Object и Entity, корня агрегата и обсудили, почему это важно с примерами агрегатов.

В книге Влада Хононова «Изучаем DDD» определение всё же есть. Но какое! См. фото. А потом ещё 8 страниц поясняющего текста.

😬😬Господа Хононов и Брандолини знают толк в извращениях.😬😬

Для тренингов я пыталась найти объяснения попроще. Пока что мне более-менее нравятся материалы:

Статья где про агрегаты рассказывается через их антипаттерн

Короткое определение от Мартина Фаулера.

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

Но в целом поиск продолжается. Поэтому интересно, вы уже проходили этап понимания агрегатов в контексте DDD и Event Storming? Поделитесь, как у вас прошло. Может, у вас есть более удачные материалы?

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

#EventStorming #СистемныйАнализ #DDD #агрегат

🎉EventStorming — это вечеринка! 🎉

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

Это презентация Альберто Брандолини. Того самого, кто продвигает EventStorming. Посмотрите, как она сделана: часть слайдов он рисовал от руки (ну или его дизайнер). Красиво, просто, доступно и смешно.

И да, он буквально начинает свой рассказ с мысли:

«EventStorming — это вечеринка!»

Так что проводить EventStorming в субботу оказалось очень символично. Всем вечеринок, коллеги! 🎊

😱Шок просто😱 Результатом прошедшего тренинга стало, пусть и с болью и переживаниями, понимание: почему на Event Storming действительно не стоит говорить об агрегатах!

Господин Брандолини прости мои шутки над тобой!

Одновременно очевидно почему нам, системным аналитикам, так хочется их обсуждать и свести к ER-диаграммам. Здесь всё просто: сущности, из которых потенциально может состоять агрегат, для нас понятная и знакомая часть работы А вот бизнес-контексты в понимании Event Storming - нет.

Здесь собаку и зарыли:

1) Часть людей на сессии будет чувствовать себя лишними.
2) Снова уйдём от бизнеса в сторону техники. А это нарушает главную задачу синхронизацию бизнес-экспертов и разработчиков.

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

Это отлично вяжется и с моей практикой: мы агрегаты вообще не выявляем.