Начато добавление материалов про созданию графических приложений на Vulkan на языке программирования С++
https://metanit.com/cpp/vulkan/1.1.php
#cpp

Шпаргалка по сегментации памяти

Краткая шпаргалка по наиболее распространенным командам в Linux #linux

Наглядно процесс разрешения DNS

Вышла новая версия Ubuntu - 25.04 "Plucky Puffin" (перевод - Отважный Тупик) на базе ядра Linux 6.14 и рабочего окружения GNOME 48.
Эта версия является промежуточной (не LTS) и будет поддерживаться до января 2026 года.
В новой версии разработчики найдут новые версии технологий и языков прогарммирования - GCC 15 (снапшот будущего релиза), LLVM 20, Python 3.13.3, Go 1.24, Rust 1.84,.NET 9.0, PHP 8.4, Ruby 3.3, OpenJDK 24, PostgreSQL 17, Valkey (форк Redis) 8.0.2, MySQL 8.4.4, Qt 6.8.3
Ряд других изменений:
ядро Linux обновлено до выпуска 6.14;
рабочий стол обновлён до выпуска GNOME 48
обновлены приложения: GIMP 3.0, LibreOffice 25.2, Firefox 137, Thunderbird 128;
обновлены серверные пакеты: Nginx 1.26.3, Apache httpd 2.4.63, OpenSSH 9.9, cloud‑init 25.1.1, Docker 27.5.1, Containerd 2.0.2, libvirt 10.10.0, ClamAV 1.4.2, OpenLDAP 2.6, QEMU 9.2.0 и т.д;
задействован пакетный менеджер APT 3.0;

Все изменения и дополнительная информация по релизу https://discourse.ubuntu.com/t/plucky-puffin-release-notes/48687

Искусственный интеллект способен заменить половину чиновников, считает глава Минцифры РФ Максут Шадаев. При этом он уточнил, что человека, особенно врачей и учителей, нейросети все же не заменят. Это заявление Шадаев сделал в ходе профильного мероприятия First Russian Data Forum.
«Человека, надеемся, он не заменит, особенно врачей и учителей. Считаю, что половину чиновников точно может заменить. Может, чуть больше», — пояснил Шадаев.
https://tass.ru/ekonomika/23708211

Процесс работы архитектуры микросервисов:

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

🔹 CDN + Статический контент: быстрее доставляет статические ресурсы, такие как HTML, CSS и JS, кэшируя их ближе к пользователям.

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

🔹 API-шлюз (API Gateway): действует как центральная точка входа, обеспечивая маршрутизацию, аутентификацию и ограничение скорости клиентских запросов.

🔹 Поставщик удостоверений (Identity Provider): аутентифицирует пользователей и выдает защищенные токены (например, OAuth или JWT) для управления доступом.

🔹 Микросервисы: Независимые сервисы, каждый из которых обрабатывает отдельную бизнес-функцию, организованную по домену. Их можно создавать, масштабировать и развертывать независимо.

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

🔹 Координация сервисов: поддерживает синхронизацию между сервисами и управляет распределенными конфигурациями (такие инструменты, как Zookeeper).

🔹 Брокер сообщений: обеспечивает асинхронную связь между сервисами с использованием очередей, таких как Kafka или RabbitMQ, — идеально подходит для разделения рабочих процессов.

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

Анимация к предыдущему посту

Как работают почтовые протоколы

Компании «Группа Астра», Axiom JDK и Haulmont представили OpenIDE — новую среду разработки с открытым исходным кодом. Решение ориентировано на госсектор и крупный бизнес. Для вывода платформы на рынок учредили совместную компанию — ООО «Открытая среда разработки».
Платформа основана на IntelliJ IDEA Community Edition. Первая версия сейчас находится на финальной стадии бета‑тестирования. В состав OpenIDE входит Axiom JDK — российская реализация JDK, доступная для промышленного использования. Также в решение добавлен бесплатный плагин Amplicode от Haulmont, предоставляющий базовую поддержку Spring. «Группа Астра» планирует добавить в OpenIDE интеграцию с платформой GitFlic.
В платформе нет проприетарных компонентов, а сервера с дистрибутивами и исходным кодом, как и команда, которая занимается ее сборкой, развитием и сопровождением, находятся в России. Также планируется добавить в платформу открытый маркетплейс, где будет поддержка российских плагинов.
https://astra.ru/about/press-center/news/openide-novaya-otechestvennaya-sreda-razrabotki-dlya-nadezhnykh-i-bezopasnykh-it-proektov/

Семантическое управление версиями (SemVer) — это схема управления версиями программного обеспечения, цель которой — передать смысл основных изменений в выпуске.

🔹 SemVer использует трехкомпонентный номер версии: MAJOR.MINOR.PATCH.

- Старшая версия (MAJOR): увеличивается при наличии несовместимых изменений API.
- Младшая версия (MINOR): увеличивается при добавлении функциональности с сохранением обратной совместимости.
- Версия патчей (PATCH): увеличивается при внесении обратно совместимых исправлений ошибок.

🔹 Пример рабочего процесса
1 — Начальная фаза разработки
Начинаем с версии 0.1.0.

2 - Первый стабильный релиз
Выпуск стабильной версии: 1.0.0.

3 - Последующие изменения
Выпуск патча: Требуется исправление ошибки для 1.0.0. Обновите до 1.0.1.
Второстепенный релиз (увеличиваем младшую версию): новая, обратно совместимая функция добавлена ​​в 1.0.3. Обновление до 1.1.0.
Основной релиз (увеличиваем старшую версию): В версии 1.2.2 введено существенное изменение, несовместимое с предыдущими версиями. Обновление до версии 2.0.0.

4 - Специальные версии и предварительные релизы
Предварительные версии: 1.0.0-alpha, 1.0.0-beta, 1.0.0-rc.1.
Метаданные сборки: 1.0.0+20130313144700.

Иллюстрация к предыдущему посту про сематическое версионирование

Краткая шпаргалка по регулярным выражениям

6 базовых архитектурных паттернов

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

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

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

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

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

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

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

Шпаргалка по наиболее распространенным размерам данных

При построении отпимальной архитектуры часто обрщают внимание на две концепции: отказоустойчивость (Failover) и репликация ( Replication). Что представляют эти две концепции?

➤ Отказоустойчивость (Failover) заключается в переключении систем/узлов, когда один из этих узлов выходит из строя. Есть два типа реализации данной концепции:

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

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


➤ Репликация (Replication) — это хранение одних и тех же данных в разных местах. Здесь распространены два типа реализации:

Одна ведущая реплика (Single-Leader): один узел пишет, остальные читают.
Плюсы: Более простая последовательность
Минусы: одно узкое место при записи, задержка при чтении реплик

Несколько ведущих реплик (Multileader): запись могут осуществлять несколько узлов.
Плюсы: Все могут писать, более высокая доступность
Минусы: конфликты данных, сложное согласование данных


Что это значит:
1. Репликация НЕ означает нулевую потерю данных.
2. Отказоустойчивость НЕ означает нулевое время простоя.
3. Не стоит выбирать шаблон на основе популярности, а стоит выбирать на основе времени восстановления, допустимой задержки и требований к согласованности.

Иллюстрация к предыдущему посту: Отказоустойчивость и репликация

Краткая история развития AI

Как работает NAT (Network Address Translation)

Иностранные компании снова активно нанимают российских IT-специалистов
По итогам 2024 года они наняли порядка 5 тыс. сотрудников, что в два раза больше, чем годом ранее. Среди наиболее активных работодателей, утверждают отечественные разработчики, китайские Huawei, Alibaba и Tencent, однако активизировались и европейские SAP, Delivery Hero и американские Amazon, OpenAI и т.д.. Спрос на российские IT-кадры вырос и со стороны ОАЭ, особенно в финтех-сегменте, а также есть рост со стороны индийских IT-аутсорсеров
Теперь иностранные компании не только напрямую нанимают сотрудников в качестве фрилансеров. Часть найма происходит через договоры оказания услуг, когда коллективы российских инженеров фактически работают над задачами зарубежных вендоров, не меняя своей юрисдикции
В Минцифры в курсе ситуации, но подчеркивают, что речь идет о частных случаях и массового характера они не носят.
https://www.kommersant.ru/doc/7675878