Микросервисная архитектура
(описание в следующем посте)

Микросервисная архитектура
(описание предыдущего поста)

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

Компоненты

* Пользовательский интерфейс = Карта города / Навигационное приложение → Помогает клиентам находить нужный магазин.
* Бизнес-сервисы = Отдельные магазины → Каждый выполняет определённую задачу (платежи, заказы, доставка и т.д.).
* Коммуникации = Дороги и грузовики доставки → Позволяют магазинам обмениваться товарами (API).
* База данных = Складские помещения магазинов → Каждый магазин управляет собственным хранилищем и запасами.

Принцип работы

* Клиент посещает карту → Находит магазин → Магазин обрабатывает запрос → Использует свой склад → Клиент получает услугу/продукт.

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

* Гибкость → Каждый магазин может выбирать собственные инструменты и стиль работы.
* Масштабируемость → Популярные магазины могут расширяться, не влияя на работу других.
* Изоляция сбоев → Если один магазин закрывается, остальные продолжают работу.
* Быстрые инновации → Новые магазины могут открываться без изменения всей системы.

Недостатки

* Сложность → Чем больше магазинов, тем сложнее логистика.
* Сетевые издержки → Доставки (API-запросы) требуют времени.
* Согласованность данных → Каждый магазин управляет собственными запасами, что усложняет синхронизацию.
* Сложность мониторинга → Требуются системы управления всем городом.

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

* Используйте чёткие правила движения (стандарты API) для бесперебойной коммуникации.
* Добавьте управление трафиком (балансировщики нагрузки, обнаружение сервисов).
* Поддерживайте порядок на складах (базах данных) и создавайте резервные копии.
* Контролируйте работу магазинов с помощью централизованных инструментов (наблюдаемость, логирование).
* Проектируйте с учётом отказоустойчивости (запасные варианты, повторные попытки).

Когда использовать

* Крупномасштабные «города» (системы) с множеством различных потребностей.
* Команды, способные управлять независимыми сервисами (магазинами).
* Бизнес, которому требуется быстрое масштабирование или частые обновления функций.

Эволюция компьютеров

Интересное совпадение: инициалы основного поддерживающего библиотеку STL (Standard Library) для С++ от Microsoft - STL (Stephan T Lavavej)

Все, кто ранее называл MAX православным менеджером, оказались неправы. Теперь в России заработал действительно православный мессенджер - «Зосима»
Новый мессенджер для верующих уже можно скачать в Google Play.

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

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

https://hi-tech.mail.ru/news/134353-v-rossii-zarabotal-pravoslavnyj-messendzher-zosima/

6 основных типов тестирования API
(описание в следующей статье)

6 основных типов тестирования API:
(описание к предыдущей статье)

1. Stress Testing (Стресс-тестирование)
- Цель: Проверка устойчивости API при высоких нагрузках.
- Процесс: Использование тестовых движков для создания высоких нагрузок и анализ работы приложения.

2. Integration Testing (Интеграционное тестирование)
- Цель: Проверка взаимодействия между различными компонентами системы.
- Процесс: Создание тестового плана, ввод данных, сравнение результатов с ожидаемыми.

3. Load Testing (Нагрузочное тестирование)
- Цель: Оценка производительности API при различных нагрузках.
- Процесс: Использование тестовых движков и инструментов, таких как Apache JMeter, для симуляции нагрузок.

4. Regression Testing (Регрессионное тестирование)
- Цель: Убедиться, что новые изменения не нарушают существующую функциональность.
- Процесс: Сравнение результатов старого и нового приложений с использованием входных данных.

5. Functional Testing (Функциональное тестирование)
- Цель: Проверка соответствия функциональности API заявленным требованиям.
- Процесс: Использование функциональной спецификации, ввод данных, сравнение результатов с ожидаемыми.

6. Smoke Testing (Дымовое тестирование)
- Цель: Быстрая проверка основных функций API после разработки.
- Процесс: Ввод данных и проверка, работает ли приложение без ошибок.

Шпаргалка по использованию iptables в Linux #linux

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

8 наиболее распространенных типов кибератак:
(описание к предыдущему посту)

1. Фишинговая атака (Phishing Attack)
- Использование обманных писем, сообщений или сайтов для получения конфиденциальной информации.
- Пример: злоумышленник отправляет ссылку, пользователь открывает её, и хакер получает доступ к учётным данным.

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

3. Отказ в обслуживании (DoS)
- Перегрузка системы или сети для нарушения её нормальной работы.
- Пример: бот-сеть атакует сервер, вызывая его недоступность.

4. Атака «человек посередине» (MitM)
- Перехват и изменение коммуникации между двумя сторонами без их ведома.
- Пример: злоумышленник вставляет себя в канал связи между пользователем и веб-приложением.

5. SQL-инъекция (SQL Injection)
- Использование уязвимостей в запросах к базе данных для получения несанкционированного доступа.
- Пример: злоумышленник отправляет вредоносный запрос, и сервер возвращает данные всех пользователей.

6. Межсайтовый скриптинг (XSS)
- Внедрение вредоносных скриптов на веб-сайты, которые просматриваются другими пользователями.
- Пример: вставка скрипта в базу данных, который затем выполняется в браузере жертвы.

7. Эксплойты нулевого дня (Zero-Day Exploits)
- Атака, использующая неизвестные уязвимости до того, как разработчики смогут их устранить.
- Пример: злоумышленник обнаруживает уязвимость, запускает атаку, а разработчики не успевают её устранить.

8. Спуфинг DNS (DNS Spoofing)
- Перенаправление запросов DNS на вредоносные сайты для несанкционированного доступа.
- Пример: злоумышленник вводит фальшивую запись DNS, и запрос пользователя перенаправляется на поддельный сайт.

Android для ПК появится в следующем году

Генеральный директор Qualcomm Криштиану Амон сообщил в ходе саммита Qualcomm Snapdragon в Мауи, что Google объединит Android и ChromeOS для создания новой операционной системы для компьютеров.
«Это то, чего мы очень ждём в следующем году», — подтвердил глава экосистемы Android Самир Самат.

По его словам, «открывающаяся возможность заключается в том, как ускорить развитие ИИ, которое мы реализуем на Android, и как можно быстрее перенести его в форм-фактор ноутбука, обеспечив при этом бесперебойную работу ноутбука и остальной экосистемы Android».
https://www.youtube.com/live/fpHCkdIg9gU?t=4655s

#android

Вкратце по шаблонам проектирования

Почему шаблоны проектирования важны?

1. Возможность повторного использования
* Проверенные решения, которые работают в разных проектах

2. Гибкость
* Способствуют слабой связности компонентов и упрощают поддержку

3. Коммуникация
* Создают общий язык для обсуждения проблем проектирования и их решений

4. Опыт
* Инкапсулируют опыт опытных разработчиков, помогая другим избегать типичных ошибок и создавать более качественное ПО


Рассмотрим основные задачи которые решают шаблоны.

Порождающие шаблоны

1. Абстрактная фабрика
* Создаёт семейства взаимосвязанных объектов через общий интерфейс

2. Строитель
* Разделяет построение сложного объекта от его представления

3. Фабричный метод
* Определяет интерфейс для создания объектов
* Позволяет подклассам выбирать конкретный класс для создания

4. Прототип
* Создаёт новые объекты путём копирования прототипа

5. Одиночка
* Гарантирует, что класс имеет только один экземпляр

Структурные шаблоны

6. Адаптер
* Преобразует один интерфейс в другой, позволяя несовместимым классам работать вместе

7. Мост
* Разделяет абстракцию и реализацию, позволяя им изменяться независимо

8. Компоновщик
* Обрабатывает отдельные объекты и их композиции единообразно, представляя иерархии часть-целое

9. Декоратор
* Динамически добавляет функциональность объекту без использования наследования

10. Фасад
* Предоставляет упрощённый интерфейс к сложной подсистеме

11. Лёгковес
* Разделяет объекты для уменьшения использования памяти при большом количестве мелких объектов

12. Заместитель
* Контролирует доступ к объекту, предоставляя различные возможности, такие как отложенная загрузка или удалённый доступ

Поведенческие шаблоны

13. Цепочка ответственности
* Разделяет отправителей и получателей запросов, позволяя нескольким объектам обрабатывать запрос

14. Команда
* Инкапсулирует запросы в объекты, позволяя вести логирование, создавать очереди и выполнять операции отмены/повтора

15. Интерпретатор
* Определяет грамматику языка и интерпретатор для выполнения выражений

16. Итератор
* Обеспечивает последовательный доступ к элементам агрегата без раскрытия внутреннего представления

17. Посредник
* Инкапсулирует взаимодействие объектов, способствуя слабой связности

18. Хранитель
* Сохраняет и восстанавливает состояние объекта без нарушения инкапсуляции

19. Наблюдатель
* Автоматически уведомляет зависимые объекты при изменении состояния

20. Состояние
* Изменяет поведение объекта при изменении его внутреннего состояния

21. Стратегия
* Инкапсулирует взаимозаменяемые алгоритмы, позволяя клиентам выбирать их динамически

22. Шаблонный метод
* Определяет скелет алгоритма, откладывая шаги реализации на подклассы

23. Посетитель
* Добавляет новые операции к структурам объектов без изменения классов элементов

Cравнение двух методов аутентификации и хранения данных в веб-приложениях: Куки и Сессии.
(продолжение в следующем посте)

Cравнение двух методов аутентификации и хранения данных в веб-приложениях: Куки и Сессии.
(продолжение в предыдущего поста)

### Cookies
- Хранение данных: Данные хранятся на стороне клиента (в браузере пользователя).
- Процесс работы:
1. Пользователь отправляет свои учетные данные на сервер.
2. Сервер устанавливает Cookie с пользовательскими данными или токеном.
3. При последующих запросах браузер отправляет Cookie вместе с запросом.
4. Сервер отвечает данными, используя информацию из Cookie.

### Sessions
- Хранение данных: Данные хранятся на сервере, а на стороне клиента сохраняется только идентификатор сессии (Session ID).
- Процесс работы:
1. Пользователь отправляет свои учетные данные на сервер.
2. Сервер создает сессию и устанавливает Cookie с Session ID.
3. При последующих запросах браузер отправляет Session ID.
4. Сервер ищет сессию по идентификатору.
5. Сервер возвращает данные сессии.
6. Сервер отвечает данными пользователю.

### Основные различия
- Cookies:
- Данные хранятся в браузере пользователя.
- Более подвержены уязвимостям, таким как атаки CSRF.
- Ограничены по размеру (обычно до 4 КБ).
- Sessions:
- Данные хранятся на сервере, что повышает безопасность.
- Требуют больше ресурсов на сервере.
- Могут быть более сложными в реализации, особенно в распределенных системах.

25 сентября 2025 года состоялся релиз стабильной версии СУБД PostgreSQL 18, обновления для которой будут выходить в течение пяти лет до ноября 2030 года.

PostgreSQL 18 включает множество новых функций и улучшений, среди которых:

* Подсистема асинхронного ввода-вывода (AIO), которая способна повысить производительность последовательных сканирований, сканирований с использованием битовых карт, операций очистки (vacuum) и других операций.

* Утилита pg_upgrade теперь сохраняет статистику оптимизатора.

* Поддержка поиска skip scan, позволяющая использовать многоколоночные B-tree индексы в большем количестве случаев.

* Функция uuidv7() для генерации UUID с упорядочиванием по временной метке.

* Виртуальные генерируемые столбцы, которые вычисляют свои значения во время операций чтения. Теперь это настройка по умолчанию для генерируемых столбцов.

* Поддержка аутентификации OAuth.

* Поддержка OLD и NEW в предложениях RETURNING для команд INSERT, UPDATE, DELETE и MERGE.

* Временные ограничения (или ограничения над диапазонами) для PRIMARY KEY, UNIQUE и FOREIGN KEY ограничений.

https://www.postgresql.org/docs/18/release-18.html

Пессимистическая и оптимистическая блокировки в базах данных
(описание в следующем посте)

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

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

### Пессимистическая блокировка
Цель: Предотвратить конфликты заранее, блокируя данные до их изменения.
Как работает:
1. Система блокирует данные сразу после их извлечения.
2. Другие пользователи не могут изменять эти данные, пока блокировка не будет снята.
3. После завершения транзакции блокировка снимается.

Преимущества:
- Гарантирует целостность данных.
- Подходит для систем с высокой конкуренцией за данные (например, финансовые операции).

Недостатки:
- Может снижать производительность из-за ожидания других процессов.
- Увеличивает вероятность взаимоблокировок (deadlocks).

### Оптимистическая блокировка
Цель: Позволить параллельную работу, проверяя конфликты только при сохранении изменений.
Как работает:
1. Данные читаются без блокировки.
2. При сохранении изменений система проверяет, не были ли данные изменены другими пользователями.
3. Если конфликт обнаружен, транзакция откатывается, и пользователь должен повторить попытку.

Преимущества:
- Высокая производительность, так как блокировки используются редко.
- Меньше вероятность взаимоблокировок.

Недостатки:
- Подходит только для систем с низкой конкуренцией за данные.
- Возможны потери изменений при частых конфликтах.

### Когда использовать?
- Пессимистическая блокировка:
- В системах с частыми изменениями одних и тех же данных.
- Когда важна абсолютная целостность данных.
- Оптимистическая блокировка:
- В системах с большим количеством чтений и редкими изменениями.
- Когда конфликты происходят редко, и их последствия незначительны.

Ипортозамещение отменяется. Слишком сырое, очень дорогое. Названы причины, почему российские компании не хотят переходить на отечественное ПО

Отечественный бизнес не очень стремится отказываться от иностранного ПО в пользу отечетсвенного. ПРичины такого отношения: дороговизна российского софта, его малофункциональность, его «сырость» и нестабильность работы, трудности внедрения, а также совмения в его безопасности

Если российским компаниям приходится расставаться с зарубежным лицензионным софтом, то в качестве альтернативы они предпочитают Open Source, а не отечественные решения

https://www.cnews.ru/news/top/2025-09-26_slishkom_syroeizbytochno

Наглядно, как изменялась производительность в .NET по версиям на примере одного запроса LINQ