Михаил Омельченко | AI&IT
5.28K subscribers
976 photos
192 videos
4 files
713 links
ИИ в работе, разработка, веб. Агенты, автоматизация, инструменты. Веду я, Михаил Омельченко, внешний технический директор по ИИ и ментор.

Менторство, реклама и сотрудничество: djwoms.ru
Telegram - @DJWOMS
YouTube - https://www.youtube.com/c/DjangoSchool
Download Telegram
🤔 Что такое Server Sent Events (SSE)?

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

💡 Как это работает?

Клиент отправляет HTTP-запрос на сервер.
Сервер отвечает специальным заголовком Content-Type: text/event-stream, что указывает на то, что это поток событий.

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

🚀 Чем это полезно?

Server Sent Events идеально подходят для сценариев, где вам нужно передавать обновления, такие как новости, уведомления или данные в онлайн-играх. SSE также менее сложны в настройке по сравнению с WebSocket, и могут быть использованы совместно с другими технологиями.

👩‍💻 Как это реализовать?

На стороне сервера, вы можете использовать множество языков программирования, включая Python, Node.js, и другие, чтобы отправлять данные в формате SSE. На стороне клиента, вы можете использовать JavaScript для прослушивания и обработки событий.

Server Sent Events - это мощный инструмент для веб-разработчиков.

#djangoschool #sse
🔥10👍5
😎 А у вас какая погода?
❤12🔥4
Сижу в кафе с пустой тарелкой.

А чего добился ты?


😜 Местная шутка.
😁4
This media is not supported in your browser
VIEW IN TELEGRAM
Кто-то кормит голубей, а кто-то чаек 😁
😁4
🚢🔗 Анти-паттерн "Лодочный якорь (Boat anchor)"

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

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

Основная причина возникновения анти-паттерна "Лодочный якорь" - это необдуманное добавление новой функциональности без оценки ее потенциальной ценности и необходимости. Часто это происходит из-за срочности задачи или желания удовлетворить запросы пользователя.

Как избежать "Лодочного якоря":

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

2️⃣ Удаление неиспользуемого кода: периодически ревьюируйте код и удаляйте ненужные функции и модули. Это поможет упростить кодовую базу и уменьшить сложность проекта.

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

4️⃣ Обучение и самообразование: развивайтесь в IT, изучайте новые технологии и подходы. Это поможет более точно оценивать ценность функциональности и избегать "Лодочного якоря".

Итак, помните, что "Лодочный якорь" - это анти-паттерн, который может затормозить разработку и усложнить поддержку проекта. Будьте внимательны при добавлении новой функциональности и удаляйте неиспользуемый код. Так вы сможете создавать более эффективные и легко поддерживаемые системы.

Если у вас есть какие-либо вопросы или опыт по борьбе с "Лодочным якорем", делитесь им в комментариях.

#djangoschool #pattern
👍6
Луковая Архитектура

Привет! Начинаю серию постов об архитектуре.
Сегодня поговорим о луковой архитектуре (Onion или Hexagonal).

🤔 Что такое Луковая Архитектура?

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

😎 Слоистая Архитектура

Мы разбиваем код на несколько слоев:

✅ Domain layer (Слой Домена): Это место, где живет бизнес-логика приложения. Здесь определяются все правила и операции, с которыми работает бизнес. Остальные слои предназначены для того, чтобы защитить бизнес-логику от внешних воздействий.

✅ Application layer (Слой Приложения): Этот слой связывает доменную модель с инфраструктурными службами. Здесь находятся классы, которые обрабатывают запросы и команды, связанные с бизнес-логикой.

✅ Infrastructure layer (Инфраструктурный слой): Этот слой содержит всю инфраструктуру, необходимую для взаимодействия приложения с внешним миром. Это файловая система, сеть, базы данных, фреймворки и так далее. Важно помнить, что здесь не должно быть никакой бизнес-логики.

🧐 Что это дает нам?

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

Зачем это нужно?

Это важно для разработчиков, так как помогает создавать более надежные и масштабируемые приложения. Ваши изменения в бизнес-логике не должны влиять на код инфраструктуры, и наоборот.

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

#djangoschool #IT #Архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥2❤1🥰1
(DDD) Domain-driven design (Предметно-ориентированное проектирование) — это набор принципов и схем, направленных на создание оптимальных систем объектов.

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

Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией.

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

#djangoschool #ddd
👍12
Стратегическое проектирование

Проектирование на высоком уровне абстракции, без технических нюансов, осуществляемое всей командой - как менеджерами/заказчиками, так и техническими специалистами.

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

Для реализации этого требуется объединение усилий как разработчиков, так и экспертов в предметной области. Создание дружной и сплоченной команды позволяет получить большое количество преимуществ для бизнеса. Обмен знаниями между членами команды снижает шансы появления «тайного знания» о модели, достигается консенсус между экспертами предметной области в отношении различных понятий и терминологии, разрабатывается более точное определение и описание самого бизнеса.

Ubiquitous Language (Единый язык)

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

Этот коллективный язык терминов называется - единый язык (Ubiquitous Language).
Это один из основных и самых важных шаблонов предметного-ориентированного проектирования.

Это не бизнес жаргон, навязанный разработчикам, а настоящий язык, созданный целостной командой – экспертами в предметной области, разработчиками, бизнес-аналитиками и всеми, кто вовлечен в создание системы. Роль в команде не столь существенна, поскольку каждый член команды использует для описания проекта единый язык.

#djangoschool #ddd
👍4
Михаил Омельченко | AI&IT
Стратегическое проектирование Проектирование на высоком уровне абстракции, без технических нюансов, осуществляемое всей командой - как менеджерами/заказчиками, так и техническими специалистами. Основной целью применения DDD является получение высококачественной…
Выводы:

1. Стратегическое проектирование включает высокоуровневое проектирование на абстрактном уровне, с участием всей команды.

2. Основная цель DDD - создание высококачественной модели ПО, отражающей бизнес-цели.

3. Единый язык (Ubiquitous Language) - это коллективный набор терминов, понятий и фраз, используемых всей командой для общения и в исходном коде программы.

4. Единый язык помогает выровнять знания и облегчает обмен полезной информацией о предметной области.

5. Единый язык создается командой, включая экспертов предметной области и разработчиков, полноценный язык общения всей команды.

Общайтесь с заказчиком, погружайтесь в тему бизнеса. Без этого будет сложно.

#djangoschool #ddd
👍3🔥3
Bounded Context (Ограниченный контекст)

Существует некая граница, в пределах которой понятия единого языка имеют вполне конкретное контекстное значение - ограниченный контекст (Bounded context).

Это второе по значимости свойство DDD после единого языка. Оба эти понятия взаимосвязаны и не могут существовать друг без друга.

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

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

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

#djangoschool #ddd
👍3
Предметная область (Domain)

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

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

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

#djangoschool #ddd
👍5