Java Portal | Программирование

Что такое ETL ETL расшифровывается как Extract, Transform, Load и означает процесс интеграции данных. Сначала данные извлекаются из разных источников, например из баз данных, файлов или API. Затем они преобразуются в удобный для аналитики или отчетности формат. На этом этапе может выполняться очистка от дублей и ошибок, обогащение за счет других источников, агрегация и сведение, преобразование типов и форматов, применение бизнес-правил или вычислений. После этого данные загружаются в целевую систему. Чаще всего это хранилище или витрина данных, где они используются для отчетности, BI и аналитики. ETL применяют в разных задачах. Он лежит в основе построения хранилищ, помогает при миграции данных между системами, используется для интеграции данных из разных источников, обеспечивает корректность данных для BI и отчетов, а также загружает структурированные и неструктурированные данные в data lake. Среди распространенных ETL-инструментов можно назвать Microsoft SSIS, Azure Data Factory, Talend, Oracle Data Integrator, Apache NiFi и AWS Glue. Сегодня также популярен подход ELT, при котором данные сначала извлекаются и загружаются в хранилище или big data-платформу, а все трансформации выполняются уже внутри целевой системы. 👉 Java Portal

Как сделать так, чтобы Spring-приложение динамически включало или отключало фичи без изменения Java-кода? Подсказка: условные бины — ключ к решению 👀 Условные бины позволяют управлять созданием и загрузкой бина в Spring по определённому условию. Это как if для компонентов. Так можно сделать приложение гибким -> включать и отключать фичи или менять поведение через конфиг или зависимости проекта, не меняя Java-код. Для этого используют аннотации, начинающиеся с @Conditional, которые ставят на методы с @Bean или на классы с @Component. Если условие выполнено, Spring создаёт бин. Если нет, то бин игнорируется. Примеры часто используемых аннотаций: @ConditionalOnProperty проверяет, есть ли у свойства в application.properties заданное значение. Это основной способ для feature toggling. @ConditionalOnClass проверяет, есть ли определённый класс в classpath. Удобно, если нужно создавать бин только при наличии библиотеки. @ConditionalOnMissingBean создаёт бин, только если нет другого бина такого же типа. Подходит для дефолтных или fallback-компонентов. @ConditionalOnWebApplication создаёт бин только если приложение работает как веб-приложение, например под Tomcat. 👉 Java Portal

А что если Java-приложение могло бы запускаться за миллисекунды и потреблять совсем немного памяти, как программы на Go или C++ GraalVM решает эту задачу. Он компилирует Java и Spring Boot напрямую в нативный исполняемый файл. Это происходит заранее на этапе сборки в отличие от стандартной JVM, которая компилирует код во время выполнения. В результате получается бинарь, который запускается без JVM Преимущества заметные, почти мгновенный старт, сокращенное потребление памяти, меньший размер пакета. Такой подход особенно удобен для микросервисов и облачных приложений Есть и минусы, время сборки увеличивается, а итоговый бинарь зависит от платформы. Для Linux и Windows нужны отдельные файлы в отличие от переносимого JAR По производительности GraalVM нативные образы близки к C++. Старт сопоставим по скорости. При тяжелых вычислительных задачах преимущество может быть у C++ благодаря управлению памятью на низком уровне. Но для большинства сценариев GraalVM выводит Java в ту же лигу, что и C++, сохраняя при этом безопасность и удобство разработки 👉 Java Portal

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

• Задержки + глобальная аудитория → CDN. Доставляем данные с edge-серверов, чтобы уменьшить latency. • Чтение + узкое место → кэш. Часто читаемые данные кладём в кэш, разгружая базу. • Запись + всплеск трафика → очередь. Пишем асинхронно, сглаживая пики нагрузки. • Распределённая транзакция → Saga. Координируем шаги с компенсациями между сервисами. • ACID + реляционка → SQL. Строгая консистентность и транзакции. • Гибкость + масштаб → NoSQL. Подходит для схемы без фиксированной структуры и горизонтального масштабирования. • SQL + рост → шардинг. Делим базу на шарды, чтобы тянуть нагрузку. • Нагрузка + рост → scale out. Добавляем сервера, а не апгрейдим один. • Трафик + надёжность → балансировка. Распределяем запросы для стабильности. • Критичные сервисы + отказ → резервирование. Дублируем, чтобы не было single point of failure. • Долговечность + сбои → репликация. Держим копии данных для доступности и восстановления. • Запросы + всплески → троттлинг. Ограничиваем лишние запросы. • Нагрузка + пики → автоскейлинг. Автоматически подгоняем мощность под трафик. • Реалтайм + обновления → WebSockets. Двунаправленное живое соединение. • Повтор + безопасность → идемпотентность. Повторяем операции без побочных эффектов.

👉 Java Portal

Не знаешь, как написать Dockerfile? Не переживай, Spring Boot сделает это за тебя. 😁 Вот как это работает. В Spring Boot есть встроенный механизм для сборки Docker-образов без Dockerfile. Начиная с версии 2.3, он использует buildpacks, чтобы упаковать твоё приложение вместе с JDK в стандартный OCI-образ. Образ собирается слоями: зависимости, ресурсы и твой код разделяются, что ускоряет пересборку. После этого образ можно запускать как обычный Docker-контейнер. 👉 Java Portal

Spring Boot с одной БД работает гладко. Но как только подключаешь вторую, то всё ломается. Почему и как это правильно настроить? С одной базой Spring Boot сам автоконфигурит нужные компоненты: DataSource, JdbcTemplate, EntityManagerFactory и т.д. Когда баз становится две, фреймворк не понимает, какую взять за основную. Автоконфигурация перестаёт работать, и нужно явно объявить бины для каждой, одну пометить как @Primary. А дальше подключать их через @Qualifier там, где требуется. ✏️ У кого так было? 👍 👉 Java Portal

Скучаешь? Попробуй собрать что-нибудь своё: • 3D игру • 3D-рендерер • Свой язык для JVM • свой первый блокчейн на Java • Android-приложение для Reddit И это только начало, вот целая подборка ✌️ 👉 Java Portal

ChatGPT 5 — страшное оружие в умелых руках Российский разработчик Олег Миллер, занимающий обучением и тренировкой новой модели Open AI в Сан-Франциско, рассказывает в своём блоге: • Как отключить цензуру у ChatGPT (инструкция) • Малоизвестные ИИ, с которыми вы станете богатым • Почему человечество обречено на катастрофу из-за развития ИИ За такие инсайды он может быть уволен. Поэтому блог закрытый, а ссылка на него постоянно меняется. Успей вступить: https://t.me/+39ZXIhVfAV0zMTcy

Когда ты создаешь бин в Spring, его scope определяет, сколько времени он будет жить и как именно шариться между разными частями приложения. По умолчанию все бины работают как singleton. Это значит, что Spring поднимает один экземпляр при старте и потом везде отдает именно его. Такой вариант подходит для сервисов и репозиториев, где не нужно хранить состояние. Есть вариант prototype. В этом случае при каждом запросе Spring возвращает новый экземпляр. Но если прототип внедрен внутрь singleton, то на деле получится один и тот же объект, потому что сам singleton создается один раз и сохраняет то, что ему подкинули при инициализации. В веб-приложениях добавляются дополнительные варианты. Request создает новый бин на каждый HTTP-запрос. Session закрепляет бин за конкретной пользовательской сессией, так что один и тот же объект сохраняется для одного пользователя между запросами. Application делает бин общим для всего приложения, по сути работает как singleton, но привязан к контексту сервлета. Websocket создает бин, живущий столько, сколько длится одно websocket-соединение. Если свести все в одно короткое объяснение, singleton глобален, prototype всегда создает новый объект, а веб-скоупы зависят от времени жизни запроса или сессии. 🍺 👉 Java Portal