Всем привет!
По традиции, сел писать мотивационную статью на воскресение, но пока думал над темой - решил написать статью - размышление (часто что-то размышлять стал☺️ ).
А поразмышлять я предлагаю о нашем будущем (ну отдельно Вашем и моем), как программистов.
Проведя много опросов, я понимаю, что подписчики канала в основном делятся на 2 категории:
1. Основная - мечтатели, которые хотят вкатиться в IT.
2. Менее представленная - уже работающие джуны и мидлы (в т.ч. и в иных профессиях IT), которые ищут способы дальнейшего развития (как и я).
Как я сейчас вижу ситуацию с рынком труда.
На мой неискушенный взгляд - все сложно и плохо. Побродив по отзывам и собесам, понимаю - время джунов прошло. Знания Java Core сейчас вообще недостаточно для поиска работы. Иначе говоря вчерашние мидлы - сейчас практически джуны и с них начинается минимальный поиск работника.
Что с этим делать я не знаю. Наверно только как завещал дедушка Ленин - учится и учится.
Можно конечно пойти "волчьим" путем, начиная от задрачивания собесов до подделки документов об опыте работы. Но для меня лично, это вообще не вариант. Уже сейчас HR-ы активно ищут и находят противодействие этому и думаю через пару лет эта практика будет умирать (наверно).
Что делать нам, тем кто находится в начале/начале+ профессионального пути?
Вопрос в том, что каждый из нас хочет развиваться. Расти как в профессиональном плане, так и в финансовом. (Цены быстро растут, а грейд нет😆)
А проблемами является то, что снизу подпирают вчерашние вкатуны с нарисованным опытом, готовые и обещающие выполнять твои обязанности быстрее и дешевле (и не важно что это лажа, тебя же уже попросят), так и то что сверху, из-за стагнации рынка, остаются те же сеньоры и мидлы+ которые никуда не уходят, не освобождая ниш для нас.
Что в этой ситуации делать?
Я не знаю.
Но для себя вижу такой план:
1. Развитие, развитие и только постоянное развитие. Куда и как, вопрос отдельный.
2. Наведение связей в IT-шной среде, знакомство с как можно большим количеством разработчиков.
3. Постоянный мониторинг рынка, чтобы понимать, насколько и как все меняется.
Разберу подробнее.
1. Развитие.
Без него никуда.
Не знаете Кафку - вы никому уже не интересны.
Не знаете зачем кубер или как настроить docker-compose, с вами не о чем поговорить в профессиональном плане.
Не понимаете чем SAGA отличается от MVC - с вами просто не будут говорить.
И это только вершина айсберга.
2. Коммуникация.
Мы социальные существа. Программисты конечно менее, но все же.
Вчерашний джун, случайно, по знакомству устроившийся в топ-компанию и протащивший Вас по реферальной программе - вот реальный кейс о котором сейчас говорят HR.
Обмен интересным опытом, фраймворками, бест практикс и код флоу на проектах - вы практически не найдете этого на Ютубе.
И да, в том же телеграмме уже много подобных каналов/чатов, но найти теплый и приветливый очень сложно (чем выше грейд - тем выше чсв).
3. Мониторинг.
Наверно самая простая и понятная часть плана. Кто осведомлен - тот вооружен.
И если завтра погонят палками - хотя-бы будешь понимать чего ждать от рынка 😄.
В итоге, каким я вижу свое будущее
Однозначно светлым (может даже нефильтрованным✈️ )
А если серьезно, то компетенции и знакомства - ключ к развитию во всех планах.
И этот канал, для меня, как раз один из способов этого достичь.
Как собственно и для Вас.
Хотя бесконечно жаль, что 90% подписчиков это даже не прочитают🤬
Да не, не жаль😄 😏
Ведь мы сами творцы своего счастья и если кто-то жаждет развития, он его найдет так и так.
А тем кто ждет, что ему все принесут на блюдечке с серебряной каёмочкой - я могу лишь пожелать удачи👏 .
А остальным я предлагаю кооперироваться. Не сидеть каждому в своей раковине, а настраивать мосты общения, обмена опытом и идеями, совместной командной разработки. 🤝
А что Вы думаете об этом???
На этом извольте откланяться - ваш @Oleborn
😎
По традиции, сел писать мотивационную статью на воскресение, но пока думал над темой - решил написать статью - размышление (часто что-то размышлять стал
А поразмышлять я предлагаю о нашем будущем (ну отдельно Вашем и моем), как программистов.
Проведя много опросов, я понимаю, что подписчики канала в основном делятся на 2 категории:
1. Основная - мечтатели, которые хотят вкатиться в IT.
2. Менее представленная - уже работающие джуны и мидлы (в т.ч. и в иных профессиях IT), которые ищут способы дальнейшего развития (как и я).
Как я сейчас вижу ситуацию с рынком труда.
На мой неискушенный взгляд - все сложно и плохо. Побродив по отзывам и собесам, понимаю - время джунов прошло. Знания Java Core сейчас вообще недостаточно для поиска работы. Иначе говоря вчерашние мидлы - сейчас практически джуны и с них начинается минимальный поиск работника.
Что с этим делать я не знаю. Наверно только как завещал дедушка Ленин - учится и учится.
Можно конечно пойти "волчьим" путем, начиная от задрачивания собесов до подделки документов об опыте работы. Но для меня лично, это вообще не вариант. Уже сейчас HR-ы активно ищут и находят противодействие этому и думаю через пару лет эта практика будет умирать (наверно).
Что делать нам, тем кто находится в начале/начале+ профессионального пути?
Вопрос в том, что каждый из нас хочет развиваться. Расти как в профессиональном плане, так и в финансовом. (Цены быстро растут, а грейд нет😆)
А проблемами является то, что снизу подпирают вчерашние вкатуны с нарисованным опытом, готовые и обещающие выполнять твои обязанности быстрее и дешевле (и не важно что это лажа, тебя же уже попросят), так и то что сверху, из-за стагнации рынка, остаются те же сеньоры и мидлы+ которые никуда не уходят, не освобождая ниш для нас.
Что в этой ситуации делать?
Я не знаю.
Но для себя вижу такой план:
1. Развитие, развитие и только постоянное развитие. Куда и как, вопрос отдельный.
2. Наведение связей в IT-шной среде, знакомство с как можно большим количеством разработчиков.
3. Постоянный мониторинг рынка, чтобы понимать, насколько и как все меняется.
Разберу подробнее.
1. Развитие.
Без него никуда.
Не знаете Кафку - вы никому уже не интересны.
Не знаете зачем кубер или как настроить docker-compose, с вами не о чем поговорить в профессиональном плане.
Не понимаете чем SAGA отличается от MVC - с вами просто не будут говорить.
И это только вершина айсберга.
2. Коммуникация.
Мы социальные существа. Программисты конечно менее, но все же.
Вчерашний джун, случайно, по знакомству устроившийся в топ-компанию и протащивший Вас по реферальной программе - вот реальный кейс о котором сейчас говорят HR.
Обмен интересным опытом, фраймворками, бест практикс и код флоу на проектах - вы практически не найдете этого на Ютубе.
И да, в том же телеграмме уже много подобных каналов/чатов, но найти теплый и приветливый очень сложно (чем выше грейд - тем выше чсв).
3. Мониторинг.
Наверно самая простая и понятная часть плана. Кто осведомлен - тот вооружен.
И если завтра погонят палками - хотя-бы будешь понимать чего ждать от рынка 😄.
В итоге, каким я вижу свое будущее
Однозначно светлым (может даже нефильтрованным
А если серьезно, то компетенции и знакомства - ключ к развитию во всех планах.
И этот канал, для меня, как раз один из способов этого достичь.
Как собственно и для Вас.
Хотя бесконечно жаль, что 90% подписчиков это даже не прочитают
Да не, не жаль
Ведь мы сами творцы своего счастья и если кто-то жаждет развития, он его найдет так и так.
А тем кто ждет, что ему все принесут на блюдечке с серебряной каёмочкой - я могу лишь пожелать удачи
А остальным я предлагаю кооперироваться. Не сидеть каждому в своей раковине, а настраивать мосты общения, обмена опытом и идеями, совместной командной разработки. 🤝
А что Вы думаете об этом???
На этом извольте откланяться - ваш @Oleborn
😎
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥2
Александр Георгиевич Шамов (29 сентября 1951, Петропавловск, Северо-Казахстанская область, Казахская ССР, СССР — 7 ноября 2020, Казань, Республика Татарстан, Российская Федерация) — советский/российский физик-химик и информатик; вёл прикладные исследования с использованием ЭВМ, руководил подразделениями по информатизации в казанских научных и учебных учреждениях, лауреат республиканской премии.
Сергей Игоревич Маторин (29 сентября 1954 года в Москве) — доктор технических наук, профессор, заведующий кафедрой прикладной информатики; разработал методы моделирования, системного анализа и инженерии знаний, применявшиеся в информационно-аналитических системах.
Oscar H. Ibarra (родился 29 сентября 1941 года в Негросе Оксидентал , Филиппины) — филиппино-американский теоретик информатики; известен работами по теории автоматов, формальным языкам и сложности, профессор UCSB — важная фигура в теоретической информатике.
Маркус Хендрик «Марк» Овермарс ( голландское произношение: [ˈmɑrkʏs ˈɦɛndrɪk ˈmɑr(ə)k ˈoːvərmɑrs] ; родился 29 сентября 1958 года) — нидерландский учёный в вычислительной геометрии и практик (создатель GameMaker); внёс вклад в алгоритмы для графики, робототехники и инструментальные средства для разработки игр.
1951 — открыт 12-й спутник Юпитера — Ананке.
#Biography #Birth_Date #Events #29Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Коллекции в Java
Глава 1. Введение в коллекции
Обзор Java Collections Framework. Интерфейсы Collection и Map. Иерархия коллекций. Отличия коллекций от массивов
Java Collections Framework (JCF) — это набор интерфейсов, классов и алгоритмов в пакете java.util, предназначенный для работы с коллекциями данных. JCF предоставляет унифицированный способ хранения и манипуляции объектами, делая код более гибким и эффективным.
- Компоненты JCF:
- Интерфейсы: Определяют контракт (что можно делать с коллекцией).
- Реализации: Конкретные классы, реализующие интерфейсы (например, ArrayList для List).
- Алгоритмы: Встроенные методы для сортировки, поиска и т.д. (в классе Collections).
JCF введен в Java 1.2 и значительно улучшен в Java 5 с generics (обобщениями), которые обеспечивают типобезопасность.
- Преимущества JCF:
- Гибкость: Динамический размер, в отличие от массивов.
- Типобезопасность: С generics — компилятор проверяет типы.
- Эффективность: Разные реализации для разных сценариев (быстрый доступ, уникальность элементов и т.д.).
- Полиморфизм: Работа через интерфейсы, легко менять реализации.
Интерфейсы Collection и Map
JCF построен вокруг двух основных интерфейсов: Collection для последовательностей объектов и Map для пар ключ-значение.
1. Интерфейс Collection<E>:
- Это базовый интерфейс для коллекций, где E — тип элементов (generics).
- Представляет группу объектов, позволяя добавлять, удалять, перебирать.
- Не гарантирует порядок или уникальность — зависит от реализации.
- Основные методы:
- add(E e): Добавляет элемент.
- remove(Object o): Удаляет элемент.
- size(): Возвращает размер.
- isEmpty(): Проверяет пустоту.
- iterator(): Для перебора (Iterator).
- contains(Object o): Проверяет наличие.
- Нюанс: Collection не индексирован (нет get(int index)), для этого — подинтерфейсы как List.
2. Интерфейс Map<K, V>:
- Представляет отображение: пары ключ-значение, где K — тип ключа, V — тип значения.
- Ключи уникальны, значения могут дублироваться.
- Не является подтипом Collection (Map не коллекция элементов, а ассоциация).
- Основные методы:
- put(K key, V value): Добавляет/обновляет пару.
- get(Object key): Возвращает значение по ключу.
- remove(Object key): Удаляет по ключу.
- size(), isEmpty().
- keySet(): Коллекция ключей (Set<K>).
- values(): Коллекция значений (Collection<V>).
- entrySet(): Коллекция пар (Set<Map.Entry<K, V>>).
- Нюанс: Map не упорядочен (кроме SortedMap), ключи не null (в большинстве реализаций).
#Java #для_новичков #beginner #Collections #Map
Глава 1. Введение в коллекции
Обзор Java Collections Framework. Интерфейсы Collection и Map. Иерархия коллекций. Отличия коллекций от массивов
Java Collections Framework (JCF) — это набор интерфейсов, классов и алгоритмов в пакете java.util, предназначенный для работы с коллекциями данных. JCF предоставляет унифицированный способ хранения и манипуляции объектами, делая код более гибким и эффективным.
- Компоненты JCF:
- Интерфейсы: Определяют контракт (что можно делать с коллекцией).
- Реализации: Конкретные классы, реализующие интерфейсы (например, ArrayList для List).
- Алгоритмы: Встроенные методы для сортировки, поиска и т.д. (в классе Collections).
JCF введен в Java 1.2 и значительно улучшен в Java 5 с generics (обобщениями), которые обеспечивают типобезопасность.
- Преимущества JCF:
- Гибкость: Динамический размер, в отличие от массивов.
- Типобезопасность: С generics — компилятор проверяет типы.
- Эффективность: Разные реализации для разных сценариев (быстрый доступ, уникальность элементов и т.д.).
- Полиморфизм: Работа через интерфейсы, легко менять реализации.
Интерфейсы Collection и Map
JCF построен вокруг двух основных интерфейсов: Collection для последовательностей объектов и Map для пар ключ-значение.
1. Интерфейс Collection<E>:
- Это базовый интерфейс для коллекций, где E — тип элементов (generics).
- Представляет группу объектов, позволяя добавлять, удалять, перебирать.
- Не гарантирует порядок или уникальность — зависит от реализации.
- Основные методы:
- add(E e): Добавляет элемент.
- remove(Object o): Удаляет элемент.
- size(): Возвращает размер.
- isEmpty(): Проверяет пустоту.
- iterator(): Для перебора (Iterator).
- contains(Object o): Проверяет наличие.
- Нюанс: Collection не индексирован (нет get(int index)), для этого — подинтерфейсы как List.
2. Интерфейс Map<K, V>:
- Представляет отображение: пары ключ-значение, где K — тип ключа, V — тип значения.
- Ключи уникальны, значения могут дублироваться.
- Не является подтипом Collection (Map не коллекция элементов, а ассоциация).
- Основные методы:
- put(K key, V value): Добавляет/обновляет пару.
- get(Object key): Возвращает значение по ключу.
- remove(Object key): Удаляет по ключу.
- size(), isEmpty().
- keySet(): Коллекция ключей (Set<K>).
- values(): Коллекция значений (Collection<V>).
- entrySet(): Коллекция пар (Set<Map.Entry<K, V>>).
- Нюанс: Map не упорядочен (кроме SortedMap), ключи не null (в большинстве реализаций).
#Java #для_новичков #beginner #Collections #Map
👍3
Иерархия коллекций в JCF
JCF имеет иерархию интерфейсов и реализаций. Вот подробная структура:
1. Иерархия Collection:
- Collection<E> (базовый):
- List<E>: Упорядоченная коллекция, позволяет дубликаты, индексация.
- Реализации: ArrayList (быстрый доступ), LinkedList (быстрые вставки/удаления), Vector (устаревший, synchronized).
- Set<E>: Неупорядоченная коллекция уникальных элементов.
- Реализации: HashSet (быстрый поиск), TreeSet (отсортированный), LinkedHashSet (сохраняет порядок вставки).
- Queue<E>: Для очередей (FIFO), или приоритетных.
- Реализации: LinkedList (как Queue), PriorityQueue (приоритетная), ArrayDeque (deque).
- Deque<E>: Двусторонняя очередь (добавление/удаление с обоих концов).
- Реализации: ArrayDeque, LinkedList.
2. Иерархия Map:
- Map<K, V> (базовый):
- HashMap<K, V>: Быстрый поиск по хэшу, не упорядочен.
- TreeMap<K, V>: Отсортированный по ключам (SortedMap).
- LinkedHashMap<K, V>: Сохраняет порядок вставки.
- Hashtable<K, V>: Устаревший, synchronized.
- Generics: С Java 5: Collection<String> list = new ArrayList<>(); — типобезопасно.
- Нюансы иерархии:
- Все реализации — concrete классы, кроме абстрактных helper-классов (AbstractList).
- Synchronized: Для многопоточности используйте Collections.synchronized*() или Concurrent* классы (ConcurrentHashMap).
- Performance: Выбирайте по нуждам — HashSet O(1) поиск, TreeSet O(log n) с сортировкой.
- Immutability: Collections.unmodifiable*() для read-only коллекций.
Отличия коллекций от массивов
Массивы — базовый тип в Java для хранения элементов фиксированного размера. Коллекции — более гибкий инструмент из JCF.
- Подробное сравнение:
1. Размер:
- Массивы: Фиксированный (int[] arr = new int[10]; — нельзя изменить).
- Коллекции: Динамический (ArrayList.add() расширяет автоматически).
2. Типы элементов:
- Массивы: Могут хранить примитивы (int[]) или объекты.
- Коллекции: Только объекты (Collection<Integer> для примитивов через wrapper).
3. Методы:
- Массивы: Ограничены (длина .length, доступ по индексу).
- Коллекции: Богатый API (add, remove, contains, sort, iterator).
4. Generics:
- Массивы: Нет (Object[] может хранить всё, но без проверки).
- Коллекции: С generics — типобезопасно (компилятор проверяет).
5. Performance:
- Массивы: Быстрее для фиксированного размера и примитивов.
- Коллекции: Overhead, но удобнее; ArrayList близок к массиву.
6. Многомерность:
- Массивы: Легко (int[][]).
- Коллекции: Вложенные (List<List<Integer>>).
7. Null и дубликаты:
- Оба позволяют, но Set в коллекциях запрещает дубликаты.
Пример перехода от массива к коллекции:
Массив:
Коллекция:
- Нюанс: Коллекции используют массивы внутри (ArrayList — resizable array).
Как работать с JCF в IntelliJ IDEA
1. Импорт: Импортируйте java.util.* или конкретно (IDE подскажет Ctrl+Space).
2. Generics: Напишите List<String> — IDE проверит типы.
3. Коллекции: New → Collection → Выберите реализацию.
4. Методы: Автодополнение для add, remove и т.д.
5. Debug: В отладке смотрите содержимое коллекций.
Полезные советы для новичков
- Выбирайте интерфейс: Кодьте под List, а не ArrayList — легко сменить реализацию.
- Generics всегда: Избегайте raw types (List без <E> — устарело).
- Коллекции vs массивы: Массивы для фиксированных примитивов, коллекции для всего остального.
- Performance: ArrayList для доступа, LinkedList для вставок, HashSet для уникальности.
#Java #для_новичков #beginner #Collections #Map
JCF имеет иерархию интерфейсов и реализаций. Вот подробная структура:
1. Иерархия Collection:
- Collection<E> (базовый):
- List<E>: Упорядоченная коллекция, позволяет дубликаты, индексация.
- Реализации: ArrayList (быстрый доступ), LinkedList (быстрые вставки/удаления), Vector (устаревший, synchronized).
- Set<E>: Неупорядоченная коллекция уникальных элементов.
- Реализации: HashSet (быстрый поиск), TreeSet (отсортированный), LinkedHashSet (сохраняет порядок вставки).
- Queue<E>: Для очередей (FIFO), или приоритетных.
- Реализации: LinkedList (как Queue), PriorityQueue (приоритетная), ArrayDeque (deque).
- Deque<E>: Двусторонняя очередь (добавление/удаление с обоих концов).
- Реализации: ArrayDeque, LinkedList.
2. Иерархия Map:
- Map<K, V> (базовый):
- HashMap<K, V>: Быстрый поиск по хэшу, не упорядочен.
- TreeMap<K, V>: Отсортированный по ключам (SortedMap).
- LinkedHashMap<K, V>: Сохраняет порядок вставки.
- Hashtable<K, V>: Устаревший, synchronized.
- Generics: С Java 5: Collection<String> list = new ArrayList<>(); — типобезопасно.
- Нюансы иерархии:
- Все реализации — concrete классы, кроме абстрактных helper-классов (AbstractList).
- Synchronized: Для многопоточности используйте Collections.synchronized*() или Concurrent* классы (ConcurrentHashMap).
- Performance: Выбирайте по нуждам — HashSet O(1) поиск, TreeSet O(log n) с сортировкой.
- Immutability: Collections.unmodifiable*() для read-only коллекций.
Отличия коллекций от массивов
Массивы — базовый тип в Java для хранения элементов фиксированного размера. Коллекции — более гибкий инструмент из JCF.
- Подробное сравнение:
1. Размер:
- Массивы: Фиксированный (int[] arr = new int[10]; — нельзя изменить).
- Коллекции: Динамический (ArrayList.add() расширяет автоматически).
2. Типы элементов:
- Массивы: Могут хранить примитивы (int[]) или объекты.
- Коллекции: Только объекты (Collection<Integer> для примитивов через wrapper).
3. Методы:
- Массивы: Ограничены (длина .length, доступ по индексу).
- Коллекции: Богатый API (add, remove, contains, sort, iterator).
4. Generics:
- Массивы: Нет (Object[] может хранить всё, но без проверки).
- Коллекции: С generics — типобезопасно (компилятор проверяет).
5. Performance:
- Массивы: Быстрее для фиксированного размера и примитивов.
- Коллекции: Overhead, но удобнее; ArrayList близок к массиву.
6. Многомерность:
- Массивы: Легко (int[][]).
- Коллекции: Вложенные (List<List<Integer>>).
7. Null и дубликаты:
- Оба позволяют, но Set в коллекциях запрещает дубликаты.
Пример перехода от массива к коллекции:
Массив:
String[] names = new String[3];
names[0] = "Алексей";
// Нет add, нужно вручную управлять размером
Коллекция:
List<String> names = new ArrayList<>();
names.add("Алексей"); // Динамично
names.remove(0); // Легко удалить
- Нюанс: Коллекции используют массивы внутри (ArrayList — resizable array).
Как работать с JCF в IntelliJ IDEA
1. Импорт: Импортируйте java.util.* или конкретно (IDE подскажет Ctrl+Space).
2. Generics: Напишите List<String> — IDE проверит типы.
3. Коллекции: New → Collection → Выберите реализацию.
4. Методы: Автодополнение для add, remove и т.д.
5. Debug: В отладке смотрите содержимое коллекций.
Полезные советы для новичков
- Выбирайте интерфейс: Кодьте под List, а не ArrayList — легко сменить реализацию.
- Generics всегда: Избегайте raw types (List без <E> — устарело).
- Коллекции vs массивы: Массивы для фиксированных примитивов, коллекции для всего остального.
- Performance: ArrayList для доступа, LinkedList для вставок, HashSet для уникальности.
#Java #для_новичков #beginner #Collections #Map
👍3
Что выведет код?
#Tasks
public class Task290925 {
public static void main(String[] args) {
Boolean a = true;
Boolean b = true;
Boolean c = new Boolean(true);
System.out.println((a == b) + " " + (a == c));
}
}#Tasks
🗿2
Продолжаем выбирать темы для разбора и голосовать за рассмотрение предложенных! 🤓
Голосуем за тему к рассмотрению в эти выходные!
Выбираем новую тему!
(можете предложить что-то из того, что предлагали на прошлой и позапрошлых неделях и что проиграло в голосовании!)
Не стесняемся!✌️
Голосуем за тему к рассмотрению в эти выходные!
Выбираем новую тему!
(можете предложить что-то из того, что предлагали на прошлой и позапрошлых неделях и что проиграло в голосовании!)
Не стесняемся!
Please open Telegram to view this post
VIEW IN TELEGRAM
Вопрос с собеседований
Что такое JIT-компилятор?🤓
Ответ:
JIT (Just-In-Time) — это часть JVM, которая во время выполнения переводит часто используемый байт-код в машинный код для ускорения работы.
Это позволяет сочетать переносимость байт-кода и скорость нативных программ.
JVM оптимизирует только «горячие» участки кода.
#собеседование
Что такое JIT-компилятор?
Ответ:
JIT (Just-In-Time)
Это позволяет сочетать переносимость байт-кода и скорость нативных программ.
JVM оптимизирует только «горячие» участки кода.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Джордж Садовски (родился 30 сентября 1936 года) — американский (родом из СССР) компьютерный учёный, активный продвигатель интернета в развивающихся странах; участвовал в разработке и распространении сетевой инфраструктуры, помогал реформированию законодательства и технологиям, уменьшению контроля и диверсификации доступа к интернету.
Андре́ас (Э́нди) Бе́хтольшайм (нем. Andreas Bechtolsheim; род. 30 сентября 1955, Германия, ФРГ) — немецко-американский инженер и предприниматель, сооснователь Sun Microsystems и ключевой дизайн-инженер аппаратной части; также один из первых инвесторов Google.
Иегуда Афек ( иврит : יהודה אפק ; сентябрь 1952) — израильский ученый в области компьютерных сетей, распределённых вычислений и кибербезопасности; участвовал в разработке алгоритмов устойчивости, DDoS-защиты и инфраструктурных решений интернета.
1929 — Английская служба «Би-би-си» впервые провела телетрансляцию.
1988 — года IBM объявила, что отгрузила 3-миллионный персональный компьютер PS/2.
#Biography #Birth_Date #Events #30Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Знакомство с Project Reactor: Mono и Flux
Project Reactor — это не просто обёртка, а полноценный фреймворк от команды Spring, оптимизированный для производительности. Он использует неблокирующий подход: всё работает на основе событий, с минимальным потреблением ресурсов. Ключевые типы — Mono и Flux, которые воплощают потоки данных. Mono для случаев с нуля или одним элементом (как одиночный запрос), Flux для последовательностей (как стриминг). Они реализуют Publisher из Reactive Streams, так что поддерживают подписку, реакции и обратное давление.
Что такое Project Reactor и как начать?
Project Reactor — библиотека для реактивного программирования, которая строит на Reactive Streams. Она предоставляет API для создания, трансформации и потребления асинхронных потоков. Под капотом — эффективный scheduler (планировщик задач), который распределяет работу по потокам без блокировок: использует event-loop для IO и параллельные пулы для вычислений.
Чтобы начать добавьте в pom.xml (Maven):
Импортируйте:
Reactor интегрируется с Spring (WebFlux), но работает standalone. Главное преимущество: код становится декларативным — вы описываете "что" (поток и реакции), а не "как" (ожидания и циклы). Это решает callback-ад: цепочки читаемы, как последовательный код, но асинхронны.
Mono: поток для нуля или одного элемента
Mono — это тип для сценариев, где ожидается максимум один результат: успех (элемент), ошибка или ничего. Идеален для HTTP-запросов, чтения записи из БД или вычислений с одиночным исходом. Mono реализует Publisher, так что вы можете подписаться и реагировать.
Создание Mono: используйте статические методы.
- Mono.just(value): из готового значения.
- Mono.empty(): пустой поток (завершится onComplete без onNext).
- Mono.fromCallable(() -> compute()): из синхронного вызова.
- Mono.defer(() -> createMono()): ленивое создание (выполняется при подписке).
Пример простого Mono:
Асинхронный пример: симулируем задержку.
Почему Mono лучше Future/CompletableFuture?
Нет блокирующего get(): результат приходит в onNext. Нет callback-ада: цепочки через операторы (map, flatMap — разберём в следующих постах). Под нагрузкой: тысячи Mono на одном потоке, без исчерпания пула.
#Java #middle #Reactor #Reactive_Streams_API #Mono #Flux
Project Reactor — это не просто обёртка, а полноценный фреймворк от команды Spring, оптимизированный для производительности. Он использует неблокирующий подход: всё работает на основе событий, с минимальным потреблением ресурсов. Ключевые типы — Mono и Flux, которые воплощают потоки данных. Mono для случаев с нуля или одним элементом (как одиночный запрос), Flux для последовательностей (как стриминг). Они реализуют Publisher из Reactive Streams, так что поддерживают подписку, реакции и обратное давление.
Что такое Project Reactor и как начать?
Project Reactor — библиотека для реактивного программирования, которая строит на Reactive Streams. Она предоставляет API для создания, трансформации и потребления асинхронных потоков. Под капотом — эффективный scheduler (планировщик задач), который распределяет работу по потокам без блокировок: использует event-loop для IO и параллельные пулы для вычислений.
Чтобы начать добавьте в pom.xml (Maven):
<dependency>
<groupId>io.projectreactor</groupId>
<artifactId>reactor-core</artifactId>
<version>3.5.0</version> <!-- версия может быть неактуальной -->
</dependency>
Импортируйте:
import reactor.core.publisher.Mono; import reactor.core.publisher.Flux;
Reactor интегрируется с Spring (WebFlux), но работает standalone. Главное преимущество: код становится декларативным — вы описываете "что" (поток и реакции), а не "как" (ожидания и циклы). Это решает callback-ад: цепочки читаемы, как последовательный код, но асинхронны.
Mono: поток для нуля или одного элемента
Mono — это тип для сценариев, где ожидается максимум один результат: успех (элемент), ошибка или ничего. Идеален для HTTP-запросов, чтения записи из БД или вычислений с одиночным исходом. Mono реализует Publisher, так что вы можете подписаться и реагировать.
Создание Mono: используйте статические методы.
- Mono.just(value): из готового значения.
- Mono.empty(): пустой поток (завершится onComplete без onNext).
- Mono.fromCallable(() -> compute()): из синхронного вызова.
- Mono.defer(() -> createMono()): ленивое создание (выполняется при подписке).
Пример простого Mono:
Mono<String> simpleMono = Mono.just("Привет из Reactor");
Подписка: subscribe() вызывает реакции.
simpleMono.subscribe(
value -> System.out.println("Значение: " + value), // onNext: реакция на элемент
error -> System.err.println("Ошибка: " + error), // onError
() -> System.out.println("Завершено") // onComplete
);
Здесь: "Значение: Привет из Reactor" и "Завершено". Подписка асинхронна — код после subscribe() идёт сразу, без ожидания. Если ошибка (например, Mono.error(new RuntimeException("Бум"))), сработает onError.Асинхронный пример: симулируем задержку.
Mono<String> asyncMono = Mono.delay(Duration.ofSeconds(1)).map(ignore -> "Готово после секунды");
asyncMono.subscribe(System.out::println); // Вывод после 1 сек
Почему Mono лучше Future/CompletableFuture?
Нет блокирующего get(): результат приходит в onNext. Нет callback-ада: цепочки через операторы (map, flatMap — разберём в следующих постах). Под нагрузкой: тысячи Mono на одном потоке, без исчерпания пула.
#Java #middle #Reactor #Reactive_Streams_API #Mono #Flux
👍3
Flux: поток для нуля, одного или множества элементов
Flux — для последовательностей: от конечных (список) до бесконечных (стриминг). Может быть пустым, с одним элементом (как Mono) или миллионами. Flux тоже Publisher, поддерживает backpressure.
Создание Flux:
- Flux.just(a, b, c): из значений.
- Flux.fromIterable(list): из коллекции.
- Flux.range(start, count): последовательность чисел.
- Flux.interval(Duration): бесконечный таймер.
- Flux.generate(sink -> { sink.next(value); sink.complete(); }): генератор с состоянием.
Пример базового Flux:
С backpressure используйте BaseSubscriber для контроля.
Асинхронный Flux: стриминг с задержкой.
Почему Flux лучше потоков или циклов?
Масштабируемость: обрабатывает миллионы элементов без лишних ресурсов. Реактивность: реагируйте на каждый элемент, без буферов в памяти. Интеграция с обратным давлением: если подписчик медленный, Flux замедляется.
Практические советы и подводные камни
- Ленивость: Mono/Flux не выполняются без subscribe(). Полезно для отложенного вычисления.
- Ошибки: всегда обрабатывайте onError, иначе они "проглатываются".
- Блокировки: избегайте Thread.sleep() в реакциях — используйте delayElements() для асинхронных пауз.
- Тестирование: используйте StepVerifier из reactor-test: StepVerifier.create(flux).expectNext(1,2).verifyComplete();
- Камень: бесконечный Flux без take() или limitRequest() — рискуете памятью. Добавляйте .onBackpressureBuffer() или drop.
В реальной практике: в WebFlux контроллер возвращает Mono<Response> для GET, Flux<Event> для SSE (сервер-сент события).
#Java #middle #Reactor #Reactive_Streams_API #Mono #Flux
Flux — для последовательностей: от конечных (список) до бесконечных (стриминг). Может быть пустым, с одним элементом (как Mono) или миллионами. Flux тоже Publisher, поддерживает backpressure.
Создание Flux:
- Flux.just(a, b, c): из значений.
- Flux.fromIterable(list): из коллекции.
- Flux.range(start, count): последовательность чисел.
- Flux.interval(Duration): бесконечный таймер.
- Flux.generate(sink -> { sink.next(value); sink.complete(); }): генератор с состоянием.
Пример базового Flux:
Flux<Integer> numbersFlux = Flux.range(1, 5);
numbersFlux.subscribe(
value -> System.out.println("Элемент: " + value), // onNext для каждого
error -> System.err.println("Ошибка: " + error),
() -> System.out.println("Завершено")
);
Вывод: 1, 2, 3, 4, 5 и "Завершено". Асинхронно: элементы "текут" по мере готовности.
С backpressure используйте BaseSubscriber для контроля.
numbersFlux.subscribe(new BaseSubscriber<Integer>() {
@Override
protected void hookOnSubscribe(Subscription subscription) {
request(2); // Запрашиваем по 2 элемента
}
@Override
protected void hookOnNext(Integer value) {
System.out.println("Получено: " + value);
request(1); // После обработки — следующий
}
});
Это предотвращает перегрузку: Flux выдаёт элементы порциями.Асинхронный Flux: стриминг с задержкой.
Flux<Long> tickingFlux = Flux.interval(Duration.ofMillis(500)).take(5); // 5 тиков каждые 0.5 сек
tickingFlux.subscribe(System.out::println); // 0, 1, 2, 3, 4 с паузами
Почему Flux лучше потоков или циклов?
Масштабируемость: обрабатывает миллионы элементов без лишних ресурсов. Реактивность: реагируйте на каждый элемент, без буферов в памяти. Интеграция с обратным давлением: если подписчик медленный, Flux замедляется.
Практические советы и подводные камни
- Ленивость: Mono/Flux не выполняются без subscribe(). Полезно для отложенного вычисления.
- Ошибки: всегда обрабатывайте onError, иначе они "проглатываются".
- Блокировки: избегайте Thread.sleep() в реакциях — используйте delayElements() для асинхронных пауз.
- Тестирование: используйте StepVerifier из reactor-test: StepVerifier.create(flux).expectNext(1,2).verifyComplete();
- Камень: бесконечный Flux без take() или limitRequest() — рискуете памятью. Добавляйте .onBackpressureBuffer() или drop.
В реальной практике: в WebFlux контроллер возвращает Mono<Response> для GET, Flux<Event> для SSE (сервер-сент события).
#Java #middle #Reactor #Reactive_Streams_API #Mono #Flux
👍4
Вы работали с реактивным программированием?
Anonymous Poll
4%
Да, регулярно использую!
17%
Очень редко, в особо узких местах
78%
Нет, вообще впервые слышу
Что выведет код?
#Tasks
import java.util.*;
public class Task300925 {
public static void main(String[] args) {
Set<Short> set = new HashSet<>();
for (short i = 0; i < 10; i++) {
set.add(i);
set.remove(i - 1);
}
System.out.println(set.size());
}
}
#Tasks
🔥1🤯1