5 HTTP-статусных кодов, которые "не должны были существовать"
(продолжение предыдущего поста)

Многие так или иначе знакомы с протоколом HTTP и его статусными кодами. Однако мало кто знает, что есть 5 кодов состояния HTTP, которые являются необычными, забавными или проблематичными - грубо говоря, статусные коды, которые "не должны были существовать"

1. 451 — "Unavailable for legal reasons" (Недоступно по юридическим причинам)
- Используется, когда доступ к запрашиваемому ресурсу запрещён по юридическим причинам.
- Некоторые сайты применяли этот код, чтобы избежать соблюдения законодательных требований, например, GDPR.
- Символика: изображение молотка, отсылающее к судебной тематике.

2. 218 — "This is fine!" (Это нормально!)
- Код вдохновлён популярным интернет-мемом, в котором изображён горящий дом и невозмутимый пёс с подписью "This is fine!".
- Указывает, что ошибка не должна перехватываться сервером — она передаётся клиенту.
- Применяется для обхода переопределений ошибок веб-сервера Apache.
- Символика: улыбающийся смайлик с поднятым вверх большим пальцем.

3. 420 — "Enhance your calm" (Успокойтесь)
- Нестандартный код, который буквально просит клиента "успокоиться".
- Изначально использовался Twitter для обозначения ситуаций, когда клиент превышал лимиты запросов (rate limits).
- Впоследствии заменён на стандартный код 429 (Too Many Requests).
- Символика: изображение человека в позе медитации, подчёркивающее идею "успокоения".

4. 530 — "Site Frozen" (Сайт заморожен)
- Применяется, когда сайт остаётся работоспособным, но намеренно заблокирован провайдером.
- Используется компанией Pantheon (облачный провайдер) для обозначения заблокированных сайтов — например, из-за неоплаченных счетов или истёкших пробных периодов.
- Символика: изображение веб-страницы с морозными узорами, визуально отображающее "заморозку".

5. 418 — "I’m a teapot" (Я — чайник)
- Появился как шутка ко Дню смеха (April Fool’s Day) в 1998 году.
- Символизирует сервер, который не способен "сварить кофе" (выполнить запрошенное действие).
- Несмотря на шуточный характер, код был поддержан основными реализациями HTTP.
- Даже породил шуточное "социальное движение" — Save 418 movement.
- Символика: изображение чайника, подчёркивающее юмористический характер кода.

Паттерн Event Sourcing (источники событий)
(продолжение в следующем посте)

Паттерн Event Sourcing (источники событий)
(продолжение предыдущего поста)

Event Sourcing (источники событий) — это архитектурный паттерн, при котором изменения состояния системы сохраняются в виде последовательного лога событий (событийного журнала), а не напрямую в виде состояния сущностей. Этот подход позволяет воссоздать текущее или историческое состояние системы, воспроизводя события в хронологическом порядке.

Разберём принцип работы по изображению:

1. App (Приложение): инициирует операции (Operations), которые преобразуются в события.

2. Event Store (Хранилище событий):
* служит центральным хранилищем, где последовательно сохраняются все события, происходящие в системе;
* события хранятся в неизменяемом (immutable) виде — их нельзя удалить или изменить, только добавить новые;
* это "источник истины" для всей системы.

3. Event Store Consumer (Потребитель хранилища событий):
* считывает события из хранилища (Consume Event);
* применяет события для формирования текущего состояния системы;
* обновляет Current State DB (БД текущего состояния) — оптимизированную базу данных для быстрого доступа к актуальному состоянию сущностей.

4. Current State DB (БД текущего состояния):
* содержит актуальное состояние системы, сформированное на основе событий;
* используется для быстрых операций чтения (например, отображения данных пользователю).

5. Replay Processor (Процессор воспроизведения):
* позволяет "перепроиграть" события из хранилища для воссоздания состояния системы на любой момент времени (Point in Time — PIT);
* полезен для отката изменений, аудита, восстановления после сбоев или анализа истории изменений.

6. Point in Time DB (БД момента времени):
* хранит состояния системы на определённые моменты времени (снимки состояния);
* позволяет быстро получить состояние системы "на дату", без необходимости полного перебора событий.

Ключевые особенности Event Sourcing:
* Децентрализованное изменение и чтение данных — события могут обрабатываться асинхронно разными компонентами системы.
* Аудит и история изменений — полный лог событий позволяет отследить, кто, когда и какие изменения вносил.
* Возможность отката — при ошибках или необходимости можно "откатить" систему до предыдущего корректного состояния.
* Масштабируемость — событийный лог легко горизонтально масштабируется.
* Сочетание с CQRS — часто используется вместе с паттерном CQRS (Command Query Responsibility Segregation) для разделения команд (изменений) и запросов (чтения).

Примеры применения:
* финансовые системы (где важна история транзакций);
* системы электронной коммерции (отслеживание изменений корзины, заказов);
* CRM-системы (логирование изменений статусов клиентов);
* игровые платформы (сохранение прогресса игрока).

В итоге Event Sourcing смещает фокус с хранения состояния на хранение изменений (событий), что делает систему более гибкой, прозрачной и устойчивой к ошибкам. Однако этот паттерн требует дополнительных ресурсов на моделирование и обработку событий.

Аутентификация на основе токенов и HMAC
(продолжение в следующем посте)

Аутентификация на основе токенов и HMAC
(продолжение предыдущего поста)

Аутентификация на основе токенов и аутентификация HMAC являются распространенными формами аутентификации. Посмотрим, в чем они различаются.

1. Принцип работы

- Аутентификация на основе токенов (Token-based authentication):
1. Клиент отправляет логин и пароль на Authentication Server.
2. Сервер аутентификации генерирует токен (уникальную строку) и передаёт его клиенту.
3. Клиент включает токен в заголовки HTTP-запросов к Web Server при обращении к ресурсам.
4. Web Server проверяет валидность токена и, если он действителен, предоставляет доступ к ресурсу.

Суть: клиент получает токен после успешной аутентификации и использует его для подтверждения своих прав при каждом запросе.

- Аутентификация на основе HMAC (HMAC authentication):
1. Клиент запрашивает API key у Authentication Server.
2. Сервер передаёт клиенту API key (секретный ключ).
3. Клиент генерирует HMAC-подпись (hmac A) на стороне клиента, используя API key и параметры запроса (например, URI, метод HTTP, временная метка).
4. Клиент отправляет запрос к Web Server вместе с HMAC-подписью.
5. Web Server генерирует свою HMAC-подпись (hmac B) с теми же параметрами, используя свой экземпляр API key.
6. Web Server сравнивает hmac A (от клиента) и hmac B (собственно сгенерированный). Если подписи совпадают — запрос считается аутентифицированным.
7. При успешной проверке клиент получает доступ к ресурсу.

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

2. Используемые механизмы безопасности

- Токены:
- Используют систему «выдать и использовать» (token issuance and validation).
- Токены могут быть JWT (JSON Web Tokens) с подписями, которые содержат метаданные (истечение срока действия, идентификатор пользователя и т. д.).
- Защита строится на валидации подписи токена и его срока действия.

- HMAC:
- Основан на криптографической функции HMAC (Hash-based Message Authentication Code), которая сочетает хэш-функцию и секретный ключ.
- Гарантирует целостность данных (данные не изменены в пути) и аутентичность отправителя (только владелец секретного ключа может сгенерировать корректную подпись).
- Секретный ключ никогда не передаётся в открытом виде — только используется для генерации подписей.

3. Этапы взаимодействия

- Токены: 4 основных шага (вход → получение токена → отправка запросов с токеном → доступ к ресурсу).
- HMAC: 7 шагов, включая генерацию и сравнение подписей (запрос API key → генерация подписи клиентом → отправка запроса → генерация подписи сервером → сравнение подписей → доступ к ресурсу).

4. Уровень сложности и вычислительных затрат

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

5. Сценарии применения

- Токены: подходят для веб-приложений, мобильных приложений, где важна простота и скорость аутентификации. Часто используются в REST API, SPA (Single Page Applications).
- HMAC: предпочтителен для API, где критична безопасность (финансовые сервисы, платёжные системы), а также для микросервисов, где требуется строгая проверка целостности запросов.

6. Уязвимости и защита

- Токены: уязвимы к перехвату (если не используются защищённые каналы, например, HTTPS). JWT могут быть подвержены атакам, если подпись не проверена должным образом.
- HMAC: более устойчив к перехвату, так как даже зная запрос, злоумышленник не сможет сгенерировать корректную подпись без секретного ключа. Однако требует строгой защиты API key.

Краткое резюме:
- Токены — удобны и быстры, но менее безопасны.
- HMAC — более сложен в реализации, но обеспечивает высокий уровень защиты за счёт криптографической проверки целостности и подлинности. Выбор зависит от требований к безопасности и архитектуры системы.

Типы криптографии
(описание в следующем посте)

Типы криптографии
(продолжение предыдущего поста)

В зависимости от устойчивости к квантовым вычислениям криптография делится на два основных класса:
1. Quantum-breakable (уязвимые для квантовых атак).
2. Quantum-secure (устойчивые к квантовым атакам).

#### 1. Quantum-breakable (уязвимые для квантовых атак)

Эти методы могут быть взломаны с помощью квантовых компьютеров. К ним относятся:

- RSA encryption (шифрование RSA):
- Сообщение шифруется с помощью публичного ключа получателя.
- Расшифровывается с помощью приватного ключа.
- Безопасность основана на сложности разложения на простые множители (вычисления приватного ключа из публичного).

- Diffie-Hellman key exchange (обмен ключами Диффи-Хеллмана):
- Два участника совместно создают общий секретный ключ по незащищённому каналу.
- Этот ключ используется для зашифрованной коммуникации.
- Безопасность основана на сложности задачи дискретного логарифма.

- Elliptic curve cryptography (криптография на эллиптических кривых):
- Используются математические свойства эллиптических кривых для генерации публичных и приватных ключей.
- Сложность восстановления приватного ключа из публичного связана с задачей дискретного логарифма на эллиптических кривых.

#### 2. Quantum-secure (устойчивые к квантовым атакам)

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

- Lattice-based cryptography (решётчатая криптография):
- Безопасность основана на сложности нахождения ближайшей точки в решётке с сотнями пространственных измерений.
- Приватный ключ ассоциируется с точкой решётки, а публичный — с произвольной точкой в пространстве.

- Code-based cryptography (криптография на основе кодов):
- Приватный ключ связан с кодом, исправляющим ошибки.
- Публичный ключ — это искажённая и ошибочная версия этого кода.
- Безопасность основана на сложности декодирования общего линейного кода.

- Multivariate cryptography (многомерная криптография):
- Основана на сложности решения систем многомерных полиномиальных уравнений.
- Использует сложные математические конструкции для обеспечения безопасности.

Резюме:
- Quantum-breakable методы эффективны сейчас, но уязвимы для будущих квантовых компьютеров.
- Quantum-secure методы разрабатываются для защиты данных в эпоху квантовых вычислений.

Полная шпаргалка по командам Docker
(продолжение предыдущего поста)

#### 1. Установка (Installation)
- Установка Docker Engine (только для Linux): [https://docs.docker.com/engine/install/](https://docs.docker.com/engine/install/).
- Установка Docker Desktop (Linux, macOS, Windows): [https://docs.docker.com/desktop/](https://docs.docker.com/desktop/).

#### 2. Команды для работы с контейнерами (Container commands)
- `docker run <image>` — создаёт и запускает новый контейнер.
- `docker run -p 8080:80 <image>` — публикует порт контейнера (80) на порт хоста (8080).
- `docker run -d <image>` — запускает контейнер в фоновом режиме (detached mode).
- `docker run -v <host>:<container> <image>` — монтирует директорию хоста в контейнер.
- `docker ps` — выводит список запущенных контейнеров.
- `docker ps --all` — выводит список всех контейнеров (запущенных и остановленных).
- `docker logs <container_name>` — получает логи контейнера.
- `docker logs -f <container_name>` — получает логи и следит за их обновлением в реальном времени (follow).
- `docker stop <container_name>` — останавливает запущенный контейнер.
- `docker start <container_name>` — запускает остановленный контейнер.
- `docker rm <container_name>` — удаляет контейнер.

#### 3. Выполнение команд внутри контейнера (Executing commands in a container)
- `docker exec <container_name> <command>` — выполняет команду внутри запущенного контейнера.
- `docker exec -it <container_name> bash` — открывает оболочку (shell) внутри запущенного контейнера для интерактивного взаимодействия.

#### 4. Команды для работы с образами (Image commands)
- `docker build -t <image> .` — создаёт новый образ из Dockerfile в текущей директории и присваивает ему тег (tag).
- `docker images` — выводит список локальных образов.
- `docker rmi <image>` — удаляет образ.

#### 5. Команды для работы с реестром контейнеров (Container registry commands)
- `docker login` — авторизуется в Docker Hub.
- `docker login <server>` — авторизуется в другом реестре контейнеров.
- `docker logout` — выходит из Docker Hub.
- `docker logout <server>` — выходит из другого реестра контейнеров.
- `docker push <image>` — загружает образ в реестр.
- `docker pull <image>` — скачивает образ из реестра.
- `docker search <image>` — ищет образы в Docker Hub.

#### 6. Системные команды (System commands)
- `docker system df` — показывает использование дискового пространства Docker.
- `docker system prune` — удаляет неиспользуемые данные (например, остановленные контейнеры, несуществующие образы).
- `docker system prune -a` — удаляет все неиспользуемые данные (включая остановленные контейнеры и образы).

#### 7. Команды Docker Compose
- `docker compose up` — создаёт и запускает контейнеры.
- `docker compose up -d` — создаёт и запускает контейнеры в фоновом режиме.
- `docker compose up --build` — пересобирает образы перед запуском контейнеров.
- `docker compose stop` — останавливает сервисы.
- `docker compose down` — останавливает и удаляет контейнеры и сети.
- `docker compose ps` — выводит список запущенных контейнеров.
- `docker compose logs` — показывает логи всех контейнеров.
- `docker compose logs <service>` — показывает логи конкретного сервиса.
- `docker compose logs -f` — показывает логи и следит за их обновлением.
- `docker compose pull` — скачивает последние образы.
- `docker compose build` — собирает или пересобирает сервисы.
- `docker compose build --pull` — скачивает последние образы перед сборкой.

Гендиректор Microsoft призвал пользователей перестать называть «шлаком» ИИ‑контент

Генеральный директор Microsoft Сатья Наделла опубликовал пост в LinkedIn, в котором подвел итоги 2025 года. В нём Наделла заявил о необходимости найти новый баланс во взаимодействии человека и ИИ вместо ставшего привычным разделения ИИ на «слоп» и «высокие технологии».

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

Глава Microsoft отметил, что главной задачей на ближайшие годы станет ответственное распространение ИИ. По мнению Наделлы, человечество скоро перейдёт от восприятия ИИ как отдельных моделей к внедрению в жизнь людей систем, основанных на ИИ. В то же время развитие ИИ опережает способность общества эффективно его использовать, признал Наделла.

https://snscratchpad.com/posts/looking-ahead-2026/

РИА Новости: сильнее всего зарплаты в России за год выросли у издателей ПО

Наиболее сильно за последний год зарплаты в России выросли у издателей программного обеспечения – сразу на 137 тысяч рублей на конец октября, следует из расчетов РИА Новости по данным статистики.

Средняя зарплата в России увеличилась за 12 последних месяцев на 13,1 тысячи рублей и составила в октябре 99,7 тысячи рублей. При этом среди отраслей рост был зафиксирован у сотрудников 258 сфер деятельности, а спад – у семи.

Еще на 69 тысяч они увеличились у рыболовов, а на 55,5 тысячи – у сотрудников холдинговых компаний. В пятерку по темпам роста также вошли занятые в сфере аренды интеллектуальной собственности – на 50,7 тысячи рублей, а также разработчики строительных проектов – на 46,3 тысячи рублей.

https://ria.ru/20260104/zarplaty-2066310216.html

Что такое взаимоблокировка (deadlock)
(продолжение в следующем посте)

Что такое взаимоблокировка (deadlock)
(продолжение предыдущего поста)

Рассмотрим взаимоблокировки: условия возникновения, способы предотвращения и стратегии восстановления.

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

Условия Коффмана

Условия Коффмана (названы в честь Эдварда Г. Коффмана‑младшего, который впервые сформулировал их в 1971 году) описывают четыре необходимых условия, которые должны присутствовать одновременно для возникновения взаимоблокировки:
* взаимное исключение (Mutual Exclusion);
* удерживание и ожидание (Hold and Wait);
* отсутствие принудительного изъятия (No Preemption);
* циклическое ожидание (Circular Wait).

Предотвращение взаимоблокировок

* Упорядочивание ресурсов: установить полный порядок для всех типов ресурсов и требовать, чтобы каждый процесс запрашивал ресурсы в строго возрастающем порядке.
* Таймауты: процесс, который удерживает ресурсы слишком долго, может быть откатан назад (выполнен откат).
* Алгоритм банкира (Banker’s Algorithm): алгоритм предотвращения взаимоблокировок, который имитирует распределение ресурсов между процессами и помогает определить, безопасно ли удовлетворять запрос на ресурс, исходя из будущего наличия ресурсов. Это позволяет избегать небезопасных состояний.

Восстановление после взаимоблокировки

* Выбор «жертвы»: большинство современных систем управления базами данных (СУБД) и операционных систем реализуют сложные алгоритмы для обнаружения взаимоблокировок и выбора «жертв». Часто допускается настройка критериев выбора «жертвы» через параметры конфигурации. Выбор может основываться на использовании ресурсов, приоритете транзакции, стоимости отката и т. д.
* Откат (Rollback): база данных может выполнить откат всей транзакции или только её части — достаточной для снятия взаимоблокировки. Откаченные транзакции могут быть автоматически перезапущены системой управления базами данных.

C# - язык года по версии TIOBE

Рейтинг TIOBE второй раз за 3 года назвал C# языком программирования года (2025 года). В комментарии от TIOBE отмечается, что "C# заслужил это звание, показав наибольший годовой рост в рейтинге. За эти годы язык претерпел фундаментальные изменения. С точки зрения проектирования языка, C# часто был одним из первых, кто перенимал новые тенденции среди основных языков. В то же время он успешно совершил два крупных парадигмальных сдвига: от языка, предназначенного только для Windows, к кроссплатформенному, и от языка, принадлежащего Microsoft, к языку с открытым исходным кодом. C# постоянно развивался в нужный момент."

Среди других победителей - Perl, который, поднялся с 32-й позиции на 11-ю и вновь вошел в топ-20, и R - вернулся в топ-10 во многом благодаря продолжающемуся росту в области науки о данных и стат. вычислений.
Среди проигравших - Go - окончательно потерял место в топ-10 в 2025 г, и Ruby, который выпал из топ-20.

https://www.tiobe.com/tiobe-index/

Базы данных NoSQL
(продолжение в следующем посте)

Базы данных NoSQL
(продолжение предыдущего поста)

Когда говорят о NoSQL, то естественно имеют ввиду базы данных, которые не используют SQL для выполнения запросов к БД. Однако в реальности мир NoSQL очень многогранен, и каждая NoSQL-БД оптимизирована под конкретные задачи. Рассмотрим основные типы БД NoSQL.

1. MongoDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- использует формат BSON (Binary JSON);
- схема не фиксирована (schema-less);
- горизонтальное масштабирование (sharding);
- репликация для высокой доступности.
- Сценарии использования:
- системы управления контентом (CMS);
- управление каталогами.

2. Cassandra (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- столбцы могут варьироваться в разных строках (wide-column);
- распределённая архитектура;
- язык запросов CQL (SQL-подобный для NoSQL);
- оптимизирована для аналитических запросов.
- Сценарии использования:
- управление временными рядами данных;
- рекомендательные системы.

3. Redis (Key-Value Store)
- Тип: Хранилище «ключ-значение».
- Особенности:
- работает в оперативной памяти (in-memory store);
- поддерживает сложные структуры данных;
- механизмы персистентности (RDB, AOF);
- репликация (primary-replica).
- Сценарии использования:
- кэширование данных;
- управление сессиями;
- таблицы лидеров в играх (gaming leaderboard).

4. Couchbase (Document Store with Key-Value Capabilities)
- Тип: Гибридная БД (документоориентированная + хранилище «ключ-значение»).
- Особенности:
- работает в режиме памяти (memory first);
- репликация между центрами обработки данных (XDCR);
- сочетает операции с документами и хранилищем «ключ-значение».
- Сценарии использования:
- системы управления контентом (CMS);
- платформы электронной коммерции.

5. Neo4j (Graph DB)
- Тип: Графовая БД.
- Особенности:
- поддерживает ACID-транзакции;
- использует язык запросов Cypher;
- индексация без дополнительных таблиц (index-free adjacency);
- кластеризация (HA cluster).
- Сценарии использования:
- социальные сети;
- системы обнаружения мошенничества (fraud detection).

6. Amazon DynamoDB (Key-Value and Document Store)
- Тип: Хранилище «ключ-значение» с поддержкой документов.
- Особенности:
- автоматическое масштабирование;
- управление через AWS;
- распределение данных между узлами;
- поддержка DynamoDB Streams.
- Сценарии использования:
- бессерверные приложения (serverless applications);
- IoT-приложения.

7. Apache HBase (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- основана на Google Bigtable;
- интеграция с Hadoop;
- автоматическое шардирование (auto-sharding);
- сильная согласованность (strong consistency).
- Сценарии использования:
- хранилища данных (data warehouse);
- крупномасштабная обработка данных (large-scale data processing).

8. Elasticsearch (Search Engine)
- Тип: Поисковая система на основе документов.
- Особенности:
- построена на Apache Lucene;
- ориентирована на документы;
- шардирование и репликация;
- RESTful API.
- Сценарии использования:
- полнотекстовый поиск (full-text search);
- анализ логов и событий (log and event data analysis).

9. CouchDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- обеспечивает согласованность данных без блокировок;
- использует RESTful API;
- модель согласованности «в конечном счёте» (eventual consistency).
- Сценарии использования:
- мобильные приложения;
- системы управления контентом (CMS).

В итоге каждая NoSQL БД оптимизирована под конкретные задачи:
- документоориентированные (MongoDB, CouchDB) — для веб-приложений и CMS;
- колоночные (Cassandra, HBase) — для аналитических запросов и временных рядов;
- хранилища «ключ-значение» (Redis, DynamoDB) — для кэширования и сессий;
- графовые (Neo4j) — для моделирования сложных связей (социальные сети, рекомендации);
- поисковые (Elasticsearch) — для полнотекстового поиска и анализа логов.