Вышла новая версия языка 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) для нагрузок с большим объёмом записи;
* полезны в случаях высокочастотных операций (например, торговые системы, системы журналирования).

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

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

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

Жизненный цикл разработки ПО включает несколько моделей, каждая из которых предлагает свой подход к этапам создания продукта. Каждая модель жизненного цикла разработки ПО имеет свои преимущества и недостатки, выбор зависит от:
* сложности и масштаба проекта;
* гибкости требований;
* сроков разработки;
* вовлечённости заказчика;
* доступных ресурсов.

Рассмотрим основные модели:

1. Waterfall (Каскадная модель):
* Последовательность этапов: анализ → проектирование (design) → разработка (build) → тестирование (test) → развёртывание (deploy).
* Особенности: строгая последовательность, переход к следующему этапу только после завершения предыдущего. Подходит для проектов с чётко определёнными требованиями (например, электронная коммерция).
* Итог: структурированный и предсказуемый процесс, но менее гибкий к изменениям.

2. Spiral (Спиральная модель):
* Структура: комбинация каскадного и итеративного подходов. Этапы повторяются в виде спирали: оценка → планирование → разработка → тестирование.
* Ключевые элементы: оценка рисков, поэтапная разработка, тестирование на каждом витке спирали.
* Применение: проекты с высоким уровнем неопределённости и риска, длительные циклы разработки.
* Итог: баланс между гибкостью и контролем рисков.

3. Agile (Гибкая модель):
* Основа: итеративные циклы (спринты), быстрая адаптация к изменениям.
* Этапы: серия спринтов, в каждом из которых разрабатывается часть функционала.
* Фокус: сотрудничество с клиентом, быстрая обратная связь, поэтапная поставка рабочих версий ПО.
* Применение: динамичные рынки, стартапы, проекты с неясными требованиями.
* Итог: высокая адаптивность, но требует активного участия заказчика.

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

5. V-Model (V-образная модель):
* Структура: усовершенствованная каскадная модель с акцентом на тестирование. Этапы разработки «зеркальны» этапам тестирования.
* Этапы разработки: бизнес-требования → системные требования → высокоуровневый дизайн → низкоуровневый дизайн → кодирование.
* Этапы тестирования: приёмочное тестирование → системная интеграция → компонентное тестирование → модульное тестирование.
* Применение: проекты с жёсткими требованиями к качеству (аэрокосмическая отрасль, здравоохранение).
* Итог: тщательная проверка на каждом этапе, минимизация ошибок.

6. Incremental (Инкрементальная модель):
* Принцип: разработка ПО частями (инкрементами), каждый из которых добавляет новый функционал.
* Этапы: анализ → проектирование → кодирование → тестирование → развёртывание (повторяется для каждого инкремента).
* Применение: проекты с ограниченными ресурсами, когда нужно быстро предоставить рабочую версию ПО.
* Итог: поэтапная поставка функционала, гибкость в управлении требованиями.

7. Big Bang (Модель «Большого взрыва»):
* Суть: отсутствие чёткого планирования, разработка начинается с накопления ресурсов и идей, затем происходит «взрыв» активности.
* Этапы: накопление ресурсов → разработка → тестирование → продукт.
* Применение: небольшие проекты с креативным подходом, когда требования не определены заранее.
* Риски: высокий риск срыва сроков и бюджета из-за отсутствия структуры.

8. RAD (Rapid Application Development — быстрая разработка приложений):
* Основа: итеративный и инкрементальный подход с акцентом на быстрое создание прототипов.
* Этапы: анализ и быстрый дизайн → разработка прототипа → демонстрация → доработка → тестирование → развёртывание.
* Применение: проекты с быстро меняющимися требованиями, необходимость быстрого выхода на рынок.
* Итог: ускоренная разработка за счёт активного вовлечения заказчика и использования прототипов.

Наглядно, что такое интеграл

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

Выполнение программы
(продолжение предыдущего поста)

Программа проходит путь от исходного кода до исполняемого файла, загружается в память, взаимодействует с ОС через системные вызовы, использует ресурсы компьютера (CPU, память, устройства) и завершается с очисткой всех задействованных ресурсов. Рассмотрим пошагово.

1. Компиляция и загрузка программы (Program Compilation and Loading)

- Исходный код (например, Enter.c) передаётся компилятору.
- Компилятор преобразует исходный код в объектный файл (Enter.obj), проверяя синтаксис и семантику.
- Используются библиотеки (например, cw32.lib), из которых извлекаются необходимые функции (например, sprintf()).
- Происходит статическая компоновка — связывание объектного файла с библиотеками для создания промежуточного кода.
- Далее подключается динамическая компоновка — связывание с динамическими библиотеками (user32.dll и др.), используемыми для функций вроде MessageBox().
- В итоге формируется исполняемый файл (Enter.exe), готовый к запуску.

2. Взаимодействие пользователя и распределение памяти (User Interaction and Memory Allocation)

- Пользователь запускает программу через графический интерфейс (например, клик по иконке).
- Операционная система (ОС) получает запрос и инициирует загрузку исполняемого файла.
- ОС выделяет память для программы, используя структуру памяти:
- Memory pool (пул памяти) — общее пространство для распределения.
- Stack (стек) — для хранения локальных переменных и вызовов функций.
- Heap (куча) — для динамического выделения памяти (malloc, free).
- Сегменты: BSS (неинициализированные данные), Data (инициализированные данные), Code (исполняемый код).
- Программа загружается в выделенную область памяти.

3. Системные вызовы (System Calls)

- Программа взаимодействует с ОС через системные вызовы (system call), которые обеспечивают доступ к ресурсам (файлам, сети, устройствам).
- Процесс вызова:
1. Программа делает системный вызов (например, открытие файла).
2. Управление передаётся ядру ОС (kernel model), которое проверяет права доступа и параметры вызова.
3. Ядро выполняет операцию через сервисные программы (например, чтение данных с диска).
4. Результат возвращается программе, которая продолжает выполнение.
- Таблица системных вызовов (Sys_call_table) хранит адреса функций ядра.

4. Состояние ЦП и структура памяти (CPU Status and Memory Structure)

- Программа выполняется на центральном процессоре (CPU), который работает в двух режимах:
- Пользовательский режим (user model) — выполнение прикладного кода.
- Режим ядра (kernel model) — выполнение системных вызовов и привилегированных операций.
- Кэширование: CPU использует кэши (L1, L2, L3) для ускорения доступа к данным.
- RAM хранит исполняемый код и данные программы во время работы.
- Регистры программ (Program register) сохраняют состояние выполнения (адрес следующей инструкции).

5. Архитектура фон Неймана (Von Neumann Architecture)

- Программа и данные хранятся в единой памяти (принцип фон Неймана).
- Центральный процессор (CPU) состоит из:
- Control Unit (CU) — управляет выполнением инструкций.
- Arithmetic/Logic Unit (ALU) — выполняет арифметические и логические операции.
- Данные поступают с устройств ввода (Input Device), обрабатываются процессором и выводятся на устройства вывода (Output Device).
- Memory Unit хранит промежуточные результаты и инструкции.

6. Завершение программы и освобождение ресурсов (Program Termination and Resource Recovery)

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

В Думу внесли законопроект о подтверждении для сайтов значимых действий

Правительство внесло в Госдуму законопроект № 1110676-8, который с 1 сентября 2026 года вводит для российских сайтов обязательное подтверждение значимых действий в интернете кодами из СМС и одновременно сообщениями с использованием мессенджера Max. Перечень таких действий утвердит правительство.
В банковской и иных сферах финансового рынка перечень значимых действий будет дополнительно согласовываться с Банком России.
https://www.interfax.ru/russia/1065345