Когда я выкладывал резюме, у меня количество приглашений было 20+, а я даже не откликался на эти вакансии, в то время, как у некоторых однокурсников было всего 2-3. Помимо везения есть ещё ряд факторов и критериев, на которые обращают внимание HR и те, кому они передают резюме для ознакомления. На эту тему общался с HR и как-то хотел написать это в статье. Но все эти факторы настолько субъективны, спорны и порой обидны, хотя почти все поправимы, что, боюсь, если я их перечислю, меня закидают шапками, что я вообще не прав и всё совсем не так)))
Про Reactor Netty: В основном, конечно, сейчас реактивное программирование идёт на Spring через WebFlux. Какого-то удобоваримого ресурса по Reactor Netty в чистом виде на русском я не встречал, в учебниках вроде Spring Boot 2, который я приводил, эта тема даётся как преддверие к WebFlux. Помимо https://projectreactor.io/learn, роликов на Ютубе и статей, только курсы, где изучается NIO -> Netty -> Reactor Netty -> WebFlux.
Я сразу понял, что у Вас большой опыт в Java. Никак не хочу принижать вес Вашего опыта и знаний. Но и Вы поймите, во-первых, то распределение – не моё know how, я не выдаю его за единственно верное и дал его как пример одного из, а во-вторых, в курсах и учебных пособиях, которые созданы тоже людьми авторитетными в мире Java с опытом таким же значимым как и у Вас каноничным является именно такой приоритет для градации компетенций в Java. Вашу логику я понимаю, но я буду придерживаться всё же того приоритета, который описал выше.
Есть мнение, что программирование это как раз гуманитарная наука. Так что из гуманитария вообще может быть даже в каком-то плане удобнее переквалифицироваться.) Тут главное видеть цель и не замечать препятствий)
Фактор везения всегда присутствует. Но мне кажется, тут больше сыграли такие факторы, как труд и подготовка, если конечно не считать момента, когда я попал в команду из которой от состава в 5 разработчиков в начале года к концу осени остался всего один и это был я. Тут уж повезло, так повезло.)
Я тоже как и Вы считаю, что Junior не должен заниматься многопоточностью, потому что действительно это – объективно сложно. С этим согласен. Также возможно Вы отчасти правы касательно коллекций, но при всей низкоуровневости считаю, что методы класса Object wait/notify/notifyAll "Junior должен как минимум знать", а именно в такой формулировке я это привёл изначально.
Wait/notify/notifyAll в совокупности со sleep, synchronized, volatile, Thread, Runnable (+ не всегда, но зачастую ещё Future и Callable) именно так идут во всех учебниках для новичков и начинающих, преподаются на 6-м и 7-м уровнях курса Java Core на JavaRush. Это база. В отличие от Atomic'ов которых обычно на первом этапе обучения Java нет!, а они появляются уже потом, когда изучается механизм CAS.
Для меня Stream API — более удобный, компактный, функциональный, но не всегда эффективный сам по себе, как и Parallel Stream. Зачастую нужно профилировать.)) Кстати, если кто-то не в курсе, то начиная с версии 2017.3 в IDEA встроен Stream Debugger во вкладке Trace Current Stream Chain:
OpenAI создавшие ChatGPT тоже принимали участие в разработке Copilot. Он, является ярким примером интеграции в IDE, которую я упомянул. Как и его аналоги (например, JARVIS от Сбера), он больше ориентирован на помощь в подборе вариантов исходя из описания контекста в самом процессе кодинга. Механизм несколько другой, порой более уместный, но зачастую, если уже знаешь, что хочешь и как это хочешь, написание контекста занимает больше времени, чем если писать сам код.
Действительно, в большей степени согласен с Вами. Поэтому я и попытался сформулировать тезис, что, на мой взгляд, это будет в будущем времени при условии, что AI будет постоянно совершенствоваться и как раз хотел подчеркнуть, что это не "ликвидирует", а "сократит дефицит".
Эта практика копирования ошибки из консоли, действительно куда лучше, чем писать "Твой код не работает, найди ошибку", на что можно получить ответ "У меня всё работает"))) В своей практике я сталкивался с ошибками, в основном, при первом варианте работы, когда пытаешься скормить не маленькую задачу (которая тут рассмотрена), а очень объёмную. Но там помимо ошибок порой приходят такие фортели, что ошибка является не самой большой проблемой кода.
Ок, тогда напишу в личку.
Когда я выкладывал резюме, у меня количество приглашений было 20+, а я даже не откликался на эти вакансии, в то время, как у некоторых однокурсников было всего 2-3.
Помимо везения есть ещё ряд факторов и критериев, на которые обращают внимание HR и те, кому они передают резюме для ознакомления.
На эту тему общался с HR и как-то хотел написать это в статье.
Но все эти факторы настолько субъективны, спорны и порой обидны, хотя почти все поправимы, что, боюсь, если я их перечислю, меня закидают шапками, что я вообще не прав и всё совсем не так)))
Про Reactor Netty: В основном, конечно, сейчас реактивное программирование идёт на Spring через WebFlux.
Какого-то удобоваримого ресурса по Reactor Netty в чистом виде на русском я не встречал, в учебниках вроде Spring Boot 2, который я приводил, эта тема даётся как преддверие к WebFlux.
Помимо https://projectreactor.io/learn, роликов на Ютубе и статей, только курсы, где изучается NIO -> Netty -> Reactor Netty -> WebFlux.
Я сразу понял, что у Вас большой опыт в Java. Никак не хочу принижать вес Вашего опыта и знаний.
Но и Вы поймите, во-первых, то распределение – не моё know how, я не выдаю его за единственно верное и дал его как пример одного из,
а во-вторых, в курсах и учебных пособиях, которые созданы тоже людьми авторитетными в мире Java с опытом таким же значимым как и у Вас каноничным является именно такой приоритет для градации компетенций в Java.
Вашу логику я понимаю, но я буду придерживаться всё же того приоритета, который описал выше.
Есть мнение, что программирование это как раз гуманитарная наука. Так что из гуманитария вообще может быть даже в каком-то плане удобнее переквалифицироваться.)
Тут главное видеть цель и не замечать препятствий)
Фактор везения всегда присутствует. Но мне кажется, тут больше сыграли такие факторы, как труд и подготовка, если конечно не считать момента, когда я попал в команду из которой от состава в 5 разработчиков в начале года к концу осени остался всего один и это был я. Тут уж повезло, так повезло.)
Я тоже как и Вы считаю, что Junior не должен заниматься многопоточностью, потому что действительно это – объективно сложно. С этим согласен.
Также возможно Вы отчасти правы касательно коллекций, но при всей низкоуровневости считаю, что методы класса Object wait/notify/notifyAll "Junior должен как минимум знать", а именно в такой формулировке я это привёл изначально.
Wait/notify/notifyAll в совокупности со sleep, synchronized, volatile, Thread, Runnable (+ не всегда, но зачастую ещё Future и Callable) именно так идут во всех учебниках для новичков и начинающих, преподаются на 6-м и 7-м уровнях курса Java Core на JavaRush. Это база.
В отличие от Atomic'ов которых обычно на первом этапе обучения Java нет!, а они появляются уже потом, когда изучается механизм CAS.
Для меня Stream API — более удобный, компактный, функциональный, но не всегда эффективный сам по себе, как и Parallel Stream. Зачастую нужно профилировать.))
Кстати, если кто-то не в курсе, то начиная с версии 2017.3 в IDEA встроен Stream Debugger во вкладке Trace Current Stream Chain:
OpenAI создавшие ChatGPT тоже принимали участие в разработке Copilot. Он, является ярким примером интеграции в IDE, которую я упомянул. Как и его аналоги (например, JARVIS от Сбера), он больше ориентирован на помощь в подборе вариантов исходя из описания контекста в самом процессе кодинга.
Механизм несколько другой, порой более уместный, но зачастую, если уже знаешь, что хочешь и как это хочешь, написание контекста занимает больше времени, чем если писать сам код.
Действительно, в большей степени согласен с Вами.
Поэтому я и попытался сформулировать тезис, что, на мой взгляд, это будет в будущем времени при условии, что AI будет постоянно совершенствоваться и как раз хотел подчеркнуть, что это не "ликвидирует", а "сократит дефицит".
Эта практика копирования ошибки из консоли, действительно куда лучше, чем писать "Твой код не работает, найди ошибку", на что можно получить ответ "У меня всё работает")))
В своей практике я сталкивался с ошибками, в основном, при первом варианте работы, когда пытаешься скормить не маленькую задачу (которая тут рассмотрена), а очень объёмную. Но там помимо ошибок порой приходят такие фортели, что ошибка является не самой большой проблемой кода.