Кэшировать или не кэшировать?

Это один из самых частых вопросов, которым задаются backend-разработчики.
Под «кэшированием» здесь понимается временное хранение данных в быстродоступной памяти для ускорения работы приложения.

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

Вот система критериев, которая поможет принять правильное решение:

1. Часто ли обращаются к этим данным?
2. Дорого ли их получать?
3. Изменчивы ли они?
4. Объёмны ли они?
5. Влияют ли они на воспринимаемую пользователем задержку?
6. Безопасно ли их кэшировать?
7. Есть ли способ их обновить или аннулировать?

Схема на картинке позволяет принять решение по поводу кэширования

Хук useEffect из React при неаккуратном обращении убивает

Cloudflare совершила DDoS-атаку на саму себя, используя хук useEffect из React
Cloudflare призналась в ошибке кода, связанной с использованием хука useEffect из React, который известен своей сложностью при неаккуратном обращении. Эта ошибка привела к сбою панели управления платформы и многих её API.

Сбой произошёл 12 сентября, длился более часа и был вызван ошибкой в ​​панели управления, которая, по словам вице-президента по разработке Тома Лианзы, привела к «повторным ненужным вызовам Tenant Service API». Этот API является частью логики авторизации запросов API и, следовательно, повлиял на другие API.

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

Lianza сообщила, что основная проблема заключалась в хуке React useEffect с «проблемным объектом в массиве зависимостей». Хук useEffect — это функция с параметрами, включая функцию настройки, возвращающую функцию очистки, и необязательный список зависимостей. Функция настройки запускается каждый раз при изменении зависимости.

В данном случае с Cloudflare функция вызывала API Tenant Service, и одной из зависимостей был объект, который «пересоздавался при каждом изменении состояния или свойства». В результате хук срабатывал многократно во время одного рендеринга панели управления, хотя должен был запускаться только один раз. Функция запускалась так часто, что API перегружался, что и приводило к сбою.

Этот инцидент вызвал в сообществе обсуждение плюсов и минусов useEffect и целесообразности его использования.

https://www.theregister.com/2025/09/18/cloudflare_ddosed_itself/?td=rt-3a

Из заметки Andrew Ng, известного специалиста в области ИИ, про необходимость тестирования кода, произведенного ИИ:
"

ИИ-агенты для коддинга действительно могут ошибаться! Мы активно их используем и сталкивались со следующими проблемами:

* Множество ошибок, введённых ИИ-агентами, включая тонкие инфраструктурные баги, на поиск которых у людей уходили недели.
* Уязвимость в системе безопасности, которая появилась в нашей производственной системе, когда ИИ-агент упростил сброс паролей для упрощения разработки.
* Взлом системы вознаграждений, когда ИИ-агентмодифицировал тестовый код, чтобы упростить прохождение тестов.
* ИИ-агент выполнил команду «rm *.py» в рабочем каталоге, что привело к удалению всего кода проекта (к счастью, он был сохранён на GitHub).

В последнем случае, когда ИИ-агента спросили о случившемся, он извинился и согласился, что «это была невероятно глупая ошибка». Нам стало легче, но ущерб уже был нанесён!

"
https://www.deeplearning.ai/the-batch/issue-319/

Практикум по Docker: обновление контейнерного приложения без потери данных 🐳

Контейнеры по умолчанию получают относительно устойчивую файловую систему — изменения, внесённые приложением, сохраняются после перезапуска контейнера, вызванного сбоями приложения, перезагрузкой хоста и т. д. Однако иногда может потребоваться использовать тома, чтобы сделать одни части файловой системы контейнера более надёжными, чем другие. Благодаря томам, даже если вы полностью удалите контейнер (вместо его простого перезапуска), вы сможете продолжить использовать данные приложения в его преемнике (например, в том же приложении, но с более новым образом).

#docker

Сравнение HTTP/2 и HTTP/3
(продолжение в следующем посте)

Сравнение HTTP/2 и HTTP/3
(продолжение предыдущего поста)

В чем же разница между протоколами HTTP/2 и HTTP/3? Начнем с основ:

* 1996 → HTTP 1
* 1997 → HTTP 1.1
* 2015 → HTTP 2
* 2022 → HTTP 3

HTTP 1.1:
✓ Персистентные соединения — повторное использование соединений вместо открытия новых.
✓ Частичная передача — отправка данных частями вместо ожидания полного ответа.
✓ Улучшенный кеш — добавлены заголовки для лучшего управления кешем и соединениями.
🅇 Последовательные запросы — запросы блокируют друг друга (блокировка в очереди на уровне запросов).
🅇 Множественные соединения — браузеры использовали несколько TCP-соединений для ускорения.

Он ввел основные функции, которые используются до сих пор.

HTTP 2:
✓ Мультиплексирование — несколько запросов в одном TCP-соединении.
✓ Сжатие заголовков (HPACK) — уменьшение размера метаданных.
✓ Приоритет потоков — обеспечение загрузки критических ресурсов в первую очередь.
🅇 Блокировка в очереди (HoL) — потеря пакета блокирует все потоки.

Хотя HTTP 2 оптимизировал TCP, он оставался ограниченным из-за блокировки в очереди TCP.

HTTP 3:
✓ Построено на QUIC (UDP) — больше нет узких мест TCP.
✓ Независимые потоки — потеря пакета в одном потоке не влияет на другие.
✓ Быстрые рукопожатия — объединение настройки транспорта и шифрования в один шаг.
✓ Мандатное шифрование (TLS 1.3) — безопасность по умолчанию.
✓ Миграция соединений — бесперебойная работа при изменении сети.

Итог: HTTP 2 оптимизировал TCP, но HTTP 3 внедряет QUIC, делая соединение быстрее, надежнее и зашифрованным по умолчанию.

Покрывающие индексы (Covering indexes)
(продолжение предыдущего поста)

Покрывающие индексы — это индексы, которые при грамотном использовании способны значительно повысить производительность системы.

Покрывающий индекс — это такой индекс, который используется для получения всех столбцов результата запроса без необходимости обращения к основному хранилищу данных таблицы. Для Postgres это означает обход файла куч таблицы, а для MySQL — обход кластеризованного индекса данных таблицы.

Рассмотрим пример запроса:

SELECT name, email
FROM user
WHERE name > 'C' AND name < 'G';

Если у нас есть индекс только по имени, например:

CREATE INDEX idx_name
ON your_table (name);

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

В качестве альтернативы можно использовать составной индекс:

CREATE INDEX idx_name_email 
ON your_table (name, email);

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

В руководство по языку Java добавлены новые статьи:

Файлы JAR, их создание и выполнение
http://metanit.com/java/tutorial/13.1.php

Создание и подключение библиотеки JAR
http://metanit.com/java/tutorial/13.2.php

Установка пути к классам Java
http://metanit.com/java/tutorial/13.3.php

#java

Как говорит встроенный калькулятор на MacOS: память есть? А если найду?

Игра для извращенцев)
Исходный код: https://gist.github.com/NSG650/74143df2a3eaea089e68cea8f551ba1d

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

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

Индексируйте столбцы в WHERE
* Если столбец используется в WHERE, он должен быть проиндексирован.
* Начинайте с высокоселективных столбцов (например, user_id, email, status).

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

Индексируйте соединения и внешние ключи
* Если по столбцу выполняется в JOIN, индексируйте его.
* Отсутствие индекса на внешних ключах = медленные соединения, гарантировано.

Используйте частичные индексы (Postgres) или фильтрованные индексы (SQL Server)
* Индексируйте только те строки, которые имеют значение.
* Пример: индексируйте только активных пользователей.

Удаляйте неиспользуемые индексы
* Индексы замедляют запись.
* Используйте pg_stat_user_indexes, sys.dm_db_index_usage_stats или эквивалент для удаления лишнего.

Используйте составные индексы (правильно)
* Порядок имеет значение: индекс (user_id, created_at) ≠ (created_at, user_id).
* Подбирайте индекс под фильтры и сортировки запросов.

Избегайте низкоселективных индексов
* Не индексируйте булевы значения или столбцы с малым количеством уникальных значений.
* Они не фильтруют данные, а только занимают место.

Следите за функциями в WHERE
* WHERE YEAR(created_at) = 2024 = полное сканирование таблицы.
* Вместо этого: created_at BETWEEN '2024-01-01' AND '2024-12-31'.

Измеряйте, а не угадывайте
* Используйте EXPLAIN, ANALYZE или планы запросов, чтобы увидеть, что происходит.
* Не доверяйте интуиции; доверяйте плану выполнения.

Тестируйте до и после
* Измеряйте время выполнения запросов до и после изменений индексов.
* Если улучшение менее 80%, пересмотрите дизайн.

Библиотекари в США начали жаловаться, что их просят найти несуществующие книги, которые на самом деле стали результатом галлюцинаций искусственного интеллекта. Этот тренд нарастает с момента выхода GPT-3.5 в конце 2022 года.

Проблема обострилась летом, когда посетители начали запрашивать несуществующие книги, но от реальных авторов. Такие списки для летнего чтения распространялись в специальных выпусках изданий Chicago Sun-Times и The Philadelphia Inquirer. Автор такой подборки признался, что использовал ИИ для составления списка, не проверяя факты.

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

«Библиотекари сообщают об общей атмосфере замешательства и недоверия, которую они испытывают со стороны своих читателей. Они видят, что у читателей, по-видимому, снизился уровень критического мышления и любопытства. Они определённо сталкиваются с некоторыми типами психозов и другими проблемами психического здоровья».

https://www.404media.co/librarians-are-being-asked-to-find-ai-hallucinated-books/

Гендиректор Nvidia: электрики, сантехники и плотники — главные профессии ближайшего будущего для развития ИИ-технологий

Генеральный директор Nvidia Дженсен Хуан в интервью британскому каналу Channel 4 заявил, что для развития ИИ‑технологий самыми ценными кадрами станут те, кто умеют работать руками. Обслуживание ИИ‑систем требует большого количества рабочей силы и сложнейших систем, включая охлаждение, сетевые соединения и электропитание, а также строительства новых ЦОД.

Глава Nvidia считает, что в ближайшие 10–20 лет будет высокий спрос на строительство таких ИИ‑кластеров, а поэтому и зарплаты у электриков, сантехников, плотников и специалистов подобных профессий резко взлетят вверх. Хуан не исключил, что мир стоит на пороге новой промышленной революции — и одной из главных проблем этого перехода станет именно острая нехватка квалифицированных рабочих кадров.

«Если вы электрик, сантехник, плотник, нам понадобятся сотни тысяч таких людей, чтобы построить все эти ИИ‑заводы. И сектор квалифицированных рабочих каждой экономики переживёт бум. Вам придётся строить, вам придётся продолжать удваивать каждый год. И я думаю, что вы будете строить инфраструктуру ИИ здесь, в Великобритании, в течение десятилетия», — пояснил Дженсен Хуан.
https://www.channel4.com/news/electricians-and-plumbers-will-triumph-in-ai-race-nvidia-boss

Одна из версий роудмапов с Джуниора до Синьора

Думаю, надо больше мониторов...
А вообще, как мне кажется, такое большое количество мониторов будет только отвлекать от работы

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

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

### SQL (Реляционные базы данных)
- Особенности: Индексирование и оптимизация, функции безопасности, поддержка SQL, структурированные данные, транзакции и ACID.
- Примеры: MySQL, Oracle, Microsoft SQL Server, PostgreSQL.

### NoSQL
- Особенности: Горизонтальное масштабирование, высокая доступность, распределенная архитектура.
- Типы:
- Columnar Database: Apache Cassandra, ClickHouse, Druid.
- NewSQL Database: SingleStoreDB, TIDB, CockroachDB.
- Spatial Database: Topology & Network Analysis, интеграция с GIS.
- Graph Database: Neo4j, GraphDB, OrientDB, Amazon Neptune.
- Document Database: MongoDB, CouchDB, MarkLogic, Elasticsearch.
- Key-Value Database: Redis, DynamoDB, BoltDB, Aerospike.
- Time-Series Database: InfluxDB, Prometheus, TimescaleDB, ClickHouse.

### Key-Value Database
- Особенности: Простая модель данных, высокая производительность записи и запросов, политика хранения данных.
- Примеры: Redis, DynamoDB, BoltDB, Aerospike.

### Time-Series Database
- Особенности: Эффективное хранение данных, политики хранения, агрегация по временным окнам.
- Примеры: InfluxDB, Prometheus, TimescaleDB, ClickHouse.

### Graph Database
- Особенности: Глубокий анализ, фокус на отношениях, интеграция с ГИС.
- Примеры: Neo4j, GraphDB, OrientDB, Amazon Neptune.

### Document Database
- Особенности: Гибкая схема, эффективная производительность запросов, управление версиями документов.
- Примеры: MongoDB, CouchDB, MarkLogic, Elasticsearch.

### Object-Oriented Database
- Особенности: Наследование и полиморфизм, инкапсуляция и абстракция данных.
- Примеры: ZODB, ObjectDB, Cache, db4o.

### Spatial Database
- Особенности: Топология и сетевой анализ, интеграция с ГИС.
- Примеры: ArangoDB, CouchDB, Snowflake.