👋1000 дней с зелёной птицей👋

Когда я только начала заниматься в Duolingo, была в восторге! Игровые механики выкручены на максимум, добавила друзей и вот вы все собираетесь в баре, не общаетесь, а пытаетесь удовлетворить запросы Дуо, чтобы он не начал присылать вам угрозы. Заниматься каждый день получалось не всегда, но я старалась. Однажды даже в азиатском отеле, в отпуске, полчаса ждала, пока начнет работать wi-fi и я смогу сделать хоть одно задание.

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

Есть ли эффект от ежедневных угроз? 👩‍🚀 Да, несомненно. Я точно не теряю свой уровень.

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

Да, я двигалась по внутренней шкале зелёной птахи. Но это просто механизм: tсли ты делаешь задания по мнению Дуо уровень растет. Даже если не растёшь на самом деле.

Несмотря на это, слезть сложно. Я целых 1000 дней уделила как такое бросить?

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

А кто ещё в плену 😪зелёной птицы😪 дайте знак и хвастайтесь своими успехами в комментах.

В одном городе на берегу Волги, на крыше с видом на неё, прошла уютная конференция самарских аналитиков и не только Samba_conf

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

🔥Про доклады🔥

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

🤩 Когда я впервые увидела тему Сергей Семикина 🤩 "Все ли “проблемы” нужно решать? А если решать, то для чего и как?" я скептически подумала: ответ "Конечно нет!" о чем говорить то?. На деле Сергей разложил подход к этому вопросу по полочкам.

Понравилась мысль: проблемы не только нужно решать, но и уметь их «продавать». А перед решением спрашивать: «Что будет, если ничего не делать? Сколько стоит найти ответ на этот вопрос (анализ)?». Если стоимость решения выше последствий, решать не надо. Жёстко, но справедливо.

Отдельно запомнился момент: при проблемах все хотят защищаться. Но это мешает искать причины. Знакомо, очень знакомо.

В конце Сергей предложил делиться инсайтами в чат и строить на этом нетворкинг. Идея интересная, но аудитории почему-то не зашла.

До выступления 🤩 Татьяны Гудковой «Супервизия в IT: как психологический разбор рабочих ситуаций делает специалистов эффективнее» 🤩 я толком не знала, что такое супервизия. А это крутая практика которая обязательна если работаешь психологом, но отлично переносящаяся в ИТ. Это инструмент, который помогает справляться с синдромом самозванца, проблемами коммуникаций и выгоранием.

В свою работу я адаптированно забрала 2 приема:

➕В менторинге уточнять «На каком уровне человек хочет разбора вопроса?». (Я люблю увлечься деталями, а это не всегда нужно.)
➕В обратной связи коллегам спрашивать напрямую: «А как бы вы поступили в этой ситуации?».

И отдельный восторг: Татьяна практикующий системный аналитик и проф. психолог.

🤩Станислав Баничус в своем докладе «Франкенштейн — современная методология разработки ПО» 🤩 для меня открыл новую методологию Spotify (да, в честь одноименного сервиса). Сейчас это очень похоже на то, с чем мы работаем, но я впервые услышала, что это так называется. Мне хватило и этого, но плюс к харизма и ораторское мастерство спикера располагали просто слушать и вникать.

Завершала конференцию 🤩 Арина Сафронова 🤩. Для меня она стала глотком свежего воздуха на фоне «недоаналитиков рынка ИТ» в Telegram. К слову после её доклада я от большинства отписалась. Она чётко и честно обрисовала текущую картину рынка. Немного попугала, но и добавила позитива. А главное - предложила посмотреть на себя в этих реалиях. Было интересно и очень профессионально. Хотя были моменты, где я не была до конца согласна, но это воспринималось скорее как здоровое альтернативное мнение.
Из важного:

➕ сейчас рулят основные скиллы, а не допы
➕ контакт пишем не только в контактах, но и в "о себе"

🔥 В общем, красивые виды не смогли отвлечь от докладов: было реально интересно. А вот усталость от нетворкинга накатила: в этот раз я почти не приставала к людям, просто слушала и мотала на ус.

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

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

Завершился летний поток курса от 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 в работе аналитика от Анастасии Московкиной(получится познакомиться лично!) и Натальи Леоновой

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