Вышла новая версия среды разработки Qt Creator - Qt Creator 18. (Qt Creator предназначен для создания кроссплатформенных приложений с использованием библиотеки Qt и языков C++, Python и QML/JavaScript)

Резюме изменений в Qt Creator 18

1. Поддержка контейнеров разработки: Добавлена экспериментальная поддержка контейнеров разработки ("Development Containers") для автоматизации настройки среды проекта. Контейнеры создаются на основе файла "devcontainer.json" и позволяют автоматически настраивать наборы инструментов (kits).

2. Обзорная вкладка "Overview": Новый интерфейс включает вкладку "Overview" на экране приветствия, объединяя полезную информацию из других вкладок. Она рекомендует учебные пособия и примеры, основываясь на потребностях разработчика, и выделяет посты разработчиков из блога Qt.

3. Интерфейс редактирования: Реализована возможность выбора редактора с вкладками. Улучшена интеграция с инструментом Clangd версии 21.1, улучшен встроенный код-моделлер для поддержки новых функций C++, добавлены быстрые исправления кода, такие как удаление фигурных скобок и автоматическое создание определений статических членов класса.

4. Работа с проектами: Файлы настроек проектов (.user) теперь хранятся в подпапке .qtcreator/, что улучшает совместимость старых проектов. Появилась возможность фильтрации отображаемых конфигураций сборки и запуска, позволяя выбирать доступные комплекты или настроенные конфигурации. Настройки построения и запуска были перемещены из окна набора инструментов в отдельные вкладки.

5. Удалённые устройства: Усовершенствована настройка удалённых устройств, позволяющая автоматически обнаруживать инструменты вроде GDB-серверов, CMake, clangd и других. Поддерживаются инструменты на удаленных устройствах Linux. Возможность автоматического подключения к устройствам при запуске IDE и использование утилиты rsync для развертывания приложений на удалённом устройстве.

6. Тестирование: Для проектов на основе CMake появилась поддержка тестовых пресетов и фильтр "ct" для запуска тестов на основе CTest.

7. Интеграция с GitHub: Подключён GitHub Copilot для корпоративных сред GitHub Enterprise.

8. Другие улучшения: Обновлён редактор коммитов для Git, позволяющий быстрее управлять файлами перед отправкой. Были устранены многие мелкие проблемы и улучшены функциональные возможности интерфейса.

https://www.qt.io/blog/qt-creator-18-released

Событийно‑ориентированная архитектура (Event-Driven Architecture )
(описание к предыдущему посту)

Обзор

→ Событийно‑ориентированная архитектура — это шаблон проектирования, при котором компоненты системы взаимодействуют и реагируют на события (изменения состояния или значимые действия).
→ Она обеспечивает асинхронное взаимодействие, что способствует масштабируемости и слабой связанности сервисов.
→ События проходят через систему, инициируя реакции без прямых зависимостей между компонентами.

Основные компоненты

→ Генератор событий — создаёт и отправляет события при наступлении определённых ситуаций (например, «Заказ оформлен»).
→ Канал событий — передаёт события от генераторов к потребителям (например, через брокеры сообщений вроде Kafka, RabbitMQ).
→ Потребитель событий — отслеживает события и выполняет действия в ответ на них (например, обновляет запасы после оформления заказа).
→ Хранилище событий — опционально сохраняет прошедшие события для аудита или повторной обработки.

Поток обработки

→ Происходит событие → Генератор публикует его в канале событий → Потребители подписываются и реагируют → Действия обрабатываются независимо.

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

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

Недостатки

→ Сложность отладки и мониторинга из‑за асинхронного поведения.
→ Возможны дублирование событий или потеря сообщений при отсутствии должной обработки.
→ Требуется надёжная инфраструктура брокеров сообщений и согласованные схемы событий.

Рекомендации к применению

→ Чёткие правила именования событий («ЗаказСоздан», «ОплатаЗавершена»).
→ Идемпотентность потребителей, чтобы избежать повторной обработки событий.
→ Централизованный журнал событий для отслеживания.
→ Реализация обработки ошибок и повторные попытки при неудачном потреблении событий.

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

→ В системах, требующих обновлений в реальном времени (финансы, IoT, электронная коммерция).
→ В микросервисных архитектурах с минимальными зависимостями между сервисами.
→ В масштабируемых системах с высокой пропускной способностью по обработке событий.

Наглядно как работает LLM

Как работает Elasticsearch
(подробное описание в следующем посте)

Как работает Elasticsearch
(описание к предыдущему посту)

Elasticsearch использует инвертированный индекс, чтобы обеспечить быстрый полнотекстовый поиск и эффективный доступ к данным.

Принцип его работы аналогичен тому, как устроен указатель в книге.

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

Мощный язык запросов DSL и эффективный механизм индексирования позволяют решать широкий спектр поисковых задач — от простых до сложных.

Чтобы лучше понять, как это работает, рассмотрим рабочий процесс системы:

1. Приём данных
→ Elasticsearch начинает с импорта данных в формате JSON — как напрямую, так и через инструменты вроде Logstash и Beats.

2. Индексирование
→ Затем система индексирует данные, создавая инвертированный индекс. Это позволяет быстро находить текстовые фрагменты, связывая термины с их местоположением в документах.

3. Шардинг и репликация
→ Система распределяет данные по узлам посредством шардирования. Репликация повышает отказоустойчивость и доступность данных.

4. Поиск
→ Язык запросов DSL позволяет пользователям выполнять поиск: система обращается к инвертированному индексу и быстро находит нужные документы.

5. Анализ и агрегация
→ Elasticsearch также даёт возможность анализировать данные и составлять сводки, выявляя тенденции и закономерности.

6. Получение результатов
→ Система извлекает и возвращает результаты запроса практически в режиме реального времени.

Ключевые преимущества Elasticsearch:
* исключительная масштабируемость;
* возможность поиска в реальном времени;
* интуитивно понятный RESTful API, который позволяет эффективно анализировать большие объёмы данных.

Благодаря обширным возможностям анализа журналов и событий система улучшает мониторинг и диагностику. Это помогает повысить безопасность и производительность приложений.

Сферы применения Elasticsearch разнообразны:
* мгновенный поиск товаров на платформах электронной коммерции;
* анализ транзакций в финансовых системах в режиме реального времени;
* системы мониторинга и журналирования — здесь Elasticsearch агрегирует и анализирует логи, давая детальную картину состояния системы и потенциальных угроз безопасности.

Кто-то предпочитает один отступ в коде, кто-то 2 или 4 отступа или табуляцию, а кто-то отступы в соответствие с числами Фибоначчи

Стратегии версионирования API
(описание в следующем посте)

Стратегии версионирования API:
(описание к предыдущему посту)

1. URI Versioning (Версионирование через URI) — добавление номера версии в URL для ясности и простоты.
Пример: /api/v1/products.

2. Path Versioning (Версионирование через путь) — версия встраивается непосредственно в путь API для наглядности.
Пример: /api/v2/products.

3. Query Parameter Versioning (Версионирование через параметры запроса) — версия указывается как параметр запроса, сохраняя чистоту структуры URL.
Пример: /api/products?version=1.

4. Subdomain Versioning (Версионирование через поддомены) — для каждой версии используются отдельные поддомены, полностью разделяя их.
Пример: v2.api.example.com/products.

5. Header Versioning (Версионирование через заголовки) — версия передаётся в заголовках запроса, URL остаётся неизменным.
Пример: GET /products Header: Accept: application/vnd.example.v1+json.

6. Timestamp Versioning (Версионирование по временным меткам) — версии основаны на временных метках, что обеспечивает гибкость при релизах.
Пример: /api/products?version=2023-10-01.

7. Content Negotiation (Согласование содержимого) — использует заголовок Accept для запроса разных версий и форматов.
Пример: GET /products Header: Accept: application/json; version=1.

8. Semantic Versioning (Семантическое версионирование) — следует семантическому версионированию (например, v1.0.0) для обозначения основных, второстепенных и патчевых изменений.
Пример: /api/products/v1.0.0.

Многие используют СУБД Postgres, но не многие знают, что Postgres предоставляет специальную утилиту для проверки производительности - explain.
Для проверки производительности работы с базой данных регулярно запускайте команды explain и explain analyze и научитесь интерпретировать их выходные данные. Это может помочь найти узкие места при запросах к БД

#sql #postgresql #database

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

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

→ 1. МНОГОУРОВНЕВАЯ (N‑УРОВНЕВАЯ) АРХИТЕКТУРА

→ Система разделена на уровни, такие как:
→ Уровень представления → Уровень бизнес‑логики → Уровень доступа к данным → База данных
→ Каждый уровень взаимодействует только с уровнем, расположенным непосредственно под ним
→ Способствует разделению ответственности и упрощает сопровождение
→ Широко применяется в корпоративных и веб‑приложениях

→ 2. АРХИТЕКТУРА «КЛИЕНТ‑СЕРВЕР»

→ Клиент отправляет запросы → Сервер обрабатывает запросы и возвращает ответы
→ Позволяет создавать распределённые системы, в которых множество клиентов взаимодействуют с централизованными серверами
→ Используется в веб‑приложениях, API и мобильных бэкендах

→ 3. АРХИТЕКТУРА МИКРОСЕРВИСОВ

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

→ 4. Событийно‑ориентированная АРХИТЕКТУРА

→ Компоненты взаимодействуют посредством событий
→ Производители генерируют события → Потребители отслеживают и реагируют на них
→ Улучшает асинхронную обработку и оперативность реагирования в реальном времени
→ Широко используется в системах потоковой передачи данных, аналитики и IoT

→ 5. СЕРВИСНО‑ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА (SOA)

→ Система строится на основе взаимодействующих сервисов
→ Каждый сервис выполняет бизнес‑функцию и взаимодействует по сети (часто через SOAP или REST)
→ Способствует повторному использованию и интеграции между системами
→ Предшественница архитектуры микросервисов

→ 6. ШАБЛОН EVENT‑SOURCING

→ Система хранит события, а не только текущее состояние
→ Каждое изменение фиксируется как неизменяемое событие в журнале
→ Позволяет вести аудит, откат и воспроизведение состояния системы
→ Часто применяется в финансовых и транзакционных системах

→ 7. CQRS (РАЗДЕЛЕНИЕ ОТВЕТСТВЕННОСТЕЙ ЗА КОМАНДЫ И ЗАПРОСЫ)

→ Разделяет операции чтения и записи
→ Команды → изменяют данные
→ Запросы → считывают данные
→ Повышает масштабируемость и поддерживает событийно‑ориентированные системы

→ 8. АРХИТЕКТУРА КОНВЕЙЕРА (ПОТОКА ДАННЫХ)

→ Данные проходят через последовательность этапов обработки
→ Каждый этап выполняет преобразование перед передачей дальше
→ Применяется в процессах ETL, обработке данных и конвейерах машинного обучения

→ 9. ОДНОРАНГОВАЯ АРХИТЕКТУРА (P2P)

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

→ 10. ПРОСТРАНСТВЕННАЯ АРХИТЕКТУРА (SPACE‑BASED)


→ Устраняет узкие места, связанные с базой данных, за счёт репликации данных в памяти (данные в гридах)
→ Подходит для систем с высокой нагрузкой и низкой задержкой, таких как платформы электронной коммерции или торговых систем

→ Краткий совет

→ Каждый архитектурный шаблон решает свои задачи:
→ Многоуровневая → простота и структурированность
→ Микросервисы → масштабируемость и независимость
→ Event-Sourcing → оперативность реагирования
→ CQRS/событийное источниковедение → согласованность и возможность аудита
→ Пространственная → производительность и отказоустойчивость

Странный способ для запоминания формул графиков, но тем не менее

Принципы SOLID
(описание в следующем посте)

Принципы SOLID
(описание к предыдущему посту)

Принципы SOLID** — краеугольный камень объектно‑ориентированного программирования. Они помогают разработчикам создавать поддерживаемые, масштабируемые и надёжные архитектуры программного обеспечения.

Эти принципы были предложены Робертом С. Мартином (Дядей Бобом), хотя на их формирование повлияли и более ранние работы.

Вот список принципов:

**1. Принцип единственной ответственности (SRP)

Каждый класс должен иметь единственную зону ответственности или фокус, что делает систему модульной и упрощает её сопровождение. Это означает, что у класса должна быть только одна причина для изменения.

Когда класс реализует единственную ответственность, изменения в спецификации, скорее всего, затронут меньшее число компонентов — и это упрощает поддержку. Кроме того, снижается связанность между различными компонентами.

Например, можно создать класс UserManager для обработки операций, связанных с пользователями: аутентификации, взаимодействия с базой данных и отправки email‑уведомлений. Если мы изменим, скажем, логику отправки email‑уведомлений, это может повлиять на другие области — например, на аутентификацию пользователей. Такие классы иногда называют «божественными классами» (*God classes*).

2. Принцип открытости/закрытости (OCP)

Программные сущности (классы, методы и т. д.) должны быть открыты для расширения, но закрыты для модификации. Это способствует стабильности и расширяемости. Иными словами, вы можете добавить новую функциональность в класс, не изменяя его существующий код.

3. Принцип подстановки Барбары Лисков (LSP)

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

4. Принцип разделения интерфейса (ISP)

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

5. Принцип инверсии зависимостей (DIP)

Модули высокого уровня не должны зависеть от модулей низкого уровня; и те, и другие должны зависеть от абстракций. Это поощряет слабосвязанную архитектуру. Кроме того, абстракции не должны опираться на детали — детали должны зависеть от абстракций.

После сокрашения штата ради ИИ компании стали возвращать сотрудников

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

Visier проанализировала данные о занятости 2,4 млн сотрудников из 142 компаний по всему миру. Около 5,3% уволенных заявляли, что они вернулись к предыдущему работодателю. Этот показатель оставался стабильным в течение нескольких лет, но недавно начал расти.

Директор Visier Андреа Дерлер отметила, что, согласно данным, многие организации теперь сталкиваются с плюсами и минусами внедрения ИИ. Она назвала искусственный интеллект удобным, но пока не полностью обоснованным объяснением увольнений.

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

Дерлер уверена, что многие руководители высшего звена просто не успели оценить фактические затраты на крупномасштабное внедрение ИИ или определить, какие роли можно автоматизировать. Внедрение инфраструктуры ИИ — оборудования, систем данных и фреймворков безопасности — требует значительных капитальных затрат. Эти затраты часто превышают первоначальные прогнозы, вынуждая руководство пересматривать фактическую окупаемость инвестиций по сравнению с удержанием квалифицированных сотрудников.
https://www.axios.com/2025/11/04/ai-jobs-layoffs-amazon