Сравнение 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.

В любом треугольнике отношение длины стороны к синусу противолежащего ей угла одинаково для всех трех сторон.

Шпаргалка по утилите grep в Linux #linux

По данным консалтинговой компании Baringa, британские банки до сих пор используют программное обеспечение, написанное в 1960-х и 1970-х годах. В нём разбираются лишь немногие старшие сотрудники.

Согласно опросу 200 банков, 16% из них используют ПО 1960-х годов, а почти 40% поддерживают код 1970-х годов.

При этом 50% представителей банков признались, что используют софт, который понимают лишь один или два сотрудника пенсионного возраста или приближающегося к нему. Ещё 31,5% заявил, что полагаются на одного или двух сотрудников, пока не достигших пенсионного возраста, для понимания устаревших систем.

Около 38 представителей банков ответили, что они до сих пор применяют код, разработанный для работы на физических системах, таких как перфокарты, а 15% — код, написанный для мэйнфреймов размером с комнату.

Один из респондентов отметил, что его банк работает с программным обеспечением Microsoft 1993 года. Сеть банкоматов банка использует устаревшие серверы Windows NT.

Другой отметил, что основные банковские системы были созданы в 1970-х годах и до сих пор используют язык программирования Cobol. Именно он был основной технологией для финансовых и административных систем.

Один из ведущих IT-специалистов в банковском секторе Великобритании, пожелавший остаться анонимным, рассказал, что работал над многими системами, созданными в 1960-х, 1970-х и 1980-х годах.

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

Аналогичная ситуация наблюдается не только в Великобритании. В США по состоянию на 2021 год более 80% личных операций в финансовых учреждениях проводили с использованием COBOL. Bank of New York Mellon в 2012 году обнаружил, что использует 112500 отдельных программ COBOL, составляющих почти 350 миллионов строк.

https://www.computerweekly.com/news/366631494/UK-banks-still-run-software-code-written-more-than-60-years-ago

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

Основные модели контроля доступа
(продолжение предыдущего поста)

### Role-Based Access Control (RBAC)
RBAC используется для управления доступом на основе ролей. На примере показано, как пользователь Alice пытается выполнить действие (например, слить запрос на слияние в GitHub). Процесс включает:
- Определение роли пользователя (например, Maintainer).
- Проверка разрешений, связанных с этой ролью (например, Merge Pull Request, Push Code, Manage Issues).
- Если разрешения удовлетворяют требованиям, доступ разрешается.

### Attribute-Based Access Control (ABAC)
ABAC основан на атрибутах пользователей, ресурсов и контекста. На примере показано:
- Пользователь Dana пытается открыть файл Budget.xlsx.
- Система проверяет атрибуты пользователя (например, отдел, уровень доступа), атрибуты ресурса (например, классификация) и контекст (например, IP-адрес, время).
- Если все условия удовлетворены, доступ разрешается.

### Access Control List (ACL)
ACL определяет доступ к ресурсам через списки контроля доступа. На примере показано:
- Пользователь Evan пытается отредактировать файл Budget.xlsx.
- Система проверяет ACL для файла, чтобы определить, имеет ли пользователь права на редактирование.
- Если права есть, доступ разрешается.

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

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