‼️ Брокеры сообщений офлайн ‼️

Запись полной теории интенсива с примерами применения по брокерам сообщений уже доступна по ссылке 🎉

Весь список занятий, доступных в записи:
✅ REST API
✅ Базы данных (middle)
✅ Брокеры сообщений

Подробно про такой формат рассказал тут.

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️Загрузка данных из внешних источников❗️

Очень часто возникает задача получить какие-то справочники или просто поток данных из внешних систем.

Как правило, качество этих данных оставляет желать лучшего 🗑

Этот кейс встречался мне почти на всех проектах и вот опять...

Завтра в большом видео расскажу и покажу, как мы побеждали дубликаты, кривые форматы и прочий мусор, который любезно отправил нам поставщик данных 👍

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

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️Новый разбор технического кейса❗️

На этот раз рассказал про свой опыт решения задач по загрузке данных из внешних источников.

Без склеек, все рассуждения и развилки решений есть в видео.

Получилось достаточно объемно, посмотреть можно:

🎬 На youtube
🔝 VK без VPN

Как вам такой формат?

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

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

🎉Повод для подарков 🎉

Как и в прошлом году, в честь своего дня рождения подготовил для вас промокод BDAY, который в этот раз дает скидку 32% 😭

Действует на любой курс и на любой тариф.

Но у промокода всего 5 активаций.

Использовать тут 👈

Еще в честь этого события я отправился в небольшой отпуск, поэтому пока не выкладываю новые видео 🙃

UPD: осталась 1 активация

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❓Как часто менять работу джунам?

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

Будет по одному видео о каждом из грейдов, потому что одно получается слишком длинным для разговорного формата :)

Начинаем с джунов 👍

⚠️ Опираюсь исключительно на свой опыт, наблюдение за коллегами и общение с HR, поэтому ваш опыт может отличаться :)

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

🗓 Интенсивы июля 🗓

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

Расписание занятий будет таким:
🔸11.07 Суббота
🔸12.07 Воскресенье

Все занятия пройдут в 12:00 по МСК.

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

Описание программ:
🔸REST API;
🔸Базы данных (с нуля);
🔸Базы данных (middle);
🔸Брокеры сообщений;
🔸Функциональные требования;
🔸Event-Driven Architecture;
🔸Нотация С4;
🔸System design.

❓Для тех, кто не понимает, о каких интенсивах речь, рассказал тут.

Сразу предлагаю выбрать тему занятия 11.07 👍

❗️Как и всегда: голосуйте, только если сможете посетить занятие❗️

Почему это важно?
Ваш голос может решить исход голосования, при этом места останутся пустыми, и меньше людей получат новые знания 🥺

Опрос ниже👇

❓Как часто менять работу мидлам?

Сегодня разберем мидлов:

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

⚠️ Опираюсь исключительно на свой опыт, наблюдение за коллегами и общение с HR, поэтому ваш опыт может отличаться :)

P.S. Там выше голосовалка за тему занятия 11.07, завтра в 12:00 подведу итоги и в 16:00 открою запись 👆

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️ 11.07 REST API ❗️

Запись будет открыта сегодня в 16:00 МСК

Тема: Проектирование REST API.
Уровень: junior.
Требуемые навыки: Умение читать ER-диаграмму.
Кол-во участников: до 4.
Длительность: ~4 часа.
Программа:
✅ Форматы данных;
✅ HTTP-методы и их свойства;
✅ REST и RESTfull;
✅ Обработка ошибок в синхронных интеграциях.

Практика:
✅ Проектирование REST API для нового сервиса;
✅ Внедрение пагинации и фильтрации;
✅ Swagger;
✅ Postman.

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

✅ Запись открыта ✅

11.07 12:00 МСК Проектирование REST API

Для записи жмите сюда 👈

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❓Что там у синьоров со сменой работы?

Сегодня на очереди синьоры, самая неоднозначная категория, на мой взгляд :)

⚠️ Опираюсь исключительно на свой опыт, наблюдение за коллегами и общение с HR, поэтому ваш опыт может отличаться :)

Предыдущие части:
🔸Где эффективно искать работу?
🔸Какие харды необходимы?
🔸Как часто менять работу джунам?
🔸Как часто менять работу мидлам?

P.S. Запись на REST API 11.07 открыта тут 👈

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️Тема занятия 12.07❗️

А давайте пока выберем тему занятия 12.07 (воскресенье), голосовать будем до понедельника:)

Описание программ:
🔸REST API;
🔸Базы данных (с нуля);
🔸Базы данных (middle);
🔸Брокеры сообщений;
🔸Функциональные требования;
🔸Event-Driven Architecture;
🔸Нотация С4;
🔸System design.

❓Для тех, кто не понимает, о каких интенсивах речь, рассказал тут.

❗️Как и всегда: голосуйте, только если сможете посетить занятие❗️

Почему это важно?
Ваш голос может решить исход голосования, при этом места останутся пустыми, и меньше людей получат новые знания 🥺

Опрос ниже👇

❗️12.07 Event-Driven Architecture❗️

✅ Запись будет открыта сегодня в 16:00 МСК ✅

Уровень: Middle+.
Требуемые навыки: Понимание принципов работы распределённых систем, Apache Kafka.
Кол-во участников: до 4.
Длительность: ~4 часа.
Программа:
✅ Немного общей теории по распределенным системам;
✅ Что такое "событие";
✅ Что такое EDA;
✅ Сильные и слабые стороны EDA;
✅ Модели данных для EDA;
✅ Мониторинг в EDA.

Практика:
✅ Проектируем EDA систему с нуля;
✅ Готовим схему расположения сервисов;
✅ Расширяем функционал системы с использованием имеющихся событий;
✅ Внедряем в систему мониторинг.

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

✅ Запись и анонс ✅

Запись на занятие по Event-Driven Architecture 12.07 12:00 МСК открыта!

Для записи жмите сюда 👈

Предыдущий разбор кейса из практики вам, вроде как, зашёл🎉

Поэтому завтра выйдет следующий!

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

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

Будет большое видео со схемой и разбором 🫡

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❗️Ещё один разбор технического кейса❗️

В этот раз получение документов из системы партнера в реальном времени внутри закрытого контура.

Без склеек, все рассуждения и развилки решений есть в видео.

Получилось достаточно объемно, посмотреть можно:

📹 На youtube
🔝 VK без VPN

У нас, кстати, REST и событийная архитектура в эти выходные, слоты ещё есть:

11.07 REST API
✅ 2 свободных места ✅

12.07 Event-Driven Architecture
✅ 3 свободных места ✅


🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❓На очереди архитекторы :)❗️

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

⚠️ Опираюсь исключительно на свой опыт, наблюдение за коллегами и общение с HR, поэтому ваш опыт может отличаться :)

Небольшой оффтоп на эту тему:

Я уже говорил ранее и скажу ещё раз, что нет ничего страшного и сложного в переходе из senior системного аналитика в архитекторы. Поэтому, если вас посещают мысли "я не потяну" и т.п., гоните их и пробуйте. А если сомнения не проходят, пишите мне, развеем:)

Предыдущие части:
🔸Где эффективно искать работу?
🔸Какие харды необходимы?
🔸Как часто менять работу джунам?
🔸Как часто менять работу мидлам?
🔸Что там у синьоров со сменой работы?

А ещё на интенсивах много мест, приходите качать харды в выходные, следующие занятия смогу провести только во 2-й половине августа 😐

✅11.07 REST API
✅12.07 Event-Driven Architecture

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

🌟Да будет холивар 🌟

Предвижу, что за этот пост мне знатно прилетит, но я обещал его сделать, поэтому вот он 😎

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

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

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

Ну что ж поехали... 💫

Стажеры
Тут все очень просто, делать самому с нуля, скорее всего, ничего не придётся, поэтому будет достаточно:

🔸Понимать, кто вообще такой аналитик и его роль в команде;
🔸Уметь читать схемы в базовых нотациях, чтобы проще было погружаться в проект;
🔸Понимать разницу между клиентом, сервером и базой данных;
🔸Отличать FE и BE разработчиков друг от друга;
🔸Иметь представление о популярных форматах (json, XML).

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

🔸Уметь внятно описывать сценарии работы системы, не важно в каком формате;
🔸Моделировать схемы в базовых нотациях (UML, BPMN). Касательно UML, сильно не упарывайтесь, будет достаточно ER, Sequence и в редких случаях use-case, ещё реже может пригодиться data flow;
🔸Отличать аутентификацию от авторизации и понимать, зачем они нужны;
🔸Понимать, что такое REST API, уметь проектировать с нуля новые эндпоинты, а также понимать, чем HTTP-методы отличаются друг от друга;
🔸Чуть-чуть знать о брокерах сообщений, достаточно понимания на уровне "черного ящика";
🔸Если говорить о базах, то будет достаточно понимания реляционных СУБД (связи и типы данных, без усложнения) и написания простых SQL-запросов на уровне join.

Мидлы
Основная прослойка специалистов, с самым большим разбросом, поэтому описываю ключевые, как мне кажется, моменты:

🔸Проектирование отдельных сервисов системы с нуля, без глубокого погружения в архитектуру;
🔸Для этого сервиса спроектировать интерфейсы (REST, gRPC и тп);
🔸Понимать отличие JWT от API KEY;
🔸Если есть работа с брокерами, то описать, что, как и в каком формате;
🔸Работу брокера, который используется на проекте, желательно знать поглубже, хотя бы на уровне балансировки сообщений;
🔸Проектировать модели данных с нуля для отдельного сервиса;
🔸SQL на уровне понимания FWGHSOL и написание простых запросов для анализа, без всяких оконных функций, хранимых процедур и тд;
🔸Уметь читать и править С4.

Синьоры
Когда ты почти архитектор, но ещё не принял этого:

🔸Подготовка архитектуры с нуля целых модулей (несколько сервисов) существующей системы со всеми вытекающими;
🔸Проектирование интеграций уже превратилось в рутину, независимо от технологии и способа;
🔸Помимо глубокого понимания устройства брокеров вашего проекта, неплохо понимать, в каких случаях применять нативные коннекторы и тп;
🔸Есть опыт работы и проектирования различных баз под разные задачи (OLAP, кеши, графы и тд);
🔸К теме работы с данными ещё круто понимать, что такое CDC и когда его применять;
🔸Балансировка нагрузки, многопоточность, прокси, CDN — не просто фоновый шум в созвонах, а понятные инструменты;
🔸Описание всего этого хозяйства в С4, желательно в DaC формате.

Архитекторы
Тут всё ещё проще, чем у стажёров: "Всего побольше и можно без хлеба"

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

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

А размазывать ответственность "коллективными решениями" — это вообще мёд 🍯

Ваш опыт и матрицы компетенций внутри компаний 100% могут отличаться, буду рад, если поделитесь в комментариях, обсудим 👍

Про использование ИИ специально не написал, расскажу отдельным постом :)

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

🤖 Так ли важно уметь работать с ИИ? 🤖

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

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

В вакансиях все чаще встречается требование к наличию опыта работы с условными Claude, Perplexity и т.п.

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

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

И лишь малая часть коллег ответила, что активно рисуют с помощью ИИ диаграммы, готовят документацию и проводят код-ревью.

Важно отметить, что именно эти люди чаще других отмечали несовершенство отдельно взятых технологий 🫂

Лично я считаю, что любой навык лучше, чем отсутствие такового (ваш капитан😎).

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

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

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

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

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

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

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

Буду рад, если поделитесь своим опытом использования подобных инструментов в комментариях👇

I'll be back... 👍

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин

❓GET с телом?❓

Неожиданно появился новый HTTP-метод ⁉️

Без преувеличения можно сказать, что такое случилось впервые в этом тысячелетии.

Да-да, сам в шоке, мне на консультации рассказали пару дней назад, решил вынести это дело в массы.

Метод был назван QUERY, и представляет собой GET с телом, такие вот дела.

Привет всем адептам отправки тела в GET 🤦‍♂

Остальные свойства аналогичны. Вот небольшое сравнение методов, заодно и память освежить поможет:

⚠️ Все свойства описаны для классического варианта применения методов!

GET:
✅ Безопасный;
✅ Кешируемый;
✅ Идемпотентный;
❌ Не определена симантика тела.

POST:
❌ Небезопасный;
❌ Некешируемый;
❌ Неидемпотентный;
✅ Определена симантика тела.

QUERY:
✅ Безопасный;
✅ Кешируемый;
✅ Идемпотентный;
✅ Определена симантика тела.

Таким образом, больше не нужно делать POST /search, чтобы передать сложную структуру фильтра.

Почему это удобно и все остальные мысли на тему появления нового метода изложил в видео, обязательно послушайте 👆

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

А как вам подобные нововведения? 😉

P.S. Подробную документацию можно почитать в самом RFC.

🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин