Как выбрать базу данных
(продолжение предыдущего поста)

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

1. Определение типа данных («What type of data do you have?»):
* Структурированные (Structured) — данные с чёткой схемой (таблицы, столбцы, строки). Примеры: транзакции, аналитика.
* Полуструктурированные (Semistructured) — данные с некоторой структурой, но без жёсткой схемы (например, JSON, XML).
* Неструктурированные (Unstructured) — данные без явной структуры (текст, изображения, видео).

2. Выбор базы данных в зависимости от типа данных:
* Для структурированных данных:
* OLTP (Transactions) — используйте Relational DB (например, PostgreSQL, MySQL) для транзакционных операций (быстрые вставки, обновления, удаления).
* OLAP (Analytics) — выбирайте Columnar DB (например, Amazon Redshift, Vertica) для аналитических запросов (агрегации, сложные выборки).
* Для неструктурированных данных — используйте Object Store (хранилище объектов, например, Amazon S3) для хранения файлов, медиа.
* Для полуструктурированных данных — переходите к следующему шагу («Semistructured»).

3. Для полуструктурированных данных («Semistructured») — уточните сценарий использования:
* Dictionary-style (словарный стиль) — данные представлены в виде пар «ключ-значение».
* Если используется как кэш («Is it used as a cache?») — выбирайте In-memory DB (например, Redis) для быстрого доступа.
* Если не используется как кэш — переходите к следующему варианту.
* Nested Objects (вложенные объекты) — выбирайте Document Store (например, MongoDB, Couchbase) для хранения документов с вложенной структурой.
* Text Search (поиск по тексту) — используйте Text Search DB (например, Elasticsearch) для полнотекстового поиска.
* Entity / Relationships (сущности и связи) — выбирайте Graph DB (например, Neo4j) для моделирования графовых структур (социальные сети, маршруты).
* Two Dimensional Key Value (двумерные пары «ключ-значение») — используйте специализированные Key-Value DB (например, Riak).

4. Уточнение по паттерну доступа («What is the access pattern?») для некоторых типов:
* Time-based (временные ряды) — выбирайте Time-series DB (например, InfluxDB) для хранения и анализа временных данных (логи, метрики).
* Location data (данные о местоположении) — используйте Geospatial DB (например, PostGIS) для геоданных (карты, маршруты).
* Wide schema (широкая схема) — выбирайте Wide-column DB (например, Cassandra) для хранения больших объёмов данных с переменной структурой.

Итог: выбор базы данных зависит от:
* типа данных (структурированные, полуструктурированные, неструктурированные);
* сценария использования (транзакции, аналитика, кэш, поиск и т. д.);
* паттерна доступа к данным (временные ряды, геоданные, широкая схема и др.).

Внедрение ИИ приведет к найму специалистов начального уровня, считают руководители компаний

Генеральные директора крупных публичных компаний считают, что распространение искусственного интеллекта приведёт к постепенному возвращению найма специалистов начального уровня. Об этом свидетельствуют результаты опроса топ‑менеджеров, проведённого консалтинговой компанией Teneo.

В исследовании приняли участие более 350 генеральных директоров публичных компаний с годовой выручкой свыше $1 млрд, а также около 400 крупных институциональных инвесторов. 67% респондентов заявили, что внедрение ИИ приведёт к росту найма на начальные позиции уже в следующем году. При этом 58% опрошенных сообщили о планах по найму специалистов на сеньорские и управленческие позиции.

Согласно докладу Teneo, рост найма может быть обусловлен стремлением компаний увеличить число сотрудников, непосредственно работающих с технологиями искусственного интеллекта. Кроме того, по мере внедрения ИИ и автоматизации процессов происходит трансформация и перераспределение существующих ролей. В результате ИИ не уничтожает рабочие места, а скорее видоизменяет их, отмечают в Teneo.

https://www.businessinsider.com/ai-hiring-comeback-entry-level-jobs-ceo-teneo-survey-2025-12?IR=T

Сравнение Rust vs C++

Наглядно про файловую систему в Linux

Обязательную идентификацию владельцев доменов через «Госуслуги» утвердили в Госдуме

Комитет Госдумы по информполитике рекомендовал к принятию законопроект, вводящий обязательную идентификацию владельцев всех доменов в зонах .ru и .рф через «Госуслуги» и создание правительственного реестра аккредитованных регистраторов.
Вступить в силу нормы о новом порядке регистрации доменов могут с 1 сентября 2026 года.

https://www.kommersant.ru/doc/8293585

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

Что такое дескриптор процесса в Linux
(продолжение предыдущего поста)

Дескриптор процесса (process denoscriptor) в Linux — это централизованная структура данных (task_struct), которая содержит всю необходимую информацию о процессе и которая позволяет ядру Linux эффективно управлять процессами, их ресурсами и взаимодействием в многозадачной среде.. Он служит «паспортом» процесса: хранит его состояние, параметры, ссылки на ресурсы и связи с другими процессами и структурами ядра.

#### Структура дескриптора (task_struct)

На изображении представлена схема дескриптора процесса. Он состоит из множества полей, среди которых:

1. `state` — текущее состояние процесса (например, выполняется, спит, завершён).
2. `*stack` — указатель на стек процесса (область памяти для хранения локальных переменных и вызовов функций).
3. `flags` — битовые флаги, определяющие свойства процесса (например, приоритет, режим выполнения).
4. `*mm` — указатель на структуру mm_struct, описывающую виртуальную память процесса (включая таблицу страниц и PGD — Page Global Directory).
5. `exit_code` — код завершения процесса (используется для передачи статуса завершения родительскому процессу).
6. `*user` — ссылка на user_struct, содержащую информацию о пользователе, запустившем процесс.
7. `pid` — идентификатор процесса (Process ID), уникальный в рамках системы.
8. `*files` — указатель на files_struct, описывающий открытые файлы и ресурсы (файловые дескрипторы).
9. `*parent` — ссылка на дескриптор родительского процесса (важно для иерархии процессов).
10. `*signal` — указатель на signal_struct, хранящую информацию о сигналах, направленных процессу.

#### Связи с другими структурами ядра

Дескриптор процесса не ограничивается только внутренними полями — он содержит указатели на другие ключевые структуры ядра:

- `mm_struct` — управляет виртуальной памятью процесса, включая таблицы страниц (pgd — указатель на глобальную директорию страниц) и связь с физической памятью (pagedir[]).
- `user_struct` — хранит данные о пользователе (UID, GID и т. д.), от имени которого запущен процесс.
- `files_struct` — описывает открытые файлы, сокеты и другие ресурсы, доступные процессу.
- `signal_struct` — содержит информацию о сигналах (например, SIGTERM, SIGINT), которые могут быть отправлены процессу.

#### Зачем нужен дескриптор процесса?

1. Управление процессами: ядро использует дескриптор для планирования, переключения контекста, синхронизации и завершения процессов.
2. Изоляция ресурсов: каждый процесс имеет свой дескриптор, что обеспечивает защиту памяти и ресурсов.
3. Взаимодействие процессов: через поля *parent, *signal и другие реализуется связь между процессами (например, передача сигналов, ожидание завершения дочерних процессов).
4. Учёт и аудит: дескриптор хранит данные для логирования (PID, пользователь, код завершения).

65% разработчиков используют ИИ-ассистенты. Теперь некоторые не могут кодить без них

Считается, что программирование с использованием ИИ обеспечивает разработчикам программного обеспечения беспрецедентный прирост производительности.
Например, согласно опросу Stack Overflow, около 65% разработчиков используют инструменты на основе ИИ еженедельно. Это связано с возможностью быстрого написания тестов, исправления ошибок и объяснения незнакомого кода.

Однако исследование показало, что хотя некоторые разработчики сообщают о значительных улучшениях продуктивности, объективные тесты демонстрируют замедление процесса программирования на 19%.

Так, в статье приводится пример инженера из компании Companion Group по имени Лучано Нойен, который активно пользовался ИИ-ассистентами на основной работе — там их предоставляли бесплатно. Но когда он начал сторонний проект без доступа к этим инструментам, то обнаружил, что не справляется с задачами, которые раньше решал автоматически. "Я чувствовал себя таким тупым, — признается Нойен. — Вещи, которые раньше были инстинктом, превратились в ручную, иногда даже громоздкую работу". По его мнению, сохранить навыки можно только как спортсменам — регулярно практикуя базовые упражнения.

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

В добавок по прежнему существуют большие технические ограничения при использовании ИИ: большие языковые модели имеют ограниченную рабочую память ("контекстное окно"), что затрудняет обработку крупных кодовых баз и ведет к ошибкам.

Некоторые считают, что технологии позволяют сосредоточиться на стратегических аспектах проектирования, другие же разочарованы невозможностью достичь существенного роста продуктивности.
Например, по словам Нико Вестердейла, CTO ветеринарной компании IndeVets, чтобы получить максимум от ИИ-инструментов, разработчикам придется отказаться от контроля над отдельными строками кода и сосредоточиться на архитектуре. Это принципиально другой набор навыков — и пока непонятно, как к нему готовить следующее поколение программистов, если джуниорские позиции исчезают быстрее, чем появляются новые карьерные траектории.

https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/

Архитектурный паттерн Command Query Responsibility Segregation (CQRS)
(продолжение в следующем посте)

Архитектурный паттерн Command Query Responsibility Segregation (CQRS)
(продолжение предыдудщего поста)

→ CQRS — это архитектурный шаблон, разделяющий операции чтения (запросы) и операции записи (команды).
→ Команды изменяют состояние системы.
→ Запросы лишь считывают данные и никогда их не модифицируют.
→ Такое разделение позволяет каждой из сторон масштабироваться, оптимизироваться и развиваться независимо.

Основные понятия

→ Команда — действие, изменяющее данные (*CreateOrder*, *UpdateProfile*).
→ Запрос — запрос, извлекающий данные (*GetOrderById*, *ListUsers*).
→ Модель записи — обрабатывает бизнес‑правила, валидацию и изменения состояния.
→ Модель чтения — оптимизирована для быстрого извлечения данных (часто денормализованная).

Как это работает

→ Клиент отправляет команду → Обработчик команд → Модель записи → База данных.
→ Клиент отправляет запрос → Обработчик запросов → Модель чтения → Оптимизированное хранилище для чтения.
→ Команды и запросы используют раздельные пути и могут работать с разными базами данных.

Простая аналогия: банковская система

→ Команды = Внесение или снятие денег (изменяет баланс).
→ Запросы = Проверка баланса счёта или истории операций (только чтение).
→ Вы не обновляете баланс при его проверке — обязанности чётко разделены.

Преимущества

→ Повышенная производительность для систем с высокой нагрузкой на чтение.
→ Независимое масштабирование операций чтения и записи.
→ Чёткое разделение обязанностей.
→ Упрощённая оптимизация моделей данных для конкретных сценариев использования.
→ Хорошая совместимость с системами, управляемыми событиями.

Недостатки

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

Лучшие практики

→ Применяйте CQRS только тогда, когда сложность оправдана.
→ Сочетайте CQRS с Event Sourcing, если требуется аудит.
→ Делайте команды сфокусированными на задаче и явными.
→ Оптимизируйте модели чтения под нужды интерфейса, а не ради чистоты домена.
→ Грамотно обрабатывайте возможную несогласованность данных в интерфейсе.

Когда применять

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

Генеральный директор Amazon Web Services Мэтт Гарман назвал «одной из самых глупых идей» сокращение вакансий для начинающих разработчиков из‑за внедрения ИИ.

По словам Гармана, полная замена младших сотрудников искусственным интеллектом не имеет никакого смысла, поскольку такие сотрудники зачастую лучше разбираются в инструментах ИИ ввиду своей молодости. Нынешние выпускники вузов выросли в эпоху новых технологий, поэтому им проще адаптироваться, говорит гендиректор AWS. Как правило, молодые специалисты находят новые быстрые способы написания кода и выясняют, как добиться наилучших результатов работы от ИИ‑агентов.

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

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

https://www.wired.com/story/the-big-interview-podcast-matt-garman-ceo-aws/

Символы ASCII вместо графики как основа для создания видеоигр

Система видеонаблюдения на основе ИИ ввела режим изоляции в средней школе имени Лоутона Чайлза в штате Флорида после того, как приняла за оружие кларнет ученика.
Прибывшая полиция объявила о прекращении режима изоляции, указав, что детям ничего не угрожало.

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

Аналогичный случай произошел в штате Мэриленд: там школьная система безопасности на базе ИИ приняла за пистолет пачку чипсов Doritos в руках старшеклассника. В двух этих случаях системы позволили ИИ принять решения без какого-либо вмешательства со стороны человека.

https://futurism.com/future-society/ai-surveillance-school-clarinet

Шпаргалка по командам для тестирования и отладки сети в Windows, Linux и MacOS

C++: Расположение данных в памяти и директивы компилятора
(продолжение в следующем посте)