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

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

- все государственные сайты, сервис госуслуги, портал электронного дистанционного голосования и выборов, платформы обратной связи;
- сервисы «Яндекса» (какие именно не уточняется);
- соцсети «ВКонтакте» и «Одноклассники»;
- маркетплейсы 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

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

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

### 1. Предохранитель (Circuit Breaker)

* Работает как электрический предохранитель.
* Когда сервис сталкивается с повторяющимися сбоями, предохранитель срабатывает и прекращает отправку запросов к этому сервису на определённый период.
* Это позволяет проблемному сервису восстановиться, не подвергаясь дополнительной нагрузке.

Основные состояния предохранителя:
* Закрыто: запросы пропускаются.
* Открыто: запросы немедленно отклоняются с ошибкой.

Эффективен для защиты от каскадных сбоев и изоляции проблемных сервисов.

### 2. Повтор запроса (Retry)

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

### 3. Таймаут (Timeout)

* Устанавливает максимальное время ожидания для запроса.
* Если ответ не получен в течение заданного периода, запрос считается неудачным.

### 4. Переборка (Bulkhead)

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

### 5. Ограничение скорости (Rate Limiting)

* Контролирует частоту входящих запросов для защиты системы от перегрузки.
* Защищает от атак типа «отказ в обслуживании», обеспечивает справедливое использование и помогает поддерживать стабильность системы.

### 6. Запасной вариант (Fallback)

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

### 7. Хеджирование (Hedging)

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

### 8. Сброс нагрузки (Load Shedding)

* Отбрасывает некритичные запросы при перегрузке системы для защиты её основной функциональности.
* Помогает поддерживать стабильность и доступность системы при пиковых нагрузках.

### 9. Обратное давление (Backpressure)

* Имеет некоторое сходство с другими паттернами отказоустойчивости.

Основной механизм обратного давления — это петля обратной связи между отправителем (производителем данных) и получателем (потребителем данных).

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

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