⚡️ Docker-Android - запуск Android-эмулятора в Docker-контейнере

Минимальный и настраиваемый Docker-образ с Android-эмулятором, который запускается в контейнере как сервис.

Он особенно полезен для автоматизации, CI/CD и тестирования мобильных приложений, когда нужен работающий эмулятор в изолированной среде без физического устройства.

Это Docker-образ на базе лёгкого Linux, со встроенным Android-эмулятором, поддержкой аппаратной виртуализации (KVM) и Java Runtime. Внутри контейнер поднимает эмулятор, ADB-сервер и инструменты виртуализации. Работа происходит в headless-режиме, то есть без графического интерфейса — удобно для серверов и CI.

Основные возможности:
• минималистичный образ с Android-эмулятором и ADB
• поддержка KVM и аппаратного ускорения
• выбор версии Android и типа образа
• проброс портов для ADB
• работа без GUI
• возможность подключать инструменты удалённого управления экраном

Плюсы:

✔ изолированная, воспроизводимая среда
✔ не нужен GUI
✔ удобно для автоматизации тестов
✔ поддержка аппаратного ускорения

docker-android — это удобный способ запускать Android-эмулятор как сервис внутри контейнера. Он упрощает автоматизацию тестирования и делает окружение предсказуемым и повторяемым.

https://github.com/HQarroum/docker-android

🚀 Spring Boot: настрой graceful shutdown с таймаутом

Когда сервис перезапускается (deploy / autoscaling / rolling update), без graceful shutdown часть HTTP-запросов может:
- оборваться на полпути
- вернуть 5xx
- прервать фоновые потоки слишком рано

В Spring Boot это решается одной настройкой - задаёшь таймаут на “мягкое” завершение:

✅ сервер перестанет принимать новые запросы
✅ но даст текущим запросам и бинам закончить работу
✅ и только потом завершится

Пример:

server:
shutdown: graceful

spring:
lifecycle:
timeout-per-shutdown-phase: 20s

Идеально для продакшена, особенно если у тебя:
- Kubernetes rolling update
- долгие запросы
- async обработчики / очереди
- фоновые задачи

💡 Java совет: избегай шаринга данных между потоками

Одна из главных причин багов в многопоточке - общий изменяемый state (shared mutable state). Чем больше потоков трогают одни и те же объекты - тем выше шанс словить race condition, deadlock или “плавающие” ошибки.

Что делать правильно:

✅ 1) Используй immutable-объекты
Если объект нельзя изменить - потокам нечего “делить”, и синхронизация почти не нужна.
В Java это удобно делать через record, final поля и неизменяемые коллекции.

✅ 2) Общайся через сообщения, а не через общую память
Вместо того чтобы менять общий объект - передавай события через очередь:
- BlockingQueue
- ConcurrentLinkedQueue
- Actor-style подход

Это снижает связанность и делает поведение системы предсказуемым.

Простой принцип:
Не “разделяй память”, а “разделяй сообщения”.
#Java #SoftwareDevelopment

🚀 LiteRT - универсальная основа для AI прямо на устройстве

Google представил LiteRT — новый универсальный фреймворк для on-device AI, который развивается из TensorFlow Lite и становится базой для высокопроизводительного ML и генеративного AI на устройствах.

🔥 Что важно

⚡ До 1.4× быстрее GPU-ускорение
LiteRT показывает прирост производительности на GPU по сравнению с TensorFlow Lite, снижая задержку и улучшая отклик моделей.

🌐 Кроссплатформенность
Работает на Android, iOS, macOS, Windows, Linux и Web. Использует OpenCL, OpenGL, Metal и WebGPU через новый движок.

🤖 Поддержка NPU
Добавлено ускорение на нейропроцессорах с единым API, что упрощает разработку под разные чипы и повышает скорость инференса.

⚙️ Модели из PyTorch и JAX
Есть удобная конвертация моделей, что упрощает перенос современных AI-моделей на устройство.

📦 Open-source
Фреймворк открыт и подходит для продакшена — можно строить реальные on-device AI-приложения.

LiteRT позволяет запускать современные AI и GenAI модели прямо на устройстве — быстрее, с меньшей задержкой и лучшей приватностью, без постоянной зависимости от облака.

https://developers.googleblog.com/litert-the-universal-framework-for-on-device-ai/

💡 Java-совет: WeakHashMap для кэша без утечек памяти

Если ты используешь HashMap как кэш - будь осторожен. Пока карта жива, ключи и значения не будут удалены GC, даже если они больше нигде не используются.

WeakHashMap решает эту проблему:

• Ключи хранятся через weak reference

• Если на ключ нет сильных ссылок в коде - GC может его удалить

• Запись автоматически исчезает из мапы

• Отлично подходит для кэшей, метаданных, listener-ов

Пример идеи:

• Положил объект в WeakHashMap

• Убрал на него все обычные ссылки

• GC очистил объект → запись исчезла сама

Когда использовать:

• Кэш, который не должен раздувать память
• Вспомогательные данные, завязанные на жизненный цикл объекта
• Framework-код, плагины, reflection-кэши

Когда не стоит:

• Если ключи должны жить строго контролируемо

• Если логика зависит от стабильного наличия записи

Коротко:
HashMap - контроль у тебя
WeakHashMap — контроль у GC 🧹

Полезный инструмент, если понимаешь его семантику.

⚡️Spring Boot: отправка email за 5 минут

Если нужно быстро добавить отправку писем в Java-приложение — используйте spring-boot-starter-mail.

Он уже содержит всю необходимую конфигурацию и зависимости, поэтому не нужно вручную настраивать SMTP-клиенты.

Что нужно сделать:

1. Добавить зависимость

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-mail</artifactId>
</dependency>
Настроить SMTP (например, Gmail)

spring.mail.host=smtp.gmail.com
spring.mail.port=587
spring.mail.username=your_email@gmail.com
spring.mail.password=your_app_password
spring.mail.properties.mail.smtp.auth=true
spring.mail.properties.mail.smtp.starttls.enable=true

Отправить письмо через JavaMailSender

@Autowired
private JavaMailSender mailSender;

public void sendEmail(String to, String subject, String text) {
    SimpleMailMessage message = new SimpleMailMessage();
    message.setTo(to);
    message.setSubject(subject);
    message.setText(text);
    message.setFrom("your_email@gmail.com");

    mailSender.send(message);
}

Когда это полезно:

• регистрация пользователей
• подтверждение email
• уведомления
• отчёты и алерты

Главный плюс - минимум кода и быстрая интеграция. Spring Boot берёт всю сложность настройки на себя.

🚀 CLI для управления iOS и Android устройствами

agent-device — это инструмент командной строки для управления мобильными устройствами, позволяющий AI-агентам взаимодействовать с приложениями на iOS и Android. Проект находится на ранней стадии разработки и открыт для вкладов.

🚀 Основные моменты:
- Поддержка iOS (симулятор) и Android (эмулятор).
- Основные команды: открытие приложений, взаимодействие с элементами интерфейса.
- Минимальные зависимости и работа напрямую с Node.js.
- Возможность создания и управления сессиями.

📌 GitHub: https://github.com/callstackincubator/agent-device

#typescript

🚀 Spring Boot: когда использовать static-классы, а когда Bean

Частая ошибка в Spring - использовать static-утилиты там, где нужен управляемый компонент.

Правило простое

Используйте static-классы только если:
- они не хранят состояние
- у них нет зависимостей
- не требуется mock в тестах
- не нужен AOP (логирование, транзакции и т.д.)

Во всех остальных случаях — лучше Spring Bean.

Почему это важно

Пример с static-кэшем:

public class CacheUtils {
    private static Map<String, String> cache = new HashMap<>();
}

Такой кэш:
• общий для всех потоков
• может случайно изменяться
• сложно контролировать и тестировать

нет управления жизненным циклом

Правильный подход — Bean со scope:

@Component
@Scope("request")
public class CacheService {
private Map<String, String> cache = new HashMap<>();
}
Теперь:

Spring управляет жизненным циклом

можно задать scope (request, session, singleton)

легко тестировать и мокать

можно добавить AOP

Главная мысль

Static — только для чистых функций.
Состояние и логика — пусть управляет Spring.

Spring лучше всего работает, когда управляет stateful-объектами.

🚀 Spring Boot трюк, который спасает продакшен

Если ваш сервис обращается к внешним API — рано или поздно они начнут падать, тормозить или отдавать ошибки.

Вместо ручной логики повторов используйте @Retryable.

Что это даёт:

- Автоматические повторные запросы при ошибках
- Настраиваемое количество попыток
- Exponential backoff (увеличение задержки между попытками)
- Fallback-логика через @Recover, если всё окончательно сломалось

Когда это нужно:

- Платёжные шлюзы
- Внешние API
- Микросервисы
- Любые нестабильные сети

Главная идея:

Не падай из-за временных ошибок - попробуй ещё раз.

Такая мелочь может значительно повысить стабильность системы без сложного кода.

💡 Spring Boot лайфхак: ускоряй интеграционные тесты

Если тебе нужно тестировать Spring MVC контроллеры, но не хочется поднимать всё приложение — используй @WebMvcTest.

Что это даёт

- Загружает только MVC-слой, без всего Application Context
- Тесты работают значительно быстрее
- Можно замокать сервисы через @MockBean
- Идеально для проверки контроллеров, статусов и ответов API

Когда использовать

- Тестируешь REST-контроллеры
- Нужно проверить HTTP-ответы
- Не нужна база, security, messaging и другие слои

Идея простая:

Вместо запуска всего приложения → поднимаем только веб-контекст.
Меньше зависимостей → быстрее тесты → стабильный CI.

Пример

@WebMvcTest(HelloController.class)
class HelloControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private HelloService helloService;

    @Test
    void sayHello_returnsExpectedMessage() throws Exception {
        given(helloService.getMessage()).willReturn("Hello!");

        mockMvc.perform(get("/api/hello"))
               .andExpect(status().isOk())
               .andExpect(content().string("Hello!"));
    }
}

Если тестируешь только контроллер — не поднимай всё приложение.
WebMvcTest экономит секунды на каждом тесте и минуты в CI.

⚡️ Spring Boot: полный контроль над HTTP-ответами через ResponseEntity

Если нужно управлять не только телом ответа, но и статусом и заголовками — используйте ResponseEntity.

Что это даёт:
- Явно задаёте HTTP-статус (200, 404, 201 и т.д.)
- Добавляете кастомные заголовки
- Возвращаете любой объект в body
- Контролируете поведение API на уровне протокола

Пример:

@GetMapping("/users/{id}")
public ResponseEntity<User> getUser(@PathVariable Long id) {
    User user = userService.findById(id);

    if (user == null) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND).build();
    }

    return ResponseEntity
            .status(HttpStatus.OK)
            .header("Custom-Header", "UserFound")
            .body(user);
}

• разные статусы для разных сценариев (404, 400, 204)

• REST API с чёткой семантикой
• добавление headers (pagination, tokens, meta)
• возврат пустого ответа без body

Совет:
Если метод просто возвращает данные - достаточно вернуть объект.
Если нужен контроль над HTTP - всегда ResponseEntity.

@javatg

#SpringBoot #Java #Backend #SoftwareEngineering

🚀 Ускоряем Spring Boot без изменения кода

Многие приложения тормозят не из-за бизнес-логики, а из-за логирования.
Каждый лог - это I/O операция. При высокой нагрузке это становится узким местом.

Решение - асинхронное логирование через Logback.

Что происходит:
- сообщения складываются в очередь
- отдельный поток обрабатывает их в фоне
- основной поток не блокируется
- меньше задержек и выше throughput

Настройка проста - добавьте logback-spring.xml в:
src/main/resources/

Пример конфигурации:

<configuration>

    <!-- Async wrapper -->
    <appender name="ASYNC_CONSOLE"
              class="ch.qos.logback.classic.AsyncAppender">
        <appender-ref ref="CONSOLE"/>
        <queueSize>5000</queueSize>
        <discardingThreshold>0</discardingThreshold>
        <includeCallerData>false</includeCallerData>
    </appender>

    <!-- Console appender -->
    <appender name="CONSOLE"
              class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>
%d{yyyy-MM-dd HH:mm:ss} %-5level [%thread] %logger - %msg%n
            </pattern>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="ASYNC_CONSOLE"/>
    </root>

</configuration>

Когда это особенно полезно:

• high-load сервисы
• микросервисы с большим количеством логов
• API с высокой RPS
• продакшен-окружение

⚠️ Важно: при аварийном завершении часть логов из очереди может потеряться. Для критичных логов используйте файл + async.

Маленькая настройка - большой прирост производительности.

#SpringBoot #Java #Backend #Performance

⚓️ Удобный клиент для управления вашим *arr стеком

ArrMatey — это современное мобильное приложение для управления несколькими инстансами Sonarr, Radarr и Lidarr. Оно построено на Kotlin Multiplatform с использованием Jetpack Compose для Android и SwiftUI для iOS, предлагая интуитивно понятный интерфейс и мощные функции.

🚀 Основные моменты:
- Поддержка нескольких инстансов с быстрой сменой
- Управление библиотекой с фильтрацией и сортировкой
- Интерактивный поиск и календарь предстоящих релизов
- Мониторинг загрузок в реальном времени
- Современный интерфейс с динамической темой

📌 GitHub: https://github.com/owenlejeune/ArrMatey

#kotlin

🚀 Spring Boot tip: как быстро защитить REST endpoint

С Spring Boot + Spring Security можно буквально за пару строк закрыть нужные маршруты.

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

@RestController
public class MyController {

    @GetMapping("/admin")
    public String admin() {
        return "Admin panel";
    }
}

Теперь хотим, чтобы /admin был доступен только аутентифицированным пользователям.

Добавляем конфигурацию безопасности:

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/admin").authenticated()
                .anyRequest().permitAll()
            .and()
            .httpBasic();
    }
}

Разберём, что происходит:

• authorizeRequests() - начинаем описывать правила доступа
• antMatchers("/admin").authenticated() - для /admin требуется аутентификация
• anyRequest().permitAll() - остальные маршруты публичные
• httpBasic() - включаем HTTP Basic Auth

В итоге:

• /admin защищён
• всё остальное - открыто
• минимум кода, максимум контроля

Spring Security выглядит сложно, пока не начинаешь разбирать по шагам.

А дальше можно добавлять роли, JWT, OAuth2 и более гибкие политики доступа.

🚀 Spring Boot: отправка email за несколько минут

В Spring Boot есть готовое решение для отправки писем - spring-boot-starter-mail.

Этот стартер уже включает всю необходимую конфигурацию и зависимости, поэтому вам не нужно вручную настраивать JavaMail или подключать десятки библиотек.

Достаточно добавить зависимость, указать SMTP-настройки в application.properties или application.yml, и можно сразу отправлять письма из приложения.

Spring Boot автоматически настроит JavaMailSender, а в коде останется лишь создать сообщение и отправить его.

Это один из самых простых способов добавить email-уведомления, подтверждения регистрации, сброс пароля или системные алерты в ваше приложение.

<!-- зависимость -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-mail</artifactId>
</dependency>

# application.properties
spring.mail.host=smtp.gmail.com
spring.mail.port=587
spring.mail.username=my_email@gmail.com
spring.mail.password=my_password
spring.mail.properties.mail.smtp.auth=true
spring.mail.properties.mail.smtp.starttls.enable=true

@Service
public class MailService {

    @Autowired
    private JavaMailSender mailSender;

    public void sendEmail(String to, String subject, String text) {
        SimpleMailMessage message = new SimpleMailMessage();
        message.setTo(to);
        message.setSubject(subject);
        message.setText(text);
        message.setFrom("your_email@gmail.com");

        mailSender.send(message);
    }
}