Всем привет!

Недавно вышла 22-я Java. Обычная, не LTS версия.
Вот неплохой обзор нововведений https://habr.com/ru/articles/801467/

Что могу отметить: из 12 JEP - больших фичей Java по сути - по которым велась работа в релизе, 7 появились в предыдущих версиях. Т.е фиксят и рефакторят.

Что же появилось интересного из новых фичей?

Launch Multi-File Source-Code Programs (JEP 458) - возможность быстрого запуска из командной строки без сборки в jar для кода, разбросанного по нескольким файлам. Запускать код из одного файла можно было и ранее.
Вместе с появившимся в 21 Java Implicitly Declared Classes and Instance Main Methods (Second Preview) (JEP 463) - запуск кода из простого метода main без параметров и без класса - видна тенденция упростить вкатывание новичков в Java, сделать его похожим на тот же Python.

Stream Gatherers (Preview) (JEP 461) - если раньше для стримов можно было писать свои коллекторы, то сейчас можно будет и gatherer - промежуточные операции. Кажется интересная тема, открывает возможности для большого расширения возможностей стримов. Странно, что ждали 14 версий)

Class-File API (Preview) (JEP 457) - если раньше для работы с байт-кодом использовались сторонние библиотеки, одна из которых - ASM - была первой среди равных, т.к. поставлялась с JDK, то сейчас сделали ее аналог уже в составе JDK. Цель - чтобы изменения в API Java и в API для работы с байт-кодом были синхронизированы. Тоже в общем-то вполне логичная фича.

Ну и еще одна мелкая фича, появление как я подозреваю которой приведет к тому, что появятся новые головоломные задачки на собесах. Statements before super(...) (Preview) (JEP 447) - как следует из названия в конструкторах можно писать код перед вызовом super(), но не любой, а только не нарушающий порядок инициализации класса. Это вам не Spring, никаких проксей) Т.е. код в прологе не должен ссылаться на конструируемый объект, включая поля из суперкласса и на экземпляры внутреннего класса.

P.S. Да, все еще идут споры по String Templates, про которые я писал ранее https://t.me/javaKotlinDevOps/246 Делать их расширяемыми или как у всех) В 22-й Java пока оставили как было

#java #java_new_version #interview_question

Всем привет!

Один из достаточно частых вопросов на собеседованиях - расскажите про стримы в Java, их плюсы и минусы. Если говорить о минусах - всегда под вопрос ставится быстродействие. У меня давно было желание его сравнить, но как часто бывает - меня опередили.
Вот неплохая статья про быстродействие стримов: https://habr.com/ru/articles/807647/

Какие выводы я сделал:

1) тот факт, что на небольшом объеме данных цикл forEach опережает любые виды стримов - ни о чем, им можно пренебречь. Как минимум в 99% случаев. Мне сложно представить кейс, когда объем данных невелик, но нужно выиграть миллисекунды. Скорее всего эти миллисекунды, или даже десятки миллисекунд, мы потеряем на сетевом взаимодействии. У нас же микросервисы, а это значит много сетевых вызовов. Если говорить о причинах - понятно, что на малых объемах данных накладные расходы, которые конечно же есть у стримов, играют роль. И еще момент - чем проще кусок кода, выполняющийся внутри стрима, тем больше отношение накладных расходов стримов к полезному действию.

2) parallelStream в большинстве случаев бьет forEach на больших объёмах данных. Почему так тоже понятно - эффект распараллеливание становится выше, чем накладные расходы на определенном объеме данных.

Итог: стримы можно использовать как вариант по умолчанию, т.к. они улучшают читаемость кода. В высоконагруженных приложениях\ больших объёмах данных имеет смысл смотреть в сторону parallelStream, особенно если есть результаты нагрузочного тестирования. Ну и только на каких-то критичных участках кода, имея на руках результаты НТ, имеет смысл переписать все на циклы

#streams #performance #interview_question

Типовые ошибки на собесах.

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

Часто на интервью есть либо задачки на live coding, либо задачки на подумать - не имеющие точного ответа.
И тут я сталкиваюсь с 2 типовыми ошибками:

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

2) кандидат скажем так сильно прикипел к своей предметной области. Предположим, его типовые задачи - реализация новых REST методов, а способ - связка controller-service-repository. Он получает задачку на собесе и сразу начинает выполнять ее по той же схеме, как делал бы на текущем месте работы. Что тут плохого? Только то, что интервьюер возможно хотел проверить знания алгоритмов, паттернов надежности или чего-то еще. А вовсе не умение раскладывать код на по слоям controller-service-repository. И получается как в анекдоте: "Некогда думать, трясти надо". Правильное решение - уточнить, что хотел интервьюер. А потом еще раз уточнить) Важнее четкое понимание задачи и обсуждение путей ее решения, чем скорость написания кода. Да, это может занять столько же времени, сколько и написание кода. И это нормально. Есть компании с нормой решенных задач на собес, но в любом случае неверно решенная задача в зачет не идет.

P.S. Отдельный важный момент связан с live coding - и это тесты. Можно сколько угодно говорить, что "надо написать тесты, я обычно так делаю, но сейчас времени нет.." Но лучше их просто написать) Можно даже перед кодом, по TDD.

#interview #interview_fails

live coding это все-таки кодинг

Недавно писал про то, что на сессии live coding на собесе не надо сразу браться за задачу, вначале стоит позадавать вопросы и продумать путь решения задачи.

Но есть и обратный кейс. Пусть у нас остается максимум полчаса времени собеса. Есть задача на live coding. И вообще то задачку можно сделать за 10 минут. И, естественно, это понимают люди, ведущие собес. Как они отнесутся, если кандидат потратит 10 минут на вопросы, 10 минут на рассуждения как лучше реализовывать и 10 минут на написание кода? И как всегда без тестов, по причине того, что тесты бы написать надо, но времени нет. Ответ - плохо отнесутся.

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

В общем не делайте так

#interview #interview_fails

AI и leetcode

Есть ряд известных компаний, предлагающих решение алгоритмических задачек на собесах. Почему они так делают в целом понятно - проверка алгоритмического мышления кандидата и навыков \ скорости написания кода.

Что меняется с появлением AI?

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

2) с точки зрения сторонников данной практики ничего не меняется - такие задачки как проверяли способности к мышлению, проектированию и кодированию, так и проверяют. И я думаю, что они останутся на собесах

3) у противников данной практики основной аргумент усиливается. Если раньше можно было сказать - с вероятностью 90% мне это в реальной работе не понадобится, то сейчас цифра примерно равна 99%)

4) но возникает интересный момент. Вот решил кандидат за 1.5 часа 3 задачки. Даже 10 минут в резерве осталось. Появляется чувство: "А я хорош!)". Возникает мысль - интересно, а AI агент эти задачки решит. И агент решает их за 10 минут... И какие-то самые некрасивые мысли лезут ко мне в голову...

#ai #interview #algorithms