Однако, если ты опытный специалист и постоянно используешь стримы в своей работе, возможно даже для тебя будет изюминка, ради которой тебе стоит прочитать статью. Я подпишу блок для тебя как *ИЗЮМИНКА*

Захотелось рассмотреть важную тему Stream API, но чтобы сделать статью интереснее, я решил сравнить его с инструментами реактивного программирования — Flux и Mono из Project Reactor.

Начнём с того, что такое Stream и в чём его схожесть с Flux.

Stream — это тип данных в Java, который представляет собой поток элементов. Когда я объясняю ученикам, что такое поток данных, я предлагаю визуализацию: представьте реку, по которой плывут лодки. Река — это поток, лодки — это данные.

Технический момент: Stream не создаёт отдельный поток операционной системы (thread). Он выполняется в том потоке, который его вызвал (например, main). Данные идут друг за другом, последовательно. Обычно стримы конечны, хотя и есть возможность сделать их бесконечными с помощью Stream.iterate() или generate(). Тогда потоки нужно ограничивать оператором .limit(), иначе они будет работать вечно -> это приведет к сингулярности.

Мы можем преобразовать коллекции в поток данных (вызвать .stream() у коллекции) и с помощью стандартных команд обработать каждый элемент: отфильтровать (filter), изменить/преобразовать (map), ограничить количество (limit).

Небольшое отступление. Исходя из методов, можно заметить сходство Stream c Flux. Именно поэтому я и рассматриваю их в связке. Вы можете проработать 2+ года разработчикам и не разу не встретить такой тип данных как Flux и как раз чтобы у вас не было удивления, когда вы все таки встретитесь, я сравниваю именно эти инструменты. У Flux тоже есть filter, map, flatMap, take (аналог limit). И на первы взгляд вам может показаться, что это одно и тоже, но это не так, сегодня мы разберем разницу, чуть дальше по тексту.

Помним аналогию:

У нас есть река (Stream), по которой плывут лодки (данные).

А как работать с таким потоком?

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

Промежуточные — это filter, map, flatMap, limit, skip. Они не запускают обработку, а только описывают, что нужно сделать. Их можно навешивать сколько угодно. Результат такой операции — новый стрим или новый Flux.

Терминальные — это collect, forEach, reduce, subscribe. Они запускают всю цепочку. После них поток данных закрывается. Повторно использовать тот же стрим или Flux нельзя.

В Stream терминальная операция одна — без неё ничего не выполнится. Во Flux терминальная операция — это subscribe(). Без неё Flux просто ничего не делает.

Ниже разберем основные методы у стримов:

filter — метод фильтрует данные по условиям, которые вы указываете.

java

List<Integer> numbers = List.of(1, 2, 3, 4, 5);
numbers.stream()
    .filter(n -> n % 2 == 0)   // оставляем чётные
    .forEach(System.out::println); // 2, 4

map — преобразует каждый элемент. Например, мы можем пройтись стримом по списку строковых значений, взять каждый элемент, привести к верхнему регистру, а потом распечатать каждый элемент или собрать в новый список.

java

List<String> words = List.of("cat", "dog", "mouse");
words.stream()
    .map(String::toUpperCase)
    .forEach(System.out::println); // CAT, DOG, MOUSE

flatMap — разворачивает вложенные потоки. Сильный инструмент. Иногда вам представится необходимость пройтись по списку, в котором каждый отдельный элемент тоже будет являться списком. И вам нужно будет эту вложенность развернуть наизнанку, взять каждый элемент и обработать его. Например, собрать в лист.

java

List<List<String>> nested = List.of(List.of("dog", "cat"), List.of("lion", "bird"));
List<String> result = nested.stream()
    .flatMap(list -> list.stream())
    .map(String::toUpperCase)
    .toList();

limit — берём только первые N элементов. Как если бы мы сказали: «Возьми только первые пять элементов, остальные не интересуют».

java

Stream.iterate(0, i -> i + 1)
    .limit(5)
    .forEach(System.out::println); // 0,1,2,3,4

skip — пропускаем первые N элементов. Смотрим на поток, но первые три не трогаем.

java

Stream.of(1,2,3,4,5)
    .skip(2)
    .forEach(System.out::println); // 3,4,5

collect — собираем все элементы в коллекцию (в List, Set, Map). Самый частый терминальный оператор.

java

List<String> result = words.stream()
    .filter(w -> w.length() > 3)
    .collect(Collectors.toList());

forEach — работает как цикл фор, перебирает элементы и можно описать любую логику для обработки элемента внутри forEach()

reduce — сворачивает весь поток в один результат. Например, считаем сумму всех элементов.

java

int sum = Stream.of(1,2,3,4)
    .reduce(0, (a, b) -> a + b); // 10

Важное правило: стрим можно использовать только один раз. После того как ты применил терминальную операцию (collect, forEach, reduce), река пересыхает. Попытка снова вызвать операцию упадёт с ошибкой.

Правило о том, что стрим нельзя использовать второй раз, предлагаю вам запомнить. У меня был собес в Сбере, и собеседующий задал мне вопрос: можем ли мы обратиться к стриму снова? Я недолго думая сказал: «Да». Однако терминальная операция закрывает стрим, и мы больше не имеем доступа к этому стриму. Но вы можете заново запустить стрим у той же коллекции, если необходимо, или у новой коллекции, которую отфильтровали.

Предлагаю на пальцах рассмотреть пример работы стрима с преобразованием данных. Чтобы точно получилось понять всем как это работает я буду максимально подробен, чуть не забыл!

*ИЗЮМИНКА* - разбирая код мы рассмотрим что такое -> лямбда и как она создает анонимная метод. Почему именно это я считаю изюминкой, просто потому что сам долго пользовался стримами, но совсем недавно понял до конца что такое анонимный метод.

Что нам понадобится для понимания

Прежде чем писать код, разберём термины, которые часто пугают.

Анонимный метод — это метод без имени. Ты не объявляешь его отдельно, а пишешь прям на месте, где он нужен. Как если бы тебе сказали: «дай сюда действие, которое я выполню для каждого элемента». Ты берёшь и даёшь это действие тут же, не создавая отдельную функцию.

Лямбда — это способ записать анонимный метод коротко. Вместо того чтобы писать:

java

public void doSomething(String s) { // вот так выглядит обычный метод
    System.out.println(s);
}

А анонимный метод пишется чере лямбду -> ты просто оборачиваешь логику в скрытый от глаз метод, хотя это буквально реализация метода:

java

s -> System.out.println(s) // если логики много обособляешь блок кода {}

Стрелочка -> разделяет параметры и тело метода. Слева то, что приходит на вход (аргументы вашего анонимного метода), справа — что делаем.

Функциональный интерфейс — это интерфейс с одним методом. Например, Function<T, R>(принимает T, возвращает R), Consumer<T> (принимает T, ничего не возвращает), Predicate<T>(принимает T, возвращает boolean). Именно такие интерфейсы можно заменить лямбдой.

Предлагаю решить простую задачу, чтобы закрепить знания по Stream

У нас есть карта (HashMap), где ключ — имя сотрудника, значение — его грейд (Junior, Middle, Senior). Мы хотим:

1. Пройти по всем записям
2. Для каждого сотрудника с грейдом Junior изменить значение на Middle
3. Добавить приписку «(повышен)»
4. Вывести результат

Кстати я всегда для себя комментариями пишу пошагавшую инструкцию, как я сделал выше, для того чтобы мне самому было легче разрабатывать. Так что берите на заметку и не бойтесь писать черновые наброски для себя.

java

// 1. Создаём HashMap и заполняем её
Map<String, String> employees = new HashMap<>();
employees.put("Анна", "Junior");
employees.put("Борис", "Middle");
employees.put("Виктор", "Junior");
employees.put("Карим", "Senior");

// 2. Используем стрим, чтобы пройти по всем записям
Map<String, String> updatedEmployees = employees.entrySet().stream()
    // .entrySet() — получаем набор пар (ключ + значение)
    // .stream() — открываем стрим для этих пар
    
    .map(entry -> {
        // 3. Лямбда для преобразования каждой пары, помним,
        // мы создали анонимный метод в который передаем по очереди каждый элемент
        // entry — это один элемент стрима (пара "ключ=значение")
        
        String name = entry.getKey();      // достаём имя (ключ)
        String grade = entry.getValue();   // достаём грейд (значение)
        
        // 4. Если грейд Junior, то повышаем до Middle
        if ("Junior".equals(grade)) {
            grade = "Middle (повышен)";
        }
        
        // 5. Возвращаем новую пару (такое же имя, обновлённый грейд)
        return Map.entry(name, grade);
    })
    // 6. Собираем результат обратно в HashMap
    .collect(Collectors.toMap(
        Map.Entry::getKey,   // ключ оставляем тот же
        Map.Entry::getValue  // значение — возможно, изменённое
    ));

Остановимся на части кода, где вы могли заметить нетривиальную запись Map.Entry::getKey

Это ссылка на метод. Короткая запись вместо entry -> entry.getKey(). Тоже лямбда, просто ещё короче. То есть указываем объект и через :: указываем метод который будет применен.

А теперь просто представьте, как выглядел бы код, если бы мы вместо лямбд каждый раз писали обычный метод. Мы захламили бы весь код и разбираться в нем было бы значительно сложнее.

Финально закрепим как это выглядело бы на примере одного метода. Вернёмся к лямбде:

java

entry -> {
    String name = entry.getKey();
    String grade = entry.getValue();
    if ("Junior".equals(grade)) {
        grade = "Middle (повышен)";
    }
    return Map.entry(name, grade);
}

Под капотом Java превращает это в анонимный класс, примерно такой:

java

new Function<Map.Entry<String, String>, Map.Entry<String, String>>() {
    @Override
    public Map.Entry<String, String> apply(Map.Entry<String, String> entry) {
        String name = entry.getKey();
        String grade = entry.getValue();
        if ("Junior".equals(grade)) {
            grade = "Middle (повышен)";
        }
        return Map.entry(name, grade);
    }
}

В первом случае 7 строк кода, во втором — 11, плюс аннотации и модификаторы (new, Function, @Override, public, apply). Лямбда просто скрывает этот boilerplate. И оставляет синтетический сахар.

Внимательный читатель и разработчик, который первый раз встретился со стримами, подумает, почему бы не использовать просто цикл, чтобы перебирать элементы.

Мы могли бы написать:

java

for (Map.Entry<String, String> entry : employees.entrySet()) {
    // та же логика
}

И это было бы нормально. Но стрим даёт нам:

1. Декларативность — мы говорим «что сделать», а не «как сделать»
2. Цепочки — можно добавить filter, потом map, потом collect, и это читается как предложение
3. Параллельную обработку — достаточно добавить .parallelStream() вместо .stream(), и Java сама разложит задачу по ядрам
4. Ленивость — если мы напишем limit(10), стрим не будет обрабатывать все элементы, а остановится после десятого

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

Теперь мы готовы рассмотреть Flux и разобраться в его ключевых отличиях от Stream

Flux — это интструмент из Project Reactor. Это неограниченная последовательность от 0 до N элементов. Работает по системе подписки, сначала нужно описать действия, что сделать посредством методов, а потом подписаться на последовательность Flux.

Главное отличие от Stream: Stream — это данные, которые уже есть в памяти. Flux — это данные, которые ещё только придут. Может, через секунду. Может, через час. Мы заранее не знаем, когда и сколько мы всего лишь открываем соединение.

java

Flux<Integer> flux = Flux.just(1, 2, 3, 4, 5);
flux.map(i -> i * 2);
// описали действия

flux.subscribe(System.out::println);
// Подписались, после чего запустился процесс обработки

Mono — брат-близнец Flux, только для одного элемента, что в принципе следует из его названия.

Если Flux — это последовательность от 0 до N элементов, то Mono — это 0 или 1 элемент. Всё остальное то же самое: подписка, ленивость, операторы.

java

Mono<String> mono = Mono.just("Привет");
mono.map(String::toUpperCase)
    .subscribe(System.out::println);

Где используется Mono? Там, где ты ожидаешь не более одного результата:

• Запрос в БД по ID
• GET запрос по одному ресурсу
• Ответ от внешнего API, который возвращает один объект

Вот основные методы Flux:

Flux.just(1, 2, 3) — создаёт Flux из конкретных значений, которые ты перечисляешь.

Flux.fromIterable(list) — создаёт Flux из коллекции (List, Set). Всё, что есть в списке, станет элементами потока.

Flux.range(1, 10) — генерирует числа от 1 до 10. Первое число — старт, второе — сколько штук.

map(x -> x * 2) — применяет функцию к каждому элементу и возвращает новый элемент. Из числа делает число, из строки — другую строку.

filter(x -> x > 5) — пропускает дальше только те элементы, которые подходят под условие. Остальные отбрасываются.

flatMap(x -> anotherFlux(x)) — для каждого элемента вызывает асинхронную операцию (которая возвращает Flux), а потом все результаты склеивает в один общий поток. Самый мощный, но и самый сложный оператор. В целом тоже самое что и у Stream.

take(10) — берёт первые N элементов, остальные игнорирует. Если элементов меньше — возьмёт сколько есть.

collectList() — ждёт, когда поток закончится, и собирает все элементы в один List. Превращает Flux в Mono<List<T>>.

subscribe(x -> doSomething(x)) — самое главное. Подписывается на поток и запускает его. Без этого Flux ничего не делает.

Итоговые вопросы для проверки себя:

• Чем метод map() отличается от flatMap()?
• Почему Stream по умолчанию конечен, а Flux не имеет размера?
• Без чего Flux не начнет работать?
• Расскажи своими словами, что такое промежуточные и терминальные операции?

Теперь предлагаю тебе самостоятельно порешать задачки с помощью стримов, такие часто дают на собеседованиях. Мой личный опыт, каждая третья задача будет решаться с помощью Stream.

Мой тг -@karim_product на связи родной/родная ;-)

Если было полезно, поддержи подпиской. Мне будет мотивация продолжать в том же духе. Мой канал - https://t.me/+uH8Hm6kPWhU2OTc6

Каждый сервис будет иметь свою логику, свою ответственность. Сервисы одной системы могут быть написаны на разных языках программирования. Однако это не будет мешать им общаться. Так вот, общение — это буквально обмен информацией, обмен сообщениями определённого формата, который смогут понять все сервисы. Это похоже на общение между нами. Я говорю что-то, собеседник слушает информацию, дальше обрабатывает её неким образом своим мыслительным аппаратом, формирует ответное сообщение и проговаривает его вслух, адресуя голос в направлении оппонента. Для отправки сообщения нам, людям, нужно знать адресата или видеть его, чтобы обратиться к нему.

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

Теперь давайте поговорим буквально о существующих инструментах общения. Можем разделить на две модели:

Первый вариант. Общение посредством прямого обращения к существующим методам другого сервиса по URL. То есть мы знаем, что такой-то сервис имеет определённые методы, в которые мы можем обратиться. Посредством контроллеров по URL мы можем отправить понятный запрос и получить предполагаемый ответ.

Второй вариант. Общение посредством брокера сообщений, например Kafka/Rabbit. Тут всё немного сложнее, так как нас как отправителя не заботит, как будут обработаны сообщения, нас не интересует ответ на наше отправленное сообщение. Нас интересует адрес, куда будем направлять сообщения, и адрес, откуда считываем. Простыми словами: есть хранилище сообщений, где всё разложено по полкам, каждая полка подписана (topic), и мы можем направлять сообщения на одну полку или считывать сообщения только с определённой полки. Прямого взаимодействия с сервисом у нас нет.

Итак, разберём, как общаться сервисам в первом варианте. Инструменты, которые вы можете использовать:

RestTemplate — блокирующий HTTP-клиент. Прост в использовании, но не рекомендуется для новых проектов.

WebClient — реактивный. Неблокирующий асинхронный клиент на Project Reactor. Идеален для высоконагруженных систем. Обеспечивает асинхронное/реактивное общение через HTTP.

Feign Client — декларативный. Описываете интерфейс с аннотациями — Spring генерирует реализацию. Минимум кода. Обеспечивает синхронное общение через HTTP (REST).

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

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

Реактивность — это возможность системы реактивно реагировать на обновление данных. Соответственно, реактивная обработка потоков данных невозможна без асинхронной обработки. Однако не только параллельная обработка данных достигается реактивностью.

• В отличие от обычной асинхронности, реактивность работает с потоками данных (множество значений во времени), а не с единичными результатами.
• Ключевая особенность реактивности — backpressure (обратное давление): потребитель данных может замедлить работу поставщика данных при необходимости.
• Реактивность даёт декларативные операторы (map, filter, flatMap, buffer), позволяя красиво и лаконично преобразовывать потоки данных. Вы, скорее всего, подумали, что речь идёт о Stream API. Но нет: просто в реактивном программировании есть инструмент Flux<T>, который так же, как и Stream API, работает как поток данных, однако может обрабатывать поступающие данные через такие же методы асинхронно. То есть работает с поступающими данными асинхронно.

java

Flux<User> users = userRepository.findAll();
Flux<String> names = users
    .filter(u -> u.getAge() > 18)
    .map(User::getName)
    .take(10);
// ПОДПИСЫВАЕМСЯ, и только после этого начинаются обращения в БД
names.subscribe(name -> {
    System.out.println("Получено имя: " + name);
});

Посмотрите на код выше. Сразу обозначим разницу от Stream API: Flux — мы можем получать прямо из БД, это всего лишь возможность запустить поток, по которому пойдут данные. Далее мы применяем инструкции с помощью команд (map, filter, flatMap, buffer), но всё ещё в БД нет обращений. И только на этапе подписки .subscribe(name -> мы начинаем вытаскивать данные и обрабатывать их. Вот мы слегка коснулись реактивного программирования.

• В Java реактивность реализуется через Project Reactor (Mono/Flux) и Spring WebFlux, но она нужна только при высоких нагрузках или потоковой обработке — для обычного CRUD это избыточно.

Теперь рассмотрим детальнее Feign Client. Это простой в использовании инструмент. Вы определяете Java-интерфейс с аннотациями Spring MVC, а Feign автоматически генерирует реализацию HTTP-клиента. Минимум кода, всё реализовано под капотом за счёт аннотаций, вручную не нужно писать HTTP-запросы. Есть возможность кэширования. Feign Client — синхронный.

Feign Client. Если сервис должен ждать ответ прямо сейчас — Feign проще. Если нужна максимальная пропускная способность — WebClient.

Также есть такой инструмент, как WebSocket. Это способ общения посредством событий, которые приходят в открытое соединение. Теперь нет никаких запросов. Есть канал для общения между сервисами, можно реализовать формат подписок. Один сервис бесконечно отправляет сообщения, другой считывает.

Если Feign и WebClient — это когда ты звонишь другу, задаёшь вопрос, получаешь ответ и кладёшь трубку, то WebSocket — это когда вы встретились в кафе и болтаете без остановки. Оба могут говорить, когда хотят, не дожидаясь вопроса. WebSocket часто используют для чатов, игр, биржевых котировок — там, где данные должны появляться мгновенно, без постоянных «стуков» от клиента. Соединение одно, а сообщения летают туда-сюда. Но важный момент: если соединение оборвалось, данные могут потеряться. WebSocket не гарантирует доставку, как Kafka. Он про скорость, а не про надёжность.

И вот мы плавно перешли к мощнейшему инструменту — Kafka.

Kafka — это хранилище сообщений, распределённый брокер, который может хранить терабайты событий. И обещает не терять их, раздавая сотням потребителей. Если сообщение ушло в Кафку, можешь быть уверен — оно там и останется. В Кафке модель общения происходит через Consumer (потребителя) и Producer (отправителя). Сервис формирует сообщение и отправляет через продюсера сообщение в топик (topic — это подписанная полка, куда направляются сообщения; в Кафке может быть множество топиков, обычно их разделяют, чтобы разбивать информацию по блокам).

Почему Кафка — это мощно?

Потому что она даёт гарантии. At-least-once — сообщение не потеряется, но может прилететь два раза (если консьюмер упал после обработки, но до коммита). Для большинства сценариев — ок. А если нужно ровно один раз — есть exactly-once (через идемпотентность и транзакции). Кафка пишет на диск, реплицирует на несколько брокеров: один упал — другой подхватил. Ничего не теряется.

Идемпотентность — это свойство операции отдавать один и тот же ответ на один и тот же запрос независимо от количества запросов. Например: вы запрашиваете запросом объект с id=9 — метод всегда будет возвращать один и тот же объект, ответ будет одинаковым. А есть метод POST: вы отправляете запрос на создание, и ответ всегда разный, вы создаёте сущность каждый раз с разными значениями, но значение id будет меняться, ведь вы создаёте новую запись.

Порядок внутри партиции — полный. Если тебе нужно, чтобы события одного пользователя шли строго по очереди — бросай его ID в ключ, и Кафка сама положит их в одну партицию. Также ты можешь настроить consumer group — запустил несколько консьюмеров, и они разберут партиции между собой, работая параллельно.

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

Спойлер: всегда, когда нужно обмениваться событийными сообщениями между сервисами.

• Когда у тебя события летят пачками, и сервисы не должны зависеть друг от друга (отправил email, начислил бонусы, записал в аналитику — всё асинхронно).
• Когда нужно перечитывать историю (например, на лету пересчитать метрики за прошлую неделю).
• Когда ты строишь потоковую обработку (Kafka Streams, ksqlDB) или ловишь изменения из БД (CDC).
• Когда надёжность важнее миллисекунды задержки.

Минусы тоже есть:

• Сложная в настройке (кластер, партиции, репликация, ZooKeeper или KRaft — это боль, но оно того стоит). На самом деле базовая настройка не очень сложная, но гибкая настройка требует от тебя внимания к деталям.
• Задержка выше, чем у прямого HTTP (не мгновенно, но для 99% асинхронных задач — незаметно).

Итак, мы разобрали основные способы общения микросервисов — от простых синхронных вызовов до реактивных потоков и брокеров сообщений. Каждый инструмент закрывает свою зону ответственности. Feign — когда надо дёрнуть и получить ответ здесь и сейчас. WebClient — когда запросов много и жалко потоки. WebSocket — когда нужно живое общение туда-сюда без переподключения или когда стоит задача бесконечного потока временных рядов. Kafka — когда важна надёжность и асинхронность, и ты готов простить ей чуть бóльшую задержку ради гарантий и возможности переиграть историю.

Оставайся со мной на связи, я исследую мир разработки и структурные данные в своих обучающих проектах. Хочешь двигаться со мной — жду тебя в ТГ: @karim_product

"настройка передачи данных из точки А в точку Б"

Повторюсь! Кажется при чем тут летящая машина. А это символика того, что данные летят из точки А в точку Б.

Кажется, при чем тут летящая машина. А это символика того, что данные летят из точки А в точку Б.
Повторюсь! Кажется, при чем тут летящая машина. А это символика того, что данные летят из точки А в точку Б.
Так же осмелюсь сказать, что так ощущается отрыв от реальности, когда ты погружаешься в любую тему со мной =)
Поначалу это утверждение показалось мне недостаточно полным. Однако если убрать шелуху и оставить только суть, то программирование это буквально передача данных. Во время этого процесса мы можем изменять данные, но по итогу мы получаем буквально движение информации из точки А в точку Б.

И сегодня мы поговорим про точку Б — Базу данных.

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

Таблица — это удобный и структурированный подход к хранению данных, представляет собой колонки с названиями и строчки записей. Базы данных представляются в виде таблиц.

Реляционная БД (PostgreSQL, MySQL, Oracle) — из названия следует relation — связь. Связанные таблицы — это мощный инструмент для хранения данных и дальнейшего использования. Создание связи между таблицами позволит вам быстро находить информацию. Например, у вас есть таблица "мировая таблица Бренды АВТО" — внутри есть разные бренды: AUDI, Mercedes, BMW. В свою очередь, внутри, например, бренда BMW вы можете увидеть связанную таблицу автомобилей M5, 320i xDrive, M8, а внутри каждого автомобиля — таблицу с характеристиками. В такой таблице у вас появляется возможность быстро находить связанные данные и выгружать их.

Нереляционная БД — очевидно, что тут речь идет уже о самостоятельных таблицах, которые не имеют никаких связей. Это менее удобный и ограниченный инструмент для хранения данных, потому что мы не сможем связывать данные из разных таблиц между собой. У вас есть одна таблица, которая ни с чем не связана. Грустно. Однако у нее есть свои плюсы: такие таблицы удобны, когда вам достаточно одной таблицы, но необходима скорость поиска.

Вернемся к реляционным базам. Чаще всего в разработке приложений мы работаем с такими БД, потому что, как уже говорил выше, мы можем связать сущности и доставать необходимые данные в удобном формате. Вы, вероятно, обратили внимание на названия таких БД и заметили там приписку SQL.

SQL (Structured Query Language) — это структурный язык запросов, предназначенный для управления, хранения, изменения и извлечения данных в реляционных базах данных.

СУБД (система управления базами данных) — это комплекс программного обеспечения, предназначенный для создания, хранения, изменения, поиска и администрирования данных в электронном виде.

Что такое язык? На нем кто-то говорит? Да, посредством такого языка мы общаемся с БД. Пример: у вас есть друг-библиотекарь, он работает в библиотеке. В данном примере библиотека — это наша база данных, например PostgreSQL, а библиотекарь, то есть ваш друг, — это и есть движок на базе SQL. Вы говорите ему: "Принеси мне все книги по физике", и он это делает. Но так как мы общаемся посредством языка не с человеком, а с программой, то мы должны использовать строгий язык, понятный движку SQL. Правильно написанные запросы позволят доставать сгруппированные, отфильтрованные данные.

Теперь коснемся той части, с которой мы работаем как Java-разработчики. Мы пишем код, то есть достаем данные из нашего хранилища БД. Получаем, изменяем, сохраняем и удаляем данные. Нас интересует, как мы в коде можем взаимодействовать с БД. То есть мы можем писать запросы на SQL вручную. Но благо есть инструменты, которые ускоряют написание запросов.

Самый низкоуровневый инструмент — это JDBC.

JDBC (Java Database Connectivity) — прямой API для отправки SQL в БД из Java. Ты пишешь строку запроса, выполняешь, получаешь ResultSet.
Такой инструмент дает нам возможность получать данные из БД и сохранять. Однако мы получаем данные из БД в определенном формате ResultSet — табличные данные в виде строк и колонок, а нам нужно получить объекты. Ты сам вручную пишешь rs.getString("name") и кладешь в поле объекта, мапя соответствующие поля, и получаешь удобный и понятный объект для дальнейшей работы в среде Java.

Термины:

JPA (Java Persistence API) — это спецификация ORM (Object-Relational Mapping). Hibernate — самая популярная реализация. Ты работаешь с объектами Java, а JPA сама генерирует SQL, управляет кешем первого уровня, lazy-загрузкой.

Hibernate — это реализация спецификации JPA. Но если JPA — это только интерфейс (набор аннотаций и правил), то Hibernate — это конкретный код, который:

• Читает твои Java-классы с аннотациями (@Entity, @Id, @OneToMany).
• По ним генерирует SQL-запросы (CREATE, INSERT, SELECT, JOIN...).
• Выполняет эти запросы через JDBC.
• Забирает ResultSet и превращает строки обратно в Java-объекты.

ORM (Object-Relational Mapping) — это инструмент для маппинга, то есть соединяет по названию колонки значения с полями в объекте и возвращает объект. То же самое делает в обратную сторону.

JPA — это спецификация, которая еще сильнее облегчает работу с базами данных за счет сильного инструмента Hibernate. Как видно, всю магию кибер берет на себя, генерирует запросы. Внутри JPA-спецификации есть набор базовых обращений в БД. Есть еще более удобная надстройка над JPA.

JpaRepository — это часть Spring Data JPA (надстройка над JPA). Чистый JPA (без Spring) использует EntityManager и методы persist(), find(), merge(), remove(). Spring Data JPA добавляет удобные репозитории с готовыми методами.
Писать ничего не надо, всё уже есть. Если вы наследуете от JpaRepository<Type_of_Object, Type_for_ID> — внутрь дженерика передаете сначала объект, который берется за основу при работе с таблицей, к которой будете обращаться посредством Hibernate, а вторым аргументом — тип данных для вашего id:

• save(entity) — сохраняет объект (INSERT, если id=null, иначе UPDATE)
• saveAll(entities) — сохраняет список объектов (пакетно)
• findById(id) — ищет по первичному ключу, возвращает Optional
• existsById(id) — проверяет, существует ли запись с таким id
• findAll() — возвращает все записи
• findAllById(ids) — возвращает записи по списку id
• count() — возвращает количество записей
• delete(entity) — удаляет объект
• deleteById(id) — удаляет по id
• deleteAll() — удаляет всё (осторожно!)
• flush() — принудительно синхронизирует изменения с БД
• saveAndFlush(entity) — сохраняет и сразу выполняет flush

Также будут доступны производные запросы типа поиска по одному или нескольким полям. Обычно они так и называются: findByName(). Внутри по ключевому слову пишется SQL-запрос WHERE name.

После того как мы узнали про базы данных, про язык запросов SQL, теперь различаем реляционные и нереляционные. Разработчику становится важна скорость поиска и скорость вставки информации в данных.

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

Только вперед!
Вспомните: когда вы первые разы сидели за рулем, на чем был ваш фокус? На том, как не бросить сцепление, не перегазовать, поставить верную скорость и не заглохнуть. А тут еще и сверху внимание на пешеходов, другие машины. Ваш мозг был занят важнейшими процессами — переключение скоростей и контроль габаритов. Однако спустя три месяца вы внезапно для себя обнаруживаете, что способны построить маршрут сложнее, успеваете перестроиться, учитываете тормозной путь и в целом способны осваивать новые горизонты вождения. А спустя год-два вам становится интересно, как удержать машину в заносе. Это я о чем?

О том, что программирование — то же самое. Сначала вы тратите ресурсы на умение читать код, не путаться в синтаксисе. Все сложные концепции проходят вас стороной. Однако, когда ресурсы освобождаются, вы легко читаете код, пишете сами из головы, можете позволить себе фривольность в реализации: тут протестировать такой подход, в другом месте объединить дублирующий код. Потом позволяете себе зайти на территорию, ранее не доступную — территорию скорости и распределения памяти между ресурсами. И вот как раз на этом этапе вам будет интересно узнать, что там по скорости записи.

Помним, что любая операция чтения или записи данных — это физическое перемещение информации между носителем и оперативной памятью.
В зависимости от того, где хранятся физически данные, будет зависеть и скорость их поиска. Основные носители — это жесткий диск (HDD, SSD) и оперативная память RAM.

RAM читает данные за наносекунды. SSD — за миллисекунды. Разница в 1000 раз даже на самом быстром диске.

Оперативная память — мощный инструмент, но она оперативная, потому что держит данные прямо сейчас, оперативно. Как только ты отрубаешься от сети, RAM теряет все данные. Поэтому скорость RAM следует использовать с умом. Иногда это незаменимый мощный инструмент: Redis как раз позволяет пользоваться таким инструментом, как RAM, для записи и хранения данных in-memory.

Как мы можем ускорить поиск, если пользуемся памятью на жестком диске? Есть такой инструмент, как индексы. Они позволяют...

Индекс — это отдельная структура данных, которая хранит значения и ссылки на физическое расположение строк в таблице. Пример поиска:

• Таблица 10 млн строк, full scan = 500 000 чтений с диска → 2-5 секунд
• B-tree индекс = 4-5 чтений с диска → 1-2 миллисекунды

Есть основные типы индексов.

B-tree работает за O(log N). Используется в PostgreSQL, MySQL, Oracle. Применяется для равенства, диапазонов и сортировки.

Хеш работает за O(1). Живет в Redis и MEMORY-таблицах MySQL. Используй только для точного совпадения. Диапазоны и сортировку сделать будет сложно, поиск связанных сущностей — тоже, но есть мощный инструмент RediSearch, который позволит проиндексировать значения хэша, который передадим как значение.

Инвертированный индекс имеет особую скорость поиска. Работает в Elasticsearch и Lucene. Можно использовать, когда нужно искать по словам и тексту.

Важную тему затронули сегодня. Мы поговорили про базы данных: про то, как они устроены, чем отличаются реляционные от нереляционных, как мы к ним обращаемся через JDBC, JPA и Hibernate, и почему Spring Data JPA с его JpaRepository делает нашу жизнь проще.

А потом мы залезли чуть глубже. Поговорили про скорость. Понятно, что теория без практики ничего не значит. Но практика без теории — тоже, я вам скажу, ни о чем. Ты вроде делаешь, закрываешь задачки, но внутри пусто, ведь сам знаешь, что не сильно копаешь и тратишь много усилий впустую, особенно когда приходит бага. Поэтому, ребят, вникайте как можно глубже.

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

Мой ник в ТГ: @karim_product — я говорю простыми словами о сложном.

Если было полезно, поддержи подпиской. Мне будет мотивация продолжать в том же духе. Мой канал - https://t.me/+uH8Hm6kPWhU2OTc6

Дорогу осилит идущий

Готовы погрузится настолько глубоко, насколько это возможно в рамках этой статьи? Делаем. Изучая тему многопоточки, мне стало интересно, что физически происходит в процессоре. Мы написали код на JAVA компилятор, скомпилировал наш код и передал его на уровень ниже, теперь JVM превращает скомпилированный код в набор инструкций понятных процессору. Сам процессор в свою очередь состоит из ядер, каждое ядро может выполнять единовременно только одну инструкцию (в нашем понимании это один поток), это связанно с тем, что для одного ядра выделяется один управляющий, который переключает датчики в соответсвии с инструкциями. Ядра могут работать одновременно каждый со своим набором инструкций.

Внутри ядра есть регистры, ранее я называл их датчиками. Правильно будет все таки понимать их как регистры, супер быстрые ячейки, которые хранят (числа, адреса, данные) без задержки в один такт

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

Бит - это буквально два возможных состояния в транзисторе. Сдвиг бита, это переключение из двух возможных состояний, высокое напряжение или низкое, мы можем это понимать как 0 и 1.

Еще один очень интересный момент. Одно ядро и правда может выполнять один поток, однако сейчас очень мощные процессоры и ядра, которые исполняют именно аппаратный поток. Благодаря суперсклярной архитектуре один аппаратный поток может за один такт выполнить 2-6 инструкций того же потока. Называется это Hyper-Threading, он же создаёт иллюзию двух потоков на одном ядре через быстрое переключение, но в каждый момент времени инструкции исполняются только одного из них.

Мой товарищ Паша Сорокин дал четкое руководство по которому мы и двинемся в изучении многопоточки, шаг первый понять как потоки устроены внутри.

Начнем с базы, мы знаем что когда запускается Java приложения то под каждый поток выделяется свой СТЕК памяти эта область памяти так и называется STACK и там хранятся все временные переменные. Однако напомню что все остальные объекты находятся в HEAP в стеках вообще нет объектов там есть только ссылки на объекты.

Получается мы имеем объекты в HEAP и в разных стеках под разные потоки данных могут находится ссылки на один и тот же объект. Вот так мы и получаем пространство вариантов. Где каждый поток по своему хочет и будет влиять на объект. Возникающие коллизии на основе такой структуры называют Race Condition в переводе - гонка потоков. Где потоки гонятся за объектами и пытаются на них воздействовать изменять по принципу кто успел тот и съел. Результат зависит от того, какой поток успел прочитать, изменить и записать значение — это и есть Race Condition. Как раз на этом фоне и возникают ошибки, которые иногда воспроизводятся, а иногда нет. Локально зачастую причем все будет работать корректно, потому что вы запустили Сервис и тестируете один метод. Этот метод отрабатывает и ни с кем не соревнуется. А на проде возможно к тем же самым объектам в этот момент будут пытаться обратиться другие потоки и у вас с некоторой периодичностью будут возникать коллизии и вы не будете знать от чего они, потому что просто не понимаете как устроены потоки внутри.

Давайте разберем, что происходит на каждом уровне. Первый уровень -> запуск программы, буквально файл который запускает приложение. Второй уровень -> это запуск процесса в операционной системе и внутри процесса третий уровень -> где потоки делят между собой одну общую память.

Получается, что процесс - это запущенный экземпляр программы, то есть Операционная Система ОС выделяет для этого процесса определенную область памяти, выделяет ресурсы для данного приложения. А поток это легковесная единица выполнения внутри процесса, таких потоков в процессе может быть множество. Физически один реальный поток занимает одно ядро процессора, значит количество реально одновременно работающих потоков ограниченно ядрами вашего процессора. Мы помним, что потоки делят между собой память и для каждого потока свой Стек памяти.

Поговорим про методы синхронизации работы потоков между собой. КОгда мы работаем с потоками, иногда нам нужно чтобы они работали параллельно, иногда последовательно. Порой, нужно, чтобы потом проделал работу и ждал, когда он снова понадобиться. Для этого есть инструменты, давайте познакомимся с ними:

wait/notify, notifyAll - это основные методы, которые позволят управлять потоками, из названий понятно, что wait() - заставляет поток ждать, то есть уснуть, пока какое-то условие не заставит его проснуться и дальше выполнять свою работу. А вот как раз методы notify() и notifyAll() - уведомляют либо один поток, либо сразу все, о том, что пора проснуться и продолжить свою работу.

Познакомимся с понятием монитор, комната ожидания и захват монитора synchronized

Как это работает, представим, что у каждого объекта есть монитор, его можно понимать как охранник, распределитель. И есть две важные зоны:

1. Entry Set — очередь потоков, которые хотят захватить synchronized блок.
2. Wait Set — комната ожидания для потоков, которые ожидают, пока не произойдет событие и тогда они активизируются.

ВАЖНОЕ ПРАВИЛО!
Команды wait(), notify(), notifyAll() могут быть вызванны только в блоке synchronized (или метода) того объекта, чей монитор используется. Иначе выбросится IllegalMonitorStateException.

На заметку!
notify() - пробуждает любой поток из очереди потоков Wait Set, notifyAll() - будит все потоки, тако вариант лучше использовать чтобы не терять уснувшие потоки. Если будто один случайный поток, то если мы потеряем этот поток, то оставшиеся потоки будут спать вечно - так называется потерянное пробуждение (lost wakeup)

За счет синхронизации захватывается монитор объекта, у каждого объекта, который наследуется от Object, а в джава это буквально каждый объект есть встроенная блокировка, которая и называется монитором. Блок синхронизации захватывает монитор у объекта и следующие потоки отправляются в Wait Set в комнату ожиданий. За счет synchronized достигаются два главных свойства многопоточности:

Взаимное исключение (Mutual Exclusion) - гарантирует, что только один поток захвативший монитор будет производить над ним изменения в один момент времени. Достигается видимость между всеми потоками с помощью переменных volatile

Видимость (Visibility) - гарантия того, что все другие объекты увидят изменения после выхода потока из блока синхронизации.

Важно отметить, что мы говорили про блокировку у объектов, однако у класса тоже можно захватить монитор, с помощью статического метода. Помним, что статические методы и переменные относятся к классу, а не статические к объекту. Нужно так же понимать, что эти блокировки не конфликтуют друг с другом, так как одна блокирует монитор объекта this, а другая Utils.class.

Когда я первый раз разбирал задачку по многопоточке, там в начале был создан новый объект и был назван как lock, я не понимал зачем был создан объект и почему назван как блокировка. Дальше этот объект выступал монитором, который блокировал остальные потоки. И понимание этой логики к вам придет, только после того, как вы поймете, что каждый объект имеет свою одну блокировку, которую можно использовать если не хотите блокировать тот объект в котором производите логику.

Бывает, так что вы не хотите использовать монитор класса this (тот класс в котором вы находитесь), а хотите параллельно реализовывать логику в одном объекте в разных методах. Тогда вы можете передать в блок синхронизации любой другой объект, монитор которого, будет использоваться. Для этого просто создаете объект с помощью new Object(); и передаете его в блок синхронизации и теперь synchronized понимает монитор какого объекта он блокирует.

Вот тут еще хочется поговорить про концепцию happens-before, по факту это гарантия, на то, что события произошедшие до, будут считанны и известны другим потокам.

Если вы хотите управлять потоками более гибким способом, то вы можете передать не просто объект для захвата монитора, а объект new ReentrantLock(), тип данных Lock. Тогда у такого объекта вы сможете захватывать монитор и иметь дополнительные методы управления, такие как:

• tryLock() — попытаться захватить блокировку без ожидания (вернуть false, если занята).
• tryLock(timeout, unit) — ждать не бесконечно.
• lockInterruptibly() — позволить прервать ожидание блокировки.
• Справедливость (fairness) — можно создать new ReentrantLock(true), тогда блокировка будет отдаваться самому долго ждущему потоку (но медленнее).

Объект Semaphore sem = new Semaphore(3); позволит управлять количество потоков.

Deadlock (взаимная блокировка): Поток А захватил монитор одного объекта и ждет освобождения монитора у другого объекта, а тот объект находится в захвате у другого блока синхронизации и ждет освобождения первого. В итоге оба стоят вечно — программа зависла, потоки не выполняются и не реагируют.

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

Давайте притормозим тут, нам важно качественно осознать информацию выше, поэтому пушим в мастер.

git commit -m "Базовые знания по многопоточности: потоки, процессор, синхронизация, deadlock, livelock"

Поговорим про синхронные и асинхронные методы, это не обязательно многопоточка, однако для понимания работы потоков нам необходимо понимание синхронности.

Синхронный метод - это обычный метод, который работает по принципу, поток зашел в метод, начал выполнять свою работу и например обратился в базу данных с запросом, запрос обрабатывается на стороне БД, поэтому поток приложения в это время ничем не занят. И он ждет ответа. В этот момент поток не выполняет никакой работы - простаивает. Сравнить можно с покупками на рынке, вы подходите в мясной отдел и запрашиваете курицу 2 килограмма, вам говорят сейчас упакуем, вы поток, ничего полезного в этот момент не делаете, просто ждете, когда вам отдадут курицу, вы пойдете дальше выполнять свою большую задачу по закупке.

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

CompletableFuture - это контейнер для результата, которого ещё нет. Он может быть в трёх состояниях: ещё не завершён, завершён с результатом, завершён с ошибкой. Ты можешь навесить на него колбэки: что сделать, когда результат появится. Главная фишка — методы thenApply, thenCompose, thenAccept, которые позволяют строить цепочки асинхронных операций.

Пример:CompletableFuture.supplyAsync(() -> userService.getUser(123L))
.thenCompose(user -> orderService.getOrdersAsync(user))
.thenAccept(orders -> System.out.println(orders));

Такой метод, будет выполнять все запросы асинхронно, то есть он пойдет в юзер сервис, дойдет до момента, когда обратиться в бд, получит обещание, что выполнится например через 1 секунду, CompletableFuture - это значит, что выполнятся все метода последовательно. Это значит пока первый блок асинхронных методов не будет выполнен, поток не будет выполнять следующий шаг. Однако простаивать тоже не будет, он уйдет в пул потоков и будет там ждать новую работу.

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

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

Вот вам и многомировая интерпретация - потоки выбирают свою вселенную, вопрос имеют ли потоки сознание и свободу воли, чтобы выбирать какую работу они пойдут выполнять?

Какой главный риск, когда мы используем асинхронные методы Через CompletableFuture в многопоточке?

Мы знаем, что количество возможных потоков в пуле потоков ForkJoinPool.commonPool(). Равно количество ядер минус один. Итого на 8 ядерном устройстве будет доступно в пуле потоков 7 потоков. А CompletableFuture буквально берет потоки из пула потоков.

И все бы хорошо, поток получает обещание от запроса к бд внутри метода и уходит обратно в пул. Но бывает такое, что внутренние методы в рамках CompletableFuture на этапе обращения к бд встречаются с внутренними методами, которые не являются асинхронными и там поток засыпает, не переходя дальше, тогда и возникает риск захвата всех потоков, если все потоки от 7 одновременных запросов кнут на пути к бд на синхронном методе. Восьмой запрос просто не получит свободного потока и будет ждать. Девятый и десятый тоже. Очередь будет расти, приложение перестанет отвечать, а ты будешь гадать, почему всё работало на тесте, а под нагрузкой упало. Диагностировать такую проблему сложно, потому что внешне код выглядит как асинхронный, а внутри спрятана синхронная бомба замедленного действия.

Внутренние методы:
supplyAsync — запускает асинхронную операцию, которая возвращает результат
thenApply — преобразует результат (синхронно)
thenCompose — преобразует результат в новый CompletableFuture (асинхронно)
thenAccept — потребляет результат, ничего не возвращая
exceptionally — обрабатывает ошибку

Итог: проверь себя

Если ты честно осилил статью, пропустил через свой мыслительный аппарат, почувствовал сложность в осмыслении, если вопросы которые у тебя появлялись ты гуглил, чтобы закрыть пробелы, то я официально считаю тебя красавчиком. Респект тебе! Можешь закрепить материал и ответить на эти вопросы:

1. Почему потенциально может возникать гонка потоков Race Condition при создании потоков?
   Подсказка: STACK
2. За счет чего достигается создание 20, 30 и более потоков на 8 ядерном процессоре? Ведь мы знаем, что количество потоков в пуле ограниченно количеством ядер минус один.
   Подсказка: Суперсклярность ядер процессора
3. Что делает блок synchronized ? Чей монитор захватывается по умолчанию?
   В чем особенности с блоком synchronized в рамках статического метода?
   Подсказка: Только ли у объекта можно захватить монитор?
4. Почему есть риск положить приложение из за нехватки потоков при использовании Асинхронных методов посредством CompletableFuture?
   Подсказка: Всегда ли гарантия Ассинхронности на метод распространяется на внутренние методы?

Ответил на все? Значит, тему ты честно преодолел большой шаг в понимании. На этом многопоточка только начинается, дальше предлагаю тебе порешать задачки, например задача "PING-PONG" Если на какие-то вопросы ответить не можешь, пиши мне, разберем вместе. Если в статье увидел не точности или противоречия, тоже пиши мне -разберемся почистим.

Мой тг -@karim_product на связи родной/родная ;)

Почему я: моя карьера в АйТи началась в 2019 году, я стартанул в IT компании, которая делала графику для TV и далее моя карьера:

Playrix Точка А - 2д аниматор (зп 80 000) -> VFX Lead (зп 230 000)

Product Manager Точка А - Prisma PM (зп 120 000) -> Pari Match Senior PM (зп 300 000)

ВТБ проект Точка А - Java Developer (зп 340 000) -> Senior Java Developer (зп 380 000)

Есть своя игра в Steam - собрал команду из 16 человек и под моим управлением создали и выпустили игру в Steam и на VK площадках.

Разбираюсь в типовых профессиях Product/Project Manager и Java Developer. Управлял командами, побеседовал, провел более 100 CastDev для выявления болей клиентов.

Под моим наставничеством, ты сможешь освоить передовую профессию в АйТи.

Контакт для связи: https://t.me/karim_product

Продукт в котором я нуждаюсь. Всегда хотелось создать нечто полезное обществу и то что мне будет интересно. У меня есть множество идей, которые я не смогу реализовать если буду один. Именно поэтому я создаю этот продукт.

Прокладывая путь самурая, я хочу открыть дорогу тем, кто тоже хочет учиться новому и исследовать.

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

Я помогу тебе начать свой путь в IT сфере.

Если ты самурай то выбери свой путь

Сёгун (Developer) - путь разработчика, ты сможешь развиваться как Java разработчик

Сёхин (Project Manager)- путь управленца, человек который разбирается в процессах управления командой

Синрёку (Product Manager) - путь стратега, исследователь, тот кто ищет ответы на все вопросы и находит боли, которые нужно залечить

Дзимей-кенси(Networking) - путь связующего звена в мире нетворкинга

Кингаку(Investor) - путь финансиста книга Теодора Драйзера "Финансист"

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

Записывайся на консультацию @karim_product - связь через телеграмм. Я подготовил подарок тем, кто напишет мне до 14.11.2025 года.

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

Последнее время ловлю себя на мысли, что мой круг друзей сформировался.
а если быть точнее, круг закрылся.
Я всегда был очень открытым человеком, поэтому завести 100 друзей как в пословице для меня не составляло никакого труда.
И я всегда стремился к новым знакомствам, чтобы найти интересных людей, тех кто стремиться к чему то великому или духовному.
У меня сформировалось несколько кругов, друзья детства, моя компания с района (самые близкие друзья, были и будут), питерская молодежь, несколько сольных друзей. И еще куча хороший ребят, которых я тоже ни раз называл друзьями. Даже еще больше чем я перечислил.
И моей дикой энергии хватало на всех, увидеться со всеми, и в будни и на выходных, в баню сходить, в бильярд. В Москве, в Саранске, в Египте, на Камчатке.
Где только я в разных компаниях не оказывался. И все блин мои друзья, всех зову на различные мероприятия. Пытаюсь объединить.
Вернусь к началу мысли, по итогу я стал чувствовать свои ограничения. Уже внутренний я говорит "Харош, ты куда разогнался?"

Лучший друг может быть только один.

Все же слышали такую поговорку, а у меня градация, лучший друг, брат, близкий, родной человек. И все их больше и больше.
Но вот когда, начал погружаться в отношения с каждым человеком в отдельности, уже встретился с реальностью и увидел, что ко мне относятся далеко не так как я.
У одного времени нет, у другого дела какие-то непонятные, третий вообще звонит, только когда деньги занять нужно. Четвертый дружит, потому что я крутой дядя для него. Пятый, потому что у меня можно чему то научится.
А настоящих друзей 2 - 3 человека.
И вот я поставил задачу себе на 2025 год и в целом ближайшие года, почистить свой круг, от тех, кто не является моим другом и не будет им никогда.
Решил для себя ввести определение дружбы и делюсь с вами дорогие читатели, может и вам будет полезно.
В общем есть несколько негласных правил, условий, как хотите, по которым стоит определять друга.
Просто обычно об этом не говорят, в вот я хочу чтобы уже всем понятно стало как дружить, зачем и почему.

Кто такой настоящий друг?

В моем понимании, это равноценно брату, если я дружу с человеком, то я скорее хочу чтобы он стал моей семьей. Поэтому и отношение у меня к нему соответствующее.

• Проблема моего друга, это моя проблема
• Радость моего друга, моя радость
• Я отношусь к другу как к брату, переживаю за него, думаю о нем, желаю ему только добра

Вот 3 простых вроде пункта, но если их реально осознать, то вы поймете, что для меня значит друг. Тут следует отметить, что это касается всего, то есть само собой разумеющиеся вещи выходят из этих пунктов: я буду честен с другом, если увижу, что он ступил не на ту дорогу. Я сам предложу помощь если увижу что она ему нужна. Я первый подойду извиниться, если зря быканул. Я вступлюсь за него, даже если он не прав, а потом мы уже решим что с этой ситуацией делать.
"Острые козырьки" смотрели?
Вот такого отношения я хочу к себе и сам для своих друзей хочу быть таким близким.
У некоторых людей, просто нет понимания дружбы и все тут. Говорить с ними бесполезно, они просто не понимают о чем речь. Они ничего не вкладывают в слово друг или просто не умеют дружить. Такие люди на самом деле всегда остаются одни и не доверяют никому.
Так во к чему я, я подумал, что да у меня есть пару друзей, за которых я прям уверен. Но есть так же неопределенный круг, он уже закрыт, однако достаточно обширный, я вот хотел бы определиться с этим кругом в эти года и отсеять реально ненужных мне людей. А с оставшейся семьей только укреплять связи.
Конечно, чтобы у тебя были самые верные друзья, нужно самому быть хорошим другом и тогда люди к тебе потянутся.
Еще хочу выделить несколько правил для себя, по которым нужно исключать людей из круга:

• человеку без разницы как здоровье ваших родителей, жены, детей и он в целом не знает как обстоят дела у вашей семьи (это факт, такой человек тебе не друг)
• человек не звонит и не пишет вам, но если у него есть время, то может с вами встретиться по вашей инициативе (в этой категории находятся друзья детства, которых никак не получается отпустить, которые на самом деле в том детстве и остались и они вам не друзья)
• человек который не находится с вами рядом в самые важные моменты вашей жизни (мы живем иногда на три города, но самые близкие люди, всегда найдут минуточку, чтобы пережить с вами ваши хорошие моменты)

Вы в свою очередь задумайтесь, а к кому вы относитесь как к другу исходя из того текста, который я написал выше.
Думать о друге и быть другом, тоже разные вещи.
Кстати, я вообще не верю в женскую дружбу и дружбу между мужчиной и женщиной. Ладно, не то что не верю, я знаю такой дружбы нет. Могу написать статью об этом 😄

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