Библиотека программиста | программирование, кодинг, разработка
84.4K subscribers
3.13K photos
147 videos
88 files
6.35K links
Все самое полезное для программиста в одном канале.

Список наших каналов: https://tttttt.me/proglibrary/9197
Учиться у нас: https://proglib.io/w/a32a0d94

Обратная связь: @proglibrary_feedback_bot

По рекламе: @proglib_adv
Прайс: @proglib_advertising
Download Telegram
🛠 Сага: эффективный шаблон микросервисной архитектуры

Полную бизнес-транзакцию, как правило, очень сложно описать с помощью одной транзакции в базе данных. Возьмем, к примеру, процесс покупки в онлайн-магазине — с момента нажатия кнопки «Купить» до момента доставки заказа к вашей двери происходит серия шагов:

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

Каждый из этих шагов включает взаимодействие с различными микросервисами — сервисов заказов, платежным сервисом и сервисом доставки. Для успешного и последовательного выполнения бизнес-транзакции важна безупречная координация всех частей системы. Эта задача кажется очень сложной, но к счастью, есть универсальный и надежный паттерн, который помогает выстроить взаимодействие микросервисов самым оптимальным образом — Сага. О нем и пойдет речь в статье.
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 приемов для создания надежного кода

От рекурсивных псевдонимов типов до дискриминированных объединений — эти приемы помогут вам писать более эффективный и безопасный код. Здесь разберем основные моменты, а полностью читайте в статье:

☑️ Интерполяция строковых литералов: позволяет динамически создавать новые типы строковых литералов на основе существующих типов.
☑️ Брендирование: позволяет создавать уникальные идентификаторы для предотвращения смешивания типов, даже если они принадлежат к одному и тому же типу данных.
☑️ Условные типы: позволяют извлекать информацию о типах из сложных структур с помощью ключевого слова infer.
☑️ Шаблонные литералы — комбинация литеральных типов и операторов для манипуляций со строками, которая позволяет создавать мощные ограничения типов на уровне строк.
☑️ Рекурсивные псевдонимы типов (алиасы): позволяют определять типы, которые ссылаются на самих себя.
☑️ Вариативные типы (TypeScript 4.0+): позволяют более гибко манипулировать кортежами.
☑️ Переименование ключей с помощью as: при работе с объектами типа ключ-значения можно использовать as для переименования ключей — это позволяет создавать производные типы с измененными именами свойств.
☑️ Константные утверждения в TypeScript: позволяют создавать более конкретные литеральные типы из массивов и объектов.
☑️ Дискриминированные объединения: позволяют создавать типы, которые могут представлять несколько различных вариантов объекта.
☑️ Фильтрация ключей по типам значений: типы ключ-значение можно комбинировать с условными — для фильтрации по типам значений.
☑️ Создание типобезопасных эмиттеров событий с помощью дженериков: типобезопасные эмиттеры событий могут существенно улучшить надежность кода, основанного на событиях.
☑️ Самоссылающиеся типы: позволяют создавать сложные, вложенные структуры данных, сохраняя при этом типобезопасность.
☑️ Непрозрачные типы с использованием unique symbol: позволяют создавать типы, которые структурно похожи, но рассматриваются типовой системой как разные.
☑️ Последовательности целых чисел на уровне типов: подход, который позволяет создавать более точные типы для операций с массивами, обеспечивая проверку длины массива на этапе компиляции.
☑️ Типобезопасный DeepPartial с использованием рекурсивных условных типов: позволяет работать с частичными данными сложных объектов безопасным способом.
🧑‍💻 Статьи для IT: как объяснять и распространять значимые идеи

Напоминаем, что у нас есть бесплатный курс для всех, кто хочет научиться интересно писать — о программировании и в целом.

Что: семь модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций.

Для кого: для авторов, копирайтеров и просто программистов, которые хотят научиться интересно рассказывать о своих проектах.

👉Материалы регулярно дополняются, обновляются и корректируются. А еще мы отвечаем на все учебные вопросы в комментариях курса.
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет, друзья! 👋

Мы готовим статью о будущем AI и его влиянии на разработку. Нам важно ваше мнение!

1️⃣ Как вы думаете, AI действительно изменит мир разработки? 🤖
2️⃣ Какие плюсы и минусы использования AI в разработке вы видите? 💡
3️⃣ Есть ли у вас примеры успешного применения AI в ваших проектах? 🛠️

Поделитесь своими идеями в комментариях! Самые интересные идеи и предложения мы обязательно включим в нашу статью. Спасибо за участие! 🙌
❗️Задача для конкурса в честь дня программиста

Условие:

Даны две строки 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
👨‍💻 Шпаргалка по проектированию реляционных баз данных

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

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

На иллюстрации представлены ключевые моменты, которые следует знать о проектировании реляционных баз данных.

👉 Источник

#инфографика #проектирование_систем
Привет, друзья! 👋

Готовим статью «Лучший ноутбук для программирования в 2024 году» и хотим узнать ваше мнение! 👇💻
Какой бюджет, по-вашему, оптимален для покупки ноутбука программисту в 2024 году? 💰
Anonymous Poll
7%
До 50 000 ₽
37%
50 000 — 100 000 ₽
33%
100 000 — 150 000 ₽
22%
Более 150 000 ₽
💬 Поделитесь опытом: на каком ноутбуке вы сейчас работаете и почему он вам нравится (или не нравится)? 🌟

Ждем ваши ответы в комментариях! Самые полезные советы войдут в нашу статью. 📝💡

Спасибо за участие! 🙌
😈 Осторожно — Regex! 3 эпических сбоя, вызванных регулярками

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

1️⃣ Сбой Stack Overflow

В 2016 году Stack Overflow испытал 34-минутный перебой в работе. Причиной стало регулярное выражение, используемое для обработки пользовательского ввода:

^[\s\u200c]+|[\s\u200c]+$


Это выражение должно было находить пробелы в начале и конце строки. Проблема возникла, когда какой-то пользователь запостил комментарий, содержащий около 20 000 последовательных пробелов. Механизм обработки регулярных выражений начал проверять каждый пробел. Когда после 20 000-го пробела встретился другой символ, движок начал откатываться назад, пытаясь найти соответствие, начиная со второго пробела, третьего и так далее.

Это привело к катастрофическому возврату (catastrophic backtracking) — ошибке, которая возникает, когда движок регулярных выражений тратит чрезмерное количество времени на попытки найти соответствие шаблону, перебирая различные комбинации. Количество проверок начало лавинообразно увеличиваться и быстро достигло 199 990 000 — это вызвало значительную задержку и в итоге сбой системы.

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

2️⃣ Сбой Cloudflare

2 июля 2019 года произошел крупный сбой в работе платформы Cloudflare. Один из инженеров написал регулярное выражение, которое привело к действительно катастрофическому возврату — вызвало экстремальную перегрузку всей инфраструктуры. Использование процессоров выросло до 100%, а большинство сайтов, подключенных к Cloudflare, замедлились до крайности или вовсе оказались недоступными.

Коварная регулярка выглядела так:

(?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))


Самую большую опасность в этом выражении представляет .*(?:.*=.*) — группа без захвата, которая может привести к чрезмерному использованию процессора при обработке определенных шаблонов. Эта конструкция вызвала серьезные проблемы с производительностью и в конечном итоге привела к массовому сбою.

3️⃣ Глобальный сбой Windows/CrowdStrike

19 июля 2024 года произошел самый массовый сбой в истории — из строя вышли около 8,5 млн Windows-компьютеров с ПО CrowdStrike. Причиной сбоя стало несоответствие между ожидаемым количеством входных параметров (21) и фактическим количеством параметров (20), которые были переданы в интерпретатор контента (этот компонент отвечает за обработку содержимого с использованием регулярных выражений). Когда система получила ввод с 21 параметром, интерпретатор контента попытался считать данные за пределами выделенной памяти, что и привело к сбою системы.

📨 Материал взят из нашей еженедельной email-рассылки, посвященной бэкенду. Подпишитесь, чтобы быть в числе первых, кто получит дайджест.
Please open Telegram to view this post
VIEW IN TELEGRAM
🦀 Embedded Software Engineering 101 — курс по основам разработки встроенного ПО, начиная с основ микроконтроллеров и постепенно переходя к более сложным встроенным системам.

👉 Пройти курс