🔍 Магия sed

Нужно массово заменить строку во всех файлах проекта? sed -i — замена прямо в файлах, без открытия редактора, без скриптов.

🔹 Зачем это нужно

— Массовый рефакторинг: переименовать endpoint, обновить URL, сменить конфиг.
— Работает с пайпами и можно комбинировать с find и grep.
— Поддерживает регулярки, а не просто текстовая замена.

🔹 Как использовать

— Замена в файле: sed -i 's/old-api/new-api/g' config.yaml
— Во всех файлах рекурсивно: find . -name "*.yaml" -exec sed -i 's/old-api/new-api/g' {} +
— Удалить строки с паттерном: sed -i '/DEBUG/d' app.log
— Вставить строку после совпадения: sed -i '/server {/a\ listen 443 ssl;' nginx.conf
— На macOS: sed -i '' 's/old/new/g' file.txt (пустой суффикс бэкапа)

💡 Перед массовым sed -i всегда делайте dry run: grep -r "old-api" --include="*.yaml" — убедитесь, что замена затронет только нужные файлы. И коммитьте перед заменой, git diff покажет, если что-то пошло не так.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

☕️ Всё серьёзное начинается с аннотации

Предлагаю повесить такую аннотацию на канал:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface BoostedChannel {
    String[] unlocks() default {
        "сторис",
        "мини-шпаргалки",
        "опросы",
        "быстрые разборы"
    };
}

Тогда откроем больше форматов без перегруза основной ленты. Буст — это один клик и новый уровень доступа для канала.

🐸 Библиотека джависта

#Enterprise

🙈 Hibernate выполняет SQL не в том порядке, в котором ты его написал

Код читается сверху вниз, а Hibernate так не работает. При flush'е Hibernate складывает все действия в ActionQueue и выполняет их в строго фиксированном порядке по типу операции, а не по порядку вызова в коде:

1. orphan removal
2. INSERT
3. UPDATE
4. удаление коллекций
5. обновление коллекций
6. вставка коллекций
7. DELETE

Классический пример с unique-ограничением:

repo.delete(oldRow);     // (1) в коде сначала удаляем
repo.save(newRow);       // (2) потом вставляем с тем же unique-значением
// commit -> ConstraintViolationException

На flush Hibernate переставит это в INSERT → DELETE. Вставка отработает до удаления, ловит конфликт по уникальному ключу, и падает, хотя в твоём коде последовательность была валидной.

Варианты решения:

— явный flush() между операциями, чтобы зафиксировать порядок;
— deferred (отложенные) constraints на стороне БД;
— пересмотр модели, чтобы коллизии в принципе не возникало.

Главное не считать, что порядок методов = порядок SQL. Это не так (для Hibernate).

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava

👀 Умеете строить предсказуемую архитектуру с ИИ? Станьте спикером Proglib academy

Мы в Proglib.academy запускаем курс по Spec-Driven Development (SDD) — учим разработчиков управлять ИИ-агентами (Cursor, Copilot, Claude) через спецификации, контекст и тесты, чтобы не перепроверять за нейросетью каждую строку.

Для этого курса мы ищем классных спикеров-практиков.

➡️ Что требуется от вас?

● BigTech бэкграунд: опыт работы разработчиком, тимлидом или архитектором в крупных технологических компаниях.
● Опыт управляемой разработки с ИИ: вы на практике знаете, как встроить AI-инструменты в личный или командный workflow (от постановки задачи до ревью AI-кода).
● Системный подход: умение превращать хаотичную генерацию кода в предсказуемый инженерный процесс (работа с архитектурой, чек-листами, легаси и покрытием тестами).

➡️ Что мы предлагаем?

● Достойную оплату за подготовку материалов и проведение занятий.
● Мощное продвижение личного бренда через медиаресурсы Proglib (наша аудитория — 1 млн+ айтишников).
● Возможность публиковать свои экспертные материалы и статьи на наших площадках.
● Доступ к сильному и закрытому профессиональному сообществу.

Также мы ищем консультанта программы.

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

➡️ Как с нами связаться:

Telegram: @alinaa_kh
E-mail: alina@proglib.io

😮 Топ-вакансий для джавистов за неделю

Java-разработчик (backend) — офис (Минск) — Приорбанк

Java-разработчик (Middle) — удалёнка — Датаюниверс

Разработчик Java (AI поисковый ассистент) — от 475 000 ₽ — удалёнка

➡️ Еще больше топовых вакансий — в нашем канале Java jobs

🪄 Магия Spring Boot, которая тихо убивает прод

Spring Boot прекрасен ровно до того момента, пока «оно само работает» не превращается в «оно само сломалось — и непонятно, где». Собрал фичи, которые на собесе звучат как удобство, а в 3 ночи как инцидент.

1️⃣ @Transactional, который держит коннект дольше, чем надо

Метод помечен @Transactional, а внутри запрос в БД, потом HTTP-вызов во внешний сервис, потом ещё один запрос. Всё это время коннект из пула занят. Даунстрим притормозил на 2 секунды → коннект висит 2 секунды → под нагрузкой пул выгребается, и приложение встаёт колом. CPU не загружен, БД не захлёбывается, а реквесты копятся.

Транзакция должна быть короткой и без сетевых вызовов внутри. Внешние интеграции выносим за её границы.

2️⃣ Self-invocation: аннотация, которая молча не работает

@Transactional, @Async, @Cacheable живут через прокси. Зовёшь аннотированный метод из этого же класса → прокси в обход, аннотация не срабатывает.

Лечится выносом в отдельный бин или self-injection. Но сначала надо просто знать, что так бывает.

3️⃣ Open Session In View — включён по умолчанию

spring.jpa.open-in-view=true из коробки. Звучит безобидно, на деле Hibernate-сессия живёт до рендера ответа: ленивые связи подтягиваются уже в слое контроллера, и ты ловишь N+1 там, где сервис давно отработал. Плюс коннект держится дольше нужного. На дев-стенде незаметно, а под нагрузкой привет latency.

Осознанно ставим false и грузим ровно то, что нужно.

4️⃣ HikariCP с дефолтным пулом

maximum-pool-size=10 по умолчанию. Для лёгкого сервиса — ок. Под реальным трафиком — узкое горлышко, о котором узнаёшь не из кода, а из графика глубины пула под нагрузкой. Тюнить надо не «побольше», а по формуле под ядра БД и характер нагрузки. Просто выкрутить в 200 — это обменять одну проблему на дедлоки в базе.

5️⃣ Actuator, открытый наружу

/actuator/env, /configprops, /heapdump — удобно для дебага и шикарно для того, кто найдёт их в проде: креды, конфиги, дампы памяти. Многое прикрыто по умолчанию, но «давайте включим всё, чтобы видеть метрики» и приехали. Открываем точечно, прячем за security, health/metrics держим отдельно от чувствительного.

6️⃣ Ретраи без circuit breaker = retry storm

Даунстрим тормозит → добавляешь 3 ретрая с бэкоффом. Но он тормозит, потому что перегружен. Твой ретрай шлёт второй запрос, третий. Помножь на всех клиентов. За полторы минуты лёгкое замедление превращается в каскадный отказ всей системы.

Ретраи — только с circuit breaker, jitter и лимитом. Иначе ты не лечишь нагрузку, а добиваешь.

🔹 Магия Spring Boot не баг, а разумные дефолты для быстрого старта. Беда в том, что дефолты «чтобы запуститься» и дефолты «чтобы держать прод» — это разные дефолты. Сеньорность тут не в том, чтобы знать всё наизусть, а в привычке спрашивать: «а что эта аннотация делает под капотом и под нагрузкой?»

💬 Какая фича Spring Boot подставила вас в проде в последний раз?

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava

✔️ Spring-тест: рассылка ушла клиентам трижды

Подняли 3 реплики в k8s, и клиенты получили одно и то же письмо три раза 👇

📦 Задание — code review

Ежедневная рассылка счетов через @Scheduled.

@Component
@RequiredArgsConstructor
public class BillingScheduler {

    private final InvoiceService invoiceService;

    @Scheduled(cron = "0 0 9 * * *")
    public void sendDailyInvoices() {
        List<Invoice> due = invoiceService.findDueToday();
        due.forEach(invoiceService::sendAndMarkSent);
    }
}

▪️ Объясни

— Почему @Scheduled выполняется на каждой реплике и приводит к дублирующим отправкам.
— Почему «сначала проверим флаг isSent, потом отправим» не спасает от гонки между подами.
— Какие есть решения и их трейд-оффы.

Ставьте → 🔥, если нравится формат. Если нет → 🌚

💬 Решения под спойлер. Сравним, какое будет лучше.

🐸 Библиотека собеса по Java

#practise

ℹ️ Какой тип индекса выбрать в PostgreSQL

Индекс — это мощный инструмент для ускорения запросов, но не все они одинаково полезны. В PostgreSQL есть несколько типов индексов, и вот как не промахнуться с выбором:

🔹 B-tree (по умолчанию)

→ Лучший выбор для: =, <, >, BETWEEN, ORDER BY.
→ Поддерживает сортировку.
→ Используется в 90% случаев.

CREATE INDEX idx_users_name ON users(name);

🔹 Hash

→ Только для точного сравнения =.
→ Не поддерживает диапазоны, сортировку, LIKE.
→ Редко используется, но может быть быстрее B-tree на =.

CREATE INDEX idx_users_email_hash ON users USING hash(email);

🔹 GIN (Generalized Inverted Index)

→ Для массивов, jsonb, full-text search.
→ Отличен при поиске по вложенным структурам или множеству значений.

CREATE INDEX idx_data_tags ON posts USING gin(tags);

🔹 GiST (Generalized Search Tree)

→ Для геоданных (PostGIS), поиска по диапазонам, tsvector.
→ Более универсален, но медленнее в некоторых кейсах, чем GIN.

CREATE INDEX idx_events_location ON events USING gist(location);

🔹 BRIN (Block Range Index)

→ Для огромных таблиц, где данные физически упорядочены.
→ Занимает очень мало места.
→ Не всегда эффективен — зависит от корреляции данных.

CREATE INDEX idx_logs_timestamp ON logs USING brin(timestamp);

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

🔍 Магия openssl

Сертификат на проде истёк, а вы узнали от пользователей? openssl s_client покажет всю цепочку сертификатов, даты истечения и проблемы за одну команду.

🔹 Зачем это нужно

— Проверка SSL без браузера: работает на любом сервере через SSH.
— Показывает всю цепочку: leaf, intermediate, root.
— Видны даты: Not Before и Not After и можно настроить алертинг до истечения.

🔹 Как использовать
— Проверить сертификат сайта: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
— Вся цепочка: openssl s_client -connect example.com:443 -showcerts </dev/null
— Subject и issuer: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer
— Проверить локальный файл: openssl x509 -in cert.pem -noout -text
— Дней до истечения: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

ℹ️ Liveness vs Readiness vs Startup: где чаще всего путаются

Три пробы в Kubernetes решают разные задачи, но иногда бывает путаница между ними. Давайте разберемся.

🔹 Liveness — «приложение живое или его пора убить». Зафейлился → под перезапускается. Подходит для дедлоков, зависших потоков, состояний, из которых само не выйдет.

🔹 Readiness — «готово ли принимать трафик прямо сейчас». Зафейлился → под не убивается, просто выпиливается из Service. Вернулся в норму и трафик снова идёт. Это про временную недоступность: упала БД, прогревается кэш, лёг downstream.

🔹 Startup — «приложение ещё стартует». Пока активен startup probe, liveness и readiness отключены. Без него Kubernetes может прибить Spring Boot приложение, которое просто долго поднимается (привет, миграции и прогрев контекста).

Ключевая ошибка: перепутать liveness с readiness. Зафейленный readiness говорит «я живой, но занят не шли мне трафик». Зафейленный liveness — «я сломан, убей и подними заново». Перепутаешь — будешь рестартовать здоровые поды или слать трафик в мёртвые.

В Spring Boot это маппится через health groups:

management:
  endpoint:
    health:
      probes:
        enabled: true
      group:
        liveness:
          include: livenessState
        readiness:
          include: readinessState, db, redis

Если readiness включает проверку БД, под автоматически выпадет из балансировки при обрыве соединения, без единой строчки кастомного кода.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava

😮 Топ-вакансий для джавистов за неделю

Java разработчик — удалёнка — CPS.ai

Middle Backend Developer (Kotlin/Java) — удалёнка — ДжазТим

Ведущий разработчик Java — офис (Москва) — МТС Банк

➡️ Еще больше топовых вакансий — в нашем канале Java jobs