DRY для джуниора и сеньора
Раз уж пошли по базовым принципам, то сегодня разберём DRY: Don't Repeat Yourself.
Такой популярный и такой обманчиво простой.
Отношение к DRY эволюционирует по мере роста разработчика и проходит через четыре этапа:
🔸 Этап 1. Стажёр
Боготворит DRY, считает дублирование кода ужасным грехом. Действительно, зачем писать несколько раз одно и то же?
Для этого код максимально оптимизируется. Универсальные методы, универсальные статические методы, много входных параметров.
🔸 Этап 2. Джуниор
Любит DRY, но понимает, что любить — значит страдать.
Проект становится больше, а бизнес-логика — сложнее. Добавить в метод ещё один if уже не так просто. Сложно разбираться в коде, сложно писать тесты, но чего не сделаешь ради хорошего кода. А хороший код на этом этапе — это максимально сжатый код🙂
🔸 Этап 3. Мидл
Всё ещё любит DRY, но более возвышенно — на уровне иерархий и паттернов. Когда приходится дублировать код, то грустит, что на проекте плохая архитектура.
🔸 Этап 4. Сеньор
Распилил монолит на сервисы, реализовал десятки крупных фич и отдал сердце SOLID.
А теперь по делу
Часто начинающие разработчики считают, что хороший код — это суперконцентрированный код с кучей паттернов и хитрых приёмов.
В больших проектах хороший код — это тот, который легко читать, тестировать и поддерживать. Оптимизации и приёмчики - это совсем небольшая часть кодовой базы.
Если бизнес-процессы не пересекаются, то связывать их искусственно с помощью кода — плохая идея.
🙁 Класс User c 20 полями. 10 полей используются в 1 сервисе, другие 10 - в другом, половина объекта всегда пустая
🙁 Универсальный метод с 7 параметрами под разные случаи
🙁 Сложная иерархия с кучей шаблонных методов
Единственный плюс — меньше кода. Зато
❌ Плохая читаемость
❌ Сложно писать тесты
❌ Сильная связность. Функцию тяжело поменять или вынести в другой модуль
Я не говорю, что копипаст - единственный шанс на хорошую архитектуру. Переиспользовать код можно, если это действительно универсальные компоненты и та же цепочка бизнес-процессов. Но такое понимание приходит только с опытом.
Раз уж пошли по базовым принципам, то сегодня разберём DRY: Don't Repeat Yourself.
Такой популярный и такой обманчиво простой.
Отношение к DRY эволюционирует по мере роста разработчика и проходит через четыре этапа:
🔸 Этап 1. Стажёр
Боготворит DRY, считает дублирование кода ужасным грехом. Действительно, зачем писать несколько раз одно и то же?
Для этого код максимально оптимизируется. Универсальные методы, универсальные статические методы, много входных параметров.
🔸 Этап 2. Джуниор
Любит DRY, но понимает, что любить — значит страдать.
Проект становится больше, а бизнес-логика — сложнее. Добавить в метод ещё один if уже не так просто. Сложно разбираться в коде, сложно писать тесты, но чего не сделаешь ради хорошего кода. А хороший код на этом этапе — это максимально сжатый код🙂
🔸 Этап 3. Мидл
Всё ещё любит DRY, но более возвышенно — на уровне иерархий и паттернов. Когда приходится дублировать код, то грустит, что на проекте плохая архитектура.
🔸 Этап 4. Сеньор
Распилил монолит на сервисы, реализовал десятки крупных фич и отдал сердце SOLID.
А теперь по делу
Часто начинающие разработчики считают, что хороший код — это суперконцентрированный код с кучей паттернов и хитрых приёмов.
В больших проектах хороший код — это тот, который легко читать, тестировать и поддерживать. Оптимизации и приёмчики - это совсем небольшая часть кодовой базы.
Если бизнес-процессы не пересекаются, то связывать их искусственно с помощью кода — плохая идея.
🙁 Класс User c 20 полями. 10 полей используются в 1 сервисе, другие 10 - в другом, половина объекта всегда пустая
🙁 Универсальный метод с 7 параметрами под разные случаи
🙁 Сложная иерархия с кучей шаблонных методов
Единственный плюс — меньше кода. Зато
❌ Плохая читаемость
❌ Сложно писать тесты
❌ Сильная связность. Функцию тяжело поменять или вынести в другой модуль
Я не говорю, что копипаст - единственный шанс на хорошую архитектуру. Переиспользовать код можно, если это действительно универсальные компоненты и та же цепочка бизнес-процессов. Но такое понимание приходит только с опытом.
👍5
Что такое Serverless. Часть 1: предыстория
По статистике 2021 года около 10% проектов уже используют архитектуру Serverless.
Новые технологии — это классно, но важно понять, в чём вообще проблема и как она УЖЕ решается текущими средствами. И зачем решать её по-новому. Нужен чёткий ответ:
— Зачем переходить с микросервисов на Serverless? Что мы от этого получим?
Для ответа немного углубимся в историю инфраструктуры.
1️⃣ Всё своё
До 2006 года в каждой IT компании была особая комната — серверная. Системные администраторы настраивали сервера, следили за обновлениями, безопасностью, блоками питания и решали тысячу других вопросов.
❌ Много расходов на оборудование и персонал
❌ Железки надо закупать, подключать и нельзя сдать обратно. Сложно наращивать мощности или оптимизировать нагрузку
2️⃣ IasS — Infrastructure as a Service
В 2006 появился Amazon EC2 и начался тренд на IaaS: код запускается не на собственных серверах, а на арендованных.
Это самый простой вариант облачной инфраструктуры. Сейчас подобную услугу предлагают AWS, Google, DigitalOcean, Microsoft, IBM, SAP, для патриотов есть Яндекс и Сбер.
✅ Легко добавлять и сокращать ресурсы
✅ Меньше расходы на персонал
✅ Не надо беспокоиться об отключении электроэнергии и потопах
Инфраструктура всё ещё требует внимания — на арендованной виртуалке надо установить ОС, JVM, все службы и обновления, настроить компоненты и развернуть сервисы.
Большая часть этих операций почти у всех одинакова. Так что дальше расходимся на две ветки:
🅰️ PaaS — Platform as a Service
PaaS = IaaS + ОС + базовый мониторинг + легко подключаемые компоненты
Облачные провайдеры берут на себя больше рутинных операций. Выглядит как будто работаешь с удалённой машиной. Можно довольно легко добавить БД, мониторинг, кэши, очереди и связать их между собой в настройках.
Примеры PaaS: Heroku, AWS Elastic Beanstalk и тд
✅ Много готовых компонентов — можно быстро настроить работающую систему
❌ Набор компонентов большой, но всё же ограниченный. Если использовать что-то непопулярное, то придётся искать обходные пути
❌ Сильная привязка к вендору. Выбрал PaaS от амазона — скорее всего файловое хранилище, очереди и БД тоже будут амазон.
🅱️ Докер
Популярная альтернатива PaaS — докер-контейнеры в предоставленных виртуалках. В каждом контейнере свой runtime и все нужные для сервиса файлы.
Для управления контейнерами есть куча инструментов — Kubernetes, Mesos, Google Container Engine. Amazon ECR и Google CR помогают с хранением докер-образов, AWS Fargate — с масштабированием.
✅ Супер гибкость. Можно собрать любые компоненты с любыми настройками и связать их как угодно
❌ Cложно выбирать и долго настраивать
Заметили, что не было ни единого слова про архитектуру? PaaS и Docker только упрощают сборку инфраструктуры. Пока что нет разницы, что запускать внутри — гигантский монолит или сервис из трёх файлов.
В следующем посте перейдём уже к Serverless. Поговорим, почему это называется архитектурой и что ещё готовы взять на себя облачные провайдеры.
По статистике 2021 года около 10% проектов уже используют архитектуру Serverless.
Новые технологии — это классно, но важно понять, в чём вообще проблема и как она УЖЕ решается текущими средствами. И зачем решать её по-новому. Нужен чёткий ответ:
— Зачем переходить с микросервисов на Serverless? Что мы от этого получим?
Для ответа немного углубимся в историю инфраструктуры.
1️⃣ Всё своё
До 2006 года в каждой IT компании была особая комната — серверная. Системные администраторы настраивали сервера, следили за обновлениями, безопасностью, блоками питания и решали тысячу других вопросов.
❌ Много расходов на оборудование и персонал
❌ Железки надо закупать, подключать и нельзя сдать обратно. Сложно наращивать мощности или оптимизировать нагрузку
2️⃣ IasS — Infrastructure as a Service
В 2006 появился Amazon EC2 и начался тренд на IaaS: код запускается не на собственных серверах, а на арендованных.
Это самый простой вариант облачной инфраструктуры. Сейчас подобную услугу предлагают AWS, Google, DigitalOcean, Microsoft, IBM, SAP, для патриотов есть Яндекс и Сбер.
✅ Легко добавлять и сокращать ресурсы
✅ Меньше расходы на персонал
✅ Не надо беспокоиться об отключении электроэнергии и потопах
Инфраструктура всё ещё требует внимания — на арендованной виртуалке надо установить ОС, JVM, все службы и обновления, настроить компоненты и развернуть сервисы.
Большая часть этих операций почти у всех одинакова. Так что дальше расходимся на две ветки:
🅰️ PaaS — Platform as a Service
PaaS = IaaS + ОС + базовый мониторинг + легко подключаемые компоненты
Облачные провайдеры берут на себя больше рутинных операций. Выглядит как будто работаешь с удалённой машиной. Можно довольно легко добавить БД, мониторинг, кэши, очереди и связать их между собой в настройках.
Примеры PaaS: Heroku, AWS Elastic Beanstalk и тд
✅ Много готовых компонентов — можно быстро настроить работающую систему
❌ Набор компонентов большой, но всё же ограниченный. Если использовать что-то непопулярное, то придётся искать обходные пути
❌ Сильная привязка к вендору. Выбрал PaaS от амазона — скорее всего файловое хранилище, очереди и БД тоже будут амазон.
🅱️ Докер
Популярная альтернатива PaaS — докер-контейнеры в предоставленных виртуалках. В каждом контейнере свой runtime и все нужные для сервиса файлы.
Для управления контейнерами есть куча инструментов — Kubernetes, Mesos, Google Container Engine. Amazon ECR и Google CR помогают с хранением докер-образов, AWS Fargate — с масштабированием.
✅ Супер гибкость. Можно собрать любые компоненты с любыми настройками и связать их как угодно
❌ Cложно выбирать и долго настраивать
Заметили, что не было ни единого слова про архитектуру? PaaS и Docker только упрощают сборку инфраструктуры. Пока что нет разницы, что запускать внутри — гигантский монолит или сервис из трёх файлов.
В следующем посте перейдём уже к Serverless. Поговорим, почему это называется архитектурой и что ещё готовы взять на себя облачные провайдеры.
👍7
Что такое Serverless, часть 2
В прошлом посте рассмотрели, как инфраструктура понемногу переходила на аутсорс. Serverless — следующий этап такого перехода.
AWS Lambda — самая первая и популярная платформа для Serverless, поэтому дальше буду говорить про неё.
Важно! Есть ещё термин Lambda Architecture — это вообще про другое.
Итак, в чём суть.
Любое приложение — это набор функций. Допустим, в интернет-магазине три функции:
▫️ Добавить товары
▫️ Сделать заказ
▫️ Вывести список текущих заказов
Можно запихать всё в один артефакт — получится монолит. Можно каждую функцию обернуть в отдельный сервис — получатся микросервисы.
Serverless абстрагируется от этой проблемы. Мы не распределяем функциональность по артефактам и работаем просто с функциями. Проектируем не сборник фич, а отдельные маленькие компоненты.
Поэтому Serverless считается архитектурой. Или отдельной моделью проектирования, если термин "архитектура" кажется вам неподходящим.
Платформы, на которых запускаются Serverless приложения, называют FaaS — Functions as a Service.
В Петербурге Serverless используют около 10 компаний, что не очень много. Но тренд растёт, даже Сбер уже сделал свою FaaS платформу.
Как это работает?
Каждая функция состоит из:
▫️ Исполняемого кода
▫️ Списка зависимостей
▫️ Списка событий-триггеров
▫️ Конфигурации — количество памяти, необходимые права, время жизни функции и тд
Когда происходит событие из списка тригеров, FaaS платформа создаёт инстанс функции и обрабатывает его. Событием может быть HTTP запрос, сообщение из очереди, действие по расписанию. После обработки функция завершается или ждёт следующее событие в течение заданного времени.
Станет ли код проще?
Точно нет. Проектировать систему с изолированными функциями гораздо сложнее, чем слепить всё в монолит или десяток сервисов🙂
У Serverless свой деплой, тестирование и кодовая база. Даже если перенести только некоторые части приложения, общая схема заметно усложнится.
Зачем переходить на Serverless?
Если микросервисы в PaaS или докере нормально справляются, то должна быть веская причина что-то менять. Таких причин может быть две:
1️⃣ Функции развёртываются по необходимости. Облака это удобно, но иногда очень дорого. FaaS модель неплохо снижает стоимость при переменной нагрузке.
2️⃣ Масштабирование по умолчанию. В AWS Lambda автоматически масштабируются и сервисы, и остальные компоненты, например, БД. В докере и PaaS для этого нужно прилагать немало усилий.
Сколько стоит?
Допустим бэкенд мобильного приложения принимает за месяц 3 миллиона запросов, среднее время — 120мс. Выделим для одной функции 1536 МБ и процессор х86.
Плата за месяц в таком случае будет 2,7 доллара.
Это только AWS Lambda, остальные компоненты оплачиваются отдельно.
Что ещё
✅ Никаких Ansible, Docker, bash скриптов
✅ Базовый мониторинг и аналитика из коробки
✅ Spring Cloud и плагин IDEA AWS Toolkit сильно облегчают разработку
😐 Нужны отличные навыки проектирования
😐 Своеобразное тестирование
❌ Сложно адаптировать уже существующие приложения
❌ Больше задержек, response time может увеличиться
В целом Serverless — очевидный тренд, который набирает обороты. Жду в ближайшие два года тонну докладов на конференциях на эту тему, как когда-то было про микросервисы и реактивное программирование🙂
В прошлом посте рассмотрели, как инфраструктура понемногу переходила на аутсорс. Serverless — следующий этап такого перехода.
AWS Lambda — самая первая и популярная платформа для Serverless, поэтому дальше буду говорить про неё.
Важно! Есть ещё термин Lambda Architecture — это вообще про другое.
Итак, в чём суть.
Любое приложение — это набор функций. Допустим, в интернет-магазине три функции:
▫️ Добавить товары
▫️ Сделать заказ
▫️ Вывести список текущих заказов
Можно запихать всё в один артефакт — получится монолит. Можно каждую функцию обернуть в отдельный сервис — получатся микросервисы.
Serverless абстрагируется от этой проблемы. Мы не распределяем функциональность по артефактам и работаем просто с функциями. Проектируем не сборник фич, а отдельные маленькие компоненты.
Поэтому Serverless считается архитектурой. Или отдельной моделью проектирования, если термин "архитектура" кажется вам неподходящим.
Платформы, на которых запускаются Serverless приложения, называют FaaS — Functions as a Service.
В Петербурге Serverless используют около 10 компаний, что не очень много. Но тренд растёт, даже Сбер уже сделал свою FaaS платформу.
Как это работает?
Каждая функция состоит из:
▫️ Исполняемого кода
▫️ Списка зависимостей
▫️ Списка событий-триггеров
▫️ Конфигурации — количество памяти, необходимые права, время жизни функции и тд
Когда происходит событие из списка тригеров, FaaS платформа создаёт инстанс функции и обрабатывает его. Событием может быть HTTP запрос, сообщение из очереди, действие по расписанию. После обработки функция завершается или ждёт следующее событие в течение заданного времени.
Станет ли код проще?
Точно нет. Проектировать систему с изолированными функциями гораздо сложнее, чем слепить всё в монолит или десяток сервисов🙂
У Serverless свой деплой, тестирование и кодовая база. Даже если перенести только некоторые части приложения, общая схема заметно усложнится.
Зачем переходить на Serverless?
Если микросервисы в PaaS или докере нормально справляются, то должна быть веская причина что-то менять. Таких причин может быть две:
1️⃣ Функции развёртываются по необходимости. Облака это удобно, но иногда очень дорого. FaaS модель неплохо снижает стоимость при переменной нагрузке.
2️⃣ Масштабирование по умолчанию. В AWS Lambda автоматически масштабируются и сервисы, и остальные компоненты, например, БД. В докере и PaaS для этого нужно прилагать немало усилий.
Сколько стоит?
Допустим бэкенд мобильного приложения принимает за месяц 3 миллиона запросов, среднее время — 120мс. Выделим для одной функции 1536 МБ и процессор х86.
Плата за месяц в таком случае будет 2,7 доллара.
Это только AWS Lambda, остальные компоненты оплачиваются отдельно.
Что ещё
✅ Никаких Ansible, Docker, bash скриптов
✅ Базовый мониторинг и аналитика из коробки
✅ Spring Cloud и плагин IDEA AWS Toolkit сильно облегчают разработку
😐 Нужны отличные навыки проектирования
😐 Своеобразное тестирование
❌ Сложно адаптировать уже существующие приложения
❌ Больше задержек, response time может увеличиться
В целом Serverless — очевидный тренд, который набирает обороты. Жду в ближайшие два года тонну докладов на конференциях на эту тему, как когда-то было про микросервисы и реактивное программирование🙂
👍10
Enum и метод values
Если вы новичок и мало знаете про enum, то лучше начать с этого лонгрида. Сегодня обсудим итерацию через метод values и как его оптимизировать.
Итак, enums — это синтаксический сахар, который при компиляции превращается в обычный класс. Класс из примера выше превратится в
Если цикл с values используется в высоконагруженном коде, то разумно сохранить массив в отдельную переменную и переиспользовать её:
Пример из жизни
В Spring Web 5.2 в классе HttpStatus есть такой код:
Теперь код выглядит так:
Будет создано 3 массива: один внутри класса Number и два клона при вызове values()
Если вы новичок и мало знаете про enum, то лучше начать с этого лонгрида. Сегодня обсудим итерацию через метод values и как его оптимизировать.
Итак, enums — это синтаксический сахар, который при компиляции превращается в обычный класс. Класс из примера выше превратится в
public final class Number extends Enum<Number
>
Элементы енума станут статическими полями:public static final Number ONE;Внутри нового класса появится массив:
public static final Number TWO;
public static final Number THREE;
Number[] VALUES = { ONE, TWO, THREE};
И его копия будет возвращаться в методе values:return VALUES.clone();При каждом вызове values возвращается новая копия массива. Дело в том, что массивы — это изменяемый объект. Если возвращать ссылку на VALUES напрямую, любой желающий сможет поменять исходный массив:
Number.values()[2] = ONE;Это небезопасно, поэтому каждый раз возвращается копия.
Если цикл с values используется в высоконагруженном коде, то разумно сохранить массив в отдельную переменную и переиспользовать её:
static Number[] numbers = Number.values();Если код вызывается редко, то смысла в отдельной переменной нет.
for (Number n : numbers) {…}
Пример из жизни
В Spring Web 5.2 в классе HttpStatus есть такой код:
for (HttpStatus status : values()) {
if (status.value == statusCode) {
return status;
}
}
Этот цикл вызывается почти в каждом запросе, но только в этом году завели баг. К описанию прилагался бенчмарк: при нагрузке 600 запросов/сек код производил мегабайт мусора каждую секунду.Теперь код выглядит так:
private static final HttpStatus[] VALUES;Ответ на вопрос перед постом
static {
VALUES = values();
}
for (HttpStatus status : VALUES) {
if (status.value == statusCode) {
return status;
}
}
Будет создано 3 массива: один внутри класса Number и два клона при вызове values()
👍10
Потихоньку появляются доклады с Joker 2021. Конференции - это классно, но часто бывает, что:
▪️ Название доклада не отражает содержание
▪️ Тема интересная, но слушать тяжело
▪️ Доклад слишком простой или слишком сложный
Поделюсь с вами summary двух самых популярных докладов с последнего джокера.
Выделила основные идеи, полезные детали и сгруппировала всё, что получилось. Если тема заинтересует — посмотрите целиком. Если нет — сэкономите 2 часа жизни🙂
P.S. Все вопросы по содержанию не ко мне, а к спикерам
▪️ Название доклада не отражает содержание
▪️ Тема интересная, но слушать тяжело
▪️ Доклад слишком простой или слишком сложный
Поделюсь с вами summary двух самых популярных докладов с последнего джокера.
Выделила основные идеи, полезные детали и сгруппировала всё, что получилось. Если тема заинтересует — посмотрите целиком. Если нет — сэкономите 2 часа жизни🙂
P.S. Все вопросы по содержанию не ко мне, а к спикерам
👍2
Два доклада с Joker 2021
1️⃣ Алексей Нестеров, Олег Докука — Что нового в Spring Framework 6 (1:10:58)
Оба спикера никак не связаны со спрингом, просто обсуждают слухи о нововведениях.
Spring 6 использует java 17 и не будет работать на версиях ниже.
Дата выхода - октябрь 2022.
Кодовая база Spring 6 использует модули (фича java 9). Можно скомпилировать только нужные модули, и итоговый проект займёт меньше места.
Spring Native переедет в Spring Boot 3.
Spring будет связывать некоторые бины на этапе сборки, а не в рантайме. Это ускорит запуск приложений и потребление памяти.
Поменяются имена некоторых модулей. Например, пакет javax.* станет jakarta.*
В Spring WebFlux добавится поддержка HTTPClient из JDK 11.
Что удалится: Hessian, Http Invoker, JMS Invoker, JAX-WS, SecurityManager.
Что удалится, но менее вероятно: поддержка Joda Time, RxJava 1/2, FactoryBean, Autowired через сеттеры, конфигурация через XML.
Зачем смотреть: незачем. Информация недостоверная, много догадок, мало деталей.
2️⃣ Иван Крылов — От 11 к 17 версии Java (55:07)
Это доклад НЕ про новые фичи языка. Про sealed классы, records и switch спикер отсылает на доклад Тагира Валеева Java 17 для тех, кто в танке.
Два подхода к обновлению версии java в проекте:
1) Каждые полгода переходить на новую версию
Вариант подойдёт для проектов, где релизы происходят часто — каждый месяц или два. Или жизненный цикл проекта — это основной релиз и поддержка нескольких следующих релизов.
Плюс — всегда новая и поддерживаемая версия java
Минус — раз в полгода тратить несколько спринтов на переход
2) Переходить только на LTS версию
Встречается в проектах с редкими релизами — реже, чем раз в полгода.
Минус — переход всегда долгий и трудный, оттягивается до последнего.
Переезд на java 17 — это необходимость. Дело не в новых фичах, а в том, что поддержка старых версий ограничена и периодически прекращается. Миграция с 8 до 17 сложная, с 11 до 17 попроще.
С чем могут быть проблемы при переходе
▫️ Удалены финалайзеры из FileOutputStream, FileInputStream, zip.Deflater, zip.Inflater, zip.ZipFile, color.ICC_Profile. Это связано с предстоящим удалением финалайзеров в java 18.
▫️ Удалён конструктор URLDecoder.
▫️ Многие классы в AWT и Swing поменяли видимость.
▫️ Удалён Applet API.
Изменения виртуальной машины
▪️ GraalVM больше не связан с OpenJDK. Причина — административные проблемы и сложности с версионированием относительно OpenJDK.
▪️ Удалена оптимизация biased locking из-за плохой совместимости с Project Loom.
▪️ Добавлены CDS архивы для уменьшения времени старта VM.
▪️ Гибкий metaspace.
Изменения в сборщиках мусора
▫️ Удалён CMS.
▫️ ZGC готов к использованию в продакшене с 15 версии, в ранних версиях очень много багов.
▫️ G1 и Shenandoah возвращают неиспользуемую память ОС. Это уменьшает потребляемую память сервиса, и сервисы в облачной среде обойдутся дешевле.
Изменения в JDK
▪️ Классы по работе с TCP и UDP работают быстрее — DatagramSocketAPI, SocketAPI.
▪️ NullPointerException показывают больше информации.
▪️ Новый генератор случайных чисел.
Изменения Security
▫️ Добавлены Root сертификаты с разным сроком действия
▫️ Удалён SecurityManager
▫️ Удалены модули java.security, java.rmi.activation
Платформы
▪️ Добавилась поддержка Linux Alpine. ОС полезна для маленьких контейнеров в облаках. В ОС меньше команд, поэтому она более безопасна. Если маленькие контейнеры не нужны, то лучше выбрать другую ОС.
▪️ Полная поддержка ARM: унифицированный Linux порт, Windows, macOS
Какие проекты не успели войти в java 17
▫️ Loom: легковесные потоки в JVM
▫️ Panama: работа с нативным кодом, альтернатива JNI
▫️ Valhalla: новые типы данных value types — функциональные как классы и компактные как примитивы
Зачем смотреть: незачем. Большую часть видео перечисляются неязыковые фичи между 11 и 17 версией. О них говорят редко, так что для кого-то информация окажется новой. Но с тем же успехом можно посмотреть полный список фич и поискать слова, которые актуальны для вашего проекта или интересны лично вам.
1️⃣ Алексей Нестеров, Олег Докука — Что нового в Spring Framework 6 (1:10:58)
Оба спикера никак не связаны со спрингом, просто обсуждают слухи о нововведениях.
Spring 6 использует java 17 и не будет работать на версиях ниже.
Дата выхода - октябрь 2022.
Кодовая база Spring 6 использует модули (фича java 9). Можно скомпилировать только нужные модули, и итоговый проект займёт меньше места.
Spring Native переедет в Spring Boot 3.
Spring будет связывать некоторые бины на этапе сборки, а не в рантайме. Это ускорит запуск приложений и потребление памяти.
Поменяются имена некоторых модулей. Например, пакет javax.* станет jakarta.*
В Spring WebFlux добавится поддержка HTTPClient из JDK 11.
Что удалится: Hessian, Http Invoker, JMS Invoker, JAX-WS, SecurityManager.
Что удалится, но менее вероятно: поддержка Joda Time, RxJava 1/2, FactoryBean, Autowired через сеттеры, конфигурация через XML.
Зачем смотреть: незачем. Информация недостоверная, много догадок, мало деталей.
2️⃣ Иван Крылов — От 11 к 17 версии Java (55:07)
Это доклад НЕ про новые фичи языка. Про sealed классы, records и switch спикер отсылает на доклад Тагира Валеева Java 17 для тех, кто в танке.
Два подхода к обновлению версии java в проекте:
1) Каждые полгода переходить на новую версию
Вариант подойдёт для проектов, где релизы происходят часто — каждый месяц или два. Или жизненный цикл проекта — это основной релиз и поддержка нескольких следующих релизов.
Плюс — всегда новая и поддерживаемая версия java
Минус — раз в полгода тратить несколько спринтов на переход
2) Переходить только на LTS версию
Встречается в проектах с редкими релизами — реже, чем раз в полгода.
Минус — переход всегда долгий и трудный, оттягивается до последнего.
Переезд на java 17 — это необходимость. Дело не в новых фичах, а в том, что поддержка старых версий ограничена и периодически прекращается. Миграция с 8 до 17 сложная, с 11 до 17 попроще.
С чем могут быть проблемы при переходе
▫️ Удалены финалайзеры из FileOutputStream, FileInputStream, zip.Deflater, zip.Inflater, zip.ZipFile, color.ICC_Profile. Это связано с предстоящим удалением финалайзеров в java 18.
▫️ Удалён конструктор URLDecoder.
▫️ Многие классы в AWT и Swing поменяли видимость.
▫️ Удалён Applet API.
Изменения виртуальной машины
▪️ GraalVM больше не связан с OpenJDK. Причина — административные проблемы и сложности с версионированием относительно OpenJDK.
▪️ Удалена оптимизация biased locking из-за плохой совместимости с Project Loom.
▪️ Добавлены CDS архивы для уменьшения времени старта VM.
▪️ Гибкий metaspace.
Изменения в сборщиках мусора
▫️ Удалён CMS.
▫️ ZGC готов к использованию в продакшене с 15 версии, в ранних версиях очень много багов.
▫️ G1 и Shenandoah возвращают неиспользуемую память ОС. Это уменьшает потребляемую память сервиса, и сервисы в облачной среде обойдутся дешевле.
Изменения в JDK
▪️ Классы по работе с TCP и UDP работают быстрее — DatagramSocketAPI, SocketAPI.
▪️ NullPointerException показывают больше информации.
▪️ Новый генератор случайных чисел.
Изменения Security
▫️ Добавлены Root сертификаты с разным сроком действия
▫️ Удалён SecurityManager
▫️ Удалены модули java.security, java.rmi.activation
Платформы
▪️ Добавилась поддержка Linux Alpine. ОС полезна для маленьких контейнеров в облаках. В ОС меньше команд, поэтому она более безопасна. Если маленькие контейнеры не нужны, то лучше выбрать другую ОС.
▪️ Полная поддержка ARM: унифицированный Linux порт, Windows, macOS
Какие проекты не успели войти в java 17
▫️ Loom: легковесные потоки в JVM
▫️ Panama: работа с нативным кодом, альтернатива JNI
▫️ Valhalla: новые типы данных value types — функциональные как классы и компактные как примитивы
Зачем смотреть: незачем. Большую часть видео перечисляются неязыковые фичи между 11 и 17 версией. О них говорят редко, так что для кого-то информация окажется новой. Но с тем же успехом можно посмотреть полный список фич и поискать слова, которые актуальны для вашего проекта или интересны лично вам.
👍3
State of spring 2021
Поделюсь статистикой State of spring 2021 от VMWare. Данные релевантны для энтерпрайзных проектов из Европы и США.
Сама статистика довольно скучная, поэтому дам небольшое овервью по некоторым модулям.
🔸 79% используют Spring Security в рабочих проектах
🔸 79% Spring Data
Простые интерфейсы для работы с данными из разных БД. Обычно используется в связке с:
▫️ 78% JPA
▫️ 74% JDBC
▫️ 46% MongoDB
▫️ 37% Redis
▫️ 31% ElasticSearch
🔸 73% WebMVC
🔸 61% Boot
🔸 39% Kafka
🔸 38% Batch — фоновая обработка большого количества данных
🔸 37% Cloud
Не смотрите на название, модуль используется не только в облачной инфраструктуре.
Берёт на себя типовые задачи в микросервисной архитектуре:
▫️ Service Discovery — получить адрес другого сервиса
▫️ Добавить в логи информацию про конкретный сервис
🔸 35% WebFlux — поддержка реактивных библиотек
🔸 32% Integration
Ещё один уровень абстракции и набор готовых компонентов, которые соединяются через Enterprise Integration Patterns. Через конфигурацию можно описать несложную логику вроде "прочитай XML, преврати в JSON, отправь по HTTP".
🔸 3% Native
Компиляция и запуск на GraalVM. Уменьшает время старта и потребление памяти, хорошо работает с контейнерами.
Большинство опрошенных в восторге от Native, но пока не торопятся внедрять в рабочий проект. Потому что Native пока в стадии бета и GraalVM слишком незрелая технология. Но 65% планируют использовать Native в будущем.
Поделюсь статистикой State of spring 2021 от VMWare. Данные релевантны для энтерпрайзных проектов из Европы и США.
Сама статистика довольно скучная, поэтому дам небольшое овервью по некоторым модулям.
🔸 79% используют Spring Security в рабочих проектах
🔸 79% Spring Data
Простые интерфейсы для работы с данными из разных БД. Обычно используется в связке с:
▫️ 78% JPA
▫️ 74% JDBC
▫️ 46% MongoDB
▫️ 37% Redis
▫️ 31% ElasticSearch
🔸 73% WebMVC
🔸 61% Boot
🔸 39% Kafka
🔸 38% Batch — фоновая обработка большого количества данных
🔸 37% Cloud
Не смотрите на название, модуль используется не только в облачной инфраструктуре.
Берёт на себя типовые задачи в микросервисной архитектуре:
▫️ Service Discovery — получить адрес другого сервиса
▫️ Добавить в логи информацию про конкретный сервис
🔸 35% WebFlux — поддержка реактивных библиотек
🔸 32% Integration
Ещё один уровень абстракции и набор готовых компонентов, которые соединяются через Enterprise Integration Patterns. Через конфигурацию можно описать несложную логику вроде "прочитай XML, преврати в JSON, отправь по HTTP".
🔸 3% Native
Компиляция и запуск на GraalVM. Уменьшает время старта и потребление памяти, хорошо работает с контейнерами.
Большинство опрошенных в восторге от Native, но пока не торопятся внедрять в рабочий проект. Потому что Native пока в стадии бета и GraalVM слишком незрелая технология. Но 65% планируют использовать Native в будущем.
👍4❤1
Ну что, какие планы на эту неделю?
Anonymous Poll
43%
Работать как обычно 🧑🏻💻
19%
Закрывать простые задачки
5%
Шутить в рабочих чатах
33%
Отдыхать и не думать о работе🎄
Мой вариант — последний😊 Чищу мандаринки, смотрю статистику канала и радуюсь.
Спасибо, что читаете нудные посты без картинок, помогаете найти ошибки и задаёте интересные вопросы. Благодаря вам канал живёт и развивается!
Продолжим этот движ в 2022🚀
Спасибо, что читаете нудные посты без картинок, помогаете найти ошибки и задаёте интересные вопросы. Благодаря вам канал живёт и развивается!
Продолжим этот движ в 2022🚀
❤31👍1
Гороскоп на 2022
Хороший год начинается с астрологического прогноза.
Если ваши спринты по две недели (половина лунного цикла), а сервисы развёртываются в облаках, то этот небесный прогноз для вас.
♈️ Овен (21 марта — 20 апреля)
В этом году возможен большой шаг в карьере, но он не будет простым. Откажитесь от лишней эмоциональности и просто идите в выбранном направлении. Посмотрите книгу Программист-прагматик, там для вас есть дельный совет.
♉️ Телец (21 апреля — 20 мая)
Год будет богат на свежие идеи и начинания. Начните то, что давно откладывали, расширяйте кругозор и пробуйте новое. Обязательно делайте бэкапы и резервные копии.
Поездите по России, вам понравится. Петербург, Краснодар, Кисловодск, Байкал, Алтай, Кавказ🧡
Во второй половине года порадуйте себя новой техникой.
♊️ Близнецы (21 мая — 21 июня)
В этом году сделайте упор на soft skills. Навыки переговоров, управления и тайм-менеджмента ускорят ваше продвижение вперёд. Сентябрь станет самым прибыльным месяцем в году.
Первая половина года подкинет отличную карьерную возможность, не упустите её.
♋️ Рак (22 июня — 22 июля)
Лучшее время для решительных шагов — начало весны. Много возможностей принесёт нетворкинг — поддерживайте тёплые отношения с коллегами, участвуйте в конференциях, митапах и корпоративных мероприятиях. Если ещё не смотрели в сторону Kotlin, самое время это сделать.
♌️ Лев (23 июля — 23 августа)
Год будет спокойным и приятным. В прошлом году вы много работали, в 2022 выделяйте больше времени на отдых. Качество жизни и работы только улучшится. Отличное время для серьёзного обучения — начните какую-нибудь большую книгу или впишитесь в долгие курсы.
Ложитесь спать пораньше, на выходных не заглядывайте в рабочие чаты.
♍️ Дева (24 августа — 22 сентября)
В этом году вы будете на переднем фронте. Вас ждут горячие фиксы и спасение команды перед дедлайном. Будет сложно, но Юпитер вам поможет. Помните об отдыхе и набирайтесь сил в спокойное время.
Зимой возможны серьёзные ошибки в коде или конфигурации, уделите больше времени самопроверке и написанию тестов.
♎️ Весы (23 сентября — 23 октября)
Водный тигр симпатизирует вам, поэтому все инициативы будут удачны, особенно весной и летом. Будьте активны на ретро, предлагайте новые фичи и подходы, возьмите под наставничество стажёров.
Никогда ничего не бойтесь, живите здесь и сейчас
♏️ Скорпион (24 октября — 22 ноября)
В этом году Скорпионам достанутся важные и сложные задачи. Карьерный рост будет спокойным и уверенным — десятки маленьких шагов в течение года выведут вас на новый уровень.
Уделяйте больше времени спорту и друзьям, прокачивайте английский.
Если вы сеньор — углубите навыки System design.
♐️ Стрелец (23 ноября — 21 декабря)
Наступает период, когда пора применить все накопленные знания. А возможности для этого обязательно будут. Юпитер будет мешать делать важные задачи в срок, поэтому закладывайте на выполнение в 2 раза больше времени.
При первой же возможности езжайте в заграничные путешествия.
♑️ Козерог (22 декабря — 19 января)
Год будет положительным и стабильным. Если у вас есть какая-то тактика, придерживайтесь её. Если нет — составьте план развития на год. Подтяните тайм-менеджмент, иначе времени на хобби и внерабочие активности совсем не останется.
♒️ Водолей (20 января — 18 февраля)
В год Тигра Водолеи нацелены на быстрый карьерный взлёт. Подтяните пробелы и обсудите с тимлидом возможности роста. Посмотрите вакансии, походите по собеседованиям. Вам нужна правильная почва для роста.
Уделите больше внимания облачным технологиям.
♓️ Рыбы (19 февраля — 20 марта)
В этом году удача не на вашей стороне, придётся много работать. Хотите успеха — начните сейчас, чтобы уже весной видеть первые результаты. Больше общайтесь с коллегами на неформальные темы, они отличные ребята В марте высокий риск простудиться, одевайтесь теплее.
PS Я включила реакции, и спектр эмоций теперь шире. Но кнопку внизу пока оставила:)
Хороший год начинается с астрологического прогноза.
Если ваши спринты по две недели (половина лунного цикла), а сервисы развёртываются в облаках, то этот небесный прогноз для вас.
♈️ Овен (21 марта — 20 апреля)
В этом году возможен большой шаг в карьере, но он не будет простым. Откажитесь от лишней эмоциональности и просто идите в выбранном направлении. Посмотрите книгу Программист-прагматик, там для вас есть дельный совет.
♉️ Телец (21 апреля — 20 мая)
Год будет богат на свежие идеи и начинания. Начните то, что давно откладывали, расширяйте кругозор и пробуйте новое. Обязательно делайте бэкапы и резервные копии.
Поездите по России, вам понравится. Петербург, Краснодар, Кисловодск, Байкал, Алтай, Кавказ🧡
Во второй половине года порадуйте себя новой техникой.
♊️ Близнецы (21 мая — 21 июня)
В этом году сделайте упор на soft skills. Навыки переговоров, управления и тайм-менеджмента ускорят ваше продвижение вперёд. Сентябрь станет самым прибыльным месяцем в году.
Первая половина года подкинет отличную карьерную возможность, не упустите её.
♋️ Рак (22 июня — 22 июля)
Лучшее время для решительных шагов — начало весны. Много возможностей принесёт нетворкинг — поддерживайте тёплые отношения с коллегами, участвуйте в конференциях, митапах и корпоративных мероприятиях. Если ещё не смотрели в сторону Kotlin, самое время это сделать.
♌️ Лев (23 июля — 23 августа)
Год будет спокойным и приятным. В прошлом году вы много работали, в 2022 выделяйте больше времени на отдых. Качество жизни и работы только улучшится. Отличное время для серьёзного обучения — начните какую-нибудь большую книгу или впишитесь в долгие курсы.
Ложитесь спать пораньше, на выходных не заглядывайте в рабочие чаты.
♍️ Дева (24 августа — 22 сентября)
В этом году вы будете на переднем фронте. Вас ждут горячие фиксы и спасение команды перед дедлайном. Будет сложно, но Юпитер вам поможет. Помните об отдыхе и набирайтесь сил в спокойное время.
Зимой возможны серьёзные ошибки в коде или конфигурации, уделите больше времени самопроверке и написанию тестов.
♎️ Весы (23 сентября — 23 октября)
Водный тигр симпатизирует вам, поэтому все инициативы будут удачны, особенно весной и летом. Будьте активны на ретро, предлагайте новые фичи и подходы, возьмите под наставничество стажёров.
Никогда ничего не бойтесь, живите здесь и сейчас
♏️ Скорпион (24 октября — 22 ноября)
В этом году Скорпионам достанутся важные и сложные задачи. Карьерный рост будет спокойным и уверенным — десятки маленьких шагов в течение года выведут вас на новый уровень.
Уделяйте больше времени спорту и друзьям, прокачивайте английский.
Если вы сеньор — углубите навыки System design.
♐️ Стрелец (23 ноября — 21 декабря)
Наступает период, когда пора применить все накопленные знания. А возможности для этого обязательно будут. Юпитер будет мешать делать важные задачи в срок, поэтому закладывайте на выполнение в 2 раза больше времени.
При первой же возможности езжайте в заграничные путешествия.
♑️ Козерог (22 декабря — 19 января)
Год будет положительным и стабильным. Если у вас есть какая-то тактика, придерживайтесь её. Если нет — составьте план развития на год. Подтяните тайм-менеджмент, иначе времени на хобби и внерабочие активности совсем не останется.
♒️ Водолей (20 января — 18 февраля)
В год Тигра Водолеи нацелены на быстрый карьерный взлёт. Подтяните пробелы и обсудите с тимлидом возможности роста. Посмотрите вакансии, походите по собеседованиям. Вам нужна правильная почва для роста.
Уделите больше внимания облачным технологиям.
♓️ Рыбы (19 февраля — 20 марта)
В этом году удача не на вашей стороне, придётся много работать. Хотите успеха — начните сейчас, чтобы уже весной видеть первые результаты. Больше общайтесь с коллегами на неформальные темы, они отличные ребята В марте высокий риск простудиться, одевайтесь теплее.
PS Я включила реакции, и спектр эмоций теперь шире. Но кнопку внизу пока оставила:)
👎89👍54🔥20
Сколько лет вы пишете на java?
Anonymous Poll
23%
Меньше года
32%
1-2 года
27%
3-5 лет
19%
Больше 5 лет
Как давно вы читаете канал?
Anonymous Poll
27%
Меньше 3х месяцев 🚀
45%
От 3х месяцев до года 👨💻
28%
Больше года ❤️
👍7
Привет!
Каждый автор пишет о том, что ему интересно, и что больше откликается у аудитории. Я в основном пишу про java core, но хочется писать и на другие темы.
Поэтому хочу узнать про вас чуть больше. Ответьте, пожалуйста, на 2 вопроса выше ⬆️
А если уделите ещё 5 минут и ответите на эту анкету, то сильно мне поможете и напрямую повлияете на будущий контент.
Каждый автор пишет о том, что ему интересно, и что больше откликается у аудитории. Я в основном пишу про java core, но хочется писать и на другие темы.
Поэтому хочу узнать про вас чуть больше. Ответьте, пожалуйста, на 2 вопроса выше ⬆️
А если уделите ещё 5 минут и ответите на эту анкету, то сильно мне поможете и напрямую повлияете на будущий контент.
👍49❤13
Первым делом хочу поблагодарить всех, кто ответил на анкету и особенно на последний вопрос. Было много приятных пожеланий и интересных идей! Спасибо🥰
Ну а теперь к делу ⬇️
Ну а теперь к делу ⬇️
Как написать hashcode лучше, чем IDE
Метод hashcode используется, когда класс работает в качестве ключа в hash-based структурах данных. Следить за тем, как используется класс, не всегда удобно, поэтому есть правило — "Переопределяешь equals — переопредели hashcode".
Метод должен соблюдать контракт:
⭐️ Если объект не меняется, хэшкод остаётся постоянным
⭐️ У одинаковых объектов одинаковый хэшкод
⭐️ Если хэшкод одинаковый, то объекты не обязательно равны
Писать equals и hashcode вручную долго, поэтому часто используется автогенерация в IDE или Lombok аннотация
Контракт соблюдается, но суть хэшкода пропадает.
Хэшкод — это быстрая проверка без лишних вычислений. В коде выше результат вычисляется каждый раз на основе множества полей. А по количеству операций
Как считать хэш быстрее:
1️⃣ Использовать одно поле
Подойдёт если у объекта нет id, и основные поля не меняются. Так сделано в классе
Метод hashcode используется, когда класс работает в качестве ключа в hash-based структурах данных. Следить за тем, как используется класс, не всегда удобно, поэтому есть правило — "Переопределяешь equals — переопредели hashcode".
Метод должен соблюдать контракт:
⭐️ Если объект не меняется, хэшкод остаётся постоянным
⭐️ У одинаковых объектов одинаковый хэшкод
⭐️ Если хэшкод одинаковый, то объекты не обязательно равны
Писать equals и hashcode вручную долго, поэтому часто используется автогенерация в IDE или Lombok аннотация
@EqualsAndHashCode. Они создают что-то вродеpublic int hashcode() {
return Objects.hash(id, param1, param2);
}
Что не так?Контракт соблюдается, но суть хэшкода пропадает.
Хэшкод — это быстрая проверка без лишних вычислений. В коде выше результат вычисляется каждый раз на основе множества полей. А по количеству операций
Objects.hashcode догоняет equals. Как считать хэш быстрее:
1️⃣ Использовать одно поле
public int hashcode() {
return id;
}
2️⃣ Сохранять результат в отдельном полеПодойдёт если у объекта нет id, и основные поля не меняются. Так сделано в классе
String:private int hash;Эффект от оптимизации будет заметен, если класс активно участвует в hash-based структурах. В остальных случаях можно оставить автогенерацию.
public int hashCode() {
int h = hash;
if (h==0 && !hashIsZero){
hash = …;
}
return h;
}
👍53🔥12❤7
Intellij IDEA: создать и переместить строку
Как создают строчку обычные люди: долго переводят курсор в конец строки и жмут
В IDEA достаточно нажать
Быстро перемещать строки:
Очень простые и приятные фичи🙂
Как создают строчку обычные люди: долго переводят курсор в конец строки и жмут
Enter. В IDEA достаточно нажать
Shift + EnterИ вы сразу перейдёте на новую строчку
Быстро перемещать строки:
Shift + Alt + (стрелка вверх/вниз)Если выделить несколько строк, то группа будет двигаться целиком.
Очень простые и приятные фичи🙂
👍127❤17🔥12👎2
Зачем спрашивать про хэшмэп
Меня раньше раздражали многие вопросы с собеседований:
▫️ Перечислить методы класса
▫️ Расшифровать SOLID
▫️ Вставить элемент в сбалансированное дерево
Задают везде по сто раз, они мало связаны с ежедневной работой и вообще неинтересные.
С годами отношение поменялось. Представьте, вам нужно нанять человека в команду для несложных (на ваш взгляд) задач. Вы и парочка сеньоров будете направлять его и подстраховывать.
Что ожидается от джуниора и мидла:
▫️ Hard skills: уметь писать на java, знать основные структуры данных, паттерны и фреймворки
▫️ Soft skills: быть приятным в общении, чётко формулировать мысли и возможные проблемы
Хард скиллс более-менее проверяется тестами и конкретными вопросами. Но никто не назовёт себя раздражительным, поэтому софт скиллс проверяются косвенно.
Интервьюер: расскажите устройство HashMap
👦🏽 Кандидат 1: закатывает глаза и вздыхает. Ну там хэши, бакеты, я это уже сто раз рассказывал на другом собесе, давайте дальше
🧔Кандидат 2: чётко и понятно отвечает на вопрос
👨🏻 Кандидат 3: чётко и понятно отвечает на вопрос, упоминает изменения в java 8, готов обсудить ConcurrentHashMap и его эволюцию
Понятно, что Кандидат 2 — отличный парень, Кандидат 3 — вообще лапочка. И по хард скиллам хорошо, и работать с ним будет приятно.
❓ Означают ли стандартные вопросы, что проект скучный?
Мне кажется, корреляция между собеседованием и дальнейшей работой довольно низкая. Бывало, что собеседование долгое и тщательное, а проект так себе. И наоборот — вопросы простейшие, а проект — конфетка. В любом случае нужно спрашивать, что происходит в проекте, какие там технологии, задачи и перспективы.
❓ Что делать, если вопросы на интервью стандартные, но хочется показать себя во всей красе?
Хорошо отвечайте на эти стандартные вопросы. Если на интервью видно ваш крепкий фундамент, значит вы без труда подстроитесь под любой стек и любые специфичные задачи.
Плюс всегда есть момент, чтобы ввернуть ваши интересы или достижения. Как минимум указать в резюме и кратко описать в первой части интервью.
❓ Что проверяют у сеньора, когда задают вопрос про HashMap?
Сеньор не только пишет классный код, но и помогает младшим товарищам. Джуниорам и мидлам придётся часто повторять одно и то же, понятно и доброжелательно. Так что вопрос про хэшмэп вполне подойдёт. Хард скиллы проверяются, конечно, другими вопросами.
Меня раньше раздражали многие вопросы с собеседований:
▫️ Перечислить методы класса
Object
▫️ Рассказать строение HashMap и списков▫️ Расшифровать SOLID
▫️ Вставить элемент в сбалансированное дерево
Задают везде по сто раз, они мало связаны с ежедневной работой и вообще неинтересные.
С годами отношение поменялось. Представьте, вам нужно нанять человека в команду для несложных (на ваш взгляд) задач. Вы и парочка сеньоров будете направлять его и подстраховывать.
Что ожидается от джуниора и мидла:
▫️ Hard skills: уметь писать на java, знать основные структуры данных, паттерны и фреймворки
▫️ Soft skills: быть приятным в общении, чётко формулировать мысли и возможные проблемы
Хард скиллс более-менее проверяется тестами и конкретными вопросами. Но никто не назовёт себя раздражительным, поэтому софт скиллс проверяются косвенно.
Интервьюер: расскажите устройство HashMap
👦🏽 Кандидат 1: закатывает глаза и вздыхает. Ну там хэши, бакеты, я это уже сто раз рассказывал на другом собесе, давайте дальше
🧔Кандидат 2: чётко и понятно отвечает на вопрос
👨🏻 Кандидат 3: чётко и понятно отвечает на вопрос, упоминает изменения в java 8, готов обсудить ConcurrentHashMap и его эволюцию
Понятно, что Кандидат 2 — отличный парень, Кандидат 3 — вообще лапочка. И по хард скиллам хорошо, и работать с ним будет приятно.
❓ Означают ли стандартные вопросы, что проект скучный?
Мне кажется, корреляция между собеседованием и дальнейшей работой довольно низкая. Бывало, что собеседование долгое и тщательное, а проект так себе. И наоборот — вопросы простейшие, а проект — конфетка. В любом случае нужно спрашивать, что происходит в проекте, какие там технологии, задачи и перспективы.
❓ Что делать, если вопросы на интервью стандартные, но хочется показать себя во всей красе?
Хорошо отвечайте на эти стандартные вопросы. Если на интервью видно ваш крепкий фундамент, значит вы без труда подстроитесь под любой стек и любые специфичные задачи.
Плюс всегда есть момент, чтобы ввернуть ваши интересы или достижения. Как минимум указать в резюме и кратко описать в первой части интервью.
❓ Что проверяют у сеньора, когда задают вопрос про HashMap?
Сеньор не только пишет классный код, но и помогает младшим товарищам. Джуниорам и мидлам придётся часто повторять одно и то же, понятно и доброжелательно. Так что вопрос про хэшмэп вполне подойдёт. Хард скиллы проверяются, конечно, другими вопросами.
👍88❤20🔥7👎3
Привет! Тема ближайших двух недель — безопасность.
Обычно детали скрыты за библиотеками и фреймворками, но важно понимать принцип работы, чтобы не сделать глупых ошибок. У новичков часто не складывается общая картина, поэтому пойдём шаг за шагом и закроем возможные пробелы.
🔸 Часть 1. Симметричное и ассиметричное шифрование
🔸 Часть 2: Цифровые подписи
🔸 Часть 3: HTTPS
А на следующей неделе подробнее поговорим про авторизацию и аутентификацию.
Обычно детали скрыты за библиотеками и фреймворками, но важно понимать принцип работы, чтобы не сделать глупых ошибок. У новичков часто не складывается общая картина, поэтому пойдём шаг за шагом и закроем возможные пробелы.
🔸 Часть 1. Симметричное и ассиметричное шифрование
🔸 Часть 2: Цифровые подписи
🔸 Часть 3: HTTPS
А на следующей неделе подробнее поговорим про авторизацию и аутентификацию.
👍76