Работа с Cron
(продолжение предыдущего поста)

1. Что такое Cron и Crontab?

Cron — это планировщик задач в Linux, который автоматически выполняет скрипты или команды по расписанию. Crontab — это файл с расписанием задач (таблицы заданий), доступный каждому пользователю системы.
Cron позволяет автоматизировать выполнение задач с высокой гибкостью: от ежеминутных проверок до ежегодных операций. Главное — правильно настроить расписание с помощью синтаксиса и операторов, а также использовать удобные макросы для стандартных интервалов.


2. Синтаксис Cron-выражений

Cron-выражение состоит из 5 полей, определяющих расписание выполнения задачи:

- Минуты (0–59);
- Часы (0–23);
- День месяца (1–31);
- Месяц (1–12);
- День недели (0–6, где 0 = воскресенье, 6 = суббота).

Формат записи:
* * * * * команда
(где * — любое значение, команда — выполняемая команда/скрипт).

Примеры из изображения:
- # every Mon midnight → 0 0 * * 1 command (выполняется в полночь по понедельникам);
- # everyday 05:04 AM → 4 5 * * * command (каждый день в 05:04 утра);
- # every Sun 12:05 PM → 5 12 * * 0 command (каждое воскресенье в 12:05).

3. Специальные сокращения (макросы)

Для удобства используются макросы — короткие обозначения стандартных расписаний:
- @reboot — при загрузке системы;
- @hourly — каждый час;
- @daily (или @midnight) — ежедневно в полночь;
- @weekly — каждую неделю;
- @monthly — каждый месяц;
- @yearly (или @annually) — каждый год.

Примеры:
- @reboot command — запуск команды при старте системы;
- @hourly command — выполнение команды каждый час;
- @yearly command — выполнение команды раз в год.

4. Операторы в Cron

В Cron используются специальные операторы для настройки расписаний:
- `*` — все возможные значения (например, * * * * * — каждую минуту каждого часа);
- `,` — перечисление значений (например, 0 8,12,16 * * * command — в 8:00, 12:00 и 16:00);
- `-` — диапазон значений (например, 0 9-17 * * 1-5 command — с 9:00 до 17:00 по будням);
- `/` — шаг (например, */5 * * * * command — каждые 5 минут);
- `L` — последнее значение (используется в полях «день месяца» и «день недели»);
- `W` — ближайший будний день (например, 15 10 * * 5W — в 10:15 в ближайшую пятницу);
- `?` — игнорирование поля (используется в «день месяца» или «день недели»).

5. Команды для работы с Crontab

Для управления заданиями Cron используются команды:
- $ crontab -e — редактирование/создание файла crontab;
- $ crontab — просмотр текущего crontab-файла;
- $ crontab -r — удаление crontab-файла;
- $ crontab -u username -l — просмотр crontab другого пользователя;
- $ crontab -u username -e — редактирование crontab другого пользователя;
- $ echo "username" > /etc/cron.allow — разрешение пользователю использовать cron;
- $ echo "username" > /etc/cron.deny — запрет пользователю использовать cron;
- $ crontab -v — показ времени последнего изменения crontab.

6. Примеры расписаний из изображения

- Каждые 6 часов: 0 */6 * * * command;
- Каждые 5 минут: */5 * * * * command;
- Ежемесячно: 0 0 1 * * command (1-го числа каждого месяца в 00:00);
- Раз в год: @yearly command или @annually command.

7. Практические шаги

1. Откройте файл crontab: $ crontab -e.
2. Добавьте расписание и команду (используя синтаксис из п. 2–4).
3. Сохраните изменения (например, в редакторе nano — Ctrl+O, затем Ctrl+X).
4. Проверьте список задач: $ crontab -l.
5. При необходимости удалите задачи: $ crontab -r.

В Южной Корее покупателей новых смартфонов обязали проходить процедуру распознавания лица

Граждан Южной Кореи обязали проходить процедуру распознавания лица при настройке нового смартфона. Со вторника эта мера стала обязательной для всех новых пользователей независимо от того, покупают они устройство онлайн или в магазинах, сообщает Korea Herald.

Согласно правилам, подтверждение личности через распознавание лица требуется при активации смартфона. Пользователям нужно сфотографировать своё лицо через приложение аутентификации PASS. Ранее хватало предъявления паспорта, но теперь добавлен дополнительный шаг биометрической проверки.

Требование касается трёх основных операторов (SK Telecom, KT и LG Uplus), а также бюджетных провайдеров. Власти планируют распространить систему на всех к 23 марта 2026 года.

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

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

https://www.koreaherald.com/article/10642116

Polling vs WebHook

Microsoft опровергла информацию (или отказалась под влиянием общественности) о том, что компания намерена переписать код Windows 11 на Rust с использованием ИИ. Ранее это заявление от имени одного из инженеров вызвало возмущение пользователей.

«Моя цель — к 2030 году полностью исключить использование C и C++ в коде Microsoft. Наша стратегия заключается в объединении ИИ и алгоритмов для переписывания крупнейших кодовых баз Microsoft. Наша путеводная звезда — “1 инженер, 1 месяц, 1 миллион строк кода”», — писал Гален Хант, ведущий инженер Microsoft.

Между тем большая часть кода уровня API Windows, а также ядро ОС, написаны на C, в то время как некоторые приложения работают на C++.

После возмущения по поводу планов «исключить каждую строку C и C++ из кода Microsoft к 2030 году» компания заявила, что таких планов у неё нет.

Фрэнк X. Шоу, глава отдела коммуникаций Microsoft, также подтвердил, что компания не планирует переписывать Windows 11 с использованием ИИ.

https://www.windowslatest.com/2025/12/24/microsoft-denies-rewriting-windows-11-using-ai-after-an-employees-one-engineer-one-month-one-million-code-post-on-linkedin-causes-outrage/

Шаблоны (паттерны) решения задач по Структурами данных и алгоритмам (Data Structures and Algorithms / DSA)
(продолжение в следующем посте)

Шаблоны (паттерны) решения задач по Структурами данных и алгоритмам (Data Structures and Algorithms / DSA)
(продолжение предыдущего поста)

1. Array / String Inputs (Массивы / строки):

1. Отсортирован ли массив?
→ Использовать бинарный поиск, два указателя или префиксные суммы.
2. Задачи оптимизации (максимум/минимум/подмассив)?
→ Подумать о скользящем окне, динамическом программировании или жадных алгоритмах.
3. Поиск дубликатов, подсчёта или частот?
→ Использовать HashMap, HashSet или массив для подсчёта.
4. Нужны подстроки или подмассивы фиксированного размера?
→ Применить скользящее окно с двумя указателями.
5. Часто встречающиеся минимум/максимум в окне?
→ Использовать монотонную очередь, deque или кучу.
6. Генерация подмножеств, перестановок, комбинаций?
→ Использовать обратный ход (backtracking).
7. Сопоставление или разбор символов?
→ Использовать стек, особенно для сбалансированных скобок, инфиксной/постфиксной записи.

2. Graph Inputs (Графы):

1. Кратчайший путь в невзвешенном графе?
→ Использовать поиск в ширину (BFS).
2. Кратчайший путь в взвешенном графе?
→ Использовать алгоритм Дейкстры, Беллмана-Форда или A*.
3. Связные компоненты / обнаружение циклов?
→ Использовать DFS или Union-Find (DSU).
4. Топологическая сортировка?
→ Использовать алгоритм Кана или DFS с набором посещённых вершин.
5. Оптимизация, например, MST (минимальное остовное дерево)?
→ Использовать алгоритмы Крускала или Прима.

3. Linked List Inputs (Связанные списки):

1. Обнаружение циклов?
→ Использовать «медленный и быстрый указатели» (алгоритм Флойда).
2. Перевороты или частичные изменения?
→ Использовать жонглирование указателями: prev, curr, next.
3. Пересечение или средний узел?
→ Использовать два указателя.

4. Tree Inputs (Часто бинарные деревья):

1. Обходы?
→ Использовать inorder, preorder, postorder или обход по уровням (BFS).
2. Проверка сбалансированности или расчёт диаметра?
→ Использовать postorder + расчёт высоты.
3. Наименьший общий предок?
→ Использовать рекурсивный DFS или карту родителей + набор предков.

5. Dynamic Programming Use-Cases (Случаи применения динамического программирования):

1. Оптимальный выбор / перекрывающиеся подзадачи?
→ Использовать ДП с мемоизацией (сверху вниз) или табуляцией (снизу вверх).
2. Задачи типа «подмножество» или "knapsack"?
→ Использовать 1D/2D массивы ДП.
3. Сопоставление строк или редактирование?
→ Использовать матрицу ДП (например, расстояние редактирования, LCS).

Вышла новая версия языка Ruby - Ruby 4.0.0

Ruby 4.0.0 включает ряд значительных нововведений и улучшений, направленных на повышение производительности, безопасности и удобства работы с языком. Некоторые из ключевых изменений:

1. ZJIT — новый JIT-компилятор. ZJIT (Just-In-Time компилятор) дополняет существующий YJIT. В отличие от YJIT, который использует подход ленивого создания версий базовых блоков, ZJIT основан на более традиционной методологии компиляции на уровне методов, а не локальных участков байткода. Для работы с ZJIT требуется Rust версии 1.85.0 или новее. Чтобы активировать ZJIT, можно использовать флаг --zjit: ruby --zjit my_script.rb. Хотя ZJIT быстрее интерпретируемого кода, для продакшена по-прежнему рекомендуется использовать YJIT. 

2. Ruby::Box — экспериментальная функция изолированных пространств имён. Позволяет создавать отдельные «боксы», в которых код выполняется с собственными глобальными переменными, константами и определениями классов. Это полезно, например, для одновременной загрузки разных версий одной библиотеки. Чтобы активировать Ruby::Box, нужно установить переменную окружения RUBY_BOX=1. 

3. Переработанный API Ractor. Для коммуникации между Ractors теперь используется Ractor::Port. Удалённы старые методы Ractor.yield и Ractor#take. Проделана большая работа по повышению стабильности, производительности и удобства использования Ractor. Эти улучшения приближают реализацию Ractor к выходу из экспериментального статуса. Добавлены методы Ractor#join и Ractor#value, аналогичные тем, что есть у Thread. 

4. Логические операторы в начале новой строки. В Ruby 4.0 теперь разрешено размещать логические операторы (&&, ||, and, or) в начале новой строки. Это улучшает читаемость сложных условных выражений и соответствует распространённым предпочтениям форматирования. 

5. `instance_variables_to_inspect`. Новая функция позволяет контролировать, какие переменные экземпляра отображаются в выводе метода inspect при отладке. Это помогает сделать вывод более лаконичным и сфокусированным на важном состоянии объекта. 

6. `Set` стал базовым классом. Ранее Set был классом из стандартной библиотеки, теперь он включён в ядро языка, и его не нужно подключать с помощью require 'set'. 

7. Новые методы в `Math`. Добавлены методы Math.log1p и Math.expm1 для более точных вычислений с малыми числами. Math.log1p(x) вычисляет log(1 + x), а Math.expm1(x)` — `exp(x) - 1. Эти методы полезны в научных расчётах и финансовых вычислениях. 

8. Другие изменения:
- nil больше не вызывает nil.to_a, что согласуется с поведением **. 
- IO.select теперь принимает Float::INFINITY в качестве аргумента таймаута. 
- File::Stat#birthtime теперь работает в Linux через системный вызов statx, если это поддерживается ядром и файловой системой. 
- Socket.tcp получил ключевой аргумент open_timeout. 
- RJIT удалён, остались только YJIT и ZJIT. 
- Юникод обновлён до версии 17.0. 
- В Windows прекращена поддержка версий MSVC старше 14.0 (_MSC_VER 1900). Для работы с Ruby 4 потребуется Visual Studio 2015 или более поздняя версия. 

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

https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-released/

Диаграмма подсистемы ввода-вывода в Linux

Лучшие практики при построении REST API
(продолжение в следующем посте)

Лучшие практики при построении REST API
(продолжение предыдущего поста)

1. Версионирование API (API Versioning)
- URL-based Versioning: версия API указывается в URL-пути, например:
https://api.example.com/v1/users (Version 1),
https://api.example.com/v2/users (Version 2).
Это позволяет клиентам легко переключаться между версиями.
- Query Parameter Versioning: версия задаётся через параметры запроса:
https://api.example.com/users?version=1 (Version 1),
https://api.example.com/users?version=2 (Version 2).
Подходит для постепенного внедрения изменений без изменения URL.

2. Стандартные коды ошибок (Standard Error Codes)
- Используйте общепринятые HTTP-коды ответов:
- 2ХХ (успех): 200 OK, 201 Created, 202 Accepted, 204 No Content.
- 4ХХ (ошибки клиента): 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict.
- 5ХХ (ошибки сервера): 500 Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.
- Это упрощает обработку ошибок на стороне клиента.

3. Именования ресурсов (Noun-Based Resource Names)
- Используйте существительные для именования конечных точек (endpoints), а не глаголы.
Пример: /api/products вместо /api/createProduct.
- Операции (Create, Read, Update, Delete) реализуются через HTTP-методы:
- POST — создание ресурса;
- GET — чтение ресурса;
- PUT — обновление ресурса;
- DELETE — удаление ресурса.

4. Идемпотентность (Idempotency)
- Идемпотентные методы (GET, HEAD, PUT, DELETE): многократное выполнение запроса даёт тот же результат, что и однократное. Это важно для устойчивости к сетевым сбоям.
- Неидемпотентные методы (POST, PATCH): повторные запросы могут привести к разным результатам (например, создание нескольких записей).
- Для обеспечения идемпотентности используйте Idempotency Key — уникальный ключ в запросе, который сервер сохраняет для предотвращения дублирования операций.

5. Пагинация (Pagination)
- Используйте offset pagination для разбиения больших наборов данных на страницы.
Пример:
- offset = 0, limit = 3 — первая страница (Page 1);
- offset = 3, limit = 3 — вторая страница (Page 2).
- Это снижает нагрузку на сервер и ускоряет обработку запросов.

6. Безопасность (Security)
- Применяйте JWT (JSON Web Tokens) для аутентификации и авторизации:
- Header: содержит алгоритм шифрования (например, HS256) и тип токена (JWT).
- Payload: данные пользователя (ID, роль, время истечения токена и др.).
- Signature: подпись токена, созданная с помощью секретного ключа.
- Используйте HTTPS для защиты передачи данных.

7. Реализация (Implementation)
- Клиент-серверный обмен: клиент отправляет запросы, сервер обрабатывает их и взаимодействует с базой данных.
- Redis: используйте для кэширования часто запрашиваемых данных, что ускоряет отклик API.
- База данных: храните основные данные приложения.

8. Структура запросов и ответов
- Соблюдайте чёткую структуру запросов и ответов, используйте JSON для передачи данных.
- Ответы должны содержать понятные сообщения об ошибках и метаданные (например, статус операции).

9. Использование HTTP-методов
- Выбирайте HTTP-метод в зависимости от операции:
- GET — для получения данных (идемпотентен);
- POST — для создания новых ресурсов (не идемпотентен);
- PUT — для полного обновления ресурса (идемпотентен);
- PATCH — для частичного обновления ресурса (не идемпотентен);
- DELETE — для удаления ресурса.

10. Документирование API
- Документируйте все эндпоинты, методы, параметры запросов и ответов, коды ошибок. Это облегчает использование API разработчиками.

Что такое sharding (шардинг)?
(продолжение в следующем посте)

Что такое sharding (шардинг)?
(продолжение предыдущего поста)

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

Разберём подробно различные стратегии и типы шардинга.

#### 1. Типы шардинга

а) Вертикальный шардинг (Vertical)
- Суть: разбиение базы данных по столбцам (колонкам), а не по строкам.
- Пример на изображении: исходная таблица с колонками ID, First Name, Last Name разделена на две части:
- Partition 1: содержит ID и First Name;
- Partition 2: содержит ID и Last Name.
- Применение: подходит для случаев, когда к определённым колонкам обращаются чаще, чем к другим (например, данные аутентификации пользователей в одном шарде, а журналы активности — в другом).

б) Горизонтальный шардинг (Horizontal)
- Суть: разделение базы данных по строкам (а не по колонкам), при этом каждая строка хранится только в одном шарде.
- Пример на изображении: данные распределены по нескольким шардам, каждый из которых содержит подмножество строк исходной таблицы.
- Применение: идеально для приложений с большим объёмом данных, где строки можно сегментировать (например, по географическим регионам или идентификаторам пользователей).

#### 2. Стратегии шардинга

а) Range Based Sharding (шардинг на основе диапазона значений)
- Суть: данные распределяются по шардам в зависимости от диапазона значений определённого поля (например, возраста).
- Пример на изображении: таблица с полем Age разделена на три диапазона:
- 20 < Age ≤ 30: содержит только запись Rohit (28);
- 30 < Age ≤ 40: содержит записи Alex (32), Adam (34), Foo (36);
- 40 < Age ≤ 50: содержит записи John (45), Anshu (50).
- Особенности: может приводить к неравномерному распределению нагрузки (некоторые шарды перегружены, другие — недогружены).
- Применение: подходит для данных с временными метками или последовательных данных (журналы, события).

б) Key Based Sharding (шардинг на основе ключа)
- Суть: использование хэш-функции для распределения данных по шардам. Хэш-функция принимает ключ (например, ID) и возвращает значение, определяющее, в какой шард попадёт запись.
- Пример на изображении: используется функция ID % 3, которая вычисляет хэш-значение для каждого ID:
- ID 1 → Hash = 1 % 3 = 1 → попадает в Shard #1;
- ID 2 → Hash = 2 % 3 = 2 → попадает в Shard #2;
- ID 3 → Hash = 3 % 3 = 0 → попадает в Shard #3;
- и так далее.
- Особенности: обеспечивает более равномерное распределение данных по шардам.
- Применение: подходит для систем, где важна балансировка нагрузки (например, хранение пользовательских сессий).

в) Directory Based Sharding (шардинг на основе каталога)
- Суть: используется специальная служба (каталог), которая отслеживает, в каком шарде хранятся те или иные данные. Каталог сопоставляет ключи шардов с их местоположением.
- Пример на изображении: таблица ID | Map показывает, в каком шарде хранится каждая запись:
- ID 1 → Map 1 → Shard #1;
- ID 2 → Map 3 → Shard #3;
- ID 3 → Map 1 → Shard #1;
- и так далее.
- Особенности: позволяет работать с неравномерным распределением данных и сложными критериями разбиения.
- Применение: подходит для сложных систем с динамическим распределением данных.

#### 3. Ключевые особенности шардинга, отражённые на изображении

- Независимость шардов: каждый шард работает автономно, запросы к одному шарду не влияют на производительность других.
- Распределение нагрузки: данные распределены между серверами, что снижает нагрузку на отдельные серверы и ускоряет обработку запросов.
- Масштабируемость: горизонтальное масштабирование позволяет добавлять новые шарды по мере роста объёма данных.
- Высокая доступность: сбой одного шарда не приводит к потере всей базы данных — недоступны будут только данные этого шарда.

Распространенные команды для анализа логов на Linux

Роб Пайк (один из ключевых создателей языка Go, один из разработчиков Unix, в частности, создал первую граф. систему окон для Unix) в своём канале в bluesky в ответ на сообщение, отправленное от лица LLM-модели Claude Opus, эмоционально выразил своё отношение к ИИ и их роли в современной мире:

«Идите [к чёрту], ребята. Вы насилуете нашу планету, тратите триллионы на токсичное, неперерабатываемое оборудование, разрушая при этом основы общества, но ещё находите время, чтобы заставить свои злобные машины поблагодарить меня за моё стремление к более простым программам.

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

Просто валите [к чёрту]. Проваливайте все.

Не помню, когда я последний раз был так зол.

У всех остальных же я прошу прощения за своё, пусть ненамеренное и скорее незначительное, участие в реализации этого насилия против человечества.»

https://bsky.app/profile/robpike.io/post/3matwg6w3ic2s

Как работает NAT (Network Address Translation)
(продолжение в следующем посте)

Как работает NAT (Network Address Translation)
(продолжение предыдущего поста)

1. Основная задача NAT

NAT — это технология, позволяющая нескольким устройствам в локальной сети (LAN) использовать один публичный IP-адрес. Это достигается путём изменения IP-адресов в заголовках пакетов данных при их передаче через маршрутизатор (NAT-шлюз).

2. Компоненты, показанные на изображении

На схеме представлены:
* Локальные устройства с частными IP-адресами (например, 192.168.0.13, 192.168.0.25, 192.168.0.30) — устройства внутри локальной сети.
* NAT-шлюз (роутер) — устройство, выполняющее преобразование адресов. Ему присвоен публичный IP-адрес (184.28.207.5).
* Публичный IP-адрес (184.28.207.5) — адрес, видимый в интернете.
* Таблица NAT — хранит соответствие между частными IP-адресами и портами локальных устройств и преобразованными публичными адресами и портами.
* Внешний ресурс (например, DNS-сервер 8.8.8.8) — цель запроса из локальной сети.

3. Процесс работы NAT по шагам

Шаг 1. Исходный пакет (до трансляции)

Когда устройство в локальной сети (например, с IP 192.168.0.13) отправляет запрос в интернет (например, к DNS-серверу 8.8.8.8:53), пакет имеет:
* Source IP & Port (исходный IP и порт): 192.168.0.13:1000 (локальный адрес и порт устройства).
* Destination IP & Port (целевой IP и порт): 8.8.8.8:53 (адрес и порт сервера в интернете).

Шаг 2. Преобразование адреса NAT-шлюзом

NAT-шлюз перехватывает пакет и изменяет его заголовки:
* Заменяет локальный IP-адрес (192.168.0.13) на свой публичный IP-адрес (184.28.207.5).
* Заменяет локальный порт (1000) на уникальный публичный порт (например, 10000), чтобы различать соединения от разных устройств.
* Сохраняет соответствие «локальный IP:порт → публичный IP:порт» в таблице NAT.

Шаг 3. Пакет после трансляции

После преобразования пакет выглядит так:
* Source IP & Port: 184.28.207.5:10000 (публичный IP и порт NAT-шлюза).
* Destination IP & Port: 8.8.8.8:53 (не изменяется — это адрес цели).

Шаг 4. Ответ от сервера

Когда сервер (8.8.8.8) отвечает, он отправляет данные на публичный IP и порт (184.28.207.5:10000).

Шаг 5. Обратная трансляция

NAT-шлюз:
* Проверяет таблицу NAT и находит запись: «184.28.207.5:10000 → 192.168.0.13:1000».
* Преобразует публичный IP и порт обратно в локальные.
* Передаёт ответ устройству с IP 192.168.0.13.

4. Таблица NAT

Таблица NAT хранит соответствия для всех активных соединений, например:
* 192.168.0.13:1000 ↔️ 184.28.207.5:10000;
* 192.168.0.25:2000 ↔️ 184.28.207.5:20000;
* 192.168.0.30:3000 ↔️ 184.28.207.5:30000.

5. Итог

Благодаря NAT:
* Несколько устройств используют один публичный IP-адрес.
* Локальные IP-адреса скрыты от интернета — это повышает безопасность сети.
* Маршрутизатор управляет трафиком, преобразуя адреса «на лету».

Таким образом, NAT обеспечивает экономию IP-адресов и защиту локальной сети.

Расспространенные алгоритмы криптографии/шифрования

Hashing Algorithms (используются для контрольных сумм, обеспечения целостности данных и хранения паролей):
1. MD5 — быстрая функция хеширования, но небезопасна из-за коллизий.
2. SHA-1 — более безопасна, чем MD5, но сейчас взломана (не использовать в новых системах).
3. SHA-256 — часть семейства SHA-2, широко используется и безопасна.
4. SHA-512 — более длинная версия SHA-256, обеспечивает повышенную безопасность.
5. BLAKE2 — быстрее и безопаснее SHA-2, современная альтернатива.
6. RIPEMD-160 — альтернатива SHA, используется для генерации адресов в Bitcoin.
7. CRC32 — лёгкий алгоритм хеширования для обнаружения ошибок, но не криптографически безопасен.

Алгоритмы хеширования паролей и вывода ключей (используются для безопасного хранения или получения ключей из паролей):
8. bcrypt — алгоритм хеширования паролей, специально замедленный для защиты от перебора.
9. scrypt — хеширование паролей с высокой нагрузкой на память, лучше защищён от ASIC-устройств по сравнению с bcrypt.
10. Argon2 — современный рекомендуемый стандарт хеширования паролей (победитель конкурса PHC).
11. PBKDF2 — итеративная функция вывода ключей, используется во многих защищённых системах.
12. HKDF — функция вывода ключей на основе HMAC, используется в TLS, Signal.

Алгоритмы симметричного шифрования (один и тот же ключ используется для шифрования и дешифрования):
13. AES (Advanced Encryption Standard) — промышленный стандарт симметричного шифрования (128, 192, 256 бит).
14. ChaCha20 — быстрый и безопасный потоковый шифр, используется в мобильных и ограниченных устройствах.
15. 3DES — тройной стандарт шифрования данных, устарел и небезопасен.
16. Blowfish — блочный шифр старого образца, заменён более безопасными вариантами, такими как AES.
17. Twofish — преемник Blowfish, был кандидатом на роль AES, но не был выбран.
18. RC4 — небезопасный потоковый шифр, не использовать в новых системах.

Алгоритмы асимметричного (с открытым ключом) шифрования (используют пару открытый/закрытый ключ для шифрования и дешифрования):
19. RSA — классический алгоритм шифрования с открытым ключом, широко используется в TLS и для подписей.
20. DSA (Digital Signature Algorithm) — алгоритм цифровой подписи, в основном заменён более новыми вариантами.
21. Diffie-Hellman — алгоритм обмена ключами, позволяет обмениваться секретами без их раскрытия.
22. Elliptic Curve Cryptography (ECC) — более безопасен при использовании меньших ключей, применяется в современных системах.
23. Ed25519 — высокопроизводительный алгоритм цифровых подписей на эллиптических кривых.
24. ECDSA — вариант DSA на эллиптических кривых, используется в Bitcoin, Ethereum и TLS.
25. X25519 — быстрый алгоритм обмена ключами Diffie-Hellman на эллиптических кривых.

Цифровые подписи и обеспечение целостности:
26. HMAC (Hash-based Message Authentication Code) — объединяет хеш с секретным ключом для обеспечения целостности.
27. RSA Signatures — подписывание данных с помощью закрытого ключа, чтобы другие могли проверить с помощью открытого ключа.
28. EdDSA — схема подписи, использующая скрученные кривые Эдвардса (например, Ed25519).
29. MAC (Message Authentication Code) — подтверждает, что данные не были изменены, аналогично HMAC.

Режимы работы (для блочных шифров, таких как AES) (определяют, как блочные шифры обрабатывают данные, превышающие размер блока):
30. ECB (Electronic Codebook) — небезопасен; одинаковые блоки открытого текста дают одинаковый шифротекст.
31. CBC (Cipher Block Chaining) — использует вектор инициализации (IV) для добавления случайности к блокам.
32. CTR (Counter Mode) — преобразует блочный шифр в потоковый шифр.
33. GCM (Galois/Counter Mode) — режим AES с встроенной аутентификацией (используется в TLS).
34. CFB (Cipher Feedback Mode) — преобразует блочный шифр в самосинхронизирующийся потоковый шифр.
35. OFB (Output Feedback Mode) — преобразует блочный шифр в синхронный потоковый шифр.

Масштабирование чтения и записи в веб-приложении
(продолжение в следующем посте)

Масштабирование чтения и записи в веб-приложении
(продолжение предыдущего поста)

Масштабирование операций чтения и записи являются частыми задачами в веб-приложении по мере увеличения нагрузки. Рассмотрим распространенные стратегии масштабирования операций чтения и записи.

1) Стратегии масштабирования чтений (проще)

Цель: Эффективно обрабатывать большой объём запросов на чтение.

Внутренний кэш (уровень приложения)
* кэш в оперативной памяти (например, локальный словарь, кэш LRU внутри экземпляра приложения);
* предотвращает повторные вычисления, но не распределяется между экземплярами.

Кэш в оперативной памяти (Redis, Memcached)
* хранит часто запрашиваемые данные в ОЗУ для сверхбыстрого доступа;
* сокращает количество запросов к базе данных, улучшая время отклика;
* оптимален для нагрузок с большим объёмом чтений (например, пользовательские сессии, предварительно вычисленные данные).

Копии для чтения (Read Replicas)
* множественные копии основной базы данных обрабатывают запросы на чтение;
* распределяет нагрузку от чтения по нескольким узлам;
* подходит для аналитических панелей и приложений с большим объёмом контента.

Сеть доставки контента (CDN — Content Delivery Network)
* кэширует статические ресурсы (изображения, видео, HTML) на периферийных узлах;
* сокращает задержки за счёт предоставления данных с ближайшего узла.

2) Стратегии масштабирования записей (сложнее)

Цель: Распределить нагрузку от записи и сохранить согласованность данных.

Шардинг (сегментация)
* разделяет данные по нескольким базам данных на основе ключа (например, ID пользователя);
* предотвращает перегрузку одной базы данных;
* требует тщательного проектирования запросов, чтобы избежать обращений к нескольким сегментам.

CQRS (разделение ответственности за команды и запросы — Command Query Responsibility Segregation)
* разделяет модели чтения и записи по разным базам данных или сервисам;
* позволяет оптимизировать нагрузки с большим объёмом записи и чтения отдельно.

Архитектура, управляемая событиями (Event-Driven Architecture)
* вместо прямых записей в БД публикуются события, которые обрабатываются асинхронно;
* помогает разделить сервисы и распределить нагрузку от записи;
* пример: сервис заказов отправляет событие «Заказ создан» → сервис инвентаризации асинхронно обновляет остатки.

Базы данных, оптимизированные для записи (Write-Optimized Databases)
* используют механизмы хранения с логической структурой (например, LSM-деревья в Cassandra, RocksDB) для нагрузок с большим объёмом записи;
* полезны в случаях высокочастотных операций (например, торговые системы, системы журналирования).

Что в итоге:
* Масштабирование чтений проще добавить позже.
* Масштабирование записей нужно проектировать на раннем этапе, чтобы избежать сложностей с рефакторингом.

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