К опросу выше⬆️

Я тут прикольную рекламу увидел про заработную плату, что если ты сеньор разработки то твоя оплата 500 тысяч на руки, а если ит лидер, то до 800, но что то я в жизни таких кейсов видел разве, что штучно, а вы? Интересно будет посмотреть на опросу выше😀


@it_underside

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

Вот что это значит:

1️⃣Согласованность
Все сервера всегда видят одно и то же. Например, если ты записал что-то в систему, все сразу видят это обновление.

2️⃣ Доступность
Система всегда отвечает на запросы, даже если какие-то сервера не работают. То есть, пользователь всегда получит ответ, но он может быть не самым свежим.

3️⃣Устойчивость к разделению
Система продолжает работать, даже если часть серверов не может общаться друг с другом (например, из-за проблем с сетью).

Суть CAP теоремы

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

Как это применить на практике

1️⃣Анализируй потребности
Подумай, что для тебя важнее: актуальные данные, постоянная доступность или работа в условиях сетевых проблем.

2️⃣Выбирай архитектуру
Исходя из этого, выбирай компромисс. Например, если твоя система должна быстро отвечать пользователям, даже если данные не всегда актуальны (как в соцсетях), то тебе подойдёт модель AP (доступность + устойчивость к разделению).

3️⃣Реализуй
Выбирай технологии и подходы, которые соответствуют твоему выбору. Для CP систем (согласованность + устойчивость к разделению) подойдут реляционные базы данных. Для AP (доступность + устойчивость к разделению) — NoSQL базы.

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

P.S. надеюсь будет выглядеть нормально, с телефона набираешь когда, есть нюансы)

@it_underside

В общем сегодня увидел статейку обзорную про HighLoad++ 2024 и там есть обзор моего доклада "Опыт перевода банковского продукта в риалтайм", есть много спорных моментов, конечно в статье, но как понял автор, так и рассказал) но вообще рассказал достаточно подробно и близко к оригиналу😀

Да, я ищу второго тестировщика как раз на этот проект)) пишите, если у вас есть кто на примете.

А вот и статейка⬇️
https://habr.com/ru/articles/825566/


#ITнаизнанку #t1 #highload++ #2024

@it_underside

Привет! Тема дня - User Story (пользовательская история) такая важная и столь недооцененная вещь в командах ( встречал сеньеров, которые вообще не понимали, что от них хотят). Где-то сейчас посмотрят с неодобрением мастодонты и промолвят, что так не бывает. Скажу так, если ты носишь "шапку" аналитика, то будь добр хорошо разбираться в этой теме, а для молодых, джунов - основа основ.

Ну, что поехали? ☹️

User story – простое описание одной или нескольких функций продукта, написанное с точки зрения пользователя. Т.е. короткая, емкая история, которая описывает, кто пользователь, что он хочет сделать и зачем. Она помогает понять, какие задачи и потребности есть у пользователей, чтобы разработчики могли создавать более удобные и полезные продукты.

Пример user story:
1. Как пользователь, я хочу зарегистрироваться на сайте, чтобы иметь возможность оставлять комментарии.
2. Как администратор, я хочу видеть список всех зарегистрированных пользователей, чтобы управлять их доступом.
3. Как покупатель, я хочу иметь возможность добавлять товары в корзину, чтобы затем быстро оформить покупку.

User stories помогают командам:
- Понять пользователя;
- Согласовать задачи;
- Разбить работу на части.

Как правильно писать user stories?🤔

1. Используй простую структуру:
⚫️Кто: "Как [тип пользователя],"
⚫️Что: "я хочу [действие],"
⚫️Зачем: "чтобы [цель или причина]."

Пример: "Как студент, я хочу видеть свои оценки онлайн, чтобы быть в курсе своей успеваемости."

2. Будь конкретным. История должна быть конкретной и понятной, без лишних деталей.

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

Пример⬇️
История: "Как покупатель, я хочу добавить товары в избранное, чтобы легко найти их позже."
Критерии приемки:
⚫️Пользователь может добавить товар в избранное.
⚫️Пользователь может просматривать список избранных товаров.

🤫Зачем нужны user stories🤫

🍿 Фокус на пользователе. Помогают команде всегда думать о конечных пользователях и их потребностях.
📞Упрощение планирования. Делят большой проект на мелкие, управляемые части.
🫵Улучшение коммуникации. Обеспечивают ясность и понимание среди всех участников команды.

✍️Примеры хороших user stories✍️

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

P.S. надеюсь легко объяснил и адекватно))

@it_underside

Всем доброй пятницы!

Хотелось бы поговорить о архитектурном проектировании, ну про монолиты и микросервисы всякие) Сегодня начинаем серию статей об архитектурном проектировании, и первая тема — это конечно монолит!

Монолитная архитектура

Монолит — это классический подход к разработке ПО, где все компоненты системы объединены в одном приложении.

🔹 Преимущества

- Простота разработки и деплоя
- Централизованное управление кодовой базой
- Легкость отладки и тестирования

❌ Недостатки

- Трудности масштабирования
- Ограниченная гибкость при внесении изменений
- Риск возникновения узких мест и точек отказа

А чуть больше подробностей 🖱тут🖱

@it_underside

Тут до меня дошло, что уже понедельник😁, значит отдых идёт хорошо))) а пока ловите мини-статейку про микросервисный подход

https://telegra.ph/Tolko-mikroservisy-tolko-hardkor-07-04

Снизу не читайте🐱

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