В оригинале не нашлась для скачивания, а русская везде лежит, пусть и здесь будет.

В общем, охват тем широкий, возможно даже слишком. Прочитав эту книгу, будешь знать шаблоны, потоки, ввод/вывод, параллельное выполнение, регулярные выражения, есть интересная информация о дженериках и тд. Она, бесспорно, способна систематизировать знания, но предназначена совсем не для того, чтобы овладеть Java, скорее, чтобы понять, как язык работает.

Предыдущая версия OpenJDK с Long Term Support, Java 11, вышла ровно 3 года назад.

Но вот уже вышло 5 версий (12, 13, 14, 15, 16) и мы не успели опомниться, как подоспела следующая LTS-версия, Java 17.

Сделано много улучшений производительности, оптимизировано потребление памяти, уменьшено время старта JVM и многое другое.

Подробнее в статье:
https://habr.com/ru/post/577924/

Пройдемся по основам?

import java.util.Scanner;
class Main {
public static void main(String[] args) {
int[] m = {-1,0,1};
Scanner sc = new Scanner(System.in);
try {
int a = sc.nextInt();
m[a] = 4/a;
System.out.println(m[a]);
} catch (ArithmeticException e) {
System.out.println("Произошла недопустимая арифметическая операция");
} catch (ArrayIndexOutOfBoundsException e) {
System.out.println("Обращение по недопустимому индексу массива");
}
}
}

Слушайте!
Слушаете?)

Ловите хорошие подкасты для вечерней пробки:

⏯ Coding Blocks. Подкаст для всех разработчиков, много качественной информации о процессах, шаблонах проектирования, реализации баз данных, объектно-ориентированном программировании и многом другом.

⏯ Подкаст Inside Java – это шоу для разработчиков Java, его записывают ребята, которые создают Java в Oracle. Темы: про язык, JVM, OpenJDK, безопасность платформы, инновационные проекты, такие как Loom и Panama и много чего еще.

⏯ JavaHut. Бодрые выпуски не только на тему Java, но и о технологиях в общем.

⏯ Подкаст «Откровенно про IT-карьеризм» – для тех, кому актуальна подготовка к собеседованию. Программист и HR-manager обсуждают темы резюме, собеседований, вопросы построения карьеры.


Что еще послушать? музыку! :)

Не шучу, серьезно.
Почти всегда работаю с музыкальным сопровождением, у меня тут пара новых открытий: Esone, Funky Bijou и Def Cut – треки в стиле breakbeat, как-то бодро под них работается. А вот еще группа, которая делает спокойную фоновую музыку – Hammock.

Ребята из «Миран» провели тесты производительности и сравнили Java 11, Java 16 и Java 17. Прирост производительности неплохой относительно всех версий, нету только сравнений с Java 8, а на ней у многих большое количество рабочих проектов.

Статья тут: https://habr.com/ru/company/dcmiran/blog/578300/

Периодически собеседую джунов и встречаю полное отсутствие понимания принципов ООП, не могут объяснить даже основные принципы. Это ладно, можно просто не брать джуна). Но бывает вижу это не только у начинающих. И иногда это опытные ребята, которые не понимают, что весь смысл ООП сводится к тому, чтобы так переформулировать задачу и её решение, чтобы писать надо было поменьше и понятнее. Наследование и полиморфизм для них просто инструмент, а что там в основе этих механизмов – неважно. Не жалуюсь, просто хочу реже такое встречать.

Ну что, проверим, как хорошо вы помните ООП и переопределение в частности? 😈

Как оптимизировать митинг: не проводить его.

Да-да, всех бесят затянутые совещания, дейли и бесконечные стендапы. Конечно, есть продакт или скрам, который должен все это контролировать. Но мне кажется, если каждый участник немного ответственней отнесется к процессу, легче станет всем. Вот мои простые, но почему-то не всем очевидные рекомендации:

👍 Готовься, не надо вспоминать на месте статус своей задачи. Если занимаешься другими делами до встречи, за несколько минут переключи контекст в голове.

👍 Не бери с собой ноутбук, убери телефон. Не решай другие задачи во время митинга, сейчас твоя задача – митинг.

👍 Держи фокус на повестке, а себя в руках). Не пускайся в обсуждение вопросов, которые связаны с другими задачами, не поддерживай отхождение от темы у коллег. Если в конце встречи останется время и ты считаешь, что это сильно необходимо обсудить сейчас, можешь предложить.

👍 Уважай коллег: не опаздывай, не переходи на личные разговоры.

👍 Развивай скилы, касающиеся выступлений и ораторских способностей. Учись четко формулировать мысль, говорить лаконично и по факту.

Почему лень – это хорошо?

➕Ленивые дольше живут! Есть исследование моллюсков Атлантического океана, которое пришло к выводу, что кальмары и каракатицы, которые активней других расходовали энергию, умирали (и даже вымирали!) значительно раньше.

➕ Лень восстанавливает мозг. Свободные от нагрузки периоды нужны голове, чтобы переработать всю информацию, подгрузить новые данные и выдать классное решение.

➕ Лень учит работать быстрее. Ленивые не начинают заранее и часто делают в последний момент.
Тонкий аромат дедлайна учит бежать быстрее, это факт.

➕ Самые мощные инсайты и озарения приходят во время ничегонеделания. Представляете, есть даже название сего феномена: «эффект инкубации».

➕ Умные бездельники – самые ценные сотрудники. Они способны предложить решение, которое будет максимально быстрым и требует минимальных ресурсов. Качество не страдает, ибо переделывать тоже лень.

➕ Благодаря лени человеческой у вас по дому ездит робот-пылесос, есть посудомоечная машина и даже дворники на машине. Лентяи заботятся о лени других!

➖ Кстати, мне было лень писать этот пост.

Парето и код-ревью

Считаю, что принцип 80/20 часто работает и в вопросе код-ревью, ибо только 20% вносимых замечаний правят баги и вскрывают важные ошибки. Остальные 80 – это субъективщина: человек привык использовать одну структуру классов, а ты внес другую. А еще он знает более модную библиотеку и паттерн проектирования из книжки ну очень просится сюда. А в итоге код остается тем же и по функциональности, и по простоте/сложности. Естественно, я не говорю про ситуации, когда, например, сеньор правит джуна и замечания влияют на гибкость кода, тут о другом.

И нет, отказываться от код-ревью, конечно нельзя, это важная часть процесса, взгляд со стороны нужен в любом случае. Но когда есть несколько способов решить проблему, всегда будут возникать другие мнения.

И вся эта шлифовка для красоты приводит только к тому, что повышается стоимость разработки, дизморалится разработчик, которого правят. На команду тоже влияет, так как работа над продуктом замедляется.

Идеально красивый код – не цель, цель – работающий продукт. Работайте на результат, а не над красотой кода.

Oracle выложили записи с конференции OracleDevLive, там много всего про новую Java 17, а еще про Vector API, Helidon, GraalVM и тд. Если планируете переходить, будет полезно.

Ссылка: https://developer.oracle.com/developer-live/java-innovations-sep-2021/

Продолжая тему пятничного поста про код-ревью, грех не вспомнить про «Чистый код» Роберта Мартина.

Краткий обзор от меня, судя по тому, что помню:

📕 Мысли и советы вроде как простые и очевидные, но зачастую игнорируемые даже опытными программистами.

📕 Основной посыл в том, чтобы писать код, который просто работает, а еще чтобы увеличивать срок его службы за счет этого.

📕 Книга скорее для ребят 1-3 года в программировании, учит задумываться об оптимизации блока кода до начала написания этого же блока и будет отличным туториалом, чтобы привить себе навыки грамотного написания и документирования кода. Совсем начинающим будет сложно осилить главу про многопоточность, например. А опытным рекомендую сделать эту книгу настольной (см.1 пункт :))

📕 Есть местами перевес в сторону идеального кода с забиванием на прагматизм. Я все-таки придерживаюсь мнения, что чистый код нужен не просто для красоты, а из практических соображений.

📕 В книге мало воды и есть смешные шутки)

📕 Перевод нормальный, но с некоторыми терминами не очень соглашусь, прикреплю вам русскую версию 2019 года полистать.

Закончу в стиле статусов ВК из нашей юности)

«Чистый код всегда выглядит так, будто его писал человек, которому не всё равно», Майкл Фезерс.

Чтобы работать рядовым разработчиком необязательно уметь эффективно сортировать списки и уметь строить бинарные деревья.

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

Структуры данных – основа всех вычислений, большая часть программирования вращается вокруг манипулирования структурами данных. Выбор неподходящих структур будет иметь огромное значение, особенно если проект большой.

У каждой профессии есть свои инструменты – это наши.

Безусловно на повышение скила это будет работать только в сумме с хорошим знанием своей основной платформы.

Если вдруг вы тот самый разработчик, который однажды подзабил на это, точно знаю, что вот эти два курса очень неплохие:

➡️https://www.udemy.com/course/introduction-to-data-structures/

➡️https://ru.coursera.org/specializations/data-structures-algorithms

Есть вся база, отличные примеры.
Про литературу по этой теме сделаю пару постов потом.

Ну и старый, но все еще радующий мем для бодрости духа при изучении

Смотрите какая классная статья по вопросам на собеседованиях о Spring Boot. Мне очень нравится, что она именно про понимание процессов, а не простое заучивание функционала. Всегда бы так.

Ссылка:
https://habr.com/ru/post/544472/

Как выглядит типичный дейлик