🟦 Нотация C4. Подборка материалов
С4 – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: Context, Container, Component, Code – отсюда и название.
1️⃣ Диаграммы контекста (Context) – показывают систему в масштабе ее взаимодействия с пользователями и другими системами. Детали здесь не важны, так как это уменьшенное изображение, показывающее общую картину системного ландшафта. В центре внимания не технологии, протоколы и другие низкоуровневые детали, а люди и системы. С диаграммой этого уровня могут работать “люди из бизнеса”.
2️⃣ Диаграммы контейнеров (Container) – показывают, как система разделена на отдельные контейнеры, которые работают в своих средах выполнения и взаимодействуют друг с другом и с внешним миром. Контейнеры могут быть приложениями, базами данных, файловыми системами, скриптами и другими элементами, необходимыми для работы системы. Диаграмма контейнеров помогает понять, какие технологии используются в системе, как она устроена и как она обслуживает пользователей и другие системы.
3️⃣ Диаграммы компонентов (Component) – показывает устройство контейнера. Здесь компонент – это группа связанных функций, объединённых четко определенным интерфейсом. Все компоненты не являются отдельно развертываемыми единицами и обычно выполняются внутри контейнера в одном и том же пространстве процесса. Целевая аудитория диаграмм уровня Component – разработчики и системные архитекторы.
4️⃣ Диаграммы кода (Code) – создаются по запросу и показывают низкоуровневую реализацию компонентов. Рекомендовано использовать UML Class diagram/Entity relationship diagram и генерировать эти диаграммы автоматически.
Пример используемых инструментов для уровня Code:
▫️ PlantUML – позволяет генерировать UML-диаграммы из текста;
▫️ C4Builder – обеспечивает экспорт в PDF и прочие форматы;
▫️ C4-PlantUML — плагин для IDEA.
Главные преимущества C4
✅ Унифицированный способ рисовать архитектурные схемы. В отличие от “нотации” boxes and lines, когда каждый рисует, как хочет и непонятно что, модель C4 позволяет улучшить читаемость диаграмм благодаря формализации использования элементов и связей.
✅ Нужная степень детализации. Модель позволяет выбрать нужный уровень детализации вместо того, чтобы попытаться запихнуть все системы и сервисы в одну схему. Это похоже на Google Maps, где можно увидеть целые страны, прежде чем опуститься до области, города и отдельного дома.
⛔️ Недостатки C4
➖ Нотация не предъявляет строгих требований, поэтому диаграммы могут выглядеть по-разному в зависимости от автора. Для большего единообразия требуются дополнительные правила на уровне соглашения архитекторов.
➖ Модель не даёт чётких критериев по выделению контейнеров и компонентов. Могут возникать споры, например, по поводу отнесения базы данных к уровню Context или к уровню Component.
➖ Модель предполагает, что система может быть полностью описана четырьмя уровнями детализации, но это не всегда так. В зависимости от размера, сложности и характера системы, может потребоваться больше или меньше уровней, а также различные способы перехода между ними.
➖ Модель не учитывает изменения в архитектуре во времени и не позволяет отображать различные варианты и сценарии.
📎 Материалы
🌐 Официальный сайт
📄 Статьи
1. Как описать архитектуру продукта по нотации C4 — теория (вариант 1)
2. Как описать большую систему в нотации С4 — теория (вариант 2)
3. Аналитик и архитектура: UML-диаграммы для модели C4 — статья от Babok School
4. Описание архитектуры системы с помощью C4 model — взгляд разработчика
5. Опыт составления HLD-документации по нотации C4
⏯️ Видео
1. Визуализация архитектуры C4 model / Максим Пальчиков
2. Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин
3. C4 models as code — Simon Brown
🎓 Бесплатный курс
#проектирование #архитектура #подборка
С4 – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: Context, Container, Component, Code – отсюда и название.
1️⃣ Диаграммы контекста (Context) – показывают систему в масштабе ее взаимодействия с пользователями и другими системами. Детали здесь не важны, так как это уменьшенное изображение, показывающее общую картину системного ландшафта. В центре внимания не технологии, протоколы и другие низкоуровневые детали, а люди и системы. С диаграммой этого уровня могут работать “люди из бизнеса”.
2️⃣ Диаграммы контейнеров (Container) – показывают, как система разделена на отдельные контейнеры, которые работают в своих средах выполнения и взаимодействуют друг с другом и с внешним миром. Контейнеры могут быть приложениями, базами данных, файловыми системами, скриптами и другими элементами, необходимыми для работы системы. Диаграмма контейнеров помогает понять, какие технологии используются в системе, как она устроена и как она обслуживает пользователей и другие системы.
3️⃣ Диаграммы компонентов (Component) – показывает устройство контейнера. Здесь компонент – это группа связанных функций, объединённых четко определенным интерфейсом. Все компоненты не являются отдельно развертываемыми единицами и обычно выполняются внутри контейнера в одном и том же пространстве процесса. Целевая аудитория диаграмм уровня Component – разработчики и системные архитекторы.
4️⃣ Диаграммы кода (Code) – создаются по запросу и показывают низкоуровневую реализацию компонентов. Рекомендовано использовать UML Class diagram/Entity relationship diagram и генерировать эти диаграммы автоматически.
Пример используемых инструментов для уровня Code:
▫️ PlantUML – позволяет генерировать UML-диаграммы из текста;
▫️ C4Builder – обеспечивает экспорт в PDF и прочие форматы;
▫️ C4-PlantUML — плагин для IDEA.
Главные преимущества C4
✅ Унифицированный способ рисовать архитектурные схемы. В отличие от “нотации” boxes and lines, когда каждый рисует, как хочет и непонятно что, модель C4 позволяет улучшить читаемость диаграмм благодаря формализации использования элементов и связей.
✅ Нужная степень детализации. Модель позволяет выбрать нужный уровень детализации вместо того, чтобы попытаться запихнуть все системы и сервисы в одну схему. Это похоже на Google Maps, где можно увидеть целые страны, прежде чем опуститься до области, города и отдельного дома.
⛔️ Недостатки C4
➖ Нотация не предъявляет строгих требований, поэтому диаграммы могут выглядеть по-разному в зависимости от автора. Для большего единообразия требуются дополнительные правила на уровне соглашения архитекторов.
➖ Модель не даёт чётких критериев по выделению контейнеров и компонентов. Могут возникать споры, например, по поводу отнесения базы данных к уровню Context или к уровню Component.
➖ Модель предполагает, что система может быть полностью описана четырьмя уровнями детализации, но это не всегда так. В зависимости от размера, сложности и характера системы, может потребоваться больше или меньше уровней, а также различные способы перехода между ними.
➖ Модель не учитывает изменения в архитектуре во времени и не позволяет отображать различные варианты и сценарии.
📎 Материалы
🌐 Официальный сайт
📄 Статьи
1. Как описать архитектуру продукта по нотации C4 — теория (вариант 1)
2. Как описать большую систему в нотации С4 — теория (вариант 2)
3. Аналитик и архитектура: UML-диаграммы для модели C4 — статья от Babok School
4. Описание архитектуры системы с помощью C4 model — взгляд разработчика
5. Опыт составления HLD-документации по нотации C4
⏯️ Видео
1. Визуализация архитектуры C4 model / Максим Пальчиков
2. Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин
3. C4 models as code — Simon Brown
🎓 Бесплатный курс
#проектирование #архитектура #подборка
🔥16👍10⚡6❤5
Forwarded from Библиотека Системного Аналитика
P of EAA Фаулер.pdf
54.4 MB
P of EAA: Patterns of Enterprise Application Architecture
(Шаблоны корпоративных приложений)
✍️ Автор: Мартин Фаулер
📅 Год: 2016
🔤 Язык: русский
📚 Объём: 548 стр.
Неустаревающая классика от Мартина Фаулера, которая раскладывает по полочкам создание корпоративных систем, дает ответы на сложные вопросы разработчиков из соответствующей сферы. Фаулер отметил, что даже с быстрым развитием технологий основные принципы проектирования не меняются. Он собрал свыше 40 оптимальных подходов в этом настольном руководстве по корпоративным приложениям. Материал ориентирован на архитекторов, проектировщиков и программистов, задействованных в создании корпоративных ПО и желающих повысить качество своих решений.
#проектирование
(Шаблоны корпоративных приложений)
✍️ Автор: Мартин Фаулер
📅 Год: 2016
🔤 Язык: русский
📚 Объём: 548 стр.
Неустаревающая классика от Мартина Фаулера, которая раскладывает по полочкам создание корпоративных систем, дает ответы на сложные вопросы разработчиков из соответствующей сферы. Фаулер отметил, что даже с быстрым развитием технологий основные принципы проектирования не меняются. Он собрал свыше 40 оптимальных подходов в этом настольном руководстве по корпоративным приложениям. Материал ориентирован на архитекторов, проектировщиков и программистов, задействованных в создании корпоративных ПО и желающих повысить качество своих решений.
#проектирование
🔥12👍4🎉2
🧭 Навигация по материалам
В нашем канале уже вышло несколько десятков полезных статей и давно созрела необходимость систематизировать посты, чтобы было проще ориентироваться. Список будет регулярно обновляться — каждый новый пост будет попадать в соответствующую рубрику в закрепе.
Подборки
📚 Подборка лучших книг для системных аналитиков
🎙 Бесплатные подкасты из Радио "Аналитик"
🟦 Нотация C4. Подборка материалов
💩 Большая подборка открытых API
Работа с требованиями
💩 Требования к требованиям, или свойства качественных требований
💩 Нефункциональные требования и зачем они нужны
💩 Декомпозиция требований и задач
💩 Статьи про User Stories
💩 4 шага как «раскопать» систему
Интеграции
💩 Типы интеграции систем. Преимущества и недостатки
💩 Как выбрать тип межсистемной интеграции
💩 Чем отличаюется синхронное и асинхронное взаимодействие
💩 HTTP. Что нужно знать аналитику
💩 HTTP. Краткие советы по использованию протокола
💩 HTTPS и его отличие от HTTP
💩 Webhook. Что это такое и когда используется
💩 WebSocket: что это, когда следует использовать и какие преимущества дает
💩 Подборка бесплатных вебинаров по основам интеграции систем
API
💩 Интеграция через API
💩 REST. Краткий обзор
💩 Ликбез по понятиям: REST, API, HTTP
💩 Подборка материалов по изучению REST
💩 SOAP. Краткий обзор
💩 REST vs SOAP. Главное
💩 gRPC – краткий обзор
💩 gRPC vs REST: сравнение по пунктам
💩 GraphQL: основные понятия
💩 GraphQL vs REST: сравнение по пунктам
💩 Большая подборка открытых API
💩 JSON-RPC: что это такое и чем отличается от REST
💩 Открытый курс по документированию API
💩 Документирование REST API с помощью Swagger и OpenAPI
Асинхронные интеграции
💩 Что нужно знать про асинхронные интеграции
💩 Очереди сообщений. Основные понятия
💩 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений
💩 Основы Kafka – что нужно знать аналитику
💩 Подборка бесплатных материалов по Kafka
💩 Основы RabbitMQ – что нужно знать аналитику
💩 Подборка бесплатных материалов по RabbitMQ
💩 Kafka vs RabbitMQ: сравнение по пунктам
Архитектура и проектирование
🔹Микросервисная архитектура: основные понятия
🔹Подборка материалов по микросервисной архитектуре
🔹Микросервисы VS монолит: сравнение в карточках
🔹SOA vs MSA: чем отличается микросервисная архитектура от сервисно-ориентированной?
🔹Архитектурные стили и паттерны
🔹Кэширование — разбор по полочкам
🔹Domain Driven Design: что это такое и зачем оно нужно системному аналитику
🔹Как работает клиент-серверная архитектура
🔹Contract First vs Code First: что выбрать
🔹Лучшие практики проектирования API
🔹Авторизация и аутентификация
🔹SSO
Базы данных
▪️Основные понятия баз данных
▪️Подборка полезных материалов по основам баз данных
▪️SQL vs NoSQL: отличие реляционных и нереляционных БД
▪️Типы связей в БД. Нормализация
▪️Виды нереляционных БД. Какие бывают NoSQL базы данных
▪️Шпаргалка по выбору правильной СУБД
▪️Памятка по SQL
Инфраструктура и сети
💩 Разбираемся с моделью OSI на пальцах
💩 Виртуализация, контейнеризация и оркестрация
💩 Балансировка нагрузки. Основные принципы
Информационная безопасность
▫️Безопасность API: базовые принципы
▫️Шифрование, хэширование, хэширование с солью и маскирование
Управление проектами
🔸Agile и Waterfall: главное о методологиях разработки ПО
🔸Релизный процесс. Кратко
Тестирование
💩 Основные понятия тестирования
Развитие навыков
💩 Интерактивная карта навыков системного аналитика
💩 Задачник для системных аналитиков от Тинькофф
💩 Задачи для системных аналитиков из конкурса IT_One Cup 2022 с решениями
💩 Типовые ошибки младшего системного аналитика
💩 Отличие системного аналитика от бизнес-аналитика
Собеседования
💩 Топ ошибок кандидатов при собеседованиях на позицию системного аналитика
💩 123 задачи с IT-собеседований
Инструменты СА
➖PlantUML: полезные материалы
➖Graphana vs Kibana
➖Цикл статьей по изучению Postman
Все теги: #подборка #требования #интеграции #api #архитектура #микросервисы #сравнение #проектирование #бд #инфраструктура #безопасность #управление_проектами #devops #тестирование #развитие #собеседования #инструменты #async #очереди #sql #управление_релизами
В нашем канале уже вышло несколько десятков полезных статей и давно созрела необходимость систематизировать посты, чтобы было проще ориентироваться. Список будет регулярно обновляться — каждый новый пост будет попадать в соответствующую рубрику в закрепе.
Подборки
📚 Подборка лучших книг для системных аналитиков
🎙 Бесплатные подкасты из Радио "Аналитик"
🟦 Нотация C4. Подборка материалов
Работа с требованиями
Интеграции
API
Асинхронные интеграции
Архитектура и проектирование
🔹Микросервисная архитектура: основные понятия
🔹Подборка материалов по микросервисной архитектуре
🔹Микросервисы VS монолит: сравнение в карточках
🔹SOA vs MSA: чем отличается микросервисная архитектура от сервисно-ориентированной?
🔹Архитектурные стили и паттерны
🔹Кэширование — разбор по полочкам
🔹Domain Driven Design: что это такое и зачем оно нужно системному аналитику
🔹Как работает клиент-серверная архитектура
🔹Contract First vs Code First: что выбрать
🔹Лучшие практики проектирования API
🔹Авторизация и аутентификация
🔹SSO
Базы данных
▪️Основные понятия баз данных
▪️Подборка полезных материалов по основам баз данных
▪️SQL vs NoSQL: отличие реляционных и нереляционных БД
▪️Типы связей в БД. Нормализация
▪️Виды нереляционных БД. Какие бывают NoSQL базы данных
▪️Шпаргалка по выбору правильной СУБД
▪️Памятка по SQL
Инфраструктура и сети
Информационная безопасность
▫️Безопасность API: базовые принципы
▫️Шифрование, хэширование, хэширование с солью и маскирование
Управление проектами
🔸Agile и Waterfall: главное о методологиях разработки ПО
🔸Релизный процесс. Кратко
Тестирование
Развитие навыков
Собеседования
Инструменты СА
➖PlantUML: полезные материалы
➖Graphana vs Kibana
➖Цикл статьей по изучению Postman
Все теги: #подборка #требования #интеграции #api #архитектура #микросервисы #сравнение #проектирование #бд #инфраструктура #безопасность #управление_проектами #devops #тестирование #развитие #собеседования #инструменты #async #очереди #sql #управление_релизами
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Системный Аналитик
🔥 Книги для системного аналитика бесплатно без регистрации и СМС 📚
Собрали для Вас 20 лучших книг для развития аналитика. Ссылки кликабельны, можно скачивать любую книгу отдельно или весь архив целиком.
👉 Скачать весь архив
Пересылайте коллегам, пусть тоже…
Собрали для Вас 20 лучших книг для развития аналитика. Ссылки кликабельны, можно скачивать любую книгу отдельно или весь архив целиком.
👉 Скачать весь архив
Пересылайте коллегам, пусть тоже…
🔥120👍24❤18👏5
Системный Аналитик pinned «🧭 Навигация по материалам В нашем канале уже вышло несколько десятков полезных статей и давно созрела необходимость систематизировать посты, чтобы было проще ориентироваться. Список будет регулярно обновляться — каждый новый пост будет попадать в соответствующую…»
Как известно, REST не является стандартом, а лишь предоставляет набор принципов, поэтому выбор способа документирования API в REST может быть разным.
OpenAPI — это самая популярная спецификация для документирования REST API. Спецификация OpenAPI не зависит от языка программирования и является машинночитаемой. Она описывается в формате JSON или YAML и содержит подробное описание методов, параметров, структуры данных и другой информации, необходимой для взаимодействия с АПИ.
Разрабатывать документацию по OpenAPI помогает Swagger, который представляет собой набор инструментов:
Способы документирования по OpenAPI
Существует два подхода к проектированию API и его документированию.
🔸 Code first — сначала пишем код, потом по нему генерируем документацию. Для всех популярных языков программирования есть библиотеки и фреймворки, которые с помощью специальных аннотаций/комментариев в коде могут автоматически генерировать спецификацию по OpenAPI.
🔹 Contract first — сначала создаем документацию (контракт), а уже потом по нему пишем код. Так как кода ещё нет, придётся вручную описывать файл спецификации OpenAPI в формате YAML или JSON. Это можно делать с помощью Swagger Editor — онлайн-редактора, который позволяет создавать и редактировать спецификацию OpenAPI в удобном интерфейсе.
В чём разница между OpenAPI и Swagger?
OpenAPI — это спецификация.
Swagger — это инструментарий, использующий спецификацию OpenAPI. Например, OpenAPIGenerator и SwaggerUI.
🖇 Материалы по изучению OpenAPI и Swagger
🌐 Официальная документация:
OpenAPI, Swagger
🎓 Открытый курс по документированию API
📑 Статьи
1. OpenAPI/Swagger для начинающих
2. Как построить REST-like API в крупном проекте
3. Как ускорить тестирование приложения с помощью OpenAPI-спецификаций
✏️ Примеры готовых спецификаций OpenAPI
1. Спецификация GitHub
2. Тестовый SwaggerUI
🔧 Инструменты
1. stoplight.io — позволяет упростить написание и ведение спецификаций
#проектирование #api
Please open Telegram to view this post
VIEW IN TELEGRAM
👍33🔥26❤9
Forwarded from Библиотека Системного Аналитика
❤22👍13🔥4
Библиотека Системного Аналитика
Мартин Фаулер. UML. Основы.pdf
📚 Подборка книг по UML на русском языке
1️⃣ Мартин Фаулер. UML. Основы.
Совсем небольшая книга, написана простым языком. Подходит для новичков в UML.
2️⃣ Буч Грэди. Язык UML. Руководство пользователя.
Более подробная чем первая, тоже подходит для новичков.
3️⃣ Дж. Шмуллер. Освой самостоятельно UML за 24 часа.
За 24 часа, конечно, вряд ли освоите, но азы в этом книге растолкованы неплохо.
4️⃣ Крэг Ларман. Применение UML и шаблонов проектирования.
В книге основной упор делается на объектно-ориентированный анализ и проектирование. UML является лишь удобным дополняющим инструментом. Для более продвинутых пользователей.
5️⃣ Джим Арлоу. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование. Книга посвящена использованию UML в связке с RUP. Вы узнаете о роли моделирования в цикле разработки ПО, и эти знания помогут вам ответить на вопрос: как и когда использовать (или не использовать) UML, чтобы найти оптимальное решение для своего проекта. Авторы приводят множество примеров и дают рекомендации по разработке моделей.
6️⃣ М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка. Книга помогает научиться мыслить в глобальном понимании проектирования любого приложения, от самого высокого уровня абстракции и до момента написания кода. Книга написана подробно (иногда чересчур) и доступно, особенно раздел, посвященный моделированию. Благодаря сквозному примеру, можно связать все модели логически, что облегчает понимание.
7️⃣ Александр Леоненков. Самоучитель UML. Можно использовать в качестве полного справочника по UML. Для новичков может быть избыточная информация, редко встречающееся на практике.
Скачать можно все книги из поста выше.
🏴☠️ опять напиратили
#проектирование #uml
1️⃣ Мартин Фаулер. UML. Основы.
Совсем небольшая книга, написана простым языком. Подходит для новичков в UML.
2️⃣ Буч Грэди. Язык UML. Руководство пользователя.
Более подробная чем первая, тоже подходит для новичков.
3️⃣ Дж. Шмуллер. Освой самостоятельно UML за 24 часа.
За 24 часа, конечно, вряд ли освоите, но азы в этом книге растолкованы неплохо.
4️⃣ Крэг Ларман. Применение UML и шаблонов проектирования.
В книге основной упор делается на объектно-ориентированный анализ и проектирование. UML является лишь удобным дополняющим инструментом. Для более продвинутых пользователей.
5️⃣ Джим Арлоу. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование. Книга посвящена использованию UML в связке с RUP. Вы узнаете о роли моделирования в цикле разработки ПО, и эти знания помогут вам ответить на вопрос: как и когда использовать (или не использовать) UML, чтобы найти оптимальное решение для своего проекта. Авторы приводят множество примеров и дают рекомендации по разработке моделей.
6️⃣ М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка. Книга помогает научиться мыслить в глобальном понимании проектирования любого приложения, от самого высокого уровня абстракции и до момента написания кода. Книга написана подробно (иногда чересчур) и доступно, особенно раздел, посвященный моделированию. Благодаря сквозному примеру, можно связать все модели логически, что облегчает понимание.
7️⃣ Александр Леоненков. Самоучитель UML. Можно использовать в качестве полного справочника по UML. Для новичков может быть избыточная информация, редко встречающееся на практике.
Скачать можно все книги из поста выше.
#проектирование #uml
🔥28👍7❤4
🔐 Авторизация и аутентификация. Обзор
Авторизация и аутентификация — это два разных, но тесно связанных процесса, которые обеспечивают безопасность и доступность данных и ресурсов в системе.
🆔 Идентификация — это процесс установления личности пользователя, то есть получение его идентификатора, такого как логин, email, номер телефона и т.д. Идентификация является первым шагом аутентификации, так как без нее система не знает, с кем имеет дело.
🔑 Аутентификация — это проверка подлинности личности пользователя, то есть подтверждение того, что он является тем, кем себя представляет.
🔐 Авторизация — это определение прав пользователя на доступ к определенным данным и ресурсам в системе, то есть установление того, что он может делать после аутентификации.
Пример: когда Вася хочет войти в конфлюэнс и вводит свою почту, система понимает, что аккаунт с таким email существует. Это идентификация. Затем система отправляет на Васин номер СМС с одноразовым паролем, а Вася вводит пароль и тем самым доказывает, что это именно он. Это аутентификация. Система понимает, что Вася настоящий и перенаправляет его на главную страницу – это авторизация, ведь Вася авторизован (то есть имеет право) на чтение главной страницы, как и любой другой сотрудник.
Способы аутентификации
🔗 OAuth 2.0 — это протокол авторизации, предназначенный для организации доступа клиента к ресурсам или данным на другом сервисе. После выполнения процедуры входа клиент получает от сервера
Напрямую возвращать токен владельцу после успешного входа на сервер OAuth 2 небезопасно. Вместо этого возвращается access_token, который затем обменивается на JWT-токен.
📜 JWT (JSON Web Token) – это открытый стандарт для создания и передачи данных в формате JSON, которые могут быть подписаны и/или зашифрованы. Поскольку информация конфиденциальна, такой токен хранится обычно несколько минут.
JWT состоит из трёх частей: заголовка, полезной нагрузки, подписи. Получив JWT от пользователя, приложение сравнивает секретный ключ с тем значением, которое было передано в токене. Если эти значения не совпадут, значит доверять ему приложение не будет.
🔑 API-ключи – это ключи шифрования для аутентификации пользователя в системе, по аналогии логина и пароля. Ключ обычно передается в заголовке или параметре запроса.
Существует два вида ключей API:
1. Публичный ключ (открытый). Используется для шифрования данных при обращении приложения к серверу.
2. Секретный ключ (закрытый). Известен только пользователю и владельцу сайта. Используется для расшифровки данных, отправленных приложением.
API-ключи применяются при ассиметричном шифровании. Такое шифрование обеспечивает большую безопасность: если злоумышленник получит публичный ключ, то все равно не сможет пройти аутентификацию без секретного ключа.
🔒 mTLS (mutual TLS) — это расширение протокола TLS, которое позволяет обеим сторонам взаимодействия (клиенту и серверу) аутентифицировать друг друга с помощью цифровых сертификатов. Это повышает уровень безопасности и доверия между сторонами, так как исключает возможность подмены или перехвата данных. mTLS часто используется для аутентификации между микросервисами или API.
Есть две пары сертификатов и два закрытых ключа.
1-й закрытый ключ находится на сервере и позволяет расшифровывать данные, которые шифруются открытым ключом, как при обычной работе TLS.
2-й закрытый ключ устанавливается на клиенте, а сервер при ответах клиенту также шифрует данные его открытым ключом. Таким образом, к серверу могут обращаться только те клиенты, у которых есть закрытый ключ для расшифровки данных.
Это не полный перечень всех способов, будем делать отдельные подборки про SSO, SAML, OpenID Connect.
Подборка материалов в следующем посте ➡️
#архитектура #безопасность
Авторизация и аутентификация — это два разных, но тесно связанных процесса, которые обеспечивают безопасность и доступность данных и ресурсов в системе.
🆔 Идентификация — это процесс установления личности пользователя, то есть получение его идентификатора, такого как логин, email, номер телефона и т.д. Идентификация является первым шагом аутентификации, так как без нее система не знает, с кем имеет дело.
🔑 Аутентификация — это проверка подлинности личности пользователя, то есть подтверждение того, что он является тем, кем себя представляет.
🔐 Авторизация — это определение прав пользователя на доступ к определенным данным и ресурсам в системе, то есть установление того, что он может делать после аутентификации.
Пример: когда Вася хочет войти в конфлюэнс и вводит свою почту, система понимает, что аккаунт с таким email существует. Это идентификация. Затем система отправляет на Васин номер СМС с одноразовым паролем, а Вася вводит пароль и тем самым доказывает, что это именно он. Это аутентификация. Система понимает, что Вася настоящий и перенаправляет его на главную страницу – это авторизация, ведь Вася авторизован (то есть имеет право) на чтение главной страницы, как и любой другой сотрудник.
Способы аутентификации
🔗 OAuth 2.0 — это протокол авторизации, предназначенный для организации доступа клиента к ресурсам или данным на другом сервисе. После выполнения процедуры входа клиент получает от сервера
access_token, который позволяет клиентскому приложению получать доступ к ресурсу для выполнения определенных действий от имени пользователя и refresh_token – необходимый для обновления access_token. refresh_token обычно имеет длительный срок действия (исчисляется в месяцах) и обменивается на новый по истечению срока действия. Напрямую возвращать токен владельцу после успешного входа на сервер OAuth 2 небезопасно. Вместо этого возвращается access_token, который затем обменивается на JWT-токен.
📜 JWT (JSON Web Token) – это открытый стандарт для создания и передачи данных в формате JSON, которые могут быть подписаны и/или зашифрованы. Поскольку информация конфиденциальна, такой токен хранится обычно несколько минут.
JWT состоит из трёх частей: заголовка, полезной нагрузки, подписи. Получив JWT от пользователя, приложение сравнивает секретный ключ с тем значением, которое было передано в токене. Если эти значения не совпадут, значит доверять ему приложение не будет.
🔑 API-ключи – это ключи шифрования для аутентификации пользователя в системе, по аналогии логина и пароля. Ключ обычно передается в заголовке или параметре запроса.
Существует два вида ключей API:
1. Публичный ключ (открытый). Используется для шифрования данных при обращении приложения к серверу.
2. Секретный ключ (закрытый). Известен только пользователю и владельцу сайта. Используется для расшифровки данных, отправленных приложением.
API-ключи применяются при ассиметричном шифровании. Такое шифрование обеспечивает большую безопасность: если злоумышленник получит публичный ключ, то все равно не сможет пройти аутентификацию без секретного ключа.
🔒 mTLS (mutual TLS) — это расширение протокола TLS, которое позволяет обеим сторонам взаимодействия (клиенту и серверу) аутентифицировать друг друга с помощью цифровых сертификатов. Это повышает уровень безопасности и доверия между сторонами, так как исключает возможность подмены или перехвата данных. mTLS часто используется для аутентификации между микросервисами или API.
Есть две пары сертификатов и два закрытых ключа.
1-й закрытый ключ находится на сервере и позволяет расшифровывать данные, которые шифруются открытым ключом, как при обычной работе TLS.
2-й закрытый ключ устанавливается на клиенте, а сервер при ответах клиенту также шифрует данные его открытым ключом. Таким образом, к серверу могут обращаться только те клиенты, у которых есть закрытый ключ для расшифровки данных.
Это не полный перечень всех способов, будем делать отдельные подборки про SSO, SAML, OpenID Connect.
Подборка материалов в следующем посте ➡️
#архитектура #безопасность
👍50🔥25❤7
Forwarded from Библиотека Системного Аналитика
Guide_to_the_Systems_Engineering_Body_of_Knowledge_v2.9.pdf
35.2 MB
SEBoK — свод знаний по системной инженерии
Все знают про существование BABOK для бизнес-аналитиков, но не каждый знает, что и системные аналитики тоже имеют собственный свод знаний — SEBoK.
К сожалению, нам не удалось найти полноценный перевод на русский за исключением нескольких статей на Хабре.
SEBoK регулярно обновляется, последняя версия выпущена 20 ноября 2023 г. Изменения можно отслеживать на официальном сайте, там же можно почитать свод знаний в формате вики-страниц.
#свод_знаний
Все знают про существование BABOK для бизнес-аналитиков, но не каждый знает, что и системные аналитики тоже имеют собственный свод знаний — SEBoK.
К сожалению, нам не удалось найти полноценный перевод на русский за исключением нескольких статей на Хабре.
SEBoK регулярно обновляется, последняя версия выпущена 20 ноября 2023 г. Изменения можно отслеживать на официальном сайте, там же можно почитать свод знаний в формате вики-страниц.
#свод_знаний
🔥29👍7❤1
По сети разлетелся пример того, как Zoom AI Companion составляет тестовое содержание встреч. Если это не фейк, то вещь незаменимая
👍15🔥7😁5
SSO
SSO (Single Sign-On) – это технология, которая позволяет пользователю войти в несколько систем без повторной аутентификации.
Например, пользователь входит в систему под своей корпоративной учёткой. Далее он может открывать портал компании, Confluence, Zoom, Outlook, Office – и ему не придётся проходить аутентификацию в каждом приложении по отдельности.
Как работает SSO
1️⃣ Когда пользователь входит в приложение, генерируется SSO-токен и отправляется запрос на аутентификацию в службу SSO.
2️⃣ Сервис проверяет, был ли пользователь ранее аутентифицирован в системе. Если да, он отправляет приложению ответ с подтверждением аутентификации, чтобы предоставить пользователю доступ.
3️⃣ Если у пользователя нет подтвержденного аккаунта, служба SSO перенаправляет пользователя в центральную систему входа (в нашем примере – аутентификация в ОС) и предлагает ему ввести имя пользователя и пароль.
4️⃣ После отправки сервис проверяет учетные данные пользователя и отправляет положительный ответ приложению.
5️⃣ В противном случае пользователь получает сообщение об ошибке и должен повторно ввести учетные данные. Многочисленные неудачные попытки входа в систему могут привести к тому, что сервис заблокирует пользователя от дальнейших попыток на определенный период времени.
Протоколы для SSO
🔸 SAML — это протокол аутентификации, основанный на языке XML. Веб-приложения используют SAML, чтобы передавать аутентификационные данные между сторонами процесса: а именно, между системой управления доступами и провайдером услуг.
🔹 OAuth 2.0 – это протокол авторизации, который позволяет приложениям получать доступ к информации пользователя с других сайтов, не сообщая ему пароль. Вместо постоянного использования паролей, приложения используют токены для доступа к данным данным.
OpenID Connect
OAuth 2.0 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому.
OpenID Connect (OIDC) — это слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись.
🆚 OAuth VS SAML
OAuth и SAML — это протоколы, используемые для предоставления доступа. Но есть радикальное отличие между ними — SAML для аутентификации, а OAuth для авторизации.
✅ Преимущества SSO
💩 Удобство: пользователь не тратит время и силы на запоминание, ввод или восстановление множества аккаунтов.
💩 Безопасность: пользователь может использовать один сильный пароль, который не хранится и не передается. Токены имеют ограниченный срок действия и могут быть отозваны.
💩 Управление: администратор может централизованно управлять учетными записями, ролями, правами и активностью пользователей, а также интегрировать новые приложения или сайты в систему SSO.
⛔️ Недостатки SSO
💩 Сложность: реализация и поддержка SSO требует дополнительных затрат и ресурсов, таких как разработка, настройка, совместимость и безопасность разных компонентов системы.
💩 Зависимость: если центральный сервер SSO выходит из строя, то все приложения, которые используют SSO, тоже падают. Также, если пользователь теряет свой логин или пароль от центрального сервера, то он теряет доступ ко всем приложениям.
💩 Приватность: пользователь может не захотеть делиться своей личной информацией с разными приложениями, которые используют SSO.
🔹 Наши подборки
Авторизация и аутентификация:
обзор + подборка материалов
📄 Статьи
1. Как работает single sign-on (технология единого входа)?
2. Технология единого входа: как работает SSO
3. Реализация SSO через SAML с примером
4. OpenID Connect (OIDC): Как получить токен?
5. Иллюстрированное руководство по OAuth и OpenID Connect
6. Как работает OAuth 2.0 и OpenID Connect
7. SAML простыми словами
8. Статьи про Keycloak: 1 и 2
9. SSO на микросервисной архитектуре. Используем Keycloak
⏯ Видео
1. SSO — три заветные буквы MustHave в любой архитектуре. Илья Волынкин. ArchDays 2022
2. Проектирование логики аутентификации и авторизации: cookies, JWT, SSO, OAuth 2.0
3. SSO на базе OpenId Connect в корпоративной системе
4. Технология SSO на примере SAML
5. SSO за 13 минут
#архитектура #проектирование
SSO (Single Sign-On) – это технология, которая позволяет пользователю войти в несколько систем без повторной аутентификации.
Например, пользователь входит в систему под своей корпоративной учёткой. Далее он может открывать портал компании, Confluence, Zoom, Outlook, Office – и ему не придётся проходить аутентификацию в каждом приложении по отдельности.
Как работает SSO
1️⃣ Когда пользователь входит в приложение, генерируется SSO-токен и отправляется запрос на аутентификацию в службу SSO.
2️⃣ Сервис проверяет, был ли пользователь ранее аутентифицирован в системе. Если да, он отправляет приложению ответ с подтверждением аутентификации, чтобы предоставить пользователю доступ.
3️⃣ Если у пользователя нет подтвержденного аккаунта, служба SSO перенаправляет пользователя в центральную систему входа (в нашем примере – аутентификация в ОС) и предлагает ему ввести имя пользователя и пароль.
4️⃣ После отправки сервис проверяет учетные данные пользователя и отправляет положительный ответ приложению.
5️⃣ В противном случае пользователь получает сообщение об ошибке и должен повторно ввести учетные данные. Многочисленные неудачные попытки входа в систему могут привести к тому, что сервис заблокирует пользователя от дальнейших попыток на определенный период времени.
Протоколы для SSO
🔸 SAML — это протокол аутентификации, основанный на языке XML. Веб-приложения используют SAML, чтобы передавать аутентификационные данные между сторонами процесса: а именно, между системой управления доступами и провайдером услуг.
🔹 OAuth 2.0 – это протокол авторизации, который позволяет приложениям получать доступ к информации пользователя с других сайтов, не сообщая ему пароль. Вместо постоянного использования паролей, приложения используют токены для доступа к данным данным.
OpenID Connect
OAuth 2.0 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому.
OpenID Connect (OIDC) — это слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись.
🆚 OAuth VS SAML
OAuth и SAML — это протоколы, используемые для предоставления доступа. Но есть радикальное отличие между ними — SAML для аутентификации, а OAuth для авторизации.
✅ Преимущества SSO
⛔️ Недостатки SSO
Авторизация и аутентификация:
обзор + подборка материалов
📄 Статьи
1. Как работает single sign-on (технология единого входа)?
2. Технология единого входа: как работает SSO
3. Реализация SSO через SAML с примером
4. OpenID Connect (OIDC): Как получить токен?
5. Иллюстрированное руководство по OAuth и OpenID Connect
6. Как работает OAuth 2.0 и OpenID Connect
7. SAML простыми словами
8. Статьи про Keycloak: 1 и 2
9. SSO на микросервисной архитектуре. Используем Keycloak
1. SSO — три заветные буквы MustHave в любой архитектуре. Илья Волынкин. ArchDays 2022
2. Проектирование логики аутентификации и авторизации: cookies, JWT, SSO, OAuth 2.0
3. SSO на базе OpenId Connect в корпоративной системе
4. Технология SSO на примере SAML
5. SSO за 13 минут
#архитектура #проектирование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍34🔥14❤5
💠 Декомпозиция требований и задач
Декомпозиция требований — разбиение хотелок бизнеса на более конкретные и понятные задачи, которые можно передавать в разработку. Декомпозиция позволяет лучше понимать дальнейшие шаги по реализации, правильно расставить приоритеты и точнее давать оценку по срокам вывода функционала. Когда функционал разбивается на части и реализуется последовательно, это позволяет быстрее получить обратную связь от заказчика и сохранить гибкость к изменениям, а также быстрее вывести рабочий функционал. В общем, понятнее, что разрабатывать и рисков меньше.
Горизонтальная и вертикальная декомпозиция
При горизонтальной декомпозиции задачи делятся по типам работ, по уровням или по компонентам. Например, одна задача идет в бэк, вторая во фронт, а третья приводит к изменениям в базе данных. Главный минус: готовый функционал можно получить только после выполнения всех задач.
Вертикальная декомпозиция означает, что результат каждой задачи должен быть логически завершенным и работающим функционалом, который можно показать заказчику.
Методы декомпозиции
1️⃣ Несколько потребностей: задача делится по союзам «и», «или». Например, «сделать заказ и оплатить картой или бонусами» разбивается на три подзадачи.
2️⃣ Сценарии использования: задача делится по основному и альтернативным путям. Например, «купить товар» разбивается на подзадачи «сравнить товары», «добавить в избранное», «узнать о наличии» и т.д.
3️⃣ Разбиение по позитивным и негативным сценариям: по ожидаемому и неожиданному поведению функционала. Например, «совершить покупку по карте» разбивается на подзадачи «совершить покупку без ошибок», «обработать ошибку при недостатке средств на карте», «обработать ошибку при блокировке учетной записи» и т.д.
4️⃣ Разбиение по этапам процесса: по последовательным шагам, которые составляют процесс. Например, «совершить покупку в интернет магазине» разбивается на подзадачи «войти в личный кабинет», «просмотреть товары в корзине», «сформировать счет на оплату» и т.д.
5️⃣ От простого к сложному: по уровню сложности функционала. Например, «сделать баннер» разбивается на подзадачи «показать одну картинку», «сделать сетку из картинок», «сделать карусель из картинок» и т.д.
6️⃣ Операции (CRUD): задача делится по операциям создания, чтения, обновления и удаления. Например, «оформить заказ» разбивается на подзадачи «создать заказ», «просмотреть заказ», «редактировать заказ» и «удалить заказ».
7️⃣ Варианты интерфейса: по поддержке разных языков, устройств, браузеров и т.д. Например, «сделать сайт мультиязычным» разбивается на подзадачи «сделать русскоязычную версию», «сделать англоязычную версию» и т.д.
8️⃣ Разбиение по типам платформы/ОС. Например, «оплатить покупку» разбивается на подзадачи «оплатить покупку на ПК», «оплатить покупку на планшете», «оплатить покупку на смартфоне» и т.д.
9️⃣ Разделение по ролям. Например, «сделать сайт» разбивается на подзадачи «сделать сайт для анонимных пользователей», «сделать сайт для авторизованных пользователей», «сделать бэкофис для пользователей колл-центра» и т.д.
🔟 Разбиение по типам данных и параметрам: по разным типам данных или параметрам, которые функционал должен обрабатывать. Например, «поиск товаров» разбивается на подзадачи «поиск по тексту», «поиск по коду», «поиск по регулярным выражениям» и т.д.
📄 Статьи
1. 8 методов декомпозиции задач
2. Паттерны декомпозиции User Story / задач (из России с VPN)
3. Как справиться с декомпозицией задач и не перестараться + видео
4. Story Mapping на примере пиццерии
5. SPIDR — пять простых техник для создания идеально разделенной пользовательской истории
6. Разбиение пользовательских историй – метод гамбургера
⏯ Видео
1. Декомпозиция задач и аналитик — Михаил Максимов
2. Как мы разбирали слона. Целые, сломанные и лишние детали — доклад Алексея Козлова на конференции Analyst Days-7
3. User Story Splitting: как и зачем добавлять детали пользовательским историям — Юрий Куприянов
4. Использование Use case и User story для декомпозиции задач — Михаил Максимов
5. Плейлист про декомпозицию задач
#требования
Декомпозиция требований — разбиение хотелок бизнеса на более конкретные и понятные задачи, которые можно передавать в разработку. Декомпозиция позволяет лучше понимать дальнейшие шаги по реализации, правильно расставить приоритеты и точнее давать оценку по срокам вывода функционала. Когда функционал разбивается на части и реализуется последовательно, это позволяет быстрее получить обратную связь от заказчика и сохранить гибкость к изменениям, а также быстрее вывести рабочий функционал. В общем, понятнее, что разрабатывать и рисков меньше.
Горизонтальная и вертикальная декомпозиция
При горизонтальной декомпозиции задачи делятся по типам работ, по уровням или по компонентам. Например, одна задача идет в бэк, вторая во фронт, а третья приводит к изменениям в базе данных. Главный минус: готовый функционал можно получить только после выполнения всех задач.
Вертикальная декомпозиция означает, что результат каждой задачи должен быть логически завершенным и работающим функционалом, который можно показать заказчику.
Методы декомпозиции
1️⃣ Несколько потребностей: задача делится по союзам «и», «или». Например, «сделать заказ и оплатить картой или бонусами» разбивается на три подзадачи.
2️⃣ Сценарии использования: задача делится по основному и альтернативным путям. Например, «купить товар» разбивается на подзадачи «сравнить товары», «добавить в избранное», «узнать о наличии» и т.д.
3️⃣ Разбиение по позитивным и негативным сценариям: по ожидаемому и неожиданному поведению функционала. Например, «совершить покупку по карте» разбивается на подзадачи «совершить покупку без ошибок», «обработать ошибку при недостатке средств на карте», «обработать ошибку при блокировке учетной записи» и т.д.
4️⃣ Разбиение по этапам процесса: по последовательным шагам, которые составляют процесс. Например, «совершить покупку в интернет магазине» разбивается на подзадачи «войти в личный кабинет», «просмотреть товары в корзине», «сформировать счет на оплату» и т.д.
5️⃣ От простого к сложному: по уровню сложности функционала. Например, «сделать баннер» разбивается на подзадачи «показать одну картинку», «сделать сетку из картинок», «сделать карусель из картинок» и т.д.
6️⃣ Операции (CRUD): задача делится по операциям создания, чтения, обновления и удаления. Например, «оформить заказ» разбивается на подзадачи «создать заказ», «просмотреть заказ», «редактировать заказ» и «удалить заказ».
7️⃣ Варианты интерфейса: по поддержке разных языков, устройств, браузеров и т.д. Например, «сделать сайт мультиязычным» разбивается на подзадачи «сделать русскоязычную версию», «сделать англоязычную версию» и т.д.
8️⃣ Разбиение по типам платформы/ОС. Например, «оплатить покупку» разбивается на подзадачи «оплатить покупку на ПК», «оплатить покупку на планшете», «оплатить покупку на смартфоне» и т.д.
9️⃣ Разделение по ролям. Например, «сделать сайт» разбивается на подзадачи «сделать сайт для анонимных пользователей», «сделать сайт для авторизованных пользователей», «сделать бэкофис для пользователей колл-центра» и т.д.
🔟 Разбиение по типам данных и параметрам: по разным типам данных или параметрам, которые функционал должен обрабатывать. Например, «поиск товаров» разбивается на подзадачи «поиск по тексту», «поиск по коду», «поиск по регулярным выражениям» и т.д.
📄 Статьи
1. 8 методов декомпозиции задач
2. Паттерны декомпозиции User Story / задач (из России с VPN)
3. Как справиться с декомпозицией задач и не перестараться + видео
4. Story Mapping на примере пиццерии
5. SPIDR — пять простых техник для создания идеально разделенной пользовательской истории
6. Разбиение пользовательских историй – метод гамбургера
1. Декомпозиция задач и аналитик — Михаил Максимов
2. Как мы разбирали слона. Целые, сломанные и лишние детали — доклад Алексея Козлова на конференции Analyst Days-7
3. User Story Splitting: как и зачем добавлять детали пользовательским историям — Юрий Куприянов
4. Использование Use case и User story для декомпозиции задач — Михаил Максимов
5. Плейлист про декомпозицию задач
#требования
Please open Telegram to view this post
VIEW IN TELEGRAM
👍36🔥23❤8👏1🥱1
Важно ли аналитику уметь программировать?
По определению, аналитик не разработчик, поэтому уметь програмиировать он не должен. А вот понимать, что такое код и как он пишется — должен. И базовые навыки программирования хорошо помогают аналитику в его повседневной работе — проектировать решение.
Главное здесь не просто знание синтаксиса языка (это можно загуглить или спросить у нейросети), а умение строить алгоритмы, понимание, как требования ложатся на код.
Python — один из самых лёгких языков программирования для изучения с нуля. В настоящее время наиболее популярен в машинном обучении. Также на питоне можно делать скрипты, боты и полноценные веб-приложения.
🎓 Бесплатные курсы
1. "Поколение Python": курс для начинающих — самый популярный курс по Питону с нуля на Stepik
2. "Поколение Python": курс для продвинутых — курс для тех, кто прошёл предыдущий или у кого уже есть базовые знания по программированию
3. Программирование на Python — второй по популярности курс по Питону с нуля на Stepik
4. Python: основы и применение — продолжение предыдущего курса, а также для тех, кто имеет базовые навыки Питона
5. pythontutor.ru — интерактивный самоучитель, много задач, которые можно проверять автоматически и смотреть решения других людей
6. Python в примерах и задачах — курс от Дальневосточного федерального университета
7. Видеокурс от Школы бэкенд-разработки Яндекса — для продвинутых, поможет научиться промышленной разработке на Python
8. Тренажер по Python от Каталог-курсов.ру
9. Автоматизация тестирования с помощью Selenium и Python
1. Питон за час
2. Python-джедай (продолжение Питон за час)
3. Плейлист Python для начинающих
4. МФТИ, цикл лекций курса «Практики программирования»
5. Python программирование — плейлист для новичков
6. Язык программирования PYTHON для начинающих — 88 видео
7. Асинхронность в Python — плейлист для продвинутых
8. Разработка Telegram Ботов на Python с нуля
📚 Книги
(ссылки ведут на pdf)
1. Эрик Мэтиз. Изучаем Python: программирование игр, визуализация данных, веб-приложения
2. Пол Бэрри. Изучаем программирование на Python
3. Эл Свейгарт. Автоматизация рутинных задач с помощью Python
4. Марк Лутц. Python. Карманный справочник
5. Аллен Б. Дауни. Основы Python. Научитесь думать как программист
🌐 Полезные сайты
1. "Укус Питона" — "A Byte of Python" по-русски — подробный справочник по Питону с объяснениями
2. Запустить код пошагово с визуализацией
3. Визуализатор рекурсии — построить наглядное дерево вызовов
4. Простейший самоучитель по Python — можно использовать в качестве справочника
5. Репозиторий 30-Days-Of-Python (англ)
6. Freecodecamp — интерактивный учебник по Python (русского нет, зато есть украинский)
7. Онлайн-тренажёр «Прогноз погоды на Python» — интерактив от Яндекса по созданию программы, которая показывает температуру в любом городе мира
8. Адаптивный тренажер Python — несколько десятков разнообразных задач на Python разных уровней сложности
9. Тренажер “Codechick” — сборник практических заданий по Python, отсортированных по уровню сложности
Django
1. Курс видео по Django от EngineerSpock
2. Django 3 для python (уроки)
3. Создание сайта на Django
4. Django Web Development with Python (на русском)
💻 IDE
1. PyCharm: Windows / Linux / Mac
2. Spider
3. Непосредственно Python
📎 Ещё подборки и ссылки
1. Обучающие материалы по питону (roadmap) — огромная подборка материалов от корки до корки
2. 15+ небанальных ресурсов для начинающего/продолжающего Python-разработчика
3. 16 лучших сайтов уроков и заданий по Python в 2023 года
4. 144 книги по Python — можно скачать бесплатно
5. Бесплатные книги по Питону на все темы
#подборка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍18😱4❤2👏1💩1