5 популярных архитектурных паттернов: VIPER, MVVM, MVC, MVP, MVI
(продолжение предыдущего поста)

#### 1. VIPER (View, Interactor, Presenter, Entity, Router)
Компоненты (на изображении выделены блоками):
* View — отвечает за отображение данных и сбор пользовательских взаимодействий (иконка «User → View»).
* Interactor — содержит бизнес-логику приложения (иконка с человеком за ноутбуком, подписана «Interactor»).
* Presenter — связующее звено между View и Interactor: подготавливает данные для отображения и реагирует на действия пользователя (иконка «Presenter»).
* Entity — хранит базовые структуры данных приложения (обозначен как «Entity»).
* Router — управляет навигацией (выделен как «Router» в центре схемы).

Особенности (согласно изображению):
* приложение делится на 5 чётких частей;
* улучшает тестируемость и разделение ответственности;
* данные передаются через уведомления (Notify) и обновления (Updates).

Идеально подходит для крупных приложений со сложной бизнес-логикой.

#### 2. MVVM (Model-View-ViewModel)
Компоненты:
* View — отображает данные, состояние контролируется ViewModel (иконка «View»).
* ViewModel — абстрагирует View, включает логику изменения состояния View, связывает Model и View (обозначен как «View model»).
* Model — содержит основную функциональность и данные (иконка «Model»).

Ключевые особенности (на схеме):
* ViewModel связывает данные модели с View;
* поддерживает двустороннюю привязку данных (Data binding, показано стрелками между View и ViewModel);
* изменения состояния (Change state) передаются от ViewModel к Model.

Применяется в WPF, Xamarin и других XAML-фреймворках.

#### 3. MVC (Model-View-Controller)
Компоненты (показаны на схеме):
* Model — хранит данные и логику приложения (иконка «Model»).
* View — отображает информацию пользователю (иконка «View»).
* Controller — обрабатывает пользовательский ввод, взаимодействует с Model и обновляет View (центральная иконка «Controller»).

Логика взаимодействия (на изображении):
1. Пользователь делает запрос → Controller.
2. Controller взаимодействует с Model.
3. Model возвращает данные → Controller обновляет View.

Особенности:
* один из старейших и наиболее распространённых паттернов;
* контроллер управляет вводом и обновлениями.

Подходит для простых приложений с чёткой структурой.

#### 4. MVP (Model-View-Presenter)
Компоненты:
* View — пассивное представление данных (иконка «View»), не обрабатывает логику.
* Model — хранит данные (иконка «Model»).
* Presenter — управляет взаимодействием между View и Model (иконка «Presenter»).

Взаимодействие (на схеме):
1. View передаёт обновления → Presenter.
2. Presenter взаимодействует с Model → получает данные.
3. Presenter возвращает данные в View.

Ключевые особенности:
* Presenter связывает Model и пассивное View;
* Presenter обрабатывает логику пользовательского интерфейса (UI logic).

Используется там, где важно отделить логику представления от View.

#### 5. MVI (Model-View-Intent)
Компоненты (согласно изображению):
* View — отображает интерфейс (иконка «View»).
* Intent — представляет пользовательские действия (намерения), запускает изменения состояния (центральная иконка «Intent» с мишенью).
* Model — обрабатывает логику и хранит состояние (иконка «Model»).

Особенности потока данных (на схеме):
* Однонаправленный поток: Intent → Model → View.
* Фокус на состоянии (state) и реактивности (reactivity) — изменения состояния обрабатываются предсказуемо.
* Данные поступают из интернета или локальных источников → обрабатываются Model → отображаются в View.

Идеально подходит для приложений, где критично управление состоянием (например, в реактивных приложениях).

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

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

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

$ mkdir -p ~/noscripts/{site-01,site-02}/{backup,monitoring,network}

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

Удобный способ сэкономить время и поддерживать упорядоченную структуру директорий.

Некоторые базовые математические обозначения

7 концепций, которые нужно освоить для работы с кэшем
(продолжение в следующем посте)

7 концепций, которые нужно освоить для работы с кэшем
(продолжение предыдущего поста)

Коэффициент попаданий в кэш (Cache Hit Ratios)
Это показатель эффективности вашей стратегии кэширования.
Высокий коэффициент попаданий означает, что в кэше часто присутствует запрашиваемые данные.
Высокий коэффициент минимизирует необходимость извлекать данные из более медленных уровней хранения.

Политики вытеснения (Eviction Policies)
Они определяют, какие данные остаются в кэше, а какие удаляются — это вопрос эффективности.

Распространённые политики:
* наименее недавно использованные данные (Least Recently Used, LRU);
* наиболее недавно использованные данные (Most Recently Used, MRU);
* наименее часто используемые данные (Least Frequently Used, LFU).

Согласованность кэша (Cache Coherence)
В распределённых системах всё становится сложнее.
Крайне важно поддерживать согласованность данных во всех кэшах.
Согласованность кэша гарантирует, что все копии элемента данных отражают самую последнюю версию.

Зернистость кэша (Cache Granularity)
Речь идёт о размере единиц данных, хранящихся в кэше.
Решения о зернистости влияют на эффективность кэша и коэффициент попаданий.
Сколько данных нужно сохранять при каждой операции?

Прогрев кэша (Cache Warm-up)
Предварительная загрузка кэша данными, которые предположительно будут востребованы, повышает производительность.
Особенно в системах, где попадания в кэш критически важны для скорости работы.

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

Сжатие кэша (Cache Compression)
Когда место ограничено, сжатие данных в кэше позволяет хранить больше информации.
Однако это влечёт за собой накладные расходы на обработку при сжатии и распаковке.

Кэширование — это не просто «скинуть данные куда‑нибудь и забыть о них».
Это также про то, *какие* данные, *как* и *когда* сохранять, чтобы сделать систему быстрее.

Разработчики в 2020 vs разработчики в 2025

Rate Limit (Ограничение частоты запросов к API)
(продолжение в следующем посте)

Rate Limit (Ограничение частоты запросов к API)
(продолжение предыдущего поста)

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

Почему важно ограничивать частоту запросов к API

* Предотвращает перегрузку сервера.
* Блокирует вредоносные боты и попытки подбора методом перебора.
* Обеспечивает справедливое распределение ресурсов.
* Повышает надёжность и время безотказной работы API.
* Помогает контролировать расходы на API и использование инфраструктуры.

Основные методы ограничения частоты запросов

1. Ограничение по фиксированному окну (Fixed Window Rate Limiting)

* Запросы учитываются в рамках фиксированного промежутка времени (например, 100 запросов в минуту).
* Простота реализации.
* Может приводить к всплескам запросов на границах окон.

2. Журнал скользящего окна (Sliding Window Log)

* Фиксирует время каждого запроса в журнале.
* Более точное сглаживание трафика.
* Повышенное потребление памяти.

3. Счётчик скользящего окна (Sliding Window Counter)

* Объединяет методы фиксированного окна и журнала.
* Обеспечивает сглаженные ограничения без значительного объёма хранения данных.
* Снижает проблемы, связанные со «всплесками» запросов.

4. Алгоритм Token Bucket

* Клиенты накапливают «токены» с фиксированной скоростью.
* Каждый запрос использует один токен.
* Позволяет контролируемые всплески запросов при соблюдении ограничений.

5. Алгоритм Leaky Bucket

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

Где применяется ограничение частоты запросов

* API‑шлюзы (Kong, NGINX, AWS API Gateway).
* Обратные прокси‑серверы.
* Уровень серверного приложения.
* Узлы CDN (Cloudflare, Akamai).
* Уровень взаимодействия микросервисов.

Типичные HTTP‑ответы при ограничении частоты запросов

* 429 Too Many Requests — клиент превысил лимит.
* Заголовок Retry‑After — указывает клиенту, сколько времени нужно подождать.

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

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

Энтузиасты разработали сверхкомпактный дистрибутив Linux под названием Tiny Core Linux, который после установки занимает всего лишь 23 МБ. Это примерно в 1100 раз меньше объема, занимаемого только что установленной Windows 11. Схожий объем имеют фотографии, снятые на современные флагманские Android-смартфоны в высоком разрешении и без экономии качества

При этом система полноценна – у нее есть функциональный оконный интерфейс, напоминающий одновременно и Windows благодаря острым углам окон, и macOS за счет небольшой док-панели внизу экрана. Tiny Core Linux располагает даже собственным установщиком программ – он подключается к серверу и открывает доступ к десяткам приложений

Что еще более примечательно, ISO-образ Tiny Core Linux «весит» больше, нежели полностью установленная система – 25,1 МБ.

http://www.tinycorelinux.net/welcome.html
https://www.tomshardware.com/software/linux/tiny-core-linux-16-2-still-fits-a-proper-linux-desktop-into-a-23mb-download-but-it-has-grown-1mb-since-the-last-time-we-looked-at-it

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

Биты, P‑биты (вероятностные биты) и кубиты
(продолжение предыдущего поста)

### 1. Физическая природа и состояние

- Бит (классический):
- Дискретная единица информации в классических компьютерах.
- Может находиться только в одном из двух состояний: $0$ или $1$.
- Состояние строго определено (например, напряжение на транзисторе: есть — 1, нет — 0).
- Нет промежуточных значений.

- P‑bit (probabilistic bit, вероятностный бит):
- Может случайным образом переключаться между 0 и 1 под действием тепловых шумов.
- Состояние описывается вероятностью: например, P(0) = 0,7, P(1) = 0,3.
- Работает при комнатной температуре.
- Реализуется на наномагнитных элементах (stochastic magnetic tunnel junctions, sMTJ).

- Кубит (quantum bit, квантовый бит):
- Квантовый объект (электрон, фотон, ион и т. п.).
- Может находиться в суперпозиции состояний: α∣0⟩+β∣1⟩, где α и β — комплексные амплитуды (∣α∣^2 + ∣β∣^2 = 1).
- При измерении «коллапсирует» в 0 или 1 с вероятностями ∣α∣^2 и ∣β∣^2
- Требует крайне низких температур (близки к абсолютному нулю) для сохранения когерентности.

### 2. Принципы работы

- Бит:
- Логические операции (И, ИЛИ, НЕ) выполняются детерминированно.
- Вычисления — последовательные или параллельно-конвейерные.

- P‑bit:
- Использует естественную случайность физических элементов для вероятностных вычислений.
- Хорошо подходит для задач оптимизации, статистического вывода, генеративных моделей.
- Позволяет массовый параллелизм при низком энергопотреблении.

- Кубит:
- Оперирует квантовыми состояниями (суперпозиция, запутанность).
- Квантовые алгоритмы (Шора, Гровера и др.) дают экспоненциальное ускорение для некоторых задач.
- Требует коррекции ошибок из-за декогеренции.

### 3. Области применения

- Бит:
- Общие вычисления, логика, хранение данных.

- P‑бит:
- Оптимизация (например, задачи коммивояжёра).
- Генеративные модели ИИ (энергоэффективно).
- Статистический вывод.

- Кубит:
- Факторизация больших чисел (криптоанализ).
- Моделирование квантовых систем (химия, материалы).
- Поиск в неструктурированных базах данных.
- Квантовое машинное обучение.


### 4. Резюме

- **Бит** — основа классических вычислений: детерминирован, масштабируем, универсален.
- **P‑bit** — вероятностный элемент: использует случайность для энергоэффективных оптимизационных задач при комнатной температуре.
- **Кубит** — квантовый элемент: даёт суперпозицию и запутанность, но требует экстремального охлаждения и коррекции ошибок.

Сервис TIOBE опубликовал декабрьский рейтинг языков программирования. Неожиданностью стало попадание языка R в первую десятку. Ну а язык C#, судя по всему, станет языком 2025 года по версии TIOBE
Понятно, что рейтинг TIOBE - это рейтинг, высосанный из пальца, но тем не менее.
https://www.tiobe.com/tiobe-index/

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

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

✓ 1. Первичные индексы
→ Автоматически создаются для первичных ключей.
→ Обеспечивают быстрый поиск по уникальным идентификаторам.
→ Всегда индексируйте поля первичного ключа для эффективного извлечения записей.

✓ 2. Вторичные индексы
→ Создаются для неключевых столбцов, часто используемых в поисках.
→ Идеальны для таких полей, как email, имя пользователя или статус.
→ Позволяют быстро фильтровать запросы без сканирования всей таблицы.

✓ 3. Составные индексы
→ Индексы, охватывающие несколько столбцов.
→ Оптимальны, когда запросы фильтруют или сортируют данные по нескольким полям.
→ Порядок имеет значение: индекс по (страна, город) поможет запросу с фильтрацией по обоим параметрам, но не по городу в одиночку.

✓ 4. Уникальные индексы
→ Гарантируют отсутствие повторяющихся значений.
→ Полезны для email, имён пользователей или любых полей, требующих уникальности.
→ Также повышают производительность, поскольку СУБД оптимизирует проверку уникальности.

✓ 5. Полнотекстовые индексы
→ Оптимизированы для поиска фраз и ключевых слов.
→ Полезны для блогов, поиска товаров, мессенджеров.
→ Поддерживают запросы на естественном языке вроде «найти посты о проектировании бэкенда».

✓ 6. Частичные (фильтрованные) индексы
→ Индексируют лишь часть таблицы (например, активных пользователей).
→ Уменьшают размер индекса и повышают скорость, если данные имеют предсказуемые шаблоны.

✓ 7. Покрывающие индексы
→ Включают все необходимые столбцы для запроса.
→ Позволяют СУБД ответить на запрос, используя только индекс — без сканирования таблицы.
→ Идеальны для нагрузок с частыми операциями SELECT.

✓ 8. Индексирование для операций соединения (joins)
→ Всегда индексируйте внешние ключи.
→ Убедитесь, что обе стороны условий соединения проиндексированы.
→ Значительно улучшают запросы с объединением нескольких таблиц.

✓ 9. Избегайте избыточного индексирования
→ Каждый индекс увеличивает объём хранимых данных.
→ Замедляет операции записи (вставка/обновление/удаление).
→ Создавайте индексы только для реальных, регулярно повторяющихся шаблонов запросов.

✓ 10. Мониторинг производительности индексов
→ Используйте команды EXPLAIN или ANALYZE для проверки использования индексов.
→ Удаляйте неиспользуемые индексы, чтобы снизить накладные расходы.
→ Постоянно корректируйте индексирование по мере эволюции данных и запросов.

Линус Тольвальдс об ИИ:

- «Искусственный интеллект — это, безусловно, мыльный пузырь, но он изменит то, как выполняется большинство квалифицированных работ».
- «Программирование с помощью ИИ отлично подходит для начала изучения программирования, но поддерживать такой код — ужасная задача».
- «Я большой сторонник ИИ. Но я не большой сторонник всего, что связано с ИИ. Я считаю, что рынок и маркетинг в этой сфере находятся в плачевном состоянии. Неизбежен обвал».

Компания Amazon поделилась историей перехода на Rust с Kotlin и Go

На конференции AWS re:Invent 2025 компания AWS (Amazon) объявила, что Rust стал языком программирования по умолчанию для всех проектов в области data plane (обработка данных), подчеркивая его превосходство в производительности по сравнению с другими языками. AWS уже использует Rust в своих микро-виртуальных машинах, таких как Bottlerocket и Firecracker.
Компания сделала акцент на преимуществах Rust, прежде всего на отсутствии накладных расходов на сборку мусора, которые сильно влияют на языки вроде Kotlin и Go в крупных распределенных приложениях.

CTO AWS Вернер Фогелс отметил, что база данных Aurora DSQL (распределенная PostgreSQL-совместимая СУБД) была переписана с Kotlin на Go для решения проблем с производительностью, но Rust показал еще лучшие результаты: «Код на [Rust] был в 10 раз быстрее нашей тщательно настроенной реализации на Kotlin — несмотря на отсутствие попыток его оптимизации».

В качестве примера успешной интеграции приводится пример с агента мониторига Datadog - изначально написанный на Go и запущенный как расширение на AWS Lambda, имел время холодного старта 700–800 мс, что считалось «огромной нагрузкой» для serverless-observability. Переход на Rust сократил это до 80 мс.

Кроме того, Rust обрабатывал в разы больше точек данных в секунду (PPS), а в целом код на Rust был почти в 3 раза быстрее. Стайвенберг объяснил, что Go тратил 30% времени на сборку мусора из-за частых мелких аллокаций памяти для данных observability. Хотя оптимизация Go с использованием off-heap памяти возможна, она приводит к неудобоуправляемому коду. В итоге: «Идиоматичный код на Rust дает производительность тщательно оптимизированного кода на Go».

https://devclass.com/2025/12/08/aws-shows-rust-love-at-reinvent-10-times-faster-than-kotlin-one-tenth-the-latency-of-go/