А вы придете завтра на встречу по изучению Spring AI в 16:00 по МСК?
Anonymous Poll
41%
Да, обязательно!
47%
Хочу, но не могу...
12%
Не приду, фигню рассматриваете
👍1
Не нашел. Знаете - напишите)
2003 — завершение миссии космического аппарата Galileo, управляемое погружение в атмосферу Юпитера (чтобы избежать биологического загрязнения спутников).
#Biography #Birth_Date #Events #21Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Ты не старый. Ты опытный.
Ты выучил Java и готов к получению оффера.
Но по твоему, у тебя есть минус: тебе уже 37 лет и часть жизни позади.
Иные профессиональные навыки, иные профессиональные привычки (ведь ты же не лежал на печи 33 года?).
И ты понимаешь, что придется работать с молодыми, похожими на тех, которых ты последние лет 5 учил и посмеивался в бороду.
А теперь они будут учить тебя.
🔜 Как с этим справиться?
🔜 Как не послать 20-летнего зазнайку в пешее эротическое?
🔜 Как стерпеть свою некомпетентность и упреки от ровесников своих детей?
Давай разбираться.
Плюсы возраста
Ты умеешь работать
Практически неважно, где ты работал до этого. У тебя за плечами по-любому были проекты, авралы, кризисы. Ты не паникуешь при фразе "сроки горят" (привыкай к слову "дедлайн"😄 ), а начинаешь решать проблемы.
Если ты смог выучить Java - значит у тебя есть усидчивость и работает голова. А это 75% успеха.
Ты умеешь общаться
Ты так и так научился коммуницировать. И ты не "отбитый", такие уж точно не пойдут учить Java. А значит ты умеешь слушать и договариваться. Это очень ценный навык ("софт-скилл"😄 ).
Ты осознан
Крайне важное отличие тебя от молодых людей. Ты не пришёл в IT "по приколу", "попробовать", "временно".
У тебя есть цель, мотивация и понимание, зачем ты это делаешь.
У тебя есть дисциплина и понимание "старшинства"
Все, кто застал Советский Союз и 90-е, понимают что такое "Старший", "Начальник", "Руководитель". И если он адекватен, то для тебя в большинстве случаев не стоит вопрос о субординации. Тем более ты знаешь что значит это слово😄 .
И если ты осознано смог выучить Java в 35+ лет, ты не пойдешь бухать в рабочие дни и пропускать дейли, ведь ты пришел РАБОТАТЬ. Тебе не нужно прививать трудовую дисциплину.
Минусы возраста (давай честно)
Технологический разрыв.
Молодые схватывают новое быстрее. Тут ничего не поделать. Ты учишься вдумчиво и дольше, но надежнее.
Эйджизм
Да, он есть. Молодняк будет думать: Ну куда ему в 40 лет учить фреймворки? Ты должен заставить их удивиться.
Собственное эго
Тяжело принять, что тот, кто моложе твоей дочки, сегодня объясняет тебе, как работает Git. С этим надо внутренне бороться и побеждать.
Как не сломаться
Признай: ты джун
Опыт в другой сфере не делает тебя синьором в новой. Сними корону (если есть), и станет легче.
Используй свой возраст
Ты можешь быть посредником между хаосом молодёжи и бизнесом. Ты уже можешь объяснить заказчику то, что молодые пока не умеют формулировать.
Учись у молодых
Пусть 20-летний объяснит тебе что-то новое. Ты не потеряешь лицо — наоборот, приобретёшь союзника.
Мои советы(по традиции)
🔹 Пойми, возраст в IT - это не приговор. Соответствуй возрасту в воспитании, общении, покажи молодым, как нужно вести себя в коллективе, ведь он у тебя не первый.
🔹 Нас (кому за 35+) ценят. HR-ы напрямую об этом говорят, даже если политика компании указывает о наборе молодых. Почему? Перечитай плюсы и старайся соответствовать 😉
🔹 Если ты понимаешь, что у 20-и летнего парня и в самом деле компетенция выше твоей, постарайся забыть о его возрасте и воспринимай его как учителя. Но не позволяй грубить и потыкать возрастом.
Тем более, большинство руководителей наши ровесники и все обо всем понимают (их тоже задрали малолетки 🤣 )
Поэтому я уверен, нет никаких границ, кроме лично выстроенных у себя в голове, чтобы прийти в IT и в 45 ✌️
Главное оставаться человеком.
И быть подписанным на наш канал☺️ 😉
Понравилась статья - поделись с другом, позови его на канал и будет тебе моя благодарность🤝
😎
#motivation
Конечно эту фразу можно использовать в разных ситуациях...😉
Но сегодня мы поговорим об IT и входе в него при 35+ годах.
Ты выучил Java и готов к получению оффера.
Но по твоему, у тебя есть минус: тебе уже 37 лет и часть жизни позади.
Иные профессиональные навыки, иные профессиональные привычки (ведь ты же не лежал на печи 33 года?).
И ты понимаешь, что придется работать с молодыми, похожими на тех, которых ты последние лет 5 учил и посмеивался в бороду.
А теперь они будут учить тебя.
Давай разбираться.
Плюсы возраста
Ты умеешь работать
Практически неважно, где ты работал до этого. У тебя за плечами по-любому были проекты, авралы, кризисы. Ты не паникуешь при фразе "сроки горят" (привыкай к слову "дедлайн"
Если ты смог выучить Java - значит у тебя есть усидчивость и работает голова. А это 75% успеха.
Ты умеешь общаться
Ты так и так научился коммуницировать. И ты не "отбитый", такие уж точно не пойдут учить Java. А значит ты умеешь слушать и договариваться. Это очень ценный навык ("софт-скилл"
Ты осознан
Крайне важное отличие тебя от молодых людей. Ты не пришёл в IT "по приколу", "попробовать", "временно".
У тебя есть цель, мотивация и понимание, зачем ты это делаешь.
У тебя есть дисциплина и понимание "старшинства"
Все, кто застал Советский Союз и 90-е, понимают что такое "Старший", "Начальник", "Руководитель". И если он адекватен, то для тебя в большинстве случаев не стоит вопрос о субординации. Тем более ты знаешь что значит это слово
И если ты осознано смог выучить Java в 35+ лет, ты не пойдешь бухать в рабочие дни и пропускать дейли, ведь ты пришел РАБОТАТЬ. Тебе не нужно прививать трудовую дисциплину.
Минусы возраста (давай честно)
Технологический разрыв.
Молодые схватывают новое быстрее. Тут ничего не поделать. Ты учишься вдумчиво и дольше, но надежнее.
Эйджизм
Да, он есть. Молодняк будет думать: Ну куда ему в 40 лет учить фреймворки? Ты должен заставить их удивиться.
Собственное эго
Тяжело принять, что тот, кто моложе твоей дочки, сегодня объясняет тебе, как работает Git. С этим надо внутренне бороться и побеждать.
Как не сломаться
Признай: ты джун
Опыт в другой сфере не делает тебя синьором в новой. Сними корону (если есть), и станет легче.
Используй свой возраст
Ты можешь быть посредником между хаосом молодёжи и бизнесом. Ты уже можешь объяснить заказчику то, что молодые пока не умеют формулировать.
Учись у молодых
Пусть 20-летний объяснит тебе что-то новое. Ты не потеряешь лицо — наоборот, приобретёшь союзника.
Мои советы(по традиции)
В целом, мне приятно работать программистом, ведь это сообщество интеллектуально развитых людей.
Они, в большинстве случаев, соблюдают нормы приличия и общения, могут понять минусы и плюсы возраста.
Тут практически не услышишь мата, атмосфера общения всегда соответствует "frendly" (можете погуглить🤣 ).
И если Вы сможете влиться в этот процесс, перенять стиль и культуру общения, то возраст станет абсолютно не важным.
Главное оставаться человеком.
И быть подписанным на наш канал
Понравилась статья - поделись с другом, позови его на канал и будет тебе моя благодарность
#motivation
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥4
Please open Telegram to view this post
VIEW IN TELEGRAM
🆒3👍2 1
@JFB_admin_bot
Бот активен и выдает ссылки)))
Залетайте✈️
Если что-то не работает, перезапустите бота)))
Бот активен и выдает ссылки)))
Залетайте
Если что-то не работает, перезапустите бота)))
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Spring AI
Настройка и запуск. Историчность и RAG
В видео мы рассмотрели новый модуль Spring - Spring AI.
🔵 Написали и запустили взаимодействие с Mistral AI (по аналогии можно запустить с любой удаленной или локальной LLM).
🔵 Дали LLM память - настроив сохранение сообщений в БД.
🔵 Модифицировали входящее сообщение в LLM, добавив свою логику.
🔵 Подключили RAG (Retrieval-Augmented Generation) - архитектуру искусственного интеллекта, которая сочетает в себе поиск информации и генерацию ответов.
🔵 Как всегда немного подебажили 😜
Ссылка на Youtube
Ссылка на Рутьюб
Ссылка на GitHub - ждёт ваших звезд☺️
Смотрите, ставьте лайки, подписывайтесь на каналы!✌️
Настройка и запуск. Историчность и RAG
В видео мы рассмотрели новый модуль Spring - Spring AI.
Ссылка на Youtube
Ссылка на Рутьюб
Ссылка на GitHub - ждёт ваших звезд
Смотрите, ставьте лайки, подписывайтесь на каналы!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
Михаил Львович Цетлин (1924—1966) — советский кибернетик, математик; его интересы включали теорию автоматов, теорию управления, информатику и разработку электронных приборов.
Сергей Валерьянович Медведев (22 сентября 1927, Калуга — 28 марта 2012, Москва) — советский и российский учёный-инженер, специалист по автоматике; участвовал в разработке и производстве систем автоматики, в том числе автоматизированных систем контроля.
Андре́й Андре́евич Ма́рков (9 [22] сентября 1903, Санкт-Петербург — 11 октября 1979, Москва) — советский математик, основатель школы конструктивной математики; руководил лабораторией математической логики и структур машин.
Джон Лерой Хеннесси (англ. John LeRoy Hennessy; р. 22 сентября 1952) — американский учёный-инженер; основатель MIPS Technologies, президент Стэнфорда, лауреат премии Тьюринга за развитие архитектуры RISC, используемой в огромном числе современных процессоров.
Ральф Энтони Брукер (22 сентября 1925 — 20 ноября 2019 года) — британский компьютерный учёный, разработал язык Mark 1 Autocode, одну из первых высокоуровневых языков программирования.
1982 — запуск спутника Космос-1409 (US-K типа) — часть советской системы предупреждения о ракетном нападении «Око».
2017 — запуск спутника Космос-2522, часть системы навигации ГЛОНАСС-М.
#Biography #Birth_Date #Events #22Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Основы ООП в Java
Глава 7. Принципы проектирования и хорошего кода
DRY, KISS, YAGNI
DRY: Не повторяйся
DRY (Don't Repeat Yourself — Не повторяйся) — это принцип, который требует избегать дублирования кода, логики или данных в программе. Если один и тот же фрагмент повторяется в нескольких местах, его нужно вынести в общий элемент, чтобы изменения в одном месте автоматически отражались везде.
Почему важно: Дублирование приводит к ошибкам — если нужно исправить логику, вы рискуете забыть обновить все копии. Это усложняет поддержку кода и увеличивает его объем.
Как применять в Java: Выносите общую логику в методы, классы или утилиты. Используйте наследование, композицию или библиотеки.
Пример нарушения DRY:
Два метода в классе Calculator, которые дублируют расчет площади:
Исправление: Выносите общую часть в метод:
Нюансы:
Не путайте с WET (We Enjoy Typing — Мы любим печатать) — саркастический термин для дублирующего кода.
В ООП: Используйте абстрактные классы или интерфейсы для общих шаблонов.
В Java: Константы в enum или static final для общих значений.
Ловушка: Избыточная абстракция — не выносите, если код используется редко (связано с YAGNI).
KISS: Делай просто
KISS (Keep It Simple, Stupid — Делай просто, глупец) — принцип, который призывает к простоте в дизайне кода, алгоритмах и архитектуре. Вместо сложных конструкций выбирайте простые решения, которые легко понять и поддерживать.
Почему важно: Сложный код трудно отлаживать, тестировать и расширять. Простота снижает ошибки и ускоряет разработку.
Как применять в Java: Избегайте ненужных абстракций, используйте встроенные средства языка, пишите короткие методы.
Пример нарушения KISS:
Сложный расчет с лишними классами:
Нюансы:
"Глупец" в аббревиатуре — напоминание, что простота побеждает "умные" хаки.
В ООП: Предпочитайте композицию над глубоким наследованием.
В Java: Используйте Stream API для простых операций, но не для всего.
Ловушка: Простота не значит примитивность — балансируйте с читаемостью.
#Java #для_новичков #beginner #OOP #DRY #KISS #YAGNI
Глава 7. Принципы проектирования и хорошего кода
DRY, KISS, YAGNI
DRY: Не повторяйся
DRY (Don't Repeat Yourself — Не повторяйся) — это принцип, который требует избегать дублирования кода, логики или данных в программе. Если один и тот же фрагмент повторяется в нескольких местах, его нужно вынести в общий элемент, чтобы изменения в одном месте автоматически отражались везде.
Почему важно: Дублирование приводит к ошибкам — если нужно исправить логику, вы рискуете забыть обновить все копии. Это усложняет поддержку кода и увеличивает его объем.
Как применять в Java: Выносите общую логику в методы, классы или утилиты. Используйте наследование, композицию или библиотеки.
Пример нарушения DRY:
Два метода в классе Calculator, которые дублируют расчет площади:
public class Calculator {
// Нарушение: Дублирование
public double circleArea(double radius) {
return 3.14159 * radius * radius;
}
public double circleVolume(double radius, double height) {
return 3.14159 * radius * radius * height; // Тот же расчет площади
}
}
Исправление: Выносите общую часть в метод:
public class Calculator {
// Правильно: Общий метод
private double calculateCircleBase(double radius) {
final double PI = 3.14159;
return PI * radius * radius;
}
public double circleArea(double radius) {
return calculateCircleBase(radius);
}
public double circleVolume(double radius, double height) {
return calculateCircleBase(radius) * height;
}
}
Нюансы:
Не путайте с WET (We Enjoy Typing — Мы любим печатать) — саркастический термин для дублирующего кода.
В ООП: Используйте абстрактные классы или интерфейсы для общих шаблонов.
В Java: Константы в enum или static final для общих значений.
Ловушка: Избыточная абстракция — не выносите, если код используется редко (связано с YAGNI).
KISS: Делай просто
KISS (Keep It Simple, Stupid — Делай просто, глупец) — принцип, который призывает к простоте в дизайне кода, алгоритмах и архитектуре. Вместо сложных конструкций выбирайте простые решения, которые легко понять и поддерживать.
Почему важно: Сложный код трудно отлаживать, тестировать и расширять. Простота снижает ошибки и ускоряет разработку.
Как применять в Java: Избегайте ненужных абстракций, используйте встроенные средства языка, пишите короткие методы.
Пример нарушения KISS:
Сложный расчет с лишними классами:
// Нарушение: Избыточная сложность
public class ComplexCalculator {
public double calculate(double a, double b) {
AdvancedMathUtils utils = new AdvancedMathUtils();
return utils.performAdvancedOps(new OperationContext(a, b)).getResult();
}
}
// Куча лишних классов...
Исправление: Простой метод:
javapublic class SimpleCalculator {
public double calculate(double a, double b) {
return Math.sqrt(a * a + b * b); // Прямо и ясно
}
}
Нюансы:
"Глупец" в аббревиатуре — напоминание, что простота побеждает "умные" хаки.
В ООП: Предпочитайте композицию над глубоким наследованием.
В Java: Используйте Stream API для простых операций, но не для всего.
Ловушка: Простота не значит примитивность — балансируйте с читаемостью.
#Java #для_новичков #beginner #OOP #DRY #KISS #YAGNI
👍3
YAGNI: Тебе это не понадобится
YAGNI (You Ain't Gonna Need It — Тебе это не понадобится) — принцип, который предупреждает против добавления функциональности заранее, на основе предположений о будущем. Реализуйте только то, что нужно сейчас, чтобы избежать переусложнения.
Почему важно: Предвидение будущего часто ошибочно, и лишний код увеличивает сложность, баги и время на поддержку.
Как применять в Java: Добавляйте код по мере необходимости, используйте рефакторинг для расширений.
Пример нарушения YAGNI:
Класс с "будущими" методами:
Нюансы:
Связано с принципом "You Are Not Gonna Need It" — фокус на MVP (минимально жизнеспособном продукте).
В ООП: Не создавайте абстрактные классы "на будущее" — реализуйте, когда нужно.
В Java: Избегайте over-engineering в дизайне (например, Factory для простых объектов).
Ловушка: YAGNI не значит игнорировать планирование — используйте TDD (тест-драйвен разработку) для роста.
Полезные советы для новичков
DRY: Ищите дубли — рефакторьте в методы или утилиты.
KISS: Читайте код через день — если не понятно, упростите.
YAGNI: Задавайте: "Нужно ли это прямо сейчас?"
В Java: Используйте IDE для рефакторинга (Extract Method для DRY).
Ресурсы: Книга "Чистый код" Роберта Мартина — классика по этим принципам.
#Java #для_новичков #beginner #OOP #DRY #KISS #YAGNI
YAGNI (You Ain't Gonna Need It — Тебе это не понадобится) — принцип, который предупреждает против добавления функциональности заранее, на основе предположений о будущем. Реализуйте только то, что нужно сейчас, чтобы избежать переусложнения.
Почему важно: Предвидение будущего часто ошибочно, и лишний код увеличивает сложность, баги и время на поддержку.
Как применять в Java: Добавляйте код по мере необходимости, используйте рефакторинг для расширений.
Пример нарушения YAGNI:
Класс с "будущими" методами:
// Нарушение: Лишние методы "на всякий случай"
public class User {
private String name;
public User(String name) {
this.name = name;
}
public void sendEmail() { /* Пока пусто */ }
public void sendSMS() { /* Пока пусто */ }
public void integrateWithAPI() { /* Пока пусто */ }
}
Исправление: Только необходимое:
javapublic class User {
private String name;
public User(String name) {
this.name = name;
}
// Только базовая функциональность
public String getName() {
return name;
}
}
Нюансы:
Связано с принципом "You Are Not Gonna Need It" — фокус на MVP (минимально жизнеспособном продукте).
В ООП: Не создавайте абстрактные классы "на будущее" — реализуйте, когда нужно.
В Java: Избегайте over-engineering в дизайне (например, Factory для простых объектов).
Ловушка: YAGNI не значит игнорировать планирование — используйте TDD (тест-драйвен разработку) для роста.
Полезные советы для новичков
DRY: Ищите дубли — рефакторьте в методы или утилиты.
KISS: Читайте код через день — если не понятно, упростите.
YAGNI: Задавайте: "Нужно ли это прямо сейчас?"
В Java: Используйте IDE для рефакторинга (Extract Method для DRY).
Ресурсы: Книга "Чистый код" Роберта Мартина — классика по этим принципам.
#Java #для_новичков #beginner #OOP #DRY #KISS #YAGNI
👍4🔥1
Вы вообще часто вспоминаете о DRY, KISS, YAGNI?
Anonymous Poll
33%
Да, держу это постоянно в голове! ☺️
30%
Иногда, когда понимаю что с кодом что-то не так 😎
10%
Изредка, и то по наводке 💃
10%
Вообще не вспоминаю 🏝
17%
Что это? 🤓
Что выведет код?
#Tasks
class Task220925 {
public static void main(String[] args) {
String input = " ";
String result = StringUtils.safeTrim(input);
System.out.println("'" + result + "'");
System.out.println("isEmpty: " + StringUtils.isEmpty(result));
}
}
public class StringUtils {
// KISS
public static boolean isEmpty(String s) {
return s == null || s.trim().isEmpty();
}
// YAGNI
public static String toTitleCase(String s) {
if (isEmpty(s)) return s;
return Character.toUpperCase(s.charAt(0)) + s.substring(1).toLowerCase();
}
// DRY
public static String safeTrim(String s) {
return isEmpty(s) ? "" : s.trim();
}
}
#Tasks
👍1
Варианты ответа:
Anonymous Quiz
7%
'' isEmpty: false
20%
' ' isEmpty: false
53%
'' isEmpty: true
20%
NullPointerException
👍1
Вопрос с собеседований
Что такое паттерн Mediator?🤓
Ответ:
Mediator — паттерн для централизованного общения объектов.
Пример:
interface Mediator {
void notify(Component sender, String event);
}
class ConcreteMediator implements Mediator { /* Логика */ }
class Component {
protected Mediator mediator;
}
Снижает coupling в системах вроде чатов.
#собеседование
Что такое паттерн Mediator?
Ответ:
Mediator
Пример:
interface Mediator {
void notify(Component sender, String event);
}
class ConcreteMediator implements Mediator { /* Логика */ }
class Component {
protected Mediator mediator;
}
Снижает coupling в системах вроде чатов.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Натаниэль С. Боренштейн (родился 23 сентября 1957 года) — американский учёный-компьютерщик . Он был одним из первых разработчиков протокола MIME для форматирования мультимедийных электронных писем в Интернете и первым отправил вложение к электронному письму.
Линь-Шань Ли (кит .李琳山; родился 23 сентября 1952 г.) — тайваньский компьютерный учёный; внёс вклад в распознавание и синтез речи, особо для китайского языка, и в технологии поиска по речи и речи-в-текст.
1873 — в Петербурге вместо керосиновых ламп зажглись первые в мире электрические фонари.
1997 — была анонсирована поисковая машина Yandex.Ru.
#Biography #Birth_Date #Events #23Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Реактивное программирование
Концепции реактивного программирования: Push vs Pull — кто управляет данными
Сегодня разберём модели Push (отправку данных) и Pull (получение данных), почему одна из них идеальна для реактивного стиля, и как это решает проблемы из первого поста: от тяжёлых потоков до callback-ада.
Представьте: у вас есть конвейер на фабрике. В pull-модели рабочий сам подходит к предыдущему этапу и "берет" деталь, когда ему нужно. В push-модели предыдущий этап "отправляет" деталь дальше, как только она готова, не спрашивая.
Какая модель лучше? Зависит от сценария. В программировании это то же самое: pull подходит для предсказуемых, контролируемых потоков, а push — для динамичных, событийных, где данные приходят непредсказуемо (сеть, пользователи, сенсоры).
Реактивное программирование строится на push — и вот почему это революция.
Pull-модель: вы контролируете темп, но рискуете блокировками
В традиционном императивном программировании (когда код выполняется шаг за шагом, как рецепт) данные обычно "получаются" по требованию. Это pull-модель: потребитель (ваш код) сам запрашивает данные, когда готов их обработать.
Пример — чтение из итератора в Java:
Здесь вы контролируете процесс: hasNext() проверяет наличие, next() получает элемент. Это удобно для локальных, синхронных данных — вы знаете, сколько элементов, и ничего не ждёте. Но под капотом это синхронно: если данные в потоке (файл, сеть), next() может заблокироваться, как в старых потоках. Поток висит в ожидании, ресурсы тратятся впустую.
В асинхронных сценариях pull эволюционировал в Future или CompletableFuture: вы "запрашиваете" результат через get() или цепочки, но контроль остаётся у вас.
Проблема: если источник данных медленный (БД, API), ваш pull-запрос блокирует или создаёт callback-ад. Под нагрузкой — тысячи pull-запросов — система не масштабируется, потому что каждый требует ресурса (потока). Это как толпа в очереди: каждый тянет за своим, но если касса одна, все стоят.
Ещё минус: pull не справляется с "лишними" данными. Если источник генерирует 1 млн событий в секунду, а вы получаете по одному — либо перегрузка буфера, либо вы не успеваете. Нет встроенного механизма, чтобы сказать "замедлись".
#Java #middle #Reactor #Push #Flux
Концепции реактивного программирования: Push vs Pull — кто управляет данными
Сегодня разберём модели Push (отправку данных) и Pull (получение данных), почему одна из них идеальна для реактивного стиля, и как это решает проблемы из первого поста: от тяжёлых потоков до callback-ада.
Представьте: у вас есть конвейер на фабрике. В pull-модели рабочий сам подходит к предыдущему этапу и "берет" деталь, когда ему нужно. В push-модели предыдущий этап "отправляет" деталь дальше, как только она готова, не спрашивая.
Какая модель лучше? Зависит от сценария. В программировании это то же самое: pull подходит для предсказуемых, контролируемых потоков, а push — для динамичных, событийных, где данные приходят непредсказуемо (сеть, пользователи, сенсоры).
Реактивное программирование строится на push — и вот почему это революция.
Pull-модель: вы контролируете темп, но рискуете блокировками
В традиционном императивном программировании (когда код выполняется шаг за шагом, как рецепт) данные обычно "получаются" по требованию. Это pull-модель: потребитель (ваш код) сам запрашивает данные, когда готов их обработать.
Пример — чтение из итератора в Java:
List<String> fruits = Arrays.asList("яблоко", "банан", "вишня");
Iterator<String> iterator = fruits.iterator();
while (iterator.hasNext()) {
String fruit = iterator.next(); // "Вытягиваем" следующий элемент
System.out.println(fruit.toUpperCase());
}
Здесь вы контролируете процесс: hasNext() проверяет наличие, next() получает элемент. Это удобно для локальных, синхронных данных — вы знаете, сколько элементов, и ничего не ждёте. Но под капотом это синхронно: если данные в потоке (файл, сеть), next() может заблокироваться, как в старых потоках. Поток висит в ожидании, ресурсы тратятся впустую.
В асинхронных сценариях pull эволюционировал в Future или CompletableFuture: вы "запрашиваете" результат через get() или цепочки, но контроль остаётся у вас.
Проблема: если источник данных медленный (БД, API), ваш pull-запрос блокирует или создаёт callback-ад. Под нагрузкой — тысячи pull-запросов — система не масштабируется, потому что каждый требует ресурса (потока). Это как толпа в очереди: каждый тянет за своим, но если касса одна, все стоят.
Ещё минус: pull не справляется с "лишними" данными. Если источник генерирует 1 млн событий в секунду, а вы получаете по одному — либо перегрузка буфера, либо вы не успеваете. Нет встроенного механизма, чтобы сказать "замедлись".
#Java #middle #Reactor #Push #Flux
👍3
Push-модель: данные приходят сами, реактивно и эффективно
Теперь изменим: в push-модели источник "отправляет" данные потребителю, как только они готовы, без запросов. Потребитель пассивен — он подписывается и реагирует.
Это основа реактивного программирования: события push'атся асинхронно, без блокировок. Контроль переходит к источнику, но с обратным давлением — подписчик может сказать "хватит на время".
В Reactive Streams это реализовано через Publisher и Subscriber: издатель толкает onNext(элемент), подписчик реагирует сразу.
Пример с Flux в Project Reactor (push-стиль):
Здесь Flux — издатель, который отправляет элементы по мере готовности. subscribe() — подписка, и элементы приходят автоматически: "ЯБЛОКО", "БАНАН"... Нет next() — нет pull.
Если источник асинхронный, например, чтение из сети:
Данные push'атся по мере поступления от сервера — без блокировок. Reactor использует неблокирующий IO (на базе Netty), так что поток не висит: один event-loop-цикл (цикл обработки событий) обслуживает тысячи подписок.
Почему push лучше для реактивности?
Во-первых, эффективность: нет лишних проверок hasNext().
Во-вторых, естественность для событий: клик мыши, сообщение в чате — это push по природе, они приходят сами.
В-третьих, масштабируемость: тысячи подписчиков на один издатель — ок, потому что push идёт через события, а не потоки на каждого.
Гибридные сценарии: когда mix работает
На практике модели смешиваются. В Reactor Flux может имитировать pull через операторы вроде buffer() или take(), но основа — push.
Пример: pull из локального списка, но push в сеть:
Здесь локальный pull (fromIterable) переходит в push (flatMap для API).
Это гибкость: используйте pull для контроля, push для асинхронности. Но важно избегать блокировок: Reactor проверяет и предупреждает, если в лямбде блокирующий код (onBlock()).
Ещё пример из реальной жизни: стриминг видео в Netflix. Pull — когда пользователь сам получает фреймы, но под нагрузкой лагает. Push — сервер отдает фреймы по мере готовности, с буферизацией. Реактивные библиотеки (как RxJava) позволяют строить такие конвейеры.
Почему Push — ключ к новому подходу в реактивном программировании
Возвращаясь к проблемам: потоки тяжёлые, потому что pull требует ожидания; Future блокирует на get(), потому что это pull в асинхронной обёртке; CompletableFuture даёт цепочки, но push-подход в нём слаб (колбэки — это мини-push, но без полного контроля).
Реактивный push меняет всё: данные текут как река, вы реагируете без ожидания, ресурсы на минимуме. Системы становятся resilient (устойчивыми): если один поток сломается, другие продолжают. Под нагрузкой — горизонтальное масштабирование без боли.
#Java #middle #Reactor #Push #Flux
Теперь изменим: в push-модели источник "отправляет" данные потребителю, как только они готовы, без запросов. Потребитель пассивен — он подписывается и реагирует.
Это основа реактивного программирования: события push'атся асинхронно, без блокировок. Контроль переходит к источнику, но с обратным давлением — подписчик может сказать "хватит на время".
В Reactive Streams это реализовано через Publisher и Subscriber: издатель толкает onNext(элемент), подписчик реагирует сразу.
Пример с Flux в Project Reactor (push-стиль):
Flux<String> pushFlux = Flux.fromIterable(Arrays.asList("яблоко", "банан", "вишня"))
.map(String::toUpperCase); // Преобразование в потоке
pushFlux.subscribe(
fruit -> System.out.println("Получено из push: " + fruit), // Реакция на толкание
Throwable::printStackTrace, // Обработка ошибок
() -> System.out.println("Push завершён")
);
Здесь Flux — издатель, который отправляет элементы по мере готовности. subscribe() — подписка, и элементы приходят автоматически: "ЯБЛОКО", "БАНАН"... Нет next() — нет pull.
Если источник асинхронный, например, чтение из сети:
WebClient.create()
.get()
.uri("https://api.example.com/fruits")
.retrieve()
.bodyToFlux(String.class) // Flux толкает строки из ответа
.subscribe(fruit -> System.out.println("Push из API: " + fruit));
Данные push'атся по мере поступления от сервера — без блокировок. Reactor использует неблокирующий IO (на базе Netty), так что поток не висит: один event-loop-цикл (цикл обработки событий) обслуживает тысячи подписок.
Почему push лучше для реактивности?
Во-первых, эффективность: нет лишних проверок hasNext().
Во-вторых, естественность для событий: клик мыши, сообщение в чате — это push по природе, они приходят сами.
В-третьих, масштабируемость: тысячи подписчиков на один издатель — ок, потому что push идёт через события, а не потоки на каждого.
Гибридные сценарии: когда mix работает
На практике модели смешиваются. В Reactor Flux может имитировать pull через операторы вроде buffer() или take(), но основа — push.
Пример: pull из локального списка, но push в сеть:
Flux.fromIterable(fruits)
.map(String::toUpperCase)
.flatMap(fruit -> sendToApi(fruit)) // flatMap толкает в асинхронный API
.subscribe(result -> System.out.println("Ответ: " + result));
Здесь локальный pull (fromIterable) переходит в push (flatMap для API).
Это гибкость: используйте pull для контроля, push для асинхронности. Но важно избегать блокировок: Reactor проверяет и предупреждает, если в лямбде блокирующий код (onBlock()).
Ещё пример из реальной жизни: стриминг видео в Netflix. Pull — когда пользователь сам получает фреймы, но под нагрузкой лагает. Push — сервер отдает фреймы по мере готовности, с буферизацией. Реактивные библиотеки (как RxJava) позволяют строить такие конвейеры.
Почему Push — ключ к новому подходу в реактивном программировании
Возвращаясь к проблемам: потоки тяжёлые, потому что pull требует ожидания; Future блокирует на get(), потому что это pull в асинхронной обёртке; CompletableFuture даёт цепочки, но push-подход в нём слаб (колбэки — это мини-push, но без полного контроля).
Реактивный push меняет всё: данные текут как река, вы реагируете без ожидания, ресурсы на минимуме. Системы становятся resilient (устойчивыми): если один поток сломается, другие продолжают. Под нагрузкой — горизонтальное масштабирование без боли.
#Java #middle #Reactor #Push #Flux
👍3
А вы готовы для устройства на работу в IT, подделать документы, трудовую и тд? 🤫
Anonymous Poll
26%
Да, конечно, а как по другому? ✌️
9%
Наверное да, но оооочееееень осторожно. 😉
11%
Не знаю. 🤷♀️
6%
Наверное нет. Я опасаюсь. 😏
49%
Точно нет. Я не нарушаю законов. 👮
👍1
Что выведет код?
#Tasks
import java.util.Random;
public class Task230925 {
public static void main(String[] args) {
Random rand1 = new Random(42);
Random rand2 = new Random(42);
System.out.println(rand1.nextInt(100) == rand2.nextInt(100));
}
}
#Tasks
👍2