В руководство по языку Си добавлена статья про Преобразование строк в целые числа
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)

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

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

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

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

В результате фишинга атакующим удалось перехватить учётные данные сопровождающего 18 популярных NPM-пакетов, в сумме загруженных более 2 миллиардов раз в неделю. Для скомпрометированных пакетов атакующие успели выпустить новые версии, содержащие вредоносный код. Это самая крупная атака на репозиторий NPM, которая затрагивает не только напрямую атакованные проекты, но сотни тысяч пакетов, зависимых от них.

Среди прочего, вредоносные обновления были выпущены для пакетов debug, chalk, ansi-styles, color-convert, wrap-ansi, supports-color и ansi-regex, имеющих более 200 млн загрузок за последнюю неделю. Отдельно выделяются пакеты chalk и debug, у которых имеется 129286 и 55289 зависимостей. Пакеты были скомпрометированы из-за утечки параметров учётной записи Джоша Джунона (Josh Junon), который является сопровождающим debug-js, chalk и множества библиотек для консольных приложений.

https://www.opennet.ru/opennews/art.shtml?num=63845

Проблема N+1 запросов
(продолжение в следующем посте)

Проблема N+1 запросов
(продолжение к предущему посту)

Проблема N+1 запросов - это ситуация, когда один запрос возвращает набор результатов, и для каждого из них требуется дополнительный запрос. Количество запросов, необходимых для загрузки страницы, зависит от размера набора результатов, что приводит к низкой производительности при большом значении N.

Пример (псевдокод):

// 1 запрос
users = db.query('SELECT * FROM users');

// ...что приводит к N дополнительным запросам
for (const user of users) {
  posts = db.query(`
      SELECT * FROM posts 
      WHERE user_id = user->id`);
  user.posts = posts;
}
// Теперь можно вернуть результат запрашивающей стороне

Вместо этого можно переписать код как один запрос с JOIN, чтобы получить все данные за одно обращение к БД:

results = await db.query(
  `SELECT u.*, p.* 
    FROM users u 
    LEFT JOIN posts p 
    ON u->id = p->user_id`);

Для некоторых запросов влияние N+1 может быть минимальным. Если N — небольшое число, всё может казаться «быстрым», если БД хорошо настроена и находится рядом с серверами приложений. Но при N=100 начинают проявляться замедления, и БД загружается сильнее, чем необходимо. Устранение таких проблем улучшает пользовательский опыт и снижает нагрузку на БД.

Шпаргалка по интервью по API
(описание в следующем посте)

Шпаргалка по интервью по API
(продолжение предыдущего поста)

Основы API

*Что такое API?*
API — это программное обеспечение, которое действует как посредник между приложениями, помогая им взаимодействовать друг с другом с помощью HTTP-запросов.

*Типы API*
* Открытые API
* Закрытые API
* Партнерские API
* Композитные API

Тестирование API

*Что такое тестирование API?*
Тестирование API — это стратегия тестирования программного обеспечения, которая гарантирует, что API стабильны, функциональны, надежны и безопасны.

*Преимущества тестирования API*
* Удобство
* Лучше, чем тестирование GUI
* Независимость от языка
* Гибкость в выборе языка программирования

REST vs SOAP

*REST*
* Использует XML или JSON
* Поддерживает HTTP
* Быстрее, чем SOAP
* Поддерживает кэширование

*SOAP*
* Использует только XML
* Поддерживает HTTP и HTTPS
* Более безопасен, чем REST
* Не поддерживает кэширование

API Testing vs Unit Testing

*Тестирование API*
* Использует тестирование «черного ящика»
* Проверяет функциональность

*Юнит-тестирование*
* Использует тестирование «белого ящика»
* Проверяет отдельные блоки кода

CRUD
Эта аббревиатура представляет четыре основные операции, распространенные в реляционных базах данных: создание, чтение, обновление и удаление.

Архитектура REST API
Схема показывает взаимодействие между клиентом и сервером через REST API, включая запросы и ответы.

Дополнительные вопросы об API

*Что такое аутентификация API?*
Аутентификация API — это процесс проверки прав доступа пользователя к данным и ресурсам, которые он запрашивает.

*Что такое Runscope?*
Runscope — это веб-приложение, используемое для мониторинга, отладки и тестирования производительности веб-сервисов API.

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