🛠 Сага: эффективный шаблон микросервисной архитектуры
Полную бизнес-транзакцию, как правило, очень сложно описать с помощью одной транзакции в базе данных. Возьмем, к примеру, процесс покупки в онлайн-магазине — с момента нажатия кнопки «Купить» до момента доставки заказа к вашей двери происходит серия шагов:
🔸 Размещение заказа. Пользователь выбирает нужные товары, добавляет их в корзину и начинает процесс оформления заказа. Система сохраняет информацию о видах товаров, их количестве, имени заказчика, адресе и способе доставки.
🔸 Создание счета-фактуры. После размещения заказа создается счет-фактура, который служит основной записью о транзакции и используется для выставления счета и учета.
🔸 Обработка платежа. Инициируется процесс оплаты, пользователь предоставляет данные банковской карты или электронного кошелька. Оплата безопасно обрабатывается, и после успешного завершения заказ подтверждается.
🔸 Отправка товара. После обработки платежа заказ готовится к отправке: создается информация для отслеживания, система уведомляет пользователя об ориентировочной дате доставки.
Каждый из этих шагов включает взаимодействие с различными микросервисами — сервисов заказов, платежным сервисом и сервисом доставки. Для успешного и последовательного выполнения бизнес-транзакции важна безупречная координация всех частей системы. Эта задача кажется очень сложной, но к счастью, есть универсальный и надежный паттерн, который помогает выстроить взаимодействие микросервисов самым оптимальным образом — Сага. О нем и пойдет речь в статье.
Полную бизнес-транзакцию, как правило, очень сложно описать с помощью одной транзакции в базе данных. Возьмем, к примеру, процесс покупки в онлайн-магазине — с момента нажатия кнопки «Купить» до момента доставки заказа к вашей двери происходит серия шагов:
🔸 Размещение заказа. Пользователь выбирает нужные товары, добавляет их в корзину и начинает процесс оформления заказа. Система сохраняет информацию о видах товаров, их количестве, имени заказчика, адресе и способе доставки.
🔸 Создание счета-фактуры. После размещения заказа создается счет-фактура, который служит основной записью о транзакции и используется для выставления счета и учета.
🔸 Обработка платежа. Инициируется процесс оплаты, пользователь предоставляет данные банковской карты или электронного кошелька. Оплата безопасно обрабатывается, и после успешного завершения заказ подтверждается.
🔸 Отправка товара. После обработки платежа заказ готовится к отправке: создается информация для отслеживания, система уведомляет пользователя об ориентировочной дате доставки.
Каждый из этих шагов включает взаимодействие с различными микросервисами — сервисов заказов, платежным сервисом и сервисом доставки. Для успешного и последовательного выполнения бизнес-транзакции важна безупречная координация всех частей системы. Эта задача кажется очень сложной, но к счастью, есть универсальный и надежный паттерн, который помогает выстроить взаимодействие микросервисов самым оптимальным образом — Сага. О нем и пойдет речь в статье.
Telegram представил обновление Bot API 7.10 с рядом нововведений
Telegram продолжает активно развивать свою платформу, добавляя полезные функции и улучшения.
Что там по Bot API 7.10?
Добавлен новый класс
Теперь можно указывать
А что ещё завезли?👀
Также, как все заметили добавили новый способ взаимодействия с аудиторией — звёздные розыгрыши⭐️
👉 Подробнее смотрите по ссылке
Telegram продолжает активно развивать свою платформу, добавляя полезные функции и улучшения.
Что там по Bot API 7.10?
Добавлен новый класс
PaidMediaPurchased
и поле purchased_paid_media
в классе Update
, которые позволяют отслеживать обновления о покупке платного медиа.Теперь можно указывать
payload
в sendPaidMedia
, который бот получает обратно в TransactionPartnerUser
и обновлениях о платном медиа.А что ещё завезли?
Также, как все заметили добавили новый способ взаимодействия с аудиторией — звёздные розыгрыши
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 Продвинутый TypeScript: 15 приемов для создания надежного кода
От рекурсивных псевдонимов типов до дискриминированных объединений — эти приемы помогут вам писать более эффективный и безопасный код. Здесь разберем основные моменты, а полностью читайте в статье:
☑️ Интерполяция строковых литералов: позволяет динамически создавать новые типы строковых литералов на основе существующих типов.
☑️ Брендирование: позволяет создавать уникальные идентификаторы для предотвращения смешивания типов, даже если они принадлежат к одному и тому же типу данных.
☑️ Условные типы: позволяют извлекать информацию о типах из сложных структур с помощью ключевого слова
☑️ Шаблонные литералы — комбинация литеральных типов и операторов для манипуляций со строками, которая позволяет создавать мощные ограничения типов на уровне строк.
☑️ Рекурсивные псевдонимы типов (алиасы): позволяют определять типы, которые ссылаются на самих себя.
☑️ Вариативные типы (TypeScript 4.0+): позволяют более гибко манипулировать кортежами.
☑️ Переименование ключей с помощью
☑️ Константные утверждения в TypeScript: позволяют создавать более конкретные литеральные типы из массивов и объектов.
☑️ Дискриминированные объединения: позволяют создавать типы, которые могут представлять несколько различных вариантов объекта.
☑️ Фильтрация ключей по типам значений: типы ключ-значение можно комбинировать с условными — для фильтрации по типам значений.
☑️ Создание типобезопасных эмиттеров событий с помощью дженериков: типобезопасные эмиттеры событий могут существенно улучшить надежность кода, основанного на событиях.
☑️ Самоссылающиеся типы: позволяют создавать сложные, вложенные структуры данных, сохраняя при этом типобезопасность.
☑️ Непрозрачные типы с использованием
☑️ Последовательности целых чисел на уровне типов: подход, который позволяет создавать более точные типы для операций с массивами, обеспечивая проверку длины массива на этапе компиляции.
☑️ Типобезопасный DeepPartial с использованием рекурсивных условных типов: позволяет работать с частичными данными сложных объектов безопасным способом.
От рекурсивных псевдонимов типов до дискриминированных объединений — эти приемы помогут вам писать более эффективный и безопасный код. Здесь разберем основные моменты, а полностью читайте в статье:
☑️ Интерполяция строковых литералов: позволяет динамически создавать новые типы строковых литералов на основе существующих типов.
☑️ Брендирование: позволяет создавать уникальные идентификаторы для предотвращения смешивания типов, даже если они принадлежат к одному и тому же типу данных.
☑️ Условные типы: позволяют извлекать информацию о типах из сложных структур с помощью ключевого слова
infer
.☑️ Шаблонные литералы — комбинация литеральных типов и операторов для манипуляций со строками, которая позволяет создавать мощные ограничения типов на уровне строк.
☑️ Рекурсивные псевдонимы типов (алиасы): позволяют определять типы, которые ссылаются на самих себя.
☑️ Вариативные типы (TypeScript 4.0+): позволяют более гибко манипулировать кортежами.
☑️ Переименование ключей с помощью
as
: при работе с объектами типа ключ-значения можно использовать as
для переименования ключей — это позволяет создавать производные типы с измененными именами свойств.☑️ Константные утверждения в TypeScript: позволяют создавать более конкретные литеральные типы из массивов и объектов.
☑️ Дискриминированные объединения: позволяют создавать типы, которые могут представлять несколько различных вариантов объекта.
☑️ Фильтрация ключей по типам значений: типы ключ-значение можно комбинировать с условными — для фильтрации по типам значений.
☑️ Создание типобезопасных эмиттеров событий с помощью дженериков: типобезопасные эмиттеры событий могут существенно улучшить надежность кода, основанного на событиях.
☑️ Самоссылающиеся типы: позволяют создавать сложные, вложенные структуры данных, сохраняя при этом типобезопасность.
☑️ Непрозрачные типы с использованием
unique symbol
: позволяют создавать типы, которые структурно похожи, но рассматриваются типовой системой как разные. ☑️ Последовательности целых чисел на уровне типов: подход, который позволяет создавать более точные типы для операций с массивами, обеспечивая проверку длины массива на этапе компиляции.
☑️ Типобезопасный DeepPartial с использованием рекурсивных условных типов: позволяет работать с частичными данными сложных объектов безопасным способом.
🧑💻 Статьи для IT: как объяснять и распространять значимые идеи
Напоминаем, что у нас есть бесплатный курс для всех, кто хочет научиться интересно писать — о программировании и в целом.
Что: семь модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций.
Для кого: для авторов, копирайтеров и просто программистов, которые хотят научиться интересно рассказывать о своих проектах.
👉Материалы регулярно дополняются, обновляются и корректируются. А еще мы отвечаем на все учебные вопросы в комментариях курса.
Напоминаем, что у нас есть бесплатный курс для всех, кто хочет научиться интересно писать — о программировании и в целом.
Что: семь модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций.
Для кого: для авторов, копирайтеров и просто программистов, которые хотят научиться интересно рассказывать о своих проектах.
👉Материалы регулярно дополняются, обновляются и корректируются. А еще мы отвечаем на все учебные вопросы в комментариях курса.
📱Пользователи из России больше не могут скачивать плагины в Android Studio из-за экспортных ограничений
💻 Исследование: ПК с Windows 11 может показывать разную производительность без явной причины
🔐 За первое полугодие 2024 года в России утекло в сеть 986 млн строк персональных данных пользователей
📹 Runet: YouTube начал вводить технические меры против переноса контента на российские видеохостинги
Какие новости пропустили? Расскажите в комментариях.
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет, друзья! 👋
Мы готовим статью о будущем AI и его влиянии на разработку. Нам важно ваше мнение! ✨
1️⃣ Как вы думаете, AI действительно изменит мир разработки? 🤖
2️⃣ Какие плюсы и минусы использования AI в разработке вы видите? 💡
3️⃣ Есть ли у вас примеры успешного применения AI в ваших проектах? 🛠️
Поделитесь своими идеями в комментариях! Самые интересные идеи и предложения мы обязательно включим в нашу статью. Спасибо за участие! 🙌
Мы готовим статью о будущем AI и его влиянии на разработку. Нам важно ваше мнение! ✨
1️⃣ Как вы думаете, AI действительно изменит мир разработки? 🤖
2️⃣ Какие плюсы и минусы использования AI в разработке вы видите? 💡
3️⃣ Есть ли у вас примеры успешного применения AI в ваших проектах? 🛠️
Поделитесь своими идеями в комментариях! Самые интересные идеи и предложения мы обязательно включим в нашу статью. Спасибо за участие! 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Условие:
Даны две строки s и f (начальная и конечная) и словарь D (набор слов).
Нужно определить, можно ли преобразовать s в f, используя только слова из словаря D. При этом каждое преобразование должно менять только один символ, а длина слова должна оставаться неизменной. Если преобразование возможно, нужно найти кратчайшую последовательность таких преобразований и вернуть ее длину. Если преобразование невозможно, вернуть "Преобразование невозможно".
Пример ввода 1:
D = ["cat", "cot", "dot", "dog", "bat", "dag"]
s = "cat"
t = "dog"
Вывод:
Минимальное количество шагов для преобразования 'cat' в 'dog': 3
Пример ввода 2:
D = ["cat", "cot", "bat"]
s = "cat"
t = "dog"
Вывод:
Минимальное количество шагов для преобразования 'cat' в 'dog': Преобразование невозможно
Please open Telegram to view this post
VIEW IN TELEGRAM
👨💻 Шпаргалка по проектированию реляционных баз данных
Реляционная база данных — это составленная по реляционной модели база данных, в которой данные, занесенные в таблицы, имеют изначально заданные отношения.
Сами таблицы в такой базе данных также соотносятся друг с другом строго определенным образом. Реляционные базы данных используют целый комплекс инструментов, которые обеспечивают целостность данных, т. е. их точность, полноту и единообразие.
На иллюстрации представлены ключевые моменты, которые следует знать о проектировании реляционных баз данных.
👉 Источник
#инфографика #проектирование_систем
Реляционная база данных — это составленная по реляционной модели база данных, в которой данные, занесенные в таблицы, имеют изначально заданные отношения.
Сами таблицы в такой базе данных также соотносятся друг с другом строго определенным образом. Реляционные базы данных используют целый комплекс инструментов, которые обеспечивают целостность данных, т. е. их точность, полноту и единообразие.
На иллюстрации представлены ключевые моменты, которые следует знать о проектировании реляционных баз данных.
👉 Источник
#инфографика #проектирование_систем
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет, друзья! 👋
Готовим статью «Лучший ноутбук для программирования в 2024 году» и хотим узнать ваше мнение! 👇💻✨
Готовим статью «Лучший ноутбук для программирования в 2024 году» и хотим узнать ваше мнение! 👇💻✨
Какие 3 характеристики ноутбука вы считаете критически важными для программирования? 🤔
Anonymous Poll
75%
Процессор
79%
Оперативная память
24%
NVME-накопитель
41%
Качество экрана
31%
Автономность
20%
Клавиатура
18%
Система охлаждения
2%
Другое (напишите в комментариях)
Какой бюджет, по-вашему, оптимален для покупки ноутбука программисту в 2024 году? 💰
Anonymous Poll
7%
До 50 000 ₽
37%
50 000 — 100 000 ₽
33%
100 000 — 150 000 ₽
22%
Более 150 000 ₽
💬 Поделитесь опытом: на каком ноутбуке вы сейчас работаете и почему он вам нравится (или не нравится)? 🌟
Ждем ваши ответы в комментариях! Самые полезные советы войдут в нашу статью. 📝💡
Спасибо за участие! 🙌
Ждем ваши ответы в комментариях! Самые полезные советы войдут в нашу статью. 📝💡
Спасибо за участие! 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
😈 Осторожно — Regex! 3 эпических сбоя, вызванных регулярками
Регулярные выражения — мощный, гибкий и многофункциональный инструмент для обработки текста и валидации данных. С их помощью можно решать сложные задачи буквально одной строкой кода. Однако неправильно составленное регулярное выражение может превратиться в настоящую бомбу замедленного действия, готовую взорваться при определенных входных данных. Последствия могут быть сложноустранимыми, а иногда катастрофическими — как в этих реальных кейсах.
1️⃣ Сбой Stack Overflow
В 2016 году Stack Overflow испытал 34-минутный перебой в работе. Причиной стало регулярное выражение, используемое для обработки пользовательского ввода:
Это выражение должно было находить пробелы в начале и конце строки. Проблема возникла, когда какой-то пользователь запостил комментарий, содержащий около 20 000 последовательных пробелов. Механизм обработки регулярных выражений начал проверять каждый пробел. Когда после 20 000-го пробела встретился другой символ, движок начал откатываться назад, пытаясь найти соответствие, начиная со второго пробела, третьего и так далее.
Это привело к катастрофическому возврату (catastrophic backtracking) — ошибке, которая возникает, когда движок регулярных выражений тратит чрезмерное количество времени на попытки найти соответствие шаблону, перебирая различные комбинации. Количество проверок начало лавинообразно увеличиваться и быстро достигло 199 990 000 — это вызвало значительную задержку и в итоге сбой системы.
Для решения проблемы потребовалось 10 минут на обнаружение причины, 14 минут на написание исправления и еще 10 минут на развертывание решения. В результате регулярное выражение было заменено на функцию подстроки.
2️⃣ Сбой Cloudflare
2 июля 2019 года произошел крупный сбой в работе платформы Cloudflare. Один из инженеров написал регулярное выражение, которое привело к действительно катастрофическому возврату — вызвало экстремальную перегрузку всей инфраструктуры. Использование процессоров выросло до 100%, а большинство сайтов, подключенных к Cloudflare, замедлились до крайности или вовсе оказались недоступными.
Коварная регулярка выглядела так:
Самую большую опасность в этом выражении представляет .*(?:.*=.*) — группа без захвата, которая может привести к чрезмерному использованию процессора при обработке определенных шаблонов. Эта конструкция вызвала серьезные проблемы с производительностью и в конечном итоге привела к массовому сбою.
3️⃣ Глобальный сбой Windows/CrowdStrike
19 июля 2024 года произошел самый массовый сбой в истории — из строя вышли около 8,5 млн Windows-компьютеров с ПО CrowdStrike. Причиной сбоя стало несоответствие между ожидаемым количеством входных параметров (21) и фактическим количеством параметров (20), которые были переданы в интерпретатор контента (этот компонент отвечает за обработку содержимого с использованием регулярных выражений). Когда система получила ввод с 21 параметром, интерпретатор контента попытался считать данные за пределами выделенной памяти, что и привело к сбою системы.
📨 Материал взят из нашей еженедельной email-рассылки, посвященной бэкенду. Подпишитесь, чтобы быть в числе первых, кто получит дайджест.
Регулярные выражения — мощный, гибкий и многофункциональный инструмент для обработки текста и валидации данных. С их помощью можно решать сложные задачи буквально одной строкой кода. Однако неправильно составленное регулярное выражение может превратиться в настоящую бомбу замедленного действия, готовую взорваться при определенных входных данных. Последствия могут быть сложноустранимыми, а иногда катастрофическими — как в этих реальных кейсах.
В 2016 году Stack Overflow испытал 34-минутный перебой в работе. Причиной стало регулярное выражение, используемое для обработки пользовательского ввода:
^[\s\u200c]+|[\s\u200c]+$
Это выражение должно было находить пробелы в начале и конце строки. Проблема возникла, когда какой-то пользователь запостил комментарий, содержащий около 20 000 последовательных пробелов. Механизм обработки регулярных выражений начал проверять каждый пробел. Когда после 20 000-го пробела встретился другой символ, движок начал откатываться назад, пытаясь найти соответствие, начиная со второго пробела, третьего и так далее.
Это привело к катастрофическому возврату (catastrophic backtracking) — ошибке, которая возникает, когда движок регулярных выражений тратит чрезмерное количество времени на попытки найти соответствие шаблону, перебирая различные комбинации. Количество проверок начало лавинообразно увеличиваться и быстро достигло 199 990 000 — это вызвало значительную задержку и в итоге сбой системы.
Для решения проблемы потребовалось 10 минут на обнаружение причины, 14 минут на написание исправления и еще 10 минут на развертывание решения. В результате регулярное выражение было заменено на функцию подстроки.
2 июля 2019 года произошел крупный сбой в работе платформы Cloudflare. Один из инженеров написал регулярное выражение, которое привело к действительно катастрофическому возврату — вызвало экстремальную перегрузку всей инфраструктуры. Использование процессоров выросло до 100%, а большинство сайтов, подключенных к Cloudflare, замедлились до крайности или вовсе оказались недоступными.
Коварная регулярка выглядела так:
(?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))
Самую большую опасность в этом выражении представляет .*(?:.*=.*) — группа без захвата, которая может привести к чрезмерному использованию процессора при обработке определенных шаблонов. Эта конструкция вызвала серьезные проблемы с производительностью и в конечном итоге привела к массовому сбою.
19 июля 2024 года произошел самый массовый сбой в истории — из строя вышли около 8,5 млн Windows-компьютеров с ПО CrowdStrike. Причиной сбоя стало несоответствие между ожидаемым количеством входных параметров (21) и фактическим количеством параметров (20), которые были переданы в интерпретатор контента (этот компонент отвечает за обработку содержимого с использованием регулярных выражений). Когда система получила ввод с 21 параметром, интерпретатор контента попытался считать данные за пределами выделенной памяти, что и привело к сбою системы.
📨 Материал взят из нашей еженедельной email-рассылки, посвященной бэкенду. Подпишитесь, чтобы быть в числе первых, кто получит дайджест.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🦀 Embedded Software Engineering 101 — курс по основам разработки встроенного ПО, начиная с основ микроконтроллеров и постепенно переходя к более сложным встроенным системам.
👉 Пройти курс
👉 Пройти курс