#Хабр

Друзья, привет!
Выложил на Хабре новую статью о best practices проектирования REST API 👨‍💻

В статье рассмотрено, как реализовать получение данных с пагинацией с помощью GET и POST методов, приложен шаблон описания методов, а также форматов данных на примере JSON-схемы и спецификации OpenAPI в YAML-формате.

По ссылкам в статье вы можете перейти в песочницу swagger, скопировать туда этот YAML и самостоятельно поисследовать реализацию.

Приятного чтения!

Друзья, привет!
Последний месяц у меня выдался несколько напряженным, поэтому совсем не было времени вести канал 🥲

Тем не менее, я вижу, что вас становится все больше, и это очень мотивирует продолжать ❤️

А пока я предлагаю вам ознакомиться с интересными IT-роадмапами на сайте https://roadmap.sh

Они больше ориентированы на подходы к разделению зон ответственности в западной IT-индустрии (США, Европа), но тем не менее будут очень полезны для расширения кругозора и закрытия пробелов в знаниях 👨‍💻

Наиболее релевантные скиллам системного аналитика роадмапы:

Software Architect
API Design Roadmap
System Design Roadmap

💜🔹🌺👆🕊🔽💮👆🌿🕊

Ознакомиться с содержанием и стоимостью вы можете здесь.

Что ждет вас на обучении?

• 7 онлайн-занятий с изучением теории и отработкой практики. Никаких записанных видео и кучи ссылок. Только живое общение со мной 👨‍💻

• Акцент на техническую составляющую самых распространенных типов интеграций (REST, gRPC, Kafka, RabbitMQ) и архитектуру систем 👨‍💻

• Резюме Middle аналитика с ориентиром на 200+ 💰

• Консультации во время испытательного срока 🆘

Для записи прошу писать мне в личные сообщения - @oldschoolsysdes.
Постараюсь быстро каждому ответить на все вопросы

Друзья, привет!

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

1⃣ Ранее я планировал канал, как сугубо технический, для желающих стать СА или узнать что-то новое, но в этом году хочу создать тут вовлеченное сообщество, поэтому попробую писать что-то более неформальное из жизни и работы.
Надеюсь из этой затеи выйдет что-нибудь путное и мне хватит времени поддерживать здесь активность 👨‍💻

2⃣ В конце года в семье случилось пополнение 🐕
Теперь у меня живет той-пудель Юна.
Могу сказать, что собака - одновременно и большая радость и ощутимые хлопоты. При желании можете поделиться фото питомцев в комментариях 🙂

3⃣ Все слоты на менторство заняты до конца января.
Сегодня открываю запись на февраль-март, при этом до 31 января стоимость останется прежней, затем увеличится. Записаться по-прежнему можно в лс @oldschoolsysdes

4⃣ Сегодня вышла моя новая статья на Хабре: «Как аналитику научиться читать код без навыков программирования».
Не скажу, что удалось полностью охватить все нюансы, но постарался на примере фреймворка Flask для Python подробно показать, как могут выглядеть простые приложения, и как можно читать их код.

Делитесь в комментариях, приходилось ли вам сталкиваться с такой необходимостью в работе 👨‍💻

🤷‍♂️ Зачем аналитику необходимо уметь читать код?

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

🟨 В обоих случаях целые 44% опрошенных (почти половина) проголосовали за вариант «мне приходилось погружаться в код и читать его».

А если учесть, что и в канале и на Хабре треть опрошенных (35% и 40% соответственно) проголосовала за вариант «посмотреть результаты», то получим около 70% аналитиков, сталкивавшихся с необходимостью погружаться в код своих коллег и это колоссальные цифры! 🤯

О чем же они говорят?

😳 1. Плохая документация
На это могло повлиять множество факторов. Как основные: или отсутствие аналитиков, или сложный запутанный домен, или команда работала в режиме «стартап», когда главное было пилить как можно быстрее новый функционал для бизнеса. Или все вместе взятое 👨‍💻

☹️2. Плохие процессы
Возможно, что в команде не были должным образом выстроены процессы проектирования, разработки и тестирования:
отсутствовали соглашения по проектированию и описанию требований, отсутствовала культура тестирования (напомню, что хорошо описанные требования на разработку являются основой для формирования тест-кейсов, и хорошие QA будут требовать документацию от аналитиков).

Что делать?

😱 Отсутствие документации — это большая возможность для прокачки скиллов: как хардов, так и софтов.
В целом в таких ситуациях я использую следующий порядок действий:

1⃣ Получить доступ к тестовому стенду и попробовать понять, какой функционал есть в системе.

2⃣ Определить круг стейкхолдеров продукта и подготовить вопросы для интервью о его функциональности.

3⃣ Изучить таск‑трекер (условная Jira) на предмет следов разработки (можно узнать о том какие сервисы и фичи были сделаны ранее)

4⃣ Пройтись по всем разработчикам и узнать, какие сервисы они разрабатывают/разрабатывали на проекте и вообще что они о нем знают.

5⃣ Изучить систему контроля версий (например GitLab или BitBucket) — позволит найти сервисы и их код.

5⃣🧡 Изучить конфигурацию сервисов. В ней могут быть скрыты URL-адреса интеграций и иных взаимодействий (БД, брокеры итд).

5⃣🌿 Изучить API, если есть описание. Если нет, то придется погружаться в чтение кода.
На всем этом этапе очень полезным станет отрисовка схемы микросервисов и определение структуры моделей данных в БД.
На схему микросервисов будет необходимо нанести сервисы, стрелочками изобразить взаимодействие между ними, и желательно написать имя используемого метода и его URL.
БД можно описывать в табличном виде или в виде ER-диаграмм.

5⃣🌿 Во время чтения кода вы можете использовать информацию из предыдущих пунктов, чтобы восстановить и задокументировать бизнес-процессы так, как они реализованы на самом деле.

👨‍💻 Спешу сообщить, что один из самых популярных видов спорта этой зимой - спортивное вкатывание в айти

16 февраля стартует последний в уходящей зиме трек моего менторства для системных аналитиков.
🤓 Подробная информация про обучение - по ссылке.

🛞Осталось 3 свободных места.
Записаться - ко мне в личку @oldschoolsysdes

👨‍💻 Небольшая подборка полезных материалов для недавно присоединившихся к сообществу

1⃣ Самостоятельное обучение
🔘Системный аналитик. Часть 1.
🔘Системный аналитик. Часть 2.
🔘Системный аналитик. Часть 3.
🔘Системный аналитик. Часть 4.
🔘Системный аналитик. Часть 5.

2⃣ Архитектура
🔘Как устроены современные приложения
🔘Микросервисы
🔘Масштабирование систем
🔘CQRS+Event Sourcing
🔘Saga

3⃣ Интеграции
🔘REST
🔘gRPC
🔘Kafka
🔘RabbitMQ

Друзья, привет!
Сегодня немного теории 🤓

Если вам в работе придётся сталкиваться с необходимостью гарантировано доставлять сообщения до какого-либо сервиса, то вам необходимо будет реализовать архитектурный паттерн Transactional Outbox (или просто Outbox), гарантирующий модель доставки at least once (хотя бы один раз).

Как работает паттерн?
Предположим, что есть два микросервиса: Сервис А и Сервис В.
Задача состоит в том, чтобы после получения сообщения в Сервис А, гарантировано передать данные из него в Сервис В.

Без использования какого-либо механизма обеспечения надежности этот процесс мог бы выглядеть следующим образом:
1. Сервис А обрабатывает запрос клиента.
2. После успешной обработки сообщения Сервис А отправляет сообщение в Сервис В через брокер (например, Kafka).

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

Чтобы избежать этой проблемы, используется паттерн Transactional Outbox.

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

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

1⃣ Сервис А получает запрос.

2⃣ Затем внутри транзакции:
🔘Сохраняется информация о запросе
🔘Создается запись в таблице Outbox с информацией о сообщении, которое должно быть доставлено
🔘Транзакция фиксируется

3⃣ Асинхронная задача (например шедулер в сервисе А) берет записи из таблицы Outbox и пытается отправить их в сервис В:
🔘Если доставка прошла успешно, то в БД данной записи проставляется атрибут (например status), свидетельствующий об ее успешной отправке в сервис В, или запись удаляется из таблицы Outbox
🔘Если происходит ошибка при доставке, асинхронная задача продолжает попытки до тех пор, пока доставка не завершится удачно

4⃣ Сервис В читает сообщения из брокера.

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

Друзья, привет!
Сегодня пост посвящен самой хайповой теме - AI 😅

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

На своем курсе я показываю обучающимся, как можно использовать LLM для:
🔘формирования Use Case’ов
🔘построения по ним Sequence-диаграмм в PlantUML
🔘формирования ER-диаграмм при проектировании БД
🔘проектирования спецификаций REST API в формате OpenAPI, проектирования protobuf-файлов для gRPC, описания json-схем.

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

А вчера мои коллеги поделились ссылкой на вот такой продукт калифорнийского стартапа https://www.cursor.com

Это форк среды разработки VSCode, к которому прикручен AI-copilot, умеющий бесплатно из коробки формировать структуру репозитория прямо в IDE, устанавливать зависимости, писать код, дебажить, запускать скрипты и сам проект на твоей машине 🤯

Под капотом бесплатный gpt-4o-mini и даже он творит нечто нереальное - можно собрать MVP проекта на любом языке меньше чем за час в пару десятков кликов, что, собственно, мои коллеги и сделали 🤑

Интересно было бы узнать ваше мнение и опыт использования AI в повседневной работе в комментариях 😊

🕊🌿👆🌸🔹🌺💎🔹

👨‍💻 Открыта запись на новый поток обучения системных аналитиков с нуля до Middle+ на ближайшие 1,5 месяца.
Старт занятий - 22 марта.

Ознакомиться с содержанием и стоимостью вы можете здесь.

Что ждет вас на обучении?

• 8 онлайн-занятий с изучением теории и отработкой практики. Никаких записанных видео и кучи ссылок. Только живое общение со мной 👨‍💻

• Акцент на техническую составляющую самых распространенных типов интеграций (REST, gRPC, Kafka, RabbitMQ) и архитектуру систем 👨‍💻

• Резюме Middle аналитика с ориентиром на 200+ 💰

Записаться - ко мне в личные сообщения @oldschoolsysdes

⚠️UPD: старт переносится на неделю вперёд, на 22 марта, так как я заболел гриппом :(

Всем, привет!
У меня две новости:

1⃣ Я выздоровел, а это значит, что у меня хорошее настроение, поэтому объявляется минута юмора 🤣
Лучше смотреть со звуком.

2⃣ Осталось 1 свободное место для записи на обучение до оффера, стартуем в субботу 22 марта. Записаться - ко мне в личные сообщения

Всем хорошего дня! ⭐

AI-хайп. Что такое AI-агенты и как работает RAG?

RAG (Retrieval Augmented Generation) — это метод работы с большими языковыми моделями, когда пользователь пишет свой вопросы, а вы программно к этому вопросу «подмешиваете» дополнительную информацию из каких‑то внешних источников и подаете все целиком на вход языковой модели. Другими словами вы добавляете в контекст запроса к языковой модели дополнительную информацию, на основе которой языковая модель может дать пользователю более полный и точный ответ.
О том, что же такое RAG более подробно можно почитать тут.

Как работает RAG.
Рассмотрим схему на рисунке.
1⃣ Предположим у нас есть UI (интерфейс). Сначала мы загрузим документы в нашу базу знаний (в любом формате: pdf, doc, да хоть в json) через сервис DocumentLoader.

2⃣ Сервис DocumentLoader перед тем, как поместить документы в хранилище, преобразует их в векторный вид с помощью Embedding Model - например из английского слова «cat» вы получите нечто похожее на [0.2, -0.4, 0.7]

3⃣ Получив в ответе от Embedding Model векторное представление документа сервис DocumentLoader сохраняет его в векторную БД Vector Database.

4⃣ После того, как мы загрузили в БД документы нашей базы знаний в векторном формате, мы можем начать работу с RAG и LLM.
Вопрос пользователя попадает в сервис Mediator, который направляет запрос в сервис RAG для поиска релевантной вопросу информации в хранилище.

5⃣ Сервис RAG преобразует вопрос пользователя в векторный вид с помощью Embedding Model и ищет совпадения в векторном хранилище, которые возвращает в качестве ответа.

6⃣ Сервис Mediator использует полученную в ответе от сервиса RAG информацию для обогащения контекста запроса в LLM.

7⃣ Ответ от LLM, при формировании которого был учтен контекст из базы знаний, возвращается пользователю на UI.

Как работают AI-агенты
Сервис Mediator в связке с LLM также может реализовывать функции AI-агента.

Если в процессе обработки запроса пользователя необходимо выполнить какие то действия, в том числе, основываясь на результатах обработки языковой моделью (LLM) вашего запроса, то здесь на помощь вам могут прийти AI-агенты.
Один из самых популярных подходов к реализации агентов называется ReAct - парадигма, объединяющая рассуждение и выполнение действий. Более подробно об устрйостве можно почитать по ссылке.

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

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

Mediator сходит в векторное хранилище за релевантной информацией, затем вызовет LLM, которая, обработав запрос, может принять решение, что ей недостаточно данных для того, чтобы фактологически точно дать ответ на вопрос и вызовет ту часть (Tools - см. статью по ссылке выше) сервиса Mediator, которая имеет подключение к внешним API (например API поиска Google), для того, чтобы она нашла в интернете релевантную информацию с новостями о нефтедобыче, дообогатила ей контекст запроса и снова вызвала LLM, а затем вернула ответ пользователю.

P.S. Не претендую на фактологическую точность материала, рассказываю то, как я это понимаю сам и с чем сталкивался в работе. Если среди подписчиков есть специалисты в ds/ml/ai, буду рад комментариям/исправлениям/дополнениям 🐈

Развеиваем сомнения начинающих аналитиков и не только 👨‍💻

1⃣ У меня нет технической «вышки», какой из меня технарь, если я даже ни разу не писал код.

В обязанности СА не входит разработка, следовательно вам не стоит опасаться того, что вас заставят это делать.
Если вы умеете читать/писать код, то это просто добавит вам авторитета в глаза команды, а также, возможно, некоторую сумму к офферу 🤑

Техническая вышка также совершенно не нужна. Знание того, как устроен процессор или того, как работает сетевой стек на физическом уровне, вам не пригодится в роли СА в 99,99 % случаев.
Безусловно, техническое образование добавляет тот же процент «респекта» со стороны команды и снижает порог вхождения и освоения в профессии, но не является камнем преткновения (ну разве что если вы собеседуетесь на вакансии в гос.учреждения).

2⃣ Я прошел обучение и все еще сомневаюсь в своих навыках. Боюсь выходить на рынок и собеседоваться.

Это нормальная ситуация, которая может сложиться по разным причинам (было мало практики на обучении, ментор не делился обратной связью, не давал ответы на вопросы о том, как это устроено и применяется в реальной работе, итд)

Вместе с тем, если вы знаете:
• как работает протокол HTTP, что такое JSON и можете описать его с помощью json-схемы;
• как устроены базы данных и можете спроектировать структуру таблиц и описать их в ER-диаграммах;
• знакомы с нотациями UML и BPMN и можете описывать процессы с их помощью;
• как устроена архитектура распределенных систем (микросервисы и как они могут взаимодействовать друг с другом);
• можете спроектировать REST API и задокументировать его в формате OpenAPI
• имеете общее понимание того, как работают брокеры (Kafka, RabbitMQ) и можете спроектировать обмен сообщениями с их помощью;

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

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

3⃣ Боюсь провалов на собеседованиях и попасть в чёрный список.

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

Как только вы выходите на рынок, то первые 3-5 собеседований с вероятностью 90% будут провальными, к этому надо быть готовым.
Затем вы понимаете, чего от вас ждут и что хотят услышать, и начинаете выстраивать и адаптировать свою линию диалога под ожидания собеседующих.
Прохождение собеседований это отдельный навык, который тренируется периодическими повторениями.

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

Верьте в себя, не опускайте руки, идите к своей цели и у вас обязательно все получится вне зависимости от пола/возраста/локации, потому что формула результата по прежнему очень проста - это время, помноженное на усилия 👨‍💻

🕊🌿👆🌸🔹🌺💎🔹

👨‍💻 Открыта запись на новый поток обучения системных аналитиков с нуля до Middle+ на ближайшие 1,5 месяца.
Старт занятий - 24 мая.

Ознакомиться с содержанием и стоимостью вы можете здесь.

Что ждет вас на обучении?

• 7 онлайн-занятий с изучением теории и отработкой практики. Никаких записанных видео и кучи ссылок. Только живое общение со мной 👨‍💻

• Акцент на техническую составляющую самых распространенных типов интеграций (REST, gRPC, Kafka, RabbitMQ) и архитектуру систем 👨‍💻

• Резюме Middle аналитика с ориентиром на 200+ 💰

Записаться - ко мне в личные сообщения @oldschoolsysdes

Друзья, привет! Давно не было на связи, постараюсь восполнить пробелы! 😅

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

1⃣Что такое шардирование?
Это метод горизонтального масштабирования, при котором данные одной большой базы разбиваются на части (шарды), которые размещаются на разных серверах или узлах кластера баз данных.

2⃣Зачем шардировать БД?
Это позволяет повысить производительность и надежность системы, поскольку объем данных и нагрузка распределяются между несколькими серверами (хранилищами).

3⃣Когда необходимо шардировать БД?
1. Когда данные не помещаются на одном сервере или сервер перестаёт справляться с нагрузкой- шардирование позволяет добавить новые серверы и распределить данные между ними.
2. Когда требуется повысить отказоустойчивость - отказ одного шарда не приводит к потере доступа ко всем данным, остаются доступны данные на других шардах.
3. Когда требуется увеличить скорость обработки запросов - параллельное выполнение запросов к разным шардам снижает конкуренцию за ресурсы и ускоряет отклик базы данных.

4⃣Как шардировать БД?
Самый распространенный подход это key-based шардирование (на рисунке)
1. Выбирается ключ шардирования, например id.
2. Создаются несколько экземпляров (шард) баз данных, каждый из которых хранит данные для своего диапазона id.
3. В сервисе (или в прокси - роутере/координаторе) реализуется логика маршрутизации запросов: если id = 1201, запрос идет на сервер 1, если id = 3103 — на сервер 2.

Для более равномерного распределения можно использовать хеширование id и направлять данные в шарды по значению хеша

За направление запроса в нужный шард может отвечать как сам сервис, так и отдельный сервис-прокси (роутер/координатор).

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

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

Диапазонное перераспределение: данные делятся на новые диапазоны по ключу и перераспределяются (вручную или автоматически) между шардами.

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

Вечернее про AI и продуктовую разработку.

Мне кажется, что хайп ai-агентов отчасти обусловлен тем, что бизнесу наконец-то дали вменяемое описание микросервисов, которое можно уместить в конструкцию из слова «агент-…» и двух-трёх последующих слов.

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

Вторая проблема, которая вырастает из первой, заключается в том, что из-за общепринятой ментальной модели «ллм+хороший промпт=автоматизация» создаётся впечатление, что разработка и отладка ai-агентов это быстро.
На этом этапе многих будет поджидать разочарование.

Третья проблема заключается в том, что по прежнему в воздухе витает некое ощущение всемогущества и всеприменимости языковых моделей - оттуда растут и тейки про замену ручного труда на нейронки.
В одном из тг-каналов сегодня подсмотрел ссылку на статью от Anthropic в которой LLM дали поуправлять магазином.
Успех относителен - модель путалась, галлюцинировала, хотя в конечном итоге справилась с задачей, пусть и принеся 30% убытков магазину.

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

Однако, Anthropic наглядно демонстрирует нам, что в эпоху экспоненциального развития технологий кто-то должен делать R’n’D в этом направлении и, возможно, при должном уровне зрелости технологий стать новым мировым гигантом на уровне тяжеловесов из FAANG.

Дискуссии и рассуждения в комментах приветствуются 👨‍💻

Страх чистого листа

У представителей многих творческих профессий существует такое понятие как «страх белого листа».
Это такое состояние, когда, например, художник смотрит на холст и не знает, с чего же ему начать.

У многих аналитиков зачастую возникает аналогичное состояние, когда они, имея на руках требования (ну или любой другой артефакт от бизнеса) не могут начать что-либо делать в части проектирования архитектуры фичи.

Делюсь изобретением велосипеда проверенным подходом, облегчающим жизнь.

1⃣Определяем контрагентов
Прежде всего необходимо понять наше окружение - с какими системами или сервисами мы взаимодействуем / с нами взаимодействуют.

2⃣Определяем границы ответственности нашей системы
Формулируем в виде списка задач, что именно наша система должна сделать (действия, функции итд).

В целом это и станет теми самыми функциональными требованиями (ФТ, FR - functional requirements)

3⃣Выделяем объекты внутри нашей системы
Существует несколько подходов к выделению объектов, но самый простой и не менее эффективный - выделять их по функциональному предназначению.

Это поможет понять структуру нашей будущей solution-архитектуры.
В дальнейшем эти сущности и станут нашими (микро)сервисами.

В большинстве случаев количество объектов будет соответствовать количеству уникальных задач из пункта 2.

Что такое уникальная задача? Например, создать заказ и обновить заказ - менее уникальные задачи, а вот создать заказ и создать чек - более уникальные.
Но в целом это довольно холиварная тема про DDD, зоны ответственности и микросервисный ад.

4⃣Определяем какими сущностями и как оперирует каждый объект внутри системы

Создаете заказ?
Сущность - заказ, действие - создать.
Для этого вам наверняка нужно ФИО пользователя, его адрес и состав заказа. Метку времени и уникальный идентификатор заказа ещё хорошо бы не забыть.
Оплачиваете заказ?
Понадобится его идентификатор, наполнение и общая стоимость.

Этот шаг поможет понять структуру данных, и в дальнейшем описать их хранение и работу с ними.

5⃣Описываем наконец все это по порядку
BPMN, сиквенсы, ER-диаграмы, API и так далее в зависимости от потребности…
И идёте пить кофе/смотреть ютубчик/что вы там ещё любите делать 😅

Стереть память - возможно!?

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

Узнал для себя несколько совершенно потрясающих фактов.

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

2⃣Процесс «укладки» памяти в мозге называется консолидация. Оказывается, на неё можно влиять с помощью специальных химических ферментов - ингибиторов синтеза белка.
То есть реально можно отключать способность запоминать что-либо.

3⃣Процесс «воспоминаний» ещё более сложный - при нем активируются эти самые биологические структуры и память «извлекается», превращаясь в зрительные образы и прочие сенсорные ощущения.

4⃣Каждый раз в процессе воспоминаний эти самые воспоминания «переукладываются» в памяти при возвращении в неё обратно - это называется реконсолидация.

5⃣Из пункта 2 следует справедливый вывод, что на реконсолидацию можно также влиять теми же средствами, что и на консолидацию.

6⃣Ученые экспериментально проверили вывод из пункта 5, и подтвердили, что существует абсолютно научный способ стирать или существенно ослаблять память (с высокой долей эффективности, но не равной 100%) - надо просто вызвать у вас воспоминание, а затем ввести препарат.

Убеждаемся, что фильм «Вечное сияние чистого разума» показывает нам вполне возможную ситуацию.
Более того, оказывается, что режиссер и был вдохновлен тем самым открытием 😅

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

🕊🌿👆🌸🔹🌺💎🔹

Друзья, привет!
👨‍💻 Открываю запись на новый поток обучения системных аналитиков.
Старт занятий - 23 августа в 11:00 (мск).

Ознакомиться с содержанием и стоимостью вы можете здесь.

Что ждет вас на обучении?

• 6 онлайн-занятий с изучением теории.
• Домашние задания по каждому занятию и итоговый проект для закрепления практических навыков.
• Акцент на техническую составляющую самых распространенных типов интеграций (REST, gRPC, Kafka, RabbitMQ) и архитектуру систем
• Резюме Middle-аналитика с ориентиром на 200+ 💰

Записаться - ко мне в личные сообщения @oldschoolsysdes
Тем, кто интересовался обучением ранее, отвечу в течение ближайших дней 👨‍💻

❌ Что не затрагиваем на курсе:
• Изучение SQL.
• Проектирование аутентификации.
• Проектирование UI.
Почему?
Потому что это составляет около 10% от возможного объёма рабочих задач, таким образом мы сокращаем время и стоимость обучения.

❗️P.S. По причине высокой нагрузки на моей основной работе вероятнее всего это будет последний поток обучения в этом году в текущем формате (онлайн)