Java: fill the gaps

Тест на бюрократию Недавно закончился набор на курс многопоточки, и захотелось написать пост про бюрократию. Курс можно было оплатить со стороны работодателя, но в итоге сорвалось 4 заявки: за 2 недели процесс согласования даже не продвинулся. А где-то мы списались с HR и за один(!) день закончили весь процесс. Откуда вообще берётся бюрократия? Уровень бюрократии не всегда связан с размером компании и численностью сотрудников. Истоки бюрократии хорошо описаны в книге "Good to Great": Задача бюрократии — компенсировать отсутствие компетентности и дисцип­лины; такая проблема не возникает, если с самого начала правильно подобраны кадры. Большинство компаний создают свои бюрократические порядки, чтобы управлять небольшим процентом «неправильных» людей на корабле. Это в свою очередь заставляет лучших специалистов уходить. Увеличивается процент посредственных специалистов, что опять-таки приводит к необходимости создания ещё более жесткой бюрократии, чтобы компенсировать некомпетентность и отсутствие дисциплины, это ещё больше отталкивает лучших и т.д. По мне слишком категорично, но доля правды есть. Как оценить уровень бюрократии уже на собеседовании? Оставим в стороне кухонные разговоры и перейдём к практике. Каждому хочется работать в комфортной среде и не тратить много сил на бумажки и согласования. Чтобы примерно оценить бюрократический накал, спросите на собеседовании - что нужно сделать, чтобы пройти обучение или поехать на конференцию? В бюрократических компаниях вам придется: 😐 Писать заявки 😒 Вписаться в лист ожидания где-то в недрах конфлюенс 😠 Обосновать потребность 😤 Самостоятельно следить за процессом 😡 Заключить договор, по которому вы оплатите часть стоимости, если уволитесь в ближайшие два года Если от вопроса начнут уходить - это плохой знак. В хорошей компании от вас требуется 1-2 пункта. Идеально, если вы просто обращаетесь к специальному человеку, который уведомит вас о результатах в разумные сроки.

Масштабирование: основные типы Что такое масштабирование? Какие виды вы знаете? - популярные вопросы на собеседованиях на позицию мидл и выше. На практике нас волнует не абстрактная стратегия масштабирования, а вполне конкретный вопрос: как обеспечить тот же уровень сервиса, если нагрузка на систему вырастет. Иногда достаточно просто поменять код. Например, добавить кэш и снизить нагрузку на БД. В итоге сервис обработает в 10 раз больше запросов, и этого улучшения хватит на несколько лет. Но это не масштабирование, а оптимизация. При масштабировании считается, что с кодом всё отлично и мы упираемся в физические ресурсы. Процессор не справляется, память кончается и так далее. И вопрос становится более конкретным: как добавлять аппаратные ресурсы к текущей системе? На самом верхнем уровне масштабирование делится на горизонтальное и вертикальное. Вертикальное - запускаем сервис на более мощной машине. Даже если сервис разворачивается в облаке, этот вариант быстро становится дорогим и неоптимальным. При горизонтальном нагрузка распределяется на несколько машин ✅ Отказ одного экземпляра не так страшен ✅ Пределы масштабирования гораздо шире ❌ Нужна инфраструктура для поддержки В книжке Art of Scalability приводится концепт scale cube и три вектора горизонтального масштабирования: 🔸Horizontal duplication: несколько копий одного сервиса ✅ Простая реализация, нам нужен только балансировщик ❌ Запутанный код ❌ Тяжело обновлять версию сервиса ❌ Большие и перегруженные кэши 🔸Functional decomposition: делим монолит на микросервисы Каждый сервис отвечает за небольшой функционал ✅ Простой и понятный код каждого сервиса ✅ Более специфичные и эффективные кэши ❌ Поделить монолит на отдельные сервисы и наладить общение между ними - чудовищно непросто ❌ Сложная инфраструктура 🔸Data partitioning или шардирование Сервисы одни и те же, но каждый экземпляр работает на ограниченном количестве данных и своём экземпляре БД ✅ Отказы БД менее критичны ✅ Кэширование работает отлично ❌ Нужен компонент для перенаправления запросов ❌ Сложная логика работы с данными На практике три подхода комбинируются в разных пропорциях.

IDEA: магия вне Хорвартса Обычно я пишу о полезных фичах IDEA, которые помогают писать код быстрее и проще. Но не сегодня. Сегодня расскажу о фиче, которая впечатлит ваших коллег. Чтобы они такие: "вау, как ты это делаешь???", а вы так загадочно улыбаетесь. Отлично подойдёт для обсуждения кода при личном общении и при демонстрации экрана на онлайн-встречах. Как вставить один и тот же код в несколько мест? Обычные разработчики использую Ctrl+C и Ctrl+V, а настоящие шоумены - мультикаретки. 🔸 Добавляете каретку через Shift + Alt + Левый клик 🔸 Начинаете печатать Вместо клика можно выделить часть текста и одновременно работать с несколькими фрагментами кода. Чтобы вернуться в нормальный мир с одной кареткой, нажмите Esc. Выглядит как магия, честное слово🔮

Набор на курс завершён! Спасибо всем, кто присоединился❤️ Спасибо всем, кто не отписался🙂

Последний шанс присоединиться к курсу Ребята, сегодня ПОСЛЕДНИЙ день, когда можно вписаться в группу. Посмотрите ещё один отзыв участника: Даже если вы читали "Java Concurrency in Practice" , вы узнаете что-то новое. Лекции короткие, насыщенные - первый курс за год, где я слушал не на 2x скорости видео. Задачи больше на понимание, с подводными камнями, комментарии преподавателя бесценны 😍 Не нужно писать тонны кода, но нужно разобраться, что происходит, и залезть в документацию. Стандартные задачи на лекциях рассматриваются, как примеры. Хорошо систематизирует знания и добавляет новые краски дизайну частей JDK. Входной уровень нужен, это не с нуля совсем курс, и больше про правду разработки, разбавленную вопросами с собесов, а не про чистые знания. Курс однозначно рекомендую, ни разу не пожалел, что прошёл. Программа, цены и другие отзывы здесь: https://fillthegaps.ru/mt2 Заявки принимаются до 20 часов, потом набор будет закрыт

Вам в какую очередь? В пакете java.util.concurrent доступно 7 очередей. Самые простые из них это

🔸 ArrayBlockingQueue
🔸 LinkedBlockingQueue
🔸 ConcurrentLinkedQueue

В этом посте кратко расскажу, чем они отличаются и как выбрать подходящую. Часть 1: внутреннее устройство По названию класса легко предположить, что одна реализация сделана на основе массива, а две - с помощью связного списка. Что это даёт? По сути - ничего. Вспомним 2 списка с похожим строением - ArrayList и LinkedList. В первом легко искать элемент по индексу, во втором - вставлять и удалять элемент из середины списка. Для очереди это не важно, потому что нас интересует только работа с началом и концом очереди. Часть 2: механизм синхронизации А здесь уже интереснее: 🔹 ArrayBQ использует один ReentrantLock 🔹 LinkedBQ - два ReentrantLock: один для начала очереди, другой - для конца 🔹 ConcurrentLQ использует CAS операции для обновления крайних элементов Давайте попарно сравним их между собой ▪️ArrayBQ и LinkedBQ Отдельные локи для начала и конца очереди в LinkedBQ хорошо работают, когда начало очереди не совпадает с концом. То есть в очереди всегда что-то есть. С двумя локами с очередью в каждый момент времени могут работать два потока. Если размер колеблется около нуля, то поддерживать два лока слишком затратно, гораздо проще работать с одним локом на всю очередь. Это вариант ArrayBQ. Поэтому первый критерий, по которому выбираем экземпляр очереди: сколько элементов она содержит большую часть времени. ▪️LinkedBQ и ConcurrentLQ Допустим, наша очередь никогда не пустует. Что лучше - два ReentrantLock или две CAS операции? Здесь разница в методах, которые нам нужны. CAS операции обновляют только сами элементы - начало и конец очереди. ReentrantLock ограждает критическую секцию, внутри которой ▫️ Проверяется текущий размер и сама возможность добавить в очередь ▫️ Обновляется начало или конец очереди ▫️ Уведомляются потоки, которые, возможно ждут на другом конце очереди Добавление и удаление в ConcurrentLQ происходит очень быстро. Если нужны дополнительные опции - фиксированный размер, блокирующие вызовы, то лучше подойдёт LinkedBQ. Поэтому критерий выбора очереди №2: необходимые методы и ограничения на размер

Началась последняя неделя набора на Тот Самый Курс🔥 Must have для разработчиков, которые мало работали с многопоточкой, но готовы закрыть этот пробел за 2 месяца. Прочтите отзыв участника первого потока: Курс дает, или способен дать, гораздо больше, чем можно было бы предположить по списку тем. Сложность только в том, чтобы унести как можно больше. ++ насыщенные домашние задания. Не "повтори услышанное за преподавателем" и не "а не вольтметром ли измеряется напряжение", часто приходилось действительно попотеть. Вопросы отчасти перекрываются с материалом лекций, а отчасти расширяют его, что особенно круто - когда что-то откопал своими усилиями, запоминается оно гораздо лучше. ++ есть и теоретические вопросы, и задания на написание и переписывание кода, в т. ч. на основе примеров из самых популярных опенсорс-проектов. ++ максимально добросовестный подход. Все задания проверялись даже раньше обещанного срока, на все вопросы были получены развернутые ответы, а к непонятным местам (в лекциях, заданиях, примерах) - исчерпывающие комментарии. ++ отличная атмосфера на курсе. Как будто бы получаешь объяснения от самого себя из той версии будущего, где ты в сложной теме разобрался. :D + высокая плотность занятий. Казалось бы, много ли можно уложить в 10-20 минут лекции плюс задания к ней? Оказывается, много. - были небольшие шероховатости по наполнению лекций (напр., иногда важные моменты проговаривались голосом, но отсутствовали на слайдах) и по формулировке отдельных вопросов. - Сама платформа неидеальная: было несколько случаев, когда отправленный текстовый ответ терялся. На такой случай развернутые ответы лучше писать и сохранять у себя локально, в текстовом файле. В целом, курс превзошел все возможные ожидания. Спасибо огромное! Присоединяйтесь, стартуем уже в следующий понедельник🚀 https://fillthegaps.ru/mt2

Популярные вопросы по поводу курса ❓ Я сеньор, читал Java Concurrency in practice и прошёл курсы на курсере, мне будет интересно? Если у вас мало опыта в решении реальных задач - однозначно да. С уверенной теоретической базой вы глубже прочувствуете практические нюансы и лучшие практики. НО если после первой недели вы поймёте, что вам курс не подходит - я без проблем оформлю полный возврат. ❓ Я с многопоточкой никогда не работал, только на собеседованиях рассказывал, мне подойдёт? Цель курса - максимально подготовить вас к реальным задачам. Если вы знаете основы многопоточки, как написать сервис на Spring и у вас есть пара лет опыта - можно идти на курс. Java - дружелюбный для разработчиков язык. Уже написаны тысячи проектов, лучшие практики давно наработаны, а ошибки - известны. За два месяца вы заполните все пробелы и будете готовы решать реальные задачи. ❓ У меня летом отпуск, я успею пройти курс? Да, можно спокойно сходить в отпуск, если в остальное время вы идёте по графику учёбы. На втором тарифе предусмотрено две бонусные недели с обратной связью. ❓ Может моя компания оплатить курс? Да, пусть ваш HR напишет на diana@fillthegaps.ru Осталось всего 9 мест на тарифе с обратной связью. Записывайтесь: https://fillthegaps.ru/mt2

Набор на второй поток Недавно завершился первый поток курса по java многопоточке. Птенчики выпорхнули со знаниями в голове и сертификатами в клювиках. Кто-то улетел покорять собеседования, а кто-то - новые задачи на текущих проектах🦅 Курс понравился и мне, и ученикам, поэтому открываю набор на второй поток. Если вам не нужно ничего объяснять, то запись тут. ❓Почему эта тема? Технически любой крупный проект - это набор сервисов в какой-то инфраструктуре. Инфраструктуру берут на себя архитекторы и девопсы, а вот код для сервисов пишут разработчики. И там нужно решать задачи взаимодействия потоков. - Но у нас на проекте нет многопоточки! Если системой хоть кто-то пользуется, то скорее всего многопоточка скрыта под абстракциями. Задачи появятся, когда придут новые требования или нагрузка на систему возрастёт. Или когда вы перейдёте на другой проект🙂 Вторая причина, по которой я решила сделать курс - это слабое знание java.util.concurrent среди разработчиков. Это хорошо видно на собеседованиях. На стандартные вопросы все отвечают бодро, но шаг в сторону или вопрос на понимание вызывают ужас и смятение. И наоборот, если кандидат уверенно чувствует себя в многопоточке, то это большой плюс к общему впечатлению. Третья причина - нет цельных и актуальных материалов по этой теме. Большинство ограничивается рассказом про поток и экзекьюторы. Во времена java 5 это были топовые знания, но в 2021 требуется другое. Я собрала и упаковала свой опыт, лучшие практики и популярные ошибки в двухмесячный курс. Рассказываю всё как есть и простым языком. ❓Кому подойдёт? ✅ Вы знаете основы многопоточности, но понимаете, что этого недостаточно ✅ Вы хотите знать лучшие практики и основные ошибки, чтобы уверенно решать задачи ✅ Хотите проходить сложные собеседования и вписываться в интересные проекты ✅ Готовы на интенсивную работу в течение 8 недель Старт: 12 июля Длительность: 8 недель 🔸С обратной связью - 15 мест 🔸Без обратной связи - 12 мест Программа, отзывы и остальные детали тут: https://fillthegaps.ru/mt2 Записываемся💅

Mutation testing: тесты на тесты Фраза "нужны тесты на тесты" на проектах встречается часто. Звучит как шутка, но проблема за этим стоит серьёзная. Тесты есть, но насколько хорошо они тестируют приложение? Когда что-то поменяется и сломается, узнаем ли мы об этом? Нет ли ошибок в самих тестах? Чем больше проект, тем насущнее эта проблема. Test Coverage - сомнительная метрика. Высокий test coverage означает только, что в тестах участвует много кода. В этом посте я расскажу о mutation testing. В чём суть, возможные минусы и как использовать подход mutation testing уже сейчас. Идея Фреймворк делает небольшое изменение в коде и запускает тесты. Тесты упали - значит кейс проверяется. Тесты прошли - значит тестов не хватает. Пример: тестируется метод

return m > 10;

Написали для него тесты: ▫️m = 0, ожидаем false ▫️m = 100, ожидаем true Фреймворк поменяет код на m ≥ 10, и ни один тест не упадёт. Значит, текущих тестов недостаточно, нужно проверить условие m = 10 Практика Для JVM языков по факту есть только один фреймворк Pitest с двумя опциями - Gregor and Descartes. Как работает: 1️⃣ Запускает тесты и анализирует test coverage. Если код не покрыт тестами, то нет смысла мутировать его. 2️⃣ Составляет список мутаций. Здесь два варианта: 🔸 Gregor тестирует по максимуму, в том числе геттеры и сеттеры 🔸 Descartes использует меньше вариаций, но работает быстрее 3️⃣ Для каждого пункта фреймворк меняет байт-код и запускает тесты. Все изменения, для которых тесты прошли, попадают в итоговый репорт Минусы ❌ Проверяются только несложные изменения бизнес-логики ❌ Долго выполняется: от 10 минут до 6 часов. Для популярных библиотек результаты такие ❌ Сложно читать результаты и понять, каких тестов не хватает. Связано это с тем, что фреймворк работает не с исходным кодом, а с байт-кодом ❌ Gregor плохо совместим с Kotlin и проверяет конструкции, недопустимые на уровне языка. Приходится либо терпеть множество предупреждений, либо исключать некоторые проверки и рисковать бизнес-логикой. Либо использовать Descartes ❌ Слабо развивается и выглядит как pet project ❌ Непонятно как встроить в CI. Так как возможны ложноположительные результаты, репорты нужно проверять вручную. Можно оставить как необязательную опцию для самых мнительных, но проверка занимает много времени и вряд ли будет востребована Итог: идея интересная и перспективная, но слабо развивается на практике. Хозяйке на заметку Подход mutation testing подойдёт для проверки тестов сложного или критичного участка кода: ▫️Поменяйте условие ▫️Верните константу в метод ▫️Удалите тело в void методе ▫️Поменяйте методы местами ▫️Уберите инкремент ▫️Верните null ▫️Поменяйте бизнес-логику И запустите тесты. Если падают - значит код протестирован хорошо. Если нет - допишите тесты. Главное - вернуть потом изменения обратно🙂

JVM Report 2020 Израильская компания Snyk каждый год опрашивает разработчиков о проектах и технологиях. В этом году в выборке 60% участников из Европы, 19% из США, на Россию и Азию пришлось 12%. Хороший шанс посмотреть, что там у других и на картину в целом Полный отчёт доступен тут, а я расскажу самое интересное 1️⃣ Самый популярный JVM язык: Однозначно, java. Используется на 91% проектов 31% используют в проектах несколько языков. Среди них: 17% Kotlin 13% Groovy 10% Scala 8,4% Closure 2️⃣ Версия java в продакшене: 61% Java 11 59% Java 8 11% Java 15 40% опрошенных используют несколько версий 30% используют Java 8 и Java 11 3️⃣ Какая JDK используется в продакшене: 44% AdoptOpenJDK 28% Oracle OpenJDK 23% Oracle JDK 15% Azul Zulu 37% участников используют 2 JDK, а 12.5% - три и больше. 4️⃣ Как собирается приложение: 76% Maven 38% Gradle 12% Ant 5️⃣ Основной фреймворк разработки: 58% Spring Boot 29% Spring MVC 24% Java EE 13% Jakarta EE 11% Quarkus 5% Micronaut 16% не пользуются фреймворками вообще😱 6️⃣ Самая популярная IDE: 72% IDEA 24% Eclipse 23% Visual Studio Code (2% в прошлом году) 13% Apache NetBeans (1% в прошлом году) 51% ответили, что пользуются несколькими IDE По сравнению с прошлым годом Java 11 используется на 40% чаще, а IDEA и Kotlin уверенно укрепляют позиции💪

Intellij IDEA: пиши код как ниндзя Успех за быстрыми. Когда решение найдено, его нужно тут же реализовать. Поэтому скорость набора кода должна стремится к скорости мысли. Intellij IDEA помогает быстро писать код с помощью live templates и code completion. 1️⃣ Live templates Аббревиатуры для кода. Вводите 4 символа, нажимаете Enter, и они разворачиваются в 40. 🔸Простые ▫️St → String ▫️sout System.out.println(); ▫️main public static void main(String[] args){} ▫️prsf private static final 🔸Сложные Разворачиваются в методы с параметрами для автозаполнения. Перемещаться между полями можно через Tab: ▫️ fori

for (int i=0; i< ; i++) {}

▫️ifn

if (args == null) {}

▫️mx

 Math.max(, );

▫️lazy if (obj == null) { obj = new Integer(); } Полный список live templates: File/Settings/Editor/Live Templates. Есть для Java, Kotlin, JS, Groovy, для разработки под Android и React. 2️⃣ Code completion Дополнение имен на основе контекста. 🔸Начните набирать начало класса/метода: ▫️Int → Integer ▫️Cust → Customer 🔸Для классов наберите заглавные буквы: ▫️NPE → NullPointerException ▫️CHM → ConcurrentHashMap 🔸Добавьте синтаксическую конструкцию: ▫️count == 4.if

if (count == 4) {}

▫️list.for

for(Integer i : list) {}

▫️obj.opt

Optional.of(obj)

▫️answer.switch

switch (answer) {}

Полный список: File/Settings/Editor/General/Postfix Completion. Есть варианты для Java, Kotlin и JS.

Generics, часть 2: вопросики В этой части разберём wildcards, и как дженерики работают с иерархиями. Начнём с ответа на вопрос перед постом. Компилятор выдаст ошибку. Почему так? Пойдём от обратного и представим, что метод принимает List<Child>. Внутри метода мы работаем со ссылкой на List<Parent>, значит в список можно добавить объект Parent. Если метод примет List<Child>, значит List<Child> тоже принимает объекты Parent. Что противоречит контракту, поэтому List<Child> никак не связан с List<Parent>. Здесь разработчики дженериков учли неудачный опыт с массивами. Для массивов возможна такая ситуация: 🔸 Создаём переменную arr с массивом Parent:

Parent[] arr;

🔸 Присваиваем массив Child:

arr = new Child[2];

🔸 Добавляем в arr экземпляры Child и Parent:

arr[0] = new Child();
arr[1] = new Parent();

Вторая строка в рантайме бросит ArrayStoreException. Дженерики обрабатываются при компиляции, поэтому ошибок на этапе выполнения нет. Wildcards Для ситуаций, когда мы точно-точно не будем менять список, и нам только посмотреть, можно использовать wildcards: void print(List<?> list) Теперь метод принимает списки любых типов. Конкретный тип неизвестен, поэтому доступны только методы класса Object. Можно получить размер списка или вызвать для элементов toString. ❓Чем List<?> отличается от List? В List<?> компилятор не даст ничего добавить, а для List ограничений нет. ❓Как вызвать нужные методы для List<?>? Тип в списке можно уточнить:

void print(List<? extends Parent> list)

Теперь метод принимает только List<Parent> и List<Child>, плюс есть доступ к методам Parent. Но менять список всё ещё нельзя. Буквы и вопросики Есть два способа ограничить типы списков:

▫️ <T extends Parent> void test(List<T> list)
▫️ void test(List<? extends Parent> list)

Чем они отличаются? T - это конкретный тип элементов списка, поэтому в список можно добавить объекты типа Т. В листе с вопросиком конкретный тип НЕ известен, и компилятор НЕ даст добавить новые элементы. extends и super В иерархии Object - Parent - Child можно ограничить типы с разных сторон. extends - ограничение иерархии "сверху" ? extends Parent: допустимы Parent, Child и наследники Child super - ограничение типов "снизу" ? super Parent принимает Parent и родителей Parent вплоть до Object

​Какой результат выполнения этого кода?

Generics, часть 1: история и корпоративные ценности Вернёмся в 1998 год. В java 1.2 появились интерфейсы Map, Set, List и основные реализации. В те времена они хранили только объекты:

List values = new ArrayList()

Чтобы нормально работать, приходилось использовать явное приведение:

values.add("value");
String s = (String) values.get(0);

Главная проблема с коллекциями тех лет - type loss, потеря типа при компиляции и написании кода: ❌ Можно запросто получить ClassCastException ❌ Надо помнить тип объектов ❌ Ошибки возникают только в рантайме В java 5 появилась возможность указать тип через дженерики:

List<String> values = new ArrayList<String>();
values.add("p");
String v = values.get(0);

✅ Удобно пользоваться ✅ Хорошо читается ✅ Компилятор проверяет типы Как реализованы дженерики? Примерим на себя должность архитектора java и прикинем, что можно сделать с ArrayList<T>: 1️⃣ Скомпилировать в класс с типом String Все T заменяем на String:

void add(String str)
String get(int index)

В итоге создаём отдельный класс для каждого типа данных. 2️⃣ Добавить в JVM параметризованный тип <T> остаётся на уровне байт-кода и определяется для каждого объекта в рантайме. 3️⃣ Оставить на уровне JVM работу с объектами. Проверить все типы во время компиляции и привести один к другому там, где нужно. Получаем один ArrayList.class и множество дополнительных конструкций по всему коду. Для ArrayList<String> программист напишет:

String value = list.get(0)

Компилятор преобразует это в

String value = (String) list.get(0);

🤔Все варианты адекватные и имеют право на жизнь. Что же выбрать? Почти в каждом IT офисе на стенах висят слоганы и ценности компании. Что-то про качество работы, развитие сотрудников, гибкость и довольных клиентов. Из этого получается классный корпоративный мерч. Ценности нормального человека определяют стратегию и дают ориентир для решения сложных ситуаций. "Ценности" java явно нигде не определены, но направление работы задано чётко. Например, кроссплатформенность и слоган Write Once, Run Anywhere заставляют разработчиков JDK поддерживать фичи даже для древних процессоров. Бинарная совместимость - ещё один ориентир java. Поэтому для дженериков используется третий вариант: компилятор добавляет необходимые приведения типов в код и стирает информацию о дженериках. И код на java 5 теперь совместим с предыдущими версиями. Ответ на вопрос перед постом В консоли напечатаются оба значения. У списка tmp тип не задан, поэтому компилятор не мешает добавлять строки и передавать объекты в метод println. Если в println передать список intList.get(0), где тип указан явно, то мы получим ошибку компиляции.

​Какой результат выполнения этого кода?

Почему на канале так много Java Core? Потому что это база для ежедневной работы, которую хорошо знать вдоль и поперёк. Но лично мой интерес лежит в другом. Мне нравится разбирать дизайн и разбираться, почему сделано так, а не иначе. Тема этой недели - дженерики. Часть 1: посмотрим реализацию в JVM Часть 2: углубимся в wildcards и работу с подтипами