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

Что такое REST API?
(продолжение предыдущего поста)

REST API (Representational State Transfer) — архитектурный стиль взаимодействия компонентов распределённой системы для передачи данных между сервером и клиентом с использованием протокола HTTP. Проще говоря, это способ взаимодействия сайтов и веб-приложений с сервером для получения, изменения или удаления данных. REST API широко используется в веб-разработке, мобильных приложениях и облачных сервисах благодаря своей простоте и эффективности.

6 ключевых принципов работы REST API:

1. Client-Server (Клиент-сервер):
* клиент (пользовательский интерфейс, например, веб-страница или приложение) и сервер разделены;
* код запросов остаётся на стороне клиента, а код для доступа к данным — на стороне сервера;
* это упрощает масштабирование и перенос интерфейса на другие платформы.

2. Stateless (Отсутствие состояния):
* сервер не хранит информацию о состоянии клиента (истории запросов);
* каждый запрос от клиента должен содержать всю необходимую информацию для обработки;
* сервер и клиент не сохраняют данные о предыдущих взаимодействиях (как показано на схеме: «Do not store state info»).

3. Uniform Interface (Единый интерфейс):
* все запросы к данным выполняются через единый URL-адрес с использованием стандартных HTTP-методов (GET, POST, PUT, DELETE, PATCH);
* ресурсы (например, /products, /users) доступны по чётким URL-адресам (например, https://example.com/api/v3/products);
* это упрощает архитектуру и делает взаимодействие с сервером более понятным.

4. Cacheable (Кэшируемость):
* данные могут быть кэшированы (сохранены в буфере) для ускорения повторных запросов;
* клиент может обращаться к кэшу вместо сервера, если данные не изменились;
* пример на схеме: ответ сервера с заголовком Cache-Control: public, max-age=3600.

5. Layered Systems (Многоуровневая система):
* архитектура состоит из нескольких уровней (например, Load Balancer, Auth Service, Product Database), которые взаимодействуют только с ближайшими уровнями;
* это повышает безопасность, упрощает масштабирование и позволяет изолировать компоненты системы (как показано на схеме с Load Balancer и Auth Service).

6. Code on Demand (Код по запросу, опционально):
* сервер может отправлять клиенту код (например, скрипт noscript.js) по требованию;
* это позволяет усложнять логику приложения только при необходимости (пример на схеме: GET /noscript.js).

### Основные HTTP-методы, используемые в REST API:
* GET — получение данных (например, GET /products);
* POST — добавление новых данных;
* PUT — обновление данных;
* DELETE — удаление данных;
* PATCH — частичное обновление данных.

Наглядно типы кабелей

Минцифры предупредило о постепенном отказе от входа на «Госуслуги» по смс
Ведомство объясняет такие меры борьбой с мошенничеством. Пока это решение касается только входа на «Госуслуги» через мобильные устройства

Некоторые пользователи портала «Госуслуги» уже столкнулись с проблемой при авторизации. После входа в аккаунт пользователям предлагают установить мессенджр MAX, однако возможность нажать кнопку «пропустить» отсутствует.

Мобильная версия сервиса настаивает на установке приложения, и избежать этого невозможно. При этом при входе в аккаунт через браузер на компьютере, пользователи могут нажать на кнопку «пропустить».

https://www.rbc.ru/society/05/12/2025/6932ee189a794711fc60e3ab?from=from_main_2

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

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/