Библиотека Java разработчика

📌 Обход коллекций в Java: делаем правильно!

Часто вижу, как разработчики по привычке используют старый подход с циклом for. Сегодня напомню оптимальные способы перебора коллекций в Java.

🧠 1. Foreach (Java 5+)
Коротко, ясно, подходит для большинства задач:

for (String item : collection) {
    // обработка элемента
}

🧠 2. Метод forEach (Java 8+)
Отлично подходит для функционального стиля:

collection.forEach(item -> {
    // обработка элемента
});

⚠️ Важно: нельзя модифицировать саму коллекцию во время такого обхода!

🧠 3. Stream API (Java 8+)
Идеален для сложной обработки с фильтрацией, маппингом и т.д.:

collection.stream()
    .filter(Objects::nonNull)
    .map(String::toUpperCase)
    .forEach(System.out::println);

💡 Что выбрать?

* Простой перебор? Используй цикл foreach.
* Нужно быстро и функционально? collection.forEach().
* Сложные манипуляции? Только Stream API.

📌 Используйте современные подходы, это читаемость и удобство поддержки вашего кода!

👉@BookJava

📌 Stream API: забудьте про peek()

Метод peek() в Java Stream API выглядит удобным для отладки, но его использование в реальном коде часто приводит к проблемам.

⚠️ Почему не стоит полагаться на peek()?

* peek() — промежуточная операция, которая не гарантирует вызов функции для каждого элемента стрима.
* Поведение зависит от терминальной операции: например, при некоторых оптимизациях JDK (особенно в параллельных стримах) вызов peek() может быть пропущен или работать непредсказуемо.

💡 Пример опасного кода:

List<String> names = Stream.of("Java", "Spring", "Hibernate")
    .peek(System.out::println) // 👈 анти-паттерн!
    .collect(Collectors.toList());

🧠 Лучший подход: используйте peek() исключительно для дебага, но никогда — для изменения состояния или важных операций.

✅ Правильная замена:
Если нужно выполнить действие над каждым элементом, используйте явный и безопасный подход:

List<String> names = Stream.of("Java", "Spring", "Hibernate")
    .map(name -> {
        log.info("Processing: {}", name); // или другая логика
        return name;
    })
    .collect(Collectors.toList());

Или вообще вынесите логику за пределы стрима.

🧹 Держите код понятным и безопасным — забудьте про peek().

👉@BookJava

🧠 Dependency Inversion Principle (D в SOLID)
Зависимости должны идти от высокоуровневой политики к низкоуровневым деталям, а не наоборот. Абстракции — хозяева, реализации — обслуживающий персонал.


📌 Коротко о сути

* Модули верхнего уровня (бизнес-логика) зависят только от интерфейсов/абстракций.
* Модули нижнего уровня (база, сеть, файлы) также зависят от тех же абстракций.
* Сами абстракции не знают ничего о деталях, тем самым разрывая «бетонную» сцепку между слоями.


💡 Мини-пример (Java 17+, Spring Boot 3+)

// 1️⃣ Абстракция — контракт
public interface NotificationSender {
    void send(Message msg);
}

// 2️⃣ Верхний уровень — бизнес-служба
@Service
public class BillingService {
    private final NotificationSender sender;

    public BillingService(NotificationSender sender) {
        this.sender = sender;                 // зависим от контракта
    }

    public void bill(Client c) {
        // ...
        sender.send(new Message("Invoice #42"));
    }
}

// 3️⃣ Низкий уровень — деталь
@Component
public class EmailSender implements NotificationSender {
    public void send(Message msg) {
        // SMTP-магия
    }
}

BillingService может жить в модульном jar без spring-email-starter и SMTP-кода — протестировать его теперь элементарно.


⚠️ Где рождаются проблемы

1. Путаница DI container ≠ DIP
IoC/DI-фреймворк (Spring, CDI) — лишь удобный способ «сращивать» зависимости, но принцип работает и без контейнера (чистый constructor injection).

2. Абстракции ради галочки
Интерфейс OneImplService с единственной реализацией ломает читаемость, тесты и автоконфиг 📉.
➜ Создавай абстракцию, когда реально нужны сменяемость, тестируемость или расширяемость.

3. Утечки деталей
Если интерфейс таскает DTO из слоя хранения, ты всё ещё «протёк» к базе. Держи контракты чистыми.

4. Слепая вера в фреймворк
Жизненный цикл бинов, прокси, lazy-init — магия мешает понимать, кто кем владеет.
➜ Всегда можешь собрать объект вручную в юнит-тесте. Если сложно — запах нарушения DIP.

5. Слишком много уровней абстракций
«Контроллер → сервис → менеджер → порт → адаптер → репозиторий» превращает код в матрёшку. Дизайн важнее количества слоёв.


📝 Практические советы

* Используй constructor injection по умолчанию. Поле final = явная зависимость.
* Группируй интерфейсы по use-case, а не по технологии (например, TransferPort, а не JdbcTransferRepository).
* В тестах не мокай фреймворк — мокай контракт.
* Для одноразовых реализаций начни с class. Если появится второй вариант — быстро вынесешь интерфейс (IDE поможет).
* Проверка себя: можно ли запустить модуль верхнего уровня без нижнего? Если да — DIP соблюдён.


💬 Итог
DIP — это не про «везде интерфейсы» и не про «подключи Spring». Это про правильное направление зависимостей, которое делает код гибким, тестируемым и не заложником технологий. А проблемы возникают, когда путают инструмент с принципом и забывают, что абстракция должна прятать детали, а не выпячивать их.

👉@BookJava

Три похожих слова в Java — final, finally, finalize — но смысл у них совершенно разный. Разберёмся 🧠


🔒 final

Ключевое слово. Используется для ограничений:

* final class — нельзя наследовать.
* final method — нельзя переопределить.
* final variable — нельзя изменить значение (один раз присвоил — всё).

📌 Особенно важно для immutability и thread-safety.

final int x = 10;
x = 20; // ошибка компиляции

🧯 finally

Блок в конструкции try-catch-finally. Выполняется всегда, даже если был return или exception.

💡 Используется для освобождения ресурсов: закрытия потоков, соединений и т.д.

try {
    // что-то может выбросить исключение
} catch (Exception e) {
    // обработка ошибки
} finally {
    // всегда выполнится
}

⚰️ finalize()

Метод из Object, вызывался перед удалением объекта сборщиком мусора.

⚠️ УСТАРЕЛ с Java 9, удалён в Java 18. Не используй.

🔪 Непредсказуем, плохо работает, тормозит GC. Вместо него — AutoCloseable и try-with-resources.

@Override
protected void finalize() throws Throwable {
    System.out.println("До свидания...");
}

🧠 Важно не путать:

* final — про нельзя менять
* finally — про всегда выполнится
* finalize — про устаревший и бесполезный метод

👉@BookJava

🧠 Ленивая инициализация через Supplier — элегантная альтернатива double-checked locking

Когда нужно отложить создание тяжёлого объекта до первого обращения, многие вспоминают double-checked locking:

private volatile SomeHeavyObject obj;

public SomeHeavyObject getObj() {
    if (obj == null) {
        synchronized (this) {
            if (obj == null) {
                obj = new SomeHeavyObject();
            }
        }
    }
    return obj;
}

⚠️ Многословно, хрупко, легко ошибиться. Есть лучше.

📌 Современный подход — использовать Supplier с ленивой инициализацией:

private final Supplier<SomeHeavyObject> lazyObj = Suppliers.memoize(SomeHeavyObject::new);

public SomeHeavyObject getObj() {
    return lazyObj.get();
}

💡 Suppliers.memoize — из Guava. Он гарантирует потокобезопасную инициализацию один раз при первом вызове get().

Плюсы:
— Читается за секунду
— Потокобезопасно
— Нет дублирования кода
— Легко тестировать и заменять

🔁 Альтернатива в чистой Java: использовать AtomicReference и updateAndGet, но это уже длиннее и менее выразительно.

Если используешь Spring — можно просто обернуть бин в @Lazy. Но вне Spring, в обычных Java-приложениях или утилитах — Supplier с memoize() идеален.

👉@BookJava

Что такое механизм try-with-resources?

Механизм try-with-resources в Java — это конструкция, которая упрощает работу с ресурсами, требующими закрытия (например, файлы, сокеты, соединения с БД и т.д.). Он автоматически закрывает ресурсы после завершения блока try, избавляя от необходимости писать finally вручную.

📌 Поддерживается с Java 7
📌 Ресурсы должны реализовывать интерфейс AutoCloseable

💡 Пример:

try (BufferedReader reader = new BufferedReader(new FileReader("file.txt"))) {
    String line = reader.readLine();
    System.out.println(line);
} catch (IOException e) {
    e.printStackTrace();
}
// reader будет закрыт автоматически, даже если произойдёт исключение

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

* Уменьшает boilerplate-код
* Исключает утечки ресурсов
* Упрощает обработку исключений

⚠️ Совет:

С Java 9 можно использовать уже объявленные переменные, если они final или effectively final:

BufferedReader reader = new BufferedReader(new FileReader("file.txt"));
try (reader) {
    System.out.println(reader.readLine());
}

👉@BookJava

📌 picocli — это современная библиотека для создания CLI-приложений на Java. Она упрощает разработку командных интерфейсов, обеспечивая:

* Автоматическую генерацию --help и --version
* Поддержку подкоманд (как в git commit, git push)
* Аргументы, параметры, опции с короткими и длинными флагами (-v, --verbose)
* Интеграцию с GraalVM (подходит для нативной компиляции)
* Поддержку аннотаций (аннотируй POJO — и готово!)
* Автоматическую валидацию аргументов
* Цветной вывод и гибкое форматирование
* Интерактивный режим и автодополнение

Проект активно развивается, полностью документирован и используется в сотнях продакшн-проектов. Если ты ищешь мощную и простую в использовании CLI-библиотеку на Java — picocli отличный выбор.

https://github.com/remkop/picocli

👉@BookJava

Double-brace инициализация в Java — это идиома, которая используется для инициализации коллекций (и иногда других объектов) в краткой форме. Она выглядит как две открывающие фигурные скобки подряд {{ и имеет специфическое поведение. Пример:

import java.util.*;

List<String> list = new ArrayList<String>() {{
    add("one");
    add("two");
    add("three");
}};

Как это работает:

Double-brace инициализация — это комбинация двух конструкций:

1. Анонимный внутренний класс:

   new ArrayList<String>() { ... }
   

Создаётся новый безымянный подкласс ArrayList.

2. Инициализатор экземпляра:

   {{ ... }}
   

Это блок, который выполняется при создании объекта. В него можно вставлять вызовы методов (например, add()).

Преимущества:

* Компактный и удобочитаемый синтаксис для заполнения коллекций.
* Можно использовать в полях final, например:

  private static final Set<String> set = new HashSet<>() {{
      add("A");
      add("B");
  }};
  

Недостатки:

1. Создаётся лишний анонимный класс — это увеличивает количество байткода и может мешать сериализации.
2. Утечки памяти — если такой класс находится внутри внешнего класса, он может неявно хранить ссылку на него.
3. Читаемость — не все разработчики знают, как это работает, и это может сбивать с толку.
4. Нарушение принципов OOP — логика инициализации размещается в конструкторе, который не явно виден.

Альтернативы:

Java 8+ (через Stream и Collectors):

List<String> list = Stream.of("one", "two", "three")
                          .collect(Collectors.toList());

Статический метод инициализации:

public static List<String> createList() {
    List<String> list = new ArrayList<>();
    list.add("one");
    list.add("two");
    return list;
}

Java 9+ (immutable):

List<String> list = List.of("one", "two", "three");
Set<String> set = Set.of("A", "B");

Вывод:

Double-brace инициализация — это удобный, но потенциально опасный трюк, который не рекомендуется использовать в продакшене. Лучше предпочесть более читаемые и безопасные альтернативы, особенно с учётом новых возможностей Java 8+.

👉@BookJava

🧠@Value vs @ConfigurationProperties — не выбирай наобум

Оба способа хороши для конфигурации, но используют их по-разному. И если ты всё ещё везде пихаешь @Value, держи краткий гайд, когда лучше что:


📌 @Value — просто, но не гибко:

@Value("${my.prop}")
private String value;

✅ Хорошо для единичных значений
❌ Плохо для сложных структур, списков, валидации
❌ Трудно покрыть тестами (без TestPropertySource)
❌ Нет биндинга по префиксу → нет группировки



📌 @ConfigurationProperties — сила и масштаб:

@ConfigurationProperties(prefix = "app.feature")
public class FeatureProperties {
    private boolean enabled;
    private List<String> items;
}

💡 Используй с @EnableConfigurationProperties или аннотируй как @Component

✅ Удобно группировать и документировать
✅ Работает с вложенными структурами, коллекциями
✅ Поддерживает JSR-303 валидацию (@Validated)
✅ Легче мокать в тестах
✅ Интеграция с Spring Boot Actuator (/actuator/configprops)


⚠️ Не смешивай: не нужно тянуть @Value внутрь @ConfigurationProperties — это антипаттерн.


💬 Если конфигурация простая — @Value норм. Но как только появляется структура, коллекции, логика — всегда используй @ConfigurationProperties.

👉@BookJava

🧠 Трюк с @EventListener в Spring — убираем лишний @TransactionalEventListener

Когда тебе нужно обрабатывать события в рамках транзакции, мы часто пишем:

@TransactionalEventListener
public void handleEvent(MyEvent event) {
    // ...
}

⚠️ Но есть нюанс: @TransactionalEventListener по умолчанию срабатывает после коммита. Иногда это не очевидно и вызывает баги, особенно если ожидаешь, что событие обработается внутри транзакции.

📌 Альтернатива: обычный @EventListener, но вместе с TransactionSynchronizationManager.

💡 Сниппет:

@Component
public class MyEventHandler {

    @EventListener
    public void handle(MyEvent event) {
        if (TransactionSynchronizationManager.isActualTransactionActive()) {
            TransactionSynchronizationManager.registerSynchronization(
                new TransactionSynchronizationAdapter() {
                    @Override
                    public void afterCommit() {
                        // обработка события после коммита
                    }
                }
            );
        } else {
            // fallback: нет активной транзакции — выполняем сразу
        }
    }
}

📎 Плюсы:
— Лучше контроль: ты сам решаешь, когда обрабатывать (до/после/вне транзакции)
— Можно централизовать поведение через utility-метод
— Гибкость: логика обработки не зависит от аннотаций Spring'а

⚠️ Минус: чуть больше кода, но понятнее поведение.

👉@BookJava

🧠 Как не словить LazyInitializationException в Spring Boot + Hibernate

Одна из самых частых ошибок при работе с JPA:

org.hibernate.LazyInitializationException: failed to lazily initialize a collection

📌 Причина: лениво загружаемая коллекция (LAZY) обращается к БД вне транзакции — например, в слое контроллера или после закрытия Session.

💡 Как избежать?

✅ Решение 1: @Transactional в сервисе

Убедитесь, что вы обращаетесь к ленивым коллекциям внутри метода с @Transactional:

@Transactional
public UserDto getUser(Long id) {
    User user = userRepository.findById(id)
        .orElseThrow();

    // OK: коллекция friends будет инициализирована в транзакции
    return new UserDto(user.getName(), user.getFriends());
}

⚠️ Не используйте @Transactional в контроллерах — это плохая практика.



✅ Решение 2: Fetch Join

Подгрузите нужные данные сразу через JOIN FETCH:

@Query("SELECT u FROM User u LEFT JOIN FETCH u.friends WHERE u.id = :id")
Optional<User> findByIdWithFriends(@Param("id") Long id);

📌 Плюс: 1 запрос вместо N (N+1 проблема решается).
📌 Минус: может быть избыточная загрузка, особенно с большими коллекциями.



✅ Решение 3: DTO проекция

Лучший способ в большинстве случаев — проецировать сразу в DTO:

@Query("""
    SELECT new com.example.UserDto(u.name, f.name)
    FROM User u
    LEFT JOIN u.friends f
    WHERE u.id = :id
""")
List<UserDto> findUserWithFriendNames(@Param("id") Long id);

📌 Выгружает только нужные данные. Быстро, безопасно, эффективно.


💬 Ленивая инициализация — ок, если вы контролируете границы транзакций.
Проекции и fetch join — ваши лучшие друзья, если нужен контроль и производительность.

👉@BookJava

📌 Java Collections

👉@BookJava

🧠 Внезапная ловушка с @Transactional и self-invocation в Spring

Вы знали, что вызов метода с @Transactional внутри того же класса не активирует транзакцию? Это один из самых частых подводных камней.

📌 Почему так происходит?
Spring AOP работает через прокси. Когда вы вызываете метод this.someTransactionalMethod(), вы обходите прокси и вызываете метод напрямую — без обёртки, которая включает транзакцию.

Пример:

@Service
public class UserService {

    public void createUser() {
        // транзакция не начнётся
        this.saveUser(); 
    }

    @Transactional
    public void saveUser() {
        // ожидаем, что тут будет транзакция, но её нет
    }
}

⚠️ Итог: никакой транзакции, и вы получите баг, который сложно заметить: данные не откатываются, lazy-loading кидает LazyInitializationException, и т.д.

💡 Как правильно:

1. Вынести transactional-метод в другой бин:

@Service
public class UserSaver {
    @Transactional
    public void saveUser() { ... }
}

2. Или получить прокси текущего бина через AopContext:

public void createUser() {
    ((UserService) AopContext.currentProxy()).saveUser();
}

📌 Для второго варианта не забудьте включить:

@EnableAspectJAutoProxy(exposeProxy = true)

⚠️ Важно: Не используйте AopContext без крайней необходимости. Предпочтительнее делегировать логику в отдельный бин — это чище и легче тестируется.

👉@BookJava

🧠 Spring Boot: ленивые зависимости через ObjectProvider

Иногда сервису не нужно всегда инжектить другую зависимость при старте — только иногда по ходу работы. Но @Autowired всё равно тянет её сразу, даже если она вам пока не нужна. Это бьёт по времени старта и может вызвать циклические зависимости.

💡 Решение: использовать ObjectProvider<T>.

Пример:

@Service
public class NotificationService {

    private final ObjectProvider<EmailSender> emailSenderProvider;

    public NotificationService(ObjectProvider<EmailSender> emailSenderProvider) {
        this.emailSenderProvider = emailSenderProvider;
    }

    public void sendEmailIfEnabled(String to, String body) {
        if (featureEnabled()) {
            EmailSender sender = emailSenderProvider.getIfAvailable();
            if (sender != null) {
                sender.send(to, body);
            }
        }
    }
}

📌 ObjectProvider:

▫️не создаёт бин сразу — ленивый доступ;
▫️ позволяет проверить наличие бина (getIfAvailable() / ifAvailable(...));
▫️можно использовать stream() — для коллекций бинов.

⚠️ Это не альтернатива DI. Это способ контролировать создание и использование бинов вручную, когда это действительно нужно.

📈 Отлично помогает:

▫️при борьбе с циклическими зависимостями;
▫️для optional-бинов;
▫️чтобы ускорить старт приложения.

👉@BookJava

💡 Чем опасен @Scheduled(fixedRate) без @Transactional?

Расписание в Spring через @Scheduled — удобный способ запускать задачи по таймеру. Но часто разработчики забывают про транзакции, особенно с fixedRate, и попадают в ловушку.

📌 Пример проблемы:

@Scheduled(fixedRate = 10_000)
public void cleanUp() {
    List<Job> jobs = jobRepository.findAllByStatus(PENDING);
    jobs.forEach(job -> {
        job.setStatus(PROCESSING);
        jobRepository.save(job);
    });
}

🧨 Каждые 10 секунд метод запускается заново. Если выполнение предыдущего ещё не закончено, начнётся второй поток, который заберёт те же PENDING -записи.
В итоге — дублирование обработки, гонки, повреждение данных.

📉 Особенно критично при долгих задачах или высокой нагрузке.

✅ Решение — обернуть метод в транзакцию + использовать блокировки:

@Transactional
@Scheduled(fixedRate = 10_000)
public void cleanUp() {
    List<Job> jobs = jobRepository.findAllByStatusForUpdate(PENDING); // SELECT ... FOR UPDATE
    jobs.forEach(job -> {
        job.setStatus(PROCESSING);
        jobRepository.save(job);
    });
}

📌 Или добавить флаг “locked”, чтобы явно помечать взятые задачи.

💡 Лучше использовать @Scheduled(fixedDelay) — он ждёт завершения предыдущего запуска. Это безопаснее по умолчанию.

🧠 Подумайте о том, чтобы заменить @Scheduled на:

* Spring Batch (если сложные джобы)
* Spring Integration / Flowable / Camunda (если нужны гарантии и retry)
* Quartz (если нужен контроль и очереди)

👉@BookJava

🔧 Maven vs. Gradle: что выбрать разработчику?

Когда речь заходит о сборке Java-проектов, выбор обычно падает на два главных инструмента: Maven и Gradle. Оба давно стали стандартом индустрии, но каждый имеет свои особенности. Разберёмся, что выбрать 👇

☕ Maven — проверенная классика

✅ Строгая структура: легче читать и сопровождать
✅ Надёжность и предсказуемость сборки
✅ Большое комьюнити и множество плагинов
⚠️ XML-конфигурация громоздкая
⚠️ Медленнее по сравнению с Gradle

⚡ Gradle — гибкость и скорость

✅ Поддержка Kotlin и Groovy DSL
✅ Инкрементальные сборки и кэширование → быстрее
✅ Более гибкий подход к настройке
⚠️ Порог входа выше
⚠️ Иногда сложно отлаживать конфигурацию


💡 Вывод:

* 🔹 Выбирай Maven, если важны стабильность, простота и читаемость.
* 🔹 Выбирай Gradle, если хочешь максимум производительности и гибкости.

🎯 В крупных проектах Gradle становится всё популярнее, особенно при использовании Kotlin. Но в enterprise-среде Maven по-прежнему правит бал.

А ты чем пользуешься? Делись опытом в комментах ⬇️

👉@BookJava

🧠 Трюк с @Configuration и @ComponentScan: как не словить баг при миграции на Spring Boot 3+

Когда вы выносите конфигурацию в отдельный модуль или создаёте библиотеку с @Configuration-классами — не забывайте:

📌 Spring Boot 3+ по умолчанию НЕ сканирует пакеты вне стартового (main).

Пример:

// Внутри библиотеки
@Configuration
public class MyLibConfig {
    @Bean
    public MyService myService() {
        return new MyService();
    }
}

И вы такие:

@SpringBootApplication
public class App {
    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

🔥 Но MyService не создаётся! Почему?

💡 Потому что @ComponentScan по умолчанию сканирует ТОЛЬКО package текущего класса и ниже.

📌 Решения:

1. Ручной импорт конфигурации:

@SpringBootApplication
@Import(MyLibConfig.class)
public class App { ... }

2. Сделать конфигурацию @AutoConfiguration и подключить через spring.factories или META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports — актуально для библиотек.

3. Переместить MyLibConfig в подпакет стартового класса (не всегда возможно или удобно).

⚠️ Часто баг проявляется неявно: контекст стартует, но бины "теряются", и вы получаете NoSuchBeanDefinitionException в рантайме.

✅ После миграции на Spring Boot 3+ обязательно проверьте, что нужные конфигурации действительно подхватываются. Особенно, если раньше они подключались "магически".

👉@BookJava

🚀 Подборка Telegram каналов для программистов

Системное администрирование, DevOps 📌

https://t.me/bash_srv Bash Советы
https://t.me/win_sysadmin Системный Администратор Windows
https://t.me/sysadmin_girl Девочка Сисадмин
https://t.me/srv_admin_linux Админские угодья
https://t.me/linux_srv Типичный Сисадмин
https://t.me/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
https://t.me/linux_odmin Linux: Системный администратор
https://t.me/devops_star DevOps Star (Звезда Девопса)
https://t.me/i_linux Системный администратор
https://t.me/linuxchmod Linux
https://t.me/sys_adminos Системный Администратор
https://t.me/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
https://t.me/sysadminof Книги для админов, полезные материалы
https://t.me/i_odmin Все для системного администратора
https://t.me/i_odmin_book Библиотека Системного Администратора
https://t.me/i_odmin_chat Чат системных администраторов
https://t.me/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
https://t.me/sysadminoff Новости Линукс Linux

1C разработка 📌
https://t.me/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://t.me/DevLab1C 1С:Предприятие 8
https://t.me/razrab_1C 1C Разработчик
https://t.me/buh1C_prog 1C Программист | Бухгалтерия и Учёт
https://t.me/rabota1C_rus Вакансии для программистов 1С

Программирование C++📌
https://t.me/cpp_lib Библиотека C/C++ разработчика
https://t.me/cpp_knigi Книги для программистов C/C++
https://t.me/cpp_geek Учим C/C++ на примерах

Программирование Python 📌
https://t.me/pythonofff Python академия.
https://t.me/BookPython Библиотека Python разработчика
https://t.me/python_real Python подборки на русском и английском
https://t.me/python_360 Книги по Python

Java разработка 📌
https://t.me/BookJava Библиотека Java разработчика
https://t.me/java_360 Книги по Java Rus
https://t.me/java_geek Учим Java на примерах

GitHub Сообщество 📌
https://t.me/Githublib Интересное из GitHub

Базы данных (Data Base) 📌
https://t.me/database_info Все про базы данных

Мобильная разработка: iOS, Android 📌
https://t.me/developer_mobila Мобильная разработка
https://t.me/kotlin_lib Подборки полезного материала по Kotlin

Фронтенд разработка 📌
https://t.me/frontend_1 Подборки для frontend разработчиков
https://t.me/frontend_sovet Frontend советы, примеры и практика!
https://t.me/React_lib Подборки по React js и все что с ним связано

Разработка игр 📌
https://t.me/game_devv Все о разработке игр

Библиотеки 📌
https://t.me/book_for_dev Книги для программистов Rus
https://t.me/programmist_of Книги по программированию
https://t.me/proglb Библиотека программиста
https://t.me/bfbook Книги для программистов

БигДата, машинное обучение 📌
https://t.me/bigdata_1 Big Data, Machine Learning

Программирование 📌
https://t.me/bookflow Лекции, видеоуроки, доклады с IT конференций
https://t.me/rust_lib Полезный контент по программированию на Rust
https://t.me/golang_lib Библиотека Go (Golang) разработчика
https://t.me/itmozg Программисты, дизайнеры, новости из мира IT
https://t.me/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻
https://t.me/nodejs_lib Подборки по Node js и все что с ним связано
https://t.me/ruby_lib Библиотека Ruby программиста
https://t.me/lifeproger Жизнь программиста. Авторский канал.

QA, тестирование 📌
https://t.me/testlab_qa Библиотека тестировщика

Шутки программистов 📌
https://t.me/itumor Шутки программистов

Защита, взлом, безопасность 📌
https://t.me/thehaking Канал о кибербезопасности
https://t.me/xakep_2 Хакер Free

Книги, статьи для дизайнеров 📌
https://t.me/ux_web Статьи, книги для дизайнеров

Математика 📌
https://t.me/Pomatematike Канал по математике
https://t.me/phis_mat Обучающие видео, книги по Физике и Математике
https://t.me/matgeoru Математика | Геометрия | Логика

Excel лайфхак📌
https://t.me/Excel_lifehack

https://t.me/mir_teh Мир технологий (Technology World)

Вакансии 📌
https://t.me/sysadmin_rabota Системный Администратор
https://t.me/progjob Вакансии в IT