Кто-то предпочитает один отступ в коде, кто-то 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

Шпаргалка по фильтрам для анализатора пакетов Wireshark

Топ-6 типов моделей ИИ
(подробное описание в следующем посте)

Топ-6 типов моделей ИИ
(описание к предыдущему посту)

1. Machine Learning Models (Модели машинного обучения)
- Описание: учатся на размеченных или неразмеченных данных для выявления закономерностей, классификации или прогнозирования результатов. Включают подходы с учителем, без учителя и с частичным обучением.
- Примеры: деревья решений, Random Forest, SVM, XGBoost (с учителем); K-Means, DBSCAN, PCA (без учителя); Label Propagation, Semi-Supervised SVM (с частичным обучением).
- Рабочий процесс: сбор размеченных данных → очистка и предобработка → выбор алгоритма ML → обучение модели → мониторинг и обновление → прогнозирование на новых данных → настройка гиперпараметров → проверка производительности.

2. Deep Learning Models (Модели глубокого обучения)
- Описание: используют многослойные нейронные сети для изучения сложных иерархических паттернов, особенно эффективны для неструктурированных данных (изображения, аудио, текст).
- Примеры: CNN (для изображений), RNN, LSTM (для последовательностей), трансформеры, автоэнкодеры.
- Рабочий процесс: сбор больших объёмов данных → нормализация входных данных → построение нейронной сети → передача входных данных → вычисление ошибки предсказания → повторение циклов обучения → обновление весов → обратное распространение градиентов.

3. Generative Models (Генеративные модели)
- Описание: изучают распределение данных и генерируют новые данные, имитирующие исходные. Применяются для создания контента, синтеза изображений и генерации текста.
- Примеры: GPT-4 (текст), DALL·E, MidJourney (изображения), MusicLM (аудио), StyleGAN (лица), AlphaCode (код).
- Рабочий процесс: обучение на датасете → изучение паттернов данных → получение пользовательского ввода → обработка через модель → вывод сгенерированного медиа → уточнение с помощью обратной связи → генерация нового контента → выборка из выходных данных.

4. Hybrid Models (Гибридные модели)
- Описание: комбинируют несколько техник ИИ (например, правила + нейронные сети) для использования преимуществ каждой. Применяются там, где важны точность и контроль.
- Примеры: RAG (LLM + поиск), ML + боты на основе правил, AutoGPT с инструментами, чат-боты с API.
- Рабочий процесс: объединение типов моделей → обучение компонентов отдельно → построение логической связи → ввод через конвейер → получение конечного результата → разрешение конфликтов → агрегация выходных данных → маршрутизация на основе логики.

5. NLP Models (Модели обработки естественного языка)
- Описание: обрабатывают и понимают человеческий язык. Используются в чат-ботах, переводчиках, сумматорах и виртуальных ассистентах.
- Примеры: BERT, GPT-3.5 / GPT-4, T5, RoBERTa, Claude.
- Рабочий процесс: очистка необработанного текста → токенизация предложений → встраивание слов → применение слоёв внимания → генерация финального текста → постобработка результата → декодирование или классификация → передача в модель.

6. Computer Vision Models (Модели компьютерного зрения)
- Описание: интерпретируют визуальное содержимое, выявляя паттерны и особенности в изображениях или видео. Применяются в распознавании лиц, медицинской визуализации и др.
- Примеры: ResNet, YOLO, VGGNet, EfficientNet, Mask R-CNN.
- Рабочий процесс: загрузка данных изображений → изменение размера и нормализация → извлечение пиксельных признаков → применение слоёв CNN → вывод меток/коробок → постобработка результатов → классификация или локализация → обнаружение пространственных паттернов.

Все, что человеку нужно, - это не любовь, а математика

Как JVM в Java исполняет байт‑код
(продолжение предыдущего поста)

Вы пишете исходный код Java в файле с расширением .java.
Компилятор Java (javac) преобразует ваш код в платформонезависимый байт‑код, который сохраняется в файлах с расширением .class.
Затем виртуальная машина Java (JVM) загружает эти файлы с байт‑кодом в память для исполнения.

Во время выполнения программы:

→ Загрузчик классов (Class Loader) загружает байт‑код в JVM и обеспечивает доступность классов, когда они требуются.
→ Проверяющий байт‑код (Bytecode Verifier) анализирует код на соответствие требованиям безопасности и типовой корректности перед исполнением.
→ Интерпретатор начинает выполнять инструкции байт‑кода построчно.
→ Компилятор «точно в срок» (Just‑In‑Time, JIT) выявляет часто исполняемые участки кода (горячие точки) и компилирует их в оптимизированный машинный код для повышения производительности.
→ Сборщик мусора (Garbage Collector, GC) автоматически управляет памятью, удаляя из кучи неиспользуемые объекты.
→ Среда выполнения (Runtime Environment) предоставляет необходимые библиотеки, управление потоками и обработку исключений для бесперебойного исполнения программы.

Результат: ваша Java‑программа эффективно работает на всех платформах с использованием JVM, сочетая переносимость с оптимизацией во время выполнения и автоматическим управлением памятью.

Большая супершпаргалка по редактору Vim

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