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

Кто-нибудь знает или помнит, что у нас есть «Большая российская энциклопедия» - аналог Википедии, точнее была...

Так вот правительство России направит 303 млн рублей на ликвидацию автономного некоммерческого общества (АНО) «Большая российская энциклопедия». Соответствующее распоряжение опубликовано на портале правовой информации. АНО занималось созданием портала, позиционирующимся как аналог «Википедии». Однако, в отличие от «Википедии», на статьи портала можно было ссылаться в научных и студенческих учебных работах, эти работы индексировались в Российском индексе научного цитирования.

Финансы выделят в 2025 году из резервного фонда кабинета министров РФ. Эти средства пойдут на погашение задолженности по заработной плате, выплаты при увольнении сотрудников и расчёты по обязательствам организации. Контролировать использование средств будет Минцифры РФ. Ведомство представит отчёт о проведённых мероприятиях до 1 марта 2026 года.
https://www.rbc.ru/rbcfreenews/68b94e179a794743f7649ffa