Собственно, название поста отображает его основную мысль) Есть желание сменить работу на Java-программиста, однако начитавшись постов и проанализировав HH возникают огромные сомнения по поводу нужности очередного стажера/джуна на рынке.
Коротко о бэкграунде: бакалавриат и магистратура по специальности "Автоматизированные системы управления тех.процессом", 5 лет опыта работы инженером-программистом АСУ ТП. Обязанности - разработка ПО для ПЛК(паскалеподобные SCL и ST) и SCADA(VBS, SQL и чуть-чуть C#), настройка ПК, ПНР.
Что делаю: купил курс на Я.Практикуме(да-да, очередной недопрограммист после курсов), когда понял, что у меня остается куча времени, т.к. курс разбит на 2-недельные спринты, а задания я прохожу от силы неделю, докупил еще JavaRush. Параллельно начал изучать Шилдта. В мыслях накидать свой петпроект для реальной задачи на работе - построение относительно простой системы отчетов. Само собой, после изучения Java Core - изучение Git, Maven, Spring и прокачка SQL.
Непосредственно вопрос: насколько реально найти с подобным "послужным" списком работу на должность Java Junior за 3-4 месяца? Город миллионник(не Москва и не Питер), на зп в целом пофиг, понимаю, что первые полгода-год - работа за еду)
Дополнительный вопрос: куда копать, куда не копать, на что следует обращать внимание?
Итак, я до этого дошел. Я писал на React + TypeScript, соответственно, и на JavaScript тоже. Но всегда хотел изучить Java. Ранее язык казался мне сложным. Сейчас у меня есть хорошая база, у меня есть план для изучения. Книги сразу нет, мне скучно и дико не хочется читать много воды. Я лучше воспринимаю видеоформат (благо в интернете миллионы уроков). Не надо кидать в меня камнями; если вы такой человек, что вам нормально взять том в тысячу страниц и сидеть его читать, то я так не могу. Я закину это дело с вероятностью 99.9%. Я решил проходить параллельно 2 курса: один больше стандартный и дает базу, второй больше проектный, учеба непосредственно на проекте.
Далее я себе придумал задачу, которую я буду решать. Так как я работаю QA, я общаюсь с программистами, и их в моем окружении не мало. Я с ними посоветовался, и в принципе задача выполнима.
Иногда буду делиться своим прогрессом. Если хотите, можете оставить ссылки на полезные ресурсы. Но не надо предлагать книги, я не буду их читать).
Язык программирования Java существенно изменился со времени предыдущего издания книги, опубликованного вскоре после выпуска Java б. Этот классический труд тщательно обновлен, чтобы читатели могли в полной мере воспользоваться возможностями последних версий языка и его библиотек функций. В современном Java поддерживается несколько парадигм программирования. Поэтому программисты часто испытывают потребность в конкретных рекомендациях, которые и описаны в данной книге.
Как и в предыдущих изданиях, каждая глава книги состоит из ряда разделов, в каждом из которых описаны конкретные советы, приведены тонкости платформы Java и содержатся обновленные примеры кода. Для каждой темы приводятся всеобъемлющее описание и пояснения, как следует поступить в данном случае, как не следует и почему.
Третье издание охватывает особенности языка программирования и библиотек, появившихся в Java 7, 8 и 9, в том числе конструкции функционального программирования, добавленные к своим объектно-ориентированным корням. В книгу включены также многие новые советы и глава, посвященная лямбда-выражениям и потокам.
Многие сталкиваются с проблемой получения доступа к OPENAI или переживают из-за большой цены за подписку. Специально для вас, мы встроили GPT-4 в Telegram бота, который также работает с изображениями. Наверное, это лучший бот, которого вы когда-либо видели. Тестируйте: t.me/Gpt4_NeuroBot?start=14
Java – один из самых популярных и востребованных языков программирования в мире, но и один из самых сложных для изучения, особенно для новичков. Автор этой книги, Брайсон Пейн, разработал собственный метод обучения, который строится на прохождении материала исключительно на практических примерах. Начните изучать Java, создавая несложные игры для ПК и Android, узнавайте, как работает инструмент JShell, используйте популярные среды разработки Eclipse и Android Studio, учитесь искать и исправлять ошибки в коде и становитесь востребованным программистом с книгой «Легкий способ выучить Java»!
Учебное пособие посвящено объектно-ориентированному программированию на языке Java. Рассматриваются основные принципы объектно-ориентированного программирования, средства работы со структурами данных – коллекции и дженерики, принципы объектно-ориентированного дизайна.
Программирование и тестирование обычно принято относить к разным профессиональным сферам. Скотт Оукс — признанный эксперт по языку Java — уверен, что если вы хотите работать с этим языком, то обязаны понимать, как выполняется код в виртуальной машине Java, и знать, какие настройки влияют на производительность.
Вы сможете разобраться в производительности приложений Java в контексте как JVM, так и платформы Java, освоите средства, функции и процессы, которые могут повысить производительность в LTS-версиях Java, и познакомитесь с новыми возможностями (такими как предварительная компиляция и экспериментальные уборщики мусора).
В этой книге вы:
- Узнаете, как платформы и компиляторы Java влияют на производительность.
- Разберетесь c механизмом уборки мусора.
- Освоите четыре принципа получения наилучших результатов при тестировании производительности.
- Научитесь пользоваться JDK и другими инструментами оценки производительности.
- Узнаете как настройка и приемы программирования позволяют минимизировать последствия уборки мусора.
- Научитесь решать проблемы производительности средствами Java API.
- Поймете, как улучшить производительность приложений баз данных Java.
Реактивщина стала поддерживаться Спрингом с 2017 года. Но через 6 лет многие так и не осознали, где её применять и зачем она нужна. А ведь для Спринга это стало целой новой эпохой.
Реактивнища это не изобретение Спринга.
Первое что нужно знать — реактивщина и реактивный подход не являются изобретением Спринга. Наоборот спринг как обычно поглотил очередную технологию, в данном случае Project Reactor
Реактивный дух времени.
Понятие реактивного подхода размыто но в общем подразумевает что приложение будет скорее событийно ориентировано. Давайте рассмотрим простой пример ниже, в котором сравним старый синхроный подход и рективный.
Синхронный блокирующий подход:
Предположим что на мнужно выполнить 3 задачи. В старом синхронном подходе мы получим код который будет запущенным одним потоком поочередно и блокирующе.
синхронный подход
Реактивный подход
Теперь перепишем ту же задачу используя реактивщину, встроенную в JDK еще с Java 9:
Создаем паблишер и отправляем ему 3 задачи.
Различия. Небольшая большая разница.
Как можно было понять что сам подход к написанию кода от «естественного» процедурного, где каждый этап движется сверху вниз теряется в реактивщине (хотя и в функциональности он тоже теряется). Реактивный код выглядит скорее как декларативный набор реакций на события и поэтому менее прозрачен и читаем. К сожалению, такой стиль написания кода усложняет процессы разработки, тестирования и поддержки кода.
Но почему реактивщина стала с каждым днем становится все более популярней?
Причин довольно много, но я упомяну лишь два наиболее важных (по моему мнению):
Эффективное использование ресурсов (это утверждение истинно только если вы используете неблокирующий код).
Отзывчивость системы (Responsive)
Реактивный + неблокирующий подходы = нефть, золото, греча и, конечно же, акции эппл.
Отгадайте, кто сожрет все потоковые ресурсы?
Если проанализировать среднестатистический цикл жизни потока то можно заметить что большую часть времени (иногда по 99% времени)
находится либо:
В состоянии ожидании доступа к локу те в состоянии ожидании монитора BLOCKED или WAITING
В "логическом ожидании" какого то ресурса как то ответа базы, сервиса или просто базы.
И это очень очень плохо. В текущих реалиях даже среднестатистический процессор обладает огромными мощностями. Большинство операций занимают нано и микросекунд, но ожидания и блокировки руинят всю производительность.
Решением является совместное использования реактивщины и неблокировщины. Первая организует процесс в котором пул потоков ожидает задачи под выполнение а неблокирующий подход не заставляет ждать потока в рамках одной из задач.
Отзывчивость системы. (Responsiveness)
Один из весомых плюсов реактивщины - возможность получения данных по мере их появления. А как следствие любые решения поверх реактивщины отзывчивы для пользователя и не висят тысячами лет пока все данные не подгрузятся.
Давайте уже, что нибудь попишем.
Как я уже упомянул есть несколько реактивных решений, но в рамках статьи мы напишем Спринговые классические решения.
Перед тем как начать. Если выше на путь реактивнищы - пути обратно нет. Все слои внутри приложений надо стараться писать именно в этом стиле. И конечно не забывать про неблокируйщий подход. Если следовать блокирующему то потоки будут стопорится именно у такой блокируюей воронки.
Что это значит на практике?
А на практике это значит что старые библиотеки вроде rest template (общение по http), jdbc template (связь с базой) должны быть выпилены и заменены не реактивные и неблокирующие:
Пример ниже не является самым сложным, но скорее показательным. Напишем простую локику:
К нам приходит http запрос
Мы перенаправляем запрос в базу
Как база дает первый ответ мы кидаем данные на фронт
Данные на фронте парсятся по мере появления (а не лишь когда все будут доступны)
Если говорить упрощенно то весь код по сути будет сводится к тому что мы будем прокладывать трубы в виде Flux или Mono объектов.
Стоит помнить что вся реактивная магия Спринга возможно лишь когда при его старте используется WebFlux'овый фреймворк. Старый вариант запуска Спринга с каким нибудь томкатом под капотом не сработает. Поэтому зависимости ниже обязательны:
Начнем с базы, используем
Пробросим Flux используя DatabaseClient:
Теперь полученный Flux выставим на сторону фронта:
Наверно вы заметили что возвращаемый тип не application/json. Да тип x-ndjson. Если использовать стандартный application/json то данные которые будут улетать на фронт будут неполный и конвертировать их в целые объекты будет головной болью. Это недостаток потокового подхода (хотя по сути это 1 http запрос, просто растянутый). x-ndjson формат позволяет кидать на фронт кидать объекты
Читаем на фронте. Код неидеален, скорее служит в качестве простого примера.
Код выше делает следующее:
Делает http запрос
Ожидает ответа
Как только ответ прилетает начинает читать его по частям и писать в конcоль
Приведенный пример является довольно простым, возможности WebFlux гораздо богаче и позволяют манипулировать данными в асинхронном, реактивном подходе. Но код становится сложнее для написания, чтения и поддержки.
Еще раз про эффективный расход процессорных ресурсов.
Я еще раз хочу упомянуть что реактивные, неблокирующие решение написанные прямыми руками позволяют выжать максимум из предоставленных ресурсов. Особенно это актуально во времена микросервисов. Все чаще на проектах под небольшой микросервис могут выделить не более чем 1/0.5/0.1 CPU и я в общем поддерживаю такой подход.
Виртуальные потоки VS Реактивщина.
Эта тема заслуживает отдельного поста. И он будет следующим если эта статья зайдет. Дайте знать в комментах если интересно.