Шаблон повторных попыток (Retry Pattern)
(описание в следующем посте)

Шаблон повторных попыток (Retry Pattern)
(описание к предыдущему посту)

Это один из самых простых способов повысить отказоустойчивость системы. Как это работает:

1. Не выполняйте повторные попытки бесконечно
Повторные попытки имеют свою цену.

* Слишком мало попыток: вы можете сдаться при временных сбоях (например, кратковременном сетевом сбое).
* Слишком много попыток: вы перегружаете систему, увеличиваете время отклика и маскируете реальные проблемы.

Практическое правило: обычно оптимальным является 3 попытки. После этого более вероятно, что вы имеете дело с реальным сбоем, а не с временным.

2. Используйте экспоненциальную отсрочку
Время повторных попыток важнее их количества.

* Без таймата: все неудачные запросы повторяются мгновенно → увеличивается перегрузка системы.
* С экспоненциальной отсрочкой (таймаутом): время ожидания увеличивается (например, 1 с → 2 с → 4 с → 8 с), давая системам время на восстановление.

Это предотвращает превращение повторных попыток в проблему.

3. Выполняйте повторные попытки только при временных ошибках
Не каждая ошибка заслуживает повторной попытки.

* Подходящие для повтора: 408 (тайм-аут), 5xx (сервер перегружен).
* Неподходящие для повтора: 400 (неверный запрос), 403 (запрещено).

Ошибки, подлежащие повторным попыткам, носят временный характер. Ошибки, не подлежащие повторным попыткам, связаны с проблемами проектирования или данных; здесь требуется исправление, а не повторная попытка.

Если торговый автомат показывает «временно не работает», попробуйте позже. Если он говорит «вставьте 5 долларов, а не 1», повторная попытка не поможет.

4. Комбинируйте с паттерном Circuit Breaker (предохранитель)
Одни только повторные попытки могут вызвать каскадные сбои, если сервис действительно не работает. Circuit Breaker добавляет защиту:

* Отслеживает частоту сбоев.
* Открывается, когда количество сбоев превышает порог → останавливает повторные попытки на некоторое время.
* Закрывается, когда состояние улучшается.

9 базовых архитектурных паттернов интеграции систем
(описание в следующем посте)

9 базовых архитектурных паттернов интеграции систем:
(описание к предыдущему посту)

1. Peer-to-Peer (P2P)
Децентрализованная сеть, где каждый участник (пир) может быть одновременно отправителем и получателем данных. Пример: обмен файлами через BitTorrent.

2. API Gateway
Центральный компонент, который управляет входящими запросами, выполняет маршрутизацию, авторизацию, ограничение скорости и другие задачи. Пример: Spring Cloud Gateway.

3. Pub-Sub (Publish-Subscribe)
Модель обмена сообщениями, где издатели отправляют сообщения в темы, а подписчики получают их. Пример: системы уведомлений.

4. Request-Response
Классическая модель клиент-сервер, где клиент отправляет запрос, а сервер возвращает ответ. Пример: HTTP-запросы.

5. Event Sourcing
Подход, при котором система сохраняет все изменения состояния в виде последовательности событий. Пример: журнал событий для восстановления состояния системы.

6. ETL (Extract, Transform, Load)
Процесс извлечения данных из источников, их преобразования и загрузки в хранилище. Пример: миграция данных между системами.

7. Batching
Обработка данных пакетами для повышения эффективности. Пример: массовая обработка платежей.

8. Streaming Processing
Обработка потоков данных в реальном времени. Пример: анализ логов приложений.

9. Orchestration
Управление последовательностью выполнения задач между сервисами. Пример: координация микросервисов в сложной системе.

9 рекомендаций по работе с Docker, которые помогут оптимизировать работу с контейнерами
(продолжение в следующем посте)

9 рекомендаций по работе с Docker, которые помогут оптимизировать работу с контейнерами:
(продолжение предыдущего поста)

1. Используйте официальные образы
Использование официальных образов Docker обеспечивает безопасность, надежность и регулярные обновления. Пример: FROM node:14-alpine.

2. Используйте конкретные версии
Указание конкретной версии образа предотвращает неожиданные изменения. Пример: FROM node:14.17.0-alpine3.13.

3. Многоступенчатые сборки
Многоступенчатые сборки уменьшают размер финального образа, исключая инструменты сборки и зависимости. Пример:

   FROM build-image AS build  
   # Build steps  
   FROM production-image  
   COPY --from=build /app /app  
   

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

  
   node_modules  
   npm-debug.log  
   

5. Наименьшие привилегии
Запуск приложений с правами непривилегированного пользователя повышает безопасность. Пример:

   RUN useradd -m myuser  
   USER myuser  
   CMD node index.js  
   

6. Используйте переменные окружения
Использование переменных окружения увеличивает переносимость приложения между средами. Пример:

   ENV APP_HOME /app  
   WORKDIR $APP_HOME  
   

7. Порядок инструкций важен для кэширования
Порядок инструкций в Dockerfile влияет на эффективность кэширования. Рекомендуется начинать с менее изменяемых команд. Пример:

   FROM debian  
   RUN apt-get update  
   RUN apt-get -y install openjdk ssh vim  
   COPY . /app  
   CMD ["java", "-jar", "/app/target/app.jar"]  
   

8. Имена для образов
Назначение имен для образов помогают организовать и управлять образами. Пример:

   LABEL maintainer="name@example.com"  
   LABEL version="1.0"  
   

9. Сканирование образов
Проверка образов на уязвимости с помощью команды docker scan помогает предотвратить проблемы безопасности.

#docker

Линус Торвальдс поясняет Биллу Гейтсу, что значит "Vibe" в словосочетании "Vibe Coding"
(Very Inefficient But Entertaining - Очень неэффективно, но занимательно)

Нейросети позволяют программистам работать быстрее, но при этом пишут в 3-4 раза больше кода и создают в 10 раз больше проблем безопасности

Компания Apiiro, занимающаяся безопасностью приложений, сообщает, что проанализировала код из десятков тысяч репозиториев и код нескольких тысяч разработчиков, связанных с предприятиями из списка Fortune 50, чтобы лучше понять влияние помощников ИИ-разработчиков кода, таких как Claude Code от Anthropic, GPT-5 от OpenAI и Gemini 2.5 Pro от Google.

Компания обнаружила, что разработчики, использующие ИИ, создают в 3-4 раза больше кода, чем их коллеги, работающие без него, но при этом создают в 10 раз больше проблем безопасности.

По состоянию на июнь 2025 года код, сгенерированный ИИ, ежемесячно вносил более 10 000 новых «проблем безопасности» в набор данных репозитория Apiiro, что в 10 раз больше, чем в декабре 2024 года, сообщает компания.

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

Помощники ИИ-кода не совсем бесполезны. Они сократили количество синтаксических ошибок на 76%, а логических — на 60%, но за счёт более серьёзных потерь — на 322% увеличилось количество путей повышения привилегий и на 153% увеличилось количество архитектурных недостатков. Другими словами, ИИ исправляет опечатки, но создаёт бомбы замедленного действия

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

Выводы компании перекликаются с результатами других исследователей. Например, в мае 2025 года учёные из Университета Сан-Франциско, Института искусственного интеллекта Vector (Канада) и Массачусетского университета в Бостоне определили, что итеративное улучшение образцов кода с помощью моделей ИИ снижает безопасность.

https://www.theregister.com/2025/09/05/ai_code_assistants_security_problems/

Минцифры составило список «белых» сайтов - тех, которые будут работать при отключения мобильного интернета. В него вошли «наиболее востребованные и социально значимые российские сервисы и сайты» по мнению Минцифры.
Список планируется пополнять в дальнейшем, подчеркнул источник. Ещё один источник на телеком-рынке подтвердил содержание списка.

В перечне к настоящему моменту присутствуют:

- все государственные сайты, сервис госуслуги, портал электронного дистанционного голосования и выборов, платформы обратной связи;
- сервисы «Яндекса» (какие именно не уточняется);
- соцсети «ВКонтакте» и «Одноклассники»;
- маркетплейсы Ozon и Wildberries;
- сервисы Сбербанка, Альфа-банка, Т-банка, Газпромбанка и Национальной системы платежных карт (НСПК);
- личные кабинеты операторов связи «большой четверки» — МТС, «МегаФона», «Т2 РТК Холдинга» (бренд Т2) и «ВымпелКома» (бренд «Билайн);
- сервисы Mail.ru и «Дзен»;
- доска объявлений Avito;
- видеосервисы Rutube и «Кинопоиск»;
- онлайн-карты 2GIS;
- сайт магазина «Магнит».

https://www.rbc.ru/technology_and_media/05/09/2025/68bab3579a79472a69e13def

Тем временм скоро появится новый отечественный мессенджер.

Компания «Ред Софт» и Passion разрабатывают новый мессенджер «Молния», который вроде как по функционалу сопоставим с мессенджером Max от VK. Как и Max, сервис создается по примеру китайского WeChat с возможностями общения, платежей и покупок.

4 сентября 2025 года на конференции ВЭФ-2025 компании официально анонсировали мессенджер Molniya. Приложение представляет собой совместную разработку, суперапп с расширенными функциями общения — от личных коммуникаций, обмена фото, видео и другим контентом до групповых звонков и совещаний.

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

Кроме того, функционал супераппа будет включать элементы социальной сети, короткие видеоролики, потоковое вещание (стриминг), возможности трансграничной торговли. Компания «Ред Софт» заявила, что об официальном запуске и функционале мессенджера будет объявлено отдельно.

https://news.1rj.ru/str/redsoft1/2054

Стратегии обновления при критических изменениях
(продолжение в следующем посте)

Стратегии обновления при критических изменениях
(продолжение предыддущего поста)

Одной из проблем при поддержке программ являются тн breaking changes или критические изменения, которые могут нарушить работы пользователей.
3 способа внедрения критических изменений в распределённых системах:

1. Развёртывание синхронным шагом

Все потребители и производитель обновляются одновременно. Это простая стратегия, но несет риски.

* Упрощает обновление, если одна команда управляет всем
* Полностью нарушает принцип «независимого развёртывания» (independent deployability)
* Одно пропущенное обновление может вывести систему из строя

Используйте этот метод только тогда, когда вы полностью контролируете обе стороны интерфейса.

2. Параллельное существование несовместимых версий

Запуск старой и новой версий сервиса параллельно.
Потребители мигрируют по собственному расписанию.

* Отлично подходит для постепенного развёртывания
* Работает, когда обновления потребителей находятся вне вашего контроля
* Имеет свою цену: двойные развёртывания, двойные исправления, больше инфраструктуры, больше сложности

Это эффективно, но дорого в обслуживании.

3. Эмуляция старого интерфейса

Предоставление доступа как к версии v1, так и к версии v2. Внутренне преобразуйте запросы v1 в логику v2.

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

Этот подход обеспечивает баланс между безопасностью и прогрессом.

Обшие рекомендации:
* Синхронное развёртывание подходит, только если одна команда владеет производителем и всеми потребителями.
* Параллельное существование версий может работать, но добавляет операционную нагрузку.
* Эмуляция идеальна, когда нужна гибкость без затрат на дублирование.

Карто-ориентированное программирование

В руководство по языку Си добавлена статья про Преобразование строк в целые числа
https://metanit.com/c/tutorial/10.6.php
#c_ansi

И также добавлена статья про Сравнение преобразования строк в целые числа в различных языках программирования
https://metanit.com/common/langs/5.5.php

Dirty reads (Грязное чтение / чтение "грязных" данных) — чтение данных, которые ещё не были подтверждены (committed) и могут быть отменены и уровни изоляции
(продолжение в следующем посте)

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

* Dirty reads (Грязное чтение / чтение "грязных" данных) — чтение данных, которые ещё не были подтверждены (committed) и могут быть отменены.
* Non-repeatable reads (Неповторяемое чтение) — ситуация, когда при повторном чтении данных в рамках одной транзакции получаются разные результаты.
* Phantom reads (Фантомное чтение) — появление новых записей при повторном выполнении запроса в рамках одной транзакции.
* Write skew (Искажения) — две транзакции читают перекрывающиеся данные, одновременно производят обновление, а затем фиксируют изменения.


Для управления транзакциями есть следующие уровни изоляции:

* Read Uncommitted — самый быстрый уровень, допускающий все виды несогласованного чтения.
* Read Committed — гарантирует, что читаются только подтверждённые данные, но допускает неповторяемые чтения.
* Repeatable Read — обеспечивает повторяемость чтений, согласованность, но не защищает от фантомных чтений.
* Serializable — самый строгий уровень, гарантирующий полную изоляцию транзакций, но требующий значительных ресурсов.


Например, рассмотрим, как происходят грязные чтения (Dirty Reads) (наглядно на картинке из предыдущего поста):

1. Клиент A начинает транзакцию и выбирает баланс клиента 1, который изначально равен $1,000.
2. Клиент B начинает свою транзакцию и обновляет баланс клиента 1 до $1,200.
3. Клиент A продолжает свою транзакцию, читая баланс клиента 1, и видит значение $1,200, хотя транзакция Клиента B еще не завершена.
4. Клиент B откатывает свою транзакцию, возвращая баланс клиента 1 к исходному значению $1,000.
5. Клиент A завершает свою транзакцию, используя некорректное значение $1,200, что приводит к "грязному чтению".

### Уровни изоляции и их влияние:

- Read Uncommitted:
- Грязные чтения: возможны.
- Неповторяемые чтения: возможны.
- Фантомные чтения: возможны.
- Искажения: возможны.

- Read Committed:
- Грязные чтения: предотвращены.
- Неповторяемые чтения: возможны.
- Фантомные чтения: возможны.
- Искажения: возможны.

- Repeatable Read:
- Грязные чтения: предотвращены.
- Неповторяемые чтения: предотвращены.
- Фантомные чтения: возможны.
- Искажения: возможны.

- Serializable:
- Грязные чтения: предотвращены.
- Неповторяемые чтения: предотвращены.
- Фантомные чтения: предотвращены.
- Искажения: предотвращены.

Общая схема CI/CD Workflow, которая иллюстрирует процесс непрерывной интеграции и доставки программного обеспечения. Основные этапы:

1. Работа над веткой функций (Working on My Feature Branch)
Разработчик создает новую ветку для работы над функцией. Здесь он пишет код и решает возникающие проблемы.

2. Подготовка кода (Code is Ready)
Когда код готов, его отправляют в систему контроля версий (Git).

3. Непрерывная интеграция (Continuous Integration)
- Код собирается из исходного кода.
- Проводится анализ качества кода.
- Выполняются модульные тесты.
- Проверяется интеграция и безопасность.

4. Проверка и одобрение (Review & Approve)
После успешного прохождения тестов код одобряется и объединяется с основной веткой (Main Branch).

5. Сборка и тестирование (Build and Test)
Создается образ приложения, который отправляется в реестр Docker.

6. Развертывание (Deployment)
Приложение развертывается в кластере Kubernetes, и процесс завершается успешным развертыванием.

Поэкспериментировал с машинным обучением на Android и создал простой cканнер QR-кодов

Доступно в магазинах приложений:
RuStore: https://www.rustore.ru/catalog/app/com.metanit.qrscanner
Google Play: https://play.google.com/store/apps/details?hl=ru&gl=ru&id=com.metanit.qrscanner

Возможно, если будет интерес, напишу по этому поводу статью, так как довольно интересная тема.
#android

Микросервисы против Монолитов

Микросервисы против Монолитов
(описание к предыдущему посту)

### Что такое Монолит?

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

### Характеристики Монолитов

* Единая кодовая база и процесс развертывания
* Все функции и модули взаимосвязаны
* Проще начать разработку и развертывание на начальном этапе

### Преимущества Монолитов

* Простота разработки и тестирования на ранних этапах
* Простой процесс развертывания
* Производительность может быть выше для небольших приложений, так как всё работает вместе

### Недостатки Монолитов

* Сложность масштабирования по мере роста системы
* Малое изменение может потребовать повторного развертывания всего приложения
* Большим командам сложно работать независимо и без конфликтов.
* Ошибка в одном модуле может повлиять на всю систему

### Что такое Микросервисы?

Архитектура микросервисов разбивает приложение на небольшие независимые сервисы, которые взаимодействуют через API (часто HTTP/REST или очереди сообщений). Каждый сервис отвечает за определённую бизнес-функцию.

### Характеристики Микросервисов

* Множество небольших сервисов, каждый со своей кодовой базой
* Сервисы взаимодействуют через API или обмен сообщениями
* Независимое развёртывание и масштабирование каждого сервиса

### Преимущества Микросервисов

* Проще масштабировать отдельные части системы
* Команды могут независимо работать над разными сервисами
* Технологическая гибкость (разные сервисы могут использовать различные языки программирования или базы данных)
* Сбои в одном сервисе реже приводят к отказу всей системы

### Недостатки Микросервисов

* Более сложная разработка и управление
* Требуется надёжное отслеживание и взаимодействие между сервисами
* Усложнение процессов развёртывания и DevOps

### Сравнение Монолита и Микросервисов

* Монолит: Единое целое, простота, но малая гибкость и слабая адаптируемость
* Микросервисы: Распределённая система, гибкая, но сложная
* Монолит: Лучше подходит для небольших и средних приложений или ранних этапов разработки
* Микросервисы: Лучше подходит для крупных, сложных и быстро развивающихся систем

В июле компания Fastly опросила 791 профессионального программиста с позицией Senior Developer (с опытом работы более 10 лет) об использовании инструментов ИИ.
По его результатам оказалось, что около трети опрошенных сгенерировали более половины своего кода. Это почти в два с половиной раза больше, чем у младших разработчиков (с опытом работы от 0 до 2 лет), а именно 13%», — отметили в Fastly.

Как признался один из опрошенных, «ИИ тестирует код на стендах и находит ошибки гораздо быстрее человека, исправляя их без проблем».

Старшие разработчики также чаще признавали, что тратят время на исправление кода, сгенерированного ИИ. Чуть менее 30% из них сообщили, что редактируют результаты ИИ в достаточной степени, чтобы компенсировать большую часть экономии времени. У младших разработчиков этот показатель составляет 17%. Тем не менее, 59% сениоров утверждают, что инструменты ИИ помогают им в целом быстрее выпускать код. У джуниоров этот показатель составляет 49%, а чуть более 50% из них отмечают, что ИИ делает их работу умеренно быстрее. Среди сениоров этот показатель составляет 39%.

Однако опытные разработчики чаще сообщают о значительном приросте скорости: 26% утверждают, что ИИ делает их намного быстрее, а у джуниоров этот показатель не превышает 13%. Одна из причин этого разрыва может заключаться в том, что опытные разработчики лучше подготовлены к выявлению и исправлению ошибок ИИ.

Почти каждый третий разработчик (28%) говорит, что ему часто приходится исправлять или редактировать код, сгенерированный ИИ, а это сводит на нет эффект экономии времени. Только 14% говорят, что им редко приходится вносить изменения. И всё же более половины разработчиков по-прежнему чувствуют себя быстрее с инструментами ИИ.

https://www.fastly.com/blog/senior-developers-ship-more-ai-code