METANIT.COM

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

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

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

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

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

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

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

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

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

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

Дескриптор процесса (process descriptor) в 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, пользователь, код завершения).

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

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

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

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

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

Сервис Cloudflare (обслуживает около 20% всего мирового веб-трафика) опубликовал годовой отчёт с анализом глобальных тенденций за 2025 год. Некоторые моменты:

- Самой популярной JS-библиотекой остаётся jQuery, на втором месте - Slick.
- Самые популярные JS-фреймворки: React (37%), далее следуют Vue.js - 19%, Next.js - 16%, Nuxt.js - 8.4%, Gatsby - 4.6%, RequireJS - 2.9%
- Популярные веб-фреймворки: Next.js - 38%, Express - 21%, Nuxt.js - 20%, ASP NET - 10%, Ruby on Rails - 4.9%, Yii - 2.3%, Spring - 2.1%, Django - 0.52%
- Популярные языки программирования: PHP - 45%, node.js - 33%, Java - 15%, Ruby - 2.2%, Python - 1.9%, Perl - 0.98%, C - 0.87%
- Популярные языки для клиентов для API: Go - 20% запросов, Python - 17%, Java - 11.2%, Node.js - 8.3%, .NET - 2.3%
- Самые популярные веб-браузеры: Chrome - 66.2%, Safari - 15.4%, Edge - 7.4%, Firefox - 3.7%, Samsung Internet - 2.3%
Для РФ доля Chrome - 44%, а Yandex Browser - 33%.
https://blog.cloudflare.com/radar-2025-year-in-review/

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

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

Генеральные директора крупных публичных компаний считают, что распространение искусственного интеллекта приведёт к постепенному возвращению найма специалистов начального уровня. Об этом свидетельствуют результаты опроса топ‑менеджеров, проведённого консалтинговой компанией 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

Базовые команды по работе с Docker

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

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

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) для хранения больших объёмов данных с переменной структурой.

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

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

Руководство как выиграть в крестики-нолики

В Anthropic 27% работы выполняет ИИ, однако работники боятся потерять квалификацию

Согласно последнему отчету Anthropic, 27% работы в компании теперь выполняется ИИ. Около 60% инженеров-программистов Anthropic обращаются к ИИ почти каждый день. Чаще всего за отладкой кода, разбором незнакомых проектов и помощью в улучшении архитектуры. ИИ активно используется и для решения более сложных задач. Так, в участие ИИ в проектировании и планировании выросло с 1% до 10%, во внедрении новых функций — с 14% до 37%. Производительность труда, по оценке сотрудников, выросла примерно наполовину. Более того, Claude позволил решить задачи, которые без ИИ вообще не были бы решены: их сочли бы избыточным по затратам, отмечают в компании.

Однако работники компании утверждают, что это снижает их квалификацию. Многие сотрудники Anthropic указывают, что из-за привычки полагаться на ИИ они стали меньше тренировать базовые навыки. Один специалист отметил, что «70% времени теперь уходит на проверку и редактирование кода вместо написания». Другой предположил, что в будущем программисты будут «контролировать работу сразу нескольких Claude» вместо прямого участия в разработке.

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

https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic

Краткий совет по Linux:

Если вы хотите очистить пустые директории, команда find значительно упростит эту задачу:

find . -type d -empty -exec rmdir -v {} +

Опция -type d осуществляет поиск директорий, -empty выбирает именно пустые из них, а -exec rmdir {} запускает команду rmdir для их удаления.

Команда rmdir перед удалением проверяет, что директория действительно пуста.

В качестве альтернативы для выполнения той же задачи можно использовать следующую команду:

find . -type d -empty -delete

Добавлены вводные статьи по фреймворку PyTorch и Deep Learning
https://metanit.com/python/pytorch/
#python #pytorch #deeplearning