Шаблоны проектирования — это многоразовые решения распространенных проблем, которые можно применять на разных языках и платформах.
Они делятся на три категории:
🟢 Порождающие паттерны (𝗖𝗿𝗲𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): гибко управляют созданием объектов
🟣 Структурные паттерны (𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): организуют объекты в более крупные структуры
🟡 Поведенческие паттерны (𝗕𝗲𝗵𝗮𝘃𝗶𝗼𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): управляют тем, как объекты взаимодействуют друг с другом.

Наиболее распространенные 7 шаблонов:
𝟭. 𝗦𝗶𝗻𝗴𝗹𝗲𝘁𝗼𝗻 - Гарантирует существование только одного экземпляра
𝟮. 𝗕𝘂𝗶𝗹𝗱𝗲𝗿 - Строит сложные объекты шаг за шагом
𝟯. 𝗙𝗮𝗰𝘁𝗼𝗿𝘆 - Создает объекты без указания точного класса
𝟰. 𝗙𝗮𝗰𝗮𝗱𝗲 - Упрощает сложные системы с помощью понятного, унифицированного интерфейса
𝟱. 𝗔𝗱𝗮𝗽𝘁𝗲𝗿 - Заставляет несовместимые интерфейсы работать вместе
𝟲. 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 - Динамически меняет алгоритмы
𝟳. 𝗢𝗯𝘀𝗲𝗿𝘃𝗲𝗿 - Для поддержания зависимостей между объектами

Сегодня столкнулся на одном сайте. С первой попытке отгадать, на каких картинках находится "undefined", не удалось

Робособачки и deep learning

Наиболее распростраенные архитектурные паттерны

𝟭. Слоистая урхитектура : Разделяет приложения на логические слои (Presentation, Business, Data) с определенными обязанностями. Способствует разделению ответственности между различными частями приложения и упрощает поддержку и развитие приложения

𝟮. Микросервисы: Разбивает приложения на небольшие независимые сервисы, взаимодействующие через API. Каждый реализует одну бизнес-возможность и может быть развернут независимо от других сервисов, обеспечивая автономность и непрерывную доставку

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

𝟰. 𝗦𝗽𝗮𝗰𝗲-𝗯𝗮𝘀𝗲𝗱: Использует независимые "пространства" как автономные единицы на нескольких серверах. Устраняет отдельные точки отказа в системах с большим объемом данных и преодолевает узкие места в данных и сетевые задержки

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

𝟲. 𝗖𝗤𝗥𝗦 (𝗖𝗼𝗺𝗺𝗮𝗻𝗱-𝗤𝘂𝗲𝗿𝘆 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗦𝗲𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻): Разделяет операции чтения и записи на отдельные модели. Улучшает производительность и масштабируемость в сложных доменах за счет независимой оптимизации каждого пути.

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

(Наглядная иллюстрация к предыдущему посту)

Undefined behavior

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

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

Cache Hit Ratio (%) = (Cache Hits / Total Lookups) x 100
Где
Cache Hit Ratio - Коэффициент попаданий в кэш (%),
Cache Hits - Число попаданий в кэш
Total Lookups - Общее количество поисков

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

Для контекста рассмотрим простой пример:
• Ваш сервис получает 10 запросов
• Первый запрос запрашивает кэш, ничего не находит (промах кэша / cache miss), запрашивает базу данных, а затем сохраняет результат в кэше.
• Следующие 9 запросов попадают в кэш и обслуживаются немедленно (попадаение в кэш/cache hit).

В этом сценарии у вас будет 9 попаданий в кэш из 10 общих поисков, что дает коэффициент попадания в кэш 90%.

Хотя универсальной цифры не существует, общее руководство следующее:
• Кэширование запросов к базе данных: 85-95%
• Кэширование ответов API: 95-99%
• Крупномасштабные CDN: 99%+

3 способа увеличить коэффициент попадания в кэш
• Предварительно загружайте наиболее запрашиваемые данные в кэша во время развертывания приложения или холодного запуска, чтобы избежать первоначального сильного роста промахов кэша.
• Настройте значение времени жизни (TTL). Если оно слишком короткое, элементы быстро устаревают, что приводит к пропускам. Если слишком большое, вы рискуете предоставить устаревшие данные.
• Убедитесь, что ключи уникальны, но предсказуемы, чтобы предотвратить пропуски записей в кэше.

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

(Наглядная иллюстрация к предыдущему посту)

Наглядно как происходит рабочий процесс в Git

Обновлено руководство по React до версии React 19
https://metanit.com/web/react/1.1.php
#react #reactjs

Тестирование API вносит значительный вклад в обеспечение надежности, безопасности, функциональности и эффективности приложений. Рассмотрим 6 базовых типов тестирования API:

🔹 Тестирование рабочего процесса (Workflow Testing)
Проверяет, правильно ли работает последовательность вызовов API для завершения определенного процесса.
Часто такие тесты рабочего процесса связаны с какой-либо бизнес-целью, например, с совершением покупки на платформе электронной коммерции.

🔹 Тестирование производительности (Performance Testing)
Оценивает скорость, отзывчивость и стабильность API в различных условиях, чтобы убедиться, что он соответствует контрольным показателям и ожиданиям пользователей
И также оценивает такие ключевые факторы, как скорость обработки, использование памяти, нагрузка на соединение, время отклика и пропускная способность сети, чтобы выявить потенциальные узкие места
Цель состоит в том, чтобы убедиться, что система выдает ожидаемые ответы в разумные сроки, даже при различной нагрузке

🔹 Тестирование безопасности (Security Testing)
Выявляет уязвимости, которые потенциально могут привести к несанкционированному доступу или утечке данных
Включает в себя строгие проверки, чтобы гарантировать, что меры безопасности достаточно надежны, чтобы предотвратить атаки и утечки данных.
Использует тестирование на проникновение (pentest) и нечеткое тестирование для выявления уязвимостей

🔹 Тестирование на основе данных (Data-driven Testing)
Передает различные наборы и типы входных данных в API, чтобы гарантировать его корректную работу в различных сценариях.
Использует таблицы входных данных, сопоставленных с ожидаемыми выходными данными, прогон этих входных данных через систему и проверку соответствия фактических выходные данные ожидаемым результатам

🔹 Тестирование конечной точки (Endpoint Testing)
Проверяет, правильно ли отдельные конечные точки API реагируют на запросы и возвращают ли ожидаемый ответ, данные, коды состояния и сообщения об ошибках

🔹 Тестирование контракта (Contract Testing)
Проверяет, что взаимодействие между поставщиком API и потребителем соответствует предопределенному соглашению/контракту, включая ожидаемые структуры запросов, форматы ответов и типы данных.
Его основная задача — гарантировать, что поставщик API не вносит критических изменений, которые могут повлиять на потребителей, использующих API.

(Иллюстрация к предыдущему посту)

Популярность языков программирования с 1965 по 2022 гг. (Популярность в данном случае определяется как процент разработчиков, которые активно используют или изучают его. Не знаю, откуда они взяли эти данные, может от фонаря, но тем не менее.)