Вышла новая версия языка Java - Java 24 вместо с комплектом разработки JDK 24. Основные нововведения:
- Stream Gatherers: функциональность в Stream API, которая добавляет ряд операций по работе с потоками данных
- Class-File API: предоставляет стандартный API для анализа, генерации и преобразования файлов классов Java.
- Ahead-of-Time Class Loading & Linking: уменьшает время запуска приложений с помощью сохранения кэша загруженных классов
- Synchronize Virtual Threads without Pinning: решает проблему блокировки платформенных потоков при использовании виртуальных потоков в synchronized-блоках
- Ограничение использования JNI: использование Java Native Interface (JNI) и Foreign Function & Memory (FFM) теперь приводит к предупреждению, а в будущем планируется выбрасывать исключение
- Прекращена поддержка Windows 32-bit x86
Подробнее все нововведения - https://jdk.java.net/24/release-notes
#java #jdk
- Stream Gatherers: функциональность в Stream API, которая добавляет ряд операций по работе с потоками данных
- Class-File API: предоставляет стандартный API для анализа, генерации и преобразования файлов классов Java.
- Ahead-of-Time Class Loading & Linking: уменьшает время запуска приложений с помощью сохранения кэша загруженных классов
- Synchronize Virtual Threads without Pinning: решает проблему блокировки платформенных потоков при использовании виртуальных потоков в synchronized-блоках
- Ограничение использования JNI: использование Java Native Interface (JNI) и Foreign Function & Memory (FFM) теперь приводит к предупреждению, а в будущем планируется выбрасывать исключение
- Прекращена поддержка Windows 32-bit x86
Подробнее все нововведения - https://jdk.java.net/24/release-notes
#java #jdk
❤🔥7🔥1👏1
HTTP 2 и HTTP 3 — в чем разница?
HTTP 1 появился в 1996 году. Уже в следующем году появился HTTP 1.1.
Прошло еще около 20 лет, прежде чем в 2015 году был стандартизирован HTTP 2. А в 2022 был официально стандартизирован HTTP 3.
HTTP 1.1:
☑️ Постоянные соединения — повторное использование соединений вместо открытия новых.
☑️ Передачи кусками — отправляет данные по частям, не дожидаясь полного ответа.
☑️ Улучшенное кэширование — введены заголовки для лучшего кэширования и управления соединениями.
X Последовательные запросы — запросы блокируют друг друга (HoL-блокировка на уровне запроса)
X Необходимо несколько подключений — браузеры использовали несколько TCP-подключений для скорости
В нем были представлены основные функции, которые используются и по сей день.
HTTP2:
☑️ Мультиплексирование — несколько запросов в одном TCP-соединении
☑️ Сжатие заголовков (HPACK) — Уменьшает размер метаданных
☑️ Приоритезация потоков — обеспечивает загрузку критически важных ресурсов в первую очередь
X Блокировка заголовка очереди (HoL) — потерянный пакет блокирует все потоки
Хотя HTTP 2 оптимизировал TCP, он оставался ограниченным блокировкой начала очереди TCP.
HTTP3:
☑️ Построен на QUIC (UDP) — больше никаких узких мест TCP
☑️ Независимые потоки — потеря пакетов в одном потоке не влияет на другие
☑️ Более быстрые рукопожатия — Объединяет настройку транспорта и шифрования за один шаг
☑️ Обязательное шифрование (TLS 1.3) — Безопасность по умолчанию
☑️ Миграция подключений — плавный переход между изменениями в сети
Вкратце: HTTP 2 оптимизировал TCP, но HTTP 3 с помощью QUIC, делает сетевое взаимодействие быстрее, надежнее и зашифрованным по умолчанию
HTTP 1 появился в 1996 году. Уже в следующем году появился HTTP 1.1.
Прошло еще около 20 лет, прежде чем в 2015 году был стандартизирован HTTP 2. А в 2022 был официально стандартизирован HTTP 3.
HTTP 1.1:
☑️ Постоянные соединения — повторное использование соединений вместо открытия новых.
☑️ Передачи кусками — отправляет данные по частям, не дожидаясь полного ответа.
☑️ Улучшенное кэширование — введены заголовки для лучшего кэширования и управления соединениями.
X Последовательные запросы — запросы блокируют друг друга (HoL-блокировка на уровне запроса)
X Необходимо несколько подключений — браузеры использовали несколько TCP-подключений для скорости
В нем были представлены основные функции, которые используются и по сей день.
HTTP2:
☑️ Мультиплексирование — несколько запросов в одном TCP-соединении
☑️ Сжатие заголовков (HPACK) — Уменьшает размер метаданных
☑️ Приоритезация потоков — обеспечивает загрузку критически важных ресурсов в первую очередь
X Блокировка заголовка очереди (HoL) — потерянный пакет блокирует все потоки
Хотя HTTP 2 оптимизировал TCP, он оставался ограниченным блокировкой начала очереди TCP.
HTTP3:
☑️ Построен на QUIC (UDP) — больше никаких узких мест TCP
☑️ Независимые потоки — потеря пакетов в одном потоке не влияет на другие
☑️ Более быстрые рукопожатия — Объединяет настройку транспорта и шифрования за один шаг
☑️ Обязательное шифрование (TLS 1.3) — Безопасность по умолчанию
☑️ Миграция подключений — плавный переход между изменениями в сети
Вкратце: HTTP 2 оптимизировал TCP, но HTTP 3 с помощью QUIC, делает сетевое взаимодействие быстрее, надежнее и зашифрованным по умолчанию
👍14❤5👏2
Шпаргалка по различным типам баз данных:
🔹 Реляционные БД
Хранят данные в таблицах со строками и столбцами, что позволяет выполнять сложные запросы и транзакции с высокой степенью согласованности и целостности, что идеально подходит для структурированных данных, которые хорошо вписываются в схемы.
🔹 Хранилища Ключ-Значение
Хранят данные в виде пар «ключ-значение», обеспечивая быстрый поиск по ключу, идеально подходят для сценариев, где критически важен быстрый доступ к неструктурированным данным.
🔹 In-Memort (БД в оперативной памяти)
Разработаны для обеспечения высокой скорости за счет хранения данных в оперативной памяти, а не на диске, и предлагают сверхбыстрые возможности чтения/записи, подходящие для аналитики и кэширования в реальном времени.
🔹 Документные БД
Хранят данные в виде документов JSON, BSON или XML, что делает их гибкими для хранения, извлечения и управления полуструктурированными данными.
🔹 БД с широкими столбцами (Wide column)
Используют табличный формат, но каждая строка может иметь разный набор столбцов; отлично подходит для анализа больших наборов данных с возможностью горизонтального масштабирования.
🔹 БД на основе графов
Разработаны для хранения сущностей и их взаимосвязей в графовой структуре, что позволяет эффективно запрашивать сложные и взаимосвязанные данные.
🔹 Бд на основе временных рядов (Time-series)
Оптимизированы для хранения и запроса последовательностей точек данных с течением времени, что делает их идеальными для мониторинга, отслеживания событий и аналитики в контекстах, чувствительных ко времени.
#database
🔹 Реляционные БД
Хранят данные в таблицах со строками и столбцами, что позволяет выполнять сложные запросы и транзакции с высокой степенью согласованности и целостности, что идеально подходит для структурированных данных, которые хорошо вписываются в схемы.
🔹 Хранилища Ключ-Значение
Хранят данные в виде пар «ключ-значение», обеспечивая быстрый поиск по ключу, идеально подходят для сценариев, где критически важен быстрый доступ к неструктурированным данным.
🔹 In-Memort (БД в оперативной памяти)
Разработаны для обеспечения высокой скорости за счет хранения данных в оперативной памяти, а не на диске, и предлагают сверхбыстрые возможности чтения/записи, подходящие для аналитики и кэширования в реальном времени.
🔹 Документные БД
Хранят данные в виде документов JSON, BSON или XML, что делает их гибкими для хранения, извлечения и управления полуструктурированными данными.
🔹 БД с широкими столбцами (Wide column)
Используют табличный формат, но каждая строка может иметь разный набор столбцов; отлично подходит для анализа больших наборов данных с возможностью горизонтального масштабирования.
🔹 БД на основе графов
Разработаны для хранения сущностей и их взаимосвязей в графовой структуре, что позволяет эффективно запрашивать сложные и взаимосвязанные данные.
🔹 Бд на основе временных рядов (Time-series)
Оптимизированы для хранения и запроса последовательностей точек данных с течением времени, что делает их идеальными для мониторинга, отслеживания событий и аналитики в контекстах, чувствительных ко времени.
#database
👍12❤2👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Автор YouTube-канала Attoparsec представил проект «самой бесполезной клавиатуры в мире». Она состоит из 1020 клавиш и печатает слова целиком. При этом на клавиатуре есть только 1000 популярных слов в английском языке и модификаторы окончаний, чтобы можно было слегка расширить доступный словарь.
Автор отмечает, что на реализацию проекта потратил полгода. При этом на обычной QWERTY-клавиатуре его скорость печати составляет 70-80 слов в минуту, а на 1000-клавишной — около 10.
Автор отмечает, что на реализацию проекта потратил полгода. При этом на обычной QWERTY-клавиатуре его скорость печати составляет 70-80 слов в минуту, а на 1000-клавишной — около 10.
👏13😁6💩3🍾2💊2
Microsoft неоднократно призывал обновить ОС до Windows 11 на своих компьютерах. Но если раньше для этого использовались всплывающие окна, то теперь компания рассылает электронные письма с аналогичным уведомлением. В письме говорится, что после 14 октября 2025 года Microsoft больше не будет предоставлять бесплатные обновления программного обеспечения через Центр обновления Windows, техническую поддержку или исправления безопасности для Windows 10.
И там же, в письме на гипотетический вопрос пользователей «что я должен сделать со своим старым компьютером», Microsoft дает следующий ответ: «Продайте его или утилизируйте его с помощью местной организации».
К слову, согласно некоторым оценкам, к концу поддержки Windows 10 составит 1 млрд единиц, а на данный момент «десятка» работает где-то на 58% компьютеров по всему миру. Подавляющее же большинство компьютеров, выпущенных до 2018 года, физически не соответствуют заявленным требованиям Windows 11 и обновиться не могут.
И там же, в письме на гипотетический вопрос пользователей «что я должен сделать со своим старым компьютером», Microsoft дает следующий ответ: «Продайте его или утилизируйте его с помощью местной организации».
К слову, согласно некоторым оценкам, к концу поддержки Windows 10 составит 1 млрд единиц, а на данный момент «десятка» работает где-то на 58% компьютеров по всему миру. Подавляющее же большинство компьютеров, выпущенных до 2018 года, физически не соответствуют заявленным требованиям Windows 11 и обновиться не могут.
😢20🤮10👍5🤬5😁3🤔2🥱1
Шаблоны проектирования — это многоразовые решения распространенных проблем, которые можно применять на разных языках и платформах.
Они делятся на три категории:
🟢 Порождающие паттерны (𝗖𝗿𝗲𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): гибко управляют созданием объектов
🟣 Структурные паттерны (𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): организуют объекты в более крупные структуры
🟡 Поведенческие паттерны (𝗕𝗲𝗵𝗮𝘃𝗶𝗼𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): управляют тем, как объекты взаимодействуют друг с другом.
Наиболее распространенные 7 шаблонов:
𝟭. 𝗦𝗶𝗻𝗴𝗹𝗲𝘁𝗼𝗻 - Гарантирует существование только одного экземпляра
𝟮. 𝗕𝘂𝗶𝗹𝗱𝗲𝗿 - Строит сложные объекты шаг за шагом
𝟯. 𝗙𝗮𝗰𝘁𝗼𝗿𝘆 - Создает объекты без указания точного класса
𝟰. 𝗙𝗮𝗰𝗮𝗱𝗲 - Упрощает сложные системы с помощью понятного, унифицированного интерфейса
𝟱. 𝗔𝗱𝗮𝗽𝘁𝗲𝗿 - Заставляет несовместимые интерфейсы работать вместе
𝟲. 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 - Динамически меняет алгоритмы
𝟳. 𝗢𝗯𝘀𝗲𝗿𝘃𝗲𝗿 - Для поддержания зависимостей между объектами
Они делятся на три категории:
🟢 Порождающие паттерны (𝗖𝗿𝗲𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): гибко управляют созданием объектов
🟣 Структурные паттерны (𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): организуют объекты в более крупные структуры
🟡 Поведенческие паттерны (𝗕𝗲𝗵𝗮𝘃𝗶𝗼𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): управляют тем, как объекты взаимодействуют друг с другом.
Наиболее распространенные 7 шаблонов:
𝟭. 𝗦𝗶𝗻𝗴𝗹𝗲𝘁𝗼𝗻 - Гарантирует существование только одного экземпляра
𝟮. 𝗕𝘂𝗶𝗹𝗱𝗲𝗿 - Строит сложные объекты шаг за шагом
𝟯. 𝗙𝗮𝗰𝘁𝗼𝗿𝘆 - Создает объекты без указания точного класса
𝟰. 𝗙𝗮𝗰𝗮𝗱𝗲 - Упрощает сложные системы с помощью понятного, унифицированного интерфейса
𝟱. 𝗔𝗱𝗮𝗽𝘁𝗲𝗿 - Заставляет несовместимые интерфейсы работать вместе
𝟲. 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 - Динамически меняет алгоритмы
𝟳. 𝗢𝗯𝘀𝗲𝗿𝘃𝗲𝗿 - Для поддержания зависимостей между объектами
❤5👍1🔥1👏1
Наиболее распростраенные архитектурные паттерны
𝟭. Слоистая урхитектура : Разделяет приложения на логические слои (Presentation, Business, Data) с определенными обязанностями. Способствует разделению ответственности между различными частями приложения и упрощает поддержку и развитие приложения
𝟮. Микросервисы: Разбивает приложения на небольшие независимые сервисы, взаимодействующие через API. Каждый реализует одну бизнес-возможность и может быть развернут независимо от других сервисов, обеспечивая автономность и непрерывную доставку
𝟯. Событийная архитектура: Использует события для асинхронной связи между компонентами. Система не ждет завершения обработки событий, что делает ее идеальной для приложений реального времени, требующих высокой масштабируемости
𝟰. 𝗦𝗽𝗮𝗰𝗲-𝗯𝗮𝘀𝗲𝗱: Использует независимые "пространства" как автономные единицы на нескольких серверах. Устраняет отдельные точки отказа в системах с большим объемом данных и преодолевает узкие места в данных и сетевые задержки
𝟱. Микроядерная архитектура: Предоставляет минимальную базовую функциональность с дополнительными службами в виде отдельных модулей. Разработчики могут изменять компоненты, не влияя на базовую функциональность, что идеально подходит для приложений, требующих настройки.
𝟲. 𝗖𝗤𝗥𝗦 (𝗖𝗼𝗺𝗺𝗮𝗻𝗱-𝗤𝘂𝗲𝗿𝘆 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗦𝗲𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻): Разделяет операции чтения и записи на отдельные модели. Улучшает производительность и масштабируемость в сложных доменах за счет независимой оптимизации каждого пути.
𝟳. Гексагональная: Изолирует бизнес-логику от внешних задач. Позволяет приложениям управляться различными источниками и разрабатываться независимо от зависимостей времени выполнения
𝟭. Слоистая урхитектура : Разделяет приложения на логические слои (Presentation, Business, Data) с определенными обязанностями. Способствует разделению ответственности между различными частями приложения и упрощает поддержку и развитие приложения
𝟮. Микросервисы: Разбивает приложения на небольшие независимые сервисы, взаимодействующие через API. Каждый реализует одну бизнес-возможность и может быть развернут независимо от других сервисов, обеспечивая автономность и непрерывную доставку
𝟯. Событийная архитектура: Использует события для асинхронной связи между компонентами. Система не ждет завершения обработки событий, что делает ее идеальной для приложений реального времени, требующих высокой масштабируемости
𝟰. 𝗦𝗽𝗮𝗰𝗲-𝗯𝗮𝘀𝗲𝗱: Использует независимые "пространства" как автономные единицы на нескольких серверах. Устраняет отдельные точки отказа в системах с большим объемом данных и преодолевает узкие места в данных и сетевые задержки
𝟱. Микроядерная архитектура: Предоставляет минимальную базовую функциональность с дополнительными службами в виде отдельных модулей. Разработчики могут изменять компоненты, не влияя на базовую функциональность, что идеально подходит для приложений, требующих настройки.
𝟲. 𝗖𝗤𝗥𝗦 (𝗖𝗼𝗺𝗺𝗮𝗻𝗱-𝗤𝘂𝗲𝗿𝘆 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗦𝗲𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻): Разделяет операции чтения и записи на отдельные модели. Улучшает производительность и масштабируемость в сложных доменах за счет независимой оптимизации каждого пути.
𝟳. Гексагональная: Изолирует бизнес-логику от внешних задач. Позволяет приложениям управляться различными источниками и разрабатываться независимо от зависимостей времени выполнения
❤7👍5👏1
Кэширование позволяет увеличить производительность приложение. И в данном случае важную роль играет коэффициент попадания в кэш (Cache Hit Ratio).
Прежде всего надо сказать, что попадаение в кэш или Cache Hit означает, что данные найдены в кэше. А промах кэша или Cache Miss означает, что данные в кэше не найдены, и надо для получения данных обращаться к хранилищу данных, например, базе данных. И каждый промах кэша — это небольшое снижение производительности.
Коэффициент попадания в кэш рассчитывается путем деления количества попаданий в кэш на общее количество поисков в кэше (попадания и промахи, общее количество запросов к кэшу) с последующим умножением на 100 для получения процента.
Cache Hit Ratio (%) = (Cache Hits / Total Lookups) x 100
Где
Cache Hit Ratio - Коэффициент попаданий в кэш (%),
Cache Hits - Число попаданий в кэш
Total Lookups - Общее количество поисков
Данный коэффициент измеряет, как часто данные извлекаются из кэша, а не из основного хранилища, что отражает эффективность работы кэша.
Проще говоря, это процент, который показывает нам, какая часть от общего числа запросов удовлетворяется кэшем, а не отправляется в основное хранилище (например, базу данных, API и т. д.).
Для контекста рассмотрим простой пример:
• Ваш сервис получает 10 запросов
• Первый запрос запрашивает кэш, ничего не находит (промах кэша / cache miss), запрашивает базу данных, а затем сохраняет результат в кэше.
• Следующие 9 запросов попадают в кэш и обслуживаются немедленно (попадаение в кэш/cache hit).
В этом сценарии у вас будет 9 попаданий в кэш из 10 общих поисков, что дает коэффициент попадания в кэш 90%.
Хотя универсальной цифры не существует, общее руководство следующее:
• Кэширование запросов к базе данных: 85-95%
• Кэширование ответов API: 95-99%
• Крупномасштабные CDN: 99%+
3 способа увеличить коэффициент попадания в кэш
• Предварительно загружайте наиболее запрашиваемые данные в кэша во время развертывания приложения или холодного запуска, чтобы избежать первоначального сильного роста промахов кэша.
• Настройте значение времени жизни (TTL). Если оно слишком короткое, элементы быстро устаревают, что приводит к пропускам. Если слишком большое, вы рискуете предоставить устаревшие данные.
• Убедитесь, что ключи уникальны, но предсказуемы, чтобы предотвратить пропуски записей в кэше.
Высокий коэффициент попадания в кэш — это хорошо, но не за счет предоставления устаревшей информации, поэтому всегда необходим баланс между эффективностью кэширования и актуальностью данных.
Прежде всего надо сказать, что попадаение в кэш или Cache Hit означает, что данные найдены в кэше. А промах кэша или Cache Miss означает, что данные в кэше не найдены, и надо для получения данных обращаться к хранилищу данных, например, базе данных. И каждый промах кэша — это небольшое снижение производительности.
Коэффициент попадания в кэш рассчитывается путем деления количества попаданий в кэш на общее количество поисков в кэше (попадания и промахи, общее количество запросов к кэшу) с последующим умножением на 100 для получения процента.
Cache Hit Ratio (%) = (Cache Hits / Total Lookups) x 100
Где
Cache Hit Ratio - Коэффициент попаданий в кэш (%),
Cache Hits - Число попаданий в кэш
Total Lookups - Общее количество поисков
Данный коэффициент измеряет, как часто данные извлекаются из кэша, а не из основного хранилища, что отражает эффективность работы кэша.
Проще говоря, это процент, который показывает нам, какая часть от общего числа запросов удовлетворяется кэшем, а не отправляется в основное хранилище (например, базу данных, API и т. д.).
Для контекста рассмотрим простой пример:
• Ваш сервис получает 10 запросов
• Первый запрос запрашивает кэш, ничего не находит (промах кэша / cache miss), запрашивает базу данных, а затем сохраняет результат в кэше.
• Следующие 9 запросов попадают в кэш и обслуживаются немедленно (попадаение в кэш/cache hit).
В этом сценарии у вас будет 9 попаданий в кэш из 10 общих поисков, что дает коэффициент попадания в кэш 90%.
Хотя универсальной цифры не существует, общее руководство следующее:
• Кэширование запросов к базе данных: 85-95%
• Кэширование ответов API: 95-99%
• Крупномасштабные CDN: 99%+
3 способа увеличить коэффициент попадания в кэш
• Предварительно загружайте наиболее запрашиваемые данные в кэша во время развертывания приложения или холодного запуска, чтобы избежать первоначального сильного роста промахов кэша.
• Настройте значение времени жизни (TTL). Если оно слишком короткое, элементы быстро устаревают, что приводит к пропускам. Если слишком большое, вы рискуете предоставить устаревшие данные.
• Убедитесь, что ключи уникальны, но предсказуемы, чтобы предотвратить пропуски записей в кэше.
Высокий коэффициент попадания в кэш — это хорошо, но не за счет предоставления устаревшей информации, поэтому всегда необходим баланс между эффективностью кэширования и актуальностью данных.
🔥11👍1